A semantical framework to engineering WSBPEL processes

Mohsen Rouached, Walid Fdhila, Claude Godart
2008 Information Systems and E-Business Management  
Web services promise the interoperability of various applications running on heterogeneous platforms over the Internet, and are gaining more and more attention. Web service composition refers to the process of combining Web services to provide value-added services, which has received much interest in supporting enterprise application integration. Industry standards for Web Service composition, such as WSBPEL, provide the notation and additional control mechanisms for the execution of business
more » ... ocesses in Web Service collaborations. However, these standards do not provide support for checking interesting properties related to Web Service and process behaviour. In an attempt to fill this gap, we describe a formalization of WSBPEL business processes, that adds communications semantics to the specifications of interacting Web Services, and uses a formal logic to model their dynamic behaviour thus enabling their formal analysis and the inference of relevant properties of the systems being built. Introduction There is an increasing acceptance of Service-Oriented Architectures (SOA) as a paradigm for integrating software applications within and across organisational boundaries. In this paradigm, independently developed and operated applications are exposed as (Web) services that communicate with each other using XML-based standards, most notably SOAP and associated specifications [11] . While the technology for developing basic services and interconnecting them on a point-to-point basis has attained a certain level of maturity, there remain open challenges when it comes to engineering services that engage in complex interactions with multiple other services. A number of approaches have been proposed to address these challenges. One such approach, known as (process-oriented) service composition [4] has its roots in workflow and business process management. The idea of service composition is to capture the business logic and behavioural interface of services in terms of process models. These models may be expressed at different levels of abstraction, down to the executable level. A number of domain-specific languages for service composition have been proposed, with consensus gathering around the Business Process Execution Language for Web Services, which is known as BPEL4WS and recently WS-BPEL (or BPEL for short). WSBPEL [2] is quickly emerging as the language of choice for Web service composition. It provides a core of process description concepts that allow for the definition of business processes interactions. This core of concepts is used both for defining the internal business processes of a participant to a business interaction and for describing and publishing the external business protocol that defines the interaction behavior of a participant without revealing its internal behavior. WSBPEL opens up the possibility of applying a range of formal techniques to the verification of the behavior of Web services. For instance, it is possible to check the internal business process of a participant against the external business protocol that the participant is committed to provide; or, it is possible to verify whether the composition of two or more processes satisfies general properties (such as deadlock freedom) or application-specific constraints (e.g., temporal sequences,limitations on resources). These kinds of verifications are particularly relevant in the distributed and highly dynamic world of Web services, where each partner can autonomously redefine business processes and interaction protocols. In the long term, we envision an environment where an agent executing one or more business processes can autonomously discover new types of services and extends its own processes accordingly. Before being integrated in the actor's processes, discovered resources must be verified against the agent's own requirements and constraints. Different techniques have been already applied to the verification of business processes (see, e.g. [10, 8, 19, 18, 21] ). However, current approaches do not address the issues of how to model the requirements that the WSBPEL processes are supposed to satisfy, and of how to manage the evolution of processes and requirements. We are interested in particular in those techniques that are applied to the verification of BPEL compositions: in this case, we have to verify the behaviors generated by the interactions of a set of BPEL processes, each specifying the workflow and the protocol of one of the services participating to the composition. A key aspect for this kind of verification is the model adopted for representing the communications among the Web services. Indeed, the actual mechanism implemented in the existing BPEL execution engines is both very complex and implementation dependent. More precisely, BPEL processes exchange messages in an asynchronous way; incoming messages go through different layers of software, and hence through multiple queues, before they are actually consumed in the BPEL activity; and overpasses are possible among the exchanged messages. On the other hand, most of the approaches proposed for a formal verification of BPEL compositions are based on a synchronous model of communications, which does not require message queues and hence allows for a better performance in verification. This synchronous mechanism relies on some strong hypotheses on the interactions allowed in the composition: at a given moment in time, only one of the components can emit a message, and the receiver of that message is ready to accept it (see e.g., [8] ). However these hypotheses are not satisfied by many Web service composition scenarios of practical relevance, where critical runs can happen among messages emitted by different Web services. This is the case, for instance, when a Web service can receive inputs concurrently from two different sources, or when a service which is executing a time consuming task can receive a cancellation message before the task is completed.
doi:10.1007/s10257-008-0081-5 fatcat:q6lltyb6nnb5pk5ppr5mnd7z6i