[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: FW: Re: [wsrm] Proposed clarificaiton resolutions to Ferriscomm ents 1,2
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]