Message binding enhancements in WebSphere Process Server V7.0, Part 1: Developing integration components that interact with WebSphere MQ and other messaging providers

WebSphere® Application Server V7 introduced the WebSphere MQ JMS J2C resource adapter for connecting to WebSphere MQ. This introduction has brought modifications to message bindings in WebSphere Process Server V7. This article explains those enhancements made in the message binding import and export components in Process Server.

Share:

Phani Madgula (mabalaji@in.ibm.com), Software Developer, IBM

author imagePhani Madgula works on WebSphere Process Server Support at the India Software Labs (ISL). He has 6 years experience at IBM. He worked in various product teams, including WebSphere Application Server Community Edition, WebSphere Business Integration Adapters, and DB2. He has experience in developing JEE applications, product support, and database administration. He is an Oracle9i certified professional.


developerWorks Contributing author
        level

Najwa Riyaz (najwariyaz@in.ibm.com), Software Engineer, IBM

Photo of Najwa RiyazNajwa Riyaz works for the WebSphere Service Integration Bus Test team at the India Software Labs (ISL). Prior to this, she worked as a Tester for several components in WebSphere Application Server and as an Automation Developer for the Administration Console. She has 7 years experience at IBM. She has certifications as a WebSphere Application Server System Administrator V6, Sun Java Programmer V5, and IBM Six Sigma Green Belt (quality certification).



13 April 2011

Also available in Chinese

Introduction

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:

Prerequisites

  • You need a good understanding of J2EE concepts.
  • You have good hands-on experience developing integration applications using WebSphere Integration Developer and WebSphere MQ.

System requirements

For the exercises illustrated in the article, the following environment is required:

  • WebSphere Integration Developer V7.0.0.3 or with the latest fix pack
  • WebSphere MQ V7.0.1.3

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 <WPS62_HOME>/lib/WMQ/java/lib directory.

However, going by industry standards, WebSphere MQ decided to develop RA for interactions with WebSphere MQ. RA is located under the <WPS70_HOME>/InstalledConnectors/wmq.jmsra.rar directory.

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:

  1. Open <WPS70_HOME>/InstalledConnectors/wmq.jmsra.rar/META-INF/ra.xml. Observe the <resourceadapter-version> element. The version is provided in this element:
    <resourceadapter-version>7.0.1.3-k701-103-100812</resourceadapter-version>
  2. Create mqversion.jy with the following contents and execute it using the wsadmin command. 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
    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
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
Listener port configuration in Process Server V6.2
Figure 4. Listener port configuration in WebSphere Integration Developer V6.2
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
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.

  1. Download OrderService.zip from the apps.zip file provided in the Download section of this tutorial and import it into WebSphere Integration Developer V7.0.0.3. 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
    WebSphere MQ objects
  2. 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.
  3. 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.
    Figure 7. Activation specifications created for the MQ and MQJMS Exports
    Activation specifications created for the MQ and MQJMS Exports
  4. Click on each of activation specifications and observe the properties.
  5. On the administration console, click Resources > JMS > Queues on the navigation tree. This opens the queues created for the OrderService module. Click the OrderService.OrderServiceExport_MQBinding_MQ_RECEIVE_D 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
    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:

  1. 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:
    1. For Name, specify WAS_EndpointInitialState.
    2. 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
    Setting the custom properties on MQ and MQJMS activation specs
  2. 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
    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
    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.

  3. 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

  1. 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
    Temporary dynamic queues for response correlatio
  2. 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
Failed event reply connection factory

Conclusion

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.


Download

DescriptionNameSize
Code sampleapps.zip26KB

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=646421
ArticleTitle= Message binding enhancements in WebSphere Process Server V7.0, Part 1: Developing integration components that interact with WebSphere MQ and other messaging providers
publish-date=04132011