Network Deployment (Distributed operating systems), v8.0 > Migration and coexistence > Migrate Messaging resources
Use a v5.1 JMS client
There are certain limitations and restrictions to bear in mind when deciding whether to use a JMS client developed for WAS v5.1 with a later version of the product.
We can use a JMS client application developed for WAS v5.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 WAS v5.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 v5.1 JMS application that uses JMS resources provided by the default messaging provider on a node on a later version. The v5.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 v5.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 WAS v5.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 v5.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 v5.1 JMS clients are 12 characters of type "char", we 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 we 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 WAS v5.1, is supported to enable connection to later versions. However, you should consider migrating your v5.1 JMS applications that use ASF to use JCA.
- Changes to writing and reading messages under syncpoint scope. A JMS application developed for WAS v5.1 uses the v5 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.
Client access to JMS resources