The CCM defines a component architecture and a container framework in which the
component life cycle takes place. Components and their supporting objects
(homes, interfaces, etc.) are all defined using a formal language called the
Interface Definition Language (IDL). The CCM is part of the OMG's CORBA version
3.0 standard, so CCM descriptions use IDL3 as a specification language.
Figure A.1:
CCM component
|
A CCM Component (Fig. A.1) provides a variety of surface
features that support ways to connect components together to form assemblies:
- Home
- The component home is an interface that defines factory and finder methods
to create or find component instances that the home manages. Each home supports
at least one create method.
- Equivalent interface
- Every IDL3 interface (containing the keywords component, home, etc.)
can be transformed into a classic IDL interface, one that can be processed by a
regular IDL compiler. This classic IDL interface is known as the equivalent
interface. The IDL3 to IDL mapping adds some interfaces and equivalent
operations to the interfaces specified by the user in the IDL3 source file. As
described by the CCM specification, every IDL3 construct defines its own IDL3 to
IDL mapping.
- Supported interface
- A home or component definition can support zero or more interfaces. Each
supported interface results in an inheritance of supported interfaces in the
corresponding equivalent interfaces. Supported interfaces basically give
component designers a way to assign context-free methods to a component.
- Attribute
- A component or a component home can have attributes. Attributes are
named values exposed through accessor and mutator operations (otherwise known as
get and set operations). Attributes are primarily intended to be used for
component configuration.
- Facet
- A component facet is a named interface that provides access to specific
component methods. A component may have zero or more facets. The component's
equivalent interface inherits the Components::Navigation interface; this
interface defines generic operations for facet access. Facets can be seen as a
way for component designers to assign contextual methods to a component; that
is, the methods defined in a facet interface can only be called if the component
has one or more compatible receptacles attached to the facet.
- Receptacle
- A component receptacle is an abstract way of creating a socket on a
component that receives connections of a certain type. Thus receptacles are
concretely manifested on a component as a set of operations for establishing and
managing connections. A component may have zero ore more receptacles. The
component's equivalent interface inherits the Components::Receptacles
interface; this interface defines generic operations for receptacle management.
Like facets, the operations defined in a receptacle interface can be seen as
contextual methods; they require a connected facet to function correctly.
- Event source
- An event source embodies the potential for the component to generate
events of a specified type and provides mechanisms for associating consumers
with sources. There are two categories of event sources, emitters and publishers. An emitter can be connected to at most one proxy provider by the
container. A publisher can be connected through the channel to an arbitrary
number of consumers that are subscribed to the publisher event source.
- Event sink
- An event sink embodies the potential for the component to receive events
of a specified type.
The component model is also defined in a MOF compliant metamodel, the Interface Repository Metamodel. The Interface Repository Metamodel expresses
the extensions to classic IDL defined by the CCM.
2003-11-09