Consortium    Solutions    Middleware    Forge    MyObjectWeb 
ObjectWeb Consortium
Print

Advanced - Powered by Google






OpenCCM

Project Links
· Home
· Download
· Documentation
· Mailing Lists
· Wiki
· Partners
· License
· History
· Related projects

Developers' Corner
· How to Contribute
· Workplan
· Resources
· CVS Repository
· Bug Tracking
· ObjectWeb Forge Site
· User Mailing List
· Team Mailing List

About
· Team
· Contacts

Table of Contents

  1. Environment for using OpenCCM
    1. Loading the OpenCCM environment
    2. The OpenCCM's Configuration Repository
  2. The OpenCCM's Compilation Chain
    1. ir3_start
    2. ir3_started
    3. ir3_stop
    4. ir3_check
    5. ir3_feed
    6. ir3_idl3
    7. ir3_idl2
    8. ir3_java
    9. ir3_jimpl
    10. ir3_xmi
  3. Generation and implementation rules
    1. Generated files
    2. Skeleton Mappings
    3. What should be implemented
  4. The OpenCCM's Execution Chain
    1. ccm_install
    2. ccm_installed
    3. ccm_deinstall
    4. ns_start
    5. ns_ior
    6. ns_gui
    7. ns_stop
    8. ots_start
    9. ots_ior
    10. ots_stop
    11. jcs_start
    12. jcs_start_ots
    13. jcs_stop
    14. ccm_deploy
  5. Writing the XML meta files
  6. Demonstrations

Environment for using OpenCCM

Loading the OpenCCM environment

To have access to all the OpenCCM's tools, it is required to source the OpenCCM environment file according to the shell used.

  • For Unix shells like sh or bash, do:
    $ . /A_PATH/bin/envi.OpenCCM.sh
  • For Unix C-shells like csh or tcsh, do:
    $ source /A_PATH/bin/envi.OpenCCM.csh
  • For Windows shells, do:
    $ call \A_PATH\bin\envi_OpenCCM.bat

Where, A_PATH refers to the path where OpenCCM is compiled or installed.

These environment files add the path of the OpenCCM's tools in the PATH shell variable and define the following shell variables required by OpenCCM:

  • OpenCCM_HOMEDIR: The directory where OpenCCM is compiled or installed.
  • OpenCCM_CONFIG_DIR: The directory where the OpenCCM Configuration Repository will be stored.

The OpenCCM's Configuration Repository

During OpenCCM uses, the OpenCCM's Configuration Repository will contain IORs (Interoperable Object Reference), PIDs (Process IDentifier), and output of the started OpenCCM tool processes.

By default, it is the $HOME/OpenCCM_CONFIG_DIR directory. Then each user has its own OpenCCM's Configuration Repository as long as he/she does not change the default value of the OpenCCM_CONFIG_DIR variable. Thus, several users can run its own OpenCCM platform on a same host.

Moreover, if the $HOME directory can be accessed by a set of networked hosts (e.g. sharing done through NFS), then a user has one OpenCCM's Configuration Repository shared across all these hosts.

If several users set their OpenCCM_CONFIG_DIR to the same directory, then they share the same OpenCCM's Configuration Repository.

Finally, if a user starts several shells and sets in each shell the OpenCCM_CONFIG_DIR variable to different directories, then he/she can run several distinct OpenCCM platforms.

The OpenCCM's Compilation Chain

The OpenCCM's Compilation Chain is composed of the following tools:

ToolDescription
ir3_startStarts the OpenCCM's OMG IDL3 Repository (named IR3).
ir3_startedChecks if the OpenCCM's IR3 is started.
ir3_stopStops the OpenCCM's IR3.
idl3_checkChecks if the specified OMG IDL 3.0 file is correct.
ir3_feedFeeds the specified OMG IDL 3.0 file into the OpenCCM's IR3.
ir3_idl3Generates an OMG IDL 3.0 file associated to an IR3 object and its childs.
ir3_idl2Generates an OMG IDL 2.4 file associated to an IR3 object and its childs.
ir3_javaGenerates all Java OpenCCM skeletons associated to an IR3 object and its childs.
ir3_jimplGenerates all Java implementation templates associated to an IR3 object and its childs.
ir3_xmiGenerates a XMI 1.1 UML document associated to an IR3 object and its childs.

