From: Paul
Fremantle [mailto:paul@wso2.com]
Sent: Sunday, March
12, 2006 1:43
AM
To: Bob Freund-Hitachi
Cc: Doug Davis; wsrx
Subject: [ws-rx]
AnonURI and Offer
and WS-Addressing
Bob et al.
I've attached a document that outlines the flow and shows message
exchanges for
a given interaction. The key question is whether the interaction:
RMD.AckRequested_EmptyBody ->
EchoResponse_World_ackSeq_1_2_3
breaks the WS-Addressing spec.
Paul
Bob Freund-Hitachi wrote:
Just
another log for the fire…
In reading
HTTP 1.1, I do not see anything
that specifies that the response entity cannot be interpreted prior to
its
completion. In principle, it seems to me that both ack and response
could
be sent on the same connection backchannel provided that it was not
closed
prematurely. Is this how the implementations that work do it?
Thanks
-bob
From: Doug
Davis [mailto:dug@us.ibm.com]
Sent: Friday, March
10, 2006 1:36
AM
To: Paul Fremantle
Cc: wsrx
Subject: Re: [ws-rx]
An
alternative approach to make anon reply-to and sync rm work
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