Linda's Open Message Queue Blog

what is MQ

I start off every entry restating that I am a poor blogger at best and I have great plans to get better. This entry is no different.

Still, its 4:00 am and I have two more hours to kill until I go to work, so this is a good time to actually make another entry. Last night, I had dreams of blogging and content fill my head, invading my dreams and leaving me here typing. These thoughts were triggered after a meeting with an open source evangelist-ish person, who reminded me that if I work on a good product (which in my mind I do) that I need to write about it and inform others why its important.

So where do I start? I could write about how I spent yesterday - but that would bore me - a day spent in meetings doing what next planning (although once we know what next is - I might). I could write about the inner workings of the product (but that requires brain power which is noticeably lacking at this moment) Since I'm operating on too little sleep, I'll start with the simple stuff and talk about what is MQ.

Open Message Queue is the open source version of the Sun Java System Message Queue. Now, I realize that that sentence I just wrote was not terribly useful, so a little better is that it is a type of Message Orientated Middleware. Making your head hurt yet, a more accurate version is that it is a product that implements the JMS specification. (still no clue ?)

Its asynchronous messaging, which means that the sending process doesn't have to wait until the receiving process handles the data before it continues processing (unlike something like RMI). Additionally, the content of the data doesn't have to be defined up front (although obviously the receiver needs to know what to do with it when it arrives).

When I try to describe what I work on to my friends, I tell them I work in middleware which immediately triggers yawns. Its actually more interesting and useful than it appears to be based on that description. MQ is really plumbing, an infrastructure which allows you to connect two disparate applications together through a messaging layer. You send a message (which can be a text message, a java object or several other constructs) through the api and it gets placed on a destination awaiting deliver to another project. At some point, that other project retrieves the data and begins to process it. It allows you to disconnect the timing of when the messages are processed from each other. For example, you may take a reservation order and want to actually process it at a later point. One application sends the message when the customer places the order, another later retrieves it and continues the processing.

JMS is also the messaging layer used with J2EE servers (and specifically open Message Queue is used in glassfish). If you are using MessageDrivenBeans to connect your applications in glassfish, its probably running on MQ.

Why not write your own

Well, obviously someone could. On the surface it doesn't sound very hard - you write a tcp socket that connects the applications. But the JMS api provides reliability guarantees that are difficult to achieve with a simple server. We promise that a message that you send will remain in the system until it is picked up by the other application (storing it if necessary) and promise that the messages will be delivered in order. We support transactions. We also take out the complication of determining who gets the message and when it is removed. In general, unless you have a lot of time for development on your hands, you probably don't want to do all the work yourself. Well, I know that if I didn't work on it for a living, I wouldn't want to write it - too much work. Many (many, many) man years went into making sure that it functions seamlessly.

So why use MQ specifically

That's always a hard question, my first answer is of course, that we are better, which is just a flippant response (I doubt that there is an engineer on any messaging product who doesn't feel that their implementation is on par or superior to the competition. Its why we became software nerds in the first place - to build software we are proud of). A less biased answer is that the product has a history, making it more stable than most (I'd like to think all, but thats no doubt over reaching) of the open source competition. It may not have all of the really cool features but it should run out of the box in anyone's environment.

How do I use JMS

Well, the real place to start is by reading the JMS specification. That where I started many years go when my second level manager at the time came into my office and said "Congratulations, you are now a Message Orientated Messaging person" (no, I didn't know from birth that its what I wanted to do). Still I'm sure a HelloWorld example would be much better. However, its almost morning so thats a topic for another day (maybe tomorrow). For now, I'll just give a quick overview of the two domains (messaging types) supported by the JMS api. They are Topics and Queues.

Topics are destinations (repositories for messages) that are publish-subscribe (one to many messaging). This means that an application (producer or specificaly Publisher) sends out a single message and multiple applications (called Consumers or in this case Subscribers) get the same message. The message hangs on the system until it is delivered to everyone. A good example of a place to use this would be a stock quote which should go to multiple people.

Queues are destinations that are point-to-point (one-to-one). This means that one message goes to only one interested party. For example, in the reservation example listed about, there may be multiple applications processing orders, if an order comes in it should be delivered to only one of the order processors (or you would get multiple reservations).

My alarm just went off, notifying me that a new day has begun. Its time to stop this entry and get moving. I'll try to keep my blogging promise and do a hello world example next.

Posted at 05:40AM Oct 17, 2007 by lindaschneider in Sun  |  Comments[12]