Das Kefk Network Wiki befindet sich im Testbetrieb.
Common Object Request Broker Architecture
Aus Kefk.
Die Common Object Request Broker Architecture kurz CORBA ist eine objektorientierte Middleware, ein sog. Objekt-Broker, die plattformübergreifende Protokolle und Dienste definiert und von der Object Management Group (OMG) entwickelt wird. CORBA vereinfacht das Erstellen verteilter Anwendungen in heterogenen Umgebungen.
Inhaltsverzeichnis |
Überblick
CORBA ist nicht an eine bestimmte Programmiersprache gebunden. Mittels einer Interface Definition Language (IDL) erstellt man eine formale Spezifikation der Klassen, die eine bestimmte Server Anwendung für Remote Zugriffe zur Verfügung stellt. IDL enthält keine Implementationsbeschreibung der entsprechenden Klassen, sondern nur ihre Signaturen. Die Funktionen sind also nicht ausprogrammiert. Diese Schnittstellenbeschreibung wird dann in ein Objektmodell der verwendeten Programmiersprache umgesetzt. Diese Umsetzung geschieht mit Hilfe eines sogenannten IDL-Compilers automatisch. Aus IDL wird dabei Quelltext generiert.
Die Instanzen 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-Implementation 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++-Klassen. Als nächstes leitet er davon seine eigenen Implementationen ab. Damit ist seine Arbeit erledigt. Ein Java-Client-Entwickler bekommt in unserem Beispiel nur die IDL-Schnittstellen des Server-Entwicklers und lässt darauf seinen IDL-Compiler los, der Java-Quelltext erzeugt. 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 gewaltig, da sämtliche Details der Interprozesskommunikation für beide Seiten, also Client und Server verborgen bleiben. Von den Programmiersprachen her unterstützen die meisten CORBA-Implementationen Java und C++. Es existieren jedoch auch Implementierungen für viele weitere Sprachen.
Der Vollständigkeit halber sei erwähnt, dass es auch die Möglichkeit gibt, CORBA ohne IDL zu verwenden. Stichworte sind hierbei Dynamic Invocation Interface (DII) und Dynamic Skeleton Interface (DSI).
Die Kommunikation innerhalb einer CORBA-Implementation – 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 „Mehrsprachigkeit“ mitschleifen muss, fällt dann weg. 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.
Bridges
Mit ihrer Hilfe 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 definiert als eindeutig identifizierbare Entität. 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 Objektreferenz.
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.
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, für eine Beschreibung sei auf [1] verwiesen: 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 sicher keine leicht zu verstehende Technologie, was an dem hohen Abstraktionsgrad des zugrunde liegenden Konzeptes liegt. Andererseits ermöglicht es gerade dieser hohe Abstraktionsgrad, verteilte Anwendungen mit sehr geringem Arbeitsaufwand zu entwickeln. Wie man an den vielen Service-Definitionen sieht, war mit CORBA der ganz große Wurf geplant. Da nur wenige Services 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
Orbix, MICO, IBM, ORBit, VisiBroker, OmniORB, TAO, MiddCor, OpenORB, JacORB, Orbacus
Siehe auch
- CORBA Component Model
- CORBA Tie Mechanismus
- Remote Method Invocation
- Distributed Component Object Model
- SOAP
- XML-RPC
- Web Service
- Grid-Computing
- Jini
- Universal Network Objects
Literatur und Quellen
- Thomas J. Mowbray, William A. Ruh: Inside Corba. Addison Wesley Longman, Amsterdam
Distributed Object Standards and Applications.
Weblinks
- CORBA Dienste
- Object Management Group
- Katalog der OMG-Spezifikationen
- OrbZone – CORBA Community
- MICO – CORBA Implementation für C++
- JacORB – CORBA Implementation in Java
- ORBit2 – CORBA-Schnittstelle für C, C++ und Python
- omniORB – CORBA-Schnittstelle für C++ und Python
- Combat – CORBA-Schnittstelle für TCL und C++
- remoting.corba – CORBA-Schnittstelle für das. NET Framework
- TAO – Bild:50%.png – The ACE ORB, der ACE ORB für C++
- CORBA Explained Simply
 | Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Common_Object_Request_Broker_Architecture, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation. |
