Graphische Umsetzung eines Werkzeuges für die zentrale Überwachung von Windows-Diensten

Studienarbeit von Angelina Jung

Einleitung:

In dieser Projektarbeit geht es um die graphische Umsetzung eines Werkzeugs, das eine bestimmte Anzahl von Windows-Diensten zentral überwacht.

Da die Windows-Dienste unbemerkt und unbewacht im Hintergrund ablaufen, ohne regelmäßig kontrolliert zu werden, besteht das Ziel dieser Aufgabe genauer gesagt in der graphischen Realisierung eines Werkzeug, mit dessen Hilfe schnell und übersichtlich erfasst werden kann, wie die verschiedenen Windows-Dienste heißen, auf welchem Server sie ablaufen und welchen Status sie haben.

Es ist wünschenswert, dass diese Windows-Dienste jederzeit aktiv sind, da sie alle eine bestimmte Aufgabe erfüllen, deren Vernachlässigung andere Arbeitsprozesse stören und behindern würde, was wiederum einen negativen Effekt auf das alltägliche Geschäft hätte.

Um zu verhindern, dass es über einen längeren Zeitraum unbemerkt bleibt, wenn ein Windows-Dienst gestoppt ist, soll das Werkzeug die Anzeige aller relevanten Services und den jeweiligen aktuellen Status ermöglichen. Dadurch soll gewährleistet werden, dass gestoppte Windows-Dienste schnell herausgefiltert und neu gestartet werden können.

Zusammenfassend besteht die Motivation dieser Aufgabe also darin, die zentrale Überwachung von Windows-Diensten zu realisieren und graphisch übersichtlich darzustellen.

Textprobe:

Kapitel 2.4.1, Java Foundation Classes:

Für die Erstellung graphischer Benutzeroberflächen mit Java stehen die Standardklassenbibliotheken Java Foundation Classes (JFC) zur Verfügung.

Sie sind in einem Gemeinschaftsprojekt der Unternehmen Sun, Netscape, IBM und Apple entstanden.

Ursprünglich wurde für die Erstellung graphischer Benutzerschnittstellen das Abstract Window Toolkit (AWT) verwendet, das in dem Java-Paket* java.awt enthalten ist und die Implementierung graphischer Benutzeroberflächen mit Fenstern, Buttons, Feldern usw. ermöglicht. Dabei wird jede Komponente als Objekt von einer eigenen Klasse erzeugt und verfügt über entsprechende eigene Methoden, z.B. um Beschriftungen anzubringen.

AWT lässt jedoch noch einige Wünsche offen, denn um die Programmierung plattformunabhängiger graphischer Oberflächen zu ermöglichen, stehen nur Widgets zur Verfügung, die auf allen Plattformen unterstützt werden und komplexere Oberflächenelement wie Bäume und Tabellen, welche nicht auf allen Betriebssystemen vorhanden sind, wurden nicht in das AWT aufgenommen. Das hatte zur Folge, dass viele und umfangreiche herstellerbezogene Bibliotheken entstanden, die die Defizite des AWT ausgleichen sollten. Eine davon ist das von Sun geschaffene Swing, das im Paket javax.swing zur Verfügung gestellt wird und erstmals Ende 1997 als externe Bibliothek ausgeliefert wurde. Swing ist demnach eine Weiterentwicklung von AWT und ermöglicht die Verwendung komplexer graphischer Oberflächen wie Bäume oder Tabellen.

Swing-Klassen beginnen immer mit dem Buchstaben J, um sich von den gleichnamigen Klassen des AWT zu unterscheiden, z.B. heißt die Fenster-Klasse im AWT-Paket Frame und entsprechend im Swing-Paket JFrame.

Zusammenfassend entstanden die JFC also mit der Intention das Entwickeln komplexer, interaktiver Applikationen zu vereinheitlichen und das Entstehen von zahlreichen herstellerbezogenen Bibliotheken zu verhindern.

2.4.2, Standard Widget Toolkit und JFace:

Im Jahr 2001 entschied sich das Team von IBM gegen die JFC und entwickelte stattdessen für die Eclipse-Plattform das Standard Widget Toolkit (SWT), das kontinuierlich gepflegt wird. SWT ist der Hauptkonkurrent von AWT und Swing und stellt GUI-Komponenten über native Komponenten des Betriebssystems zur Verfügung. JFace erweitert die Funktionen von SWT und dient als Schnittstelle zwischen SWT und der Eclipse-Plattform. Es setzt aus den von SWT gelieferten Basiskomponenten komplexere Widgets zusammen und erleichtert die Entwicklung von Desktop-Anwendungen auf SWT-Basis, indem es SWT um den Model-View-Controller Ansatz (MVC) ergänzt. MVC gliedert ein Programm in drei Anwendungsschichten, nämlich Model, View und Controller. Das Model verwaltet die Daten und die Verarbeitungslogik, eine View stellt die Daten des Models für den Benutzer an der Bildschirmoberfläche dar und ein Controller verbindet die Views mit dem Model.

2.5, Die Rich-Client-Plattform von Eclipse:

