%% $Id: FOCUS.tex,v 1.2 2005/10/14 16:29:03 schmidt Exp $

%%%%%
% Here are reviewer's comments that all relate to automating the
% specializations. This section should address all of the concerns
% expressed by the reviewers.
%%%%

%%%%
% Reviewer #1: The question is how should they be implemented without
% doing them by hand. That is the key challenge that this paper motivates
% but does not address.
%%%%%

\section {Framework for Automating Middleware Specializations}
\label{FOCUS-approach}
Although our specializations improved TAO's performance and
predictability, the effort required to specify and apply these
specializations was prohibitive for production middleware and PLAs for
DRE systems, {\em e.g.}, manually applying these specializations to
the millions of lines of C++ and thousands of components in Bold
Stroke would be infeasible.  In this section, we describe the Feature
Oriented Customization (FOCUS) tool we are developing to automate
specialization of middleware for PLAs.

\sqztiny
\subsection {FOCUS Motivation \& Goals}
\label{focus-goals}
Our primary goal for FOCUS is to build specialization language, tool
and process to automate the specializations across different
platforms.  The different types of specializations discussed in the
paper required the following capabilities to be supported by an
automation framework:

\sqzlarge\paragraph*{\bf 1. Ability to do simple code manipulation}
Framework specialization required capability to devirtualize
hook methods in the base classes.  All the specializations required
some form of pattern matching capabilities for search and replace
type of operations.

\sqzlarge\paragraph*{\bf 2. Ability to copy chunks of code} Framework
specializations need to move specialized code (concrete implementation
of the template methods) from the derived class to the base class.
Similarly additional include files and class members may need to be
moved from/to a derived class to/from a base class.

\sqzlarge\paragraph*{\bf 3. Ability to comment code regions}
Code refactoring, memo-ization and aspect weaving
specializations required redundant functionality to be removed.
For example, in the memo-ization optimization the fast path can
be woven in by first commenting out the invocation to the normal
path and replacing it with the appropriate fast path.

{
\begin{table}[htpb]
\begin{center}
\scriptsize
\begin{tabular}{|c|c|}\hline
{\bf Category} & {\bf Tools}
\tabularnewline \hline
 Aspects & AspectJ, AspectC++ \tabularnewline \hline
 Transformational & DMS, Stratego-XT\tabularnewline \hline
 Template Code based & Jostraca \tabularnewline
 approach & Java Emitter Templates \tabularnewline \hline
\end{tabular}
\caption {Existing specialization Tools}
\label{spl-tool-summary}
\end{center}
\vspace{-0.5cm}
\end{table}
}

Given these requirements, we initially considered different language
mechanisms shown in Table~\ref{spl-tool-summary}.  Aspect mechanisms
such as AspectC++~\cite{Spinczyk:02} provided capabilities for code
manipulations but did not support our necessary capabilities such as
commenting/copying regions of code and ability to devirtualize the
specialization hooks.  Additionally, AspectC++ was not able to parse
the TAO middleware implementation.  Template code approaches such as
Jostraca~\cite{Rodger:02} combined annotations (directives) with code
templates to generate concrete executable programs in different
languages. Using this approach specialized classes can be generated
from code templates, indirectly providing capabilities 2 and
3. However this approach did not support code manipulation
capabilities.  Transformational systems such as DMS~\cite{Baxter:01}
and Stratego-XT~\cite{Vis01.rta} provided a transformational language
(such as Straetgo) for capturing the transformation in either
abstract/concrete syntax and set of transformational tools (such as
XT) for executing transformation across different languages.  These
approaches have historically been applied to compiler optimizations
(such as dead code elimination), program generation (pretty printing)
and document generation.  However, these approaches provide
specialization based on language features such as constant
function/procedure arguments as opposed to feature level invariance
which is our goal.

We next describe the language features and capabilities of our FOCUS
(\url{www.dre.vanderbilt.edu/~arvindk/FOCUS}) automation framework and
illustrate how it addresses our specialization goals.

\sqztiny
\subsection {FOCUS Approach for Specialization Automation}
\label{focus-design}

The FOCUS approach can be broken down into the following phases that are
executed by two actors, the middleware and application PLA developers:

\sqztiny
\subsubsection {Capturing Specialization Transformations}
In this first step the middleware developer captures the code level
transformations required to implement a specialization using the
FOCUS specialization language.  Currently, the language allows
the following types of specializations including:
search and replace transformations, copying text from different positions
in multiple files onto a destination file, commenting regions of a
program and capability to remove text from a program.  The specialization
language uses an XML DTD approach for capturing the transformations.

