Projektstudium SS98 - distributed computing


Clients und Server als Java Applications

Abbildung 1 illustriert das einfachste Szenario, das Java ORBs verwickelt: Ein Client interagiert mit einem Server. Client und Server sind beide in Java implementiert. Abbildung 1 ist eine abstrakte Repräsentation des Client-Server Modells in Java ORBs. In dieser Grafik sind fünf Komponenten eingezeichnet. Zwei dieser Komponenten sind Java Virtual Machines, die die Ausführung des Client Server Programmes erlauben. Die restlichen drei sind der Client, der Server und der ORB. Der Client kommuniziert mit dem ORB, um eine Anfrage bezüglich dem Aufruf einer Operation an den Server weiterzuleiten. Dieser sendet die Antwort auf die Anfrage via ORB an den Client zurück.

 

 

Abbildung 1: Client Server Modell mit Java ORBs: abstrakte Sicht.

 

Abbildung 2 zeigt eine konkretere Sichtweise von der Weiterleitung einer von einem Client gestellten Anfrage durch den ORB, wobei die hellgrau schattierten Objekte im Diagramm vom ORB bereitgestellt werden. Die folgenden Unterabschnitte beschreiben die Funktionalität dieser Komponenten.

 

Abbildung 2: Client-Server Modell mit Java ORBs: konkrete Sicht

 

Stub und Skeleton Code

Der IDL Compiler generiert diverse Java Klassen, die als Stub Classes für den Client und als Skeleton Classes für den Server bezeichnet werden. Die Rolle der Stub Class ist die, Proxy Objekte auf die der Client Methoden aufrufen kann, bereitzustellen. Diese Proxy Objekt Methoden Implementationen rufen die Operationen der Objekt Implementation, die möglicherweise entfernt lokalisiert sind, auf.

Wenn die Objekt Implementation sich an einem entfernten Ort befindet, ordnet und überträgt das Proxy Objekt die aufgerufene Anfrage. Dies geschieht indem es den Operationsnamen sowie den Typ und die Werte der Argumente der sprachunabhängigen Datenstrukturen in eine lineare Repräsentation, die geeignet für eine Übertragung ist, umwandelt. Der Code, der für das Ordnen und Übertragen der programmdefinierten Datentypen zuständig ist, ist ein wesentlicher Teil des Stub Codes. Das resultierende Form der Anfrage wird zur Objekt Implementation durch Verwendung der speziellen ORB Infrastruktur gesendet. Diese Infrastruktur beinhaltet ein Netzwerktransportmechanismus und zusätzlich Mechanismen zur Lokalisierung der Implmentierungen von Objekten sowie möglicherweise Mechanismen zur Aktivierung des CORBA Server Programmes, das die Implementation anbietet.

Der Skeleton Code verbindet eine Objekt Implmentation, einen CORBA Server und den ORB. Die CORBA Spezifikation läßt viele der Interfaces zwischen dem ORB Kern, der BOA und dem Server Programmen teilweise oder völlig unspezifiziert. Aus diesem Grund besitzen verschiedene ORBs verschiedene Mechanismen für die Verwendung der BOAs zur Aktivierung des Servers und für die Verwendung von Servern zum Informieren der BOA, daß ihre Objekte für den Empfang von aufgerufenen Anfragen bereit sind.

Die Skeleton Klasse implementiert die Mechanismen durch die Anfragen die zum Server gelangen, zur richtigen Methode der richtigen Implementation gelenkt werden. Die Implementation dieser Methoden ist Aufgabe des Anwendungsentwicklers.

 

ORB und BOA Libraries

Die BOA hat ein spezielles Interface zum ORB, das nicht in CORBA standardisiert ist. Dies bedeutet im allgemeinen das die BOA Funktionalität als Teil des gleichen Codes, der für den ORB verwendet wird, teils in Bibliotheken, teils in Stub und Skeleton Code und teils in einem Run-Time Daemon implementiert wird. Die Marshaling Routinen sowohl im Stub als auch im Skeleton Code tauschen aufgerufene Anfragen und Ergebnisse via Netzwerk Verbindung, die durch Verwendung des ORB Bibliothek Codes, der mit CORBA Servern verbunden sein muß, aufgebaut wird. Dieser Code kommuniziert zusätzlich mit dem ORB Run-Time Daemon, dem bekannt ist, welche Server welche Objekte implementieren und Server lokalisieren und/oder aktivieren kann, wenn Anfragen bezüglich ihnen gestellt werden.

Die Information wie Objekte und Server verbunden sind oder wie Java Byte Code Dateien gestartet werden ist im Implementation Repository gespeichert. Dies ist eine CORBA Komponente, deren Existenz zwar vorausgesetzt wird, deren Interface aber nicht spezifiziert und in jedem ORB anders ist.

Abbildung 3 illustriert die Interaktion zwischen Server Programmen, den von ihnen unterstützen Objekt Implementationen und dem ORB Run-Time Daemon.

 

Abbildung 3: Java ORB Server-Seite

 

Wie Abbildung 3 zeigt, unterstützt ein CORBA Server gewöhnlich mehrere CORBA Objekte. Die main Routine des Servers wird zur Erzeugung von CORBA Objekt Instanzen und zur Bestätigung der Verfügbarkeit der Objekte für Clients durch die Verwendung der Operationen object_is_ready () und impl_is_ready (), die durch die Bibliotheksmethoden des BOA Pseudo-Objektes unterstützt werden, verwendet . Es sollte erinnert werden, daß ein Pseudo-Objekt die Implementation einer CORBA Pseudo-IDL Interface Spezifikation in einer ORB-spezifischen Art (gewöhnlich als Bibliotheks Code) ist.

 

nächste Seite 


© Copyright 1998 André Möller, Oliver Mentz & Magnus Wiencke