% $Id: posa.tex 3805 2006-09-12 17:07:49Z gokhale $

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

Model-driven Development (MDD)~\cite{MDA:01,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 automated QoS validation.
This paper describes an approach comprising 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.
Moreover, POSAML provides middleware-specific QoS validation by virtue
of plugging in different model interpreters.

\subsubsection{Challenge 1- Variability in Middleware Composition}
\label{sec:vert_var}

When deploying complex applications, systems developers must decide
the composition and customization of middleware that hosts the
application components.  Middleware composition includes assembling
individual but compatible building blocks of middleware.  The building
blocks of middleware are most often patterns-based.  A software
pattern~\cite{Vlissides:94} codifies recurring solutions to a
particular problem occurring in different contexts, which is embodied
as a reusable software building block.  The systems developer 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
incurred design space 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 forming 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.  

\subsubsection{Challenge 2- Building Block Configuration Variability}
\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 developer is required to make.  Any ad
hoc decision affects the time-to-market and also can deliver
less-than-desired performance.  Since the impact is on a per building
block basis -- as opposed to a composition described in the previous
challenge -- we  refer to this as {\em configuration dimension
  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. 


Our research contributions to address the challenges illustrated in
Section~\ref{sec:challenges} leverage the fact that standardized
middleware are made up of different layers of software performing
numerous activities, 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}.     

Thus a visual representation of these patterns enables systems
integrators to view the middleware stacks at a higher level of
abstraction that is independent of any specific middleware technology.
The QoS validation mechanisms associated with the visual capability
subsequently map these abstractions to specific platforms.  The
architectural patterns present 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}.  The visual modeling capabilities we
discuss in this paper are provided as a visual domain-specific
modeling language (DSML)~\cite{Janos:03} called POSAML (Pattern
Oriented Software Architecture Modeling Language).  It enables
modeling of the patterns described in the POSA book.  In addition to
pattern modeling, POSAML provides a clean separation of concerns
between the provisioning and QoS validation phases within the same
unified framework. 

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

% had to move this here so it shows up in the right place
\begin{figure*}[thb]
	\centering
%		\includegraphics[width=\columnwidth]{figs/reactor_meta.eps}
		\includegraphics[width=4.5in]{figs/reactor_meta.eps}
	\caption{Metamodel for the Reactor Pattern}
	\label{fig:reactor_meta}
\end{figure*}


POSAML has been developed using the Generic Modeling Environment
(GME)~\cite{GME:01}.  Figure~\ref{fig:middleware_meta} shows the
metamodel for the top-level view of POSAML.  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.  By providing such
views, the modeling environment effectively allows visual separation
of concerns.  The ``Connection'' element describes the type of
association between other modeling elements of the language.  The GME
environment can be used by application developers to model
examples that conform to the syntax and semantics of the modeling
language captured in the metamodels.

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.  The figure also illustrates how the metamodel separates the
concerns of modeling the pattern, its configuration and their
compositions, and system QoS validation. This separation is shown as 
three aspects; namely Pattern, Feature and Benchmarking. 

The rest of the section describes the pattern aspect, which allows a
systems engineer to model a middleware building block comprising the
individual patterns.  We focus on a subset of the
POSA patterns describing the visual modeling elements provided in
pattern modeling.  Section~\ref{sec:soc} describes how POSAML
provides the provisioning and QoS capabilities.

\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 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 metamodel for POSAML is shown in
Figure~\ref{fig:reactor_meta}, which 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.
\end{enumerate}

Constraint checking within the POSAML reactor 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.   

A system engineer can model an instance of the Reactor pattern using
POSAML, as shown in Figure~\ref{fig:reactor_model}.  
It can be seen 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 to
Section~\ref{sec:benchmarking}).  Due to the constraints specified in
the metamodel (see Figure ~\ref{fig:reactor_meta}), the system engineer
cannot connect the different objects in the model arbitrarily.  For
instance, POSAML will not allow the modeler to connect the event
handlers to the synchronous event demultiplexer as this would raise an
error.  Thus, through the use of constraints, POSAML only allows
the system designer to model his/her patterns in a correct manner,
thereby providing syntactically ``correct by construction'' systems.

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

\subsection{Modeling the Acceptor and Connector Pattern}
\label{sec:acceptor}

The Acceptor-Connector pattern pair decouples connection establishment
and service initialization in a distributed system from subsequent
processing performed by the two end points of a service once they are
connected and initialized.  This decoupling is achieved by acceptors,
connectors and service handlers.  Connection-oriented protocols
provide reliable delivery of data between two or more end points of
communication~\cite{Schmidt:00a}.  Establishing connection
between end points involves two roles:  

\begin{itemize}
	\item \textit{Passive role}: This type of role initializes end points of
  communication at a particular address and waits passively for
  other end points to connect with it.  
	\item \textit{Active role}: This type of role actively initiates a
  connection to one or more end points that are playing the passive role. 
\end{itemize}

It is important to know the communication role in terms of server and
client.  Most often the client plays an active role in
connecting with a passive server.  Thus, in the Acceptor-Connector
pattern, the acceptor provides the passive role and the connector plays an
active role.  

\iffalse
\begin{figure*}[bht]
	\centering
%		\includegraphics[width=\columnwidth]{connector}
		\includegraphics[width=4in]{connector}
	\caption{Connector part of metamodel}
	\label{fig:connector}
\end{figure*}
\fi

In order to understand the Acceptor-Connector
metamodel properly, we have simplified it by dividing it into two parts
with the acceptor part shown in Figure~\ref{fig:acceptor} (The
connector part is similar and is not shown due to space limitations). 
Various participants of this metamodel are as follows: 

\begin{figure*}[hbt]
	\centering
%		\includegraphics[width=\columnwidth]{acceptor}
		\includegraphics[width=4in]{acceptor}
	\caption{Acceptor part of metamodel}
	\label{fig:acceptor}
\end{figure*}


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

%JGG: The paragraph below needed a lot of editing; please make sure
% I did not change the meaning

A system engineer can model the Acceptor-Connector pattern in POSAML
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. 

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


\subsection{Modeling a Middleware Configuration}
\label{sec:example}

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

% Dimple, here I want to show how all these things can come together
% into an example model. If necessary we can explain this more but for
% this the earlier part needs to be trimmed a bit.  -Andy
Figure~\ref{fig:middleware_model} shows an example where the designer 
has modeled the Reactor and Acceptor-Connector patterns. 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 figure. Sections~\ref{sec:reactor} 
and ~\ref{sec:acceptor} describe pattern modeling of the 
Reactor and Acceptor-Connector patterns. 
	
From the figure, it can be seen that POSAML follows a hierarchical
structure. At the top-most level one can model inter-pattern
relationships and constraints. At the lower level, a designer can enter
``inside'' each pattern to model the participants of the pattern and
the inter-pattern relationships between them.


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