jBPM jPDL 用户开发手册3.2.3 - 第4章

第4章面向图的程序设计

4.1. 介绍

本章可以给出JBoss jBPM的明细单，完整的愿景概览、当前战略下的理念以及JBoss jBPM项目未来的方向。这一愿景和传统的取向相比有极大的不同。

首先，我们相信复合流程（multiple process）语言。不同环境和不同目的要求他们自己特定的流程语言。

其次，面向图形的程序设计是一个新的技术实现，这种技术实现是针对所有基于图的流程语言的基础。

这样做的最主要的好处就是它定义了一种针对所有类型的流程语言基础技术。

当今的软件开发越来越多的依赖领域特定语言。一个典型的java开发人员将使用相当多的领域特定语言。项目中的XML文件作为各种框架的输入就可以认为是领域特定语言。

图 4-1 基于图的语言的定位

工作流、BPM、orchestration 和pageflow的领域特定语言是基于定向图执行之上的。其他的像hibernate的映射文件、ioc-configuration则不是这样的。面向图的程序设计是基于执行图的领域特定语言的基础。

面向图的程序设计语言是非常简单的技术，它描述了如何定义图和被执行在纯OO程序设计语言上。

在 4.5 应用领域，我们将涉及大多数的常用的流程语言，这些语言都是可以使用面向图的程序设计方法来实现的，如工作流、BPM、编排（orchestration）和pageflow。

4.1.1. 域特定语言

每一流程语言都能被认为是一个领域特定语言（Domain Specific Language ,DSL）。DSL透视图让开发人员能很好的理解流程语言和纯OO程序设计如何关联的。

本节也许会留下我们单纯地专注在以程序设计环境为中心的印象。这是千真万确的。面向图的程序设计包含了从API库到完全成熟的BPM成套产品的整个BPM产品线。这套Bpm产品是完整的软件开发环境，这个环境是以业务流程为中心的。在那种类型的产品中，在程序语言中的编码被尽可能的避免了。

一个重要的领域特定语言的方面就是每一种语言都有某种语法。那种语法能够被表述为一个领域模型。

假如是java的话，这就是类、方法、域和构造器等等，而对于jPDL就是节点、转换和动作等等，而对于规则（rules），这就是条件和结果等等。

DSL的主旨就是开发人员当使用特定的语言创作为工件时可以考虑那些语法。IDE工具建立语言语法。然后，不同的编辑器就能创作工件。例如：jPDL流程有一个图形编辑器和一个XML源代码查看编辑器。而且有不同的方法来存储相同的工件：对于jPDL来说，这可能是一个流程XML文件或序列化了的节点和转换的对象图。

另一个（理论上的）例子是java：你可以在系统上使用java类文件格式。当用户启动编辑器时，源文件就被生成了。当用户保存时这个编译过的类也就被保存了…

10年前，开发人员最大部分的精力花在写代码上了。现在一个转换已经取代了这个位置，他们而是去学习和使用领域特定语言。这种趋势仍将继续而且导致的结果就是开发人员将在框架和在主机平台上开发软件之间有了更大的选择。JBoss SEAM正走向那个方向。

那些语言中的一些是基于图执行之上的。例如：java的工作流jPDL、服务编排的BPEL和SEAM pageflow等等，对于所有这些类型的领域特定语言，面向图的程序设计是一个通用基础。

将来，对于每一个语言、开发人员能够选择一个适合自己的最好的编辑器。例如：重量级的程序员可能更喜欢以源文件格式编辑java，因为那样工作真的很快。但是缺少经验的java开发人员可能会选择一个通过点击编辑器就能编写一个功功能性的java类。Java源编辑将更加灵活。

查看这些领域特定语言（包括程序设计语言）的另一种方式是从结构化软件透视图。面向对象的程序设计（OOP）使用数据通过分组设计方法增加结构。面向切面程序设计（AOP）增加一个方法结构通过分组方法去提取关注的交叉切面。依赖注入（DI）和反转控制（IoC）框架增加简易的对象图配线。而且通过结构化图执行周围的软件项目的一部分，基于执行语言的图（这提及的）是能有帮助的去处理复杂性的事务。

一个在领域特定语言（DSL）的基本解释能够在Martin Fowler的博客（bliki）上找到。但它之后的愿景在Martin的关于《Language Workbenches》的文章中有更加详细的说明。

4.1.2. 基于图的语言的属性

