Deriving Reliable Compositions using Cancelable Web Services

Transcription

1 ACM SIGSOFT Software Engineering Notes Page 1 January 2014 Volume 39 Number 1 Deriving Reliable Compositions using Cancelable Web Services Kanchana Rajaram SSN College of Engineering, Anna University Chennai, TamilNadu, India rkanch@ssn.edu.in Chitra Babu SSN College of Engineering, Anna University Chennai, TamilNadu, India chitra@ssn.edu.in ABSTRACT Reliability is one of the main challenges while composing web services. Due to the inherent heterogeneity of web services, it is important to predict the behaviour of the overall composite service. Existing works that deal with reliable web service composition consider only three basic transactional properties such as pivot, retriable, and compensatable. When a service fails, its results can be ignored if it is pivot; it can be retried until it succeeds if it is retriable; or the previously completed services must be rolled back if they are compensatable, in order to achieve reliable execution. In general, business applications involve long running services. Service execution must be interrupted to adapt to dynamically changing user preferences since execution of the service to completion with the older requirements is no longer meaningful. Hence, service composition requires additional transactional support beyond the three transactional properties. To address this need, we introduce cancelable services and investigate the transactional properties of composite services that involve cancelable component services. The valid compositions, which result in a reliable execution are identified and formally verified. 1. INTRODUCTION Service-Oriented Computing (SOC) [1] is an emerging paradigm that facilitates a new generation of software applications that can run over heterogeneous network infrastructures. In a dynamic environment, services need to be procured and bound on the fly so that, collectively, they can fulfil the intended business goals. Service Oriented Architecture (SOA) [2] provides an effective approach to build business applications wherein service interfaces are published and discovered on demand. Web Services (WS) are the predominant standards-based way of realizing SOA. Complex business processes involve collaboration of multiple business organizations. A service may be composed across multiple organizational boundaries as some of its functionalities may be outsourced. Transactions among these organizations represent exchanges of information that result in state changes. The internal behaviour of a service is the responsibility of the service provider alone, while the consumer of the service should be concerned with the behaviour of the composite service as it affects the consumer. The consumer has to ensure that the component services behave as described, otherwise the reliable execution of overall composition may not be achieved. Such reliability concerns are important so that the consumer can be confident about the services provided. Reliable execution of a composite service is possible only when the web services are selected by matching their transactional capabilities against the transactional requirements. Transactional support for business integration through composition of web services is a critical issue. Current web services specifications, for example BPEL [3], have been proposed to deal with this issue but on a strong assumption that each web service is compensatable and its effects can be undone for a recovery purpose. The mechanism of compensation was originally proposed by Gray et al. [4], and then became widely used in both advanced transaction models [5, 6] and transactional workflows [7] to maintain atomicity when the isolation property has to be relaxed. However, web services composition requires additional transactional support beyond the compensation-based solution. With long-running systems, exclusive locking of resources is impossible or impractical. In this context, investigating transactional properties of composed web services is becoming more important. Whenever user requirements or business policies change during the life span of a long running service, which can range from a day to month(s), the service execution must be interrupted to adapt to the new requirements or to incorporate the changed policies, since execution of the service to completion with the older requirements or policies is no longer meaningful. In the case of a cancelable long running service, the consumer has only the overhead associated with the compensation of the completed portion of the service. Alternatively, in the case of a non-cancelable long running service, the consumer needs to wait until completion, which may incur considerable overhead to compensate for the entire execution, since the successful execution will no longer be useful in the scenario of the changed requirements. Thus, selection of a non cancelable long running service involves a higher risk for the consumer. Since cancellation recovery achieves consistent termination when the execution of the service is interrupted in the middle, cancelable services are flexible to use. In addition, cancellation of a process supports cancellation recovery. When a long running composite service is cancelled, consistent termination is achieved by performing cancellation recovery, which compensates the completed component services of the composite service as well as all the services completed earlier than the cancelled service. This motivated us to consider the cancelable property for long running services. The behaviour of a composition depends on the behaviour of the individual components and the way in which they are composed. Therefore, the behaviour or transactional properties of a composite service whose component services may be cancelable have been derived from the behaviour of the component services. This research is useful in two ways: 1. To verify whether a specific composition results in reliable execution, when the transactional requirements of its component services are known. 2. To find out the transactional requirements of the individual component services of a composite service whose transactional property is known.

