ws-rx message

Subject: Re: [ws-rx] Use Case for having Reliability assurances at finer granularitythan Port Type

From: Doug Davis <dug@us.ibm.com>
To: tom@coastin.com
Date: Tue, 28 Jun 2005 15:29:47 -0400

One thing to consider is whether or not sequences can/should be tied to a port. For example, in one direction, should the spec allow for defining different qos levels per operation? Or, in the other direction, should it allow a single sequence to span multiple ports? In an old version of the RM spec it was much more vague and allowed for an M-N relationship, meaning multiple RM sources and destination could share a single sequence. In the current version of the spec it is much more restrictive and requires it to be between a single RM source and single RM destination. But clearly there are use cases where different levels of granularity are useful. Tom (I think) already gave one where it was needed on a per operation basis. Having a single sequence span multiple ports (much like an MQ queue does) could be needed as well. I'd like the issue to include both requirements.
thanks,
-Doug

Tom Rutt <tom@coastin.com>

06/28/2005 03:16 PM

Please respond to
tom

To	Paul Fremantle <pzf@uk.ibm.com>
cc	Doug Bunting <Doug.Bunting@Sun.COM>, Christopher B Ferris/Waltham/IBM@IBMUS, "Patil, Sanjay" <sanjay.patil@sap.com>, 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: >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

Follow-Ups:
- Re: [ws-rx] Use Case for having Reliability assurances at finer granularitythan Port Type
  - From: Tom Rutt <tom@coastin.com>

References:
- Re: [ws-rx] Use Case for having Reliability assurances at finer granularitythan Port Type
  - From: Tom Rutt <tom@coastin.com>