2008/9/16 kpalania <[EMAIL PROTECTED]>: > Wouldn't it be better if the client had a web service available and the > callback was simply to that web service? Seems cleaner than this "sort of > fake" asynchronous approach..
This is probably more robust -- less prone to timeouts etc. -- but the downside obviously is that is puts a whole bunch more responsibility (and dependencies) on the client. This is fine if you know if advance who all the consumers of your service will be, and are in a position to dictate requirements to them, but this often isn't the case. And it won't work if the client is behind a firewall or a NAT router -- they'll be able to make http requests to your service, but not vice versa. The alternative is the submit/monitor/retrieve job model, one implementation here (discovered via the other thread someone posted): http://www.jroller.com/gmazza/entry/creating_service_side_asynchronous_web This has the robustness of not needing to maintain 'fake' asyncrony via a long background http request, but also loads very little extra responsibility, and no extra code or architectural dependencies, onto the client. Andrew.
