Share via

BizTalk Server 2006 or WF? Choosing the Right Workflow Tool for Your Project

  • Article

Kent Brown

twentysix New York (www.26ny.com)

November 2007

Revised February 2008

Applies to:

   Microsoft BizTalk Server 2006

   Windows Workflow Foundation

Summary: This article will provide guidance for choosing between Microsoft BizTalk Server 2006 and Windows Workflow Foundation in a variety of Application and Enterprise Integration workflow scenarios. (16 printed pages)

Contents

Introduction

Process for Choosing the Right Workflow Tool

Common Workflow Scenarios

It's All in the Host

Workflow-Technology Recommendations

Future-Proofing

Conclusion

Addendum

Acknowledgments

More Information

Introduction

Workflow is pervasive in everyday business processes, so that a common need is finding programming tools that directly support building workflow solutions. Microsoft BizTalk Server 2006 and Windows Workflow Foundation (WF) are the two primary tools from Microsoft for programming workflow solutions. However, because of the apparent overlap between them, many architects and developers have difficulty deciding which workflow technology makes sense for their purposes.

This is especially true given the fact that WF has been clearly identified as the preferred workflow technology going forward, while BizTalk Server 2006 is still the premium server product for enterprise integration. Until BizTalk Server orchestration fully supports WF, architects and developers have to choose carefully in which technology to invest.

One of the challenges in choosing the right technology for implementing workflow is that workflow can mean many things—among them:

  • Flow of UI screens with which a user interacts to complete a task.
  • Flow of business logic within an application or service.
  • Interaction of several human beings to complete a business process.
  • Coordination of multiple message exchanges between systems to process a business transaction.
  • Coordination of steps for extracting, transforming, and loading (ETL) data into a database.

While the spectrum of workflow scenarios is wide, it is helpful to group them into four broad categories: Human Workflow, Application Workflow, Enterprise Integration Workflow, and Data Integration Workflow.

Of the four major workflow categories, Application Workflow and Enterprise Integration Workflow are the two areas in which people find it most difficult to choose a technology. The Human Workflow and Data Integration Workflow scenarios are fairly straightforward, from a tools-selection perspective. Human workflow requires a user interface and is often document-centric, so that Microsoft Office SharePoint Server 2007 is the recommended platform for building Human Workflow solutions. Microsoft SQL Server Integration Services (SSIS) is the recommended tool for Data Integration scenarios.

This article will provide guidance for choosing between BizTalk Server 2006 and WF in Application Workflow and Enterprise Integration Workflow scenarios.

The BizTalk Server Orchestration Engine

The BizTalk Server orchestration engine has always been one of the compelling features of BizTalk Server. When it was introduced, it was the best tool that was available from Microsoft for performing workflow-centric programming. BizTalk Server orchestration provides a visual programming environment for developing components to control complex, multistep message flows to complete a particular business transaction.

The BizTalk Server orchestration code artifacts closely resemble the flowchart or Unified Modeling Language (UML) activity diagrams that a business analyst might produce to document a business process. These artifacts then can be compiled and executed in the orchestration-engine runtime, which provides services such as long-running transactions and compensation, durability, fault tolerance, and disaster recovery, which are crucial for building systems that automate mission-critical business transactions.

A Workflow Foundation for the Future

While there are distinct categories of workflow scenarios, there is enough in common between the scenarios, from a programming perspective, to make it worthwhile to try to establish a common framework for workflow development. The orchestration engine in BizTalk Server is powerful, but it was never designed to be used outside of BizTalk Server; so, it is not possible to repurpose BizTalk Server orchestration effectively for the other workflow categories.

WF, which is released in Microsoft .NET Framework 3.0, introduces a visual, workflow-centric programming model to the .NET Framework that is designed to be general and extensible enough to be used in all workflow-related scenarios on the Windows platform going forward. The team that produced WF was able to take the best concepts of the BizTalk Server orchestration engine, consider the requirements for the broader realm of workflow scenarios, and design a framework that is flexible enough to support them all.

As evidence of the flexibility of WF, Microsoft Office SharePoint Server 2007 uses it to implement Human Workflow solutions. The intent is for third-party BPM vendors also to build their solutions on top of WF, instead of building their own proprietary workflow engines; several vendors have already done so. Individual developers also can use WF to implement custom Application Workflow in .NET Framework applications. The plan also is for a future version of BizTalk Server to implement the orchestration engine on WF for implementing Enterprise Integration Workflow solutions.

