|
Request Duration
There are different scenarios where it makes sense to offload and distribute computes off of your web service. The first one that comes to most people's minds is when you have long-running tasks that peg your CPU. These kinds of applications are fairly common in the realm of intensive analytics or scientific computations. Even more common is a scenario where a short-running task consumes the CPU for a smaller period of time. For example, if your service generates dynamic content for a PDF, this might take only 15 seconds, but consume an entire CPU on a server.
While both of these scenarios are a good fit for distributed computing, the former may require a slightly different approach to session state. For example, a short-running task can be serviced with a simple request-response model and the service can be stateless. This is the simplest model for service requests and can look much like a method call to a client of your service. This approach can be highly scalable, depending on how you configure your web service and by taking advantage of its ability to reuse threads to efficiently manage concurrent connections.
Long-running tasks become more complex. You cannot assume that your client can maintain a consistent connection to your web service throughout the life of a task that takes 15 minutes, much less one hour or two days. In this case, you need to implement a solution that follows a full-duplex pattern (where your client is also a service and gets notified when the task is completed) or a polling scheme (where your client checks back later to get the results). Both of these solutions require stateful services. This full-duplex pattern becomes straightforward to implement using the Windows Communications Foundation (Indigo) included with .NET 3.0. |
