At the end of October, members of the OASIS international open standards consortium approved version 1.0 of the Advanced Message Queuing Protocol (AMQP), an enterprise-level messaging protocol, as an OASIS Standard.

Active support by Red Hat, Microsoft, VMware, INETCO and a plethora of other vendors makes this a very credible standard. Active support by JPMorgan, Bank of America, Deutsche Börse, Goldman Sachs, Credit Suisse, the US Department of Homeland Security, and other large end users guarantees it’s a standard that will be seen in the enterprise at the very least.

The standardization of AMQP marks a turning point in the industry, a turning point from the past, consisting of a small number of enterprise-capable proprietary systems plus numerous, specific-purpose “roll your own” protocols, to the future, consisting of a standard messaging protocol used to interconnect products and services from a large number of vendors. In fact, with a modest degree of luck, AMQP will do to middleware messaging what TCP did for computer-to-computer communications, IEEE 802 did for local area networking, and HTTP did for the Internet.

The standardization of AMQP signals the death knell for proprietary messaging systems. Large end users have signaled by their participation in the AMQP standards group—and their use of products developed with the protocol—that they are tired of being held hostage to proprietary messaging systems. Even if AMQP does not itself end up being the ultimate messaging standard, the word is out that the way to connect services is by open standards. Translation: If vendors do not want to use AMQP, they still need to be ready to propose an alternate open standard. Proprietary messaging systems are a thing of the past.

What justification is there for this confidence? Well, the big push over the past few years has been to connect products and services from multiple vendors into ever-larger total solutions. In the days when distributed systems existed within the enterprise itself, the different components could be provided by a single vendor using a proprietary messaging technology. In the current environment of cloud and service-based computing, this is no longer the case. Different components come from different vendors: some big, some small, some Linux, some Microsoft, some in North America, some in Europe, some written in Java, some in .NET, and so on. Connecting all these via proprietary technologies is just not an option.

An excellent way to ascertain when an area is ripe for standardization is to look at the external environment. In the case of messaging protocols, the increasing activity in the area of “open-source” protocols of various types, along with the increased interest and adoption rates by large organizations, has made it clear that the time has come for a standard. Likewise, when vendors and organizations large and small start working together, it is inevitable that the end result will be a standard that will revolutionize the space.

So why should AMQP be that standard? It is attractive as a general-purpose messaging protocol for a number of reasons:
• It supports a comprehensive set of interaction patterns, including publish/subscribe, transactions, request/response, one-way messaging, and store-and-forward.
• It is independent of any broker technology, allowing it to be used by a diverse set of brokers such as Microsoft’s Service Bus, VMware’s RabbitMQ and IIT Software’s SwiftMQ.
• It stands on its own, allowing AMQP to be used in real-time, point-to-point messaging environments.
• There are interoperable products out there that use it.
• Non-key capabilities are optional, allowing it to be very wire-efficient for real-time applications requiring minimal messaging capabilities, while still supporting more intensive broker-based transactional applications as well.
• The timing of the AMQP standardization effort is dead on to when the market needs it.
• It enjoys support from both large and small vendors as well as large, game-changing organizations.
• There are currently no competing standards that offer similar capabilities, enjoy similar support, and are application/broker independent.

Now for the full disclosure! I wouldn’t be using AMQP or participating in its standardization if I didn’t believe in it. However, I am a co-chair of the OASIS AMQP 1.0 Technical Committee, and the CTO of a company that uses AMQP in its main product. You can take this as a bias. You may just as easily take it as me knowing what I’m talking about. Your choice. Either way, check it out! You can find more at the AMQP website, and find the standard itself at https://www.oasis-open.org/standards#amqpv1.0.

One word of caution: AMQP 1.0 has evolved from a number of earlier attempts at messaging (some better than others). Anything that is not specifically AMQP 1.0 should be ignored. They’re different protocols.

Angus Telfer is a founder and CTO of INETCO Systems, and was co-chair of the OASIS AMQP 1.0 Technical Committee at the time of its standardization.