Asynchronous calls

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Asynchronous calls

Benoit Guillon

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.
Reply | Threaded
Open this post in threaded view
|

Re: Asynchronous calls

David Illsley-2

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)
[hidden email]



From:
"GUILLON Benoit" <[hidden email]>
To:
<[hidden email]>
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







Reply | Threaded
Open this post in threaded view
|

RE: Asynchronous calls

Rogers, Tony
Re: Asynchronous calls
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


From: [hidden email] on behalf of David Illsley
Sent: Tue 10-Jul-07 5:57
To: GUILLON Benoit
Cc: [hidden email]; [hidden email]
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)
[hidden email]



From:
"GUILLON Benoit" <[hidden email]>
To:
<[hidden email]>
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








Reply | Threaded
Open this post in threaded view
|

RE: Asynchronous calls

Benoit Guillon
In reply to this post by Benoit Guillon
Re: Asynchronous calls

Hi,

 

Thanks for your replies. I think I’d better be WS-A compliant if I plan to use it - or drop it if my requirements keep the same.

 

There is still a little something that makes me dither: can I call the “reply-to” endpoint several times to notify client that the long operation has started, has generated a first result set and finally has ended? Must these replies conform to the XSD schema of the response type declared in my WSDL? It seems I’m touching WS-Eventing area …

 

Benoit

 

 


De : Rogers, Tony [mailto:[hidden email]]
Envoyé : mardi 10 juillet 2007 00:19
À : David Illsley; GUILLON Benoit
Cc : [hidden email]; [hidden email]
Objet : RE: Asynchronous calls

 

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

 


From: [hidden email] on behalf of David Illsley
Sent: Tue 10-Jul-07 5:57
To: GUILLON Benoit
Cc: [hidden email]; [hidden email]
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)
[hidden email]



From:
"GUILLON Benoit" <[hidden email]>
To:
<[hidden email]>
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







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.
Reply | Threaded
Open this post in threaded view
|

RE: Asynchronous calls

Benoit Guillon
In reply to this post by Benoit Guillon
Re: Asynchronous calls

Hi,

 

Thanks for your replies. I think I’d better be WS-A compliant if I plan to use it - or drop it if my requirements keep the same.

 

There is still a little something that makes me dither: can I call the “reply-to” endpoint several times to notify client that the long operation has started, has generated a first result set and finally has ended? Must these replies conform to the XSD schema of the response type declared in my WSDL? It seems I’m touching WS-Eventing area …

 

Benoit

 


De : Rogers, Tony [mailto:[hidden email]]
Envoyé : mardi 10 juillet 2007 00:19
À : David Illsley; GUILLON Benoit
Cc : [hidden email]; [hidden email]
Objet : RE: Asynchronous calls

 

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

 


From: [hidden email] on behalf of David Illsley
Sent: Tue 10-Jul-07 5:57
To: GUILLON Benoit
Cc: [hidden email]; [hidden email]
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)
[hidden email]



From:
"GUILLON Benoit" <[hidden email]>
To:
<[hidden email]>
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.
Reply | Threaded
Open this post in threaded view
|

RE: Asynchronous calls

Rogers, Tony
Re: Asynchronous calls
You can, but don't claim to be doing the in-out MEP. Define your own MEP, and you can use whatever pattern suits you. In-multiple out is not difficult to define. You can define a different end-point and schema for each out, or use the same one - whatever you define in your MEP.
 
Tony Rogers
CA, Inc
Senior Architect, Development
co-chair UDDI TC at OASIS


From: [hidden email] on behalf of GUILLON Benoit
Sent: Tue 10-Jul-07 18:36
To: [hidden email]
Subject: RE: Asynchronous calls

Hi,

 

Thanks for your replies. I think I’d better be WS-A compliant if I plan to use it - or drop it if my requirements keep the same.

 

There is still a little something that makes me dither: can I call the “reply-to” endpoint several times to notify client that the long operation has started, has generated a first result set and finally has ended? Must these replies conform to the XSD schema of the response type declared in my WSDL? It seems I’m touching WS-Eventing area …

 

Benoit

 


De : Rogers, Tony [mailto:[hidden email]]
Envoyé : mardi 10 juillet 2007 00:19
À : David Illsley; GUILLON Benoit
Cc : [hidden email]; [hidden email]
Objet : RE: Asynchronous calls

 

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

 


From: [hidden email] on behalf of David Illsley
Sent: Tue 10-Jul-07 5:57
To: GUILLON Benoit
Cc: [hidden email]; [hidden email]
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)
[hidden email]



From:
"GUILLON Benoit" <[hidden email]>
To:
<[hidden email]>
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.
Reply | Threaded
Open this post in threaded view
|

RE: Asynchronous calls

Christopher B Ferris
In reply to this post by Rogers, Tony

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: [hidden email]
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986


