|
<ter1> Need to
clarify that no implementation details are prescribed for abstract RMP
operations:
Proposed clarification:
Add at the end of line 85
the following sentence to the qos bullet:
These abstract operations
are associated with processing of an RMP, however implementation aspects
regarding how, or when, they are invoked are not prescribed by this
specification.
<JD1>
Although these ops are first mentioned in line 85, this reference is very
general and does not call for such a detailed adjustment that early. In line
85, I would just add "These operations are defined in Section 1.5".
</JD1>
Add the following new
paragraph between lines 105 and 106, before the Note
The direction of the arrows
for the qos contract abstract operations, shown in Figure 1, represents the
direction of information flow associated with the operation. Implementation
details of how these operations are invoked, including which entity invokes
the abstract operation, are not prescribed by this specification.
<JD1>
OK, but I would remove second sentence if we use my rewording below for the
Note, as it is redundant.
<JD1>
I think we need an even more explicit statement, for addressing comments 1,2
from CF:
"
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. "
I
would place the statement in the "Note" after Figure 1, replacing and expanding on sentence in line 110 ("
The interpretation of these operations is a matter of implementation.")
<DB1>
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:
above
[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.
"
<JD3>
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 </JD3>
<JD5>
Lines 182-198: generalize
the definitions of the four abstract operations
Deliver:
An abstract operation
supported by the RMP. When invoked on a Receiving RMP, the operation makes
the payload of one Reliable Message available to the 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.
Submit:
An abstract operation
supported by the RMP. When invoked, the operation transfers payload data from
the Producer to the Sending RMP (e.g., a request to the Sending RMP to take
responsibility for the Reliable Message).
Respond:
An abstract operation
supported by the RMP. When invoked, the operation transfers payload data from
the Consumer to a Receiving RMP.
Notify:
An abstract operation
supported by the RMP. When invoked, the operation makes available a response
payload received by the Sending RMP, to the Producer, or makes available to
the Producer the status of a Reliable Message (e.g., a notification that the
Sending RMP failed to send a Reliable Message).
with the following:
-----------------------
Deliver:
An abstract operation
associated with a Receiving RMP. When invoked, the operation makes the
payload of one Reliable Message available to the Consumer from the Receiving
RMP. 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.
<JD1>
The "associated with a Receiving RMP" might still be
misinterpreted.
I
would replace 1st sentence with:
"An
abstract operation that controls a transfer from Receiving RMP to
Consumer."
Submit:
An abstract operation
associated with a Sending RMP. When invoked, the operation transfers payload
data from the Producer to the Sending RMP (e.g., a request to the Sending RMP
to take responsibility for the Reliable Message).
<JD1>
I would replace 1st sentence with:
"An
abstract operation that controls a transfer from Producer to Sending
RMP."
Respond:
An abstract operation
associated with a Receiving RMP. When invoked, the operation transfers
payload data from the Consumer to a Receiving RMP.
<JD1>
I would replace 1st sentence with:
"An
abstract operation that controls a transfer from Consumer to Receiving
RMP."
Notify:
An abstract operation
associated with a Sending RMP. When invoked, the operation makes available a
response payload received by the Sending RMP, to the Producer, or makes
available to the Producer the status of a Reliable Message (e.g., a
notification that the Sending RMP failed to send a Reliable Message).
<JD1>
similarly,
"An
abstract operation that controls a transfer from Sending RMP to
Producer."
plus a
narrowing: replace "the status" by "the failure status".
<DB1>
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.
<JD3>
on Deliver: 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>
<JD5>
Answer to JD4 From Doug B: 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>
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.
<JD3> On notify: 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>
<JD5>
Response from Doug on <JD3> Moving these sentences elsewhere is
fine. I am not sure what is missing
(or where) with regard to your last sentence.
<JD>
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.
</JD5>
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.
"
<JD3>
On Respond: same remarks as for Notify. Also the 2nd sentence seems not
at its place in this a definition, which 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>
<JD5>
Response to JD3 from Doug: 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.
JD: 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").
</JD5>
<JD4>
1) and 2) follow-up:
<JD4>
in addition to proposed resolution (previous emails), we need to fix - or
explain the way we name these operations: we call them currently "RMP
operations" at various places, but as noted these abstract operations
are not necessarily supported by the RMP.
So
to be more precise we could rename them (QoS operations? or transfer
operations?) or just explain that this naming does not mean all these ops are
supported by an RMP.
</JD4
<JD5>
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... "
</JD5>
-------------------------
<JD5>
B) in Section 2.2 that expands on "RMP operations", add:
(after
line 255 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)]
</JD5>
|