% $Id: solution.tex 16889 2009-02-21 03:51:46Z gokhale $
\section{Enhancing the Quality of DRE System Software Architectures}
\label{sec:sol}

We now present our model transformation-based approach to address the
impediments to the quality of software architectures of component-based
DRE systems stemming from suboptimal deployment and configuration
decisions.  We use a simple representative example to discuss our
approach.

\input{casestudy}


\subsection{Heuristics-based Model-transformation Algorithm}
\label{sec:algo}


The model transformation algorithm we developed takes the following
models and generated artifacts as its input: (1) DRE QoS requirements
specification in the form of models as shown in
Figure~\ref{fig:basicsp_model}, and (2) the generated DRE system
deployment plan indicating the coarse-grained component-to-node mapping
and configuration options to be used for the middleware.  We assume that
this mapping includes collocation groups, which are sets that include
the components that can be placed together on a node and  that too in
the same address space.   The objective of our algorithm is to improve
the end-to-end latencies in DRE system as well as reduce the memory
footprint of the DRE system by virtue of minimizing the number of
containers needed to host the DRE system components.

The output of our algorithm is an enhanced QoS policy set\footnote{QoS
  policy set is a group of configuration files that completely capture
  the DRE system QoS. These files are used by the middleware to
  ultimately provision  infrastructure resources such that the QoS can
  be met.}, which is incorporated into the DRE system model.  Our
approach produces optimized QoS policy sets by employing novel ways 
of reusing and/or combining existing deployment and configuration
metadata and applying deployment heuristics in an application-specific
manner.

We have used the Graph Rewriting And Transformation
(GReAT)~\cite{Karsai:03} language for defining our transformation
algorithms.  GReAT, which is developed using GME, can be used to define
transformation rules using its visual language, and executing these
transformation rules for generating target models using the GReAT
execution engine (GR-Engine).  The graph rewriting rules are defined in
GReAT in terms of source and target languages (\emph{i.e.}, metamodels).

Below we explain the individual steps in our transformation process.

\subsubsection{Step I: Modeling Language used in the Transformation Algorithm}
\label{sec:stepI}

To demonstrate our technique we required a modeling language to enable
the developers to annotate their QoS requirements on the DRE system
models. A simplified UML QoS configuration metamodel that we used is
shown in Figure~\ref{fig:cqml}. 

\begin{figure}[htb]
  \centering  
    \includegraphics[width=0.7\textwidth,keepaspectratio]{configuration}    
    \caption{Simplified UML notation of QoS configuration meta-model in CQML}
\label{fig:cqml}
\end{figure} 

The metamodel defines the following elements corresponding to several
LwCCM real-time configuration mechanisms:

