Network Deployment (Distributed operating systems), v8.0 > Migration and coexistence > Migrate Messaging resources > Migrate from WAS v5 embedded messaging

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

We can migrate a message-driven bean application from the embedded messaging in WAS v5.1 to the default messaging provider in later versions. Before migrating a WAS v5.1 node, stop v5.1 JMS applications using the JMS queues that are to be migrated.

• Stop all message-producing JMS applications in the WAS v5.1 environment. For example, you can use the admin console to stop the applications, as described in Start or stop enterprise 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.

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 v5.1 1 node, called wasA, on which it runs. When migrating the WAS v5.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 v5.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. WAS v5.1 single-node MDB application scenario before migration
JMS resources: a JMS queue connection factory, PPQCF; two JMS queues, InQ and OutQ; and a listener port, MDBPort. These resources are to be replaced by equivalent resources of the later version." />

• The JMS resources are defined on WAS v5.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 WAS 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.

• WAS v5 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, WAS v5.1 node after migration.

• The JMS application communicates with the JMS resources developed for WAS v5.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 v5.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 v5.1 default messaging JMS resources.

  • For each JMS queue defined on the v5.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 v5.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 v5.1 JMS client applications have been migrated onto the later version).

To migrate the MDB application from v5 embedded messaging to the default messaging provider in the later version...

Procedure

1. Migrate the WAS node to the later version. See the documentation about migrating product configurations. The v5 embedded messaging JMS resources have been migrated to v5.1 default messaging JMS resources.

2. If any JMS application uses the v5 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 v5.1 node, the MDB application scenario becomes as shown in the following figure:
Figure 2. WAS v5.1 node after migration
JMS resources, but equivalent v7.0 resources have been created for use by the MDB application when it has been redeployed as a JCA 1.5-compliant resource with the JMS activation specification. The v7.0 resources are: a JMS queue connection factory, PPQCF; two JMS queues, InQ and OutQ; and a listener port, MDBPort." />

The MDB application can continue to access the JMS resources, which are now implemented through the WAS default messaging provider in the later version. We can use the admin console of that later version to manage the JMS resources as v5.1 default messaging JMS resources.

The MDB application can continue to receive messages through the listener port.

What to do next

After migrating a v5.1 MDB application, you should complete the following steps:

1. You should replace v5.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.

We can replace JMS resources manually, for example by using the console. Alternatively, you can replace the resources by writing some scripting that retrieves the v5.1 property values then creates JMS resources in the later version with values appropriate to that environment and your use of the v5.1 properties.

For an example of migrating the MDB application from v5.1 default messaging JMS resources and listener port to default messaging provider JMS resources in a later version, including JMS activation specification, see Example: Migrating a message-driven bean from v5 embedded messaging - stage 2.
1 To make reading easier in this topic, the abbreviation "Version 5.1" is sometimes used to refer to "WAS v5.1". For example, "Version 5.1 JMS resources" refers

+

Search Tips   |   Advanced Search