DCS Physical Architecture

The DCS runtime executes as a collection of .NET Framework Web services hosted by Internet Information Services (IIS). The services implementing the DCS runtime can be hosted by using IIS version 6.0 on Windows Server 2003 R2, Service Pack 2 and IIS version 7.0 on Windows Server 2008. DCS also requires the .NET Framework version 3.0 (or a later version), the Windows Communication Foundation and Windows Workflow Foundation runtime components, and SQL Server 2005 or SQL Server 2008.

When a user-defined service (one that is not a core Web service from the DCS runtime) executes in the DCS environment, it runs in an IIS worker process that acts as a Windows Workflow Foundation (WF) host application. When a client application invokes an operation, a task factory (part of the DCS runtime) instantiates the appropriate implementation, and creates the WF workflow host to run the task.

The services included in the DCS runtime are as follows:

  • Discovery Service. This acts as a service directory and provides location independence for DCS services. The Discovery Service provides functionality for retrieving the physical URLs for services that match a specified contract and scope. It implements the WS-Discovery specification.
  • Management Services. This manages the DCS infrastructure. It is a set of Web services that provide functionality for creating and managing services, operations, tasks, and policies, and for configuring DCS itself. The DCS Management Services console uses these services.
  • Application Management Service. This provides the workflow management for DCS services. DCS uses this service to dehydrate and rehydrate services, to detect and manage errors in the workflow runtime, and to stop a workflow if necessary.
  • Token Issuer Service. This acts as a security token service and provides authentication and authorization services for DCS.

The DCS services can be deployed to the same instance of IIS, or they can be hosted by different instances running on different computers. For more information, see the DCS Deployment Guide.

The services in the DCS runtime maintain information in the following collection of SQL Server databases. You use SQL Server 2005 or SQL Server 2008 to manage these databases.

  • Discovery database – This holds information about the endpoint and metadata (MEX) address for each service, and the scopes that each instance can respond to. For more information about scopes, see DCS Scopes – The Discovery Service uses this database.
  • ServiceConfiguration databaseThis holds information about individual services, operations, and policies. The Management Services use this database.
  • DCSManagementDB databaseThis holds configuration information about the services. This includes the tasks, pipelines, filters, transparent processes that the services implement. The Management Services use this database.
  • BusinessLog database – This records the messages and actions sent to and received from services when the Business Log policy is enabled. For more information about the Business Log policy, see CCF 2009 SP1 Deployment Guide.
  • WorkflowPersistenceStore database – This holds information about the workflows that implement the tasks being run for each service, and the state of those workflows. The DCS runtime can dehydrate long-running, inactive tasks implemented as workflows, and save them in the WorkflowPersistenceStore database. It can rehydrate them and resume them when they become active again. The Application Management service uses this database.

Client applications use a proxy class to connect to a DCS service. This class is an extended WCF proxy that transparently communicates with the Discovery Service to establish a connection with a service. The client proxy uses a customized version of the WCF channel factory that was extended to include the functionality that DCS requires.

The proxy also interacts with other client-side components to configure the client channel to match the policy requirements for communicating with the service, and to transparently fallback to another instance of the service (if available) if a communication fails. A developer can build customized versions of these components. For more information, see Extending DCS Functionality.

Dd632066.note(en-us,MSDN.10).gifNote:
By default, the client channel is discovery-aware. However, you can change this behavior in the client application configuration file if you have to direct the client proxy to a specific service endpoint.

If the administrator configures the caching policy for a service, the client proxy can transparently store response messages in a local SQL Server Compact Edition database. Later requests to the same service for the same information can satisfied without requiring the client proxy to transmit a message to the service or wait for a response.

The DCS Software Factory provides the ProxyBuilder utility to generate the code for this customized proxy class. This utility works with the WCF SvcUtil tool. It uses the WS-MetadataExchange protocol to download the WSDL definition for a service and generate the code for a basic WCF proxy class. The DCS Business Logic Visual Studio Extensions include a recipe that automates these two tasks. For more information, see The DCS ProxyBuilder Utility.

The DCS Management Services console is a Microsoft Management Console (MMC) snap-in that enables an administrator to configure DCS services, tasks, operations, and policies. It is a DCS client application that communicates with the Management Services to query and maintain configuration information. For more information about how to use the DCS Management Services console, see CCF 2009 SP1 Deployment Guide .

Show: