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
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Venkita Subramonian">
<meta name="GENERATOR" content="Mozilla/4.79 [en] (Windows NT 5.0; U) [Netscape]">
<title>CIAO Static Configuration</title>
<base target="main">
<!-- $Id$ -->
</head>
<body>
<center>
<h2>
CIAO Static Configuration Support for Real-Time Platforms</h2></center>
<h3>
<a NAME="intro"></a>1. Introduction</h3>
The dynamic packaging, assembly, and deployment mechanisms currently available
in CIAO are useful for application domains where component metadata is
less likely to be known a priori, where implementation upgrades may need
to be performed on-line, and where platform features like loading and unloading
dynamic libraries are both available and useful. Furthermore, the
new CCM Deployment and Configuration specification describes a wider range
of configuration capabilities, opening up the question of alternative component
configuration strategies more generally and requiring that any solution
we devise can be migrated to that new configuration approach.
<p>Therefore, we have incorporated support for component configuration
in CIAO on platforms like VxWorks, as a set of optional strategies and
optimizations to the existing CIAO configuration capabilities. By
supporting both dynamic and static styles of configuration in CIAO, we
will both (1) be able to realize our short term goals in making CIAO available
on VxWorks for use in the Boeing PCES/MoBIES OEP, and (2) set a precedent
for availability of static configuration capabilities more generally, so
that DRE systems are well-supported within the new Deployment and Configuration
specification implementation for CIAO as well.
<p>The fundamental intuition in understanding our approach is that in DRE
systems the stages of the overall system lifecycle are similar to those
in more dynamic conventional component-oriented client-server applications.
However, in DRE systems several phases of the system lifecycle are compressed
into the compile-time and system-initialization phases, so that (1) for
testing and verification purposes the set of components in an application
can be identified and analyzed before run-time, and (2) overheads for run-time
operation following initialization are reduced and made more predictable.
Furthermore, due to the nuances of the platforms traditionally used for
deploying DRE systems, not all features of conventional platforms are available.
Our approach therefore avoids certain mechanisms that are either unavailable
or too costly in terms of performance.
<p>We follow these intuitions in our approach, taking the existing configuration
phases in CIAO and pushing several of them earlier in the configuration
lifecycle. We ensure that our approach can be realized in the context
of the platforms on which the Boeing PCES/MoBIES OEP will be deployed,
notably VxWorks, by re-factoring the configuration mechanisms and retargeting
them to use only the services available on the target real-time platforms.
<br>
<h3>
<a NAME="currentarch"></a>2. Current CIAO Configuration Architecture</h3>
<center>
<p><br><img SRC="ciao-dynamic1.jpg" height=462 width=774>
<p><b>Figure 1. Current configuration process in CIAO</b></center>
<p>The first stage of the CIAO system lifecycle occurs off-line, when component
package (.csd) and assembly (.cad) files are generated by a modeling tool
or other prior stage of the tool chain. These files contain an abstract
specification of the configuration that is to be achieved by CIAO in each
particular deployment environment .
<p>CIAO interprets these .csd and .cad files, and creates and configures
the components, their run-time server environments, and QoS properties
within the supporting ORB and other related infrastructure. Currently,
CIAO runs several daemon processes for each deployment environment: one
or more Component Installation / Server Activation (CISA) daemons on each
machine where components can be deployed, an additional Assembly Manager
daemon and an Assembly Deployer process used by the system developer.
<p>The Assembly Manager stores an internal table with the target platform
availability information . The Assembly Deployer tells
the Assembly Manager which assemblies of components (each assembly is defined
in a separate .cad file) should be deployed on which target machines.
The Assembly Manager parses the XML structures in the .cad file, and generates
its own internal data structure (<b>Figure 2</b>) as an intermediate representation
of that assembly.
<p>The Assembly Manager then traverses (<b>Figure 2</b>) this intermediate
representation, instructing each CISA daemon to install and configure specific
component servers and containers, to create specific homes, and to instantiate
specific component instances. Each CISA daemon has additional
information about the component implementations available on that endsystem
– each component UUID is mapped to a disk path for the .dll or .so file
within which a factory method for its home factory is defined.
<center>
<p><img SRC="ciao-dynamic2.jpg" height=384 width=699>
<p><b>Figure 2. Intermediate representation of configuration information</b></center>
<p>The following steps are optional, and will only be performed if they
are explicitly specified in the assembly definition itself. For the
sake of discussion, we consider the case where all the steps are in fact
specified. The Assembly Manager will tell the CISA daemon the UUIDs
of the components to be installed in that component server, and the CISA
daemon will look up and load the appropriate dynamic library, invoke the
home factory method to create the home, and then invoke the home’s component
creation method. After all the component instances and homes have
been created and references to them have been obtained, the assembly manager
will then make all the connections between ports and receptacles, facets,
and event sources and sinks by invoking connect and subscribe methods on
the receiving end component.
<p>QoS-specific metadata like priorities can be configured by a .cad file
extension called a real-time descriptor (.rtcad) file. The Assembly
Manager will read the .rtcad file and will parse and associate real-time
policies with the appropriate component instances. One implication
of this mechanism is that the Assembly Manager will maintain QoS meta-data
within its intermediate representation, alongside the conventional CCM
meta-data.
<p>Furthermore, when the Assembly Manager interacts with the CISA daemon(s)
on each endsystem, commands to configure particular component and component
server run-time infrastructure QoS properties are passed from the Assembly
Manager to the CISA daemon. The ORB (and as a future extension the
ORB Services) of the endsystem on which the components are installed is
currently configured via the ACE Service Configurator. The CISA daemon
maps different service configurations (as defined in particular svc.conf
files) to logical names used in the component assembly descriptors.
<p>The logical configuration names are encoded within the .cad file as
an extension of the conventional .cad file format using the “extension”
element of the existing .cad file XML DTD. The Assembly Manager passes
a component server creation command, containing a logical configuration
name, which the CISA daemon maps to a particular svc.conf file when it
creates a new component server. The CISA daemon adds a command line
flag to the execution command line used to spawn the new component server,
which causes that configuration file to be parsed and applied during startup
of the component server itself.
<h3>
<a NAME="staticapproach"></a>3. Static Configuration Approach</h3>
In the static configuration approach (<b>Figure 3</b>), configurations
XML files are translated in a code generation step just before compile
time (managed by the same project/Makefile processes that do the compilation)
into C++ header and source files that are then compiled and linked with
the main application.
<center>
<p><img SRC="ciao-static1.jpg" height=523 width=800>
<p><b>Figure 3. Static Configuration in CIAO</b></center>
<p>First, one of the generated files is a C++ header file, so that it can
be included directly by C++ source files. There is no additional
parsing required to import a number of static constants and identifiers
it declares and defines, so that those constants end up being compiled
directly into C++ code. Second, where enumeration of information
is needed, the header file contains simple homogeneous C++ arrays so that
C++ source code can iterate over those arrays with minimal overhead.
Third, it declares information so that later information depends on earlier
information (<b>Figure 4</b>), and the components are directly configured
within that header file.
<center>
<p><img SRC="ciao-static2.jpg" height=476 width=816>
<p><b>Figure 4. All XML files are parsed offline and stored as cross-referenced
tables in Static_Assembly_Config.h</b></center>
<p>The major issues that we addressed in developing a re-factored version
of the CIAO configuration mechanisms are as follows:
<p>1. XML parsing is too expensive to be performed during system initialization,
so that all such parsing has been moved off-line to before compile-time,
and the resulting information is linked statically into the application
itself.
<p>2. Each endsystem boots and initializes in a single process address
space, so that any remaining inter-process communication between daemons
is replaced by direct interactions between objects, or at most between
threads.
<p>3. Dynamic link libraries are unavailable on VxWorks, so an alternative
mechanism for obtaining the home factory method entry point is needed.
We gather this information from the XML files and statically generate a
map containing the entry point function names and the entry point
function pointers. This information will be used by the CIAO container
implementation instead of trying to load a dll and then finding the entry
point in the dll.
<h4>
Moving XML Parsing Earlier</h4>
We first focused on taking the XML parsing stage off-line. Since
the time required to do this by CIAO is currently reasonable as an off-line
activity, we simply created (<b>Figure 4</b>) a stripped-down version of
the Assembly Manager (reusing the existing class libraries the Assembly
Manager uses) that after it performs the XML parsing and generation of
its intermediate representation, emits a C++ header file containing that
intermediate representation.
<h4>
Combining Configuration Daemons at Run-Time</h4>
The intermediate representation is included in a configuration engine (CIAO::Static_Configurator)
that consists of a simple reader for the intermediate representation, again
derived from the code currently used in the Assembly Manager, which will
dispatch to the configuration code used by the CISA daemons in the dynamic
case. The configuration engine will be invoked from the application’s
main entry point prior to starting execution of the application itself.
<h4>
Eliminating Dynamic Library Loading</h4>
All code will need to be known a priori, and linked statically into the
application. If alternative configurations must be supported statically,
then those separate configurations can be alternative selections chosen
during the build process. If alternative configurations must be selected
adaptively at run-time then all the code for each possible configuration
must be linked in statically, and appropriate mechanisms used to re-target
a logical name dynamically to each particular configuration (e.g., different
configurations for different system modes).
<br>
<br>
<br>
<br>
<center>
<p><img SRC="ciao-static-vs-dynamic.jpg" height=384 width=735>
<br><b>Figure 5. CIAO Dynamic vs Static Configuration</b></center>
<h3>
<a NAME="status"></a><b>4. Status of CIAO Static Configuration</b></h3>
The initial version of the CIAO static configurator is available under
$CIAO_ROOT/tools/static_configurator.
<p>To run the static configurator,
<p><b><tt>Static_Assembly_Parser -a <.cad file></tt></b>
<p>This will generate three files -
<p><b><tt>Static_CCM_App.cpp</tt></b> - this file contains the main program
which instantiates the component server and invokes the static configuration
engine to create containers, homes, etc.
<p><b><tt>Static_CCM_App.mpc</tt></b> - this file contains the necessary
files for building the static application. You have to manually change
this file so as to include files that are not known to the static configurator.
<p><b><tt>Static_Assembly_Config.h</tt></b> - this file contains the C++
intermediate representation of all the information in the .cad, .csd and
.ssd XML files.
<p><a NAME="Example"></a><b>Example</b> - An <a href="static_config_example.html">example</a>
run is shown using the <a href="../examples/OEP/BasicSP">BasicSP</a> scenario.
<h3>
<a NAME="futurework"></a><b>5. Future work</b></h3>
The current implementation does not have support for processing RTCORBA
policy related information in .rtcad file. We plan to support this in a
future implementation.
<p>The current implementation does not have support for multiple component
servers running on multiple processors. Multiprocessor scenario involves
coordination and synchronization among the component servers running on
different processors. There has to be some kind of a mediator which determines
that all components are instantiated before connections can be made among
them.
<p>We aim to ensure that the time and space costs of initialization and
operation are kept as close as possible to those currently seen in the
Boeing PCES/MoBIES OEP, and we will follow our implementation of these
alternative mechanisms by performing empirical studies to determine the
extent to which our approach succeeds in these goals, and to identify opportunities
for improvement.
<br>
<br>
</body>
</html>
|
