RE: Asynchronous calls

Ah,  much better:-)

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

"Rogers, Tony" <Tony.Rogers@ca.com> wrote on 07/10/2007 08:03:37 AM:

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