In Modul 1 und 2 haben wir betrachtet, was innerhalb eines Computers geschieht. Nun verbinden wir mehrere Systeme miteinander.

BENUTZER
   ↓
ANWENDUNG
   ↓
BETRIEBSSYSTEM
   ↓
NETZWERK
   ↓
ENTFERNTES SYSTEM

Die entscheidende neue Frage lautet: Welche Anwendung möchte von welcher anderen Anwendung etwas?

Eine Anwendung ist Software, die eine bestimmte Aufgabe für einen Benutzer oder ein anderes technisches System erfüllt.

Beispiele sind Browser, E-Mail-Client, Messenger, Datenbankanwendung, Webanwendung, SSH-Client oder RDP-Client.

Eine Anwendung kann lokal arbeiten, Netzwerkfunktionen nutzen oder beides kombinieren.

Eine lokale Anwendung kann ihre wesentliche Aufgabe auf demselben System erfüllen, auf dem sie ausgeführt wird.

BENUTZER
   ↓
ANWENDUNG
   ↓
LOKALES BETRIEBSSYSTEM
   ↓
LOKALE DATEI

Auch eine grundsätzlich lokale Anwendung kann zusätzliche Netzwerkfunktionen besitzen. Die Kategorien sind deshalb keine starren Grenzen.

Netzwerkanwendungen kommunizieren mit anderen Systemen oder Anwendungen über ein Netzwerk.

ANWENDUNG A
    ↓
 NETZWERK
    ↓
ANWENDUNG B

Browser, SSH-Client und RDP-Client sind bekannte Beispiele.

Ein Client ist eine Anwendung oder ein System, das einen Dienst eines anderen Systems nutzt beziehungsweise eine Anfrage an diesen Dienst richtet.

CLIENT
   │ Anfrage
   ▼
SERVER

Ein Browser übernimmt beim Abruf einer Webseite typischerweise eine Clientrolle.

Ein Server stellt anderen Anwendungen oder Systemen einen Dienst bereit.

CLIENT
   │ Anfrage
   ▼
SERVER
   │ Antwort
   ▼
CLIENT

Der Begriff Server kann je nach Kontext die Rolle, die Serveranwendung oder das System bezeichnen, auf dem diese Anwendung läuft.

Ein Laptop kann in einer Kommunikation Client sein und in einer anderen selbst einen Dienst bereitstellen.

SYSTEM A ── Clientrolle ──→ SYSTEM B
SYSTEM A ←─ Serverrolle ─── SYSTEM C

Ein einzelnes System kann gleichzeitig mehrere Anwendungen ausführen. Einige können als Clients, andere als Server agieren.

Das verhindert die vereinfachte Vorstellung: Client = Arbeitsplatzrechner und Server = große Maschine.

Viele Client-Server-Kommunikationen lassen sich als Anfrage und Antwort beschreiben.

CLIENT
   │
   │ REQUEST
   ▼
SERVER
   │
   │ RESPONSE
   ▼
CLIENT

Request bedeutet Anfrage, Response bedeutet Antwort.

Das Request-Response-Modell ist ein hilfreicher Einstieg, aber reale Anwendungen können viele Anfragen erzeugen, länger bestehende Verbindungen verwenden oder Daten in beide Richtungen übertragen.

Ein Benutzer öffnet eine Webseite. Aus Sicht dieses Moduls betrachten wir zunächst die Anwendungen.

BENUTZER
   ↓
BROWSER
   ↓ Request
WEBSERVER
   ↓ Response
BROWSER

Spätere Module ergänzen DNS, IP, TCP, TLS, Firewalls und weitere Infrastruktur.

Eine Webanwendung stellt Funktionen über Webtechnologien bereit und wird häufig über einen Browser genutzt.

Beispiele sind Portale, Suchoberflächen, Webmail, Dashboards oder Verwaltungsanwendungen.

Eine Webanwendung besteht häufig nicht nur aus einer einzigen Serverkomponente.

Als Frontend bezeichnet man vereinfacht den Teil einer Anwendung, mit dem ein Benutzer unmittelbar interagiert beziehungsweise der ihm dargestellt wird.

BENUTZER
   ↓
FRONTEND

Bei einer Webanwendung kann das Frontend beispielsweise im Browser dargestellt werden.

