Component model

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
\includegraphics[width=6cm,angle=0]{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