Network Deployment (Distributed operating systems), v8.0 > Migration and coexistence > Migrate Messaging resources > Migrate from WAS v5 embedded messaging

Migrate a network deployment configuration from v5 embedded messaging

Migrate a WAS Network Deployment environment from the embedded messaging in WAS v5.1 to the default messaging provider in later versions. Before migrating a WAS v5.1 node, stop v5.1 JMS applications using the JMS queues that are to be migrated.

• Stop all message-producing JMS applications in the WAS v5.1 environment. For example, you can use the admin console to stop the applications, as described in Start or stop enterprise applications.
• Allow all message-consuming JMS applications (including those consuming publications as a result of durable subscriptions) to continue until all the JMS queues are drained, then stop those applications.

When migrating a WAS v5.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 v5.1 JMS resources, apart from one exception which is described below. For a more detailed explanation, see Migration from v5 embedded messaging.

Consider the basic network deployment scenario before migration, as shown in the following figure WAS Network Deployment v5.1 JMS application scenario before migration.

• The JMS application uses JNDI to look up the JMS resources in the WAS 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, 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 dmgr cell, and by default connects to the JMS server on the same node as the JMS application.
• WAS v5 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. WAS Network Deployment v5.1 JMS application scenario before migration.

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 dmgr on nodeC. The JMS application can be running within the application server or as a JMS client application.

To migrate a WAS Network Deployment environment from v5 embedded messaging to the default messaging provider in a later version...

Procedure

1. Migrate the WAS node to the later version. See the documentation about migrating product configurations. At this point, we have a cell in the later version, which is managed by a dmgr at that version, with two Version 5 nodes (and their node agents).
2. Migrate the JMS server node to the later version. See the documentation about migrating product configurations.

   The migration wizard creates the following results

   • The JMS server is migrated to an application server, called jmsserver, and added as a member of a service integration bus that has the same name. A messaging engine is created automatically on that bus for the application server. There is only one such application server and bus for each v5 node.
   • A default WebSphere MQ client link, called Default.MQClientLink, is created automatically for the node and assigned to the messaging engine for the application server called jmsserver.

   • For each JMS queue defined on the JMS server, the migration process automatically creates a new bus queue with the same name as the v5.1 JMS queue, and creates a message point assigned to the messaging engine. Messages sent to the JMS queues are stored and processed at the message point.

   After migrating the dmgr and JMS server nodes, the network deployment scenario becomes one of interoperation between v5.1 and later nodes within a dmgr cell of the later version as shown in the following figure WAS Network Deployment v5.1 JMS application scenario after migration stage 1.

   • In the example shown in the figure, the JMS resources, a JMS queue connection factory (shown as V5 JMS QCF) and a JMS queue (shown as v5.1 JMS Q), are managed by the v7.0 dmgr as v5.1 default messaging JMS resources.
   • The JMS application communicates with the JMS resources developed for WAS v5.1, through the WebSphere MQ client link and the messaging engine in the application server created from the JMS server. This is all invisible to the JMS application.

   
   Figure 2. WAS Network Deployment v5.1 JMS application scenario after migration stage 1
   

   This figure shows the example network deployment scenario after migrating the dmgr nodeC and the JMS server nodeA to WAS v7.0. The v5.1 JMS server has been recreated as a v7.0 application server with a messaging engine in its own service integration bus, shown as bus nodeA. Also, a WebSphere MQ client link and bus queue have been created and assigned to the messaging engine, to enable JMS applications developed for WAS v5.1 to use the JMS resources.

   The interoperation between v5.1 and later nodes within a dmgr cell of the later version is intended only as an intermediary stage toward a complete cell at that later version. In this scenario, to complete the migration you migrate the remaining application server nodeB.

3. Use the migration tools to migrate the v5.1 application server nodes to the later version. See the documentation about using the migration wizard to migrate product configurations.

4. If any v5.1 default messaging JMS topic connection factory has the Port property set to DIRECT, change it to QUEUED before use with the default messaging provider of the later version. For example, use the admin console...
   1. Display the v5.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 WAS Network Deployment v5.1 JMS application scenario after migration stage 2.
Figure 3. WAS Network Deployment v5.1 JMS application scenario after migration stage 2.

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

The JMS application can continue to access the v5.1 JMS resources, which are now managed as v5.1 default messaging JMS resources implemented by the WAS v7.0 default messaging provider. We can use the v7.0 admin console to manage the JMS resources as v5.1 default messaging JMS resources.

There are two variants on this migration:

• If the application server and JMS server were on the same host, the migration creates the same pair of service integration buses on the one host of the later version, as shown in the following figure WAS Network Deployment v5.1 JMS application scenario after migration of a combined JMS server - application server node.

• If JMS applications on a node of a later version have to use JMS resources provided by a JMS server on a v5.1 node in the cell, they can do so through the v5.1 default messaging JMS resource definitions.

Figure 4. WAS Network Deployment v5.1 JMS application scenario after migration of a combined JMS server - application server node

This figure shows an example network deployment scenario after migrating the dmgr nodeC and a server node that hosts both a JMS server and application server. The JMS server developed for WAS v5.1 has been recreated as a v7.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 WAS v5.1 to use the JMS resources implemented by the v7.0 default messaging provider.

What to do next

You should replace the v5.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 Configure resources for the default messaging provider.

+

Search Tips   |   Advanced Search