High Quality JMS Messaging.

Example 2

This example shows how to create bridges between SwiftMQ and WebsphereMQ 5.3.

The first bridge is of type "local to remote" and connects the SwiftMQ queue "toMQ@router1" with WebsphereMQ's queue "queue". If a message is send to "toMQ@router1", it will be transfered to "queue" on the WebsphereMQ server.

The second bridge is of type "remote to local" and connects WebsphereMQ's queue "queue" with SwiftMQ's queue "fromMQ@router1". If a message is send to "queue", it will be transfered to "fromMQ@router1" on the SwiftMQ router.

Therefore, if a message is send to "toMQ@router1", it will be transfered to "queue" on the WebsphereMQ server and immediately transfered back to "fromMQ@router1" on the SwiftMQ router. The following pictures illustrates it:

Preparation

On the WebsphereMQ server:

To create the JNDI bindings, you have first to edit JMSAdmin.config which is located in WebsphereMQ's Java/bin directory. Set the following properties (we assume that WebsphereMQ's installation directory is "d:/appserver/mq5.3"):

      INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
      PROVIDER_URL=file:/d:/appserver/mq5.3/Java/bin

Then start JMSAdmin.bat from WebsphereMQ's Java/bin directory and issue the following commands:

      DEF QCF(QCF)
      DEF Q(queue) QUEUE(queue)

This will create a QueueConnectionFactory with name "QCF" and a JNDI binding for the queue "queue" with JNDI name "queue".

On the SwiftMQ router (we assume the routername is "router1"):

Step 1: Enable Tracing

It is highly recommended to enable tracing while you define your bridges. To do so, go to the Trace Swiftlet, change the filename of the first predicate of the trace space "swiftlet" to "console" and enable the trace space:

Step 2: Define a Server

Go to the JMS Bridge Extension Swiftlet, click on node "Server" and do a right click. Choose "Create a new Entity". This displays a frame to create a new Server. Just give it a name, e.g. "webspheremq", leave it disabled (we will enable it later) and hit "Create":

Step 3: Define JNDI Properties

Expand the "Object Factory" node of the newly created bridge, select "Object Factory Properties":

Do a right click and select "Show Entity Table". A frame is displayed where you can add JNDI properties which is used from the bridge to create a JNDI InitialContext for Weblogic:

Use the "Add" button on the top left corner to add a JNDI property "java.naming.factory.initial" and specify the "com.sun.jndi.fscontext.RefFSContextFactory" factory:

Add another JNDI property with the "java.naming.provider.url" and specify the provider URL "file:/d:/appserver/mq5.3/Java/bin". This points to a file named ".bindings" where the JNDI entries are stored (you can store this file wherever you want but you have to change the provider URL accordingly):

The frame now lists all JNDI properties you've added; you can close it:

Step 4: Define a bridge from SwiftMQ to WebsphereMQ

Next step is to define a bridge between the local SwiftMQ queue "toMQ@router1" and the remote WebsphereMQ queue "queue". Select the node "JMS Bridgings", right click and select "Create a new Entity":

A frame is displayed to enter the bridging attributes:

The following table explains the above data:

Field Description
Name "toMQ" is just a name of this bridge.
Bridging Direction Goes from here to Weblogic, so it is "local_to_remote".
Durable Name n/a
Local Destination Name Is the local queue name "toMQ@router1".
Local Destination Type Is "queue".
Remote Factory Name Is the name of the remote connection factory. You've defined "QCF" in WebsphereMQ and this is what you specify here.
Remote Destination Name Is the remote queue name "queue".
Remote Destination Type Is "queue".
Transfer Persistence Define "as_source" to leave the persistence setting of a message untouched. You could also define "persistent" or "non_persistent" to change the persistence setting of messages on the fly.

Pushing the "Create" button creates the bridge.

Step 5: Define a bridge from WebsphereMQ to SwiftMQ

Next step is to define a bridge between the remote WebsphereMQ queue "queue" and the local SwiftMQ queue "fromMQ@router1". Repeat the above procedure to create a new entity:

The following table explains the above data:

Field Description
Name "fromMQ" is just a name of this bridge.
Bridging Direction Goes from WebsphereMQ to here, so it is "remote_to_local".
Durable Name n/a (only required if you connect to a durable subscriber)
Local Destination Name Is the local queue name "fromMQ@router1".
Local Destination Type Is "queue".
Remote Factory Name Is the name of the remote connection factory. You've defined "QCF" in WebsphereMQ and this is what you specify here.
Remote Destination Name Is the remote queue name "queue".
Remote Destination Type Is "queue".
Transfer Persistence Define "as_source" to leave the persistence setting of a message untouched. You could also define "persistent" or "non_persistent" to change the persistence setting of messages on the fly.

Pushing the "Create" button creates the bridge.

Step 6: Enable the Server

Everything is defined. Now you are ready to enable the server with its bridgings. To do so, double click the "Enabled" attribute of the server:

The server is now activated. Since you've enabled tracing, you should see it in your console window:

      2005-01-26 10:02:10.765/swiftlet/xt$bridge/webspheremq/creating objectfactory
        'com.swiftmq.extension.bridge.JNDIObjectFactory'
      2005-01-26 10:02:10.765/swiftlet/xt$bridge/webspheremq/create bridgings ...
      2005-01-26 10:02:10.765/swiftlet/xt$bridge/webspheremq/create bridging 'fromMQ' ...
      2005-01-26 10:02:10.781/swiftlet/xt$bridge/webspheremq/created:
        [DestinationBridge, name=fromMQ, source=[RemoteQueueBridgeSource, queue=queue:///queue],
        sink=[LocalQueueBridgeSink, queue=fromMQ@router1]]
      2005-01-26 10:02:10.781/swiftlet/xt$bridge/webspheremq/create bridging 'toMQ' ...
      2005-01-26 10:02:10.781/swiftlet/xt$bridge/webspheremq/created:
        [DestinationBridge, name=toMQ, source=[LocalQueueBridgeSource, queue=toMQ@router1],
        sink=[RemoteQueueBridgeSink, queue=queue:///queue]]

An entry is shown below the "Usage" node as long as the server bridge is active.

Step 7: Send some Test Messages

Send some Messages to "toMQ@router1". You should see the transfer to/from WebsphereMQ and the messages you sent should finally arrive at "fromMQ@router1".

Step 8: Disable Tracing

If everything is ok, the tracing needs to be disabled because it will slow down your bridges a lot. Double click the "Enabled" attribute of the "Swiftlet" trace space:

Step 9: Save your Changes!

Finally and most important you should save your changes now:

The following XML is stored in the routerconfig.xml:

      <swiftlet name="xt$bridge">
        <servers>
          <server name="webspheremq" enabled="true">
            <bridgings>
              <bridging name="fromMQ"
                        direction="remote_to_local"
                        localname="fromMQ@router1"
                        remotefactoryname="QCF"
                        remotename="queue"
                        remotetype="queue"/>
              <bridging name="toMQ"
                        localname="toMQ@router1"
                        remotefactoryname="QCF"
                        remotename="queue"
                        remotetype="queue"/>
            </bridgings>
            <objectfactory>
              <properties>
                <property name="java.naming.factory.initial"
                          value="com.sun.jndi.fscontext.RefFSContextFactory"/>
                <property name="java.naming.provider.url"
                          value="file:/d:/appserver/mq5.3/Java/bin"/>
              </properties>
            </objectfactory>
          </server>
        </servers>
      </swiftlet>