Vorlesung 6: Architekturmuster und -stile (Fortsetzung) Flashcards
Erkläre Bereitstellungsarten und architektonische Quanta
Architektur-Quanten und Bereitstellungsstile:
Bereitstellungsstile definieren nicht die innere Struktur von Komponenten, sondern die Anzahl der unabhängig bereitgestellten Komponenten.
Ein Architektur-Quantum bezeichnet ein unabhängig bereitstellbares Artefakt mit hoher funktionaler Kohäsion und synchroner Konnascenz:
Unabhängig bereitstellbar: Ein Quantum enthält alle Komponenten, die notwendig sind, um unabhängig zu funktionieren (einschließlich Infrastrukturkomponenten wie genutzte Datenbanken).
Hohe funktionale Kohäsion: Ein Quantum verfolgt einen bestimmten Zweck und „erfüllt eine sinnvolle Funktion“.
Synchrone Konnascenz: Innerhalb eines Quantums sind synchrone Serviceaufrufe üblich, daher müssen die Betriebseigenschaften zwischen den aufgerufenen Komponenten identisch sein (die Services müssen gleich skalierbar sein).
Ein Architektur-Quantum ist die „minimale architektonische Einheit“.
erkläre Monolithische Systeme:
Ein Monolith wird allgemein als eine geologische Struktur aus einem einzigen massiven Stein oder Felsen betrachtet.
Ein monolithisches System ist als untrennbare Einheit konzipiert, die nicht explizit in Unter-Komponenten aufgeteilt ist und alle zugehörigen Quellcodes in einer einzigen Bereitstellung enthält (Benutzeroberfläche, Geschäftsprozessabläufe, Geschäftsregeln usw.).
Größere monolithische Systeme haben typischerweise eine große Quantengröße und weisen oft keine hohe funktionale Kohäsion auf.
Monolithen werden oft als „Big Ball of Mud“ betrachtet, wenn das System eine chaotische Struktur hat, bei der die Komponenten stark gekoppelt sind und Änderungen weitreichende Nebeneffekte verursachen können.
Vor- und Nachteile von Monolithen:
Vorteile:
Einfach zu ändern und zu entwickeln, insbesondere bei kleineren Änderungen.
Funktionalitäten können leicht zwischen verschiedenen Komponenten geteilt werden.
Konsistenz zwischen den Komponenten ist einfach zu erreichen.
Höhere Leistung aufgrund fehlender Latenzzeiten und Kommunikationsaufwands.
Nachteile:
Hohe Kopplung der Komponenten wird nicht verhindert.
Mit wachsender Systemgröße steigt die Komplexität.
Längere Entwicklungszyklen bei wachsenden Systemen.
Architektonische Änderungen sind schwer umzusetzen, da das gesamte System betroffen ist.
Fehler in einer Komponente können das gesamte System beeinträchtigen.
Keine selektive Skalierbarkeit möglich.
Organisatorischer Mehraufwand bei der Arbeit mit mehreren Teams.
Erkläre Modulare Monolithen: Modulithen
Grundprinzipien und Strukturierung:
Einige Nachteile von Monolithen, einschließlich des “Big Ball of Mud”-Antipatterns, treten hauptsächlich auf, wenn ein Monolith schlecht strukturiert ist.
Die Strukturierung eines Monolithen in Module kann das Risiko einer chaotischen Struktur vermindern, indem sie:
Komponenten isoliert,
eine lose Kopplung zwischen den Komponenten fördert,
kleine Änderungseinheiten ermöglicht.
Unabhängigkeit und Management von Modulen:
Module sind niemals unabhängig; sie sind integraler Bestandteil des Systems.
Die Verwaltung von Modulen ist essentiell, um eine Verschlechterung der Architektur zu verhindern. Dies beinhaltet:
Festlegung klarer Modulgrenzen (Kohäsion),
Definition von Modulschnittstellen (Informationsverbergung).
Innere Struktur modularer Monolithen:
Module innerhalb eines Monolithen können mit passenden architektonischen Stilen und Mustern strukturiert werden.
Abhängigkeiten zwischen den Modulen sollten auf Geschäftsfunktionalitäten basieren.
Domain-Driven Design (DDD) unterstützt die Schaffung klarer Modulgrenzen durch abgegrenzte Kontexte und hilft, das Teilen von Code zu vermeiden, wodurch die Kopplung reduziert wird.
Verschiedene architektonische Stile in Modulen:
Unterschiedliche architektonische Stile können in verschiedenen Modulen verwendet werden, was besonders bei variierenden Qualitätsanforderungen sinnvoll sein kann:
Microkernel-Architektur, wenn Erweiterbarkeit wichtig ist,
Pipeline-basierte Architektur für Module, die ähnlich wie ETL-Prozesse funktionieren.
Herausforderungen beim Mischen architektonischer Stile:
Das Mischen verschiedener architektonischer Stile kann zu Problemen führen:
Entwickler, die mit einem Modul vertraut sind, können ihr Wissen möglicherweise nicht auf ein anderes übertragen.
Elemente eines architektonischen Stils können in andere Module übergehen, was die Gesamtkomplexität erhöht (z.B. die Implementierung von Plugins in einem Microkernel-Modul).
Diese Zusammenfassung verdeutlicht die Vorteile und Herausforderungen modularer monolithischer Systeme, insbesondere im Hinblick auf ihre Strukturierung, das Modulmanagement und die Auswahl geeigneter architektonischer Stile für die verschiedenen Module.
Sieh dir die Abbildung an: Inner Structure of Modular Monoliths (2)
Sieh dir die Abbildung an: Inner Structure of Modular Monoliths (3)
Vergleich zwischen Monolithen und Modulithen
▪ Modulare Monolithen sind Monolithen “richtig gemacht”
▪ Die Strukturierung eines Monolithen in Module hat Vorteile:
- Änderbarkeit und Erweiterbarkeit werden erhöht
- Architektonische / technologische Modernisierungen können leicht im Rahmen eines einzelnen Moduls durchgeführt werden
- Verschiedene Teams können leichter an getrennten Modulen arbeiten
- Ripple-Down-Effekte werden verhindert
▪ Einige Nachteile sind jedoch weiterhin relevant:
- Entwicklungszyklen werden länger, wenn Systeme wachsen (ein großes Quantum)
- Fehler in einer einzelnen Komponente können zu einer Beeinträchtigung des gesamten Systems führen
- Keine “selektive Skalierbarkeit” möglich
- Organisatorischer Mehraufwand bei der Arbeit mit mehreren Teams (aber reduzierter
Erkläre Bereitstellungsstile: Verteilte Systeme
Charakteristika verteilter Systeme:
Verteilte Systeme zeichnen sich durch die Zusammenarbeit von Verarbeitungs- und Speicherkomponenten über Kommunikationsnetzwerke aus.
Daten, Prozesse und Benutzer können räumlich verteilt arbeiten.
Die Kommunikation zwischen Komponenten kann synchron oder asynchron erfolgen.
Koordination und Unabhängigkeit:
Die Koordination der Arbeit kann zentralisiert (mit einem Orchestrator) oder dezentralisiert sein.
Komponenten werden unabhängig voneinander bereitgestellt.
Architektonische Quanten in verteilten Systemen:
Ein verteiltes System besteht aus verschiedenen architektonischen Quanten, die typischerweise kleiner sind als in einem monolithischen System.
Diese Quanten können eine höhere Kohäsion erreichen, bedingt durch ihre kleinere Größe.
Transparenz für den Benutzer:
Die Kombination unterschiedlicher Komponenten ist für die Nutzer nicht sichtbar, was die Komplexität des Systems für die Endbenutzer verbirgt.
Diese Zusammenfassung hebt die Hauptmerkmale verteilter Systeme hervor, einschließlich ihrer strukturellen Verteilung, Kommunikationsmechanismen, Koordinationsansätze und der Unabhängigkeit ihrer Komponenten.
Erkläre Verteilter Bereitstellungsstil: Client-Server
Grundlagen der Client-Server-Architektur:
Die Client-Server-Architektur ist die einfachste Form eines verteilten Systems und besteht mindestens aus zwei Bereitstellungseinheiten: den Clients und dem Server.
Clients nutzen Dienste, die von einem bekannten Server bereitgestellt werden, während Server diese Dienste anbieten und Ergebnisse an die aufrufenden Clients zurücksenden.
Kommunikation und Beziehungen:
Die Kommunikation zwischen Client und Server erfolgt synchron.
Traditionell gibt es eine n:1-Beziehung zwischen Clients und Servern, aber es können mehrere Server verwendet werden, um horizontal zu skalieren.
Integration in monolithische Systeme:
Auch in monolithischen Systemen wird eine Trennung zwischen Client- und Servicekomponenten als Stand der Technik angesehen, beispielsweise in geschichteten Architekturen.
Diese Zusammenfassung zeigt, dass die Client-Server-Architektur ein grundlegendes Modell für verteilte Systeme darstellt, welches durch seine klare Trennung von Client- und Serverrollen und die Möglichkeit zur Skalierung charakterisiert ist.
erkläre Moderne Webanwendungen als Client-Server-Architekturen
Traditionelle webbasierte Anwendungen:
In traditionellen Webanwendungen erfolgt die gesamte Verarbeitung auf einem Backend-Server.
Aus Sicht der Benutzeroberfläche (UI) beinhaltet dies auch das serverseitige Rendern (Server-Side Rendering, SSR) von HTML oder HTML-Fragmenten.
Das serverseitige Rendern kann relativ lange dauern, da die gesamte Anwendung gerendert werden muss, was den Benutzerfluss stören kann.
Moderne Ansätze und Client-seitiges Rendern:
Aufgrund dieser Einschränkungen nutzen moderne Anwendungen einen Ansatz des client-seitigen Renderns (Client-Side Rendering, CSR).
Beim CSR wird der Inhalt direkt im Browser gerendert, wobei der Server lediglich Daten (anstatt fertigen HTML-Codes) an den Browser sendet.
Der Anwendungscode, der diese Daten verarbeitet und das HTML rendert, läuft direkt im Browser.
Single-Page Applications (SPAs):
Single-Page Application (SPA) Frameworks sind fortschrittliche CSR-Frameworks, die auch Teile der Geschäftslogik enthalten können. Beispiele hierfür sind Angular und React.
Diese Frameworks ermöglichen eine dynamische Interaktion auf der Client-Seite, ohne dass für jede Aktion eine neue Seite vom Server geladen werden muss.
Zusammenfassung:
Moderne Webanwendungen, die CSR und SPA-Frameworks nutzen, können als Client-Server-Architekturen betrachtet werden, bei denen die Verarbeitungslast zwischen dem Client und dem Server aufgeteilt ist.
Diese Ansätze bieten eine verbesserte Benutzererfahrung durch schnelleres Rendern und geringere Störungen des Benutzerflusses. Sie erlauben eine effizientere und reaktionsfähigere Interaktion mit der Benutzeroberfläche im Vergleich zu traditionellen SSR-basierten Anwendungen.
erkläre Verteilter Bereitstellungsstil: Ereignisgesteuerte Architektur
Traditionelle anfragebasierte Modelle:
Die meisten Anwendungen folgen einem anfragebasierten Modell, bei dem eine Anfrage an einen Anfrage-Orchestrator (z. B. eine Benutzeroberfläche) gesendet wird.
Der Anfrage-Orchestrator leitet die Anfrage deterministisch und synchron an verschiedene Anfrage-Prozessoren weiter, die die Anfrage bearbeiten
Ereignisgesteuerte Architekturen:
Im Gegensatz zu anfragebasierten Modellen stehen ereignisgesteuerte Architekturen, bei denen das System auf Situationen reagiert und auf der Basis dieser Ereignisse (typischerweise asynchron) Aktionen ausführt.
Ereignisgesteuerte Systeme sind reaktiver und können dynamischer auf Veränderungen oder Benutzereingaben reagieren.
Topologien ereignisgesteuerter Systeme:
Es gibt zwei verschiedene Topologien ereignisgesteuerter Systeme: die Broker-Topologie und die Mediator-Topologie.
Broker-Topologie: Bei dieser Topologie werden Ereignisse durch einen zentralen Broker geleitet, der für die Verteilung der Ereignisse an die entsprechenden Dienste zuständig ist.
Mediator-Topologie: Hierbei wird ein Mediator verwendet, der nicht nur die Ereignisse verteilt, sondern auch die Verarbeitungslogik orchestriert und möglicherweise aggregiert.
Zusammenfassung:
Ereignisgesteuerte Architekturen bieten im Vergleich zu traditionellen anfragebasierten Modellen eine flexiblere und oft effizientere Möglichkeit, auf Benutzeraktionen oder Systemereignisse zu reagieren. Diese Architekturen eignen sich besonders gut für Anwendungen, die eine hohe Skalierbarkeit und reaktive Verarbeitung erfordern. Sie nutzen entweder eine Broker- oder eine Mediator-Topologie, um Ereignisse zu verwalten und zu verarbeiten.
Erkläre Ereignisgesteuerte Architektur: Kommunikationsaufrufe
Asynchrone Kommunikation:
In einer ereignisgesteuerten Architektur ist die Kommunikation typischerweise asynchron.
Diese Art der Kommunikation wird sowohl für “Fire-and-Forget” als auch für das “Request-Response”-Schema verwendet.
Asynchrone Kommunikation zwischen Komponenten erhöht die Reaktionsfähigkeit, auch wenn die Leistung nicht signifikant gesteigert wird.
Herausforderungen bei asynchroner Kommunikation:
Ein negativer Aspekt der asynchronen Nachrichtenübermittlung ist die Fehlerbehandlung: Der Nachrichtensender wird nicht direkt über einen Verarbeitungsfehler informiert, sobald die Nachricht abgesetzt wurde.
Synchrone Kommunikation:
Synchrone Kommunikation kann durch “Request-Reply”-Messaging mit Wartezeiten und dedizierten Anfrage- und Antwortwarteschlangen umgesetzt werden.
Zusammenfassung:
Ereignisgesteuerte Architektur nutzt hauptsächlich asynchrone Kommunikation, um die Reaktionsfähigkeit zu verbessern, steht jedoch vor Herausforderungen bei der Fehlerbehandlung. Synchrone Kommunikationsmethoden können ebenfalls integriert werden, erfordern jedoch spezifische Mechanismen wie dedizierte Warteschlangen.
Erkläre Ereignisgesteuerte Architektur: Verhinderung von Datenverlust
Datenverlust als Hauptanliegen:
In der asynchronen Kommunikation, wie sie in ereignisgesteuerten Architekturen üblich ist, stellt der Datenverlust ein primäres Anliegen dar.
Es sind Mechanismen erforderlich, um zu bestätigen, dass eine Nachricht ihr Ziel erreicht hat. Nachrichten können beim Senden zum Kanal oder vor der Zustellung an den Empfänger verloren gehen. Auch die Verarbeitung einer Nachricht durch den Empfänger kann fehlschlagen.
Maßnahmen zur Vermeidung von Datenverlust:
Persistente Warteschlangen und synchrones Nachrichtensenden können helfen, Nachrichtenverlust am Anfang des Übertragungsweges zu verhindern.
Der Client-Acknowledge-Modus kann eingesetzt werden, um zu gewährleisten, dass der empfangende Ereignisprozessor die Nachricht erhalten hat.
Nach Abschluss der Verarbeitung können Last Participant Support (LPS) oder Last Resource Commit Optimization (LRCO) verwendet werden, um zu bestätigen, dass die Verarbeitung abgeschlossen wurde.
Zusammenfassung:
Um den Herausforderungen des Datenverlusts in ereignisgesteuerten Architekturen zu begegnen, ist der Einsatz von persistenten Warteschlangen, synchroner Übertragung und Bestätigungsmechanismen essenziell. Diese Methoden stellen sicher, dass Nachrichten korrekt empfangen, verarbeitet und deren Verarbeitungsabschluss dokumentiert wird.
Erkläre Ereignisgesteuerte Architektur: Broker-Topologie
Grundlagen der Broker-Topologie:
In einer Broker-Topologie gibt es keinen zentralen Ereignisvermittler.
Der Nachrichtenfluss wird über die Ereignisprozessorkomponenten verteilt, ähnlich einer Kettenübertragung.
Nachrichten werden typischerweise asynchron verarbeitet.
Komponenten einer Broker-Topologie:
Initiierendes Ereignis: Ein Ereignis (einfach oder komplex), das den gesamten Fluss startet.
Event-Broker: Kanäle im Event-Broker nehmen Ereignisse auf und verteilen sie.
Ereignisprozessor: Nimmt Ereignisse vom Broker auf und startet die Verarbeitung.
Verarbeitungsereignis: Ereignisprozessoren können Verarbeitungsereignisse (d.h. Nachfolgeereignisse) erzeugen, die wiederum von anderen Ereignisprozessoren aufgenommen werden können.
Nachrichtenkanäle und -verarbeitung:
Ereigniskanäle werden typischerweise über Publish-and-Subscribe-Themen realisiert.
Ereignisprozessoren, die auf dieselbe Nachricht reagieren, werden parallel ausgeführt.
Lose Kopplung und Erweiterbarkeit:
Ereignisprozessoren wissen in der Regel nicht, wer die ausgesendeten Ereignisse konsumiert, was eine lose Kopplung darstellt.
Die Erweiterbarkeit wird ermöglicht, indem Ereignisprozessoren stets neue Ereignisse auf Basis ihrer Verarbeitung ausgeben.
Wenn kein Ereignisprozessor auf ein spezifisches Ereignis hört, wird es verworfen.
Bestehende Prozesse können durch Hinzufügen neuer Ereignisprozessoren erweitert oder bereichert werden.
Ressourcenaufwand und Workflow-Management:
Der Ressourcenaufwand für das Senden unerwünschter Nachrichten ist vernachlässigbar.
Das Aufbauen von Workflows basierend auf Nachrichten in einer Broker-Topologie kann schwierig zu überwachen sein.
Zusammenfassung:
Die Broker-Topologie in ereignisgesteuerten Architekturen ermöglicht eine flexible und skalierbare Behandlung von Ereignissen durch asynchrone Verarbeitung und parallele Ausführung von Ereignisprozessoren. Die Topologie unterstützt die lose Kopplung und einfache Erweiterbarkeit von Systemkomponenten, stellt jedoch Herausforderungen in der Überwachung komplexer Nachrichtenflüsse dar.
erkläre Ereignisgesteuerte Architektur: Mediator-Topologie
Kernkonzept der Mediator-Topologie:
Im Zentrum der Mediator-Topologie steht ein Ereignisvermittler (Event Mediator), der den Workflow von Ereignissen steuert, welche die Koordination mehrerer Ereignisprozessoren erfordern.
Komponenten einer Mediator-Topologie:
Initiierendes Ereignis: Ein Ereignis, das den gesamten Fluss startet und an eine spezifische “initiierende” Ereigniswarteschlange gesendet wird.
Ereigniswarteschlange: Nimmt initiierende Ereignisse auf, die vom Ereignisvermittler bearbeitet werden.
Ereignisvermittler: Kennt die Verarbeitungsschritte für ein initiierendes Ereignis und leitet diese Ereignisse an die entsprechenden Ereigniskanäle weiter.
Ereignisprozessor: Hören auf dedizierte Ereigniskanäle, verarbeiten Ereignisse und antworten dem Ereignisvermittler.
Vielseitigkeit und Komplexitätsmanagement:
Es kann mehrere Ereignisvermittler geben, die spezifisch für bestimmte Domänen sind.
Vermittler können verkettet werden, um auf die Komplexität eines Ereignisses zu reagieren. Beispielsweise werden einfache Ereignisse direkt verarbeitet, während komplexe Ereignisse auf der Basis von Geschäftsprozessmanagement (BPM) an einen spezialisierten Ereignisvermittler für komplexe Ereignisse weitergeleitet werden.
Zusammenfassung:
Die Mediator-Topologie in ereignisgesteuerten Architekturen ermöglicht eine zentralisierte Steuerung und Koordination von Ereignisflüssen durch spezialisierte Vermittler, die die notwendigen Verarbeitungsschritte an verschiedene Ereignisprozessoren delegieren. Diese Topologie eignet sich besonders für komplexe Szenarien, in denen Ereignisse mehrstufige Verarbeitungen durchlaufen müssen, und unterstützt durch die Verkettung von Vermittlern eine flexible Reaktion auf unterschiedliche Anforderungen der Ereigniskomplexität.
erkläre die Vor- und Nachteile ereignisgesteuerter Architekturen
Vorteile:
Lose Kopplung der Komponenten: Ereignisgesteuerte Architekturen ermöglichen eine sehr lose Kopplung der Komponenten, was besonders in der Broker-Topologie ausgeprägt ist.
Hohe Leistungsfähigkeit: Sie bieten hohe Performance durch asynchrone Verarbeitung.
Skalierbarkeit und Elastizität: Aufgrund der losen Kopplung und asynchronen Verarbeitung sind diese Systeme gut skalierbar und elastisch.
Anpassungsfähigkeit und Erweiterbarkeit: Ereignisgesteuerte Architekturen sind leicht anpassbar und erweiterbar, was Änderungen und Erweiterungen der Systemfunktionalität erleichtert.
Modulare Struktur: Sie ermöglichen eine einfache Implementierung modularer Strukturen.
Fehlertoleranz: Ausfälle bei einzelnen Ereignisprozessoren beeinträchtigen nicht das gesamte System.
Nachteile:
Unsicherheit über das Ergebnis: Die Sicherheit über das Endergebnis ist reduziert, da die asynchrone Natur und die lose Kopplung es schwieriger machen, den Endzustand vorherzusagen.
Komplexität: Ohne Mediator kann die Architektur sehr komplex werden, da die Koordination und Verwaltung der Ereignisse schwieriger ist.
Testbarkeit: Die Testbarkeit ist aufgrund des nichtdeterministischen Flusses eine Herausforderung. Es ist oft kompliziert, alle möglichen Zustände und Ereignisfolgen effektiv zu testen.
Zusammenfassung:
Ereignisgesteuerte Architekturen bieten zahlreiche Vorteile wie lose Kopplung, hohe Leistung und Fehlertoleranz, stehen jedoch vor Herausforderungen wie erhöhter Komplexität und schwieriger Testbarkeit, besonders in Abwesenheit eines Mediators. Diese Eigenschaften machen sie ideal für Systeme, die eine hohe Skalierbarkeit und Anpassungsfähigkeit benötigen, erfordern jedoch sorgfältige Planung und Management, um die Kontrolle über die Systemdynamik zu behalten.
Erkläre: Verteilter Bereitstellungsstil: Space-based Architektur
Grundlagen der Space-based Architektur:
Die Space-based Architektur ist darauf ausgelegt, hohe Skalierbarkeit, Elastizität und Nebenläufigkeit zu erreichen, auch bei extremen Lastspitzen.
Sie basiert auf dem Konzept des Tupelraums:
Ein Raum (Space) dient als Repository für Tupel.
Tupel können gleichzeitig zugegriffen und bearbeitet werden.
Tupel werden im Raum veröffentlicht und von einer Verarbeitungseinheit („Consumer“) basierend auf dem Tupelmuster verarbeitet.
Datenverwaltung und -speicherung:
Als schwer skalierbare Komponente wird die Datenspeicherung in In-Memory-Datengitter repliziert.
Daten werden asynchron persistiert, beispielsweise unter Verwendung von Nachrichtenwarteschlangen.
Zusammenfassung:
Die Space-based Architektur nutzt das Konzept des Tupelraums, um eine effiziente und hoch skalierbare Verarbeitung von Daten zu ermöglichen. Durch die Verwendung von In-Memory-Datengittern und asynchroner Datenpersistenz wird die Leistung optimiert und die Systemelastizität verbessert. Diese Architektur eignet sich besonders für Anwendungen mit hohen Anforderungen an Nebenläufigkeit und Lastspitzen.
Erkläre Caching in Space-based Architekturen
Übersicht der Caching-Optionen:
In Space-based Architekturen gibt es zwei Hauptmethoden für das Caching: Repliziertes Caching und Verteiltes Caching.
Repliziertes Caching:
Jede Verarbeitungseinheit enthält eine Kopie der Daten in ihrem eigenen Datengitter.
Die Datengitter werden asynchron zwischen den Verarbeitungseinheiten synchronisiert. Dadurch haben alle Einheiten stets Zugriff auf eine lokale Kopie der Daten, was die Zugriffszeiten verkürzt und die Leistung verbessert.
Verteiltes Caching:
Beim verteilten Caching wird ein externer Server verwendet, der einen zentralisierten Cache hält.
Lese- und Schreibvorgänge erfolgen synchron zur zentralen Instanz. Dies kann die Konsistenz verbessern, führt jedoch möglicherweise zu längeren Antwortzeiten, da alle Operationen über das Netzwerk zum zentralen Cache-Server geleitet werden müssen.
Zusammenfassung:
Caching-Strategien in Space-based Architekturen, wie repliziertes und verteiltes Caching, bieten unterschiedliche Vor- und Nachteile hinsichtlich Leistung und Datenkonsistenz. Repliziertes Caching fördert die Leistung durch lokale Datenverfügbarkeit, während verteiltes Caching eine zentrale Kontrolle und möglicherweise höhere Datenkonsistenz bietet.
Erkläre Verteilter Bereitstellungsstil: Serviceorientierte Architektur (SOA)
Grundlagen der SOA:
Eine traditionelle serviceorientierte Architektur (SOA) basiert auf unabhängigen Diensten, die durch einen Enterprise Service Bus (ESB) koordiniert werden.
Der ESB orchestriert die Prozessabläufe von Geschäftsdiensten und bietet Funktionen wie Transaktionsmanagement oder Nachrichtentransformation.
Entwicklung und Hauptmotivation:
Die Architekturform entstand in den 1990er Jahren.
Die primäre Motivation hinter SOA war die Wiederverwendung bestehender Dienste bzw. Ressourcen.
Aktuelle Entwicklungen:
Da es heute mehrere dienstbasierte Ansätze gibt, wird dieser Architekturstil auch als ESB- oder Orchestrierungs-getriebene SOA bezeichnet.
Zusammenfassung:
SOA ermöglicht es Unternehmen, bestehende Dienste effizient zu nutzen und durch die Koordination mittels eines ESB komplexe Geschäftsprozesse effektiv zu managen. Diese Architektur unterstützt die Wiederverwendung von Ressourcen und bietet eine robuste Basis für die Integration und Orchestrierung verschiedener Geschäftsdienste.
Erkläre die Dienstarten in ESB-basierten SOA-Systemen
Geschäftsdienste (Business Services):
Diese Dienste sind der Einstiegspunkt für domänenspezifisches Verhalten, das von Geschäftsnutzern definiert wird.
Sie sind nicht durch tatsächlichen Code repräsentiert, sondern eher durch Geschäftsregeln und -prozesse.
Unternehmensdienste (Enterprise Services):
Feingranulare, gemeinsam genutzte Implementierungen von Geschäftsfunktionen.
Sie bilden die Bausteine für die gröber granulierten Geschäftsdienste.
Der Schwerpunkt liegt auf der Wiederverwendung dieser Funktionen innerhalb verschiedener Kontexte und Anwendungen.
Anwendungsdienste (Application Services):
Einmalige Implementierungen von Diensten, bei denen die Wiederverwendung nicht berücksichtigt wird.
Die Granularität dieser Dienste kann variieren.
Sie werden von spezifischen Anwendungsteams verwaltet und sind oft eng an die Bedürfnisse dieser Teams angepasst.
Infrastrukturdienste (Infrastructure Services):
Diese Dienste befassen sich mit betrieblichen und bereichsübergreifenden Anliegen.
Sie sind typischerweise in der Verantwortung eines dedizierten Infrastrukturteams, das sich um Aspekte wie Sicherheit, Netzwerkmanagement und Datenverwaltung kümmert.
Zusammenfassung:
In ESB-basierten SOA-Systemen variieren Dienste in ihrer Funktion und Granularität, angefangen bei hochgradig wiederverwendbaren Unternehmensdiensten bis hin zu spezifischen Anwendungsdiensten. Diese Struktur unterstützt sowohl die Wiederverwendung von gemeinsamen Geschäftsfunktionen als auch die spezifische Anpassung an einzelne Teamanforderungen und die Integration von Infrastrukturfunktionen.
Erkläre Nachrichtenfluss in einer ESB-basierten SOA
Grundprinzipien:
In einer ESB-basierten SOA (Service-Oriented Architecture) erfolgt der gesamte Nachrichtenfluss über den Enterprise Service Bus (ESB).
Funktionen des ESB:
Der ESB fungiert als Orchestrator und als Integrationshub, der verschiedene Dienste und Anwendungen innerhalb der Organisation verbindet.
Dienstdefinition und -koordination: Geschäftsdienste werden im ESB als Kombination von Unternehmensdiensten definiert. Diese Definition beinhaltet Prozessflüsse, die beschreiben, wie verschiedene Dienste zur Erfüllung von Geschäftszielen zusammenspielen.
Dienstlokalisierung: Der ESB verfügt über ein internes Dienstregister, das die Lokalisierung spezifischer Dienste ermöglicht. Dieses Register enthält Informationen darüber, wo und wie Dienste innerhalb des Netzwerks erreichbar sind.
Kommunikationsmanagement: Der ESB verwaltet die Kommunikation, indem er festlegt, welche Protokolle und Nachrichtenformate verwendet werden müssen. Diese Aufgabe ist zentral für die Gewährleistung einer effizienten und fehlerfreien Datenübertragung.
Nachrichtentransformation: Während des Nachrichtenflusses transformiert der ESB die Nachrichten nach Bedarf, um sicherzustellen, dass sie in einem Format ankommen, das vom Empfängerdienst verarbeitet werden kann.
Zusammenfassung:
Der ESB spielt eine zentrale Rolle in einer SOA, indem er als kritische Schaltstelle für die Koordination, Integration und das Management des Nachrichtenflusses zwischen verschiedenen Diensten dient. Er optimiert den Nachrichtenfluss durch Transformationen und gewährleistet die korrekte Anwendung von Kommunikationsprotokollen, wodurch die Integration verschiedener Geschäftsprozesse und -dienste innerhalb der Organisation erleichtert wird.
