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

I bet this really pisses off the copyright expansi

[ShatteredDream]

As a voting libertarian, I whole-heartedly encourage companies to actively develop whatever technical solution that best fits their needs. This is one example of how open source software really fits in with the libertarian world view. It's not the "free software versus only commercial software," but a mix and match that lets both coexist. If someone wants to develop their own software, then let them and don't even begrudge them the right to give it away.

This is what really pisses me off about the copyright expansionists. They don't want people to be able to easily develop software for free. Copyright expansionism, as pushed by groups like the "Progress and Freedom Foundation" is not about freedom, it's about protecting business against hobbyists and other "asymmetric competition." I bet it makes such groups' heads spin to think that one of the biggest corporations on Wall Street is now about to dive head first into open source development and that the result of this development could send shockwaves through a segment of the commercial software industry.

The freedom to write open source software is the same freedom to write closed source software. If you erode the foundation for the former, then you have no right to demand respect for the latter. That is why when the big copyright cartels lobby Congress, I see nothing wrong in doing things like buying academic licenses for software and taking them out into the real world. The copyright holder makes no profit on the academic license, only the seller does.

a camel

[St. Arbirix]

an open-source message queuing system that can compete with proprietary message systems like IBM MQSeries

Somewhere in IBM's headquarters there is a camel. A straw has just been placed on its back.

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?

Savings

[blackmonday]

Some years ago a company I worked for was quoted one hundred thousand dollars as the cost to license IBM MQ Series messaging. There could be some serious savings in using an OSS product like this.

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...

Re:Flabbergasted

[slcdb]

As one other Slashdotter commented about the article itself:

Buzzword, buzzword, buzzword, incorrectly used terminology, buzzword, buzzword, buzzword...

The same could be said to summarize most of the Slashdot readers' comments.

I guess somebody just needs to say it: the article was crap, and Slashdot was the wrong forum for discussing it.

please someone explain.

[Lord Bitman]

What is a message queue, why should I care, what does this have to do with anything, what are they talking about? In short: what kinds of messages are we talking about, what are sending them to what, and why do we need to queue them?

"A message queue is a queue onto which messages can be placed."
thanks a fucking lot google

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.