Migrate a stand-alone application server from WebSphere Application
Server Version 5 embedded messaging for use with the WebSphere Application
Server Version 6 default messaging provider.
Before you begin
Before starting this task you must stop all Version 5 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 environment. For example, use the administrative console
to stop the JMS applications, as described in Starting and stopping 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
For related information, see General considerations for migrating from Version 5 embedded messaging.
When migrating a WebSphere Application Server
Version 5 stand-alone application server to Version 6, you do not need to
make any changes to JMS applications which can continue to use their same
deployment and installation, and their same configurations of Version 5 JMS
resources, apart from one exception which is described below.
Before
migrating, consider the stand-alone application server scenario 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 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 Version 6 default messaging provider,
complete the following steps:
Procedure
- Migrate the stand-alone WebSphere Application Server to Version
6. Use the procedure described in Migrating product configurations.
As part of the task for migrating an application server, 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 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 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 application 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 Version 5 embedded messaging JMS resources have been migrated
to Version 5 default messaging JMS resources.
- 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 Version 6 default messaging provider. For example, after migrating
the application server 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 . All
currently configured JMS providers (default, Version 5 default, and WebSphere
MQ) are listed.
- From the list view, select the required provider.
- In the content pane, under Additional properties, click Topic
connection factories All topic connection factories
for the selected provider are displayed.
- For the Port field, select the QUEUED
option
- Click OK.
- Save any 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
Figure 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.
- 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.
What to do next
Security tip: If you have configured
authorization level security on Version 5 it cannot be migrated to Version
6. The migration tool cannot migrate authorization security for you and manual
configuration is needed.
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;
for example, as described in Configuring resources for the default messaging provider.