... oder: Wenn verteilte Applikationen das Weite suchen ...
Client/Server-Systeme und überhaupt jede Art von
verteilten Applikationen haben ihren Vorteil vor allem darin, die
nötige Flexibilität der IT-Landschaft bei den
gelegentlich sich ändernden Geschäftsprozessen eines
Unternehmens zu gewährleisten. Oft wird hauptsächlich
über Tools und Technologien der Entwicklung debattiert und
dabei werden die Bedürfnisse des Betriebes
vernachlässigt. Wenn dann eine der System-Komponenten aber
nicht funktioniert, richtet sich die ganze Aufmerksamkeit bis ins
obere Management auf die Betriebsmannschaft, die dann sozusagen
mit gebundenen Händen und oft auch mit verbundenen Augen im
Schussfeld stehen.
Betriebsunterbrüche verhindern
In vielen Fällen könnten Betriebsunterbrüche
jedoch vorausgesehen werden, wenn man die richtigen Hilfsmittel
dazu hätte. Bei einem Auto prüft man periodisch (oder
sollte wenigstens) Ölstand, Reifendruck, Kühlwasserstand
usw.; bei Maschinen führt man eine regelmässige Wartung
mit Messungen durch, bei Grosscomputern überwacht man laufend
die Ressourcen-Auslastung usw. Mittels solch einfacher Diagnosen
kann oft im frühen Stadium etwas unternommen werden, bevor
das ganze System zusammenbricht. Aber was ist zu bewerkstelligen,
wenn es sich um eine abnutzungsfreie aber dafür in der Regel
nicht perfekte Applikations-Software handelt, deren Komponenten
zudem noch "frei" im Netz auf verschiedenen Rechnern
verteilt sind?
Typischerweise sind solche Komponenten durch eine sogenannte
Middleware wie CORBA, RMI/EJB, DCOM u.a. miteinander gekoppelt.
Auf jede Komponente kann über eine Schnittstelle, die sie
nach aussen im Netz repräsentiert, zugegriffen werden. Eine
Schnittstelle ist eine Sammlung von Funktionen mit Parametern,
welche über die Middleware aktiviert werden können.
Solche Komponenten können mit Inseln im Ozean verglichen
werden, wobei das Meer die Middleware, die Häfen der Inseln
die Schnittstellen und die dazwischen kursierenden Schiffe die
Informations-Meldungen sind.
Diese Schnittstellen sind in der Regel applikationspezifisch
zugeschnitten. Es ist praktisch ein fast unlösbares Problem,
ein DiagnoseProgramm zu entwickeln, durch welches alle
Applikationen überwacht und geprüft werden können;
insbesondere darum, weil diese Applikationsschnittstellen und die
dahinter liegenden Implementationen laufenden Änderungen der
Applikations-Anforderungen unterworfen sind. Auch für das
Betriebspersonal wäre dies nicht zu bewältigen,
müssten sie doch alle Applikationen im Detail kennen, um
diese richtig zu betreuen.
Es gibt aber eine einfache Lösungsvariante, die uns da
weiterhilft. Wenn man z.B. eine auf CORBA basierte Middleware
verwendet, können Applikationen mit mehreren, verschiedenen
Schnittstellen realisiert werden. Die aussenstehenden
Client-Applikationen können z.B. die
Applikationsschnittstellen a1 von Applikation A verwenden, ohne
davon betroffen zu sein, dass die Applikation A noch weitere
Schnittstellen a2 und a3 hat (Abb.
1).
Dieser Umstand kann ausgenutzt werden, um jeder Applikation
eine identische Diagnostik-Schnittstelle zu geben, welche
genereller Natur ist. Nur ist es notwendig, dass eine
Diagnostik-Client-Applikation gebaut werden muss, welche jede
Applikation, die mit der genannten Diagnostik-Schnittstelle
versehen ist, überwachen kann. Die Applikationen müssen
zwar die Diagnostik-Funktionen implementiert haben und diese
über die Diagnostik-Schnittstelle nach aussen
repräsentieren. Wenn die Diagnostik-Client-Applikation
geschickt implementiert ist, kann sie jedoch gleichzeitig den
Zustand mehrerer Applikationen überwachen.
Abbildung 1: Konzept OUDiagnostic
Funktionen von Applikationen
Welche Funktionen müsste ein generisches
Diagnostik-Interface einer Applikation unterstützen?
Unsere Erfahrung mit verschiedensten, verteilten Applikationen
hat folgende Funktionalitäts-Anforderungen
herauskristallisiert:
- aktuelle Version einer Applikation zur Laufzeit abfragen
- momentanen Zustand (Status) einer Applikation abfragen
- momentane Auslastung einer Applikation abfragen (in %) .
- Liste von applikationsspezifischen Diagnose-Funktionen
ausgeben
- Auslösen von Diagnose-Funktionen der Applikation
- Verändern des Detaillierungsgrades für die
Fehler-Trace-Ausgabe zum Suchen eines Fehlers
Das Abfragen der Liste verfügbarer Diagnostik-Funktionen
ist der wichtige generische Teil, da jeder Service seine
spezifischen Diagnostik-Routinen hat. Typischerweise melden diese
Operationen lediglich detailliertere Informationen über den
Zustand der Applikations-Komponente zurück. Dies können
zum Beispiel Anzahl Client-Objekte, Anzahl offener Verbindungen zu
anderen Services usw. mit detaillierten Angaben zu welchem Client
diese gehören, wann sie eröffnet wurden und in welchem
Zustand sich diese zur Zeit gerade befinden.
Eher selten lösen diese Diagnostik-Funktionen eine
Zustandsveränderung im Server aus, und wenn dies der Fall
ist, dann wäre die Verwendung auf eine bestimmte
Benutzergruppe zu beschränken.
Abbildung 2: Benutzerschnittstelle OUDiagnostic-Tool
Jede Funktion in der Liste kann über den Diagnostic-Client
(vgl. Abbildung 2) ausgelöst werden und die Resultate werden
dahin zurückgeliefert. Das heisst, dank der darunterliegenden
Middleware kann der Diagnostik-Client jede im Netz zugreifbare
Applikation überwachen, was dieses Prinzip sehr mächtig
macht. Die zurückgelieferten Resultate sind in der Regel in
lesbarem Text, wobei die Zeichensatzkonversion automatisch durch
die darunterliegende Middleware gelöst wird.
Abfragen des aktuellen Status
Das Abfragen des aktuellen Status und der aktuellen Belastung
erfolgt über die nicht generische Schnittstelle (in CORBA IDL
definiert). Dies kann vom DiagnostikClient auch periodisch und
automatisch gemacht werden, und aufgrund dessen die Farbe des zur
Applikation zugehörigen Fensters entsprechend geändert
werden (grün = ok), so dass die für den Betrieb
verantwortliche Person auf den ersten Blick sieht, wenn ein
Service überlastet, in einem kritischen Zustand (gelb) oder
sogar unterbrochen (rot) ist.
Unsere Erfahrung mit diesem einfachen Werkzeug ist
überraschend gut. Bereits in der Entwicklung der
Applikations-Services , aber auch für unsere Kunden in der
Testphase und später im produktiven Betrieb, hat sich dieses
einfache Prinzip sehr bewährt.
Gerade die Flexibilität und die Einfachheit (für die
Entwicklungsseite wie für den Betrieb) ist überzeugend
und die Funktionalität kann laufend dem Bedarf angepasst und
ausgebaut werden.
Wenn Sie Interesse an diesem Konzept gefunden haben, empfehlen
wir Ihnen die verwendete IDL-Schnittstellen-Definition und die
zugehörigen Code-Beispiele von unserer Home-Page zu holen und
darauf aufzubauen. (Der URL ist: http://www.objeng.ch/DE/page/software-diagnostik.html)
Die verfügbaren Teile können Sie unter Quellenangabe und
Einhaltung des Urheberrechts kostenlos verwenden. Falls Sie die
zugehörige in Java geschriebene Diagnostik-Client-Applikation
möchten, senden Sie uns bitte eine per
Kontaktformular und
wir werden Ihnen das entsprechende Zip-File kostenlos zusenden.
Weitere Fragen beantworten wir gerne über das
Kontaktformular
unter dem Stichwort: OUDiagnostic.
Deshalb
hier noch ein Bild der Brooklyn Bridge
Editorial