首页 > 编程开发 > Objective-C编程 >
-
c#教程之WF学习系列WF基础知识点概述下
自定义跟踪服务
Windows Workflow Foundation 包含 SqlTrackingService 服务,该服务可用于跟踪存储在 SQL Server 数据库中的数据。但是,由于 Windows Workflow Foundation 使用了扩展性模型,因此可以创建使用如本地文件等各种存储介质的自定义跟踪服务,这是因为运行时引擎不关心数据的最终目标或交付格式。有关如何创建自定义跟踪服务的更多信息,请参见创建自定义跟踪服务。
4 补偿概述
补偿是由于工作流中其他位置发生异常而做出的一种行为,这种行为撤消由成功完成的可补偿活动所执行的任何操作。
已完成事务的 Windows Workflow Foundation 补偿模型是一个处理工作流中发生的任何业务异常并合乎逻辑地撤消已完成事务的过程。
Windows Workflow Foundation 补偿可以是:
未指定异常处理程序或未处理特定异常时,默认为隐式。
使用 CompensateActivity 活动时为显式。
5 本地通信和关联概述
宿主进程可以通过经由自定义本地通信服务交换数据来与工作流进行通信。 这些本地通信服务实现了一些用户定义的接口,这些接口定义了将在工作流和宿主进程之间进行传递的方法和事件。
通过使用在宿主进程和工作流之间作为事件参数传递的唯一 ID,宿主进程还可以在特定的工作流实例中与特定的活动进行交互。 这称为“关联”。
Windows Workflow Foundation 支持工作流的承载环境中的本地通信服务和 Web 服务通信。
Windows Workflow Foundation 通信服务使工作流能够使用方法和事件通过消息与外部系统交互。 事件用于将数据发送到工作流,而工作流使用方法将数据发送到主机应用程序。 通过事件与工作流进行通信的功能提供了一种将数据发送到工作流的异步方式。
在工作流中使用本地服务
Windows Workflow Foundation 工作流通信服务向工作流编写器公开用户定义的服务类,作为方法调用和事件处理程序,以简化出站和入站消息交换的建模。 单个服务类实例到多个工作流实例的多路复用允许主机编写器对出站消息的单个位置进行编程,而引发事件时仍针对特定工作流实例。
下图演示本地通信服务如何与其主机应用程序通信。
工作流实例上的 HandleExternalEventActivity 和 CallExternalMethodActivity 活动与在自定义接口中声明并在自定义本地服务中实现的事件和方法交互。 HandleExternalEventActivity 活动响应由主机应用程序引发且由本地服务实现的特定事件。 CallExternalMethodActivity 对本地服务调用方法。
工作流通信服务
Windows Workflow Foundation 工作流通信服务实现一种供对象与工作流实例通信的简单机制。通信通道的定义是一个接口,其实现是添加到运行时以方便通信的服务类。对于服务类,工作流的行为很像任何其他类,您通过引发事件和接收方法调用与其通信。 对于工作流,通信接口显示为包含入站事件接收和出站操作方法调用的通道。ExternalDataExchangeService 将接口上的外部方法声明转换为服务对象上的方法调用。 我们可以视为本地服务的类能够引发事件,工作流运行时引擎截获这些事件并将其作为工作流的入站消息加以传送。
下面的代码示例演示如何定义本地工作流通信接口的示例。
[ExternalDataExchange]
public interface ICommunicationService
{
void HelloHost(string message);
event EventHandler<ExternalDataEventArgs> HelloWorkflow;
}
服务类
服务类实现用于定义与工作流进行通信的接口。 接口上的所有事件都是单向的,也就是说,这些事件没有 ref 或 out 参数,并且没有返回值。 但是,对于传出请求,接口上的方法可以具有 ref 和 out 参数,并且有返回值。
通信模型为多对一:有很多工作流实例,每个实例可以使用此单一实例服务对象在很多会话上传递。这意味着对所有工作流中的特定方法 m 的所有出站调用由同一个对象上的同一个 m 提供服务。相反,所有入站调用必须显式定向到正确的工作流实例和会话。 Windows Workflow Foundation 为 m 提供一种机制以区别出站调用的工作流实例和会话。 使用这两段信息,对象可以将响应定向回正确的工作流实例上的正确的会话。
Windows Workflow Foundation 在出站调用线程上的 System.Workflow.Runtime.WorkflowEnvironment.WorkflowInstanceId 中提供调用工作流的实例标识符。
下面的代码示例演示通信服务实现。
public class CommunicationService : ICommunicationService
{
public event EventHandler<ExternalDataEventArgs> HelloWorkflow;
public void HelloHost(string message)
{
Console.WriteLine("This is the message: {0}", message);
// Raise the HelloWorkflow event.
HelloWorkflow(null, new ExternalDataEventArgs(WorkflowEnvironment.WorkflowInstanceId));
}
}
您启动工作流的实例之前,必须将 ExternalDataExchangeService 添加到工作流运行时引擎,然后将自定义通信服务添加到 ExternalDataExchangeService,如下面的代码示例所示。
ExternalDataExchangeService externalService = new ExternalDataExchangeService();
workflowRuntime.AddService(externalService);
externalService.AddService(new CommunicationService());
在工作流中使用关联
Windows Workflow Foundation 运行时引擎使用关联将入站消息映射到某个工作流实例中的特定 HandleExternalEventActivity 活动。 对实例的映射是在将工作流实例 InstanceId 传递到 ExternalDataEventArgs 构造函数时完成的。通过使用接口属性来定义关联。 Windows Workflow Foundation 工作流通信服务接口可以为关联指定附加的元数据。 关联某个工作流实例的事件活动时需要此关联数据。 关联元数据规范采用接口属性的形式,即 CorrelationParameterAttribute 属性。
注意:
为通信接口提供关联属性是可选的。 默认情况下,通信接口都是无关联的。 用户只有在需要使用关联将消息传递给特定活动实例时才应添加关联属性。
接口属性
下表描述在可供 Windows Workflow Foundation 工作流通信服务使用的接口定义中可以使用的接口属性全集。
属性 | 说明 |
CorrelationParameterAttribute | 用于指定在接口中定义的方法和事件的用于关联的参数名称。 如果方法或事件包含一个与该名称匹配的形参,则该参数定义该方法或事件上的相关值。 如果方法或事件没有此类参数,则方法或事件可以使用 CorrelationAliasAttribute 来定义相关值的位置。 此属性在一个接口中可以出现多次。 |
CorrelationInitializerAttribute | 用于在方法或事件中指示相关参数的值是在调用该方法或引发该事件时初始化的。 对于给定的 CorrelationToken,必须在对话中的任何其他方法或事件执行之前调用或接收初始值设定项方法或事件。 任何可以初始化新对话(即新的相关令牌)的方法或事件都必须使用此属性进行标记。 对于每个相关令牌,方法或事件必须包含一个适当的命名参数或一个 CorrelationAliasAttribute。 |
CorrelationAliasAttribute | 在方法或事件定义中用来重写该成员的 CorrelationParameter 设置。 CorrelationAliasAttribute 属性指定可用参数中可以获得相关值的位置。 该字符串参数是针对形参集的以点分隔的路径。 该参数指示在何处可以找到匹配数据值。 如果定义了多个相关令牌,还必须指定令牌 Name 命名参数。 |
使用相关属性
CorrelationParameterAttribute 命名对话标识符和关联。 然后,使用该名称的形参对接口上的每个方法或事件进行声明(例如 id),如下面的 ITaskService 接口代码示例所示。 也可以使用其他属性来说明更复杂的相关映射。 当实例和相关信息已为某个对话所了解时,该类将引发其本地服务事件。它在调用上的参数数据中指定关联。
下面的代码演示与接口定义相关的工作流通信服务 ITaskService。
[Serializable]
public class TaskEventArgs : ExternalDataEventArgs
{
private string id;
public TaskEventArgs(Guid instanceId,string id)
:base(instanceId)
{
this.id = id;
}
public string Id
{
get { return id; }
set { id = value; }
}
}
[ExternalDataExchange]
[CorrelationParameter("taskId")]
public interface ITaskService
{
[CorrelationInitializer]
void CreateTask(string taskId, string assignee, string text);
[CorrelationAlias("taskId", "e.Id")]
event EventHandler<TaskEventArgs> TaskCompleted;
}
任何启动新对话的操作、方法或事件必须具有 CorrelationInitializerAttribute 属性。 如果发生对 CorrelationInitializerAttribute 方法 m 的调用,则服务类能了解该调用正在初始化新对话。 工作流对话生存期由相关引用的生存期指示。 工作流可以在对话之间卸载或加载。
下面的代码示例演示实现 ITaskService 的服务类。
public class TaskService : ITaskService
{
public void CreateTask(string taskId, string assignee, string text)
{
Console.WriteLine("task " + taskId + " created for " + assignee);
}
public void RaiseEvent(TaskEventArgs args)
{
if (TaskCompleted != null)
TaskCompleted(null, args);
}
public event EventHandler<TaskEventArgs> TaskCompleted;
}
6 持久性概述
Windows Workflow Foundation 简化了有状态的、长期运行的持久性工作流应用程序的创建过程。 工作流运行时引擎管理工作流的执行情况,而且允许工作流长期保持活动状态并在应用程序重新启动之后存在。这种持久性是 Windows Workflow Foundation 的关键原则。 它意味着可以在等待输入时从内存中卸载工作流,而且工作流可以序列化为持久性存储(如 SQL 数据库或 XML 文件)。 只要收到了输入,工作流运行时引擎就会将工作流状态信息重新加载到内存中并继续执行工作流。
Windows Workflow Foundation 提供的 SqlWorkflowPersistenceService 可以与 Microsoft SQL Server 2005 Express、SQL Server 2000(或更高版本)或 SQL Server 2000 Desktop Engine (MSDE) 很好地集成,以便方便而又高效地保持工作流信息。 您还可以通过从 WorkflowPersistenceService 基类派生来创建自己的持久性服务,以便按照所需的方式存储工作流状态信息。
7 跟踪概述
“跟踪”是一项功能,用于指定并捕获有关工作流实例的信息,并在这些实例执行时存储该信息。 Windows Workflow Foundation 提供了 SqlTrackingService 这一跟踪服务,该服务使用 SQL 数据库来存储所收集的跟踪信息。您也可以编写自己的跟踪服务来收集该信息,并以您应用程序需要的任何格式将其存储下来。
创建新工作流时,该跟踪服务会请求一个要与该工作流相关联的跟踪通道。 之后,会将该工作流中的所有跟踪信息发送到该跟踪通道。
该跟踪服务可以跟踪三种类型的事件:工作流实例事件、活动事件和用户事件。 通过提供跟踪配置文件,您可以配置您的服务要为特定工作流实例或特定类型的工作流接收的信息类型和数量。
跟踪框架还能够在事件期间提取与活动或工作流相关的信息。 如果需要跟踪活动或工作流中的特定属性或字段,您可以在跟踪配置文件的提取节中提供此信息,将在指定事件期间提取该信息。
8 序列化概述
对工作流、活动和规则可以进行序列化和反序列化。 这样就可以保持它们,在工作流标记文件中使用它们,以及在工作流设计器中查看其属性、字段和事件。
Windows Workflow Foundation 为标准活动提供了默认的序列化功能,您也可以为自定义活动创建自己的序列化功能。例如,利用自定义活动序列化程序,可以决定对哪些成员进行序列化以及如何对其进行序列化。 这也将确定这些成员在工作流设计器中是可见还是隐藏。
9 工作流更改概述
使用 Windows Workflow Foundation,可以在运行时动态更新工作流实例和声明性规则。在计划待执行的活动之前,可以更改预期行为、流控制等。 使用该功能,可以修改业务处理逻辑,且不必重新编译和重新启动工作流。
10 “规则和条件”概述
Windows Workflow Foundation 可将业务逻辑作为规则或条件来实现。 IfElseBranchActivity、ConditionedActivityGroup、WhileActivity 和 ReplicatorActivity 活动使用条件来控制活动的执行。 条件可以声明方式表示,也可以在代码中定义。 声明性条件以代码 DOM 语句的形式在规则的 XML 文件中创建。 基于代码的条件可引用工作流的代码文件中的一个方法,该方法通过 Result 属性返回其结果。
与条件一样,规则以代码 DOM 语句的形式表示,并收集到规则的 XML 文件中。 规则包含一个条件语句和一些操作集合,这些集合中的操作是根据条件的结果来执行的。规则将会收集到规则集中,规则集既支持规则的简单依序执行,也支持规则的复杂正向链接。 规则集由 PolicyActivity 活动执行。
使用规则和声明性条件定义逻辑的一个主要优点是,通过使用工作流更改来执行动态更新,可在运行时修改这些规则和声明性条件。 此外,规则使您可将业务逻辑与工作流分开,以便与其他工作流共享这些规则。最后,通过在规则中定义业务逻辑,可在对象模型之上构建高级工具,如依赖关系可视化工具和影响分析工具。
11 错误处理概述
工作流运行时引擎在一个称为“错误处理”的进程中异步处理活动中所出现的异常。 异常被安排在队列中以便日后处理。 如果异常类型与特定 FaultHandlerActivity 活动所处理的类型相符,则该活动将处理此异常。 如果无法处理异常,则通过父活动向上冒泡,直到最终导致工作流实例终止。
Windows Workflow Foundation 中的错误处理指的是以异步方式处理异常。这意味着工作流运行时引擎会捕获在活动中(显式或隐式)引发的异常,然后将其安排在队列中以便以后处理。 这与常规异常处理不同,因为在常规异常处理中,如果异常是在 try 块中引发的,则它可以由相应的 catch exception 块捕获,也可以立即对用户引发。
异常的原因
在工作流中,异常可能通过下列方式生成:
TransactionScopeActivity 或 CompensatableTransactionScopeActivity 中的事务超时。
工作流通过使用 ThrowActivity 活动引发的显式异常。 有关更多信息,请参见使用 ThrowActivity 活动。
从代码活动的处理程序或自定义活动的代码旁置引发的 .NET Framework 异常。
从库或在工作流中使用的组件等外部代码引发的异常。
捕获异常
在错误处理中,如果引发异常的活动不能处理异常,则该异常将被传输到其父活动以进行解决。 在处理异常或工作流运行时引擎终止工作流实例之前,该异常将被传输到工作流层次结构中。
异常由 FaultHandlerActivity 活动来处理。 每个 FaultHandlerActivity 活动都与 .NET Framework 异常类型相关联,并且如果引发的异常与该异常类型匹配,则该活动还包含一组所执行的活动。 FaultHandlerActivity 活动是包含 0-n 个 FaultHandlerActivity 活动的 FaultHandlersActivity 活动的父级。 FaultHandlersActivity 可以是任何复合活动的子活动。
Windows Workflow Foundation 中错误处理的目标是撤消已发生异常的活动的部分工作及不成功的工作。 FaultHandlerActivity 活动的完成从不被视为其相关活动的成功完成。 这意味着,当执行 FaultHandlerActivity 活动时,引发异常的活动被置于错误状态。当 FaultHandlerActivity 活动完成时,相关联的活动被置于关闭状态。 此外,相关联活动的任何同级活动(如 ParallelActivity 活动的其他子级)被置于取消状态,然后置于关闭状态。它们永远不会成功执行。
错误处理与补偿
错误处理与补偿之间的区别是,补偿只能对已成功完成的活动执行,不能对引发异常和处于错误状态的活动执行;但是,在与引发异常的活动相关联的 FaultHandlerActivity 活动内可以执行 CompensateActivity 活动。 例如,补偿处理的典型情形是,一项活动成功完成,但在工作流后面的另一活动中引发异常。该活动的错误处理程序包含一个 CompensateActivity,后者可撤消在工作流中以前完成的任何操作。 若要对此进行进一步扩展,您可能要在工作流后面由另一活动引发 ItemDiscontinuedException 之后向客户退款。
12 工作流标记概述
基于可扩展应用程序标记语言 (XAML) 的工作流标记可以使开发人员和设计人员以声明方式为业务逻辑建模,并将其与由代码旁置文件建模的低级实现细节区分开。因为工作流可以声明方式建模,所以可以在运行时,通过直接将工作流标记文件加载到工作流运行时引擎的方式来激活工作流。
出处:http://mjgforever.cnblogs.com/