diff options
| author | venkita <venkita@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 2004-03-10 22:07:28 +0000 |
|---|---|---|
| committer | venkita <venkita@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 2004-03-10 22:07:28 +0000 |
| commit | 8c7ab69df895a47cf6b639fb2a5b8b373f83eb77 (patch) | |
| tree | 29b9656d1b5f34e7fff45a66cb0233c767a2235c /TAO/CIAO | |
| parent | 70be0978ef0175116ffc62b2447acf0d7d256578 (diff) | |
| download | ATCD-8c7ab69df895a47cf6b639fb2a5b8b373f83eb77.tar.gz | |
ChangeLogTag: Wed Mar 10 14:59:19 2004 Venkita Subramonian <venkita@cs.wustl.edu>
Diffstat (limited to 'TAO/CIAO')
| -rw-r--r-- | TAO/CIAO/ChangeLog | 7 | ||||
| -rwxr-xr-x | TAO/CIAO/docs/static_ciao_contents.html | 242 | ||||
| -rwxr-xr-x | TAO/CIAO/docs/static_ciao_index.html | 23 | ||||
| -rwxr-xr-x | TAO/CIAO/docs/static_ciao_toc.html | 26 |
4 files changed, 298 insertions, 0 deletions
diff --git a/TAO/CIAO/ChangeLog b/TAO/CIAO/ChangeLog index ba211073f54..5b0705eac44 100644 --- a/TAO/CIAO/ChangeLog +++ b/TAO/CIAO/ChangeLog @@ -1,3 +1,10 @@ +Wed Mar 10 14:59:19 2004 Venkita Subramonian <venkita@cs.wustl.edu> + + * docs/static_ciao_toc.html: + * docs/static_ciao_contents.html: + * docs/static_ciao_index.html: Updated documentation. Renamed + static_ciao.html to static_ciao_contents.html. + Wed Mar 10 12:36:01 2004 Jeff Parsons <j.parsons@vanderbilt.edu> * CIDLC/ServantHeaderGenerator.cpp: diff --git a/TAO/CIAO/docs/static_ciao_contents.html b/TAO/CIAO/docs/static_ciao_contents.html new file mode 100755 index 00000000000..2f21e719c61 --- /dev/null +++ b/TAO/CIAO/docs/static_ciao_contents.html @@ -0,0 +1,242 @@ +<!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>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> + +<p><a NAME="status"></a><b>4. Status of CIAO Static Configuration</b> +<p>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="futurework"></a><b>5. Future work</b> +<p>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> + diff --git a/TAO/CIAO/docs/static_ciao_index.html b/TAO/CIAO/docs/static_ciao_index.html new file mode 100755 index 00000000000..627e07c65ca --- /dev/null +++ b/TAO/CIAO/docs/static_ciao_index.html @@ -0,0 +1,23 @@ +<html> + +<head> +<meta name="GENERATOR" content="Microsoft FrontPage 5.0"> +<meta name="ProgId" content="FrontPage.Editor.Document"> +<title>New Page 1</title> +<!-- $Id$ --> + +</head> + +<frameset cols="294,*"> + <frame name="contents" target="main" src="static_ciao_toc.html"> + <frame name="main" src="static_ciao_contents.html" target="main"> + <noframes> + <body> + + <p>This page uses frames, but your browser doesn't support them.</p> + + </body> + </noframes> +</frameset> + +</html> diff --git a/TAO/CIAO/docs/static_ciao_toc.html b/TAO/CIAO/docs/static_ciao_toc.html new file mode 100755 index 00000000000..710276e2880 --- /dev/null +++ b/TAO/CIAO/docs/static_ciao_toc.html @@ -0,0 +1,26 @@ +<!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="Microsoft FrontPage 5.0"> + <title>CIAO Static Configuration</title> + <base target="contents"> +<!-- $Id$ --> +</head> +<body> +<h3 align="center">CIAO Static Configuration Documentation </h3> + +<ol> + +<li><a target="main" href="static_ciao_contents.html#intro">Introduction</a></li> +<li><a target="main" href="static_ciao_contents.html#currentarch">Current CIAO Configuration +Architecture</a></li> +<li><a target="main" href="static_ciao_contents.html#staticapproach">Static Configuration +Approach</a></li> +<li><a target="main" href="static_ciao_contents.html#status">Status of CIAO Static Configuration</a></li> +<li><a target="main" href="static_ciao_contents.html#futurework">Future work</a></li> +</ol> +</body> +</html> + |