% by Mirella M. Moro; version: September/23/2011 @ 05:01pm
% -- 09/03/2010: bib file with names for proceedings and journals; cls with shrinked {received}
% -- 08/27/2010: appendix, table example, more explanation within comments, editors' data

\documentclass[jidm,a4paper]{jidm} % NOTE: JIDM is published on A4 paper
\usepackage{graphicx,url}  % for using figures and url format
\usepackage[T1]{fontenc}   % avoids warnings such as "LaTeX Font Warning: Font shape 'OMS/cmtt/m/n' undefined"


%\usepackage{cite} % NOTE: do **not** include this package because it conflicts with jidm.bst

% Standard definitions
\newtheorem{theorem}{Theorem}[section]
\newtheorem{conjecture}[theorem]{Conjecture}
\newtheorem{corollary}[theorem]{Corollary}
\newtheorem{proposition}[theorem]{Proposition}
\newtheorem{lemma}[theorem]{Lemma}
\newdef{definition}[theorem]{Definition}
\newdef{remark}[theorem]{Remark}
\newenvironment{latexcode}
{\vspace{0.1in}\setlength{\parindent}{18pt}}
{\vspace{0.1in}}


% ALL FIELDS DOWN TO BEGIN{document} ARE MANDATORY

% The following data (volume, number and page) are given by the editors prior to publishing your article
\jidmVolume{3}
\jidmNumber{1}
\jidmYear{12}
\jidmMonth{February}
\setcounter{page}{1}


% Includes headers with simplified name of the authors and article title
\markboth{M. Yamashita, K. Becker, R. Galante}
{JIDM - Journal of Information and Data Management}
%  -> \markboth{}{}
%         takes 2 arguments
%         ex: \markboth{M. M. Moro}{Any article title}


% Title of the article
\title{A Flexible Approach for Assessing Service Compatibility \\ at Feature Level}


% List of authors
%IF THERE ARE TWO or more institutions, please use:
%\author{Name of Author1\inst{1}, Name of Author2\inst{2}, Name of Author3\inst{2}}
\author{Marcelo Yamashita, Karin Becker, Renata Galante}


%Affiliation and email
\institute{Universidade Federal do Rio Grande do Sul, Brazil \\ \email{\{marcelo.yamashita, karin.becker, galante\}@inf.ufrgs.br}
% IF THERE IS ANOTHER INSTITUTION:
%\and Name_of_the_second_institution \\
%\email{address@whatever.com}
}


