The entire premise behind the Web services paradigm is enabling access to loosely coupled services via the Web. In essence, Web services are based on a synchronous request-response type interaction. On the other hand, a client's interaction with a Web service can be synchronous or asynchronous.
When application functionality is exposed in the form of Web services, one of the dangers in designing the architecture of the service layer is that the designers tend to think from the perspective of service consumption only. In other words, the focus is on "who is going to call me" and not on "whom am I going to call?" Granted that the design of services needs to target the consumer, but when dealing with the asynchronous paradigm, remember that there is also the "callback" to be accounted for. Since Web services are primarily used for integrating heterogeneous platforms, it is important to also consider the constraints of the client.
Please allow me to elaborate. With synchronous services, clients invoke a request on a service and then suspend their processing while they wait for a response. With asynchronous services (also dubbed document-style Web services), clients initiate a request to a service and then resume their processing without waiting for a response. The service handles the client request and returns a response at some later point, at which time the client retrieves the response and proceeds with its processing.
Let us consider this from the design of the client. The client invokes an asynchronous Web service through the interface method exposed by the service. The result of the Web service can be obtained in one of the following ways:
- The client polls for the response. This means that the client calls the Web service interface for a response to the original request at periodic intervals.
- The service calls back the client's service with the result
Incorporating the second approach is a little more complicated. The assumption in this case is that the client is modifiable to the extent that it can be "Web service-enabled." This also leads to a greater coupling between the service interface and the client - the interface developed for this protocol is developed for the sole purpose of being able to complete the circuit. In other words, the service interface developed on the client is for the purpose of completing the functionality of the service that was developed for the application. However, this approach has the advantage of being true to the "event listener" paradigm. While designing the interfaces for the Web service, care should be taken to give the client's architecture due consideration. Several aspects need to be considered, some of which are:
- Technology: Is the client in a state to be Web service enabled? As mentioned earlier, the primary purpose of exposing a Web service interface is to integrate heterogeneous platforms. The client may be a legacy application, in which case, development of a Web service interface on the client may not be feasible.
- Ownership: Even if the client is technologically mature, it may not fall under the purview of the group or organization that is developing the Web service interface.
- Testing: A stable client that now exposes a Web service interface will have to be retested for "callability." This could have substantial impact.
- Ubiquity: Depending on the client to assume a part of the responsibility for the protocol makes the service less ubiquitous. Each client that calls the service will now have to be Web service enabled.