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.
Why and when to perform 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 name space. 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,
Figure 2.
- 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:
Steps for this task
- Migrate the WebSphere Application Server node to Version 6. Use the procedure described in Migrating product configurations. 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.
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.
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