added git repo
This commit is contained in:
parent
f204a3047b
commit
0fe85d2274
Binary file not shown.
|
|
@ -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}
|
||||
|
|
@ -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}
|
||||
|
|
@ -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}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 77 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 53 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 82 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 215 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 119 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 63 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 96 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 71 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 47 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 235 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
|
|
@ -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}
|
||||
Binary file not shown.
Loading…
Reference in New Issue