\section{Related Work}
\label{sec:related}

This section briefly describes related work.

\sqztiny\paragraph {Techniques for middleware configuration.}
% TO-DO
% we should talk about different ways middleware can be configured
% e.g., service configurator, XML property files - Andy
A number of ORBs (such as VisiBroker, ORBacus, omniORB, and CIAO)
provide mechanisms for configuring and customizing the middleware.
For example, CIAO uses the ACE Service Configurator
framework~\cite{Schmidt:02a}, which can be used to statically and
dynamically configure components into middleware and
applications. Likewise, Java provides an API for configuring
applications based on {\em XML property files}.  Key/value pairs for
specific options are stored in an XML-formatted files and read by
applications using XML parsers or a provided API.

The Microsoft .Net platform provides a similar approach to the Java
XML property files named {\em .Net configuration files}.  The {\tt
System.Configuration} API can be used to read the configuration.
\iffalse
Using this API, .Net provides access to three different information:
(1) {\em machine configuration files}, which control machine-wide
assembly binding and remoting channels, (2) {\em application
configuration files}, which control application-specific
configurations, such as assembly binding policies and remoting
objects, and (3) {\em security configuration files}, which contain
security information for applications.
\fi

\sqztiny\paragraph {Empirical QoS evaluation.}
\label{empirical_relwork}
There have been several initiatives that use generative techniques for
quality assurance similar to our work.

ForeSight~\cite{LiuY:02} uses an empirical benchmarking engine to
capture QoS information for component middleware. The results are used
to build mathematical models to predict performance. ForeSight uses a
three-pronged approach of (1) creating a performance profile of how
components in a middleware affect performance, (2) constructing a
reasoning framework to understand architectural trade-offs, {\em
i.e.}, know how different QoS attributes interact with one another,
and (3) feeding this configuration information into generic
performance models to predict the configuration settings required to
maximize performance.

SoftArch/MTE~\cite{Grundy:01} provides a framework for system
architects to define higher level abstractions of their system by
specifying characteristics such as middleware, database technology,
and client requests. SoftArch/MTE then generates an implementation of
the system along with the performance tests that measure these system
characteristics. These results are then displayed back, {\em i.e.},
annotated in the high level diagrams, using tools such as Microsoft
Excel, thereby allowing architects to refine the design for system
deployment.

These techniques lack the means to identify the dominant or
main-effects C\&C options that are crucial for our approach.
