diff options
Diffstat (limited to 'modules/CIAO/docs/static_ciao_contents.html')
| -rwxr-xr-x | modules/CIAO/docs/static_ciao_contents.html | 359 |
1 files changed, 359 insertions, 0 deletions
diff --git a/modules/CIAO/docs/static_ciao_contents.html b/modules/CIAO/docs/static_ciao_contents.html new file mode 100755 index 00000000000..d043e4c0aee --- /dev/null +++ b/modules/CIAO/docs/static_ciao_contents.html @@ -0,0 +1,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> |