有为数众多的基于图的流程语言。在环境和焦点里有很大的不同。举例来讲，BPEL作为一个XML被计划，这个XML是基于在企业服务总线（Enterprise Service Bus ,ESB）架构之上的服务编排组件的。并且pageflow流程语言可以解释web应用的页面是如何能够被导航的。这些是两种完全不同的环境。

尽管有这些不同，你也会发现在几乎每一个流程语言里有两个特征：等待状态支持（support for wait states）和图示（graphical representation）。这不是偶然的因为这两种特征在纯粹的面向对象程序设计语言（如java）中没有被充分的支持。

面向图的程序设计是一种用面向对象程序设计语言去实现的技术。面向图的程序设计对OOP的依赖意味着实现于面向图的程序设计的所有具体流程语言将使用OOP来开发。但是这不是说流程语言本身暴露出了这种OOP的任何特性。例如：BPEL和OO程序设计没有任何关系并且它可以在面向图的程序设计上被实现。

 

 

4.1.2.1. 等待状态支持

命令式的程序设计语言（如java）常被用来表示一个系统中被执行的顺序指令。没有等待指令。命令式的语言描述起来是完美的，例如一个服务器的请求响应周期。系统将连续执行顺序指令直到请求被处理并且完成响应。

但一个这样的请求是较大的场景典型代表。例如：客户端提交一个采购订单，这一订单将被采购经理验证。在审批后，这一信息必须录入到ERP系统中去。大量的对服务器的请求是相同的大场景的部分。

所以流程语言是描述较大场景的语言。一个非常重要的区别是我们必须认为这是一个系统（编排）上是可执行的场景，而且场景也是在多系统（安排）间可以描述协议的。

基于图的程序设计实现技术只是瞄准可以在机器（编排机）上执行的流程语言。

所以一个编排流程根据一个系统描述整个场景.例如：当客户端提交一个订单时开始流程。流程的下一步是订单经理审批。所以系统必须在订单经理的任务列表中增加一个入口点和一个等待（状态）直到订单经理处理这个请求的输入。当这个输入接收后，流程继续执行。现在一个消息送达到ERP中流程处理待状态直到响应消息返回。

所以为一个系统描述整个场景，我们需要一个应付等待状态的机制。

在大多数的应用领域，执行必须在等待状态时被持久化。那也就是为什么只阻塞线程是不足够的原因。聪明的Java程序员也许会考虑Object.wait()和Object.notify()方法。那种处理用于模拟等待状态还可以，但问题是线程是不可被持久化的。

连续（Continuations）是使线程（和上下文变量）可持久化的技术。这个也许是足够解决等待状态问题的了。而且我们也将在下一节讨论，图示在许多应用领域也是重要的。而且连续（Continuations）是一个基于命令式程序设计的技术，所以它是不适合的对于图形表示。

所以支持等待状态的一个重要的方面就是执行需要是可持久化的。不同的应用领域也许有不同的需求来持久化这样一个执行。对于大多数工作流，BPM和编排应用，执行需要在关系数据库中持久化。代表性的是，一个流程执行中的状态转换将和数据库中的一个转换进行通信。

4.1.2.2. 图形化表示

软件开发的某些方面得益于基于图的途径是非常好的。业务流程管理是基于图的语言的应用领域中的最明显的一个。在那个例子中，在业务分析和开发人员间的通讯是被改进的用基于图的业务流程图解像通用语言那样。参考4.5.1 业务流程管理（BPM）节

 另一方面能够从图示中得益的是页面流（pageflow）。假若那样的话，在图示里页面、导航和动作命令是被显示和链接在一起的。

在面向图的程序设计里，我们瞄准表示一些执行的表单的图表。那是和诸如UML类图有明显的区别的，这种UML类图表示一个OO数据结构的静态模型。

此外图形表示可以被看作在OO程序设计中错过的特性。而且也没有什么明智的方法能够以图形化的表示OO程序的执行。所以在OO程序和图形视图间没有什么直接关系。

面向图程序设计，是以图为中心并且是一个的真正的软件制品，如描述流程图的XML文件。因为图形视图是软件的固有部分，它总是同步的。无须将一个图形需求插翻译成软件设计。软件是以图进行组织的。

 

4.2. 面向图的程序设计

这里我们展示的是一个基于图的执行语言的实现技术。这里展示的技术是基于与图集成的运行时的，其他的图执行技术都是基于消息队列或代码生成的。

