%%% $Id: intro.tex,v 1.8 2005/02/15 09:43:36 gokhale Exp $
\section{Introduction}
\label{intro}

\subsection*{Emerging Trends and Challenges}

% showcase salient features of DHPS systems
Large-scale, distributed, high performance software (DHPS) systems
form the basis of numerous scientific grid computing applications.  
DHPS systems comprise many interdependent artifacts, such as
network/bus interconnects, many coordinated local and remote
endsystems, and multiple layers of software. DHPS systems demand
multiple simultaneous quality of service (QoS) properties including
predictability, controllability, and adaptability of operating
characteristics for applications with respect to such features as
time, throughput, accuracy, confidence, security and
synchronization.  All these issues become highly volatile in
large-scale DHPS systems, due to the dynamic interplay of the many
interconnected parts that are often constructed from smaller parts.

Although it is possible in theory to develop these types of complex
DHPS systems from scratch, contemporary economic and organizational
constraints, as well as increasingly complex requirements and
competitive pressures, make it infeasible to do so in
practice. A key enabler in recent successes with DHPS systems has been
{\em QoS-enabled middleware}~\cite{Schmidt:01o}, such as
Globus~\cite{Globus:97}.

% folks I don't think this figure is needed either - Andy
\iffalse
, as shown in Figure~\ref{fig:mw-layers}. 

\begin{figure}[htb]
\begin{center}
\includegraphics[width=2.1in]{../Sigmetrics-2005/eps/mw-layers2.eps}
\bfcaption{Middleware Stack}
\label{fig:mw-layers}
\end{center}
\end{figure}
\fi

Middleware comprises software layers that provide platform\--independent
execution semantics and reusable services that coordinate how
application components are composed and interoperate. The primary
role of middleware is to (1)~functionally bridge the gap between
application programs and the lower-level hardware and software
infrastructure in order to coordinate how parts of applications are
connected and how they interoperate, (2)~enable and simplify the
integration of components developed by multiple technology suppliers,
and (3)~provide common reusable accessibility for functionality and
patterns by factoring out artifacts from applications into reusable
code. 

% our vision
The flexibility and configurability offered by middleware is
manifested in the large number of reusable software building blocks
and configuration options, which can be used to compose and build large
systems end to end. These building blocks embody good design practices
called patterns~\cite{Vlissides:94,Schmidt:00a}. The choice of the
pattern to use is dependent on the context and the consequences of
using the pattern.

\iffalse
% commented out - Andy
Figure~\ref{fig:posa2-plop} depicts a number of such interacting 
patterns. Many patterns may often provide
similar functionality but their suitability is dependent on the specific
operation contexts. For example, the {\em Active Object} and {\em
Leader-follower}~\cite{Schmidt:00a} patterns provide alternate approaches to 
concurrency with each solution having its own advantages and 
disadvantages. Although the Active Object pattern 
is simple to implement, it incurs an
additional performance penalty due to thread context switching and
message queueing. On the other hand, the Leader-Follower does
not incur these drawbacks, but its implementation is very complex and
might lead to race conditions. Developers of
DHPS systems need to make the right choices of patterns to use in their
solutions, such that the end-to-end QoS and functional requirements of
the DHPS systems are met. The choice of the patterns to use are
driven by various factors including the context in which the DHPS
system will be deployed, concurrency and distribution requirements of
the application, and other QoS concerns, such as end-to-end latency
and timeliness requirements for real-time DHPS systems or
throughput for other applications (e.g., a telecommunication call
processing switch). 

% Jeff: The figure below is very hard to read when printed on paper.
\begin{figure}[htb]
\begin{center}
\mbox{\includegraphics[width=3in]{../Sigmetrics-2005/eps/posa2-plop.eps}}
\bfcaption{Middleware Patterns and Pattern Languages}
\label{fig:posa2-plop}
\end{center}
\end{figure}
\fi

Current {\em ad hoc} techniques based on manually choosing the right 
set of building blocks are error-prone and may adversely impact
performance, system costs and schedules, since most errors are caught
very late in the lifecycle of DHPS development. It is desirable to
have the ability to analyze the performance of individual building
blocks and the composed system much earlier in the lifecycle of
DHPS systems, thereby significantly lowering system testing costs as
well as improving correctness of the final developed system. 

To address the challenges of performance evaluation of DHPS systems
design, a systematic performance analysis methodology is necessary. 
This methodology would comprise performance models of the 
individual building blocks and the composition of the building blocks.
The performance models are based upon well-known 
%Jeff: mrm and fspn not in the bibtex
% DONE
%analytical/numerical modeling paradigms~\cite{mrm,evol-spn,mrspn,fspn-1} and 
analytical/numerical modeling paradigms~\cite{evol-spn,mrspn,fspn-1} and 
% Jeff: citation needed below
% Ok, I added something - Andy
simulation techniques~\cite{NS-2}. As a first step towards the development
of such a methodology, this paper presents a model of the 
Reactor pattern~\cite{Schmidt:00a}, which provides the very important 
synchronous demultiplexing and dispatching capabilities in 
DHPS systems. The model is based on the 
Stochastic Reward Net (SRN) modeling paradigm~\cite{evol-spn}. 
We illustrate how the model can be used 
to obtain estimates of key performance metrics 
and for the sensitivity analysis of the Reactor pattern with relative ease. 

\subsection*{Paper Organization}

%Jeff: If anyone agrees with my comments about combining sections 2 and 3,
%then the following would need to be changed.
% DONE _ andy
This paper is organized as follows: 
Section~\ref{sec:background} provides an overview of performance
modeling techniques we use followed by related work; 
Section~\ref{sec:reactor_perf} presents the SRN model of the Reactor 
pattern, and illustrates the use of the model through examples;
and finally Section~\ref{sec:conclusions}
offers concluding remarks and directions for future research. 
