[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
Doug Davis wrote:
I think Doug is raising yet another issue, can a sequene span multiple
ports.
Tom Rutt
> 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
>
>
>
--
----------------------------------------------------
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]