Klausur Verteilte Anwendungen

Verteilte Systeme

  • Verteilte Systeme

    • Komponenten befinden sich auf verschiedenen Geräten in einem oder mehreren Netzwerken
    • Aktionen und Daten werden durch Kommunikation unter den Systemen gesteuert
    • Menge unabhängiger Systeme die als ein System auftreten

  • Client Server Model

    • Client –> Server
    • Client –> Server / Client –> Server

  • Three Tier Architecture

    • Client Application –> Server Application (UI, Access Control, Business Logic, Data Layer) –> Database

  • Vorteile verteilter Systeme

    • Funktionale Trennung: Systeme basierend auf Funktionalität, Nutzen Fähigkeiten oder Aufgaben getrennt
    • Verteilung: Funktionen der Systeme sind von Natur aus gleichmäßig Verteilt
    • Resilienz: Fähigkeit zur Selbstheilung nach Ausfall, Belastung oder Angriff
    • Skalierbarkeit: bei wachsender Last Ressourcen hinzufügen
      • Vertical: Instanzen selbst verbessern
      • Horizontal: Mehr Instanzen nutzen
    • Fehlertoleranz: Fähigkeit trotz Ausfall einiger Systeme weiter zu funktionieren
      • Redundanz: Wenn System 1 ausfällt wird System 2 genutzt
      • Replikation: Alle Systeme werden immer gleichzeitig angesprochen, Ergebnis wird anhand von Vergleich ausgegeben

Aufbau einer verteilten Anwendung: Bild

Virtualisierung und Deployment

Arten der Virtualisierung: Bild

  • Simulation von Software und Hardware auf der eine Software ausgeführt wird

  • kann reelles System

    • verschiedene virtuelle Systeme spalten
    • wie ein anderes System aussehen lassen

  • Hypervisor

    • VMM Type 1
      • direkt auf der Hardware
      • minimales OS um VMs zu verwalten
      • Pro: Effizienter
      • Con: benötigt spezielle Treiber
    • VMM Type 2
      • VMM als Prozess auf OS
      • VMs sind ebenfalls Prozesse
      • Pro: keine speziellen Treiber nötig
      • Con: Mehr Overhead

  • Full Virtualization

    • Hypervisor emuliert Geräte
    • Hardware kann VM übergreifend geteilt werden
    • Binary translation
      • nicht privilegierte Aktionen direkt auf der CPU
      • sensible und privilegierte Aktionen werden simuliert ausgeführt
      • kritische Aktionen werden mit Exceptions behandelt
      • Problem: kritische Aktionen hängen manchmal von Parametern ab

  • Paravirtualization

    • unterstützt durch OS
    • Gast OS weiss das es in einer VM ist
      • kritische Aktionen werden nicht ausgeführt
    • Gast OS source code muss angepasst werden um Unterstützung nicht zu nutzen
    • meisten Virtualisierungsplatformen nutzen OS Assisted für Geräte

  • Accelerated Virtualization

    • Hardware gestützt
    • durch Optimierung der Hardware
      • besserer Datendurchsatz zwischen Gast und Gerät
    • Direct Assignment
      • VM besitzt die Hardware
      • Hardware kann nicht geteilt werden
      • Ziel: Effizienter Input und Output ohne VMM
      • Problem: VMM muss Korrektheit und Isolation korrekt umsetzten

  • OS Virtualisierung

    • Kernel erlaubt Existenz verschiedener isolierter Instanzen im User Space
    • Programme im Container können nur Inhalte des Containers sehen sowie zugewiesene Geräte
    • weniger Overhead als Full Virtualization, Programm nutzt normales Interface des OS

Tabelle Vergleich von Virtualisierung: Bild

Cloud Computing und Skalierung

  • Eigenschaften

    • On Demand Self Service
      • keine manuelle Aktion nötig für Zuweisung von Ressourcen
    • breiter Netzzugang
      • Zugriff über Netzwerk mit Standardmechanismen
    • Bündelung von Ressourcen
      • Gebündelte Ressourcen können mehreren Verbrauchen zugewiesen werden
    • Schnelle Elastizität
      • Funktionen nach Bedarf zuteilen und freigeben
    • Leistung wird gemessen
      • Nutzung der Ressourcen wird überwacht, kontrolliert und gemeldet

  • Service Models

    • Software as a Service
      • Anwendungen werden direkt bereitgestellt
    • Platform as a Service
      • Kunden können eigene Anwendungen bereitstellen basierend auf Angebot des Anbieters
    • Infrastructure as a Service
      • Anbieter verwaltet Ressourcen

  • Deployment Models

    • Private Cloud
      • Infrastruktur für nur eine Organisation
      • intern oder extern gehostet, Dienstleister oder Selbst
    • Public Cloud
      • Service für breites Publikum verfügbar
    • Community Cloud
      • Infrastruktur geteilt von verschiedenen Organisationen
    • Hybrid Cloud
      • Public und Private Cloud

Application Server und Frameworks

  • Application Server
    • Jede Application läuft in eigenem ClassLoader
    • Applikationen isoliert
    • teilen gleiches OS und JVM
    • teilen Libraries und Funktionen
    • Pro: Weniger Overhead, schnelles Deployment
    • Con: Keine Limits und Isolation der Hardware
  • Application Server vs Web Server Deployment
    • Web Server stellt nur statische Inhalte
    • Application Server führt Logik aus
    • Application benötigt spezifische Konfiguration

