APPE

• Analyse des Memorybedarfs
• Wie reagiert die Anwendung bei hoher Belastung durch viele parallele Clients
  - Queuing der Anfragen.
  - Zurückweisen von Anfragen.
  - Verlust von Anfragen.
   
• Wiederanlaufverhalten bei Teilsystemausfall
  - Robustheit und Stabilität.
  - Resilienz.
   

Systemtechnisches Testen einer Applikation auf verschiedene Sicherheitslücken.
Prüfung und Weiterverwendung von Eingabeparameter.

Bekannte Beispiele:
- SQL-Injection in Formularen.
- Session Hijacking.

Das man immer alle unteren Schichten (integrativ) mittestet. Dies hat negative Auswirkungen für die Integrationstests:

• Ausführungszeit steigt an
• Selektivität sinkt stetig (redundante Tests)
• Abhängigkeiten steigen

Datenmanipulation durch Testfälle. Reproduzierbarkeit muss gewährleistet sein D.h:
Zustand DB muss vor und nach der Ausführung der Testfälle definiert werden.

Schnittstelle ist das GUI selber.

• Interaktivität muss für Automatisierung simuliert werden
• Verifikation des Resultates muss optisch erfolgen

Im Unterschied zu Rich-Gui-Anwendungen basieren Web Applikationen und Services auf einem strikten Request Response-Modell. (Request erzeugt Response)

Java Framework, die das automatisierte, funktionale Testen von Web-Applikationen und/oder Services ermöglichen.

• Mittels Testframeworks (JUnit, Springboot)
• Integrationstests
• Test Container
• Manuell mit Postman

• Nur eine Code-Basis
• Einfach zum deployen
• Einfach zu betreiben
• Gute Performance

• Technologie gebunden
• kann nur am Stück deployed werden
• Wartbarkeit
• Fehler Toleranz
• Beweglichkeit
• Skalierbarkeit

• Der Aufruf ist asynchron
• Anfrage wird in eine (Queue) Warteschlange gestellt
• Service hört auf eine Queue
• Wenn der Service eine Antwort benötigt, erstellt es eine Antwortnachricht und stellt es in eine Queue
  
  void MyAwsomeService(Request request)

Verfügbarkeit
Wenn der Service nicht vorhanden ist hat der Aufruf ein Fehler und der Aufrufer muss den Fehler handeln.
Fehler Toleranz
Wenn der Service gecrashed ist, hat der Aufrufer ein Timeout und er muss mit dem Fehler umgehen können.
Erweiterbarkeit
Point-to-Point Verbindung hat eine höhere Kopplung - Daher entstehen höher Kosten bei einer Anpassung
Skalierbarkeit
Wie kann man skalieren bei höherer Belastung?

Bild

Bild

Belastbarkeit:
Nachrichten gehen nicht verloren, wenn das Netzwerk ausgefallen ist. Sie werden gepuffert und geliefert, wenn das Netzwerk wieder verfügbar ist.

Fehlertoleranz:
Wenn ein Dienst abgestürzt ist oder eine Anforderung nicht verarbeiten kann, kann eine Nachricht erneut zugestellt werden.

Asynchronität:
Dienste können die weitere Verarbeitung fortsetzen, auch wenn noch keine Antwort empfangen wurde oder das Netzwerk ausgelastet ist.

Entkopplung:
Kommunikationsdienste kennen sich nicht und sind entkoppelt.

Effizienz und Skalierbarkeit:
Die vollständig asynchrone Kommunikation ist ein Schlüsselaspekt für die Reaktionsfähigkeit und die Skalierbarkeit. Die Nachrichtenwarteschlangen entkoppeln Produzent und Konsument und ermöglichen das Verteilen von Nachrichten, wenn ein Konsument überlastet wird.

Es hilft das System zu designen -> Message First Ansatz

• Mittels Geschäftsanforderungen die Aktivitäten ermitteln vom System
• Aufschlüsselung der Anforderung schlägt die Nachrichten vor im System
• Bietet konzeptionelle Ebene zwischen GS-Anforderungen und technischen SySpec.

Synchron
Wird benötigt, wenn der Caller eine Bestätigung benötigt, dass eine gewisse Aktion gemacht wurde.

Asynchron
Asynchrone Systeme sind eher ereignisgesteuert.

Um ein dynamisches Routing von Nachrichten zu ermöglichen, können wir einen Namespace für diese Nachrichten einführen. Es gibt mehrere Möglichkeiten, dies zu tun. Betrachten wir die folgenden zwei:

Beschriftungen im Nachrichtenkopf (Pattern Matching with Labels)
Der Nachrichtenkopf kann beliebige benutzerdefinierte Schlüssel-Wert-Paare enthalten. Durch das Einfügen eines Label-Schlüssels in den Header kann das Nachrichten-Routing basierend auf diesen Labels durchgeführt werden.

Hierarchische Benennung von Nachrichten (Hierarchical Naming)
Die Benennung der Nachrichten kann hierarchisch erfolgen, so dass die Nachrichten mit Musterabgleich weitergeleitet werden können.

Software, welche Messages verteilt (Messageing Service)

Dem antwortenden Service mitteilen wohin er die Nachricht senden soll.
Mit einem ReplyTo property im Message header.

