[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
Christopher B Ferris wrote: >Tom writes: > > one comment inline >"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? > > We can define a fault "qos not supported" which the receiver can return to the sender in this case. >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]