RE: [ws-rx] An alternative approach to make anon reply-to and sync rmwork

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:] 

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
  <> 

  
03/09/2006 06:53 PM 

  
  
  
   

    
    
To

    
    
    
wsrx <>
    

    
   

   

    
    
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



"Oxygenating the Web Service Platform",
www.wso2.com