工作流管理系统（WfMS）介绍
1.3 工作流管理系统
1.3.1. 概述：
即Workflow Management System，简称WFMS，是定义、创建、执行工作流的系 统。工作流管理系统为方便业务交互逻辑、业务处理逻辑以及参与者的修改，多数通过提 供可视化的流程设计器以及表单设计器来实现，为实现工作流管理系统的扩展性。
1.3.2. 定义：
一个软件应用程序，它存储流程定义并通过其工作流引擎组件来根据这些流程定义运行工作。工作流引擎是运行时执行模块
1.3.3. WfMS的接口：
定义接口：允许流程开发人员部署流程定义；这里的“流程开发人员”是业务分析师和软件开发人员的组合
执行接口：使用户和系统可以操作流程实例；流程实例是流程定义的执行；流程定义的控制流通过状态机描述；执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态的结束
应用程序接口：表示由工作流系统发起的工作流系统和外部系统之间的交互。当用户或系统管理一个流程实例的运行时，会产生事件；流程定义中可以指定一段响应事件的可执行代码逻辑，程序代码能够和组织内外部的其他系统通信
监控接口：管理人员通过监控接口获得流程运行记录的统计数据；有时，运行记录也可用于跟踪审计
1.4 工作流引擎
英文全称是：WorkFlow Engine，是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。工作流引擎的几个要素有：
1.4.1. 实体(Entity)
是工作流的主体，是需要随着工作流一起流动的物件(Object)。例如，在一个采购申请批准流程中，实体就是采购申请单；在公文审批流程中，实体就是公文
1.4.2. 参与者(Participant)
是各个处理步骤中的责任人，可能是人，也可能是某个职能部门，还可能是某个自动化的设备
1.4.3. 流程定义(Flow Definition)
是预定义的工作步骤，它规定了实体流动的路线。它可能是完全定义的，即对每种可能的情况都能完全确定下一个参与者，也可能是不完全定义的，需要参与者根据情况决定下一个参与者；
1.4.4. 工作流引擎(Engine)
是驱动实体按流程定义从一个参与者流向下一个参与者的机制
流程定义的四个层次
流程定义的内容可以分为四个不同的层次：状态（state）、上下文（context）、程序逻辑（programming logic）和用户界面（UI）
l 状态层
Ø 所有的状态表述和控制流属于业务流程的状态层；
Ø 标准程序语言的控制流定义了必须被执行的指令的顺序，由我们书写的命令、if语句、循环语句等确定；业务流程中的控制流基本相同，但使用基本元素替代指令；业务流程中的基本元素是状态；
Ø 在流程中，状态(或等待状态)指定一种对外部参与者的依赖；状态的意思就像“现在X系统或Y人必须做某些事，在此等待直到参与者通知任务已完成的外部触发”；
Ø 流程定义中的状态也指定了执行依赖于哪个参与者；WfMS使用代表参与者的名字的信息构建任务列表，这是WfMS的通用特性；对于需要人参与的状态，WfMS必须在运行时计算出具体人，这样的计算使WfMS必须依赖于组织结构信息；
Ø 流程定义的控制流是一组和结合状态之间关系的状态；
Ø 状态之间的逻辑指定哪些执行路径可以并发执行，那些是排它的；并发执行路径用交叉和联合来建模，而排它执行路径用判断和合入来建模；
Ø UML活动图经常被用来做业务流程建模；
Ø 虽然活动图是一种直观和通用的表达，但在图形表述上有一个主要问题，就是没有区分状态和动作，都用活动来建模；
Ø UML活动图的第二个问题是在UML2.0版本中引入的，当多个迁移到达一个活动（只读状态）时，以前的版本指定为一个缺省合并，而在2.0版中指定为需要同步的缺省联合；
Ø 只要对两条构建语义作如下的变化，UML活动图仍旧可以用来对业务流程状态层建模：
Ø 在用图形表述业务流程时，只建模状态层（状态和控制流），不包括动作。这意味着图形中的矩形都是状态而不是活动；
Ø 如果多个迁移到达一个状态，缺省定义为不需要同步的合并；
Ø 在流程执行过程中，WfMS使用令牌（token）作为跟踪流程状态的指示器；当令牌到达一个状态时，被分配给WfMS等待的外部参与者；
Ø 外部参与者可以是个人、组织或者计算机系统，我们定义流程运行的执行人或系统为参与者（actor）；
Ø 只有在WfMS需要访问组织结构信息时，才将令牌分配给一个参与者
Ø 工作流系统通过分配令牌构建任务列表
l 上下文层
Ø 流程上下文变量或简称变量，是与流程实例相关的变量；
Ø 流程变量允许流程开发人员在流程实例的生命周期中存储数据；
Ø WfMS具有固定的一组数据类型，也可以定义自己的数据类型；
Ø 注意变量也可以保存引用，例如可以引用数据库中的记录、网络上的文件；
Ø 和流程变量相关的另一个有趣的方面是：WfMS如何将数据转化为信息；
Ø 工作流用于在组织内部的各种异构系统之间实现任务和数据进行协同；
Ø 对于业务流程中人工执行的任务，WfMS负责从其他相关系统，如SAP、数据库、CRM系统、文档管理系统收集相关数据。在业务流程的每一个人工步骤，只有相关的数据项从异构系统中收集和计算；
Ø 通过这种方式，从不同系统来的数据被转换并呈现为信息
l 程序逻辑层
Ø 动作是在流程运行过程中WfMS为响应指定事件而执行的一段程序逻辑
Ø 程序逻辑可以是二进制或源代码形式的、用任何语言或脚本编写的软件片断
Ø 程序逻辑层根据指定事件的信息将需要执行的所有软件片断组合
l 用户界面层
Ø 参与者通过向流程变量填充数据的事件，来触发结束一个状态
Ø 某些WfMS允许指定哪些数据可以填充到流程中，以及如何存储到流程变量中
Ø 可以生成UI表单从用户收集这些信息
与WfMS相对的可执行业务流程
l 当前BPM领域的新趋势是可执行业务流程的集中规范
l XLANG、WSFL 和BPML合并为基于交互（消息交换）的BPEL
l BPEL在面向服务体系结构(SOA)环境下定义，其前提条件之一是服务必须用WSDL声明
l BPEL规定了一套看作一种编程语言的XML语法，通过掉用WSDL中定义的服务整合控制流
l 可执行业务流程和基于状态的WfMS所使用的方法中，有三点主要的区别：
Ø 基于状态VS面向消息：基于状态的WfMS以状态（或者活动）概念为中心，工作流引擎维护状态并计算从一个状态到另一个状态的迁移；另一方面，像BPEL这样的可执行流程以响应输入消息的定义为中心，可以将一组这样的响应以及其他信息看作一个业务流程，这解释了为什么BPEL是基于状态的WfMS的一些补充；例如，BPEL响应输入消息的onMessage事件处理器，可以在状态之间迁移时执行
Ø 流程实例ID VS消息关系：可执行业务流程的复杂性之一是消息关系；流程描述的一部分必须说明BPEL引擎如何从输入消息中确定流程实例的标识，这必须基于输入消息的一个数据项；而基于状态的WfMS为每个创建的流程实例生成ID，客户端可以在后面调用引擎API时使用这个ID
Ø 核心工作流引擎API VS抽象服务端点（endpoint）：基于状态的WfMS提供一组核心API，这意味着客户端通过调用核心API管理所有流程实例的执行；在可执行业务流程中，每个流程表现为一个服务，这意味着每个流程定义都有一个不同的访问点
1.3.1. 概述：
即Workflow Management System，简称WFMS，是定义、创建、执行工作流的系 统。工作流管理系统为方便业务交互逻辑、业务处理逻辑以及参与者的修改，多数通过提 供可视化的流程设计器以及表单设计器来实现，为实现工作流管理系统的扩展性。
1.3.2. 定义：
一个软件应用程序，它存储流程定义并通过其工作流引擎组件来根据这些流程定义运行工作。工作流引擎是运行时执行模块
1.3.3. WfMS的接口：
定义接口：允许流程开发人员部署流程定义；这里的“流程开发人员”是业务分析师和软件开发人员的组合
执行接口：使用户和系统可以操作流程实例；流程实例是流程定义的执行；流程定义的控制流通过状态机描述；执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态的结束
应用程序接口：表示由工作流系统发起的工作流系统和外部系统之间的交互。当用户或系统管理一个流程实例的运行时，会产生事件；流程定义中可以指定一段响应事件的可执行代码逻辑，程序代码能够和组织内外部的其他系统通信
监控接口：管理人员通过监控接口获得流程运行记录的统计数据；有时，运行记录也可用于跟踪审计
1.4 工作流引擎
英文全称是：WorkFlow Engine，是指workflow作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。工作流引擎的几个要素有：
1.4.1. 实体(Entity)
是工作流的主体，是需要随着工作流一起流动的物件(Object)。例如，在一个采购申请批准流程中，实体就是采购申请单；在公文审批流程中，实体就是公文
1.4.2. 参与者(Participant)
是各个处理步骤中的责任人，可能是人，也可能是某个职能部门，还可能是某个自动化的设备
1.4.3. 流程定义(Flow Definition)
是预定义的工作步骤，它规定了实体流动的路线。它可能是完全定义的，即对每种可能的情况都能完全确定下一个参与者，也可能是不完全定义的，需要参与者根据情况决定下一个参与者；
1.4.4. 工作流引擎(Engine)
是驱动实体按流程定义从一个参与者流向下一个参与者的机制
流程定义的四个层次
流程定义的内容可以分为四个不同的层次：状态（state）、上下文（context）、程序逻辑（programming logic）和用户界面（UI）
l 状态层
Ø 所有的状态表述和控制流属于业务流程的状态层；
Ø 标准程序语言的控制流定义了必须被执行的指令的顺序，由我们书写的命令、if语句、循环语句等确定；业务流程中的控制流基本相同，但使用基本元素替代指令；业务流程中的基本元素是状态；
Ø 在流程中，状态(或等待状态)指定一种对外部参与者的依赖；状态的意思就像“现在X系统或Y人必须做某些事，在此等待直到参与者通知任务已完成的外部触发”；
Ø 流程定义中的状态也指定了执行依赖于哪个参与者；WfMS使用代表参与者的名字的信息构建任务列表，这是WfMS的通用特性；对于需要人参与的状态，WfMS必须在运行时计算出具体人，这样的计算使WfMS必须依赖于组织结构信息；
Ø 流程定义的控制流是一组和结合状态之间关系的状态；
Ø 状态之间的逻辑指定哪些执行路径可以并发执行，那些是排它的；并发执行路径用交叉和联合来建模，而排它执行路径用判断和合入来建模；
Ø UML活动图经常被用来做业务流程建模；
Ø 虽然活动图是一种直观和通用的表达，但在图形表述上有一个主要问题，就是没有区分状态和动作，都用活动来建模；
Ø UML活动图的第二个问题是在UML2.0版本中引入的，当多个迁移到达一个活动（只读状态）时，以前的版本指定为一个缺省合并，而在2.0版中指定为需要同步的缺省联合；
Ø 只要对两条构建语义作如下的变化，UML活动图仍旧可以用来对业务流程状态层建模：
Ø 在用图形表述业务流程时，只建模状态层（状态和控制流），不包括动作。这意味着图形中的矩形都是状态而不是活动；
Ø 如果多个迁移到达一个状态，缺省定义为不需要同步的合并；
Ø 在流程执行过程中，WfMS使用令牌（token）作为跟踪流程状态的指示器；当令牌到达一个状态时，被分配给WfMS等待的外部参与者；
Ø 外部参与者可以是个人、组织或者计算机系统，我们定义流程运行的执行人或系统为参与者（actor）；
Ø 只有在WfMS需要访问组织结构信息时，才将令牌分配给一个参与者
Ø 工作流系统通过分配令牌构建任务列表
l 上下文层
Ø 流程上下文变量或简称变量，是与流程实例相关的变量；
Ø 流程变量允许流程开发人员在流程实例的生命周期中存储数据；
Ø WfMS具有固定的一组数据类型，也可以定义自己的数据类型；
Ø 注意变量也可以保存引用，例如可以引用数据库中的记录、网络上的文件；
Ø 和流程变量相关的另一个有趣的方面是：WfMS如何将数据转化为信息；
Ø 工作流用于在组织内部的各种异构系统之间实现任务和数据进行协同；
Ø 对于业务流程中人工执行的任务，WfMS负责从其他相关系统，如SAP、数据库、CRM系统、文档管理系统收集相关数据。在业务流程的每一个人工步骤，只有相关的数据项从异构系统中收集和计算；
Ø 通过这种方式，从不同系统来的数据被转换并呈现为信息
l 程序逻辑层
Ø 动作是在流程运行过程中WfMS为响应指定事件而执行的一段程序逻辑
Ø 程序逻辑可以是二进制或源代码形式的、用任何语言或脚本编写的软件片断
Ø 程序逻辑层根据指定事件的信息将需要执行的所有软件片断组合
l 用户界面层
Ø 参与者通过向流程变量填充数据的事件，来触发结束一个状态
Ø 某些WfMS允许指定哪些数据可以填充到流程中，以及如何存储到流程变量中
Ø 可以生成UI表单从用户收集这些信息
与WfMS相对的可执行业务流程
l 当前BPM领域的新趋势是可执行业务流程的集中规范
l XLANG、WSFL 和BPML合并为基于交互（消息交换）的BPEL
l BPEL在面向服务体系结构(SOA)环境下定义，其前提条件之一是服务必须用WSDL声明
l BPEL规定了一套看作一种编程语言的XML语法，通过掉用WSDL中定义的服务整合控制流
l 可执行业务流程和基于状态的WfMS所使用的方法中，有三点主要的区别：
Ø 基于状态VS面向消息：基于状态的WfMS以状态（或者活动）概念为中心，工作流引擎维护状态并计算从一个状态到另一个状态的迁移；另一方面，像BPEL这样的可执行流程以响应输入消息的定义为中心，可以将一组这样的响应以及其他信息看作一个业务流程，这解释了为什么BPEL是基于状态的WfMS的一些补充；例如，BPEL响应输入消息的onMessage事件处理器，可以在状态之间迁移时执行
Ø 流程实例ID VS消息关系：可执行业务流程的复杂性之一是消息关系；流程描述的一部分必须说明BPEL引擎如何从输入消息中确定流程实例的标识，这必须基于输入消息的一个数据项；而基于状态的WfMS为每个创建的流程实例生成ID，客户端可以在后面调用引擎API时使用这个ID
Ø 核心工作流引擎API VS抽象服务端点（endpoint）：基于状态的WfMS提供一组核心API，这意味着客户端通过调用核心API管理所有流程实例的执行；在可执行业务流程中，每个流程表现为一个服务，这意味着每个流程定义都有一个不同的访问点