本节会解释这个策略如何在OO程序设计语言上实现图执行。那些同设计模型是相似的，它是命令模式（command pattern）和责任链模式（chain of responsibility pattern）的结合体

            我们将用最简单的可能模型来开始并一点点的扩展它。

4.2.1. 图结构

首先，图的结构是用节点（Node）和转换（Transition）类来表示的。一个转换有一个方向，因此节点具有了离开和到达转换（的事件）。

图 4-2 节点和转换类

4.2.2. 执行

执行（execution）模型在图结构上定义，它看起来像一个有限状态机或UML状态图。实际上面向图程序设计能够用来实现那些各类的行为，但是也可以做更多的事。

一个执行（也叫令牌[token]）用一个叫做Execution的类来表示。一个执行有一个一当前节点的引用。

图 4-3 执行（Execution）类

转换能够用方法take从源节点到目标节点通过执行。

图 4-4 转换（Transition）的take方法

当一个执行到达节点时，那个节点被执行。这个节点执行方法来负责传播这个执行。传播执行意味着能够传递执行到节点，也就是通过它的离开转换到下一个节点。

图 4-5 节点（Node）的execute方法

当一个节点的execute方法不能传播执行时，它表现为一个等待状态。而且当一个新的执行被创建时，它被初始为一个开始节点并且等待一个事件。

事件（event）被赋给一个执行而且它有触发执行开始移动。如果事件赋给与当前节点相关的离开转换的话，执行将处理那个转换。执行然后将继续传播直到它进入另一个具有等待行为的节点。

图 4-6 执行的event方法

4.2.3. 流程语言

所以现在我们能够看到已经支持了两个主要的特性：等待状态和图形化表示。

在等待状态期间，执行只是指向图中的一个节点。流程图和执行都能被持久化。例如：使用O/R映射工具存到一个关系数据库中或者是序列化图存成一个文件。

            此外你可以看到那个节点和转换形成图并且以后是直接和一个图示结合的。

流程语言无非是一系列节点实现。每个节点实现和流程构图（constructs）进行通信。流程构图的需要的行为通过覆盖execute方法来实现。

这里显示一个有4个构图的流程语言的例子：一个开始状态、一个条件、一个任务和一个结束状态。这个例子没有关联jPDL流程语言。

图 4-6 流程语言示例

具体的节点对象现在可以用来建立流程图在我们流程语言示例中。

图 4-8 流程示例

当创建一个流程的新的执行时，我们开始定位这个执行在开始节点。因此只要执行不接收到一个事件，这个执行就将一直定位在开始状态。

图 4-9 新执行

现在让我们看下当一个事件到达时会发生什么。在最初状态下，我们击发缺省的事件将和缺少的转换进行通信。

也就是在执行对象上调用事件方法。这个事件方法将传播找到缺少的离开转换并传递执行通过转换，调用转换的take方法并将其自己作为一个参数进行传递。

这个转换将传递执行到决策节点并调用execute方法。让我们假设这个决策的execute方法发送了“是”这个事件到执行上。那将导致这个执行继续通过“是”转换并且执行将到达任务节点——“仔细检查”。

让我们假设执行“仔细检查”任务节点的实现加一个入口刊检查员的任务列表，然后等待检查员输入而不会进一步传播执行。

现在，执行将一直定位在“极细检查”任务节点。所有的嵌套调用将开始运行直到那个最初的事件方法返回。

图 4-10 在“仔细检查”等待状态的执行

4.2.4. 动作

在一些应用领域一定有一种方法来包含程序设计逻辑的执行，而不用为它引入节点。在业务流程管理示例这是一个非常重要的方面。业务分析负责图形表示而开发人员负责让其执行。如果开发人员必须改变图表来囊括业务分析中没有吸引力的技术细节的话将是不可接受的。

一个动作也是一个执行方法的命令。动作能够同事件关联。

当执行正在执行时，有两个基本事件：节点离开和结节进入被Node类击发。连同事件一起。

伴随有引起了要被处理的转换的事件，使得自由的注入程序设计逻辑进入这个图的执行。

图 4-11 图形视图中的隐藏动作

每个事件可以关联一系列的动作列表。所有的动作将随着事件的触发而被执行。

4.2.5. 同步执行

默认的执行的传播是同步的。在4.3.4 异步连续 节，我们将要看到缺省行为是如何被改变的。     

