Originally posted by jack nick:
...so we are not sending any response back (at all). But would like the client to be sent an acknowledgment to the effect that their SOAP message was received at our end. (Would I be calling this async???)
As Bill has already pointed out it seems a bit peculiar that you don't simply accept the request and
immediately return a reply to the client acknowledging receipt of the "document". I hope that the lack of response isn't due to the fact that the web service is running the ~45 min process itself without completing the request because that would be an anti-pattern in itself.
Basically
you should be implementing a
Producer/Consumer (
Blocking Queue shows a simple Java version). The service instance created by the arrival of the SOAP request should act as a "Producer" and simply place all the request information on the "Queue" and then simply complete the request by responding with an "accepted" response document. It is the (separate) "consumer" that then takes the information off the queue to initiate or run the actual "process".
So maybe this wasn't a problem related to HTTP response codes at all?
If you need to send a response after the process has completed then WS-Addressing is certainly one option - however this is basically server to server communication as the service provider has to expose a public HTTP endpoint for the service consumer to send the initial request to
AND the service consumer has to expose a public HTTP endpoint so that the service provider can return the asynchronous result back to the service consumer. Inside the same firewall this isn't a big issue - however when both systems have to hide behind their respective firewalls the networking department of the service consumer may not be all that thrilled if they have to move a separate public HTTP endpoint into their DMZ - effectively increasing the organizations attack surface. This then leads to situations where some organizations will expose one single endpoint URI for all possible service consumers behind the firewall - additional information in the addressing headers will be required in order to route the result to the correct recipient.
One option is to send a completion response through a separate communication channel.
8.4.3 Refactoring Synchronous to Asynchronous interactions shows the use of JMS. You can just as easily use SMTP (email) - as long as you realize that email is neither reliable nor secure (by itself). In that case you can give your client in your "SubmitEndOfDay" request document the option of specifying an email address for the completion response. Furthermore that completion response could be human readable (e.g. plain text) or machine readable (e.g. XML, XML-in-SOAP, etc.), again selectable in the "SubmitEndOfDay" request document.
A more conventional approach is to fake asynchronous communication through synchronous calls from the client with "Pattern 3: Request/reply operations with polling" as described in
Asynchronous operations and Web services, Part 2. This approach requires that you include a
correlation identifier in your response to their initial "SubmitEndOfDay" request document. The client can then include the correlation identifier in a "EndOfDayResultQuery" request document - for a valid correlation identifier your response document will simply indicate that the results are not available yet or it will return the results of the completed process. You will just have to get to some kind of agreement with your clients that they won't be banging away at your endpoint with "EndOfDayResultQuery" documents at every second.