2 ACM SIGSOFT Software Engineering Notes Page 2 January 2014 Volume 39 Number 1 The rest of the paper is organized as follows: Existing work is reviewed in Section 2. The cancelable web services are defined in Section 3. In Section 4, the transactional properties of composite services comprising of cancelable component services are derived to identify valid compositions that result in a reliable execution. Section 5 concludes the paper. 2. EXISTING WORK Bhiri et al. [8] proposed a transactional approach for reliable web service compositions. This approach used the Acceptable Termination State (ATS) property as a correctness criterion to ensure failure atomicity of compositions as required by the designers. A set of transactional rules were defined to assist the designers to compose a valid composite web service with regard to the specified ATS. In this work, cancellation dependencies among services alone were considered. The web service selection mechanism proposed by Montagut et al. [9, 10] enables the automatic design of a composite service using the ATS model. The above approaches are based on the ATS model and the specification of ATS is a non-trivial and difficult task as it is manually specified by the user. Moreover, cancelable services are not considered by these approaches. Liu et al. [11] proposed a framework, FACTS, for fault-tolerant composition of transactional web services. FACTS considers cancelable and compensatable behaviours of transactional web services. However, cancelable web services considered by FACTS enable only internal cancellation of the service upon failure of another service. Neila et al. [12] proposed a transaction model for reliable service composition and execution, namely WS-SAGAS. Haddad et al. [13] proposed an algorithm namely TQoS for web service selection based on transactional as well as QoS properties. Li et al. [14] proposed an approach to derive transactional properties of composite services from the transactional properties of their components. However, none of the above works consider externally interruptible or cancelable long running services and their composition to guarantee consistent outcomes. 3. CANCELABLE PROPERTY OF WEB SER- VICES The behavioural properties of a given web service have an impact on other services in a composition. The failure of a component service may require retrying the same service or undoing the effects of a completed component service, so that the composed service terminates in a consistent state. The extended transaction model [15, 16] for Multi Database Systems (MDBS) proposed the CPR model comprising of three transactional properties namely compensatable (cp), pivot (p), and retriable (r). A Transactional Web Service (TWS) is a simple (non-composite) web service with a valid transactional property. A TWS is compensatable if, upon its successful completion, its effects can be semantically undone. A retriable TWS can be invoked a finite number of times in case of an internal failure. A TWS is a pivot service if it cannot be semantically undone on successful completion; if it fails, it leaves no trace. A pivot TWS is neither compensatable nor retriable.in addition to the properties supported by the CPR model, we introduce the cancelable (cc) property for web services to enable cancellation or interruption of execution. A TWS with cancelable property is defined as follows. Definition 1. Cancelable TWS: A TWS is cancelable if it can be cancelled by an external entity during its execution. Upon cancellation, it leaves no trace. A TWS may have more than one of these basic transactional properties (cp,p,r,cc). A successfully completed retriable service that is capable of semantically undoing its effects upon failure of another service is compensatable retriable with properties {cpr}. Alternatively, a completed retriable service, which is incapable of performing rollback, is pivot retriable with properties {pr}. A cancelable service is compensatable if it can be rolled back after its successful completion and has properties {cpcc}. Alternatively, a cancelable service, which cannot be compensated is pivot cancelable with properties {pcc}. A cancelable service, which is guaranteed to succeed by retrying a finite number of times, due to internal failures is cancelable retriable. Such a cancelable retriable service exhibits {cpccr} properties if it is capable of compensating upon failure of another service, otherwise it is pivot and has properties {pccr }. The pivot property {p} cannot combine with the compensatable property {cp} as a pivot service cannot be compensatable. Therefore, the set of possible transaction properties for a service is {p, pr, cp, pcc, cpr, pccr, cpcc, cpccr}. The transactional properties of a TWS describe its behavior. Hence, there can be 8 different types of TWS based on their behaviors. A Composite Web Service (CWS) is an orchestration of a multitude of component services. The transactional properties of the component services and the manner in which they are composed, viz. in parallel or in sequence, influence the transactional properties of a CWS. A CWS with valid transactional properties that lead to a consistent state is termed a Transactional Composite Web Service (TCWS) [13]. A TCWS is atomic (a) if it cannot be rolled back on successful completion. However, when one of its components fails or gets cancelled in the middle of its execution, all completed component services are compensated to reach a consistent state. Alternatively, a non-atomic (ā) CWS cannot be rolled back due to the failure of a subsequent service; its completed component services cannot be undone due to its failure or cancellation in the middle of its execution. A TCWS is compensatable and has the property {cp} if all its component services are compensatable. A compensatable TCWS enables backward recovery. Two more types of TCWS based on the proposed cancelable property are defined below. Definition 2. Cancelable TCWS: An atomic or a compensatable TCWS is cancelable if all its component services are cancelable and will have transactional properties {acc} or {cpcc} respectively. Cancellation recovery is enabled by a cancelable TCWS. Definition 3. Retriable TCWS: An atomic or a compensatable or cancelable TCWS is retriable if all its component services are retriable and will exhibit transactional properties {ar}, {cpr}, {accr}, or{cpccr} respectively. A retriable TCWS enables forward recovery. A TCWS cannot be a pivot service since it represents a composition of multiple component services. The set of possible transaction properties for a TCWS is {a, ar, cp, acc, cpr, accr, cpcc, cpccr}. 4. DERIVING A COMPOSITE SERVICE WITH A VALID TRANSACTIONAL PROPERTY The transactional property of a TCWS depends on the transaction properties of its component services. It is essential to derive the transactional property of a CWS based on the transactional properties of its component services in order to check whether the

