7.2.4 Klassifikation mobilen Codes Nicht vergessen:  Sowohl das Fernkopieren als auch die Migration von Objekten setzt voraus, daß der Code entweder am.

Präsentation zum Thema: "7.2.4 Klassifikation mobilen Codes Nicht vergessen:  Sowohl das Fernkopieren als auch die Migration von Objekten setzt voraus, daß der Code entweder am."—  Präsentation transkript:

1 7.2.4 Klassifikation mobilen Codes Nicht vergessen:  Sowohl das Fernkopieren als auch die Migration von Objekten setzt voraus, daß der Code entweder am Zielort vorhanden ist (schon geladen oder dynamisch aus dem Dateisystem nachladbar) oder zusammen mit den Daten im Netz übertragen werden kann.  Code-Übertragung zwischen Rechnern mit verschiedener Architektur kommt nicht in Frage, wenn es sich um Maschinencode handelt. (Daten dagegen können stets umcodiert werden!)  Code-Übertragung (wenn möglich) wird natürlich vielfach - und wurde immer schon - auch ohne Objekte eingesetzt.

2 Allgemeine Situation ohne Objektorientierung: Prozeß A ist an einer Dienstleistung interessiert, Prozeß B ist an deren Erbringung beteiligt, A und B befinden sich auf verschiedenen Stationen S A, S B. Dienstleistung wird erbracht durch Ausführung von Code (evtl. parametrisiert) auf Daten/Ressourcen  Klassifikation von Mobilcode-Paradigmen:

3 ParadigmaSASA SBSB Client/Server AB Code Daten Remote Evaluation (uploading) A Code B Daten Code on Demand (downloading) A Daten B Code Mobile Agent (process, not object) A Code Daten Code A Code

4 Extreme Flexibilität dank interpretiertem Code z.B. bei Java: Dynamisches Laden von Klassen (.class) aus Dateisystem oder über Netz Beispiele:  Applets (downloading)  Fernaufruf von Compute Server (uploading)  Per Fernaufruf Vertreterobjekt holen (downloading) (Details: Kap. 9)

5 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

6 7.3.1 Orca Datenabstraktion, Klassen, keine Vererbung, keine Verweise object spec Queue; operation append(item: in integer); operation remove(item: out integer); end; object impl Queue;..... representation operation append... operation remove... begin..... initialization end;

7 Parametermechanismen: Wertparameter in Ergebisparameter out Variablenparameter shared Prozeßtyp: process Producer(q: shared Queue);..... declarations begin..... statements end; Prozeßerzeugung: fork Producer(q); fork Consumer(q);

8 Semantik gemeinsamer Objekte: Serialisierbarkeit Implementierung gemeinsamer Objekte: Leser/Schreiber-Ausschluß gemäß statischer Code-Analyse Replizierte Implementierung, falls Prozesse verteilt:  Replikat bei jedem Prozeß  aktive Replikation (write-update, nicht write-invalidate)  sequentielle Konsistenz duch vollständig geordnete Rundrufe (mittels Sequencer [4.2.3])

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

10 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.

11  Zugriff auf Anker grundsätzlich mit Lese/Schreibsperren, die vom Server (!) verwaltet werden.  Erteilung des Schreibrechts an einen Klienten geht einher mit Invalidierung 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