Es ist stark an der EJB-Spezifikation der Firma Sun orientiert und stellt gewissermaßen eine von einer konkreten Programmiersprache unabhängige Verallgemeinerung der EJBs dar. Es existiert eine standardisierte Abbildung, mit deren Hilfe EJBs als CCMs (oder umgekehrt) betrachtet werden können.
Das CCM beschränkt sich explizit auf Server-seitige Bausteine mit relativ grober Granularität. Diese können in beliebigen Programmiersprachen implementiert werden, solange sie über eine CORBA-konforme Schnittstellenbeschreibung verfügen.
Ähnlich wie bei den EJBs werden unterschiedliche Arten von Bausteinen unterschieden: Session- und Entity-Bausteine, die ihrem jeweiligen Äquivalent in der EJB-Architektur entsprechen; darüber hinaus Service-Komponenten, die einen zustandslosen Dienst bereitsstellen sowie Process-Komponenten zur Modellierung von Abläufen.
Die Schnittstellen, über die ein CCM-Baustein angesprochen werden kann werden als sogenannte Ports bezeichnet. Es werden die folgenden vier Ports unterschieden:
Darüber hinaus muß jeder CCM-Baustein über eine Vielzahl von Schnittstellen verfügen, die die Kommunikation mit dem ausführenden Container betreffen.
Ein CCM-Baustein macht seine Konfigurationsattribute über Methoden zugänglich. Somit ist eine Entwicklungsumgebung in der Lage, die Bausteine für die Verwendung in einer speziellen Umgebung bzw. in einer bestimmten Anwendung zu konfigurieren.
Die Verknüpfung von CCM-Bausteinen zu Anwendungen erfolgt typischerweise wie bei den EJBs innerhalb der Clients. Darüber hinaus existiert die Möglichkeit der Verknüpfung mittels Receptacles bzw. Events, über die aufgrund der bislang fehlenden Implementierung allerdings keine Aussage getroffen werden kann.
Genau wie bei den EJBs erfolgen Aufrufe eines CCM-Bausteins niemals direkt, sondern immer über den ausführenden Container (Interception ). Auch hier wäre somit durch Instrumentierung des Containers eine Automation der Anwendungsüberwachung zu erreichen.