Interaktives Web-GUI (Rückverbindung, Hintergrundimage, Marker)

Transkript

1 Interaktives Web-GUI (Rückverbindung, Hintergrundimage, Marker) Gruppe 5 Harald Demel Markus Mai Marcus Pollice

2 Inhaltsverzeichnis EINLEITUNG... 3 TECHNOLOGIEEVALUIERUNG... 3 Java-Applet... 3 JavaScript... 3 Entscheidung... 4 UMSETZUNG... 5 Long-Polling... 5 System-Status... 5 Ablauf... 6 VORAUSSETZUNGEN AM CLIENT... 6 HOWTO - BEISPIEL ADAPTIEREN... 7 FAZIT... 10

3 Einleitung Bei unserer Arbeit zum Thema interaktives WebGUI ging es darum, Technologien für die Erstellung eines solchen GUIs zu evaluieren und anschließend an Hand einer von uns gewählten Technologie einen funktionierenden Prototyp zu programmieren. Technologieevaluierung Wir haben die folgenden beiden Technologiekombinationen evaluiert bevor wir mit der Umsetzung begonnen haben. Java-Applet Die simpelste Lösung wäre die Umsetzung mit Hilfe eines Java-Applets. Diese hat jedoch gravierende Nachteile wie das lange Laden beim Aufruf und einen, für diese Aufgabe, unverhältnismäßig großen Overhead durch Java. Zudem muss auf dem Computer die Java Runtime installiert sein, was in vielen Fällen nicht der Fall / durch Beschränkungen in Firmennetzen nicht möglich ist. Außerdem wäre an diesem Ansatz nichts Neues und er ist daher für uns wenig interessant. JavaScript JavaScript erlaubt es, über AJAX-Technik, eine weitere Verbindung zum Server im Hintergrund aufzubauen um Daten nachzuladen. Darauf basierend kann eine Technik namens Comet angewendet werden, die es erlaubt Push-Verhalten nach zu bilden. Eine gute Anleitung zu Comet findet sich unter Wichtig ist hierbei zu bemerken, dass sowohl AJAX als auch Comet keine Technologien sind sondern lediglich Techniken, die JavaScript einsetzen. Das

4 bedeutet, dass nichts zusätzlich installiert werden muss, da nur Funktionalität verwendet wird die schon in JavaScript vorhanden ist. Auf Basis dieser Technologien lässt sich ein Web-GUI umsetzen, das zur Gänze im Browser läuft. Auf der Serverseite, kann beliebige Software eingesetzt werden, die Webseiten dynamisch erzeugen kann, wie zum Beispiel PHP oder Python in Kombination mit einem Webserver. Entscheidung Wir haben uns für die JavaScript-Variante entschieden, da diese deutlich schlanker ist, weniger Anforderungen an das System stellt und auch technisch interessanter erscheint. Außerdem kann diese Variante deutlich besser in eine bestehende Lösung integriert oder um weitere Funktionalitäten erweitert werden. Zusätzlich wurde uns während den ersten Tests schnell klar, dass JavaScript unseren Ansprüchen vollkommen gerecht wird und wir keine aufgeblasene Java Funktionalität, wie sie die Applet Lösung geboten hätte, benötigen. Außerdem floss natürlich auch noch die im vorigen Punkt beschriebene Tatsache, dass JavaScript von nahezu allen derzeit aktuellen Webbrowsern, ohne eine zusätzliche Installation von Komponenten, unterstützt wird, in unsere Wahl mit ein. Auf der Server-Seite haben wir uns aufgrund der weiten Verbreitung für die Kombination von Apache und PHP entschieden. Beide Programme waren erste Wahl für uns, da sie zum einen weit verbreitet und zum anderen vollkommen gratis erhältlich sind. Außerdem ist der Setup Aufwand für diese beiden Komponenten relativ gering, da sie bereits in der Grundinstallation eine (für unsere Zwecke) ausreichende Konfiguration bieten. Selbstverständlich ist auch jede andere Kombination aus Webserver und PHP möglich.

