Migrate a WebSphere® Application Server Network Deployment environment
from the embedded messaging in WebSphere Application Server Version 5.1 to the default messaging
provider in later versions.
Before you begin
Before migrating a
WebSphere Application Server Version 5.1 node, you need to stop
Version 5.1 JMS applications using
the JMS queues that are to be migrated.
- Stop all message-producing JMS applications in the WebSphere Application Server Version 5.1 environment. For example,
you can use the administrative console to stop the applications, as
described in Starting or stopping 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.
About this task
When migrating a WebSphere Application Server Version 5.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 Version 5.1 JMS
resources, apart from one exception which is described below. For
a more detailed explanation, see Migration from Version 5 embedded messaging.
Consider the basic network deployment
scenario before migration, as shown in the following figure
WebSphere Application Server Network Deployment Version 5.1 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 can 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 Network Deployment Version 5.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
deployment manager on nodeC. The JMS application can 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 default messaging provider
in a later version, complete the following steps:
Procedure
- Migrate the WebSphere Application Server node
to the later version. See the documentation about migrating
product configurations.
At this point, you have a cell in the later version, which
is managed by a deployment manager at that version, with two Version
5 nodes (and their node agents).
- Migrate the JMS server node to the later
version. See the documentation about migrating product
configurations.
As
part of the task for migrating a node, you should complete the following
steps to continue to use Version 5.1 default
messaging JMS resources:
- Create a service integration bus, and add an application
server to that bus.
The 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. JMS applications developed for WebSphere Application Server Version 5.1 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
JMS applications developed for WebSphere Application Server Version 5.1 and the protocols used
by messaging engines in the later version.
- For each resource of Version 5 embedded messaging, create
an equivalent V5 default messaging provider resource.
The administrative name for the embedded messaging JMS resources
is changed from WebSphere JMS Provider resources
to V5 default messaging provider resources.
For example, in the administrative console the queue connection factory
can be found by clicking .
- For each JMS queue defined on the Version 5.1 JMS server, create a
new bus queue with the same name as the Version 5.1 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.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 deployment manager and JMS server
nodes, the network deployment scenario becomes one of interoperation
between
Version 5.1 and later
nodes within a deployment manager cell of the later version as shown
in the following figure
WebSphere Application Server Network Deployment Version 5.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 Version 5.1 JMS Q), are managed by
the Version 7.0 deployment manager as Version 5.1 default messaging JMS
resources.
- The JMS application communicates with the JMS resources developed
for WebSphere Application Server Version 5.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. WebSphere Application Server Network Deployment Version 5.1 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 7.0. The Version 5.1 JMS server has been recreated
as a Version 7.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 WebSphere Application Server Version 5.1 to use the JMS resources.
The interoperation between Version 5.1 and later nodes within
a deployment manager 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.
- Use the migration tools to migrate the Version 5.1 application server nodes
to the later version. See the documentation
about using the migration wizard to migrate product configurations.
- If any Version 5.1 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 of the later version. For example, use the administrative
console to complete the following steps:
- Display the Version 5.1 default
messaging JMS topic connection factory Click .
- For the Port field, select the
QUEUED option
- Click OK.
- 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 WebSphere Application Server Network Deployment Version 5.1 JMS application scenario after migration stage 2.
Figure 3. WebSphere Application Server Network Deployment Version 5.1 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 7.0, but before replacing
JMS resources developed for WebSphere Application Server Version 5.1 with equivalent Version 7.0 JMS resources. The WebSphere MQ client link for the messaging
engine on bus B enables JMS applications to use the Version 5.1 JMS resources implemented
by the Version 7.0 default messaging
provider.
The JMS application can continue to access the Version 5.1 JMS resources, which
are now managed as Version 5.1 default
messaging JMS resources implemented by the WebSphere Application Server Version 7.0 default messaging provider.
You can use the Version 7.0 administrative
console to manage the JMS resources as Version 5.1 default messaging JMS
resources.
There are two variants on this migration:
Figure 4. WebSphere Application Server Network Deployment Version 5.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 deployment manager nodeC and a server node that hosts
both a JMS server and application server. The JMS server developed
for WebSphere Application Server Version 5.1 has been recreated as
a Version 7.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 WebSphere Application Server Version 5.1 to use the JMS resources
implemented by the Version 7.0 default
messaging provider.
What to do next
You should replace the Version 5.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 Configuring resources for the default messaging provider.