Starting the OpenCCM's OMG IDL3 Repository

The OpenCCM's Compilation Chain is mainly based on the use of an OMG IDL 3.0 Repository.

Note that before using any OpenCCM's Compilation Chain tool, it is required to start the OpenCCM's OMG IDL3 Repository (named IR3).

The ir3_start script starts the OpenCCM's IR3, e.g.:

$ ir3_start
The OpenCCM's OMG IDL3 Repository will be started.
Creating the $OpenCCM_CONFIG_DIR directory.
Launching the OpenCCM's IR3.
Feeding the OpenCCM's IR3 with the IFR_3_0.idl file.
. . .
Feeding the OpenCCM's IR3 with the Components.idl file.
. . .
The OpenCCM's OMG IDL3 Repository is started.
$

Note that this script automatically creates the $OpenCCM_CONFIG_DIR directory if it does not exist, launches the OpenCCM's IR3 process, and feeds it with the IFR_3_0.idl and Components.idl files.

Moreover, the IOR, PID, and standard output of the started OpenCCM's IR3 are stored into the OpenCCM's Configuration Repository, e.g.:

$ ls $OpenCCM_CONFIG_DIR
IR3.IOR IR3.PID IR3.output
$

Warning: Only one OpenCCM's IR3 can be started for an OpenCCM's Configuration Repository, e.g.:

$ ir3_start
Error: The OpenCCM's OMG IDL3 Repository is already started!
$

See the ir3_stop script to stop the started OpenCCM's IR3.

Checking if the OpenCCM's OMG IDL3 Repository is started

The ir3_started script checks if the OpenCCM's IR3 is started, e.g.:

$ ir3_stop
. . .
$ ir3_started
Error: The OpenCCM's OMG IDL3 Repository is not started!
$

Note that this OpenCCM script is mainly used by other OpenCCM scripts to check if the OpenCCM's IR3 is started or not.

Stopping the OpenCCM's OMG IDL3 Repository

The ir3_stop script stops the previously started OpenCCM's IR3, e.g.:

$ ir3_start
. . .
$ ir3_stop
The OpenCCM's OMG IDL3 Repository will be stopped.
Removing the $OpenCCM_CONFIG_DIR directory.
The OpenCCM's OMG IDL3 Repository is stopped.
$

Note that this script shutdowns the OpenCCM's IR3 process, removes its associated IOR, PID, and standard output files, and removes the $OpenCCM_CONFIG_DIR directory.

Checking an OMG IDL 3.0 file

The idl3_check script checks if the specified OMG IDL 3.0 file is correct, e.g.:

$ cat test/sample.idl3
// This file is the example used in the OpenCCM User'Guide.
#pragma prefix "ccm.objectweb.org"
module sample
{
  component MyComponent {};
  home MyHome manages MyComponent {};
};
$
$ idl3_check test/sample.idl3
OpenCCM's OMG IDL 3.0 Compiler 0.5: Reading from file test/sample.idl3...
OpenCCM's OMG IDL 3.0 Compiler 0.5: Preprocessing file test/sample.idl3...
OpenCCM's OMG IDL 3.0 Compiler 0.5: File test/sample.idl3 preprocessed
OpenCCM's OMG IDL 3.0 Compiler 0.5: Feeding the Interface Repository ...
OpenCCM's OMG IDL 3.0 Compiler 0.5: Compilation completed : 0 warnings.
$

This script starts a C/C++ preprocessor on the specified file, compiles and checks the preprocessed result file.

Note that the standard -D, -U and -I options for the C/C++ preprocessor could be passed as arguments to idl3_check before the file name, e.g.:

$ idl3_check -DFOO -Itest test/sample.idl3
. . .
$

Feeding an OMG IDL 3.0 file into the OpenCCM's IR3

Warning: To use any of the generation OpenCCM tools, it is required to feed the OpenCCM's IR3 with OMG IDL 3.0 files.

The ir3_feed script allows one to compile a specified OMG IDL 3.0 file and to feed the OpenCCM's IR3, e.g.:

