ActiveBPEL 引擎结构
ActiveBPEL 引擎结构 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
<receive>
Block and wait for a message from a partner
<reply>
Reply back to the partner that sent the message we received
<invoke>
Call some other Web service, either one-way or request-response
<assign>
Assign or copy values to variables
<throw>
Generate a fault
<wait>
Wait for a given time period (time-out) or until a particular time has passed (alarm)
<empty>
A no-op
Structured activities
Activity
Notes
<sequence>
Execute children in order
<switch>
Just like a 'switch' or 'case' statement
<while>
Repeat an activity while a condition is true
<pick>
Block and wait for a message, time-out, or alarm
<flow>
Children are executed concurrently; links can provide additional control structure
Special activities
Activity
Notes
<scope>
Define a new scope for variables, fault handlers, and compensation handlers
<compensate>
Invoke compensation on an inner scope that has already completed normally
<terminate>
Immediately terminate a business process instance
States
每个活动都有一个相关的状态,这些活动进入或是退出这些状态都基于BPEL标准.活动也会触发事件,使得监听能够发现其状态的改变.有一些机制来监听这些事件.
表示状态的常量定义在AeBpelState中,一个活动必须是下列的状态之一:
State
Notes
INACTIVE
当流程开始的时候,所有BPEL的活动都是没有非活动的状态
All BPEL activities are in the inactive state when the Process starts
READY_TO_EXECUTE
准备执行.这些活动在它们的父队列里,它们的连接条件的值为true.
Ready to execute. These activities have been queued by their parent and their join condition has evaluated to true
EXECUTING
正在执行.
Currently executing
FINISHED
执行完成,没有出错.
Finished executing without a fault
FAULTED
执行完成,出错.
Finished executing with a fault
DEAD_PATH
由于绝对路径的消除从执行路径中移出,当一个父活动的状态变为:DEAD_PATH,这个状态会传给它所以的子活动.
Removed from the execution path due to dead path elimination. When a parent activity's state becomes DEAD_PATH, that state is propagated to all of its children
QUEUED_BY_PARENT
父活动的执行队列.
Queued for execution by their parents
TERMINATED
终止.
Terminated
Unknown
活动的状态为空.如果一个父活动的状态变为unkown,它的子状态变为INACTIVE.
The activity's state is null. If a parent activity's state becomes unknown, then the childrens' states change to INACTIVE.
Activities
所有的活动都有一套共同的方法使得它们在以上各种状态和提及的事件触发间的运转变的更容易.下列这些方法描述了每个活动的实现细节.
Activity class hierarchy
Figure 4. Activity Class Hierarchy(活动类的继承))
一些活动例如:结构化活动和作用域都包含了其他活动.
Common methods
所有活动的共同的方法:
isReadyToExecute()Returns true if the Activity is OK to prepare for execution. This is determined by checking the activity's incoming links if any. Some activities use this method to perform some initialization.
execute()
This is where the activity's primary action takes place. The activity may set up any supporting elements required for the activity's execution. An example of this is a Scope activity creating variables. Then this method performs the primary action. For example, if it's an Invoke, this is where the invocation is made to the Web service.
objectCompleted()
Called by the activity when it is done with its execution. This method processes any outgoing links (aka source links) and then signals the process that the activity is complete.
terminate()
Called by a parent process when there is a fault and the activity is required to terminate.
Link handling and dead path elimination
The BPEL 1.1 spec covers link handling in Section 12.5. Below are some noteworthy points from the spec:
· Links cannot cross the boundary of a <while>, serializable <scope>, <eventHandlers>, or a <compensationHandler>
· Links can only be OUTBOUND from within a Fault Handler
· Activities that have suppressJoinFailure set to true have an IMPLICIT Scope around them with the only behavior being a fault handler for bpws:joinFailure. In the event that the activity is an Invoke with an implicit Scope then the two Scopes are MERGED to form a single Scope with the same name as the activity.
Files
See ActiveBPEL File Formats for descriptions of the formats and contents of these files.
Engine
aeEngineConfig.xml
When the ActiveBPEL engine is created, this file is loaded. It is used to set options such as the unmatched correlated receive timeout, whether XPath creation is allowed, external XPath function contexts, logging, and more.
BPEL Processes
*.bpr
A BPEL process archive. It contains the BPEL, Process Deployment Description (.pdd), WSDL, and partner files necessary to deploy a BPEL process. See Deploying BPEL Processes.
*.pdd
A Process Deployment Descriptor tells the ActiveBPEL engine about a BPEL process. It describes the partner links and WSDL files needed.
wsdlCatalog.xml
The WSDL catalog provides a way for the ActiveBPEL engine to find WSDL files within a .bpr deployment archive. wsdlCatalog.xml lives in the META-INF directory
