related-work.tex

%!TEX root=paper.tex

\section{Related Work}
\label{sec:related}

% testing... the performacen
% there is plenty of work on testing for finding fauls
% people: https://scholar.google.nl/citations?user=DWd972sAAAAJ&hl=en&oi=ao


A rich body of work exists that studies the evolution and maintenance of APIs from the perspective of source code evolution \cite{dig2006apis, hora2015developers, hora2015apiwave}. However, since services are increasingly being used across a variety of systems in which adaptability, flexibility, and environmental awareness are essential~\cite{pernici2016monitoring} in our work we focus on the analysis of the runtime aspects of service APIs. Our work is thus, more related to the work on dynamic analysis of software systems; however, most of this work has been done in order to support the reverse engineering and enhance the understanding of software systems\cite{Corn09-dynamic}. 

In this context, our work falls within the server-side run-time monitoring of services ~\cite{ghezzi2007run}. 
% While we don't implement the more advanced features of related monitoring solutions like QoS policies driving the monitoring, it presents nevertheless an easy to use approach towards improving the performance of web applications.
There is a long tradition of using visualization for gaining insight into software performance. Tools like Jinsight \cite{Pauw02a} and Web Services Navigator \cite{Pauw05} pioneered such an approach for Java and for Web Services that communicate with SOAP messages. More recent tools present live visualizations for monitoring multiple interacting software systems utilizing the city metaphor for each software system \cite{fittkau2013live}. All these approaches have an ``omniscient'' view of the services / objects and their interactions. As opposed to them, in our work we present an analytics platform which focuses on monitoring a single Python web service from its own point of view. 

Kieker -- has been presented by Rohr et al \cite{Rohr08} as a system targeted at monitoring the performance of Java services. The system provides better performance in terms of overhead with respect to ours, but does not support integration with git and multi-version analysis as the system presented here. 

Similar to our discussion on pre-emptive monitoring, Cito et al. \cite{cito2015runtime} argue for bringing performance measurements back in the IDE to provide the developers with such information during the development process.

In their work Baresi and Guinea have proposed the Multi-layer Collection and Constraint Language (mlCCL) which allows them to define how to collect, aggregate, and analyze runtime data in a multi-layered system. They also present ECoWare, a framework for event correlation and aggregation that supports mlCCL, and provides a dashboard for on-line and off-line drill-down analyses of collected data \cite{Bare13-monitoring}.

Monitoring can be performed on different types of system components and for several purposes beyond the ones presented here. Service-oriented literature on the subject discussed the multitude of aspects related to monitoring for services; the interested reader is referred to ~\cite{ghezzi2007run},~\cite{metzger2010analytical}, or more recently~\cite{pernici2016monitoring} for an extensive presentation of the subject. 

% Our 
% - Lanza has done nice stuff for source code evolution patterns. we need more work on automatic detection of service / endpoint evolution patterns. as exemplified by the utilization evolution.



% \va{Mircea: Consider removing the rest for space...}
% An existing monitoring tool is Pingdom \footnote{https://www.pingdom.com/company/why-pingdom}, which monitors the uptime of an existing web-service. This tool works by pinging the websites (up to 60 times) every minute automatically. Thus this creates a lot of overhead and is bound to be noisy since it will also be influenced by the speed of the network connection\footnote{Another problem is that such a tool would }

% \todo{Runscope? Others?}