Figure 1. Using the right workflow tool: BizTalk Server 2006 vs. WF

Process for Choosing the Right Workflow Tool

Our method for providing guidance to help you decide which workflow tool fits your project will be to delineate the most common workflow scenarios, so that you can determine the scenario or combination of scenarios that best fits your project. Then, we will give specific guidance for each scenario as to which tool—BizTalk Server 2006 or WF—is the best fit, and why. In addition, we will make use of the Application Platform Infrastructure Optimization (APIO) Model—a model for rating the maturity of an organization's application platform and development capabilities—to provide organization-specific guidance in the scenarios in which either tool can be used effectively. Finally, we will look at the road map for BizTalk Server 2006 and WF, so that you can make the best decisions for future-proofing the applications that you are building today.

Common Workflow Scenarios

Even after confining our scope to the Application and Enterprise Integration categories of workflow, there is still a broad range of workflow scenarios to consider. As Figure 2 shows, on one side of the spectrum are scenarios in which WF clearly is the right choice. An example of this is workflow capability within an independent software vendor (ISV) product, where the licensing costs and deployment complexity of BizTalk Server 2006 would be prohibitive. In this scenario, as an ISV, you are in the business of making commercial software, and the extra programming effort that is required to host WF royalty-free is a reasonable investment.

Figure 2. Integration and workflow continuum

On the other side of the spectrum are Enterprise Integration solutions that are built within a corporate IT department, where clearly BizTalk Server 2006 is the right choice. In this scenario, you want to focus on producing business value, instead of investing in building the "plumbing" to make your solution scalable, reliable, and manageable; so, the licensing cost of BizTalk Server 2006 is well worth it, because of what it provides.

Most projects fall somewhere between these two ends of the spectrum. The following are some common scenarios in which the requirements dictate a workflow solution:

  • UI Page Controller—A common requirement in complex applications is to enforce UI screen navigation according to the business rules of the specific use case that is being implemented. The simplest example is a wizard that walks the user through a prescribed set of screens to accomplish a task. Often, it is a more complex graph of screen-navigation possibilities that are based on the user's actions and the state of the data.
    The Model-view-controller (MVC) pattern is the classic technique for pulling this navigational logic out of the forms themselves, so that they are simpler and more reusable across different use cases. The Controller in the MVC pattern is really a workflow, or state machine; so, it is natural to look for a workflow tool in implementing these kinds of applications.
  • Long Running Business Logic—When many steps are required to complete a business transaction, the user might have to stop in the middle of the process or wait for actions from other users or systems before continuing. The ability to pause temporarily (or "hibernate") a process and then restart it, based on external events, is central to the idea of workflow. Without a workflow engine, developers are forced to design and code manually the mechanisms for storing the state of an incomplete process and recalling that state when the process is continued. With a well-designed workflow engine, this capability is supported natively without additional work for the developers.
  • Dynamically Updateable Process Flow—While it seems possible at first to codify business processes into well-defined sequential steps, humans often must modify the flow midstream to account for real-life situations. In an expense-approval process, the manager of the employee who submitted the expense report might be the default approver. However, the manager might decide to delegate the task to a secretary (for example, because the manager is headed out to play golf) or escalate the approval to a superior (for example, because the manager is unsure of the policy for a particular expense). Allowing the user to update the flow is often simpler than trying to anticipate every possible permutation of the flow ahead of time.
  • Abstraction of Rules from Business Logic—In this scenario, your goal is to separate the business rules from other business logic. A good example is form-validation rules. In a Mortgage Application program, the Loan Application form might have one set of field-validation rules before the user can press the Submit button to submit a loan application. If the same form is used by the loan officer to review and approve the loan, additional validation rules are required, because it is at a different stage in the process.
    Implementing the validation rules separately from the form makes it easier for the form to be reused in different scenarios and to enforce the appropriate validation rules simply by evaluating the appropriate set of rules for that scenario.
  • Web Service Aggregator—Applications often must aggregate data from several different Web services. In many situations, the aggregation logic itself can and should be extracted from the application, and exposed as a service in its own right that can be reused from other applications. These services often are called composite Web services, and they are an important element of a mature service-oriented architecture. The Web Service Aggregator scenario usually is synchronous and short-running.
  • Long Running Business Process—The Long Running Business Process scenario is used in this article to designate server-based processes that integrate multiple applications together, whereas business logic is used for logic within a single application. The requirements for these server-based Long Running Business Processes for multithreading, asynchronous behavior, persistence of process state, correlation of messages to process instances, scalability, reliability, transactional integrity, and so forth, are much higher than for business logic within an application.
  • Business to Business (B2B) Process—The B2B Process scenario is essentially the same as the Long Running Business Process scenario, except that the former is between organizations in addition to internal applications. The security requirements, therefore, are paramount. In addition, you have even less control over the specific data format and transport protocol, as these might be dictated by your business partner; so, you need the ability to support a broad range of formats and protocols and support configuration of the specific interchanges for a large number of partners.
  • Abstraction of Rules from Business Process—Similarly to the Abstraction of Rules from Business Logic scenario, this scenario applies when you want to separate the business rules from the main code in the Long Running Business Process scenario and the B2B Process scenario. This scenario requires a higher level of performance and scalability. Also, it likely will require tools to allow nonprogrammers to view and edit the rules.
  • Enterprise Rule Repository—In this scenario, the goal is to build a central shared-rules repository that can be invoked from all applications in the enterprise. This provides consistency across all applications in an organization for applying important business rules. Similarly to the Abstraction of Rules from Business Process scenario, this scenario requires high scalability and tools to allow nonprogrammers to view and edit the rules. In addition, this scenario requires that the rules repository be capable of existing as its own entity in the enterprise, with its own hosting mechanism that is separate from the workflow engine, and with components or APIs for executing the rules from various applications.
  • Enterprise Service Bus (ESB)/Message Broker—Many organizations want a standardized communication infrastructure for all services. The two most common topologies for this infrastructure are the ESB and the Message Broker. Publish/subscribe messaging and topic-base routing are commonly expected features of this infrastructure.

