% $Id: ngs06.tex,v 1.9 2006/01/30 16:21:08 gokhale Exp $

\documentclass[10pt,twocolumn]{article}
\usepackage{ipdps}

\usepackage{graphicx}
\usepackage{epsfig}
\usepackage{url}
\usepackage{cite}

\input macros
\usepackage{vmargin}%
\setpapersize{USletter} %
\setmargnohf{0.8125in}{1in}{6.875in}{8.875in}


\graphicspath{{./}{../}{../../ISSRE-2005/}{../../SRDS-2005/}}
%-------------------------------------------------------------------------
% take the % away on next line to produce the final camera-ready version
\pagestyle{empty}

%-------------------------------------------------------------------------

% the twoaffiliations environment is used to make a table of two
% affiliations. You will use N twoaffiliations commands if you have 2N
% affiliations. If you have an odd # of affiliations, then the last
% one has to be printed using the oddaffiliation environment

\newenvironment{twoaffiliations}{\begin{tabular}{cc}}{\end{tabular}}
\newenvironment{oddaffiliation}{\begin{center}}{\\~\\\end{center}}




\title{Model-driven Generative Techniques for Scalable
Performabality Analysis of Distributed Systems\thanks{This research was 
supported in part by a collaborative grant from the National Science
Foundation (CSR-SMA).}}


\author{Arundhati Kogekar$^1$, Dimple Kaul$^1$, Aniruddha Gokhale$^1$,
  \\Paul Vandal$^2$, Upsorn Praphamontripong$^2$, Swapna Gokhale$^2$,
  \\Jing Zhang$^3$, Yuehua Lin$^3$, Jeff Gray$^3$
 ~ \\
 ~ \\
\begin{twoaffiliations}
$^1$Vanderbilt University            & $^2$University of Connecticut\\
Dept. of Electrical Engineering  & Dept. of Computer Science \\
and Computer Science  & and Engineering \\
Nashville, TN 37235  USA & Storrs,  CT 06269 USA \\
\{akogekar,dkaul,gokhale\}@dre.vanderbilt.edu     &  
\{ssg\}@engr.uconn.edu \\
~ \\
\multicolumn{2}{c}{$^3$University of Alabama at Birmingham} \\
\multicolumn{2}{c}{Dept of Computer and Information Science} \\
\multicolumn{2}{c}{Birmingham, AL USA} \\
\multicolumn{2}{c}{\{zhangj,liny,gray\}@cis.uab.edu} 
\end{twoaffiliations} %%
% for some reason this madness is not working so I am using the
% multicolumn trick
\iffalse
\and
\begin{oddaffiliation}
\begin{tabular}{c}
$^3$University of Alabama at Birmingham \\
Dept. of Computer and Information Sciences \\
Birmingham, AL 35294 USA \\
gray@cis.uab.edu 
\end{tabular}
\end{oddaffiliation}
\fi
}


\begin{document}


\maketitle
\thispagestyle{empty}

\begin{abstract}

The ever increasing societal demand for the timely availability of
newer and feature-rich but highly dependable network-centric
applications imposes the need for these applications to be constructed
by the composition, assembly and deployment of off-the-shelf
infrastructure and domain-specific services building blocks.  Service
Oriented Architecture (SOA) is an emerging paradigm to build
applications in this manner by defining a choreography of loosely
coupled building blocks.  However, current research in SOA does not
yet address the performability (i.e., performance and dependability)
challenges of these modern applications.  Our research is developing
novel  mechanisms to address these challenges.  We
initially focus on the composition and configuration of the
infrastructure hosting the individual services.  We illustrate the use
of domain-specific modeling languages and model 
weavers to model infrastructure composition using middleware building
blocks, and to enhance these models with the desired performability
attributes.  We also demonstrate the use of generative tools that
synthesize metadata from these models for performability validation
using analytical, simulation and empirical benchmarking tools.

{\bf Keywords: Model driven development, Generative programming,
  Performability}

\end{abstract}

\renewcommand{\thefootnote}{}
%\footnotetext{\hspace{-2em} FOOTNOTE GOES HERE}


%-------------------------------------------------------------------------
\Section{Introduction}

Society is increasingly reliant on a wide array of applications (e.g.,
electric power grid, mobile communications, health care,
entertainment) provided by distributed networked systems.  Rapid
advances in networking and hardware technologies, and increased
competition, is requiring service providers to rapidly introduce newer
applications to the market.  Service providers, however, now have to
deal with two major forces.  On the one hand they must reduce the {\em
  time to market} while on the other hand they must ensure that the
