| TOP | PREV | NEXT |
Once you know how to model your Web service and the design approach you want to take, then you are ready to implement the service. The key steps for implementing a Web service are:
Exposing Model Data Via Web Services explains how to design enterprise bean components as reusable Web service components. Web Services in the BluePrints Application shows how the Java Pet Store sample application implemented its Web service.
The Web tier, through a JAX-RPC endpoint, generally receives client requests. Incoming client requests (in the form of SOAP
messages) are mapped to method calls on the classes that implement the Web service interface. This service endpoint should perform
security validation, transform parameters, and pre-process the parameters for these requests before delegating the requests to the
Web service business logic. Parameters are passed as either Java objects, XML documents (javax.xml.transform.Source
objects), or even SOAP document fragments (SOAPElement objects).
While it is straightforward to handle parameters bound to Java objects, additional steps may be required with XML documents. The following steps are recommended:
It is important that security validation be performed as close to the service endpoint as possible, and certainly in the Web tier. Catching errors earlier avoids unnecessary calls to the EJB tier.
Response generation, which is simply constructing the method call return values, is also performed on the Web tier, again as close as possible to the service endpoint. Keeping this functionality in the endpoint enables you to implement caching of data to avoid extra trips to the EJB tier. It also permits centralizing response assembly and XML document transformations, particularly if the document to return to the caller must conform to a different schema from the internal schema.
Figure 1.9 shows the recommended way to handle requests and responses in the Web tier interface.
Figure 1.9 Web Tier Request and Response Processing
The Web service endpoint handles all incoming SOAP requests and delegates to the business logic exposed in the EJB tier, possibly through a Session Facade design pattern in the EJB tier. The Web service interface when implemented in this manner gives you several advantages, since it:
You should consider several guidelines when mapping Web service calls to business logic. Generally, in RPC-oriented Web services, you want to map calls from a Web service interface implementation to a Session Facade. Following this design pattern will make it easier to move at a later date to an enterprise bean endpoint.
It is also important to consider granularity. A Session Facade method should have a granularity that is finer than the Web service interface. That is, one method call on a Web service should map to one or more calls on a Session Facade. When multiple Web service calls map to one Session Facade call, then the Web service must maintain some context regarding the calls. Maintaining such context is not recommended.
With a document-oriented model using asynchronous messaging, it's best to map the request to a JMS message submission. JMS provides the asynchronous handling.
The EJB tier or business layer is where the business logic is applied to a Web service request. A Web service exists to expose an application's functionality. It typically does not influence the business logic processing. This is particularly true for Web services using an object-centric approach. However, there are some guidelines for performing business logic for Web services with document-centric processing.
It is a good practice to keep an enterprise bean's document manipulation logic separate from the business logic.
With document-centric processing, business logic is applied to data accessed through XML documents. Thus, an enterprise bean must read and modify an XML document to apply the business processing. Abstracting document manipulation logic from business logic allows the bean's developer to switch between different XML document manipulation approaches, such as DOM, SAX, JDOM, and so forth, without affecting the business logic. In addition, it completely hides document processing implementation details from the business logic. This is similar to the Data Access Object (DAO) pattern, which abstracts database access code from the bean's business logic.
In the document-centric processing model, an enterprise bean receives an XML document that contains all information for processing a request. Typically, the XML document has well-defined segments containing details about a specific entity.
Rather than pass the entire document to different components, it's best if the receiving bean breaks the document into fragments and passes only the required fragments to other components that implement portions of the business logic.
Figure 1.10 Fragmenting an XML Document
Figure 1.10 shows how the EJB tier might process an XML document representing a purchase order. The document contains such details as account information, credit card data, line items on the order, and so forth. The business logic involves verifying the account, authorizing the credit card, and processing the line items. It's not necessary to pass all the document details to a workflow stage that is only performing one piece of the logic, such as account verification. Passing the entire purchase order document to all stages of the workflow results in unnecessary information flows and extra processing. It is more efficient to extract the logical fragments -- account fragment, credit card fragment, line item fragment -- from the incoming XML document and then pass these individual fragments to the appropriate workflow stages in the most appropriate format (DOM tree, Java object, serialized XML, and so forth) expected by the receiver.
Fragmenting a document has the following benefits:
- It avoids extra processing of superfluous information throughout the workflow.
- It maximizes security because it limits sending sensitive information through the workflow.
- It centralizes the workflow and simplifies the workflow implementation.
- It provides greater flexibility to workflow error handling.
Exposing a Web service means publishing a description of the Web service. A Web service description consists of the service's Web Services Description Language (WSDL) description and XML schemas referenced by the service description. (WSDL is the standard language for describing a service.)
You may publish a Web service description on a corporate registry within an enterprise or on a public registry outside the enterprise. You may also publish XML schemas defined by the Web service on the same corporate or public repository. A Java Web service client uses the JAXR APIs to look up the service description on the corporate or public registry.
You do not need to use a registry if all your clients are dedicated partners. Instead, you can publish your Web service description (the WSDL and XML schemas) on the Web tier of your application or at a well-known location with the proper protection. An example might be a client application of a reseller that has an agreement with a particular supplier and has been statically bound at development time to its supplier's Web service. Only authorized parties can retrieve the service description from the Web tier to generate the client code, as well as reference the XML schemas.
Good design and proper use of the technologies can greatly improve Web service performance. You should consider the following performance recommendations when designing a Web service.
1.4.5.1 Using Caching and Service GranularityWeb service clients tend to be richer clients and thus can do more work on the client side, such as caching. Web services can maximize performance by correctly using data caching. You should consider using caching in a Web service when the service's requested information is primarily read only or when that information changes at a slower rate than at which it is requested.
Caching at the client side may also be effective when the service's granularity of operation is more coarse grained than that of the client requestor. (See Granularity of Web Services.) In such a situation, the service provides more information than the client needs for a particular request. However, if the client issues similar requests, then caching the data may improve response time. This is especially true for clients making synchronous requests, since they must consider the time to construct the response in addition to the time to transfer the data.
On the other hand, fine-grained Web services transfer smaller sets of data but may handle more requests within the same time frame. The amount of time to handle the SOAP protocol, including parsing the XML document request and constructing the XML response, becomes critical, and caching may be useful on the server side. This is especially true when the service exposes fine-grained operations to distributed applications but internally handles coarse-grained requests. Consider caching on the server the SOAP request and response to the Web service itself (with SOAP message handlers) and any internal requests and responses between the Web tier and the EJB tier.
1.4.5.2 Using XMLXML, while it has many benefits, also has performance disadvantages. XML often demands a great deal of CPU processing. Most XML documents must not only be parsed but also validated, and many require additional processing. Processing XML documents also requires a large amount of memory. Typically, XML processing may require creating large numbers of objects, especially when handling document object models of any kind. XML may also be network intensive. A given document may be the aggregation of different external entities. Parsing the document may require that each entity be retrieved across the network.
The following guidelines help minimize the performance overhead of using XML.
- Use XML judiciously. Use XML when you must interoperate with heterogeneous systems and provide loosely-coupled integration points. Try to rely on XML protocols such as those implemented by JAX-RPC. Maximize interoperability by using existing public vertical schemas. Avoid using XML for unexposed interfaces or for exchanges between components that are tightly coupled.
- Avoid unnecessary parsing and validation. Because processing XML documents may be CPU, network, and memory expensive, it's best to keep to a minimum such operations. You should parse incoming XML documents only when the request is properly formulated, such as documents passed as
Sourceparameters to JAX-RPC calls. Validate the document's meta information, which may have been passed as additional JAX-RPC arguments, and perform the security validation before retrieving the document. Always try to use the proper API to process the document.- Bind documents to domain Java objects as soon as possible. Then process the Java objects rather than the XML documents.
Additional guidelines apply when implementing an application that spans multiple containers. When the application components interact remotely, try to pass only Java objects. Also consider using the Transfer Object design pattern. With remote interaction, it is expensive to pass DOM trees, plus not all implementations support Java serialization of DOM trees. While using serialized XML is expensive and thus best avoided, it may be required to provide loosely-coupled integration points.
When application components follow a local interaction mode (they reside in the same container or Virtual Machine), then it is highly efficient to pass Java objects. It is also efficient to pass DOM trees by reference, though this may not be the optimal choice from the perspective of the business object interface. Because of the manipulation required, passing DOM trees by reference impacts memory and processing. However, it is acceptable to do so when required by the application processing model, especially for document-centric models. However, local components should not pass serialized XML among themselves. In the context of a local call, there is no reason to serialize XML and later deserialize it.