OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] Proposal for i008


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
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]