Du point de vue d'un non-expert, il y a deux choses qui, pour moi, de faire le cas pour WF-l'un flux de travail unique à des plates-formes, les autres peut-être plus de commodité chose.
La commodité est la capacité à créer de nouvelles façons de composer des activités. La programmation impérative fournit un répertoire limité de composition primitives: fondamentalement, le séquençage, l'if-else et des boucles. WF vous permet de construire votre propre composition des opérateurs tels que l'exécution entrelacée, l'exécution en parallèle, first past the post, etc. Et bien sûr, il a la composition sophistiquée mécanisme de machines d'état intégré.
Je dis que c'est une fonctionnalité pratique parce que vous pouvez construire tous ces opérateurs dans un langage impératif comme le C#: en fait, c'est comment vous construire le WF opérateurs. Mais WF rend facile à utiliser et à lire personnalisé compositions, alors qu'en C# vous avais rapidement descendre dans une grêle de lambda expressions. Donc, si vous avez une orchestration complexe exigences-qui est, si la façon dont vos activités ensemble, c'est plus compliqué que de séquences, if-else et boucles -- puis WF peut rendre votre programme plus facile à exprimer et à comprendre.
La caractéristique unique est la durabilité. C'est là que le Shukla et Schmidt livre commence à partir, et où il revient sans cesse. Un impératif programme écrit en C# ou VB peut courir pendant des heures, des jours, des semaines, si c'est de la chance, peut-être même des mois... mais finalement IIS va le cycle de l'application de la piscine, ou les admins vont vouloir installer les dernières mises à jour de sécurité, ou quelqu'un va trébucher sur le cordon d'alimentation. Alors, comment est-ce que votre programme rappelez-vous, "d'accord, j'ai le bon de commande à partir d'Imagination Noms de Société R Us, et je suis en attente sur une approbation de crédit de la Banque de Breadheads Inc., et quand je reçois ce que je peux envoyer l'e-mail de confirmation"?
Dans un classique programme impératif, lorsque le processus meurt, l'état d'exécution meurt avec elle. Vous pouvez démarrer un nouveau processus, mais il va commencer au début du programme. Bien sûr, vous pouvez créer une base de données et l'utiliser pour stocker les drapeaux comme "a obtenu la commande d'achat" et "a obtenu une approbation de crédit." Mais maintenant vous avez à écrire spécifique à l'application du code de sauvegarder et de rechercher de l'état, et de revenir au point de droit dans le programme en fonction de cet état. Et vous avez à la conception d'une nouvelle base de données et de nouvelles sauver/restaurer/saut logique pour chaque application qui tourne depuis longtemps.
Durable de flux de travail est de s'attaquer à ce problème. Si vous écrivez votre programme comme un flux d'activités, alors WF prendra soin de la persistance de son état, y compris lorsqu'il est dans son flux d'exécution. La machine qui exécute le programme peut prendre feu et brûler votre centre de données, mais quand la réponse de la banque vient en, WF réveillera votre programme dans votre autre centre de données, et il va commencer à courir au bon endroit et avec les bonnes données.
Pour moi, c'est le "fort" pour WF. Dans de nombreux cas, vous n'en avez pas besoin: les applications sont suffisamment courte durée que l'échec n'est pas une préoccupation importante, et de redémarrer à partir de zéro est viable de la stratégie de rétablissement. Mais pour les applications de longue durée, tels que l'endroit où vous pouvez être à l'orchestration externe des systèmes qui peuvent prendre des heures à répondre, ou des processus d'affaires qui impliquent les humains qui peuvent prendre des jours pour responsables, la durabilité peut être la killer feature pour WF.
Avertissement: je ne suis pas un WF programmeur et n'ont jamais construit un monde réel WF système. Je viens à ce à partir d'une BizTalk arrière-plan, et de ce que j'ai lu sur WF, de sorte que cette évaluation est un peu théorique. Espérons que cela aide tout de même!
