Apache ODE架构介绍

Apache ODE引擎架构设计

1.  编写目的

该文档描述Apache ODE（Orchestra Director Engine）引擎的系统架构，对于后期的系统扩展做好准备。

下面的部分将从较高层次介绍ODE的系统整体架构，首先将先对ODE的设计目标进行一个简单描述，然后再介绍各种ODE组件以及它们之间是如何交互的，最后是对本项目BPEL引擎模块的一个初步设想。

2.  ODE的设计目标

ODE的开发目标是建立一个可靠的、轻型的、可嵌入的能够管理长时间运行流程的组件，该流程由BPEL流程描述语言定义。开发核心是创建一些小模块，这些小模块具有很小的互相的依赖性，通过很容易的组装这些组件可以构成一个完整的BPM系统。

3.  模块

ODE系统架构的关键模块包括ODE BPEL编译器、ODE BPEL运行时、ODE数据访问对象（DAOs）、ODE集成层（ILs）和用户工具。下面的这张图从较高层次上表示了这些不同组件之间的关系。

 

图 1 ODE模块关系图

这个整体关系可以这样认为：“编译器将BPEL文档转化成为可以被BPEL运行时库执行的格式，执行时通过一种可靠的方式进行，它依赖于一个持久化方式（通过DAOs）；运行时库在集成层的上下文环境总执行，该集成层将引擎与外界更宽广的执行环境相连接”。

3.1 ODE BPEL编译器 

ODE BPEL编译器负责将BPEL源文件（BPEL流程描述文件、WSDL文件以及Schemas）转化成一个编译好的、适合于引擎执行的流程表示形式。编译器的输出不是一个“好的”编译好的表示形式，就是一系列的错误信息，表明该源文件的问题。

编译好的BPEL流程表示是一个对象模型，该模型在结构上和底层的BPEL流程文档是一样的。然而，编译好的流程表示已经解析了大量BPEL文档中的命名引用（例如变量名），将所需要的WSDL文件以及类型信息，还有产生的大量的结构（像default compensation handlers）内化（internalized）。该编译好的文件（一个扩展名为.cbp的文件）是唯一一个BPEL运行时所需的文件。

3.2 ODE BPEL引擎运行时

ODE BPEL运行时就是bpel-runtime模块，提供对于执行编译好的BPEL流程所需的功能。运行时模块通过提供对于各种不同BPEL结构的实现，来执行流程运行的工作。运行时模块同时还实现了一些必须的逻辑上的功能，像决定何时一个新的实例需要被创建，以及一个新到来的message应该被发送到那个实例中等。最终，运行时模块还实现了流程管理API，这些API使用外层用户用来和流程进行交互的。

为了达到在不可靠环境下，可靠地执行流程的目的，运行时模块依赖于DAOs模块来提供相关的持久化功能。对于这些DAOs的实现是可以被定制的，但是一般情况下都是由一个事务关系型数据库来充当的。关于DAOs的更多细节将在下一小节中详细叙述。

运行时模块对于BPEL结构的实现是通过ODE的Java Concurrent Objects（Jacob）框架来实现的。Jacob提供了一个应用级的并发机制（它并不是依赖于线程）同时包括一个透明的处理流程中断和持久化流程状态的机制。Jacob是Java对于ACTORS[Agha]并行模型实现的一个很大的组成部分，同时还有很多的流程代数学特征，像pi的演算。本质上，Jacob提供了一个持久虚拟机来执行BPEL结构。

3.3 ODE 数据访问对象（DAOs）

ODE 的数据访问对象（DAOs）处于BPEL运行时模块与底层数据源交互过程的中间位置。一般情况下，该数据源是一个JDBC的关系型数据库：目前，这个DAOs是通过OpenJPA数据访问库（Data access library）来实现的。你也可以创建一个特定的DAO实现，它使用另外一种不是JDBC的方式的机制来达成数据持久化目的，但是在这里并不提供这样的实现。BPEL引擎的运行时要求DAO对象能够处理以下的这些持久化事件：

1)        活动的实例——跟踪哪些实例已经被创建

2)        消息路由——哪个实例在等待哪个消息

