Korrelation mehrerer Kontrollflüsse

Sind mehrere Kontrollflüsse an der Erbringung einer BTA  beteiligt, so müssen dem Managementsystem die Identifikatoren aller beteiligten Kontrollflüsse bekannt sein. Da zu einem bestimmten Zeitpunkt jeder Kontrollfluß nur an der Bearbeitung einer einzigen Instanz einer BTA  beteiligt sein kann, ist dies bereits ausreichend, um alle beteiligten Subtransaktion en eindeutig ihrer jeweiligen BTA  zuordnen zu können.

Entlang der in Abbildung  angegebenen Varianten der Erbringung von BTA s wird im folgenden untersucht, wie die Zuordnung der Subtransaktion en im Falle mehrerer beteiligter Kontrollflüsse erfolgen kann.

• Start neuer Kontrollflüsse [Start neuer Kontrollflüsse mittels Bibliothek]Start neuer Kontrollflüsse mittels Bibliothek   [r]
  
  [width=0.98]StartKontrollfl
  
  
  Der Start neuer Kontrollflüsse erfolgt durch einen Systemmechanismus. Dieser wird gewöhnlich von einer speziellen Bibliothek des Systems aufgerufen, die den eigentlichen Systemaufruf vor der Anwendung verschattet. Der Aufruf der Bibliothek erfolgt innerhalb des aktuellen Kontrollflusses. Somit ist an dieser Stelle sowohl der Identifikator des alten als auch der Identifikator des neuen Kontrollflusses bekannt (siehe Abbildung ). Übergibt man diese Informationen an das Managementsystem, so wird es in die Lage versetzt, den neuen Kontrollfluß ebenfalls der entsprechenden BTA  zuzuordnen. Es ist also eine Instrumentierung der Bibliothek für den Start neuer Kontrollflüsse erforderlich, durch die die gewünschten Informationen an die Managementsysteme übermittelt werden.

  Findet der Start des neuen Kontrollflusses nicht innerhalb eines Bausteins, sondern in der Anwendungslogik  statt, so ist zu untersuchen, inwiefern die oben beschriebene Technik ausreicht, um die Korrelation der Kontrollflüsse zu gewährleisten: Die Anwendungslogik  wird zunächst sicher im Kontrollfluß des aufrufenden Bausteins ausgeführt, unabhängig davon, ob es sich z.B. tatsächlich um einen asynchronen Aufruf eines Bausteines oder einen Event-basierten Aufrufmechanismus handelt. Der Start des neuen Kontrollflusses findet somit ebenfalls sicher im Kontrollfluß des aufrufenden Bausteins statt; die oben beschriebene Instrumentierung der Bibliothek für die Erstellung neuer Kontrollflüsse ist somit auch in diesem Falle geeignet, um die Zuordnung herzustellen.

  Ebenso wie der Start eines Kontrollflusses kann auch dessen Ende durch Erweiterung des entsprechenden Mechanismus ermittelt und an das Managementsystem übermittelt werden. Start und Stop von Kontrollflüssen sind gleichzeitig als Start und Stop einer Subtransaktion zu betrachten.

• Aufruf aktiv er Bausteine

  Neben dem Start neuer Kontrollflüsse ist der Aufruf aktiver Bausteine die zweite Variante, wie weitere Kontrollflüsse an der Erbringung einer BTA  beteiligt werden können. Ein aktiv er Baustein ist hierbei ein Baustein, der über einen eigenen Kontrollfluß verfügt und der z.B. in regelmäßigen Abständen überprüft, ob ein Auftrag zur Bearbeitung vorliegt. Das Erteilen eines Auftrages erfolgt durch den Aufruf einer entsprechenden Methode des aktiv en Bausteins, die beispielsweise die zu bearbeitenden Daten in eine Warteschlange einreiht. Andere Formen der Kommunikation, z.B. über gemeinsamen Speicher sind aufgrund der getroffenen Voraussetzungen über die Kommunikation zwischen Bausteinen nicht möglich.

  Abbildung  veranschaulicht die Abläufe beim Aufruf eines aktiv en Bausteins. Aus darstellungstechnischen Gründen wurde eine explizite Warteschlange für die Aufträge eingeführt; diese kann aber ebenso Teil des aktiv en Bausteins sein. Um einen Auftrag an einen aktiv en Baustein zu erteilen, ruft ein Client-Baustein eine entsprechende Methode der Warteschlange auf, die somit im Kontrollfluß des Clients ausgeführt wird. Zu beliebigen, nicht vorherbestimmbaren Zeitpunkten überprüft der aktiv e Baustein, ob Aufträge in der Warteschlange vorliegen. Ist dies der Fall, so beginnt er mit der Bearbeitung des jeweiligen Auftrags.

  
  

   

  Abbildung:  Vollständige Entkoppelung der Kontrollflüsse im Falle aktiver Bausteine

  27#27

  
  

  Die Problematik, die sich hierbei ergibt, ist die vollständige Entkoppelung der beteiligten Kontrollflüsse. Zum Zeitpunkt der Auftragsbearbeitung durch den aktiv en Baustein ist es nicht mehr ohne Instrumentierung des Bausteins möglich zu entscheiden, welcher BTA  die Subtransaktion  zuzuordnen ist, da sich in der Warteschlange Daten unterschiedlicher BTA s zur Bearbeitung befinden können (Eine Lösung für diese Problematik wird in Abschnitt  angegeben).