| TOP | PREV | NEXT |
Recall that the previous discussion of the Web service model referred to synchronous and asynchronous communication. There are two principal architectures for Web service interfaces: synchronous Web services and asynchronous Web services. These two architectures are distinguished by their request-response handling. With synchronous services, clients invoke a request on a service and then suspend their processing while they wait for a response. With asynchronous 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.
A Web service may combine synchronous and asynchronous architectures. Often, this architectural decision is made based on the types of work the service performs and the available technologies.
In addition, enterprise application integration (EAI) uses Web services to integrate enterprise information systems. EAI may make use of both synchronous and asynchronous Web services. See EIS Integration with Web Services for a more detailed discussion of EAI.
Synchronous services are characterized by the client invoking a service and then waiting for a response to the request. Because the client suspends its own processing after making its service request, synchronous services are best when the service can process the request in a small amount of time. Synchronous services are also best when applications require a more immediate response to a request. Web services that rely on synchronous communication are usually RPC-oriented. Generally, consider using an RPC-oriented approach for synchronous Web services.
A credit card service, such as one that might be used in an e-commerce application, is a good example of a synchronous service. Typically, a client -- the e-commerce application at check out time -- invokes the credit card service with the credit card details and then waits for the approval or denial of the credit card transaction. The client cannot continue its processing until the transaction completes, and obtaining credit approval is a prerequisite to completing the transaction. (See Figure 1.3.) A stock quote Web service is another example of a synchronous service. A client invokes the quote service with a particular stock symbol and waits for the stock price response.
Figure 1.3 Synchronous Web Service Interaction
Synchronous Web services are architected using a JAX-RPC servlet endpoint. The servlet endpoint receives the client's request and then delegates the request to the service's appropriate business logic, which may reside in the service's Web tier or Enterprise JavaBeansTM (EJBTM) tier. The service's business logic processes the request. It may access the business data through a persistence mechanism, if required. When it completes its processing, the service's business logic formulates a response and the JAX-RPC servlet endpoint returns the response to the client. See Figure 1.4.
Figure 1.4 Synchronous Services With JAX-RPC
A synchronous architecture such as this is also suited to expose a Web service interface to an existing J2EE application that may already have a browser, wireless client, or rich client interface. In such a case, the Web service interface becomes another view (or presentation of) the existing J2EE application.
With asynchronous services, the client invokes the service but does not -- or cannot -- wait for the response. Often, with these services, the client does not want to wait for the response because it may take a significant amount of time for the service to process the request. The client can continue with some other processing rather than wait for the response. Later, when it does receive the response, it resumes whatever processing initiated the service request.
Generally, a document-oriented approach is used for asynchronous class of services. Services which process documents tend to use an asynchronous architecture. A document-oriented Web service receives a document as a service request. The document content determines the processing workflow for the Web service. There can be a number of processing steps required to fulfill the request.
A travel agency service is a good example of a document-oriented Web service that might benefit by using asynchronous communication. The client sends a document (such as an XML document) to the travel service requesting arrangements for a particular trip. Based on the document's content, the service performs such steps as verifying the user's account, checking accommodations and transportation availability, building an itinerary, purchasing tickets, and so forth. Since the travel service must perform a series of often time-consuming steps in its normal workflow, the client cannot afford to pause and wait for these steps to complete. The Java Pet Store supplier sample application is another example of a document-oriented service that works well with asynchronous communication. (See Web Services in the BluePrints Application for more details on the supplier application.)
Figure 1.5 shows how an asynchronous Web service might be architected. This figure shows one recommended approach for architecting a Web service to achieve asynchronous communication in the J2EE 1.3 setting. In this architecture, the client sends a request to the JAX-RPC servlet endpoint on the Web container. The servlet endpoint delegates the client's request to the appropriate business logic of the service. It does so by sending the request as a Java Message Service (JMS) message to a designated JMS queue or topic. The JMS layer (along with message-driven beans) makes asynchronous communication possible.
Figure 1.5 Asynchronous Web Service Communication
After the request is successfully delegated to the business logic, the JAX-RPC servlet endpoint may return an ID to the client. Message-driven beans in the EJB tier read the request and initiate processing so that a response can ultimately be formulated. The service may make the result to the client's request available in one of two ways:
Figure 1.6 shows how the supplier sample application implemented an asynchronous communication such as this. A customer shopping the pet store initiates an order. The pet store application generates a purchase order and sends it via JMS to the Order Processing Center (OPC) application. The OPC has a Web service invoker that sends a supplier purchase order as a request to the supplier application's Web service endpoint. The endpoint receives the request and acknowledges the receipt by sending an ID back to the OPC Web service invoker. Later, when the supplier application fulfills the request, its Web service invoker sends the result to the OPC Web service endpoint.
Figure 1.6 Communication to the Supplier Application