% $Id: reactor.tex,v 1.5 2006/02/12 09:16:39 akogekar Exp $
\subsection{Modeling the Reactor Pattern}
\label{sec:reactor}
The ability to handle and dispatch simultaneously occurring events
effectively without any additional resource overhead is an integral
part of middleware used in a real-time, event-driven and
performance-critical environment. The Reactor architectural pattern~\cite{akogekar:posa2} allows
event-driven applications to demultiplex and dispatch service requests
that are delivered to an application from one or more clients.  The
Reactor pattern inverts the flow of control in a system during
event handling.
Figure~\ref{fig:reactor_structure}~\cite{akogekar:posa2} shows the
structural composition of the reactor pattern.
\begin{figure}[htbp]
	\centering
		\includegraphics[width=10cm]{reactor_pattern}
	\caption{Structural Represenation of the Reactor Pattern}
	\label{fig:reactor_structure}
\end{figure}

The Reactor meta-model that we have developed for POSAML is given in Figure~\ref{fig:reactor_meta}. 
\begin{figure}[htbp]
	\centering
		\includegraphics[width=12cm]{figs/reactor_meta.eps}
	\caption{Metamodel for the Reactor Pattern}
	\label{fig:reactor_meta}
\end{figure}
This meta-model is based on the structural representation of the Reactor pattern that is shown in Figure ~\ref{fig:reactor_structure}. In addition to this, the meta-model includes certain cardinality and relationship constraints (for example, a reactor can be connected to one and only one synchronous event demultiplexer). These constraints ensure that the modeler does not build an incorrect model. 

The Reactor pattern consists of the following participants:
\begin{enumerate}
	\item \textit{Handle}: The handle uniquely identifies event sources
  such as network connections or open files.  Whenever an event is
  generated by an event source, it is queued up on the handle for that
  source and marked as ``ready''. 
	\item \textit{Reactor}: The reactor is the dispatching mechanism of
  the Reactor pattern.  In response to an event, it dispatches the
  corresponding event-handler for that event. 
	\item \textit{Event Handler}: The event handlers are the entities
  which actually process the event.  These are registered with the
  reactor and are dispatched by the reactor when the event for which
  they are registered occurs.
  \item \textit{Handle Set}:  The registered handles form a set called the ``Handle Set''. 
	\item \textit{Synchronous Event Demultiplexer}: This entity is
  actually implemented as a function call, such as \url{select()} or
  \url{WaitForMultipleObjects()} (in case of Windows-based
  systems).  It waits for one or more indication events to occur, and
  then propagates these events to the reactor. 
	\item \textit{Concrete Event Handlers}: The concrete event handlers
  specialize the generalized Event Handler.  They are responsible for
  processing specific types of events.
  Figure~\ref{fig:reactor_structure} shows three types of concrete
  event handlers: the Acceptor, the Connector and the Service Handler.
	\end{enumerate}

Figure~\ref{fig:reactor_dynamics}~\cite{akogekar:posa2} illustrates the dynamics of the
Reactor pattern.  

\begin{figure}[htbp]
	\centering
		\includegraphics[width=8cm]{reactor_dynamics}
	\caption{Dynamics of the Reactor Pattern}
	\label{fig:reactor_dynamics}
\end{figure}

In the initialization phase, the application registers its event
handlers, and the handles that they accept,
with the reactor.  The reactor collects all the registered handles into a
handle set.  In the event handling phase, whenever an event occurs,
the synchronous event demultiplexer channels it to the reactor.  Based
on the handle for that event, the reactor dispatches the
corresponding registered event handler, which then processes the event. Additional information about the Reactor architectural pattern can be found in~\cite{akogekar:posa2}. 
  
A system developer can model the Reactor pattern using POSAML as shown in Figure~\ref{fig:reactor_model}. 
\begin{figure}[htbp]
	\centering
		\includegraphics[width=8cm]{reactor_model}
	\caption{Model of the Reactor Pattern}
	\label{fig:reactor_model}
\end{figure}

It can be seen here that the system developer has modeled the reactor pattern as having two event handlers. The service time for these handlers can be fixed in the benchmarking aspect (refer Section~\ref{sec:benchmarking}). Due to the constraints specified in the meta-model (refer Figure ~\ref{fig:reactor_meta}), the modeler cannot connect the various objects in the model arbitrarily. For instance, the modeler would not be allowed to connect the event handlers to the synchronous event demultiplexer; this would raise an error. In this way, through the use of constraints, POSAML only allows the system designer to model his/her patterns in a correct manner.