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.
- 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.
About 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.
- The JMS application uses JNDI to look up the JMS resources in the WebSphere
Application Server name space.
- 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 could 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 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.
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:
Procedure
- 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, as shown in Version 5
is renamed to in Version 6.
Migrate the JMS server node to Version 6. Use the procedure described in Migrating product configurations.
As part of the task for migrating a node, you should complete
the following steps to continue using default messaging JMS resources from
Version 5:
- Create a service integration bus, and add an application server
to that bus.
The Version 6 default messaging provider is based
on one or more service integration buses. JMS destinations are assigned to
a service integration bus. To make use of resources through service integration
technologies, you can add any application server as a member of the service
integration bus. A messaging engine is created automatically on that bus for
that application server.
- Create a WebSphere MQ client link for the node and assign it
to one messaging engine on the service integration bus. Version
5 JMS applications can use resources on a service integration bus through
a WebSphere MQ client link assigned to a messaging engine on
the service integration bus. 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.
- For each resource of Version 5 embedded messaging, create an
equivalent Version 5 Default Messaging Provider resource.
The administrative name for the embedded messaging JMS resources
is changed from WebSphere JMS Provider resources to Version
5 Default Messaging Provider resources. For example, in the version
6 WebSphere Application Server administrative console the queue connection
factory can be found by
- For each JMS queue defined on the Version 5 JMS server, create
a new bus queue with the same name as the Version 5 JMS queue, and create
a message point assigned to the messaging engine. Messages sent to the JMS
queues are stored and processed at the message point.

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.
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.
- Use the migration tools to migrate the Version 5 application server
nodes to Version 6. Use the procedure described
in Using the Migration wizard to migrate
product configurations.
- 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:
- Display the Version 5 default messaging JMS topic connection
factory Click .
- In the content pane, under the Additional Properties heading,
click Topic connection factoriesjms_qcf_name.
- For the Port field, select the QUEUED
option
- Click OK.
- Save any changes to the master configuration.
Results
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.
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:
- 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 Version 6 host,
as shown in the following figure Figure 4.
- If JMS applications on a Version 6 node need to use JMS resources provided
by a JMS server on a Version 5 node in the cell, they can do so through the
Version 5 default messaging JMS resource definitions.
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.
What to do next
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.