Das Backend umfasst vereinfacht die serverseitige Logik und Verarbeitung hinter einer Anwendung.

FRONTEND
   ↓
BACKEND

Das Backend kann Daten prüfen, Geschäftslogik ausführen, andere Dienste aufrufen oder Daten aus einer Datenbank beziehen.

BENUTZER
   ↓
FRONTEND
   ↓
BACKEND
   ↓
DATEN

Die sichtbare Oberfläche und die dahinterliegende Verarbeitung sollten technisch getrennt betrachtet werden.

Ein Webserver ist Software, die Webanfragen entgegennimmt und Webinhalte beziehungsweise Antworten bereitstellen kann.

Ein Webserver kann statische Inhalte direkt ausliefern oder Anfragen an weitere Anwendungskomponenten weitergeben.

Statische Inhalte können beispielsweise HTML-Dateien, Bilder, Stylesheets oder andere unverändert bereitgestellte Ressourcen sein.

Browser
   ↓
Webserver
   ↓
Datei / Ressource

Bei dynamischen Anwendungen muss eine Antwort möglicherweise erst erzeugt werden.

Browser
   ↓
Webserver
   ↓
Anwendungslogik
   ↓
Datenbank
   ↓
Antwort

Die Antwort kann sich abhängig von Benutzer, Eingabe, Zeitpunkt oder gespeicherten Daten unterscheiden.

Der Begriff Application Server bezeichnet vereinfacht eine Komponente, auf der Anwendungslogik ausgeführt beziehungsweise bereitgestellt wird.

Für Anfänger genügt die Trennung: Webserver nimmt Webkommunikation entgegen; Anwendungslogik verarbeitet fachliche oder technische Funktionen. In realen Architekturen können diese Funktionen zusammenfallen oder getrennt sein.

BROWSER
   ↓
WEBSERVER
   ↓
APPLICATION SERVER
   ↓
DATENBANK

Dieses Modell ist für den weiteren Kurs zentral, weil an jeder Schicht andere technische Daten und Ereignisse entstehen können.

Eine Datenbank dient der strukturierten Speicherung und Verwaltung von Daten.

Beispiele sind Benutzerinformationen, Konfigurationen, Produkte, Vorgänge, Zeitstempel oder Anwendungsdaten.

Eine Datenbank ist nicht einfach nur eine große Datei, auch wenn Daten letztlich auf Speichermedien abgelegt werden.

Die Software, die Datenbanken verwaltet, wird häufig Datenbankmanagementsystem genannt.

Anwendungen kommunizieren normalerweise mit dieser Software und nicht direkt mit einzelnen Speicherblöcken auf einer SSD.

Relationale Datenbanken organisieren Daten häufig in Tabellen.

users
┌────┬─────────┬───────────────────┐
│ id │ name    │ role              │
├────┼─────────┼───────────────────┤
│ 1  │ Alice   │ analyst           │
│ 2  │ Bob     │ administrator     │
└────┴─────────┴───────────────────┘

Spalten beschreiben Merkmale, Zeilen einzelne Datensätze.

Ein Primary Key ist ein Feld beziehungsweise eine Feldkombination, mit der ein Datensatz innerhalb einer Tabelle eindeutig identifiziert werden kann.

Im vereinfachten Beispiel kann die Spalte id diese Funktion erfüllen.

Eine Anwendung kann gezielt Daten aus einer Datenbank anfordern.

BACKEND
   │ Anfrage: Datensatz mit ID 42
   ▼
DATENBANK
   │ Ergebnis
   ▼
BACKEND

SQL wird später nur dort vertieft, wo es für einen Spezialisierungspfad erforderlich ist.

Moderne Anwendungen verwenden typischerweise Zwischenschichten. Das Backend kann Zugriffe kontrollieren, Eingaben prüfen und nur notwendige Funktionen bereitstellen.

Browser → Backend → Datenbank

Das ist zugleich eine erste Vorbereitung auf Sicherheits- und Architekturprinzipien.

API steht für Application Programming Interface. Eine API ist eine definierte Schnittstelle, über die Software miteinander interagieren kann.

ANWENDUNG A
   ↓
   API
   ↓
ANWENDUNG B

Eine API beschreibt, welche Funktionen oder Daten auf welche Weise angefragt werden können.