% Article abstract - it should be from 100 to 300 words
\begin{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. 
However, providers cannot always guarantee that the necessary changes yield compatible service descriptions. 
In practice, providers describe the changes in release notes, focusing on the explicit changes, very often disregarding their cascading effects. 
Thus, typically it is the responsibility of client's developers to assess the extent of the change and their impact in their particular usage scenario. 
This paper addresses service evolution on a finer grain manner, referred to as features. 
It describes a versioning model and a compatibility assessment algorithm at service feature level, which allows the identification of changes impact points, 
and propagation effects, as well as the assessment of changes' compatibility. 
The paper also reports an experiment based on a real service, which explores the versioning model to assess the scope of implicit and explicit changes.
\end{abstract}


% ACM Computing Classification System categories
\category{H. Information Systems}{H.2 Database Management}{Miscellaneous}
% Categories and Descriptors are available at the 1998 ACM Computing Classification System
% http://www.acm.org/about/class/1998/
%  -> \category{}{}{}
%         takes 3 arguments for the Computing Reviews Classification Scheme.
%         ex: \category{D.3.3}{Programming Languages}{Language Constructs and Features}
%                   [data types and structures]
%                   the last argument, in square brackets, is optional.

% Article keywords
\keywords{Service compatibility, service evolution management, service versioning}
%  -> \keywords{} (in alphabetical order \keywords{document processing, sequences,
%                      string searching, subsequences, substrings})


% THE ARTICLE BEGINS
\begin{document}

% This is optional:
\begin{bottomstuff}
% similar to \thanks
% for authors' addresses; research/grant statements
\end{bottomstuff}

\maketitle


% ARTICLE NEW SECTION
\section{Introduction}

Services are subject to constant changes and variations, requiring appropriate strategies to support and manage multiple versions throughout their lifetime. 
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 \cite{Papazoglou08}. In order to minimize the impact on clients, a common approach to manage service versions 
from the provider perspective, is the versioning of service interface description \cite{FrankLF08}.

Service interface description exposes the service version as a \emph{contract} established by the provider, which guides clients on how to access service functionality. 
However, current notations for service interface description, including the standard WSDL/XSD, do not properly handle versioning \cite{AndrikopoulosBM11}. 
Typically, despite many service features remain unchanged (e.g. types, operations, message calls), the whole description document is versioned. This leads to 
difficulties on recognizing and measuring the actual impact of a change, especially regarding each particular usage scenario. In the absence of proper support, 
very often providers publish new versions using unique version numbers or timestamps, together with release notes documents that hopefully will help clients to 
adjust to changes (e.g. eBay, Google, Amazon). Typically, release notes describe the direct changes (e.g. changes on schema types of service calls), but fail to 
properly identify how changes propagate their effect throughout the entire service \cite{ZouFL08}\cite{FokaefsMT11}. For instance, if a change is applied to 
a type that is referenced (directly or indirectly) by an operation, then this operation is also affected by the change. As interface description versions (and 
corresponding release notes) are traditionally large documents, the task of finding whether the introduced changes impact client applications is hard, labor-intensive 
and error-prone \cite{ZouFL08}\cite{BeckerLM08}.

Service change management requires mechanisms for the identification and classification of changes in order to plan for compensatory actions for their side effects. 
Thus, service stakeholders need to \emph{quantify} the scope of changes and \emph{qualify} their impact. In other words, they need to easily identify which are the changed (or affected) 
features in a new version, if compared to previous ones, and whether these features were changed in a way clients are not broken. The need for a smaller grain of 
change representation is highlighted in different works, for purposes such as client synchronization \cite{ZouFL08}, change impact quantification \cite{WangC09}, 
accurate recognition of changes \cite{FokaefsMT11}, and usage oriented compatibility assessment \cite{YamashitaBG11}.

Compatibility is a central issue on service evolution, because its assessment can provide valuable information regarding the effects of changes on client applications 
\cite{BeckerLM08}. However, traditional compatibility approaches (e.g. \cite{FangLF07}) are also document-oriented, which means that the assessment of compatibility 
among different versions is focused on the worst-case of total service compatibility. 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 
features they provide. Works such as \cite{YamashitaBG11}\cite{PonnekantiF04}\cite{AndrikopoulosBM08} suggest the benefits of assessing compatibility in terms of 
specific client usage.

The objective of this work is to detect explicit and implicit changes between service versions in order to pinpoint incompatible changes. 
The contribution of this paper is twofold: a) it describes a feature-oriented versioning model that allows to version services, operations and types individually, 
whilst maintaining their relationships and b) a compatibility assessment algorithm for services versioned according to this model. 
The versioning model handles the structural service description from the abstract perspective of service features, 
which correspond to fragments of a service interface description document. 
This small-grained versioning model enables to locate and quantify the impact of changes, whereas the assessment of compatibility at feature level enables to qualify it.

The approach discussed in this paper lays foundation for a wide spectrum of applications in the context of service evolution. The analysis of change impact propagation, 
which is a straightforward consequence of feature-oriented versioning, allows the quantification of change impact (e.g. \cite{WangC09}). It could also support the 
automatic creation of more detailed release notes based on usage analysis, as in \cite{ZouFL08}. Compatibility assessment at feature level enables service evolution 
based on usage profiles \cite{YamashitaBG11}, reduction of provisioned versions based on proxy redirections \cite{FrankLF08}, and load balance management among 
implemented versions, which precedes the finer grain deployment in \cite{TreiberAD10}.

The remaining of this paper is structured as follows. Section 2 describes the feature-oriented versioning model, and Section 3 presents the corresponding compatibility 
assessment algorithm. Section 4 reports an experiment that explores the feature-oriented versioning model to quantify the impact of changes in a real case scenario. 
Section 5 describes related work. Conclusions and future work are addressed in Section 6.

\section{Feature-Oriented Versioning Model}

