Benefits of SOA specifications based on design Patterns

• Provide platform for communication between designers by use of pattern names vs. the details of the patterns.
• Collect experience of solving a type of problem.
• Helps making designs more reusable.
• Systematize reuse of things that have been seen before.
• Inspire to teach good design.

• ESB (Enterprise Service Bus): is a new way to integrate applications (services), coordinate resources, and manipulate information in a way which is independant of the actual implementation technology for the attached services.
• JMS (Java Message Service): is a messaging API allowing application components based on the Java 2 Platform, Enterprise Edition (J2EE) to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous.
• WSDL (Web Service Definition Language): XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.
• BPM (Business Process Management): refers to activities performed by businesses to optimize and adapt their processes, commonly grouped into three categories: design, execution and monitoring. Design covers either the design or capture of existing processes. Execution covers development and/or purchase of application to support the busines requirements. Monitoring covers tracking of individual processes so that information on their state becomes transparent.
• BPEL or BPEL4WS (Business Process Execution Language) for Web Services is a XML-based language used for formal specification of business processes and business interaction protocols using Web services. While extending the Web Services interaction model and enabling it to support business transactions, BPEL enables top-down realization of Service Oriented Architecture (SOA) through composition, orchestration, and coordination of Web services. BPEL provides a simple and straightforward approach to compose multiple Web services into new composite services called business processes. It combines efforts through cross-company initiatives from IBM, BEA and Microsoft to develop a universally supported process-related language.

• Unified logical view (facade pattern) if possible, don't expose legacy - use the facade pattern instead
• Adapters (for legacy code) Adapters for legacy interfaces - not always possible to use facade, then use the adapter pattern to expose individual backends
• Composable components (BPEL) to use a language like BPEL, more complicated webservices are required
• Replaceable components (change the implementation, clients still works) if multiple services standardize on a single interface, you can replace one service with another - used in 3 layers: business processes / business transactions / function services

Some SOA relevant design patterns

1. Asyncroneous
   1. Asynchronous query
   2. Point-to-point
   3. Publish-subscriber
2. Syncroneous
   1. Service proxy
   2. Proxy with channel
   3. Service coordinator
   4. Service simulator

1. Asyncroneous Patterns

1. 1. Asynchronous query

Asynchronous query pattern is actually a pattern describing the basic use of a messenger-service queue.

The requester submit a query and receives a correlationID in return, which is a unique number assigned to the message by the queue - a number which will be known by the processor, when it obtain the message to process it. Finally, the requestor waits for a response marked with the originally corrolation ID, which identifies the response as the appropriate processed result for the original request.

The process flow starts by the requester submitting a request to the Service Provider - who queues up the message and returns a correlation ID - the request processor dequeues the request and processes it (processing of the request can take significant time) - when processing is completed, the Processor queues a response message (marked with original correlation ID) - subsequently at some indeterminate point in the future, the Requester asks the Service Provider for a response - if available, the Provider returns that response back to the requester - if not available, the Provider reports such to the Requester (after an timeout), who can choose to either cancel the request or continue to wait, polling the Provider at intervals until response becomes available.

When to use:

• in systems with no need for immediate response

Benefits:

• by asynchronously detaching requester from processor, asynchronous processing of requests becomes possible

Use in J2EE:

• JMS

1. 2. Point-to-point channel

Point-to-Point design pattern ensures that one given message is distributed to (only) one receiver. The channel may have multiple receivers to consume multiple messages concurrently - but if that's the case, only one of them will be allowed consume a particular message. This behaviour is ensured by the channel distributing a message. If multiple receivers try to consume a single message, the channel will only allow one of them succeeds. The receivers themselves have no need to coordinate with each other. This design pattern may be implemented both in synchronous/asynchronous versions - but is usually implemented using (ansynchronous) message queues.

When to use:

• where guaranteed delivery is required to only one receiver

Benefits:

• assigns delivery responsability to the channel and removes need for the receivers to cooperate with each other

Use in J2EE:

• JMS

1. 3. Publish-subscriber

Publish-Subscribe Pattern solves the tight coupling problem - by providing an interface allowing entities interested in information to subscribe to the publisher by registering for the information. This removes coupling by the publisher of information supporting a generic interface for subscribers. Publisher code does not need to be modified every time a subscriber is introduced. This design pattern may be implemented both in synchronous/asynchronous versions - but is usually implemented using (ansynchronous) message queues.

