[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]