AMQP 1.0 Business Requirements - Revised
The table below represents Alexis's proposed refinements and clarifications of the 1.0 Business Requirements that were voted in on July 2nd, 2008. Alexis was not available during the period of comment prior to the vote due to vacation. Matthew worked directly with Alexis to capture these revisions based on the direction of the PMC given on June 25th, 2008.
| Release | Requirement | |
|---|---|---|
| Ubiquitous & Pervasive | UBIQUITOUS AND PERVASIVE | |
| 1.0 | Open standard supporting unencumbered use, implementation and extension | Open internet protocol standard supporting unencumbered (a) use, (b) implementation, and (c) extension by independent RFCs |
| 1.0 | Clear and unambiguous core functionality for business message delivery | Clear and unambiguous core functionality for business message routing and delivery within Internet infrastructure - so that business messaging is provided by infrastructure and not by integration experts |
| Low barrier (opportunity cost) to understand, use and implement | ||
| 1.0 | Fits into existing enterprise messaging applications environments (e.g., Tibco, MQ, JMS) | Fits into existing enterprise messaging applications environments in a practical way (e.g., Tibco, MQ, JMS, FIX) |
| Safety | SAFETY | |
| 1.0 | Secure and trusted global transaction network
|
Infrastructure for a secure and trusted global transaction network
|
| 1.0 | Supports business requirements to transport business transactions of any financial value | Supports business requirements to transport business transactions of any financial value |
| 1.1 | Sender and Receiver are mutually agreed upon counter parties - No possibility for injection of Spam | Sender and Receiver are mutually agreed upon counter parties - No possibility for injection of Spam |
| Fidelity | FIDELITY | |
| 1.0 | Well-stated reliable delivery semantics covering at-most-once, at-least-once, and once-and-only-once | Well-stated message queueing and delivery semantics covering: at-most-once; at-least-once; and once-and-only-once aka 'reliable' |
| 1.0 | Well-stated reliable message ordering semantics | Well-stated message ordering semantics describing what a sender can expect (a) a receiver to observe and (b) a queue manager to observe |
| 1.0 | Well-stated reliable failure semantics so all exception can be managed | Well-stated reliable failure semantics so all exceptions can be managed |
| Unified | UNIFIED |
|
| As TCP subsumed all technical features of networking, AMQP aspires to be the sole business messaging technology (tool) for organizations so that with increased use, ROI increases and TCO decreases |
||
| 1.0 | Communicates universally over TCP | Any AMQP client can initiate communication with, and then communicate with, any AMQP broker over TCP |
| 1.1 | Negotiate communication over alternate transport protocols (e.g., SCTP, UDP/Multicast, SCMP, etc.) | Any AMQP client can request communication with, and if supported negotiate the use of, alternate transport protocols (e.g. SCTP, UDP/Multicast), from any AMQP broker |
| 1.0 | Provides the core set of message exchange patterns - asynchronous messaging, request/reply, pub/sub | Provides the core set of messaging patterns via a single manageable protocol: asynchronous directed messaging, request/reply, publish/subscribe, store and forward |
| 1.0 | Supports Hub & Spoke messaging topology within and across business boundaries |
Supports Hub & Spoke messaging topology within and across business boundaries |
| 1.1 | Supports Hub to Hub message relay across business boundaries through enactment of explicit agreements between broker authorities |
Supports Hub to Hub message relay across business boundaries through enactment of explicit agreements between broker authorities |
| Supports Peer to Peer messaging across any network | ||
| Interoperable |
INTEROPERABILITY | |
| 1.0 | Multiple stable implementations from independent providers (minimum 2, desirable 3) |
Multiple stable and interoperating broker implementations each with a completely independent provenance including design, architecture, code, ownership (minimum 2, desirable 3) |
| 1.0 | Globally conformant for the core message exchange and queuing functionality | Each broker implementation is conformant with the specification, for all mandatory message exchange and queuing functionality, including fidelity semantics |
| 1.0 | Implementations independently testable and verifiable | Implementations are independently testable and verifiable by any member of the public free of charge |
| 1.0 | Stable client-broker wire protocol ensuring forward compatibility during client feature evolution |
Stable core (client-broker) wire protocol so that brokers do not require upgrade during 1.x feature evolution: Any 1.x client will work with any 1.y broker if y >= x |
| 1.1 | Stable broker-broker wire protocol ensuring forward compatibility during all feature evolution | Stable extended (broker-broker) wire protocol so that brokers do not require upgrade during 1.x feature evolution: Any two brokers versions 1.x, 1.y can communicate using protocol 1.x if x<y |
| 1.0 | Features & network transports extendable by independent communities of use | Layered architecture, so features & network transports can be independently extended by separated communities of use, enabling business integration with other systems without coordination with the AMQP PMC |
| Scalable and Managed |
MANAGEABLE | |
| 1.0 | Binary WIRE protocol so that it can be ubiquitous, fast, embedded (XML can be layered on top) | Binary WIRE protocol so that it can be ubiquitous, fast, embedded (XML can be layered on top), enabling management to be provided by encapsulating systems (e.g. O/S, middleware, phone) |
| 1.0 | High performance fault-tolerant lossless messaging infrastructure |
Scalable, so that it can be a basis for high performance fault-tolerant lossless messaging infrastructure, i.e without requiring other messaging technology |
| 1.x | Supports enactment of entitlements at all levels of interaction with the message delivery system | Interaction with the message delivery system is possible, sufficient to integrate with prevailing business operations that administer messaging systems using management standards. |
| 1.x | Supports traffic flow management, quality of service | Intermediated: supports routing and relay management, traffic flow management and quality of service management |
| 1.x | Decentralized deployment with independent local governance | Decentralized deployment with independent local governance |
| 1.1 | Global addressing standardizing end to end delivery across any network scope |
Global addressing standardizing end to end delivery across any network scope (yes but this will break wire protocol??) |