Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les services de flux de travail sont des services basés sur WCF implémentés à l’aide de flux de travail. Les services de flux de travail sont des flux de travail qui utilisent les activités de messagerie pour envoyer et recevoir des messages Windows Communication Foundation (WCF). .NET Framework 4.5 introduit un certain nombre d’activités de messagerie qui vous permettent d’envoyer et de recevoir des messages à partir d’un flux de travail. Pour plus d’informations sur les activités de messagerie et leur utilisation pour implémenter différents modèles d’échange de messages, consultez Activités de messagerie.
Avantages de l’utilisation des services de flux de travail
À mesure que les applications deviennent de plus en plus distribuées, les services individuels deviennent responsables de l’appel d’autres services pour décharger une partie du travail. L’implémentation de ces appels en tant qu’opérations asynchrones introduit une certaine complexité dans le code. La gestion des erreurs ajoute une complexité supplémentaire sous la forme de la gestion des exceptions et fournit des informations de suivi détaillées. Certains services fonctionnent souvent pendant de longues périodes et peuvent occuper des ressources système précieuses pendant qu'ils attendent des entrées. En raison de ces problèmes, les applications distribuées sont souvent très complexes et difficiles à écrire et à gérer. Les flux de travail constituent un moyen naturel d’exprimer la coordination du travail asynchrone, en particulier les appels aux services externes. Les flux de travail sont également efficaces pour représenter des processus métier de longue durée. Il s’agit de ces qualités qui rendent le flux de travail un excellent atout pour créer des services dans un environnement distribué.
Implémentation d’un service de flux de travail
Lors de l’implémentation d’un service WCF, vous définissez un certain nombre de contrats qui décrivent le service et les données qu’il envoie et reçoit. Les données sont représentées sous forme de contrats de données et de contrats de message. Les services WCF et de flux de travail utilisent des définitions de contrat de données et de contrat de message dans le cadre des descriptions de service. Le service lui-même expose les métadonnées (sous la forme de WSDL) pour décrire les opérations du service. Dans WCF, les contrats de service et les contrats d’opération définissent le service et les opérations qu’il prend en charge. Toutefois, dans un service de flux de travail, ces contrats font partie du processus métier lui-même. Ils sont exposés dans les métadonnées par un processus appelé inférence de contrat. Lorsqu’un service de flux de travail est hébergé à l’aide WorkflowServiceHost, la définition de flux de travail est examinée et un contrat est généré en fonction de l’ensemble des activités de messagerie trouvées dans le flux de travail. En particulier, les activités et propriétés suivantes sont utilisées pour générer le contrat :
Receive Activité
SendReply Activité
TransactedReceiveScope Activité
Le résultat final de l’inférence de contrat est une description du service utilisant les mêmes structures de données que les services WCF et les contrats d’opération. Ces informations sont ensuite utilisées pour exposer WSDL pour le service de flux de travail.
Remarque
.NET Framework 4.6.1 ne vous permet pas d’écrire des services de flux de travail à l’aide d’une définition de contrat existante sans prise en charge supplémentaire des outils. Les contrats de service de flux de travail sont créés par le processus d’inférence de contrat décrit précédemment. Toutefois, les contrats de messages et les contrats de données sont entièrement pris en charge.
Services de flux de travail et liaisons basées sur MSMQ
WCF définit deux liaisons basées sur MSMQ NetMsmqBinding et MsmqIntegrationBinding. Les liaisons basées sur MSMQ sont souvent utilisées avec les services de workflow en raison de la longue durée d’exécution de ces services. Les liaisons MSMQ ont une ValidityDuration
propriété qui spécifie la durée pendant laquelle les messages MSMQ peuvent être valides. En raison de la nature longue des services de flux de travail, il est possible que la durée de validité d’un message MSMQ puisse s’écouler avant que le service de flux de travail puisse le traiter. Il est donc très important d’affecter une valeur appropriée à la durée de validité d’une liaison MSMQ. Cette valeur doit être choisie en fonction du flux de travail et de la façon dont elle traite les messages. Par exemple, si vous avez un flux de travail avec une Receive activité suivie d’une activité personnalisée qui prend 10 minutes à s’exécuter, suivie d’une autre Receive activité, la valeur correcte est ValidityDuration
supérieure à 10 minutes.
Hébergement d’un service de flux de travail
Comme les services WCF, les services de flux de travail doivent être hébergés. Les services WCF utilisent la classe ServiceHost pour héberger des services et des services de flux de travail utilisent WorkflowServiceHost pour héberger des services. Comme les services WCF, les services de flux de travail peuvent être hébergés de différentes façons, par exemple :
Dans une application .NET Framework managée.
Dans Internet Information Services (IIS).
Dans le service d’activation des processus Windows (WAS).
Dans un service Windows géré.
Les services de flux de travail hébergés dans une application gérée par .NET Framework ou un service géré par Windows créent une instance de la classe WorkflowServiceHost et transmettent une instance de WorkflowService contenant la définition de flux de travail dans la propriété Body. Une définition de flux de travail qui contient des activités de messagerie est exposée en tant que service de flux de travail.
Pour héberger un service de flux de travail dans IIS ou WAS, placez le fichier .xamlx qui contient la définition du service de flux de travail dans un répertoire virtuel. Un point de terminaison par défaut (utilisation BasicHttpBinding) est créé automatiquement pour plus d’informations, consultez Configuration simplifiée. Vous pouvez également placer un fichier Web.config dans le répertoire virtuel pour spécifier vos propres points de terminaison. Si votre définition de flux de travail se trouve dans un assembly, vous pouvez placer un fichier .svc dans le répertoire virtuel et l’assembly de workflow dans le répertoire App_Code. Le fichier .svc doit spécifier la fabrique hôte de service et la classe qui implémente le service de workflow. L’exemple suivant montre comment définir l'usine d'hôte de service et la classe qui implémente le service de flux de travail.
<%@ServiceHost Factory="System.ServiceModel.Activities.Activation.WorkflowServiceHostFactory"
Service="EchoService"%>