Remote Method Invocation

Transkript

1 Remote Method Invocation Remote Method Invocation (RMI) ist Teil der JDK Es wurde entwickelt, um Remote Method Invocation nahtlos über verschieden Java Virtual Machines hinweg zu unterstützen. Damit ist ein Distributed Object Model in die Java Programmiersprache integriert. Ein RMI Objekt ist ein entfernetes Java Objekt, - dessen Methoden von einer anderen Java Virtual Machine aus, auch über ein Netzwerk, aufgerufen werden können. - Dies geschieht im Quellcode in transparenter Weise, so wie bei einem lokalen Java Objekt. Damit ähnelt RMI sehr CORBA. - Wie bei CORBA, kann auch über RMI eine Referenz auf ein Objekt dem entferneten Objekt übergeben werden. RMI ist nicht auf JavaBeans beschränkt. JavaBeans können es jedoch verwenden

2 12.1 Überblick Überblick RMI Klienten wechselwirken mit entfernten Objekten über deren veröffentlichte Schnittstellen. - Sie kommunizieren nie direkt mit den Klassen, die diese Schnittstellen implementieren. Um die Kommunikation zwischen entfernten Objekten transparent zu bewerkstelligen, verwenden die Objekte - Stubs und - Skeletons. Eine Client Objekt möge eine Methode eines Server Objektes aufrufen. - Da das Server Objekt sich in einen anderen Adreßraum befindet, kann dies nicht auf direktem Wege geschehen. - Stattdessen wird die gleichnamige Methode in dem Stub aufgerufen, der den Aufruf über die JVM an das Skeleton auf der entfernten Seite übergibt. - Das Skeleton ruft dann die tatsächliche Methode des Server Objektes auf. Client Maschine Server Maschine Client Server Stub Skeleton Java Virtual Machine (JVM) und RMI System Java Virtual Machine (JVM) und RMI System

3 12.1 Überblick Überblick Stubs Der Stub entspricht einem Remote Proxy (oder Surrogate) im Sinne von (den tatsächlichen) Design Patterns für das Server Objekt. - Dabei ist der Stub ein lokaler Repräsentant für das entfernte Objekt in dem anderen Adreßraum. Der Stub hat drei Aufgaben: - Er hat dieselbe Schnittstelle wie das entfernte Objekt. - Zusammen mit der JVM und dem RMI System serialisiert er sämtliche Parameter des entfernten Methodenaufrufs und sendet diese Informationen zur Server Maschine. - Er empfängt mögliche Ergebniswerte des entfernten Methodenaufrufes und liefert diese an das Client Objekt zurück. Skeletons Auf der Server Seite hat das Skeleton die folgenden Aufgaben: - Es empfängt den entfernten Methodenaufruf und alle damit verbundenen Parameter. Zusammen mit der JVM und dem RMI System deserialisiert er sämtliche Parameter des entfernten Methodenaufrufs. - Es ruft die entsprechende Methode des Server Objektes mit den empfangenen Parametern auf. - Es empfängt mögliche Rückgabewerte, serialisiert diese und sendet sie zurück zur Client Maschine

4 12.1 Überblick Überblick Zur Serialisierung wird die normale Java Objekt Serialisierung verwendet. - Damit können auch Objekte als Parameter gesandt oder als Ergebniswerte empfangen werden. Objekte als lokale Parameter werden immer in Kopie versandt. Dies entspricht praktisch einem call by value. Entfernte Objekte werden als Referenzen behandelt. Es wird nicht deren Implementierung übertragen. RMI stellt neue Schnittstellen und Klassen zur Verfügung, die es erlauben, entfernte Objekte zu finden, sie zu laden und sicher ihre Methoden auszuführen. Zur Zeit stellt RMI nur einen einfachen, nicht persistenten Naming Service zur Verfügung, um entfernte Objekte zu lokalisieren. Weiterhin stellt es einen Class Loader zur Verfügung, mit dessen Hilfe Klienten Stubs vom Server herunterladen können. Verteilte Objekte können komplexere Fehlerzustände erzeugen als lokale. Dazu stellt RMI eine zusätzliche Remote Exception Klasse zur Verfügung

5 12.2 Erstellung von Stubs und Skeletons Erstellung von Stubs und Skeletons Erstellung mit einem Hilfsprogramm, dem RMI Compiler rmic. Woher erhält das Client Objekt die Referenz zu dem richtigen Stub für das entfernte Server Objekt? - Erstens: Registry, welches Namen auf entfernte Objekt Referenzen abbildet. - Unser Server Objekt kann sich z.b. mit dem Namen Divide- Server registrieren. - Zweitens wird ein entferntes Objekt über einen URL benannt, der von dem rmi Protokoll verwendet wird. - Dieser URL hat die Struktur: rmi://host:port/server - Dabei ist host die IP-Adresse oder der Name der Server Maschine, auf der sich das entfernte Objekt befindet. - port ist als Option die Port-Nummer der Registry auf der entfernten Maschine. - server ist der Name des Server Objektes. Wenn also unser Client Objekt den Stub für das entfernte Server Objekt auf der Maschine mit der IP-Adresse a.b.c.d haben möchte, so kann es die dortige Registry nach einer Referenz des URL rmi://a.b.c.d/divideserver fragen. Sobald das Client Objekt die Referenz auf den Stub hat, kann es Methodenaufrufe an den Stub richten

6 12.2 Erstellung von Stubs und Skeletons Entwicklungsprozeß (1/3) 1 Definiere das Remote Interface 2 Implementiere das Interface (.java) 3 javac (.class) 8 Implementiere den Client uses 4 Client Stub (.class) rmic Server Skeleton (.class) Server Klasse (.class) (.java) 5 9 javac Starte RMI Registry 10 (.class) 6 Starte Server Objekte Starte Client 7 Registriere Remote Objects Client Server 1. Definiere das Remote Interface. Das Server Objekt muß seine Dienste als Remote Interface publizieren. Dazu muß es einen Nachfahren der Schnittstelle java.rmi.remote deklarieren. Jede Methode dieses Interfaces muß deklarieren, daß sie möglicherweise die java.rmi.remoteexception wirft. 2. Implementiere das Remote Interface. Die Java Server Klasse, die das obige Interface implementiert. Sie muß Nachfahre von java.rmi.unicastremoteobject sein. 3. Übersetze die Server Klasse

