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
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
|
<!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.76 [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>
<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>
<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>
</p>
<h3><a name="currentarch"></a>2. Current CIAO Configuration Architecture</h3>
<center>
<p><br>
<img src="imgs/ciao-dynamic1.jpg" height="462" width="774"></p>
<p><b>Figure 1. Current configuration process in CIAO</b></p>
</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>
<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>
<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>
<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.
</p>
<center>
<p><img src="imgs/ciao-dynamic2.jpg" height="384" width="699"></p>
<p><b>Figure 2. Intermediate representation of configuration information</b></p>
</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>
<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>
<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>
<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.
</p>
<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="imgs/ciao-static1.jpg" height="523" width="800"></p>
<p><b>Figure 3. Static Configuration in CIAO</b></p>
</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.
</p>
<center>
<p><img src="imgs/ciao-static2.jpg" height="476" width="816"></p>
<p><b>Figure 4. All XML files are parsed offline and stored as
cross-referenced
tables in Static_Assembly_Config.h</b></p>
</center>
<p>The major issues that we addressed in developing a re-factored
version
of the CIAO configuration mechanisms are as follows:
</p>
<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>
<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>
<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.
</p>
<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="imgs/ciao-static-vs-dynamic.jpg" height="384" width="735"><br>
<b>Figure 5. CIAO Dynamic vs Static Configuration</b></p>
</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>
<p><b><tt>Static_Assembly_Parser -a <.cad file></tt></b>
</p>
<p>This will generate three files -
</p>
<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>
<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>
<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>
<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.
</p>
<h3><a name="futurework"></a><b>5. Future work</b></h3>
<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.<br>
<br>
</p>
</body>
</html>
|
