Suggestions from Marleen

Author: hermanbanken

paper.tex

@@ -113,13 +113,13 @@ \section{Conclusion}
 
 The relationship between multi-tenancy and the \ac{SaaS} domain is considered close~\cite{dillon2010cloud}, or even stronger: multi-tenancy is a characteristic of the \ac{SaaS} domain~\cite{tsai2010towards}. Additionally, the challenges of cloud services overlap with the challenges of multi-tenancy~\cite{dillon2010cloud,krebs2012architecture}.
 
-In security, an overview has been provided of the new security concerns and their solutions introduced in multi-tenancy, including data localization, data storage and authentication and authorization. We showed that there is a thin line between security issues caused by multi-tenancy and security issues caused by the general cloud technologies. Multi-tenancy is a high-level concept, relying on a multitude of other technologies, which thereby inherits traditional security issues.  
+In Section~\ref{sec:security} on security, an overview has been provided of the new security concerns and their solutions introduced in multi-tenancy, including data localization, data storage and authentication and authorization. We showed that there is a thin line between security issues caused by multi-tenancy and security issues caused by the general cloud technologies. Multi-tenancy is a high-level concept, relying on a multitude of other technologies, which thereby inherits traditional security issues.  
 
-In Scalability research on estimating resource consumption per tenant and using these estimations to place tenants within the existing infrastructure was discussed. In addition to that an overview of data layer specific scalability research was presented.
+In Section~\ref{sec:scalability} on scalability, research on estimating resource consumption per tenant and using these estimations to place tenants within the existing infrastructure was discussed. In addition to that an overview of data layer specific scalability research was presented.
 
-\ac{QoS} research was surveyed separately from scalability. Three techniques that use a form of per tenant request limiting for separating tenants where discussed.
+\ac{QoS} research was surveyed separately from scalability. Three techniques that use a form of per tenant request limiting for separating tenants were discussed.
 
-In Variability, most research is done on modeling variations and describing techniques to build variants. We provided an overview of the levels of variability (e.g. external variability, visible to the customer; and internal variability, invisible to the customer), three modeling techniques (Feature modeling, Decision modeling and Orthogonal Variability modeling) and the various variation techniques.
+On the subject of variability, most research is done on modeling variations and describing techniques to build variants. We provided an overview of the levels of variability (e.g. external variability, visible to the customer; and internal variability, invisible to the customer), three modeling techniques (Feature modeling, Decision modeling and Orthogonal Variability modeling) and the various variation techniques.
 
 \subsection{Research Agenda}
 \label{sec:ra}
@@ -128,25 +128,25 @@ \subsection{Research Agenda}
 
 \item \textbf{Automation}. 
 To exploit economies of scale, providers of multi-tenant applications want to attract as many tenants and users as possible. 
-However managing all these tenants and their configuration, takes a lot of time without the proper tools. 
+However, managing all these tenants and their configurations takes a lot of time without the proper tools. 
 Research has been done on creating wizards for tenants~\cite{mietzner2008generation,mietzner2008defining}, but this field is not completely covered yet and additionally, automatic deployment of the outcome of these wizards can be investigated (Section~\ref{sec:var_agenda}).
 \item \textbf{Guarantees}. 
 In all aspects of multi-tenancy new problems arise. 
 The solutions proposed for these problems need to be provable, for multi-tenancy to be usable in high availability or business critical applications. 
 Open research opportunities lie in state consistency while updating the platform (Section~\ref{sec:var_agenda}), proving data isolation between tenants (Section~\ref{sec:security_agenda}), providing performance isolation and minimal performance (Section~\ref{sec:qos_agenda}).
 \item \textbf{Effective security}.
-Although security measures have been proposed to secure multi-tenant systems, research should dedicated to finding a effective balance between security and performance. Traditional and new Security mechanisms should be redesigned to increase their effectiveness in multi-tenancy environments (Section~\ref{sec:security_agenda}).
+Although security measures have been proposed to secure multi-tenant systems, research should be dedicated to finding a effective balance between security and performance. Traditional and new security mechanisms should be redesigned to increase their effectiveness in multi-tenancy environments (Section~\ref{sec:security_agenda}).
 \item \textbf{Tenant aware components}.
 In scalability and \ac{QoS} research, tools like tenant aware load balancers and tenant aware databases are used or proposed (Section~\ref{sec:scal_mta} and \ref{sec:tenant_aware}).
 The benefits of such tools in a multi-tenant environment have already been proven.
 The proposed multi-tenant aware database is still incomplete as it lacks tenant aware administration tooling and more work on the storage model is needed. 
-For the multi-tenant aware load balancers the approaches used need to be validated further.
+Also, the approaches used for making load balancers multi-tenant aware, need to be validated further.
 
 %\item \highlight{Voeg hier je belangrijkste punten toe}  en probeer te kijken of het niet overlapt met andere punten en zo ja: voeg samen.
 \end{itemize}
 
 \section{Acknowledgements}
