% $Id: transform.tex 19213 2009-08-17 10:06:43Z gokhale $
\section{The QUICKER QoS Configuration Process}
\label{sec:transform}

Figure~\ref{fig:overall} shows the automated middleware QoS
configuration approach adopted by QUICKER to address the challenges
outlined in Section~\ref{sec:issues}.   QUICKER uses
model-to-model transformation tec\-hniqu\-es~\cite{Czarnecki:06} to
translate the platform-independent specifications of domain-specific
QoS policies modeled in one DSML into middleware-specific QoS
configurations modeled in another DSML.  

\begin{figure}[htb]
  \centering
  \includegraphics[width=\columnwidth,keepaspectratio]{quicker-wide}  
  \bfcaption{Model-driven QoS configuration process}
  \label{fig:overall}
\end{figure}

The source models of domain-specific QoS policies are modeled using a
DSML is called \emph{Platform-Independent Component Modeling Language}
(PICML)~\cite{Schmidt:04z}.  PICML provides a construct called
\emph{Policies} that enables developers of component-based DRE systems
to annot\-ate com\-ponent-based application models developed in PICML
with QoS policies.   These policies are specified at a higher-level of
abstraction using \emph{platform-independent} artifacts rather than
using low-level, platform-specific configuration options typically
found in middleware configuration files.  QUICKER thus allows
flexibility in mapping the same QoS policy to other middleware
technologies. 

QUICKER's automated mapping process transforms the PICML QoS policy
models into models of middleware-specific QoS configuration
options that belong to a DSML called the \emph{Component QoS Modeling
  Language} (CQML).  In this paper, CQML enables the modeling of
platform-specific QoS configurations provided by the
CIAO~\cite{Schmidt:06r} real-time CORBA Component Model middleware.

To demonstrate the viability of the QUICKER approach, we have used the
Generic Modeling Environment (GME)~\cite{GME:01} framework for
developing the source and target DSMLs.   GME is a metaprogrammable
modeling environment with a general-purpose editing engine, separate
view-controller GUI, and a configurable persistence engine.  Since GME
is metaprogrammable, the same environment used to define a DSML is
also used to build models, which are instances of the DSML metamodel.
GME provides the ability to use OCL to assign semantics to the
concrete syntax of a DSML.  GME also enables associating generators
with individual DSMLs through a plugin mechanism.  These generators
are typically model interpreters that can traverse the entities of the
DSML and can be implemented to synthesize different artifacts, such as
XML descriptors, source code, or input to analysis tools.

The  model-to-model transformations have been
developed~\cite{Gokhale_GTQMAP_RTAS:08} using the Graph Rewriting And
Transformation (GReAT)~\cite{Karsai:03} framework.  GReAT, which is
implemented within the framework of 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).

\subsection{Modeling QoS Policies: The Source DSML}
\label{sec:picmlmodel}

QUICKER defines a \texttt{Policy} modeling construct as a
generalization of QoS policies.  As shown in
Figure~\ref{fig:requirements}, source elements \texttt{Component},
\texttt{Com\-pone\-ntAs\-sem\-bly}  or \texttt{Port} connections can
be associated with  a \texttt{Policy} element.  The modeling
abstractions in QUICKER allow association of multiple source elements
with the same \texttt{Policy} as long as those source elements are of
the same \emph{type}.  Moreover a \texttt{Comp\-onent\-Assembly}'s
\texttt{Policy} is also associated with all the components
contained in that \texttt{Com\-pon\-entAss\-emb\-ly}.  Such associations
provide significant benefits in terms of flexibility in the creation of
QoS policies models and scalability of the models.  The metamodels
we describe below have been integrated with PICML using these 
associations; thus a single model of DRE system captures its entire
QoS policies specification.
 
\begin{figure}[htb]
\centering
\includegraphics[width=0.9\columnwidth,keepaspectratio]{policies}
\bfcaption{Simplified UML notation of QoS Policies associations in QUICKER}
\label{fig:requirements}
\end{figure}

Next we discuss the policies specification across the following
two real-time QoS dimensions: (1) RT request/response that is used to
specify policies for components and the synchronous connections
between components, and (2) RT publish/subscribe service that is used to
specify policies for asynchronous event-based connections between
components.

