Archive for the ‘amqp’ Category

AMQP 1.0 becomes ISO 19464

May 1, 2014
A guest post by John O’Hara, Originator of AMQP

I’d like to thank Steve for inviting me to write a few words on his blog.

I remember using Steve’s ACE framework on a banking project back in the 90’s before I got to know him through his contributions to AMQP (Advanced Message Queuing Protocol).

I’ve taken to posting a rare blog entry because today AMQP becomes ISO 19464.

ISO standardization is a high bar requiring international consensus to achieve and as a result it confers an associated sense of stability and longevity.  I think this milestone will establish AMQP as the backbone of business computing; the unseen, essential networks that hold the world together.

What does this mean?

It means that for the first time, we have standardized connectivity that is portable between businesses and which combines security, event subscription and the enactment of transacted reliable messages. With AMQP / ISO 19464, we can be reliably enact ecommerce without depending on third-party exchanges or requiring proprietary software and this removes many of the technical barriers to dealing with new business partners.

This portability makes AMQP an important technology for switching workloads between Cloud providers, where it is already widely adopted.

AMQP also enhances the potential of other ISO standards including ISO 20022 (Unifi) the standard for financial messaging by combining the means to perform financial transactions with a secure reliable transport.

How might this affect me?

If you are in business or government computing, you should take a look at how AMQP / ISO 19464 can connect your internal systems and your business partners in an open, secure, agile manner.  Take a look too if you’re writing mobile apps, multiplayer games, computer animations, social networks, departmental applications or if you are building out the Internet of Things.  An AMQP implementation will get you to market faster.

How did this happen?

I’m the father of AMQP, the guy with a vision who invited those first bold firms to join the AMQP Working Group.  There, a dozen or so middleware experts and users from leading firms worked together to realize a shared vision to make messaging better. We transitioned to OASIS as part of a deliberate journey towards openness and today’s ISO recognition.  We wanted to get to ISO to ensure AMQP could be relied upon for the long term by the largest consumers of middleware; government, healthcare, finance, etc.  We wanted it to be dependable for decades, an industrial level of stability that is necessary when connecting between independent entities.

What next?

As we developed AMQP we gained profound insights in to the nature of messaging.  When you work long enough with it you discover that the patterns in messaging are axiomatic truths of nature to be discovered rather than invented.  Early iterations of AMQP embody useful innovations but also contain issues that made it difficult to use at global scale or to admit existing products.  More recent editions corrected these and also reduced the scope slightly to broaden its applicability. What we have today in AMQP / ISO 19464 delivers the essential core of messaging and opens the door to future innovations in intelligent networking. I’m excited about what people will do with it.

What is this in layman’s terms?

Take social networks as an example. These are based on the idea of creating queues of events (they call them timelines) and notifying subscribers (they call them friends) of interesting developments.  AMQP brings the basic machinery for doing that to every software developer.  But it also adds security and performance optimizations, and it adds the ability to perform transactions.  AMQP sets a high bar for the lowest common denominator of capability and then makes that pervasive.

AMQP has been a long time in the making since it was conceived in 2003.  Achieving consensus in something as complex as messaging and working it through the rigorous processes that lead to standardization takes time.

I want to express again my thanks and sincere appreciation for the commitment, the intellect, the passion and the good humor of all the people who have helped make AMQP.  These are people I am proud to count among my friends and mentors.


John O’Hara
Originator of AMQP


For more views and news on today’s ISO announcement concerning AMQP, please see blog posts from Ram Jeyaraman and Brian Benz of Microsoft, and David Ingham of Red Hat.

Apache Qpid 0.10 Released

May 4, 2011

The following announcement was issued by the Apache Qpid project:

The Apache Qpid community is pleased to announce the immediate availability of Apache Qpid 0.10.

Apache Qpid ( is a cross-platform enterprise messaging solution which implements the Advanced Message Queuing Protocol (AMQP, It provides brokers written in C++ and Java, along with clients for C++, Java JMS, .Net, Python, and Ruby.

Qpid 0.10 is available from our website:

The 0.10 release has undergone a lot of bug fixing and feature enhancement.  We recommend that all users upgrade.  A few changes of note:

  • The C++ broker now supports priority-ordered message queuing
  • The C++ broker and client now implement producer flow control
  • The Java JMS client is now available via Maven

A comprehensive list of features, improvements, and bugs resolved in the 0.10 release is available here:

Simple, Single-Thread Message Receive in Apache Qpid C++

November 16, 2009

In my September 2009 newsletter article I showed a simple example of sending a message using the C++ API to Apache Qpid. Since I intend to write a number of how-to Qpid articles, most of them will appear here in my blog. (You can still subscribe to my newsletter… there are other interesting things there 🙂 If you’re not too familiar with AMQP terminology it may help to review the newsletter article because it defines the basic architectural pieces in AMQP.

This article shows a simple, single-threaded way to receive a message from a queue. The previous example showed how to send a message to the exchange with routing key “my_key”. Thus, if we have a client that creates a queue and binds the exchange to it using the routing key “my_key” the message will arrive on the queue.

To start, we need the header files:

#include <qpid/client/Connection.h>
#include <qpid/client/Session.h>
#include <qpid/client/Message.h>

Just as with the message-sending example, we need a connection to the broker and a session to use. We’ll assume there’s a broker on the local system and that it’s listening on TCP port 5672 (the default for Qpid). The new things in this example are:

  • Declare a queue (my_queue) that will receive the messages this program is interested in.
  • Bind the new queue to the exchange using the routing key that the message sender used (my_key).
  • Use a SubscriptionManager and LocalQueue to manage receiving messages from the new queue. There are a number of ways to receive messages, but this one is simple and needs only the single, main thread.
qpid::client::Connection connection;
try {"localhost", 5672);
  qpid::client::Session session = connection.newSession();
  session.exchangeBind(arg::exchange="", arg::queue="my_queue", arg::bindingKey="my_key");

  SubscriptionManager subscriptions(session);
  LocalQueue local_queue;
  subscriptions.subscribe(local_queue, string("my_queue"));
  Message message;
  local_queue.get(message, 10000);
  std::cout << message.getData() << std::endl;
  return 0;
catch(const std::exception& error) {
  std::cout << error.what() << std::endl;
  return 1;

It’s pretty easy. Again, this is a simple case and there are many options and alternatives. One particular thing to note in the above example is that the Message::getData() method returns a reference to a std::string. It is easy to assume that this means the message is text. This would be a bad assumption in general. A std::string can contain any set of bytes, text or not. What those bytes are is up to the application designers.

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

April 2, 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 (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.