C.6 C.8. 1 Java (5) 1 Java (4) 1 Java (6) 2 Java RMI Grundlagen. Sicherheitsmechanismen. Hierarchische Benennung von Interfaces und Klassen

Transkript

1 1 Java (4) Hierarchische Benennung von Interfaces und Klassen Paketname + Klassenname (Package) z.b. java.lang.object weltweite eindeutige Benennung durch Anlehnung des Paketnamens an Domainname z.b. org.aspectix.orb.orb (angelehnt an aspectix.org) Compilierung auf Klassenebene (Class File) übersetzt in interpretierten Byte-Code Dynamisches Laden von Klassen ClassLoader kann Klassen von beliebigen Quellen laden 1 Java (5) Sicherheitsmechanismen Byte-Code-Verifier Ausführung des Byte-Codes erhält Semantik der Sprache z.b. kein Zugriff auf nicht-öffentliche Instanzvariablen anderer Objekte möglich Sandboxing Klassen eines neuen ClassLoaders werden von einem SecurityManager kontrolliert versagt oder gewährt Zugriff auf Dateien Zugriff auf Netzwerkverbindungen etc. Threads als Sprachkonzept verfügbar als spezielle Objekte C.5 C.6 1 Java (6) JVM, Java Virtual Machine Interpreter für Java Class-Files (JIT-Compiler) Ausführungsumgebung für Java Programme bzw. Klassen mehrere ClassLoader möglich 2 Java RMI Grundlagen Java Remote Method Invocation Erweiterung des Java Programmiermodells für Verteilung mehrere JVMs spannen eine verteilte Rechenplattform auf Verteilungseinheiten Java Objekte Verteilungstransparenz orts- und zugriffstransparente Methodenaufrufe an verteilten Java Objekten C.7 C.8

