Compartir a través de

Chapter 14: Designing Workflow Components

  • Artículo

For more details of the topics covered in this guide, see Contents of the Guide.

Contents

  • Overview
  • Step 1 — Identify the Workflow Style Using Scenarios
  • Step 2 — Choose an Authoring Mode
  • Step 3 — Determine How Rules Will be Handled
  • Step 4 — Choose a Workflow Solution
  • Step 5 — Design Business Components to Support Workflow
  • Additional Resources

Overview

There are many scenarios where a user's tasks must be completed in an ordered way based on the completion of specific steps, or to satisfy a set of underlying business rules. Workflow components can be used to encapsulate the tasks and to coordinate the steps required to complete them. Workflow components can also support tasks that are dependent on the information being processed, such as the data entered by the user or by dynamic business rules that define a business process.

This chapter examines different scenarios and provides guidance on how to design workflow components. It starts with a look at how real world scenarios map to key workflow scenarios to help you to identify the appropriate workflow style for your application. Next, it examines how requirements and rules affect the options you have for implementing workflow components. The final step provides guidance on designing workflow components to support the different options that are available.

For general component design considerations, and more information on the components commonly found in the layers of an application, see Chapter 10 "Component Guidelines."

Step 1 — Identify the Workflow Style Using Scenarios

There are three basic types of workflow style: sequential, state machine, and data driven. With sequential workflow, a task moves through a specific set of steps until it is completed. With a state machine workflow, activities are defined as a set of states and events that cause transitions from one state to another. With data driven workflow, activities are executed based on information associated with data. As a result, the first step in designing workflow components is to understand the style of workflow you must support. The following list provides guidance on when to use each of the three basic workflow styles:

  • Sequential workflow style. In this style, the workflow controls the sequence of activities and decides which of the steps will execute next. Although a sequential workflow can include conditional branching and looping, the path it follows is predictable. Consider sequential workflows if you must execute a series of predefined steps to accomplish a certain task; or for scenarios such as systems management, business to business orchestration, and business rule processing.
  • State machine workflow style. In this style, the workflow acquires a given state and waits for events to occur before moving into another state. Consider the state-machine style if you require workflows designed for event driven scenarios, user interface page flows such as a wizard interface, or order processing systems where the steps and processes applied depend on data within the order.
  • Data driven workflow style. In this style, information in the document determines which activities the workflow will execute. It is appropriate for tasks such as a document approval process.

Step 2 — Choose an Authoring Mode

You can use code, markup languages, or a combination of both code and markup to author workflows. The approach you take depends on the authoring mode requirements for your solution. The authoring mode you choose will also influence how you will package and distribute the application. The choices available are the following:

  • Code-only. Choose this option if the workflow will not change much over time, if you have complex business rules that cannot be easily expressed using markup, if your development team is more familiar with authoring managed code rather than creating markup using a visual designer, or if you want to create new workflow types that are not possible using the markup option. Code-only workflows are also easy to integrate into your source code control system.
  • Code-separation. Choose this option if you have complex business rules that are encapsulated by business components, or you want to provide users or administrators with the ability to modify some aspects of the workflows using workflow designers.
  • Markup. Choose this option if the workflow will change more frequently over time, if your business rules associated with the workflow can be easily expressed using markup languages, you do not need to create new workflow types, and you need the flexibility to update the workflow model without rebuilding the workflow types referenced by the model.

Step 3 — Determine How Rules Will Be Handled

At this point, you should have identified the workflow style and determined an authoring mode for creating workflows. The next step is to determine how your workflow will handle the business rules. The option you choose is based on the complexity, durability, and management requirements associated with the business rules. Consider the following factors for handling business rules in workflow components:

  • If rules are complex, you should consider a code-only or code-separation authoring mode. Business components can be used to implement and encapsulate the rules, allowing the workflow to coordinate their execution.
  • If rules are not durable, you should consider a markup authoring mode for simple or data-driven rules. However, if the rules are managed by an external system such as a business rules engine, consider a code-only or code-separation authoring mode.
  • If business users, administrators, or analysts will manage rules, you should consider a solution that uses a markup authoring mode that provides a visual designer or other rule editing facility, or supports a Domain Specific Language (DSL). However, if the rules are managed by an external system such as a business rules engine, consider a code-separation authoring mode.

