Abstract: In this paper we present Colombo, a framework in which web services are characterized in terms of (i) the atomic processes (i.e., operations) they can perform; (ii) their impact on the “real world ” (modeled as a relational database); (iii) their transition-based behavior; and (iv) the messages they can send and receive (from/to other web services and “human ” clients). As such, Colombo combines key elements from the standards and research literature on (semantic) web services. Using Colombo, we study the problem of automatic service composition (synthesis) and devise a sound, complete and terminating algorithm for building a composite service. Specifically, the paper develops (i) a technique for handling the data, which ranges over an infinite domain, in a finite, symbolic way, and (ii) a technique to automatically synthesize composite web services, based on Propositional Dynamic Logic. 1

Abstract. We study services modeled as open workflow nets (oWFN) and describe their behavior as service automata. Based on arbitrary finite-state service automata, we introduce the concept of an operating guideline, generalizing the work of [1,2] which was restricted to acyclic services. An operating guideline gives complete information about how to properly interact (in this paper: deadlock-freely and with limited communication) with an oWFN N. It can be executed, thus forming a properly interacting partner of N, or it can be used to support service discovery. An operating guideline for N is a particular service automaton S that is enriched with Boolean annotations. S interacts properly with the service automaton Prov, representing the behavior of N, and is able to simulate every other service that interacts properly with Prov. The attached annotations give complete information about whether or not a simulated service interacts properly with Prov, too. 1

Abstract. We present a Petri net semantics for the Business Process Execution Language for Web Services (BPEL). Our semantics covers the standard behaviour of BPEL as well as the exceptional behaviour (e.g. faults, events, compensation). The semantics is implemented as a parser that translates BPEL specifications into the input language of the Petri net model checking tool LoLA. We demonstrate that the semantics is well suited for computer aided verification purposes. Key words: Business process modeling and analysis, Formal models in business

In this paper, we address the problem of the automated composition of web services by planning on their “knowledge level ” models. We start from descriptions of web services in standard process modeling and execution languages, like BPEL4WS, and automatically translate them into a planning domain that models the interactions among services at the knowledge level. This allows us to avoid the explosion of the search space due to the usually large and possibly infinite ranges of data values that are exchanged among services, and thus to scale up the applicability of state-of-the-art techniques for the automated composition of web services. We present the theoretical framework, implement it, and provide an experimental evaluation that shows the practical advantage of our approach w.r.t. techniques that are not based on a knowledgelevel representation. 1

Web services technologies enable flexible and dynamic interoperation of autonomous software and information systems. A central challenge is the development of modeling techniques and tools for eanbling the (semi-)automatic composition and analysis of these services, taking into account their semantic and behavioral properties. This paper presents an overview of the fundamental assumptions and concepts underlying current work on service composition, and provides a sampling of key results in the area. It also provides a brief tour of several composition models including semantic web services, the “Roman” model, and the Mealy/conversation model.

We propose a novel planning framework for the automated composition of web services. We consider services that are specified and implemented in industrial standard languages for business processes modeling and execution, like BPEL4WS. These languages describe web services whose behavior is intrinsically asynchronous. For this reason, the key aspect of our framework is the modeling of asynchronous planning problems. In the paper we describe the framework and propose a planning approach that is based on state of the art techniques for planning under uncertainty. Our experiments show that this approach can scale up to significant cases, i.e., to cases in which the manual development of BPEL4WS composed services is not trivial and is time consuming.

Abstract. This paper addresses the problem of analyzing the interaction between BPEL processes. We present a technology chain that starts out with a BPEL process and transforms it into a Petri net model. On the model we decide controllability of the process (the existence of a partner process, such that both can interact properly) and compute its operating guideline (a characterization of all properly interacting partner processes). A case study demonstrates the value of this technology chain. Key words: Business process modeling and analysis, Formal models in business

Abstract not found

Abstract not found

We present a language for specifying web service interfaces. A web service interface puts three kinds of constraints on the users of the service. First, the interface specifies the methods that can be called by a client, together with types of input and output parameters; these are called signature constraints. Second, the interface may specify propositional constraints on method calls and output values that may occur in a web service conversation; these are called consistency constraints. Third, the interface may specify temporal constraints on the ordering of method calls; these are called protocol constraints. The interfaces can be used to check, first, if two or more web services are compatible, and second, if a web service A can be safely substituted for a web service B. The algorithm for compatibility checking verifies that two or more interfaces fulfill each others' constraints. The algorithm for substitutivity checking verifies that service A demands fewer and fulfills more constraints than service B.