ActiveBPEL Engine Architecture
ActiveBPEL™ 引擎执行业务流程执行语言 , 它接受 BPEL 流程的定义 , 创建流程实例 , 并执行它们 . ActiveBPEL™ 引擎在结构上有三个主要的方面 : 引擎 , 流程和活动 . 引擎执行相匹配的一个或多个 BPEL 流程 , 流程由活动组成 , 并按照活动的顺序或包含 LINK 执行 . ActiveBPEL™ 引擎根据 BPEL 流程的定义 (XML 文件 ) 创建流程实例 , 并执行这个流程 .
Table of Contents
ActiveBPEL 引擎结果
** 1. ** ** 引擎 ** **
**
** 2. ** ** 流程 ** **
**
** 3. ** ** 活动 ** **
**
** 4. ** ** 文件 **
The Engine
_ Engine Startup
_
利用一个引擎工厂管理一个 ActiveBPEL 引擎的创建 . 应用处理服务的对象例如队列管理 , 警报和计时服务 , 流程配置使得引擎的各项职责互相分离 . 下面的代码描述了引擎工厂的创建和支撑服务 .
**engine = new Engine(getEngineConfigurationInfo(),
**
** createQueueManager(),
**
** createProcessStateManager());
**
**engine.setPlanManager(createProcessDeploymentProvider());
**
**createProcessDeploymentManager();
**
**createWorkManager();
**
**createAlarmAndTimerService();**
引擎配置的处理是通过一个对象提供的缺省值并读取 aeEngineConfig.xml 文件 . 引擎连接一个队列管理器和一个流程状态管理器 , 对象负责执行履行那些服务给引擎 . 引擎是高度可配置的 , aeEngineConfig.xml 文件不仅描述了像缓存的大小和日志状态 , 也决定了各种管理器和处理器应用的类 .
一个流程配置提供者处理读取流程配置描述 (.pdd)文件, 并且一个流程配置处理器处理流程的创建.一个工作管理器在时间上是异步操作.
_ Process Creation
_
一个新的 BPEL 流程当它的起始活动被触发时创建 , 当接收到一个消息或是一个 PICK 活动的警报时活动被触发 . 当传入的消息包含相关的数据 , 引擎发现已经存在的流程替换匹配的数据 . 当引擎读取一个 BPEL 流程定义 , 它就创建对象并调用流程模型的活动定义 .
活动定义包含了一个 BPEL 活动执行对象的例示所需要的所有信息 . 当执行的对象类似于类的实例化对象 , 活动定义就与类相似 .
引擎和它的事件监听都访问这些定义 . 这些事件包含一个 Xpath 值它表示了流程中的哪个活动正在触发事件 . 这些 Xpath 的值来自活动的定义 .
引擎采用访问者的模式访问活动定义对象模型来创建它的执行对象 , 并且从这个模型来创建执行对象 . ActiveBPEL 引擎密封了任何关于流程构造的逻辑实现 . 举例来说 , 一个固有作用域的调用活动将产生一个带有外部作用域的单独的调用子活动 . 设计者或其他监听都不知道关于这些实现 , 因为他们只关注定义和它们的 XPATH 信息 .
_ Input and Output
_
Activebpel 引擎本身并不处理输入和输出 . 然而 , 协议规范处理器像 AeBpelRPCHandler 和 AeBpelDocumentHandler 把数据从一种特殊的协议转换为一种消息 ,反之亦然.
_ Data Handling
_
所有变量的实现通过 IAeVariable 接口 . 这个接口能够得到变量的定义和它的有效负载 , 如果变量被声明成一种相对的元素或消息 , 将会有所不同 . 消息的负载需要一个和部件对象交互的接口 .
_ Expression Evaluation
_
所有活动和链接允许使用对象各种属性的表达式 . 这些表达式需要一个相容的方法来执行 并描述执行的相互关系 . __ IaeBpelObject对象本身可以包含这些实现并能够提供继承于对象的抽象基本类.BPEL对象是它自己的作用域并且可以被用来正确的找回表达式内容的变量.赋值允许所有的XPATH扩展( for example, bpws:getVariableData ` ).
`
_ Debugging and Logging
_
在流程执行期间 ,ActiveBPEL 引擎激活流程的事件 . 当日志启动 , 一个 AEEngineLogger 实例监听引擎的事件并写出每个流程的日志文件 . 一旦流程完成 , 文件关闭 .
** 日志文件放在 ** {user.home} _ /AeBpelEngine/process-logs , _ {user.home}是java系统属性”user.home”的值.日志被命名为process-id _ .log _ _ , _ process-id 是一个由引擎给出流程的 ID号码,为了启动日志,应用 BpelAdmin配置页,( http://localhost:8080/BpelAdmin/config.jsp ).
Processes
一个流程的组成 :
** Partner links
**
描述两个 web services 之间接口关系 .
** Partners
**
** ** 参与 web service 交易的实体 .
** Variables
**
** ** 值的容器 .
** Correlation sets
**
** ** 确定业务流程唯一的一套数据 . 在流程的不同时期 , 流程可以定义不同的相关集 .
Fault handlers
** ** 描述发生问题时的处理方法 .
** Compensation handlers
**
描述如何退回已经完成的业务流程
** Event handlers
**
** ** 处理引入的消息和警报 .
** A top-level activity
**
一个单独的 BPEL 活动 , 通常是一个其他活动的容器 .
_ Dispatching Requests
_
每个 BPEL 流程必须至少有一个起始活动 . 一个新的 BPEL 流程当它的起始活动被触发时创建 , 也就是一个引入消息或一个 PICK 活动的警报的到来 . 引擎分派引入的消息给正确的流程实例 . 如果有相关的数据 , 引擎就会发现正确的实例并匹配相关的数据 . 如果没有相关的数据 , 请求匹配一个新的活动 , 一个新的流程实例被创建 .
_ Figure 3. Request Dispatch Flowchart
_
Queued Receives
接收队列包含了所有流程实例的当前在执行的 RECEIVE 活动 . RECEIVE 活动包括了消息活动 , 它是 PICK 或一个事件处理的一部分 . 接收队列也包含了来自外部的绑定的消息 , 如果和队列中等待接收的活动不匹配 , 它们本身是不能创建新的流程实例 . 一个不匹配的接收数据像给出的异步的 WEB 服务 . 引擎将接收这些所提供不匹配的消息 , 它们包含了相关的数据 . 这些消息留在队列里 , 直到超时为止 . 这个时间由引擎的配置参数 UnmatchedReceiveTimeout 指定 ` .
`
如果一个流程队列的一个活动比如说一个 RECEIVE活动,它会一直保存在队列里直到数据到达或流程终止.PICK 略有不同:第一个匹配的消息或警报的到来,PICK活动立即设置其它的消息或警报的状态为DEAD_PATH.这将把它们从队列中移走.一旦定义他们的作用域完成,事件处理器会自动把它们从队列中移走.
Activities
BPEL 流程由活动的块组成 . 基本的活动从概念上是一个简单的行为如接收一个消息 , 调用一个 WEB 服务 , 赋值给变量 . 结构化的活动与带有条件或循环构造的程序语言相似 . 特殊的活动介绍了变量 , 作用域和处理正常的活动像流程终止和补偿活动 .
活动加入了 LINKS,有外部的或固有的.活动的路径和LINKS由多种因素决定,包括变量的值和表达式的值.每个活动都存在一个作用域,包括相关的变量,错误处理和补偿处理.作用域在概念上与程序语言的介绍变量的域和处理exception相似.一些活动像Scope和Invoke产生了新的作用域,外部的或是内部的.
_ BPEL Activities
_
Basic activities
** Activity
**
|
** Notes
**
---|---
`
1<receive> `
2
3|
4
5Block and wait for a message from a partner
6
7` <reply> `
8
9|
10
11Reply back to the partner that sent the message we received
12
13` <invoke> `
14
15|
16
17Call some other Web service, either one-way or request-response<</invoke></reply></receive>