Step 4 — Choose a Workflow Solution

Now that you have an understanding of the workflow style, authoring mode, and rule handling requirements for your workflow, the next step is to choose a workflow solution. The choice you make is based on capabilities that each solution provides. The following technologies are available on the Microsoft platform:

  • Windows Workflow Foundation (WF). WF provides a developer centric solution for creating sequential, state-machine, and data driven workflows. It supports code-only, code-separation, and markup authoring modes. Designer support is available through Visual Studio 2005 with extensions and directly in Visual Studio 2008 and higher. WF includes protocol facilities for secure, reliable, transacted data exchange, activity tracking, a broad choice of transport and encoding options, and provides support for long running workflows that can persist across system shutdowns and restarts.
  • Workflow Services. Workflow Services provides integration between Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) to provide WCF-based services for workflow. Starting with Microsoft .NET Framework 3.5, WCF has been extended to provide support for workflows exposed as services and the ability to call services from within workflows. In addition, Microsoft Visual Studio 2008 includes new templates and tools that support workflow services.
  • Microsoft Office SharePoint Services (MOSS). MOSS is a content management and collaboration platform that provides workflow support based on WF. MOSS provides a solution for human workflow and collaboration in the context of a Microsoft Office SharePoint® server. You can define approval-based workflows related to SharePoint list items using the Web interface, and define conditional and data driven workflows using the SharePoint designer or the Windows Workflow Designer in Visual Studio. For workflow customization, you can use the WF object model within Visual Studio. However, MOSS is suitable only if your business layer is confined to a single SharePoint site and does not require access to information in other sites.
  • BizTalk Server. BizTalk supports sequential, state-machine, and data driven workflows; and code-separation, and markup authoring modes. It enables electronic document exchange relationships between companies using Electronic Data Interchange (EDI) and/or XML formats; and contains powerful orchestration capabilities for designing and executing long running, loosely coupled business processes and workflows with reliable store and forward messaging capabilities. BizTalk integrates with heterogeneous applications and systems through adapters, and provides a business rules engine and Business Activity Monitoring. If you must interact with non-Microsoft systems, perform EDI operations, or implement Enterprise Service Bus (ESB) patterns, consider using the ESB Toolkit for BizTalk Server.

Step 5 — Design Business Components to Support Workflow

In general, you should implement workflows that involve a multistep or long running process within separate components, and ensure that you handle all fault conditions within the workflows by exposing suitable exceptions. When designing business workflows, you must consider method invocations that require no reply, or have long response times. If the component must execute a specified set of steps sequentially and synchronously, consider using the pipeline pattern. Alternatively, if the process steps can be executed asynchronously in any order, consider using the event pattern.

Use the following sections to understand how you design workflows using the technologies available on the Microsoft platform.

Windows Workflow Foundation

The business components you might design to use Windows Workflow Foundation (WF) include custom workflow, activity, and state objects; as well as custom services. The components you require depend on the workflow style and authoring mode. The following list describes the process for creating the three basic types of workflows, custom services, and workflow markup using WF:

  • When designing sequential workflows, you define or use existing Activity classes (code-only and code-separation), define custom workflow classes (code-only), and define business process components that interact with workflow components (code-only).
  • When designing state machine workflows, you define state classes used to represent different states of the process (code-only and code-separation), define or use existing events that trigger state changes (code-only and code-separation), define or use existing Activity classes that manage state transitions (code-only and code-separation), define custom workflow classes (code-only), and define business process components that interact with workflow components (code-only).
  • When designing data driven workflows, you define or use existing Activity classes (code-only and code-separation), define or use existing Condition classes to interact with data providers (code-only and code-separation), define custom workflow classes (code-only), and define business process components that interact with workflow components (code-only).
  • When designing custom services, you define or use existing Activity classes to interact with the service, define a service interface that supports the required operations, design the service using proven practices, and choose the appropriate host for your service (IIS, Workflow Appliance Software (WAS), or WorkflowServiceHost).
  • When designing workflow markup, you can use the Visual Studio designer (available as an extension to Visual Studio 2005 and included in Visual Studio 2008 and higher) or the SharePoint Designer to build workflows based on SharePoint lists. Alternatively, you can use a third party designer to create markup associated with the third party product, or hand-code the markup using appropriate XAML syntax.