The proposed model aims at supporting the analysis of service versions on a more flexible way. As mentioned, it suits a number of different applications, but in this 
paper we focus on its contribution for measuring the scope of change and qualifying its compatibility on a finer grain manner. For this purpose, 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 (referred to as \emph{types}), which in turn may depend on other schema elements. We refer to a service and each of 
its operations and types as a service \emph{feature}. The abstract representation of features and their relationship is described in Figure~\ref{fig:abstract_service_representation}.

\begin{figure}[t]
\begin{center}
\includegraphics[scale=0.35]{imagens/abs_service_representation2.png}
\end{center}
\vspace{-20pt}
\caption{Abstract service representation}
\label{fig:abstract_service_representation}
\end{figure}

Each feature corresponds to a portion of a WSDL/XSD service description document. We propose to version features separately, and to maintain their dependency 
relationships at version level. The idea of feature versioning is to provide an abstract management to different parts of the interface description in order to 
version only the changed features, rather than the entire service. Hence, when a new service interface document is exposed, we convert it to an abstract internal 
representation, compare the descriptions of the features with regard to previously existing ones, as well as their relationship with other features, and create 
new versions only when changes occurred. As a consequence, a new service is represented by interdependent features associated to new versions, or previously existing 
ones, according to the changes. This finer-grain of service representation allows us to control the actual modified pieces of a service description, and version only 
the modified ones. 

The versioning model is depicted in Figure~\ref{fig:versioning_model} using a UML class diagram. A feature is generalization of service, operation and type. 
Each feature has at least one version, which in turn can depend on other versions of different features (for instance, an \emph{operation} may depend on a set of \emph{types}). 
Versions are uniquely identified by a pair <\emph{Feature.Name}, \emph{Version.Number}>, referenced throughout the remaining of this paper as \emph{v\scriptsize{featureName,versionNumber}}. 
The \emph{Version.Description} attribute corresponds to the textual description of the WSDL document, according to the feature type. 
The compatibility between two versions of a same feature is also maintained and assessed, as described in more details in Section 3.

\begin{figure}[b]
\begin{center}
\includegraphics[scale=0.5]{imagens/versioning_model.png}
\end{center}
\vspace{-10pt}
\caption{Versioning Model at Feature Level}
\label{fig:versioning_model}
\end{figure}

\subsection{Feature Level Representation}

We have established the following correspondence between the textual WSDL/XSD service representation and the proposed feature-oriented version model:

\begin{itemize}
	\item \emph{Operation}: related to the content of the tag <\emph{operation}> within both <\emph{portType}> and <\emph{binding}> tags;
	\item \emph{Type}: related to the content of tags <\emph{element}>, <\emph{complexType}> or <\emph{simpleType}> within <\emph{schema}> tag or the content of <\emph{message}> tag. 
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. 
Consequently, we do not version neither primitive types (e.g. string, double, etc), nor complex types that cannot be referenced elsewhere.
	\item \emph{Service}: related to all the remaining content of the interface description document, such as the <\emph{service}> tag and the remaining content of <\emph{schema}>, 
<\emph{portType}> and <\emph{binding}> tags.
\end{itemize}
 
\begin{figure}[t]
\begin{center}
\includegraphics[scale=0.43]{imagens/WSDL_fragments_v3.png}
\end{center}
\vspace{-10pt}
\caption{Example of a WSDL 1.1 description and the proposed representation}
\label{fig:wsdl_fragments}
\end{figure}

This mapping was developed considering WSDL 1.x, but it could be adapted to the more recent WSDL 2.0 with smaller changes. 
We illustrate in Figure~\ref{fig:wsdl_fragments} the manner we map the fragments of a WSDL 1.6 description to the proposed representation, using the \emph{StockQuote} service\footnotemark[1].
We separate the description of Figure~\ref{fig:wsdl_fragments}(i) into fragments to represent the service, its operation and types. 
The result of this fragmentation is a rooted graph containing the features versions (Figure~\ref{fig:wsdl_fragments}(ii)). 
Each feature version is associated with a corresponding description, such the examples in Figures~\ref{fig:wsdl_fragments}(iii), 
~\ref{fig:wsdl_fragments}(iv) and ~\ref{fig:wsdl_fragments}(v).
\footnotetext[1]{\url{http://www.w3.org/TR/wsdl#_wsdl}}

\subsection{Versioning the features of an interface description document}

In order to version the features of a WSDL description document, we need to identify the features within the document, relate them to the appropriate versions, 
possibly by creating new versions in this process, and store this abstract representation in a repository. This requires two steps: a) the conversion of the interface 
description document to the finer granulated perspective of features, and b) the analysis of the features in order to discover whether they have changed regarding 
all their previous representation in the repository.

