Unique Features of CCM
Interworking with EJB

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.

  container architecture

As shown in the figure above, the container manages a component. It creates and uses a POA with requested features for specific component category. Client can use external interfaces of a component to interact with component and home interfaces to manage life cycle of a component.

  External API Types

The external API types of a component are the contract between the component developer and the component client. It consists of two types of interfaces mainly home interface and application interface. Home interface allows client to obtain reference to one of the application interfaces the component implements. From client's prospective two design patterns are supported namely factory patterns for creating new components and finder patterns for existing components. These patterns are distinguished by the presence of primary key on home declaration.

  Container API Type

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.

  CORBA Usage Model

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.


  Component Categories

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

Usage Model
API Type
Primary Key Component

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 Server Programming Environment

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.

Servant Lifetime Management
  Servant Lifetime Management

Servants are programming language objects which the POA uses to dispatch operation requests based on object identification. The server programming model for CORBA components include facilities to efficiently manage the memory associated with these programming objects. The servant lifetime policies are defined as follows:

Method This policy causes the container to activate the component on every operation request and to passivate when that operation is completed.
Transaction This policy causes the container to activate the components on the first operation of request within transaction and leave it until transaction completes.
Component This policy causes the container to activate the component on the first operation and remains active until component implementation requests to passivate.
Container This policy cause the container to activate component on the first operation request and leave it active until container decides to passivate it.



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.

Container-managed persistence the component developer simply defines the state that is to be made persistent and container automatically saves and restores state as required. Container managed persistence is selected by defining abstract state associated with component using state declaration language called PSDL (Persistence State Description Language)
Self-managed persistence the component developer assumes the responsibility of managing persistent state of the component.
  CORBA® is a Registered Trade Mark of Object Management Group,Inc. in USA and other countries
Copyright 2008 iCMG. All rights reserved.
Site Index | Contact Us | Legal & Privacy Policy