Utilisation de services locaux dans les workflows

Article
09/12/2008

Windows Workflow Foundation prend en charge les services de communication locaux dans l'environnement d'hébergement de workflow, ainsi que les communications entre workflows via les services Web. Pour plus d'informations sur les communications entre workflows à l'aide des services Web, consultez Communication avec d'autres workflows.

Les services de communication entre flux de travail de Windows Workflow Foundation exposent une classe de service définie par l'utilisateur au writer de flux de travail en tant qu'appels de méthode et gestionnaires d'événements, afin de simplifier la modélisation d'échanges de messages sortants et entrants. Le multiplexage d'une instance de classe de service unique vers plusieurs instances de flux de travail permet au writer hôte de programmer un emplacement unique pour les messages sortants tout en continuant à cibler des instances de flux de travail spécifiques lors du déclenchement d'événements.

Le diagramme suivant illustre la méthode utilisée par un service de communication local pour communiquer avec son application hôte.

Communication d'hôte local

Les activités HandleExternalEventActivity et CallExternalMethodActivity présentes sur l'instance de workflow interagissent avec les événements et les méthodes déclarées au sein d'une interface personnalisée ; elles sont implémentées dans un service local personnalisé. L'activité HandleExternalEventActivity répond à un événement particulier déclenché par l'application hôte et est implémenté par le service local. L' CallExternalMethodActivity appelle une méthode au niveau du service local. Pour plus d'informations sur l'utilisation de HandleExternalEventActivity et de CallExternalMethodActivity, consultez Utilisation de l'activité HandleExternalEventActivity et Utilisation de l'activité CallExternalMethodActivity.

Services de communication entre workflows

Les services de communication entre workflows de Windows Workflow Foundation implémentent un mécanisme simple pour que les objets puissent communiquer avec une instance de workflow. La définition du canal de communication est une interface, et son implémentation est une classe de service ajoutée à l'exécution pour faciliter la communication.

Dans la classe de service, le workflow se comporte comme toute autre classe, et vous communiquez avec lui en déclenchant des événements et recevant des appels de méthode. Dans le workflow, l'interface de communication apparaît comme un canal qui contient des récepteurs d'événements entrants, ainsi que des appels de méthode d'opération sortante.

Les déclarations de méthode externes sur l'interface sont converties par le ExternalDataExchangeService en appels de méthode sur l'objet de service. La classe que nous pouvons considérer comme un service local déclenche des événements, qui sont interceptés par le moteur d'exécution de workflow et remis comme messages entrants pour le workflow.

L'exemple de code suivant illustre la méthode de définition d'une interface de communication de workflow locale.

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

Classe de service

Une classe de service implémente une interface utilisée pour définir des communications avec un workflow. Tous les événements présents sur l'interface sont unidirectionnels, ce qui signifie qu'ils ne possèdent pas de paramètres ref ou out et qu'ils n'ont aucune valeur de retour. Toutefois, pour les demandes sortantes, les méthodes présentes sur l'interface peuvent posséder des paramètres ref et out, ainsi qu'une valeur de retour.

Le modèle de communications est de type plusieurs-à-un : présence de nombreuses instances de workflow, chacune d'entre elles pouvant transférer de nombreuses conversations avec cet objet de service singleton. Cela signifie que tous les appels sortants à une méthode spécifique, m, en provenance de tous les workflows, sont traités par la même méthode m sur le même objet.

Inversement, tous les appels entrants doivent être acheminés explicitement vers l'instance de workflow et vers la conversation appropriées. Windows Workflow Foundation fournit à la méthode m un mécanisme permettant de faire la distinction entre l'instance de workflow et la conversation de l'appel sortant. Grâce à ces deux informations, l'objet peut transmettre une réponse à la conversation appropriée, sur l'instance de workflow appropriée.

Windows Workflow Foundation inclut l'identificateur d'instance du workflow appelant dans l'System.Workflow.Runtime.WorkflowEnvironment.WorkflowInstanceId, sur le thread appelant sortant.

L'exemple de code suivant illustre une implémentation du service de communication.

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));
    }
}

Avant de démarrer une instance de votre workflow, vous devez ajouter le ExternalDataExchangeService au moteur d'exécution de workflow, puis ajouter votre service de communication personnalisé au ExternalDataExchangeService comme l'illustre l'exemple de code suivant.

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

Pour obtenir un exemple de communication hôte avec un service local, consultez HostCommunication Sample.

Voir aussi

Utilisation de services locaux dans les workflows

Services de communication entre workflows

Classe de service

Voir aussi

Référence

Concepts

Autres ressources

Ressources supplémentaires