General considerations for migrating from Version 5 embedded messaging

This topic describes the general considerations for migrating from Version 5 embedded messaging to the Version 6 default messaging provider. These general considerations apply to the related migration tasks.

You do not need to change Version 5 JMS applications

When migrating a WebSphere® Application Server Version 5 node to Version 6, you do not need to make any changes to JMS applications; they can continue to use their same deployment and installation, and their same configurations of Version 5 JMS resources (with one exception given in You do not need to change Version 5 JMS resource definitions).

The applications can continue to use the same JMS API classes and listener ports, but rather than communicating to a WebSphere MQ queue manager, the applications communicate with a messaging engine on a service integration bus.

You do not need to change Version 5 JMS resource definitions

When migrating a WebSphere Application Server Version 5 node to Version 6, you do not need to make any changes to JMS resource definitions. JMS applications can continue to use their same configurations of Version 5 JMS resources, with the following exception.

The exception to this is for JMS applications that use the Version 5 embedded messaging provider's DIRECT port for publish/subscribe messaging, as set on the WebSphere topic connection factory. If any Version 5 WebSphere topic connection factory has the Port property set to DIRECT, change it to QUEUED before use with the Version 6 default messaging provider.

If a node is migrated to WebSphere Application Server Version 6, the JMS resources are not changed, except to use the Version 6 naming convention. That is, the administrative name for the Version 5 embedded messaging JMS resources is changed from WebSphere JMS Provider resources to V5 default messaging resources.

Listener ports are copied over unmodified from the Version 5 configuration, and are used on the WebSphere Application Server Version 6, whenever the associated V5 default messaging resources are used.

After migration, the JMS resources are 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. For example, in the Version 6 WebSphere Application Server administrative console you can list Version 5 default messaging JMS queue connection factories can be managed by Resources > JMS > JMS Providers > V5 default messaging provider > Queue connection factories

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). This enables 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 administrative console. Alternatively, you can replace the resources programmatically, for example by 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.

New JMS resources should be created as Version 6 JMS resources. Any wsadmin or JMX scripts that create Version 5 JMS resources need to be changed to create Version 6 JMS resources for use in WebSphere Application Server Version 6.

You do not need to change version 5 client JMS resource definitions

JMS client applications that have JMS resources configured using the Application Client Resource Configuration Tool (ACRCT) in WebSphere Application Server Version 5 should continue to work without change with WebSphere Application Server Version 6.

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 the application servers have been migrated onto WebSphere Application Server Version 6). You should use the Version 6 ACRCT to replace the JMS resources and to create any new JMS resources. New JMS resources should be created as Version 6 JMS resources.

Before migrating a WebSphere Application Server Version 5 node, you might need to consume messages

When migrating a WebSphere Application Server Version 5 node to Version 6, any messages (and knowledge of durable subscriptions) held by the JMS server are not migrated automatically. Whether you need to drain all the JMS queues depends upon your migration strategy.

You should use one of the following migration strategies:
  • Before migrating a WebSphere Application Server Version 5 node, you 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.

    For each JMS queue defined on the JMS server, the migration process automatically creates a new bus queue with the same name as the Version 5 JMS queue, and creates a message point assigned to the messaging engine. Messages sent to the JMS queues are stored and processed at the message point.

  • Leave the JMS server node at WebSphere Application Server Version 5 and write an application to run on a Version 6 node, to access the Version 5 JMS Server, get the Version 5 messages, and resend or publish them to applications on WebSphere Application Server Version 6.
  • Use the message migration utility to migrate the contents of existing WebSphere Application Server Version 5 embedded messaging queues, as described in Migrating Version 5 messages using the WebSphere message migration utility.
    Note: the message migration utility does not migrate publish/subscribe messages or durable subscriptions.

You should replace MDB listener ports with JMS activation specifications

A JMS application that uses a message-driven bean and its listener port in WebSphere Application Server Version 5 can continue to use the listener port without change in WebSphere Application Server Version 6. However, the message listener service uses the Application Server Facilities (ASF), which are an optional part of the JMS specification. Also, ASF is not supported by the service integration technologies on which the Version 6 default messaging provider is implemented.

The Version 6 default messaging provider is implemented as a J2EE Connector Architecture (JCA) resource adapter, for which inbound connectivity is configured as an activation specification. Therefore, as soon as is conveniently possible, you should replace any listener port with a JMS activation specification for use by MDB applications with the Version 6 default messaging provider.

[z/OS] If you also classify inbound MDB work requests for the z/OS® workload manager, you should convert the InboundClassification type="mdb" classifications with SibClassifications type="jmsra" classifications. For more information about classifying MDB work for the Version 6 default messaging provider, see Workload classification file.

[z/OS] If your inbound MDB work is for another JMS provider, such as WebSphere MQ, you should continue to use any listener ports and their associated InboundClassification type="mdb" classifications for the z/OS workload manager. You cannot create specific z/OS workload manager classifications for inbound MDB work to JCA resource adapters other than the Version 6 default messaging provider - such MDB work uses the default z/OS workload manager classification. For more information about classifying MDB work for listener ports, see Workload classification file.

If you used the listener port retry count in WebSphere Application Server Version 5, there is one extra consideration. The Java™ Connection Architecture has no concept of a listener port retry count, so this is not supported by the Version 6 default messaging provider. This should not present a problem because the Version 6 default messaging provides destinations with a "Maximum failed deliveries" setting. This defines the maximum number of times that the service tries to deliver a message to the destination before forwarding it to the exception destination. Although applications do not need to be changed, any wsadmin or JMX scripts that make use of the listener port retry count need to be changed to make use of the "Maximum failed deliveries" setting for use in WebSphere Application Server Version 6.

A Version 5 JMS server is converted to a Version 6 application server [AIX HP-UX Linux Solaris Windows]

Version 5 JMS applications access JMS resources through a JMS server, which acts as one or more queue managers. The WebSphere Application Server Version 6 default messaging provider uses fully-integrated Java technology, and needs no JMS server.

[AIX HP-UX Linux Solaris Windows]

The wildcard syntax is converted automatically for interoperation between Version 5 and Version 6

Existing WebSphere Application Server Version 5 client applications using Version 5 connection factory and destination definitions use the WMQI wildcard convention. Such applications can connect to the default messaging provider and service integration bus, and automatically have their wildcard syntax mapped to the XPath convention when subscriptions are created. Any display of these subscriptions through a Version 6 administrative interface shows the XPath syntax.

Configuration scripts for WebSphere Application Server Version 5 Embedded Messaging should not be run, and fail if they are run

When upgrading from WebSphere Application Server Version 5 to Version 6, the Embedded Messaging configuration scripts are retained, but have no influence on the WebSphere Application Server Version 6 default messaging provider and fail if run. Do not run the scripts. Failure of the scripts can appear to be a failure of the WebSphere Application Server Version 6 installation, but no damage or action to the WebSphere Application Server installation results from running the scripts.




Related tasks
Migrating Version 5 messages using the WebSphere message migration utility
Migrating a stand-alone application server from Version 5 embedded messaging
Migrating a network deployment from Version 5 embedded messaging
Example: Migrating an MDB application from Version 5 embedded messaging - stage 1
Example: Migrating an MDB application from Version 5 embedded messaging - stage 2
Migrating from WebSphere Application Server Version 5 embedded messaging
Reference topic    

Terms of Use | Feedback

Last updated: Feb 19, 2011 5:25:36 AM CST
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v610web&product=was-nd-mp&topic=rjn0040_
File name: rjn0040_.html