Standards

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.