← Prev in month
← Prev in thread
Next in thread →
Next in month →
Re: [oasis-charter-discuss] RE: [members] OASIS Advanced MessageQueuing Protocol (AMQP) Technical Committee
Jacques Regarding the ability to produce an implementably interoperable specification: the planned input specification is already being tested for interoperability with a set of "connectathons", with the specific aim of testing whether the specification stands up to this test. With regards to the timetable: yes - this is a very aggressive timetable, but we know that this is an aim and the reality is that it will become an OASIS standard if and only if it is ready and meets OASIS's requirements. The participants who have worked in the open on this specification for the past 5 years believe that the input specification will stand up well to the OASIS standardization process but of course that is just a prediction. With regard to other organizations: are there external organizations or TCs that you believe that this TC should be liaising with? Best Paul On 11 August 2011 21:08, Jacques Durand <> wrote: About AMQP charter: The timeline sounds rather optimistic: "The TC shall produce the OASIS Standard version of the v1.0 AMQP wire level protocol specification before July 2012." Does that mean the Candidate OS must be ready for PR before July 2012? Or the OS be approved by then? Must be clarified. In all cases, that means at the latest a CSD that is considered final (candidate CS then OS) must be produced in April 2012 then go in first PR. For a TC that aims at rebuilding the entire messaging stack on top of TCP, and given the ambitious statement of purpose (while AMQP initial draft reads in many places more like a requirements doc), 6 months of work sounds rather short. Also it is unclear if the resulting spec will be sufficient to build interoperable message handlers/brokers. As a vendor, I would expect the final AMQP specification to contain and/or refer to all the technical information necessary for implementing an interoperable AMQP broker or client, i.e. where the only potential interoperability issues are expected to be those related to diverging interpretations of feature details in the standard, or minor under-specifications. But it is not clear if AMQP TC is committed to provide that level of detail. Also the TC does not seem to plan to liaise with any other TC or external org. Regards, Jacques Durand TAB member, Fujitsu -----Original Message----- From: Chet Ensign [mailto:] Sent: Wednesday, August 10, 2011 10:41 AM To: ; ; Cc: Staff; ; OASIS TAB Subject: [members] OASIS Advanced Message Queuing Protocol (AMQP) Technical Committee To OASIS Members: A draft TC charter has been submitted to establish the OASIS Advanced Message Queuing Protocol (AMQP) Technical Committee (below). In accordance with the OASIS TC Process Policy section 2.2: (http://www.oasis-open.org/committees/process-2009-07-30.php#formation) the proposed charter is hereby submitted for comment. The comment period shall remain open until 11:45 pm ET on 24 August 2011. OASIS maintains a mailing list for the purpose of submitting comments on proposed charters. Any OASIS member may post to this list by sending email to: . All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive emails must join the group by selecting "join group" on the group home page: http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/. Employees of organizational members do not require primary representative approval to subscribe to the oasis-charter-discuss e-mail. A telephone conference will be held among the Convener, the OASIS TC Administrator, and those proposers who wish to attend within four days of the close of the comment period. The announcement and call-in information will be noted on the OASIS Charter Discuss Group Calendar. We encourage member comment and ask that you note the name of the proposed TC ("AMQP") in the subject line of your email message. === (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, , Bank of America Abbie Barbir, , Bank of America Andreas Moravec, , Deutsche Börse AG Hanno Klein, , Deutsche Börse AG Andreas Mueller, , IIT Software GmbH Matthew Arrott, , Individual Member Bijan Sanii, , INETCO Systems Ltd. Angus Telfer, , INETCO Systems Ltd. Allan Cornish, , INETCO Systems Ltd. Allan Beck, , JPMorgan Chase Bank N.A Robert X. Godfrey, , JPMorgan Chase Bank N.A Laurie M. Bryson, , JPMorgan Chase Bank N.A John Fallows, , Kaazing Brian Albers, , Kaazing David Ingham, , Microsoft Ram Jeyaraman, , Microsoft Xin Chen, , Microsoft Alexandros Kritikos, , my-Channels Colin MacNaughton, , Progress Software Jaime Meritt, , Progress Software Carl Trieloff, , Red Hat Gordon Sim, , Red Hat Mark Little, , Red Hat Rafael Schloming, , Red Hat Prasad Yendluri, , Software AG Ross Cooney, , StormMQ Limited Raphael Cohn, , StormMQ Limited Winston Bumpus, , VMware, Inc. Alexis Richardson, , VMware, Inc. Adrian Colyer, , VMware, Inc. Paul Fremantle, , WSO2 (e) Statement of Support Abbie Barbir, , 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, , 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, , 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, , 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, , 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, , Kaazing - As Primary Representative for Kaazing, I am pleased to offer our strong support for the creation of this Technical Committee. Ram Jeyaraman, , Microsoft - As the Primary Representative for Microsoft, I am pleased to offer our support for the creation of this Technical Committee. Alexandros Kritikos, , 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, , 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, , Red Hat - As the Primary Representative for Red Hat, I offer our support for the creation of this Technical Committee. Prasad Yendluri, , 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, , 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, , 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, , 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 -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn: http://linkd.in/OASISopen Twitter: http://twitter.com/OASISopen Facebook: http://facebook.com/oasis.open --------------------------------------------------------------------- This email list is used solely by OASIS for official consortium communications. Opt-out requests may be sent to , however, all members are strongly encouraged to maintain a subscription to this list. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair, VP, Apache Synapse UK: +44 207 096 0336 US: +1 646 595 7614 blog: http://pzf.fremantle.org twitter.com/pzfreo http://freo.me/wso2con11 wso2.com Lean Enterprise Middleware Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.
← Prev in month
← Prev in thread
Next in thread →
Next in month →