\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}