Table of contents
-
Environment for using OpenCCM
-
Loading the OpenCCM environment
-
The OpenCCM's Configuration Repository
-
The OpenCCM's Compilation Chain
-
ir3_start
-
ir3_started
-
ir3_stop
-
ir3_check
-
ir3_feed
-
ir3_idl3
-
ir3_idl2
-
ir3_java
-
ir3_jimpl
-
ir3_xmi
-
Generation and implementation rules
-
Generated files
-
Skeleton Mappings
-
What should be implemented
-
The OpenCCM's Execution Chain
-
ccm_install
-
ccm_installed
-
ccm_deinstall
-
ns_start
-
ns_ior
-
ns_gui
-
ns_stop
-
ots_start
-
ots_ior
-
ots_stop
-
jcs_start
-
jcs_start_ots
-
jcs_stop
-
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
installed or compiled.
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
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:
Tool | Description |
ir3_start | Starts the OpenCCM's OMG IDL3 Repository (named IR3). |
ir3_started | Checks if the OpenCCM's IR3 is started. |
ir3_stop | Stops the OpenCCM's IR3. |
idl3_check | Checks if the specified OMG IDL 3.0 file is correct. |
ir3_feed | Feeds the specified OMG IDL 3.0 file into the OpenCCM's IR3. |
ir3_idl3 | Generates an OMG IDL 3.0 file associated to an IR3 object
and its childs. |
ir3_idl2 | Generates an OMG IDL 2.4 file associated to an IR3 object
and its childs. |
ir3_java | Generates all Java OpenCCM skeletons associated to an
IR3 object and its childs. |
ir3_jimpl | Generates all Java implementation patterns associated
to an IR3 object and its childs. |
ir3_xmi | Generates 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.4: Reading from file test/sample.idl3...
OpenCCM's OMG IDL 3.0 Compiler 0.4: Preprocessing file test/sample.idl3...
OpenCCM's OMG IDL 3.0 Compiler 0.4: File test/sample.idl3 preprocessed
OpenCCM's OMG IDL 3.0 Compiler 0.4: Feeding the Interface Repository ...
OpenCCM's OMG IDL 3.0 Compiler 0.4: 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.4: Reading from file test/sample.idl3...
OpenCCM's OMG IDL 3.0 Compiler 0.4: Preprocessing file test/sample.idl3...
OpenCCM's OMG IDL 3.0 Compiler 0.4: File test/sample.idl3 preprocessed
OpenCCM's OMG IDL 3.0 Compiler 0.4: Feeding the Interface Repository ...
OpenCCM's OMG IDL 3.0 Compiler 0.4: 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 patterns associated to an IR3 object
The ir3_jimpl script allows one to generate the Java
implementation patterns 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 XMIPrinter 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.
The XMIPrinter 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
. . .
$
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
. . .
$
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
. . .
. . .
$
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 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/ .
-
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.
-
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.
-
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:
- General mappings: The implementations of all operations inherited
from the
Components::CCMObject, Components::Navigation,
Components::Receptacles, and Components::Events
interfaces are automatically generated.
- 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.
- Executor mappings: The implementation of the component's
initialization is automatically generated.
-
Mappings for homes:
- General mappings: The implementations of all operations inherited
from the
Components::CCMHome interface are automatically
generated.
- Specific mappings: The implementations of all operations inherited
from the generated Implicit OMG IDL 2.4 interface are automatically
generated.
- Executor mappings: The implementation of the home's initialization
is automatically generated.
What should be implemented
- 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 interface. 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.
- Components
Actually OpenCCM doesn't provides 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.
-
Homes
OpenCCM have 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.
- 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.
-
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:
Tool | Description |
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.
|
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.
Demonstrations
The following demonstrations are available:
Demo | Description |
demo/hello | This 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/demo1 | This 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/demo2 | This 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/demo3 | This 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/dinner | This 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:
- Go to the associated directory.
-
Execute the following command:
% ant
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 use a transactional service.
-
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 to do:
-
bin/install_java <ComponentServerName> <NS_Name> or
bin/install_cssh <ComponentServerName> <NS_Name> or
bin/install_jish <ComponentServerName> <NS_Name>
where <ComponentServerName> is the name of the component server on which you
choose to deploy the Server home (usually "ComponentServer1" or "ComponentServer2")
and <NS_Name> is a name used to register the Server home in the
Name Service.
-
bin/run_java <NS_Name> or
bin/run_cssh <NS_Name> or
bin/run_jish <NS_Name>
where <NS_Name> is the name of a Server home used to instantiate
components.
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.
|