2 2.1 Verteilte Java Objekte Schnittstelle verteilte Java Objekte / RMI-Objekte implementieren spezielle Java-Interfaces genauer: mindestens ein Java-Interface, das direkt oder indirekt von java.rmi.remote erbt dient als Marker, enthält keine Methoden alle Methoden in von java.rmi.remote erbenden Interfaces müssen die Exception java.rmi.remoteexception deklarieren zeigt Fehler bei entfernten Aufrufen an in der Regel At-Most-Once-Semantik es kann auch eine Basisklasse deklariert werden, z.b. java.io.ioexception oder java.lang.exception 2.1 Verteilte Java Objekte (2) Beispiel public interface Printer implements java.rmi.remote { public void print( String s ) throws java.rmi.remoteexception; C.9 C Verteilte Java Objekte (2) Entfernt ansprechbare Methoden entfernt sind nur die Methoden aus Interfaces ansprechbar, die von Remote erben andere Methoden und Instanzvariablen sind nur lokal ansprechbar Referenzen Referenzen nur mit dem Namen eines Remote-Interfaces typisieren nicht mit dem Klassennamen der Implementierung Beispiel: avo.printer p; try { p.print( Testdruck ); catch( java.rmi.remoteexception e) { 2.2 Erzeugen eines RMI-Objekts Übliches Vorgehen Implementierungsklasse erbt/implementiert mind. ein Remote-Interface Implementierungsklasse erbt von java.rmi.server.unicastremoteobject bereitet Objektinstanz für entfernte Aufrufe: exportiert Objekt Alternative Implementierungsklasse erbt/implementiert mind. ein Remote-Interface manuelles Vorbereiten für entfernte Aufrufe: Aufruf von java.rmi.server.unicastremoteobject.exportobject( obj, ) C.11 C.12

3 2.2 Erzeugen eines RMI-Objekts (2) Beispiel public class MyPrinter extends java.rmi.unicastremoteobject implements avo.printer { public void print( String s ) throws java.rmi.remoteexeception { 2.2 Erzeugen eines RMI-Objekts (3) RMI Compiler erzeugt Stubklasse für Clientseite nur bis Java 1.4 notwendig ab Java 1.5 (Java 2 Version 5) generische Stubs erzeugt Skeletonklasse für Serverseite nur bis Java 1.1 notwendig ab Java 1.2 generische Skeletons Kommando rmic z.b. für avo.myprinter wird Stubklasse avo.myprinter_stub erzeugt C.13 C Erzeugen eines RMI-Objekts (4) Stubklasse implementiert alle Remote-Interfaces der ursprünglichen Objektklasse Compiler erkennt Remote-Interfaces an Marker-Interface java.rmi.remote Objekte der Stubklasse werden als Stellvertreter auf Clientseite benutzt Client hat Java Objektreferenz auf Stubobjekt statt auf lokales Objekt 2.2 Erzeugen eines RMI-Objekts (5) Beispiel für das Erzeugen des Objekts im Java-Code avo.printer p = new avo.myprinter();// Erzeugung des Objekts Objekt wurde durch Basisklasse automatisch exportiert sofort von außen (entfernt) ansprechbar lokaler Aufruf wie bisher entfernter Aufruf (?) Referenz auf RMI-Objekt notwendig Client Stubobjekt Skeleton RMI-Objekt C.15 C.16

4 2.3 Finden initialer Referenzen Namensdienst zum Registrieren von Objekten Klasse java.rmi.registry.locateregistry erlaubt das Erzeugen einer Namensdienst-Instanz erlaubt das Erzeugen einer Objektreferenz zu einer (entfernten) Namensdienst-Instanz Hostname und Portnummer für TCP/IP-Verbindungen zum Namensdienst müssen bekannt sein Objektreferenz ist vom Remote-Interface java.rmi.registry.registry bind( String s, Remote obj ) registriert Objekt obj unter Name s lookup( String s ) gibt Objektreferenz für Objekt mit Namen s zurück 2.3 Finden initialer Referenzen (2) Naming-Interface abkürzender Zugriff auf bestehende Registry statische Methoden der Klasse java.rmi.naming bind( String s, Remote obj ) registriert Objekt obj unter Name s lookup( String s ) gibt Objektreferenz für Objekt mit Namen s zurück String s ist von der Form: rmi://host:port/objectname host = Rechner, auf dem Registry läuft port = Portnummer, unter der Registry registriert ist objectname = Objektname beim Registrieren bzw. Nachfragen C.17 C Finden initialer Referenzen (3) Beispiel auf Serverseite public class MyPrinter extends java.rmi.unicastremoteobject implements avo.printer { static void main( String [] args ) { avo.printer p = new avo.myprinter(); java.rmi.naming.bind( "rmi:myprinter", p ); public void print( String s ) throws java.rmi.remoteexeception { C Finden initialer Referenzen (4) Beispiel auf Clientseite public class MyClient { static void main( String [] args ) { avo.printer p; p= (avo.printer) java.rmi.naming.lookup( "rmi:myprinter" ); try { p.print( Testdruck ); catch( java.rmi.remoteexception e) { C.20

5 2.4 Parameterübergabe Parameterübergabesemantik bei lokalen Aufrufen Call-By-Value für Nicht-Objekttypen (z.b. Integer) Call-By-Object-Reference für Standard-Java-Objekte und lokale RMI-Objekte entfernte RMI-Objekte Referenz auf Stubobjekt wird übergeben Client verwendet Stubobjekt wie lokales Objekt Call-By-Object-Reference Semantik für RMI-Objekte Objekt Instanzvariable Aufruf übergebene Referenz 2.4 Parameterübergabe (2) Parameterübergabesemantik bei entfernten Aufrufen Marshalling der Parameter Parameter werden serialisiert (Java Serialization) Erzeugung eines Bytestroms aus den Parametern Übertragung des Bytestroms Regenerierung der Datentypen und Java-Objekte aus Bytestrom Call-By-Value für Nicht-Objekttypen (z.b. Integer) Datentypen werden kopiert Beispiel: Objekt Aufruf 42 Instanzvariable 42 übergebener Wert Knotengrenze C.21 C Parameterübergabe (3) serialisierbare Java-Objekte und lokale, nicht-exportierte RMI-Objekte Serialisierung führt zu vollständiger Kopie eines Objekts und seiner untergeordneten Objekte evtl. große transitive Hülle zu übertragender Daten aber: Erhaltung der Objektstruktur über alle Parameter Call-By-Copy Semantik Objekt Instanzvariable Knotengrenze Aufruf übergebene Objektstruktur C Parameterübergabe (3) Parameterübergabesemantik bei entfernten Aufrufen (fortges.) nicht-serialisierbare Java-Objekte nicht übertragbar: MarshalException lokale, exportierte RMI-Objekte Einfügung eines geeigneten Stubobjekts in den Bytestrom Regenerierung des Stubobjekts auf der Empfängerseite Call-By-Object-Reference Semantik für lokale RMI-Objekte entfernte, exportierte RMI-Objekte Einfügung des vorhandenen Stubobjekts in den Bytestrom Call-By-Object-Reference Semantik für entfernte RMI-Objekte Objekt Aufruf übergebene Referenz Instanzvariable C.24

6 2.5 Beispiel 2.5 Beispiel (2) Aufbau der Referenz über Namensdienst Aufbau der Stubs und Skeletons MyClient MyPrinter MyClient MyPrinter JVM Client 1:Ref 3:Ref 2:bind() 4:lookup() JVM Server JVM Client JVM Server JVM Registry Registry JVM Registry Registry C.25 C.26 3 Programmiermodell 3 Programmiermodell (2) Erweiterung des Java-Programmiermodells Programmiermodell von Java Wesentliche Änderungen gegenüber Java Java RMI Interface obligatorisch Exception-Handling obligatorisch veränderte Parameterübergabesemantik bei übergebenen Nicht-RMI-Objekten Zugriffstransparenz verletzt keine Erkennung von doppelten Object-Locks Deadlock beim Wiedereintritt in das selbe RMI-Objekt Bewahrte Konzepte aus dem Java-Programmiermodell Objekte Methodenaufrufe syntaktisch gleich Parameterübergabesemantik für übergebene RMI-Objekte und Nicht-Objekte Typisierung volle Typisierung im verteilten Fall (dynamische) Type-Casts auch für RMI-Objekte möglich Stubobjekte besitzen alle Methoden des Originals Garbage Collection transparente Speicherbereinigung verteiltes Verfahren zur Speicherbereinigung basierend auf Leases C.27 C.28

7 4 Dynamisches Klassenladen Deserialisierung Objektinstanzen werden regeneriert Instanzvariablen werden restauriert pro JVM und pro Objekt muss Klasse verfügbar sein im Verteilten System Verfügbarkeit der Klassen nicht automatisch garantiert Serialisierter Bytestrom enthält Objektdaten keine Klassen Klassenname wird übertragen Klasse lokal vorhanden: Verwendung für regenerierte Objektinstanz Klasse nicht lokal vorhanden: Möglichkeit des dynamischen Ladens der Klasse über das Netzwerk Class-Path (?) 4 Dynamisches Klassenladen (2) Serverseite Bereitstellung der Klassen über einen externen Server Web-Server FTP-Server File-Server Codebase-URL gibt Wurzel für Klassen pro Server an Codebase muss beim Server-Lauf festgelegt werden Java Property java.rmi.server.codebase liefert Codebase-URL z.b. java -Djava.rmi.server.codebase= C.29 C.30 4 Dynamisches Klassenladen (3) 4 Dynamisches Klassenladen (4) Weitergabe von Referenzen auf RMI-Objekte z.b. bei Registrierung in Registry oder Namensdienst Stubobjekt wird serialisiert RMI-System trägt Klassenname und Codebase in Bytestrom ein empfangendes RMI-System: 1. Suche der Klasse lokal 2. falls nicht gefunden: Laden der Klasse über Codebase + Klassenname z.b. Klasse avo.myprinter_stub unter MyPrinter_Stub.class 3. falls nicht gefunden: Laden der Klasse über clientseitig definierte Codebase (z.b. über Codebase-Property) 4. falls nicht gefunden: ClassNotFoundException für entfernt geladene Klassen steht Codebase für erneute Weitergabe fest Beispiel Webserver JVM Registry Registry Code für MyPrinter_Stub wird dynamisch geladen MyPrinter JVM Server C.31 C.32

8 4 Dynamisches Klassenladen (5) 5 Implementierung Beispiel MyClient MyPrinter Vorgabe eines RMI-Gerüstes durch Sun Microsystem verschiedene Implementierungen möglich meist jedoch die von Sun verwendet (Package sun.rmi) JVM Client JVM Server Webserver JVM Registry Registry Code für MyPrinter_Stub wird dynamisch geladen C.33 C Client-Seite Implementierung der Stubs 5.1 Client-Seite (2) Stub generalisiert Aufrufe RemoteObject RemoteStub MyPrinter_Stub 0..1 <<Interface>> RemoteRef sichtbare RMI-Komponenten RemoteObject Basisklasse für Stubs und RMI-Objekte RemoteStub Basisklasse für alle Stubs RemoteRef Interface für Protokollimplementierung Aufruf der invoke()-methode an RemoteRef wie bei Java-Reflection Method-Objekt bezeichnet Methode, Object-Array bezeichnet Parameter Java Remote Method Protocol (JRMP) im Wesentlichen Java-Serialisierung Annotierung der Codebase, falls vorhanden Signalisierung von Aufrufen Multiplexen mehrerer Aufrufe Adressierung über Hostname/IP-Adresse, Portnummer Bestandteil der RemoteRef weitere Adressierung über Objektidentifikator C.35 C.36

9 5.2 Server-Seite generisches Skeleton nimmt JRMP-Anfragen entgegen interpretiert Protokoll, deserialisiert Objekte Aufruf der lokalen Methode über Reflection Tabelle der exportierten Objekte Zuordnung von Anfragen zu RMI-Objekten durch Objektidentifikator mind. lokal eindeutige Objektnummern zugeordnet werden beim Export zugeteilt Identifikation exportierter, lokaler RMI-Objekte Ersetzung durch Stub beim Marshalling 5.3 Socket-Factories RMI-Implementierungen benutzen Sockets zur Kommunikation java.net.serversocket und java.net.socket stattdessen Einsatz von anwendungsspezifischen Sockets möglich Socket-Factory erzeugt anwendungsspezifische Sockets Übergabe der Factory an das RMI-System z.b. als Parameter zum Konstruktor von java.rmi.unicastremoteobject RMI-Stub-Objekt enthält Verweis auf Socket-Factory wird evtl. dynamisch geladen wird zur Kommunikation eingesetzt Einsatz z.b. Verschlüsselung (SSL) C.37 C.38 6 Beispiel: White-Board Anwendungsszenario White-Board-Server als Objekt Clients als Objekte 6.1 Interaktionsmuster Mitteilung von Änderungen auf dem White-Board White-Board White-Board 1: sendevent 1.1: notify Client Client Client Client Client Client Clients referenzieren White-Board-Objekt Clients registrieren sich selbst beim White-Board White-Board-Objekt kennt alle Clients C.39 Bei Manipulation des White-Board-Inhalts durch Client Senden eines Änderungsereignisses an White-Board (Methodenaufruf) White-Board aktualisiert Zustand und sendet Benachrichtigungan an alle Clients C.40

10 6.2 RMI-Implementierung Schnittstelle White-Board public interface WhiteBoard implements java.rmi.remote { public void register( WhiteBoardClient c ) throws java.rmi.remoteexception; public void sendevent( WhiteBoardEvent ev ) throws java.rmi.remoteexception; Schnittstelle Client public interface WhiteBoardClient implements java.rmi.remote { public void notify( WhiteBoardEvent ev ) throws java.rmi.remoteexception; C RMI-Implementierung (2) White-Board public class MyWhiteBoard extends java.rmi.unicastremoteobject implements WhiteBoard { static void main( String [] args ) { avo.whiteboard c = new avo.mywhiteboard(); C RMI-Implementierung (3) Client public class MyClient extends java.rmi.unicastremoteobject implements WhiteBoardClient { avo.whiteboard s; static void main( String [] args ) { avo.whiteboardclient c = new avo.myclient(); public MyClient() { s = java.rmi.naming.lookup( ); s.register( this ); C.43 7 Aktivierung und Deaktivierung Zweck persistente Objektimplementierungen konzeptionelles Objekt überlebt temporäre Objektimplementierungen Laststeuerung nicht alle Objektimplementierungen müssen in JVMs vorgehalten werden (aktiv sein) Realisierung persistente entfernte Referenzen überleben das Passivieren eines verteilten Objekts überleben die JVM eines passivierten verteilten Objekts triggern das Reaktivieren einer JVM und des Objekts C.44

11 7.1 Terminologie Aktives Objekt (active object) verteiltes Objekt realisiert durch eine exportierte Implementierungsinstanz in einer passenden JVM Passives Objekt (passive object) momentan nicht durch Implementierung repräsentiertes aber dennoch aktivierbares verteiltes Objekt evtl. nicht einmal JVM dafür vorhanden entfernte Referenzen (Stubs) sind bereits im Umlauf 7.2 Architektur Aktives Objekt aktuelle, normale RMI-Referenz (RemoteRef) zum aktiven Objekt wird in aktivierbaren Stub eingebettet und verwendet für Aufrufe Fehlersituation eingebettete RMI-Referenz funktioniert nicht mehr z.b. Absturz der Server-JVM z.b. Passivierung des RMI-Objekts Aktivierung (activation) Transformation eines passiven in ein aktives Objekt in der Regel Aktivierung auf Anfrage, d.h. bei Methodenaufruf (Lazy activation) C.45 C Architektur (2) 7.2 Architektur (3) Stub des aktivierbaren Objekts enthält normale RMI-Referenz auf einen Activator enthält eine Aktivierungs-ID bezeichnet Objekt eindeutig gegenüber Activator im Fehlerfall: Kontaktierung des Activators Skeleton Activator JVM Activator ermittelt Activation-Descriptor (Activator verwaltet Datenbank) Activation-Group-ID Bezeichner für JVM, die Gruppe aktivierbarer Objekte beherbergt Klassenname und Codebase für RMI-Objekt objektspezifische Initialisierungsdaten (MarshalledObject) Client-Stub Skeleton RMI-Objekt JVM C.47 C.48

12 7.2 Architektur (3) Activator (fortges.) startet Activation-Group falls nötig eigene JVM initialisiert Activation-Group triggert Activation-Group zur Erzeugung des RMI-Objekts neues RMI-Objekt Initialisierung mit objektspezifischen Daten z.b. über Datei, welche persistenten Zustand hält Rückgabe einer normalen Referenz an den Activator Rückgabe der Referenz an den ursprünglichen Stub 7.3 Marshalled Object Container für serialisiertes Objekt serialisiertes Daten-Objekt wird in ein MarshalledObject eingebettet aus MarshalledObject kann Datenobjekt deserialisiert werden Vorteil des Einsatzes MarshalledObject enthält Datenstrom der Serialisierung benötigt jedoch zur Laufzeit nicht die Klasse des serialisierten Objekts MarshalledObject kann gespeichert und weitergegeben werden z.b. durch Serialisierung des MarshalledObject jedoch kein Klassenladen erforderlich Stub des aktivierbaren Objekts Einbetten der Referenz in die RemoteRef C.49 C Erzeugen eines aktivierbaren Objekts Übliches Vorgehen Implementierungsklasse erbt von java.rmi.activation.activatable zusätzlicher Konstruktor für die Aktivierung public MyImpl( ActivationID id, MarshalledObject data ) id ist ein Identifikator, der das zu aktivierende Objekt beschreibt data ist ein serialisiertes Objekt, das zur Initialisierung eines zu aktivierenden Objekts dienen kann (z.b. Filename für Daten etc.) Konstruktor ruft Konstruktor der Basisklasse für das Exportieren auf Registrierung des Objekts beim Aktivierungsmechanismus im (Default-) Konstruktor Basisklassenmethode getid liefert eine ActivationID: eindeutiger Bezeichner für aktivierbares Objekt 7.4 Erzeugen eines aktivierbaren Objekts (2) Alternatives Vorgehen ohne Vererbung zusätzlicher Konstruktor für die Aktivierung (siehe vorherige Folie) Konstruktor ruft statische Methode zum Exportieren auf: java.rmi.activation.activatable.exportobject( ) Aufruf liefert ActivationID: eindeutiger Bezeichner für aktivierbares Objekt Registrierung des Objekts beim Aktivierungsmechanismus im normalen Konstruktor Erzeugen eines aktivierbaren Objekts ohne Objektinstanz wie beschriebene Möglichkeiten jedoch: Registrierung des Objekts beim Aktivierungsmechanismus ohne Erzeugung einer Implementierung C.51 C.52

13 7.5 Registrierung eines aktivierbaren Objekts 7.5 Registrieren eines aktivierbaren Objekts (2) Registrierung an der ActivationGroup ActivationGroup ist innerhalb einer JVM eine Gruppe von aktiven Objekten letztlich bezeichnet eine ActivationGroup eine JVM Erzeugen einer ActivationGroup new-operation auf java.rmi.activation.activationgroupdesc erzeugt einen Descriptor/Identifikator für eine ActivationGroup Properties können angegeben werden z.b. für Security Policies (sonst keine RMI-Verbindungen zwischen den JVMs möglich) Erzeugen der ActivationGroup über ein ActivationSystem ActivationSystem-Implementierung wird über statische Methode ActivationGroup.getSystem ermittelt Aufruf der Methode registergroup am ActivationSystem liefert eine Instanz von ActivationGroupID zurück ActivationGroupID ist ein Identifikator für die ActivationGroup C.53 Erzeugen eines ActivationDesc für das aktivierbare Objekt ActivationDesc ist ein Deskriptor für das aktivierbare Objekt enthält Klassennamen enthält CodeBase enthält MarshalledObject das zur Initialisierung bei Re-Aktivierung dienen kann enthält ActivationGroupID für die JVM, in der das aktivierbare Objekt laufen soll Erzeugen des ActivationDesc-Objekts durch new-operator ohne Angabe einer ActivationGroupID wird Default-Gruppe verwendet und gegebenenfalls automatisch erzeugt Problem: Defaultgruppe hat meist nicht die richtigen Policy Properties C Registrieren eines aktivierbaren Objekts (3) Registrieren des ActivationDesc-Objekts Aufruf der statischen Methode Activatable.register mit dem ActivationDesc-Objekt als Parameter Rückgabe einer entfernten Referenz auf die Implementierung (Stub mit Fähigkeit der Re-Aktivierung) z.b. anschließend Registrierung im Nameserver 7.6 Aktivierung Aktives Objekt kein besonderes Vorgehen Passives Objekt Objekt hat sich deaktiviert Aufruf von inactiveobject in Klasse Activatable mit ActivationID als Parameter Stubobjekte bekommen keine Verbindung mehr und stoßen Aktivierung an Aktivierung ist transparent für einen Aufrufer lediglich zusätzliche Exceptions möglich (Subklassen von java.rmi.remoteexception) C.55 C.56

14 7.6 Aktivierung (2) Aktivierung durch den Stub Stub kennt die zugehörige ActivationID ActivationID enthält Referenz auf einen Activator Stub fordert einen Activator auf, das Objekt zu aktivieren interner Aufruf der Methode activate am Activator bekommt als Ergebnis eine neue Standard-RMI-Objektreferenz (bei Erfolg), die intern gespeichert wird Activator typischerweise einmal pro System vorhanden kennt aktive und passive Objekt anhand ActivationIDs kennt aktive ActivationGroups Standardimplementierung: Dämon-Prozess rmid intern ist Activator eine RMI-Referenz, die automatisch ermittelt wird C Aktivierung (3) ActivationGroup aktiv Activator beauftragt die ActivationGroup das Objekt zu aktivieren, d.h. mit Hilfe des zusätzlichen Konstruktors zu erzeugen Activator bekommt eine neue Referenz auf das aktivierte Objekt (Standard- Stub) ActivationGroup passiv Activator startet neue JVM und instanziiert ActivationGroup neue ActivationGroup bekommt neue Generationennummer dient zur Realisierung der At-most-once-Semantik Übergabe z.b. über Standardeingabe Rest wie bei aktiver ActivationGroup C Aktivierung (4) Kontrollfluss persistenter Stub kennt Activator über ActivationID: Aufruf von activate Activator kennt aktive Gruppen (lokales Caching bzw. Informationen aus den Gruppen): Aufruf von newinstance am ActivationInstantiator Interface (gehört zur Implementierung der Gruppe) Rückgabe eines transienten Stubs an Activator Rückgabe eines transienten Stubs an den persistenten Stub falls Gruppe passiv: Activator erzeugt neue Gruppe: Starten einer neuen JVM sobald sich Gruppe aktiv meldet: fortfahren wie oben 7.6 Aktivierung (5) Initialisierung des reaktivierten Objekts zusätzlicher Konstruktor erhält ActivationID und ein MarshalledObject MarshalledObject wurde bei Erzeugung des ActivationDesc spezifiziert enthält ein serialisiertes Objekt zur direkten oder indirekten (Re-)Initialisierung, z.b. Dateinamen, Datenbankverweis, entfernte RMI- Referenzen Übergabe des transienten Stubs als MarshalledObject Objekt ist serialisiert: Code muss nicht geladen werden C.59 C.60

15 7.7 Implementierung Aktivierungsmechanismus hauptsächlich durch Interfaces vorgegeben z.b. Activator, ActivationGroup, ActivationSystem, ActivationInstantiator Implementierung durch Property java.rmi.activation.activator.class festlegbar für andere Teile sind feste Klassen vorgesehen, z.b. ActivationDesc, ActivationID, ActivationGroupDesc, ActivationGroupID diese interagieren mit den hinter Interfaces verborgenen Implementierungen 7.7 Implementierung (2) Activator prüft Gruppen bei Absturz von Gruppen werden diese reaktiviert (neu gestartet) Ständige Aktivierung bei Registrierung kann dauerhafte Aktivierung angegeben werden bei Absturz der Gruppe wird dauerhaft aktives Objekt sofort wieder re-aktiviert Interner ActivationMonitor wird pro ActivationGroup erzeugt und vom Activator benutzt Gruppe muss an den ActivationMonitor berichten Aktivierung, Deaktivierung von Objekten in der Gruppe Deaktivierung der Gruppe C.61 C Bewertung Zweistufige Aktivierung und Deaktivierung Objektebene Gruppenebene (JVM-Ebene) Verteilung aktivierbares Objekt wird immer auf gleichen Rechner aktiviert Activator-Referenz hängt an der ActivationID keine Migration möglich aber eventuell Realisierung durch eigene Activator-Implementierung Garbage Collection Objekt müssen sich sauber deaktivieren, sonst bleiben Referenzen stehen 7.9 Weiterführende Links RMI Informationen bei Sun Microsystems RMI Einführung hello-world.html RMI Activation Tutorial Java Serialisierung C.63 C.64