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" <>
> Date:
> Thu, 15 Jul 2004 10:39:44 -0600
> To:
> "Tom Rutt" <>
>
> To:
> "Tom Rutt" <>
>
>
> 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.
...
