Transcript Vorlesungsfolien vom 19. Dezember

Paradigmen der Programmierung
Nebenläufigkeit
Prof. Dr. Christian Kohls
Informatik, Soziotechnische Systeme
4. Frameworks für nebenläufige Anwendungen
• Actors mit akka
• Play Framework
• Node.js
HINWEIS:
Die Inhalte dieser Folien sind NICHT klausurrelevant.
Sie dienen der Anregung, sich mit diesen Frameworks zu beschäftigen.
akka.io
Akka
• Actor-Framework für Java und Scala
• Ersetzt die bisherigen Actors in Scala
– Funktioniert konzeptionell genau wie bisher
gesehen
– Etwas aufwändigere Einarbeitung:
http://doc.akka.io/docs/akka/2.3.8/intro/getting-started.html
– Effizienter und robuster
Hello Word
mit alten (deprecated) Scala Actors
Hello Word
mit akka (von Typesafe Website)
Receive Methode
Become
Akka: Robuster und effizienter
ActorSystem und Actors
• Actor System ist schwergewichtig und verwaltet 1..N Threads
• Mehrere Actor Systeme gleichzeitig möglich, ein System ist eine logische Einheit
• Actors sind leichtgewichtig und teilen sich Threads
• Standardmäßig verhalten sich akka Actors wie die react Methode
• Ereignis-gesteuerte Schleife: Nachrichten werden verteilt wenn sie eintreffen
• Millionen von Actors gleichzeitig möglich
(Overhead pro Actor ca. 300 Bytes)
Jeder Actor wird durch eine ActorReference gekapselt
• Hierarchie von Actors
• Actors gehören immer zu einem übergeordneten Actor
• Actors können auf Fehler ihrer Kind-Actors reagieren
• „Let it crash“ Modell: System kann sich selbst heilen
Actors in akka
Zu einem akka Actor gehören:
• Actor Reference: kapselt den eigentlichen Actor
• State: interner Zustand
• Behavior: Verhalten
• Mailbox: Verschiedene Strategien (FIFO, Priorität) möglich
• Children: untergeordnete Actors
• Supervisor Strategy: Übergeordneter Actor muss sich um Fehlerbehandlung kümme
Strategien für übergeordneten Actor:
- Untergeordneten Actor wieder anstoßen und
akkumulierten internen Zustand beibehalten
- Untergeordneten Actor neu starten und
akkumulierten internen Zustand verwerfen
- Untergeordneten Actor dauerhaft aufgeben
- Fehler eskalieren, d.h. selbst scheitern
Actors Hierarchie
system.actorOf()
context.actorOf()
-> erzeugt Kind von user
-> erzeugt Kind innerhalb eines Actors
Play web-site
https://www.playframework.com/
Play Framework
•
•
•
•
•
Framework für Webanwendungen
Direkte Unterstützung für Java und Scala
Basiert auf akka
Leichtgewichtige, zustandslose Architektur
Geringe Ressourcennutzung (CPU, Speicher,
Anzahl Threads)
• Typsicherheit bei der Datenverarbeitung
• Große Entwicklercommunity
• Viele erfolgreiche Anwendungen
Beispiel: Extreme Collaboration
Play Framework
• Optimiert für asynchrone Programmierung
• Nicht-blockierende
Verarbeitung von Anfragen
I/O Operationen
• Unterstützung asynchroner Kommunikation mit Clients mit
WebSockets
• Unterstützung asynchroner Verarbeitung serverseitig
• Gute Template-Lösung
• Kosequente Umsetzung des
Model View Controller Ansatzes
Bestandteile
Projekt in Eclipse öffnen
Activator UI
• Verändern von Model, View, Controller im Browser
• Automatisches Kompilieren
Actions und Controller
Requests werden von einer Aktion beantwortet
Aktionen sind Java Methoden, die
- Request Paramter erhalten und verarbeiten
- Ein Resultat an den Client zurücksenden
Mehrere Aktionen werden zu Controllern zusammengefasst
Controller
Action
Result
Resultate
Redirects
Auch Redirects sind Resultate
Asynchrone Controller mit Promise
Jeder Request wird asynchron und nicht-blockierend behandelt
Controller sollten möglichst auch asynchron arbeiten
Action Code sollte nicht blockieren
Kritische Beispiele:
Datenbankaufrufe, Abrufen von Daten via Web Services, lange Berechnungen
Statt eines Resultats wird das Versprechen auf ein Resultat geliefert:
Promise <Result>
Das Versprechen auf ein Resultat wird später eingelöst
- Das Resultat wir dann an den Client geschickt wenn es vorliegt
- Der Action-Code ist längst abgearbeitet und hat nicht blockert
Beim Warten auf das Ergebnis wird nur der Web-Client blockiert, nicht der Server
Promise<Result> statt Result wiedergeben
Actions werden immer asynchron behandelt
Auch hier wird Result intern in ein Promise verpackt
Intern werden also Promise<Result> und Result gleich behandelt
Man könnte sagen, dass beim direkten zurückgeben von Result
das Versprechen schneller eingelöst wird.
In jedem Fall wird das Resultat asynchron empfangen
Von Routes zu Controller-Actions
Von Controller-Actions zu Views
…und mittendrin das Datenmodell
Controller und Views
- HTTP Request ist ein Event
- Routes leiten die Anfrage an einen Action-Handler eines Controller weiter
- Action-Handler verändert gffs. das Datenmodel
- Weitergeleitet wird an einen View
- Views können unabhängig voneinander existieren und verschiedene
Sichten auf die gleichen Daten liefern
Views erzeugen mit Templates
Scala Templates sind Textdateien mit kleinen Scala Code-Blöcken
Erzeugt werden textbasierte Formate, z.B. HTML, XML, CSV,…
Beispiel-Template:
Template Parameter
Beginn eines
dynamischen Ausdrucks
Iteration
Anforderungen an die Seitengestaltung
Vorlagen-Bausteine
unabhängig
anpassen
Unterschiedliche Inhalte
in gleiche Vorlagen
einbauen
 Trennung von Inhalt und Layout ist erforderlich!
