Mandantenfähigkeit (Context) für dWb+

vorhergehende Artikel in: dWb+
26.10.2015

Bereits vor einigen Jahren wurde für dWb+ die Einführung von Mandantenfähigkeit diskutiert. Die damaligen ersten Skizzen der Konzeptionierung und Implementierung werden derzeit wieder aus der Schublade geholt und ihre Implementierung von Neuem diskutiert.

Einleitung

Beim Stichwort Mandantenfähigkeit geht es darum, dass es in datenflussorientierten Umgebungen durchaus so sein kann, dass neben den eigentlichen Daten noch Informationen zu ihrer Entstehung für die Verarbeitungseinheiten weiter hinten in der Verarbeitungskette interessant sein könnten.

Es soll hier zunächst an einigen Beispielen gezeigt werden, wofür eine solche Mandantenfähigkeit nützlich sein kann.

Szenario A - Serverdienst

Dataflow Workbench dWb+ In diesem ersten Szenario geht es um die Umsetzung eines einfachen HTTP-Servers, der basierend auf der abgeforderten URL eine Datenverarbeitung anstößt und das Ergebnis der Datenverarbeitung an den Anfragenden zurückliefern soll. Dabei stelle man sich den Workflow so vor, dass es einen BeanContextService gibt, der die HTTP-Protokollunterstützung liefert. Auf dem Arbeitstisch werden zwei Module abgelegt: HTTP-Sender und HTTP-Receiver. Das Receiver-Modul gibt die empfangene URL an das nächste Modul weiter. zwischen Sender und Receiver sind beliebig viele andere Module geschaltet, die entsprechend der URL verschiedene Arbeitsschritte durchführen, bis wieder ein String entsteht, der über den Sender an den Client zurückübertragen werden soll.

Da aber HTTP ein Protokoll ist, bei dem sich quasi gleichzeitig beliebig viele Clients mit einem Server verbinden können, existiert im beschriebenen Szenario ein Problem: Wenn sich während der Bearbeitung eines Requests bereits vier neue Clients mit dem Server verbinden, weiß das Sender-Modul am Ende nicht mehr, welchem Client es die Antwort zusenden soll. Das könnte man verhindern, indem man 503 (Service Unavailable) an den Client meldet, solange die Bearbeitung des letzten Requestes nicht abgeschlossen ist. Eine solche Lösung wäre arnselig und nicht mehr zeitgemäß.

Wenn man es aber schaffen könnte, mit den eigentlichen Nutzdaten einen Datenspeicher zu verknüpfen, der Daten zum Kontext der Operation enthält, der die Datenverarbeitung angestoßen hat, und diese Information über viele verschiedene Komponenten oder Verarbeitungseinheiten hinweg konsistent bliebe, könnte man im Receiver-Modul die Kennung des Client in den Kontext schreiben. Dieser würde bei jeder Kommunikation zweier Module weitergegeben und das Sender-Modul müsste lediglich in den Kontext schauen, um zu wissen, welchem Client es die in Rede stehende Antwortbotschaft übermitteln soll.

Szenario B - Synchronisation

Das zweite Beispiel ist die Synchronisation, die sich in wenigen Worten wie folgt zusammenfassen lässt: Wenn ein Modul zwei Daten erzeugt und diese über verschiedene Kanäle an unterschiedliche nachfolgende Verarbeitungsketten - also ein oder mehrere gekoppelte Verarbeitungseinheiten - zur Weiterverarbeitung übergibt, ist das ein normales Szenario, das keine besonderen Vorbereitungen bedarf.

Sollen aber die Ergebnisse der beiden Verarbeitungseinheiten am Ende miteinander verschmolzen werden, muss man wissen, welches Ergebnis aus Verarbeitungskette A mit welchem Ergebnis aus der Kette B kombiniert werden soll. Timestamps zur Kennzeichnung der Ergebnisse des ersten Modul fallen aus, da keine zwei Ereignisse in Rechnersystemen wirklich gleichzeitig geschehen. Man muss an die Daten Marker anfügen. Das letzte Modul könnte dann die Marker vergleichen und herausfinden, welche zwei seiner Inputs miteinander kombiniert werden müssten.

Auch hier ist es wieder so, dass diese Marker über die gesamte Kette der Verarbeitungseinheiten konsistent erhalten bleiben müssten.

Szenario C - Transaktionen

Das dritte Beispiel sind Transaktionen, die sich in datenflussgetriebenen Systemen mittels Mandantenfähigkeit wie folgt umsetzen ließen: In diesem Szenario sind die Verarbeitungen in den einzelnen Modulen einer Verarbeitungskette vergleichbar den atomaren Operationen in einer durch eine Transaktion gekapselten Operation. Das erste Atom eröffnet die Transaktion. Jedes weitere Glied in der Kette muss über die geöffnete Transaktion informiert sein, denn im Fehlerfall muss diese zurückgerollt werden. Das letzte Modul in der Kette muss schließlich dafür sorgen, die Transaktion "zu committen" - also die Ergebnisse persistent zu machen. Auch dazu muss es auf Wissen über die laufende Transaktion zugreifen können.

Dieses Szenario ist ebenfalls ein gutes Beispiel für die Nützlichkeit des Konzeptes der Mandantenfähigkeit oder eines globalen Kontextes: Diesmal muss die Information über die Transaktion über die gesamte Kette der Verarbeitungseinheiten konsistent erhalten bleiben.

Artikel, die hierher verlinken

Verschiedene Interaktionsmetaphern in dWb+

18.09.2016

Nach Fertigstellung einiger Module, die die Kommunikation zwischen Komponenten auf Dateiebene unterstützen, werde ich versuchen, verschiedene Interaktionsmetaphern bzw. Kommunikationsstrategien aus anderen datenflussgetriebenen Systemen in dWb+ nachzuvollziehen, um die Effizienz der Implementierung und die Vor- und Nachteile ihrer Anwendung diskutieren zu können.

WebSocket Server in dWb+

08.11.2015

Bereits vor einigen Jahren wurde für dWb+ die Einführung von Mandantenfähigkeit diskutiert. Die aus der Schublade geholte Implementierung wurde nach erfolgreichen Lasttests für die Entwicklung von Servern verschiedenster Art eingesetzt.

Lasttests für Mandantenfähigkeit in dWb+

27.10.2015

Bereits vor einigen Jahren wurde für dWb+ die Einführung von Mandantenfähigkeit diskutiert. Die aus der Schublade geholten Implementierungen wurden nach leichten Änderungen in verschiedenen Szenarien Lasttests unterzogen.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

Neueste Artikel

  • SQL Funktionen in SQLite als BeanShell-Scripts

    Ich habe bereits hin und wieder über Erweiterungen der sQLshell berichtet, die bestimmte spezifische, proprietäre Features des jeweiligen DBMS in der sQLshell verfügbar machen.

    Weiterlesen...
  • Spieleengine IX

    Es gibt seit Ewigkeiten mal wieder Neues von meiner eigenen Spieleengine!

    Weiterlesen...
  • Neue Version plantumlinterfaceproxy napkin look

    Es gibt eine neue Version des Projektes plantumlinterfaceproxy - Codename napkin look.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.