|
Overview
The JMS Bridge Extension Swiftlet provides bridging functionality between SwiftMQ and any foreign JMS 1.0.2 compliant systems. The Swiftlet installation may be executed within any router of a router network. The Swiftlet supports the bridging to any number of different foreign JMS systems simultaneously. Within a swiftlet, one can, for example, define bridges to different Weblogic JMS and MQSeries JMS servers simultaneously and so implement a central "JMS Exchange" by a SwiftMQ router.

On breakdown or unavailability of a foreign JMS server, an automatic reconnect in a configurable retry interval takes place by the Swiftlet. Undelivered messages are redelivered.
The bridging between SwiftMQ and a foreign JMS server may be defined to queue/queue, topic/topic, queue/topic and topic/queue.
During the message transfer of a bridge, an automatic conversion within the message implementation of the respective target system takes place. The persistence manner of the messages may retain unchanged or it may be defined that messages are always transferred declared as persistent or non persistent. This, independent of the adjusted persistence mode of the source message.
Technical Implementation
The bridging to foreign JMS servers is done on the basis of the JMS API, which means, the Extension Swiftlet operates towards the foreign JMS server as a normal JMS client.
Any number of foreign JMS servers may be defined within a Swiftlet. These are bridged in parallel and independently. Various properties are defined per foreign JMS server, which are necessary for the connection setup. These are username/password concerning the creation of Queue/TopicConnections, a retry interval whether the foreign JMS server is not available as well as the class name of an ObjectFactory and the name of a configuration file.
The ObjectFactory has a particular importance as it is used by the Swiftlet to produce the required administered objects, in other words connection factories and destinations. The indicated configuration file contains generic properties, which are used exclusively by the specified ObjectFactory. As the J2EE standard states that JMS administered objects are read out of a JNDI repository, this distribution delivers a JNDIObjectFactory. The corresponding configuration file contains the respective JNDI properties like the provider URL etc., required to create the InitalContext. With this JNDIObjectFactory it should be possible to bridge most of the foreign JMS systems.
Unfortunately, also such JMS systems exist, in which one need to use their proprietary connection factories. In this case, the ObjectFactory is implemented by yourself and their class name is to be specified at the server configuration. You find the javadoc documentation for the ObjectFactory here.
Any number of JMS bridgings can be defined on any within the Swiftlet defined server. Every bridging configuration contains the bridging direction (local-to-remote or remote-to-local), name and type (queue/topic) of the local destination, the name of the remote factory (Queue/TopicConnectionFactory), name and type (queue/topic) of the remote destination as well as the transfer persistence. The latter signifies the message persistence to the target. Here, you may choose between "always persistent", "always non persistent" or "as set within the message". Concerning the local-to-remote bridgings, of which the source is a queue, it is to be taken into account that these need to exist on the local router because no QueueReceiver can be created for a remote queue.
Thereafter, the bridging starts between the defined destinations. If a fault should occur, the entire defined server is marked as invalid, all connections are closed and it is tried within the retry interval to re-establish the bridges.
|
|