“Judges”?
All we need is the spec Doug. What in WS-A backs up your interpretation? I’ve
looked at the spec and don’t get that at all.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Friday, March 10, 2006 8:24
AM
To: Paul Fremantle
Cc: wsrx
Subject: Re: [ws-rx] An
alternative approach to make anon reply-to and sync rm work
I think we need a ruling from the WSA judges :-)
But to me anon replyTo means the response goes back on this http response flow.
If this response flow is closed then you're out of luck. If you
want the response to flow back on some other http response flow then you'd need
to use a new URI. Again, I don't read anon replyTo as 'any response
flow', but rather 'this response flow', or in more specish words, the http
response flow of the http request flow that had this request - not just any
request. Even if there are two relatesTo (like you suggest in your other
note) I don't think it changes the implicit correlation requirements that anon
imposes.
BTW - in general I do agree that there can be two relatesTo headers but you
need to make sure that the rules for how responses are generated and where they
go are still adhered to. As I said, if you defined a new URI it could
work. For example, if the replyTo was "anonRM" and the
semantics of that meant "same as WSA anon, when possible, but if the connection
isn't there then use the SeqID (or whatever we choose) as the correlator when a
new ackReq comes in" then it might be able to work w/o bending the WSA
rules. In this case I think the response to your ackReq/poll request
might have 2 relatesTo - 1 to indicate its a response to the ackReq and one to
indicate its a response to the original request. The first is valid per
WSA (assuming the ackReq used anon replyTo), and the 2nd is valid per anonRM
URI semantics.
thanks,
-Doug
|
Paul Fremantle <paul@wso2.com>
03/10/2006 11:01 AM
|
|
To
|
Doug Davis/Raleigh/IBM@IBMUS
|
|
cc
|
wsrx <ws-rx@lists.oasis-open.org>
|
|
Subject
|
Re: [ws-rx] An alternative approach to make
anon reply-to and sync rm work
|
|
Doug
I'm sure this one is fixable.
I'm not a WS-Addressing expert (but I know we have
some). If the
ackrequest message had the same messageId as a
previous business
message, I think that would be a problem. But that
is not what I'm
proposing. I'm proposing that the response message
has the relatesTo
pointing to the original message. It is perfectly
acceptable to have
multiple messages that relate as replies to a
single message.
Paul
Doug Davis wrote:
>
> That's a whole lot of "ifs" and
other conditional terms :-)
> Still pondering your note (lots of "this
case but not this case"
> things to keep straight) but something else
to worry about.... I'm not
> sure you can respond based on just an ackReq
coming in. The response
> will need to have a wsa:RelatesTo (when wsa
is turned on) that points
> to the messageID of the request. In order to
comply with WSA the
> ackReq's messageID would have to be the same
as the original request
> message - but then you run into the
uniqueness issue around
> messageID's. I know at one point WSA
may some allowances for
> resending of messages and reusing messageIDs
are ok then, but this
> isn't a retransmission, its really a new
message so I'm not sure it
> would fall into that category.
> -Doug
>
>
>
> *Paul Fremantle <paul@wso2.com>*
>
> 03/10/2006 03:21 AM
>
>
> To
>
Doug Davis/Raleigh/IBM@IBMUS
> cc
>
wsrx <ws-rx@lists.oasis-open.org>
> Subject
>
Re: [ws-rx] An alternative approach to make anon reply-to
and sync rm
> work
>
>
>
>
>
>
>
>
>
> Doug
>
> I think the important point here is that the
use of this model is
> optional for an RMS.
>
> There are a number of scenarios, some of which
work and some don't. The
> question is - is the RMS (or the RMD) ever
forced to use a scenario
> which doesn't work?
>
> For an anonymous reply-to case, I think the
relevent the scenario space
> and issues are:
> A) Is the client completely synchronous? In
other words, there is no way
> of correlating a response message other than
the HTTP channel it comes
> back on?
>
> B) The opposite of A - in other words the
client can correlate based on
> WSA relatesTo.
>
> C) Is there an RMS that spans multiple clients
(for example a gateway)?
>
> In the case of A (but not C):
> the RMS cannot use the ackrequested model. It
has to rely on the
> replaying of request messages. So either the
RMS can support this model,
> or it should not start the sequence with
anonURI+Offer.
>
> In the case of B (but not C):
> the model works fine. Like any other async
client, the correlation of
> request messages takes place based on
something in the message, and
> nothing new happens here.
>
> In the case of C and A:
> The only way to make this work is if the
gateway "knows" the MEP. In
> this case the RMS can use the request replay
model. In other cases the
> RMS should not start the sequence with
anonURI+Offer.
>
> In the case of B and A:
> In general this is not possible and the RMS
should not start the
> sequence with anonURI+Offer. On the other
hand a smart RMS or gateway
> could correlate the relatesTo and therefore
route the requests to the
> relevant client.
>
> However, I think C as a whole is an unlikely
scenario. A sufficiently
> complex installation to support a shared RMS
or a gateway would also
> have the necessary support to expose ports on
firewalls, etc, and should
> have no need to initiate anonymousURI+Offer
type sequences.
>
> Paul
>
>
>
> Doug Davis wrote:
> >
> > Paul,
> >
> > I think there are some problems with
this - I still think this
> > violates WSA. There's a reason
anon replyTo means, in essence, the
> > http response flow of the request
message. The connection becomes the
> > correlator between the request and the
response - meaning if several
> > anon requests come in the only way the
server knows which client gets
> > which response is thru the http
connection. In your scenario if there
> > are two anon requests sent to the server
using the same sequence and
> > no responses sent, when the third
connection is made (to carry the
> > ackReq) how does the server know which
client is initiating the
> > request. It can not simply assume
that just because they shared the
> > same sequence that they also share WSA
state and that any response can
> > be sent to any client. The
correlation is now lost.
> >
> > thanks,
> > -Doug
> >
> > The biggest issue with the two way
reliable HTTP + anonURI case is the
> > requirement to replay request messages
to get responses.
> >
> > Why is this a problem? Because it means
that the client has to store
> > requests (if and only if the interaction
is two-way) beyond getting an
> > ack
> > for that request.
> >
> > This means that the RMS has to
"know" if this particular message
> > interaction is one-way or two way. This
means that for example, a dumb
> > gateway can't do it without looking at
WSDLs etc.
> >
> > Why do we need to do this: because WSA
states:
> >
> > "For instance, the SOAP 1.2
> > HTTP binding puts the reply message in
the HTTP response."
> >
> > So I agree we should not put an
application reply to message A in an
> > HTTP response to application message B.
> >
> > However, if we added the following text
to our spec:
> >
> > "In the case where an offered
sequence is used, the RMS may send an
> > <wsrm:AckRequested> header
together with an empty SOAP body. A valid
> > response to this message MAY either
contain an empty SOAP body, or MAY
> > contain a message for the *offered*
sequence".
> >
> > The result of this would be that the
response message on the HTTP reply
> > would be a valid reply to the request
message and therefore would not
> > break the
> > WS-Addressing text above. Effectively
WSRM would be defining what
> > the SOAP request/reply would be, and
therefore "making it right"
> > with respect to the HTTP binding.
> >
> > So, when things are going well the HTTP
reply to any given request
> > message would be the
> > correct response message. But in the
case that this message got lost or
> > delayed, the RMS would have a choice. If
it still had the message,
> and it
> > "knew" that the MEP was
two-way, it could choose to resend the
> > original request OR it could send an
empty body with an ackRequested
> > header.
> >
> > This also gives the offered sequence a
message onto which to
> > piggyback Close and TerminateSequence
requests, solving another problem.
> >
> > More importantly it removes the need for
> > the RMS to "know" the MEP,
because by the repeated application of
> > empty-body ackRequests,
> > the RMS can get the offered sequence
into a decent state.
> >
> > The only compulsory implementation
change I see is that the RMD would
> > have to be coded to know what this empty
body + ackrequest means.
> >
> > From the RMS I see this as optional. It
is completely up to the RMS
> > whether it initiates a CS with
Offer+AnonURI. So if an implementation
> > doesn't support this,
> > it will never initiate such a channel.
And if the RMS does initiate such
> > a channel, it will "know" it
is in this mode, that it needs to send
> > occasional empty ackrequests until it
can close down the offered
> sequence.
> >
> > In addition we would have to remove the
words that say Offer is simply
> > an optimization,
> > because this usage makes a specific
correlation between a sequence and
> > offered sequence.
> >
> > 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
>
>
--
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