本来想翻译以下的，可是太多了，翻译下来这一天就不用干别的了，呵呵。这里主要是介绍了WF引擎的架构。分析了不同Layer的关系、功能和实现。摘自《Presenting Windows Workflow Foundation, Beta Edition》。
Windows Workflow Foundation Engine Architecture
Given the breadth of scenarios requiring workflow and the key goal of providing a singular technology layer to support all these scenarios, the workflow technology is a well-factored framework with numerous pluggable interfaces and extensibility as a core design principle. The architecture for Windows Workflow Foundation is depicted in Figure 1.1.
Figure 1.1. Windows Workflow Foundation engine architecture.
At the bottom of Figure 1.1 is the host process. Windows Workflow Foundation has no inherent execution process. Instead, Windows Workflow Foundation is an in-process engine that runs inside a host process. The host process is responsible for providing a set of services to Windows Workflow Foundation. A wide variety of host processes are available on the Windows platform including console applications, WinForms applications, web applications, web services applications, SharePoint Server, and NT Service applications. Effectively, any executable process can host the Windows Workflow Foundation runtime engine.
This also presents some interesting challenges because the capabilities of each host are often different to another host. SharePoint is a dramatically different environment than a console application. For this reason the Windows Workflow Foundation architecture hosting layer provides a set of pluggable interfaces from Windows Workflow Foundation to the host.
Sitting on top of the hosting layer in the Windows Workflow Foundation architecture is the runtime layer. The runtime layer is the core of the engine providing both workflow execution and workflow lifecycle management capabilities.
Finally, the workflow model layer is where most developers will interact with Windows Workflow Foundation. The workflow model layer includes the various workflow models, APIs, and the activities. The following sections provide more details on the hosting, runtime, and workflow model layers.
Hosting Layer
The hosting layer provides interfaces between Windows Workflow Foundation and a particular host for the following key services: Communication, Persistence, Tracking, Timer, Threading, and Transaction. The implementations of the former three services that ship with Windows Workflow Foundation are durable while the latter two services are stateless. However, none of the services are necessarily durable if you write your own. By abstracting each of these services Windows Workflow Foundation can take advantage of specific capabilities available in specific hosts. The following sections describe the functions performed by each of these services:
Persistence:xs Although some workflows may execute for a short period of time, workflow is inherently asynchronous and a particular workflow, such as the Ph.D. thesis approval process, may take many days or months. A workflow engine that retained its state in memory for that period would not scale as each instance of the workflow would consume memory for the duration and eventually the system memory would be exhausted. Instead, a persistent architecture is used where workflow is executed in memory, and should it be required, the workflow state will persist to a store while it waits for a response that might take some time such as the "Ph.D. approved" step in the workflow. Each host application has a specific set of persistence requirements. For example, to persist state, ASP.NET uses a set of Session State objects that has state client providers for in-memory persistence and SQL Server persistence. In contrast, SharePoint persists state in a SharePoint-specific set of tables in SQL Server and your console application may choose to persist state to the file system as XML. With such a large variety of host-specific persistence capabilities, it would not be sensible for a broadly applicable technology such as Windows Workflow Foundation to specify a single persistence provider. The Windows Workflow Foundation hosting layer persistence interface enables Windows Workflow Foundation to work across the full gamut of host persistence architectures.
Timer: Workflows often need to wait for an event to continue. The timer is the supplied clock that is used to manage these delays. For example, an approval workflow may delay and unload from memory until a particular approver completes the necessary approval. The timer implementation in this case might be a durable timer that survives a potential system restart while waiting for approval.
Tracking: A key reason to implement workflow is because the workflow model provides a greater degree of system transparency at runtime than amorphous code. Indeed, all workflows are automatically instrumented without any programming. The tracking instrumentation is consistent across both the event content and the tracking interface. Depending on the host, the target tracking infrastructure is often different. For example, a LOB application often persists workflow tracking information within the LOB database whereas a console application may persist tracking information to an XML file. The tracking interface receives tracking events from the Windows Workflow Foundation runtime and passes them on to the host application.
Communications: Workflows send and receive events or messages from their host. These events trigger workflows, and move the workflow to the next step in the overall flow. There are a wide variety of communications infrastructures available on the Windows platform including web services, .NET calls, loosely coupled messaging, and so on. For this reason, Windows Workflow Foundation does not provide its own proprietary communications layer. Instead, Windows Workflow Foundation provides pluggable interfaces that can be implemented for any communications layer. Of course, there are easy-to-use, prebuilt communication interfaces to and from common targets such as web services and for passing data objects in and out of a workflow—perhaps from a form.
The physical job of development of these interfaces for specific hosts is relatively challenging compared to other aspects of workflow development described shortly. For this reason, ISVs will typically build host layer providers into their host applications so that end-user developers can simply reuse these services. In addition, Windows Workflow Foundation ships prebuilt support for ASP.NET 2.0 and the interfaces shown in Table 1.1.
Table 1.1. Prebuilt Host Layer Service Implementations
___________________________________________________________________
Host Layer Service Implementation
Persistence SQL Server state persistence
Timer Both an in-memory and SQL Server–based timer
Threading .NET thread pool/ASP.NET thread pool
Tracking SQL Server Tracking Persistence and Event Log recording for termination
Communications .NET components and web services
___________________________________________________________________
Sitting on top of the hosting layer is the runtime layer.
Runtime Layer
The runtime layer is core to Windows Workflow Foundation. In direct comparison to the other layers in the architecture, the runtime layer is not pluggable as it contains the mission-critical services required for workflow. These services include the following:
Execution: The execution service schedules activities and supports common behaviors such as event handling, exceptions, tracking, and transactions.
Tracking: The tracking service creates the tracking events that are serialized through the tracking interface.
State management: The state management service manages states that may be persisted through the persistence interface.
Scheduler: The scheduler service schedules execution of activities.
Rules: The rules service provides policy execution functionality and CodeDOM condition evaluation.
Workflow Model Layer
The workflow model layer is where most application developers will spend the majority of their time writing code for Windows Workflow Foundation. This layer includes support for multiple workflow model types, activities, and the main programming APIs use by most developers.
Windows Workflow Foundation supports two models out of the box:
Sequential workflow model: This model is primarily a structured workflow where a step in the workflow leads to another step in a manner that may be determined often at design-time and can be represented in a flow diagram such as that shown in Figure 1.2.
Figure 1.2. Sequential workflow.
Sequential workflows are most often used to represent structured workflows such as system-to-system workflow. These transformational workflows are self-driven once they are initiated, have a highly predictable path through the events, and are often literally sequential in nature.
State machine workflow model: This model uses the paradigm of states and transitions between states to represent the workflow. There is no deterministic path between the steps from a design perspective because the workflow does not execute in a sequential nature. Rather, the workflow is a set of events that are handled in a highly variable order with one event completing and triggering a state that another event may itself trigger from. The state machine model can literally jump from any stage in the workflow to any other stages, and often will do so multiple times before reaching a completed state. The order workflow is a state machine where various messages are received and trigger the workflow to progress to a particular state. Each iteration of this workflow may result in a different path through the model as depicted in Figure 1.3.
Figure 1.3. State machine workflow model.
State Machine Workflows are an effective way of representing highly people-centric workflows where the workflow thread of execution is not easily represented in a flow. This workflow model is also very useful for scenarios where a high priority event must be processed even though work is already in process or when a large number of events may occur at a particular stage in the workflow. A perfect example is a stage in the order workflow where an "order cancelled," "order updated," and "order completed" event that may be received at any time and should immediately cancel the entire process.
Although Windows Workflow includes these two models, customers can inherit from them to create their own specific models or create new models.
Regardless of model and sequencing behavior the basic element of execution and reuse is called an activity. An example of an activity is "send goods" in the previous sequential workflow example.
There are two types of activities—the simple activity and the composite activities. What makes Windows Workflow Foundation very different from traditional workflow engines is that the engine has no fixed underlying language or grammar. Instead the engine chains a set of activities that are supplied by Microsoft and created by you the developer. Microsoft-supplied constructs include "If," "Code" blocks, activities for web services, and many more. In addition, you can create your own control flow activities such as "do until" but more likely you will be creating higher level activities such as the "Receive Order" activity described previously. By using an activity execution methodology rather than a language, Windows Workflow Foundation is able to support a broad range of scenarios and you can reuse your activities across multiple workflows. Indeed the flow and the state workflow models share a majority of activities with some specific inclusions and exclusions to each model. Activities become the unit of encapsulation in much the same way that ActiveX controls were for Visual Basic 6 applications. It is expected that customers and partners will share activities in the community and generate business from activity creation.
The set of flow control activities that ship with Windows Workflow Foundation include the following:
Control flow activities: Sequence, Parallel, While, IfElse, Listen, EventDriven, ConditionedActivityGroup, Replicator, Delay
Transaction and exception activities: ExceptionHandler, Throw, Compensate, Suspend, and Terminate
Data/form-centric activities: UpdateData, SelectData, WaitForData, WaitForQuery
Communication activities: InvokeWebService, WebServiceReceive, WebServiceResponse, InvokeMethod, and EventSink
The code activity: Code
There are three additional activities that are specific for the state machine workflow model: StateInitalization, State, and SetState.
Each activity is derived from the Activity base class and includes the code that will execute when the activity and a set of design-time properties for use in the designer is called. Later chapters in this book will go into detail on each of these activities; however, a few activities are worth mentioning here. The data- and form-centric activities enable you to bind data from forms and easily surface that information into a workflow; the web services activities give you the capability to consume and expose web services; more advanced activities such as the conditioned activity group enable policy- or rules-based condition evaluation.
Over time, many activities will become available through the broader activity ecosystem through blogs and shared source as well as through Microsoft partners.
Now that we have addressed activities in detail it is important to point out that the model itself is nothing more than a "root" level activity in the Windows Workflow Foundation infrastructure.
One of the significant features of Windows Workflow Foundation is that it offers you the ability to dynamically create workflow at runtime and dynamically update an existing workflow. This is discussed in more detail later in this book.
Now that you have completed your tour of the Windows Workflow Foundation architecture, it's time to examine the coding and design-time support for you to interact with the engine.
Windows Workflow Foundation Engine Architecture
Given the breadth of scenarios requiring workflow and the key goal of providing a singular technology layer to support all these scenarios, the workflow technology is a well-factored framework with numerous pluggable interfaces and extensibility as a core design principle. The architecture for Windows Workflow Foundation is depicted in Figure 1.1.
Figure 1.1. Windows Workflow Foundation engine architecture.
At the bottom of Figure 1.1 is the host process. Windows Workflow Foundation has no inherent execution process. Instead, Windows Workflow Foundation is an in-process engine that runs inside a host process. The host process is responsible for providing a set of services to Windows Workflow Foundation. A wide variety of host processes are available on the Windows platform including console applications, WinForms applications, web applications, web services applications, SharePoint Server, and NT Service applications. Effectively, any executable process can host the Windows Workflow Foundation runtime engine.
This also presents some interesting challenges because the capabilities of each host are often different to another host. SharePoint is a dramatically different environment than a console application. For this reason the Windows Workflow Foundation architecture hosting layer provides a set of pluggable interfaces from Windows Workflow Foundation to the host.
Sitting on top of the hosting layer in the Windows Workflow Foundation architecture is the runtime layer. The runtime layer is the core of the engine providing both workflow execution and workflow lifecycle management capabilities.
Finally, the workflow model layer is where most developers will interact with Windows Workflow Foundation. The workflow model layer includes the various workflow models, APIs, and the activities. The following sections provide more details on the hosting, runtime, and workflow model layers.
Hosting Layer
The hosting layer provides interfaces between Windows Workflow Foundation and a particular host for the following key services: Communication, Persistence, Tracking, Timer, Threading, and Transaction. The implementations of the former three services that ship with Windows Workflow Foundation are durable while the latter two services are stateless. However, none of the services are necessarily durable if you write your own. By abstracting each of these services Windows Workflow Foundation can take advantage of specific capabilities available in specific hosts. The following sections describe the functions performed by each of these services:
Persistence:xs Although some workflows may execute for a short period of time, workflow is inherently asynchronous and a particular workflow, such as the Ph.D. thesis approval process, may take many days or months. A workflow engine that retained its state in memory for that period would not scale as each instance of the workflow would consume memory for the duration and eventually the system memory would be exhausted. Instead, a persistent architecture is used where workflow is executed in memory, and should it be required, the workflow state will persist to a store while it waits for a response that might take some time such as the "Ph.D. approved" step in the workflow. Each host application has a specific set of persistence requirements. For example, to persist state, ASP.NET uses a set of Session State objects that has state client providers for in-memory persistence and SQL Server persistence. In contrast, SharePoint persists state in a SharePoint-specific set of tables in SQL Server and your console application may choose to persist state to the file system as XML. With such a large variety of host-specific persistence capabilities, it would not be sensible for a broadly applicable technology such as Windows Workflow Foundation to specify a single persistence provider. The Windows Workflow Foundation hosting layer persistence interface enables Windows Workflow Foundation to work across the full gamut of host persistence architectures.
Timer: Workflows often need to wait for an event to continue. The timer is the supplied clock that is used to manage these delays. For example, an approval workflow may delay and unload from memory until a particular approver completes the necessary approval. The timer implementation in this case might be a durable timer that survives a potential system restart while waiting for approval.
Tracking: A key reason to implement workflow is because the workflow model provides a greater degree of system transparency at runtime than amorphous code. Indeed, all workflows are automatically instrumented without any programming. The tracking instrumentation is consistent across both the event content and the tracking interface. Depending on the host, the target tracking infrastructure is often different. For example, a LOB application often persists workflow tracking information within the LOB database whereas a console application may persist tracking information to an XML file. The tracking interface receives tracking events from the Windows Workflow Foundation runtime and passes them on to the host application.
Communications: Workflows send and receive events or messages from their host. These events trigger workflows, and move the workflow to the next step in the overall flow. There are a wide variety of communications infrastructures available on the Windows platform including web services, .NET calls, loosely coupled messaging, and so on. For this reason, Windows Workflow Foundation does not provide its own proprietary communications layer. Instead, Windows Workflow Foundation provides pluggable interfaces that can be implemented for any communications layer. Of course, there are easy-to-use, prebuilt communication interfaces to and from common targets such as web services and for passing data objects in and out of a workflow—perhaps from a form.
The physical job of development of these interfaces for specific hosts is relatively challenging compared to other aspects of workflow development described shortly. For this reason, ISVs will typically build host layer providers into their host applications so that end-user developers can simply reuse these services. In addition, Windows Workflow Foundation ships prebuilt support for ASP.NET 2.0 and the interfaces shown in Table 1.1.
Table 1.1. Prebuilt Host Layer Service Implementations
___________________________________________________________________
Host Layer Service Implementation
Persistence SQL Server state persistence
Timer Both an in-memory and SQL Server–based timer
Threading .NET thread pool/ASP.NET thread pool
Tracking SQL Server Tracking Persistence and Event Log recording for termination
Communications .NET components and web services
___________________________________________________________________
Sitting on top of the hosting layer is the runtime layer.
Runtime Layer
The runtime layer is core to Windows Workflow Foundation. In direct comparison to the other layers in the architecture, the runtime layer is not pluggable as it contains the mission-critical services required for workflow. These services include the following:
Execution: The execution service schedules activities and supports common behaviors such as event handling, exceptions, tracking, and transactions.
Tracking: The tracking service creates the tracking events that are serialized through the tracking interface.
State management: The state management service manages states that may be persisted through the persistence interface.
Scheduler: The scheduler service schedules execution of activities.
Rules: The rules service provides policy execution functionality and CodeDOM condition evaluation.
Workflow Model Layer
The workflow model layer is where most application developers will spend the majority of their time writing code for Windows Workflow Foundation. This layer includes support for multiple workflow model types, activities, and the main programming APIs use by most developers.
Windows Workflow Foundation supports two models out of the box:
Sequential workflow model: This model is primarily a structured workflow where a step in the workflow leads to another step in a manner that may be determined often at design-time and can be represented in a flow diagram such as that shown in Figure 1.2.
Figure 1.2. Sequential workflow.
Sequential workflows are most often used to represent structured workflows such as system-to-system workflow. These transformational workflows are self-driven once they are initiated, have a highly predictable path through the events, and are often literally sequential in nature.
State machine workflow model: This model uses the paradigm of states and transitions between states to represent the workflow. There is no deterministic path between the steps from a design perspective because the workflow does not execute in a sequential nature. Rather, the workflow is a set of events that are handled in a highly variable order with one event completing and triggering a state that another event may itself trigger from. The state machine model can literally jump from any stage in the workflow to any other stages, and often will do so multiple times before reaching a completed state. The order workflow is a state machine where various messages are received and trigger the workflow to progress to a particular state. Each iteration of this workflow may result in a different path through the model as depicted in Figure 1.3.
Figure 1.3. State machine workflow model.
State Machine Workflows are an effective way of representing highly people-centric workflows where the workflow thread of execution is not easily represented in a flow. This workflow model is also very useful for scenarios where a high priority event must be processed even though work is already in process or when a large number of events may occur at a particular stage in the workflow. A perfect example is a stage in the order workflow where an "order cancelled," "order updated," and "order completed" event that may be received at any time and should immediately cancel the entire process.
Although Windows Workflow includes these two models, customers can inherit from them to create their own specific models or create new models.
Regardless of model and sequencing behavior the basic element of execution and reuse is called an activity. An example of an activity is "send goods" in the previous sequential workflow example.
There are two types of activities—the simple activity and the composite activities. What makes Windows Workflow Foundation very different from traditional workflow engines is that the engine has no fixed underlying language or grammar. Instead the engine chains a set of activities that are supplied by Microsoft and created by you the developer. Microsoft-supplied constructs include "If," "Code" blocks, activities for web services, and many more. In addition, you can create your own control flow activities such as "do until" but more likely you will be creating higher level activities such as the "Receive Order" activity described previously. By using an activity execution methodology rather than a language, Windows Workflow Foundation is able to support a broad range of scenarios and you can reuse your activities across multiple workflows. Indeed the flow and the state workflow models share a majority of activities with some specific inclusions and exclusions to each model. Activities become the unit of encapsulation in much the same way that ActiveX controls were for Visual Basic 6 applications. It is expected that customers and partners will share activities in the community and generate business from activity creation.
The set of flow control activities that ship with Windows Workflow Foundation include the following:
Control flow activities: Sequence, Parallel, While, IfElse, Listen, EventDriven, ConditionedActivityGroup, Replicator, Delay
Transaction and exception activities: ExceptionHandler, Throw, Compensate, Suspend, and Terminate
Data/form-centric activities: UpdateData, SelectData, WaitForData, WaitForQuery
Communication activities: InvokeWebService, WebServiceReceive, WebServiceResponse, InvokeMethod, and EventSink
The code activity: Code
There are three additional activities that are specific for the state machine workflow model: StateInitalization, State, and SetState.
Each activity is derived from the Activity base class and includes the code that will execute when the activity and a set of design-time properties for use in the designer is called. Later chapters in this book will go into detail on each of these activities; however, a few activities are worth mentioning here. The data- and form-centric activities enable you to bind data from forms and easily surface that information into a workflow; the web services activities give you the capability to consume and expose web services; more advanced activities such as the conditioned activity group enable policy- or rules-based condition evaluation.
Over time, many activities will become available through the broader activity ecosystem through blogs and shared source as well as through Microsoft partners.
Now that we have addressed activities in detail it is important to point out that the model itself is nothing more than a "root" level activity in the Windows Workflow Foundation infrastructure.
One of the significant features of Windows Workflow Foundation is that it offers you the ability to dynamically create workflow at runtime and dynamically update an existing workflow. This is discussed in more detail later in this book.
Now that you have completed your tour of the Windows Workflow Foundation architecture, it's time to examine the coding and design-time support for you to interact with the engine.
8175
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
