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: Christopher B Ferris <chrisfer@us.ibm.com>
- To: Doug Bunting <Doug.Bunting@Sun.COM>
- Date: Thu, 11 May 2006 09:44:29 -0400
If there was a TC chartered to solve
the problem of allowing a man to lift a rock that weighed
more than he, and a member of the TC
proposed a new device (s)he called the "lever", that coincidently
could also be used as an entertainment
device for small children, should the proposed solution
be ruled out?
I would think/hope not.
That said, I did not read anything in
the thread below that even remotely suggested a charter change until
DougB's note. Did I miss something?
Cheers,
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
Doug.Bunting@Sun.COM wrote on 05/10/2006 10:01:16
PM:
> Are you proposing a Charter change?
>
> On 10/05/06 18:48, Patil, Sanjay wrote:
> > If a proposal happens to address other use cases (with no added
> > complexity) beyond the current scope of an issue, that may actually
be
> > a better proposal, IMO. For example, it will help implementers
in
> > reusing the same underlying technology stack and design/communication
> > patterns in building different solutions. At least that's what
I
> > sense as the general preference of the product teams in my company!
> >
> > Can we please focus on the technical aspects of how Dug's (or
other)
> > proposal addresses the stated problem. I don't think that
> > applicability to problems that are not stated in our scope is
a
> > sufficient argument to shoot down any proposal.
> >
> > -- Sanjay
> >
> > ------------------------------------------------------------------------
> > *From:* Doug Davis [mailto:dug@us.ibm.com]
> > *Sent:* Wednesday, May 10, 2006 14: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
> > <http://www.google.com/search?hl=en&lr=&q=%
> 22cutting+your+nose+off+despite+your+face%22>.
> >
> > -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]