Application Platform Infrastructure Optimization Model

In some of the workflow scenarios, both BizTalk Server 2006 and WF satisfactorily meet the technical requirements. For these scenarios, making the right workflow-technology choice requires matching the solution to the needs of the specific organization. For the purposes of making recommendations that apply to your particular organization, we will use the Application Platform Infrastructure Optimization (APIO) model, as shown in Figure 3.

Figure 3. Application Platform Infrastructure Optimization (APIO) model

The APIO model is a technique for profiling an organization's maturity with respect to its application infrastructure, architecture, and development practices. The goal of this model is to give organizations a road map for optimizing their agility in providing IT solutions to meet the needs of the business.

The APIO model uses the following four profiles of an organization's maturity:

  • Basic—Organizations treat software as a cost. They have largely siloed applications with little integration or reuse. The applications that they do have might be on a variety of platforms. They do not have consistent standards for infrastructure or development techniques; they do not have a consistent architectural vision.
  • Standardized—Organizations still treat software as a cost, but they have taken steps to improve efficiencies. They have an architectural vision and try to consider opportunities for reuse. They have started to integrate some applications, but they are mostly point-to-point integrations.
  • Advanced—Organizations treat software as a business enabler. They have dedicated architects and a clear architectural vision. They have many services and achieve a high level of reuse. All core business processes are automated and monitored. They use a centralized, packaged integration platform.
  • Dynamic—Organizations treat software as a strategic asset. They have a very mature SOA in vision and implementation. They have clear processes for dynamically versioning and redeploying services. The can quickly adapt to business requirements changes, and can quickly integrate with new business partners.

It's Not Just Where You Are, but Where You Are Going

Somewhat implicit in the APIO model is the notion that every organization would aspire to move towards the Dynamic profile. In reality, it depends on the nature of the business and the philosophy of management regarding technology. Some businesses might be completely satisfied to stay in the Basic or Standardized profile.

You should consider the current profile, as well as the near-term and long-term goals, with the near-term goal being the most important. An organization in the Basic profile, with a desire to be in the Dynamic profile eventually, might choose wisely to focus initially on getting into the Standardized profile; so, its technology decisions should mostly be consistent with the Standardized profile.

In general, BizTalk Server 2006 is going to be a better fit in organizations that are—or have a near-term goal to be—in the Advanced or Dynamic profile. An organization in the Basic profile that is relatively satisfied in this profile might have neither the strategic motivation to adopt BizTalk Server 2006 nor the capabilities to take advantage of it effectively; so, they would not likely want to make the investment. However, if an organization in the Basic profile has made a decision to move towards the Advanced profile aggressively, adopting BizTalk Server 2006 might be a strategic step in that direction.

