ActiveBPEL引擎架构
2007-06-25 15:09
274 查看
ActiveBPEL Engine Architecture
The ActiveBPEL™ engine executes Business Process Execution Language (BPEL) processes. It accepts BPEL process definitions, creates process instances, and executes them. For more information about BPEL, see Introduction to the ActiveBPEL Engine.
There are three main areas in the architecture of the ActiveBPEL engine: the engine, processes, and activities. The ActiveBPEL engine coordinates the execution of one or more BPEL processes. Processes are in turn made up of activities, which may in turn contain or link to further activities. The ActiveBPEL engine creates a process from a BPEL process definition (an XML file) and then executes this process. (Processes may also be abstract, which means they are non-executable, but the ActiveBPEL engine runs executable processes.) This architecture document describes these three main areas-the engine, processes, and activities.
Table of Contents
ActiveBPEL Engine Architecture
The Engine
Processes
Activities
Files
The Engine
The ActiveBPEL engine executes BPEL processes.
The "database" elements on the right of this illustration represent generic persistent storage. The ActiveBPEL engine uses a pluggable architecture; different persistence managers may implement different storage mechanisms. The ActiveBPEL engine ships with a persistence manager that keeps everything in memory.
Engine Startup
An engine factory manages the creation of an ActiveBPEL engine. Separation of responsibilities is achieved through the use of objects that handle services such as queue management, alarm and timer services, and process deployment. The following pseudocode describes the factory's creation of the engine and supporting services.
Engine configuration is handled by an object that supplies default values and reads the aeEngineConfig.xml file. The engine is connected to a queue manager and a process state manager, objects that are responsible for performing those services for the engine. The engine is highly configurable. aeEngineConfig.xml specifies not only values like cache sizes and logging state, but also determines the class of various factories, managers, and handlers.
A process deployment provider handles reading Process Deployment Descriptor (.pdd) files, and a process deployment manager handles process creation (see Process Creation below).
A work manager schedules asynchronous operations.
Process Creation
A new BPEL process gets created when one of its start activities is triggered, either by an incoming message or by a Pick activity's alarm. When an incoming message contains correlation data, the engine finds the existing process matching the data instead. See Dispatching Requests for details.
When the engine reads a BPEL process definition it creates objects called activity definitions that model the process.
Activity definitions contain all of the information required to instantiate a BPEL activity implementation object. In this regard, definitions are analogous to classes while the implementation objects are analogous to instances of those classes-objects.
Both the engine and its event listeners have access to these definitions. The events contain an XPath value that indicates which activity in the process is triggering the event. These XPath values come from the activity definitions.
The engine creates its implementation objects by using a Visitor pattern to visit the activity definition object model and creating implementation objects from this model. The ActiveBPEL engine encapsulates any implementation logic within this construction process. For example, an implicit scope within an invoke activity will generate an explicit scope with a single invoke child activity. The designer or other listeners don't have to know about these implementation decisions since they're only aware of the definitions and their XPath information.
Input and Output
The ActiveBPEL engine itself does not handle input and output. Instead, protocol-specific handlers such as AeBpelRPCHandler and AeBpelDocumentHandler translate data from a particular protocol to a message and vice versa.
Data Handling
All variables implement the IAeVariable interface. This interface has the ability to get the definition and the payload, which will be different if the variable is declared as a type versus an element or message. The message payload requires an interface for detailed interactions with the part objects.
Expression Evaluation
All activities and links allow expressions for various attributes of the object. These expressions require a consistent method for execution and describing the execution context. The IAeBpelObject itself can wrapper execution and can be supplied in the abstract base class from which the objects inherit. The BPEL object is itself a scope (in the variable sense of the word) and can be used to correctly retrieve the accessible variables of the expression context. Evaluation allows all the XPath extensions which have been documented in the BPEL spec (for example, bpws:getVariableData).
Debugging and Logging
During process execution, the ActiveBPEL engine fires events indicating its progress. When logging is turned on, an instance of AEEngineLogger listens for engine events and writes them out to individual process log files. Once the process completes, the file will be closed.
The log files are created in the directory {user.home}/AeBpelEngine/process-logs, where {user.home} is the value of the Java System property "user.home". The log files are named process-id.log, where process-id is a process id number assigned by the engine. To turn on logging, use the BpelAdmin configuration page (which is normally found at http://localhost:8080/BpelAdmin/config.jsp).
Processes
A process consists of the following components:
Partner links
Describe a relationship between two Web services at the interface level
Partners
Entities taking part in a Web service transaction
Variables
Containers for values
Correlation sets
Sets of data that uniquely identify the business process. At different times in the process, different correlation sets may identify the process.
Fault handlers
Describe what to do when problems occur
Compensation handlers
Describe how to reverse already-completed business processes
Event handlers
Handle incoming messages and alarms
A top-level activity
A single BPEL activity, usually a container for other activities
Dispatching Requests
Each BPEL process must have at least one start activity. A new BPEL process gets created when one of its start activities is triggered, either by an incoming message or by a Pick activity's alarm.
The engine dispatches incoming messages to the correct process instance. If there is correlation data, the engine tries to find the correct instance that matches the correlation data. If there is no correlation data and the request matches a start activity, a new process instance is created.
Queued Receives
The receive queue contains the currently executing receive activities across all process instances. Receive activities include onMessage activities that are part of a pick or an event handler. A receive activity is said to be executing when it has been queued by its parent (for example, a scope, flow, or sequence) but has not yet received the message that it's waiting for from the outside world.
The receive queue also contains inbound messages from the outside world that did not match up to a waiting receive activity already in the queue and were themselves not capable of creating a new process instances. An unmatched receipt of data like this is possible given the asynchronous nature of some Web services. The engine will accept these unmatched messages provided that they contain correlation data. These messages are queued until a timeout period passes. The period is specified by the engine configuration parameter UnmatchedReceiveTimeout.
If a process queues an activity like a receive, then this activity will stay in there until the data arrives or the process terminates (through a fault or terminate activity). Picks are slightly different: the first onMessage or onAlarm to match for the pick immediately sets the state of all of the other possible messages/alarms for that pick to DEAD_PATH. This will remove them from the queue. Event handlers automatically remove their queue entries once the scope that defines them completes.
Activities
Activities are the building blocks of BPEL processes. Basic activities are conceptually simple behaviors like receiving a message, invoking a Web service, and assigning values to variables. Structured activities are similar to conditional and looping constructs in programming languages. Special activities introduce variable scoping and handle abnormal activities such as process termination and compensation (explicitly "undoing" a process).
Activities are joined by links, either explicit or implicit. The path taken through the activities and links is determined by many factors, including the values of variables and the evaluation of expressions.
Every activity exists within a scope which is a context for variables, fault handlers, and compensation handlers. Scopes are conceptually similar to programming language blocks that introduce new variable scope and (depending upon the language and construct used) exception handling mechanisms. Some activities such as Scope and Invoke generate new scopes, whether implicitly or explicitly.
BPEL Activities
Basic activities
Structured activities
Special activities
States
Each activity has an associated state. The activities enter or exit these states based on the rules of BPEL. The activities also fire events to notify listeners of their changes in state. There are mechanisms in place for listening to these events.
State constants are defined in AeBpelState. An activity must be in one of the following states:
Activities
All activities have a common set of methods that facilitate the movement between states and the above referenced event firing. This overview of these methods is followed by a detailed description of each activity's implementation.
Activity class hierarchy
Some activities such as the structured activities and Scope contain other activities.
Common methods
These are some of the methods common to all activities.
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.
The ActiveBPEL™ engine executes Business Process Execution Language (BPEL) processes. It accepts BPEL process definitions, creates process instances, and executes them. For more information about BPEL, see Introduction to the ActiveBPEL Engine.
There are three main areas in the architecture of the ActiveBPEL engine: the engine, processes, and activities. The ActiveBPEL engine coordinates the execution of one or more BPEL processes. Processes are in turn made up of activities, which may in turn contain or link to further activities. The ActiveBPEL engine creates a process from a BPEL process definition (an XML file) and then executes this process. (Processes may also be abstract, which means they are non-executable, but the ActiveBPEL engine runs executable processes.) This architecture document describes these three main areas-the engine, processes, and activities.
Table of Contents
ActiveBPEL Engine Architecture
The Engine
Processes
Activities
Files
The Engine
The ActiveBPEL engine executes BPEL processes.
![]() |
Figure 1. Engine Architecture |
Engine Startup
An engine factory manages the creation of an ActiveBPEL engine. Separation of responsibilities is achieved through the use of objects that handle services such as queue management, alarm and timer services, and process deployment. The following pseudocode describes the factory's creation of the engine and supporting services.
engine = new Engine(getEngineConfigurationInfo(), createQueueManager(), createProcessStateManager()); engine.setPlanManager(createProcessDeploymentProvider()); createProcessDeploymentManager(); createWorkManager(); createAlarmAndTimerService(); |
A process deployment provider handles reading Process Deployment Descriptor (.pdd) files, and a process deployment manager handles process creation (see Process Creation below).
A work manager schedules asynchronous operations.
Process Creation
A new BPEL process gets created when one of its start activities is triggered, either by an incoming message or by a Pick activity's alarm. When an incoming message contains correlation data, the engine finds the existing process matching the data instead. See Dispatching Requests for details.
When the engine reads a BPEL process definition it creates objects called activity definitions that model the process.
![]() |
Figure 2. Runtime Engine Object Creation |
Both the engine and its event listeners have access to these definitions. The events contain an XPath value that indicates which activity in the process is triggering the event. These XPath values come from the activity definitions.
The engine creates its implementation objects by using a Visitor pattern to visit the activity definition object model and creating implementation objects from this model. The ActiveBPEL engine encapsulates any implementation logic within this construction process. For example, an implicit scope within an invoke activity will generate an explicit scope with a single invoke child activity. The designer or other listeners don't have to know about these implementation decisions since they're only aware of the definitions and their XPath information.
Input and Output
The ActiveBPEL engine itself does not handle input and output. Instead, protocol-specific handlers such as AeBpelRPCHandler and AeBpelDocumentHandler translate data from a particular protocol to a message and vice versa.
Data Handling
All variables implement the IAeVariable interface. This interface has the ability to get the definition and the payload, which will be different if the variable is declared as a type versus an element or message. The message payload requires an interface for detailed interactions with the part objects.
Expression Evaluation
All activities and links allow expressions for various attributes of the object. These expressions require a consistent method for execution and describing the execution context. The IAeBpelObject itself can wrapper execution and can be supplied in the abstract base class from which the objects inherit. The BPEL object is itself a scope (in the variable sense of the word) and can be used to correctly retrieve the accessible variables of the expression context. Evaluation allows all the XPath extensions which have been documented in the BPEL spec (for example, bpws:getVariableData).
Debugging and Logging
During process execution, the ActiveBPEL engine fires events indicating its progress. When logging is turned on, an instance of AEEngineLogger listens for engine events and writes them out to individual process log files. Once the process completes, the file will be closed.
The log files are created in the directory {user.home}/AeBpelEngine/process-logs, where {user.home} is the value of the Java System property "user.home". The log files are named process-id.log, where process-id is a process id number assigned by the engine. To turn on logging, use the BpelAdmin configuration page (which is normally found at http://localhost:8080/BpelAdmin/config.jsp).
Processes
A process consists of the following components:
Partner links
Describe a relationship between two Web services at the interface level
Partners
Entities taking part in a Web service transaction
Variables
Containers for values
Correlation sets
Sets of data that uniquely identify the business process. At different times in the process, different correlation sets may identify the process.
Fault handlers
Describe what to do when problems occur
Compensation handlers
Describe how to reverse already-completed business processes
Event handlers
Handle incoming messages and alarms
A top-level activity
A single BPEL activity, usually a container for other activities
Dispatching Requests
Each BPEL process must have at least one start activity. A new BPEL process gets created when one of its start activities is triggered, either by an incoming message or by a Pick activity's alarm.
The engine dispatches incoming messages to the correct process instance. If there is correlation data, the engine tries to find the correct instance that matches the correlation data. If there is no correlation data and the request matches a start activity, a new process instance is created.
![]() |
Figure 3. Request Dispatch Flowchart |
The receive queue contains the currently executing receive activities across all process instances. Receive activities include onMessage activities that are part of a pick or an event handler. A receive activity is said to be executing when it has been queued by its parent (for example, a scope, flow, or sequence) but has not yet received the message that it's waiting for from the outside world.
The receive queue also contains inbound messages from the outside world that did not match up to a waiting receive activity already in the queue and were themselves not capable of creating a new process instances. An unmatched receipt of data like this is possible given the asynchronous nature of some Web services. The engine will accept these unmatched messages provided that they contain correlation data. These messages are queued until a timeout period passes. The period is specified by the engine configuration parameter UnmatchedReceiveTimeout.
If a process queues an activity like a receive, then this activity will stay in there until the data arrives or the process terminates (through a fault or terminate activity). Picks are slightly different: the first onMessage or onAlarm to match for the pick immediately sets the state of all of the other possible messages/alarms for that pick to DEAD_PATH. This will remove them from the queue. Event handlers automatically remove their queue entries once the scope that defines them completes.
Activities
Activities are the building blocks of BPEL processes. Basic activities are conceptually simple behaviors like receiving a message, invoking a Web service, and assigning values to variables. Structured activities are similar to conditional and looping constructs in programming languages. Special activities introduce variable scoping and handle abnormal activities such as process termination and compensation (explicitly "undoing" a process).
Activities are joined by links, either explicit or implicit. The path taken through the activities and links is determined by many factors, including the values of variables and the evaluation of expressions.
Every activity exists within a scope which is a context for variables, fault handlers, and compensation handlers. Scopes are conceptually similar to programming language blocks that introduce new variable scope and (depending upon the language and construct used) exception handling mechanisms. Some activities such as Scope and Invoke generate new scopes, whether implicitly or explicitly.
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 |
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 |
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 |
Each activity has an associated state. The activities enter or exit these states based on the rules of BPEL. The activities also fire events to notify listeners of their changes in state. There are mechanisms in place for listening to these events.
State constants are defined in AeBpelState. An activity must be in one of the following states:
State | Notes |
INACTIVE | All BPEL activities are in the inactive state when the Process starts |
READY_TO_EXECUTE | 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 | Removed from the execution path due to dead path elimination. When a parent activity's state becomes that state is propagated to all of its children. |
QUEUED_BY_PARENT | Queued for execution by their parents |
TERMINATED | Terminated |
Unknown | The activity's state is null. If a parent activity's state becomes unknown, then the childrens' states change to INACTIVE. |
All activities have a common set of methods that facilitate the movement between states and the above referenced event firing. This overview of these methods is followed by a detailed description of each activity's implementation.
Activity class hierarchy
![]() |
Figure 4. Activity Class Hierarchy |
Common methods
These are some of the methods common to all activities.
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.
相关文章推荐
- ActiveBPEL引擎文件格式
- 使用Eclipse编译ActiveBPEL引擎4.0源程序
- ActiveBPEL引擎(4.0)启动步骤分析(ActiveBPEL Engine Startup Steps)
- ActiveBPEL 引擎结构
- 安装和配置ActiveBPEL引擎3.1
- ActiveBPEL引擎文件格式描述
- 安装部署ActiveBPEL引擎到JBoss应用服务器(Install ActiveBPEL Engine on JBoss)
- ActiveBPEL引擎流程部署描述符(pdd)文件概述
- 安装ActiveBPEL引擎(tomcat5.5+mysql5.1+ActiveBPEL5.0.2)
- ActiveBPEL 引擎结构
- 安装ActiveBPEL引擎(tomcat5.5+mysql5.1+ActiveBPEL5.0.2)
- 部署流程到ActiveBPEL的准备工作
- Unity3d 引擎原理详细介绍、Unity3D引擎架构设计- zhibolife(转载分享)
- WebRTC音视频引擎研究(1)--整体架构分析
- atitit 研发管理 要不要自己做引擎自己实现架构?.docx
- Cocos2d-x 3.0final 终结者系列教程04-引擎架构分析
- 【Ogre引擎架构】 第四讲 模型文件渲染数据的存储机制
- Apache Lucene全文检索引擎架构之搜索功能
- 网易考拉规则引擎平台架构设计与实践
- 全文检索、数据挖掘、推荐引擎技术架构