工作流参考模型(WFMC)

工作流参考模型（Workflow Reference Model）是由工作流管理联盟（Workflow Management Coalition，简称WfMC）提出的一个概念模型，旨在为工作流管理系统的开发和实现提供一个标准化的框架。

它的发展历史可以追溯到20世纪90年代初。随着计算机技术的发展和企业对于业务流程自动化的需求增加，工作流技术应运而生。为了实现工作流系统之间的互操作性和标准化，许多研究人员和企业开始关注工作流参考模型的研究和发展。

本篇文章主要介绍和翻译WFMC，让大家有个基础的了解认识。

以下是工作流参考模型中的主要组件：

1. 过程定义工具：用于创建可由工作流执行软件解释的过程描述。
2. 工作流执行服务：负责实例化和激活过程，管理活动的序列化，并与外部资源交互。
3. 工作流引擎：执行工作流实例的运行时环境。
4. 工作流客户端应用：与最终用户交互的软件实体，负责处理工作列表。
5. 被调用应用程序：工作流引擎直接激活的特定工具，用于执行特定活动，也就是调用第三方工具。
6. 工作流相关数据和应用程序数据：工作流引擎用于确定状态转换的数据，以及特定于应用程序的数据。

工作流执行服务

工作流执行服务（Workflow Enactment Services）通过一个或多个工作流引擎，为流程实例和任务提供运行环境，负责解释和执行定义的工作流程，与流程所需的外部资源进行交互。

以下是其主要功能：

• 创建和管理工作流实例。
• 解释和激活过程定义。
• 与外部资源交互，包括用户、应用程序和数据库。

通过这些功能，工作流执行服务能够提供一个强大且灵活的环境，以支持各种业务流程的自动化和优化。工作流执行服务的设计和实现对于确保工作流管理系统的整体性能和可靠性至关重要。

工作流引擎

工作流引擎是工作流执行服务中的软件服务或“引擎”，它为工作流实例的运行时执行环境提供支持。引擎通常提供以下功能：

• 解释过程定义。

  这里是让静态的定义能动起来运行。
  

• 控制过程实例的创建、激活、挂起、终止等。

  这里其实就是流程的生命周期。
  

• 在过程活动中，可能涉及顺序或并行操作、截止日期调度、解释工作流相关数据等。

  流程中每个节点都代表一个业务操作。
  

• 管理用户交互，如登录、注销、识别用户任务、维护工作项等。

  这个属于用户管理模块的功能。
  

• 维护工作流控制数据和工作流相关数据，以及将工作流相关数据传递给应用程序或用户。

  这个是引擎运行时的数据，以及数据的流转问题。
  

• 调用外部应用程序，并链接任何工作流相关数据。

  这个是跟第三方系统打通。
  

• 执行控制、管理、审计目的的监管操作。

  这里是将系统的权限控制、平台管理和运行日志等信息的维护管理。
  

同质与异质工作流执行服务

同质工作流执行服务由一个或多个兼容的工作流引擎组成，这些引擎为具有定义好的（产品特定）过程定义属性的工作流过程提供运行时执行环境。而异质工作流执行服务则由两个或多个同质服务组成，这些服务遵循共同的互操作性标准，其内容主要涉及以下几个方面:

• 定义一套共同的命名方案

  为了实现跨不同工作流系统或引擎的互操作性，需要一个共同的命名方案，以便在不同的执行环境中一致地识别和引用过程、活动、用户和其他相关对象。

• 流程定义对象和属性：支持在不同系统之间共享和交换流程定义对象和属性

• 定义如何在不同工作流引擎之间传输工作流相关数据

• 流程、子流程或活动在不同工作流引擎之间的传输

  在异质环境中，可能需要将一个流程、子流程或活动从一个工作流引擎传输到另一个引擎，标准应支持这种传输的机制和协议。

• 支持共同的管理监控功能

  为了管理和监控跨多个工作流系统的执行状态，需要共同的管理和监控功能，这可能包括用户管理、角色管理、审计管理和资源控制等。

通过遵循这些共同的互操作性标准，不同的工作流执行服务能够更好地协作，实现跨系统的工作流管理和数据交换，从而提高工作流技术的整体效率和灵活性。这些标准有助于构建一个更加开放和集成的工作流生态系统，使得组织能够更有效地利用工作流技术来优化业务流程。

（1）这里异质工作流执行服务你可以理解成不同产商的工作流产品，上面的内容就是说这些不同产商的工作流产品需要遵守的一些标准。
（2）这里早期的规范是希望各个厂商之间的工作流系统能够遵循一套标准，来实现系统之间的数据交互，但现实是几乎各个都有自己的一套标准，很难兼容打通。

流程实例的基本状态变迁

工作流执行服务可以被视为一个状态机，其中的活动实例可以改变状态以响应外部事件，下面显示了流程实例的基本状态变迁：

• 初始化（Initiated）：表示过程实例已被创建，包括相关的流程状态数据和工作流相关数据，但尚未开始执行。
• 运行（Running）：过程实例已经开始执行，其活动可以启动（一旦满足适当的活动开始条件）。
• 活动（Active）：至少有一个活动已经开始（即已创建并分配给适当的活动实例）。
• 挂起（Suspended）：过程实例处于静止状态，直到通过恢复命令返回到运行状态，在此期间不会启动任何活动。
• 完成（Completed）：过程实例已满足完成条件，所有内部的后续操作（如记录审计数据或统计信息）将被执行，然后销毁过程实例。
• 终止（Terminated）：过程实例的执行在正常完成之前被停止；可能会执行任何内部操作，如错误记录或记录恢复数据，然后销毁过程实例。

活动实例的基本状态变迁

活动实例状态指的是在工作流执行过程中，各个活动可能处于的不同阶段。这些状态对于理解工作流的动态行为和进行有效的流程控制至关重要。无论是同质还是异质工作流执行服务，活动实例的状态通常包括以下几种：

• 初始（Inactive）：活动实例已被创建，但尚未激活。例如，由于活动的入口条件尚未满足，它还没有开始执行。
• 活动（Active）：活动实例已经激活并正在执行。这意味着已经为该活动创建了工作项，并且可能已经分配给适当的参与者或自动化系统进行处理。
• 挂起（Suspended） ：活动实例处于非活动状态，暂时不会继续执行，直到恢复命令被发出。这可能是由于某种外部条件或内部决策导致活动需要暂停。
• 完成（Completed） ：活动实例的执行已经完成。这通常意味着所有的任务都已执行完毕，并且任何后续的过渡条件都已经评估过。

这两部分其实就是前面文章介绍的流程和任务的生命周期。

工作流应用编程接口与数据交换

工作流应用编程接口，即Workflow Application programming Interface ，简称WAPI。WAPI是工作流执行服务在其边界上支持的一组API调用和交换函数，用于与其他资源和应用程序进行交互。WAPI定义了一组API命令和交换格式的核心集，并根据需要为每个功能区域提供特定的扩展。

这里其实就是说工作流的核心API，以及这些API的输入输出数据格式。

数据类型

WFMC定义了三种数据类型：工作流控制数据、工作流相关数据和工作流应用数据。

工作流控制数据（Workflow Control Data）

定义：工作流控制数据是由工作流管理系统或工作流引擎管理的内部数据。这种数据通常不通过工作流应用程序编程接口（WAPI）命令直接访问或交换，但某些信息内容可能在特定命令的响应中提供（例如查询过程状态、提供性能指标等）。

作用：工作流控制数据用于管理工作流系统内部，以维护和跟踪工作流实例的状态、活动的状态、以及工作流执行的历史记录等。这包括工作流引擎的状态信息、检查点和恢复/重启信息，这些信息对于协调和恢复失败条件至关重要。

工作流相关数据（Workflow Relevant Data）

定义：工作流相关数据是工作流管理系统用来确定工作流过程实例的状态转换的数据。这种数据可能影响下一个要执行的活动的选择，并可能需要在活动之间传输。

作用：工作流相关数据对于工作流的逻辑决策至关重要，它支持基于条件的工作流导航和动态流程控制。例如，根据工作流相关数据的值，工作流引擎可能决定将控制权转移到特定的活动或分支。

