Hi, I am working on Jboss Application server. I have to use a message queueing service to have the sureity that the data is sent to the database and transaction is completed properly . I have been asked to implement the MQSeries MEssaging service for the same . But what i have in mind is that when a application server has its own messaging service e.g JBOSSMQ or Advanced Queueing in case of Oracle 9i , then why do we need to make use of an external messaging service ? I need to know the stability differences between the 2 . MQSeries makes use of the JMS api and the JbossMQ also makes use of the same , then why use MQSeries when the functionality can be got from the Messaging service provided with the application server ? I am really confused and need someone to guide me the rite way from design point of view . i.e the absic difference between architectures of the differnt messaging services .Hope someone can help.. Thanx, Aanchal.
MQ Series (now known as WebSphere MQ) does messaging in a larger context than just JMS. It allows programs in C/C++, COBOL, legacy apps running on CICS on the mainframe, and other diverse environments all to talk together. It's also geared to talk between multiple diverse platforms and to perform with industrial-strength performance and robustness.
Sometimes the only way things ever got fixed is because people became uncomfortable.
I have seen several clients with the same type of questions, although most are dealing with MSMQ or WebLogic instead of JBoss(I have no exposure there). Oftentimes it comes down to the dollars of IBM's WSMQ licensing versus using the MQ service native to the app server they are running on. Ultimately, if you have a JBoss server, with JBossMQ, you should be able to talk to WSMQ with minimal if any issues. For MSMQ to talk to WSMQ, you need a bridge that can be had from MicrSoft for a few hundred dollars. JBoss should have specs available for communications with WSMQ, including any software bridge that may be required. If not, check the WebSphere MQSeries site for details. For pure consistency, WSMQ to WSMQ is a breeze to get it up and running, and being able to use the same resources to manage the messaging systems across multiple platforms can be very attractive, especially to smaller to mid-sized companies. The majority of messaging services are able to communicate to the others with a minimum of heartburn. The protocols are virtually identical, and the vendors are very aware that their clients use the same type of messaging applications across multiple platforms. They have heard the message that intercommunication between platforms is paramount. Any vendor who wants to be strictly proprietary will find expansion difficult when there are vendors who are willing to allow integration on multiple levels.All that being said, there may be a reason why WSMQ was chosen over the JBossMQ, that would be a question for the project owner. Kat >^..^<
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop