There are certain limitations and restrictions to bear
in mind when deciding whether to use a JMS client developed for WebSphere® Application Server Version 5.1 with a later version
of the product.
About this task
You can use a JMS client application developed for WebSphere Application Server Version 5.1 with a later version
of the product without needing to recompile the application client.
However, consider the following points:
Procedure
- A JMS client developed for WebSphere Application Server Version 5.1 can access JMS resources
on a later version, which can be assigned to resources on a service
integration bus, but cannot access directly default messaging JMS
resources on that later version.
Consider the JMS interoperation
scenario, of a Version 5.1 JMS
application that uses JMS resources provided by the default messaging
provider on a node on a later version. The Version 5.1 JMS queue is backed by
a bus queue, which is normal for a JMS queue on the later version,
but there is no configured link between the Version 5.1 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.
Later versions of the product
do not support the equivalent of channel exits. However, JMS clients
developed for WebSphere Application Server Version 5.1 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.1 user IDs and user IDs
on the later version. Security checks are performed at
connection time by using the system security context of the later
version, 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.1 JMS clients
are 12 characters of type "char", you have to create a mapping
between these and the user IDs of the later version.
- Dynamic selectors are not supported. Later versions
of the product do not provide support for dynamic selectors. That
is, it is not possible to change the selector after having created
a session. If you have 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.1 JMS clients
that use a topic connection factory pointing to the high
performance publish/subscribe provider must 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™ EE Connector Architecture (JCA). ASF, used
by JMS applications developed for WebSphere Application Server Version 5.1, is supported to enable
connection to later versions. However, you should consider migrating
your Version 5.1 JMS applications
that use ASF to use JCA.
- Changes to writing and reading messages under syncpoint
scope. A JMS application developed for WebSphere Application Server Version 5.1 uses the Version 5 embedded
messaging provider to 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
later versions cannot do this, because messages are never visible
to a consumer until the message producer commits the message.