The point of introducing the APIO model into the discussion is that having a good idea of the current and targeted APIO profiles of the organization will aid in deciding between WF and BizTalk Server 2006, when the technical scenario could be well supported by either technology. Two different organizations might well make different choices—each making the right choice for its organizational profile.

It's All in the Host

One of the most important aspects to consider when choosing between BizTalk Server 2006 and WF is the hosting requirements for your workflows. Unlike BizTalk Server 2006, WF does not provide hosting "out-of-the-box"; you must implement a host that establishes the Windows process and starts up the workflow runtime engine in which your workflows will execute.

In order to build a framework that can support the full spectrum of workflow scenarios realistically, WF abstracts the core behaviors that an environment such as BizTalk Server 2006 provides, so that various hosts can provide the specific desired behavior for these services.

The core services that a WF workflow host provides are the following:

  • Scheduling service—Creates and manages the threads that are used by the runtime engine to execute workflow instances.
  • Commit Work Batch service—Manages the transactions that are used by the runtime engine for database operations.
  • Persistence service—Handles persistence of the workflow instance when it is directed to do so by the runtime engine. This service is optional. If it is not provided, the workflow instances will not be persisted, and they must run in-memory for their entire lifetime.
  • Tracking service—Provides ability to record tracking events within workflows. This service is optional.

What It Takes to Build a Workflow Host

Depending on your workflow scenario and the services that you must provide to your workflows, building a WF host might be trivial or prohibitive. For the scenarios in which workflow is within the context of an application, hosting WF is fairly straightforward. The application itself acts as the process host, and there are standard implementations of the core services that can be configured with minimal effort.

However, the necessary sophistication of the host jumps dramatically when you get into highly scalable, server-based scenarios. Table 1 shows a laundry list of host services that might be needed—most of which are provided in BizTalk Server 2006.

Table 1. Host services

  • Scale-out configuration
  • Load balancing
  • Fail-over
  • Throttling
  • Thread management
  • Memory management
  • Service isolation
  • Exception configuration
  • Failed-message management
  • Message tracking
  • Archiving and purging
  • Identity and impersonation
  • Multi-environment deployment model
  • Health monitoring
  • Utilization/Performance tracking
  • Composite-process state management
  • Scripting
  • Disaster recovery
  • Regulatory compliance
  • Configuration management

What Business Are You In, Anyway?

If you are tasked with building a specific application with tight deadlines, you probably don’t want your team distracted by having to build a complex host when they should be focused on implementing the necessary business logic. In this case, BizTalk Server 2006 is well worth the investment to buy—instead of attempting to build—a robust workflow host. If you are part of the central architectural team of a large corporation, you might choose to invest in building a host that could be used across the organization. Even so, this effort should not be taken on lightly.

Workflow-Technology Recommendations

For Scenarios Within an Application: WF

For all of the scenarios that are contained within an application—including UI Page Controller, Long Running Business Logic, Dynamically Updateable Process Flow, Web Service Composition, and Abstraction of Rules from Business Logic—WF is the right workflow-technology choice.

In the majority of application-centric scenarios, the usage pattern requires synchronous, low-latency interaction between the application and the workflow, which is not the strength of BizTalk Server 2006. BizTalk Server 2006 would not be a good fit for these scenarios, for performance reasons; BizTalk Server orchestrations run on dedicated BizTalk Servers, and invoking them from a client application requires a round trip across the network. In addition, the design of BizTalk Server 2006 of persisting every message to the MessageBox database for durability introduces additional latency, which might not be acceptable in the context of an interactive UI, if the workflow must be called synchronously.

WF is a better fit for these scenarios; it meets the workflow requirements, and it is simpler and cheaper than BizTalk Server 2006. The messaging capabilities of BizTalk Server 2006—for example, the Mapping and Adapters—are not needed in these scenarios. The requirements for hosting services are modest, so that hosting the WF runtime inside the application does not require a prohibitive amount of work.

For Most Business-Process Scenarios: BizTalk Server 2006

For most of the scenarios that involve server-based business processes, BizTalk Server 2006 is the right choice. These include B2B Process, Abstraction of Rules from Business Process, Enterprise Rule Repository, and Enterprise Service Bus (ESB)/Message Broker.

