Usage of CIF

In general the lifecycle of a component respective an assembly is determined by subsequent steps at least :

The implementation of a component using CIF requires only to fill in implementation code in generated business code skeletons. The skeletons are generated by the idl2idl compiler. Code has to be inserted for interface operations defined in supported and provided interfaces of the component, for components attributes, for home operations and for the entry_point function. Additionally a user can add arbitrary implementation code. All user added code persists over repeated compiler runs.

The packaging of component implementations or assemblies should be done by a special packaging tool for convenience. Nevertheless when using CIF, support for packaging may be integrated in makefile or project file. Currently the examples with VC++ embedd the command line version of winzip for instance.

The component implementation deployment is done using the interface ComponentInstallation, which is implemented by the Runtime/css executable of the container implementation. The subdirectory Runtime/Deployment of the CIF installation directory contains all deployment related stuff. The XML file DeployedComponents.xml contains information about all already installed component implementations and is used to keep those information persistent. The subdirectory ComponentPackages contains the softpackages for assemblies. Currently for each assembly intended to be installed, the package has to be put there before manually. During component installation for each component implementation to be newly installed, a directory named by the UUID of the implementation is created in the Runtime/ComponentImplementations subdirectory. Subsequently the idl2idl compiler generates the equivalent idl and implementation code for servants from the unpacked idl specification. The generated servant code together with the output of the ORB specific IDL compiler, compiling the equivalent IDL, finally is compiled and linked to a dynamic library. This library together with the business code libarary from the software package remains in the implementation specific directory. The used makefile is the makefile in Runtime/ComponentImplementations. For each ORB implementation and architecture the makefile has to be adapted.

The component assembly instantiation is done according to CCM by creating an assembly object. Therefore the interface Components/Deployment/AssemblyFactory is implemented by the Runtime/css server. A client has to create an assembly object giving the name of the assembly package, which must be in the Runtime/Deployment/ComponentPackages directory. Due to the lack of specification for package uploading, currently the package has to be moved to this directory beforehand. It has to be created by the assembly developer, containing an assembly descriptor, zip files for each component and probably property file descriptors for component instances. The component zip files in turn contain a software package descriptor, a CORBA Component Descriptor for each implementation, the dynamic library for the components business logic and the idl file for the servant code generation.

Setup the Component Runtime Environment

In order to setup the component container as the runtime environment for components, it must be properly installed (see), tools and dynamic libraries have to be in the appropriate path, the makefile for the actual environment in Runtime/Deployment/ComponentImplementations has to be adapted, the installations repository file Runtime/Deployment/DeployedComponents.xml has to be removed and a CORBA Nameservice has to be started. Afterwards the executable Runtime/css has to be started. This server runs implementations for the interfaces AssemblyFactory, ComponentInstallation and ServerActivator from the Components/Deployment module of CCM.