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

[Jeff Mischkinsky <jeff.mischkinsky@oracle.com>]

On Jun 28, 2005, at 5:20 AM, 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.

What about choosing between various QoS that and endpoint supports? Is 
that the same thing as a source "asserting" a QoS?

jeff

>
> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
--
Jeff Mischkinsky					jeff.mischkinsky@oracle.com
Director, Web Services Standards		+1(650)506-1975
Consulting Member Technical Staff           500 Oracle Parkway, M/S 4OP9
Oracle                                                              
Redwood Shores, CA 94065