|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:||Re: Fwd: Re: [wsrm] Proposed clarificaiton resolutions to Ferriscomments 1,2|
|From:||Doug Bunting (Doug...@Sun.COM)|
|Date:||Jul 15, 2004 1:24:53 pm|
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:
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.
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.
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.
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. "
On 15-Jul-04 10:25, Mark Peel wrote:
To: "Tom Rutt" <to...@coastin.com>
I agree "manages" is overly broad, but I think "controls" carries a wrong implication: it suggests a multi-step procedure. "Initiates" similarly suggests a long-running process; we don't really want to suggest *anything* about the way the process works. I propose "accomplishes". If you don't like that, "effects" also works.