Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Computing
Conference & Expo
November 2-4, 2009 NYC
Register Today and SAVE !..

2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
In many cases, the end of the year gives you time to step back and take stock of the last 12 months. This is when many of us take a hard look at what worked and what did not, complete performance reviews, and formulate plans for the coming year. For me, it is all of those things plus a time when I u...
SYS-CON.TV
Web Service Local Reference
Solving significant concerns

There is a need for container-managed support for local invocations among colocated Web services. This feature would be similar to EJB local invocations in the J2EE world.

This need stems from the fact that a lot of enterprise applications are being Web service enabled and wrapped for the twin purposes of easier EAI and external access across firewalls in a standards-based way. Given the increasingly complex nature of business transactions, often these Web services that need to invoke each other due to functional dependencies. Also, some facade Web services need to invoke back-end applications, which themselves are Web services that in turn wrap other legacy applications running on different platforms. In these scenarios, and many others, it would be an overhead to use HTTP/SOAP for invocations among Web services running within the same Web service container.

There needs to be a way for the container to identify potential efficiencies in such scenarios and make use of them. One such way is to use local references for calls among colocated Web services. Also, optionally, Web service clients can be granted an ability to designate some invocations as "local" Web service invocations.

In this article we look at possible scenarios that emphasize the need for such features. Further, we also identify various architectural possibilities for how this can be achieved.

Scenarios
There are various circumstances in which local references to Web services would be useful:

  • Functional dependencies may exist across colocated Web services. For example, a location-based Web service deployed in an MNO (Mobile Network Operator) environment like "local map service" needs location information, which could be provided by a location Web service. Since this location service is possibly in the same Web service container, it would make sense to invoke the location service as a language method call rather than through HTTP/SOAP.
  • Third-party Web services may be needed to wrap around and provide new standards-based interfaces and in turn expose them as new Web services. This can happen, for example, in the case of third-party telecom Web services obeying an MM7 interface to be exposed as Parlay-X Web services. In this scenario, the wrapper Web service can call the underlying Web service more efficiently than by the traditional way of parameter marshalling/ unmarshalling and network invocation.
  • There may be a need to compose existing Web services into more complex and higher value-added Web services, which are branched sequences of simpler Web service invocations. For example, a content portal can compose a profile Web service and a news Web service to give a user a personalized news Web service. This composed service is colocated with the constituent simple Web services and can interact with them using a "local" invocation.
  • There may be a need to provide a facade Web service to multiple other Web services as a common invocation point or common interface. This could serve the dual purpose of simplifying the interfaces to the end user as well as abstracting them from actual service locations. This Web service pattern can have a runtime advantage because the Web services encapsulating the actual business logic are located in the same container.
  • Non-Web service components may exist that invoke Web services within the same container; for example, a servlet or EJB invoking a Web service. In such cases, local invocations can enhance the performance of the applications. Ideally, this must be done transparently by the Web services container.
In these and many similar scenarios, more efficient invocations to Web services would be possible than those supported by the current implementations based on HTTP/SOAP. The Web service containers need to exploit these possibilities and optimize these calls.

Container Architectural Possibilities
Presented here are some possibilities that container providers can explore to achieve local invocations among Web services. The Web service containers can provide Web service client libraries (e.g., JAX-RPC factories) that can internally optimize "local" Web service access. This can be done by first identifying the fact that the invocation is local. This identification can be done in many ways:

  1. By the client application marking the invocation local, or
  2. By the container intelligently deducing this.
In the J2EE world, for example, JAX-RPC client libraries are used for Web service invocations. The "Call" object is configured with invocation parameters and in this case is used as the client-side proxy. By having the Call class determine through the invoked endpoint that the invocation is local, the implementation can intelligently and transparently optimize the invocation.

It should be possible to achieve similar efficiencies in the .NET world.

Using the above mechanisms, the container is able to identify the invocation as local. Further, this information should be used to optimize the invocation itself.

