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

Active MQ

[LordMyren]

I thought that's what CodeHaus's ActiveMQ was for.

CodeHaus rocks, even if they are overly java biased for my tastes.

Re:Active MQ

[Anonymous Coward]

IBM MQ is extremely useful becuase it goes across platforms (Windows, any type of Unix, mainframe) as well as languages (C, C++, C#, Java, perl, Cobol, etc).

Any Java-centric system is useful to tie Java programs together, but not for firm-wide integration. The same story goes for platform-specific products. Unless your firm uses only one langauge/platform, in which case you're not likely to need queueing...

"What Is Message Queuing?"

[modifried]

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

From http://www.developer.com/net/asp/article.php/32979 11

Re:"What Is Message Queuing?"

[Profane MuthaFucka]

That little word "reliably" is more important than the blurb above states. Unlike some messaging systems, MQ will either deliver your message, or will let you know that it did not deliver your message. There is no such things as sending a note off into the wild blue yonder, only to have it mysteriously disappear without a trace.

Re:"What Is Message Queuing?"

[AusG4]

The message queuing they're talking about is code centric asynchronous message sending in either publish/subscribe or peer-to-peer systems. It's for when one library of code (say, manufacturing control) needs to relay an XML message (or Java object serialization, or whatever) to another library of code (say, procurement) to tell it to execute additional logic. Human beings, save for debugging purposes, never actually read the messages and indeed, many times the messages aren't even really human readable.

So, no, not really like SMTP. Though SMTP is, I guess, a loose metaphor for how MQ servers work. That said, Exchange has nothing to do with it. The SMTP/POP3/IMAP model is just a little too much overhead for most message queue applications.

Of course, the real problem with your statement is that asynchronous messaging doesn't in fact preclude reliability, and indeed, the word asynchronous/synchronous and reliability are more or less completely different topics and wholly unrelated.

Most MQ servers persist undeliverable messages until such time as the destination peer (or the whole of the registered subscriber list) is available and ack's receipt of the message in question. All "asynchronous" means is that library A can send a message and continue on without ever caring about -when- the message is delivered.

Using the manufacturing/procurement example again, you can see why it would be stupid for manufacturing to walk their ordering message over to procurement, then wait around for the mail clerk to show up, take the message, and acknowledge it's been received. This would be a "synchronous" message transmission. Surely, it's easier to just leave it in an "inbox" for the clerk to pick up later (send the message asynchronously).

As for reinventing the wheel, I largely agree. Most large scale applications are being rolled out in J2EE or .NET, both of which offer message queuing (J2EE having tons from many different vendors - we use OpenJMS a lot in our shop).

The only thing I can see as being beneficial is a new MQ implemented with interaction entirely in XML-RPC, etc ... as this would allow J2EE/.NET/PHP/whatever apps to use it regardless of platform.

Re:I thought that was sendmail?

[Anonymous Coward]

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.

Re:Web services

[Rob Riggs]

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.

Re:MQSeries

[azaris]

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.

Re:And that would be what, exactly?

[easter1916]

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.

Re:Web services

[Anonymous Coward]

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