Manage WAS V5.1 JMS use of messaging resources in later versions of WAS ND

To enable JMS applications developed for WAS V5.1 to use messaging resources of the default messaging provider, a WebSphere MQ client link is created on the node of the later version of WAS ND. Each WebSphere MQ client link presents itself as a queue manager and transforms between the WebSphere MQ client protocols used by V5.1 and the protocols used by the default messaging provider in later versions.

Throughout this topic, the abbreviation "Version 5.1" refers to "WAS V5.1" . For example, "Version 5.1 JMS resources" refers to JMS resources provided by WAS V5.1.

This task refers to the default messaging provider. For related information, see Manage messaging with the default messaging provider.

JMS connectivity between the V5.1 messaging provider and the default messaging provider in later versions of the product is enabled and managed by a WebSphere MQ client link. This does not mean that a WebSphere MQ system is involved. The V5.1 messaging provider uses WebSphere MQ client protocols, and is therefore handled as if it were a WebSphere MQ client by the default messaging provider in later versions of WAS ND. The WebSphere MQ client link is provided only for use with JMS applications developed for WAS V5.1. Moreover, this JMS connectivity is only intended as an aid to migration from the V5.1 messaging provider to the default messaging provider of later versions.

See about migrating from the V5.1 messaging provider, see Migrate from WAS V5 embedded messaging.

Applications running in later versions can use the messaging resources of the V5.1 messaging provider without any need for a WebSphere MQ client link.

The following figure shows a JMS application running on V5.1 and using JMS resources provided by the default messaging provider on a V7.0 node. The JMS queue hosted by V5.1 is backed by a service integration bus queue, which is normal for a JMS queue hosted by V7.0, but there is no configured link between the V5.1 JMS queue and the bus queue. The JMS application communicates with the bus queue through the WebSphere MQ client link and the messaging engine. To send messages to the bus queue or receive messages from the queue, the JMS application opens a connection on the WebSphere MQ client link. This is all invisible to the JMS application, but can be displayed and managed by the administrator.

 

• Configure a node on the later version to support V5.1 applications that use JMS resources. If you want a node on the later version to provide JMS destinations for use by applications running on V5.1, complete the following steps:

  1. Create an application server. Use an existing application server on the node; for example, an application server onto which a V5.1 application is to be deployed.

  2. Create a service integration bus. Use an existing bus.

  3. Add the application server as a bus member. This automatically creates a messaging engine on the application server.

  4. Create a WebSphere MQ client link on the messaging engine. Specify the following property values:

     Name

     This can be any name that is useful for the admin purposes. It is not used by the application environment.

     MQ channel name

     This is the name of the channel for the WebSphere MQ client link, used to flow messages between the application that is running on V5.1 and the bus. This name must match the receiving channel name configured for V5.1:

     WAS.JMS.SVRCONN
     

     This is the default value shown when you first display the WebSphere MQ client link settings panel.

     Queue manager name

     This is the virtual queue manager name that is associated with the messaging engine, and by which the messaging engine is known to applications running on V5.1 . Type the queue manager name in the form:

     WAS_node_name_server_name
     
     

     Where:

     node_name

     is the name of the node on the later version of WAS ND.

     server_name

     is the name of the application server.

     The correct value is shown by default when you first display the WebSphere MQ client link settings panel.

     Default queue manager

     Select this check box if you want the WebSphere MQ client link to be used as the default for applications that cannot find a suitable WebSphere MQ client link to use.

     If an application running on V5.1 specifies that it is to connect to a non-default queue manager name, you can configure a WebSphere MQ client link with that queue manager name. If a WebSphere MQ client link cannot be found with the required queue manager name, the connection is rejected. Alternatively, you can select this option on another WebSphere MQ client link, which is used instead of rejecting the connection.

  5. 
     Define a port called JMSSERVER_QUEUED_ADDRESS on the application server. The port number must be the same used by the SIB_MQ_ENDPOINT_ADDRESS port.Specify the following property values:

     Port name

     For Well-known Port, select JMSSERVER_QUEUED_ADDRESS

     Host

     Type the IP address, DNS host name with domain name suffix, or the short DNS host name of the node of the later version of WAS ND.

     Port

     Type the port number used by the SIB_MQ_ENDPOINT_ADDRESS port. By default, this is 5558.

