• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Rabbit MQ in Action Question: JMS vs AMQP

 
author
Posts: 23958
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Alvaro, Jason,

I am very interested in your opinion on AMQP -- since Rabbit MQ is one of the few vendors that implements it. The question is... JMS already does a good job at abstracting the messaging bus from the application. And in this regard, it is also a bit of a "lowest common denominator", as some JMS functionality is not as rich when compared to using the messaging middleware native APIs... So... What is the advantage of AMQP? Is there a need for the messaging protocol to be standardized? For the messaging bus components to be interoperable? And doesn't that become an even lower common denominator?

Henry
 
author
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.)
 
Henry Wong
author
Posts: 23958
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jason J. W. Williams wrote: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.




I am not convinced that this is a strong argument. If you look at the common messaging systems today, they already provide multiple APIs. And in some cases, due to legacy issues, they provide more than one API for the same language, for example, a Java API *and* a JMS API.

Of course, it was me that brought up the comparison of JMS and AMQP, so it isn't really fair for me to change the rules ... ... 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?


Jason J. W. Williams wrote: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.



That's actually a good point -- if you consider it as a standard that is based on everything learned so far; you can design a new protocol, which is layered by a supporting APIs (and probably a framework), which in turn, allows you to build new applications. This would make AMQP a good thing.

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.


Thanks for your opinion on this,
Henry
 
Jason J. W. Williams
author
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Henry Wong
author
Posts: 23958
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jason J. W. Williams wrote:
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.




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.

Henry
 
Jason J. W. Williams
author
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Henry Wong
author
Posts: 23958
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jason J. W. Williams wrote:
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.



Well, to be fair, with JMS, there is no such a thing as "a client library you like". In JMS, the API is the standard -- meaning your application should be coded the same way, regardless of which client library you use. So in theory you should be able to switch from one JMS vendor to another JMS vendor with a configuration change. Obviously, there are some incompatibilities (okay, there are more than "some"), but those are generally around the more "exotic" features which may or may not be supported between vendors.

Henry
 
Ranch Hand
Posts: 1907
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henry Wong wrote:

Jason J. W. Williams wrote:
In JMS, the API is the standard -- meaning your application should be coded the same way, regardless of which client library you use. So in theory you should be able to switch from one JMS vendor to another JMS vendor with a configuration change. Obviously, there are some incompatibilities (okay, there are more than "some"), but those are generally around the more "exotic" features which may or may not be supported between vendors.
Henry



This generally may not happen. EMS(Tibco's JMS server) is common example. Its ofcourse supports JMS spec but when we use the tool BW(tool for designing processes),Tibco makes sure you use somehow EMS features. Ultimately we end up using EMS(ConnectionFactories,Connection objects etc). So your client code is locked in vendor.

 
Henry Wong
author
Posts: 23958
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Arjun Shastry wrote:
This generally may not happen. EMS(Tibco's JMS server) is common example. Its ofcourse supports JMS spec but when we use the tool BW(tool for designing processes),Tibco makes sure you use somehow EMS features. Ultimately we end up using EMS(ConnectionFactories,Connection objects etc). So your client code is locked in vendor.



Well... if you are using Tibco BusinessWorks, then worrying about vendor lock-in at the messaging layer may be moot -- as you are committed to Tibco for many other layers...

Henry

 
Grow a forest with seedballs and this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic