更广泛的工作流概念和术语
l Generic Workflow Product Structure: 见图5
l Workflow Product Components&Interfaces: 见图6
l Workflow Application:一个与workflow enactment service交互的软件程序，它处理一个process中某个特定活动。
分两类：
Client Application要求workflow engine服务。
Inoved Application支持特殊的活动或work items，由WMS初始化。
l Client Application: 要求workflow engine服务的应用程序。
Worklist 处理。
Process instance初始化和其他控制功能（挂起/唤醒等）。
获取和操作过程定义数据。
各种系统管理功能（例如：挂起某些过程定义的使用）。
参见Workflow Reference Model标准接口中的API。
l Invoked Application:是由WMS激活的、全部或部分地支持工作流的participant完成某项活动的应用。
可有workflow engine和/或worklist handler激活。
参见Workflow Reference Model标准接口中的API。
l Workflow Data Structure – overview:
见图7
l Application Data:应用特定的数据，它不被WMS访问。
（假如这种数据被WMS用于确定状态的改变，它就变成来了Relevant Data）
l Workflow Relevant Data:被WMS用于确定workflow instance状态改变的数据，例如：在pre-和post-conditions、transition condition或工作流参与者赋的值中。
Workflow application和workflow engine都可操作该数据。
它对后续活动或其他process instance应用，它影响下一步活动的选择（例如：两个活动之间传递的决策数据和/或引用值）。
它有两种类型：
Typed 数据的结构由它的类型隐含（WMS能理解和处理之中数据的结构）。
Untyped WMS不能理解这种数据结构，但可传递该数据（引用）到应用。
l Workflow Control Data:由WMS和workflow engine管理的数据。它是WMS的内部数据，对工作流应用不可见。
表示工作流系统和它的process instance的动态状态。
例如：每个workflow instance的状态信息、每个activity instance的状态信息（活动或不活动）、每个过程中的恢复点等。
工作流控制数据可为持久性数据，以便系统失败后恢复，也可用于派生审计数据。
l Process State:一个process instance在某个点上的内部状态条件。大多数WMS将它作为工作流控制数据的一部分。
在运行时，每个process instance的状态由WMS维护。不同的提供上由不同的表达方法。
随着一个process instance的执行，process state发生一系列的状态变化，一个完整的process states集完全定义了process instance遵守内部的行为。
常用状态：
Initiated：过程实例已创建，但还没有执行。
Running：过程实例已经开始执行，且一个以上的活动已经开始。
Active：一个以上活动开始，且活动实例存在（进一步，支持子状态以纪录active活动的详细信息。
Suspended：过程实例静止不动了，且直到resume以前无进一步的活动开始。
Complete：过程实例已经达到了它的完成状态，且任何的后续系统（如audit logging）已开始进行。
Terminated：由于出错或用户的要求，过程的执行已经停止（不正常）。
Archived：过程实例已进入不确定的档案状态（但可唤醒，如长生命周期过程）。
WAPI定义了很多处理过程状态信息的调用，如：访问process state或强迫使一个变迁为一个新状态等。
l Activity State:在一个点上，定义一个activity instance状态的内部条件。很多WMS将其作为工作流控制数据维护。
在执行时，WMS维护每个process instance的状态，有些WMS可扩展到维护每一个已创建的activity instance。不同的开发商由不同的activity state的表示方法。
常用状态：
Inactive 活动实例一创建，但还没有激活；对该活动没有workitems。
Active 一个以上的workitems已创建且分配给它进行处理。
Suspended 活动实例停止不动；直到它resume以前没有进一步workitem开始（注意：有些活动是不能suspended）。
Completed process instance已达到它的完成条件，且任何的后续系统（如audit logging）已开始进行。
l State Transition:从一个状态（process或activity instance）转换到另一个状态，反映了工作流状态的变化，如：初始化一个特殊的活动。状态变化可能是对外部事件、用户API调用、workflow engine做出的路由决策等的反应。
随着工作流的执行，产生一系列的状态转化。它由workflow engine纪录并可作为审计数据。
l Dummy Activity:无实际的动作，但可作为处理复杂路由或过程控制条件的表示。
它是过程路由网络中的一个节点，但无任何动作。
l Event:一种特殊条件（WMS内部或外部）的发生，它将引起WMS做一个动作。例如：一个特定的email可能使WMS开始一个特定过程定义的实例。
一个事件有两部分：
Trigger 一组预定义的、与系统操作相关的条件，它引起一个特定动作的执行。
Action(响应) 一个trigger的、系统预定义的响应。
WMS直接响应一个特定的事件，或应用直接监督和处理的事件。这种应用通过WAPI初始化一个动作或设置工作流相关数据等。
Workflow Event连接trigger条件和WMS涉及的系统动作。
其他类型的事件由参与工作流的应用使用，而不是WMS。
一个特殊的事件被用于在并行工作流线程之间发信号。
l Audit Data:过程实例从头到尾的历史纪录，这种数据并入过程实例状态变换信息中。
如：date、time、状态变幻的工作类型。
WfMC Audit Data specification标识了一组标准的审计数据纪录，它们与工作流中特定的事件和变换联系。
l Workflow Definition:过程定义部分中可自动的活动部分。
Process definition与workflow definition是有趣别的。
l Process Execution:一个过程实例被创建和被管理的这段时间。
Process execution阶段和process definition阶段不同。
l Organization Role:一组有特殊属性、资格和/或技能的participants。
该组的任何participants可执行任何需要该组数性资源的活动/workitem。
如：Supervisor role、Insurance Underwriter role
工作流的参与者保证一个叫色
l Organization Model:表达组织实体和它们之间关系的模型；它也可并入该实体的各种数据中，如：技能或叫色。它可用目录指南，或数据库实现。
这种模型可组织成层次、职权、责任和与角色相连的属性。WMS可将其作为过程角色的一部分。
Process definition将引用Organization Model，根据Organization Model中的属性指派participants。在过程运行期间，WMS可通过Organization Model获得participant的细节。
例如：图
WfMC Process Definition Meta-Model包含一个最简单的内值的组织模型，它也可引用外部数据。
l Process Role:把participants分配一组工作流活动的机制。
WMS给participant指定一个角色以访问和处理一个工作。
角色定义了user在一个特定的过程或活动中的上下文。角色通常包含组织的概念(如：结构和关系、责任或职权)，但也可引用其它属性（如：技能、位置、值、时间或日期等）。
l Escalation:当一个特定的限制或条件不能满足时，就激活一个过程。(异常处理)
一般地，它是提交给一个上层权力机构。
l Constraint:一个在工作处理过程中必须满足的条件（通常是活动/工作的选择/完成条件）；不能满足一个限制可引起一个异常条件或其他定义的过程。
例如：
基于时间的（见deadline）
基于资源的（如：消费少于……）
基于花费的（如：花费大于……）
l Workflow Monitoring:在工作流执行期间，能跟踪和报告工作流事件。
过程的拥有者通过Workflow Monitoring监督过程实例的执行。
l Workflow Engine:对一个过程实例提供执行使环境的软件服务。
根据过程定义，对business process的执行提供操作函数。包括：
解释过程定义
创建过程实例，管理它们的执行，如：start/stop/suspend/resume等。
在活动之间导航，并为它们的处理创建适当的workitem。
管理、监督功能。
Workflow engine通常包含worklist handling功能（尽管它与Workflow engine共享一个平台，但它是以用户为中心的）。
一个以上的Workflow engine组成一个工作流领域（workflow domain）；工作流领域提供一个同类的过程处理环境。一个workflow enactment service提供一个在多个workflow engines（它们可术语不同的域）上执行的特定工作流的执行。
两个以上的workflow engines科协做工项工作流的执行。（见workflow interoperablity）。
l Workflow Interoperability:两个以上workflow engines互相通讯、协同工作的能力。
它包括以下概念：
通过一个workflow enactment service提供过程在不同workflow engines上执行。
有各种互操作性方式：
层次的（Nested Subprocess）
Connected Discrete(Chained)
Connected Indiscrete(Peer-to-Peer) （参见Workflow Reference Model）
并行且同步的
细节请参见WfMC Workflow Reference Model和interoperability specification。
能在同质和异质的workflow engine之间互操作；可能在不同层次的功能之间。
WfMC Workflow Reference Model包含函数接口（接口4）以支持workflow engine之间的互操作性。
l Workflow Interoperability Contract:一个预先在组织（定义合同范围的组织）、业务和工作流互操作性激素框架之间建立的合同。
主要是在合作的业务过程、过程名字和地址、安全性和审计要求等方面
通常也包含合法的、商业的和技术的因素，它们对支持在EC环境中的写作过程执行是必要的。
l Workflow Enactment Service:包含若干个workflow engine以便创建、管理和执行特殊工作流实例的软件服务。应用与它的交互用WAPI。
它可在一个（同质的）工作流域中操作，或通过WfMC的互操作接口提供异质的工作流之间的操作。
l Workflow Domain:一个工作流管理服务，它包含一个或多个workflow engines（同质的，在同一个管理模式下进行）。
一个workflow domain有如下的常用管理功能：
common workflow naming(processes/activities)
common user naming
common interpretation of process definitions and state transitions
a common organizational model and roles
a common supervisory interface
common audit data
它们典型地来至于通用、同质的产品集。
参见接口4。一个特殊的过程的运行服务可能跨越多个workflow engines和异质的产品。
l Work Item Pool:一个workflow engines所能访问的workitems
一个worklist handler可能（异常地）需要所有workitems的纵观，Work Item Pool可满足者已要求。
l Administrator:一个工作流系统的特殊用户，它有进行各种系统建立、控制和管理功能的特权。在有些系统中，这些任务可在若干个administrator之间共享，每人管理不同的范围。
Administrator的功能是：
建立和管理用户名、口令和角色等
分配和在分配workitem
异常条件处理
过程定义和版本控制
监督work和process instance的进展
系统审计功能
可用一些特殊的管理工具。