We intend to version only explicitly changed features, or features that are indirectly affected by the changes. 
By \emph{changed} we refer to a feature that either has its description fragment changed somehow, depends on feature it did not previously depended on, or, 
conversely, no longer depends on a feature it previously depended on. 
By \emph{affected} we refer to a feature that did not explicitly changed, but depends on a feature that has changed. 

First, we convert the interface description document (e.g. Figure~\ref{fig:wsdl_fragments}(i)) to the feature level representation, which results in a graph representing 
the features' versions and their dependency relationships (e.g. Figure~\ref{fig:wsdl_fragments}(ii)). For each feature, we analyze its correspondent in the repository in 
order to compare to existent versions. The analysis is done in a bottom-up manner regarding the graph of features in order to properly verify dependencies changes. 
The analysis leads to four possibilities:

\begin{itemize}
	\item If the feature does not exist, then it is created together with its first version.
	\item If the feature already exists (it was previously versioned) and its description differs from all existing versions of this particular feature, then it 
is marked as changed in the graph and a new version for this feature is created.
	\item If the feature already exists and its description is equal to an existing version:
\begin{itemize}
	\item If it depends on another feature that has been already marked as changed, then a new version is created due propagation effects.
	\item If it does not depend on any changed feature, then every other feature that depends on this one is referenced to an already existing (equal) version.
\end{itemize}
\end{itemize}

\begin{figure}[b]
\begin{center}
\includegraphics[scale=0.5]{imagens/versions_v3.png}
\end{center}
\vspace{-10pt}
\caption{Example of versioning StockQuote}
\label{fig:versions_graph}
\end{figure}

To illustrate the idea of feature versioning, suppose a provider exposes the interface description for the first version of \emph{StockQuote} 
service as depicted in Figure~\ref{fig:wsdl_fragments}(i). 
We convert the interface description to the feature level representation and version them, such that each feature is associated 
with its first version (Figure~\ref{fig:wsdl_fragments}(ii)). 
Suppose now that the provider exposes a new interface for this service that has two major changes: 
a) a new operation with related types exchanged in messages, and b) changes the type of an existing feature. 
For the later, suppose that the primitive type associated with \emph{TradePrice} is changed from \emph{float} (Figure~\ref{fig:wsdl_fragments}(v)) to \emph{double}. 
This new description is converted to the feature representation, and the change in \emph{TradePrice} description is identified. 
So a new version is created, and associated with this feature. 
By propagation, features \emph{GetLastTradePriceOutput}, \emph{GetLastTradePrice} and \emph{StockQuote} are affected, and hence equally versioned. 
In addition, features, together with the respective versions, are created for the new operation \emph{GetBestOffer}, 
which in turn depends on the newly created features \emph{GetBestOfferInput} and \emph{GetBestOfferOutput}. 
These in turn depend on other features, which either previously existed (\emph{TradePrice}) or need to be created (\emph{BestOffer}, \emph{StatusType}). 
The resulting version graph is depicted in Figure~\ref{fig:versions_graph}. 

\section{Compatibility Assessment}

The algorithm proposed in this paper aims to assess compatibility between any two versions of a service, which implies examining the compatibility considering all 
the features that describe the service. The assessment of compatibility at feature level relies on the compatibility detection algorithm proposed in \cite{BeckerLM08}, 
which assesses compatibility on object-oriented service descriptions. We have adapted this algorithm to address the compatibility on smaller fragments of the WSDL 
interface description, as represented by our feature-oriented versioning model.

Very few changes are backward-compatible, basically, the addition of new operations, and types that are not referenced by existing operations and types 
(\cite{AndrikopoulosBM11}\cite{BeckerLM08}\cite{FangLF07}\cite{BrownE04}). For this paper we consider the change cases depicted in Table~\ref{table:change_cases}, 
which translate the core cases found in the literature into change operations in our versioning model.

