Bewertung

  Der vorgeschlagene Ansatz basiert auf einer Managementinstrumentierung  der Basisbausteine. Die Abhängigkeiten zwischen den einzelnen Bausteinen eines zusammengesetzten Bausteins werden zum Zeitpunkt der Anwendungserstellung  in einem Strukturgraphen statisch festgelegt. Die Korrelation der Informationen der darunterliegenden Bausteine erfolgt bereits im Baustein und nicht in einer speziellen Managementanwendung. Dieser Ansatz hat sich im Laufe der durchgeführten Untersuchungen als nur bedingt geeignet für die Überwachung bausteinbasierter Anwendungsdienst e erwiesen. Dies liegt insbesondere an der statischen Beschreibung der Abhängigkeiten innerhalb der Anwendung bereits zum Zeitpunkt der Anwendungserstellung, aber auch an dem immer noch erheblichen Aufwand für Baustein- und Anwendungsentwickler  und der eingeschränkten Flexibilität der Lösung. Im folgenden wird eine detaillierte Bewertung des vorgestellten ersten Ansatzes vorgenommen:

• Beschreibung der Abhängigkeiten
  Die Beschreibung der Abhängigkeiten und Zusammenhänge innerhalb der zu überwachenden Anwendung erfolgt bei diesem Ansatz statisch zum Zeitpunkt der Anwendungserstellung. Dies erweist sich allerdings als schwierig. Anwendungen durchlaufen z.B. je nach Benutzereingabe unterschiedliche Zweige und aus Gründen der Lastverteilung und Redundanz können mehrere Instanzen desselben Bausteins existieren. Es ist somit zum Zeitpunkt der Anwendungserstellung  im allgemeinen nicht möglich, einen Strukturgraphen anzugeben, der die tatsächlichen Abläufe innerhalb der Anwendung hinreichend beschreibt. Diese Information kann erst zur Laufzeit der Anwendung ermittelt werden. Selbst wenn ein Graph angegeben werden kann, der alle Möglichkeiten beschreibt, wie die Anwendung durchlaufen werden könnte, ist es zur Laufzeit der Anwendung dennoch nicht möglich, den für eine konkrete Instanz einer Transaktion relevanten Weg durch den Graphen ohne Instrumentierung der Anwendungslogik zu bestimmen.
• Aufwand
  Durch die Verlagerung des Instrumentierungsaufwandes vom Anwendungsentwickler auf den Bausteinentwickler kann eine erhebliche Reduzierung des Gesamtaufwandes erreicht werden. Dies begründet sich mit der Möglichkeit der mehrfachen Verwendung von Bausteinen in unterschiedlichen Anwendungen, der Verringerung der Komplexität der einzelnen Instrumentierungsaufgaben und der teilweise automatisierbaren und werkzeuggestützten Erstellung der Managementlogik.

  Die Instrumentierung jedes einzelnen Basisbausteins stellt aber dennoch einen erheblichen zusätzlichen Aufwand für den Bausteinentwickler  dar. Das Problem des hohen Instrumentierungsaufwandes, das eines der Haupthindernisse für eine rasche Verbreitung von Instrumentierungstechniken im Anwendungsmanagement darstellt, wird somit nicht gelöst, sondern nur verringert und vom Anwendungsentwickler  auf den Bausteinentwickler  verlagert.

  Auch die schwierige Aufgabe, die Abhängigkeiten der einzelnen Bausteine untereinander zu bestimmen, kann nicht vollständig automatisiert werden. Auch wenn in vielen Fällen die Zusammenhänge automatisch erkannt werden können, müssen dennoch in einer Vielzahl der Fälle Entscheidungen weiterhin vom Anwendungsentwickler  getroffen werden.

• Verfügbare Information
  Durch die Instrumentierung der Bausteine ist es möglich, die geforderte Information vollständig zu ermitteln. Da Bausteine allerdings mehrere unterschiedliche Transaktionen erbringen können, wäre ein Ausweitung des Ansatzes von der Beschreibung der Verknüpfung von Bausteinen auf die Verknüpfung von Transaktionen eines Bausteins erforderlich.