$ ir3_feed test/sample.idl3
OpenCCM's OMG IDL 3.0 Compiler 0.5: Reading from file test/sample.idl3...
OpenCCM's OMG IDL 3.0 Compiler 0.5: Preprocessing file test/sample.idl3...
OpenCCM's OMG IDL 3.0 Compiler 0.5: File test/sample.idl3 preprocessed
OpenCCM's OMG IDL 3.0 Compiler 0.5: Feeding the Interface Repository ...
OpenCCM's OMG IDL 3.0 Compiler 0.5: Compilation completed : 0 warnings.
$

This script starts a C/C++ preprocessor on the specified file, compiles the preprocessed result file, and feeds the OpenCCM's IR3.

Note that the standard -D, -U and -I options for the C/C++ preprocessor could be passed as arguments to ir3_feed before the file name, e.g.:

$ ir3_feed -DFOO -Itests test/sample.idl3
. . .
$

Warning, OMG IDL files must be fed into the OpenCCM's OMG IDL3 Repository only once!!!

Generating an OMG IDL 3.0 file associated to an IR3 object

The ir3_idl3 script allows one to generate the OMG IDL 3.0 definition associated to an OpenCCM's IR3 object and its child objects, e.g.:

$ ir3_idl3 sample
. . .
#pragma prefix "ccm.objectweb.org"
module sample
{
  component MyComponent;
  component MyComponent
  {
  };
  home MyHome
  manages ::sample::MyComponent
  {
  };
};
$

By default, the ir3_idl3 script generates the OMG IDL 3.0 definition to the standard output.

However, this script can produce the output into a file specified by the -o filename option, e.g.:

$ ir3_idl3 -o tmp.idl3 sample
$ cat tmp.idl3
. . .
$

Using the -i flag produces an import statement into the begin of the output, e.g.:

$ ir3_idl3 -i Components sample
. . .
import Components;
. . .
$

Generating equivalent OMG IDL 2.4 mapping for an IR3 object

The ir3_idl2 script allows one to generate the OMG IDL 2.4 CCM's mapping associated to an OpenCCM's IR3 object and its child objects, e.g.:

$ ir3_idl2 sample
. . .
#pragma prefix "ccm.objectweb.org"
module sample
{
    interface MyComponent;
    local interface CCM_MyComponent_Executor;
    local interface CCM_MyComponent;
    local interface CCM_MyComponent_Context;
    interface MyHomeExplicit;
    interface MyHomeImplicit;
    interface MyHome;
    local interface CCM_MyHomeExplicit;
    local interface CCM_MyHomeImplicit;
    local interface CCM_MyHome;
    interface MyComponent : ::Components::CCMObject
    {
    };
    local interface CCM_MyComponent_Executor : ::Components::EnterpriseComponent
    {
    };
    local interface CCM_MyComponent : ::sample::CCM_MyComponent_Executor
    {
    };
    local interface CCM_MyComponent_Context : ::Components::CCMContext
    {
    };
    interface MyHomeExplicit : ::Components::CCMHome
    {
    };
    interface MyHomeImplicit : ::Components::KeylessCCMHome
    {
        ::sample::MyComponent create()
            raises(::Components::CreateFailure);
    };
    interface MyHome : ::sample::MyHomeExplicit, ::sample::MyHomeImplicit
    {
    };
    local interface CCM_MyHomeExplicit : ::Components::HomeExecutorBase
    {
    };
    local interface CCM_MyHomeImplicit
    {
        ::Components::EnterpriseComponent create()
            raises(::Components::CCMException);
    };
    local interface CCM_MyHome : ::sample::CCM_MyHomeExplicit, ::sample::CCM_MyHomeImplicit
    {
    };
};
$

By default, the ir3_idl2 script generates the OMG IDL 2.4 CCM's mapping to the standard output.

However, this script can produce the output into a file specified by the -o filename option, e.g.:

$ ir3_idl2 -o tmp.idl sample
$ cat tmp.idl
. . .
$

Using the -i flag produces a #include statement into the begin of the output, e.g.:

$ ir3_idl2 -i tmp.idl sample
. . .
#include "tmp.idl"
. . .
$

