summaryrefslogtreecommitdiff
path: root/ACE/bin/FOCUS/README
blob: 7fd7059b9e60c6cd47100122f7471665c9333c43 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
$Id$
                          FOCUS README
                          ============

Motivation:
----------
Middleware is often developed as a set of frameworks that can be
extended and configured with alternative implementations of key
components, such as different types of transport protocols e.g.,
TCP/IP, VME, or shared memory), event demultiplexing mechanisms
e.g., reactive-, proactive-, or thread-based), request
demultiplexing strategies (e.g., dynamic hashing, perfect
hashing, or active demuxing), and concurrency models (e.g.,
thread-per-connection, thread pool, or thread-pre-request).  A
particular DRE application, however, may only use a small subset
of the potential framework alternatives.  As a result, general-purpose
middleware may be overly extensible, i.e., contain
unnecessary overhead for indirection and dynamic dispatching that is
not needed for use cases in a particular context.
A challenge is to develop middleware specialization
techniques that can eliminate unnecessary overhead associated with
overly extensible middleware framework implementations for certain
product variants or application-specific contexts.

Example and Approach:
--------------------
The reactor framework in ACE allows plug and play of different
reactors such as Select, TP, Devpoll etc. The TAO middleware
implementation and applications that run atop TAO typically use
one particular implementation of the Reactor. For example, a
single-threaded application might use select_* reactors. The
Reactor framework uses the bridge pattern to transparently
invoke operations on the right reactors. When the concrete
Reactor is known, it should be possible to specialize the
framework to use the concrete reactor directly rather than use
the bridge.

As a part of the Feature Oriented Customizer (FOCUS) tool being
,we are trying to specialize frameworks
when the concrete implementation type is known a priori. FOCUS
provides an XML based transformation engine, where the
specialization transformations are captured in XML file and a
weaver specializes the code.

To help in this transformation process, FOCUS applies markers
within the source code. These markers are added as special
comments. For example, //@@ REACTOR_SPL_INCLUDE_FORWARD_DECL_ADD_HOOK
represents a hook where forward declarations and include files are
added by the weaver. As these markers are comments therefore should not
affect normal applications in *any* manner. Additionally, applications
that use multiple reactor implementations not be affected/do not need any
change. Currently, these specializations are targeted for TAO middleware,
where applications know the target reactor a priori and want to
leverage the specialization to improve performance.

FOCUS Installation
------------------
. FOCUS is written using Perl and does not require any compilation. Additionally
  FOCUS does not depend on any external tools.

Requirements
------------
. FOCUS has been tested on Perl version 5.8.0 and uses the following Perl
  packages:
   -- XML::DOM package --> Perl package for processing XML DTDs

Sample Usage:
-------------
FOCUS can be invoked from the command line in the following manner:
cmd>$ACE_ROOT/bin/FOCUS/FOCUS.pl --reactor-spl=select-st
                                 --prefix-path=/build/arvindk/ACE_wrappers
                                 --output-prefix=/build/arvindk/spl-files

More Information:
-----------------
More information about FOCUS should be available from the docs directory.