Ana səhifə

Adaptive and Distributed Service Oriented Processes: An Architectural Methodology Michael Pantazoglou, George Athanasopoulos, Aphrodite Tsalgatidou

Yüklə 253 Kb.
ölçüsü253 Kb.
  1   2   3

Adaptive and Distributed Service Oriented Processes: An Architectural Methodology

Michael Pantazoglou, George Athanasopoulos, Aphrodite Tsalgatidou

National and Kapodistrian University of Athens, Greece


The goal of this chapter is to present a solution towards the performance improvement of service-oriented process execution engines. More specifically, the chapter contributes a distributed infrastructure that enables the scalable execution of service-oriented processes, while also supporting their data-driven adaptation. The presented approach is particularly applicable to processes implemented with the use of the BPEL standard, which are long-running, consume large volumes of data, and are concurrently accessed by large numbers of clients. The proposed solution is part of the runtime infrastructure that was developed in the context of the ENVISION project, and has been applied to a number of use cases in the environmental domain in order to support the efficient execution and monitoring of service-oriented environmental models.


The Web Services Business Process Execution Language [ref], abbreviated to WS-BPEL or BPEL, is widely considered the de facto standard for the implementation of executable service-oriented business processes as compositions of Web services. Still, in many cases, which have become evident in various application domains, centralized BPEL engines are clearly not adequate to guarantee smooth process execution, and thereby ensure client satisfaction, in the presence of multiple, concurrent, long-running process instances, which in addition are involved in the exchange of voluminous data. Indeed, as the number of clients grows, the underlying infrastructure needs to maintain and handle multiple processes instances while waiting for the external Web services that are invoked to complete their execution. Although clustering techniques can be employed to address the scalability issue, the deployment and maintenance of clusters consisting of two or more centralized BPEL engines sets requirements on the underlying hardware resources that cannot be always fulfilled by the involved organizations. Furthermore, clustering could be proved an inefficient approach under certain conditions, as it cannot overcome the emergence of bottlenecks that are caused by specific activities of a BPEL process. In such context, inevitably, the BPEL engine becomes bloated with pending requests coming from multiple concurrent clients. Hence, the overall throughput of the execution infrastructure is dramatically deteriorated, while the process execution times escalate at unacceptable levels.

Aside from the aforementioned scalability issues that derive from the centralized architecture of most BPEL engine solutions, the execution of BPEL processes is also performed in a closed runtime environment. More specifically, process instances are isolated from each other, as well as from any other potential source of information. This prevents processes from finding and exploiting relative data at runtime, in order to improve their predefined behavior in a dynamic manner. Instead, it becomes the responsibility of the process designer to manually adapt the process specification so as to accommodate emerging data sources.

In order to address all these challenges, we propose a decentralized BPEL engine architecture with data-driven adaptation capabilities. Our engine employs the hypercube peer-to-peer (p2p) topology along with a set of distributed algorithms in order to improve the average process execution times, and the enhancement of the overall throughput of the execution infrastructure in the presence of multiple, concurrent and long-running process instances.

In addition to the decentralized architecture, the proposed engine accommodates the provision of adaptable BPEL processes by exploiting information available to the process environment along with existing services. Adaptation in the context of our approach is about the identification and use of possible alternatives for the achievement of the goals and sub-goals defined in a BPEL process; these include the utilization of available, related information and/or services (or service chains). Data-driven adaptation incorporates Artificial Intelligence (AI) planning and context-aware computing techniques to support the discovery of process execution path substitutions at deployment time. When calculating the possible choices, the goal of our approach is to reduce the number of steps, i.e. the number of activities defined in the original process. In this way, data-driven adaptation complements the enhancement of the overall performance of our decentralized BPEL engine.

Overall, our solution is characterized by the following features:

  • Fully decentralized, P2P-based BPEL engine architecture. BPEL processes are deployed, executed, and monitored by a set of nodes organized in a hypercube P2P topology. Each node does not fully take charge of executing the whole process; rather, it contributes by running a subset of the process activities, and maintaining a sub-set of the generated process data. Thus the BPEL execution engine is fully operational without the need of any central controller components.

  • Fine-grained distribution of process activities. Decentralization of process execution fits to the nature of long-running business-to-business interactions, and significantly improves the performance and throughput of the execution infrastructure. BPEL processes are fully de- composed into their constituent activities. Large-scale parallelization is feasible as the various activities designated to run in parallel can be synchronized and executed by different nodes.

  • Proximity-based distribution of process variables. Since in many application domains processes consume and produce large volumes of data, it is important that those data are distributed in order to avoid resource exhaustion situations. Our algorithms make sure that the data produced by a BPEL process will be distributed across the nodes involved in its execution. Moreover, they will stay close to the process activities that produce them, thereby avoiding the unnecessary transfer of potentially large volumes of data between nodes as much as possible.

  • Asynchronous interaction with the client. Even if a BPEL process is synchronous, following the request-response communication pattern, the interaction between the client and the distributed execution engine occurs in an asynchronous, non-blocking manner. This way, the execution engine is able to serve multiple long-running process instances without the need to maintain open connections to the respective clients over long periods of time. Furthermore, while waiting for a long-running process instance to complete, clients are given the monitoring mechanisms to retrieve intermediate results, without intervening or inflicting additional delays to the process execution.

  • Efficient use of the available resources and balanced workload distribution. The proposed algorithms ensure that all nodes available in the P2P infrastructure will contribute to the execution of BPEL processes. The frequency of use of each node is taken into account upon load balancing, while efficient routing techniques are employed in order to achieve an even distribution of the workload at any given time and thereby avoid the emergence of performance bottlenecks.

  • Reuse of available data and services for process adaptation. The provided BPEL processes are expanded at deployment time with alternative execution paths and extension points. The latter are evaluated at runtime, so as to accommodate process adaptation based on the exploitation of available information elements, which are external to the process execution context.

  • Exchange of semantically annotated information with external sources. BPEL process instances are able to exchange information with external sources as long as the provided information is annotated with appropriate semantics. The infrastructure complies by a Linda-based architectural model, hence it permits the interaction of BPEL processes with any type of external information source. This mechanism is extendable with regards to the metadata primitives used for the annotation of information elements and supports their logical organization into groups.

  • Calculation of process adaptation paths at pre-execution time. Calculation of possible process adaptation paths involves that execution of time consuming computations and interactions with external systems, e.g. service registries. To avoid the overhead that would be introduced to the process execution by an on-the-fly adaptation approach, we perform all required computations at process deployment time.

All the aforementioned features are supported by our engine in a transparent fashion. Thus, no additional overhead is imposed on the BPEL process designer, the process clients, and the administrator of the execution infrastructure.

The objectives of this chapter have as follows:

  • To provide an overview of the literature in decentralized BPEL process execution and data-driven adaptation

  • To present a solution towards the performance improvement of service-oriented process execution based on the use of adaptable processes and distributed process execution

  • To illustrate the architecture, algorithms and mechanisms composing the Adaptive Execution Infrastructure


Provide broad definitions and discussions of the topic and incorporate views of others (literature review) into the discussion to support, refute or demonstrate your position on the topic.

The Web Services Business Process Execution Language

WS-BPEL 2.0 [ref] is the widely known OASIS standard used for the provision of executable business processes. Since almost the onset of the Service-Oriented Computing vision, WS-BPEL has emerged as the prominent approach for the interoperable specification of intra-corporate and business-to-business interactions, by providing a model and a grammar capable of describing the behaviour of a business process in terms of interactions between the process and its partners. As it constitutes the de facto standard for the specification of service-oriented processes it is briefly presented and analysed here.

Technically, WS-BPEL provides a language for the formal specification and modelling of both forms of business processes: i) executable and ii) abstract business processes. Executable business processes model actual behaviour of a participant in a business interaction, where abstract business processes use process descriptions to specify the mutually visible message exchange behaviour of the parties involved in the process. A brief list of its principle characteristics is the following:

  • It is an XML-based language that is based on XML Schema 1.0 [ref] for the definition of data structures and on XPath 1.0 [ref] for retrieval of XML elements (data manipulation).

  • It models a business process as a composition of elementary Web Services and depends on the W3C standards WSDL 1.1[ref] for the description of the inputs, outputs, and operations of a WS.

  • WS-BPEL defined business processes are exposed as WSs, so they can be accessed from another business process as a WS.

A WS-BPEL process specification is defined in terms of the following six main concepts:

  • Partner Link: the interaction with each partner occurs through WS interfaces. Particularly, a Partner Link encapsulates the structure of the relationship at the interface level between two partners (e.g. a Web Service and a process). A respective partner link type must be defined first to specify the required and provided WSDL port types. As we will see below, while partner link is the one, which provides the communication channel to remote WSs, the use of partner link type creates problems.

  • Variables: they are used to store both, message data of WS interactions and control data of the process.

  • Correlation: correlation sets specify in which business process instance a returned message from a WS should be retrieved, and that because long-running business processes are supported, so there may be several process instances waiting for the arrival of a WS message.

  • Basic Activities: they are separated in activities which communicate with Web Services (invoke, receive, reply), in activities which manipulate variables (assign), and in activities that wait or terminate a process (wait, exit).

  • Structured Activities: they can define the control flow of basic activities. They include activities, which specify sequential/ parallel execution (sequence/flow), activities that decide which branch will be executed (if-else), activities-loops (while).

  • Handlers: they are provided so as to deal with unexpected or exceptional situations and they are available in two forms, event handlers and fault handlers.

