The Process Virtual Machine

第一次翻译文章，其中还有很多错误以及语句不通顺的地方，还希望各位能够海涵，
如果能够不吝指出我翻译中存在的问题，就是给我莫大的帮助。

Tom Baeyens:The Process Virtual Machine
链接地址：http://www.theserverside.com/news/thread.tss?thread_id=45602
http://www.onjava.com/pub/a/onjava/2007/05/07/the-process-virtual-machine.html?
CMP=OTC-FP2116136014&ATT=The+Process+Virtual+Machine

几周前，Tom Baeyens 和Miquel Valdes Faura 在OnJava上写下了“流程虚拟机”。这个文章背后的想法是：
在对一般的流程编码熟练之后，流程可以使用一般的描述结合具体的语言如jPDL,BPEL,page flow和其他已经实现的语言来描述。
同样的，它反应了这个思想，就像JVM和各种已经在其上实现的语言：BPEL将会是一个在流程虚拟机上实现的流程语言。
这是一个有趣的想法，给各种开发者提供了很多优势：既然它把开发者和业务分析者(流程语言最通常的受益者)作为目标对象，业务流程能被更多的人，使用在更多的领域，得到更好的结果。
在很大程度上，web应用程序可以看作一个业务流程的例子。当这个业务流程在SEAM(并且，推测起来，web bean，不管怎样已经完成)中可用时，这个想法可以概括为消息队列，数据项目，工作流，全部的符号——并且有一个流程虚拟机意味着开发者能轻易的得到业务流程而不需要精通整个抽象域。
介绍：
这篇文章将展示业务分析人员和开发者如何受益于流程，业务流程管理和orchestration。我们将使用简单的术语解释核心的工作流引擎本质，以及在java环境中这个如何起到杠杆作用。每个好的开发者都知道数据库的关系模型，而工作流引擎缺少一个相应的模型，流程虚拟机将提供这缺失的一块。
流程虚拟机是概念模型，应该是每个开发者的所有技能中的一项，因为它帮助解释所有变化的公开的工作流引擎。更进一步，因为Microsoft已经独立的达到了同样的方法(见下一个部分 另一边)，我们确信它将是下一代流程引擎的基础。这篇文章将清楚地显示这个目标和流程虚拟机的价值，并且指导你通过下面提及的流程虚拟机论文到达最重要的部分。你将也学习工作流技术是什么，什么时候在软件工程中它将有意义。
文章中，工作流，BPM和orchestration相互之间的区别是不相关的，因此为了简单起见，我们将涉及到这些时都当作工作流。大多数工作流语言的目标是在工作流引擎中，长运行的流程能使用图形化的方式表达和执行。图形化的很大的优势是开发者和业务分析者能使用同一个语言。典型的工作流例子如：
    保险索赔
    支票记录
    雇佣新员工
但是工作流技术能应用在拥有状态机特征的软件的任何方面，如显示的以下这些额外的工作流例子：
    定义一个粗糙的web服务作为其他web服务的一个功能
    在web应用程序中，页面流描述页面间的导航
    作业调度
    信息队列orchestration