BizTalk Server

BizTalk can support either a code-separation or a markup authoring mode. With BizTalk, you may need to design workflow components that are used within a BizTalk orchestration. Examples of workflow components include adapters and connectors. You may also need to create services that provide operations required by the workflow, or design business components that handle requests from BizTalk workflows.

You can also use BizTalk without writing custom components, which represents a markup authoring mode. In other words, if only simple operations are required, you can take advantage of the message transformation and function definition features of BizTalk Server. The following list describes the process for creating workflows using BizTalk:

  • When designing workflow components for BizTalk, you define a class that implements the appropriate interface and then register the class with COM.
  • When designing business components for BizTalk, you define classes that support the required operations. You can initiate atomic transactions within business components that are called by an orchestration if required, and you should design the business layer to support the required operations using proven practices.
  • When designing custom services, you define or use existing BizTalk classes to interact with the service, define a service interface that supports required operations, design the service using proven practices, and choose the appropriate host for your service (IIS or WAS).

Figure 1 shows how all of these components can work together to support a BizTalk workflow.

Ee658122.cf4fa74f-74e7-4963-9ae3-edcf11942c7c(en-us,PandP.10).png

Figure 1

Components working together to support a BizTalk workflow.

BizTalk with ESB

The Microsoft Enterprise Service Bus (ESB) Toolkit extends BizTalk with capabilities focused on building connected, service oriented applications. The ESB Toolkit consists of components that support and implement a messaging environment, making it easier to build message-based enterprise applications. Components provided by the toolkit include:

  • ESB Web Services. These provide key Microsoft ESB Toolkit capabilities. The services provided include the following:
    • Itinerary on-ramp Web services that accept external messages and submits them for processing.
    • Resolver Web service that allows external applications to call the Resolver Framework to look up ESB endpoints based on resolution mechanisms supported by the Resolver Framework, such as business rules policies, UDDI registrations, static invocation, WS-MetadataExchange interface, and the content of the message.
    • Transformation Web service that provides features to transform message content and fulfill business requirements. Transformations can take place directly on an incoming message or on messages retrieved from the BizTalk MessageBox database.
    • Exception Handling Web service that accepts exception messages from external sources and publishes them to the ESB Exception Management Framework. From there, the fault processor pipeline will normalize, track, and publish the exception message to the ESB Management Portal.
    • UDDI Web service that allows applications and users to look up endpoints based on the service name, business provider, or business category; it also allows applications and users to manipulate the business providers, services, and categories stored in a UDDI repository.
    • BizTalk Operations Web service that exposes information about BizTalk hosts, orchestration, applications, and status.
  • ESB Management Portal. This provides features such as exception and fault tracking, message resubmission, alerts and notifications, UDDI integration, reporting and analytics, and configuration capabilities.
  • ESB Pipeline Interop Components. These include Java Messaging Service (JMS) and namespace components for use in BizTalk pipelines.
  • Exception Management Framework. This can capture exceptions from both BizTalk messaging and orchestration subsystems and generate fault messages.
  • ESB Resolver and Adapter Provider Framework. This implements a pluggable and configurable architecture for dynamically resolving endpoints and transform requirements, and for routing messages.
  • Itinerary Processing. This mechanism provides a lightweight capability for dynamically describing, submitting, and executing multiple service invocations or routing/transformation requests.
  • ESB Sample Applications. These demonstrate usage of the Microsoft ESB Toolkit, demonstrating how you can take advantage of the features it provides in your own SOA and ESB applications.

Using Windows Workflow Foundation and BizTalk Together

There are many cases where Windows Workflow Foundation (WF) or BizTalk may not individually provide full support for the workflows you must implement. When faced with this situation you can often take advantage of the appropriate features from both workflow solutions within the same application. Consider using WF and BizTalk together when you want to implement business rule workflow using WF components in a code-only authoring mode that interacts with the BizTalk rules engine, when you have existing WF workflows that must be invoked from a BizTalk orchestration, when you are writing a SharePoint workflow that must execute a BizTalk orchestration, or when a WF workflow must integrate with heterogeneous or legacy systems.

Additional Resources

For more information on workflow technologies, see the following resources: