Webplattform zur Verwaltung von Schneeprofilen

Leopold-Franzens-Universität Innsbruck
Institut für Informatik
Datenbanken und Informationssysteme
Webplattform zur Verwaltung von Schneeprofilen
Bachelor-Arbeit
Aleksandar Stojakovic
betreut von
Dipl.-Ing. Robert Binna
Innsbruck, 4. November 2012
Zusammenfassung
Die vorliegende Arbeit beschreibt die Entwicklung einer Webplattform
zur Verwaltung von Schneeprofildaten. Es wird der Aufbau eines Schneeprofils und dessen Umsetzung in die Plattform beschrieben. Desweiteren
wird die Architektur der Webplattform erklärt, aus welchen Komponenten sie besteht, wie diese Komponenten zusammenarbeiten und welche
Technologien eingesetzt wurden.
Abstract
This paper describes the implementation of a web platform for the management of snow profile data. It describes the structure of a snow profile
and how they are implemented in the platform. Furthermore, the architecture of the web platform will be explained, of what components it
consists, how these components work together and witch technology is
used.
Inhaltsverzeichnis
1 Einleitung
1
2 Das Schneeprofil
2.1 Aufbau des Schneeprofils . . . .
2.1.1 Metadaten . . . . . . .
2.1.2 Schichtprofil . . . . . . .
2.1.3 Schneetemperaturprofil
2.1.4 Stabilitätstests . . . . .
2.2 Das CAAML-Format . . . . . .
.
.
.
.
.
.
3
3
4
4
6
7
8
.
.
.
.
.
.
.
.
.
11
13
14
15
16
17
17
18
19
20
.
.
.
.
.
.
.
.
.
23
23
25
26
26
27
27
29
29
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Die Architektur
3.1 Datenkonverter . . . . . . . . . . . . . . . .
3.2 Backend . . . . . . . . . . . . . . . . . . . .
3.2.1 Die Datenbank . . . . . . . . . . . .
3.2.2 Integration von CAAML-Dateien . .
3.2.3 Kommunikationsschnittstelle für den
3.3 Frontend . . . . . . . . . . . . . . . . . . . .
3.3.1 MVC-Muster . . . . . . . . . . . . .
3.3.2 Benutzerschnittstelle . . . . . . . . .
3.3.3 Schneeprofil-Diagramm . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
. . . .
Client
. . . .
. . . .
. . . .
. . . .
4 Verwendete Technologien
4.1 XSL-Transformation . . . . . . . . . . . . . . . .
4.2 JSON . . . . . . . . . . . . . . . . . . . . . . . .
4.3 REST . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Prinzipien . . . . . . . . . . . . . . . . . .
4.3.2 Beispiel . . . . . . . . . . . . . . . . . . .
4.4 ExtJS . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Rhino . . . . . . . . . . . . . . . . . . . . . . . .
4.6 Batik . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 Dokumentenorientierte Datenbanken & OrientDB
5 Ausblick
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
III
INHALTSVERZEICHNIS
6 Zusammenfassung
35
Appendix
37
A.1 Schneeprofildaten im JSON-Format . . . . . . . . . . . . . 37
A.2 Schneeprofil-Grafik . . . . . . . . . . . . . . . . . . . . . . 39
A.3 Benutzerhandbuch . . . . . . . . . . . . . . . . . . . . . . 41
Literaturverzeichnis
IV
45
Aleksandar Stojakovic
Kapitel 1
Einleitung
Die Aufnahmen der Schneeprofile bilden die Grundlage eines Lawinenwarndienstes und ist damit ein wichtiger Faktor für die Sicherheit in
den Bergen und auf den Pisten. Mit ihrer Hilfe bekommt man einen
Überblick über den Aufbau der Schneedecke, welche auf Schwachschichten untersucht wird, die die Ursache für Lawinenabgänge sind.
Diese Schneeprofile werden von verschiedenen Lawinenwarndiensten weltweit erhoben. Jedoch erfolgt die Speicherung der Schneeprofile unterschiedlich, da jeder LWD ein proprietäres Format dafür verwendet, was
den Informationsaustausch zwischen ihnen schwierig gestaltet.
Um den Datenaustausch und die Kommunikation zwischen den verschiedenen Lawinenwarndiensten zu verbessern wurde ein Standart Format für den Austausch und die Speicherung der Schneeprofile von einem internationalen Gremium bestehend aus Lawinenwarndiensten der
Länder Kanada, Europa, darunter im Speziellen Schweiz und Italien, Tirol und Colorado eingeführt - den CAAML-Standard. Beim Canadian
Avalanche Association Markup Language handelt es sich um ein XMLbasiertes Format, das die wichtigsten Schneeprofilinformationen beinhaltet.
Um die Verbreitung des Standards zu beschleunigen und zu unterstützen
ist die Verfügbarkeit freier Software notwendig, welche die vorhandenen
proprietären Daten in die Plattform integriert und künftige Datenaufnahmen über die Plattform vonstatten gehen.
Im folgenden wird die Umsetzung der Webplattform erklärt, dazu wird
die Arbeit in drei Teile gegliedert. Kapitel 2 befasst sich mit dem Aufbau des Schneeprofils und dem CAAML-Format. Im anschließenden Kapitel wird die Architektur der Plattform beschrieben. Dabei werden die
Komponenten beschrieben aus denen die Architektur besteht und wie
1
KAPITEL 1. EINLEITUNG
sie miteinander kommunizieren bzw. interagieren. Im darauffolgenden
Kapitel wird detailierter auf die Technologien eingegangen, mit denen
sich die einzelnen Komponenten bedienen. Abschließend wird ein Ausblick gegeben, wie die Plattform zukünftig verwendet wird und welche
Erweiterungen geplant sind.
2
Aleksandar Stojakovic
Kapitel 2
Das Schneeprofil
Ein Schneeprofil kann prinzipiell als Querschnitt durch eine Schneedecke
gesehen werden. Dabei wird die Schneedecke in Schichten unterteilt und
in Hinblick auf Parameter wie Härte, Kornform, Korngröße und Wassergehalt untersucht. Desweiteren wird die Schneetemperaturen gemessen
und verschiedene Stabilitätstests durchgeführt um das Schneeprofil auf
Schwachschichten zu untersuchen, die verantwortlich für Instabilitäten
in der Schneedecke sind. Appendix A.2 zeigt und beschreibt kurz ein
Schneeprofil.
Dieses Kapitel beschreibt die wichtigsten Komponenten aus denen sich
ein Schneeprofil zusammensetzt, welche Kriterien eine Schwachschicht
auszeichnet und ihre Darstellung im CAAML-Format.
2.1
Aufbau des Schneeprofils
Der Aufnahme des Schneeprofils ist in vier Sektionen unterteilt. Dazu
zählen die Metadaten, das Schichtprofil, das Schneetemperaturprofil und
die Stabilitätstests. Diese werden im Folgenden erklärt und es wird beschrieben welchen Einfluss sie auf die Untersuchung der Schwachschichten haben.[fSuLS]
3
KAPITEL 2. DAS SCHNEEPROFIL
Abbildung 2.1: Aufbau des Schneeprofils
2.1.1
Metadaten
Die Metadaten enthalten Informationen wie den Namen des Erstellers
des Schneeprofils, das Erstelldatum, die Uhrzeit, den Ort (Region und
Koordinaten), die Höhe über dem Meeresspiegel, Windverhältnisse, Niederschlag und sonstige Punkte, die Auskunft über die Umgebung des
Profilortes und Art der Profilaufnahme geben.
2.1.2
Schichtprofil
Das Schichtprofil zeigt die Unterteilung der Schneedecke bzw. des Schneeprofils in Schichten. Diese Schichten unterscheiden sich voneinander in
Kornform und Korngröße, die das Kristallgefüge des Schnees beschreiben, und in Härte und Wassergehalt (Feuchte). Aus den Daten eines
Schichtprofils erschließt sich der Nietentest. Der Nietentest ist der erste Schritt zur Untersuchung der Schneedecke auf Schwachschichten.
[fWSuLW]
4
Aleksandar Stojakovic
KAPITEL 2. DAS SCHNEEPROFIL
Nietentest:
Der Test dient vor allem dazu, den Schneedeckenaufbau im Hinblick auf
mögliche, kritische Schwachschichten zu beurteilen. Er besteht aus sechs
kritischen Punkten, wobei vier von denen, auch Schichtnieten genannt,
für jede Schicht und zwei Punkte, Schichtgrenzennieten genannt, für zwei
benachbarte Schichten überprüft werden. Trifft ein Kriterium zu, wird
der Schicht eine Niete vergeben, das heißt es vergrößert sich das Risiko,
dass diese Schicht eine Schwachschicht ist. Die Folgende Auflistung beschreibt kurz die Kriterien:
Schichtnieten
• Kornform: Wenn die Kornform der Schicht folgende Eigenschaften besitzt: kantige Formen, Schwimmschnee oder Oberflächenreif,
dann trifft das Kriterium zu und der Schicht wird eine Niete vergeben. Auf die genauere Definition dieser Eigenschaften wird hier
nicht eingegangen, da sie für die Webplattform nicht relevant sind.
• Korngröße: Hierbei gilt, je größer die Korngröße, desto geringer
die Festigkeit der Schicht, d.h. die Schicht ist schwächer. Das Kriterium ist erfüllt wenn die Korngröße größer als 1mm ist.
• Härte: Für die Beurteilung der Härte der einzelnen Schichten betrachtet man die Handhärte. Schwache Schichten haben meist eine
Handhärte Faust“ oder allenfalls eine Härte der Stufe 1 bis 2, d.
”
h. Faust“ bis Vier Finger“.
”
”
• Tiefe in der Schneedecke: Je geringer die Schneehöhe (oberhalb
der Waldgrenze), umso schlechter ist in der Regel der Schneedeckenaufbau. In der Regel erhält eine Schicht eine Niete sobald
sie tiefer als 1m in der Schneedecke positioniert ist.
Schichtgrenzennieten
• Korngrößenunterschied: Ein großer Korngrößenunterschied bedeutet in der Regel, dass zwei sehr unterschiedliche Schichten zusammenkommen. Somit ist es wahrscheinlich, dass die Schichtgrenze
eine potenzielle Bruchfläche darstellt. Ist der Unterschied zwischen
den Korngrößen größer als 3/4mm ist das Kriterium erfüllt.
• Härteunterschied: Je größer der Härteunterschied zwischen zwei
benachbarten Schichten ist, umso eher ist diese Schichtgrenze eine
potenzielle Bruchfläche. Ein Härteunterschied von zwei oder mehr
Stufen der Handhärte ist in der Regel als kritisch zu beurteilen.
Aleksandar Stojakovic
5
KAPITEL 2. DAS SCHNEEPROFIL
Trifft eine der beiden Kriterien für die Schichtgrenzennieten zu, so wird
die Niete der unteren der beiden Schichten, die miteinander verglichen
werden, vergeben.
Der folgende Pseudocode veranschaulicht den Nietentest. Die Reihenfolge geschieht von der obersten Schicht bis zur Untersten, wobei jede
Schicht nach den oben beschriebenen Kriterien untersucht wird.
Algorithm 1 Pseudocode Nietentest
Require: Schneeprofil
for all Schichten do
Initialize niete to zeroif kornf orm = kantigeF orm then
niete + +
else if kornf orm = Schwimmschnee then
niete + +
else if kornf orm = Oberf laechenreif then
niete + +
end if
if korngroesse > 1mm then
niete + +
end if
if härte > 2 then
niete + +
end if
if schichthoehe > 1m then
niete + +
end if
if |Schicht.korngroesse − ObereSchicht.korngroesse| < 3/4mm
then
niete + +
end if
if |Schicht.haerte − ObereSchicht.haerte| > 2 then
niete + +
end if
end for
Eine Schicht gilt als potenzielle Schwachschicht, wenn mehr als vier Nieten zutreffen.
2.1.3
Schneetemperaturprofil
Anhand des Temperaturverlaufs kann abgeschätzt werden, wie ausgeprägt die aufbauende Umwandlung in der Schneedecke ist. Grundsätzlich
gilt: Je höher der Temperaturgradient, desto ausgeprägter die aufbau6
Aleksandar Stojakovic
KAPITEL 2. DAS SCHNEEPROFIL
ende Umwandlung. Das heißt: große Kristalle werden immer größer und
kleine Kristalle werden aufgelöst. Dies führt zu einem Festigkeitsverlust
in der umgewandelten Schneeschicht.
2.1.4
Stabilitätstests
Neben den eigentlichen Schneeprofilinformationen und dem Nietentest
bilden Stabilitätstests, darunter Kompressionstest (CT), erweiterter Kompressionstest (ECT) und Rutschblocktest (RBT), eine weitere Aussagekraft über die Stabilität der Schneedecke. Bei all diesen Tests werden
jeweils Blöcke der Schneedecke abgeschnitten und Bruchtests durchgeführt. Dabei werden Daten wie die Schneehöhe, Bruchart, Bruchfläche
und die Belastungsstufe aufgenommen. Während die Bruchart für alle
Tests die gleichen Werte besitzen kann, also kein Bruch, Teilbruch oder
ganzer Block, ebenso die Bruchfläche, glatt, rau oder mittelmäßig unterscheidet sich die Belastungsstufe bei den Tests wie folgt:
RB/RBT - Rutschblocktest:
• RB 1. Bruch beim Graben/Ausschneiden
• RB 2. Bruch beim Betreten mit Skiern
• RB 3. Bruch beim Wippen mit Skiern
• RB 4. Bruch beim ersten Sprung mit Skiern
• RB 5. Bruch beim 2. oder 3. Sprung mit Skiern
• RB 6. Bruch beim Sprung ohne Skiern
• RB 7. kein Bruch
Aleksandar Stojakovic
7
KAPITEL 2. DAS SCHNEEPROFIL
CT - Kompressionstest:
• CT 0. Block bricht während des Ausschneidens
• CT 1-10. Bruch beim Fallenlassen der Hand aus der Handwurzel Handfläche trifft auf das Schaufelblatt
• CT 11-20. Bruch beim Fallenlassen des Unterarms aus dem Ellenbogen - Handfläche trifft auf das Schaufelblatt
• CT 21-30. Bruch beim Fallenlassen des gesamten Arms aus dem
Schultergelenk - Faust trifft auf das Schaufelblatt
• CT 31. kein Bruch möglich
ECT - Erweiterter Kompressionstest:
Die Auflistung ist hierbei analog zum CT, nur ist die Größe des ausgeschnittenen Blocks größer.
• ECT 0. Block bricht während des Ausschneidens
• ECT 1-10. Bruch beim Fallenlassen der Hand aus der Handwurzel
- Handfläche trifft auf das Schaufelblatt
• ECT 11-20. Bruch beim Fallenlassen des Unterarms aus dem Ellenbogen - Handfläche trifft auf das Schaufelblatt
• ECT 21-30. Bruch beim Fallenlassen des gesamten Arms aus dem
Schultergelenk - Faust trifft auf das Schaufelblatt
• ECT 31. kein Bruch möglich
2.2
Das CAAML-Format
Bisher verwendeten die meisten Lawinenwarndienste zur Darstellung der
Schneeprofildaten ein propriäteres Format. Beispielsweise für den Lawinenwarndienst von Tirol stellt dies eine Barriere für den Informationsaustausch mit internationalen LWDs dar, da aktuell die Schneeprofildaten in einem proprietären XML-Format, das höchstem in den Ländern
Tirol und Bayern Anwendung findet, gespeichert sind. Deswegen wurde
ein neuer Standard für die elektronische Darstellung der Schneeprofile
entwickelt, welcher weltweit nötige Informationen abdeckt, die für die
Aufnahme von Schneeprofilen von Belang sind. Dieser Standard heißt
CAAML.
8
Aleksandar Stojakovic
KAPITEL 2. DAS SCHNEEPROFIL
Der Zweck von CAAML (Canadian Avalanche Association Markup Language) ist, eine Datenstruktur zu definieren, um den elektronischen Austausch von Lawineninformationen zu unterstützen. CAAML definiert die
Struktur und Elemente des Schneeprofils und spezifiziert wie die oben
genannten Sektionen im Schneeprofil integriert sind. CAAML basiert auf
XML1 , das etablierte Format für den Datenaustausch im World Wide
Web.
Für die Entwicklung werden online unter http://caaml.org ein XMLSchema und die dazu gehörige Dokumentation der Elemente und Struktur bereitgestellt. Aufgrund des jungen Entwicklungsstandes zum Zeitpunkt der Ausführung dieser Arbeit liegt aber keine offizielle Dokumentation von CAAML vor.
1
http://www.w3.org/XML/
Aleksandar Stojakovic
9
Kapitel 3
Die Architektur
Für den Austuasch der Schneeprofildaten zwischen den Lawinenwarndiensten werden sowohl datenorientierte als auch grafische Formate zur
Verfügung gestellt, wobei für Änderungsoperationen ausschließlich die
datenorientierten Formate zulässig sind. Bei den datenorientierten Formaten handelt es sich um das CAAML-Format, das das Schneeprofil
in Form von Rohdaten repräsentiert, während grafische Formate JPG-,
PNG- oder PDF-Dateien sind, die die Schneeprofildaten in einem Diagramm zusammenfasst.
Aufgrund der Anforderungen in Bezug auf einfache Handhabung, Wartbarkeit und an den Datenaustausch, sowohl datenorientiert als auch
grafisch, wurde die Applikation zur Verwaltung der Schneeprofile als
Webplattform konzipiert. Um sowohl eine hohe Interaktivität der Benutzeroberfläche als auch ein möglichst flexible Integration in andere
Applikationen, wie Webportale der Lawinenwarndienste, sicherzustellen
wurde eine 2-Schichten-Architektur gewählt. Die 2 Schichten bestehen
dabei aus dem Backend, welche für die Persistenz und das Umwandeln
der Daten zuständig ist, und dem Frontend das die Präsentationsschicht
darstellt und die Daten für die Persistenz vorbereitet. Diese Architektur
wird auch als Client-Server-Architektur bezeichnet.
Der Server kümmert sich um die Datenbankanbindung, also um die Persistenz, und ist zuständig für die Umwandlung der Daten, sei es, ob
die Daten in die gewünschten Ein- und Ausgabeformate exportiert bzw.
importiert werden sollen oder die Schneeprofil-Grafik als PDF zum Download bereitgestellt wird.
Der Client ist nach dem MVC-Muster aufgebaut, das die Benutzerschnittstelle und ein Model des Schneeprofils erstellt. Außerdem führt
der Client notwendige Berechnungen durch um die Daten für die Persistenz vorzubereiten.
11
KAPITEL 3. DIE ARCHITEKTUR
Der Austausch der Daten zwischen Client und Server geschieht über
eine REST-Schnittstelle. Diese REST[Fie00]-Schnittstelle stellt dabei
CRUD-Funktionalitäten zur Verwaltung der Schneeprofile und Benutzer zur Verfügung. CRUD bezeichnet im Allgemeinen Datenbankoperationen Create, Read, Update und Delete. Da REST in der Plattform
als HTTP-Schnittstelle verwendet wird, werden die Bezeichnungen der
HTTP-Operationen verwendet - GET, POST, PUT und DELETE. Eine Operation in Kombination mit einer URL stellt für den Client die
Möglichkeiten dar, entweder auf Ressourcen zuzugreifen (GET), neue
Ressourcen über die URL an den Server zu senden (POST), vorhandene Ressourcen zu aktualisieren (PUT) oder den Befehl für das Löschen
einer Ressource über die URL zu geben (DELETE).
Für die Kommunikation zwischen Backend und Frontend wird das JSONFormat (JavaScript Object Notation) verwendet. Grund dafür ist der
kompakte Aufbau von JSON aus einer für Mensch und Maschine einfach
lesbaren Textform, die Implementierung des Clients mittels JavaScript
und die Art der Datenbank die Daten als JSON-Dokumente abzuspeichern.
Die Webplattform arbeitet damit folgerichtig hauptsächlich mit Schneeprofildaten, die im JSON-Format vorliegen. Beim Import der CAAMLDaten wandelt der Server diese in JSON um und speichert sie in die
Datenbank ab. Über die REST-Schnittstelle fragt der Client die Daten
ab, die er im JSON-Format erhält, sie verarbeitet und sie im Browser
darstellt.
Die Webplattform wurde in drei Module aufgeteilt. Das erste Modul beschreibt den Datenkonverter, der die propriäteren Daten in das CAAMLFormat umwandelt. Darauffolgend wird das Backend beschrieben, das
den Server und damit verbunden die Datenbank repräsentiert. Desweiteren wird die Integration der CAAML-Daten in das System beschrieben.
Letztlich wird auf das Frontend eingegangen, der die Implementierung
des Clients nach dem MVC-Muster und die Kommunikationsschnittstelle REST beschreibt.
12
Aleksandar Stojakovic
KAPITEL 3. DIE ARCHITEKTUR
Abbildung 3.1: Aufbau der Webplattform
3.1
Datenkonverter
Die bisher erhobenen Schneeprofildaten des Lawinenwarndienstes sind
im propriäteren Format vorhanden. Diese müssen in das CAAML-Format
umgewandelt werden um einerseits einen einfachen Informationsaustausch mit internationalen Lawinenwarndiensten zu ermöglichen und
andererseits sie in die Webplattform zu integrieren. Prototypisch wurde
dafür ein Konverter entwickelt der die Daten des Lawinenwarndienstes
von Tirol in das CAAML-Format umwandelt.
Unter Zuhilfenahme der XSL-Transformation, kurz XSLT 1 , ist es möglich
aus den propriäteren Dateien neue Dateien im CAAML-Format zu erzeugen. Erforderlich dafür ist ein XSLT-Stylesheet, das selbst nach den
Regeln des XML-Standards aufgebaut ist. Das Stylesheet definiert die
Struktur der zu erzeugenden neuen Datei, also die CAAML-Struktur,
und befüllt die Datei mit den Werten aus der propriäteren Datei (Abbildung 3.2).
1
http://www.w3.org/TR/xslt
Aleksandar Stojakovic
13
KAPITEL 3. DIE ARCHITEKTUR
Abbildung 3.2: XSL-Transformation
Der Datenkonverter ist in erster Linie nicht direkt in der Webplattform
eingegliedert sondern als seperates Tool entwickelt worden, welches zwei
Parameter verwendet: den Pfad zur propriäteren Datei und den Pfad wo
die neue Datei gespeichert werden soll.
3.2
Backend
Das Backend umfasst den Server und damit die Integration der Datenbank und die Interaktion mit dem Client. Desweiteren bindet das
Backend Schneeprofil-Daten die im CAAML-Format vorliegen in das
System ein.
Abbildung 3.3: Backend - Aufbau
14
Aleksandar Stojakovic
KAPITEL 3. DIE ARCHITEKTUR
3.2.1
Die Datenbank
Aufgrund des geschachtelten Aufbaus des Schneeprofils (siehe Appendix A.1) und der zu erwartenden großen Datenmenge wird die dokumentenorientierte Datenbank OrientDB verwendet. OrientDB zeigt, im
Vergleich zu relationalen Datenbanken, kurze Anfragezeiten bei großen
Datenmengen auf. Auch kann es Daten trotz geschachtelten Aufbaus
sehr gut verwalten.
OrientDB stellt Daten in Form von Dokumenten dar, die eine geschlossene Einheit bildet. Ein Dokument entspricht einem JSON-Objekt - es
besitzt Eigenschaften, bestehend aus einem Schlüssel und einem Wert
(Key-Value-Format). Auch kann es eine geordnete Liste von Werten,
die in einem Array dargestellt werden, oder weitere Objekte, die dem
Wurzel-Objekt unterliegen, besitzen.
Das Schneeprofil ist als solch eine geschlossene Einheit zu betrachten. Es
bildet das Wurzel-Objekt und beinhaltet Eigenschaften (z.B. das Feld
Person wird mit dem Namen des Profilaufnehmenden besetzt) und weitere Objekte, wie beispielsweise Schichten, die wiederrum Felder, wie
Höhe oder Kornform besitzen. Abbildung 3.4 veranschaulicht grob ein
Schneeprofil-Dokument.
Abbildung 3.4: Struktur eines Dokuments
Aleksandar Stojakovic
15
KAPITEL 3. DIE ARCHITEKTUR
Da OrientDB, so wie der Server, auf der Programmiersprache Java basieren, kann diese direkt in einem embedded-Modus in den Server integriert
werden.
3.2.2
Integration von CAAML-Dateien
OrientDB-Dokumente sind JSON-Daten. Der Server stellt deshalb neben
den Funktionen die Datenbankanbindung herzustellen und Ressourcen
für den Client zur Verfügung zu stellen, auch einen Konverter bereit,
der CAAML-Dateien in das JSON-Format umwandelt und wieder exportiert.
Der Konverter ist mithilfe der JSON-Bibliothek von json.org 2 realisiert. Mit diesem Konverter können XML- Dokumente - darunter auch
CAAML-Dokumente - in das JSON-Format umgewandelt werden. Dieser analysiert dabei schrittweise jedes Element des XML-Dokuments. Es
baut aus einem Element ein JSON-Objekt auf, das als Schlüssel den
Elementnamen verwendet und als Wert den Textinhalt des Elementes.
Da JSON nicht zwischen Attributen und Elementen unterscheidet werden Attribute seperat als Eigenschaften in das JSON-Objekt eingefügt.
Besitzt das Element geschachtelte Elemente, werden diese analog geschachtelt in das JSON-Dokument eingefügt.
Abbildung 3.5: Konvertierung - XML in JSON
Die Rückkonvertierung geschieht über einen Konverter derselben Bibliothek, die JSON-Daten in XML-Dokumente umwandelt. Dabei werden
die Schlüssel als Elemente mit den Werten als Inhalt erstellt. Aufgrund
der Nichtunterscheidung zwischen Attributen und Elementen ist eine
weitere Konvertierung, in Form einer XSL-Transformation, notwendig
um die Daten in Form einer CAAML konformen Datei zu exportieren.
2
16
http://json.org/
Aleksandar Stojakovic
KAPITEL 3. DIE ARCHITEKTUR
3.2.3
Kommunikationsschnittstelle für den Client
Um auf Anfragen des Clients zu reagieren definiert der Server Klassen, die Methoden der RESTlet-Ressource implementieren. RESTlet
ist dabei ein REST-Framework für die Java-Plattform. Jede Klasse repräsentiert somit eine Ressource, die an eine bestimmte URL angehängt
wird auf die der Client zugreifen kann. (Listing 3.1)
Listing 3.1: Klasse an eine URL anhängen
router . attach ( ” / s n o w p r o f i l e /{ i d } ” ,
SingleSnowProfileResource . class ) ;
RESTlet verwendet Annotationen um eine Methode einer CRUD- Operation zuzuordnen. Beispielsweise wird eine Methode die Daten von der
Datenbank ladet und dem Client zur Verwendung gibt mit der Annotation @Get() gekennzeichnet (siehe Listing 3.2).
Listing 3.2: Methode in SingleSnowProfileResource
@Get ( )
// Annotati on , d i e O p e r a t i o n f u e r Methode
// d e f i n i e r t
public String getJson ( ) {
...
// Daten von Datenbank l a d e n
return returnSnowProfile ;
}
Der Server leitet somit die Anfrage des Clients, die über die URL geschehen ist an die verantwortliche Klasse, diese führt die Methode aus,
die mit der Operation gekennzeichnet ist, die der Client verwendet.
3.3
Frontend
Das Frontend umfasst die Implementierung des Clients. Der Client stellt
die Benutzerschnittstelle her über die die Schneeprofildaten bearbeitet
werden können. Desweiteren werden diese Daten auch in einem Diagramm zusammengefasst. Es stellt Schnittstellen bereit um das Diagramm als PDF herunterzuladen und/oder sie als XML-Dateien im
CAAML-Format zu exportieren bzw. importieren. Dabei verwendet es
die REST-Schnittstelle zum Server um auf die Daten zuzugreifen und
sie zu manipulieren.
Die Implementierung des Programms erfolgt nach dem Schema des MVCMusters, das die Aufgaben innerhalb des Programms aufteilt. Dies erhöht
die Wartbarkeit des Programms und Neuerungen können, soweit sie
nicht gravierend vom Grundstil abweichen, einfach eingebaut werden.
Aleksandar Stojakovic
17
KAPITEL 3. DIE ARCHITEKTUR
Dafür wurde die JavaScript-Bibliothek ExtJS verwendet, das die Strukturierung nach dem MVC-Muster erlaubt.
3.3.1
MVC-Muster
Das MVC-Muster (engl. Model-View-Controller Pattern) ist ein Muster
zur Strukturierung der Software in drei Einheiten: Datenmodell (Model),
Präsentation (View) und Programmsteuerung (controller). Zusätzlich zu
diesen drei Einheiten bietet ExtJS eine weitere Einheit, die aber im Allgemeinen zum Model gezählt wird: die Speicherung (Store).
Abbildung 3.6: MVC-Muster
• Das Model beschreibt die darzustellenden Daten, die meist reale
Objekte sind, und bildet eine Schnittstelle zwischen der View und
dem Store. Models können mit anderen Models durch Assoziationen miteinander verlinkt werden. Dadurch kann ein hierarchischer
Aufbau umgesetzt werden.
• Der Store ist wie erwähnt eine Teileinheit der Model-Einheit. Sie
entkapselt einen clientseitigen Cache vom Model und stellt eine
Verbindung, via einem Proxy (einer Kommunikationsschnittstelle),
mit dem Server her, der Daten beispielsweise aus einer Datenbank
anfragt, sofern nicht ein Proxy schon im Model definiert ist.
• Die View ist die visuelle Präsentation der Daten. Sie besteht aus
mehreren Komponenten, die in sich weitere Komponenten beinhalten können. Diese Strukturierung vereinfacht die Umsetzung der
Webplattform.
18
Aleksandar Stojakovic
KAPITEL 3. DIE ARCHITEKTUR
• Der Controller bildet die Steuerungseinheit. Er reagiert auf jegliche Aktionen des Programms, sei es wenn Daten geladen oder
verändert werden oder wenn an der View beispielsweise ein Knopf
betätigt wurde - der Controller ist verantwortlich dafür, was bei
diesen Aktionen passieren soll.
3.3.2
Benutzerschnittstelle
Für die Entwicklung der Benutzerschnittstelle musste die Struktur der
zu verwaltetenden Schneeprofildaten analysiert werden. Wie in Kapitel 2
beschrieben besteht das Schneeprofil aus den vier Einheiten: Metadaten,
Schichtprofil, Schneetemperaturprofil und Stabilitätstests. Jede dieser
Einheiten bildet eine Komponente der Benutzerschnittstelle.
Abbildung 3.7: Aufbau des Schneeprofils
Folglich besteht die Plattform aus vier View-Einheiten, die eigene Modelle und Stores zur Datenverwaltung benötigen. Es wird dennoch ein
eigenes Model benötigt, das das Schneeprofil als eigene Einheit darstellt - das Wurzel-Modell. Die Aufgabe des Controllers besteht nun
darin, den Zusammenhang zwischen den vier Grund-Einheiten und der
Schneeprofil-Einheit zu finden. Das heißt: wird ein Schneeprofil vom Server angefordert muss der Controller zuerst das Schneeprofil analysieren
und die Daten auf die vier Modelle der Grundeinheiten aufteilen. Erst
dann werden die Daten den einzelnen Stores zugewiesen und die Views
können auf diese zugreifen. Umgekehrt müssen beim Speichern der DaAleksandar Stojakovic
19
KAPITEL 3. DIE ARCHITEKTUR
ten in die Persistenz, diese zuerst aus den einzelnen Stores angefordert
und zu einer Schneeprofil-Einheit zusammengeführt werden ehe sie an
den Server gesendet werden.
Aufbau der Benutzerschnittstelle - GUI
Die Benutzerschnittstelle soll benutzerfreundlich und intuitiv bedienbar sein. Die Visualisierung wird daher an das propriätere DesktopProgramm des Lawinenwarndienstes von Tirol angelehnt (siehe Appendix A.3).
Abbildung 3.8: Aufbau des Schneeprofils
Die Plattform wird in drei Abschnitte unterteilt: Ein Formular für die
Metadaten, ein Tab-Panel für das Schichtprofil, Schneetemperaturprofil
und Stabilitätstests und eine Grafik-Komponente für das SchneeprofilDiagramm, das die Schneeprofildaten grafisch zusammenfasst.
Ein Tab-Panel fasst mehrere Komponenten in einen Kartei-Container
zusammen. Somit können mehrere Komponenten in die Plattform eingefügt werden für die nur ein Platz im Browser-Fenster verwendet wird.
Die drei Komponenten im Tab-Panel sind jeweils in Tabellen umgesetzt,
die jede Schicht, Temperatur oder Stabilitätstest auflistet.
3.3.3
Schneeprofil-Diagramm
Lawinenwarndienste verwenden zur Analyse von Schneeprofilen hauptsächlich ein Diagramm, das dem Diagramm unter Appendix A.2 entspricht. Die Webplattform soll folglich eine Rendering-Engine bereitstel20
Aleksandar Stojakovic
KAPITEL 3. DIE ARCHITEKTUR
len, die ein Diagramm aus den Schneeprofildaten erstellt. Sowohl Client
als auch Server greifen auf diese Rendering-Engine zu, die als JavaScriptDatei implementiert wurde, um entsprechend das Diagramm auf die Benutzerschnittstelle zu projezieren und es für den PDF-Download vorzubereiten. Der Vorteil einer zentralisierten Rendering-Engine ist die
Wartbarkeit. Sollten sich die Anforderungen des Diagramms in Zukunft
ändern, so ist diese Änderungen nur an der Rendering-Engine durchzuführen.
Die Rendering-Engine ist eine JavaScript-Funktion, die als Parameter
ein Schneeprofil im JSON-Format erhält und daraus ein Array zusammensetzt und zurückgibt. Dieses Array enthält Informationen über GrafikObjekte, wie Rechtecke, Texte und Pfade, die in sich weitere Informationen beinhalten, wie die Koordinaten in der sie positioniert werden und
ihre Größen. Diese Grafikinformationen werden von den verantwortlichen Komponenten seitens des Clients bzw. des Servers verwendet um
auf ihrer Seite das Diagramm zu erstellen.
Clientseitig
Die Benutzerschnittstelle des Clients verfügt neben den Komponenten
für die Ein- und Ausgabemaske auch über eine Komponente, die ein
Schneeprofildiagramm aus diesen Daten erstellt, indem sie auf die Rendering-Engine zugreift. ExtJS stellt dafür ein Grafik-Panel zur Verfügung,
das eine SVG-Grafik3 erstellt, welches das Schneeprofil-Diagramm repräsentiert. Dieses Grafik-Komponente ist so implementiert, dass sie
auf Veränderungen in der Eingabemaske reagiert und das SchneeprofilDiagramm in Echtzeit, also sofort nach der Änderung, aktualisiert.
Serverseitig
Wird auf der Benutzerschnittstelle der Button für den PDF-Druck betätigt, so kommuniziert der Client dem Server, dass dieser aus den
Schneeprofildaten eine Grafik erzeugen und als PDF zur Verfügung stellen soll. Der Server greift dabei auf die Rendering-Engine zurück, benötigt
aber eine Java-Implementierung, die JavaScript interpretieren kann. So
eine Implementierung bietet Rhino. Rhino hilft serverseitig die JavaScriptFunktionen auszuführen, die die Rendering-Engine bereitstellt.
Abschließend müssen die Rendering-Daten mittels eines SVG-Toolkits
gezeichnet werden. Ein Java-basiertes SVG-Toolkit ist Batik SVG Toolkit, das die Daten, die die Rendering-Engine zurückgibt, verwendet um
ein Schneeprofil-Diagramm als SVG-Grafik zu erstellen. Das Batik SVG
3
http://www.w3.org/Graphics/SVG/
Aleksandar Stojakovic
21
KAPITEL 3. DIE ARCHITEKTUR
Toolkit stellt abschließend Module zur Verfügung, die das SVG-Diagramm
in PDF konvertiert.
Batik bietet auch Module für die Konvertierung in andere Formate, beispielsweise grafische Formate wie JPG oder PNG, die in eigenen Plattformen der Lawinenwarndienste verwendet werden können.
22
Aleksandar Stojakovic
Kapitel 4
Verwendete Technologien
Dieses Kapitel beschreibt die Technologien, die für die Arbeit verwendet
wurden, allgemein und mit Beispielen zur Veranschaulichung.
4.1
XSL-Transformation
Für die Datenkonvertierung wurde die Technik der XSL-Transformation
(XSLT)12 verwendet. Dabei handelt es sich um ein Verfahren, das aus
dem Inhalt einer Datei im XML-Format mit Hilfe eines XSLT-Stylesheets
eine neue Datei, in einem beliebigen Format, erstellt.
Abbildung 4.1: XSL-Transformation
Der XSLT-Prozessor liest die propriätere Datei ein und traversiert die
1
2
http://www.w3.org/TR/xslt
http://www.w3.org/Style/XSL/
23
KAPITEL 4. VERWENDETE TECHNOLOGIEN
darin enthaltene Baumstruktur des XML-Formats. Mittels XPath 3 kann
schließlich auf einen beliebigen Pfad der in der Eingabe-Datei enthaltenen Information zugegriffen werden.
Der in diesem Projekt umgesetzte Konverter wandelt mit dieser Technik
Schneeprofildateien, welche vom Schneeprofilprogramm der Firma Sommer Mess- & Systemtechnik in einem XML Format verwaltet werden in
CAAML konforme XML-Dateien.
Listing 4.1 zeigt zur Veranschaulichung ein Teil des Inhaltes des Eingabeformats des implementierten Konverters
Listing 4.1: Code-Ausschnitt propriätere Datei
<SPP−P r o f i l>
<Kopf>
<Beobachter>Aleksandar Stojakovic</ Beobachter>
<Kopf>
</SPP−P r o f i l>
Listing 4.2 zeigt wie der Zugriff auf diesen Inhalt geschieht, nämlich
durch die Eingabe des Element-Pfades.
Listing 4.2: Code-Ausschnitt des XSLT-Stylesheets
<S n o w P r o f i l e>
<metaDataProperty>
<MetaData>
<s r c R e f>
<O p e r a t i o n g m l : i d=”SLF”>
<c o n t a c t P e r s o n>
<Person>
<name>
<x s l : v a l u e −o f s e l e c t=”SPP−P r o f i l / Kopf / Beobachter ” />
</name>
</ Person>
</ c o n t a c t P e r s o n>
</ O p e r a t i o n>
</ s r c R e f>
</ MetaData>
</ metaDataProperty>
</ S n o w P r o f i l e>
Die daraus resultierende Datei im CAAML-Format zeigt Listing 4.3.
3
24
http://www.w3.org/TR/xpath/
Aleksandar Stojakovic
KAPITEL 4. VERWENDETE TECHNOLOGIEN
Listing 4.3: Das Ergebnis der Transformation
<S n o w P r o f i l e>
<metaDataProperty>
<MetaData>
<s r c R e f>
<O p e r a t i o n g m l : i d=”SLF”>
<c o n t a c t P e r s o n>
<Person>
<name>Aleksandar Stojakovic</name>
</ Person>
</ c o n t a c t P e r s o n>
</ O p e r a t i o n>
</ s r c R e f>
</ MetaData>
</ metaDataProperty>
</ S n o w P r o f i l e>
4.2
JSON
JSON (JavaScript Object Notation) ist ein immer populärer werdendes und kompaktes Datenformat für semistrukturierte Daten[Bun97],
das entwickelt wurde um einen einfachen Datenaustausch zwischen Anwendungen zu gewährleisten. Die Syntax entspricht der Skriptsprache
JavasScript. JSON zeigt sich dadurch aus, das es durch seine KeyValue-Struktur von Mensch und Maschine einfach les- und beschreibbar ist. Außerdem geht JSON, im Vergleich zu XML, sparsamer mit
Speicherplatz und CPU-Leistung um. Dies ist aus dem Aufbau von
JSON-Objekten zurückzuführen, das sich aus zwei Grundtypen zusammensetzt: Objekte und Arrays. Diese Struktur führt dazu, dass sie eine
einfache und klare Syntax besitzt. Der Zugriff auf Inhalte ist eindeutig.
Ein Beispiel für eine JSON-Datei zeigt Listing 4.4. Um den Vergleich
mit XML zu erkennen wurde das Beispiel von Listing 4.1 verwendet
bzw. mit Schichten erweitert um beide Grundtypen (Objekte und Arrays) zu veranschaulichen:
Listing 4.4: JSON-Beispiel
{
”SPP−P r o f i l ” : {
” Kopf : {
” Beobachter ” :
},
” Schichten ” : { [
{ ” Schicht1 ” :
{ ” Schicht2 ” :
{ ” Schicht3 ” :
]}
Aleksandar Stojakovic
” Aleksandar Stojakovic ”
” Schicht 1 ” } ,
” Schicht 2 ” } ,
” Schicht 3 ” }
25
KAPITEL 4. VERWENDETE TECHNOLOGIEN
}
}
4.3
REST
Representational State Transfer oder REST ist ein Architekturparadigma für Client-Server Applikationen, welche es dem Client ermöglicht
über ein klar definiertes Set an Operationen den Zustand eindeutig addressierbarer Resourcen abzufragen, neu zu erstellen, zu manipulieren
und zu löschen. Ein Beispiel für ein REST basiertes System ist HTTP
und das darauf basierende World Wide Web.
4.3.1
Prinzipien
Es gibt fünf Prinzipien die einen REST-Dienst ausmachen:[Fie00]
• Adressierbarkeit: Jeder REST-konformer Server stellt ein Set von
eindeutig adressierten Ressourcen bereit. Diese werden über eine
eindeutige URL angesprochen.
• Unterschiedliche Repräsentationen: Jede Ressource die über eine
Adresse angefordert wird, kann auf verschiedene Weisen dargestellt
werden. Dem Client liegt es frei die Art der Repräsentation, den
Typ, auszuwählen. Solche Typen sind beispielsweise HTML, XML
oder JSON - die genaue Repräsentation wird zwischen Client und
Server ausgehandelt.
• Zustandslosigkeit: Jede Botschaft die über REST geschieht enthält
alle notwendigen Informationen einer Nachricht. REST nimmt hierbei die Verantwortung der clientseitigen und serverseitigen Anwendungen die Informationen selbst zu verwalten. Dadurch kann ein
Webservice als zustandslos bezeichnet werden. Dies hat den Vorteil, dass jede Nachrichten-Transaktion unabhängig voneinander
zu behandeln ist.
• Operationen: Dienste die REST verwenden müssen ein einheitliches Set von Operationen zur Verfügung stellen anhand derer
Ressourcen manipuliert werden können. HTTP zum Beispiel definiert folgende Operationen: GET, POST, PUT und DELETE. In
Verbindung mit der URL wird auf eine bestimmte Ressource eine
Methode ausgeführt, die nach bestimmten Regeln ablaufen sollen.
GET beispielsweise muss “sicher“ sein. D.h., dass diese Methode nur Informationen holt und keine sonstigen Aktionen ausführt.
Während die restlichen Methoden beim mehrfachen ausführen der
26
Aleksandar Stojakovic
KAPITEL 4. VERWENDETE TECHNOLOGIEN
gleichen Anforderung wie ein einzelner Aufruf verhält - dies wird
als indempotent bezeichnet.
• Verwendung von Hypermedia: Bei einer Anfrage eines Clients werden nicht nur die benötigten Daten als Antwort gesendet, sondern
auch Adressen auf Ressourcen, welche verlinkt sind, damit die Anwendung weiß welchen Schritt sie als nächstes durchzuführen hat.
Zum Bsp. eine Liste von Benutzern, die pro Benutzer eine Adresse
zur Benutzerinformation bereitstellt.
4.3.2
Beispiel
Listing 4.5: REST: Anfrage einer clientseitigen Anwendung
GET / customers /123 HTTP : 1 . 1
Host : example . com
Accept : application / json
Listing 4.5 veranschaulicht eine Anfrage über eine REST-basierte HTTPSchnittstelle, welche die Kundendaten eines spezifischen Kunden im
JSON-Format erhalten möchte. Als Operation wurde GET gewählt,
d.h. die Anwendung will Daten von einem Server anfragen. Dies geschieht über eine URL, /customers/123 des Hosts example.com. Der
Repräsentationstyp ist JSON. Kurz gesagt: der Client fordert vom Server Daten eines Customers mit der ID 123 an und will diese in Form
von einem JSON-Objekt erhalten.
4.4
ExtJS
ExtJS ist eine JavaScript-Bibliothek zur Entwicklung von Desktopähnlichen Anwendungen im Web. Es vermittelt dem Benutzer das Gefühl
nicht auf einer Webseite zu sein, sondern mit einem Programm zu arbeiten, was diesem intuitiver erscheint und die Benutzerfreundlichkeit des
Programms erhöht.
ExtJS erweitert JavaScript im Sinne der Klassenbasiertheit. Es stellt
über 300 Klassen zur Verfügung, welche Funktionen für das Erstellen
von geeigneten Benutzerschnittstellen, das clientseitige Cachen von Daten und die Manipulation derer bereitstellt. Dies ist durch die Vererbbarkeit von JavaScript möglich, was ExtJS zu einer clientseitigen objektorientierten Scriptsprache macht.
ExtJS bietet die Möglichkeit Clients nach dem MVC-Muster zu entwickeln. Es ist möglich Controller, Modelle und Views zu definieren, wobei Modelle die Struktur der Daten festlegen, Views diese mittels einer
Aleksandar Stojakovic
27
KAPITEL 4. VERWENDETE TECHNOLOGIEN
Vielzahl von GUI-Komponenten darstellen und Controller auf Ereignisse der Benutzerschnittstelle reagieren. Die Bibliothek beinhaltet dabei
unter Anderem folgende GUI-Elemente:
Formular-Elemente
• Text-Felder (einzeilig und mehrzeilig)
• Datumsfelder mit Eingabehilfe in Form eines aufklappbaren Kalenders
• Numerische Felder mit Schaltflächen für Inkrement und Dekrement
• Listenfelder und Auswahlboxen (Combobox)
• Optionsfeld (Radiobutton) und Kontrollkästchen (Checkbox)
• HTML-Eingabebereiche
Jedes Formularelement kann eigene Validierungen definieren, welche Eingaben erlaubt sind, beispielsweise keine leeren Eingaben oder nur Dezimalwerte sind erlaubt. Desweiteren stehen verschiedene vorgefertigte
Elemente, auch Widgets genannt, zur Verfügung:
Widgets
• Listendarstellung (Nur-Lese- oder mit Editierfunktion, sortierbar,
Spaltenreihenfolge änderbar)
• Baumstruktur
• Registerkarten-Darstellung
• Menüleisten
• Kontextmenüs im Aussehen des Desktop-Betriebssystems
• Dynamische Platzaufteilung der Steuerelemente
• Bildlaufleisten
• Grafiken auf SVG-Basis
Die Kommunikationsschnittstellen zum Server können über verschiedene Typen, beispielsweise Ajax oder Rest, geschehen. Dabei werden auch
Datenformate, XML oder JSON, und Handler, die Aktionen bei bestimmten Operationen, zum Bsp. lesen oder schreiben, ausführen, definiert.
28
Aleksandar Stojakovic
KAPITEL 4. VERWENDETE TECHNOLOGIEN
4.5
Rhino
Rhino ist eine Open-Source Implementierung von JavaScript, die in Java geschrieben ist. Sie bietet die Möglichkeit JavaScript-Code über eine
Java-Applikation zu kompilieren und zu interpretieren. Rhino wandelt
dabei JavaScript Skripts in Java-Klassen um und verwendet ihre Funktionen als Methoden, denen Parameter übergeben werden können und
dessen Return-Werte in der restlichen Java-Applikation verwendet und
bearbeitet werden können.
4.6
Batik
Batik ist ein Java-basiertes Toolkit zur Erstellung von SVG-Grafiken4 .
Batik bietet ein Set von Modulen die entweder gemeinsam oder individuell für SVG-Lösungen verwendet werden können. Ein Beispiel für
Batik-Module sind der SVG-DOM und der SVG-Creator, die für die serverseitige Erstellung des Schneeprofil-Diagramms verwendet wird. Das
SVG-DOM erstellt SVG-Elemente, die nach dem XML-Format aufgebaut sind und der SVG-Creator erzeugt daraus eine eigenständige SVGGrafik.
Listing 4.6 zeigt die Erstellung eines Rectangle-Elements mittels SVGDom. Dem Rechteck-Element werden x-, y-Koordinaten, Höhe, Breite
und die Füllfarbe definiert. Damit wird ein rotes Rechteck, das 10 Pixel
vom linken Rad und 20 Pixel vom oberen Rand des SVG-Dokuments
erstellt.
Listing 4.6: Beispiel-Implementierung eines Rechtecks über SVG-DOM
DOMImplementation impl = SVGDOMImplementation .
getDOMImplementation ( ) ;
Document doc = impl . createDocument ( svgNS , ” sv g ” , null ) ;
Element rectangle = doc . createElementNS ( svgNS , ” r e c t ” ) ;
rectangle . setAttributeNS ( null , ”x” , ” 10 ” ) ;
rectangle . setAttributeNS ( null , ”y” , ” 20 ” ) ;
rectangle . setAttributeNS ( null , ” width ” , ” 100 ” ) ;
rectangle . setAttributeNS ( null , ” h e i g h t ” , ” 50 ” ) ;
rectangle . setAttributeNS ( null , ” f i l l ” , ” r e d ” ) ;
4
http://www.w3.org/TR/SVG11/
Aleksandar Stojakovic
29
KAPITEL 4. VERWENDETE TECHNOLOGIEN
4.7
Dokumentenorientierte Datenbanken & OrientDB
Moderne Webapplikationen müssen aufgrund ihrer starken Verbreitung
und der Möglichkeit enorm große Benutzergruppen anzusprechen mit hohen Anforderungen an Performance und Skalierbarkeit umgehen. Durch
das Entstehen von Web 2.0 und damit verbunden die Erhöhung der
Popularität von Social Media stieg die Anzahl von Benutzern eines
Webdienstes von 10 auf mehrere Millionen Benutzer, die jeweils Informationen speichern wollen, deren Struktur nicht flach sondern hierarchisch ist. Um die Daten skalierbar zu verwalten und schnellen Zugriff
darauf zu gewährleisten benötigt es eine verteilte Datenbank. So eine
Shared-Nothing-Architektur bietet dabei nicht nur einen Knoten für die
Verbindung zur Datenbank sondern mehrere Knoten die über eigene
Prozessoren verfügen. Zusammen ergeben sie eine zentrale Datenbank.
Im Vergleich zu Shared-Disk- und Shared-Memory-Architekturen gehen
Shared-Nothing-Architekturen besser mit der Skalierbarkeit über verteilte Maschinen und der Entfernung zwischen den Maschinen um. Die
Konsistenz der Daten ist dabei aber nicht gegeben.
Ein daraus resultierendes Datenbanksystem ist das dokumentenorientierte Datenbanksystem (DODBS), das zu den zentralen NoSQL- Technologien zählt. Anders als bei relationalen Datenbanksystemen arbeiten
DODBS nicht mit Tabellen sondern mit Dokumenten. Die Daten in einem Dokument werden in Form von Key/Value-Paaren gespeichert. Das
heißt es besteht aus Schlüsselfeldern, denen bestimmte Werte zugewiesen werden. Das Wort Wert bezeichnet hier nicht ein atomares Datum
sondern eine beliebige Information, die auch ein Array sein kann oder
ein weiteres geschachteltes Datum. An dieser Stelle erkennt man eine
Analogie zum vorher beschriebenen JSON-Format.
In DODBS existieren daher keine Relationen, da ein Dokument schon
alle wichtigen Informationen atomar oder geschachtelt gespeichert hat
- das Dokument ist eine geschlossene Einheit. DODBS stellen deswegen
auch keine mächtige Abfragesprache zur Verfügung wie SQL, da diese
nicht mehr erforderlich sind.
Die in dieser Arbeit verwendete Datenbank OrientDB erfüllt die Bedingungen einer verteilten, skalierbaren und flexiblen dokumentenorientierten Datenbank.
30
Aleksandar Stojakovic
KAPITEL 4. VERWENDETE TECHNOLOGIEN
Vergleich mit relationalen Datenbanksystemen
Ein Grundgedanke hinter DODBS ist zusammengehörige Daten auch gemeinsam zu speichern. Ein relationales Datenbanksystem (RDBS) speichert Daten in verschiedenen Tabellen. Informationen die entfernt zusammengehören müssen darum aufwendig mit Techniken der Abfragesprache SQL verbunden werden oder weitere Tabellen erstellen, die die
Beziehung zweier Tabellen beschreibt. Diese drei Tabellen müssen wiederrum mit SQL verbunden werden um die gewünschte Repräsentation
der Daten zu erhalten. Diese Art von Datenabfragen kosten bei großen
Datenmengen und einer Vielzahl von Nutzern sehr viel Speicher und
Zeit.
Das CAP-Theorem besagt, dass eine Unvereinbarkeit der drei wichtigsten Ziele, Konsistenz, Verfügbarkeit im Sinne schneller Antwortzeiten und Ausfalltoleranz von verteilten DBS vorliegt [JCA10]. Laut
diesem Theorem können nur zwei Ziele erreicht werden - auf eins muss
bei der Entwicklung verzichtet werden. Während RDBS sich auf die Konsistenz konzentriert, und dabei die Verfügbarkeit vernachlässigt, stellen
DODBS die Antwortzeiten in den Vordergrund und nehmen vorübergehende Phasen von Inkonsistenz auf.
Spätestens seit dem Aufschwung von Web 2.0, dem Voranschreiten von
Social Media, wie Facebook und Twitter, können sich NoSQL-System
mit den RDBS messen.
Aleksandar Stojakovic
31
Kapitel 5
Ausblick
Die Webplattform zur Verwaltung von Schneeprofilen ist initial für den
Lawinenwarndienst von Tirol entwickelt worden. Aktuell befindet sich
die Plattform im Testbetrieb und soll nach einem intensiven Bugfix und
einer Quality Assurance (QA) -Phase mit der Wintersaison 2012 in den
Regelbetrieb, zunächst für eine eingeschränkte Benutzergruppe im LWD
von Tirol, übergeführt werden. Darauffolgend wird die Internationalisierung der Arbeit vorangetrieben. Die Webplattform wird auf Mehrsprachigkeit erweitert und es werden weitere Optimierung durchgeführt um
ein einwandfreies Arbeiten über Ländergrenzen hinweg zu gewährleisten.
Die Webplattform soll weltweit zu einer Basisplattform zur Verwaltung
von Schneeprofilen werden. Auf dieser Grundlage werden weitere Punkte wie automatisches Analysieren der Schneeprofile für die Einschätzung
der Lawinensituation, eine Erweiterung der Datenstruktur in Kombination mit Wetterstationsdaten und die Entwicklung eines Mobile Clients
zur Eingabe mittels HTML5 vor Ort und automatischer GPS-Erkennung
entwickelt. Auch wird der Einbezug von weiteren Lawinenwarndiensten
weltweit angestrebt.
33
Kapitel 6
Zusammenfassung
In dieser Arbeit wurde die Entwicklung einer Webplattform zur Verwaltung von Schneeprofildaten erklärt. Neben der Verwaltung von Schneeprofilen liegt der Zweck der Webplattform darin die Profilaufnahme zu
zentralisieren. Es wird zunächst der Aufbau eines Schneeprofils beschrieben, die für die Entwicklung der Plattform wichtig ist um geeignete
Komponenten für das Design auszusuchen. Darauffolgend wird die Architektur der Plattform beschrieben. Es wird auf das Frontend, seine
Realisierung nach dem MVC-Muster, und das Backend, das die Datenbank bereitstellt, eingegangen. Dabei wird die Kommunikation zwischen
Backend und Frontend beschrieben und die Art und das Format des Datenaustauschs erklärt. Desweiteren wird ein Datenkonverter beschrieben,
der die vorhandenen Daten der Lawinenwarndienste, die im propriäteren
Format vorliegen, in das neu entwickelte CAAML-Format umwandelt.
Es wird die verwendete Technologie im Detail erklärt und schlussendlich
ein Ausblick gewährt wie der Einsatz der Webplattform für die Zukunft
aussieht.
35
Appendix
A.1
Schneeprofildaten im JSON-Format
{” SnowProfile ” : {
” l o c R e f ” : { ” ObsPoint” : {
” d e s c r i p t i o n ” : ”” ,
”name” : ” ” ,
” obsPointSubType ” : ” ” ,
” pointLocation ” : {” gml Point ” : {
” gml id ” : ”” ,
” gml pos ” : ” ” ,
” srsDimension ” : ”” ,
” srsName ” : ” ”
}} ,
” validAspect ” : {” AspectPosition ” : {” p o s i t i o n ” : ”” }} ,
” v a l i d E l e v a t i o n ” : {” E l e v a t i o n P o s i t i o n ” : {
” p o s i t i o n ” : ”” ,
”uom” : ” ”
}} ,
” v alid S lop eA n gle” : {” S lop eA n glePosit ion” : {
” p o s i t i o n ” : ”” ,
”uom” : ” ”
}}
}} ,
” metaDataProperty ” : { ” MetaData ” : {
” dateTimeReport ” : ” ” ,
” srcR ef ” : {” Operation” : {
” c o n t a c t P e r s o n ” : { ” Person ” : {
”name” : ” ”
}} ,
”name” : {}
}}
}} ,
” on lin e ” : ”” ,
” s n o w P r o f i l e R e s u l t s O f ” : { ” SnowProfil eM e a sur em en ts ” : {
” airTempPres ” : {
” content ” : ”” ,
”uom” : ”degC”
},
”comment” : ” ” ,
” densityProfile ” : {
37
APPENDIX A.1. SCHNEEPROFILDATEN IM JSON-FORMAT
” uomDensity ” : ”kgm−3” ,
”uomDepthTop ” : ”cm” ,
” uomThickness ” : ”cm”
},
” d i r ” : ” bottom up” ,
”hS” : { ” Components” : { ” snowHeight ” : {
” content ” : ”” ,
”uom” : ”cm”
}}} ,
” hardnessProfile ” : {
”uomDepthTop ” : ”cm” ,
” uomDropHeight ” : ”cm” ,
” uomHardness” : ”N” ,
” uomThickness ” : ”cm” ,
”uomWeightHammer” : ” kg ” ,
”uomWeightTube ” : ” kg ”
},
” precipTI ” : ”” ,
” profileDepth ” : {
” content ” : ”” ,
”uom” : ”cm”
},
” skyCond” : ” ” ,
” stbTests” : {
”ComprTest ” : [ ] ,
” ExtColumnTest ” : [ ] ,
” RBlockTest ” : [ ]
},
” s t r a t P r o f i l e ” : { ” Lay er ” : [ ] } ,
” tempProfile” : {
”Obs” : [ ] ,
”uomDepth” : ”cm” ,
”uomTemp” : ”degC”
},
” windDir ” : { ” A s p e c t P o s i t i o n ” : { ” p o s i t i o n ” : ” ” } } ,
” windSpd” : {
” content ” : ”” ,
”uom” : ”ms−1”
}
}} ,
” v a l i d T i m e ” : { ” T i m e I n s t a n t” : { ” t i m e P o s i t i o n ” : ” ” } } ,
” xmlns app ” : ” h t t p : / /www. s n o w p r o f i l e a p p l i c a t i o n . com” ,
” x mlns caaml ” : ” h t t p : / /www. caaml . o r g / v5 . 0 / S n o w p r o f i l e /IACS” ,
” xmlns gml ” : ” h t t p : / /www. o p e n g i s . n e t / gml” ,
” x m l n s x s i ” : ” h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ” ,
” x s i s c h e m a L o c a t i o n ” : ” h t t p : / / caaml . o r g / Schemas/V5 . 0 /
P r o f i l e s / SnowProfileIACS
h t t p : / / caaml . a v i s u a l a n c h e . ca / Schemas/V5 . 0 /
P r o f i l e s / SnowprofileIACS / CAAMLv5 SnowProfileIACS . xsd ”
}}
38
Aleksandar Stojakovic
APPENDIX A.2. SCHNEEPROFIL-GRAFIK
A.2
Schneeprofil-Grafik
Die folgende Grafik fasst alle Schneeprofildaten visuell zusammen. Am
Anfang werden die Metadaten zusammengefasst, die gefüllten Rechtecke
zeigen die jeweiligen Schichten des Schichtprofils, der rote Pfad zeigt den
Verlauf der Schneetemperatur in Abhängigkeit von der Schneehöhe bzw.
-tiefe. Zu jeder Schicht werden der Wassergehalt (Feuchte), die Kornformen, die Korngröße und Härte angezeigt, die manuell im Schichtprofil
eingegeben wurden. Der Punkt Niete wird aufgrund der SchichtprofilEingabe automatisch generiert - die Anzahl der Sterne, also *, ergibt
sich aus der Anzahl der zutreffenden Nietentest-Kriterien, die in der
Einleitung beschrieben wurden. Zum Schluss folgen die Stabilitätstests.
Aleksandar Stojakovic
39
APPENDIX A.2. SCHNEEPROFIL-GRAFIK
40
Aleksandar Stojakovic
APPENDIX A.3. BENUTZERHANDBUCH
A.3
Benutzerhandbuch
Die Webplattform wird nach der Testphase auf einem vom Lawinenwarndienst von Tirol bereitgestellten Server installiert. Bei der Benutzung der
Webplattform soll dieses Benutzerhandbuch helfen, das alle Seiten und
Funktionen erklärt.
Login
Jeder Benutzer erhält einen Benutzernamen und ein Passwort mit der
er in die Plattform einsteigen kann. Es wird zwischen Administrator,
der Vollzugriff auf die Plattform hat, und gewöhnlichen Benutzer, der
Einschränkungen unterliegt, unterschieden. Der Administrator ist in der
Anfangsphase für die Überprüfung der Schneeprofildaten zuständig und
kann diese Sperren lassen um gewöhnlichen Benutzern den Zugang darauf zu verwehren. Nach dem erfolgreichen Login wird der Benutzer auf
die Übersichtsseite verlinkt. Jede Seite nach dem Login verfügt über
einen Logout-Button, der den Benutzer vom System abmeldet.
Schneeprofil - Übersicht
Die Übersichtsseite listet alle Schneeprofile auf mit der Möglichkeit ein
neues Schneeprofil zu erstellen und vorhandene Schneeprofile zu bearbeiten oder zu löschen. Das Löschen eines Schneeprofils bewirkt nur das
Löschen aus der Datenbank - es wird dabei auf keine andere Seite hinverlinkt, während beim neu Erstellen bzw. Bearbeiten eines Schneeprofils
auf die Eingabemaske und damit der wichtigsten Maske der Webplattform verlinkt wird.
Aleksandar Stojakovic
41
APPENDIX A.3. BENUTZERHANDBUCH
Schneeprofil - Eingabemaske
Diese Eingabemaske besteht aus den in der Architektur beschriebenen
Komponenten: Metadaten, Schichtprofil, Schneetemperaturprofil, Stabilitätstests und dem Schneeprofil-Diagramm.
Im Folgenden sind die Komponenten: Metadaten, Schichtprofil, Schneetemperaturprofil und Stabilitätstests genauer aufgezeigt. Die Bedeutung
der Felder und ihr Einfluss auf das Schneeprofil wird im Kapitel 2 erklärt.
Zuerst werden die Metadaten mittels einem Speichern-Button gespeichert, damit das Schneeprofil eine ID erhält. Erst dann ist die Eingabe
der anderen Komponenten möglich.
Desweiteren stehen Buttons für den PDF-Druck der Schneeprofil-Diagramm,
dem Import von CAAML-Daten in das System und dem Export der
Schneeprofildaten als CAAML-Dateien. Abschließend ist ein Zurück Button vorhanden um auf die Übersichtsseite zu gelangen.
42
Aleksandar Stojakovic
APPENDIX A.3. BENUTZERHANDBUCH
Metadaten
Die Komponenten für Schichtprofil, Schneetemperaturprofil und die Stabilitätstests sind jeweils Tabellen, die die jeweiligen Daten aufzeigen.
Jede Zeile ist durch Doppelklick editierbar, während es für jede Tabelle
jeweils zwei Buttons zur Verfügung stehen - eine für das Einfügen einer
neuen Zeile und eine für das Löschen einer Zeile zuständig ist.
Schichtprofil
Aleksandar Stojakovic
43
APPENDIX A.3. BENUTZERHANDBUCH
Schneetemperaturprofil
Stabilitätstests
Das Schneeprofil-Diagramm ist im Appendix A.2 ersichtlich.
44
Aleksandar Stojakovic
Literaturverzeichnis
[Bun97]
P. Buneman: Semistructured Data, 1997, pages 117–121.
[Fie00]
R. T. Fielding: Architectural Styles and the Design of
Network-based Software Architectures, Ph.D. thesis, University of California, Irvine, 2000.
[Fie09]
The International Classification for Seasonal Snow on
the Ground (Draft), International Hydrological Programme
(IHP) of the United Nations Educational, Scientific and Cultural Organization (UNESCO), 75732 Paris Cedex 15, France, 2009.
[fSuLS]
W. I. für Schnee-und Lawinenforschung SLF: Schneeund Lawineninfo - Erläuterungen, http://www.slf.ch/
lawineninfo/schneeinfo/sds/erlaeuterungen_DE, [Online; accessed 18-September-2012].
[fWSuLW] E. F. für Wald Schnee und Landschaft WSL:
Schweizer
Interpretation
Schneedeckenuntersuchungen,
http://www.wsl.ch/info/mitarbeitende/
schweizj/publications/Schweizer_Interpretation_
Schneedeckenuntersuchungen.pdf, [Online;
accessed
18-September-2012].
[JCA10]
N. S. J. Chris Anderson, Jan Lehnardt: The Cap Theorem,
O’REILLY, 2010, pages 12–13.
45