Common Object Request Broker Architecture
Die Common Object Request Broker Architecture kurz CORBA ist eine objektorientierte Middleware, 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.
CORBA ist nicht an eine bestimmte Programmiersprache gebunden. Mittels einer Interface Definition Language (IDL) erstellt man eine formale Spezifikation der Klassen und Objekte sowie sämtlicher Parameter und Datentypen. Diese Schnittstellenbeschreibung wird dann in ein Objektmodell der verwendeten Programmiersprache umgesetzt. Die breiteste Unterstützung existiert für Java und C++, es existieren jedoch auch Implementierungen für viele weitere Sprachen.
Meist erzeugt ein so genannter IDL-Compiler Stubs und Skeletons, die mit der eigentlichen Programmlogik ergänzt werden. Der lokale Client ruft nun den Stub-Code auf, der die Daten an einen Object Request Broker (ORB) weitergibt. Dieser ORB reicht die Daten dann an den ORB des entfernten Objekts weiter. Der Aufruf des entfernten Objekts erfolgt mittels der Skeletons.
Die zweite Möglichkeit verwendet clientseitig das Dynamic Invocation Interface (DII), um ohne IDL auch unbekannte Objekte ansprechen zu können. Hierbei können die Methoden dynamisch abgefragt und aufgerufen werden. Serverseitig kann das Objekt mittels Dynamic Skeleton Interface (DSI) dynamisch auf Methodenaufrufe reagieren.
Die Kommunikation zweier ORBs untereinander erfolgte in CORBA 1.0 mittels eines herstellerspezifischen Protokolls. Damit auch ORBs unterschiedlicher Hersteller aufgerufen werden 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).
CORBA-Objekte sind Instanzen von Servant-Klassen. Jedes CORBA-Objekt besteht somit aus einer eindeutigen Adresse Interoperable Object Reference (IOR) und einem Servant, der den Zustand und das Verhalten eines CORBA-Objektes repräsentiert.
Nach den Bemühungen von z.B. Microsoft, eine objektorientierte, CORBA-artige Struktur in ihrem Betriebssystem nachzubilden (OLE, COM, dann im Netzwerk DCOM, MTS, COM+ ) sollte die Entwicklung von Web Services CORBA endgültig ablösen. Dies war zuerst aus mehreren Gründen offensichtlich, galt CORBA doch als zu langsam und oftmals nicht kompatibel genug, wenn es um verschiedene Implementierungen und Standards ging. Jedoch wird CORBA seit dem Jahr 2004 wieder vermehrt eingesetzt, was vor allem daran liegt, dass mittlerweile für die netzwerk- und prozessorintensive CORBA-Struktur genug Rechenleistung zur Verfügung steht und ein ORB nicht stateless vorgeht, wie es bei Web Services aufgrund des ihnen zugrunde liegenden http-Protokolls der Fall ist.
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 Ereignis-basierte 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 Standard-konforme Implementierung des Relationship Service sollte Level 1, Level 1 und 2 oder Level 1-3 implementieren.
Ausserdem existieren beispielsweise noch folgende Dienste, für eine Beschreibung sei auf http://www.marclayer.de/stud/proj/cos/CORBAservices.php verwiesen: Externalization Service, Persistent Object Service, Concurrency Control Service, Transaction Service, Property Service, Licensing Service, Object Collection Service, Query Service, Time Service, Security Service,
CORBA-Implementierungen
Orbix, Mico, ORBit, VisiBroker, OmniORB, TAO, MiddCor, OpenORB, JacORB
Siehe auch
RMI, DCOM, SOAP, XML-RPC, Web Service, Grid-Computing, CORBA Component Model, JINI