工作流概念
工作流管理联盟(WfMC) 对于“工作流” 这个概念的经典定义为: 全部或者部分由计算机支持或自动处理的业务过程.
工作流管理系统(Workflow Management System, WFMS), 它通过执行计算机的流程定义去支持一批专门设定的业务. 它被用来支持、管理和执行工作流程.
因此, 对于我们, 工作流管理系统的目标是: 管理工作的流程以确保工作正确的时间被期望的人员所执行——在自动化进行的业务过程中 "插入" 人工的执行和干预, 可以说正是工作流管理系统的价值所在, 也是工作流系统开发者的主要工作内容.
如何从一个开发者的角度看工作流技术
使用工作流技术体系开发软件系统对开发者又有什么好处呢?
举个例子说明.
现在我们来看一个简单的业务——订货流程:
- 客户提交采购订单
- 业务员执行订单处理
- 如果缺货, 转工厂生产
- 仓库发货
- 物流发货
不使用工作流技术, 从头开始开发这个订购流程的业务系统, 我们需要:
- 每个活动节点都要开发交互界面和后台处理程序.
- 每次活动的流转都需要硬性判断下一步活动节点及其处理人.
- 每次操作都需要维护业务数据和流程的一些相关数据.
- 一旦业务流程, 就需要大量的更改程序, 甚至重新开发以适应新的需求.
- 监视、控制、分析流程处理情况的应用还需要单独开发, 且成本不低.
结果这个业务系统可能是如下图所示的情况, 请注意这不包括监视器、控制、分析流程的部分.
下面我们看看使用工作流技术实现上述的订货流程将会是什么情况, 如下图:
很明显, 位于右侧的工作流管理系统接管了所有订货业务在流程方面的定义和执行, 这包括:
- 使用专门的 "流程数据" 系统, 维护所有涉及流程传递的数据.
- 提供 "流程设计" 工具, 帮助用户定义订货流程的模型, 这一般都是基于图形界面的.
- 工作流引擎作为工作流管理系统的核心, 负责解释流程定义、管理流程数据、计算和驱动流程实例的运行.
- 工作流引擎提供众多 API 供客户端应用程序或外部业务系统调用, 将特定的 "业务(例如: 订货)" 纳入"流程" 的管理和控制之中, 从而实现工作流程管理和业务操作的完美结合.
- 工作流引擎还提供众多 API 供流程的 "增值" 系统使用, 例如流程监控系统可以使用工作流程引擎提供的 API 去监视流程的执行过程、挂起和恢复流程实例的运行; 流程数据分析系统可以使用工作流引擎的 API 分析出工作完成的效率、业务流程的瓶颈等结果, 以便重组流程、优化业务.
综上所述, 引入工作流技术对于技术开发来说, 有如下好处:
- 降低开发风险——通过使用诸如活动、流转、状态、行为这样的术语, 使得业务分析师和开发人员使用同一种语言交谈成为可能. 优秀的流程设计模型工具, 甚至能使开发人员不必将用户需求转换为详细设计文档.
- 流程实现的集中统一——应对业务流程经常变化的情况, 使用工作流技术的最大好处是, 使业务流程的实现代码, 不再散落在各式各样的业务系统中.
- 加速开发——开发者不用再关注流程的参与者、活动节点的衔接、流转控制. 因为这些工作很多被工作流框架接管了. 因而开发者开发起来更快、代码出错更少、系统更加容易维护.
- 提升对迭代开发的支持——如果系统中业务流程部分被硬编码, 就不容易更改, 需求分析师就会花费很大的精力在开发前的业务分析中, 并且希望以此成功. 但可悲的是, 在任何软件项目开发中, 这都很少能实现.
工作流管理使得业务流程很容易部署和重新编排, 业务流程相关的应用开发可以以一种 "迭代/渐进" 的方式推进, 也就是说工作流在某种程度上支持 “需求分析不必一次完全成功”.
工作流管理系统参考模型
首先, 最重要的部分就是中间的工作流引擎, 可以说他是整个工作流管理系统的心脏, 因为所有的工作流管理系统都要使用工作流引擎:
- 为执行的流程实例解释流程定义——这些流程定义一般都是由接口1获得的.
- 组织调度流程的实例, 推进工作流程的前进, 这包括条件流转、分支聚合、子父进程.
- 处理工作任务的分配、接收、提交等行为——无论是人工干预或自动执行的任务, 都需要经过工作流引擎和持久化.
- 管理调用其他的 4 个接口——这可能包括执行工作流程定义的一些外部脚本.
工作流引擎做的工作就像心脏把血液不断送到身体的各个部分一样.
工作流管理系统5个部分
接口1——流程定义工具
前面提到过我们使用它来设计业务流程, 提供给工作流引擎来实例化运行. 所谓的 "业务流程定义" 一般来说就是一段 XML, 它一般遵循 XPDL标准 BPEL标准 或其它厂商自定义的标准.事实上可以把流程定义工具理解为一个产生 XML 的图形化设计建模软件.
接口2——工作流客户端应用
这很有意思, 当业务流程设计好了 运行起来了, 那么我们——"人类" 如何与工作流引擎交互呢?
这时候, 工作流引擎就通过接口 2, 为我们提供各种各样的工作任务列表 工作表单 流程列表以及一些查询功能.
我们通过这些接口应用, 就可以填写表单 处理任务 从而实现人与工作流引擎的沟通.
接口3——执行外部应用
工作流引擎通过这个接口去执行一些外部的或面向专门职能领域的应用程序.
例如财务系统 报表系统等, 让第三方系统参与进来, 从而完成定义的工作流程.
同时我们也可以发现接口2 和接口 3 之间的界定有些模糊, 难道接口 2 提到的 "工作任务列表" 不能算是外部的应用程序吗?
没错! 这个问题确实存在, 这也就是为什么荷兰工作流大师 Aalst 在其著作<工作流管理——模型 方法和系统> 中写道 "建议每个应用程序都有此 '应用程序执行服务' 打开" 的原因, 他是在建议统一这两个接口吗? 总之, 接口3在标准化方面众口不一.
接口4——其他工作流应用接口服务
用来处理若干自治工作流管理系统之间的工作交换, 例如实例转移 工作任务外包等. 事实上, WfMC 组织的初衷是想通过这个接口来连接各种不同的工作流引擎和系统, 使他们在一个统一的标准下工作和交流.
想法是非常不错的, 但是, 由于种种原因吧, 作者认为是商业利益的因素以及 WfMC 没有强大到能 "号令江湖, 莫敢不从" 的地步, 所以到目前为止, 接口 4 基本不被支持, 也就是说, 各大厂商的工作流产品并不能用同一种语言对话.
但是, 随着jbpm4 推出的 PVM——流程虚拟技术的发展, 接口4 的障碍也许能被打破.
接口5——管理和监控工具
虽然很多工作流管理系统, 特别是开源工作流管理系统实现的最简单的部分就是这个接口, 但我认为最能体现工作流管理系统在企业管理方面价值的就是这个部分, 它主要被用来搜集管理信息.
这包括诸如工作流系统功能管理工具, 流程实时监控和控制工具, 以及工作效率分析和流程覆盖面分析等各种商业智能工具, 这为提升企业的管理能力, 优化重组企业的流程, 分析企业内部的工作效率瓶颈等提供了重要的量化数据支持.
总结一下, 工作流管理系统参考模型的 5 大接口各自强调了什么?
接口1 —— 提供流程定义
接口2 —— 提供工作任务列表等客户端应用程序, 实现使用者与工作流引擎的沟通
接口3 —— 支持外部应用程序参与工作流程
接口4 —— 支持不同工作流引擎系统间的连接
接口5 —— 提供监控工具, 搜集管理信息
BPM
BPM 即业务流程管理, 其重点是通过建模, 自动化, 管理和优化流程, 来优化公司业务的效率和效果.
BPM 打破了跨部门, 跨系统和跨用户, 强调端对端的业务流程. BPM 系统运行在公司的内部和外部, 不仅员工, 客户, 合作伙伴和提供商都能够进入该系统. 同时, 在公司内部 BPM 的应用系统还包含了提升业务可视水平和可预见水平的功能.
BPM 通常以 Internet 方式实现信息传递, 数据同步, 业务监控和企业流程的持续升级和优化. 从这方面来说, BPM 不但涵盖了 "传统工作流" 的流程传递, 流程监控的范涛, 而且突破了 "传统工作流" 技术应用范围的瓶颈.
BPM 同样需要流程定义语言描述流程. 流程定义语言可以将企业中的各种业务流程表示成一种格式化的模型.
BPM 的相关技术标准可以用来定义业务流程和 Web Service 的集成与部署, 以达成企业业务目标. 也就是说, BPM 语言不仅拥有 XML 表示的流程定义, 还延伸到了SOAP WSDL UDDI等多项技术规格.
关于jbpm4 您需要知道的
JBPM 是一个可扩展的, 灵活的能够实现工作流/业务流程管理的企业级开发框架, 提供了流程定义, 流程部署, 流程执行, 流程管理等功能.
1. 嵌入式的工作流引擎
JBPM4 是完全支持嵌入式应用的业务流程开发框架, 可以在事务处理, 持久化等各个方面与业务应用程序进行灵活集成.
2. 可插拔的体系架构
JBPM4 采用了模块化的架构设计, 采用了 IOC 的设计理念, 各个模块之间可以比较方便的解除耦合或替换不同的实现.
例如持久化, 事务处理 身份认证, 日志服务等, 都由可选模块实现.
JBPM 的可插拔体系架构, 为软件开发者灵活选择 JBPM 的功能, 自定义已有的功能和拓展新的功能提供了 "无限可能".
3.易扩展的流程语言
JBPM 框架内置的流程定义活动, 包括 start, task, fork, join和decision等, 是构建完整业务流程所必须的组成部分, 他们提供了可以将业务逻辑Java代码和业务流程编排无缝衔接的绑定机制.
