For workflow capabilities, the Microsoft Office system depends on Windows Workflow Foundation, which officially is a part of the Microsoft .NET Framework 3.0 (previously known as WinFX). This also means that the new workflow features in Office SharePoint Server 2007 are possible because of this new technology that facilitates the creation of workflows.
WinFX is the code name for the .NET Framework 3.0 and builds on the previous release. The .NET Framework 3.0 adds four new components: Windows Workflow Foundation, Windows Presentation Foundation, Windows Communication Foundation, and Windows CardSpace. Currently, these four components are built on top of the .NET Framework 2.0.
Windows Communication Foundation is a component that supports building applications based on Service Oriented Architecture (SOA) and includes functionality such as Web services, remoting, enterprise services, queueing technologies, and Web Service Enhancements (WSE).
The Windows Presentation Foundation component of .NET 3.0 helps to create coherent user interfaces. Windows Presentation Foundation revolutionizes the development of user interfaces for Windows-based platforms by offering support for video, animation, two-and three-dimensional graphics, and various kinds of documents.
The final new component in the .NET Framework 3.0 is Windows CardSpace. Windows CardSpace offers a new approach to managing digital identities. To help people keep track of their digital identities, CardSpace represents each identity as a distinct information card that makes managing identities and passwords easier.
Windows Workflow Foundation is not a standalone application, as it always needs to be hosted by another application. The Microsoft Office system workflows use the Windows Workflow Foundation engine that is embedded inside SharePoint Server 2007 that acts as the workflow host. SharePoint Server 2007 does not use the set of pluggable services that is already included in the Windows Workflow Foundation engine, but it provides its own implementations of services for transactions, persistence, notifications, roles, tracking, and messaging.
SharePoint Designer 2007 is the most important tool when it comes to creating SharePoint workflows, as it makes creating workflows-whether they be simple, average, or complex-an appealing job. The Microsoft Office system client applications, such as Word 2007, start workflows by calling into the SharePoint Web services application programming interface (API).
Windows Workflow Foundation technology is an important part of the Microsoft strategy regarding workflow creation. Windows Workflow Foundation is the premier tool for creating workflows in Visual Studio 2005, so it is likely that third-party products will start to include this technology. Windows Workflow Foundation is embedded in all the Microsoft Office server products-such as SharePoint Portal Server, Project Server, Navision, and CRM. Other Microsoft products will use Windows Workflow Foundation as well. Microsoft BizTalk Server vNext (the one after BizTalk Server 2006) will also include Windows Workflow Foundation.
A workflow is executed on a SharePoint server, which in turn uses Windows Workflow Foundation as the foundation of the execution of a workflow process. SharePoint Server 2007 includes support for workflows in lists, libraries, and content types, and it provides queuing and management of lists and libraries to provide the necessary data to the Workflow Foundation runtime as demanded by the workflow's configuration.
SharePoint Server 2007 runs the workflow until it reaches a point at which it cannot proceed until a specific event occurs or the workflow ends. This leads to the persistence of such an activity to the database in a single SQL transaction. After that, the activity is discarded from memory. For example, a workflow process might halt until a document is approved.
If a workflow is not currently processing any activities, it can get into an idle state, which leads to the hydration of a workflow. As a result, the workflow is discarded from memory and persisted to a database. If a new event occurs that is targeted toward a hydrated workflow, the event handler extracts the workflow ID from the event and passes it into the SharePoint Server 2007 queue manager, which ensures that the correct workflow is started. In other words, SharePoint dehydrates the workflow as needed.
The context of workflow events is persisted to tables in the database. The two SQL Server database tables that are most important when it comes to storing information concerning workflows are Content DB. Workflow and ContentDB.WorkflowAssociation.
You should not create any application that programmatically accesses Content DB.Workflow and ContentDB. WorkflowAssociation directly. Microsoft does not support this, and using these tables in this way can cause severe performance problems. You cannot predict what load you will cause on the system when running this type of application. Instead, use the SharePoint Web services API and the SharePoint object model to accomplish tasks related to workflows.
Once workflow event information is stored in the database, it sits there waiting for an active thread of the SharePoint queue manager that is able to pick up the information and process it. Because of this, it is possible to start a workflow on a given Web front-end and continue to work on the workflow on another Web front-end.
If multiple workflow items are queued for processing by the Workflow Foundation runtime, one item per operating thread is processed until all items are done. If the SharePoint server runs out of bandwidth, the SharePoint Timer Service (also known as the Windows SharePoint Services Timer, or SPTimer) is used to queue items. The SharePoint Timer Service is a Windows service that handles scheduled jobs. For example, not only is the SharePoint Timer Services responsible for queueing workflow items, it is also responsible for handling workflow Delay activities. Delay activities are parts of a workflow that allow you to build delays in a workflow based on a time-out interval.
Workflow items are always processed by hydrated workflows. The decision to hydrate or dehydrate a workflow is made by SharePoint. Currently, it is not possible to influence this decision process and influence settings regarding queueing, load balancing, and time-based execution.
Workflows designed with SharePoint Designer 2007 do not contain custom code and are not compiled and deployed as assemblies are. Rather, they are stored in the form of source files within Windows SharePoint Services and compiled into memory only when needed. For each SharePoint site, workflows of this type are stored in a separate document library. This document library contains a folder for each workflow designed in SharePoint Designer 2007. The folder contains all the source files necessary for the workflow, including the following ones:
The workflow markup file, which contains markup that describes the activities included in the workflow. Workflow markup files have the .xoml file extension.
The workflow rules file, which contains the business logic of the workflow in the form of declarative rules (instead of code). Workflow rules files have the .xoml.rules file extension.
The workflow configuration file, which contains general workflow configuration information. Such files have the .xoml.wfconfig.xml file extension.
ASP.NET Web Forms for any custom workflow forms necessary. Web Forms have the .aspx file extension.
As you can see in Figure 28-1, SharePoint Designer 2007 shows you all source files that are part of a workflow in the Folder List task pane.
Figure 28-1: Source files of a workflow
Workflows are expressed in .xoml files containing workflow markup language. The .xoml file extension, shown in Figure 28-1, stands for eXtensible Object Markup Language (XOML) and is a serialization format for the Windows Workflow Foundation workflow objects. The schema for .xoml files is identical to the schema that is used for .xaml (eXtensible Application Markup Language) files. The only difference lies in the names of the file extensions.
The .xaml (pronounced "zammel") extension is the user interface markup language for Windows Presentation Foundation.
In principle, .xoml files can be created using any text or XML editor you choose, as long as such files adhere to the XOML schema. Nevertheless, it is advisable to use either SharePoint Designer 2007 or Visual Studio 2005 Designer because those products have built-in support for creating workflows.
SharePoint Designer 2007 contains a just-in-time compiler that is able to compile the workflow source files into a workflow the first time that workflow is started. SharePoint Designer 2007 keeps the compiled workflow in memory to speed up future execution performance. Each time a workflow is started on a list or library item, SharePoint Designer 2007 needs to determine whether the workflow was deployed as an assembly or in the form of a collection of source files. The decision process contains the following steps:
If a workflow assembly exists, SharePoint Designer 2007 calls that assembly to instantiate the workflow instance.
If the workflow was deployed as a collection of source files, SharePoint Designer 2007 has to determine whether it already has a workflow loaded in memory that was compiled based on those source files.
If the workflow was previously compiled, SharePoint Designer 2007 calls the in-memory compiled workflow to instantiate the workflow instance.
If the workflow was not compiled earlier, SharePoint Designer 2007 uses its just-in-time compiler to compile source files into an in-memory workflow, which then will be called to instantiate the workflow instance.
What choices do you have when it comes to implementing workflows? In SharePoint Portal Server 2003, sophisticated workflows were often implemented using third-party products. With the advent of strong support for workflow technology in SharePoint Server 2007, those third-party vendors will probably become less important in the near future. If you want to, you can also create your own workflows using the SharePoint event model.
For Windows and ASP.NET applications, developers can use the User Interface Process Application Block (UIPAB), which can be downloaded for free from http://www.microsoft.com/downloads/details.aspx?familyid=&displaylang=en on the Microsoft Web site as a component that can be used in developing workflows.
Microsoft Exchange Server 2000 and 2003 and SharePoint Portal Server 2001 included a workflow engine that could be used to create workflows of medium complexity. (This workflow engine was a part of SharePoint Portal Server 2001 and was not supported officially.)
BizTalk Server 2006 includes Human Workflow Services (HWS), a technology intended to aid in creating human-oriented workflows, although Human Workflow Services is now considered to be deprecated technology. BizTalk Server includes a Windows SharePoint Services adapter that is able to communicate with SharePoint lists and libraries and can be used to build workflows, although this requires a considerable amount of work.
Currently, if you are building workflows using Microsoft technology, not just for SharePoint technology, the most appealing options are Windows Workflow Foundation and BizTalk Server 2006. Use Windows Workflow Foundation when you are creating workflows within an application (human-oriented workflows), and use BizTalk Server 2006 for creating workflows across applications (application-oriented workflows). Both products are suitable choices because they speed up the development time for creating workflows considerably and have a bright future.