• Zuordnung der Teilinformationen
  Sind zu einem bestimmten Zeitpunkt mehrere Transaktionen gleichzeitig aktiv, so ist bei einer Beschreibung der Abhängigkeiten zum Zeitpunkt der Anwendungserstellung nicht festzustellen, zu welcher der Transaktionen ein Baustein aktuell beiträgt. Somit kann die beschriebene Berechnung nur durchgeführt werden, wenn zu jedem Zeitpunkt nur eine Transaktion ausgeführt wird und keine parallelen Transaktionen existieren. Dies ist in der Praxis in den meisten Fällen so nicht gegeben.

  In vielen Fällen sind Bausteine nicht einer bestimmten Anwendung fest zugewiesen, sondern können von mehreren unterschiedlichen Anwendungen genutzt werden. Die Zuordnung von Managementinformation zu einer übergeordneten Anwendung erweist sich in diesem Fall als besonders schwierig. Die Bausteine müßten in der Lage sein, je nachdem, welcher der übergeordneten Bausteine eine Anfrage durchführt, die jeweils korrekte Information zu liefern. Dies würde zu einer erheblichen Erhöhung der Komplexität der Bausteine führen. Zustandslose Bausteine, die in vielen Bausteinarchitektur en explizit vorgesehen sind, könnten diese Art der Information ohnehin nicht liefern.

• Integration von Legacy-Bausteinen
  Eine Lösung, die eine spezielle Managementinstrumentierung  aller Bausteine erfordert, eignet sich nicht für die Integration von Legacy-Bausteinen, also Bausteinen, die nicht über eine derartige Instrumentierung verfügen. Bausteine ohne entsprechende Schnittstelle können zwar weiterhin zum Einsatz kommen, die Einbeziehung dieser Bausteine in die Überwachung ist dann aber ausgeschlossen. Da in der Praxis nicht davon auszugehen ist, daß sämtliche eingesetzten Bausteine über eine derartige Schnittstelle verfügen werden, ist eine Lösung, die auch die (zumindest eingeschränkte) Überwachung nicht instrumentierter Bausteine gestattet, vorzuziehen.
• Verläßlichkeit der Information
  Insbesondere vor dem Hintergrund der Anwendungserstellung  aus Bausteinen unterschiedlicher - evtl. sogar anonymer - Herkunft ist die Verläßlichkeit der gelieferten Information ein wesentlicher Aspekt. Die gewonnenen Daten werden unter anderem eingesetzt für Zwecke der Abrechnung, aber auch um diejenigen Bausteine zu ermitteln, die ursächlich für eine Fehlfunktion oder den Ausfall eines Dienstes oder einer bestimmten Transaktion sind. Es ist somit nicht auszuschließen, daß vom Baustein übermittelte Informationen z.B. eine häufigere Nutzung des Bausteines vortäuschen, um somit beispielsweise höhere Nutzungsgebühren fordern zu können. Ebenso ist es denkbar, daß eine bessere Performanz angegeben wird, um das Risiko zu verringern, daß der Baustein gegen einen leistungsfähigeren Baustein z.B. eines anderen Herstellers ausgetauscht wird.
• Flexibilität
  Eine Verdichtung der Managementinformation bereits im Baustein schränkt die Flexibilität der Lösung für die Managementsysteme ein. Einer Managementanwendung können somit evtl. nicht mehr die eigentlich benötigten Informationen zur Verfügung gestellt werden, obwohl diese ursprünglich von den darunterliegenden Bausteinen angeboten wurden.
• Präzision der Information
  Durch die Berechnung der Managementinformation aus den Informationen der darunterliegenden Bausteine macht man bei gewissen Informationen zwangsläufig Fehler. Dies begründet sich damit, daß die Anwendungslogik , die die einzelnen Bausteine miteinander verknüpft, nicht in die Berechnung mit eingeht, allerdings einen teilweise nicht unerheblichen Prozentsatz z.B. der Gesamtdauer einer Transaktion oder der verbrauchten Prozessorzeit einnimmt. So kann in dem oben beschriebenen Algorithmus für die Berechnung der Antwortzeit beispielsweise der asynchrone Aufruf eines Bausteins nicht berücksichtigt werden, auch wenn der Aufruf selbstverständlich eine gewisse Zeit in Anspruch nimmt. Hier wäre es erforderlich, zusätzlich zur Instrumentierung der Bausteine, eine Instrumentierung der Anwendungslogik vorzunehmen, so daß die dort anfallenden Informationen ebenfalls mit in die Berechnung einbezogen werden können.