Jason J. W. Williams

Interesting. I am seeing this pressure from the users (meaning the customers who use the major messaging systems), and not from the view of the standards organizations. I guess it makes sense. If you put pressure on the vendors to support AMQP, the vendors will put pressure on the standards body to enable (or ease) any transition process.... Anyway, "broker-to-broker connectivity standard" doesn't sound like the vendors will support AMQP natively. Instead, it looks like the broker will be a sort of gateway, router, or forwarder, connecting the native messaging bus to the AMQP messaging bus.

That very well may be. I don't see it in Tibco or IBM's best interest to support AMQP and make it easier for their clients to change platforms.

Back onto the main topic of JMS for a minute, another key differentiator from AMQP, is that JMS clients are not cross-compatible even within Java. With rare exception you can't use vendor A's JMS client with vendor B's broker. And their adherence to the JMS API interfaces is even loose enough to the point that it's not always plug and play to change clients in your app either.

The beauty of AMQP is, once you find a client library you like, you can stick with it even if you change brokers. Since AMQP is a standard wire protocol, all AMQP clients work with all AMQP brokers with rare exception. Also, being a wire protocol standard, you see a proliferation of AMQP clients generated by the users and community, as opposed to JMS where most of the clients by nature can only be developed and are locked to the vendor.

As you can tell, for me AMQP's beauty is in making it easy for the app to talk to any other app or broker without lock-in.

I guess the point that I am making is, as an abstraction layer, which arguably both are (just at different layers), can you actually do a common protocol that isn't a lowest common denominator?

AMQP really is not an abstraction layer, where an abstraction layer is constrained by the direct protocols and software it is trying to abstract. AMQP never was designed to be an abstraction layer, but rather a new common protocol many could implement if they desired. And in this case, many brokers (RabbitMQ, Qpid, etc.) use as their only protocol.

On the other hand, I am seeing AMQP being pushed (and pushed hard) as a connectivity standard. The idea is if you can push Tibco and IBM products to share the same protocol, then you can get your old Tibco RV applications talking to your old IBM MQ applications -- simply by changing the shared libraries (and maybe some config files). I think this will be very difficult -- and even if it is possible, I will argue that it will be the lowest common denominator requiring application changes.

The folks pushing AMQP as a connectivity standard are the folks who have commandeered the AMQP Working Group (RedHat, etc.) for that sales-pitch. In fact that's why AMQP 1.0 is about as related to AMQP 0.9.1 as Gopher is to HTTP (in this case 0.9 would be HTTP). If you look at AMQP 1.0 it has been re-engineered to make it easier to use as a broker-to-broker connectivity standard. But that's also why it's used by almost no one.

90% of the world uses AMQP 0.9.1 which is truly a new protocol for messaging and not trying at all to be an broker integration layer (0.9.1 is focused on making actual app developers lives easier rather than broker writers). AMQP 0.9.1 is what RabbitMQ uses, and it's what we cover in the book...and frankly it's far superior in my opinion for app developers than 1.0. Most of the world using AMQP is using Rabbit and RabbitMQ has not been moving towards AMQP 1.0 since it's not what users want. Rather, the Rabbit team have been adding extensions to 0.9.1 that you can use or not, without breaking the protocol. AMQP 0.9.1 is not going anywhere, and I think we'll see 1.0 wither on the vine.

Hi Rogerio,

Two examples of good fits for RabbitMQ:

1.) Batch processing jobs - Let's say you have a website that allows photo uploads, and those photos must be resampled to two "thumbnail" sizes in addition to storing the original. Rather than having your front end application make the user wait for their upload to "finish" while it does the resampling, your front end app could simply publish a message into RabbitMQ containing a reference to the image's ID in the database and then immediately return to the user. Your backend "resampler" app would then consume from the queue that receives resampling requests and generate the thumbnails asynchronously from the actual front-end upload of the image. Your user has a faster upload experience, and if you need to scale up more "resampling" horsepower you simply attach more instances of the "resampler" app to the RabbitMQ queue that receives the requests. Your front end is no longer tightly coupled to the resampling process...it simply stores the original image, fires off the resampling message and goes back to letting your users interact with your site. RabbitMQ is great for any type of batch oriented job like this, where you receive "work orders" and want to be able to both process them asynchronously from receiving them, and be able to easily scale processing power up or down.

2.) Logging and Decoupling - Let's say you built an instant messaging website, where you want to both log every IM and display realtime summary statistics (IMs/sec, number of IMs set to particular recipients, etc). Also, let's say you want to store the actual IMs in Cassandra, but the summary statistics you want in a fast in-memory store like Redis so they can be updated in realtime. With RabbitMQ you could have your front-end publish each IM just once into Rabbit with a tag of "im_log". Then you could create two queues (permanent_log, summary_log) that both subscribe to copies of messages tagged with "im_log". You'd write a consumer app that attaches to the permanent_log queue and writes all log entries to Cassandra, and then you could write a second consumer app that attaches to the summary_log queue and updates summary statistics in Redis in realtime. Now let's say a week goes by and your biggest user wants the ability to send a copy of every IM on their account via XMPP to an outside IM server. Since you're using Rabbit already, all you have to do is create a new queue called "external_log" that also subscribes to messages with the "im_log" tag and then attach a consumer to that queue that forwards the IMs on. Bingo presto, no changes to your front-end or other loggers and you've got the new feature! This is a huge gain over writing a huge monolithic logging app that would have to be rewritten to add the XMPP forwarding feature...or even worse to add the same directly into your front end code and break who knows what. Also, like the last example, you can scale up any of the 3 logger apps easily by attaching more instances as needed to the appropriate queues.

Does that help?

-J

(There's lots of other models that are good fits for Rabbit too since you can actually reply to messages in Rabbit...and use it for RPC or the like.)

Hi Henry,

The biggest benefit over JMS is not being locked into one language. AMQP doesn't care if your front end is in Ruby and your back end is in Java. It really makes it much easier to integrate diverse applications into a single stack. JMS is a lowest common denominator because it was designed as an abstraction layer over brokers that already existed. As a result the native APIs always were going to have a richer feature set.

By contrast AMQP, was not designed to layer over existing brokers, but to start with a fresh sheet of paper to provide the desired features for messaging using an open protocol. As a result, AMQP is not constrained by what existing brokers do or do not offer, instead it's design goals have been dictated by what do messaging users want? AMQP is a modern intepretation of what a messaging protocol should offer...both in it's 0.9.1 and 1.0 variations. That's why AMQP is very much not in the same "lowest common denominator" boat as JMS.

-J

(...also crucially different...AMQP provides mechanisms for broker-specific extensions that don't break the overall protocol. So you get the best of both worlds, a common protocol with optional extensions you are free to utilize or not. Which is unlike JMS, where you HAVE to use a completely proprietary native API if you want those extensions. With AMQP you use AMQP, no matter what subset of it's features you want.)

Hi Daryl,

From my discussions with Marek @ Rabbit about it, it should support "moderate" load on a single Rabbit instance and benefit from clustering for scaling up. The performance hit as compared to pure STOMP should be negligible. Does that help?

-J

Very happy to be here! Thank you for inviting us to be a part. Please do let us know any questions you have and we'll be happy to answer!