This topic provides an example of the migration of an MDB
(message-driven bean) application 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 a contextual description of the migration,
then a summary of the steps involved.
The
migration of the MDB application is part of the migration of the Version
51 node, called wasA, on which it runs. When migrating
the WebSphere Application
Server Version 5 node to version 6, you do not need to make any changes
to the MDB application; it can continue to use the same deployment
and installation, and the same configurations of Version 5 JMS resources.
However, to complete the migration, you should replace the listener
port used by the MDB application with a JMS activation specification.
Consider
the example scenario shown, before migration, in the following figure.
Figure 1. WebSphere Application
Server Version 5 single-node MDB application scenario before migration
- The JMS resources are defined as embedded messaging JMS resources,
shown on the Version 5 WebSphere Application
Server administrative console under :
- WebSphere Queue connection
factory, PPQCF
Name: |
PPQCF |
JNDI Name: |
jms/SamplePPQCF |
All other properties have default settings. By default,
the connection factory creates connections to the JMS server on the
same node.
- WebSphere Queue, InQ
Name: |
InQ |
JNDI Name: |
jms/SampleInputQueue |
All other properties have default settings.
- WebSphere Queue, OutQ
Name: |
OutQ |
JNDI Name: |
jms/SampleOutputQueue |
All other properties have default settings.
- The MDB application, MyMDB, is installed on the application server
called server1.
- The listener port called MDBPort is defined on the application
server and references the defined JMS queue connection factory and
JMS input queue.
Name: |
MDBPort |
Initial state: |
Started |
Connection Factory JNDI Name: |
jms/SamplePPQCF |
Destination JNDI Name: |
jms/SampleInputQueue |
- The use of these resources in a message flow is:
- The JMS client application uses JNDI to look up the JMS resources
in the WebSphere Application
Server JNDI namespace. The client puts a message on the input queue.
- The message-driven bean in the MyMDB application uses the listener
port to listen for messages arriving on the input queue. When a message
is put on the input queue, the onMessage method of the message-driven
bean is called, and the message-driven bean application puts a reply
message on the output queue.
- The JMS client application gets the reply message from the output
queue.
- WebSphere Application
Server Version 5 embedded messaging uses WebSphere MQ technology, and is implemented
through a JMS server that runs as a service within the application
server. The JMS client application uses WebSphere MQ client protocols to communicate
with the JMS server.
After migrating the node, the basic single-node scenario
becomes as shown in the following figure,
WebSphere Application Server Version 5 node after migration.
- The JMS application communicates with the Version 5 JMS resources
through the WebSphere MQ
client link and the messaging engine on the service integration bus.
This is all invisible to the JMS application.
- The Version 5 application server, server1, is migrated to a Version
6 application server with the same name, and added as a member of
a service integration bus that is named for the bus. A messaging engine
is created automatically on that bus for the application server.
- 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.
- The application server is not added to any service integration
bus. The MDB application connects to the JMS queues through the WebSphere MQ client link.
- The JMS resources, a JMS queue connection factory (shown as V5
JMS QCF) and a JMS queue (shown as V5 JMS Q), are managed as Version
5 default messaging JMS resources.
- For each JMS queue defined on the Version 5 application server,
you create a new bus 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.
You should then replace the Version 5 default messaging
JMS resources with equivalent Version 6 default messaging provider
JMS resources as soon as is conveniently possible (for example, after
any Version 5 JMS client applications have been migrated onto WebSphere Application Server
Version 6).
To migrate the MDB application 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.
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. 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 JMS application uses the Version 5 embedded messaging
provider's DIRECT port for publish/subscribe messaging, as set on
the WebSphere topic connection
factory, change the Port property of the connection factory to QUEUED
before use with the Version 6 default messaging provider.
Results
After migrating the Version 5 node, the MDB application scenario
becomes as shown in the following figure:
Figure 2. WebSphere Application Server
Version 5 node after migration
The MDB application can continue to access the JMS resources,
which are now implemented through 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.
The MDB application can continue to receive messages
through the listener port.
What to do next
After migrating a Version 5 MDB application, you should complete
the following steps:
- You should replace 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).
- Change the configuration of the MDB application to use a JMS activation
specification instead of the listener port.
- Re-deploy or re-install (with the Deploy EJB option selected)
the MDB application.
These steps enable you to benefit from the better performance
of the Version 6 default messaging provider, and to exploit the use
of multiple messaging engines in a service integration bus, and other
default messaging functions enabled by service integration technologies.
You
can replace JMS resources manually, for example by using the WebSphere Application Server
administrative console. Alternatively, you could replace the resources
by writing some scripting that retrieves the Version 5 property values
then creates Version 6 JMS resources with values appropriate to your
Version 6 environment and your use of the Version 5 properties.
For
an example of migrating the MDB application from Version 5 default
messaging JMS resources and listener port to Version 6 default messaging
provider JMS resources including JMS activation specification, see Example: Migrating an MDB application from Version 5 embedded messaging - stage 2
1 To make reading easier in this topic, the abbreviation
"Version
5" is sometimes used to refer to
"WebSphere Application Server Version 5" and
"version
6" is used to refer to
"WebSphere Application
Server Version 6". For example,
"Version 5 JMS resources" refers
to JMS resources provided by WebSphere Application
Server Version 5.