Open Source Message Queuing System

psicode writes "John Davies has announced AMQ, an effort at JPMorgan Chase & Co. to create an open-source message queuing system that can compete with proprietary message systems like IBM MQSeries and Tibco/RV. The announcement was made at the annual conference Web Services on Wall Street during Davies' presentation on February 1. eWeek has an article today with more details and some funny statements about Red Hat, SuSE and Sun possibly integrating AMQ into their "kernel". If JPMorgan Chase & Co. follows through with their announcement and they come up with a suitable open-source license, AMQ could become the Apache of messaging systems."

Comments

Re:Messaging = IMing?

[jdray]

I have noticed the phenomenon you mention, though I would hardly call it "anyone." I suppose I could have elaborated on the details of how a system-based message queuing system is designed to be a lossless, connectionless method for intrasystem messaging, much like a small town post office, where one piece of software delivers a message, often packaged as XML or CSV, and marks it for entry into a particular queue or stack. When other pieces of software are subscribed to the queue in question, they pick up the messages that get registered there. The messages are either destroyed on pick up or stay in the queue, depending on what type the queue is. But all this is just a surface look at how MQs are used and how they work. A layman's introduction, it might be said. It also doesn't cover the fact that they can be used as the back-end for IM systems, if you write the appropriate client software. I was thinking that this person might like to have their choice of in-depth articles to read that would educate them far more than I was willing to in the short time alloted to me for reading Slashdot each day.

But thanks for your concern. I'm done trolling for now, how about you?

Flabbergasted

[Anonymous Coward]

By the technical ignorance of some of the posters here... Before you post, please make sure you have at least an inkling about what you're talking about! A Message-Oriented Middleware system has absolutely nothing to do with IM, or Web Services (except in a very indirect way), or even REST systems. /. seems to be in dire need of real geeks, it seems...

Queue Redux

[Doc Ruby]

Keep in mind that Wall Street was probably *the* major engine driving Web applications into the mainstream in the 1990s. One reason Wall Street went crazy touting the Web as an unlimited business panacea was that it was actually like that for its own industry. By the time they promoted it in 1995, Wall Street shops had been churning out httpd patches, CGI apps, Perl revisions and code, DB connection software and techniques, TCL patterns, and all kinds of R&D that underpinned much of the development momentum. Message Queueing has a similar arc, because Wall Street both inhabits the bloodiest edge on which they can survive, and has the least tolerance for failure. The flakiness of network messaging is the root of some of the worst inhibition on network growth among users and deployers - Wall Street has been there, and has answers. Let's use them.

Re:"What Is Message Queuing?"

[vidarh]

Except that most mail servers aren't designed to give the kind of delivery guarantees that message queueing software like MQSeries does. Most are also not designed for the kind of performance you can get out of many message queuing solutions that take advantage of the fact that the number of recipients tend to be low (compared to e-mail) and keeping persistent connections to some or all queue endpoints may be acceptable; and neither are they designed to provide support for transactions etc.

It's not that this can't be done over SMTP, but that SMTP isn't practical for it - you'd need lots of extra data in the headers, and applications supporting it.

Sure, you can write the support for all of it on top of SMTP, or FTP or SCP or HTTP or any protocol you can think of that can move data from one point to another, but the whole point of message queueing applications is that the heavy lifting has been done for you.

If you don't care about the transactions, or it doesn't matter if your messages can be delivered twice by mistake, or any of the other features of a proper message queuing system, then sure, go ahead and use a mail server - a previous place I worked we used Qmail with good results. It's a trade off, but the difference is huge.