Listing~\ref{reactor-spl-rules} depicts portion of a specialization file
that to capture transformations required to automate challenge 5
(Section~\ref{mw-spl-challenges}).
\begin{Box}
\caption{\footnotesize{Reactor Specialization}}
\label{reactor-spl-rules}
\begin{Verbatim}[frame=none,fontsize=\scriptsize]
<?xml version='1.0'?>
 <transform>
1: <module name="ace">
2:  <file name="Select_Reactor_Base.h">
3:   <add>
4:    <hook>REACTOR_SPL_INCLUDE_HOOK</hook>
5:    <data>class ACE_Sig_Handler;</data>
6:    <data>class ACE_Sig_Action;</data>
7:   <data>class ACE_Sig_Set;</data>
8:  </add>
9:  </file>
10: </module>
11: <module="TAO/tao">
12:  <file name="advanced_resource.cpp">
13:   <comment>
14:    <start-hook>TAO_REACTOR_SPL_COMMENT_HOOK_START
       </start-hook>
15:    <end-hook>TAO_REACTOR_SPL_COMMENT_HOOK_END
       </end-hook>
16:   </comment>
17:  </file>
18: </module>
23: ....
  </transform>
\end{Verbatim}
\end{Box}
Lines 1--2 capture the module (directory or package) and file on which
the transformations are done. Lines 3--8 capture forward declarations
required to bring in other class declarations required for the
specializations.  These declarations (represented in the $<$data$>$ tags) are
placed at a predetermined point (represented in the $<$hook$>$ tags) within the
source files.  Similarly lines 14--16 show how unspecialized code within two
points in the file ($<$start-hook$>$ ... $<$end-hook$>$) is commented out for
the transformations.  The output of this phase is a or a set of
specialization files required that capture the all the transformations
needed for the specialization.

An XML based specialization language facilitates ease of (1)
extension, {\em i.e.}, additional transformations can be represented
via new XML tags and (2) transformation, {\em i.e.}, XSLT
transformations can be used to transform the specializations onto
different tool input formats.  Similar approaches have been used in
commercial tools, {\em e.g.}, Ant{(ant.apache.org}) uses an XML
approach for capturing build steps and rules.

\sqztiny
\subsubsection {Middleware Annotation}
In this phase, using the specialization files, a middleware developer
annotates the middleware with meta-data required for the
transformations.  In FOCUS, annotations are required only for
transformations that copy, comment or add code (when $<$add$>$,
$<$comment$>$ or $<$copy-from-source$>$ tags are used).  Other transformations
such as search and replace and remove do not require annotation.  Metadata
is inserted as special comments in the source code.
Listing~\ref{annotated-source} shows how the middleware developer annotates
source code with hooks based on the specialization file
(Listing~\ref{reactor-spl-rules}).  She adds two hooks, one for forward
declaration and one for commenting unspecialized code in the respective
source files.  In FOCUS,
the names for the hooks do not have any significance, {\em i.e.}, they
can be arbitrary as long as there is a corresponding name in the
specialization file.

\begin{Box}
\caption{\footnotesize{Annotated Middleware Source Code}}
\label{annotated-source}
\begin{Verbatim}[frame=none,fontsize=\scriptsize]
//File: Reactor.h
class ACE_Reactor_Impl;

/* FOCUS forward declaration hook */
//@@ REACTOR_SPL_INCLUDE_HOOK
class Reactor
{
public:
  virtual int
   run_reactor_event_loop (REACTOR_EVENT_HOOK = 0);
  // Other public methods ....
private:
  ACE_Reactor_Impl *reactor_impl_;
  // ......
};

//File: advanced_resource.cpp
ACE_Reactor_Impl*
TAO_Default_Resource_Factory::
  allocate_reactor_impl (void) const
{
  ACE_Reactor_Impl *impl = 0;
  /* FOCUS: Comment hook */
//@@ TAO_REACTOR_SPL_COMMENT_HOOK_START
  ACE_NEW_RETURN (impl,
                  ACE_TP_Reactor,
                  0);
//@@ TAO_REACTOR_SPL_COMMENT_HOOK_END
  return impl;
}
\end{Verbatim}
\end{Box}
Annotations help our transformation process by:
(1) enabling a light weight specialization approach, where a
parser is not necessary to parse the entire source code to identify
the specialization points (hooks) and (2) identifying points of variability
within middleware where customization
opportunities exists.  Annotation approach enables FOCUS to across
middleware implementations in different languages, where a hooks can be
left within a C++ or a Java based middleware implementation for FOCUS
to weave in code.