这里其实就是工作流中各个活动实例在运行时的数据，工作流可以根据这些运行时数据进行决策控制活动流转方向。

工作流应用程序数据（Workflow Application Data）

定义：工作流应用程序数据是特定于应用程序的数据，不由工作流管理系统直接访问。这种数据仅与在工作流中执行的应用程序或用户任务相关，并且通常由应用程序或用户直接操作。

作用：工作流应用程序数据是工作流中处理的具体内容，例如文档、表格或其他业务数据。工作流管理系统通常不直接处理这些数据，但可能需要在活动之间传递这些数据，或将其作为工作流相关数据的一部分进行管理。

这里其实就是工作流在调用第三方系统，例如数据库、文档等进行操作时产生的业务数据。

数据交换（Data Interchange）

数据交换确保了在工作流之间，以及工作流与外部系统之间的信息流动和同步。

数据交换在工作流执行服务中涉及以下几个方面：

工作列表处理（Worklist Handling）：

该部分主要是接口2（Interface 2）：

• 工作列表是分配给特定用户或用户组的工作项队列。工作流引擎将工作项添加到工作列表中，而工作列表处理组件（通常是工作流客户端应用程序的一部分）则负责从工作列表中检索工作项供用户处理。

  这里工作项例如审批操作，表单操作涉及跟人交互的一些活动。
  

• 数据交换可能涉及将工作相关数据嵌入到工作项中，并在用户处理工作项时提供给用户界面或特定应用程序。

  这里说的是相关数据怎么在前端展示出来给用户去操作的问题。
  

被调用的应用程序（Invoked Applications）：

该部分主要是接口3（Interface 3）：

• 工作流引擎可能需要直接激活特定的应用程序来执行某些活动。这种情况下的数据交换取决于应用程序的调用接口和工作流引擎的能力。
• 工作流引擎可能需要将工作流相关数据传递给应用程序，并在活动完成后接收应用程序数据。

这里是工作流引擎调用第三方系统时传递数据以及接受数据的情况。一般第三方系统都会提供API，工作流引擎可以通过POST方式传递数据给第三方系统，并通过这接口获取第三方系统返回的处理结果数据。

工作流引擎交换（Workflow Engine Interchange）：

该部分主要是接口4（Interface 4）：

• 在异质工作流执行服务中，不同的工作流引擎可能需要交换活动或子过程的执行。这种情况下的数据交换可能需要通过一个网关机制来映射不同系统之间的对象命名和数据类型约定。
• 工作流引擎之间的数据交换可能涉及工作流相关数据的转换、名称映射和运行时信息的同步。

例如，厂商A的工作流引擎，有数据格式a、b、c、d来定义流程。而厂商B的工作流引擎，则有A、B、C、D来定义流程。如果两个不同产商的工作流引擎之间需要进行数据交换，那就得先维护一个映射关系来说明，厂商A的字段跟厂商B的字段哪些是映射相等的，哪些是不同的。

流程定义

流程定义工具

过程定义工具是指用于分析、建模、描述和记录业务过程的各种工具。这些工具可以是非常基础的（如纸和笔），也可以是高度复杂和正式的。过程定义工具的目的是创建一个过程模型，该模型能够被工作流管理系统在运行时解释和执行。这些工具可能包括：

• 业务过程分析工具：用于识别和记录业务需求、流程和规则。
• 建模工具：用于创建业务过程的图形表示，如流程图、状态图等。
• 文档编辑器：用于编写和维护过程定义的文档。
• 自动化工具：用于将手动定义的过程转换为可由工作流引擎执行的格式。

