Migrating a single node from version 5 embedded messaging

This topic describes the migration of a single-node 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.

Stop all message-producing JMS applications in the WebSphere Application Server version 5 environment. For example, you can use the administrative console to stop the applications, as described in Starting and stopping 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.

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.

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

Note: To make reading easier in this topic, the abbreviation

"version 5" is sometimes used to refer to

"WebSphere Application Server version 5" and

"version 6" is used to refer to

"WebSphere Application Server version 6". For example,

"version 5 JMS resources" refers to JMS resources provided by WebSphere Application Server version 5. Consider the basic single-node scenario shown, before migration, in the following figure Figure 1.

The JMS application uses JNDI to look up the JMS resources in the WebSphere Application Server name space.
The JMS resources in this example are a JMS queue connection factory (shown as JMS QCF) and a JMS queue (shown as JMS Q).
WebSphere Application Server version 5 embedded messaging uses WebSphere MQ technology, and is implemented through a JMS server that runs as the jmsserver service of the application server. The JMS application uses WebSphere MQ client protocols to communicate with the JMS server.

Figure 1. WebSphere Application Server 5 single-node JMS application scenario before migration .

This figure shows the example single-node scenario before migrating the node to WebSphere Application Server version 6. The JMS application is supported by an application server. The JMS application could be running within the application server or as a JMS client application.

To migrate a single-node WebSphere Application Server environment from version 5 embedded messaging to the version 6 default messaging provider, complete the following steps:

Steps for this task

Use the migration wizard to migrate the WebSphere Application Server node to version 6. See Migration for more information. The version 5 embedded messaging JMS resources are renamed to
"V5 Default Messaging" JMS resources in WebSphere Application Server version 6. For example, on the WebSphere 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.
The version 5 application server is migrated to a version 6 application server with the same name. The server is added as a member of a service integration bus that is named for the node on which the server is located. A messaging engine is created automatically on that bus for the application server.
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.
For each JMS queue defined on the version 5 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.
If any V5 default messaging JMS topic connection factory has the Port property set to DIRECT, change it to QUEUED before use with the version 6 default messaging provider. For example, after migrating the node use the version 6 WebSphere 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_tcf_name.
2. For the
  Port field, select the QUEUED option
3. Click
  OK .
4. Save any changes to the master configuration.

After migrating the node, the basic single-node scenario becomes as shown in the following figure Figure 2.

The JMS application can continue to access the version 5 JMS resources, which are now managed as V5 default messaging JMS resources implemented by the WebSphere Application Server version 6 default messaging provider.
The JMS application communicates with the version 5 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 version 5 default messaging JMS resources.
The new bus queue, shown as Bus Q, is managed as a resource of the service integration bus. Messages for JMS Q(V5) are stored and processed by the message point for the associated bus destination, a queue point shown as BusQ@ME.
The WebSphere MQ client link presents itself as a queue manager and transforms between the WebSphere MQ client protocols used by version 5 JMS applications and the WebSphere Application Server version 6 protocols used by messaging engines.

Figure 2. WebSphere Application Server 5 JMS application scenario after migration .

This figure shows an example single-node scenario after migrating the node to WebSphere Application Server version 6. The JMS resources are now managed as V5 default messaging JMS resources implemented by the version 6 default messaging provider. 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 an example single-node scenario after migrating the node to WebSphere Application Server version 6. For more information about this scenario, see the text that accompanies this figure.

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 (after all 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.

Parent topic: Migrating from version 5 embedded messaging

Searchable topic ID: tjn0041