The details of a Service Layer are at the discretion of the implementers. However, like any architectural choices, there are better ones as well as some that are not so good. The PanDOORA architectural template recommends an approach that provides advantages over some less-structured but simpler-to-understand designs.

The thinnest possible Service Layer has only three elements:

• A back-end adaptor that knows how to send/receive messages to/from the existing system.
• A front-end Web service that is accessible by the service consumers.
• A mediation layer that converts between the two messaging and invocation styles.

In the simplest implementation all three elements could actually be coded within the “doPost” method of a single servlet. Unfortunately, doing it that way creates an undesirable coupling between the elements and guarantees that a change to any part ripples through the code.

Any best practice approach provides decoupling between the “front” and “back” ends. That makes it easy for the implementer to replace or modify one part without having to recode another part. So if the underlying legacy system undergoes an upgrade that changes details of the messaging, the front end (and the consumers) don’t need to know that or deal with it.

In addition to decoupling the front and back ends, the mediator element should be decoupled from both of them so that it can be changed or replaced as required. In fact, some of the mediator’s responsibilities might be provided by a separate facility such as an ESB. For example, the actual version and location of the service provider could be determined within ESB as a runtime decision. In that case, changing a table might result in another choice. In an example of message-based routing, details of the initial request might result in a different style of response – possibly a choice of currency or language. Maximum flexibility and the opportunities for unlimited value add require that the layers be completely separated.

PanDOORA is an architectural template. It does not provide code, but rather gives guidance on the design. PanDOORA for Web Services helps designers by giving a template for a Service Layer. This layer has six elements. In a specific implementation, each element would normally be a single Java class, although that is not a restriction, just observed practice.

• The Requestor Adaptor knows how to access the underlying system.
• The Requester Agent decouples the Business Service from the Requestor Adaptor.
• The Business Service contains all business logic. It is generally a poor practice to put business logic outside the Business Service.
• The Provider Adaptor is the actual Web service. In practice, this may be a SAAJ-style Servlet, or it could be a Java Bean that is extended with an automatically-generated JAX-RPC SEI.
• The Provider Agent decouples the Provider Adaptor from the Business Service.
• The Client Proxy resides in the client and knows how to access the Provider Adaptor Web service. Depending on the situation, the Client Proxy may be supplied by the implementers of the Provider Adaptor, or it may be generated from supplied WSDL.
• Various “Contracts” are Java Interfaces representing Value Objects containing the parameters that are passed from one layer to the next, which results in a further level of decoupling. We discuss the options for implementing the Contracts below.

1

• Next

Home
Webinars
Blogs
Subscriptions
White Paper
Analyst Corner

Goals

Enabling Business Agility and Reuse
Improving Business Processes
Leveraging Information and Intelligence
Governing the Infrastructure
Leveraging the Connected Web
Securing Enterprise Applications
Supporting Industry Solutions

About Us
Editorial Calendar
Feedback
FAQ
Advertise With Us
Site Map
Privacy Policy
Unsubscribe