QDquaderni. Designing Self Adaptive Service Oriented Applications G. Denaro, M. Pezzè, D. Tosi. university of milano bicocca

Transcription

1 ARACNE university of milano bicocca QDquaderni department of informatics, systems and communication Designing Self Adaptive Service Oriented Applications G. Denaro, M. Pezzè, D. Tosi research report n. 4 march 2006

2 A01 084/04

3 university of milano bicocca QDquaderni department of informatics, systems and communication Designing Self Adaptive Service Oriented Applications G. Denaro, M. Pezzè, D. Tosi research report n. 4 march 2006 ARACNE

4 Copyright MMVII ARACNE editrice S.r.l. via Raffaele Garofalo, 133 A/B Roma (06) ISBN ISSN xxxxx I diritti di traduzione, di memorizzazione elettronica, di riproduzione e di adattamento anche parziale, con qualsiasi mezzo, sono riservati per tutti i Paesi. Non sono assolutamente consentite le fotocopie senza il permesso scritto dell Editore. I edizione: gennaio 2007

5 Table of Contents Designing Self-Adaptive Service-Oriented Applications Giovanni Denaro, Mauro Pezzè and Davide Tosi 1 Introduction The Service Mismatch Problem A Self-Adaptive Approach Design Time Support Integration Mismatch Taxonomy A Framework for Developing Self-Adaptive Service-Oriented Applications The SHIWS Eclipse plug-in The runtime infrastructure Preliminary Results and Lessons Learned The Methodology Preliminary Validation Results Related Work Conclusions

6

7 Designing Self-Adaptive Service-Oriented Applications Giovanni Denaro 1, Mauro Pezzè 1 and Davide Tosi 1 Università degli Studi di Milano - Bicocca Via Bicocca degli Arcimboldi Milano, Italia Abstract. The integration of third-party web services helps solve complex business problems and reduce risks, costs and time-to-market. However, the task of the integrators is challenged by services that are maintained by different organizations, and may evolve dynamically and autonomously. The impossibility of statically determining which service implementation will be bound at runtime may lead to unexpected failures. This paper presents a novel approach for designing self-adaptive serviceoriented applications, which autonomously react to changes in the implementation of the services, automatically detect possible integration mismatches, and dynamically execute suitable adaptation strategies. The solution proposed in this paper, is based on a runtime infrastructure that automatically tests remote web services, uses test results to diagnose service mismatches, and executes adaptation strategies to overcome the revealed problems without user intervention. 1 Introduction Web services and service-oriented architectures are emerging technologies for integrating enterprise applications, leveraging electronic B2B and B2C solutions, and extending the life of legacy software. In a nutshell, web services are remote programs invoked over the Internet, using standard protocols (e.g., HTTP and XML) for exchanging data between requesters and providers. Web services allow enterprises to export functionality outside the enterprise bounds, thus enabling stakeholders of different domains to rapidly and seamlessly integrate third-party expertise into their applications. For example, airlines and hotel chains can export services for online booking; so that travel agencies can combine these and other services to optimize travel plans. Service-oriented architectures help solve complex business problems, decreasing risks, costs and time-to-market. The integration of third-party web services is challenged by the difficulty of keeping consistency between software systems that are maintained by different organizations and may evolve dynamically and independently, because of both changes in the services and the dynamic discovery of new services. Service providers may change the implementation independently from clients, e.g., to correct faults or meet new requirements. For example, this is the case of old

8 Product Categories Books Electronics Musical Instruments Pets Service Characteristics Shipping Modality TNT express Shipping Times 24 h Payment Modality PayPal Product Availability Required SUBMIT REQUEST 8 G. Denaro, M. Pezzè and D. Tosi versions substituted with new ones. Moreover, in many service-oriented architectures, clients can locate services dynamically, using service discovery mechanisms that allow clients to discover and connect web services based on machinereadable descriptions. This means that clients may use different web services in different invocations depending on the choice of a service broker. As illustrated in Figure 1, a broker matches client requests with available services published by providers according to common protocols (e.g., SOAP, WSDL and UDDI), and each time applications reconnect to web services through brokers, they can get different matches and thus use different implementations of the requested services [5]. Communication (SOAP) Bind SERVICE PROVIDER Publish(WSDL) The Virtual Store Application SERVICE REQUESTOR Find(WSDL) SERVICE BROKER UDDI Registry Fig. 1. Main entities and interactions in a service oriented architecture In this paper, we focus on integration problems that derive from dynamic changes of the invoked services. Different services or service implementations that can be invoked to satisfy a given request must comply with a contract that indicates the characteristics of the required service 1. In principle, services that comply with the same contract should be equivalent, but in practice contracts tend to specify little more than the service syntax and parameters, leaving many semantic details unspecified and thus implementation-dependent. For example, we have been using web services for obtaining the weather temperatures in US districts on the basis of a contract that required the target location to be indicated with the zip-code and the temperature to be returned as a floating point value, but did not indicate the measurement unit of the return temperature. This contract matched many services that returned temperatures expressed in different measurement units, e.g., Fahrenheit and Celsius, thus leading to client-side failures. 1 Contracts are usually expressed in standard machine-readable languages, e.g. the Web Service Description Language (WSDL) [3].