These scenarios require high scalability. Also, they require the ability to view running processes, and to stop and restart them. Finally, they require support for scaling out to multiple servers. In these scenarios, the advanced hosting features of BizTalk Server 2006 are required and well worth the investment.

Basic Standardized Advanced Dynamic

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Figure 4. Long Running Business Process scenario

BizTalk Server 2006 is generally going to be the best platform for the Long Running Business Process scenario. These processes tend to be asynchronous, long-running, and stateful. These processes are often mission-critical to the organization; therefore, they require high availability, visibility, security, and manageability. The Group or "Farm" topology of BizTalk Server 2006 allows you to manage an array of servers to provide scalability and redundancy.

The persistence mechanism of BizTalk Server 2006 for storing process state has robust security built in to protect the privacy of the persisted state, which might be important for regulatory reasons. The Business Activity Monitoring (BAM) of BizTalk Server 2006 provides appropriate business-level visibility into the running processes in a secure fashion. Finally, these scenarios often require support for heterogeneous message formats and transport protocols, including legacy systems.

For these reasons, BizTalk Server 2006 usually is going to be the best choice for organizations that are targeting the Standardized, Advanced and Dynamic profiles. These organizations usually consider the Long Running Business Process scenario to be very important to the business and very common within the enterprise; so, they purchase BizTalk Server 2006 specifically to establish a standardized platform for them.

However, WF might be a better choice for organizations that are in the Basic APIO profile. These organizations generally are not looking to invest in building a standardized application platform. Instead, they are looking to minimize costs, and the licensing and hardware costs of BizTalk Server 2006 might be prohibitive. The exception to this guidance is when there are requirements for high scalability, monitoring, and support for a broad variety of message formats and transport protocols. In this case, although the organization is reluctant to invest in their application platform, the cost of building the hosting and messaging features from scratch likely would exceed the costs of BizTalk Server 2006.

Basic Standardized Advanced Dynamic

WF

WF → BizTalk Server 2006

BizTalk Server 2006

BizTalk Server 2006

Figure 5. Web Service Aggregator scenario

Both BizTalk Server orchestrations and WF workflows have strong support for external-consuming Web services from a workflow, and for exposing the workflow as a Web service. Therefore, for building Web Service Aggregator solutions, just as for Long Running Business Process solutions, the choice is determined by the organizational profile and hosting requirements.

If the aggregating Web service is only to aggregate other Web services, the ability of BizTalk Server 2006 to support heterogeneous message formats and transport protocols adds little value. However, if the service also should aggregate data from legacy environments that are not exposed as Web services, BizTalk Server 2006 would add value.

Because the usage pattern is quick, synchronous request/response calls, the message durability that is provided by BizTalk Server 2006 usually is not important. In fact, the latency that is introduced by the persistence to the MessageBox actually is a liability. The main value that BizTalk Server 2006 provides for this scenario is the ability to manage the deployment across many servers and to monitor running instances. The BAM capability of BizTalk Server 2006 also might be useful for monitoring that service-level agreements (SLAs) are met.

For these reasons, WF is a very good choice for implementing Web Service Aggregators, especially in organizations in the Basic and Standardized profiles. An example in which BizTalk Server 2006 might be advantageous is one in which you must manage a large number of endpoints for different client organizations. The Receive Port and Receive Location configuration of BizTalk Server 2006 specifically handles this. In this case, certificates might be important, too, and the support of BizTalk Server 2006 for configuring and managing certificates and applying them to encryption/decryption might be useful.

Future-Proofing

You want to ensure that your investments in software licensing costs, in learning a workflow technology, and in building specific workflow components, will provide you the most possible value in the future. Besides choosing the right workflow for your specific workflow scenario and organization, you must also take into account the product road maps for BizTalk Server 2006 and WF. There is not a simple answer for this. The comments that follow do not make a strong argument for choosing either technology; instead they are data points to aid in your decision.

What BizTalk Server 2006 R2 Adds

BizTalk Server 2006 R2 adds two features that might affect your choice of workflow platform: the WCF Adapters, and the BAM interceptors for WCF and WF.

WCF Adapters

If your team has adopted Windows Communication Foundation (WCF) as the standard technology for implementing services in building your SOA, the fact that BizTalk Server 2006 did not have WCF support might have disqualified it as a platform for building and hosting composite Web services. This might have pushed you towards WF, even if BizTalk Server 2006 was otherwise a great match for your scenarios and APIO profile.

