OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tc-announce message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Call for Participation: Rechartered Advanced Message Queuing Protocol (AMQP) TC

OASIS members and interested parties, 

The OASIS Advanced Message Queuing Protocol (AMQP) Technical Committee has approved [1] a revised charter, included below. The TC name, statement of purpose, scope, list of deliverables, audience, IPR mode and language specified in the revision below will constitute the TC's official charter. A red-lined version of the charter showing the revisions from the original is attached to this message. 

The TC will hold its first meeting under the revised charter on 20 November 2012 at 08:00 Pacific time. Submissions of technology for consideration by the TC, and the beginning of technical discussions, may begin no sooner than this first meeting.

OASIS and the TC welcome participation by all interested parties. 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 after the revised charter is published to the TC's home page on 13 November 2012, which members may do by using the Roster "join group" link on the TC's home page at [2].

Note that everyone who wishes to participate must explicitly join the TC as described in (b) above. Membership under the original charter does not automatically carry over. 

Non-OASIS members who wish to participate may contact us about joining OASIS [3]. Instructions for joining the Technical Committee can be found at the "Join This TC" link on the TC's public home page [4]  

Please feel free to forward this announcement to any other appropriate lists. OASIS is an open standards organization; we encourage your participation in our work.

[1] recharter ballot: 

[2] TC web page:

[3] https://www.oasis-open.org/join

[4] https://www.oasis-open.org/committees/amqp

--- Revised Charter

(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 OASIS Standard versions of the AMQP core specification [2] including necessary XML renderings.
Features of the AMQP core specification [2] 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 TC will also accept technical contributions on extensions to the AMQP core specification [2] and produce OASIS Standard versions of the same, including necessary XML renderings.

A core extension defines semantics of AMQP endpoints not previously defined by the AMQP core specification. Extensions may be defined in the form of dedicated endpoints, addresses or defined message formats. Extensions must not require the creation of new performatives in the AMQP core transport. The availability or otherwise of a given extension must be expressed through the use of the extension capability mechanisms defined in the AMQP core specification.

Examples of core extensions may include, but are not limited to:

  - Distributed transactions - support for the coordination of AMQP messaging transactions by an external transaction coordinator.
  - Global addressing - definition of a URI-based addressing scheme and messaging forwarding semantics to enable a global message delivery network.
Out of scope:  Any work not reasonably covered by the Scope of Work section is deemed to be out of scope. Bindings of the AMQP core protocol to alternative transports and mapping from programming language APIs to the AMQP core protocol are deemed to be out of scope and are expected to be covered by a separate TC. 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 will produce OASIS Standard versions of the AMQP core specification, and core extension specifications, and may then advance them to ISO/IEC JTC 1 through the JTC 1 PAS Transposition Process. The TC expects to produce the OASIS Standard version of some of those specifications by December 2013.
The TC will maintain previously adopted deliverables and provide minor revisions of those deliverables, in order to clarify ambiguities, inconsistencies, and obvious errors.
(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 21 June 2012.
(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.

[1] Advanced Message Queuing Protocol (AMQP) v1.0 Final

[2] OASIS AMQP Version 1.0 Specification http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf.

(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 TC will be held by teleconference on Nov 20, 2012 during 8-9am PT. This meeting will be sponsored by Microsoft. 

(c) On-Going Meeting Plans & Sponsors
It is anticipated that the TC will meet weekly via teleconference and if needed meet face-to-face every 2-3 months at a time and location to be determined by the TC members. At its first meeting, the TC will setup an on-going meeting schedule and determine who will sponsor these meetings.
(d) Proposers of the TC
(e) Statement of Support
(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 continue its affiliation with the AMQP Member Section.
(h) List of anticipated contributions
(i) Frequently Asked Questions (FAQ) relating to the planned scope of the TC
(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

Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society

Primary: +1 973-996-2298
Mobile: +1 201-341-1393

Attachment: AMQP-revised-charter-redline.pdf
Description: Adobe PDF document

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]