CN102662725B - 一种事件驱动的高并发流程虚拟机实现方法 - Google Patents

Abstract

本发明公开了一种事件驱动的高并发流程虚拟机实现方法，属于软件技术领域。本方法为：1)建立一基于事件驱动的流程运行时模型，用于描述目标流程语言的执行语义；2)流程解析器将目标流程语言描述的流程运行时模型转化为事件驱动的执行结构，由运行时引擎进行执行；3)运行时引擎采用两级事件队列-多调度器的调度方式执行转化后的执行结构。与现有技术相比，本发明面对流程语言的更新和变化，具有很高的扩展能力及灵活性，同时本发明提高了并发执行性能，能够应对高负载压力。

Description

一种事件驱动的高并发流程虚拟机实现方法

技术领域

本发明涉及一种事件驱动的流程模型构造方法，以及一种基于事件驱动的高并发流程运行环境实现方法，属于软件技术领域。

背景技术

对于商业软件系统来说，理解其系统功能和需求十分重要，软件系统的实际需求和功能通常可以通过业务流程建模(Business Process Modelling)来表示。一个业务流程(BusinessProcess)可以被定义为“一系列相互关联的活动或者程序集合，它们有序的组合在一起以实现一个完整的业务目标”(参见文献：Business Process Modeling Languages：Sorting Throughthe Alphabet Soup，ACM Computing Surveys，November 2010)。

业务流程建模技术常用于描述和表达隐藏在软件系统功能后面的业务逻辑，并且已广泛应用于现在的软件系统中(包括电子商务系统，物流系统，企业管理系统等)，按照其目标可以被划分为三个层次：流程描述(Descripting a process)，流程分析(Analyzing a process)和流程演练(Enacting a process)。其中，流程演练通常是指流程的模拟和执行。流程的可执行性对于业务流程的分析，调试和重构来说十分重要，只有在实际的执行中才能更好地发现，优化和解决问题。因而随着流程描述语言的发展，也促使了流程执行环境(流程引擎)的出现和发展。

工作流系统是目前常用于业务流程建模和执行的系统，它将这些流程表示为一系列相互交互的片段(Segments)或者事务(Tansactions)，通过各种控制逻辑将它们组合在一起以表达和实现一个复杂的业务功能。工作流系统不仅提供了业务流程的描述和表示功能，通过将流程部署到对应的工作流引擎，进一步实现了业务流程的模拟和执行功能。

在软件系统web化的大趋势下，流程中的很多子功能活动通常都以服务的方式被实现和调用，因此从另一个角度来说，这些流程也可以看做一个组合服务，它按照业务逻辑组合了各个子服务以供复杂的复合服务功能。业务流程的执行在SOA的环境中也可看做组合服务的执行，例如WS-BPEL(Business Processs Execution Language)。

随着业务流程建模及工作流技术的发展，已陆续涌现出了大量流程描述语言，包括XPDL，BPMN，XLANG，WSFL，WS-BPEL，WS-CDL等等，它们用于描述不同的领域中各种各样的业务流程，然而当前传统的流程执行引擎通常只能服务于某一种特定的流程语言，这就使得针对每一种流程语言都需要实现一个专门引擎来支持它的执行。因而，JBoss将其流程建模系统实现于一个抽象的模型层上，实现了支持四种流程语言(jBPM，BPEL，WSDL，JPDL)执行的通用内核，从而提出了流程虚拟机(PVM，Process Virtual Machine)的概念。如图1所示，一个流程虚拟机可以定义为“一个同时支持多种流程语言执行的运行时环境”。

另一方面，为了能够应对企业级的业务流程，业务流程引擎需要具备较高的并发处理能力。最近的研究表明现在大部分的开源流程引擎(包括ApacheODE，ActiveBPEL，JBoss的JBPM)在高负载下都存在严重的性能问题，无法胜任企业级的应用(参见文献：D.Bianculli，W.Binder，M.L.Drago：Automated Performance Assessment for Service-OrientedMiddleware：a Case Study on BPEL Engines，WWW 2010)。

