ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: WS-RX charter clarification is effective (w attachment)
- From: James Bryce Clark <jamie.clark@oasis-open.org>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 28 Jul 2005 16:46:54 -0400
Re-sending.
This is your notification under the OASIS TC Process rules that the
ballot entitled
"Charter clarification proposal (1 of 2: Bunting)"
and reported at
http://www.oasis-open.org/apps/org/workgroup/ws-rx/ballot.php?id=803
was successful, and the TC's charter has been clarified as a
result. The amendment to the language is now effective. The text we plan
to post to the official TC charter site is attached. This text also
incorporates a typo noted by the TC as its action item #2 at
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=939
I will announce this to the [members] and [tc-announce] lists and post
it tomorrow (minus the proofreading marks).
Regards JBC
Title: OASIS WS-RX TC Charter
The original Call for Participation for this TC may be found
at http://lists.oasis-open.org/archives/tc-announce/200505/msg00004.html.
The charter for this TC is as follows.
Name and abbreviation
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 this TC.
Add "this TC" and delete "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.
Corrected: "producesdo" -> "produces do"
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.
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]