9 Designing Self-Adaptive Service-Oriented Applications 9 We propose a solution that exploits a self-adaptive approach based on a mechanism for revealing possible mismatches between requested and provided services, and for dynamically adapting the client application accordingly. An integration fault taxonomy helps service integrators identify possible integration mismatches, generate test cases for revealing integration problems, and design recovery actions. Integrators can code test cases and adaptation strategies in separate modules, which we refer to as adaptation aspects. We automatically weave adaptation aspects into the client applications, so that the modified client application executes test cases whenever a new service implementation is detected to reveal possible mismatches, and triggers suitable adaptation mechanisms accordingly. We refer to the proposed approach as adaptive integration of web services. This paper is organized as follows. Section 2 describes mismatch problems that may derive from the integration of web services, referring to a working example that will be used throughout the paper. Section 3 presents an overview of our approach to adaptive integration of web services. Section 4 and Section 5 respectively introduce details of the approach discussing the methodology and the framework for developing self-adaptive service oriented applications. In Section 6 we summarize the results of our experiments. We discuss related work in Section 7, and finally we conclude in Section 8. 2 The Service Mismatch Problem As discussed in the introduction, the services invoked by an application may change due both to autonomous modifications of the service implementation by the provider and to bindings to new services dynamically discovered by a broker. In this section, we illustrate the problems that derive from dynamically evolving services through a virtual store, an example that we use throughout the paper. Figure 2 illustrates the interactions between the virtual store and the broker to dynamically discover remote stores and other services. When customers select product categories (e.g. electronics, books, musical instruments, etc...) and required purchase characteristics (e.g. price limit, delivery time, shipping and payment modalities, etc...), VirtualStore asks the broker for providers that satisfy the requirements. If the selected providers do not offer all the required services, VirtualStore integrates the services by asking the broker for additional services, e.g., credit cards validations, or shopping carts. The dynamic integration of different services may lead to several problems. Consider for example, the request for a shopping cart web service. Figure 3 shows an excerpt of the operations that characterize the specification of the request. This WSDL description can match many WSDL specifications of services available from common UDDI repositories e.g. Amazon [ that differ in several small but important details. For instance, some providers offer a CartAdd operation able to manage multiple instances of the same item in a single add operation, while others may not support multiple instances; we used services that provide CartModify operations that remove an item by changing

10 10 G. Denaro, M. Pezzè and D. Tosi SERVICE BROKER VIRTUAL STORE APPLICATION VIRTUAL STORE FRONT END Sign On/Off Update Account Info Start New Orders Browse Remote Catalogs WS1 Credit Card Validator WS2 Shopping Cart WEB STORE A WS Shopping Cart Update Remote Orders Submit Remote Orders WS2 Shopping Cart WS3 Catalogs WEB STORE B Fig. 2. The overall architecture of the VirtualStore application its quantity to zero and others that remove an item by decreasing the quantity by one; we discovered services that can create empty carts (CartCreate operation) and others that require a selected item to create a cart. Finally, we used services that can manage orders and purchases processed in different user sessions (persistent cart), and others that do not, i.e., that loose their contents when sessions terminate (non-persistent cart). All variants match the WSDL interface. Since VirtualStore can be connected to different shopping cart services at different times, we can have several relevant failures due to the inhomogeneous implementations of the target services. 3 A Self-Adaptive Approach High availability requirements and dynamically discovered web services exclude the possibility of traditional stop-update-test-redeploy-restart approaches to the integration of new or modified services. Self-adaptive applications have been recognized as viable solutions for dealing with systems where size and complexity increase beyond the ability of humans to respond manually, coherently and timely to environmental and system changes [7]. Self-adaptive solutions are being experimented in several application domains, but not in service-oriented applications yet. The massive reuse of services and the frequent updates of implementations corresponding to compatible interfaces are typical of service-oriented

11 Designing Self-Adaptive Service-Oriented Applications <! -- ItemSearch: Searches and selects an item through a product catalog -- > 3 - <operation name=" ItemSearch " > 4 <input message =" tns:itemsearchrequest "/ > 5 <output message =" tns:itemsearchresponse "/ > 6 </ operation > <! -- CartGet: Retrieves the list of items in a cart that you have built but have not yet submitted to store for a customer to purchase --> 10 - <operation name=" CartGet " > 11 <input message =" tns:cartgetrequest "/ > 12 <output message =" tns:cartgetresponse "/ > 13 </ operation > <! -- CartAdd: Adds selections to the cart --> 16 - <operation name=" CartAdd " > 17 <input message =" tns:cartaddrequest "/ > 18 <output message =" tns:cartaddresponse "/ > 19 </ operation > <! -- CartCreate: Creates a remote shopping cart for a single customer --> 22 - <operation name=" CartCreate " > 23 <input message =" tns:cartcreaterequest "/ > 24 <output message =" tns:cartcreateresponse "/ > 25 </ operation > <! -- CartModify: Changes quantities of items, delete items, replaces items with new ones --> 28 - <operation name=" CartModify " > 29 <input message =" tns:cartmodifyrequest "/ > 30 <output message =" tns:cartmodifyresponse "/ > 31 </ operation > <! -- CartClear: Removes all selections from a cart, emptying the cart --> 34 - <operation name=" CartClear " > 35 <input message =" tns:cartclearrequest "/ > 36 <output message =" tns:cartclearresponse "/ > 37 </ operation > <! -- CartPurchase: Finalizes the purchase process --> 40 - <operation name=" CartPurchase " > 41 <input message =" tns:cartpurchaserequest "/ > 42 <output message =" tns:cartpurchaseresponse "/ > 43 </ operation > Fig. 3. Excerpt of the WSDL description of a shopping cart WS

12 12 G. Denaro, M. Pezzè and D. Tosi applications, and allow for defining efficient domain specific self-adaptive solutions for the service-oriented domain. In this paper we propose a self-adaptive approach to the development of service-oriented applications that combines novel techniques into a traditional sense-plan-act control loop, where the subject system is connected to a controller that in turn feeds commands back into the subject system. Figure 4 illustrates how to instantiate a classic sense-plan-act control loop to deploy self-adaptive service-oriented applications. The invocation of a web service triggers monitoring mechanisms. Such mechanisms identify changes in the invoked services that may depend on server-side implementation updates or dynamically discovered services. The detection of a new service implementation triggers diagnosis mechanisms that run test cases on the target web service to reveal possible mismatches. If the diagnosis mechanisms reveal any mismatches, associated adaptation strategies update the structure and the behavior of the client application to solve the identified problems and optimize the interaction with the target service. Monitoring Mechanisms WS Invocation CHECKING WS IMPLEMENTATION New implementation detected NORMAL EXECUTION No change TESTING THE WS No mismatch Diagnosis Mechanisms New Configuration UPDATING THE APPLICATION Mismatches detected Adaptation Mechanisms Fig. 4. The generic adaptation control loop The sense-plan-act control loop must be instantiated for each set of services that comply with a specific contract. The customization consists of defining a set of test cases that can reveal mismatches between different implementations of the same contract and a set of adaptation strategies for the classes of possible mismatches. For example, in the VirtualStore presented in Section 2, we can identify the set of services that comply with the WSDL cart specification in Figure 3.

13 Designing Self-Adaptive Service-Oriented Applications 13 Different implementations of the WSDL specification may provide persistent and non-persistent carts, i.e., carts that keep or loose their contents through different sessions. A self-adaptive mechanism for these kinds of mismatches can include a set of test cases to verify the persistency of the cart, and adaptation strategies to overcome persistency problems, as illustrated in Figure 5. WS Invocation No change New implementation detected Test specs Test_1: Check for cart persistence 6. login to the cart web service, 7. create a new cart and add an item, 8. logout and login again to the cart web service, 9. try to retrieve the previously created cart, 10. if the cart does not exist or is empty, fail the test, otherwise signal test success. New Configuration Mismatches detected Adaptation strategies - If Test_1 fails, then use local support for persistence. - If Test_1 succeeds, then rely on remote persistence. Fig. 5. The instantiated adaptation control loop for the persistency problem The control loop instantiated with automatic test cases and adaptation strategies will enhance all client invocations of the cart web service. Enhanced client applications intercept all calls to the cart web service, dynamically check the persistence of the cart, and adapt the local behavior accordingly. 4 Design Time Support The customization of the sense-plan-act control loop is based on a methodology and a design framework that help designers identify the customization requirements for control loops. The methodology is composed of three steps illustrated in Figure 6 that are executed when a new web service category is selected for integration in the target application. 1. SET-UP Identify mismatches 2. DIAGNOSIS Define a test suite 3. ADAPTATION Define an adaptation suite Fig. 6. The methodology for designing customized control loops

14 14 G. Denaro, M. Pezzè and D. Tosi Set-up (identify mismatches) In the set-up phase, software architects analyze the WSDL description of the new category to identify ambiguities that may result in implementation dependent mismatches. The analysis is driven by domain specific fault taxonomies. Subsection 4.1 presents the taxonomy of integration faults that we used in our experiments, together with simple examples of faulty services. Diagnosis (define a test suite) In the diagnosis phase, software architects design test cases to reveal the occurrence of the potential mismatches identified in the setup phase. Test cases are defined according to guidelines that describe possible test strategies for different fault categories. Subsection 4.1 presents the test strategies that we used in the experiments, together with examples of applications. Adaptation (define an adaptation suite) In the adaptation phase, software architects design adaptation strategies. When the application senses possible changes in the services, it automatically executes the test cases defined in the previous phase. If the tests reveal service mismatches, the application tries to adapt to the new service implementation by executing the adaptation strategy corresponding to the identified problem, and checks if the adaptation succeeds. Adaptation strategies are defined according to domain specific adaptation patterns for recurrent types of mismatches. In our experiments, we used a set of adaptation patterns based on common design patterns. Subsection reports the identified adaptation patterns for the classes of mismatches in our taxonomy, together with simple examples of applications that refer to the samples of Subsection Integration Mismatch Taxonomy When integrating web services into client applications, we may expect to have both problems similar to the ones typical of the traditional object-oriented paradigm, and new failures specifically related to the service-oriented paradigm. In this section, we provide an integration mismatch taxonomy, composed of seven different kinds of potential mismatches, together with simple examples. Inconsistent Interpretation of Parameters or Values Definition: The semantics of input and output parameters or values may not be fully specified by the WSDL interface of the service, thus leading to inconsistent interpretation of the input/output parameters or values. Test Suite: The test suite can be defined by: a) identifying parameters or values that return distinguishable result for each possible interpretation; b) invoking the service with the identified values; c) checking the results. Adaptation Suite: The adaptation suite can be defined by designing a set of adapters for each possible interpretations of parameters or values. The adapters mediate calls to the target service and provide correct conversions

