工作流模型分析(5)——流程整合模型

类别:软件工程 点击:0 评论:0 推荐:

 

流程模型分析(5

              ——流程整合模型

 

 

五、流程整合模型

流程整合的模型,已经超越了“流程运转模型”的概念范畴。但是作为目前“系统整合”的一个比较流行的趋势,拿到这里顺便提一下。

现在的业务越来越复杂,跨区域,跨部门之间信息交互方式的需要越来越明显,而且跨区域,跨部门之间业务配合也越来越多。从信息整合的发展来看,“面向应用的数据层整合”和“面向服务的接口层整合”都逐渐走向“BMP”模式:由中央主流程控制多个子流程(分布在不同地域或不同部门,各自独立的流程)协同运行,以达到整个业务逻辑的运行。

 

       其实在第二章“流程的激活模型”的“外界消息激活”模型中,我已经简单提到了一些,只是不太明确。那么现在让我们来看看一个普通的“流程整合”大概是什么样子的,请参看下图。

       实际的整合要比这张图上的复杂很多,也许还会有一些JMS/WebService等的信息交换接口,可能用到不同厂家的数据交换平台,或消息中间件等等;当然那些安全措施也必不可少了。

       简单的整合模型,基本上都是采用“主流程控制”的方式:由一个主流程控制整个流程的运行,由各个子流程具体完成某项任务,并向主流程返回处理结果。主流程在确定子流程正确运行/处理完后,并得到处理完的信息后,会继续按照预定的流程路线,激活另一个子流程。

       在有的流程整合设计中,主流程本身不完成任何任务(只负责运转控制);而有的设计中,主流程本身自己也需要完成一些任务。

 

      

图(5-1

 

 

       到此,有关流程的运转模型,基本上就完结了。现实中,可能存在的模型要比这些“图形”要复杂很多,也会考虑很多因素(组织模型,安全,信息文档等等)。考虑的因素越多,涉及的流程复杂度越高,对工作流引擎的要求就越高。实际上,一个非常通用的工作流引擎是很难存在的。因为一个工作流引擎不仅需要解析预定的流程,而且还需要控制维护流程运转中的数据信息(很多业务数据是有很强的领域性),所以大多的工作流引擎都是定位在某一方向上,以解决某一类问题为主。

 

       希望以上的文字,能够让大家了解通用的一些流程运转模型。真正在使用中,还需要大家自己去摸索,去积累了。

       本来也想将“流程的状态模型”也加上,但考虑这个状态模型本身就够说一大堆的,所以就推到以后了,在接下来我会专门写一篇探讨状态模型的文章。

       毕竟一家之言,难免有遗漏错误之出,请斧正。

 

 

后记:

       总算写完了,煞费苦心啊。光图就画了20多张。不过,总归很值,以前这些模型都记在大脑里,以为很完善了,结果真正写出来的时候,才发觉要说的真多。

       这两年,流行“工作流”,“整合”,“内容管理”等等。已远远超越了前几年简简单单的MIS概念,可知信息化发展有多快。其实工作流概念出来已经很久了,只是近几年才在中国软件业内流行,所以,不论从理论,还是从实践,我们都落后国外很远。

       其实,很多方面,我们都落后的,虽然我们也能够跟上国外的新概念。但人家的概念是从实践中慢慢积累出来的,发展深化来的;而我们大多是“引入”。前几天参加bea的dev2dev更是深有感触啊。

 

       感叹的话,就不多说了,希望大家在以后的应用中,逐渐“深化”。

 

---------------------------

作者:胡长城 (银狐999 , james999)

Email:[email protected]

 

本文地址:http://com.8s8s.com/it/it37529.htm