5 Umsetzung Long-Polling Long-Polling ist eine Umsetzung der Comet-Technik und stellt den technischen Kern unserer Implementierung dar. Die Idee dahinter ist es, das Server-Push-Verhalten nachzubilden, indem der Client Polling betreibt und der Server seine Antwort hinauszögert bis es etwas Relevantes zu Antworten gibt. Technisch bedeutet das also, dass der Client eine TCP-Verbindung aufbaut und diese dann so lange offen gehalten wird bis es eine Nachricht gibt. Die Nachricht wird dann übertragen und die TCP-Verbindung abgebaut. Sofort beim Erhalt der Nachricht wird vom Client eine neue TCP-Verbindung aufgebaut um die nächste Nachricht empfangen zu können. Falls ein Timeout auftritt wird dieser einfach ignoriert und (um eine Überlastung zu verhindern nach einer kurzen Wartezeit) eine neue TCP-Verbindung aufgebaut. Theoretisch müsste die TCP-Verbindung nach dem Empfangen einer Nachricht auch nicht abgebaut und eine Neue aufgebaut werden, doch dies wird von den meisten Browsern nicht unterstützt. System-Status Da in unserem Fall der Status eines Netzwerks abgebildet werden sollte, stellte sich die Frage, woher der Server bei der Anfrage weiß ob der Client schon den aktuellen oder einen veralteten Zustand kennt. Die Ansätze eines Zeitstempels oder einer Zustandsnummer hatten beide den Nachteil, dass sich der Server zu jedem Zeitstempel oder zu jeder Zustandsnummer den Zustand hätte merken müssen. Daher haben wir uns dafür entschieden, den Zustand möglichst kompakt darzustellen und bei der nächsten Abfrage wieder zurück an den Server zu schicken. Dadurch muss am Server nichts gespeichert werden und auch die Robustheit des Systems ist deutlich höher.

6 Ablauf 1. Der Browser lädt die Webseite auf der sich vor allem das Hintergrundbild und Platzhalter für die Status-Bilder befinden. 2. Im Hintergrund wird eine AJAX-Verbindung zum Server aufgebaut. Dieser wird der derzeitig angezeigte, also der leere, Zustand (Initial-Zustand) mitgegeben. 3. Der Server vergleicht seinen lokalen Zustand mit dem derzeit angezeigten. Da wir das erste Mal abfragen ist der lokale Zustand verändert und wird sofort an den Client zurückgeschickt. 4. Der Client erhält die Nachricht und stellt sofort die nächste AJAX-Verbindung zum Server her. Erst dann ändert er alle Status-Bilder auf den aktuellen Zustand indem er den DOM-Baum modifiziert und passt eventuell auch Links oder einen Textbereich an. 5. Der Server überprüft alle 0.2 Sekunden ob sich der lokale Zustand im Vergleich zum Mitgeschickten geändert hat und antwortet erst bei einer Änderung. 6. Weiter bei 4. bis das Browserfenster geschlossen wird. Voraussetzungen am Client Grundsätzlich gilt, dass praktisch jeder derzeit erhältliche Browser die benötigte Funktionalität bereits enthält. Manchmal scheitert jedoch die Ausführung des Scripts an einem deaktivierten JavaScript oder zu strikten Sicherheitseinstellungen (die zumeist JavaScript deaktivieren). Wir haben unsere Implementierung mit den gängigen Browsern wie Firefox, Internet Explorer, Chrome, Safari und Opera mit der Standardkonfiguration, direkt nach der Installation, erfolgreich getestet. Sollte die Ausführung des Scripts scheitern, so sollte der erste Blick zu den Sicherheitseinstellungen des verwendeten Browsers führen und sichergestellt

