The CORBA Component Model (CCM) is a specification for creating server-side scalable, language-neutral, transactional, multi-user and secure enterprise-level applications. It provides a consistent component architecture framework for creating distributed n-tier middleware. It would be fair to call a component written to the CCM spec a CORBA component.

A typical CCM Architecture consists of
CCM Containers,
CORBA components that run in these containers,
the Portable Object Adapter (POA),
the Object Request Broker (ORB)
other CORBA object services like
CORBA Transactions, CORBA Security, CORBA Persistence, CORBA Events, etc...

In a typical development and deployment scenario, there will be an Application server provider who creates and sells an Application server along with CCM containers that will run on these servers. Then there will be the CCM providers-people responsible for developing CORBA components and the Application assemblers-people that use pre-built CORBA components to build their applications.

Application Servers :
These provide the system services like a raw execution environment, multiprocessing, load-balancing, device access, provide naming and transaction services and make containers visible.

CCM Containers :
These act as the interface between a CORBA component and the outside world. A CCM client never accesses a CORBA component directly. Any component access is done through container-generated methods which in turn invoke the component's methods. There are basically two basic types of containers. They are transient containers that may contain transient, non-persistent components whose states are not saved at all and persistent containers that contain persistent components whose states are saved between invocations. Depending upon the types of components that they can execute, CCM Containers may be divided into:
Service containers,
Session containers,
Entity containers, and
Other containers

CCM Clients :
These make use of the CCM components for their operations. They find the CCM container that contains the component through COSNaming and create, or obtain a reference to the component's container through the component's Home Interface. They then make use of the CCM Container to invoke the component methods.

CCM Components:
CCM components can expose multiple interfaces. While defining the IDL for each component, the interfaces that it provides and the interfaces that it uses have to be specified. Similarly, the events that it emits (or publishes) and the events that it consumes have to be defined in the IDL. The interfaces that it provides are called facets. The ability to use an interface is facilitated by declaring it as a receptacle. Event emition and publication declarations are used to define an event source. Event consumption declarations are used to describe event sinks. Facets, receptacles, event sources and event sinks are collectively called Ports.

There are four types of CCM components. They are
Service components,
Session components,
Process components and
Entity components

Service Components:
Each Service component is usually associated with one CCM Client and it's lifetime is restricted to that of one single operation request (or a single method call) . Each Service component is created and destroyed by the particular CCM Client that it is associated with. Service components do not survive a System shutdown.

Session Components:
Each Session component is usually associated with one CCM Client. Each Session component is created and destroyed by the particular CCM Client that it is associated with. A Session component can either have states or they can be stateless. However, Session components do not survive a System shutdown. A Session component is very similar to a Session EJB.

Process Components:
Process components always have states. Each Process component may however be shared by multiple CCM Clients. Their states can be persisted and stored across multiple invocations. Hence they can survive System Shutdowns.

Entity Components:
Entity components always have states. Each Entity component may however be shared by multiple CCM Clients. Their states can be persisted and stored across multiple invocations. Hence they can survive System Shutdowns. Each Entity component can be uniquely identified by its Primary Key. An Entity component is very similar to an Entity EJB.

One of the major differences between Process and Entity components are that while the Entity component has a Primary Key to uniquely be identified by the client, a Process component does not expose its identity to the client except through user-defined operations. While Entity Components are used to represent entities like customers or accounts, Process components represent business processes like applying for a loan or creating a work order, etc.

Servers have a right to manage their working set and they sometimes achieve this using Persistence. They may either use CORBA persistence or a user-defined persistence mechanism. Passivation is the process by which the state of a component is saved to persistent storage and then is swapped out. Activation is the process by which the state of a component is restored by swapping it in from persistent storage.

There are two types of Session Components. They are
Stateless Session Components and
Stateful Session Components

Stateless Session Components:
These types of components have no internal state. Since they do not have any states, they need not be passivated. Because of the fact that they are stateless, they can be pooled in to service multiple clients (remember MTS components and Stateless Session EJBs?)

Stateful Session Components:
These types of components possess internal states. Hence they need to handle Persistence. These types of components can be saved and restored across client sessions. (remember Stateful Session EJBs?)

Persistence in Entity and Process components is of two types. They are:
Container-managed persistence
Component-managed persistence

Container-managed persistence:
Here, the CCM container is responsible for saving the component's state. Since it is container-managed, the implementation is independant of the data source. Persistence is automatically handled by the container.

Component-managed persistence:
Here, the Entity component is directly responsible for saving its own state. The container does not need to generate any database calls. Hence the implementation is less adaptable than the previous one as the persistence needs to be hard-coded into the component.

Interfaces between the Application Server and CCM Containers :
The CCM specification defines a standard way to implement the container API through CORBA object services. Therefore, the interfaces between the Server and the container are well specified. In fact, since EJB is a subset of CCM, vendors can now implement the EJB container API through CORBA object services.

Packaging and Deployment:
CCM uses XML descriptors for specifying information about packaging and deployment just like EJB. However, additionally, CCM has an assembly descriptor, which contains metadata about how two or more CCM components are wired together.

 

More to come soon...