Est-ce que WF et nServiceBus se chevauchent? Comment? Et lequel utiliser?

Question

Existe-t-il un chevauchement entre MS WF et NServiceBus, en termes de flux de travail en particulier? Faut-il utiliser l'un si l'autre est déjà utilisé? À quel point jouent-ils ensemble?

Answer 1

NServiceBus prend en charge les flux de travail à travers « sagas », http://nservicebus.com/Sagas.aspx

La principale différence est que Sagas est plus facile de test unitaire et que vous n'avez pas à vous soucier de la cohérence depuis l'utilisation sous-jacente de NSB des files d'attente et DTC se assure les étapes ayant échoué sont réessayées automatiquement.

Udi a un podcast à discuter tout cela:

http://www.udidahan.com/2007/10/23/podcast-durable-services-with-wcf-wf-and-nservicebus/

En bref: Si vous utilisez NSB il n'y aurait pas besoin de l'OMI pour MS WF.

Answer 2

Je voudrais donner mes 2 cents:

Je travaille dans le nouveau projet avec un domaine assez complexe, où certains flux de travail de domaine peuvent évoluer et changer dans certains scénarios différents. Nous avons analysé les solutions possibles pour orchestrer les différents serveurs d'applications (services WCF). La première solution architecturale que nous avons analysée utilisait un modèle Service Bus + PubSubs (nservicebus, rhino ESB, masstransit, Shuttle ESB ...). L'autre solution que nous avons analysée était WF 4.0. Nous sommes proches de prendre la décision et maintenant WF 4.0 est l'Elu parce que:

• Workflows sont modélisés à l'aide workflow diagrams
• Flux de travail diagram designer can be embedded dans une application personnalisée, qui peut être utilisé pour évoluer les flux de travail en cours de production, car ils sont défini en XAML.
• PubSubs modèle avec Sagas, serait en quelque sorte diluée comment le flux de travail est modélisé et dans certains scénarios complexes, il serait difficile d'avoir une vision claire de la façon dont fonctionne le flux de travail
• WF 4.0 Services de workflow est on top of WCF, de sorte que vous pouvez avoir Envoyer/Recevoir des activités qui parlent aux points de terminaison WCF. Par conséquent, nous avons toute la puissance et la flexibilité de la WCF: la sécurité, comms fiables, MSMQ, WS * normes, ...
• WF 4.0 services peuvent être hébergés sur Appfabric: évolutivité, maintenabilité, la surveillance et le dépannage rendu facile

Nous sommes déjà en train d'analyser le fait que WF 4.0 ne prend pas en charge les machines d'état (comme c'était le cas en version 3.5). Bien que MSFT explains how to implement state machines en utilisant les nouvelles activités Fowchart livrés avec 4,0

Hope this helps,

Juanjo

Answer 3

Je suis en désaccord avec @Andreas Öhlund. C'est comme dire "J'ai C# et le .NET Framework, alors pourquoi ai-je besoin d'acheter un système ERP?" La réponse de @ juanjo.arana est beaucoup plus équilibrée. Le NServiceBus documentation for Sagas est une page (5 écrans sur mon moniteur). Le livre Pro WF est de 850 pages. (Je l'ai lu, ce n'est pas de remplissage.) Le livre Professional K2 blackpearl (discutant un système complet BPM) est de 870 pages (le compte d'Amazon est éteint).

Même WF 4 (sauf SharePoint) n'est pas un système BPM complet. Il manque un modèle de sécurité au niveau de l'activité, le verrouillage ("Bob a revendiqué ce bon de travail, mais ne l'a pas encore terminé"), le versioning avancé et le reporting. Vous pouvez construire toutes ces choses, mais elles ne sont pas dans la "boîte".

Regardez la section Timeouts de la page NServiceBus Sagas. Comparez cela à la méthode visuelle de faire un expiration in WF 4. Imaginez-en un suivi dans un workflow complexe, où des délais (escalades) sont nécessaires à chaque fois qu'un manager souhaite être informé qu'un employé prend trop de temps dans un système de traitement de documents. Je suis d'accord que les workflows sont parfois exagérés et qu'ils peuvent être difficiles à tester. (Il y a ways to unit test WF 4.) Mais je ne voudrais pas construire un workflow de style BPM dans le monde réel avec NServiceBus.