GEBIT Solutions - Die Experten für IT im Handel

Technische Komponenten

Technische Komponenten der GEBIT Retail Platform sind für ein technisches, nicht-funktionales oder allgemein infrastrukturelles Thema zuständig und stellen für dieses die benötigten Funktionen und ggf. Daten bereit.

Eine solche Komponente wird nicht direkt von Endbenutzern verwendet, sondern ist ein Teil des "Backends" bzw. der allgemeinen Infrastruktur der Anwendungslandschaft. Technische Komponenten können genau wie fachliche Komponenten untereinander Kommandos, Events und allgemein Daten über den Event-Bus austauschen. Sie können aber im Gegensatz zu diesen auch eine andere Struktur aufweisen bzw. selbst Bausteine zur Konstruktion fachlicher Komponenten sein.

Technische Komponenten können je nach Art technisch unabhängig von den anderen technischen Komponenten sein und dann auch getrennt von diesen weiterentwickelt und veröffentlicht werden.

 

 

Event Bus

Der Event-Bus ist das Bindeglied zur Kommunikation zwischen den Komponenten der Anwendungslandschaft (s. Business Components). Er existiert auf verschiedenen organisatorischen Ebenen und kann durch unterschiedliche Produkte realisiert werden.

Die grundlegende Charakteristik des Event-Busses ist durch folgende Punkte gegeben:

Event-basiert: Komponenten reagieren auf Ereignisse in ihrer Umgebung und lösen daraufhin Geschäftsprozesse aus. Diese führen zu weiteren Ereignissen, die in Komponenten empfangen werden. Dieses Architekturmuster führt zu einer losen Kopplung der Komponenten, so dass diese unabhängiger voneinander werden verglichen mit einer Architektur, in der sich die Komponenten direkt aufrufen. Das wiederum hat einen positiven Einfluss auf die Wartbarkeit und somit die Fähigkeit, Komponenten schnell um neue Funktionen zu erweitern.

Asynchron: der Nachrichtenaustauch zwischen Komponenten erfolgt asynchron, also nebenläufig, ohne dass i.d.R. ein Aufrufer auf die Erledigung einer gestellten Aufgabe wartet. Diese Architektur führt zu einer sehr hohen Skalierbarkeit und Modularisierung der Anwendungslandschaft. Das Anwendungsdesign muss bzw. sollte allerdings auch darauf abgestimmt sein, um die Vorteile dieser Architektur auch voll auszunutzen. Bei neueren Entwicklungen und Frameworks ist dies i.d.R. bereits gegeben. Alle Komponenten der GEBIT Retail Platform sind von vornherein für diese Architektur konzipiert worden.

Die transaktionale Konsistenz des Gesamtsystems unterliegt den Gesetzen hoch verteilter Systeme, die asynchron miteinander kommunizieren. Das bedeutet z.B., dass eine fachliche Transaktion, die mehrere Komponenten beinhaltet, nicht wie in einem monolithischen System in einer einzigen relationalen Datenbank "committed" wird, sondern die Konsistenz aller verteilten Daten, die teilweise auch redundant vorliegen, stellt sich "letztendlich" ein (eventual consistency). In der Praxis heisst das, dass dies i.d.R. einige Millisekunden, auch hundertstel Sekunden und in sehr seltenen Fällen auch bis hin zu einigen wenigen Sekunden beanspruchen kann. Während dies natürlich zunächst nicht wie ein Vorteil gegenüber einem monolithischen System aussieht, muss man aber in Betracht ziehen, dass die Realität heutiger Systeme auch bereits diesen Gesetzmäßigkeiten unterliegt, in dem z.B. verschiedene zentrale und dezentrale Systeme Daten austauschen bzw. synchronisieren. Indem eine Softwarearchitektur wie die GEBIT Retail Platform dies von vornherein berücksichtigt bzw. selbst keine höheren Ansprüche an die transaktionale Konsistenz stellt, ist sie für die heutige und zukünftige Welt hochverteilter und teilweise autonomer Systeme sehr gut aufgestellt.

Mehrere Event-Busse

