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-

Explore Our Topics

• BPM & Enterprise Architecture
• BPM Standards
• BPM Implementation
• BPM Best Practices
• Continuous Process Improvement
• BPM Governance
• Service Governance

• Business to Business (B2B)
• BPM for Supply Chain
• BPM for Customer Management
• BPM for Financial Services
• BPM for Healthcare & Insurance
• BPM for Government

• Business Activity Monitoring
• Event Processing
• Process Intelligence
• Business Rules Management
• Decision Management
• Operational Intelligence

• Workflow Automation
• BPM & Enterprise 2.0
• BPM & Web 2.0
• BPM & ECM
• Case Management
• Collaboration
• Enterprise Portals
• Social BPM

• BPM & Cloud Integration
• BPM Analysis & Optimization
• Business Process Simulation
• Process Visibility & Monitoring
• Process Orchestration
• Process Discovery
• Process Modeling

Home
Webinars
Blogs
ebizQ Forum
All Topics
Subscriptions
White Papers
Analyst Corner
Follow us on Twitter
Fan us on Facebook

Explore Our Topics

BPM Strategy
BPM Solutions
Event Processing Strategy
Content-Centric & Collaborative BPM
Process-Centric BPM

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