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: Thu, 4 May 2006 23:07:03 -0400
"Durand, Jacques R." <JDurand@us.fujitsu.com>
wrote on 05/04/2006 10:44:03 PM:
> I believe the challenge of the multiple RMD-clients is more for the
> RMS-server about associating the [offered] sequenceIDs with their
> respective RMDs. Once this done, Paul has no more problems with
> subsequent instances of the in/out pattern: correlation between
in
> / out is supported by WS stack as done for non-reliable exchanges.
Well, yes and no. I agree that the challenge
is to figure out which
client initiated the GetMessage - which is the same
thing as associating
the passed-in SeqID with the desired RMD/client. However,
doing that
is non-trivial. You seem to be suggesting that WSA
can provide some
help here and it doesn't. The wsa:RelatesTo
can be used to correlate
a response to a request, yes, but it can not be used
to correlate
the response to an endpoint. By that I mean,
if you send a response
to the wrong endpoint (wrong client) you can not assume
that the client
will be able to pass that response over to the right
client by simply
looking at the wsa:RelatesTo. At best all it
can do is know whether or
not the message was really something it should have
received. If not
there's nothing it can do - there's no assumption
that all clients/RMDs
share WSA state info and can move messages between
each other.
> Now he still has a problem with the Notify kind
of exchange (out
> only) as you said before: that’s a use case discussion (how much
do
> we want to support that case?).
Yup.
> Back to the the wsrm:Offer/wsrm:Endpoint, regardless
whether we use
> it or not, it appears that the wording in the spec excludes the use
> of this offered sequence for multiple endpoints – at least excludes
> multiple RMD endpoints for that seq. In that case we can still stickto
[1 seq
> à 1 RMD] and the RMD can safely pull based on sequence Id.
Really? The text in the spec says:
This REQUIRED element, of type wsa:EndpointReferenceType
as specified
by WS-Addressing [WSAddressing] specifies the endpoint
reference to
which WS-RM protocol messages related to the offered
Sequence
are to be sent.
How does this restrict us to one endpoint? This
EPR is there so the
server know where to send things like Close/Terminate
- not RM-enabled
app messages. This EPR is, sort of, the equivalent
of the wsa:To on a
CreateSequence, but since in the Offer case there
is no CS we needed
to tell it what the EPR is. We could have just
as easily told the
RMD to use the wsa:ReplyTo from the Offer message
but because its
possible people may want their RM protocol messages
to go to somewhere
else we chose to allow that flexibility by providing
yet another EPR.
(At least that's what I remember about this EPR :-)
> Now, what should go in this wsrm:Endpoint element
could be the
> response to the identification of the RMD-client – couldn’t this
be
> the same as the EPR you recommend to use with the */polling
URI in
> your proposal?
Not sure I follow but I think its because we're disagreeing
on what
this EPR is there for.
-Doug
> Jacques
>
>
> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Thursday, May 04, 2006 7:13 PM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Minimalist GetMessage proposal: the anon use
case
>
>
> 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]