Technology Basics of Workflow and SharePoint Products and Technologies
Updated: February 26, 2009
Applies To: Office SharePoint Server 2007
Topic Last Modified: 2009-02-19
Understanding Microsoft’s support for human workflow requires a basic grasp of the two fundamental technologies that underlie this support: Windows Workflow Foundation and Windows SharePoint Services. This section briefly describes each one.
It’s common for software to implement some kind of process, with multiple steps performed one after another in a defined order. Given how often this approach is used, why not provide explicit support for creating this kind of application? The goal of Windows Workflow Foundation is to do exactly this. An application built with Workflow Foundation consists of one or more workflows, each of which contains some number of activities. A workflow’s activities are executed one at a time by Workflow Foundation’s runtime engine, with the execution order determined by the workflow itself. By providing direct support for process-oriented applications, Workflow Foundation can make those applications easier to create and maintain.
The following figure shows Workflow Foundation’s main components. A workflow, built from activities, executes using the runtime engine. This execution depends on a set of runtime services, provided by Workflow Foundation, that allow persisting a workflow’s state, tracking its execution, and more. All of this runs inside some host, which can be any Windows process ranging from a simple desktop application to a scalable server. And to accommodate different requirements imposed by different hosts and different kinds of applications, the Workflow Foundation runtime services can be replaced if necessary.
As the figure indicates, workflows can be created using Workflow Foundation Workflow Designer. This tool runs inside Visual Studio 2005, and it provides a graphical environment for organizing activities into workflows. An activity is just a class, so it’s also possible to create workflows purely in code—using a graphical tool isn’t required. Although a workflow can use any activities a developer chooses, Workflow Foundation provides a Base Activity Library (BAL). The BAL includes a number of fundamental activities, including the following:
IfElse: executes the activities contained in two or more possible paths based on whether a condition is met.
While: repeatedly executes one or more activities as long as a condition is true.
Sequence: executes a group of activities one at a time in a defined order.
Parallel: executes two or more groups of activities in parallel.
Code: executes a defined chunk of code.
Listen: waits for one of a set of events, then executes one or more activities when that event is received.
InvokeWebService: calls a Web service.
Policy: allows defining and executing business rules using a Workflow Foundation-supplied rules engine.
Workflow Foundation provides two types of built-in workflows:
Sequential workflows, which execute activities in a defined order. A sequential workflow can contain IfElse, While, and any other activities.
State machine workflows, which implement a traditional finite state machine. This type of workflow can also contain IfElse, While, and other activities, but it depends on other activities such as State to represent states and transitions.
It’s important to understand that Workflow Foundation isn’t itself a complete workflow application. Instead, it provides a foundation for developers to create workflow-based software. And because it can be hosted in any Windows process, Workflow Foundation can be combined with other technologies to provide workflow services. Windows SharePoint Services 3.0 does exactly this, and so the next step in understanding Microsoft’s support for human workflow is to understand the basics of this technology.
Sharing information is a fundamental part of modern life. Whether in our jobs, as part of a volunteer organization, or in some other way, we frequently need to share documents and other information with a group of people. Windows SharePoint Services, a standard part of Windows Server 2003, can make this sharing easier.
As the figure below illustrates, users of Windows SharePoint Services can create sites, each of which contains document libraries and lists. The information in each site, including documents and list items, is stored in SQL Server. Using Internet Information Services (IIS), people can interact with sites from Microsoft Office applications or a Web browser such as Internet Explorer. Users can also customize the browser interface using Web Parts, allowing each user to create an interface that works well for her.
Version 3.0 of Windows SharePoint Services also adds support for content types. A content type provides a schema that defines a document or list item. By default, every document in a given library has the same schema, as does every item in a particular list. Attaching a content type to a document or list item allows specifying the schema of that document or item independently from the other elements of the library or list it belongs to. Policies can also be attached to content types, specifying things such as how long a document should be retained. These polices will then be applied to any document or item to which that policy is attached.
It’s possible for multiple machines running Windows SharePoint Services to access a single SQL Server database or a group of databases with sites partitioned across them. This improves scalability, allowing access to the same sites by a large number of users. It’s also worth pointing out that although they’re logically separate and appear to users differently, documents and items are actually quite similar under the covers: both are just entries in SQL Server tables. There are some differences—documents can be checked in and out, for example, while items cannot—but the distinction between the two has more to do with how a user sees them than with how they’re implemented.
Windows SharePoint Services also relies on other standard Windows technologies. It can use Active Directory to identify users, for example, and its user interface, including Web Parts, is built on ASP.NET. Both because it’s a standard part of Windows and because it addresses a common set of problems, Windows SharePoint Services has become a very popular technology. It’s used by many organizations for sharing many different kinds of information. Until Windows SharePoint Services 3.0, however, there was no built-in support for creating workflows. How Version 3.0 makes this possible is described next.
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable content for Office SharePoint Server 2007.