传统的工作流引擎有一些瑕疵，在流程虚拟机中将得到解决：
1    单一的集中在业务分析员。 传统的工作流系统有一个大的功能集中在图形化工具，这个做法意味着一个非技术人员能画一个业务流程图。然后工作流引擎将自动的提取该流程的软件支持信息。如果你考虑一下，你想把一个软件产品的创建由一个非技术人员来完成吗？流程虚拟机展示如何创建一个在业务分析员与开发者之间有效率的协作。能通过仅仅点击，编辑流程图形来实现的流程是非常有限的。除了这些，流程虚拟机也支持需要流程逻辑和流程代码的组合的大部分流程。
2    流程引擎是与应用集成的系统的一个整体。这个使部署，测试和耦合使用应用程序事务的工作流事务很复杂。流程虚拟机允许工作流引擎能嵌入java应用程序或者能单独的部署。
3    一个单一的，固定的流程语言。流程语言实际上是图形结构的集合，每个图形结构表示一个具体的，确定的运行时行为。在传统的引擎中，自然的只能支持一种流程语言，并且不可能加入新的图形结构。而使用流程虚拟机，流程的结构被作为可插入的。使用这个方法，它能够支持多种的流程语言，它也能作为实现有限的定制流程语言的基础，例如，在文档管理系统中。
4    一个单一的环境。每个流程语言主要的对应它特别的环境。这个环境的具体可能是，比如，标准的java，企业级java，企业服务总线，或者jms队列，有或者没有持久化。许多流程语言，并且因此许多流程引擎，被设计成只能在某一种具体的环境中运行。我们承认不同的环境需要不同的流程语言，一种流程语言是不够的，但我们仍能实现一个流程虚拟机作为一个单一的基础，在这之上，其他的流程语言都能够被构成。
5    与程序的逻辑绑定不容易。实际上，流程能够为现实生活中的业务流程提供很大的支持。但是，大部分情况是，它通常需要结合其他的技术，比如，你能够开发你的下一个工程而只使用java代码吗？没有xml配置文件？没有O/R映射？没有ant编译代码？自动的业务流程也如此：流程语言一定需要跟其他技术结合起来使用。一个工作流引擎需要使所有的结合融入java程序环境。这就是流程虚拟机确切的能够提供的。
6    缺乏知识共享。今天的工作流市场是完全支离破碎的，每个引擎有它自己的流程语言概念和运行时概念。流程虚拟机的目的在于弥补这个鸿沟。每个程序员应该能在工作流，BPM和orchestration方面达成共识。
软件开发的许多方面是基于图形的，长运行的执行。为了这些用例，流程虚拟机能作为一个基本的库来使用。通过使用这个库，我们能明显的减少建立流程语言的花费。它也能使定制流程语言变得更加切实可行。
这篇文章实际上是各大领导开源社区达到共识的结果。这将使BPM,工作流和orchestration进入另一个层次。Red Hat(有JBoss jBPM)和Bull(Bonita,Orchestra)有多年的使用各种不同的流程语言和引擎的经验，以下的流程语言当前正在考虑形成一个单一的模型：JPDL,XPDL,BPEL,pageflow和线程流。
流程虚拟机结合了有限状态机，petri网和其他工作流建模方法的最好的想法。
嵌入性
    当前的BPM，工作流和orchestration系统作为一个整体的引擎而建立，不能很好的与java软件的开发结合起来。可是，软件工程项目只有流程的技术的非常少。在多数情况，流程需要与其他的技术结合起来。而面对这种情况，运行时的流程引擎能否与java程序在各个层次上结合变得非常重要，在部署模型(把整个引擎当作一个库)，事务处理，在关系数据库中的持久化处理和用户界面的交互这些层面上。在所有的这些层面上，工作流引擎应该能自然的与应用程序结合起来。流程虚拟机已经证明能在标准的和企业级的java平台中提供这种嵌入式的功能。
可插拔特性
最重要的可插入点是结点的实现。流程结构的运行时行为使用java来实现。流程虚拟机将提供API来实现结点的行为。如果你从这个角度来看待它，流程虚拟机相当于一个建立流程结构的组件模型。
为了让这个组件模型有效率，流程引擎使用的服务应该是可插拔的，例如：持久化，事务处理，身份组件，日志。为了弄清流程虚拟机如何能扩展来支持可插拔特性，请查阅流程虚拟机的全文。
另一边
流程引擎的市场现在完全是支离破碎的，不管是产品还是标准。至今为止的研究都是为了一种最好的流程语言。但是有这么多的不同的环境和不同的特点，一种流程语言将绝对不能满足要求。
在java领域方面，流程虚拟机的方法都是独特的。但是在另一边，在microsoft的领域里，在windows的流程基础运行方法与在流程虚拟机中提议的非常相似。两者本质上都是组件模型。一个流程结构被看作一个组件，一个API和程序包都当作组件来提供，用来实现流程结构。
    着两种技术有什么共同点，它们都把满足多个流程语言作为一个实现目标。因此它们都支持流程结构的组件模型，这意味着在这技术的基础上许多流程语言能被编译。这是一个流程引擎产品的全新的转换，不再去创建实现一个语言适用于多个应用环境的平衡的桥梁，这个问题反转过来了：用户被调整而来创建自己的流程语言。
    一些流程语言可能是用于某个特定的目的。例如：jPDL使用在java环境中，BEPL使用在企业服务总线ESB环境中。但是有许多实现有限而简单的流程语言的机会——例如，用来描述企业内容管理系统中流程审批的流程语言，用来描述多线程并发的流程语言，用来描述web应用系统页面流向的流程语言，等等。