我们在软件上看到一个流程图，实际上是这个软件对流程的定义文件进行了一个解释渲染出来后的一个展示。例如我们经常用的word文档docx文件，我们用软件看到是很丰富的图文数据，其实它是一个xml的文件描述。例如下面的一个word文档其定义和解释。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:document xmlns:wpc="http://schemas.microsoft.com/office/word/2010/wordprocessingCanvas" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:wp14="http://schemas.microsoft.com/office/word/2010/wordprocessingDrawing" xmlns:wp="http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing" xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" xmlns:w14="http://schemas.microsoft.com/office/word/2010/wordml" xmlns:w10="urn:schemas-microsoft-com:office:word" xmlns:w15="http://schemas.microsoft.com/office/word/2012/wordml" xmlns:wpg="http://schemas.microsoft.com/office/word/2010/wordprocessingGroup" xmlns:wpi="http://schemas.microsoft.com/office/word/2010/wordprocessingInk" xmlns:wne="http://schemas.microsoft.com/office/word/2006/wordml" xmlns:wps="http://schemas.microsoft.com/office/word/2010/wordprocessingShape" xmlns:wpsCustomData="http://www.wps.cn/officeDocument/2013/wpsCustomData" mc:Ignorable="w14 w15 wp14"><w:body><w:p><w:pPr><w:rPr><w:rFonts w:asciiTheme="minorHAnsi" w:hAnsiTheme="minorHAnsi" w:eastAsiaTheme="minorHAnsi" w:cstheme="minorBidi"/><w:color w:val="00000A"/><w:sz w:val="24"/><w:szCs w:val="24"/><w:lang w:val="en-US" w:eastAsia="en-US" w:bidi="ar-SA"/></w:rPr></w:pPr><w:r><w:t>This is a word document.</w:t></w:r></w:p><w:p/><w:p><w:r><w:drawing><wp:anchor distT="0" distB="0" distL="0" distR="0" simplePos="0" relativeHeight="251659264" behindDoc="0" locked="0" layoutInCell="1" allowOverlap="1"><wp:simplePos x="0" y="0"/><wp:positionH relativeFrom="column"><wp:posOffset>41910</wp:posOffset></wp:positionH><wp:positionV relativeFrom="paragraph"><wp:posOffset>480695</wp:posOffset></wp:positionV><wp:extent cx="2266950" cy="923925"/><wp:effectExtent l="0" t="0" r="0" b="0"/><wp:wrapSquare wrapText="largest"/><wp:docPr id="1" name="Image1"/><wp:cNvGraphicFramePr><a:graphicFrameLocks xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main" noChangeAspect="1"/></wp:cNvGraphicFramePr><a:graphic xmlns:a="http://schemas.openxmlformats.org/drawingml/2006/main"><a:graphicData uri="http://schemas.openxmlformats.org/drawingml/2006/picture"><pic:pic xmlns:pic="http://schemas.openxmlformats.org/drawingml/2006/picture"><pic:nvPicPr><pic:cNvPr id="1" name="Image1"/><pic:cNvPicPr><a:picLocks noChangeAspect="1" noChangeArrowheads="1"/></pic:cNvPicPr></pic:nvPicPr><pic:blipFill><a:blip r:embed="rId6"/><a:stretch><a:fillRect/></a:stretch></pic:blipFill><pic:spPr><a:xfrm><a:off x="0" y="0"/><a:ext cx="2266950" cy="923925"/></a:xfrm><a:prstGeom prst="rect"><a:avLst/></a:prstGeom></pic:spPr></pic:pic></a:graphicData></a:graphic></wp:anchor></w:drawing></w:r><w:r><w:t xml:space="preserve">This is a </w:t></w:r><w:r><w:fldChar w:fldCharType="begin"/></w:r><w:r><w:instrText xml:space="preserve"> HYPERLINK &quot;http://example.com/&quot; \h </w:instrText></w:r><w:r><w:fldChar w:fldCharType="separate"/></w:r><w:r><w:rPr><w:rStyle w:val="12"/></w:rPr><w:t>link</w:t></w:r><w:r><w:rPr><w:rStyle w:val="12"/></w:rPr><w:fldChar w:fldCharType="end"/></w:r><w:r><w:t>.</w:t></w:r></w:p><w:p/><w:p/><w:p/><w:p/><w:p/><w:p/><w:p/><w:p/><w:p><w:bookmarkStart w:id="0" w:name="_GoBack"/><w:bookmarkEnd w:id="0"/></w:p><w:sectPr><w:headerReference r:id="rId3" w:type="default"/><w:footerReference r:id="rId4" w:type="default"/><w:pgSz w:w="12240" w:h="15840"/><w:pgMar w:top="1440" w:right="1440" w:bottom="1440" w:left="1440" w:header="720" w:footer="720" w:gutter="0"/><w:pgNumType w:fmt="decimal"/><w:cols w:space="720" w:num="1"/><w:formProt w:val="0"/><w:docGrid w:linePitch="360" w:charSpace="0"/></w:sectPr></w:body></w:document>

