A Flexible Approach for Assessing Service Compatibility at Element Level

Transcription

1 153-1 A Flexible Approach for Assessing Service Compatibility at Element Level Marcelo Yamashita, Karin Becker, Renata Galante Instituto de Informática - Universidade Federal do Rio Grande do Sul Porto Alegre, RS - Brazil {marcelo.yamashita, karin.becker, galante}@inf.ufrgs.br Abstract. Service evolution requires sound strategies to appropriately manage versions resulting from changes during service lifecycle. Compatibility addresses the graceful evolution of services by considering the effects of changes on client applications. Traditionally, compatibility assessment is restricted to the worst-case scenario, because the analysis is based on the documents that describe service properties (e.g. WSDL and XSD files). However, such compatibility may not be representative of the real impact on clients, because a non-compatible change may affect a not used element, such as the type of an optional parameter or an unused operation. This paper addresses service evolution on a finer grain fashion. We propose a versioning model and a compatibility assessment at element level in order to identify the impact points, propagation effects and categorization of changes on service elements during evolution. This approach provides important information for supporting service evolution by either maximizing version reusability (e.g redirecting of requests, overload balancing, etc.) and/or pinpointing the change impact points that basis approaches such as usage based analysis. Categories and Subject Descriptors: H. Information Systems [H.m. Miscellaneous]: Databases Keywords: Service evolution management, service versioning, version compatibility 1. INTRODUCTION Services are subject to constant changes and variations, requiring appropriate strategies to support and manage multiple versions during their lifetime [Papazoglou 2008]. Service evolution management encompasses the creation, maintenance and decommission of different versions in a service provider environment, which leads to the maintenance of several concurrent versions [Papazoglou 2008]. Provisioning multiple versions of a same service can impose serious burdens and costs on service providers, who need mechanisms to manage versions in a graceful and unambiguous fashion [Andrikopoulos et al. 2008, Yamashita et al. 2011]. In order to minimize impact on clients, a common approach to manage service versions from the provider perspective, is the versioning of service interface description [Frank et al. 2008, Becker et al. 2008]. Service interface description exposes the service version as a contract established by the provider that guides clients on how to access the service functionality. Despite guiding clients on the appropriate manner to acquaint with services, traditional interface description documents, including the dominant WSDL and XML-based notations, do not handle versioning constraints [Ebay 2011]. Existing approaches address service versioning by using concepts such as compatibility to achieve some degree of conformance and/or transparency during evolution [Frank et al. 2008, Andrikopoulos 2010]. Compatibility is a central issue on evolving services, because its assessment can provide valuable information regarding the effects of changes on client applications [Yamashita et al. 2011]. Traditional compatibility approaches are focused on documentoriented compatibility, which means that the assessment of compatibility among different versions is 105

2 153-2 focused on the worst-case of total compatibility. A document that describes a changed service interface (e.g. WSDL, XSD) contains several different elements that are unaltered wit h regard to the previous description, but yet versioned as a set of elements in a new document version. This leads to difficulties on measuring the actual impact of a change, especially regarding the service usage. [Becker et al. 2008] proposed a versioning framework based on a smaller grain of service description (classes that describe a service), but still bound to the documents that described each class. The need for a smaller grain of change representation is highlighted in [Zou et al. 2008], which aims at generating personalized release notes for each service client in the event of a new version. The approach is based on the identification of the specific elements that have changed, and the confrontation with clients usage logs. Change management requires mechanisms for the identification and classification of changes in order to plan compensatory actions for their side effects. During service evolution, changes may occur on specific parts of the service, which reflects on a new service version. Changes applied to an element can propagate their effects to either the same element on previous versions and/or elements that depend on it. For instance, if a change is applied to a type that is referenced (directly or indirectly) by an operation, then this operation can potentially be affected if the change is incompatible. Establishing compatibility relationship between service versions does not necessarily capture the (in)compatibility impact of the change, because client applications are not bound to the whole service as described by the interface, but rather to specific functionality they provide. For instance, clients may use a fraction of the available operations, and the exchanged messages may not contain all available data described (e.g. optional elements in data types) [Zou et al. 2008, Yamashita et al. 2011]. This paper focuses on a more flexible approach to handle service versions in order to asse ss compatibility at service element level. We define service elements as abstract elements of a service representation (e.g. operation, type), which correspond to fragments of description in a service description document. To achieve compatibility at element level, we propose a versioning model to handle the structural service description from the abstract perspective of service elements. By doing so, we present an abstract versioning model and repository, and an algorithm to assess compatibility among the versioned service elements. 1.1 Application Scenarios The application scenarios are motivated by the need to deal with service evolution with regard to finer grainer granularity, particularly, the service element evolution. The first scenario illustrates the need of our current work [Yamashita et al. 2011] for assessing compatibility among service operations. The second and third scenarios depict the environment of a service provider, which deals with the provisioning for several versions of a same service and their management. Usage-Based Evolution. In Usage-Based Evolution, as pointed out in [Yamashita et al. 2011], the provider strives for evolving services with regard the usage of client applications for each version of a provided functionality (e.g. operation). This approach aims at measuring the impact of changes with regard the trade-off between its effect and its usage. In such approach, the assessment of compatibility is vital to derive an effective measure to represent the actual impact of changes on client applications. Load Balance Management of implemented versions. As pointed out in [Treiber, 2010], service providers need to deal with the problem of requests overload to implementation versions. [Treiber, 2010] addresses this issue with a fine-grained deployment approach for services, which generates customized implementation versions to accommodate and balance requests using behavioral modules. By versioning and assessing the compatibility at element level, we address the same issue just by redirecting the request to an already existent and compatible implemented version. 106