\sqztiny
\subsubsection {Executing Specialization Transformations}
Figure~\ref{focus-transform} illustrates the different steps in this
phase.  (1) A product-line application developer chooses the
specializations that are suitable for the variant. This is done during
the offline SCV analysis phase. (2) FOCUS transformation engine, based
on the features to be specialized, queries
the specialization repository to select the right file(s).
(3) Based on the
transformation rules in the specialization file executes
the transformations and (4)
Optimizing compiler then uses the modified source file to generate
executable platform code.

The FOCUS transformation engine is written in Perl.  The motivation being
to leverage the mature regular expressions support in Perl. Regular
expressions enhance the richness of the transformations to be specified
within the specialization files.
For example, search and replace capabilities in FOCUS leverage regular
expressions to ignore leading trailing white spaces and newline characters.
\begin{figure}[!htbp]
\center{
\includegraphics[width=8cm]{./figures/FOCUS-Transformation.eps}}
\caption{FOCUS: Transformation Process}
\label{focus-transform}
\end{figure}

Listing~\ref{reactor-spl-transformation} illustrates the transformed
source code using FOCUS where the base Reactor (\url{ACE_Reactor_Impl})
is replaced with the specialized Select\_Reactor.
Another observation is
that the annotations are preserved during the transformation process.
This enables multiple specializations to use the same hook for specifying
transformations thereby avoiding cluttering of hooks within the middleware
source code.

\sqztiny
\subsection {Summary}
Our FOCUS approach (1) has no run-time overheads, {\em i.e.}, incur
time/space penalties that make the specialized code slower than normal
middleware, (2) preserves middleware portability, {\em i.e.}, the
specialized middleware should run on all platforms on which the
middleware runs, (3) has no external dependencies, {\em i.e.}, not
require external libraries to be linked for execution, (4) is
extensible, {\em i.e.}, allow addition of new capabilities required
for future specializations, (4) provides role separation, {\em i.e.},
middleware developer captures the specialization and annotates the
middleware while the PLA application developer selects the
specialization at a feature level (5) provides an open-source
implementation. The transformations in FOCUS are compile time static
transformations, similar to other source-to-source transformations
such as AspectC++, DMS and JET.  FOCUS specializations modify only
framework structure and do not affect business logic.  Therefore
existing framework is still available when developers need OO
capabilities.

The limitations of FOCUS include: (1) need for annotations to be
synchronized with the specialization rules, {\em i.e.}, if the
annotations are changed the specialization files also need change, (2)
modifications/enhancements to the state and/or- interface of
implementations require changes to the specializations, {\em i.e.}, if
the name of an operation or its parameters change, the specialization
files need to be updated, (3) inability of the transformation engine
to guarantee that the woven code compiles or executes, a restriction
for source-to-source languages such as AspectC++ and (4) lack of
dynamic run-time specializations. Limitation (3) can be ameliorated
via offline Quality Assurance (QA) techniques that can be used to
validate the specializations regularly to ensure correctness during
middleware evolution.  Similarly, as our specializations are driven by
invariance assumptions known a priori, our approach does not require
run-time specializations, similar to \url{cflow} constructs in
Aspects.

\begin{Box}
\caption{\footnotesize{Transformed Middleware Source Code}}
\label{reactor-spl-transformation}
\begin{Verbatim}[frame=none,fontsize=\scriptsize]
//File: Reactor.h

//@@ REACTOR_SPL_INCLUDE_HOOK
// Code woven by FOCUS:
#include "ace/Select_Reactor.h"
// END Code woven by FOCUS
class Reactor
{
public:
  int
   run_reactor_event_loop (REACTOR_EVENT_HOOK = 0);
  // Other public methods ....
private:
// Code woven by FOCUS:
  ACE_Select_Reactor *reactor_impl_;
// End Code woven by FOCUS
  // ......
};
// File: advanced_resource.cpp
// Code woven by FOCUS:
ACE_Select_Reactor*
// End Code woven by FOCUS
TAO_Default_Resource_Factory::
  allocate_reactor_impl (void) const
{
// Code woven by FOCUS:
  ACE_Select_Reactor *impl = 0;
// End Code woven by FOCUS
  /* FOCUS: Comment hook */
//@@ TAO_REACTOR_SPL_COMMENT_HOOK_START
//  ACE_NEW_RETURN (impl,
//                  ACE_TP_Reactor,
//                  0);
//@@ TAO_REACTOR_SPL_COMMENT_HOOK_END
// Code woven by FOCUS:
}
\end{Verbatim}
\end{Box}
