review till page 5
This commit is contained in:
parent
db7261af56
commit
1603346644
|
|
@ -1,11 +1,6 @@
|
|||
\part{Layered Architectures}
|
||||
\section{Architektur-Pattern}
|
||||
\subsection{Layers Pattern}
|
||||
\subsubsection{Erkläre die Funktionsweise + Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/esa_layers.jpg}
|
||||
\end{figure}
|
||||
\part{Pattern im Projekt}
|
||||
\section{Layers Pattern}
|
||||
\subsection{Erkläre die Funktionsweise + Skizze}
|
||||
\begin{itemize}
|
||||
\item Client schickt eine Anfrage an Layer N
|
||||
\item Layer N reicht da er nicht vollständig alleine beantworten kann, Anfragen an darunterliegenden Layer weiter
|
||||
|
|
@ -13,9 +8,13 @@
|
|||
\item dies wird immer weiter fortgesetzt bis Layer 1 erreicht ist
|
||||
\item dabei gehen Abhängigkeiten nur von oben nach unten
|
||||
\end{itemize}
|
||||
3 Schichten Architektur:
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/esa_layers.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{3 Schichten Architektur:}
|
||||
\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}
|
||||
\item beinhaltet DAO und DAOImpl >> DocumentDAO, DocumentlibraryDAO
|
||||
\end{itemize}
|
||||
|
|
@ -23,6 +22,7 @@
|
|||
\begin{itemize}
|
||||
\item beinhaltet
|
||||
\begin{itemize}
|
||||
\item \textbf{Service Layer Pattern} (aka Session Fassade - siehe~\ref{sec:slp})
|
||||
\item DTO >> DocumentDTO
|
||||
\item Mapper >> DocumentMapper
|
||||
\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
|
||||
\begin{itemize}
|
||||
\item Controller (ViewHelper) >> DocumentController, DocumentListController
|
||||
\item View (WebApp)
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\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/web-2ndpart.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel}
|
||||
\subsection{Beschreibe ein konkretes Anwendungsbeispiel}
|
||||
\begin{itemize}
|
||||
\item Java Enterprise Edition (JEE) Architektur bestehend aus
|
||||
\begin{itemize}
|
||||
|
|
@ -50,43 +51,43 @@ public static DocumentDTO toDTO(Document document){};
|
|||
\item EIS Tier (Database Server)
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\subsection{Data Access Object (DAO) Pattern}
|
||||
\subsubsection{Erkläre die Funktion + Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/dao_pat1.jpg}
|
||||
\includegraphics[width=0.3\textwidth]{pics/dao_pat2.jpg}
|
||||
\end{figure}
|
||||
\section{Data Access Object (DAO) Pattern}
|
||||
Befindet sich im Projekt in data und damit innerhalb des Data Layer.
|
||||
\subsection{Erkläre die Funktion + Skizze}
|
||||
\begin{itemize}
|
||||
\item Client erstellt ein DAO Object und kann nach Entitäten suchen, einfügen, löschen, etc.
|
||||
\item das DAO selbst soll keine spezifischen Elemente enthalten (Entity Manager, SQL Exception -> stattdessen DAOException)
|
||||
\item dadurch entsteht eine Kapselung bei der die DAOImpl ohne den Client zu verändern ausgetauscht werden kann
|
||||
\end{itemize}
|
||||
\begin{figure}[!h]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{pics/dao_pat1.jpg}
|
||||
\end{figure}
|
||||
\begin{minted}[breaklines=true]{java}
|
||||
@ApplicationScoped
|
||||
public class DocumentDAOImpl implements DocumentDAO, Serializable {
|
||||
@ApplicationScoped
|
||||
public class DocumentDAOImpl implements DocumentDAO, Serializable {
|
||||
private static final long serialVersionUID = 1L;
|
||||
private static final Logger logger = LoggerFactory.getLogger(DocumentDAOImpl.class);
|
||||
@PersistenceContext
|
||||
private EntityManager entityMangaer;
|
||||
|
||||
@Override
|
||||
public List<Document> findByCommunity(Community community) {}
|
||||
public List<Document> findByCommunity(Community community) {...}
|
||||
|
||||
@Override
|
||||
public List<Document> findByUser(User user) {}
|
||||
public List<Document> findByUser(User user) {...}
|
||||
|
||||
@Override
|
||||
public void insert(Document document) {}
|
||||
public void insert(Document document) {...}
|
||||
|
||||
@Override
|
||||
public void delete(Document document) {}
|
||||
public void delete(Document document) {...}
|
||||
|
||||
@Override
|
||||
public Document findById(Long id) {}
|
||||
}
|
||||
public Document findById(Long id) {...}
|
||||
}
|
||||
\end{minted}
|
||||
\subsubsection{Nenne die Konsequenzen der Anwendung}
|
||||
\subsection{Nenne die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item Zugriff auf persistenten Speicher wird abstrahiert
|
||||
\item Details des Speichers werden versteckt
|
||||
|
|
@ -94,8 +95,8 @@ public static DocumentDTO toDTO(Document document){};
|
|||
\item entkoppelt Implementierung von Persistierung (Datenbank,...)
|
||||
\item ermöglicht Objektorientierte Ansicht des Speichers
|
||||
\end{itemize}
|
||||
\subsection{Service Layer Pattern (auch Session Fassade)}
|
||||
\subsubsection{Erkläre die Funktion + Skizze}\label{subsubsec:service-layer-pattern}
|
||||
\section{Service Layer Pattern (auch Session Fassade)}\label{sec:slp}
|
||||
\subsection{Erkläre die Funktion + Skizze}\label{subsubsec:service-layer-pattern}
|
||||
|
||||
\begin{itemize}
|
||||
\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_pat2.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{Nenne die Konsequenzen der Anwendung}
|
||||
\subsection{Nenne die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item Reduzierung der Abhängigkeiten zwischen Presentation und Domain Layer
|
||||
\item Zentralisiertes Sicherheits und Transaktionshandling
|
||||
|
|
@ -294,8 +295,8 @@ public static DocumentDTO toDTO(Document document){};
|
|||
\item gut für Remote Aufrufe geeignet (weniger Aufrufe)
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Model-View-Controller Pattern}
|
||||
\subsubsection{Erkläre die Funktion + Skizze}
|
||||
\section{Model-View-Controller Pattern}
|
||||
\subsection{Erkläre die Funktion + Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/mvc_pat.jpg}
|
||||
|
|
@ -314,7 +315,7 @@ public static DocumentDTO toDTO(Document document){};
|
|||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/webapp-location.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{Nenne die Konsequenzen der Anwendung}
|
||||
\subsection{Nenne die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item Visualisierung abhängig vom Model - nicht umgekehrt
|
||||
\item verschiedene Darstellungen möglich
|
||||
|
|
@ -322,8 +323,8 @@ public static DocumentDTO toDTO(Document document){};
|
|||
\item gute Strukturierung
|
||||
\item View wird leichter austausch bzw. änderbar
|
||||
\end{itemize}
|
||||
\subsection{Front Controller}
|
||||
\subsubsection{Erkläre die Funktion + Skizze}
|
||||
\section{Front Controller}
|
||||
\subsection{Erkläre die Funktion + Skizze}
|
||||
\begin{itemize}
|
||||
\item Client schickt Request an Front Controller
|
||||
\item FC erfasst nur Infos die er für die weiter Delegation braucht
|
||||
|
|
@ -340,25 +341,14 @@ public static DocumentDTO toDTO(Document document){};
|
|||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/fc_pat.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel}
|
||||
\subsection{Beschreibe ein konkretes Anwendungsbeispiel}
|
||||
\begin{itemize}
|
||||
\item Java Server Faces (bei Java Server Faces enthält das File zwar keinen Java Code, interagiert aber direkt mit Java Code einer Backing Bean)
|
||||
\end{itemize}
|
||||
\begin{minted}[linenos,breaklines=true]{xml}
|
||||
<?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">
|
||||
<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-name>Faces Servlet</servlet-name>
|
||||
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
|
||||
|
|
@ -457,7 +447,7 @@ public static DocumentDTO toDTO(Document document){};
|
|||
</web-app>
|
||||
\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
|
||||
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
|
||||
|
|
@ -514,14 +504,14 @@ mode="advanced" label="Add document (.pdf .jpg .docx)">
|
|||
</ui:composition>
|
||||
\end{minted}
|
||||
|
||||
\subsubsection{Nenne die Konsequenzen der Anwendung}
|
||||
\subsection{Nenne die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item es muss nur EIN (Front) Controller konfiguriert werden
|
||||
\item da bei jedem Request ein neues Command Objekt erzeugt wird ist Thread-Safety nicht notwendig
|
||||
\item da nur EIN Controller sind auch Erweiterungen durch z.B.: Decorator einfach (auch zur Laufzeit)
|
||||
\end{itemize}
|
||||
\subsection{View Helper}
|
||||
\subsubsection{Erkläre die Funktion + Skizze}
|
||||
\section{View Helper}
|
||||
\subsection{Erkläre die Funktion + Skizze}
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\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 in View befindet sich HTML Code im ViewHelper Java Code zur Aufbereitung der Daten (+ wenig HTML)
|
||||
\end{itemize}
|
||||
\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel}
|
||||
\subsection{Beschreibe ein konkretes Anwendungsbeispiel}
|
||||
\begin{itemize}
|
||||
\item bei Verwendung von JSP (Java Server Pages enthalten neben HTML auch Java Code)
|
||||
\end{itemize}
|
||||
\subsubsection{Nenne die Konsequenzen der Anwendung}
|
||||
\subsection{Nenne die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item kapselt Design-Code in View und View-Processing-Code Logik in Helper
|
||||
\item steigert Wiederverwendbarkeit, Wartbarkeit und Strukturierungsqualität der Anwendung
|
||||
|
|
@ -547,8 +537,8 @@ mode="advanced" label="Add document (.pdf .jpg .docx)">
|
|||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Dependency Injection (don't call us, we'll call you)}
|
||||
\subsubsection{Erkläre die Funktion + Skizze}
|
||||
\section{Dependency Injection (don't call us, we'll call you)}
|
||||
\subsection{Erkläre die Funktion + Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\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 erspart Factories
|
||||
\end{itemize}
|
||||
\subsubsection{Nenne die Konsequenzen der Anwendung}
|
||||
\subsection{Nenne die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item loose gekoppelte Objekte
|
||||
\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
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\subsection{Data Transfer Object (DTO) Pattern}
|
||||
\subsubsection{Erkläre die Funktion (Skizze - ein Grund für DTO)}
|
||||
\section{Data Transfer Object (DTO) Pattern}
|
||||
\subsection{Erkläre die Funktion (Skizze - ein Grund für DTO)}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\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 ev. Map, Record Set, ...
|
||||
\end{itemize}
|
||||
\subsubsection{Beschreibe ein konkretes Anwendungsbeispiel}
|
||||
\subsection{Beschreibe ein konkretes Anwendungsbeispiel}
|
||||
% todo: Anwendungsbeispiel
|
||||
\subsubsection{Nenne die Konsequenzen der Anwendung}
|
||||
\subsection{Nenne die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item kapselt und versteckt
|
||||
\item nimmt Komplexität
|
||||
\item steigert Effizienz da weniger Aufrufe über Remotegrenze
|
||||
\end{itemize}
|
||||
\subsection{Page-Object-Pattern}
|
||||
\section{Page-Object-Pattern}
|
||||
PageObjectPattern
|
||||
|
||||
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)
|
||||
\section{Remote}
|
||||
\subsection{Beschreibe die Unterschiede zwischen lokalem und Remote Interface Design}
|
||||
\section{Beschreibe die Unterschiede zwischen lokalem und Remote Interface Design}
|
||||
\begin{itemize}
|
||||
\item Aufrufe innerhalb des Prozesses sind schneller als über Prozessgrenzen
|
||||
\item lokale Interfaces sind möglichst fein-granular während Remote Interfaces grob-granular sein müssen (weniger Aufrufe - Effizienz)
|
||||
\item viele kleine Aufrufe mit wenigen Daten sind "teuer" (Latenz durch Verbindungsherstellung)
|
||||
\end{itemize}
|
||||
\subsection{Beschreibe drei Situationen wo Multiple Prozesse in Applikationen verwendet werden müssen}
|
||||
\section{Beschreibe drei Situationen wo Multiple Prozesse in Applikationen verwendet werden müssen}
|
||||
\begin{itemize}
|
||||
\item Trennung zwischen Clients und Servern in Business Software
|
||||
\item Trennung zwischen server-basierter Applikationssoftware und Datenbank (SQL ist als Remote Interface designed, daher sind hier schnelle Abfragen möglich)
|
||||
\item Trennung wegen unterschiedlichen Anbietern oder Programmiersprachen
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Beschreibe das folgende Diagramm. Was können wir daraus für das Design von Remote Interfaces folgern?}
|
||||
\section{Beschreibe das folgende Diagramm. Was können wir daraus für das Design von Remote Interfaces folgern?}
|
||||
\begin{itemize}
|
||||
\item speziell bei "teuren" Remote Calls ist es empfehlenswert weniger Calls mit großen Datenmengen anstatt vielen Calls mit wenigen Daten zu machen
|
||||
\item dieser Gedanke befürwortet auch den Einsatz von DTO um Calls und Daten zu bündeln
|
||||
|
|
@ -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}
|
||||
\end{figure}
|
||||
\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}
|
||||
\item Checked Exceptions (z.B. SQL-Exception) leiten von Exception Klasse ab und müssen behandelt werden (trows - catch)
|
||||
\begin{itemize}
|
||||
|
|
@ -667,16 +657,16 @@ Bei HTML-Änderung muss ich nur Page-Objekt ändern und ansonsten nichts angreif
|
|||
\centering
|
||||
\includegraphics[width=0.3\textwidth]{pics/except_class_dia.jpg}
|
||||
\end{figure}
|
||||
\subsection{Beschreibe einen Use Case für eine Checked Exceptions in Java}
|
||||
\section{Beschreibe einen Use Case für eine Checked Exceptions in Java}
|
||||
\begin{itemize}
|
||||
\item eine Netzwerkübertragung schlägt fehl - es ist vorgesehen, dass der Applikations-User dies neu anstoßen kann
|
||||
\end{itemize}
|
||||
\subsection{Beschreibe einen Use Case für eine Runtime Exceptions in Java}
|
||||
\section{Beschreibe einen Use Case für eine Runtime Exceptions in Java}
|
||||
\begin{itemize}
|
||||
\item Die Datenbank ist beschädigt - die Exception geht durch alle Layer erst mit
|
||||
Implementierungsspezifischer Exception später mit Runtime ohne Stacktrace (Sicherheit) bis zum User.
|
||||
\end{itemize}
|
||||
\subsection{Beschreibe 5 Best Practice Beispiele beim Einsatz von Exceptions}
|
||||
\section{Beschreibe 5 Best Practice Beispiele beim Einsatz von Exceptions}
|
||||
\begin{itemize}
|
||||
\item Exceptions nicht für Programmflusskontrolle verwenden (schlechte Performance)
|
||||
\item offene Ressourcen schließen (try-with-resources bzw. close im finally)
|
||||
|
|
@ -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
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Beschreibe 5 Exception Handling Anti Pattern}
|
||||
\section{Beschreibe 5 Exception Handling Anti Pattern}
|
||||
\begin{itemize}
|
||||
\item Log and Trow (nie beides: entweder, oder)
|
||||
\item Trowing Exception bzw. catch Exception (spezifischere anstatt Basisklasse verwenden)
|
||||
|
|
@ -695,15 +685,15 @@ Bei HTML-Änderung muss ich nur Page-Objekt ändern und ansonsten nichts angreif
|
|||
\item Unsupported Operation return Null (besser UnsupportedOperationException)
|
||||
\end{itemize}
|
||||
\section{Logging}
|
||||
\subsection{Nenne die Nachteile von debugging mit printf() sowie die Vorteile die Logging Frameworks wie log4j bieten}
|
||||
\subsubsection{Nachteile printf()}
|
||||
\section{Nenne die Nachteile von debugging mit printf() sowie die Vorteile die Logging Frameworks wie log4j bieten}
|
||||
\subsection{Nachteile printf()}
|
||||
\begin{itemize}
|
||||
\item Produktiv-Code wird überfüllt -> erschwert Lesbarkeit
|
||||
\item Consolenausgabe wird bei vielen prints auch schnell unübersichtlich
|
||||
\item im Falle eines vorzeitigen Absturzes können Ausgabedaten verloren gehen
|
||||
\item Performance bei vielen Logprints
|
||||
\end{itemize}
|
||||
\subsubsection{Vorteile Logging mittels Framework (z.B.: log4j)}
|
||||
\subsection{Vorteile Logging mittels Framework (z.B.: log4j)}
|
||||
\begin{itemize}
|
||||
\item Nutzt ein einheitliches Format / Konventionen
|
||||
\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}
|
||||
\end{figure}
|
||||
\section{Toni}
|
||||
\subsection{Annotationen}
|
||||
\subsubsection{@MappedSuperclass}
|
||||
\section{Annotationen}
|
||||
\subsection{@MappedSuperclass}
|
||||
\begin{itemize}
|
||||
\item ist im Hybernate Framework eine Klasse durch die gemeinsame Felder definiert werden.
|
||||
\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.
|
||||
@Remote – interprozessaufrufe. RMI
|
||||
@ApplicationException – Rollback wenn so eine Exception kommt, Nachricht zum Client.
|
||||
\subsection{Patterns in Practice}
|
||||
\section{Patterns in Practice}
|
||||
Data Access Layer
|
||||
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.
|
||||
|
|
@ -755,7 +745,7 @@ Mapper – von DTO in Entity und Entity ins DTO.
|
|||
|
||||
FrontController web.xml
|
||||
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
|
||||
Wildfly – server
|
||||
Primeafce = jsf Framework
|
||||
|
|
@ -763,7 +753,7 @@ Jacoco = test Coverage
|
|||
Slf4j = logger
|
||||
Jaxb – xml
|
||||
Cdi = context dependancy injection
|
||||
\subsection{Reihenfolge - Wildfly - Abfolge - einzelne Schritte}
|
||||
\section{Reihenfolge - Wildfly - Abfolge - einzelne Schritte}
|
||||
Reihenfolge:
|
||||
\begin{multicols}{2}
|
||||
\begin{enumerate}
|
||||
|
|
@ -777,7 +767,7 @@ Reihenfolge:
|
|||
\end{enumerate}
|
||||
\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
|
||||
|
||||
DocumentDAO – DocumentService – DocumentController – so sollte Exception-Handling implementiert warden
|
||||
|
|
|
|||
|
|
@ -6,14 +6,14 @@
|
|||
\item wird von Dritten zusammen mit anderen Components verwendet
|
||||
\end{itemize}
|
||||
\section{Infrastruktur Pattern}
|
||||
\subsection{Component Pattern}
|
||||
\subsubsection{Beschreibe die Problemstellung}
|
||||
\section{Component Pattern}
|
||||
\subsection{Beschreibe die Problemstellung}
|
||||
\begin{itemize}
|
||||
\item großer Broken Funktionalität vom technischen Teil getrennt ist besser als Vermischung
|
||||
\item Änderungen an kleinem Teil können Auswirkungen auf das ganze System haben
|
||||
\item unabhängige Deployments bzw. Updates der Teile ist unmöglich -> soll aber möglich werden
|
||||
\end{itemize}
|
||||
\subsubsection{Erkläre die Lösung inkl. Skizze}
|
||||
\subsection{Erkläre die Lösung inkl. Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\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 durch Zusammenfügen der Funktionalitäten loser Komponenten wird die Anwendung realisiert
|
||||
\end{itemize}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\subsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item eine Komponente sollte sich gut an andere anpassen, jedoch nur lose an diese gekoppelt sein
|
||||
\item Comp-Interface ist von Comp-Impl getrennt
|
||||
\item Funktionalitätsänderung, erfordert nur Änderung innerhalb entsprechenden Komponente
|
||||
\end{itemize}
|
||||
\subsection{Container Pattern}
|
||||
\subsubsection{Beschreibe die Problemstellung}
|
||||
\section{Container Pattern}
|
||||
\subsection{Beschreibe die Problemstellung}
|
||||
\begin{itemize}
|
||||
\item Components enthalten reine Business Logik (keine technischen Aspekte)
|
||||
\item es wird etwas zur Behandlung der technischen Aspekte und Integration benötigt...
|
||||
\item Lösung soll wiederverwendet werden können
|
||||
\end{itemize}
|
||||
\subsubsection{Erkläre die Lösung inkl. Skizze}
|
||||
\subsection{Erkläre die Lösung inkl. Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\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)
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\subsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item zur Integration spezifizieren Annotations technische Anforderungen der Components (getrennt von Implementierung)
|
||||
\item Glue-Code-Layer (generischer Containerteil) wird zur Anpassung /Füllung erstellt
|
||||
\item für unterschiedliche Component Typen gibt es verschiedene Container
|
||||
\end{itemize}
|
||||
\subsection{Service Component Pattern}
|
||||
\subsubsection{Beschreibe die Problemstellung}
|
||||
\section{Service Component Pattern}
|
||||
\subsection{Beschreibe die Problemstellung}
|
||||
\begin{itemize}
|
||||
\item es werden "Service Provider" benötigt, dies sind Komponenten die andere Komponenten der externe Systeme verändern
|
||||
\item dienen als Fassade für Subsystem, welches aus weiteren Komponenten besteht
|
||||
\end{itemize}
|
||||
\subsubsection{Erkläre die Lösung inkl. Skizze}
|
||||
\subsection{Erkläre die Lösung inkl. Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/service_compontent_pat.jpg}
|
||||
|
|
@ -70,7 +70,7 @@
|
|||
\item so kann Container Components effizient verwalten
|
||||
\item jede Operation muss abgeschlossen sein
|
||||
\end{itemize}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\subsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item dient als Fassade für komplexe Systeme
|
||||
\item vereinfacht Zugriff auf diese Systeme
|
||||
|
|
@ -79,15 +79,15 @@
|
|||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Session Component Pattern}
|
||||
\subsubsection{Beschreibe die Problemstellung}
|
||||
\section{Session Component Pattern}
|
||||
\subsection{Beschreibe die Problemstellung}
|
||||
\begin{itemize}
|
||||
\item Service Component reicht nicht aus
|
||||
\item es soll auch ein Client oder Session-Status gespeichert werden
|
||||
\item Status ist nicht persistent und wird durch Garbage-Collection wieder entfernt
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Erkläre die Lösung inkl. Skizze}
|
||||
\subsection{Erkläre die Lösung inkl. Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/session_component_pat.jpg}
|
||||
|
|
@ -97,7 +97,7 @@
|
|||
\item Overhead gering da es keine Nebenläufigkeit gibt
|
||||
\item Ressourcenverbrauch wird auch vom Container niedrig gehalten
|
||||
\end{itemize}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\subsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item nur ein Client pro Komponente erlaubt
|
||||
\item Server kann Speicher ausgehen (\#Session-Components = \#Clients)
|
||||
|
|
@ -105,12 +105,12 @@
|
|||
\end{itemize}
|
||||
|
||||
\section{Implementierungs Pattern}
|
||||
\subsection{Virtual Instance Pattern}
|
||||
\subsubsection{Beschreibe die Problemstellung}
|
||||
\section{Virtual Instance Pattern}
|
||||
\subsection{Beschreibe die Problemstellung}
|
||||
\begin{itemize}
|
||||
\item viele Komponenten-Instanzen können zu Ressourcenknappheit (Speicher, Container, Systemressourcen) führen
|
||||
\end{itemize}
|
||||
\subsubsection{Erkläre die Lösung inkl. Skizze}
|
||||
\subsection{Erkläre die Lösung inkl. Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\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)
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\subsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item Anzahl realer Instanzen im Speicher meist wesentlich geringer als virtueller
|
||||
\item somit ist Aufwand und Speicherbedarf des Containers geringer
|
||||
\end{itemize}
|
||||
\subsection{Instance Pooling Pattern}
|
||||
\subsubsection{Beschreibe die Problemstellung}
|
||||
\section{Instance Pooling Pattern}
|
||||
\subsection{Beschreibe die Problemstellung}
|
||||
\begin{itemize}
|
||||
\item Komponenteninstanzen erstellen und entfernen ist "teuer" (Overhead)
|
||||
\end{itemize}
|
||||
\subsubsection{Erkläre die Lösung inkl. Skizze}
|
||||
\subsection{Erkläre die Lösung inkl. Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/instance_pooling_pat.jpg}
|
||||
|
|
@ -146,7 +146,7 @@
|
|||
\item nach Nutzung kommt diese wieder in den Pool
|
||||
\item Zustandsänderungen werden durch Lifecycle Callbacks kontrolliert
|
||||
\end{itemize}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\subsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item bei Container Instance Pooling, zwei Status:
|
||||
\begin{itemize}
|
||||
|
|
@ -159,15 +159,15 @@
|
|||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Passivation Pattern}
|
||||
\subsubsection{Beschreibe die Problemstellung}
|
||||
\section{Passivation Pattern}
|
||||
\subsection{Beschreibe die Problemstellung}
|
||||
\begin{itemize}
|
||||
\item Session Components haben Status ohne Repräsentation im Speicher
|
||||
\item es gibt Zeiträume der Inaktivität
|
||||
\item es sollen Ressourcen gespart werden
|
||||
\item z.B. Einkaufswagen eines Online Shops
|
||||
\end{itemize}
|
||||
\subsubsection{Erkläre die Lösung inkl. Skizze}
|
||||
\subsection{Erkläre die Lösung inkl. Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/passivation_pat.jpg}
|
||||
|
|
@ -177,7 +177,7 @@
|
|||
\item Zustand wird persistent gespeichert und aus Hauptspeicher gelöscht
|
||||
\item wird Instanz benötigt wird diese von Festplatte in Hauptspeicher geladen
|
||||
\end{itemize}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\subsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item Instanzen werden wirklich aus Speicher entfernt
|
||||
\item bei neuerlicher Herstellung müssen auch Verbindungen zu anderen Ressourcen neu geladen werden
|
||||
|
|
@ -185,8 +185,8 @@
|
|||
\item bedeutet deutlichen Overhead und sollte vermieden werden (besser mehr Speicher)
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Component Proxy Pattern}
|
||||
\subsubsection{Beschreibe die Problemstellung}
|
||||
\section{Component Proxy Pattern}
|
||||
\subsection{Beschreibe die Problemstellung}
|
||||
\begin{itemize}
|
||||
\item Clients müssen auf virtuelle Komponenteninstanzen referenzieren
|
||||
\item Container muss bei Client Aufruf für virtuelle, physikalische Instanz bereitstellen
|
||||
|
|
@ -194,7 +194,7 @@
|
|||
\end{itemize}
|
||||
|
||||
|
||||
\subsubsection{Erkläre die Lösung inkl. Skizze}
|
||||
\subsection{Erkläre die Lösung inkl. Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/component_proxy_pat.jpg}
|
||||
|
|
@ -206,7 +206,7 @@
|
|||
\item zur Performancesteigerung bedient ein Proxy mehrere virtuelle Komponenteninstanzen
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\subsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item dem Client wird durch den Proxy etwas gegeben, das ohne echte Komponenteninstanz aufgerufen werden kann
|
||||
\item Client Methodenaufrufe enthalten ID der logischen Komponenteninstanz zur korrekten Weiterleitung
|
||||
|
|
@ -215,14 +215,14 @@
|
|||
\end{itemize}
|
||||
|
||||
|
||||
\subsection{Glue-Code Pattern}
|
||||
\subsubsection{Beschreibe die Problemstellung}
|
||||
\section{Glue-Code Pattern}
|
||||
\subsection{Beschreibe die Problemstellung}
|
||||
\begin{itemize}
|
||||
\item Container soll wiederverwendet werden, dazu muss Funktionalität generisch sein
|
||||
\item Komponenten besitzen spezielle Schnittstelle und Annotationen welche spezielle Config für technische Anforderungen enthalten
|
||||
\item völlig generische Container können keine unterschiedlichen Komponenten beherbergen
|
||||
\end{itemize}
|
||||
\subsubsection{Erkläre die Lösung inkl. Skizze}
|
||||
\subsection{Erkläre die Lösung inkl. Skizze}
|
||||
\begin{figure}[!htp]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/glue_code_pat.jpg}
|
||||
|
|
@ -233,7 +233,7 @@
|
|||
\item Compontent-Proxy ist Teil dieser Schicht
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\subsection{Beschreibe die Konsequenzen der Anwendung}
|
||||
\begin{itemize}
|
||||
\item in Java mit Reflection umsetzbar (ermöglicht dynamischen Operationsaufruf)
|
||||
\item Reflection viel langsamer als spezifischer generierter Code
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
\part{Service-Oriented Architecture (SOA)}
|
||||
\section{SOA}
|
||||
\subsection{Auf welche drei technischen Konzepte basiert SOA?}
|
||||
\section{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
|
||||
|
|
@ -13,7 +13,7 @@
|
|||
\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}
|
||||
\section{Beschreibe die Eigenschaften von großen Verteilten Systemen}
|
||||
\begin{itemize}
|
||||
\item Heterogen -> unterschiedliche
|
||||
\begin{itemize}
|
||||
|
|
@ -24,7 +24,7 @@
|
|||
\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}
|
||||
\section{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:
|
||||
|
|
@ -34,7 +34,7 @@
|
|||
\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}
|
||||
\section{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
|
||||
|
|
@ -45,14 +45,14 @@
|
|||
\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}
|
||||
\section{Beschreibe drei unterschiedliche Service Kategorien}
|
||||
\subsection{Basic Services}
|
||||
\begin{itemize}
|
||||
\item grundlegende, an vielen Stellen gebrauchte Business-Funktionalität
|
||||
\item meist kurze Laufzeit
|
||||
\item stateless
|
||||
\end{itemize}
|
||||
\subsubsection{Composed Services}
|
||||
\subsection{Composed Services}
|
||||
\begin{itemize}
|
||||
\item aus Basic Services zusammengesetzt („Orchestration“)
|
||||
\item auf höherer Ebene als Basic Services angesiedelt
|
||||
|
|
@ -60,7 +60,7 @@
|
|||
\item kurze Laufzeit
|
||||
\item oft Adapter Services um anderen Services eine Schnittstelle zu bieten
|
||||
\end{itemize}
|
||||
\subsubsection{Process Services}
|
||||
\subsection{Process Services}
|
||||
\begin{itemize}
|
||||
\item Längerfristige Prozesse, die Geschäftsprozesse umsetzen
|
||||
\item Interagieren mit Benutzer oder anderen Systemen
|
||||
|
|
@ -68,7 +68,7 @@
|
|||
\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}
|
||||
\section{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
|
||||
|
|
@ -78,16 +78,16 @@
|
|||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/topDown-bottomUp.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{Top Down}
|
||||
\subsection{Top Down}
|
||||
|
||||
\begin{itemize}
|
||||
\item Prozess auf kleiner Prozesse herunterbrechen, bis Ebene von Basic Services erreicht ist
|
||||
\end{itemize}
|
||||
\subsubsection{Bottom Up}
|
||||
\subsection{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}
|
||||
\section{Beschreibe das Konzept des Enterprise Service Bus inkl. Skizze}
|
||||
|
||||
\begin{itemize}
|
||||
\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_3.jpg}
|
||||
\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}
|
||||
\item Unterschied: Kopplung der Consumer an physikalische Verbindung (P2P enger)
|
||||
\end{itemize}
|
||||
\subsubsection{Point-to-Point}
|
||||
\subsection{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}
|
||||
\subsection{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}
|
||||
\section{Beschreibe das Konzept der loosen Kopplung und die beiden wichtigsten damit verbundenen Themen}
|
||||
\subsection{Konzept}
|
||||
\begin{itemize}
|
||||
\item bezeichnet einen geringen Grad der Abhängigkeit zwischen Hard- oder Software-Komponenten
|
||||
\item ermöglicht
|
||||
|
|
@ -140,7 +140,7 @@
|
|||
\end{itemize}
|
||||
\end{multicols}
|
||||
\end{itemize}
|
||||
\subsubsection{damit verbundene Konzepte}
|
||||
\subsection{damit verbundene Konzepte}
|
||||
\begin{itemize}
|
||||
\item Asynchrone Kommunikation
|
||||
\begin{itemize}
|
||||
|
|
@ -156,8 +156,8 @@
|
|||
\end{itemize}
|
||||
\section{Microservice Architekturen}
|
||||
|
||||
\subsection{Beschreibe die wesentlichsten Unterschiede zwischen einer monolithischen Anwendung und dem Mikroservices Ansatz}
|
||||
\subsubsection{Monolithisch}
|
||||
\section{Beschreibe die wesentlichsten Unterschiede zwischen einer monolithischen Anwendung und dem Mikroservices Ansatz}
|
||||
\subsection{Monolithisch}
|
||||
\begin{itemize}
|
||||
\item Enterprise Applications bestehen oft aus drei Teilen
|
||||
\begin{itemize}
|
||||
|
|
@ -167,7 +167,7 @@
|
|||
\end{itemize}
|
||||
\item da die Applikation \textbf{eine} Einheit ist, muss sie bei Änderungen neu gebuilded und deployed werden
|
||||
\end{itemize}
|
||||
\subsubsection{Microservices}
|
||||
\subsection{Microservices}
|
||||
\begin{itemize}
|
||||
\item sind gut skalierbar
|
||||
\item Applikation besteht aus vielen kleinen Services
|
||||
|
|
@ -176,26 +176,26 @@
|
|||
\item Services können unabhängig voneinander deployed werden
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Vergleiche die Unterschiedlichen Skalierungstrategien von monolitischen Applikationen und Mikroservices}
|
||||
\subsubsection{Monolithisch}
|
||||
\section{Vergleiche die Unterschiedlichen Skalierungstrategien von monolitischen Applikationen und Mikroservices}
|
||||
\subsection{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}
|
||||
\subsection{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}
|
||||
\section{Erkläre den Unterschied zwischen Libraries und Services}
|
||||
\subsection{Library}
|
||||
\begin{itemize}
|
||||
\item Komponenten, die in eine Applikation verlinkt werden und lokal (im selben Prozess) verwendet werden
|
||||
\end{itemize}
|
||||
\subsubsection{Services}
|
||||
\subsection{Services}
|
||||
\begin{itemize}
|
||||
\item besitzen immer eine Remote Schnittstelle
|
||||
\item befinden sich in eigenem Prozess (stärker entkoppelt)
|
||||
|
|
@ -208,20 +208,20 @@
|
|||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Beschreibe die Beziehung zwischen einer Team Struktur und dem Design einer Software}
|
||||
\subsubsection{Silo-Ansatz}
|
||||
\section{Beschreibe die Beziehung zwischen einer Team Struktur und dem Design einer Software}
|
||||
\subsection{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}
|
||||
\subsection{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"}
|
||||
\section{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
|
||||
|
|
@ -229,7 +229,7 @@
|
|||
\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?}
|
||||
\section{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
|
||||
|
|
@ -238,15 +238,15 @@
|
|||
\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}
|
||||
\section{Beschreibe die wichtigsten Design-Überlegungen im Zusammenhang mit Mircroservices ("Design for Failure", "Evulutionary Design")}
|
||||
\subsection{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}
|
||||
\subsection{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
|
||||
|
|
@ -261,14 +261,14 @@
|
|||
\end{itemize}
|
||||
\end{itemize}
|
||||
\section{Von Objekten zum Service}
|
||||
\subsection{Beschreibe die Nachteile von klassischen verteilten Objektarchitekturen}
|
||||
\section{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}
|
||||
\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::
|
||||
\begin{itemize}
|
||||
\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.
|
||||
\end{itemize}
|
||||
\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}
|
||||
\item Kapselung:
|
||||
\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
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\subsubsection{RPC API}
|
||||
\subsubsection{Erkläre die Funktionalität inkl. Skizze}
|
||||
\subsection{RPC API}
|
||||
\subsection{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,
|
||||
|
|
@ -345,14 +345,14 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
|
|||
\begin{itemize}
|
||||
\item Message-API
|
||||
\end{itemize}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Nutzung}
|
||||
\subsection{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}
|
||||
\subsection{Message API}
|
||||
\subsection{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
|
||||
|
|
@ -373,14 +373,14 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
|
|||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/message_api.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Nutzung}
|
||||
\subsection{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}
|
||||
\subsection{Resource API}
|
||||
\subsection{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)}
|
||||
|
|
@ -420,7 +420,7 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
|
|||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/ressource_api.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Nutzung}
|
||||
\subsection{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
|
||||
|
|
@ -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.
|
||||
\end{itemize}
|
||||
\section{Web Service Infrastruktur}
|
||||
\subsection{Service Connector Pattern}
|
||||
\subsubsection{Erkläre die Funktionalität inkl. Skizze}
|
||||
\section{Service Connector Pattern}
|
||||
\subsection{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:
|
||||
|
|
@ -449,7 +449,7 @@ Kopplung beschreibt den Grat der Abhängigkeiten eines Moduls von einem anderen
|
|||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/serv_connector_api.JPG}
|
||||
\end{figure}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Nutzung}
|
||||
\subsection{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.:
|
||||
|
|
@ -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.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Service Descriptor Pattern}
|
||||
\subsubsection{Erkläre die Funktionalität inkl. Skizze}
|
||||
\section{Service Descriptor Pattern}
|
||||
\subsection{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
|
||||
|
|
@ -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_codeFirst.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Nutzung}
|
||||
\subsection{Beschreibe die Konsequenzen der Nutzung}
|
||||
|
||||
\begin{itemize}
|
||||
\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}
|
||||
|
||||
|
||||
\subsection{Consumer-Driven Contracts Pattern}
|
||||
\subsubsection{Erkläre die Funktionalität inkl. Skizze}
|
||||
\section{Consumer-Driven Contracts Pattern}
|
||||
\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.
|
||||
|
||||
|
|
@ -528,7 +528,7 @@ Das hilft Serviceentwickler beim vornehmen an Änderungen der API, um deren Ausw
|
|||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/customer_driven_contracts.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Nutzung}
|
||||
\subsection{Beschreibe die Konsequenzen der Nutzung}
|
||||
|
||||
\begin{itemize}
|
||||
\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))
|
||||
|
||||
|
|
@ -581,7 +581,7 @@ Gateway verwendet. Dieser kann für jeden Client eine andere API verfügbar mac
|
|||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{pics/api_gateway.jpg}
|
||||
\end{figure}
|
||||
\subsubsection{Beschreibe die Konsequenzen der Nutzung}
|
||||
\subsection{Beschreibe die Konsequenzen der Nutzung}
|
||||
|
||||
\begin{itemize}
|
||||
\item Das Gateway isoliert den Client von den Microservices
|
||||
|
|
|
|||
Loading…
Reference in New Issue