Generator für die Abbildungsvorschrift von Datenstrukturen

Vorwort:

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

Teil 1 - Teil 2 - Teil 3 - Teil 4 -  Teil 5  - Teil 6 - Teil 7 - Teil 8   zu Model Driven Transformation for Streaming Applications

In diesem Blog-Beitrag beschäftigen wir uns mit der Generierung der Datentransformations-Regeln aus dem Innovator-Modell.

Datentransformation vom Producer zum Consumer

Vorwort:

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

Teil 1 - Teil 2 - Teil 3 - Teil 4 -  Teil 5  - Teil 6 - Teil 7 zu Model Driven Transformation for Streaming Applications

In diesem Beitrag beschäftigen wir uns mit dem Daten-Mapping zwischen Producer und Consumer.

Producer und Consumer – die Anbindung der Systeme

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

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

In diesem Betrag beschäftigen wir uns mit dem Aufbau und der Anbindung der Producer- und der Consumer-Applikation.

Unser Labor - Einrichtung der Entwicklungsumgebung

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

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

In diesem Beitrag wird Ihnen die benötigte Entwicklungsumgebung, welche für dieses Projekt zusammengestellt wurde, vorgestellt.

Modellierung der Eingangs- und Ausgangs-Datenstrukturen sowie der Datentransformation

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

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

In diesem Betrag beschäftigen wir uns mit der Struktur des innovator-Modells, aus dem die Datentransformationsregeln generiert werden sollen.

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:

Apache Kafka – Funktionsweise, Doku, API

Was wir bisher zu dem Thema veröffentlicht haben finden Sie hier: Teil 1 und Teil 2

In diesem Betrag beschäftigen wir uns näher mit dem Stream Processing System Kafka.

Was ist Apache Kafka?

Apache Kafka - hat nichts mit Franz Kafkas „Der Prozess“ zu tun, sondern es handelt sich um eine der bekanntesten Streaming Plattformen auf dem Markt. Apache Kafka ist eine verteilte Streaming Plattform und der wohl bekannteste Vertreter der Kappa-Architektur. Kafka ist in der Lage nahezu in Echtzeit eine extrem hohe Anzahl von Daten bzw. Ereignisse in Form eines Datenstromes entgegenzunehmen, zu speichern, zu verarbeiten und bereitzustellen. Apache Kafka ist laut Confluent (https://www.confluent.io/) für zwei Einsatzszenarien am geeignetsten: zuverlässige Echtzeit-Streaming-Datenpipelines und reaktionsschnelle Echtzeit-Streaming-Anwendungen mit Datentransformation.

Fachliches Integrationsszenario und Lösungsansatz mit Kafka

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

In diesem Beitrag beschreiben wir die Gesamtarchitektur unseres Ansatzes auf oberster Ebene.

Die Challenge/Vision:

Aufgrund unserer Erfahrungen und Erkenntnisse bei der Arbeit mit verschiedenen Kunden haben wir als Anwendungsbeispiel zur praktischen Erprobung von Apache Kafka ein übliches Szenario aus der Unternehmenspraxis gewählt, nämlich die Datenübertragung von einem Quell-System (Producer) zu einem Ziel-System (Consumer), wobei die Daten bei ihrer Übertragung einer Transformation unterzogen werden sollen.

Die IT-Landschaft von heute muss sich immer wieder und dazu noch in immer kürzeren Zeitabschnitten an die wachsenden Datenmengen anpassen. Wir schreiben keine Nachrichten mehr, sondern übertragen Voice Messages, hören on Demand Musik über Streaming-Anbieter und schauen Video-On-Demand auf dem Fernseher und von unterwegs. Neue Fahrzeuge haben das Potential bei einem Unfall direkt Kontakt mit der Versicherung für Schadensmeldung aufzunehmen und selbst unser Kühlschrank könnte schon leer gewordene Lebensmittel selbständig nachbestellen. Zudem kommt hinzu, dass dieses Meer an Daten in „Echtzeit“ analysiert, verarbeitet und weitertransportiert werden muss.

Bei der Frage welche Software Architektur für diese Herausforderungen die Richtige ist bzw. welche Komponenten am besten in meine bestehende IT-Landschaft passen, stößt man heutzutage sehr schnell auf die Streaming Architektur und um es noch stärker einzugrenzen auf die Kappa Architektur mit ihrem populärsten Vertreter, der Streaming Plattform Apache Kafka.

Was ich nicht weiß, macht mich nicht heiß

Im Blog-Beitrag zu Innovator 14 und den Neuerungen im Bereich der Konfiguration haben wir uns mit der Möglichkeit beschäftigt, wie zusätzliche Stereotyp-Merkmale in nahezu jedem Profil zu einem Stereotyp hinzugefügt werden können.

Doch wie verhält es sich mit ungewünschten, nicht benötigten Eigenschaften (Labels, Spezifikationstexten (F3-Texte)), Verbindungsmöglichkeiten zwischen Modellelementen sowie die Möglichkeit, Elemente generell anlegen zu können? Oftmals ist das Ziel einer eigenen Modellierungsmethodik, die Modellierung zu vereinfachen und nur diejenigen Elemente mit spezifischen Eigenschaften dem Anwender zur Verfügung zu stellen, die tatsächlich im Kontext des Unternehmens bzw. des Projekts benötigt werden.

Bislang hatten Sie diesbezüglich wenige Möglichkeiten, ungewünschte Stereotypen bzw. deren Eigenschaften aus dem Modell zu entfernen. Sie konnten auch hier entweder nur die Konfiguration der Elemente in den definierenden Profilen anpassen (Stichwort: Updateproblematik bei der Verwendung von Migrationsprofilen – siehe Blog-Beitrag Innovator-Konfiguration leicht gemacht) oder sich wieder eigene Profile mitsamt allen benötigten Elementen anlegen (sehr aufwändig und nicht updatebar ohne manuelle Anpassungen).

Mit Innovator 14 gehört auch dies der Vergangenheit an!