See the CORBA Component Model specification for more information about the OMG IDL 2.4 mapping.

Generating the Java OpenCCM skeletons associated to an IR3 object

The ir3_java script allows one to generate the Java OpenCCM skeletons associated to an OpenCCM's IR3 object and its child objects, e.g.:

$ ir3_java ::sample
. . .
$ ls org/objectweb/ccm/sample
MyComponentCCM.java                 MyHomeCCM.java
MyComponentMonolithicWrapper.java   MyHomeSkeletonInterceptor.java
MyComponentSkeletonInterceptor.java MyHomeStubInterceptor.java
$

See Generation Rules for more information.

Generating all the Java implementation templates associated to an IR3 object

The ir3_jimpl script allows one to generate the Java implementation templates associated to an OpenCCM's IR3 object and its child objects, e.g.:

$ ir3_jimpl ::sample
. . .
$ ls org/objectweb/ccm/sample
MyComponentMonolithicImpl.java MyHomeImpl.java
$

These generated files could be used as starting point to implement components and homes, i.e. writting their functional part.

See Generation and Implementation Rules for more information.

Generating a XMI 1.1 UML document for an IR3 object

This OpenCCM's script generates valid XMI 1.1 documents against the OMG XMI 1.1 UML DTD (see OMG TC Document ad/99-10-05.txt) available for download at the XMI 1.1 Specification section at the OMG website. This script conforms with the OMG UML Profile for CORBA Specification (see OMG TC Document formal/02-04-01) even when dealing with CORBA Components declarations. This may change in a future release when the UML Profile for CORBA Components Specification will be published.

The ir3_xmi script allows one to generate the OMG XMI 1.1 UML document associated to an OpenCCM's IR3 object and its child objects, e.g.:

$ ir3_xmi sample
<?xml version="1.0" encoding="UTF-8"?>
. . .
<!DOCTYPE XMI SYSTEM "xmi.dtd">
<XMI xmi.version="1.1" xmlns:UML="org.omg/UML1.3">
    <XMI.header>
        <XMI.documentation>
            <XMI.exporter>OpenCCM XMI generator</XMI.exporter>
        </XMI.documentation>
    </XMI.header>
    <XMI.content>
    . . .
    </XMI.content>
</XMI>
$

By default, the ir3_xmi script generates the OMG XMI 1.1 UML document to the standard output.

However, this script can produce the output into a file specified by the -o filename option, e.g.:

$ ir3_xmi -o tmp.xml sample
$ cat tmp.xml
<?xml version="1.0" encoding="UTF-8"?>
. . .
<!DOCTYPE XMI SYSTEM "xmi.dtd">
<XMI xmi.version="1.1" xmlns:UML="org.omg/UML1.3">
    <XMI.header>
        <XMI.documentation>
            <XMI.exporter>OpenCCM XMI generator</XMI.exporter>
        </XMI.documentation>
    </XMI.header>
    <XMI.content>
    . . .
    </XMI.content>
</XMI>
$

The generated XMI UML document will always declare the XMI UML DTD it refers to. If none has been specified from the command line, the XMI document will assume that the XMI DTD is stored in the same directory as itself and named xmi.dtd.

Using the -dtd xmi_dtd option allows one to set the full path location of the XMI UML DTD file, e.g.:

$ ir3_xmi -dtd UML.dtd sample
<?xml version="1.0" encoding="UTF-8"?>
. . .
<!DOCTYPE XMI SYSTEM "UML.dtd">
. . .
$

Setting the correct location of the XMI UML DTD is only required when the user wants to validate generated XMI UML documents.

Currently, the XMI 1.1 UML DTD is located in the src/dtd/xmi/XMI_1_1_UML.dtd file.

Generation and implementation rules

Here are described the most important generation and implementation rules for the OpenCCM platform.

Have a look into the generated OpenCCM files or into the CORBA Component Model Specification for more details.

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 home MyHome 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 doesn't 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_EventTypeConsumer 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.

The OpenCCM's Execution Chain

The OpenCCM's Execution Chain is composed of the following tools:

ToolDescription
ccm_install Installs the OpenCCM's Configuration Repository.
ccm_installed Checks if the OpenCCM's Configuration Repository is installed.
ccm_deinstall Deinstalls the OpenCCM's Configuration Repository.
ns_start Starts the Name Service used by the OpenCCM's Execution Chain.
ns_ior Obtains the IOR of the running Name Service.
ns_gui Starts a client GUI on the running Name Service.
ns_stop Stops the Name Service used by the OpenCCM's Execution Chain.
ots_start Starts the Transaction Service used by the OpenCCM's Execution Chain.
ots_ior Obtains the IOR of the running Transaction Service.
ots_stop Stops the Transaction Service used by the OpenCCM's Execution Chain.
jcs_start Starts an OpenCCM's Java Component Server.
jcs_start_ots Starts a Transactional OpenCCM's Java Component Server.
jcs_stop Stops an OpenCCM's Java Component Server.
ccm_deploy Initiates an OpenCCM XML based deployment.

Installing the OpenCCM's Configuration Repository

The OpenCCM's Execution Chain is mainly based on the use of the OpenCCM's Configuration Repository.

Note that before using any OpenCCM's Execution Chain tool, it is required to install the OpenCCM's Configuration Repository.

The ccm_install script installs the OpenCCM's Configuration Repository, e.g.:

$ ccm_install
The OpenCCM Platform will be installed.
Creating the $OpenCCM_CONFIG_DIR directory.
Creating the $OpenCCM_CONFIG_DIR/ComponentServers directory.
The OpenCCM Platform is installed.
$

Note that this script automatically creates the $OpenCCM_CONFIG_DIR and $OpenCCM_CONFIG_DIR/ComponentServers directories. This latter is used to store the standard output and the PID of all started OpenCCM's Component Servers.

Warning: This script can be started only once, e.g.:

$ ccm_install
Error: The OpenCCM Platform is already installed!
$

See the ccm_deinstall script to deinstall the OpenCCM's Configuration Repository.

Checking if the OpenCCM's Configuration Repository is installed

The ccm_installed script checks if the OpenCCM's Configuration Repository is installed, e.g.:

$ ccm_deinstall
. . .
$ ccm_installed
Error: The OpenCCM Platform is not installed!
$

Note that this OpenCCM script is mainly used by other OpenCCM scripts to check if the OpenCCM's Configuration Repository is installed or not.

Deinstalling the OpenCCM's Configuration Repository

The ccm_deinstall script deinstalls the previously installed OpenCCM's Configuration Repository, e.g.:

$ ccm_install
. . .
$ ccm_deinstall
The OpenCCM Platform will be deinstalled.
Removing the $OpenCCM_CONFIG_DIR directory.
The OpenCCM Platform is deinstalled.
$

Note that this script stops current started OpenCCM's processes and removes the $OpenCCM_CONFIG_DIR directory.

Starting the Name Service used by the OpenCCM's Execution Chain

The ns_start script starts the Name Service used by the OpenCCM's Execution Chain, e.g.:

$ ns_start
The Name Service will be started.
Launching the Name Service.
The Name Service is started.
$

Note that this script automatically launches a Name Service process and stores its IOR and PID into the OpenCCM's Configuration Repository, e.g.:

$ ls $OpenCCM_CONFIG_DIR
ComponentServers/ NameService.IOR NameService.PID
$

Warning: Only one Name Service can be started for an OpenCCM's Configuration Repository, e.g.:

$ ns_start
Error: The Name Service is already started!
$

See the ns_stop script to stop the started Name Service.

Obtaining the IOR of the running Name Service

The ns_ior displays the IOR of the running Name Service, e.g.:

$ ns_ior
file:$OpenCCM_CONFIG_DIR/NameService.IOR
$

Starting a client GUI on the running Name Service

The ns_gui starts a client GUI on the running Name Service, e.g.:

$ ns_gui
An ORBacus Name Service's GUI will be started.

Warning, currently this script is only provided for the ORBacus product!

Stopping the Name Service used by the OpenCCM's Execution Chain

The ns_stop script stops the previously started Name Service, e.g.:

$ ns_stop
The Name Service will be stopped.
The Name Service is stopped.
$

