%
%  $Id: challenges.tex,v 1.12 2004/11/04 02:58:49 gokhale Exp $
%
% goal of this file is to discuss the challenges in developing DRE
% systems. We need to make a case that these systems are going to be
% assembled from middleware components. 
\section{Technical Challenges Developing DPSS Systems}
\label{sec:challenges}

Section~\ref{intro} discussed how the next generation of DPSS
systems are increasingly being developed and deployed using reusable
middleware building blocks. This section elaborates on the
patterns-based building blocks provided by contemporary middleware
technologies eliciting the technical difficulties DPSS developers will
face when constructing these systems. Furthermore, we provide details on
the Reactor~\cite{Schmidt:00a} pattern, which is the 
focus for performance evaluation in this paper.

\subsection{Patterns-based Building Blocks in Middleware}
\label{sec:posa2}

Figure~\ref{fig:posa2-plop} illustrates a family of patterns forming a
pattern language~\cite{Alexander:77} for DPSS systems. A software
pattern codifies recurring solutions to a particular problem occurring
in different contexts, which is embodied as a reusable software
building block. When designing DPSS systems, its developers will be
required to decide the right set of patterns to use in the system
composition, such that the desired end to end QoS and functional
requirements are met. The choice of the patterns to use are
driven by various factors including the context in which the DPSS
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 DPSS systems or
throughput for other applications (e.g., a telecommunication call
processing switch). 

\begin{figure}[htb]
\begin{center}
\mbox{\includegraphics[width=3in]{eps/posa2-plop.eps}}
\bfcaption{Middleware Patterns and Pattern Languages}
\label{fig:posa2-plop}
\end{center}
\end{figure}

Figure~\ref{fig:posa2-plop} depicts a number of interacting
patterns. Patterns, such as the {\em Active Object} and {\em
Leader-follower}~\cite{Schmidt:00a} provide alternate approaches to concurrency with each
solution having its own advantages and disadvantages. For example,
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. Other patterns like the {\em Reactor}
and {\em Proactor}~\cite{Schmidt:00a} provide solutions to synchronous and asynchronous
event demultiplexing and dispatching, respectively. Both of these
patterns provide the building block of the asynchronous part of 
the {\em half-sync/\-half-async} pattern shown in
Figure~\ref{fig:posa2-plop}. Patterns, such as the {\em Asynchronous
Completion Token} pattern can be used only in those cases where the
underlying platform can support asynchronous messaging. Developers of
DPSS 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 DPSS systems are met. 

Contemporary middleware technologies provide these reusable
building blocks to the DPSS developers. However, the responsibility of
making the right choice rests on the developers. Moreover, without any
estimates of expected end-to-end performance provided by the
middleware, DPSS developers are forced to rely on rigorous testing
later in the lifecycle to determine if the design choices were
appropriate. Unfortunately, these decision occur very late in the
lifecycle of DPSS systems, which adversely impacts costs and
schedules. A mechanism is needed that will enable
performance estimation of composable systems at design time. It is
well understood that any changes at design-time are much easier to
incorporate into the system. Moreover, the higher-levels of
abstraction and formalism provided by the design-phase makes it
possible to formally verify the systems for correctness. 

Model-driven Software Development (MDSD)~\cite{MDA:01,Janos:03}
has gained prominence in assisting DPSS developers to make the right
choices in designing and composing large systems. Model-based
performance analysis can be used to analyze the performance of
patterns-based DPSS systems. In order to facilitate the use of
model-based performance analysis, however, it is necessary for MDSD
tools to provide analytical models of the various possible
patterns. These models can be used to estimate the performance of each
pattern when used in different configurations and
contexts. Subsequently, these models can be used in a plug-and-play
fashion to form larger models corresponding to composition of patterns
in the DPSS system. This paper focuses on using Stochastic Reward
% need citation
Nets (SRNs)~\cite{evol-spn} as a paradigm to model middleware patterns. Our
technique is showcased in Section~\ref{sec:srn} in the
context of the Reactor pattern~\cite{Schmidt:00a}, which is described
briefly in Section~\ref{sec:reactor}.  

\subsection{Reactor Pattern and Middleware Implementations}
\label{sec:reactor}

Figure~\ref{fig:mw-demux} depicts a typical event demultiplexing and
dispatching mechanism documented in the Reactor pattern. The
application registers an event handler with the event demultiplexer
and delegates to it the responsibility of listening for incoming
events. On occurrence of an event, the demultiplexer dispatches the
event by making a callback to the right application-supplied event
handler. This is the idea behind the Reactor pattern, which provides
synchronous event demultiplexing and dispatching capabilities.

\begin{figure}[htb]
\begin{center}
\includegraphics[width=2.3in]{eps/demux.eps}
\bfcaption{Event Demultiplexers in Middleware}
\label{fig:mw-demux}
\end{center}
\end{figure}

The Reactor pattern could be implemented in many different ways
depending on the event demultiplexing capabilities provided by the
operating systems and the concurrency requirements of the
applications. For example, the demultiplexing capabilities of a
Reactor could be based on the {\em select} or {\em poll} system calls
provided by POSIX-compliant operating systems or {\em
WaitForMultipleObject} as in the different flavors of Win32 operating
systems. Moreover, the handling of the event in the event handler
could be managed by the same thread of control that was listening for
events giving rise to a single-threaded Reactor
implementation. Alternately, the event could be delegated to a pool of
threads to handle the events to give rise to a thread-pool
Reactor. Delegation of events to one of the threads of the thread pool
can be implemented using either the {\em Leader-Follower} or the {\em
Active Object} patterns mentioned earlier. These different choices are
dictated by the requirements of the application.
