[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Use Case for having Reliability assurances at finer granularity than Port Type
Doug,
I think this is the case here.
abbie
> -----Original Message-----
> From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM]
> Sent: Tuesday, June 28, 2005 1:41 PM
> To: tom@coastin.com
> Cc: Christopher B Ferris; Patil, Sanjay; Paul Fremantle; wsrx
> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >>
> >
> >
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]