3 ACM SIGSOFT Software Engineering Notes Page 3 January 2014 Volume 39 Number 1 composition is reliable or in other words whether the composition results in a TCWS. A set of theorems has been formulated in this section to derive the transactional property of a composite service, based on the transactional properties of its component services. For simplicity, a TCWS comprising of two component services S1 and S2, which may be simple or composite are considered. These component services can either be executed sequentially ( S1;S2) or concurrently ( S1 S2). The theorems governing the transaction property of a TCWS composed in sequence and in parallel are discussed below. THEOREM 1. ATCWScomposedinsequence,S1;S2 or in parallel S1 S2 is fully recoverable iff both S1 and S2 have {cpccr} property. PROOF. A fully recoverable TCWS is compensatable, retriable, and cancelable. A TCWS is compensatable only when all its component services are compensatable. All the component services of a cancelable TCWS must be cancelable (Definition 2). Similarly, a TCWS is retriable when all its component services are retriable (Definition 3). Hence, a TCWS has a combination of three properties {cpccr}, only when all the component services have each one of these properties. COROLLARY 1. When S1 has the property {cpccr}, ase- quentially composed TCWS S1;S2 will have the same property as S2. PROOF. Service S1 is compensatable as it has the property {cpccr}. When it is sequentially composed with S2 that is pivot or atomic, the resulting properties of TCWS include {a} as it cannot be semantically undone after its completion. When S1 is composed in sequence with S2 whose properties include {cp}, the properties of the resulting TCWS also includes {cp} as both S1 and S2 are compensatable. The properties of the TCWS S1;S2 include {r}, {cc}, or{ccr } if S2 includes {r} (Definition 3), {cc} (Definition 2), or {ccr } (Definition 2 and 3) respectively. 5. If S1 has a property from {p/a, pcc/acc}, S2 must have a property from {pr/ar, cpr}. PROOF. In case of failure or cancellation of S2, for the TCWS S1;S2 to become atomic, S1 must be compensatable as S1 must be semantically undone. When S1 has the property {cp}, S2 may either be a pivot or an atomic service resulting in an atomic sequential composition. Hence, the possible transactional properties that can be assigned to S2 are any of the properties from {p/a, pcc/acc, pr/ar, pccr/accr}. When S1 has the property {cpr}, S2 can be a pivot or atomic service but cannot include the retriable property as this would make S1;S2 retriable (Definition 3). When S1 has the property {cpcc}, S2 must be a pivot or an atomic service and cannot include the cancelable property as this would make S1;S2 cancelable (Definition 2). When S1 is fully recoverable, S2 must have the property {p/a} to make the sequential composition atomic (Corollary 1). If S2 is guaranteed to succeed, i.e. retriable and non-cancelable, S1 need not be compensatable since there is no need to compensate S1. Thus,S1 can be a pivot or an atomic non-retriable service and the resulting S1;S2 will also be an atomic service (Definition 3). THEOREM 2B. A TCWS composed in parallel S1 S2 is atomic iff the following condition holds. If either S1 or S2 has a property from {p/a, pcc/acc}, the other one should have the {cpr} property. PROOF. A parallel composition S1 S2 is atomic only when one of the component services, say S1 is a pivot/atomic or cancelable service and properties of the other service, say S2, includes {cp}. Moreover, S2 should not fail or get cancelled, since S1 is noncompensatable (Definitions 2 and 3). Hence, the only possible transaction property that can be assigned to S2 is {cpr}. COROLLARY 2. When S1 has the property {cpccr}, acon- currently composed TCWS S1 S2 will have the same property as S2 only when S2 is compensatable. PROOF. Service S1 is cancelable as it has property {cpccr}. When it isconcurrently composed withs2, which is non-compensatable, it will result in non-atomic composition as S2 cannot be undone upon cancellation of S1. When S1 is composed in parallel with S2 whose properties include {cp}, the properties of the resulting TCWS also include {cp} as both S1 and S2 are compensatable. The properties of the TCWS S1 S2 include {r}, {cc}, or{ccr } if S2 includes {r} (Definition 3), {cc} (Definition 2), or {ccr } (Definition 2 and 3). THEOREM 2A. A sequentially composed TCWS S1;S2 is atomic iff one of the following conditions hold. 1. If S1 has the property {cp}, S2 must have a property from {p/a, pr/ar, pcc/acc, pccr/accr}. 2. If S1 has the property {cpr}, S2 must have a property from {p/a, pcc/acc}. 3. If S1 has the property {cpcc}, S2 must have a property from {p/a, pr/ar}. 4. If S1 has the property {cpccr}, S2 must have the property {p/a}. THEOREM 3A: A sequentially composed TCWS S1;S2 is atomic retriable iff one of the following conditions hold. 1. If S1 has a property from {pr/ar, pccr/accr}, then S2 must have a property from {pr/ar, cpr}. 2. If S1 has the property {cpr}, then S2 must have a property from {pr/ar, pccr/accr}. 3. If S1 has the property {cpccr}, then S2 must have the property {pr/ar}. PROOF. Two retriable services S1 and S2 that are composed in sequence result in an atomic retriable TCWS (Definition 3). The possible properties that can be assigned to S1 are {pr/ar, cpr, pccr/accr, cpccr}. When S1 has the property {pr/ar} or {pccr/accr }, S2 must be non-cancelable to achieve an atomic retriable composition since S1 is not compensatable (Definition 3). When S1 has the property {cpr}, S2 cannot be compensatable as it results in a compensatable TCWS, but it can be cancelable (Definition 3). If S1 has the property {cpccr}, S2 must have the property {pr/ar} to make the sequential composition atomic retriable (Corollary 1). THEOREM 3B. A TCWS composed in parallel,s1 S2 is atomic retriable iff one of the following conditions hold.

