% $Id$

\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}
\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*{(a) 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, timeliness requirements for
real-time systems, or throughput for other enterprise systems (e.g.,
telecommunications call processing).  We refer to this provisioning
variability  as {\em middleware compositional variability}. 

\begin{figure}[htb]
\centering
\includegraphics[width=\columnwidth]{posa2-plop.eps}
%\mbox{\includegraphics[width=2.9in]{mw-plop.eps}}
\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.  For example, event
demultiplexing and dispatching via the Reactor or Proactor pattern can
be composed with the concurrent event handling provided by the
Leader-Follower or Active Object pattern.  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 leverages
pattern as the means to address the middleware compositional
variability concerns in provisioning. 

\subsubsection*{(b) 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 {\tt select()} or {\tt poll()} system
calls provided by POSIX-compliant operating systems or {\tt
  WaitForMultipleObject()} 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: Unified Framework}
\label{sec:posaml-framework}

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} describes
the need for a unified framework that enables the QoS validation phase
of provisioning to leverage the decisions made at the configuration
phase.  Model-driven Engineering (MDE)~\cite{Schmidt:06a,Janos:03}
has gained prominence in assisting application developers to make the
right choices in configuring and composing large systems.  Model-based
solutions based on visual aids can help resolve the variability in
middleware provisioning and automate the QoS validation phase.  MDE
frameworks provide 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.

Our research contributions within the unified MDE framework include the
design of a visual domain-specific modeling language (DSML) called
POSAML ({\em Patterns-oriented Software Architecture Modeling
  Language}), which enables the modeling of middleware stacks and
their configurations 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. 

Figure~\ref{fig:middleware_meta} shows the metamodel for the top-level
view of POSAML.  POSAML 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 ``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 that is
a criterion that we had to meet.  The ``Connection'' element describes
the type of association between other modeling elements of the
language.  The same GME environment can be used by provisioners to
model middleware provisioning using the POSAML framework.

\begin{figure}[htb]
  \centering
  \includegraphics[width=0.9\columnwidth]{middleware_meta.eps}
	\caption{Top-level Metamodel of Middleware Structure}
	\label{fig:middleware_meta}
\end{figure}

The metamodel illustrated in Figure~\ref{fig:middleware_meta}
consists of the visual syntactic and semantic elements that describe
individual patterns, and specifies how they can be connected to each
other according the the pattern language.  The figure also illustrates
how the metamodel separates the concerns of modeling the pattern, its
configuration and their compositions, and system QoS validation by
virtue of using GME aspects.  This separation is shown as  three
aspects; namely Pattern, Feature and Benchmarking.  

The unified framework allows middleware provisioners to plug in
different model interpreters that can automatically synthesize
artifacts that are specific to a particular middleware technology. 

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

Section~\ref{sec:posaml-framework} described the POSAML unified
framework and illustrated how a systems provisioner can use the visual
mechanisms provided by POSAML to model middleware provisioning
decisions.  In this section we describe how the unified POSAML
framework separates the concerns of configuration and QoS validation,
and how generative programming capabilities provided by model
interpreters seamlessly unify these separate views.  

The middleware configuration 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 to perform QoS validation.  The
remainder of this section describes these capabilities of POSAML.

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

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 request represented as higher-level
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.  

\subsubsection{QoS Validation Modeling in POSAML}
\label{sec:benchmarking}

To enable the performance analysis of a composed system, the modeling
language provides a method to model 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
below.  This file can be used by an existing 
benchmarking library within the middleware which is being benchmarked.


\subsubsection{Generative Capabilities in POSAML}
\label{sec:generative}
A unified framework must provide the mechanisms for the decisions made
at configuration time to be available at QoS validation time, and
enabling 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.  POSAML metamodel
is a middleware-independent modeling language, however, by leveraging
the GME environment's capabilities, different middleware-specific
QoS validation interpreters can be plugged in.  The following
describes two model interpreters that we have developed:

\subsubsection* {(a) 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 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.  


\subsubsection*{(b) 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). They are generated
in XML format and can be used to parametrize an existing benchmarking
library. 

 
%%%%%%%%%%%%%%%%%%%%%% Workflow %%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{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.  

\subsubsection*{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
demonstrate 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.  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 enter ``inside'' each pattern to model the
participants of the pattern and the inter-pattern relationships
between them. In the remainder of this section we describe these
individual steps of the provisioning workflow.
	
\begin{figure*}[htb]
	\centering
%		\includegraphics[width=\columnwidth]{middleware_model.eps}
		\includegraphics[width=4.2in]{middleware_model.eps}
	\caption{Middleware Provisioning in POSAML}
	\label{fig:middleware_model}
\end{figure*}

\subsubsection*{Step 2: Modeling the Reactor Pattern}

The ability to handle and dispatch simultaneously occurring events
effectively without any additional resource overhead is an integral
part of middleware used in real-time, event-driven and
performance-critical environments.  The Reactor~\cite{Schmidt:00a} 
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. 

The Reactor model for POSAML model of our sample client-server
application is shown in Figure~\ref{fig:reactor_model}, where the
provisioner configures the following participants:  

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

\begin{enumerate}\crunchlist
	\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.
\end{enumerate}

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 systems that are correct by construction.

\subsubsection*{Step 3: 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.9\columnwidth]{Acc-Con-model}
	\caption{Model of Acceptor-Connector}
	\label{fig:Acc-Con-model}
\end{figure}

\begin{enumerate}\crunchlist
\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 factory
(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, 
a Dispatcher demultiplexes connection indication events received on
transport handles. Multiple Acceptors can be registered within
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,
typically 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. 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{enumerate}

\subsubsection*{Step 4: Modeling the Features of Pattern Participants}
\label{sec:example-features}

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.  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.
\begin{figure}[htb]
	\centering
  \includegraphics[width=\columnwidth]{feature-model}
	\caption{POSAML Model: Feature View}
	\label{fig:feature-model}
\end{figure}
 
\begin{enumerate}\crunchlist
	\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.  
  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.

  \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}
 
\subsubsection*{Step 5: 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=\columnwidth]{benchmark_model}
%		\includegraphics[width=4in]{benchmark_model}
	\caption{Benchmarking Aspect}
	\label{fig:benchmark-model}
\end{figure}

\subsubsection*{Step 6: Using the Generative Capabilities}

The generative capabilities in POSAML 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.  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 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}


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