- Q1: Why are you doing this?
- Q2: How will the AMQP work be licensed?
- Q3: Can I implement AMQP commercially, as open source, in hardware, etc?
- Q4: How does AMQP relate to IBM MQSeries or Tibco Rendezvous?
- Q5: How is this related to Web Services?
- Q6: Which application Use Cases does AMQP support?
- Q7: Where can I get an implementation of AMQP?
- Q8: Is AMQP proven? Is anyone using AMQP?
- Q9: How do I adopt AMQP in my organization?
- Q10: Why isn't company "X" involved in the AMQP Working Group?
- Q11: How is AMQP different from email?
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.
AMQP provides solutions to these problems in the form of a freely-licensed protocol specification intended to enable implementations from any number of sources to address the most common business messaging requirements.
A: Deliverables of the OASIS AMQP Technical Committee are produced under the Royalty-Free on RAND Mode of the OASIS IPR Policy.
Versions of AMQP that were formally published by the former AMQP Working Group are unencumbered. All the rights necessary to effectively use or implement the protocol are freely granted.
Anyone may freely implement any Published Specification version in software or hardware without prior permission, provided that they comply with the terms of the license. You should state which version(s) of the specifcation your implementation supports.
Yes. We encourage both commercial and open source implementations of AMQP, in software, hardware or embedded in other services and solutions. We encourage distribution of implementations in source or binary forms and we encourage the bundling and distribution of AMQP as part of operating systems and other infrastructure. The AMQP License enables this.
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.
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.
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.
A: AMQP is a specification and not a product. Products are developed elsewhere by OASIS AMQP members or unaffiliated third parties.
See the AMQP Products page.
A: Interoperable implementations of AMQP were created 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.
By working in close partnership with other AMQP 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.
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: OASIS AMQP cannot make any claim as to the performance of any product claiming to implement AMQP; see the license agreement.
A: Participation in OASIS AMQP is open to all interested parties. Contact email@example.com for more information.
If you want to participate, please get in touch with us. 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.
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!