Web Service Composition Based on Petri Nets: Review and Contribution

Abstract

LNCS n°8194International audienceWeb Services (WSs) are the most used implementation of service-oriented architectures allowing the construction and the sharing of independent and autonomous software. WS composition consists in combining several WSs into a Composite one, which becomes a value-added service, in order to satisfy complex users queries. Thus, the WS composition process may imply several phases to identify how and which WSs will conform the Composite WS, including specification, verification, evaluation, WSs selection, and execution. As it is known, Petri Nets are the main formal models used to describe static vision of a system and dynamic behavior of processes. Then, Petri Nets are well suited to model internal operations of WSs and interactions among them as well as to model the processes in all phases of the WS composition process. In this article we present a review of approaches using Petri Nets for WS composition. Moreover, we describe our experiences in this field: a transactional-QoS-driven WS selection approach and a framework for reliable execution of Composite WSs based on Colored Petri Nets

Reliability prediction and QoS selection for web service composition

“…Several approaches proposed in [15][16][17] have some things in common: (1) They use Petri net to model control flows or path in the process of service composition. Inputs and outputs of places in Petri net only come from user's request.…”

“…However, composite service reliability is affected by the reliability of each component service in the composition, and the reliability of the operating environment. Existing methods including literature [15][16][17] assume that reliability of atomic and component services are known on the basis of which reliability of composite service is computed. Besides, environmental impacts for composition reliability are overlooked.…”

Fuzzy ACID properties for self‐adaptive composite cloud services execution

“…[4][5][6][7] Traditional ACID transaction model provides an "all-or-nothing" execution approach to support service failures generally based on transactional properties, compensation, rollback, and replication. The constantly increasing number of such services for accessing data on the cloud arises new challenges for enabling their integration and collaboration while guarantying self-organization and self-adaptivity properties, specially to manage failures.…”

“…() Meanwhile, transactional support is a way to guarantee reliable composite service (CS), by considering the classical ACID (atomicity, consistency, isolation, and durability) transactional properties or a variation of them. ()…”

“…2,3 Meanwhile, transactional support is a way to guarantee reliable composite service (CS), by considering the classical ACID (atomicity, consistency, isolation, and durability) transactional properties or a variation of them. [4][5][6][7] Traditional ACID transaction model provides an "all-or-nothing" execution approach to support service failures generally based on transactional properties, compensation, rollback, and replication. However, for some applications, the classical "all-or-nothing" model is too restrictive for independent and multi-proprietors services running on distributed environments, such as cloud platforms.…”