4 ACM SIGSOFT Software Engineering Notes Page 4 January 2014 Volume 39 Number 1 1. Both S1 and S2 must have the {pr/ar} property. 2. If either S1 or S2 has the {cpr} property, the other one must have a property from {pr/ar, pccr/accr}. PROOF. Two retriable services, S1 and S2, that are composed in parallel result in atomic retriable TCWS (Definition 3). When one of the concurrently running services has the property {pr/ar}, it is non-compensatable and hence the other one must be noncancelable and retriable, i.e it may be assigned {pr/ar} or {cpr}, to achieve an atomic retriable composition (Definition 3). When a service composed in parallel has the property {cpr}, the other concurrent service cannot be compensatable as it results in a compensatable TCWS but it can be cancelable, i.e. it may be assigned {pr/ar} or {pccr/accr }. THEOREM 4. A sequentiallycomposed TCWSS1;S2 is atomic cancelable iff one of the following conditions hold. 1. If S1 has the property {cpcc} then S2 must have a property from {pcc/acc, pccr/accr}. 2. If S1 has the property {cpccr} then S2 must have the property {pcc/acc}. PROOF. Two services S1 and S2, that are composed in sequence result in an atomic cancelable TCWS if both S1 and S2 include the property {pcc/acc} (Definition 2). S1 must be cancelable and compensatable as S1 can be undone in case S2 fails or gets cancelled. Thus, the only possible properties for S1 are {cpcc} or {cpccr} (Definition 2). When S1 has the property {cpcc}, S2 must be cancelable (Definition 2) but should not be compensatable since it may result in a compensatable composition. If S1 has the property {cpccr}, S2 must have the property {pcc/acc} to make the sequential composition atomic cancelable (Corollary 1). THEOREM 5. ATCWScomposedinsequence,S1;S2 or in parallel, S1 S2 is compensatable iff one of the following conditions hold. 1. Both S1 and S2 must have the {cp} property. 2. If one of them has a property from {cpcc, cpccr}, the other onemusthavethe{cp} property. 3. If one of them has the property {cpr}, the other one must have a property from {cp, cpcc}. PROOF. In a compensatable sequential or parallel composition, all the component services must be compensatable. One of the component services, say S1, can be assigned any property from {cp, cpr, cpcc, cpccr}. When S1 has the property {cp}, S2 can be assigned any of the four properties from {cp, cpr, cpcc, cpccr} to result in compensatable S1;S2 or S1 S2. When S1 has the property {cpr}, S2 must be a compensatable service but cannot include the retriable property since it results in retriable S1;S2 or S1 S2 (Definition 3). When S1 has the property {cpcc}, S2 must be a compensatable service and cannot include the cancelable property as this will result in cancelable S1;S2 or S1 S2 (Definition 2). When S1 is fully recoverable, S2 must have the property {cp} to make the sequential or parallel composition compensatable (Corollaries 1 and 2). THEOREM 6. ATCWScomposedinsequenceS1;S2 or in parallel S1 S2 is compensatable retriable iff one of the following conditions hold. Both S1 and S2 must have the {cpr} property. If either S1 or S2 has the property {cpccr}, the other one must have {cpr}. PROOF. A sequentially or concurrently composed TCWS is compensatable and retriable only when its component services are both compensatable and retriable. Thus, the possible properties that can be assigned to one of the services are {cpr} or {cpccr}. When S1 has the property {cpr}, S2 should be compensatable and retriable to obtain TCWS S1;S2 or S1 S2 with the property {cpr}. Hence, the possible properties that can be assigned to S2 are {cpr} or {cpccr}. When S1 has the property {cpccr} (Definition 3), composing it either sequentially or concurrently with S2 having the property {cpr} will yield a TCWS with the property {cpr} (Corollaries 1 and 2). THEOREM 7. A sequentially composed TCWS S1;S2 is cancelable retriable iff the following condition holds. If S1 has the property {cpccr} then S2 must have the property {pccr/accr }. PROOF. A TCWS sequentially composed from S1 and S2 is atomic, cancelable, and retriable only when both S1 and S2 are cancelable (Definition 2) and retriable (Definition 3) and S1 is compensatable. The only possible transactional property for S1 is {cpccr} and S1;S2 would be cancelable retriable {ccr }, provided S2 is assigned the property {ccr } (Corollary 1). COROLLARY 3. ATCWScomposedinparallel,S1 S2 cannot be either cancelable or cancelable retriable. PROOF. An atomic cancelable or atomic cancelable retriable TCWS S1 S2 requires both the component services cancelable (Definition 2). However, two concurrent cancelable services will not result in an atomic composition. THEOREM 8. ATCWScomposedinsequenceS1;S2 or in parallel S1 S2 is compensatable cancelable iff one of the following conditions hold. 1. Both S1 and S2 must have {cpcc} property. 2. If either S1 or S2 has the property {cpccr}, the other one must have {cpcc}. PROOF. A sequentially or concurrently composed TCWS is compensatable and cancelable only when its component services are both compensatable and cancelable. Thus, the possible properties that can be assigned to one of the services are {cpcc} or {cpccr}. When S1 has the property {cpcc}, S2 should be compensatable and cancelable (Definition 2) to obtain TCWS S1;S2