applications continue to provide high performance and dependability --
the so called {\em performability} of the applications.  The Service
Oriented Architecture (SOA)~\cite{SOA_ERL:06} provides a mechanism by
which new applications can be defined as a choreography of loosely
coupled services.

Recent trends in software design indicate that the use of
prefabricated building blocks for software development is on the rise.
The prefabricated artifacts are the off-the-shelf (COTS) software
infrastructure and domain-specific service components that one can
acquire from different vendors and assemble them to deploy large-scale
applications.  Modern applications designed using SOA
use these concepts to form component
assemblies that are deployed on distributed resources.  Component
middleware technologies,  
\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
such as J2EE~\cite{J2EE:01},
.NET~\cite{DotNet:02} and CORBA Component Model
(CCM)~\cite{CorbaComponents:02}, coupled with advances in
technologies, such as SOAP~\cite{SOAP:00}, WSDL~\cite{WSDL:01} and
XML~\cite{XML:00}, 
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
such as J2EE, .NET and CORBA Component Model (CCM), coupled with
advances in technologies, such as SOAP, WSDL and XML, 
are increasingly being used to provision such
applications since they enable the construction of application
functionality dynamically by connecting individual component
functionalities spread across distributed resources.    

Although these advances in software development are necessary for the
rapid development of new applications, service providers are now
required to ascertain whether the choice of the components, and their
configurations and compositions will provide the required levels of
performance and dependability.  This analysis must be performed in the
early phases of the application's life cycle~\cite{bbook-new} (i.e.,
at design time).  Design-time performability analysis is almost
invariably based on a model that represents application behavior.  For
example, in order to enable model-based performability analysis of
event-driven applications, it is necessary to build a model of the
underlying event demultiplexing framework that is ubiquitous in such
applications. In the past, design-time performability analysis has been
conducted on a per-application basis, but this methodology does not
scale as service providers are required to deploy newer applications.


Our focus is on developing and implementing novel techniques to
conduct design-time performability analysis of applications built
using the SOA approach.  This problem requires a two-level design-time
performability approach.   At the first level it is necessary to
ascertain that the configuration and composition of individual
infrastructures at different nodes in the distributed system provide
the desired performability guarantees.  At the second level, we
require the need for performability analysis for the assembly of
services.  Our previous work~\cite{Gokhale_Globecom05,Gokhale_PMEO:06}
applied analytical methods for
design-time performability analysis of event demultiplexing patterns in
network services, such as virtual private networks.  In this previous
work we described the manual development and validation of analytical
models for patterns-based middleware building blocks.   

In this paper we first describe the manual process in developing a
Stochastic Reward Net (SRN)~\cite{rel-srn}, which is an analytical
performability model for patterns-based building blocks.  We then show
how the manual development process becomes infeasible and cannot scale
since the middleware building blocks provide numerous configuration
parameters that affect their behavior.  This problem is further
complicated when such building blocks are composed to form larger
systems (Note: Other kinds of performability analysis, such as
  simulations or empirical benchmarking will exhibit similar
  challenges).  To address these concerns we describe a framework 
comprising model-driven generative tools~\cite{Janos:97,MDA:01}, which
enables the automatic synthesis of scalable SRN performability models,
simulations and empirical benchmarks for services that are modeled as
a composition of patterns-based middleware building blocks. 

This paper is organized as follows: 
Section~\ref{sec:reactor_perf} discusses the process of building a
performability model of the reactor pattern using the SRN modeling
paradigm;  Section~\ref{sec:mdd} describes how the performability
analysis process can be scaled and automated using a model-driven
generative framework; 
\iffalse
Section~\ref{sec:eval_perf} illustrates the use of
our MDD framework for performability analysis of a application on mobile
devices;
\fi 
Section~\ref{sec:relwork} discusses our work comparing it to
related work; and finally Section~\ref{sec:conclusions} provides
concluding remarks outlining the lessons learned from this study, as
well as directions for future research. 


%-------------------------------------------------------------------------

\Section{Developing a Performability Model of a Middleware Building Block} 
\label{sec:reactor_perf}

In this section we describe the process of constructing a Stochastic
Reward Net (SRN)~\cite{rel-srn} model of a representative middleware
building block.  We focus on the reactor pattern~\cite{Schmidt:00a},
which provides synchronous demultiplexing and dispatching capabilities
by decoupling these from event handling.  Such decoupling is useful
for building event-driven systems.  In developing a model for a reactor
requires identifying the different characteristics and performability
measures of the reactor.  A SRN model of the reactor pattern is then
presented along with a discussion of how the performability measures can
be obtained by assigning reward rates at the net level. We conclude
the section with a discussion of the scalability challenges involved
in constructing the performability models.    

