FH-Joanneum_public
/
PSE_learning
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

review till page 5

This commit is contained in:
Daniel Sommer 2019-03-02 10:38:23 +01:00
parent db7261af56
commit 1603346644
3 changed files with 164 additions and 174 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

148
parts/01_layered-arc.tex
View File

@ -1,11 +1,6 @@
\part{Layered Architectures} \part{Pattern im Projekt}
\section{Architektur-Pattern} \section{Layers Pattern}
\subsection{Layers Pattern} \subsection{Erkläre die Funktionsweise + Skizze}
\subsubsection{Erkläre die Funktionsweise + Skizze}
\begin{figure}[!htp]
\centering
\includegraphics[width=0.5\textwidth]{pics/esa_layers.jpg}
\end{figure}
\begin{itemize} \begin{itemize}
\item Client schickt eine Anfrage an Layer N \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 Layer N reicht da er nicht vollständig alleine beantworten kann, Anfragen an darunterliegenden Layer weiter
@ -13,9 +8,13 @@
\item dies wird immer weiter fortgesetzt bis Layer 1 erreicht ist \item dies wird immer weiter fortgesetzt bis Layer 1 erreicht ist
\item dabei gehen Abhängigkeiten nur von oben nach unten \item dabei gehen Abhängigkeiten nur von oben nach unten
\end{itemize} \end{itemize}
3 Schichten Architektur: \begin{figure}[!htp]
\centering
\includegraphics[width=0.5\textwidth]{pics/esa_layers.jpg}
\end{figure}
\subsubsection{3 Schichten Architektur:}
\begin{itemize} \begin{itemize}
\item Data Source Layer(data): Zugriff auf Daten, kümmert sich um Kommunikation mit anderen Systemen (z.B.: Datenbank) \item Data Source Layer (data): Zugriff auf Daten, kümmert sich um Kommunikation mit anderen Systemen (z.B.: Datenbank)
\begin{itemize} \begin{itemize}
\item beinhaltet DAO und DAOImpl >> DocumentDAO, DocumentlibraryDAO \item beinhaltet DAO und DAOImpl >> DocumentDAO, DocumentlibraryDAO
\end{itemize} \end{itemize}
@ -23,6 +22,7 @@
\begin{itemize} \begin{itemize}
\item beinhaltet \item beinhaltet
\begin{itemize} \begin{itemize}
\item \textbf{Service Layer Pattern} (aka Session Fassade - siehe~\ref{sec:slp})
\item DTO >> DocumentDTO \item DTO >> DocumentDTO
\item Mapper >> DocumentMapper \item Mapper >> DocumentMapper
\begin{minted}[breaklines=true]{java} \begin{minted}[breaklines=true]{java}
@ -34,6 +34,7 @@ public static DocumentDTO toDTO(Document document){};
\item Presentation Layer(web): serverseitig, kümmert sich um Benutzerinteraktion \item Presentation Layer(web): serverseitig, kümmert sich um Benutzerinteraktion
\begin{itemize} \begin{itemize}
\item Controller (ViewHelper) >> DocumentController, DocumentListController \item Controller (ViewHelper) >> DocumentController, DocumentListController
\item View (WebApp)
\end{itemize} \end{itemize}
\end{itemize} \end{itemize}
\begin{figure}[!htp] \begin{figure}[!htp]
@ -41,7 +42,7 @@ public static DocumentDTO toDTO(Document document){};
\includegraphics[width=0.4\textwidth]{pics/tree-projectmain.png} \includegraphics[width=0.4\textwidth]{pics/tree-projectmain.png}
\includegraphics[width=0.4\textwidth]{pics/web-2ndpart.jpg} \includegraphics[width=0.4\textwidth]{pics/web-2ndpart.jpg}
\end{figure} \end{figure}
\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} \subsection{Beschreibe ein konkretes Anwendungsbeispiel}
\begin{itemize} \begin{itemize}
\item Java Enterprise Edition (JEE) Architektur bestehend aus \item Java Enterprise Edition (JEE) Architektur bestehend aus
\begin{itemize} \begin{itemize}
@ -50,43 +51,43 @@ public static DocumentDTO toDTO(Document document){};
\item EIS Tier (Database Server) \item EIS Tier (Database Server)
\end{itemize} \end{itemize}
\end{itemize} \end{itemize}
\subsection{Data Access Object (DAO) Pattern} \section{Data Access Object (DAO) Pattern}
\subsubsection{Erkläre die Funktion + Skizze} Befindet sich im Projekt in data und damit innerhalb des Data Layer.
\begin{figure}[!htp] \subsection{Erkläre die Funktion + Skizze}
\centering
\includegraphics[width=0.5\textwidth]{pics/dao_pat1.jpg}
\includegraphics[width=0.3\textwidth]{pics/dao_pat2.jpg}
\end{figure}
\begin{itemize} \begin{itemize}
\item Client erstellt ein DAO Object und kann nach Entitäten suchen, einfügen, löschen, etc. \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 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 \item dadurch entsteht eine Kapselung bei der die DAOImpl ohne den Client zu verändern ausgetauscht werden kann
\end{itemize} \end{itemize}
\begin{figure}[!h]
\centering
\includegraphics[width=0.8\textwidth]{pics/dao_pat1.jpg}
\end{figure}
\begin{minted}[breaklines=true]{java} \begin{minted}[breaklines=true]{java}
@ApplicationScoped @ApplicationScoped
public class DocumentDAOImpl implements DocumentDAO, Serializable { public class DocumentDAOImpl implements DocumentDAO, Serializable {
private static final long serialVersionUID = 1L; private static final long serialVersionUID = 1L;
private static final Logger logger = LoggerFactory.getLogger(DocumentDAOImpl.class); private static final Logger logger = LoggerFactory.getLogger(DocumentDAOImpl.class);
@PersistenceContext @PersistenceContext
private EntityManager entityMangaer; private EntityManager entityMangaer;
@Override @Override
public List<Document> findByCommunity(Community community) {} public List<Document> findByCommunity(Community community) {...}
@Override @Override
public List<Document> findByUser(User user) {} public List<Document> findByUser(User user) {...}
@Override @Override
public void insert(Document document) {} public void insert(Document document) {...}
@Override @Override
public void delete(Document document) {} public void delete(Document document) {...}
@Override @Override
public Document findById(Long id) {} public Document findById(Long id) {...}
} }
\end{minted} \end{minted}
\subsubsection{Nenne die Konsequenzen der Anwendung} \subsection{Nenne die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item Zugriff auf persistenten Speicher wird abstrahiert \item Zugriff auf persistenten Speicher wird abstrahiert
\item Details des Speichers werden versteckt \item Details des Speichers werden versteckt
@ -94,8 +95,8 @@ public static DocumentDTO toDTO(Document document){};
\item entkoppelt Implementierung von Persistierung (Datenbank,...) \item entkoppelt Implementierung von Persistierung (Datenbank,...)
\item ermöglicht Objektorientierte Ansicht des Speichers \item ermöglicht Objektorientierte Ansicht des Speichers
\end{itemize} \end{itemize}
\subsection{Service Layer Pattern (auch Session Fassade)} \section{Service Layer Pattern (auch Session Fassade)}\label{sec:slp}
\subsubsection{Erkläre die Funktion + Skizze}\label{subsubsec:service-layer-pattern} \subsection{Erkläre die Funktion + Skizze}\label{subsubsec:service-layer-pattern}
\begin{itemize} \begin{itemize}
\item Service Layer delegiert auf Business Logik (z.B.: Zeile 82 community.setDocumentlibrary) und zum DAO (z.B.: Zeile 80, 81,82 ...) \item Service Layer delegiert auf Business Logik (z.B.: Zeile 82 community.setDocumentlibrary) und zum DAO (z.B.: Zeile 80, 81,82 ...)
@ -285,7 +286,7 @@ public static DocumentDTO toDTO(Document document){};
\includegraphics[width=0.45\textwidth]{pics/sl_pat1.jpg} \includegraphics[width=0.45\textwidth]{pics/sl_pat1.jpg}
\includegraphics[width=0.45\textwidth]{pics/sl_pat2.jpg} \includegraphics[width=0.45\textwidth]{pics/sl_pat2.jpg}
\end{figure} \end{figure}
\subsubsection{Nenne die Konsequenzen der Anwendung} \subsection{Nenne die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item Reduzierung der Abhängigkeiten zwischen Presentation und Domain Layer \item Reduzierung der Abhängigkeiten zwischen Presentation und Domain Layer
\item Zentralisiertes Sicherheits und Transaktionshandling \item Zentralisiertes Sicherheits und Transaktionshandling
@ -294,8 +295,8 @@ public static DocumentDTO toDTO(Document document){};
\item gut für Remote Aufrufe geeignet (weniger Aufrufe) \item gut für Remote Aufrufe geeignet (weniger Aufrufe)
\end{itemize} \end{itemize}
\subsection{Model-View-Controller Pattern} \section{Model-View-Controller Pattern}
\subsubsection{Erkläre die Funktion + Skizze} \subsection{Erkläre die Funktion + Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/mvc_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/mvc_pat.jpg}
@ -314,7 +315,7 @@ public static DocumentDTO toDTO(Document document){};
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/webapp-location.jpg} \includegraphics[width=0.5\textwidth]{pics/webapp-location.jpg}
\end{figure} \end{figure}
\subsubsection{Nenne die Konsequenzen der Anwendung} \subsection{Nenne die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item Visualisierung abhängig vom Model - nicht umgekehrt \item Visualisierung abhängig vom Model - nicht umgekehrt
\item verschiedene Darstellungen möglich \item verschiedene Darstellungen möglich
@ -322,8 +323,8 @@ public static DocumentDTO toDTO(Document document){};
\item gute Strukturierung \item gute Strukturierung
\item View wird leichter austausch bzw. änderbar \item View wird leichter austausch bzw. änderbar
\end{itemize} \end{itemize}
\subsection{Front Controller} \section{Front Controller}
\subsubsection{Erkläre die Funktion + Skizze} \subsection{Erkläre die Funktion + Skizze}
\begin{itemize} \begin{itemize}
\item Client schickt Request an Front Controller \item Client schickt Request an Front Controller
\item FC erfasst nur Infos die er für die weiter Delegation braucht \item FC erfasst nur Infos die er für die weiter Delegation braucht
@ -340,25 +341,14 @@ public static DocumentDTO toDTO(Document document){};
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/fc_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/fc_pat.jpg}
\end{figure} \end{figure}
\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} \subsection{Beschreibe ein konkretes Anwendungsbeispiel}
\begin{itemize} \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) \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} \end{itemize}
\begin{minted}[linenos,breaklines=true]{xml} \begin{minted}[linenos,breaklines=true]{xml}
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1"> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd" version="3.1">
<display-name>Practical Software Engineering 2018</display-name> ...
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
<context-param>
<param-name>primefaces.THEME</param-name>
<param-value>bootstrap</param-value>
</context-param>
<welcome-file-list>
<welcome-file>index.xhtml</welcome-file>
</welcome-file-list>
<servlet> <servlet>
<servlet-name>Faces Servlet</servlet-name> <servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
@ -457,7 +447,7 @@ public static DocumentDTO toDTO(Document document){};
</web-app> </web-app>
\end{minted} \end{minted}
\subsubsection{Anwendung im Projekt} \subsection{Anwendung im Projekt}
JavaServer Faces: mächtiges Framework, wo das MVC Pattern verwendet wird. Auf der einen Seite JavaServer Faces: mächtiges Framework, wo das MVC Pattern verwendet wird. Auf der einen Seite
stehen die reinen Views (XHTML Seiten) und auf der anderen Seite Java Beans (Java Klassen), die als stehen die reinen Views (XHTML Seiten) und auf der anderen Seite Java Beans (Java Klassen), die als
View Helper fungieren können. Beispiel: layered/MVC-JSF View Helper fungieren können. Beispiel: layered/MVC-JSF
@ -514,14 +504,14 @@ mode="advanced" label="Add document (.pdf .jpg .docx)">
</ui:composition> </ui:composition>
\end{minted} \end{minted}
\subsubsection{Nenne die Konsequenzen der Anwendung} \subsection{Nenne die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item es muss nur EIN (Front) Controller konfiguriert werden \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 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) \item da nur EIN Controller sind auch Erweiterungen durch z.B.: Decorator einfach (auch zur Laufzeit)
\end{itemize} \end{itemize}
\subsection{View Helper} \section{View Helper}
\subsubsection{Erkläre die Funktion + Skizze} \subsection{Erkläre die Funktion + Skizze}
\begin{figure}[h!] \begin{figure}[h!]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/view-helper_pat1.jpg} \includegraphics[width=0.5\textwidth]{pics/view-helper_pat1.jpg}
@ -530,11 +520,11 @@ mode="advanced" label="Add document (.pdf .jpg .docx)">
\item View delegiert Aufgaben an Helper (Helper adaptieren View zu Model) \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) \item in View befindet sich HTML Code im ViewHelper Java Code zur Aufbereitung der Daten (+ wenig HTML)
\end{itemize} \end{itemize}
\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} \subsection{Beschreibe ein konkretes Anwendungsbeispiel}
\begin{itemize} \begin{itemize}
\item bei Verwendung von JSP (Java Server Pages enthalten neben HTML auch Java Code) \item bei Verwendung von JSP (Java Server Pages enthalten neben HTML auch Java Code)
\end{itemize} \end{itemize}
\subsubsection{Nenne die Konsequenzen der Anwendung} \subsection{Nenne die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item kapselt Design-Code in View und View-Processing-Code Logik in Helper \item kapselt Design-Code in View und View-Processing-Code Logik in Helper
\item steigert Wiederverwendbarkeit, Wartbarkeit und Strukturierungsqualität der Anwendung \item steigert Wiederverwendbarkeit, Wartbarkeit und Strukturierungsqualität der Anwendung
@ -547,8 +537,8 @@ mode="advanced" label="Add document (.pdf .jpg .docx)">
\end{itemize} \end{itemize}
\subsection{Dependency Injection (don't call us, we'll call you)} \section{Dependency Injection (don't call us, we'll call you)}
\subsubsection{Erkläre die Funktion + Skizze} \subsection{Erkläre die Funktion + Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/dependency_inj_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/dependency_inj_pat.jpg}
@ -586,7 +576,7 @@ mode="advanced" label="Add document (.pdf .jpg .docx)">
\item Context wird geladen damit alles verknüpft ist \item Context wird geladen damit alles verknüpft ist
\item erspart Factories \item erspart Factories
\end{itemize} \end{itemize}
\subsubsection{Nenne die Konsequenzen der Anwendung} \subsection{Nenne die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item loose gekoppelte Objekte \item loose gekoppelte Objekte
\item Referenzen nurmehr auf Interfaces \item Referenzen nurmehr auf Interfaces
@ -598,8 +588,8 @@ mode="advanced" label="Add document (.pdf .jpg .docx)">
\item Nachteil Annotation: nicht so flexibel wie XML \item Nachteil Annotation: nicht so flexibel wie XML
\end{itemize} \end{itemize}
\end{itemize} \end{itemize}
\subsection{Data Transfer Object (DTO) Pattern} \section{Data Transfer Object (DTO) Pattern}
\subsubsection{Erkläre die Funktion (Skizze - ein Grund für DTO)} \subsection{Erkläre die Funktion (Skizze - ein Grund für DTO)}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.9\textwidth]{pics/lok-vs-remote.jpg} \includegraphics[width=0.9\textwidth]{pics/lok-vs-remote.jpg}
@ -610,15 +600,15 @@ mode="advanced" label="Add document (.pdf .jpg .docx)">
\item fasst Daten verschiedener Objekte zusammen die vom Remote Objekt benötigt werden \item fasst Daten verschiedener Objekte zusammen die vom Remote Objekt benötigt werden
\item ev. Map, Record Set, ... \item ev. Map, Record Set, ...
\end{itemize} \end{itemize}
\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel} \subsection{Beschreibe ein konkretes Anwendungsbeispiel}
% todo: Anwendungsbeispiel % todo: Anwendungsbeispiel
\subsubsection{Nenne die Konsequenzen der Anwendung} \subsection{Nenne die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item kapselt und versteckt \item kapselt und versteckt
\item nimmt Komplexität \item nimmt Komplexität
\item steigert Effizienz da weniger Aufrufe über Remotegrenze \item steigert Effizienz da weniger Aufrufe über Remotegrenze
\end{itemize} \end{itemize}
\subsection{Page-Object-Pattern} \section{Page-Object-Pattern}
PageObjectPattern PageObjectPattern
HTML – wrappen mit JavaCode, um es zu manipulieren HTML – wrappen mit JavaCode, um es zu manipulieren
@ -629,20 +619,20 @@ GUI-Test-Klasse und Page-Object
Bei HTML-Änderung muss ich nur Page-Objekt ändern und ansonsten nichts angreifen (Verkapselung) Bei HTML-Änderung muss ich nur Page-Objekt ändern und ansonsten nichts angreifen (Verkapselung)
\section{Remote} \section{Remote}
\subsection{Beschreibe die Unterschiede zwischen lokalem und Remote Interface Design} \section{Beschreibe die Unterschiede zwischen lokalem und Remote Interface Design}
\begin{itemize} \begin{itemize}
\item Aufrufe innerhalb des Prozesses sind schneller als über Prozessgrenzen \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 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) \item viele kleine Aufrufe mit wenigen Daten sind "teuer" (Latenz durch Verbindungsherstellung)
\end{itemize} \end{itemize}
\subsection{Beschreibe drei Situationen wo Multiple Prozesse in Applikationen verwendet werden müssen} \section{Beschreibe drei Situationen wo Multiple Prozesse in Applikationen verwendet werden müssen}
\begin{itemize} \begin{itemize}
\item Trennung zwischen Clients und Servern in Business Software \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 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 \item Trennung wegen unterschiedlichen Anbietern oder Programmiersprachen
\end{itemize} \end{itemize}
\subsection{Beschreibe das folgende Diagramm. Was können wir daraus für das Design von Remote Interfaces folgern?} \section{Beschreibe das folgende Diagramm. Was können wir daraus für das Design von Remote Interfaces folgern?}
\begin{itemize} \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 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 \item dieser Gedanke befürwortet auch den Einsatz von DTO um Calls und Daten zu bündeln
@ -652,7 +642,7 @@ Bei HTML-Änderung muss ich nur Page-Objekt ändern und ansonsten nichts angreif
\includegraphics[width=0.9\textwidth]{pics/lok-vs-remote.jpg} \includegraphics[width=0.9\textwidth]{pics/lok-vs-remote.jpg}
\end{figure} \end{figure}
\section{Exception Handling} \section{Exception Handling}
\subsection{Beschreibe den Unterschied zwischen Checked und Runtime Exceptions in Java (inkl. Klassendiagramm)} \section{Beschreibe den Unterschied zwischen Checked und Runtime Exceptions in Java (inkl. Klassendiagramm)}
\begin{itemize} \begin{itemize}
\item Checked Exceptions (z.B. SQL-Exception) leiten von Exception Klasse ab und müssen behandelt werden (trows - catch) \item Checked Exceptions (z.B. SQL-Exception) leiten von Exception Klasse ab und müssen behandelt werden (trows - catch)
\begin{itemize} \begin{itemize}
@ -667,16 +657,16 @@ Bei HTML-Änderung muss ich nur Page-Objekt ändern und ansonsten nichts angreif
\centering \centering
\includegraphics[width=0.3\textwidth]{pics/except_class_dia.jpg} \includegraphics[width=0.3\textwidth]{pics/except_class_dia.jpg}
\end{figure} \end{figure}
\subsection{Beschreibe einen Use Case für eine Checked Exceptions in Java} \section{Beschreibe einen Use Case für eine Checked Exceptions in Java}
\begin{itemize} \begin{itemize}
\item eine Netzwerkübertragung schlägt fehl - es ist vorgesehen, dass der Applikations-User dies neu anstoßen kann \item eine Netzwerkübertragung schlägt fehl - es ist vorgesehen, dass der Applikations-User dies neu anstoßen kann
\end{itemize} \end{itemize}
\subsection{Beschreibe einen Use Case für eine Runtime Exceptions in Java} \section{Beschreibe einen Use Case für eine Runtime Exceptions in Java}
\begin{itemize} \begin{itemize}
\item Die Datenbank ist beschädigt - die Exception geht durch alle Layer erst mit \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. Implementierungsspezifischer Exception später mit Runtime ohne Stacktrace (Sicherheit) bis zum User.
\end{itemize} \end{itemize}
\subsection{Beschreibe 5 Best Practice Beispiele beim Einsatz von Exceptions} \section{Beschreibe 5 Best Practice Beispiele beim Einsatz von Exceptions}
\begin{itemize} \begin{itemize}
\item Exceptions nicht für Programmflusskontrolle verwenden (schlechte Performance) \item Exceptions nicht für Programmflusskontrolle verwenden (schlechte Performance)
\item offene Ressourcen schließen (try-with-resources bzw. close im finally) \item offene Ressourcen schließen (try-with-resources bzw. close im finally)
@ -685,7 +675,7 @@ Bei HTML-Änderung muss ich nur Page-Objekt ändern und ansonsten nichts angreif
\item dokumentieren mit @trows im DOC, testen mit JUnit \item dokumentieren mit @trows im DOC, testen mit JUnit
\end{itemize} \end{itemize}
\subsection{Beschreibe 5 Exception Handling Anti Pattern} \section{Beschreibe 5 Exception Handling Anti Pattern}
\begin{itemize} \begin{itemize}
\item Log and Trow (nie beides: entweder, oder) \item Log and Trow (nie beides: entweder, oder)
\item Trowing Exception bzw. catch Exception (spezifischere anstatt Basisklasse verwenden) \item Trowing Exception bzw. catch Exception (spezifischere anstatt Basisklasse verwenden)
@ -695,15 +685,15 @@ Bei HTML-Änderung muss ich nur Page-Objekt ändern und ansonsten nichts angreif
\item Unsupported Operation return Null (besser UnsupportedOperationException) \item Unsupported Operation return Null (besser UnsupportedOperationException)
\end{itemize} \end{itemize}
\section{Logging} \section{Logging}
\subsection{Nenne die Nachteile von debugging mit printf() sowie die Vorteile die Logging Frameworks wie log4j bieten} \section{Nenne die Nachteile von debugging mit printf() sowie die Vorteile die Logging Frameworks wie log4j bieten}
\subsubsection{Nachteile printf()} \subsection{Nachteile printf()}
\begin{itemize} \begin{itemize}
\item Produktiv-Code wird überfüllt -> erschwert Lesbarkeit \item Produktiv-Code wird überfüllt -> erschwert Lesbarkeit
\item Consolenausgabe wird bei vielen prints auch schnell unübersichtlich \item Consolenausgabe wird bei vielen prints auch schnell unübersichtlich
\item im Falle eines vorzeitigen Absturzes können Ausgabedaten verloren gehen \item im Falle eines vorzeitigen Absturzes können Ausgabedaten verloren gehen
\item Performance bei vielen Logprints \item Performance bei vielen Logprints
\end{itemize} \end{itemize}
\subsubsection{Vorteile Logging mittels Framework (z.B.: log4j)} \subsection{Vorteile Logging mittels Framework (z.B.: log4j)}
\begin{itemize} \begin{itemize}
\item Nutzt ein einheitliches Format / Konventionen \item Nutzt ein einheitliches Format / Konventionen
\item logging kann optional an und ausgeschalten werden \item logging kann optional an und ausgeschalten werden
@ -717,8 +707,8 @@ Bei HTML-Änderung muss ich nur Page-Objekt ändern und ansonsten nichts angreif
\includegraphics[width=0.4\textwidth]{pics/tree-project-test.png} \includegraphics[width=0.4\textwidth]{pics/tree-project-test.png}
\end{figure} \end{figure}
\section{Toni} \section{Toni}
\subsection{Annotationen} \section{Annotationen}
\subsubsection{@MappedSuperclass} \subsection{@MappedSuperclass}
\begin{itemize} \begin{itemize}
\item ist im Hybernate Framework eine Klasse durch die gemeinsame Felder definiert werden. \item ist im Hybernate Framework eine Klasse durch die gemeinsame Felder definiert werden.
\item definiert eine abstrakte Superklasse \item definiert eine abstrakte Superklasse
@ -742,7 +732,7 @@ Bei HTML-Änderung muss ich nur Page-Objekt ändern und ansonsten nichts angreif
@Local – Klasse für lokale Aufrufe. @Local – Klasse für lokale Aufrufe.
@Remote – interprozessaufrufe. RMI @Remote – interprozessaufrufe. RMI
@ApplicationException – Rollback wenn so eine Exception kommt, Nachricht zum Client. @ApplicationException – Rollback wenn so eine Exception kommt, Nachricht zum Client.
\subsection{Patterns in Practice} \section{Patterns in Practice}
Data Access Layer Data Access Layer
Entity – Java Repräsentation vom DB Entity Entity – Java Repräsentation vom DB Entity
DAO damit man auf die Entities zugreifen kann. DB abstrahieren. Methoden mit denen man auf die DB zugreifen kann. DAO damit man auf die Entities zugreifen kann. DB abstrahieren. Methoden mit denen man auf die DB zugreifen kann.
@ -755,7 +745,7 @@ Mapper – von DTO in Entity und Entity ins DTO.
FrontController web.xml FrontController web.xml
ViewHelper *ServiceImpl ViewHelper *ServiceImpl
\subsection{Konfigurationsdateien (pom.xml), (persistence.xml) und noch a bissl mehr Scheiß} \section{Konfigurationsdateien (pom.xml), (persistence.xml) und noch a bissl mehr Scheiß}
Resource plugin – klar für Ressourcen Resource plugin – klar für Ressourcen
Wildfly – server Wildfly – server
Primeafce = jsf Framework Primeafce = jsf Framework
@ -763,7 +753,7 @@ Jacoco = test Coverage
Slf4j = logger Slf4j = logger
Jaxb – xml Jaxb – xml
Cdi = context dependancy injection Cdi = context dependancy injection
\subsection{Reihenfolge - Wildfly - Abfolge - einzelne Schritte} \section{Reihenfolge - Wildfly - Abfolge - einzelne Schritte}
Reihenfolge: Reihenfolge:
\begin{multicols}{2} \begin{multicols}{2}
\begin{enumerate} \begin{enumerate}
@ -777,7 +767,7 @@ Reihenfolge:
\end{enumerate} \end{enumerate}
\end{multicols} \end{multicols}
\subsection{Frageart Prüfung} \section{Frageart Prüfung}
Welche Fehler können bei Exception-Handling vorkommen in unserem Projekt?? – wie funktioniert es grundsätzlich in unserem Code Welche Fehler können bei Exception-Handling vorkommen in unserem Projekt?? – wie funktioniert es grundsätzlich in unserem Code
DocumentDAO – DocumentService – DocumentController – so sollte Exception-Handling implementiert warden DocumentDAO – DocumentService – DocumentController – so sollte Exception-Handling implementiert warden

