Jms Messaging Bridge

What is a jms Bridge?

A messaging bridge consists of two destinations that are being bridged: a Source destination that the bridge reads messages from and a Target destination where the bridge sends the messages that it receives from the source destination. Many of the jms provider provide the jms bridge capabilty. However it is also easy to build a custom JMSbridge using JMSJCA

Building jms bridge using java or Composite Application

1. Using standalone java application

JMSJCA support connecting to various JMS Providers like Sun Java Message Queue, JBossMQ, Websphere Message Queue or MQSeries, Weblogic JMS Server, JMS Grid, STCMS. So if one want to build bridge which does not require support for XA transaction. One can easily use the JMSJCA as library  for the purpose as it provide a unified interface for accessing the JMS Providers. The diagram below shows the flow of message.


2. Using javaee container

However one may like to make the bridge more reliable. and like to treat the receiving of messages from the source and delivering the same to the target as atomic, i.e want the bridge to support XA transaction, then it will ideal to use javaee container for that purpose, We will show a sample piece of pseudo code which use MDB to build a bridge.

More Info on How to create a MDB and jms Message Producer using JMSJCA in glassfish is available here

Lets say that the requirement is to build a bridge for Sun-Java-Message-Queue to Websphere-Message-Queue , One can use the following logic in the MDB

public void onMessage(Message sunJavaMessage){

     //sunJavaMessage is the received message from Sun Java MQ ,

  1.  Create a producer, for say Websphere Message Queue(WMQ)

  2.  Transform message Header, Properties, Body from  SunJava-MQ to WMQ message

  3.  Send the message


Note that the step 2 , is the crucial step which one need to implement. While implementing the Message Conventer one has to take care of the following

  • iterate over jms Message Properties, copy from source to destination

  • handle vender specific properties, i.e properties starting with JMS_

  • copy message Body, note Text, Map, Byte,Object, Stream Message needs to handled seperately

  • copy relevant jms headers (like jms type, correlationId, timestamp, priority, expiration etc)

Some of the advantages of using a javaee container along with JMSJCA are

  • The ejb(mdb) container takes care of the reliable delivery

  • One can have a scalable messaging bridge

  • Resource Management, Connection pooling , MDB Instance pooling is done by the container

  • In case of a crash, the appServer/ejb container takes care of recovery

  • leverage the JMSJCA monitoring capabilty

  • redelivery handling

  • JMSJCA message wrapping

3. Building jms bridge using Composite Application

Idea is, Can we build a jms messaging bridge without any java-code , One can create a composite application which uses jmsbc-->bpel-->jmsbc . Note One limitation of building a bridge using jmsbc is that not all the jms message type is supported by jmsbc, Only supported Message are TextMessage, BytesMessage and MapMessage. Also if one require to convert all the message Header , Properties from source to destination , then one has to create a more involved wsdl. More info on creating composite applications using  JMSBC and BPEL. The diagram below shows the flow of message.

step a) Create a CompositeApp using jmsbc-->bpel-->jmsbc 


step b) Use the bpel mapper to map message properties , header and body

Use the bpel mapper to copy the message headers, properties and body, Note this takes care of only part of the message conversation, However one can always specify the message parts which maps to other message properties, see the link for more info

More info on Messaging Bridge and their JMS provider

  1. Weblogic Messaging Bridge

  2. Sun Java Message Queue

  3. Jboss Messaging Bridge

  4. ActiveMQ bridge

  5. SoniqMQ Bridge


Hi Sujit!

Very interesting post!

I'm wondering why it is necessary to copy the message to a new message (copy the payload and headers). From what I remember from the JMS Spec, a JMS provider must be able to accept messages that came from a different implementation (see section 3.12 if I remember correctly).

So I think you can write
onMessage(Message m) {
... even if m came from JMS implementation 1, and producer is of JMS implementation 2.


Posted by Frank Kieviet on April 30, 2009 at 04:49 AM PDT #

Hi Frank,
Very good point, Yes this is the ideal scenario, for most vendors this should work, however one layer of indirection just gives some extra capabilty , like if one require to customize the JMSReplyTo or cleanup vendor specific Message properties, like message properties starting with JMS_Vendor\*


Posted by Sujit Biswas on April 30, 2009 at 09:26 AM PDT #

Thanks for the good and complete instructions. It was what I had in mind as well and could use your explanation to implement it :)

This is also one other thing besides the point from Frank:
The User Properties can not be copied in this simple manner. With both JavaCAPS6.2 and GF_ESB2.1 I get the following error:
BPCOR-6174: Selection Failure occurred in BPEL

If you have any idea to copy all the User Properties I would be very happy with receiving that idea.

Posted by Remold Krol on January 20, 2010 at 03:43 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed



« July 2016