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.


I did actually wonder what MQ is.

Now I have a much better concept of what it is.

Thanks for that.

Posted by noyb on October 17, 2007 at 11:23 AM BST #

Hello Linda,

I have been working on a migration project from another vendor to Glassfish. My experience with using OpenMQ via Glassfish:
1) Not having open mq source code consistent with what is in Glassfish v2 bits was really painful in debugging some problems with OpenMQ.
2) There are bugs in direct connection mode and every time I posted a problem in Glassfish forum, the response was use Local Broker, don't use Embedded Broker because there are issues with Direct Connection.
3) I was less than impressed with overall realiability of OpenMQ in Glassfish v2, more so when we were porting an existing working application from one vendor to Glassfish. MQ has been our biggest pain point and not having a source code consistent with binaries made my pain go up higher because I just could not step through to see what was going on.

I think overall some work needs to be done to make open mq reliable specially with embedded mode/direct connection in Glassfish.

My usage is in financial services/brokerage/trading world where queuing/messaging is used heavily and needless to say it has to be rock solid in this world.

Posted by Sanjay Dwivedi on October 17, 2007 at 03:41 PM BST #

I understand that having two different repositories for glassfish and MQ source bases can make life difficult. This is the side effect of the fact that the two products (while they work together) were developed independently and ship as standalone products. I doubt that the two will ever completely merge (although both will be at least using the same source code control system in the near future) although we are trying to improve it.

As far as the reliability of Direct Mode. Since its a new feature, I'm not surprised that its unstable. However, we actually don't have any specific defects filed against that part of the current (4.1 FCS) product. (obviously I'm not monitoring the right aliases/forums - which ones did you post to).

Can you tell me whats not working correctly so bugs can get filed/fixed ? It its easier to go over email, feel free to send it to the alias: imq-feedback@sun.com. That alias is monitored by the engineers working on the product.

Posted by Linda Schneider on October 17, 2007 at 04:06 PM BST #

Great blog! Frankly, you are a good blogger already :)

Shouldn't there be a dev/users@mq.dev.java.net mailing list?

Posted by Kedar Mhaswade on October 17, 2007 at 06:10 PM BST #

Yep - there are users/dev mailing lists. (users@mq.dev.java.net and dev@mq.dev.java.net). I should have mentioned them in my earlier comment but old habits die hard (the feedback alias has existed since MQ's 2.0 phase so mentioning it is just a bad habit). They are probably more appropriate for bugs and issues.

Posted by Linda Schneider on October 17, 2007 at 08:14 PM BST #

@Linda: Thanks for the writeup. I think Sanjay was referring to the users@glassfish.dev.java.net alias and the glassfish forum

@Sanjay: "There are bugs in direct connection mode and every time I posted a problem in Glassfish forum, the response was use Local Broker, don't use Embedded Broker because there are issues with Direct Connection."

Thanks for your comments.

The "Direct mode" was a new feature introduced in MQ 4.1 [and GF2/AS9.1] and is the default mode only in DAS. The Direct mode is represented as EMBEDDED in GlassFish's MQ integration mode and basically bypasses the networking stack for JMS operations and as indicated at http://docs.sun.com/app/docs/doc/819-3672/beaoc?a=view it is not supported in a cluster use.

The AS/MQ integration onepager has more details on this http://wiki.glassfish.java.net/attach/OnePagersOrFunctionalSpecs/as-mq-integration-gfv2.txt

Having said that, please raise Direct mode issues that you have faced in the GlassFish/OpenMQ issue tracker and help us fix/track these issues.

Cluster instances and standalone instances, on the other hand, are by default LOCAL and for clustered production setups, we recommend using LOCAL/BROKER based on your needs. See a discussion at http://docs.sun.com/app/docs/doc/819-3680/abfdn?a=view regarding deployment planning for your messaging needs.

Please use the glassfish/openmq user mailing lists for any other issues you might have


Posted by Sivakumar Thyagarajan on October 18, 2007 at 06:46 AM BST #


Thanks so much for taking the time to write this blog. I enjoyed reading it. I agree with Kedhar, you are all ready a great blogger. What sort of things will one find in openmessagequeue that are beyond the functionality of the JMS spec?


Posted by Tom Kincaid on October 19, 2007 at 01:55 PM BST #

Hi Tom ...

I'll write a longer answer to your question on a blog in the near (I don't know how near) future.

But the high points are that it provides:

\*clustering of servers for data availability
\*integrated SOAP / HTTP messaging
\*a C Client API
\* a JCA 1.5 compliant Resource Adapter
\*JMX support for both administration and monitoring
\*High Availability (HA) support
\*pluggable authentication

(there are also a whole bunch of minor features like supporting a dead message queue, and additional control for destinations that I'm leaving out)

In the near future (e.g. next week or so) we will be adding XA support to our C-API and integration with Tuxedo

Posted by Linda Schneider on October 19, 2007 at 05:39 PM BST #

Hi Linda,

I've used the MQ product for quite some time now (as iMQ, Sun ONE, etc.) and it's served me quite well.

I recently began utilizing the C API which is very clean, consistent and well documented, so I must give thanks to everybody involved for that.

However, do I need to make any special considerations when transferring string's back and forth? My understanding was that java.lang.String stores everything as UTF-16, so I was concerned that if I used a BytesMessage whose payload is a "stream of uninterpreted bytes" (as the spec states) which may contain the values of a good ole char\*, I may need to handle the UNICODE conversion manually (the same goes for a TextMessage I suppose). Does the C library handle everything I could possibly worry about for me? :-)

Again, thanks for a very nice product!


Posted by Troy Zimmerman on January 08, 2008 at 12:38 PM GMT #

i configured mysql with glassfish .my messages are storing successfully in mysql , but i want to add additional columns to my table and want to insert message properties into it .is it possible if yes how ?

Posted by Bhupinder on August 20, 2008 at 06:25 AM BST #

Thanks for this blog posts. I just now found it, but it went quite a ways to answer my questions and give me a reasonable overview of MQ.

Thank you!

Posted by runester on March 24, 2009 at 07:46 AM GMT #

Post a Comment:
Comments are closed for this entry.

A blog for Open Message Queue, the JMS provider in GlassFish Server, Open Source Edition


Top Tags
« April 2014