FAQ

A: We have collectively noted that open standards efforts between companies to automate electronic transactions are often hindered by the need to incorporate proprietary solutions at the messaging layers of such protocol stacks. This lack of a capable, open transport undermines the aims of such standards and imposes unnecessary barriers to e-commerce, distributed systems, electronic marketplaces and ultimately to free trade itself.

Messaging middleware is also a vital internal component of many applications, yet until now the market has failed to provide a unified, standardized solution for this necessary utility.

To attempt to provide solutions to these problems the Working Group members set about designing AMQP freely-licensed protocol specification intended to enable implementations from any number of sources to address the most common business messaging requirements.

Q2: How will the AMQP work be licensed?

A: The AMQP Working Group immediately and freely grants all the rights necessary to effectively use or implement the protocol upon the release of a formally published version of the Specification. AMQP is an unencumbered work. See the license page.

The initial version (0.8) was released by the group as a Published Specification. In December 2006, V0-9 was also released as a Published Specification (note the versioning is 0-9 with a dash, because the next release is 0-10!).

Anyone may freely implement any Published Specification version in software or hardware without the prior permission of the group, provided that they comply with the terms of the license. You should state which version(s) of the specifcation your implementation supports.

AMQP will continue to evolve and no guarantee of backwards compatibility can be given prior to version 1-0, but it is the aim of the group that backwards compatibility will not be given up lightly.

Note: A license is NOT granted for the implementation of unfinished Draft Specifications, because these are subject to change and premature implementations of these may lead to significant incompatibilities between implementations.

Q3: Which application Use Cases does AMQP support?

A: We're merging the essential capabilities of store-and-forward transactional messaging, high-performance publish and subscribe event notification, and batch file transfer styles of messaging.

The standard use cases are:

Reliably deliver value bearing messages (fire and forget; you can absolutely trust AMQP to get the message to its destination once receipt is acknowledged by the transport)
Rapidly deliver status events to a large community (publish sub-event notification)
File transfer (secure, can be resumed, firewall friendly, and dependable)

Many business applications depend heavily on these idioms. AMQP brings them together in one solution. One can imagine an AMQP based middleware solution as the only messaging middleware in a typical enterprise business system that:

distributes price and inventory information to hundreds of clients in real time across a global network
accepts orders from those clients and processes them reliably in a clustered transaction processing engine
produces batch file feeds for internal ledgers, reconciliation, and the like
connects to other trading partners over the Internet to exchange information between their back-office processes
carries out all these functions in a secure manner which would pass an audit
enables operators to monitor and control the system, and integrate it with existing back-up regimes
monitor application traffic to build up a real-time view of business activity.

AMQP solutions may also be effectively deployed to high performance clustering and grid computing problems, however the primary goal of AMQP is to enable the communications necessary for business processes.

Q4: What is a 'wire-level' protocol?

A: A wire-level protocol can be thought of as the complement of an API. Instead of defining functions and creating libraries, you define the conversational byte sequences that pass over a network to make things happen.

When a protocol is specified at the wire-level and published, most technologies can use it, or be made to use it. Compare this to an API, where the actual implementation is specific to the platform.

JMS is an API. HTTP is a protocol. AMQP delivers the middleware equivalent of HTTP while leaving it up to others to provide implementations.

Q5: What do you mean by a 'standard protocol'?

A: We want to work to create a standard ratified by an official standards organization.

It is the AMQP Working Group's resolve to develop AMQP to the point where that is a practical thing to do.

For example, to qualify for an IETF RFC there needs to be at least two independent implementations built from the specifications that are proven to inter-operate.

Many of the Working Group members are involved in creating implementations of AMQP and the charter of the group has the objective to handover of specification to a standards body in due course.

Q6: How is this different from the Java Messaging Service (JMS)?

A: JMS is a de-facto API standard for store-and-forward and publish/subscribe messaging in Java.

JMS does not specify the implementation or the wire-level protocol. JMS is not technology agnostic and only legitimately supports Java platforms under the terms of its licensing (there will be a product which provides a JMS interface, but a JMS-like interface cannot legally be provided for non-Java platforms).

AMQP provides a superset of the semantics required to implement JMS, but also enables APIs for C, C++, Python, C# or any other language on Linux, Solaris, Windows, Z/OS, etc...

Q7: Are you going to specify an API too?

A: The AMQP Working Group is not initially focusing on standardizing an API for AMQP implementations.

It will be natural for programming environments to create API's onto AMQP which are natural for programmers of that environment; an API for Java is likely to look like JMS but an API for Python or COBOL may look quite different.

Despite being written to different API's, implementations which are AMQP compliant will inter-operate seamlessly - so a Java program could use a AMQP compliant JMS to communicate with a .NET program which is using a different API. That's an advantage of wire-level protocols.

Q8: How does AMQP relate to IBM MQSeries or Tibco Rendezvous?

A: MQSeries and Tibco Rendezvous are leading commercial middleware products with their own unique proprietary protocols and features. MQ Series and RV cannot natively interoperate with each other or other middleware products.

AMQP is a specification (not a product) that was created to enable interoperability between multiple integration broker implementations. AMQP is a protocol and a fairly complete specification for the most commonly used middleware functionality.

We do not expect companies with successful deployments of other technologies to abandon them for AMQP based solutions; but we do hope that companies will consider AMQP as a possible middleware strategy.

Any vendor is free to implement AMQP compatibility in their technologies if they choose to do so. See the license.

Q9: How is this related to Web Services?

A: AMQP can be used as a guaranteed transport for Web service calls - AMQP does not define the payload, just the transport layer, which means that SOAP, WS-Security, WS-Transactions, WS-MetaData Exchange, and so forth can all be run over AMQP in the same way that they can be used over JMS. However, AMQP provides vendor-neutral interoperability at the lowest levels of the transport link.

Q10: Where can I get an implementation of AMQP?

A: AMQP is a specification and not a product. Products are developed elsewhere by members of the Working Group or unaffiliated third parties.

See the AMQP Products page.

Q11: Is AMQP proven? Is anyone using AMQP?

A: It was a conscious aim of the Working Group to make the protocol relevant by creating inter-operable implementations, in multiple computer languages, for several platforms and by different entities prior to the initial release of the specification.

Only by testing and revising the specification against real requirements with different parties working together could the specification be rapidly matured. AMQP has been in design for more than two years with input from dozens of people from several companies.

By working in close partnership with other Working Group members JPMorgan has deployed an application which is using multiple implementations of AMQP.

One product is providing Java and .NET client access, another is providing C/C++ client and message broker functions on Linux, Solaris and Windows. The JPMorgan application uses AMQP to inform and transact with hundreds of simultaneous users around the globe via clustered AMQP broker deployments in three regional data centers.

The AMQP implementation has also been bridged to several legacy proprietary middleware products to ensure a smooth transition.

Note: That JPMorgan does not make any claim as to the performance of any product claiming to implement AMQP; see the license agreement.

Q12: How do I adopt AMQP in my organization?

A: We do not expect that existing, working middleware deployments would migrate to AMQP based solutions without a sound business justification - if it ain't broke don't fix it.

We expect that the most natural way for an organization to adopt AMQP in the normal course of business is to deploy it opportunistically as part of a considered strategy to move to standards-based middleware. This approach may enable an organization to benefit from competitively priced or open-source solutions and gain experience with the protocol and products which support it. Over the course of a few years much of your messaging may become AMQP enabled by following this approach. It is also possible that your current middleware supplier may adopt AMQP and enable your move to a standards based model in that way. We hope that AMQP will eventually be provided as a core service by your network infrastructure.

On the other hand, if a firm is embarking on a Service Oriented Architecture (or bus based architecture) we would suggest that an en-masse deployment of AMQP as the backbone of the SOA be considered. Doing so may position you to benefit from competition from suppliers of AMQP compatible middleware so you may achieve the levels of support and qualities of service you need from a suitable supplier. Deploying AMQP may also address the worrisome issue of vendor lock-in or supplier failure for the critical bus component of an SOA which is a long-term investment for your firm. This same thinking also applies where open protocols for e-business are being deployed between trading partners over the Internet or leased lines,

Of course, a firm's IT strategy must be determined by that firm alone; your circumstances will be unique and you must make your own evaluation and decisions regarding your middleware strategy.

Note: The AMQP Working Group cannot make any claim as to the performance of any product claiming to implement AMQP; see the license agreement.

Q13: What platforms will it support?

A: The protocol has been designed to be platform and protocol neutral.

It is expected that several of the firms represented in the Work Group will be releasing AMQP based products for a variety of platforms.

Q14: Why isn't company "X" involved in the AMQP Working Group?

A: Most of the major middleware suppliers are in some way aware of the AMQP project; and some have been offered the opportunity to be part of the effort. However, we were unable to approach everyone and not every company felt the need to participate at this time.

If you are a vendor and want to participate, please get in touch with us. Likewise, if you are an end-user of middleware and would like to see your favorite product support AMQP, then you might want to raise that requirement to your supplier.

Q15: How does AMQP relate to multicast?

A: We are working to specify multicast for subnet optimizations for cluster and grid distribution.

We envisage that AMQP will provide a clean way of reliably propagating of multicast messages between subnets. Transports like PGM may also provide an optimisation for transporting pub/sub AMQP messages within a subnet.

There is still work to be done but the desire is to have a well designed interoperability from PGM to AMQP and AMQP to PGM.

Q16: How is AMQP different from email?

A: The Emperors New Clothes - middleware and email are essentially the same thing!

AMQP is similar to email, but with fine control over the delivery quality of service (QoS).

Things that are ambiguous in email get defined in AMQP. For example, message size, reliability, security, discard policy, TTL, high speed group delivery, 1-of-N delivery, and so forth.

Importantly, unlike email, you have to authenticate to an AMQP system to send a message — hence there should be no spam-like messages, which is important for business messaging!

Q17: How is this different to Spread, or ICE or Elvin or TAO or Muscle or...?

A: There are many middleware software packages, and they address differing needs.

AMQP is not a software product, it is a documented protocol definition for messaging middleware.

AMQP as a protocol is also quite unique in its tight focus on the type of message exchange capabilities specifically required for highly reliable business messaging; as described elsewhere in the FAQ.

Q18: How is this different to CORBA/IIOP, DCE and ONC RPC?

A: CORBA/IIOP is a wire-level protocol for remote object invocation. You get a handle on an object and call a method. This is different from DCOM, where you get a handle on an ``interface`` (subtle), and ONC/RPC and DCE, where you get a handle on a process.

All of these are synchronous networked calls, and there is no notion of guarantee, or queuing, and little notion of QoS. Protocols like these have a place but they are incomplete on their own. IIOP also doesn't play nice with firewalls, which crop up frequently in real application scenarios.

AMQP is conceptually similar to the CORBA Notification Service & CORBA Event Service. However, there are few implementations of the Notification or Event services in part because of the complexity of the specifications and you need a full ORB to run it. This complexity is not amenable to wide spread adoption.

Finally, messaging is something that should be built under an object transport layer, not on top of it. Messaging is a more general idiom than object method invocation.

Q19: How can I see the Development of the Specification (or mail lists archives)?

A: Development lists are located here: https://amqp.108.redhat.com/servlets/SummarizeList?listName=dev