Component container

Components run in a CCM Container (Fig. A.2). Containers provide the runtime environment for CORBA components. Containers are built on the Object Request Broker (ORB), the Portable Object Adapter (POA), and other CORBA services.

Figure A.2: CCM container

As shown in Fig. A.2, the container programming model is made of interfaces that are used by the client, the container, and the components. These interfaces fall into the following three categories:

Internal interfaces

These local interfaces are used by the component developer and provided by the container to assist in the implementation of the component's behavior.

External interfaces

The external interfaces define the external view of a component. They are used by the client and implemented by the component developer.

Callback interfaces

These local interfaces are used by the container and implemented by the component, either in generated code or directly, so that the component can be deployed in the container.

The CCM specification defines four component categories. The behavior of these categories is specified by the container interface types. Additionally, there is a component category that describes the empty container.

Service component

The service component has behavior, no state, and no identity. The lifespan of a service component is equivalent to the lifetime of a single operation request.

Session component

The session component has behavior, transient state, and an identity (which is not persistent). Note that the session component is equivalent to the stateful session bean found in Enterprise Java Beans (EJB).

Process component

The process component has behavior, persistent state (which is not visible to the client), and a persistent identity.

Entity component

The entity component has behavior, persistent state (which is visible to the client), and an identity (which is visible to the clients through a primary key declaration).