Network Deployment (Distributed operating systems), v8.0 > Reference > Developer best practices

Migration from v5 embedded messaging

When you migrate from WAS Version 5 embedded messaging to the default messaging provider, you do not have to change v5.1 JMS applications, JMS resource definitions, or client JMS resource definitions. Use of bus resources is enabled by a WebSphere MQ client link, and the wildcard syntax is converted automatically for interoperation between v5.1 and later versions.

• You do not have to change v5.1 JMS applications
• You do not have to change v5.1 JMS resource definitions
• You do not have to change v5.1 client JMS resource definitions
• Before migrating a WAS v5.1 node, you might have to consume messages
• You should replace MDB listener ports with JMS activation specifications
• A v5.1 JMS server is converted to a application server at a later level
• Use of bus resources in later versions is enabled by a WebSphere MQ client link
• The wildcard syntax is converted automatically for interoperation between v5.1 and later versions
• Configuration scripts for WAS v5 embedded messaging should not be run, and fail if they are run

You do not have to change v5.1 JMS applications

When migrating a WAS v5.1 node to later versions, 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 v5.1 JMS resources (with one exception given in You do not have to change v5.1 JMS resource definitions).

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

You do not have to change v5.1 JMS resource definitions

When migrating a WAS v5.1 node to later versions, you do not need to make any changes to JMS resource definitions. JMS applications can continue to use their same configurations of v5.1 JMS resources, with the following exception.

The exception to this is for JMS applications that use the v5 embedded messaging provider DIRECT port for publish/subscribe messaging, as set on the WAS topic connection factory. If any WAS v5.1 topic connection factory has the Port property set to DIRECT, change it to QUEUED before use with the default messaging provider in the later version.

If a node is migrated to a later version, the JMS resources are not changed, except to use the new naming convention. That is, the administrative name for the v5 embedded messaging JMS resources is changed from WebSphere JMS Provider resources to V5 Default Messaging resources.

Listener ports are copied over unmodified from the v5.1 configuration, and are used on the later version whenever the associated v5 default messaging resources are used.

After migration to the later version, the JMS resources are implemented through the default messaging provider. We can use the admin console to manage the JMS resources as v5.1 default messaging JMS resources. For example, in the administrative console you can list v5.1 default messaging JMS queue connection factories by clicking Resources -> JMS -> JMS providers -> V5 default messaging provider -> [Additional Properties] Queue connection factories

You should replace v5.1 default messaging JMS resources with equivalent default messaging provider JMS resources as soon as is conveniently possible (after all JMS applications that use those resources have been moved onto the later version). This enables 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 programmatically, for example by some scripting that retrieves the v5.1 property values then creates JMS resources for the later version, with values appropriate to that environment and your use of the v5.1 properties.

New JMS resources should be created as JMS resources in the later version. Any wsadmin or JMX scripts that create v5.1 JMS resources must be changed to create JMS resources for use in the later version.

You do not have to change v5.1 client JMS resource definitions

JMS client applications that have JMS resources configured by using the Application Client Resource Configuration Tool (ACRCT) in WAS v5.1 should continue to work without change with later versions.

You should replace v5.1 default messaging JMS resources with equivalent default messaging provider JMS resources as soon as is conveniently possible (after all the application servers have been migrated onto the later version). You should use the ACRCT ofo the later version to replace the JMS resources and to create any new JMS resources. New JMS resources should be created as JMS resources for the later version.

Before migrating a WAS v5.1 node, you might have to consume messages

When migrating a WAS v5.1 node to a later version, any messages (and knowledge of durable subscriptions) held by the JMS server are not migrated automatically. Whether we have to drain all the JMS queues depends upon your migration strategy.

You should use one of the following migration strategies:

• Before migrating a WAS v5.1 node, you 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.

  For each JMS queue defined on the JMS server, the migration process automatically creates a new bus queue with the same name as the v5.1 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 WAS v5.1 and write an application to run on a later-level node, to access the v5.1 JMS server, get the v5.1 messages, and resend or publish them to applications on the later version.

• Use the message migration utility to migrate the contents of existing WAS v5 embedded messaging queues, as described in Migrate v5.1 messages using the message migration utility.

  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 WAS v5.1 can continue to use the listener port without change in later versions. 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 later default messaging provider is implemented.

The default messaging provider in later versions is implemented as a Java EE 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 default messaging provider.

If you used the listener port retry count in WAS v5.1, there is one extra consideration. The Java EE Connection Architecture has no concept of a listener port retry count, so this is not supported by the later default messaging provider. This should not present a problem because the 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 have to be changed, any wsadmin or JMX scripts that make use of the listener port retry count must be changed to make use of the "Maximum failed deliveries" setting for use in the later version.

A v5.1 JMS server is converted to a application server at a later level

JMS applications developed for WAS v5.1 access JMS resources through a JMS server, which acts as one or more queue managers. The default messaging provider in later versions uses fully-integrated Java technology, and needs no JMS server.

• On a stand-alone node the JMS server runs as the jmsserver service of an application server. If you migrate a WAS v5.1 stand-alone node to a later version, the v5.1 application server is migrated to an application server with the same name, on the later version. The server is added as a member of a service integration bus that is named for the node on which the server is located. A messaging engine is created automatically on that bus for the application server.

• In a cell, each node has at most one JMS server. If you migrate a WAS v5.1 node to a later version, the JMS server is migrated to an application server, called jmsserver, and added as a member of a service integration bus that has the same name as the node. A messaging engine is created automatically on that bus for the application server. There is only one such application server and bus for each v5.1 node.

Use of bus resources in later versions is enabled by a WebSphere MQ client link

Version 5 embedded messaging uses WebSphere MQ technology, and for communication uses WebSphere MQ client protocols. The default messaging provider in later versions uses fully-integrated Java technology, and JMS applications access JMS resources through the messaging engines on a service integration bus.

JMS applications developed for WAS v5.1 can use resources on a service integration bus through a WebSphere MQ client link assigned to a messaging engine on the service integration bus. The WebSphere MQ client link is provided only for use with JMS applications developed for WAS v5.1. This link presents itself as a queue manager and transforms between the WebSphere MQ client protocols used by JMS applications developed for WAS v5.1 and the protocols used by messaging engines in the later version. This link can be used to access JMS resources that have a destination anywhere on the bus or on any other connected bus.

If you migrate a WAS v5.1 node to a later version, a default WebSphere MQ client link is created automatically for the node, and assigned to the messaging engine for the application server that is also created by the migration process. The default link has the following properties:

Property	Value
Name	Default.MQClientLink
Description	Default MQ Client Link
Queue manager name	WAS_nodeName_jmsserver
Channel name	WAS.JMS.SVRCONN

Figure 1. WAS 5 JMS application scenario after migration

This figure shows an example single-node scenario after migrating the node to WAS v7.0. The JMS resources are now managed as v5 embedded messaging JMS resources implemented by the v7.0 default messaging provider. Also, a WebSphere MQ client link and bus queue have been created and assigned to the messaging engine, to enable JMS applications developed for WAS v5.1 to use the JMS resources.

The wildcard syntax is converted automatically for interoperation between v5.1 and later versions

Existing WAS v5.1 client applications using v5.1 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 the administrative interface of a later version shows the XPath syntax.

Configuration scripts for WAS v5 embedded messaging should not be run, and fail if they are run

When upgrading from WAS v5.1, the v5 embedded messaging configuration scripts are retained, but have no influence on the default messaging provider in the later version, and fail if run. Do not run the scripts. Failure of the scripts can appear to be a failure of the installation of the later version, but no damage or action to the installation results from running the scripts.

+

Search Tips   |   Advanced Search