5 ACM SIGSOFT Software Engineering Notes Page 5 January 2014 Volume 39 Number 1 or S1 S2 with the property {cpcc}. Thus, the possible properties that can be assigned to S2 are {cpcc} or {cpccr}. When S1 has the property {cpccr}, composing S2 with the property {cpcc} either sequentially or in parallel will yield a TCWS with the property {cpcc} (Corollaries 1 and 2). The transactional properties of a TCWS composed either in sequence or in parallel from two component services (single or composite) as derived using these theorems are summarized in Table 1. The invalid compositions that do not guarantee consistent outcome are marked in the table. The theorems can be clearly understood using the finite automaton depicted in Fig. 1 showing possible TCWSs. Each transactional property is modelled as a terminal state and state I is the initial one. When one of the terminal states is reached, a TCWS is obtained. A transition from state1 to state2 on input indicates that composition of a state1 service with another service having transactional property input results in a state2 TCWS. The input also indicates whether the composition is performed in sequence or in parallel. For example, let us consider a retriable composite service CS1 consisting of S1;S2 S3. This composition can be viewed as CS2 S3, where the composite service CS2 comprises of S1;S2. The state {ar} can be reached from the states {ar}, {cpr}, and{accr} on concurrent composition as shown in Fig. 1. One of these properties, say {cpr} is assigned to CS2. The transition from the state {cpr} to the state {ar} (required property of CS1 ) happens on input which is either {pr/ar} or {pccr/accr }. Hence,S3 is assigned one of these two properties, say {pccr }. Two transitions lead to {cpr} (the required property of CS2 ) on sequential composition from states {cpccr} and {cpr}. Among these properties, {cpccr} is randomly assigned for S1. The transition from state {cpccr} leading to state{cpr} happens on input {cpr}. Hence, S2 must be assigned transactional property {cpr}. 5. CONCLUSION A new transactional property of web services, cancelable that enables external interruption of a long running business process, has been introduced. The cancelable web services are helpful to adapt to the frequently changing requirements and policies during the execution of a long running composition. Transaction aware web service selection is a prerequisite to achieve reliable execution of composed services. While selecting services, it is necessary to choose services with appropriate behaviour so that their composition can be executed with guaranteed consistent termination. The contribution of this paper is that the valid compositions that result in a reliable execution have been derived and formally verified with a set of theorems. The compositions are derived from eight different types of component web services with varied behaviour including cancelable services. By knowing the valid compositions that guarantee consistent outcomes, the component services with appropriate transactional properties can be discovered and composed. In addition, given a set of a services with known transactional properties, it is possible to predict whether their composition would result in a reliable execution. 6. REFERENCES [1] M.P. Singh and M.N. Huhns. Service Oriented Computing: Semantics, Processes, Agents. John Wiley and Sons Ltd., [2] T. Erl. Service Oriented Architecture: Concepts, Technology, and Design. Pearson Education, Table 1: Transactional properties of TCWS S1 S2 S1;S2 S1 S2 p/a pccr/accr ā ā cpr a a pcc/acc pccr/accr ā ā cpr a a pr/ar ar ar pr/ar pccr/accr ā ā cpr ar ar pr/ar ar ā pccr/accr pccr/accr ā ā cpr ar ar p/a a ā pcc/acc a ā cp pccr/accr a ā cpcc cp cp cpr cp cp cpccr cp cp p/a a ā pcc/acc acc ā cpcc pccr/accr acc ā cpcc cpcc cpcc cpr cp cp cpccr cpcc cpcc p/a a a pcc/acc a a pr/ar ar ar cpr pccr/accr ar ar cpcc cp cp cpr cpr cpr cpccr cpr cpr p/a a ā pcc/acc acc ā pr/ar ar ā cpccr pccr/accr accr ā cpcc cpcc cpcc cpr cpr cpr cpccr cpccr cpccr