Der Begriff Rich Client wird im Zusammenhang mit Client-Server-Architekturen verwendet. Bei einem Client-Server-Modell sind die Aufgaben und Dienstleistungen innerhalb eines Netzwerks verteilt (siehe Abbildung 7). Die Aufgaben werden von Programmen erledigt, die in Clients und Server unterteilt sind, wobei ein Client eine Aufgabe von einem Server anfordern kann. Der angesprochene Server kann sich dabei auf dem gleichen oder aber auch auf einem beliebig anderen Rechner im Netzwerk befinden. Er beantwortet die Anforderungen der Clients.

Rich Client ist die Bezeichnung für einen Client, bei dem die Verarbeitung der Daten vor Ort auf dem Client vollzogen wird.

Für das Erstellen von Clientanwendungen steht in der Entwicklungsumgebung Eclipse die Rich-Client-Plattform (RCP) zur Verfügung. Folgende Komponenten machen Eclipse RCP aus:

OSGi: Standardplattform, die die Entwicklung modularer, Plug-in-basierter Anwendungen auf der Java-Plattform erleichtert.

Equinox: implementiert zusätzlich zum OSGi-Standard weitere Funktionalitäten für Eclipse-Anwendungen.

Eclipse Core Runtime:

stellt allgemeine, nicht Graphik bezogene Funktionalitäten für Eclipse-Anwendungen bereit, verwaltet unter anderem den Lebenszyklus von Eclipse-Anwendungen, ist also für den Start und die Initialisierung der Anwendung verantwortlich.

SWT: Graphik Toolkit der Eclipse-Plattform.

JFace: setzt aus den von SWT gelieferten Basiskomponenten komplexere Widgets zusammen.

Eclipse UI: stellt die so genannte Workbench (deutsch: Werkbank) bereit, eine leere, graphische Anwendung, die die Bedienkonzepte wie View- und Editor-Reiter, Perspektiven, Menüstrukturen etc. bereitstellt.

RCP enthält eine allgemeine Infrastruktur für Clientanwendungen, die vom Entwickler um die eigenen Anwendungsbestandteile erweitert werden kann. Das Arbeiten mit Eclipse RCP bietet viele Vorteile. Es werden ausgereifte Basiskomponenten für GUI-Anwendungen angeboten, die sich bereits für viele Anwendungsfälle bewährt haben. Darüber hinaus sind die Grundstrukturen für den Aufbau einer GUI-Anwendung durch das Framework vorgegeben und müssen nicht erst durch den Entwickler geschaffen werden. Auch bezüglich Erweiterbarkeit besteht ein Vorteil, denn die Plattform ist auf Modularität hin ausgelegt und ermöglicht es, dass getrennt entwickelte Plug-ins zu einer Anwendung verschmolzen werden können.

Aufgrund dessen gehört es zu der allgemeinen Grundstrategie der untersuchten Versicherung, Clientanwendungen mit Hilfe von RCP in Eclipse zu realisieren.

3., Analyse:

3.1, Ist-Zustand:

Die Windows-Dienste, die die Gruppe IAS06 betreffen, laufen auf verschiedenen Servern im Hintergrund ab, ohne regelmäßige Überwachung oder Benachrichtigung, wenn ein Dienst gestoppt ist.

Um eine Übersicht über diese Dienste zu erhalten, ist eine Remotedesktopverbindung auf den Server nötig, auf dem die Dienste ablaufen. Um diese Verbindung herzustellen, werden ein Benutzername und das dazugehörige Passwort benötigt, andernfalls erhält man keinen Zugriff auf die Dienste.

Befindet man sich per Remoteverbindung auf dem Server, kann man sich eine Übersicht aller Dienste anzeigen lassen, die auf diesem Server ablaufen. Dabei ist es für die Mitarbeiter der Gruppe IAS06 nicht möglich, nur diejenigen Dienste anzeigen zu lassen, die für sie relevant sind. Stattdessen erhält man eine Anzeige sämtlicher Services, was zu Unübersichtlichkeit führt und einen schnellen Start der gestoppten Dienste erschwert.

Die zu der Gruppe IAS06 zugehörigen Dienste befinden sich auf den Servern mit den Namen dmse01, dmse02, dmst01 und dmst02. Der Buchstabe vor den Zahlen, steht jeweils für die Ebene des Ebenenkonzepts, das bereits oben beschrieben wurde. Demnach befinden sich dmse01 und dmse02 auf der Entwicklungsebene, während dmst01 und dmst02 zur Testebene gehören.

Eine Übersicht über die ablaufenden Dienste ist nur durch einzelne Remotedesktopverbindungen auf den jeweiligen Server möglich.

Um die Übersicht über die Windows-Dienste zu erleichtern und den umständlichen Weg über eine Remotedesktopverbindung zu vermeiden, soll ein Werkzeug graphisch umgesetzt werden, dass die gewünschten Informationen über die Dienste übersichtlich für den Benutzer darstellt. Eine Schwierigkeit bei der Umsetzung besteht darin, dass die Informationen über die Windows-Dienste nicht in einer Liste oder ähnlichem zur Verfügung stehen und somit nicht ohne weiteres bei der graphischen Oberfläche eingebaut werden können. Folglich müssen die gewünschten Informationen über die Dienste mit Hilfe eines Java-Programms direkt vom Server erfragt und unmittelbar in die graphische Oberfläche integriert werden, was den Vorteil hat, dass die Daten stets aktuell sind.