Migrating a network deployment configuration from Version 5 embedded messaging

Migrate a WebSphere® Application Server Network Deployment environment from the embedded messaging in WebSphere Application Server Version 5.1 to the default messaging provider in later versions.

Before you begin

Before migrating a WebSphere Application Server Version 5.1 node, you need to stop Version 5.1 JMS applications using the JMS queues that are to be migrated.

About this task

When migrating a WebSphere Application Server Version 5.1 node to a later version, you do not need to make any changes to JMS applications; they can continue to use their same deployment and installation, and their same configurations of Version 5.1 JMS resources, apart from one exception which is described below. For a more detailed explanation, see Migration from Version 5 embedded messaging.

Consider the basic network deployment scenario before migration, as shown in the following figure WebSphere Application Server Network Deployment Version 5.1 JMS application scenario before migration.
  • The JMS application uses JNDI to look up the JMS resources in the WebSphere Application Server namespace.
  • The JMS resources, in this example a JMS queue connection factory (shown as JMS QCF) and a JMS queue (shown as JMS Q), can be configured as server resources or in the client container . The JMS resources are migrated without change except that if a topic connection factory has the Port property set to DIRECT, you must change it to QUEUED before use with the default messaging provider.
  • The JMS queue connection factory creates connections to the JMS server on nodeA, as defined by the Node property of the connection factory. The connection factory can be configured to connect to a JMS server on any node in the deployment manager cell, and by default connects to the JMS server on the same node as the JMS application.
  • WebSphere Application Server Version 5 embedded messaging uses WebSphere MQ technology, and is implemented through a JMS server that runs as a separate server on the node. The administrator has defined the name of the JMS queue, Q, to the JMS server. The JMS application uses WebSphere MQ client protocols to communicate with the JMS server.
Figure 1. WebSphere Application Server Network Deployment Version 5.1 JMS application scenario before migration.
This figure is described in the surrounding text.

This figure shows the example network deployment scenario before migrating any nodes to the later version. The JMS application is supported by an application server running on nodeB, and uses JMS resources configured to use a JMS server on nodeA. The cell is managed by the deployment manager on nodeC. The JMS application can be running within the application server or as a JMS client application.

To migrate a WebSphere Application Server Network Deployment environment from Version 5 embedded messaging to the default messaging provider in a later version, complete the following steps:

Procedure

  1. Migrate the WebSphere Application Server node to the later version. See the documentation about migrating product configurations. At this point, you have a cell in the later version, which is managed by a deployment manager at that version, with two Version 5 nodes (and their node agents).
  2. Use the migration tools to migrate the Version 5.1 application server nodes to the later version.
  3. If any Version 5.1 default messaging JMS topic connection factory has the Port property set to DIRECT, you must change it to QUEUED before use with the default messaging provider of the later version. For example, use the administrative console to complete the following steps:
    1. Display the Version 5.1 default messaging JMS topic connection factory Click Resources > JMS > JMS providers > V5 default messaging provider > [Additional Properties] Topic connection factories > factory_name.
    2. For the Port field, select the QUEUED option
    3. Click OK.
    4. Save your changes to the master configuration.

Results

After migrating all the nodes in the cell, the scenario then becomes as shown in the following figure WebSphere Application Server Network Deployment Version 5.1 JMS application scenario after migration stage 2.

Figure 2. WebSphere Application Server Network Deployment Version 5.1 JMS application scenario after migration stage 2.
This figure is described in the surrounding text.

This figure shows the example network deployment scenario after migrating all the nodes to WebSphere Application Server Version 7.0, but before replacing JMS resources developed for WebSphere Application Server Version 5.1 with equivalent Version 7.0 JMS resources. The WebSphere MQ client link for the messaging engine on bus B enables JMS applications to use the Version 5.1 JMS resources implemented by the Version 7.0 default messaging provider.

The JMS application can continue to access the Version 5.1 JMS resources, which are now managed as Version 5.1 default messaging JMS resources implemented by the WebSphere Application Server Version 7.0 default messaging provider. You can use the Version 7.0 administrative console to manage the JMS resources as Version 5.1 default messaging JMS resources.

There are two variants on this migration:
Figure 3. WebSphere Application Server Network Deployment Version 5.1 JMS application scenario after migration of a combined JMS server - application server node
This figure is explained in the surrounding text.

This figure shows an example network deployment scenario after migrating the deployment manager nodeC and a server node that hosts both a JMS server and application server. The JMS server developed for WebSphere Application Server Version 5.1 has been recreated as a Version 7.0 application server with a messaging engine in its own service integration bus, shown as bus nodeB. Also, a WebSphere MQ client link has been created for the messaging engine on bus nodeB, to enable JMS applications developed for WebSphere Application Server Version 5.1 to use the JMS resources implemented by the Version 7.0 default messaging provider.

What to do next

You should replace the Version 5.1 default messaging JMS resources with equivalent default messaging provider JMS resources of the later version as soon as is conveniently possible (that is, after all the JMS applications that use those resources have been moved onto the later version).

You should define any new JMS resources as resources in the later version; for example, as described in Configuring resources for the default messaging provider.

Task topic    

Terms of Use | Feedback

Last updated: Oct 22, 2010 12:21:29 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-zos&topic=tjn0042_
File name: tjn0042_.html