Concur *heavily*
with Chris’ comments.
Duane
From: Christopher B
Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, October 13, 2005
9:39 AM
To: ws-rx@lists.oasis-open.org
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
>
>