jbpm第四章翻译

第四章 面向图形编程

现阶段工作流和业务流程管理（bpm）的整体结构显得特别的支离破碎。在工具，标准和学术界很少有统一的认识。传统的方法导致了把很多功能集成在一起的、和别的系统没有接口的、庞大的系统。

Java编程语言本身缺失的一个特性致使在这个领域中产生了一系列的解决方法。这篇文章就是要鉴别出这个缺失的特性并提出了一个简单的解决方案——面向图形编程。面向图形编程可以被看作工作流，业务流程管理（bpm），和协调（orchestration）解决方案的一个基本构建模块。

4.1 缺失的一环

让我们从高层次来看一下现在工作流，业务流程管理（bpm）和协调（orchestration）解决方案的整体结构。

图4.1 工作流，业务流程管理（bpm），协调（orchestration）的整体结构概览

既然这里没有关于工作流，业务流程管理（bpm），协调（orchestration）清晰的一般的可以接受的概念，我们这里就做一些一般的观察把。

工作流是和管理分配给人们的任务最相关的了。工作流的流程集中关注指定给人们要完成的任务，这些任务都和取得特定的流程目标相关。

业务流程管理，通过企业应用集成和工作流结合在一起。一个业务流程指定人们的任务和一些特定的软件结合并且指定它们怎么结合来完成业务流程特定目标。

协调（Orchestration）和大家最大的不同是它的环境。协调（Orchestration）语言（像BPEL）主要是面向web service环境的。一种协调（Orchestration）语言是一种面向（web）service的编程语言。这就意味着你可以协调（orchestrat）其他web service来写一个新的web service。协调（Orchestration）语言就像普通编程语言一样也有流程控制部件。但是它的主要操作是调用其他的web services。

现在我们可以强调一下这三个领域共同的方面。也就是它们都具有作为流程一部分的等待状态。执行的流程在进入等待状态时必须暂停执行。

在java里暂停正在执行的流程是不可能的。实际上，在java中暂停和继续执行一个线程是可能的（例如用 Object.wait()和 Object.notify()方法.）。但是因为持久化这和流程等待状态的需要还是不相符。在等待状态时工作流，业务流程管理（bpm），协调（orchestration）解决方案需要保存流程的运行实例。实际上，一个流程中状态的变化应该反映到服务器的事务上。在这些事务中间，被暂停的执行的流程实例应该被持久化倒数据库中或文件系统中。

图4.2 暂停正在执行程序的路径是java缺失的一个特性。

实际上，java没有提供一个内建的机制来暂停和保存执行的程序，这并不奇怪。这是因为java是建立在冯 诺依曼体系结构上的。这就从本质上归结为一个顺序执行指令的环境。这篇文章展示了一个对冯 诺依曼体系结构扩展的技术，通过这个技术可以暂停和保存正在执行的程序。

这三个领域的产品都从自己的视角出发，用他们自己的方法解决了这个问题。因此造成了这样一个局面，每个解决方案都绑定了一个暂停正在执行的程序的技术，并且这个技术还附带了很多其他功能。这是在开发社区里对这几个主题的认识非常迷惑和不清晰的根本原因。

4.2 图形化表示和开发流程

在我们提出挂起正在执行的程序的解决方案之前，有一方面非常重要并且需要我们在这里提及一下。

挂起正在执行的程序的技术方面的能力提供了一个非常有趣的机会：能使业务流程和技术实现直接相连。业务流程是业务分析人员界定的需求的一个核心部分。如果没有提供一套挂起正在执行的程序的机制，业务流程的实现就需要很复杂的转译到软件设计当中。这种情况下，在程序进入等待状态时，开发者就不得不把执行状态存储到数据库的某些表中。再结合业务流程的功能需求，这将变得更加复杂。

结论就是假如我们能找到一个能挂起和业务流程图形表示相关的正在执行的程序的解决方案那就非常有价值。很多（或许是所有）业务流程的图形化表示都是基于有向图的。很多流程语言局限在树状图，有向图的一个子集。这些语言被称为结构块语言。

一个好的解决方案的一个重要的考虑是它应该支持迭代开发。用uml类图是惯例的做法。业务分析人员可以用uml类图画出分析模型。然后开发人员从这个模型开始把它转译成设计模型。添加更多的技术细节就能使之成为一个完整的实现。很多好的解决方案因为可视化编程而最终失去了生命力。

4.3传统解决方案

传统的解决方案是把流程语言当成一组建构单元。每个建构单元都有一个图形表示和运行时行为。

这种被广泛应用的解决方案有如下内在的缺陷：

单一系统：在传统上工作流，业务流程管理（BPM），协调（orchestration）解决方案都被打包成一个单一的系统，这样它就需要一个分离的环境。在多数情况下，这意味着它在你的应用系统里比较难使用，并且因为它在你的应用系统之外，所以也是很难管理的。

不完整的流程语言：学术研究（workflowpatterns.com）已经指出现在所有的（甚至研究胡只局限于控制流程建构单元）标准和解决方案，都有严重的局限性。

没有建模自由：在流程的图形化表示和流程建构单元的运行时行为之间存在一个固定的连接，这使得分析人员失去了建模的自由。画任何一个建构单元立即需要所有实现细节，而这些是业务分析人员并不关心的。

