|Jacques Durand||Jul 14, 2004 5:20 pm|
|Abbie Barbir||Jul 15, 2004 7:37 am|
|Tom Rutt||Jul 15, 2004 9:03 am|
|Abbie Barbir||Jul 15, 2004 9:22 am|
|Doug Bunting||Jul 15, 2004 1:24 pm|
|Jacques Durand||Jul 15, 2004 5:09 pm|
|Doug Bunting||Jul 15, 2004 10:04 pm|
|Jacques Durand||Jul 17, 2004 8:43 pm|
|Tom Rutt||Jul 18, 2004 1:47 pm|
|Subject:||FW: Re: [wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2|
|From:||Jacques Durand (JDur...@us.fujitsu.com)|
|Date:||Jul 17, 2004 8:43:09 pm|
Title: FW: Re: [wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2
comments inline <JD2> plus a resulting proposal for the RMP ops definitions.
-----Original Message----- From: Doug Bunting [mailto:Doug...@sun.com] Sent: Thursday, July 15, 2004 10:11 PM To: Jacques Durand Cc: Mark Peel; ws...@lists.oasis-open.org Subject: Re: Fwd: Re: [wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2
Please see below
On 15-Jul-04 17:15, Jacques Durand wrote: ...
An abstract operation that transfers the payload of one Reliable Message from Receiving RMP to Consumer. For example, in one specific implementation choice, the payload is placed into a queue by the Receiving RMP to be consumed by an application component.
<JD> So you propose to not use anymore the expression "making available". In that case we should warn that the notion of "transfer" above must also be understood in an abstract way, as a transfer of control (or of responsibility) on the payload, not necessarily as a physical transfer which may take place later (in which case we may not want to wait for this to happen before sending the Ack). E.g. an RMP may "deliver" by just setting a flag on payload stored in a persistent store, meaning availability to a COnsumer which may later complete the actual transfer by querying the store. </JD>
Whether payloads or control of payloads is transfered is a very low implementation detail that does not matter when we are talking about abstract operations on abstract components. I believe this only confuses the specification.
<JD2> my concern was precisely to make sure that "transfer" remains abstract enough and is not understood in a too restrictive way, which could possibly lead a developer to believe (in my above example) that its RMP has to wait for the payload to be physically fetched by the COnsumer, before sending the ack for a delivery. (that's a possible interpretation, but not the only one.) To keep "transfer" abstract enough I propose to add a sentence like: "transfer to a component" in above definitions does not imply a complete physical transfer of data. It is, mor generally, the act of making data available in some way to the component. (see below my more complete proposal) </JD2>
. We define Deliver (and other ops) in terms of "transfer", so if we want these ops to remain
An abstract operation that transfers a failure status or contained payload of one Reliable Message from Sending RMP to Producer. The transfered status might include an indication the Sending RMP was unable to reliably deliver the message. The Sending RMP is NOT REQUIRED to invoke this operation for every Reliable Message submitted; it MAY invoke Notify for a subset of the completed Submit operations.
<JD> the last sentence ("it MAY...") is not clear, and talks of correlation between these ops that I believe should be addressed later in the doc in a more informed context, e.g. section 2.2. Also we may want to move the requirements (statements using the RFC keywords) out of these definitions, and in a more prescriptive section like 2.2. The prescriptive section (2.2) should also say the most basic: that an RMP MUST be able to invoke Notify (regardless how the op is implemented) as well as Deliver. The other operations (Submit, Respond) are to be invoked from outside.</JD>
Moving these sentences elsewhere is fine. I am not sure what is missing (or where) with regard to your last sentence.
<JD2> nothing missing... I was just saying there is no requirement attached to the invocation of (Submit, Respond) as the RMP is not supposed to invoke these. </JD2>
An abstract operation that transfers the payload of one Response Message from Consumer to Receiving RMP. When supported in the protocol, this payload data will be carried together with RM Reply headers (see below). The Consumer is NOT REQUIRED to invoke this operation for every Reliable Message delivered; it MAY invoke Respond for a subset of the completed Deliver operations. " <JD> same remarks as for Notify. Also the 2nd sentence seems not at its place in this a definition, whch I believe does not need to mention all the rules associated with these ops. I propose to keep just the 1st sentence, in the def.</JD>
In another email, you agreed with the general use of forward references from this section. The second sentence above is a forward reference to the rules you mention, not those rules.
<JD2> Forward refs are OK, my concern on your sentence #2 above, is that it is in fact a hidden requirement (the "will be" actually sounds like a MUST), which exposes deeper protocol ramifications than necessary in this section (which I tend to consider just as a glossary). So the sentence tells either too much or not enough, if left here. Instead, we could refer to the section that expands on it (e.g. "more detailed semantics is given in Section 2.2"). </JD>
<JD2> my proposal:
A) for the terminology section, after compilation of previous other comments:
(note again that these definitions do not pretend make explicit all the rules and semantics attached to the usage of these ops, which would be described elsewhere in the spec.) This is along keeping the terminology section as nothing more than a glossary.
Note also that I use the term "message" instead of "payload" (see C.F. comment #15): although I don't see this as a mjor issue, CF has a point that RMP is a SOAP node (or processor)before all. "payload" may sound specific of an implementation. To be discussed in other mail.
Deliver: "An abstract operation that transfers a message from Receiving RMP to Consumer. This operation is invoked by the RMP. More details are given in section... "
Submit: "An abstract operation that transfers a message from Producer to Sending RMP. More details are given in section... "
Respond: "An abstract operation that transfers a message from Consumer to Receiving RMP, as a response to a previously received message. More details are given in section... "
Notify: "An abstract operation that transfers from Sending RMP to Producer, either a failure status of a previously sent message, or a message received as response. This operation is invoked by the RMP. More details are given in section... "
B) in Section 2.2 that expands on "RMP operations", add:
(after 1st sentence that introduces the four ops) (mostly wording from Doug, +few edits: choices->choice, and some addition on "transfer".)
"These operations and executable components are abstractly defined here to simplify discussion of the WS-Reliability protocol and not to imply a particular API or component separation. The separations described here between producer and consumer and their associated RMP do indicate the expected value of placing WS-Reliability support within an infrastructure component. However, any implementation choice leading to the externally observable properties discussed in this specification is equally valid.
The operations themselves describe a transfer of information (message data or error notice) between external components (Producer, Consumer) and an associated RMP. This "transfer" does not imply a complete physical transfer of data. It is, more generally, the act of making data available in some way to the component.
This specification makes no requirement on how these operations should be implemented, by which component or if these operations are explicitly present in an implementation."
[note: other edits may be necessary in 2.2. or elsewhere. But note that I'd prefer to leave the section 1.2 as is and not overload it with more details on Deliver/Submit/Respond/Notify - although that's where we talk first about these ops - as this is not essential to the purpose of this section (to convey the general RM concepts and scope)] </JD>