This topic describes considerations for using a Version 5 JMS client
(a JMS client developed for WebSphere Application Server Version 5) with WebSphere
Application Server Version 6.
Why and when to perform this task
You can use a Version 5 JMS client (a J2EE application client
developed to use JMS for WebSphere Application Server Version 5) with WebSphere
Application Server Version 6 without needing to recompile the application
client. However, consider the following points:
- Version 5 JMS client can access Version 5 WebSphere JMS resource,
which can be assigned to resources on a service integration bus, but cannot
access directly Version 6 default messaging JMS resources.
Consider
the JMS interoperation scenario, of a Version 5 JMS application using JMS
resources provided by the default messaging provider on a WebSphere Application
Server version 6 node. The Version 5 JMS queue is backed by a bus queue, as
normal for a version 6 JMS queue, but there is no configured link between
the Version 5 JMS queue and bus queue. The JMS application communicates with
the bus queue through a 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.
- Application servers generate null responses for security flows
sent by clients.
WebSphere Application Server Version 6 does
not support the equivalent of channel exits. However, Version 5 JMS clients
can invoke security, message send, and message receive exits. The message
send and receive exits are driven only at the client end, but clients can
send. security flows to the application server. The application server generates
null security responses for such security flows.
- Create a mapping between Version 5 user IDs and Version 6 user
IDs. Security checks are performed at connection time using the
WebSphere Application Server Version 6 system security context, and at the
time of creating sessions against bus destinations. The user ID associated with the client is used. However,
because user IDs for Version 5 JMS clients are 12 chars, you need to create
a mapping between these and Version 6 user IDs.
- Dynamic selectors are not supported. WebSphere Application
Server Version 6 does not provide support for dynamic selectors. That is,
it is not possible to change the selector after having created a session.
If you need to change a selector after having created a consumer session,
the current consumer session is closed then a new consumer session is created
with the new selector.
- Reconfigure DIRECT topic connections to QUEUED topic connections. Version 5 JMS clients that use a topic connection factory pointing to
the high performance publish/subscribe provider have to change
their topic connection factory to point to the queue based publish/subscribe
provider instead. To do this, change the Port property of the Topic Connection
Factory from DIRECT to QUEUED.
- Application Server Facilities (ASF). The use of ASF
is discouraged by Sun, with the statement that they are superseded by the
Java Connector Architecture (JCA). ASF used by Version 5 JMS applications
is supported to enable connection to WebSphere Application Server Version
6. However, you should consider migrating your Version 5 JMS applications
that use ASF to use JCA.
- Changes to writing and reading messages under syncpoint scope. A Version 5 JMS application that used the Version 5 embedded JMS provider
could write messages under syncpoint scope to a queue, then read those messages
before the writes have been committed. A JMS application that connects to
the default messaging provider in WebSphere Application Server Version 6 cannot
do this, because messages are never visible to a consumer until the message
producer commits the message.