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: "Abbie Barbir" <abbieb@nortel.com>
- To: "Christopher B Ferris" <chrisfer@us.ibm.com>, "Marc Goodner" <mgoodner@microsoft.com>
- Date: Wed, 10 May 2006 20:40:09 -0400
This is really getting rediculous.
May be this work should move to a new TC "Titled"
WS-Let-get-over-it-and-try-to-move-on-for-god-sake.
Abbie
Funny, that isn't how I read Doug's
response. Maybe you shouldn't be putting words in other people's mouth's.
Christopher Ferris
STSM, Software Group
Standards Strategy
email: chrisfer@us.ibm.com
blog:
http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508
377 9295
"Marc Goodner"
<mgoodner@microsoft.com> wrote on 05/10/2006 05:18:58 PM:
> So
you are advocating using the polling mechanism you are proposing
> for
unreliable messaging as well?
>
> 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: Wednesday, May 10, 2006
2:17 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx]
Minimalist GetMessage proposal: the anon use case
>
>
> Kill a simple
idea because even though it solves our problems, and
> does so (IMO) w/o
the complexity you fear, simply because it _might_
> be used in other
situations. wow.
> -Doug
>
>
> "Marc Goodner" <mgoodner@microsoft.com>
> 05/10/2006 05:04 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
>
>
>
>
>
>
>
>
>
>
> Yes but it is not tied to RM in any way besides it’s namespace.
That
> is going to lead to it being used for non RM applications. There be
dragons.
>
> 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: Wednesday, May 10, 2006 2:05 PM
>
To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Minimalist
GetMessage proposal: the anon use case
>
>
>
Interesting... a generic polling mechanism should consider things
> like
batching. I suppose it could also do such other basic things
> like
examine the wsa:ReplyTo so the polling response could be sent
> to
someplace else. All these kinds of things could make perfect
> sense for
a general purpose polling mechanism. I wonder why our
> proposal
doesn't do stuff like that? Could it be because its not a
> general
purpose polling mechanism? Could it be that our proposal
> focuses
on just one thing, the re-establishment of a lost
> backchannel? naaa
:-)
> -Doug
>
> "Marc
Goodner" <mgoodner@microsoft.com>
>
05/10/2006 03:59 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
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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.
>
> 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: 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
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]