%\begin{center} 	% TABLES SHOULD BE CENTERED
\begin{table}[b]% TABLES SHOULD BE AT THE TOP [t] OR BOTTOM [b} OF PAGES
	\caption{Change cases for version compatibility} % ALWAYS INCLUDE CAPTIONS IN YOUR TABLES
	\label{table:change_cases} % USE THE CONTENT WITHIN label FOR REFERENCING IT (USE \ref WITHIN THE TEXT)
\sffamily % CHANGES THE FONT WITHIN THE TABLE TO sans serif
\begin{tabular}{c|c|c|c|c}
\hline
\emph{Cases} & \emph{Change} & \emph{Feature Type} & \emph{Description} & \emph{Compatibility Verdict} \\ \hline
1 & Add & Operation & Add new operation to a service & \emph{Compatible} \\ \hline
2 & Add & Type & Add new type as dependency of a new operation/type & \emph{Compatible} \\ \hline
3 & Add & Type & Add new type as dependency of an existent operation/type & \emph{Incompatible} \\ \hline
4 & Update & Type & Change in description due to order, cardinality or type & \emph{Incompatible} \\ \hline
5 & Remove & Operation & Remove operation dependency & \emph{Incompatible} \\ \hline
6 & Remove & Type & Remove type dependency & \emph{Incompatible} \\ \hline
\end{tabular}
\rmfamily % RESTORES TO TIMES, SO THAT CAPTION IS WRITTEN PROPERLY
\end{table}
%\end{center}

The algorithm, aims to recursively evaluate the compatibility relationship between two feature versions according to the rules of Table~\ref{table:change_cases}, 
and to establish the compatibility relationship between them, with the corresponding verdict (Figure~\ref{fig:versioning_model}). 
The pseudo-algorithm is presented in Listing 1. 
It receives two feature versions as input, \emph{v\scriptsize{feature,p}} and \emph{v\scriptsize{feature,q}}, and assess the compatibility of the later with regard to the former. 
We assume that both versions relate to the same feature (i.e. have the same name). 
The algorithm verifies if dependencies of features present in \emph{v\scriptsize{feature,p}} have not been removed from \emph{v\scriptsize{feature,q}} (line 2), 
compare the description fragment associated with the compared versions (line 3), and then recursively evaluates the compatibility of all 
corresponding dependent feature versions (lines 4-9), when it finally sets the compatibility relationships and verdict (line 10). 
The version graph rooted \emph{v\scriptsize{feature,q}}, is traversed in a depth-first manner, which enables the propagation of detected incompatibilities to dependent versions.

The first step of the algorithm (line 2) aims to evaluate whether feature dependencies were removed from \emph{v\scriptsize{feature,q}} compared to \emph{v\scriptsize{feature,p}}. The function 
\emph{evaluateRemovedDependencies} verifies if all features in the set of dependencies of \emph{v\scriptsize{feature,p}} still exist in the set of dependencies of \emph{v\scriptsize{feature,q}}. 
If it detects a removed dependency, then versions \emph{v\scriptsize{feature,p}} and \emph{v\scriptsize{feature,q}}  are incompatible due to cases 5 and 6 of Table~\ref{table:change_cases}. 
The algorithm also evaluates the textual description associated with versions \emph{v\scriptsize{feature,q}} and \emph{v\scriptsize{feature,p}}. The description evaluation is detailed in Listing 2.

Then, the algorithm traverses all features upon which \emph{v\scriptsize{feature,q}} depends in order to assess their compatibility against the corresponding ones in the dependency set of 
\emph{v\scriptsize{feature,p}}. For all dependencies of \emph{v\scriptsize{feature,q}} (line 4), if there is a dependency in \emph{v\scriptsize{feature,p}} with the same feature name and different version number (line 5), 
then the algorithm is called recursively to assess the compatibility of these two versions (line 6). If any dependency is incompatible, then the algorithm updates the 
verdict to incompatible due to propagation effects. If there is a dependent version of \emph{v\scriptsize{feature,q}} that does not exist in \emph{setOfDependencies}(\emph{v\scriptsize{feature,p}}), 
then this situation is related to the compatible cases 1 and 2 of Table~\ref{table:change_cases}.
Finally, the algorithm returns the compatibility assessment of \emph{v\scriptsize{feature,q}} regarding \emph{v\scriptsize{feature,p}}. 
Notice that the algorithm could stop at any point where incompatibility is detected, but we have opted by continuing the assessment as a placeholder 
for later documenting all incompatible changes found.  

