OASIS members & interested parties,
A new OASIS technical committee is being formed. The OASIS Advanced Message Queuing Protocol (AMQP) Technical Committee has been proposed by the members of OASIS listed in section 2.d of the charter below. The TC name, statement of purpose, scope, list of deliverables, audience, IPR mode and language specified in the proposal will constitute the TC’s official charter. Submissions of technology for consideration by the TC, and the beginning of technical discussions, may occur no sooner than the TC’s first meeting.
The eligibility requirements for becoming a participant in the TC at the first meeting are:
(a) you must be an employee of an OASIS member organization or an individual member of OASIS, and
(b) you must join the Technical Committee, which you may do by using the “Join this TC” button on the TC’s home page at http://www.oasis-open.org/committees/amqp/.
To be considered a voting member at the first meeting, you must:
(a) join the Technical Committee at least 7 days prior to the first meeting
(by 7 October 2011); and
(b) you must attend the first meeting of the TC, at the time and date fixed below
(14 October 2011).
Participants also may join the TC at a later time. OASIS and the TC welcomes all interested parties.
Non-OASIS members who wish to participate may contact us about joining OASIS. See http://www.oasis-open.org/join/. In addition, the public may access the information resources maintained for each TC: a mail list archive, document repository and public comments facility, which will be linked from the TC’s public home page at http://www.oasis-open.org/committees/amqp/.
Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your participation.
—
(1) Charter of the Technical Committee
(a) Name of the TC
OASIS Advanced Message Queuing Protocol (AMQP) Technical Committee (TC).
(b) Statement of Purpose
The purpose of the Advanced Message Queuing Protocol (AMQP) Technical Committee (TC) is to define an open internet protocol for business messaging. Salient business messaging requirements are:
– Ubiquity
– Open internet protocol standard supporting unencumbered (a) use, (b) implementation, and (c) extension.
– 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 to understand, use and implement.
– Fits into existing enterprise messaging applications environments in a practical way.
– Safety
– Infrastructure for a secure and trusted global transaction network.
– Consisting of business messages that are tamper-proof.
– Supporting message durability independent of receivers being connected, and
– Message delivery is resilient to technical failure.
– Supports business requirements to transport business transactions of any financial value.
– Sender and receiver roles are mutually agreed upon by counter parties – no possibility for injection of spam.
– Fidelity
– Well-stated message queuing and delivery semantics covering: at-most-once; at-least-once; and once-and-only-once aka ‘reliable’.
– Well-stated message ordering semantics describing what a sender can expect (a) a receiver to observe and (b) a queue manager to observe.
– Well-stated reliable failure semantics so all exceptions can be managed.
– Applicability
– As TCP subsumed all technical features of networking, we aspire for AMQP to be the prevalent business messaging technology (tool) for organizations so that with increased use, ROI increases and TCO decreases.
– Any AMQP client can initiate communication with, and then communicate with, any AMQP broker over TCP.
– 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.
– Provides the core set of messaging patterns via a single manageable protocol: asynchronous directed messaging, request/reply, publish/subscribe, store and forward.
– Supports hub and spoke messaging topology within and across business boundaries.
– 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.
– Interoperability
– 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.
– Stable extended (broker-broker) wire protocol so that brokers do not require upgrade during 1.x feature evolution: Any two broker versions 1.x, 1.y can communicate using protocol 1.x if x<y.
– Layered architecture, so features & network transports can be independently extended by separated communities of use, enabling business integration with other systems.
– Manageability
– 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).
– Scalable, so that it can be a basis for high performance fault-tolerant lossless messaging infrastructure, i.e. without requiring other messaging technology.
– Interaction with the message delivery system is possible, sufficient to integrate with prevailing business operations that administer messaging systems using management standards.
– Intermediated: supports routing and relay management, traffic flow management and quality of service management.
– Decentralized deployment with independent local governance.
– Global addressing standardizing end to end delivery across any network scope.
(c) Scope of Work
The TC will accept as input the v1.0 Final version of the AMQP wire level protocol specification [1] and will produce an OASIS Standard version including necessary XML renderings.
Features of the AMQP wire protocol specification [1] include:
– Types – A wire-efficient encoding system involving:
– "Primitive" type encodings for basic types present in most programming languages
– "Described" type encodings consisting of descriptor and Primitive type for user defined custom types
– Format codes for fixed width, variable width, compound, and array type data categories
– Composite types (encoded either as a described list or a described map) for encoding structured data such as frame bodies
– Transport – A layered, peer-to-peer transport protocol involving:
– The following entities:
– Nodes as named entities for the safe storage/delivery of messages
– Containers as named entities containing one or more Nodes
– Unidirectional Links between Nodes, over which messages flow
– Links over bidirectional Sessions
– Sessions consisting of two unidirectional Channels flowing in opposing directions
– Channels over Connections
– Connections providing connectivity between two Containers
– Frames for carrying data over Connections.
– Protocol version negotiation
– Connection operation including opening, pipelined open, pipelining, closing, simultaneous close, and other connection management mechanisms
– Session operation including establishing, ending, simultaneous ending, session flow control, session errors, and other session management mechanisms
– Link operation including naming, establishing, resuming, detaching, reattaching, closing, flow control, synchronous get, asynchronous notification, stopping, link errors, and other link management mechanisms
– Message operation including sections, fragments, transfers, resuming, and large message transfer.
– Messaging – Providing interoperable messaging capabilities involving:
– Message formatting, transfer states, message states, message states at distribution nodes, and behavior at sources and targets
– Transactions – Coordination, operation, and error handling of transactions
– Local transactions
– Multiple transactions per Session
– Transaction over multiple Sessions
– Security – Ability to establish an authenticated and/or encrypted transport
– Use of AMQP in a TLS environment
– Use of AMQP in a SASL environment
The scope of work for the OASIS Standard version of the AMQP wire protocol specification is limited to:
– Technical refinements to features defined in v1.0 Final version of the AMQP wire level protocol specification [1] arising from demonstrable interoperability problems.
– Non-technical changes aimed at improving quality of the input specification such as better documentation.
The TC shall conduct business as described in the OASIS Technical Committee Process and will take advantage of the services provided by OASIS, including e-mail lists and archives, and web servers for tracking progress. E-mail archives will be visible to the public.
Out of scope:
Any work not mentioned in the Scope of Work section is deemed to be out of scope. Contributions to this TC which are out of scope for this charter may be accumulated and taken into consideration for potential development of a charter for another technical committee that may be created to address future extensions or modifications.
(d) Deliverables
The TC shall produce the OASIS Standard version of the v1.0 AMQP wire level protocol specification before July 2012. Following that, the TC may advance the OASIS Standard version of the AMQP wire level protocol specification to ISO/IEC JTC 1 through the JTC 1 PAS Transposition Process.
Maintenance:
Once the TC has successfully produced the deliverables, the TC will enter into a maintenance mode.
The purpose of the maintenance mode is to provide minor revisions to previously adopted deliverables, in order to clarify ambiguities, inconsistencies, and obvious errors. The maintenance mode will not functionally enhance a previously adopted deliverable, or extend its functionality.
The TC will collect issues raised against the deliverables and periodically process those issues. Issues that require extended or enhanced functionality shall be recorded and set aside for potential development of a charter for another technical committee that may be created to address them. Issues that result in the clarification or non-substantive correction of the deliverables shall be processed. The TC shall maintain a list of the adopted clarifications and shall create a new minor revision of the deliverables incorporating those
adopted clarifications.
(e) IPR Mode
This TC will operate under RF on RAND Terms IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy effective 15 October 2010.
(f) Anticipated Audience
The anticipated audience for this work includes:
– Business messaging users
– Business messaging middleware vendors
(g) Language
TC business will be conducted in English.
References
[1] Advanced Message Queuing Protocol (AMQP) v1.0 Final https://www.amqp.org/resources/download – This link contains the latest version; the final version is expected soon.
(2) Non-normative information regarding the startup of the TC
(a) Similar Work
Some of the existing messaging protocol standards include ebXML, Web Services Reliable Exchange (WS-RX), and XMPP.
Some of the defining characteristics of AMQP as compared to those protocols are:
– It is a binary protocol that operates directly over TCP (instead of over HTTP).
– It incorporates efficient binary encodings of the protocol (as opposed to XML).
Some of the general characteristics of AMQP are:
– It is API agnostic, but has been designed for integration into existing mainstream messaging and integration technologies including Java Message Service and Microsoft Windows Communication Foundation, so that interoperability between them is possible.
– It has been designed to be used with a broker; providing a safe place to exchange messages with 3rd party systems, and to store and forward messages when the recipient is unavailable.
– It brings together frequently used combinations of message exchange patterns in one protocol (asynchronous publish/subscribe and direct delivery patterns such as queuing) that incorporates message level flow control.
In summary, AMQP sets out to provide efficient, high performance, internet scale business messaging. This translates into: a reliable binary transport for sending and receiving messages over WAN and LAN, that integrates with existing messaging products, but can scale to the needs of modern environments such as "cloud applications".
(b) Date, Time, and Location of First Meeting
The first meeting of the AMQP TC will be a face-to-face meeting to be held in New York on October 14, 2011 from 9 AM ET to 5 PM ET. This meeting will be sponsored by JPMorgan Chase Bank N.A.
(c) On-Going Meeting Plans & Sponsors
It is anticipated that the AMQP TC will meet via teleconference every week for 60 minutes at a time determined by the TC members during the TC's first meeting. It is anticipated that the AMQP TC will meet face-to-face every 2-3 months at a time and location to be determined by the TC members. The actual pace of face-to-face and teleconference meetings will be determined by TC members. One of the proposers, as listed below, will sponsor the teleconferences unless other TC members offer to donate their own facilities.
(d) Proposers of the TC
John O’Hara, john.ohara1@baml.com, Bank of America
Abbie Barbir, abbie.barbir@bankofamerica.com, Bank of America
Andreas Moravec, andreas.moravec@deutsche-boerse.com, Deutsche Börse AG
Hanno Klein, hanno.klein@deutsche-boerse.com, Deutsche Börse AG
Andreas Mueller, am@iit.de, IIT Software GmbH
Matthew Arrott, marrott@novgp.com, Individual Member
Bijan Sanii, bijans@inetco.com, INETCO Systems Ltd.
Angus Telfer, angus.telfer@inetco.com, INETCO Systems Ltd.
Allan Cornish, acornish@inetco.com, INETCO Systems Ltd.
Allan Beck, allan.beck@jpmorgan.com, JPMorgan Chase Bank N.A
Robert X. Godfrey, robert.godfrey@jpmorgan.com, JPMorgan Chase Bank N.A
Laurie M. Bryson, laurie.m.bryson@jpmorgan.com, JPMorgan Chase Bank N.A
John Fallows, john.fallows@kaazing.com, Kaazing
Brian Albers, brian.albers@kaazing.com, Kaazing
David Ingham, david.ingham@microsoft.com, Microsoft
Ram Jeyaraman, ram.jeyaraman@microsoft.com, Microsoft
Xin Chen, xinchen@microsoft.com, Microsoft
Alexandros Kritikos, alex.kritikos@my-channels.com, my-Channels
Colin MacNaughton, cmacnaug@progress.com, Progress Software
Jaime Meritt, jmeritt@progress.com, Progress Software
Carl Trieloff, cctrieloff@redhat.com, Red Hat
Gordon Sim, gsim@redhat.com, Red Hat
Mark Little, mlittle@redhat.com, Red Hat
Rafael Schloming, rafaels@redhat.com, Red Hat
Prasad Yendluri, prasad.yendluri@softwareag.com, Software AG
Ross Cooney, ross.cooney@stormmq.com, StormMQ Limited
Raphael Cohn, raphael.cohn@stormmq.com, StormMQ Limited
Winston Bumpus, wbumpus@vmware.com, VMware, Inc.
Alexis Richardson, arichardson@vmware.com, VMware, Inc.
Adrian Colyer, acolyer@vmware.com, VMware, Inc.
Paul Fremantle, paul@wso2.com, WSO2
(e) Statement of Support
Abbie Barbir, abbie.barbir@bankofamerica.com, Bank of America – As the OASIS Primary Representative for Bank of America, I am pleased to offer our support for the creation of the OASIS AMQP Technical Committee.
Andreas Moravec, andreas.moravec@deutsche-boerse.com, Deutsche Börse AG – As the Primary Representative for Deutsche Börse AG, I am pleased to offer our support for the creation of this Technical Committee.
Andreas Mueller, am@iit.de, IIT Software GmbH – As the Primary Representative for IIT Software GmbH, I am pleased to offer our support for the creation of this Technical Committee.
Angus Telfer, angus.telfer@inetco.com, INETCO Systems Ltd. – As the Primary Representative for INETCO, I am pleased to offer our support for the creation of this Technical Committee.
Allan Beck, allan.beck@jpmorgan.com, JPMorgan Chase Bank N.A – As the Primary Representative for JPMorgan Chase Bank, I am pleased to offer our support for the creation of this Technical Committee.
John Fallows, john.fallows@kaazing.com, Kaazing – As Primary Representative for Kaazing, I am pleased to offer our strong support for the creation of this Technical Committee.
Ram Jeyaraman, ram.jeyaraman@microsoft.com, Microsoft – As the Primary Representative for Microsoft, I am pleased to offer our support for the creation of this Technical Committee.
Alexandros Kritikos, alex.kritikos@my-channels.com, my-Channels – As the Primary Representative for my-Channels, I am pleased to offer our support for the creation of the OASIS AMQP Technical Committee.
Jaime Meritt, jmeritt@progress.com, Progress Software – As the Primary Representative for Progress Software, I am pleased to offer our support for the creation of the OASIS AMQP Technical Committee.
Mark Little, mlittle@redhat.com, Red Hat – As the Primary Representative for Red Hat, I offer our support for the creation of this Technical Committee.
Prasad Yendluri, prasad.yendluri@softwareag.com, Software AG – As the Primary Representative for Software AG, I am pleased to offer our support for the creation of this Technical Committee.
Ross Cooney, ross.cooney@stormmq.com, StormMQ Limited – As the Primary Representative for StormMQ Limited, I am pleased to offer our support for the creation of this Technical Committee.
Winston Bumpus, wbumpus@vmware.com, VMware, Inc. – As Primary Representative for VMware, Inc., I am pleased to offer our strong support for the creation of this Technical Committee.
Paul Fremantle, paul@wso2.com, WSO2 – As Primary Representative for WSO2, I am pleased to offer WSO2's strong support for the creation of this Technical Committee.
(f) TC Convener
The TC Convener for the first meeting will be Angus Telfer from INETCO Systems Ltd.
(g) Affiliation to Member Section
It is intended that the AMQP TC will be affiliated with the AMQP Member Section.
(h) List of anticipated contributions
Advanced Message Queuing Protocol (AMQP) v1.0 Final https://www.amqp.org/resources/download – This link contains the latest version; the final version is expected soon.
(i) Frequently Asked Questions (FAQ) relating to the planned scope of the TC
None
(j) Proposed working title and acronym for the specification(s) to be developed by the TC
Proposed title of the specification: Advanced Message Queuing Protocol
Proposed acronym of the specification: AMQP