-This literature survey was done in the context of the TI3700 course on the Delft University of Technology. We thank Cor-Paul Bezemer, as the first reviewer, for his helpful comments to improve this paper.
+This literature survey was done in the context of the TI3700 course on the Delft University of Technology. We thank Cor-Paul Bezemer, as our first reviewer, for his helpful comments to improve this paper.
 
 \bibliographystyle{plain}
 \bibliography{ref}

variability.tex

@@ -1,4 +1,4 @@
-In multi-tenancy \textit{variability} is a key concept. The term was first introduced in the car industry, where customers could choose certain \textit{variants} of chassis, engine and color~\cite[p. 153]{kabbedijk2011variability}. 
+In multi-tenancy variability is a key concept. The term was first introduced in the car industry, where customers could choose certain \textit{variants} of chassis, engine and color~\cite[p. 153]{kabbedijk2011variability}. 
 In research on software engineering the concept was defined as ``the ability of a software system or artefact to be efficiently extended, changed, customized or configured for use in a particular context''~\cite{svahnberg2005taxonomy}.
 Two keywords from this definition are customization and configuration. 
 In a multi-tenant context, configuration is preferred over customization~\cite{sun2008software}, as customization requires the process of reengineering an application, maintaining multiple branches and deploying these branches separately, while configuration can be done at run-time and does not require multiple instances or branches.
@@ -20,9 +20,9 @@ \subsection{Levels of variability}
 When looking to realized variability, two types of variability can be distinguished: external and internal variability~\cite{mietzner2009variability}:
 \begin{itemize}
 \item \textbf{External variability} is the variability that is communicated to the customers. Most of the time, this variability is \textbf{customer-driven} and is implemented because customers asked for it or because the developers thought the customers would ask for it. The possibility to upload a custom logo, to select data-separation requirements (such as guaranteed data isolation) or to define custom workflows are examples of external variability.
-\item \textbf{Internal variability} exists because of implementation details, is visible only to the developer or provider and is mostly \textbf{realization-driven}. For example some - external - variant may depend on some internal variation, that guarantees a certain property. When one tenant requires its data to be stored separately, the internal variability consists of the possibility to launch either a single or multiple instances of the database server. It might be more economic to use the same internal variant for all tenants on the same instance to accomplish different external variations, even if this internal variant alone is more expensive.
+\item \textbf{Internal variability} exists because of implementation details, is visible only to the developer or provider and is mostly \textbf{realization-driven}. For example some - external - variant may depend on some internal variation, that guarantees a certain property. When one tenant requires its data to be stored separately, the internal variability consists of the possibility to launch either a single or multiple instance(s) of the database server. It might be more economic to use the same internal variant for all tenants on the same instance to accomplish different external variations, even if this internal variant alone is more expensive.
 \end{itemize}
-Figure~\ref{fig:ovm} depicts this distinction by the a line separating the two types.
+Figure~\ref{fig:ovm} depicts this distinction by a line separating the two types.
 
 \subsection{Variability Modeling}
 For all stakeholders in a multi-tenant application it is important that a variability model exists~\cite{schroeter2012towards}. For the developer, it is important to document all variation built into the application to keep the application maintainable for both current and new developers. 
@@ -35,20 +35,20 @@ \subsection{Variability Modeling}
 \begin{itemize}
 \item \textbf{Feature modeling} or a ``feature based component model" is applied by Walraven et al.~\cite{walraven2011middleware} in their paper on a multi-tenant middleware layer. A variation is
 expressed in terms of a feature, a distinctive functionality, service, quality or characteristic of an 
-application. Features can have multiple implementations that can then be composed into the 
-base application as ideally they are modular pieces of software. By splitting the application in 
+application. Features can have multiple implementations that can be composed into the 
+base application, as ideally they are modular pieces of software. By splitting the application in 
 these kind of features it is easier to keep functionality together, to make each feature 
 customizable and to add implementations in a later stage.
 
 \item \textbf{Decision modeling}, as described by Schmid et al.~\cite{schmid2004customizable}, is used in 
 Software Product Line Engineering to manage the variability of an application that is not specifically 
 multi-instance or even multi-tenant aware. However the concepts can be similarly applied to 
 multi-tenancy. In the decision model, variables are defined that are used throughout the 
-application. For each variable it is defined when the variable is relevant (e.g., dependencies), 
+application. For each variable it is defined when the variable is relevant (e.g. dependencies), 
 what the range of possible values is, what the cardinality is (a set of values is possible), what 
 constraints apply and when the variable is to be bound. The problem with decision variables is 
 that the configuration points and the application code can quickly become incomprehensible 
