版权声明：CSDN是本Blog托管服务提供商。如本文牵涉版权问题，CSDN不承担相关责任，请版权拥有者直接与文章作者联系解决。
1、什么是WfMS
（1）定义
l 工作流系统是以规格化的流程描述作为输入的软件组件,它维护流程的运行状态,并在人和应用之间分派活动
l 基本概念：
Ø 流程定义（process definition）：一个业务流程或过程的规格化描述
Ø 流程实例（process instance）：流程定义的一个运行实体
Ø 状态 (state，或者说等待状态)：代表一种对外部参与者的依赖；这意味着在流程运行时流程引擎必须等待，直到外部参与者通知工作流系统指定的状态完成了
Ø 动作（action）：在流程运行过程中，工作流系统为响应指定事件运行的一段程序逻辑；当流程运行过程中指定的事件发生时，工作流系统启动并执行这些动作
Ø 流程上下文变量（process context variable）：保存每一个流程运行的上下文信息；通常在流程定义中声明这些变量，然后在流程实例生成时被实例化
（2）目标
l 作为企业应用系统集成（EAI）的平台：当前大部分企业级IT架构中包含各种专门应用；这些专门应用提供了一组固定的自动化业务流程；而工作流系统将业务流程描述作为输入并管理流程实例的执行，比专门应用更灵活；因此，工作流系统和专门系统是相互补充的，使用工作流系统管理全局的业务流程，结合所有的专门应用，来构建一个EAI平台
l 协助涉及多人相关任务的工作流软件的开发
l 将工作流引擎嵌入到其他应用中：开发专门应用的公司可以将工作流引擎嵌入到他们的软件中；在这里，工作流引擎只是作为一个软件组件，主要是为了重用和应用软件的可维护性
2、工作流案例
引入工作流能够在软件开发级和业务级受益。
（1）简化开发
l 降低开发风险 ：业务分析师和开发人员使用相同语言交谈（如状态和动作术语），这意味着开发人员没有必要将用户需求转化成软件设计
l 集中实现：业务流程经常变化，使用工作流系统的最大好处是：实现不再是散落在各种系统中模糊整合的软件片断
l 加快应用开发 - 你的软件不再有在流程终保持与参与者联系的任务，开发更快，代码更容易维护
（2）业务流程管理（BPM）
在你能够自动化业务流程之前，分析它们并创建规范化描述是一件艰苦但会有很好回报的工作：
l 提高效率：许多业务流程自动化的结果是去除许多不必要的步骤
l 更好的流程控制：通过标准的工作方法和跟踪审计，提高了业务流程的管理
l 改进客户服务 - 流程的一致性，提高了各层次对客户响应的可预见性
l 灵活性：基于流程的软件控制，使得可以重新设计以符合业务需要的变化
l 业务流程改进：聚焦业务流程，导致它们的流线性和简化性
l 改进的迭代开发支持：工作流系统使得新业务流程很容易部署，业务流程软件可以使用迭代方式开发，因此使用工作流系统使开发更有效、风险更低
（3）缺失的环节
l 工作流系统是企业应用开发中缺失的环节
l 在企业级软件中并入业务流程逻辑的缺省方式是分散的，这意味着业务流程逻辑散布在各种系统中，如EJB容器、数据库触发器、消息代理等等
l 这导致软件难于维护，结果使得改变业务流程软件作为最后的选择；他们经常宁愿改变流程而不是软件
l 假设我们认识到这个问题，并打算集中一个流程相关的代码；这对于一个流程可以很好的工作，但要实现多个流程时，管理状态和流程变量的代码被到处复制
l 第三种方法是提取出复制的代码，放到一个集中的库中；这就是一个工作流管理系统
l WfMS以流程定义为输入
l 可以将流程定义看作UML活动图、UML状态图或者有限状态机
l 工作流系统负责维护这些流程定义的执行状态和上下文
l 为此，需要通知状态的变化；运行流程的状态变化可以记录下来，以备监控管理
l 下面是WfMS的接口：
Ø 定义接口：允许流程开发人员部署流程定义；这里的“流程开发人员”是业务分析师和软件开发人员的组合
Ø 执行接口：使用户和系统可以操作流程实例；流程实例是流程定义的执行；流程定义的控制流通过状态机描述；执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态的结束
Ø 应用程序接口：表示由工作流系统发起的工作流系统和外部系统之间的交互。当用户或系统管理一个流程实例的运行时，会产生事件；流程定义中可以指定一段响应事件的可执行代码逻辑，程序代码能够和组织内外部的其他系统通信
Ø 监控接口：管理人员通过监控接口获得流程运行记录的统计数据；有时，运行记录也可用于跟踪审计
流程定义的内容可以分为四个不同的层次：状态（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表单从用户收集这些信息
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管理所有流程实例的执行；在可执行业务流程中，每个流程表现为一个服务，这意味着每个流程定义都有一个不同的访问点