Transactional-Aware Web Service Composition: A Survey

Introduction

Web Services (WSs) are quickly raising as a standard for publishing data and operations for weakly loose, heterogeneous systems, by handling simple request and response messages from/to users to satisfy their requirements. WSs are the most famous implementation of Service-Oriented Architectures (SOA) (Erl, 2005) allowing the construction and the sharing of independent and autonomous software. Flexible SOA connections between services, as well as, software components that pass simple data among other services or that coordinate simple activities, are seen as services which can be combined with other services to achieve specific goals. Thus, SOA provides a scalable and robust framework to integrate heterogeneous software agents and enhance reliability of isolated software components (Papazoglou et al., 2007).

As WSs proliferate, it becomes more difficult to find a specific service that can perform a given task, and combinations of several services may be required to satisfy the more complex user queries, which claim for functional and non-functional requirements. SOA technology trend proposes that applications should not be manually developed but integrated from an adequate set of already existing and available WSs. Successive compositions of WSs usually create a complex structure of interactions among a large number of Composite WSs (CWSs) distributed over the Internet. In this sense, automatic service composition has a great potential to facilitate the integration of WSs deployed in distributed platforms (Rao & Su, 2004). In this context, Web Service Composition (WS Composition) consists in aggregating pre-existing WSs, developed by different organizations and offering diverse functional (e.g. ticket purchase, information search), Quality of Service (e.g. execution time, price), and transactional (e.g. compensable or not) properties, to produce a CWS. It allows building, what is called by Ben Lakhal et al. (2009), value-added services or more powerful and feature-rich processes.

Web Service Selection corresponds to the step of the WS Composition process where the most appropriate service is selected for each operation from a set of candidates which are differentiated by their non-functional properties (Li et al., 2009). The selection task can be static or dynamic. As explained by Egambaram et al. (2010), the differentiation between both selection techniques deals with the moment at which a concrete WS is integrated into the CWS. With static selection the concrete services are determined and integrated into the CWS at design time. With dynamic selection on the other hand, at design-time there is only a specification of the type of required service and the concrete WS is then integrated at run-time. The order in which WSs should be executed is called the control flow structure of the CWS. This control structure can be generated automatically in the selection step (Shin et al., 2009) or can be generated “by hand” by the designer/user by specifying an abstract representation of processes (e.g., a workflow, a Petri Net) (Huang et al., 2009).

After the selection step, the CWS should be executed over the distributed environment; however the interoperation of distributed software-systems is always affected by failures, dynamic changes, availability of resources, user errors, or interference of concurrently executing actions. In this context, Liu et al. (2010) consider that delivering reliable CWS over unreliable services is a challenging problem. A service that does not provide a proper transaction management support that prevents the system from entering undesired states might be as useless as a service not providing the desired functional results (Cardinale et al., 2010). If the composition is based on WSs by only considering functional requirements and QoS properties, then it is possible that during the execution, the whole system becomes inconsistent in presence of failures. Thus, considering transactional properties in WS Composition allows the system to guarantee reliable composition execution. Indeed, the execution of Transactional CWSs (TCWSs) will leave the system in a consistent state even in presence of failures. As explained by Badr et al. (2010), “today’s WS applications require advanced transactional models to guarantee integrity and continuity of business processes” (p.30).