Fortunately, with the introduction of great WCF integration in BizTalk Server 2006 R2, this is no longer a concern. BizTalk Server 2006 now has strong integration with WCF, and it is an excellent platform for building composite services out of more granular services and exposing these composite services as WCF services.

BAM Interceptor for WF

The second relevant BizTalk Server 2006 R2 feature is the introduction of the BAM interceptor for WF. If business-activity monitoring is an important feature of your solution, you might have been pushed toward using BizTalk Server 2006—just to take advantage of BAM—when WF was otherwise a better fit for your scenario. With the BAM interceptor for WF, you can choose WF if it is the right workflow technology for your project and still make use of BAM as an enterprise business-activity monitoring solution.

BAM is a feature of BizTalk Server 2006 that provides a framework for capturing events and data from BizTalk Server orchestrations and message flows, and presenting that data in a portal to provide the business user with end-to-end visibility into the business process. A powerful aspect of the way in which BAM works for BizTalk Server 2006 applications is that BAM monitoring can be configured (or "instrumented") after a BizTalk Server 2006 application has been deployed, without requiring modifications to the BizTalk Server 2006 code artifacts.

BAM is designed as an enterprise-wide business-activity monitoring solution; therefore, it is possible for non–BizTalk Server 2006 applications to feed events and data into BAM. However, the APIs for doing so require quite a bit of code to be written in the external applications. The BAM WF interceptor in BizTalk Server 2006 R2 provides the capability to instrument WF workflows for BAM more simply and without requiring code modifications. By using the BAM interceptors, you can track your business processes without recompiling your WF or WCF solution; integration is done through a configuration file.

BizTalk Server 2006 Extensions for WF SDK

The BizTalk Server 2006 Extensions for WF SDK was announced and demoed at TechEd 2007. This SDK provides a simple mechanism for hosting WF workflows in BizTalk Server 2006. This tool is intended for use by .NET developers who are building WF workflows today and looking for an easy way to achieve robust, scalable hosting of those workflows.

The SDK provides two custom WF Activities—a btsReceive activity and a btsSend activity—that can be used within a WF workflow for receiving and sending messages via BizTalk Server 2006. As a developer, you define WCF DataContracts for the inbound and outbound messages, and a ServiceContract to define the message-exchange pattern. Within the WF workflow, the btsReceive and btsSend activities are configured to use the defined ServiceContract, as shown in Figure 6.

Figure 6. btsReceive and btsSend activities for use in defined ServiceContract

After the WF workflow has been completed and compiled, you right-click on the workflow project and select Generate Orchestration to generate automatically a wrapper orchestration (see Figure 7) that will initiate the WF workflow and route BizTalk Server 2006 messages both to and from it.

The auto-generated wrapper orchestration contains schemas for the messages defined in the ServiceContract. It also contains the BizTalk Server orchestration shapes and code for receiving a BizTalk Server 2006 message, creating and starting the workflow instance, passing inbound message(s) into the workflow instance, receiving the outbound message(s), and forwarding them back to the BizTalk Server 2006 messaging engine. To complete the hosting of your WF workflow, you just have to compile and deploy the wrapper orchestration, and bind it by using the normal BizTalk Server 2006 mechanism.

Figure 7. Generating a wrapper orchestration automatically

In addition to taking advantage of the robust, scalable hosting mechanism of BizTalk Server 2006 for WF workflows, the BizTalk Server 2006 Extensions for WF SDK allows you to take advantage of the BizTalk Server 2006 messaging infrastructure. Thus, you can leverage the many available Adapters for getting messages into and out of BizTalk Server 2006, as well as the pipeline processing, including the Mapping capabilities.

As powerful as it is, the BizTalk Server 2006 Extensions for WF SDK should be used as a tool to allow WF developers to deploy their workflows on top of BizTalk Server 2006—not as a replacement for orchestrations in scenarios in which we have identified BizTalk Server 2006 as the proper tool. There are some WF shapes that do not work when they are wrapped in an orchestration. This is because hosting your WF workflows inside of BizTalk Server 2006 by using the BizTalk Server 2006 Extensions for WF SDK will not provide the same hosting behavior as native orchestrations. The SDK has a FAQ list (included in the Quick Start Guide) that outlines these differences.

Conclusion

BizTalk Server 2006 and Windows Workflow Foundation are the primary tools from Microsoft for implementing workflow solutions in the Application and Enterprise Integration Workflow categories. In order to choose which is right for your project, you first must identify which of the workflow scenarios you are targeting.

