diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000..1d1d469 Binary files /dev/null and b/.DS_Store differ diff --git a/parts/.DS_Store b/parts/.DS_Store new file mode 100644 index 0000000..5008ddf Binary files /dev/null and b/parts/.DS_Store differ diff --git a/parts/01_layered-arc.tex b/parts/01_layered-arc.tex new file mode 100644 index 0000000..7723f6f --- /dev/null +++ b/parts/01_layered-arc.tex @@ -0,0 +1,330 @@ +\part{Layered Architectures} +\section{Architektur-Pattern} +\subsection{Layers Pattern} +\subsubsection{Erkläre die Funktionsweise + Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/esa_layers.jpg} +\end{figure} +\begin{itemize} + \item Client schickt eine Anfrage an Layer N + \item Layer N reicht da er nicht vollständig alleine beantworten kann, Anfragen an darunterliegenden Layer weiter + \item Eine Anfrage kann bei Bedarf auch in mehrere Anfragen an darunterliegende Layer geteilt werden + \item dies wird immer weiter fortgesetzt bis Layer 1 erreicht ist + \item dabei gehen Abhängigkeiten nur von oben nach unten +\end{itemize} +3 Schichten Architektur: +\begin{itemize} + \item Presentation Layer: serverseitig, kümmert sich um Benutzerinteraktion + \item Domain Layer: enthält Business Logik (Berechnungen, Datenvalidierung, ...) + \item Data Source Layer: Zugriff auf Daten, kümmert sich um Kommunikation mit anderen Systemen (z.B.: Datenbank) +\end{itemize} +\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} +\begin{itemize} + \item Java Enterprise Edition (JEE) Architektur bestehend aus + \begin{itemize} + \item Client Tier (Client Machine) + \item Web Tier, Business Tier (Java EE Server) + \item EIS Tier (Database Server) + \end{itemize} +\end{itemize} +\subsubsection{Nenne die Konsequenzen der Anwendung} +\begin{itemize} + \item hilft dabei eine Applikation die in Unteraufgaben zerlegt werden können, zu strukturieren + \item jede Teilaufgabengruppe befindet sich in einem eigenen Layer + \item ermöglicht bzw. vereinfacht Austauschbarkeit +\end{itemize} + +\subsection{Data Access Object (DAO) Pattern} +\subsubsection{Erkläre die Funktion + Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/dao_pat1.jpg} + \includegraphics[width=0.3\textwidth]{pics/dao_pat2.jpg} +\end{figure} +\begin{itemize} + \item Client erstellt ein DAO Object und kann nach Entitäten suchen, einfügen, löschen, etc. + \item das DAO selbst soll keine spezifischen Elemente enthalten (Entity Manager, SQL Exception -> stattdessen DAOException) + \item dadurch entsteht eine Kapselung bei der die DAOImpl ohne den Client zu verändern ausgetauscht werden kann +\end{itemize} +\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} +\begin{itemize} + \item EntityManager in JEE +\end{itemize} +\subsubsection{Nenne die Konsequenzen der Anwendung} +\begin{itemize} + \item Zugriff auf persistenten Speicher wird abstrahiert + \item Details des Speichers werden versteckt + \item ermöglicht einheitlichen Zugriff auf Daten + \item entkoppelt Implementierung von Persistierung (Datenbank,...) + \item ermöglicht Objektorientierte Ansicht des Speichers +\end{itemize} +\subsection{Service Layer Pattern (auch Session Fassade)} +\subsubsection{Erkläre die Funktion + Skizze} + +\begin{itemize} + \item Service Layer delegiert auf Business Logik und zum DAO + \item bei wenig Logik wird zumindest Transaktions, Error und Validierungshandling im Service erledigt +\end{itemize} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.45\textwidth]{pics/sl_pat1.jpg} + \includegraphics[width=0.45\textwidth]{pics/sl_pat2.jpg} +\end{figure} +\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} +\begin{itemize} + \item eine Applikation mit unterschiedlichen Clienttypen +\end{itemize} +\subsubsection{Nenne die Konsequenzen der Anwendung} +\begin{itemize} + \item Reduzierung der Abhängigkeiten zwischen Presentation und Domain Layer + \item Zentralisiertes Sicherheits und Transaktionshandling + \item verbirgt vor Client Komplexität der Business Logik + \item stellt Client ein grobkörniges Interface zur Verfügung + \item gut für Remote Aufrufe geeignet (weniger Aufrufe) +\end{itemize} +\subsection{Model-View-Controller Pattern} +\subsubsection{Erkläre die Funktion + Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/mvc_pat.jpg} +\end{figure} +\begin{itemize} + \item MVC unterteilt eine interaktive Applikation in drei Teile: + \begin{itemize} + \item Model: Kenfunktionalität und Daten (z.B.: Datenbankzugriff) + \item View: Visualisierung bzw. User-Interaktion + \item Controller: enthält Logik und behandelt Benutzereingaben + \end{itemize} + \item Controller und View befinden sich im Presentation Layer und haben gegenseitig Abhängigkeiten + \item Model darf keine Abhängigkeiten haben (Controller und View hängen vom Model ab) +\end{itemize} +\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} +\begin{itemize} + \item Look\&Feel fokusierte Anwendung -> so kann View ohne Große Probleme ausgetauscht werden +\end{itemize} +\subsubsection{Nenne die Konsequenzen der Anwendung} +\begin{itemize} + \item Visualisierung abhängig vom Model - nicht umgekehrt + \item verschiedene Darstellungen möglich + \item einfaches Testen der Domain-Logik + \item gute Strukturierung + \item View wird leichter austausch bzw. änderbar +\end{itemize} +\subsection{Front Controller} +\subsubsection{Erkläre die Funktion + Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/fc_pat.jpg} +\end{figure} +\begin{itemize} + \item Client schickt Request an Front Controller + \item FC erfasst nur Infos die er für die weiter Delegation braucht + \item FC gibt Request an entsprechenden ConcreteCommand oder View weiter + \item es gibt zwei Implementierungsvarianten des Controller + \begin{multicols}{2} + \begin{itemize} + \item Servlet + \item ConcreteCommand + \end{itemize} + \end{multicols} +\end{itemize} +\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} +\begin{itemize} + \item Java Server Faces (bei Java Server Faces enthält das File zwar keinen Java Code, interagiert aber direkt mit Java Code einer Backing Bean) +\end{itemize} +\subsubsection{Nenne die Konsequenzen der Anwendung} +\begin{itemize} + \item es muss nur EIN (Front) Controller konfiguriert werden + \item da bei jedem Request ein neues Command Objekt erzeugt wird ist Thread-Safety nicht notwendig + \item da nur EIN Controller sind auch Erweiterungen durch z.B.: Decorator einfach (auch zur Laufzeit) +\end{itemize} +\subsection{View Helper} +\subsubsection{Erkläre die Funktion + Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.4\textwidth]{pics/view-helper_pat1.jpg} + \includegraphics[width=0.4\textwidth]{pics/view-helper_pat2.jpg} +\end{figure} +\begin{itemize} + \item View delegiert Aufgaben an Helper (Helper adaptieren View zu Model) + \item in View befindet sich HTML Code im ViewHelper Java Code zur Aufbereitung der Daten (+ wenig HTML) +\end{itemize} +\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} +\begin{itemize} + \item bei Verwendung von JSP (Java Server Pages enthalten neben HTML auch Java Code) +\end{itemize} +\subsubsection{Nenne die Konsequenzen der Anwendung} +\begin{itemize} + \item kapselt Design-Code in View und View-Processing-Code Logik in Helper + \item steigert Wiederverwendbarkeit, Wartbarkeit und Strukturierungsqualität der Anwendung + \item vereinfacht Tests (Helperfunktionen ohne View) + \item bessere Trennung zwischen + \begin{itemize} + \item Presentation und Data Source Layer + \item Entwickler und Designer + \end{itemize} +\end{itemize} + + +\subsection{Dependency Injection (don't call us, we'll call you)} +\subsubsection{Erkläre die Funktion + Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/dependency_inj_pat.jpg} + \includegraphics[width=0.4\textwidth]{pics/dependency_inj_spring_pat.jpg} +\end{figure} +\begin{itemize} + \item Grundidee sind loose gekoppelte Objekte + \item Objekte werden mittels externem Assembler verknüpft + \item Abhängigkeiten bestehen nur auf Interfaces + \item Assembler Objekt erzeugt die Interface-Implementierungen (z.B.: durch Factory) +\end{itemize} +\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} +\begin{itemize} + \item Im Spring Context: Dependency Injection mit XML-Datei + \item alle Beans sind dort gelistet und werden verknüpft + \item Context wird geladen damit alles verknüpft ist + \item erspart Factories + \item man unterscheidet Constructor und Setter Injection +\end{itemize} +\subsubsection{Nenne die Konsequenzen der Anwendung} +\begin{itemize} + \item loose gekoppelte Objekte + \item Referenzen nurmehr auf Interfaces + \item hohe Flexibilität (Strategy, Proxy,..) + \item bessere Erweiterbarkeit und Testbarkeit + \item bei Spring kann Dependency Injection mittels XML oder Annotation erfolgen + \begin{itemize} + \item Vorteil Annotation: Typ-Sicherheit (Tippfehler passieren schnell im XML) + \item Nachteil Annotation: nicht so flexibel wie XML + \end{itemize} +\end{itemize} +\subsection{Remote Facade} +\subsubsection{Erkläre die Funktion + Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/rem_fass_pat.jpg} +\end{figure} +\begin{itemize} + \item bietet dem Client ein grobes Interface + \item ist Schicht die von grob zu fein-granularem Interface umwandelt + \item steigert so Netzwerkeffizienz +\end{itemize} +\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} +\begin{itemize} + \item Implementierung in Applikation um überlastetes Netzwerk zu entlasten. +\end{itemize} +\subsubsection{Nenne die Konsequenzen der Anwendung} +\begin{multicols}{2} + \begin{itemize} + \item weniger Remote Calls + \item Entlastung des Netzwerkes + \item steigert Zuverlässigkeit + \end{itemize} +\end{multicols} +\subsection{Data Transfer Object (DTO) Pattern} +\subsubsection{Erkläre die Funktion (Skizze - ein Grund für DTO)} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.9\textwidth]{pics/lok-vs-remote.jpg} +\end{figure} +\begin{itemize} + \item Transportiert Daten zwischen Prozessen um Remote Methodenaufrufe zu minimieren + \item besteht aus Fields, Getter und Setter + \item fasst Daten verschiedener Objekte zusammen die vom Remote Objekt benötigt werden + \item ev. Map, Record Set, ... +\end{itemize} +\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} +% todo: Anwendungsbeispiel +\subsubsection{Nenne die Konsequenzen der Anwendung} +\begin{itemize} + \item kapselt und versteckt + \item nimmt Komplexität + \item steigert Effizienz da weniger Aufrufe über Remotegrenze +\end{itemize} +\section{Remote} +\subsection{Beschreibe die Unterschiede zwischen lokalem und Remote Interface Design} +\begin{itemize} + \item Aufrufe innerhalb des Prozesses sind schneller als über Prozessgrenzen + \item lokale Interfaces sind möglichst fein-granular während Remote Interfaces grob-granular sein müssen (weniger Aufrufe - Effizienz) + \item viele kleine Aufrufe mit wenigen Daten sind "teuer" (Latenz durch Verbindungsherstellung) +\end{itemize} +\subsection{Beschreibe drei Situationen wo Multiple Prozesse in Applikationen verwendet werden müssen} +\begin{itemize} + \item Trennung zwischen Clients und Servern in Business Software + \item Trennung zwischen server-basierter Applikationssoftware und Datenbank (SQL ist als Remote Interface designed, daher sind hier schnelle Abfragen möglich) + \item Trennung wegen unterschiedlichen Anbietern oder Programmiersprachen +\end{itemize} + +\subsection{Beschreibe das folgende Diagramm. Was können wir daraus für das Design von Remote Interfaces folgern?} +\begin{itemize} + \item speziell bei "teuren" Remote Calls ist es empfehlenswert weniger Calls mit großen Datenmengen anstatt vielen Calls mit wenigen Daten zu machen + \item dieser Gedanke befürwortet auch den Einsatz von DTO um Calls und Daten zu bündeln +\end{itemize} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.9\textwidth]{pics/lok-vs-remote.jpg} +\end{figure} +\section{Exception Handling} +\subsection{Beschreibe den Unterschied zwischen Checked und Runtime Exceptions in Java (inkl. Klassendiagramm)} +\begin{itemize} + \item Checked Exceptions (z.B. SQL-Exception) leiten von Exception Klasse ab und müssen behandelt werden (trows - catch) + \begin{itemize} + \item Verwendung für Probleme die durch User behoben werden können (alternative Aktion) + \end{itemize} + \item Unchecked Exceptions (z.B. NullPointerException) leiten von RuntimeException ab + \begin{itemize} + \item Verwendung für technische Probleme (User kann nichts machen außer neu starten) + \end{itemize} +\end{itemize} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.3\textwidth]{pics/except_class_dia.jpg} +\end{figure} +\subsection{Beschreibe einen Use Case für eine Checked Exceptions in Java} +\begin{itemize} + \item eine Netzwerkübertragung schlägt fehl - es ist vorgesehen, dass der Applikations-User dies neu anstoßen kann +\end{itemize} +\subsection{Beschreibe einen Use Case für eine Runtime Exceptions in Java} +\begin{itemize} + \item Die Datenbank ist beschädigt - die Exception geht durch alle Layer erst mit + Implementierungsspezifischer Exception später mit Runtime ohne Stacktrace (Sicherheit) bis zum User. +\end{itemize} +\subsection{Beschreibe 5 Best Practice Beispiele beim Einsatz von Exceptions} +\begin{itemize} + \item Exceptions nicht für Programmflusskontrolle verwenden (schlechte Performance) + \item offene Ressourcen schließen (try-with-resources bzw. close im finally) + \item selbst erstellte Exceptions auch mit nützlichen Infos ausstatten + \item Implementierungsspezifische Exceptions nicht bis zum User durchwerfen (stattdessen catch + trow RuntimeException) + \item dokumentieren mit @trows im DOC, testen mit JUnit +\end{itemize} + +\subsection{Beschreibe 5 Exception Handling Anti Pattern} +\begin{itemize} + \item Log and Trow (nie beides: entweder, oder) + \item Trowing Exception bzw. catch Exception (spezifischere anstatt Basisklasse verwenden) + \item Destructive Wrapping (wenn bei catch + trow = wrapping nicht die Original Exception weitergegeben wird) + \item Log and return Null (provoziert an einer anderen Stelle eine NullPointerException) + \item Catch and Ignore + \item Unsupported Operation return Null (besser UnsupportedOperationException) +\end{itemize} +\section{Logging} +\subsection{Nenne die Nachteile von debugging mit printf() sowie die Vorteile die Logging Frameworks wie log4j bieten} +\subsubsection{Nachteile printf()} +\begin{itemize} + \item Produktiv-Code wird überfüllt -> erschwert Lesbarkeit + \item Consolenausgabe wird bei vielen prints auch schnell unübersichtlich + \item im Falle eines vorzeitigen Absturzes können Ausgabedaten verloren gehen + \item Performance bei vielen Logprints +\end{itemize} +\subsubsection{Vorteile Logging mittels Framework (z.B.: log4j)} +\begin{itemize} + \item Nutzt ein einheitliches Format / Konventionen + \item logging kann optional an und ausgeschalten werden + \item durch verschiedene Log-level können Logs gefiltert erstellt werden + \item Layout für Ausgabe kann zentral definiert/geändert werden +\end{itemize} +\section{Durchlesen: JEE Web Tier} +\section{Durchlesen: JavaServer Faces} +\section{Durchlesen: Wildfly Overview} \ No newline at end of file diff --git a/parts/02_comp-based_arc.tex b/parts/02_comp-based_arc.tex new file mode 100644 index 0000000..4386c4d --- /dev/null +++ b/parts/02_comp-based_arc.tex @@ -0,0 +1,245 @@ +\part{Component Based Architectures} +\section{Erkläre den Begriff Software Komponente wie von Clemens Szypersky definiert} +\begin{itemize} + \item ist eine Einheit aus spezifizierten Interfaces mit expliziten Context-Abhängigkeiten + \item kann solange Abhängigkeiten erfüllt, unabhängig deployed werden + \item wird von Dritten zusammen mit anderen Components verwendet +\end{itemize} +\section{Infrastruktur Pattern} +\subsection{Component Pattern} +\subsubsection{Beschreibe die Problemstellung} +\begin{itemize} + \item großer Broken Funktionalität vom technischen Teil getrennt ist besser als Vermischung + \item Änderungen an kleinem Teil können Auswirkungen auf das ganze System haben + \item unabhängige Deployments bzw. Updates der Teile ist unmöglich -> soll aber möglich werden +\end{itemize} +\subsubsection{Erkläre die Lösung inkl. Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/component_pat.jpg} +\end{figure} +\begin{itemize} + \item Funktionalität der Anwendung wird in mehrere Teilkomponenten zerlegt + \item jede Komponente soll ihre Verantwortlichkeiten ohne starke Abhängigkeiten \textbf{vollständig} implementieren + \item durch Zusammenfügen der Funktionalitäten loser Komponenten wird die Anwendung realisiert +\end{itemize} +\subsubsection{Beschreibe die Konsequenzen der Anwendung} +\begin{itemize} + \item eine Komponente sollte sich gut an andere anpassen, jedoch nur lose an diese gekoppelt sein + \item Comp-Interface ist von Comp-Impl getrennt + \item Funktionalitätsänderung, erfordert nur Änderung innerhalb entsprechenden Komponente +\end{itemize} +\subsection{Container Pattern} +\subsubsection{Beschreibe die Problemstellung} +\begin{itemize} + \item Components enthalten reine Business Logik (keine technischen Aspekte) + \item es wird etwas zur Behandlung der technischen Aspekte und Integration benötigt... + \item Lösung soll wiederverwendet werden können +\end{itemize} +\subsubsection{Erkläre die Lösung inkl. Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/container_pat.jpg} +\end{figure} +\begin{itemize} + \item Container ist Ausführungsumgebung für technische Aspekte der Components + \item umhüllt Components und erweckt Anschein einer fixen Integration + \item um Wiederverwendung zu fördern werden Frameworks verwendet (z.B.: Code Generation) +\end{itemize} + +\subsubsection{Beschreibe die Konsequenzen der Anwendung} +\begin{itemize} + \item zur Integration spezifizieren Annotations technische Anforderungen der Components (getrennt von Implementierung) + \item Glue-Code-Layer (generischer Containerteil) wird zur Anpassung /Füllung erstellt + \item für unterschiedliche Component Typen gibt es verschiedene Container +\end{itemize} +\subsection{Service Component Pattern} +\subsubsection{Beschreibe die Problemstellung} +\begin{itemize} + \item es werden "Service Provider" benötigt, dies sind Komponenten die andere Komponenten der externe Systeme verändern + \item dienen als Fassade für Subsystem, welches aus weiteren Komponenten besteht +\end{itemize} +\subsubsection{Erkläre die Lösung inkl. Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/service_compontent_pat.jpg} +\end{figure} +\begin{itemize} + \item Service Component: Kapselt Prozesse und Workflow + \item Prozesse sind stateless + \item so kann Container Components effizient verwalten + \item jede Operation muss abgeschlossen sein +\end{itemize} +\subsubsection{Beschreibe die Konsequenzen der Anwendung} +\begin{itemize} + \item dient als Fassade für komplexe Systeme + \item vereinfacht Zugriff auf diese Systeme + \item jede Operation einer Service Component ist eigene Transaktionseinheit + \item da stateless - gute Performance +\end{itemize} + + +\subsection{Session Component Pattern} +\subsubsection{Beschreibe die Problemstellung} +\begin{itemize} + \item Service Component reicht nicht aus + \item es soll auch ein Client oder Session-Status gespeichert werden + \item Status ist nicht persistent und wird durch Garbage-Collection wieder entfernt +\end{itemize} + +\subsubsection{Erkläre die Lösung inkl. Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/session_component_pat.jpg} +\end{figure} +\begin{itemize} + \item SessionComponents merken Client-spezifischen Zustand (nicht persistent) + \item Overhead gering da es keine Nebenläufigkeit gibt + \item Ressourcenverbrauch wird auch vom Container niedrig gehalten +\end{itemize} +\subsubsection{Beschreibe die Konsequenzen der Anwendung} +\begin{itemize} + \item nur ein Client pro Komponente erlaubt + \item Server kann Speicher ausgehen (\#Session-Components = \#Clients) + \item um Speicherproblem gegenzuwirken wird Passivation verwendet +\end{itemize} + +\section{Implementierungs Pattern} +\subsection{Virtual Instance Pattern} +\subsubsection{Beschreibe die Problemstellung} +\begin{itemize} + \item viele Komponenten-Instanzen können zu Ressourcenknappheit (Speicher, Container, Systemressourcen) führen +\end{itemize} +\subsubsection{Erkläre die Lösung inkl. Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/virtual_instance_pat.jpg} +\end{figure} +\begin{itemize} + \item es wird nur eine virtuelle Komponenten-Referenz geführt + \item erst bei Bedarf (Clientaufruf) wird auf eine reale Instanz verwiesen + \item nach Nutzung wird reale Instanz wieder in Instanzenpool zurückgegeben + \item Arten virtueller Instanzen: + \begin{itemize} + \item Instance Pooling (wie beschrieben) + \item Passivation (reale Instanzen werden zwischenzeitlich auf Festplatte geschrieben und aus Speicher gelöscht, bei Bedarf wieder geladen) + \end{itemize} +\end{itemize} +\subsubsection{Beschreibe die Konsequenzen der Anwendung} +\begin{itemize} + \item Anzahl realer Instanzen im Speicher meist wesentlich geringer als virtueller + \item somit ist Aufwand und Speicherbedarf des Containers geringer +\end{itemize} +\subsection{Instance Pooling Pattern} +\subsubsection{Beschreibe die Problemstellung} +\begin{itemize} + \item Komponenteninstanzen erstellen und entfernen ist "teuer" (Overhead) +\end{itemize} +\subsubsection{Erkläre die Lösung inkl. Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/instance_pooling_pat.jpg} +\end{figure} +\begin{itemize} + \item im Container wird ein Pool von Komponenteninstanzen erstellt + \item wird virtuelle aufgerufen, wird Poolinstanz zugeteilt + \item nach Nutzung kommt diese wieder in den Pool + \item Zustandsänderungen werden durch Lifecycle Callbacks kontrolliert +\end{itemize} +\subsubsection{Beschreibe die Konsequenzen der Anwendung} +\begin{itemize} + \item bei Container Instance Pooling, zwei Status: + \begin{itemize} + \item pooled state: Instanz hat keine logische Identität + \item active state: Instanz repräsentiert logische Identität, sowie funktionalen Zustand dieser + \end{itemize} + \item Komponenteninstanzen für Pooling befinden sich immer im Speicher + \item Anzahl echter Instanzen schwankt mit Nutzung + \item Component-Proxy wird verwendet um Lifecycle Operation auszulösen, bevor Poolinstanz verwendet wird +\end{itemize} + + +\subsection{Passivation Pattern} +\subsubsection{Beschreibe die Problemstellung} +\begin{itemize} + \item Session Components haben Status ohne Repräsentation im Speicher + \item es gibt Zeiträume der Inaktivität + \item es sollen Ressourcen gespart werden + \item z.B. Einkaufswagen eines Online Shops +\end{itemize} +\subsubsection{Erkläre die Lösung inkl. Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/passivation_pat.jpg} +\end{figure} +\begin{itemize} + \item Komponenteninstanzen können durch Container temporär aus Speicher entfernt werden + \item Zustand wird persistent gespeichert und aus Hauptspeicher gelöscht + \item wird Instanz benötigt wird diese von Festplatte in Hauptspeicher geladen +\end{itemize} +\subsubsection{Beschreibe die Konsequenzen der Anwendung} +\begin{itemize} + \item Instanzen werden wirklich aus Speicher entfernt + \item bei neuerlicher Herstellung müssen auch Verbindungen zu anderen Ressourcen neu geladen werden + \item es müssen Lifecycle Callbacks implementiert werden (teilweise vom Container automatisch) + \item bedeutet deutlichen Overhead und sollte vermieden werden (besser mehr Speicher) +\end{itemize} + +\subsection{Component Proxy Pattern} +\subsubsection{Beschreibe die Problemstellung} +\begin{itemize} + \item Clients müssen auf virtuelle Komponenteninstanzen referenzieren + \item Container muss bei Client Aufruf für virtuelle, physikalische Instanz bereitstellen + \item zuvor wird durch Lifecycle Callbacks auf freie geprüft +\end{itemize} + + +\subsubsection{Erkläre die Lösung inkl. Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/component_proxy_pat.jpg} +\end{figure} +\begin{itemize} + \item es wird ein Proxy für physikalische Komponenteninstanzen bereitgestellt + \item Clients haben nie eine direkte Referenz sondern agieren nur mit Proxy + \item Proxy handelt Instance Pooling und Passivation + \item zur Performancesteigerung bedient ein Proxy mehrere virtuelle Komponenteninstanzen +\end{itemize} + +\subsubsection{Beschreibe die Konsequenzen der Anwendung} +\begin{itemize} + \item dem Client wird durch den Proxy etwas gegeben, das ohne echte Komponenteninstanz aufgerufen werden kann + \item Client Methodenaufrufe enthalten ID der logischen Komponenteninstanz zur korrekten Weiterleitung + \item Proxy implementiert keine Logik - leitet nur weiter + \item Proxy kann generiert werden, meist als Teil des Glue-Code-Layers +\end{itemize} + + +\subsection{Glue-Code Pattern} +\subsubsection{Beschreibe die Problemstellung} +\begin{itemize} + \item Container soll wiederverwendet werden, dazu muss Funktionalität generisch sein + \item Komponenten besitzen spezielle Schnittstelle und Annotationen welche spezielle Config für technische Anforderungen enthalten + \item völlig generische Container können keine unterschiedlichen Komponenten beherbergen +\end{itemize} +\subsubsection{Erkläre die Lösung inkl. Skizze} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/glue_code_pat.jpg} +\end{figure} +\begin{itemize} + \item Schicht aus generiertem Code als Adapter zwischen generischem Teil des Containers und Komponentenimplementierung + \item pro spezifischer Komponente wird eigene Glue-Code-Schicht erzeugt + \item Compontent-Proxy ist Teil dieser Schicht +\end{itemize} + +\subsubsection{Beschreibe die Konsequenzen der Anwendung} +\begin{itemize} + \item in Java mit Reflection umsetzbar (ermöglicht dynamischen Operationsaufruf) + \item Reflection viel langsamer als spezifischer generierter Code + \item Komponenten-Deployment: + \begin{itemize} + \item Zeitpunkt der Integrationsmaßnahmen des Containers + \item Zeitpunkt der Glue-Code-Layer Generierung + \end{itemize} +\end{itemize} diff --git a/parts/03_service-orientated_arc.tex b/parts/03_service-orientated_arc.tex new file mode 100644 index 0000000..819bdf3 --- /dev/null +++ b/parts/03_service-orientated_arc.tex @@ -0,0 +1,593 @@ +\part{Service-Oriented Architecture (SOA)} +\section{SOA} +\subsection{Auf welche drei technischen Konzepte basiert SOA?} +\begin{itemize} + \item Services: unabhängige Business-Funktionalität + \item Enterprise service bus (ESB): Infrastruktur, zwischen verteilten Service-Systemen + \begin{itemize} + \item erledigt Datenkonvertierung und Verteilung + \item wird meist durch große, kommerzielle Sofwarepakete realisiert + \end{itemize} + \item Lose Kopplung: reduziert Systemabhängikeiten. + \begin{itemize} + \item einzelne Services sollen auch dann arbeiten, wenn andere nicht verfügbar oder langsam sind + \end{itemize} +\end{itemize} +\subsection{Beschreibe die Eigenschaften von großen Verteilten Systemen} +\begin{itemize} + \item Heterogen -> unterschiedliche + \begin{itemize} + \item Plattformen + \item Programmiersprachen + \end{itemize} + \item Komplex + \item Nicht perfekt (wäre zu teuer) + \item Redundant (alle Redundanz zu eliminieren verlangsamt das System) +\end{itemize} +\subsection{Beschreibe den Begriff Business View im Kontext von SOA} +\begin{itemize} + \item Geschäftsprozessmodellierung wird verwendet um alle Aspekte eines GP grafisch zu beschreiben + \item Standards zur Modellierung, damit Experten daraus GP entwerfen können: + \begin{itemize} + \item Business Process Execution Language (BPEL) im XML Format + \item Unified Modeling Language (UML) + \end{itemize} + \item Process View entspricht Top-Down-Ansatz der Systemmodellierung (Prozess auf kleinere herunter brechen) +\end{itemize} +\subsection{Beschreibe den Begriff Service View auf ein Software-System im Kontext von SOA} +\begin{itemize} + \item entspricht Bottom-Up-Ansatz der Systemmodellierung (Services in größere Einheiten zusammenfassen bis GP vollständig) + \item Schnittstellen-Definition ist Kern der Service-orientierten Architektur + \item Schnittstellen-Beschreibung: + \begin{itemize} + \item syntaktisch durch Signatur (Input, Output, Exception) + \item semantisch + \end{itemize} + \item Vertrag: ist vollständige Spezifizierung eines Services zwischen Consumer und Provider +\end{itemize} +\subsection{Beschreibe drei unterschiedliche Service Kategorien} +\subsubsection{Basic Services} +\begin{itemize} + \item grundlegende, an vielen Stellen gebrauchte Business-Funktionalität + \item meist kurze Laufzeit + \item stateless +\end{itemize} +\subsubsection{Composed Services} +\begin{itemize} + \item aus Basic Services zusammengesetzt („Orchestration“) + \item auf höherer Ebene als Basic Services angesiedelt + \item stateless + \item kurze Laufzeit + \item oft Adapter Services um anderen Services eine Schnittstelle zu bieten +\end{itemize} +\subsubsection{Process Services} +\begin{itemize} + \item Längerfristige Prozesse, die Geschäftsprozesse umsetzen + \item Interagieren mit Benutzer oder anderen Systemen + \item BPEL ermöglicht \textbf{laufenden} Process Services nicht, Benutzerinteraktion auszulösen (beeinflusst Design) + \item statefull (z.B. wie weit ist Benutzer im Prozess) +\end{itemize} + +\subsection{Erkläre die beiden Ansätze für SOA System-Design inkl. Skizze} +\begin{itemize} + \item Kommunikation zwischen Komponenten funktioniert über Schnittstellen + \item Schnittstellen sind public und published, deshalb schwer änderbar + \item wird eine neue Version veröffentlicht werden Vorversionen meist noch angeboten +\end{itemize} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/topDown-bottomUp.jpg} +\end{figure} +\subsubsection{Top Down} + +\begin{itemize} + \item Prozess auf kleiner Prozesse herunterbrechen, bis Ebene von Basic Services erreicht ist +\end{itemize} +\subsubsection{Bottom Up} +\begin{itemize} + \item Services in größere Einheiten zusammenfassen, bis Geschäftsprozess vollständig abgebildet +\end{itemize} +\subsection{Beschreibe das Konzept des Enterprise Service Bus inkl. Skizze} + +\begin{itemize} + \item ist Kommunikationsmedium zwischen einzelnen Services + \item Hauptaufgaben sind: + \begin{itemize} + \item Datentransformation (Umwandlung von Datenpaketen und Feldern dieser) + \item Routing + \begin{itemize} + \item Services finden + \item Daten zwischen Services vermitteln + \item Loadbalancing zwischen Serviceanbietern + \end{itemize} + \item Protokolle und Middleware kann Heterogen sein + \item ESB: REST, CORBA, SOAP + \item REST verwendet http für Transport + \end{itemize} +\end{itemize} + +\begin{figure}[!htp] + \centering + \includegraphics[width=0.3\textwidth]{pics/esb_1.jpg} + \includegraphics[width=0.3\textwidth]{pics/esb_2.jpg} + \includegraphics[width=0.3\textwidth]{pics/esb_3.jpg} +\end{figure} +\subsection{Beschreibe den Unterschied zwischen P2P Verbindungen und dem Konzept ESB als Mediator} + +\begin{itemize} + \item Unterschied: Kopplung der Consumer an physikalische Verbindung (P2P enger) +\end{itemize} +\subsubsection{Point-to-Point} +\begin{itemize} + \item Consumer muss Endpunkt kennen da Empfänger bestimmt sein muss + \item ist Verbindung nicht möglich, schlägt Aufruf fehl +\end{itemize} +\subsubsection{ESB als Mediator} +\begin{itemize} + \item Ziel-Service wird vom Consumer mittels Tag angegeben + \item ESB kümmert sich um die Zustellung -> Vorteil: dynamische Änderungen möglich +\end{itemize} +\subsection{Beschreibe das Konzept der loosen Kopplung und die beiden wichtigsten damit verbundenen Themen} +\subsubsection{Konzept} +\begin{itemize} + \item bezeichnet einen geringen Grad der Abhängigkeit zwischen Hard- oder Software-Komponenten + \item ermöglicht + \begin{multicols}{3} + \begin{itemize} + \item Skalierbarkeit + \item Flexibilität + \item Fehlertoleranz + \end{itemize} + \end{multicols} +\end{itemize} +\subsubsection{damit verbundene Konzepte} +\begin{itemize} + \item Asynchrone Kommunikation + \begin{itemize} + \item Sender und Empfänger sind nicht synchronisiert + \item nach dem Versand kann sofort andere Arbeit ausgeführt werden + \item trifft Antwort ein wird diese ursprünglichem Request zugeordnet + \end{itemize} + \item Heterogene Datentypen + \begin{itemize} + \item da Daten in großen Systemen unterschiedlich sind, werden Mappings benötigt + \item Mappings gehen auf technische und semantische Aspekte ein + \end{itemize} +\end{itemize} +\section{Microservice Architekturen} + +\subsection{Beschreibe die wesentlichsten Unterschiede zwischen einer monolithischen Anwendung und dem Mikroservices Ansatz} +\subsubsection{Monolithisch} +\begin{itemize} + \item Enterprise Applications bestehen oft aus drei Teilen + \begin{itemize} + \item Client-seitigem User Interface + \item Server-seitiger monolithischer Applikation + \item Datenbank + \end{itemize} + \item da die Applikation \textbf{eine} Einheit ist, muss sie bei Änderungen neu gebuilded und deployed werden +\end{itemize} +\subsubsection{Microservices} +\begin{itemize} + \item sind gut skalierbar + \item Applikation besteht aus vielen kleinen Services + \item jedes Service läuft in eigenem Prozess und deckt einzelne Funktionalität vollständig ab + \item für die Interservicekommunikation werden leichtgewichtige Kommunikationswege verwendet (z.B.: HTTP - kein ESB mehr nötig) + \item Services können unabhängig voneinander deployed werden +\end{itemize} + +\subsection{Vergleiche die Unterschiedlichen Skalierungstrategien von monolitischen Applikationen und Mikroservices} +\subsubsection{Monolithisch} +\begin{itemize} + \item gesamte Applikation muss skaliert werden + \item erfolgt durch mehrerer Instanzen (horizontale Skalierung) bzw. Load Balancing + \item Nachteil: alles und nicht nur benötigtes wird dupliziert -> Ressourcenbelastung +\end{itemize} +\subsubsection{Microservices} +\begin{itemize} + \item Service-Grenzen sind funktional orientiert + \item es können speziell benötigte Services öfter instanziert werden + \item Nachteil: Interprozesskommunikation nimmt aufgrund der Verteilung auf viele kleine Servicekomponenten zu +\end{itemize} + +\subsection{Erkläre den Unterschied zwischen Libraries und Services} +\subsubsection{Library} +\begin{itemize} + \item Komponenten, die in eine Applikation verlinkt werden und lokal (im selben Prozess) verwendet werden +\end{itemize} +\subsubsection{Services} +\begin{itemize} + \item besitzen immer eine Remote Schnittstelle + \item befinden sich in eigenem Prozess (stärker entkoppelt) + \item Aufruf über Web Services oder Remote Procedure Calls + \item Konsequenzen: + \begin{itemize} + \item getrennt auslieferbar + \item Explizite Schnittstelle + \item Services sind published -> schwer änderbar + \end{itemize} +\end{itemize} + +\subsection{Beschreibe die Beziehung zwischen einer Team Struktur und dem Design einer Software} +\subsubsection{Silo-Ansatz} +\begin{itemize} + \item Zuständigkeiten bei großen Applikationen werden oft an technologische Grenzen angepasst + \item so entstehen Teams für UI, Server-Side oder Datenbank Teams + \item kleine Änderungen führen so bereits zu hohen Kosten da Team übergreifend gearbeitet werden muss +\end{itemize} +\subsubsection{Cross-Functional Ansatz} +\begin{itemize} + \item bei Microservices wird ähnlich wie bei Scrum ein cross-functional Ansatz verfolgt + \item ein Team ist somit für das gesamte Service, welches nur eine gesamte Funktionalität abdeckt, verantwortlich +\end{itemize} + +\subsection{Erkläre das Konzept "smart endpoints and dump pipes"} +\begin{itemize} + \item wird anstatt eines ESB, welcher oft smarte Mechanismen für Routing und Transforming anbietet, verwendet + \item Smart Endpoints sind z.B. RabbitMQ oder REST + \item diese verwenden einfache Protokolle wie z.B. HTTP zur Übertragung + \item Microservices agieren wie Filter bei Unix und wenden ihre Logik auf Anfragen an bevor die Antwort erzeugt wird +\end{itemize} + +\subsection{Was sind die Herausforderungen von dezentralisiertem Datenmanagement?} +\begin{itemize} + \item Monolitische Applikationen bevorzugen eine Datenbank für alle Daten des Systems + \item dies Ansatz wird oft auch von Unternehmen bevorzugt + \item Microservices verwenden hingegen den "Polyglot Persistence" Ansatz -> für einzelne Services jeweils eine eigene Datenbank + \item Konsequenz: transaktionslose Koordination zwischen Services + \item Herausforderung: Aufsplittung der Datenbank beim Wechsel von Monolith zu Microservice Ansatz +\end{itemize} + +\subsection{Beschreibe die wichtigsten Design-Überlegungen im Zusammenhang mit Mircroservices ("Design for Failure", "Evulutionary Design")} +\subsubsection{Design for failure} +\begin{itemize} + \item bei Microservices nimmt Fehlerpotential durch Interprozesskommunikation massiv zu + \item jeder Aufruf kann bei Nichtverfügbarkeit des Services fehlschlagen + \item Software muss daher Fehlertolerant konzipiert sein + \item es gibt diverse Monitoring-Tools um Fehler und Probleme zur Laufzeit zu erkennen +\end{itemize} +\subsubsection{Evolutionary Design} +\begin{itemize} + \item das Setzen der Grenzen der Micro-Service Komponenten nach einer Aufteilung ist herausfordernd + \item Änderungen sollen nach Aufteilung nur das entsprechende Modul betreffen + \item Module sollen unabhängig voneinander geändert werden können + \item Evolutionary Design + \begin{itemize} + \item Beginne mit Monolith und trenne erst auf Microservices wenn dieser zum Problem wird + \item kommt hauptsächlich im Kontext mit Extreme-Programming zum Einsatz + \item Weiterentwicklung des Designs erfolgt durch \textbf{Refactoring} + \item ist das Gegenteil von geplantem Design, da Designelemente erst wenn notwendig eingebaut werden + \item Design for the future wird vermieden + \end{itemize} +\end{itemize} +\section{Von Objekten zum Service} +\subsection{Beschreibe die Nachteile von klassischen verteilten Objektarchitekturen} +\begin{itemize} + \item Die Kommunikation von verteilten Objekte erfolgt oft über \textbf{nicht standardisierte} TCP-Ports verschiedenster Middleware-Libraries (z.B. CORBA, DCOM, RMI) - oft durch die meisten Firewalls standardm. blockiert, + \item größere Serverauslastung durch viele Anfragen vom Client, da Objektstatus darüber ausgetauscht wird, + \item Load-Balancing schwieriger zu implementieren und zu verwalten, + \item Reservierter Speicher durch den Client muss vom Server automatisch wieder freigegeben werden (z.B. bei Ausfall des Clients) +\end{itemize} +\subsection{Erkläre die unterschiedlichen Formen der Kopplung} +Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen Modul (z.B. Client vom Server). Dabei gibt es verschiedene Formen:: +\begin{itemize} + \item Functional Coupling: + \begin{itemize} + \item Clients hängen von der in Web-Services implementierten Logik ab - bei Fehlern oder Inkonsistenzen sind sie betroffen, + \end{itemize} + \item Data Structure Coupling: + \begin{itemize} + \item Clients müssen die Datenstrukturen eines Services verstehen (in Bezug auf z.B. Datentypen oder Character-Encodings der ausgetauschten Nachrichten) + \end{itemize} + \item Temporal Coupling: + \begin{itemize} + \item hoch, wenn Request sofort nach dem Empfang verarbeitet werden muss (Request/Response pattern), + \item kann gesenkt werden, wenn die Zeit, wann request verarbeitet werden muss, ausgedehnt oder verschoben wird (Request/Acknowledge pattern) + \end{itemize} + \item URL coupling + \begin{itemize} + \item Clients sind oft stark an Service-URLs gebunden, da oft statisch oder nach einem einfachen Schema definiert. + \end{itemize} + \item Durch Vermeidung der Kopplung auf Computing-Plattformen können die Nachteile von Software-Wiederverwendung verringert werden. +\end{itemize} +\section{Web Service API Styles} +\subsubsection{Beschreibe aktuelle Designüberlegungen für Web Service APIs} +\begin{itemize} + \item Kapselung: + \begin{itemize} + \item Services sollten Implementierungsdetails verstecken, + \item Client sollte über Domain-Model, Datenbanktabllen oder Stored-Procedure-Designs nicht Bescheid wissen, + \item Service-APIs sollten "top-down" desgined werden (API wird an Anforderungen seitens Client-Applikationen angepasst) + \end{itemize} + \item Service-Contract: + \begin{itemize} + \item Spezifiziert die Art der Interaktionen zwischen Services und Clients, + \item z.B. welche Bedingung vor Aufruf wahr sein muss (\textbf{pre-condition}), + \item oder die Ereignisse nach Ausführung des Services (\textbf{post-condition}), + \item die meisten Contracts können nur die Basisinformationen eines Services abbilden (z.B. bei WSDL Web-Service-Description-Language die syntaktische Spezifikation). + \end{itemize} + \item Autonomie/Unabhängigkeit: + \begin{itemize} + \item Services sollten eigene Ausführung kontrollieren und nur wenige Abhängigkeiten nach außen aufweisen, + \item Web-Services sollten verteilte Transaktionen \textbf{verhindern} + \item Web-Services können Kompensierung durch die Bereitstellung von gegenteiligen Service-Paaren (logische Funktion genau invers), + \item Daten in verteilten Systemen können nicht vollständig synchron sein + \end{itemize} + \item Latenz: + \begin{itemize} + \item Zeit eines Clients für die Beantwortung von Anfragen an Web-Services signifikant höher als ähnlicher Aufruf innerhalb desselben Prozesses, + \item Web-Services sollten daher APIs erstellen, welche die Anzahl der netzwerkbelastenden Aktionen gering hält + \end{itemize} + \item Partial failures: + \begin{itemize} + \item Clients müssen auf die Fehlfunktion von Services vorbereitet werden, + \item Situationen, in denen der Netzwerkverkehr abbricht oder ausgelastet ist, müssen stets berücksichtigt werden + \end{itemize} + \item Message Encoding: + \begin{itemize} + \item Web-Services verwenden textbasierte Nachrichten, + \item manchmal sind sie jedoch in Binärform umgewandelt zur Verminderung von payload und damit Senkung der benöt. Netzwerkbandbreite + \end{itemize} +\end{itemize} +\subsubsection{RPC API} +\subsubsection{Erkläre die Funktionalität inkl. Skizze} +\begin{itemize} + \item Client sendet Nachricht zu Remote-Server und blockiert, während er auf die Response wartet, + \item Die Nachricht in der Anfrage identifiziert den auszuführenden Prozess und beinhaltet Parameter, welche direkt den Parametern der Remote-Prozedur entsprechen, + \item Sobald der Service ausgeführt wurde, wird die Anfrage des Clients bearbeitet und eine Antwort wird zurückgeschickt, + \item Client kann anschließend die Ergebnisse extrahieren und die Ausführung fortsetzen. + \item Mittels WSDL kann die Bearbeitbarkeit durch den Entwickler durch automatische Codegenerierung vereinfacht werden - Defin. mittels XSD oder WSDL +\end{itemize} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/rpc_api.jpg} +\end{figure} +\begin{itemize} + \item Message-API +\end{itemize} +\subsubsection{Beschreibe die Konsequenzen der Nutzung} +\begin{itemize} + \item Die Wahrscheinlichkeit, dass Entwickler Signaturen erstellen wie bei normalen Klassenmethoden (z.B. mit langen Parameterlisten) ist hoch - dadurch Einschränkungen in Flexibilität und Erhöhung der Instabilität + \item Proxys werden meist mittels clientseitiger Codegeneratoren (z.B. basierend auf WSDL) generiert - der Proxy muss somit bei jeder Änderung der WSDL-Beschreibung mitgeändert werden, + \item Durch die Client-Proxys wird es schwierig, festzustellen, wann Remote-Prozeduren aufgerufen werden sollen - daher meiden Entwickler oft die notwendige Implementierung von Exception-Handling im Netzwerkbereich (Verbindungsverlust, Servercrash und belegte Dienste) +\end{itemize} +\subsubsection{Message API} +\subsubsection{Erkläre die Funktionalität inkl. Skizze} +\begin{itemize} + \item Dienste, die Message-APIs verwenden, empfangen ein oder mehrere selbstbeschreibende Nachrichtentypen mithilfe einer gegebenen URL + \item Aufruf einer Message-API oft durch Standardformate wie SOAP oder XML + \item Client sendet Nachricht an eine bestimmte URL und ist blockiert, während er auf die Antwort wartet + \item Wenn Nachricht bei Server ankommt, wird sie deseralisiert und inspiziert und an den zuständigen Handler weitergeleitet, + \item Sobald der Handler aufgerufen wurde, ist er in der Lage, den Request des Clients verarbeiten und eine Response zurücksenden, + \item Nachrichten werden meist über XML Schema-Definitionen definiert, + \item Die API stellt meist einen empfangenden Endpunkt zur Verfügung, während der Web-Service als Versender agiert, + \item Clients versenden meist einen der drei Message-Typen: + \begin{itemize} + \item Command-Message, + \item Event-Message, + \item Document-Message + \end{itemize} + \item Message-APIs stellen Ergebnisse oft auch über Messages zur Verfügung. +\end{itemize} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/message_api.jpg} +\end{figure} +\subsubsection{Beschreibe die Konsequenzen der Nutzung} +\begin{itemize} + \item Message-APIs setzen zur Unterstützung clientseitiger Code-Generierung oft Service-Descriptors, wie z.B. WSDL ein, + \item Logik zur Verarbeitung von speziellen Nachrichtentypen wird durch Command-Invoker in Gang gebracht, + \item Vereinfachung durch Trennung der Verarbeitungslogik vom empfangenden Web-Service +\end{itemize} +\subsubsection{Resource API} +\subsubsection{Erkläre die Funktionalität inkl. Skizze} +\begin{itemize} + \item Verwendung durch Services mittels Anfrage-URL und HTTP-Methoden des Clients begleitet durch \textbf{media type}, um Anfrage des Clients zu erkennen + \item Anfragen oft nach dem Prinzip von \textbf{Respresentational State Transfer (REST)} + \item Beispiele für eine \textbf{ressource}: + \begin{itemize} + \item Textdatei, + \item Mediendatei, + \item einzelne Spalte in Datenbanktabelle, + \item Collection mit Daten etc. + \end{itemize} + \item Clients manipulieren desn Status der Ressource durch \textbf{representations} + \item Verwendete HTTP-Methoden durch Resource-API: + \begin{itemize} + \item PUT - Ressourcenupdate, + \item GET - Abruf der Repräsentation einer Ressource, + \item DELETE - Löschen einer Ressource, + \item POST - Erstellen oder Updaten einer Ressource, + \item HEAD - ähnlich wie GET, nur ohne Abruf der Repräsentation - verwendet, um Metadaten der media-types zu erhalten, + \item OPTIONS - liefert die HTTP-Methoden der Ziel-URL zurück + \end{itemize} + \item Vorteile: + \begin{itemize} + \item Spezifikation durch HTTP definiert - Client muss keine neue API einsetzen! + \item Status-Codes von HTTP für Rückmeldung an Client können hier auch verwendet werden, + \item Regeln für \textbf{idempotent} und \textbf{safe} von HTTP gelten + \end{itemize} + \item \textbf{media types} einer Resource-API-Anfrage müssen klar definiert werden. + \item Definiert werden \textbf{media types} durch: + \begin{itemize} + \item Character-Encodings, + \item Regeln für das Parsen der Daten, + \item Standards für die Koppelung mit anderen Ressourcen, + \end{itemize} + \item Clients müssen über die media types des Services und die Verwendung dieser Bescheid wissen. +\end{itemize} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/ressource_api.jpg} +\end{figure} +\subsubsection{Beschreibe die Konsequenzen der Nutzung} +\begin{itemize} + \item Resource-APIs sind eine gute Wahl bei großer Anzahl von zugreifenden Clients, + \item Resource-APIs machen die Weitergabe der Verwendungsart der Services durch den URL-Standard sehr einfach. Nachteil: Auch durch potenzielle Angreifer einfach zu verstehen und auszunützen - Security-Probleme + \item Code-Generierung durch Entwickler kann meist nicht verwendet werden, da Service-Descriptors durch Resource-APIs nicht angeboten werden, + \item Resource-APIs bieten die Möglichkeit, die Präferenzen des Clients über die mitgegebenen \textbf{media types} abzufragen und dieselbe Ressource im richtigen Format zurückzuliefern. +\end{itemize} +\section{Web Service Infrastruktur} +\subsection{Service Connector Pattern} +\subsubsection{Erkläre die Funktionalität inkl. Skizze} +\begin{itemize} + \item Service-Connectors vereinfachen die Verwendung von Services durch Verdecken der API-Komplexität, + \item viele generische Funktionen werden gekapselt und mit zusätzlicher Logik, die der Service benötigt, erweitert: + \begin{itemize} + \item Service Location und Connection-Management wird implementiert: + \begin{itemize} + \item Ermitteln der Service-Adressen, + \item Aufbau der Verbindung zum Service, + \item Aufzeichnung aller verbindungsspezifischen Fehler. + \end{itemize} + \item Nach der Verbindung des Clients mit dem Connector leitet er die Anfrage im Auftrag des Clients weiter + \item Connectors empfangen auch die Responses des Services und stellen Hilfsfunktionen zur Unterstützung von Client-Applikationen (z.B. Datentypübersetzung oder Aufzeichnung aller HTTP status-codes) bereit, + \item Ein Connector kapselt die gesamte Verbindungslogik des Clients zur spezifischen Kommunikation mit dem Service + \end{itemize} +\end{itemize} +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/serv_connector_api.JPG} +\end{figure} +\subsubsection{Beschreibe die Konsequenzen der Nutzung} +\begin{itemize} + \item Nutzung eines Connectors als Test-Double in automatisierten Tests, ohne den Web-Service ansprechen zu müssen, + \item generische Logik zur Verwendung durch den Client wird eingesetzt, wie z.B.: + \begin{itemize} + \item Logging, + \item Validierung, + \item Exception Handling, + \item Eingabe von Benutzeranmeldedaten (siehe Service-Inceptor-Pattern) + \end{itemize} + \item Ein Connector hängt von den Services, für die er erstellt wurde, ab. Bei Generierung der Services durch einen Descriptor (z.B. WSDL) muss der Entwickler informiert werden - Änderung des Descriptors und Neugenerierung dringend erforderlich + \item Clients können Exception-Handling in Bezug auf Netzwerkfehler (verlorene Verbindungen, Server-Crashes, belegte Services) oft schwer implementieren, da Informationen über den Ablauf im Hintergrund (Kommunikation mit Service) durch den Connector versteckt werden. +\end{itemize} + +\subsection{Service Descriptor Pattern} +\subsubsection{Erkläre die Funktionalität inkl. Skizze} + +\begin{itemize} + \item bietet eine \emph{Maschinen lesbare} Auflistung an logischen Operationen oder Ressourcen die eine Organisation bietet + \item die Metadaten von jeder logischen Operationen oder Ressource identifizieren ein Webservice und geben die Typen (Nachrichten oder Medien) an die es empfangen und zurückgeben kann. + \item Service Metadaten werden mit \textbf{XML} beschrieben -> bei Webservice nennt man das \textbf{WSDL} (Web Service Description Language) oder \textbf{WADL} bei Web Applikationen +\end{itemize} + +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/service_descriptor_contFirst.jpg} + \includegraphics[width=0.5\textwidth]{pics/service_descriptor_codeFirst.jpg} +\end{figure} +\subsubsection{Beschreibe die Konsequenzen der Nutzung} + +\begin{itemize} + \item kann als Vertrag zwischen Server und Client angesehen werden wie eine Interaktion auszusehen hat. + \item üblicherweise in WSDL beschrieben (siehe oben) + \item Service Designer sollte Client-Service Interaktionen berücksichtigen (Netzwerkeffizienz) + \item Client benötigt viele Netzwerkanfragen um eine Anfrage abzuschließen. + \item Systeme aus weniger, größeren Komponenten als feinkörnige Systeme sollten bevorzugt werden. + \item Eine grobkörnige Beschreibung eines Systems betrifft große Unterkomponenten, während eine feinkörnige Beschreibung kleinere Komponenten betrifft, aus denen die größeren zusammengesetzt sind. + \item \textbf{Dieser Ansatz ist bekannt als das Remote Facade Pattern.} + \item Service Connectors die vom Service Descriptor generiert werden sind eng verbunden mit ihnen und müssen neu generiert werden wenn es Änderungen gibt + \item Verwendung von Service Descriptor mindert nicht die Notwendigkeit eine gute Dokumentation zu verfassen. Diese ist für Client Entwickler wichtig um Dienste korrekt zu verwenden. +\end{itemize} + +\paragraph{Contract-First vs. Code-First} +\begin{itemize} + \item Contract-First + \begin{itemize} + \item Service Descriptors werden dazu verwendet die Server-seitigen Artefakte zu generieren. Definiert in XML und XSD + \item Compiler kann DTO und Service Interface Klassen auf Basis des "Vertrages" generieren (in der jeweilig benötigten Programmiersprache) + \end{itemize} + \item Code-First + \begin{itemize} + \item Service Deskriptoren werden automatisch von + Web-Service-Frameworks zur Laufzeit erstellt. Klassen, die als Service-Controller bezeichnet werden, werden in Java erstellt und annotiert. Diese Annotationen werden vom Service-Framework verwendet, welche Controller-Methoden aufgerufen werden sollen. + \end{itemize} +\end{itemize} + + +\subsection{Consumer-Driven Contracts Pattern} +\subsubsection{Erkläre die Funktionalität inkl. Skizze} + +Egal wie viel Zeit und Mühe in ein Design investiert wird, ein Dienst muss möglicherweise noch geändert werden. Veröffentlichte APIs die erweitert werden oder andere unerwartete Änderungen. + +Service Anbieter können davon profitieren, wenn sie wissen, welche (und wie) Clients ihren Service verwenden. + +Das hilft Serviceentwickler beim vornehmen an Änderungen der API, um deren Auswirkungen zu verstehen. + +\begin{itemize} + \item Serviceentwickler bekommen Integrations-Tests von jedem Client. + \item Der Entwickler kann dann sehen welche Auswirkung seine Änderungen auf die verschiedenen Clients haben. + \item Fehlgeschlagene Tests erleichtern die Fehlersuche. + +\end{itemize} + + + +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/customer_driven_contracts.jpg} +\end{figure} +\subsubsection{Beschreibe die Konsequenzen der Nutzung} + +\begin{itemize} + \item Consumer-Driven Contracts werden geschrieben um Integrationstests ausführen zu können. + \item Sollten versioniert werden, um Änderungen besser nachverfolgen zu können. (zusätzliche Aufteilung je nach Client) + \item Contract tests sollten nach jeder Änderung am API oder der internen Logik überprüft werden. + \item Dieses Pattern wird verwendet, wenn Entwickler ihre Clients kennen und die Clients auch Contracts zurückschicken können. +\end{itemize} + +\begin{itemize} + \item Test Strategie + \begin{itemize} + \item sollte happy-path und falsche Verwendung vom API testen. + \end{itemize} + \item Asynchrone Services und jene mit langer Laufzeit + \begin{itemize} + \item Request/Acknowledge ist schwer zu testen + \end{itemize} + \item Dem Client die Spezifikation des API zu ermöglichen kann die Integrität dieser API in frage stellen. +\end{itemize} + + + + +\subsection{API Gateway Pattern} + + + +\subsubsection{Erkläre die Funktionalität inkl. Skizze} + +APIs die von Microservices zur Verfügung gestellt unterscheiden sich oft von den Anforderungen der Clients (Different clients need different data (desktop browser vs. mobile client)) + +Bei sehr detailieren APIs muss ein Client häufig mit mehreren Services interagieren. Auch die Netzwerkgeschwindigkeit ist bei jedem Client unterschiedlich. + + +Um das zu umgehen wird ein API-Gateway eingefügt der einen zentralen Eintrittspunkt für Clients darstellt. + + +Es gibt 2 Möglichkeiten wie ein Gateway Anfragen abarbeiten kann: + +\begin{itemize} + \item einfaches routen zum entsprechendem Service + \item Anfragen an mehrere Services schicken +\end{itemize} + + +Anstatt eine einheitliche API für alle bereitzustellen, wird ein +Gateway verwendet. Dieser kann für jeden Client eine andere API verfügbar machen. + +\begin{figure}[!htp] + \centering + \includegraphics[width=0.5\textwidth]{pics/api_gateway.jpg} +\end{figure} +\subsubsection{Beschreibe die Konsequenzen der Nutzung} + +\begin{itemize} + \item Das Gateway isoliert den Client von den Microservices + \item das optimale API je nach Client-Typ kann bereitgestellt werden + \item reduziert die Anzahl an Anfragen + \item vereinfacht den Client -> die Logik um verschiedene Services aufzurufen wird auf das Gateway verlagert. + \item das Gateway ist eine weitere Komponente die Entwickelt und verwaltet werden muss... + \item längere Antwortzeiten -> zusätzlicher Schritt (jedoch sind die Kosten für den extra Aufruf nicht sehr hoch) +\end{itemize} \ No newline at end of file diff --git a/pics/api_gateway.jpg b/pics/api_gateway.jpg new file mode 100644 index 0000000..9febcd8 Binary files /dev/null and b/pics/api_gateway.jpg differ diff --git a/pics/bottom_up_1.jpg b/pics/bottom_up_1.jpg new file mode 100644 index 0000000..2aa19ef Binary files /dev/null and b/pics/bottom_up_1.jpg differ diff --git a/pics/component_pat.jpg b/pics/component_pat.jpg new file mode 100644 index 0000000..a32cab7 Binary files /dev/null and b/pics/component_pat.jpg differ diff --git a/pics/component_proxy_pat.jpg b/pics/component_proxy_pat.jpg new file mode 100644 index 0000000..92753b1 Binary files /dev/null and b/pics/component_proxy_pat.jpg differ diff --git a/pics/container_pat.jpg b/pics/container_pat.jpg new file mode 100644 index 0000000..609947b Binary files /dev/null and b/pics/container_pat.jpg differ diff --git a/pics/customer_driven_contracts.jpg b/pics/customer_driven_contracts.jpg new file mode 100644 index 0000000..2510a78 Binary files /dev/null and b/pics/customer_driven_contracts.jpg differ diff --git a/pics/dao_pat1.jpg b/pics/dao_pat1.jpg new file mode 100644 index 0000000..61bc983 Binary files /dev/null and b/pics/dao_pat1.jpg differ diff --git a/pics/dao_pat2.jpg b/pics/dao_pat2.jpg new file mode 100644 index 0000000..927fc44 Binary files /dev/null and b/pics/dao_pat2.jpg differ diff --git a/pics/dependency_inj_pat.jpg b/pics/dependency_inj_pat.jpg new file mode 100644 index 0000000..16c30f3 Binary files /dev/null and b/pics/dependency_inj_pat.jpg differ diff --git a/pics/dependency_inj_spring_pat.jpg b/pics/dependency_inj_spring_pat.jpg new file mode 100644 index 0000000..04a3f66 Binary files /dev/null and b/pics/dependency_inj_spring_pat.jpg differ diff --git a/pics/esa_layers.jpg b/pics/esa_layers.jpg new file mode 100644 index 0000000..8b7b257 Binary files /dev/null and b/pics/esa_layers.jpg differ diff --git a/pics/esb_1.jpg b/pics/esb_1.jpg new file mode 100644 index 0000000..669ed73 Binary files /dev/null and b/pics/esb_1.jpg differ diff --git a/pics/esb_2.jpg b/pics/esb_2.jpg new file mode 100644 index 0000000..a56057c Binary files /dev/null and b/pics/esb_2.jpg differ diff --git a/pics/esb_3.jpg b/pics/esb_3.jpg new file mode 100644 index 0000000..019a774 Binary files /dev/null and b/pics/esb_3.jpg differ diff --git a/pics/esb_mediator.jpg b/pics/esb_mediator.jpg new file mode 100644 index 0000000..1cde6da Binary files /dev/null and b/pics/esb_mediator.jpg differ diff --git a/pics/except_class_dia.jpg b/pics/except_class_dia.jpg new file mode 100644 index 0000000..5146369 Binary files /dev/null and b/pics/except_class_dia.jpg differ diff --git a/pics/fc_pat.jpg b/pics/fc_pat.jpg new file mode 100644 index 0000000..2dbe657 Binary files /dev/null and b/pics/fc_pat.jpg differ diff --git a/pics/glue_code_pat.jpg b/pics/glue_code_pat.jpg new file mode 100644 index 0000000..4ab05cd Binary files /dev/null and b/pics/glue_code_pat.jpg differ diff --git a/pics/instance_pooling_pat.jpg b/pics/instance_pooling_pat.jpg new file mode 100644 index 0000000..fd0ab56 Binary files /dev/null and b/pics/instance_pooling_pat.jpg differ diff --git a/pics/lok-vs-remote.jpg b/pics/lok-vs-remote.jpg new file mode 100644 index 0000000..fa04dba Binary files /dev/null and b/pics/lok-vs-remote.jpg differ diff --git a/pics/message_api.jpg b/pics/message_api.jpg new file mode 100644 index 0000000..b58c489 Binary files /dev/null and b/pics/message_api.jpg differ diff --git a/pics/mvc_pat.jpg b/pics/mvc_pat.jpg new file mode 100644 index 0000000..08627a3 Binary files /dev/null and b/pics/mvc_pat.jpg differ diff --git a/pics/passivation_pat.jpg b/pics/passivation_pat.jpg new file mode 100644 index 0000000..218f774 Binary files /dev/null and b/pics/passivation_pat.jpg differ diff --git a/pics/rem_fass_pat.jpg b/pics/rem_fass_pat.jpg new file mode 100644 index 0000000..596e613 Binary files /dev/null and b/pics/rem_fass_pat.jpg differ diff --git a/pics/ressource_api.jpg b/pics/ressource_api.jpg new file mode 100644 index 0000000..84f6007 Binary files /dev/null and b/pics/ressource_api.jpg differ diff --git a/pics/rpc_api.jpg b/pics/rpc_api.jpg new file mode 100644 index 0000000..33a6ef9 Binary files /dev/null and b/pics/rpc_api.jpg differ diff --git a/pics/serv_connector_api.JPG b/pics/serv_connector_api.JPG new file mode 100644 index 0000000..6ad90a4 Binary files /dev/null and b/pics/serv_connector_api.JPG differ diff --git a/pics/service_compontent_pat.jpg b/pics/service_compontent_pat.jpg new file mode 100644 index 0000000..00bf5a8 Binary files /dev/null and b/pics/service_compontent_pat.jpg differ diff --git a/pics/service_descriptor_codeFirst.jpg b/pics/service_descriptor_codeFirst.jpg new file mode 100644 index 0000000..6cde453 Binary files /dev/null and b/pics/service_descriptor_codeFirst.jpg differ diff --git a/pics/service_descriptor_contFirst.jpg b/pics/service_descriptor_contFirst.jpg new file mode 100644 index 0000000..ab98f31 Binary files /dev/null and b/pics/service_descriptor_contFirst.jpg differ diff --git a/pics/service_view.jpg b/pics/service_view.jpg new file mode 100644 index 0000000..1b7d42b Binary files /dev/null and b/pics/service_view.jpg differ diff --git a/pics/session_component_pat.jpg b/pics/session_component_pat.jpg new file mode 100644 index 0000000..aff7d68 Binary files /dev/null and b/pics/session_component_pat.jpg differ diff --git a/pics/sl_pat1.jpg b/pics/sl_pat1.jpg new file mode 100644 index 0000000..edb88cb Binary files /dev/null and b/pics/sl_pat1.jpg differ diff --git a/pics/sl_pat2.jpg b/pics/sl_pat2.jpg new file mode 100644 index 0000000..5db1653 Binary files /dev/null and b/pics/sl_pat2.jpg differ diff --git a/pics/slp_pat1.jpg b/pics/slp_pat1.jpg new file mode 100644 index 0000000..edb88cb Binary files /dev/null and b/pics/slp_pat1.jpg differ diff --git a/pics/slp_pat2.jpg b/pics/slp_pat2.jpg new file mode 100644 index 0000000..5db1653 Binary files /dev/null and b/pics/slp_pat2.jpg differ diff --git a/pics/topDown-bottomUp.jpg b/pics/topDown-bottomUp.jpg new file mode 100644 index 0000000..64f807c Binary files /dev/null and b/pics/topDown-bottomUp.jpg differ diff --git a/pics/top_down.jpg b/pics/top_down.jpg new file mode 100644 index 0000000..4b454f3 Binary files /dev/null and b/pics/top_down.jpg differ diff --git a/pics/view-helper_pat1.jpg b/pics/view-helper_pat1.jpg new file mode 100644 index 0000000..6de6f13 Binary files /dev/null and b/pics/view-helper_pat1.jpg differ diff --git a/pics/view-helper_pat2.jpg b/pics/view-helper_pat2.jpg new file mode 100644 index 0000000..3d4f413 Binary files /dev/null and b/pics/view-helper_pat2.jpg differ diff --git a/pics/virtual_instance_pat.jpg b/pics/virtual_instance_pat.jpg new file mode 100644 index 0000000..1beed50 Binary files /dev/null and b/pics/virtual_instance_pat.jpg differ diff --git a/sw-arc.tex b/sw-arc.tex new file mode 100644 index 0000000..ce1b7bb --- /dev/null +++ b/sw-arc.tex @@ -0,0 +1,27 @@ +% Preamble +\documentclass[11pt]{article} + +% Packages +\usepackage{a4wide} +\usepackage[T1]{fontenc} +\usepackage[utf8]{inputenc} +\usepackage[hidelinks]{hyperref} +\usepackage{multicol} +\usepackage{graphicx} +%\usepackage{minted} +\usepackage[outputdir=../../auxil]{minted} + +% Document +\begin{document} + \author{Phillip Wo \\ Benjamin Moser \\ Daniel Sommer} + \title{Enterprise Software Architecture - FAQ Ausarbeitung} + \maketitle + \pagebreak + % \tableofcontents + % \pagebreak + + \include{parts/01_layered-arc} + \include{parts/02_comp-based_arc} + \include{parts/03_service-orientated_arc} + +\end{document} diff --git a/~$tchriftBenjiToni.docx b/~$tchriftBenjiToni.docx deleted file mode 100644 index e3c229c..0000000 Binary files a/~$tchriftBenjiToni.docx and /dev/null differ