Klaus-Peter Löhr! 8 Java RMI!

Transkript

1 Klaus-Peter Löhr 8 Java RMI 8.1 Fernaufrufbare Objekte Das rmiregistry Parameterübergabe Mobiler Code Sicherheit Hochladen von Code Herunterladen von Code 54 Zusammenfassung 55 WS 13/14 ALP 5 - Java RMI 1

2 8.1 Fernaufrufbare Objekte Ø Ø Ø Ø Objekte können fernaufrufbar gemacht werden. Klasse und Vertreterklasse implementieren gleiche Schnittstelle. Keine Fernerzeugung von Objekten. Mäßige Verteilungsabstraktion WS 13/14 ALP 5 - Java RMI 2

3 interface Counter { // lokal, ohne RMI int inc(int i); int value(); } public class CounterImpl implements Counter { int c = 0; public int inc(int i) { return c += i; } public int value() { return c; } public int dec(int i) { return c -= i; } } WS 13/14 ALP 5 - Java RMI 3

4 import java.rmi.*; interface Counter extends Remote { // mit RMI int inc(int i) throws RemoteException; int value() throws RemoteException; } public class CounterImpl implements Counter { int c = 0; public int inc(int i) { return c += i; } public int value() { return c; } public int dec(int i) { return c -= i; } } Achtung - evtl. nichtsequentielle Benutzung solcher Objekte (hier der Einfachheit halber ignoriert) WS 13/14 ALP 5 - Java RMI 4

5 Ø Ø Ein mit new erzeugtes Objekt der Klasse CounterImpl ist lokal aufrufbar - und kann zusätzlich fernaufrufbar gemacht werden ( remote object ) und durch Parameterübergabe in andere Rechner exportiert werden. Letzteres gelingt nur, wenn die Klasse ein Remote Interface implementiert, bei deren Methoden RemoteExceptions vereinbart sind (für verteilungsbedingte Fehler). Remote ist ein leeres, sogenanntes marker interface. Ø Beachte: Die Nutzen der Trennung von Schnittstelle und Implementierung wird bei Fernaufrufen besonders augenfällig. Ein Klient muss natürlich die Schnittstelle kennen. Die implementierende Klasse ist aber nicht nur unbekannt - sie ist womöglich gar nicht lokal vorhanden. WS 13/14 ALP 5 - Java RMI 5

6 Entfernte Benutzung eines fernaufrufbaren Objekts: public class Inc { public static void main(string[] arg) { Counter x =... // Stub beschaffen int i = x.inc(integer.parseint(arg[0])); System.out.println("counter is " + i); } } Beim Aufrufer Inc ist die Klasse CounterImpl womöglich unbekannt Den Stub x erhält man in der Regel durch einen Fernaufruf. WS 13/14 ALP 5 - Java RMI 6

7 Objekt fernaufrufbar machen: import java.rmi.server.unicastremoteobject; Statische Methode exportobject(x,port) - macht das Remote Objekt x fernaufrufbar über den Port port (irgendeinen, falls 0); - erzeugt für x einen Vertreter vom Typ RemoteStub, - liefert einen Verweis auf diesen Vertreter. - Für eine Sicht auf den Verweis gemäß Anwendungstyp ist eine explizite Typanpassung erforderlich, z.b. (Counter)UnicastRemoteObject.exportObject(x,0) Folgendes macht alle Objekte einer Remote Klasse fernaufrufbar: class CounterImpl extends UnicastRemoteObject {... } WS 13/14 ALP 5 - Java RMI 7

8 8.2 Objektverzeichnis rmiregistry Ø Start des Programms rmiregistry erzeugt einen Trägerprozess für ein Register öffentlicher Objekte: rmiregistry <port> & (default port: 1099) Nicht 1099 verwenden Nicht kill <procno> vergessen Ø Ø Verwaltet werden ausschließlich systemlokale Objekte. Einträge haben die Form (Name, Fernverweis) Ø Typische Verzeichnisoperationen lookup, bind, rebind WS 13/14 ALP 5 - Java RMI 8

9 mein.rechner.de dein.rechner.de bind JVM1 rmiregistry JVM2 mein.rechner.de dein.rechner.de JVM1 lookup rmiregistry JVM2 mein.rechner.de dein.rechner.de JVM1 doit rmiregistry JVM2 WS 13/14 ALP 5 - Java RMI 9

10 import java.rmi.registry.registry; Eine Remote Schnittstelle von Objektverzeichnissen, mit Methoden bind, rebind, lookup,... import java.rmi.registry.locateregistry; Statische Methode getregistry(host, port) liefert einen Client Stub für den Fernaufruf eines (lokalen oder entfernten) Registry-Objekts in einem rmiregistry-prozess. WS 13/14 ALP 5 - Java RMI 10

11 Erzeugung und Bekanntmachung eines fernaufrufbaren Objekts: import java.rmi.server.unicastremoteobject; import java.rmi.registry.locateregistry; import java.rmi.registry.registry; public class CounterImpl implements Counter { int c = 0; public int inc(int i) { return c += i; } public int value() { return c; } public int dec(int i) { return c -= i; } public static void main(string[] arg) throws Exception { Counter x = new CounterImpl(); Counter stub = (Counter)UnicastRemoteObject. exportobject(x,0); Registry registry = LocateRegistry.getRegistry(); registry.rebind("mycounter", stub); } // main thread dies; hidden thread waits for invocation } WS 13/14 ALP 5 - Java RMI 11

12 Auffinden und Benutzen eines entfernten Objektes: // usage: java Inc host increment import java.rmi.registry.locateregistry; import java.rmi.registry.registry; public class Inc { public static void main(string[] arg) throws Exception { Registry registry = LocateRegistry. getregistry(arg[0]); Counter x = (Counter)registry.lookup("myCounter"); int i = x.inc(integer.parseint(arg[1])); System.out.println("counter is " + i); } } Typanpassung - kann scheitern (Alternative: Klasse java.rmi.naming verwenden) WS 13/14 ALP 5 - Java RMI 12

13 Lokaler Test: $ javac Counter.java $ javac CounterImpl.java $ javac Inc.java $ java CounterImpl & Exception in thread "main" java.rmi.connectexception: Connection refused to host: $ rmiregistry & [1] 8774 $ [ Register läuft nicht ] WS 13/14 ALP 5 - Java RMI 13

14 $ java Inc localhost 10 Exception... java.rmi.notboundexception: mycounter... [ CounterImpl läuft nicht ] $ java CounterImpl & [2] 8777 $ java Inc localhost 10 counter is 10 $ java Inc localhost 10 counter is 20 $ java Inc localhost -20 counter is 0 $ kill 8777 [ CounterImpl-Prozess löschen ] $ kill 8774 [ rmiregistry-prozess löschen ] WS 13/14 ALP 5 - Java RMI 14

15 Test im Netz: rmiregistry & [1] 8774 java CounterImpl & [2] java Inc lounge.mi.fu-berlin.de 10 counter is 10 java Inc lounge 10 counter is 20 WS 13/14 ALP 5 - Java RMI 15

16 Was passiert hier? Registry registry = LocateRegistry.getRegistry(); (S. 11) registry.rebind("mycounter", stub); Statische Methode getregistry(host, port) liefert einen Client Stub für den Fernaufruf eines (lokalen oder entfernten) Registry-Objekts in einem rmiregistry-prozess. rebind("mycounter", stub) ruft das Register auf: Kopien der Argumentobjekte werden übergeben (siehe Ú 8.3), und im Verzeichnis wird entsprechender Eintrag vorgenommen. Counter x = (Counter)registry.lookup("myCounter"); (S. 12) Dieser Fernaufruf liefert eine Kopie des im Register unter "mycounter" gespeicherten Stubs. WS 13/14 ALP 5 - Java RMI 16

17 ... und das Kleingedruckte: Ø Die Unmarshaling-Routine im Register erwartet zum Herstellen des Client Stub des Counter aus der serialisierten rebind- Nachricht die Schnittstelle Counter.class in seinem Classpath, d.h. '.' - wenn nicht anders festgelegt. (Sonst ClassNotFoundException) Ø Es kann nicht ausgeschlossen werden, dass Aufrufer und Aufgerufener mit nicht identischen Kopien der Schnittstelle Counter.class arbeiten. Mit kryptographischen Hash- Werten wird sichergestellt, dass die aufgerufene Methode vorhanden ist und die richtige Signatur hat. (Sonst UnmarshalException: invalid method hash ) WS 13/14 ALP 5 - Java RMI 17

18 $ rmiregistry & [1] 8774 ann@server:~ $ bob@server:~/classes $ ls Counter.class CounterImpl.class bob@server:~/classes $ java CounterImpl & [1] 8777 bob@server:~/classes $ Exception in thread "main" java.rmi.serverexception: RemoteException occurred in server thread; nested exception is: java.rmi.unmarshalexception: error unmarshalling arguments; nested exception is: java.lang.classnotfoundexception: Counter... WS 13/14 ALP 5 - Java RMI 18

19 Dies wird wie folgt geheilt: $ ls Counter.class CounterImpl.class $ java \ > -Djava.rmi.server.codebase=file:/Users/bob/classes/ \ > CounterImpl & [1] 8779 bob@server:~/classes $ Unverzichtbar (vgl. Ú 8.4) Dem von CounterImpl versendeten Fernverweis wird die Codebasis der Schnittstelle beigegeben, damit der Empfänger die Schnittstelle Counter.class finden und damit einen Stub erzeugen kann. Dies ist gute RMI-Praxis, wenn das Register von verschiedenen Personen für verschiedene Anwendungen eingesetzt werden soll. WS 13/14 ALP 5 - Java RMI 19

20 Alternative: programmatische Erzeugung des Registers z.b. gleich gefolgt vom Eintrag eines Objekts:... LocateRegistry.createRegistry(56789); // at given port IN THIS JVM Registry registry = LocateRegistry. getregistry(null, 56789); Counter x = (Counter)UnicastRemoteObject. exportobject(new CounterImpl(),0); registry.rebind("mycounter", x);... WS 13/14 ALP 5 - Java RMI 20

21 8.3 Parameterübergabe Nochmals eingeschärft: Java kennt nur einen Parametermechanismus Wertparameter (call by value) Im Hinblick auf Fernaufrufe ist das einerseits gut, weil es keine Variablenparameter gibt, andererseits schlecht, weil es keine Ergebnisparameter gibt. Außerdem ist die Allgegenwart von Verweisen ungünstig. (Zur Erinnerung: 7.3.1) WS 13/14 ALP 5 - Java RMI 21

22 An argument to, or a return value from, a remote object can be any object that is serializable. This includes primitive types, remote objects, and non-remote objects that implement the Serializable interface. [RMI spec.] Argumente/Ergebnisse von Verweistypen: Ø Ø Ø Wenn das Argument/Ergebnis fernaufrufbar ist, wird ein Fernverweis (stub) übergeben. Wenn das Argument/Ergebnis nicht fernaufrufbar ist, aber Serializable, wird eine Kopie übergeben. Sonst wird der Fehler MarshalException gemeldet (bedingt durch NotSerializableException). Entsprechend für Komponenten von Argumenten/Ergebnissen WS 13/14 ALP 5 - Java RMI 22

23 import java.rmi.server.unicastremoteobject; import java.rmi.registry.locateregistry; import java.rmi.registry.registry; public class Par { public static void main(string[] arg) throws Exception { Counter count = new CounterImpl(); Counter stub = (Counter)UnicastRemoteObject. exportobject(count,0); Registry registry = LocateRegistry.getRegistry(arg[0]); Param x = (Param)registry.lookup("param"); int i = x.call(count); // executes 'return c.inc(7);' int k = x.call(stub); // executes 'return c.inc(7);' System.out.println("counter is " + i + " " + k + " " + count.value() + " " + stub.value()); System.exit(0); // enforces program shutdown } } $ java Par localhost counter is $ WS 13/14 ALP 5 - Java RMI 23

24 Nichtlokal - evtl. Problem bei IP-Adressen-Umsetzung: xian: java ParamImpl & home: java Par xian.imp.fu-berlin.de Exception in thread "main" java.rmi.serverexception: RemoteException occurred in server thread; nested exception is: java.rmi.connectioexception: Exception creating connection to: ; nested exception is: java.net.noroutetohostexception: No route to host Dies wird wie folgt geheilt: meine IP-Adresse im VPN home: java -Djava.rmi.server.hostname= \ > Par xian.imp.fu-berlin.de counter is home: WS 13/14 ALP 5 - Java RMI 24

25 3-mal Kleingedrucktes zur Verteilungsabstraktion: Counter x1 = (Counter)registry.lookup("myCounter"); Counter x2 = (Counter)registry.lookup("myCounter"); Hier gilt leider nicht x1 == x2 (da der Fernaufruf lookup ein neues Stub-Objekt liefert), wohl aber x1.equals(x2) object.method(node1, node2); (vgl , S. 24) RMI betrachtet (node1, node2,...) als ein Geflecht If two references to an object are passed from one JVM to another JVM in parameters (or in the return value) in a single remote method call and those references refer to the same object in the sending JVM, those references will refer to a single copy of the object in the receiving JVM. synchronized(remobj) {...} Vorsicht Hier wird der Vertreter gesperrt, nicht das Objekt WS 13/14 ALP 5 - Java RMI 25

26 ... und die Fehlersemantik: If a MarshalException occurs during a remote method call, the call may or may not have reached the server. If the call did reach the server, parameters may have been deserialized. A call may not be retransmitted after a MarshalException and reliably preserve at most once call semantics. (java.rmi.marshalexception API) M.a.W.: Nicht nur gibt RMI keine Garantien bezüglich einer präzisen Fehlersemantik, der Benutzer hat auch bei der Ausnahmebehandlung keinerlei Möglichkeit, etwas Besseres zu realisieren. WS 13/14 ALP 5 - Java RMI 26

27 8.4 Mobiler Code Ein Objekt besteht aus Daten und Code (gemäß seiner Klasse). Wenn beim Fernaufruf ein Fernverweis übertragen wird, braucht kein Code übertragen zu werden: am Zielort ist der Vertretercode vorhanden oder wird im Fluge aus der Schnittstelle erzeugt (die am Zielort notwendigerweise vorhanden ist). Wenn eine Objektkopie übertragen wird, ist der Code (.class) am Zielort womöglich unbekannt. Die serialisierten Daten werden übertragen; den Code muss der Empfänger auf anderem Weg erhalten WS 13/14 ALP 5 - Java RMI 27

28 java.io.serializable sind beispielsweise Ø Number mit Unterklassen Integer,... Ø String, StringBuffer Ø alle Felder Ø java.util.arraylist,.linkedlist,.hashset,... Ø java.rmi.server.remotestub,.unicastremoteobject,... Ø class myclass implements Serializable... Dieser Code wird u.u. nicht beim Empfänger bekannt sein WS 13/14 ALP 5 - Java RMI 28

29 Ø Der Klassenname und die serialversionuid* werden mit der Objektkopie übertragen. Ø Die empfangende JVM sucht die Klasse im classpath. Ø Wenn Sender und Empfänger das gleiche Dateisystem sehen, kann das Problem eventuell mit java -cp <classpath> gelöst werden. Ø Wenn nicht, Fernladen von benötigten.class- oder.jar-dateien über das Web: * siehe java.io.serializable WS 13/14 ALP 5 - Java RMI 29

30 Fernladen: Situation: myprogram erzeuge Objekte von nur lokal bekannten Klassen, die nicht Remote, aber Serializable sind, und diese Objekte werden als Argumente oder Ergebnisse von Fernaufrufen verschickt. Maßnahme: Die benötigten.class- oder.jar-dateien über einen Web Server verfügbar machen und beim Programmstart die Web-Adresse als Codebasis (codebase) angeben, z.b. $ java -Djava.rmi.server.codebase=\ > \ > myprogram (vgl. 8.2, S. 19) WS 13/14 ALP 5 - Java RMI 30

31 Beispiel: Fernaufrufbares Factory-Objekt zur Erzeugung von Serializable Objekten, die die Klienten sich per Fernaufruf beschaffen können.... implements Factory create new... data code data code? (Netz)Dateisystem code WS 13/14 ALP 5 - Java RMI 31

32 Beispiel: Fernaufrufbares Factory-Objekt zur Erzeugung von Serializable Objekten, die die Klienten sich per Fernaufruf beschaffen können.... implements Factory create new... data code data code? code Separates Dateisystem WS 13/14 ALP 5 - Java RMI 32

33 interface Echo { // is not Remote void print(); // display contents of Echo object } import java.rmi.*; interface Factory extends Remote { Echo create(string s) throws RemoteException; } // delivers a new Echo object // equipped with string s anna als Anbieterin der Fabrik stellt den Benutzern lediglich diese zwei Schnittstellen zur Verfügung. Ihre Implementierung von Echo ist Serializable WS 13/14 ALP 5 - Java RMI 33

34 In Kenntnis dieser Schnittstellen, des Namens von annas Rechner und des Namens der Fabrik im dortigen Register verfasst paul ein Klientenprogramm: import java.rmi.registry.*; public class Test { public static void main(string[] arg) throws Exception{ Registry registry = LocateRegistry.getRegistry( "lounge.mi.fu-berlin.de"); Factory f = (Factory)registry.lookup("factory"); Echo x = f.create(arg[0]); // delivers copy x.print(); // local call } } WS 13/14 ALP 5 - Java RMI 34

35 Netzdateisystem: $ ls Echo.class EchoFactory.class EchoImpl.class Factory.class $ rmiregistry & [1] 1373 $ java EchoFactory & $ ls Echo.class Factory.class Test.class $ java Test Wesel Exception in thread "main" java.rmi.unmarshalexception: error unmarshalling return; nested exception is: java.lang.classnotfoundexception: EchoImpl... WS 13/14 ALP 5 - Java RMI 35

36 Dies wird wie folgt geheilt: $ \ > java -cp.:/home/fenn/anna/echo/classes/ Test Wesel esel paul@xian:~/test/classes $ Bemerkung 1: Dies macht es im übrigen entbehrlich, Echo.class und Factory.class bei paul vorzuhalten. Bemerkung 2: paul muss natürlich auf die Dateien in /home/fenn/anna/echo/classes Lesezugriff haben - sonst gibt es wiederum eine ClassNotFoundException: EchoImpl Bemerkung 3: Wenn die Klasse von der richtigen abweicht (), InvalidClassException WS 13/14 ALP 5 - Java RMI 36

37 Separates Dateisystem: Z.B. $ java Test Wesel? Dem Objekterzeuger EchoFactory muss eine URL beigegeben werden, die die Codebasis für die zu versendende Objektkopie bezeichnet (dort ist der Code EchoImpl.class vorzuhalten). $ java \ > -Djava.rmi.server.codebase=\ > \ > EchoFactory & Beim Eintreffen der Objektkopie sorgt der RMI-Klassenlader für das Herunterladen des Codes vom Web Server. WS 13/14 ALP 5 - Java RMI 37

38 $ java Test Wesel Exception in thread "main" java.rmi.unmarshalexception: error unmarshalling return; nested exception is: java.lang.classnotfoundexception: EchoImpl (no security manager: RMI class loader disabled) Das Nachladen von Code über das Web wird verweigert, wenn kein Security Manager installiert ist: Gefahr Trojanischer Pferde WS 13/14 ALP 5 - Java RMI 38

39 8.5 Sicherheit Achtung - mobiler Code wirft grundsätzliche Sicherheitsfragen auf, nicht nur bei RMI Prinzipiell: Bei jedem fremden Code muss man damit rechnen, dass er sich anders verhält als erwartet - das gilt für lokal geladenen Code in gleicher Weise wie für übers Netz geladenen Code. WS 13/14 ALP 5 - Java RMI 39

40 Ø Schadcode (malware) hat unerwünschte Funktionalität, die dem Benutzer Schaden zufügen kann. Typisch sind: Trojanisches Pferd hat zwar die gewünschte Funktionalität, aber zusätzlich (und verdeckt) eine schädliche Funktionalität; Virus ist Schadcode, der zusätzlich zu seiner schädlichen Funktionalität auch anderen - bislang unschädlichen - Code infiziert. Ø Sicherheitsbewusstes Verhalten: nur solchen Code benutzen, den man selbst geschrieben hat oder dessen Autor man vertraut (?) oder der erfahrungsgemäß richtig funktioniert (??). WS 13/14 ALP 5 - Java RMI 40

41 ... und auf RMI bezogen: Vorsicht mit Fernaufruf-Argumenten/Ergebnissen, deren Klassen Serializable Anwendungsklassen sind (Beispiel: EchoImpl, S. 33) $ java -Djava.rmi.server.codebase=\ > \ > EchoFactory paul@home: $ java Test Wesel Hier muss der von Anna bereitgestellten Code EchoImpl übers Netz geladen werden - ohne Security Manager scheitert das (S. 35) ( Wenn Anna nur die Nutzung im gleichen (Netz-)Dateisystem erlauben will: -Djava.rmi.server.codebase=file:/home/fenn/anna/classes/ - vgl 8.2, S. 19 ) WS 13/14 ALP 5 - Java RMI 41

42 Schutz vor unerwünschten Aktionen fremden Codes: Security Manager mitlaufen lassen: Ø entweder $ java -Djava.security.manager... Ø oder if(system.getsecuritymanager() == null) System.setSecurityManager( new SecurityManager()); (typischerweise am Anfang von main) WS 13/14 ALP 5 - Java RMI 42

43 Der Security Manager orientiert sich an benutzerdefinierten Richtlinien (policies), die in Richtlinien-Dateien (policy files) formuliert sind: ~/.java.policy (privat) $JAVAHOME/jre/lib/security/java.policy (global)... und evtl. andere, explizit benannte Dateien Berechtigungen (permissions) sind der wesentliche Bestandteil einer Richtlinien-Datei: sie legen die erlaubten Aktionen fest. Was nicht explizit erlaubt ist, ist verboten Wenn keine Richtlinien-Datei gefunden werden kann, ist nichts erlaubt WS 13/14 ALP 5 - Java RMI 43

44 Beispiel für eine Richtlinien-Datei mypolicy von bob: grant codebase "file:${user.home}/-" { permission java.security.allpermission; }; grant codebase "file:/usr/ann/classes/*" { permission java.io.filepermission "/usr/bob/help/*","read"; permission java.net.socketpermission "localhost:1024-", "connect, accept"; }; grant { // allows any code to read in pub subtree permission java.io.filepermission "/usr/bob/pub/-", "read"; }; Benutzung z.b. so: bob: java -Djava.security.manager \ > -Djava.security.policy=mypolicy... WS 13/14 ALP 5 - Java RMI 44

45 Programm policytool erlaubt komfortable Bearbeitung von Richtlinien-Dateien, z.b. beim Mac: WS 13/14 ALP 5 - Java RMI 45

46 Beispiel (ohne RMI): System Property erfragen class GetProps { public static void main(string[] arg) throws Exception { s = System.getProperty("java.home", "not specified"); System.out.println("Your Java home directory is: " + s); } } $ java GetProps Your Java home directory is: /System/Library/Frameworks/JavaVM.fr $ java -Djava.security.manager GetProps Exception in thread "main" java.security.accesscontrolexception: access denied (java.util.propertypermission java.home read)... $ WS 13/14 ALP 5 - Java RMI 46

47 Dies wird geheilt durch Bereitstellung einer einfachen Richtlinien-Datei.java.policy mit grant codebase "file:${user.home}/-" { permission java.security.allpermission; }; Damit kann endlich auch Paul die EchoImpl testen (S. 38, 41): paul@home: $ java -Djava.security.manager \ > Test Wesel esel paul@home: $ WS 13/14 ALP 5 - Java RMI 47

48 ... und das Kleingedruckte zu den Richtlinien-Dateien: The exact meaning of a codebase value depends on the characters at the end. A codebase with a trailing "/" matches all class files (not JAR files) in the specified directory. A codebase with a trailing "/*" matches all files (both class and JAR files) contained in that directory. A codebase with a trailing "/-" matches all files (both class and JAR files) in the directory and recursively all files in subdirectories contained in that directory. Aus Abschnitt The SignedBy, Principal, and CodeBase Fields WS 13/14 ALP 5 - Java RMI 48

49 8.6 Hochladen von Code (nach Wir haben rechenintensiven Code compute und wollen ihn auf einer fremden, leistungsfähigen Maschine zur Ausführung bringen. Spezifikation der Berechnung: public interface Task<T> { // not Remote T compute(); // computes value of type T } Spezifikation eines entfernten Objekts Computer: public interface Computer extends Remote { <T> T execute(task<t> t) throws RemoteException; } // executes "return t.compute()" WS 13/14 ALP 5 - Java RMI 49

50 Die tatsächliche Berechnung eines Objekts vom Typ Double - hier im Beispiel die Berechnung von π mit n Stellen: class ComputePI implements Task<Double>, Serializable { ComputePI(int n) { this.n = n; } final int n; // number of digits to be computed public Double compute() {... } } ( Die Implementierung class ComputeEngine implements Computer {... } ist dem Klienten unbekannt ) WS 13/14 ALP 5 - Java RMI 50

51 ... und das Rahmenprogramm des Klienten: class RemotePiComputation { public static void main(string arg[]) {... Computer c = (Computer)registry.lookup("computer"); Double pi = c.execute(new ComputePI(100));... } } Die vollständigen.java-dateien findet man unter WS 13/14 ALP 5 - Java RMI 51

52 ... und damit: Fritz stellt auf xian eine ComputeEngine (mit eingebautem Register) bereit und informiert die Öffentlichkeit: $ java -Djava.security.manager \ > ComputeEngine & ComputeEngine ready on Franz stellt ComputePI auf Web Server bereit und startet (mit VPN) einen Klienten RemotePiComputation auf home : franz@home $ java -Djava.rmi.server.codebase=\ > \ > RemotePiComputation xian.imp.fu-berlin.de PI is Freya stellt gleichzeitig ComputeE auf Web Server WS 13/14 ALP 5 - Java RMI 52

53 Übersicht über die eingesetzten Protokolle: (im Beispiel ComputeEngine) (im Beispiel EchoFactory) WS 13/14 ALP 5 - Java RMI 53

54 8.7 Herunterladen von Code EchoFactory war ein konstruiertes Beispiel. Graphische Benutzerschnittstelle (GUI) ist attraktives Beispiel: Ø Ø wird programmatisch konstruiert als Objekt gui einer Klasse class GUI extends java.awt.frame... (javax.swing.jframe) wird sichtbar gemacht durch gui.setvisible(true) Ø ist Serializable und kann daher per Fernaufruf von einem Server-Objekt heruntergeladen werden App application = (App)Naming.lookup(rmiurl); GUI gui = application.getgui(); gui.setvisible(true); WS 13/14 ALP 5 - Java RMI 54

55 Zusammenfassung Ø Die Verteilungsabstraktion von RMI ist nur mäßig gut ausgeprägt: für die Realisierung von Fernaufrufen werden objektorientierte Techniken explizit eingesetzt (Remote, RemoteException,...). Klassenmethoden sind grundsätzlich nicht fernaufrufbar. Es gibt keine Fernerzeugung privater Objekte. Ø Keine Fernaufrufe ohne ein Register, das als initiales fernaufrufbares Objekt ansprechbar ist Ø Die im Register verzeichneten Objekte sind öffentlich - jeder kann sie über das Register erreichen. WS 13/14 ALP 5 - Java RMI 55

56 Ø Die Semantik der Parameterübergabe ist nicht unabhängig davon, ob ein Aufruf normal oder als Fernaufruf erfolgt. Ø Bei der Behandlung eigener Anwendungsklassen, deren Objekte per Kopie übergeben werden sollen, muss man die Codeverwaltung und Sicherheitsfragen (Ú 8.4, 8.5) im Blick behalten. Ø Fernaufrufe über die Firewalls von Intranetzen hinweg werden in der Regel nicht zugelassen und erfordern besondere Maßnahmen. Ø Und nie vergessen: öffentliche Objekte befinden sich in einer potentiell nichtsequentiellen Umgebung (ALP 4 ist hier nicht nur nicht irrelevant, sondern wird sogar besonders relevant.) WS 13/14 ALP 5 - Java RMI 56

57 Ø Mobiler Code bei RMI ist überhaupt nur möglich, weil es sich um interpretierten Bytecode handelt, der auf allen Plattformen lauffähig ist. Ø Ohne die Unterstützung von Code-Mobilität wäre die Benutzung von Serializable Argumenten/Ergebnissen nur sehr eingeschränkt möglich. Ø Mobiler Code bringt ein erhöhtes Sicherheitsrisiko mit sich; RMI erzwingt daher den Einsatz des Security Manager und zwingt den Benutzer, sich über die Rechtevergabe an fremden Code Gedanken zu machen. WS 13/14 ALP 5 - Java RMI 57

58 Quellen Oracle Corp.: RMI Specification. docs.oracle.com/javase/7/docs/platform/rmi/spec/rmitoc.html Oracle Corp.: RMI Tutorial. docs.oracle.com/javase/tutorial/rmi/ W. Grosso: Java RMI. O Reilly Oracle Corp.: Java Security. docs.oracle.com/javase/7/docs/technotes/guides/security Oracle Corp.: Java Security Tutorial. docs.oracle.com/javase/tutorial/security A. Fuggetta, G.P. Picco, G. Vigna: Understanding Code Mobility. IEEE Trans. on Software Engineering 24.5, May WS 13/14 ALP 5 - Java RMI 58