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