Technisch gesehen kann und wird es i.d.R. mehr als einen Event-Bus geben: der gleiche Event-Bus, also das gleiche Produkt, könnte mehrfach in verschiedenen Lokationen installiert sein. Oder es gibt ein Produkt in der oder den Zentrale(n) und ein "leichtgewichtigeres" Produkt für den Einsatz in den Märkten oder innerhalb einzelner Devices.

Die Lokationen können auf einer organisatorischen Ebene liegen (z.B. mehrere Zentralen bzw. Data Center) oder auch auf untergeordneten Ebenen wie z.B. in jedem einzelnen Store oder auch noch einmal in Devices wie stationären POS-Systemen, um z.B. eine grundlegende Offline-Fähigkeit bestimmter Prozesse zu gewährleisten. Die konkrete Ausgestaltung ist von den individuellen Anforderungen abhängig und wird daher durch die GEBIT Retail Platform nicht vorgegeben.

Grafik: Verteilung von Event-Bussen...

Grafik: Die allgemeine Situation der Verteilung von Event-Bussen - auf den verschiedenen Ebenen - unter "maximalen" Annahmen.

 

 

Reactive Event Bus Adapter (REBA)

Der Reactive Event Bus Adapter (REBA) erlaubt die Verwendung des Event-Busses und somit den Zugriff auf sämtliche vorhandenen Business Components (Anwendungen oder fachliche Komponenten) über eine einheitliche Schnittstelle (API). Die API liegt in mehreren Technologie-Varianten vor:

  • REST API (Remote)
  • Java API (In-process)
  • Weitere API-Varianten können bei Bedarf hinzugefügt werden

Der REBA erlaubt zur Dienstnutzung:

  • das Senden von Commands (Kommunikationsbausteine) an andere Business Components, z.B. createCustomer oder checkInCustomer and die Customer-Komponente.
  • das Empfangen / Abbonieren von Events (Kommunikationsbausteine), die von anderen Business Components ausgesendet werden, z.B. customerCreated oder customerCheckedIntoStore.

und zur eigenen Diensterbringung:

  • das Empfangen von Commands, die von anderen Business Components angefordert werden.
  • das Senden von Events, so dass andere Business Components diese empfangen können.

Die Nachrichtenformate für Commands und Events inkl. der Adressierung der Komponenten sind durch den REBA standardisiert und in ihrer Struktur generisch. Die konkreten Ausprägungen (Namen und Inhalte der Commands und Events) werden durch die jeweiligen Komponenten festgelegt und dokumentiert.

Sämtliche Operationen laufen asynchron; das zu Grunde liegende Prozess- und somit auch Programmiermodell ist reaktiv. Je nach gewählter Technologie-Variante für die API des REBA können Events z.B. über die REST API gepollt werden (analog einem Feed) oder werden im Rahmen des jeweiligen Frameworks direkt an definerte Endpunkte (Callbacks) zugestellt.

Der REBA bietet die notwendigen technischen Garantien über den Versand und Empfang von Commands und Events (insbesondere at-least-once Zusstellung), wobei man als verwendende Komponente unabhängig von der technischen Realisierung des darunter liegenden Event-Busses bleibt und sich auch um die komplexen Verteilungsaspekte einer typischen Retail-Landschaft normalerweise nicht kümmern muss.

Auf der Provider-Seite des REBA, also zum konkret verwendeten Event-Bus hin, existieren ebenfalls mehrere Technologie-Varianten für verschiedene einsetzbare Event-Bus-Technologien bzw. Messaging-Systeme, u.a.

  • Apache Kafka
  • Eclipse Vert.x
  • Akka
  • Spezielle Implementierungen zu Testzwecken
  • Weitere Implementierungen können bei Bedarf hinzugefügt werden

Natürlich können Business Components alternativ auch direkt mit dem konkret verwendeten Event-Bus kommunizieren, um ggf. spezielle Features oder Eigenschaften der jeweiligen Technologie auszunutzen. Für diesen Fall stellt die Retail Platform Best Practices bereit, um den Geschäftscode der Komponente von der technischen Anbindung an den Event-Bus sauber zu trennen.