Pattern overview

The IBM® SOA Policy Pattern routes MQ JMS messages based on data held in policy documents retrieved from a service registry.

The IBM SOA Policy Pattern for Red Hat Enterprise Linux V2.0 provisions and manages the IBM PureApplication System (IPAS) hardware or IBM Workload Deployer (IWD) to provide the following features, which are pre-configured as a part of the pattern:

What scenarios are enabled by this pattern?

MQ JMS applications send messages to the JMS input queue for this pattern, and those messages are routed to another MQ JMS queue depending on which policy matches that input message. The pattern uses JMS header information to decide which policies are applicable, then evaluates those policies to determine where the message is routed. A response is sent back to the JMS sending application to acknowledge that the message has been routed. As a result, the pattern can support many JMS applications simultaneously, each with their own routing rules expressed through a set of policies.

Policies specify the schedule in terms of the times of the day and the day of the week, and so on, to route messages to different endpoint destinations. No other conditions or actions are supported in this pattern. The pattern uses the WS-MediationPolicy standard to define how and when messages are routed. The namespace for this standard is http://www.ibm.com/xmlns/stdwip/2011/02/ws-mediation. The Web Services Mediation Policy 1.0 domain defines a set of policy assertions for describing mediation requirements for a service.

Each policy is a part of the SOA policy lifecycle. Policies that are applied must be in the Approved, Deprecated, or Superceded governance states. For more information, see Policy usage in the IBM SOA Policy Pattern.

What is included in the pattern?

The IBM SOA Policy Pattern is an example of a virtual system pattern. A virtual system pattern consists of a collection of parts. Each part is a virtual operating system image containing installed IBM software that has been configured based on pattern parameters supplied during the provisioning process.

This pattern provides three parts:
  • An image containing WebSphere Message Broker V8.0.0.1 and WebSphere MQ V7.0.1.8.
  • An image containing WebSphere Service Registry and Repository V8.0 and WebSphereApplication Server V8.0.
  • An image containing DB2® Enterprise Edition (to support WSRR) V9.7.5.
When the IBM PureApplication System hardware or IBM Workload Deployer user creates an instance of the IBM SOA Policy Pattern to provide a pre-configured ESB, three images are created from those parts. This configuration is shown in the following figure:
Figure 1. Overview of the IBM SOA Policy PatternA diagram representing the configuration, which is explained by text in this section.
To create this configuration the user runs the following components:
  1. One WebSphere MQ queue manager to provide JMS services and allow JMS programs to connect to the pattern.
  2. One preconfigured WebSphere Message Broker to perform the routing between JMS destinations.
  3. One preconfigured WSRR instance to define and manage the policies that control routing.
  4. One DB2 instance to support WSRR.
  5. The IBM Workload Deployer or IBM PureApplication System browser-based user interface used to deploy the pattern.
  6. The Business Space browser-based user interface used for creating and managing policies.

What other applications does it integrate with?

You can load your own policy documents into WSRR and these policies define their own JMS end point destinations. At first configuration, the registry is loaded with two example policies that use two example endpoints. The WebSphere Message Broker configuration included with the IBM SOA Policy Pattern provides a message flow that reads JMS messages from an input queue, and based on the policies retrieved from the registry, routes the messages to output queues.

The IBM SOA Policy Pattern includes a JMS provider but does not include JMS applications, so you need to add your existing MQ JMS applications to complete the solution. JMS destinations are defined using standard WebSphere MQ procedures. You can choose how your MQ JMS applications connect to control what sort of messaging topology you build; they can attach remotely a single queue manager hosted by the pattern, using MQ Client bindings, or they can use MQ distributed messaging techniques to feed messages into the pattern queue manager from an existing remote queue manager.

Draft comment:
!!! NOTE !!! this second part is really a new user story, and not something we have described in the documentation, but it is important to explain the difference between the JMS configuration files needed by the broker and those which might be needed by the applications.

How do you control the message routing?

When the pattern has been instantiated, the routing behaviour is controlled by a policy administrator who uses Business Space (provided with WSRR) to define and manage policies that satisfy routing requirements. For each policy, a JMS destination needs to exist so a messaging administrator must ensure that each JMS endpoint defined in a policy also exists on the messaging subsystem. For more information, see Working with the deployed instance.


Information Information

Feedback

Timestamp icon Last updated: Thursday, 3 July 2014
http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawmbwsrr.doc/topics/pattern_overview.htm