\SubSection{Characteristics of the Reactor Performability Model}
\label{sec:reactor_modeling}

In our performability model of the reactor, we consider a
single-threaded, select-based implementation of the reactor pattern
with the following characteristics, as shown in
Figure~\ref{fig:reactor_model_params}:

\begin{figure}[ht]
\center{\includegraphics[width=3.7in]{eps/reactor_perf_model.eps}}
\bfcaption{Characteristics of the Reactor}
\label{fig:reactor_model_params}
\end{figure}

\begin{itemize}%\crunchlist
\item The reactor receives two types of input events with one
      event handler for each type of event registered with the reactor.
\item Each event type has a separate queue, which holds the incoming
      events of that type. The buffer capacity for the queue of type
      \#1 events is denoted $N_1$ and of type \#2 events is denoted $N_2$.
\item Event arrivals for both types of events follow a Poisson
      distribution with rates $\lambda_1$ and $\lambda_2$, while the
      service times of the events are exponentially distributed with
      rates $\mu_1$ and $\mu_2$. 
\item In a given snapshot, if the event handles corresponding to both 
      the event types are enabled, then they are serviced in no particular
      order. In other words, the order in which the events are handled 
      is non-deterministic.  
\end{itemize}

The following performability metrics are of interest for each one of
the event types in the reactor pattern model:

\begin{itemize}%\crunchlist
\item {\bf Expected throughput} -- which provides an estimate of the number
      of events that can be processed by the single threaded event
      demultiplexing framework. These estimates are important for
      many applications, such as telecommunications call processing.
\item {\bf Expected queue length} -- which provides an estimate of the
      queuing for each of the event handler queues. These estimates are
      important to develop appropriate scheduling
      policies for applications with real-time requirements.
\item {\bf Expected total number of events} -- which provides an estimate of
      the total number of events in a system. These estimates are also
      tied to scheduling decisions. In addition, these
      estimates will determine the right levels of resource
      provisioning required to sustain the system demands.
\item {\bf Probability of event loss} -- which indicates how many events
      will have to be discarded due to lack of buffer space. These
      estimates are important particularly for safety-critical
      systems, which cannot afford to lose events. These
      also provide an estimate of the desired levels of resource
      provisioning. 
\end{itemize}

\SubSection{SRN Model of the Reactor Pattern}
\label{sec:srn}
SRNs represent a powerful modeling technique that is concise in its
specification and whose form is closer to a designer's intuition about
what a model should look like.  Since a SRN specification is closer to
a designer's intuition of system behavior, it is also easier to
transfer the results obtained from solving the models and interpret
them in terms of the entities that exist in the system being
modeled. An overview of SRNs can be found in ~\cite{evol-spn}. 
Stochastic reward nets have been extensively used for performability,
reliability and performability analysis of a variety of
systems~\cite{ramani00,avail-vax,poll-perf,man-perf,queue-perf,rel-srn}.
The work closest to our work is reported by Ramani {\em
et al.}~\cite{ramani00}, where SRNs are used for the performability
analysis of the CORBA event service. The CORBA event service is 
yet another pattern that provides publish/subscribe services.   

\paragraph*{Description of the net:} Figure~\ref{fig:pn_non_det} shows the 
SRN model for the Reactor pattern. 
%described in Section~\ref{sec:reactor}. 
The net is comprised of two parts. Part (a)
models the arrival, queuing, and service of the two types of events
as explained below. Transitions $A1$ and $A2$ represent the  
arrivals of the events of types one and two, respectively. 
Places $B1$ and $B2$ represent the queue for the two
types of events. Transitions $Sn1$ and $Sn2$ are immediate transitions
which are enabled when a snapshot is taken. Places $S1$ and $S2$ 
represent the enabled handles of the two types of events, whereas 
transitions $Sr1$ and transition $Sr2$ represent the execution of
the enabled event handlers of the two types of events. An inhibitor
arc from place $B1$ to transition $A1$ with multiplicity $N1$ prevents 
the firing of transition $A1$ when there are $N1$ tokens in the 
place $B1$. The presence of $N1$ tokens in the place $B1$ indicates
that the buffer space to hold the incoming input events of the first
type is full, and no additional incoming events can be accepted.
The inhibitor arc from place $B2$ to transition $A2$ achieves
the same purpose for type two events.

