Network Deployment (Distributed operating systems), v8.0 > Migration and coexistence > Migrate Messaging resources > Migrate from WAS v5 embedded messaging
Migrate a stand-alone application server from v5 embedded messaging
Migrate a stand-alone application server from WAS v5 embedded messaging for use with the default messaging provider in later versions. Before starting this task stop all v5.1 JMS applications that are using the JMS queues to migrate:
- Stop all message-producing JMS applications in the WAS v5.1 environment. For example, use the admin console to stop the JMS applications, as described in Start or stop enterprise applications.
- Allow all message-consuming JMS applications (including those JMS applications that are consuming published messages as a result of durable subscriptions) to continue, until all the queues are drained, then stop the JMS applications.
When migrating a WAS v5.1 stand-alone application server to later versions, you do not have to make any changes to JMS applications that can continue to use their same deployment and installation, and their same configurations of v5.1 JMS resources, apart from one exception which is described below. For a more detailed explanation, see Migration from v5 embedded messaging.
Before migrating, consider the stand-alone application server scenario shown in the following figure Stand-alone WAS 5 JMS application scenario before migration.
- The JMS application uses JNDI to look up the JMS resources in the WAS namespace.
- The JMS resources in this example are a JMS queue connection factory (shown as JMS QCF) and a JMS queue (shown as JMS Q).
- WAS v5 embedded messaging uses WebSphere MQ technology, and is implemented through a JMS server that runs as the jmsserver service of the application server. The JMS application uses WebSphere MQ client protocols to communicate with the JMS server.
Figure 1. Stand-alone WAS 5 JMS application scenario before migration. This figure shows the example stand-alone application server scenario before migrating the stand-alone application server to a later version. The JMS application is supported by an application server. The JMS application can be running within the application server or as a JMS client application.
To migrate a stand-alone WAS environment from v5 embedded messaging to the default messaging provider in later versions...
Procedure
- Migrate the stand-alone WAS to the later version.
See the documentation about migrating product configurations.
The v5 embedded messaging JMS resources have been migrated to V5 default messaging JMS resources.
- If any v5.1 default messaging JMS topic connection factory has the Port property set to DIRECT, change it to QUEUED before use with the default messaging provider. For example, after migrating the application server, use the admin console in the later version...
- Display the v5.1 default messaging JMS topic connection factory Click Resources -> JMS -> JMS providers -> V5 default messaging provider -> [Additional Properties] Topic connection factories > factory_name.
- For the Port field, select the QUEUED option.
- Click OK.
- Save your changes to the master configuration.
Results
After migrating the application server, the basic stand-alone application server scenario becomes as shown in the following figure WAS v5 JMS application scenario after migration.
- The JMS application can continue to access the v5.1 JMS resources, which are now managed as v5.1 default messaging JMS resources implemented by the default messaging provider in the later version.
- The JMS application communicates with the v5.1 JMS resources through the WebSphere MQ client link and the messaging engine. This is invisible to the JMS application.
- The JMS resources, a JMS queue connection factory, shown as JMS QCF(V5), and a JMS queue, shown as JMS Q(V5), are managed as v5.1 default messaging JMS resources.
- The new bus queue, shown as Bus Q, is managed as a resource of the service integration bus. Messages for JMS Q(V5) are stored and processed by the message point for the associated bus destination, a queue point shown as BusQ@ME.
- The WebSphere MQ client link presents itself as a queue manager and transforms between the WebSphere MQ client protocols used by v5.1 JMS applications and the protocols used by the messaging engines in the later version of the product.
Figure 2. WAS Version 5 JMS application scenario after migration. This figure shows an example stand-alone application server scenario after migrating the application server to WAS v7.0. The JMS resources are now managed as v5 default 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.
What to do next
Security tip: If we have configured authorization level security on v5.1 it cannot be migrated to the later version. The migration tool cannot migrate authorization security for you and manual configuration is needed.
You should replace the 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 of the product).
You should define any new JMS resources as resources in the later version; for example, as described in Configure resources for the default messaging provider.