Third party JMS in J2EE Server

[Krishna Raj]

First, I would like to confirm that MQ and other third party JMSproviders can be accessed from J2EE servers like weblogic 7. and websphere 5. ?
I do see these in the resources, but have not been able to connect the two.
Ultimately I am looking to accessing messages in MQ from an MDB as well as a standalone java application.
I know the MDB can work with the J2EE/JMS but can it get msgs from MQ ?
In a standalone app, how do I access the JNDI and hence the resources since the resources are stored as JNDI objects ?
Thank you all

[Kyle Brown]

MQ will certainly work perfectly well with WebSphere 5. The procedure for installing and configuring this is covered in the InfoCenter.
Kyle

[Nitzan Levi]

hi,
1. MQ is implementing the JMS standart so when you say that MDB can work with JMS it means that it can get meassages from MQ (if u uses it for you JMS implementation).the all idea of JMS that it hides the MQ or other MOM provider's API .
2. there is no problem for a standalone java(and other) application to send messages to the MDB. you can do it in two ways :
1. the java application will take the JMS administered objects(connection factory , queue,topics) from the jndi and work exactly the same as it would inside the container !!
2.the java application can create those objects with the standart JMS api with no JNDI use!
the best way is the first way because that way you can change the administered objects parameters in one place !

[Krishna Raj]

Thanks for your info. I have tried MQ in WAS5 but it does not seem to communicate.
Kyle, have you actually set up this in your machine. If so I have a few setup questions.
Nitzan: JMS being just an API, MDB will work with it. The problem is accessing the server in this case WAS. MDB is built to work with WASQ which I learnt is different from MQ as MQ is treated as a third party queue manager. In the case of jndi access, I was wondering if any of you may have the params for jndi access like the context factory, provider etc. I tried the one that comes with samples but again doesnt seem to be working for me from a standalone app.

[Kyle Brown]

Yes, I have set it up before (during the beta program) but I do not have it currently set up on my machine (I'm using embedded messaging at the moment).
Kyle

[Kyle Brown]

Originally posted by Krishna Raj:
Thanks for your info. I have tried MQ in WAS5 but it does not seem to communicate.
Kyle, have you actually set up this in your machine. If so I have a few setup questions.
Nitzan: JMS being just an API, MDB will work with it. The problem is accessing the server in this case WAS. MDB is built to work with WASQ which I learnt is different from MQ as MQ is treated as a third party queue manager. In the case of jndi access, I was wondering if any of you may have the params for jndi access like the context factory, provider etc. I tried the one that comes with samples but again doesnt seem to be working for me from a standalone app.

What do you mean WASQ? There is no IBM product by that name. MDB's will work on NATIVE WebSphere MQ Queues. In fact, WebSphere embedded messaging is just a stripped-down version of WebSphere MQ.
Kyle

[Krishna Raj]

Kyle, WASQ is WAS queue as you found out. The product may have shared code base in the past but are completely different (This is apparant what you put on WAS is not visible from WMQ !) There has to be some sort of a config to link messages put into WAS queus to be visible in MQ and vise versa. WAS queus are more than stripped down versions of MQ. They actually are designed to work within J2EE and hence have lot of context info available from within WAS as against MQ that has to follow a JNI route. making it more complex.

[Kyle Brown]

Originally posted by Krishna Raj:
Kyle, WASQ is WAS queue as you found out. The product may have shared code base in the past but are completely different (This is apparant what you put on WAS is not visible from WMQ !) There has to be some sort of a config to link messages put into WAS queus to be visible in MQ and vise versa. WAS queus are more than stripped down versions of MQ. They actually are designed to work within J2EE and hence have lot of context info available from within WAS as against MQ that has to follow a JNI route. making it more complex.

Krishna, the embedded messaging in WAS is a stripped down version of MQ 5.3 and MQ Event Broker. Trust me on this one. All that we did is to remove many of the management pieces of MQ and forbid clustering. It's not "a shared code base in the past". It's a shared code base NOW. The development that we did to make the messaging work within the J2EE environment has been placed in the base MQ 5.3 product as well -- which is why you can use either.
MQ has for several versions supported two options on clients -- a "bound" version that uses JNI and a "thin" version that uses TCP/IP. What we did in WAS 5.0 is to make the "thin" version capable of working with XA -- which has been moved into MQ 5.3 also.
Yes, there is configuration required to let a "regular" MQ queue see information placed in a queue in embedded messaging. But that is more due to the complexities of managing multiple MQ queue managers than anything...
I'll assure you that my sources are accurate -- this information comes from the developers in IBM Hursley labs...
Kyle
------------------------------------
Kyle Brown
Senior Technical Staff Member
IBM Software Services for WebSphere