How the DCS Runtime Executes a Service Based on a Conversational Workflow
Conversational workflows let you implement a stateful series of operations. The workflow maintains state between calls to operations in the service. When you develop the workflow, you use the WaitForEvent activity to pause the workflow until a message of a specified type arrives, perform the processing that is necessary to handle this message, and then use the SendResponse activity to send a response to the client application. The sequence of WaitForEvent and SendResponse activities builds up a conversation template to let you control the sequence of messages.
Conversational workflow execution relies on the service to respond to a sequence of events. The conversation is initiated when the client application invokes the first operation in the workflow. The workflow then performs the specified activities, up to the first SendResponse activity. At this point, the workflow sends the required response message and idles on the next WaitForEvent activity in the sequence. The following figure shows this process.
The sequence of messages between a client application and a conversational operation
When the client application receives the response message from the workflow, it can continue execution until it has to call the next operation in the conversation. At this point, the client application creates a new request message of the type that is required by the next operation in the sequence that is defined by the conversation and invokes this operation, passing the request message and context information to the service just like any other operation call. When the service receives the message, it raises the event that the WaitForEvent activity is waiting for, and then the conversational workflow continues execution until it executes another SendResponse activity.
This cycle continues until there are no more WaitForEvent activities left for the workflow to pause on. The workflow sends the final SendResponse message, executes any final functionality, and then terminates.
Each phase of the conversation has its own request and optional response messages. When you define a conversational workflow, the DCS Software Factory generates code that instantiates the request and response objects for the initial exchange with the client application. However, for subsequent exchanges, you must provide the code that instantiates any response messages.
In addition, you must add properties to the workflow to expose an instance of the request and response message for each phase of the conversation. Although the operation template defines the Request and Response properties automatically, these are used only for the first phase of the conversation. Any subsequent phases require different Request and Response properties, matching the required type of Message class. To create the properties, you can write the property code into the workflow code-behind file manually, or you can use the Bind Property dialog box to create the property for you. For more information, see Walkthrough: Implementing a Service by Using a Sequential Conversational Workflow and Walkthrough: Implementing a Service by Using a State Machine Conversational Workflow.
Each instance of the workflow exists from the first incoming message that the DCS runtime receives until the final SendResponse activity that the service executes. You should consider using workflow persistence and the PersistencePoint activity to enable the DCS runtime to dehydrate and store the workflow state during any potential periods of latency and to reduce the resources that inactive service workflows consume. The DCS runtime can automatically rehydrate a service workflow when a client application sends another request. For more information, see The PersistencePoint Activity.