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

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