|
Table of Contents
Warning: The OpenCCM User's Guide is now split
into the following documents:
-
OpenCCM User's Guide home page
-
The OpenCCM's Compilation Chain
-
Generation and implementation rules
-
The OpenCCM's Execution Chain
-
Demonstrations
-
Writing an application with OpenCCM
-
Writing CCM XML meta files
Generation and implementation rules
-
Generated files
-
Skeleton mappings
-
What should be implemented
Here are described the most important generation and implementation rules
for the OpenCCM platform.
For more details, have a look into the generated OpenCCM files or into the
CORBA Component Model Specification.
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
MyHome home definition, two interceptor
files are generated: MyHomeSkeletonInterceptor and
MyHomeStubInterceptor .
-
For an event type definition, no files are generated.
-
For a valuetype inheriting from
Components::PrimaryKeyBase
(i.e. a primary key type), no files are generated.
Skeleton mappings
-
Mappings for components:
-
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 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.
-
Components
Actually OpenCCM does not provide a complete Component Implementation
Framework (CIF). However, components implementors can choose between a
monolithic and a segmented implementation strategy as specified in the
CCM specification.
-
Monolithic strategy
In a monolithic strategy, all features of the component must
be provided by the same class. In order to do this, the following
rules must be followed:
-
For a
MyComponent component declaration and a
MyComponentImpl implementation, MyComponentImpl
class must extend org.omg.CORBA.LocalObject and implement
the CCM_MyComponent local interface,
-
If a
MyComponent component declaration provides a
facet of type InterfaceType , the
MyComponentImpl implementation class
has to implement the CCM_InterfaceType local interface.
-
Segmented strategy
In a segmented strategy, features implementations can be delegated
to specific classes. In order to do this, the following rules must be
followed:
-
For a
MyComponent component declaration and a
MyComponentImpl main executor implementation,
MyComponentImpl class must extend
org.omg.CORBA.LocalObject and implement
the CCM_MyComponent_Executor and
org.omg.Components.ExecutorLocator local interfaces,
-
If a
MyComponent component declaration provides a
facet of type InterfaceType , this facet can be implemented
in a specific class and must extend the
org.omg.CORBA.LocalObject interface and
implement the CCM_InterfaceType local interface.
-
If a
MyComponent component declaration consumes
an event of type MyEventType , the event consumer
can be implemented in a specific class and must extend the
org.omg.CORBA.LocalObject interface and
implement the CCM_MyEventTypeConsumer local interface.
In both cases, some specific OpenCCM dependencies
have to be respected. The main executor class has to implement the
following method:
-
A configuration_complete method which is added
to org.omg.Components.EnterpriseComponent :
public void
configuration_complete()
throws org.omg.Components.InvalidConfiguration;
This method is called by the container when component configuration
is done after deployment. This specific OpenCCM dependency was introduced
because the CCM specification does not provide a standard way.
-
OpenCCM allows you to implement the
Component::SessionComponent local interface
in your main executor implementation. But warning, only
set_session_context and ccm_remove
methods of this interface are called from the OpenCCM
container, so ccm_activate and
ccm_passivate
are never called by the container. This issue
should be resolved in next releases.
-
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.
-
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.
|