Re: Fwd: Re: [wsrm] Proposed clarificaiton resolutions to Ferriscomments 1,2

[Doug Bunting <Doug.Bunting@Sun.COM>]

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.

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.

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

thanx,
	doug

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

> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: [wsrm] Proposed clarificaiton resolutions to Ferris comments 1,2
> From:
> "Mark Peel" <mpeel@novell.com>
> Date:
> Thu, 15 Jul 2004 10:39:44 -0600
> To:
> "Tom Rutt" <tom@coastin.com>
> 
> To:
> "Tom Rutt" <tom@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.

...