Ausführungs- und Verteilungssicht

• Die Ausführungs- und Verteilungssicht beschreibt die Verteilung und Ausführung von Softwarekomponenten auf physische und logische Ressourcen (Hardware, Container/VMs/Cloud, Kommunikationswege).
• Fünf Eckpunkte sind für jede Anwendung zu klären: Infrastruktur, Client-Server-Aufteilung, Backend-Aufteilung, Persistenz und Verarbeitung.
• Die nichtfunktionalen Anforderungen (NFR) sind Performanz, Skalierbarkeit, Verfügbarkeit, Deployments (wenig/keine Downtime) und geringe Komplexität - jede Maßnahme wird gegen diese bewertet.
• Zentrale Stellschrauben: vertikal/horizontal skalieren, zustandslose Server, HA (SPOFs eliminieren), Disaster Recovery, Datenbank-Maßnahmen (Isolationsgrad, kleine LUW, eventual consistency, CQRS) und Zero Downtime.
• Die Datenbank ist das wiederkehrende Nadelöhr: Konflikt zwischen Skalierbarkeit, Performanz und Konsistenz; horizontales Skalieren scheitert an den ACID-Sperren.
• Da alle Maßnahmen zusammengenommen die Gesamtverfügbarkeit senken (Produkt der Einzelverfügbarkeiten), braucht es Resilienz: unter der Annahme entwickeln, dass etwas ausfällt.

1. Definition und Einordnung der Sicht

Die Ausführungs- und Verteilungssicht (auch Verteilungs- und Laufzeitsicht) beschreibt die Verteilung und Ausführung von Softwarekomponenten auf physische und logische Ressourcen. Sie ist eine der Architektursichten neben Geschäftssicht, Kontextsicht, Logischer Sicht, Entwicklungssicht und Datensicht. Ihre Kernthemen laut Übersicht: Verteilung auf Infrastruktur, Hintergrundverarbeitung, Performanz und Skalierung, Betrieb.

2. Bestandteile und Verwendung der Sicht

Bestandteile sind: Physische Ressourcen (Hardware für Server, Netzwerke, Datenspeicher), Logische Ressourcen (Webserver, Container, virtuelle Maschinen, Cloud-Dienste) und Kommunikationswege (Netzwerkverbindungen, verwendete Protokolle). Die Sicht beantwortet: Was muss bereitgestellt werden? Wie kann das System skaliert werden? Welche Sicherheitsmaßnahmen sind erforderlich? Das durchgängige Beispiel NGHR zeigt eine Verteilung u.a. mit Browser (Employee UI, HR UI), Docker/Tomcat/JVM für die NGHR-Application, SQL-Server und MS Exchange, verbunden über https, JDBC und SMTP.

3. Die fünf Eckpunkte

Für jede Anwendung sind fünf Eckpunkte zu klären: 1) Infrastruktur

• welche und woher, sowie Sizing (wie groß). 2) Client-Server-Aufteilung
• welche Aufgaben im Client, welche im Backend. 3) Backend-Aufteilung
• aus welchen Komponenten/Technologien besteht das Backend und wie arbeiten sie zusammen. 4) Persistenz
• welche Technologien zum Speichern der Daten. 5) Verarbeitung
• wie ist die Laufzeit-Verarbeitung organisiert (Request/Reply, ereignisorientiert, Batch; synchron oder asynchron).

4. Infrastruktur-Bereitstellung: On Premise / IaaS / PaaS

Der Stack von unten nach oben: Netzwerk, Storage, Server (inkl. OS), Virtualisierung, Betriebssystem (VM), Middleware, Laufzeit, Daten, Anwendung. Bei On Premise verantwortet die IT-Organisation alles selbst. Bei Infrastructure as a Service (IaaS) verwaltet der Anbieter bis zur Virtualisierung, die IT-Organisation ab Betriebssystem/VM aufwärts. Bei Platform as a Service (PaaS) verwaltet der Anbieter bis einschließlich Laufzeit/Middleware, die IT-Organisation liefert nur Daten und Anwendung (per Konfigurationsdatei: Storage, Datenbankservice, Anwendung mit Laufzeit/Startkommando, Verbindungen). Die Infrastruktur muss gewartet werden: Administration, Backup, Monitoring, Patches (IT-Sicherheit).

5. Sizing

