How DCS Supports Scalability
The DCS model is intended to support potentially large volumes of concurrent requests. This involves running multiple instances of workflows and returning results in a timely manner. Additionally, DCS supports conversational workflows that retain state information between invocations. The conversational model lets multiple clients start tasks in the same workflow instance, which enables them to share data. Conversational workflows can consume significant resources. If a workflow instance becomes inactive, the WF runtime can temporarily dehydrate the workflow instance together with its state information, and remove it from memory. When the workflow resumes, the WF runtime can rehydrate the workflow instance, load it back into memory, restore its state information, and continue its execution.
The DCS architecture supports horizontal and vertical scalability. Horizontal scalability is supported by a fully distributed architecture that lets a solution use Microsoft network load balancing (NLB) services to balance requests across multiple servers in a Web farm. Under certain circumstances, if a conversational workflow that is being executed by a DCS service instance displays no affinity for a particular host server, the client might send a follow-up request message as part of the same conversation through NLB to a different physical host server. In this situation, the DCS runtime can persist the conversational workflow running on the original host server to the WorkflowPersistenceStore database and rehydrate it on the host server responding to the follow-up request, as shown in the following image.
Rehydrating a DCS service in an NLB environment
Depending on the work being performed by an operation and the nature of the data that it is accessing, an instance of a DCS service might be required to have an affinity with the host server that was active when the conversational workflow was initiated. In this situation, the workflow cannot be dehydrated and rehydrated on a different host server. However, the DCS runtime can detect the affinity requirement and create a proxy object to forward the follow-up request to the correct host server. The proxy object receives the response, and can forward it to the client application, as shown in the following image. This process is transparent to the client application and the conversational workflow.
Forwarding a request and response in an NLB environment
For more information about how to configure DCS in a Web farm environment, see the DCS Deployment Guide.
Vertical scalability is supported by the underlying implementation of DCS. DCS can use 64-bit servers that have multiple and multi-core CPUs. Additionally, the underlying infrastructure uses SQL Server to provide persistence for dehydrated workflows and configuration information for DCS. SQL Server is a highly scalable database management system.