7 12.2 Erstellung von Stubs und Skeletons Entwicklungsprozeß (2/3) 1 Definiere das Remote Interface 2 Implementiere das Interface (.java) 3 javac (.class) 8 Implementiere den Client uses 4 Client Stub (.class) rmic Server Skeleton (.class) Server Klasse (.class) 9 javac (.java) 5 Starte RMI Registry 10 (.class) 6 Starte Server Objekte Starte Client 7 Registriere Remote Objects Client 4. Starte den Stub Compiler. Er wird durch rmic aufgerufen. Parameter ist die entfernte.class Datei. Damit werden Stubs und Skeletons (als.class Dateien) erzeugt. Als Voreinstellung werden sie in dem aktuellen Verzeichnis erzeugt. Also z.b. rmic KlassenName 5. Starte die RMI Registry auf dem Server. Da dies ein nichtpersisteneter naming-service ist, müssen entfernte Objekte immer wieder neu registriert werden. Man kann in jedem Server-Prozeß eine Registry haben oder eine zentrale stand-alone Registry für alle JVM auf einem Server Node. Wir starten die Registry auf unserem Server mit rmiregistry Die Registry Datenbank ist zuächst leer. 6. Starte das Server Objekt. Damit werden Instanzen der Remote Objects erzeugt Server

8 12.2 Erstellung von Stubs und Skeletons Entwicklungsprozeß (1/2) 1 Definiere das Remote Interface 2 Implementiere das Interface (.java) 3 javac (.class) 8 Implementiere den Client uses 4 Client Stub (.class) rmic Server Skeleton (.class) Server Klasse (.class) 9 javac (.java) 5 Starte RMI Registry 10 (.class) 6 Starte Server Objekte Starte Client 7 Registriere Remote Objects Client 7. Registriere die Remote Objects. Methoden der Klasse java.rmi.naming werden dazu verwendet, um einen Namen an ein Server Objekt zu binden. Die Informationen werden in der Registry gespeichert. Nun können die Server Objekte von Klienten angesprochen werden. 8. Schreibe den Client Code. Dies ist wahrscheinlich normaler Java Quelltext. Mit Hilfe der Klasse java.rmi.naming kann das entfernte Objekt gefunden werden. Dessen Methoden können dann über einen Stub, der als Proxy für das entfernte Objekt dient, aufgerufen werden. Stubs werden von rmic erzeugt. 9. Übersetze den Client Code. 10. Starte den Client. Dazu werden die Client Klassen und deren Stubs geladen. RMI ermöglicht es auch, Stub Klassen nach Bedarf von dem Server herunterzuladen. Wer CORBA kennt, stellt viele Ähnlichkeiten fest. Tatsächlich kann man RMI als einen ORB (Object Request Broker) ansehen Server

9 12.3 Grundlegende RMI Interfaces und Klassen Grundlegende RMI Interfaces und Klassen Das gesamte RMI System besteht aus vier Packages java.rmi java.rmi.server java.rmi.dgc java.rmi.registry Funktional kann man RMI in vier Kategorien einteilen: Grundlegende Schnittstellen und Klassen für Nutzer von RMI RMI Naming Service implementiert die Registry RMI Security definiert den neuen RMI Security Manager und die Class Loader Schnittstelle RMI Marshaling definiert low-level Schnittstellen zur Serialisierung und Versenden entfernter Objekte und Stubs Wir beschäftigen uns zunächst mit der ersten Kategorie. Sie definiert die Stubs und Skeletons Infrastruktur zum entfernten Aufruf von Methoden. Weiterhin unterstützt sie die Fehlerbehandlung bei entfernten Zugriffen

10 12.3 Grundlegende RMI Interfaces und Klassen Remote Interface Dieses Interface definiert keine Methoden oder Konstanten. Alle Remote Interfaces müssen Nachfahren der Schnittstelle java.rmi.remote sein, um anzuzeigen, daß sie entfernte Schnittstellen sind. Nur solche Schnittstellen können über RMI aufgerufen werden. Für rein lokale Schnittstellen geht dies nicht. Klasse RemoteObject Nachfahre von java.lang.object im Package java.rmi.server. - Im Grunde die remote Version von Object. - Redefiniert equals(), hashcode(), und tostring(), um das Verhalten für entfernte Objekte anzupassen. Die geerbte Methode getclass() angewandt auf ein entferntes Objekt liefert Informationen über den zugehörigen Stub zurück. Klasse RemoteServer java.rmi.server.remoteserver ist Nachfahre von RemoteObject. Abstrakte Klasse mit Methoden, um entfernte Objekte zu erzeugen und zu exportieren. - getclienthost() liefert die Host Adresse des aufrufenden Klienten. - getlog() liefert den Stream für den RMI call log. - setlog() definiert den Output Stream, in den RMI Calls protokolliert werden

11 12.3 Grundlegende RMI Interfaces und Klassen Klasse UnicastRemoteObject Konkrete Subklasse von RemoteServer. Server Objekte müssen Nachfahren hiervon sein. Sie haben die folgenden Eigenschaften: - Alle Referenzen zu dem entfernten Objekt sind nur so lange gültig, wie der Prozeß, der das entfernte Objekt erzeugt hat, existiert. - Das Transportprotokoll muß TCP sein. - Um Parameter, Aufrufe und Ergebnisse zu übertragen wird ein Stream Protokoll verwendet. exportobject() liefert den passenden Stub für das entfernte Objekt zurück, so daß er als lokaler Proxy von dem Klienten verwendet werden kann. - Klienten können mit dieser Methode Stubs dynamisch herunterladen. clone() erzeugt eine Kopie des entfernten Objektes mit unterschiedlicher Identität. Klasse RemoteStub Alle von dem rmic Compiler generierten Stubs sind Nachfahren dieser Klasse

12 12.3 Grundlegende RMI Interfaces und Klassen Klasse RemoteException Bei einer verteilten Anwendung kann eine Vielzahl von Fehlern auftreten: - Kommunikation zwischen den Maschinen kann gestört sein. - Ein Stub oder Skeleton fehlt. - Es gibt Probleme beim Serialisieren und Deserialisieren der Parameter oder Rückgabewerete. Die Klasse java.rmi.remoteexception ist Nachfahre von IOException und Superklasse für alle Exceptions, die von dem RMI System zur Laufzeit geworfen werden können. Jede Methode in einem remote Interface muß RemoteException in ihrer throw-klausel spezifizieren. Über die getmessage() Methode kann der Grund des Fehlers erhalten werden

13 12.3 Grundlegende RMI Interfaces und Klassen Zusammenhang der RMI Basis Dienste Java.lang Java.io Object IOException Java.rmi Java.rmi.server Remote implements RemoteException getmessage() RemoteObject hashcode() equals() tostring() RemoteServer getclienthost() getlog() setlog() RemoteStub setref() uses UnicastRemoteObject exportobject() clone() MyClient MyServer

