TQoS: Transactional and QoS-Aware Selection Algorithm for Automatic Web Service Composition

Abstract

Web Services are the most famous implementation of service oriented architectures that has brought some challenging research issues. One of these is the composition, i.e. the capability to recursively construct a composite Web service as a workflow of other existing Web services, which are developed by different organizations and offer diverse functionalities (e.g. ticket purchase, payment), transactional properties (e.g. compensatable or not) and Quality of Service (QoS) values (e.g. execution price, success rate). The selection of a Web service, for each activity of the workflow, meeting the user's requirements, is still an important challenge. Indeed, the selection of one Web service among a set of them that fulfill some functionalities is a critical task, generally depending on a combined evaluation of QoS. However, the conventional QoS-aware composition approaches do not consider the transactional constraints during the composition process. This paper addresses the issue of selecting and composing Web services not only according to their functional requirements but also to their transactional properties and QoS characteristics. We propose a selection algorithm that satisfies user's preferences, expressed as weights over QoS criteria and as risk levels defining semantically the transactional requirements. Proofs and experimental results are presented.

Verifying Transactional Requirements of Web Service Compositions Using Temporal Logic Templates

“…For example, a component-level transactional requirement of the online payment composition could specify that Card Authorization cannot be retried without first reattempting PUT Card Data. Other common transactional requirements applied to components include compensatable, retriable, pivot, replaceable, or similar labels [3,[5][6][7]. However, using templates to specify these requirements, instead of applying labels to components, is a more expressive method, as it allows scope and other options to be adjusted, and enables complex requirements to be specified, such as satisfactory recovery conditions for specific failures.…”

“…Our composition-level templates enables more detailed composition-level requirements with the definition of critical preconditions, triggers, and reachability conditions for commit, abort, and other transactional states. Another approach proposed by El Haddad et al [7] uses risk levels provided by the user to specify whether the resulting composition should be compensatable, but reduces user control over the transactional behavior of their composition. In contrast, our approach allows compensatory activities to be explicitly specified and verified against business requirements.…”

“…For example, a service to retrieve customer details can be retried safely, but services to commit payment or place orders may require recovery or replacement upon failure. Business logic can also dictate requirements at the composition-level, such as compensatory processes to rollback all execution effects [7].…”

“…Previous approaches have proposed the detailed specification of failure models [5], composition risk levels [7], or the definition of vital components for the successful completion of Web services [3]. These approaches offer significant improvements towards the verification of transactional requirements, but tend to lead to state space explosion when verified [8] or restrict the transactional requirements that can be verified.…”

A Gravitational Search Algorithm for effective Web Service Selection for Composition with enhanced QoS in SOA

“…The Service Composition becomes a decision problem on which component services should be selected the user"s functional [21] and nonfunctional [22] requirements. Web services have important implication for business-to-business transaction [9].…”