0 évaluation0% ont trouvé ce document utile (0 vote)
22 vues11 pages
Web Services provide a standard way to meet these objectives, as they use common communication pattern like XML and HTTP. On the other hand, it also brings some issues about reliability, availability and other non functional problems. This paper presents an effective way to certificate the correct use of those patterns by applying perturbation and mutation testing techniques.
Web Services provide a standard way to meet these objectives, as they use common communication pattern like XML and HTTP. On the other hand, it also brings some issues about reliability, availability and other non functional problems. This paper presents an effective way to certificate the correct use of those patterns by applying perturbation and mutation testing techniques.
Droits d'auteur :
Attribution Non-Commercial (BY-NC)
Formats disponibles
Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
Web Services provide a standard way to meet these objectives, as they use common communication pattern like XML and HTTP. On the other hand, it also brings some issues about reliability, availability and other non functional problems. This paper presents an effective way to certificate the correct use of those patterns by applying perturbation and mutation testing techniques.
Droits d'auteur :
Attribution Non-Commercial (BY-NC)
Formats disponibles
Téléchargez comme PDF, TXT ou lisez en ligne sur Scribd
Testing Web Services through Transactional Patterns
Paulo Roberto Nunes
Universidade de So Paulo So Paulo, Brazil prnunes@ime.usp.br Ana Cristina Vieira de Melo Universidade de So Paulo So Paulo, Brazil acvm@ime.usp.br ABSTRACT Software technology has become essential since it is available in most places. Powered by Internet, nowadays, information quickly ows throw systems. Web services provide a stan- dard way to meet these objectives, as they use common com- munication pattern like XML and HTTP. The use of Web services brings many benets. On the other hand, it also brings some issues about reliability, availability and other non functional problems. Transactional patterns are an al- ternative to outline such problems. This paper presents an eective way to certicate the correct use of those patterns by applying perturbation and mutation testing techniques. As a result, it is shown which of techniques are applicable. 1. INTRODUCTION The integration between applications is increasingly present. With the need for information and as new de- mands arrive, service-oriented architectures gain evidence, with Web Services, software designed to provide machine to machine interoperability over a network [1]. Web Services are means of requesting information through a network and whose response is requested and informed in XML (extended markup language) [1]. Today, they represent a technology- based components and widely used to implement solutions and systems [2]. The concept of making available dierent services allows a scenario to be created. In such scenario, Internet plays a data repository, where information and services can be used anywhere in the world [3]. This environment has improved interoperability, greater dynamism and exibility, especially if compared to other platforms, such as Common Object Re- quest Broker Architecture (Corba) [4]. However, it signi- cantly aects non-functional attributes, eg reliability, avail- ability, security, and others [5, 6]. In some scenarios with the highest criticality, condence in a Web Service becomes an important factor [6]. In order to solve this limitation, academic community and even industry have spent a great eort to develop models Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for prot or commercial advantage and that copies bear this notice and the full citation on the rst page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specic permission and/or a fee. SAC12 March 25-29, 2012, Riva del Garda, Italy. Copyright 2011 ACM 978-1-4503-0857-1/12/03 ...$10.00. focused on Quality of Service, specically Web Services[7], and study alternatives to the problem, aiming reliability of the services oered by them [8]. The approach diers from the denition of standards towards development of tests to ensure adequate coverage. Many standards have been created with the objective of establishing methods for Web Services compositions and their behavior. The execution is correct if it reaches the goal, or fail if the requirements are not met. When execu- tions occur according to a predetermined pattern, behavior of composite services is more predictable [9]. Another way to get a reliable service is by performing tests to ensure the proper functioning of the whole service. When a battery of tests is performed, the fundamental objective is to evaluate if the service responds according to requirements, whether functional or non-functional. However testing is an expensive and dicult task, more specically to Web Services, due to their peculiarities [10]. Testing techniques applied to other paradigms such as object orientation and procedural, are also generally applied to Web Services. But, there are several specic characteristics that allow a better exploitation of these techniques [11]. Among the current challenges is the task of making more ecient the Web Services test activity, with the primary purpose of increasing reliability. There is a lot of tool to support non-functional testing [10, 11]. The objective of this study is to identify test requirements to validate the suitability of the service and the applica- tion according to a set of standards to ensure greater re- liability of the system. In Section 2 are presented related works. Section 3 highlights Transactional Web Services con- cepts. Then, Section 4 presents an overview of Web Services testing. Section 5 shows aspects about how Transactional Web Services are compound. Section 6 discusses criteria for Transactional Web Services Composition, illustrated by Case studies in Section 7. Finally, Section 8 presents the nal remarks. 2. RELATED WORK Researches have addressed issues about availability and reliability of Web Services[12]. Among the initiatives, we can mention those that seek to ensure quality by setting standards. On the other hand, there are other initiatives that verify if the quality exists or not, through tests [13]. 2.1 Pattern denition The standardization of communication between services contributes to interoperability, facilitating the execution of their duties. Interoperability is the ability of multiple com- ponents work together, exchanging information in a well- dened process [14]. In his research, Saha describes a technique to ensure greater reliability of sent data [15], based on fault-tolerant algorithms. Another Sahas work focuses mainly at service availability [16], through developing a reliable and exible model. Erradi et al. suggest the creation of a framework, MASC (Manageable and Adaptive Service Composition), mainly based on policies that govern failures management [17]. This is a pattern intercepts operations normally performed, adding an extra layer of political architecture, allowing to detect and treat a lot of failure types. Bhiri et al. present the creation of a standard that consid- ers the systems ow, keeping guarantees oered by trans- actional methods [9]. Some factors may aect dependen- cies between the requesting and requested services: De- pendence and Activation Status Activation; Addiction Al- ternative and Alternative condition; Dependence Condition Abortion and Miscarriage, and Condition Dependence Com- pensation and Compensation; Dependence Cancellation and cancellation policy. Based on these items, denitions of con- trol ow and ows of transactions were identied in order to dene their own standards for such transactions. Wen et al. also focus on the analysis of transactions ap- plied to Web Services, but using BPEL (Business Process Execution Language). It was developed a tool for validate transactional properties in compositions of Web Services[18]. Out of the studied solutions, those involving specications aimed at modeling transactions. Other solutions end up helping more developers in the task of improving reliability of web services facing problems such as unavailability, data loss and security. 2.2 Web Services testing Testing represents a key role in assessing systems. De- spite of all studies have been conducted in research of Web Services quality, it is necessary highlight the fact that some requirements have been implemented [19]. Li et al. present a method of generating test cases from the combination of features of WSDL and knowledge of the user [20]. They present a tool called Gen-WSTD implementing the dened method. Their tool allows users to customize data types and select a specic rule for each type. Out and Xu propose an approach in which SOAP mes- sages are captured during the communication between ser- vices and, based on them, test cases are generated by in- serting the message failures [21]. These test cases evaluate the behavior of the service in the presence of invalid mes- sages. Also evaluating the behavior of an invalid data ser- vices, Laranjeiro et al. present a tool called wsrbench 1 to assess the robustness of a given Web Service [22]. In the research of Paradkar et al., is evaluated a test case generation model [23]. The proposal presents a method for generating test data based on fault models, in order to use them to evaluate semantic web service, which are dened by inputs, outputs, preconditions and eects - IOPE (Input, Output, Preconditions and Eects). Wombacher et al. dene a process for review BPEL speci- cation and transformation in DFA [24]. Although the main objective of the work is the facilitation of service discovery 1 Available at http://wsrbench.dei.uc.pt in catalogs, it is possible to evaluate scenarios for testing, considering variables such as transactional and conditions. Sowmya and Ramsokul present a framework that veries the appropriateness of implementing protocols Web Service with the specications [25]. With the use of an ASEHA (Asynchronous Extended Hierarchical Automata) used to model functional aspects of the protocol, it is possible to evaluate dierent transactional characteristics, for example, atomicity. The Framework captures SOAP messages sent by the service and confronts the implementation to its speci- cation. The need for tests is evident. Web Services present new challenges and require further study, particularly on issues related to the application of standards. This paper focuses interoperability testing. 3. TRANSACTIONAL WEB SERVICES 3.1 Web Services Web applications gained prominence in the world of infor- mation technology and became a major mean of communica- tion between suppliers and their customers. As technology advances, applications become more complex and dynamic, making e-business enter a new system development era[26]. In a service-oriented architecture (SOA) there is a Ser- vice Provider, available through a communication proto- col, Service Requisitor (also called a client or service con- sumer) that uses the service and a Services Repository. The repository contains the list of available services as well as descriptions of their use, often fed by the various existing providers. The provider creates a WSDL (Web Services Description Language) 2 from a specic service, detailing the interface: operations performed by him; the inputs and outputs and; its restrictions. Once created, the description is available in the repository so that customers can use the service. There are several of these repositories available on the Inter- net, whose main purpose is to provide necessary information about the various public services such as site access. Many of these repositories provide some search criteria (for exam- ple, by category), to facilitate access by customers. For eective communication client-server, each client ap- plication implements a boundary, which is responsible for exchange of messages between client application and avail- able service, following the specications of how to send and receive information (for instance, using SOAP - Simple Ob- ject Access Protocol 3 ). For publication services, dynamic queries and invocations through the Web [27], there is a UDDI (Universal Description, Discovery and Integration) standard proposed by OASIS 4 . 3.2 Transactional Web Services According to Bhiri et al. [9], a Transactional Web Service is a Web Service with special attributes, such as [28, 18]: retriable: a service is retriable if within a nite tries it will be concluded once; compensatable: a service is compensatable if there are compensation policies to undo what it has done; 2 W3C Web Services Description Language (WSDL) 1.1 3 W3C SOAP Version 1.2 4 Available at http://uddi.org/pubs/uddi_v3.htm pivot: a service is a pivot if, once completed, it cannot be undone. Transactional Web Services can hold not just one of all above properties, but a combined set of them, as long as they keep a consistent combination. For instance, consis- tent Transactional Web Services can be either retriable or compensatable or pivot or both retriable and compen- satable or both retriable and pivot. In a system, a transaction can be formed by one or more transition states. In a composition of Transactional Web Services, a transaction allows combine Web Service transi- tions, in order to keep whole system consistency. In other words, the set of state and transitions depends on transac- tional properties. Each service must have the states Initial, aborted, active, canceled, failed, completed and the tran- sitions abort(), activate(), cancel(), fail(), complete() [29]. Retriable and Compensatable Web Services has retry() and compensate() transitions in addition, respectively. A sub- set of such transitions describes Transactional Web Service inner behavior (complete(), fail(), retry()), being named as Internal Transitions. All other transitions trigger other Web Services, thus, they are named External Transitions. Definition 1. Transactional Web Services transi- tions and States [29] Possible Transactional Web Service states, their Internal and External transitions are dened as following: Ti = |complete(), fail(), retry() a set of Web Service Internal Transitions; Te = |abort(), activate(), cancel(), compensate() a set of Web Service External Transitions; and Sts = |Initial, aborted, active, cancelled, failed, completed, compensated a set of Web Serviceinternal states; Definition 2. Transactional Web Service A Trans- actional Web Service TWS(s i ) is dened by the tuple |Initial(s i ), Ti(s i ), Te(s i ), Sts(s i ), Bi, Be where, Initial(s i ) represents the initial state of s i ; Ti(s i ) Ti represents a set of s i s internal transi- tions; Te(s i ) Te represents a set of s i s external transi- tions, started from s i ; Te 1 (s i ) Te represents a set of s i s external transi- tions, nishing at s i ; Sts(s i ) Sts represents a set of s i s internal states; Bi(s i ) : Sts(s i ) Ti(s i ) Sts(s i ) represents the re- lation between internal transitions and s i s internal states; Be(s i ) : Sts(s i ) Te(s i ) Sts(s j ) represents the rela- tion between external transitions started in s i and s j s internal states [ j ,= i; Be 1 (s i ) : Sts(s j ) Te 1 (s i ) Sts(s i ) represents the relation between external transitions ending in s i and s j [ j ,= i. TWS denotes a innite set of all Transactional Web Ser- vices TWS(s i ). Both type of transitions, internals and externals, allow Web Services communication over messages exchange. Definition 3. Given a message m ij M sent from a service s i to a service s j , K ij = |c 1 , c 2 , ..., c n is the set of all elds in m ij . M represents a innite set of all messages m. Proposition 1. Let s i and s j Transactional Web Ser- vices. If te is a transition from s i to s j (whose sent message is m ij ), then te Te(s i ) te Te 1 (s j ) (s i , te, s j ) Be(s i ) Transactional Web Service behavior is given by all pos- sible Transactional Web Service transition executions, in- ternal and external. Its remarkable that inner and outer transactional behavior can be set apart. In the same way, it can be observed that all transitions and available states for each Transactional Web Service depend on their trans- actional properties. For instance, a Transactional Web Ser- vice with pivot property nor cannot have a compensate() method, neither a compensated state. 4. TESTING WEB SERVICES Current web service testing approaches are not sucient as they are more heterogeneous than components and ap- plications web. Web Services may also be written in sev- eral languages and they can be used for various operating systems and run in containers of dierent application [30]. For web services, there is minimal control between provider, consumer, and integrator, which directly aect the cost of testing and QoS (Quality of Service) [31]. Thus, it is necessary to perform the test suite coverage in key points, specically to Web Services, functional and non- functional. Among the functional, if the service provides appropriate responses in accordance with the specications provided. But among the non-functional, should be evalu- ated: the ability to respond eciently to a given number of requests (performance), aspects of authorization, encryption and protection against attacks (security); and adherence to a particular set of pre established (interoperability). This work approaches evaluation of interoperability testing. After extensive research on the issues discussed today, there is few references in the literature on specic Web Ser- vices testing criteria [32, 14]. Some initiatives analyzed cur- rent situation in order to assess Web Services issues [33, 14]. Since it is a distributed environment, some researchers argue tests should be dierent from conventional [34, 35]. Analyzing a web service and comparing it with current paradigms, especially object-oriented, we can classify testing criteria into two types: criteria for functional testing, and non-functional [14]. Many of the criteria applied to this paradigm does not apply to service [12]. Considering aspects enable one to see service as a func- tion available for remote use, you can use criteria that guide unit tests assessing their functional characteristics. Depend- ing on the implementation approach, the test criteria can be varied. Blanco et al. [36] suggest adopting criteria for cov- erage of state transitions, due to the model adopted. For testing non-functional, many quality-related criteria can be dened [37]. Aspects such as availability, reliability, secu- rity and robustness, can be specied by SLA (Service Level Agreement) and security requirements. To make sure that the process works as expected, a set of tests is executed to identify gaps and thereby improve the nal product. In a process composed of services, the ideal is that all of them have quality and their integration does not compromise the composition. There are perturbation techniques to test reliability of Transactional Web Services compositions, and evaluate them in isolation. Through these techniques, it is able to explore test conditions and thus enhance the detection of system problems. The set of techniques used by Melo and Silveira [38] allows the automatic creation of test cases, using as the basis submitted messages from one service to another. Definition 4. Let PertDados be a set of all data pertur- bation techniques, PertCom be a set of all communication perturbation, and MutDados be set of all data mutation, used by Melo and Silveira [38]. Thus: PertDados = |string, boolean, numeric, data, bi- nary, enumeration, fractionDigits, length, maxExclu- sive, maxInclusive, maxLength, minExclusive, minIn- clusive, minLength, pattern, totalDigits, whiteSpace PertCom = |minOcurrs, maxOcurres, choice, any element MutDados = |divide, Multiply, Negative, Absolute, Exchange, Unauthorized, Null, Incomplete, Inversion, ValueInversion, Mod Len, Space TEC = PertDados PertCom MutDados Definition 5. Let s i be a initial state, s j nal state, m ij a message sent from s i to s j , cT (m ij ) is a set of all test case generated based on m ij . Thus: cT (m ij ) = TT(PertDados, m ij ) Tc(PertCom, m ij ) /T(MutDados, m ij ) where: 1. TT(pd, m ij ) is a set of test cases generated according to data perturbation and pd PertDados; 2. Tc(pc, m ij ) is a set of test cases generated according to communication perturbation and pc PertCom; 3. /T(md, m ij )is a set of test cases generated according to data mutation and md MutDados; m ij is used as a seed to originate test cases TT(PertDados, m ij ), Tc(PertCom, m ij ) e /T(MutDados, m ij ). The validation of Transac- tional Web Services belonging to the system through the validation can occur in isolation, as well as verication of the preconditions of each, as well as validation of the result. Considering the ideal scenario, the execution with valid data, is set for all services following a certain order, exchanging messages with each other and returning the system response in the nal state. However, in normal use, there may be violation of preconditions or even the sequence of use. In the example of travel system, it could be a problem in communication between the airline reservation systems, hotel reservation and payment. To avoid problems with the payment system, it needs to make appropriate treatments, forecasting situations where the data is lost, is corrupted, or simply ignored. Therefore, it is necessary to validate the entire process, testing such situations, simulating scenarios in which losses occur (or accidental changes) of data. You must also assess whether the mounted ow and in which order the services are vulnerable to problems in processing. For this validation can be performed, you can create some test scenarios that allow exploring situations: 1. Transactional Web Services isolated validation: perturbation and mutation techniques are used for Transactional Web Services validation; 2. Precondition and sequence validation: process sequence is kept, applying perturbation in messages (respecting preconditions); 3. sequence violation: changing the process sequence and; 4. preconditions violation: process sequence is kept, applying perturbation in messages, but violating pre- conditions. In the following sections possible situations are presented in the composition of Transactional Web Services, highlight- ing what alternatives can be identied to validate them sep- arately and to validate that systems formed through a com- bination of them meet the expected properties. 4.1 Isolated testing systematic Web application, as isolated Web Services, needs a re- markable reliability. The GenAutoWS tool uses perturba- tion testing techniques and generates a huge test case set. Melo and Silveira [38] show two ways to apply perturbation on communication: RPC and Document, used according to the established pattern. RPC way is designed for test the services use of data, meanwhile, Document way allows tests related to relationship and restriction. Web Services have specic characteristics. As seen before, GenAutoWS tool can automatically generate a test set to Web Services. To generate tests that can validate and pro- cess system transactions, the message exchanged between services can be used as seed generating. From unitys point of view, using perturbation techniques (based on perturbation data types and restrictions), defects are sought by performing tests of equivalence classes. The data perturbation modies values through the use of infor- mation on their type. These types are determined by the XML Schema of the message itself. With the technique of boundary value analysis, test cases can be prepared accord- ing to the primitive type of entry. Similarly, for disturbances in communication, taking the restrictions based on XML re- lationships, it is possible validate Transactional Web Ser- vicesingly. The mutation, another useful technique for vali- dating isolated Transactional Web Services, is performed by operators of mutation. These operators are applied in the original message, increasing the chance of an error is iden- tied, if any. As for the other techniques, the mutation is applied to individual tests. In summary, the test set formed by applying the three kinds of techniques, perturbation data, communication and changing data is the following: cT (m ij ) = TT(pd, m ij )Tc(pc, m ij )/T(md, m ij ). Despite of having adequate coverage when they test them- selves Web Services as units, in a composition of them (and when it involves transactions), the set of tests is not su- cient. 5. COMPOSING TRANSACTIONAL WEB SERVICES Web application can represent a composition of existing Web Services. Such compositions are developed following transactional patterns. When a system is built based on two or more Web Services, it can be seen as a process, made of a set of Web Services, being one initial, followed by its transitions. There are precondition that must be true in order to execute each Web Service. Transaction ow of the Transactional Web Service Composition consists of a set of external transitions between services. Each transition has its own set of preconditions that must be met for transitions from one state to another, or simply to invoke a particular service. Consequently, there is a set of preconditions that need to be respected to run properly. All Web Service preconditions are a set of expected situ- ations, without which there is no guarantee that the service will operate as specied. Definition 6. Service preconditions Let Prop be a property, Prop is a function dening for each transition of an external Transactional Web Service to a property that it must ensure in order to be activated. Prec : Te TWS Prop. s i , te [ s i TWS te Te 1 (s i ) Prec(te, s i ) = Prop. PROP denotes the innite set of all the properties that Transactional Web Servicesshould ensure in order to be ac- tivated. Definition 7. Transactional Composite Web Ser- vices [29] A Transactional Composite Web Service, tcs ( Transactional Composite Web Service), is dened by tcs = (tws TWS, Prec), where: tws denotes the set of Transactional Web Services compose the service (tws = |s 1 , ..., s n , s i is a Trans- actional Web Service component of tcs) TCS denotes a set of all Transactional Composite Web Services. As a tcs can be composed by many Transactional Web Services, their states are represented by: s.e), where s tws and e Sts(s). Similarly, the transitions are also represented with the identication of services that generate: s.t()), where s tws and t Te(s). Preconditions expresses, in form of dependency, the rela- tionship between services, showing how they can be com- bined. Certain services can inuence the behavior of others. There are dependencies for the implementation of essential services[9]. 6. VALIDATING COMPOSITE TRANSAC- TIONAL WEB SERVICES 6.1 Transaction Patterns One requirement for having a reliable composition is the non-existence of inconsistencies in control ow. To ensure consistency between the transition and several calls between services, Bhiri em et al. suggest using a context-free gram- mar,for the propose of evaluate the quality of the specica- tion of the connections[9]. As a result, transactional ow has some attributes: each service is either retriable or pivot; each compensate destine service must be compensable; each compensate origin service must be retriable. It also is valid for cancel or alternative services. For the composition may be formed, it is necessary for a given Transactional Web Service follow these characteristics. Moreover, it is essential that appropriate transitions are car- ried out in adequate conditions for their execution and that the ow of control of their composition is consistent and standardized. 6.1.1 Dependencies and Transition Conditions As can be seen previously, a given state can contain pre- conditions, which depend on the transitions to be performed. Thus, for each transition occurs according to established standards, service preconditions must be respected. In the context of preconditions, execution dependencies end up ref- erencing the relationship between services. Therefore, it is necessary to describe them more accurately. Definition 8. Property: Service Dependency Let s i and s j be two Transactional Web Services, s i .e [ and Sts(s i ), s j .t l () [ t 1 T 1 (s j ), dep(s i .e, s j .t l ()) denes that e needed s i .e k be its current s i state aiming s j .t l () transition. The dependencies are in agreement with the situation. Altogether, there are ve situations, described as following. Activation: The set of preconditions for activation of a service consists of situations that needed to be activated and that the system remains in a consistent state. In a process consisting of Transactional Web Services, the rst service to be done has preconditions that are identical to the whole process. For services that are not performed initially, the precondition is that the preceding has been completed suc- cessfully. Dependency and Activation Condition: expresses the rela- tionship that a given service has to be with other res, and contain the necessary conditions for activation. The acti- vation dependency, in a transition from s i to s j can be ex- pressed as following: depAtivation(s i , s j ) = dep(s i .completed, s j .activate()) For s j be activated, it is necessary that s i is complete and that its activation triggers the completion s j . The message m ij in this case has the function enable s j , one can (or more) eld c K ij take the information necessary to per- form the activation. For example, for the inventory control system records the sale of a product, it must be held be- fore the sale of the item, ie, the realization of active service volume debit; Alternative: An alternative execution must necessarily be caused by a failure. This allows the process to keep the ow without the need to be stopped as there is an alterna- tive service. Alternative condition: allows you to dene the alternatives in case of failure, as well as preconditions for each alterna- tive is feasible. This allows the implementation of recovery mechanisms, specifying that the execution of a second ser- vice is a possible alternative should the primary fail. The dependence of the alternative service s i for the service s j exists if the s i failure can activate s j , expressed as follows: depAlternativa(s i , s j ) = dep(s i .failed, s j .activate()) The message m ij be the function enable s j . She can carry the information that s i has failed, but not necessarily for- ever. For example, the core service delivery, when clicked, shows a failure of execution, triggering the invocation of an- other service delivery. The second need not know the rst one failed, depending on need. Abort: originated also from a failure can happen two dierent scenarios: rst, the failure is simply responsible for the interruption of the process, the second failure initiates a cancellation of the service which then aborts the rest, who therefore aborts the process ; Abort Condition: allows stop the execution of a particular service and prevent the system propagates a failure state. In a transition service from s i to s j , s j is aborted if s i fails or canceled. The relationship can be described as follows: depAborto(s i , s j ) = dep(s i .failed s i .cancelled, s j .abort()) This feature allows fault propagation from one service to their successors. One or more elds of the message m ij can report that s j must be aborted. For example, the process of buying a product can be aborted if the low-inventory was not completed; Compensation: for this transition, similar to the tran- sition of abortion, there are two sets of viable preconditions, arising from a failure that triggers a compensation or, orig- inated following a series of compensation; compensate condition: denes a mechanism for recover- ing from a given state through the implementation of state compensation. This is by specifying the steps needed to se- mantically undo what has been done by a particular service, indicating what must be undone. A transition of compen- sation, from a service s i to a service s j , occurs if s i fails, or if the compensation of s i shoots compensation of s j . This transaction is dened more specically as follows: depCompensacao(s i , s j ) = dep(s i .failed, s j .compensate()) dep(s i .compensate(), s j .compensate()) For this situation, the message m ij can have in an informa- tion eld that will trigger compensation of s j . For example, assuming a sale on a particular product, the low inventory is successful, however, to make the payment, it fails. The compensation is to reverse the fall in the stock, thus undoing what had already been done. That is, the failure of payment triggers the reversal of low inventory. Cancel: arises from a failure, which triggers a cancel- lation. In this scenario, the precondition is determined by failure of the previous service. Cancel condition: allows you to set rules for cancellation of certain services. It is similar to the abortion item, with the dierence that the whole service is canceled. A transition of cancellation from a service S i to s j service, occurs if s i fails and triggers the cancellation of s j . This relationship can be described as follows: depCancelamento(s i , s j ) = dep(s i .failed, s j .cancel()) The message m ij has the task of ring the cancellation s j . Fields of m ij may contain information that s i has failed and that this failure resulted in the cancellation of s j . For example, suppose a particular accounting system does not provide for cancellation, thus preventing a release of com- pensation is made. In this situation, should the need arise, the cancellation is made through a credit in another account. 6.1.2 Control Flow patterns and Transitions In the context of Web Services composition, there are two levels in the denition of control ows: the internal ow, in which service performs its own operations according to need and, the external ow, also known as coordination ow (or orchestration), which organizes the inputs and outputs of each Web Service, following a given sequence. The way that the ow coordination is dened directly inuences the quality and reliability of the composition [9]. Thus, van der Aalst and van Hee [39] have modeled se- quence, AND-Split, AND-Join, OR-split, OR-Join, XOR- Split and XOR-Join, from which, one can set standards for the control ows and thus determining transactional pat- terns. Such standards set by Bhiri et al. [9] are based on models proposed by van der Aalst and van Hee. A unappropriated construction or improper setting can cause ow inconsistencies. For example, when an XOR-Split is followed by an AND-Join: only one of two services, Web ServicesWS 1 or WS 2, runs; in an AND-Join, it is ex- pected the return of both. So, it is feasible ensure the con- sistency of ow through the application of these patterns. 6.2 A systematic for Transactional Composite Web Servicesreliable test based on trans- action patterns Through previously seen techniques, it is possible to ex- plore test conditions and thus enhance the detection of sys- tem problems. The set of techniques used by Melo and Sil- veira [38] allows the automatic creation of test cases, using as the basis submitted messages from one service to another. 6.2.1 sequence and precondition validation In the execution of a process, there is a certain order in the sequence. In this approach, we attempt to identify fault con- ditions, without the process or result of the preconditions are violated, acting directly on the messages exchanged. Thus, situations caused by loss of information, interference prob- lems in the middle or in the execution of services are simu- lated. For example, it can happen all the preconditions for the execution of a particular service are satised, however, problems in information transmitted. The reliability of the composition depends on the way such situations are outlined in the event. Independently of the types of input data for each service, the perturbation with limit values apply. This type of dis- turbance, based on all data types, when applied to specic elds of the message, allows interfere with the way informa- tion is transmitted between services. The disturbance in restricted types, through the facets, are used to dene valid data and invalid restrictions on data types. Simulated situations through the operators fractionDigits, length, maxLength, minLength, totalDigits, whiteSpace, maxExclusive, maxInclusive, minExclusive and minInclusive are already covered by disturbance-based limit values of data type, but can also identify inconsistencies in the solution. Operators enumeration, pattern to assess the reliability of a similar service. That is, all the techniques of perturbation-based facets contributed to this test scenario. Together with techniques based on primitive types, we have the set pd = PertDados accounting techniques that help the generation of test cases. The disturbance of com- munication enables creation of tests focused on the relation- ship and constraints on the messages exchanged between services. It is possible, for example, to simulate situations of dependency between the services: if a particular service s i needs to receive 3 responses from 3 other services, it is part of the preconditions for implementation of s i the com- pletion of the three services. If the message there is the 3 an- swers, even with complete services (pr-condition satised), the reliability will be compromised. These mutation opera- tors are applicable: Exchange(c 1 , c 2 ); Null(c), Incomplete(c), Inversion(c), ValueInversion(c) and Mod Len(c). For instance, assuming a sequence of two Transactional Web Services s i and s j , witch external transition is triggered by s i sending a message m ij to s j . Let s i .completed Prec(te, s j ). Thus, s j needs to be notied that s i is at a completed status. Let c k be a eld in m ij , where 1 k n and n equals to all eld in m ij . The perturba- tions Exchange, Null, Incomplete, Inversion, ValueInversion and Mod Len, when applied to c k compromise the notica- tion. Thereby, one can evaluate s j reliability, according to the resultd. All other mutation operators presents no con- tribution to the reliability evaluationin a precondition and sequence validation. The complete set of test case is the following:: cT (m ij ) = TT(pd, m ij ) Tc(pc, m ij ) /T(md, m ij ) onde: pd = PertDados, pc = PertCom e md = |Exchange, Null, Incomplete, Inversion, ValueInversion, Mod Len, Space. 6.2.2 Sequence Violation Perform services discarding the order in which they are as- signed can cause system problems. Through this approach, one can evaluate the ability of each service to respond to ad- verse situations, since it is not being executed in the order originally proposed. This makes it possible to evaluate all combinations of performance of the services that comprise the process. However, the universe of tests becomes very broad. For a process consisting of n services, we have n! combinations, all are expensive to run. Evaluating from the post-conditions of each service in the context of rape sequence, it is expected that a failure in ex- ecution, with the exception of services that are independent of the previous execution of other services, called the initial services of the process. Since there are no services previ- ously performed in the ow, it is expected that there are no failures. However, for the other services of the process, the ex- pected result is failure to perform. For this, the trouble is the n messages services, to perform in isolation, without the need to run the rest of the sequence in its entirety. That is, for every s i tws, 1 i n, with s i is not original, simply ensure that the process simulated with s i as initial failure. Thus, for this approach, the set of test cases is the same test isolated, so the application identical to that adopted in the validation of individual Transactional Web Services. The complete set of test cases is the following: cT (m ij ) = TT(pd, m ij )Tc(pc, m ij )/T(md, m ij ) 6.2.3 precondition violations With the sequence of the process unchanged and with no disruption in the messages exchanged in compliance with the preconditions, there is another scenario validation. In this approach, the aim is to identify problems due to not predicting certain behaviors in the system. For example, if a particular precondition is violated, it is expected that the system fails - it does not, or precondition was wrong, or the system not treated properly. By acting in the ow, without changing execution orders, test cases presented by Melo and Silveira [38], because they are directly linked to messages, add little to this approach. That is, for the breach of preconditions, you must also per- form other test cases. As Web Services are designed to be in- dependent [40], by assumption, the state of a service is only knowledge of the other services just by exchanging messages. activation condition: For the condition of activation, in a transition from s i to s j , is necessary for the service s i is complete. As in previous situations, the message sent to s j indicates the completion of s i . To test this condition, it is necessary that even s j receiving a message, it may not contain information referring to the completion of s i . With- out interfering in the meaning that the elds may have the tests that allow this are the disturbances on data types that deal with empty string, or 0 (which may mean, depending on the context, the absence of information), as well as the disturbance whitespace. The disturbances on communica- tion minOccurs, maxOccurs, choice, and all anyelement also enable the testing of this scenario, besides the mutation op- erators Exchange(c 1 , c 2 ), Null(c), Incomplete(c) and Space (c). For the status of activation, has been a test case of the activation state s j without the state s i is completed. The perturbation of the message between s i and s j will facilitate the violation of the precondition. Thus, applicable test cases in this scenario are as follows: CT(m ij ) = PD(pd, m ij ) PC(pc, m ij ) MD(md, m ij ) onde: PD(pd, m ij ) [ pd = |String, Numeric, Binary, WhiteSpace, PC(pc, m ij ) [ pc = |minOccurs, maxOccurs, choice, all, anyElement e MD(md, m ij ) [ md = |Exchange, Null, Incomplete, Space Alternative condition: As an alternative, it is neces- sary that the failure of s i triggers s j . However, the message m ij contains no information related to the failure of s i . Disturbances in this situation do not contribute in identify- ing specic failures of this condition. As it is a XOR-Split, a path does not necessarily knows about the existence of the other. The perturbation for the Alternative condition does not directly aect the test scenario. Thus, PD(|, m ij ) = PC(|, m ij ) = MD(|, m ij ) = . Similarly, in the alternative situation there is a test case that activates state s j with state s i dierent from failed. compensation condition: The condition for compensa- tion is identied in a transition from s i to s j through the message sent to s j with no information about the s i . Be- cause it is also an XOR-Split, where a path does not neces- sarily know of the existence of another, nor the disturbance or the mutations directly aect the test scenario. Thus, the tests presented in this case do not contribute, ie PD(|, m ij ) = , PC(|, m ij ) = and MD(|, m ij ) = . Condi cao de aborto: On the other hand, the conditions for abortion are related to an abrupt halt in the process, do not represent the right backdrop for running tests generated based on perturbations. thus, PD(|, m ij ) = , PC(|, m ij ) = and MD(|, m ij ) = . cancellation condition: Finally, in the situation of can- cellation can be validated through perturbation of operators Exchange(c 1 , c 2 ), Null(c), Incomplete(c), ValueInversion(c) and Space(c). The disturbances on primitive data types that deal with empty string, or 0 also contribute to these tests, as well as restrictions on the disturbance whitespace. Similar to the activation condition for the cancellation is to inform relevant data that result from processing the service of origin, which triggered the cancellation process. Thus, it has been running a test case that triggers the cancellation of s j with no failure in s i . The set of test cases to the cancellation policy is as follows: CT(m ij ) = PD(pd, m ij ) PC(pc, m ij ) MD(md, m ij ) onde: PD(pd, m ij ) [ pd = |String, Numeric, Binary, WhiteSpace, PC(pc, m ij ) [ pc = |minOccurs, maxOccurs, choice, all, anyElemente MD(md, m ij ) [ md = |Exchange, Null, Incomplete, ValueInversion, Space 7. WEB TRAVEL - A CASE STUDY To evaluate the criteria studied, it was constructed a hypothetical scenario, which consists of a system that en- ables customers to plan their trip using a single interface to make the hotel reservation, purchase airline tickets, pay- ment of both the request and delivery. Each service is oered through Web Services, integrated to the Web Travel System. By assumption, the client tells his origin, his destination, departure date and return date. The system then informs the available hotels and ight schedules that meet chosen criteria. After selecting the hotel and airline, the system has the date and time of ight, date, hotel check in and check out time, room type, total price information and credit card for delivery of tickets. Such services are represented by services s i : s 1 is a Hotel service; s 2 is a Flight service; s 3 is a Payment service; s 4 is a Delivery service 1 and; s 5 is a second Delivery service. Thus: tws = |s 1 , s 2 , s 3 , s 4 , s 5
As it is a process composed by Web Services, from the rst
data sent through the SOAP message, services communicate with each other, generating a series of other messages. The BPEL engine receives the rst message, creates the SOAP messages that are sent to the service of hotel reservation and ight booking. After processing services, the BPEL engine organizes and prepares answers the call to the next Web Service. The service on the reservation of hotel rooms responds to the request, stating that the request data can be properly charged, The airline reservation service returns an XML le containing the ight information, so that it can also be charged,through invocation of the service s 3 . The trans- mitted message from s 1 to s 3 is m 13 and the transmitted message from s 2 to s 3 is m 23 . The payment service can then be invoked. Gathering in- formation provided at the beginning of the process with the information received from the Flight reservation and Hotel reservation services, the invocation message is created. Similar to previous services, the Web Service payment processes the request and returns information regarding the consummation of the transaction. With this information, the BPEL engine can then combine with other information and form for the message delivery service s 4 .The message m 34 is transmitted s 3 for s 4 . The process is conrmed by the response of the servicewhich is used to compose the process response.s 5 service is not invoked if the s 4 runs suc- cessfully and so the message m 35 fails to be generated. 7.1 Techniques and Automatic test case gen- eration There are several transactional properties described in the system that can be veried. Starting with the individual services, one can evaluate the system units. The sequence of execution is also subject to assessment, which may be considered preconditions, especially in three critical points for the composition: parallel execution of airline booking services and hotel reservation (AND-SPLIT), the junction at the time of starting the execution of the payment service (AND-JOIN) and, to the exclusive delivery service (XOR- SPLIT). 7.1.1 Test case for isolated services and sequence validation For Web Services hotel and the airline s 1 and s 2 , for ser- vices to be initiated, the tests to be performed are the same type of tests performed to validate the sequence. The only restriction is just related to the input data for each service. In this approach, the execution of validation in the form of units of the system, tests were performed satisfactorily. Ac- cording to the test case, the results were as expected - both for failures as for successes. For example, in value inversions for the FirstName and LastName are not expected fail- ures. However, for value inversion of the elds from and to is expected to be an inconsistency of data presented as supposedly the date from must be smaller than the data to. Thus, service returns an error message after running the test case which reverses the eld values from and to. For other services, payment and delivery, is expected a failure as result. For the evaluation of the sequence, using the techniques outlined previously and test cases generated by GenAu- toWSit holds a battery of tests, in order to certify the re- sults. The tests are performed from the point of view of unity, evaluating them isolated. 7.2 Preconditions and sequence validation In addition to unit tests, also called isolated Web Services tests, it is important to validate the preconditions in the se- quence shown through the whole process. The critical points of the process are the AND SPLIT, AND JOIN and XOR JOIN. The AND SPLIT point starts the parallel execution of reservation services for hotel and ight reservation. AND JOIN The point is the junction of the responses and syn- chronization services for the payment service is triggered. The point of XOR SPLIT determines the performance of only a unique service delivery. For these situations, the approach is to evaluate the reli- ability of critical points. The execution order and the pre- conditions remain unchanged. Services s 1 and s 2 are the rst service of process. There is no restriction that prevents the execution of each one. The tests performed for evalua- tion alone is enough. However, subsequent servicing, s 3 , s 4 e s 5 , have the necessary conditions for the tests. All previ- ously dened test cases are applicable while maintaining the preconditions and sequencing. By running the test case that followed the technique Ex- change, applied to elds FlightNumber and HotelId, it was expected the system to fail to invoke the service s 3 . However, a positive response is obtained. The system went into an inconsistent state by accepting the invocation con- taining invalid values. There are several ways to correct the problem. One way to do it is through the implementation of a somewhat more sophisticated mechanism that allows cer- tify that the generated response is part of a same request. For example, when starting the process identier is gener- ated based on the date and time of commencement. From this point, the codes have been exchanged between the ser- vices that handle in its composition. 7.3 Precondition violation Considering the violation of preconditions, the objective is to evaluate how the system behaves if the preconditions are not met. The composition of services s 1 , s 2 , ..., s 5 follow specic patterns. To validate them, all test case seen in previous section will be applied. 7.3.1 Flight and Hotel services In Web Travel System, for Hotel and Flight services s 1 and s 2 , there are no conditions to be activated. If a request is sent to any of these services which results in an inconsis- tency, it should be treated by the service itself. For example, to start a particular seat ight reservation, that seat must be free. The same goes for a hotel room. But, as the goal is to evaluate characteristics of transactional Web composi- tions, these conditions are supposed to be treated properly in the GUI system. Thus, under the transactional view- point, there are no preexisting conditions for the activation of both services. By the attributes of the system, there is no alternative services for s 1 and s 2 . In another scenario, you can deploy services with alternative execution, or to a hotel with com- fort and has the same availability, or other airlines that oer other ights on the same date and time of the rst, which has the same origin and same fate. Both services are not subject to abortion. The failure of one must necessarily en- sure that the other was not executed. Thus, there is no position to abortion. Regarding the conditions of compensation, there are three situations: s 1 and s 2 fail not; s 2 and s 1 fail not; both s 1 and s 2 fail. Note that if both are carried out successfully there is need for compensation, not characterizing a necessary con- dition for compensation. In all three situations, there is no test cases based on change and disruption that contributes to the identication of aws in this scenario. Finally, the situation is not part of cancellation of the existing scenar- ios. 7.3.2 Payment and Delivery services The payment service s 3 and delivery services s 4 and s 5 several preconditions have to be run correctly. Activation of the payment service should only occur in case of suc- cessful execution of the previous (s 1 and s 2 ). Activation of the service delivery s 4 must occur through successful imple- mentation of service s 3 . Since the activation of the service delivery s 5 should only occur if the service performed s 3 has been successful and that s 4 has suered a failure to perform. The next step is to perform the tests. The results showed no gaps in services. However, for services s 4 and s 5 were noticed some unexpected situations in the system. The exe- cution is exclusive: that is just one of the services should be run. Running s 5 , even without fault in s 4 , there is a positive response from the system, and it was expected a message of inconsistency. That is, the precondition activation s 5 was broken (it was necessary that s 3 state was successfully com- pleted and that s 4 was in a state of failure, however, s 5 has been activated s 3 in completed state successfully and s 4 with state successfully completed). Although the problem has been identied through the exe- cution of test cases suggested by the data perturbation tech- nique, one can identify the same problem through the exe- cution of other test cases. 8. FINAL REMARKS There are several challenges in Web Servicesimplementa- tion. Many initiatives have emerged to overcome known problems with the main objective of making the adoption of Web Services simple and composite systems that they are reliable. Among the ways to address the problems, are the adoption of frameworks, usage patterns, transactional pat- terns, and performing such tests. This research contributes mainly on issues related to testing Web Services, by propos- ing criteria that help to identify test cases for specic trans- actional patterns. As seen in sections 5 and 6, it was possible to analyze a broad set of techniques for generating test cases and deter- mine the coverage when employed in verication and valida- tion Web Services and their composition. The application of these techniques proved satisfactory for validation of pre- conditions. In addition, the analysis by applying the techniques make it possible to evaluate thoroughly the characteristics of the composition, the critical behavior of the system. Thus, al- though some of the test cases to apply only to Web Services pure, you can still get valuable information of composition and how they can be tested. Perturbation techniques and mutation presented by Melo and Silveira [38] implemented in GenAutoWS have been al- ready evaluated for applicability testing Web Services iso- lated. When analyzing a system more fully, or more pre- cisely integration points, there has been little information about the eectiveness of the tests and what the best ap- proach. Simply apply the test cases presented in a ad hoc way can result in the desired situation. The adoption of standards for composition Web Services is an alternative to improve the interoperability of web sys- tems. Transactional patterns are useful in building processes based on such compositions. This study used as the applica- tion of transactional patterns that let you combine Web Ser- vices with specic characteristics, such as having the ability to re-run, have conditions of compensation, among others. Moreover, they are taken as a basis the set of techniques of mutation and perturbation test data applicable to Web Services. Based on the transactional characteristics and also the set of test cases generated from the mutation and per- turbation techniques, this paper seeks to identify certain conditions to identify problems eectively in the composi- tion of services, validate the condition of your use and as ow of information can aect the behavior of the service as a whole. From the analysis of each technique as well as the anal- ysis of the conditions of the standards, you get coverage of techniques for each situation identied in the applica- tion of transactional patterns. Such coverage can be veried through the application in a case study, whose objective is to seek to understand and demonstrate how to apply and how is it possible to identify problems in the composition of Web Services to the development of a process. There is also a huge range of topics and issues to be ad- dressed, all related to the topic discussed in this work. The scope of the analysis was specic to transactional patterns and also covers how mutation based tests and data pertur- bation can contribute to the reliability of composition Web Services. Other patterns, however, can be assessed, for ex- ample security, exceptional treatment, among others. Sim- ilarly, one can evaluate other testing techniques that guide how the reliability should be obtained. All these tests con- tribute to a clear denition of criteria, not just for testing Web Services, but also for their own composition. The denition of communication between Web Services other item is likely to deepen. In this work we considered the exchange of messages targeted for analysis. It is possible to identify other means of extracting test conditions, thus rening the systematic validation of service composition. Acknowledgment The authors would like to thank... more thanks here 9. REFERENCES [1] W3C, The world wide web consortium (w3c), 2010, disponvel em http://www.w3.org/, acessado em fevereiro de 2010. [2] H.-G. Gross, Component-based Software Testing With Uml. SpringerVerlag, 2004. [3] C. Ferris and J. Farrell, What are web services? Commun. ACM, vol. 46, no. 6, p. 31, 2003. [4] G. Alonso, F. Casati, H. Kuno, and V. Machiraju, Web Services - Concepts, Architectures and Applications, 1st ed. Springer, October 2003. [Online]. Available: http://www.worldcat.org/isbn/3540440089 [5] J.-C. Laprie, From dependability to resilience, in Supplemental Proceedings of the International Conference on Dependable Systems & Networks. Anchorage, Alaska, USA: DSN, 2008, pp. 89. [6] E. Chang, F. Hussain, and T. Dillon, Trust and Reputation for Service-Oriented Environments: Technologies For Building Business Intelligence And Consumer Condence, 1st ed. Wiley, July 2006. [Online]. Available: http://www.amazon.com/exec/obidos/redirect?tag= citeulike07-20\&path=ASIN/0470015470 [7] D. A. Menasce, Qos issues in web services, IEEE Internet Computing, vol. 6, no. 6, pp. 7275, 2002. [8] G. Dobson, Using ws-bpel to implement software fault tolerance for web services, in EUROMICRO 06: Proceedings of the 32nd EUROMICRO Conference on Software Engineering and Advanced Applications. Washington, DC, USA: IEEE Computer Society, 2006, pp. 126133. [9] S. Bhiri, C. Godart, and O. Perrin, Transactional patterns for reliable web services compositions, in ICWE 06: Proceedings of the 6th international conference on Web engineering. New York, NY, USA: ACM, 2006, pp. 137144. [10] G. A. Di Lucca and A. R. Fasolino, Testing web-based applications: The state of the art and future trends, Inf. Softw. Technol., vol. 48, no. 12, pp. 11721186, 2006. [11] C. Bartolini, A. Bertolino, S. Elbaum, and E. Marchetti, Whitening soa testing, in ESEC/FSE 09: Proceedings of the the 7th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering. New York, NY, USA: ACM, 2009, pp. 161170. [12] G. Canfora and M. Penta, Service-oriented architectures testing: A survey, Software Engineering: International Summer Schools, ISSSE 2006-2008, Salerno, Italy, Revised Tutorial Lectures, pp. 78105, 2009. [13] M. A. Friedman and J. M. Voas, Software Assessment: Reliability, Safety, Testability. New York, NY, USA: John Wiley & Sons, Inc., 1995. [14] M. H. Mustafa Bozkurt and Y. Hassoun, Testing web services: A survey, Department of Computer Science, Kings College London, Tech. Rep. TR-10-01, January 2010. [15] G. K. Saha, Fault tolerance in web services, Ubiquity, vol. 2006, no. March, p. 1, 2006. [16] , Transient software fault tolerance using single-version algorithm, Ubiquity, vol. 2005, no. August, 2005. [17] A. Erradi, P. Maheshwari, and V. Tosic, Recovery policies for enhancing web services reliability, in ICWS 06: Proceedings of the IEEE International Conference on Web Services. Washington, DC, USA: IEEE Computer Society, 2006, pp. 189196. [18] S.-T. Wen, Q. Li, L. Yue, and A. Liu, An approach to validating transactional properties of ws-bpel composition, in Fifth International Conference on Semantics, Knowledge and Grid, 2009., vol. 2009, oct. 2009, pp. 216 223. [19] D. L ubke, Unit testing bpel compositions, in Test and Analysis of Web Services. Springer, 2007, pp. 149171. [20] Z. J. Li, J. Zhu, L.-J. Zhang, and N. Mitsumori, Towards a practical and eective method for web services test case generation, in Automation of Software Test, 2009. AST 09. ICSE Workshop on, 18-19 2009, pp. 106 114. [21] J. Outt and W. Xu, Generating test cases for web services using data perturbation, SIGSOFT Softw. Eng. Notes, vol. 29, no. 5, pp. 110, 2004. [22] N. Laranjeiro, S. Canelas, and M. Vieira, wsrbench: An on-line tool for robustness benchmarking, in SCC 08: Proceedings of the 2008 IEEE International Conference on Services Computing. Washington, DC, USA: IEEE Computer Society, 2008, pp. 187194. [23] A. M. Paradkar, A. Sinha, C. Williams, R. D. Johnson, S. Outterson, C. Shriver, and C. Liang, Automated functional conformance test generation for semantic web services, Web Services, IEEE International Conference on, vol. 0, pp. 110117, 2007. [24] A. Wombacher, P. Fankhauser, and E. Neuhold, Transforming bpel into annotated deterministic nite state automata for service discovery, in In Intl. Conference on Web Services (ICWS. IEEE Computer Society, 2004, pp. 316323. [25] P. Ramsokul and A. Sowmya, A snier based approach to ws protocols conformance checking, in ISPDC 06: Proceedings of the Proceedings of The Fifth International Symposium on Parallel and Distributed Computing. Washington, DC, USA: IEEE Computer Society, 2006, pp. 5865. [26] Y. Yang, Q. Tan, and Y. Xiao, Verifying web services composition based on hierarchical colored petri nets, in IHIS 05: Proceedings of the rst international workshop on Interoperability of heterogeneous information systems. New York, NY, USA: ACM, 2005, pp. 4754. [27] M. P. Papazoglou, Service -oriented computing: Concepts, characteristics and directions, in WISE 03: Proceedings of the Fourth International Conference on Web Information Systems Engineering. Washington, DC, USA: IEEE Computer Society, 2003, p. 3. [28] S. Mehrotra, R. Rastogi, H. F. Korth, and A. Silberschatz, A transaction model for multidatabase systems, University of Texas at Austin, Austin, TX, USA, Tech. Rep., 1992. [29] S. Bhiri, O. Perrin, and C. Godart, Ensuring required failure atomicity of composite web services, in WWW 05: Proceedings of the 14th international conference on World Wide Web. New York, NY, USA: ACM, 2005, pp. 138147. [30] J. Williams, The web services debate: J2ee vs. .net, Commun. ACM, vol. 46, no. 6, pp. 5863, 2003. [31] S. Balasubramaniam, G. A. Lewis, E. Morris, S. Simanta, and D. B. Smith, Challenges for assuring quality of service in a service-oriented environment, in PESOS 09: Proceedings of the 2009 ICSE Workshop on Principles of Engineering Service Oriented Systems. Washington, DC, USA: IEEE Computer Society, 2009, pp. 103106. [32] H. Huang, W.-T. Tsai, R. Paul, and Y. Chen, Automated model checking and testing for composite web services, in ISORC 05: Proceedings of the Eighth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing. Washington, DC, USA: IEEE Computer Society, 2005, pp. 300307. [33] A. Barbir, C. Hobbs, E. Bertino, F. Hirsch, and L. Martino, Challenges of testing web services and security in soa implementations, in Test and Analysis of Web Services. Springer, 2007, pp. 395440. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-72912-9 14 [34] W. Tsai, R. Paul, L. Yu, A. Saimi, and Z. Cao, Scenario-based web services testing with distributed agents, IEICE transactions on information and systems, vol. 86, no. 10, pp. 21302144, 2003. [Online]. Available: http://ci.nii.ac.jp/naid/110003213658/ [35] G. Canfora and M. Di Penta, Testing services and service-centric systems: Challenges and opportunities, IT Professional, vol. 8, no. 2, pp. 1017, 2006. [36] R. Blanco, J. Garca-Fanjul, and J. Tuya, A rst approach to test case generation for bpel compositions of web services using scatter search, in ICSTW 09: Proceedings of the IEEE International Conference on Software Testing, Verication, and Validation Workshops. Washington, DC, USA: IEEE Computer Society, 2009, pp. 131140. [37] V. Pretre, F. Bouquet, and C. Lang, Using common criteria to assess quality of web services, in ICSTW 09: Proceedings of the IEEE International Conference on Software Testing, Verication, and Validation Workshops. Washington, DC, USA: IEEE Computer Society, 2009, pp. 295302. [38] A. C. de Melo and P. Silveira, Improving data perturbation testing techniques for web services, Information Sciences, vol. 181, no. 3, pp. 600 619, 2011. [Online]. Available: http://www.sciencedirect. com/science/article/B6V0C-515SRJV-4/2/ d10fe4c467bfec9717327d6bc0f784ef [39] W. van der Aalst and K. van Hee, Workow Management: Models, Methods, and Systems. Cambridge, MA, USA: MIT Press, 2004. [40] L. Baresi and E. D. Nitto, Test and Analysis of Web Services. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2007.