3.5. Processing Layer Design
The processing layer is where the business logic is applied to a Web service request. Recall that Web service is an interoperable way to expose new or existing applications. Hence, regardless of the means you use to expose your application's functionality, the business logic design issues are the same. You must still design the business logic by considering such issues as using enterprise beans, exposing a local or a remote EJB interface model, using container-managed or bean-managed persistence, and so forth.
The issues and considerations for designing an application's processing or business logic layer, such as whether to perform this logic in the Web or EJB tier, are the same whether or not you use a Web service.
We do not address these business logic design issues here, since much of this discussion has already been covered in the book Designing Enterprise Applications with the J2EETM Platform, Second Edition, and you can refer to that book for general guidelines and recommendations. You should also refer to the BluePrints Web site at http://java.sun.com/blueprints for recommendations on designing an application's business processing logic.
In addition to these general guidelines, there are some specific issues to keep in mind when designing the processing layer of a Web service.
Keep the processing layer independent of the interaction layer. By keeping the layers independent and loosely coupled, the processing layer remains generic and can support different types of clients, such as Web service clients, classic Web clients, and so forth. To achieve loose coupling between the layers, consider using delegate classes that encapsulate the access to business components.
Bind XML documents to Java objects in the interaction layer. There are times when your Web service expects to receive from a client an XML document containing a complete request, but the service's business logic has no need to operate on the document. On these occasions, it is recommended that the interaction layer bind the XML document contents to Java objects before passing the request to the processing layer. Since the processing logic does not have to perform the XML-to-Java conversion, a single processing layer can support XML documents that rely on different schemas. This also makes it easy to support multiple versions of an XML schema.
Keep in mind that your processing logic can operate on the contents of an XML document received from a client. Refer to “Handling XML Documents in a Web Service” on page 105, which highlights issues to consider when you pass XML documents to your business processing logic.
Depending on your application scenario, your processing layer may be required to work with other Web service peers to complete a client's request. If so, your processing layer effectively becomes a client of another Web service. Refer to Chapter 5 for guidelines on Web service clients. In other circumstances, your processing layer may have to interact with EISs. For these cases, refer to Chapter 6 for guidelines.