% $Id: transform.tex 16638 2009-01-29 19:00:10Z gokhale $
\section{The QUICKER QoS Configuration Process}
\label{sec:transform}
\begin{figure}[htb]
  \centering
  \includegraphics[width=0.6\columnwidth,keepaspectratio]{quicker-wide}  
  \caption{Model-driven QoS configuration process}
  \label{fig:overall}
\end{figure}
Figure~\ref{fig:overall} shows our overall approach (for details
please see~\cite{Gokhale_GTQMAP_RTAS:08}).  DRE
system developers use the \emph{Requirements} domain-specific 
modeling language (DSML)/metamodel to specify the system QoS 
requirements. Using our configuration process, a specification of system 
QoS requirements acts as the source model of QoS mapping 
algorithms. As can be seen in Figure~\ref{fig:overall}, our
process uses model transformations for achieving QoS mapping. 
Middleware-specific QoS configuration options are captured as 
models using the \emph{QoS Configurations} DSML which serves as 
the target model in the transformation process. 

We have used the Generic Modeling Environment (GME)~\cite{GME:01} 
toolkit for developing these source and target languages, which 
provides a  graphical user interface that
can be used to define both language semantics and system models that
conform to the languages defined in it. The model-to-model
transformations, on the other hand, have been developed using the 
Graph Rewriting And Transformation (GReAT)~\cite{Karsai:03}. 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 requirements}
\label{sec:picmlmodel}
\vspace{-0.1in}
QUICKER defines the \texttt{Req\-uire\-ment} element as a generalization
of QoS requirements. 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{Req\-uire\-ment} element. Modeling abstractions in 
QUICKER allow association of multiple source elements with the same 
\texttt{Requirement} as long as those source elements are of the same 
\emph{type}. 
Moreover a \texttt{Comp\-onent\-Assembly}'s \texttt{Req\-uire\-ment}
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
requirements 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 requirements specification.
\iffalse
As mentioned 
earlier for the scope of this paper, QUICKER has been used in 
conjunction with PICML and therefore the discussion above pertains 
to associations of QUICKER QoS requirements with various 
CCM-specific functional entities. However its modeling abstractions 
are flexible enough to be extended for other component-oriented 
technologies. A detailed discussion of how it can be applied in
the context of other platforms is beyond the scope of this paper.
\fi
 
%\vspace{-0.1in}
\begin{figure}[htb]
\centering
%\includegraphics[width=1.3\columnwidth,keepaspectratio]{requirements}
\includegraphics[width=0.5\columnwidth,keepaspectratio]{requirements}
%\vspace{-0.2in}
\caption{Simplified UML notation of QoS requirements associations in QUICKER}
%\vspace{-0.3in}
\label{fig:requirements}
\end{figure}
%\vspace{-0.2in}

Next we discuss the requirements specification across the following
two RT QoS dimensions: (1) RT-CCM that is used to specify requirements
for components and synchronous connections between components, and
(2) RT publish/subscribe service that is used to specify requirements
for asynchronous connections between components.

\noindent\textbf{Real-time QoS requirements.}
\label{re-req} 
\iffalse
\paragraph{\textbf{High Level Directives for Real-time Configuration}}
\label{sec:rtdirectives}
\begin{NumList}
\item System computing, communication and memory resources can be 
allocated statically (\emph{i.e.}, resources are reserved throughout
the application execution cycle) or dynamically (\emph{i.e.}, resources
are created/assigned on demand and destroyed/de-allocated when not in use) in
RT-CCM. Resources should be dynamically allocated for systems that
primarily have \emph{bursty} client request invocation patterns. On the 
other hand, for systems with a constant request invocations per unit 
time, statically allocated resources should be used. In this case, 
the amortized cost associated with exclusive allocation of system 
resources is justified and economical compared to creating resources on the fly.

\item RT-CCM allows for compartmentalization of thread resources by allowing
configuration of \emph{ThreadPool} with \emph{Lanes}. All thread resources 
that belong to a \emph{ThreadPool Lane} have the same priority value. Using 
separate \emph{Lanes} for servicing client invocations at individual priority
values prevents exhaustion of threads by low priority requests. Therefore, sufficient
\emph{Lanes} should be configured for server components such that all of its 
client priority levels can be serviced.

\item In order to minimize client-side priority inversions due to queuing of high priority
invocations following those at lower priorities, RT-CCM provides \emph{Priority Banded 
Conections} to program client components to use distinct pre-assigned connections for 
separate invocation priority ranges. 

\end{NumList}
\fi
Real-time requirements have component-level granularity.  
\iffalse
Depending on the 
implementation of a CCM component, it may play the following two
roles: (1) service provider \emph{i.e.}, a server component that
provides certain functionality to other component(s) and (2) service
consumer \emph{i.e.}, a client component that requires certain
functionality from other component(s). 
\fi
A \texttt{RT\-Re\-qu\-ir\-em\-ent}
element which is derived from \texttt{Requirement}, captures real-time requirements of a component 
and may have the following two attributes:% depending on its role: 
(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.  

\noindent\textbf{Publish/subscribe QoS requirements.}
\label{ec-req}
We have modeled requirements 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.

The \texttt{ECRequirement} element is derived from \texttt{Requirement}.
It models the properties of the 
event channel and can be used to specify the following QoS requirements: 
(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
requirements have an enumerated data type with values \texttt{LO} and
\texttt{HI}.

\subsection{Modeling middleware QoS options}
\label{sec:cqmlmodel}
Rather than directly transforming source models of DRE system into 
configuration descriptors 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. We
have developed interpreters for parsing CQML system models
and generating deployment descriptors in preparation of
deploying the DRE system on target environment.
\iffalse
Such an approach 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.%~\cite{Schmidt:06x}.
\item Using models of application at each step of
software development increases traceability as QoS 
requirements are translated to low-level QoS options \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 requirements 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}
\fi

\noindent\textbf{Real-time QoS options.} 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 setting 
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 
{\sc client\_propagated} if the invocation priority is preserved, or 
{\sc server\_declared} if the server component changes the priority of 
invocation. (4) \texttt{BandedConnections}, which defines separate connections
for individual (client) service invocations.

\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 contain 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).


\subsection{Model transformations 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. They are applicable to any system model that
conforms to the Requirements 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.

\noindent\textbf{Mapping real-time QoS requirements.} 
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]
\caption{Real-time QoS requirements 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 requirements.} 
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]
\caption{Publish/Subscribe service QoS requirements 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). 

\noindent\textbf{Resolving Challenges 1 \& 2:} 
Target typed graph elements (\emph{i.e.}, QoS options), are
well-understood by implementation middleware experts.  QUICKER
transformation algorithms~\ref{alg:rt-map} and ~\ref{alg:ec-map} are
designed in terms of source and target typed graphs by these
experts.  System developers can describe their system QoS requirements
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 requirements, 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.  

