% $Id: posaml.tex 6421 2007-05-14 11:44:49Z gokhale $

\section{The POSAML Visual Framework for Middleware Provisioning}
\label{sec:posaml}

This section describes the POSAML (Pattern Oriented Software
Architecture Modeling Language) visual modeling framework for
middleware provisioning.  We discuss the design of POSAML and how it
meets the criteria described in Section~\ref{sec:challenges}.  


%%%%%%%%%%%%%%%%%%%%%% Criterion 1 %%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Meeting Criterion 1: Accounting for Variability Across a
  Range of Middleware}
\label{sec:posaml-variability}

Figure~\ref{fig:mw-stack} illustrated the structure of contemporary
middleware, which are made up of different layers of software performing
various functions, such as data marshaling, event handling,
brokering, concurrency handling and connection management.  In an
object-oriented design of a middleware framework, these capabilities
are realized by building blocks based on proven patterns of software
design~\cite{Vlissides:94}.  A software pattern codifies recurring
solutions to a particular problem occurring in different contexts,
which is embodied as a reusable software building block in middleware.
The architectural patterns found in contemporary middleware systems
are discussed extensively in the book {\em Pattern Oriented Software
  Architecture: Patterns for Networked and Concurrent Systems}
(POSA)~\cite{Schmidt:00a}.  We leverage these characteristics of
middleware design to develop our visual provisioning framework.

In our approach, a visual representation of these patterns enables
system provisioners to view the middleware stacks at a higher level of
abstraction, which is independent of any specific middleware
technology.  The QoS validation mechanisms associated with the visual
capability subsequently map these abstractions to technology-specific
platforms.  In the following we discuss how
patterns~\cite{Vlissides:94} and pattern languages~\cite{Alexander:77}
enable us to identify and resolve the variability in middleware
provisioning. 

\subsubsection{Identifying Variability in Composing Functionality} 
\label{sec:vert_var}

When deploying complex applications, systems provisioners must decide
the composition and customization of middleware that hosts the
application.  Middleware composition includes assembling
individual but compatible building blocks of middleware at multiple
layers.  The systems provisioner chooses a block based on various
factors including the context in which the application will be
deployed, the concurrency and distribution requirements of the
application, the end-to-end latency and timeliness requirements for
real-time systems, or throughput for other enterprise systems (e.g.,
telecommunications call processing).  We refer to this dimension of
provisioning variability  as {\em middleware compositional
  variability}. 

\begin{figure}[htb]
\centering
\includegraphics[width=0.85\columnwidth,keepaspectratio]{posa2-plop.eps}
%\includegraphics[width=4in,keepaspectratio]{posa2-plop.eps}
\vspace{-.2in}
\caption{Middleware Patterns and Pattern Languages}
\label{fig:posa2-plop}
\end{figure}

Figure~\ref{fig:posa2-plop} illustrates a family of interacting
patterns that form a pattern language~\cite{Alexander:77} for
middleware designed to support such applications.  The middleware can
be customized by composing compatible patterns-based building blocks.
For example, event demultiplexing and dispatching via the Reactor or
Proactor patterns~\cite{Schmidt:00a} can be composed with the
concurrent event handling provided by the Leader-Follower or Active
Object patterns~\cite{Schmidt:00a}.  However, an Asynchronous
Completion Token (ACT) pattern works only with asynchronous event
demultiplexing provided by the Proactor.  Thus, a combination of
Reactor and ACT is invalid.  Our POSAML visual framework formalizes
the concept of a pattern language to resolve the middleware
compositional variability concerns in middleware provisioning. 

\subsubsection{Identifying Variability in Building Block
  Configurations} 
\label{sec:horiz_var}

Middleware developers provide numerous configuration options to
customize the behavior of individual building blocks.  This
flexibility further exacerbates the already incurred variability in
design choices that the systems provisioner is required to make.  Since
the variability is on a per building block basis -- as opposed to a
composition described above -- we  refer to this as {\em building
  block configuration variability}.  

As a concrete example, the Reactor pattern can be configured in many
different ways depending on the event demultiplexing capabilities
provided by the underlying OS  and the concurrency requirements of an
application.  For example, the demultiplexing capabilities of a
Reactor could be based on the \texttt{select()} or \texttt{poll()}
system calls provided by POSIX-compliant operating systems or
\texttt{Wait\-ForMult\-iple\-Object()} available on Windows.  Moreover, the 
handling of the event in the Reactor's event handler can be managed by
a single thread of control or handed over to a pool of threads
depending on the concurrency requirements.  POSAML captures the
representation of individual patterns and their variations to address
the per building block configuration variability. 

%%%%%%%%%%%%%%%%%%%%%% Criterion 2 %%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Meeting Criterion 2: Separation of Concerns}
\label{sec:posaml-soc}

In this section we discuss how the insights we gain from exploring
the patterns and pattern languages become part of our visual framework
for middleware provisioning.  Section~\ref{sec:challenges} described
the need for separation of concerns in the provisioning stages.
Model-based solutions based on visual aids can provide the desired
solution.  Model-driven Engineering (MDE)~\cite{Janos:03,Schmidt:06a},
which is a model-based solution, has gained prominence in providing
the capabilities to model systems and use generative programming
techniques to synthesize artifacts that result from the models.  This
paper describes the POSAML MDE framework for assisting provisioners to
make the right choices in configuring, optimizing and validating large
systems hosted on middleware platforms.

Our research contributions within the MDE framework include the
design of a visual domain-specific modeling language (DSML) called
POSAML, which enables the modeling of middleware stacks and
their configurations, optimizations and validation phases by providing
intuitive visual abstractions of middleware building blocks.  POSAML
also provides middleware-specific QoS validation by virtue of allowing
different model interpreters to be plugged into the MDE framework. 

\subsubsection{Visual Modeling Capabilities in POSAML}
\label{sec:posaml_meta}

Figure~\ref{fig:middleware_meta} shows the metamodel for the top-level
view of POSAML, which has been developed using the Generic Modeling
Environment (GME)~\cite{GME:01}.  GME is a tool that enables domain
experts to develop visual modeling languages and generative tools
associated with those languages.  The modeling languages in GME are
represented as metamodels.  A metamodel in GME depicts a class diagram
using UML-like constructs showcasing the elements of the modeling
language and how they are associated with each other.  For example,
the ``Model'' element defines an element that can comprise other
elements.  The ``Connection'' element describes the type of
association between other modeling elements of the language.  The
``Aspect'' element describes a specific view provided by the modeling
environment thereby promoting separation of concerns within a modeling
environment.  By providing such views, the modeling environment
effectively allows visual separation of concerns, which is a criterion
that we had to meet.  The same GME environment can be used by
provisioners to model the provisioning decisions using the POSAML
metamodel. 

\begin{figure}[htb]
  \centering
  \includegraphics[width=0.85\columnwidth,keepaspectratio]{middleware_meta}
  \vspace{-1in}
	\caption{Top-level Metamodel of Middleware Structure}
	\label{fig:middleware_meta}
\end{figure}

The metamodel illustrated in Figure~\ref{fig:middleware_meta}
provides the visual syntactic and semantic elements that describe
individual patterns, and specifies how they can be connected to each
other according to the pattern language.  The metamodel also comprises
other elements (shown as GME aspects), such as the feature modeling
capability that enables configuring and optimizing each block,
simulation modeling capability that enables validation via simulation,
and benchmarking modeling capability that enables validation via
empirical benchmarking.  By providing each of these capabilities as a
separate first class element of the metamodel, POSAML separates the
concerns of modeling the pattern, its configuration, optimizations and
their compositions, and system QoS validation by virtue of using GME
aspects.  We describe these visual separation of concerns below.

\subsubsection{Enabling Separation of Concerns}
\label{sec:mde_soc}

We now describe how POSAML provides visual separation of concerns
that are useful for the different provisioning phases. 

\textbf{(a) Pattern Modeling in POSAML}

Figure~\ref{fig:middleware_meta} showed how the high-level POSAML
metamodel enables a system architect to design a composition of
patterns.  Due to the hierarchical nature of POSAML, each pattern
itself has a metamodel associated with it.  This metamodel enables
that particular pattern to be modeled in the ``Pattern'' GME Aspect.
This provides visual mechanisms to concentrate on individual building
blocks of the middleware and their configurations and optimizations. 
We illustrate this capability with an example metamodel of the
Reactor~\cite{Schmidt:00a} building block. 

The ability to handle and dispatch simultaneously occurring events
effectively without any additional resource overhead is an integral
part of systems designed for use in real-time, event-driven and
performance-critical environments.  The Reactor 
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-meta} illustrates the
metamodel of the Reactor building block in POSAML. 

\begin{figure}[htb]
	\centering
	\includegraphics[width=0.85\columnwidth,keepaspectratio]{reactor_meta}
	\caption{Meta-model of the Reactor Pattern}
	\label{fig:reactor-meta}
\end{figure}

This metamodel enables the designer to model the following
participants and their relationships of a Reactor building block:  
\begin{NumList}
	\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 \texttt{select()} or
  \texttt{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, such as input data or timeouts.
\end{NumList}

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
model interpreters are used.  Constraint checking within the POSAML
metamodel includes 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 thereby ensuring that systems conform to
the semantics of the pattern languages.  

\textbf{(b) Feature Modeling in POSAML:}

A Feature model~\cite{Generative:Programming:00} is defined as 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 representations 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 requests, all represented as
higher-level visual artifacts. 

This level of modeling enables system provisioners 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 to describe the ports and communication
mechanisms used by the client and server to communicate with each
other.  

Feature modeling paves the way to select the desired configuration and
customization parameters of a middleware building block and the
compositions of these building blocks.  The selected features provide
the means for optimization tools to specialize the middleware code so
that the hosting platform is fine tuned to support application QoS.

Developing a feature model out of a metamodel involves defining valid 
entity and relationships in the schema.  All these features are
pattern-specific.  For example Concurrency, Thread Queue, and Reactor
Type are Reactor-specific; Active Object map size is Active Object
pattern-specific; and End-points are Acceptor and Connector
pattern-specific. 

\textbf{(c) QoS Validation Modeling in POSAML}

To enable the performance analysis of a configured and customized
system, the modeling language provides a method to model simulation
and benchmarking characteristics.  The POSAML metamodel enables the
systems provisioner 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 service times
for event handlers within the application.  In the QoS validation
view, the provisioner can select which benchmarking parameters to
select for the performance analysis of the modeled system.  These
parameters are then automatically written to an XML file by the
benchmarking interpreter described later.  This file can be used by
an existing  benchmarking library within the middleware which is being
benchmarked. 

%%%%%%%%%%%%%%%%%%%%%% Criterion 3 %%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Meeting Criterion 3: Unified Framework}
\label{sec:posaml-framework}

We discussed earlier how the middleware configuration is accomplished
through POSAML's feature
modeling~\cite{Generative:Programming:00,Batory:06}  capability, which
assists a system developer in configuring a variety of different
middleware features (e.g., choosing the pattern and its configuration
parameters).  However, for other visually modeled concerns such as
benchmarking to leverage the modeled system in the feature aspect
requires unifying the different concerns internally.  For example, the
benchmarking capability (though visually decoupled from the
feature modeling capability) is internally integrated and is used in
automatically synthesizing empirical benchmarks for the provisioned
system to perform QoS validation.  The remainder of this section
describes these capabilities of POSAML.  

A unified framework must provide the mechanisms for the decisions made
at configuration time to be available at QoS validation time, and
enable the synthesis of validation artifacts.  In an MDE
framework, such capabilities are realized via generative programming
capabilities.  Within the GME DSML development environment, in
particular, these capabilities are realized by GME model interpreters,
which traverse the graphical hierarchy of a model.  The POSAML
metamodel is a middleware-independent modeling language.  By
leveraging the capabilities of the GME environment, different
middleware-specific interpreters can be plugged in.  The following
describes two model interpreters that we have developed.

\textbf{(a) Configurator Interpreter:}
This interpreter is used to generate two artifacts which are required
to configure the specific instance of middleware.  One of the
generated artifacts is a configurator file and the other one is a
script file.  The configurator file is used to set QoS related
configuration policies using middleware-specific mechanisms for
different applications.  The middleware provisioner is shielded from
these details since the interpreters automate the task of generating
the platform-specific details. 

\textbf{(b) Optimizing Interpreter:}
Figure~\ref{fig:reactor_specialization} shows an example of how we
can model a building block  with the different specializations of the
building block.  In this example we have modeled the abstract base class
\texttt{ACE\_Re\-actor\_Impl} with its concrete implementation of
subclasses  like \texttt{ACE\_Sel\-ect\_Rea\-ctor},
\texttt{ACE\_WF\-MO\_Rea\-ctor} and \texttt{ACE\_TP\_Rea\-ctor}.  It
also shows two modeled specialization 
aspects named as \texttt{Sin\-gle\_Thr\-ead\_Asp\-ect} and
\texttt{TP\_Thr\-ead\_Asp\-ect}.
\texttt{Sin\-gle\_Thr\-ead\_Asp\-ect} specialization is for single
threaded implementation of Reactor and \texttt{TP\_Thread\_Aspect}
specialization is for threadpool implementation of Reactor.  

\begin{figure}[htb]
	\centering
	\includegraphics[width=0.8\columnwidth]{reactor_specialization}
	\label{fig:reactor_specialization}
	\caption{Modeling of Build Block Specializations in POSAML}
\end{figure}

The optimizing interpreter consults the feature model for the
configuration parameters deducing the type of the building block being
selected, such as the reactor type.  Using the information from the
specialization model, the optimization interpreter generates metadata
used by aspect oriented tools, like
AspectC++~\cite{Spinczyk:02,Olaf_AOSD:05} and
AspectJ~\cite{kiczales01overview,gregor:97} so that the  
middleware code can be optimized based on the selected features of a
building block.


\textbf{(c) Benchmark Interpreter:}
The configuration and QoS modeling capabilities in POSAML serve as
inputs to determine the benchmarking artifacts necessary to validate
QoS.  Using the benchmarking interpreter, which can be plugged into
POSAML via the GME environment, the provisioner can generate
benchmarking parameters for an existing benchmarking library.  These
parameters include artifacts, 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).  The parameters
are generated in XML format and can be used to parametrize an existing
benchmarking library. 


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