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

[Tom Rutt <tom@coastin.com>]

Paul Fremantle wrote:

>Doug
>
>I think we have three issues:
>
>1) Source-based assertion
>2) Granularity of publishing of policy
>3) Declaration of Delivery Assurances.
>
>The reason add #3 is because  - at the moment - Tom's point about
>publishing the different delivery assurances is moot. In the specification,
>the delivery assurances are part of a private contract between the RM
>destination and the application destination. They are not published and
>they are not visible to the "outside" world - i.e. to the source.
>
>  
>
This problem is a little more complicated. 

The first question to tackle is how a receiving endpoint can assert what 
reliability qos is supports for each operation
in that endpoint.  Perhaps this could be done staticaly on a wsdl 
description by port type,
but in some cases it may be for a particular service endpoint.  

The tricky part is when there are differences in the qos levels across 
the operations of a port, there could be a need to
have more than one sequence created for that endpoint, eg/. one for 
ordered delivery, the other without.

Then we have the problem of letting the sender know which of these 
sequences to use for each operation.

Tom Rutt

>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
>
>Doug Bunting <Doug.Bunting@Sun.COM>@Sun.COM on 28/06/2005 18:40:42
>
>Sent by:    Doug.Bunting@Sun.COM
>
>
>To:    tom@coastin.com
>cc:    Christopher B Ferris <chrisfer@us.ibm.com>, "Patil, Sanjay"
>       <sanjay.patil@sap.com>, Paul Fremantle/UK/IBM@IBMGB, wsrx
>       <ws-rx@lists.oasis-open.org>
>Subject:    Re: [ws-rx] Use Case for having Reliability assurances at finer
>       granularity than Port Type
>
>
>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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>          
>>>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>  
>


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