[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 finergranularity 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]