% $Id: soc.tex 3484 2006-06-19 22:57:53Z gokhale $


\section{Separation of Concerns in POSAML}
\label{sec:soc}

\begin{figure*}[htb]
	\centering
%  \includegraphics[width=\columnwidth]{feature-meta}
  \includegraphics[width=4in]{feature-meta}
	\caption{POSAML Metamodel: Feature View}
	\label{fig:feature-meta}
\end{figure*}

Section~\ref{sec:posa} described the POSAML metamodel and illustrated
how a systems developer can use the visual mechanisms provided by POSAML
to model middleware stacks.  In this section we describe how POSAML
provides a unified framework that separates the concerns of provisioning 
and QoS validation.  The middleware provisioning is
accomplished through POSAML's feature
modeling~\cite{Batory:06,Generative:Programming:00}  
capability, which assists a systems engineer in configuring a variety
of different 
middleware features (e.g., choosing the pattern and its
configuration parameters).  The benchmarking capability (though
visually decoupled from the provisioning capability) is internally
integrated and is used in automatically synthesizing empirical
benchmarks for the provisioned system.  The remainder of this section
describes these capabilities of POSAML.

\subsection{Feature Modeling in POSAML}
\label{sec:features}

A Feature model~\cite{Generative:Programming:00} is an abstraction of
a family of systems in a particular domain capturing commonalities and
variabilities among the members of the family.  In our POSAML modeling
language, a feature modeling aspect provides
domain-specific artifacts to model a system, in contrast to using
low-level platform-specific artifacts.  The feature modeling capabilities
in POSAML provide structural representation of different
possible middleware pattern properties.  In our case, the feature
modeling comprises several non-functional and QoS
requirements, such as the choice of network transport, listening end
points, concurrency requirements, and periodicity of request
represented as higher-level artifacts.

This level of modeling enables system integrators to select various strategies,
resource settings and factories within the middleware that can be
parameterized according to user needs by driving the selection process
using the visual feature modeling framework.  For example, the
designer can specify the ``End points'' feature for the
Acceptor-Connector Pattern.  Using the Configurator interpreter, different 
feature settings are generated in a configuration file that 
can be used to set or change different middleware configurations.
Traditional middleware architectures suffer from insufficient model
level reusability.  The feature model aspect of POSAML provides a way to
% Dimple, I cannot understand this - Andy
% Andy, I tried to make some changes. What i am trying to say here is 
% Earlier we had no modeling way to configure middleware but
% using this aspect of POSAML we can change the behaviour aspect of
% middleware--Dimple 
set different behavioral aspects of middleware.  

Figure~\ref{fig:feature-meta} illustrates the GME-based feature
modeling capability in the POSAML metamodel.  Developing feature
modeling capability in a metamodel involves defining valid entities 
and relationships between different elements of a model.  
All of the features that have been developed are specific to a pattern.  
For example, features such as concurrency, thread queue and reactor 
type are Reactor-specific; the active object map size is specific 
to the Active Object pattern; and end points are specific 
to the Acceptor and Connector patterns.  These pattern-specific features assist
the modeler in selecting the correct feature-pattern relationship during modeling.
In the following, we describe some of the features that POSAML provides.

\begin{enumerate}
	\item \textbf{Concurrency: }  This feature is important for
  different middleware to manage concurrency and allow long running
  operations to execute simultaneously without impeding the progress
  of other operations.  Server concurrency strategies found in
  contemporary middleware solutions, such as the TAO CORBA
  middleware~\cite{Schmidt:02g}, support different types of
  concurrency strategies~\cite{Schmidt:02g}, including {\em reactive}
  and {\em thread per connection}.  

	\item \textbf{Reactor Type:} This feature is used to specify the
  kind of reactor used by the system.  
% Dimple, I removed use of terms that are specific to ACE or TAO such
% as resource factories, etc and wrote this in very generic terms.
% See how I did this. We need this level of abstraction. The in our
% configuration interpreter we describe how it can be mapped to
% specific middleware platforms.
  For example, depending on the concurrency strategy chosen, the
  reactor could be single threaded or multi threaded.  Different
  strategies can be plugged within the reactor for event
  demultiplexing.  This depends on whether the reactor is used to
  demultiplex network events or GUI events.  For network events, the
  demultiplexer may use the POSIX \url{select ()} and \url{poll ()}
    system calls, or Win32-specific API, such as \url{
      WaitForMultipleObjects ()}.  For event handling, the reactor may 
  choose a number of strategies
  including single threaded handling, thread-per-event, or thread-pool
  based handling.  All of these features can be selected by a
  systems developer at model-time.

  \item \textbf{Thread Queue:}  In the case of concurrent request
  handling by a reactor, different strategies can be selected for
  handling queued events e.g., FIFO or LIFO.

  \item \textbf{End points:} This feature applies to the
  acceptor-connector patterns, which instructs the system of the
  listening end points for the server role.  The range of available
  end points in POSAML include listening ports (e.g., TCP port
  number), host IP addresses or canonical names, and the protocol used
  (e.g., TCP, UDP, Shared Memory or other custom transports).  

\end{enumerate}
 
\begin{figure}[htb]
	\centering
  \includegraphics[width=\columnwidth]{feature-model}
	\caption{POSAML Model: Feature View}
	\label{fig:feature-model}
\end{figure}
 
A systems 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 engineer can model
zero or more features using this tool.  Once the feature modeling part
is done, then the next step is to transform pattern-specific features
into configuration files specific to a middleware. This is performed by model
interpreters that are plugged into POSAML, as described in
Section~\ref{sec:generative}.  If features are not selected from the
model, default values for these features will be selected.  In order to
minimize the risk of choosing incorrect and incompatible features,
various constraints are specified within the POSAML metamodel using both
OCL, which checks constraints at modeling time, and interpreters,
which check constraint violations when the generative tools are used.
Some examples of these OCL constraints
include checking for non-null references or proxies.

% Dimple, please refine the following subsection the way I did the
% above. 
\subsection{QoS Validation Modeling in POSAML}
\label{sec:benchmarking}

%JGG: This "Benchmarking Aspect:" seems to appear out of the blue.
%JGG: I think more transition is needed here

The designer can select which
  benchmarking parameters to set for the performance analysis of the
  modeled system. These parameters are then written to an XML file by
  the benchmarking interpreter. This file can be used by an existing
  benchmarking library. 

To enable the performance analysis of a composed system, the modeling
language provides a method to model benchmarking characteristics. 
This can be done in the ``Benchmarking
Aspect''. Figure~\ref{fig:benchmark_meta} shows the metamodel for the
Benchmarking view. 

\begin{figure*}[htb]
	\centering
%		\includegraphics[width=\columnwidth]{benchmark_meta}
		\includegraphics[width=4in]{benchmark_meta}
	\caption{The Benchmarking metamodel}
	\label{fig:benchmark_meta}
\end{figure*}

The metamodel enables the systems developer to model the workload
(number of threads, data, and the number of data exchanges), as well
as which metric to measure (latency or throughput). It is also
possible to set the handle time for each event handler. A sample model
that can be constructed using this paradigm is shown in
Figure~\ref{fig:benchmark-model}.  In this case the systems developer 
has modeled two patterns, the Reactor and
the Acceptor-Connector, as well as the benchmarking characteristics to
analyze the performance of the Reactor pattern. Therefore, the latency
and throughput metrics are 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=\columnwidth]{benchmark_model}
%		\includegraphics[width=4in]{benchmark_model}
	\caption{Benchmarking Aspect}
	\label{fig:benchmark-model}
\end{figure}

 

% Dimple, please clean this up too such that it ties back to the two
% example models we show above. Make a case that different
% middleware-specific interpreters can be plugged in. In this case we
% show what we can do with the ACE/TAO middleware.
\subsection{Generative Capabilities in POSAML}
\label{sec:generative}
The dynamic semantics of POSAML are implemented by GME model interpreters, 
which traverse the graphical hierarchy of a model.  POSAML is a platform-independent modeling 
language and different middleware-specific interpreters can be plugged in. 
Our current implementation of interpreters are ACE/TAO middleware-specific. 
The following is a description of two interpreters that we have developed:
\subsubsection {Configurator Interpreter}
\label {sec:config-interpreter}
This interpreter is used to generate two 
artifacts which are required to configure middleware.  One of the artifacts 
is the service configurator file and the other one is a script 
file.  The Service Configurator file is used to set QoS related configuration
policies by middleware for different applications. It has different
options that control the behavior of strategies and resources used by the
middleware framework. This file allows an application to configure
service objects statically and dynamically.  
Options in the configuration file can represent either the
components provided by the middleware framework or customized components
developed by users. 

Different services can be configured using this interpreter. There are some 
service settings that are used to control the creation of configurable 
resources used by an object broker, irrespective of the client or server roles. 
Some example settings that are used to control the behavior of client
and server include a concurrency strategy, demultiplexing strategies,
request multiplexing strategies, wait strategies, and connection
strategies.  We used POSAML  to create a configuration 
file and script file for ACE/TAO middleware.  A snippet of the
generated service configuration file for ACE/TAO middleware is shown
below:


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

A POSAML model interpreter also generates a script file 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. 

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


\subsubsection{Benchmarking Interpreter}
The benchmarking aspect enables a user to model the benchmarking
characteristics of the system. Using the benchmarking interpreter, the
developer can generate benchmarking parameters for an existing
benchmarking library. These parameters can be parameters such as the
number of data exchanges, the number of client threads, the data to be
sent, the number of event handlers and the service time (in case of
reactor). They are generated in XML format (snippet shown below) and
can be used by an existing library. 

\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}

Our future work in this regard lies in auto-generating benchmarking
code, instead of just generating benchmarking parameters for existing
benchmarking libraries. Another approach which we are pursuing is the
auto-generation of simulation models of the patterns using
POSAML. This would be helpful in the design-time performance analysis
of middleware systems. 

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "hicss07-visa"
%%% End: 
