Deriving Reliable Compositions using Cancelable Web Services

18 downloads 0 Views 707KB Size Report
SSN College of Engineering, Anna University. Chennai, TamilNadu, India [email protected]. Chitra Babu. SSN College of Engineering, Anna University.
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

[email protected]

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

DOI: 10.1145/2557833.2557851

Chitra Babu

SSN College of Engineering, Anna University Chennai, TamilNadu, India

[email protected]

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.

http://doi.acm.org/10.1145/2557833.2557851

ACM SIGSOFT Software Engineering Notes

Page 2

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 SERVICES

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.

DOI: 10.1145/2557833.2557851

January 2014 Volume 39 Number 1

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 (¯ a) 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

http://doi.acm.org/10.1145/2557833.2557851

ACM SIGSOFT Software Engineering Notes

Page 3

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 ( S1S2). The theorems governing the transaction property of a TCWS composed in sequence and in parallel are discussed below. THEOREM 1. A TCWS composed in sequence, S1;S2 or in parallel S1S2 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 }, a sequentially 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.

January 2014 Volume 39 Number 1 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 S1S2 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 S1S2 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 }.

THEOREM 3A: A sequentially composed TCWS S1;S2 is atomic COROLLARY 2. When S1 has the property {cpccr }, a conretriable iff one of the following conditions hold. currently composed TCWS S1S2 will have the same property as S2 only when S2 is compensatable. PROOF. Service S1 is cancelable as it has property {cpccr }. 1. If S1 has a property from {pr/ar, pccr/accr }, then S2 must When it is concurrently composed with S2, which is non-compensatable, have a property from {pr/ar, cpr }. it will result in non-atomic composition as S2 cannot be undone 2. If S1 has the property {cpr }, then S2 must have a property upon cancellation of S1. When S1 is composed in parallel with from {pr/ar, pccr/accr }. S2 whose properties include {cp}, the properties of the resulting TCWS also include {cp} as both S1 and S2 are compensatable. 3. If S1 has the property {cpccr }, then S2 must have the propThe properties of the TCWS S1S2 include {r }, {cc}, or {ccr } erty {pr/ar }. if S2 includes {r } (Definition 3), {cc} (Definition 2), or {ccr } (Definition 2 and 3). PROOF. Two retriable services S1 and S2 that are composed in sequence result in an atomic retriable TCWS (Definition 3). THEOREM 2A. A sequentially composed TCWS S1;S2 is atomic The possible properties that can be assigned to S1 are {pr/ar, cpr, pccr/accr, cpccr }. When S1 has the property {pr/ar } or iff one of the following conditions hold. {pccr/accr }, S2 must be non-cancelable to achieve an atomic retriable composition since S1 is not compensatable (Definition 3). 1. If S1 has the property {cp}, S2 must have a property from When S1 has the property {cpr }, S2 cannot be compensatable {p/a, pr/ar, pcc/acc, pccr/accr }. as it results in a compensatable TCWS, but it can be cancelable 2. If S1 has the property {cpr }, S2 must have a property from (Definition 3). If S1 has the property {cpccr }, S2 must have the {p/a, pcc/acc}. property {pr/ar } to make the sequential composition atomic retriable (Corollary 1). 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}.

DOI: 10.1145/2557833.2557851

THEOREM 3B. A TCWS composed in parallel, S1S2 is atomic retriable iff one of the following conditions hold.

http://doi.acm.org/10.1145/2557833.2557851

ACM SIGSOFT Software Engineering Notes