Sizing ist die Auswahl der richtigen Menge physikalischer Ressourcen; die richtige Größe entscheidet über Funktionsfähigkeit und Kosten. Bestandteile: Virtuelle Maschinen (Speicher und CPU, vertikal skalieren = größere VMs oder horizontal skalieren = mehr VMs), Storage (Menge und Geschwindigkeit/Durchsatz) und ggf. Netzwerkverbindung (Latenzzeit

• wichtig bei großen geografischen Entfernungen
• und Durchsatz). Man kommt zu den Größen über Messwerte, wenn möglich, sonst durch Zahlen sammeln und quantitativ schätzen.

6. Bestandteile typischer Geschäftsanwendungen

Vier Schichten: Präsentationslogik/User Interface (Model = Datenobjekte der Oberfläche, View = Darstellung, Control = Verarbeitung von Benutzereingaben wie Navigation, Dateneingabe, Aktionen), Anwendungslogik (Daten und Verhalten der Geschäftsobjekte im Speicher), Datenzugriff (Zugriff auf persistierte Daten, CRUD = Create-Read-Update-Delete) und Persistierte Daten (gespeicherte Geschäftsobjekte und andere Daten wie Konfiguration).

7. Client-Server-Aufteilung: Thin Client, Web Anwendung, Fat Client

Thin Client: Browser mit HTML und CSS, Server-Side Rendering; Präsentations-, Anwendungslogik und Datenzugriff liegen auf dem Server. Vorteile: kein Deployment auf Endgeräten, keine Code-Duplizierung; Nachteil: viel Netzwerkkommunikation (so waren einst alle Webanwendungen). Web Anwendung: Browser mit JS-Engine, Client-Side Rendering; Präsentationslogik im Browser, Rest am Server. Vorteile: mehr UI-Optionen, weniger Netzwerkverkehr; Nachteile: Deployment auf dem Client, Code-Duplizierung (z.B. Validierung). Fat Client: App auf PC/Smartphone mit Client-Side-Logik; Präsentations- und Anwendungslogik im Client. Vorteile: Client-Hardware voll nutzbar, noch weniger Netzwerkverkehr; Nachteile: Deployment auf dem Client, Code-Duplizierung.

8. Backend-Aufteilung: Monolith

Monolith: Anwendung auf einem Server (ggf. mehrere Instanzen), eine Datenbank. Vorteile: einfach zu betreiben (wenig Infrastruktur/Wissen, einfaches Monitoring/Logging, wenige Points of Failure), einfach zu entwickeln (gesamter Quellcode an einem Ort), schnell (wenig Netzwerkverkehr). Nachteile (besonders bei großen Anwendungen): Wartbarkeitsrisiko (Abhängigkeiten in DB und Code werden groß), neigt zu großen seltenen Deployments (Agilität schwierig), Skalierung schlecht (man muss immer alles skalieren, DB nicht horizontal skalierbar).

9. Backend-Aufteilung: Serviceorientiert

Verteilt auf mehrere Server, aber eine gemeinsame Datenbank, ggf. weitere Komponenten. Zentral ist das API-Gateway (hier lebt der Service): eine stabile HTTP-API für alle Clients (Entwurfsmuster Facade und ISP), mit Optionen wie Load Balancer, Request-IDs fürs Logging, Authentifizierung, Routing ins innere Subnetz, Firewall, Rate Limiter. Optionaler Service Bus = Datenaustauschinfrastruktur, auch anwendungsübergreifend. Vorteile: granulare horizontale Skalierbarkeit der Server, kleinere/unabhängige Deployments (agiler), verschiedene Technologien pro Service. Nachteile: Datenbank weiter nicht horizontal skalierbar, höhere Komplexität (mehr Points of Failure, Monitoring/Logging schwieriger), Performanz-Risiko durch mehr Netzwerkaufrufe.

10. Backend-Aufteilung: Verteilt (Microservice)

Mehrere Server UND mehrere Datenbanken, Prinzip Share Nothing (DB A, DB B, DB C). Vorteile: Server und Datenbank horizontal skalierbar, kleine unabhängige Deployments (unabhängige Entwicklung in kleinen Teams), verschiedene Technologien für Services und DB. Nachteile: hohe Komplexität (wie serviceorientiert), Performanz-Risiko durch mehr Netzwerkaufrufe (Antipattern Chatty Services), und Datenkonsistenz über mehrere Datenbanken schwierig - keine transaktionale Konsistenz oder nur langsame verteilte Transaktionen. Zur Einordnung der Latenzen: im Speicher ~1-10 ns, im Rechenzentrum ~0,1-1 ms, zum Rechenzentrum ~10-100 ms.

