Common Object Request Broker Architecture

Die CORBA-Spezifikation ist nicht an eine bestimmte Plattform gebunden. Vielmehr sind die Softwarehersteller oder Communitys aufgerufen, auf der Grundlage dieser Spezifikation eigene Object-Request-Broker-Implementierungen zu erstellen. Die meisten Hersteller bieten Implementierungen für mehrere Programmiersprachen und auch Betriebssysteme an. Die gemeinsame Spezifikation ermöglicht dann die Kommunikation von Anwendungen untereinander, die mit unterschiedlichen Programmiersprachen erstellt worden sind, verschiedene ORBs nutzen und auf verschiedenen Betriebssystemen und Hardwareumgebungen laufen können.

Mittels der ebenfalls von der OMG spezifizierten Interface Definition Language (IDL) erstellt der Programmierer eine formale Spezifikation der Schnittstellen (Datentypen und Methodensignaturen), die ein Objekt für entfernte oder lokale Zugriffe zur Verfügung stellt. Die Schnittstellensemantik wird dabei nicht festgelegt. Diese Schnittstellenbeschreibung wird dann mit einem IDL-Compiler in äquivalente Beschreibungen der verwendeten Programmiersprache umgesetzt. Außerdem wird Quelltext generiert, der zu der benutzten ORB-Implementierung passt. Dieser Quelltext enthält Stubs und Skeletons. Sie implementieren das Vermittler-Pattern als Architekturmuster, um die Komplexität der Netzwerkkommunikation zu verbergen und einen Methodenaufruf wie einen lokalen Aufruf erscheinen zu lassen. Ein Stub akzeptiert die gleichen Nachrichten wie das entfernte Objekt, das er repräsentiert. Daher kann er von anderen Objekten wie ein lokales Objekt ihrer Programmiersprache benutzt werden, während die Interprozesskommunikation mit dem entfernten, repräsentierten Objekt in mitgelieferten Bibliotheken der CORBA-Implementierung verborgen bleibt. IDL-Compiler werden häufig vom Hersteller des jeweiligen ORB mitgeliefert.

So definiert z. B. der Entwickler einer C++-Server-Anwendung zuerst seine IDL-Schnittstellen, danach erzeugt er mit Hilfe eines entsprechenden IDL-Compilers C++-Skeleton-Klassen. Als Nächstes erweitert er die Skeletons mit der notwendigen Implementierung der Logik. Damit ist seine Arbeit erledigt. Ein Client-Entwickler benutzt die IDL-Schnittstellen des Server-Entwicklers und erzeugt mittels seines IDL-Compilers Stubs im Quelltext seiner Programmiersprache. Er kann dann die Instanzen dieser generierten Klassen wie oben erläutert als „normale“ Objekte benutzen.

Diese Vorgehensweise reduziert den Arbeitsaufwand in der Client-Server-Entwicklung, da sämtliche Details der Interprozesskommunikation für Client und Server verborgen bleiben. Die meisten CORBA-Implementierungen unterstützen die Programmiersprachen Java und C++. Es existieren jedoch auch Implementierungen für viele weitere Sprachen.

Es gibt auch die Möglichkeit, CORBA ohne IDL zu verwenden. Dafür stehen das Dynamic Invocation Interface (DII) und das Dynamic Skeleton Interface (DSI) zur Verfügung.

Die Kommunikation innerhalb einer CORBA-Implementierung – ORB – erfolgte in früheren CORBA Spezifikationen mittels eines herstellerspezifischen Protokolls. Damit auch ORBs unterschiedlicher Hersteller miteinander kommunizieren können, wurde mit CORBA 2.0 das General Inter-ORB Protocol (GIOP) festgelegt, das die Kommunikation für verschiedene Transportprotokolle definiert. Am weitesten verbreitet ist der Einsatz des GIOP über TCP/IP, das Internet Inter-ORB Protocol (IIOP).

