[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oasis-charter-discuss] OASIS Advanced Message Queuing Protocol (AMQP) Technical Committee
FWIW, The submissions policy (currently found in the Liaison Policy)
requires an interoperability demonstration, though OASIS staff has
proposed eliminating that requirement.
Also, FWIW, regardless of what the TC Charter says -- the submissions
policy outlines the steps required to submit to JTC1 (or any other
body). Under those rules, the TC can request that happens --
regardless whether the Charter says it may, so that statement in the
charter, while it may help to set expectations about what the
proposers of the charter would like to see happen, are essentially
meaningless. I.E. they neither allow nor prohibit the TC from taking
action.
My suggestion would be to change the words in the Charter to conform
to official OASIS policy and to state the intention.
cheers,
jeff
On Aug 11, 2011, at 7:34 AM, Martin Chapman wrote:
> I note that under deliverables it states:
>
> "...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."
>
> Yet this charter does not mention anything about testing. One would
> hope that some testing deliverables are planned before going to OS
> and proceeding to JTC1!
> I would like to see the charter elaborate on this topic please.
>
> Cheers,
> Martin.
>
>> -----Original Message-----
>> From: Chet Ensign [mailto:chet.ensign@oasis-open.org]
>> Sent: 10 August 2011 18:41
>> To: tc-announce@lists.oasis-open.org; oasis-charter-discuss@lists.oasis-
>> open.org; members@lists.oasis-open.org
>> Cc: Staff; oasis-board-comment@lists.oasis-open.org; OASIS TAB
>> Subject: [oasis-charter-discuss] 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: oasis-charter-discuss@lists.oasis-open.org. 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, 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
>>
>>
>> --
>>
>> /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
>>
>> ---------------------------------------------------------------------
>> 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
>>
>
> ---------------------------------------------------------------------
> 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
>
--
Jeff Mischkinsky jeff.mischkinsky@oracle.com
Sr. Director, Oracle Fusion Middleware +1(650)506-1975
and Web Services Standards 500 Oracle Parkway, M/S 2OP9
Oracle Redwood Shores, CA 94065
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]