72
parts/02_comp-based_arc.tex
View File

@ -6,14 +6,14 @@
\item wird von Dritten zusammen mit anderen Components verwendet \item wird von Dritten zusammen mit anderen Components verwendet
\end{itemize} \end{itemize}
\section{Infrastruktur Pattern} \section{Infrastruktur Pattern}
\subsection{Component Pattern} \section{Component Pattern}
\subsubsection{Beschreibe die Problemstellung} \subsection{Beschreibe die Problemstellung}
\begin{itemize} \begin{itemize}
\item großer Broken Funktionalität vom technischen Teil getrennt ist besser als Vermischung \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 Ä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 \item unabhängige Deployments bzw. Updates der Teile ist unmöglich -> soll aber möglich werden
\end{itemize} \end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze} \subsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/component_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/component_pat.jpg}
@ -23,20 +23,20 @@
\item jede Komponente soll ihre Verantwortlichkeiten ohne starke Abhängigkeiten \textbf{vollständig} implementieren \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 \item durch Zusammenfügen der Funktionalitäten loser Komponenten wird die Anwendung realisiert
\end{itemize} \end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung} \subsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item eine Komponente sollte sich gut an andere anpassen, jedoch nur lose an diese gekoppelt sein \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 Comp-Interface ist von Comp-Impl getrennt
\item Funktionalitätsänderung, erfordert nur Änderung innerhalb entsprechenden Komponente \item Funktionalitätsänderung, erfordert nur Änderung innerhalb entsprechenden Komponente
\end{itemize} \end{itemize}
\subsection{Container Pattern} \section{Container Pattern}
\subsubsection{Beschreibe die Problemstellung} \subsection{Beschreibe die Problemstellung}
\begin{itemize} \begin{itemize}
\item Components enthalten reine Business Logik (keine technischen Aspekte) \item Components enthalten reine Business Logik (keine technischen Aspekte)
\item es wird etwas zur Behandlung der technischen Aspekte und Integration benötigt... \item es wird etwas zur Behandlung der technischen Aspekte und Integration benötigt...
\item Lösung soll wiederverwendet werden können \item Lösung soll wiederverwendet werden können
\end{itemize} \end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze} \subsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/container_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/container_pat.jpg}
@ -47,19 +47,19 @@
\item um Wiederverwendung zu fördern werden Frameworks verwendet (z.B.: Code Generation) \item um Wiederverwendung zu fördern werden Frameworks verwendet (z.B.: Code Generation)
\end{itemize} \end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung} \subsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item zur Integration spezifizieren Annotations technische Anforderungen der Components (getrennt von Implementierung) \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 Glue-Code-Layer (generischer Containerteil) wird zur Anpassung /Füllung erstellt
\item für unterschiedliche Component Typen gibt es verschiedene Container \item für unterschiedliche Component Typen gibt es verschiedene Container
\end{itemize} \end{itemize}
\subsection{Service Component Pattern} \section{Service Component Pattern}
\subsubsection{Beschreibe die Problemstellung} \subsection{Beschreibe die Problemstellung}
\begin{itemize} \begin{itemize}
\item es werden "Service Provider" benötigt, dies sind Komponenten die andere Komponenten der externe Systeme verändern \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 \item dienen als Fassade für Subsystem, welches aus weiteren Komponenten besteht
\end{itemize} \end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze} \subsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/service_compontent_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/service_compontent_pat.jpg}
@ -70,7 +70,7 @@
\item so kann Container Components effizient verwalten \item so kann Container Components effizient verwalten
\item jede Operation muss abgeschlossen sein \item jede Operation muss abgeschlossen sein
\end{itemize} \end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung} \subsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item dient als Fassade für komplexe Systeme \item dient als Fassade für komplexe Systeme
\item vereinfacht Zugriff auf diese Systeme \item vereinfacht Zugriff auf diese Systeme
@ -79,15 +79,15 @@
\end{itemize} \end{itemize}
\subsection{Session Component Pattern} \section{Session Component Pattern}
\subsubsection{Beschreibe die Problemstellung} \subsection{Beschreibe die Problemstellung}
\begin{itemize} \begin{itemize}
\item Service Component reicht nicht aus \item Service Component reicht nicht aus
\item es soll auch ein Client oder Session-Status gespeichert werden \item es soll auch ein Client oder Session-Status gespeichert werden
\item Status ist nicht persistent und wird durch Garbage-Collection wieder entfernt \item Status ist nicht persistent und wird durch Garbage-Collection wieder entfernt
\end{itemize} \end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze} \subsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/session_component_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/session_component_pat.jpg}
@ -97,7 +97,7 @@
\item Overhead gering da es keine Nebenläufigkeit gibt \item Overhead gering da es keine Nebenläufigkeit gibt
\item Ressourcenverbrauch wird auch vom Container niedrig gehalten \item Ressourcenverbrauch wird auch vom Container niedrig gehalten
\end{itemize} \end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung} \subsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item nur ein Client pro Komponente erlaubt \item nur ein Client pro Komponente erlaubt
\item Server kann Speicher ausgehen (\#Session-Components = \#Clients) \item Server kann Speicher ausgehen (\#Session-Components = \#Clients)
@ -105,12 +105,12 @@
\end{itemize} \end{itemize}
\section{Implementierungs Pattern} \section{Implementierungs Pattern}
\subsection{Virtual Instance Pattern} \section{Virtual Instance Pattern}
\subsubsection{Beschreibe die Problemstellung} \subsection{Beschreibe die Problemstellung}
\begin{itemize} \begin{itemize}
\item viele Komponenten-Instanzen können zu Ressourcenknappheit (Speicher, Container, Systemressourcen) führen \item viele Komponenten-Instanzen können zu Ressourcenknappheit (Speicher, Container, Systemressourcen) führen
\end{itemize} \end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze} \subsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/virtual_instance_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/virtual_instance_pat.jpg}
@ -125,17 +125,17 @@
\item Passivation (reale Instanzen werden zwischenzeitlich auf Festplatte geschrieben und aus Speicher gelöscht, bei Bedarf wieder geladen) \item Passivation (reale Instanzen werden zwischenzeitlich auf Festplatte geschrieben und aus Speicher gelöscht, bei Bedarf wieder geladen)
\end{itemize} \end{itemize}
\end{itemize} \end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung} \subsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item Anzahl realer Instanzen im Speicher meist wesentlich geringer als virtueller \item Anzahl realer Instanzen im Speicher meist wesentlich geringer als virtueller
\item somit ist Aufwand und Speicherbedarf des Containers geringer \item somit ist Aufwand und Speicherbedarf des Containers geringer
\end{itemize} \end{itemize}
\subsection{Instance Pooling Pattern} \section{Instance Pooling Pattern}
\subsubsection{Beschreibe die Problemstellung} \subsection{Beschreibe die Problemstellung}
\begin{itemize} \begin{itemize}
\item Komponenteninstanzen erstellen und entfernen ist "teuer" (Overhead) \item Komponenteninstanzen erstellen und entfernen ist "teuer" (Overhead)
\end{itemize} \end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze} \subsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/instance_pooling_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/instance_pooling_pat.jpg}
@ -146,7 +146,7 @@
\item nach Nutzung kommt diese wieder in den Pool \item nach Nutzung kommt diese wieder in den Pool
\item Zustandsänderungen werden durch Lifecycle Callbacks kontrolliert \item Zustandsänderungen werden durch Lifecycle Callbacks kontrolliert
\end{itemize} \end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung} \subsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item bei Container Instance Pooling, zwei Status: \item bei Container Instance Pooling, zwei Status:
\begin{itemize} \begin{itemize}
@ -159,15 +159,15 @@
\end{itemize} \end{itemize}
\subsection{Passivation Pattern} \section{Passivation Pattern}
\subsubsection{Beschreibe die Problemstellung} \subsection{Beschreibe die Problemstellung}
\begin{itemize} \begin{itemize}
\item Session Components haben Status ohne Repräsentation im Speicher \item Session Components haben Status ohne Repräsentation im Speicher
\item es gibt Zeiträume der Inaktivität \item es gibt Zeiträume der Inaktivität
\item es sollen Ressourcen gespart werden \item es sollen Ressourcen gespart werden
\item z.B. Einkaufswagen eines Online Shops \item z.B. Einkaufswagen eines Online Shops
\end{itemize} \end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze} \subsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/passivation_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/passivation_pat.jpg}
@ -177,7 +177,7 @@
\item Zustand wird persistent gespeichert und aus Hauptspeicher gelöscht \item Zustand wird persistent gespeichert und aus Hauptspeicher gelöscht
\item wird Instanz benötigt wird diese von Festplatte in Hauptspeicher geladen \item wird Instanz benötigt wird diese von Festplatte in Hauptspeicher geladen
\end{itemize} \end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung} \subsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item Instanzen werden wirklich aus Speicher entfernt \item Instanzen werden wirklich aus Speicher entfernt
\item bei neuerlicher Herstellung müssen auch Verbindungen zu anderen Ressourcen neu geladen werden \item bei neuerlicher Herstellung müssen auch Verbindungen zu anderen Ressourcen neu geladen werden
@ -185,8 +185,8 @@
\item bedeutet deutlichen Overhead und sollte vermieden werden (besser mehr Speicher) \item bedeutet deutlichen Overhead und sollte vermieden werden (besser mehr Speicher)
\end{itemize} \end{itemize}
\subsection{Component Proxy Pattern} \section{Component Proxy Pattern}
\subsubsection{Beschreibe die Problemstellung} \subsection{Beschreibe die Problemstellung}
\begin{itemize} \begin{itemize}
\item Clients müssen auf virtuelle Komponenteninstanzen referenzieren \item Clients müssen auf virtuelle Komponenteninstanzen referenzieren
\item Container muss bei Client Aufruf für virtuelle, physikalische Instanz bereitstellen \item Container muss bei Client Aufruf für virtuelle, physikalische Instanz bereitstellen
@ -194,7 +194,7 @@
\end{itemize} \end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze} \subsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/component_proxy_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/component_proxy_pat.jpg}
@ -206,7 +206,7 @@
\item zur Performancesteigerung bedient ein Proxy mehrere virtuelle Komponenteninstanzen \item zur Performancesteigerung bedient ein Proxy mehrere virtuelle Komponenteninstanzen
\end{itemize} \end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung} \subsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item dem Client wird durch den Proxy etwas gegeben, das ohne echte Komponenteninstanz aufgerufen werden kann \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 Client Methodenaufrufe enthalten ID der logischen Komponenteninstanz zur korrekten Weiterleitung
@ -215,14 +215,14 @@
\end{itemize} \end{itemize}
\subsection{Glue-Code Pattern} \section{Glue-Code Pattern}
\subsubsection{Beschreibe die Problemstellung} \subsection{Beschreibe die Problemstellung}
\begin{itemize} \begin{itemize}
\item Container soll wiederverwendet werden, dazu muss Funktionalität generisch sein \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 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 \item völlig generische Container können keine unterschiedlichen Komponenten beherbergen
\end{itemize} \end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze} \subsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp] \begin{figure}[!htp]
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/glue_code_pat.jpg} \includegraphics[width=0.5\textwidth]{pics/glue_code_pat.jpg}
@ -233,7 +233,7 @@
\item Compontent-Proxy ist Teil dieser Schicht \item Compontent-Proxy ist Teil dieser Schicht
\end{itemize} \end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung} \subsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize} \begin{itemize}
\item in Java mit Reflection umsetzbar (ermöglicht dynamischen Operationsaufruf) \item in Java mit Reflection umsetzbar (ermöglicht dynamischen Operationsaufruf)
\item Reflection viel langsamer als spezifischer generierter Code \item Reflection viel langsamer als spezifischer generierter Code

118
parts/03_service-orientated_arc.tex
View File

@ -1,6 +1,6 @@
\part{Service-Oriented Architecture (SOA)} \part{Service-Oriented Architecture (SOA)}
\section{SOA} \section{SOA}
\subsection{Auf welche drei technischen Konzepte basiert SOA?} \section{Auf welche drei technischen Konzepte basiert SOA?}
\begin{itemize} \begin{itemize}
\item Services: unabhängige Business-Funktionalität \item Services: unabhängige Business-Funktionalität
\item Enterprise service bus (ESB): Infrastruktur, zwischen verteilten Service-Systemen \item Enterprise service bus (ESB): Infrastruktur, zwischen verteilten Service-Systemen
@ -13,7 +13,7 @@
\item einzelne Services sollen auch dann arbeiten, wenn andere nicht verfügbar oder langsam sind \item einzelne Services sollen auch dann arbeiten, wenn andere nicht verfügbar oder langsam sind
\end{itemize} \end{itemize}
\end{itemize} \end{itemize}
\subsection{Beschreibe die Eigenschaften von großen Verteilten Systemen} \section{Beschreibe die Eigenschaften von großen Verteilten Systemen}
\begin{itemize} \begin{itemize}
\item Heterogen -> unterschiedliche \item Heterogen -> unterschiedliche
\begin{itemize} \begin{itemize}
@ -24,7 +24,7 @@
\item Nicht perfekt (wäre zu teuer) \item Nicht perfekt (wäre zu teuer)
\item Redundant (alle Redundanz zu eliminieren verlangsamt das System) \item Redundant (alle Redundanz zu eliminieren verlangsamt das System)
\end{itemize} \end{itemize}
\subsection{Beschreibe den Begriff Business View im Kontext von SOA} \section{Beschreibe den Begriff Business View im Kontext von SOA}
\begin{itemize} \begin{itemize}
\item Geschäftsprozessmodellierung wird verwendet um alle Aspekte eines GP grafisch zu beschreiben \item Geschäftsprozessmodellierung wird verwendet um alle Aspekte eines GP grafisch zu beschreiben
\item Standards zur Modellierung, damit Experten daraus GP entwerfen können: \item Standards zur Modellierung, damit Experten daraus GP entwerfen können:
@ -34,7 +34,7 @@
\end{itemize} \end{itemize}
\item Process View entspricht Top-Down-Ansatz der Systemmodellierung (Prozess auf kleinere herunter brechen) \item Process View entspricht Top-Down-Ansatz der Systemmodellierung (Prozess auf kleinere herunter brechen)
\end{itemize} \end{itemize}
\subsection{Beschreibe den Begriff Service View auf ein Software-System im Kontext von SOA} \section{Beschreibe den Begriff Service View auf ein Software-System im Kontext von SOA}
\begin{itemize} \begin{itemize}
\item entspricht Bottom-Up-Ansatz der Systemmodellierung (Services in größere Einheiten zusammenfassen bis GP vollständig) \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-Definition ist Kern der Service-orientierten Architektur
@ -45,14 +45,14 @@
\end{itemize} \end{itemize}
\item Vertrag: ist vollständige Spezifizierung eines Services zwischen Consumer und Provider \item Vertrag: ist vollständige Spezifizierung eines Services zwischen Consumer und Provider
\end{itemize} \end{itemize}
\subsection{Beschreibe drei unterschiedliche Service Kategorien} \section{Beschreibe drei unterschiedliche Service Kategorien}
\subsubsection{Basic Services} \subsection{Basic Services}
\begin{itemize} \begin{itemize}
\item grundlegende, an vielen Stellen gebrauchte Business-Funktionalität \item grundlegende, an vielen Stellen gebrauchte Business-Funktionalität
\item meist kurze Laufzeit \item meist kurze Laufzeit
\item stateless \item stateless
\end{itemize} \end{itemize}
\subsubsection{Composed Services} \subsection{Composed Services}
\begin{itemize} \begin{itemize}
\item aus Basic Services zusammengesetzt („Orchestration“) \item aus Basic Services zusammengesetzt („Orchestration“)
\item auf höherer Ebene als Basic Services angesiedelt \item auf höherer Ebene als Basic Services angesiedelt
@ -60,7 +60,7 @@
\item kurze Laufzeit \item kurze Laufzeit
\item oft Adapter Services um anderen Services eine Schnittstelle zu bieten \item oft Adapter Services um anderen Services eine Schnittstelle zu bieten
\end{itemize} \end{itemize}
\subsubsection{Process Services} \subsection{Process Services}
\begin{itemize} \begin{itemize}
\item Längerfristige Prozesse, die Geschäftsprozesse umsetzen \item Längerfristige Prozesse, die Geschäftsprozesse umsetzen
\item Interagieren mit Benutzer oder anderen Systemen \item Interagieren mit Benutzer oder anderen Systemen
@ -68,7 +68,7 @@
\item statefull (z.B. wie weit ist Benutzer im Prozess) \item statefull (z.B. wie weit ist Benutzer im Prozess)
\end{itemize} \end{itemize}
\subsection{Erkläre die beiden Ansätze für SOA System-Design inkl. Skizze} \section{Erkläre die beiden Ansätze für SOA System-Design inkl. Skizze}
\begin{itemize} \begin{itemize}
\item Kommunikation zwischen Komponenten funktioniert über Schnittstellen \item Kommunikation zwischen Komponenten funktioniert über Schnittstellen
\item Schnittstellen sind public und published, deshalb schwer änderbar \item Schnittstellen sind public und published, deshalb schwer änderbar
@ -78,16 +78,16 @@
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/topDown-bottomUp.jpg} \includegraphics[width=0.5\textwidth]{pics/topDown-bottomUp.jpg}
\end{figure} \end{figure}
\subsubsection{Top Down} \subsection{Top Down}
\begin{itemize} \begin{itemize}
\item Prozess auf kleiner Prozesse herunterbrechen, bis Ebene von Basic Services erreicht ist \item Prozess auf kleiner Prozesse herunterbrechen, bis Ebene von Basic Services erreicht ist
\end{itemize} \end{itemize}
\subsubsection{Bottom Up} \subsection{Bottom Up}
\begin{itemize} \begin{itemize}
\item Services in größere Einheiten zusammenfassen, bis Geschäftsprozess vollständig abgebildet \item Services in größere Einheiten zusammenfassen, bis Geschäftsprozess vollständig abgebildet
\end{itemize} \end{itemize}
\subsection{Beschreibe das Konzept des Enterprise Service Bus inkl. Skizze} \section{Beschreibe das Konzept des Enterprise Service Bus inkl. Skizze}
\begin{itemize} \begin{itemize}
\item ist Kommunikationsmedium zwischen einzelnen Services \item ist Kommunikationsmedium zwischen einzelnen Services
@ -112,23 +112,23 @@
\includegraphics[width=0.3\textwidth]{pics/esb_2.jpg} \includegraphics[width=0.3\textwidth]{pics/esb_2.jpg}
\includegraphics[width=0.3\textwidth]{pics/esb_3.jpg} \includegraphics[width=0.3\textwidth]{pics/esb_3.jpg}
\end{figure} \end{figure}
\subsection{Beschreibe den Unterschied zwischen P2P Verbindungen und dem Konzept ESB als Mediator} \section{Beschreibe den Unterschied zwischen P2P Verbindungen und dem Konzept ESB als Mediator}
\begin{itemize} \begin{itemize}
\item Unterschied: Kopplung der Consumer an physikalische Verbindung (P2P enger) \item Unterschied: Kopplung der Consumer an physikalische Verbindung (P2P enger)
\end{itemize} \end{itemize}
\subsubsection{Point-to-Point} \subsection{Point-to-Point}
\begin{itemize} \begin{itemize}
\item Consumer muss Endpunkt kennen da Empfänger bestimmt sein muss \item Consumer muss Endpunkt kennen da Empfänger bestimmt sein muss
\item ist Verbindung nicht möglich, schlägt Aufruf fehl \item ist Verbindung nicht möglich, schlägt Aufruf fehl
\end{itemize} \end{itemize}
\subsubsection{ESB als Mediator} \subsection{ESB als Mediator}
\begin{itemize} \begin{itemize}
\item Ziel-Service wird vom Consumer mittels Tag angegeben \item Ziel-Service wird vom Consumer mittels Tag angegeben
\item ESB kümmert sich um die Zustellung -> Vorteil: dynamische Änderungen möglich \item ESB kümmert sich um die Zustellung -> Vorteil: dynamische Änderungen möglich
\end{itemize} \end{itemize}
\subsection{Beschreibe das Konzept der loosen Kopplung und die beiden wichtigsten damit verbundenen Themen} \section{Beschreibe das Konzept der loosen Kopplung und die beiden wichtigsten damit verbundenen Themen}
\subsubsection{Konzept} \subsection{Konzept}
\begin{itemize} \begin{itemize}
\item bezeichnet einen geringen Grad der Abhängigkeit zwischen Hard- oder Software-Komponenten \item bezeichnet einen geringen Grad der Abhängigkeit zwischen Hard- oder Software-Komponenten
\item ermöglicht \item ermöglicht
@ -140,7 +140,7 @@
\end{itemize} \end{itemize}
\end{multicols} \end{multicols}
\end{itemize} \end{itemize}
\subsubsection{damit verbundene Konzepte} \subsection{damit verbundene Konzepte}
\begin{itemize} \begin{itemize}
\item Asynchrone Kommunikation \item Asynchrone Kommunikation
\begin{itemize} \begin{itemize}
@ -156,8 +156,8 @@
\end{itemize} \end{itemize}
\section{Microservice Architekturen} \section{Microservice Architekturen}
\subsection{Beschreibe die wesentlichsten Unterschiede zwischen einer monolithischen Anwendung und dem Mikroservices Ansatz} \section{Beschreibe die wesentlichsten Unterschiede zwischen einer monolithischen Anwendung und dem Mikroservices Ansatz}
\subsubsection{Monolithisch} \subsection{Monolithisch}
\begin{itemize} \begin{itemize}
\item Enterprise Applications bestehen oft aus drei Teilen \item Enterprise Applications bestehen oft aus drei Teilen
\begin{itemize} \begin{itemize}
@ -167,7 +167,7 @@
\end{itemize} \end{itemize}
\item da die Applikation \textbf{eine} Einheit ist, muss sie bei Änderungen neu gebuilded und deployed werden \item da die Applikation \textbf{eine} Einheit ist, muss sie bei Änderungen neu gebuilded und deployed werden
\end{itemize} \end{itemize}
\subsubsection{Microservices} \subsection{Microservices}
\begin{itemize} \begin{itemize}
\item sind gut skalierbar \item sind gut skalierbar
\item Applikation besteht aus vielen kleinen Services \item Applikation besteht aus vielen kleinen Services
@ -176,26 +176,26 @@
\item Services können unabhängig voneinander deployed werden \item Services können unabhängig voneinander deployed werden
\end{itemize} \end{itemize}
\subsection{Vergleiche die Unterschiedlichen Skalierungstrategien von monolitischen Applikationen und Mikroservices} \section{Vergleiche die Unterschiedlichen Skalierungstrategien von monolitischen Applikationen und Mikroservices}
\subsubsection{Monolithisch} \subsection{Monolithisch}
\begin{itemize} \begin{itemize}
\item gesamte Applikation muss skaliert werden \item gesamte Applikation muss skaliert werden
\item erfolgt durch mehrerer Instanzen (horizontale Skalierung) bzw. Load Balancing \item erfolgt durch mehrerer Instanzen (horizontale Skalierung) bzw. Load Balancing
\item Nachteil: alles und nicht nur benötigtes wird dupliziert -> Ressourcenbelastung \item Nachteil: alles und nicht nur benötigtes wird dupliziert -> Ressourcenbelastung
\end{itemize} \end{itemize}
\subsubsection{Microservices} \subsection{Microservices}
\begin{itemize} \begin{itemize}
\item Service-Grenzen sind funktional orientiert \item Service-Grenzen sind funktional orientiert
\item es können speziell benötigte Services öfter instanziert werden \item es können speziell benötigte Services öfter instanziert werden
\item Nachteil: Interprozesskommunikation nimmt aufgrund der Verteilung auf viele kleine Servicekomponenten zu \item Nachteil: Interprozesskommunikation nimmt aufgrund der Verteilung auf viele kleine Servicekomponenten zu
\end{itemize} \end{itemize}
\subsection{Erkläre den Unterschied zwischen Libraries und Services} \section{Erkläre den Unterschied zwischen Libraries und Services}
\subsubsection{Library} \subsection{Library}
\begin{itemize} \begin{itemize}
\item Komponenten, die in eine Applikation verlinkt werden und lokal (im selben Prozess) verwendet werden \item Komponenten, die in eine Applikation verlinkt werden und lokal (im selben Prozess) verwendet werden
\end{itemize} \end{itemize}
\subsubsection{Services} \subsection{Services}
\begin{itemize} \begin{itemize}
\item besitzen immer eine Remote Schnittstelle \item besitzen immer eine Remote Schnittstelle
\item befinden sich in eigenem Prozess (stärker entkoppelt) \item befinden sich in eigenem Prozess (stärker entkoppelt)
@ -208,20 +208,20 @@
\end{itemize} \end{itemize}
\end{itemize} \end{itemize}
\subsection{Beschreibe die Beziehung zwischen einer Team Struktur und dem Design einer Software} \section{Beschreibe die Beziehung zwischen einer Team Struktur und dem Design einer Software}
\subsubsection{Silo-Ansatz} \subsection{Silo-Ansatz}
\begin{itemize} \begin{itemize}
\item Zuständigkeiten bei großen Applikationen werden oft an technologische Grenzen angepasst \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 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 \item kleine Änderungen führen so bereits zu hohen Kosten da Team übergreifend gearbeitet werden muss
\end{itemize} \end{itemize}
\subsubsection{Cross-Functional Ansatz} \subsection{Cross-Functional Ansatz}
\begin{itemize} \begin{itemize}
\item bei Microservices wird ähnlich wie bei Scrum ein cross-functional Ansatz verfolgt \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 \item ein Team ist somit für das gesamte Service, welches nur eine gesamte Funktionalität abdeckt, verantwortlich
\end{itemize} \end{itemize}
\subsection{Erkläre das Konzept "smart endpoints and dump pipes"} \section{Erkläre das Konzept "smart endpoints and dump pipes"}
\begin{itemize} \begin{itemize}
\item wird anstatt eines ESB, welcher oft smarte Mechanismen für Routing und Transforming anbietet, verwendet \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 Smart Endpoints sind z.B. RabbitMQ oder REST
@ -229,7 +229,7 @@
\item Microservices agieren wie Filter bei Unix und wenden ihre Logik auf Anfragen an bevor die Antwort erzeugt wird \item Microservices agieren wie Filter bei Unix und wenden ihre Logik auf Anfragen an bevor die Antwort erzeugt wird
\end{itemize} \end{itemize}
\subsection{Was sind die Herausforderungen von dezentralisiertem Datenmanagement?} \section{Was sind die Herausforderungen von dezentralisiertem Datenmanagement?}
\begin{itemize} \begin{itemize}
\item Monolitische Applikationen bevorzugen eine Datenbank für alle Daten des Systems \item Monolitische Applikationen bevorzugen eine Datenbank für alle Daten des Systems
\item dies Ansatz wird oft auch von Unternehmen bevorzugt \item dies Ansatz wird oft auch von Unternehmen bevorzugt
@ -238,15 +238,15 @@
\item Herausforderung: Aufsplittung der Datenbank beim Wechsel von Monolith zu Microservice Ansatz \item Herausforderung: Aufsplittung der Datenbank beim Wechsel von Monolith zu Microservice Ansatz
\end{itemize} \end{itemize}
\subsection{Beschreibe die wichtigsten Design-Überlegungen im Zusammenhang mit Mircroservices ("Design for Failure", "Evulutionary Design")} \section{Beschreibe die wichtigsten Design-Überlegungen im Zusammenhang mit Mircroservices ("Design for Failure", "Evulutionary Design")}
\subsubsection{Design for failure} \subsection{Design for failure}
\begin{itemize} \begin{itemize}
\item bei Microservices nimmt Fehlerpotential durch Interprozesskommunikation massiv zu \item bei Microservices nimmt Fehlerpotential durch Interprozesskommunikation massiv zu
\item jeder Aufruf kann bei Nichtverfügbarkeit des Services fehlschlagen \item jeder Aufruf kann bei Nichtverfügbarkeit des Services fehlschlagen
\item Software muss daher Fehlertolerant konzipiert sein \item Software muss daher Fehlertolerant konzipiert sein
\item es gibt diverse Monitoring-Tools um Fehler und Probleme zur Laufzeit zu erkennen \item es gibt diverse Monitoring-Tools um Fehler und Probleme zur Laufzeit zu erkennen
\end{itemize} \end{itemize}
\subsubsection{Evolutionary Design} \subsection{Evolutionary Design}
\begin{itemize} \begin{itemize}
\item das Setzen der Grenzen der Micro-Service Komponenten nach einer Aufteilung ist herausfordernd \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 Änderungen sollen nach Aufteilung nur das entsprechende Modul betreffen
@ -261,14 +261,14 @@
\end{itemize} \end{itemize}
\end{itemize} \end{itemize}
\section{Von Objekten zum Service} \section{Von Objekten zum Service}
\subsection{Beschreibe die Nachteile von klassischen verteilten Objektarchitekturen} \section{Beschreibe die Nachteile von klassischen verteilten Objektarchitekturen}
\begin{itemize} \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 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 größere Serverauslastung durch viele Anfragen vom Client, da Objektstatus darüber ausgetauscht wird,
\item Load-Balancing schwieriger zu implementieren und zu verwalten, \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) \item Reservierter Speicher durch den Client muss vom Server automatisch wieder freigegeben werden (z.B. bei Ausfall des Clients)
\end{itemize} \end{itemize}
\subsection{Erkläre die unterschiedlichen Formen der Kopplung} \section{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:: 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} \begin{itemize}
\item Functional Coupling: \item Functional Coupling:
@ -291,7 +291,7 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
\item Durch Vermeidung der Kopplung auf Computing-Plattformen können die Nachteile von Software-Wiederverwendung verringert werden. \item Durch Vermeidung der Kopplung auf Computing-Plattformen können die Nachteile von Software-Wiederverwendung verringert werden.
\end{itemize} \end{itemize}
\section{Web Service API Styles} \section{Web Service API Styles}
\subsubsection{Beschreibe aktuelle Designüberlegungen für Web Service APIs} \subsection{Beschreibe aktuelle Designüberlegungen für Web Service APIs}
\begin{itemize} \begin{itemize}
\item Kapselung: \item Kapselung:
\begin{itemize} \begin{itemize}
@ -329,8 +329,8 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
\item manchmal sind sie jedoch in Binärform umgewandelt zur Verminderung von payload und damit Senkung der benöt. Netzwerkbandbreite \item manchmal sind sie jedoch in Binärform umgewandelt zur Verminderung von payload und damit Senkung der benöt. Netzwerkbandbreite
\end{itemize} \end{itemize}
\end{itemize} \end{itemize}
\subsubsection{RPC API} \subsection{RPC API}
\subsubsection{Erkläre die Funktionalität inkl. Skizze} \subsection{Erkläre die Funktionalität inkl. Skizze}
\begin{itemize} \begin{itemize}
\item Client sendet Nachricht zu Remote-Server und blockiert, während er auf die Response wartet, \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 Die Nachricht in der Anfrage identifiziert den auszuführenden Prozess und beinhaltet Parameter, welche direkt den Parametern der Remote-Prozedur entsprechen,
@ -345,14 +345,14 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
\begin{itemize} \begin{itemize}
\item Message-API \item Message-API
\end{itemize} \end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Nutzung} \subsection{Beschreibe die Konsequenzen der Nutzung}
\begin{itemize} \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 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 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) \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} \end{itemize}
\subsubsection{Message API} \subsection{Message API}
\subsubsection{Erkläre die Funktionalität inkl. Skizze} \subsection{Erkläre die Funktionalität inkl. Skizze}
\begin{itemize} \begin{itemize}
\item Dienste, die Message-APIs verwenden, empfangen ein oder mehrere selbstbeschreibende Nachrichtentypen mithilfe einer gegebenen URL \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 Aufruf einer Message-API oft durch Standardformate wie SOAP oder XML
@ -373,14 +373,14 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/message_api.jpg} \includegraphics[width=0.5\textwidth]{pics/message_api.jpg}
\end{figure} \end{figure}
\subsubsection{Beschreibe die Konsequenzen der Nutzung} \subsection{Beschreibe die Konsequenzen der Nutzung}
\begin{itemize} \begin{itemize}
\item Message-APIs setzen zur Unterstützung clientseitiger Code-Generierung oft Service-Descriptors, wie z.B. WSDL ein, \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 Logik zur Verarbeitung von speziellen Nachrichtentypen wird durch Command-Invoker in Gang gebracht,
\item Vereinfachung durch Trennung der Verarbeitungslogik vom empfangenden Web-Service \item Vereinfachung durch Trennung der Verarbeitungslogik vom empfangenden Web-Service
\end{itemize} \end{itemize}
\subsubsection{Resource API} \subsection{Resource API}
\subsubsection{Erkläre die Funktionalität inkl. Skizze} \subsection{Erkläre die Funktionalität inkl. Skizze}
\begin{itemize} \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 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 Anfragen oft nach dem Prinzip von \textbf{Respresentational State Transfer (REST)}
@ -420,7 +420,7 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/ressource_api.jpg} \includegraphics[width=0.5\textwidth]{pics/ressource_api.jpg}
\end{figure} \end{figure}
\subsubsection{Beschreibe die Konsequenzen der Nutzung} \subsection{Beschreibe die Konsequenzen der Nutzung}
\begin{itemize} \begin{itemize}
\item Resource-APIs sind eine gute Wahl bei großer Anzahl von zugreifenden Clients, \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 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
@ -428,8 +428,8 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
\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. \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} \end{itemize}
\section{Web Service Infrastruktur} \section{Web Service Infrastruktur}
\subsection{Service Connector Pattern} \section{Service Connector Pattern}
\subsubsection{Erkläre die Funktionalität inkl. Skizze} \subsection{Erkläre die Funktionalität inkl. Skizze}
\begin{itemize} \begin{itemize}
\item Service-Connectors vereinfachen die Verwendung von Services durch Verdecken der API-Komplexität, \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: \item viele generische Funktionen werden gekapselt und mit zusätzlicher Logik, die der Service benötigt, erweitert:
@ -449,7 +449,7 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/serv_connector_api.JPG} \includegraphics[width=0.5\textwidth]{pics/serv_connector_api.JPG}
\end{figure} \end{figure}
\subsubsection{Beschreibe die Konsequenzen der Nutzung} \subsection{Beschreibe die Konsequenzen der Nutzung}
\begin{itemize} \begin{itemize}
\item Nutzung eines Connectors als Test-Double in automatisierten Tests, ohne den Web-Service ansprechen zu müssen, \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.: \item generische Logik zur Verwendung durch den Client wird eingesetzt, wie z.B.:
@ -463,8 +463,8 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
\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. \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} \end{itemize}
\subsection{Service Descriptor Pattern} \section{Service Descriptor Pattern}
\subsubsection{Erkläre die Funktionalität inkl. Skizze} \subsection{Erkläre die Funktionalität inkl. Skizze}
\begin{itemize} \begin{itemize}
\item bietet eine \emph{Maschinen lesbare} Auflistung an logischen Operationen oder Ressourcen die eine Organisation bietet \item bietet eine \emph{Maschinen lesbare} Auflistung an logischen Operationen oder Ressourcen die eine Organisation bietet
@ -477,7 +477,7 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
\includegraphics[width=0.5\textwidth]{pics/service_descriptor_contFirst.jpg} \includegraphics[width=0.5\textwidth]{pics/service_descriptor_contFirst.jpg}
\includegraphics[width=0.5\textwidth]{pics/service_descriptor_codeFirst.jpg} \includegraphics[width=0.5\textwidth]{pics/service_descriptor_codeFirst.jpg}
\end{figure} \end{figure}
\subsubsection{Beschreibe die Konsequenzen der Nutzung} \subsection{Beschreibe die Konsequenzen der Nutzung}
\begin{itemize} \begin{itemize}
\item kann als Vertrag zwischen Server und Client angesehen werden wie eine Interaktion auszusehen hat. \item kann als Vertrag zwischen Server und Client angesehen werden wie eine Interaktion auszusehen hat.
@ -506,8 +506,8 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
\end{itemize} \end{itemize}
\subsection{Consumer-Driven Contracts Pattern} \section{Consumer-Driven Contracts Pattern}
\subsubsection{Erkläre die Funktionalität inkl. Skizze} \subsection{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. 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.
@ -528,7 +528,7 @@ Das hilft Serviceentwickler beim vornehmen an Änderungen der API, um deren Ausw
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/customer_driven_contracts.jpg} \includegraphics[width=0.5\textwidth]{pics/customer_driven_contracts.jpg}
\end{figure} \end{figure}
\subsubsection{Beschreibe die Konsequenzen der Nutzung} \subsection{Beschreibe die Konsequenzen der Nutzung}
\begin{itemize} \begin{itemize}
\item Consumer-Driven Contracts werden geschrieben um Integrationstests ausführen zu können. \item Consumer-Driven Contracts werden geschrieben um Integrationstests ausführen zu können.
@ -552,11 +552,11 @@ Das hilft Serviceentwickler beim vornehmen an Änderungen der API, um deren Ausw
\subsection{API Gateway Pattern} \section{API Gateway Pattern}
\subsubsection{Erkläre die Funktionalität inkl. Skizze} \subsection{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)) 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))
@ -581,7 +581,7 @@ Gateway verwendet. Dieser kann für jeden Client eine andere API verfügbar mac
\centering \centering
\includegraphics[width=0.5\textwidth]{pics/api_gateway.jpg} \includegraphics[width=0.5\textwidth]{pics/api_gateway.jpg}
\end{figure} \end{figure}
\subsubsection{Beschreibe die Konsequenzen der Nutzung} \subsection{Beschreibe die Konsequenzen der Nutzung}
\begin{itemize} \begin{itemize}
\item Das Gateway isoliert den Client von den Microservices \item Das Gateway isoliert den Client von den Microservices