OpenCCM - Generation and Implementation Rules

Table of Contents

This document describes the most important generation and implementation rules for the OpenCCM platform.

  1. Generated files
  2. Skeleton mappings
  3. What should be implemented

For more details, have a look into the CORBA Component Model Specification or into the generated OpenCCM files.

Generated files

If no prefix is specified into OMG IDL 3.0 files, then the enclosing module name is taken as target directory name for file generation. Otherwise, the prefix is taken as target.

For example, if there is no prefix and the module name is MyModule, then the target directory will be ./MyModule/. If the prefix is "objectweb.org", then the target directory will be ./org/objectweb/.

  1. Java skeleton files

    • For a MyComponent component definition, the generated Java skeleton file is MyComponentCCM.java.
    • For a MyHome home definition, the generated Java skeleton file is MyHomeCCM.java.
    • For an event type definition, no skeleton file is generated.
    • For a valuetype MyPrimaryKey inheriting from Components::PrimaryKeyBase (i.e. a primary key type), no skeleton files are generated.

  2. Helper files

    • For a component definition, no helpers are generated.
    • For a home definition, no helpers are generated.
    • For a MyEventType event type definition, an helper file named MyEventTypeFactoryHelper is generated. This file provides facilities to register a factory for the equivalent OMG IDL 2.4 value type, to narrowcast a base event type into this type and to create an any from an event of this type.
    • For a valuetype MyPrimaryKey inheriting from Components::PrimaryKeyBase (i.e. a primary key type), a file called MyPrimaryKeyFactoryHelper is generated. This class provides same facilities as described above for event type helper files generation.

  3. Internally used files

    • For a MyComponent component definition, two interceptor files are generated: MyComponentSkeletonInterceptor and MyComponentStubInterceptor. Moreover, a MyComponentMonolithicWrapper is generated such as the framework accesses monolithic or segmented component implementations in the same way.
    • For a MyHome home definition, two interceptor files are generated: MyHomeSkeletonInterceptor and MyHomeStubInterceptor.
    • For an event type definition, no files are generated.
    • For a valuetype inheriting from Components::PrimaryKeyBase (i.e. a primary key type), no files are generated.

Skeleton mappings

  • Mappings for components:

    1. General mappings: The implementations of all operations inherited from the Components::CCMObject, Components::Navigation, Components::Receptacles, and Components::Events interfaces are automatically generated.
    2. Specific mappings: The implementations of all operations inherited from the generated OMG IDL 2.4 equivalent interface (i.e. the management for provides, uses, consumes, emits, and publishes port declarations) are automatically generated.
    3. Executor mappings: The implementation of the component's initialization is automatically generated.

  • Mappings for homes:

    1. General mappings: The implementations of all operations inherited from the Components::CCMHome interface are automatically generated.
    2. Specific mappings: The implementations of all operations inherited from the generated Implicit OMG IDL 2.4 interface are automatically generated.
    3. Executor mappings: The implementation of the home's initialization is automatically generated.

What should be implemented

  1. General

    In the next parts, focus is set on the implicit dependencies between OpenCCM runtime framework and implementation classes.

    For explicit dependencies, have a look at the generated OMG IDL 2.4 equivalent interfaces. For example, you have to implement the mutator and accessor methods of a declared attribute. Also, if a component supports an interface, then the attributes and operations of this supported interface must be implemented. In fact, all the functional parts of components and homes must be implemented, the non-functional parts are implemented by the skeletons.

    See the demonstration source files for more details.

  2. Components

    Actually OpenCCM does not provide a complete Component Implementation Framework (CIF). However, components implementors can choose between a monolithic and a segmented implementation strategy as specified in the CCM specification.

    • Monolithic strategy

      In a monolithic strategy, all features of the component must be provided by the same class. In order to do this, the following rules must be followed:

      • For a MyComponent component declaration and a MyComponentImpl implementation, MyComponentImpl class must extend org.omg.CORBA.LocalObject and implement the CCM_MyComponent local interface,
      • If a MyComponent component declaration provides a facet of type InterfaceType, the MyComponentImpl implementation class has to implement the CCM_InterfaceType local interface.

    • Segmented strategy

      In a segmented strategy, features implementations can be delegated to specific classes. In order to do this, the following rules must be followed:

      • For a MyComponent component declaration and a MyComponentImpl main executor implementation, MyComponentImpl class must extend org.omg.CORBA.LocalObject and implement the CCM_MyComponent_Executor and org.omg.Components.ExecutorLocator local interfaces,
      • If a MyComponent component declaration provides a facet of type InterfaceType, this facet can be implemented in a specific class and must extend the org.omg.CORBA.LocalObject interface and implement the CCM_InterfaceType local interface.
      • If a MyComponent component declaration consumes an event of type MyEventType, the event consumer can be implemented in a specific class and must extend the org.omg.CORBA.LocalObject interface and implement the CCM_MyEventTypeConsumer local interface.

    In both cases, some specific OpenCCM dependencies have to be respected. The main executor class has to implement the following method:

    • A configuration_complete method which is added to org.omg.Components.EnterpriseComponent:

      public void
      configuration_complete()
      throws org.omg.Components.InvalidConfiguration;

      This method is called by the container when component configuration is done after deployment. This specific OpenCCM dependency was introduced because the CCM specification does not provide a standard way.

    • OpenCCM allows you to implement the Component::SessionComponent local interface in your main executor implementation. But warning, only set_session_context and ccm_remove methods of this interface are called from the OpenCCM container, so ccm_activate and ccm_passivate are never called by the container. This issue should be resolved in next releases.

  3. Homes

    OpenCCM has no specific requirement for homes. Implementing a home executor is done in the same way as in the CCM specification.

    If a home has the following form:

    home MyHome ... // possible inheritance
    manages MyComponent
    ... // possible primary key
    {...};

    Then, the home executor class must have this form:

    public class MyHomeImpl
         extends org.omg.CORBA.LocalObject
      implements CCM_MyHome
    {
    ...
    }

    and the following method must be implemented by the home executor class:

    public org.omg.Components.EnterpriseComponent
    create();

    This method must return a new instance of the managed component executor.

    Futhermore, at least one method of this form must be implemented to be used by component servers to instantiate the home implementation:

    static public org.omg.Components.HomeExecutorBase
    XXX();

    Where XXX is a name of your choice. This method must be provided by the home implementation class and must return a new instance of the home executor.

  4. Events

    Implementing event types in OpenCCM is simply done by implementing the associated generated value type and its factory.

    Note that you also have to register the event type factory to the ORB. It's recommended to make this registration in each home which manages a component that consumes this event type. This registration can be done only once using a Java static block in the home executor class and using the associated factory helper generated by OpenCCM Java skeletons generator. This solution is temporary and will be replaced by a specific flag in the CCM deployment files. For more details, please have a look in the OpenCCM demonstrations.

  5. Primary keys

    Implementing primary keys in OpenCCM is simply done by implementing the associated generated value type and its factory.

    Note that you also have to register the primary key factory to the ORB. It's recommended to make this registration in each home which manages components using this primary key type. This registration can be done only once using a Java static block in the home executor class and using the associated factory helper generated by OpenCCM Java skeletons generator. This solution is temporary and will be replaced by a specific flag in the CCM deployment files. For more details, please have a look in the OpenCCM demonstrations.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster | Last modified at 2005-07-07 02:04 PM