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

[Tom Rutt <tom@coastin.com>]

Christopher B Ferris wrote:

>
> 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 agree with Chris's sentiments.  I do not like the restriction that 
requires the RMD to be aware of the operation type (if it does not have 
to look at the body it will be much easier to implement)   It gets even 
worse with security concerns,n making the rmd look into the soap body to 
do its job.

However, there are other ways to realize different DA per operation type 
on an endpoint.  Use multiple seuqnces is one that comes to mind as a 
simple approach.

If we allow attachment of DA policy at Operation binding level, then the 
easiest
way to allow this to be expressed at run time is by having the rms and 
rmd set up multiple
sequences, each with a specific DA associated with it (as anish suggests 
a simple element
could be added to the create sequence exchange, to express the da level 
for that sequence).

But first we have to resolve issue 008, in my opinion.  If issue 008 
allows attaching policy below endpoint subject, then a negtiation in 
create sequence is a simple way to realize this at run time.

If Issue 008 does not allow attachment of policy below endpoint subject 
level, then the need is less
for the negotiation of DA by RMS.

Others seem to think the negotiation of DA is usefule outside the 
granularity of policy, but that
involves different arguments, which I have not personally championed yet.

Tom Rutt

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



-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133