\noindent\textbf{Request/Response QoS policies.}  The
request/response policies have component-level granularity.   A
\texttt{RTPolicy}  element, which is derived from
\texttt{Policy}, captures real-time policies of a component
and may have the following two attributes: (1)
\texttt{fix\-ed\_pri\-ori\-ty\_ser\-vi\-ce\_exe\-cu\-ti\-on}, a server
component Boolean property for specifying whether or not it modifies
client service invocation priorities, and (2)
\texttt{bur\-sty\_cli\-ent\_req\-ue\-sts}, a server component Boolean
property for specifying the profile of service invocations made by its 
client components.  Figure~\ref{fig:rtrequirements} illustrates the relevant
concrete syntax for modeling the policies for the request/response
real-time communication.

\begin{figure}[htb]
\centering
\includegraphics[width=0.7\columnwidth,keepaspectratio]{RTRequirements}
\bfcaption{Simplified UML notation for Real-time Request/Response Policies}
\label{fig:rtrequirements}
\end{figure}

\noindent\textbf{Publish/subscribe QoS policies.}
We have modeled the policies for real-time publish/subscribe event
service to enable specification of QoS across asynchronous and 
anonymous interactions in component-based DRE systems.  In the context
of a publish/subscribe service, a \textbf{Subscriber} component
subscribes to receive events from a \textbf{Publisher} component that
generates events.  Publisher (subscriber) component connects to a
mediator entity, an \textbf{Event Channel}, to publish (subscribe to)
events.  Figure~\ref{fig:ecrequirements} illustrates the relevant
concrete syntax for modeling the policies of the event channel.

\begin{figure}[htb]
\centering
\vspace{-.2in}
\includegraphics[width=\columnwidth,keepaspectratio]{ECRequirements}
\vspace{-.2in}
\bfcaption{Simplified UML notation for Policies of Event Channels}
\label{fig:ecrequirements}
\end{figure}

A \texttt{ECPolicy} element is derived from \texttt{Policy}.
It models the properties of the event channel and can be used to specify
the following QoS policies:  (1) \texttt{network\_quality}, a
connection-level property that captures the quality value of network
used for running the application; (2)
\texttt{co\-nn\-ec\-ti\-on\_fr\-eq\-ue\-nc\-y}, a component-level
property specifying the frequency at which the component (dis)connects
with the publish/subscribe connection; (3)
\texttt{ev\-en\-t\_di\-st\-ri\-bu\-ti\-on\_ra\-ti\-o}, a
connection-level property that specifies the ratio:
$\frac{{E^a}_c}{{E^s}_c}$, where ${E^a}_c$ denotes number of events
available for subscription at connection $c$ and ${E^s}_c$ denotes
average number of events subscribed to at connection $c$ by each
subscriber component. 

These modeling capabilities are at a sufficiently high level of
abstraction and are intuitive to be applied to a variety of
publish/subscribe mechanisms. All the policies have an enumerated
data type with values \texttt{LO} and \texttt{HI}.

\subsection{Modeling Middleware QoS Options: The Target DSML}
\label{sec:cqmlmodel}

Rather than directly transforming source models of DRE system QoS
policies into configuration descriptors in XML required for deploying it
on the middleware, we chose to generate models of middleware-specific
QoS options from these source models such that they can be used for
further analysis such as model-checking QoS properties of the DRE
system.  This represents the Component QoS Modeling Language (CQML).
We have developed interpreters for parsing CQML system models and
generating XML deployment descriptors in preparation for deploying the
DRE system on the target environment. 

\noindent\textbf{Request/Response QoS options.} A simplified UML
notation of CQML modeling elements for Request/Response QoS
options is shown in Figure~\ref{fig:rtconfig}. 

\begin{figure}[htb]
\centering
\includegraphics[width=\columnwidth,keepaspectratio]{configuration}
\bfcaption{Simplified UML notation for RT-CCM Request/Response Configuration Options}
\label{fig:rtconfig}
\end{figure}