14 12.4 Java RMI Naming Service Java RMI Naming Service Bevor Klienten die Methode eines entfernten Objektes aufrufen können, müsen sie zuvor eine Referenz auf dieses Objekt erhalten. Dies geschieht üblicherweise als Rückgabewert eines Methodenaufrufs. RMI stellt aber auch einen Naming Service zur Verfügung, so daß man die Referenz auch über die Angabe eines Namens erhalten kann. Dazu existieren zwei Klassen und eine Schnittstelle: Java.lang Object Java.rmi Remote Registry Java.rmi.registry LocateRegistry getregistry() createregistry() lookup() bind() unbind() rebind() list() Naming lookup() bind() unbind() rebind() list() Die Implementierung des Registry Interfaces ist sehr einfach. - Informationen sind nicht-persistent. - Entfernte Klienten können nur die Methoden lookup() und list() aufrufen. - Um die übrigen Methoden benutzen zu können, muß der Klient auf derselben Maschine wie die Registry laufen

15 12.4 Java RMI Naming Service Schnittstelle Registry Methoden, um Einträge in der Registry zu pflegen und den Inhalt aufzulisten. bind() verbindet ein entferntes Objekt mit einem Namen. rebind() verbindet mit einem in der Registry eventuell schon existierenden Namen ein (möglicherweise anderes) Objekt. Indem man immer rebind() verwendet, vermeidet man eine Already- BoundException. Mit lookup() erhält man eine Referenz auf das mit einem Namen verbundene Objekt. - Ist das Objekt ein entferntes, muß es mit seinem remote Interface ge-casted werden. Mit unbind() wird eine bestehende Verknüpfung aufgehoben. list() liefert ein Array of Strigs mit allen in der Registry bekannten Namen. Klasse LocateRegistry Mit Hilfe einer Reihe von überladenen statischen Methoden getregistry() kann mein eine bestimmte Registry auf einem Host finden. Mit createregistry() kann ein neues Registry Objekt erzeugt werden

16 12.4 Java RMI Naming Service Klasse Naming java.rmi.naming stellt drei Methoden zur Verfügung, um Namen mit entfernten Objekten zu verbinden: static void bind(string name, Remote robj) throws AlreadyBoundException, MalformedURLException static void rebind(string name, Remote robj) throws RemoteException static void unbind(string name) throws MalformedURLException, NotBoundException, RemoteException rebind() kann einen schon registrierten Namen wiederverwenden. Der Parameter name entspricht dabei der URL Syntax: rmi://host:port/name Defaults: host: Current Host port: 1099 name in dem URL ist der Name des entfernten Objektes. Weiterhin gibt es eine Methode, um die Referenz auf ein entferntes Objekt zu erhalten: static Remote lookup(string url) throws MalformedURLException, NotBoundException, RemoteException, UnknownHostException url ist ein String, der die URL nach dem RMI-Protokol darstellt. Meistens wird man nur mit der Klasse Naming arbeiten

17 12.5 Eine einfache Client/Server Anwendung Einfache Client/Server Anwendung (1/5) Die Anwendung dient der Division zweier Gleitkommazahlen auf dem Server und der Rückgabe des Ergebnisses. Nachfahre des Remote Interfaces Das remote Interface, das der Server zur Verfügung stellt. Das Interface muß Nachfahre von Remote sein. Es stellt die Methode divide() zur Verfügung. Jede entfernte Methode muß eine RemoteException werfen können. // File DivideServer.java package divide; import java.rmi.*; public interface DivideServer extends Remote { double divide(double d1, double d2) throws RemoteException;

18 12.5 Eine einfache Client/Server Anwendung Einfache Client/Server Anwendung (2/5) Implementierung des Remote Interfaces Alle remote Objects müssen Nachfahren der Klasse UnicastRemoteObject sein und die entsprechende Schnittstelle implementieren, hier DivideServer. // File DivideServerImpl.java package divide; import java.rmi.*; import java.rmi.server.*; public class DivideServerImpl extends UnicastRemoteObject implements DivideServer { public DivideServerImpl() throws RemoteException { public double divide(double d1, double d2) throws RemoteException { return d1 / d2;

19 12.5 Eine einfache Client/Server Anwendung Einfache Client/Server Anwendung (3/5) Hauptprogramm des Servers Hauptaufgabe ist es, eine Instanz des für den Klienten entfernten Objektes zu erzeugen und dieses dem Naming Service bekannt zu machen. Hier wird dazu die rebind() Methode benutzt. Die Registrierung geschieht auf dem Current Host unter Verwendung des Default Ports Daher muß als URL nur der Name des Objektes angegeben werden. // File DivideServerApp.java package divide; import java.net.*; import java.rmi.*; public class DivideServerApp { public static void main(string args[]) { // create and install the security manager System.setSecurityManager(new RMISecurityManager()); try { DivideServerImpl divideserverimpl; divideserverimpl = new DivideServerImpl(); Naming.rebind("DivideServer", divideserverimpl); catch(exception ex) { ex.printstacktrace();

20 12.5 Eine einfache Client/Server Anwendung Einfache Client/Server Anwendung (4/5) Client Anwendung (1/2) Drei Aufrufparameter: - Name oder IP-Adresse der Server-Maschine. - Dividend und Divisor Konstruiere URL String. - Name des entfernten Objektes: DivideServer. lookup() liefert eine Referenz auf das entfernte Objekt. Rückgabetyp Remote wird zu DivideServer umgewandelt. divideserver dient dann als Referenz auf das entfernte Objekt. // File DivideClient.java package divide; import java.rmi.*; public class DivideClient { public static void main(string args[]) { // create and install the security manager System.setSecurityManager(new RMISecurityManager()); try { // Make rmi URL to name DivideServer String divideserverurl; divideserverurl = "rmi://" + args[0] + "/DivideServer"; // Obtain a reference to that remote object DivideServer divideserver; divideserver = (DivideServer)Naming.lookup( divideserverurl); // Display numbers System.out.println("The first number is: " + args[1]); double d1 = Double.valueOf(args[1]).doubleValue(); System.out.println("The second number is: " + args[2]); double d2 = Double.valueOf(args[2]).doubleValue();

21 12.5 Eine einfache Client/Server Anwendung Einfache Client/Server Anwendung (5/5) Client Anwendung (2/2) // Invoke remote method and display result double result = divideserver.divide(d1, d2); System.out.println("The result is: " + result); catch(exception ex) { ex.printstacktrace();