3)        变量——对于每一个实例的BPEL流程变量的值

4)        伙伴链接——对于每个实例的BPEL伙伴链接的值

5)        流程执行状态——Jacob的持久化虚拟机的连续状态

关于OpenJPA/JDBC 的DAO实现，它们用来实现上面这些功能的关系结构在图1中已经表明。

3.4 ODE集成层

ODE BPEL引擎运行时不能在一个真空中存在：它自己是无法影响任何与外部世界的交互的。关于这一点，它是依赖于ODE的集成层（ILs）。在执行环境中集成层是嵌入在运行时中的。例如，目前ODE提供对于AXIS2和JBI的集成层。集成层的最基础的功能是提供跟运行时的一个通信通道（communication channels）。AXIS2的集成层通过使用AXIS2的库来达到这一目的，这样可以使得运行时通过Web Service调用进行通信。JBI的集成层通过将运行时绑定到JBI的消息总线上来达到这一目的。

此外对于通信，一个集成层通过一个线程调度机制提供运行时，同时管理运行时的生存周期（例如，配置和启动运行时）。

4. CSSP引擎设计初步设想

如果采用Apache ODE引擎作为本项目的引擎原型系统进行开发，主要的工作将包括以下几个部分：

1)        对于BPEL4People实现的集成

根据目前了解情况Intalio公司的Tempo工作流框架实现了B4P（同时还包括BPEL、Xforms、WebService等）规范，而且已经加入到了他们公司的BPMS产品中，该产品的BPEL4WS的实现就是ODE，所以证明了ODE+Tempo集成的可行性。但该产品并没有完全开源。但是Tempo部分完全开源，可以获得其源代码。但是针对BPEL4People的设计器目前还没有看到，所以该部分的设计器的实现将是很大的工作。

从ActiveBPEL的源代码组织结构上来看，B4W的实现和B4P的实现时完全分开的，也就是说一个流程要么是B4W的，要么是B4P的，不同的流程会分发到不同的实现中去执行。我们也可以学习这种方式，设计好的流程根据其设计种类，其执行实现也不同，即就是B4W的通过ODE来实现，B4P的通过Tempo来实现。这样或许可以解决BPEL4People的集成问题。

2)        对于Eclipse-BPEL设计器的改造

首先是对于用户可用性的改造，包括汉化、活动名称的改变、一些BPEL术语的解释等，这些还都是表面活动。然后，就是与流程部署的集成，可以在设计完成之后，直接就可以部署该流程；与引擎生存周期管理的集成，像是引擎的启动、停止、重启等操作。最后，还需要加入对于执行的流程实例的监控，包括可以重启某个实例、停止实例执行、检查实例的中间执行状态等。

对于流程设计人员，该设计器将是其最主要的工作平台，但是不光是一个设计平台，它最终是一个All-In-One的一个软件，包括了以上所提到的各个部分。

3)        对于服务动态绑定模块的扩展

该部分的主要工作将在引擎中进行。目前，我的解决方案是：在流程部署描述符中添加特定标签，来指示该流程是否需要动态绑定；动态绑定的流程部署的时候，可以不用WSDL文件，只需要在部署描述文件中描述该WSDL的url便可以，流程在执行过程中再获取该WSDL然后发送SOAP消息。

4)        对于分布式流程执行的探索研究

该部分目前还只是术语探索阶段，暂时没有解决方案。

ODE的优势：

1)        开源，文档相对较为齐全

2)        与Eclipse-BPEL设计器、Tempo（B4P的一个实现）结合相对比较紧密，集成难度相对较小

从Eclipse-BPEL的SVN上来看，它的下一版本将会与ODE集成，设计完的流程可以直接部署到ODE引擎中，还有就是IBM的Developerworks网站上对于BPEL流程设计的教程也是通过ODE+EclipseBPEl的方式来进行描述的。

还有就是ODE，以及Tempo最初都是源于同一个公司Intalio，而且该公司也已经发布了一个ODE+Tempo+BPMN-modeler的产品。

3)        与JBI的集成较为简单，因为ODE的实现就考虑到了JBI集成问题。