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.
We established that Windows Workflow Foundation isn't an end user product in a recent entry . In this
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.
i have written a excel-like application with the Infragistics Ultragrid.
More then 200 Columns, 1000 Rows....
every Cell (!) uses a RuleSet (WF-RuleSet) to calculate the Layout (the Layout depends on multiple Values in multiple Cells)
With the RuleSet-Editor the Layout-Rules are high customizible for my user/customer
it works fast!
I'm building a software using WF.
I'm using WF because clients have different business logic. So I'm leaving the funcionality of build the business logic to clients. I think it is a very interesting use. I'll build a example to put in www.codeplex.com to brazilian software developer comunnity (I'll make the documentation in portuguese) know better about WF using. I'll build a virtual store and I'll use workflow to pageflow, to save data on database, to tracking and transaction.
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?
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.
most of us think that MWF is just another tool in the pandora box to write application. I think quite differently. I think this is going to be a new way of writing applications. The use if we think carefully is very extensive. If we put our mind to it we can nearly write anything using MWF with minimum code. The catch is if MFW takes off we are not going to wait for IT engineers to write applications for us but we are going to write our own applications as per our needs. At one time IT staff did the spreadsheets for thier finance department. Now they Finance do it themselves. It is not what the technlogy can do for us but what we can do with technology.
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.
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.
Just highlighting Paul's great post that he wrote the other week about "What to use Workflow Foundation...
I am contemplating using WF on a rather large ASP.NET project that we are embarking on, but the options are so vast and the learning curve so steep that I'm not sure where to head with WF.
In our design we heavily rely upon swimlane diagrams to model business processes. I have always thought that workflow (from a business perspective, not a technical one) is about the transfer of responsibility for a given work entity, and swimlane diagrams document that transfer very elegantly. e.g. The responsibility for an Order transfers from order fulfillment to shipping once the order fulfillment folks have assembled the order. This can also be modeled as a transition in a state machine, but state machines are confusing to look at for long, complex business cycles that are being modeled.
I want to set up business rules that define what work must be performed (from a DB perspective, this means validating the existence of certain rows|entities and that certain fields in those entities have data) before the transition to a new state, or transfer of responsibility, is allowed to occur. I also want to notify the next responsible person via email when they have work to do.
It's not clear to me what the best path is to achieving this in WF. Does anyone have experience with this scenario?
What I think WF is best for:
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.
With WF we are trying to provide the low level technology for workflow solutions that is well known and can be considered a solved problem. The engine represents this but there are many things above the engine that we haven't built and could be built in many different ways for many different types of scenarios.
We don't have swim lanes out of the box in WF and we also don't have the concept of assigning something to a resource or person. These can be easily built on top of WF and Microsoft Office SharePoint Server does provide task assignment to people. I would be interested in hearing from anyone who is planning to build swimlane technology on top of WF as I have described.
Hope this helps.