We established that Windows Workflow Foundation isn't an end user product in a recent entry. In this entry I want to give my opinions on what software developers should be using WF for. WF is a new capability in the .NET Framework 3.0 that developers have to use in solutions that they build. After working with lots of customers using WF for a while now it's really interesting to step back and consider the common uses that they make of WF. These are what I've observed. Some, but not all are ones that we expected when the technology was first announced back at the PDC 2005.
1. Building a Process Server (or a BPM Server)
It seems like the most obvious use of WF in projects so far is when you're building a process server product. People building a process server already know all about process execution, how it is different from writing procedural code and all the considerations required for that type of work. The WF runtime is a common piece of technology to process servers and it represents a commoditisation of that engine. It's not surprising then that several process server vendors have moved to WF already. They don't have to maintain that engine code any longer, this leaves the process server vendor to focus on higher level features
But in terms of the number of .NET Framework developers out there, process servers are a relatively small percentage. So the really interesting question is what are regular .NET Framework developers using WF for in their projects?
2. Long Running Business Logic
WF is well suited to implementing long running business logic. Some software doesn't require any business logic. But most enterprise software projects do. They need lots of it and much of the time is spend discussing with the business owners what the software should do. I think of the enterprise software developers job as translating business requirements into lines of procedural code. When you translate a long running process into code you have to write several distinct methods in code that act as atomic blocks of the process. For example when responding to a purchase order being received the process may involve requesting stock from a supplier with some delay. Procedural code can't just pause waiting for a response here (unless it's very poorly designed), you have to deal with the state and any message correlation once the waiting event is received. WF solves that by modelling the process at a slightly higher level than directly in code. You still have to write code but the state management, persistence and correlation of incoming messages is provided by the WF runtime.
3. Regularly Changing Business Logic or Rules
WF solves another type of common software problem where a software application is written once and applied to many end customers. Each customer has their own requirements for the business logic implementation and often a long period of customisation before the software can be used. WF provides a model where a set of activities can be built in code and for an individual customer the order of execution of those activities and the properties on those activities can be customised easily in the WF designer. The software is still built primarily in code, but customisation of the model for a new customer or just for a customer that requests change frequently becomes much easier.
WF allows a scenario where business logic inplemented as a workflow model or as a set of rules can be changed while the application is executing. No redeployment of .NET assemblies or recompilation is required. This leads to a software design where a central repository of business logic is possible that can be edited as part of normal work processes.
4. Require Visibility into Business Logic Execution or Model
Once you decide to build your business logic as a workflow model you can take advantage of services provided by WF. These services include ACID transactions, compensating actions, exception management and process tracking. The tracking service provides visibility into executing workflow instances and the tracking service like other services is something that can be applied to the workflow runtime without adding extra code. Very often adding tracking or logging requires additional code to be written after the main software is complete.
You also gain visibility into the workflow model simply because you can view a workflow model in the workflow designer, and you can print it out or take a copy of the image for inclusion in a functional specification. This can be valuable in explaining the software to non-developers or it could be useful documentation for when a software design needs to be learned by others and modified later.
What do you think?
What do you think WF is best suited for in software development? Have you built a system that uses WF for long running business logic? If you've read this far then I'm interested in your feedback. Please add a comment here.