Windows Workflow Foundation
This page will talk about the Windows Workflow Foundation technology.
What is it?
Windows Workflow Foundation (WF) is a framework technology which provides a level of abstraction for developing workflow based applications. Windows Workflow provides the core functionality you would need in a workflow such as flow control, persistence of workflow state, error management and instance management.
I addition to these core concepts of a workflows runtime requirements WF also provides an activity which is a unit of work which you can implement with out of the box activities or extension to your own custom requirements.
WF can be used directly by your own code to implement custom workflows or you could be using WF in directly within a product such as SharePoint or Dynamics CRM which lets you build something like a SharePoint workflow which under the hood use the WF framework.
It is probably fair to say uptake of WF by developers within their own custom applications has been limited and the main reason for that was that WF is a framework technology and you needed to host it inside your own application which would host the WF runtime as there wasn’t really an enterprise ready host available. That said since Microsoft started using the WF framework more in their own products this has given developers the option to create workflows at a higher level of abstraction with the confidence that there is a robust host for the workflow. In this space WF usage has increased significantly but also got developers more accustomed to the underlying framework and given developers more confidence to use it in custom applications too.
The below picture shows an example of how WF implements the process manager enterprise integration pattern.
Windows Workflow Foundation has the following features:
The workflow runtime is the runtime engine under which the WF workflow will execute. The runtime provides access to some of the features mentioned below but the runtime requires something to host it which can be your own code or an application such as SharePoint. The Workflow Runtime contains a class called WorkflowServiceHost which is the one which you would use to self host the runtime inside something like a Windows Service or custom application.
Within the Workflow Runtime there are features which support persistence of the workflow. This means that when a workflow is to perform certain activities the state can be saved so there is a known recovery point the workflow can be returned to in the case of an error.
Correlation is a way to relate a message and a workflow instance. This is important when interacting with applications outside of the workflow so that a message is able to be returned to the correct workflow instance.
An activity is a unit of work within a workflow. Your workflow may be comprised of a number of activities chained together in an order which represents the workflow.
Messaging Activities allow your to send and receive WCF messages in a workflow. This allows your workflow to interact with services outside of the workflow or to expose an endpoint that an application can use to make a call to your workflow.
In .net 4.5 the WF runtime has introduced support for side-by-side versioning of workflows within a host. This means any in flight workflows can continue to work against the older versions of code after a new deployment of an updated workflow.
WF provides some support for common workflow patterns such as a sequential workflow and a state machine workflow. This can make it easier to implement these specific patterns.
The key strength of WF is that Microsoft is eating its own dog food and using WF as a core part of some of its most important products such as Sharepoint, Office 365, Dynamics CRM and its also into Azure BizTalk Services. This should give WF a strong future and some good investment. The fact that WF can be used at a higher abstraction layer in these products makes WF easier to use and more reliable than when you have to do the plumbing work your self when self hosting it.
Originally there were 2 key weaknesses with WF:
- Lack of an enterprise strength host
- Lack of a super user focused authoring story
- I think that these have both been addressed to a large degree by presenting workflow within the container of another product.
- Lack of wide spread adoption except by product vendors
In addition to this Windows Workflow Manager is now being used by a lot of these products internally hot the hosting of Workflow and this is also something that you can use yourself to solve the problem of the Enterprise Host if you want to run Workflow for your self.
WF itself doesn’t need have a requirement for any dependencies other than the .net framework however to build an enterprise solution using WF your likely to need to combine it with other products to get all of the features you need. If your using WF indirectly within another product then this is likely to have been taken care of for you, but if your self hosting then Workflow Manager and SQL Server are two things you will probably need.
WF itself is free and part of the core .net framework. However be aware of the dependencies section above which may mean to deliver a WF based solution you need other supporting technologies which may have a cost associated with them.
Similar & Related Technologies
The following technologies have a relationship or similarity to WF:
Microsoft Flow & Logic Apps
The core use cases for each product are:
- Microsoft Flow is a way for super users to create their own workflows connecting systems and automating their daily tasks.
- Logic Apps is a platform for a developer to build an enterprise ready workflow by using a designer and connecting applications
- WF would be used by a developer to write a workflow in code with some designer support
The big difference is that Logic Apps and Flow come with a hosting environment and runtime platform for the workflows to execute on. With WF you would need to get or build a host.
WF and Flow have overlaps in that they could be used to create a workflow, but their use cases are very different.
Really a more likely comparison is that WF would be comparable to the underlying framework that Logic Apps and Flow use to implement their workflows. A bit like comparing a finished car with a car chassis.
BizTalk offers a feature called orchestration based on the XLANG framework in BizTalk. This is a more constrained workflow framework which is specific to BizTalk Server and is specific around working with the BizTalk message box. From an integration architects perspective there can be some confusion between the overlap of WF and BizTalk Orchestration. The key difference is that BizTalk provides a whole bunch of other features for integration solutions and using a BizTalk orchestration within that context is fine. WF offers a more open workflow framework which can be used for any kind of workflow scenario not just for integration, but WF does not have the other features which BizTalk offers which integration needs.
The BizTalk XLANG workflows are ideal for implementing complex EAI patterns where you need to do the common nasty work to integrate with line of business applications.
I think creating Service Based solutions where a business workflow was hosted in WF and could be called by BizTalk when it is making the transition from an EAI piece of work to a service based piece of work would be a good way to combine the use of these two products.
Windows Server AppFabric
AppFabric contains a WF hosting feature. This was used by some customers but has been superseeded by Workflow Manager. If you are starting a new project today with WF then Workflow Manager should be the place to look for self hosting options rather than AppFabric.
Windows Workflow Manager
Workflow Manager is now the recommended host if you want to host WF yourself and provides a lot of the features you may need which will save you custom development.
WCF is used along side WF for calling out to external systems from a workflow or to expose a workflow as a service
I believe that WF is a technology that is pretty niche today. Some vendors (inc Microsoft) have used this under the hood in their products with plenty of success but there is a strong trend of those who have used WF in this manner to be looking to move away from WF to things like Flow and Logic Apps today. We can see examples of this in Dynamics and SharePoint.
I think for an enterprise company WF is there are some that have implemented their own solutions using WF but not a huge number.
I would also say at this stage WF is tied to the lifecycle of .net Framework. You are fine for quite a long time in terms of support for .net Framework including WF but some organisations will be migrating some services to .net core. Its not clear if .net core will include WF at this stage
Microsoft has decided not to convert WF to be part of .net core and has instead released it as a community supported open source project. (https://github.com/UiPath-Open/corewf)
Based on this farming off of the project it is not something I would look to invest in for new projects and would be looking to move my risk away from existing investments in WF.
The future for WF style implementations would seem to fit more likely with Logic Apps, Power Automate and Durable Functions depending on the type of use case you have.