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.
上一页 下一页
