Re: [ws-rx] An alternative approach to make anon reply-to and sync rm work

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

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