2. Bernd Gewehr
• Bauingenieure
• 750 Mitarbeiter
• 43 Jahre Know-how
• 25 Büros in 5 Ländern
• 12.000 Projekte in 15 Ländern
Leiter der IT-Abteilung
25 Jahre Betriebszugehörigkeit
4 Entwickler in Düsseldorf
3. Konzepte der Software-Architektur
• Anfrage – Antwort
(Request – Response)
Bei diesem Muster kommunizieren die Komponenten synchron durch direkte Anfragen und
Antworten. Es ist einfach zu verstehen und zu implementieren, kann aber zu enger Kopplung
und geringer Skalierbarkeit führen.
Server
REQ/RES
Client
4. Konzepte der Software-Architektur
• veröffentlichen – abonnieren
(publish - subscribe)
Bei diesem Muster kommunizieren die Komponenten asynchron durch Ereignisse über einen
Ereignisbus. Es ist komplexer zu verstehen und zu implementieren, kann aber zu loser Kopplung
und höherer Skalierbarkeit führen.
Ereignis-
Bus
PUB/SUB
Client
PUB/SUB
Server
5. Konzepte der Software-Architektur
• Monolithische Architektur
Applikation
Server
Dienst
Dienst
Dienst
Client REQ/RES Daten
Bei diesem Muster wird eine Anwendung als eine einzige, zusammenhängende Einheit erstellt. Es ist
einfacher zu entwickeln und bereitzustellen, kann aber zu enger Kopplung und Skalierbarkeitsproblemen
führen, wenn die Anwendung wächst.
6. Konzepte der Software-Architektur
• Serviceorientierte Architektur
(SOA)
Dienst-
Verzeichn
is, Dienst-
BUS
PUB/SUB
Dienst
Dienst
Dienst
Client
Server
SOA ist ein architektonisches Muster, das die Verwendung von Diensten, d. h. von in sich geschlossenen
Funktionseinheiten, zur Erstellung von Anwendungen in den Vordergrund stellt. Die Dienste
kommunizieren untereinander über genau definierte Schnittstellen. SOA kann auch verschiedene
Kommunikationsmuster wie Anfrage/Antwort oder Veröffentlichen/Abonnieren verwenden.
7. Konzepte der Software-Architektur
• Microservices-Architektur
Microservices konzentrieren sich auf die Zerlegung von Anwendungen in kleine, unabhängig voneinander
einsetzbare Dienste, die über APIs kommunizieren. Microservices können Kommunikationsmuster wie
Request/Response oder Publish/Subscribe verwenden.
Client
PUB/SUB
Dienst
Dienst
Dienst
Server Foundry
8. Konzepte der Software-Architektur
• ereignisgesteuerte Architektur
Event
BUS
PUB/SUB
Dienst
PUB/SUB Client
PUB/SUB
Dienst
PUB/SUB
Dienst
Server
REQ/RES
Server PUB/SUB
Foundry
Softwareentwurfsmuster, das die Erzeugung, Erkennung und Nutzung von Ereignissen fördert. In diesem
Paradigma wird der Ablauf der Anwendung durch Ereignisse bestimmt, d. h. durch signifikante
Zustandsänderungen oder Aktionen, die innerhalb des Systems auftreten. Diese Ereignisse werden in der
Regel als Nachrichten dargestellt und zwischen verschiedenen Komponenten, über einen zentralen
Ereignis-Bus oder ein Nachrichtensystem ausgetauscht.
Foundry
9. Konzepte der Software-Architektur
ChatGPT: Die Event Driven Architecture (EDA) bietet im Vergleich zu anderen Ansätzen mehrere Vorteile:
1. Lose Kopplung: EDA fördert die asynchrone Kommunikation zwischen Komponenten, wodurch Abhängigkeiten reduziert werden und es einfacher wird,
einzelne Komponenten zu ändern, zu warten und zu skalieren, ohne das gesamte System zu beeinträchtigen.
2. Verbesserte Reaktionsfähigkeit: Da EDA-basierte Systeme auf Ereignisse reagieren, sobald sie eintreten, können sie sich schnell an veränderte
Bedingungen anpassen und eine bessere Reaktionsfähigkeit in Echtzeit bieten.
3. Skalierbarkeit: Die entkoppelte Natur der EDA ermöglicht eine einfache horizontale Skalierung, da neue Ereignisproduzenten und -konsumenten
hinzugefügt werden können, ohne dass dies Auswirkungen auf bestehende Komponenten hat.
4. Widerstandsfähigkeit: EDA-basierte Systeme sind in der Regel fehlertoleranter, da der Ausfall einer Komponente nicht unbedingt zu kaskadenartigen
Ausfällen im gesamten System führt.
5. Verarbeitung in Echtzeit: Die EDA eignet sich gut für die Datenverarbeitung und -analyse in Echtzeit, da sie es den Komponenten ermöglicht, auf
Ereignisse zu reagieren und Daten zu verarbeiten, sobald sie verfügbar sind.
6. Flexibilität: EDA ermöglicht die unabhängige Verarbeitung desselben Ereignisses durch mehrere Verbraucher, so dass verschiedene Geschäftslogiken oder
Verarbeitungsanforderungen parallel implementiert werden können.
Trotz dieser Vorteile ist EDA möglicherweise nicht für alle Szenarien die beste Wahl. Sie kann die Komplexität des Systems erhöhen, erfordert eine sorgfältige
Prüfung der Nachrichtenbehandlung und Fehlerbehebung und ist möglicherweise nicht für Anwendungen geeignet, die eine synchrone Kommunikation oder
sofortige Antworten erfordern. Die Entscheidung für den Einsatz von EDA sollte auf einer gründlichen Analyse der spezifischen Anforderungen, Ziele und
Beschränkungen des Projekts beruhen.
13. Event Driven Architecture in Domino
• Erkenntnisse:
• Anwendungs-Transaktionen führen zu Benachrichtigungen
• Benachrichtigungen wurden z. B. gesendet, indem man
in der Formel der Aktions-Schaltfläche
• Der Vorteil: Einfach zu erstellen, einfach zu konsumieren
• Nachteil:
• App-Entwickler entscheidet über Inhalt, Medium und Verteilung der Benachrichtigung "im
Code".
• Andere Empfänger können nicht entscheiden, ob sie zuhören wollen
14. Event Driven Architecture in Domino
• Beispiele Ereignis-Benachrichtigungsaktionen @vössing:
• Erstellung neuer Dokumente in Datenbanken
• Workflow-Ereignis-Aktionen wie z. B. Freigabe
• Abschluss von Projekten nach Abschluss
• Empfangene oder bezahlte Rechnungen in der
Kreditorenbuchhaltung
• Neue Kommentare zu Datenobjekten
• @Anmerkungen in diesen Kommentaren von Web UI
• Statusänderungen, etc.
15. Event Driven Architecture in Domino
Aktionen
Aktionen
Aktionen
Aktionen
Aktionen
Aktionen
veröffentlichen
• Durch Aktionen ausgelöste Benachrichtigungen @voessing
„Benachrichtigungs-Event-Bus"
16. Event Driven Architecture in Domino
• Ereignisbenachrichtigungskanäle @vössing:
• Feed (in der Mitarbeiter-Selbstbedienungs-App)
• E-Mail (Notes)
• CNX Connections Aktivitätsstrom (CNX Portal)
• Team-Chat oder persönlicher Chat (MS Teams)
• Geplant: Push-Benachrichtigungen mit Volt MX für
native Mobil-/Desktop-Anwendungen
17. Event Driven Architecture in Domino
• Was wäre, wenn...
• Ereignisse als abstrakte Muster definiert werden könnten, die von
Anwendungen ausgelöst werden
• Die Definition von Ereignismustern Benachrichtigungsoptionen für
verschiedene Benachrichtigungskanäle enthalten würde
• Die Nutzer festlegen und verwalten könnten, über welche
Ereignisse sie wann und wie (auf welchem Kanal) informiert werden
möchten.
• Andere Apps können diese Ereignisse auch zu
Automatisierungszwecken abonnieren
18. Event Driven Architecture in Domino
• 1. Erstellen Sie einen Ereigniskategorienkatalog:
Grundlegende Informationen
zur Kategorie
Scopes bieten einen
interessanten Filter für
Benutzer, wie "nur meine
eigenen" oder "für mich
relevante" Ereignisse dieser
Kategorie
Zur Auswahl stehende Kanäle
74
Kategorien
gefunden
19. Event Driven Architecture in Domino
• 2. Erstellen Sie parametrische Benachrichtigungen:
93
Ereignisse
konfiguriert
23. Event Driven Architecture in Domino
• Automatisierung ausgelöst durch Ereignisse @vössing:
„Einkaufs-Event-Bus"
Dienst
Dienst
Dienst
Aktionen
Aktionen
Aktionen
veröffentlichen
24. Event Driven Architecture in Domino
Ereignis "Ende des Leasings“
löst Kaufantrag aus
Einkaufs-Event-Bus
• Durch Ereignisse ausgelöste Transaktionen @vössing:
„Einkaufs-Event-Bus"
Ereignis "Erfolgreiche Löschung“
deaktiviert Inventar
Ereignis Lieferschein
löst den Artikelstatus aus
Ereignis Serieneintrag
löst Installation/
Inventarisierung aus
Ereignis Versand
ändert Gerätestatus
(UPS API)
Ereignis Genehmigung
löst Bestellung aus
Ereignis der
Auftragsbestätigung
ändert Status der
Anfrageposition
auf „bestätigt“
Rechnungs-Ereignis
löst
Datenaktualisierung aus
25. Event Driven Architecture in Domino
• Nächste Schritte für ausgelöste Ereignisse @vössing:
• "Projekt Ereignisbus"
• Neu-Abschluss eines Kunden- oder Lieferantenvertrags löst
Q&A mit dem Projektmanagement für Kommunikations-
/Koordinations-/Inhaltsanforderungen aus
• Das Beenden eines Vertrages verschiebt Inhalte in den
schreibgeschützten Archiv-Bereich und speichert auf
billigerem Speicher, usw.
26. Event Driven Architecture in Domino
• OK. Was ich gerade gezeigt habe, ist nicht die ideale
Form einer ereignisgesteuerten Architektur
• ABER: Ereignisgesteuertes Design hilft bei der
Entwicklung flexibler, lose gekoppelter, skalierbarer
Anwendungen, die sich leicht integrieren lassen - sogar
in Domino
• Vielen Dank für‘s Zuhören!