这些当前的主流的开源流程引擎都主要采用了线程驱动的架构。线程驱动和事件驱动是实现并发系统的两种常用泛型，当前主流的编程语言和操作系统都提供了对多线程的支持，线程驱动的特征是同步执行，架构简单，易于实现，容易维护，因此也普遍被应用于服务器端的引擎架构。

事件驱动的架构将任务看做等待特定事件的操作或活动，任务的执行不再是同步的调用-返回过程，而是被动触发，异步执行的方式。这使得这种架构，耦合度比较低，灵活性高，同时在面对一些高并发交互型负载时具有较强处理能力，这些优势使其适用于交互性较强的用户界面编程(如VB)及松散架构的环境(分布式系统)。但是事件驱动的架构较难于很好地设计实现，增加了系统结构的复杂度，这是很多系统没有采用这一架构的主要原因。

这两种并发泛型虽各有优劣但其本质上是等价的，选择哪一种架构，取决于软件系统的底层支持和应用环境特征(参见文献：H.C.Lauer，R.M.Needham：On the duality of operatingsystem structures.In Second International Symposium on Operating Systems，IR1A 1978)。

通过对业务流程应用的观察和分析，我们觉得线程驱动的架构并不太适合工作流引擎的运行时环境，其原因主要包括以下几方面：1)业务流程多处于一种松散的执行环境中，执行流程中消息交互可能比较频繁，会有大量的消息被发出和接收，它们可能和多个第三方的服务进行交互与访问，同步的消息的交互会浪费大量CPU资源在忙等状态；2)业务流程的执行通常是一个时间开销较大的过程，线程驱动独占式的分配方式会带来大量的资源浪费并成为并发性能瓶颈；3)在业务流程逻辑较为复杂的情况下，一个完整的流程实例是一个十分重量级的执行单位，高负载情况下创建和维护这些实例会带来大量开销，同时也不利于性能优化。

发明内容

本发明的目的在于灵活支持多种流程语言的执行，同时针对线程驱动架构无法适应高并发压力的主要问题，提出一种事件驱动的流程执行架构，提供轻量级，高并发，同时又具有较强通用性的流程引擎实现方法。

本发明采用的技术方案为：

一种事件驱动的高并发流程虚拟机实现方法，其步骤为：

1)建立一基于事件驱动的流程运行时模型，用于描述目标流程语言的执行语义；

2)流程解析器将目标流程语言描述的流程运行时模型转化为事件驱动的执行结构，由运行时引擎进行执行；

3)所述运行时引擎采用两级事件队列-多调度器的调度方式执行转化后的执行结构。

进一步的，所述流程运行时模型包括：活动、事件、端口、上下文；其中，活动的类型包括连接器和任务活动；所述连接器类型活动用于检查当前执行状态下的控制条件，以决定后续流程的执行方向；所述任务活动类型活动用于实现具体任务功能的操作；所述事件用于承载活动之间的通信消息；所述端口用于活动中接收和发送事件；所述上下文为用于保存流程当前执行状态。

进一步的，所述连接器类型包括：与连接器、或连接器、条件选择连接器，所述连接器包括前置连接器和后置连接器；所述任务活动类型包括：服务调用活动、赋值活动；所述事件包括：开始事件、完成事件、外部事件、异常事件；所述上下文包括流程上下文、实例上下文；所述流程上下文用于维护当前执行流程的流程结构，变量和消息定义，并提供路由服务和对象池服务的访问接口，所述实例上下文负责维护每一个运行时流程实例的执行状态信息，当前待执行或正在执行的活动及其状态，事件队列访问接口。

进一步的，一个活动与一个或多个端口对应。

所述运行时引擎对每一所述活动分配一个唯一的名字；其中，命名规则为：活动名称＝[语言类型]_[流程标识]_[活动类型名]_[流程局部编号]；所述运行时引擎根据产生事件的活动和事件类型对所述事件进行命名；其中，命名规则为：事件名称＝事件_[活动名称]_[事件类型]。

进一步的，所述流程解析器将目标流程语言描述的流程运行时模型转化为事件驱动的执行结构的方法为：首先，流程解析器将流程描述语言中的控制逻辑转化为具有等价执行语义的连接器或者连接器的组合，将流程描述语言中所有的任务节点的功能逻辑实现为一系列任务活动；然后，将活动之间的流程路径映射为事件的发布订阅关系，并维护一份事件路由表。

