Netzprogrammierung: Java RMI - Remote Method Invocation (Teil 3)

Transkript

1 Netzprogrammierung: Java RMI - Remote Method Invocation (Teil 3) Robert Tolksdorf und Peter Löhr

2 Überblick 1. Aktivierung und Deaktivierung von Objekten Robert Tolksdorf und Peter Löhr 2

3 Aktivierung und Deaktivierung von Objekten Robert Tolksdorf und Peter Löhr

4 Persistente Objekte Beachte: Ein fernaufrufbares Objekt braucht als Träger eine aktive JVM - auch wenn es tagelang nicht aufgerufen wird. Wünschenswert: Persistente Objekte: ruhen meistens passiv im Dateispeicher und sind nur dann in einer JVM aktiv, wenn sie aktuell benutzt werden. Für die Benutzung müssen sie aktiviert werden, nach der Benutzung können sie deaktiviert werden. Robert Tolksdorf und Peter Löhr 4

5 Probleme Naiver Ansatz mit hypothetischem persistenten Java : Wurzelklasse Object verfüge über Methoden save und load... Mytype x, y;... x.save("myob");... // Kopieren in Datei y = (Mytype) load("myob ); // Laden aus Datei... // Objekt hat normale Klasse: Persistenzabstraktion Probleme: Objektidentität... vor allem bei Benutzung durch mehrere Prozesse Objektgeflechte (Transaktionen?) Speicherbereinigung entfernte Objekte?? Robert Tolksdorf und Peter Löhr 5

6 Persistenz in Java Reale Persistenz in Java: Java Persistence API: Objektspeicherung in relationalen Datenbanken mittels EJB Java RMI Object Activation: Persistente fernaufrufbare Objekte Robert Tolksdorf und Peter Löhr 6

7 RMI Activation Framework Aktivierung eines entfernten persistenten Objekts erfordert das Hochfahren einer JVM am Ort des Objekts, die als Träger des aktiven Objekts dient (falls nicht schon vorhanden). Dies setzt wiederum voraus, dass am Ort des Objekts ein Prozess installiert ist, der den JVM-Prozess erzeugen kann: rmid (RMI daemon) ist das einschlägige Programm. Der rmid-prozess verwaltet für jedes lokal aktivierbare Objekt einen Objektdeskriptor (activation descriptor), der die Lokalisierung von Code und Daten des Objekts erlaubt und über eine Objektkennung (activation identifier) identifiziert wird. (ActivationID --> ActivationDesc) Verzögerte Aktivierung (lazy activation) wird praktiziert: der Vertreter eines passiven Objekts ist so beschaffen, dass ein Aufruf nicht direkt zum Objekt, sondern zum RMI daemon führt. Dieser nimmt die Aktivierung vor und liefert dem Vertreter die Daten für die Lokalisierung des aktiven Objekts. Robert Tolksdorf und Peter Löhr 7

8 Beispiel Counter Wiederaufnahme des einfachen Beispiels Counter : package activation; import java.rmi.*; interface Counter extends Remote { int inc(int i) throws RemoteException; void deactivate() throws Exception; } package activation; import java.io.*; import java.rmi.*; import java.rmi.activation.*; // erlaubt das Deaktivieren class CounterImpl implements Counter { int c = 0; public int inc(int i) { return c += i; } // synchronization ignored... Robert Tolksdorf und Peter Löhr 8

9 Konstruktor für aktivierbare Objekte // Obligatorischer Konstruktor, bei Aktivierung eingesetzt. // id und info (hier ein Dateiname) kommen vom rmid.... ActivationID id; public CounterImpl(ActivationID id, MarshalledObject info) throws... { this.id = id; // memoriert für spätere Deaktivierung String filename = (String) info.get(); // info-objekt deserialisieren c = getstate(filename); // lokale Hilfsmethode // Objektzustand aus Datei laden - siehe unten Activatable.exportObject(this, id, 0); // Objekt über das Aktivierungssystem // fernaufrufbar machen (vgl. RMI-1, S.21) }... Robert Tolksdorf und Peter Löhr 9

10 RandomAccessFile raf; int getstate(string name) throws Exception { File file = new File(name); boolean newfile =! file.exists(); raf = new RandomAccessFile(file, "rw"); return newfile? 0 : raf.readint(); } Nebenbei bemerkt: leider keinerlei Persistenzabstraktion! Robert Tolksdorf und Peter Löhr 10