当事件送到执行时，执行开始。那个执行将要开始传播通过转换并进入节点。如果节点决定传播这个执行，这个 take 方法被调用了在离开转换上而且这个执行进一步传播。通过缺省，所有的这些传播作为嵌套方法调用被处理。那就意味着当执行已经进入新的等待状态时，原始事件方法只能返回。所以这个执行在一个事件方法的调用期间能够遍历多个节点。

典型的，signal方法在转换内部被调用了。这就意味着在一个转换里，在流程图上这个执行可以通过多个节点潜在地移动。那个结果在系统上有很大的程度的性能益处，即每个节点需要一个转换。

另一个同步执行的益处是有更多的异常处理选项。如果所有节点是被同步执行的，所有执行的传播将被嵌套方法调用。当signal方法返回时，这个signal方法的调用方将知道新的等待状态已经到而且没有问题发生。

4.2.6. 代码示例

为了让人们了解面向图的程序设计的原则，我们用少于130行的代码写了四个类。你可以只是读代码就能想法或者你能真正的和他们一起开始工作及实现自己的节点类型。

这有示例代码：

l  Execution.java

l  Node.java

l  Transition.java

l  Action.java

你可以下载整个源项目（297KB）并且自己开始。它包含一个eclipse项目，所以你只要在你的eclipse中导入它就可以开始了。在下一节还提及了一系列的用来显示基本的流程执行和高级的图执行概念测试。

4.3. 面向扩展图的程序设计

上一部分介绍了纯面向图编程模型用它的最简单的表单。这部分将讨论基于图语言的各个方面以及面向图的程序设计怎样才能被使用或扩展这些需求。

4.3.1. 流程变量

流程变量维护流程执行的上下文数据。在一个保险说明流程时在，'claimed amount'、'approved amount' 和 'isPaid'是流程变量的好例子。在许多方面，他们是同类的成员域是相似的。

面向图的设计有了流程变量支持可以容易地被扩展，这些流程变量是与执行关联的一系列的键值（key-value）对。并发执行路径（Concurrent execution paths）和流程组成（process composition）将是有点复杂的事。如果发生执行的并发路径或子流程那么界定（scoping）规则将定义流程变量的可视性。

工作流数据模型是一个通用的研究报告，在界定类型上的这个报告可以被应用到子流程和并发执行中的流程变量。

4.3.2. 并发执行

假设你使用工作流基于图的流程语言开发一个“sale”流程。在客户端提交订单后中，有一系列的客户端记账活动并且还有一系列的有关运输项目的活动。正像你想象的一样，记账活动和运输活动能够被并行处理。

那样的话，一个执行将不足以保持整个流程状态的跟踪。让我们逐步来扩展基于图程序设计模型并增加并发执行支持。

首先，让我们重命名空上执行到一个执行路径。然后我们可以引入新的概念叫流程执行（process execution）。流程执行代表一个完整的流程执行并且包含多个执行路径。

这个执行路径可以被分层排序。那也就意味着当新的流程执行被实例化时一个根执行路径被创建。当一个根执行路径分叉进入多个并发执行路径时，这个根是父亲，新创建的执行路径称为这个根的孩子。这样的话，结合实现可以变成直接的：这个结合实现就不得不去检查所有的兄弟执行路径（sibling-execution-paths）已经处在结合节点了。如果那样的话，这个父执行路径可以恢复执行离开结合节点。

当层级执行路径和基于兄弟执行路径的结合实现覆盖了用例的大部分时，其他的并发行为在这种情形下也许是合适的。例如当多个合并关联到一个分裂时。在这样的形式下，其他的运行时数据的合并以了合并实现是必须的。

图 4-12 并发路径执行

执行的多并发路经常与多线程编程混淆。尤其在工作流和BPM的上下文中，这些是完全不同的。流程指状态机。考虑状态机总是在一个稳定状态和瞬间的状态转换中。这样你就可以通过查看导致状态转换的事件来解析执行的并发路径。并发执行的意思是被处理的事件和并发执行路径两者间是无关的。现在让我们假设在流程执行中的状态转换和数据库转换是相关的（也在4.3.5 持久化和事件节被解释了），那么你将发现多线程程序设计是完全不需要支持执行的并发路径的。

4.3.3. 流程组成

流程组成是去包含作为超流程（super process）部分的子流程（sub process）的这个能力。这个高级的属性使得增加一个抽象到流程模型成为可能。对于事务分析，这个属性处理在较小的板块里中止大模型是重要的。