22 12.5 Eine einfache Client/Server Anwendung Erstellen der verteilten Anwendung (1/2) Übersetze die vier Quelldateien mit javac. Generiere Stubs und Skeletons mit rmic für das entfernte Objekt DivideServerImpl: rmic d. divide.divideserverimpl OPtion d spezifiziert das Wurzel-Verzeichnis für die Java Klassen. Hier ist es das augenblicklich aktive Verzeichnis. Dieses Kommando erzeugt die Dateien DivideServerImpl_Skel.class und DivideServerImpl_Stub.class Kopiere die.class Dateien. Wir haben jetzt sechs.class Dateien. Aus Gründen der Einfachheit kopieren wir alle sowohl auf den Server als auch auf den Client, auch wenn nicht überall alle Dateien benötigt werden. Zum Testen auf nur einer Maschine kann als Server-Maschine auch die lokale Maschine mit der IP-Adresse angegeben werden. Starte das RMI Registry auf der Server-Maschine mit der Eingabe von start rmiregistry in einer DOS-Box. Ein leeres Fenster erscheint. Starte die Server Anwendung durch java divide.divideserverapp Erzeugt das DivideServerImpl Objekt und registriert es. Starte den Klienten durch java divide.divideclient server1 8 2 oder (lokal) durch java divide.divideclient

23 12.5 Eine einfache Client/Server Anwendung Erstellen der verteilten Anwendung (2/2) Als Ergebnis erhält man: The first number is: 8 The second number is: 2 The result is: 4.0 Sequenz-Diagramm Client Server DivideClient System Naming System DivideServerApp setsecuritymanager() DivideServerImpl new setsecurity Manager rebind() lookup() divide() Proxy Server (Stub) divide()

24 12.6 Objekte als Argumente und Rückgabewerte Objekte als Argumente und Rückgabewerte Löseung einer quadratischen Gleichung. Wir übergeben die Koeffizienten wieder als primitive Datentypen. Das Ergebnis in Form zweier komplexer Zahlen lassen wir uns jedoch als ein Objekt zurückgeben. Wie geschieht das? Remote Objekte (solche, die die Schnittstelle Remote implementieren) werden als Referenz übergeben, lokale Objekte immer als Wert. Wir wollen die Gleichung ax 2 + bx + c = 0 lösen. Die beiden Lösungen sind: d = Math.sqrt(b*b 4*a*c); x0 = ( b+d)/(2*a); x1 = ( b d)/(2*a); x0 und x1 sind komplexe Zahlen. Wir gehen vor wie in dem vorigen Beispiel:

25 12.6 Objekte als Argumente und Rückgabewerte Objekt als Rückgabewert (1/5) Remote Interfaces Die Methode solve() der Schnittstelle QuadraticServer hat drei double Parameter und liefert ein Array aus zwei Objekten der Klasse Complex zurück. // File QuadraticServer.java package quadratic; import java.rmi.*; public interface QuadraticServer extends Remote { Complex[] solve(double a, double b, double c) throws RemoteException;

26 12.6 Objekte als Argumente und Rückgabewerte Objekt als Rückgabewert (2/5) Klasse Complex Kapselt den Real- und Imaginärteil eine komplexen Zahl. tostring() liefert ein String Objekt, das die komplexe Zahl darstellt. Die Klasse muß die Schnittstelle Serializable implementieren, da sonst Objekte der Klasse nicht als Ergebnis geliefert werden können. // File Complex.java package quadratic; import java.io.*; public class Complex implements Serializable { private double real, imaginary; public Complex(double real, double imaginary) { this.real = real; this.imaginary = imaginary; public String tostring() { String sr = "" + real; String si = "" + imaginary; if(si.startswith("-")) { return sr + si + "i"; else { return sr + "+" + si + "i";

27 12.6 Objekte als Argumente und Rückgabewerte Objekt als Rückgabewert (3/5) Implementierung des Remote Interfaces Dies funktioniert bis auf die zusätzliche Mathematik wie im vorigen Beispiel. // File QuadraticServerImpl.java package quadratic; import java.rmi.*; import java.rmi.server.*; public class QuadraticServerImpl extends UnicastRemoteObject implements QuadraticServer { public QuadraticServerImpl() throws RemoteException { public Complex[] solve(double a, double b, double c) throws RemoteException { Complex roots[] = new Complex[2]; double d = b * b - 4 * a * c; if(d > 0) { d = Math.sqrt(d); roots[0] = new Complex((-b + d)/(2 * a), 0); roots[1] = new Complex((-b - d)/(2 * a), 0); else { d = Math.sqrt(-d); double e = -b/(2 * a); double f = d/(2 * a); roots[0] = new Complex(e, f); roots[1] = new Complex(e, -f); return roots;

28 12.6 Objekte als Argumente und Rückgabewerte Objekt als Rückgabewert (4/5) Hauptprogramm des Servers Auch das wie gehabt: // File QuadraticServerApp.java package quadratic; import java.rmi.*; public class QuadraticServerApp { public static void main(string args[]) { // create and install the security manager System.setSecurityManager(new RMISecurityManager()); try { QuadraticServerImpl quadraticserverimpl; quadraticserverimpl = new QuadraticServerImpl(); Naming.rebind("QuadraticServer", quadraticserverimpl); catch(exception ex) { ex.printstacktrace();

