From: Marc Goodner
[mailto:mgoodner@microsoft.com]
Sent: Wednesday, May 10, 2006
12:59 PM
To: Doug Davis;
ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Minimalist
GetMessage proposal: the anon use case
Well Dave’s
mention below is the first I’ve seen. Why is this such a bad idea though?
Returning multiple messages to a client after it polls a mailbox location
certainly seems a reasonable design choice. Such an approach could compose well
with something like WS-Enumeration. Considerations like this need to be taken
into account in any honest examination of designing a general purpose polling
mechanism.
Of course this, and
the other two proposals (from one person), just further illustrates to me why doing
this in this TC is a bad idea. Polling is a general purpose mechanism that
should be designed completely, not partially as it is in the three current
proposals that take that approach.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Monday, May 08, 2006 1:15 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Minimalist
GetMessage proposal: the anon use case
Blimey - who suggested that! :-)
-Doug
"David Orchard"
<dorchard@bea.com>
05/08/2006
03:47 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
|
|
One thing I do not want to see is boxcarring of
multiple responses for a single "Get*" response.
Blimey and crikey, what happens if the connection fails partway
through such a boxcarred response. Argh and yuck.
Dave
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Sunday, May 07, 2006 6:39 PM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] Minimalist GetMessage proposal: the anon use
case
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
>