RE: Asynchronous calls

Tony,

I'm fairly certain that the statement you are making is somewhat 
inaccurate. You MAY get both, the fault 
might be transmitted separately much later, when the message is actually 
processed.
Possibly, you are referring to the initial response carried on the HTTP 
response
message which MAY be either a 200, 202 OR a 3xx 4xx or 5xx response per 
the SOAP 1.2
HTTP binding [1]. Note that the SOAP 1.2 HTTP binding does permit that a 
SOAP
envelope be present on a 202 response message.

An HTTP 202 means that the message was accepted for processing... nothing 
more. It is 
intentionally non-committal.

Quoting RFC2616 [2]
10.2.3 202 Accepted

   The request has been accepted for processing, but the processing has
   not been completed.  The request might or might not eventually be
   acted upon, as it might be disallowed when processing actually takes
   place. There is no facility for re-sending a status code from an
   asynchronous operation such as this.

   The 202 response is intentionally non-committal. Its purpose is to
   allow a server to accept a request for some other process (perhaps a
   batch-oriented process that is only run once per day) without
   requiring that the user agent's connection to the server persist
   until the process is completed. The entity returned with this
   response SHOULD include an indication of the request's current status
   and either a pointer to a status monitor or some estimate of when the
   user can expect the request to be fulfilled.

One cannot assume that ANY of the headers have been processed at the point 
at which a 202 has been received. However,
since the SOAP HTTP binding does permit that a SOAP envelope be returned 
with the 202 response message. Such a message
**could** provide a status indicator as to disposition of the message 
(e,g. successfully dispatched for processing).

I think that what David was suggesting is that infrastructure code today 
generally does not do something like this, and mucking
around with the infrastructure code is not advisable. I would tend to 
agree. However, if you wanted to do something such as initially
suggested, you can design a process that spans multiple WSDL operations in 
which a "request" message is comprised of a req/resp
MEP at the SOAP/WSDL level with the response being a status inidicator, 
and with the application processing effectively
doing the dispatching for subsequent processing. In such a case, the 
response is more likely to be either a 200 or a 3, 4 or 5XX
not a 202, because from the perspective of the HTTP application-layer, the 
request HAS been processed (the processing
is the act of dispatching for subsequent processing).

WS-RM is an example of an interchange that will (whcen configured to 
provide an Ack to the anon endpoint) in which there
is an intermediate response of sorts. This is typically an 
infrastructure-level response that also makes no claims as to 
whether or not the message can or even will be successfully processed 
(e.g. a subsequent fault MAY be generated).

However, to the original question, as to whether it would be compliant 
with WS-A to have such an intermediate
response, it would largely depend upon the design of the application. As 
mentioned, if you have such a long-running
operation and you want to provide the requestor with some sort of 
intermediate status, then design the interfaces
accordingly (e.g. don't try to map such a thing to a single req/resp 
operation in WSDL, but rather as described above).

[1] http://www.w3.org/TR/2007/REC-soap12-part2-20070427/#http-bindrespnode
[2] http://ietf.org/rfc/rfc2616

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986

public-ws-addressing-request@w3.org wrote on 07/09/2007 06:19:17 PM:

> To be a little pedantic, what you will get is an HTTP 202   *OR*   a
> fault - you will never get both; you should get exactly one. The 202
> is the response saying "got the message, working on it, I didn't see
> anything obviously wrong with it before I sent this 202 response" - 
> at that point you know it has read and interpreted some of the 
> headers at least.
> 
> Tony Rogers
> CA, Inc
> Senior Architect, Development
> tony.rogers@ca.com
> 
> From: public-ws-addressing-request@w3.org on behalf of David Illsley
> Sent: Tue 10-Jul-07 5:57
> To: GUILLON Benoit
> Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> Subject: Re: Asynchronous calls

> 
> Hi,
> What you will get when using the WS-A implementations I'm aware of is an
> HTTP 202 indicating that the message was successfully received, and if
> there is a fault, the fault will be sent to the ReplyTo/FaultTo per WS-A
> Core. Anything over and above that in the direction you suggest isn't in
> any specification I'm aware of so you'd have to define that yourself and
> make your infrastructure support it (which isn't something I'd advise).
> David
> 
> David Illsley
> Web Services Development
> MP211, IBM Hursley Park, SO21 2JN
> +44 (0)1962 815049 (Int. 245049)
> david.illsley@uk.ibm.com
> 
> 
> 
> From:
> "GUILLON Benoit" <guillon@sungard-finance.fr>
> To:
> <public-ws-addressing@w3.org>
> Date:
> 07/09/2007 01:58 PM
> Subject:
> Asynchronous calls
> 
> 
> 
> Hello,
> 
> I?m working on publishing long operations via WebServices: client sends 
a
> message via HTTP to my service which starts the long operation. Client
> gets the result later in a JMS queue or its own endpoint gets called 
with
> the response. To achieve this, I plan to use WS-Addressing for message
> correlation and reply-to endpoint definition.
> 
> However, I want my service to return a first reply saying ?Ok I managed 
to
> start the long operation (or not and why)? in the HTTP response of
> client?s call whatever the ?reply-to? field was.
> 
> I was wondering if this use-case was still compliant with WS-Addressing 
or
> if it was a bad use of ?reply-to?.
> 
> Best regards
> 
> Benoît Guillon * NTIC * SunGard * Asset Arena Investment Accounting * 7
> rue Royale, 173 Bureaux de la Colline, Bâtiment E, 92213 Saint-Cloud
> Cedex, France * Tel +33 1 49 11 31 87 * Fax +33 1 49 11 30 30 *
> 
> 
> CONFIDENTIALITY: This email (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited. If you received this email in error,
> please notify the sender and delete this email from your system. Thank 
you
> 
> 
> 
> CONFIDENTIALITÉ: Ce courrier électronique (pièces jointes incluses) peut
> contenir des informations confidentielles, propriétaires et 
privilégiées,
> dont la divulgation ou l'utilisation non-autorisée est interdite. Si 
vous
> avez reçu ce courrier électronique par erreur, nous vous remercions de
> bien vouloir avertir l'expéditeur et détruire ce courrier électronique 
de
> votre système. Merci.
> 
> 
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> 
> 
> 
> 
> 
>