[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] PR035, PR009, PR020: DA defs
I am much more comfortable with
these defs and - given minor tweaking started by Stefan - I feel I can
explain them to my reviewers.
I also believe we need to modify the Deliver
definition as Chris suggested.
See below in line, proposed edits following up
on Stefan remarks.
Jacques
-----Original
Message-----
From: Stefan Batres [mailto:stefanba@microsoft.com]
Sent:
Thursday, January 25, 2007 9:46 AM
To: Matthew Lovett;
ws-rx@lists.oasis-open.org
Cc: Durand, Jacques R.
Subject: RE: [ws-rx]
PR035, PR009, PR020: DA defs
Matt,
Thanks for putting this
together. I've inlined a couple of
comments.
--Stefan
-----Original Message-----
From: Matthew
Lovett [mailto:MLOVETT@uk.ibm.com]
Sent:
Thursday, January 25, 2007 5:36 AM
To: ws-rx@lists.oasis-open.org
Cc:
Durand, Jacques R.
Subject: Re: [ws-rx] PR035, PR009, PR020: DA
defs
Hi all,
Following on from the discussion about using
"deliver" rather than "process to conclusion", here are some definitions that
Peter and I have worked on. We believe these definitions help define the
end-to-end DA, as they include the RMS
behaviour.
--
wsrmp:DeliveryAssurance
When applied to an RM
Destination, this element defines a policy assertion that identifies a
requirement on RM Sources. Any RM Source that transmits messages to this RM
Destination SHOULD conform to the requirement expressed by this assertion.
Conversely, when it is applied to an RM Source this assertion identifies a
requirement on RM Destinations. Any RM Destination that receives messages from
this RM Source SHOULD conform to the requirement expressed by this
assertion.
wsrmp:AtLeastOnce
Each message is to be delivered at
least once. The requirement on an RM Source is that it SHOULD retry transmission
of every message sent by the Application Source until it receives an
acknowledgement from the RM Destination. The requirement on the RM Destination
is that it SHOULD retry delivery to the Application Destination of every message
that it accepts from the RM Source. There is no requirement for the RM
Destination to apply duplicate message filtering.
[SB] I think there
should be a requirement to indicate an error if the assurance can't be
met.
<JD> Indeed. I believe the duty to notify error (whatever that means) is part of the DA, not something to do if DA is not met (DA MUST always be met !) We can do :
"Each message is to be delivered
at least once, or else a "delivery error" MUST be made
available to either Application Source or Application Destination. The
requirement on an RM Source is that it SHOULD retry transmission of every
message sent by the Application Source until it receives an acknowledgement from
the RM Destination. The requirement on the RM Destination is that it SHOULD
retry delivery to the Application Destination of every message that it accepts
from the RM Source, in case of unsuccessful delivery.
There is no requirement for the RM Destination to apply duplicate message
filtering."
wsrmp:AtMostOnce
Each message is to be
delivered at most once. The RM Source MAY retry transmission of unacknowledged
messages, but is NOT REQUIRED to do so. The requirement on the RM Destination is
that it MUST filter out duplicate messages, i.e. that it MUST NOT redeliver any
message.
[SB] I find "that is MUST NOT redeliver any message" confusing.
The requirement is to filter out duplicates that arrive on the wire. But we
can't forbid redelivery of a message that arrived only once or for which
duplicates have been eliminated.
e.g. RMD delivers message to AD in the
context of a local atomic transaction that gets rolled back, this text seems to
say that the message should not be redelivered.
<JD> Right - but the roll-back/retry case can be taken care of by a better def of "Deliver" (see previous mail). So I think Stefan means:
"Each message is to be delivered at most once. The RM Source MAY retry transmission of unacknowledged messages, but is NOT REQUIRED to do so. The requirement on the RM Destination is that it MUST filter out duplicate messages, i.e. that it MUST NOT deliver a duplicate of a message that has already been delivered."
(NOTE that this DA does NOT allow an RMD to
let a duplicate slip out and get by with raising an
error...)
wsrmp:ExactlyOnce
Each message is to be delivered
exactly once. The requirement on an RM Source is that it SHOULD retry
transmission of every message sent by the Application Source until it receives
an acknowledgement from the RM Destination. The requirement on the RM
Destination is that it MUST filter out duplicate messages, i.e. that it MUST NOT
redeliver any message.
[SB] Same comments apply.
--
<JD> merging the hard part of each updated DA above:
"Each message is to be delivered at least
once, or else a "delivery error" MUST be made available to either Application
Source or Application Destination. A message also MUST NOT be delivered more
than once. The requirement on an RM Source is that it SHOULD retry transmission
of every message sent by the Application Source until it receives an
acknowledgement from the RM Destination. The requirement on the RM Destination
is that it SHOULD retry delivery to the Application Destination of every message
that it accepts from the RM Source in case of unsuccessful delivery, and that it
MUST NOT deliver a duplicate of a message that has already been
delivered."
Some additional comments:
Doug pointed out that we talk about the
RMS and RMD here, but that the wsrmp spec doesn't quite call out where the RMS
and RMD are. For example, if a WSDL output message is decorated with the RM
assertion + a DA, we would expect the server-side RMS to exist and do it's part,
and similarly the client side RMD has a role to play. I think that this is a
separate issue, and needs a bit of discussion, but the text for the DAs should
be ok however we resolve that.
<JD> I suggest that these DA defs be
inserted in the core spec: that is where users look first. They can be
associated (referred to) with policy assertions in WS RM Policy spec. It is
better that RM Policy doc refers to core RM spec, than the
reverse.
Jacques: I hoped to get this out to you earlier so you
could see our thought process, but I'm running out of time before the call. I'm
sorry that time got away from
me!
Thanks
Matt
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]