Local Publish-Subscribe Pattern is a pattern where publisher and all the subscribers are a part of the same task.

• PublishStatus - informs registered subscribers about change in status
• Register - handles registration of an object for the status change notification
• Deregister - handles deregistration of an object - to stop receiving notifications of status changes

• PublishStatus - informs registered subscribers about change in status
• HandleRegisterRequest - handles registration request message - enabling remote entities registering for status change messages
• HandleDeregisterRequest - handles deregistration request message - used by remote entities to stop receiving status change messages

When to use:

• where guaranteed delivery is required to only one receiver

Benefits:

• assigns delivery responsability to the channel and removes need for the receivers to cooperate with each other

Use:

• ip multicasting

2. Syncroneous Patterns

2. 1. Service proxy GOF: Proxy pattern

Service proxy pattern decouples the service from the main program, and make it possible to leverage this extra layer to clear the interface and to implement some useful features, such as logging and coordination.

The proxy implements an interface, separating operations required for performing the call: parameter passing - web service calling - reading the results. First step is applying a series of setXXX() methods, one for each parameter involved in the service call. After setting parameters, the service proxy execute the service through its call() method. Finally when method returns, the client can retrieve returned data calling through getter methods getXXX():

Service Proxy class will represents a single service, used in UML diagrams to show relationships, collaborations and more. It should not, however call multiple services (orchistration). Functionality is covered by the Service Coordinator pattern which builds on the Service Proxy pattern.

Naturally you need not use the same queue for request and response. It's just the case here for simplicity.

When to use:

• where integration code is excessively large, multiplicating boilerplate code (xml parsing, validation etc. ) and replicating calls to the same service in different program locations

Benefits:

• organizing code bt providing one service for one class
• decoupling the techical layer and API used to access the service from the client code thus reducing the cost of a possibile API changeover

Use in J2EE:

• Webservices

2. 2. Proxy with channel GOF: Proxy pattern

Proxy with channel pattern decouples communication using a channel object. possibile to decouple the protocol layer from the service aspect. The idea here is to allows change of the physical protocol used; fx. replacing SOAP with JMS or vice versa. Decoupling makes single service and channel class simpler.

When implementing an integration framework using Service Proxy classes, it's possible to end up with a common abstract class that hosts the boilerplate code (xml parsing, validation etc.) used to costruct and decode the SOAP messages. This way, you keep the single Service Proxy classes simpler, but you hardcode in the class hierarchy the wire protocol you're using. Even using JAX-RPC technology you're tying your code to SOAP. It is, despite the API designer's intentions, the only protocol implemented. Even if future implementations will provide different protocols, JAX-RPC architecture requires that you have to regenerate the stub and skeletons for each protocol used.

When to use:

• where integration code is excessively large, multiplicating boilerplate code and replicating calls to the same service in different program locations

Benefits:

• organizing code bt providing one service for one class
• decoupling the techical layer and API used to access the service from the client code thus reducing the cost of a possibile API changeover

Use in J2EE:

• Webservices

2. 3. Service coordinator GOF: Facade

Service coordinator mediates interaction between program and other services. In some respect related to the GOF proxy pattern. Where business processes requires interaction of several services, coordination could be performed by off-the-shelf web services orchestraction products - or implemented by the application logic. Coordinator class implements application logic necessary to manage the interaction between the services.

Solution depends on the nature of the services to integrate. Where distributed transaction system is required or the output from one service is used as input for another service, implementing the logic in the client code ties the particular process (required to perform a business function) with the available services to the application. But the problem is that the process could change, maybe because the required services change themselves. As a result, the developer must rewrite the orchestration code inside the application.

2. 4. Service simulator GOF: Strategy

Service proxy simulates present connections in an actually disconnected environment - by providing the same interface as the original service but without implementing any communication.

This pattern has really two appliances: fake stub-connections in a test environment -or- maybe on a broader scale allowing interfacing to services, which may require direct communication by design

An application may want to call a service - which is not presently available. This could occur when developing in a disconnected environment, or where business processes required for integration are not readily available in the development environment. Here the Service Simulator will apply a special channel, simulating communications necessary to test the application without using the real service.

Abstract Service class contains base functionality for the Service Proxy and hosts a Channel. This component describes the interface of a generic Channel that is implemented in one concrete implementation for each protocol supported (SOAP, XML-RPC, and a REST implementation).