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

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

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

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>