WebSphere Application Sever V7.0 introduced the WebSphere MQ JMS J2C resource adapter (RA) for connecting to WebSphere MQ. RA is supplied by the WebSphere MQ software to be packaged with WebSphere Application Server V7.0. This mandated the applications be developed for WebSphere Application Server V7.0 to use RA for interaction with WebSphere MQ. Consequently, since WebSphere Process Server V7.0 (hereafter called Process Server) uses the WebSphere Application Server facilities, Process Server has leveraged the facilities provided by RA for its message binding components. This introduction of RA has brought significant changes in the message bindings provided by Process Server.
Integration developers need to be aware of these changes when developing applications that use message bindings to connect to WebSphere MQ. The message bindings internally use RA for interaction with WebSphere MQ. One of the significant changes that RA has brought forth is the use of activation specs in the place of listener ports. Process Server administrators need to be aware of tools available to administer the message endpoints to control message flows from WebSphere MQ through the message binding components, especially when using the event sequencing functionality.
Process Server V7.0 introduced dynamic response destinations for message bindings. Therefore, there are no CALLBACK queues for storing correlation information for the request/response operations.
In Process Server V7.0, failed events are generated when there are any runtime exceptions in the MQ/MQJMS bindings. These failed events have their type as MQ. This event type is introduced in addition to existing event types.
This article briefly discusses the above changes in Process Server V7.0 message bindings with sample applications and illustrations.
The article is divided into the following sections:
- Introduction to WebSphere MQ RA
- Administering message endpoints for event sequencing
- Using dynamic response queues for message correlation
- Failed event management in MQ/MQJMS bindings
- You need a good understanding of J2EE concepts.
- You have good hands-on experience developing integration applications using WebSphere Integration Developer and WebSphere MQ.
For the exercises illustrated in the article, the following environment is required:
- WebSphere Integration Developer V220.127.116.11 or with the latest fix pack
- WebSphere MQ V18.104.22.168
Introduction to WebSphere MQ RA
From WebSphere Application Server V7.0 onwards, applications have to use RA
to connect to WebSphere MQ. The previous version of WebSphere Application
Server had a WebSphere MQ JMS provider, which was used for interaction
with WebSphere MQ. The WebSphere MQ JMS provider provided a set of client
libraries located under the
However, going by industry standards, WebSphere MQ decided to develop RA
for interactions with WebSphere MQ. RA is located under the
The upgrades for RA is maintained by the WebSphere Application Server V7.0 fix packs. The version of RA is determined by one of the following ways:
<WPS70_HOME>/InstalledConnectors/wmq.jmsra.rar/META-INF/ra.xml. Observe the
<resourceadapter-version>element. The version is provided in this element:
mqversion.jywith the following contents and execute it using the
wsadmincommand. Make sure that the server started when the command is executed.
wmqInfoMBeansUnsplit = AdminControl.queryNames("WebSphere:type=WMQInfo,*") wmqInfoMBeansSplit = AdminUtilities.convertToList(wmqInfoMBeansUnsplit) for wmqInfoMBean in wmqInfoMBeansSplit: print wmqInfoMBean; print AdminControl.invoke(wmqInfoMBean, 'getInfo', '')
The output looks like Figure 1.
Figure 1. WebSphere MQ JCA RA version
The MQJMS binding is most suitable when working with JMS-style messages in WebSphere MQ. It abstracts some of the details away and works more like the JMS binding types in Process Server, including their data handler styles, function selectors, and so on. For pure WebSphere MQ interactions and messages, the use of MQ binding is selected. In this article, we use the term "message bindings" to represent all the message bindings (MQ, MQJMS, JMS, and generic) provided by Process Server. When there are differences, we will mention the specific binding names.
Process Server provides MQ/MQJMS bindings to integrate SCA components with WebSphere MQ. Prior to Process Server V7.0, the WebSphere MQ JMS provider was used by MQ/MQJMS bindings for interactions with WebSphere MQ. For MQJMS bindings, the provider provides a facility known as listener ports for inbound interactions. The MQ binding used to allow only client transport type to connect to WebSphere MQ. The bindings transport was not supported by the MQ binding. However, the MQJMS binding allowed both client as well as bindings transport modes to connect to WebSphere MQ. The bindings transport mode is used when the WebSphere MQ Queue Manager is running on the same machine as the client. It uses process-to-process communication to improve the performance when the queue manager is running locally. The listener ports need to be configured using the administration console as shown in Figure 2.
Figure 2. Listener port in Process Server V6.2
The listener port has to be configured with the JNDI names of connection factory and the WebSphere MQ JMS destination as shown in Figure 3. When there is a message in the configured WebSphere MQ destination, the listener pushes the message to the endpoints configured to receive the messages. The administration console provided the options to start and stop the listener ports. You can set the initial status of the listener ports to be active or inactive when the application starts up.
Figure 3. Listener port configuration in Process Server V6.2
Figure 4. Listener port configuration in WebSphere Integration Developer V6.2
RA that is provided by WebSphere MQ V7.0 makes it easy for both inbound and outbound interactions. The MQ/MQJMS bindings in Process Server V7.0 use this RA for interactions with WebSphere MQ. The following changes are brought by RA for message bindings:
- Use of J2C activation specifications instead of listener ports on MQJMS bindings.
- MQ bindings introduced the bindings transport for connecting to WebSpere MQ.
- RA provides facilities to support MQ native headers through the MQ JMS API.
Consequently, the introduction of RA has helped to converge JMS, MQ, and MQJMS bindings more closely.
Figure 5 illustrates how Process Server V7.0 connects to the WebSphere MQ Queue Manager.
Figure 5. Connecting to Queue Manager through RA
The legacy applications (application developed for previous versions of Process Server) continue to use the listener ports, using RA.
- Download OrderService.zip from the apps.zip
file provided in the Download section of this tutorial and import it
into WebSphere Integration Developer V22.214.171.124. Observe that the MQ
Export uses the bindings transport whereas the MQJMS Export
uses the client transport. Create the following objects in
WebSphere MQ as shown in Figure 6.
Figure 6. WebSphere MQ objects
- Also create a server-connection channel using the name of CHANNEL1. Note that you will have to create an mqauth authentication alias with proper authorizations to connect to WebSphere MQ in the test server through admin console. Provide the authentication alias in the Security Attributes > Authentication Properties section of the MQJMS export bindings. Click MQJMS Export and then the Properties tab to open the section. Start the test server in WebSphere Integration Developer and deploy the OrderService module.
- Open the admin console and click Resources > JMS >
Activation specifications in the Navigation tree. Observe the
following activation specification created for the exports as shown in
Figure 7. Activation specifications created for the MQ and MQJMS Exports
- Click on each of activation specifications and observe the properties.
- On the administration console, click Resources > JMS >
Queues on the navigation tree. This opens the queues created
for the OrderService module. Click the
queue. Click Custom properties on the right-hand side. The
customer properties, as shown in Figure 8, are set for the JMS queues
created for the MQ bindings.
Figure 8. Custom properties set on MQ queues
If you use the pre-configured resources for MQ bindings, the above properties have to be set for the destinations.
Administering message endpoints for event sequencing
When an application that uses event sequencing is deployed on to a cluster, it is required to have a message endpoint in only one cluster member to be active. If the endpoints on all the cluster members are active, any cluster member can pick up the message from the queue. The sequencing of the message processing is not guaranteed. In the previous versions of Process Server, listener ports provided a way to set the initial status of the endpoints on all the cluster members to inactive. After an application is started, you can select a particular cluster member to activate the endpoint.
With the activation specifications replacing the listener ports in Process Server V7.0, similar capability is required. With Process Server V7.0 Fix Pack 3, the problems around the activation and deactivation of the message endpoints are fixed. The following options help set the message endpoint status:
- You can set the WAS_EndpointInitialState property on the
activation specs to configure the initial status of the message
endpoints. To set the custom property WAS_EndpointInitialState
for an activation specification, enter the values as follows:
- For Name, specify WAS_EndpointInitialState.
- For Value, specify one of the following options:
ACTIVE: Specify a value of ACTIVE if message consumption is to begin as soon as the message driven bean connects with the JMS destination.
INACTIVE: Specify a value of INACTIVE if message consumption is not to begin until you use the wsadmin tool or the administrative console to activate the message consumption for the message driven bean.
For Type, select String.
Figure 9 illustrates how to set for the MQ and MQJMS bindings.
Figure 9. Setting the custom properties on MQ and MQJMS activation specs
- Click Applications > SCA modules > OrderService in the
admin console navigation tree and expand Exports > Binding.
Click either MQ or MQJMS. This is shown in Figure 10.
Figure 10. MQ and MQJMS bindings in the module
Click the MQJMS binding and then the Runtime tab. You can observe the status of the endpoints. You can resume or pause the endpoints through these panels. This is shown in Figure 11.
Figure 11. Controlling the endpoint status through SCA admin panels
You can configure the above property on the OrderService module activation specifications to INACTIVE, and restart the module to observe that the initial status of the corresponding message endpoint has been paused.
- You can use the procedure given in this technote to pause or resume the message endpoints selectively.
With the above facilities, you can set the initial status of the endpoints to INACTIVE after installing and before starting the applications using the event sequencing. You can use the admin console (Step 2 above) or wsadmin scripts (Step 3 above) to set the status to ACTIVE for a selected message endpoint.
Using dynamic response queues for message correlation
- Download the OrderService1.zip and import
into WebSphere Integration Developer. Open the assembly diagram of the
OrderServiceClient module and click MQJMSImport. In the
Properties tab, click the Message Configuration link. For the
Response correlation scheme, a new option is introduced as “Use a
temporary dynamic destination for receiving responses”. This option
allows a temporary queue to be recreated to store the response for
each request that is sent through the import. This option is also
available for JMS and Generic JMS bindings. The target service is
required to honor the ReplyToDestination property to send the response
after processing the request. We recommend this option for short lived
services. This is shown in Figure 12.
Figure 12. Temporary dynamic queues for response correlation
- Deploy on the application and test OrderServiceClientComp in WebSphere Integration Developer. Observe that the request/response operations do not create any CALLBACK queues for storing the correlation information. You can check it using the SIBExplorer embedded with the admin console. When the request is sent to the target service, a temporary queue is created dynamically and it is set to the ReplyToDestination header. The target service processes the request and sends the response to the designated queue.
Failed event management in MQ/MQJMS bindings
Starting from Process Server V7.0, the new MQ failed event type is created to generate the failed events when there are service runtime exceptions while processing MQ messages. You are required to create an appropriate connection factory for the queue manager and provide it in the Failed Event Reply Connection Factory settings on the MQJMS Import and Export bindings. This setting is available on the Request tab for MQJMS exports, and on the Response tab for MQJMS imports. This is shown in Figure 13.
Figure 13. Failed event reply connection factory
This article explained the enhancements provided for message bindings in WebSphere Process Server V7.0. The WebSphere MQ resource adapter brought new improvements in message bindings. The article discussed various options available to administer the message endpoints. It also illustrated the custom properties available on the activation specs to control the status of the message endpoints. The dynamic temporary destinations alleviate the need for CALLBACK queues and reduce the number of queues on the system integration buses. The introduction of the MQ failed event type allows for easy recovery options from errors experienced while processing MQ messages.
- Message bindings in WebSphere Process Server
- WebSphere Process Server V7.0 Information Center
- WebSphere Process Server support blog
- IBM Redbooks on WebSphere Process Server
- WebSphere Process Server product support
- Complimentary data migration documentation
- Technotes and techdocs on migration
- WebSphere Process Server migration planning sheet
- developerWorks WebSphere application connectivity zone