Is there any overlap between MS WF and NServiceBus, in terms of workflow specifically? Is there a need to use one if the other is already in use? How well do they play together?
NServiceBus supports workflows through "sagas", http://nservicebus.com/Sagas.aspx
The key difference is that Sagas is easier to unit test and that you don't have to worry about consistency since NSB's underlying use of queues and DTC makes sure that failed steps are retried automatically.
Udi has a podcast discussing all this:
http://www.udidahan.com/2007/10/23/podcast-durable-services-with-wcf-wf-and-nservicebus/
In short: If you use NSB there would be no need IMO for MS WF.
I would like to give my 2 cents:
I'm working in new project with a quite complex domain, where some domain workflows may evolve and change in some different scenarios. We've been analysing the possible solutions to orchestrate the different application Servers (WCF services). The first architectural solution we analysed was using a Service Bus + PubSubs pattern (nservicebus, rhino ESB, masstransit, Shuttle ESB...). The other solution we analysed was WF 4.0. We are close to make the decision and by now WF 4.0 is the chosen one because:
- Workflows are modelled using workflow diagrams
- Workflow diagram designer can be embedded in a custom application, that can be used to evolve workflows during production since they are defined in XAML.
- PubSubs pattern with sagas, somehow would dilute how the workflow is modelled and in some complex scenarios it'd be difficult to have a clear view of how the workflow works
- WF 4.0 Workflow services is on top of WCF, so you can have Send/Receive activities that talk to WCF endpoints. Therefore, we have all the power and flexibility of WCF: security, reliable comms, MSMQ, WS* standards, ...
- WF 4.0 services can be hosted on Appfabric: scalability, maintainability, monitoring and troubleshooting made easy
There is a con that we're are already analysing that is the fact that WF 4.0 does not support state machines (like it did in version 3.5). Although MSFT explains how to implement state machines using the new Fowchart activities shipped with 4.0
Hope this helps,
Juanjo
I have to disagree with @Andreas Öhlund. This is like saying "I have C# and the .NET Framework, so why do I need to buy an ERP system?" @jdearana's answer is much more balanced.
The NServiceBus documentation for Sagas is one page (5 screens on my monitor). The book Pro WF is 850 pages. (I've read it; it's not filler.) The book Professional K2 blackpearl (discussing a full BPM system) is 870 pages (Amazon's count is off).
Even WF 4 (excluding SharePoint) is not a full-featured BPM system. It's missing an activity-level security model, locking ("Bob has claimed this work order, but has not completed it yet"), advanced versioning, and reporting. You can build all of these things, but they aren't in the "box."
Look at the Timeouts section of the NServiceBus Sagas page. Compare that to the visual method of doing an expiration in WF 4. Imagine keeping track of this in a complex workflow, where timeouts (escalations) are needed every time a manager wants to be notified that an employee is taking too long in a document-processing system.
I agree that workflows are sometimes overkill, and that they can be hard to test. (There are ways to unit test WF 4.) But I would not want to build a real-world, BPM-style workflow with NServiceBus.
NServiceBus supports workflows through "sagas", http://nservicebus.com/Sagas.aspx
The key difference is that Sagas is easier to unit test and that you don't have to worry about consistency since NSB's underlying use of queues and DTC makes sure that failed steps are retried automatically.
Udi has a podcast discussing all this:
http://www.udidahan.com/2007/10/23/podcast-durable-services-with-wcf-wf-and-nservicebus/
In short: If you use NSB there would be no need IMO for MS WF.
© 2022 - 2024 — McMap. All rights reserved.