Page 4

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 sequentially composed TCWS S1;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. A TCWS composed in sequence, S1;S2 or in parallel, S1S2 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 one must have the {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 S1S2. 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 S1S2 (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 S1S2 (Definition 2). When S1 is fully recoverable, S2 must have the

DOI: 10.1145/2557833.2557851

January 2014 Volume 39 Number 1

property {cp} to make the sequential or parallel composition compensatable (Corollaries 1 and 2). THEOREM 6. A TCWS composed in sequence S1;S2 or in parallel S1S2 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 S1S2 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. A TCWS composed in parallel, S1S2 cannot be either cancelable or cancelable retriable. PROOF. An atomic cancelable or atomic cancelable retriable TCWS S1S2 requires both the component services cancelable (Definition 2). However, two concurrent cancelable services will not result in an atomic composition. THEOREM 8. A TCWS composed in sequence S1;S2 or in parallel S1S2 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

http://doi.acm.org/10.1145/2557833.2557851

ACM SIGSOFT Software Engineering Notes

Page 5

or S1S2 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;S2S3. This composition can be viewed as CS2S3, 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.

January 2014 Volume 39 Number 1 Table 1: Transactional properties of TCWS S1

p/a

pcc/acc

pr/ar

pccr/accr

cp

cpcc

cpr

REFERENCES

[1] M.P. Singh and M.N. Huhns. Service Oriented Computing: Semantics, Processes, Agents. John Wiley and Sons Ltd., 2005. [2] T. Erl. Service Oriented Architecture: Concepts, Technology, and Design. Pearson Education, 2005.

DOI: 10.1145/2557833.2557851

cpccr

S2 p/a pcc/acc pr/ar pccr/accr cp cpcc cpr cpccr p/a pcc/acc pr/ar pccr/accr cp cpcc cpr cpccr p/a pcc/acc pr/ar pccr/accr cp cpcc cpr cpccr p/a pcc/acc pr/ar pccr/accr cp cpcc cpr cpccr p/a pcc/acc pr/ar pccr/accr cp cpcc cpr cpccr p/a pcc/acc pr/ar pccr/accr cp cpcc cpr cpccr p/a pcc/acc pr/ar pccr/accr cp cpcc cpr cpccr p/a pcc/acc pr/ar pccr/accr cp cpcc cpr cpccr

S1;S2 a ¯ × a ¯ × a a ¯ × a ¯ × a ¯ × a a ¯ × a ¯ × a ¯ × a a ¯ × a ¯ × a ¯ × a a ¯ × a ¯ × a ¯ × ar a ¯ × a ¯ × a ¯ × ar a ¯ × a ¯ × a ¯ × ar a ¯ × a ¯ × a ¯ × ar a ¯ × a a a a cp cp cp cp a acc a acc cp cpcc cp cpcc a a ar ar cp cp cpr cpr a acc ar accr cp cpcc cpr cpccr

S1S2 a ¯ × a ¯ × a ¯ × a ¯ × a ¯ × a ¯ × a a ¯ × a ¯ × a ¯ × a ¯ × a ¯ × a ¯ × a ¯ × a a ¯ × a ¯ × a ¯ × ar a ¯ × a ¯ × a ¯ × ar a ¯ × a ¯ × a ¯ × a ¯ × a ¯ × a ¯ × a ¯ × ar a ¯ × a ¯ × a ¯ × a ¯ × a ¯ × cp cp cp cp a ¯ × a ¯ × a ¯ × a ¯ × cp cpcc cp cpcc a a ar ar cp cp cpr cpr a ¯ × a ¯ × a ¯ × a ¯ × cp cpcc cpr cpccr

http://doi.acm.org/10.1145/2557833.2557851

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. http://docs.oasis-open.org/wsbpel/2.0/serviceref/, 2009. [4] J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann Publishers, San Mateo, 1993. [5] A.K. Elmagarmid (Ed.). Database Transaction Models for Advanced Applications, pages 349–397, 1992. [6] H. Garcia-Molina and K. Salem. Sagas. ACM SIGMOD Int. Conf. on Management of data, pages 249–259, 1987. [7] A.P. Sheth and M. Rusinkiewicz. On Transactional Workflows. IEEE Data Engineering Bulletin, 16(2):37–40, 1993. [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 138–147, 2005. [9] F. Montagut and R. Molva. Augmenting web services composition with transactional requirements. IEEE Int. conference on Web Services (ICWS), pages 91–98, 2006. [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, 2008. [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,

DOI: 10.1145/2557833.2557851

3(1):46–59, 2010. [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, 2001. [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, 2010. [14] L. Li, C. Liu, and J. Wang. Deriving Transactional Properties of Composite Web Services. IEEE International Conference on Web Services (ICWS), pages 631–638, 2007. [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, 1992. [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 1994. ********************

http://doi.acm.org/10.1145/2557833.2557851