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.

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." />

After migrating the node, the basic single-node scenario becomes as shown in the following figure, WAS v5.1 node after migration.

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