[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: OASIS TC Call for Participation: OASIS Web Services Reliable Exchange (WS-RX) TC
A new OASIS technical committee is being formed. The OASIS Web
Services Reliable Exchange (WS-RX) Technical Committee has been proposed by
the members of OASIS listed below. The proposal (below) meets the
requirements of the OASIS TC Process [1]. The TC name, statement of
purpose, scope, list of deliverables, audience, 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.
This TC will operate under our 2005 IPR Policy.[2] The eligibility
requirements for becoming a participant in the TC at the first meeting (see
details below) are that:
(a) you must be an employee of an OASIS member organization or an
individual member of OASIS;
(b) the OASIS member must sign the OASIS membership agreement (see [3]);
(c) you must notify the TC chair of your intent to participate at
least 15 days prior to the first meeting, which members may do by using the
"Join this TC" button on the TC's public page at [4]; and
(d) you must attend the first meeting of the TC, at the time and date
fixed below.
Of course, it also will be possible to join the TC at a later time.
Standards always are improved by broad participation. Non-OASIS
members who wish to participate may contact us about joining OASIS
[3]. Our rules and structure are designed to promote inclusiveness. We
look forward to assisting parties interested in joining the community of
implementers, technologists, academics and end-users working on OASIS
standardization projects. All also are welcome to take advantage of the
public resources maintained for each TC: a mail list archive, document
repository and public comments facility, all of which will be available via
the TC's public home page at [4]. Archives of the TC's mail list and public
comment lists, as with all OASIS TCs, will be visible at [5].
Further information generally related to the topic may be found on the
Cover Pages at http://xml.coverpages.org/reliableMessaging.html.
Please feel free to forward this announcement to any other appropriate
lists. OASIS is an open standards organization; we encourage your
feedback. JBC
~ James Bryce Clark
~ Director, Standards Development, OASIS
~ jamie.clark@oasis-open.org
[1] http://oasis-open.org/committees/process.shtml
[2] http://www.oasis-open.org/who/intellectualproperty.php
[3] See http://www.oasis-open.org/join/
[4] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx
[5] http://lists.oasis-open.org/archives/
====
1. TC Charter:
Name
OASIS Web Services Reliable Exchange Technical Committee (WS-RX)
Purpose
The purpose of the OASIS Web Services Reliable Exchange (WS-RX)
Technical Committee (TC) is to define a protocol for reliable message
exchanges between two Web services, through continued development of the
Web Services Reliable Messaging specification [1] submitted to the TC as
referenced in this charter and to define a mechanism by which Web services
express support for reliable messaging as well as other related useful
parameters. This mechanism will be based upon the Web Services Reliable
Messaging Policy Assertion ("WS-RM Policy") specification [2] submitted to
the TC.
Scope
The TC will accept as input the February 2005 Version 1.0 of the WS-
ReliableMessaging [1] and WS-RM Policy [2] specifications (the Input
Documents) from BEA Systems, IBM, Microsoft, and TIBCO Software. Other
contributions and changes to the input documents will be accepted for
consideration without any prejudice or restrictions and evaluated based on
technical merit in so far as they conform to this charter. OASIS members
with extensive experience and knowledge in these areas are particularly
invited to participate.
The scope of the TC's work is to continue development and refinement
of the input documents to produce as output modular specifications that
standardize the concepts, WSDL documents and XML schema renderings required
to provide reliability assurances to message exchanges between two parties
that conform to the specifications.
Reliable messaging systems can generally be described using a four
agent model. In this model there is an Application Source, a Reliable
Messaging Source that acts on behalf of the Application Source, an
Application Destination and a Reliable Messaging Destination that acts on
behalf of the Application Destination. Message Transfer is the function of
moving messages from a Reliable Message Source to a Reliable Messaging
Destination. This TC will provide protocols for the reliable message
transfers that occur between Reliable Messaging Sources and Reliable
Messaging Destinations. The TC will not develop additional mechanisms by
which a Reliable Messaging Source captures messages from an Application
Source or mechanisms by which a Reliable Messaging Destination delivers
messages to an Application Destination.
A reliable message transfer is one in which certain reliability
assurances exist between two parties even in the presence of a variety of
failures. There can be multiple, concurrent and independent reliable
exchanges between two parties. Reliability assurances make statements about
the type of reliability provided to a message exchange.
The specifications will define a set of basic concepts required for
the correct functioning of message exchanges with reliability assurances.
The specifications will render these concepts as a specific set of
restrictions over SOAP messages including XML schemas and WSDL documents.
The specific reliability assurances in the scope of the TC are:
-- At Least Once: Messages are transferred at least one time or an
error is raised on at least one of the endpoints. It is possible that some
messages are transferred more than once.
-- At Most Once: Messages are transferred at most one time or an
error is raised on at least one of the endpoints. It is possible that some
messages are not transferred.
-- Exactly Once: Messages are transferred at least one time and at
most one time or an error is raised on at least one of the endpoints.
-- Ordered: Messages are transferred in the order in which they are sent.
These reliability assurances can be combined and certain combinations
are of particular interest due to their widespread application: Exactly
Once and Ordered (also referred to as Exactly Once Ordered).
The specifications developed by the WS-RX TC will define mechanisms
that support and allow the implementation and expression of reliability
assurances, at most once, at least once, exactly once, ordered, and will
not define mechanisms for applications to manifest reliability assurances.
The specifications developed by the WS-RX TC will define elements and
relationships among elements that enable the implementation of the
following functions which support the reliability assurances in the scope
of the TC:
-- Reliable establishment and teardown of one or more independent
shared contexts between two parties within which reliability assurances
apply to one-way or two-way messaging.
-- A mechanism which two parties can use to perform one-way or
two-way reliable messaging within a reliable context.
-- Ensures timely destination amnesia detection. Destination amnesia
is the condition resulting from catastrophic failure in which a Destination
loses the shared context required by reliability assurances.
-- At Most Once reliability assurances even in the case of
Destination amnesia.
-- Efficient message retransmission and acknowledgment.
-- Duplicate message detection.
-- Detection of out-of-order messages and discovery of the correct
order of messages.
-- Unique identification of messages within a reliable context
-- Acknowledgement of all messages within a reliable context
-- RM protocol violation detection and the raising and transmission
of related fault information.
-- Efficient preservation of the integrity of reliable contexts by
composition with WS-Security or other SOAP security mechanisms.
-- Expression of support for the specifications using the WS-Policy
Framework [9] and binding of that policy to a WSDL port.
-- A binding of the reliable messaging protocol elements to SOAP 1.1
and SOAP 1.2.
The specifications will uphold the basic principles of other Web
services specifications of independence and composition and must be
composable with the other specifications in the Web services architecture,
such as WS-Security [3], WS-Trust [4], WS-SecureConversation [5],
WS-Addressing [6], SOAP 1.1 [7], SOAP 1.2 [8], bindings of SOAP 1.1/1.2 to
HTTP, WS-Policy [9], WSDL 1.1 [10] and WSDL 2.0 [11]. The TC will also
take into consideration applicable work, such as the WS-I Basic Profile
[12]. The "Secure, Reliable, Transacted Web Services: Architecture &
Composition" white paper [13] published in 2003 provides information on the
Web services architecture.
If an above specification is outside of a standardization process at
the time this TC moves to ratify its deliverables, or is not far enough
along in the standardization process, any normative references to it in the
TC output will be expressed in an abstract manner, and the incarnation will
be left at that time as an exercise in interoperability.
While composition with other specifications is a goal of the TC, it is
also a goal to leave the specifics of how that composition is achieved
outside the scope of the RM specifications.
Each of the protocol elements will use implementation and language
neutral XML formats defined in XML Schema [14].
Out of Scope: The following is a non-exhaustive list. It is provided
only for the sake of clarity. If some function, mechanism or feature is not
mentioned here, and it is not mentioned in the Scope of Work section
either, then it will be deemed to be out of scope.
The TC will not define a mapping of the functions and elements
described in the specifications to any programming language, to any
particular messaging
middleware, nor to specific network transports.
The elements and/or mechanisms the TC defines must be independent of
issues and considerations that do not affect an interoperable reliable
messaging protocol.
Specifically: the TC is not concerned with binding the specifications
to specific underlying transports.
The TC and the specifications that it produces do not address
considerations, such as durability related to Sources' and/or Destinations'
ability to satisfy reliability assurances.
Except for the elements directly related to the functions in the scope
of the specifications, the TC will not prescribe the format of messages
that are transferred reliably according to the specifications.
The TC will make no assumptions about the location of Application
Sources relative to RM Sources and Application Destinations relative to RM
Destinations.
The TC will not attempt to define concepts or renderings for functions
that are of wider applicability including but not limited to:
-- Security (Encryption, Integrity and Authentication)
-- Addressing
-- Policy languages and frameworks
-- Routing
-- Transactions and Compensation
Where required these functions are achieved by composition with other
Web services specifications.
The TC will not attempt to define functionality duplicating that of
any normatively referenced specification in the input WS-ReliableMessaging
or WS-RM Policy specifications. If the referenced specification is outside
of a standardization process at the time this TC moves to ratify its
deliverables, or is not far along enough in the standardization process,
any normative references to it in the TC output will be expressed in an
abstract manner, and the incarnation will be left at that time as an
exercise in interoperability.
Deliverables
The TC has the following set of deliverables.
-- A revised Web Services Reliable Messaging Protocol
specification. Committee Specifications are scheduled for completion
within one year of the first TC meeting.
-- A revised Web Services Reliable Messaging Policy Assertion
specification. Committee Specifications are scheduled for completion
within one year of the first TC meeting.
These specifications will reflect refinements, corrections or material
technological improvements with respect to the input documents and in
accordance with this charter.
Ratification of the above specifications as OASIS Standards, including
a brief period to address any errata, will mark the end of the TC's lifecycle.
The TC may choose to vary the number of the specification documents
and their titles.
IPR Mode
This TC will operate under the "RF (Royalty Free) on RAND Terms" IPR
mode as defined in the OASIS Intellectual Property Rights (IPR) Policy,
effective 15 April 2005.
Audience
The anticipated audience for this work includes:
-- Vendors offering Web services products;
-- Other specification authors that need reliable message delivery
for Web services;
-- Software architects and programmers, who design, write or
integrate applications for Web services; and
-- End users implementing Web services-based solutions that require
an interoperable, composable reliable messaging solution.
Language
TC business will be conducted in English.
2. Non-normative information regarding the TC:
Similar or applicable work
The following work may be relevant to this WS-RX TC:
Similar Work:
-- OASIS Web Services Reliable Messaging TC. The WSRM TC has a
similar goal to that of WS-RX; to specify reliable message delivery for Web
services. However, the WSRM TC has a fundamentally different view with
regard to scope of the specification, required functions, policy, and Web
services architecture
composability.
-- OASIS ebMS TC. The ebMS TC has as part of its scope a similar
goal to that of WS-RX. However, it has a fundamentally different view with
regard to scope, QoS, required functions and Web services composability.
The proposers of this TC recognize there are different reliability
approaches in the industry and believe that the defined Scope of Work of
this TC addresses many functional use cases of these parallel efforts. The
proposers of this TC seek involvement from the authors of WS-Reliability in
particular, and the contribution of their expertise and experience, and
intend to work in harmony with them in the creation of the product of this
technical committee.
Applicable Work:
-- OASIS Web Services Security TC. WS-RX will ensure that its
specifications compose with the WSS TC specifications.
-- W3C Web Services Addressing WG. WS-RX will utilize the
WS-Addressing functions where appropriate and avoid creating overlapping
functions.
The TC may decide to establish liaisons with other groups as needed.
Responsibilities for such liaison will be defined by the TC at that time.
Anticipated contributions:
-- The current WS-Reliable Messaging [1] and WS-RM Policy [2]
specifications, as published February 2005 by BEA, IBM, Microsoft, and
TIBCO Software are expected to be contributed to this TC.
First meeting
The first meeting of the WS-RX TC will be a face to face meeting held
in Palo Alto, California, USA on Thursday, June 23 from 9:00 am to 5:30
local time and Friday June 24 from 9am to 12pm local time. This meeting
will be sponsored by SAP.
On-going meeting schedule
It is anticipated the WS-RX Technical Committee will meet via
teleconference every week at a time determined by the TC members during the
TC's first meeting. It is anticipated that the WS-RX Technical Committee
will meet in face to face every quarter at a time and location to be
determined by the TC members. 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. If no other TC proposers offer to sponsor teleconference
facilities, Microsoft will donate their facilities.
Proposers
The following eligible individuals are in support of this proposal:
Atsushi Atarashi, NEC, atarashi@sv.nec-labs.com
Anto Budiardjo, Individual Member, antob@clasma.com
Abbie Barbir, Nortel, abbieb@nortel.com
Doug Bunting, Sun Microsystems, doug.bunting@sun.com
Lloyd Burch, Novell, lburch@novell.com
Serge Cayron, ACORD, scayron@acord.org
Steve Carter, Novell, srcarter@novell.com
David Chappell, Sonic Software, dchappell@sonicsoftware.com
Alan Clark, Novell, aclark@novell.com
Lloyd Chumbley, ACORD, lchumbley@acord.org
David Connelly, OAGI, dconnelly@openapplications.org
Toby Considine, The University of North Carolina at Chapel Hill,
toby.considine@fac.unc.edu
Paul Cotton, Microsoft Corporation, pcotton@microsoft.com
Glen Daniels, Sonic Software, gdaniels@sonicsoftware.com
Chris Ferris, IBM, chrisfer@us.ibm.com
Dan Foody, Actional, dan.foody@actional.com
Paul Fremantle, IBM, pzf@uk.ibm.com
Robert Freund, Hitachi, Ltd., bob.freund@hitachisoftware.com
Peter Furniss, Choreology, peter.furniss@choreology.com
Alastair Green, Choreology, alastair.green@choreology.com
Anish Karmarkar, Oracle, Anish.Karmarkar@oracle.com
Chris Kurt, Microsoft Corporation, ckurt@microsoft.com
Dan Leshchiner, TIBCO, dleshc@tibco.com
Mark Little, Arjuna, mark.little@arjuna.com
Matt Mackenzie, Adobe, mattm@adobe.com
Matt Mihic, Blue Titan, mmihic@bluetitan.com
Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com
Nilo Mitra, Ericsson, nilo.mitra@ericsson.com
Tim Moses, Entrust, tim.moses@entrust.com
Eric Newcomer, IONA, eric.newcomer@iona.com
David Orchard, BEA Systems, dorchard@bea.com
Sanjay Patil, SAP, sanjay.patil@sap.com
Jim Purves, United Kingdom e-Government Unit,
jim.purves@cabinet-office.x.gsi.gov.uk
Andrew Nash, Reactivity, anash@reactivity.com
Shivajee Samdarshi, TIBCO, shivajee@tibco.com
Jiri Tejkl, Systinet, jiri.tejkl@systinet.com
Claus von Riegen, SAP, claus.von.riegen@sap.com
Pete Wenzel, SeeBeyond, pete@seebeyond.com
Steve Winkler, SAP, steve.winkler@sap.com
Prasad Yendluri, webMethods, prasad.yendluri@webmethods.com
Matsuki Yoshino, Hitachi, Ltd., yoshinom@itg.hitachi.co.jp
Convener
Paul Cotton, Microsoft Corporation, pcotton@microsoft.com
Proposed TC Chairs
Paul Fremantle, IBM, pzf@uk.ibm.com
Sanjay Patil, SAP, sanjay.patil@sap.com
References
[1] WS-ReliableMessaging
http://schemas.xmlsoap.org/ws/2005/02/rm
[2] WS-RM Policy
http://schemas.xmlsoap.org/ws/2005/02/rm/policy
[3] WS-Security
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
[4] WS-Trust
http://schemas.xmlsoap.org/ws/2005/02/trust
[5] WS-SecureConversation
http://schemas.xmlsoap.org.ws/2005/02/sc
[6] WS-Addressing
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
[7] SOAP 1.1
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[8] SOAP 1.2
http://www.w3.org/TR/soap12-part1/
http://www.w3.org/TR/soap12-part2/
[9] WS-Policy
http://schemas.xmlsoap.org/ws/2004/09/policy
[10] WSDL 1.1
http://www.w3.org/TR/2001/NOTE-wsdl-20010315
[11] WSDL 2.0
http://www.w3.org/TR/wsdl20-extensions
http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803
[12] WS-I Basic Profile
http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile
[13] Secure, Reliable, Transacted Web Services: Architecture & Composition
http://msdn.microsoft.com/webservices/understanding/advancedwebservices/default.aspx?pull=/library/en-us/dnwebsrv/html/wsoverview.asp
http://www-128.ibm.com/developerworks/webservices/library/ws-
securtrans/index.html
[14] XML Schema
http://www.w3.org/TR/xmlschema-1/
http://www.w3.org/TR/xmlschema-2/
====
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]