ActiveBPEL引擎架构

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.

Figure 1. Engine Architecture

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 = new Engine(getEngineConfigurationInfo(), createQueueManager(), createProcessStateManager()); engine.setPlanManager(createProcessDeploymentProvider()); createProcessDeploymentManager(); createWorkManager(); createAlarmAndTimerService();

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.

Figure 2. Runtime Engine Object Creation

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.

Figure 3. Request Dispatch Flowchart

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

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

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.

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

Figure 4. 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.