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
WebSphere Application Server Version 5 network deployment 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 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.
The following figure shows an 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.
Figure 1. WebSphere Application Server
Version 5 network deployment JMS application scenario before migration
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.
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
WebSphere Application Server Version 5 network deployment JMS application scenario after migration stage 1.
- 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.
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.
Figure 2. WebSphere Application
Server Version 5 network deployment JMS application scenario after
migration stage 1
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.
- 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 WebSphere Application Server Version 5 network deployment JMS application scenario after migration stage 2.
Figure 3. WebSphere Application
Server Version 5 network deployment JMS application scenario after
migration stage 2
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:
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.
Figure 4. WebSphere Application
Server Version 5 network deployment JMS application scenario after
migration of a combined JMS server - application server node
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.