Developer FAQ's

Q1: Can I use the AMQP XML files to generate code; can I ship those as part of the source code?

A: Some of the AMQP Specifications are in the form of XML, and designed to assist the creation of implementations.

We encourage people to copy, excerpt and distribute the XML as needed to make it usable in your chosen implementation technology. If you are shipping source code as part of an open source distribution or if your implementation uses the XML at runtime, that is also encouraged.

Q2: What standards body will you hand AMQP over to and when?

A: This is a topic which is under active discussion in the Working Group. The transition will not be sooner than the finalisation of AMQP 1.0.

Q3: 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.

Q4: 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.

Q5: 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...

Q6: 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.

Q7: 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.

Q8: 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.

Q9: 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.

Q10: 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.

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

A: Development lists are located within the OASIS AMQP Technical Committee.

Q12: How can I contribute?

A: Join OASIS and then join the OASIS AMQP Technical Committee.