AMQP surfing a wave of positive progress

Earlier this week I attended the second annual AMQP Face-to-Face conference at the beautiful Scripps campus at the University of California San Diego.  Even a somewhat dreary day in San Diego, which they call June Gloom, is better than a nice day back home in Ottawa, and I was inspired by the many surfer dudes and dudettes who braved the cool weather to venture into the waves.  I kept my feet on dry land and the lifeguards no doubt appreciated that.

The first day of the event was open to the public, and over 50 attendees came to see what’s happened with AMQP over the past year.  The agenda for the day included technical tutorials on the AMQP1.0 wireline specification, some sharing of user experiences, and a discussion of plans for 2010.

In summary, after six years in development the AMQP1.0 wireline spec is now in “recommended” state. That means it is frozen and the only technical changes will be errata. That’s important because any required changes must be addressed in a backward compatible manner if at all possible, so people can now implement the wireline protocol without worrying so much about the need to redevelop things.  The spec will move to “final” when there are two independent and interoperable implementations.

AMQP1.0 is a significant change from previous 0.x versions where things like “exchanges” existed.  The new architecture has “nodes” and “links”, with “sessions” and “connections” being used to provide a framework for message exchange.  It includes capabilities such as the definition and encoding of data types (which can be used for things like JMS data types), flow control, flow (de)multiplexing on a single connection, persistent/durable delivery, security, and local as well as global transactions.   This is all spelled out in great detail, and in some cases the functions have even prototyped by group members, which represents a ton of effort put forth over the past year.

The next step is for the group to build upon the foundation of 1.0:

• The group will specify how the AMQP1.0 wireline protocol can be used to have a JMS API from one vendor talk AMQP1.0 to a broker from a second vendor, and then to an API from a third vendor which could be JMS or WCF.  Both API and wireline interoperability through a broker — now that level of interoperability in the messaging world is seriously worth watching!
• The group will also focus on broker management, i.e. standardizing how brokers can be managed by users by — you guessed it — sending AMQP messages to a special “management” entity within the broker.

All in all, the three day meeting was upbeat and positive, demonstrating a lot of progress and bringing more clarity to the impressive potential of AMQP. And as if the weather gods were paying attention to our sessions, the clouds parted and the sun came out as the discussion moved on to plans for the future of AMQP in 2010 — surely a sign of good things to come.