Der empfangende Teil kann eine Bestätigung (ACK) senden, um zu bestätigen, dass eine Nachricht erfolgreich zugestellt oder verarbeitet wurde.
Acknowledgments können in beide Richtungen verwendet werden beim Messageingsystem:

• Das Nachrichtensystem teilt einem Produzenten mit, dass seine Nachricht empfangen wurde.
• Ein Verbraucher teilt dem System mit, dass er eine Nachricht empfangen oder verarbeitet hat.

• Fire and Forget
• Winner-take-all
• Request/Response
• Synchronous-Observed
• Dead Letter Queue

Die Kommunikation ist asynchron und die Messages werden nicht konsumiert. Jeder Service wo interessiert ist kann Nachrichten erhalten. Der Sender erwartet keine Antwort.

Die Kommunikation ist asynchron, die Nachrichten werden jedoch konsumiert. Mehrere Services können danach horchen, jedoch nur einer wird die Nachricht erhalten. Dies wird normalerweise in einem Szenario verwendet, in dem mehrere Mitarbeiter bestimmte Vorgänge parallel ausführen.

Die Kommunikation ist synchron und die Nachrichten werden konsumiert. Der sendende Service erwartet eine Nachricht auf seine Anfrage. Der horchende Service konsumiert die Nachricht und kein weiterer Service wird die Nachricht erhalten.

Die Kommunikation ist synchron, jedoch werden die Nachrichten nicht konsumiert. Der sendende Service erwartet eine Antwort auf seine Anfrage. Andere Abhördienste können die Nachrichten beobachten, aber der Absender ist nur an der Antwort eines bestimmten Teilnehmers interessiert.

Bsp:
Ein Warenkorb-Service sendet die Checkout-Nachricht, die von einem Lieferservice beantwortet wird. Der Empfehlungsservice hört auf die Checkout-Nachricht und berechnet ihre Empfehlungsdaten neu.

Es gibt eine Reihe von Gründen, warum eine Nachricht nicht zugestellt werden kann:

• Ein Empfänger kann die Nachricht nicht verarbeiten
• Ein Empfänger hat die Nachricht abgelehnt
• Eine Queue war voll
• Eine Queue ist nicht mehr verfügbar
• Die Nachricht ist abgelaufen

Ein üblicher Ansatz besteht darin, eine Queue für nicht zustellbare Nachrichten einzurichten, an die alle nicht zustellbaren Nachrichten gesendet werden. Die Queue für nicht zustellbare Nachrichten kann verwendet werden, um potenzielle Probleme im System zu finden.

Während ein asynchrones System viele Vorteile bietet, sind einige Herausforderungen zu bewältigen, wenn das System stark ausgelastet ist.
Bsp:
Angenommen wir haben 5 Produzenten, die 2 Nachrichten pro Sekunde senden, und einen Konsumenten, der 5 Nachrichten pro Sekunde verarbeiten kann: Wenn diese Situation andauert, wächst die Warteschlange auf unbestimmte Zeit.

Eine Lösung besteht darin, mehrere Instanzen des Consumers zu skalieren und hinzuzufügen. Bei diesem Ansatz beschleunigen wir den Verbrauch.

Eine andere Lösung besteht darin, die produzierende Partei zu verlangsamen, indem Gegendruckstrategien angewendet werden:

• Synchroner Gegendruck
• Lastabwurf
• Ablaufsteuerung

Messaging System
In RabbitMQ gibt es drei Grundkonzepte:

• Exchange: Ein Exchange nimmt Nachrichten entgegen und verteilt sie auf der Grundlage von Weiterleitungsregeln an Queues.
• Queue: Nachrichten werden in die Queues gestellt, die später von Verbrauchern abgerufen werden.
• Bindings: Eine Konfiguration, die einen Exchange einer Queue zuordnet und das Routing definiert.

Advanced Message Queuing Protocoll

Direct: Verwendet den Queue-namen als Bindungsmuster.

Fanout: Der Fanout-Exchange verteilt Nachrichten an alle gebundenen Queues (ohne Routing).

Topic: Verwendet den Weiterleitungsschlüssel (Routing-Key) der Queues und das Pattern-Matching, um Nachrichten an die entsprechenden Queues zu verteilen.

Connection: Die Verbindung ist eine TCP-Verbindung zu RabbitMQ. Verwenden Sie eine Verbindung pro Prozess und lassen Sie sie offen. (Nicht zu viele Connection = brauchen viel Ressourcen)

Channel: Der Kanal ist eine virtuelle Verbindung innerhalb einer Verbindung. Kanäle sind leichter. Es wird jedoch empfohlen, die Kanäle offen zu halten. Verwenden Sie unterschiedliche Kanäle für unterschiedliche Threads. (pro Thread, einen Channel -> da nicht Threadsicher)

Als Steakholder werden Personen oder Personengruppen bezeichnet, die ein berechtigtes Interesse am Verlauf oder Ergebnis eines Prozesses oder Projektes hat.

Nutzungsanforderungen: Effiziente Erbringung eines Ergebnisses

Gesetzliche Anforderungen: Gesetzgeber & Behörden

Fachliche Anforderungen: Vollständigkeit & Korrektheit

Organisatorische Anforderungen: Verhalten von Personen und Organisationseinheiten

Marktanforderungen: Für Kaufentscheidung relevant