C.37-C.64 - Verteilte Systeme

5.2 Server-Seite
5.3 Socket-Factories
■ generisches Skeleton
■ RMI-Implementierungen benutzen Sockets zur Kommunikation
◆ nimmt JRMP-Anfragen entgegen
◆ java.net.ServerSocket und java.net.Socket
◆ interpretiert Protokoll, deserialisiert Objekte
◆ stattdessen Einsatz von anwendungsspezifischen Sockets möglich
◆ Aufruf der lokalen Methode über Reflection
■ Socket-Factory erzeugt anwendungsspezifische Sockets
■ Tabelle der exportierten Objekte
◆ Übergabe der Factory an das RMI-System
◆ Zuordnung von Anfragen zu RMI-Objekten durch Objektidentifikator
• z.B. als Parameter zum Konstruktor von java.rmi.UnicastRemoteObject
• mind. lokal eindeutige Objektnummern zugeordnet
■ RMI-Stub-Objekt enthält Verweis auf Socket-Factory
• werden beim Export zugeteilt
◆ wird evtl. dynamisch geladen
◆ Identifikation exportierter, lokaler RMI-Objekte
◆ wird zur Kommunikation eingesetzt
• Ersetzung durch Stub beim Marshalling
✱ Einsatz
◆ z.B. Verschlüsselung (SSL)
C.37
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
6 Beispiel: White-Board
C.38
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
6.1 Interaktionsmuster
■ Anwendungsszenario
■ Mitteilung von Änderungen auf dem White-Board
◆ White-Board-Server als Objekt
White-Board
◆ Clients als Objekte
White-Board
1: sendEvent
Client
Client
1.1: notify
Client
Client
Client
Client
■ Bei Manipulation des White-Board-Inhalts durch Client
◆ Senden eines Änderungsereignisses an White-Board (Methodenaufruf)
◆ Clients referenzieren White-Board-Objekt
◆ White-Board aktualisiert Zustand und
◆ Clients registrieren sich selbst beim White-Board
◆ ... sendet Benachrichtigungan an alle Clients
• White-Board-Objekt kennt alle Clients
C.39
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
C.40
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
6.2 RMI-Implementierung
6.2 RMI-Implementierung (2)
■ Schnittstelle White-Board
■ White-Board
package avo;
package avo;
public interface WhiteBoard implements java.rmi.Remote {
public void register( WhiteBoardClient c )
throws java.rmi.RemoteException;
public class MyWhiteBoard extends
java.rmi.UnicastRemoteObject implements WhiteBoard {
...
static void main( String [] args ) {
avo.WhiteBoard c = new avo.MyWhiteBoard();
}
public void sendEvent( WhiteBoardEvent ev )
throws java.rmi.RemoteException;
}
...
}
■ Schnittstelle Client
package avo;
public interface WhiteBoardClient implements java.rmi.Remote
{
public void notify( WhiteBoardEvent ev )
throws java.rmi.RemoteException;
}
C.41
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
6.2 RMI-Implementierung (3)
C.42
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7 Aktivierung und Deaktivierung
■ Client
■ Zweck
◆ persistente Objektimplementierungen
package avo;
public class MyClient extends
java.rmi.UnicastRemoteObject implements WhiteBoardClient
{
avo.WhiteBoard s;
static void main( String [] args ) {
avo.WhiteBoardClient c = new avo.MyClient();
}
• 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
public MyClient()
{
s = java.rmi.Naming.lookup( ... );
s.register( this );
}
• überleben die JVM eines passivierten verteilten Objekts
• triggern das Reaktivieren einer JVM und des Objekts
...
}
C.43
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
C.44
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.1 Terminologie
7.2 Architektur
■ Aktives Objekt (active object)
■ Aktives Objekt
◆ verteiltes Objekt realisiert durch eine exportierte Implementierungsinstanz in
einer passenden JVM
■ Passives Objekt (passive object)
◆ aktuelle, normale RMI-Referenz (RemoteRef) zum aktiven Objekt wird in
aktivierbaren Stub eingebettet und verwendet für Aufrufe
■ Fehlersituation
◆ momentan nicht durch Implementierung repräsentiertes
aber dennoch aktivierbares verteiltes Objekt
◆ eingebettete RMI-Referenz funktioniert nicht mehr
• z.B. Absturz der Server-JVM
◆ evtl. nicht einmal JVM dafür vorhanden
• z.B. Passivierung des RMI-Objekts
◆ 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)
C.45
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.2 Architektur (2)
C.46
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.2 Architektur (3)
■ Stub des aktivierbaren Objekts
■ Activator
◆ enthält normale RMI-Referenz auf einen Activator
◆ ermittelt Activation-Descriptor (Activator verwaltet Datenbank)
◆ enthält eine Aktivierungs-ID
• Activation-Group-ID
– Bezeichner für JVM, die Gruppe aktivierbarer Objekte beherbergt
• bezeichnet Objekt eindeutig gegenüber Activator
• Klassenname und Codebase für RMI-Objekt
◆ im Fehlerfall: Kontaktierung des Activators
• objektspezifische Initialisierungsdaten
(MarshalledObject)
JVM
Skeleton
Activator
JVM
Skeleton
Client-Stub
RMI-Objekt
C.47
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
C.48
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.2 Architektur (3)
7.3 Marshalled Object
■ Activator (fortges.)
■ Container für serialisiertes Objekt
◆ startet Activation-Group falls nötig
◆ serialisiertes Daten-Objekt wird in ein MarshalledObject eingebettet
◆ aus MarshalledObject kann Datenobjekt deserialisiert werden
• eigene JVM
• initialisiert Activation-Group
✱ Vorteil des Einsatzes
◆ triggert Activation-Group zur Erzeugung des RMI-Objekts
◆ MarshalledObject enthält Datenstrom der Serialisierung
• neues RMI-Objekt
◆ benötigt jedoch zur Laufzeit nicht die Klasse des serialisierten Objekts
• Initialisierung mit objektspezifischen Daten
– z.B. über Datei, welche persistenten Zustand hält
◆ MarshalledObject kann gespeichert und weitergegeben werden
• z.B. durch Serialisierung des MarshalledObject
• Rückgabe einer normalen Referenz an den Activator
• jedoch kein Klassenladen erforderlich
◆ Rückgabe der Referenz an den ursprünglichen Stub
■ Stub des aktivierbaren Objekts
◆ Einbetten der Referenz in die RemoteRef
C.49
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.4 Erzeugen eines aktivierbaren Objekts
C.50
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.4 Erzeugen eines aktivierbaren Objekts (2)
■ Übliches Vorgehen
■ Alternatives Vorgehen ohne Vererbung
◆ Implementierungsklasse erbt von java.rmi.activation.Activatable
◆ zusätzlicher Konstruktor für die Aktivierung (siehe vorherige Folie)
◆ zusätzlicher Konstruktor für die Aktivierung
public MyImpl( ActivationID id, MarshalledObject data )
• Konstruktor ruft statische Methode zum Exportieren auf:
java.rmi.activation.Activatable.exportObject( ... )
• id ist ein Identifikator, der das zu aktivierende Objekt beschreibt
• Aufruf liefert ActivationID: eindeutiger Bezeichner für aktivierbares Objekt
• 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 normalen
Konstruktor
■ Erzeugen eines aktivierbaren Objekts ohne Objektinstanz
◆ Registrierung des Objekts beim Aktivierungsmechanismus im (Default-)
Konstruktor
◆ wie beschriebene Möglichkeiten jedoch:
• Basisklassenmethode getID liefert eine ActivationID: eindeutiger Bezeichner
für aktivierbares Objekt
C.51
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
• Registrierung des Objekts beim Aktivierungsmechanismus ohne Erzeugung
einer Implementierung
C.52
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.5 Registrierung eines aktivierbaren Objekts
7.5 Registrieren eines aktivierbaren Objekts (2)
■ Registrierung an der ActivationGroup
■ Erzeugen eines ActivationDesc für das aktivierbare Objekt
◆ ActivationGroup ist innerhalb einer JVM eine Gruppe von aktiven Objekten
◆ ActivationDesc ist ein Deskriptor für das aktivierbare Objekt
◆ letztlich bezeichnet eine ActivationGroup eine JVM
• enthält Klassennamen
• enthält CodeBase
■ 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)
• 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
◆ Erzeugen der ActivationGroup über ein ActivationSystem
• ohne Angabe einer ActivationGroupID wird Default-Gruppe verwendet und
gegebenenfalls automatisch erzeugt
• ActivationSystem-Implementierung wird über statische Methode
ActivationGroup.getSystem ermittelt
◆ Aufruf der Methode registerGroup am ActivationSystem liefert eine Instanz
von ActivationGroupID zurück
• Problem: Defaultgruppe hat meist nicht die richtigen Policy Properties
• ActivationGroupID ist ein Identifikator für die ActivationGroup
C.53
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.5 Registrieren eines aktivierbaren Objekts (3)
C.54
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.6 Aktivierung
■ Registrieren des ActivationDesc-Objekts
■ Aktives Objekt
◆ Aufruf der statischen Methode Activatable.register mit dem
ActivationDesc-Objekt als Parameter
◆ kein besonderes Vorgehen
■ Passives Objekt
◆ Rückgabe einer entfernten Referenz auf die Implementierung
(Stub mit Fähigkeit der Re-Aktivierung)
◆ Objekt hat sich deaktiviert
• Aufruf von inactiveObject in Klasse Activatable mit ActivationID als
Parameter
• z.B. anschließend Registrierung im Nameserver
◆ 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
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
C.56
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.6 Aktivierung (2)
7.6 Aktivierung (3)
■ Aktivierung durch den Stub
■ ActivationGroup aktiv
◆ Stub kennt die zugehörige ActivationID
◆ Activator beauftragt die ActivationGroup das Objekt zu aktivieren, d.h. mit Hilfe
des zusätzlichen Konstruktors zu erzeugen
• ActivationID enthält Referenz auf einen Activator
◆ Activator bekommt eine neue Referenz auf das aktivierte Objekt (StandardStub)
◆ Stub fordert einen Activator auf, das Objekt zu aktivieren
• interner Aufruf der Methode activate am Activator
■ ActivationGroup passiv
• bekommt als Ergebnis eine neue Standard-RMI-Objektreferenz
(bei Erfolg), die intern gespeichert wird
◆ Activator startet neue JVM und instanziiert ActivationGroup
◆ neue ActivationGroup bekommt neue Generationennummer
■ Activator
◆ typischerweise einmal pro System vorhanden
• dient zur Realisierung der At-most-once-Semantik
◆ kennt aktive und passive Objekt anhand ActivationIDs
• Übergabe z.B. über Standardeingabe
◆ Rest wie bei aktiver ActivationGroup
◆ kennt aktive ActivationGroups
◆ Standardimplementierung: Dämon-Prozess rmid
• intern ist Activator eine RMI-Referenz, die automatisch ermittelt wird
C.57
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.6 Aktivierung (4)
C.58
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.6 Aktivierung (5)
■ Kontrollfluss
■ Initialisierung des reaktivierten Objekts
◆ persistenter Stub kennt Activator über ActivationID: Aufruf von activate
◆ zusätzlicher Konstruktor erhält ActivationID und ein MarshalledObject
◆ Activator kennt aktive Gruppen (lokales Caching bzw. Informationen aus den
Gruppen): Aufruf von newInstance am ActivationInstantiator Interface (gehört
zur Implementierung der Gruppe)
◆ MarshalledObject wurde bei Erzeugung des ActivationDesc spezifiziert
◆ Rückgabe eines transienten Stubs an Activator
• enthält ein serialisiertes Objekt zur direkten oder indirekten
(Re-)Initialisierung, z.B. Dateinamen, Datenbankverweis, entfernte RMIReferenzen
◆ 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
C.59
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
C.60
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.7 Implementierung
7.7 Implementierung (2)
■ Aktivierungsmechanismus hauptsächlich durch Interfaces vorgegeben
■ Activator prüft Gruppen
◆ z.B. Activator, ActivationGroup, ActivationSystem, ActivationInstantiator
◆ bei Absturz von Gruppen werden diese reaktiviert (neu gestartet)
◆ Implementierung durch Property java.rmi.activation.activator.class
festlegbar
◆ für andere Teile sind feste Klassen vorgesehen, z.B. ActivationDesc, ActivationID,
ActivationGroupDesc, ActivationGroupID
■ Ständige Aktivierung
◆ bei Registrierung kann dauerhafte Aktivierung angegeben werden
◆ bei Absturz der Gruppe wird dauerhaft aktives Objekt sofort wieder re-aktiviert
• 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
C.61
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.8 Bewertung
C.62
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
7.9 Weiterführende Links
■ Zweistufige Aktivierung und Deaktivierung
■ RMI Informationen bei Sun Microsystems
◆ Objektebene
http://java.sun.com/j2se/1.5/docs/guide/rmi/
◆ Gruppenebene (JVM-Ebene)
■ RMI Einführung
■ Verteilung
http://java.sun.com/j2se/1.5/docs/guide/rmi/hello/
hello-world.html
◆ aktivierbares Objekt wird immer auf gleichen Rechner aktiviert
■ RMI Activation Tutorial
• Activator-Referenz hängt an der ActivationID
http://java.sun.com/j2se/1.5/docs/guide/rmi/activation.html
◆ keine Migration möglich
• aber eventuell Realisierung durch eigene Activator-Implementierung
■ Java Serialisierung
http://java.sun.com/j2se/1.5/docs/guide/serialization/
■ Garbage Collection
◆ Objekt müssen sich sauber deaktivieren, sonst bleiben Referenzen stehen
C.63
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/
C.64
 2002-2005, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2005w-AvO-C-RMI.fm, 2005-10-23 18.03] http://www-vs.informatik.uni-ulm.de/teach/ws04/avo/