7 werden, dass eine Sicherheitsstufe gewählt wurde, die JavaScript erlaubt. Weitere Anforderungen gibt es an den Browser allerdings nicht. Wichtig ist noch, dass die AJAX-Verbindung zum selben Server aufgebaut werden sollte von dem auch die Hauptseite stammt, da viele Browser sonst eine Cross-Site- Scripting-Attacke vermuten und die Verbindung verhindern. Das muss beim Planen einer solchen Statusseite berücksichtigt werden, sollte aber kaum praktische Einschränkungen mit sich bringen. Diese Information ist für den Betreiber der Statusseite wichtig und kann vom Nutzer nicht beeinflusst werden! Howto - Beispiel adaptieren Das Beispiel kann unter herunter geladen werden und sollte nach dem Entpacken in den www-order eines beliebigen Webservers mit PHP Unterstützung funktionieren. Bei uns kam PHP in Kombination mit Apache zum Einsatz. 1. systemstate.txt öffnen es zeigt sich folgendes Bild server1;g server2;y server3;g server4;g server5;y server6;r Diese Datei muss nun an die eigenen Gegebenheiten angepasst werden. Pro Zeile ein Server mit seinem jeweiligen Status. Die Servernamen (server1, server2, ) sind beliebig es empfiehlt sich jedoch Namen zu verwenden die man sich leicht merken kann, da diese im späteren Verlauf noch gebraucht werden. g (green) steht für Up & running y (yellow) steht für Error

8 r (red) steht für Down Ein Eintrag in dieser Datei hat also die Form [SERVER_NAME];[STATUS] als Beispiel die Einträge für 2 Server: server1;g server2;y Sind alle zu überwachenden Server eingetragen wird die Datei gespeichert und kann geschlossen werden. 2. settings.inc.php in einem Texteditor öffnen Hier werden nur wenige Basiseinstellungen das Hintergrundbild betreffend festgelegt. $settings['bgimg']['filename'] = "bgimg.gif"; $settings['bgimg']['width'] = 700; $settings['bgimg']['height'] = 487; Hier müssen die Werte nach dem = an die eigenen Anforderungen angepasst werden. Als filename kann jedes beliebige Bild definiert werden. Es empfiehlt sich jedoch die Verwendung einer.gif,.jpg oder.png Datei um einen optimalen Kompromiss zwischen Qualität und Dateigröße zu finden. Mit width und height wird definiert wie breit und wie hoch das Hintergrundbild sein soll (Angaben in Pixel) Damit sind die Modifikationen in dieser Datei auch schon wieder abgeschlossen.

9 3. servers.html in einem Texteditor öffnen Hier gibt es nun für jeden zuvor in der systemstate.txt definierten Server einen Eintrag der mit <div > beginnt und durch </div> wieder geschlossen wird. Durch diesen wird die Position des Statusbildes auf dem Hintergrundbild festgelegt. Ein Beispiel: <div style="position:absolute; left:185px; top:285px;"> <a id="server1.a" target="_blank" href="#"> <img id="server1" border="0" src="images/default.png" height="30"> </a> </div> Interessant sind hier die farbig markierten Einträge. Mit left:185px; wird der Abstand vom linken Rand des Hintergrundbilds festgelegt. Mit top:285px; wird der Abstand vom oberen Rand des Hintergrundbilds festgelegt. Der orange Eintrag server1.a der Teil vor dem Punkt (server1) muss dem Namen eines Servers in der systemstate.txt entsprechen. An diesen wird danach einfach.a angehängt um einen eindeutigen Namen zu erzeugen (es muss IMMER.a angehängt werden). Der blaue Eintrag server1 muss allerdings genau mit dem Namen aus der systemstate.txt Datei übereinstimmen. Wenn alle Server eingetragen sind ist die Bearbeitung dieser Datei abgeschlossen.

10 4. Ordner details In diesem Ordner können, für alle in der systemstate.txt angelegten Server,.html,.php etc. Seiten (auch Bilder sind möglich) angelegt werden die Detailinfos oder ähnliches enthalten. Die einzige Bedingung ist wiederrum, dass die Dateien so heißen wie die Einträge in der systemstate.txt. Pro Server ist nur eine Datei möglich! Bsp.: server1.php, server2.jpg Fazit Wir waren sehr überrascht wie einfach es möglich ist, den Zustand eines Servers mit Hilfe eines Hintergrundbildes und ein paar Markern gepaart mit einer kleinen Portion JavaScript und PHP Code anschaulich für jedermann darzustellen. Die von uns gefundene Lösung zeigt einen schnellen, effizienten und weitgehend fehlerresistenten Weg auf um die Aufgabenstellung zu lösen. Potential für die Optimierung unserer Skripten ist wahrscheinlich gegeben aber wir haben einen guten Mittelweg zwischen Funktionalität und Komplexität gefunden!