RE: HTTP based async request-response

So, if I understand your proposal well, in a WSDL request/response the
"out" message could be bound to a SOAP 1.2 Response MEP. But what would
the "in" message be bound to?

Ugo

> -----Original Message-----
> From: public-ws-async-tf-request@w3.org 
> [mailto:public-ws-async-tf-request@w3.org] On Behalf Of Marc Hadley
> Sent: Wednesday, February 02, 2005 1:46 PM
> To: public-ws-async-tf@w3.org
> Subject: HTTP based async request-response
> 
> 
> 
> I took an action to outline one approach to async request-response 
> using HTTP. Basically the request is sent as normal as the 
> entity body 
> of a HTTP POST request but instead of returning the response in the 
> HTTP entity body, the server responds with a 303 (See other) status 
> code and includes a Location header that gives a URI from which the 
> response can be retrieved. The client then uses a new HTTP 
> GET request 
> to retrieve the response. E.g.
> 
> Initial request:
> 
> POST /StockQuote HTTP/1.1
> Host: stockquote.example.com
> Content-Type: application/soap+xml
> Content-Length: nnnn
> 
> <env:Envelope xmlns:env="...">
>     ...
> </env:Envelope>
> 
> Response:
> 
> HTTP/1.1 303 See Other
> Location: http://stockquote.example.com/someuniqueidentifier
> Retry-After: 120
> Content-Type: text/html
> Content-Length: 0
> 
> Susequent request to retrieve response:
> 
> GET /someuniqueidentifier HTTP/1.1
> Host: stockquote.example.com
> 
> Response:
> 
> HTTP/1.1 200 OK
> Content-Type: application/soap+xml
> Content-Length: nnnn
> 
> <env:Envelope xmlns:env="...">
>     ...
> </env:Envelope>
> 
> If the response isn't yet ready the server can send back another 303 
> indicating when the request may be retried using the Retry-After 
> header.
> 
> I quite like this approach since it pushes the asynchrony 
> down into the 
> HTTP layer and doesn't require anything new in WSDL or SOAP. The 
> existing SOAP 1.2 HTTP binding supports this usage.
> 
> Marc.
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
> 
> 
>

Received on Wednesday, 2 February 2005 22:44:59 UTC