流程模型分析（5）
——流程整合模型
流程整合的模型，已经超越了“流程运转模型”的概念范畴。但是作为目前“系统整合”的一个比较流行的趋势，拿到这里顺便提一下。
现在的业务越来越复杂，跨区域，跨部门之间信息交互方式的需要越来越明显，而且跨区域，跨部门之间业务配合也越来越多。从信息整合的发展来看，“面向应用的数据层整合”和“面向服务的接口层整合”都逐渐走向“BMP”模式：由中央主流程控制多个子流程（分布在不同地域或不同部门，各自独立的流程）协同运行，以达到整个业务逻辑的运行。
其实在第二章“流程的激活模型”的“外界消息激活”模型中，我已经简单提到了一些，只是不太明确。那么现在让我们来看看一个普通的“流程整合”大概是什么样子的，请参看下图。
实际的整合要比这张图上的复杂很多，也许还会有一些JMS/WebService等的信息交换接口，可能用到不同厂家的数据交换平台，或消息中间件等等；当然那些安全措施也必不可少了。
简单的整合模型，基本上都是采用“主流程控制”的方式：由一个主流程控制整个流程的运行，由各个子流程具体完成某项任务，并向主流程返回处理结果。主流程在确定子流程正确运行/处理完后，并得到处理完的信息后，会继续按照预定的流程路线，激活另一个子流程。
在有的流程整合设计中，主流程本身不完成任何任务（只负责运转控制）；而有的设计中，主流程本身自己也需要完成一些任务。
图（5-1）
到此，有关流程的运转模型，基本上就完结了。现实中，可能存在的模型要比这些“图形”要复杂很多，也会考虑很多因素（组织模型，安全，信息文档等等）。考虑的因素越多，涉及的流程复杂度越高，对工作流引擎的要求就越高。实际上，一个非常通用的工作流引擎是很难存在的。因为一个工作流引擎不仅需要解析预定的流程，而且还需要控制维护流程运转中的数据信息（很多业务数据是有很强的领域性），所以大多的工作流引擎都是定位在某一方向上，以解决某一类问题为主。
希望以上的文字，能够让大家了解通用的一些流程运转模型。真正在使用中，还需要大家自己去摸索，去积累了。
本来也想将“流程的状态模型”也加上，但考虑这个状态模型本身就够说一大堆的，所以就推到以后了，在接下来我会专门写一篇探讨状态模型的文章。
毕竟一家之言，难免有遗漏错误之出，请斧正。
后记：
总算写完了，煞费苦心啊。光图就画了20多张。不过，总归很值，以前这些模型都记在大脑里，以为很完善了，结果真正写出来的时候，才发觉要说的真多。
这两年，流行“工作流”，“整合”，“内容管理”等等。已远远超越了前几年简简单单的MIS概念，可知信息化发展有多快。其实工作流概念出来已经很久了，只是近几年才在中国软件业内流行，所以，不论从理论，还是从实践，我们都落后国外很远。
其实，很多方面，我们都落后的，虽然我们也能够跟上国外的新概念。但人家的概念是从实践中慢慢积累出来的，发展深化来的；而我们大多是“引入”。前几天参加bea的dev2dev更是深有感触啊。
感叹的话，就不多说了，希望大家在以后的应用中，逐渐“深化”。
---------------------------
作者：胡长城 （银狐999 ， james999）
Email：james-fly@vip.sina.com
发表于 @ 2003年11月14日 08:37:00|评论(loading...)|编辑