Release Information for the Component Integrated ACE ORB (CIAO)
This document contains information on the following topics related to the
release of CIAO:
- The first cut of the new DnC
specification implementation, which we call DAnCE is available in
this distribution. DAnCE is housed under
. We plan to enhance DAnCE in the next few months. We believe
DAnCE will replace existing tool sets in
$CIAO_ROOT/tools. There are a few features in
$CIAO_ROOT/tools that are missing in the DAnCE
implementation. Please see TODO file
for more details. We plan to implement them soon and use DAnCE
- The first cut of DAnCE includes two parts:
A modeling tool chain ,
CoSMIC, which is capable of describing the Assembly/Component
GME as the development bed. The artifacts generated from the
CoSMIC are a set of XML descriptors.
- This run-time infrastructure that performs the actual deployment
and configuration, with a superset of the capabilities described in
OMG DnC specification with CIAO extension.
In the new DnC run-time framework we have migrated all the
functionalities present in the old CIAO runtime except the
Real-Time configuration and Static Configuration, which are
developed by Washington University in St. Louis. Currently,
the two CIAO runtime co-exist in our source and the component
implementation could be used with both framework without much
change. (For the change that one has to go through please
ciao_preactivate () and
ciao_postactivate () have been added to the
SessionComponent interface. This implies that component
developers have to implement those operations within the
executor. We plan to get around this, i.e., users having to
implement these two operations, in the next month or so.
Here is a set of updates in the CIDL Compiler.
- Fixed bugs in generation of inherited: home operations,
attribute operations, port operations, home factory operations,
- Added support for multiplex uses ports. This implies that users
could use "uses multiple" in their component definitions.
- Added automatic registration of value factories for event
consumers. This has been long outstanding. This change alleviates
component developers need to register the valuetype factory of their
eventtypes with the ORB.
- Added support for emits keyword and we now generate navigation
code for this.
- Fixed bug with multiple facets in a build that provide the same
- Added option
--gen-exec-impl to generate executor
impl classes, with no-op versions of each IDL operation.
- Implemented get_all_facets() and get_all_consumers() navigation
- Added support for the IDL keywords
getraises, associated with attributes in IDL3.
- Added support for both subscription and event push of event types
that are a base class of the IDL-specified port type. A check is
performed during the subscribe call to make sure the eventtype is
actually an ancestor of the declared port type.
- Problems with generated code when the composition declaration is
nested inside one or more IDL modules has prompted a change. The
'CIAO_GLUE_' prefix has been eliminated. The composition name is now
mapped to a C++ namespace, prefixed with 'CIDL_'. This new namespace
(as well as namespaces generated from IDL modules enclosing the
composition name, if any) encloses
- the component servant class
- the home servant class
- all facet servant classes, if any
- the *_Exec interface in the *E.idl file
- all executor impl classes, if automatically generated
CIAO doesn't yet support features that help integrating CORBA
components with Enterprise Java Beans (EJB).
Test to demonstrate composition of applications with real-time
behavior using CIAO's real-time extension was added. Please see
The CIAO static configurator tool has been enhanced to support
processing of RTCORBA policy related information. Please see
To further interoperability with non-component-aware clients, there
are files in the $CIAO_ROOT/tools/IDL3_to_IDL2 directory that can be
compiled into an executable called tao_idl3_to_idl2. This executable
takes an IDL file (on the command line) containing IDL3 declarations
and outputs an IDL file with the IDL3 declarations converted to
equivalent IDL2. IDL2 declarations in the input file are unchanged.
See the README file in that directory for more information.
Email: [email protected]