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 new 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 WebSphere Application Server Version 5 JMS application scenario. 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.