Re: [ws-rx] AnonURI and Offer and WS-Addressing

[Doug Davis <dug@us.ibm.com>]

Paul,
  please see:  http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-soap.html?content-type=text/html;%20charset=utf-8#anonaddress
which is the latest editor's copy of
WSA, and in particular:
When "http://www.w3.org/2005/08/addressing/anonymous"
is specified for the response endpoint and the message is the http://www.w3.org/2003/05/soap/mep/InboundMessage
property of a SOAP request-response MEP [SOAP
1.2 Part 2: Adjuncts], then any response
MUST be the http://www.w3.org/2003/05/soap/mep/OutboundMessage property
of the same instance of the SOAP request-response MEP [SOAP
1.2 Part 2: Adjuncts].

They've added quite a bit of clarifying
text since the submitted version.  I think the "same instance"
part makes it clear that the response MUST flow over the same http connection
as the request. 

Perhaps it would help if we summarized
the list of options:

1 - prohibit anon replyTo if the response
is expected to be sent using RM
2 - prohibit the use of RM when the
wsa:To is anonymous - or said another way, when replyTo is anon the response
is not sent using RM
3 - resend request until response is
delivered/acked even if the request is acked
4 - don't ack a request until the response
is sent
5 - define a new URI that allows a polling
flow like Paul described in his previous note

Here are some comments on each:
1 and 2 might actually be the same thing
but my intention was to say that in '1' you can't use anon replyTo if the
response is sent reliably - so perhaps a Fault is generated.  In '2',
if the replyTo is anon then no matter what the wsdl/policy... says, RM
needs to be turned off for the response - it can still be sent but just
not as part of an RM sequence.  Slightly different.
'3' is a change to what I believe is
most people current view of the RM processing model because we'll resend
ACKed messages.  It also will only work for one-req/one-res MEPs.
 Out-only, or single-req/multiple-res may have issues. 
'4' is a change to the RM processing
model because the RMD will not ACK a message even if it is received.  Depending
on how you view things this could mean that the RMD needs to lie about
what it has and could cause messages to be resent because the RMD is waiting
for a response before it will ACK the request.  Now, since the RMD
gets to choose when it ACKs (meaning is it simply 'I got it' or something
else it up to it), so to some this may not be lying but just a change to
the ACK model of that RMD.
'5' doesn't require a change to the
RM processing model but heads in the direction of ws-polling and can work
w/o a change to the RM processing model and can work for all MEPs.  Even
if we did pick this option we'd still need to say something in the RM spec
about what should happen when anon replyTo is used (I'm guessing 1 or 2).

Are there any other options people think
we need to add to the list?  Having all of the known choices in front
of us might help focus the discussions.

thanks,
-Doug

Paul Fremantle <paul@wso2.com>

03/12/2006 04:43 AM

To	Bob Freund-Hitachi <bob.freund@hitachisoftware.com>
cc	Doug Davis/Raleigh/IBM@IBMUS, wsrx <ws-rx@lists.oasis-open.org>
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

Paul Fremantle <paul@wso2.com>

03/09/2006 06:53 PM

To	wsrx <ws-rx@lists.oasis-open.org>
cc
Subject	[ws-rx] An alternative approach to make anon reply-to and sync rm work

 

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[attachment "AnonURI+Offer.doc" deleted by Doug Davis/Raleigh/IBM]