Gleiche Inhalte
in unterschiedlichen
Vorlagen nutzen
Das Modell
• Business-Logik in package model festlegen
• Playframework ist zustandslos
• Persistente Datenhanltung über
– Datenbank
– Cache (möglicher Datenverlust)
– Flash/Session Scrope
(via Cookies, daher nur Strings und max 4KB)
Model View Controller (MVC)
Verändern,
bearbeiten
Aktualisieren
Model
Controller
Controller
Controller
Controller
View
View
View
View
nutzt
sieht
User
Vorteile MVC
• Ermöglicht Wartung und Entwicklung des Designs
unabhängig von der Codebasis
• Emöglicht schrittweisen Aufbau einer Webanwendung
• Ermöglicht neue Repräsentation der gleichen Daten
• Ermöglicht Arbeitsteilung im Projekt
• Ermöglicht die Wiederverwendung von
Funktionalitäten einer Webanwendung
• Ermöglicht Skalierbarkeit
Fallbeispiel: e-teaching.org
Umfangreiche Inhalte
1200+ Inhaltsseiten
80+ PDF Dokumente
100+ Produktsteckbriefe
150+ Referenzbeispiele
500+ Glossarbegriffe
2000+ Blogeinträge
Community-Funktionen
-Visitenkarte
-Vernetzung der Mitglieder
-Forum und Blog
-Linklisten
-Projektdatenbank
Verschiedene Anwender
-Nutzer
-Mitglieder
-Partnerhochschulen
-Redakteure
-Landesportale
e-teaching.org
Angepasst an die verschiedenen Nutzer
e-teaching.org
Angepasst an die verschiedenen Nutzer
Community-Mitglieder
e-teaching.org-Redaktion
Hochschul-Redakteure
Landesportal
e-teaching.org
Angepasst an die verschiedenen Nutzer
Community-Mitglieder
e-teaching.org-Redaktion
Hochschul-Redakteure
Landesportal
e-teaching.org
Angepasst an die verschiedenen Nutzer
Community-Mitglieder
e-teaching.org-Redaktion
Hochschul-Redakteure
Landesportal
e-teaching.org
Angepasst an die verschiedenen Nutzer
Community-Mitglieder
e-teaching.org-Redaktion
Hochschul-Redakteure
Landesportal
e-teaching.org
Sichten auf spezielle Inhaltstypen
Produktsteckbriefe
Projektdatenbank
Referenzbeispiele
Community-Events
Veranstaltungen
E-Teacher
Weiterbildung
Audio-Pod
Realisierung e-teaching.org mit Plone / ZOPE und Python
Webframework basierend auf JavaScript
Node.js und Express
Framework
• Serverseitige Plattform für
Netzwerkanwendungen
• Basiert auf der JavaScript Laufzeitumgebung „V8“
• Ereignisgesteuerte Architektur
• Optimiert für verteilte, daten-intensive
Echtzeitanwendung
Struktur
Eigene Module
Öffentliche Dateien: JavaScript, CSS, Bilder…
Model
View
Controller
Hauptanwendung
Externe Module
Single Thread Event Loops
Server starten
> node myappserver.js
Programm-Logik
Clientseitiges Javascript
IdeaWall.js (client-seitig)
Synchroner vs. asynchroner Seitenaufbau
Web-Server
Benutzeraktionen ändern die Seite
ohne Zugriff auf den Server
Xjdooi dof
Oidufio df
pifdp
Web-Server
Aktualisierung von
Seitenteilen statt
Ganzer Seiten
Asynchrone Verarbeitung
auch auf dem Server
Ausblick
Visuelle Programmierung
Entwurfmuster (Softwaredesign)