PSE_learning/parts/02_comp-based_arc.tex

\part{Component Based Architectures}
\section{Erkläre den Begriff Software Komponente wie von Clemens Szypersky definiert}
\begin{itemize}
    \item ist eine Einheit aus spezifizierten Interfaces mit expliziten Context-Abhängigkeiten
    \item kann solange Abhängigkeiten erfüllt, unabhängig deployed werden
    \item wird von Dritten zusammen mit anderen Components verwendet
\end{itemize}
\section{Infrastruktur Pattern}
\subsection{Component Pattern}
\subsubsection{Beschreibe die Problemstellung}
\begin{itemize}
    \item großer Broken Funktionalität vom technischen Teil getrennt ist besser als Vermischung
    \item Änderungen an kleinem Teil können Auswirkungen auf das ganze System haben
    \item unabhängige Deployments bzw. Updates der Teile ist unmöglich -> soll aber möglich werden
\end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp]
    \centering
    \includegraphics[width=0.5\textwidth]{pics/component_pat.jpg}
\end{figure}
\begin{itemize}
    \item Funktionalität der Anwendung wird in mehrere Teilkomponenten zerlegt
    \item jede Komponente soll ihre Verantwortlichkeiten ohne starke Abhängigkeiten \textbf{vollständig} implementieren
    \item durch Zusammenfügen der Funktionalitäten loser Komponenten wird die Anwendung realisiert
\end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize}
    \item eine Komponente sollte sich gut an andere anpassen, jedoch nur lose an diese gekoppelt sein
    \item Comp-Interface ist von Comp-Impl getrennt
    \item Funktionalitätsänderung, erfordert nur Änderung innerhalb entsprechenden Komponente
\end{itemize}
\subsection{Container Pattern}
\subsubsection{Beschreibe die Problemstellung}
\begin{itemize}
    \item Components enthalten reine Business Logik (keine technischen Aspekte)
    \item es wird etwas zur Behandlung der technischen Aspekte und Integration benötigt...
    \item Lösung soll wiederverwendet werden können
\end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp]
    \centering
    \includegraphics[width=0.5\textwidth]{pics/container_pat.jpg}
\end{figure}
\begin{itemize}
    \item Container ist Ausführungsumgebung für technische Aspekte der Components
    \item umhüllt Components und erweckt Anschein einer fixen Integration
    \item um Wiederverwendung zu fördern werden Frameworks verwendet (z.B.: Code Generation)
\end{itemize}

\subsubsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize}
    \item zur Integration spezifizieren Annotations technische Anforderungen der Components (getrennt von Implementierung)
    \item Glue-Code-Layer (generischer Containerteil) wird zur Anpassung /Füllung erstellt
    \item für unterschiedliche Component Typen gibt es verschiedene Container
\end{itemize}
\subsection{Service Component Pattern}
\subsubsection{Beschreibe die Problemstellung}
\begin{itemize}
    \item es werden "Service Provider" benötigt, dies sind Komponenten die andere Komponenten der externe Systeme verändern
    \item dienen als Fassade für Subsystem, welches aus weiteren Komponenten besteht
\end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp]
    \centering
    \includegraphics[width=0.5\textwidth]{pics/service_compontent_pat.jpg}
\end{figure}
\begin{itemize}
    \item Service Component: Kapselt Prozesse und Workflow
    \item Prozesse sind stateless
    \item so kann Container Components effizient verwalten
    \item jede Operation muss abgeschlossen sein
\end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize}
    \item dient als Fassade für komplexe Systeme
    \item vereinfacht Zugriff auf diese Systeme
    \item jede Operation einer Service Component ist eigene Transaktionseinheit
    \item da stateless - gute Performance
\end{itemize}


\subsection{Session Component Pattern}
\subsubsection{Beschreibe die Problemstellung}
\begin{itemize}
    \item Service Component reicht nicht aus
    \item es soll auch ein Client oder Session-Status gespeichert werden
    \item Status ist nicht persistent und wird durch Garbage-Collection wieder entfernt
\end{itemize}

\subsubsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp]
    \centering
    \includegraphics[width=0.5\textwidth]{pics/session_component_pat.jpg}
\end{figure}
\begin{itemize}
    \item SessionComponents merken Client-spezifischen Zustand (nicht persistent)
    \item Overhead gering da es keine Nebenläufigkeit gibt
    \item Ressourcenverbrauch wird auch vom Container niedrig gehalten
\end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize}
    \item nur ein Client pro Komponente erlaubt
    \item Server kann Speicher ausgehen (\#Session-Components = \#Clients)
    \item um Speicherproblem gegenzuwirken wird Passivation verwendet
\end{itemize}

\section{Implementierungs Pattern}
\subsection{Virtual Instance Pattern}
\subsubsection{Beschreibe die Problemstellung}
\begin{itemize}
    \item viele Komponenten-Instanzen können zu Ressourcenknappheit (Speicher, Container, Systemressourcen) führen
\end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp]
    \centering
    \includegraphics[width=0.5\textwidth]{pics/virtual_instance_pat.jpg}
\end{figure}
\begin{itemize}
    \item es wird nur eine virtuelle Komponenten-Referenz geführt
    \item erst bei Bedarf (Clientaufruf) wird auf eine reale Instanz verwiesen
    \item nach Nutzung wird reale Instanz wieder in Instanzenpool zurückgegeben
    \item Arten virtueller Instanzen:
    \begin{itemize}
        \item Instance Pooling (wie beschrieben)
        \item Passivation (reale Instanzen werden zwischenzeitlich auf Festplatte geschrieben und aus Speicher gelöscht, bei Bedarf wieder geladen)
    \end{itemize}
