GB/T 32393-2015 信息技术 工作流中间件 参考模型和接口功能要求
- 名 称：GB/T 32393-2015 信息技术 工作流中间件 参考模型和接口功能要求 - 下载地址1
- 下载地址：[下载地址1]
- 提 取 码：
- 浏览次数：3
发表评论 加入收藏夹 错误报告目录| 新闻评论（共有 0 条评论） |
资料介绍
ICS 35. 060 L 74
中 华 人 民 共 和 国 国 家 标 准
GB/T 32393—2015
信息技术 工作流中间件参考模型和接口功能要求
Information technology—Workflow middleware—
Referencemodeland interface functionalrequirement
2015-12-31发布 2015-12-31实施
中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会
发
布
GB/T 32393—2015
GB/T 32393—2015
前 言
本标准按照 GB/T 1. 1—2009给出的规则起草 。
本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归 口 。
请注意本文件的某些内容可能涉及专利 。本文件的发布机构不承担识别这些专利的责任 。
本标准起草单位 : 中创软件商用中间件股份有限公司 、中国电子技术标准化研究院 、北京东方通科技股份有限公司 、山东浪潮齐鲁软件产业股份有限公司 、华迪计算机集团有限公司 、北京炎黄盈动科技发展有限责任公司 。
本标准主 要 起 草 人 : 何 忠 胜 、陈 志 峰 、李 海 波 、李 春 青 、邓 鹏 飞 、王 洁 萍 、王 卫 国 、杨 丽 蕴 、贾 德 星 、程勇 、张燕生 。
信息技术 工作流中间件参考模型和接口功能要求
1 范围
本标准描述了工作流中间件参考模型和工作流中间件接口要求 。本标准适用于工作流中间件产品的开发 。
2 术语、定义和缩略语
2. 1 术语和定义
下列术语和定义适用于本文件 。
2. 1. 1
流程 process
一组具有共同 目的 、协调的 、并行和/或串行的活动 。 2. 1.2
流程定义 processdefinition
流程的计算机化表示 。
注 :流程包括人工定义和自动化的工作流定义 。
2. 1.3
子流程定义 sub-processdefinition
流程执行或调用的流程 ,包括该流程的工作流部分 。 2. 1.4
流程活动 processactivity
一项工作的逻辑步骤或描述 。
2. 1.5
工作流活动 workflow activity
有助于工作流完成的计算机自动操作逻辑步骤 。
2. 1.6
流程实例 processinstance
流程定义的实例示范 。
注 :流程实例包括人工实例和自动化的(工作流)实例 。
2. 1.7
流程执行 processexecution
一种流程状态 ,在此状态下 ,启动了工作流执行以支持流程 。 2. 1. 8
工作流 workflow
流程的全部或部分计算机化 。
GB/T 32393—2015
2. 1.9
工作流中间件 workflow middleware
一种系统 ,它全面负责定义 、管理 、执行 、监控和优化由软件执行的工作流 ;执行顺序由工作流逻辑产生 。
2. 1. 10
工作流执行服务器 workflow enactmentserver
一种软件服务器 ,它可以由一个或多个工作流引擎组成 ,用以创建 、管理和执行工作流实例 。是工作流管理系统的核心组成部分 。
2. 1. 11
工作流管理系统 workflow managementsystem
工作流管理系统是指工作流中间件 。
工作流管理系统与工作流中间件(见 2. 1. 9)同义 。
2. 1. 12
工作流引擎 workflow engine
一种软件服务器或软件 “引擎 ”,为工作流实例提供运行时期的执行环境 。
2. 1. 13
工作流执行 workflow execution
工作流中间件根据工作流定义创建并管理工作流实例 。
2. 1. 14
工作流实例 workflow instance
工作流定义的实例示范 ,仅包括流程实例的自动化部分 。
2. 1. 15
工作流活动实例 workflow activityinstance
工作流实例组成部分的流程活动实例示范 。
2. 1. 16
工作流参与者 workflow participant
一种资源 ,它部分或全部执行由工作流活动实例代表的工作 。
2. 1. 17
工作流应用 workflow application
一种软件 ,此种软件可以完全或部分支持推进某项工作 , 以达到工作流活动实例的目标 。
2. 1. 18
工作流控制数据 workflow controldata
由工作流中间件和/或工作流引擎管理的数据 。
2. 1. 19
工作流相关数据 workflow relevantdata
由工作流中间件用于确定工作流实例的状态转移情况的数据 。
注 :可以是按类划分的(引擎可以理解)或非按类划分的(引擎不可理解) 。
2. 1.20
应用数据 application data
不可以由工作流中间件访问的特定数据 。
2. 1.21
工作流应用编程接口 workflow application programminginterface;WAPI
指工作流应用和工具与工作流执行服务器之间的应用编程接 口 。
注 :工作流执行服务器提供此接口功能 。
2. 1.22
任务表处理器 worklisthandler
用于管理和格式化对工作流执行服务器的请求(以便获得任务项目表)的软件部件 。
2. 1.23
工具 tool
工作流中间件所涉及的工作流应用 。
2. 1.24
审计记录 audittrail
工作流实例从开始到最后完成的状态转移的历史记录 。
2. 1.25
转移条件 transition condition
流程实例的当前活动向下一个或多个活动移动或转移时所遵循的准则 。
2.2 缩略语
下列缩略语适用于本文件 。
API 应用编程接口(Application Programming Interfaces)
ORB 对象请求代理 (ObjectRequestBroker)
WAPI 工作流应用编程接 口 (Workflow Application Programming Interfaces)
3 工作流中间件参考模型
3. 1 参考模型
工作流中间件参考模型见图 1。
图 1 工作流中间件参考模型
工作流执行服务器 、流程定义工具 、工作流客户端应用 、被调用应用程序 、管理监控工具和其他工作流执行服务器是工作流中间件的主要组件 。 以工作流引擎为核心的工作流执行服务器是工作流中间件提供服务和管理调度的组件 ,它与流程定义工具 、工作流客户端应用 、被调用应用 、管理监控工具和其他工作流执行服务器通过各个接口交互 。这些接口包括流程定义交换接 口 (接 口 1) 、工作流客户端应用接口(接 口 2) 、被调用应用接口(接 口 3) 、工作流互操作接口(接 口 4) 、管理和监控接口(接 口 5) ,接口功能由工作流服务器提供 ,其中包含 WAPI信息和数据交换格式 。这些功能中很多是两个或两个以上接
口服务共有的 。通过 WAPI可以访问工作流执行服务器的服务 、管理工作流执行服务器与其他系统组件之间的交互 。WAPI可以看作是工作流执行服务器经由五个接口提供工作流管理服务的统一的服务接 口 ,而不是工作流服务器的五个单独的接 口 。
3.2 工作流执行服务器
3.2. 1 概述
工作流执行服务器为流程实例和活动实例提供运行环境 ,利用一个或几个工作流引擎解释和激活流程定义的一部分或全部 , 以及为处理各种活动与必要的外部资源进行交互 。
在工作流中间件参考模型中 ,构成工作流执行服务器的流程和活动控制逻辑与构成流程(与关联每个活动关联)的应用工具和末端用户 ,这两部分之间在逻辑上是分离的 。
工作流执行服务器通过以下任一接口访问外部资源 :
a) 客户端应用接 口 :
工作流引擎通过该接口与代表用户资源负责组织任务的任务表处理器进行交互 。任务表处理器负责从任务表中选择和推进任务项 。任务表处理器或末端用户可以控制应用工具的激活 。
b) 被调用应用调用接 口 :
该接口允许工作流引擎直接激活特定工具以执行指定活动 。典型的情况是 ,所调用的是一种没有用户接口的基于服务器的应用 ;在指定的活动使用一种要求末端用户交互的工具的情况下 ,通常是经由任务表接口调用 ,使用户任务进度安排更灵活 。
在分布式工作流执行服务器中 ,每个工作流引擎控制流程执行的一部分 ,并与该流程中由工作流引擎负责的各项活动涉及的用户和应用工具交互 。此类分布式工作流执行服务器中有公共的命名空间和管理范围 , 因此可以按一致的方式处理流程定义(或子流程定义) 和用户/应用名称 。 分布式工作流系统 ,在工作流引擎间采用特定协议和信息转换格式 ,用以同步工作流引擎间的操作 ,交换流程和活动控制信息 。工作流相关数据也可以在工作流引擎间传递 。在同构的工作流执行服务器中 ,此类操作由厂商设定 。
在涉及异构工作流执行服务器的情况下 ,工作流引擎间需要标准的交换格式 。使用接 口 4,执行服务器可以把活动或者子流程转移到另外一个(异构)执行服务器去执行 。在工作流中间件参考模型中 ,这种情况显示为工作流引擎之间的交换 。
在此类异构环境下 ,还可能要求公共的管理和监控功能给予支持 。
3.2.2 工作流引擎
工作流引擎负责工作流执行服务器中部分(或者全部)运行时期控制环境 。
工作流引擎主要用以 :
a) 解释流程定义 ;
b) 控制流程实例 ,包括实例的创建 、激活 、挂起 、终止等 ;
c) 为流程活动导航 ,可能涉及顺序或并行操作 、设定截止期限 、解释工作流相关数据等 ;
d) 支持特定参与者登录和退出 ;
e) 确定用户关注的任务项和用于支持用户交互的接 口 ;
f) 维护工作流控制数据和工作流相关数据 ,与应用或用户往来传递工作流相关数据 ;
g) 提供调用外部程序的接 口 ,链接任何工作流相关数据 ;
h) 为控制 、管理和审计提供监控功能 。
工作流引擎可以控制定义范围内的流程集 、子流程或实例的执行 。执行何种 , 由对象类型的范围及对象的属性确定 。
在一个由多个工作流引擎构成的工作流执行服务器中 ,流程划分给各个工作流引擎执行 。若按流程类型划分 ,一个引擎控制一个特定类型的流程 ;若按功能分配 ,每一个工作流引擎控制一个流程的某些部分 ,这些部分要求确定在其控制范围内用户或资源所处的位置 。
3.2.3 同构和异构工作流执行服务器
同构工作流执行服务器由一个或多个兼容的工作流引擎组成 。这些工作流引擎使用确定的一组流程定义属性为工作流流程提供运行时期执行环境 。用以在各种工作流引擎上对流程执行进行组织的机制以及用于支持这种组织的协议和交换格式 , 随产品而定 。
异构工作流执行服务器是由两个或者多个不同的同构工作流执行服务器组成 。这些同构工作流执行服务器在规定的符合性级别上遵循共同的互操作性标准 。
异构工作流执行服务包括但不限于以下要求 :
a) 覆盖该异构范围的公共命名方案 ;
b) 在该范围上支持公共流程定义对象和属性 ;
c) 在该范围上支持工作流相关数据 ;
d) 支持流程 、子流程或者活动在异构工作流引擎间的传递 ;
e) 在该范围上支持公共的管理和监控功能 。
为支持异构工作流执 行 服 务 器 间 的 全 面 开 放 式 交 互 , 需 要 对 公 共 工 作 流 控 制 数 据 及 其 交 换 给 予支持 。
3.2.4 WAPI和交换
WAPI和交换功能是工作流执行服务器在其与其他资源和应用交互的范围内支持的一组 API调用和数据交换功能 。
WAPI的主要功能包括 API调用以及设定的若干参数集合和相应的代码 ,此外 , WAPI还定义数据交换格式 。
3.2.5 工作流控制数据、工作流相关数据和应用数据
工作流执行服务器通过维护工作流控制数据以确定流程实例或活动实例的状态 ,并且可以支持其他内部状态信息 。工作流控制数据不能使用 WAPI命令访问或交换 ,但是有些信息内容可以在响应某些特殊命令(如 ,查询流程状态等)时提供 。 同构工作流执行服务器可以通过使用特定内部对话在工作流引擎间交换信息 。
工作流中间件通过工作流相关数据确定指定的转移条件 ,并且可能影响到对待执行的下一步活动的选择 。此类数据可由工作流应用访问 , 以便就该数据进行操作 , 因此可能需要通过工作流执行服务器在活动之间传递该数据 。在异构环境下操作时 ,此类数据可能需要在工作流引擎之间传递 ,在这种情况下 ,流程执行序列在两个或多个工作流引擎上展开 ;该流程可能要求名称映射或数据变换 。
流程定义中的每个活动中可能都要(例如 ,通过特定工具或应用)进行应用数据操作 ,这种操作在应用直接控制下进行 ,或结合某种形式的用户交互进行 。
应用数据不是供工作流执行服务器使用的 ,只在工作流执行期间与应用或用户任务相关 。就像工作流相关数据一样 ,应用数据可能需要在某个异构执行服务器中的工作流引擎间传递(或变换) ,从而可供各个工作流引擎上执行的相应的活动使用 。
3.2.6 数据交换
为支持经由以下三个接口的交互 ,需要在 WAPI上交换工作流相关数据和应用数据 :
a) 任务表处理器(在接 口 2 中调用) ;
b) 调用应用(在接 口 3 中调用) ;
c) 工作流引擎互操作(在接 口 4 中调用) 。
由电子邮件驱动的工作流中间件是一种典型的应用数据直接交换 。在此类系统中 ,应用数据在应用驱动的或用户驱动的活动之间实际传递 。在此情况下 ,不需要明确定义活动与应用数据间的关系 ;应用数据作为标准工作流活动导航的一部分传递 ,并且 ,在调用应用时 ,在本地链接到该应用 。需要在活动间提供数据格式变换时 ,特定应用可以作为与之关联的某种属性定义数据类型 。从而使工作流中间件能够在针对相应的应用定义的类型属性的基础上 ,使用异构工作流应用来支持数据变换 。
对于对象命名和访问权限 , 同构系统可能采用专用的约定 ,而异构系统需要公共的方案 。在这种情况下 ,流程定义要包含通往应用数据对象存储器的访问路径 ,或者 ,活动间的导航针对要在活动之间传递的任何数据对象 ,传递必要的访问路径指示 。
异构工作流中间件之间的交互 ,需要遵循相同的应用数据交换方法 ,或通过网关机制交互 。这种网关机制可以通过适当的约定 ,在两种方法之间映射 ,处理对象命名和数据类型变换中的差异 。
应用数据或相关数据交换通过三个接口处理 , 以下是关于处理中的一些操作选项 :
a) 客户端应用接 口 :
工作流相关数据可以嵌入任务项 ,并且从任务表中提取后呈现给用户或链接到特定应用工具 。工作流相关数据也可以通过共享的对象存储形式间接传递特定应用(例如 ,使用公共文件夹在应用之间传递数据 ,或者将特定文件夹引用嵌入任务项中予以传递) 。
b) 被调用应用接 口 :
依据应用调用接口的性质进行数据交换 ,可能需要在调用服务时把数据包含在具体应用协议中 。用于读/写工作流相关数据的 API适宜于工作流支持的特定应用 ,也适宜于形成一般性应用代理 。
c) 工作流引擎互操作接 口 :
需要考虑的事项与客户端应用接口类似 ,不过 ,在不同系统之间支持不同应用数据交换方法的情况下 ,需要使用网关功能在两种方法间进行映射 ,并处理名称问题 。
3.3 流程定义工具
在工作流中间件生产自己的流程定义工具的情况下 ,所产生的流程定义一般保留在该系统范围内 ,这些流程定义可以或者不可以经由编程接口访问进行读 、写 。在分别使用单独的工具和系统来定义和执行流程的情况下 ,这些流程定义可以根据需要进行传递并存储在单独的数据库里供这些工具和系统以及其他开发工具访问 。
4 工作流中间件接口
4. 1 流程定义交换接口
流程定义交换接口见图 2。在建模和定义工具与工作流中间件间的接口是流程定义出 、入 口 。 这个接口实质上是一种交换格式和 API调用 ,可以支持互换流程定义信息 。这个接口支持互换完整的流程定义或其子集(如 ,该流程定义中的流程定义变更集合或特定活动属性集合) 。
图 2 流程定义交换接口
标准化的流程定义在构建环境与运行环境之间设定分隔点 ,使一个建模工具生成的流程定义可以用于多个工作流中间件的输入 ,并且 ,使得流程定义可能输出给若干不同的工作流中间件 ,从而支持这些系统协同工作 , 以提供一种分布式执行服务器 。
元模型和 API调用支持标准化的流程定义 。
元模型可用于表述 流 程 定 义 中 的 对 象 、对 象 间 的 关 系 和 对 象 的 属 性 , 可 以 作 为 一 组 交 换 格 式 的基础 。
工作流中间件之间的或工作流中间件与流程定义工具之间的 WPI调用(WAPI内) 为访问工作流流程定义提供共同访问方法 。
a) 基本元模型 :
基本元模型用于流程定义的元模型标识一组与简单流程定义的初始交换水平对应的基本对象类型 。 随着对象类型的增加或定义更多的符合性级别 ,可能要补充交换功能 。
元模型中定义的各类部件及其主要属性描述如下 :
1) 工作流类型定义 :
● 工作流流程名 ;
● 版本号 ;
● 流程开始/结束条件 ;
● 安全 、审计或其他控制数据 。
2) 活动 :
● 活动名 ;
● 活动类型(子流动 、最小流动等) ;
● 前置和后置活动条件 ;
● 其他调度约束 。
3) 转移条件 :
● 流动或执行条件 。
4) 工作流相关数据 :
● 数据名与路径 ;
● 数据类型 。
5) 角色 :
● 名称与组织实体 。
6) 被调用应用 :
● 一般类型或名称 ;
● 执行参数 ;
● 位置或访问路径 。
b) 访问流程定义 API:
WAPI中的 API命令集用于支持访问流程定义数据 , 以下描述命令集的一些通用功能 。各项命令按列表操作 ,或者针对各个对象或属性操作 。
1) 建立会话 :
● 连接/断开参与系统间的会话 。
2) 工作流定义操作 :
● 从流程定义库或者其他源列表检索工作流流程定义名称列表 ;
● 选择/取消选择工作流流程定义为后续对象层操作提供会话句柄 ;
● 读/写顶层工作流流程定义对象 。
3) 工作流定义对象操作 :
● 创建 、检索和删除工作流定义中的对象 ;
● 检索 、设置和删除对象的属性 。
4.2 工作流客户端应用接口
4.2. 1 工作流客户端应用
在工作流中间件参考模型中 ,客户端应用与工作流引擎之间通过一个采用工作表概念的接口进行交互 。按此概念 ,工作流引擎给特定用户(或公共用户组)分配任务项队列 。在最简单层上 ,工作流引擎可以访问任务表 , 以分配任务项 ,任务表处理器可以访问任务表 , 以检索任务项供用户进行处理 。
可以在工作流客户应用或末端用户控制下激活任务表中各个任务项(如 ,启动应用和链接工作流相关数据) 。在工作流客户端应用与工作流执行服务器间定义若干规程 ,用以支持向任务表增加新的任务项 ,从任务表中删除完成的活动 , 临时挂起活动等 。
可以通过任务表处理器处理应用调用 。这种处理可以直接进行 ,也可以在末端用户控制下进行 。
与任务表关联的活动相关数据是任务表处理器调用相应的应用时所需的信息 。在应用数据按类型划分的情况下 ,与数据的关联状态可以存储在任务表处理器中 ,供调用时使用 。在其他情况下 ,任务表处理器与工作流引擎间需要交换完整的应用名称和地址信息 。在这种情况下 ,工作流客户端应用接 口也实现被调用应用接 口 ( 即接 口 3)中的一些功能 , 以获取必要的信息 。
任务表可能包含与一个流程中的几个不同实例相关的若干任务项 , 和(或) 包含来自几个不同流程中的活动的各个任务项 。一个任务表处理器可能要与几个不同的工作流引擎或不同的工作流执行服务器交互 。
工作流客户端应用与工作流引擎间的接口需要灵活地使用以下各项内容 , 以容纳各种实现方法 :
a) 流程和活动标识符 ;
b) 资源名和地址 ;
c) 数据引用和数据结构 ;
d) 可选择的通讯机制 。
4.2.2 工作流客户端应用接口
满足上述需求的方法是提供一组标准的 API(WAPI) ,从而为从工作流客户端应用到工作流引擎和任务表的访问提供与产品实现性质无关的一致的访问方式 。
API及其参数可以映射到替代通信机制上 , 以适应各种工作流实现模型 。
工作流客户端应用接口概念图见图 3。
图 3 工作流客户端应用接口
下面按不同功能领域分类描述工作流客户端应用接口命令 。各功能领域的命令用于针对单个流程 、或流程集合 、活动实例 、任务表管理的操作 。
a) 会话建立 :
● 连接/断开参与系统间的会话 。
b) 工作流定义操作 :
● 检索/查询工作流流程定义名称或者属性 。
c) 流程控制 :
● 创建/启动/终止流程实例 ;
● 挂起/唤醒流程实例 ;
● 强制变更流程实例或活动实例中的状态 ;
● 分配或查询流程实例或活动实例的属性 。
d) 流程状态 :
● 开启/关闭流程实例或活动实例的查询 ,设置过滤条件 ;
● 提取流程实例或活动实例的详细信息 ,按规定过滤 ;
● 提取特定流程实例或活动实例的详细信息 。
e) 任务表/任务项处理 :
● 开启/关闭任务表查询 ,设置过滤条件 ;
● 提取任务项 ,按规定过滤 ;
● 任务项选择/重分配/结束通知 ;
● 分配或查询任务项属性 。
f) 流程监控 :
● 变更工作流流程定义及当前流程实例的操作状态 ;
● 变更特定类型的所有流程实例或活动实例的状态 ;
● 为特定类型的所有流程实例或活动实例的属性赋值 ;
● 终止所有流程实例 。
g) 数据处理 :
● 检索/返回工作流相关数据或应用数据 。
除以上所述功能外 , 某 些 工 作 流 客 户 端 应 用 需 要 对 WAPI上 的 附 加 管 理 功 能 提 供 支 持 , 即 管 理功能 。
以上所述功能为任务表处理器调用应用提供基本支持功能 。
4.3 被调用应用接口
一些可能的应用调用接口类型见表 1。
表 1 应用调用接口
被调用应用接口(接 口 3)范围见图 4。此接口可用于指定为 “所支持的工作流 ”(即直接与工作流引擎交互)的应用和应用代理 。
图 4 被调用应用接口
在简单情况中 ,工作流引擎在本地处理应用调用 ,通过使用流程定义中的信息来确定活动的性质 、所要调用的应用类型和数据需求 。被调用应用可能是工作流引擎本地的 、与工作流引擎共同驻留于同一个平台的 ,或者是在一个独立网络可访问平台上的 。 流程定义包含为调用该应用所需的应用类型信息和寻址信息 。在这种情况下 ,工作流引擎与流程定义之间关于应用命名和寻址的约定在本地定义 。
以下描述一组可能适用于应用调用功能的命令 。
a) 会话建立 :
● 连接/断开应用(或应用代理)会话 。
b) 活动管理 :
(工作流引擎到应用)
● 启动活动 ;
● 挂起/恢复/放弃活动(异步应用接口适用) ; (应用到工作流引擎)
● 活动完成通知 ;
● 预示事件(如同步) ;
● 查询活动属性 。
c) 数据处理功能 :
● 提供工作流相关数据(给应用的活动前数据 、来自应用的活动后数据) ;
● 提供应用数据或数据地址 。
更复杂的涉及异构工作流引擎间交互的场景 ,可能需要在工作流引擎间传递应用调用信息 ,这种传递既可以作为运行时期交换的一部分也可以通过在流程开发阶段后导入流程定义的方式执行 。
4.4 工作流互操作接口
4.4. 1 互操作模式
工作流中间件的 WAPI有 4种互操作模式 ,它们覆盖多种不同级别的能力 。
a) 链接模式 :
链接模式如图 5所示 。流程 A 的一个节点 , 连接到流程 B 的一个节点 。 两个连结点 ,一个是流程的终止点 ,一个是另一个流程的起始点 。这些连结点可以是流程中任何位置 ,只要在这里通过连接这两点能建立基本流程 。
图 5 链接模式
此模式支持在两个工作流环境之间传递单一任务项(或流程实例 、活动实例) ,然后在第二个环境中独立执行 ,不需要同步 。此类模式可以通过网关应用功能 、处理数据格式约定 、流程和活动名映射等方式实现 ,也可以将其纳入一个工作流执行服务器中 ,例如 ,两个工作流执行服务器使用同一个标准 API
调用的情况下 。
b) 子流程嵌套模式 :
子流程嵌套模式如图 6所示 。此类模式支持嵌套的流程执行 , 即一个特定工作流执行服务器中执行的某个流程可以完全封装到另一个工作流执行服务器中执行的某个流程(上层流程) 中 ,作为后者的一项任务 。前一个流程(即嵌套的流程)与后一个流程(上层流程)之间存在层次关系 ,嵌套的流程在效果上是上层流程的子流程 。这种分层关系可以在不同流程上显现 , 即形成一系列嵌套的子流程 。此种模式可以迭代应用 ,也可以不迭代 。
图 6 嵌套子流程模型
c) 对等模式 :
对等模式如图 7所示 。此模式支持全混合环境 。 图 7 中示出一个综合流程 C, 它包含那些可以在多个工作流执行服务器上执行的活动 ,形成一个共享域 。活动 C1 、C2 和 C5 可能由工作流引擎 A(或同一个领域里几个同构的工作流引擎)协调 ,而活动 C3、C4 和 C6 由工作流引擎 B协调 。
在这种模式中 ,流程是透明地从一个任务到另一个任务推进 ,必要时 ,在工作流引擎间交互 。
图 7 对等模式
按这种模式 ,需要这两个工作流执行服务器支持共同的 API集合 ,用于彼此通信 ;需要这两个工作流执行服务器能解释公共的流程定义 — 既可能是导入这两个工作流服务器的流程定义(用以构成公共流程) ,也可能是从它们导出的流程定义 。还可能需要在不同的异构工作流引擎之间传递工作流相关数据和应用数据 。
d) 并行同步模式 :
并行同步模式如图 8所示 。这种模式允许两个流程在分开的工作流执行服务器上进行实质上的独立运行 ,只需要在两个流程间设置同步点 。每个流程达到其执行序列中的预定点时 ,就触发一个公共事件 ,从而实现流程间同步 。这种机制有利于一些功能的实现 ,如 ,在一些并行执行线程上安排流程进度 、核查回复数据或者在不同流程实例之间传递工作流相关数据 。 图 8 中示出流程 A 内的活动 A3 与流程B 内的活动 B4 之间的同步关系 。
图 8 并行同步模式
在每个流程中特定点上可以同步配对的任务 。此中模式的实现需要事件协调和跟踪机制予以支持 , 以便能确认来自两个流程定义的任务 。
4.4.2 工作流互操作接口描述
异构工作流中间件之间的信息和控制流的一般性质如图 9所示 。
图 9 工作流互操作接口
工作流互操作性的两个主要方面是 :
● 需要并且能够实现的对流程定义(或其子集)做共同解释的程度 ;
● 在运行时期 ,支持各种控制信息的交换和在不同的工作流执行服务器之间传递工作流相关数据和(或)应用数据 。
a) 跨多域使用流程定义 :
在两个工作流执行服务器能够解释一个公共的流程定义的情况下 ,例如 ,从公共的流程定义池生成特定的流程定义 ,这两个工作流执行服务器就能共享关于这个流程定义的对象和属性的视图 ,其中可能包含活动 、应用 、组织和角色名称 、导航条件等 。从而可能支持各个工作流引擎在一个公共的命名和对象模型的上下文环境中 ,把活动或子流程传递给异构工作流引擎去执行 。 这种方法特别适合上述第 3种互操作模式 。
在流程定义视图共享不可行的情况下 ,可以作为运行时期交换的组成部分 ,“导出 ”流程定义子集的详细信息 。流程定义交换 API提供一种向特定工作流执行服务器请求对象 、属性等数据的方法 ,使得工作流引擎能够获取与在合作执行环境中分配给它的活动或子流程相关的流程定义数据 。
在上述方法都不可行的情况下 ,使用网关实现互操作 。通过一个应用交互网关 ,把对象名称和属性(通常是它们的子集)在两个工作流执行服务器间映射 。在最简单的情况下 ,两个单独的工作流执行服务器使用各自的流程定义格式 ,在网关中映射 。 这种方法不适于较简单的模式 1 和模式 2 以及模式 4的大部分实现 。
b) 运行时期控制交互 :
在运行时期 ,WAPI调用用于工作流执行服务器之间的传递控制 , 以便在特定服务器上发布子流程或单个活动 。在两个服务器都支持共同的 WAPI调用和公共的流程定义对象视图(包括命名约定和工作流相关数据或应用数据)的情况下 ,将直接在工作流引擎间传递控制 ,不过 ,需要公共协议支持 WAPI原语 。
若非上述情况 ,可以使用 WAPI调用构建网关功能 ,通过在两个工作流执行服务器之间映射不同的对象和数据视图并且(必要时)支持每个工作流执行服务器的不同协议环境 , 为两个工作流执行服务器提供交互能力 。
图 10 使用 WAPI的网关操作
图 10 中示出了网关操作主要原理 :依据特定交互场景 ,将域 A 的一个活动映射到域 B 的新的流程或子流程的一个活动 。
有很多 WAPI命令可以用于支持互操作 , 既可以通过两个工作流执行服务器之间的直接调用 ,也可以通过网关功能执行 。 以下功能覆盖的一些 WAPI命令适用于支持工作流互操作 :
● 会话建立 ;
● 对工作流定义及其对象的操作 ;
● 流程控制和状态 ;
● 活动管理 ;
● 数据处理操作 。
一旦活动在一个单独(附属)的服务器上发布 , 同时需要将工作流客户端应用与原服务器间的交互(例如 ,查询活动/流程实例的状态 ,或者挂起/恢复/终止流程实例) “转介 ”到该附属服务器 。在这种情况下 ,可能需要将某些操作与多个工作流引擎链接(例如 ,一个激活的流程实例的多个不同活动分布在多台计算机中) 。可能还需要一些事件通知服务 ,通告活动状态转移的启动和活动/子流程的完成 。状态转移流程参见附录 A。
4.5 管理和监控接口
管理和监控功能支持一个供应商的管理应用在其他的工作流引擎上工作 。 通过标准化的公共接口 ,使若干工作流执行服务器能在一定范围内共享管理功能和系统监控功能 。
管理和监控接口包括 WAPI集合中的那些用于支持操控管理和监控功能的命令 。
图 11是管理和监控接口的概念图 。 图中示出独立的管理应用与不同的工作流执行服务器的交互 。也可能有其他适用场景 ,例如 ,管理应用不是独立的 ,而是其中一个工作流执行服务器的一个组成部分 ,但它具有管理各个工作流执行服务器上各种功能的能力 。
图 11 管理和监控接口
除图 11所示外 ,管理应用也可能执行其他的管理功能 。例如 ,管理工作流流程定义 、充当资源库和通过接 口 1 的操作为不同的工作流执行服务器分配流程定义 。
此接口包含以下类型的操作(其中一些是与其他接口共同的) :
a) 用户管理操作 :
● 建立/删除/挂起/修改用户或工作组的权限 。
b) 角色管理操作 :
● 定义/删除/修正角色 。
c) 审计管理操作 :
● 查询/打印/新建/删除审计记录或事件日志等 。
d) 资源控制操作 :
● 设置/取消/修改流程或活动并发级别 ;
● 询问资源控制数据(数量 、阈值 、使用参数等) 。
e) 流程监控 :
● 变更工作流流程定义或其现有流程实例的操作状态 ;
● 启用或停用流程定义特定版本 ;
● 变更某类型的所有流程或活动实例的状态 ;
● 为某类型的所有流程或活动实例的属性赋值 ;
● 终止所有的流程实例 。
f) 流程状态 :
● 开启/结束流程或活动实例的查询 ,设置过滤条件 ;
● 提取流程实例或活动实例的详细信息 ,按规定过滤 ;
● 提取特定(单个)流程或活动实例的详细信息 。
附 录 A (资料性附录)状 态 转 移
可以把工作流执行服务器看作是状态转移机 。在这个转移机里 ,变更流程或活动实例状态 , 以响应外部事件(如 ,活动的完成)或工作流引擎采取的特定控制决策(如 ,引导到流程里下一个活动步骤) 。
流程实例的基本状态转移模式如图 A. 1所示 。
图 A. 1 流程实例状态转移示例
在图 A. 1 中 ,状态转移(用箭头表示)响应所标识的特定 WAPI的命令 。某些状态之间的转移是满足流程定义中转移条件的结果(例如 ,作为某外部事件或时间/日期依赖条件的结果等) 。
基本状态包括 :
a) 初始状态 — 创建了流程实例 ,包括关联的流程状态日期和工作流相关数据 ,但是流程还没有满足启动执行的条件 ;
b) 运行状态 — 流程实例已开始执行 ,流程中满足相应启动条件的活动开始执行 ;
c) 挂 起 状 态 — 流 程 实 例 休 眠 , 直 到 流 程 返 回 运 行 状 态(通 过 恢 复 命 令) 前 , 流 程 中 的 活 动 不启动 ;
d) 完成状态— 流程实例满足完成条件 ;将执行所有完成后的操作(如记录审计数据或统计) 并取消流程实例 ;
e) 终止状态 — 流程实例在正常完成前停止执行 ;将执行诸如差错记录或记录恢复数据之类内部操作并取消流程实例 。
参 考 文 献
[1] WFMCSC00-1002 WFM Coalition ProposalInformation
[2] WFMCSC00-1006 WFM Coalition TechnicalCommittee Operations
[3] WFMCTC00-1008 Interoperability White Paper
[4] WFMCTC00-1009 Clientapplication APIdescriptions
[5] WFMCTC00-1010 Workflow Definition Read/Write Descriptions
[6] WFMCTC00-1011 Terminology and Glossary
[7] WFMCTC00-1013 Workflow APIs—Naming Conventions
