- CORBA
-
Die Common Object Request Broker Architecture (CORBA, engl. Allgemeine Architektur für Vermittler von Objekt-Anforderungen) ist eine Spezifikation für eine objektorientierte Middleware, deren Kern ein sog. Object Request Broker, der ORB bildet, und die plattformübergreifende Protokolle und Dienste definiert. Sie wird von der Object Management Group (OMG) entwickelt. CORBA-konforme Implementierungen vereinfachen das Erstellen verteilter Anwendungen in heterogenen Umgebungen.
Inhaltsverzeichnis
Überblick
Die CORBA-Spezifikation ist nicht an eine bestimmte Programmiersprache 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 ORBs, Programmiersprachen und Betriebssystemen erstellt wurden.
Mittels der in CORBA genutzten Interface Definition Language (IDL) erstellt der Programmierer eine formale Spezifikation der Schnittstellen (Daten und Methodensignaturen), die eine bestimmte Serveranwendung für entfernte oder lokale Zugriffe zur Verfügung stellt. Die Funktionen sind also nicht ausprogrammiert. Diese Schnittstellenbeschreibung wird dann mit einem IDL-Compiler in ein Objektmodell der verwendeten Programmiersprache umgesetzt. Diese IDL-Compiler werden dabei von dem Hersteller des jeweiligen ORB mitgeliefert. Aus der IDL wird Quelltext generiert, der zu der jeweiligen ORB-Implementierung passt. Der Quelltext enthält dann die so genannten Stubs und Skeletons. Hier wird ein Architekturmuster verwendet, das so genannte Broker Pattern, welches die Komplexität der Netzwerkschnittstelle vor dem Programmierer verbirgt und einen Methodenaufruf wie einen lokalen Aufruf erscheinen lässt.
Die Stubs dieser generierten Klassen können nun von der Client-Anwendung wie ganz normale lokale Objekte benutzt werden. Die ganze Arbeit bei der Interprozesskommunikation besorgen die generierten Klassen und die von der CORBA-Implementierung mitgelieferten Bibliotheken. 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-Compiler Stubs im Java-Quelltext. Er kann dann die Instanzen dieser generierten Klassen wie oben erläutert als ganz normale Java-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 CORBA 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).
Verwandte Technologien
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. Wird als Programmiersprache nur Java verwendet, wird meist RMI zur Interprozesskommunikation eingesetzt. Der Overhead an Komplexität, den CORBA aufgrund seiner Sprachunabhängigkeit mit sich bringt entfällt dann. Eine weitere Möglichkeit stellen Web Services dar. Sie sind wie CORBA sprach- und plattformunabhängig.
Performance
Mittlerweile ist die Performance von CORBA auf dem Stand vergleichbarer Technologien wie RMI. Sie hängt in erster Linie von der Bandbreite und der Latenzzeit des Netzwerkes ab.
Kompatibilität
Mit Hilfe von Bridges kann eine CORBA-Anwendung an Anwendungen, die RMI oder COM-/DCOM-Schnittstellen zur Verfügung stellen, gekoppelt werden. Das ist vor allem für ältere Windows-Anwendungen mit COM-Interface interessant.
Das Objektmodell von CORBA
Der Objektbegriff der 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.
Die bisher erwähnten Datentypen sind flach. Um zu einer objektorientierten Sicht der Dinge zu kommen, benötigt der Entwickler noch eine weitere Form der Daten, nämlich Objektreferenzen. In CORBA identifizieren Objektreferenzen die Objekte innerhalb einer ORB-Domäne. Welchen Aufbau solche Referenzen haben, bestimmt CORBA nicht, denn die von ihnen repräsentierte Information wird nur im ORB selbst gebraucht. In diesem Fall ist immer die Rede von IOR (= Interoperable Object Reference).
CORBA-Dienste
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 oder ereignisbasierte n:n Kommunikation. Die Aufrufe erfolgen nicht mehr synchron. Beim Push-Modell senden die Server-Objekte die Ergebnisse zum Client, beim Pull-Modell fragen die Clients explizit nach Ereignissen.
Der Life Cycle Service stellt Operationen zum Kopieren (Migrieren), Verschieben und Löschen von Objekten zur Verfügung.
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
Einordnung
CORBA ist ein relativ abstraktes Konzept, was den intuitiven Zugang erschwert. Allerdings ermöglicht es 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 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 Firmen.
Implementierungen
Siehe auch
- CORBA Component Model
- Remote Method Invocation
- Distributed Component Object Model
- SOAP
- XML-RPC
- Web Service
- Grid-Computing
- Jini
- Universal Network Objects
- Internet Communications Engine
Literatur und Quellen
- Thomas J. Mowbray, William A. Ruh: Inside Corba. Addison Wesley Longman, Amsterdam
Distributed Object Standards and Applications.
Weblinks
Wikimedia Foundation.
