initial commit

docs/uebungen/uebung-1.tex

@@ -0,0 +1,140 @@
+\documentclass{uebung}
+
+\author{Linus Nagel}
+\chapter{1}
+
+\usepackage{listings}
+\usepackage{xcolor}
+
+\lstset{
+    language=Java,
+    basicstyle=\ttfamily\small,
+    keywordstyle=\color{blue},
+    commentstyle=\color{green!60!black},
+    stringstyle=\color{red},
+    numbers=left,
+    numberstyle=\tiny,
+    frame=single,
+    breaklines=true,
+    showspaces=false,
+    showtabs=false,
+    tabsize=2
+}
+
+\begin{document}
+
+\maketitle
+
+\begin{exercises}
+    \item \textbf{Welche Nachteile ergeben sich durch bisherige Schichtentrennung bei der Client-Server-Programmierung mit Stand-Alone Clients?}
+
+    Bei Stand-Alone Clients ergeben sich folgende Nachteile:
+    \begin{itemize}
+        \item Jeder Client öffnet eigene Datenbankverbindungen, was bei vielen Clients zu einer hohen Belastung des Datenbankservers führt.
+        \item Die Datenbankverbindungsdaten liegen als \texttt{.class}-Dateien auf dem Client und können per Decompiler ausgelesen werden – ein erhebliches Sicherheitsrisiko.
+        \item Es fehlt eine zentrale Kontrolle über Transaktionen, Caching und Ressourcenpooling.
+    \end{itemize}
+
+    \item \textbf{Welche Nachteile ergeben sich durch bisherige Schichtentrennung bei der Client-Server-Programmierung mit Web Clients?}
+
+    Bei Web Clients treten folgende Nachteile auf:
+    \begin{itemize}
+        \item Kein einfaches Clustering (Lastverteilung und Ausfallsicherheit).
+        \item Kein zentraler Cache – häufig angefragte Daten müssen immer wieder neu aus der Datenbank geladen werden.
+        \item Threadinterferenzen müssen manuell durch den Programmierer verhindert werden.
+    \end{itemize}
+
+    \item \textbf{Was ist ein Application Server?}
+
+    Ein Application Server ist eine Laufzeitumgebung für Jakarta EE-Komponenten. Er stellt Container (z.B. EJB-Container, Web-Container) bereit und bietet standardisierte Dienste wie Transaktionssteuerung (JTA), Sicherheit (JAAS), Namensdienst (JNDI), Messaging (JMS) und Persistenz (JPA). Bekannte Beispiele sind WildFly, WebSphere und WebLogic.
+
+    \item \textbf{Worum handelt es sich bei einer Session Bean?}
+
+    Eine Session Bean ist eine Komponente der Jakarta Enterprise Beans (EJB), die die Geschäftslogik einer verteilten Anwendung kapselt. Sie wird im EJB-Container des Application Servers ausgeführt und kann von Clients (lokal, remote oder als Webservice) aufgerufen werden. Es gibt drei Typen: Stateless, Stateful und Singleton Session Beans.
+
+    \item \textbf{Worin liegt der Unterschied zwischen Stateless und Stateful Session Beans?}
+
+    \begin{itemize}
+        \item \textbf{Stateless Session Bean:} Sie speichert keinen client-spezifischen Zustand. Der Container verwaltet einen Pool von Instanzen. Bei jedem Aufruf kann eine beliebige Instanz verwendet werden. Nach der Methode werden die Daten nicht aufbewahrt.
+        \item \textbf{Stateful Session Bean:} Sie behält über mehrere Aufrufe hinweg einen client-spezifischen Zustand. Für jeden Client wird eine eigene Instanz erzeugt und bei späteren Aufrufen dieselbe Instanz wiederverwendet.
+    \end{itemize}
+
+    \item \textbf{Welche Möglichkeiten gibt es für einen Aufruf einer Session Bean?}
+
+    \begin{itemize}
+        \item \textbf{Lokaler Aufruf:} Innerhalb derselben Java Virtual Machine (z.B. von einer anderen Bean).
+        \item \textbf{Remoter Aufruf:} Von einer anderen JVM (z.B. Standalone-Client).
+        \item \textbf{Webservice-Aufruf:} Nur für Stateless Session Beans möglich, über SOAP oder REST.
+    \end{itemize}
+
+    \item \textbf{Wie wird eine Stateless Session Bean erstellt?}
+
+    \begin{enumerate}
+        \item Erstellen eines Business-Interfaces (mit \texttt{@Remote} oder \texttt{@Local}), das die öffentlichen Methoden deklariert.
+        \item Erstellen einer Klasse, die das Interface implementiert und mit \texttt{@Stateless} annotiert wird.
+    \end{enumerate}
+
+    \item \textbf{Welche Schritte sind für einen Client notwendig, um eine Methode einer Stateless Session Bean aufzurufen?}
+
+    \begin{enumerate}
+        \item Erstellen eines \texttt{InitialContext} mit den nötigen Properties (z.B. Provider-URL, Context Factory).
+        \item Aufruf von \texttt{lookup()} mit dem JNDI-Namen der Bean.
+        \item Cast des zurückgegebenen Proxy-Objekts auf das Remote-Interface.
+        \item Aufruf der gewünschten Methode auf dem Proxy.
+    \end{enumerate}
+
+    \item \textbf{Wie muss eine Stateful Session Bean annotiert werden?}
+
+    Die Bean-Klasse wird mit \texttt{@Stateful} annotiert.
+
+    \item \textbf{Wie kann bei einer Stateful Session Bean angegeben werden, dass eine Bean-Instanz nicht mehr benötigt wird und vom Server zerstört werden kann?}
+
+    Eine Methode (z.B. \texttt{beenden()}) wird mit der Annotation \texttt{@Remove} versehen. Nach dem Aufruf dieser Methode zerstört der Container die Instanz.
+
+    \item \textbf{Welchen Unterschied gibt es bei Stateful Session Beans bezüglich des JNDI-Namens?}
+
+    Beim Lookup muss an den JNDI-Namen \texttt{?stateful} angehängt werden. Beispiel: \texttt{ejb:/meineBean?stateful}
+
+    \item \textbf{Worum handelt es sich bei Singleton Session Beans?}
+
+    Eine Singleton Session Bean wird nur einmal pro Application Server instanziiert. Diese eine Instanz wird von allen Clients gemeinsam genutzt. Sie eignet sich für globale Ressourcen oder zentrale Dienste.
+
+    \item \textbf{Wie werden Singleton Session Beans erstellt?}
+
+    Die Klasse wird mit \texttt{@Singleton} annotiert. Optional kann \texttt{@Startup} hinzugefügt werden, damit die Instanz bereits beim Serverstart erzeugt wird (sonst beim ersten Lookup).
+
+    \item \textbf{Welche Probleme können durch einen gemeinsamen Zugriff von mehreren Clients auf eine Singleton Session Bean theoretisch entstehen?}
+
+    Da mehrere Threads gleichzeitig auf dieselbe Instanz zugreifen können, kommt es zu Threadinterferenzen, wenn sie lesend und schreibend auf gemeinsame Daten zugreifen. Dies kann zu Dateninkonsistenz und unerwartetem Verhalten führen.
+
+    \item \textbf{Wie kann diesen Problemen programmatisch entgegnet werden?}
+
+    Es gibt zwei Ansätze:
+    \begin{itemize}
+        \item \textbf{Container Managed Concurrency (Standard):} Mit \texttt{@Lock(LockType.READ)} für lesende und \texttt{@Lock(LockType.WRITE)} für schreibende Methoden. Der Container sorgt dann für die nötige Synchronisation.
+        \item \textbf{Bean Managed Concurrency:} Die Bean wird mit \texttt{@ConcurrencyManagement(ConcurrencyManagementType.BEAN)} annotiert und der Programmierer verwendet eigene Synchronisationsmechanismen (z.B. \texttt{synchronized}).
+    \end{itemize}
+
+    \item \textbf{Erstellen Sie eine Stateless Session Bean, die eine Methode zur Verschlüsselung eines Strings bereitstellt.}
+
+    \textbf{Remote-Interface:} \lstinputlisting{code/aufgabe16/EncryptorRemote.java}
+
+    \textbf{Bean-Klasse:} \lstinputlisting{code/aufgabe16/Encryptor.java}
+
+    \textbf{Standalone-Client:} \lstinputlisting{code/aufgabe16/Client.java}
+
+    \item \textbf{Erstellen Sie eine Stateful Session Bean, die einen Zähler zur Verfügung stellt.}
+
+    \textbf{Remote-Interface:} \lstinputlisting{code/aufgabe17/CounterRemote.java}
+
+    \textbf{Bean-Klasse:} \lstinputlisting{code/aufgabe17/Counter.java}
+
+    \textbf{Client (mehrfache Aufrufe auf derselben Instanz):} \lstinputlisting{code/aufgabe17/CounterClient.java}
+
+    \item \textbf{Warum liefert die get-Methode aus Aufgabe 17 bei einem erneuten Aufruf der Testklasse immer wieder den Startwert des Zählers?}
+
+    Bei jedem Aufruf der \texttt{main}-Methode wird eine neue Instanz der Stateful Session Bean erzeugt, da der \texttt{lookup} jedes Mal eine frische Bean-Instanz zurückgibt. Der alte Zustand (Zählerstand) ist nur innerhalb derselben Client-Sitzung gültig. Wird das Client-Programm neu gestartet, gibt es eine neue Instanz mit dem Anfangswert 0. Möchte man den Zähler über mehrere Programmstarts hinweg speichern, müsste man ihn in einer Datenbank oder Datei persistieren.
+
+\end{exercises}
+
+\end{document}