CORBA beschreibt den Standard der Object Management Architecture (OMA) (siehe Abbildung 2.12), dessen wichtigste Komponente der Object Request Broker (ORB) darstellt. Der Broker ist ein Vermittlungsmechanismus zum Aufruf von Methoden auf entfernten Objekten. Zentraler Bestandteil des ORB ist der Object Bus. Er leitet Methodenaufrufe eines Clients einschließlich Parameter an ein Server-Objekt weiter und gibt umgekehrt Ergebnisse oder Fehler zurück. Als ein weiteres Merkmal übernimmt er die Lokalisierung der Server-Objekte. Auf dem ORB bauen sämtliche Komponenten der OMA auf. Die Object Services stellen eine Zusammenstellung von fundamentalen Diensten dar, die für die Entwicklung von verteilten, objektorientierten Anwendungen benötigt werden. Insgesamt hat die OMG Standards für 16 Dienste veröffentlicht, darunter Funktionen für das Auffinden von Objekten (Naming Service), das Kreieren, Kopieren, Verschieben oder Löschen von Objekten (Life Cicle Service), dem Versand von asynchronen Ereignismeldungen (Event Service) oder der persistenten Speicherung von Objekten (Persistence Service). Die Common Facilities standardisieren unabhängig von einem bestimmten Anwendungsbereich infrastrukturelle Dienste wie dem Information und System Management. An den Standards für die Common Facilities wird nach wie vor gearbeitet [OMG,OH97].
Der ORB vermittelt Nachrichten zum Transport von Methodenaufrufen eines Clients an ein Server-Objekt. Im Gegenzug übermittelt er Ergebnisse oder Fehlermeldungen. Für den Client ist es völlig transparent, wo sich das Server-Objekt physisch befindet. Der Client benötigt lediglich eine Referenz auf den Server, anhand derer der ORB die Objekte lokalisiert. Das impliziert, daß die Server-Objekte ihre Verfügbarkeit beim ORB anmelden. In einem großen Netz können mehrere ORBīs an der Nachrichtenvermittlung beteiligt sein. Zur Kooperation der ORB's untereinander müssen sie sich eines gemeinsamen, standardisierten Protokolls bedienen. Seit der Version 2.0 wird diese Interoperabilität zwischen den ORB's verschiedener Hersteller durch das Internet Inter-ORB Protocol (IIOP) gewährleistet.
Abbildung 2.13 zeigt die Client- und Server-Seiten eines CORBA ORB's. Auf den Kern des ORB's setzen die Objekte, sogenannte Stubs auf Client-Seite und Skeletons auf Server-Seite, auf. Mit IDL definiert CORBA eine eigene Sprache, die unabhängig von einer bestimmten Programmiersprache ist. Sie ähnelt allerdings bekannten Programmiersprachen wie bspw. C oder C++. IDL bietet ausschließlich Konstrukte zur Beschreibung von Attributen, Methoden und Datentypen von Objekten. Die OMG legt über standardisierte language mappings die Abbildung von IDL auf die Implementierungsprache wie Java [Mic,Fla97] oder C++ fest. Mittels dieser Abbildungsvorschrift erzeugt ein IDL-Compiler den Stub oder Skeleton in der jeweiligen Implementierungssprache.
Die Client Stubs sowie die Server Skeletons bilden eine statische Schnittstelle zur Nutzung von Diensten. Aus Sicht des Clients agiert der Stub als ein lokaler Aufruf. Es stellt einen lokalen Proxy für ein verteiltes Server-Objekt dar. Im Gegensatz dazu definiert CORBA das Dynamic Invocation Interface (DII), das es Anwendungen erlaubt, dynamisch zur Laufzeit Dienste vom Server-Objekt in Anspruch zu nehmen. Zu allen registrierten Server-Objekten enthält das Interface Repository (IR) die IDL-Beschreibungen ihrer Schnittstellen. Mit Hilfe dieser Beschreibungen kann ein Client dynamisch über das DII Methodenaufrufe an den Server senden. Das ORB Interface besteht aus einigen wenigen für die Anwendungen interessanten Funktionen. Zum Beispiel stellt CORBA Funktionen zur Verfügung, die Objekt-Referenzen in Strings umwandeln und umgekehrt.
Auf Server Seite ist das Dynamic Skeleton Interface (DSI) das Äquivalent zum DII. Nützlich ist dieses Interface v.a. für die Bildung von generischen Brücken zwischen den ORB's. Das DSI kann entweder statische oder dynamische Aufrufe des Clients empfangen. Der Basic Object Adapter (BOA) hat seinen Platz an der Spitze der zentralen Kommunikationsdienste des ORB. Er nimmt Anfragen für Dienste im Auftrag der Server-Objekte entgegen. Der BOA bietet eine Laufzeitumgebung für die Instantiierung der Server-Objekte, stellt Anfragen an sie und ordnet ihnen Objekt ID's, sogenannte Object References in CORBA, zu. Ebenso registriert der BOA alle von ihm unterstützten Klassen und ihre Instanzen im sogenannten Implementation Repository. CORBA verlangt, daß jeder ORB einen BOA zur Verfügung stellt.
Die Motivation, CORBA statt SNMP für das Management einzusetzen, ergibt sich aus den Vorteilen von CORBA. So beschränkt sich das Management von SNMP auf das Lesen und Schreiben einfacher Variablen. SNMP bietet keine komplexen Datentypen. Die Realisierung von Beziehungen zwischen Objekten kann nur über Indexvariablen bzw. Indextabellen verwirklicht werden. CORBA hingegen erlaubt durch die Sprache IDL eine objektorientierte Modellierung der Ressourcen. Mit IDL lassen sich auch komplexere Datenstrukturen modellieren. Ein weiterer Vorteil ist die Vererbung. Mit ihr lassen sich definierte Informationen und Funktionalitäten wiederverwenden. Im Gegensatz zu SNMP, das Tabellen nur sequentiell auslesen kann, gewährt CORBA einen wahlfreien Zugriff auf die Attribute eines Objekts. Die Beschreibung von CORBA-Objekten in IDL ist unanhängig von der Programmiersprache. Dadurch ermöglicht der ORB den Austausch von Objekten, die in unterschiedlichen Programmiersprachen implementiert worden sind. Die Verwendung von Java als Implementierungssprache erleichtert weitergehend die Entwicklung von portablen Managementanwendungen und deren grafischer Oberfläche. Nicht zuletzt bietet CORBA mit seinem Event Service, der im Kapitel 2.3.1 behandelt wird, ein leistungsstarkes Kommunikationsmechanismus für den Versand von asynchronen Meldungen.