进一步的，所述目标流程语言为通过XML标签形式描述的流程语言；所述流程解析器包括一解析器管理模块、一主解析器和若干子解析器；其中，所述解析管理器模块用于管理标签或关键词到子解析器的映射；所述主解析器用于完整遍历目标语言描述的流程信息，以及遍历过程中决策和判断，同时调用子解析器对流程中的子结构进行进一步解析；所述子解析器用于对子结构的具体语法单元或者结构体进行解释和映射，将其构建成为运行时可执行对象。

进一步的，所述主解析器的遍历方法为：

a)在引擎初始化时，在一个Map数据结构中初始化目标流程语言所包含的标签和主解析器的映射关系表；

b)启动主解析器，遍历流程的XML描述，每当遇到一个标签时，判断是开始标签还是结束标签；

c)如果是开始标签，则获得标签名字并通过解析器管理模块查询映射关系表，如果不存在则打印出错信息；如果存在已注册映射关系，则将当前解析器压入栈，取出新标签对应的子解析器设为当前解析器；

d)主解析器调用子解析器接口创建一个该标签对应的运行时对象，对于标签的所有属性，主解析器调用该子解析器接口将该标签的属性转换为运行时对象的属性；

e)如果是结束标签，则取出其标签名与当前解析器比较；如果不相同，则打印出错信息；如果相同，则判断当前解析器是否创建了新的对象，如果是，则将获取并暂存该新对象，弹出当前解析器，从栈中取出栈顶解析器作为新的当前解析器，并为其添加前一解析器创建的对象。

进一步的，所述运行时引擎执行转化后的执行结构的方法为：

a)所述运行时引擎为执行结构中每一个流程实例设一子队列，所有被激活的子队列按照先入先出的顺序连接成一个链接表，即主队列；

b)当主队列非空时，所述运行时引擎从主队列中依次取出子队列并进行调度处理；

c)所述运行时引擎每次取出一个待调度的子队列后，依次从中取出事件并利用事件路由服务进行事件匹配查询该事件触发的活动，然后执行被触发的活动。

进一步的，所述运行时引擎采用细粒度的对象池技术执行被触发的活动，其方法为：

a)所述运行时引擎通过对象池获取一个该活动类型的对象实例，如果当前没有可用实例，则创建一个新的该类型对象实例；

b)该活动类型的对象实例被执行完毕之后，所述运行时引擎清除该活动类型的对象实例的状态并将其返回对象池。

本发明主要包括如下步骤：

1)建立了一种事件驱动的流程运行时模型，如图2所示，该模型是流程描述在引擎中执行的实际对象，能够适应和描述主流流程语言的执行语义；

2)提供流程描述语言的描述模型到步骤1)事件驱动的运行时模型的转化方法；通过这一方法可以使多种描述语言都以统一的事件驱动的执行结构在引擎中执行。

3)构建了基于步骤1)事件驱动流程模型的运行时引擎系统(即流程虚拟机)，如图3所示，该系统能够同时支持多种类型的流程执行；

4)提供针对步骤2)事件驱动执行结构的运行时优化方法，优化流程的并发性能；

1.事件驱动的流程运行时模型定义如下：

事件驱动的流程运行时模型层次图如图2所示，我们定义事件驱动的流程运行时模型主要包括下面四个部分：活动(action)，事件(event)，端口(port)，上下文(context)。

1)活动(action)，主要包括两种类型：连接器(Connector)和任务活动(Behavior Action)

a)连接器(Connector)，它是一种抽象的结构用于检查当前执行状态下的控制条件，以决定后续流程的执行方向。它可以被实现为包含具体控制语义的连接结构，如“与连接器(And-Connector)”，“或连接器(Or-Connector)”，“条件选择连接器(Condition-Connector)”等。在我们的执行模型中，一个具体的任务活动通常包含两个连接器结构：前置连接器，和后置连接器，分别用于活动的开始状态和完成状态的检查。

b)任务活动(Behavior Action)，用于实现实际任务的功能性结构的统称，它可以被实现为具有具体功能的操作如“服务调用活动(Service Invoker)”，“赋值活动(Assign)”等。

