This task enables J2EE applications running in WebSphere Application
Server Version 5 to use messaging resources of the default messaging provider
in WebSphere Application Server Version 6 and later versions.
Before you begin
Throughout this topic, the abbreviation "Version 5" refers
to "WebSphere Application Server Version 5" and "Version 6" refers
to "WebSphere Application Server Version 6". For example, "Version
5 JMS resources" refers to JMS resources provided by WebSphere Application
Server Version 5.
This
task refers to the default messaging provider. For related information,
see Managing messaging with the default messaging provider.
JMS connectivity
between the Version 5 messaging provider and later versions is enabled and
managed by a WebSphere MQ client link. This does not mean that
a WebSphere MQ system is involved. The Version 5 messaging provider uses WebSphere
MQ client protocols, and is therefore handled as if it were a WebSphere MQ
client by later versions of the product. The WebSphere MQ client link is provided only for use with JMS applications developed for WebSphere Application Server Version 5. Moreover,
this JMS connectivity is only intended as an aid to migration from the Version
5 messaging provider to the default messaging provider in Version 6 and later
versions. For more information about migrating from the Version 5 messaging
provider, see Migrating from WebSphere Application Server Version 5 embedded messaging.
Applications
running in Version 6 and later versions can use the messaging resources of
the Version 5 messaging provider without any need for a WebSphere MQ client
link.
About this task
To enable JMS applications running in Version 5 to use messaging
resources of the default messaging provider, a WebSphere MQ client link is
created on the Version 6 or later version node. Each WebSphere MQ client
link presents itself as a queue manager and transforms between the WebSphere
MQ client protocols used by Version 5 and the protocols used by the default
messaging provider in Version 6 and later versions.
The following figure
shows a JMS application running on Version 5 using JMS resources provided
by the default messaging provider on a Version 6 node. The JMS queue hosted
by Version 5 is backed by a service integration bus queue, which is normal
for a JMS queue hosted by Version 6 or later versions, but there is no configured
link between the Version 5 JMS queue and the bus queue. The JMS application
communicates with the bus queue through the WebSphere MQ client link and
the messaging engine. To send messages to the bus queue or receive messages
from the queue, the JMS application opens a connection on the WebSphere
MQ client link. This is all invisible to the JMS application, but can
be displayed and managed by the administrator.
Figure 1. WebSphere
Application Server Version 5 JMS application scenario
Note: If
you want to send messages from a Version 5 application to a remote cell rather
than within the same cell, the recommended and supported method for doing
this is to use the IBM Client for JMS on J2SE with IBM WebSphere Application
Server. The client is supported in WebSphere Application Server Version 5
provided that all of the following conditions apply:
- All enterprise applications using the client package the client jar files
inside the EAR file.
- All enterprise beans jar files within the enterprise application EAR file
must include the client jar files in the classpath statement in their manifest.mf
file, for example, Class-Path: sibc.jms.jar sibc.jndi.jar.
- All enterprise applications using the client must be deployed with Classloader
Mode=PARENT_LAST.
IBM Client for JMS on J2SE with IBM WebSphere Application Server is available
for download at
http://www.ibm.com/support/docview.wss?uid=swg24012804.
Procedure
- Configure a Version 6 or later node to support Version 5 applications
that use JMS resources. If you want a Version 6 or later node to
provide JMS destinations for use by applications running on Version 5, complete
the following steps:
- Create an application server.
You
can use an existing application server on the Version 6 or later node; for
example, an application server that a Version 5 application is to be deployed
onto.
- Create a service
integration bus.
You can use an existing bus.
- Add the application
server as a bus member.
This automatically creates
a messaging engine on the application server.
- Create a WebSphere MQ client link on the messaging engine. Specify the following property values:
- Name
- This can be any name that is useful for your administrative purposes.
It is not used by the application environment.
- MQ channel name
- This is the name of the channel for the WebSphere MQ client link, used
to flow messages between the application that is running on Version 5 and
the bus. This name must match the receiving channel name configured for Version
5:
WAS.JMS.SVRCONN
This is the default value shown when you first
display the WebSphere MQ client link settings panel.
- Queue manager name
- This is the virtual queue manager name that is associated with the messaging
engine, and by which the messaging engine is known to applications running
on Version 5 . Type the queue manager name in the form:
WAS_node_name_server_name
Where:- node_name
- is the name of the Version 6 or later node.
- server_name
- is the name of the application server.
The correct value is shown by default when you first display
the WebSphere MQ client link settings panel.
- Default queue manager
- Select this check box if you want the MQ client link to be used as the
default for applications that cannot find a suitable MQ client link to use.
If
an application running on Version 5 specifies that it wants to connect to
a non-default queue manager name, you can configure a WebSphere MQ client
link with that queue manager name. If a WebSphere MQ client link cannot be
found with the required queue manager name, the connection is rejected. Alternatively,
you can select this option on another WebSphere MQ client link, which is used
instead of rejecting the connection.
- Define
a port called JMSSERVER_QUEUED_ADDRESS on the application server. The port number must be the same used by the SIB_MQ_ENDPOINT_ADDRESS
port.
Specify the following property values:
- Port name
- For Well-known Port, select JMSSERVER_QUEUED_ADDRESS
- Host
- Type the IP address, domain name server (DNS) host name with domain name
suffix, or the short DNS host name of the Version 6 or later node.
- Port
- Type the port number used by the SIB_MQ_ENDPOINT_ADDRESS port. By default,
this is 5558.
- Configure a Version 6 managed node to support applications running
on Version 5 that use JMS resources. If you want a Version 6 managed
node to provide JMS destinations for use by applications running on Version
5, complete the following steps:
- Create an application server.
Specify
the name jmsserver.
- Create a service
integration bus.
You can use an existing bus.
- Add the application
server as a bus member.
This automatically creates
a messaging engine on the application server.
- Create a WebSphere MQ client link on the messaging engine. Specify the following property values:
- Name
- This can be any name that is useful for your administrative purposes.
It is not used by the application environment.
- MQ channel name
- This is the name of the channel for the WebSphere MQ client link, used
to flow messages between the application running on Version 5 and the bus.
This name must match the receiving channel name configured for Version 5:
WAS.JMS.SVRCONN
This
is the default value shown when you first display the WebSphere MQ client
link settings panel.
- Queue manager name
- This is the virtual queue manager name that is associated with the messaging
engine, and by which the messaging engine is known to applications running
on Version 5. Type the queue manager name in the form:
WAS_node_name_jmsserver
Where:- node_name
- is the name of the Version 6 or later node.
The correct value is shown by default when you first display
the WebSphere MQ client link settings panel.
- Default queue manager
- Select this check box if you want the MQ client link to be used as the
default for applications that cannot find a suitable MQ client link to use.
If
an application running on Version 5 specifies that it wants to connect to
a non-default queue manager name, you can configure another WebSphere MQ client
link with that queue manager name. If a WebSphere MQ client link cannot be
found with the required queue manager name, the connection is rejected. Alternatively,
you can select this option on a WebSphere MQ client link, which is used instead
of rejecting the connection.
- Define
a port called JMSSERVER_QUEUED_ADDRESS on the application server. The port number must be the same used by the SIB_MQ_ENDPOINT_ADDRESS
port.
Specify the following property values:
- Port name
- For Well-known Port, select JMSSERVER_QUEUED_ADDRESS
- Host
- Type the IP address, domain name server (DNS) host name with domain name
suffix, or the short DNS host name of the Version 6 or later node.
- Port
- Type the port number used by the SIB_MQ_ENDPOINT_ADDRESS port. By default,
this is 5558.
- If the application looks up JMS resources in JNDI on the Version
6 or later application server , configure the JMS resources on the Version
6 or later application server as Version 5 Default Messaging JMS resources.
- For each JMS queue destination that the application uses, create a Version
5 Default Messaging WebSphere queue destination.
- For each JMS queue destination that the application uses, create a bus destination with the same
name. Assign the bus destination to a bus member in the same bus as the jmsserver bus
member.You
must also create an alias destination with an identifier WQ_<destination_name>,
that points to the service integration destination that has been created.
The WQ_ prefix is needed because all destination names are prefixed with WQ_.
If you are manually migrating the WebSphere JMS Provider resources, you also
need to create the 'WQ_' queues.
- Configure JMS connection factories as Version 5 Default Messaging
WebSphere queue
connection factories and topic connection factories.
- If the application looks up JMS resources outside the JNDI on the
Version 6 or later application server, configure the JMS connection factory
to point to the Version 6 or later node.
Results
The application running on Version 5 can continue to access the
Version 5 JMS resources, which are now implemented through the Version 6 and
later default messaging provider. as shown in the figure Figure 1. The JMS application communicates with the Version 5 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 Version 5 default messaging JMS resources. The new bus queue, shown as
JMS Q, is managed as a resource of the service integration bus. Messages for
JMS Q are stored and processed by the message point for the associated bus
destination, a queue shown as Bus Q. The WebSphere MQ client link presents
itself as a queue manager and transforms between the WebSphere MQ client protocols
used by JMS applications running on Version 5 and the protocols used by messaging
engines on Version 6 and later versions.