• Configure a managed node on the later version of WAS ND to support applications running on V5.1 that use JMS resources.

  If you want a managed node to provide JMS destinations for use by applications running on V5.1...

  1. Create an application server. Specify the name jmsserver.

  2. Create a service integration bus. Use an existing bus.

  3. Add the application server as a bus member. This automatically creates a messaging engine on the application server.

  4. Create a WebSphere MQ client link on the messaging engine. Specify the following property values:

     Name

     This can be any name that is useful for the admin purposes. It is not used by the application environment.

     MQ channel name

     This is the name of the channel for the WebSphere MQ client link, used to flow messages between the application running on V5.1 and the bus. This name must match the receiving channel name configured for V5.1:

     WAS.JMS.SVRCONN
     

     This is the default value shown when you first display the WebSphere MQ client link settings panel.

     Queue manager name

     This is the virtual queue manager name that is associated with the messaging engine, and by which the messaging engine is known to applications running on V5.1. Type the queue manager name in the form:

     WAS_node_name_jmsserver
     

     Where:

     node_name

     is the name of the node on the later version of WAS ND.

     The correct value is shown by default when you first display the WebSphere MQ client link settings panel.

     Default queue manager

     Select this check box if you want the WebSphere MQ client link to be used as the default for applications that cannot find a suitable WebSphere MQ client link to use.

     If an application developed for WAS V5.1 specifies that it is to connect to a non-default queue manager name, you can configure another WebSphere MQ client link with that queue manager name. If a WebSphere MQ client link cannot be found with the required queue manager name, the connection is rejected. Alternatively, you can select this option on a WebSphere MQ client link, which is used instead of rejecting the connection.

  5. Define a port called JMSSERVER_QUEUED_ADDRESS on the application server. The port number must be the same used by the SIB_MQ_ENDPOINT_ADDRESS port.Specify the following property values:

     Port name

     For Well-known Port, select JMSSERVER_QUEUED_ADDRESS

     Host

     Type the IP address, DNS host name with domain name suffix, or the short DNS host name of the node on the later version of WAS ND.

     Port

     Type the port number used by the SIB_MQ_ENDPOINT_ADDRESS port. By default, this is 5558.

• If the application looks up JMS resources in JNDI on the application server, configure the JMS resources on the application server of the later version as V5.1 default messaging JMS resources.

  1. For each JMS queue destination that the application uses, create a V5 default messaging provider queue destination.

  2. For each JMS queue destination that the application uses, create a bus destination with the same name. Assign the bus destination to a bus member in the same bus as the jmsserver bus member.You must also create an alias destination with an identifier WQ_<destination_name>, that points to the service integration destination that has been created. The WQ_ prefix is needed because all destination names are prefixed with WQ_. If you are manually migrating the WebSphere JMS provider resources, you also have to create the "WQ_" queues.

  3. Configure JMS connection factories as V5.1 default messaging queue connection factories and topic connection factories.

• If the application looks up JMS resources outside the JNDI on the application server, configure the JMS connection factory to point to the node on the later version of WAS ND.

 

Results

The application running on V5.1 can continue to access the JMS resources on the later level of WAS ND, which are now implemented through the default messaging provider, as shown in the figure WAS V5.1 JMS application scenario. The JMS application communicates with the V5.1 JMS resources through the WebSphere MQ client link and the messaging engine. This is invisible to the JMS application. The JMS resources, a JMS queue connection factory, shown as JMS QCF(V5), and a JMS queue, shown as JMS Q(V5), are managed as V5.1 default messaging JMS resources. The new bus queue, shown as JMS Q, is managed as a resource of the service integration bus. Messages for JMS Q are stored and processed by the message point for the associated bus destination, a queue shown as Bus Q. The WebSphere MQ client link presents itself as a queue manager and transforms between the WebSphere MQ client protocols used by JMS applications developed for WAS V5.1 and the protocols used by messaging engines on the later version.