DCS Logical Architecture

DCS is a set of Web services and other components that provides infrastructure hosting services and the client applications to connect to them. The following image shows the logical architecture of DCS and highlights the key functionality that the DCS infrastructure provides. The following sections describe the elements in the diagram.

Dd632279.28163fff-c674-4bb8-a2ee-758c5b30534e(en-us,MSDN.10).png

The logical architecture of DCS

The DCS Message Bus implements the core communication and control functionality of DCS. It extends the functionality of Windows Communication Foundation (WCF) to provide facilities for authentication, authorization, caching, transportation, discovery, logging, policies, reliability, and security. The message bus combines the concepts of contracts, addresses, and bindings to define the abilities and functionality exposed by endpoints. The message bus supports the common message exchange patterns that are required by most services: request-response (synchronous and asynchronous) and one-way communications.

The message bus handles all interactions between services and client applications, regardless of whether the services are local to the client applications or distributed over a network. This enables disconnected communication between the client application and a service. The location of a service is not hard-coded into a client application, and the client application and service can both be relocated with minimal effect on the other.

The message bus is also used to transport context between components. The DCS runtime can use the context information to direct a client request to a specific implementation of an operation, based on criteria defined by an administrator. For more information, see DCS Context and Task Filters.

The message bus is built upon WS-* Web service standards, increasing extensibility and interoperability with client applications and services built by using other technologies but based on the same standards.

The message bus uses the Core DCS Services to implement its functionality. These services provide the message bus with the following capabilities:

  • Provide location independence for DCS services.
  • Manage policy for DCS services in a single location, and propagate policy to client applications dynamically.
  • Protect services and data by authenticating and authorizing users who run client applications.
  • Protect request and response messages by encrypting data and implementing a secure messaging protocol.
  • Improve performance by caching metadata, discovery information, and service response messages.
  • Perform business logging of request and response messages.
  • Log performance data.

For more information about the Core DCS Services, see DCS Physical Architecture.

A developer defines the operations for a DCS service as a collection of tasks. An operation is a logical definition of a piece of business logic, and a task is the physical implementation of that business logic. Typically, a developer uses the tools that are provided with the DCS Software Factory to implement a task as a Windows Workflow Foundation (WF) workflow. However, you can also create a task as a linear piece of application code. A task runs in a host application that provides the workflow runtime environment. This host application can execute as an IIS worker process, or in a self-hosted environment.

Dd632279.note(en-us,MSDN.10).gifNote:
The default host environment that the DCS services use is provided by the Microsoft.ConnectedIndustry.ProcessExecution.WorkflowHost.ExtendedSqlWorkflowPersistenceService class. This is a customized version of the WF System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService class. It represents a persistence service that uses a SQL Server database to store workflow state information. The extended class that is provided with DCS can also persist DCS service metadata and context information. You can replace this customized workflow host with your own implementation if your organization has different requirements.

A developer can provide multiple implementations of a single operation by creating multiple tasks for that operation. Each task can implement the business logic for the operation differently. An administrator can configure tasks for a service by using the DCS Management Services console, and specifying which task is executed based on the context and scoping information that the client application provides when it invokes an operation.

The Discovery Service enables client applications to dynamically determine the location of an endpoint for a service. DCS maintains a list of endpoints and service implementations in the Discovery database. An administrator can configure these endpoints and services by using the DCS Management Services console.

The Discovery Service supports system recovery and business continuation scenarios. A client application can transparently fall back to another instance of a service if a failure occurs.

DCS provides a centralized store for service policies in a SQL Server database. An administrator can configure service policy by using the DCS Management Services console.

When a client application first connects to a service instance, a WS-MetadataExchange communication occurs. This communication lets the client determine the policies exposed by the service instance. All communications between the client and service must comply with these policies. The DCS infrastructure provides a client-side policy importer that transparently applies the correct set of policies to the client application when it communicates with the service. Therefore, the policies mandated by a DCS service can be easily changed by an administrator. The new policy requirements are detected and applied automatically the next time that a client opens a communications channel with the service. The administrator does not have to change the client configuration.

DCS can use almost any external directory of users to perform authentication. However, by default, DCS implements a security model that is based on credentials stored in the Microsoft Active Directory® directory service. The DCS message bus implements a service authority that can use a built-in Security Token Service (STS) to generate SAML tokens. The DCS STS follows the WS-Trust protocol.

An administrator configures the security policy for a service by using the DCS Management Services console. You can use SAML tokens that the STS issues to encrypt and sign messages as specified by the security policy for the service, following the WS-Security specification. This is handled by the client-side proxy and is transparent to the business logic in a client application.

DCS can be configured to use an external authorization service (another STS) that implements the WS-Trust specification. DCS can request authorization for a user based on the SOAP action of the operation being invoked, information that was provided in the scope of the client request, and the identity of the client (which could be provided as claims in a SAML token). A service can perform additional authorization when it receives a request by implementing its own mechanism for examining the identity associated with the request.

DCS client applications connect to a DCS service by using a proxy object. When a developer uses the DCS Software Factory to build a service, the tools generate an assembly that contains a proxy class for the client applications to use. The proxy connects the client application to the DCS message bus. It is an extended WCF proxy that hides the complexity of discovering services through the Discovery Service and importing and applying the policies required to communicate with a service.

Show: