dr. welf löwe und markus noga1 verteilte speicherbereinigung problem –verteilung von komponenten...
TRANSCRIPT
Dr. Welf Löwe und Markus Noga 1
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
Dr. Welf Löwe und Markus Noga 2
Modell
Ein verteiltes System besteht aus diskjunten (Adress-) RäumenRä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
Dr. Welf Löwe und Markus Noga 3
Modell
Raum Raum Raum
Komponenteninstanz
Komponenteninstanz
Komponenteninstanz
Komponenteninstanz
Schlüssel Bezug
Schlüssel Bezug
Bezug
Dr. Welf Löwe und Markus Noga 4
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
Dr. Welf Löwe und Markus Noga 5
Kriterien für Verfahren
Erkennen von Zyklen– Transitive Selbstbezüge ohne Einstieg über Bezug aus aktivem
Programm– Über Räume hinweg
SkalierbarSicherheit gegen Ausfall von RäumenResistent gegen Probleme mit Nachrichten– Verdopplung– Vertauschung– Verlust
Implementiert
Dr. Welf Löwe und Markus Noga 6
Überblick
Klassisches TracingReferenzzählen– naiv– gewichtet
ReferenzlistenHybridverfahren– Migration von Objekten– Probelöschen
Verteiltes Tracing– Zeitstempel
Dr. Welf Löwe und Markus Noga 7
Klassisches Tracing
System anhaltenLokal lebendige Komponenten markierenAlle von ihnen global erreichbaren Komponenten markierenNicht markierte Komponenten freigebenTheoretisch einfach, praktisch unbrauchbar. Leistung furchtbar.
Raum
Komponente
Schlüssel
Dr. Welf Löwe und Markus Noga 8
Naives Referenzzählen
Anzahl der Bezüge B im Schlüssel zählenFreigabe wenn B=0 Nachricht an Besitzer bei Duplizieren und LöschenNachteile– 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
Dr. Welf Löwe und Markus Noga 9
Raum
Gewichtetes Referenzzählen
Gewicht des Schlüssels WTeilgewicht der Bezüge Ti
W= Ti
Löschen bei W=0Nachricht nur bei LöschenDuplizieren: Ti aufteilen
Vorteile– Weniger Nachrichten– Verträgt Vertauschung
Probleme– keine Zyklenerkennung– Falsche Freigabe u. Behalten– Neu: Aufteilbarkeit
Raum
Komponente
Schlüssel W=1.0
BezugT=0.5
Dr. Welf Löwe und Markus Noga 10
Mögliche Verbesserungen
Optimiertes gewichtetes Referenzzählen– Invariante abschwächen: W Ti– 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
Dr. Welf Löwe und Markus Noga 11
Raum 2
Referenzlisten
Menge aller Benutzer B im Schlüssel speichernLöschen bei B=Nachricht bei Duplizieren und LöschenVorteile– Verträgt Verdopplung– Raumausfall behandelbar
Nachteile– Viele Nachrichten– Verlust, Vertauschung ungelöst
Raum 1
Komponente
Schlüssel B={2, …}
Bezug
Dr. Welf Löwe und Markus Noga 12
Hybridverfahren: Migration
Annahmen– Referenzzählen oder
Referenzlisten– Lokale GC
Idee– Migriere lokal tote, global
lebendige KomponentenVorteil– Globale Zyklen werden lokal
und von der GC beseitigtProbleme– Umgang mit Indirektionen– Migration u.U. unmöglich
Raum
Raum
K 1
K 2
K 2
Dr. Welf Löwe und Markus Noga 13
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
Dr. Welf Löwe und Markus Noga 14
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
Dr. Welf Löwe und Markus Noga 15
Beispiel: Tracing mit Zeitstempeln
Raum 2
Raum 3Raum 1
ZeitabstimmungR={1,2,3,…}
f: RTminRf
Kt=2
Kt=3
Kt=1
Kt=2
Kt=3
Kt=2
Dr. Welf Löwe und Markus Noga 16
Beispiel: Tracing mit Zeitstempeln
Raum 2
Raum 3Raum 1
ZeitabstimmungR={1,2,3,…}
f: RTminRf
Kt=2
Kt=3
Kt=4
Kt=2
Kt=3
Kt=2
f(1)=4, minRf=2
t=4
Dr. Welf Löwe und Markus Noga 17
Beispiel: Tracing mit Zeitstempeln
Raum 2
Raum 3Raum 1
ZeitabstimmungR={1,2,3,…}
f: RTminRf
Kt=2
Kt=3
Kt=4
Kt=4
Kt=3
f(2)=5, minRf=3t=4
Dr. Welf Löwe und Markus Noga 18
Beispiel: Tracing mit Zeitstempeln
Raum 2
Raum 3Raum 1
ZeitabstimmungR={1,2,3,…}
f: RTminRf
Kt=4
Kt=3
Kt=4
Kt=4
f(3)=6, minRf=4
Dr. Welf Löwe und Markus Noga 19
Beispiel: Tracing mit Zeitstempeln
Raum 2
Raum 3Raum 1
ZeitabstimmungR={1,2,3,…}
f: RTminRf
Kt=2
Kt=7
Kt=4
f(1)=7, minRf=5
t=7
Dr. Welf Löwe und Markus Noga 20
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
Dr. Welf Löwe und Markus Noga 21
Bewertung
Zyklen Skaliert Raum-ausfall
Verdop-pelung
Vertau-schung
Verlust Impl.
Referenzzählen
gewichtet
Referenzlisten
Hybride () ()
Zeitstempel () n.a n.a n.a
Dr. Welf Löwe und Markus Noga 22
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
Aktive verteilte DokumenteEine XML-basierte Architektur
Markus L. NogaDoktorandenseminar IPD
29.6.2001
Dr. Welf Löwe und Markus Noga 24
Was bisher geschah
Bisher– Komponenten zentrales Konzept– Daten untergeordnet
Jetzt duale SichtBeschreibung von XML Daten– XML Schema
Erweiterung auf Komponenten– Negativbeispiel: WSDL
Kommunikation via XML– Negativbeispiel: SOAP
Referenzen auf Komponenten
Dr. Welf Löwe und Markus Noga 25
Ziel
Vereine Daten und KomponentenAktive verteilte Dokumente– Statische Daten– Dynamische Generatoren– Verteilung– Bearbeitung
Dr. Welf Löwe und Markus Noga 26
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 DokumenteBenutzbarkeitTransparente Verteilung
Dr. Welf Löwe und Markus Noga 27
Gliederung
Stand der Technik– Basistechnologie– Verwandte Anwendungen
Architektur– Domäne– Schichten
Technische FragenAusblick
Dr. Welf Löwe und Markus Noga 28
Stand der Technik
Basistechnologie (bekannt)– XML Schema– SOAP– DOM
Verwandte Anwendungen– Textverarbeitung– Tabellenkalkulation– Das Netz– Industrielle Komponentensysteme
Dr. Welf Löwe und Markus Noga 29
Textverarbeitung
Löst: Lokale Bearbeitung von TextenVertreter: Microsoft WordErweiterbare hierarchische DokumenteGeneratoren nicht transparentInkrementelle BearbeitungKeine Typen, keine ValidierungBenutzerfreundlichKeine Verteilung
Dr. Welf Löwe und Markus Noga 30
Tabellenkalkulation
Löst: Aktives lokales DokumentVertreter: Microsoft ExcelStarre DokumenteGeneratoren transparentInkrementelle BearbeitungKeine Typen, keine ValidierungBenutzerfreundlichKeine Verteilung
Dr. Welf Löwe und Markus Noga 31
Das Netz
Löst: Verteiltes Lesen von DokumentenVertreter: HTTP/HTMLErweiterbare hierarchische DokumenteGeneratoren nicht für TeileKeine inkrementelle BearbeitungKeine Typen, keine ValidierungBenutzerfreundlichVerteilt
Dr. Welf Löwe und Markus Noga 32
Komponentensystem
Löst: Verteilung von KomponentenVertreter: Corba, COM, EJBKein Begriff des DokumentsStarke TypisierungNur von Experten verwendbarVerteilt
Dr. Welf Löwe und Markus Noga 33
Stand der Technik: Fazit
System K1 K2 K3 K4 K5 K6
Textverarbeitung
Tabellenkalkulation
Das Netz
Komponenten
Dr. Welf Löwe und Markus Noga 34
Architektur: Betrachtete Domäne
Aktive verteilte Dokumente sind Wälder von KnotenKnoten sind typisierte Behälter– Werte– Teilbäume– Generatoren für Werte– Generatoren für Teilbäume
Uniform referentTransparent gegenüber Verteilung
Dr. Welf Löwe und Markus Noga 35
Schichten
EditorsEditors
Bidirectional XML Transport Protocol
DOM / Generators
DOM / Values
User InterfaceEditors
Dr. Welf Löwe und Markus Noga 36
Transportprotokoll
Anforderungen– Feingranular– Bidirektional – Änderungspropagation
Konstruktion– Erweitere URL um Feinadressierung– Expliziter Kontext im Rückkanal– Komplementiere Pull mit Push
Dr. Welf Löwe und Markus Noga 37
DOM mit Generatoren
Erweiterung des DOMGeneratorknoten kapselt– Verweis– Abfrage (z.B. XPath)– Transformation (z.B. Untermenge XSLT)– Programm
Jeweils verteiltGenerator ist BlattKeine Typen
Dr. Welf Löwe und Markus Noga 38
DOM mit Werten
Schnittstelle ist DOM Generatoren durch Werte ersetztDynamische Aktualisierung– bei Änderung der Quelle– bei Änderung der Sicht
• wo technisch möglich• wo zulässig
Typen und Validierung
Dr. Welf Löwe und Markus Noga 39
Benutzerschnittstelle
Allgemeiner XML-Editor– Visualisierung als Baum, Text etc.
Dynamischer Wechsel zwischen– Generatorensicht– Wertesicht
Einbettung spezieller Editoren nach– Elementtyp– Benutzereinstellungen
Dr. Welf Löwe und Markus Noga 40
Spezielle Editoren
DOM/V nutzt– Werte– Dyn. Verbindung
DOM/G zusätzlich– Generatoren– Schachtelung
Beispiele– Read: HTML, SVG– Write: Tabelle
Writ
e
DOM/V
Read
DOM/G
Edit
View
SmartEdit
Smart View
Dr. Welf Löwe und Markus Noga 41
Technik: DOM Operationen
DOM ist attributierter BaumVollständige Operatormenge– Knoten einfügen– Knoten löschen– Attribute ändern
Für die Praxis zusätzlich– Cut/Paste von Teilbäumen
Semantik, Umsetzung klar
Dr. Welf Löwe und Markus Noga 42
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
Dr. Welf Löwe und Markus Noga 43
Zyklische Bezüge
Führen in unendliche RekursionVermeidung nicht möglichErkennen– Verteilung stört traditionelle Ansätze– Nutze Erkenntnisse der verteilten GC?
Auflösen– Dem Nutzer überlassen– Fixpunkt-Iteration?
Dr. Welf Löwe und Markus Noga 44
Werden die Kriterien erfüllt?
System K1 K2 K3 K4 K5 K6
Textverarbeitung
Tabellenkalkulation
Das Netz
Komponenten
Aktive Dokumente
Dr. Welf Löwe und Markus Noga 45
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?
Dr. Welf Löwe und Markus Noga 46
Fazit der Veranstaltung
1. Einführung– Motivation– Definition, – Konzepte für Komponenten (klassische, kommerzielle, akademische)
2. Industrielle Komponentensysteme der 1. Generation1. CORBA 2. Enterprise JavaBeans3. (D)COM
3. Anpassungen – Daten und Funktion– Interaktion
• Kommunikation• Synchronisation• Protokolle
– Lebendigkeit
Dr. Welf Löwe und Markus Noga 47
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
Dr. Welf Löwe und Markus Noga 48
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
Dr. Welf Löwe und Markus Noga 49
Klassische Komponentensysteme
Wie Männer - Im Prinzip alle gleichGelöste Probleme– Verteilung von Komponenten– Kommunikation über Standardschnittstellen
• Stub und Proxy• Verteilte Referenzen
– Heterogene Komponenten und Komponentensysteme
Ungelöste Probleme– Anpassungen– Entwurf
Dr. Welf Löwe und Markus Noga 50
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
Dr. Welf Löwe und Markus Noga 51
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
Studien- / Diplomarbeiten im EU Projekt EASYCOMP Dynamic
Composition
ComponentModels andSpecification
Process Support
Case Studies
Case Studies
Case StudiesC
ase
Stud
ies
Aspect-basedComposition
CompositionConsistencyChecking
CompositionTechnology
EasyComp
Komponenten
Repräsentation
Verarbeitung & Komposition
Verifikation
Interesse?Ansprechperson: Elke Pulvermü[email protected] oder Geb.50.41 (AVG), 2.OG
Dr. Welf Löwe und Markus Noga 53
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 Nogaloewe|[email protected] Geb.50.41 (AVG), 2.OG
Lehre
Dr. Welf Löwe und Markus Noga 55
Dr. Welf Löwe und Markus Noga 56
Dr. Welf Löwe und Markus Noga 57
Dr. Welf Löwe und Markus Noga 58
Dr. Welf Löwe und Markus Noga 59
Dr. Welf Löwe und Markus Noga 60