基础
我想在具备了足够的背景资料之后，该是为了这块真实的肉而着手开始的时候了。以下这些是流程虚拟机的基本原则。整篇论文也将描述多个必须的扩展来应付多个可能的场景。
流程是一个执行流程的图形化描述。例如，支票记录的过程就是一个流程。它能被部署在流程引擎中。一个流程可以有多个执行。例如，我上周一的支票记录应该被支票记录流程的一个具体执行来处理。图1显示了一个保险索赔的流程。
图1：一个保险索赔的流程例子
流程的基本结构是由结点和转换组成。转换有一个指引的方向，因此一个流程构成一个有向图。结点也能有一组嵌套结点。图2显示了在UML类图，转换和结点如何建模。 
图2：结点，转换以及他们的行为组成的类图
流程中的每个结点都有相应的一块java代码与之相连，作为他们的行为。这是一个接口，与结点相关的java代码：
public interface Executable {
  void execute(Execution execution) throws Exception;
}
现在，我们看这个执行。一个执行是一个指针，保持流程图的当前位置的轨迹。就象图3所示： 
图3：流程图当前位置的一个执行点
当一个指定的流程的新的执行开始，初始时的结点将被指向这个流程的初始结点。之后，流程的这个执行将等待一个外部的触发。
一个外部的触发将通过执行的方法process(String transitionName)来实现。这样的外部触发与有限状态机的信号操作非常相似。这个执行知道怎么样解释流程图。通过调用流程方法，执行将进入指定的(或默认的)转换，到达这个转换的目的结点。然后，执行将更新它的结点指针，并调用相应的结点行为。
结点的行为通过执行有权访问当前的流程状态，执行被作为变量传递进来。这个相关更详细的描述在完整版的论文里面，实现了怎么样实现，例如，变量或者外部服务将通过执行来提供。
在另一方面，结点的行为能够控制执行的传播。这意味着可执行的实现能运转，就象一个等待状态，继续执行，创建并发执行，或者更新执行中的任何信息。
让我们来看看两个结点行为执行的例子。
1．    任务结点
为什么任务管理和工作流的关系如此紧密，是因为在软件系统中，人们的任务常常转化为等待状态。流程能使用以下的方式轻易的结合软件操作与人们的任务。
流程执行引擎之外第一个需要的事情是任务的存储，任务需要为了人们的使用而有一个空间来保存。紧接着组成的是，一个用户接口，它允许人们看到他们的任务清单，然后完成它们。
    然后你能设想以下的任务结点的执行行为。首先，一些外部触发必须被提供(使用流程的方法)以便流程能够开始执行，并且到达任务结点。任务行为的执行将为任务清单中指定的人们创建一个新的任务，任务也包含一个回退到相关的执行的操作。然后，结点行为在没有执行的传播时返回。这意味着当继续执行需要返回时执行将被指向任务结点。
public class TaskNode implements Executable {
  String taskName;
  public void execute(Execution execution) {
    // find the responsible person for this new task
    User assignedUser = calculateUser(taskName, execution);
    // create the task
    Task task = new Task(taskName, assignedUser, execution);
    // add the task to the repository
    TaskRepository taskRepository = execution.getContext().getTaskRepository();
    taskRepository.addTask(task);
  }
}
    这个taskName成员变量显示在流程定义文件中详细指定的配置信息应该怎么样被注入到行为对象中。