Anwendungen müssen nicht wissen, wie eine andere Anwendung intern aufgebaut ist. Sie benötigen eine definierte Schnittstelle.

Das ähnelt einem Vertrag: Welche Anfrage ist erlaubt, welche Angaben werden benötigt und welche Antwort ist zu erwarten?

Eine grafische Oberfläche richtet sich primär an Menschen. Eine API richtet sich primär an Software.

MENSCH → GUI
SOFTWARE → API

Eine Anwendung kann gleichzeitig eine GUI und eine API besitzen.

REST ist ein verbreiteter Architekturstil für Web-APIs. Für den Grundlagenkurs genügt zunächst, dass Ressourcen über standardisierte Webmechanismen angesprochen werden können.

Wir behandeln REST nicht als Programmierthema, sondern als Modell moderner Anwendungskommunikation.

Eine API kann beispielsweise Ressourcen wie Benutzer, Geräte oder Vorgänge bereitstellen.

/users
/devices
/events

Wie solche Pfade technisch übertragen werden, betrachten wir später bei HTTP.

GET wird im HTTP-Kontext typischerweise verwendet, um eine Ressource beziehungsweise Darstellung anzufordern.

CLIENT → „Gib mir Ressource X“ → SERVER

Die genaue HTTP-Semantik folgt in Modul 6.

POST wird häufig verwendet, wenn Daten an einen Dienst übermittelt oder eine Verarbeitung angestoßen werden soll.

Für dieses Modul genügt die Unterscheidung: Anwendungen können nicht nur Daten abrufen, sondern auch Informationen übermitteln.

JSON kennen wir bereits aus Modul 1. Jetzt sehen wir, warum es in modernen Anwendungen wichtig ist.

{
  "id": 42,
  "name": "Alice",
  "role": "analyst"
}

Eine API kann strukturierte Daten beispielsweise als JSON zurückgeben.

JSON ist ein Format zur Darstellung beziehungsweise zum Austausch strukturierter Daten. Eine Datenbank ist ein System zur Speicherung und Verwaltung von Daten.

FRONTEND
   │ Request
   ▼
API / BACKEND
   │ Abfrage
   ▼
DATENBANK
   │ Ergebnis
   ▼
BACKEND
   │ JSON Response
   ▼
FRONTEND

Damit können wir erstmals einen modernen Anwendungsablauf als Kette verstehen.

Nicht nur Browser kommunizieren mit Servern. Ein Backend kann selbst zum Client eines anderen Dienstes werden.

Browser
   ↓
Backend A
   ↓
API von Dienst B

Client und Server sind deshalb immer relativ zur betrachteten Kommunikationsbeziehung.

Technische Systeme kommunizieren häufig ohne unmittelbare Benutzerinteraktion miteinander.

SERVER A
   ↓ Request
SERVER B
   ↓ Response
SERVER A

Später werden solche Beziehungen in Netzwerkdaten und Logs besonders wichtig.

Browser
   ↓
Webserver
   ↓
Backend
   ├── API A
   ├── API B
   └── Datenbank

Die sichtbare Anwendung kann deshalb nur die Oberfläche einer wesentlich komplexeren Architektur sein.

Ein einzelnes Betriebssystem kann mehrere Serverprozesse beziehungsweise Dienste gleichzeitig ausführen.

SERVER-SYSTEM
 ├── Webserver
 ├── API-Dienst
 ├── SSH-Dienst
 └── Monitoring

Diese Unterscheidung knüpft direkt an Modul 2 an.

Umgekehrt kann ein einzelner Dienst auf mehreren Systemen laufen.

┌→ Server 1
Client → Dienst
             └→ Server 2

Die Gründe dafür – Skalierung, Verfügbarkeit und Lastverteilung – behandeln wir später in Modul 8.

Anwendung ist ein weiter Begriff für Software mit einer bestimmten Funktion. Dienst bezeichnet häufig eine bereitgestellte technische Funktion, die von anderen Komponenten genutzt werden kann.

Die Begriffe können sich in der Praxis überschneiden; entscheidend ist deshalb immer der konkrete Kontext.

Auch hier gilt das Modell aus Modul 1:

ANWENDUNG / PROGRAMM
      ↓ Start
PROZESS

Eine Anwendung kann aus einem oder mehreren Prozessen bestehen.