Note that this script shutdowns the Name Service process and removes its associated IOR and PID files from the OpenCCM's Configuration Repository.

Starting the Transaction Service used by the OpenCCM's Execution Chain

The ots_start script starts the Transaction Service used by the OpenCCM's Execution Chain, e.g.:

$ ots_start
The Transaction Service will be started.
Launching the Transaction Service.
The Transaction Service is started.
$

Note that this script automatically launches a Transaction Service process and stores its IOR and PID into the OpenCCM's Configuration Repository, e.g.:

$ ls $OpenCCM_CONFIG_DIR
ComponentServers/ TransactionService.IOR TransactionService.PID
$

Warning: Only one Transaction Service can be started for an OpenCCM's Configuration Repository, e.g.:

$ ots_start
Error: The Transaction Service is already started!
$

See the ots_stop script to stop the started Transaction Service.

Obtaining the IOR of the running Transaction Service

The ots_ior displays the IOR of the running Transaction Service, e.g.:

$ ots_ior
file:$OpenCCM_CONFIG_DIR/TransactionService.IOR
$

Stopping the Transaction Service used by the OpenCCM's Execution Chain

The ots_stop script stops the previously started Transaction Service, e.g.:

$ ots_stop
The Transaction Service will be stopped.
The Transaction Service is stopped.
$

Note that this script shutdowns the Transaction Service process and removes its associated IOR and PID files from the OpenCCM's Configuration Repository.

Starting an OpenCCM's Java Component Server

The jcs_start script starts an OpenCCM's Java Component Server, e.g.:

$ jcs_start MyServerName
The OpenCCM's Java Component Server MyServerName will be started.
Creating the $OpenCCM_CONFIG_DIR/ComponentServers/MyServerName.archive_cache directory.
Launching an OpenCCM's Java Component Server.
The OpenCCM's Java Component Server MyServerName is started.
$

Note that the Name Service must be started before. Then, this script automatically creates a directory to store downloaded archives, launches an OpenCCM's Java Component Server process and stores its standard output, IOR and PID into the OpenCCM's Configuration Repository, e.g.:

$ ls $OpenCCM_CONFIG_DIR/ComponentServers
MyServerName.IOR MyServerName.PID MyServerName.archive_cache/ MyServerName.output
$

Warning: Each started OpenCCM's Java Component Server must have a distinct name, e.g.:

jcs_start MyServerName
Error: The Component Server MyServerName is already started!
$

See the jcs_stop script to stop a started OpenCCM's Java Component Server.

Starting a Transactional OpenCCM's Java Component Server

The jcs_start_ots script starts a Transactional OpenCCM's Java Component Server, e.g.:

$ jcs_start_ots MyServerName
The Transactional OpenCCM's Java Component Server MyServerName will be started.
Creating the $OpenCCM_CONFIG_DIR/ComponentServers/MyServerName.archive_cache directory.
Launching a Transactional OpenCCM's Java Component Server.
The Transactional OpenCCM's Java Component Server MyServerName is started.
$

Note that, as with jcs_start, the Name Service must be started before, and the Transaction Service also.

See the jcs_stop script to stop a started OpenCCM's Java Component Server.

Stopping an OpenCCM's Java Component Server

The jcs_stop script stops a previously started OpenCCM's Java Component Server, e.g.:

$ jcs_stop AnotherServer
Error: The Java Component Server AnotherServer is not started!
$
jcs_stop MyServerName
The Java Component Server MyServerName will be stopped.
The Java Component Server MyServerName is stopped.
$

Note that this script shutdowns the specified OpenCCM's Java Component Server process and removes its associated files from the OpenCCM's Configuration Repository.

Initiating an XML deployment process

The ccm_deploy script launches the deployment of homes, instantiates components, connects them to each other, and runs the application automatically, reading its input from XML descriptors. Here is for example, the deployment of demo1, run from the demo1 directory:

$ ccm_deploy ./META-INF/demo1.cad
Installing archive archives/demo1.jar...
Instantiating homes...
Installing archive archives/demo1.jar...
Instantiating homes...
switching the components to "conf_complete"
$

Refer to the Writing the XML meta files section for more information about the XML files you can use.

