246 lines
11 KiB
TeX
246 lines
11 KiB
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}
|
|
\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}
|
|
\subsection{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}
|
|
\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}
|
|
\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}
|
|
\subsection{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}
|
|
|
|
\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}
|
|
\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}
|
|
\subsection{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}
|
|
\subsection{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}
|
|
|
|
|
|
\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}
|
|
|
|
\subsection{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}
|
|
\subsection{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}
|
|
\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}
|
|
\subsection{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}
|
|
\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}
|
|
\section{Instance Pooling Pattern}
|
|
\subsection{Beschreibe die Problemstellung}
|
|
\begin{itemize}
|
|
\item Komponenteninstanzen erstellen und entfernen ist "teuer" (Overhead)
|
|
\end{itemize}
|
|
\subsection{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}
|
|
\subsection{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}
|
|
|
|
|
|
\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}
|
|
\subsection{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}
|
|
\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
|
|
\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}
|
|
|
|
\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
|
|
\item zuvor wird durch Lifecycle Callbacks auf freie geprüft
|
|
\end{itemize}
|
|
|
|
|
|
\subsection{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}
|
|
|
|
\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
|
|
\item Proxy implementiert keine Logik - leitet nur weiter
|
|
\item Proxy kann generiert werden, meist als Teil des Glue-Code-Layers
|
|
\end{itemize}
|
|
|
|
|
|
\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}
|
|
\subsection{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}
|
|
|
|
\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
|
|
\item Komponenten-Deployment:
|
|
\begin{itemize}
|
|
\item Zeitpunkt der Integrationsmaßnahmen des Containers
|
|
\item Zeitpunkt der Glue-Code-Layer Generierung
|
|
\end{itemize}
|
|
\end{itemize}
|