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] How does Receiver Endpoint assert Reliability QOS perOperation

Tom Rutt wrote:

> Based on the discussions of my past emails, I would like to have this 
> mail start a new thread on just a receiver
> endpoint issue..
> The question is:  How does a receiving endpoint assert the reliability 
> qos level it supports on a per operation basis?

I just realized that I have been carrying another asumption pertaining 
to this issue which might not be obvious to others.

So I will explicitly explain.

Given  a single endpoint having some operation types for which at least 
once and/or at most once assurance suffices, and others for which 
ordered delivery is supported, it could benefit from having two 
reliability sequences concurrently running:  one upon which ordered 
delivery is implied, and another which does not support ordered 
delivery.  Since ordered delivery requires the buffering of held 
messages on the receiving side, it would benefit from such a 
partitioning across reliable message sequences.

While some implementation might just apply the strongest case qos to any 
reliabile sequence on that receiving endpint,
the spec should allow the kind of optimizations that multiple message 
sequences per receiving endpoint allow.

Tom Rutt

> Example:  for the following interface definition:
> Interface (Broker){
> Operation Buy(in AccountNo, in StockName, in NumberOfShares):
> Operation Sell(in AccountNo, in StockName, in NumberOfShares);
> Operation UpdateInfo(in AccountNo, in CustomerAddress, in 
> CustomerPhoneNo);
> Operation query (in AccountNo, out SequenceOf {StockName, NumberOfShares}
> }
> when bound to a soap endpoint,
> Buy and Sell need to be protected for guaranteed delivery, duplicate 
> elim, and ordered delivery.
> UpdateInfo only needs to be protected for guaranteed delivery (it is 
> idempotent).
> Query needs no reliability Qos.
> the query operation would not use ws-reliability at all.

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]