Can anybody let me know about know about the pros/cons of
MQSeries Vs. Message Beans for achieving messaging between two applications.
Right now we are not using EJBs and want to have messaging between aplications,
which arch. to be chosen.
Any suggestion is highly appriciable.
Just to be clear, MQSeries is just the communications mechanism between the publisher of information and the consumer(s) of information. It sounds like your question is do you write an MDB to act as that consumer or do you write a custom server-type application that uses JMS to receive messages in a mechanism similar to how a web server receives and handles TCP/IP requests on port 80.
If that's the case, then I would recommend using MDBs. Generally, anyone on my team has to justify the use of EJBs, but with MDBs, it's usually easy. Let the container manage the availability and scalability of the MDBs. If you write your own server-type app, then you need to worry about monitoring the app, scaling the app, thread synchronization, security and transactions (if that's an issue).
If your question is about JMS versus the MQSeries Java API, we generally use JMS. We haven't run into a condition where we've had to use the MQSeries Java API and we do a lot of PtoP and Pub-Sub stuff both internal and with external partners.
> Can anybody let me know about know about the pros/cons of
> MQSeries Vs. Message Beans for achieving messaging between two applications.
> Right now we are not using EJBs and want to have messaging between aplications,
> which arch. to be chosen.
> Any suggestion is highly appriciable.
MQ Series is a messaging system that provides many features for connecting applications. There are tons of web sites that describe how MQ works.
Message beans are simply EJBs that provide the construct needed to process an incoming message. JMS is the java messaging standard that describes how java applications can communicate using messages which are usually XML based. (check out a java website for more information). IBM (and other vendors) provide a JMS implementation based on MQ Series.
The first thing you need to do is to work out how your applications need to connect (synchronous, asynchronous, high performance, low performance, volumes and types of data, message routing mechanisms etc.etc) then choose an appropriate messaging product.
Then you need to work out how you connect applications. Using EJBs is an appropriate approach and you could have a MQ Series message trigger a Message Bean through the use of the MQ Series JMS implementation. Alternatively, you could have a Stateless Session bean send a message via JMS to the MQ Series environment that connects the two applications.
One of the core reasons for Oragnizations to choose MQSeries from IBM is becuase of MQSI. You can elaborate on Message workflow and Formating through this tool and is very efficient and easy to manage. I've seen this being extensively used in the Insurance industry from formatting and processing Messages that need to co exist in their corporate enterprise filled with Legacy systems.
At the end of the day, if JMS/MDB is what you are after then like the others pointed out, weigh out the other implementations. MQ Series does not come cheap. Ofcourse if you happen to be an IBM shop and happen to use WebSphere , you sort of get it for free ;)