This paper presents a peer-to-peer approach to execution of BPEL processes. It does not pre-allocate resources as in existing decentralized approaches. Nor does it involve global coordination for normal executions. The approach is of continuation-passing style, where continuations, or the reminder of executions, are passed along with messages for process execution. Two continuations are associated with an execution: a success continuation and a failure continuation. Recovery plans for processes are automatically generated at runtime and attached to failure continuations.
WS-BEPL [8], or simply BPEL, is becoming a de-facto standard for services composition based on the workflow technology. Using BPEL, a composite service is a BPEL process that uses other services (processes) in some prescribed order. Today, executions of BPEL processes are typically conducted by heavyweight central engines. The cost of deploying a central engine is usually too high for a large number of small businesses or end-users. Moreover, a central engine can become a potential processing and communication bottleneck as well as a central point of failure [1].
Several decentralized or peer-to-peer approaches have been proposed [2][3][4] [5] [6][7] [9]. Common to most of these, a process is instantiated prior to its execution. During instantiation, proper resources and control are pre-allocated in the distributed environment. These approaches inevitably allocate resources even for the parts that are not executed. They also tend to have limited adaptability at runtime due to the complication of re-allocating the pre-allocated resources and control.
Our peer-to-peer approach does not involve process instantiation before execution. The approach is of continuation-passing style, which is a common practice in the functional programming community. Basically, a continuation represents the rest of an execution at a certain point of the execution. It is automatically derived during the execution. By knowing the continuation of the current execution, the control can be passed to the proper subsequent processing entities without the involvement of a central engine. In addition, the approach supports automatic process recovery by associating two continuations with any particular point of execution. The success continuation represents the path of execution towards the successful completion of the process. The failure continuation represents the path of execution towards the proper compensation of committed effects after certain failure events.
In BPEL, processes and (composite) services are synonymous. A (sub-) process is an activity, which has a hierarchical structure. Basic activities include empty activities, activities for providing and invoking services, cast of fault events, etc. A structured activity consists of a collection of activities to be executed in some prescribed order, such as in sequence and in parallel.
Activities run within scopes, which provide boundaries for fault handling and recovery. A process instance runs within a top-level scope. A scope can be associated with a number of activities, including a number of event handlers and fault handlers, an optional compensation handler, and a primary activity that defines its normal behavior. Within a scope, a fault can be thrown with a fault name. The fault will be captured by the scope and handled with a corresponding fault handler. A fault handler typically contains a compensation activity, which executes the compensation operations currently installed within the scope.
Basically, a message tells a site what to do next. If a message also contains a continuation, the site can figure out the execution plan that follows up. In our approach, conducting the execution of a process is the sequences of sending and interpreting messages that contain continuations.
There are some specific issues to be addressed for peer-to-peer process execution using continuations. 1. A partially executed process must be rolled back if some fault event occurs. To enable process rollbacks, two continuations are associated with any particular execution point. The success continuation represents the path of execution towards the successful completion of the process. The failure continuation represents the path of execution towards the proper compensation of committed effects after certain failure events. 2. Some management tasks, such as proper handling of parallel branches and termination of scopes, must be carried out by the proper sites at proper time. The management tasks are defined as auxiliary activities that are automatically added into continuations during execution. 3. Parallel branches must be kept track of in order to: (a) stop all branches of a scope when the scope terminates, and (b) stop and rollback all branches of a scope in case of some fault event. This is done with scope agents. More specifically, a message for process execution contains a control activity and two continuations. The control activity is the activity to be executed immediately. It is either a BPEL activity or an auxiliary activity. One of the two continuations, the success or the failure continuation, is to be executed after the control activity. A continuation is represented as a stack of activities.
The local architecture at a site is shown in Figure 1. Requests for process executions at the site are delivered to its message queue (1). A process interpreter is a pool of threads that interpret the messages. A thread dequeues a message from the message queue (2) and decides the next action according to the control activity of the message. There are two possibilities here: either can the process move on with local processing, or it is dependent on some other messages that are not available yet, such as a provided service waiting for an incoming invoking message. In the former case, the thread invokes (3, 4) some local programs, which might interact with human users. In the latter case, the current message is put in the pending message pool (5). This message will be used later (6) when a dependent message is available (2 again). After the execution of local programs, new messages are either put in the pending message pool (5) or sent to a remote site (7).
to network If a site is also a scope agent, it maintains the scope state in the scope registry (8,9). Basically, the scope state contains the current locations of all active parallel branches. The location of a branch changes when a message is sent. To keep this location state up to date, when a site sends a message (7), it also notifies the management agent of the immediate enclosing scope. To terminate a scope, the scope agent asks all registered sites to stop and clear up the corresponding local activities. To rollback a scope, all these sties run the respective parts of failure continuations.
One important property of our approach is that the next step a site should take is only dependent on local information. No global coordination is needed. Moreover, housekeeping of runtime states is limited within scopes. This inherently addresses the scalability and reliability problems of centralized approaches [1].
Another important property of our approach is that it allows for dynamic invocation of services and just-in-time distribution of resources. That is, the resources can be allocated when the services are to be executed. This is contrary to most other decentralized approaches [3] [9] where resources for the entire process are pre-allocated during process instantiation a prior to their executions. INCA [2] goes a step further than most of the decentralized approaches. A message (called information carrier, INCA) contains a log of the execution so far and rules for further enactment. The rules and the log thus play the roles similar to success and failure continuations of our approach. INCA does not totally eliminate pre-allocation of resources: workflows are enacted using both rules carried in messages and pre-installed local rules. This paper extends our earlier work [10] by dealing with features specific to BPEL processes, including dependencies between parallel branches and scope management.
Our contribution is a new peer-to-peer approach to execution of BPEL processes. The continuation-passing style of the approach makes the conduction of process execution as local operations rather than global coordination. As a distinct feature, it does not unnecessarily pre-allocate resources prior to process executions. Furthermore, it supports process recovery by automatically generating recovery plans into failure continuations. The approach is supported by a working prototype.