2)事件(event)，用于承载活动之间通信消息的一种数据结构。在我们的引擎中事件结构定义如下：

事件头部(EventHead)：事件头部包括事件的基本描述信息，主要包括：事件名(EventName)、事件类型(EventType)、事件所属的流程标识(processID)、产生事件的实例标识(instanceID)、时间戳(TimeStamp)等。

事件体(EventBody)：事件体包含了需要由事件从上一个活动传递到下一个活动的消息参数，该参数由活动执行后在运行时产生和修改。例如：一个异常事件可以将对应的异常代码放在事件体中传递到后续活动节点。

在流程执行过程中，不同类型的事件表达了活动执行的不同状态，主要包括：开始事件(start event)，完成事件(complete event)，外部事件(external event)，异常事件(exeption event)等。

a)开始事件：开始事件通常由一个活动的前置的连接器产生，用于通知后续的活动开始执行。

b)完成事件：完成事件可以产生于任何活动(包括后置连接器和任务活动)执行完成之后，它表明了该活动的成功执行，同时也可以用作触发后续活动开始执行的通知事件。

c)外部事件：在一个业务流程中经常需要接收流程之外的输入来进行交互或者触发后续活动(例如，用户输入，web消息接收等)，这些来自流程外部的事件都被统一表示为外部事件。

d)异常事件：流程执行的过程中不被期望发生的事件(错误事件和警告事件)或者非预见性的事件(如：未定义的事件)都被标记为异常事件，异常事件通常会触发异常处理流程，甚至导致该流程执行终止。

3)端口(port)：活动中用于接收和发送事件的数据结构(每个端口实际可以看做小的事件接受/发送队列)，通常一个活动可能持有多个端口，分别对应可能接收和发送的多个事件。

4)上下文(context)，用于保存流程当前执行状态的数据结构，流程执行中任何和业务逻辑相关的状态变化都会以变量的方式被存储于上下文中，一个流程实例执行时只会有一个上下文结构，它会被依次传递给这个流程中正在执行的活动。

在事件驱动的执行过程中，一个流程被分割为多个活动，它们之间的关联通过事件异步触发，从而实现了一种松散的异步执行过程。

2.一种流程描述语言到事件驱动执行结构的转化方法，主要包括下面几个步骤：

1)将流程描述语言中所有的控制逻辑转化为具有等价执行语义的连接器(connector)或者连接器的组合；

2)将流程描述语言中所有的任务节点的功能逻辑实现为一系列任务活动(BehaviorAction)；

3)将活动之间的流程路径映射为事件的发布订阅关系，并维护一份事件路由表；

经过以上三个步骤后，由特定流程语言描述的流程执行结构就被转化为事件驱动的执行模型，由运行时引擎进行执行。对于转换后的执行模型，需要运行时引擎来支持其执行。

3.基于事件驱动流程模型的运行时引擎，其架构主要包括三个层次：

1)第一层主要包括事件队列，及事件调度分发器，负责事件的接收、调度和分发。

2)第二层主要包括运行时管理模块，负责上下文管理，线程调度执行，web服务调用等。

3)第三层主要包括一些运行时引擎所需的基本服务，包括命名服务，线程池，对象池，事件路由服务。

运行时一个流程实例的执行过程如下：

1)首先，流程的调用者发送流程开始的外部事件到引擎，该事件被放到事件队列中等待调度。该事件会触发流程实例的实例化并触发第一个活动的执行。

2)发现事件队列非空时，事件调度器会从事件队列中依次取出事件，如果是一般事件(异常事件和终止事件以外的事件)，则转3)；如果是异常事件，转5)；如果是终止事件则终止该事件对应的执行实例。每次调度后，如果队列非空，事件调度器继续调度，否则暂时休眠等待新的事件到来。

3)通过事件路由服务找到该事件触发的活动(Action)，将这些活动交给线程调度器，线程调度器为每个提交的活动(Action)分配一个线程，并让其开始执行；

4)一般的活动正常执行完成后，线程和活动对象会被回收，并产生活动完成的新事件而流程的最后一个活动执行完成后，会产生一个终止事件，这些事件都会被自动添加到事件队列，转2)；

