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
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 13 Oct 2005 12:38:47 -0400
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]