Using a foreign WLS JMS queue (no bridge)

Question

          Hi,
          We have a configuration from which we communicate from WLS 7 to a foreign MQ via
          JMS. This works well and we have loaded the foreign MQ jms objects into WLS JNDI
          using a statup class (as the whitepaper available describes) and we look them
          up successfully.
          However, we now have a siutation where we briefly need to switch our application
          to point to a WLS JMS queue on another remote WLS server. Is there an easy way
          to load foreign (maybe remote would be a better word in this case) WLS JMS QCF's
          and destinations into my local WLS JNDI so that I can treat them the same way
          as my MQ objects?
          I can't seem to find any information on how to do this as all information seems
          to point towards the messaging bridge (we can't use this as the bridge changes
          the message JMSMessageID and screws our correlation mechanism up).
          I know we could just look the foreign objects up by using the JNDI environment
          of the remote WLS machine but this would mean changing code and this I can't to
          do (as all our code uses the local default WLS JNDI).
          Any ideas would be gratefully received.
          Cheers,
          Jay.
          

Answer 1

WLS JMS and MQ JMS handle their JNDI objects a little differently, so I can
          see how this can be confusing. An MQ JMS "ConnectionFactory" or
          "Destination" object is like a little configuration file that tells you
          where the queue manager or queue is, so you can serialize it and look it up
          later and use it to find the queue manager.
          A WLS JMS ConnectionFactory or Destination object is a reference to an
          object on a running server. So, you connect to the server and look them up,
          and then you can use it for messaging. You don't have to store these objects
          in a separate place, like MQ makes you do. But it means that the WLS JNDI
          objects have to be looked up from a running server, and if the server
          restarts, you have to look them up again.
          Doing what you're asking is definitely trickier in 7.0. One thing you could
          do is, again using a servlet or an EJB, connect to the remote JMS cluster
          and look up the objects at the time you want to make the switch. (If the
          remote cluster is down, you'll have to retry from time to time.) If the
          remote cluster is down, you won't be able to look up those objects, but then
          again, if it were down you wouldn't be able to send messages there anyway.
          Using 8.1 would be less complicated, but this method should also work.
          greg
          "Jay Green" <[email protected]> wrote in message
          news:[email protected]...
          >
          > Thanks Greg. When I was searching the BEA website I read about the
          facility in
          > 8.1. Unfortunatley, as you point out, it doesn't help me much with WLS
          7.0.
          >
          > My first thought was to copy my exisiting MQ startup class but I couldn't
          work
          > out how to do this for the remote WLS jms objects as the standard jms
          classes
          > (for QCF etc) don't have methods that allow me to define the foreign WLS
          jms
          > host IP address etc. I checked the WLS 7 API and the jms package didn't
          seem
          > to offer anything to help me do this (as IBM do for MQ). Any ideas?
          >
          > Apologies if I'm being a bit slow here!
          >
          > "Greg Brail" <[email protected]> wrote:
          > >WLS 8.1 includes a feature called "Foreign JMS Providers" that lets you
          > >configure (using the console or config.xml) a link between a JMS JNDI
          > >object
          > >in your WLS servers' tree, and a JNDI object in another provider -- which
          > >could be WLS JMS, or a foreign vendor.
          > >
          > >Using this feature, your application could just look up the local JNDI
          > >objects in the local WLS tree, and then the server in turn performs the
          > >lookup from the actual JNDI provider using the parameters you put in
          > >the
          > >console (or config.xml). So, when you make a change in the console, new
          > >JNDI
          > >lookups will go to the new place.
          > >
          > >Unfortunately, this doesn't help you with 7.0. You could always
          > >programmitically update the local JNDI tree the way you're doing in your
          > >startup class, but instead do it from a servlet or an EJB.
          > >
          > > greg
          > >
          > >"Jay Green" <[email protected]> wrote in message
          > >news:[email protected]...
          > >>
          > >> Hi,
          > >>
          > >> We have a configuration from which we communicate from WLS 7 to a
          foreign
          > >MQ via
          > >> JMS. This works well and we have loaded the foreign MQ jms objects
          > >into
          > >WLS JNDI
          > >> using a statup class (as the whitepaper available describes) and we
          > >look
          > >them
          > >> up successfully.
          > >>
          > >> However, we now have a siutation where we briefly need to switch our
          > >application
          > >> to point to a WLS JMS queue on another remote WLS server. Is there
          > >an easy
          > >way
          > >> to load foreign (maybe remote would be a better word in this case)
          > >WLS JMS
          > >QCF's
          > >> and destinations into my local WLS JNDI so that I can treat them the
          > >same
          > >way
          > >> as my MQ objects?
          > >> I can't seem to find any information on how to do this as all
          information
          > >seems
          > >> to point towards the messaging bridge (we can't use this as the bridge
          > >changes
          > >> the message JMSMessageID and screws our correlation mechanism up).
          > >>
          > >> I know we could just look the foreign objects up by using the JNDI
          > >environment
          > >> of the remote WLS machine but this would mean changing code and this
          > >I
          > >can't to
          > >> do (as all our code uses the local default WLS JNDI).
          > >>
          > >> Any ideas would be gratefully received.
          > >>
          > >> Cheers,
          > >>
          > >> Jay.
          > >
          > >
          >