可视化编程：作为流程建构单元的图形化表示和它们运行时行为之间固定连接关系的直接后果，它总是以某种图形化编程的形式而失去生命力。根据经验，我们知道这是一种非常耗费时间的编程方式。

4.4什么是面向图形编程

面向图形编程是为了解决挂起和存储执行的程序问题的一门技术。因为它的范围限制，这门技术，作为针对工作流、业务流程管理（BPM）、协调解决方案（orchestration）的功能的构建模块来理解和应用是比较简单的。

面向图形编程的核心思想是我们用一个执行图形的实时模型来补足普通的规则编程（imperative programming）。所以图形就成了软件的一部分，并且在实时运行阶段，图形的执行和规则编程（imperative programming）软件的执行是一起的。

一个流程图是由节点（Node）和转换（Transition）组成的。转换（Transition）是有方向的，并且它在图形上连接两个节点（Node）。

图4.3 一个流程是一个有向图

尽管我们这里将要解释的运行模型是具体的，并且能更好的支持执行时的并发路径，我们依然可以把这个图看作是一个状态机。

下边的uml类图勾画出了流程元素怎样被表示成uml的类图。这也说明了一个流程图可以被描绘成数据。流程图数据有好几种不同的表示方式：xml，java类，数据库中的记录……

图4.4 一个流程图可以用节点（node）和转换（transition）来建模

下一部分对程序员和技术人员来说是最难理解的一部分。这是因为我们指定了一个不同于著名的冯诺依曼体系结构的执行模型。

我们定义执行的一条路径为一个Token，它是一个系统内的一条执行路径。

图4.5一个token是你的系统执行的一条路径

请注意一个流程的执行可以涉及多个并发执行路径。我们现在把一个流程的执行定义成一棵token树。在流程图中一个token指向一个节点（node）。

图4.6 一个流程的执行可以被表示为一棵token树

下边的uml类图是token树被用uml类图来进行建模。这包括说明了一个流程的执行可以被表示为数据。这实际上是把可执行的程序持久化关键的一部分。

图4.7 执行流程的数据模型

现在，我们来解释java的执行是怎样和图形的执行联系在一起的。下一张图展示的是节点（Node）和转换（Transition）中的和图形的执行相关的方法。为了计算正在执行程序的下一个状态，我们对在GOF的“设计模式”书中描述的责任链模式进行了修改。

图4.8 图形的执行是责任者模式中链条中的一个变量

图形中的节点可以代表等待状态。在等待状态时，一个token指向这个节点。在节点上的token可以接受一个信号（signal）。当等待状态完成以后一个信号可以被发送给一个token来使程序继续执行。这将使图形执行开始。

图4.9 一个信号（Signal）触发图形流程的继续执行

信号（signal）的作用就是使token离开节点。在节点拥有多于一个离开转换的情况下，离开转换必须被指定为信号的一部分。转换只是把token定位到目标节点。当一个token进入一个节点，这个节点就被执行。图形中的每个节点都是一个特定类型的，这决定了它的运行时行为。每个节点类型对应于节点的一个子类，并且它的行为是在execute方法中实现的。

节点的execute方法有两个职责。首先，它可以执行一些业务逻辑，这和节点的类型有关。例如:发送一个消息，更新一下数据库，为某个用户产生一个新任务……。节点的Execute方法第二个职责是传播图形的执行。如果节点没有传播执行，它就是一个等待状态。它可以传播到达这个节点的token给离开转换中的一个。或者它可以产生新的tokens并拿它们传播给离开转换。

当所有的token进入等待状态时，图形执行结束。在那个时候，信号（signal）已经被完全处理并且全部的执行流程（由token树组成）进入了一个新的等待状态。在这个时候，这棵token树就可以被保存起来。现在每个token都在等待接受另外的信号（signal）。

这个模型中，一个不可缺少的非常精致的部分是：动作（Actions）。动作（Actions）是流程中的事件被触发时执行的一些java代码片断。例如事件：离开一个节点，进入一个节点，和发生转换。这些都是一些无法跨越等待状态的即时事件。

动作（Actions）对精致的图形执行模型来说是必需的，因为这样就允许技术开发人员，不必要改变原来业务分析人员指定的流程图的情况下，就能给业务流程添加上技术细节实现。

现在我们来总结一下这个模型是怎样解决工作流，业务流程管理（BPM），协调解决方案（orchestration solutions）的传统问题的。

简单的api+责任链：代替单一的系统。

从节点继承：提供了最终的流程语言能力。

添加了不可见的动作（Actions）：为流程分析人员提供了建模自由。

循环开发流程：代替了可视化编程。

4.5构建模块

我们介绍的模型为普通编程提供了等待状态支持。用面向图形编程，我们可以定义横跨等待状态的执行路径。这个模型可以被当作实现工作流（workflow），业务流程管理（BPM），协调功能（orchestration functionalities）的基础。

图4.10面向图形编程就像一个积木块

结构化编程，面向对象编程和面向方面编程都可以被看作构建软件的一套机制。面向图形编程也可以被看作另外一种构建软件的机制。给软件添加结构对管理复杂性来说是非常重要的。既然软件项目的花费随它们的大小呈指数增加，所以一套减少复杂性的机制能省下来的钱应该是巨大的。