Ebenfalls zur Erstellung von verteilten Anwendungen, die mehrere Programmiersprachen verwenden, eignet sich das von Microsoft entwickelte COM/DCOM. Allerdings muss man dann in der Windows-Welt bleiben. Soll eine Verknüpfung zwischen Java und einer anderen Programmiersprache hergestellt werden, so kann ebenfalls das JNI verwendet werden.

Mittlerweile ist die Performance von CORBA auf dem Stand vergleichbarer Techniken wie RMI. Sie hängt in erster Linie von der Bandbreite und der Latenzzeit des Netzwerkes ab.

Mit Hilfe von Bridges kann eine CORBA-Anwendung an Anwendungen, die RMI oder COM-/DCOM-Schnittstellen zur Verfügung stellen, gekoppelt werden. Das ist unter anderem im Zusammenspiel mit Windows-Anwendungen mit COM-Interface interessant.

Der Objektbegriff der Object Management Group (OMG) unterscheidet sich kaum von anderen computerwissenschaftlichen Definitionen des Wortes „Objekt“: Objekte werden als eindeutig identifizierbare Entität definiert. Im Objektmodell werden neben den Eigenschaften von Objekten auch Typen, Schnittstellen, Operationen und Attribute genauer qualifiziert. Typen dienen dazu, die möglichen Werte von Daten einzugrenzen und diese Eingrenzung zu benennen. Dabei unterscheidet CORBA zwei verschiedene Typengruppen: die einfachen und die konstruierten Typen. Zu den einfachen Typen gehören short, long, float, double, char, boolean, octet, string, enum und any.

Die konstruierten Typen sind struct, sequence und union.

Für eine objektorientierte Sicht benötigt der Entwickler noch eine weitere Form der Daten, nämlich Objektreferenzen. In CORBA identifizieren Objektreferenzen die Objekte innerhalb einer ORB-Domäne. Den internen Aufbau solcher Referenzen bestimmt CORBA nicht und er kann je nach ORB-Hersteller und Programmiersprache unterschiedlich ausfallen. Damit aber die Kommunikation und der Austausch von Objektreferenzen übergreifend erfolgen kann, definiert CORBA als Austauschformat die IOR (= Interoperable Object Reference).

Zusätzlich zum Protokoll definiert CORBA noch einige Dienste bzw. Services, die eine definierte IDL-Schnittstelle besitzen. Der wichtigste CORBA-Dienst ist der Naming Service, der Serverobjekten ermöglicht, mittels eines festgelegten Namens angesprochen zu werden. Der Namensdienst liefert dann die IOR zu einem registrierten Objektnamen. Der Naming Service ist eine Art „Telefonbuch“ für CORBA-Objekte.

Der Trading Service ermöglicht es ebenfalls, Objekte zur Laufzeit zu finden. Allerdings werden Objekte hier über ihre Eigenschaften identifiziert und nicht durch einen Namen. Das Ergebnis einer solchen Suche können auch mehrere Objekte sein.

Der Event Service ermöglicht lose gekoppelte, ereignisbasierte n:m Kommunikation. Der Versand erfolgt asynchron. Beim Push-Modell sendet der Supplier (Anbieter) ein Event (Ereignis) in Form eines beliebigen Objektes zum Consumer (Verbraucher), beim Pull-Modell fordert der Consumer ein Event explizit (u. U. blockierend) an. Event Channels erlauben die Pufferung von Events in FIFO-Reihenfolge. Darüber hinaus ermöglichen sie die gleichzeitige Verwendung unterschiedlicher Kommunikationsmodelle zur Übertragung von Events. So kann ein Consumer etwa ein Event „pullen“, das von einem Supplier in einen Channel „gepusht“ worden ist.

Der Life Cycle Service stellt Operationen zum Kopieren, Verschieben und Löschen von Objekten zur Verfügung. Zusammen mit dem Externalization Service wird damit das Migrieren von Objekten ermöglicht.

Der Relationship Service ermöglicht die Modellierung von Beziehungen zwischen Objekten, wobei diese dabei bestimmte Rollen in der Beziehung übernehmen. Dabei sind drei Level definiert: Grundlegende Beziehungen, Beziehungsgraphen und spezielle Relationen (Enthaltensein-Beziehungen (1:n), Referenz-Beziehungen (n:m)). Eine standardkonforme Implementierung des Relationship Service sollte Level 1, Level 1 und 2 oder Level 1–3 implementieren.

Außerdem existieren beispielsweise noch folgende Dienste: Externalization Service, Persistent Object Service, Concurrency Control Service, Transaction Service, Property Service, Licensing Service, Object Collection Service, Query Service, Time Service, Security Service, Notification Service als Erweiterung zum Event Service.

CORBA ist ein relativ abstraktes Konzept, welches den intuitiven Zugang erschwert. Allerdings ermöglicht der hohe Abstraktionsgrad, verteilte Anwendungen mit sehr geringem Arbeitsaufwand zu entwickeln. Mit seinen vielen Service-Definitionen war CORBA zum Zeitpunkt seiner Entwicklung ein innovatives Konzept mit großem Potenzial. Da nur wenige Services tatsächlich implementiert wurden, hat sich diese Hoffnung nicht erfüllt. Die von Programmiersprachen wie Java, Objective-C oder C# mitgelieferten Bibliotheken bieten heute vieles an, was einst als CORBA-Services definiert wurde, und binden damit den Entwickler an die jeweilige Programmiersprache und die dahinter stehenden Hersteller.

• AdORB - CORBA ORB for Mac OS X and iPhone OS (Eingestellt, letztes Release V1.6 vom 30. Januar 2010[1])
• VisiBroker von Micro Focus International, ursprünglich Borland. (Eingestellt, letztes Release V8.5 vom 31. Januar 2012[2])
• JacORB (Letztes Release 3.9 vom 31. August 2017[3])
• MICO CORBA (Eingestellt, letztes Release 2.3.13 vom 4. September 2008[4])
• omniORB (Letztes Release 4.3.0 vom 9. Januar 2022[5])
• Orbacus (Letztes Release 4.3.5 vom 7. Oktober 2016)[6]
• TAO (Letztes Release 2.5.6 vom 30. Juli 2019[7])

• CORBA Component Model
• Distributed Component Object Model
• Grid-Computing
• Internet Communications Engine
• Jini
• Remote Method Invocation
• SOAP
• Universal Network Objects
• Webservice
• XML-RPC

• Thomas J. Mowbray, William A. Ruh: Inside Corba. Addison-Wesley Longman, Amsterdam
  Distributed Object Standards and Applications.

• Literatur über Common Object Request Broker Architecture im Katalog der Deutschen Nationalbibliothek
• Object Management Group mit dem Katalog der OMG-Spezifikationen
• Der aktuelle CORBA-Standard der OMG Group (PDF, 9,6 MiB)
• The Rise and Fall of CORBA, ein kritischer Artikel, erschienen in den Communications of the ACM

1. AdORB - CORBA ORB for Mac OS X. 30. Januar 2010, abgerufen am 21. Oktober 2019 (englisch).
2. VisiBroker. 31. Januar 2012, abgerufen am 21. Oktober 2019.
3. JacORB. 31. August 2017, abgerufen am 21. Oktober 2019 (englisch).
4. MICO CORBA. 15. Dezember 2008, abgerufen am 21. Oktober 2019 (englisch).
5. omniORB. Abgerufen am 8. Juli 2021.
6. Orbacus. 7. Oktober 2016, abgerufen am 21. Oktober 2019 (englisch).
7. Johnny Willemsen: [tao-announce] ACE 6.5.6 and TAO 2.5.6 available for download. 30. Juli 2019, abgerufen am 21. Oktober 2019.