Slashdot Mirror
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."
I think web services are going to be the next big thing.
yay
I thought that's what CodeHaus's ActiveMQ was for.
CodeHaus rocks, even if they are overly java biased for my tastes.
Buzzword buzzword buzzword, incorrectly used terminology, buzzword buzzword.
wdd
"Message queuing is a communication tool that allows applications to reliably interconnect in a distributed environment where one of the applications may or may not be available at any given time. The queue acts as a holding container for messages as they are sent between applications. The applications send messages to and read messages from queues to communicate back and forth. An application writes a message to a queue, which will then be received and processed by another application at some point determined by the receiving application. This type of communication is designed for asynchronous use where the applications involved are not waiting for an immediate response from the other end."
9 11
From http://www.developer.com/net/asp/article.php/3297
Message queueing is application-to-application messaging, which once-only guaranteed delivery. In addition, both the reading and writing of messages can be done transactionally, with a transaction spanning multiple queue operations.
Think of it like a database where an application can write a record that can be read and committed by exactly one reader; however, if that reader crashes before committing, another reader can pick up that record and try to commit it, etc.
Financial services firms use this tie their many apps together.
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?
The Spoon
Updated 6/28/2011
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...
My perception of MQ is that we would be better off throwing it away and FTPing files back and forth while using SAP's job control to kick things off.
Good luck with writing ACID transaction support, rerouting in case of failure, dead letter handling and enterprise scalability features. Then get busy convincing dozens of sysadmins to bust their firewalls open to allow the antiquated piece of crap that is the FTP protocol to get further than your office router.
Trying to replicate enterprise functionality with naive hacks makes no sense whatsoever. I pity the fool who gets to administer the kludge you leave behind when you switch jobs.
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.
--
make install -not war
No, it's akin to JMS (Java Messaging System) or, say, the TIBCO/Rendezvous system used to broadcast trading information to NASDAQ clients.
Here at my workplace, we use "guaranteed messaging" to integrate disparate systems such as SAP R/3, as iSeries/AS400 running BPCS, a bespoke warehousing system. Messages (i.e., details of a transaction, for example an XML doc. containing details of a sales order) are transmitted between systems to keep them in sync. If the target system is down the messages are queued for delivery in the messaging system itself, and delivered later.
Not a great explanation, but I hope it helps.