IID – Design Patterns

Design Patterns:

When implementing mediation modules, they should have certain common characteristics to optimize component reuse. The design should adhere to one or more of the pattern templates laid out for the project and recommended by product documentation. However, there can be cases where the requirement is such that there is no pattern template that matches the design layout. This case is to be treated as a special one, and a new pattern template for this case should be designed first before moving on to the more technical design.

IBM provides some of the commonly used patterns for Enterprise Service Buses (ESBs), helping speed up the process of implementing solutions. These patterns are commonly used scenarios that all ESB technologies support.

  • Simple service proxy pattern
  • Service selector pattern
  • Service translator pattern
  • Service gateway pattern
  • Message enrichment pattern
  • Batch aggregation pattern
  • Multiple source aggregation pattern

 

More information about these patterns can be found at the IBM WESB Knowledge Center.

 

  1. Simple service proxy pattern

The simple service proxy pattern creates a one-to-one mapping between service requesters and service providers. By placing an ESB between the two services, it hides the real location of the service provider. The simple service proxy pattern is also of particular value in providing a point for access control, request tracking, or auditing.

You can use this pattern when:

  • You want to provide access to a service through a control point without exposing the actual location (endpoint address) of the service to the clients.
  • You must apply some form of control (access management, authorization, auditing, or logging) every time a service is accessed.

  1. Service selector pattern

The service selector pattern provides multiple implementations of the same service interface to be grouped behind a single endpoint address. Each implementation can have a different quality of service or behaviour, and each client request can be matched to a particular implementation determined by different criteria, such as the content of the message into the ESB.

You can use this pattern when:

  • There are multiple implementations of a particular service all sharing the same interface.
  • Different implementations provide different qualities of service.
  • Requests from different clients are to be routed to a particular implementation in accordance with some set of predefined criteria.

 

  1. Service translator pattern

The service translator pattern provides access to a service implementation with a different interface or protocol. You can select operations to be restricted or restructured on some interfaces, and you can convert and format data for users of specific interfaces.

You can use this pattern when:

  • The existing interface provides more functions of the interface than you want to make available.
  • The interface needs to be modified to conform to the company’s requirements.
  • Requesting services expect to use different interfaces or protocols.

                  

  1. Service gateway pattern

The service gateway pattern introduces a point of control, and can bring a range of services under the control of an ESB without the need to develop individual mediations for each service. The service gateway provides a single access point and acts as a proxy for multiple services. In addition, service gateways encapsulate transformations, routing, and common processing across all the services.

You can use this pattern when:

  • You want to route messages to multiple endpoints using a variety of protocols.
  • A set of services needs to be accessed in the same way without the need for multiple mediations.
  • You want to provide generic processing (for example, auditing or a security enforcement point) across all the services.

 

  1. Message enrichment pattern

The message enrichment pattern provides a method to modify or add to the existing content in a message before it is forwarded onto the service provider. An example of message enrichment is to retrieve data from a database and add the data to a given location in a message.

You can use this pattern when messages are sent in order to obtain further information from another database.

  1. Batch aggregation pattern

The batch aggregation pattern provides a method for an inbound request to the mediation to map into several individual outbound requests to the service provider. The responses from these requests can be collected (aggregated) into a single response for the original request.

You can use this pattern when there is a need for messages that include multiple records and each is required to be forwarded onto the service provider individually.

  1. Multiple source aggregation pattern

The multiple source aggregation pattern provides a method for an inbound request to the mediation to map into several individual outbound requests to the service provider. The responses from these requests can be collected (aggregated) into a single response for the original request.

You can use this pattern when there is a single message sent into the ESB that requires two or more service providers to process the message. An aggregated response is sent back to the service requestor.

Authors:

Manju Rahangdale is a Technical Professional in Integration Technologies with 6 years of experience in development, architecture, design, solutioning, and sustenance, covering all aspects of SDLC. He is experienced in analysis, configuration, and implementation of complex integrations like BPEL, ESB, and WebService using IBM Integration Designer.

 

 

Suvajit Mukhopadhyay is a Smarter Process evangelist with nearly 10 years of experience in BPM. He has shown varied expertise in the areas of pre-sales, architecture, design, development, and sustenance with various Fortune 500 customers. He has proven experience with Smarter Process implementations in banking and financial services.