RE: [ws-rx] Use Case for having Reliability assurances at finer granularity than Port Type

Title: RE: [ws-rx] Use Case for having Reliability assurances at finer granularity than Port Type

Doug,

I think this is the case here.

abbie

> -----Original Message-----

> From:  [mailto:] 

> Sent: Tuesday, June 28, 2005 1:41 PM

> To: 

> Cc: Christopher B Ferris; Patil, Sanjay; Paul Fremantle; wsrx

> 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: 

> >> blog: http://webpages.charter.net/chrisfer/blog.html

> >> phone: +1 508 377 9295

> >>

> >> "Patil, Sanjay" <> 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:] 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: 

> >>>> blog: http://webpages.charter.net/chrisfer/blog.html

> >>>> phone: +1 508 377 9295

> >>>>

> >>>> Paul Fremantle <> 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

> >>>>> 

> >>>>> "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 <> on 27/06/2005 22:12:41

> >>>>>

> >>>>> Please respond to 

> >>>>>

> >>>>> To:    Paul Fremantle/UK/IBM@IBMGB

> >>>>> cc:    wsrx <>

> >>>>> 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

> >>>>>> 

> >>>>>> "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 <> on 27/06/2005 21:59:49

> >>>>>>

> >>>>>> Please respond to 

> >>>>>>

> >>>>>> To:    wsrx <>

> >>>>>> 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: ; 

> >>>>>> Tel: +1 732 801 5744          Fax: +1 732 774 5133

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>

> >>>>>>         

> >>>>>

> >>>>> --

> >>>>> ----------------------------------------------------

> >>>>> Tom Rutt           email: ; 

> >>>>> Tel: +1 732 801 5744          Fax: +1 732 774 5133

> >>>>>

> >>>>>

> >>>>>

> >>>>>

> >>>>>       

> >>>>

> >>>>     

> >>

> >>

> >>  

> >>

> > 

> > 

> 

>