CORBA ist nicht an eine bestimmte gebunden. Mittels einer Interface Definition Language (IDL) erstellt man eine formale Spezifikation Klassen und Objekte sowie sämtlicher Parameter und Diese Schnittstellenbeschreibung wird dann in ein Objektmodell verwendeten Programmiersprache umgesetzt. Die breiteste Unterstützung existiert Java und C++ es existieren jedoch auch Implementierungen für weitere Sprachen.
Meist erzeugt ein so genannter IDL-Compiler und Skeletons die mit der eigentlichen Programmlogik werden. Der lokale Client ruft nun den auf der die Daten an einen Object Broker (ORB) weitergibt. Dieser ORB reicht die dann an den ORB des entfernten Objekts Der Aufruf des entfernten Objekts erfolgt mittels Skeletons.
Die zweite Möglichkeit verwendet clientseitig das Invocation Interface (DII) um ohne IDL auch Objekte ansprechen zu können. Hierbei können die dynamisch abgefragt und aufgerufen werden. Serverseitig kann Objekt mittels Dynamic Skeleton Interface (DSI) dynamisch Methodenaufrufe reagieren.
Die Kommunikation zweier ORBs untereinander erfolgte CORBA 1.0 mittels eines herstellerspezifischen Protokolls. Damit ORBs unterschiedlicher Hersteller aufgerufen werden können wurde CORBA 2.0 das General Inter-ORB Protocol (GIOP) das die Kommunikation für verschiedene Transportprotokolle definiert. weitesten verbreitet ist der Einsatz des GIOP TCP/IP das Internet Inter-ORB Protocol (IIOP).
Jedes CORBA-Objekt auch Servant genannt ist einer eindeutigen Adresse ansprechbar der Interoperable Object (IOR).
Zusätzlich zum Protokoll definiert CORBA noch Dienste bzw. Services die eine definierte IDL-Schnittstelle Der wichtigste CORBA-Dienst ist der COS Naming Service der Serverobjekten ermöglicht mittels eines festgelegten angesprochen zu werden. Der Namensdienst liefert dann IOR zu einem registrierten Objektnamen.
Bekannte CORBA-Implementierungen: Orbix Mico ORBit VisiBroker TAO