\begin{BulletList}
\item \texttt{Lane}, which is a logical set of threads each one of which
runs at \texttt{lane\_priority} priority level.  It is possible to
configure the number of \emph{static} threads (\emph{i.e.}, those that
remain active till the system is running, and \emph{dynamic} threads
(\emph{i.e.}, those threads that are created and destroyed as required)
using \texttt{Lane} element.

\item \texttt{Thr\-ead\-Pool}, which controls various settings of
\texttt{Lane} elements, or a group thereof.  These settings include
\texttt{stacksize} of threads, whether borrowing of threads across two
\texttt{Lane} elements is allowed, and maximum resources assigned to the
buffer requests that cannot be immediately serviced. 

\item \texttt{PriorityModelPolicy}, which controls the policy model that
a particular \texttt{Thr\-ead\-Pool} follows.  It can be set to either
{\sc client\_propagated} if the invocation priority is preserved, or
{\sc server\_declared} if the server component changes the priority of
invocation.   

\item \texttt{BandedConnections}, which defines separate connections for
individual (client) service invocations.  Thus, using
\texttt{BandedConnections}, it is possible to define a separate
connection for each (range of) service invocation priorities of a client
component.  The range can be defined using \texttt{low\_range} and
\texttt{high\_range} option values of \emph{Ba\-ndedC\-onne\-cti\-ons}.

\end{BulletList}

\iffalse
Thus, using the CQML modeling elements explained above, developers 
specify QoS configuration policies for their DRE systems.  We now
explain how these QoS policies specified by the developers are updated
using our model transformation algorithm.

As shown, CQML defines a number of elements corresponding to several
RT-CCM configuration mechanisms, which in turn is based on real-time
CORBA.  For example, CQML models QoS policies that allow DRE systems to
configure and control (1) \emph{processor resources} via thread pools
(see \texttt{Thr\-ead\-Pool} and \texttt{Lane}), priority mechanisms
(see \texttt{PriorityModelPolicy}), intra-process mutexes, and a global
scheduling service, (2) \emph{communication resources} via protocol
properties and explicit bindings (see \texttt{BandedConnections}, and
(3) \emph{memory resources} via buffering  requests in queues and
bounding the size of thread pools and its attributes (see
\texttt{stacksize}).
\fi

\subsubsection{Step II: QoS Policy Optimization Algorithm}
\label{sec:stepII}

Algorithm~\ref{alg:optimize} depicts our heuristics-based
model-transformation algorithm, which uses the metamodel shown in
Figure~\ref{fig:cqml} as its source and target language, for optimizing
the deployment and configuration decisions.  

\begin{algorithm}[htb]
\caption{Transformation Algorithm for Optimizing Deployment and
  Configuration Metadata}
\label{alg:optimize}
{
\scriptsize
\dontprintsemicolon
\Indm
\Setnlskip{0.17in}
\linesnumbered
\SetCommentSty{textsf}
\KwIn{set of deployment plans $SP$; \;
			set of components $SC$, $SCS$ (those that use server declared
      policy), $SCC$ (those that use client propagated policy);\; 
			component $c$, $c_p$;  \;
      deployment plan $p$; \;
			set of QoS policies $SQ_1$, $SQ_2$, $qp_a$ (QoS policy set of a
      specific component 'a'), $qp_b$ (similarly for a component 'b'); \;
			set of collocation groups $SCG$; \;
      collocation group $g$}
      
\Begin{ 
       
   \ForEach{$p \in SP$}{\nllabel{algo1:for1}\;
   
   			$SCG \leftarrow collocationGroups(p);$\tcp{collect all collocation
          groups in the deployment plan}\; 
   			
   			\ForEach{$g \in SCG$}{
   
\iffalse
% This is very confusing. I decided to use a simpler way
   			$c_p \leftarrow components (p);$ 
   			
   			$SC \leftarrow SC + c_p \; | \; c_p \in cgComponents(g);$\;\nllabel{algo1:allcomps}\;
\fi   			

        $SC \leftarrow SC + components (g);$ \tcp{Collect all components
          of a single collocation group}\;\nllabel{algo1:allcomps}\;
   			\uIf{$c \in SC \; | \; c.priorityModel == SERVER\_DECLARED \; $}{
     						$SCS \leftarrow SCS + c;$ \tcp{Collect all components
                  using the server declared policy}\;\nllabel{algo1:allsd}\;
     				}
     				\uElseIf{$c \in SC \; | \; c.priorityModel == CLIENT\_PROPAGATED \; $}{
     						$SCC \leftarrow SCC + c;$  \tcp{Collect all components
                  using the client propagated policy}\;\nllabel{algo1:allcp}\;
     				}     				
 %    		\uIf{$c \in SC \; | \; c.priorityModel == CLIENT\_PROPAGATED \; $}{
%     						$SCC \leftarrow SCC + c;$\;     						     						            
%     				}  			
     				
     		 \ForEach{$c \in SCS$}{
     		   $SQ_1 \leftarrow SQ_1 \; + \; c.QoSPolicy ();$\;
     		   minimize $\; SQ_1 \;$\;\nllabel{algo1:main1}\;
     		   subject to $ \; qp_a \; \bowtie \; qp_b \; | \; qp_a \; \cong \; qp_b;$\nllabel{algo1:main2}\;
     		 }
     	\ForEach{$c \in SCC$}{
     		   $SQ_2 \leftarrow SQ_2 \; + \; c.QoSPolicy ();$\;
     		   minimize $\; SQ_2 \;$\;\nllabel{algo1:main3}\;
     		   subject to $ \; qp_a \; \bowtie \; qp_b \; | \; qp_a \; \cong \; qp_b;$\nllabel{algo1:main4}\;
     		 }
%     		 \ForEach{$c \in SCC$}{
%     		   $SQ \leftarrow SQ \; + \; c.QoSPolocy ();$\;
%     		   $\; minimize \; SQ \; subject \; to \; qp_a \; \bowtie \; qp_b \; | \; qp_a \; \cong \; qp_b;$\;
%     		 }
%     		  
 		}
 		
    $modifyDeploymentPlan (p, SQ_1, SQ_2);$\nllabel{algo1:last}
    \tcp{modify the plan and repeat until no more optimizations are feasible}\; 		

   }
      
}
}
\normalsize
\end{algorithm}

The algorithm is executed for all the deployment plans specified for an
application and the policy optimizations are applied for each such plan
as shown in Line~\ref{algo1:for1}.  In Line~\ref{algo1:allcomps}, all
the components from a single collocation group are found.\footnote{Note
  that this is a host-based collocation group.}  Based on whether they
have \textsc{server\_declared} or \textsc{client\_propagated} priority
model, they are grouped  together in $SCS$ and $SCC$ as shown in
Lines~\ref{algo1:allsd} and ~\ref{algo1:allcp},  respectively.  

Finally, for each set of components above, the algorithm minimizes the
number of QoS policies in Line~\ref{algo1:main1} subject to the
condition in Line~\ref{algo1:main2}.  This condition stipulates that if
QoS policies of two (sets of) components $a$ and $b$ each indicated in
the Algorithm by $qp_a$ and $qp_b$, respectively, are similar (binary
Boolean function $\cong$ finds whether the policies are similar), then
they are combined (indicated by $\bowtie$) leading to a reduction in the
size of $SQ_1$.  This test is applied pairwise to all components in the
set.  The Algorithm implements symmetric rules for
\textsc{client\_propagated} policy model.

In Line~\ref{algo1:last} the results from applying all the above rules
to the DRE system model are used to modify the current deployment plan,
and the process is repeated for all the remaining plans of the DRE
system until no more optimizations are feasible.

\iffalse
At the end of step I, the developers created the application model that
captured the initial QoS policies.  The transformation
Algorithm~\ref{alg:optimize} is applied in step II to that DRE system
model, which updates it and generates a modified QoS configuration
policies using the rules described above. 

\subsection{Resolving the Challenges in Optimizing QoS Configurations}
\label{sec:resolve}

Our automated, model transformation-based approach resolves the
challenges we have discussed in Section~\ref{sec:chal} as follows:
The inherent platform-specific complexities in optimizing DRE system QoS
configurations are encapsulated in the transformation rules described in
Section~\ref{sec:algo}.  The developers can thus focus on application
business logic, and use our approach to optimize the QoS
configuration.  Further, the model transformation rules are reusable and
can be applied repeatedly, during application development, and
maintenance. 

Next, we apply our approach to a representative case study and show how it
improves the end-to-end invocation latency.
\fi