这个主旨思想是超流程有在图中有一个代表完整子流程执行的节点。当执行进入超流程的子流程节点（sub-process-node）时，将要考虑几个事情：

l  首先，为子流程创建新执行

l  可选的，一些存储在超流程中的流程变量信息能够从超流程执行注入子流程执行。最容易的形式是子流程配置一系列的用来把变量从超流程复制到子流程的变量。

l  子流程的开始节点（start-node）应该只有一个离开转换。支持多离开转换的流程语言必须有一个选择那些基于超流程的流程变量的转换中的一个转换的机制。

l  子流程执行通过发送一个响应开始状态默认转换的事件被启动。

在子流程进入等待状态后，超流程执行将指示子流程节点和子流程执行在一些等待状态。

当子流程执行完成时，超流程执行能够继续。下列方面那时是需要被考虑的：

l  流程变量信息可能需要从子流程执行中复制回超流程执行。

l  超流程执行将要继续。典型地，流程语言只允许在子流程节点上有一个离开转换。那样的话超流程执行被传播通过那个默认的离开转换。

l  如果子流程节点被允许多于一个的离开转换，一个机制将被引入到选择离开转换中。这个选择能够基于子流程执行的变量也可以是子流程的结束状态（典型状态机能有多个结束状态）。

WS-BPEL有一个子流程处理的隐性概念，要是显式的就好了。调用将开始新的子流程。然后超流程将有一个直到子流程结束的等待的接收活动。所以正常的调用和接收被特殊的活动取代了。

4.3.4. 异步连续

以上的，我们看到了去异步执行流程的默认行为直到有一个等待状态。典型地这全部的状态变换被打包成一个转换。在这部分里，你将看到如何在流程语言里划分转换边界。异步连续意思是流程可以异步地继续。这就意味着第一个转换将发送一个消息。那个消息代表一个连续命令。然后这个消息接收器执行第二个转换命令。然后这个流程继续它的自动执行，但是它分开了两个转换。

为了增加异步连续到面向图的程序设计，需要一个消息系统，这样的一个集成了你的程序设计逻辑的系统允许消息事务发送和接收。消息系统也被叫做面向消息的中间件（message oriented middleware, MOM）而且Java消息服务（Java Message Service , JMS）是用在这个系统上的标准API。

有三个执行能够被异步地继续的地方：

l  在节点的execute方法前。即进入节点后。

l  当执行将要通过一个转换进行传播时。即在离开节点前。

l  每个动作里也可以被异步的执行。

让我们详细地考虑下第一种情形当他被显示在下列图形中。假设某些事件导致一个执行通过图开始传播而且在“generatePdf”节点转换将要调用 execute 方法。取代直接地在“generatePdf”节点上的execute方法调用，新的消息命令正在使用一个指针到创建到执行。命令消息应该被解析为作为“通过执行节点继续这个执行”。这个消息通过消息队列被发送到命令执行器。这个命令执行器从消息执行器取得消息并以这个执行作为参数来调用节点的execute方法。

图 4-13 异步连续

注意现在两个独立的事务被涉及了。从初始事件发起的一个事务。那个事务包含了移动这个执行进入“generatePdf”节点并发送命令消息。在第二个事务中，命令消息被消费掉并且节点的execute方法以执行为参数被调用。在这两个事务之间，执行应该被到来的事件阻塞。

4.3.5. 持久化和事务

流程定义信息（像节点、转换和动作）和执行信息（像执行）两者都可以被存储在关系数据库中。ORM解决方案（像Hibernate/EJB3）可以用来做映射在数据库记录和OOP对象之间。

所有流程定义信息是静态的。因此它可以被缓存在内存中。这给了一系列的性能提高。不过每个转换中的运行时执行数据将不得不从数据库中被加载。

转换通常相当于执行上的事件方法。当事件正在被处理的时候转换开始。这个事件方法将触发执行继续直到新的等待状态到达。当那个发生时，执行的事件方法返回并且转换结束。

这整个事件方法调用的变换就是执行已经被移动了，它的节点指针从一个节点到另一个节点。这个ORM解决可以计算出原始数据库状态和被更新的java对象之间的差异。然后那些变化将在执行事件方法的结束点被刷到数据库中。在我们的例子中这是一个执行上的SQL更新（update）语句，设置节点指针到新（等待状态）节点。

