Déploiement d'un workflow en tant que service Web
L'infrastructure Windows Workflow Foundation prend en charge l'interopérabilité des services Web. Cela inclut la capacité d'exposer un workflow comme service Web aux clients ASP.NET et à d'autres workflows. Windows Workflow Foundation prend en charge la publication d'un workflow comme service Web ASP.NET sur un serveur Web ou une batterie de serveurs qui exécutent ASP.NET sur IIS (Internet Information Services) 6.0. Du fait que la prise en charge du service Web Windows Workflow Foundation est basée sur ASP.NET 2.0, elle hérite de la plupart des fonctionnalités d'un service Web ASP.NET standard.
La bibliothèque d'activité de base de Windows Workflow Foundation contient les activités WebServiceInputActivity et WebServiceOutputActivity, qui activent un workflow devant être utilisé comme point de terminaison de service Web. Pour plus d'informations sur l'utilisation d'activités de service Web, consultez Utilisation de l'activité WebServiceInputActivity et Utilisation de l'activité WebServiceOutputActivity.
Hébergement Web du workflow
Les classes primaires utilisées pour l'hébergement Web du workflow sont :
WorkflowWebHostingModule
La classe WorkflowWebHostingModule est le mécanisme de routage par défaut permettant de router une demande de service Web à une instance de workflow appropriée à l'aide de cookies ASP.NET. Bien sûr, les clients qui font ces demandes sont tenus de prendre en charge des cookies.
Bien que Windows Workflow Foundation fournisse ce mécanisme de routage par défaut, vous pouvez implémenter votre propre routage personnalisé. Par exemple, dans les cas où l'activation de cookies auprès du client n'est pas une option, le client pourrait être configuré en vue de créer l'instance de workflow avec un ID spécifique et passer l'ID sur chaque demande de service Web. Le pipeline de demande pourrait être configuré avec les gestionnaires SOAP ou HTTP en vue d'intercepter l'appel, en récupérant l'ID de l'instance du workflow des informations d'en-tête, puis en affectant la valeur HttpContext.Current.Items.Add("__WorkflowInstanceId__", workflowInstanceId) à l'ID entrant.
ManualWorkflowSchedulerService
La classe ManualWorkflowSchedulerService est une implémentation spécialisée de WorkflowSchedulerService qui contrôle le nombre de threads engendré dans un processus ASP.NET en réutilisant le thread qui a fait la demande Web ASP.NET d'exécuter l'instance de workflow. Cela garantit qu'à tout moment, le nombre de threads actifs dans l'exécution du workflow est égal au nombre de demandes Web actives dans le processus ASP.NET.
Limitations du workflow exposées comme services Web
Instance qui route des travaux selon une session ASP.NET. Comme tout consommateur de service Web, il doit prendre en charge un cookie ASP.NET.
Bien que l'opération Réception d'une demande - Envoi d'une réponse puisse être modélisée comme asynchrone à l'intérieur d'un workflow, la limitation générale d'ASP.NET s'applique au consommateur d'un service Web, autrement dit, une instance ne peut pas faire migrer des processus entre une opération demande-réponse en attente.
Activation des cookies pour appeler un service Web de workflow
Un service Web de workflow utilise des cookies pour effectuer le suivi d'état. Si vous publiez un workflow comme un service Web, vous devez activer les cookies dans le code client qui l'appelle. Par exemple :
CalculatorWorkflow_WebService service = new CalculatorWorkflow_WebService();
service.CookieContainer = new System.Net.CookieContainer();
Cela vous permet de faire des appels de méthode sur le 'service' objet.
Voir aussi
Référence
WebServiceInputActivity
WebServiceOutputActivity
WorkflowWebHostingModule
ManualWorkflowSchedulerService
Concepts
Communication avec d'autres workflows
Utilisation de l'activité WebServiceInputActivity
Utilisation de l'activité WebServiceOutputActivity
.gif)
Copyright ©2007 par Microsoft Corporation. Tous droits réservés.