% $Id: plop.tex,v 1.6 2006/02/13 03:06:41 gokhale Exp $

\section{Variability Challenges in Service Oriented Middleware}
\label{sec:plop}

As noted earlier distributed service-oriented applications must be
hosted on possibly heterogeneous middleware platforms in the networked
environment.  Moreover, each middleware stack on which the individual
components of the distributed application are hosted may need to be
fine tuned in different ways to cater to the several different quality
of service (QoS) requirements of the overall application.  These
requirements are one of several sources of variability in
the design of these large-scale applications.  Others include the
deployment decisions, resource allocations, workload characterizations
among others.  In this paper we focus on the variability in the
middleware itself and how our solution addresses these challenges. 

In the remainder of this section we describe the sources of
variability in middleware and how visual domain-specific modeling
languages provide the solutions to address these challenges.

\subsection{Challenge 1: Middleware Composition Variability}
\label{sec:vert_var}

When designing service-oriented systems, developers must decide the
composition and configuration of middleware that hosts the application
components.  Middleware composition includes assembling individual
building blocks of middleware that are compatible with each other to
form middleware stacks that are suited to host application components.
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 choice of patterns-based
block is driven by various factors, including the context in which the
service-oriented system will be deployed, the concurrency and
distribution requirements of the application, and other concerns, such
as end-to-end latency and timeliness requirements for real-time
service-oriented systems, or throughput for other service-oriented
systems (such as telecommunications call processing).  We refer to
this incurred design space variability as the middleware compositional
variability.

Figure~\ref{fig:posa2-plop} illustrates a family of interacting
patterns forming a pattern language~\cite{Alexander:77} for middleware
designed to support service-oriented systems.  When designing
service-oriented applications, its developers will be required to
decide the right set of patterns to use in the middleware compositions,
such that the desired end to end QoS and functional requirements are met.

\begin{figure}[htb]
\centering
\includegraphics[width=4in]{posa2-plop.eps}
%\mbox{\includegraphics[width=2.9in]{mw-plop.eps}}
\caption{Middleware Patterns and Pattern Languages}
\label{fig:posa2-plop}
\end{figure}

Patterns such as the {\em Active Object} (not shown) and {\em
  Leader-Follower}~\cite{Schmidt:00a}, provide alternate solutions to
concurrency with each having its own advantages and disadvantages.
For example, although the Active Object pattern is simple to
implement, it incurs an additional performance penalty due to thread
context switching and message queueing.  Conversely, the
Leader-Follower does not incur these drawbacks, but its implementation
is more complicated to implement and analyze, so it may cause race
conditions if not implemented properly.

Other patterns like the {\em Reactor} and {\em
  Proactor}~\cite{Schmidt:00a} provide solutions to synchronous and 
asynchronous event demultiplexing and dispatching, respectively.  Both
of these patterns provide the building block of the asynchronous part of 
the {\em half-sync/\-half-async} pattern shown in
Figure~\ref{fig:posa2-plop}.  Patterns, such as the {\em Asynchronous
  Completion Token} pattern can be used only in those cases where the
underlying platform can support asynchronous messaging.  Developers of
service-oriented systems need to make the right choices of patterns to
use in their solutions, such that the end-to-end QoS and functional
requirements of the service-oriented systems are met. 

The middleware can be customized by composing either the Reactor or
Proactor pattern with the Leader-Follower or Active Object pattern
using the {\em Strategy}~\cite{Vlissides:94} pattern.  Similarly, a
reactor could be composed with the {\em Connector} (client-side) or
{\em Acceptor} (server-side) pattern.  Developers of service-oriented
systems need to make such choices of patterns and their configurations
to use in their solutions, so that the end-to-end performance and
functional requirements of the service-oriented systems are met, {\em
  i.e.}, they are responsible for handling the composition dimension
of middleware variability. 

\subsection{Challenge 2: Configuration Variability}
\label{sec:horiz_var}

Middleware developers provide numerous configuration options to
customize the behavior of individual building blocks, such as the
Reactor and Acceptor.  This flexibility incurs significant variability in
design choices and hence affects the performance of building
blocks.  Since the impact is on a per building block basis -- as
opposed to a composition -- we refer to this as the configuration
dimension of variability. 

Figure~\ref{fig:mw-demux} shows an example of this type of variability
involving an event demultiplexing and dispatching mechanism codified
by the Reactor pattern~\cite{Schmidt:00a}.  In this pattern, a
service-oriented application registers an event handler with the event
demultiplexer and delegates to it the responsibility of listening for
incoming events. On occurrence of an event, the demultiplexer
dispatches the event by making a callback to the right
application-supplied event handler.

\begin{figure}[htb]
\centering
\includegraphics[width=4in]{demux2.eps}
\caption{Event Demultiplexers in Middleware}
\label{fig:mw-demux}
\end{figure}

The Reactor pattern could be configured in many different ways
depending on the event demultiplexing capabilities provided by an 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 event handler
could be managed by the same thread of control that was listening for
events giving rise to a single-threaded Reactor implementation.
Alternately, the event could be delegated to a pool of threads to
handle the events giving rise to a thread-pool Reactor (other variants
are also possible).  These different configuration choices are
dictated by the functional and performance needs of service-oriented systems,
which means that service-oriented developers are responsible for handling this
horizontal dimension of variability.


\subsection{Impact of Variability on Systems Analyses}
\label{sec:analysis}

Sections~\ref{sec:vert_var} and~\ref{sec:horiz_var} describe the
composition and configuration variability showcasing the challenges
that need to be overcome in selecting the right set of building blocks
for middleware.  Resolving these challenges is important due to  
the significant variability~\cite{Weiss:98} and its impact on
performance that is manifested by the need to compose service-oriented
systems by selecting the right set of individual building blocks to
assemble.  Moreover, the fact that each building block can be
customized in different ways adds to the variability in performance
characteristics of the composed system.  

In addressing these sources of variability, there is a need to
estimate expected end-to-end performance provided by the
customized middleware very early in the development lifecycle.
Otherwise service-oriented developers will be forced to rely on
rigorous testing later in the lifecycle to determine if the design
choices were appropriate.  Unfortunately, these decisions occur very
late in the lifecycle of service-oriented systems, which adversely
impacts costs and schedules.  A mechanism is needed that will enable
performance estimation of composable systems at design time.  It is
well understood that any changes at design-time are much easier to
incorporate into the system.  Moreover, the higher-levels of
abstraction and formalism provided by the design-phase makes it
possible to formally verify the systems for correctness. 

\subsection{Solution Approach: Model Driven Software Development}
\label{sec:mdd}


Model-driven Software Development (MDSD)~\cite{MDA:01,Janos:03}
has gained prominence in assisting service-oriented developers to make
the right choices in configuring and composing large systems.
Model-based performance analysis can be used to analyze the
performance of patterns-based service-oriented systems.  In order to
facilitate the use of model-based performance analysis, however, it is
necessary for MDSD tools to provide analytical models of the various
possible patterns.  These models can be used to estimate the
performance of each pattern when used in different configurations and
contexts.  Subsequently, these models can be used in a plug-and-play
fashion to form larger models corresponding to composition of patterns
in the service-oriented system. 

The domain of interest of a DSML can range from something very specific,
such as the elements of a radar system, or can be as broad as the set of
all the component-based middleware applications built using platforms such
as EJB, or CCM.  The key idea behind DSMLs is their ability to capture the
elements of the domain as {\em first-class objects}.

A DSML can be viewed as a five-tuple~\cite{Janos:03} consisting of:
\begin{enumerate}
\item {\bf Concrete Syntax (C)}, which defines the specific notation
  (textual or graphical) used to express domain elements,
\item {\bf Abstract Syntax (A)}, which defines the concepts, relationships
  and integrity constraints available in the language,
\item {\bf Semantic Domain (S)}, which defines the formalism used to map
  the semantics of the models to a particular domain,
\item {\bf Syntactic Mapping (M$_{C}$: A$\rightarrow$C)}, which assigns
  syntactic constructs ({\em e.g.}, graphical and/\-or textual) to elements
  of the abstract syntax, and
\item {\bf Semantic Mapping (M$_{S}$: A$\rightarrow$S)}, which relates the
  syntactic concepts to those of the semantic domain.
\end{enumerate}

Thus the abstract syntax determines all the (syntactically) correct
``sentences'', \textit{i.e.}, models, in the language.  A DSML is also
known as a ``metamodel'', since a DSML is (itself) a model that defines all
the possible models that can be built using it.  To support the development
of DSMLs, we have developed a ``meta-programmable'' modeling environment
called the Generic Modeling Environment (GME) described in
Sidebar~\ref{gme}. 

\BeginSidebar{Generic Modeling Environment}
\label{gme}

Generic Modeling Environment (GME) is an open-source, visual, configurable
design environment for creating DSMLs and program synthesis environments,
available for download from
\url{escher.isis.vanderbilt.edu/downloads?tool=GME}.  A unique
feature of GME is that it is a {\em meta-programmable} environment.  By
{\em meta-programmable}, we refer to the fact that GME is not only used to
build DSMLs, but also to build models that conform to a DSML.  In fact, the
environment used to build DSMLs in GME is itself built using another DSML
(also known as the {\em meta-metamodel}) called ``MetaGME''.  GME provides
the following elements to define a DSML:
\begin{itemize}
\item {\bf Project}, which is the top-level container in a DSML,
\item {\bf Folders}, which are used to group collections of similar elements
  together,
\item {\bf Atoms}, which are the indivisible elements of a DSML, and used
  to represent the leaf-level elements in a DSML,
\item {\bf Models}, which are the compound objects in a DSML, and are used
  to contain different types of elements like References, Sets, Atoms,
  Connections {\em et al.} (the elements that are contained by a Model are
  known as {\em parts}),
\item {\bf Aspects}, which are primarily used to provide a different
  viewpoint of the same Model (every part of a Model is associated with an
  Aspect),
\item {\bf Connections}, which are used to represent relationships between
  the elements of the domain,
\item {\bf References}, which are used to refer to other elements in
  different portions of a DSML hierarchy (unlike connections which can be
  used to connect elements within a Model),
\item {\bf Sets}, which are containers whose contained elements are defined
  within the same aspect and have the same container as the owner.
\end{itemize}

\EndSidebar



%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "JVLC06"
%%% End: 
