Migrate a stand-alone application server from WebSphere® Application Server Version 5 embedded messaging
for use with the default messaging provider in later versions.
Before you begin
Before starting this task you must stop all
Version 5.1 JMS applications that
are using the JMS queues you want to migrate:
- Stop all message-producing JMS applications in the WebSphere Application Server Version 5.1 environment. For example,
use the administrative console to stop the JMS applications, as described
in Starting or stopping enterprise applications.
- Allow all message-consuming JMS applications (including those
JMS applications that are consuming published messages as a result
of durable subscriptions) to continue, until all the queues are drained,
then stop the JMS applications.
About this task
When migrating a WebSphere Application Server Version 5.1 stand-alone application
server to later versions, you do not have to make any changes to JMS
applications that 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.
Before
migrating, consider the stand-alone application server scenario shown
in the following figure
Stand-alone WebSphere Application Server 5 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 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.
To migrate a stand-alone WebSphere Application Server environment
from Version 5 embedded messaging to the default messaging provider
in later versions, complete the following steps:
Procedure
- Migrate the stand-alone WebSphere Application Server to the later version.
See the documentation about migrating product configurations.
As part of the task for migrating an application server,
you should complete the following steps to continue using 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 application server and assign it to one messaging engine on the
service integration bus. The MDB application connects to
the JMS queues through the WebSphere MQ
client link. The application server on which the MDB application
is deployed does not have to be added to any service integration bus.
- 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 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 application 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 Version 5 embedded messaging JMS resources have been
migrated to V5 default messaging JMS resources.
- 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. For example, after migrating the application server,
use the administrative console in the later version 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 the application server, the basic stand-alone
application server scenario becomes as shown in the following figure
WebSphere Application Server Version 5 JMS application scenario after migration.
- 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 default messaging provider
in the later version.
- The JMS application communicates with the Version 5.1 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.1 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.1 JMS applications and
the protocols used by the messaging engines in the later version of
the product.
What to do next
Security tip: If you have
configured authorization level security on Version 5.1 it cannot be migrated
to the later version. The migration tool cannot migrate authorization
security for you and manual configuration is needed.
You
should replace the Version 5.1 default
messaging JMS resources with equivalent default messaging provider
JMS resources as soon as is conveniently possible (after all JMS applications
that use those resources have been moved onto the later version of
the product).
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.