Dr. Welf Löwe und Markus Noga1 Verteilte Speicherbereinigung Problem –Verteilung von Komponenten –Bezüge auf ferne Komponenten möglich –Wann löschen? Ansätze.

Präsentation zum Thema: "Dr. Welf Löwe und Markus Noga1 Verteilte Speicherbereinigung Problem –Verteilung von Komponenten –Bezüge auf ferne Komponenten möglich –Wann löschen? Ansätze."—  Präsentation transkript:

1 Dr. Welf Löwe und Markus Noga1 Verteilte Speicherbereinigung Problem –Verteilung von Komponenten –Bezüge auf ferne Komponenten möglich –Wann löschen? Ansätze –Explizit durch Benutzer vorgeben Verlagert das Problem, löst es nicht In klassischen Sprachen (C, C++) häufigste Fehlerquelle! –Automatisch durch Laufzeitsystem Korrektheit Effizienz? Modell aufstellen

2 Dr. Welf Löwe und Markus Noga2 Modell Ein verteiltes System besteht aus diskjunten (Adress-) Räumen Räume kommunizieren über Nachrichten –Mögliche Probleme der Nachrichten Verdopplung Vertauschung Verlust Ein Raum enthält –Komponenten –Bezüge auf (lokale und) ferne Komponenteninstanzen Bezüge nur auf Instanzen exportierter Komponenten

3 Dr. Welf Löwe und Markus Noga3 Modell Raum Komponenten instanz Schlüssel Bezug Schlüssel Bezug

4 Dr. Welf Löwe und Markus Noga4 Operationen auf Bezügen Anlegen –Besitzer einer Komponenteninstanz sendet Bezug –ggf. Schlüssel erzeugen Duplizieren –Inhaber eines Bezuges kopiert ihn –Sendet an fremden Raum Löschen –Manuell –Automatisch durch Speicherbereinigung Austausch von Nachrichten zwischen Räumen als Implementierung

5 Dr. Welf Löwe und Markus Noga5 Kriterien für Verfahren Erkennen von Zyklen –Transitive Selbstbezüge ohne Einstieg über Bezug aus aktivem Programm –Über Räume hinweg Skalierbar Sicherheit gegen Ausfall von Räumen Resistent gegen Probleme mit Nachrichten –Verdopplung –Vertauschung –Verlust Implementiert

6 Dr. Welf Löwe und Markus Noga6 Überblick Klassisches Tracing Referenzzählen –naiv –gewichtet Referenzlisten Hybridverfahren –Migration von Objekten –Probelöschen Verteiltes Tracing –Zeitstempel

7 Dr. Welf Löwe und Markus Noga7 Klassisches Tracing System anhalten Lokal lebendige Komponenten markieren Alle von ihnen global erreichbaren Komponenten markieren Nicht markierte Komponenten freigeben Theoretisch einfach, praktisch unbrauchbar. Leistung furchtbar. Raum Komponente Schlüssel

8 Dr. Welf Löwe und Markus Noga8 Naives Referenzzählen Anzahl der Bezüge B im Schlüssel zählen Freigabe wenn B=0 Nachricht an Besitzer bei Duplizieren und Löschen Nachteile –Zyklen nicht erkennbar –Falsche Freigabe bei Verdopplung Löschen Vertauschung Duplizieren/Löschen Verlust Duplizieren –Falsches Behalten bei Verlust Löschen Raum Komponente Schlüssel B=1

9 Dr. Welf Löwe und Markus Noga9 Raum Gewichtetes Referenzzählen Gewicht des Schlüssels W Teilgewicht der Bezüge T i W=  T i Löschen bei W=0 Nachricht nur bei Löschen Duplizieren: T i aufteilen Vorteile –Weniger Nachrichten –Verträgt Vertauschung Probleme –keine Zyklenerkennung –Falsche Freigabe u. Behalten –Neu: Aufteilbarkeit Raum Komponente Schlüssel W=1.0 Bezug T=0.5