Writing the XML meta files

Conforming to the CCM specification, you should have to provide three kinds of meta files, since the Corba Component Descriptor will be generated from CIDL.

  • The Component Assembly Descriptor: <assembly>.cad

    This is the main descriptor you must take care about when setting up a distributed application. It allows you to point out which packages will be involved, which Component Servers will be the targets for the homes, and which connections to do at deployment time.

    The actual version of OpenCCM's deployment tool supports hostcollocation and processcollocation. That means you can describe your partitioning with these features, using homeplacement.

    The destination tag is simply used to mention the Component Server registered with the Naming Service.

    For each homeplacement, you select packages using a componentfileref refering to pre-defined packages. This is done in the componentfiles part of the file, using componentfile tags that will point to CSD files.

    Another important part is the connections one. For each connectinterface or connectevent you have to operate, you must simply fill the tags with references to components (with componentinstantiationref pointing the IDs defined in partitioning), and identifiers to specific connectors: usesidentifier, providesidentifier, consumesidentifier, publishesidentifier.

  • The Software Package Descriptor: <package>.csd

    This descriptor provides every information concerning a particular package: IDL reference, various implementations for specific languages, OS, compilers...

    Again, the OpenCCM's deployment tool does not need/support each of the tags from the CCM specification. Meta informations such as title, license, author,... are not used by the deployment tool, but should be filled in order to share components.

    At current stage, the tool supports ONE implementation tag; that means you should need more than one CSD file in case of testing various OS, for example.

    The important tags are the fileinarchive and entrypoint contained in code. They refer to the JAR file containing your business code, and to the create_home method of the implementation.

  • The Property File Descriptor: <file>.cpf

    Setting properties on components is done using this meta descriptor. In CCM specification, you should be able to refer a properties file anywhere in the Assembly Descriptor, at home level or component level, or in the Software Package Descriptor, at package level or implementation level.

    The OpenCCM's deployment tool remains quite limited on properties. First, it only looks for a propertyfile reference into the Component Assembly Descriptor, at component level. Second, it only accepts simple tags. describing string values.

Demonstrations

The following demonstrations are available:

DemoDescription
demo/helloThis illustrates the classical Hello World application showing how component-unaware clients could create a server component and use a facet provided by this one.
demo/demo1This illustrates a simple clients / server application showing how client components could be connected by a receptacle to a facet provided by a server component.
demo/demo2This illustrates a simple producer / consumers application showing how a producer component could push events by an event source to a set of event consumer sinks.
demo/demo3This illustrates a simple clients / server-producer / consumers application showing how a component can simultaneously be a server providing a facet and a producer with an event source.
demo/dinnerThis illustrates the philosopher's dinner with Philosopher, Fork and Observer components. Philosophers try to acquire both forks to eat and publish events with their state to observer components. This demo was used at 2002 Yokohama (Japan) and Orlando (USA) OMG Meetings to show interoperability between CCM implementations.

To compile a demonstration, do the next steps:

  1. Go to the associated directory.
  2. Execute the following command on Unix systems:

    $ build.sh

    or on Windows systems:

    $ build.bat

To start the demonstration, execute one of the following scripts:

  • bin/start_java: The demonstration deployment is done by a Java program.
  • bin/start_java_ots: The demonstration deployment is done by a Java program and uses a transactional service.
  • bin/start_java_xml: The demonstration deployment is done by a Java program and uses the files from the META-INF/ directory.
  • bin/start_jish: The demonstration deployment is done by a Java IDLScript engine.
  • bin/start_cssh: The demonstration deployment is done by a CorbaScript engine.

Note that for the hello demonstration, you have also to do:

  1. bin/install_java or

    bin/install_cssh or

    bin/install_jish

  2. bin/run_java or

    bin/run_cssh or

    bin/run_jish

Then, have fun with the demonstration...

To stop the demonstration, execute respectively:

  • bin/stop_java,
  • bin/stop_java_ots,
  • bin/stop_jish, or
  • bin/stop_cssh.

Note that to execute the demonstrations from Java IDLscript or CorbaScript, it is required that these scripting engines are accessible through the PATH environment variable.


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