GUI Entwicklung eines Labor-Service

GUI Entwicklung eines Labor-ServiceSystems zur Darstellung von
Überwachungsdaten und grafischer
Auswertung
eingereicht am 12.01.2011
von
Martin Guse | Voßstraße 65 |18059 Rostock
Matrikel-Nr.: 5200097
Betreuer:
Dipl.-Wirt.--Ing. Benjamin Wagner
Dipl.-Ing. Christian Fabian
Betreuender Hochschullehrer:
Prof. Dr.-Ing. Dirk Timmermann
Projektarbeit
Fakultät für Informatik und Elektrotechnik
Inhaltsverzeichnis
Abbildungsverzeichnis...............................................................................................................iv
Tabellenverzeichnis.....................................................................................................................v
1.
Einleitung.....................................................................................................................................1
1.1 Thematischer Hintergrund und Zielstellung..............................................................................1
1.2 Gliederung der Arbeit................................................................................................................1
2. Grundlagen..................................................................................................................................3
2.1 Sensor Web Enablement............................................................................................................3
2.1.1 Sensor Observation Service...............................................................................................4
2.1.2 SensorML – Sensor Model Language................................................................................8
2.1.3 O&M – Observation and Measurements..........................................................................10
2.2 Web-2.0-Anwendungsentwicklung mit dem Google Web Toolkit..........................................12
2.2.1 GWT Java-nach-JavaScript-Kompiler.............................................................................13
2.2.2 GWT Development Mode...............................................................................................14
2.2.3 Google Web Toolkit API-Klassenbibliothek....................................................................16
2.2.4 GWT-Einstieg an einem kleinen Beispiel........................................................................18
2.3 Das User-Interface-Framework ExtGWT................................................................................23
2.3.1 Widgets des ExtGWT.......................................................................................................24
2.4 OX-Framework als Bindeglied zwischen Sensor Observation Service und Java-Servlet.......25
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein
ortsbasiertes Servicesystem......................................................................................................28
3.1 Das Einsatzumfeld – Hard- und Software für das ortsbasierte Servicesystem........................29
3.1.1 Sensorknoten und Fox-Board als Datenquelle für den Sensor Observation Service.......30
3.1.2 SOS-Implementierung von 52° North..............................................................................33
3.1.3 UroSweClient als Container für die grafische Oberfläche...............................................33
3.1.4 UroSweClient-Portlet-Schnittstelle für die GUI..............................................................34
3.2 SOSGui – Struktur der Quellen...............................................................................................37
3.2.1 Serverpaket der SOSGui..................................................................................................38
3.2.2 Clientpaket der SOSGui...................................................................................................38
3.3 SOSGui – Klassenentwurf.......................................................................................................39
3.3.1 Serverpaket.......................................................................................................................39
3.3.2 Clientpaket.......................................................................................................................40
4. Zusammenfassung und Ausblick.............................................................................................42
Anhang.......................................................................................................................................43
Literaturverzeichnis..................................................................................................................52
iii
Abbildungsverzeichnis
Abbildung 2.1: OpenGIS-Spezifikationen des Sensor Web Enablement.............................................3
Abbildung 2.2: Profile des Sensor Observation Service und die dazugehörigen Operationen............4
Abbildung 2.3: Schema einer GetCapabilities Antwort.......................................................................5
Abbildung 2.4: Inhalt eines SensorML-Dokumentes...........................................................................9
Abbildung 2.5: Struktur eines SensorML-Dokumentes.....................................................................10
Abbildung 2.6: Elemente eines O&M-Dokumentes...........................................................................11
Abbildung 2.7: Elemente des result-Abschnittes in einem O&M-Dokument....................................12
Abbildung 2.8: GWT-Kernkomponenten...........................................................................................13
Abbildung 2.9: Verzeichnisstruktur eines war-Files...........................................................................14
Abbildung 2.10: GWT Development Mode window.........................................................................15
Abbildung 2.11: Browser-Fenster mit GWT-Beispiel-Anwendung...................................................16
Abbildung 2.12: GWT-Projekt-Struktur.............................................................................................18
Abbildung 2.13: Klassen für den RPC-Service..................................................................................20
Abbildung 2.14: GWT-Beispiel nach Ausführung eines RPC............................................................23
Abbildung 2.15: Widget-Beispiele im Ext GWT Explorer Demo......................................................24
Abbildung 2.16: Drei-Stufen-Architektur des OX-Frameworks........................................................26
Abbildung 3.1: Ablauf eines Versuches..............................................................................................28
Abbildung 3.2: Frontend der SOSGui................................................................................................29
Abbildung 3.3: Struktur eines Sensornetzes.......................................................................................30
Abbildung 3.4: Zusammenwirken der Komponenten eines Sensorknotens.......................................30
Abbildung 3.5: Sensorknoten aus Battery Board und Target Board..................................................31
Abbildung 3.6: UroSweClient als Container für die GUI..................................................................34
Abbildung 3.7: Ablauf beim Zugriff auf eine Funktion der Oberfläche............................................35
Abbildung 3.8: SOSGui Paketstruktur...............................................................................................37
Abbildung 3.9: SOSGui Schichten des Serverpaketes.......................................................................38
Abbildung 3.10: SOSGui Schichten des Clientpaketes......................................................................39
iv
Tabellenverzeichnis
Tabelle 2.1: Antwort-Felder des Observation Offering........................................................................6
Tabelle 2.2: Parameter für die DescribeSensor-Operation...................................................................7
Tabelle 2.3: Parameter der GetObservation-Operation........................................................................8
Tabelle 2.4: GWT-Widget-Sammlung................................................................................................17
Tabelle 3.1: Funktionen zur Messwertanalyse 1................................................................................28
Tabelle 3.2: Funktionen zur Messwertanalyse 2................................................................................29
Tabelle 3.3: Hardware des eZ430-RF2480 Demo Kit........................................................................31
Tabelle 3.4: Interne Peripherie des MSP430F2274............................................................................32
v
1. Einleitung
1. Einleitung
1.1 Thematischer Hintergrund und Zielstellung
Die Laborautomatisierung in einem Analytiklabor soll Operationen wie Temperieren und Dosieren
sowie Überwachen von Messwerten automatisiert durchführen. Ziele der Automatisierung ist die
Senkung von Kosten durch eine Parallelisierung der Laborprozesse sowie Erhöhung der Reproduzierbarkeit durch immer gleich bleibende Arbeitsschritte.
Diese Anforderungen erfordern eine Spezialisierung der Automatisierungseinrichtung. Dem gegenüber steht, dass eine schnelle Wiederverwendbarkeit des Laborreaktors eine gewisse Flexibilität der
Messeinrichtung erfordert um die unterschiedlichen Prozessparameter mit notwendigen Genauigkeit
zu erfassen.
Durch eine Automatisierung von Prozessabläufen ist der Mensch nicht mehr direkt am Prozess beteiligt. Dies erfordert eine nachvollziehbare, durchgängige Überwachung.
Um diesen Erfordernissen zu genügen, wurde im Rahmen der Diplomarbeit von Dipl.-Wirt. Ing.
Benjamin Wagner ein ortsbasiertes Servicesystem entwickelt [1], welches die Arbeit des Laborpersonals unterstützen soll. Die geforderte Flexibilität der Messeinrichtung wurde durch den Einsatz
von drahtlosen Sensorknoten in einem Sensornetzwerk sicher gestellt. Diese Sensorknoten sollen
Parameter der Umgebung, wie zum Beispiel die Temperatur, Kohlenmonoxid- oder Wasserstoffgehalt, erfassen. Da die Sensoren über eine Funkschnittstelle die Messwerte an eine Basisstation übertragen, ist es notwendig, dass diese Sensorknoten über ein Verfahren zur Ortsbestimmung verfügen,
um jedem Messwert auch einem Messzeitpunkt zuordnen zu können.
Ziel dieser Arbeit ist die Entwicklung einer grafische Oberfläche, die es dem Laborpersonal ermöglicht unkompliziert auf aktuelle und historische Messwerte des Sensornetzwerkes zuzugreifen. Dieses grafische Benutzerinterface soll sich in die, im Rahmen einer Vorentwicklung entstandenen
Oberfläche einbinden. Dazu ist die Portletarchitektur1 des Gesamtsystems entsprechend zu erweitern. Die Umsetzung erfolgte mit Hilfe des Google Web Toolkits als JavaScript-Anwendung, die in
jedem Webbrowser lauffähig ist. Um eine ansprechendes und einheitliches Design der Oberfläche
zu erhalten, wurde auf die Bibliothek ExtGWT zurück gegriffen.
Der Nutzer soll die Möglichkeit erhalten Sensordaten visualisiert darzustellen. Die ExtGWT-Bibliothek bietet hier eine einfache Möglichkeit Messwerte als Diagramm zu anschaulich zu machen.
Durch umfassende Auswertemöglichkeiten soll der Anwender in die Lage versetzt werden, auch
nicht offensichtliche Zusammenhänge zwischen verschiedenen Messkurven zu erkennen.
1.2 Gliederung der Arbeit
Basis für diese Arbeit bildet der Sensor Observation Service als Bestandteil der Sensor Web Enablement. Kapitel 2.1 liefert eine Einordnung dieses Service in das Sensor Web Enablement. Kapitel
2.1.1 befasst sich genauer mit dem Sensor Observation Service und dessen Operationen. In den anschließenden beide Kapiteln werden die Informationsschemas des Sensor Web Enablement beleuchtet, die vom Sensor Observation Service verwendet werden.
1In einer Portletarchitektur können beliebige Komponenten einer Benutzeroberfläche kombiniert werden. Portlets
stellen Codefragmente zur Verfügung, die auf einer Portalseite zusammengefügt werden.
1
1. Einleitung
In Kapitel 2.2 wird das Google Web Toolkit beschrieben, welches die Basis für die Visualisierung
bildet. Der Java nach JavaScript-Kompiler ist die Hauptkomponente des GWT und wird in Kapitel
2.2.1 beschrieben. Anschließend wird auf die Entwicklung von GWT-Anwendungen mit Hilfe des
GWT Development Mode eingegangen. Ein weitere Bestandteil des Google Web Toolkit ist dessen
Klassenbibliothek. Kapitel 2.2.3 beleuchtet diese. Im letzten Kapitel über das Google Web Toolkit
wird eine kleine Beispielanwendung vorgestellt, die die in vorherigen Kapiteln beschriebenen Mittel einsetzt.
Für die Gestaltung der Oberfläche wird das User Interface Framework ExtGWT von Sencha Inc.
benutzt. Eine Übersicht liefert Kapitel 2.3. Die Widgets des Frameworks und deren Arbeitsweise
beschreibt Kapitel 2.3.1.
Als letztes Kapitel der Grundlagen wird das OWS Access Framework von 52° North untersucht. Es
ist das Bindeglied zwischen dem Sensor Observation Service und der GWT-Gui.
Ziel dieser Arbeit ist ein Grafisches Benutzerinterface in der Laborautomatisierung. In Kapitel 3
wird die Umsetzung und die Probleme dabei beschrieben. Zuerst wird ein Überblick über die zu
Grunde liegende Hard- und Software gegeben. Die Datenquelle ist Thema in Kapitel 3.1.1. Der Leser soll in die Lage versetzt werden, die Struktur der Daten im Sensor Observation Service zu verstehen, um sie später erweitern zu können. Der SOS ist nur die Spezifikation einer Schnittstelle. Kapitel 3.1.2 liefert Informationen über die Implementation. Die letzten beiden Kapitel befassen sich
mit dem UroSweClient, der diese Gui am Ende aufnehmen soll. Besonders wichtig ist hier das Kapitel 3.1.4, wo die Schnittstelle zur Einbindung der Oberfläche beschrieben wird.
Die Struktur der Anwendung wird in 3.2 beschrieben. Jeweils ein Kapitel widmet sich dem Serverpaket und eines dem Clientpaket.
Auf die Quellen und deren Besonderheiten wird in 3.3 eingegangen.
Ergebnisse und Möglichkeiten werden im vierten Kapitel Zusammenfassung und Ausblick beschrieben.
2
2. Grundlagen
2. Grundlagen
2.1 Sensor Web Enablement
Ein Sensor Web bietet Zugriff auf das Sensornetzwerk und deren aufgezeichneten Daten durch Nutzung standardisierter Protokolle und Programmierinterfaces. Das Open Geospatial Consortium Inc.
begann unter dem Namen Sensor Web Enablement die Entwicklung eines Frameworks aus offenen
Standards um auf beliebige Sensordaten aus dem Netz zuzugreifen.
Durch Nutzung der Hyper Text Markup Language und dem Hypertext Transfer Protocol ist es möglich beliebige Informationen im Internet zur Verfügung zu stellen. Das Rahmenwerk bietet Schnittstellen um Sensoren zu finden, diese zu steuern sowie Sensordaten auszutauschen. Der Standard benutzt dazu eine Reihe von OpenGIS-Spezifikationen. [2][3] In den Informationsmodellen sind Sensoren oder Messdaten als Metadaten mit ihrer Kodierung gespeichert. Die Servicemodelle beschreiben die angebotenen Dienste durch Nutzung der Informationsmodelle.
Abbildung 2.1: OpenGIS-Spezifikationen des Sensor Web Enablement
Zur Beschreibung von Sensoren wird das XML-Schema Sensor Model Language eingesetzt. Das
SensorML-Dokument enthält Prozessmetadaten, Basisinformationen, räumliche oder zeitliche Einschränkungen, Fähigkeiten und Charakteristiken der Prozesse, Kontaktinformationen sowie Referenzen.
Observation & Measurement spezifiziert Beobachtungen und Messungen. Dies können aktuelle
(Echtzeit-)Werte sein oder auch abgespeicherte Werte. Auch hier wird XML zur Beschreibung eingesetzt.
Die Transducer Markup Language wird genau wie O&M zur Beobachtung und Messung eingesetzt.
Durch die Übertragung von Datenblöcken als Cluster eignet es sich gut für die Übertragung von
Datenströmen, wie beispielsweise Kameraaufnahmen.
3
2. Grundlagen
2.1.1 Sensor Observation Service
Der Sensor Observation Service ist das Kernmodul des Sensor Web Enablement. Um auf Sensoren,
Sensordaten und Messwerte zuzugreifen, stehen verschiedene Schnittstellen zur Verfügung. Diese
Schnittstellen sind in Profile eingeteilt, das Core Operations Profile, das Transactional Operations
Profile und das Enhanced Operations Profile. Für eine dem Standard entsprechende Implementierung ist nur das Core Operations Profile notwendig, die anderen beiden Profile sind hinreichend. In
jedem Profil sind Operationen für den Sensor Observation Service definiert. Eine Übersicht der
Operationen und Profile ist in der Abbildung 2.2 zu sehen.
Die am häufigsten eingesetzte Operation des Core Operations Profile ist GetObservation. Sie liefert
auf Anfrage die Beobachtungswerte mit Metadaten. Die Messwerte werden im Observation & Measurement Format kodiert.
Um korrekte Anfragen an den SOS stellen zu können, sind Informationen wie zum Beispiel angebotene Operationen, Zeitraum der Messung, beobachtete Phänomene und verfügbare Sensoren notwendig. Die GetCapabilities-Operation liefert diese Informationen als XML-Beschreibung zurück.
Abbildung 2.2: Profile des Sensor Observation Service und die dazugehörigen Operationen
DescribeSensor liefert Metadaten der Sensoren im SensorML-Format. Der zurückgelieferte Datensatz enthält die Sensor ID, Position des Sensors oder auch die beobachteten Phänomene.
Die verwendeten Informationsmodelle SensorML und O&M sollen in eigenen Kapiteln genauer betrachtet werden. Im Rahmen dieser Arbeit wurden nur die Core-Operationen verwendet. Deshalb
werden folgend alle Information zur Anwendung dieser Befehle aufgezeigt. Für ausführliche Infor-
4
2. Grundlagen
mationen auch über Transactional Operations Profile- und Enhanced Operations Profile-Anweisungen empfiehlt sich das Studium von [4].
GetCapabilities
Diese Operation stellt dem Client Informationen über den spezifizierten Dienst zur Verfügung, und
stellt den Einstiegspunkt zum Zusammenstellen von Anfragen an den Sensor Observation Service
dar. Es ist der einzige Befehl der HTTP-GET zur Argumentübertragung nutzen kann. Dadurch kann
zur Testzwecken der SOS-Server direkt über einen Browser angesprochen werden. Folgende Adresse stellt einen gültigen Aufruf dar.
http://localhost:8080/52nSOSv3_WAR/sos?REQUEST=GetCapabilities&SERVICE=SOS
Per HTTP-GET werden der Adresse zwei Parameter mitgegeben. Der Wert für das REQUEST-Argument bezeichnet die Operation, die der Sensor Observation Service ausführen soll. Zur Ausführung dieser Operation ist ein zweiter Parameter notwendig. Der SERVICE-Parameter bekommt als
Wert immer „SOS“.
Die Antwort als XML-Beschreibung ist in Sektionen eingeteilt. Hier von Interesse für den Nutzer
sind die Abschnitte OperationMetadata, Filter_Capabilities und Contents.
Abbildung 2.3: Schema einer GetCapabilities Antwort
Im Abschnitt OperationMetadata sind alle Operationen aufgelistet, die der SOS-Server versteht.
Hieran kann die Clientanwendung erkennen, ob neben dem Core-Profile die Befehle weiterer Profile unterstützt werden. Für jeden Befehl sind die Parameter angegeben sowie alle gültige Parameterwerte beschrieben.
5
2. Grundlagen
Alle unterstützten Abfrageparameter des Services für die GetObservation-Operation sind im Abschnitt Filter_Capabilities aufgeführt. GetObservation ist die einzige Operation, die diese Art der
Filterung unterstützt.
Content bietet eine Auflistung aller beobachteten Phänomene. Der Client erhält beispielsweise Informationen wo sich der Sensor befindet, für welche Zeitraum Messwerte vorliegen und unter welcher Adresse diese Daten abgefragt werden können. Dieses Observation Offering enthält Pflichtfelder und optionale Felder, die in der folgenden Tabelle zusammen gefasst sind.
Name
Definition
Pflichtfeld/Häufigkeit
intendedApplication Beabsichtigte Verwendung für dieses Offering z.B.: optional
innere Sicherheit oder Ressourcenplanung
time
Zeitraum für den Messwerte vorliegen
notwendig / einmal
procedure
Verweis auf eine oder mehrere Verfahren, einnotwendig / ein- oder
schließlich Sensor-Systeme, Instrumente, Simulato- mehrmals
ren usw., die Beobachtungen in diesem Offering
zur Verfügung stellen.
DescribeSensor kann aufgerufen werden, um eine
SensorML- oder TML-Beschreibung für jedes System zu erhalten
observedProperty
Die Phänomene, die durch dieses Offering abge- notwendig / ein- oder
fragt werden können
mehrmals
featureOfInterest
Feature oder Feature-Sammlungen, die ein identifi- notwendig / ein- oder
zierbares Objekt repräsentiert, auf dem das Sensor- mehrmals
System Beobachtungen macht. Bei einem in-situ
Sensor kann dies eine Station sein, wo der Sensor
seine direkte Umgebung erfasst. Bei Fern-Sensoren
entspricht es der Fläche oder des Volumen, wo der
Messwertaufnehmer die Messwerte erfasst. Dies
kann ein anderer Standort sein, als der des Sensors.
responseFormat
MIME-Typ der Daten, die die GetObservation-An- notwendig / ein- oder
frage zurück gibt. Dies ist
mehrmals
meist text / xml; Subtyp = "om/1.0.0".
resultModel
Gibt den Namen des Ergebnistyps der Antwort der
GetObservation-Operation zurück.
optional
responseMode
Beschreibt welche Arten von Antworten für dieses
Offering möglich sind.
optional
Tabelle 2.1: Antwort-Felder des Observation Offering
DescribeSensor
Durch die GetCapabilities-Anweisung erhält man schon einen groben Überblick über alle Prozeduren aus einem Katalog. Diese High-Level-Informationen enthalten aber nur Informationen über die
beobachteten Eigenschaften, den Ort oder Kontaktinformationen.
6
2. Grundlagen
Genauere Metadaten über die Sensoren erhält man mit der DescribeSensor-Operation. Der Client
erhält einen genaue Beschreibung der Sensoren in der Sensor Model Language oder der Transducer
Markup Language.
Beim Aufruf der Operation werden innerhalb eines XML-Files an den SOS-Server Parameter zum
Bestimmen des Ausgabeformates, die Id des gewünschten Sensors, wieder der Service-Identifizierung und die Spezifikationsversion der Operation übertragen. Folgende XML-Code ist eine DescribeSensor-Anfrage an den SOS-Server.
<DescribeSensor xmlns="http://www.opengis.net/sos/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/sos/1.0
http://schemas.opengis.net/sos/1.0.0/sosAll.xsd"
service="SOS"
outputFormat="text/xml;subtype="TML/1.0""version="1.0.0">
<procedure>urn:ogc:object:Sensor:MyOrg:12349</procedure>
</DescribeSensor>
Listing 2.1: SensorML-Antwort auf eine DescribeSensor-Anfrage
Die Tabelle 2.2 beschreibt die Attribute der DescribeSensor-Anfrage.
Name
Definition
Auftreten
outputFormat OutputFormat bestimmt das gewünschte Ausgabeformat notwendig
der Operation
sensorId
Die SensorId bestimmt den Sensor von dem die Beschrei- einmal - obligatorisch
bung zurück geliefert wird. Der Wert muss einem xlink:href-Attribut einer Procedure entsprechen
service
Servicetype-Identifikator „SOS“
einmal - obligatorisch
version
Spezifikationsversion der Operation
einmal - obligatorisch
Tabelle 2.2: Parameter für die DescribeSensor-Operation
Die gültigen Werte für die Parameter erhält man aus der GetCapabilities-Operation.
Die Antwort ist ein strukturiertes Dokument, welches als SensorML-Dokument ebenfalls durch das
OpenGIS-Konsortium spezifiziert wurde. Im Kapitel 2.1.2 wird auf diese Spezifikation genauer
eingegangen.
GetObservation
Die GetObservation-Operation ist eine Anfrage an den Sensor Observation Service um Beobachtungsdaten strukturiert nach der Observation & Measurement Spezifikation zu Empfangen. Der
SOS-Server liefert auf die Anfrage die geforderten Daten oder, wenn dies nicht möglich ist, einen
Ausnahmereport.
Jede GetObservation-Anweisung enthält den Servicetype-Identifikator und die Version der Spezifikation, nach der die Operation implementiert ist. Weiter ist eine URI des Offerings notwendig. Diese wird meist aus der Id des ObservationOffering der Antwort auf die GetCapabilities-Operation
entnommen. Ebenso notwendig sind die Parameter observedProperty, der das beobachtete Phänomen bestimmt, und responseFormat, welcher das Ausgabeformat bestimmt. Auch für diese beiden
7
2. Grundlagen
Attribute stehen alle gültige Werte in der Antwort der GetCapabilities-Operation. Alle Parameter
sind in der Tabelle 2.3 beschrieben.
Name
Definition
Auftreten
service
Servicetype-Identifikator „SOS“
Einmal - obligatorisch
Version
Spezifikationsversion der Operation
Einmal - obligatorisch
SrsName
Definiert ein räumliches Referenzsystem, Einmal - optional
welches für alle Geometrischen Angaben benutzt wird.
Offering
URI für das Angebot im GetCapabilities-Do- Einmal - obligatorisch
kument
EventTime
Bestimmt den Zeitraum, für den Beobachtun- Einmal - optional
gen angefordert werden
Procedure
Bestimmt das Sensorsystem von dem Beob- Einmal - optional
achtungen angefordert werden
ObservedProperty Bestimmt das Phänomen
Ein- oder mehrmals - obligatorisch
FeatureOfInterest
Einmal - optional
Result
Hier können OGC-Filter-Ausdrücke verwen- Einmal - optional
det werden
ResponseFormat
Einmal - obligatorisch
ResultModel
Einmal - optional
responseMode
Einmal - optional
Tabelle 2.3: Parameter der GetObservation-Operation
2.1.2 SensorML – Sensor Model Language
Sensoren sind Geräte, die zum erfassen physikalischer Größen genutzt werden. Dabei gibt es eine
große Variation von Sensortypen. Die Spanne reicht von einfachen visuellen Thermometern bis zum
komplexen Elektronenmikroskop oder einem Erdbeobachtungssatelliten.
Die Sensor Model Language liefert nun ein XML-Schema, welches für diese unterschiedlichen Typen ein Definition der geometrischen und dynamischen Charakteristika sowie die Beobachtungsmerkmale möglich macht.
SensorML soll allgemeine Sensorinformationen, welche die Analyse der Daten erleichtern, zur Verfügung stellen. Die Verarbeitung und Analyse der Sensormessungen wird unterstützt. Dies XMLSchema ermöglicht eine geografische Zuordnung der gemessenen Daten und liefert Leistungsmerkmale wie beispielsweise Genauigkeit oder Schwellwert. Grundlegende Eigenschaften und Annahmen über die Sensoren werden gesammelt.
Eine Übersicht der Informationen, die einem SensorML-Dokument entnommen werden können, liefert die Abbildung 2.4.
8
2. Grundlagen
Abbildung 2.4: Inhalt eines SensorML-Dokumentes
Ein SensorML-Dokument liefert keine Hardware-Beschreibung eines Sensors, sondern ist vielmehr
ein allgemeines Schema zur Beschreibung eines funktionalen Modells des Sensors.
Eine allgemeine Beschreibung eines SensorML-Dokumentes kann [5] entnommen werden. Hier
sollen nur die für diese Arbeit notwendigen Abschnitte beleuchtet werden.
Nach einem Header folgen sechs Bereiche. Das erste Element dient zur Identifikation des Sensors.
Eingebettet in <sml:identification> enthält Der Wert dieses Elementes eine URN 2 nach folgendem Schema.
urn:ogc:object:feature:Sensor:IFGI:ifgi-sensor-1
Diese URN ist ein dauerhafter, ortsunabhängiger Bezeichner für die Ressource über die gesamte
Lebenszeit der Ressource. Sie bleibt gleich, auch wenn sich die Position des Sensors ändert – im
Gegensatz zu einer URL3, die den Standort einer Ressource bezeichnet. Ein neuer Sensor am selben
Ort bekommt eine neue URN zugeteilt.
Das <sml:capabilities> - Element beinhaltet Statusinformationen oder Informationen zur Mobilität des Sensors. Ein Feld mit dem Namen status zeigt an, ob der Sensor gerade Daten sammelt
oder nicht. Der Wert ist demnach vom Typ Boolean. Das Statusfeld mobile beschreibt ob der Sensor seine Position verändern kann oder ob er einen festen Standort hat.
Die letzte gemessene Position des Sensors kann man dem <sml:position name=“sensorPosition“> -Element entnehmen. Hier wird im Allgemeinen ein Vektor mit den Werten für jede Achse des
Koordinatensystems gespeichert. Für jede Achse ist die Bezeichnung, die Einheit der Angabe sowie
der Wert abgespeichert.
Ein Sensor kann mehrere verschiedene physikalische Werte erfassen. Unter <sml:inputs> ist die
Liste aller Phänomene, die dieser Sensor beobachtet, abgelegt. Die Phänomene, die in der Datenbank abgelegt werden, ist unter <sml:outputs> aufgeführt. In dieser Liste aufgeführte Phänomene,
müssen auch Angaben enthalten, um die Messwerte für dieses Phänomen von diesem Sensor abfra2 URN – Uniform Resource Name
3 URL – Uniform Resource Locator
9
2. Grundlagen
gen zu können. Zu diesem Zweck ist die ID für das Offering sowie eine beschreibende Bezeichnung
hinterlegt.
Ein SensorML-Dokument enthält noch einen Abschnitt <sml:components>, der aber nicht von der
verwendeten Implementierung für der Sensor Observation Service verwendet wird.
Folgende Grafik zeigt die Struktur eines SensorML-Dokuments. An Hand des im Anhang befindlichen Beispiels für so ein Dokument lässt sich diese Struktur leicht nachvollziehen.
Abbildung 2.5: Struktur eines SensorML-Dokumentes
Die Kenntnis von dem Aufbau eines solchen Dokuments, erleichtert das Verständnis für den Zugriff
auf die hier gespeicherten Informationen über das eingesetzte Rahmenwerk.
2.1.3 O&M – Observation and Measurements
Eine Observation stellt eine Zuordnung einer Anzahl, Dauer oder eines anderen Symbols an einem
bestimmten Zeitpunkt oder Zeitraum zu einem Phänomen her. Dazu werden Prozeduren benutzt,
welche meistens Instrumente oder Sensoren, aber auch Prozessketten, menschliche Beobachter, Algorithmen oder Simulationen darstellen. Die Schlüsselidee ist, dass Beobachtungsergebnisse Abschätzungen für Werte einer Eigenschaft eines bestimmten feature of interest sind. Beobachtungsbestandteile liefern Zusammenhänge oder Metadaten, welche die Auswertung und Interpretation unterstützen und die Nutzung des Ergebnisses ermöglichen.
Wie eine Observation dem Client zur Verfügung gestellt wird, soll im Folgenden beschrieben werden. Diese Informationen ermöglichen den Einsatz eines Parsers um Messwerte zu extrahieren. Der
Parser des Frameworks ist hier durch seine allgemeinen Einsatzmöglichkeiten sehr komplex. Deshalb bietet es sich an, bei konkreten Anwendungsfällen die Messwerte durch eigene Funktionen
dem Dokument zu entnehmen.
10
2. Grundlagen
In Abbildung 2.6 ist der Aufbau eines O&M-Dokumentes, wie ihn eine getObservation-Anfrage zurück liefert, dargestellt. Ein Vergleich mit dem Beispieldokument im Anhang verdeutlicht die Struktur.
Abbildung 2.6: Elemente eines O&M-Dokumentes
Das von <gml:boundedBy> eingeleitete Element enthält die Angabe eines Rechtecks, wo die Messdaten aufgenommen wurden.
Im Bereich <om:samplingTime> findet man Angaben zum Zeitbereich, wann die Messung stattgefunden haben. Hier steht, wenn mehrere Messwerte aufgenommen wurden, wann die erste Messung
getätigt wurde und wann die letzte Messung.
Unter <om:procedure> wird dem Client die URN der Prozedur, die die Daten liefert, zur Verfügung
gestellt.
Um Informationen über die Bestandteile einer Messung zur Erhalten, wir das <observedProperty>
-Element analysiert. Aus den Angaben lässt sich beispielsweise ermitteln, nach welchem Standard
Zeitangaben dokumentiert sind.
folgt eine Auflistung aller Feature Of Interests, deren Werte in diesem
Dokument zur Verfügung gestellt werden. Dazu wird zu jedem foi hier ID, Name und Position angegeben.
<om:featureOfInterest>
Der Bereich <om:result> enthält die eigentlichen Messwerte. Abbildung 2.7 veranschaulicht die
einzelnen Elemente dieses Abschnittes.
11
2. Grundlagen
Abbildung 2.7: Elemente des resultAbschnittes in einem O&M-Dokument
Die Anzahl der Messwerte kann man dem Wert im <swe:elementCount>-Element entnehmen. Es
stellt die Zeilenanzahl dar, wenn man das Datenarray als Tabelle betrachtet.
Im <swe:elementType> ist der Tabellenkopf hinterlegt. Zu jeder Spalte ist hier der Name, die Kodierung sowie eventuelle Einheiten gespeichert.
In <swe:values> sind die Zeilen der Tabelle fortlaufend als Zeichenkette hinterlegt. Wie diese Zeichenhkettette in einzelne Element zerlegt werden muss, entnimmt man dem <swe:encoding>-Element. Hier findet man die Trennzeichen, die die einzelnen Zeilen von einander trennen und auch
ein Trennzeichen für die Spalten der Tabelle. Da es lokale Unterschiede beim Dezimaltrennzeichen
gibt, ist hier auch dieses abgespeichert.
Mit diesen Informationen ist es möglich eigene Routinen für die Verarbeitung eines O&M-Dokumentes zu schreiben. Genauere Informationen erhält man durch Studium von [6] und[7].
2.2 Web-2.0-Anwendungsentwicklung mit dem Google Web Toolkit
Interaktive Anwendungen basierend auf Internettechnologien werden heute allgemein als Web-2.0
bezeichnet. Bei der Entwicklung von JavaScript-Code für solche Web-2.0-Anwendungen mangelt
es an Komfort. Der Programmierer muss auf die Vorzüge einer integrierte Entwicklungsumgebung
wie Hervorhebung von Schlüsselwörtern, Syntax-Prüfung während der Eingabe oder Codeergänzung verzichten. Eine zielgerichtete Fehlersuche ist trotz Unterstützung durch Browser-Plugins
kaum möglich.
Das Google Web Toolkit erlaubt die Entwicklung von Web-2.0-Applikationen in Java. Typsicherheit
und statische Codeanalyse im Compiler sind die Vorzüge dieser Programmiersprache, die den Programmierer bei der Arbeit unterstützen.
Der GWT-Compiler übersetzt den Javacode nach JavaScript und erzeugt eine Webseite mit eingebetteter Web-Anwendung. Der generierte Code wird optimiert, so dass das Ergebnis schneller als
handgeschriebener Code ist. Dieses auf schnelle Ausführung zugeschnittene JavaScript-Programm
ist leider nur noch schlecht lesbar. Das Skript wird auch nicht kleiner durch diese Maßnahmen.
GWT-Anwendungen sind browserunabhängig. Es werden die gängigen Browser unterstützt. Für Firefox, Internet Explorer, Opera, Safari, Chrome gibt es eigens angepasste Codeabschnitte.
12
2. Grundlagen
Die Oberflächenerzeugung wird mit GWT durch LayoutManager, ähnlich den Frameworks für
Desktopanwendungen, unterstützt. Der Web-2.0-Designer muss dazu nicht umständlich mit CSSStilen und Tabellen hantieren.
Die Hürden für den Einstieg in die Entwicklung mit dem Google Web Toolkit sind niedrig. Notwendig ist nur ein aktuelles Java Development Kit4 und das aktuelle GWT-Paket5. Von Google wird ein
Plugin für die Entwicklungsumgebung Eclipse zur Verfügung gestellt, wodurch das GWT-Framework vollständig in die Umgebung integriert wird. Aber auch für andere Java-IDEs, wie zum Beispiel Netbeans, sind solche Plugins verfügbar.
GWT ist eine Sammlung von Tools, die es ermöglichen komplexe JavaScript-Benutzerschnittstellen
in Java zu entwickeln. Die Abbildung 2.8 stellt die Kernkomponenten des Frameworks dar.
Abbildung 2.8: GWT-Kernkomponenten
2.2.1 GWT Java-nach-JavaScript-Kompiler
Das Google Web Toolkit unterstützt zwei Modi, den Production Mode und den Development Mode.
Soll eine Anwendung im Production Mode ausgeführt werden, muss sie durch den GWT-CrossCompiler von Java nach JavaScript übersetzt werden. GWT-Anwendungen werden im Production
Mode als reiner JavaScript mit HTML ausgeführt.
Der GWT-Compiler unterstützt die Mehrzahl der Sprachelemente der Programmiersprache Java.
Eine relevante Teilmenge der Java-Laufzeit-Bibliothek (JRE) wird durch die GWT-Laufzeit-Bibliothek emuliert. Wird eine Klasse oder Methode der Java-Laufzeit-Umgebung nicht unterstützt wird
eine Fehlermeldung zurück gegeben.
Da Java und JavaScript einige Unterschiede aufweisen, kann es zu einigen Problemen bei der Ausführung des kompilierten Codes kommen. Beispielsweise ist keine 1:1-Abbildung der primitiven
Datentypen möglich. Unterschiede gibt es auch bei der Ausnahmebehandlung. JavaScript bietet im
Gegensatz zu Java ebenfalls keine Möglichkeit der parallelen Thread-Ausführung.
Um den GWT-Compiler zu starten wird das Ant-Skript build.xml ausgeführt. Der Compiler erzeugt
eine Verzeichnisstruktur, die alle notwendigen Dateien zur Veröffentlichung auf einem Web-Server
enthält. Bei Bedarf wird diese Verzeichnisstruktur in einer war-Datei für die Bereitstellung zusammengefasst. Abbildung 2.9 zeigt den Inhalt so eines war-Files.
4 Ein Java Development Kit ist verfügbar unter http://www.oracle.com/technetwork/java/javase/downloads/index.html.
5 Das aktuelle GWT-Paket wird unter http://code.google.com/intl/de-DE/webtoolkit/download.html bereit gestellt.
13
2. Grundlagen
Abbildung 2.9: Verzeichnisstruktur eines war-Files
Die erste Seite, die der Client besucht, ist welcomeGWT.html. Sie wird als Host-HTML-Seite bezeichnet. Von ihr werden alle Anwendungsdaten geladen. Dazu referenziert ein <script>-Tag die
GWT-Anwendungs-Bootstrap-Datei.
In der Abbildung 2.9 ist dies die Datei org.yournamehere.Main.nocache.js . Dieses Ladeprogramm
entscheidet über die Programmversion, welche geladen wird. Grundlage für diese Entscheidung ist
der verwendete Browser und, wenn die Anwendung lokalisiert wurde, auch die Sprachversion des
Browsers oder eine anwenderspezifische Auswahlregel.
Die einzelnen Programmversionen sind die Dateien mit dem Namensschema <md5>.cache.html.
In diesem Beispiel gibt es fünf Versionen, jeweils eine optimierte Variante für einen der bereits erwähnten Webbrowser.
2.2.2 GWT Development Mode
Während der Entwicklung wird die GWT-Anwendung im Allgemeinen im Entwicklungsmodus ausgeführt. Hierbei wird die Anwendung direkt innerhalb einer Java Virtual Machine als Java-Byte-Code ausgeführt. Im GWT-Development-Mode ist es möglich Codeabschnitte während der Ausführung zu verändern. Es unterstützt den Entwickler beim Debuggen der Applikation. Abbildung 2.10
zeigt das Fenster des GWT Development Mode.
14
2. Grundlagen
Abbildung 2.10: GWT Development Mode window
Das Fenster des GWT Development Mode besitzt nach dem Start zwei Tabs. Der erste Reiter dient
zum Starten der Module. Weiter zeigt es Informationen, die nicht einem spezifischen Modul zugeordnet werden können.
Um den Browser die Anwendung anbieten zu können ist eine Anwendungsserver notwendig. Dies
kann der eingebaute Jetty-Server sein, oder ein Eigener. Der zweite Reiter zeigt die Statusnachrichten dieses Anwendungs-Web-Servers an.
Für die Darstellung des Benutzerinterfaces wird auch im Development Mode jeder Standard WebBrowser unterstützt. Einzig ein Developer Plugin muss im Browser installiert sein. Über den Button
Launch Default Browser wird das Modul in den Browser geladen. Wenn das notwendige Plugin
nicht installiert ist, wird ein Hinweis angezeigt, der auch eine Quelle zum Download des Plugins
anbietet. Nach dem Laden des Moduls in den Browser, wird ein dritter Tab mit den Logs für diese
URL angeboten. Debug-Meldungen lassen sich über die GWT.log()-Methode in diesem Fenster
ausgeben. Das Browser-Fenster ist in Abbildung 2.11 dargestellt.
15
2. Grundlagen
Abbildung 2.11: Browser-Fenster mit GWT-Beispiel-Anwendung
Eine herausragende Eigenschaft des Entwicklungsmodus ist, dass während der Entwicklungsphase
der Quellcode geändert werden kann, ohne den Entwicklungsmodus zu beenden. Bei Änderung des
Client-Codes muss der Entwickler lediglich die Änderungen speichern und im Browser den ReloadKnopf betätigen. Dadurch wird das Codefragment neu kompiliert. Wurde der Server-Code geändert,
muss das Modul neu kompiliert werden und der Restart-Button auf dem Jetty-Tab des GWT Development Modes betätigt werden. Der Anwendungsserver wird nun neu gestartet. Ein Auffrischen des
Browsers oder der Neustart des Jetty-Servers sind deutlich schneller als das Beenden und Neustarten des Development Modes.
2.2.3 Google Web Toolkit API-Klassenbibliothek
Zum Google Web Toolkit gehört die GWT-API-Klassenbibliothek. Sie stellt dem Programmierer
unterschiedliche Funktionalitäten bereit, die hier nur aufgezählt werden sollen. Tiefgreifende Informationen finden sich in [8].
Widgets und Panels des Google Web Toolkits
Bestandteil der GWT-API ist ein kleines Paket aus Widgets und Panels zur Gestaltung grafischer
Oberflächen. Tabelle 2.4 listet diese auf.
16
2. Grundlagen
Widgets
Panels
• Button
• PopupPanel
• PushButton
• StackPanel
• RadioButton
• StackLayoutPanel
• CheckBox
• HorizontalPanel
• DatePicker
• VerticalPanel
• ToogleButton
• FlowPanel
• TextBox
• VerticalSplitPanel
• PasswordTextBox • SplitLayoutPanel
• TextArea
• DockLayoutPanel
• Hyperlink
• TabPanel
• ListBox
• TabLayoutPanel
• MenuBar
• DisclosurePanel
• Tree
• SuggestBox
• RichTextArea
• Table
• TabBar
• DialogBox
Tabelle 2.4: GWT-Widget-Sammlung
Der Programmierer kann diese dynamischen und wiederverwendbaren UI-Komponenten nutzen um
zeitsparend dynamisches Verhalten wie beispielsweise Drag and Drop oder anspruchsvolle Baumstrukturen zu realisieren. Viele sinnvolle Widgets, die nicht in GWT enthalten sind, werden als externe Bibliotheken zur Verfügung gestellt. Das später noch beschriebene ExtGWT ist so eine Bibliothek. Sie ersetzt die GWT-eigenen Widgets komplett.
GWT-Internationalisierung
Durch GWT wird eine einfache Internationalisierung der Anwendung ermöglicht. Soll eine Anwendung in eine andere Sprache übersetzt werden, müssen zwei Arten von Text angepasst werden, konstante Strings und parametrisierbare Nachrichten. GWT unterstützt diese Arbeit mit drei Techniken,
Static String Internationalization, Dynamic String Internationalization und Localizable Interface,
die sich in Overhead und Aufwand unterscheiden. [9]
Testen von GWT-Anwendungen
JUnit ist eine Framework zum Testen von Java-Programmen. GWT liefert eine Integration für dieses Rahmenwerk und ermöglicht so Unit-Tests, die im Development Mode als auch im Production
Mode laufen. [10]
17
2. Grundlagen
Asynchrone Kommunikation mittels GWT-RPC
GWT-Anwendungen laufen als JavaScript im Webbrowser des Endnutzers. Wenn man nun mehr
möchte als eine rein im Client ablaufende Applikation, muss man mit dem Web-Server kommunizieren.
Gewöhnliche Webapplikationen senden eine Anfrage zum Web-Server und empfangen eine komplette HTML-Seite als Antwort. Im Gegensatz dazu wird bei einer AJAX-Anwendung im Vorfeld
das Nutzerinterface übertragen. Zum Senden und Empfangen der Nutzerdaten nutzt man asynchrone Aufrufe. Diese Trennung von Interface und Daten ermöglicht eine flüssige Bedienung, es entstehen keine wahrnehmbaren Pausen durch das nachladen von Daten. Die Bandbreite, die die Anwendung belegt, ist kleiner, da die Benutzeroberfläche nur einmal übermittelt wird.
Das Google Web Toolkit stellt zwei Techniken zur asynchronen Kommunikation zur Verfügung,
wobei die Wahl der Technik durch die zugrunde liegende Servertechnologie bestimmt wird. Ist die
Serverfunktionalität nicht in Java als Servlet implementiert, muss man JSON verwenden. Wenn diese Voraussetzung erfüllt ist, ist die Verwendung von GWT-Remote Procedure Calls die bessere
Wahl. [11]
GWT-RPC überträgt Java-Objekte zu und vom Server über HTTP. Es ermöglicht transparente Aufrufe von Methoden des Java-Servlets, ohne das sich der Programmierer um Low-Level-Details wie
beispielsweise die Serialisierung und Deserialisierung der Objekte kümmern muss.
2.2.4 GWT-Einstieg an einem kleinen Beispiel
Für dieses Beispiel wurde die NetBeans-IDE mit dem NetBeans-GWT-Plugin benutzt. Nach dem
Erzeugen eines Java-Web-Projektes für das Google Web Toolkit stellt sich die Projektstruktur wie in
Abbildung 2.12 da.
Abbildung 2.12: GWT-Projekt-Struktur
Java-Programme benötigen die main()-Methode als Einsprungpunkt. Bei GWT-Programmen ist die
onModulLoad()-Methode vergleichbar zur main()-Methode. Die Hauptklasse einer GWT-Anwendung muss das Interface EntryPoint implementieren. Dieses Interface schreibt die onModulLoad()Methode vor.
18
2. Grundlagen
19 public class MainEntryPoint implements EntryPoint {
20
/**
21
* Creates a new instance of MainEntryPoint
22
*/
23
public MainEntryPoint() {
24
}
25
26
/**
27
* The entry point method, called automatically by loading a module
28
* that declares an implementing class as an entry-point
29
*/
30
public void onModuleLoad() {
31
final Label label = new Label("Hello, GWT!!!");
32
final Button button = new Button("Click me!");
33
34
button.addClickHandler(new ClickHandler() {
35
public void onClick(ClickEvent event) {
36
label.setVisible(!label.isVisible());
37
}
38
});
39
40
RootPanel.get().add(button);
41
RootPanel.get().add(label);
42
}
43 }
Listing 2.2: MainEntryPoint.java
In Zeile 31 und 32 wird ein Label und ein Button erzeugt und in Zeile 40 und 41 werden sie dem
Hauptpanel hinzugefügt.
In der Datei Main.gwt.xml befindet sich die Konfiguration für diese Anwendung. Es enthält zwei
Elemente. Das Element inherits bezeichnet die Module von denen dieses Modul erbt. In diesem einfachen Fall ist dies nur das Modul com.google.gwt.user.User aus dem GWT-Rahmenwerk. Das
entry-point-Element referenziert die Hauptklasse.
1 <?xml version="1.0" encoding="UTF-8"?>
2
3 <!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 1.7.0//EN"
"http://google-web-toolkit.googlecode.com/svn/tags/1.7.0/distrosource/core/src/gwt-module.dtd">
4
5 <module>
6
<inherits name="com.google.gwt.user.User"/>
┋
15
<entry-point class="org.yournamehere.client.MainEntryPoint"/>
┋
18 </module>
Listing 2.3: Main.gwt.xml
Der Inhalt der Datei welcomeGWT.html wurde bereits auf Seite 14 beleuchtet.
19
2. Grundlagen
Client-Server-Kommunikationen mittels GWT-RPC
Das NetBeans-GWT-Plugin stellt einen Wizard für die Erzeugung eines RPC-Services bereit. Die
notwendigen Klassen werden automatisch vom Wizard erzeugt.
Abbildung 2.13: Klassen für den RPC-Service
Die Klasse GWTService in Listing 2.4 enthält die clientseitige Definition des Service. Dieses Interface erweitert das RemoteService-Interface.
8
9
┋
16
17
18
import com.google.gwt.user.client.rpc.RemoteService;
import com.google.gwt.user.client.rpc.RemoteServiceRelativePath;
public interface GWTService extends RemoteService {
public String myMethod(String s);
}
Listing 2.4: GWTService.java
Der Beispielservice bekommt einen String übergeben und liefert einen String zurück.
20
2. Grundlagen
8 import com.google.gwt.user.server.rpc.RemoteServiceServlet;
10 import org.yournamehere.client.sampleservice.GWTService;
┋
16 public class GWTServiceImpl extends RemoteServiceServlet implements
GWTService {
17
public String myMethod(String s) {
18
// Do something interesting with 's' here on the server.
19
return "Server says: " + s;
20
}
21 }
Listing 2.5: GWTServiceImpl.java
Die GWTServiceImpl-Klasse implementiert serverseitig die Funktionalität des Service. Dazu implementiert die Klasse das Interface GWTService. Im Beispiel wird der empfangene String mit einem
vorangestellten „Server says:“ wieder zurückgegeben.
8 import com.google.gwt.user.client.rpc.AsyncCallback;
┋
14 public interface GWTServiceAsync {
15
public void myMethod(String s, AsyncCallback<String> callback);
16 }
Listing 2.6: GWTServiceAsync
GWTServiceAsync ist das asynchrone Interface, basierend auf das GWTService-Interface. Es liefert
das callback-Objekt, das die asynchrone Kommunikation zwischen Server und Client ermöglicht.
21
2. Grundlagen
7
8
9
10
11
12
13
14
15
┋
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
import
import
import
import
import
import
com.google.gwt.core.client.GWT;
com.google.gwt.user.client.rpc.AsyncCallback;
com.google.gwt.user.client.ui.Label;
com.google.gwt.user.client.ui.Button;
com.google.gwt.user.client.ui.TextBox;
com.google.gwt.user.client.ui.VerticalPanel;
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
public class GWTServiceUsageExample extends VerticalPanel {
// Create the client proxy. Note that although you are creating the
// service interface proper, you cast the result to the asynchronous
// version of the interface. The cast is always safe because the
// generated proxy implements the asynchronous interface automatically.
private GWTServiceAsync gwtService = GWT.create(GWTService.class);
private Label lblServerReply = new Label();
private TextBox txtUserInput = new TextBox();
private Button btnSend = new Button("Send to server");
public GWTServiceUsageExample() {
add(new Label("Input your text: "));
add(txtUserInput);
add(btnSend);
add(lblServerReply);
// Create an asynchronous callback to handle the result.
final AsyncCallback<String> callback = new AsyncCallback<String>() {
public void onSuccess(String result) {
lblServerReply.setText(result);
}
public void onFailure(Throwable caught) {
lblServerReply.setText("Communication failed");
}
};
// Listen for the button clicks
btnSend.addClickHandler(new ClickHandler() {
public void onClick(ClickEvent event) {
// Make remote call. Control flow will continue immediately
// and later callback will be invoked when the RPC completes.
gwtService.myMethod(txtUserInput.getText(), callback);
}
}
});
}
Listing 2.7: GWTServiceUsageExample.java
Im Listing 2.7 wird ein Testclient erzeugt. Eine Instanz dieser Klasse erzeugt ein Panel mit einem
Eingabefeld,einem Button und einem Label. Die Eingabe wird nach Betätigung des Knopfes an den
Server geschickt. Das Label zeigt die Antwort des Servers an.
22
2. Grundlagen
In Zeile 27 wird die Service-Proxy-Klasse erzeugt. Eine Instanz dieser Klasse wird durch Aufruf
von GWT.create(Class) angelegt.
Zeile 40 bis 49 dienen zum Aufsetzen des Callback-Objektes. Die Methode onSuccess() in Zeile
42 wird im Erfolgsfall ausgeführt. Tritt ein Fehler bei der Behandlung des RPC auf, wird die Methode onFailure() in Zeile 46 ausgeführt.
Der Aufruf des Remote Procedure Calls erfolgt in Zeile 57.
Nach Ersetzen von Zeile 41 und 42 durch
RootPanel.get().add(new GWTServiceUsageExample());
in der Datei MainEntryPoint.java ist dieses Beispiel komplett.
Abbildung 2.14 zeigt die Browser-Ansicht dieses Beispiels.
Abbildung 2.14: GWT-Beispiel nach Ausführung eines RPC
2.3 Das User-Interface-Framework ExtGWT
Das Google Web Toolkit ist ein guter Weg für Ajax 6-Anwendung. Aufbauend auf den Stärken von
GWT ermöglicht ExtGWT ein Benutzungsgefühl, das dem einer Desktop-Anwendung gleicht.
Out of the Box stellt GWT nur ein kleines Sortiment an Basis-Widgets zur Verfügung. Zusätzlich
mangelt es an einem Rahmenwerk, dass es dem Entwickler ermöglicht strukturiert große Anwendungen zu programmieren.
Da GWT offen und erweiterbar ist, setzt ExtGWT der Firma Sencha Inc. hier an. Dieses Internet
Application Framework für Google Web Toolkit liefert eine umfassende Komponentenbibliothek,
vergleichbar mit dem, was man für Desktop-Umgebungen nutzt. Das Ergebnis ist eine Programmansicht, die näher an einer Desktop-Anwendung ist als an einer Webseite. Zusätzlich stehen effektive Funktionen zum Arbeiten von lokalen und fernen Daten bereit. Ein Model-View-Controller-Framework ermöglicht die übersichtliche Entwicklung großer Anwendungen.
ExtGWT ist eine reine Java-Bibliothek. Es nutzt nur GWT-Methoden und kommt ohne externes JavaScript oder Bibliotheken aus anderen Quellen aus. Kernfunktionen des GWT, wie beispielsweise
Remote Procedure Calls, werden voll unterstützt.
Für den Nutzer stehen zwei Lizenzmodelle zur Verfügung. Es gibt eine open source Lizenz. Für
den, der sich mit den Einschränkungen dieser Lizenz nicht anfreunden kann, gibt es aber auch ein
kommerzielles Lizenzmodell.
Als Quelle für genauere Informationen bietet sich das ExtGWT Help Center [12] an. Als Beispiel
dient nur die ExtGWT Explorer Demo7.
6 Ajax – Asynchronous JavaScript and XML
7 Die ExtGWT Explorer Demo ist zu finden unter: http://www.sencha.com/examples/explorer.html#overview .
23
2. Grundlagen
Abbildung 2.15: Widget-Beispiele im Ext GWT Explorer Demo
Die Beispiele für die einzelnen Widgets sind leider durch ihre Komplexität nicht so leicht zu durchschauen. Ebenfalls negativ ist, dass als Datenquelle für die Beispiele externe Datengeber-Klassen
verwendet werden, die nicht dokumentiert sind. Um einen Eindruck über die Möglichkeiten von
ExtGWT zu bekommen, ist das ExtGWT Explorer Demo aber gut geeignet.
2.3.1 Widgets des ExtGWT
Das Framework bietet eine große Sammlung an guten und anpassbaren User Interface Widgets. Da
es für fast alle möglichen Desktop-Elemente einen Nachbau gibt, ist es leicht möglich ein einheitliche Benutzerführung und Design zu erzeugen.
Eine Übersicht über die angebotenen Widgets bietet die ExtGWT Explorer Demo.
ExtGWT-Widgets und GWT-Widgets unterscheiden sich in der Handhabung. Die Komponenten
werden immer erst bei Bedarf berechnet, im Gegensatz zu GWT, wo die Komponenten sofort nach
ihrer Instanziierung erzeugt werden. Dies wird als Lazy Rendering bezeichnet und hat den Vorteil,
dass die Komponenten bereits vor der Anzeige konfiguriert werden können.
24
2. Grundlagen
LayoutContainer als Container für Widget-Komponenten
LayoutContainer bezeichnen einen Container, der Widgets aufnehmen kann und nach einem bestimmten Layout anordnet. Nach dem ein Layout innerhalb eines LayoutContainers zusammengestellt wurde, gibt es drei Möglichkeiten diesen zur Anzeige zu bringen.
Die einfachste Variante ist, das Hinzufügen des Containers zur Seite:
RootPanel.get().add(container); .
RootPanel.get()
liefert als Wurzelpanel das <body>-Element des HTML-Dokuments.
Wenn der Container bereits gerendert wurde und der Inhalt hat sich geändert, so muss das Layout
neu berechnet werden. Dies kann manuell durch Aufruf der Methode container.layout() erfolgen. Erst danach wird die Änderung im Dokument sichtbar.
Um komplexe User Interface-Designs zu erstellen, können Container geschachtelt werden. Die letzte Möglichkeit ein Rendering der Komponenten auszulösen, ist das Berechnen des Layouts eines
Wurzelcontainers. Beim Rendern des Layouts eines Containers, wird das Layout aller Kinder des
Container überprüft. Ist dies nun ebenfalls ein Container, so wird auch für diesen das Layout neu
errechnet.
2.4 OX-Framework8 als Bindeglied zwischen Sensor Observation
Service und Java-Servlet
Voraussetzung für die Entwicklung von Client-Anwendungen für OGC-Web-Services ist die Implementierung einer Schnittstelle, die eine Interaktion mit dem Service-Interface ermöglicht. Mit der
Standardisierung der Interaktion für OGC-Web-Services im Jahre 2006 begann auch die Entwicklung des OX-Frameworks unter dem Dach der 52°North open source initiative. Hierbei handelt es
sich um ein Software-Rahmenwerk, dessen Architektur die leichte, gekapselte Nutzung von OGCWeb-Services ermöglicht. Es bildet die technologische Basis für Sensor-Web-Anwendungen.
Das OX-Framework stellt, im Gegensatz zu vielen anderen Frameworks, eine integrierte Lösung für
Client und Server bereit. Es soll eine eingliedernde Sicht auf alle Arten von OGC-Web-Services liefern, um daraus Daten zu verarbeiten und zu visualisieren. Die Vielfalt der verschiedenen Dienste
und Datenformate verlangt nach einer flexiblen Architektur. Beim OX-Framework wurden drei Designkonzepte umgesetzt: Dreistufenarchitektur, Plugin-Mechanismen und Listener-Konzept.
Die Stufenarchitektur, wie in Abbildung 2.16 zu sehen, reduziert die Komplexität des Rahmenwerks
durch Strukturierung in drei Ebenen: Adapter-Subsystem, Core-Subsystem und Utilities-Subsystem.
8 OX-Framework – OGC Web Service Access Framework
25
2. Grundlagen
Abbildung 2.16: Drei-Stufen-Architektur des OX-Frameworks
Das Adapter-Subsystem enthält die Realisierungen aller Service-Adapter für spezifische OGC-WebServices, beispielsweise SOS. Diese Service-Adapter kommunizieren untereinander über das CoreSubsystem, mittels einem gemeinsamen Datenmodells. Das Utilities-Subsystem enthält Funktionen
für UI-Frameworks (zum Beispiel Swing).
Der Plugin-Mechanismus ermöglicht das dynamische Anpassen und Erweitern des Frameworks mit
notwendigen Service-Adaptern.
Durch das Listener-Konzept bietet das OX-Framework ein hohes Maß an Erweiterbarkeit und
Transparenz. Der Entwickler hat so die komplette Kontrolle über das Rahmenwerk. [13]
Das Listing 2.8 zeigt den Zugriff auf einen SOS-Server durch Nutzung des OX-Frameworks.
26
2. Grundlagen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
package soshello;
import
import
import
import
import
import
import
import
import
import
import
java.io.FileOutputStream;
java.io.IOException;
java.util.logging.Level;
java.util.logging.Logger;
org.n52.oxf.OXFException;
org.n52.oxf.owsCommon.ExceptionReport;
org.n52.oxf.owsCommon.capabilities.Operation;
org.n52.oxf.serviceAdapters.OperationResult;
org.n52.oxf.serviceAdapters.ParameterContainer;
org.n52.oxf.serviceAdapters.sos.ISOSRequestBuilder;
org.n52.oxf.serviceAdapters.sos.SOSAdapter;
public class SOSHello {
private final static String url="http://localhost:8080/52nSOSv3_WAR/sos";
private final static SOSAdapter sosAdapter = new SOSAdapter();
public static void main(String[] args)
throws ExceptionReport, OXFException {
ParameterContainer pc = new ParameterContainer();
pc.addParameterShell(
ISOSRequestBuilder.GET_CAPABILITIES_SERVICE_PARAMETER, "SOS");
Operation op = new Operation("GetCapabilities",url+"?",url);
OperationResult opResult = sosAdapter.doOperation(op, pc);
saveResultInFile(opResult);
}
}
private static void saveResultInFile(OperationResult opResult) {
try {
FileOutputStream out = new FileOutputStream("output.xml");
out.write(opResult.getIncomingResult());
out.flush();
out.close();
} catch (IOException ex) {
Logger.getLogger(
SOSHello.class.getName()).log(Level.SEVERE, null, ex);
}
}
Listing 2.8: SOSHello.java
In der Zeile 17 wird der Adapter für den SOS-Service instanziiert. Über dieses Objekt erfolgt die
Kommunikation mit dem Service.
Eine Operation wird in Zeile 25 zusammen gestellt. Als Parameter muss die Bezeichnung der Operation und die Adressen für HTTP-GET und HTTP-POST übergeben werden. Die URL, die für das
Zusammensetzen dieser Adresse notwendig ist, wird in Zeile 16 in der Konstante url gespeichert.
Die Ausführung der Operation erfolgt in Zeile 26. Als Parameter muss die vorher erzeugte Operation übergeben werden und ein ParameterContainer, der aller Parameter der Operation enthält. Der
einzig notwendige Parameter für die getCapabilities-Operation ist der Service-Parameter. Dieser
wird in Zeile 22 und 23 dem ParameterContainer übergeben. Das Ergebnis der Operation wird in
Zeile 27 in einer Datei gespeichert.
27
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage
und Visualisierung für ein ortsbasiertes Servicesystem
Die Anforderung des Laborpersonals an die Auswerte- und Visualisierungsmöglichkeiten des ortsbasierten Servicesystems wurden während einer Befragung ermittelt. Dazu wurden die typischen
Arbeitsschritte im Laborumfeld analysiert. Dabei wurden zwei Anwendungsfälle, die von dem grafischen Benutzerinterface unterstützt werden, ermittelt.
Im ersten Fall soll aus den Messungen eine Erkenntnis über das eigentliche Messobjekt ermittelt
werden. Das heißt, die Probe beeinflusst während der Messreihe direkt ein vom Sensor erfasstes
Phänomen.
Der Messablauf in Abbildung 3.1 bildet die Grundlage für das Anfordungsprofil.
Abbildung 3.1: Ablauf eines Versuches
Daraus ergeben sich folgende zu implementierende Funktionen:
1. Aufruf eines Zeitverlaufes als Normverlauf
2. Definition der erlaubten Schwankungsbreite
3. Anzeige des Normverlaufes mit anderem Zeitverlauf zusammen
Tabelle 3.1: Funktionen zur Messwertanalyse 1
Der zweite Fall stellt das Gegenteil da. Hier steht die Frage im Raum, wie ein vom Sensor erfasster
Umgebungsparameter die Probe beeinflusst. Wenn beispielsweise nach einem Versuch bei einer
Probe ein unerwartetes Ergebnis sichtbar wird, kann überprüft werden ob Veränderungen der Probenumgebung mit dem Ergebnis korrelieren. Dazu sind die Funktionen der Tabelle 3.2 notwendig.
28
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
1. Aufruf mehrerer Zeitverläufe
2. gemeinsame Anzeige der Zeitverläufe
Tabelle 3.2: Funktionen zur Messwertanalyse 2
Für den Fall, dass die Auswertemöglichkeiten nicht genügen, soll eine Exportmöglichkeit integriert
werden. Da es sich um Tabellen handelt, bietet sich hier das CSV-Format an.
Abbildung 3.2: Frontend der SOSGui
Die Abbildung 3.2 zeigt die Oberfläche, wie sie sich dem Laborpersonal darstellt.
3.1 Das Einsatzumfeld – Hard- und Software für das ortsbasierte
Servicesystem
In dem hier beschriebenen Szenario sind in einem Raum beliebig Sensorknoten verteilt worden. Die
Anzahl der Knoten sowie deren Position kann vom Anwender selbst festgelegt werden und kann so
den jeweiligen Anforderungen angepasst werden. In [1] werden drei unterschiedliche Szenarien ausführlich beschrieben um die universelle Anwendbarkeit dieser Technik zu verdeutlichen.
Diese Sensorknoten übermitteln über eine Funkschnittstelle die Messwerte an eine Basisstation.
Diese trägt die Daten in eine Datenbank ein. Die Benutzerschnittstelle fragt bei der Datenbank diese
Daten ab um sie dem Nutzer zur Verfügung zu stellen.
29
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
Abbildung 3.3: Struktur eines Sensornetzes
Da dieses Interface für ein vorhandenes Anwendungssystem entwickelt wurde, sollen hier einführend die zugrunde liegenden Techniken und Konzepte beschrieben werden.
3.1.1 Sensorknoten und Fox-Board als Datenquelle für den Sensor
Observation Service
Anforderungen und Aufbau eines Sensorknotens
Der Sensorknoten soll physikalische Phänomene erfassen und Veränderungen schnell zur Weiterverarbeitung zur Verfügung stellen. Da diese Knoten autark agieren, muss die eingesetzte Technik
sehr energieeffizient sein.
Ein typischer Sensorkonten besteht aus vier Komponenten. Ein oder mehrere Messfühler wandeln
physikalische Größen in äquivalente elektrische Signale um. Diese analogen Signale werden von einem Mikrocontroller abgetastet und diskretisiert. Im Mikrocontroller kann auch eine Verarbeitung
der Messwerte erfolgen um beispielsweise Störung aus dem Signal zu filtern. Die Messwerte werden über eine Funkschnittstelle zur Basisstation übertragen. Für die Komponenten ist eine unabhängige Stromversorgung notwendig.[14]
Abbildung 3.4: Zusammenwirken der Komponenten eines Sensorknotens
Das entscheidende Kriterium für die Auswahl der Elemente ist, dass ein möglichst langer autonomer Betrieb möglich ist.
30
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
Im eZ430-RF2480 Demo Kit von Texas Instruments[15] sind diese Komponenten in einem Paket
vereint. Das Demo Kit enthält die im Folgenden aufgelistete Hardware.
Anzahl
Bezeichnung
3
CC2480 Target Board
1
eZ430 USB Emulator Board
2
AAA eZ430 Battery Board
Tabelle 3.3: Hardware des eZ430-RF2480 Demo Kit
Als Sensorknoten wird das CC2480 Target Board mit dem AAA eZ430 Battery Board kombiniert.
Abbildung 3.5: Sensorknoten aus Battery Board
und Target Board
Quelle: [15]
Auf dem Knoten ist der MSP430F2274 Mikrocontroller mit dem CC2480 Netzwerkprozessor über
einen SPI-Bus verbunden. Das Boarddesign ist so gestaltet, dass ein möglichst kleine Fläche bei
Nutzung einer Chip-Antenne benötigt wird. Das Target Board stellt eine rot und eine grüne LED zur
Verfügung sowie einen Taster. Über den Mikrocontroller stehen fünf GPIO-Anschlüsse zur Verfügung. Hierüber können beispielsweise weitere Sensoren angeschlossen werden.
MSP430F2274 Mikrocontroller zur Messwertaufbereitung auf dem Sensorknoten
Die MSP430-Mikrocontroller-Familie des Herstellers Texas Instruments ist auf besonders geringen
Energieverbrauch ausgelegt. Die Architektur mit fünf Energiesparmodi ist optimal angepasst für
den mobilen, batteriebetriebenen Einsatz. Die von Neumann-Architektur des Mikrocontrollers hat
eine Busbreite von 16 bit. Der RISC-Befehlssatz des Controllers umfasst 51 Befehle. In der folgenden Tabelle ist die intern zur Verfügung stehende Peripherie aufgelistet.
31
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
Takterzeugung
Intern – Frequenzen bis 26 MHz
Intern – Low-Power Low-Frequency Oscillator
32 kHz Crystal
High-Frequency Crystal
32x Digital Input/Output
2x 16-Bit Timer
Universal Serial Communication Interface UART
IrDA
SPI
I²C™
10-Bit 200-ksps Analog to Digital Converter
Operationsverstärker
Brownout Detector
Speicher
32KB + 256B Flash
1KB RAM
Tabelle 3.4: Interne Peripherie des MSP430F2274
Über den Analog-Digital-Konverter ist auf dem CC2480 Target Board ein Lichtsensor mit dem Mikrocontroller verbunden.[16]
Datenübertagung mit Hilfe des CC2480 Z-Accel 2.4 Ghz ZigBee® Processor
Speziell für niederbitratige Personal Area Networks wurde die kabellose ZigBee-Technologie standardisiert. Diese Funktechnologie arbeitet im lizenzfreien 2.4 GHz Band. Sie wurde mit besonderem Augenmerk auf kosteneffiziente, energiesparende Anwendung entwickelt.
Ein ZigBee-Netzwerk ist ein selbst konfigurierendes, multi-hop-fähiges drahtloses Netzwerk. Dadurch ist es möglich, dass ein Endknoten, der nicht direkt mit der Basisstation kommunizieren kann,
über andere Knoten die Daten übermittelt.
Für ein ZigBee-Netzwerk sind drei Gerätetypen definiert. Vom Koordinator-Knoten darf nur ein
Gerät im Netzwerk vorhanden sein. Als erstes Device startet es das Netzwerk in dem es Kanal und
Netzwerk-ID bestimmt. Der Router stellt Netzwerkfunktionen zur Weiterleitung von Daten zur Verfügung. Er erlaubt anderen Knoten dem Netzwerk beizutreten. Nur Endknoten haben keine weiteren Netzwerkfunktionen und können deshalb alle Möglichkeiten zum Energiesparen nutzen um eine
lange Batterielaufzeit zu erzielen.
Der CC2480-Netzwerkporzessor unterstützt alle Gerätetypen. Er behandelt alle zeitkritischen und
rechenaufwendigen Aufgaben des ZigBee-Protokolls und lässt so Kapazitäten des Mikrocontrollers
frei für andere Anwendungen. Mikrocontroller und Netzwerkprozessor kommunizieren über den
SPI-Bus9 miteinander. Der CC2480 stellt einen Batterie-Monitor und einen Temperatursensor zur
9SPI-Bus - Serial Peripheral Interface: synchroner serieller Datenbus hauptsächlich eingesetzt zur Kommunikation
einzelner Komponenten einer Leiterplatte
32
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
Verfügung. Daneben gibt es noch weiter Peripherie, die aber auf dem Target-Board nicht genutzt
werden kann.
Das FOX-Board als Basisstation
Als Gegenstelle für die Sensorknoten dient ein FOX-Board der Firma ACME Systems [17]. Hierbei
handelt es sich um ein eingebettetes System mit kompakten Abmessungen, dass auf geringen Energieverbrauch ausgelegt ist. Ein oben beschriebenes CC2480 Target-Board kombiniert mit dem
eZ430-USB-Emulator-Board wird als ZigBee-Netzwerk-Koordinator betrieben und stellt eine
Kommunikationsmöglichkeit mit der Basisstation zur Verfügung.
Das Linux-System des FOX-Boards läuft auf einem 32 Bit RISC-Prozessor mit 100 MHz. Neben
mehreren USB 1.1 -Ports steht eine Ethernetanschluss und weiter Schnittstellen zur Verfügung.
Auf dieser Basisstation läuft eine Gateway-Anwendung, die die Daten der Sensorknoten in die Datenbank einträgt. Im Detail beschrieben wird diese Gateway-Anwendung in [14]. Als standardisierte
Schnittstelle wird der Sensor Observation Service benutzt.
3.1.2 SOS-Implementierung von 52° North
Für den in Kapitel 2.1.1 beschriebenen Sensor Observation Service sind nur die Schnittstelle definiert, nicht aber der Service selber. Es gibt aber mehrere frei verfügbare Umsetzungen für diesen
Web-Service. Diese Implementierung sind für verschiedene Programmiersprachen, etwa für Java,
C++ oder Python verfügbar.
Die Java-Realisierung von 52° North bietet sich hier an, da man aus gleicher Hand das OX-Framework als Schnittstelle für eigene Anwendungen, bekommt. Für den SOS-Server von 52° North ist
der Webserver Tomcat notwendig. Für die hier beschriebene Internet-Applikation benötigt man
ebenfalls einen Webserver zur Ausführung des Servlets. Auf dem Tomcat-Servlet-Container können
also beide Anwendungen ausgeführt werden.
Die Implementation unterstützt die Operationen des Core-Profils und darüber hinaus noch einige
Operationen des Enhanced Profile. GetResult ermöglicht es, bei konstanten Metadaten, nur Messdaten ohne Metadaten abzufragen. Die Operation GetFeatureOfIntererst liefert die Objekte, dessen
Eigenschaften vom Sensor überwacht werden. GetObservationById benötigt als Parameter die Id
für eine Beobachtung um die Observation zurückzugeben.
Das Transactional Profile wird nicht unterstützt so, dass das Eintragen neuer Sensoren oder Messwerte nicht über die definierten Schnittstellen des SOS erfolgen kann. Dazu muss direkt auf die Datenbank zugegriffen werden.
Die Installation des Servers sowie die Dokumentation der Datenbank findet man in [18].
3.1.3 UroSweClient als Container für die grafische Oberfläche
Die im Rahmen der Vorentwicklung entstandenen Funktionalitäten soll durch diese Arbeit erweitert
werden. Dazu soll die Portlet-Architektur des UroSweClients erweitert werden.
Im Menü SOS connections findet man Menüpunkte zum Anlegen und Löschen von Verbindungen
sowie zum Laden einer Verbindung. Die geladene Verbindung wird im SweConfigurationPanel unter der Menüleiste angezeigt.
33
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
Abbildung 3.6: UroSweClient als Container für die GUI
Wie in Abbildung 3.6 zu sehen ist, befindet sich links eine Übersicht, mit welchen Servern die Anwendung verbunden ist. Unter der Server-Adresse findet man einige Buttons, mit denen man Funktionalitäten der Oberfläche aufrufen kann. Die Funktion wird dann als Tab links neben der Verbindungsübersicht geöffnet.
3.1.4 UroSweClient-Portlet-Schnittstelle für die GUI
Im Rahmen der Portlet-Architektur soll sich das grafische Benutzerinterface zur Messdatenauswertung in den UroSweClient integrieren. Dazu muss in der vorhandenen Oberfläche ein Button angelegt werden, der einen neuen Tab mit der Gui öffnet.
34
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
Abbildung 3.7: Ablauf beim
Zugriff auf eine Funktion
der Oberfläche
Das dargestellte Vorgehen in Abbildung 3.7 beginnt mit dem Laden der Verbindung. Dadurch werden die SOSConnectionInfo angelegt.
Um einen neuen Button anzulegen, müssen zwei Dateien bearbeitet werden. In der Datei SweGuiConstants.java muss ein neuer Button Identifier eingetragen werden. Diese Konstante bezeichnet
später den Funktionstyp, welche aufgerufen werden soll.
17 package org.uro.urosweclient.client.Control;
┋
26 public class SweGuiConstants {
┋
43
/////////////////////////////////////////////////////////////////////////
44
//BUTTON IDENTIFIER /////////////////////////////////////////////////////
45
public static final String SETTINGS = "Settings";
46
public static final String DB_MENUE = "SOS connections";
47
public static final String ADD_DB = "Add SOS connection";
48
public static final String RM_DB = "Remove SOS connection";
49
public static final String LOAD_DB = "Load SOS connection";
50
public static final String CANCEL = "Cancel";
51
public static final String META = "SOS connection MetaData";
52
public static final String SERVICE_META = "Show Service MetaData";
53
public static final String SENSOR_META = "Show Sensor MetaData";
54
public static final String TIMESERIES = "Timeseries Control";
55
public static final String TIMESERIES_ADD = "Add new Timeseries";
56
public static final String TIMESERIES_RM = "Remove Timeseries";
57
public static final String DESASTER = "Desaster Management";
┋
85 }
Listing 3.1: ::org.uro.urosweclient.client.Control::SweGuiConstants
Für den Button muss eine Methode zum Anlegen in der Datei SweConfigurationPanel.java erzeugt
werden.
35
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
17 package org.uro.urosweclient.client.view.gui.elements;
┋
58 public class SweConfigurationPanel extends ContentPanel implements
SweViewable {
┋
232
private class SOSUrlPanel extends ContentPanel implements SweViewable {
┋
285
286
/**
287
* This function adds all buttons to the SOSUrlPanel.<p>
288
* - MetaData<p>
289
* - TimeSeries<p>
290
* - DesasterManagement<p>
291
*/
292
private void addButtons() {
293
294
this.addMetaDataButton();
295
this.addTimeSeriesButton();
296
this.addDesasterButton();
297
}
┋
304
private void addMetaDataButton() {
305
//Generate Button
306
Button metadata = new Button();
┋
317
//Add actions
318
metaService.addSelectionListener(new
SelectionListener<MenuEvent>() {
319
//Generate Tab with MetaDataView
320
321
public void componentSelected(MenuEvent me) {
┋
info.getView().getControl().getEventmanager().
┋
fireGenerateMetaDataTabView(getId(), SweGuiConstants.SENSOR_META);
323
}
334
});
┋
340
this.add(metadata, new VBoxLayoutData(new Margins(0, 0, 5, 0)));
341
}
┋
529
}
530 }
Listing 3.2: Innere Klasse SOSUrlPanel der Klasse
::org.uro.urosweclient.client.view.gui.elemets::SweConfigurationPanel
In Zeile 321ff des Listing 3.2 wird auf Tastendruck beispielhaft die Funktion, die mit dem Button
Identifier SENSOR-META verbunden ist, aufgerufen. Durch die Methode addButtons() wird die
Methode addMetaDataButton() aufgerufen und der Button im SweConfigurationPanel angelegt.
Um nun dem Button eine Funktion zuzuordnen, muss die Datei SweServiceMetaDataTab.java
angepasst werden. Im Listing der Datei sieht man die Methode createContent(). Diese muss um
einen if else-Zweig für den neuen Button Identifier erweitert werden.
36
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
17 package org.uro.urosweclient.client.view.gui.elements;
┋
56 public class SweServiceMetaDataTab extends SweTab {
┋
82
private void createContent(SOSConnectionInfo sosinfo, String type) {
┋
91
String tag = "";
92
93
if (type.equals(SweGuiConstants.SERVICE_META)) {
94
95
tag = "SERVICE METADATA";
96
97
} else if (type.equals(SweGuiConstants.SENSOR_META)) {
98
99
tag = "SENSOR METADATA";
100
}
┋
107
//Generate the ContentPanel
108
ContentPanel cp = new ContentPanel();
109
cp.setBodyBorder(false);
110
cp.setHeaderVisible(false);
111
cp.setButtonAlign(HorizontalAlignment.CENTER);
112
cp.setLayout(new FitLayout());
113
cp.setFrame(false);
114
cp.setHeight(this.getView().getTabPanel().getHeight() - 20);
115
cp.setWidth(this.getView().getTabPanel().getWidth());
┋
138
//Add data elements to parents
139
cp.add(tree);
140
this.add(cp);
141
}
┋
240 }
Listing 3.3: ::org.uro.urosweclient.client.view.gui.elements::SweServiceMetaDataTab
Das ContentPanel, das in Zeile 108 angelegt wird, nimmt entsprechend der Variable tag die
geforderte Funktion auf.
3.2 SOSGui – Struktur der Quellen
Bei der Entwicklung der Anwendung wurde ein eigenständiges Software-Design umgesetzt. Um sie
balastfrei und kompakt zu programmieren, wurde sie als unabhängiger Webservice implementiert.
Erst nach Abschluss der Entwicklung wird sie über oben beschriebene Schnittstelle in den UroSweClient integriert.
Das Google Web Toolkit gibt als grundsätzliche Struktur zwei Pakete vor. Abbildung 3.8 stellt dies
da.
Abbildung 3.8: SOSGui Paketstruktur
37
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
Das Clientpaket enthält das Frontend und das Serverpaket das Java-Servlet. Beide Bestandteile der
Rich Internet Applikation kommunizieren über den GWT-RPC-Service mit einander. Client- und
Server sind wiederum in Pakete unterteilt.
3.2.1 Serverpaket der SOSGui
Schichten sollen Funktionalitäten kapseln, so dass die Implementierung einer Schicht leicht zu ersetzen ist. Dieses System besteht aus drei Schichten, wie Abbildung zeigt.
Abbildung 3.9: SOSGui
Schichten des Serverpaketes
Die Serviceverbindungsschicht bietet Funktionen, die Daten für die Übertragung aufbereitet. Im
Clientpaket muss eine passende Gegenstück zu dieser Schicht vorhanden sein. Bei der SOSGui-Applikation wird hier der GWT-RPC-Mechanismus implementiert.
In der Datenrepräsentationsschicht werden fachliche Objekt realisiert. Diese Objekte stellen strukturiert Daten für Programmlogik bereit. Wie diese Daten dauerhaft gespeichert werden, ist der Schicht
aber nicht bekannt.
Dazu ist die Datenspeicherschicht zuständig. Zugriffe auf den SOS-Server zum Lesen werden hier
implementiert.
3.2.2 Clientpaket der SOSGui
Das Clientpaket ist ebenfalls in drei Schichten unterteilt. Außerhalb dieser Schichten ist der MainEntryPoint angeordnet, da er einen variablen Einsprungpunkt in die Anwendung darstellt (siehe
dazu Abbildung 3.10). Während der Entwicklung stellt es den Einsprungpunkt in die GWT-Anwendung dar. Wenn die Gui später in die Portlet-Architektur des Gesamtsystems integriert werden soll ,
stellt diese Funktion einen Container mit der Gui bereit. Dieser Container wird dann in die Hauptanwendung eingebettet.
38
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
Abbildung 3.10: SOSGui Schichten des
Clientpaketes
Das Gegenstück zur Serviceverbindungsschicht des Serverpaketes stellt die Serviceverbindungsschicht des Clientpaketes dar.
Obwohl die Datenrepräsentationsschicht von Clientpaket und Serverpaket gleich heißen, enthalten
sie doch unterschiedliche Objekte. Im Clientpaket sind hier die Datenobjekte gespeichert, die für
Präsentation notwendig sind.
Die Präsentationsschicht enthält die grafischen Elemente, die zur Darstellung der Daten benötigt
werden.
Die Zugehörigkeit der einzelnen Klassen zu einer Schicht und deren Interaktion geht aus den Abbildungen und im Anhang hervor.
3.3 SOSGui – Klassenentwurf
3.3.1 Serverpaket
Broker<T>
Die generische Klasse Broker<T> enthält die Methode makeObject, die in konkreten Subklassen
implementiert werden müssen. Die Methode query benötigt die SOS-Operation, die Adresse das
SOS-Servers und die Parameter für die SOS-Operation als Aufrufparameter
CapabilityBroker
Diese Klasse enthält die Implementierung der makeObject-Methode. Sie hat das Wissen über den
genauen Aufbau der getCapabilities-Operation des SOS. Ein CapabilityBroker-Objekt kann nur
über getInstance erzeugt werden. Die Methode getCapability liefert das Capability-Object zurück
und benötigt als Parameter nur SOSConnection. Wenn nun eine getCapabilities-Operation mit mehr
Parametern gewünscht ist, kann man hier eine weitere getCapability-Methode als überladenen Methode implementieren.
ObservationBroker und ObservationContentHandler
Von der Art der Implementierung unterscheidet sich die Klasse ObservationBroker nur wenig von
der Klasse CapabilityBroker. Allerdings benutzt die Methode getObservation zum Zerlegen der Ant39
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
wort des SOS-Servers nicht die Funktionen des OX-Frameworks. Über die Klasse ObservationContentHandler wird der SAX-Parser benutzt um dem O&M-Dokument die Daten zu entnehmen.
Observation, Offering und Capability
Diese Klassen bilden die Ergebnis-Objekte der Broker-Klassen. Sie enthalten nur get und set Methoden für die Attribute.
SOSConnection
SOSConnection enthält die Verbindungsparameter für den SOS-Server. Über den Konstruktor wird
das Attribut url mit der Adresse des SOS-Servers gesetzt.
GWTServiceImpl
Die get-Methoden sind die Implementierung des GWT-RPC. Die Methode iso8601ToDate wandelt
das Datumsformat des Sensor Observation Service in ein Date-Objekt. convertStringToDouble wird
bisher nicht benutzt.
3.3.2 Clientpaket
GWTService und GWTServiceAsync
Die Methoden dieser Klasse sind die Gegenstelle des GWT-RPC-Service. GetObservation liefert
ein ObservationModel, welches eine Tabelle für die Anzeige enthält. Als Parameter müssen alle notwendigen Parameter der GetObservation-Operation des SOS sowie die URL angegeben werden.
GetCapability benötigt nur die URL um ein CapabilityTreeModel zurückzugeben.
ObservationModel und ObservationChartModel
Diese Klassen sind Daten-Objekte für die Darstellung innerhalb der Gui. Sie enthalten nur get- und
set-Methoden für deren Attribute.
CapabilityTreeModel
CapabilityTreeModel erweitert das BaseTreeModel. Innerhalb des Konstruktors werden die set-Methoden des BaseTreeModels aufgerufen. Mit diesem Objekt lässt sich ein Baum aufbauen, mit dem
der CapabilityTreeContainer befüllt wird.
DateTimePicker
Eine Objekt dieser Klasse realisiert eine Kombination aus Datumsfeld und Zeitfeld.
TimeAxis
Diese Klasse ist eine Erweiterung der Klasse XAxis und enthält Methoden.
40
3. SOSGui – Grafisches Benutzerinterface zur Datenabfrage und Visualisierung für ein ortsbasiertes
Servicesystem
EventManager, ISelectListener und OverviewLayoutContainer
OverviewLayoutContainer implementiert das Interface ISelectListener. Die Methode addSelectListener() trägt ein Objekt in eine Liste des EventManagers ein. Über die statische Methode getInstance erhält man eine Instanz des EventManagers. Durch einen fireSelectionChanged-Methodenaufruf
werden alle Objekte in der Liste über das Selection-Ereignis informiert, die Methode onSelect der
Listenobjekte wird aufgerufen. OverviewLayoutContainer teilt die Anzeigefläche für die Gui auf.
Sie legt eine ToolBar an, erzeugt ein Tab-Panel für die ObservationTableContent und ein Contentpanel für die CapabilityTreeContainer.
ObservationTableContentPanel
Diese Container-Klasse enthält die Ansicht einer Tabelle, die die Messwerte anzeigt.
CapabilityTreeContainer
Hier findet man einen Baum zur Ansicht der Capabilities des SOS-Servers. Unterhalb der Serverbezeichnung werden die Sensoren und darunter die Phänomene, die der Sensor aufzeichnet, zur Auswahl angezeigt.
ObservationChartWindow
Diese Klasse implementiert ein Fenster, welches die ausgewählten Messwerte im ObservationTableContentPanel, grafisch darstellt.
41
4. Zusammenfassung und Ausblick
4. Zusammenfassung und Ausblick
In dieser Arbeit wird dargestellt, welche Möglichkeiten die Verknüpfung unterschiedlicher Techniken wie das Sensor-Web-Enablement mit einer Rich Internet Application bietet. Das Laborpersonal
hat die Möglichkeit in einer Flexiblen Umgebung, immer unter einer gleichen Benutzeroberfläche
Daten abzurufen. Die Gui bietet einen ersten Überblick über die Daten, in dem es den zeitlichen
Verlauf der Sensormesswerte visualisiert.
Es stellte sich aber heraus, dass das Abspeichern der Messwerte aus einer JavaScript-Anwendung
heraus nicht möglich ist. Durch die Entwicklung mit dem GWT-Compiler, helfen auch die Möglichkeiten vom Google Web Toolkit nicht weiter. Eine Möglichkeit dies zu Implementieren besteht aber
durch Einsatz eines Servlets, das die gewünschten Daten aus dem Sensor Observation Service abholt und einen Downloadlink für diese zur Verfügung stellt. Dies zu implementieren war aus zeitlichen Gründen nicht mehr möglich.
Die verwendete Technik wird sehr aktiv weiterentwickelt. Während der Bearbeitungsphase wurde
für das Google Web Toolkit mehrere Aktualisierungen herausgegeben.
Auch das User Interface Framework ExtGWT erschien während der Entwicklung in einer neuen
Version, die als Haupteigenschaft die Kompatibilität zum Google Web Toolkit verbesserte.
Die vom ExtGWT zur Verfügung gestellten grafischen Elemente ermöglichen den Aufbau einer
Gui, die der einer Desktop-Anwendung kaum nachsteht. Da ExtGWT eigene Konzepte zur Programmierung umsetzt ist der Einstieg in dieses Framework wenig intuitiv. Zudem weist das Framework eine schlecht Dokumentation auf. Der Entwickler findet kaum Beispiele, die vom Hersteller
herausgegebenen sind sehr komplex und nicht vollständig.
Vom Hersteller wird eine Tool vermarktet, was den Aufbau grafischer Oberflächen mittels Gui-Designer ermöglicht. Um schneller und weniger fehleranfällig zu Ergebnissen zu kommen, ist der Einsatz eines solchen Tools anzuraten.
Die Möglichkeiten zur Visualisierung der Messwerte durch das ExtGWT-Framework ist begrenzt.
Der Einsatz von Alternative, zum Beispiel Google Chart Tools Library, könnte Möglichkeiten wie
beispielsweise Hilfslinien oder Drag and Drop innerhalb des Diagramms ermöglichen.
Eine grafische Auswahlmöglichkeit der Sensoren über eine Karte ist gerade in einem Umfeld mit
mobilen Sensoren interessant. Als Ansatz gibt es hier OpenLayers, in das man auch eigene Karten
einbinden kann.
Um die Entwicklung weiter voranzutreiben, ist es aber erforderlich über einen umfangreichen Satz
an Testdaten zu verfügen.
Wenn diese Voraussetzungen erfüllt sind, lassen sich die Möglichkeiten dieser GUI um viele sinnvolle Fähigkeiten erweitern.
42
Anhang
Anhang
SensorML-Beispiel-Dokument
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<sml:SensorML xmlns:sml="http://www.opengis.net/sensorML/1.0.1"
xmlns="http://www.opengis.net/sensorML/1.0.1"
xmlns:gml="http://www.opengis.net/gml"
xmlns:swe="http://www.opengis.net/swe/1.0.1"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0.1"
xsi:schemaLocation="http://www.opengis.net/sensorML/1.0.1
http://schemas.opengis.net/sensorML/1.0.1/sensorML.xsd">
<sml:member>
<sml:System>
<!--sml:identification element must contain the ID of
the sensor-->
<sml:identification>
<sml:IdentifierList>
<sml:identifier>
<sml:Term
definition="urn:ogc:def:identifier:OGC:uniqueID">
<sml:value>
urn:ogc:object:f
eature:Sensor:IFGI:ifgi-sensor-1
</sml:value>
</sml:Term>
</sml:identifier>
</sml:IdentifierList>
</sml:identification>
<!-- sml:capabilities element has to contain status and
mobility information -->
<sml:capabilities>
<swe:SimpleDataRecord>
<!-- status indicates, whether sensor is
collecting data at the moment (true) or not (false) -->
<swe:field name="status">
<swe:Boolean>
<swe:value>true</swe:value>
</swe:Boolean>
</swe:field>
<!-- status indicates, whether sensor is
mobile (true) or fixed (false) -->
<swe:field name="mobile">
<swe:Boolean>
<swe:value>false</swe:value>
</swe:Boolean>
</swe:field>
</swe:SimpleDataRecord>
</sml:capabilities>
<!-- last measured position of sensor -->
<sml:position name="sensorPosition">
43
Anhang
<swe:Position referenceFrame="urn:ogc:def:crs:EPSG:4326">
<swe:location>
<swe:Vector gml:id="STATION_LOCATION">
<swe:coordinate name="easting">
<swe:Quantity axisID="x">
<swe:uom code="degree"/>
<swe:value>7.727958</swe:value>
</swe:Quantity>
</swe:coordinate>
<swe:coordinate name="northing">
<swe:Quantity axisID="y">
<swe:uom code="degree"/>
<swe:value>51.883906</swe:value>
</swe:Quantity>
</swe:coordinate>
<swe:coordinate name="altitude">
<swe:Quantity axisID="z">
<swe:uom code="m"/>
<swe:value>52.0</swe:value>
</swe:Quantity>
</swe:coordinate>
</swe:Vector>
</swe:location>
</swe:Position>
</sml:position>
<!-- list containing the input phenomena for this sensor
system -->
<sml:inputs>
<sml:InputList>
<sml:input name="waterlevel">
<swe:ObservableProperty
definition="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel"/>
</sml:input>
</sml:InputList>
</sml:inputs>
<!-- list containing the output phenomena of this sensor
system; ATTENTION: these phenomena are parsed and inserted into the database;
they have to contain offering elements to determine the correct offering for the
sensors and measured phenomena -->
<sml:outputs>
<sml:OutputList>
<sml:output name="waterlevel">
<swe:Quantity
definition="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel">
<gml:metaDataProperty>
<offering>
<id>GAUGE_HEIGHT</id>
<name>
waterlevel of rivers in North
Rhine Westfalia
</name>
</offering>
</gml:metaDataProperty>
44
Anhang
<swe:uom code="cm"/>
</swe:Quantity>
</sml:output>
</sml:OutputList>
</sml:outputs>
<!-- description of components of this sensor system;
these are currently not used by the 52N SOS -->
<sml:components>
<sml:ComponentList>
<sml:component name="water sensor">
<sml:Component>
<sml:identification>
<sml:IdentifierList>
<sml:identifier>
<sml:Term
definition="urn:ogc:def:identifier:OGC:uniqueID">
<sml:value>
urn:ogc:object:feature:Sensor:water_level_sensor
</sml:value>
</sml:Term>
</sml:identifier>
</sml:IdentifierList>
</sml:identification>
<sml:inputs>
<sml:InputList>
<sml:input name="waterlevel">
<swe:ObservableProperty
definition="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel"/>
</sml:input>
</sml:InputList>
</sml:inputs>
<sml:outputs>
<sml:OutputList>
<sml:output name="waterlevel">
<swe:Quantity
definition="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel">
<swe:uom code="cm"/>
</swe:Quantity>
</sml:output>
</sml:OutputList>
</sml:outputs>
</sml:Component>
</sml:component>
</sml:ComponentList>
</sml:components>
</sml:System>
</sml:member>
</sml:SensorML>
45
Anhang
O&M-Beispiel-Dokument
<?xml version="1.0" encoding="UTF-8"?>
<om:ObservationCollection xmlns:om="http://www.opengis.net/om/1.0"
xmlns:gml="http://www.opengis.net/gml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:sa="http://www.opengis.net/sampling/1.0" gml:id="oc_0"
xsi:schemaLocation="http://www.opengis.net/om/1.0
http://schemas.opengis.net/om/1.0.0/om.xsd http://www.opengis.net/sampling/1.0
http://schemas.opengis.net/sampling/1.0.0/sampling.xsd">
<gml:boundedBy>
<gml:Envelope srsName="urn:ogc:def:crs:EPSG:4326">
<gml:lowerCorner>52.9 7.52</gml:lowerCorner>
<gml:upperCorner>52.9 7.52</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>
<om:member>
<om:Measurement gml:id="o_3">
<om:samplingTime>
<gml:TimeInstant xsi:type="gml:TimeInstantType">
<gml:timePosition>2008-0401T17:46:00.000+02:00</gml:timePosition>
</gml:TimeInstant>
</om:samplingTime>
<om:procedure xlink:href="urn:ogc:object:feature:Sensor:IFGI:ifgisensor-1"/>
<om:observedProperty
xlink:href="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel"/>
<om:featureOfInterest>
<sa:SamplingPoint gml:id="foi_1001">
<gml:name>ALBER</gml:name>
<sa:position>
<gml:Point>
<gml:pos srsName="urn:ogc:def:crs:EPSG:4326">52.9
7.52</gml:pos>
</gml:Point>
</sa:position>
</sa:SamplingPoint>
</om:featureOfInterest>
<om:result uom="cm">70.4</om:result>
</om:Measurement>
</om:member>
<om:member>
<om:Measurement gml:id="o_2">
<om:samplingTime>
<gml:TimeInstant xsi:type="gml:TimeInstantType">
<gml:timePosition>2008-0401T17:45:00.000+02:00</gml:timePosition>
</gml:TimeInstant>
</om:samplingTime>
<om:procedure xlink:href="urn:ogc:object:feature:Sensor:IFGI:ifgisensor-1"/>
<om:observedProperty
xlink:href="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel"/>
<om:featureOfInterest>
46
Anhang
<sa:SamplingPoint gml:id="foi_1001">
<gml:name>ALBER</gml:name>
<sa:position>
<gml:Point>
<gml:pos srsName="urn:ogc:def:crs:EPSG:4326">52.9
7.52</gml:pos>
</gml:Point>
</sa:position>
</sa:SamplingPoint>
</om:featureOfInterest>
<om:result uom="cm">40.2</om:result>
</om:Measurement>
</om:member>
<om:member>
<om:Measurement gml:id="o_1">
<om:samplingTime>
<gml:TimeInstant xsi:type="gml:TimeInstantType">
<gml:timePosition>2008-0401T17:44:00.000+02:00</gml:timePosition>
</gml:TimeInstant>
</om:samplingTime>
<om:procedure xlink:href="urn:ogc:object:feature:Sensor:IFGI:ifgisensor-1"/>
<om:observedProperty
xlink:href="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel"/>
<om:featureOfInterest>
<sa:SamplingPoint gml:id="foi_1001">
<gml:name>ALBER</gml:name>
<sa:position>
<gml:Point>
<gml:pos srsName="urn:ogc:def:crs:EPSG:4326">52.9
7.52</gml:pos>
</gml:Point>
</sa:position>
</sa:SamplingPoint>
</om:featureOfInterest>
<om:result uom="cm">50.0</om:result>
</om:Measurement>
</om:member>
<om:member>
<om:Measurement gml:id="o_6">
<om:samplingTime>
<gml:TimeInstant xsi:type="gml:TimeInstantType">
<gml:timePosition>2008-0401T17:49:00.000+02:00</gml:timePosition>
</gml:TimeInstant>
</om:samplingTime>
<om:procedure xlink:href="urn:ogc:object:feature:Sensor:IFGI:ifgisensor-1"/>
<om:observedProperty
xlink:href="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel"/>
<om:featureOfInterest>
<sa:SamplingPoint gml:id="foi_1001">
<gml:name>ALBER</gml:name>
<sa:position>
<gml:Point>
<gml:pos srsName="urn:ogc:def:crs:EPSG:4326">52.9
47
Anhang
7.52</gml:pos>
</gml:Point>
</sa:position>
</sa:SamplingPoint>
</om:featureOfInterest>
<om:result uom="cm">110.1213</om:result>
</om:Measurement>
</om:member>
<om:member>
<om:Measurement gml:id="o_5">
<om:samplingTime>
<gml:TimeInstant xsi:type="gml:TimeInstantType">
<gml:timePosition>2008-0401T17:48:00.000+02:00</gml:timePosition>
</gml:TimeInstant>
</om:samplingTime>
<om:procedure xlink:href="urn:ogc:object:feature:Sensor:IFGI:ifgisensor-1"/>
<om:observedProperty
xlink:href="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel"/>
<om:featureOfInterest>
<sa:SamplingPoint gml:id="foi_1001">
<gml:name>ALBER</gml:name>
<sa:position>
<gml:Point>
<gml:pos srsName="urn:ogc:def:crs:EPSG:4326">52.9
7.52</gml:pos>
</gml:Point>
</sa:position>
</sa:SamplingPoint>
</om:featureOfInterest>
<om:result uom="cm">45.456</om:result>
</om:Measurement>
</om:member>
<om:member>
<om:Measurement gml:id="o_4">
<om:samplingTime>
<gml:TimeInstant xsi:type="gml:TimeInstantType">
<gml:timePosition>2008-0401T17:47:00.000+02:00</gml:timePosition>
</gml:TimeInstant>
</om:samplingTime>
<om:procedure xlink:href="urn:ogc:object:feature:Sensor:IFGI:ifgisensor-1"/>
<om:observedProperty
xlink:href="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel"/>
<om:featureOfInterest>
<sa:SamplingPoint gml:id="foi_1001">
<gml:name>ALBER</gml:name>
<sa:position>
<gml:Point>
<gml:pos srsName="urn:ogc:def:crs:EPSG:4326">52.9
7.52</gml:pos>
</gml:Point>
</sa:position>
</sa:SamplingPoint>
</om:featureOfInterest>
48
Anhang
<om:result uom="cm">60.5</om:result>
</om:Measurement>
</om:member>
</om:ObservationCollection>
49
Anhang
Klassendiagramm des Serverpaketes
50
Klassendiagramm des Clientpaketes
51
Literaturverzeichnis
Literaturverzeichnis
[1]
Wagner, Benjamin: Ortsbasiertes Service-System für die Laborautomatisierung,
Diplomarbeit, Universität Rostock, 2010
[2]
OGC White Paper - OGC Sensor Web Enablement: Overview And High Level
Architecture, Open Geospatial Consortium Inc., 2007
[3]
Klipp, Roman: Sensor Web Standards für proprietäre Messnetze, Diplomarbeit,
Berufsakademie Gera - University of Cooperative Education, 2008
[4]
OpenGIS® Implementation Standard - Sensor Observation Service, Open Geospatial
Consortium Inc., 2007
[5]
OpenGIS© Discussion Paper - Sensor Model Language (SensorML)for In-situ and
Remote Sensors, Open GIS Consortium Inc., 2002
[6]
OpenGIS® Implementation Standard - Observations and Measurements –Part 1 Observation schema, Open Geospatial Consortium Inc., 2007
[7]
OpenGIS® Implementation Standard - Observations and Measurements –Part 2 Sampling Features, Open Geospatial Consortium Inc., 2007
[8]
Google Web Toolkit API Reference, http://google-webtoolkit.googlecode.com/svn/javadoc/2.1/index.html, Google Inc., geprüft am 10.01.2011
[9]
Internationalizing a GWT Application, http://code.google.com/intl/deDE/webtoolkit/doc/latest/tutorial/i18n.html, Google Inc., geprüft am 10.01.2011
[10]
Unit Testing GWT Applications with JUnit, http://code.google.com/intl/deDE/webtoolkit/doc/latest/tutorial/JUnit.html, Google Inc., geprüft am 10.01.2011
[11]
Communicating with the server, http://code.google.com/intl/deDE/webtoolkit/doc/latest/tutorial/clientserver.html, Google Inc., geprüft am 10.01.2011
[12]
Ext GWT Help Center, http://www.sencha.com/helpcenter/index.jsp, Sencha Inc.,
geprüft am 10.01.2011
[13]
Bröring, Arne; Jürrens, Eike Hinderk; Jirka, Simon; Stasch, Christoph: Development of
Sensor Web Applications with Open Source Software, 52° North Initiative for
Geospatial Open Source Software GmbH, 2009
[14]
Heß, Christian: Dienst-orientierte Middleware für die Einbindung von Sensordaten in
Anwendungen, Diplomarbeit, Universität Rostock, 2009
[15]
User's Guide - eZ430-RF2480 Demonstration Kit, Texas Instruments, 2008
[16]
Data Sheet - MSP430x22x2, MSP430x22x4 Mixed Signal Microcontroller, Texas
Instruments, 2006
[17]
Fox Board LX832 - A complete Linux system in just 66x72mm,
http://foxlx.acmesystems.it/?id=4, ACME Systems, geprüft am 10.01.2011
[18]
Sensor Web Enablement - Installation Guide for Sensor Observation Service, 52°North
Initiative for Geospatial Open Source Software GmbH, 2010
52