-- GuoliLi - 03 Feb 2007 Draft, Draft, Draft

The Business Process Execution Language (BPEL) standardizes the development of composite enterprise applications that make use of software components exposed as Web services. BPEL processes are currently executed by a centralized orchestration engine, in which issues such as scalability and platform heterogeneity can be difficult to manage. We design a distributed business process execution architecture based on the flexible PADRES publish/subscribe layer. The idea is to mapping standard BPEL processes, inculding the complete set of BPEL activities, to a set of distributed activity agents, which are publish/subscribe clients to PADREs, with control flow realized using decoupled publish/subscribe semantics. The porcess exeuciton is event-driven and naturally distributed. We also evaluate our distributed BPEL engine with a centralized one, and demonstrate that the performance and scalability is improved over the centralizaed engine.

System Architecutre

The system architecture includes four components: the underlying PADRES broker network, activity agents, Web service agents and a business process manager, as shown in the following figure.

• ws-architecture.jpg:
  

Activity agent: in our architecture, each business process element, e.g., a BPEL activity, has a corresponding activity agent, which is a lightweight publish/subscribe client. Generally, an agent waits for its predecessor activities to complete by subscribing to such an event, then executes its activity, and finally triggers the successor activities by publishing a completion event.

Web service agent: Cross-enterprise business interaction is a requirement in business processes. For example, BPEL supports invoking partner Web services. The Web service agent allows a business process to invoke and be invokded by external Web services by translating between Web service protocols and publish/subscribe message formats.

Business process manager: is a publish/subscribe client to PADRES. It transforms business processes into publish/subscrbie messages for the activity agents, deploys the process onto the available agents in the broker network, triggers instances of business processes, and monitors and controls the execution.

Business Process Management

Our approach addresses four phases of business process exeuction and management: process transformation phase, deployment phase, execution phase, and monitoring/control phase.

Transformation Phase: A business process is mapped to a set of activity agents and corresponding publish/subscribe messages that specify the dependencies among the activities. The transformation of some BPEL activities is illustrated in the following figures.

• whileactivity.eps: whileactivity.eps

• pickactivity.eps: pickactivity.eps

• compensateactivity.eps: compensateactivity.eps

Deployment Phase: the business process manager deploys the process to the appraopriate activity agents. Each activity agent subscribes to agent control messages, which allows the manager to install an activity at a particular agent. In deployment phase, the inter-agent activity dependencies have been built up.

Execution Phase: The deployed processes can be invoked through a Web service agent, which translates the invocation into a trigger publication message in PADRES.The first activity agent receives the trigger, instantiates a process instance, processes the activity, and triggers its successor activities. Agents execute and trigger one another using publish/subscribe messages in an event-driven manner until the process terminates.

Monitoring/Control Phase: our approach supports both real-time and historic process monitoring. The real-time monitoring includes: observing the status of individual activities, tracing the execution of a particular process instance, or performing countless other queries. The historic process monitoring includes any queries to the instances of completed processes. PADRES also supports the hybird monitoring with the feature of composite subscriptions. We can also visualize the network topology and message routing.

The advanced process control functions include suspending, resuming or stopping running process instances. We can also update a business process on-line by keeping different version information.

Evaluation Results

The experiments are based on a 12 broker network with 10 agents. We compared the centralized process execution with the distributed approach by measuring the average process execution time and system throughput.

Varying Request Rate: The default values for Service Delay is 100 ms, and Msg Size is 512 bytes. The execution time is measured from when the client sends the request to when it receives the response. Each data point is the average execution time after all the instances are finished. Since the distributed execution takes advantages of more computing resources and the parallel branches in a process, the execution time is improved, compare to the centralized execution. The results suggest that the overhead of message traversing among the 12 broker network is negligible.

Throughput is the number of process instances the system processes per minute. The centralized execution reaches the maximum system throughput at about 250 /min, while the distributed execution reaches its maximum at 1000/min. The improvement is up to 130%.

• Average Execution Time with Different Msg Rate:
  

• Average Throught with Different Msg Rates:
  

Varying Web Service Delay: The default values for Request rate is 500 /min, and Message size is 512 bytes. We vary the service time from 20ms to 2 sec. A longer service delay increase the execution time, because more concurrent process instances are queuing in the system. But the distributed execution is less affected.

• Average Execution Time with Different Web Service Time:
  

Varying Message Size: The default values for Request rate is 500/min, and Service delay is 100ms. We vary the msg payload(payload is not for matching) from 512 bytes to 256 Kb. The results suggest that the communication and processing large messages in the broker network does not affects the throughput significantly.

• Average Throught with Different Msg Size:
  

Parallelism: We run a process with 10 parallel branches. The default values for Service delay is 100ms, and Msg size is 512 bytes. The centralized execution can not handle the request rate larger than 50 /min. while the distributed execution works fine with request rate up to 1000/min. The centralized execution does not scale with the size of business processes.

• Average Execution Time with Different Msg Rate for Parallel Processes:
  

• Average Throught with Different Msg Rates for Parallel Processes: