593 lines
31 KiB
TeX
593 lines
31 KiB
TeX
\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} |