Object-Request-Broker

Anfrage-Vermittler (Request-Broker) in verteilten Objektmodellen

Die Grundidee hinter einem Object-Request-Broker basiert auf dem Paradigma der Objektorientierung und besteht im Kern darin, Aufrufe eines Objektes an ein anderes über Rechner- (HW/SW-Plattformen), Netzwerk-  und Prozessgrenzen (Betriebssysteme) hinweg transparent zu machen (Abb. 1). In einem sich so ergebenden verteilten Objektsystem interagieren die SW-Objekte so, als wären ihre Methodenaufrufe an andere Objekte lokal. Sie „spüren“ nichts von der Verteilung, von unterschiedlichen Betriebssystemen, Rechnerplattformen und – zumindest in der Grundvision – auch nichts von unterschiedlichen Programmiersprachen. Insofern handelt es sich um eine spezielle Ausprägung der Realisierung von Middleware.

Vereinfacht ausgedrückt besteht die Aufgabe eines Object-Request-Brokers nun darin, die Vermittlungsrolle auszufüllen d.h. den kooperierenden Objekten ein lokales Objektsystem „vorzugaukeln“ und bei Überschreitung der lokalen Grenzen die beiden Objekte so zusammen zu führen, als würden sie lokal kooperieren. So muss der Broker u.a. die Adressen der entfernten Objekte kennen, neben dem eigentlichen Methodenaufruf auch die entsprechenden Anfragedaten übertragen, den entfernten Diensterbringer aufrufen und schließlich die Rückgabewerte wieder an den Aufrufer zurückgeben.

Abb. 1: Vom lokalen zum verteilten Objektsystem

Common Object Request Broker Architecture (CORBA)

Die Object Management Group [OMG] hat zur Umsetzung dieses Konzeptes ein allgemeines Architekturmodell – die Common Object Request Broker Architecture (CORBA) – entwickelt, anhand dessen im Folgenden nun die Funktion eines Object-Request-Brokers näher erläutert werden soll. Anzumerken bleibt an dieser Stelle, dass es sich bei CORBA um eine reine Spezifikation und nicht um lauffähige Software handelt. Die Anbieter von ORB-Middleware setzen diese Spezifikation aber mehr oder weniger genau um, so dass die Orientierung an diesem Architekturmodell hier als sinnvoll erscheint. Abbildung 2 zeigt ein an der OMG-Spezifikation orientiertes, vereinfachtes Schema:

Abb. 2: Anfrage-Vermittlung am Beispiel der Common Object Request Architecture (Corba) [OMG]

Um von der Implementierung von Objekten in spezifischen Programmiersprachen unabhängig zu bleiben, werden in CORBA die Schnittstellen von Methoden (Interfaces) allgemein in einer eigens dafür entwickelten, an die Syntax der Programmiersprache C angelehnten, Schnittstellenbeschreibungssprache (Interface Definition Language IDL) beschrieben. Ausgehend von diesen Schnittstellenbeschreibungen können dann mit entsprechenden – den ORB-Produkten i.d.R. beigefügten – Compiler-Werkzeugen Stellvertreter-Objekte erzeugt werden, die auf Client-Seite Stubs und auf der Server-Seite Skeletons genannt werden. In einem entsprechenden Interface Repository – eine Art Telefonverzeichnis für Methodenschnittstellen – führt der ORB Buch über diese Schnittstellen und ihre Anbieter.

Wendet sich nun ein Anfrager (Client) mit dem Wunsch einer Methodenausführung – für den Aufrufer bleibt dabei im Sinne der Middleware transparent, wo der entsprechende Objekt-Server lokalisiert und wie genau die Methode dort implementiert ist – an das ORB-Interface, übernimmt der ORB dann die Vermittlung. Programmiertechnisch ruft der Client das entsprechende Stellvertreter-Objekt – den Stub – so auf, wie er auch ein lokales Objekt aufrufen würde. Der ORB übernimmt für den Client transparent die Zustellung des Aufrufes über ein entsprechendes Adapter-Interface (Object Adapter) an eine geeignete Implementierung des Objekt-Servers (Object Implementation). Als Pendant zum Stub auf Client-Seite stellt das Skeleton auf Server-Seite den Programmcode zur Verfügung, der dem Server-Objekt einen lokalen Methodenaufruf „vorgaukelt“. Auch dieser Code wird aus der IDL-Schnittstellenbeschreibung mittels Werkzeugen generiert.

Weitere Funktionen und Dienste im ORB-Kern, deren detaillierte Darstellung hier aber zu weit führen würde, sind u.a.:

• Naming-Service (Namensdienst):
  Auffinden von Objekten über ihren symbolischen Namen.
• Event-Service:
  Entkopplung von Client und Server über Ereignisse (asynchrone Kommunikation).
• Transaction-Service:
  Gewährt die Möglichkeit, eine oder mehrere Operationen auf einem oder mehreren Objekten in einer Transaktion zu klammern.
• Implementation-Repository:
  Enthält Informationen über den Aufenthaltsort von Objekten.
• Marshalling:
  Transparentes Zustellen der Methodenaufrufparameter vom Client an den Server und den Methodenergebnissen vom Server zurück an den Client.

Literatur

Britton, Chris ; Bye, Peter: IT Architectures and Middleware: Strategies for Building Large, Integrated Systems. Amsterdam : Addison-Wesley, 2004

Gall, Nick: The Origin (Coining) of the Term "Middleware" http://ironick.typepad.com/ironick/2003/11/the_origin_coin.html (Abruf 16.08.2016)

Kaib, Michael: Enterprise Application Integration. Wiesbaden : Deutscher Universitäts-Verlag, 2002

OMG: "Common Object Request Broker Architecture" http://www.corba.org/ und http://www.omg.org/ (Abruf 16.08.2016)

Autor