\begin{figure}[t]
\begin{center}
\includegraphics[scale=0.6]{imagens/listing01.png}
\end{center}
\vspace{-10pt}
\label{lis:listing01}
\end{figure}

\begin{figure}[b]
\begin{center}
\includegraphics[scale=0.6]{imagens/listing02.png}
\end{center}
\vspace{-20pt}
\label{lis:listing02}
\end{figure}

Function \emph{evaluateDescription} (line 3 in Listing 1), detailed in Listing 2, aims at verifying the remaining incompatible cases of Table~\ref{table:change_cases}, namely cases 3 and 4. 
It receives as input the versions of a same feature \emph{v\scriptsize{feature,p}} and \emph{v\scriptsize{feature,q}} and check if their descriptions are different (line 2), assuming incompatibility, 
except in the case of type features, when a more detailed examination of the description field is performed (lines 3-16). 
In the future we plan for studying less restrictive compatibility. 
For instance, adding a new optional type at the end of a complex type sequence can be compatible if it is an input message \cite{BeckerLM08}\cite{AndrikopoulosBM11}.

In order to extract the description elements and their properties from the WSDL fragments we use the function \emph{setOfElements}, 
which parses the excerpt of WSDL corresponding to the description field. 
The algorithm verifies if there is any added element in \emph{v\scriptsize{feature,q}} regarding  \emph{v\scriptsize{feature,p}} (line 5), 
which leads to the verification of case 3 of Table~\ref{table:change_cases}. 
Next, if the element exists within the two versions we compare their properties (line 7) in order to verify if they have changed. 
The comparison of element properties refers to case 4 of Table~\ref{table:change_cases}. 
Removed description elements are verified in lines 11 to 15. 
Finally, it returns the compatibility verdict for \emph{v\scriptsize{feature,q}} regarding \emph{v\scriptsize{feature,p}}.

\section{Experiments}

We have implemented a prototype for versioning services at feature level, which identifies explicit changed features and affected ones in order to version them. 
The prototype also generates a report listing the changed and affected features.
Our goal is to compare this report with the provider's release notes in order to understand the actual lack of information clients' developers deal with when adapting their applications.