10 Dr. Welf Löwe und Markus Noga10 Mögliche Verbesserungen Optimiertes gewichtetes Referenzzählen –Invariante abschwächen: W   T i –Wenn Teilgewicht nicht aufteilbar, auf 0 setzen –Gelegentlich anderes Verfahren einsetzen, das ursprüngliche Invariante wiederherstellt (z.B. klassisches Vorgehen) –Verbesserung Aufteilung von Teilgewichten Verträgt Verlust von Nachrichten Vorteile des anderen Verfahrens Indirektes gewichtetes Referenzzählen –Einführen indirekter Schlüssel –Verbesserung Aufteilung von Teilgewichten

11 Dr. Welf Löwe und Markus Noga11 Raum 2 Referenzlisten Menge aller Benutzer B im Schlüssel speichern Löschen bei B=  Nachricht bei Duplizieren und Löschen Vorteile –Verträgt Verdopplung –Raumausfall behandelbar Nachteile –Viele Nachrichten –Verlust, Vertauschung ungelöst Raum 1 Komponente Schlüssel B= {2, …} Bezug

12 Dr. Welf Löwe und Markus Noga12 Hybridverfahren: Migration Annahmen –Referenzzählen oder Referenzlisten –Lokale GC Idee –Migriere lokal tote, global lebendige Komponenten Vorteil –Globale Zyklen werden lokal und von der GC beseitigt Probleme –Umgang mit Indirektionen –Migration u.U. unmöglich Raum K 1 K 2

13 Dr. Welf Löwe und Markus Noga13 Hybridverfahren: Probelöschen Annahme –Referenzzählen oder Referenzlisten –Heuristik für tote Komponenten (z.B. lokale GC) Idee –Lösche vermutlich tote Komponenten probeweise –Prüfe ob dabei alle Referenzen verschwinden Vorteil –Globale Zyklen werden erkannt Probleme –Konkurrierende Probelöschungen –Steht und fällt mit Heuristik

14 Dr. Welf Löwe und Markus Noga14 Tracing mit Zeitstempeln Annahme –Globaler Dienst zur Zeitabstimmung Idee –Objekte mit Zeitstempeln markieren –Lokale GC propagiert sie entlang der Bezüge –Tote Komponenten haben alte Zeitstempel Vorteil –Nur lokales Anhalten –Globale Zyklen werden erkannt –Verträgt Vertauschung und Verdoppelung Nachteil –Abstimmungsdienst skaliert schlecht –Ausfall eines Raums macht lokale GC unmöglich –Verlust von Nachrichten ungelöst

15 Dr. Welf Löwe und Markus Noga15 Beispiel: Tracing mit Zeitstempeln Raum 2Raum 3Raum 1 Zeitabstimmung R={1,2,3,…} f: R  T min R f K t=2 K t=3 K t=1 K t=2 K t=3 K t=2

16 Dr. Welf Löwe und Markus Noga16 Beispiel: Tracing mit Zeitstempeln Raum 2Raum 3Raum 1 Zeitabstimmung R={1,2,3,…} f: R  T min R f K t=2 K t=3 K t=4 K t=2 K t=3 K t=2 f(1)=4, min R f=2 t=4

17 Dr. Welf Löwe und Markus Noga17 Beispiel: Tracing mit Zeitstempeln Raum 2Raum 3Raum 1 Zeitabstimmung R={1,2,3,…} f: R  T min R f K t=2 K t=3 K t=4 K t=4 K t=3 f(2)=5, min R f=3 t=4

18 Dr. Welf Löwe und Markus Noga18 Beispiel: Tracing mit Zeitstempeln Raum 2Raum 3Raum 1 Zeitabstimmung R={1,2,3,…} f: R  T min R f K t=4 K t=3 K t=4 K t=4 f(3)=6, min R f=4

19 Dr. Welf Löwe und Markus Noga19 Beispiel: Tracing mit Zeitstempeln Raum 2Raum 3Raum 1 Zeitabstimmung R={1,2,3,…} f: R  T min R f K t=2 K t=7 K t=4 f(1)=7, min R f=5 t=7