工作流定义交换（Workflow Definition Interchange）

工作流定义交换是指在过程定义工具和运行时工作流管理软件之间的接口。这个接口允许过程定义在不同的工作流产品之间进行导入和导出。它包括：

• 交换格式：定义了如何在不同系统之间传递过程定义信息的格式。这可能包括XML、JSON或其他数据交换标准。
• API调用：提供了一组API命令，用于在工作流系统之间读取、写入或修改过程定义信息。

这里其实就类似说异构系统之间的数据交互问题。

元模型（Meta-Model）

为了实现过程定义的标准化交换，WfMC正在开发一个元模型，该模型能够表达过程定义中的对象、它们之间的关系和属性。这个元模型将作为交换格式的基础，并可能包括以下元素：

• 工作流类型定义：包括工作流名称、版本号、启动和终止条件等。
• 活动：包括活动名称、类型（子流程、原子流等）、前置和后置条件等。
• 转换条件：涉及流程或执行条件。
• 角色：涉及组织实体和角色。
• 被调用的应用程序：包括应用程序的通用类型或名称、执行参数、位置或访问路径等。

这里其实就是我们前面【流程建模】讲的那几部分内容。

API调用（API Calls）

WAPI（工作流应用程序编程接口）中将定义一组API命令，以支持对过程定义数据的访问。这些API命令可能包括：

• 会话建立：建立和断开参与系统之间的会话。
• 工作流定义操作：从存储库或其他源列表中检索工作流过程定义名称的列表或属性。
• 工作流定义对象操作：在工作流定义中创建、检索、删除对象，以及检索、设置和删除对象属性。

通过这些工具和接口，过程定义可以被标准化和共享，从而使不同的工作流管理系统能够相互协作，实现更加灵活和高效的业务流程管理。

其实就是说工作流的增删改查等接口定义问题。

工作流客户端功能

介绍了工作流系统中客户端应用程序与工作流引擎之间的交互。这部分内容强调了工作流客户端应用程序在用户与工作流管理系统之间的中介作用，以及它们如何通过标准化的接口与工作流引擎进行通信。

这里的客户端按现在话说其实就是浏览器，其实就是说Web前端提供的交互功能与后端的工作流系统实现通信。

工作流客户端应用程序（Workflow Client Applications）:

• 工作流客户端应用程序，也称为工作列表处理程序（worklist handler），是与最终用户进行交互的软件实体。它负责管理用户的工作列表，即由工作流引擎分配给特定用户（或用户组）的工作任务队列。
• 工作列表处理程序可以作为工作流管理产品的一部分提供，也可以由用户编写，以适应特定的业务需求或与多个不同的工作流应用程序一起使用。
• 工作流客户端应用程序与工作流引擎之间的交互通过一个明确的接口进行，该接口包括工作列表的概念，即由工作流引擎为特定用户分配的任务队列。

工作流客户端应用程序接口（Workflow Client Application Interface，Interface 2）:

• 定义了一组API（应用程序编程接口），使得客户端应用程序可以一致地访问工作流引擎和工作列表，无论实际产品实现的性质如何。
• API调用和参数将映射到几种不同的通信机制上，以适应工作流实现模型的多样性。
• 提供了一系列命令，用于对单个或集体的流程或活动实例进行操作，以及对工作列表进行操作。

API命令的类型（Types of API Commands）:

• 会话建立：建立和断开参与系统之间的会话。
• 工作流定义操作：检索工作流过程定义名称或属性的列表。
• 流程控制函数：创建、启动、终止单个流程实例。
• 流程状态函数：获取流程或活动实例的详细信息。
• 工作列表/工作项处理函数：打开和关闭工作列表查询，获取工作列表项，通知工作项的选择、重新分配或完成。
• 过程监管功能：在监管特权级别下操作所有流程或活动实例的功能。

应用程序调用（Application Invocation）:

• 工作列表处理程序可能需要直接或在最终用户的控制下激活工作列表中的单个工作项。这可能涉及到启动应用程序并将工作流相关数据与工作项关联起来。
• 工作列表处理程序可能需要与多个不同的工作流引擎和执行服务进行交互，以管理和执行分配给用户的任务。

通过这些功能，工作流客户端应用程序为用户提供了一个与工作流管理系统交互的界面，使用户能够查看、管理和执行他们的工作任务。同时，这也为不同的工作流产品提供了一个标准化的交互方式，有助于提高工作流技术在不同环境和平台之间的互操作性和集成性。

被调用的应用程序功能

它涉及工作流引擎如何与外部应用程序交互以及如何调用这些应用程序来执行特定的工作流活动。以下是对3.6节内容的展开：

被调用的应用程序（Invoked Applications）:

• 工作流管理系统（WFM）中的工作流引擎需要与各种IT应用程序和工具交互，以便执行工作流中的活动步骤。这些被调用的应用程序可能包括文档编辑器、数据库系统、电子邮件客户端等。
• 工作流引擎通过使用标准接口来激活这些应用程序，从而允许工作流技术与多种类型的应用程序集成，而不需要对每个应用程序进行特定的硬编码。

应用程序调用接口（Invoked Applications Interface，Interface 3）:

• 定义了工作流引擎与被调用应用程序之间的接口，包括应用程序代理（application agents）和设计为“工作流启用”的应用程序，这些应用程序可以直接与工作流引擎交互。
• 接口提供了一组标准化的API和数据交换格式，使得工作流引擎可以启动应用程序、传递数据，并接收应用程序执行的结果。

应用程序调用的API命令（API Commands for Application Invocation）:

• 会话建立：建立和断开应用程序或应用程序代理的会话。
• 活动管理功能：工作流引擎向应用程序发送开始、暂停/恢复、中止活动的命令。
• 数据处理功能：在活动执行前向应用程序提供工作流相关数据，以及在活动执行后从应用程序获取数据。

应用程序调用的复杂场景（Complex Scenarios for Application Invocation）:

• 在异构工作流引擎之间进行工作流互操作时，可能需要在工作流引擎之间传递应用程序调用信息，这可能是运行时交换的一部分，或者是在流程开发阶段之后导入（部分）过程定义。
• 描述了几种可能的应用程序调用接口类型，并讨论了标准化这些接口的可能性。

通过这些功能和接口，工作流系统能够灵活地与现有的IT应用程序集成，扩展工作流技术的应用范围，并提高业务流程自动化的效率。这种集成允许工作流引擎根据工作流的逻辑和规则动态地调用和控制外部应用程序，从而实现复杂的业务流程自动化。

这里说的其实是调用第三方系统的事情。

工作流互操作性

这是工作流管理系统中不同产品和系统之间能够无缝协作和交换信息的能力。这一部分详细讨论了如何在不同的工作流系统之间实现互操作性，以及如何通过标准化来促进这种协作。但落到具体商业化产品上，其实是很难实现的目标，毕竟各个厂商都有自己的考虑。

以下是对3.7节内容的展开：

异构工作流执行服务（Heterogeneous Workflow Enactment Services）:

• 工作流产品具有多样性，从用于任务或数据的临时路由到用于高度规范化的生产流程的系统。
• 工作流联盟的目标是定义标准，使得不同供应商生产的工作流系统能够无缝地在彼此之间传递工作项。

互操作性模型（Interoperability Models）:

• 描述了四种可能的互操作性模型，覆盖了从简单任务传递到完整工作流应用互操作性的不同级别。
• 这些模型包括：连接离散（Chained）、层次嵌套（Nested Subprocesses）、连接不明确（Peer-to-Peer）、并行同步（Parallel Synchronised）。

连接离散（Chained）

• 这个模型允许在一个工作流中的某个点连接到另一个工作流中的另一个点。这种连接通常是线性的，从一个工作流的活动直接传递到另一个工作流的活动。
• 例如，工作流A的某个活动（A5）完成时，会触发工作流B中的一个活动（B1）。这两个活动之间的连接是线性的，活动A5的输出直接作为活动B1的输入。
• 这种模型适用于简单的任务传递，其中两个工作流之间的交互是预定义和直接的。