For this experiment we chose eBay \emph{Trading} service \footnote[2]{\url{https://www.x.com/developers/ebay/products/trading-api}}. 
eBay introduces a new version of this service every two weeks and supports each version for at least 18 months. 
For each version, there is a release notes entry on eBay website that reports the explicit points of change with regard to the previous version. 
However, there is no information on how these changes affect other parts of the service. 
The manual analysis of propagation effects is a hard task since the interface document is huge (e.g. the most recent version of Trading service has almost 130.000 lines). 
Thus, client developers are responsible for detecting whether changes affect their applications.

We used for this experiment the 41 versions of \emph{Trading} service currently supported by eBay. 
As our goal was to analyze structural changes, we removed all semantic information (e.g. documentation tags) from the service interface documents. 
We used the oldest available version (653) as baseline, and quantified the explicit and cascaded changes of each new service version with regard to 
the previous one by counting the newly created versions. 
Recall that each new version corresponds to a feature that was changed or affected. The results are displayed in Figure~\ref{fig:change_analysis}.

We verified that all changed features made explicit due to our versioning model are described in the release notes, but none of the affected ones are mentioned. 
Explicitly changed features correspond in total to less than 5\% of the overall detected changes, which means that more than 95\% of changes are not addressed in the release notes. 
For instance, version 659 has introduced a single explicit change on a type feature, which is reported in the release notes \footnote[3]{\url{http://developer.ebay.com/Devzone/XML/docs/WebHelp/ReleaseNotesArchive.html#659}}. 
However, this change affects 36 operations and 100 types that depend on it directly or indirectly, and which are not covered by the release notes.

We also verified that 99\% of explicitly changed features are done to types, whereas the propagation effects reach an average of 26\% for operations and 74\% for types. 
This indicates that a change is typically done to a type, and in most cases it is not directly propagated to an operation. 
Instead, its effects cascade through several types until it affects an operation.

\vspace{10pt}
\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.55]{imagens/experiments_v2.png}
\end{center}
\caption{Change analysis of eBay Trading service interface versions at feature level}
\label{fig:change_analysis}
\end{figure}

This experiment confirms that current information provided by release notes is insufficient for client developers to detect which changes affect them, 
and in which way, in order to rapidly being able adequate their applications to evolutionary changes of services. 
We conclude that the proposed versioning model supported the efficient identification and quantification of changes impact. 
Moreover, the further implementation of the compatibility assessment algorithm can support a more efficient analysis of change impact by qualifying changes and their effect in each feature.


\section{Related Work}

Current approaches on service evolution address service versioning and service compatibility, in order to achieve some degree of conformance and/or transparency during evolution. 
Common approaches for service versioning include the use of XML namespaces for each version that potentially breaks the client; 
version identifiers for unambiguously naming versions; or a combination of these \cite{BrownE04}\cite{AndrikopoulosBM11}. 
However, all these approaches address the versioning of the entire interface description document, 
which leads to difficulties on measuring the actual impact of a change between versions \cite{ZouFL08}\cite{FokaefsMT11}, particularly regarding compatibility. 
\cite{BeckerLM08} proposes a finer-grain versioning model based on the object-oriented paradigm, but which does not fit W3C current standards. 
\cite{AndrikopoulosBM11} proposes an abstract model for the description of services, which details all its components, 
but it is targeted at verifying formally the compatibility of service interface versions, and which does not address versioning itself. 

Different works express the need for the easy change impact. 
\cite{ZouFL08} proposes a service delta analyzer to detect explicit changes between service versions, in order to produce customized release notes. 
\cite{WangC09} proposes a dependency model to detect and quantify explicit and implicit changes in order to measure change impact, but does not enable the assessment of compatibility.
\cite{FokaefsMT11} presents an alternative method for change detection based on edition distance and clustering. 
However, current approaches do not address the assessment of compatibility in a finer-grain.

Works such as \cite{BrownE04}\cite{FangLF07}\cite{BeckerLM08}\cite{AndrikopoulosBM11} discuss compatibility rules, i.e. change operations that do not break client application. 
\cite{BeckerLM08} addresses the automatic assessment of compatibility but it targets on classes that represent service descriptions. 
\cite{PonnekantiF04} addresses compatibility on a finer-grain but restricted to the perspective of a particular client application usage. 
\cite{YamashitaBG11} suggests the benefits of compatibility assessment on a finer-grain by considering compatibility against specific usage profiles.

The work described in this paper contributes to the above work by the versioning of services in a finer-grain manner, i.e. at feature level. 
In doing so, we can identify explicit changes, analyze their propagation effects within the feature level proposal and assess compatibility on specific feature versions. 
Consequently, we can both quantify the scope of changes and qualify their impact. 
The result of this work supports various applications, such as the service evolution based on usage profiles \cite{YamashitaBG11}, 
reduction of provisioned versions based on proxy redirection \cite{FrankLF08}, and enables load balance management among implemented versions, 
which precedes the finer-grain deployment in \cite{TreiberAD10}.


\section{Conclusion}

We presented a versioning model and compatibility assessment algorithm for supporting evolution on a finer grain than the typical service description WSDL/XSD documents. 
The approach enables to easily identify which are the changed (or affected) features in a new service version, and whether these features were changed in a way 
client applications are not broken. Hence, we address the identification of impact points, propagation effects, and the qualification of changes. 
We have experimented our feature-oriented versioning model using a real service, and were able to demonstrate its usefulness for pointing out the changes 
performed in a service description, particularly if compared to the release notes. 
The approach also 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 \cite{FrankLF08}\cite{TreiberAD10}\cite{ZouFL08}\cite{YamashitaBG11}.

We have prototyped an implementation for versioning service descriptions according to our model, 
and currently we are concluding the implementation of the compatibility assessment algorithm. 
Future work will integrate the versioning model and compatibility assessment algorithm into the framework designed for usage profiles analysis presented in \cite{YamashitaBG11}. 


	
% INCLUDE BIBLIOGRAPHY WHICH MUST FOLLOW jidm.bst TEMPLATE
\bibliographystyle{jidm}
\bibliography{jidmb}
% For information on how to write bibliography entries, 
% see file jidmb.bib

\begin{received}
\end{received}


\end{document}
