Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Contrairement on ce que l’on pourrait croire, le WorkflowServiceHost n’est pas juste une petite refonte de l’hôte de service WCF pour exposer des workflows Xamlx via WCF. Oh non ! le WorkflowServiceHost va plus loin, beaucoup plus loin.

Avant de m’expliquer d’avantage sur le WorkflowServiceHost, je tiens à réaffirmer que l’on ne se trouve pas obliger d’écrire des fichiers Xamlx pour exposer un workflow. Pour plus d’explication sur ceci, je vous renvoie à l’un de mes précédents articles sur WF4+WCF : Hoster un service WF sans Xamlx, ni IIS… ni BasicHttpBinding.

Mais revenons à nos moutons ;)

Quelles sont les rôles du WorkflowServiceHost ?

Dans un premier temps, on voit surtout l’hôte de services et donc les éléments de base de WCF et de son ABC et donc :

• Les Endpoints sont configurable et exploitables via le WorkflowSericeHost.
• Les Bindings sont configurable et exploitables via le WorkflowSericeHost.
• Les Contrats… ne servent malheureusement pas à grand-chose dans la monture actuelle de WF4. On peut uniquement choisir le nom qui sera utilisé par le service, mais WF4 ne respectera aucune interface.

Au détail près du contrat qui est de la responsabilité du workflow et non pas de son hôte, on a là des éléments bien connu de WCF. Maintenant, partons dans la dimension Workflow Foundation :

Dans WF4 on utilise généralement un WorkflowInvoker ou un eWorkflowApplication. Le premier est un peu limité, et le second offre accès a toute une palette de fonctionnalités liées à WF4. C’est là que Microsoft a fait fort avec le WorkflowServiceHost : Tout ce qui est accessible avec un WorkflowApplication l’est avec le WorkflowServiceHost . Donc on peut :

• Utiliser des extensions.
• Utiliser la persistance.
• Utiliser le tracking.
• Utiliser des bookmarks (même si les activités Receive sont vraiment plus faciles à utiliser)
• Piloter le comportement des instances de workflow en cas : d’erreur, attente, annulation…

Mais là où le WorkflowServiceHost est vraiment impressionnant, c’est qu’il ne gère pas qu’une instance de workflow.

Je vais prendre quelques secondes pour être le plus claire possible :

Un WorkflowServiceHost comme un hôte WCF n’expose qu’un service, et donc qu’un workflow. De la même manière le workflow peut donc être consommé par plusieurs clients et donc peut avoir plusieurs appels concurrents. On peut donc avoir comme pour un service classique plusieurs instances de Workflow qui fonctionnent au même moment.

Ceci est géré par le WorkflowServiceHost. Par défaut, on ne se retrouve donc pas qu’avec une seule instance de Workflow. Ne cherchez donc pas à mettre en place un Variable dans votre workflow pour la rendre globale à vos clients de votre service. Cela ne fonctionne pas comme ça ;)

Bien entendu le WorkflowServiceHost est aussi responsable de la libération des ressources propres à chaque instance de Workflow. Ainsi, quand un workflow arrive à son terme, il n’est pas laissé en suspend, mais se termine normalement comme pour une WorkflowApplication.

Là où WF4 va loin, c’est qu’il est possible de gérer la corrélation. Ce dispositif merveilleux est de la responsabilité du WorkflowServiceHost, qui en fonction des appels effectués par les clients WCF serra en mesure de déterminer quelle instance de Workflow est concernée (promis, je referais un point complet prochainement sur la corrélation).

On pourra donc imaginer partager un même workflow avec plusieurs clients WCF. Le WrokflowServiceHost peut donc permettre des scénarios très évolués avec des instances de workflow invoquées par des clients WCF et poursuivis par d’autres. A l’époque bénite du SAAS on peut déjà se voir dématérialiser certain processus lourd en services…

Mais comment les chosent se passent si mon application est interrompue (plantage ou reboot d’un serveur) avant que toutes mes instances de workflow se soient terminées ?

Comme dit plus haut, le WorkflowServiceHost sait gérer la persistance. On peut donc en tirer partie ici et faire persister ses workflows. Lors d’un appel d’un client WCF, le WorkflowServiceHost serra en mesure de déterminer si le client fourni des informations de corrélation liées à un workflow persisté, de quelle instance il s’agit. Il peut alors la raviver.

On a donc là un dispositif très évolué capable de mettre en base de données des instances de workflows en attente et de les extraire dès que l’on en a à nouveau besoin.

Donc, avec un WorkflowServiceHost, aucun besoin de réinventer la roue, elle tourne très bien et s’adresse déjà aux scénarios les plus courants, comme les plus évolués. Dans des applicatifs type SAAS, le WorkflowServiceHost a donc un grand rôle à jouer.

… une petite couche d’AppFabric là dessus et… hummmm ;)