第四章. 面向图的程序设计当前工作流和业务流程管理(BPM)的总体发展来说是极其零碎的.在一些工具,规范和学术界发现很少的统一意见 .传统方法导致笨重的,单系统把大量的功能包含在一个单一的系统中. Java开发语言中缺少的特性导致在这个范围产生了完整系列的解决方法. 这个文章将标识缺少的特性并且提出一个简单的解决方法让java变成面向图的开发语言.面向图的开发语言可以看作是构造工作流,BPM及流程编排通用构造模块. 先从比较高层面来看看当前工作流,BPM和流程编排(或协调)领域的解决方法. 因为现在没有很清晰和被普遍接受的有关工作流,BPM和流程编排(或协调)的定义,我们还是做一些普通的观察 工作流是同人们管理任务最接近的. 重点关注工作流指明的由人完成的任务同流程目标的联系. 业务流程管理(BPM),指把工作流和企业应用集成(EAI)结合起来 . 一个业务流程指明通过人通过一些软件完成的任务及他们如何互相联系来完成业务流程目标. 流程编排(Orchestration)根据它所处的环境而有显著的不同. 流程编排(Orchestration)语言(像BPEL)是定位于web 服务环境. 流程编排(orchestration)语言是为web服务所用的编程语言. 这就表明你可以由流程编排来为其他web Serverice 编写新的web Service. 流程编排语言有控制流结构作为语言的一部分.其他的基本操作需要调用其他的 web services. 现在,我们对这三个领域的一般的期望都有了明显的认识. 对流程来说有等待状态是必须具有的能力.这些流程的在等待状态时必须能暂停执行. 暂停执行在Java中是不可能的.实际上在Java里暂停和继续一个thread(线程)是可能的 (比如用 Object.wait()和 Object.notify() ).但是由于永久化的原因这同流程的等待状态不是非常匹配.工作流, BPM 和流程编排方法在等待状态时候需要永久化它们的执行.事实上, 在流程流程中状态的改变对应着服务器上的事务..在这些事务之间暂停执行应该被永久化到数据库中或文件系统里. 实际上, Java缺少内置的暂停和永久化的机制是没有什么让人惊奇的. 这是因为Java是构造在诺依曼架构上.基本的特征就是顺序执行指令. 这篇文章就是呈现一种扩展诺依曼架构来支持暂停和永久化执行的技术. 在这三个领域的产品为了解决上述问题都有从自己的角度来观察的方法, . 作为结果,每一个解决组合暂停执行的方法都包含了所有的可用功能. 这就是让开发社区感到不清楚和混乱的根本原因.. 在我们开始处理暂停执行的解决方法之前有一个方面是什么重要的必须引起重视:流程的图形表示. 暂停执行的这个技术能力产生了非常有趣的机会 : 两个业务流程之间的直接连结及技术实现. 业务流程是业务分析需求确定中的中心部分. 没有暂停执行的机制, 业务流程的需求实现需要复杂转换成软件设计. 这种情况下,开发者不的不在等待状态保存某些形式的执行状态到数据库中.如此的复杂性会因为业务的功能需求和组合而增加. 结论是如果我们找到一个解决用图形表示的业务流程的执行暂停的方法,将会是一件伟大的事情.. 许多 (可能是全部) 图形化表示业务流程是基于定向图. 一个流程语言限制成了一个tree,只是定向图的一个子集. 这些语言叫做块结构语言block structured languages . 一个重要的考虑结果提议利用迭代开发. 对UML 类图, 这是常见的联系. 分析员可以用UML类图来画分析模型.然后开发人员用这个模型作为设计模型的开始点. 然后在实现中加入更多的技术细节. 太多的建议方案最后都是结束于形成一个可视化的开发环境. 传统方法是指定一个作为结构集合的流程语言.每一个结构有一个图形表示和运行时的行为. 下面是一般的回顾常用的方法:
面向图的程序设计是解决执行暂停和永久化的问题的技术..因为它的局限范围,这个技术,是容易理解和作为工作流,BPM和流程编排方法功能的建设模块 . 面向图的程序设计中心思想是我们为运行时间的图执行用简单的命令式编程.因此图是软件的一部分并且在运行时间图的执行同解释命令软件紧密偶合的 . 流程图是有节点(nodes)和转换(Transitions)组成.转换(Transitions)有方向并且在图中连接两个节点. 图可以看成是一个状态机. 执行模型我们可以解释的比较具体对路径的并发执行有较好的支持. 下面的UML类图勾画了流程元素怎么被建模UML类图中.这也展示了流程图可以被表现为数据(data). 流程图数据可以用不同的方式表达:XML,java对象,数据库记录... 下一个部分对开发人员和技术人员来说是最难于理解的部分.这是因为我们指明的执行模型同众所周知的 诺埃曼架构 不同. 我们定义一个令牌作为执行路线.它是在一个系统内的执行路线. 注意流程执行可能包括多个并发的执行路线.我们现在定义一个流程执行作为一个令牌树.令牌在流程图中有个指针指向节点. 下面的UML类图展示了令牌树如何建模做为UML类图.同样流程执行也能表示为数据.这实际上是使执行永久化的关键部分. 现在,我们来解释java的执行如何同图的执行紧密偶合的. 下一个图形展示了节点和转换中的方法在图执行中是相关的.为了计算下一个执行状态,我们用一个改良的GOF设计模式中提到的chain of responsibility 模式版本. 图中的节点表示等待状态.在等待状态期间, 一个令牌指到节点.在节点每个令牌可以接受信号signal. 信号可以被送到令牌来再继续开始执行,之后等待状态结束了.这将使图执行开始. 信号的效果使令牌离开节点. 在case中节点有多个离开转换In case the node has more then one leaving transition, 离开转换必须作为信号的一部分.转换只是使令牌到目的节点.当令牌到达节点,节点被执行.图中每个被定义类型的节点都有运行时间的行为.每个节点类型对应着节点的子类其行为在excute方法中实现. 节点的execute方法有两个责任.第一, 她执行同节点类型一致的一些业务逻辑,比如.发送一个消息, 更新数据库,为一个用户生成任务... 第二个责任是节点的execute方法必须传播图执行.如果节点不传播执行,那么它的行为就是等待状态.她可以传播到达节点的令牌向下到其中的一个离开转换. 或者她可以新建一个令牌然后传播这些向下到离开转换. 当所有令牌进入等待状态的时候图执行就结束了. 在这个时候,信号已经全部处理过了并且流程执行全部完成 (由令牌树组成)全部进入新的等待状态.此时令牌树可被保持.每个令牌在等待接受另外一个信号. 这个模型需要一个重要的精化 : 动作(action). 动作是在流程事件中执行的一段java代码. 比如事件是'离开节点leaving a node', '进入节点entering a node'和 '取得转换taking a transition'. These 这些都是直接的不能跨越等待状态的事件. 图执行模型用动作action来做精化是必须的,因为这允许技术开发人员可以为商业流程增加执行的细节 , 而不必改变由分析员建立的原始图. 现在我们小结一下这个模型怎么解决传统工作流,BPM和流程编排的问题.
|
|