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

[Jacques Durand <JDurand@us.fujitsu.com>]

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.Bunting@sun.com]
Sent: Thursday, July 15, 2004 1:31 PM
To: Mark Peel
Cc: wsrm@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:

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

...

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.