OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] Proposed list of issues for discussion on 10/13 conf-call



I think this unnecessarily over-complicates things.

A Sequence should treat all messages within the sequence equally IMO.
What you are asking for is an optimization, one that could be effected by sending the
two messages over different Sequences. Conversely, they could also be
sent over the same sequence with the higher QoS.

I would strongly advise against providing multiple QoS characteristics on a
message-by-message basis... it just overcomplicates things unnecessarily (IMNSHO).

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


Tom Rutt <tom@coastin.com> wrote on 10/13/2005 11:35:47 AM:

> Marc Goodner wrote:
>
> >In your discussion points on i008 you noted that having a different
> >assertion on each operation would require separate sequences for each.
> >So why would the RMS need to signal anything about the DA to the RMD?
> >  
> >
> To answer this requires on to think of the buffering that goes along
> with exactly once ordered
> delivery.
>
> Say one operation type (fooAMO) on the port only needs at most once,
> while the onther
> (fooEOIO) needs exactly once in order DA.  
>
> only fooEOIO needs to have its messages buffered, while waiting for a
> prior.  if both operations are send over the same sequence, the fooAMO
> request messages will be in the same sequence as the fooEOIO request
> messages.  If a fooEOIO message number 101 is received by the rmd, and
> message 100 was not yet received, that message 101 will be buffered
> waiting for 100 to be delivered before 100 is delivered.
>
> Now suppose message 102 is a request for a fooEOIO, it does not require
> ordered delivery, and if it
> were on a sequence which did not have ordered delivery DA in place it
> would be delivered immediately.  However on this combinded sequence it
> is buffered and it has to wait until message 100 is received.
>
> Thus if any operation needs Ordered delivery on a sequence, all
> operations will get ordered delivery, since it is impossible for the RMD
> to know what kind of operation the missing message 100 is a request for.
>
> If this were the behaviour, there would be no reason to attach policy at
> a finer level that endpoint.
>
> My own position is that endpoint policy attachment for WSRM should be
> the default, with finer grained
> attachment an extension point.  This default mechanism would not require
> negotation of DA on a sequence at creation time.
>
> Users of the extension point would have to also define how the rms
> determines which operation types to put on each of multiple concurrent
> sequences between the rms and rmd, and which sequence has which DA level
> at destination.
>
> There are other examples as well but this suffices to illustrate why
> operatio level da requirements lead to the need for multiple concurrent
> rm sequences, each with a given level of DA at the Destination.
>
> Tom Rutt
>
> >Each operation with a different DA would have its own sequence and there
> >would be no need for the RMS to signal anything. So even if your
> >proposal for i008 that kept the granularity at the endpoint subject
> >level was not accepted and the assertion did become more granular I
> >still don't see the need for the RMS to signal anything about the DA.
> >
> >Maybe I'm misinterpreting what you are trying to accomplish. Are you
> >thinking of attaching multiple DAs to the same operation if the
> >granularity of the assertion was finer? I could see that if you could do
> >this you would require additional features added to the protocol to
> >signal which DA the RMS chose. I don't think this makes any sense
> >though. Why would an RMS choose any one DA over another for the same
> >operation? Why would an RMD expose different DAs for the same operation?
> >
> >So either way I think i006 should be closed with no action.
> >
> >
> >-----Original Message-----
> >From: Tom Rutt [mailto:tom@coastin.com]
> >Sent: Wednesday, October 12, 2005 2:28 PM
> >To: Marc Goodner
> >Cc: Anish Karmarkar; Christopher B Ferris; ws-rx@lists.oasis-open.org
> >Subject: Re: [ws-rx] Proposed list of issues for discussion on 10/13
> >conf-call
> >
> >Marc Goodner wrote:
> >
> >  
> >
> >>I don't think i006 needs to be linked to the others. As Tom already
> >>proposed on this issue no matter the outcome of i008 and i021 this
> >>    
> >>
> >would
> >  
> >
> >>be outside the scope of WS-RM. Why don't we go ahead and try to close
> >>    
> >>
> >at
> >  
> >
> >>least that one?
> >>
> >>
> >>    
> >>
> >I disagree, if we have operation level policy attachment, then we need a
> >
> >way to signal which DA
> >level is on a given sequence.
> >
> >My proposal to 6 assumed the proposal to 8 would pass.
> >
> >Tom Rutt
> >
> >Thus we need to agree to 8 before we can discuss 006.
> >
> >Tom Rutt
> >
> >  
> >
> >>-----Original Message-----
> >>From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> >>Sent: Wednesday, October 12, 2005 11:56 AM
> >>To: tom@coastin.com
> >>Cc: Christopher B Ferris; ws-rx@lists.oasis-open.org
> >>Subject: Re: [ws-rx] Proposed list of issues for discussion on 10/13
> >>conf-call
> >>
> >>Tom Rutt wrote:
> >>
> >>
> >>    
> >>
> >>>Christopher B Ferris wrote:
> >>>
> >>>  
> >>>
> >>>      
> >>>
> >>>>Sanjay,
> >>>>
> >>>>I can appreciate that POV, but frankly, I think that the protocol
> >>>>    
> >>>>
> >>>>        
> >>>>
> >>spec
> >>
> >>
> >>    
> >>
> >>>>is far more important.
> >>>>There aren't many outstanding issues and it would be great if we
> >>>>    
> >>>>
> >>>>        
> >>>>
> >>could
> >>
> >>
> >>    
> >>
> >>>>close on the issues
> >>>>we have and nail down the protocol spec sooner rather than later.
> >>>>
> >>>>    
> >>>>
> >>>>        
> >>>>
> >>>Issue 006 could have impact on the protocol spec, and it depends on
> >>>issues 008 and 021.
> >>>
> >>>However, I agree that the email around these proposed solutions has
> >>>  
> >>>
> >>>      
> >>>
> >>not
> >>
> >>
> >>    
> >>
> >>>yet reached concensus.
> >>>
> >>>Thus I do not mind postponing resolution of 6, 8, and 21 until further
> >>>  
> >>>
> >>>      
> >>>
> >>
> >>
> >>    
> >>
> >>>discussion occurs on the list.
> >>>
> >>>  
> >>>
> >>>      
> >>>
> >>Postponing these issues until there is further discussion make sense to
> >>    
> >>
> >
> >  
> >
> >>me too.
> >>
> >>-Anish
> >>--
> >>
> >><snip/>
> >>
> >>
> >>
> >>    
> >>
> >
> >
> >  
> >
>
>
> --
> ----------------------------------------------------
> 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]