2008/9/17 kpalania <[EMAIL PROTECTED]>: > What would be clean and distributed in my mind is if the callback actually > happens to be another web service call. That way, the client registers a web > service call as the callback and when the response is ready, the server side > implementation simply calls the callback web service and passes the > response. Ofcourse, this would mean that the client has a web service > implementation as well but that seems simpler and well-detached compared to > this AsyncHandler approach. Right?
Well, 'simpler' is pretty subjective. I personally wouldn't design any of my web services so that only another server could access them -- which is what your solution implies. But then I'm building services for public consumption, and the client might be a few lines of Perl or Python, or a desktop workflow management app like Taverna, for example. If they can only get the results out of my service by running another service themselves, well that's most of my users gone. But if your usage scenario means that you know exactly who the client is, and you're using web services primarily for peer-to-peer communication between server machines anyway, then maybe it is no less hassle to have a web service on each end. Andrew.
