Message-oriented middleware (MOM) solutions are widely deployed and constitute a common enterprise integration component. MOM integrates disparate systems and enables asynchronous transaction models. One such MOM solution is IBM’s WebSphere MQSeries.
Although SOA best practices dictates that integrations with such system rely on standards based protocols such as JMS, we inevitably encounter situations where the preferred integration uses a proprietary channel. For example, although one can fully exchange messages programmatically with WebSphere MQSeries using JMS and JNDI, a native integration mechanism is also available.
This tutorial describes how the SecureSpan SOA Gateway Appliance solution is configured to natively communicate with WebSphere MQSeries to exchange messages (inbound and outbound).
The first thing you need to enable native MQSeries on the SecureSpan SOA Gateway is to install the necessary module. As is with most add-on modules for theSecureSpan SOA Gateway, this is easily and conveniently packaged in an AAR file, which you can retrieve from your Layer 7 support portal. Once the AAR is in place, you will notice two additions to the Layer 7 Policy Manager GUI. First is a new Tasks menu item labeled “Manage Native MQ Connections” as illustrated in Figure 1 below and the second is a new assertion added to the routing palette named “Route via MQ” as illustrated in Figure 2 below.
Figure 1 – Manage Native MQ Connections menu item.
Figure 2 – Route via MQ assertion
The “Manage Native MQ Connections” menu item opens the “Manage WebSphere MQ Queues” dialog, which lets you register existing MQSeries queues that you want the SecureSpan SOA Gateway to interact with. See below Figure 3 the queue properties dialog where connection settings, security parameters and queue handling behavior are defined.
Figure 3 – Registering Queues
Queues registered as outbound can be referred to in a Layer 7 Policy workflow inside a Route via MQ assertion. When registering such a queue, you can specify if a response is expected and, if so, where to read it from. You can have the SOA Gateway create a temporary queue for this transaction or specify a queue in advance where all responses end up for this type of transaction. This is illustrated in Figure 4 below.
Figure 4 – Outbound queue options.
Queues that are registered as inbound will be monitored by the SecureSpan SOA Gateway. For these types of queues, you specify the acknowledgement behavior, the reply behavior and you optionally tell the SOA Gateway which policy to subject messages read from this queue. If you prefer to let the SOA Gateway decide for you what policies are applicable for each message, this will be done based on message level inspection. For example, a SOAP payload would be resolved against a set of published service and associated WSDL to find a match. Inbound queue configuration is illustrated in Figure 5 below.
Figure 5 – Inbound queue options.
Once these queues are registered, the SecureSpan SOA Gateway automatically starts monitoring inbound queues and outbound queues can be chosen from MQSeries Routing policy assertions as part of the runtime workflow. When the SecureSpan SOA Gateway processes inbound or outbound messages from/to Websphere MQSeries, it can read and write RFH/RFH2 headers. These headers can be used to include application level or metadata along with the message payload. The SecureSpan SOA Gateway can be used to either pass-through RFH header information from inbound message to outbound message, interpret and act on information from incoming RFH headers, or inject such headers in messages written to queues. See below Figure 6.
Figure 6 – Routing properties