[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
Dug,
On 08/05/06 05:19, Doug Davis wrote:
> DougB,
> Who said reliable notif w/o reliable subscription?
You did, when you pointed to "problems" with reliable notifications
which relate only to the case in which the destination system did not
offer a sequence. That destination system would be unknown only in the
case where it had not subscribed.
> 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
Most of those questions, especially about when the client (destination)
knows to offer a sequence apply equally to your proposal. When does the
destination know to poll?
> 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.
Without section 4.2 of Paul's proposal, I don't think that's the case.
Nor do I think the "heart of issue 89" is about a generic back-channel
for any and all messages one system may have queued for another.
thanx,
doug
> -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]