WebSphere WebSphere Application Server Network Deployment, Version 6.0.x Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Migrating a network deployment from Version 5 embedded messaging

This topic describes the migration of a network deployment environment from the embedded messaging in WebSphere Application Server Version 5 to the default messaging provider in WebSphere Application Server Version 6.

Before you begin

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

Why and when to perform this task

This topic provides the main steps, which are based on the general considerations given in General considerations for migrating from Version 5 embedded messaging, and link to tasks that provide the detailed steps involved.

The main consideration is that when migrating a WebSphere Application Server Version 5 node to Version 6, 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 JMS resources (with one exception below).

Consider the basic network deployment scenario before migration, as shown in the following figure Figure 1.
Figure 1. WebSphere Application Server Version 5 network deployment JMS application scenario before migration. This figure shows the example network deployment scenario before migrating any nodes to WebSphere Application Server Version 6. 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 could be running within the application server or as a JMS client application.
This figure shows the example network deployment scenario before migrating  any nodes to WebSphere Application Server Version 6.

To migrate a WebSphere Application Server network deployment environment from Version 5 embedded messaging to the Version 6 default messaging provider, complete the following steps:

Steps for this task

  1. Migrate the WebSphere Application Server node to Version 6. Use the procedure described in Migrating product configurations. At this point, you have a WebSphere Application Server Version 6 cell, which is managed by a Version 6 deployment manager, with two Version 5 nodes (and their node agents).

    The Version 5 embedded messaging JMS resources in the deployment manager cell are renamed to "V5 Default Messaging" JMS resources in WebSphere Application Server Version 6. For example, on the administrative console, WebSphere JMS Provider > WebSphere queue connection factories as shown in Version 5 is renamed to V5 Default Messaging > WebSphere queue connection factories in Version 6.

  2. Migrate the JMS server node to Version 6. Use the procedure described in 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 version 5 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 Version 5 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 deployment manager and JMS server nodes, the network deployment scenario becomes one of interoperation between Version 5 and Version 6 nodes within a Version 6 deployment manager cell as shown in the following figure Figure 2.
    • The JMS resources, a JMS queue connection factory (shown as V5 JMS QCF) and a JMS queue (shown as Version 5 JMS Q), are managed by the Version 6 deployment manager as Version 5 default messaging JMS resources.
    • The JMS application communicates with the Version 5 JMS resources 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. WebSphere Application Server Version 5 network deployment JMS application scenario after migration stage 1. This figure shows the example network deployment scenario after migrating the deployment manager nodeC and the JMS server nodeA to WebSphere Application Server Version 6. The Version 5 JMS server has been recreated as a Version 6 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 Version 5 JMS applications to use the JMS resources.
    This figure shows the example network deployment scenario after migrating the deployment manager node C and the JMS server node B to WebSphere Application Server Version 6.

    The interoperation between Version 5 and Version 6 nodes within a Version 6 deployment manager cell is intended only as an intermediary stage toward a complete Version 6 cell. In this scenario, to complete the migration you migrate the remaining application server nodeB.

  3. Use the migration tools to migrate the Version 5 application server nodes to Version 6. Use the procedure described in Using the Migration wizard.
  4. If any Version 5 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. For example, use the Version 6 WebSphere Application Server administrative console to complete the following steps:
    1. Display the Version 5 default messaging JMS topic connection factory Click Resources > JMS Providers > V5 Default Messaging > WebSphere Topic Connection Factories > jms_qcf_name.
    2. For the Port field, select the QUEUED option
    3. Click OK.
    4. Save any changes to the master configuration.

After migrating all the nodes in the cell, the scenario then becomes as shown in the following figure Figure 3.

Figure 3. WebSphere Application Server Version 5 network deployment JMS application scenario after migration stage 2. This figure shows the example network deployment scenario after migrating all the nodes to WebSphere Application Server Version 6, but before replacing Version 5 JMS resources with equivalent Version 6 JMS resources. The WebSphere MQ client link for the messaging engine on bus B enables JMS applications to use the Version 5 JMS resources implemented by the Version 6 default messaging provider.
This figure shows the example network deployment scenario after migrating all the nodes to WebSphere Application Server Version 6.

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

There are two variants on this migration:
Figure 4. WebSphere Application Server Version 5 network deployment JMS application scenario after migration of a combined JMS server - application server node. 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 Version 5 JMS server has been recreated as a Version 6 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 Version 5 JMS applications to use the JMS resources implemented by the Version 6 default messaging provider.
This figure shows an example network deployment scenario after migrating.

You should replace the Version 5 default messaging JMS resources with equivalent Version 6 default messaging provider JMS resources as soon as is conveniently possible (that is, after all the JMS applications using those resources have been moved onto WebSphere Application Server Version 6).

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

Related tasks
Migrating Version 5 messages using the WebSphere message migration utility
Migrating a stand-alone application server from Version 5 embedded messaging
Example: Migrating an MDB application from Version 5 embedded messaging - stage 1
Example: Migrating an MDB application from Version 5 embedded messaging - stage 2
Related reference
General considerations for migrating from Version 5 embedded messaging

Task topic

Terms of Use | Feedback

Last updated: 15 Mar 2007
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc\tasks\tjn0042_.html

© Copyright IBM Corporation 2004, 2007. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)