11 Deaktivierung... public void deactivate() throws Exception { raf.setlength(0); raf.writeint(c); // Zustand wird in Datei gerettet raf.close(); Activatable.unexportObject(this, true ); // Objekt wird beim Fernaufrufsystem abgemeldet Activatable.inactive(id); // Objekt wird deaktiviert, ausführende // JVM wird beendet, falls dort keine weiteren // aktiven Objekte vorhanden } } // end class Robert Tolksdorf und Peter Löhr 11

12 ... und der Klient Der Klient wird z.b. mit java activation/inc mycounter 10 aufgerufen und sieht so aus: package activation; 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(); Counter x = (Counter) registry.lookup(arg[0]); int i = x.inc(integer.parseint(arg[1])); // impliziert Aktivierung in neuer JVM! System.out.println("counter is " + i); x.deactivate(); // deaktiviert x und beendet die JVM } } Robert Tolksdorf und Peter Löhr 12

13 Einrichten eines aktivierbaren Objekts Für die Aktivierung eines Objekts muss eine JVM bereitstehen bzw. bereitgestellt werden. Für die Konfigurierung dieser JVM müssen geeignete Properties vorgehalten werden. Die Konfigurierungsbeschreibung für die JVM wird als Gruppendeskriptor (activation group descriptor) bezeichnet (weil eine JVM für eine ganze Gruppe von aktivierbaren Objekten zuständig sein kann). Die Gruppendeskriptoren werden vom rmid verwaltet und dort über Gruppenkennungen (activation group identifiers) identifiziert (analog zu den Objektkennungen). Die Einrichtung eines aktivierbaren Objekts erfolgt hier mit einem separaten Programm Setup, z.b. so: java... activation/setup mycounter activation.counterimpl count Optionen mnemonischer Name Objektklasse Zustandsdatei Robert Tolksdorf und Peter Löhr 13

14 Einrichten eines aktivierbaren Objekts package activation; import java.rmi.*; import java.rmi.activation.*; import java.rmi.registry.*; import java.util.properties; public class Setup { // Argumente: Name Klasse Datei (des Objekts) public static void main(string[] args) throws Exception { String implclass = args[1]; // Objektklasse String implbase = System.getProperty("activation.impl.codebase"); // Codebasis der Klasse... Properties props = new Properties(); // für die Objektgruppe props.put("activation.impl.codebase", implbase); props.put("activation.file", arg[2]); props.put("java.security.policy", "group.policy"); props.put("java.class.path", "no_classpath"); Robert Tolksdorf und Peter Löhr 14

15 Einrichten eines aktivierbaren Objekts... ActivationGroupDesc groupdesc= new ActivationGroupDesc(props, null); ActivationGroupID groupid = ActivationGroup.getSystem(). registergroup(groupdesc); // Gruppe registrieren beim Aktivierungssystem MarshalledObject data = new MarshalledObject(arg[2]); ActivationDesc desc = new ActivationDesc(groupID, implclass, implbase, data); Remote stub = Activatable.register(desc); // Objekt registrieren beim Aktivierungssystem LocateRegistry.getRegistry().rebind(arg[0], stub); } // Objekt registrieren beim Registry } // end class Setup Robert Tolksdorf und Peter Löhr 15

16 Richtliniendateien 2 Richtliniendateien werden benötigt: group.policy: legt fest, was die Objektgruppe darf grant codebase "${activation.impl.codebase}" { // permission to read and write object's file permission java.io.filepermission "${activation.file}","read,write"; // permission to listen on an anonymous port permission java.net.socketpermission "*:1024-","accept"; }; // permission to connect to rmid for deactivation permission java.net.socketpermission "*:1098", "connect,resolve"; Robert Tolksdorf und Peter Löhr 16

17 Richtliniendateien rmid.policy erlaubt dem rmid das Starten von JVMs mit den angegebenen Properties, wie bei class Setup vorgesehen: grant { // no codebase means any code permission com.sun.rmi.rmid.execoptionpermission "-Djava.security.policy=${activation.policy}"; permission com.sun.rmi.rmid.execoptionpermission "-Djava.class.path=no_classpath"; permission com.sun.rmi.rmid.execoptionpermission "-Dactivation.impl.codebase=*"; permission com.sun.rmi.rmid.execoptionpermission "-Dactivation.file=*"; }; Robert Tolksdorf und Peter Löhr 17

18 endlich: der Test Dateien für lokalen Test mit aktuellem Verzeichnis /home/user/act: $ ls * more group.policy rmid.policy activation: Counter.class CounterImpl.class Inc.class Setup.class $ Robert Tolksdorf und Peter Löhr 18

19 endlich: der Test Lokaler Test mit aktuellem Verzeichnis /home/user/act: $ rmiregistry & [1] 6034 $ rmid -J-Djava.security.policy=rmid.policy \ -J-Dactivation.policy=group.policy & [2] 6035 $ java -Dactivation.impl.codebase=file:/home/user/act/ \ activation/setup mycounter activation.counterimpl count $ java activation/inc mycounter 5 counter is 5 $ java activation/inc mycounter 3 counter is 8 $ Robert Tolksdorf und Peter Löhr 19

20 Zusammenfassung Robert Tolksdorf und Peter Löhr

21 Zusammenfassung Aktivierbares Objekt ist entweder aktiv oder passiv, d.h. technisch nicht als Objekt vorhanden, kann persistenten Zustand im Dateisystem halten rmid verwaltet aktivierbare Objekte benötigt Richtliniendateien rmiregistry registriert aktivierbare Objekte genauso wie normale Objekte (offen geblieben: Speicherbereinigung, Fehlerdetails,... ) Robert Tolksdorf und Peter Löhr 21

22 Literatur Robert Tolksdorf und Peter Löhr 22