CDI, JPA und Transaktionen

  • Jakarta Persistence

    • Mit @Entity als Entity setzen
    • @Table für Tabelle in DB
    • @Column für spalten
    • @Id für PK

  • Transaction

    • CAP
      • Consistency: jeder Knoten hat neusten und erfolgreich geschriebenen Wert
      • Availability: jeder nicht ausgefallene Knoten gibt keine Fehler zurück
      • Partition-tolerance: System funktioniert auch wenn Nachrichten fallengelassen werden
    • ACID Eigenschaften
      • Atomicity: Alle Daten einer Transaction werden entweder geschrieben oder nicht geschrieben. Keine teilweisen Änderungen
      • Consistency: Alle Daten müssen gemäß der gesetzten Constraints valid sein
      • Isolation: gleichzeitige Ausführung von Transaktionen soll Datenbank so verändern wie sequentielle Ausführung würde
      • Durability: Transaktionen die committed wurden bleiben commited, auch wenn ein System ausfällt

HTTP & JSON

  • HTTP Client-Server Protokoll

    • basierend auf Request und Response
    • Schickt 6 und 7, Presentation und Application
    • Sequenz
      1. Client SYN –> Server
      2. Client <– Server SYN/ACK
      3. Client ACK
      4. Client ClientHello –> Server
      5. Client <– Server ServerHello, Certificate, ServerHelloDone
      6. Client ClientKeyExchange, ChangeCipherSpec, Finished –> Server
      7. Client <– Server ChangeCipherSpec, Finished
      8. Client HTTP Request –> Server
      9. Client <– Server HTTP Response
    • besteht aus Header und Body
      • Header
        • General Header
        • Request/Response Header
        • Entity Header
      • Body

  • HTTP Request/Response Message

    • GET /index HTTP/1.1: METHOD, PATH, VERSION
    • HTTP/1.1 200 OK: VERSION, STATUS CODE, STATUS MESSAGE

  • HTTP Request Methods

    • Get
      • spezifische Ressource anfragen
      • NUR Daten abfragen
    • Post
      • Objekt “einsenden”
      • Ändern von Inhalten, Erstellen von neuen Inhalten
    • Put
      • Alle derzeitigen Objekte mit neuem “eingesendetem” Objekt ersetzten
    • Patch
      • Teilweise Veränderung eines Objekts
    • Delete
      • Löschen einer Ressource
    • Head
      • Fragt nach IDENTISCHER Response, nur OHNE Response Body
    • Connect
      • Erzeugt Tunnel zum Server anhand von abgefragter Ressource
    • Options
      • Fragt nach Optionen für spezifische Ressource
    • Trace
      • Look-back Test entlang der Server

  • Uniform Resource Locator (URL)

  • HTTP Response Codes

    • 100 - 199
      • Informationen
      • 101 Switching Protocols
    • 200 - 299
      • Erfolgreiche Antworten
      • 200 ok
      • 204 keine Inhalte
    • 300 - 399
      • Umleitungen
      • 301 Moved Permanently
    • 400 - 499
      • Client Error Response
      • 401 Unauthorized
      • 404 Not Found
    • 500 - 599
      • Server Error Response
      • 500 Internal Server Error

REST, JAX-RS, Validation

  • Representational State Tranfer, REST

    • Architektur basierend auf HTTP
    • beschreibt uniformes Interface zur Kommunikation
    • Beschränkungen
      • Server und Client reagieren unabhängig
      • Stateless: Server kennt Stand des Clients nicht
      • Cacheable: Server sagt ob Daten gecached werden sollen
      • Uniformes Interface: Client und Server interagieren in vorhersehbaren Weg
      • Layered: Funktioniert immer gleich, unabhängig von Objekten zwischen Systemen
    • CRUD Operationen
      • Create: POST
      • Read: GET
      • Update: PUT, PATCH
      • Delete: DELETE

  • JAX-RS

    • Get: @GET
    • Head: @HEAD
    • Post: @POST
    • Put: @PUT
    • Patch: @PATCH
    • Delete: @DELETE
    • Options: @OPTIONS
    • @PathParam
    • @QueryParam
    • @HeaderParam
    • @CookieParam
    • @FormParam
    • @MatrixParam
    • @DefaultValue

  • Validation

    • mit @Valid annotation nach Input

Caching (HTTP) & Redis

  • Caching

    • Temporärer Speicher
    • Bereits erhaltene Werte speichern und schneller erneut verwenden
    • Web Content
      • Browser: Browser Cache, Resolver Cache
      • Proxy: Proxy Cache, CDN Cache, DNS Cache
      • Application: Distributed Cache, Application Data Cache
      • Database: Buffer Pool, In Memory Storage Engine

  • HTTP Caching

    • In Browser und Proxy
    • Kontrolliert durch HTTP Response Header
    • Cache Control Header
      • TTL: Time To Live
      • Typen von Cache (Control)
        • Public
        • Private
        • No-Cache, in Cache gespeichert muss aber vor jedem Benutzen validiert werden
        • No-Store

  • Distributed Cache

    • Sammelt RAM mehrerer Systeme zu einem System
    • Nutzen
      • Datenverkehr reduzieren
      • Anwendung beschleunigen
      • Web Session Data speichern
      • Ausfällen standhalten

  • Redis, Remote Dictionary Service

    • Keys
      • sollte Schema key:value folgen
      • kann genutzt werden um nach werten zu filtern
      • Key kann mit TTL versehen werden

Messaging & Kafka

Last modified 2024.07.01