20 Dr. Welf Löwe und Markus Noga20 Mögliche Erweiterungen Hierarchie einführen –Skaliert besser Übergang zu Zeitlisten –Ein Zeitstempel pro benutzendem Raum –Ausfall von Räumen bewältigbar Bündelung von Updates –reduziert Anzahl der Nachrichten

21 Dr. Welf Löwe und Markus Noga21 Bewertung ZyklenSkaliertRaum- ausfall Verdop- pelung Vertau- schung VerlustImpl. Referenzzählen gewichtet Referenzlisten Hybride ( ) ( ) Zeitstempel ( )n.a

22 Dr. Welf Löwe und Markus Noga22 Industrielle Praxis COM, Corba –Referenzzählen Enterprise JavaBeans –Lokale GC Transportkanal sichert gegen –Verlust –Verdopplung –Lokale Vertauschung Entwurf muß absichern gegen –Globale Vertauschung –Zyklen Z.B. durch Schichtenmodell

23 Aktive verteilte Dokumente Eine XML-basierte Architektur Markus L. Noga Doktorandenseminar IPD 29.6.2001

24 Dr. Welf Löwe und Markus Noga24 Was bisher geschah Bisher –Komponenten zentrales Konzept –Daten untergeordnet Jetzt duale Sicht Beschreibung von XML Daten –XML Schema Erweiterung auf Komponenten –Negativbeispiel: WSDL Kommunikation via XML –Negativbeispiel: SOAP Referenzen auf Komponenten

25 Dr. Welf Löwe und Markus Noga25 Ziel Vereine Daten und Komponenten Aktive verteilte Dokumente –Statische Daten –Dynamische Generatoren –Verteilung –Bearbeitung

26 Dr. Welf Löwe und Markus Noga26 Kriterien Erweiterbare Dokumente –K1 Erweiterbar, hierarchisch organisiert –K2 Transparente Erzeugung von Teilen Benutzbarkeit –K3 Inkrementelle Bearbeitung –K4 Typen und Validierung –K5 Benutzerfreundlich K6 Transparente Verteilung Erweiterbare Dokumente Benutzbarkeit Transparente Verteilung

27 Dr. Welf Löwe und Markus Noga27 Gliederung Stand der Technik –Basistechnologie –Verwandte Anwendungen Architektur –Domäne –Schichten Technische Fragen Ausblick

28 Dr. Welf Löwe und Markus Noga28 Stand der Technik Basistechnologie (bekannt) –XML Schema –SOAP –DOM Verwandte Anwendungen –Textverarbeitung –Tabellenkalkulation –Das Netz –Industrielle Komponentensysteme

29 Dr. Welf Löwe und Markus Noga29 Textverarbeitung Löst: Lokale Bearbeitung von Texten Vertreter: Microsoft Word Erweiterbare hierarchische Dokumente Generatoren nicht transparent Inkrementelle Bearbeitung Keine Typen, keine Validierung Benutzerfreundlich Keine Verteilung

30 Dr. Welf Löwe und Markus Noga30 Tabellenkalkulation Löst: Aktives lokales Dokument Vertreter: Microsoft Excel Starre Dokumente Generatoren transparent Inkrementelle Bearbeitung Keine Typen, keine Validierung Benutzerfreundlich Keine Verteilung

31 Dr. Welf Löwe und Markus Noga31 Das Netz Löst: Verteiltes Lesen von Dokumenten Vertreter: HTTP/HTML Erweiterbare hierarchische Dokumente Generatoren nicht für Teile Keine inkrementelle Bearbeitung Keine Typen, keine Validierung Benutzerfreundlich Verteilt

32 Dr. Welf Löwe und Markus Noga32 Komponentensystem Löst: Verteilung von Komponenten Vertreter: Corba, COM, EJB Kein Begriff des Dokuments Starke Typisierung Nur von Experten verwendbar Verteilt

33 Dr. Welf Löwe und Markus Noga33 Stand der Technik: Fazit SystemK1K2K3K4K5K6 Textverarbeitung Tabellenkalkulation Das Netz Komponenten

34 Dr. Welf Löwe und Markus Noga34 Architektur: Betrachtete Domäne Aktive verteilte Dokumente sind Wälder von Knoten Knoten sind typisierte Behälter –Werte –Teilbäume –Generatoren für Werte –Generatoren für Teilbäume Uniform referent Transparent gegenüber Verteilung

35 Dr. Welf Löwe und Markus Noga35 Schichten Editors Bidirectional XML Transport Protocol DOM / Generators DOM / Values User Interface Editors

36 Dr. Welf Löwe und Markus Noga36 Transportprotokoll Anforderungen –Feingranular –Bidirektional –Änderungspropagation Konstruktion –Erweitere URL um Feinadressierung –Expliziter Kontext im Rückkanal –Komplementiere Pull mit Push

37 Dr. Welf Löwe und Markus Noga37 DOM mit Generatoren Erweiterung des DOM Generatorknoten kapselt –Verweis –Abfrage (z.B. XPath) –Transformation(z.B. Untermenge XSLT) –Programm Jeweils verteilt Generator ist Blatt Keine Typen

38 Dr. Welf Löwe und Markus Noga38 DOM mit Werten Schnittstelle ist DOM Generatoren durch Werte ersetzt Dynamische Aktualisierung –bei Änderung der Quelle –bei Änderung der Sicht wo technisch möglich wo zulässig Typen und Validierung

39 Dr. Welf Löwe und Markus Noga39 Benutzerschnittstelle Allgemeiner XML-Editor –Visualisierung als Baum, Text etc. Dynamischer Wechsel zwischen –Generatorensicht –Wertesicht Einbettung spezieller Editoren nach –Elementtyp –Benutzereinstellungen

40 Dr. Welf Löwe und Markus Noga40 Spezielle Editoren DOM/V nutzt –Werte –Dyn. Verbindung DOM/G zusätzlich –Generatoren –Schachtelung Beispiele –Read: HTML, SVG –Write: Tabelle

41 Dr. Welf Löwe und Markus Noga41 Technik: DOM Operationen DOM ist attributierter Baum Vollständige Operatormenge –Knoten einfügen –Knoten löschen –Attribute ändern Für die Praxis zusätzlich –Cut/Paste von Teilbäumen Semantik, Umsetzung klar

42 Dr. Welf Löwe und Markus Noga42 Semantik auf DOM/V Einfügen –Was? –Wo? Löschen –Was? Ändern –Was? Auswirkungen propagieren Generatoren –Verweis –Abfrage –Transformation –Programm Abbildung i.A. –nicht umkehrbar –nicht hinreichend

43 Dr. Welf Löwe und Markus Noga43 Zyklische Bezüge Führen in unendliche Rekursion Vermeidung nicht möglich Erkennen –Verteilung stört traditionelle Ansätze –Nutze Erkenntnisse der verteilten GC? Auflösen –Dem Nutzer überlassen –Fixpunkt-Iteration?

44 Dr. Welf Löwe und Markus Noga44 Werden die Kriterien erfüllt? SystemK1K2K3K4K5K6 Textverarbeitung Tabellenkalkulation Das Netz Komponenten Aktive Dokumente

45 Dr. Welf Löwe und Markus Noga45 Ausblick Berücksichtige Erkenntnisse aus –Attributgrammatiken –Funktionalen Sprachen Verfeinere Architektur –Schnittstellen der Schichten –Zusammenspiel Beachte Einsatz von –Standardwerkzeugen –Eigenentwicklungen des IPD Umsetzen –mit Ihrer Hilfe?

46 Dr. Welf Löwe und Markus Noga46 Fazit der Veranstaltung 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle, akademische) 2. Industrielle Komponentensysteme der 1. Generation 1. CORBA 2. Enterprise JavaBeans 3. (D)COM 3. Anpassungen –Daten und Funktion –Interaktion Kommunikation Synchronisation Protokolle –Lebendigkeit

47 Dr. Welf Löwe und Markus Noga47 Einführung Definition –Programmeinheiten mit standardisierter Basiskommunikation –Standardisierte Verträge für Wiederverwendung –Anpassungen nötig Immer zusammen zu betrachten –Komponente und –Wechselnde Umgebungen Unterscheidung –Statische Komponente (Programm oder Spezifikation) –Dynamische Instanz einer Komponente

48 Dr. Welf Löwe und Markus Noga48 Einführung Objektorientiertes Programmieren –Bibliotheken –Frameworks Aspektorientiertes Programmieren –Sichten auf ein System (Abstraktion) unterschiedlich beschreiben –Weben des Systems (Konkretisierung) oft unklar Architektursysteme –Begriff der Ports –Programmpunkte zur Adaption der Kommunikation Metaprogrammierung –Uraltes Konzept: Programme sind Daten (bekannt seit Lisp) –Methode zur Anpassung von Komponenten

49 Dr. Welf Löwe und Markus Noga49 Klassische Komponentensysteme Wie Männer - Im Prinzip alle gleich Gelöste Probleme –Verteilung von Komponenten –Kommunikation über Standardschnittstellen Stub und Proxy Verteilte Referenzen –Heterogene Komponenten und Komponentensysteme Ungelöste Probleme –Anpassungen –Entwurf

50 Dr. Welf Löwe und Markus Noga50 Anpassungen Daten –XML zur Datenbeschreibung –XSLT zur Transformation Funktionalität –Umwickeln der Komponenten (wrapper) –Einmischen der Wrapper mit Metaprogrammierung Kommunikation und Synchronisation –Erkenne Kommunikations- und Synchronisationspunkte –Beschreibe sie abstrakt –Konkretisierung durch Metaprogramm Protokolle und Lebendigkeit –Dynamisch –Statisch schwierig, da aufwendige Analyse nötig

51 Dr. Welf Löwe und Markus Noga51 Offene Probleme Entwurf von Komponentensystemen –Vordefinierte Komponenten –Nichtfunktionale Leistungskriterien (Bandbreite, Verfügbarkeit, etc.) Re-Engineering von Altsystemen –Erkennen von Komponenten und Kommunikation in Altsystemen Profiling und Metriken statische Analysen Visualisierung von Software –Anpassungen Lernkurve senken –Bessere Bücher für Einsteiger –Dokumentation generieren

52 Studien- / Diplomarbeiten im EU Projekt EASYCOMP Dynamic Composition Component Models and Specification Process Support Case Studies Aspect-based Composition Consistency Checking Composition Technology EasyComp Komponenten  Repräsentation  Verarbeitung & Komposition  Verifikation Interesse? Ansprechperson: Elke Pulvermüller pulvermu@ipd.info.uni-karlsruhe.de oder Geb.50.41 (AVG), 2.OG

53 Dr. Welf Löwe und Markus Noga53 Studien- und Diplomarbeiten XML und Webkomponenten in einem Industrieprojekt –SOAP, WSDL, UDDI etc. –.NET und EJB –Castor –XML Protocol,... XML und GUI Building –Uniforme Beschreibung von GUIs mit XML –Abbildung auf das Web und klassische APIs HTML Formulare(via XSLT) Java/Swing (Codegenerierung oder Werkzeuganbindung) Ansprechpartner: Löwe und Noga loewe|noga@ipd.info.uni-karlsruhe.de Geb.50.41 (AVG), 2.OG

54 Lehre

55 Dr. Welf Löwe und Markus Noga55

56 Dr. Welf Löwe und Markus Noga56

57 Dr. Welf Löwe und Markus Noga57

58 Dr. Welf Löwe und Markus Noga58

59 Dr. Welf Löwe und Markus Noga59

60 Dr. Welf Löwe und Markus Noga60