Review of AMQP Face-to-Face Public Meeting, April 1, 2009

View from Scripps Forum at UCSD

View from Scripps Forum at UCSD

Holding a public review for a new middleware specification somewhere as gorgeous as the Scripps Institution of Oceanography at UC San Diego takes guts. I mean, really, with views like this, the material being presented has to be really good to keep the audience’s attention.

AMQP, and its energetic originator and chief evangelist, John O’Hara from JP Morgan, did not disappoint, referring to AMQP as “Internet Protocol for Business Messaging” with a vision to have an AMQP endpoint with every TCP endpoint, much as is the case with HTTP today.

With the AMQP specification nearing version 1.0, it was time to bring the community up to date on progress and what has changed since version 0-10.

During the 1.0 work, Mark Blair from Credit Suisse headed a “user sig” to ensure that business requirements would be met by the AMQP specification. The sig identified a number of critical characteristics:

  • Ubiquitous, prevasive. In addition to the wire protocol, the AMQP license is extraordinarily open, ensuring it can be obtained and implemented by virtually any interested party.
  • Safety – trusted/secure operation is a priority.
  • Fidelity – predictable delivery semantics across boundaries
  • Unified – wants to be the sole messaging tool for all; has new global addressing format
  • Interoperability between different implementations
  • Manageable – users want standard management and plug-ins to other existing standard management tools

There was a lot of information at multiple levels of technical detail that you can read about at www.amqp.org (the presentations are at the bottom of the page) but I’ll briefly explain the two items that struck me most as being big improvements for version 1.0:

  1. Exchanges are gone. Pre version 1.0, an Exchange accepts messages from producer applications and routes them to message queues using prearranged message binding criteria. In real-life situations this left too much responsibility to the producing application; the arrangement has been simplified for version 1.0. Applications now interact only with queues having well-known names. A new element, Links, has been added. Links move messages between queues using contained routing and predicate logic. They can be configured using the new management facilities. The new arrangement is simpler and more flexible and will likely result in even simpler client implementations.
  2. A new Service concept – a Service is an application inside the broker. You can add new ones as needed. Interbroker operation is a service, as is the management facility. I’m sure many new, creative things can be added to AMQP implementations with this new facility.

So when will AMQP version 1.0 be available? The PMC is working to iron out the remaining details of the specification now. Then the implementing begins. After there are at least two independent implementations of the specification that successfully interoperate, the specification will be considered final 1.0.

I came away from the meeting very excited about AMQP’s future. Message-oriented middleware (MOM) is a fundamental piece of many systems and is the natural solution to many networked application areas, but the solution space has been fragmented and often very expensive. That’s all changing. There are hundreds of real-life AMQP deployments today. The attention AMQP has generated is leading to more interest from more varied application areas. I’m confident that the new facilities and simplifications for the next AMQP version will further its progress even more.

Advertisements

2 Responses to “Review of AMQP Face-to-Face Public Meeting, April 1, 2009”

  1. Eric Strennen Says:

    I am just starting to get up to speed on AMQP. I am the principal developer of a scientific application that has disparate programs that communicate via sockets using the ACE framework (on a Windows platform). To me it appears as though AMQP is a layer abstracted above ACE. Would you be able to briefly describe the strengths/weaknesses through a comparison of these two? Thanks.

    • stevehuston Says:

      Good question, Eric. You’re right that AMQP is a layer above ACE. One could build an AMQP implementation using ACE.

      ACE: broad C++ OS middleware – it covers much more than comms, as it has facilities for sockets, threads, containers, memory pools, synch primitives, etc. In terms of comparing with AMQP for communications, ACE is great for when you need TCP-level flexibility or you want direct control of the connection. ACE would also be more appropriate if you must interact with a peer whose software you don’t control; i.e., the protocol is defined beforehand and you have no control over that. ACE also has a big advantage in platform and compiler coverage at this time.

      AMQP: all about business messaging (think MSMQ or IBM MQ Series). If the problem you are solving involves exchanging messages that are not necessarily 1:1 peer-to-peer, need reliable queuing, can be persistent across failures, or that involve transactions, AMQP is better suited. Again, you could build an AMQP with ACE, but why would you? There are multiple AMQP implementations available to use already, in various languages.

      That said, ACE and AMQP are not mutually exclusive. You can, for example, use AMQP for messaging and ACE to handle threads or work queuing or portable shared memory. It would also be possible, for example, to develop an ACE Reactor implementation that handles AMQP messages.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: