Re: [ws-rx] Proposal for i008

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

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.

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