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.

Überblick

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.

Ablauf eines entfernten Aufrufs: siehe CORBA FAQ [1] [[2]].

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 der Fall ist, insofern diese das HTT-Protokoll als Datenübertragungsprotokoll verwenden.

Das Objektmodel 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 [3] verwiesen: Externalization Service, Persistent Object Service, Concurrency Control Service, Transaction Service, Property Service, Licensing Service, Object Collection Service, Query Service, Time Service, Security Service

Implementierungen

Orbix, MICO, ORBit, VisiBroker, OmniORB, TAO, MiddCor, OpenORB, JacORB

Siehe auch

Weblinks