Re: [ws-rx] Use Case for having Reliability assurances at finergranularity than Port Type

[Doug Bunting <Doug.Bunting@Sun.COM>]

Tom and Chris,

Am I correct that we are discussing two separate issues here?  On one 
hand, we have the already-logged issue about senders asserting 
requirements for reliability assurance on the receiver.  On the other, 
we have the question Tom originally raised in this thread about the 
granularity of a receiver's declarations.

If I am correct, could we at least split these issues into separate threads?

thanx,
	doug

On 28/06/05 10:22, Tom Rutt wrote:
> Christopher B Ferris wrote:
> 
>> Sanjay writes: "If this requirement seems reasonable, then Tom's 
>> concern about not allowing advertisement of
>> RM policies per operation also seems reasonable to me! Let us at least 
>> log this as a potential issue."
>>
>> In my previous note, I indicated that it was reasonable to advertise 
>> the capabilities of the destination endpoint. However, that is
>> very different than what Tom was asking for which was that the source 
>> be able to assert the QoS.
>>  
>>
> In my example, the endpoint has four operations.  The reliability qos 
> needs are different for these operations.
> 
> The credit, debit operations need duplicate elimintation and ordered 
> delivery.
> 
> the update only needs guaranteed delivery.
> 
> The query operaton needs no reliability qos.
> 
> How is the server going to advertise this mixed bag of reliability qos 
> on a single endpoint?
> 
> Tom Rutt
> 
>> Tom wrote:
>>
>> "The current protocol has no way to have the message sender signal 
>> what reliabilty qos should be applied to a message.  A simple 
>> mechanism, with a indication of the qos level requested in the create 
>> sequence operation would allow a sender to set up individual sequences 
>> for each qos level required.  If the receiving endpoint does not 
>> support the requested level of Qos, a 'not supported feature' fault 
>> can be returned."
>>
>> Again, I just don't see a use case for having a service which offered 
>> its clients the ability to have AtLeastOnce or AtMostOnce
>> QoS semantics at the client's discretion. I certainly CAN see a use 
>> case for giving the client the visibility as to the QoS capabilities
>> of the service endpoint and using that information to decide whether 
>> it wanted to use that service or select another
>> that offered the desired QoS.
>>
>> 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
>>
>> "Patil, Sanjay" <sanjay.patil@sap.com> wrote on 06/28/2005 02:29:33 AM:
>>
>>  
>>
>>> Can the Source really be unaware of the contract between the RM
>>> Destination and the Application destination in all the cases? For
>>> example, how does a Source RM decide bracketing a set of messages handed
>>> by Source Application in different Sequences? Let us look at the
>>> semantics of TerminateSequence. The contributed material says - The RM
>>> Destination can safely reclaim any resources associated with the
>>> Sequence upon receipt of the <TerminateSequence> message. Doesn't this
>>> mean that the Source is *aware* of the potential state on the
>>> Destination RM?
>>>
>>> Consider that the Source Application has handed 10 messages to its
>>> Source RM. Could the Source RM now independently decide whether all the
>>> 10 messages should be sent in one single Sequence or break them into
>>> multiple Sequences? It is arguable that this decision be based on the
>>> contract between Source RM and Source Application? But without the
>>> Source RM being *sure* about the Destination RM's capabilities, why
>>> should it care for spending resources in creating one single Sequence
>>> for all the 10 messages. On the other hand, if the Source RM chooses to
>>> split the 10 messages into different Sequences, then the Destination RM
>>> can not possibly establish ordering of the messages received as part of
>>> the different Sequences. Doesn't it seem logical that whenever the
>>> Destination RM is willing to dedicate resources for ordering, etc, it
>>> also advertises its corresponding capabilities. If this requirement
>>> seems reasonable, then Tom's concern about not allowing advertisement of
>>> RM policies per operation also seems reasonable to me! Let us at least
>>> log this as a potential issue.
>>>
>>> Thanks,
>>> Sanjay
>>>   
>>>
>>>> -----Original Message-----
>>>> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] Sent: 
>>>> Monday, Jun 27, 2005 15:20 PM
>>>> To: Paul Fremantle
>>>> Cc: wsrx
>>>> Subject: Re: [ws-rx] Use Case for having Reliability assurances at 
>>>> finer granularity than Port Type
>>>>
>>>> Tom writes:
>>>>
>>>> "The current protocol has no way to have the message sender signal what
>>>> reliabilty qos should be applied to a message."
>>>>
>>>> Frankly, I don't get this requirement at all. Maybe it's my nature 
>>>> to rebel when someone tells me what to do, but I really don't 
>>>> understand
>>>> why you'd want to assert on a pairwise-basis, whether duplicates are
>>>> eliminated, or the messages must be processed exactly once.
>>>>
>>>> If we have 4 nodes: A, B, C and D with D serving as the Destination 
>>>> and A, B and C serving as the Source of messages to the service
>>>> offered at D, why would A choose a quality of service different than
>>>> B and/or C? Wouldn't it be FAR more likely that D would effect a 
>>>> consistent QoS (again, as a contract between its RM Destination and
>>>> its Application Destination roles) that A, B and C would avail 
>>>> themselves
>>>> of when using the RM protocol? Keep in mind that the protocol is the 
>>>> same
>>>> as perceived on the wire regardless of QoS effected at the 
>>>> destination endpoint.
>>>>
>>>> Can someone come up with a valid use case that would require the 
>>>> ability
>>>> of the Source endpoint to assert the QoS on the part of the Destination
>>>> where the QoS itself would likely vary from one Source endpoint to 
>>>> another?
>>>> Furthermore, since effecting QoS would require some utilization of 
>>>> resources
>>>> at the Destination endpoint (e.g. durable store for unprocessed 
>>>> messages)
>>>> is it realistic to have the Source assert a requirement that the 
>>>> Destination
>>>> cannot meet because of constraints it might have on those resources?
>>>>
>>>> Personally, I would think that giving a Destination the ability to 
>>>> advertise
>>>> the QoS that is observed at the endpoint by virtue of the QoS 
>>>> contract that the Application
>>>> Destination has with the RM Destination combined with any 
>>>> capabilities that the Application
>>>> Destination itself (e.g. elimination of duplicates) and allowing a 
>>>> Source
>>>> endpoint to choose whether or not to use the service (e.g. whether 
>>>> the QoS
>>>> meets its expectations) is a more appropriate way to go.
>>>>
>>>> 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
>>>>
>>>> Paul Fremantle <pzf@uk.ibm.com> wrote on 06/27/2005 05:17:27 PM:
>>>>
>>>>     
>>>>
>>>>>
>>>>>
>>>>> Tom
>>>>>
>>>>> I agree that the current spec doesn't allow that. However,       
>>>>
>>>> in your use case
>>>>     
>>>>
>>>>> below I imagine that the service provider could decide the       
>>>>
>>>> QoS required per
>>>>     
>>>>
>>>>> operation type.
>>>>>
>>>>> Paul
>>>>>
>>>>> Paul Fremantle,
>>>>>
>>>>> STSM, WebServices standards and architecture
>>>>> Hursley WebServices Team
>>>>> Consulting IT Specialist
>>>>> IBM Hursley Lab (MP 189)
>>>>> Winchester, SO21 2JN, UK
>>>>>
>>>>> ph+fax    44 (0) 1962 815 078
>>>>> int ph: 245 078
>>>>> pzf@uk.ibm.com
>>>>> "God, however, has chosen the most perfect world, that is to       
>>>>
>>>> say the one
>>>>     
>>>>
>>>>> which is at the same time the simplest in hypotheses and the       
>>>>
>>>> richest in
>>>>     
>>>>
>>>>> phenomena." Liebniz
>>>>>
>>>>> Tom Rutt <tom@coastin.com> on 27/06/2005 22:12:41
>>>>>
>>>>> Please respond to tom@coastin.com
>>>>>
>>>>> To:    Paul Fremantle/UK/IBM@IBMGB
>>>>> cc:    wsrx <ws-rx@lists.oasis-open.org>
>>>>> Subject:    Re: [ws-rx] Use Case for having Reliability       
>>>>
>>>> assurances at finer
>>>>     
>>>>
>>>>>       granularity than Port Type
>>>>>
>>>>>
>>>>> Paul Fremantle wrote:
>>>>>
>>>>>       
>>>>>
>>>>>> Tom
>>>>>>
>>>>>> Is that a correct reading of the specification? I thought that the
>>>>>> restriction to portType is the WSRM Policy. Since the         
>>>>
>>>> policy does not
>>>>     
>>>>
>>>>>> define the GD, DE, or OD, then this does not affect those. As I 
>>>>>>         
>>>>
>>>> understand
>>>>     
>>>>
>>>>>> the submitted spec qos's are based on a private contract         
>>>>
>>>> between the RM
>>>>     
>>>>
>>>>>> destination and the application destination, which could         
>>>>
>>>> well be more
>>>>     
>>>>
>>>>>> finely grained than per porttype since it is not defined in         
>>>>
>>>> the spec or
>>>>     
>>>>
>>>>>> policy at all.
>>>>>>
>>>>>>
>>>>>>         
>>>>>
>>>>> I did not want to put all the details in the first mail, but your
>>>>> question begs that I bring up one of my
>>>>> major concerns with the ws-reliable messageing protocol.
>>>>>
>>>>> The current protocol has no way to have the message sender       
>>>>
>>>> signal what
>>>>     
>>>>
>>>>> reliabilty qos should be applied
>>>>> to a message.  A simple mechanism, with a indication of the qos level
>>>>> requested in the create sequence operation
>>>>> would allow a sender to set up individual sequences for each       
>>>>
>>>> qos level
>>>>     
>>>>
>>>>> required.  If the receiving endpoint does not support the requested
>>>>> level of Qos, a "not supported feature" fault can be returned.
>>>>>
>>>>> Currently the spec seems to indicate that an endpoint will       
>>>>
>>>> apply its own
>>>>     
>>>>
>>>>> qos level appropriate with the application.
>>>>>
>>>>> My point is that the protocol should enable a sender to express
>>>>> different Qos levels per operation type on an endpoint.
>>>>>
>>>>> If there is some other way to enable this (eg. policy or wsdl
>>>>> decorations) I am open for discussion.
>>>>>
>>>>> I just feel this is a requirement that is not met by the existing 
>>>>>       
>>>>
>>>> protocol.
>>>>     
>>>>
>>>>>> Paul
>>>>>>
>>>>>> Paul Fremantle,
>>>>>>
>>>>>> STSM, WebServices standards and architecture
>>>>>> Hursley WebServices Team
>>>>>> Consulting IT Specialist
>>>>>> IBM Hursley Lab (MP 189)
>>>>>> Winchester, SO21 2JN, UK
>>>>>>
>>>>>> ph+fax    44 (0) 1962 815 078
>>>>>> int ph: 245 078
>>>>>> pzf@uk.ibm.com
>>>>>> "God, however, has chosen the most perfect world, that is         
>>>>
>>>> to say the one
>>>>     
>>>>
>>>>>> which is at the same time the simplest in hypotheses and         
>>>>
>>>> the richest in
>>>>     
>>>>
>>>>>> phenomena." Liebniz
>>>>>>
>>>>>> Tom Rutt <tom@coastin.com> on 27/06/2005 21:59:49
>>>>>>
>>>>>> Please respond to tom@coastin.com
>>>>>>
>>>>>> To:    wsrx <ws-rx@lists.oasis-open.org>
>>>>>> cc:
>>>>>> Subject:    [ws-rx] Use Case for having Reliability         
>>>>
>>>> assurances at finer
>>>>     
>>>>
>>>>>>      granularity than Port Type
>>>>>>
>>>>>>
>>>>>>
>>>>>> The current WS-reliable messaging contribution does not support the
>>>>>> application of reliability quality of service
>>>>>> at a finer granularity than port type.
>>>>>>
>>>>>> I provide an example interface definition (which would map to a WSDL
>>>>>> port type)
>>>>>>
>>>>>> 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}
>>>>     
>>>>
>>>>>> }
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> For this use case, the sender should be able to set up two         
>>>>
>>>> Reliability
>>>>     
>>>>
>>>>>> message sequences,
>>>>>> one with all qos enabled,
>>>>>> the other with only Guaranteed delivery enabled.
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> ----------------------------------------------------
>>>>>> Tom Rutt           email: tom@coastin.com; trutt@us.fujitsu.com
>>>>>> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>
>>>>> -- 
>>>>> ----------------------------------------------------
>>>>> Tom Rutt           email: tom@coastin.com; trutt@us.fujitsu.com
>>>>> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>       
>>>>
>>>>     
>>
>>
>>  
>>
> 
>