Service Orchestration and Windows Workflow Foundation

Building and executing workflows without a traditional Enterprise Service Bus (ESB) is possible using Microsoft .NET 3.0 technologies.

• By Peter Varhol
• October 1, 2006

Web services do not exist in a vacuum. You must execute them in a given sequence, a sequence that might be different for different types of transactions. This process is called a workflow, and the management of transactions through this workflow is referred to as orchestration. While traditional monolithic applications can implement a workflow and orchestrate transactions throughout it, they lack the flexibility to upgrade, add, or swap out steps in the process.

So enterprises are breaking up these traditional applications into multiple services, or writing entirely new services. As a result, you need an external agent for orchestration and execution of the individual workflow steps in these services.

One way that you can perform this type of orchestration is with Microsoft's Windows Workflow Foundation (WWF), which is a .NET Framework 3.0 technology. WWF is an add-in to Visual Studio 2005, and lets you build workflow-oriented applications visually and with code.

Once a workflow model is compiled, you can execute it inside any Windows process, including console apps, forms-based apps, Windows Services, ASP.NET Web sites, and Web services. This provides you with the ability to set up the workflow visually within Visual Studio, write code that implements the steps of that workflow, and deliver it as a completed, services- and components-based application.

How Does WWF Work?
WWF is comprised of the programming model, engine, and tools for building workflow enabled applications on Windows. It consists of a .NET Framework 3.0 namespace, an in-process workflow engine, and designers for Visual Studio 2005. A completed workflow application requires that the computer on which it executes have the upcoming .NET Framework 3.0.

At its core, WWF implements a state machine. It enables an application to transition from one state to the next. Its Visual Studio add-in incorporates a set of workflow states and state transitions, and also a workflow menu to the menu bar. The visual elements of the workflow represent states that define what activity might occur at specific parts of the workflow.

WWF conveniently incorporates the visual design elements for building workflows and the ability to write code for the workflow within the same Visual Studio environment. Analysts can lay out the flow using the graphical modeling components, and developers can code the services and other application components that implement the workflow.

A workflow project is a console application. Web services and .NET assemblies implementing logic don't generally have a user interface that's associated with them. If a user interface is needed, it's added to individual services or components in the workflow, rather than the workflow itself.

WWF is still in beta, and expected to be released, along with Windows Vista, as a part of .NET 3.0 offering. But you have been able to download community versions for initial use since the beginning of 2006. And WWF has proved to be useful and stable, so Microsoft now offers Go Live licenses for enterprises that are looking to deploy a workflow application before the formal release of the product. However, these enterprises have to acquire Windows Vista to use in conjunction with Go Live WWF early deployment licenses if they intend to deploy a workflow application early.

Looking in Depth at a Workflow
A common business workflow might take an incoming order and check the order against inventory. If the product is available, then the workflow accepts the order, schedules the product for shipment, and bills the customer. If the product is not available, then the workflow notifies the customer and places the order on backorder status, assuming the customer approves. When the inventory arrives, the workflow matches inventory to backorder, ships the product, and bills the customer.

You can probably imagine how a person or group of people might handle this workflow. The order is taken by a sales person, who contacts the warehouse supervisor on the inventory status of the item. Depending on whether or not the order is in-stock, the sales person either places the order immediately or puts it on backorder status. Once the item is shipped from the warehouse, the accounts receivable bookkeeper receives instructions from the warehouse inventory manager to bill for the item. At least three or four people in total have touched the order before it is complete, and the paperwork is passed around among these people multiple times.

This workflow is an ideal candidate for automation, which could improve accuracy and cut overhead costs. In the past, all of these activities described in the workflow were supported by separate applications. The sales person used a Customer Relationship Management (CRM) package; the warehouse manager used an inventory management system; and the bookkeeper used an accounts receivable package. Now you can use Visual Studio to join these business applications together as services (assuming the appropriate service interfaces exist), or you can write your own code as a replacement for the existing applications.

To automate this workflow using Visual Studio, you begin by selecting a workflow console application, which provides you with a canvas and a toolbox with the graphical workflow elements. Selecting from the toolbox, you can insert elements and connections between them onto the canvas. For example, you can select visual elements, to start, conclude, and create events entirely within Visual Studio. This puts you in the unique position of both laying out the workflow and coding for it.

You start most workflows with a SequentialWorkflowActivity to enable the execution of a group of related activities in sequence. Then you can use an EventDrivenActivity, named CreateCustomer in this case, to define a customer for subsequent activities. The event for this scenario is the product order, which is submitted as a HandleExternalEvent. This external event handler calls an EventHandlingScope to check if the product is available in inventory. And, this activity sequence continues on through the process until the workflow is completed. This resulting workflow is modeled in Figure 1.

Because each of the workflow states is represented in the workflow namespace, they can also be subclassed and coded. The classes themselves are rich, so often you have to make only minor customizations to your objects for unique business logic, and don't have to worry about getting data between the steps in the workflow sequence.

The WWF toolbox also includes graphical representations for WebServiceInput, WebServiceOutput, and WebServiceFault. The first two provide the interfaces that let you pass Simple Object Access Protocol (SOAP) messages to and from an existing Web service in order to execute a step. The third lets you catch and handle a fault in external Web service execution. These graphic tools let you work with all Web services, not just those written with Microsoft technologies.

Adding Services
Unlike an ESB, WWF doesn't allow you to add certain types of enterprise services to the workflow application. For example, there are no inherent WWF facilities for security or reliable transactions.

Microsoft approaches these services from a different direction. They are collectively a part of what Microsoft is calling .NET 3.0, to be incorporated into the Windows Vista release. Specifically, they are packaged as programming interfaces to the Windows Communication Foundation (WCF); and they can be added to the code at every step in the development process, rather than incorporated as a part of the orchestration.

This might mean more work for you, but calling these programming interfaces is easy, with only two or three lines of code necessary for implementing them under normal circumstances. But once the code's been written, you, or a small team, can automate this process entirely from within Visual Studio. Granted, the code you use to implement this workflow must run from a Windows platform, but for a Microsoft shop, it still offers a natural way to adapt applications to a workflow model.

WWF is an interesting combination of high-level conceptualization and business process modeling: nuts-and-bolts service coding and execution. You can implement an application using a mix of executable code and declarative activity models, and the rules that bind them together.

By itself, WWF doesn't serve enterprise purposes, where as an ESB does, but it provides a foundation for workflow applications, including those that utilize Web services. This foundation, while also executing on Windows XP and Windows Server 2003, requires primarily Windows Vista to run well. If you already have a number of .NET applications that implement specific functions and might be joined together as part of a workflow, it is natural for you to move to WWF. Does WWF take the place of an ESB? Not entirely, but it does offer similar services, and from the perspective of the OS rather than an additional piece of expensive middleware. WWF and other .NET 3.0 technologies are going to give traditional ESBs a run for their money.