Publications in Bussiness Process Execution Language


Articles in Refereed Journals:

  1. L. Baresi, D. Bianculli, C. Ghezzi, S. Guinea, P. Spoletini. Validation of web service compositions. IET Software, Vol. 1, Num. 6, pages 219-232, December 2007.
    Abstract: Web services support software architectures that can evolve dynamically. In particular, in this paper the focus is on architectures where services are composed (orchestrated) through a workflow described in the business process execution language (BPEL). It is assumed that the resulting composite service refers to external services through assertions that specify their expected functional and non-functional properties. On the basis of these assertions, the composite service may be verified at design time by checking that it ensures certain relevant properties. Because of the dynamic nature of web services and the multiple stakeholders involved in their provision, however, the external services may evolve dynamically, and even unexpectedly. They may become inconsistent with respect to the assertions against which the workflow was verified during development. As a consequence, validation of the composition must extend to run time. In this work, an assertion language, called assertion language for BPEL process interactions (ALBERT), is introduced; it can be used to specify both functional and non-functional properties. An environment which supports design-time verification of ALBERT assertions for BPEL workflows via model checking is also described. At run time, the assertions can be turned into checks that a software monitor performs on the composite system to verify that it continues to guarantee its required properties. A TeleAssistance application is provided as a running example to illustrate our validation framework.

  2. Bianculli, D., Ghezzi, C., Spoletini, P.. A Model Checking Approach to Verify BPEL4WS Workflows. Service-Oriented Computing and Applications, 2007. SOCA '07. IEEE International Conference on, To Appear, June 2007.
    Abstract: The increasing diffusion of service oriented computing in critical business transactions demands reliability and correctness of the workflow logic representing web service orchestrations. We present an approach for the formal verification of workflow-based compositions of web services, described in BPEL4WS. Workflow processes can be verified in isolation, assuming that the external services invoked are known only through their interface. It is also possible to verify that the actual composition of two or more processes behaves correctly. We can verify deadlock freedom, properties expressed as data-bound assertions written in WS-CoL, a specification language for web services, and LTL temporal properties. Our approach is based on the software model checker Bogor, whose language supports the modeling of all BPEL4WS constructs. We provide an empirical evaluation of our approach and we compare the results with other BPEL4WS model checking tools.

  3. Chun Ouyanga, Eric Verbeekb, Wil M.P. van der Aalst, Stephan Breutel, Marlon Dumas, Arthur H.M. ter Hofstede. Formal semantics and analysis of control flow in WS-BPEL. Science of Computer Programming, Vol. 67, Num. 2-3, pages 162-198, April 2007.
    Abstract: Web service composition refers to the creation of new (Web) services by combining functionalities provided by existing ones. A number of domain-specific languages for service composition have been proposed, with consensus being formed around a process-oriented language known as WS-BPEL (or BPEL). The kernel of BPEL consists of simple communication primitives that may be combined using control-flow constructs expressing sequence, branching, parallelism, synchronization, etc. We present a comprehensive and rigorously defined mapping of BPEL constructs onto Petri net structures, and use this for the analysis of various dynamic properties related to unreachable activities, conflicting messages, garbage collection, conformance checking, and deadlocks and lifelocks in interaction processes. We use a mapping onto Petri nets because this allows us to use existing theoretical results and analysis tools. Unlike approaches based on finite state machines, we do not need to construct the state space, and can use structural analysis (e.g., transition invariants) instead. We have implemented a tool that translates BPEL processes into Petri nets and then applies Petri-net-based analysis techniques. This tool has been tested on different examples, and has been used to answer a variety of questions.

  4. J. Cardoso. Complexity analysis of BPEL Web processes. Software Process: Improvement and Practice, Vol. 12, Num. 1, pages 35-49, Whiley-Interscience, 2007.
    Abstract: Several organizations have already realized the potential of using WS-BEPL, the Process Execution Language for Web Services, to model the behavior of Web services in business processes. WS-BPEL provides a model for describing simple or complex interactions between business partners. In some cases, WS-BPEL process designs can be highly complex, due, for example, to the vast number of Web services carried out in global markets. High complexity in a process has several undesirable drawbacks; it may result in poor understandability, more errors, defects, and exceptions, leading to processes requiring more time to be developed, tested, and maintained. Therefore, excessive complexity should be avoided. Processes that are highly complex tend be less flexible, since it is more complicated to make changes to the process. The major goal of this article is to present two metrics to analyze the control-flow complexity (CFC) of WS-BPEL Web processes. The metrics are to be used at design-time to evaluate the complexity of a process design before implementation actually takes place.

  5. James Pasley. How BPEL and SOA Are Changing Web Services Development. IEEE Internet Computing, Vol. 9, Num. 3, pages 60-67, 2005.
    Abstract: As the use of Web services grows, organizations are increasingly choosing the Business Process Execution Language for modeling business processes within the Web services architecture. In addition to orchestrating organizations' Web services, BPEL's strengths include asynchronous message handling, reliability, and recovery. By developing Web services with BPEL in mind, organizations can implement aspects of the service-oriented architecture that might previously have been difficult to achieve.

  6. Xiulan Yu, Long Zhang, Ying Li, Ying Chen. WSCE: a flexible Web Service Composition Environment. Web Services, 2004. Proceedings. IEEE International Conference on, To Appear, July 2004.
    Abstract: In this paper, we propose the concepts of virtual partner and inspector into the Web services composition. Virtual partner, as an IT level concept, is a Web service (pseudo Web service) using the same interface with the actual partner but different binding message. A virtual partner can be invoked directly by a business process described by BPEL, so that the BPEL programmer can test both application's functionality and non functionality performance early in the development cycle to avoid any problems in the final runtime, or test the selection of their partners in business level design. The IT virtual partners provide developers with a range of the techniques which let them explore every aspect of their program. Inspector is proposed when using the third-party process engine. An inspector itself is also a Web service. The programmer can register any required output information in it. The IT virtual partner and the inspector concepts have been integrated in our WSCE, a flexible Web Services Composition Environment for a business process. WSCE is a prototype of autonomic modeling and simulation environment. With the help of a third-party BPEL engine, it provides programmer with concepts and tools to facilitate business process programming.

  7. Marco Pistore, Marco Roveri, Paolo Busetta. Requirements-Driven Verification of Web Services. Electr. Notes Theor. Comput. Sci., Vol. 105, pages 95-108, 2004.
    Abstract: We propose a requirements-driven approach to the design and verification of Web services. The proposed methodology starts from a requirements model, which defines a business domain at a "strategic" level, describing the participating actors, their mutual dependencies, goals, requirements, and expectations. This business requirements model is then refined into a business process model. In this refinement, definitions of the processes carried out by the actors of the domain are added to the model in the form of BPEL4WS code. We show how to exploit model checking techniques for the verification of the specification, both at the requirements and at the process level. At the requirements level, model checking is used to validate the specification against a set of queries specified by the designer; at the process level, it is used to verify if the BPEL4WS processes satisfy the constraints described in the requirements model.

  8. W. van der Aalst. Don't go with the flow: Web services composition standards exposed. IEEE Intelligent Systems, To Appear, Jan/Feb 2003.
    Abstract: The recently released Business Process Execution Language for Web Services (BPEL4WS) is said to combine the best of other standards for web services composition such as WSFL from IBM and XLANG of Microsoft. BPEL4WS allows for a mixture of block structured and graph structured process models thus making the language expressive at the price of being complex. Although BPEL4WS is not such a bad proposal by itself, it is remarkable how much attention this standard receives while the more fundamental issues and problems such as semantics, expressiveness, and adequacy do not get the attention they deserve. Having a standard is a very good idea. However, there are too many of them and most of them die before becoming mature. A simple indicator of this development is the increasing length of acronyms: PDL, XPDL, BPSS, EDOC, BPML, WSDL, WSCI, ebXML, and BPEL4WS are just some of the acronyms referring to various standards in the domain. Another problem is that these languages typically have no clearly defined semantics. The only way to overcome these problems is to critically evaluate the so-called standards for web services composition, i.e., Don't go with the flow!


