ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] Proposal for i008
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: wsrx <ws-rx@lists.oasis-open.org>
- Date: Thu, 27 Oct 2005 15:50:11 -0400
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
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]