The OMG's CORBA Components Technology

Warning: This is not a full and official description of the Object Management Group's CORBA Component Model, only some of our points of view. For more details, have a look to the latest CCM Tutorial presented during OMG meetings.

The CORBA 2.4 specification provides interoperability for objects and applications through OMG IDL, mappings, GIOP, IIOP, and the POA. Some of the goals of the CORBA Component Model are:

Reuseability of software components,
Describing more than programming, in fact, only the functional aspects should be hand-written, other aspects should be described and/or generated,
Deployment that should be done automatically.

The current CCM specification defines the four following models:

The abstract model

The CCM abstract model offers developers to define interfaces and properties of components. The OMG IDL (Interface Definition Language) has been extended to express component interconnections. A component can offer multiple interfaces, each one defining a particular point of view to interact with the component. The four kinds of interfaces are named ports.

Two interaction modes are provided: facets for synchronous invocations, and event sinks for asynchronous notifications. Moreover, a component can define its required interfaces, which define how the component interacts with others: receptacles for synchronous invocations, and event sources for asynchronous notifications.

The abstract model also defines instance managers -- component homes -- which are based on two design patterns: factory and finder. A home is defined to create and retrieve a specific component type, and can only manage instances of this type. Nevertheless, it is possible to define several home types for a single component type.

The programming model

The CCM programming model defines the Component Implementation Definition Language (CIDL) which is used to describe the implementation structure of a component and its system requirements: the set of implementation classes, the abstract persistence state, etc. This language is associated with the Component Implementation Framework (CIF). This framework allows developers to merge the component functional part they have produced and the non-functional part generated from OMG IDL3 and CIDL descriptions. The functional part includes the implementation of the provided interfaces (facets and event sinks).

Using the OMG IDL3 definition as well as the CIDL description of the component, a compiler produces the skeleton of the component implementation. This skeleton includes the non-functional part of the component implementation, i.e. unmarshaling GIOP requests, port management, activation, and persistence requirements. These skeletons are implemented on top of APIs provided by containers. Thus, a developer only has to write the functional code in order to complete the component implementation. The compiler also produces the OMG IDL2 mapping as well as a XML descriptor for the component implementation. The OMG IDL2 will be used by component clients. The XML descriptor will be used during the deployment of the component implementation as discussed in the following subsection.

The implementation generated part also provides a dynamic introspection API. It includes the operations to discover component ports in a generic manner (same operations for any component type), or in a specific one (operations generated according to the component type). These operations can be used in a dynamic platform to introspect and interconnect component instances at runtime.

The deployment model

The CCM deployment model is based on the use of software packages, i.e. ``ZIP'' archives containing component descriptors and implementations. Descriptors are written using the Open Software Description (OSD) language which is a XML vocabulary. This language allows architects to describe four kinds of descriptors:

The Software Package Descriptor provides global information about a package such as the author of the package, the license, as well as interfaces, properties, dependencies, and implementations of a component.
The CORBA Component Descriptor contains technical information about the component implementation. This information is generated from the CIDL description and the administrator only has to set the policies (like security).
The Component Assembly Descriptor describes the initial configuration of the application. It defines which components to use and how to interconnect them.
The Property File Descriptor contains the value of the component properties. These are used while configuring the various component instances.

The deployment process allows architects to easily install an application on various sites. A ComponentInstallation and an AssemblyFactory have to be running on any site an application could be installed. These two objects are used by the deployment tool to install the packages of the application, and to create an instance of it. AssemblyFactory objects manage Assembly objects that represent deployed applications. The deployment tool provides an OSD assembly descriptor to the Assembly object that really performs the deployment of the application. Thus, the deployment process is fixed in this object, and cannot be controlled by an architect nor by the application!

The execution model

The CCM execution model defines containers as the technological artifacts. A container is a runtime environment for component instances and their homes. Several containers could be hosted by a same component server.

A container is more than a simple execution environment. Containers hide the complexity of most of the system services like the POA, transaction, security, persistence, and notification services. Thus, containers take part in the management of non-functional aspects of a component. Clients interact with a component instance through the generated OMG IDL2 interfaces.

An interesting feature of component servers is the ability to download archives from repositories. Thus, downloading packages can be done at any time, and more precisely only when a component is required.

Advantages of the CORBA Component Model compared to the CORBA object model

The following list identifies some of the advantages of the CORBA Component Model compared to the CORBA object model.

A global standard development process
The CORBA object model does not standardize a global development process. As contrary, the CCM makes role of designer (OMG IDL), developer/implementor (OMG CIDL), packager and assembler very clear. It identifies and addresses the concerns of each of them.
Assembling components visually
Creating visually assemblies was not easier with CORBA 2.x objects. But with CCM, building applications is plug and play now.
An automatized distributed deployment and configuration process
The CORBA object model does not address the deployment and configuration of distributed CORBA applications, i.e. it does not provide any means to express and automatize deployment and configuration of distributed CORBA objects. With CORBA 2.x, deployment is done by hand, e.g. CORBA processes must be started on each node where the application will run, and configuration must be hard coded into applications.