Articles in Refereed Conferences:

  1. Moreno Marzolla, Raffaela Mirandola. Performance Prediction of Web Service Workflows. Software Architectures, Components, and Applications, Lecture Notes in Computer Science, Vol. 4880, pages 127-144, January 2008.
    Abstract: Web Services play an important role in the SOA paradigm, as they allow services to be selected on-the-fly to build applications out of existing components. In this scenario, the BPEL notation can be used as an orchestration language which allows the user to describe interactions with Web Services in a standard way. The performance of a BPEL workflow is a very important factor for deciding which components must be selected, or to choose whether a given sequence of interactions can provide the requested quality of service. Due to its very dynamic nature, workflow performance evaluation can not be accomplished using traditional, heavy-weight techniques. In this paper we present a multi-view approach for the performance prediction of service-based applications encompassing both users and service provider(s) perspectives. As a first step towards the realization of this integrated framework we present an efficient approach for performance assessment of Web Service workflows described using the BPEL notation. Starting from annotated BPEL and WSDL specifications, we derive performance bounds on response time and throughput. In such a way users are able to assess the efficiency of a BPEL workflow, while service provider(s) can perform sizing studies or estimate performance gains of alternative upgrades to existing systems. To bring this approach to fruition we developed a prototype tool called bpel2qnbound, using which we analyze a simple case study.

  2. Sheng Chen, Liang Bao, Ping Chen. OptBPEL: A Tool for Performance Optimization of BPEL Process. Software Composition, pages 141-148, 2008.
    Abstract: The Business Process Execution Language (BPEL) is now a de facto standard for specifying and executing business process for web service composition and orchestration. As more and more web services are composed using BPEL, tuning these compositions and gain better performance becomes increasingly important. This paper presents our approach for optimizing the BPEL process and introduces OptBPEL, a tool for performance optimization of BPEL process. The approach starts from the optimization of synchronization structure concerning link in BPEL. After that, some concurrency analysis techniques are applied to obtain further performance improvement. Finally, we give some experiments and prove the efficiency of these optimization algorithms used in OptBPEL.

  3. Gero Decker, Oliver Kopp, Frank Leymann, Mathias Weske. BPEL4Chor: Extending BPEL for Modeling Choreographies. ICWS, pages 296-303, 2007.
    Abstract: The Business Process Execution Language (BPEL) is a language to orchestrate web services into a single business process. In a choreography view, several processes are interconnected and their interaction behavior is described from a global perspective. This paper shows how BPEL can be extended for defining choreographies. The proposed extensions (BPEL4Chor) distinguish between three aspects: (i) participant behavior descriptions, i.e. control flow dependencies in each participant, (ii) the participant topology, i.e. the existing participants and their interconnection using message links and (iii) participant groundings, i.e. concrete configurations for data formats and port types. As BPEL itself is used unchanged, the extensions facilitate a seamless integration between service choreographies and orchestrations. The suitability of the extensions is validated by assessing their support for the Service Interaction Patterns.

  4. Dmytro Rud, Andreas Schmietendorf, Reiner Dumke. Performance Modeling of WS-BPEL-Based Web Service Compositions. Services Computing Workshops, pages 140-147, September 2006.
    Abstract: This paper addresses quality of service aspects of Web service orchestrations created using WS-BPEL from the standpoint of a Web service integrator. A mathematical model based on operations research techniques and formal semantics of WS-BPEL is proposed to estimate and forecast the influence of the execution of orchestrated processes on utilization and throughput of individual involved nodes and of the whole system. This model is applied to the optimization of service levels agreement process between the involved parties

  5. Wil M. P. van der Aalst, Marlon Dumas, Chun Ouyang, Anne Rozinat, H. M. W. Verbeek. Choreography Conformance Checking: An Approach based on BPEL and Petri Nets. The Role of Business Processes in Service Oriented Architectures, 2006.
    Abstract: Recently, languages such as BPEL and CDL have been proposed to describe the way services can interact from a behavioral perspective. The emergence of these languages heralds an era where richer service descriptions, going beyond WSDL-like interfaces, will be available. However, what can these richer service descriptions serve for? This paper investigates a possible usage of behavioral service descriptions, namely as input for conformance checking. Conformance checking is the act of verifying whether one or more parties stick to the agreed-upon behavior by observing the actual behavior, e.g., the exchange of messages between all parties. This paper shows that it is possible to translate BPEL business protocols to Petri nets and to relate SOAP messages to transitions in the Petri net. As a result, Petri net-based conformance checking techniques can be used to quantify fitness (whether the observed behavior is possible in the business protocol) and appropriateness (whether the observed behavior "overfits" or "underfits" the business protocol). Moreover, non-conformance can be visualized to pinpoint deviations. The approach has been implemented in the context of the ProM n framework.

  6. Fabio Barbon, Paolo Traverso, Marco Pistore, Michele Trainotti. Run-Time Monitoring of Instances and Classes of Web Service Compositions. ICWS, pages 63-71, 2006.
    Abstract: The run-time monitoring of web service compositions has been widely acknowledged as a significant and challenging problem. In this paper, we propose a novel solution to the problem of monitoring web services implemented in BPEL. We devise an architecture that clearly separates the business logic of a web service from its monitoring functionality. The architecture supports both "instance monitors" that deal with the execution of a single instance of BPEL process, as well as "class monitors" that report aggregated information about all the instances of a BPEL process. We also define a language for the specification of instance and class monitors. The language allows for specifying boolean, statistic, and time-related properties. Finally, we devise a technique for the automatic translation of all these kinds of monitors to Java programs.

  7. Marina Mongiello, Daniela Castelluccia. Modelling and verification of BPEL business processes. Fourth Workshop on Model-Based Development of Computer-Based Systems, 2006.
    Abstract: A business process is a complex Web service with functions provided by different Web services, which are already existing in Web and are dynamically integrated for granting a more complex business task. For this reason, business processes have become more and more diffuse in B2B and B2C domains, so that the importance of their activities asks for a high-level of reliability. Methods and tools for supporting automatic system verification and validation could be useful. Among the techniques of automatic verification, we choose model checking method, because we applied it efficiently for verification of a single Web service and in this paper we extend the area of application also in business processes. Descriptions of the behavior of a business process are coded using a standard language, BPEL4WS, that has broadly spread because it is able to describe a business process as both an executable process and an abstract process. Therefore, we model a BPEL description of a generic business process with a formal model and we formalize correctness properties about the reliability of the business process design. Also, we build a framework that performs automatic verification of formal models of business processes through NuSMV model checker. If there is a violation of correctness specifications, NuSMV provides counter-examples, so we can locate errors and effect right changes for correcting business process design.

  8. Yuan Yuan, Zhongjie Li, Wei Sun. A Graph-Search Based Approach to BPEL4WS Test Generation. ICSEA, 14 pages, 2006.
    Abstract: Business Process Execution Language for Web Services (BPEL4WS) is a kind of concurrent programming languages with several special features that raise special challenges for verification and testing. This paper proposes a graph-search based approach to BPEL test case generation, which effectively deals with BPEL concurrency semantics. This approach defines an extension of CFG (Control Flow Graph) - BPEL Flow Graph (BFG) - to represent a BPEL program in a graphical model. Then concurrent test paths can be generated by traversing the BFG model, and test data for each path can be generated using a constraint solving method. Finally test paths and data are combined into complete test cases.

  9. Bernd-Holger Schlingloff, Axel Martens, Karsten Schmidt. Modeling and Model Checking Web Services. Vol. 126, pages 3-26, Elsevier, March 2005.
    Abstract: We give an overview on web services and the web service technology stack. We then show how to build Petri net models of web services formulated in the specification language BPEL4WS. We define an abstract correctness criterion for these models and study the automated verification according to this criterion. Finally, we relate correctness of web service models to the model checking problem for alternating temporal logics.

  10. Jorge Cardoso. About the Data-Flow Complexity of Web Processes. 6th International Workshop on Business Process Modeling, Development, and Support: Business Processes and Support Systems: Design for Flexibility, pages 67-74, 2005.
    Abstract: Abstract. Organizations are increasingly faced with the challenge of managing e-commerce and e-business applications involving Web services and Web processes. In some cases, Web processes’ design can be highly complex, due, for example, to the vast number of services carried out in global markets. High complexity in a process has several undesirable drawbacks, it may result in bad understandability, more errors, defects, and exceptions leading processes to need more time to develop, test, and maintain. Therefore, excessive complexity should be avoided. Flexibility and complexity are guiding principles in the design of business processes. In most business processes, flexibility and complexity are related inversely. Processes with a high complexity tend be less flexible, since it is more complicated to make changes to the process. In our previous work we have defined a metric to measure the control-flow complexity of Web processes. The major goal of this paper is to study the issues and establish the requirements for the development of a metric to analyze the data-flow complexity of Web processes.

  11. Samuele Carpineti, Cosimo Laneve, Paolo Milazzo. BoPi - A Distributed Machine for Experimenting Web Services Technologies. ACSD, pages 202-211, 2005.
    Abstract: BoPi is a programming language with a runtime support that allows the distribution and the execution of programs over the network. The language is a process calculus with XML values and datatypes, and with a pattern matching mechanism for deconstructing values. The compiler gives a typesafe bytecode in the form of an XML document, that may be deployed on the network. What comes out is a simple, statically typed, and formally defined core BPEL language with a basic query mechanism supplied by patterns.

  12. Dimka Karastoyanova, Alejandro Houspanossian, Mariano Cilia, Frank Leymann, Alejandro P. Buchmann. Extending BPEL for Run Time Adaptability. EDOC, pages 15-26, 2005.
    Abstract: The existing Web Service Flow (WS-flow) technologies enable both static and dynamic binding of participating Web services (WSs) on the process model level. Adaptability on per-instance basis is not sufficiently supported and therefore must be addressed to improve process flexibility upon changes in the environment. Ad-hoc process instance changes can be enabled by swapping participating WS instances, by modifying port Types of the partners to be invoked, and by changing process logic. In this work we address the problem of dynamic binding of WSs to WS-flow instances at run time, i.e. the ability to exchange a WS instance participating in a WS-flow instance with an alternative one. The problem is additionally complicated by the fact that the execution of a process depends on its deployment. We describe the "find and bind" mechanism, and we show its representation as a BPEL extension. We discuss the benefits that could be gained and the disadvantages it brings in. The mechanism extends and improves the existing process technologies. It facilitates a precisely controlled policy-based selection of WSs at run time and also provides for process instance repair, while maintaining simplicity. We also discuss a prototypical implementation of the presented functionality.

  13. Florian Rosenberg, Schahram Dustdar. Business Rules Integration in BPEL - A Service-Oriented Approach. CEC, pages 476-479, 2005.
    Abstract: Business rules change quite often. These changes cannot be handled efficiently by representing business rules embedded in the source code of the business logic. Efficient handling of rules that govern ones business is one factor for success. That is where business rules engines play an important role. The service-oriented computing paradigm is becoming more and more popular. Services offered by different providers, are composed to new services by using Web service composition languages such as BPEL. Such process-based composition languages lack the ability to use business rules managed by different business rules engines in the composition process. In this paper, we propose an approach on how to use and integrate business rules in a service-oriented way into BPEL.

  14. Jesus Arias-Fisteus, Luis Sanchez Fernandez, Carlos Delgado Kloos. Formal Verification of BPEL4WS Business Collaborations. E-Commerce and Web Technologies, 5th International Conference, EC-Web 2004, Proceedings, Lecture Notes in Computer Science, Vol. 3182, pages 76-85, Springer Verlag, 2004.
    Abstract: Web services are a very appropriate communication mechanism to perform distributed business processes among several organisations. These processes should be reliable, because a failure in them can cause high economic losses. To increase their reliability at design time, we have developed VERBUS, a framework for the formal verification of business processes. VERBUS can automatically translate business process definitions to specifications verifiable in several available tools. It is based on a modular and extensible architecture: new process definition languages and verification tools can be added easily to the framework. The prototype of VERBUS presented in this work can verify BPEL4WS process specifications, by translating them to Promela. The Promela specifications are verified with the well known model checker Spin. In this paper we describe the general architecture of VERBUS and how BPEL4WS specifications are translated and verified. The explanation is completed by describing what types of properties can be verified and providing an overview of the implementation.

  15. Roozbeh Farahbod, Uwe Glässer, Mona Vajihollahi. Specification and Validation of the Business Process Execution Language for Web Services. Abstract State Machines, pages 78-94, 2004.
    Abstract: We formally define an abstract executable semantics for the Business Process Execution Language for Web Services in terms of a distributed ASM. The goal of this work is to support the design and standardization of the language. There is a need for formalism. It will allow us to not only reason about the current specification and related issues, but also uncover issues that would otherwise go unnoticed. Empirical deduction is not sufficient. - Issue 42, OASIS WSBPEL TC. The language definition assumes an infrastructure for running Web services on some asynchronous communication architecture. A business process is built on top of a collection of Web services performing continuous interactions with the outside world by sending and receiving messages over a communication network. The underlying execution model is characterized by its concurrent and reactive behavior making it particularly difficult to predict dynamic system properties with a sufficient degree of detail and precision under all circumstances.

  16. Xiang Fu, Tevfik Bultan, Jianwen Su. Analysis of Interacting BPEL Web Services. WWW'04: Proceedings of the 13th International Conference on World Wide Web, pages 621-630, ACM Press, 2004.
    Abstract: This paper presents a set of tools and techniques for analyzing interactions of composite web services which are specified in BPEL and communicate through asynchronous XML messages. We model the interactions of composite web services as conversations, the global sequence of messages ex- changed by the web services. As opposed to earlier work, our tool-set handles rich data manipulation via XPath expressions. This allows us to verify designs at a more detailed level and check properties about message content. We present a framework where BPEL specifications of web ser- vices are translated to an intermediate representation, followed by the translation of the intermediate representation to a verification language. As an intermediate representation we use guarded automata augmented with unbounded queues for incoming messages, where the guards are expressed as XPath expressions. As the target verification language we use Promela, input language of the model checker SPIN. Since SPIN model checker is a finite-state verification tool we can only achieve partial verification by fixing the sizes of the input queues in the translation. We propose the concept of synchronizability to address this problem. We show that if a composite web service is synchronizable, then its conversation set remains same when asynchronous communication is replaced with synchronous communication. We give a set of sufficient conditions that guarantee synchronizability and that can be checked statically. Based on our synchronizability results, we show that a large class of composite web services with unbounded input queues can be completely verified using a finite state model checker such as SPIN.

  17. Andreas Wombacher, Peter Fankhauser, Erich J. Neuhold. Transforming BPEL into Annotated Deterministic Finite State Automata for Service Discovery. ICWS, pages 316-323, 2004.
    Abstract: Web services advocate loosely coupled systems, although current loosely coupled applications are limited to stateless services. The reason for this limitation is the lack of a method supporting matchmaking of state dependent services exemplarily specified in BPEL. In particular, the sender's requirement that the receiver must support all possible messages sent at a certain state are not captured by models currently used for service discovery. Annotated deterministic finite state automata provide this expressiveness. In this paper the transformation of a local process specification given in BPEL to annotated deterministic finite state automata is presented.


