Web Services: A Process Algebra Approach

It is now well-admitted that formal methods are helpful for many issues raised in the Web service area. In this paper we present a framework for the design and verification of WSs using process algebras and their tools. We define a two-way mapping between abstract specifications written using these calculi and executable Web services written in BPEL4WS. Several choices are available: design and correct errors in BPEL4WS, using process algebra verification tools, or design and correct in process algebra and automatically obtaining the corresponding BPEL4WS code. The approaches can be combined. Process algebra are not useful only for temporal logic verification: we remark the use of simulation/bisimulation both for verification and for the hierarchical refinement design method. It is worth noting that our approach allows the use of any process algebra depending on the needs of the user at different levels (expressiveness, existence of reasoning tools, user expertise)

A Calculus for Orchestration of Web Services

We introduce COWS (Calculus for Orchestration of Web Services), a new foundational language for SOC whose design has been influenced by WS-BPEL, the de facto standard language for orchestration of web services. COWS combines in an original way a number of ingredients borrowed from well-known process calculi, e.g. asynchronous communication, polyadic synchronization, pattern matching, protection, delimited receiving and killing activities, while resulting different from any of them. Several examples illustrates COWS peculiarities and show its expressiveness both for modelling imperative and orchestration constructs, e.g. web services, flow graphs, fault and compensation handlers, and for encoding other process and orchestration languages

COWS: A Timed Service-Oriented Calculus

COWS (Calculus for Orchestration of Web Services) is a foundational language for Service Oriented Computing that combines in an original way a number of ingredients borrowed from well-known process calculi, e.g. asynchronous communication, polyadic synchronization, pattern matching, protection, delimited receiving and killing activities, while resulting different from any of them. In this paper, we extend COWS with timed orchestration constructs, this way we obtain a language capable of completely formalizing the semantics of WS-BPEL, the ‘de facto’ standard language for orchestration of web services. We present the semantics of the extended language and illustrate its peculiarities and expressiveness by means of several examples

Using formal methods to develop WS-BPEL applications

In recent years, WS-BPEL has become a de facto standard language for orchestration of Web Services. However, there are still some well-known difficulties that make programming in WS-BPEL a tricky task. In this paper, we firstly point out major loose points of the WS-BPEL specification by means of many examples, some of which are also exploited to test and compare the behaviour of three of the most known freely available WS-BPEL engines. We show that, as a matter of fact, these engines implement different semantics, which undermines portability of WS-BPEL programs over different platforms. Then we introduce Blite, a prototypical orchestration language equipped with a formal operational semantics, which is closely inspired by, but simpler than, WS-BPEL. Indeed, Blite is designed around some of WS-BPEL distinctive features like partner links, process termination, message correlation, long-running business transactions and compensation handlers. Finally, we present BliteC, a software tool supporting a rapid and easy development of WS-BPEL applications via translation of service orchestrations written in Blite into executable WS-BPEL programs. We illustrate our approach by means of a running example borrowed from the official specification of WS-BPEL

A Calculus for Orchestration of Web Services

Service-oriented computing, an emerging paradigm for distributed computing based on the use of services, is calling for the development of tools and techniques to build safe and trustworthy systems, and to analyse their behaviour. Therefore, many researchers have proposed to use process calculi, a cornerstone of current foundational research on specification and analysis of concurrent, reactive, and distributed systems. In this paper, we follow this approach and introduce CWS, a process calculus expressly designed for specifying and combining service-oriented applications, while modelling their dynamic behaviour. We show that CWS can model all the phases of the life cycle of service-oriented applications, such as publication, discovery, negotiation, orchestration, deployment, reconfiguration and execution. We illustrate the specification style that CWS supports by means of a large case study from the automotive domain and a number of more specific examples drawn from it

Regulating Data Exchange in Service Oriented Applications

We define a type system for COWS, a formalism for specifying and combining services, while modelling their dynamic behaviour. Our types permit to express policies constraining data exchanges in terms of sets of service partner names attachable to each single datum. Service programmers explicitly write only the annotations necessary to specify the wanted policies for communicable data, while a type inference system (statically) derives the minimal additional annotations that ensure consistency of services initial configuration. Then, the language dynamic semantics only performs very simple checks to authorize or block communication. We prove that the type system and the operational semantics are sound. As a consequence, we have the following data protection property: services always comply with the policies regulating the exchange of data among interacting services. We illustrate our approach through a simplified but realistic scenario for a service-based electronic marketplace

Model-checking Web Services Orchestrations using BP-calculus

AbstractThe Business Process Execution Language for Web Services (BPEL) is the standard for implementing orchestrated business processes designed but not limited to, as web services. BPEL is a powerful language but lacks a widely accepted formal semantics, and this makes it difficult to formally validate the correct execution of BPEL implementations. In the other hand, process algebras have proved their efficiency in the specification of web services orchestrations. In this paper we improve the BP-calculus, a π-calculus based formalism designed to ease the automatic generation of verified BPEL code, by defining specific equivalence and logic in order to verify BPEL implementations through their formal specification expressed in this calculus. The formal specification of service-oriented applications allows the checking of functional properties described by means of the new logic, that is shown to be well suited to capture peculiar aspects of services formalized in π-like languages. As an illustrative example, we present the BP-calculus specification and the verification results of a trade market service scenario

A compensating transaction example in twelve notations

The scenario of business computer systems changed with the advent of cross-entity computer interactions: computer systems no longer had the limited role of storing and processing data, but became themselves the players which actuated real-life actions. These advancements rendered the traditional transaction mechanism insufficient to deal with these new complexities of longer multi-party transactions. The concept of compensations has long been suggested as a solution, providing the possibility of executing “counter”-actions which semantically undo previously completed actions in case a transaction fails. There are numerous design options related to compensations particularly when deciding the strategy of ordering compensating actions. Along the years, various models which include compensations have emerged, each tackling in its own way these options. In this work, we review a number of notations which handle compensations by going through their syntax and semantics — highlighting the distinguishing features — and encoding a typical compensating transaction example in terms of each of these notations.peer-reviewe