Using Local Services in Workflows

Artigo
10/14/2009

Windows Workflow Foundation supports local communication services in a workflow's hosting environment and communications between workflows using Web services. For more information about workflow communications using Web services, see Communicating with Other Workflows.

Windows Workflow Foundation workflow communication services expose a user-defined service class to the workflow writer as method calls and event handlers to simplify the modeling of outbound and inbound message exchange. The multiplexing of a single service class instance to multiple workflow instances enables the host writer to program against a single location for outbound messages while still targeting specific workflow instances when raising events.

The following diagram shows how a local communication service communicates with its host application.

Local host communication

The HandleExternalEventActivity and CallExternalMethodActivity activities on the workflow instance interact with events and methods that are declared in a custom interface and implemented in a custom local service. The HandleExternalEventActivity activity responds to a particular event that is raised by the host application and implemented by the local service. The CallExternalMethodActivity invokes a method on the local service. For more information about how to use HandleExternalEventActivity and CallExternalMethodActivity, see Using the HandleExternalEventActivity Activity and Using the CallExternalMethodActivity Activity.

Workflow Communication Services

Windows Workflow Foundation workflow communication services implement a simple mechanism for objects to communicate with a workflow instance. The definition of the communications channel is an interface, and its implementation is a service class that is added to the runtime to facilitate communication.

To the service class, the workflow behaves much like any other class, and you communicate with it by raising events and receiving method calls. To the workflow, the communication interface appears as a channel that contains inbound event sinks, and outbound operations method invocations.

External method declarations on the interface are converted by the ExternalDataExchangeService into method calls on the service object. The class we can refer to as a local service raises events, which are intercepted by the workflow runtime engine and delivered as inbound messages for the workflow.

The following code example shows an example of how to define a local workflow communication interface.

[ExternalDataExchange]
public interface ICommunicationService
{
    void HelloHost(string message);
    event EventHandler<ExternalDataEventArgs> HelloWorkflow;
}

Service Class

A service class implements an interface that is used to define communications with a workflow. All events on the interface are one-way, that is, they have no ref or out parameters and no return value. However, for outgoing requests, the methods on the interface can have ref and out parameters and a return value.

The communications model is many-to-one: many workflow instances, each of which may be carrying on many conversations, with this singleton service object. This means that all outbound calls to a particular method, m, from all workflows are serviced by the same m on the same object.

Conversely, all inbound calls must be explicitly directed to the correct workflow instance and conversation. Windows Workflow Foundation provides m with a mechanism to distinguish the outbound call's workflow instance and conversation. With these two pieces of information, the object can direct a response back to the correct conversation on the correct workflow instance.

Windows Workflow Foundation supplies the instance identifier of the calling workflow in System.Workflow.Runtime.WorkflowEnvironment.WorkflowInstanceId, on the outbound calling thread.

The following code example illustrates a communication service implementation.

public class CommunicationService : ICommunicationService 
{
    public event EventHandler<ExternalDataEventArgs> HelloWorkflow;

    public void HelloHost(string message)
    {
        Console.WriteLine("This is the message: {0}", message);

        // Raise the HelloWorkflow event.
        HelloWorkflow(null, new ExternalDataEventArgs(WorkflowEnvironment.WorkflowInstanceId));
    }
}

Before you start an instance of your workflow, you must add the ExternalDataExchangeService to the workflow runtime engine and then add your custom communication service to the ExternalDataExchangeService as shown in the following code example.

ExternalDataExchangeService externalService = new ExternalDataExchangeService();
workflowRuntime.AddService(externalService);
externalService.AddService(new CommunicationService());

To see an example of host communication with a local service, see the HostCommunication Sample.

Compartilhar via

Using Local Services in Workflows

Workflow Communication Services

Service Class

See Also

Reference

Concepts

Other Resources

Recursos adicionais