As shown, CQML defines the
following elements corresponding to several RT-CCM configuration
mechanisms: (1) \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 \emph{static} thread (\emph{i.e.}, those that
remain active till the system is running and \emph{dynamic} thread
(\emph{i.e.}, those threads that are created and destroyed as required)
numbers using \texttt{Lane} element; (2) \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 buffer requests that cannot be immediately
serviced; (3) \texttt{PriorityModelPolicy}, which controls the policy
model that a particular \texttt{Thr\-ead\-Pool} follows. It can be set
to either \textsc{client\_propagated} if the invocation priority is
preserved, or  \textsc{server\_declared} if the server component changes
the priority of invocation; and (4) \texttt{BandedCon\-nections}, which
defines separate connections for individual (client) service
invocations. 

An example snippet of XML descriptors that are generated out of CQML
models for request/response policies is shown in
Listing~\ref{extn:xmlsnippet}.   As shown in lines 3-19,
\texttt{Th\-re\-ad\-Po\-olW\-ith\-La\-nes}  consists of the following
two options: (a) \texttt{Lane},  specifying the number of thread
resources and their type, and (b) \texttt{Thr\-ea\-dP\-oo\-l},
governing various characteristics  of a pool of \texttt{Lanes}. For
each option in this listing, the value of that option must be enclosed
in appropriate XML tags such that the QoS specification is valid and
complete.


\begin{Descriptor}

    \begin{Verbatim}[numbers=left,numbersep=3pt,frame=single,fontsize=\relsize{-2}]
    <orbConfigs>
    <resources>
      <threadpoolWithLanes id="threadpool-2">
        <threadpoolLane>
          <static_threads>5</static_threads>
          <dynamic_threads>0</dynamic_threads>
          <priority>2</priority>
        </threadpoolLane>
        <threadpoolLane>
          <static_threads>5</static_threads>
          <dynamic_threads>0</dynamic_threads>
          <priority>1</priority>
        </threadpoolLane>
        <stacksize>0</stacksize>
        <allow_borrowing>false</allow_borrowing>
        <allow_request_buffering>false</allow_request_buffering>
        <max_buffered_requests>0</max_buffered_requests>
        <max_request_buffered_size>0</max_request_buffered_size>
      </threadpoolWithLanes>    
    \end{Verbatim}

\caption{XML Descriptor Snippet for RT request/response Configuration in LwCCM}
\label{extn:xmlsnippet}
\end{Descriptor}

\noindent\textbf{Publish/subscribe QoS options.} For QoS configuration
of asynchronous event communications, CQML defines the following
elements: (1) \texttt{Publisher} and \texttt {Subscriber} modeling
elements containing all the event source and sink settings, respectively.
These include, for example, thread locks management mechanisms for
publishers (subscribers) that are accessed by multi-threaded  systems,
and types of event filtering used, (2) \texttt{RTECFactory} element
contains configurations specific to the event channel itself.  These
include, for example, event dispatching method that controls how events
from publishers are forwarded to the respective subscribers, scheduling
of events for delivery and other scheduler-related coordination, and
handling of timeout events in order to forward them to respective
subscribers, and (3) \texttt{FilterGroup} element that specifies
strategies to group more than one filters together for publishers
(subscribers). 

\begin{figure}[htb]
\centering
\includegraphics[width=\columnwidth,keepaspectratio]{ECConfiguration}
\bfcaption{Simplified UML notation for RT-CCM Publish/Subscribe Configuration Options}
\label{fig:ecconfig}
\end{figure}

Having a DSML such as CQML has the following advantages:

\begin{BulletList}
\item The (generated) CQML models can be used for further analysis such
as, for example, model-checking QoS properties of the DRE
system.
\item Using models of application at each step of software development
increases traceability as QoS policies are translated to low-level
QoS configurations \emph{i.e.}, to middleware descriptors required for
deploying the DRE system.
\item The CQML models are \emph{closed} in terms of modification by
system developers, and can only be (re-)generated by applying QUICKER
model transformations on system QoS policy models.  Such a design
choice simplifies software development and is a crucial step towards
addressing productivity problem~\cite{MDABook:03} at the middleware
level.   
\end{BulletList}

\subsection{Model-to-model Transformation Algorithms}
\label{sec:algo}
The QUICKER model transformation rules have been defined in GReAT and
are based on our past experiences in configuring QoS for component-based
DRE  systems.   Transformation rules are defined using the GReAT
visual language.   They are applicable to any system model that
conforms to the Policies DSML, and thus can be used by the system
developers repetitively during the development and/or maintenance
phase(s) of the DRE system.  QUICKER model transformations preserve the
granularity specified in the source models. 

Figure~\ref{fig:GReAT} shows the high-level steps
involved in developing transformation algorithms using the GReAT tool
chain. In Step 1, the source and target domain-specific modeling
languages (DSMLs) for the transformation tool chain are defined. In
Step 2, developers use the GReAT transformation  language to define
various  translation rules in terms of patterns\footnote{Here, pattern
  refers to a valid structural composition using model objects in the
  source (target) DSML.} of source and target modeling objects.  Rules
that cannot be captured visually can be encoded as C++ code snippets
associated with the mapping blocks.   In Step 3, a source model
instance is provided to the GReAT framework.   Finally, in Step 4,
developers execute the GReAT engine (called the GR-engine) that
translates the source model using rules specified in Step 2 into the
target model.

\begin{figure}[htb]
\centering
\includegraphics[width=0.85\columnwidth,keepaspectratio]{GReATOverview}
\bfcaption{Model Transformation Process in GReAT (details of the models
  are not important for this figure).}
\label{fig:GReAT}
\vspace{-.1in}
\end{figure}

More specifically, the GR-engine execution involves the following steps:
(1) executing the \emph{master interpreter} that generates the necessary
intermediate files containing all the rules in the current
transformation, (2) compile these intermediate files, if not done
already, and (3) run the generated executable.  

We now describe the mapping rules we have encoded using the GReAT
transformation language for mapping QoS policies into middleware QoS
configurations for situations that use request/response and
publish/subscribe semantics.

\noindent\textbf{Mapping real-time QoS Policies.} 
Let ${R_p}^o$ and ${R_p}^i$ denote, respectively, the set of 
outgoing (required/event source) and incoming (provided/event sink) ports of
component $p \in P$. Let $S$ and $C$ be the sets of server and client
components respectively and are given by:
 
$ p \in S \; if \; {R_p}^i \neq \emptyset$
and
$ p \in C \; if \; {R_p}^o \neq \emptyset$

Algorithm~\ref{alg:rt-map} describes (non-exhaustive) RT-CCM QoS mappings
in QUICKER. Lines 5-13 show the thread resource
allocation scheme for server components.  For every incoming port of a
server component, the number of interface operations and client
components are counted (lines 9 and 10).  These counts are used by 
the auxillary function $ThreadResources$ to calculate the total
threads required for handling all client service invocations at that
server.  

\begin{algorithm}[htb]
\bfcaption{Real-time QoS policies mapping}
\label{alg:rt-map}
{%\small
\footnotesize
%\scriptsize
\dontprintsemicolon
\Indm
\Setnlskip{0.17in}
\linesnumbered
\KwIn{set of client components $C$,
			set of server components $S$,
      set of bursty client components $B$,
      set of threadPool lanes $TPLanes$}
\Begin{
  InterfaceOperationsCount $ioc$;
  ClientsCount $cc$;\;IncomingPort $ip$;
  OutgoingPort $op$;ThreadCount $tc$;\;
  Component $c$;set of Components $CPS$;
  Buffering $bf$;\;
       
   \ForEach{$p \in S$}{
   
   			$ioc \leftarrow 0;$ $cc \leftarrow 0;$
   			$tc \leftarrow 0;$ $bf \leftarrow false;$\;
   			
   			$CPS \leftarrow\ ClientComponents(p);$\;  			
  			
     		\ForEach{$ip \in {R_p}^i$}{
       			$ioc \leftarrow\ ioc + countOperations(p,ip);$\;         
       			$cc \leftarrow\ cc + countClientComponents(p,ip);$\;
     		}
     		$tc \leftarrow\ ThreadResources(ioc, cc);$\;
     		
     		$createTPLanes(p,tc);$\;     		
     		
     		\ForEach{$c \in CPS $}{
     				\uIf{$c \in B$}{
     						$bf\leftarrow true;$\;
     						$assignThreadResources($\;
     						  $TPLanes_{p},c,tc);$\;             
     				}     				
     				$assignTPoolAttributes(TPLanes_{p},bf);$\;
     		
     				$ioc \leftarrow\ 0;$\;		
     				
    				\ForEach{$op \in {R_c}^{o}$}{
      					$ioc \leftarrow ioc + countOperations(c,op);$\;
    				}
    				$createBands(c,ioc);$  					
     				$matchPriorities(p,c);$\;
   			}

   }
      
}
}
\normalsize
\end{algorithm}
%\vspace{-0.2in}

For handling bursts of client requests, server components should
configure their thread pool to grow dynamically such that threads are
created only when
required.%~\cite{Schmidt:99aa}. 
$assignThreadResources$ function is used
to adjust the ratio of static and dynamic threads for a server,
depending on whether its \texttt{bur\-sty\_cli\-ent\_req\-ue\-sts}
property is set to {\sc true}. In addition, lane borrowing feature at
the server is set to {\sc true} such that the thread pool lanes across
various priority levels can be borrowed.  Finally,
\emph{PriorityBands} are configured and the their priority values are
matched with server-side lane values in line 24. 

\noindent\textbf{Mapping publish/subscribe QoS policies.} 
Let ${PC_c}^s$ denote the synchronization mechanism, ${PC_c}^t$ denote
the type, ${PC_c}^i$ denote the iterator in proxy collection $PC$
for component $c$, respectively.  Let $L_c$ denote the locking
policy, $CP_c$ denote control policy, $SF_c$ denote supplier-based
filtering at component $c$, respectively.  Algorithm~\ref{alg:ec-map}
gives the (non-exhaustive) publish/subscribe QoS mappings.

%\vspace{-0.15in}
\begin{algorithm}[htb]
\bfcaption{Publish/Subscribe service QoS policies mapping}
\label{alg:ec-map}
{%\small
\footnotesize
%\scriptsize
\dontprintsemicolon
\Setnlskip{0.17in}
\linesnumbered
\SetAlFnt{\small\sf}
\Indm
\KwIn{set of components $CPS$}

\Begin{
	Component $c$; ThreadPoolLaneCount $lc$;\;
	NetworkQuality $nq$;\;
	
	\ForEach{$c \in CPS$}{
		$lc = countThreadResources(c)$;
		$cf = connectionFrequency(c)$;
		$nq = networkQuality(c)$;	
		$dr = eventDistributionRatio(c)$;\;
		
		\uIf{$lc \neq 1$}{
		  ${PC_c}^s = MT;$
		  $L_{c} = THREAD;$\;
		}
		\Else{
			${PC_c}^s = ST;$
			$L_{c} = NULL;$\;
		}
		\uIf{$cf \neq LO$}{
		  ${PC_c}^t = LIST;$
		  ${PC_c}^i = COPY\_ON\_READ;$\;
		}
		\Else{
			${PC_c}^t = RB\_TREE;$
			${PC_c}^s = COPY\_ON\_WRITE;$\;
		}
		\uIf{$nq \neq LO$}{
		  $CP_c = NULL;$\;
		}
		\Else{
			$CP_c = REACTIVE;$\;
		}
		\uIf{$c \in S$ }{
			\uIf{$dr \neq LO$}{
		  	$SF_c = PER\_SUPPLIER;$\;
			}
			\Else{
				$SF_c = NULL;$\;
			}
		}
				
	}
}
}
\normalsize
\end{algorithm}

A publish/subscribe service has several settings for configuring
the way collections of publisher and subscriber object references
are created and accessed, which must be chosen appropriately
for individual applications.  Lines 6-9 in Algorithm~\ref{alg:ec-map}
show how the choice of serialization mechanism is affected by the 
number of thread resources configured at component $c$. 

The choice of the \emph{type} of collection is based on the following:
(1) {\sc rb\_tree} data structure exhibits faster ($O(log(n))$) 
insertion and removal operations.  Therefore, it is more suited for
connections whose components have a high (dis)connection rate; (2)
{\sc list} data structure on the other hand, should be chosen in cases
where iteration is frequent (and therefore, more crucial for
efficient application execution) than modifications to it. % give O()

Lines 11-14 give the steps in algorithm that configure the collection
type.  Finally, {\sc reactive} policy is chosen for applications that use
low-quality value network on Lines 16-19, which ensures that 
(publisher/subscriber) components are periodically polled for determining 
their states (\emph{i.e.}, whether or not they are connected to the
event channel). 

\subsection{Resolution of Challenges 1 \& 3}
\label{sec:resolve1_2} 
Target typed graph elements (\emph{i.e.}, QoS options), are
well-understood by middleware implementation experts.  We expect that
the QUICKER transformation algorithms~\ref{alg:rt-map} and
~\ref{alg:ec-map} will be designed in terms of source and target typed
graphs by these experts.  DRE system developers will only need to think
of their policies at levels that are intuitive.  Hence, they can
describe their system QoS policies using the modeling capabilities
discussed in Section~\ref{sec:picmlmodel}. 

By providing  platform-independent modeling elements in QUICKER and
defining representational semantics that closely follow those of the
system policies, QUICKER allows system developers to describe system
QoS using simple, intuitive notations.  Further, model transformations
defined in QUICKER automatically identify and deduce QoS configurations
that are best suited to achieve the desired QoS for DRE systems being
configured.   This resolves Challenge 1 described in
Section~\ref{sec:issues}.

Challenge 3 described in Section~\ref{sec:issues} is partly resolved as
follows.  QUICKER transformation rules contain information about the 
semantics of the QoS options, their inter-dependencies, and how they
affect the high-level QoS policies of a DRE system and therefore are
used to assign values to the subset of options chosen earlier.  Further,
QoS options semantics are known precisely during transformations, and
thus QUICKER ensures preservation of the target typed graph
semantics. Component interactions defined in input typed graph instance
(\emph{i.e.}, source model), along with the user-specified QoS
policies captured in that instance are used to completely generate
an instance of the output graph. 


