Proposed resolution to CF public review comments.

[Tom Rutt <tom@coastin.com>]

The group formulated a set of public review comments.from the 
presentation by Chris Ferris:

Cf1: Two schemas and namespaces are unnecessary for two soap versions.
Agreed:

Proposed change:
remove the soap 1.2 schema, and change the following lines on the soap 
1.1 schema:
soap 1.1 schema has:

"
...
<xsd:schema 
targetNamespace="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"; 
xmlns:wsrm="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"; 
elementFormDefault="qualified" attributeFormDefault="unqualified" 
version="0.62">
<xsd:import namespace="http://schemas.xmlsoap.org/soap/envelope/"; 
schemaLocation="http://schemas.xmlsoap.org/soap/envelope"/>
<!-- 4WSRM Headers -->
<xsd:element name="Request" type="wsrm:RequestType"/>
<xsd:element name="Response" type="wsrm:ResponseType"/>
<xsd:element name="PollRequest" type="wsrm:PollRequestType"/>
<!-- Describe the BaseTypes -->
<xsd:complexType name="HeaderBaseType">
<xsd:sequence>
<xsd:any namespace="##other" processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute ref="soap11:mustUnderstand" use="required" fixed="1"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
...
"
to the folloing:
"
...
<xsd:schema 
targetNamespace="http://www.oasis-open.org/committees/wsrm/schema/1.1/";
xmlns:wsrm="http://www.oasis-open.org/committees/wsrm/schema/1.1/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="0.62b">

<!-- 4WSRM Headers -->

<xsd:element name="Request" type="wsrm:RequestType"/>
<xsd:element name="Response" type="wsrm:ResponseType"/>
<xsd:element name="PollRequest" type="wsrm:PollRequestType"/>
<!-- Describe the BaseTypes -->
<xsd:complexType name="HeaderBaseType">
<xsd:sequence>
<!--mustUnderstand attribute for soap version used must be present with 
value = 1 -->
<xsd:any namespace="##other" processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute ref="soap12:mustUnderstand" use="required" fixed="1"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
..
"

And add the following text to the spec:


When soap 1.1 is used, the soap1.1 mustUnderstand attribute MUST be 
present with value 1.

When Soap 1.2 is used, the soap1.2 mustUnderstand attribute MUST be 
present with value 1.

Cf2: Why are soap faults not used for RM-Fault?

The SOAP Fault model was not used to report RM Faults is because:
- SOAP Fault model doesn’t support batching of Faults which this 
protocol requires.
- While it is not illegal to send a Fault in a Request, it is unusual to 
send a Fault in a request message.

Because we didn’t want to use SOAP Fault model for few allowed cases and 
use RM Fault model for other cases, we consolidated into just one model.

Proposed change: none required

Cf3: Not Acking until delivery to the application causes unnecessary delays?

The definition of delivery in the specification is abstract, and allows 
implementation architectures using queues and other mechanisms not 
actually requiring the ultimate receiving application to participate in 
the acknowledgment procedure. Delivery can occur as soon as the 
Receiving RMP can ensure that a received message message meets the qos 
constraints associated with the request (e.g., all prior messages in an 
ordered sequence have been received, so the next message may be delivered).

The initial contribution to the TC work had a protocol which returned an 
ack to the sender as soon as the message was received (assuming it is 
not expired). However, this behaviour admitted failure use cases where 
the sender would think the message was delivered, while a failure 
condition after this ack admitted cases where the message could not be 
delivered (e.g., the receiving RMP has a processing failure while a 
received messages is being held waiting for a prior message in an 
ordered sequence).

Also, the state machine was simplified significantly by sending the ack 
only when the receiving RMP delivers the message (e.g, makes it 
available to the next processing element in a chain by putting it in a 
queue).

Proposed change: none required

Cf4: Unclear if the spec can compose with WS-Addressing or WS-MD?

An important consideration in design of the WS-Reliability protocol was 
to have it be orthogonal to any other web services protocols which 
define the use of soap header elements.

WS-Reliability defines elements to be sent in Soap headers . Our header 
elements only contain parameters essential for the operation of the 
WS-reliability protocol. For example, WS-reliability defines a reply to 
element for the sending Reliable Message Processor to convey a call back 
address for the Reliable messaging reply. This address is independent of 
any other reply mechanisms used for other protocols (e.g., WSDL response 
is not influenced by the WS-Reliability reply To parameter).

Proposed change: none required

Cf5: Persistence model will not work on devices with non volatile storage?

The persistence requirements (e.g., holding a received message in a 
buffer until all priors have been delivered in an ordered sequence; 
holding a list of integer ranges of sequence numbers which have been 
delivered, or faulted, in the sequence) are identical for WS-Reliability 
protocol and WS-ReliableMessaging protocol.

A device with non volatile storage can meet the requirements of the 
protocol as long as its storage remains in tact. Because messages are 
only acked when delivered, in cases where failure of the non-volatile 
storage results in a message not being delivered, the sending RMP will 
notify the producer of the message that the message cannot be assured to 
have been delivered.

Proposed change: none required.

Cf6: Mandatory Expiry time requires synchronization of clocks:
The precision of the expiry time selected by the sending application 
needs to be selected to allow for skews in system clock.

Propose change: under discussion by the WSRM TC.

Cf7: There is unnecessary complexity in the spec, headers have 
unnecessary elements making them larger than necessary?

The TC charter required the WSRM TC to produce a requirements document 
to determine features, required by members of the TC, to be met by the 
protocol.

These requirements led to the need for three RM reply patterns to cover 
the use cases identified in the requirements.

WS-Reliable messaging specification does not support all the use cases 
identified in the WS-Reliability requirements (e.g., it does not support 
polling for RM replies), thus its protocol may seem to be less complex.

However, conformance claims can be made by an implementation to any 
valid subset of WS-Reliability features (a receiving RMP can return a 
notSupportedFeature rm-fault code in response to a request for features 
it cannot satisfy). Thus a WS-Reliability implementation needs only be 
as complex as required by the applications it is designed to support.

The cost of adding necessary indicators of features requested in request 
header elements is minimal in terms of header size and processing 
complexity.

Proposed change: None required.


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133