3 153-3 Reducing the provisioned versions. As addressed in [Frank et al. 2008], the provisioning of multiple versions of a same service can be improved by assessing compatibility among existing versions in order to reduce the number of maintained versions and thus, the cost of maintenance. For instance, versions that have their service elements assessed as compatible regarding others can have their requests mapped/redirected to the compatible versions, which leads to the decommission of the first without any impact to the client. Since [Frank et al. 2008] regards the versioning of entire service versions his approach addresses the storage of operations compatibility in a proxy configuration table, which in our approach is straightforward. The above application scenarios require strategies to deal with compatibility on the service element level. Despite the proposal of service evolution centered on its elements have emerged from a particular scenario, its application can cover different and actual scenarios indicating its alignment with the current challenges of service evolution. The remaining of this paper is structured as follows: in section 2, we present our versioning model and repository. In section 3, we present compatibility assessment algorithm at functionality level. In section 4, we present the related works. Finally, section 5 concludes the paper with a perspective of future contributions. 2. VERSIONING MODEL The proposed model aims at supporting the analysis of service versions on a more flexible way, because it permits the analysis of compatibility on a finer grain fashion. In order to do so, we characterize a service as a composition of operations that can be accessed by client applications. These operations are bound to a particular format (order and type of input/output parameters), which is usually defined by schema elements that may depend on or be composed by other schema elements. We refer to schema elements as Types to maintain consistency with service interface dominant notations (WSDL 1.1/2.0). The abstract representation of service elements and their relationship is described in Fig. 1. Every service element version has a corresponding description within the document that describes the service interface version. Thus, when a new service interface version is exposed, we convert it to an abstract internal representation. This finer-grain of service representation allows us to control the actual modified pieces of a service description, and version only the modified elements. So, when a new service interface description becomes available, whenever a service element description is modified, then the service element is versioned with its new description. Notice this conceptual view of a service is relatively independent of service description notation (e.g. WSDL 1.1 or WSDL 2.0). In order to maintain reliability when mapping service elements, we illustrate in Table 1, the correspondence between the service representation of Fig. 1 and the dominant notations for service interface description to secure that every element of the service description is addressed. The idea of service element versioning is to provide an abstract management to different parts of the interface description in order to version only the changed service elements rather than the entire service. By doing so,we need to comprise in the versioning model the elements and relationships of the service element representation (in Fig. 1). The versioning model is depicted in Fig. 2. Fig. 1: Abstract service interface representation 107

4 153-4 Table I: Service element correspondence on dominant description approaches Service elements WSDL 1.1 elements WSDL 2.0 elements Service (is composed by) Operation (is composed by) Type (refers to) WSDL Definition WSDL Service Port WSDL Service Binding Signature WSDL PortType Signature XSD Signature WSDL Operation Signature WSDL Related Binding Signature XSD Simple Elements XSD Enumeration Elements XSD Complex Elements WSDL Messages (if needed) WSDL Description WSDL Service Endpoint WSDL Service Binding Signature WSDL Interface Signature XSD Signature WSDL Operation Signature WSDL Related Binding Signature XSD Simple Elements XSD Enumeration Elements XSD Complex Elements To support element versioning, we address service elements as a generalization of services, operations and types. Service elements are identified by a Name and an ItemType, which correspond to the kind of the element it represents. Each service element has at least one version, which in turn can depend on or be dependent of other versions (of different service elements). A version is identified by a Name and a Version number, and is associated with the current maintenance State within the provider environment. The Description attribute regards the part of the service interface description that the functionality refers to (e.g. and excerpt of a WSDL/XSD file). The dependency relation among versions of different elements aims to maintain the cohesion of relationships defined in Fig. 1, as well as specify some important information that could reflect on incompatibility propagation. Hence, a version dependency has a Name and Version number to the service element version it depends on and the type of dependency (DepType), for instance the output parameter of an operation. When addressing types, we only consider for versioning the ones defined outside the context of XSD complex elements, which means that we version only types meant for reuse. However, nonversioned XSD simple elements are considered as part of XSD complex elements description in order to permit further compatibility assessment. Fig. 2: Versioning model 108