因此当系统正在等待用户完成任务时，执行能被持续保持。过一段时间后，当用户完成了任务，任务管理组件将使用相关的执行来提供一个触发。这个是用继续执行的方法完成的。然后执行将重新开始，离开任务结点，然后继续。
2．    决策结点
决策结点与任务结点不同在于它是自动的。一个条件需要评估并且基于评估结果；执行将立即被传播到一个离开转换。执行的传播是在决策结点的行为执行后，跟随执行方法的调用完成的，如下所示：
public class DecisionNode implements Executable {
  Condition condition;
  public void execute(Execution execution) {
    // evaluate the condition
    String outcome = condition.evaluate(execution);
   
    // propagate the execution with the outcome of the condition
    execution.proceed(outcome);
  }
}
执行的并发路径
整篇流程虚拟机论文描述对基本建模的表现以及之上的一系列扩展，例如，流程变量，动作，流程组合，异步执行，等等。但是最重要的扩展是合适的执行的并发路径。
    在一些情况下，一个执行是不够的，为了保存当前执行的状态。例如，流程的开账单部分可能包含很多步骤，航运部分包含许多步骤，但是航运和开账单可以并行完成。因此，执行可以扩展成父子关系，这意味着一个执行能拥有很多子执行，每个子执行指向流程图中的它自己。
异步结构
    基本上，基于消息队列和web服务的体系结构总是异步的结构。异步的通讯意味着发送和接收方不共享同一个线程。接收消息与发送消息完全独立。
    Web服务时，一个web服务调用的结果总是同步的返回。但是当你希望对方调用你的web服务时返回你对对方的web服务调用时，就需要用到异步了。
    现在我们来关心一个这样的软件系统的架构，许多系统使用异步的方式互相通信。当一个信息过来，系统必须回复，通过发送一个或多个信息到其他的系统。之后，这个系统可能希望相关的信息反馈。
    一个流程可以表达这种一个单一系统中相关信息的全部的流程。
总结
    有多种流程语言，每个语言都有它自己的环境和目标使用案例。一些语言是通用目的的，一些语言是就比较局限，用来专门应用的。
    流程虚拟机是一个简单但是强大的模型，它证明能支持各种工作流，BPM和orchestration语言。在这之上，它成为一个可插拔的，嵌入式设计的流程引擎。
    当前的工作流技术仅仅是集中在业务分析。业务分析员与开发者的协作被严重的忽视了。流程虚拟机给了业务分析员更多的建模的自由。并且，它能使开发者平衡流程技术嵌入java应用程序。
资源
·    The full paper on The Process Virtual Machine
·    JBoss jBPM
·    Bonita The XPDL workflow engine by Bull hosted at OW2
·    jPDL The workflow for Java process language of JBoss jBPM
·    JBoss SEAM Pageflow The process language build on jBPM for specifying navigation between web pages
·    Orchestra The BPEL engine from Bull hosted at OW2
·    JBoss jBPM BPELThe BPEL engine from JBoss build on top of jBPM
·    Windows Workflow Foundation
·    XPDL The workflow language defined by the WfMC and supported by Bonita
·    BPELThe service orchestration language defined by OASIS
Tom Baeyens is the founder and lead developer of JBoss jBPM, an open source workflow, BPM and orchestration engine. He is an employee of Red Hat and participates in the Java Community Process.
Miguel Valdes Faura is the Workflow Project Manager working for Bull R&D. He is also member of the OW2 Technical Council in which he is leading the Bonita Workflow project.

评论

2 楼 fly_ever 2007-06-04  

我也正在看完整的这篇，想翻译好了再贴上来。

1 楼 hantsy 2007-06-04  

这是jbpm作者写的，这只是摘录了一部分，原文比较长，
http://docs.jboss.com/jbpm/pvm/