Example: Migrating a message-driven bean from Version 5 embedded messaging - stage 1

You can migrate a message-driven bean application 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.

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 5.11 node, called wasA, on which it runs. When migrating the WebSphere Application Server Version 5.1 node to later versions, 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.1 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.1 single-node MDB application scenario before migration
This figure shows a WebSphere Application Server Version 5 single-node MDB application scenario before migration.
  • The JMS resources are defined on WebSphere Application Server Version 5.1 as embedded messaging JMS resources:
    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:
    1. 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.
    2. 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.
    3. 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.1 node after migration.
  • 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 on the service integration bus. This is all invisible to the JMS application.
  • 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.1 default messaging JMS resources.

You should then replace the Version 5.1 default messaging JMS resources with equivalent default messaging provider JMS resources in the later version as soon as is conveniently possible (for example, after any Version 5.1 JMS client applications have been migrated onto the later version).

To migrate the MDB application from Version 5 embedded messaging to the default messaging provider in the later version, complete the following steps:

Procedure

  1. Migrate the WebSphere Application Server node to the later version. See the documentation about migrating product configurations. The Version 5 embedded messaging JMS resources have been migrated to Version 5.1 default messaging JMS resources.
  2. If any JMS application uses the Version 5 embedded messaging provider 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 default messaging provider of the later version.

Results

After migrating the Version 5.1 node, the MDB application scenario becomes as shown in the following figure:
Figure 2. WebSphere Application Server Version 5.1 node after migration
This figure shows a WebSphere Application Server Version 5 single-node MDB application scenario after migration.

The MDB application can continue to access the JMS resources, which are now implemented through the WebSphere Application Server default messaging provider in the later version. You can use the administrative console of that later version to manage the JMS resources as Version 5.1 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.1 MDB application, you should complete the following steps:
  1. You should replace Version 5.1 default messaging JMS resources with equivalent default messaging provider JMS resources of the later version as soon as is conveniently possible (after all JMS applications that use those resources have been moved onto the later version).
  2. Change the configuration of the MDB application to use a JMS activation specification instead of the listener port.
  3. 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 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 can replace the resources by writing some scripting that retrieves the Version 5.1 property values then creates JMS resources in the later version with values appropriate to that environment and your use of the Version 5.1 properties.

For an example of migrating the MDB application from Version 5.1 default messaging JMS resources and listener port to default messaging provider JMS resources in a later version, including JMS activation specification, see tjn0044_.html#tjn0044_.

1 To make reading easier in this topic, the abbreviation "Version 5.1" is sometimes used to refer to "WebSphere Application Server Version 5.1". For example, "Version 5.1 JMS resources" refers to JMS resources provided by WebSphere Application Server Version 5.1.
Task topic    

Terms of Use | Feedback

Last updated: Oct 21, 2010 3:36:59 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-express-iseries&topic=tjn0043_
File name: tjn0043_.html