6 ACM SIGSOFT Software Engineering Notes Page 6 January 2014 Volume 39 Number 1 Figure 1: Finite Automaton for Deriving Transactional Properties of CWS [3] D. Jordan and J. Evdemon. Web Services Business Process Execution Language Version 2.0, OASIS Standard [4] J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann Publishers, San Mateo, [5] A.K. Elmagarmid (Ed.). Database Transaction Models for Advanced Applications, pages , [6] H. Garcia-Molina and K. Salem. Sagas. ACM SIGMOD Int. Conf. on Management of data, pages , [7] A.P. Sheth and M. Rusinkiewicz. On Transactional Workflows. IEEE Data Engineering Bulletin, 16(2):37 40, [8] S. Bhiri, O. Perrin, and C. Godart. Ensuring Required Failure Atomicity of Composite Web Services. Proc. of 14th Int. conference on World Wide Web (WWW2005), pages , [9] F. Montagut and R. Molva. Augmenting web services composition with transactional requirements. IEEE Int. conference on Web Services (ICWS), pages 91 98, [10] F. Montagut, R. Molva, and S. T. Golega. Automating the Composition of Transactional Web Services. Int. Journal of Web Service Research, 5(1):24 41, [11] A. Liu, Q. Li, L. Huang, and M. Xiao. FACTS: A Framework for Fault-Tolerant Composition of Transactional Web Services. IEEE Transactions On Services Computing, 3(1):46 59, [12] B. L. Neila, K. Takashi, and Y. Haruo. WS-SAGAS: Transaction Model for Reliable Web-Services Composition Specification and Execution. DBSJ Letters, 2(2):1 4, [13] J.E. Haddad, M. Manouvrier, and M. Rukoz. TQoS: Transactional and QoS-Aware Selection Algorithm for Automatic Web Service Composition. IEEE Transactions on Services Computing, 3(1):73 85, [14] L. Li, C. Liu, and J. Wang. Deriving Transactional Properties of Composite Web Services. IEEE International Conference on Web Services (ICWS), pages , [15] S. Mehrotra, R. Rastogi, H.F. Korth, and A. Silberschatz. A Transaction Model for Multidatabase Systems. 12th Int. conference on distributed computing systems (ICDCS92), pages 56 63, [16] A. Zhang, M. Nodine, B. Bhargava, and O. Bukhres. Ensuring Relaxed Atomicity for Flexible Transactions in Multidatabase Systems. ACM SIGMOD Record, 23:67 78, May ********************