5)对于异常事件，通过同样路由服务找到异常处理活动，启动异常处理流程，并终止原实例的执行。

4.运行时引擎提供了事件驱动执行结构的优化机制，主要包括轻量级流程实例和对象池技术。

1)轻量级流程实例，为了实现流程执行状态与执行逻辑的分离，系统中提供了流程上下文和实例上下文两类上下文：

a)流程上下文(process context)：维护该执行流程的流程结构，变量和消息定义，并提供路由服务和对象池服务的访问接口，这些信息都是流程部署后基本不会改变的静态信息。通常，一个流程结构可能会有多个流程并发实例在执行，流程上下文可由同一个流程结构的多个并发实例所共享。

b)实例上下文(instance context)：负责维护每一个运行时流程实例的执行状态信息，包括：实例标识信息，变量值信息，当前待执行或正在执行的活动及其状态，事件队列访问接口。这些信息都是每个流程实例执行时产生和需要维护的动态信息，每个执行实例会持有一份独立的实例上下文。

这些上下文是独立于执行逻辑独立进行维护的，这使得一个流程实例执行的任意时刻，只需要持有当前待执行的活动和该实例对应的上下文信息。这使得一个流程的执行体十分的简洁和轻量级，在大量并发的执行环境下，流程实例的数量巨大并且常常切换执行，这种轻量级的机制大大减少了流程实例化和实例切换的消耗。

2)细粒度对象池技术：在事件驱动的运行时环境中，由于流程执行状态与执行逻辑分离，流程中某一活动在执行后变得无状态，因此可以立即被其他实例所重用，相比传统引擎中以流程实例为单位的缓存，提供以活动为单位的对象池供大量个流程实例共享使用，即细粒度的对象池技术。其工作机制描述如下：

a)当一个活动被触发执行后，调度器试图通过对象池获取一个该活动类型的对象实例，如果当前没有可用实例则创建一个新的该类型对象实例；

b)该活动实例被执行完毕之后，会被清除状态并返回对象池；

c)被返回对象池的对象实例可以立即被分配给新的对象请求并执行。

与现有技术相比，本发明的积极效果主要为：

1.具有很高的扩展能力及灵活性

通过定义上述完整的层次化的事件驱动的执行模型，使得引擎可以灵活组合这些基本结构已实现不同的复杂的流程执行语义，针对不同的流程语言，只需要实现从它的描述模型到引擎执行模型的映射就能支持其执行，以此提供了同时支持多种流程语言执行的能力。面对流程语言的更新和变化，也能够通过灵活变化基本结构的组合或者扩展新的基本结构来应对。

2.提高并发执行性能，能够应对高负载压力

我们的流程虚拟机采用了事件驱动的执行架构，避免了传统线程驱动的同步开销和冗余的“忙等”消耗，提高了CPU的有效利用率；系统采用了轻量级的执行单位，将执行逻辑与执行状态(上下文)进行分离，结合优化的对象池技术，大大减少了并发执行多个流程实例消耗的系统资源以及多线程上下文切换带来的损耗，从而提高了系统的吞吐量。

附图说明

图1流程虚拟机概念图。

图2事件驱动的流程运行时模型层次图。

图3事件驱动的运行时引擎系统架构图。

图4细粒度对象池技术的工作机制示意图。

(a)流程实例初始化，(b)新实例复用旧实例创建的活动对象，

(c)多个实例间的对象复用，(d)实例终止后，其创建的活动对象依然被其他实例复用。

具体实施方式

1.流程解析

为了让各种类型的流程描述语言都能在流程虚拟机中执行，需要在部署时对这些流程进行解析将其转换为可执行的运行时对象，流程解析的实施主要包括三个部分：

1)解析器管理模块(Reader Manager)：负责管理标签或关键词到子解析器的映射，这些映射关系也可动态注册和改变。

2)主解析器(Handler)：对于每一个特定流程描述语言为其实现一个主解析器，它负责完整遍历这个语言描述的流程信息，负责遍历过程中决策和判断，同时调用子解析器对流程中的子结构进行进一步解析。

