Re: [ws-rx] Proposal for i008

[Tom Rutt <tom@coastin.com>]

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