类似hibernate/EJB3的ORM解决方案中，它们在每个session中同不同的对象集一起工作。这就意味着所有访问Node实现是被序列化了的并且只要代码使用执行数据（不是静态变量、实例）的话就移除写线程安全的代码的必要性。

4.3.6. 服务和环境

节点可能想利用可插拨的服务或新的节点实现可能想使用新服务，这还是个未知数在设计时。为了适应这方面，一个服务框架应该被增加到面向图的程序设计中，以至于节点可以访问何意的服务和配置。

基本上，有两方面：

l  向下传递执行上下文对象（上面提到的包裹了执行对象传递被传递）

l  线程本地执行上下文

执行上下文包含通过“环境”来访问服务是可用的。这个环境是客户端代码（代码调用Execution.event(String)加上一个可选的客户端代码的运行容器）。

服务的例子是定时器服务、异步的消息服务和数据库服务（java.sql.Connection）等等。

4.4. 注意事项

4.4.1. 运行时数据隔离

面向图的程序设计清晰地从运行时数据中（执行）中分离了定义数据（节点、转换和动作）。

所以代替了进入节点的传播执行，任何节点实现可以重新安排代表执行的整个运行时数据。这就创造了许多为实现不同形式的fork.split和结合（join/merge）行为的灵活性。

此外，定义信息是静态的而且从不变化。这个对于各种各样的执行优化是重要的。

4.4.2. GOP与其他技术相比

在这部分我们描述下面向图的程序和其它的实现技术如何被用于基于图的执行语言。

在基于面向消息的中间件（MOM）的执行引擎中，执行通过沿着消息队列传递的消息来表示的。每一个流程图中的节点是通过系统中的消息队列来表示的。实际上，面向图的程序设计是基于MOM的执行的超集。

在面向图的程序设计（GOP）中，缺省的，从一个等待状态到另一个等待状态移动执行的计算是被同步完成的。在这份文件的后部分，我们将提到用来解释MOM怎样才能够被用来在流程同步中做一步的异步连续扩展。所以基于MOM的执行在所有节点被异步地执行方面同面向图的程序设计是相似的。

另一种被用来实现工作流、BPM和编排系统的技术是代码生成。在那个方案中，基于图的流程被翻译成命令式的编程逻辑（如java）。这个被生成的编程逻辑对于外部的触发器有一个方法，它可以在等待状态后被给出。那些方法将计算转换到一个新的等待状态。这一技术是在流程版本能力和实践中被限制的，因为代码生成已经被证明在软件开发流程中是不实用和具有瓶颈的。

4.4.3. GOP 与Petri网比较

学术界，长时间以来，对于工作流和业务流程建模一直集中在petri网上，这主要是因为petri网是支持执行的并发路径唯一的精确定义的模型。由于数学基础的原因，许多有趣的验证和完整性算法可以被定义。

在petri网和GOP间最大的差异就是他们的本质。Petri网是一数学模型，而GOP是一个实现技术或设计模式。

GOP可以用来实现petri网。Petri网位置（places）和petri网转换可以作为两个不同的节点类型来实现。Petri网弧（arcs）相当于GOP的转换。一个petri网令牌（token）相当于GOP执行。

已经被定义在petri网上较高层的扩展（extensions）也可以用GOP的术语进行定义。

GOP自身并不支持分析算法当他们被定义在petri网上时。那是因为GOP没有一个具体的解释。分析算法只能定义在具有确定设计时解释的模型上。GOP在另一方面也支持具有非确定设计时解释节点。GOP节点实现可以潜在的去做任何运行时计算类型和决定，以及执行如何被传播。分析算法只能被定义在具体的流程语言上，因为这个节点实现让确定设计时解释成这个节点类型。

4.5. 应用领域

4.5.1. 业务流程管理 (BPM)

4.5.1.1. BPM不同方面

BPM的目标是让一个组织能够更高效的运行。第一步是分析和描述出组织是如何完成工作的。让我们定义一个业务流程即人和系统一起工作来完成一个特定的工作的方法的描述。一旦业务流程被描述了搜索优化就可以开始了。

有时业务流程已经有组织地被演化并且只是看这整个的业务流程显示某些明显的无效率。查找出使这些业务流程更加高效的修正称为业务流程重建（Business Process Reengineering ,BPR）。一旦流程大部分是自动地、统计和审核追踪能帮助查找并标识出这些无效性。

另一种提高效率的方式能够使用信息技术去自动化业务流程整体或部分。

