JMS backed by Websphere MQ

This is a learning experience about a JMS queue backed by Websphere MQ. My initial understanding was that a message published on the MQ queue wouldn't invoke the onMessage method of a listener/MDB. The notion sounded logical as the Java/JMS equivalent of the message exposed by the MQ JMS is of type com.ibm.mq.JMSBytesMessage and the onMessage expects the argument to be of type javax.jms.Message. Yesterday, we were able to publish a message on MQ and get an MDB listen to the messages. The details follow...

Before getting into the nitty-gritty, some backdrop on the context - our requirement was to process messages put on the MQ "asynchronously". Our knowledge of MQ being naive, the task motivated us and we explored the MQI(java interface for MQ) and played with it by developing some sample code. This led to the roll out of a design using the MQI and the quartz scheduler. I named it the "Pull Approach". A quartz job would poll the MQ at a defined time intervals and retrieve any messages in the MQ queue. Developed the code for the Pull approach and gave a demo of it.

Intrigued by the challenge and exploring more, came up with a second design that would use the inbuilt features of the MQ. A trigger is invoked on publishing a message. The trigger "translates" the message to JMS compatible message and publishes the message on a Topic. This design was baptized as "Push Approach" as the MQ server was pushing the messages. A document has been prepared with both the approaches and with crisp state diagrams made using Rational Rose and circulated it across. There was an inherent flaw in the Push approach, it didn't give implicit support for transactions. There were mixed opinions amongst the folklore about the the approaches with offhsore favoring Pull and onsite for Push.

With adrenalin still gushing, we got more adventurous and explored the JMSAdmin of the MQ. We have been playing around with that for a while but couldnot hit the bush.We decided to give try it afresh from scratch. So, created a context in the JMSAdmin, bound the connection factory and queue to the JNDI, used the same bindings in the JMS configuration on Websphere App server. The prototype was ready for testing. And to our surprise, when we pubslished a message on the MQ, it did invoke the MDB, though there was a ClassCastException for com.ibm.jms.JMSBytesMEssage. The cast exception could be resolved by reading out the bytes out of the JMSBytesMessage and copying them onto the JMS TextMessage.

This was an interesting development, indeed. Although, the earlier two approaches would be promptly decommissioned in favor of the third approach, we are happy that we were able to suggest a robust design that leverages the inbuilt features of the product. The learning curve has taken off. The documentation and the articles found on the IBM developer works site didn't help us much and most of the examples appeared to ratify our initial understanding. Well, being li'l adventurous and thinking outta box does help sometimes. There will a sequel to this blog entry soon with gory technical details.

*** UPDATE ***
There is an article on IBM site that explains in detail about configuring Weblogic JMS for Websphere MQ. Read the article here. I wish the article would have been published earlier that would have saved a few days of my tussle .