Preliminary Thursday minutes sent on behalf of Tom Rutt

-bob

 

Title: Bob Freund provided a new bridge number to allow us to dial in at the
meeting











Bob Freund provided a new bridge number to allow us to dial
in at the meeting. 



WSRM TC Face To face Meeting (Day 1) at New Orleans Marriott 



The meeting of the WSRM TC will take place 



wed, April 28, 2004, from 9:00 am to 3:00 PM Central Daylignt Time 



and Thur April 29: 9:00 AM to 12:00 AM CDT. 



There will be a conference bridge available on both days from 10:00 AM to 12:00 Noon CDT both days. 



New Conference call Dial-in number (different than previously stated) 



Toll Free US 1-888-384-9090 Toll number : 1-719-955-1560 Participant code:
409525 



Draft Agenda 



Wednesday 



9:00 AM: Action Item Status Review 



*Action Item List from 4/20 Teleconf* <http://www.oasis-open.org/archives/wsrm/200404/msg00073.html>




9:30 AM: Editors Draft .993 Status Review 



10:00 AM: Roll Call (Conference Bridge opens) 



10:15: Status of Public Review 



http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6524/DraftPublicReviewOutcome.htm


10:30 12:00 Noon – Issues and Editorial comment resolutions 







12:00 noon (conference Bridge Closes, lunch begins 



1:00-2:00 pm FAQ discussion 



2:00-3:00 PM Continuation of comment resolutions and Homework assignments 



3:30 – 5:00 –Liaison activities with other committees (EbMS joint meeting
included) 



Thursday: 





Joe Chiusano - bah


Review of Homework assignment status 


 



Iwasa produced draft .994:



Document Description:



April 28,2004(WD0.994)



This was updated for:



DraftPublicReviewOutcomeforMinutes.htm



with:



1.4, 2.2, 2.6, 3.17, 5.1, 6.1, 7.2,
7.3, 7.4, 7.5, 7.8, 7.11, 7.13, 8.2, 8.5, 



and editorial updates for examples
as described in a minutes on 4/28/2004.



 



And here are some comments: 



2.5



 *This was already resolved at 0.993:



 



7.12 Schema in appendix



 *The latest schemas Needed.



Action: Iwasa needs to make a new appendix, with the
disclaimer for schema precedence (as in the schema text) and a URL pointing at
the current schema on the WSRM server.



 



7.13



 526: "nor to notify failure on the sender
side" should be "nor to notify 
the RMP Sender of the failure".



 *Replaced "RMP Sender" with
"Sending RMP"



agreed



7.13



 527: "it's" should be "its".  Schemas: "it's" (in comment blocks)
should be "its"



 *Schemas was not taken care of. Other items in
7.13 was implemented.



Sunil has action item to apply comment 7.13 resolution to
schema.



 



Action on Jacques: incorporate his new Agreement section
while doing the document restructureing.



 


Draft resolution of CF public review comments


We need to prepare a paper which rebuts the concerns of
Chris Ferris, expressed in his presentation to the OASIS Symposium, and
provides a counter argument as to the perceived problems with the
WS-ReliableMessaging spec from Microsoft, IBM and partners.



 



The following was provided by Tom Rutt as a starting point
for resolving the CF public review comments:



 



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> 

        <!--mustUnderstand attribute for
soap version used must be present with value = 1 -->

       <xsd:anyAttribute
namespace="##other" processContents="lax"/> 

   </xsd:complexType> 

.. 

" 



And add the following text to the spec, in the new annex pointing at the schema:






When used with soap 1.1, the soap1.1 mustUnderstand attribute MUST be present
with value equal to 1 in all RM header blocks. 



When used with Soap 1.2, the soap1.2 mustUnderstand attribute MUST be present
with value equal to 1 in all RM header blocks.



 



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 Soap Fault in an HTTP Request,  it is unusual to send a Fault in a request
message.



 



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 the
delivery contract associated with the request is satisfied (e.g., all prior
messages in an ordered sequence have been received).  In most cases delivery occurs immediately
after receipt of the message.



 



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 composable with 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).   The syntax for this element
is URI, since that way of referencing a soap endpoint is independent of any
specific adressing or message delivery specification.



 



We want ws-reliability to compose
with many other mechanisms.



 



The WS-Reliable messaging protocol,
since it relies on ws addressing From address as the callback destination, does
not support a callback to a different endpoint than the from address. 



 



Proposed change: none required



 



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



 



WS Reliability does not explicitly
prescribe persistence requirements.



 



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) are identical for WS-Reliability protocol and
WS-ReliableMessaging protocol.



 



A device with volatile storage
(e.g, memory goes away when power goes away) 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 not receive an ack.  The sending RMP can notify the producer of
the message that the message is not assured to have been delivered.



 



Proposed change: TC is checking if
there is any mention of persistence remaining, which will be removed.



 



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 normal skews
in system clock.



 



Although there may be some merit in
designing a more robust mechanism to deal with excessive clock skews, the
expiry time mechanisms used is consistent with other specifications, such as
ebxml Messaging, ws lifecycle management.



 



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, amongst
other features, to the need for three RM reply patterns to cover the use cases
identified in the requirements.



 



