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