\begin{figure*}[htb]
\centerline{\includegraphics[width=4.5in]{eps/pn-non-det.eps}}
\caption{SRN model of the Reactor pattern}
\label{fig:pn_non_det}
\end{figure*}

Part (b) models the process of taking successive snapshots and
non-deterministic service of event handles in each snapshot 
as explained below. Transition $Sn1$ is enabled when there 
are one or more tokens in place 
$B1$, a token in place $StSnpSht$, and no token in place $S1$. Similarly,
transition $Sn2$ is enabled when there are one or more tokens in place 
$B2$, a token in place $StSnpSht$ and no token in place $S2$. Transition
$T\_StSnp1$ and $T\_StSnp2$ are enabled when there is a token in either
place $S1$ or place $S2$ or both. Transitions $T\_EnSnp1$ and $T\_EnSnp2$
are enabled when there are no tokens in both places $S1$ and $S2$. 
Transition $T\_ProcSnp2$ is enabled when there is no token in place $S1$,
and a token in place $S2$. Similarly, transition $T\_ProcSnp2$ is enabled
when there is no token in place $S2$ and a token in place $S1$.
Transitions $Sr1$ is enabled when there is a token 
in place $SnpInProg1$, and transition $Sr2$ is enabled when there is 
a token in place $SnpInProg2$. 

\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
Table~\ref{table:enable} summarizes
the enabling functions for the transitions in the net shown in 
Figure~\ref{fig:pn_non_det}.         