The CORBA component model provides an automatized distributed deployment and configuration process:
- to install the various component implementations of an application on a set of distributed nodes,
- to create component instances,
- to configure their attributes,
- to interconnect the created components,
- to start the components.
This deployment process could work because the CCM includes:
- a packaging and assembling technology, i.e. standard format for component and assembly archives and XML descriptors,
- a container technology to download and host components,
- a component model allowing to capture configurable attributes and interconnection ports (facets, receptacles, event sinks and sources) of each component.
Description of non functional aspects instead of explicit programming
With CORBA 2.x, developers must deal directly with ORB and POA features. Each time they want to use CORBA services like the Name Service, Trader Service, Security Service, Object Transaction Service, Persistent State Service, Notification Service in their applications, then they need to write code related to their services.

The CCM defines a set of standard profiles for using POA and services, some are implemented in the deployment process (those related to registration and querying of the Name and Trader services), other are implemented by containers like POA usages, access control checks, transaction demarcation, persistence, and event notification.

With CCM, developers need not to program code related to services, they just feel CCM XML descriptors which will be interpreted by the deployment process and/or containers in order to execute the right requested profiles.

Let's note that the previous list is not exhaustive and you are welcome to provide us your points of view. Please just send us an email to the OpenCCM mailing list.

Some WWW links

Some interesting OMG documents are:

OMG Components 1.2 RTF Web Page.
OMG Components 1.1 RTF Updated Specification,
OMG TC Document ptc/2002-08-03.
Local copy of the PDF file.
Download from OMG.
OMG Components 1.1 RTF Interim Report,
OMG TC Document ptc/2002-08-02.
Local copy of the PDF file.
Download from OMG.
OMG Components 1.1 RTF Web Page.
CORBA Components Specification, Version 3.0,
OMG TC Document formal/2002-06-65.
Local copy of the PDF file.
Download from OMG.

Some interesting WWW links about the CORBA Component Model are:

The Diego Sevilla Ruiz's CORBA and CORBA Component Model (CCM) Page: A lot of information about the CCM.

Some interesting books:

Bertram Neubauer, Tom Ritter, and Frank Stoinski, CORBA Komponenten - Effektives Software-Design und Programmierung, Published by Springer, July 2004, ISBN: 3-540-00922-1, ISSN: 14395428.

More information at: http://www.qedo.org/CCMBuch/index.html

Some interesting english papers:

Douglas C. Schmidt and Steve Vinoski, The CORBA Component Model: Part 2, Defining Components with the IDL 3.x Types, C/C++ Users Journal, April 2004.

URL: http://www.cuj.com/documents/s=9152/cujexp0404vinoski
Douglas C. Schmidt and Steve Vinoski, The CORBA Component Model: Part 1, Evolving Towards Component Middleware, C/C++ Users Journal, February 2004.

URL: http://www.cuj.com/documents/s=9039/cujexp0402vinoski
Philippe Merle, OpenCCM: The Open CORBA Components Platform, Presentation at the Third ObjectWeb Conference, INRIA Rocquencourt, France, 20 - 21 November 2003.

Abstract: OpenCCM, the Open CORBA Component Model Platform, is the first public available and open source implementation of the CORBA Component Model (CCM) specification defined by the Object Management Group (OMG). OpenCCM is an ObjectWeb project licensed under GNU LGPL.
OpenCCM allows you to design, implement, compile, package, assemble, deploy, install, instantiate, configure, execute, and manage distributed CORBA component-based applications.
This presentation provides a status on the latest stable OpenCCM 0.8 release and an overview of development perspectives for OpenCCM 1.0.
- Download the presentation (.ppt) file.
- Download the presentation (.pdf) file.
Philippe Merle, OpenCCM: Status and work plan, Presentation at the ObjectWeb architecture meeting, INRIA, Montbonnot Saint-Martin, France, 21 - 22 january 2002.
Raphaël Marvie and Philippe Merle, CORBA Component Model: Discussion and Use with OpenCCM, Technical Report, LIFL, France, 2002.

Abstract: Distributed Object Computing (DOC) middleware has introduced the use of Interface Definition Languages to improve the design, production, and execution of large scaled critical distributed applications. Nowadays, software engineering is evolving to Distributed Component Computing (DCC) middleware in order to also address deployment and administration of such applications. In this context, the Object Management Group proposes the CORBA Component Model (CCM) as ``the first industrial heterogeneous component model''. This model seems to be the proposal with the highest potential, compared to Sun Microsystems' Enterprise Java Beans and Microsoft's Distributed Component Model, to design, produce, deploy, and run distributed heterogeneous component based applications. Nevertheless, no implementation covers it in its whole. This article aims at discussing the CCM and to introduce OpenCCM---the first available open source implementation of the CCM. In that, most of the CCM concepts are illustrated using an example developed with OpenCCM.

