WF vs. BizTalk


Windows Workflow Foundation (WF) and BizTalk both provide workflow capabilities.  This brings up many questions.  Which should be used?  How does one make this determination?  Is WF a replacement of BizTalk?  I’m not the best person to answer these questions, but many, more qualified individuals, have already done so.  In Professional BizTalk Server 2006 Jefford, Smith, and Fairweather suggest using “WF for within your application and BizTalk Server for use between your applications” (616).  Former Group Product Manager for BizTalk, Scott Woodgate, also advises the use of WF for scenarios where the workflow will be used only within an application and recommends BizTalk for situations where a workflow will span multiple applications ( 

When evaluating the two, it is also important to keep in mind that, though both are centered around workflows, their intensions are fundamentally different.  WF is a foundational building block used to create systems in a way that separate processes from application code.   On the other hand, BizTalk is an enterprise-caliber platform for building service-oriented applications.  WF provides an API that developers can use and build upon while BizTalk offers a number of prebuilt components that almost all enterprise-caliber service-oriented systems need.  For instance, BizTalk provides adapters to integrate disparate systems, a durable, transactional message store, orchestration abilities, message transformation, a business rules engine (BRE), a scalable architecture, monitoring and management functionality, administrative tools, and a proven history with thousands of successful installs.  Each of BizTalk’s features that are absent in WF must be implemented by end users; even the ones that it does include (e.g., the BRE), must be tested, built upon, supported and scaled up by its users.

As posted elsewhere on the Internet, the following table further compares these two technologies:





Server-side in the BizTalk process

Hosted in a custom application (client-side execution, but the client could be an ASP.NET application)


Included in Visual Studio

Included in Visual Studio, or custom designers can be written


Well-proven, highly scalable

Developer must implement

Transactional integrity

Long running and atomic (ACID) transactions

Developer must implement

Tracking infrastructure

Comprehensive Business Activity Monitoring infrastructure provided

Simple framework pieces provided that allow you to build the tracking infrastructure

Runtime modification of "in-flight" workflows

No, workflows are defined at design time

Yes, but developer must implement

Cross-platform integration capabilities

Extensive adapters available

Not supported natively