主解析器维护了一张解析器映射表和一个主遍历算法。解析器映射表保存了每一个标签对应的子解析器对象；主遍历算法的功能就是深度优先遍历流程的描述结构(一般为XML文件描述)并对每个子标签调用对应的子解析器进行解析。

3)子解析器(Reader)：对于流程描述语言中每种结构会实现一种满足其语义的子解析器，它负责对该结构的具体语法单元或者结构体进行解释和映射，将其构建成为运行时可执行对象。例如，对于BPEL这类基于XML的流程描述，通过对每一个标签构建一个解析器，将其表示的结构和语义映射为运行时可执行对象。

目前引擎实现了一套对于基于XML描述的流程语言的支持，这些流程语言通常采用XML标签形式将流程描述为嵌套式的树形结构，主解析器实现采用了深度优先的基于标签的遍历算法，算法如下：

[1]在引擎初始化时，初始化主解析器中的标签到子解析器的映射关系表，维护在一个Map数据结构中。

[2]启动主解析器；主解析开始遍历流程的XML描述，每当遇到一个标签时，判断是开始标签还是结束标签，开始标签则转到[3]，结束标签转[6]，没有新的标签则结束解析；

[3]对于开始标签，获得标签名字，并通过解析器管理模块查询映射关系，如果存在已注册映射关系则转[4]，否则打印错误信息；

[4]将当前解析器压入栈，取出新标签对应的子解析器设为当前解析器，转[5]；

[5]主解析器调用子解析器接口创建一个该标签对应的运行时对象，对于标签的所有属性，主解析器调用该子解析器接口将该标签的属性转换为运行时对象的属性。然后遇到新的标签时转[2]；

[6]对于结束标签，取出其标签名，与当前解析器比较，如果相同，则说明一个子结构已解析结束，转[7]，否则打印出错信息；

[7]判断当前解析器是否创建了新的对象，如果是，则将获取并暂存该新对象，弹出当前解析器，从栈中取出栈顶解析器作为新的当前解析器，并为其添加前一解析器创建的对象(此时前一层解析创建的对象为当前解析器的子对象)，继续解析转[2]。

2.命名服务实现

命名服务对于事件驱动的系统来说十分重要，主要负责提供高效便捷的命名机制为事件、活动的调度和匹配服务。

在我们的实现中，出现在一个流程中的每一个活动(Action)都会被分配一个唯一的名字(ActionName)，命名规则如下：

ActionName＝[语言类型]_[流程标识]_[活动类型名]_[流程局部编号]

其中，各个参数说明如下：

1)语言类型，包括BPEL，XPDL，BPMN等；

2)流程标识是为每一个部署流程分配的唯一标识；

3)活动类型名，该活动所属活动类型的名字，例如，对于“与连接器”则为AndConnector，

4)流程局部编号：每一个流程子结构都会获得一个该流程内部的唯一编号，以区分同一活动类型在一个流程中多次出现的情况；

另外，引擎中所有出现的事件都会根据产生它的活动和事件类型进行命名：

EventName＝Event_[ActionName]_[事件类型]

其中，事件类型包括，开始事件(StartEvent)，完成事件(Complete Event)，外部事件(External Event)，异常事件(Exception Event)等。

通过这两个规则进行命名后，同一个流程实例内部的事件和活动都可以通过其名字进行唯一的识别。

3流程部署过程

流程部署过程主要是为了建立事件到流程各个活动的事件路由表，通过前述的解析过程得到各个活动对象，并通过命名服务将其注册后，每个活动都会活动在该流程中唯一的名字标识。在这些基础之上，对于解析到得的每一类型的活动为其建立一个构造器(builder)，该构造器按照前述发明内容第二部分的“事件驱动执行结构的转化方法”将其转化为运行时结构，并将这些活动之间的事件映射关系保存在事件路由表中，供运行时调度使用。该转换实际实现如下：

1)将一个活动中的控制逻辑(如选择，分支，循环，并行等)映射为具有等价执行语义的连接器(connector)或者连接器的组合；在命名服务中注册这些连接器并将它们之间的连接事件添加到事件路由服务。