29 12.6 Objekte als Argumente und Rückgabewerte Objekt als Rückgabewert (5/5) Client Anwendung 4 Aufrufparameter: Name oder IP-Adresse des Servers und 3 Koeffiz. package quadratic; import java.rmi.*; public class QuadraticClient { public static void main(string args[]) { // create and install the security manager System.setSecurityManager(new RMISecurityManager()); try { // Make rmi URL to name QuadraticServer String quadraticserverurl; quadraticserverurl = "rmi://" + args[0] + "/QuadraticServer"; // Obtain a reference to that remote object QuadraticServer quadraticserver; quadraticserver = (QuadraticServer)Naming.lookup(quadraticServerURL); // Display coefficients double a = Double.valueOf(args[1]).doubleValue(); double b = Double.valueOf(args[2]).doubleValue(); double c = Double.valueOf(args[3]).doubleValue(); System.out.println("The coefficients are:"); System.out.println("\ta = " + a); System.out.println("\tb = " + b); System.out.println("\tc = " + c); // Invoke remote method and display results Complex results[] = quadraticserver.solve(a, b, c); System.out.println("The results are:"); System.out.println("\t" + results[0]); // use tostring() System.out.println("\t" + results[1]); catch(exception ex) { ex.printstacktrace();

30 12.6 Objekte als Argumente und Rückgabewerte Erstellen der verteilten Anwendung Übersetze die fünf Quelldateien mit javac. Generiere Stubs und Skeletons rmic d. divide.quadraticserverimpl Erzeugt die Dateien QuadraticServerImpl_Skel.class, QuadraticServerImpl_Stub.class Kopiere die.class Dateien. Wir haben jetzt sieben.class Dateien. Wieder kopieren wir aus Gründen der Einfachheit alle sowohl auf den Server als auch auf den Client. Starte das RMI Registry auf der Server-Maschine start rmiregistry Starte die Server Anwendung durch java quadratic.quadraticserverapp Erzeugt das QuadraticServerImpl Objekt und registriert es. Starte den Klienten durch java quadratic.quadraticclient server oder (lokal) durch java quadratic.quadraticclient Ergebnis: The coefficients are: a = 8.0 b = 2.0 c = 7.0 The results are: i i

31 12.7 Broadcast Anwendung Broadcast Anwendung (1/7) Anwendung mit bi-direktionalen entfernten Methodenaufrufen. Klienten registrieren sich bei einer Broadcast Anwendung, von der sie dann Botschaften empfangen. Dazu benötigen wir zwei remote Interfaces. Klienten implementieren das eine, um die Messages zu empfangen, der Server implementiert das andere, mit Hilfe dessen die Klienten sich als Listener registrieren können. Sechs Quelldateien. Broadcast Server Definiert das remote Interface, das der Server implementieren muß. package broadcast; import java.rmi.*; public interface BroadcastServer extends Remote { void addbroadcastlistener(broadcastlistener bl) throws RemoteException; void removebroadcastlistener(broadcastlistener bl) throws RemoteException;

32 12.7 Broadcast Anwendung Broadcast Anwendung (2/7) Broadcast Listener Schnittstelle für die Clients, um Broadcast Ereignisse zu empfangen. package broadcast; import java.rmi.*; public interface BroadcastListener extends Remote { public void receivebroadcast(string message) throws RemoteException; Klasse BroadcastServerImpl (1/3) Implementierung des remote Interfaces des Servers. Referenzen der Clients, die sich registrieren, werden in dem Vector listeners gehalten. Listener, die Probleme bereiten, werden aus der Liste der Listeners entfernt. package broadcast; import java.io.*; import java.rmi.*; import java.rmi.server.*; import java.util.*; public class BroadcastServerImpl extends UnicastRemoteObject implements BroadcastServer, Runnable { private Vector listeners; private Thread thread; public BroadcastServerImpl() throws RemoteException { listeners = new Vector(); thread = new Thread(this); thread.start();

33 12.7 Broadcast Anwendung Broadcast Anwendung (3/7) Klasse BroadcastServerImpl (2/3) public void addbroadcastlistener(broadcastlistener bl) throws RemoteException { listeners.addelement(bl); public void removebroadcastlistener(broadcastlistener bl) throws RemoteException { listeners.removeelement(bl); public void run() { try { InputStreamReader isr; isr = new InputStreamReader(System.in); BufferedReader br; br = new BufferedReader(isr); while(true) { String p = "Enter the message to be broadcast:"; System.out.println(p); String s = br.readline(); if(s == null) { return; sendmessage(s); catch(exception ex) { ex.printstacktrace();

34 12.7 Broadcast Anwendung Broadcast Anwendung (4/7) Klasse BroadcastServerImpl (3/3) protected void sendmessage(string message) { // v1 = a clone of the listeners vector // v2 = a new vector Vector v1, v2; synchronized(this) { v1 = (Vector)listeners.clone(); v2 = new Vector(); // Broadcast the message to these listeners Enumeration e1 = v1.elements(); while(e1.hasmoreelements()) { BroadcastListener bl; bl = (BroadcastListener)e1.nextElement(); try { bl.receivebroadcast(message); catch(exception ex) { v2.addelement(bl); // Remove listeners that caused exceptions Enumeration e2 = v2.elements(); while(e2.hasmoreelements()) { listeners.removeelement(e2.nextelement());

35 12.7 Broadcast Anwendung Broadcast Anwendung (5/7) Klasse BroadcastListenerImpl Hier wird das remote Interface des Klienten implementiert. Es gibt einfach die empfangene Message aus. package broadcast; import java.rmi.*; import java.rmi.server.*; public class BroadcastListenerImpl extends UnicastRemoteObject implements BroadcastListener { public BroadcastListenerImpl() throws RemoteException { public void receivebroadcast(string message) throws RemoteException { System.out.println("Message = " + message);

36 12.7 Broadcast Anwendung Broadcast Anwendung (6/7) Klasse BroadcastServerApp Hauptprogramm für die Server-Maschine. package broadcast; import java.net.*; import java.rmi.*; public class BroadcastServerApp { public static void main(string args[]) { // create and install the security manager System.setSecurityManager(new RMISecurityManager()); try { BroadcastServerImpl bsi; bsi = new BroadcastServerImpl(); Naming.rebind("BroadcastServer", bsi); catch(exception ex) { ex.printstacktrace();

37 12.7 Broadcast Anwendung Broadcast Anwendung (7/7) Klasse BroadcastClient Implementiert die Client-Seite. Hat ein Kommandozeilen-Argument: Die IP-Adresse des Servers. Zunächst wird wie üblich die Referenz auf den Server über den Naming Service gesucht. Dann wird eine Instanz des Broadcast Listeners erzeugt und als statische Variable gespeichert. Anschließend wird diese Instanz als Listener bei der entfernten Ereignisquelle registriert. package broadcast; import java.rmi.*; public class BroadcastClient { private static BroadcastListenerImpl bli; public static void main(string args[]) { // create and install the security manager System.setSecurityManager(new RMISecurityManager()); try { // Make rmi URL to BroadcastServer String broadcastserverurl; broadcastserverurl = "rmi://" + args[0] + "/BroadcastServer"; // Obtain a reference to that remote object BroadcastServer broadcastserver = (BroadcastServer)Naming.lookup(broadcastServerURL); bli = new BroadcastListenerImpl(); broadcastserver.addbroadcastlistener(bli); catch(exception ex) { ex.printstacktrace();

38 12.8 Dynamisches Laden von Stubs Dynamisches Laden von Stubs Dynamic Stub Loading RMI erweitert Javas dynamisches Laden von Klassen auf Stubs. - Damit können Klienten dynamisch Stubs herunterladen, die entfernte Objekte auf dem Server referenzieren. - Dieses just-in-time Herunterladen von Stubs wird als Dynamic Stub-Loading bezeichnet. Im Extremfall könnte der Stub-Code on-the-fly auf dem Server generiert und dann heruntergeladen werden. Ein Stub wird gebraucht, wenn ein Client ein remote Interface aufrufen möchte. - Dasselbe gilt, wenn als Ergebnis ein entferntes Objekt geliefert wird. - Um darauf zugreifen zu können, wird ebenfalls ein passender Stub gebraucht. - Ist kein passender Stub auf der lokalen Maschine, ist Dynamic Stub-Loading die einzige Alternative. Natürlich ist das Herunterladen beliebiger Klassen, um dann ihre Methoden aufzurufen, ein enormes Sicherheitrisiko

39 12.8 Dynamisches Laden von Stubs Dynamisches Laden von Stubs Den Stub finden RMIs Dynamic Stub-Loading braucht drei Funktionen: - Einen Java Class Loader, - einen Security Manager und - einen Objekt-Serialisierungsmechanismus, um Klassen zu übertragen. Bei einer Anforderung, eine Stub dynamisch zu laden, wird zunächst in dem lokalen Dateisystem nach dem Stub gesucht (CLASSPATH?). Wird er da nicht gefunden, muß RMI wissen, wo es den Stub finden kann. Dies kann auf zwei verschiedene Arten geschehen: - Der Server teilt dem Client mit, wo er den Stub finden kann, indem er den URL des Stub als Teil der Objekt-Referenz mitschickt. Dazu muß die java.rmi.server.codebase Eigenschaft des Server- Systems entsprechend gesetzt sein. - Als zweite Möglichkeit werden Stubs von einem URL geladen, der in der java.rmi.server.codebase Eigenschaft des Client-Systems gespeichert ist. Wie teilen RMI Server ihren Clients mit, wo diese die Stubs finden können? - Dies geschieht mittels RMI Marshaling. - Wenn eine entfernte Objekt Referenz innerhalb einer Message als Parameter gesandt wird, kann zusammen damit eine URL geschickt werden, die dem Client sagt, wo er den Stub finden kann. - Der Marshaling Stream enthält zusätzlich diese Information

40 12.8 Dynamisches Laden von Stubs Dynamisches Laden von Stubs Den Stub finden (1) RMI Client MyInterface mi;... mi = (MyInterface)Naming.lookup( "//theserver/objecttoget"); Naming.lookup (2) Erzeuge neue Instanz der "well-known" Stub- Klasse für rmiregistry, welches auf theserver läuft (3) Rufe lookup(objecttoget) der Registry unter Verwendung der Referenz aus (2) (4) Die Registry liefert eine remote reference für objecttoget zurück (5) Naming.lookup liefert die remote reference für objecttoget rmiregistry Beim Aufruf von Naming.lookup() (1) sieht man, wie ein Client die Referenz auf den remote Server erhält. Alle Aufrufe entfernter Methoden können remote references zurückliefern. Die geschieht beim Aufruf von Naming.lookup(). - Es verwendet zunächst einen well-known Stub (2), um einen remote call zu rmiregistry auf dem Server durchzuführen (3). - Diese Aufruf liefert eine remote reference auf das gewünschte Objekt zurück (4). - Jede remote reference enthält den Host-Namen des Servers und die Port-Nummer, so daß der Client die VM kontaktieren kann, die das entfernte Objekt bedient. Sobald der RMI Client die remote reference hat (5), kann er Host- Namen und Port-Nummer verwenden, um eine Socket-Verbindung zu dem entfernten Server aufzubauen

41 12.8 Dynamisches Laden von Stubs Dynamisches Laden von Stubs Security Manager Jedes Laden einer Klasse über ein Netz muß von einem Security Manager kontrolliert und ggf. eingeschränkt werden. Ein Server lädt üblicherweise seine Klassen von der Server- Maschine. - Aber auch er kann die Referenz eines entfernten Objektes als Parameter erhalten. - Dann wird er für diesen Fall zum Client und unterliegt denselben Restriktionen. RMI erlaubt es, einige Eigenschaften zu definieren, die die Politik des Ladens von anderen Maschinen bestimmen: - Können entfernte Klassen überhaupt auf einen Server geladen werden, - oder nur von bestimmten Lokationen her. Die beiden Klassen RMIClassLoader und RMISecurityManager implementieren diese Dinge. Der Security Manager muß zuallererst in einem Java Programm gestartet werden, bevor eine entfernte Klasse geladen werden kann. - Er kontrolliert dann alle entfernten Ladevorgänge

42 12.8 Dynamisches Laden von Stubs Security Manager Mit Hilfe der SecurityManager Klasse kann einen Anwendung ihre eigenen Sicherheitsregeln implementieren. - Sie erlaubt es einer Anwendung, noch bevor sie eine möglicherweise unsichere oder sensible Operation durchführt, zu überprüfen, ob dies erlaubt ist. - Die Anwendung kann die Operation erlauben oder verbieten. Die Klasse SecurityManager enthält viele Methoden, deren Name mit check beginnt. - Diese Methoden werden von vielen Methoden der Java Bibliotheken aufgerufen, bevor diese eine möglicherweise unsichere Methode aufrufen. SecurityManager security = System.getSecurityManager(); if (security!= null) { security.checkxxx(argument,... ); Damit hat der Security Manager die Chance, diese Operation zu unterbinden. Dazu wirft er eine Exception. - Ein Security Manager kehrt einfach zu der rufenden Methode zurück, wenn die Operation erlaubt ist. - Anderenfalls wirft er eine SecurityException. Der gültige Security Manager wird durch die Methode setsecuritymanager() der Klasse System gesetzt. Der zur Zeit gültige Security Manager kann durch die Methode getsecuritymanager() erhalten werden

43 12.8 Dynamisches Laden von Stubs Einfacher Class File Server Original ReadMe-Datei (1/2) ClassFileServer is an implementation of a mini-webserver that can be used by an RMI application to load classes over the network. Typically, RMI uses an HTTP server to load files from a URL. The ClassFileServer provides the same basic functionality. In order to run the class server, compile the java files and run the server, specifing the port on which you want the server to run and the classpath where the server locates class files, e.g.: (Solaris) % java examples.classserver.classfileserver 2001 /home/ann/classes (Windows) C:> start java examples.classserver.classfileserver 2001 /home/ann/classes When you start up your RMI server, the codebase URL you supply simply needs to be a URL containing the host and port that the class server runs on (since the classpath root is specified when you start up the ClassFileServer, see above), e.g.: (Solaris) % java -Djava.rmi.server.codebase= MyRMIServer (Windows) C:> start java -Djava.rmi.server.codebase= MyRMIServer

44 12.8 Dynamisches Laden von Stubs Einfacher Class File Server Original ReadMe-Datei (2/2) You can embed your own class server inside your RMI server application instead of running one separately. In your server, simply create a ClassFileServer and supply the appropriate port number and classpath: import examples.classserver.classfileserver; //... new ClassFileServer(port, classpath); Read the documentation for the ClassFileServer "Main" method for more info on how to run or embed a ClassFileServer in your application

45 12.9 Remote Object Activation Remote Object Activation Mit dem JDK 1.2 erhält RMI einige Neuerungen. Diese erleichtern es, in Zukunft RMI mit CORBA zu verbinden. Eine dieser Neuerungen ist Remote Object Activation. Dies ist ein Activation Framework, das ebenfalls dem von CORBA ähnelt. Ausgangspunkt ist, daß man nicht Unmengen von Server Objekten ständig aktiv haben kann. - Der Server sollte also in der Lage sein, einige Objekte zu deaktivieren, damit andere ausgeführt werden können. - Für Klienten sollte das aber transparent sein. - Sie sollen glauben, alle Server Objekte seien ständig aktiv. Mit der neuen RMI Version des JDK 1.2 können Klienten in transparenter Weise Server Objekte reaktivieren. - Daraufhin re-initiiert der RMI ORB die Ausführung des Objektes innerhalb der passenden Java VM. Dabei verwendet RMI eine sog. lazy activation. - D.h. Objekte werden erst dann aktiviert, wenn sie von dem Klienten das erste Mal gebraucht werden. Die Objekt-Referenz enthält einen unique identifier, der auf ein ActivationDesc Objekt zeigt. Dies ist ein serialisierbares Objekt, das das folgende enthält: - Einen Group-ID, der die VM spezifiziert, in dem das Objekt aktiviert werden muß. - Den Klassennamen des Objektes. - Eine java.security.codesource Instanz, die angibt, von wo der Code der Objekt-Klasse geladen wird. - Einige objektspezifische Daten (in marshaled Form), z.b. den Namen der Datei, die die Daten des Objektes enthält

46 12.9 Remote Object Activation Remote Object Activation Der Activator lädt die Klasse des Objektes und instanziiert dann das Objekt selbst unter Verwendung eines speziellen Konstruktors, der mehrere Parameter aufnimmt, u.a. den zuvor registrierten Activation Descriptor. Konkret wird dazu die - Klasse java.rmi.activation.activatable und - der RMI daemon rmid verwendet. Programme registrieren Informationen über die Implementierung entferneter Objekte, die on demand erzeugt und ausgeführt werden sollen, statt ständig aktiv sein zu müssen. Der RMI daemon rmid stellt eine JVM zur Verfügung, von der andere JVM Instanzen hervorgebracht (spawned) werden können

47 12.9 Remote Object Activation Erzeuge aktivierbare Klasse Die Schritte, um eine activatable Klasse und zugehörige Anwendung zu erzeugen: Remote Interface Wie bisher: package activation; import java.rmi.*; public interface MyRemoteInterface extends Remote { public Object callmeremotely() throws RemoteException;

48 12.9 Remote Object Activation Erzeuge aktivierbare Klasse Implementierung des Remote Interface Hier ist zusätzlich das Package java.rmi.activation zu importieren. Die Klasse muß Nachfahre von Activatable sein. Der Constructor hat zwei Argumente. package activation; import java.rmi.*; import java.rmi.activation.*; public class ActivatableImplementation extends Activatable implements activation.myremoteinterface { // The constructor for activation and export; // this constructor is called by the method // ActivationInstantiator.newInstance during // activation, to construct the object. public ActivatableImplementation(ActivationID id, MarshalledObject data) throws RemoteException { // Register the object with the activation system // then export it on an anonymous port super(id, 0); // Implement the method declared in MyRemoteInterface public Object callmeremotely() throws RemoteException { return "Success";

49 12.9 Remote Object Activation Erzeuge aktivierbare Klasse Setup -Klasse (1/3) Hier werden alle Informationen zusammengestellt, um die Klasse aktivieren zu können, ohne daß gleich eine Instanz des entfernten Objektes erzeugt wird. Die Informationen werden an den RMI Daemon rmid übergeben. Bei rmiregistry wird eine remote reference (Instanz der zu der aktivierbaren Klasse gehörigen Stub Klasse) und ein Identifier (Name) registriert. Danach kann das Objekt sich beenden. Sieben Detailschritte: 1. Importiere Packages 2. Installiere den Security Manager 3. Erzeuge eine Instanz der Klasse ActivationGroup 4. Erzeuge eine Instanz der Klasse ActivationDesc 5. Deklariere eine Instanz des remote interface und registriere es bei rmid. 6. Binde den Stub an einen Namen bei rmiregistry. 7. Beende die Setup-Anwendung

50 12.9 Remote Object Activation Erzeuge aktivierbare Klasse Setup -Klasse (2/3) package activation; import java.rmi.*; import java.rmi.activation.*; import java.util.properties; public class Setup { // This class registers information about the // ActivatableImplementation class with rmid and the // rmiregistry public static void main(string[] args) throws Exception { System.setSecurityManager(new RMISecurityManager()); // After JDK1.2Beta4, ActivationGroups are no longer // created implicitly as a side-effect of creating or // registering the first Activatable object // Because of the 1.2 security model, a security policy // should be specified for the ActivationGroup VM. The // first argument to the Properties put method, inherited // from Hashtable, is the key and the second is the value Properties props = new Properties(); props.put("java.security.policy", "file:\\\\d:\\activation\\policy"); ActivationGroupDesc.CommandEnvironment ace = null; ActivationGroupDesc examplegroup = new ActivationGroupDesc(props, ace); // Once the ActivationGroupDesc has been created, // register it with the activation system to obtain its ID ActivationGroupID agi = ActivationGroup.getSystem().registerGroup(exampleGroup);

51 12.9 Remote Object Activation Erzeuge aktivierbare Klasse Setup -Klasse (3/3) // Now explicitly create the group ActivationGroup.createGroup(agi, examplegroup, 0); // The "location" String specifies a URL from where the // class definition will come when this object is // requested (activated). // Don't forget the trailing slash at the end of the URL // or your classes won't be found. String location = "file:/activation/"; // Create the rest of the parameters that will be passed // to the ActivationDesc constructor MarshalledObject data = null; // The second argument to the ActivationDesc constructor // will be used to uniquely identify this class; it's location // is relative to the URL-formatted String, location. ActivationDesc desc = new ActivationDesc ("activation.activatableimplementation", location, data); // Register with rmid MyRemoteInterface mri = (MyRemoteInterface)Activatable.register(desc); System.out.println( "Got the stub for the ActivatableImplementation"); // Bind the stub to a name in the registry running on 1099 Naming.rebind("ActivatableImplementation", mri); System.out.println("Exported ActivatableImplementation"); System.exit(0);

52 12.9 Remote Object Activation Erzeuge aktivierbare Klasse Policy-Datei Alles ist erlaubt (nur für dieses Beispiel verwenden)! grant { // Allow everything for now permission java.security.allpermission; ; Client (1/2) package examples.activation; import java.rmi.*; public class Client { public static void main(string args[]) { String server = "localhost"; if (args.length < 1) { System.out.println ("Usage: java Client <rmihost>"); System.exit(1); else { server = args[0];

53 12.9 Remote Object Activation Erzeuge aktivierbare Klasse Client (2/2) try { String location = "rmi://" + server + "/ActivatableImplementation"; // Since you can't create an instance of an interface, // what we get back from the lookup method is a // remote reference to an object that implements // MyRemoteInterface. // Then we cast the remote reference (serialized stub // instance) returned from Naming.lookup to a // "MyRemoteInterface" so we can call the interface // method(s). MyRemoteInterface mri = (MyRemoteInterface) Naming.lookup(location); System.out.println("Got a remote reference to the " + "object that extends Activatable."); // The String "result" will be changed to "Success" by // the remote method call String result = "failure"; System.out.println("Making remote call to the server"); result = (String)mri.callMeRemotely(); System.out.println("Returned from remote call"); System.out.println("Result: " + result); catch (Exception e) { e.printstacktrace();

54 12.9 Remote Object Activation Erzeuge aktivierbare Klasse Erzeugen der Anwendung Übersetze die Quelldateien: javac d. activation\myremoteinterface.java javac d. activation\activatableimplementation.java javac d. activation\client.java javac d. activation\setup.java Erzeuge Stub und Skeleton: rmic d. activation.activatableimplementation Starte die Registry (in der DOS-Box): start rmiregistry Starte den Aktivierungs-Dämon (in der DOS-Box): start rmid Starte das Setup-Programm (auch aus der DOS-Box) und übergib die Lokation des Security Policy Files als System-Property, den URL, woher der Stub Code geladen werden kann (darf) und den voll qualifizierten Namen des Setup-Programms: java -Djava.security.policy=\\d:\\activation\\policy -Djava.rmi.server.codebase=file:/d:/activation/ activation.setup Achtung auf die diversen Slash-Varianten unter Windows!! Starte den Client: java activation.client Mehr Details in der JDK 1.2 Dokumentation

55 12.10 Zusammenfassung Zusammenfassung Die Entwicklung von Java RMI hat einen starken Einfluß auf CORBA gehabt. RMI ist tatsächlich eine neue Art eines ORBs (Object Request Broker). Wie jeder ORB stellt RMI fünf spezielle Neuerungen zur Verfügung: 1. Zusätzlich zu Daten kann auch Code transportiert werden. 2. Es wird ernsthaft versucht sicherzustellen, daß heruntergeladener Code sicher zum Ablauf gebracht werden kann. 3. Objekte können als Werte übergeben werden. 4. Java wird sowohl als IDL als auch als Implementierungssprache verwendet. 5. Es verwendet ein URL-basiertes Namens-Schema. RMI ist für Java-zu-Java Kommunikation leicht und angenehm zu benutzen. - Alles spielt sich innerhalb Java ab. Zur Zeit entwickelt Sun ein RMI-über-IIOP Schema (IIOP = Internet Inter-ORB Protocol). - Dann kann man über RMI auch mit nicht-java Objekten kommunizieren

56 13. BeanContext BeanContext Neuer Mechanismus in der JDK 1.2 (Java 2 Standard Edition SDK): - Extensible Runtime Containment and Services Protocol API, kurz BeanContext. - Beans als Container und Beans in einem Container. - Beans können dynamisch miteinander vebunden werden. Beispielhaft implementiert in der BeanBox des BDK 1.1. Bisher werden Beans mit entsprechenden Werkzeugen zur Design- Zeit angepaßt und miteinander verbunden. - Dies geschieht dadurch, daß Ereignisse einer Bean mit einer öffentlichen Methode einer anderen Bean verknüpft werden. Die so miteinander verbundenen Komponenten können in Form eines Applets oder einer Anwendung an die Benutzer ausgeliefert werden. - Sie verwenden die resultierenden Beans dann zur Laufzeit. Die BeanContext API fügt diesem Szenario neue Flexibilität hinzu: - Sie ermöglicht der Bean, ihre Umgebung nach bestimmten Möglichkeiten und verfügbaren Services zu befragen. - Somit kann die Bean dynamisch ihr Verhalten an den Container oder Context, in dem sie sich befindet, anpassen. Die API besteht aus zwei Teilen: 1. Logical Containment Hierarchie für JavaBeans Komponenten und deren Veröffentlichung und 2. das Feststellen von Services, die die Beans zur Verfügung stellt, innerhalb einer solchen Hierarchie

57 13. BeanContext 13.1 Logical Containment Logical Containment Mit der Containment Hierarchie wird es ermöglicht, Beans logisch zu gruppieren, so daß sie z.b. entsprechend besucht werden können (traverse). - Die Gruppierung geschieht mittels des BeanContext Containers. Dieser unterscheidet sich von einem AWT- oder JFC-Container: - Der BeanContext Container hat eine - funktionale und - logische - Bedeutung, jedoch selten einen direkten Bezug dazu, wie sich die Bean auf dem Bildschirm darstellt. Ein BeanContext Container kann andere BeanContexts enthalten, so daß eine beliebige Gruppierungs-Hierarchie von Komponenten aufgebaut werden kann. Beispiel für logical containment: - Dokumentenmanagementsystem: - System kann aus Verzeichnissen und Dokumenten bestehen. - Ein Dokument kann wiederum aus Unterdokumenten bestehen. - Die API kann dazu verwendet werden, um solche Unterdokumente in einem BeanContext Container zu verwalten, der dann das Gesamtdokument repräsentiert. - Mehrere Dokumente können in einen anderen BeanContext Container plaziert werden, das Verzeichnis

58 13. BeanContext 13.1 Logical Containment Logical Containment Struktur der BeanContext Container wird mit der Collections API (auch neu in JDK 1.2) realisiert. - Daher gelten für eine BeanContext Umgebung dieselben Regeln wie für eine Collections Umgebung. - Insbesondere müssen die add() und remove() Methoden eines BeanContext einer bestimmten Semantik folgen. Für diese Einführung sind dies: - BeanContext Container werden mittels des BeanContext.globalHierarchyLock synchronisiert. - Jedes Child Object kommt nur einmal in der Menge der Kinder für einen bestimmten BeanContext vor. - Jedes hinzugefügte Child bleibt solange Bestandteil des Bean- Context, bis es wieder durch eine der Methoden remove(), removeall(), retainall() oder clear() entfernt wird. Wenn eine Bean den BeanContext, in dem sie enthalten ist, verwenden will, muß sie das BeanContextChild Interface implementieren. Wenn BeanContext Container ineinander verschachtelt werden, muß das BeanContextChild auch das BeanContext Interface implementieren