[rabbitmq-discuss] AMQP 0-9-1 released

[Alexis Richardson]

Hi,

The RabbitMQ team is very pleased to announce that the AMQP 0-9-1
specification was approved by the AMQP Working Group in a vote
yesterday.

The need for AMQP 0-9-1 arose from the AMQP community and AMQP
customers.  The community wants interoperability - indeed this is a
major goal of AMQP.  People frequently try to download a broker from
one implementor, and use it with a client from another implementor.
Even when both sets of code implement the same specification, this has
not always worked 'out of the box'.

Frequently asked questions have included "how to I do I .."

* get OpenAMQ's C client working with RabbitMQ,
* or get RabbitMQ's Java client to work with OpenAMQ
* use QPid's M2.1 JMS-style Java client with RabbitMQ

This has all been possible and people have done it, but in each case
it has been a few hours of coding to get it working, without the
assurance you want from a fully QAd or regression-tested and certified
package.

So I think we all want interop to work out of the box and many people
have said they expect this too.  Interop would also remove cost from
"business to business" integration projects.

AMQP 0-9-1 was created to meet that need.  It is a simplified 'interop
release' that starts from the 0-9 specification and then fixes interop
bugs and removes a lot of unused material.  For reasons of backwards
compatibility with certain existing deployments, the 0-9-1 spec will
work with 0-9 wire frames.  This means that the community can expect
to get what it demands: a set of brokers and clients that work
together.

The work to achieve this clean up was a collective effort and
represents 18 months of 'lessons learnt in production' by all the
major AMQP implementations in the 0-8/0-9 family.  Documents should
appear on http://www.amqp.org imminently.  Thank-you to all those
involved on behalf of the RabbitMQ team.

I should also explain what AMQP 0-9-1 is *not*.  It does not
interoperate with AMQP 0-10.  AMQP 0-10 introduces technology for
transactional 'once and only once' delivery within the protocol.
Similar features are planned for AMQP 1.0 which is currently under
development by the Working Group.  So please see 0-9-1 as a
stabilisation of earlier spec work, based on hard experience in
production with the 0-8 and 0-9 protocols.  Current and future
protocol work concerns the step up to the 1.0 business requirements as
published on http://www.amqp.org.

What does this mean for RabbitMQ users?

Interop is good news for RabbitMQ because we think messaging should
'just work'.  RabbitMQ will implement AMQP 0-9-1 on the 1.x tree.
AMQP 0-9-1 is absurdly similar to 0-8 and 0-9, which is one reason we
found the 'interop delta' so frustrating.

For RabbitMQ users this means a migration path not much more complex
than (say) moving from RabbitMQ 1.3 to 1.4.  Existing deployments will
continue to work but some methods - eg. access tickets - are now
formally deprecated.  For implementors of clients, the cost of
upgrading to 0-9-1 should not be more than a day's coding in most
cases.  RabbitMQ will provide updated client codegen tools when an
0-9-1 broker is released.

In terms of timing and details of the RabbitMQ 1.x broker roadmap, I
refer you to the development team.  For discussions on this as well as
packaging dependencies, and client release plans, we strongly urge the
community to come forward with comments, questions and offers of
assistance.

We hope the RabbitMQ community places a high value on 0-9-1 interop -
as high as we do as providers of the product.  I cannot speak here for
the other implementations but we have good reason to believe that
their respective communities will value 0-9-1 interop equally highly.
But if you see gaps - please jump in and help with some code or
requirements.  Or - even better - provide some test harnesses.  And if
you see any errata then you can also list them here.

What about 2009?

With interest growing in AMQP around the community, and the Working
Group being joined by Microsoft, we think AMQP is in good shape for
the future.

Members of the RabbitMQ community who wish to contribute to the
development of the protocol as we move towards 1.0, should not be shy
of speaking up on this list.  We aim to track this spec and invite
implementation ideas for RabbitMQ 2.0.  We don't want to rush things -
RabbitMQ's existing implementations set a high bar.  Stability at
scale, and ease of use, are of the utmost importance.

So - finally - I think this is a very good time to say a big thank-you
to everyone who has made RabbitMQ successful so far.   Thank-you!

Best wishes,

alexis