[hidden email] 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
> [hidden email]
>
> From: [hidden email] on behalf of David Illsley
> Sent: Tue 10-Jul-07 5:57
> To: GUILLON Benoit
> Cc: [hidden email]; [hidden email]
> 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)
> [hidden email]
>
>
>
> From:
> "GUILLON Benoit" <[hidden email]>
> To:
> <[hidden email]>
> 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
>
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Asynchronous calls

Christopher B Ferris
In reply to this post by Benoit Guillon

Benoit,

I think you've pretty much answered your own question here. The answer is yes, but it really
means that you need to design the interface that way, using something such as eventing/notification
or possibly two (or more) oneway operations (in opposite directions) and have the whole
process mapped to BPEL.

Cheers,

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


[hidden email] wrote on 07/10/2007 04:36:33 AM:

> Hi,

>  
> Thanks for your replies. I think I’d better be WS-A compliant if I
> plan to use it - or drop it if my requirements keep the same.

>  
> There is still a little something that makes me dither: can I call
> the “reply-to” endpoint several times to notify client that the long
> operation has started, has generated a first result set and finally
> has ended? Must these replies conform to the XSD schema of the
> response type declared in my WSDL? It seems I’m touching WS-Eventing area …

>  
> Benoit
>  
>
> De : Rogers, Tony [mailto:[hidden email]]
> Envoyé : mardi 10 juillet 2007 00:19
> À : David Illsley; GUILLON Benoit
> Cc : [hidden email]; [hidden email]
> Objet : RE: Asynchronous calls

>  
> 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
> [hidden email]
>  
>
> From: [hidden email] on behalf of David Illsley
> Sent: Tue 10-Jul-07 5:57
> To: GUILLON Benoit
> Cc: [hidden email]; [hidden email]
> 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)
> [hidden email]
>
>
>
> From:
> "GUILLON Benoit" <[hidden email]>
> To:
> <[hidden email]>
> 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.
Reply | Threaded
Open this post in threaded view
|

RE: Asynchronous calls

Rogers, Tony
In reply to this post by Christopher B Ferris
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:[hidden email]]
Sent: Tue 10-Jul-07 22:01
To: Rogers, Tony
Cc: David Illsley; GUILLON Benoit; [hidden email]; [hidden email]
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: [hidden email]
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986


[hidden email] 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
> [hidden email]
>
> From: [hidden email] on behalf of David Illsley
> Sent: Tue 10-Jul-07 5:57
> To: GUILLON Benoit
> Cc: [hidden email]; [hidden email]
> 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)
> [hidden email]
>
>
>
> From:
> "GUILLON Benoit" <[hidden email]>
> To:
> <[hidden email]>
> 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
>
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Asynchronous calls

Christopher B Ferris

Ah,  much better:-)

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


"Rogers, Tony" <[hidden email]> 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:[hidden email]]
> Sent: Tue 10-Jul-07 22:01
> To: Rogers, Tony
> Cc: David Illsley; GUILLON Benoit; [hidden email];
> [hidden email]
> 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: [hidden email]
> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
> phone: +1 508 234 2986
>
> [hidden email] 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
> > [hidden email]
> >
> > From: [hidden email] on behalf of David Illsley
> > Sent: Tue 10-Jul-07 5:57
> > To: GUILLON Benoit
> > Cc: [hidden email]; [hidden email]
> > 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)
> > [hidden email]
> >
> >
> >
> > From:
> > "GUILLON Benoit" <[hidden email]>
> > To:
> > <[hidden email]>
> > 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
> >
> >
> >
> >
> >
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: Asynchronous calls

David Hull
In reply to this post by Rogers, Tony
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 [[hidden email]]
Sent: Tue 10-Jul-07 22:01
To: Rogers, Tony
Cc: David Illsley; GUILLON Benoit; [hidden email]; [hidden email]
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: [hidden email]
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986


[hidden email] 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
> [hidden email]
>
> From: [hidden email] on behalf of David Illsley
> Sent: Tue 10-Jul-07 5:57
> To: GUILLON Benoit
> Cc: [hidden email]; [hidden email]
> 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)
> [hidden email]
>
>
>
> From:
> "GUILLON Benoit" [hidden email]
> To:
> [hidden email]
> 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
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Asynchronous calls

Benoit Guillon
In reply to this post by Benoit Guillon

Dear all,

 

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

 

Best regards

 

Benoit

 


De : David Hull [mailto:[hidden email]]
Envoyé : mardi 10 juillet 2007 16:11
À : Rogers, Tony
Cc : Christopher B Ferris; David Illsley; GUILLON Benoit; [hidden email]; [hidden email]
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 [[hidden email]]
Sent: Tue 10-Jul-07 22:01
To: Rogers, Tony
Cc: David Illsley; GUILLON Benoit; [hidden email]; [hidden email]
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: [hidden email]
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986


[hidden email] 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
> [hidden email]
>
> From: [hidden email] on behalf of David Illsley
> Sent: Tue 10-Jul-07 5:57
> To: GUILLON Benoit
> Cc: [hidden email]; [hidden email]
> 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)
> [hidden email]
>
>
>
> From:
> "GUILLON Benoit" [hidden email]
> To:
> [hidden email]
> 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.