\begin{table*}[hbt]
\begin{center}
\caption{Guard functions}
\label{table:enable}
\begin{tabular}{|c|c|} \hline
Transition & Guard function \\ \hline 
$Sn1$ & $((\#StSnpShot == 1) \&\& (\#B1 >= 1) \&\& (\#S1 == 0)) ? 1:0$ \\ \hline 
$Sn2$ & $((\#StSnpShot == 1) \&\& (\#B2 >= 1) \&\& (\#S2 ==0)) ? 1:0$ \\ \hline 
$T\_StSnp1$ & $((\#S1 == 1) || (\#S2 == 1)) ? 1:0$ \\ \hline 
$T\_StSnp2$ & $((\#S1 == 1) || (\#S2 == 1)) ? 1:0$ \\ \hline 
$T\_ESnpSht1$ & $((\#S1 == 0 \&\& (\#S2 == 0)) ? 1:0$ \\ \hline 
$T\_ESnpSht2$ & $((\#S1 == 0 \&\& (\#S2 == 0)) ? 1:0$ \\ \hline 
$T\_ProcSnp1$ & $((\#S1 == 1 \&\& (\#S2 == 0)) ? 1:0$ \\ \hline 
$T\_ProcSnp2$ & $((\#S1 == 0 \&\& (\#S2 == 1)) ? 1:0$ \\ \hline 
$Sr1$ & $(\#SnpInProg1 == 1) ? 1:0$ \\ \hline 
$Sr2$ & $(\#SnpInProg2 == 1) ? 1:0$ \\ \hline 
\end{tabular}
\end{center}
\end{table*}
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%

\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
\paragraph*{Dynamic evolution of the net:} We explain the process of
taking a snapshot and servicing the enabled
event handles in the snapshot with the help of an example. We consider
a scenario where there is one token each in places $B1$ and $B2$. 
Due to the presence of tokens in places $B1$ and $B2$, and a token in
place $StSnpSht$, transitions $Sn1$ and $Sn2$ are enabled. Both these
transitions are assigned the same priority, and hence either one of
them can fire. Without loss of generality, we assume that transition
$Sn1$ fires first, which deposits a token in place $S1$. The presence
of a token in place $S1$ and place $StSnpSht$ enables transition  
$T\_StSnp1$. Also, transition $Sn2$ is already enabled. If transition
$T\_StSnp1$ were to fire before transition $Sn2$, the firing of
transition $Sn2$ would be precluded. In order to prevent this from
happening, transition $Sn2$ is assigned a higher priority than transition
$T\_StSnp1$, so that transition $Sn2$ fires before $T\_StSnp1$ when
both are enabled. Firing of transition $Sn2$ deposits a token in place
$S2$ which enables transition $T\_StSnp2$. Transitions $T\_StSnp1$
and $T\_StSnp2$ are both enabled, corresponding to the event handles
of both types of events. If transition $T\_StSnp1$ fires before 
$T\_StSnp2$, then event handle for the first type of event will
be executed prior to event handle for the second type of event.
On the other hand, $T\_StSnp2$ fires before 
$T\_StSnp1$, then event handle for the second type of event will
be executed prior to event handle for the first type of event.
Both the transitions $T\_StSnp1$ and $T\_StSnp2$ have an equal
chance of firing, and this represents the non-determinism in the
execution of the enabled event handles. Without loss of generality,
we assume transitions $T\_StSnp1$ fires depositing a token in 
place $SnpInProg1$, which enables transitions $Sr1$.
Additionally, firing of transition $T\_StSnp1$ precludes the
firing of transition $T\_StSnp2$ and vice versa. 
Once transition $Sr1$ fires, a token is removed from 
place $S1$, after which transition $T\_ProcSnp2$ fires and deposits
a token in place $SnpInProg2$. A token in place $SnpInProg2$ enables
transition $Sr2$. Firing of $Sr2$ removes the token from place
$S2$. Once $Sr2$ fires, there are no tokens in places $SnpInProg1$
and $SnpInProg2$, which enables transition $T\_EnSnp2$. The firing
of $T\_EnSnp2$ marks the completion of the present snapshot, and 
the beginning of the next one.  
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%

\paragraph*{Assignment of reward rates:} The performability measures
described in Section~\ref{sec:reactor_modeling} can be computed  
by assigning reward rates at the net level as summarized in 
Table~\ref{table:rr}. The throughputs $T_1$ and $T_2$ are respectively
given by the rate at which transitions $Sr1$ and $Sr2$ fire. 
The queue lengths $Q_1$ and $Q_2$ are given by the average number 
of tokens in places $B1$ and $B2$, respectively. The total number of events
$E_1$ is given by the sum of the number of tokens in places $B1$ and $S1$.
Similarly, the total number of events $E_2$ is given by the sum of the
number of tokens in places $B2$ and $S2$. The loss 
probability $L_1$ is given by the probability of $N1$
tokens in place $B1$. Similarly, the loss probability $L_2$ is given by
the probability of $N2$ tokens in place $B2$.  

\begin{table}[htb]
\begin{center}
\caption{Reward assignments to obtain performability measures}
\label{table:rr}
\begin{tabular}{|c|c|} \hline
Performability metric & Reward rate \\ \hline 
$T_1$ & return rate($Sr1$) \\ \hline 
$T_2$ & return rate($Sr2$)  \\ \hline 
$Q_1$ & return ($\#B1$)  \\ \hline 
$Q_2$ & return ($\#B2$)  \\ \hline 
$L_1$ & return ($\#B1 == N1 ? 1:0$) \\  \hline 
$L_2$ &  return ($\#B2 == N2 ? 1:0$) \\ \hline 
$E_1$ & return($\#B1 + \#S1$) \\ \hline 
$E_2$ & return($\#B2 + \#S2$) \\ \hline 
\end{tabular}
\end{center}
\end{table}

After the model is developed, it must be solved to determine how the
system will perform for the given workloads.  Our previous
work~\cite{Gokhale_Globecom05,Gokhale_PMEO:06} describes the results
of solving the SRN models for the reactor pattern with event handling
priorities. Validation of the performability measures obtained from SRN
model using CSIM is also described in our earlier work~\cite{Gokhale_PMEO:06}.

\SubSection{Scalability Challenges}
\label{sec:srn-scalability}
The previous section described the manual process of constructing a SRN
model for the reactor pattern and assigning reward rates to obtain the
different performability measures.  Many different variations of the
reactor pattern are possible depending on the configuration parameters
used.  These variations stem from the different event demultiplexing
and event handling strategies used in a reactor.  For example, in
network-centric applications, networking events can be demultiplexed
using operating system calls, such as {\tt select} or {\tt poll}.  For
graphical user interfaces (GUIs), these events could be due primarily
to mouse clicks and can be handled by GUI frameworks like Qt or Tk.
On the other hand, the event handling mechanisms could involve a
single thread of control that demultiplexes and handles an event, or
each event could be handled concurrently using worker threads in a
thread pool or by thread on demand. 

Other variations stem from the number of event types handled, the
buffer space available for queuing events, input workloads and event
service rates.  To enable design-time performability analysis for an
application employing a variant of the reactor pattern, the SRN model
of the variant needs to constructed manually.  This process is
cumbersome, tedious and time-consuming.  These challenges are further
complicated when systems are composed of several middleware building
blocks.  There is a need to automatically generate performability models
for different variants based on the performability model, which captures
the invariant characteristics of the pattern and specializing them
with the possible variations.  Section~\ref{sec:mdd} describes our
solution to address these challenges.

%-------------------------------------------------------------------------
\Section{Scaling and Automating the Performability Modeling Process}
\label{sec:mdd}

The previous sections described how a SRN model for performability of
the desired application can be developed.  The process described until
now focuses on manually developing these models and the associated
input scripts used by the model solvers, such as SPNP~\cite{spnp-new}.  
\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
As the
application complexity grows, however, it becomes tedious and error
prone to develop these models manually since the accidental
complexities involved in modeling the system performability
characteristics and the input script sizes for the model solver grow
substantially.  As explained earlier there could be several different event
types that an event demultiplexing and handling framework may have to
handle.  Moreover, it should be possible for a software architect, who
is a non expert in the tools and techniques of performability analysis to
be able to use the model.  To enable these dual objectives, it is
necessary to encapsulate the performability modeling approach described
in the earlier sections into user-friendly tools that enable model
scalability to large systems.  
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
In this section, we describe the
model-driven development (MDD)~\cite{Janos:97,MDA:01} approach, which
allows the user to scale the base SRN models and automate the
process of performability analysis.

\SubSection{Modeling Languages for Performability Analysis}
\label{sec:dsml}
In this section we describe the ideas based on a
model-driven~\cite{MDA:01} generative programming~\cite{Czarnecki:00}
framework we are developing to address the aforementioned challenges.
Our modeling framework comprises modeling languages we have developed
using the Generic Modeling Environment (GME)~\cite{GME:01}.  GME is a
tool that enables domain experts to develop visual modeling languages
and generative tools associated with those languages.  The modeling
languages in GME are represented as metamodels.  A metamodel in GME
depicts a class diagram using UML-like constructs showcasing the
elements of the modeling language and how they are associated with
each other.  The GME environment can then be used by application
developers to model examples that conform to the syntax and semantics
of the modeling language captured in the metamodels.  

We have developed two modeling languages that provide the visual
syntactic and semantic elements required to model the systems
compositions and their performability models (Note: Formal
  descriptions of these modeling languages is beyond the scope of
  this paper).  The first language is called POSAML (Patterns-Oriented
Software Architecture Modeling Language), which models the patterns
described in the POSA~\cite{Schmidt:00a} pattern language.  The POSA
pattern language is a vocabulary describing a set of related patterns
used to develop network services.  The other modeling language is
called SRNML (Stochastic Reward Net Modeling Language), which enables
a user to model the behavior of individual patterns as a SRN.
Additional details on these languages and their capability are
described in our recent work~\cite{Gokhale_DSN_PDS:06}.

\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
Figures~\ref{fig:posa-meta-bench} and~\ref{fig:posa-meta-conf}
illustrate two different views of the metamodel for the
POSAML language.  
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
Figure~\ref{fig:posa-meta-bench} illustrates the benchmarking view of
the metamodel for the POSAML language.  POSAML allows a user to
describe the middleware as a collection of patterns.  
\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
Progress to date on POSAML
enables users to model the Reactor, Acceptor and Connector patterns.
POSAML decouples the middleware structural composition i.e, the way
individual patterns are associated with each other from the
variability modeling in each pattern.  The variability in each pattern
stems from the allowable configurations of each pattern, which can be
modeled using the configuration capabilities of the language.  For
example, an Acceptor pattern can be configured with the transport
protocol and the end point it will use to listen for incoming
requests.  Yet another dimension of modeling permitted by POSAML is
related to benchmarking, a capability enabled by the benchmarking view
of the language.  
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
In the benchmarking view of the system the modeling language enables
users to model the workload characterization for the composed system.
For example, it is possible to model the input arrival patterns of
requests, the service rates of the event handlers in the systems, and
sizes of thread pools. 

\begin{figure}[!htb]
\centering\includegraphics[width=\columnwidth]{eps/benchmarking_meta.eps}
\caption{POSAML Metamodel: Benchmarking View}
\label{fig:posa-meta-bench}
\end{figure}

\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
\begin{figure}[!htb]
\centering\includegraphics[width=\columnwidth]{eps/features_meta.eps}
\caption{POSAML Metamodel: Configuration View}
\label{fig:posa-meta-conf}
\end{figure}
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%

Built in constraint checking in POSAML enables correct by construction
structure of system compositions since any erroneous associations
between different patterns are flagged as an error at modeling time.
Moreover, the feature modeling view and benchmarking view of the
language also flags errors when a model engineer commits errors.  For
example, if an engineer chooses a single threaded reactor demultiplexing
strategy in the feature view but provides a thread pool configuration
in the benchmarking view, then the constraint checker flags this
condition as an error.

Figure~\ref{fig:posa-example} illustrates an example middleware
composition comprising three patterns of the POSAML language.  
\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
The figure illustrates the configuration view of the system.   Such a
configuration will be useful in generating the artifacts for the
empirical benchmarking tests as well as simulations.
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%

\begin{figure}[!htb]
\centering\includegraphics[width=4in]{eps/posaml-example.eps}
\caption{POSAML GME Model for the Reactor Pattern}
\label{fig:posa-example}
\end{figure}

A second language we have developed is the Stochastic Reward Net
Modeling Language (SRNML).  Parts of SRNML are shown in
Figure~\ref{fig:srn-meta}.  SRNML provides the artifacts necessary to
model a system as a SRN.

\begin{figure}[!htb]
%\centering\includegraphics[width=4in]{eps/srn-meta.eps}
\centering\includegraphics[width=3.5in]{eps/SRN_meta.eps}
\vspace{-0.4in}
\caption{SRN Metamodel}
\label{fig:srn-meta}
\end{figure}

Figure~\ref{fig:srn-example} illustrates a sample the SRN model using
SRNML.

\begin{figure}[!htb]
\centering\includegraphics[width=3.in]{eps/SRN_example.eps}
\vspace{-1.0in}
\caption{SRN GME Model of the reactor pattern}
\label{fig:srn-example}
\end{figure}

\SubSection{Generative Tools and Model Scalability}
\label{sec:gen}

The GME environment allows metamodel developers to plugin model
interpreters that can provide various capabilities, such as code
generation or configuration information.

In POSAML to date we have included two model interpreters with
generative capabilities.  The benchmark interpreter described here
traverses all the elements of the model (i.e., Pattern, Feature and
Benchmarking), extracting relevant information and generating an XML
file to drive the simulations and benchmarking.  The relevant
information captured in the synthesized metadata includes:
\begin{enumerate}
  \item the Reactor type (extracted from the Feature Aspect), such as
  a single threaded or multi-threaded.
  \item the desired metrics, such as whether the measurements should
  include latency or throughput or both.
  \item the number of data exchanges (which is basically the number of
  times one client thread generates events for the reactor).
  \item the number of client threads (or connections).
  \item the number of event handlers (extracted from the Pattern Aspect)
  \item the service time required by a handler specified as uniform
  distribution or exponential distribution.
  \item arrival pattern of requests modeled as Poisson or periodic
  arrivals. 
\end{enumerate}

Following is a snippet of the XML file generated by the benchmark
interpreter: 
\begin{verbatim}
<benchmark_inputs>
   <connections>5</connections>
   <data>ABCDEF</data> 
   <data_exchanges>200</data_exchanges>
   <reactor_inputs>
   <reactor_type>wfmo</reactor>
      <handlers>2</handlers>
   </reactor_inputs>
 </benchmark_inputs>
\end{verbatim}


\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
The other interpreter in POSAML is the configuration interpreter,
which synthesizes the configuration parameters for each pattern
modeled in the system.
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%

Model scalability is addressed using a model replicator tool we have
developed previously called C-SAW (Constraint-Specification Aspect
Weaver)~\cite{Gray:01}.  The model replication and scalability was
discussed in an earlier work of ours~\cite{Gray-MoDELS05a}. 
We have designed C-SAW to provide support for modularizing
crosscutting modeling concerns as well as scaling models in the GME.
This weaver operates on the internal representation of a model
(similar to an abstract syntax tree of a compiler).  GME provides a
framework that allows metamodel developers to register custom actions
and hooks with the environment.  These hooks can read and write the
elements of a model during the modeling stage.  GME also provides an
introspection API, which provides knowledge about the types and
instances of a model, without {\em a priori} knowledge about the
underlying metamodel.  Utilizing this feature of GME, we have
implemented C-SAW as a ``plug-in,'' which is GME terminology for a
metamodel independent hook.  
\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
Thus, the benefits of C-SAW are
applicable across a whole spectrum of metamodels.  C-SAW is thus
useful to scale the models such as those modeled by POSAML and
SRNML.  
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%


\iffalse

\SubSection{Scaling the Models via Model Replicators}
\label{sec:replicator}

Section~\ref{sec:dsml} describes the modeling languages we have
developed to model the system compositions and the stochastic reward
net models of systems.  


\SubSection{Unresolved Challenges for Model-driven Frameworks} 
\label{sec:mdd-challenges}
In the above sections, we describe how the base model which captures the
essential concepts could be easily scaled using a model-driven framework. 
The scaled model essentially embodies the same characteristics of the 
original base model. In practice, however, it may be necessary to
vary certain characteristics of the base model, in order to create 
``variants'' of the pattern.  For example, some applications that
must provided differentiated levels of service must handle events in a
prioritized manner, and the implementation of such applications will
require a reactor pattern which provides prioritized handling. 
Another possibility is to handle events
concurrently in multiple threads. In the future, we propose
to develop the model-driven framework further, so that creating 
the variants of the base model will be facilitated, in addition
to scaling the models with minimal manual intervention. 

\fi
%-------------------------------------------------------------------------

\Section{Related Work}
\label{sec:relwork}

Performance and dependability analysis of some middleware 
services and patterns has been addressed by some researchers. 
Ramani {\em et al.}~\cite{ramani00}
develop a SRN model for the performability analysis of a CORBA event service,
which is a pattern that provides publish/\-subscribe service.
Aldred {\em et al.}~\cite{aldred05} develop Colored Petri Net
(CPN) models for different types of coupling between the application 
components and with the underlying middleware.  They also define the
composition rules for composing the CPN models if multiple types of
coupling is used simultaneously in an application.  A dominant aspect
of these works are related to application-specific performability
modeling.  In contrast we are concerned with determining how the
underlying middleware that is composed for the systems they host will
perform. 

With the growing complexity of component-based systems, composing 
system-level performance and dependability attributes using the component
attributes and system architecture is gaining attention.  Crnkovic
{\em et al.}~\cite{crnkovic05} classify the quality attributes 
according to the possibility of predicting the attributes of the
compositions based on the attributes of the components and the 
influence of other factors such as the architecture and the 
environment.  However, they do not propose any methods for composing 
the system-level attributes. 

At the model-driven development and program transformation level, 
the work by Shen and Petriu~\cite{Petriu_MODELS05} investigated the use
of aspect-oriented modeling techniques to address performability concerns
that are weaved into a primary UML model of functional behavior.  It has 
been observed that an improved separation of the performability description
from the core behavior enables various design alternatives to be considered
more readily (i.e., after separation, a specific performance concern can be
represented as a variability measure that can be modified to examine the
overall systemic effect).  The performability concerns are specified in the 
UML profile for Schedulability, Performance, and Time (SPT) with underlying 
analysis performed by a Layered Queueing Network (LQN) solver.  

A disadvantage of the approach is that UML forces a specific modeling
language.  The SPT profile also forces performability concerns to be
specified in a manner than limits the ability to be tailored to a
specific performability analysis methodology.  As an alternative,
domain-specific modeling supports the ability to provide a model
engineer with a notation that fits the domain of interest, which
improves the level of abstraction of the performability modeling
process.  Our work falls in the category of developing domain-specific
models for performability analysis. 

%-------------------------------------------------------------------------
\Section{Concluding Remarks}
\label{sec:conclusions}

Time to market pressures and economic reasons are requiring the next
generation of distributed networked services to be developed via
composition and assembly of off-the-shelf reusable components.  The
service providers are now required to reason about the performance and
dependability of such composed systems.  This paper discusses a
framework for design-time performability analysis and validation of
services that are composed, configured and deployed using
patterns-based middleware building blocks.  The performability analysis
models in our study use Stochastic Reward Nets.  However, as shown due
to the substantial variability that exists within every building block
and in their compositions, it is infeasible to manually develop
performability models for large systems.  We presented a model-driven
generative framework that can be used to automatically synthesize
complex SRN models, simulations and empirical benchmarks for the
composed systems.  
\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
We demonstrate the results of solving a SRN model
for the Reactor pattern and validate these results using simulations
generated by our MDD approach. 
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%

Current shortcomings in our work will be addressed as we extend
POSAML to include the additional patterns used in network systems and
address correctness of the compositions.
\iffalse   %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
This will include the ability to compose large-scale systems and
addressing their correctness issues of their compositions.  
\fi        %%%%%%%%%  COMMENTED OUT %%%%%%%%%%%
Additional focus will be on integration of POSAML and SRNML.  The goal
is to use this integrated 
framework to drive performability analysis using analytical models,
simulations and empirical benchmarking of large systems.  Additional
concerns, such as dependability and security, will also be addressed
in combination with the performability dimension addressed in this
paper.  Ultimately, we want to scale our models to handle the
performability evaluation of the distributed assemblies envisioned in
the SOA approach.


%-------------------------------------------------------------------------

\bibliographystyle{ipdps}
\bibliography{networks,analysis,perf-id}



\end{document}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "ngs06"
%%% End: 