Ein laufender Prozess kann Netzwerkverbindungen annehmen und dadurch eine Serverfunktion bereitstellen.

SERVERPROZESS
     ↓
wartet auf Anfragen
     ↓
CLIENTS

Ports und Sockets lernen wir in Modul 5.

Eine einzelne Benutzeraktion kann zahlreiche technische Aktionen auslösen.

Klick auf „Anmelden“
   ↓
Frontend
   ↓
Request
   ↓
Backend
   ↓
Prüfung
   ↓
Datenbank
   ↓
Response
   ↓
Frontend

Je nachdem, wo wir eine Anwendung beobachten, sehen wir unterschiedliche Informationen.

Browser → Webserver → Backend → Datenbank
   ▲          ▲          ▲          ▲
 Client     Weblog     Applog      DB-Log

Diese Idee wird in Modul 11 und den Werkzeugmodulen zentral.

Ein Webserver-Log beschreibt Vorgänge aus Sicht des Webservers. Ein Datenbank-Log beschreibt Vorgänge aus Sicht der Datenbank.

Keines davon ist automatisch die vollständige Realität des gesamten Dienstes.

Die Beobachtung einer Anfrage beweist noch nicht, dass die gewünschte Aktion erfolgreich durchgeführt wurde.

REQUEST
   ↓
SERVER
   ↓
ERFOLG / FEHLER / ABLEHNUNG / TIMEOUT

Für belastbare Aussagen müssen gegebenenfalls Antwort und weitere Ereignisse betrachtet werden.

Auch eine technisch erhaltene Antwort kann einen Fehler oder eine Ablehnung enthalten.

Später lernen wir HTTP-Statuscodes und Anwendungsfehler genauer kennen.

Bei der Analyse können unterschiedliche technische Merkmale auftreten: Prozessname, Dienstname, Hostname, Benutzerkonto, URL, API-Pfad oder später IP-Adresse und Port.

Keiner dieser Werte sollte ohne Kontext vorschnell mit einem Menschen oder einer fachlichen Handlung gleichgesetzt werden.

BENUTZER
   ↓
BROWSER / FRONTEND
   ↓ Request
WEBSERVER
   ↓
BACKEND
   ↓
API / ANWENDUNGSLOGIK
   ↓
DATENBANK
   ↓
Response
   ↓
BROWSER

Das ist unser erstes belastbares Architekturmodell einer modernen Anwendung.

SSH CLIENT
   ↓ Request / Verbindungsaufbau
SSH SERVER / DIENST
   ↓
Authentifizierung
   ↓
Shell

Auch SSH folgt grundsätzlich einer Client-Server-Beziehung, obwohl die konkrete Kommunikation später komplexer betrachtet wird.

RDP CLIENT
   ↓
RDP SERVICE
   ↓
Remote Session

Auch hier sind Client und Server Rollen von Anwendungen beziehungsweise Diensten.

Für die weitere Ausbildung sollten Teilnehmer drei Ebenen auseinanderhalten:

SYSTEM
  ↓ beherbergt
PROZESS / DIENST
  ↓ stellt bereit
ANWENDUNGSFUNKTION

Ein physisches oder virtuelles System ist nicht dasselbe wie der darauf laufende Dienst.

Bis jetzt wissen wir, welche Anwendungen miteinander kommunizieren wollen. Noch wissen wir aber nicht, wie die beteiligten Computer einander technisch finden und erreichen.

CLIENT-ANWENDUNG
      ↓
      ?
      ↓
SERVER-ANWENDUNG

Genau dieses Fragezeichen füllt Modul 4 – Netzwerkgrundlagen.

Client und Server sind Rollen innerhalb einer Kommunikationsbeziehung.

Ein Server ist nicht automatisch eine einzelne physische Maschine.

Eine moderne Anwendung kann aus Frontend, Webserver, Backend, APIs und Datenbanken bestehen.

Eine API ist eine definierte Schnittstelle für die Kommunikation zwischen Software.

JSON ist ein Datenformat und keine Datenbank.

Eine Benutzeraktion kann zahlreiche technische Vorgänge auslösen.

Ein Request beweist noch keinen erfolgreichen fachlichen Vorgang.

Jede technische Datenquelle zeigt nur einen bestimmten Ausschnitt.