Title: RE: Fwd: Re: [wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2

Overall the 1st part of this rewording looks fine to me, as it rightly emphasizes that the whole model (components + operations) is an abstract template that can be instantiated in many ways, depending on how we want the QoS contract to apply, between which parties.

One edit: I believe the singular form should be used: "...any implementation choices leading to the externally observable properties discussed in this specification are equally valid" ---> "...any implementation choice leading to the externally observable properties discussed in this specification is equally valid"

Other comments inline, for the operation definitions <JD>

Jacques

-----Original Message----- From: Doug Bunting [mailto:Doug...@sun.com] Sent: Thursday, July 15, 2004 1:31 PM To: Mark Peel Cc: ws...@lists.oasis-open.org Subject: Re: Fwd: Re: [wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2

I agree with the general direction outlined in the attached discussion but think we should go a bit further.

With regard to the set of definitions, we should be clear these operations define the abstract interface to a subset of the infrastructure on either the sending or the receiving side that may not be nearly this clearly separated. That is, the RMP itself is abstract in the sense that it has the abstract interface described using the submit, notify, deliver and respond operations. The RMP is also abstract because the infrastructure support for reliable delivery may be more or less comprehensive that what we have arbitrarily chosen to place within that bucket for the purposes of making our specification clear. This adds up to meaning the notify operation (for example) may or may not exist in a real deployment, not just that the producer might actually poll for errors.

If we start with Jacques' suggestion for text below Figure 1:

" These operations are abstractly defined here as transfer of information (message payload, error notice) between the RMP and external components (Producer, Consumer). This specification makes no requirement on how these operations should be implemented, and by which component. Defining the reliability QoS contracts does not require more concrete definitions, which are left to implementations. "

[As an aside, this point seems important enough not to relegate it to a (non-normative?) note and should be in the regular specification text.] I would re-word it slightly:

" 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 choices leading to the externally observable properties discussed in this specification are equally valid.

The operations themselves describe a transfer of information (payload or error notice) between external components (Producer, Consumer) and an associated RMP. Again, 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. "

With this background, we can be a bit more straightforward with our definitions of the operations. We have already described them as abstract and for the exposition of the text. This leaves us able to simplify the abstract interface and talk directly about invocation and information transfer. How about:

" 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>

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>

Submit:

An abstract operation that transfers the payload of one Reliable Message from Producer to Sending RMP. Essentially, the Submit operation is a request to the Sending RMP that it take responsibility for the Reliable Message.

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>

thanx, doug

On 15-Jul-04 10:25, Mark Peel wrote:

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.