Books and Monographs:

  1. Mariya Koshkina. Verification of Business Processes for Web Services. Ms. Thesis, York University - Department of Computer Science, October 2003.
    Abstract: The Business Process Execution Language for Web Services (BPEL4WS or simply BPEL) is a recently developed language, which is used to specify interactions between web services. Among its features it allows specification of concurrent behavior. Erroneous specification can lead to such problems as deadlock. In our research we focus on the concurrency mechanism in BPEL. Our main goal is to analyze processes in order to detect possible deadlocks. To achieve this we introduce a process algebra called the BPE-calculus. It is a small language which captures all the BPEL features relevant to the analysis. This process algebra is modelled using a labeled transition system. An existing verification tool called the Concurrency Workbench is customized to use our BPE-calculus. This tool allows us to verify many properties of BPE-calculus processes specified in a logic called the mu-calculus, including deadlock freedom.


Publications in Refereed Workshops:

  1. S. Nakajima. Model-Checking Behavioral Specification of BPEL Applications. Proceedings of the International Workshop on Web Languages and Formal Methods, WLFM 2005, 2005.
    Abstract: To provide a framework to compose lots of specialised services flexibly, BPEL is proposed to describe Web service flows. Since the Web service flow description is basically a distributed collaboration, writing correct programs in BPEL is not easy. Verifying BPEL program prior to its execution is essential. This paper proposes a method to extract the behavioral specification from a BPEL appliation program and to analyze it by using the SPIN model checker. With the adequate abstraction method and support for DPE, the method can analyze all the four example cases in the BPEL standard document.


