| TOP | PREV | NEXT |
Before you even begin to design a Web service, you should decide whether you need a Web service solution for your application. Web services should be used when you need interoperability across heterogeneous platforms. That is, when you need to expose all or part of your application to other applications on different platforms. Implementing a Web service makes sense when your application's clients are potentially non-J2EE applications. Even if your application's clients are all J2EE applications, you may still want to use Web services if your clients are scattered across the Web. However, when clients are all J2EE applications, it may be best to use J2EE technologies and avoid the extra performance cost of a Web service. Keep in mind that one of the key advantages to using Web services technologies is the ability to go through firewalls.
Generic Web services follow the service-oriented architecture model shown in Figure 1.1. In this model, a Web service first publishes its interface to a registry. The client then looks up, or discovers, the Web service from the registry. Last, the client binds to the Web service in order to use its services. In a Java programming environment, the Web service uses the Java API for XML Registries (JAXR) to publish itself to the registry. The client uses the same JAXR API to look up the service in the registry. The client uses JAX-RPC to bind to and use the Web service. See Figure 1.1.
Figure 1.1 Publish-Discover-Bind Model
While this architecture showcases generic Web services, when the service provider and the client are known to each other, they can bypass the publish and discover steps of the process. Instead, they can directly bind with each other and directly use each other's services. This document looks at scenarios in which the service provider and the client know each other.
Key to Web service design are how a Web service processes requests at the server side (its processing model) and how clients invoke and use the service (the Web service's interaction model). Figure 1.2 shows the categorization of Web services according to their interaction and processing models. Notice that typical Web services mix the different interactions and processing models, along with synchronous and asynchronous communication.
Figure 1.2 Web Service Models
A service's processing model may be business object (or method) centric or it may be document centric. The business object-centric approach (referred to as object centric) is driven by a series of method calls. These method calls apply the business logic of the service to a set of business objects containing the information required for processing the request. An example of an object-centric service might be a credit card authorization Web service. Such a service may receive the credit card details as parameters with the method calls. The methods invoked on the service map directly to specific business logic. The method parameters are used to map to a particular business object (such as a session or entity object) or they are used to pass data to the business logic.
With a document-centric Web service, the business logic is kept separate from the document content. The service receives an XML document, and that document contains only data and no explicit binding to the business logic that is to be applied. There is no mapping of the request to the business logic; that is, specific methods are not invoked on the service. Instead, the Web service applies its business logic to the XML document, and the document content determines the processing workflow. A travel agency Web service is a good example of a document-centric service. The service receives a request: an XML document that contains the details of the desired travel itinerary -- dates, places to visit, preferred accommodations, and so forth. The travel agency service processes the request according to the document content.
The interaction model encompasses the client's interaction with the Web service. A client's interaction with a Web service can be
synchronous or asynchronous, or a combination of both types of communication. (That is, some method invocations may be synchronous and
others may be asynchronous.) When a synchronous model is followed, the application typically uses an RPC-oriented interaction. With
this type of interaction, the client's request is mapped to a method call on the Web service's business logic on the server. Using the
credit card service as an example, the client utilizes an RPC call to invoke a method on the credit card service's server. The client
passes the method the credit card details as an argument. The client might invoke a method to authorize use of the credit card and
pass the method an object containing the card details, such as by invoking the method authorizeCreditCard(CreditCard
cardDetails).
Document-centric processing is usually associated with an asynchronous messaging communication. The client's request is sent as a message. The Web service receives the message and processes it, sending the results when it completes its processing. In the case of the travel agency service, the details of the client's travel request are sent to the service as an XML document via a message (or as an attachment to an RPC call). The service receives the document and parses it to determine how to process the request.
The RPC-oriented and document-oriented Web services form two ends of a spectrum. At one end, a Web service may use a totally RPC-oriented interaction model and object-centric processing, in which case you model it as a RPC-oriented Web service. At the other end, a service may be completely document oriented and communicate with asynchronous messaging.
However, keep in mind that most Web services fall somewhere between these two cases and you can mix and match the models. Keep in mind, also, that even a purely RPC-oriented Web service uses XML protocol (Simple Object Access Protocol), though it keeps the use of XML transparent to the client and server. The client and server deal with method calls and objects as parameters to these calls. The underlying platform handles the XML.