1.2.1 工作流管理系统参考模型 (zhuan)

标签：

http://book.51cto.com/art/201009/228705.htm

*************************************************

1.2.1  工作流管理系统参考模型

许多软件开发商都有工作流产品，并且不断有新的工作流产品走入市场。市场上可选择的产品范围很大，因此每个开发商只关注产品的特殊功能，而用户可以采用不同的产品来满足不同的需求。

然而，由于各个厂商不兼容的流程控制方式，导致没有统一的规范使得不同的工作流产品协同工作。对于这个问题，业界一直认为，所有的工作流产品都有一些相同的特性，只要其各种功能遵循公共的标准，就可以实现不同工作流产品间的协同工作。

由此WfMC应运而生，WfMC的全称是Workflow Management Coalition--工作流管理联盟，它是由一些公司联合在一起成立的组织，从事工作流问题的研究和指导。

图1-5所示就是WfMC提出的工作流管理系统参考模型（Reference Model of the Workflow Management Coalition）。作为工作流技术标准化的工业组织，WfMC的这个参考模型无疑为各家工作流管理软件提供者的系统设计规划给出了权威的参考，乃至标准。

（点击查看大图）图1-5  工作流管理系统参考模型

首先，最重要的部分就是中间的工作流引擎，可以说它就是整个工作流管理系统的心脏，因为所有的工作流管理系统都要使用工作流引擎：

1）为执行的流程实例解释流程定义--这些流程定义一般都是由接口1获得的。

2）组织调度流程的实例，推进工作流程的前进，这包括条件流转、分支聚合、父子流程……

3）处理工作任务的分配、接受、提交等行为--无论是人工干预或自动执行的任务，都需要经过工作流引擎计算和持久化（如果需要的话）。

4）管理调用其他的4个接口--这可能包括执行工作流程定义中的一些外部脚本。

工作流引擎做的工作就像心脏把血液不断地送到身体的各个部分一样。关于工作流引擎应该如何架构和设计，在本书后面章节会涉及。

那么，接下来说说工作流管理系统"身体"的5个组成部分吧，也就是图1-5所示的5个接口。

接口1--流程定义工具。

前面提到过我们使用它来设计业务流程定义供工作流引擎来实例化运行。所谓的"业务流程定义"一般来说就是一段XML，它一般遵循XPDL（XML Process Define Language）标准、BPEL（Business Process Execution Language）标准或其他厂商自定义的标准（例如jBPM的流程定义语言就是jPDL）。事实上可以把流程定义工具理解为一个产生XML的图形化设计建模软件。这种软件各个厂商的技术实现可谓五花八门，仅基于Web的就有很多种技术实现，例如Java Swing，Flash，ActiveX；当然，很多开源项目采用的还是基于客户端的实现，例如jBPM使用的是基于Eclipse图形化插件的实现，Shark Workflow使用的则是JAWE（一种基于Java技术实现的XPDL建模工具）。当然，它们的最终目的都是统一的--产生XML格式的流程定义。

接口2--工作流客户端应用。

这很有意思，当业务流程设计好了、运行起来了，那么我们--"人类"如何与工作流引擎交互呢？这时候，工作流引擎就通过接口2，为我们提供各种各样的工作任务列表、工作表单、流程列表以及一些查询功能。我们通过这些接口应用，就可以填写表单、处理任务……从而实现人与工作流引擎的沟通。

接口3--执行外部应用。

工作流引擎通过这个接口去执行一些外部的或面向专门职能领域的应用程序，例如财务系统、报表系统等，让第三方系统参与进来，从而完成定义的工作流程。这看起来就像EAI（Enterprise Application Integration，企业应用集成）的特性，而事实上它也可以说就是Workflow EAI。同时我们也可以发现接口2和接口3之间的界定有些模糊，难道接口2提到的"工作任务列表"不能算是外部的应用程序吗？没错！这个问题确实存在，这也就是为什么荷兰工作流大师Aalst在其著作《工作流管理--模型、方法和系统》中写道"建议每个应用程序都由此‘应用程序执行服务‘打开"的原因，他是在建议统一这两个接口吗？总之，接口3在标准化方面众口不一。

接口4--其他工作流应用接口服务。

用来处理若干自治工作流管理系统之间的工作交换，例如实例转移、工作任务外包等。事实上，WfMC组织的初衷是想通过这个接口来连接各个不同的工作流引擎和系统，使它们在一个统一的标准下工作和交流。想法是非常不错的，但是，由于种种原因吧，作者认为是商业利益的因素以及WfMC还没有强大到能"号令江湖，莫敢不从"的地步，所以到目前为止，接口4基本不被支持，也就是说，各大厂商的工作流产品并不能用同一种语言对话。但是，随着jBPM4推出的PVM-流程虚拟机技术（这在本书的后面会涉及）的发展，实现接口4的障碍也许能被打破。您可以拭目以待。

接口5--管理和监控工具。

虽然很多工作流管理系统，特别是开源工作流管理系统实现的最简单部分就是这个接口，但作者认为最能体现工作流管理系统在企业管理方面价值的就是这个部分，它主要被用来搜集管理信息，这包括诸如工作流系统功能管理工具、流程实时监视和控制工具，以及工作效率分析和流程覆盖面分析等各种商业智能工具，这为提升企业的管理能力、优化重组企业的业务流程、分析企业内部的工作效率瓶颈等提供了重要的量化数据支持。我们说"工业化解放人类的体力，信息化解放人类的智力"，这个接口提供的功能不正是解放了流程企业领导和决策者们的智力吗，而这正是企业信息化的初衷、工作流管理的最终价值所在。传统的工作流管理系统在这个接口上的"短板"，正为下一节要说的BPM（Business Process Management）这个概念的支持者提供了攻击工作流技术的口实，BPM概念在这个接口上的强化成了很多人认为"Workflow系统"不等同于或弱于"BPM系统"的重要原因。事实上，这都不过是些概念而已，实现工作流管理系统、解决业务流程改进方面的问题才是我们所要做的。

总结一下，工作流管理系统参考模型的5大接口各自强调了什么？

接口1--提供流程定义。

接口2-提供工作任务列表等客户端应用程序，实现使用者与工作流引擎的沟通。

接口3--支持外部应用程序参与工作流程。

接口4--支持不同工作流引擎系统间的连接。

接口5--提供监控工具，搜集管理信息。

还有一些问题供读者思考：

接口3和接口5标准化工作进展较为缓慢，为什么？读者可以参考上文的说明思考得出。

接口3和接口4需要完善的地方很多，例如，流程和工作任务的事务、回滚（包括被动退回和主动取回的任务）问题，在这两个问题上如何处理、怎么处理好、如何保持原子性，如何进行"补偿"，乃至如何支持"中国特色"的业务，都是很有思考空间的。

1.2.1 工作流管理系统参考模型 (zhuan)

标签：

原文地址：http://www.cnblogs.com/zhao1949/p/5977492.html