% $Id: example.tex 6421 2007-05-14 11:44:49Z gokhale $
%%%%%%%%%%%%%%%%%%%%%% Workflow %%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{POSAML in Action}
\label{sec:example}

This section describes the workflow of activities performed by a
systems provisioner using the capabilities of POSAML.  We use a sample
client-server application to demonstrate concretely the capabilities
of POSAML.  We focus on a subset of the middleware blocks used by the
sample application.  

\textbf{Step 1: Modeling Application Structure:}
Figure~\ref{fig:middleware_model} shows an example where the
provisioner has modeled the sample application as a composition of the
Reactor and Acceptor-Connector patterns.  The Reactor exemplifies the
event handling within the server, while the Acceptor-Connector
demonstrates the communication mechanisms between the client and
server.  In addition to this high-level view, the user can click on
any one of the patterns and model its internals, as shown in the ovals
in the figure (whose details are described below).  From the figure,
it can be seen that POSAML follows a hierarchical modeling structure.
At the top-most level one can model inter-pattern relationships and
constraints.  At the lower level, a provisioner can drill down into
each pattern to model the participants of the pattern and the
inter-pattern relationships between them. 
	
\begin{figure*}[hbt]
	\centering
		\includegraphics[width=0.85\columnwidth]{middleware_model}
%		\includegraphics[width=4.2in]{middleware_model.eps}
	\caption{Middleware Provisioning in POSAML}
	\label{fig:middleware_model}
\end{figure*}

 
\textbf{Step 2 (a): Modeling the Reactor Pattern:}

The metamodel for the Reactor pattern has been illustrated in
Figure~\ref{fig:reactor-meta}. Figure~\ref{fig:reactor_model} shows
the use of this metamodel in modeling the Reactor for a POSAML model
of our sample client-server application.  The various participants of
the Reactor pattern have been described in
Section~\ref{sec:posaml-soc}.

\begin{figure}[htbp]
	\centering
		\includegraphics[width=0.85\columnwidth]{reactor_model}
	\caption{Model of the Reactor Pattern}
	\label{fig:reactor_model}
\end{figure}

In Figure~\ref{fig:reactor_model} the provisioner has modeled two
event handlers corresponding to a handle set consisting of two
handles.  Both the event handlers are connected to the Reactor, which
indicates that both of them are ready to handle events of the
appropriate type.  The handles are connected to the synchronous event
demultiplexer, which indicates that both the handles are active and
ready to accept events of the corresponding type.  It is also possible
to model different types of reactor (e.g.,
single-threaded/multi-threaded).

\textbf{Step 2(b): Modeling the Acceptor-Connector Pattern:}
A system engineer can model the Acceptor-Connector pattern in POSAML
for the sample application as shown in Figure~\ref{fig:Acc-Con-model}.
Various constraints minimize the risk of choosing a wrong combination
of elements in the pattern.  Only the correct combinations of
connections and features are allowed to be added for a particular
pattern.  For example, only the ``End Point'' feature can be added to
the Acceptor-Connector pattern.  The middleware provisioner models the
following participants of the Acceptor-Connector pattern:

\begin{figure}[ht]
	\centering
		\includegraphics[width=0.85\columnwidth]{Acc-Con-model}
	\caption{Model of Acceptor-Connector}
	\label{fig:Acc-Con-model}
\end{figure}

\begin{NumList}
\item \textit{Acceptor}: The Acceptor is a factory that implements a
passive strategy to establish a connection and initialize the
associated Service Handler.  It creates a passive mode end point
transport handle that has necessary end points needed by the Service
Handlers.  

\item \textit{Connector}: A Connector is a factory that implements the
active strategy to establish a connection and initialize the
associated Service Handler.  It initiates the connection with a remote
Acceptor and has synchronous mode (using the Reactor pattern) and
asynchronous mode (using the Proactor pattern) connections.  

\item \textit{Dispatcher}: The Dispatcher manages registered Event
Handlers.  In case of the Acceptor, the Dispatcher demultiplexes
connection indication events received on transport handles.  Multiple
Acceptors can be registered within the Dispatcher.  For Connector, the
Dispatcher demultiplexes completion events that arrive in response to
connections.  

\item \textit{Service Handler}: A Service Handler is an abstract class
that is inherited from Event Handler. It implements an application
service playing the client role, server role or both roles.  It
provides a hook method that is called by an Acceptor or Connector to
activate the application service when the connection is established.  

\item \textit{Transport End points}: These represent a factory that
listens for connection requests to arrive, accepts those connection
requests, and creates transport handles that encapsulate the newly
connected transport end points.  By using these end points data can be
exchanged by reading or writing to their associated transport handles.
A transport handle encapsulates a transport end point. 
\end{NumList}

\textbf{Step 3: Modeling the Features of Pattern Participants:}
\label{sec:example-features}

A system developer uses the feature aspect of POSAML as a visual tool 
to select different pattern-specific features of the middleware.
Figure~\ref{fig:feature-model} illustrates an instance of a feature
model.  The system developer can model zero or more features using this
tool.  If features are not selected from the model, default values for
these features will be selected.   In order to minimize the risk of choosing 
wrong connections and options, various constraints are embedded in the
POSAML metamodel.  Some of these constraints are checked using OCL
constraint language i.e., checking for non-null references or proxies
and some of them are checked at the time of execution of interpreters,
i.e. check if a feature is connected to the correct pattern or not.
The selected features set with different options are exported into
files using  configuration interpreter and are used to configure
middleware system.  

\begin{figure}[htb]
	\centering
  \includegraphics[width=0.85\columnwidth]{feature-model}
	\caption{POSAML Model: Feature View}
	\label{fig:feature-model}
\end{figure}
 
\textbf{Step 4: Modeling the QoS Validation:}
A sample model that can be constructed using POSAML is shown in
Figure~\ref{fig:benchmark-model}.  In this case the system provisioner
has modeled two patterns: the Reactor and the Acceptor-Connector, as
well as the benchmarking characteristics to analyze the performance of
the Reactor pattern.  The latency and throughput metrics are shown
attached to the Reactor pattern.  In addition, the model also
specifies the number of client threads and the service time for each
event handler in the Reactor Pattern.   

\begin{figure}[htb]
	\centering
		\includegraphics[width=0.85\columnwidth]{benchmark_model}
%		\includegraphics[width=4in]{benchmark_model}
	\caption{Benchmarking Aspect}
	\label{fig:benchmark-model}
\end{figure}

\textbf{Step 5: Using the Generative Capabilities:}
The generative capabilities in POS\-AML use the models to synthesize
artifacts for concrete middleware platforms.  Different services can
be configured using this interpreter.  For example, it could include
some service settings that are used to control the creation of
configurable resources used by an object broker.  Other settings are
used to control the behavior of client and server including the
concurrency strategy, demultiplexing strategies, request multiplexing
strategies, wait strategies, and connection strategies.  We used
POSAML  to create a configuration file and script file for a CORBA
middleware called TAO~\cite{Schmidt:02g}.  A snippet of the generated
service configuration file and benchmarking artifacts are shown
below. 

\begin{footnotesize}
\begin{verbatim}
static Advanced_Resource_Factory  
   "-ORBReactorType tp -ORBReactorThreadQueue LIFO"
static Server_Strategy_Factory 
   "-ORBConcurrency reactive"
\end{verbatim}
\end{footnotesize}

\begin{footnotesize}
\begin{verbatim}
- <benchmark_inputs>
    <connections>10</connections> 
    <data>ABCDEF</data> 
    <data_exchanges>200</data_exchanges> 
  - <reactor_inputs>
      <reactor_type>wfmo</reactor_type> 
      <handlers>2</handlers> 
      <service_time>Uniform</service_time> 
    </reactor_inputs>
  </benchmark_inputs>
\end{verbatim}
\end{footnotesize}

The POSAML model interpreter also generates a script file shown below
that contains inputs to run any application  (e.g., the Naming service
or benchmarking evaluation tool) with proper end points (e.g.,
listening ports,  protocol and host name).  These end points are also
used by the Acceptor-Connector pattern for different transport
handles.  For example, in the snippet below, the benchmarking test is
run on an endpoint that uses the IIOP protocol from CORBA.

\begin{footnotesize}
\begin{verbatim}
benchmark_test -ORBEndpoint iiop://127.0.0.1:9000
\end{verbatim}
\end{footnotesize}

In the following code snippet we illustrate optimization metadata
generated by the optimizer interpreter for the
\texttt{Select\_Reactor} implementation.   

\begin{footnotesize}
\begin{verbatim}
/**
  * Aspect for Single Threaded specialization
  */
aspect Single_Thread_Aspect
{
  /**
    * It redirects purge_pending_notifications 
    * method of ACE_Reactor_Impl to same method
    * of ACE_Select_Reactor subclass.
    */
    
  advice call ("% ACE_Reactor_Impl
    ::purge_pending_notifications(...)"):around ()
  {
    ((ACE_Select_Reactor_Impl *) tjp->target ())->
      ACE_Select_Reactor_Impl
      ::purge_pending_notifications 
      		(*tjp->arg < 0 >(),*tjp->arg < 1 >());
  }
}
\end{verbatim}
\end{footnotesize}

In the code snippet, the generated metadata for
AspectC++~\cite{Spinczyk:02,Olaf_AOSD:05} redirects 
the method  \texttt{purge\_pending\_notification} of the abstract
class to the same method name of concrete implementation directly
thereby removing the virtual table lookup overhead between abstract
and base classes.

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "JVLC-2007"
%%% End: 
