Paradigmen der Programmierung Nebenläufigkeit Prof. Dr. Christian Kohls Informatik, Soziotechnische...

Paradigmen der Programmierung NebenläufigkeitProf. Dr. Christian KohlsInformatik, 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 Wordmit alten (deprecated) Scala Actors

Hello Wordmit 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ümmern

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() -> erzeugt Kind von usercontext.actorOf() -> 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-blockierendeVerarbeitung von AnfragenI/O Operationen

• Unterstützung asynchroner Kommunikation mit Clients mit WebSockets

• Unterstützung asynchroner Verarbeitung serverseitig

• Gute Template-Lösung

• Kosequente Umsetzung desModel View Controller Ansatzes

Bestandteile

Projekt in Eclipse öffnen

Activator UI• Verändern von Model, View, Controller im Browser• Automatisches Kompilieren

Actions und ControllerRequests werden von einer Aktion beantwortetAktionen 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

RedirectsAuch Redirects sind Resultate

Asynchrone Controller mit Promise

Jeder Request wird asynchron und nicht-blockierend behandeltController sollten möglichst auch asynchron arbeitenAction 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 Resultdas 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 TemplatesScala Templates sind Textdateien mit kleinen Scala Code-BlöckenErzeugt werden textbasierte Formate, z.B. HTML, XML, CSV,…

Beispiel-Template:

Beginn einesdynamischen Ausdrucks

Template Parameter

Iteration

Anforderungen an die Seitengestaltung

Unterschiedliche Inhaltein gleiche Vorlagen einbauen

Vorlagen-Bausteineunabhängig anpassen

Gleiche Inhaltein unterschiedlichenVorlagen nutzen

Trennung von Inhalt und Layout ist erforderlich!

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)

Model

ViewController

User

nutzt sieht

Verändern,bearbeiten

Aktualisieren

ViewView

View

ControllerController

Controller

Vorteile MVC

• Ermöglicht Wartung und Entwicklung des Designsunabhä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.orgUmfangreiche Inhalte1200+ Inhaltsseiten80+ PDF Dokumente 100+ Produktsteckbriefe150+ Referenzbeispiele500+ Glossarbegriffe2000+ Blogeinträge

Community-Funktionen-Visitenkarte-Vernetzung der Mitglieder-Forum und Blog-Linklisten-Projektdatenbank

Verschiedene Anwender-Nutzer-Mitglieder-Partnerhochschulen-Redakteure-Landesportale

Angepasst an die verschiedenen Nutzer

e-teaching.org

Angepasst an die verschiedenen Nutzer

Community-Mitglieder Hochschul-Redakteure

e-teaching.org-Redaktion Landesportal

e-teaching.org

Angepasst an die verschiedenen Nutzer

Community-Mitglieder Hochschul-Redakteure

e-teaching.org-Redaktion Landesportal

e-teaching.org

Angepasst an die verschiedenen Nutzer

Community-Mitglieder Hochschul-Redakteure

e-teaching.org-Redaktion Landesportal

e-teaching.org

Angepasst an die verschiedenen Nutzer

Community-Mitglieder Hochschul-Redakteure

e-teaching.org-Redaktion Landesportal

e-teaching.org

Sichten auf spezielle Inhaltstypen

Produktsteckbriefe Referenzbeispiele Veranstaltungen Weiterbildung

Projektdatenbank Community-Events E-Teacher Audio-Pod

e-teaching.org

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

ModelView

Controller

Externe Module

Eigene Module Öffentliche Dateien: JavaScript, CSS, Bilder…

Hauptanwendung

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

Web-ServerXjdooi dofOidufio df

pifdp

Aktualisierung von Seitenteilen stattGanzer Seiten

Asynchrone Verarbeitungauch auf dem Server

Ausblick

Visuelle Programmierung

Entwurfmuster (Softwaredesign)