The Journey to AMQP 1.0 with Apache Qpid
To be honest my journey to AMQP 1.0 with the Qpid implementation was a little bumpy. My job requires me to be involved in lots of different technologies: from the micro Realtime kernel (no I have not contributed to the kernel - I just had to learn and teach others about realtime use cases), to the macro grid and cloud technologies; with messaging and virtualization etc. in between. Switching hats all the time, and often at the same meeting, is challenging. I do like to keep my hands in the technology - to keep me honest. The area I have most rolled up my sleeves is with messaging but it is often in short bursts.
As a result I have been less involved in the AMQP specification as I'd like to be. And that is: not at all - unless you count any influence I have with the involved engineers at Red Hat. So I did not always see the progression to AMQP like those involved and I got very confused along the way.
I "loved" exchanges. They were part of the first AMQP 0.8 specification. They made so much sense. When Qpid made changes to the "addressing" I wasn't all that happy. It seemed confusing and complicated. Why were we moving to a new and simpler API but then forcing a complicated and confusing addressing mechanism? (Compound that with inconsistencies between the C++ and Java APIs and my frustration grew worse.) But it was all part of the move to AMQP 1.0 I was told. And I was getting a bit fearful of what AMQP was turning into. It was explained that there was a move away from exchanges and queues to "nodes". I was beginning to get deflated. Why move from something that worked so great and was so cool to explain the value of to people, to something with abstractions like nodes and addresses?
So my colleagues went to work on me. Understanding that I'm not nearly as foolish as I let on they took the time to invest in convincing me that AMQP 1.0 was way better. (Or perhaps they thought I was a fool but still needed to be convinced.) It's been a long road (especially with all the travel interruptions). But I get it now.
The power of AMQP is in the addressing. In the AMQP 0.8 specifications this was wrapped up in exchanges and queues and bindings. The real power of 0.8 was NOT in the exchanges but instead it was in the bindings - the routing. After all, the three (or more) different exchanges were really just specializations of the same abstraction - a router or the default exchange. I have always maintained that the power of AMQP is that it is a really powerful router of messages. The broker of 0.8 and it's exchanges, queues and bindings provided a brilliant and dynamic routing capability mainly through decoupling the sender from the endpoint.
With AMQP 1.0 all that is in the addressing with much more power. My clients/publishers/senders (whatever you wish to call them) do not care how the endpoint is implemented. And by the way that endpoint was always a broker in 0.8. So you are not sending to an exchange but to an address. How it gets there or where that is is neither here nor there. And with AMQP that can end up to be many different endpoints or applications. And the receivers/subscribers/servers don't care where a message came from (except from a security perspective) or how that was implemented.
I can still have a broker. But a broker becomes much more how I used to describe a broker: a router. I can still implement an exchange in my router. I can have different flavors of routers instead of a one size fits all broker (0.8). Routers for various tasks. And, by the way, with the Qpid proton library approach I can stick that in anything and anywhere!
So with AMQP my messaging topology becomes much more of a network. And that is much more powerful. AMQP is to messaging networking to what HTTP is for request-response internet application communications. In fact many internet applications are going to be relieved of some unorthodox HTTP trickery by switching to AMQP. People will use only HTTP where it makes sense and use AMQP everywhere else. (I'll post an HTTP and AMQP comparison at another time.) Lots of new types of mobile and cloud applications become much more reasonable with AMQP.
TrackBack URL: http://ipbabble.com/cgi-bin/mt/mt-tb.cgi/54