Methodik für den Bausteinentwickler   

Jeder Bausteinentwickler  sollte bei der Erstellung von Bausteinen nach der folgenden Methodik verfahren, um Bausteine zu erzeugen, die die oben beschriebene Managementlösung unterstützen:

Zunächst ist zu entscheiden, ob der zu erstellende Baustein überhaupt eine spezielle Instrumentierung benötigt. Dies ist nur für Oberflächen- und aktive Bausteine der Fall. Andere Bausteine als die oben angegeben erfordern keinerlei spezielle Managementinstrumentierung, können aber optional instrumentiert werden. Je nach Art des Bausteins sind dann die folgenden Schritte durchzuführen:

• Eingabebaustein
  • Identifikation aller BIs des Bausteins, die den Beginn einer BTA  darstellen können.
  • Für jede identifizierte BI:
    • Einfügen einer Variablen (und geeigneter Methoden zum Zugriff auf die Variable), die zum Zeitpunkt der Anwendungserstellung im Rahmen des Customizing des Bausteins mit dem Namen der zugehörigen BTA belegt werden kann.
    • Einfügen von startBTA unmittelbar nach Entgegennahme der BI und removeControlFlow unmittelbar vor einer Rückkehr des Kontrollflusses zur Oberfläche. Diese Aufrufe dürfen nur dann erfolgen, wenn vom Anwendungsentwickler die zugehörige Variable gesetzt worden ist, die BI also tatsächlich den Beginn einer zu überwachenden BTA darstellt. Falls möglich, soll der Aufruf von removeControlFlow Information über die erfolgreiche bzw. nicht erfolgreiche Ausführung der zugehörigen Subtransaktion enthalten.

  Das in Abbildung  dargestellte Code-Segment zeigt am Beispiel eines JavaBeans Buttons, welche Anpassungen erforderlich sind. Die einzufügenden Zeilen sind durch fetteren Druck hervorgehoben.

  
  

   

  Abbildung: Beispiel für die Instrumentierung eines Eingabebausteins 

  34#34

  
  

  Zunächst muß eine private Variable angelegt werden, die den Namen der gestarteten BTA enthalten kann. In diesem Fall soll die BI mouseReleased des Buttons instrumentiert werden, also das Loslassen des Buttons mit der Maus. Dies stellt typischerweise die BI dar, die bei einem Button zum Start einer BTA führt. Es wird also eine Variable mouseReleasedBTA vom Typ String angelegt, sowie (nach JavaBeans-Konvention) die beiden Methoden getMouseReleasedBTA und setMouseReleasedBTA zum Auslesen und Setzen der Variable durch die Entwicklungsumgebung.

  Innerhalb der Methode mouseReleased wird mit Hilfe des Aufrufs von fireAction das eigentliche Event ausgelöst. Direkt vor Aufruf von fireAction wird folglich startBTA eingefügt und der Name der gestarteten BTA als Parameter übergeben. Der Aufruf von fireAction findet in einer try/catch-Umgebung statt. Nach Rückkehr von diesem Aufruf hat der Kontrollfluß die Bearbeitung der BTA sicher verlassen und es kann removeControlFlow aufgerufen werden. Je nachdem, ob eine Exception auftrat oder nicht, wird Success oder Failure übergeben. Diese Aufrufe finden nur statt, wenn vom Anwendungsentwickler für mouseReleasedBTA eine Belegung definiert wurde, die Überwachung für diese BI also gewissermaßen aktiviert wurde.

• Präsentationsbaustein
  • Identifikation aller BIs des Bausteins, die das Ende einer BTA  darstellen könnten
  • Für jede identifizierte BI:
    • Einfügen einer Variablen vom Typ boolean (und geeigneter Methoden zum Zugriff auf die Variable), die zum Zeitpunkt der Anwendungserstellung im Rahmen des Customizing des Bausteins mit dem Wert true belegt werden können.
    • Einfügen von stopBTA unmittelbar vor Beginn der jeweiligen BI. Dieser Aufruf darf nur dann erfolgen, wenn die zugehörige Variable auf true gesetzt wurde.
  Die Instrumentierung von Präsentationsbausteinen erfolgt also analog zur Instrumentierung von Eingabebausteinen.
• aktiver Baustein
  • Erweiterung aller Methoden, über die ein Auftrag an einen aktiven Baustein erteilt werden kann. Folgende Schritte sind innerhalb dieser Methoden durchzuführen:
    • Aufruf von initiatedTA um dem Meßobjekt die Auftragserteilung bekanntzugeben. Im Falle aktiver Bausteine handelt es sich um einen asynchronen Anstoß einer Subtransaktion, was mit Hilfe des Parameterwertes async übermittelt wird.
    • Speicherung des als Rückgabewert erhaltenen Identifikators gemeinsam mit der Information über den zu erledigenden Auftrag.
  • Erweiterung der Auftragsbearbeitung:
    • Aufruf von startTA zu Beginn der Auftragsbearbeitung. Als Parameter muß der zuvor gespeicherte Identifikator der aufrufenden Transaktion übergeben werden.
    • Aufruf von removeControlFlow zum Ende der Bearbeitung des Auftrags um anzuzeigen, daß der Kontrollfluß die Bearbeitung der BTA wieder verlassen hat und die Subtransaktion  beendet wurde. Wiederum ist die Angabe des Erfolgs bzw. Mißerfolgs der Bearbeitung möglich.
  Der einzufügende Code wird wiederum durch die schwarz gedruckten Zeilen des in Abbildung  dargestellten JavaBeans-Beispiels verdeutlicht.
  
   

  Abbildung: Beispiel für die Instrumentierung eines aktiven Bausteins 

  35#35

  
  In diesem Beispiel wird davon ausgegangen, daß der aktive Baustein Aufträge als Parameter des Aufrufs erteileAuftrag entgegennimmt. In dieser Methode ist ein Aufruf von initiatedTA einzufügen und der Rückgabewert zu speichern. Neben dem Abspeichern des Auftrages in der Warteschlange muß nun dieser Rückgabewert ebenfalls in der Warteschlange gespeichert werden.

  Die Methode bearbeiteAuftrag läuft in einem anderen Kontrollfluß und wird in regelmäßigen Abständen aktiviert, um die Warteschlange auf Aufträge zu überprüfen. Ist ein Auftrag vorhanden, so muß zusätzlich dessen zuvor gespeicherter Identifikator ausgelesen werden. Dann muß vor der eigentlichen Bearbeitung des Auftrags ein startTA-Aufruf und nach Beendigung der Bearbeitung ein removeControlFlow-Aufruf (im Beispiel mit Parameter ,,Success``) eingefügt werden. Der startTA-Aufruf erhält dabei (neben dem üblichen Bausteinnamen sowie einem Identifikator der Bausteininstanz) den Identifikator der Transaktion als Parameter.

Darüber hinaus wird kein zusätzlicher Aufwand vom Bausteinentwickler  gefordert. Selbstverständlich sind auch beliebige Kombinationen der beschriebenen Bausteinklassen denkbar, also z.B. aktive Präsentationsbausteine ober kombinierte Eingabe- und Präsentationsbausteine.

Durch Einfügen von logInfo-Aufrufen in beliebige Bausteine ist es optional möglich, weitere Information (z.B. interne Fehlerzustände) zu übermitteln. Diese können beliebig eingefügt werden und müssen nicht explizit mit einer Transaktion korreliert werden, da dies von der vorgestellten Architektur vollständig transparent erbracht wird.