Keywords: CORBA Component Model, Distributed Component Based Applications, Middleware, OpenCCM.

Download the .ps file.
Philippe Merle, OpenCCM, Presentation at the First ObjectWeb Conference, ENST Paris, France, 30 - 31 October 2001.

Abstract: OpenCCM (Open CORBA Component Model platform) is the first public available open source implementation of the CCM (CORBA Component Model) defined by the OMG (Object Management Group). OpenCCM allows to design, implement, compile, package, deploy, and execute distributed applications compliant with the OMG's CORBA Component Model. It includes a complete OMG IDL3 compiler, an OMG IDL3 Repository, generators for CCM's OMG IDL2 mapping and extended Java component skeletons,a Java component server to host Java components, and a distributed deployment infrastructure.

Some interesting french papers and reports are:

Philippe Merle, Au coeur d'OpenCCM, atelier durant la Quatrième École d'été sur les Intergiciels et sur la Construction d'Applications Réparties (ICAR 2003), organisée par l'INRIA Rhône-Alpes et le consortium ObjectWeb, Autrans, France, 25 - 29 août 2003.

Résumé : Présentation du projet OpenCCM et des principes de construction de sa chaîne de production, de son outillage de conditionnement et d'assemblage, de son infrastructure répartie de déploiement, de son outillage d'administration et de sa plate-forme d'exécution.

Mots-clés : CORBA, CCM, Composants, OpenCCM.
- Le fichier PowerPoint.
- Le fichier PDF.
Philippe Merle, Etude de cas d'une application construite avec CCM, atelier durant la Quatrième École d'été sur les Intergiciels et sur la Construction d'Applications Réparties (ICAR 2003), organisée par l'INRIA Rhône-Alpes et le consortium ObjectWeb, Autrans, France, 25 - 29 août 2003.

Résumé : Présentation de la construction de l'application diner des philosophes avec un environnement CCM.

Mots-clés : CORBA, CCM, Composants, OpenCCM.
- Le fichier PowerPoint.
- Le fichier PDF.
Philippe Merle, Le modèle de composants CORBA, cours durant la Quatrième École d'été sur les Intergiciels et sur la Construction d'Applications Réparties (ICAR 2003), organisée par l'INRIA Rhône-Alpes et le consortium ObjectWeb, Autrans, France, 25 - 29 août 2003.

Résumé : Présentation du modèle de composants CORBA.

Mots-clés : CORBA, CCM, Composants.
- Le fichier PowerPoint.
- Le fichier PDF.
Raphaël Marvie et Philippe Merle, Vers un modèle de composants pour CESURE - Le CORBA Component Model, Rapport Technique no 3, projet RNRT'98 CESURE, novembre 2000.

Résumé : Présentation du modèle de composants de CORBA, discussion sur les apports, avantages et inconvénients du CCM. Synthèse de l'état actuel de la spécification.

Mots-clés : CORBA, Composants, CCM.

Le fichier en .ps.gz.

L'entrée BibTeX :
```
    @TechReport{RNRT_CESURE_D3,
      author = 	 {Rapha"el Marvie and Philippe Merle},
      title = 	 {Vers un mod{\`e}le de composants pour
                  {CESURE} - Le {CORBA} {C}omponent {M}odel},
      institution =  {Projet {RNRT} 98 {CESURE}},
      year = 	 {2000},
      number = 	 {3},
      month =    {Novembre},
      note =     {http://www.gemplus.fr/cesure/},
    }
          
```

Raphaël Marvie, Philippe Merle, Jean-Marc Geib et Mathieu Vadet, OpenCCM : une plate-forme ouverte pour composants CORBA, actes de la 2ème Conférence Française sur les Systèmes d'Exploitation (CFSE'2), pages 1 - 12, Paris, France, 24 - 26 avril 2001.

Le fichier en .ps.

L'entrée BibTeX :

    @InProceedings{openccm_cfse2,
      author =    {Rapha"el Marvie and Philippe Merle and Jean-Marc Geib
                   and Mathieu Vadet},
      title =     {{O}pen{CCM}~: une plate-forme ouverte pour composants {CORBA}},
      booktitle = {Actes de la seconde {C}onf{\'e}rence {F}ran{\c}aise
                   sur les {S}yst{\`e}mes d'{E}xploitation ({CFSE'2})},
      year =      {2001},
      address =   {{P}aris, {F}rance},
      month =     {{A}vril}
    }