15 Designing Self-Adaptive Service-Oriented Applications 15 of parameters and values. When testing reveals an interpretation mismatch, the adaptation strategy dynamically selects the proper adapter that provides the right interpretation. Examples: Consider for example a web service that controls a camera based on three floating point parameters that indicate the position of the focus. Possible mismatches can derive from interpretations of the three values as Cartesian or polar coordinates. To reveal the use of polar instead of Cartesian coordinates, we can test the service by one parameter in turn set to zero. No movement in one of the tests indicates polar coordinates. Adapters implement conversions between different types of coordinates e.g., Polar to Cartesian. Violation of Value Domains or of Capacity/Size Definition: The syntax of WSDL specifications does not provide information about the domains of values or capacity/size, thus leading to potential violation of the structural constraints of the service. Test Suite: The test suite can be defined by: a) invoking the service with representative values for each possible value domain and capacity constraint; b) checking the results. Adaptation Suite: The adaptation suite can be defined by designing a set of proxies that filter calls to the target service, identify the calls that violate value domains or capacity, and handle the violations. Non-violating calls are simply forwarded. When testing reveals the existence of a domains or capacities violation, the adaptation strategy dynamically selects the proxy that can handle the violation. Examples: Consider for example a web service that validates credit cards based on two strings that indicate credit card number and expiration date. Possible mismatches can derive from the domain of the credit card number that may include all possible types of credit card issuers or only a subset of them, and may or may not include a validation code at the end of the card number. To reveal limits in the supported credit card issuers, we can test the service with different credit card numbers, which represent different types of credit card issuers. Proxies filter the non-supported credit card issuers to overcome domain mismatches. Unexpected Side Effect on Parameters or Resources Definition: The invocation of the operations exposed in WSDL specifications may produce unexpected side effects on parameters or resources of the service. Test Suite: The test suite may be defined by: a) invoking the service with values that may cause perceivable side effects; b) checking the results. Adaptation Suite: The adaptation suite may be defined by designing a set of decorators that either mask or fix the side-effects. When testing detects a side-effect, the strategy dynamically wraps the service with the corresponding decorator.

