Architekturkonzepte

Nachdem wir aus Ländern und Kontinenten bestehende Anwendungslandschaften kennengelernt haben und wissen, dass die Plattform von Geschäftsprozessen "bevölkert" wird, die WebServices und Events nutzen, schauen wir uns etwas genauer an wie das funktioniert.

Im Detail und technischer erläutert der Architektur-Track die softwaretechnische Realisierung. In diesem Track - CS in a Nutshell - stellen wir die zugrundeliegenden Konzepte möglichst allgemeinverständlich vor.

Werfen wir nun einen Blick "unter die Erde" um zu verstehen, wie Länder aufgebaut sind.

Länder - der größte Teil ist unter der Erde

Für Geschäftsprozesse sichtbar sind nur die Oberflächen der Länder, die Service-Fassaden sowie Webservices und Events zur Verfügung stellen (im Bild also der Blick von "oben"). Die Implementierung liegt in den Schichten darunter. Die Applikationslogik beinhaltet die Implementierung der Geschäftslogik, und steuert die darunter liegende Persistenz-Schicht. Jedes Land verfügt über ein eigenes DB-Schema.
Diese Struktur ähnelt bekannten 3-Schicht Modellen, wobei an die Stelle des UIs die Service-Fassade getreten ist. Jedes Land ist strikt unabhängig von anderen Ländern implementiert, was die Grundlage der Rekombinationsmöglichkeit von Ländern zu Anwendungslandschaften ist. Eine solche Architektur wird auch als "Microservice Architecture" bezeichnet.

Service Bus - die zentrale Vermittlungsstelle

Wir haben bisher verschwiegen, dass Service-Aufrufer nicht direkt den Ziel-Service ansprechen sondern lediglich die Kennung eines jeweiligen Ziel-Services nutzen. Dies stellt eine sinnvolle Entkopplung von Service-Aufrufern und Services dar.
Über den Services und Events liegt im Bild der Service Bus, die zentrale Vermittlungsstelle des Systems. Sucht ein Geschäftsprozess einen aufzurufenden Service (genauer gesagt dessen Endpunkt) nutzt er die zentrale Vermittlungsstelle der Plattform, den Service Bus. Dieser verfügt über eine Service-Registry, ein Verzeichnis in dem alle Services registriert sind und einen Service-Broker, der die Anfragen nach Services behandelt. Dies vereinfacht die Kommunikation in der Anwendungslandschaft erheblich, da nicht jeder Prozess (Service-Nutzer) selbst über das Wissen bzgl.der Erreichbarkeit der für ihn relevanten Services verfügen muss. Dies würde zu erheblichen Redundanzen im System führen und die Aktualisierung erschweren, wenn ein Service mal seine Adresse ändert. Verbindungen können so dynamisch auf- und abgebaut werden.

Architektur: Service Bus

Business Events - das Hollywood-Prinzip

"Don´t call us, we call you." Bei Business Events - d.h. bei Events über Bausteine hinweg - erfolgt die Nachrichtenübermittlung in umgekehrter Richtung. Ist ein Prozess an Nachrichten interessiert, die aus einem Land kommen, kann kann es diese Nachrichten abonnieren, d.h. es registriert sich beim Service Bus oder genauer gesagt bei einer speziellen Komponente des Service Bus, dem Message Bus. Diese Komponente ist für die Verteilung von Nachrichten auf der gesamten Plattform zuständig. Der Message Bus weiß, welche Abonnenten (Subscriber) für den Empfang von Nachrichten eines Landes (Publisher) registriert sind. Veröffentlicht ein Land eine Nachricht, wird diese an alle Abonnenten weitergeleitet (Publish-Subscribe). Ist eine Komponente mal nicht empfangsbereit, speichert der Message Bus die Nachrichten für diesen Abonnenten zwischen und versucht die Zustellung in vorgegebenen Intervallen erneut. Waren alle Versuche nicht erfolgreich, wird die Nachricht in der Vermittlungsstelle eingelagert. Solche gestrandeten Nachrichten werden als Dead Letter bezeichnet. Operatoren der Plattform können dann entscheiden, ob ein erneuter Zustellungsversuch unternommen werden soll oder die Nachrichten entfernt werden (ggf. gibt es den Empfänger ja nicht mehr).

Architektur: Messaging

Geschäftsprozesse

Geschäftsprozesse können in Schleupen.CS aus mehreren Abschnitten zusammengesetzt sein. Ein Abschnitt kann ein im Hintergrund laufender Workflow oder ein Dialogablauf mit Benutzerinteraktion sein. Diese Abschnitte können sequentiell hintereinander laufen oder auch geschachtelt werden (z.B. untergeordneter Dialogablauf im Bild). Dies erlaubt eine Wiederverwendung von Prozessen (Abschnitten). Prozesse werden entweder (wie im folgenden Bild) durch Anwender im Portal (Dialogstartmenü), den Jobserver oder als Reaktion auf das Auftreten eines Events gestartet.

Grundsätzlich unterscheidet die Plattform zwei mögliche Arten von Prozessabschnitten:

• Dialogabläufe sind UIs der Prozesse und ermöglichen die Interaktion eines Anwenders. Dialogabläufe bestehen aus einer oder mehreren Dialogseiten. Die Seiten eines Dialogablaufs können zu geführten Interaktionen zusammengestellt werden (Assistenten, Wizards).
• Workflows sind die im Hintergrund laufenden Teile eines Prozesses. Hier findet der automatisierte Teil der Verarbeitung statt.
  

Aufgrund von Unschärfen bei der Abgrenzung des Begriff "Geschäftsprozess" verwenden wir häufig den neutraleren Begriff "Prozess" für Abläufe, die auf der Plattform ausgeführt werden.

Zur Steigerung der Effizienz setzt Schleupen.CS, als konsequent prozessorientiertes System, auf Automatisierung. Im Gegensatz zu entscheidungsbasierten Systemen läuft der Prozess im System und nicht vor dem Bildschirm in den Köpfen der Anwender ab. Aber was passiert, wenn dabei mal etwas schief geht? Wie kann man sich sicher sein, dass "es läuft"?

Architektur: Geschäftsprozesskomponenten