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

[Tom Rutt <tom@coastin.com>]

Christopher B Ferris wrote:

>Tom writes:
>  
>
one comment inline

>"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?
>  
>
We can define a fault "qos not supported" which the receiver can return 
to the sender in this case.

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


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