自动化和修改业务流程是使组织更加高效地运行的最通用方式。总之重要的是注意那些是业务流程管理的部分内容。

经理不断地被他们的组员打断工作，进入被执行的步骤。例如一个软件开发经理组织一个团队建设事件。假使那样的话，业务流程的描述可能只在经理的前面完成。其他的情形像一个大保险公司处理一桩保险索赔而需要一个更正式的BPM方案。

总收入能够从管理业务流程并改进一定数量的业务流程执行时间效率中获得。管理业务流程正式化的成本是花费在分析、描述、改进和自动化业务流程上的额外成果。所以当决定哪一个流程将被选出来进行正规化管理及自动化时这些成本就不得不被考虑。这个解释就是要集中在高复发率的过程上。

4.5.1.2. BPM 系统的目标

BPM系统的主要目标是促进商务流程的自动化。在为业务流程构建软件中，两个角色能够被区别：业务流程分析人员和开发人员，在小点的团队里，这两个角色当然可以是一个人。业务分析人员研究、描述业务流程并指出软件需求，而开发人员创建可执行的软件。

传统BPM套件试着开始从业务分析模型并且按他们的方式向下完成可执行软件。他们 试着最小化技术技能需求，以至于业务分析人员能够生产出可执行软件。所有这一切不可避免的是以图为中心的，技术细节扰动着分析人员的世界。

图 4-14 传统的BPM方案

在我们的视野里，中心思想是业务分析人员和开发人员使用通用的语言进行沟通在流程的图形视图的帮助下。

技术技能将总是必须的当开发软件。业务分析人员负责图形化视图并且不应该去被迫处理流程的技术面。

没有那些技术面流程将不会完全的定义而且以后它是不可执行的。开发人员负责技术实现面。技术面不应该要求图的改变。

图 4-15 改进的BPM方案

4.5.2. 服务编排

最多的被公认服务编排语言的名称BPEL。服务编排常在企业服务总线（Enterprise Service Bus,ESB）的上下文中看到。ESB是企业级的中央通信主干。它集成了许多的相异的系统而且基于XML技术。

假设在你的ESB上你有A、B和C 三个服务。服务编排是用来写作为现有服务的一个函数的一个新的服务的基于图的执行语言。例如使用编排脚本，一个新服务D能够作为服务A、B和C的函数而被写。

图 4-16 服务

4.6. 基于嵌入图的语言

当BPM引擎能够被完全地整合到一个软件开发项目中、甚至BPM引擎的数据表也被整合到项目的数据库中时，然后我们提到可嵌入的BPM引擎。那就是我们用GOP瞄准的这个目标：一个基于图的语言实现的通用基础。

4.7. 市场

4.7.1. 终极流程语言

传统上，厂商正在找终极的流程语言。这个方案是用来指定流程语言作为一系列的构成（construct）。每个构成有一个图形表示和一个运行时行为。换句话说，在流程图中每个构成是一个节点类型。这样流程语言只是一系列的节点构成。

这个思想是厂商正在找最好的流程构成去形成一个统一的可应用流程语言。这个想法今天还是发现了许多而且我们称它为终极流程语言。

我们相信这一焦点不放在试着去找终极流程语言，而是去找在不同的场景和不同的环境中都能够被用来作为流程语言根基的通用基础。我们提出的GOP下一步将被看作这样的一个基础。

4.7.2. 相关信息

当前工作流景色，BPM和编排解决方案完全地分立的。这部分我们将描述下两个分裂的维度。第一个维度叫BPM产品线（BPM product continuum），它被展示在下一幅图片中。这个术语最初是被Derek Miers和Paul Harmon在《The 2005 BPM Suites Report》中引入的。

在左边，你可以看到编程语言。连续体的这边被瞄准在IT开发人员。编程语言是最灵活的而且它完整地集成了为特定的项目而开发的其他软件。它带来了相当多的程序去实现业务流程。

右边，有一个BPM套件。这个套件是完整的被用来瞄准用于业务分析软件开发环境。软件围绕业务流程被开发。无须编程不得不被做用来在BPM套件里创建可执行的软件。

     

            图 4-16 BPM产品线

4.7.3. 其他实现技术

基于消息队列技术。

基于代码生成技术。

谢谢大家的细节阅读，技术和能力有限，差错在所难免，诚惶诚恐。如有问题望大家不吝赐教，虚心学习和交流，!