CCM Containers 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
Component implementations can be packaged in the following manner: First they are placed inside of a assembly file, such as a shared library, a JAR file, or a DLL, and linked dynamically. Second, a deployment mechanism supplied by a CCM provider is used to deploy the component in a component (application) server that hosts component implementations by loading their assembly files. Thus, components execute in component servers and are available to process client requests.
The CCM behaves from a component developer’s perspective, allowing the developer to generate many types of server applications automatically.
Components can now be deployed in component servers that have no advanced knowledge of how to configure and instantiate these deployed components. This is accomplished by the component implementing a generic interface that all servers can recognize.
CCM components can also be configured dynamically through the use of ports. Ports enable standard configuration mechanisms to modify component configurations/state remotely. They are similar to a GET method call in OOD.
The CCM port mechanisms provide interfaces to configure a component, enabling developers to set up object connections, subscribe or publish events, and establish component attributes. For a developer to assemble components into a software component infrastructure or integrate a component into an application, however, there must be a mechanism to express a concrete configuration for a component; in particular they need to designate what component(s) must be connected and how the events published and received by a component relate to each other. Therefore, CCM defines a standard component configuration interface, called
CCM also defines several other interfaces to support the structure and functionality of components. Many of these interfaces can be generated automatically via tools supplied by CCM Providers. Moreover, life cycle management and the state management implementations can be factored out and reused. The CORBA Component Implementation Framework (CIF) is designed to shield component developers from these tedious tasks by automating common component implementation activities.
Many business applications use components to model “real world” entities, such as employees, bank accounts, and stockbrokers. These entities may persist over time and are often represented as database entries. Components with persistent state are mapped to a persistent data store that can be used to reconstitute component state whenever the component instance is activated. For example, when a bank account component is instantiated, the CCM component model implementation is able to reconstitute the previous status of the account from a database. The CIF defines a set of APIs that manage the persistent state of components and construct the implementation of a software component .