流程虚拟机|虚拟机安装教程

　　有很多种语言与业务流程管理(BPM)、工作流、服务编制有关系，为简单起见，我们把这些语言都称为工作流语言。 　　工作流包括两个方面的内容：第一是流程建模，第二是流程自动化。工作流领域存在的最严重的问题是：现在的工作流技术不能同时适应这两个方面的内容。本文要讨论的主题就是怎么解决这个问题。
　　
　　流程虚拟机(Process VirtualMachine，下称PVM)并不定义流程语言，相反地，PVM认为不同的流程语言有不同的适用场景，所以应该容许多流程语言共存。
　　PVM定义了多个流程执行语言共享的公共模型，并且定义了把流程结构看作软件组件的策略，由此清晰地定义了把流程技术与软件开发技术结合的方法。
　　
　　组件技术
　　
　　要对流程语言进一步分解，是因为工作流要处理很多个不同的环境和特性。
　　以前，我们一直追求找到“最好的”流程语言，但是一直到现在，我们还没有发现一个流程语言可以在任何一个层面上覆盖另外一个流程语言。所以PVM秉持一个观点：不同的流程语言服务于不同的环境。
　　每一个开发者都知道，关系数据库的概念模型是关系模型，但是在工作流领域，一直没有出现对应的概念模型。
　　PVM期望通过为流程结构定义组件模型来解决这个问题。按这个思路，一个完整的流程语言作为一组流程结构的实现，将基于PVM而搭建。了解PVM的开发人员将能更好的了解流程语言，而且，我们希望PVM成为下一代工作流引擎的基础。
　　软件开发涉及到的语言越来越多，包括领域模型和把领域模型映射到不同框架的编程语言。现在的趋势是更少依赖编程语言、更多依赖开发框架，这里说的框架可能是一个库或者是一个DSL(领域特定语言)。
　　
　　这些框架用更简单更中立的方式来描述软件开发某一个方面的问题，这些框架有：带流程语言的流程引擎，带规则语言的规则引擎，带映射元数据的对象关系映射框架，语法解析器，带对象注入语言的IOC框架，带配置文件的web框架。
　　我们现在看到的一些DSL是基于图形的执行语言，PVM可以看作这些DSL的公共基础，主要用来减少设计、实现、维护的成本。流程语言在PVM的基础上是可插拔的。
　　
　　嵌入式了作流
　　
　　只有很少一部分的流程自动化项目必须用流程语言来实现。有些BPM套件追求“无代码”的目标，但是他们只合适用在完全用流程建模的项目，我们认为工作流只可以在某些特定的方面帮助简化软件项目。一个软件项目涉及到很多的方面，只有其中几个方面才合适用流程来建模。
　　嵌入式工作流的含义是：流程引擎很容易地集成到软件开发项目中。与它相对的，是传统的独立的BPM服务器。
　　软件行业的总体趋势，是越来越多地使用DSL，嵌入式工作流符合了这一潮流：流程语言就是在软件项目中的DSL语言。工作流是对传统编程方式的补充，开发者应该可以自由地选择不同的流程语言。
　　对于嵌入式工作流来说，有下面的几个关键点：
　　持久化。工作流引擎应该与软件项目实际的持久化技术解藕。持久化技术应该是可选的，开发人员应该可以选择JPA、JAVA序列化、XML序列化等不同的技术，如果采用了关系数据库来持久化，开发人员可以让工作流引擎使用与软件项目不同的数据库，或者用同一个数据库中的不同的表结构，放在不同的数据库中可以保证更好的可管理性。
　　
　　服务。服务应该是可插拔的，比如定时器服务或者异步消息服务，软件开发人员在不同的环境中可以使用不同的服务，比如在标准Java环境可以使用定时器服务，在企业JAVA环境可以使用异步消息服务等。
　　事务。如果工作流引擎可以和应用工作在同一个数据库连接下，就没有必要使用全局事务或者分布式事务，这样可以很大程度上减少复杂度。
　　库管理。除了传统的王作流引擎独立部署方式，更实际的方式是把引擎的库部署在应用系统中。 可测试性，可执行流程也是软件，所以它应该和普通软件一样可测试。对流程的测试应该在不同的场景下执行，这些场景可以集成到应用系统的基本测试体系中。
　　绑定。应该很容易就可以在应用开发中绑定流程逻辑。可执行的流程由可视的图形和技术细节组合而成。到目前为止，流程工具主要关心可视的图形，但是一个软件项目总是包括多个语言比如JAVA、流程语言、脚本语言等。所以我们期望流程工具要关心更多的内容，比如对JAVA类的重构，可能会涉及到JAVA类文件的更新和流程定义文件的更新。
　　
　　范围
　　
　　我们已经讨论过，PVM是多个流程语言的公共基础。PVM之上的流程语言需要具备三个方面的特征：
　　首先是流程通过图形的方式来表达，由此促成流程各个相关人员的沟通。
　　其次是流程能够描述控制流。
　　最后是从引擎的角度看，流程可以包括等待状态，它是“长时间运行”的流程。
　　不只是现在已经有的工作流语言才符合PVM的标准，满足上面三个特征的流程语言都可以基于PVM而存在。比如页面流，用来描述在WEB应用中页面之间流转规则的流程语言，就可以基于PVM。
　　
　　PVM基本原则
　　
　　下面我们讨论PVM的几个基本原则。讨论完基本原则，我们再讨论一些扩展原则，由此得到设计一个流程语言的主要内容。
　　流程是执行流的图形化描述，一个流程可以有多个执行实例。下面是一个流程图的例子。
　　流程的基本结构由节点和迁移组成。迁移是方向敏感的，所以流程就是一个有向图。节点是自包含的(一个节点可以包括多个节点)，下图列出了节点和迁移在UML图中的表达。
　　
　　流程中的每个节点，对应于代表它行为的一段Java代码。这段Java代码都实现了同一个Java接口。下面我们看看运行时的数据结构，每个“执行”是一个指针，它指向流程执行的当前位置，如图3所示。
　　在流程刚启动时，“执行”指针指向流程的起始节点，然后，“执行”就等待外部的触发器。“执行”的类如图4所示。
　　对“执行”对象执行proceed方法，就是一个触发器。这样的触发器与FSM(有限状态机)的signal操作非常相似。“执行”对象知道怎么解析流程图，通过调用proceed方法，“执行”对象将沿指定的迁移路线执行，到达迁移的目标节点。然后，“执行”对象将更新它的节点指针，调用节点的行为动作。
　　“执行”对象作为参数传给节点对象，这样节点就知道了流程的当前状态。从另外一方面看，节点 的行为控制了“执行”对象的传播。这意味着节点的思想可以是一个等待状态、继续执行状态、并发执行状态、更新信息状态等。
　　
　　任务节点
　　
　　工作流与任务管理密切相关，这是因为人工任务经常被对应到软件系统的等待状态。在流程执行引擎之外需要一个任务库，用来存放人员的任务。在任务库之上有一个用户界面，人员通过界面看到任务列表，并且执行任务。
　　我们可以大致想象任务节点的大致行为表现。
　　首先，触发器被触发，流程执行到达任务节点，然后任务节点从任务列表组件中找到应该为谁产生任务，然后为该人员产生任务，最后把这个任务添加到任务库中去。任务节点返回时，不会传播“执行”对象的状态，这意味着流程的状态将停留在任务节点。
　　在系统等待用户完成任务时，任务的状态可以被持久化。等到用户完成任务时，任务管理组件将利用“执行”对象的引用，向流程启动一个触发器。
　　
　　邮件节点
　　
　　邮件节点与任务节点不同，因为它是自动节点。邮件节点执行时，先发送一封邮件出去，然后流程马上沿指定的迁移执行。流程的执行是调用“执行”对象的proceed方法实现的。
　　
　　图形化表达
　　
　　流程虚拟机的基本概念，表达了一个有向图怎么样执行。流程由节点和迁移组成，因此节点和迁移与图形有直接的关系。流程虚拟机的图形结构覆盖了流程语言的大多数概念，但是流程语言可以对流程虚拟机进行概念的扩展，比如定时器、数据流、条件等。
　　我们在任务节点的内容中知道，节点可以表达等待状态。当流程到达任务节点，流程将进入等待状态，等待一个外部的触发器。在这个时候，一般需要把流程的“执行”对象持久化。
　　有了等待状态，流程就可以表示跨越软件操作和人工任务的执行流，这就是我们平常说的“长期运行流程”。
　　
　　同步执行
　　
　　当客户端调用proceed方法时，“执行”对象将在一个线程中解释和执行一个流程。“执行”对象选取一个迁移，然后执行目标节点的内容。
　　当“执行”对象调用目标节点的行为时，它把它自己作为参数传人。那么节点就可以继续调用“执行”对象的proceed方法了。要注意这仍然是在客户端线程执行的，它等待原始的proceed方法的返回。
　　这意味着“执行”对象永远是在客户端被解释。缺省的情况是实现同步执行，这样可以限制事务数，提高性能。