Technical Reports and Manuals:

  1. Oliver Kopp, Rania Khalaf, Frank Leymann. Reaching Definitions Analysis Respecting Dead Path Elimination Semantics in BPEL Processes. Num. 2007/04, Institut für Architektur von Anwendungssystemen, November 2007.
    Abstract: The Business Process Execution Language for Web Services (BPEL) is a workflow language geared towards Service Oriented Computing. BPEL provides basic workflow capabilities, such as the ability to impose control on a set of activities via explicit links, as well as advanced features such as recovery and event handling. The area of workflow often requires understanding the data dependencies as well as the control dependencies between activities. This aids in business process design as well as in analysis and rengineering. BPEL, however, uses shared variables to model data. Activities read and write data to these variables, i.e. there is no explicit data link construct. In order to draw out the flow of data between the activities of a BPEL process, one must therefore perform data-flow analysis on that process. To address this problem, we present an algorithm that statically determines such data dependencies. "Statically" means, that we do not determine the dependencies per process instance at runtime, but on the process model without creating any instances. Mainstream data-flow analysis techniques are presented in [ALSU06, Muc97, NNH04]. However, these techniques cannot be directly applied to a BPEL process, since BPEL supports both parallelism and dead path elimination (DPE, [CDG+ 03, OAS07, CKLW03, BK05, LR00]). DPE is a technique used in BPEL to propagate activity disablement down paths that can no longer be executed. The algorithm in this paper consists of reaching definitions analysis dealing with DPE, enabling it to reduce the number of data dependencies when compared to approaches not dealing with DPE.

  2. Diane Jordan, John Evdemon, Alexandre Alves, Assaf Arkin, Sid Askary, Charlton Barreto, Ben Bloch, Francisco Curbera, Mark Ford, Yaron Goland, Alejandro Guízar, Neelakantan Kartha, Canyang Kevin Liu, Rania Khalaf, Dieter König, Mike Marin, Vinkesh Mehta, Satish Thatte, Danny van der Rijn, Prasad Yendluri, Alex Yiu . Web Services Business Process Execution Language Version 2.0. IBM, Microsoft, BEA, Intalio, Individual, Adobe Systems, Systinet, Active Endpoints, JBoss, Sterling Commerce, SAP, Deloitte, TIBCO Software, webMethods, Oracle, 2007.
    Abstract: This document defines a language for specifying business process behavior based on Web Services. This language is called Web Services Business Process Execution Language (abbreviated to WS-BPEL in the rest of this document). Processes in WS-BPEL export and import functionality by using Web Service interfaces exclusively. Business processes can be described in two ways. Executable business processes model actual behavior of a participant in a business interaction. Abstract business processes are partially specified processes that are not intended to be executed. An Abstract Process may hide some of the required concrete operational details. Abstract Processes serve a descriptive role, with more than one possible use case, including observable behavior and process template. WS-BPEL is meant to be used to model the behavior of both Executable and Abstract Processes. WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to- business spaces.

  3. Tony Andrews, Francisco Curbera, Hitesh Dholakia, Yaron Goland, Johannes Klein, Frank Leymann, Kevin Liu, Dieter Roller, Doug Smith, Satish Thatte, Ivana Trickovic, Sanjiva Weerawarana. Business Process Execution Language for Web Services, version 1.1. BEA Systems, International Business Machines Corporation, Microsoft Corporation, SAP AG, Siebel Systems, 2003.
    Abstract: This document defines a notation for specifying business process behavior based on Web Services. This notation is called Business Process Execution Language for Web Services (abbreviated to BPEL4WS in the rest of this document). Processes in BPEL4WS export and import functionality by using Web Service interfaces exclusively. Business processes can be described in two ways. Executable business processes model actual behavior of a participant in a business interaction. Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes. BPEL4WS is meant to be used to model the behavior of both executable and abstract processes. BPEL4WS provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web Services interaction model and enables it to support business transactions. BPEL4WS defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.

<scube-tech-UPM-local@clip.dia.fi.upm.es> Last updated on Mon Jun 30 14:39:14 CEST 2008