Re: [ws-rx] Proposal to resolve Issue 006

[Tom Rutt <tom@coastin.com>]

Anish Karmarkar wrote:

> Tom Rutt wrote:
>
>> Description
>>
>>                Is there a requirement that the sender can assert that 
>> the receiver must
>>                deliver a particular reliability assurance on a given 
>> sequence?
>>
>> Discussion         It has been agreed that the protocol is the same 
>> on any ws -rm Sequence, regardless of DA level agreements in place 
>> between RMD and Destination Application.    There is no need to have 
>> a standard protocol mechanism for the RMS to signal DA requirments on 
>> the sequence for the RMD.
>>
>> If reliaiblity policy is attached to a destination endpoint at a 
>> finer level of granularity than endpoint subject level,  an 
>> implementaton (extension beyond normal conformance) would have to use 
>> means outside the scope of this standard to convey such requirements 
>> (e.g., RMD could be aware of the wsdl description).
>>
>
> I don't see this issue as being tied to finer level of granularity. 
> Say the granularity is at the message-level or operation-level. When 
> the receiver receives a message, it is clear from the message which 
> operation is being invoked.

Knowing what is invoked is not the problem.  The problem is that it is 
impossible for the RMD to know what the operation type of a missing 
message in a sequence is.

As I already stated in my response to Marc G:

Say one operation type (fooAMO) on the port only needs at most once, 
while the onther
(fooEOIO) needs exactly once in order DA.  
only fooEOIO needs to have its messages buffered, while waiting for a 
prior.  if both operations are send over the same sequence, the fooAMO 
request messages will be in the same sequence as the fooEOIO request 
messages.  If a fooEOIO message number 101 is received by the rmd, and 
message 100 was not yet received, that message 101 will be buffered 
waiting for 100 to be delivered before 100 is delivered.

Now suppose message 102 is a request for a fooEOIO, it does not require 
ordered delivery, and if it
were on a sequence which did not have ordered delivery DA in place it 
would be delivered immediately.  However on this combinded sequence it 
is buffered and it has to wait until message 100 is received.
Thus if any operation needs Ordered delivery on a sequence, all 
operations will get ordered delivery, since it is impossible for the RMD 
to know what kind of operation the missing message 100 is a request for.

If this were the behaviour, there would be no reason to attach policy at 
a finer level that endpoint.

My own position is that endpoint policy attachment for WSRM should be 
the default, with finer grained
attachment an extension point.  This default mechanism would not require 
negotation of DA on a sequence at creation time.

Users of the extension point would have to also define how the rms 
determines which operation types to put on each of multiple concurrent 
sequences between the rms and rmd, and which sequence has which DA level 
at destination.

There are other examples as well but this suffices to illustrate why 
operatio level da requirements lead to the need for multiple concurrent 
rm sequences, each with a given level of DA at the Destination.

Tom Rutt

>
> The issue is about -- how does a sender indicate to the receiver that 
> a particular QoS is required for a particular Sequence? This may be 
> needed because the receiver supports multiple QoS and the sender wants 
> to choose OR the sender is not aware of the QoS being implemented and 
> wants to assert the QoS for the Sequence (and have the receiver fault 
> on the CS message if it cannot).
>
> One way I can think of doing this is to include the 
> wsrm:DeliveryAssertion (as defined by the resolution of issue i009) as 
> an optional element in the CreateSequence message and define a 
> specific fault that the RMD can send when the wsrm:DeliveryAssertion 
> is not supported/allowed.
>
> -Anish
> -- 
>
>> Proposed resolution to Issue 006:
>>
>> close issue with no changes to specfication.
>>
>>
>


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133