Re: Asynchronous calls

The fault endpoint is FaultTo: if it's there, ReplyTo: if it's not
(ReplyTo: defaults to anonymous).

If the fault endpoint is anonymous, all faults MUST come in the HTTP
response.

If the fault endpoint is non-anon, any faults produced before WSA is
engaged (mustUnderstand, bad envelope, whatever else) will come back in
the HTTP response.  All others MUST go to the fault endpoint.

Someone came up with a timeline describing this, way back in the day :-).

Rogers, Tony wrote:
> Sorry, I wasn't completely clear (inadequately pedantic!).
>  
> You will only get one response on the HTTP backchannel - it will be
> HTTP 202 or a fault. Sure, you can get a fault later, but it cannot
> appear on the backchannel. 
>  
> Tony Rogers
>
> ------------------------------------------------------------------------
> *From:* Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> *Sent:* Tue 10-Jul-07 22:01
> *To:* Rogers, Tony
> *Cc:* David Illsley; GUILLON Benoit; public-ws-addressing@w3.org;
> public-ws-addressing-request@w3.org
> *Subject:* 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
> >
> >
> >
> >
> >
> >
> >