-when lots of variables exist that might be used thorough different features and components.
+when lots of variables exist that might be used throughout different features and components.
 
 \item \textbf{\acf{OVM}} is used by Mietzner et al.~\cite{mietzner2009variability} as their variability model. \ac{OVM} differs from other approaches in that it does provide a separate view on variability. This reduces the size of the model and makes it easier to understand the models as commonalities are left out and only the variability is modeled. This allows for understanding the model without understanding the application's design model. 
 
@@ -59,7 +59,7 @@ \subsection{Variability Modeling}
     \label{fig:ovm}
 \end{figure}
 
-In \ac{OVM}, the \textit{\acp{VP}} are the key items. One variation point has multiple \textit{variants} that are either optional or mandatory. Relations between \acp{VP} exist that define whether some variant is mutually exclusive with some other variant or whether some variant requires an other variant. Relations are drawn as lines between \acp{VP}. External and internal variability are separated by a dashed line to show which variability customers can choose and which is internally bound. An example can be seen in Figure \ref{fig:ovm}.
+In \ac{OVM}, the \textit{\acp{VP}} are the key items. One variation point has multiple \textit{variants} that are either optional or mandatory. Between \acp{VP}, relations exist that define whether some variant is mutually exclusive with some other variant or whether some variant requires an other variant. Relations are drawn as lines between \acp{VP}. External and internal variability are separated by a dashed line to show which variability customers can choose and which is internally bound. An example can be seen in Figure \ref{fig:ovm}.
 \end{itemize}
 
 % \subsection{Developing with variability in mind}
@@ -106,20 +106,20 @@ \subsection{\aclp{VRT}}
 % MAYBE-TODO: this paragraph could be more elaborate
 
 \subsection{Research Agenda for Variability}\label{sec:var_agenda}
-While there has been done a lot of research, much remains to be covered:
+Although a lot of research has been done, much remains to be covered:
 \begin{itemize}
 
 \item \textbf{Automation}.
-For variability to become manageable, tools must exist for \ac{SaaS} providers to manage the configuration of tenants and to deploy new tenants. Mietzner et al. try to make variability easier to manage by creating so called \textit{customization processes}~\cite{mietzner2008generation} to guide the customer through the customization, and \textit{solutions}~\cite{mietzner2008defining}, that define which variants should be bound. It could be investigated how deployment scripts could be derived from these solutions, to automatically deploy tenants.
+For variability to become manageable, tools must exist for \ac{SaaS} providers to manage the configuration of tenants and to deploy new tenants. Mietzner et al. try to make variability easier to manage by creating so called \textit{customization processes}~\cite{mietzner2008generation} to guide the customer through the customization, and \textit{solutions}~\cite{mietzner2008defining} that define which variants should be bound. It could be investigated how deployment scripts could be derived from these solutions, to automatically deploy tenants.
 
 \item \textbf{Cost Models}.
-While it is researched how the costs of multi-tenant aware applications compare to non-multi-tenant aware applications~\cite{mietzner2009variability}, no research is done to relate a cost model to a variability model. Future research could be done to determine the cost of creating, maintaining and managing variants. The providers can then decide whether or not it makes more sense, economically, to keep a variant or to remove it.
+While it is researched how the costs of multi-tenant aware applications compare to non-multi-tenant aware applications~\cite{mietzner2009variability}, no research is done to relate a cost model to a variability model. Future research could be done to determine the cost of creating, maintaining and managing variants. With the outcome of this research, providers will be able to decide whether or not it makes more sense, economically, to keep a variant or to remove it.
 
 \item \textbf{Identify more \aclp{VRT}}. 
 Kabbedijk and Jansen~\cite{kabbedijk2011variability} have determined some \acp{VRT}, but note that more \acp{VRT} could be identified and should be tested on effectiveness, maintainability, scalability and performance.
 
 \item \textbf{Maintaining Context in \ac{COP}}. 
-Truyen et al.~\cite{truyen2012context} found that \ac{COP} was useful as a \ac{VRT} but ContextJ lacked support for asynchronous request because context is not shared to new threads. Research could be done to see if it is possible to bridge this gap to make \ac{COP} more usable as more and more applications are using asynchronous functionality.
+Truyen et al.~\cite{truyen2012context} found that \ac{COP} was useful as a \ac{VRT} but ContextJ lacked support for asynchronous request because context is not shared to new threads. Research could be done to determine if it is possible to bridge this gap to make \ac{COP} more usable as more and more applications are using asynchronous functionality.
 
 \item \textbf{Maintaining State Consistency while doing Updates}.
 Another open issue is maintaining global state consistency when doing (partial) updates of components that potentially service a lot of tenants~\cite{truyen2012context,dumitracs2009upgrades}. The tenants that do not use any of the updated functionality should not experience any interruptions. This is especially difficult if multiple versions of components must coexist, since each component may depend on other components. When \acp{SLA} are sold this consistency and uninterrupted service should be provable.