2)对于活动中的功能逻辑(如服务调用、赋值、任务执行等)映射为实现了该功能的任务活动，注册该任务活动到命名服务，并将该活动的触发和完成事件添加到事件路由服务。

3)对于异常处理活动将其异常处理流程添加到异常处理模块；对于每个流程的最后一个活动，将其完成事件注册为终止事件，添加到路由服务。

部署过程会将解析后的流程对象中的每个活动依次调用其构造器，构造器执行结构并注册事件关系，使其能够被调度器调度执行。

4.事件调度及流程执行

运行时的事件调度交由专门的调度器(Scheduler)负责，目前运行时的流程调度采用两级事件队列-多调度器的调度方法，该调度方法工作机制描述如下：

1)每一个流程实例持有一个属于自己的事件队列(子队列)，当有新的事件进入这些子队列后他们会被激活，所有被激活的子事件队列按照先入先出的顺序连接成一个链接表(即主队列)；

2)当主队列非空时，调度器会从中依次取出子队列并进行调度处理；

3)调度器每次取出一个待调度的子队列后，依次从中取出事件并利用事件路由服务进行事件匹配查询该事件触发的活动，最后交由执行器执行被触发的活动。调度器每次会将一个子队列的事件调度完之后才会切换到下一个子队列(如果存在的话)。

4)当主队列中没有被激活的子事件队列时，所有调度器会进入休眠状态直到下次新事件来临。

事件调度器的调度算法具体实现逻辑如下：

[1]如果主队列不空，从中取出第一个子队列；否则休眠，直到队列收到非空的通知

[2]如果子队列非空，则依次取出队列首部第一个事件，判断事件类型，普通事件转[3]，错误事件转[4]，终止事件转[5]；

[3]通过事件路由服务的路由表找到该事件触发的活动(Action)列表，对于列表中的每一个活动(Action)，从对象池中获取它的一个实例，为其发送该事件通知，然后将这些Action交由执行器进行执行；调度器进入下一次调度，转[1]；

[4]对于错误事件，进入错误处理流程，根据错误事件携带的信息进行对应处理，然后进入下一次调度，转[1]；如果是致命错误，则打印错误信息并终止该实例的执行，转[5]；

[5]进入实例终止流程，清理执行状态，并删除流程实例信息。

4.对象池实现

运行时引擎的对象池技术主要用于动态回收执行完成的Action对象并将其重新分发给需要执行同一类型Action的流程实例。对象池主要负责维护以下几个部分数据：

1)流程中定义的各个Action对象的原型，这些原型对象不会被分配出去，仅用于克隆生成新的Action对象；

2)每类Action对象的缓存池，用于回收缓存使用过的Action对象提高重用率；

3)对象类型名到对象缓存池的映射表，用于获取Action对象实例的查找过程。

对象池的处理主要可以划分为两个阶段，分发阶段和回收阶段：

1)分发阶段：当事件调度器向路由服务请求事件的监听队列时，路由服务实际返回的是监听对象的类型信息，因此，执行器获得这些对象类型信息后，还要从对象池请求一个类型的对象才能真正执行。对象池会优先返回一个被回收的对象实例，如果缓存队列为空，才会创建一个新的对象返回。

2)回收阶段：在执行器拿到Action对象并执行完毕后，它会调用对象池接口回收这个对象，回收后的对象会被按照对象类型缓存在对象池中供下次分配。对象池的工作机制见图4。

Claims (9)

1.一种事件驱动的高并发流程虚拟机实现方法，其步骤为：

1)建立一基于事件驱动的流程运行时模型，用于描述目标流程语言的执行语义；其中，所述流程运行时模型包括：活动、事件、端口、上下文；活动的类型包括连接器和任务活动；所述连接器类型活动用于检查当前执行状态下的控制条件，以决定后续流程的执行方向；所述任务活动类型活动用于实现具体任务功能的操作；所述事件用于承载活动之间的通信消息；所述端口用于活动中接收和发送事件；所述上下文为用于保存流程当前执行状态；

2)流程解析器将目标流程语言描述的流程运行时模型转化为事件驱动的执行结构，由运行时引擎进行执行；

3)所述运行时引擎采用两级事件队列-多调度器的调度方式执行转化后的执行结构。

