How DCS Implements Services and Operations

A DCS service exposes one or more operations to client applications. An operation is a logical abstraction of a piece of business logic. You implement this logic by defining a task. A task is an item of executable code. You can use the Business Logic Visual Studio Extensions to define an operation for a service, and you can use a Windows Workflow Foundation (WF) workflow or an ordinary .NET Framework class to implement the operation. You compile the workflow or .NET Framework class into an assembly, and then deploy this assembly on the server that will host the service.

By default, when you use the DCS Software Factory tools to deploy an assembly that implements one or more tasks, the DCS Service Publishing utility configures the operations that you defined for your service so that they refer to the tasks implemented by the assembly. At first, there is a one-to-one correspondence between operations and tasks. However, you can create additional implementations of a task, and then use the DCS Management Services console to associate each implementation with the same operation.

When a client application sends a request message to a DCS service, the request message includes context information as metadata in the message header. Part of this context information can be used by the Discovery Service to help determine the most appropriate service instance to use for a client application. (For more information, see How a DCS Client Invokes an Operation). The context can also include environmental information about the client application, such as the culture of the computer that is running the client application. An administrator can configure a task to respond to a message if the context in the message header matches specified criteria, by defining a task filter. For example, client applications that are running in different locales with different cultures can be directed toward different tasks implementing culture-specific versions of the business logic. For more information about how to define task filters, see Task Filters.

The DCS runtime includes an activator component that examines the context in the header of incoming request messages, and then loads the assembly that contains the appropriate task implementation into the host process for the service. The following image shows this process.

Dd632140.40cd26b4-e706-409b-8f18-f7f904e714dd(en-us,MSDN.10).png

Directing a client request to a specific task

The conversational model implemented by DCS enables a service instance to maintain state information between calls to operations. When a client application starts a conversational service, the DCS runtime generates a unique ID for that service instance. The runtime automatically routes follow-up requests from the same client application for operations in that service to the same service instance. The service instance ID is returned to the client application in the context object. The DCS runtime uses the service instance ID to match subsequent calls made by the client application and to make sure that they are dispatched to the correct service instance, as shown in the following image. This ID is known as the correlationID for the conversation.

Dd632140.69818078-e26e-45d7-b357-044d44d23c7b(en-us,MSDN.10).png

Client application Invoking operations in a conversational service

DCS lets multiple client applications interact with the same service instance that is executing a conversational workflow. To achieve this, the client application that starts the conversation can transmit the correlation ID to a second client application that wishes to participate in the same conversation. The second client application can add this correlation ID to the Correlations property of the context object it uses when it sends a request. The DCS runtime can then route the request from the second client to the same service instance. The following image shows this process.

Dd632140.07db9e9b-fc8b-47c0-9161-26521ee2808b(en-us,MSDN.10).png

Multiple client applications that share the same conversational service instance

Dd632140.note(en-us,MSDN.10).gifNote:
 Client applications can use any convenient mechanism to transmit correlation IDs to one another. In an enterprise environment, you could store this information in a database and then implement a catalog of active service instances.

If it is not convenient or safe for client applications to maintain and transmit service IDs to one another, you can implement a ticketer to transparently match client applications with service instances. For more information, see Ticketers.

Show: