% $Id: challenges.tex 6420 2007-05-14 10:49:40Z gokhale $

\section{Designing Visual Tools for Middleware Provisioning}
\label{sec:challenges}

Middleware provisioning is the activity that comprises the
configuration, optimization and validation of the middleware
platform for QoS properties of the hosted applications.  We are
interested in the systemic (i.e., non-functional) properties of
applications that are assured by the middleware provisioning process.
The motivation for visual tools in middleware provisioning stem from
the non-intuitive, non-reusable and error-prone nature of traditional
approaches.  For visual tools to be effective, they must meet a set of
criteria described below and resolve the challenges arising in meeting
these criteria.   

\textbf{$\bullet$ Criterion 1: Accounting for variability across a
  range of middleware technologies:}
Figure~\ref{fig:mw-stack} illustrates the structure of contemporary
middleware technologies.  It depicts multiple layers of middleware,
each of which addresses specific requirements and provides reusable
functional capabilities.  For example, the host infrastructure
middleware provides a uniform layer of abstraction to mask the
heterogeneity arising from different operating systems, hardware and
networks; the distributed middleware provides location transparency;
common services include directory services, messaging services, and
transaction services among others; and domain-specific services
include additional reusable capabilities that are specific to a domain
(e.g., avionics or telecom).

\begin{figure}[htb]
\centering
\vspace{-.7in}
\includegraphics[width=0.7\columnwidth]{mw-stack}
\vspace{-1in}
\caption{Middleware Structure}
\label{fig:mw-stack}
\end{figure}

Distributed applications are typically hosted on multiple
heterogeneous middleware platforms in a networked environment.  For
each host in the deployment environment, the middleware stacks on
which an application is hosted may need to be fine-tuned in different
ways to meet the different QoS requirements of applications.
To support a wide range of application QoS needs, contemporary
middleware technologies provide several different reusable
capabilities that can be individually configured and composed with
each other.  This flexibility offered by individual middleware
technologies gives rise to variability that a middleware provisioner
faces when provisioning applications on the platforms. 

The visual tool used for middleware provisioning must handle this
variability in the context of application QoS needs, and provide
an intuitive user interface to the middleware provisioner to eliminate
provisioning errors.  Our approach to resolve these challenges is
based on abstracting away the implementation- and technology-specific
details of contemporary middleware solutions and focus on the patterns
of reuse~\cite{Vlissides:94} that form the building blocks of the
different layers of middleware.  Section~\ref{sec:posaml-variability}
describes how we leverage and formalize these insights to design and
implement the POSAML visual tool for middleware provisioning.

\textbf{$\bullet$ Criterion 2: Separation of concerns:}
Each phase of middleware provisioning is filled with numerous
accidental complexities.  For example, the configuration phase
requires the actors to make the right decisions on the choice of
configuration options to select.  When confronted with multiple
different middleware technologies, the actor is required to have
detailed understanding of the flexibility and configurability of the
middleware stack.  Similarly, optimizations require different kinds of
fine tuning and are driven by the QoS needs of the application.  Once
again we observe that different middleware technologies use different
data models and messaging standards which require different kinds of 
optimizations.  The QoS validation phase involves analytical and
empirical evaluation of QoS properties.  It requires the systems
developers to construct appropriate application testing and middleware
benchmarking code in accordance to the configuration decisions.  
Many different techniques exist for such evaluations and different
middleware stacks will need potentially different methods to validate
QoS.  Each of these phases thus incurs substantial accidental
complexity as described, which is further compounded by the fact that
they are all driven by the same QoS requirements of the application
and decisions at one phase impact the other.  There is a need to
disentangle the phases at an intuitive level of abstraction that
addresses the challenges incurred by the accidental complexities in
each phase.  Section~\ref{sec:posaml-soc} describes how POSAML provides these
separation of concerns at the user interface level using visual
notations of middleware abstractions and their features.  

\smallskip
\textbf{$\bullet$ Criterion 3: Need for a unified framework:}
Although traditional approaches to middleware provisioning decouple
the configuration, optimization and validation phases, such a
decoupling is not useful since each subsequent phase tends not to keep
any knowledge of the earlier decisions.  Moreover, these activities
are typically carried out by a different set of actors.  Although
decoupling is necessary to separately address the challenges in each
phase, it is necessary that the intent of the actors and their
decisions be made available to all phases.  As noted earlier, however,
middleware provisioning needs to be guided by the application QoS
needs.  This requires that the three stages of provisioning be 
performed in a unified manner (although visually separated) such that
decisions made in the configuration phase are leveraged in the
optimization phase, and the decisions of these two phases are
leveraged in the QoS validation phase.  Thus it is important that
the separation of concerns be restricted to an intuitive level of
abstraction, such as at the level of visual perception to the
actors.   This requirement adds a new dimension of variability to the
challenges described in Criterion 1.  Moreover, it requires that the
separation of concerns called for in Criterion 2 remain at the visual
abstraction level so that the process is more intuitive but remains
unified internally.   To address these criteria, the visual mechanisms
should provide a unified framework that can address the configuration,
optimization and QoS validation concerns that arise in middleware
provisioning.  Such a framework must provide the means to transfer 
the intent and decisions at each stage to the next in the entire
provisioning lifecycle.  Section~\ref{sec:posaml-framework} describes
how POSAML provides intuitive abstractions of the middleware stacks to
the system integrators, which eases the task of provisioning. 


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