MID GmbH

              Leistungen          Kundenservice          Downloads            Unternehmen

Model Driven Transformation for Streaming Applications - Teil 4

Event Driven Streaming Architektur

Was wir bisher zu dem Thema veröffentlicht haben finden Sie hier:

Teil 1 Teil 2 - Teil 3 - zu Model Driven Transformation for Streaming Applications

In diesem aktuellen Beitrag beschreiben wir den technischen Rahmen für die Software-Entwicklung – die Software Architektur.

Die Challenge/Vision:

Für das erfolgreiche Design der Software Architektur sind neben den nicht-funktionalen Anforderungen unter anderem auch funktionale Anforderungen, wie das Datenaufkommen, die bestehenden oder zukünftigen Geschäftsprozesse, sowie der Systemkontext wichtige Architekturtreiber. Für die hier vorgestellte Software Architektur sind folgende funktionale Anforderungen definiert worden:

  • Unterstützung von komplexen, ereignisorientierten (even-driven) Geschäftsprozessen
  • near-realtime Verarbeitung von Event- bzw. Datenströmen
  • Anbindung von REST-Services
  • Synchrone und asynchrone Kommunikation
  • Lose Kopplung von Komponenten
  • Unterstützung von Datentransformationen

Unsere Lösung:

Zwei wesentliche Faktoren bei den oben aufgezählten funktionalen Anforderungen sind die Events und die Services mit synchroner und asynchroner Kommunikation. Damit steht der Fokus zum einen auf die ereignisgesteuerte und zum anderen auf die serviceorientierte Architektur unter Berücksichtigung des Data Streamings.

Als skalierbare, hochperformante Event/Data Streaming Plattform ist Apache Kafka gesetzt. Aus mehreren Gründen: Skalierbarkeit, Performance, Fehlertoleranz und Entkopplung. Durch Apache Kafka ist es möglich Eventströme von Drittsystemen problemlos zu empfangen, schnell zu verarbeiten und weiterzuleiten.

Ein Event wird von einem Event-Producer in einen Event-Channel eingespeist damit es von einer Consumer-Applikation verarbeitet werden kann. Kennzeichen des event-driven Ansatzes ist es, dass die Producer-Applikation nicht erwartet, dass die Consumer-Applikation „sofort“ reagiert, also blockiert ist, solange die Consumer-Applikation nicht reagiert (asynchrone statt synchroner Kommunikation). In vielen Geschäftsprozessen erwartet eine Producer-Applikation jedoch früher oder später eine Antwort (Bestätigung und/oder Rückweisung des gesendeten Events) und muss darauf reagieren. Die Antwort ist also selbst wieder ein Event, dass von der ursprünglichen Consumer-Applikation an die ursprüngliche Producer-Applikation geht. Aufgrund der Asynchronität kann hierbei nicht von einer echten Real-Time-Antwort gesprochen werden, jedoch kann bei geeigneter Konfiguration des Regelwerks eine schnelle Antwort erwartet werden (near-realtime). Es sind natürlich auch Anwendungsszenarien denkbar, bei den mehr als eine Applikation im Spiel ist.

Gerade durch die Digitalisierung kommen zunehmend komplexere Prozesse ins Spiel, bei denen eine Vielzahl von Applikationen (Microservices, Sensoren, horizontal und vertikale integrierte Systeme, etc.) zusammenspielen, so dass ein Event durch eine ganze Kette von Applikationen verarbeitet werden bzw. Applikationen aus einem Event Nachfolgeevents generieren und diese weitergeben. Die Consumer werden gleichzeitig wieder zu Producer. Die Events selbst können zudem aus komplexen Daten bestehen. Diese Daten, größtenteils mit gleicher fachlicher Bedeutung, können von verschiedenen Applikationen unterschiedlich interpretiert und dargestellt werden. Es ergibt sich also die Notwendigkeit die Daten, je nach Verwendungsszenario, zu transformieren.

Für die Software Architektur sind nun folgende Komponenten identifiziert:

  • Producer-Applikation (Spring-Framework, REST-Service)
  • Consumer-Applikation mit Datenbank (Spring-Framework, REST-Service)
  • Streaming Plattform (Apache Kafka)
  • Transformation-Applikation (StreamMapper)

Die Schnittstellen und somit auch die Kommunikation zwischen den einzelnen Komponenten sind maßgeblich von den Vorgaben und dem Regelwerk der Streaming Plattform abhängig. In Abbildung 1 wird das Zusammenspiel der Komponenten nun deutlich gemacht.

 

 

Detailliertere Einblicke in die einzelnen Komponenten und das Zusammenspiel zwischen diesen, sowie die dazugehörige Modellierung erhalten Sie in den nachfolgenden Blogbeiträgen.

Weiterlesen:

Im folgenden Blog-Beitrag wird es um die Modellierung der Eingangs- und Ausgangs-Datenstrukturen sowie um die Daten-Transformation gehen.

Johannes Mickel

geschrieben von Johannes Mickel

Beschäftigt sich seit 2011 mit Software Architekturen für Industrie und im öffentlichen Dienst. Seit 2015 ist er für die MID GmbH als Senior Consultant für den Bereich Software Architektur und Requirements Engineering tätig.

<< Zurück

Relevante Posts:

MID Blog

Hier bloggen Mitarbeiter der MID und eingeladene Gastautoren zu Themen rund um die Modellierung. Bleiben Sie auf dem Laufenden und lassen Sie sich per Email über neue Blogbeiträge informieren.

Neue Beiträge per Mail

Autoren

Interessieren Sie sich für ein Thema, dass wir bisher noch nicht behandelt haben? Oder haben Sie Fragen oder Anmerkungen zu einem bestimmten Beitrag?

Schreiben Sie uns gerne einen Kommentar, wir werden das Thema in der Zukunft aufgreifen.

Die neuesten Posts

MID Newsletter abonnieren