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.
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.
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?
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.
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.
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.
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.
MH
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.
Grow a forest with seedballs and this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|