The WS-Reliable messaging
specification, from Microsoft IBM and partners, 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 use
cases 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.



 



Cf8    Spec does not state a Reciever MUST
acknowledge all delivered messages with each acknowledgment indication.



 



WS-reliability requires an ack to
be sent for all delivered messages. It states “If a receiving RMP receives a
message with AckRequested element, the receiver MUST send an Acknowledgment
message even when the message is a duplicate, and if it has already been
previously delivered.”



 



Sending the complete ack history
for a sequence along with every ack indication was deemed unnecessary for the
WS-Reliability protocol.



 



Ws-Reliability has a polling
mechanism to allow the Sending RMP to request the acknowledgment status for all
the messages sent within a Group.  .



 



Proposed change: 



TC is currently working on
clarification wording which covers the polling case, where the ack is made
available for a poll response (but not sent until the poll is received).



 



 



Cf9   There is
unnecessary implementation details in the spec.



 



The spec has several,
non-normative, implementation guidance notes.



 



Proposed change: TC has agreed to
move many of these non-normative implementation notes into an informative
companion document.



 


Paper in response to Chris Ferris Presentation at OASIS Symposium


 



The TC agreed to prepare a paper to address the concerns
express by Chris Ferris at the presentation, and to provide a balanced
comparision, from our point of view, with the Microsoft IBM and partners
WS-Reliable messaging specication.



 



Points to be included in our comparison:



Lack of polling support



 



Why is “to” field needed for
reliability.



 



If both From and Reply to are
present in the ws-addressing header, it is not clear where to send either the
ack or the fault.



 



They do not send any policy directives
on the wire.  Since there is no policy
property defined for indicating duplicate elimination or other qos contracts,
there is no specification on how this is accomplished.



 



The spec does not address rm
processing failures of any kind.



 



Unclear what behaviour of NACK is
when a fault is already sent for a particular message in a sequence.



 



Poor support for groups with one
message.



 



Batching of faults is not
supported.



 



Sending an ack at time of receipt
admits potential failure cases.  Sending
the entire ack history is not sufficient. (we should give one or more use cases
which show their deficiency)



 



Their spec is not clear with
respect to a wsdl oneway operation how the destination for the ack is
determined. 



 



The schema is not fully explained
in the spec, and there appear to be inconsistencies



 



Bob F took action to lead a team to provide an initial draft
of this paper for review by the TC. 
Sunil and Jacques joined the team.



 


FAQ


Agreed that we should come back to addressing the FAQ after
we prepare the paper.



 



No discussion at this meeting.



 


Pete wenzel Action


Def of



Reliable
Messaging Processor (RMP):



A
module capable of processing and enforcing Reliable Messaging as described in
this



specification.
With regard to the transmission of a message from one RMP to another, the
former



will
be act in the role of “sender” and the latter in the role of “receiver”.



 



 



Pete: Need to relate this definition to base terms which
have a normative definition in the soap specification.  We also have to relate this to the
diagrams.  Sometimes they are called
nodes, which is a soap term.



 



Is an RMP an entire soap node, or soap processor, or is it
just a slice of a soap node.  This
impacts the interfaces the rmp must expose and use to communicate with other
processing elements.



 



Jacques: It could be a soap node, but does not have to
be.  It could be implemented as a Java
handler, which extends a soap node.



 



Pete: we need to give it a definition which is flexible
enough to allow alternative implementations.



 



Jacques: the definition of deliver was left abstract for
this reason.  It does not necessarily
mean reaching the ultimate application. 
It could be another handler in a chain within a node.



 



We agreed to change “application” to “producer” and
“consumer” throughout the document.



 



Fig 7 and fig 4 are not consistent.



 



These figures should be updated to use the terms “producer”
, consumer and Sending rmp and receiving rmp.



 



Pete: is the consumer role only on the receiving rmp end?



 



We need to formally define “producer’ and “consumer”  in the spec.



 



Action: Jacques will lead a team to ensure the terminology
used in the spec is consistent with normative terms in the soap spec.  Pete W will work with Jacques to provide a
proposal to resolve this.



 



11-12: Planning for Future CD Balloting 



 



April 29: Iwasa posts all agreed edits in a new .995
editor’s draft. 



 



May 4 morning: Jacques posts a change barred .996 editor’s
draft for review by TC (including a rough draft implementers guide holding
non-normative text removed from .995 draft.



 



May 4 evening - resolve all comments at TC meeting with
editing instructions for editors.



 



May 6 - Final Editors draft posted resolving all comments.





May 10 – member editorial review comments due 



 



May 11 – TC votes approval of CD 1.0 ballot and vote to
submit to OASIS at call



 



May 14 – three letters from members on “using the spec”



 



May 14 – Submit package to OASIS for OASIS Standard
Processing 





 



Sunil expressed concern that there is not enough time for
member review of the final editor’s draft between May 7 and May 11.



 



Bob: Jamie clarified that once it is submitted for OASIS
review, no changes are allowed by the process (no edits at all).  We are doing restructuring and may editorial
text changes.  We should have a proof
reading



 



 



Tom will schedule 2 hour Tuesday phone calls for the next four
weeks 5:30PM to 7:30 PM EDT.



 



12: noon
– Meeting to adjourn.