The Container manages component instances depending on component category. It offers all its services through simplified APIs: it becomes component's window to the outside world. The container offers series of local interfaces (internal interfaces) for establishing component's context and allows component to implement series of callback methods.

The container API defines a API framework, i.e. contract between specific component and container. It defines two types of container APIs namely session APIs and entity APIs depending on component category explained below.

A CORBA® usage model specifies the required interaction pattern between the container, the POA and the CORBA services. It defines three types of usage model that are distinguished by reference persistence and servant to ObjectId mapping.

Stateless - which uses transient object references in conjunction with a POA servant which can support any ObjectId. Conversational - which uses transient references with a POA servant that is dedicated to specific ObjectId Durable - which uses persistence references with POA servant that is dedicated to a specific ObjectId.

The component categories are defined as valid combination of external API types, container type and CORBA usage model and can be summarized as follows:

A service component has behaviour, but no state and no identity. It's useful for modelling things that provide single independent execution of an operation. For example a command object, wrapper of legacy procedure or a TUXEDO service can be modelled as service components.

A session component has a behaviour, a transient state and but no persistent identity. It's useful for modelling a client session such as Login, Iterator or Shopping Cart.

An entity component has behaviour (possibly transactional), persistent state which is not visible to client and identity which is visible to client via a primary key. It's useful in modelling business entities such as Account, Customer etc.

A process component has behaviour, persistent state which is not visible to client and persistent identity which is visible through explicit user defined operations. It's useful to model a business process rather than entities. For example order processing and payment processing can be modelled as process components.

The container provides interfaces to component (Container APIs) to access CORBA services (transaction, security and persistence) and to other elements of component model. Component defines these features using deployment descriptors for runtime container. In addition to object services the component can specify servant lifetime policy to optimise memory usage.

CORBA component supports both self-managed transaction through container APIs or container managed transaction by using set of defined policies.

NOT_SUPPORTED The component does not support transactions. If client sends transaction to the component, it remains suspended until component completes the operation. REQUIRED The component requires a current transaction to execute successfully. If the operation is invoked without a transaction context, the container starts new transaction and commits or rollback once operation is completed by component. SUPPORTS This component will support transaction if one is available. REQUIRES_NEW The component requires its own transaction to execute successfully. If client sends transaction context it'll remain suspended until the new transaction is completed. MANDATORY The component requires the client be in a current transaction before this operation is invoked. NEVER The component required that client not be in current transaction before this operation is invoked.

The security policy is applied consistently to all categories of components. The container relies on CORBA security to consume the security policy declarations from the deployment descriptor and to check active credential for invoking operations. Access permissions are defined by the deployment descriptor associated with the component.

CORBA components use a simple subset of the CORBA notification service to emit and consume events. Event can be transactional as well as can contain access control lists.

The entity container API type supports the use of persistence mechanism for making component state durable. Container API defines two types of persistence support.