Der Austausch von Nachrichten zwischen Objekten ist eines der Grundprinzipien in der objekt-orientierten Programmierung. So spricht man zum Beispiel in Smalltalk [GR89] von message passing, wenn Methoden eines Objekts benutzt werden sollen. Allerdings ist damit meist nicht der Versand von Nachrichten über physikalische Netzwerke in verteilten Systemen gemeint, sondern der Aufruf der Methode eines Objekts im gleichen Applikationsprogramm.
Mit dem Nachrichtenaustausch in objekt-orientierten verteilten Systemen beschäftigt sich die Object Management Group (OMG). Von der OMG wurde mit CORBA (Common Object Request Broker Architecture) [OMG95] ein Standard für verteilte objekt-orientierte Systeme definiert. Ein Object Request Broker (ORB) ist ein System, das in Übereinstimmung mit dem CORBA Standard die Programmierung von verteilten Objekten unterstützt. CORBA verkapselt die fehleranfälligen Routinen für den Nachrichtenaustausch in verteilten Applikationen.
Abbildung 3.7: Struktur der ORB Schnittstelle
Abbildung 3.7 zeigt die Struktur der ORB Schnittstelle. Ein Client ist ein Programm, das eine Operation mit einem Objekt ausführen will. Object Implementation enthält die Implementierung eines Objekts, d.h. den Programmcode zur Ausführung von Operationen. Der ORB ist für die Kommunikation zwischen den beiden Systemen verantwortlich. Bei einer Anfrage eines Clients mußder ORB zunächst den Ort der Objektimplementierung herausfinden. Anschließend schickt der ORB die notwendigen Daten zur Objektimplementierung. Die Schnittstelle für den Client ist unabhängig von allen Daten, die nur der Objektimplementierung bekannt sind und nicht in der Schnittstellendefinition beschrieben sind.
Eine Schnittstelle wird in der Interface Definition Language (IDL) beschrieben. Für den Client werden aus Schnittstellendefinition in IDL Stubs generiert, die das Interface des Objekts in die jeweilige Client-Programmiersprache abbilden. Der Client kann die Objektmethoden entweder über die IDL Stubs, über ein dynamisches Interface, das für alle Objekte gleich ist, oder direkt über die ORB Schnittstelle aufrufen. Der ORB leitet die Methodenaufrufe über Skeletons an die Objektimplementierung weiter. Skeletons können auch aus der Objektdefinition in IDL erstellt werden. Die Objektimplementierung kann über den Object Adaptor mit dem ORB kommunizieren.
Die Übertragung der Schnittstellendefinition in IDL auf eine objekt-orientierte Programmiersprache bildet die Objekte in CORBA in entsprechende Objekte der Programmiersprache ab. In Abbildung 3.8 ist die Struktur eines Clients dargestellt.
Abbildung 3.8: Struktur eines ORB Clients
Die sprachabhängigen Objektreferenzen werden auf die ORB Objektreferenzen abgebildet. Für den Zugriff auf die Objektimplementierungen enthält der Client die entsprechenden IDL Stubs der Schnittstellendefinitionen und die dynamische Aufruf-Schnittstelle.
Der Nachrichtenaustausch zwischen den einzelnen Komponenten erfolgt über ein Netzwerk, dessen physische Eigenschaften nicht näher definiert sind. Für Methodenaufrufe gibt es drei mögliche Mechanismen, wie der Nachrichtenaustausch realisiert werden kann [OMG93]:
Bei synchronem Aufruf sendet der Client die Nachricht und wartet bis eine Antwort vom aufgerufenem System zurückkommt. Dieser Mechanismus entspricht dem Aufrufmechanismus in nicht-verteilten Programmiersystemen. Jedoch gibt es bei verteilten Systemen mehr Fehlermöglichkeiten als bei nicht-verteilten Systemen. Bei einem Methodenaufruf, der nachweislich korrekt ist und zu einem Ergebnis führen müßte, kann es im verteilten Systemen trotzdem zu Fehlern durch Hardware- oder Softwarefehler auf entfernten Computern kommen. Deshalb sind in CORBA Ausnahmebehandlungen für solche Fälle integriert.
Bei verzögertem synchronem Aufruf wird die Operation in zwei Phasen unterteilt. Zunächst wird die Nachricht versendet und der Client bekommt einen Identifikator zurück, mit der später nach einem Ergebnis gefragt werden kann. Bei One-Way-Mechanismus wird die Nachricht gesendet, der Client interessiert sich in diesem Fall aber nicht für das Ergebnis der Nachricht. Die Gefahr bei solchen Nachrichten besteht darin, daßder Client nicht weiß, ob die Operationen erfolgreich beendet worden sind oder überhaupt schon bearbeitet sind. In dem Fall, wo der Client ständig One-Way-Nachrichten sendet, kann es auf Serverseite zu einem Verlust von Nachrichten kommen, weil die Operationen nicht schnell genug bearbeitet werden können und die Länge der Nachrichtenwarteschlange begrenzt ist.
Christoph Quix