Next, use the table in Figure 8 to see the recommended workflow technology for your scenario. For workflow within an application, we recommend WF. For most server-based business process and B2B scenarios, we recommend BizTalk Server 2006.

Figure 8. Scenario-specific workflow technologies

For both the Long Running Business Process and the Web Service Aggregator scenarios, either technology can be applied affectively. For these scenarios, you should assess the current and near-term target APIO profile of your organization. Organizations that are either in or moving towards the Advanced or Dynamic profiles should use BizTalk Server 2006 for these scenarios. Organizations in the Basic and Standard profiles can use WF effectively for these scenarios.

Finally, you should consider the release dates and desired lifetime of your solution, relative to the product road map for BizTalk Server 2006 and WF. By using this framework and the guidance in this article, you should be able to choose the right workflow for your project.

Addendum

Dispelling Misconceptions About BizTalk Server 2006 vs. WF

The following are some common misconceptions regarding WF and BizTalk Server 2006, and the clarifying arguments that we use to dispel them:

  • WF is the replacement for BizTalk Server 2006. No. Because WF is the "latest and greatest" offering from Microsoft for programming workflows, many who are unfamiliar with BizTalk Server 2006 initially assume that it has been made obsolete with the release of WF. The simple answer to correct this impression is that WF is a low-level developer framework for building all kinds of workflows, while BizTalk Server 2006 is a full-blown server product with advanced features for a specific category of workflow scenarios: Enterprise Integration. (See Figure 1.)
    WF provides only a small subset of this functionality: Workflow and Business Rules. While WF might be a simpler, more cost-effective solution for scenarios that do not require all of the other features that BizTalk Server 2006 provides, in no way does it supplant BizTalk Server 2006 for the core Enterprise Integration scenarios that BizTalk Server 2006 was designed to support.
  • BizTalk Server is going away. No. A similar misconception is the impression that because WF was released as the workflow tool of the future, and BizTalk Server has not yet been rewritten to use WF, Microsoft is no longer investing in BizTalk Server and will eventually replace it with a new WF-based product. This is just not the case; BizTalk Server has been a very successful product, and the Enterprise Integration area that it targets continues to be an area that Microsoft is committed to supporting.
  • You have to choose BizTalk Server 2006 over .NET Framework. No. It might be tempting for .NET developers who are not familiar with BizTalk Server 2006 to choose WF over BizTalk Server 2006, just on the basis that they would rather go "pure" .NET. However, this is really not a useful criterion; BizTalk Server 2006 itself is built on the .NET Framework.
    In fact, BizTalk Server 2006 represents over 2 million lines of .NET code that can be applied to your solution—saving you the time, trouble, and cost of developing its functionality from scratch. In addition, BizTalk Server 2006 programming itself is done inside of Microsoft Visual Studio .NET, and the components are compiled and deployed as .NET assemblies. Besides, most significant BizTalk Server 2006 projects combine BizTalk Server 2006 components with custom .NET components; so, BizTalk Server 2006 development should be considered specialized .NET development, instead of something that is foreign or different.
    The real question is whether the BizTalk Server 2006 features provide enough value for your particular workflow scenario to justify the licensing costs. You don't want to use a sledgehammer to hang pictures; neither do you want to use a carpenter's hammer for crushing large rocks.
  • The most features wins. A poor choice. We could put up a feature matrix that compares the granular features of WF to those of BizTalk Server 2006. However, this comparison would not be very helpful; BizTalk Server 2006 has such a large number of features that are targeted specifically at the Enterprise Integration space. If that is not your target scenario, the feature comparisons will be meaningless. BizTalk Server 2006 would probably win, in terms of the number of feature check boxes; however, this is an apples-to-oranges comparison, if those features do not relate to the workflow scenario that you are targeting.

Acknowledgments

I would like to thank Paul Andrew and Kris Horrocks, and everyone who reviewed this article.

More Information

About the author

Kent Brown is the director and senior architect of the Enterprise Integration Practice at twentysix New York, a Microsoft Gold Certified consulting partner in New York City. He has been excited about BizTalk Server since its inception in 2000, and has played an evangelist role around the product for the last seven years. Kent is a member of the Microsoft BizTalk Virtual Technical Specialist Team, as well as a Microsoft Connected Systems Developer MVP. He is the founder and leader of the NYC Connected Systems Users Group (http://www.NYCCSUG.org).