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 thought that's what CodeHaus's ActiveMQ was for.
CodeHaus rocks, even if they are overly java biased for my tastes.
"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
Since everyone else is laughing at you, I'll tell you why.
Message Queueing != Instant Messaging. RTFM luser.
Might I suggest exercising your Google skillz. Try these search terms: message queuing MQSeries MSMQ Java MQ what is a message queue?
The Spoon
Updated 6/28/2011
Ever since sendmail, email protocols did all the store&forward & configurable retrys & multiple routes & failure-messages back to the source for error conditions, etc. that these messenging systems had. Why not use them?
Crap. In my rush to be a smart ass, I forgot to select Plain Old Text. Message was supposed to read:
Might I suggest exercising your Google skillz?
Try these search terms:
message queuing
MQSeries
MSMQ
Java MQ
what is a message queue?
Thanks for your patience.
The Spoon
Updated 6/28/2011
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.
Messaging is transactional, with guaranteed once-only delivery. The messaging server (queue manager) uses database technology such as write-ahead logging to achive this.
Implementing this across TCP/IP generally requires a lon-lived conenction, as you have seperate read/write/commit/backout operations that belong together. Doing so over HTTP is theoretically feasible, but a long-lived TCP connection makes it a lot easier. Compare to databases... insert/commit isn't over HTTP either.
Until Joram works in *WELL* in a clustered mode, or doesn't decide to randomly die because it can't handle several million messages, I'd say Joram is a very poor excuse for a MQ option.
Funny thing is, Java EJBs are CORBA. They communicate over IIOP. You can generate CORBA IDL for them. And you can connect a CORBA client to them. CORBA isn't "due any day" -- it's here.
Those who know history (esp. of distributed object systems) are watching SOAP and "Web Services" evolve and just laughing our asses off (or crying, depending on the situation). CORBA has been simplifying while SOAP has been complexifying. SOAP is now more complicated to develop for than CORBA.
the growth in cynicism and rebellion has not been without cause
Our turn to laugh at you...
Jabber > Instant Messaging
IM seems to be the only significant application on the Jabber architechture though, unless I'm missing something.
Oh yeah, and to respond in kind: "try google next time, you insensitive clod!"
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.
Joram is beautiful. Unfortunatly it's entirely java based. Sure you can interface to native C applications, but you still end up with a huge runtime, and sometimes you need really lightweight processes.
_______
2B1ASK1
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.
XML blaster is an open source message oriented middleware that has bindings for multiple languages (C,C++, Java, PHP, Python, Perl).
I have never used it, but it's been available since a long time.
My heart is pure, but make no mistake, it's pure evil
You are indeed quite funny. However, the total tonnage of posts later in other threads asking about how MQ-Series competes with HTTP, InstantMessanger, J2EE containers has just made it clear to me that Slashdot hasn't been particularly illuminating to nerds - it's spent far to much time on MPAA/RIAA.
Message-oriented middleware (MOM)is broard term encompasing a messaging system that may be sychronous or asynchronous. MQ-Series runs on over 30 platforms and allows developers to integrate apps on wildly differnet systems. How would you get an app on a Tandam-Hymalaya nonstop machine to talk to an AS400, then pass the results off to Linux box as well as supplying an audit trail to a Z/OS Mainframe?
Remember that some of these platforms might not even support TCP/IP at your site.
Hint: Yahoo Instant Messanger will be viewed as a sub-optimal solution.
AC
p.s. I was just made redundant at work yesterday. (The company closed - everyone was let go) Time to stop posting and get another job....
What does it do? Virtually nothing. Just takes a few buytes of data and sends it from here to there. Thats the easy part - the hard part is that it does so with absolutely guaranteed results - if you send it, you know they will get it. Imagine chains of more or less reliable machines, software stacks and networks all linking together sender and receiver, and the horrendous business impact of failure of even a single message, and the non-negotiable need for auditing, and you start to see why there might just be a little tiny bit of complexity in there.
Some systems throw a few extra dyanmics in on top, such as a publish/subscribe model which takes you beyond just sender and receiver, but the essence of these things is not functionality but utter, total reliability.
Which seems to me why an open source model is not, in itself, an obvious way to produce such a piece of software. More than anything else - except perhaps database systems - people look to the vendors of these things to guarantee 100% reliability. Such a project, if open source, would require a big name behind it before any corporate would use it - and large corporates by their nature are the normal customers for these things.
[x] auto-moderate all posts by this user as insightful
It's been out for five years on freshmeat, and supports CORBA, RMI, XML-RPC, nativ socket, or persistent HTTP.
See the link at http://freshmeat.net/projects/xmlblaster/.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
There's been a opensource, cross-platform solution for a number of years (shameless plug), http://www.osmq.org/index.html
~~~ They call me Little John, but don't let the name fool you...in real life I'm very big.
Just last week I developed a SOAP provider and SOAP consumer application in C++ using the gSOAP toolkit. (Check it out on sourceforge). My impression: Absolutely amazing. gSOAP makes SOAP basd applications (whether or not they were initially designed to use SOAP) a breeze to code. Totally flexible, amazingly easy. The applications are boundless.
(No, I am not affiliated with gSOAP at all, just singing the praises for this amazing (open source) project).
In the sense of MQSeries and Rendevous, it's exactly what you describe except with guaranteed delivery. I know they sound a bit useless today but it's like transaction support for network communications among other things.
i nd ex.cfm?FeatureID=731
Let me give you a PERFECT example of how I've seen MQ Series used.
DB2 has/had (gone with Stinger, I think) something called userexit. This was a compiled program that was called whenever DB2 was in archival log mode.
In our case, we use a TSM (Tivoli Storage Manager) userexit. When DB2 is ready to archive a log file, it ships the log to TSM and it's on tape. One company I've heard does MQ Series userexits.
DB2 userexit's to archive the log and ships it to MQ Series. MQ Series breaks it up into smaller chunks (64k maybe? I can't remember) and sends it to a remote MQ Series server. From that server, the logs are stored locally and backed up or used to roll-forward a read-only copy of database.
The upside is that this remote MQ server is across the country at another datacenter and you know the log files got there and they got there the way they were when the MQ server got them.
Check this link. I think it's provided the best simple description of Message Queuing I've seen yet:
http://www.techworld.com/applications/features/
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"