In general, a workflow (or seamlessly a process model), consists of three dimensions: (i) process logic, namely ’what’ is to be done, (ii) organization, namely ’who’ does it, and (iii) infrastructure, namely ’which’ tools are used. In WS-BPEL the ‘what’ dimension is based on activities and the ‘which’ dimension is based on Web Services. From the moment that activities directly refer to WSDL operations in order to call a Web Service, we infer that ‘which’ and ‘what’ dimensions are closely related. Indeed this bond is far from desirable and has been the source of severe criticism on WS-BPEL. This strong bond hinders the exploitation of services, which do not comply with the WSDL specification. Thus, the flexibility and reusability properties of WS-BPEL are largely affected by this. The advent of Semantic Web [OWL, WSML] and Semantic Web Services (SWS) [WSML, OWL-S] has aggravated this problem. SWS provide a declarative description of the service functionality, contrary to conventional Web Services where syntactic descriptions are the prime means for service interface definition. SWS give the opportunity to be discovered by criteria based on their functionality and not on their signature. This new opportunity cannot be directly exploited by WS-BPEL due to its strong bond with WSDL.

Another strong point of criticism to WS-BPEL is its strict nature, which poses significant barriers in the provision of dynamic process models. As business models (and process models consequently) mature the ability to evolve and adapt to changing conditions is becoming a necessity. Process models defined in WS-BPEL are unable to accommodate changes in user requirements and operation environments due to the inherently static nature of the WS-BPEL process flow specification. Thus, a process defined in WS-BPEL should be redesigned in cases where additional services or information should be integrated. This inability is a significant barrier towards the use of WS-BPEL in the provision of modern context-aware systems and many approaches have emerged in order to surpass it.

Distributed Scientific Workflow Systems

In the last years, developments in Scientific Workflow (SWF) systems have made possible the efficient, scalable execution of long-running workflows that comprise large numbers of parallel tasks, and operate on large sets of data. Since the challenges met by those efforts bear some resemblance to the motivation behind our work, we would like to emphasize on their different scope and technical foundations.

By definition, the majority of SWF solutions are particularly designed to support the modeling and execution of in silico simulations and scientific experiments. Moreover, they are mostly based on proprietary executable languages, which are tailor-made to the needs of such applications. On the other hand, by using the BPEL standard as its underlying basis, our engine has more general purposes and can be used to support a wider range of environments and applications. The different scopes of our proposed engine and the various SWF systems are also reflected by their pursued programming models. Due to their data-flow orientation, most SWF engines (see for instance Taverna (Missier, Soiland-Reyes, et al. 2010)) follow a functional, data-driven model, whereas BPEL engines, including the one presented in this chapter, implement an imperative, control-driven model. Hence, the focus of our contribution is on implementing algorithms that distribute the control flow of processes, in a way that no central coordinator is required. On the other hand, since the control flow is of minor importance to scientific workflows, SWF systems build on efficient parallelization and pipelining techniques, in order to improve the processing of large-scale data flows. For instance, Pegasus (Callaghan, Deelman et al. 2010) attains scalability by mainly addressing the large number of parallel tasks in a single workflow, and the corresponding voluminous data sets, through task clustering and in-advance resource provisioning. In our work, we are primarily interested in improving the throughput of the BPEL engine, and the average process execution times, in the presence of large numbers of concurrently running process instances that are long-running, and consume potentially large data sets.

Most SWF systems (e.g. Kepler (Altintas, Berkley, et al. 2004), Triana (Taylor, Shields, et al. 2003), or Pegasus (Deelman, Singh et al. 2005)) exhibit a clear separation of concerns between the design of a workflow and the execution infrastructure, although much effort has been spent on supporting Grid settings such as Globus. In general, however, Grid infrastructures are heavyweight, complex, and thus difficult to manage and maintain. In contrast, our BPEL engine is able to seamlessly organize and manage any set of nodes in a hypercube topology, so as to engage them in the execution of long-running and resource-demanding processes.

Still, despite their inherently different scopes, programming models, and scalability concerns, SWF systems have effectively dealt with advanced data management aspects, such as provenance (Altintas, Barney, & Jaeger-Frank 2006), or high-speed data transfer (Allcock, Bresnahan, et al. 2005). These features are complementary to our approach and could be accommodated by our BPEL engine to further enhance its capabilities and performance.

BPEL Decentralization

The decomposition and decentralized enactment of BPEL processes is a valid problem that has been the subject of many research efforts in the last years. In the following, we review a number of related results that have become available in the literature.