11. Persistenz-Technologien

Klassiker: Relationale Datenbankmanagementsysteme (RDBMS) mit Tabellen und festem Schema (Anzahl und Art der Spalten) sowie das Dateisystem. NoSQL-Alternativen: Key-Value Store (Redis)

• Schlüssel mit unstrukturierten Werten; Zeitreihen
• Key-Value-Variante spezialisiert auf Zeitstempel als Schlüssel; Wide Column Store (Cassandra)
• zweidimensionaler Key-Value-Store aus Tabellen, wo jede Zeile andere Spalten haben kann; Dokumentenorientiert (MongoDB)
• semi-strukturierte Dokumente in XML/JSON unter einem Schlüssel; Graphenorientiert (Neo4J)
• Knoten und Kanten zur Abbildung von Netzen.

12. Verarbeitung: Request/Reply vs. Ereignisbasiert vs. Batch

Request/Reply: Sender schickt Anfrage und wartet auf Antwort

• synchrone, blockierende Kommunikation (Thread gebunden), Sender muss Empfänger kennen (enge Kopplung), Empfänger leicht überlastbar, keine Lastverteilung, dafür einfach (keine weiteren Komponenten). Ereignisbasiert: Sender löst ein Ereignis aus, Empfänger bekommt es (über Queue) zugestellt
• Sender muss Empfänger nicht kennen (lose Kopplung), asynchrone/nicht-blockierende Kommunikation möglich, Empfänger nicht überlastbar (Lastverteilung, Verkettung in Arbeitsschritte), aber Komplexität durch erforderliche Middleware (z.B. Service Bus). Hintergrundverarbeitung (Batch/Stapel): zeitgesteuert oder durch Ereignis ausgelöst; Struktur Job Definition -> Job (1..n Schritte) -> Job Instanz -> Job Ausführung -> Schritt Ausführung, mit Item Reader, Item Processor und Item Writer (Beispiel Payroll-Job: Positionen berechnen, Gehalt überweisen).

13. Nichtfunktionale Anforderungen (NFR)

Die fünf NFR, gegen die alle Maßnahmen bewertet werden: Performanz (Antwortzeiten für Requests, Datendurchsatz bei Hintergrundverarbeitung), Skalierbarkeit (bleibt performant/funktioniert bei steigender Last), Verfügbarkeit (geringe/keine ungeplante Ausfallzeit und geringe geplante Downtime bei HW-Tausch/Patches), Deployments (kurze/keine Downtime für Releases) und Geringe Komplexität (Änderungen schnell und sicher, geringe Kosten für HW, SW, Energie, Personal). Die einfache Webanwendung (App-Server + Datenbank) erfüllt kaum eine: nur vertikal skalierbar, SPOFs vorhanden, Downtime bei HW-Tausch/Patches und Releases.

14. Vertikal vs. Horizontal skalieren

Vertikal skalieren: mehr Ressourcen (CPU, Speicher) für Applikationsserver und Datenbank. Hilft der Performanz, ist aber prinzipiell begrenzt und teuer (Commodity Hardware in Rechenzentren, weil einfache PC/Laptop-Hardware günstiger ist als Spezialhardware); SPOFs bleiben, Downtime bleibt. Horizontal skalieren: mehr als ein Application Server, ein Load Balancer verteilt die Websessions. App-Server: skalierbar mit Einschränkungen (Speicherbedarf pro User Session, keine Lastumverteilung); Datenbank: nicht horizontal skalierbar. Verbessert die Verfügbarkeit (App-Server-SPOF eliminiert, keine Downtime für HW-Tausch/Patch der App-Server), Zero Downtime für Deployments mit Einschränkungen (Release-Kompatibilität, Sessions müssen beendet sein), aber mehr Komponenten.

15. Zustandslose Server

Zustandsbehaftete Server halten zwischen Requests userbezogene Informationen im Speicher (Websession-ID, Berechtigungen, Anwenderprofil, Geschäftsobjekte in Bearbeitung) - Nachteile: eingeschränkte Skalierbarkeit (Speicherverbrauch, keine Lastumverteilung), eingeschränkte Verfügbarkeit (bei Serverausfall verlieren User ihre Daten, nicht PaaS-ready), schwierigere Deployments (auf Sessionende warten). Zustandsloser Server: hält keine userbezogenen Informationen zwischen Requests. Der Zustand wird gehalten in Option 1 dem Client (mit jedem Request mitschicken), Option 2 der Datenbank (von allen geteilt, nur bei Bedarf wegen Overhead) oder für die Session-ID im spezialisierten Session Store (nicht im Client wegen Authentifizierung). Vorteile: nahezu unbegrenzte Skalierbarkeit der App-Server, hohe Verfügbarkeit (Fail-Over durch Loadbalancer), Zero Downtime ohne Session-Verlust. Nachteile: mehr Netzwerkverkehr/Last, schwierige zustandsbehaftete Funktionalität, komplexes Session-Management, größere Angriffsfläche (XSS, never trust the client), schwierigeres Logging/Monitoring. Zustandslose Server sind Standard, PaaS erwartet Zustandslosigkeit (Cloud Foundry gibt 10 Sekunden zum Runterfahren, Kubernetes stoppt/startet Container nach Bedarf).

16. Metriken der Verfügbarkeit: SLA, RTO, RPO

Service Level Agreement (SLA): Verfügbarkeit in Prozent bezogen auf eine Periode (meist ein Monat); bei SaaS/Anwendungen sind Wartungsfenster oft ausgeschlossen, bei IaaS/PaaS zählen alle Zeiten. Beispielwerte: 99,0% = 7,2h Ausfall/Monat, 99,5% = 3,6h (three nine), 99,99% = 4,3 min (four nine), 99,999% = 24 sec (five nine). Restore Time Objective (RTO): Dauer nach einer Störung, bis die Anwendung wieder verfügbar ist. Restore Point Objective (RPO): Dauer vor der Störung, auf deren Datenstand wiederhergestellt wird. Hochverfügbarkeit ist definiert als RTO fast Null und RPO = 0; RPO = 0 ist über größere geografische Distanzen physikalisch nicht möglich.

17. Hochverfügbarkeit (HA)

Strategie: SPOF (Single Point of Failure) eliminieren. Maßnahmen am Beispiel Datenbank: Redundanz (primäre Ressource wird genutzt, sekundäre Standby-Ressource bereitgehalten), Datenreplikation (Daten im Speicher und/oder persistiert), automatisches Fail-Over (Agenten überwachen und schalten um) und Monitoring (drohende/eingetretene Ausfälle bemerken, Redundanz wiederherstellen; Methoden: Heart-Beat, Antwortzeiten, Request-Status, CPU-/Memory-/Speicherverbrauch). HA durch Cluster erreicht RTO = 0 und RPO = 0. Bewertung: Replikation kostet Performanz, DB bleibt Nadelöhr, keine SPOF mehr und Zero Downtime bei HW-Tausch/Patches - aber keine Verfügbarkeit bei einem Desaster, höhere Komplexität durch Standby-Instanzen, Replikation und hohe Monitoring-Anforderungen.

18. Disaster Recovery (DR)

Ein Desaster ist eine Störung des Betriebs, die durch die vorhandenen Ressourcen nicht behoben werden kann (Gründe: Rechenzentrum unbrauchbar, Stromausfall, Naturkatastrophen, Cyberangriffe, politische/militärische Ereignisse). Strategie: Wiederherstellung des Betriebs woanders. HA kann DR mit abdecken (redundante Komponenten in anderem Rechenzentrum), aber nur bis ca. 50 km wegen der Endlichkeit der Lichtgeschwindigkeit (RPO = 0 erfordert zeitnahe Replikation). DR-Lösungen: Backup (beliebige Entfernung, keine redundante Infrastruktur, RTO Tage bis Wochen, RPO Stunden bis ein Tag), Short Distance DR/SDDR (bis ca. 50 km, nutzt HA-Infrastruktur, RTO = 0, RPO = 0), Long Distance DR/LDDR (beliebige Entfernung, Duplikation der Infrastruktur inkl. HA, RTO Stunden bis ein Tag, RPO Stunden). Eine andere Verfügbarkeitszone bedeutet meist: physikalischer Brandschutz, getrennte Stromversorgung, getrenntes Netzwerk.

19. Transaktionen, LUW und ACID

Eine Logical Unit of Work (LUW) fasst logisch zusammengehörende Datenbankänderungen zusammen (im Beispiel: Erstellung einer Gehaltsabrechnung über mehrere Tabellen, Zeilen und Spalten - PAYROLL und PAYROLL_ITEM). Ohne Transaktion drohen halbfertige Datensätze bei Abbruch oder das Lesen inkonsistenter Zwischenstände. ACID-Eigenschaften einer Transaktion: Atomic (alles oder nichts wird geschrieben), Consistent (Datenbank ist vor und nach der Transaktion konsistent), Independent/Isolated (Transaktionen sind voneinander unabhängig), Durable (einmal gemachte Änderung ist dauerhaft, auch bei Stromausfall). Beispiel: elementare Statements zwischen start transaction und commit zusammenfassen. Wichtig: LUW ist fachlich, nicht technisch definiert.

20. Konflikt Skalierbarkeit / Performanz / Konsistenz

Um ACID einzuhalten, setzt die Datenbank Sperren auf Zeilen (update, read) und Tabellen (insert, delete); andere Zugriffe müssen warten. Das erzeugt einen grundlegenden Konflikt: Skalierbarkeit (viele Anfragen unabhängig voneinander), Konsistenz (jeder lesende Zugriff sieht den letzten schreibenden, Zugriffe müssen warten, horizontal skalieren problematisch) und Performanz (jede Operation schnell) lassen sich nicht gleichzeitig maximieren. Folgerung: horizontales Skalieren der Datenbank ist keine Option (Sperren müssten instanzübergreifend gesetzt werden), vertikal skalieren geht mit Grenzen. Da die LUW fachlich definiert ist, müssen Skalierbarkeit und Performanz der Datenbank auch fachlich betrachtet werden - eine reine Infrastrukturlösung ist nicht möglich.

21. DB-Maßnahme 1: Isolationsgrad reduzieren

Mögliche Inkonsistenzen: Dirty Reads (noch nicht committete Änderungen werden gelesen), Non-Repeatable Reads (T1 liest, T2 ändert und committet, T1 liest anderes Ergebnis) und Phantom Reads (T2 fügt Zeilen ein und committet, T1 bekommt beim erneuten Lesen eine Zeile mehr). Isolationsgrade: Read Uncommitted (alle drei erlaubt), Read Committed (Dirty Reads verhindert), Repeatable Read (Dirty und Non-Repeatable verhindert), Serializable (alle drei verhindert). Wenn fachlich zu rechtfertigen, verzichtet man in kontrollierter Weise auf etwas Konsistenz zugunsten von Skalierbarkeit und Performanz.

22. DB-Maßnahme 2 und 3: Kleine LUW und Eventual Consistency

Maßnahme 2

• LUW klein halten (keine Sagas): Konsistenzanforderungen sind fachlich und nicht wegdiskutierbar, aber oft kann man Anwendungsfälle aufteilen (Beispiel NGHR Mitarbeiter Einstellen: Aufteilung in drei Teile mit neuem Zustand In Anlage). Maßnahme 3
• Zukünftige Konsistenz (eventual consistency): oft reicht Konsistenz zu einem späteren Zeitpunkt; kleine Transaktionen ohne echten Konsistenzverzicht, wobei die spätere Verarbeitung wie mit ACID-Kriterien garantiert wird. Eine Saga verkettet mehrere Transaktionen (Teil 1, Teil 2, Teil 3) über Trigger, mit temporärer Inkonsistenz zwischen den Schritten. Teilt man das Datenmodell so, dass zwischen Datengruppen zukünftige Konsistenz genügt, kann man massiv horizontal skalieren (Weg zum Microservice): Datenbank und App-Server unabhängig horizontal skalierbar, bessere Verfügbarkeit, weniger Deployment-Auswirkungen, kleinere Teams (wenn Modul A ausfällt, läuft Modul B weiter).

23. DB-Maßnahme 4: CQRS

Command-Query Responsibility Segregation trennt Lesen und Schreiben mit zukünftiger Konsistenz. Schreiben nutzt ein normalisiertes Schema mit minimaler Anzahl von Referenzen (Command Model/Schema, schnelles Schreiben); Lesen nutzt ein denormalisiertes Schema mit hoher Anzahl von Referenzen (Query Model/Schema, schnelles Lesen). Die Übertragung erfolgt per ETL (Extract-Transform-Load). Nachteile: zusätzliche Komplexität, fragliche User Experience. Elegant ist, von Anfang an Datenbank-Views statt eigener Query-Schemata zu nutzen, weil der Umstieg dann einfacher ist und eine Verteilung auf zwei DB-Server (horizontale Skalierung) möglich wird. Das ist nicht neu: siehe OLTP (Online Transactional Processing) versus OLAP (Online Analytical Processing / Data Warehouse).

24. Zero Downtime

Ziel: Release wechseln ohne Nichtverfügbarkeit. Technische Voraussetzungen: mindestens zwei Applikationsserver mit Load Balancer und zustandslose Server. Release-Kompatibilität bedeutet: das neue Release muss mit dem alten Datenbankschema kompatibel sein, im Hintergrund bereits das neue Schema bedienen und umschaltbar sein (per Toggle oder Versionierung des Verhaltens von Geschäftsobjekten). Beispiel Schemaänderung (Kunde -> Land -> Region) in fünf Schritten: 1) Datenbank vorbereiten (neue Tabellen, optionale Relation), 2) Release, das altes und neues Schema bedient, 3) Datenmigration der Bestandsdaten, 4) Toggle anschalten (nur noch neues Schema), 5) beim nächsten Release aufräumen (alte Tabelle löschen, Toggle und toten Code entfernen). Merksatz: Zero Downtime ist nicht nur eine Frage von Infrastruktur und Betrieb, sondern muss bei der Release-Planung von Anfang an bedacht werden.

25. Übersicht der Maßnahmen und ihr Zusammenspiel-Problem

Die Übersichtstabelle ordnet jede Maßnahme den NFR zu: Vertikal skalieren (Performanz, Skalierbarkeit), horizontal skalieren und zustandslose Server (Skalierbarkeit, Verfügbarkeit, Downtime), HA für SPOFs (Verfügbarkeit, Downtime), DR (Verfügbarkeit), Isolationsgrad und kleine LUW (Performanz, Skalierbarkeit), zukünftige Konsistenz (Performanz, Skalierbarkeit, Verfügbarkeit, Downtime), CQRS (Performanz, Skalierbarkeit) und Release-Kompatibilität einplanen (Downtime). Pointe der Vorlesung: Für alle NFR wurden Maßnahmen gefunden, doch zusammengenommen funktionieren sie nicht - unbemerkt hat sich ein neues Problem gebildet: die Verfügbarkeit stark verteilter Systeme.

26. Resilienz

In stark verteilten Systemen ergibt sich rechnerisch eine geringe Gesamtverfügbarkeit, weil die Gesamtverfügbarkeit das Produkt der Einzelverfügbarkeiten ist. Bei Einzelverfügbarkeit 99,9% liegt das System bei 15 Komponenten schon bei 98,5% (ca. 10,7 h/Monat Ausfall), bei 30 Komponenten bei 97,0% (ca. 21,3 h/Monat). Zudem ist das Verhalten nicht vorhersagbar (keine systemweite Transaktion, unkontrolliertes Netzwerk, Programmierfehler, Patches, Releases, Konfiguration). Die Einzelverfügbarkeit weiter zu erhöhen hilft nicht (unmöglich/zu teuer). Man lässt die Annahme fallen, ein zuverlässiges System bauen zu können, und entwickelt unter der Annahme, dass etwas ausfällt - getestet durch Chaos Engineering (in der Testumgebung zufällig Komponenten abschalten). Resilienz ist die Fähigkeit, sich schnell von widrigen Umständen zu erholen. Elemente: Isolation (unabhängige Einheiten, kaskadierende Fehler verhindern), Redundanz (HA, DR, Datenreplikation statt Online-Zugriff, Retry), Lose Kopplung (zukünftige Konsistenz, asynchrone Kommunikation über Middleware), Fall-back (Alternativen oder kontrollierte Teildeaktivierung) und Recovery (Monitoring und Notfallpläne). Resilienz beginnt bei den fachlichen Szenarien: Was muss verfügbar sein, was kann isoliert werden, was sind geeignete Alternativen.