Towards Self-Adaptive Service-Oriented Architectures G. Denaro, M. Pezz´ e, D. Tosi Universit ´ a di Milano Bicocca Dipartimento di Informatica Sistemistica e Comunicazione I-20126, Milano, Italy {denaro|pezze|tosi}@disco.unimib.it Daniela Schilling * University of Paderborn Warburgerstr. 100 33098 Paderborn, Germany das@upb.de Abstract Web services, service-oriented, and service-discovery archi- tectures help developers solve complex business cases, re- duce costs, risks, and time-to-market. The task of develop- ers is challenged by the difficulty of guaranteeing interoper- ability with target web services, since the lack of information about the interaction protocol of dynamically discovered web services may lead to unexpected runtime failures. This pa- per proposes an approach to design self-adaptive service- oriented architectures. The approach enables clients to au- tomatically adapt their behavior to alternative web services that provide compatible functionality through different in- teraction protocols. It uses an infrastructure that traces the successful interactions of the web services, automatically synthesize models that approximate the interaction proto- cols, and steer client-side adaptations at runtime. 1. INTRODUCTION Web services, service-oriented, and service-discovery archi- tectures are becoming the standard technology for enterprise application integration. Web services are self-contained remote programs that can be invoked over the Internet using standard protocols such as HTTP and XML. Service-oriented architectures are soft- ware architectures that provide new functionality based on the composition of services offered by different suppliers. Inter-service communication in the web domain is provided by web services. Service-discovery architectures are partic- ular service-oriented architectures in which the connections between service clients and providers can be dynamically established using discovery mechanisms. Figure 1 illustrates the main entities and interactions in a typical web service-based service-discovery architecture. * The research was conducted while this author was on study leave at University of Milano Bicocca, supported by the Eu- ropean Research Training Network SegraVis. 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 profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. TAV-WEB’06, July 17, 2006, Portland, Maine, USA. Copyright 2006 ACM 1-59593-458-8/07/2006 ...$5.00 A broker is responsible for matching client requests with available services published by providers. Providers publish machine-readable interface descriptions of their services to the broker using a suitable language such as the Web Ser- vice Description Language (WSDL) [10]. Clients use WSDL descriptions to look up the available services that can match their needs. Service-discovery architectures enhance flexibility and fault- tolerance of service-oriented architectures. Higher flexibility stems from the possibility of extending the set of available services without modifying the clients; fault-tolerance in- creases because providers can be dynamically and transpar- ently replaced, so that they do not represent single-points- of-failure. The Virtual Store Application Books Books Electronics Musical Inst rument s Pets Product Categories Shipping Modality Shipping Times Payment Modalit y Product Availability Service Characteristics TNT express 24 h PayPal Required SUBMIT REQUEST Find(WSDL) SERVICE BROKER SERVICE PROVIDER Publish(WSDL) Bind Co mmunication SERVICE REQUESTOR Figure 1: Main entities and interactions in a service- discovery architecture Service-discovery architectures face the difficulty of guaran- teeing the interoperability between clients and dynamically discovered services. The WSDL descriptions used for match- ing services and requests specify the service syntax and pa- rameters, but leave many semantic details implementation dependent. In particular, the sequences in which the opera- tions of a target service can be invoked (aka the interaction protocol ) is generally unspecified. Whenever a client tries to use a service with an interaction protocol different from the expected one, the interaction may fail, even if syntax and parameters are correct. Since clients may use alterna- tive (even though compatible) web services in distinct invo- cations, they may be connected to web services that work 10