"Alexander Kaplunov" <ak*******@nvidia.com> wrote in message news:Op*************@TK2MSFTNGP15.phx.gbl...
1. I have an application that calls a web service and passes an
object. Web Service takes that object and does some stuff with it, which
could take some time. It seems to me that in this case it would be
appropriate to use asynchronous web service. Am I correct?
That's correct. Often, invoking a web service call has some latency associated
with it, so a better question is when is it justifiable to make a synchronous (blocking)
call to a web service? [One-way messages, batch processing systems with absolutely
nothing else to do, dedicated thread devoted to one or multiple sequential calls, and
troubleshooting a client when you want to disentangle the complications of asynchrony
from the problem under investigation.]
I fully agree that if the web service is a long-running remote process, it is best called
in an asynchronous manner. Additionally, if the client is interactive and needs to have
a responsive user interface, the web service should be called asynchronously.
2. I also have another application that calls a different web
service. In this scenario the calling application may call this web service
many times in a row and I don't want to wait while it processes the data
from the previous call. On important thing is that I must get the return
value for each of those calls. Would it be appropriate to use asynchronous
web service in this case?
You can (should) make all of the web service calls asynchronously. However,
your design has to contend with the possibility that the web services may return
in a different order than you had called them.
If not, what would be a good way for me to solve the potential bottle neck?
Another option you haven't mentioned, is to dispatch several one-way web
service calls (with some token ID that identifies their "batch number") and
then fire off a web service call that retrieves all of that data (by it's "batch
number.") Not that I wouldn't make that ultimate call asynchronously, too,
but this approach may help you handle the data management aspects by
receiving the result set from one call instead of many calls coming back in
an unpredictable order.
Derek Harmon
