What to use Windows Workflow Foundation for?
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.
Comments
Anonymous
February 01, 2007
We established that Windows Workflow Foundation isn't an end user product in a recent entry . In thisAnonymous
February 01, 2007
I find Dave Green's <a href="http://blogs.msdn.com/davegreen/archive/2005/09/17/470704.aspx">post on this same topic</a> very useful.Anonymous
February 01, 2007
The comment has been removedAnonymous
February 04, 2007
The comment has been removedAnonymous
February 05, 2007
我们在上次的文章已经提及了WF工作流不是一个终端用户的产品。在这篇文章里我想表明一下我的观点：开发人员到底应该使用WF来干嘛？WF是.net3.0框架中的一个新技能，开发人员必须在他们创建的解决方案使...Anonymous
February 05, 2007
It seems to me that Workflow would be useful any time you're implementing a non-trivial state machine in software. Is this the case? It seems that since everybody describes state machines in terms of a diagram anyway that it would be most natural to make changes to the diagram itself and have that propagate to code. Is there something I'm missing as to why this would be a bad idea? Is it not worth the cost when you don't have a large number of processes to manage or they don't change very often?Anonymous
February 08, 2007
Hi Farmer Buzz, Yeah you could use it just as a state machine in code. For simple state machines the separate context that workflow instances run on will be a consideration. Marshalling is required to get data into and out of workflow instances. You can donate your thread to the workflow instance so that it doesn't run on a CLR Thread Pool thread, but you would still have to send data into and out of the workflow using marshalled messages. Because of this it makes most sense to put your end to end business process in the workflow instance. Regards, PaulAnonymous
February 10, 2007
The comment has been removedAnonymous
February 23, 2007
I am not convinced by WF in real business logic applications. Real life business gets complicated quickly, with exceptions. The resulting Sequence/ State diagrams become complicated quickly defeating the objectives of a WF presentation. I have seen a WF Webcast, which involved over thrity activities, and exception branches, to model what seemed like a simple business process. The Presenter lost the audience, because the WF was so complicated, scrolling over 3 windows wide,and 4 windows down.Very unconvicing.Anonymous
February 25, 2007
Hi Jules, I'm not familiar with that web cast please share the URL. Certainly there are challenges in creating workflows for large business problems. It sounds like your example was using activities that were too low level for the business problem being solved. Regards, PaulAnonymous
February 27, 2007
Just highlighting Paul's great post that he wrote the other week about "What to use Workflow Foundation...Anonymous
February 27, 2007
The comment has been removedAnonymous
February 27, 2007
What I think WF is best for: http://udidahan.weblogs.us/archives/362Anonymous
February 28, 2007
One of the problems that I have faced with using the workflow is if we have to change the workflow due to a change in business requirement. Making the change to the WF is easy but the real problem happens when there are instance of the workflow which have already started and stored in the tracking/persistance stores. Now the new workflow definition does not serialize to the existing workflow definition and causes problems. I do understand that changing the workflow in the middle can be disastrous but I am unable to find solution to handle my scenario. To be more elaborate about my scenario if there is a state machine with states A --> B--> C --> D.In an ideal world (:-)) , when I am in state B changes to state C or D should not cause any problems. I guess I am going to have to write my own custom serialization which can handle changes to workflow definitions gracefully. Please let me know if you heard of any other solution for my scenario. Thanks.Anonymous
February 28, 2007
The comment has been removedAnonymous
February 28, 2007
Paul, I am indeed interested in the idea of building swimlane technology on top of WF, but don't have any plans, as we're a project shop, not an ISV. For the present that helps clarify the direction for this project. For the future: any ISV's out there planning to build Swimlane on top of WF? If so, here's what I want:
- Swimlane designer (lanes, tasks, transfer|flow - don't remember what the UML guys call these)
- Ability to associate with a business object assembly
- Optionally specify rules on transfers to other tasks, each of which must evaluate to true in order for the transfer to be allowed. (e.g. "Order.DeliveryCarrier is specified" before transfer goes to the shipping dept.)
- Specify rules about who is notified when transfer occurs Any takers?
Anonymous
March 01, 2007
Hi Todd, I'd recommend you take your request to the WF MSDN Forum. See http://www.windowsworkflow.net/forums Regards, PaulAnonymous
March 01, 2007
Good idea Paul. I posted it to the forum: http://forums.microsoft.com/msdn/ShowPost.aspx?postid=1291607&siteid=1Anonymous
March 05, 2007
If you have some questions regarding BTS and WF and when to select one, the following may be useful:Anonymous
March 19, 2007
Hi, I have some doubts regarding WF and BTS 1.Can Business Process Orchestration be done without BTS i.e., only with WF. 2.How is WCF connected to all of this..Anonymous
July 17, 2007
Hoy por hoy, las empresas y el mundo de los negocios esta siendo sometido a una especie de terremoto,