The Joy of Message Queuing
There are three main middleware technologies used today for communication between distributed applications: remote procedure call (RPC), message queuing, and, if one of the applications is a web browser, HTTP. It’s usually pretty obvious when HTTP is the right choice, but deciding between RPC and message queuing can be harder. The holy war that has raged between adherents of both technologies has made the decision more difficult still.
I spent several years as a foot soldier in the RPC army, dutifully dissing the evil message queuing. But I was wrong. A service that allows an application to send a message, then go on about its business confident that the message will eventually be delivered, is a great thing to have.
Message queuing is like e-mail for applications, while RPC is akin to placing a phone call. If you know your target is in, and you need a response right now, picking up the phone is the right approach -- it’s immediate and efficient. But phone tag is no fun, and there are plenty of situations where e-mail is a better way to communicate. Accordingly, message queuing is exactly the right technology for many, many problems. Among other things, a message queuing infrastructure allows recovery in the face of network failures, permits variable quality of service through prioritization of requests, and supports workflow applications. All of these features are part of why message queuing is thriving as an underlying technology for enterprise application integration.
Choosing a message queuing vendor was once a painful process. The market was full of small companies, each of which offered something slightly different and any of which might be out of business in a year. Today, the market has matured, and choosing a product is much easier.
To pick a message queuing vendor, you should begin by answering one question: Does IBM’s MQSeries meet your requirements? MQSeries is available on most operating systems, it is from a reliable vendor, and it has acquired something like two-thirds of the message queuing market today. When choosing a vendor, I’m always inclined to begin my search with the market leader, so any hunt for a message queuing product should begin with IBM.
The most serious competitor to MQSeries today is the Microsoft Message Queue (MSMQ). According to Alan Dickman, a noted transaction processing expert and chief technologist with the consulting firm TPMQ-Experts (www.tpmq-experts.com), "MSMQ offers ease of programming and administration, terrific performance, and great reliability." It's also bundled with Windows NT Server, which gives it a very attractive price point -- zero.
And although Microsoft only provides MSMQ on its own operating systems, a firm called Level 8 Systems Inc. (www.level8.com) offers MSMQ clients on many other systems. This makes MSMQ especially interesting for customers who have chosen Windows NT as their primary platform for new development. They can use MSMQ as their application messaging backbone while still sending and receiving messages with Unix, OS/390, OS/400, and OpenVMS systems using Level 8’s products. Of course, Level 8’s products still require an NT server around somewhere -- you can’t completely dispense with Microsoft’s MSMQ code.
Finally, there are several smaller companies still selling message queuing products, including BEA Systems Inc. (www.beasys.com), Iona Technologies (www.iona.com), and Tibco (www.tibco.com). These companies also offer solid products that can make sense for companies choosing a strategic middleware product. But Dickman adds, "I am less likely to recommend them to customers needing a point solution, because of the ongoing support costs associated with products outside the mainstream." He is right on the money. As always, it’s tough for smaller fish to make headway when they’re sharing a pond with IBM and Microsoft.
Message queuing isn’t easy. Writing applications that use messaging is probably a little more complex than writing RPC apps, and managing a complex environment with lots of queues takes time and effort. Still, when the application-to-application phone call of RPC won’t suffice, sending a message is the way to go. --David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at david@chappellassoc.com.