OpenCCM Module User Guide
See also these documentations which cover more global concerns :
The OpenCCM Production Tool Chain
The OpenCCM Production Tool Chain is a set of tools for compiling CORBA Components specifications (i.e. OMG IDL 3.0, OMG PSDL, OMG CIDL, and XMI 1.1 UML 1.4 Profile for CORBA Components files) and for generating CORBA Components implementation artefacts (i.e. OMG IDL 2.x interfaces and local interfaces, container code, XML CCM descriptors).
The OpenCCM Production Tool Chain is composed of the following tools:
| Tool | Description |
|---|---|
ir3_start | Starts the OpenCCM Interface Repository. |
ir3_started | Checks if the OpenCCM Interface Repository is started. |
ir3_stop | Stops the OpenCCM Interface Repository. |
idl3_check | Checks OMG IDL 3.0 files. |
ir3_feed | Feeds OMG IDL 3.0 files into the OpenCCM Interface Repository. |
xmi2ir | Feeds XMI 1.1 UML 1.4 documents into the OpenCCM Interface Repository. |
ir3_destroy | Destroys OpenCCM Interface Repository objects. |
ir3_idl3 | Generates OMG IDL 3.0 files from the OpenCCM Interface Repository. |
ir3_xmi | Generates XMI 1.1 UML documents from the OpenCCM Interface Repository. |
ir3_idl2 | Generates equivalent OMG IDL 2.4 files from the OpenCCM Interface Repository. |
ir3_java | Generates Java container code from the OpenCCM Interface Repository. |
ir3_jimpl | Generates Java component business implementation skeletons from the OpenCCM Interface Repository. |
cidl_cif | Compiles OMG CIDL files and generates associated OMG IDL and Java component executor skeleton files. |
cidl | Compiles specifications and regenerates the OMG CIDL part only. |
cif_jimpl | Generates Java business component implementation skeletons from OMG CIDL. |
psdl_java | Compiles OMG PSDL files and generates associated Java mapping implementations. |
psdl | Compiles specifications and regenerates the OMG PSDL part only. |
In the following sections, all OpenCCM Production Tool Chain scripts are illustrated on top of the ORBacus 4.1.0 product running on a Linux system.
However all these following scripts could be used in the same way on any ORB products and operating systems supported by OpenCCM.
Generating XMI 1.1 UML documents from the OpenCCM Interface Repository
The ir3_xmi script generates valid XMI 1.1 documents
conform to 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 you to generate the OMG XMI 1.1 UML
document associated to an OpenCCM Interface Repository
object and its children 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 OMG XMI 1.1 UML document will always declare the XMI 1.1 UML DTD it refers to.
If none has been specified from the command line, the XMI 1.1 document
will assume that the XMI 1.1 DTD is stored in the same directory as itself
and named xmi.dtd.
Using the -dtd xmi_dtd option allows you 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 1.1 UML DTD is only required when the user wants to validate generated XMI 1.1 UML documents.
Currently, the XMI 1.1 UML DTD is located in the
src/dtd/xmi/XMI_1_1_UML.dtd file.
Generating Java container code from the OpenCCM Interface Repository
The ir3_java script allows you to generate the Java container code
associated to an OpenCCM Interface Repository
object and its children objects, e.g.:
$ ir3_java ::sample File '.../MyComponentCCM.java' has been generated File '.../MyComponentSkeletonInterceptor.java' has been generated File '.../MyComponentStubInterceptor.java' has been generated File '.../MyComponentMonolithicWrapper.java' has been generated File '.../MyHomeCCM.java' has been generated File '.../MyHomeSkeletonInterceptor.java' has been generated File '.../MyHomeStubInterceptor.java' has been generated idl_to_mi 0.9: Generating MetaInformation implementations for sample... File '.../MyHome_homeMI.java' has been generated File '.../MyHome_interfaceMI.java' has been generated File '.../MyComponent_componentMI.java' has been generated idl_to_mi 0.9: MetaInformation for sample generated. $
The Java container code is generated in a directory associated to the generated Java package, e.g.:
$ ls org/objectweb/ccm/sample MyComponentCCM.java MyHomeCCM.java MyComponent_componentMI.java MyHome_homeMI.java MyComponentMonolithicWrapper.java MyHome_interfaceMI.java MyComponentSkeletonInterceptor.java MyHomeSkeletonInterceptor.java MyComponentStubInterceptor.java MyHomeStubInterceptor.java $
See Generation and implementation rules for more information.
Generating Java component business implementation skeletons from the OpenCCM Interface Repository
The ir3_jimpl script allows you to generate
Java component business implementation skeletons
associated to an OpenCCM Interface Repository
object and its children objects, e.g.:
$ ir3_jimpl ::sample File 'org/objectweb/ccm/sample/MyComponentMonolithicImpl.java' has been generated File 'org/objectweb/ccm/sample/MyHomeImpl.java' has been generated $
The Java container code is generated in a directory associated to the generated Java package, e.g.:
$ 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.
Compiling OMG CIDL files and generating associated OMG IDL and Java files
The cidl_cif script allows you to compile an OMG CIDL file
and generate:
- local OMG IDL interfaces mapping for OMG CIDL definitions
- Java component and home executor skeletons implementing previous interfaces
- Java class dependencies files for each CIDL composition
$ cat test/sample.cidl
// This file is the OMG CIDL example used in the OpenCCM User's Guide.
#pragma prefix "ccm.objectweb.org"
module sample
{
composition session SampleSessionComposition
{
home executor HomeImpl
{
implements MyHome;
manages ComponentImpl;
};
};
};
$
$ cidl_cif test/sample.cidl
cidl_cif 0.9: Reading from file test/sample.cidl...
cidl_cif 0.9: Preprocessing file test/sample.cidl...
cidl_cif 0.9: File test/sample.cidl preprocessed.
cidl_cif 0.9: Compiling test/sample.cidl file...
cidl_cif 0.9: Compilation completed: 0 warning.
cidl_cif 0.9: Generating CIF mapping from test/sample.cidl...
cidl_cif 0.9: OMG IDL mapping generated in generated_cif.idl.
cidl_cif 0.9: Generating CIF implementations...
File '.../generated/.../HomeImpl.java' has been generated
File '.../generated/.../ComponentImpl.java' has been generated
cidl_cif 0.9: CIF implementations generated.
cidl_cif 0.9: Generating CIDL dependencies...
File '.../dependencies/SampleSessionComposition.dep' has been generated
cidl_cif 0.9: CIDL dependencies generated.
$
The generated_cif.idl file contains the local OMG IDL 2.4 interfaces
mapping OMG CIDL definitions.
$ cat generated_cif.idl
. . .
#ifndef __FILE_generated_cif_idl__
#define __FILE_generated_cif_idl__
#pragma prefix "ccm.objectweb.org"
module sample
{
module SampleSessionComposition
{
local interface CIF_HomeImpl;
local interface CIF_SegmentBase;
local interface CIF_ComponentImpl;
local interface CIF_HomeImpl
: ::sample::CCM_MyHome
{
};
local interface CIF_SegmentBase
{
::sample::CCM_MyComponent_Context get_context();
::sample::SampleSessionComposition::CIF_ComponentImpl get_main_segment();
};
local interface CIF_ComponentImpl
: ::sample::SampleSessionComposition::CIF_SegmentBase,
::Components::ExecutorLocator,
::Components::SessionComponent,
::sample::CCM_MyComponent_Executor
{
};
};
};
#endif
$
The generated OMG IDL interfaces are implemented by the generated HomeImpl
and ComponentImpl Java classes.
$ ls generated/org/objectweb/ccm/sample/SampleSessionComposition/ ComponentImpl.java HomeImpl.java $
These generated classes are the home and component executor skeletons which must be inherited by the business implementation classes.
The SampleSessionComposition.dep file contains all classes
to run this compostion except user implementation classes.
$ cat dependencies/SampleSessionComposition.dep # ================================================================== # Package for Composition : # ::sample::SampleSessionComposition # ================================================================== # ================================================================== # Component ::sample::SampleSessionComposition::HomeImpl::ComponentImpl # ================================================================== org/objectweb/ccm/sample/CCM_MyComponent.class org/objectweb/ccm/sample/CCM_MyComponentHelper.class org/objectweb/ccm/sample/CCM_MyComponentHolder.class org/objectweb/ccm/sample/CCM_MyComponentOperations.class org/objectweb/ccm/sample/CCM_MyComponent_Context.class org/objectweb/ccm/sample/CCM_MyComponent_ContextHelper.class org/objectweb/ccm/sample/CCM_MyComponent_ContextHolder.class org/objectweb/ccm/sample/CCM_MyComponent_ContextOperations.class org/objectweb/ccm/sample/CCM_MyComponent_Executor.class org/objectweb/ccm/sample/CCM_MyComponent_ExecutorHelper.class org/objectweb/ccm/sample/CCM_MyComponent_ExecutorHolder.class org/objectweb/ccm/sample/CCM_MyComponent_ExecutorOperations.class org/objectweb/ccm/sample/MyComponent.class org/objectweb/ccm/sample/MyComponentCCM.class org/objectweb/ccm/sample/MyComponentHelper.class org/objectweb/ccm/sample/MyComponentHolder.class org/objectweb/ccm/sample/MyComponentMonolithicWrapper.class org/objectweb/ccm/sample/MyComponentOperations.class org/objectweb/ccm/sample/MyComponentPOA*.class org/objectweb/ccm/sample/MyComponentPOATie.class org/objectweb/ccm/sample/MyComponentSkeletonInterceptor.class org/objectweb/ccm/sample/MyComponentStubInterceptor.class org/objectweb/ccm/sample/MyComponent_componentMI.class org/objectweb/ccm/sample/MyComponent_interfaceMI.class org/objectweb/ccm/sample/SampleSessionComposition/CIF_ComponentImpl.class org/objectweb/ccm/sample/SampleSessionComposition/CIF_ComponentImplHelper.class org/objectweb/ccm/sample/SampleSessionComposition/CIF_ComponentImplHolder.class org/objectweb/ccm/sample/SampleSessionComposition/CIF_ComponentImplOperations.class org/objectweb/ccm/sample/SampleSessionComposition/CIF_SegmentBase.class org/objectweb/ccm/sample/SampleSessionComposition/CIF_SegmentBaseHelper.class org/objectweb/ccm/sample/SampleSessionComposition/CIF_SegmentBaseHolder.class org/objectweb/ccm/sample/SampleSessionComposition/CIF_SegmentBaseOperations.class org/objectweb/ccm/sample/SampleSessionComposition/ComponentImpl.class org/objectweb/ccm/sample/_MyComponentStub.class ... $
The cidl_cif script supports the following options:
| Option | Description |
|---|---|
-h or --help | Display usage and help information, and exit. |
--version | Output version information and exit. |
--silent | Silent output messages. |
--cpp path | Set the path to the external C preprocessor used. |
-P | Inhibit generation of #-lines with line-number information. |
-DNAME or -DNAME=DEF | Define NAME as DEF, default is 1. |
-UNAME | Remove any definition for NAME. |
-IDIR | Put DIR in the include file search path. |
-o outputfile | Set the output file name, default is generated_cif.idl. |
-ipath file | Add a #include "file" statement
where file must be the complete file path.
|
-d outputdir | Generate Java implementations into directory outputdir,
default is generated/.
|
-dep dependencies_dir | Generate CIDL class dependencies into directory dependencies_dir,
default is dependencies/.
|
--noprefix aprefix | CIDL class dependencies starting with aprefix
will not be included.
|
To obtain usage and help information, do:
$ cidl_cif --help
Usage: cidl_cif [-h|--help] [--version] [--silent]
[--cpp path] [-P] [-DNAME|-DNAME=DEF] [-UNAME] [-IDIR]
[-o outputfile] [-ipath file] [-d outputdir]
[-dep dependencies_dir] [--noprefix aprefix] file
Options:
-h, --help Display this information and exit
--version Output version information and exit
--silent Silent output messages
--cpp path Set the path to the external C preprocessor used
-P Inhibit generation of #-lines with line-number information
-DNAME, -DNAME=DEF Define NAME as DEF, default is 1
-UNAME Remove any definition for NAME
-IDIR Put DIR in the include file search path
-o outputfile Set the output file name, default is generated_cif.idl
-ipath file Add a #include "file" statement where
file must be the complete file path
-d outputdir Generate Java implementations into directory <outputdir>,
default is generated/
-dep dependencies_dir Generate CIDL class dependencies into directory <dependencies_dir>,
default is dependencies/
--noprefix aprefix CIDL class dependencies starting with <aprefix>
will not be included.
Description:
Compile an OMG CIDL file and generate its associated:
- local CIF interfaces
- Java component and home executor skeletons
- class dependencies files
$
To obtain version information, do:
$ cidl_cif --version OpenCCM cidl_cif 0.9 Copyright (C) 2000-2005 INRIA - USTL - LIFL - GOAL . . . $
By default, the cidl_cif script displays messages.
To silent these output messages, do:
$ cidl_cif --silent test/sample.cidl $
By default, the cidl_cif script uses an internal preprocessor written in Java.
However, it is possible to use any external C/C++ preprocessor, e.g.:
$ cidl_cif --cpp /usr/bin/cpp test/sample.cidl . . . $
Let's note that the standard -P, -D, -U and -I
options for the C/C++ preprocessor could be passed as arguments to
cidl_cif before the file name, e.g.:
$ cidl_cif -DFOO -Itest test/sample.cidl . . . $
When some preprocessing options are often used, e.g. -IAnIncludeDir,
-DTheMacro, then they could be set by default in the
xml/launcher/CIDLtoCIF.xml file if they are specific to the
cidl_cif script or in the xml/launcher/Compiler.xml
file if they are required by all OpenCCM compilation scripts.
By default, the __OMG_IDL_3__ macro is defined by
the OpenCCM OMG IDL/PSDL/CIDL compiler.
This macro could be used to distinguish if used OMG IDL modules
should be imported from the OpenCCM Interface Repository or
if their associated files should be included, e.g.
// An OMG CIDL file. #ifdef __OMG_IDL_3__ // This file is compiled by an OMG IDL 3.x compliant compiler. import CORBA; #else // This file is compiled by a non OMG IDL 3.x compliant compiler. #include <CORBA.idl> #endif // ...
By default, the cidl_cif script generates the CIDL to OMG IDL mapping
into the generated_cif.idl file.
However, this script can produce the output into a file specified by
the -o outputfile option, e.g.:
$ cidl_cif -o mapping.idl test/sample.cidl . . . $ cat mapping.idl . . . $
Using the -ipath flag produces a user
#include statement at the begin of the
generated OMG IDL 2.4 file, e.g.:
$ cidl_cif -ipath file.idl test/sample.cidl . . . $ cat generated_cif.idl . . . #include "file.idl" . . . $
By default, the cidl_cif script generates the Java component
and home executor skeleton classes into the generated/ directory.
However, the -d outputdir option allows you to specify another
directory, e.g.:
$ cidl_cif -d mapping test/sample.cidl . . . $ ls mapping/org/objectweb/ccm/sample/SampleSessionComposition/ ComponentImpl.java HomeImpl.java $
By default, the cidl_cif script generates class files
dependencies from OMG CIDL compositions into the dependencies/ directory.
However, the -dep dependencies_dir option allows you to specify another
directory, e.g.:
$ cidl_cif -dep sample_dep test/sample.cidl . . . $ ls sample_dep/ SampleSessionComposition.dep $
By default, the cidl_cif script generates all compositions class files
dependencies.
You can restrict dependencies by adding the --noprefix aprefix option to
remove class files whose name begins with aprefix, e.g.:
$ cidl_cif --noprefix org/objectweb/ccm/sample/SampleSessionComposition/ test/sample.cidl . . . $ cat SampleSessionComposition.dep # ================================================================== # Package for Composition : # ::sample::SampleSessionComposition # ================================================================== # ================================================================== # Component ::sample::SampleSessionComposition::HomeImpl::ComponentImpl # ================================================================== org/objectweb/ccm/sample/CCM_MyComponent.class org/objectweb/ccm/sample/CCM_MyComponentHelper.class org/objectweb/ccm/sample/CCM_MyComponentHolder.class org/objectweb/ccm/sample/CCM_MyComponentOperations.class org/objectweb/ccm/sample/CCM_MyComponent_Context.class org/objectweb/ccm/sample/CCM_MyComponent_ContextHelper.class org/objectweb/ccm/sample/CCM_MyComponent_ContextHolder.class org/objectweb/ccm/sample/CCM_MyComponent_ContextOperations.class org/objectweb/ccm/sample/CCM_MyComponent_Executor.class org/objectweb/ccm/sample/CCM_MyComponent_ExecutorHelper.class org/objectweb/ccm/sample/CCM_MyComponent_ExecutorHolder.class org/objectweb/ccm/sample/CCM_MyComponent_ExecutorOperations.class org/objectweb/ccm/sample/MyComponent.class org/objectweb/ccm/sample/MyComponentCCM.class org/objectweb/ccm/sample/MyComponentHelper.class org/objectweb/ccm/sample/MyComponentHolder.class org/objectweb/ccm/sample/MyComponentMonolithicWrapper.class org/objectweb/ccm/sample/MyComponentOperations.class org/objectweb/ccm/sample/MyComponentPOA*.class org/objectweb/ccm/sample/MyComponentPOATie.class org/objectweb/ccm/sample/MyComponentSkeletonInterceptor.class org/objectweb/ccm/sample/MyComponentStubInterceptor.class org/objectweb/ccm/sample/MyComponent_componentMI.class org/objectweb/ccm/sample/MyComponent_interfaceMI.class org/objectweb/ccm/sample/_MyComponentStub.class ... $
Warning: The good way to generate CIF mapping is as following:
-
ir3_feed <file.idl3> -
ir3_feed <file.psdl> -
ir3_feed <file.cidl>
OMG PSDL and CIDL files should have an import statement to access
OMG IDL declarations fed into the OpenCCM Interface Repository.
Generating Java business component implementation skeletons from OMG CIDL
The cif_jimpl script allows you to generate
Java business component implementation skeletons for an OMG CIDL file, e.g.:
$ cif_jimpl test/sample.cidl cif_jimpl 0.9: Reading from file test/sample.cidl... cif_jimpl 0.9: Preprocessing file test/sample.cidl... cif_jimpl 0.9: File test/sample.cidl preprocessed. cif_jimpl 0.9: Compiling test/sample.cidl file... cif_jimpl 0.9: Compilation completed: 0 warning. File '.../generated/.../MyHomeImpl.java' has been generated File '.../generated/.../MyComponentImpl.java' has been generated $
These generated files could be used as starting point to implement components and homes, i.e. writting their functional part.
$ ls generated/org/objectweb/ccm/sample/SampleSessionComposition/ MyComponentImpl.java MyHomeImpl.java $
The cif_jimpl script supports the following options:
| Option | Description |
|---|---|
-h or --help | Display usage and help information, and exit. |
--version | Output version information and exit. |
--silent | Silent output messages. |
--cpp path | Set the path to the external C preprocessor used. |
-P | Inhibit generation of #-lines with line-number information. |
-DNAME or -DNAME=DEF | Define NAME as DEF, default is 1. |
-UNAME | Remove any definition for NAME. |
-IDIR | Put DIR in the include file search path. |
-d outputdir | Generate Java templates into directory outputdir,
default is generated/.
|
To obtain usage and help information, do:
$ cif_jimpl --help
Usage: cif_jimpl [-h|--help] [--version] [--silent]
[--cpp path] [-P] [-DNAME|-DNAME=DEF] [-UNAME] [-IDIR]
[-d outputdir] file
Options:
-h, --help Display this information and exit
--version Output version information and exit
--silent Silent output messages
--cpp path Set the path to the external C preprocessor used
-P Inhibit generation of #-lines with line-number information
-DNAME, -DNAME=DEF Define NAME as DEF, default is 1
-UNAME Remove any definition for NAME
-IDIR Put DIR in the include file search path
-d outputdir Generate Java implementations templates into directory <outputdir>,
default is generated/
Description:
Compile an OMG CIDL file and generate its associated Java implementation templates.
$
To obtain version information, do:
$ cif_jimpl --version OpenCCM cif_jimpl 0.9 Copyright (C) 2000-2005 INRIA - USTL - LIFL - GOAL . . . $
By default, the cif_jimpl script displays messages.
To silent these output messages, do:
$ cif_jimpl --silent test/sample.cidl $
By default, the cif_jimpl script uses an internal preprocessor written in Java.
However, it is possible to use any external C/C++ preprocessor, e.g.:
$ cif_jimpl --cpp /usr/bin/cpp test/sample.cidl . . . $
Let's note that the standard -P, -D, -U and -I
options for the C/C++ preprocessor could be passed as arguments to
cif_jimpl before the file name, e.g.:
$ cif_jimpl -DFOO -Itest test/sample.cidl . . . $
When some preprocessing options are often used, e.g. -IAnIncludeDir,
-DTheMacro, then they could be set by default in the
xml/launcher/CIFtoJavaImpl.xml file if they are specific to the
cif_jimpl script or in the xml/launcher/Compiler.xml
file if they are required by all OpenCCM compilation scripts.
By default, the __OMG_IDL_3__ macro is defined by
the OpenCCM OMG IDL/PSDL/CIDL compiler.
This macro could be used to distinguish if used OMG IDL modules
should be imported from the OpenCCM Interface Repository or
if their associated files should be included, e.g.
// An OMG CIDL file. #ifdef __OMG_IDL_3__ // This file is compiled by an OMG IDL 3.x compliant compiler. import CORBA; #else // This file is compiled by a non OMG IDL 3.x compliant compiler. #include <CORBA.idl> #endif // ...
By default, the cif_jimpl script generates the Java implementation
templates into the generated/ directory.
However, the -d outputdir option allows you to specify another
directory, e.g.:
$ cif_jimpl -d mapping test/sample.cidl . . . $ ls mapping/org/objectweb/ccm/sample/SampleSessionComposition/ MyComponentImpl.java MyHomeImpl.java $
Warning: The good way to generate CIF implemention templates is as following:
-
ir3_feed <file.idl3> -
ir3_feed <file.psdl> -
ir3_feed <file.cidl>
OMG PSDL and CIDL files should have an import statement to access
OMG IDL declarations fed into the OpenCCM Interface Repository.
The OpenCCM Execution Tool Chain
The OpenCCM Execution Tool Chain provides a set of tools to control the OpenCCM distributed execution infrastructure for deploying and running CORBA component based applications.
The OpenCCM module provides the following tools :
| Tool | Description |
|---|---|
ccm_deinstall
| Deinstalls the OpenCCM Configuration Repository. |
ccm_deploy
| Deploys a CORBA component assembly archive. |
ccm_install
| Installs the OpenCCM Configuration Repository. |
jcs_start
| Starts an OpenCCM Java Component Server. |
jcs_stop
| Stops an OpenCCM Java Component Server. |
tear_down
| Tears down a deployed CORBA component assembly. |
Installing the OpenCCM Configuration Repository
The OpenCCM Execution Tool Chain is mainly based on the use of the OpenCCM Configuration Repository.
Let's note that before using any OpenCCM Execution Tool Chain tool, it is required to install the OpenCCM Configuration Repository.
The ccm_install script installs the OpenCCM Configuration
Repository, e.g.:
$ ccm_install The OpenCCM Platform will be installed. Creating the $OpenCCM_CONFIG_DIR directory. Creating the $OpenCCM_CONFIG_DIR/DCIManagers directory. Creating the $OpenCCM_CONFIG_DIR/NodeManagers directory. Creating the $OpenCCM_CONFIG_DIR/ComponentServers directory. Creating the $OpenCCM_CONFIG_DIR/AssemblyFactoryManagers directory. Creating the $OpenCCM_CONFIG_DIR/log directory. Copying the default Trace Service config file. The OpenCCM Platform is installed. $
Let's note that this script automatically creates the
$OpenCCM_CONFIG_DIR and its subdirectories.
The DCIManagers,
NodeManagers,
ComponentServers, and
AssemblyFactoryManagers
subdirectories will store the standard output, the IOR, and the PID of
all started OpenCCM DCI Managers, Node Managers, Component Servers, and
Assembly Factory Managers respectively.
The log subdirectory will store trace output files.
$ ls $OpenCCM_CONFIG_DIR AssemblyFactoryManagers/ ComponentServers/ DCIManagers/ NodeManagers/ log/ $
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 Configuration Repository.
Deinstalling the OpenCCM Configuration Repository
The ccm_deinstall script deinstalls the previously installed
OpenCCM 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. $
Let's note that this script stops all currently started OpenCCM processes
and removes the $OpenCCM_CONFIG_DIR directory.
Starting an OpenCCM Java Component Server
An OpenCCM Java Component Server is the runtime structure
for hosting CORBA container, home and component instances.
This server implements the CORBA Components Deployment
ComponentServer
and Container interfaces.
The jcs_start script starts an OpenCCM Java
Component Server.
Its usage is the following:
$ jcs_start usage: jcs_start [-h|--help] [--ots] [--trace] <server_name> $
Each OpenCCM Java Component Server must be started with an unique server name, e.g.:
$ jcs_start MyServerName The OpenCCM Java Component Server MyServerName will be started with []. Creating the $OpenCCM_CONFIG_DIR/ComponentServers/MyServerName.archive_cache directory. Creating the $OpenCCM_CONFIG_DIR/ComponentServers/MyServerName/ specific directory. Launching an OpenCCM Java Component Server with []. Backup the current directory. The OpenCCM Java Component Server MyServerName is started with []. $
Warning: Each started OpenCCM Java Component Server must have a distinct name, e.g.:
$ jcs_start MyServerName Error: The OpenCCM Java Component Server MyServerName is already started! $
Let's note that the CosNaming Service must be started before, see the ns_start script, e.g.:
$ ns_stop . . . $ $ jcs_start MyServerName Error: The CosNaming Service is not started! $
The jcs_start script automatically creates a directory to store downloaded archives,
launches an OpenCCM Java Component Server process and stores its standard output,
IOR and PID into the OpenCCM Configuration Repository, e.g.:
$ ls $OpenCCM_CONFIG_DIR/ComponentServers MyServerName/ MyServerName.archive_cache/ MyServerName.IOR MyServerName.output MyServerName.PID $
The started OpenCCM Java Component Server is bound into the CosNaming Service with the server name given as parameter.
The --ots option starts a transactional OpenCCM
Java Component Server, e.g.:
$ jcs_start --ots MyServerName The OpenCCM Java Component Server MyServerName will be started with [ Transactional ]. Creating the $OpenCCM_CONFIG_DIR/ComponentServers/MyServerName.archive_cache directory. Creating the $OpenCCM_CONFIG_DIR/ComponentServers/MyServerName/ specific directory. Launching an OpenCCM Java Component Server with [ Transactional ]. Backup the current directory. The OpenCCM Java Component Server MyServerName is started with [ Transactional ]. $
Let's note that the CosTransactions Service must be started before, see the ots_start script, e.g.:
$ ots_stop . . . $ $ jcs_start MyServerName Error: The CosTransactions Service is not started! $
The --trace option starts an OpenCCM
Java Component Server with the trace service, e.g.:
$ jcs_start --trace MyServerName The OpenCCM Java Component Server MyServerName will be started with [ Trace ]. Creating the $OpenCCM_CONFIG_DIR/ComponentServers/MyServerName.archive_cache directory. Creating the $OpenCCM_CONFIG_DIR/ComponentServers/MyServerName/ specific directory. Launching an OpenCCM Java Component Server with [ Trace ]. Copying the Trace Service configuration file to the specific ComponentServer directory. Backup the current directory. The OpenCCM Java Component Server MyServerName is started with [ Trace ]. $
Both --ots and --trace options could be used
simultaneously, e.g.:
$ jcs_start --ots --trace MyServerName The OpenCCM Java Component Server MyServerName will be started with [ Transactional Trace ]. Creating the $OpenCCM_CONFIG_DIR/ComponentServers/MyServerName.archive_cache directory. Creating the $OpenCCM_CONFIG_DIR/ComponentServers/MyServerName/ specific directory. Launching an OpenCCM Java Component Server with [ Transactional Trace ]. Copying the Trace Service configuration file to the specific ComponentServer directory. Backup the current directory. The OpenCCM Java Component Server MyServerName is started with [ Transactional Trace ]. $
See the jcs_stop
script to stop a started OpenCCM Java Component Server.
Stopping an OpenCCM Java Component Server
The jcs_stop script stops a previously started
OpenCCM Java Component Server.
Its usage is the following:
$ jcs_stop usage: jcs_stop [-h|--help] <server_name> $
To stop an OpenCCM Java Component Server, it is required to provide its server name, e.g.:
$ jcs_stop MyServerName The OpenCCM Java Component Server MyServerName will be stopped. The OpenCCM Java Component Server MyServerName is stopped. $
$ jcs_stop MyServerName Error: The OpenCCM Java Component Server MyServerName is not started! $
When providing an invalid server name, an error obscurs, e.g.:
Let's note that this script shutdowns the specified OpenCCM Java Component Server process and removes its associated files from the OpenCCM Configuration Repository.
$ ls $OpenCCM_CONFIG_DIR/ComponentServers $
Deploying a CORBA Component Assembly Archive
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 an assembly archive, i.e. a ZIP file with CCM XML descriptors
and CORBA component archives.
The usage of this script is the following:
$ ccm_deploy usage: ccm_deploy [-h|--help] [--version] [--silent] [--ots] [--trace] [--tracing] [-l] [-F <AssemblyFactoryName>] <assembly.aar> $
To start a deployment, an assembly archive must be provided as parameter, e.g.:
$ ccm_deploy MyAssembly.aar ccm_deploy 0.9: Initiating deployment sequence of archives\MyAssembly.aar http://127.0.0.1:2255/archives\MyAssembly.aar Request received:GET /archives\MyAssembly.aar HTTP/1.1 Downloading http://134.206.11.41:2255/archives\MyAssembly.aar [******************] AssemblyManager>>File [META-INF/MyAssembly.cad] is used for deployment Request received:GET /archives/MyComponent.jar HTTP/1.1 Request received:GET /MyComponent.car HTTP/1.1 ccm_deploy 0.9: Successfully deployed archives\MyAssembly.aar $
Deploy the given component assembly archive using the default factory connected to the current DCIManager.
$ ccm_deploy -F myAssemblyFactory MyAssembly.aar ccm_deploy 0.9: Initiating deployment sequence of archives\MyAssembly.aar Use the specified assembly factory [myAssemblyFactory] http://127.0.0.1:2255/archives\MyAssembly.aar Request received:GET /archives\MyAssembly.aar HTTP/1.1 Downloading http://134.206.11.41:2255/archives\MyAssembly.aar [******************] AssemblyManager>>File [META-INF/MyAssembly.cad] is used for deployment Request received:GET /archives/MyComponent.jar HTTP/1.1 Request received:GET /MyComponent.car HTTP/1.1 ccm_deploy 0.9: Successfully deployed archives\MyAssembly.aar $
Deploy the given component assembly archive using the myAssemblyFactory assembly factory given in parameter.
The assembly factory must be started by the factory_start myAssemblyFactory command.
$ ccm_deploy -l MyAssembly.aar ccm_deploy 0.9: Initiating deployment sequence of archives\MyAssembly.aar Local deployment processing http://127.0.0.1:2255/archives\MyAssembly.aar Request received:GET /archives\MyAssembly.aar HTTP/1.1 Downloading http://134.206.11.41:2255/archives\MyAssembly.aar [******************] AssemblyManager>>File [META-INF/MyAssembly.cad] is used for deployment Request received:GET /archives/MyComponent.jar HTTP/1.1 Request received:GET /MyComponent.car HTTP/1.1 ccm_deploy 0.9: Successfully deployed archives\MyAssembly.aar $
Deploy the given component assembly archive without any assembly factory the deployment is locally proceed. The resulting assembly will not be teardownable beacause no server hosts the assembly object.
$ ccm_deploy -l -F myAssemblyFactory MyAssembly.aar ccm_deploy 0.9: Initiating deployment sequence of archives\MyAssembly.aar Local deployment processing http://127.0.0.1:2255/archives\MyAssembly.aar Request received:GET /archives\MyAssembly.aar HTTP/1.1 Downloading http://134.206.11.41:2255/archives\MyAssembly.aar [******************] AssemblyManager>>File [META-INF/MyAssembly.cad] is used for deployment Request received:GET /archives/MyComponent.jar HTTP/1.1 Request received:GET /MyComponent.car HTTP/1.1 ccm_deploy 0.9: Successfully deployed archives\MyAssembly.aar $
Deploy the given component assembly archive without any assembly factory the deployment is locally proceed. The resulting assembly will not be teardownable beacause no server hosts the assembly object. In that case the second parameter -F myAssemblyFactory is ignored because the local deployment have the highter priority.
Refer to the Writing CCM XML meta files section for more information about the XML files you can use.
The ccm_deploy script supports the following options:
| Option | Description |
|---|---|
-h or --help | Display usage and help information, and exit. |
--version | Output version information and exit. |
--silent | Silent output messages. |
--ots | Deploy inside a transaction. |
--trace | Deploy with the Trace Service running. |
-l | Precise that the deployment must be local without using assembly factory. |
-F <AssemblyFactoryName> | Set which assembly factory must be used to deploy. |
To obtain usage and help information, do:
$ ccm_deploy --help
Usage: ccm_deploy [-h|--help] [--version] [--silent]
[-l] [-F factory_name] zip_file.aar
Options:
-h, --help Display this information and exit
--version Output version information and exit
--silent Silent output messages
-l This flag indicates that the deployment must be done locally
without using an assembly factory
-F factory_name The name of the factory to use, default is DefaultFactory
Description:
Deploy an assembly archive
$
To obtain version information, do:
$ ccm_deploy --version ccm_deploy 0.9 Copyright (C) 2000-2003 INRIA - USTL - LIFL - GOAL . . . $
By default, the ccm_deploy script displays messages.
To silent this output messages, do:
$ ccm_deploy --silent MyAssembly.zip $
Warning: Both --ots and --trace options
will be supported in future releases.
Tearing down an assembly
$ tear_down MyAssembly
[No output if successfull.]
$
The tear_down command allows to stop the assembly MyAssembly given in parameter from the console. The torn assembly is not destroyed : To destroy it you can use the ccm_explorer. The parameter MyAssembly is the componentassembly id described in the component assembly descriptor.
Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster | Last modified at 2005-07-07 02:04 PM