16 16 G. Denaro, M. Pezzè and D. Tosi Examples: Consider for example the web service that validates credit cards. It may or may not reduce the available credit as a side effect of the validation (this may lead to exhausting the credit without completing all of the requested transaction). To reveal whether the service reduces the available credit as a side effect of the credit card validation, we may try to validate a credit card twice with single values within the credit limit, and sum exceeding the limit. Decorators can buffer the accesses to the credit validation and postpone the validation at the end of the transactions, to reduce the risk of credit overflow. Missing or Misunderstood Functionality Definition: Operations exposed by WSDL specifications may or may not be actually implemented by the service, or service functionalities may be misunderstood by software integrators. Test Suite: The test suite can be defined by: a) identifying cases where correctness depends on the presence of the considered functionality, and produce distinguishable results depending on the presence of the functionality; b) running the service for the identified cases c) checking the results. Adaptation Suite: The adaptation suite can be defined by designing a set of decorators that implement the missing functionality or convert between different possible interpretation of the misunderstood functionality. When testing reveals missing or misunderstood functionality, the adaptation strategy dynamically wraps the service with the corresponding (set of) decorator(s). Examples: Consider for example a web service that controls the access to a restricted area based on an access-identifier. The service may or may not keep track of the status of the access-identifier, and thus allow an access-identifier to re-enter the restricted area without leaving the area in between. To discover whether the service keeps track of the status of the access-identifier, we can try to enter the reserved area twice with the same access-identifier without leaving the area in between. A decorator can keep track of the access-identifier status and warn the user about the risks of using different access-identifiers to enter and exit the area. Violation of non-functional Requirements Definition: The syntax of WSDL specifications does not provide a way to describe non-functional requirements of the service, thus leading to violation of performance or security constraints. Test Suite: The test suite can be defined by: a) identifying cases that reveal different non-functional characteristics of the services; b) running the service for the identified cases; c) checking the results; d) deducing the corresponding non-functional service profile. Adaptation Suite: The adaptation suite can be defined by designing ad-hoc adaptation solutions that relax the violated non-functional requirements to meet the non-functional profile of the target web service.

