4 Replies Latest reply on Jun 7, 2007 5:29 AM by Thomas Roka-Aardal

    Bridging JMS providers

    Thomas Roka-Aardal Newbie

      The new Bridge is very handy when integrating with different providers, but when that works there is a "small" added feature that could give a lot of value to developers: correlating messages on different providers. It would be very interesting to see if a simple and elegant solution such as the Bridge could be explored further to aid this common scenario. Here are some thoughts...

      The specification clearly states that message id's don't need to be unique across providers, this always cuts down to creating custom solutions for replying to external JMS messages. ReplyTo indicates specifying a Destination, which is not relevant when going across providers.

      Directly after sending a message the provider's jms message id is available in the message object on the client side. If the Bridge were to make that id available somehow it would be trivial to map id's between providers. Let's say there are two bridge instances set up:

      1) Listens to local queue "outbound" and sends to remote provider "in"
      2) Listens to remote provider "out" and sends to local queue "inbound"

      If the message id obtained from sending at "1" were available somehow, we could either allow "2" to map the message (most powerful) or add a property of kind, allowing other code (perhaps the listener on "inbound") to understand the mapping.

      Any thoughts?

        • 1. Re: Bridging JMS providers
          Tim Fox Master

          Hello Thomas-

          I'm not sure I fully understand what you are suggesting - are you suggesting doing some kind of remote replyTo - where you can specify a replyToDestination that still works after a message is bridged?

          Can you explain in more detail.

          BTW Have you tried the bridge?


          • 2. Re: Bridging JMS providers
            Thomas Roka-Aardal Newbie

            Hi Tim.

            In brief: yes, that is what I am thinking, a remote replyto that would work across providers after bridging.

            I've tried the bridge, and it is very handy. However, what I am thinking of is analogous to what you are suggesting: a remote replyto, but since replyto (which is a destination) does not apply across providers that does not seem to be a possible way to go. I'm thinking this scenario:

            (sorry for long post)

            1) A JMS client sends a message to a queue on JBossMessaging (messageid: 1) expecting a response (on a replyto temp destination)

            2) A Bridge configuration picks up message 1 and sends it to a remote provider, expecting a reply (the remote message gets a provider-specific messageid, lets say "A" to differentiate them). Here we cannot use the same replyto destination given in 1) since we are going to another provider.

            3) A remote JMS client (not able to talk to JBM) receives the message (A) and replies to it to a (for him) local queue with a new message (B), using "A" as the correlation id (these legacy clients typically don't obey a replyto header anyway, they just send a response where they usually put it. They do, however, use the correlationid)

            4) A Bridge configuration picks up message B and puts it on the replyto destination given by the original JMS client

            This scenario is quite common and is often (in the proprietary world) handled by bridging products where you configure how to map correlation/replies between providers. Now that JBM has a bridge, this kind of functionality could perhaps be added to it, making it even more powerful.

            If a remote client respected the replyto destination given in the header and the remote provider supports temp destinations, the "outgoing" Bridge could see that there is a destination in the original request, create a remote temp queue and send the message using a replyto with the new (remote) temp queue. However, that would require that the "receiving" Bridge configuration would have to be able to listen to dynamically created remote queues and still have no understanding of where to put the received messages. If two bridge configurations were to be "aware" of each other (lets say a bridge xml could contain BOTH an in- and outbound route) they could also share this temporary queueing, AND know the mapping of messageid's since they get the remote provider's messageid after send().

            If we cannot use temp destinations, the Bridge (if configured in in/out pairs) could still map correlationid's, which would be extremely powerful.

            • 3. Re: Bridging JMS providers
              Tim Fox Master

              This is an interesting discussion, I don't think it would be too hard to get something like this to work.

              Perhaps you should continue it on the design forum.