Common Object Request Broker Architecture

Common Object Request Broker Architecture

Die Common Object Request Broker Architecture (CORBA, englisch für 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 Communities 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. Die Stubs und Skeletons implementieren das Vermittler Pattern als Architekturmuster, um die Komplexität der Netzwerkkommunikation zu verbergen und einen Methodenaufruf wie einen lokalen Aufruf erscheinen zu lassen.

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-Compilers Stubs im Quelltext seiner Programmiersprache. Er kann dann die Instanzen dieser generierten Klassen wie oben erläutert als ganz 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 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. Soll eine Verknüpfung zwischen Java und einer anderen Programmiersprache hergestellt werden, so kann ebenfalls das JNI verwendet werden. Für die Interprozesskommunikation innerhalb von Java selbst wird meist RMI 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. Den internen Aufbau solcher Referenzen bestimmt CORBA nicht und der kann je nach ORB-Hersteller und Programmiersprache anders sein. Damit aber die Kommunikation und der Austausch von Objektreferenzen übergreifend funktioniert, definiert CORBA als Austauschformat die 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

Literatur und Quellen

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

Weblinks


Wikimedia Foundation.

Schlagen Sie auch in anderen Wörterbüchern nach:

  • Common object request broker architecture — CORBA, acronyme de Common Object Request Broker Architecture, est une architecture logicielle, pour le développement de composants et d’Object Request Broker ou ORB. Ces composants, qui sont assemblés afin de construire des applications complètes …   Wikipédia en Français

  • Common Object Request Broker Architecture — Common Object Request Broker Architecture,   CORBA …   Universal-Lexikon

  • Common Object Request Broker Architecture — The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together (i.e., it… …   Wikipedia

  • Common Object Request Broker Architecture — CORBA, acronyme de Common Object Request Broker Architecture, est une architecture logicielle, pour le développement de composants et d’Object Request Broker ou ORB. Ces composants, qui sont assemblés afin de construire des applications complètes …   Wikipédia en Français

  • Common Object Request Broker Architecture —    Abbreviated CORBA. A standard from the Object Management Group (OMG), whose members include SunMicrosystems, Hewlett Packard, DEC, and IBM, that enables communications between distributed object oriented applications, regardless of the… …   Dictionary of networking

  • Common Object Request Broker Architecture — (Internet) (Internet) standard for software interoperability (set of common, object oriented interfaces that can communicate on various platforms), CORBA …   English contemporary dictionary

  • Common Object Request Broker Architecture — …   Википедия

  • Object Request Broker — ORB est le sigle de Object Request Broker (traduction littérale : courtier de requêtes objet). Un ORB est l ensemble de fonctions (classes Java, bibliothèques C++...) qui implémentent un « bus logiciel » par lequel des objets… …   Wikipédia en Français

  • Object Request Broker —    Abbreviated ORB. A communications mechanism used in an object oriented distributed computing environment in which program modules can be written in any programming language and still provide services to other applications.    An object makes a …   Dictionary of networking

  • Object request broker — In distributed computing, an object request broker (ORB) is a piece of middleware software that allows programmers to make program calls from one computer to another via a network. ORBs promote interoperability of distributed object systems… …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”