17 Designing Self-Adaptive Service-Oriented Applications 17 Examples: Consider for example a composite service that invokes several elementary web-services for booking a complete trip (flight, hotel, car, etc...). Each elementary web service may be offered by different providers with different response times. The order of invocation of the elementary web services may violate performance requirements of the composite service. To discover whether the choice of the elementary web services violates the response time requirements of the composite service, we can measure the response time of the different providers and estimate the total average response time. No standard adaptation pattern is available. Violation of the Interaction Protocol Definition: In general, WSDL specifications do not fully specify the sequence in which the operations of a target service can be invoked, thus leading to violation of the interaction protocol of the service. Test Suite: The test suite can be defined by: a) identifying a model of the interaction protocol (e.g., a finite state machine); b) selecting an adequacy criterion (e.g., transition coverage) and generate a set of test cases; c) running the service for the identified cases d) checking the results. Adaptation Suite: The adaptation suite can be defined by designing a set of façades that map the interaction protocol used by the client application to the interaction protocol of the target service. When testing reveals a violation of the interaction protocol, the adaptation strategy dynamically selects the façade that provides the correct mapping. Examples: Consider for example a web service that manages online orders, and stores items selected by the customer. The service may or may not require the creation of an empty cart before adding the first item, thus resulting in potentially incorrect interactions with the service. To discover whether carts must be explicitly created before adding any item, we can try to connect the service and add an item without creating the cart. A façade can map the client invocations to the order of invocations required by the shopping cart web service. Notes: Conformance testing provides several approaches for testing and deriving the interaction protocol of a system. However, these approaches are often too expensive and inapplicable. When the behavior of the service is complex, the number of the test cases derivable applying conformance techniques is too huge, thus making inadmissible to run the service with all the identified cases. Violation of the Cardinality of Input Parameters Definition: In general, the WSDL specification of a service does not specify the mandatory input parameters, or the order of the parameters for each operation, thus leading to a potential violation of the cardinality of input parameters.