5 153-5 The compatibility relation is a metric to assess whether different versions of the same element can potentially cause any impact to the context within which the service operates if one version is replaced with the other. While dependency relation regards the versions of different elements the compatibility relation addresses different versions of a same element. The assessment of compatibility among versions is described in details in section Incorporating an interface description version To support the element versioning model, we propose a repository that incrementally stores the new versions and builds the relationships with regard to the unchanged service elements. In order to compose the repository we need to go through the following steps to import the service interface description versions, as illustrated in Fig. 3. In the first step, we identify the service elements in the interface description document and create their abstract representation into a repository model assuming the bottom-up dependency hierarchy from Fig. 1 (types operations service). In this moment, we identify and build up the dependencies among the service elements and import their description as it is in the interface description version. Next, we compare every service element to its corresponding versions in the repository to assess for changes of any kind. In order to assess for propagation changes, the comparison of versions results on marking the service element on the pre repository version. After that, a propagation analysis is executed to verify the versions that will be imported. These lead to four possibilities for versioning the new service element: If the service element does not exist, then it will be created with its first version. If the service element already exists, but the version in analysis differs from all existing versions, then it is assessed as changed and a new version is created in the repository. If the new version has its description equal to an existing version. If it depends on another service element that has been already assessed as changed, then its new version is created due propagation effects. If it does not depend on any changed service element, then every other element (in analysis) that depends on this one is referenced to an already existing (equal) version in the repository. Finally, the repository is updated with the new service element versions. To illustrate the idea of service element versioning, suppose the repository has a service version S' that depends on the operation OP1' and OP2', which in turn depends on the types TP1' and TP2', respectively. The S' version is illustrated as a dependency tree in Fig. 4 (a). Suppose then, the provider exposes a new interface description version S'' (Fig. 4 (b)), which modifies the parameters of the operation OP2', described by TP2' to a new version TP2''. After comparing S'' with S', we assess that TP2'' is different from TP2', but every other element is equal to its previous version in S'. On Fig. 3: Incorporating the service interface description versions 109

6 110

7 111

8 153-8 [Andrikopoulos et al. 2008, Yamashita et al. 2011]. In order to minimize impact on clients, a common approach to manage service versions from the provider perspective, is the versioning of service interface description [Frank et al. 2008, Becker et al. 2008], which exposes the service version as a contract established by the provider that guides clients on how to access the service functionality. Current approaches on service evolution address service versioning in addition to concepts such as compatibility in order to achieve some degree of conformance and/or transparency during evolution. These can be divided into preventive approaches, which establish practices to evolve services while maintaining compatibility e.g. [Papazoglou 2008, Becker et al. 2008]; or corrective, which aim at adapting the service stakeholders to the incompatible changes as they occur [Andrikopoulos 2010]. Corrective approaches include client notification [Fang et al. 2007] and synchronization [Zou et al. 2008], functionality mapping and message redirection e.g. [Frank et al. 2008], message and deployment adaptability e.g. [Treiber et al. 2010]. However, current approaches address the versioning of the entire interface description, which leads to difficulties on measuring the actual impact of a change, especially regarding the service usage. This research is positioned within the corrective approach. We propose the versioning of service interfaces on finer grain fashion, which allows a more flexible manner on analyzing compatibility. For instance, this research can make more flexible the analysis of compatibility for message redirection, e.g. [Frank et al. 2008], which in turn can enhance other corrective approaches such as [Treiber et al. 2010]. Specifically, the element-centric versioning approach basis our current work [Yamashita et al. 2011] that aims to compare incompatible operations against their usage in order to derive impact metrics. 5. CONCLUSION We presented a versioning model and compatibility assessment algorithm for supporting evolution on a finer grain fashion. In summary, we aim to answer what are the incompatible service elements between two service versions. Hence, we address the identification of impact points, propagation effects, and categorization of changes. This approach provides important information for supporting service evolution by either maximizing version reusability (e.g redirecting of requests, overload balancing, etc.) and/or pinpointing the change impact points that basis usage based approaches. We have prototyped an implementation for incorporating service description versions into a repository that conforms with the proposed versioning model. The algorithm for compatibility assessment at functionality level is on implementation phase. Future work will address the scenario of change analysis based on usage profiles and the impact of changes on them. Once we know what are the incompatibilities between two versions, we aim to confront these information with usage profiles in order to better understand the actual impact for a change. REFERENCES ANDRIKOPOULOS V. BENBERNOU S. PAPAZOGLOU M. Managing the Evolution of Service Specification. CAISE, pp ANDRIKOPOULOS V. A Theory and Model for the Evolution of Software Services. PhD Thesis, ISBN BECKER K. LOPES A. MILOJIC D. ET AL. Automatically Determining Compatibility of Evolving Services. ICWS, pp EBAY. ebay Developers Program. Accessed on: developer. ebay.com on Jun/2011. FANG. R. LAM L. FONG L. ET AL. A Version-aware Approach for Web service Directory. ICWS, pp FRANK D. LAM L. FONG L. ET AL. Using an Interface Proxy to Host Versioned Web services. SCC, pp PAPAZOGLOU M. The Challenges of Service Evolution. CAISE, pp TREIBER M. ANDRIKOPOULOS V. DUSTDAT S. Calculating Service Fitness in Service Networks. ICSOC, pp YAMASHITA M. BECKER K. GALANTE R. Service Evolution Management based on Usage Profile. ICWS, ZOU Z. FANG R. LIU L. ET AL. On Synchronizing with Web service Evolution. ICWS, pp