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.[AIX Solaris HP-UX Linux Windows]
    • The Version 5.1 application server, server1, is migrated to an application server with the same name on the later version, 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.1 default messaging JMS resources.[AIX Solaris HP-UX Linux Windows]
    • For each JMS queue defined on the Version 5.1 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.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.

    [z/OS] As part of the task for migrating a node, you should complete the following steps to continue to use Version 5.1 default messaging JMS resources:

    [z/OS]
    1. Create a service integration bus, and add an application server to that bus.

      The default messaging provider in later versions 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.

    2. 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.
    3. 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 Resources > JMS > JMS providers > V5 default messaging provider > [Additional Properties] Queue connection factories .

    4. 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 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 10:04:34 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-mp&topic=tjn0043_
File name: tjn0043_.html