ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon use case
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Mon, 8 May 2006 08:19:56 -0400
DougB,
Who said reliable notif w/o reliable
subscription?
Its too bad you think things like reliable
notifications, unreliable-in/reliable-out,
out-only, allowing an RMS to choose
which sequence a message goes into...
are all 'bizarre'.
I would point out that most of my questions
on paul's proposal were simply based
on trying to understand how someone
would actually implement it. Its interesting
in theory to simply say "oh, just
have the client send an Offer and the server can
use that" - when in practice I
think I've shown there are lots of open questions around
using some of the technique Paul has
proposed. And yes, I agree its confusing
because this "narrowly scoped"
proposal is claiming to do things its just not possible
to do (as currently defined anyway).
The other proposal, in my unbiased opinion :-),
is not confusing, it does just one very
simple thing - creates a backchannel which is
at the heart of issue 089. It doesn't
try to do anything more than that, which is why
all of the types of questions that have
been raised with Paul's proposal do not
exist in ours. I think it would
fairly easy to claim that Paul's proposal actually goes
well beyond the scope of i089 because
if, in the end, his proposal does things like
links two sequences then we're no longer
just dealing with anon EPRs.
-Doug
Doug.Bunting@Sun.COM wrote on 05/08/2006 01:19:20
AM:
> This is all very confusing but I think can be summed up thus: Dug's
> proposal does more than WS-RM protocol or the WS-RX TC charter needs
or
> allows. Paul's proposal doesn't do everything Dug wants. Did
I miss
> something?
>
> As a number of people on the last call noted, most of us are listening
> to an argument with no clear movement toward a compromise. I
hope Paul
> and Dug are having offline discussions to reach a conclusion the rest
of
> us can support.
>
> If we must implement something on the table now, I prefer the more
> narrowly scoped proposal. I have yet to hear justification for
the
> bizarre scenarios you're describing Dug. (Reliable notification
without
> reliable subscription, why?)
>
> thanx,
> doug
>
> On 07/05/06 18:38, Doug Davis wrote:
> > So, for every request message that had a response there would
have to be
> > a GetMessage? 10 requests == 10 GetMessages? Doesn't
seem optimal :-)
> > Or if you mean that a GetMessage+msgID can pull back any response
related
> > to any request from the client->server seq, then how long
does the
> > server need
> > to maintain this state info? It would need to save every
request
> > msgID since it
> > might appear later on in a GetMessage.
> >
> > And, even if it did, can it really make any assumption about
that
> > message and any
> > message flowing in the other direction? Remember, under
normal
> > circumstances an
> > RMS could decide, for any variety of reasons, why a message goes
into
> > a sequence.
> > You seem to be implying that by passing in a msgID that _all_
> > responses related to
> > any message associated with the client->server seq (as correlated
by
> > this msgID)
> > MUST then use this Offered sequence - seems a bit restrictive.
Or, if
> > not MUST, then
> > it at least implies that it SHOULD, and if not either of those
then
> > what other sequence
> > can the server use since the client has no way of knowing when
to
> > Offer any other.
> >
> > I really don't understand the point of the Offered sequence as
> > currently specified in
> > your proposal. Without any additional correlation info what can
the
> > server possibly
> > assume its used for? It doesn't know which endpoint sent
it. It
> > seems like the only
> > option available with your proposal is the Offered sequence of
the
> > original
> > client->server CS msg - and if either of those sequences
> > close/terminate early then
> > all bets are off. And I think it links the two sequences
pretty
> > tightly - something I thought
> > we were trying to avoid.
> >
> > -Doug
> >
> >
> > Paul Fremantle <paul@wso2.com> wrote on 05/05/2006 01:14:38
PM:
> >
> > > Actually that was exactly the motivation for allowing the
GetMessage to
> > > include a messageID for relatesTo matching. However, I am
not yet
> > > convinced that the use case of an anon client shared across
multiple
> > > endpoints is really so useful. I can't imagine a case in
which this
> > > would be necessary. The scenarios for a shared sequence
across an
> > > endpoint seem to imply some cluster of machines or corporate
gateway
> > and
> > > these usually have well defined endpoints. Alternatively,
its possible
> > > that a gateway could do its own correlation of responses
back to the
> > > correct endpoint.
> > >
> > > If you can persuade me that this is a highly valuable and
very
> > important
> > > scenario I'd be happy to add the <wsa:MessageID> back
into the proposal
> > > which would fix this. However, at the moment I would lean
towards
> > adding
> > > a warning "here be dragons", that alerts implementors
to this issue.
> > > Since the situation is purely initiated by the "client"
then a client
> > > RMS should not initiate an offered anonymous sequence if
it is not able
> > > to distribute the messages to the right endpoint.
> > >
> > > Paul
> > >
> > >
> > >
> > >
> > > Doug Davis wrote:
> > > >
> > > > Maybe I didn't follow the thread but I thought the
problem related to
> > > > how, when a
> > > > client sends a GetMessage, does the server know which
client is
> > > > sending the
> > > > message? It can't just send any message in the
sequence to any
> > client
> > > > who
> > > > happens to be an RMD for that sequence. If the
RMD spans multiple
> > > > endpoints
> > > > the server needs to make sure that the messages for
clientA go to
> > > > clientA and
> > > > not clientB. SequenceID alone isn't enough -
so what other
> > > > correlation does
> > > > Paul's proposal use? Or is the answer that Paul's
solution only
> > works
> > > > for
> > > > one endpoint per sequence? If so, we have yet
another restriction on
> > > > the use-cases
> > > > that it supports.
> > > >
> > > > -Doug
> > > >
> > > >
> > > >
> > > > *"Marc Goodner" <mgoodner@microsoft.com>*
> > > >
> > > > 05/04/2006 09:22 PM
> > > >
> > > >
> > > > To
> > > > Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
> > > > cc
> > > >
> > > > Subject
> > > > RE: [ws-rx] Minimalist GetMessage proposal:
the anon use case
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > So how does telling the other side where to send the
RM protocol
> > > > messages not solve the problem you perceive Doug?
> > > >
> > > > Marc Goodner
> > > > Technical Diplomat
> > > > Microsoft Corporation
> > > > Tel: (425) 703-1903
> > > > Blog: _http://spaces.msn.com/mrgoodner/_
> > > >
> > > >
> > ------------------------------------------------------------------------
> > > >
> > > > *From:* Doug Davis [mailto:dug@us.ibm.com] *
> > > > Sent:* Thursday, May 04, 2006 6:17 PM*
> > > > To:* ws-rx@lists.oasis-open.org*
> > > > Subject:* RE: [ws-rx] Minimalist GetMessage proposal:
the anon use
> > case
> > > >
> > > >
> > > > If I remeber correctly, that part of the spec just
tells the other
> > > > side where to send RM protocol messages to for the
Offered sequence -
> > > > since it otherwise has no idea where they go.
> > > > -Doug
> > > >
> > > > *"Durand, Jacques R." <JDurand@us.fujitsu.com>*
> > > >
> > > > 05/04/2006 07:39 PM
> > > >
> > > >
> > > > To
> > > > Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
> > > > cc
> > > >
> > > > Subject
> > > > RE: [ws-rx] Minimalist GetMessage proposal:
the anon use case
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > That crossed my mind too…
> > > > But then the spec seems to rule that case out in case
of offered
> > > > sequences, given the exclusive scoping to one endpoint
assumed by:
> > > > wsrm:Offer/wsrm:Endpoint (WD12, Line283)
> > > >
> > > > Jacques
> > > >
> > > >
> > > >
> > > >
> > > >
> > ------------------------------------------------------------------------
> > > >
> > > > *
> > > > From:* Doug Davis [mailto:dug@us.ibm.com] *
> > > > Sent:* Thursday, May 04, 2006 3:53 PM*
> > > > To:* ws-rx@lists.oasis-open.org*
> > > > Subject:* RE: [ws-rx] Minimalist GetMessage proposal:
the anon use
> > case
> > > >
> > > >
> > > > I'm a bit lost - too much email on this today :-) but
even if there
> > > > as a wsrm:Identifier
> > > > in a message that doesn't tell you which client it
is since a
> > sequence
> > > > can span
> > > > multiple endpoints.
> > > > -Doug
> > > >
> > > > *"Durand, Jacques R." <JDurand@us.fujitsu.com>*
> > > >
> > > > 05/04/2006 03:17 PM
> > > >
> > > >
> > > >
> > > >
> > > > To
> > > > "Paul Fremantle" <paul@wso2.com>
> > > > cc
> > > > "wsrx" <ws-rx@lists.oasis-open.org>
> > > > Subject
> > > > RE: [ws-rx] Minimalist GetMessage proposal:
the anon use case
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > - The case reliable-in/reliable-out works quite well,
provided the RMS
> > > > does the correlation between initial sequence and offered
seq, as
> > > > recommended in 4.2.
> > > > - The case unreliable-in/reliable-out seems to need
the "hint" you
> > > > mention in 4.2., plus some other way to offer a sequence
than the CS
> > > > carrier.
> > > >
> > > > In any case, the many-anonymous(RMD)clients- to-one-(RMS)server
> > appears
> > > > to be quite a common case (many users of the same WS
instance), to
> > > > justify adding back 4.2 in your proposal...
> > > >
> > > > Jacques
> > > >
> > > > -----Original Message-----
> > > > From: Paul Fremantle [mailto:paul@wso2.com]
> > > > Sent: Wednesday, May 03, 2006 11:15 PM
> > > > To: Durand, Jacques R.
> > > > Cc: wsrx
> > > > Subject: Re: [ws-rx] Minimalist GetMessage proposal:
the anon use case
> > > >
> > > > Jacques
> > > >
> > > > You are quite right. This is an interesting situation.
One of the
> > > > problems is that we do not in this spec define how
messages are
> > > > allocated to sequences. The IBM proposal simply shifts
this problem to
> > > > the EPRId as you point out.
> > > >
> > > > In one of my own early drafts of the proposal I had
these words in
> > > > section 4.2, but I removed them for simplicity. However,
if they are
> > > > useful they could be added back.
> > > >
> > > > "The WSRM specification does not define the allocation
of messages
> > to a
> > > > sequence. In the case of reliable request-response
with an anonymous
> > > > client, the server MAY make a correlation between an
incoming sequence
> > > > and an offered sequence. In the case where the request
message is
> > > > unreliable, and the client is anonymous, there might
not be a clear
> > > > basis to allocate messages to a given sequence. In
this scenario the
> > > > client MAY add the <wsrm:Identifier> of the offered
sequence as a SOAP
> > > > Header element or elsewhere in the message as a hint
to the server."
> > > >
> > > > Paul
> > > >
> > > > Durand, Jacques R. wrote:
> > > > > Paul:
> > > > >
> > > > > Are you sure this works when two different (un-addressable)
clients
> > > > are
> > > > > sending an anonymous wsrm:Offer/wsrm:Endpoint
to the same RMS-to-be
> > > > > endpoint, say for offering sequences S1 and S2?
> > > > > The offered sequences S1 and S2 have to be clearly
associated
> > from the
> > > > > start with the right client-RMD, by the server-RMS.
> > > > > With an in/out pattern where the in message is
not sent
> > reliably, how
> > > > > would the server-RMS know if it should use S1
or S2 when sending the
> > > > out
> > > > > message for an in message of one of the
two initiators?
> > > > > Don't we still face the same issue of distinguishing
anonymous
> > > > endpoints
> > > > > that IBM proposal tries to address ( with wsrm:EPRid)
?
> > > > > (Do I miss something?)
> > > > >
> > > > > Jacques
> > > > >
> > > > > -----Original Message-----
> > > > > From: Paul Fremantle [mailto:paul@wso2.com]
> > > > > Sent: Wednesday, May 03, 2006 12:05 PM
> > > > > To: wsrx
> > > > > Subject: [ws-rx] Minimalist GetMessage proposal
> > > > >
> > > > > Based on some of the discussions it seemed to
me that it could be
> > > > > valuable to produce a completely "minimalist"
GetMessage proposal.
> > > > >
> > > > > This is a new proposal that is based on the previous
WSO2 proposal.
> > > > >
> > > > > The proposal removes the MessageID selector in
the GetMessage -
> > > > relying
> > > > > on simply getting whatever message the server
sends back next.
> > > > >
> > > > > Also it removes the section 4.2. Effectively section
4.2 is an
> > > > > optimisation: for example to support unreliable-in/reliable-out
a
> > > > client
> > > > >
> > > > > could do a createsequence+offer and never use
the outgoing sequence.
> > > > In
> > > > > this case there is an overhead, which 4.2 aimed
to remove, but this
> > > > > simplifies the proposal by focussing on the bare
minimum required to
> > > > > support the most common use cases, but still allowing
the other use
> > > > case
> > > > >
> > > > > with a slight overhead.
> > > > >
> > > > > I've also included a sample message flow which
I hope helps
> > understand
> > > >
> > > > > the proposal and show the general usage.
> > > > >
> > > > > Paul
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > > Paul Fremantle
> > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > >
> > > > http://feeds.feedburner.com/bloglines/pzf
> > > > paul@wso2.com
> > > >
> > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > >
> > >
> > > --
> > >
> > > Paul Fremantle
> > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > >
> > > http://feeds.feedburner.com/bloglines/pzf
> > > paul@wso2.com
> > >
> > > "Oxygenating the Web Service Platform", www.wso2.com
> > >
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]