Chris:
A couple of things rather confusing in your paragraph below:
>While I think that it might be appropriate to turn RM on
or off at the operation or
>message
level, I don't agree that we would want to mix-n-match DAs across a given
>sequence,
based on the operation. If you want a different DA, use a different sequence.
>If
we only have granularity at the port-level, then carve out the operations that
require
>ordered
delivery into a separate port type and assign them to a different sequence.
- ". If you want a different DA, use a different
sequence." ). I assume you meant "...use different ports".
I believe there is no correlation so far between DAs and sequences. I assume
that several sequences could be active between RMS-RMD, and as long as they all
concern the same port, they all are subject to the same protocol policy. (and remain
orthogonal to the DA behind, not precluding a finer-grain scope of DA)
- "I don't agree that
we would want to mix-n-match DAs across a given sequence, based on
the operation..." If an RMD may span multiple service WSDL
ports (per i010 proposal) then the same RMD may have to concurrently enforce
different DAs. We do not have today a firm requirement that messages intended
to these different ports need belong to different sequences. Although there
could be trouble if protocol parameters are set differently in these WSDLs, nothing
in the specification prevents using a unique sequence for all these messages,
meaning effectively using a single sequence for several DAs. Enabling the RMS
to use different sequences based on destination endpoint, needs be
specified.
Regards,
jacques
From: Marc Goodner
[mailto:mgoodner@microsoft.com]
Sent: Wednesday, November 02, 2005
11:54 AM
To: Christopher B Ferris; wsrx
Subject: RE: [ws-rx] Proposal for
i008
+1!
Very well said Chris. To me this is even
further argument that it is a mistake to expose the DAs. The DA in effect at
the RMD does not change and should not change the RMS behavior in how it
responds to acknowledgements from the RMD.
From: Christopher B
Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, October 27, 2005
12:50 PM
To: wsrx
Subject: Re: [ws-rx] Proposal for
i008
As I have tried, apparently unsuccessfully, in the past to explain...
regardless of the DA
in
force, in effect or observed at the RMD, the source CAN ONLY know which
messages have
been
received. It can make NO assumptions (unless it wants to succumb to the Felix
Unger
ass-u-me
adage) as to which messages have been or ever will be "delivered" to
the AD.
None
Nada
Nunca
Zippidy-doo-dah
All it
can *possibly* know with any certainty is which of the messages have been
successfully
received
by the RMS.
The
job of the RMS is to ensure that messages have been received. Nothing more,
nothing less.
If it
receives an ack that suggests that a message was not received, it retransmits
that message
and
listens for an ack that indicates that the message was indeed received. It then
uses the
shampoo
methodology (lather, rinse, repeat) until the message is successfully received.
In the
case of in order delivery, you might assume that because there is a gap in the
sequence
according to the final ack received (following a Close()) that it would be safe
to
assume
(again, that word and all of its connotations) that you could create a new
sequence
starting at the first gap in the sequence and continuing from there at the
infrastructure
level, but you would likely be wrong in making such an assumption
because
you can have no guarantee what-so-ever that the message(s) prior to that
gap in
the defunct sequence will be, or have been, delivered.
With
that said, the issue is granularity of the scope of the DA as applies to the
port, operation or
message.
While I think that it might be appropriate to turn RM on or off at the
operation or
message
level, I don't agree that we would want to mix-n-match DAs across a given
sequence,
based on the operation. If you want a different DA, use a different sequence.
If we
only have granularity at the port-level, then carve out the operations that
require
ordered
delivery into a separate port type and assign them to a different sequence.
I
personally think that trying to manage application of different DAs across the
various
messages
within a given Sequence, based on the operation or whatever would be
a
mistake.
At
this point, I am no longer in favor of finer granularity than [Endpoint Policy
Subject]
for RM
because it over-complicates the model. Maybe someday we will get better
at
this, and we can contemplate per-message QoS, but I would suggest we leave that
for a
subsequent version of the protocol.
Cheers,
Christopher
Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295
Tom Rutt
<tom@coastin.com> wrote on 10/27/2005 02:45:43 PM:
> Anish Karmarkar wrote:
>
> > Tom,
> >
> > > During normal circumstances there
would actually be no extra resources
> > > required to support ordered exactly
once delivery, since each message
> > > will be received in proper order.
> >
> > We are trying to deal with non-normal
conditions in this protocol
> > (without making operation under normal
conditions non-performant).
> > Yes, under "normal" conditions
ordered delivery isn't very costly
> > because most (though not all) underlying
networks will order the
> > messages for you. But that is exactly
where this protocol and DAs are
> > useful to the higher-level application.
These non-normal conditions
> > typically occur in a "bursty"
way. To protect against that the RMD/RMS
> > require additional durability
features/resources which can be costly
> > or limited.
> >
> > This proposal seems overly restrictive
to me.
> > It assumes that it is OK to apply the most
stringent QoS to all the
> > operations within a portType. Why? You
end up paying for more than
> > what is needed. By extension one could
then argue that there is no
> > need for DAs and related policy
parameters -- everything can be made
> > ordered exactly-once -- but that is not
what we decided for issue i009.
>
> In fact, the In order DA does impact the
behaviour of how the Source
> must interpret the ack data.
>
> If a message is received before one with a
prior sequence number, it is
> acked immediately, but buffered
> for delivery. When all priors
are delivered the message can be delivered.
>
> However the catch is when the sender closes
the sequence, it got an ack
> for that message, when in fact
> it was not delivered. If the DA on the
receiving side did not include
> in order da that message would
> have been delivered.
>
> This is one of the major differences in what
is "seen" by the source
> with ordred delivery.
>
> If the DA was specified on a per operation
basis, it would avoid all
> operations having this behaviour,
> whether in order was required or not.
>
> So I would prefer to have da by operation.
>
> tom Rutt
>
> >
> > WS-policy allows one to attach polices
as the operation level. Why not
> > keep it flexible and allow the policies
to be attached at the
> > operation level as well as the endpoint
level? Does WS-policy prohibit
> > that?
> >
> > -Anish
> > --
> >
> > Tom Rutt
wrote:
> >
> >> Discussion around Issue 008:
Granularity of policy attachment
> >>
> >> For this discussion lets investigate
the potential attachment of
> >> policy at a finer level than
enpoint-subject.
> >>
> >> Assume a default semantics
associated with attaching policy at the
> >> operation level would be such that they
apply only to the input
> >> message of that operation. There may
be some benefit in resource
> >> utilization for an RMD, if it could
support different DA levels for
> >> each operation supported by that
endpoint. However this would require
> >> multiple sequences to be set up
between the source and destination,
> >> one for each level of DA required
(even thought the protocol is the
> >> same on each sequence, the actions
of the RMD may be different due to
> >> DA requirments, such as buffering
messages while waiting for prior).
> >>
> >> Since the protocol is the same on
every reliabile messaging sequence,
> >> irregardless of the agreed
destination DA level, there is no great
> >> benefit in having multiple sequences
between the same source and
> >> destination in order to support
differing DA levels for different
> >> operations.
> >>
> >> The use case of the broker interface
can be served by applying
> >> exactly once in order delivery
assurance for each operation on that
> >> endpoint. The extra cost of
buffering messages for ordered delivery,
> >> even when it is not required, will
only come into play during times
> >> of message loss.
> >>
> >> During normal circumstances there
would actually be no extra
> >> resources required to support
ordered exactly once delivery, since
> >> each message will be received in
proper order.
> >>
> >> If each operation on the endpoint is
be given the same DA support for
> >> their input messages, the endpoint
has to support the most stringent
> >> DA level requirement over that
endpoint's operations..
> >>
> >> As a design principle, the most
stringent DA level required over the
> >> endpoint's operations should
be attached to that endpoint's wsdl
> >> description.
> >>
> >> If this design principle is adhered
to, the default semantics
> >> associated with the proposal for
Issue 21 are sufficient.
> >>
> >> Lets assume that the following
default semantics apply:
> >>
> >> As a default, when rm policy
assertions are attached to a WSDL
> >> description only at endpoint subject
level, the implied semantics for
> >> all operations served by that
endpoint can be interpreted as:
> >> * each of those operations
require reliable delivery only for their
> >> input messages.
> >> * client relevant policy types
(such as retransmission interval)
> >> apply to the RMS invoking on that
Endpoint,
> >> * server relevant policy types
(such as DA levels and Ack interval)
> >> apply to the RMD at the service
Endpoint.
> >>
> >> Supporting expression of reliability
policy different for each
> >> operation of a WSDL defined
endpoint, would require attaching RM
> >> policy at the operation-subject
level.
> >>
> >> Supporting the expression of
reliability policy for the output
> >> message of a wsdl request/response
operation would require attaching
> >> rm policy at the message-subject
level.
> >>
> >> Such fine grained policy attachments
can be left as extension points
> >> to the specification..
> >>
> >> Proposed text change for Issue 008:
> >>
> >> Add the following text after the
text added for resolution of Issue 021:
> >>
> >> "
> >> Attaching reliability policy to a
wsdl description at a finer level
> >> than endpoint-subject level is
outside the scope of this version of
> >> the specification. Such out-of-scope
policy attachments are
> >> considered extension points.
> >>
> >> "
> >>
> >
>
>
> --
>
----------------------------------------------------
> Tom Rutt
email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744
Fax: +1 732 774 5133
>
>