Draft Submission Letter for WS-Reliability 1.1
1. A formal specification that is a valid member of its type, together
with appropriate documentation for the specification, both of which must
be written using approved OASIS templates.
Pdf file for ws-reliability version 1.1
.xsd file for Ws-Reliability schedma
xsd file for Reference type
xsd file for Features and Properties
xsd file for wsrm features and properties
2. A clear English-language summary of the specification.
WS-Reliability version 1.1 specifies a SOAP Module (as defined by [SOAP 1.2]),
which fulfills reliable messaging requirements that are critical in some applications of
Web Services. The WS-Reliabilty Specification, version 1.1, specifies a transport-agnostic
protocol based on SOAP for providing quality of service in the reliable delivery
of messages.
This specification defines the following reliability features:
- Guaranteed message delivery, or At-Least-Once delivery semantics.
- Guaranteed message duplicate elimination, or At-Most-Once delivery semantics.
- Guaranteed message delivery and duplicate elimination, or Exactly-Once delivery semantics.
- Guaranteed message ordering for delivery, within a group of messages.
3. A statement regarding the relationship of this specification to
similar work of other OASIS TCs or other standards developing organizations.
This specification has been designed to be used in combination with other complementary protocols,
and has built upon previous experiences from the ebXML Message Service [ebMS].)
Both WS-Reliability and ebMS have same messaging reliability contracts as objectives:
guaranteed delivery, no duplicate delivery, ordered delivery, and combinations
of these.
However, WS-Reliability has improved on scalability and performance by generalizing the
use of sequence numbers, and can accommodate different security and access conditions on
each party, as this is more frequently the case with a Web service and its clients,
compared to more symmetrical access conditions in messaging. The reliability contract is
more "application-oriented" in WS-R, where acknowledgment is on final delivery,
in contrast to "on receipt" by the message handler in ebMS.
4. Certification by at least three OASIS member organizations that they
are successfully using the specification consistently with the OASIS IPR
Policy.
The chair has received statements from the following TC member
organizations. We include pointers to the e-mail archive record of the statements made.
Hitachi:
http://www.oasis-open.org/archives/wsrm/200406/msg00050.html
Fujitsu
http://www.oasis-open.org/archives/wsrm/200406/msg00084.html
Oracle:
http://www.oasis-open.org/archives/wsrm/200406/msg00081.html
5. An account of each of the comments/issues raised during the public
review period, along with its resolution.
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7059/PublicCommentsIsssues-060104Output.html
<will update with final public comment issue resolution document>
6. An account of and results of the voting to approve the approve the
specification as a Committee Draft.
<tbd> voted at teleconf on ???
7. An account of or pointer to votes and comments received in any
earlier attempts to standardize substantially the same specification,
together with the originating TC's response to each comment.
This specification has not been previously submitted to OASIS.
8. A pointer to the publicly visible comments archive for the originating TC
WSRM TC public comment list:
http://lists.oasis-open.org/archives/wsrm-comment/
WSRM TC list:
http://lists.oasis-open.org/archives/wsrm/
9. A statement from the chair of the TC certifying that all members of
the TC have been provided with a copy of the OASIS IPR Policy.
The TC chair certifies that all members have been reminded to read the
IPR statement on numerous occasions and also in an e-mail
“Call for IPR disclosure regarding ws-Reliability spec” at:
http://www.oasis-open.org/archives/wsrm/200405/msg00022.html
10. Optionally, a pointer to any minority reports submitted by one or
more TC members who did not vote in favor of approving the Committee
Draft, or certification by the chair that no minority reports exist.
No minority reports have been submitted to the chair as of this
writing.
Submitted by the TC chair, Tom Rutt, trutt@us.fujitsu.com