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.