层次嵌套（Nested Subprocesses）

• 在这个模型中，一个工作流的过程可以被完全封装为另一个工作流中的一个单一任务。这种封装创建了一个层次关系，其中父流程包含了子流程。
• 例如，工作流服务A中的一个活动（A3）被定义为在工作流服务B中执行的完整过程（B）。当活动A3在服务A中被执行时，它实际上是启动了服务B中的整个过程B，并且一旦过程B完成，控制权就会返回给服务A。
• 这个模型允许在不同的工作流服务之间创建复杂的嵌套关系，其中子流程可以在父流程的上下文中执行。

连接不明确（Peer-to-Peer）

• 这个模型允许在多个工作流服务之间创建一个混合环境，其中多个活动可以在不同的工作流服务上执行，形成一个共享的领域。
• 例如，一个复合过程C可能包括由服务A协调的活动C1、C2和C5，以及由服务B协调的活动C3、C4和C6。
• 这种模型要求两个工作流服务支持共同的API集进行通信，并且都能够解释一个共同的过程定义。这可能需要在工作流服务之间传递工作流相关数据和应用程序数据。

并行同步（Parallel Synchronised）

• 这个模型允许两个过程基本上独立运行，可能是在不同的工作流服务上，但要求在两个过程之间存在同步点。
• 例如，两个工作流服务A和B，它们中的活动A3和B4之间存在同步点。当两个活动分别到达预定义的同步点时，会触发一个共同的事件。
• 这种模型需要一个事件协调和跟踪机制，以及两个服务都能够识别来自两个过程定义的任务。

WAPI互操作性功能（WAPI Interoperability Functions，Interface 4）:

WAPI允许不同的工作流执行服务之间进行交互和协作。这些功能是通过WAPI（Workflow Application Programming Interface）实现的，它是工作流系统中用于不同组件之间通信的标准接口。以下是Interface 4中包含的关键功能和概念的展开说明：

1. 活动或子过程调用（Activity or Sub-process Invocation）:

   • 这个功能允许一个工作流执行服务（Workflow Enactment Service）请求另一个服务执行一个特定的活动或子过程。这涉及到启动和控制跨工作流服务的工作项。

     这里就是前面我们介绍的【回调接口】或者【审批】应用节点，前者或生产一个URL接口供外部调用，后者可以通过审批API调用。
     

2. 过程/活动状态控制（Process/Activity Status Control）:

   • 工作流执行服务可以通过WAPI调用来查询或修改跨服务的工作流实例或活动的状态。这可能包括暂停、恢复、挂起或终止工作流实例的能力。

     就是API开放接口
     

3. 应用程序/工作流相关数据传输（Application/Workflow Relevant Data Transfer）:

   • 这个功能使得工作流执行服务能够传递工作流相关数据，这些数据对于工作流的执行至关重要。这可能包括在不同工作流服务之间传递数据，以便它们可以协调工作流实例的不同部分。

     数据传递可以通过接口、数据库、文件、环境变量等方式传递，具体可以参考后面《数据管理机制》章节的内容。
     

4. 同步点协调（Synchpoint Coordination）:

   • 在需要多个工作流服务协同工作的场合，同步点协调功能允许服务之间同步它们的进度。例如，当一个工作流实例需要等待来自另一个服务的数据或事件时，可以使用同步点来确保流程的一致性和协调性。

5. 过程定义读写（Process Definition Read/Write）:

   • 为了实现跨服务的互操作性，可能需要读取或写入工作流定义。这个功能允许工作流执行服务访问、更新或共享工作流定义，以便在不同的执行环境中重用或集成。

通过Interface 4，工作流系统可以实现更高层次的集成和协作，允许它们共享工作流实例、数据和控制信息。这种互操作性对于构建跨组织边界的复杂业务流程至关重要，因为它允许不同的IT系统和应用程序无缝地协同工作，以支持整个企业的操作。

使用过程定义跨多个域（Use of Process Definitions across Multiple Domains）:

指在不同的工作流执行服务或系统之间共享和应用过程定义的能力。这一概念对于实现工作流系统的互操作性至关重要，因为它允许不同来源的工作流组件能够理解和执行同一个业务流程。以下是对这一概念的展开说明：

1. 共享过程定义视图和属性（Shared View of Process Definitions）:
   • 当不同的工作流执行服务能够解释一个共同的过程定义时，它们可以共享关于过程对象（如活动、角色、转换条件等）的视图和属性。这种共享视图使得各个工作流引擎可以在保持一致性的同时，独立地执行业务流程的不同部分。
2. 过程定义的导入和导出（Process Definition Import/Export）:
   • 过程定义的导入和导出功能允许工作流系统在不同的执行环境中传递和应用过程定义。这可能涉及到将过程定义从一个系统导出，然后在另一个系统中导入，以便在那里执行业务流程的特定部分。
3. 网关方法（Gateway Approach）:
   • 如果无法直接共享过程定义，可以通过网关方法实现互操作性。在这种方法中，一个网关应用或服务充当中介，将一个系统的命名约定、对象模型和数据格式映射到另一个系统。这样，即使两个系统使用不同的过程定义格式，它们也能够相互理解和协作。

通过使用过程定义跨多个域，组织可以实现更广泛的业务流程集成和自动化。

运行时控制交互（RunTime Control Interactions）:

• 在运行时，WAPI调用用于在不同的工作流服务之间传递控制信息，以执行特定的子流程或活动。
• 如果两个服务支持共同的WAPI调用和过程定义对象视图，则可以直接在工作流引擎之间进行交互。
• 对于不支持共同WAPI调用的服务，可以通过构建网关功能来提供两个工作流服务之间的互操作性。

总体而言，工作流互操作性是一个涉及多个方面和层次的复杂主题，它要求在不同工作流产品和系统之间建立共同的理解和通信标准。通过实现这些标准，可以提高工作流技术在不同环境和平台之间的灵活性和可用性，从而为用户提供更加强大和高效的业务流程管理解决方案。

这个互操作性从现在看其实是失败的，各个厂商都按照自己的标准来实现。

管理监控工具

讨论了工作流管理系统中与系统管理和监控相关的功能和接口。

管理和监控工具 (Administration & Monitoring Tools)

• 描述了工作流管理系统中需要的管理和监控工具，这些工具可以跨越多个工作流服务，共享常见的管理和监控功能。
• 强调了对于整体状态监控和提取度量信息的需求，以及对于安全性、控制和授权的具体考虑。

管理和监控接口 (Administration & Monitoring Interface)（Interface 5）

• 介绍了一个独立的管理应用程序与不同的工作流域进行交互的接口模型。
• 管理应用程序可以是某个工作流服务的一部分，也可以跨越多个异构工作流域进行管理。
• 描述了典型的功能区域，如用户管理、角色管理、审计管理、资源控制和流程监管等。

功能区域 (Typical Functional Areas)

• 用户管理操作：包括用户的权限建立、删除、暂停、修改等。
• 角色管理操作：涉及角色与参与者关系的设定、删除、修改，以及角色属性的设置和取消。
• 审计管理操作：包括查询、打印、启动新的或删除审计跟踪和事件日志等。
• 资源控制操作：涉及设置、取消、修改进程或活动并发级别，以及查询资源控制数据（计数、阈值、使用参数等）。
• 流程监管功能：包括更改工作流进程定义或现有进程实例的操作状态、启用或禁用特定版本的进程定义、更改指定类型的所有进程或活动实例的状态、为所有进程或活动实例分配属性、终止所有进程实例等。
• 进程状态功能：包括开启/关闭进程或活动实例查询、获取进程实例或活动实例的详细信息、获取特定（单独）进程或活动实例的详细信息等。

该章节强调了为了实现跨多个工作流服务的共同管理和监控功能，需要一个标准化的接口。这个接口将允许管理应用程序以统一的方式与不同的工作流引擎进行交互，从而提供一致的管理和监控功能。此外，还提到了进一步研究的意向，包括对接口细节的探讨，以及如何利用现有的协议机制（如CMIP和SNMP）来设置和检索管理状态和统计信息。