Vs7.21 7.3 Replizierte Objekte Vollständige Replikationsabstraktion ist attraktiv und machbar. 2 Beispiele: Orca(H. Bal, VU Amsterdam, 1987-90) = klassenbasierte,

Präsentation zum Thema: "Vs7.21 7.3 Replizierte Objekte Vollständige Replikationsabstraktion ist attraktiv und machbar. 2 Beispiele: Orca(H. Bal, VU Amsterdam, 1987-90) = klassenbasierte,"—  Präsentation transkript:

1 vs7.21 7.3 Replizierte Objekte Vollständige Replikationsabstraktion ist attraktiv und machbar. 2 Beispiele: Orca(H. Bal, VU Amsterdam, 1987-90) = klassenbasierte, nichtsequentielle Sprache mit replizierten Objekten Javanaise (INRIA 1997/98) = Java mit Object Caching

2 vs7.22 7.3.1 Orca Datenabstraktion, Klassen, keine Vererbung, keine Halde object spec Queue; Schnittstelle der Klasse Queue operation append(item: in integer); operation remove(item: out integer); end; object impl Queue; Implementierung der Klasse Queue..... Repräsentation operation append... operation remove... begin..... Initialisierung end;... q: Queue... Vereinbarung eines Queue -Objekts

3 vs7.23 Parametermechanismen: Wertparameter in Ergebnisparameter out Variablenparameter shared (für Objekte) Prozesstyp: process Producer(q: shared Queue);..... Vereinbarungen begin..... Anweisungen end; Prozesserzeugung: fork Producer(q); fork Consumer(q);

4 vs7.24 Semantik gemeinsamer Objekte: Serialisierbarkeit Implementierung gemeinsamer Objekte: Leser/Schreiber-Ausschluss gemäß statischer Code-Analyse (!) Replizierte Implementierung, falls Prozesse verteilt: Kopie eines gemeinsamen Objekts bei jedem beteiligten Prozess aktive Replikation (d.h. write-update, nicht write-invalidate) sequentielle Konsistenz duch vollständig geordnete Rundrufe (mittels Sequencer (4.2.3  ))4.2.3

5 vs7.25 7.3.2 Javanaise Einsatzbereich: CSCW-Systeme..... Javanaise clients Javanaise server CSCW system hier wird GUI Applet vorgehalten, erreichbar über Web Server

6 vs7.26 Javanaise-Szenario: Benutzer lädt Applet (übers Netz) und startet es: appletviewer Applet macht keine Fernaufrufe, sondern Caching, aber nicht für Einzelobjekte, sondern für Object Clusters: jedes Cluster hat ausgezeichnetes Anker-Objekt, über das es von außen angesprochen wird; Bezugnahme auf andere Clusters über Vertreter.

7 vs7.27  Zugriff auf Anker grundsätzlich mit Lese/Schreibsperren, die vom Server (!) verwaltet werden.  Erteilung des Schreibrechts an einen Klienten geht einher mit Ungültigmachen aller Kopien bei den anderen Klienten.  Somit schwache Konsistenz, gebunden an die Sperrsynchronisation, ausreichend für sequentielle Konsistenz aus Anwendersicht. Replikationsabstraktion? 1. Zentralisiertes Programm entwickeln und austesten (!) 2. Entscheidungen treffen bzgl. Clustering und Anker-Klassen 3. Schnittstellen der Anker mit read/write annotieren 4. Vertreter-Klassen generieren