The IBM® SOA Policy Pattern routes MQ JMS messages based on data held in policy documents retrieved from a service registry.
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.
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.
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.
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.
!!! 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.