Slides for a presentation in the course "Distributed Systems " at the University of Applied Sciences Schmalkalden

1. Distributed Programming in Mozart Verteilte Systeme Sebastian Stallenberger FH Schmalkalden WS10/11

2. Gliederung Einleitung Was ist Mozart? Paradigmen Die Entwicklungsumgebung „Hello World“ Verteilte Programmierung in Mozart Grundlagen Language entities Umsetzung der Verteilung Beispiel 2

3. Was ist Mozart? Mozart ist ein Programmiersystem, das auf der Programmiersprache „Oz“ basiert Zusammenarbeit des Deutschen Forschungszentrums für künstliche Intelligenz Schwedischen Instituts für Informatik einigen anderen Instituten Wurde 1995 veröffentlicht, bis heute stetig weiterentwickelt Sollte ursprünglich Probleme mit künstlicher Intelligenz in mobilen Agenten lösen Erzeugt plattformunabhängigen Bytecode, der von einer virtuellen Maschine ausgeführt wird 3

4. Paradigmen Oz ist eine Multi-Paradigmen-Sprache Objektorientierte Programmierung Funktionale Programmierung Logische und Constraint-Programmierung Nebenläufigkeit Verteilung 4

5. Die Entwicklungsumgebung Erhältlich für die wichtigsten Betriebs- systeme Basiert auf Texteditor Emacs Wichtigste Komponenten: Compiler Emulator Debugger Profiler Buffer Browser 5

6. Buffer: Compiler: Im Emulator: Im Browser: „Hello World“ 6

7. Gliederung Einleitung Was ist Mozart? Paradigmen Die Entwicklungsumgebung „Hello World“ Verteilte Programmierung in Mozart Grundlagen Language entities Umsetzung der Verteilung Beispiel 7

8. Grundlagen „verbunden“ – Zwei oder mehr Anwendungen teilen sich eine Referenz auf ein Objekt, über das sie Informationen austauschen können „site“ -> Basiseinheit einer Verteilung Site = Prozess auf einer Maschine Ein Multitasking-System kann mehrere Sites hosten 8

9. Gliederung Einleitung Verteilte Programmierung in Mozart Grundlagen Language entities Statefulentities Single-assignmententities Statelessentities Umsetzung der Verteilung Beispiel 9

10. LE – Statefulentities Statefulentities haben einen Zustand Bei Zustandsänderung -> globale Änderung 10

11. LE – Statefulentities – Objects (1) Cachedobject (auch: mobile objects): Obj={New Class Init} „default“-Einstellung Ersteller-site = „ownersite“ Entfernte sites = „proxysites“ Lokal in entfernter site ausgeführt Site muss sich Objekt holen Solange Objekt auf site bleibt, keine weiteren Nachrichten nötig Wenn mehrere sites das gleiche Objekt wollen, wird fair-share-Verfahren angewandt 11

12. LE – Statefulentities – Objects (2) Cachedobject (Fortsetzung): Ablauf: Proxy site 1 schickt Nachricht an ownersite Ownersite sendet „forwardingrequest“ an proxysite 2, die das Objekt gerade hostet Proxy site 2 übergibt Zeiger auf Objekt an proxysite 1 Klasse eines „cachedobjects“ wird lazily auf jede site kopiert, die das Objekt aufruft. 12

13. LE – Statefulentities – Objects (3) Stationaryobject Obj={NewStat Class Init} Für Server genutzt Bleibt auf ownersite Jede Referenz -> eigener Thread 2 Messages Bei Beginn Nach Ende, um zu synchronisieren Exceptions auf proxysite 13

14. LE – Statefulentities – Objects (4) Sequentialasynchronousstationaryobject Obj={NewSASO Class Init} Nur eine Nachricht Wartet nicht bis Ende Alle Aufrufe werden in gleichem Thread ausgeführt Ausführung sequentiell 14

15. LE – Statefulentities – Other (1) Thread Führt Folge von Anweisungen aus Stationär auf ownersite Kommunikation über gemeinsame Daten Block, wenn diese Daten nicht vorhanden sind Port Port != Port Asynchroner n:1 Kanal, der nach FIFO-Prinzip arbeitet Stationär auf ownersite Nachrichten werden an Stream der ownersite angehängt Mehrere Nachrichten  Reihenfolge des Absendens Stream wird von „future“ beendet 15

