ObjectWeb logo
Valid HTML 4.01!Valid CSS!
[Advanced search]
 [Become a member of the ObjectWeb Consortium! Membership is free for individuals.]

OpenCCM:   
Download  Documentation  Mailing lists  Partners  License  History 
Developers' corner:   
How to contribute  Workplan  CVS repository  ObjectWeb Forge site  User Mailing List  Team Mailing List 
About OpenCCM:   
Team  Contacts 
ObjectWeb resources:   
FAQ  Mailing lists  CVS repositories  Search  ObjectWeb Forge  Mirror sites 

 The OMG 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.

 Some WWW links 

Some interesting WWW links about the CORBA Component Model are:

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

Some interesting OMG documents are:

  1. CORBA Components Specification, Version 3.0,
    OMG TC Document formal/02-06-65.
    Download the PDF file.

Some interesting english papers:

  1. Philippe Merle, OpenCCM: Status and work plan, Presentation at the ObjectWeb architecture meeting, INRIA, Montbonnot Saint-Martin, France, 21 - 22 january 2002.

  2. 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.

  3. 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:

  1. 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},
              OPTmonth = 	 {Novembre},
              OPTnote = 	 {http://www.gemplus.fr/cesure/},
            }
              
  2. 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}
            }
              

Last modified at 2003-03-28 08:22 PM - Copyright © 1999-2003, ObjectWeb Consortium