B.33 B Programmiermodell. 3 Programmiermodell (2) Erweiterung des Java-Programmiermodells. Wesentliche Änderungen gegenüber Java

Transkript

1 3 Programmiermodell Erweiterung des Java-Programmiermodells Programmiermodell von Java Java RMI Wesentliche Änderungen gegenüber Java Interface obligatorisch Exception-Handling obligatorisch veränderte Parameterübergabesemantik bei übergebenen Nicht-RMI-Objekten Zugriffstransparenz verletzt veränderte Semantik bei Koordinierung im entfernten Fall wird der Stub gesperrt statt das RMI-Objekt keine Erkennung von doppelten Object-Locks Deadlock beim Wiedereintritt in das selbe RMI-Objekt B.33 3 Programmiermodell (2) 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 Referenzzähler und Leases Halter einer entfernten Referenz muss Besitz immer wieder bestätigen passiert automatisch durch lokales RMI-System B.34

2 4 Implementierung Vorgabe eines RMI-Gerüstes durch Sun Microsystem verschiedene Implementierungen möglich meist jedoch die von Sun verwendet (Package sun.rmi) von einigen Fremdherstellern auch eigene Implementierungen verfügbar B 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 (?) B.36

3 4.1 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= B Dynamisches Klassenladen (3) 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 B.38

4 4.1 Dynamisches Klassenladen (4) Beispiel MyPrinter JVM Server Webserver JVM Registry Registry Code für MyPrinter_Stub wird dynamisch geladen B Dynamisches Klassenladen (5) Beispiel MyClient MyPrinter JVM Client JVM Server Webserver JVM Registry Registry Code für MyPrinter_Stub wird dynamisch geladen B.40

5 4.2 Kommunikation Java Remote Method Protocol (JRMP) TCP-basiertes RPC-Protokoll RPC = entfernter Prozeduraufruf / Remote Procedure Call im Wesentlichen Java-Serialisierung Annotierung der Codebase, falls vorhanden Signalisierung von Aufrufen Multiplexen mehrerer Aufrufe Adressierung über Hostname/IP-Adresse, Portnummer adressiert entferntes RMI-System weitere Adressierung über Objektidentifikator adressiert konkretes Objekt B Client-Seite Implementierung der mit rmic erzeugten Stubs RemoteObject 0..1 <<Interface>> RemoteRef RemoteStub MyPrinter_Stub sichtbare RMI-Komponenten RemoteObject Basisklasse für Stubs und RMI-Objekte RemoteStub Basisklasse für alle Stubs RemoteRef Interface für Protokollimplementierung B.42

6 4.3 Client-Seite (2) Implementierung der generischen Stubs RemoteObject- Invocation- Handler Proxy <<Interface>> RemoteRef eigentlicher Stub Instanz von java.lang.reflect.proxy Spezialklasse, die beliebige Interfaces implementieren kann Interfaces werden bei Erzeugung individuell angegeben Aufrufe werden generalisiert und in einem Handler bearbeitet java.rmi.server.remoteobjectinvocation. Handler bearbeitet Aufrufe B Client-Seite (3) Stub generalisiert Aufrufe Aufruf der invoke()-methode an RemoteRef wie bei Java-Reflection Method-Objekt bezeichnet Methode, Object-Array bezeichnet Parameter RemoteRef enthält Adressierungsinformation Lokale JRMP-Implementierung wird von allen lokalen Stubs verwendet TCP/IP-Verbindung zu entfernten RMI-Systemen Öffnen eines TCP-Socket, falls Verbindung abgerissen oder noch nicht besteht Multiplexen von Aufrufen an Objekte des selben RMI-Systems über selbe TCP-Verbindung B.44

7 4.4 Server-Seite Generisches Skeleton Teil des lokalen RMI-Systems nimmt JRMP-Anfragen entgegen hat TCP-Server-Socket geöffnet interpretiert Protokoll, deserialisiert Objekte Aufruf der lokalen Methode über Java-Reflection Identifikation des Objekts durch zusätzlichen Objektidentifikator 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 B Client und Server Konzeptionelle Sicht JVM Server JVM Client JVM Server B.46

8 4.5 Client und Server (2) Tatsächliche Implementierungen RMI-Sys. JVM Server RMI-Sys. RMI-Sys. JVM Client JVM Server B Parametertransport Basis: Serialisierung von Java-Datentypen und -Objekten Übergabe von Referenzen auf RMI-Objekte lokal: Referenz auf einen Stub Serialisierung des Stubs lokal: Referenz auf RMI-Objektimplementierung Ersetzung des RMI-Objekts durch geeigneten Stub vor der Serialisierung serialisierter Stub enthält eindeutige Identifikation des referenzierten Objekts: IP-Adresse, Portnummer und Objektidentifikator B.48

9 4.7 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) B.49 5 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 B.50

10 5.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 Aktivierung (activation) Transformation eines passiven in ein aktives Objekt in der Regel Aktivierung auf Anfrage, d.h. bei Methodenaufruf (Lazy activation) B 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 B.52

11 5.2 Architektur (2) 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 JVM Activator Client-Stub Skeleton RMI-Objekt JVM B Architektur (3) 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) B.54

12 5.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 Stub des aktivierbaren Objekts Einbetten der Referenz in die RemoteRef B 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, da Klasse MarshalledObject lokal bekannt B.56

13 5.4 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 B 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 B.58

14 5.5 Registrierung eines aktivierbaren Objekts 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 B Registrieren eines aktivierbaren Objekts (2) 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 B.60

15 5.5 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 B Aktivierung Aktives Objekt kein besonderes Vorgehen Passives Objekt Objekt hat sich deaktiviert z.b. durch 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) B.62

16 5.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 B 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 nächst höhere Generationennummer dient zur Erkennung von Aufruffehlern Übergabe z.b. über Standardeingabe Rest wie bei aktiver ActivationGroup B.64

17 5.6 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 Übergabe des transienten Stubs als MarshalledObject Objekt ist serialisiert: Code muss nicht geladen werden B 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 B.66

18 5.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 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 B 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 B.68

19 5.8 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 B Weiterführende Links RMI Informationen bei Sun Microsystems RMI Einführung hello-world.html RMI Activation Tutorial Java Serialisierung B.70