16. LE – Statefulentities – Other (2) Cell Updatebare Referenz auf andere Entität Gleiche Semantik wie cachedobjects Bis zu 3 Nachrichten für Aktualisierung der Referenz Wenn cell lokal  keine Nutzung des Netzwerks Thread-reentrant lock Erlaubt nur einem einzigen Thread eine bestimmte Programmregion zu „betreten“ Gleiche Semantik wie cachedobjects oder cells 16

17. LE – Single-assignmententities Wichtige Funktion: Binding Dataflow Variable an Wert gebunden -> alle verteilten Referenzen an selben Wert gebunden 17

18. LE – SAE – Dataflow Variables (1) Logic variable Ähnlich „final“ in Java Können gebunden werden, bevor sie Wert haben Gründe für den Einsatz Effizienz Fehlertoleranz Sind Basis-Mechanismus für gleichläufige Programmierung 18

19. LE – SAE – Dataflow Variables (2) Future Read-onlylogic variable Bei Bindungs-Versuch -> Block z.B. Schutz logischer Variablen vor Bindung durch unauthorisiertesites 19

20. LE – SAE – Stream Kanal zur 1:m Kommunikation Liste mit log. var. oder future als letztes Element Bei Bindung an ownersite wird Bindung asynchron an alle sites geschickt, die den Stream referenziert haben Port + Stream = asynchroner n:m Kanal 20

21. LE - Statelessentities (1) Ohne internen Zustand Effiziente Verteilung Unterscheiden sich durch Art der Kopie Lazy (on demand) Nur Kopie, wenn benötigt Reduziert Netzlast, erhöht Latenz Eager (on supply) Immer Kopie Minimale Latenz, aber Gefahr der Netzüberlastung erlaubte Anzahl an Kopien in einer site 21

22. LE - Statelessentities (2) Records und numbers: Werden „eagerly“ kopiert Procedures, funktions, classes, functors, chunks, atoms und names Werden „eagerly“ übers Netzwerk kopiert Können nur einmal auf einer site existieren Werden „sitedcomponents“ genannt Object-records: Werden „lazily“ kopiert 22

23. Language Entities 23 „Concepts, techniques, andmodelsofcomputerprogramming“ - Peter Van-Roy, Seif Haridi

24. Gliederung Einleitung Was ist Mozart? Paradigmen Die Entwicklungsumgebung „Hello World“ Verteilte Programmierung in Mozart Grundlagen Language entities Umsetzung der Verteilung Beispiel 24

25. Umsetzung der Verteilung Offene Verteilung Geschlossene Verteilung Global naming 25

27. UdV – Naming (2) Tickets Globale Möglichkeit, auf jede Entität zuzugreifen Ähnlich Reference, aber auch außerhalb eines Mozart Prozesses gültig Repräsentiert durch ASCII String z.B. oz-ticket://192.168.6.115:9000/h4074176#1* Explizit erschaffen und dereferenziert Kommuniziert z.B. über Protokolle wie TCP, IP, SMTP zwischen Prozessen Verteilung kann stattfinden: Lokal: über Dateisystem (incl. LAN) Global: über Webserver 27

28. UdV - Module (1) Connection: stellt Basis Mechanismus tickets Anbieten eines Tickets: {Connection.offerOnce X T}{Connection.offerMany X T} Annehmen eines Tickets: {Connection.take T X} Pickle: Erlaubt einer Anwendung, stateless Daten (also Klassen, Prozeduren usw.) laden und zu schreiben {Pickle.save X PathV} {Pickle.load UrlV Value} Um Daten mit Zustand zu verteilen: Cell C={NewCellunit} 28

29. UdV - Module (2) Remote: Einsatz in closeddistribution erlaubt aktiver Anwendung, eine neue „site“ zu erschaffen (auf lokaler oder entfernter Maschine) R={New Remote.managerinit(host:´meine.entfernte.maschine.de´)} init(host: HostV fork: ForkA) Anschließend können neue Funktoren installiert werden über apply() {R apply(F X)} Weitere Methoden: ping(), close() DP: Stellt Konfigurations-Techniken bereit 29

30. Gliederung Einleitung Was ist Mozart? Paradigmen Die Entwicklungsumgebung „Hello World“ Verteilte Programmierung in Mozart Grundlagen Language entities Umsetzung der Verteilung Beispiel 30

31. Danke! „ Doesthe Mozart distribution model giveprogrammers a warm, fuzzyfeelingwhenwritingdistributedapplications? In short, yesitdoes.“ 31