Re: FW: Re: [wsrm] Proposed clarificaiton resolutions to Ferriscomm ents 1,2

[Tom Rutt <tom@coastin.com>]

I am happy with Jacques' edits.

Tom Rutt

Jacques Durand wrote:

> comments inline <JD2>
> plus a resulting proposal for the RMP ops definitions.
>
> -Jacques
>
> -----Original Message-----
> From: Doug Bunting [mailto:Doug.Bunting@sun.com]
> Sent: Thursday, July 15, 2004 10:11 PM
> To: Jacques Durand
> Cc: Mark Peel; wsrm@lists.oasis-open.org
> Subject: Re: Fwd: Re: [wsrm] Proposed clarificaiton resolutions to
> Ferris comments 1,2
>
>
> Jacques,
>
> Please see below
>
> On 15-Jul-04 17:15, Jacques Durand wrote:
> ...
>
> > Deliver:
> >
> > 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
>
> > Notify:
> >
> > 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>
>
> ...
>
> > Respond:
> >
> > 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>
>
>
>
> > thanx,
> >         doug
>
> <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>
>

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