A P2P-based workflow management system called SwinDeW that enables the decentralized execution of workflows was proposed by Yan, Yang, & Raikundalia (2006). According to the authors, the generic workflow representation model is compatible with most concrete workflow languages including BPEL, although this compatibility is not demonstrated. In any case, similar to our presented approach, SwinDeW is based on the decomposition of a given workflow into its constituent tasks, and their subsequent assignment to the available nodes of a P2P network, in order to remove the performance bottleneck of centralized engines. A main difference between that approach and the one presented in this chapter lies in their corresponding worker recruitment algorithms: SwinDeW makes use of the JXTA (Gong 2001) peer discovery mechanism to find nodes with specific capabilities, and then quantifies their workload before assigning the given task to the one with the minimum workload. Since the respective discovery protocol cannot guarantee that all relevant peers will be found upon a query, it may become possible that not all available nodes in the P2P network are equally utilized. In our approach, the recruitment algorithm relies on the hypercube topology, the inherent ability to perform efficient random walks, and the frequency of use of each node in order to evenly divide the workload and thereby exploit all available resources.

The NINOS orchestration architecture (Li, Muthusami, & Jacobsen 2010) is based on a distributed content-based publish/subscribe (pub/sub hereinafter) infrastructure, which is leveraged to transform BPEL processes into fine-grained pub/sub agents. The latter then interact using pub/sub messages and collaborate in order to execute a process in a distributed manner. A critical departure of our work from the NINOS approach lies in the respective process deployment mechanisms. In NINOS, a BPEL process is deployed prior to its execution to a number of agents, which remain the same for all subsequent executions of the process. Hence, the infrastructure may underperform in the presence of multiple concurrent instances of the same process. In our case, the BPEL process is decomposed and its constituent activities are assigned to the available nodes in the P2P network at runtime, depending on their current workload, which is inferred by their frequency of use.

In an attempt to improve the throughput of the BPEL process execution infrastructure in the presence of multiple concurrent clients, a program partitioning technique has been proposed by Nanda, Chandra, & Sarkar (2004), which splits a given BPEL process specification into an equivalent set of processes. The latter are then executed by different server nodes without the need of a centralized coordinator. Similar approaches have also been proposed by Baresi, Maurino, & Modafferi (2006) as well as by Yildiz & Godart (2007). Along the same lines, the use of a penalty-based genetic algorithm to partition a given BPEL process and thereby allow decentralized execution was proposed by Ai, Tang, & Fidge (2011). However, to realize these partitioning techniques, each participating node must host a full-fledged BPEL engine, which is often heavyweight and therefore not always affordable by many small organizations and businesses. In our approach, there is no such requirement imposed on the nodes forming the underlying P2P infrastructure, and thus each node has a relatively small memory footprint. This way, our distributed BPEL engine can leverage and be deployed on hardware with limited capabilities.

A solution to the problem of decentralized BPEL workflow enactment that is based on the use of tuplespace technology was reported by Wutke, Martin, & Leymann (2008). According to that approach, workflows are defined as BPEL processes, which are split among all participating partners, and are implemented directly by the individual components. The latter are deployed and coordinate themselves using shared tuplespace(s). Like our approach, the tuplespace technology facilitates the execution of data-intensive workflows, since it allows for data distribution and yields a decrease of messages being passed between the interacting components. Unlike our approach, however, the overall decomposition requires considerable preparatory work such as component configuration to be conducted at deployment time, which could eventually become a scalability bottleneck.

In order to effectively separate the concerns of regular BPEL engines and various other complex aspects, including decentralized orchestration, Jimenez-Peris, Patino Martinez, & Martel-Jordan (2008) proposed the ZenFlow BPEL engine. ZenFlow employs techniques from reflective and aspect-oriented programming, and makes use of specialized meta-objects to describe and plug the extensions necessary for de- centralized execution into the centralized BPEL engine. In this work, however, decentralization is enabled by means of a cluster of centralized BPEL engines, with each one being responsible for the execution of the whole process each time. We follow a fine-grained decentralization strategy, whereby the BPEL process is decomposed into the constituent activities, the execution of which is distributed among the nodes of a P2P network.

The CEKK machine that was presented by Yu (2007) supports P2P execution of BPEL processes based on the continuation-passing style. In this approach, the execution control is formalized as a continuation, and is passed along from one processing unit to another without the interference of a central coordinating component. In this distributed execution environment, special attention is paid to the problem of failure handling and recovery, while a number of extensions to the BPEL language are introduced. Overall, this approach focuses on the formalization of a distributed process execution model and does not address aspects related to the structure of the P2P infrastructure, or the distribution of process activities and variables. Furthermore, it lacks an evaluation that would allow us to assess its applicability to the execution of long running and data-intensive BPEL processes.

  1   2   3

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur © 2016
rəhbərliyinə müraciət