RE: Asynchronous calls

Dear all,

 

Thanks again for your replies. They will help me to make my decision. 

 

Best regards

 

Benoit

 

________________________________

De : David Hull [mailto:dmh@tibco.com] 
Envoyé : mardi 10 juillet 2007 16:11
À : Rogers, Tony
Cc : Christopher B Ferris; David Illsley; GUILLON Benoit; public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
Objet : 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> <mailto:guillon@sungard-finance.fr> 
> To:
> <public-ws-addressing@w3.org> <mailto: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
> 

> 

 




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.