2.如权利要求1所述的方法，其特征在于所述连接器类型包括：与连接器、或连接器、条件选择连接器，所述连接器包括前置连接器和后置连接器；所述任务活动类型包括：服务调用活动、赋值活动；所述事件包括：开始事件、完成事件、外部事件、异常事件；所述上下文包括流程上下文、实例上下文；所述流程上下文用于维护当前执行流程的流程结构，变量和消息定义，并提供路由服务和对象池服务的访问接口，所述实例上下文负责维护每一个运行时流程实例的执行状态信息，当前待执行或正在执行的活动及其状态，事件队列访问接口。

3.如权利要求1所述的方法，其特征在于一个活动与一个或多个端口对应。

4.如权利要求1所述的方法，其特征在于所述运行时引擎对每一所述活动分配一个唯一的名字；其中，命名规则为：活动名称＝[语言类型]_[流程标识]_[活动类型名]_[流程局部编号]；所述运行时引擎根据产生事件的活动和事件类型对所述事件进行命名；其中，命名规则为：事件名称＝事件_[活动名称]_[事件类型]。

5.如权利要求1或2或3或4所述的方法，其特征在于所述流程解析器将目标流程语言描述的流程运行时模型转化为事件驱动的执行结构的方法为：首先，流程解析器将流程描述语言中的控制逻辑转化为具有等价执行语义的连接器或者连接器的组合，将流程描述语言中所有的任务节点的功能逻辑实现为一系列任务活动；然后，将活动之间的流程路径映射为事件的发布订阅关系，并维护一份事件路由表。

6.如权利要求5所述的方法，其特征在于所述目标流程语言为通过XML标签形式描述的流程语言；所述流程解析器包括一解析器管理模块、一主解析器和若干子解析器；其中，所述解析管理器模块用于管理标签或关键词到子解析器的映射；所述主解析器用于完整遍历目标语言描述的流程信息，以及遍历过程中决策和判断，同时调用子解析器对流程中的子结构进行进一步解析；所述子解析器用于对子结构的具体语法单元或者结构体进行解释和映射，将其构建成为运行时可执行对象。

7.如权利要求6所述的方法，其特征在于所述主解析器的遍历方法为：

1)在引擎初始化时，在一个Map数据结构中初始化目标流程语言所包含的标签和主解析器的映射关系表；

2)启动主解析器，遍历流程的XML描述，每当遇到一个标签时，判断是开始标签还是结束标签；

3)如果是开始标签，则获得标签名字并通过解析器管理模块查询映射关系表，如果不存在则打印出错信息；如果存在已注册映射关系，则将当前解析器压入栈，取出新标签对应的子解析器设为当前解析器；

4)主解析器调用子解析器接口创建一个该标签对应的运行时对象，对于标签的所有属性，主解析器调用该子解析器接口将该标签的属性转换为运行时对象的属性；

5)如果是结束标签，则取出其标签名与当前解析器比较；如果不相同，则打印出错信息；如果相同，则判断当前解析器是否创建了新的对象，如果是，则将获取并暂存该新对象，弹出当前解析器，从栈中取出栈顶解析器作为新的当前解析器，并为其添加前一解析器创建的对象。

8.如权利要求4所述的方法，其特征在于所述运行时引擎执行转化后的执行结构的方法为：

1)所述运行时引擎为执行结构中每一个流程实例设一子队列，所有被激活的子队列按照先入先出的顺序连接成一个链接表，即主队列；

2)当主队列非空时，所述运行时引擎从主队列中依次取出子队列并进行调度处理；

3)所述运行时引擎每次取出一个待调度的子队列后，依次从中取出事件并利用事件路由服务进行事件匹配查询该事件触发的活动，然后执行被触发的活动。

9.如权利要求8所述的方法，其特征在于所述运行时引擎采用细粒度的对象池技术执行被触发的活动，其方法为：

1)所述运行时引擎通过对象池获取一个该活动类型的对象实例，如果当前没有可用实例，则创建一个新的该类型对象实例；

2)该活动类型的对象实例被执行完毕之后，所述运行时引擎清除该活动类型的对象实例的状态并将其返回对象池。