18 18 G. Denaro, M. Pezzè and D. Tosi Test Suite: The test suite may be defined by: a) identifying possible alternatives for the number and order of the input parameters; b) invoking the service for each identified alternative; c) checking the results. Adaptation Suite: The adaptation suite may be defined by designing a set of façades that map client calls to target services with different numbers and orders of input parameters. When testing reveals a violation in the number or order of input parameters, the adaptation strategy dynamically selects the façade that provides the correct mapping. Examples: Consider for example the Google web search: with this web service, software developers can query billions of web pages directly from their own computer programs. The WSDL specification of the Google web search defines the available queries with a generic set of parameters, resulting in possible incorrect service invocations. To discover the mandatory input parameters for a web search, we may try to use the service with a selected set of combinations of input parameters. A façade can map the client invocations to the number of input parameters required by the Google search web service. 5 A Framework for Developing Self-Adaptive Service-Oriented Applications The implementation of self-adaptive service-oriented applications is facilitated by the SHIWS (Self-Healing Integrator for Web Services) framework. SHIWS automatically builds the runtime infrastructure that links the client application to the target web services, incorporating the diagnosis and adaptation strategies provided by designers. The runtime infrastructure both handles the logics of the customized sense-plan-act control loops at runtime, and allows for dynamically selecting and enacting different adaptation strategies. We implemented a SHIWS prototype as a plug-in of the Eclipse open platform, an extensible development IDE widely used in many domains. Eclipse consists of a set of open source projects focused on providing an extensible development platform and application frameworks for building software [ Since Eclipse is increasingly used to support software development throughout all phases of the development process, it is an ideal joint-point for introducing our novel approach in the software process of service-oriented applications. The current SHIWS prototype works for web applications written in Java. 5.1 The SHIWS Eclipse plug-in Our prototype augments Eclipse with two new commands, Add new web service and Generate self-adaptation, and a new development perspective 2, the control loop customization perspective, shown in Figure 7. 2 In Eclipse, a perspective is a customized view of the IDE, which is tailored around a specific programming language or functionality.

19 Designing Self-Adaptive Service-Oriented Applications 19 (a) (a) web service interface (c) adaptation.config (b) (b) test_case.config Fig. 7. The new control loop customization perspective of Eclipse The command Add new web service facilitates the inclusion of new web services in a project. The developer is required to provide the URL of a WSDL specification that describes the characteristics of the included web service. SHIWS retrieves the WSDL description, and parses it for identifying operations and parameters of the web service. The main effect of the command Add new web service is the initialization of the artifacts for designing a customized sense-plan-act control loop for the included web service. Such customization artifacts consist of two files that can be browsed and edited in the control loop customization perspective. The first customization file (Figure 7-b) contains the test cases designed to reveal the occurrence of potential mismatches in the web service. Each test case is specified as a separate method, using the JUnit assertions library to signal failure or success of the test. The second customization file (Figure 7-c) contains the adaptation suite, i.e., the set of modules designed to adapt different implementations of the web service. A typical test case specification is shown in Figure 8. This test implements the test strategy Missing and misunderstood functionality for checking the persistency of remote shopping carts. In the signature of test methods we introduce the use of two new keywords onsuccessselects and onfailureselects (highlighted in the figure), which allow developers to specify the adaptation modules to be triggered when the test succeeds or fails. In the example, the success of the test case indicates a persistent cart and triggers the PersistentCartDecorator adaptation module, while a failure indicates a non-persistent cart and triggers the NonPersistentCartDecorator adaptation module. When the customization is complete, the command Generate self-adaptation builds the corresponding runtime infrastructure. The runtime infrastructure con-

20 20 G. Denaro, M. Pezzè and D. Tosi 1 public class TestCartWS extends junit. framework. TestCase { 2 ShoppingCartWebService cart =...; 3 // automatically initialized as a reference to the actual web service 4 5 public void testcartpersistency () 6 onsuccessselects PersistentCartDecorator 7 onfailureselects NonPersistentCartDecorator { 8 cart. login (" mylogin "," mypassword "); 9 int cartid =cart. CartCreate (); 10 cart. CartAdd ( cartid, " CD2 Platinum Collection "); 11 cart. logout (); 12 cart. login (" mylogin "," mypassword "); 13 try { 14 String [] cartitems = cart. CartGet ( cartid ); 15 assertfalse ( cartitems. length == 0); 16 } catch ( CartNotPersistentException e){ 17 fail (); 18 } 19 } 20 } Fig. 8. Test case for the persistence mismatch of the shopping cart WS sists of a set of automatically generated Java classes that will be compiled with the application to provide the self-adaptive behavior. 5.2 The runtime infrastructure Figure 9 illustrates the high level architecture of the typical runtime infrastructure generated by SHIWS for controlling the customized sense-plan-act control loop of a target web service. WEB SERVICE DOMAIN WS_1 WS_n CONTROL LOOP CUSTOMIZATION DOMAIN APPLICATION DOMAIN AdaptationModule_1 WSInvocation AdaptationInterface AdaptationModule_n AdaptationInterface The actual adaptation module can be dinamically selected. TestDriver selects the proper adaptation module according to the result of the test. TestSuite executes WSInterface Wrapper notifies of service implementation changes TestDriver -<from junit.framework> INFRASTRUCTURE Fig. 9. Prototype design

21 Designing Self-Adaptive Service-Oriented Applications 21 The Wrapper mediates the interactions between the application and the web service. It dynamically monitors the current service to check if it has changed since its last invocation. The Wrapper detects changes of service provider by comparing the provider details between subsequent invocations of the service, and in the implementation of the services offered by the same provider relying on version tags exported by the service. Current web services do not always provide version information, but it is reasonable to expect that the increasing use of web services will foster such good practice. The Wrapper is built automatically starting from the WSDL description of the target web service. The Wrapper delegates web service invocations to adaptation modules that are responsible for handling the adaptation of the web service. The proper adaptation module may vary for different web service implementations. The infrastructure allows for the actual adaptation modules to be selected at runtime. Moreover, the infrastructure allows adaptation modules to be composed. The adaptation modules are provided by designers in the customization phase. When the Wrapper detects a change in the service implementation, it notifies the TestDriver. This component is built automatically, based on the JUnit framework and embeds the test suite designed in the customization phase. The TestDriver runs the test cases. Based on the embedded onfailureselects and onsuccessselects logic, the TestDriver selects the adaptation modules that best fit the characteristics of the current web service. Then, it reconfigures the infrastructure to use the selected adaptation modules. 6 Preliminary Results and Lessons Learned In this section we illustrate the whole methodology with a simple example, and then we present preliminary evaluation results on a simple industrial benchmark. 6.1 The Methodology In this section, we illustrate the methodology with a simple application that provides statistical data about weather conditions, and uses web services to collect climate data in selected locations. The key service is a web service that provides the temperatures across the US. This service is invoked with the zipcode of a US location, and returns the corresponding temperature. For instance, the portal provides a demo web service of this type. Figure 10 reports the most relevant part of the WSDL description of the web service. The message tags specify two messages: the message gettemprequest that defines the parameter zipcode of type string, and the message gettempresponse that defines the parameter return of type float. The operation tag specifies the service interface that consists of the operation name gettemp, the input parameter as defined by the message gettemprequest, and the return value as defined by the message gettempresponse.

22 22 G. Denaro, M. Pezzè and D. Tosi <! -- gettemprequest message defines the input parameter zipcode --> 3 - <message name=" gettemprequest " > 4 <part name=" zipcode " type=" xsd:string " / > 5 </ message > 6 <! -- gettempresponse message defines the output parameter return --> 7 - <message name=" gettempresponse " > 8 <part name=" return " type=" xsd:float " / > 9 </ message > 10 - <porttype name=" TemperaturePortType " > 11 <! -- gettemp operation --> 12 - <operation name=" gettemp " > 13 <input message =" tns:gettemprequest " / > 14 <output message =" tns:gettempresponse " / > 15 </ operation > 16 </ porttype > Fig. 10. Excerpt of the WSDL description for the Weather-Temperature web service During the set-up phase, we identified a possible integration mismatch of type Inconsistent interpretation of parameters or value that may originate from the incompleteness of this service description. In particular, we identified the possibility of inconsistent interpretations of the return value: the service returns a floating point value that can be interpreted according to different measurement units (Fahrenheit or Celsius degrees), thus leading to possible inconsistent interpretations. In the diagnosis and adaptation phases we designed a control loop customization to overcome this mismatch. We designed a set of test cases that can reveal the reference measurement unit and a set of adapters that implement conversions between different measurement units. We distinguish Fahrenheit from Celsius degrees by sampling the temperature of locations with seasonal temperature regularities. For example, values between 9 and 45 in San Diego in summer suggest temperatures expressed in Celsius degrees, while values greater than 45 suggest Fahrenheit. Figure 11 shows the test case that implements this test strategy is the zipcode of SanDiego. The stub object TemperatureService is automatically generated by SHIWS based on the interface of the actual web service. It facilitates service invocations within the test cases, hiding the details of the SOAP protocol. The assertion verifies that the result is in the expected range. Figure 12 shows the adapters that are selected according to the result of the test. At instantiation-time, the infrastructure connects the adapters to the web service (AdapteeWS). We draw on the assumption that the client application works with Celsius degrees, thus the task of the two adapters is straightforward: AdapterFahrenheit converts values coming from the web service from Fahrenheit to Celsius degrees, while AdapterCelsius returns the unmodified result back to the application.

23 Designing Self-Adaptive Service-Oriented Applications public void testtemp () 3 onsuccessselects AdapterCelsius 4 onfailureselects AdapterFahrenheit { 5 float temp ; 6 String zipcode =" "; 7 temp= TemperatureService. gettemp ( zipcode ); 8 asserttrue (( temp >9) &&( temp <45) ); 9 } Fig. 11. Test cases generated for the temperature web service 1 2 public interface ITemperatureServiceAdaptation 3 extends ITemperatureService { } 4 5 public class AdapterCelsius implements ITemperatureServiceAdaptation { 6 private static AdapteeWS adapteews ; 7 public AdapterCelsius ( AdapteeWS adap ){ this. adapteews = adap ;} 8 9 public float gettemp ( String zipcode ) { 10 float temperature = adapteews. gettemp ( zipcode ); 11 return temperature ; 12 } 13 } public class AdapterFahrenheit implements ITemperatureServiceAdaptation { 16 private static AdapteeWS adapteews ; 17 public AdapterFahrenheit ( AdapteeWS adap ) { this. adapteews = adap ;} public float gettemp ( String zipcode ) { 20 float temperature = adapteews. gettemp ( zipcode ); 21 return ( float ) ((( temperature. floatvalue ()) -32) /1.8) ; 22 } 23 } Fig. 12. Adapters designed for the temperature web service 6.2 Preliminary Validation Results VirtualStore is a web portal for a set of e-commerce applications (hereafter called backend e-stores). VirtualStore enables the search for best offers through the catalogs of backend e-stores, provides the abstraction of a shopping cart that can collect products from different backend e-stores, and handles payments by means of credit cards to multiple backend e-stores in a single user transaction. We experimented VirtualStore with three backend applications: the e-commerce web application of Amazon; the Pet Store, a web application provided by Sun to demonstrate J2EE technology, and the Computer Store, a web application developed in our lab as an extension of Pet Store. VirtualStore manages the communication with the backend applications through a common set of web services for browsing product catalogs and handling remote shopping carts. Moreover, VirtualStore uses third-party web services for credit card validation. As for the product catalog and the shopping cart web services, we referred to interfaces compatible with the Amazon web service. (An excerpt of the referred shopping cart interface has been described earlier in this paper - see Figure 3.) As for the credit card validation we referred to available web services published

24 24 G. Denaro, M. Pezzè and D. Tosi by Imacination Software [ and TPISoftware [ The WSDL interface of this service is showed in Figure 13: it exposes the operation validatecard that takes two input parameters, the number (ccnumber of type string) and the expiry date (ccdate of type string) of the credit card, and returns a boolean result according to whether or not the credit card is valid <wsdl : message name=" validatecardreq " > 3 <wsdl : part name=" ccnumber " type=" xsd : string "/> 4 <wsdl : part name=" ccdate " type=" xsd : string "/> 5 </ wsdl : message > 6 - <wsdl : message name=" validatecardresp " > 7 <wsdl : part name=" validatecardreturn " type=" xsd : boolean "/> 8 </ wsdl : message > 9 - <wsdl : porttype name=" Validate " > 10 - <wsdl : operation name=" validatecard " parameterorder =" ccnumber ccdate " > 11 <wsdl : input name=" validatecardreq " message =" impl : validatecardreq "/> 12 <wsdl : output name=" validatecardresp " message =" impl : validatecardres "/> 13 </ wsdl : operation > 14 </ wsdl : porttype > Fig. 13. Excerpt of the WSDL description for the Credit Card Validation web service For the target categories of web services, we identified 11 possible mismatches based on the taxonomy described in Section 4.1. Next, we identified a total of 24 test cases that are able to disambiguate all mismatches. Finally, we implemented 11 adaptation modules, one for each mismatch, to satisfy the adaptation requirements. Some of the identified mismatches, test strategies, and adaptation patterns have been discussed earlier in this paper for exemplification purposes. Figures 14 and 15 summarize mismatches, test cases, and adaptation strategies for the shopping cart web services, the catalog web services, and the credit card validation web services. We run the experiments with a fixed set of backend e-stores and two credit card validation web services. In the case of dynamic discovery, we handled integration using customized control loops to connect and adapt web services of the same category. The experience with VirtualStore points out important aspects of our approach: Separation of concerns: in our approach, the adaptation issues of each web service are handled in separate modules. They are designed and developed independently of both other services and the main functionality of the client application. From a design view point, we found that extremely beneficial focusing the adaptation concerns of different web services as separate problems. Automatic generated infrastructure: much of the infrastructure for controlling the dynamics of sense-plan-act loops is automatically generated by

25 Designing Self-Adaptive Service-Oriented Applications 25 International Journal of Web Services Research, Vol.X, No.X, 200X SHOPPING CART WEB SERVICE Possible Mismatches Result for Amazon Cart capacity boundaries max 50 items Handling of multiple instances of an item in a add operations Persistence of the cart across different sessions Result for PetStore Result for Computer Store N. of Test Cases unlimited unlimited 1 supported supported supported 1 persistent non persistent non persistent 1 Adaptations a proxy that filters requests and instantiates new empty carts when needed a decorator that introduces an enhanced add operation a decorator that provides the local support for persistency Require the creation of an empty cart before adding the first item yes no no 1 a façade that reorders client invocations as required by the service Item search is mandatory before adding an item no no yes 1 a façade that reorders client invocations as required by the service Semantics of remove: yield an empty cart, dispose the cart, reduce item quantity, delete an entry reduce item quantity delete an entry delete an entry 2 a proxy that maps client invocations wrt service semantics CATALOG WEB SERVICE Possible Mismatches Result for Amazon Result for PetStore Result for ComputerStore N. of Test Cases Adaptations unsupported format of product data detailed product data, high res. image summery of product data, high res. image summary of product data, low res. image 2 a proxy that filters the returned description in a client-supported format CREDIT CARD VALIDATION WEB SERVICE Possible Mismatches Result for Imacination Result for TPISoft N. of Test Cases Adaptations supported types of cc issuers supported: enroute, American Express, JCB, Diners Club, CartBlanche, supported: American Express, JCB, Diners Club, CartBlanche, VISA, 12 a proxy that blocks non-supported cc Fig. 14. VirtualStore - Report of the Experiments Results (1/2)

26 26 G. Denaro, M. Pezzè and D. Tosi Semantics of remove: yield an empty cart, dispose the cart, reduce item quantity, delete an entry reduce item quantity delete an entry delete an entry 2 a proxy that maps client invocations wrt service semantics CATALOG WEB SERVICE Possible Mismatches Result for Amazon Result for PetStore Result for ComputerStore N. of Test Cases Adaptations unsupported format of product data detailed product data, high res. image summery of product data, high res. image summary of product data, low res. image 2 a proxy that filters the returned description in a client-supported format CREDIT CARD VALIDATION WEB SERVICE Possible Mismatches Result for Imacination Result for TPISoft N. of Test Cases Adaptations supported types of cc issuers supported: enroute, American Express, JCB, Diners Club, CartBlanche, VISA, MasertCard, Discover non-supported: 1xxx, SUN Oil, Exxon, Voyager, 9xxx supported: American Express, JCB, Diners Club, CartBlanche, VISA, MasertCard, Discover non-supported: 1xxx, enroute,, SUN Oil, Exxon, Voyager, 9xxx 12 a proxy that blocks non-supported cc decrease the credit as side effect of a validation request no no 1 a decorator that postpones validations to the end of transactions support for 3-digits security codes (cvc2) no no 1 a proxy that removes cvc2 numbers security check for multiple validation attempts no no 1 a decorator that adds local support for checking validation attempts Table 4: Report of the experiments results Fig. 15. VirtualStore - Report of the Experiments Results (2/2)

27 Designing Self-Adaptive Service-Oriented Applications 27 SHIWS. This eliminates many of the technical difficulties in the integration problem, such as, handling the communication via SOAP primitives, checking changes of the service provider or implementation, executing test cases, and activating adaptation modules as needed. Fault taxonomy support: the integration fault taxonomy guides designers through the analysis of the adaptation requirements. It works as a checklist that focuses on typical mismatches, and suggests candidate test cases and adaptation patterns. The fault taxonomy appears as the natural joint point for integrating new domain knowledge in the approach. Reusable adaptation modules: the loose dependency between adaptation modules and client applications seems to indicate that the same adaptation modules can be (at least partially) reused across applications that integrate similar web services. This suggests the possibility of designing libraries of standard adaptation modules. Tool support: the experiments show that the process of identifying mismatches, defining test cases and writing adaptation modules is well supported by SHIWS. 7 Related Work Feedback loops applied to monitoring characteristics of a computer system and also the keeping of application parameters under control, relate to recent initiatives on autonomic computing and self-managed systems [7]. In the last few years, researchers have investigated this notion in many fields having different goals and approaches. This has included self-configuring software architectures, e.g., [9] [12] [2], self-adaptive use and allocation of computing resources, e.g., [4] [10], self-healing mechanisms, e.g., [5], and programming models inspired from biology [6]. Our work exploits the ideas of autonomic computing and self-managed systems to guarantee the interoperability of clients and remote web services that can have many possible third-party implementations. Unwanted web service interactions can be monitored and diagnosed by means of assertions. For example, Baresi, Ghezzi and Guinea use assertions (in combination with orchestration languages) to monitor whether or not a web service complies to a predefined functional contract: the developers of client applications specify the expected functional contracts with suitable assertions; the assertions are checked at runtime against the responses from web services; the identified contract violations trigger the adaptation strategies, such as the selection of alternative services [1]. The approach of Baresi et al. is complementary to ours. Their approach aims to increase fault-tolerance to contract violations, while our approach allows the application to adapt to the diverse valid implementations that are underspecified elements in the service description. Assertions and testing represent complementary detection mechanisms. Testing allows to sample the service function with specific inputs that lead to diverse outcomes for each possible implementation, while assertions could fail to distinguish among the possible implementations for values that satisfy the contracts