\end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize}
    \item Anzahl realer Instanzen im Speicher meist wesentlich geringer als virtueller
    \item somit ist Aufwand und Speicherbedarf des Containers geringer
\end{itemize}
\subsection{Instance Pooling Pattern}
\subsubsection{Beschreibe die Problemstellung}
\begin{itemize}
    \item Komponenteninstanzen erstellen und entfernen ist "teuer" (Overhead)
\end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp]
    \centering
    \includegraphics[width=0.5\textwidth]{pics/instance_pooling_pat.jpg}
\end{figure}
\begin{itemize}
    \item im Container wird ein Pool von Komponenteninstanzen erstellt
    \item wird virtuelle aufgerufen, wird Poolinstanz zugeteilt
    \item nach Nutzung kommt diese wieder in den Pool
    \item Zustandsänderungen werden durch Lifecycle Callbacks kontrolliert
\end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize}
    \item bei Container Instance Pooling, zwei Status:
    \begin{itemize}
        \item pooled state: Instanz hat keine logische Identität
        \item active state: Instanz repräsentiert logische Identität, sowie funktionalen Zustand dieser
    \end{itemize}
    \item Komponenteninstanzen für Pooling befinden sich immer im Speicher
    \item Anzahl echter Instanzen schwankt mit Nutzung
    \item Component-Proxy wird verwendet um Lifecycle Operation auszulösen, bevor Poolinstanz verwendet wird
\end{itemize}


\subsection{Passivation Pattern}
\subsubsection{Beschreibe die Problemstellung}
\begin{itemize}
    \item Session Components haben Status ohne Repräsentation im Speicher
    \item es gibt Zeiträume der Inaktivität
    \item es sollen Ressourcen gespart werden
    \item z.B. Einkaufswagen eines Online Shops
\end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp]
    \centering
    \includegraphics[width=0.5\textwidth]{pics/passivation_pat.jpg}
\end{figure}
\begin{itemize}
    \item Komponenteninstanzen können durch Container temporär aus Speicher entfernt werden
    \item Zustand wird persistent gespeichert und aus Hauptspeicher gelöscht
    \item wird Instanz benötigt wird diese von Festplatte in Hauptspeicher geladen
\end{itemize}
\subsubsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize}
    \item Instanzen werden wirklich aus Speicher entfernt
    \item bei neuerlicher Herstellung müssen auch Verbindungen zu anderen Ressourcen neu geladen werden
    \item es müssen Lifecycle Callbacks implementiert werden (teilweise vom Container automatisch)
    \item bedeutet deutlichen Overhead und sollte vermieden werden (besser mehr Speicher)
\end{itemize}

\subsection{Component Proxy Pattern}
\subsubsection{Beschreibe die Problemstellung}
\begin{itemize}
    \item Clients müssen auf virtuelle Komponenteninstanzen referenzieren
    \item Container muss bei Client Aufruf für virtuelle, physikalische Instanz bereitstellen
    \item zuvor wird durch Lifecycle Callbacks auf freie geprüft
\end{itemize}


\subsubsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp]
    \centering
    \includegraphics[width=0.5\textwidth]{pics/component_proxy_pat.jpg}
\end{figure}
\begin{itemize}
    \item es wird ein Proxy für physikalische Komponenteninstanzen bereitgestellt
    \item Clients haben nie eine direkte Referenz sondern agieren nur mit Proxy
    \item Proxy handelt Instance Pooling und Passivation
    \item zur Performancesteigerung bedient ein Proxy mehrere virtuelle Komponenteninstanzen
\end{itemize}

\subsubsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize}
    \item dem Client wird durch den Proxy etwas gegeben, das ohne echte Komponenteninstanz aufgerufen werden kann
    \item Client Methodenaufrufe enthalten ID der logischen Komponenteninstanz zur korrekten Weiterleitung
    \item Proxy implementiert keine Logik - leitet nur weiter
    \item Proxy kann generiert werden, meist als Teil des Glue-Code-Layers
\end{itemize}


\subsection{Glue-Code Pattern}
\subsubsection{Beschreibe die Problemstellung}
\begin{itemize}
    \item Container soll wiederverwendet werden, dazu muss Funktionalität generisch sein
    \item Komponenten besitzen spezielle Schnittstelle und Annotationen welche spezielle Config für technische Anforderungen enthalten
    \item völlig generische Container können keine unterschiedlichen Komponenten beherbergen
\end{itemize}
\subsubsection{Erkläre die Lösung inkl. Skizze}
\begin{figure}[!htp]
    \centering
    \includegraphics[width=0.5\textwidth]{pics/glue_code_pat.jpg}
\end{figure}
\begin{itemize}
    \item Schicht aus generiertem Code als Adapter zwischen generischem Teil des Containers und Komponentenimplementierung
    \item pro spezifischer Komponente wird eigene Glue-Code-Schicht erzeugt
    \item Compontent-Proxy ist Teil dieser Schicht
\end{itemize}

\subsubsection{Beschreibe die Konsequenzen der Anwendung}
\begin{itemize}
    \item in Java mit Reflection umsetzbar (ermöglicht dynamischen Operationsaufruf)
    \item Reflection viel langsamer als spezifischer generierter Code
    \item Komponenten-Deployment:
    \begin{itemize}
        \item Zeitpunkt der Integrationsmaßnahmen des Containers
        \item Zeitpunkt der Glue-Code-Layer Generierung
    \end{itemize}
\end{itemize}