The optimizations in the invocations are container dependent, although there are, again, numerous potential approaches. Containers can choose to convert SOAP/HTTP calls to direct object invocations. This will obviate the overheads in the above protocols and the network latencies.

On another level, the protocols can be optimized to gain execution time economies. Bypassing serialization and deserialization of parameters is another option to achieve similar goals of performance and scalability. One more means of optimization could be to avoid type-mapping lookups for the colocated calls. Another way is to bypass security alone - in case authentication and authorization are already performed in the calling Web service.

Remember that one objective is that existing clients should be unaware of migration. The changes to client libraries must not render existing deployments incompatible.

Heterogeneous Invocations
Since the concept of local invocations is an intracontainer affair, the optimizations can be completely abstracted by container implementations and can be made transparent to the invoking client (see Figure 1).

An added advantage from the above is that the existing clients can enjoy the added performance and scalability without having to undergo any change themselves. This means that heterogeneous invocations (e.g., .NET client to J2EE Web service) will continue to be as much of a possibility as they are today.

Conclusion
Performance and scalability of server components are significant concerns in the Web services implementations. The proposal here aims to mitigate these concerns and help optimize application execution in turn reducing underlying hardware costs. It exploits a priori information available to the container with respect to Web service deployment. This information is utilized for achieving better performance and scalability for invocations between colocated Web services.

About Pankaj Kothari
Pankaj Kothari is a technology consultant at Hewlett-Packard. He has around 7 years of experience in the areas of Web Services, J2EE, and workflow, and
has been involved in various product development efforts at HP.

About Venkat Ragunathan
Venkat Ragunathan is a software architect at Hewlett-Packard. He has 14 years of experience in the areas of Web services, mobility and Internet applications and has been involved in various product and solution development efforts at HP.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

Hi Stephen:
As one of the co-authors of this article, we would wish to state that we don't want to tie the web service to a single platform. As far as JAX-RPC is concerned, we have said that how web service local reference can be achieved in a J2EE container. Similar approaches are possible in .NET world. This in no way is going to affect how the web service is consumed by the end client and hence the interoperability issues also don't arise.

I've heard this all before. This is just another example of pplication server vendors to make themselves relevant in a Web Services Environment. Everyone talks about the overhead of HTTP/SOAP, in actually what I've found is most of the overhead and inefficiencies can be trace to badly implemented Application Server SOAP stacks and badly implemented Services (usually automatically generated from EJB interfaces). Tying the Web Services stack to any particular technology is a bad idea and is counter to the original goals Web Services are trying to achieve.


Your Feedback
Venkatavaradan wrote: Hi Stephen: As one of the co-authors of this article, we would wish to state that we don't want to tie the web service to a single platform. As far as JAX-RPC is concerned, we have said that how web service local reference can be achieved in a J2EE container. Similar approaches are possible in .NET world. This in no way is going to affect how the web service is consumed by the end client and hence the interoperability issues also don't arise.
P. Stephen Murphy wrote: I've heard this all before. This is just another example of pplication server vendors to make themselves relevant in a Web Services Environment. Everyone talks about the overhead of HTTP/SOAP, in actually what I've found is most of the overhead and inefficiencies can be trace to badly implemented Application Server SOAP stacks and badly implemented Services (usually automatically generated from EJB interfaces). Tying the Web Services stack to any particular technology is a bad idea and is counter to the original goals Web Services are trying to achieve.
SOA World Latest Stories
When building large, cloud-based applications that operate at a high scale, it’s important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. “Fly two mistakes ...
Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations, in addition to network and sy...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand usin...
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portabil...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is founda...
Using new techniques of information modeling, indexing, and processing, new cloud-based systems can support cloud-based workloads previously not possible for high-throughput insurance, banking, and case-based applications. In his session at 18th Cloud Expo, John Newton, CTO, Founder an...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021


SYS-CON Featured Whitepapers
Most Read This Week
ADS BY GOOGLE