DPArchiv.0068
Werbung
Diplomarbeit
Web-Services zur Datenintegration mobiler
Endgeräte
Tom Koenig
Februar 2003
Betreuer: Prof. Dr. Paul Müller
Dipl. Inform. Markus Hillenbrand
Fachbereich Informatik
AG Integrierte Kommunikationssysteme
Universität Kaiserslautern Postfach 3049 67653 Kaiserslautern
Experimente sind in diversen Bereichen nicht sinnvoll anwendbar, da aufgrund des Einflusses
vielfältiger Störfaktoren eine Abbildung der entsprechenden Situation nicht möglich ist. In diesen
Bereichen kann die Anwendung von Simulationen, auf geeigneten Modellen basierend, Abhilfe
schaffen. Es ist oftmals nötig zum einen, Wechselwirkungen zwischen verschiedenen Faktoren
aufzudecken, zum anderen im Rahmen einer Optimierung, durch Abstimmung der entsprechenden
Faktoren, eine Minimierung dieser Wechselwirkungen zu erzielen. Mit Hilfe von Simulationen kann
eine Unterstützung dieser Aufgaben erfolgen. Modelle, die als Basis für eine Simulation dienen,
benötigen jedoch eine Datengrundlage um ein realitätsnahes Abbild der jeweiligen Situation zu
schaffen. Ziel dieser Arbeit ist es ein Software System zu konzipieren und zu entwickeln, das es zum
einen ermöglicht eine entsprechende Datengrundlage zu schaffen, zum anderen einen Zugriff auf diese
Daten bereitstellt, um diese im Rahmen von Modellen zu verwenden.
Im Bereich der Stadt- und Raumplanung beispielsweise wird das Nachhaltigkeitsprinzips zunehmend
zum Leitprinzip. Es ist von essentieller Bedeutung, ein Abstimmen der Säulen Ökonomie, Ökologie
und Soziales jeglichem Handeln zugrunde zu legen. Das Ziel ist, unter Berücksichtigung der heutigen
Anforderungen keine Einscheidung für zukünftige Generationen zu erhalten. Aufgrund vielfältiger
Wechselwirkungen zwischen Faktoren der drei Säulen kann dies sich als sehr problematisch erweisen.
Geeignete Simulationen können jedoch eingesetzt werden, um das Erreichen des Prinzips der
Nachhaltigkeit zu unterstützen.
Ich versichere, dass ich die vorliegende Diplomarbeit selbständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel verwendet habe.
(Tom Koenig)
Inhaltsverzeichnis
Inhaltsverzeichnis
Kapitel 1:
Einführung .......................................................................................................... 9
1.1
Einführung............................................................................................................................9
1.2
Problembeschreibung .........................................................................................................10
1.3
Benutzeranforderungen und Entwurfsentscheidungen .......................................................12
Kapitel 2:
Unterstützende Technologien .......................................................................... 14
2.1
Einleitung ...........................................................................................................................14
2.2
XML/HTTP ........................................................................................................................14
2.2.1
XML ...................................................................................................................................14
2.2.2
XML Namespaces ..............................................................................................................16
2.2.3
XML Schema .....................................................................................................................18
2.2.4
HTTP ..................................................................................................................................20
2.3
Web-Services .....................................................................................................................20
2.3.1
Einführung..........................................................................................................................20
2.3.2
Anforderungen ...................................................................................................................21
2.4
JINI .....................................................................................................................................32
2.4.1
Einführung..........................................................................................................................32
2.4.2
Komponenten .....................................................................................................................33
2.4.3
JINI Dienste........................................................................................................................34
2.4.4
Voraussetzungen ................................................................................................................34
2.5
.NET ...................................................................................................................................35
2.5.1
.NET-Framework ...............................................................................................................36
2.5.2
Web-Services .....................................................................................................................40
2.5.3
Sicherheit der XML Web-Services ....................................................................................42
2.5.4
Visual Studio .NET ............................................................................................................43
2.6
SUN ONE ...........................................................................................................................43
2.6.1
Services on Demand ...........................................................................................................43
2.6.2
ONE-Architektur ................................................................................................................44
2.6.3
Web-Services .....................................................................................................................46
2.6.4
Sicherheit der Web-Services ..............................................................................................47
2.6.5
Kompabilität zu Microsoft .NET........................................................................................49
Kapitel 3:
Vergleich der Plattformen ............................................................................... 50
3.1
Sun ONE versus Microsoft .NET .......................................................................................50
3.1.1
Reife ...................................................................................................................................50
3.1.2
Programmiersprache...........................................................................................................51
3.1.3
Portabilität ......................................................................................................................... 51
3.1.4
Web-Services (allgemein) ................................................................................................. 51
3.1.5
Technologie ....................................................................................................................... 51
3.1.6
Entwicklungswerkzeug ...................................................................................................... 52
3.1.7
Datenbankzugriff ............................................................................................................... 52
3.1.8
Web-Services ..................................................................................................................... 52
3.1.9
XML-Unterstützung .......................................................................................................... 52
3.1.10
Sicherheit ........................................................................................................................... 53
3.2
Übersicht und Empfehlung ................................................................................................ 53
3.3
Erweiterung der Anforderungen ........................................................................................ 54
Kapitel 4:
Realisierungsentscheidung .............................................................................. 55
4.1
Mobiles Endgerät ............................................................................................................... 55
4.1.1
Erfassen der Daten ............................................................................................................. 55
4.1.2
Aufbereiten der Daten ....................................................................................................... 56
4.1.3
Anbieten der Daten ............................................................................................................ 57
4.1.4
Sicherheit ........................................................................................................................... 60
4.2
Daten-Server ...................................................................................................................... 60
4.2.1
Informationen .................................................................................................................... 61
4.2.2
Kommunikation Middleware – Daten-Server ................................................................... 61
4.2.3
Sicherheit ........................................................................................................................... 62
4.3
Middleware ........................................................................................................................ 62
4.3.1
Persistente Speicherung der Daten (Kommunikation Middleware – mobiles Endgerät) .. 63
4.3.2
Client-Zugriff (Kommunikation Middleware - Client) ..................................................... 64
4.4
Erweiterung der Anforderungen ........................................................................................ 70
4.5
Verifikation Entwickleranforderungen - Benutzeranforderungen ..................................... 71
Kapitel 5:
Realisierung ...................................................................................................... 73
5.1
Mobiles Endgerät ............................................................................................................... 73
5.1.1
Erfassen der Daten ............................................................................................................. 73
5.1.2
Aufbereiten der Daten ....................................................................................................... 77
5.1.3
Anbieten der Daten ............................................................................................................ 82
5.1.4
Sicherheit ........................................................................................................................... 82
5.2
Daten-Server ...................................................................................................................... 84
5.3
Middleware ........................................................................................................................ 85
5.3.1
Komponenten..................................................................................................................... 86
5.3.2
Web-Services ..................................................................................................................... 95
5.3.3
Datenbankschema ............................................................................................................ 103
5.4
Client ............................................................................................................................... 103
Inhaltsverzeichnis
5.4.1
Client API.........................................................................................................................104
5.4.2
GPS ..................................................................................................................................105
5.4.3
Client-Anwendung ...........................................................................................................106
5.5
Gesamtsystem im Überblick ............................................................................................106
5.6
Erweiterung der Anforderungen .......................................................................................107
5.7
Verifikation ......................................................................................................................107
Kapitel 6:
Implementierung ............................................................................................ 109
6.1
Mobiles Endgerät (C++ Komponenten) ...........................................................................109
6.2
Daten-Server (C++/CGI Komponente) ............................................................................110
6.3
Middleware (Java-Klassen) ..............................................................................................110
6.4
Verifikation ......................................................................................................................112
6.4.1
Inverse Anforderungen .....................................................................................................112
Kapitel 7:
Zusammenfassung und Ausblick .................................................................. 114
Kapitel 8:
Anhang A ......................................................................................................... 116
8.1
Mobiles Endgerät .............................................................................................................116
8.1.1
Versuchsanordnung: .........................................................................................................116
8.1.2
Konfiguration des Informationsflusses auf dem Board ....................................................118
8.1.3
GPS-Chip .........................................................................................................................120
8.1.4
Temperaturmodul .............................................................................................................121
8.1.5
LCD Modul ......................................................................................................................121
8.2
Konfigurationsdateien ......................................................................................................121
8.2.1
Mobiles Endgerät .............................................................................................................121
8.2.2
Middleware.......................................................................................................................123
8.3
Web-Services ...................................................................................................................124
8.3.1
ant .....................................................................................................................................124
8.3.2
Web-Service konfigurieren ..............................................................................................127
8.3.3
Erstellen, Veröffentlichen und Aufrufen eines Web-Services .........................................128
8.3.4
Datenbank.........................................................................................................................128
Kapitel 9:
Anhang B ......................................................................................................... 129
9.1
Statuscodes der Middleware und ihre Bedeutung ............................................................129
9.2
Statuscodes und zu treffende Maßnahmen .......................................................................131
Kapitel 10:
Anhang C ..................................................................................................... 133
Kapitel 11:
Anhang D ..................................................................................................... 137
11.1
Validierung .......................................................................................................................137
11.1.1
Middleware Komponente Server, Komponente Registrierung ........................................138
11.1.2
Middleware Komponente Update ....................................................................................138
11.1.3
Middleware Komponente Config .....................................................................................146
11.1.4
Middleware Komponente Authorization ......................................................................... 148
11.1.5
Middleware Komponente Payment ................................................................................. 149
11.1.6
Middleware Komponente ClientAPI ............................................................................... 152
11.1.7
Middleware Komponente EarthCoord, Komponente GPSCheck, Komponente
GPSNMEA, Komponente CoordTransform....................................................................................... 159
11.1.8
Mobiles Endgerät: Komponente chipmodul .................................................................... 162
11.1.9
Daten-Server : Komponente CGI-Modul ........................................................................ 164
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 1: Einführung
Problembeschreibung und Anforderungen
1.1 Einführung
In vielen Forschungsbereichen ist der Einsatz von Experimenten nicht möglich, da die entsprechenden
Situationen und vor allem deren Entwicklung Auf Grundlage von Einflussfaktoren (Störfaktoren)
nicht vorhersagbar sind und somit eine experimentelle Umgebung nicht realistisch modellierbar ist. In
diesen Bereichen können jedoch Simulationen auf Basis geeigneter Modelle herangezogen werden,
um ein entsprechendes realitätsnahes Abbild zu schaffen und Entscheidungen auf dieser Grundlage zu
ermöglichen. Eine Simulation und die der Simulationen zugrunde liegende Modelle erfordern eine
entsprechende Datengrundlage. Ohne Datengrundlage kann keine Modellierung der Situation und
keine Simulation erfolgen. Das in dieser Arbeit konzipierte und realisierte System ermöglicht es, eine
entsprechende Datengrundlage zu schaffen, um somit mögliche Modelle zu erstellen und anzuwenden.
Aufgrund der notwendigen Unterstützung einer großen Vielfalt an Datenquellen (Sensoren, DatenServer, etc.) wird in dieser Arbeit ein allgemeingültiger Ansatz zur Datenbeschaffung und
Datenhaltung bereitgestellt. Als Beispiele für die vielfältigen möglichen Daten seien hier
stellvertretend genannt:
Temperatur,
Regenmenge,
Pläne und
Skizzen.
Ein mögliches Szenario stellt das Prinzip der "Nachhaltigen Entwicklung" dar, das als zentrales
Leitbild der Stadt- und Regionalplanung übernommen wurde. Die zukünftige Entwicklung muss den
drei Dimensionen Gesellschaft, Wirtschaft und Umwelt Rechnung tragen, die die Grundlage dieses
Ansatzes darstellen. Ziel ist es, unter Berücksichtung der gegenwärtigen Anforderungen die
Möglichkeiten nachfolgender Generationen zu erhalten. Eine Abstimmung dieser drei Dimensionen
muss jedem Handeln zugrunde liegen, um so die Umsetzung des Ziels zu ermöglichen. Um ein
ökonomisch-ökologisch-soziales Gleichgewicht zu schaffen, muss es vor allem möglich sein,
Wechselwirkungen verschiedenster Faktoren aus diesen drei Bereichen zu bestimmen, um so eine
Abstimmung dieser Faktoren aufeinander zu ermöglichen. Auf Basis einer entsprechenden
Datengrundlage können Simulationen (Modelle) eingesetzt werden, die eine Minimierung dieser
Wechselwirkungen erreichen.
Seite 9
Web-Services zur Datenintegration mobiler Endgeräte
1.2 Problembeschreibung
Die Bereitstellung der Datengrundlage wird im Rahmen dieser Arbeit in mehrere Schritte unterteilt:
In einem ersten Schritt muss eine Beschaffung der Daten erfolgen. Im Rahmen der Datenerfassung
können zwei Datentypen unterschieden werden: dynamische und statische Daten. Statische Daten sind
"unveränderlich" und werden direkt angeboten (ohne Messung). Beispiele hierfür sind Pläne oder
Skizzen. Im Gegensatz dazu müssen dynamische Daten in einem ersten Schritt gemessen werden,
bevor ein Anbieten der Daten stattfinden kann. In diesem Bereich sind Mechanismen nötig, um die
Daten zu erfassen (in Form von Programmen). Mögliche Beispiele dafür sind Temperatur oder
Regenmenge.
Auf Grundlage dieser Typunterscheidung werden im Rahmen der vorliegenden Arbeit zwei
Datenquelltypen unterschieden
Mobile Endgeräte sowie
Daten-Server.
Die Bezeichnung "Endgerät" wird nachfolgend als Sammelbegriff für diese beiden Typen verwendet
und steht somit für die in dieser Arbeit zu erfassenden Datenquellen.
Ein mobiles Endgerät verfügt über mehrere Sensoren, die ständig aktuelle Daten liefern (z.B.
Temperatur) und dementsprechend in regelmäßigen Abständen abgefragt werden müssen, um so
immer einen möglichst aktuelle Datengrundlage zu schaffen. Ein Daten-Server hingegen stellt keine
Mechanismen zur Erfassung von Daten bereit, es werden nur fest eingespeiste Daten angeboten. Es
handelt sich dabei um statische Daten, die nicht in regelmäßigen Abständen, sondern nur bei Bedarf
aktualisiert werden.
Demzufolge kann Auf Grundlage obiger Erläuterung folgende Zuordnung getroffen werden:
Mobiles Endgerät ↔ dynamische Daten bzw.
Daten-Server ↔ statische Daten.
Nach der Datenbeschaffung sollen die Daten in einem standardisierten Format abgelegt werden, um
zum einen die Erfassung möglichst vielfältiger Datentypen zu ermöglichen und zum anderen die
Weiterverarbeitung einfach zu gestalten.
Ähnlich wie die Datenaufbereitung soll auch der Datentransfer möglichst standardisiert ablaufen. In
diesem Bereich werden in dieser Arbeit drei Ansätze analysiert, die einen entsprechenden Transfer
gewährleisten können:
Seite 10
Web-Services zur Datenintegration mobiler Endgeräte
Web-Services (SOAP),
JINI bzw.
XML und HTTP.
Um eine Datengrundlage schaffen zu können, ist es nötig die Daten persistent ablegen zu können. In
dieser Arbeit werden die Daten zu diesem Zweck von einer zentralen Instanz, einer so genannten
"Middleware" gesammelt. Diese Middleware sammelt Daten unterschiedlichster Quellen und legt sie
persistent in einer Datenbank ab. Die Daten können dann in einem letzten Schritt (zentral) angeboten
werden. Es besteht die Möglichkeit den gesammelten Datenbestand "Clients" zur Verfügung zu
stellen. Es ist somit möglich beispielsweise die Daten in mathematische Modelle einfließen zu lassen
(z.B. Wettermodelle). Für diese Arbeit wurde ein zentraler Ansatz zur Datenhaltung und somit auch
zum Anbieten der Daten gewählt, da eine dezentrale Lösung zum Teil erhebliche Nachteile aufweist.
Ein dezentraler Ansatz setzt immer die Kenntnis der physischen Adresse aller nötigen Endgeräte
voraus, die als Datengrundlage für einen Client dienen sollen; eine Middleware abstrahiert von diesem
Aspekt. Der Speicherplatz eines Endgeräts ist begrenzt und würde somit nach kürzester Zeit zur
Verdrängung früher Ergebnisse führen, es können somit beispielsweise Zeitreihen nicht vollständig
aufgestellt werden. Ein zentraler Ansatz hält hingegen alle gesammelten Daten bereit, so dass
vielfältige Auswertungsmöglichkeiten denkbar sind.
Im Bereich des Anbietens der Daten werden zwei Ansätze zur Implementierung der Web-Service
Architektur analysiert, die eine "neue" Art der plattformunabhängigen Bereitstellung von
Informationen und Funktionalitäten anbieten:
Sun ONE
.NET
Neben obigen Anforderungen werden drei weitere Aspekte im Rahmen der Problembeschreibung
erläutert und auf ihre Verwendung hin untersucht:
Im Rahmen der Datensicherheit soll festgelegt werden, wer wann auf welche Daten zugreifen darf.
Eine Verschlüsselung soll die Art des Schutzes bei der Übertragung der Daten festlegen. Des Weiteren
soll eine Abrechnung vorgesehen werden, die eine Möglichkeit zur Bezahlung von Informationen
berücksichtig.
Im Rahmen der Arbeit gilt es, eine Schnittstelle zur Verfügung zu stellen, die obige Anforderungen
erfüllt.
Die Schnittstelle, die in einem ersten Schritt der Arbeit theoretisch entwickelt wird, wird dann in
einem zweiten Schritt praktisch implementiert.
Seite 11
Web-Services zur Datenintegration mobiler Endgeräte
Die Implementierung wird prototypisch realisiert, es steht zu diesem Zweck ein Prototyp eines
mobilen Endgeräts zur Verfügung. Dieser Prototyp enthält neben einem Beck IPC SC12, einen GPSEmpfänger und sieht die Möglichkeit vor, weitere Sensoren zu betreiben. Der SC12-Chip bietet die
Möglichkeit Programme auszuführen, die mittels C/C++ erstellt wurden. Des Weiteren kann über den
angeschlossenen GPS-Empfänger die aktuelle Position des Endgeräts aus einem Programm heraus
ermittelt werden. An weiteren Schnittstellen können exemplarisch zusätzliche Datenquellen betrieben
werden, die ebenfalls aus Programmen heraus abgefragt werden können. Somit ist es möglich, eine
exemplarische Datengrundlage im Rahmen der Implementierung zu schaffen.
Aus obiger Problembeschreibung ergeben sich also folgende Benutzeranforderungen, die an das
System gestellt werden:
1.3 Benutzeranforderungen und Entwurfsentscheidungen
Funktionale Benutzeranforderung
Mobiles Endgerät
FBA1
Daten erfassen
FBA2
Daten allgemeingültig aufbereiten
Daten allgemeingültig zur Verfügung stellen
FBA3
(mehrere Möglichkeiten untersuchen: WebServices, JINI, XML und HTTP)
Daten-Server
FBA4
Daten allgemeingültig zur Verfügung stellen
Middleware
FBA5
Daten sammeln
FBA6
Daten in einer Datenbank ablegen
Daten anbieten (verschiedene mögliche
FBA7
Implementierungen von Web-Services
untersuchen)
FBA8
Datensicherheit
FBA9
Verschlüsselung
FBA10
Abrechnung
Seite 12
Web-Services zur Datenintegration mobiler Endgeräte
Inverse Anforderung
Middleware
Die Konsistenz der Daten darf nicht verletzt
IA1
werden. Es muss das ACID-Prinzip für die
Datenbank gewahrt bleiben.
Fehler werden abgefangen – System darf nur in
Situationen, in denen ein Weiterarbeiten
IA2
unmöglich ist, beendet werden (wenn möglich
Fehlerursache per E-Mail an Administrator
melden)
Entwurfsentscheidungen
Mobiles Endgerät
EE1
EE2
Die zu benutzende Hardware ist ein Beck IPC
SC12
Programmiersprache C/C++
Daten-Server
EE3
CGI-Programmierung
Middleware
EE4
Die eingesetzte Datenbank ist PostgreSQL
Seite 13
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 2: Unterstützende Technologien
Beschreibung relevanter Technologien
2.1 Einleitung
Dieses Kapitel gibt eine Einführung in mögliche Technologien zur Realisierung der benötigten
Funktionalität der Endgeräte, sowie der Middleware, die im vorherigen Kapitel erläutert wurde.
In einem ersten Schritt werden mögliche Technologien vorgestellt, die die Funktionalität des
Endgerätes bereitstellen können. Im Einzelnen sind dies:
XML/HTTP,
Web-Services und
JINI.
Anschließend werden dann zwei Ansätze zur Umsetzung der Middleware erläutert:
.NET und
Sun ONE.
Es sei an dieser Stelle erwähnt, dass in diesem Kapitel obige Technologien nicht mit der Realisierung
in Bezug gesetzt werden, es werden ausschließlich allgemeine Einführungen in die genannten
Technologien gegeben. Beleuchtet werden nur die Aspekte der jeweiligen Technologie, die für den
weiteren Verlauf der Arbeit relevant sind. Weiterführende Gesichtspunkte der einzelnen Technologien
können den jeweils angeführten Literaturangaben entnommen werden.
2.2 XML/HTTP
2.2.1
XML
2.2.1.1 Einführung
XML, die Extensible Markup Language, ist eine Beschreibungssprache, die es ermöglicht
Informationen in einer einfach verständlichen Weise zu spezifizieren. Im Gegensatz zu HTML, die
sich nur auf die Darstellung von Informationen beschränkt, bietet XML eine Möglichkeit
Informationen über den Inhalt anzugeben.
Seite 14
Web-Services zur Datenintegration mobiler Endgeräte
2.2.1.2 Struktur eines XML-Dokuments
Ein XML-Dokument muss einer bestimmten Struktur entsprechen, damit es interpretierbar wird.
Entspricht ein XML-Dokument einer vorgegebenen Syntax, siehe hierzu [BrPaSp98], gilt das XMLDokument als wohlgeformt. Im Folgenden wird nun die Syntax eines XML-Dokumentes erläutert.
Ein XML-Dokument besteht allgemein aus zwei Elementen:
prolog und
element.
An folgendem Beispiel können beide Elemente anschaulich erläutert werden.
<?xml version="1.0"?>
<DOCTYPE email SYSTEM "email.dtd">
<email>
<empfaenger>Herr A</empfaenger>
<absender>Firma B</absender>
<betreff>Bestellung vom 1.1.2002</betreff>
<nachricht>
Ihre Bestellung ist bei uns eingegangen und wird bearbeitet.
Mit freundlichen Grüßen
Firma B
</nachricht>
</email>
</xml>
Beispiel 1: XML-Dokument
prolog
Das prolog-Element enthält die so genannte XML Deklaration:
<?xml version="1.0"?>
Diese gibt die verwendete XML Version an.
Zweites Element des prolog ist die Angabe der Dokumenttyp-Definition (DTD). Dieses Element ist
von zentraler Bedeutung, da die DTD die Grammatik für ein XML-Dokument enthält. In der DTD
wird beschrieben, welche Elemente das XML-Dokument enthalten muss und in welcher Form diese
vorliegen müssen. Man kann ein XML-Dokument als eine Instanz einer DTD ansehen. Folgendes
Beispiel gibt die DTD zu obigem XML-Dokument an:
Seite 15
Web-Services zur Datenintegration mobiler Endgeräte
<!ELEMENT email (empfaenger,absender,betreff,nachricht)>
<!ELEMENT empfaenger (#PCDATA)>
<!ELEMENT absender (#PCDATA)>
<!ELEMENT betreff (#PCDATA)>
<!ELEMENT nachricht (#PCDATA)>
Beispiel 2: Dokumenttyp-Definition
Die DTD beschreibt also in Beispiel 2 das Element E-Mail, das aus den Feldern empfaenger,
absender, betreff und nachricht bestehen muss. Zu den jeweiligen Feldern wird dann noch
eine Typdefinition angegeben, in diesem Beispiel sind alle Felder vom Typ #PCDATA was einem
Textfeld entspricht. Weitere Informationen zu Typbezeichnern können der XML-Spezifikation
[BrPaSp98] entnommen werden.
element
Dieser Teil des XML-Dokuments enthält die eigentlichen Daten, die in der (durch die DTD)
spezifizierten Form bereitliegen müssen. Die Daten werden in Form von Tags angegeben, wie das
auch aus HTML bekannt ist. In HTML sind die Tags vorgegeben (etwa <title> zur Angabe des
Titels der Webseite), während die Tags in XML durch Angabe der DTDs selbst erstellt werden und
die zu speichernden Informationen widerspiegeln. Jedes Element aus der DTD wird in einem XMLDokument durch ein Tag repräsentiert. In Beispiel 1 wird die DTD aus Beispiel 2 instantiiert und so
eine E-Mail-Nachricht in Form eines XML-Dokumentes beschrieben.
Eine weitere kurze Einführung in XML kann folgenden Referenzen entnommen werden [Tra00],
[Koe00].
Es wurden einige Erweiterungen zu XML veröffentlicht, die eine Reihe von Problemen in der
Standard-Version der XML beseitigen und XML um einige Funktionalitäten ergänzen.
Zwei dieser Erweiterungen werden nun folgend beschrieben, diese sind für den weiteren Verlauf der
Arbeit von Interesse, da Standards wie etwa SOAP darauf aufbauen.
2.2.2
XML Namespaces
Eine Erweiterung der XML sind die so genannten Namensräume, Namespaces.
Ein Problem der XML stellen Dokumente dar, die Elemente und Attribute aus mehreren
Dokumenttyp-Definitionen verwenden. Die Verwendung dieser Elemente führt in einem Dokument
dann unweigerlich zu Mehrdeutigkeiten, da nicht entschieden werden kann, zu welcher Grammatik ein
Element gehört.
Dieses Problem wird durch die Angabe von Namensräumen gelöst. Ein Namensraum ist ein Uniform
Ressource Identifier (URI), über den ein Element eindeutig identifiziert werden kann.
Seite 16
Web-Services zur Datenintegration mobiler Endgeräte
Die Deklaration eines Namensraums nsp für ein Element e sieht wie folgt aus:
<e xmlns:nsp='http://www.xyz.com/element_e'>
...
</e>
Beispiel 3: Deklaration eines XML Namespace
Durch diese Deklaration wird das Element e und alle seine Subelemente eindeutig an den
Namensraum nsp gebunden und Mehrdeutigkeiten, die durch Attribute oder Elemente innerhalb des
Elements e entstanden sind, können so vermieden werden.
Folgendes Beispiel zeigt ein XML-Dokument, in dem ein Konflikt entsteht:
<prüfung>
<student>
<name>ABC</name>
...
</student>
<professor>
<name>ABC</name>
...
</professor>
</prüfung>
Beispiel 4: Konflikt durch Mehrdeutigkeit
Das Element name ist doppelt vorhanden und um diesen Konflikt zu lösen, werden Namensräume
deklariert und an die Elemente student und professor gebunden:
<prüfung
xmlns:stu=http://www.server.com/student"
xmlns:pro=http://www.server.com/professor">
<stu:student>
<stu:name>ABC</stu:name>
...
</stu:student>
<pro:professor>
<pro:name>ABC</pro:name>
...
</pro:professor>
</prüfung>
Beispiel 5: Auflösung eines Konflikts durch Deklaration geeigneter Namensräume
Weitere Erläuterungen zu XML-Namensräumen können folgender Referenz entnommen werden:
[Schu01].
Seite 17
Web-Services zur Datenintegration mobiler Endgeräte
2.2.3
XML Schema
Eine weitere Erweiterung der XML stellt XML Schema dar, es kann als erweitertes Pendant zu dem
üblichen DTD verstanden werden. Die DTDs waren aufgrund ihrer Mächtigkeit immer der Kritik
seitens der Benutzer ausgesetzt. Eine Dokumenttyp-Definition ist nicht hierarchisch aufgebaut, es
kann zwar eine Hierarchie durch Verwenden definierter Elemente geschaffen werden, wie dies in
Beispiel 2 für das E-Mail-Element der Fall ist, dies ist aber eine eher künstlich geschaffene Hierarchie.
XML Schema bietet in diesem Bereich die Möglichkeit Elemente klar hierarchisch zu definieren.
Des Weiteren ist es nicht möglich mittels einer DTD-Restriktionen bezüglich eines Elements zu
spezifizieren, so zum Beispiel das Vorkommen eines Elements als optional oder aber zwingend
notwendig anzugeben. Ein Element innerhalb einer DTD muss in einem XML-Dokument zwingend
vorhanden sein, ansonsten entspricht das Dokument nicht seiner Grammatik und wird als fehlerhaft
betrachtet. In diesem Bereich bietet XML Schema ebenfalls Abhilfe, es kann durch Angabe von
Minimal- und Maximalwerten exakt auf das Vorkommen eines Elements eingegangen werden.
XML Schema sollen, wie dies auch für eine DTD der Fall ist, eine Klasse von Dokumenten
beschreiben, sie bilden ähnlich wie eine DTD eine Grammatik für eine Klasse von Dokumenten. Ein
XML Schema ist selbst ein XML-Dokument, somit ist nur ein Parser zur Verarbeitung notwendig.
Struktur
Folgende beiden Beispiele veranschaulichen die Struktur einerseits eines XML-Dokuments unter
Verwendung eines Schemas, andererseits auch die Struktur des Schemas selbst.
<xsd:schema xmlns:xsd="www.server.com/xyz">
<xsd:annotation>
<xsd:documentation xml:lang="DE">
Definition einer Prüfung durch Angabe aller nötigen Elemente
</xsd:documentation>
</xsd:documentation>
<xsd:element name="prüfung" type="prüfungtyp"/>
<xsd:complexType name="prüfungtyp" mixed="true">
<xsd:sequence>
<xsd:element name="prüfer" type="person" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="prüfling" type="person" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="beisitzer" type="person" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="vorlesung" type="xsd:String" minOccurs="1"
maxOccurs="unbound"/>
</xsd:sequence>
<xsd:attribute name="datum" type="xsd:date"/>
<xsd:attribute name="uhrzeit" type="xsd:time"/>
</xsd:complexType>
Seite 18
Web-Services zur Datenintegration mobiler Endgeräte
<xsd:complexType name="person">
<xsd:element name="vorname" type="xsd:String" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="name" type="xsd:String" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="matrikelnummer" type="xsd:String" minOccurs="0"
maxOccurs="1"/>
</xsd:complexType>
</xsd:schema>
Beispiel 6: XML Schema
Ein Schema wird an einen Namensraum, wie in vorheriger Sektion beschrieben, gebunden. Es besteht
die Möglichkeit innerhalb eines Schemas Anmerkungen anzubringen, dies kann mittels des Elements
annotation erfolgen. Innerhalb des annotation Elements gibt es mehrere Möglichkeiten
Anmerkungen zu verfassen, je nachdem ob die Anmerkung durch eine Anwendung verarbeitet wird
oder aber vom Anwender gelesen wird. In obigem Beispiel wird zweiter Fall verfolgt und mittels des
documentation Subelements kann ein freier Text angegeben werden.
Das Schema besteht aus einem Element im Stamm des Dokuments, nämlich dem Element prüfung,
das vom Typ prüfungtyp ist. Im folgenden Teil des XML Schema Dokuments werden alle
benötigten Typen definiert. Zu Beginn wird der Typ prüfungtyp definiert, dann alle weiteren
Typen, die innerhalb dieses Typs verwendet worden sind.
Ein Element kann vom Typ complexType oder simpleType sein, je nachdem ob es sich um
einen zusammengesetzten Typ oder aber um einen einfachen Typ, beispielsweise einen String etc.
handelt.
Der Typ prüfungtyp besteht aus einem Prüfer, einem Prüfling und einem Beisitzer, allesamt
Elemente des Typs person. Eine Person besteht aus einem Namen, einem Vornamen und eventuell
einer Matrikelnummer. Die Attribute minOccurs und maxOccurs bieten, wie oben bereits
erwähnt, die Möglichkeit, das minimale und maximale Auftreten eines Elements anzugeben. Das
Element matrikelnummer muss also in obigem Beispiel nicht notwendigerweise auftreten, wenn
es
aber
auftritt,
darf
es
höchstens
einmal
auftreten.
Es besteht
im Rahmen
dieser
Häufigkeitsbeschränkungen sogar die Möglichkeit Elemente auszuschließen, indem beide Attribute
den Wert Null zugewiesen bekommen.
Neben den drei Personen-Elementen enthält eine Prüfung des Weiteren noch ein Element
vorlesung, das ein einfaches Element vom Typ String darstellt und zwei Attribute, zum einen
das Datum, zum anderen die Uhrzeit zu der die Prüfung stattfindet.
Nach Abschluss der Definition eines Schema-Dokuments, kann ein XML-Dokument aus dem Schema
instantiiert werden. Folgendes Beispiel stellt ein solches Dokument dar:
Seite 19
Web-Services zur Datenintegration mobiler Endgeräte
<?xml version="1.0"?>
<prüfung datum="2003-01-01" uhrzeit="15:30:00.000">
<prüfer>
<vorname>Jens</vorname>
<name>Mustermann</name>
</prüfer>
<prüfling>
<vorname>Anna</vorname>
<name>Musterfrau</name>
<matrikelnummer>555555</matrikelnummer>
</prüfling>
<beisitzer>
<vorname>Torsten</vorname>
<name>Mustermann</name>
</beisitzer>
<vorlesung>Datenbanken I</vorlesung>
<vorlesung>Datenbanken II</vorlesung>
</prüfung>
Beispiel 7: XML-Dokument abgeleitet von einem XML Schema
Detaillierte Beschreibungen aller möglichen Beziehungen und Typen können folgenden Referenzen
entnommen werden: [BaEb01], [BaEb01], [BaEb01].
2.2.4
HTTP
Die vorliegenden XML-Dateien, die die Daten enthalten, werden über einen Web-Server angeboten.
Eine Middleware kann anschließend unter Verwendung von HTTP die entsprechenden Dateien
abholen. HTTP selbst wird in dieser Arbeit nicht vertieft, es soll lediglich angeführt werden, dass die
Kommunikation im Rahmen dieses Ansatzes auf HTTP basiert. Weiterführende Inhalte können
folgender Referenz entnommen werden: [Nwg97].
2.3 Web-Services
2.3.1
Einführung
Das Internet hat sich in den letzten Jahren wie kaum eine andere Technologie verbreitet und
entwickelt. Große Bedeutung wurde und wird vor allem der Entwicklung von Netzanwendungen zuteil
werden. Diese Entwicklung wurde durch die Einführung von Web-Services noch einmal stark
verändert. Bisher waren Anwendungen, die für das Internet entwickelt wurden, browserbasiert.
Dienste wurden also fast immer dem Browser zur Verfügung gestellt, der für die Ausführung
verantwortlich war. Dieser Anwendungstypus, obwohl bereits sehr leistungsstark, weist natürlich
einen entscheidenden Nachteil auf: Das konsumierende Element muss zwangsläufig eine spezifische
Anwendung (hier der Browser) sein. Web-Services bieten in diesem Zusammenhang eine völlig neue
Seite 20
Web-Services zur Datenintegration mobiler Endgeräte
Art und Weise der Erstellung von Anwendungen, die in einer verteilten Umgebung wie dem Internet
ablaufen. Es ist einer Anwendung möglich, Dienste in Form von Operationen nach außen hin zur
Verfügung zu stellen. Der bisher einschränkende Faktor ist somit eliminiert und es ist ab sofort jeder
Anwendung möglich Dienste zur Verfügung zu stellen und einen Dienst zu konsumieren. Besonderes
Augenmerk sollte in diesem Zusammenhang auch den Plattformen zuteil kommen, die Dienste
konsumieren. Die Vorstellungen seitens Industrie und Entwicklern reicht von der "üblichen" Plattform
PC über das Handy und neuere Plattformen wie etwa PDAs.
Zu erwähnen bleibt, dass es natürlich nicht möglich ist, jeder (vorhandenen oder zu erstellenden)
Anwendung ohne Erweiterungen die Möglichkeit zu bieten Dienste anzubieten oder zu konsumieren.
Diese Funktionalität wird erst durch die Implementierungen der Web-Services möglich. Im Folgenden
wird näher auf die Technologie der Web-Services eingegangen.
2.3.2 Anforderungen
Ein Web-Service muss allgemein betrachtet einige Anforderungen erfüllen, er muss eine gewisse
Funktionalität bereitstellen.
2.3.2.1 Beschreibung der Daten
Eine Kommunikation zwischen heterogenen Plattformen kann nur über eine einheitliche Beschreibung
der nötigen Parameter etc. ermöglicht werden. In diesem Bereich nutzen Web-Services eine
Technologie aus, die in den letzten Jahren einen enormen Zuwachs erfahren hat: XML. Im vorherigen
Kapitel wurde schon näher auf XML eingegangen, hier wird der Nutzen der XML für die WebServices erläutert. XML ermöglicht es, Daten in einer Form zu beschreiben, die sowohl gut lesbar für
den Menschen, aber ebenso gut durch Programme interpretierbar und verarbeitbar ist. Dieser Aspekt
lässt XML allgemein ein großes Interesse zuteil werden, bietet aber auch einen großen Vorteil für die
Web-Services. XML wird im Rahmen der Web-Service-Spezifikation als Beschreibungssprache für
die zugrunde liegenden Technologien eingesetzt. Somit ist eine Plattformunabhängigkeit hinsichtlich
der Beschreibungssprache gewährleistet. Diese Unabhängigkeit der Beschreibungssprache ist eine
Voraussetzung für die Plattformunabhängikeit der drei Technologien, die im Folgenden vorgestellt
werden und deren Zusammenschluss dann einen Web-Service definiert.
2.3.2.2 Funktionalität des Web-Services
Es ist nötig, die durch einen Web-Service angebotene Funktionalität in einer für Mensch und
Maschine verständlichen Art und Weise zu beschreiben. Die Art und Weise des Aufrufs, etwa
übergebende Parameter und die zu erwartende Rückgabe, muss klar beschrieben sein. Es muss also
zum einen dem Anbieter möglich sein seinen Dienst zu beschreiben, um so zum anderen seitens des
Konsumenten das Verständnis des Dienstes zu ermöglichen. Zu diesem Zweck wurde die WebService Description Language (WSDL) entwickelt, eine einheitliche Sprache zur Beschreibung von
Web-Services. Die WSDL basiert auf XML, d.h. die Notation der WSDL ist XML.
Seite 21
Web-Services zur Datenintegration mobiler Endgeräte
Ein WSDL-Dokument enthält allgemein folgende Elemente:
< definitions>
< im port>
< types>
< sc hem a>
< m essage>
< part>
< PortType>
< input>
< output>
< fault>
< binding>
< input>
< output>
< servic e>
< port>
Abbildung 1: allgemeine Struktur eines WSDL-Dokuments
Seite 22
Web-Services zur Datenintegration mobiler Endgeräte
Nachfolgend werden die einzelnen Elemente kurz erläutert und anhand von Beispielen illustriert:
<definitions>
Das definitions-Element umschließt das komplette Dokument und bietet eine zentrale
Möglichkeit Namespaces zu definieren, die innerhalb des gesamten Dokuments sichtbar sein müssen.
Ein Beispiel eines solchen definitions-Blocks sieht wie folgt aus:
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://com.test/wsdl/MyVerwaltung"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ns2="http://java.sun.com/jax-rpc-ri/internal"
name="MyVerwaltung"
targetNamespace="http://com.test/wsdl/MyVerwaltung">
...
</definitions>
Beispiel 8: definitions-Element
<import>
Das erste Unterelement des definitions-Element
kann das import-Element sein.
Vergleichbar ist das Element mit der C-Direktive include. Es ermöglicht es, ein WSDL-Dokument
über mehrere Dokumente zu verteilen um so eventuell eine bessere Übersicht zu erreichen.
<types>
Das types-Element
beschreibt die Datentypen, die in den darauf folgenden message-
Elementen benötigt werden. Viele elementare Datentypen wurden bereits durch die XMLSpezifikation bereitgestellt, so dass nur komplexe Datentypen oder eigene Typen innerhalb dieses
Bereichs definiert werden müssen.
Will man beispielsweise den aus Java bekannten komplexen Datentyp Hashtable verwenden, muss
das types-Element folgenden Eintrag enthalten:
<complexType name="hashtable">
<complexContent>
<extension base="tns:map">
<sequence />
</extension>
</complexContent>
</complexType>
<complexType name="map">
<complexContent>
<restriction base="soap-enc:Array">
<attribute ref="soap-enc:arrayType" wsdl:arrayType="tns:mapEntry[]"
/>
</restriction>
Seite 23
Web-Services zur Datenintegration mobiler Endgeräte
</complexContent>
</complexType>
<complexType name="mapEntry">
<sequence>
<element name="key" type="anyType" />
<element name="value" type="anyType" />
</sequence>
</complexType>
Beispiel 9: types-Element
<message>
Das message-Element beschreibt alle Nachrichten, die für eine Kommunikation zwischen WebService-Endpunkt und Benutzer nötig sind. Es handelt sich dabei sowohl um zu sendende Nachrichten
als auch um zu empfangende Nachrichten.
Soll die folgende Methode am Web-Service-Endpunkt bereitgestellt werden,
Hashtable getType(String type),
müssen folgende message-Einträge vorhanden sein:
<message name="VerwaltungIF_getType">
<part name="String_1" type="xsd:string" />
</message>
<message name="VerwaltungIF_getTypeResponse">
<part name="result" type="ns2:hashtable" />
</message>
Beispiel 10: Beispiel-Einträge für message-Elemente
Anzumerken ist, dass der Eintrag VerwaltungID_getTypeResponse nicht notwendigerweise in
dieser Form angeführt werden muss, es stellt lediglich eine Vereinbarung zur besseren Lesbarkeit dar.
<PortType>
Nach dem alle nötigen Nachrichten beschrieben wurden, werden diese Elemente nun innerhalb des
Porttype-Elements referenziert, um so alle Operationen, die am Web-Service-Endpunkt
verfügbar sein sollen, zu beschreiben.
Für obiges Beispiel müsste innerhalb des Porttype-Elements folgender Eintrag vorhanden sein:
<portType name="VerwaltungIF">
<operation name="getType" parameterOrder="String_1">
<input message="tns:VerwaltungIF_getType" />
<output message="tns:VerwaltungIF_getTypeResponse" />
</operation>
...
</portType>
Beispiel 11: PortType-Element
Seite 24
Web-Services zur Datenintegration mobiler Endgeräte
Die Anordnung der ouput- und input-Elemente gibt den Typ der Kommunikation an, der durch
diese Methode realisiert wurde.
Folgende Tabelle beschreibt alle möglichen Typen:
Elemente und deren
Anordnung
input output
output input
Beschreibung
Benutzer sendet Nachricht und empfängt anschließend Nachricht
des Web-Service-Endpunkts
Web-Service-Endpunkt sendet Nachricht und wartet auf Antwort
des Benutzers
input
Benutzer sendet Nachricht an Web-Service Endpunkt
output
Benutzer empfängt Nachricht vom Web-Service Endpunkt
Tabelle 1: mögliche Nachrichtenkommunikation innerhalb des <PortType> Elements
<binding>
Zu jedem PortType-Element existiert ein binding-Element, das ein konkretes Protokoll
definiert.
Auch wird zu jedem operation-Element
des Porttype-Elements
binding-Elements ebenfalls ein operation-Element
innerhalb des
angegeben, das das für die
entsprechende Operation zu verwendende Protokoll definiert.
Zu obigem Beispiel sieht das binding-Element wie folgt aus:
<binding name="VerwaltungIFBinding" type="tns:VerwaltungIF">
<operation name="getType">
<input>
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
use="encoded" namespace="http://com.test/wsdl/MyVerwaltung" />
</input>
<output>
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
use="encoded" namespace="http://com.test/wsdl/MyVerwaltung" />
</output>
<soap:operation soapAction="" />
</operation>
...
</binding>
Beispiel 12: binding-Element
Dieses Beispiel zeigt, dass das zu verwendende Protokoll für die Nachrichtenkommunikation SOAP
(Simple Object Access Protocol) ist.
Des Weiteren ist es möglich, ein soap:binding-Element einzufügen, welches den Typ der
SOAP-Kommunikation festlegt.
Seite 25
Web-Services zur Datenintegration mobiler Endgeräte
In folgendem Beispiel wird die SOAP-Kommunikation im Rahmen von Remote Procedure Calls
(RPC) durchgeführt:
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="rpc" />
<service>
Das letzte Element der WSDL-Beschreibung gibt zu dem entsprechenden Port an, an welcher URL
sich der Web-Service-Endpunkt befindet und erreichbar ist.
<service name="MyVerwaltung">
<port name="VerwaltungIFPort" binding="tns:VerwaltungIFBinding">
<soap:address xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
location="http://localhost:8080/middleware/Verwaltung" />
</port>
</service>
Beispiel 13: service-Element
Die WSDL bietet nur die Möglichkeit den Dienst zu beschreiben. In beiden oben erwähnten Fällen ist
es nötig, mit der Außenwelt zu kommunizieren, um Informationen über einen Dienst zu suchen oder
bereitzustellen. Dies kann mittels unterschiedlicher Protokolle erfolgen. Das World Wide Web
Consortium (W3C) geht in seiner WSDL-Spezifikation explizit auf drei Protokolle ein: SOAP, HTTP
und MIME. [ChCu01]. In dieser Arbeit wird die erste Variante, also eine Nutzung der WSDL unter
Verwendung von SOAP erläutert, da SOAP immer mehr zum Standardprotokoll in diesem Bereich
avanciert, andere Varianten können der Literatur entnommen werden. SOAP wird in einem der
folgenden Abschnitte näher beschrieben.
Nachdem mittels WSDL eine Möglichkeit zur Beschreibung eines Dienstes vorgestellt worden ist,
konzentriert sich der folgende Abschnitt auf die Suche und das Anbieten eines Dienstes. Es muss
einem Konsumenten möglich sein, einen für ihn geeigneten Dienst zu suchen und dem Anbieter
entsprechend einen Dienst zur Verfügung zu stellen. In diesem Bereich werden zurzeit hauptsächlich
folgende zwei Technologien verwendet:
UDDI (Universal Description, Discovery and Integration) und
ebXML (electronic business XML).
Es handelt sich bei beiden um so genannte XML-basierte Registries, welche zum einen die
Möglichkeit bieten einen Dienst zu registrieren, zum anderen es Clients erlauben, Dienste zu finden
und dann entsprechend zu nutzen. Das Hauptaugenmerk soll nun sich auf UDDI liegen, deren
Verbreitung größer ist als die der ebXML; nachfolgend werden aber beide Techniken beschrieben.
Folgende Referenz enthält weitere Informationen zu WSDL: [ChJe02].
Seite 26
Web-Services zur Datenintegration mobiler Endgeräte
UDDI
Bei UDDI handelt es sich um eine Registry, welche es Anbietern von Web-Diensten ermöglicht ihren
Web-Dienst zu registrieren.
Die Registrierung wird mittels XML durchgeführt, wobei das XML-Dokument einem gewissen, durch
UDDI vorgegebenen Schema entsprechen muss, wie in folgender Struktur angegeben wird:
businessEntity
businessServices
businessService
bindingTemplates
bindingTemplate
tModel
Abbildung 2: Struktur eines UDDI Dokuments
Das oberste Element ist das businessEntity-Element, es beschreibt das entsprechende
Unternehmen über verschiedene Attribute. Ein businessEntity-Element enthält ein
businessServices-Element, das die verschiedenen angebotenen Dienste in Form von
businessService-Elementen einschließt. Ein businessServices-Element kann also
mehrere businessService-Elemente enthalten, je nach Anzahl der von der Unternehmung
bereitgestellten
Webdienste.
Innerhalb
bindingTemplates-Element
der
businessService-Elemente
wird
ein
angegeben, das mehrere bindingTemplate-Elemente
zusammenfassen kann. Ein bindingTemplate Element gibt einer Anwendung die nötigen
Informationen, um eine Verbindung und den Zugriff auf einen Webdienst zu ermöglichen.
Seite 27
Web-Services zur Datenintegration mobiler Endgeräte
Weitere einen Webdienst betreffende Informationen können mittels des so genannten tModelElements beschrieben werden. Allgemein bietet dieses Element die Möglichkeit, Informationen
über den Dienst betreffende Spezifikationen anzugeben.
Es ist in diesem Zusammenhang leider nicht möglich, ein vollständiges Beispiel einer UDDIRegistrierungsbeschreibung anzugeben, da diese sich bereits für kleine Dienste über mehrere Seiten
erstrecken, folgende Referenz aber enthält entsprechende Beispiele: [Cha02].
ebXML
Bei ebXML handelt es sich um ein B2B1-Initiative. Durch die Verwendung von ebXML sollen ein
Unternehmen betreffende Informationen zum einen veröffentlichen werden können, zu anderen soll
aber auch der Zugriff auf diese Informationen möglich sein.
ebXML bietet das Beschreiben von Informationen über zwei Elemente an:
Collaboration-Protocol Profile (CPP) und
Collaboration-Protocol Agreement (CPA).
Beide Elemente sind XML-Dokumente, beschreiben jedoch unterschiedliche Aspekte. Das CPP
beschreibt ein Unternehmen und dessen Informationsaustausch mit anderen Unternehmen betreffende
Informationen. Das CPA beschreibt Informationen, die für eine Zusammenarbeit zweier Unternehmen
relevant sind.
Ein CPA wird von einem Unternehmen erstellt, falls mittels der CPP ein zweites Unternehmen
innerhalb einer Registry gefunden wurde, mit dem eine Zusammenarbeit stattfinden soll. Diese CPA
wird dann dem entsprechenden Unternehmen übermittelt, um so eine Einigung bezüglich der
Zusammenarbeit an beiden Eckpunkten zu ermöglichen. Folgende Literaturverweise enthalten
detaillierte Informationen zu ebXML: [Ebx02], [Qua02].
Alle vorherigen Technologien (UDDI und ebXML) benötigen im Rahmen des Web-Service-Ansatzes
eine Möglichkeit zur Kommunikation. Die Web-Service-Spezifikation schlägt hier den Einsatz des
oben erwähnten SOAP-Protokolls vor.
2.3.2.3 Kommunikation
Die im Rahmen von Web-Services nötige Kommunikation ist vielseitig. Zu erwähnen sind einerseits
die Kommunikation zwischen Client und Registry, Server und Registry und natürlich als zentrales
Element die Kommunikation zwischen Client und Anbieter. Die Kommunikation ist zum einen
notwendig, um eine Suche nach geeigneten Web-Services durchführen zu können, zum anderen aber
auch um den eigentlichen Aufruf des Web-Services (Anfrage seitens des Client und Antwort des
1
Business to Business
Seite 28
Web-Services zur Datenintegration mobiler Endgeräte
Servers) durchführen zu können. Diese Kommunikation wird in den meisten Fällen durch SOAP
realisiert. SOAP basiert ebenso wie die WSDL auch auf XML. Ein SOAP-Aufruf wird in XML
abgewickelt, die anschließende Übertragung der XML-Dateien kann dann mittels unterschiedlicher
Transportprotokolle erfolgen. Gängige SOAP-Architekturen verwenden aber das HTTP Protokoll zum
Transport, da dieses eine sehr weite Verbreitung vorweisen kann. Die W3C-Spezifikation aber weist
seit der Version 1.1 der SOAP-Spezifikation [GuHe02] darauf hin, dass nicht wie noch in Version 1.0
nur HTTP unterstützt wird, sondern weitere Transportprotokolle, die den Anforderungen des
Rahmenwerks entsprechen, möglich sind. In dieser Arbeit wird aber das Augenmerk auf dem HTTP
orientierten SOAP-Protokoll liegen, somit basiert SOAP auf zwei äußerst verbreiteten internationalen
Standards XML und HTTP. Diese Basis ist es auch, die SOAP Vorteile im Gegensatz zu anderen
Ansätzen (etwa den Remote Procedure Calls) verschafft.
Die Anforderungen für einen serverseitigen Einsatz von SOAP sind minimal:
XML-Parser und Interpretation und
HTTP-Pakete senden und empfangen.
Zum einen ist natürlich ein HTTP-Server erforderlich, der eine Anfrage empfangen kann. In einem
zweiten Schritt muss diese Anfrage mittels eines XML-Parsers interpretiert werden können, um so
anschließend die benötigte Operation (also den Dienst) auszuführen und die entsprechende Antwort zu
generieren und zurückzusenden.
Im nächsten Abschnitt wird der Aufbau eines SOAP-Pakets erläutert, wobei HTTP als
Transportprotokoll verwendet wird dabei.
SOAP
Eine SOAP-Nachricht besteht aus folgenden Teilen:
SOAP Envelope (erforderlich),
SOAP Header (optional) und
SOAP Body (erforderlich).
Diese drei Elemente werden dabei in einem XML-Dokument wie folgt geschachtelt:
Seite 29
Web-Services zur Datenintegration mobiler Endgeräte
SOAP Enveloppe
SOAP Header
SOAP Body
Abbildung 3: SOAP Nachricht
Die SOAP Envelope ist der erste Teil des XML-Dokumentes; angegeben wird hier die
Versionsnummer des Envelope-Elements in Form eines URI. Eine fehlerhafte Version sollte
eine Fehlermeldung seitens des Servers verursachen. Des Weiteren besteht die Möglichkeit, über
Schemata eigene Datentypen zu spezifizieren, die im Body-Element verwendet werden können.
Die SOAP Envelope kann dann als nächstes Element den optionalen Header enthalten Der
Header dient dazu die Nachricht zu erweitern. Denkbar wären hier Aspekte wie etwa
Authentifizierung, Zahlungsmechanismen, etc.
Der Envelope folgt schließlich das Body-Element, das wieder erforderlich ist. In diesem Element ist
die für den Client eigentlich relevanten Information, also die Anfrage an den Server enthalten, man
spricht hier auch von der so genannten XML-Nutzlast.
Um diese Erläuterungen anschaulich zu gestalten, werden im Folgenden eine Anfrage und eine
Rückmeldung über HTTP dargestellt. In den beiden Beispielen werden jeweils auch SOAP
Nachrichten exemplarisch dargestellt.
Seite 30
Web-Services zur Datenintegration mobiler Endgeräte
POST /Fussballergenis HTTP/1.1
Host: www.fussballergebnis.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xx
SOAPAction: "URI-Referenz"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetErgebnis xmlns:m="URI-Referenz">
<Spieltag>34</Spieltag>
<Paarung>1</Paarung>
</m:GetErgebnis>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Beispiel 14: SOAP HTTP-Anfrage
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: xx
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetErgebnis xmlns:m="URI-Referenz">
<Ergebnis>2-1</Ergebnis>
</m:GetErgebnis>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Beispiel 15: SOAP HTTP-Rückmeldung
HTTP- Erläuterungen
Das obige Beispiel demonstriert den Einsatz des HTTP-Protokolls zum Transport einer SOAP
Nachricht. Da dies ein zentraler und wichtiger Vorgang des SOAP Ansatzes ist wird hier kurz auf die
Struktur eines HTTP-Headers, wie er in beiden Beispielen jeweils über der SOAP Nachricht zu finden
ist, eingegangen. Tiefergehende Informationen können folgender Referenz entnommen werden
[Nwg97].
Die Beispiele Beispiel 14 und Beispiel 15 zeigen den HTTP-Anfrage- sowie den HTTP-AntwortHeader.
Der HTTP-Anfrage-Header besteht aus der Methode die bei Senden der Nachricht verwendet wird
(bei SOAP ist hier POST vorgesehen), dann der URI (hier /Fussballergebnis) sowie der
eingesetzten Version des Protokolls (hier HTTP/1.1). Dann folgen weitere Informationen, die die zu
sendende Nachricht betreffen. Zu erwähnen ist, dass das Content-Type-Feld bei SOAP-Nachrichten
text/xml sein muss. Ein weiteres Element, um das der HTTP-Header bei SOAP-Anfragen ergänzt
Seite 31
Web-Services zur Datenintegration mobiler Endgeräte
wurde ist SOAPAction. Dieses Element enthält Informationen über die SOAP-Anfrage. Das
SOAPAction-Feld ermöglicht so beispielsweise einer Firewall eine Sicherheitsprüfung, ohne den
Inhalt der Anfrage verarbeiten zu müssen. Es kann bereits aufgrund dieses Feldes entschieden werden
ob eine bestimmte Anfrage abgelehnt wird.
Die Rückmeldung gibt dann Auskunft über den Status der gestellten Anfrage. Es werden die vom
Server unterstützte HTTP-Version, ein Statuscode (dreistellige Zahlenkombination) sowie ein
Statustext, der den Statuscode anschaulich wiedergibt ausgegeben. Im Beispiel wird der Code 200 OK
geliefert; er gibt an, dass die Nachricht von Server verarbeitet werden konnte. Aus dem Status des
HTTP-Headers kann man nicht schließen ob die SOAP-Anfrage korrekt verarbeiten werden konnte, er
gibt nur Aufschluss über die Abarbeitung der eigentlichen HTTP-Anfrage.
Die Abfrage der SOAP-Verarbeitung ist aber auch möglich; SOAP bietet hier das SOAP-FaultElement an mittels welchem Fehler- und Statusinformationen weitergereicht werden können. Das
Fault Element wird dabei innerhalb des Body Elements angegeben und besteht aus vier Elementen:
faultcode,
faultstring,
faultactor und
detail.
Der faultcode gibt eine Klassifikation des Fehlers an und ist vor allem zur maschinenbasierten
Verarbeitung gedacht. Im Gegensatz dazu gibt der faultstring eine Beschreibung des Fehlers in
lesbarer Form an. Der faultactor dient dazu, den Verantwortlichen für den Fehler angeben zu können.
Das detail-Feld ist speziell für Fehler innerhalb des Body-Elements gedacht und darf nur für dieses
verwendet werden. Bezieht sich der Fehler beim Verarbeiten des Dokumentes nicht auf das BodyElement, so wird das detail-Element weggelassen.
2.4 JINI
2.4.1
Einführung
Eine weitere Technologie zur Bereitstellung von Diensten in einem Netzwerk stellt JINI dar. Das Ziel
von JINI wird in der Literatur oft beispielhaft erläutert: [OaWo00]. Ein Beispiel ist dabei sehr häufig
zu finden, das auch in dieser Arbeit verwendet wird, da es das Ziel von JINI anschaulich beschreibt.
Man kauft sich einen neuen Drucker. Der Drucker wird angeschlossen, dann angeschaltet und das
Display zeigt den Status "BEREIT" an. Anschließend öffnet man ein Textverarbeitungsprogramm,
schreibt einige Zeilen, öffnet das Druckmenü, in dem der neue Drucker schon zur Auswahl steht und
Seite 32
Web-Services zur Datenintegration mobiler Endgeräte
druckt das vorhandene Dokument ohne Probleme aus. Dem Benutzer steht also ab sofort ein neuer
Dienst in Form des Druckers zur Verfügung, ohne dass ein Eingreifen seinerseits nötig war.
Ein zentraler Aspekt der JINI-Spezifikation ist der eines Dienstes. Ein Dienst ist laut JINISpezifikation [SunJa01] eine Einheit, die von einer Person, einer Anwendung oder einem anderen
Dienst benutzt werden kann. Obiges Beispiel stellt den Druckdienst zur Verfügung.
Das Konzept von JINI beruht darauf, verschiedene Komponenten (Software, Hardware) zu einem
verteilten "dynamischen" System zusammenzuschließen. Im Folgenden werden nun die Elemente
vorgestellt, die es ermöglichen diesen Zusammenschluss zu vollziehen, dabei wird vor allem auf den
Aspekt des "dynamischen" Systems eingegangen, das ein zentrales Element der JINI-Architektur
darstellt.
2.4.2 Komponenten
Ein JINI-System besteht im Allgemeinen aus 3 Komponenten:
Client,
Service und
Lookup-Service.
Diese drei Komponenten sind über ein Netzwerk miteinander verbunden, um so eine Kommunikation
und ein Zusammenspiel zu ermöglichen. Der Lookup-Service dient als Vermittler zwischen dem
Client der einen Service nutzen will und dem eigentlichen Dienst.
Lookup-Service
Der JINI-Lookup-Service ist dabei eine zentrale Komponente innerhalb der JINI-Architektur, da sehr
viele Anfragen über diesen Dienst abgewickelt werden. Alle Dienste, die verfügbar sein sollen,
müssen sich im Lookup-Service registrieren. Analog dazu werden benötigte Dienste über den LookupService seitens der Clients erfragt und ihnen dann zur Verfügung gestellt.
Die Architektur von JINI sieht einige Vorgänge vor, die die oben genannten drei Komponenten so in
Beziehung stellt, dass das Konzept des "dynamischen" Systems zustande kommt:
Lookup-Service finden,
Registrieren eines Dienstes im Lookup-Service und
Nutzen eines Dienstes über den Lookup-Service.
Seite 33
Web-Services zur Datenintegration mobiler Endgeräte
2.4.3
JINI Dienste
Ein neuer Dienst, der erstellt wurde und in ein bestehendes System integriert werden soll, muss sich
beim Lookup-Service anmelden, um den restlichen Teilnehmern des Systems zur Verfügung zu
stehen. Bevor nun aber diese Anmeldung erfolgen kann, muss der Lookup-Service gefunden werden.
JINI stellt zu diesem Zweck einen Discovery-Prozess zur Verfügung, der es ermöglicht den LookupService zu finden.
Es gibt zwei mögliche Vorgehensweisen um den Lookup-Service zu lokalisieren:
Multicast-Discovery
Hierbei wird eine Multicast-Abfrage im Netzwerk abgesendet, die von allen Lookup-Services
beantwortet werden kann, die diese Abfrage empfangen.
Unicast-Discovery
Diese Variante setzt voraus, dass die Existenz eines Lookup-Services an einem gewissen Ort bekannt
ist, zu dem dann eine Verbindung hergestellt werden kann.
Nachdem der Lookup-Service ermittelt worden ist, ist es nun möglich den entsprechenden Dienst zu
registrieren. Ein Client kann nun über den Lookup-Service auf den entsprechenden Dienst zugreifen.
Einer der zentralen Aspekte der JINI-Architektur ist die Bereitstellung eines dynamischen Systems.
Dynamisch wird das System unter Verwendung so genannter Leases. Ein Lease ist eine temporäre
Erlaubnis, die einem Dienst vom jeweiligen Lookup-Service ausgestellt wird, um am bestehenden
System teilzunehmen. Der Lease muss in regelmäßigen Abständen vom Client erneuert werden; wird
die Erlaubnis innerhalb dieser Zeitspanne nicht erneuert, wird der entsprechende Dienst vom LookupService entfernt. Um das Beispiel des Druckers erneut aufzugreifen, könnte es passieren, dass der
Drucker defekt ist und seinen Dienst nicht mehr bereitstellen kann, er kann somit seinen Lease nicht
mehr erneuern und wird entfernt. Es kann also kein Zugriff mehr erfolgen. Ist der Drucker dann
wieder einsatzbereit, registriert er sich wieder bei dem entsprechenden Lookup-Service, so dass der
Dienst ab diesem Zeitpunkt wieder zur Verfügung steht. Diese Dynamik ist einer der Hauptaspekte der
JINI-Architektur.
2.4.4
Voraussetzungen
Die Komponenten der JINI-Architektur stehen über ein Netzwerk miteinander in Verbindung, da wie
erwähnt mittels JINI ein verteiltes System entsteht. JINI abstrahiert vom verwendeten Netz, so dass
hier (zumindest theoretisch) jede mögliche Architektur denkbar wäre.
Eine weitere Voraussetzung für den Betrieb von JINI ist Java. Eine Java Virtual Machine (JVM) ist
erforderlich, um die angebotenen Dienste ausführen zu können. Es ist aber möglich, einen Dienst auf
Seite 34
Web-Services zur Datenintegration mobiler Endgeräte
einem Gerät anzubieten, auf dem selbst keine JVM läuft. So ist es denkbar, JINI in vielfältigen
Umgebungen zu betreiben. Die JVM bleibt aber auch in diesem Fall eine Voraussetzung, nur dass sie
als Proxy auf einem Rechner ausgeführt werden kann, der die notwendige Unterstützung bereitstellt.
Eine dritte Vorraussetzung schwächt das einführende Beispiel in punkto Dynamik von JINI etwas ab.
Vorab wird ein weiteres Element eingeführt, das in diesem Zusammenhang von Bedeutung ist. Wie
bereits oben erwähnt wurde, ist ein Dienst eine Einheit die von einer Person, einer Anwendung oder
einem anderen Dienst benutzt werden kann. In JINI wird noch ein weiteres Element betrachtet, auf das
bisher noch nicht eingegangen wurde, das Interface. Bisher wurde immer behauptet: Ein Rechner
bietet einen Dienst an. Dies ist eine sehr abstrakte Betrachtung, denn eigentlich bietet der Rechner ein
Interface, also eine Schnittstelle nach außen hin an, die benutzt werden kann. Die Schnittstelle ist
letztendlich die Implementierung des abstrakten Objekts Dienst. Ein Client, der einen Dienst in
Anspruch nehmen will, muss das entsprechende Interface kennen. Diese Anforderung schwächt
natürlich einen Hauptaspekt von JINI etwas ab, denn in obigem Beispiel kann der Drucker zwar dem
Netzwerk beitreten, kann aber erst vom Textverarbeitungsprogramm genutzt werden, wenn dies die
nötigen Methoden kennt.
2.5 .NET
(gesprochen DOT NET)
Eine mögliche Plattform zur Implementierung und Verwendung von Web-Services stellt Microsofts
.NET-Ansatz dar.
Microsoft beschreibt .NET als "neuartige Plattform, die das Entwickeln von Anwendungen in der
verteilten
Umgebung
des
Internet
wesentlich
vereinfacht".
Microsoft
will
das
Internet
"programmierbar machen". Es wird davon ausgegangen, dass der Entwickler von Anwendungen ein
gewisse Einarbeitungszeit benötigt, um sich den neuen Gegebenheiten der .NET-Plattform anzupassen
und diese zu erlernen. Nach dieser Einarbeitungszeit aber soll die Produktivität hinsichtlich der
Entwicklung von Anwendungen auf der neuen Plattform im Gegensatz zur vorherigen (WindowsPlattform oder ähnlichen) um ein Wesentliches gesteigert werden können. Besonderen Wert wird in
diesem Bereich auf Web-Services gelegt, so soll der erwähnte Aspekt der Programmierbarkeit durch
Web-Services geschaffen werden. Microsoft will die Art und Weise der Erstellung und Nutzung von
Anwendungen verändern. Der Weg soll weg von Einzelplatzanwendungen, aber auch weg von
heutigen browsergestützten Anwendungen (die ein zu geringes Maß an Potenzial bergen) hin zu
servicegestützten Anwendungen. Dienste sollen, wie in Kapitel 2.2 beschrieben, angeboten und von
Anwendungen konsumiert werden können. Eine Unterstützung der sehr weit verbreiteten
Einzelplatzanwendungen ist aber ebenso vorgesehen, so dass alle möglichen Projekte, sowohl
existierende als auch zukünftige im Rahmen der neuen Plattform entwickelt werden können. Der
Unterschied zur bisherigen Entwicklung bildet das neu geschaffene .NET-Framework, das einen völlig
neuartigen Rahmen für die Entwicklung einer Anwendung schafft. Neben diesem Rahmen wurde als
Seite 35
Web-Services zur Datenintegration mobiler Endgeräte
weiterer Hauptbestandteil von .NET eine neue Version der Visual Studio-Reihe entwickelt, Visual
Studio .NET. Visual Studio stellt ein Werkzeug mit einer graphische Entwicklungsoberfläche zur
Erstellung von Anwendungen bereit. Im Folgenden wird nun im Detail auf die Neuerungen der
Plattform eingegangen, dabei werden vorab die Produkte von .NET vorgestellt, bevor dann auf die
Unterstützung der .NET-Plattform zur Erstellung von Web-Services eingegangen wird.
Die .NET-Plattform besteht aus mehreren Produkten; zwei essentielle Bestandteile davon sind:
.NET-Framework und
Visual Studio .NET.
2.5.1
.NET-Framework
Das .NET-Framework besteht aus zwei Hauptkomponenten, der Common Language Runtime (CLR)
und der .NET-Framework class library.
2.5.1.1 Common Language Runtime
Die CLR wird als Fundament des .NET-Frameworks verstanden. Alle Anwendungen der .NETPlattform (inklusive der .NET-Framework class library) bauen auf der CLR auf. Es werden Aspekte
wie
Speicherverwaltung,
Thread-Ausführung,
Code-Ausführung Kompilierung und
weitere
Systemdienste, darunter auch die automatische Speicherbereinigung in Form einer Garbage Collection
von der CLR übernommen.
Die CLR bildet dabei die Basis aller Programmiersprachen der .NET Plattform. Dies ist eine der
zentralen Neuerungen der Microsoft-Initiative. Es wird somit möglich, unabhängig von Performanceoder Funktionalitätsaspekten eine Programmiersprache zur Entwicklung einer Anwendung
auszuwählen. Es ist dem Entwickler völlig frei gestellt, welche Programmiersprache er wählt, er kann
seine bevorzugte Programmiersprache verwenden ohne dabei Einbußen in punkto Leistung oder
Funktionalität machen zu müssen, wie das auf früheren Windows-Plattformen der Fall war.
Microsofts Ansatz wird durch eine neue Art und Weise der Bereitstellungsphase einer Anwendung
umgesetzt. Bisher wurden Anwendungen kompiliert, um dann eine ausführbare Code-Komponente zu
liefern, die auf einem Zielsystem ausgeführt wird. Nun wird der Code unabhängig von der
verwendeten Programmiersprache in eine so genannte Microsoft Intermediate Language (MSIL)
übersetzt und dann an den Client ausgeliefert. Der Code wird, wie dies bisher auch der Fall war, vor
der Ausführung in Maschinencode umgesetzt. Der Unterschied aber liegt darin, dass nicht der
Entwickler diesen Vorgang anstößt, sondern der Anwender. Zwei mögliche Alternativen werden
bereitgestellt, die Kompilierung kann bei Installation der Anwendung oder aber vor jeder Ausführung
(Just-in-time, JIT) erfolgen.
Seite 36
Web-Services zur Datenintegration mobiler Endgeräte
Weitere Informationen und detaillierte Beschreibungen der CLR können folgenden Referenzen
entnommen werden [Wes02], [Cha02], [Mic02].
2.5.1.2 .NET-Framework class library
Neben der CLR bietet das .NET-Framework eine weitere Komponente, die von jeder
Programmiersprache aus benutzt werden kann: die .NET-Framework class library. Es handelt sich
hierbei um eine Reihe von Klassen, auf die jede Anwendung zugreifen kann. Einige Dienste, die
innerhalb der Klassenbibliothek angeboten werden, sind:
ASP.NET und
ADO.NET.
Beide Dienste werden in einem der folgenden Abschnitte erläutert.
Ein Vorteil der .NET-Plattform im Gegensatz zur vorherigen Windows-Entwicklungsplattform liegt in
der Art und Weise des Zugriffs auf diese Bibliothek. Alle Programmiersprachen können in einer
einheitlichen Weise auf die Dienste zuzugreifen. In früheren Windows-Umgebungen war dies oft nicht
der Fall, es gab eine Vielzahl unterschiedlichster Zugriffe über Schnittstellen auf Dienste des
Betriebssystems. Viele Programmiersprachen definierten ihren eigenen Zugriff auf einen gewissen
Dienst, so entstanden im Laufe der Zeit eine Vielzahl von Schnittstellen, die sich meist auch noch in
Performance und gebotener Funktionalität unterschieden, so dass es sehr schwierig wurde, sich auf der
einen Seite das nötige Wissen anzueignen, auf der anderen Seite diese Schnittstellen zu warten. Diese
Problematik löst Microsoft nun mit der Klassenbibliothek, die einen objektorientierten Zugriff auf alle
möglichen Betriebssystemdienste ermöglicht. Programmiersprachen sind so nicht nur auf einer
gemeinsamen Basis aufgebaut, sondern greifen auch in derselben Art und Weise über eine einheitliche
Schnittstelle auf Dienste der Plattform zu.
Im Folgenden werden nun einige der Bereiche der .NET-Framework class library eingeführt und kurz
erläutert, um die grundsätzlichen Möglichkeiten darzulegen, die diese Bibliothek dem Entwickler
bietet. Auf den größten Teil der angebotenen Funktionalität kann jedoch kein Bezug genommen
werden, da dies den Rahmen dieser Arbeit sprengen würde. Der gesamte Umfang der Funktionalität
dieser Bibliothek kann unter [Mic02] eingesehen werden.
Eingeteilt ist die Klassenbibliothek in so genannte Namespaces. Ein Namespace kann Klassen oder
Schnittstellen sowie wiederum Namespaces enthalten. Vergleichbar ist eine Namespace mit Paketen in
der Java-Welt. Im Folgenden werden beispielhaft einige Namespaces erläutert. Es ist für einen
Entwickler relativ unsinnig, sich die Gesamtheit dieser Bibliothek anzueignen; er sollte möglichst
einige elementare Namespaces kennen und sich alle weiteren Pakete bei Bedarf aneignen. Einige
dieser elementaren Namespaces werden kurz vorgestellt.
Das Wurzelelement der Klassenbibliothek ist der System-Namespace.
Seite 37
Web-Services zur Datenintegration mobiler Endgeräte
Das Element enthält dabei weitere untergeordnete Namespaces, die aufgrund des Umfangs der
Bibliothek in dieser Arbeit nicht alle erläutert werden können, verwiesen wird zu diesem Zweck auf
folgende Referenzen: [Cha02],[Mic02].
Einige Namespaces, die auch für den weiteren Verlauf der Arbeit von Interesse sind, werden im
Anschluss erklärt, dies sind:
System.Data und
System.Web.
2.5.1.3 System.Data (ADO.NET)
Der Namespace System.Data implementiert ADO.NET, eine neue Version der ActiveX Data Objects
(ADO), die den Zugriff auf Daten ermöglicht. Das Hauptaugenmerk liegt dabei auf dem Zugriff auf
Daten, die in einer relationalen Datenbank (Oracle, etc.) abgelegt wurden.
Der Zugriff auf Daten erfolgt in ADO.NET über Schnittstellen, einem so genannten .NETDatenprovider. Es werden aktuell drei Typen von Datenprovider zur Verfügung gestellt:
SQL,
OLE-DB und
ODBC.
Der .NET-Datenprovider für SQL ist der einzige native Datenprovider unter den zur Verfügung
gestellten. Ein nativer Datenprovider ist ein Provider, der vollständig in so genanntem verwaltetem
Code (Code, der vollständig auf dem .NET-Framework beruht) vorliegt. Durch diesen Umstand stellt
der SQL-Provider den aktuell leistungsfähigsten Zugriff auf gespeicherte Daten.
Folgende Abbildung fasst alle drei Zugriffsarten zusammen:
Seite 38
Web-Services zur Datenintegration mobiler Endgeräte
Datenprovider
Daten
SQL
SQL-Server
OLE-DB
OLE-DB
Schnittstelle
ODBC
ODBC
Schnittstelle
Nativer
verwalteter
Code
Schnittstelle
ausserhalb des
verwalteten Codes
Datenbank
Datenbank
Abbildung 4: ADO.NET-Datenprovider
Da sowohl der OLE-DB-Provider, wie auch der ODBC-Provider über ausgelagerte Schnittstellen auf
die entsprechenden Datenquellen zugreifen, wird der Zugriff (gegenüber dem Zugriff auf eine SQLDatenquelle) um einen gewissen Faktor verlangsamt.
Da jeder Datenprovider einen zum Teil unterschiedlichen Zugriff auf eine Datenquelle beschreibt und
somit unterschiedliche Objekte zum Zugriff verwendet, wird in dieser Arbeit nicht auf die
entsprechenden Klassen eingegangen, hierzu können [Mic02] und [Cha02] hinzugezogen werden.
Zu erwähnen bleibt noch, dass viele Autoren in der Art und Weise der Implementierung der
ADO.NET Version eine zum Teil strategische Entscheidung seitens Microsoft sehen, da eine
Bevorzugung des Microsoft eigenen SQL Servers entsteht. Dieser Aussage etwas entgegengesetzt
stehen Ankündigungen, wonach auch native Provider für Oracle Datenbanken und andere
Datenbanken entwickelt werden sollen.
2.5.1.4 System.Web (ASP.NET)
Der Namespace System.Web implementiert ASP.NET, den Nachfolger der Active Server Pages
(ASP). Neben der Erstellung von Browser-Anwendungen mittels System.Web.UI bietet System.Web
Seite 39
Web-Services zur Datenintegration mobiler Endgeräte
einen weiteren Namespace, System.Web.Services der zu Erstellung von Web-Services gedacht ist. Die
oben genannte erste Form der Web-Anwendungen wird nicht weiter erläutert, kann aber in [Cha02]
oder [Mic02] vertieft werden. Die zweite Form wird folgend näher erläutert.
2.5.2
Web-Services
Der Namespace System.Web.Services, der Teil von ASP.NET ist, bietet die entsprechende
Unterstützung zur Erstellung und Veröffentlichung von Web-Services.
Web-Services können im Rahmen von ASP.NET als Methoden zur Verfügung gestellt werden.
Im Folgenden werden beide Ziele der Nutzung von Web-Services erläutert, zum einen das Erstellen
und Anbieten eines Dienstes, zum anderen der Zugriff auf einen Webdienst.
Erstellen und Veröffentlichen eines Web-Service
Ein Web-Service wird in einer .asmx Datei abgelegt. Diese Datei kann mehrere Methoden in einer
Klasse eingebettet enthalten. Methoden, die als Webdienst zur Verfügung gestellt werden sollen
müssen entsprechend als solche gekennzeichnet werden. Dies erfolgt durch Angabe eines Attributes
[WebMethod] vor der entsprechenden Methode. Die zur Definition benutzte Sprache ist in diesem
Zusammenhang völlig unerheblich, sie wird zu Beginn der ASP Datei angegeben. Einzig wichtig ist
die Kennzeichnung der Methoden auf die ein Zugriff ermöglicht werden soll.
Microsofts Umsetzung der Web-Services beruht, obwohl das nicht direkt sichtbar ist, auf den bereits
erwähnten Technologien (SOAP, UDDI, WSDL). Der Entwickler bekommt von alldem sehr wenig
mit, das liegt zum einen an der Umsetzung (der Implementierung) der Web-Service Unterstützung,
zum anderen auch an der Unterstützung durch Visual Studio.NET.
Das eigentliche Veröffentlichen des Dienstes auf dem entsprechenden Server wird vollständig von
Visual Studio.NET übernommen, so dass ein sofortiger Zugriff auf den Dienst mittels SOAP möglich
ist.
Zugriff auf einen Web-Service
Eine Anwendung, also ein Client kann in einer ähnlich einfachen Art und Weise auf einen WebService zugreifen. Eine Voraussetzung muss allerdings erfüllt werden, um einen Zugriff zu
ermöglichen. Der Entwickler der Client-Anwendung muss einen so genannten Proxy erstellen, der als
lokaler Stellvertreter für den Web-Service dient. Folgende Abbildung veranschaulicht den Zugriff auf
einen Dienst:
Seite 40
Web-Services zur Datenintegration mobiler Endgeräte
CLIENT
SERVER
Webservice
Client Anwendung
Klasse ABC
...
Methode XYZ{
...
}
XYZ();
...
Aufruf der
Methode
XYZ
Aufruf des
Web
Service
Rückgabewert
des Web
Service
Rückgabewert
der
Methode
XYZ
Proxy Klasse
Methode XYZ{
...
}
SOAP Anfrage
Umsetzung der
SOAP Anfrage
Generierung der
Antwort
SOAP Antwort
Abbildung 5: Zugriff auf einen Web-Service
Visual Studio.NET erstellt für einen Dienst (der mittels einer WSDL-Beschreibung oder einer URIReferenz lokalisiert wird) eine Proxy-Klasse, die die benötigten Methoden implementiert. Diese
Implementierung steht lokal bei der Client-Anwendung zur Verfügung. Die entsprechenden Methoden
der Proxy-Klasse enthalten nicht die Implementierung der eigentlichen Methode, sondern erzeugen bei
einem Aufruf eine SOAP-Anfrage, die dann an den entsprechenden Server übermittelt wird. Der
Server erzeugt anschließend eine entsprechende Antwort. Diese Antwort wird dann über den
Rückgabewert an die Client-Anwendung zurückgeliefert. Der Entwickler bekommt von diesem
Vorgang nichts mit, da sämtliche Aufgaben von Visual Studio .NET übernommen werden.
Zu erwähnen ist an dieser Stelle noch, dass Microsoft nur UDDI-Registries unterstützt und keinen
Zugriff auf ebXML-Registries ermöglicht.
Seite 41
Web-Services zur Datenintegration mobiler Endgeräte
2.5.3
Sicherheit der XML Web-Services
Die Umsetzung folgender Sicherheitsaspekte wird untersucht:
Verschlüsselung,
Autorisierung und
Authentisierung.
2.5.3.1 Verschlüsselung
Die Verschlüsselung des Datenstroms erfolgt durch den Web-Server. Microsoft lagert das Problem der
Verschlüsselung auf den Internet Information Server (IIS) aus. Eine SSL-Unterstützung der WebServices hängt somit von der Konfiguration des Web-Servers ab.
2.5.3.2 Autorisierung und Authentisierung
Analog zu der Verschlüsselung werden auch Autorisierung und Authentisierung vom IIS
übernommen. Es besteht die Möglichkeit, über die Eigenschaften der entsprechenden .asmx Datei,
eine Authentifizierung, sowie eine Autorisierung auszuwählen.
HTTP Basic
Der Benutzer wird durch Benutzername/Passwort-Kombination authentisiert. Diese Authentisierung
ist unsicher, da Benutzername und Passwort als Text gesendet werden. Unter Verwendung von Secure
Sockets Layer (SSL) Verschlüsselung kann dieser Nachteil abgeschwächt werden.
Client-certificate
Diese Form der Authentisierung benutzt SSL, um eine verschlüsselte (und somit sicherere
Übertragung) zu gewährleisten. Ein Client authentisiert sich mittels eines Zertifikats, das er erhalten
muss. Zertifikate werden auf Benutzer-Accounts abgebildet, die der IIS verwaltet.
Digest
Im Rahmen dieser Form der Authentisierung werden Passwörter verschlüsselt abgelegt. Die
Verschlüsselung ist sehr schwer umkehrbar, so dass die Sicherheit gewährleistet ist. Die Passwörter
können durch den Internet Information Server (trotz der Verschlüsselung) zur Authentisierung
verwendet werden. Aus Sicht des Benutzers ist kein Unterschied zur Basic-Authentisierung zu
erkennen. Ein wichtiger Unterschied stellt aber das Passwort dar, das immer (auch wenn keine
Verwendung von SSL stattfindet) verschlüsselt übertragen wird und somit eine wesentlich sicherere
Kommunikation gewährleistet.
Seite 42
Web-Services zur Datenintegration mobiler Endgeräte
2.5.4 Visual Studio .NET
Visual Studio ist ein Werkzeug, eine graphische Entwicklungsumgebung, zur Erstellung von
Anwendungen. Die neue Variante der Visual Studio-Reihe, die den Zusatz .NET als Versionsnummer
trägt, unterstützt vor allem die neuen Aspekte der Entwicklung, etwa die Bereitstellung oder den
Zugriff auf Web-Services. Diese Arbeit beschäftigt sich im Wesentlichen mit den Konzepten der
neuen Plattform, Einführungen und Handbücher zu den Werkzeugen, wie etwa Visual Studio können
der Literatur zu .NET entnommen werde. Im nächsten Abschnitt wird Visual Studio an einigen Stellen
referenziert, um einen Überblick zu geben, welche Aspekte in groben Strukturen wie umgesetzt
werden können.
2.6 SUN ONE
Sun Microsystems zog nach der Einführung der .NET-Plattform seinerseits mit der Einführung der
Sun ONE-Architektur nach. ONE steht hierbei für Open Net Environment. Sun legt Wert darauf, dass
die ONE-Architektur alle Arten von Entwicklungen unterstützt, sowohl gegenwärtige, wie auch
zukünftige Projekte sollen effizient umgesetzt werden können. Sun beschreibt im Sun ONE
Architecture Guide [SunAg02] die Evolution des "Network computing" innerhalb der letzen Jahre und
wie diese Änderung meist mit Einführung eines neuen Betriebssystems einhergeht. Auf Grundlage
dieser Evolution stellt Sun ein Ziel an die ONE-Plattform: "Unternehmen an die neue Generation der
Netzwerk-Anwendungen heranzuführen".
In einem ersten Schritt wird nun eine Einführung in die Art der unterstützten Projekte geboten, bevor
eine Erläuterung der Plattform folgt. Ein weiterer zentraler Teil der Einführung wird wie bei der
Erläuterung der .NET-Plattform der Umsetzung der Web-Services zuteil kommen.
2.6.1 Services on Demand
Der Begriff Services on Demand wurde von Sun geprägt, er beschreibt die möglichen
Anwendungsalternativen, die seitens der ONE-Plattform unterstützt werden. Sun spricht im
Zusammenhang der Services on Demand gar von einer "Vision". Die Services on Demand umfassen
vergangene, gegenwärtige und zukünftige Dienste. Im Einzelnen sind dies:
Lokale Anwendungen
Anwendungen, die auf PCs oder Workstations laufen, z.B. Office-Anwendungen
Client/Server-Anwendungen
Anwendungen, die aufgeteilt sind, üblicherweise wird die Präsentationslogik clientseitig und die
Business-Logik serverseitig bereitgestellt.
Seite 43
Web-Services zur Datenintegration mobiler Endgeräte
Web-Anwendungen
Anwendungen, die über das Web laufen und auf Browserclients sowie Standard-Webprotokollen
basieren (HTML, HTTP).
Web-Services
Dienste, die über das Web ausgeführt werden und mit anderen Diensten kombiniert werden können
um hochkomplexe Anwendungslösungen bereitstellen zu können.
Web-Clients
Anwendungen, die in Java geschrieben sind und die über das Web an Java-fähige Geräte etwa PDAs
etc. ausgeliefert werden.
2.6.2
ONE-Architektur
Sun beschreibt seine Architektur als so genannten "Service Stack", der in drei Stufen unterteilt ist. In
einer sehr allgemeinen Form sieht der Stack wie folgt aus:
Stufe 3
Stufe 2
Stufe 1
Erzeugen, Binden und Veröffentlichen von
Services on Demand
Service
Delivery
Service
Container
Service
Integration
Betriebssystem-,Netzwerk-,Hardware-Plattform
Identität
Abbildung 6: Sun ONE-Plattformarchitektur
Die erste Stufe beschreibt sehr generelle Aspekte, sie besteht aus der Betriebssystem-, der Hardware-,
und Netzwerk-Plattform, sowie Aspekten der Identität.
Seite 44
Web-Services zur Datenintegration mobiler Endgeräte
Die zweite Stufe ist unterteilt in 3 Schichten:
Service Delivery,
Service Container und
Service Integration.
Die dritte Stufe zielt auf das Erzeugen, Binden und Veröffentlichen von Services ab.
Den einzelnen Stufen sind Standard-APIs zugeordnet, welche die jeweiligen Aspekte umsetzen. Das
Architecture Guide [SunAg02] bietet neben einer Zuordnung möglicher Standard-APIs zu den drei
Stufen des Stack eine weitere Zuordnung der auf der ONE-Plattform verwendeten Produkte zu den
einzelnen Stufen. Es stehen jeweils eine Reihe möglicher Technologien und Standard-APIs für die
einzelnen Stufen zur Verfügung.
Eines der Produkte wird im Folgenden kurz vorgestellt. Es handelt sich dabei um ein Werkzeug, das
der dritten Stufe, also der Erstellung und Veröffentlichung von Web-Services zugeordnet ist. Das
Produkt trägt den Namen Sun ONE Studio.
2.6.2.1 Sun ONE Studio Enterprise Edition (Forte 4)
Mit Sun ONE Studio stellt Sun dem Entwickler ein Werkzeug bereit, das zur Unterstützung und
Veröffentlichung von Services on Demand genutzt werden kann. Vergleichbar ist das Produkt mit
Visual Studio .NET, das auf der .NET-Plattform zum Einsatz kommt. Beide Werkzeuge verfolgen ein
ähnliches Prinzip und bieten auch zum Teil ähnliche Funktionalitäten an, unterscheiden sich jedoch
durch eine unterschiedliche Bedienung und natürlich hauptsächlich durch die zugrunde liegende
Plattform. Die dadurch resultierenden Unterschiede beziehen sich zum einen auf unterschiedliche
unterstützte Programmiersprachen und zum Teil auch auf die angebotene Funktionalität. Hinsichtlich
der Programmiersprache ist Sun durch die ONE-Plattform an Java gebunden, während Visual Studio
seinerseits die Wahl der Programmiersprache dem Entwickler überlässt, die er aus einem Pool an
angebotenen Sprachen (Kapitel 2.5) treffen kann.
Das Sun ONE Studio-Werkzeug ist keine vollständige Neuentwicklung von Sun, es ist wie Visual
Studio .NET auch die Neuauflage eines bereits existierenden Produkts. Sun hat das Forte-Produkt, das
zuletzt in Version 3 erschienen ist, an die neue Plattform angepasst und in diesem Zuge ist das Produkt
hinsichtlich der Funktionalität erweitert worden. Eine der wichtigsten Neuerungen in Version 4, also
Sun ONE Studio, ist die Unterstützung der Erstellung und Veröffentlichung von Web-Services, die
aber nur in der Enterprise Edition (kostenpflichtig) verfügbar ist.
Es wurde bereits mehrfach erwähnt, dass die Unterstützung der Erstellung der Services on Demand
und somit auch der Web-Services (ein Teil der Services on Demand) zentraler Aspekt der ONEPlattform und ihrer Produkte ist. Im Folgenden wird diese Unterstützung erläutert:
Seite 45
Web-Services zur Datenintegration mobiler Endgeräte
2.6.3
Web-Services
Die Unterstützung der Web-Services wird durch die Java 2 Plattform Enterprise Edition (J2EE) und
einer Reihe von APIs ermöglicht. Die Enterprise Edition der Java 2 Plattform unterstützt die
Entwicklung von Anwendungen die hohen Ansprüchen in Bereichen wie Sicherheit und Stabilität
genügen müssen. Diese Unterstützung kommt somit auch den Web-Services zugute. Aktuell liegt
J2EE in Version 1.3 vor, welche noch keine implizite Unterstützung zur Erstellung von Web-Services
enthält. In Version 1.4 soll laut Sun diese Unterstützung bereits Bestandteil des Pakets sein, bis dahin
erfolgt diese über ein separates Paket, das so genannte Java Web-Services Developer Pack, das von
Sun bezogen werden kann [SunDp02]. Dieses Paket enthält eine Reihe von APIs, die der
Unterstützung der Web-Services dienen; im Einzelnen sind dies:
JAXP (Verarbeitung von XML-Dokumenten),
JAXB (Zuordnung von XML-Elementen zu Java-Klassen),
JAXM (SOAP-Nachrichten verschicken),
JAXR (Zugriff auf Registries) und
JAX-RPC (SOAP-Anfragen in Form von Remote Procedure Calls stellen und verarbeiten).
Im Folgenden werden einige der oben erwähnten Schnittstellen genauer beschrieben. Allgemein
enthalten folgende Referenzen weitere Beschreibungen und Einführungen in die Umsetzung der WebServices von Sun: [SunDp02], [SunWs02], [SunDg02], [SunDw02].
2.6.3.1 JAXR
Sun bietet mit JAXR eine Möglichkeit, einen Web-Service innerhalb einer Registry zu registrieren.
Die Umsetzung konzentriert sich nicht auf eine spezifische Registry, sondern soll laut Sun die am
häufigsten eingesetzten Registries unterstützen. Der Vorteil dieses Ansatzes ist natürlich, dass der
Entwickler sich keine Gedanken über die kleineren Unterschiede zwischen beispielsweise der UDDI
Registry und der ebXML Registry zu machen braucht, da die Schnittstelle im Wesentlichen davon
abstrahiert.
Das JWSDP enthält ein Werkzeug, einen Registry Browser, der es ermöglicht sich Informationen aus
Registries anzusehen oder aber Dienste in einer Registry einzutragen. Das Werkzeug befindet sich im
bin Verzeichnis des Installationsverzeichnis des WSDP und kann über jaxr-browser aufgerufen
werden.
Folgende Referenzen bieten weitergehende Informationen zu der JAXR-Schnittstelle an: [OrMa02],
[Qua02].
Seite 46
Web-Services zur Datenintegration mobiler Endgeräte
2.6.3.2 JAX-RPC
Dieses API bietet eine Umsetzung der Web-Service-Unterstützung.
Zum einen ermöglicht diese Schnittstelle das Erstellen und Veröffentlichen eines Dienstes, zum
anderen den Zugriff auf den entsprechenden Dienst.
Web-Service erstellen und veröffentlichen
Zur Erstellung eines Web-Service werden zwei Dateien benötigt, erstens ein Interface das alle nötigen
Methoden des Web-Service enthält und zweitens eine Klasse, die alle Methoden implementiert.
Nachdem diese beiden Dateien existieren, werden alle Dateien in ein Web Application Archive
(WAR) gebunden. Eine WAR-Datei ist vergleichbar mit einer JAR Java-Datei. Diese WAR Datei
wird abschließend auf einem entsprechenden Server veröffentlicht.
Web-Service nutzen
Einen Web-Service zu nutzen ist sehr einfach. Eine Klasse muss eine Instanz des entsprechenden
Interface erstellen und über diese Instanz die entsprechende Methode aufrufen.
Hinter den Kulissen werden die Aufrufe in SOAP-Anfragen umgewandelt und über eine Anfrage an
den Server wird dann eine Antwort erstellt und der Rückgabewert wird dann an die Client Anwendung
übermittelt.
Neben diesen beiden API werden noch APIs zum Verarbeiten von XML-Dokumenten (JAXP und
JAXB) sowie ein API zum Erstellen und Verschicken von SOAP-Anfragen bereitgestellt.
2.6.4 Sicherheit der Web-Services
Die Umsetzung folgender Sicherheitsaspekte wird im Folgenden näher betrachtet:
Verschlüsselung,
Autorisierung und
Authentisierung.
Ein Web-Service wird unter Verwendung des JWSDP über den Tomcat Server veröffentlicht, dieser
regelt Zugriffe auf die einzelnen Dienste und ist somit auch für Aspekte der Sicherheit verantwortlich.
2.6.4.1 Verschlüsselung
Eine sichere Kommunikation kann durch den Einsatz von SSL garantiert werden. Tomcat unterstützt
SSL und es kann somit eine Verschlüsselung des Datenflusses erreichet werden.
2.6.4.2 Autorisierung
Das JWSDP bietet die Möglichkeit, über den Tomcat Server sicherheitsrelevante Informationen zu
verwalten und zu steuern.
Seite 47
Web-Services zur Datenintegration mobiler Endgeräte
Drei Aspekte werden bereitgestellt:
Benutzer
Person oder Anwendung, die gewisse zugewiesene Rollen besitzt und möglicherweise zu einer oder
mehreren Gruppen gehört.
Gruppen
Eine Klasse von Benutzern, die gewisse zugewiesene Rollen besitzt.
Rollen
Erlaubnis, auf gewisse Ressourcen zuzugreifen.
Benutzerinformationen werden durch Tomcat in einer XML-Datei verwaltet. Zum einen ist es möglich
eine Verwaltung der Benutzer mittels dieser XML-Datei vorzunehmen, zum anderen wird ein
Werkzeug namens admintool angeboten, das eine graphische Verwaltung der Gruppen, Rollen und
Benutzer ermöglicht.
Auf Grundlage dieser Informationen können Webressourcen abgesichert werden. Ein Web-Service
wird als WAR-Datei auf einem Server veröffentlicht. Das Erstellen eines Web-Service benötigt neben
der eigentlichen Implementierung der Klassen weitere Informationen den Dienst betreffend. Diese
Informationen werden in einer XML-Datei (web.xml) gespeichert. Unter anderem enthält diese XMLDatei Einschränkungen bezüglich der Sicherheit des entsprechenden Dienstes. Analog zu den
Benutzerinformationen
wird
ein
Werkzeug
angeboten,
welches
die
Möglichkeit
bietet,
Einschränkungen graphisch vorzunehmen. Das deploytool Werkzeug bietet die Möglichkeit, zu einer
WAR-Datei Rollen anzugeben, die Zugriff auf den Dienst erhalten. Somit können nur autorisierte
Benutzer, also Benutzer, die eine entsprechende Rolle vorweisen, den Web-Service nutzen.
2.6.4.3 Authentisierung
Das Werkzeug deploytool bietet neben der Kontrolle von Web-Services gegen unbefugten Zugriff auf
Basis der Autorisierung auch die Möglichkeit, Authentisierungsmechanismen für eine WAR-Datei
und somit einen Web-Service festzulegen.
Es gibt mehrere mögliche Formen der Authentisierung:
HTTP Basic
Der
Benutzer
wird
durch
eine
Benutzername/Passwort-Kombination
authentisiert.
Diese
Authentisierung ist unsicher, da Benutzername und Passwort als Text gesendet werden. Unter
Verwendung von Secure Sockets Layer (SSL) Verschlüsselung kann diese dieser Nachteil
ausgeschlossen werden.
Seite 48
Web-Services zur Datenintegration mobiler Endgeräte
Form-based
Im Rahmen der form-based-Authentisierung wird das Login-Fenster durch die implementierende
Anwendung vorgegeben und kann somit an eigene Bedürfnisse angepasst werden. Es besteht
hinsichtlich der eigentlichen Authentisierung kein Unterschied zur Basic-Authentisierung, analog
muss auch diese Form der Authentisierung mittels SSL abgesichert werden, um eine vernünftige
Sicherheit zu bieten.
Client-certificate
Diese Form der Authentisierung benutzt Secure Socket Layer (SSL) um eine verschlüsselte (und somit
sicherere Übertragung) zu gewährleisten. Ein Server (optional kann dies auch für den Client erfolgen)
authentisiert sich mittels eines Public Key Certificates. Durch SSL (also einer Verschlüsselung des
Kommunikationsflusses) ist eine sichere Kommunikation möglich.
Digest
Im Rahmen dieser Form der Authentisierung werden Passwörter verschlüsselt abgelegt. Die
Verschlüsselung ist sehr schwer umkehrbar, so dass die Sicherheit gewährleistet ist. Die Passwörter
können durch Tomcat (trotz der Verschlüsselung) zur Authentisierung verwendet werden. Aus Sicht
des Benutzers ist kein Unterschied zur Basic-Authentisierung zu erkennen. Ein wichtiger Unterschied
stellt aber das Passwort dar, das immer (auch wenn keine Verwendung von SSL stattfindet)
verschlüsselt übertragen wird und somit eine wesentlich sicherere Kommunikation gewährleistet.
2.6.5 Kompabilität zu Microsoft .NET
Sun war sich der Tatsache bewusst, dass sehr viele Unternehmen die neue .NET-Plattform nutzen
werden oder bereits benutzen und so wurde eine Unterstützung der .NET-Plattform umgesetzt.
Sun verspricht eine volle Unterstützung der Web-Services. Es soll sowohl möglich sein, auf WebServices zuzugreifen, die mittels der .NET-Plattform erstellt wurden, als auch Web-Services
anzubieten, die dann seitens der .NET-Plattform genutzt werden können. Die Basis dieser
Unterstützung liegt natürlich vor allem in der strikten Umsetzung des Web-Services-Gedanken und
seiner zugrunde liegenden Technologien (WSDL, UDDI, SOAP), die den Aspekt der
Plattformunabhängigkeit propagieren und somit diese Interoperabilität ermöglichen.
Seite 49
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 3: Vergleich der Plattformen
In diesem Kapitel wird eine Vergleich zwischen den Plattformen von Sun und Microsoft angestellt, so
dass eine Entscheidung bezüglich des Einsatzes einer der Plattformen in der vorliegenden Arbeit auf
dieser Grundlage getroffen werden kann.
3.1 Sun ONE versus Microsoft .NET
Vor dem eigentlichen Vergleich werden noch einige Anmerkungen zu den Vor- und Nachteilen
angeführt. Die Punkte sind mit dem Hauptaugenmerk auf die Entwicklung von Web-Services
herausgearbeitet worden. Zum Teil sind die erwähnten Punkte im Rahmen der Einarbeitung in beide
Plattformen hervorgetreten, zum Teil werden auch Punkte aufgeführt, die aus der Literatur entnommen
wurden. Es gibt in diesem Bereich einige Artikel, die sich der Gegenüberstellung beider Plattformen
annehmen und die Vor- und Nachteile beider Plattformen auflisten, sowie auch Empfehlungen an
Entwickler geben, welche der beiden Plattformen bei der Entwicklung von Anwendungen geeigneter
ist.
Es wird darauf hingewiesen, dass diese Gegenüberstellung keinen politischen oder strategischen
Hintergrund verfolgt, es werden objektiv die einzelnen Punkte einander gegenübergestellt und
bewertet.
Im Folgenden werden nun zentrale Themen der Entwicklung von Anwendungen und weitere relevante
Gebiete oder Eigenschaften einer Entwicklungsplattform aufgezählt und deren Umsetzung oder
Ausprägung auf beiden Plattformen erläutert.
3.1.1
Reife
Einer der Hauptkritikpunkte an .NET ist der geringe Reifegrad der Plattform, .NET ist eine Plattform,
die zum größten Teil von Grund auf neu entwickelt worden ist. Es stellt sich also in diesem Rahmen
die Frage nach der Fehleranfälligkeit und somit auch der Stabilität einer .NET-Anwendung, sowie
auch der mitgelieferten Produkte. Der Vorteil der ONE-Plattform ist in diesem Bereich ganz klar in
der Verwendung bereits existierender Produkte begründet. Mit Java, allen voran der J2EE Version
kann Sun eben diese Stabilität bereits vorweisen, da sich die Produkte bereits über einen längeren
Zeitraum bewährt haben. Im Vergleich weisen die entsprechenden ONE-Produkte also einen höheren
Reifegrad als die der .NET-Plattform auf. Allerdings wird darauf hingewiesen, dass dies eine
Momentaufnahme ist, die sich im Laufe der Zeit verändern kann, da mit der Zeit auch der Reifegrad
der .NET Produkte wachsen kann, wenn diese sich bewähren.
Seite 50
Web-Services zur Datenintegration mobiler Endgeräte
3.1.2 Programmiersprache
ONE bietet als Programmiersprache Java an, Sun setzt voll und ganz auf diese eine Sprache, die
hinsichtlich Funktionalität kaum Wünsche offen lässt.
.NET bietet dem Programmierer eine Reihe möglicher Sprachen, so dass eine Einschränkung auf eine
Sprache nicht erfolgt und der Programmierer die ihm vertraute Sprache zur Entwicklung von
Anwendungen auswählen kann.
In diesem Bereich weist .NET einen leichten Vorteil auf, es sei allerdings erwähnt, dass Java in punkto
Funktionalität jeder Sprache der .NET-Plattform ebenbürtig ist. Einige Entwickler messen aber dem
Aspekt der freien Auswahl der Programmiersprache größere Bedeutung zu.
3.1.3 Portabilität
In punkto Web-Services ist es möglich, auf der .NET-Plattform entwickelte und angebotene WebServices auf der ONE-Plattform zu benutzen. Ebenso ist auch der analoge Rückschritt möglich, so
dass der Bereich der Web-Services hinsichtlich der Portabilität keine Vor- oder Nachteile aufweist.
Anders sieht es allerdings im Bereich der eigentlichen Anwendungen aus, während die JavaAnwendungen der ONE-Plattform auf allen Java fähigen Plattformen ausgeführt werden können, sind
alle Anwendungen die auf der .NET-Plattform entwickelt werden, (noch) an MicrosoftBetriebssysteme gebunden. Es ist theoretisch möglich - wie Microsoft erwähnt - dass Just-in-Time
Compiler auch für andere Plattformen entwickelt werden. Einen solchen Versuch stellt das MonoProjekt dar, das den Versuch unternimmt .NET auf UNIX zu portieren. Das Projekt befindet sich
zurzeit noch in der Entwicklung, einige Bereiche konnten jedoch bereits übernommen werden, siehe
hierzu auch [Xim02].
3.1.4 Web-Services (allgemein)
Der Aspekt der Web-Service-Entwicklung wurde im vorherigen Kapitel eingehend erläutert, es
werden hier noch einmal kurz die Ergebnisse zusammengefasst: Beide Plattformen unterstützen das
Entwickeln von Web-Services nach den Standards XML, UDDI, SOAP und WSDL, so dass in diesem
Bereich beide Plattformen eine hervorragende Unterstützung bieten.
3.1.5 Technologie
Microsoft bietet mit der .NET-Plattform ein Produkt an, das im Moment noch keinen Standard
darstellt, einige Aspekte wurden zur Standardisierung eingereicht, den Status eines Standards
wird.NET aber wahrscheinlich nie erreichen. Demgegenüber bietet Sun mit seinen Produkten, wie
J2EE Standards zur Entwicklung an. Java vereint mehrere Unternehmen, die Produkte für ihre
Plattform entwickeln, während Microsoft hier eher eine alleinige Entwicklung anstrebt. Es besteht
somit die Möglichkeit, dass Sun eine höhere Kompetenz aufweisen könnte, dies ist aber eine eher
martkstrategische Überlegung, die an dieser Stelle nicht weiter verfolgt werden soll.
Seite 51
Web-Services zur Datenintegration mobiler Endgeräte
3.1.6
Entwicklungswerkzeug
In diesem Bereich haben beide Anbieter sehr leistungsfähige Produkte: Auf der einen Seite bietet
Microsoft das Visual Studio .NET-Produkt, auf der anderen Seite Sun Sun ONE Studio. Beide
Werkzeuge unterstützen alle Aspekte der Entwicklung, so dass dem Entwickler eine wesentliche
Unterstützung bei der Erstellung von Anwendungen zuteil wird. Allgemein wird das Visual Studio
.NET in der Literatur als leistungsfähigeres und umfangreicheres Produkt von beiden beschrieben.
Neben diesen allgemeinen Aspekten, die beide Plattformen einander gegenüberstellen, ohne dabei das
Augenmerk auf die vorliegenden Arbeit zu legen, werden nun Aspekte erläutert, die direkt mit der
Implementierung der Arbeit in Verbindung stehen.
3.1.7
Datenbankzugriff
Der Datenbankzugriff in .NET wird mittels ADO.NET abgewickelt, wie dies auch schon in
vorherigem Kapitel erwähnt wurde. Das Problem, das im Moment im Bereich des Datenbankzugriffs
mit ADO.NET vorherrscht, ist das des mangelnden Angebots an nativen Datenbanktreibern. Einzig
ein nativer Datenbanktreiber für den Microsoft SQL Server wird von Microsoft angeboten, so dass in
punkto Performance andere Datenbanken gegenüber dem Microsoft-Produkt leichte Nachteile
vorweisen. Dies kann durch Entwicklung adäquater nativer Datenbanktreiber für die .NET-Plattform
ausgeräumt werden, falls eine dementsprechende Möglichkeit seitens Microsoft zugelassen wird.
Die ONE-Plattform bietet für den Datenbankzugriff das JDBC API, das es ermöglicht eine Reihe von
Datenbanken über native Treiber anzusprechen, so dass etwaige Performance-Probleme nur mit einer
schlechten Umsetzung eines Treibers zusammenhängen, nicht aber auf einen Mangel an Treibern
zurückzuführen sind.
3.1.8
Web-Services
Die Umsetzung der Web-Services wurde bereits im Detail besprochen. An dieser Stelle werden die
Ergebnisse kurz noch einmal zusammengefasst. .NET bietet einen entsprechenden Namespace
System.Web.Services innerhalb von ASP.NET an, der eine Entwicklung von Web Diensten
ermöglicht. Sun bietet das so genannte Java Web-Services Developer Pack an, das eine Reihe von
Schnittstellen (JAXP, JAXB, JAXM, JAXR, JAX-RPC) vereint, welche eine Entwicklung und
Veröffentlichung der Web-Services ermöglichen.
3.1.9
XML-Unterstützung
Beide Plattformen bieten die Möglichkeit, XML-Dokumente zu verarbeiten, .NET innerhalb eines
entsprechenden Namespaces, ONE bietet die JAXP- und JAXB-Schnittstellen mit Hilfe welcher
XML-Dokumente auf Basis der Parser SAX und DOM verarbeitet werden können
Seite 52
Web-Services zur Datenintegration mobiler Endgeräte
3.1.10 Sicherheit
Sowohl .NET als auch ONE bieten die Möglichkeit, Web-Services gegen unrechtmäßige Zugriffe zu
schützen. .NET bietet die Möglichkeit über den IIS, Autorisierung und Authentisierung sowie auch
einen verschlüsselte Kommunikation unter Verwendung von SSL zu gewährleisten. Die ONEPlattform bietet u.a. den Tomcat Server an, der ähnlich wie IIS auch die Aspekte der Autorisierung
und Authentisierung umsetzt und ebenso wie IIS auch eine verschlüsselte Kommunikation über SSL
bietet.
3.2 Übersicht und Empfehlung
Folgende Tabellen bieten eine übersichtliche Darstellung aller Aspekte zuzüglich einer Bewertung.
Aspekt / Plattform
.NET
ONE
Reife
-
++
Programmiersprache
++
+
Portabilität
o
++
Web-Services
++
++
Technologie
o
+
Werkzeug
++
+
Tabelle 2: Bewertung allgemeiner Aspekte der .NET und ONE-Plattformen
.NET
Aspekt
Bewertung
Umsetzung
Bewertung
Datenbankunterstützung ADO.NET
+
JDBC
++
Web-Services
++
JWSDP
++
XML
Sicherheit
Umsetzung
ONE
ASP.NET
XML
Namespace
IIS
++
++
JAXP,JAXB
(SaX, DOM)
Tomcat
++
++
Tabelle 3: Bewertung von Implementierungsaspekten der .NET und ONE-Plattformen
Die Empfehlungen, die aus verschiedenen Literaturquellen [ShMo02] und [Kru02] hervorgehen, sind
einheitlich der ONE-Plattform positiver gestimmt. Es wird allerdings erwähnt, dass ein Wechsel
zwischen den Plattformen unsinnig wäre, da keine einen diesen enormen Schritt rechtfertigenden
Vorteil besitzt. Beide Plattformen unterscheiden sich in punkto Funktionalität nicht wesentlich, alle
notwendigen Unterstützungen sind vorhanden, so dass hier keine Entscheidung getroffen werden
kann. Vor allem aber der Aspekt der Reife und der damit verbundenen Stabilität und Performance
Seite 53
Web-Services zur Datenintegration mobiler Endgeräte
spricht im Moment für die ONE-Plattform, hier muss noch einige Zeit vergehen, bis die .NETPlattform, zumindest theoretisch einen ähnlichen Stellenwert erreichen kann. Eine Bewertung beider
Plattformen anhand der Verbindung obiger Aspekte (Tabellen) und der Literaturkritiken führt zu dem
Ergebnis, das s zum aktuellen Zeitpunkt die Sun ONE-Plattform als Grundlage der Implementierung
der Middleware dieser Diplomarbeit dienen sollte.
3.3 Erweiterung der Anforderungen
Auf Grundlage der vorherigen Beschreibungen kann aus FBAF7 eine weitere Entwurfsentscheidung
abgeleitet werden:
Entwurfsentscheidungen
Middleware
Die Implementierung der Middleware, somit
EE6
auch das Anbieten der Daten mittels WebServices erfolgt auf Basis der ONE-Plattform.
EE7
Der Zugriff auf die Datenbank erfolgt mittels
JDBC.
Seite 54
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 4: Realisierungsentscheidung
Anforderungen und mögliche Realisierungen
Auf der Grundlage der Sun ONE-Plattform werden in diesem Kapitel die Anforderungen an das zu
entwerfende System angeführt. Dabei wird neben den Anforderungen an die einzelnen Komponenten
Endgerät, Middleware und Client vor allem das Zusammenspiel dieser Komponenten berücksichtigt.
Auf den Anforderungen basierend werden mögliche Realisierungsalternativen vorgestellt und für die
Verwendung im Rahmen dieser Arbeit bewertet.
4.1 Mobiles Endgerät
Für die vorliegende Diplomarbeit steht als Plattform für ein mobiles Endgerät ein Beck IPC Chip
SC121 zur Verfügung, der einen Web-Server bereitstellt sowie eine Schnittstelle, über die mögliche
Sensoren, die an den Chip angeschlossen werden können, abgefragt werden können. Primäre Aufgabe
eines solchen Endgeräts ist die Aufbereitung und das Zur-Verfügung-Stellen der gemessenen Daten.
Vier Aspekte sind dabei für die Implementierung der Funktionalität von Bedeutung:
Erfassen der Daten,
Aufbereiten der Daten,
Anbieten der Daten sowie
Sicherheit.
Im Folgenden werden diese Aspekte erläutert:
4.1.1 Erfassen der Daten
Ein mobiles Endgerät hat die primäre Aufgabe die an den Sensoren vorliegenden Daten der
Middleware zur Verfügung zu stellen. Die Daten, die in regelmäßigen Abständen an möglichen
Quellen (Sensoren) erhoben werden, werden zu diesem Zweck lokal gespeichert. Die gespeicherten
Daten können somit nach außen hin zur Verfügung gestellt werden.
Folgender Ablauf wird zur Erfassung der Daten gewählt:
In der Initialisierungsphase werden die Informationen zu den einzelnen Datenquellen verarbeitet, es
wird eine Liste erstellt, welche alle zu diesem Zeitpunkt aktiven Datenquellen enthält. Zu jeder der
Datenquellen muss die Zeitspanne angegeben sein, in der eine Aktualisierung der Daten
vorgenommen wird. Zusätzlich werden zu diesen Datenquellen die entsprechenden Daten
1
Datenblatt mit technischen Daten im Anhang
Seite 55
Web-Services zur Datenintegration mobiler Endgeräte
abgespeichert. Anschließend wird ein Durchlauf gestartet, der ein regelmäßiges Abfragen der Daten
ermöglicht.
In diesem regelmäßigen Durchlauf wird anhand der vorgegebenen Zeitspanne überprüft, ob eine
Datenquelle ihren Messwert aktualisiert hat. Ist dies der Fall, werden die aktuellen Daten gespeichert,
um somit immer die aktuellsten Daten anbieten zu können.
4.1.2
Aufbereiten der Daten
Während der Erfassung der Daten werden die an den Sensoren vorliegenden Daten in regelmäßigen
Abständen gespeichert. Das Speichern der Daten muss in einem standardisierten Format erfolgen, so
dass eine weitere Verarbeitung einfach und problemlos möglich ist. In Kapitel 2 wurde zu diesem
Zweck die Extensible Markup Language vorgestellt, die an dieser Stelle zum Einsatz kommt. Das
Aufbereiten der Daten erfolgt also in Form von XML-Dateien, in denen die gemessenen Daten
abgelegt werden. Hierzu werden allgemeine Schemata festgelegt, welche alle theoretisch möglichen
Typen von Sensoren unterstützen.
Im Folgenden werden Anforderungen an die XML-Schemata hinsichtlich der zu speichernden
Informationen und der Beziehungen zwischen den jeweiligen Informationen genannt, im
nachfolgenden Kapitel werden diese Schemata dann realisiert.
Die allgemeinste Einheit, die zur Verfügung steht, ist das mobile Endgerät. Folgende Informationen
werden abgelegt:
Information
Typ
Beschreibung
id
String
Identifikation des mobilen Endgeräts
number
Integer
Anzahl der Datenquellen die das Endgerät enthält
uptime
Integer
gibt indirekt die Zeitpunkte an, zu welchen das Endgerät erreichbar
ist
Tabelle 4: Informationen über das mobile Endgerät
Aus der Tabelle geht hervor, dass ein mobiles Endgerät mehrere Datenquellen besitzen kann, diese
stellen die nächste Ebene der Granularität dar.
Eine Datenquelle enthält folgende Informationen:
Seite 56
Web-Services zur Datenintegration mobiler Endgeräte
Information
Typ
Beschreibung
id
String
gibt eine Identifikation für die Datenquelle an
description
String
gibt eine allgemeine Beschreibung der Datenquelle an
type
String
gibt den Typ der Datenquelle an
status
boolean
gibt an, ob die Datenquelle aktiv ist oder nicht
refresh rate
Integer
measurement
String
gibt die Abstände an, an denen die Datenquelle aktualisiert
wird
verweist auf die Messergebnisse
Tabelle 5: Informationen über einen Sensor
In Bezug auf die Messwerte wird eine weitere Anforderung an ein mobiles Endgerät gestellt. Es sollte
eine gewisse (vom Benutzer bestimmbare) Anzahl an Messwerten pro Datenquelle gehalten werden
können. Das mobile Endgerät muss demzufolge lokal Messergebnisse speichern können.
Ein Messwert besteht aus mehreren Teilen, die im Einzelnen im folgenden Kapitel erläutert werden.
Nachstehende Graphik veranschaulicht die Informationseinheiten und deren Beziehung untereinander:
Endgeraet
Quelle n
id
sources
uptime
Quelle 1
id
description
type
status
refresh rate
measurement
Messdaten
Abbildung 7: Daten des mobilen Endgerätes
Diese Informationen werden im nachfolgenden Kapitel in XML-Schemata umgesetzt, welche dann als
Grundlage für XML-Dateien dienen, die die Messwerte der Datenquellen aufnehmen.
4.1.3 Anbieten der Daten
Nachdem ein mobiles Endgerät die Daten der Datenquellen aktualisiert und in Form von XMLDateien aufbereitet hat werden diese zum Zweck der persistenten Speicherung von einer Middleware
abgeholt. Im Rahmen der Kommunikation zwischen Middleware und Endgerät ist es notwendig, dass
ein mobiles Endgerät einer Middleware die Bereitschaft zur Kommunikation durch eine Anmeldung
mitteilt. Die Middleware kann anschließend die Aktualisierung der Daten koordinieren und in
entsprechenden Zeitabständen wiederholen. Im Rahmen einer Abmeldung kann die Bereitschaft zur
Seite 57
Web-Services zur Datenintegration mobiler Endgeräte
Kommunikation durch ein Endgerät wieder aufgehoben werden. Die Middleware beendet dann
jegliche Kommunikation bis zu einer weiteren Anmeldung.
Folgende Graphik veranschaulicht die Kommunikation, die zwischen Endgerät und Middleware
erfolgt:
Mobiles
Endgeraet
Anmelden (IP-Adresse,ID,”ME”)
Middleware
(Einmalig zu Beginn)
Abfrage der aktuellen Daten
(Regelmaessig je nach uptime)
Abmelden (IP-Adresse)
(Einmalig am Ende)
Abbildung 8: Kommunikation Mobiles Endgerät – Middleware
4.1.3.1 Anmeldung
Das mobile Endgerät meldet sich an einem Server (einer Middleware) an und übermittelt
Informationen, die für eine Kommunikation zwischen beiden Parteien nötig sind. Anschließend spricht
die Middleware das Endgerät in regelmäßigen Abständen an und bezieht die aktuellsten Daten, die
dann in einer Datenbank abgelegt werden können.
Während der Anmeldung ist es nötig, die Identifikation des Endgeräts zu übertragen. Die Middleware
kann das Endgerät anhand dieser Identifikation eindeutig identifizieren und eine eventuelle
Aktualisierung der Parameter durchführen. Des Weiteren wird die IP-Adresse übertragen, die ein
Ansprechen des Endgeräts ermöglicht. Der Typ des Endgeräts (im Falle eines mobilen Endgeräts
'ME') wird als weiterer Parameter bei der Anmeldung übertragen, um der Middleware mitzuteilen,
dass eine regelmäßige Aktualisierung der Daten des Endgeräts erfolgen soll.
Information
Beschreibung
ID
eindeutige Identifikation des Endgeräts
Typ (hier 'ME')
Typ des Endgeräts
IP-Adresse
IP-Adresse des Endgeräts
Tabelle 6: Informationen, die bei einer Anmeldung eines mobilen Endgeräts übertragen werden
Seite 58
Web-Services zur Datenintegration mobiler Endgeräte
Anzumerken ist, dass im Informationskreislauf nicht nur ein Server (also eine Middleware) existiert,
sondern möglicherweise mehrere Server, so dass ein Endgerät eine Konfiguration enthalten muss, die
eine Liste aller Server enthält, an denen eventuell eine Anmeldung zu erfolgen hat.
Information
IP-Adresse
Port
Beschreibung
IP-Adresse, mit der das Endgerät die Middleware
eindeutig ansprechen kann.
Nummer des Ports, an dem die Middleware
Anmeldungen entgegen nehmen kann.
Tabelle 7: Informationen über Middleware-Server
4.1.3.2 Regelmäßiges Abfragen der Daten
Ein mobiles Endgerät wird von der Middleware registriert, um eine Aktualisierung der Daten in
regelmäßigen Abständen zu ermöglichen. Für dieses Abfragen der aktuellen Daten stehen mehrere
mögliche Implementierungen zur Verfügung. Die theoretischen Grundlagen der einzelnen Techniken
wurden in Kapitel 2 vorgestellt, diese werden im Folgenden Auf Grundlage des vorliegenden Systems
bewertet.
XML und HTTP
Eine Möglichkeit, Daten über ein mobiles Endgerät anzubieten, stellt ein Zugriff auf XML-Dateien
über den Web-Server des entsprechenden Endgeräts dar. Die XML-Dateien, die die gesammelten
Daten in aufbereiteter Form enthalten, werden von einer Middleware über den Web-Server des
Endgeräts abgeholt. Der in dieser Arbeit verwendete Beck IPC ermöglicht den Einsatz dieser Lösung
aufgrund eines integrierten Web-Servers.
JINI
Der eingesetzte Beck Chip bietet keine vollständige Unterstützung der Programmiersprache Java. Die
für den Beck Chip eigens entwickelte Java Virtuelle Machine stellt nicht die vollständige Java
Funktionalität bereit. Gegenüber der Standard Java Version wurden einige Bibliotheken nicht
umgesetzt, die für allem für einen Einsatz von JINI nötig wären. Eine Lösung des Problems mittels
JINI ist somit mit der vorliegenden Hardware nicht möglich.
Web-Services
Um ein Abfragen der Daten mittels Web-Services zu ermöglichen, ist es nötig die Web-ServiceFunktionalität auf dem Beck Chip bereitzustellen. Zum einen ist es möglich unter Verwendung von
Bibliotheken1 die Funktionalität anzubieten. Es werden Web-Service-Bibliotheken angeboten, jedoch
1
für SOAP, XML Parser etc.
Seite 59
Web-Services zur Datenintegration mobiler Endgeräte
sind die Einschränkungen des IPC Chip hinsichtlich verfügbarem Speicher, aber vor allem wegen der
Vorraussetzung einer 16-bit-Entwicklung zu groß, so dass keine der verfügbaren Bibliotheken für die
vorliegende Umgebung genutzt werden kann. Eine Alternative wäre eine Entwicklung einer eigenen
Bibliothek, die eine entsprechende Funktionalität bereitstellt. Der zeitliche Rahmen der vorliegenden
Arbeit und der verfügbare Speicher erlauben diese Umsetzung jedoch nicht. Es besteht demzufolge
keine Möglichkeit, die Web-Service Funktionalität zu nutzen.
4.1.3.3 Abmelden
Nach der Anmeldung eines Endgeräts an einer Middleware wird das Endgerät registriert, um eine
regelmäßige Aktualisierung seiner Daten zu gewährleisten. Wird diese Aktualisierung nicht mehr
benötigt, teilt das Endgerät dies der Middleware mit, indem es eine Abmeldung durchführt. Die
Registrierung kann dann von der Middleware aufgehoben werden.
Zu diesem Zweck ist folgender zusätzlicher Eintrag in der Konfiguration notwendig:
Information
Beschreibung
Nummer des Ports an dem die Middleware
Port
Abmeldungen entgegen nehmen kann.
Tabelle 8: Abmelde-Informationen
4.1.4
Sicherheit
Der Zugriff auf den Datenbestand eines mobiles Endgeräts soll u.U. nur autorisierten ServerPlattformen erlaubt sein. Die Kommunikation zwischen Middleware und Endgerät wird dazu
verschlüsselt, so dass ein Abfangen der Daten keinen Nutzen für etwaige Angreifer hat. In einem
vorherigen Abschnitt wurde bereits auf die Notwendigkeit eingegangen, Informationen zu allen
angeschlossenen Middleware-Plattformen (IP-Adresse) lokal zu speichern, um eine Anmeldung des
mobilen Endgeräts an jedem Server zu ermöglichen. Diese Informationen können auch zur
Autorisierung genutzt werden. Bei einem Zugriff auf die Daten des mobilen Endgeräts erfolgt ein
Vergleich der IP-Adresse der Middleware, die eine Anforderung gestellt hat, mit den lokal abgelegten
Informationen aller autorisierten Middleware-Plattformen. Ist dieser Vergleich erfolgreich wird der
Server autorisiert, andernfalls wird der Zugang zu den Daten verwehrt. Angriffe mittels so genanntem
IP-Spoofing lassen sich dadurch zwar nicht unterbinden, aber die Restriktionen des Beck Chips
erlauben derzeit keine ausgefeilteren Mechanismen zur Autorisierung.
4.2 Daten-Server
In dieser Arbeit liegt das Hauptaugenmerk auf den mobilen Endgeräten. An dieser Stelle werden kurz
die für eine Integration der Daten-Server in das bestehende Konzept nötigen Anforderungen erläutert.
Seite 60
Web-Services zur Datenintegration mobiler Endgeräte
Die Daten der Daten-Server sind im Unterschied zu denen der mobilen Endgeräte statisch, müssen
also nicht erfasst werden; Änderungen werden von einer Person vorgenommen. Beispiele für solche
Daten sind Pläne, Skizzen oder ähnliches.
4.2.1 Informationen
Analog zu den mobilen Endgeräten müssen auch bei den Daten-Servern Informationen bezüglich der
angebotenen Daten verfügbar sein.
Die gröbste Einheit stellt wiederum der Server selbst dar, Informationen, die vorliegen müssen, sind:
Information
Typ
Beschreibung
id
String
gibt eine Identifikation für ein Endgerät an
number
Integer
Anzahl der Datenquellen
Tabelle 9: Informationen über einen Daten-Server
In der Tabelle wird die nächste Ebene deutlich: die Datenquelle. Diese muss folgende Informationen
enthalten:
Information
Häufigkeitsbeschränkung Typ
Beschreibung
gibt eine Identifikation für die
id
String
description
String
type
String
gibt den Typ der Datenquelle an
URL
verweist auf die Daten
measurement
1 ... n
Datenquelle an.
gibt eine allgemeine Beschreibung
der Datenquelle an
Tabelle 10: Informationen über die Datenquellen
4.2.2 Kommunikation Middleware – Daten-Server
Die Kommunikation zwischen einer Middleware und einem Daten-Servern läuft etwas anders ab als
die Kommunikation mit den mobilen Endgeräten. Folgende Graphik veranschaulicht die
Kommunikation:
Seite 61
Web-Services zur Datenintegration mobiler Endgeräte
Daten
Server
Middleware
Update (IP-Adresse, ID, ”DS”)
Abfrage der aktuellen Daten
Abbildung 9: Kommunikation Daten-Server - Middleware
Es findet jeweils eine Benachrichtigung der Middleware statt, falls aktuelle Daten verfügbar sind.
Diese Benachrichtigung wird analog zu einem Anmelde Vorgang eines mobilen Endgeräts
durchgeführt. Dabei wird jedes Mal die IP-Adresse, die Identifikation, sowie der Typ des Endgeräts
("DS" für einen Daten-Server) übertragen. Die Middleware kann anhand des Typs des Endgeräts
feststellen, ob eine Registrierung des Geräts nötig ist (um so eine Aktualisierung der Daten in
regelmäßigen Abständen vornehmen zu können). Da ein Daten-Server die Aktualisierung seiner Daten
an einer Middleware selbst anstößt, wird dieser nicht aktiv registriert.
Seitens eines Daten-Servers wird folgende Komponenten realisiert:
Update Komponente
Die Entwicklungsplattform kann frei gewählt werden, es muss allerdings eine Kommunikation mit den
Komponenten der Middleware möglich sein (über Socket-Schnittstellen)
4.2.3
Sicherheit
Analog zu den Sicherheitsanforderungen an ein mobiles Endgerät gelten identische Anforderungen für
einen Daten-Server. In den meisten Fällen kann die Sicherheit jedoch vollständig durch den WebServer des Daten-Servers übernommen werden. Viele Standard Web-Server bieten Autorisierungsund Authentisierungsmechanismen an, die bei Zugriff auf die Daten des Servers eine Überprüfung
vornehmen.
4.3 Middleware
Die Middleware koordiniert die regelmäßige Aktualisierung der Daten eines mobilen Endgeräts und
nimmt Aktualisierungsgesuche eines Daten-Servers entgegen. Die Daten werden in einer Datenbank
Seite 62
Web-Services zur Datenintegration mobiler Endgeräte
persistent abgelegt, um so einen dauerhaften Zugriff zu ermöglichen. Die gesammelten Daten werden
im Rahmen einer zu definierenden Schnittstelle über Web-Services den Clients zur Verfügung gestellt.
4.3.1 Persistente Speicherung der Daten (Kommunikation Middleware – mobiles
Endgerät)
Die persistente Speicherung der Daten wird in einer Datenbank vorgenommen. Die Anforderungen an
ein Datenbankschema lassen sich aus den Tabellen 3 und 4 ableiten. Ein mobiles Endgerät meldet sich
einmalig an einer Middleware an und wird dann in regelmäßigen Abständen abgefragt.
Folgende Phasen sollen seitens der Middleware (analog zu denen des mobilen Endgeräts) bereitgestellt
werden:
Meldet sich ein mobiles Endgerät an einer Middleware an, wird überprüft, ob bereits eine frühere
Anmeldung vorliegt. Ist dies der Fall, werden die Informationen zum Endgerät bei Bedarf aktualisiert.
Sollte es sich um eine erstmalige Anmeldung handeln, wird ein Eintrag in der Datenbank
vorgenommen. Zusätzlich werden sowohl bei Anmeldung als auch in der Phase der regelmäßigen
Abfrage die Sensordaten überprüft und aktualisiert.
Bei der Anmeldung werden die Endgeräte registriert, um dann eine Aktualisierung aller Daten an den
entsprechenden Zeitpunkten vorzunehmen.
Den Aktualisierungsvorgang kann ein Endgerät über den Abmeldevorgang beenden. Die Middleware
hebt die vorliegende Registrierung auf und löscht alle Registrierungseinträge.
Eine persistente Speicherung der Daten erfolgt in einer Datenbank, es werden Tabellen angelegt, die
alle nötigen Informationen zu den Endgeräten, den Datenquellen und den Messwerten bereitstellen.
Folgende Tabellen fassen die nötigen Anforderungen zusammen:
Information
IP-Adresse
Identifikation
uptime
Beschreibung
die Middleware kann mit der IP-Adresse das
Endgerät eindeutig ansprechen
eindeutige Identifikation des Endgeräts
gibt an in welchen zeitlichen Abständen das
Endgerät erreichbar ist
Tabelle 11: Anforderungen an ein Datenbankschema bezüglich des mobilen Endgeräts
Seite 63
Web-Services zur Datenintegration mobiler Endgeräte
Information
Typ
Identifikation
String
Endgerät
String
Beschreibung
String
Typ
String
Status
boolean
Refreshrate
Integer
Beschreibung
gibt eine Identifikation für die
Datenquelle an
Verweis auf das entsprechende
mobile Endgerät
gibt eine allgemeine Beschreibung
der Datenquelle an
gibt den Typ der Datenquelle an
gibt an, ob die Datenquelle aktiv ist
oder nicht
gibt die Abstände an, an denen die
Datenquelle aktualisiert wurde
Tabelle 12: Anforderungen an ein Datenbankschema bezüglich der Sensoren
Im Bezug auf ein Messergebnis kann es möglich sein, dass ein Sensor mehrere Werte liefert,
beispielsweise ein Windsensor kann die Windrichtung und die Windstärke liefern. Zu diesem Zweck
enthält folgende Tabelle eine Häufigkeitsbeschränkung, die für den Eintrag Messergebnis festlegt,
dass eventuell mehrere Einträge auftreten können.
Information
Häufigkeitsbeschränkung Typ
Quelle
String
Datum-Zeit
Timestamp
Messergebnis
1..n
eigener Typ
Beschreibung
Verweis auf die entsprechende
Datenquelle
Angabe eines Zeitstempels an dem
die Messergebnisse erfolgten
gibt den gemessenen Wert mit der
Messeinheit wieder
Tabelle 13: Anforderungen an ein Datenbankschema bezüglich der Messergebnisse
Diese Anforderungen werden in Kapitel 5 in ein reales Datenbankschema umgesetzt.
4.3.2
Client-Zugriff (Kommunikation Middleware - Client)
Der Datenbestand, der in den vorherigen Phasen durch die Kommunikation zwischen den Endgeräten
und einer Middleware aufgebaut wurde, wird Clients zur Verfügung gestellt.
Seite 64
Web-Services zur Datenintegration mobiler Endgeräte
Die Kommunikation zwischen beiden Parteien besteht aus zwei Bestandteilen:
Anfordern von Daten und
Positionsspezifisches Anbieten von Daten.
Im Unterkapitel 4.3.2.1 wird das Anfordern der Daten erläutert, anschließend wird das
"Positionspezifisches Anbieten von Informationen" in Kapitel 4.3.2.2 vorgestellt.
Neben diesen beiden Bestandteilen der Kommunikation ist der Aspekt der Sicherheit eine weitere
Anforderung an die Kommunikation.
4.3.2.1 Schnittstelle (Web-Services)
Die Kommunikation zwischen beiden Einheiten läuft allgemein und möglichst standardisiert ab, um so
einen schnellen und einfachen Zugriff auf den Datenbestand seitens der Clients zu ermöglichen.
Der Web-Service-Ansatz kann diese Anforderungen erfüllen. Die Daten werden über Web-Services
bereitgestellt, womit eine unkomplizierte Art des Zugriffs möglich wird. Im Bereich der Entwicklung
eines Clients ist bis auf zwei Aspekte völlige Entscheidungsfreiheit gegeben.
Da der Zugriff auf die Daten über Web-Services erfolgt, ist eine Unterstützung der Web-Services
absolut notwendig.
Zum anderen stellt ein Client (falls ein positionsspezifisches Anbieten von Daten seitens des Servers
möglich sein soll) die Möglichkeit bereit, Nachrichten von der Middleware entgegenzunehmen. Die
Art dieser Nachrichtenkommunikation wird in Kapitel 5 durch die Realisierung festgelegt.
Ein wichtiger Aspekt stellt die angebotene Schnittstelle dar. Ein Web-Service kann eine Reihe von
Parametern enthalten, die es einem Client ermöglichen, schnell auf die Daten zuzugreifen. Folgende
Informationen sind relevant:
Chip-ID,
Sensor-ID,
Zeitpunkt/Zeitraum,
Position und
Typ.
Seite 65
Web-Services zur Datenintegration mobiler Endgeräte
Eine Kombination obiger Informationen zu Parametern eines oder mehrerer Web-Services würde dann
Folgende Möglichkeiten liefern:
Abfragen der Daten eines Chips (aktuell/Zeitpunkt/Zeitraum)
Bsp.: Liefere alle Daten des Endgeräts wetterstation vom 1.8.2002 bis 1.9.2002
Abfragen der Daten eines Sensors (aktuell/Zeitpunkt/Zeitraum),
Bsp.: Liefere alle aktuellen Daten des Sensors temp1 des Chips wetterstation
räumliche Anfrage (aktuell/Zeitpunkt/Zeitraum)
Bsp.: Liefere alle Daten in der Umgebung (Positionsangabe) vom 1.9.2002
typbezogene Abfrage (verschiedene Kombinationen der Faktoren Position/Zeit)
Bsp.: Liefere alle Temperatur-Daten vom 1.9.2002
Bsp.: Liefere alle aktuellen Wind-Daten in der Umgebung (Positionsangabe)
Im Rahmen der Realisierung werden Web-Services bereitgestellt, die sinnvolle Kombinationen dieser
Informationen implementieren.
4.3.2.2 Positionsspezifisches Anbieten von Informationen
Es gibt zwei Möglichkeiten, ein positionsspezifisches Anbieten von Daten zu realisieren:
Realisierung durch die Middleware – Variante Middleware
Einerseits könnte die Middleware diesen Aspekt übernehmen und Clients, die entsprechende
Informationen wünschen, diese in regelmäßigen Abständen anbieten.
Folgende Realisierung wäre unter diesen Umständen denkbar:
Ein Client übermittelt bei seiner Anmeldung neben Informationen (wie etwa IP-Adresse und ID) seine
Position an die Middleware. Diese Position wird in regelmäßigen Abständen aktualisiert, so werden
auch mobile Clients ermöglicht.
Auf Basis einer Datenbanktabelle (die alle aktiven Clients enthält) erfolgt regelmäßig eine "räumliche
Nachbarschaftsanfrage". Es wird anhand der Client-Position ermittelt, ob dieser sich in räumlicher
Nachbarschaft (ermittelt durch einen zu spezifizierenden Radius) zu einem der mobilen Endgeräte
befindet. Ist dies der Fall, werden dem Client die Daten des Endgeräts mit einem Vermerk der
räumlichen Nachbarschaft angeboten. Es ist dem Client freigestellt, ob er die Daten annimmt oder aber
nicht. Diese Anfrage wird für alle in der Tabelle befindlichen Clients durchgeführt. Die
Kommunikation zwischen beiden Entitäten wird in folgender Graphik veranschaulicht:
Seite 66
Web-Services zur Datenintegration mobiler Endgeräte
Client
Anmelden (IP-Adresse,ID,Position)
Middleware
(Einmalig zu Beginn)
Anforderung von Daten
Bereitstellen der Daten
Anbieten von Daten (positionsbezogen)
Daten annehmen/ablehnen
Abmelden
(Einmalig am Ende)
Abbildung 10: Realisierung des "positionsspezifischen Anbietens" durch die Middleware
Folgende Aspekte müssten berücksichtigt werden:
Middleware:
Annehmen der Anmeldung und
Regelmäßiges Anbieten von Daten über eine Nachrichtenschnittstelle.
Client
Anmeldung an einer Middleware,
Implementierung einer Nachrichtenschnittstelle und
Verarbeiten der Daten.
Realisierung durch den Client – Variante Client
Das positionsspezifische Anbieten der Daten könnte auch seitens des Client realisiert werden,
korrekterweise müsste man dann von einem positionsspezifischen "Abholen" der Daten reden.
Folgende Realisierung wäre hier denkbar:
Der Client holt sich nach eigenen Wünschen die Daten zu den von ihm gewählten Zeitpunkten ab. Ein
Client kann eine eigene Positionsänderung wesentlich schneller feststellen als dies die Middleware
könnte, die erst über eine Anfrage an den Client die Position erhält. In der Middleware müsste eine
Schnittstelle realisiert werden, die ein Abholen von Daten ermöglicht. Es bedarf keiner weiteren
Implementierung, da diese Schnittstelle bereits vorhanden ist. In Kapitel 4.3.2.1 wurde eine
Schnittstelle vorgestellt, die es Clients ermöglicht Daten abzuholen. Von Interesse ist eine spezifische
Seite 67
Web-Services zur Datenintegration mobiler Endgeräte
Methode der Schnittstelle und zwar die räumliche Anfrage, die es ermöglicht, alle Daten in einer
Umgebung um einen bestimmten Punkt abzufragen.
Die Kommunikation zwischen beiden Einheiten wird in folgender Graphik veranschaulicht:
Middleware
Client
Anforderung von Daten
Bereitstellen der Daten
Abbildung 11: Realisierung des "positionsspezifischen Anbietens" durch den Client
Folgende Aspekte müssten berücksichtigt werden:
Middleware
Schnittstelle
Client
Abholen der Daten
Verarbeiten der Daten
Vergleich beider Möglichkeiten
Die Variante "Client" bietet eine Reihe von Vorteilen gegenüber der Variante "Middleware", vor allem
die Aspekte Aufwand, Komplexität und Freiheitsgrade sind bei der Realisierung durch den Client
positiv herauszustellen.
Aufwand
Der Aufwand der Realisierung würde in der Variante "Client" auf beiden Seiten (Middleware und
Client) geringer. Seitens der Middleware wäre keine weitere Implementierung nötig. Der Client
müsste gegenüber der ersten Lösung nur das Abholen der Daten bereitstellen, die Schnittstelle (WebServices) besteht bereits, und das Verarbeiten der Daten muss in beiden Varianten auf jeden Fall
erfolgen. Es besteht also kein direkter Mehraufwand für den Client.
Die Verringerung des Aufwands bedeutet aber auch eine Entlastung der Middleware, die weniger
Arbeit verrichtet. Da keine regelmäßige Übermittlung der Positionsangabe von einem mobilen
Seite 68
Web-Services zur Datenintegration mobiler Endgeräte
Endgerät an eine Middleware erfolgen muss, ist die Netzlast geringer. Darüber hinaus wird dadurch
auch die Middleware entlastet, die keine Verarbeitung dieser Angaben vornehmen muss.
Komplexität
Durch eine Verringerung des Aufwands kann auch eine Verringerung der Komplexität erreicht werden
(dies ist keine allgemeingültige Aussage, im vorliegenden Fall jedoch ist sie gültig). Wie schon oben
kurz erwähnt wurde, muss der Client das Abholen der Daten implementieren. Ein regelmäßiges
Abholen der Daten erfordert einen gewissen Aufwand und eine gewisse Komplexität, der einen
Vergleich zu der Variante Middleware bestehen muss. Es gilt hier das Gesamtkonzept zu betrachten,
also die Kombination von Middleware und Client. Das Abholen der Daten wurde bei der Variante
"Client", im Gegensatz zur Variante "Middleware" von der Middleware auf den Client ausgelagert, so
dass man in diesem Bereich von einer Umschichtung der Komplexität (die Komplexität dieses
Aspekts bleibt gleich) reden kann. Da aber gegenüber der Variante "Middleware" eine Realisierung
der Nachrichtenschnittstelle unnötig ist, ist die Komplexität der Variante "Client" in der Summe aller
Implementierungsaspekte geringer.
Freiheitsgrade in der Realisierung
Eine Realisierung der Variante "Middleware" würde den Client unnötig einschränken, da die
Zeitpunkte des Anbietens der Daten von der Middleware vorgegeben werden. Des Weiteren müsste
ein Client notwendigerweise eine bestimmte Nachrichtenschnittstelle (die seitens der Middleware
vorgegeben wird) bereitstellen.
Die Variante "Client" bietet wesentlich höhere Freiheitsgrade hinsichtlich der Realisierung eines
Clients, da als einzige Anforderung eine Unterstützung der Web-Service Schnittstelle nötig ist.
Entscheidung
Die oben beschriebenen Vorteile führen zu der Wahl die Realisierung mittels Variante "Client"
durchzuführen.
4.3.2.3 Sicherheit
Um den unerlaubten Zugriff auf die abgelegten Daten zu verhindern, werden gewisse
Sicherheitsanforderungen an die Kommunikation zwischen Client und Middleware gestellt. Es gelten
ähnliche Anforderungen wie auch für die Kommunikation zwischen Middleware und mobilem
Endgerät.
Der Informationsfluss wird verschlüsselt übertragen, um ein Abhören zu vermeiden. Etwaige
Spoofing-Angriffe werden im Rahmen einer Authentisierung durch Nachweis der Identität eines
Clients verhindert. Neben einer Authentisierung ist eine Autorisierung nötig, die sich mit der Frage
"Wer hat Zugriff auf welche Daten" beschäftigt. In diesem Zusammenhang wurden in Kapitel 2 bereits
mögliche Umsetzungen der Autorisierung besprochen. Das Problem der vorliegenden Mechanismen
Seite 69
Web-Services zur Datenintegration mobiler Endgeräte
ist allerdings eine Beschränkung der Autorisierung auf den Web-Service. Der Web-Service ist aber als
gewählte Komponente zu grob-granular, da keine Entscheidung bezüglich der einzelnen Daten
getroffen werden kann. In diesem Bereich ist die Umsetzung der so genannten "programmatic
security" [SunWt02] von Bedeutung. Ein Problem stellen Anforderungen dar, die eine Auswertung
außerhalb eines Web-Service nicht zulassen, diese werden also in den Web-Service eingelagert.
Auf Basis eines Nutzungsschemas kann eine solche Autorisierung erfolgen. Nach einer
Authentisierung wird anhand eines solchen Schemas überprüft, ob die Daten dem Benutzer zugänglich
sind und anschließend je nach Auswertung der Zugriff auf die Daten geregelt.
Angeforderte Daten können eventuell gegen Entgelt zur Verfügung gestellt werden. Dieser Dienst
erfolgt auf Basis der vorherigen Faktoren (Verschlüsselung, Authentisierung und Autorisierung), um
einen einwandfreien Betrieb zu ermöglichen. Neben einem Nutzungsschema, das eine Kosten-DatenZuordnung vornimmt, ist die Abwicklung des Zahlungsverkehrs von Bedeutung. Die Möglichkeiten
der Realisierung dieses Aspekts sind vielfältig.
4.4 Erweiterung der Anforderungen
Auf Grundlage vorhergender Beschreibungen kann aus FBAF2 eine weitere Entwurfsentscheidung
abgeleitet werden:
Entwurfsentscheidungen
Mobiles Endgerät
EE5
Die Daten werden in Form von XML-Dateien über
einen Web-Server angeboten
Die Benutzeranforderungen können nun zu entsprechenden Entwickleranforderungen erweitert
werden.
Seite 70
Web-Services zur Datenintegration mobiler Endgeräte
Funktionale Entwickleranforderungen
Mobiles Endgerät
FEA1
Sensordaten in regelmäßigen Abständen auslesen
FEA2
Aufbereiten der Daten in Form von XML-Dateien
FEA3
FEA4
Daten auf Web-Server in Form von XML-Dateien
ablegen
Anmelden an Middleware-Plattformen
Daten-Server
FEA3
FEA5
Daten auf Web-Server in Form von XML-Dateien
ablegen
Update der Daten anstoßen
Middleware
FEA6
Anmeldung der Endgeräte annehmen
FEA7
Abfragen der Sensordaten
FEA8
Einlagern der Daten in einer Datenbank
FEA9
Anbieten der Daten mittels Web-Services
FEA10
FEA11
Vielfältige Möglichkeiten des Zugriffs auf die Daten
mittels Web-Services ermöglichen
Verschlüsselung der Kommunikation durch Einsatz
von SSL
FEA12
Zugriff auf Daten nur nach Autorisierung
FEA13
Zugriff auf Daten nur nach Bezahlung
FEA14
Abmeldung eines Endgeräts annehmen
Die inversen Anforderungen werden direkt übernommen.
4.5 Verifikation Entwickleranforderungen Benutzeranforderungen
Folgende Tabelle stellt die Benutzeranforderungen den Entwickleranforderungen gegenüber, somit
kann ermittelt werden, ob alle Benutzeranforderungen umgesetzt worden sind. Des Weiteren wird eine
Verfolgbarkeit der einzelnen Anforderungen gewährleistet.
Seite 71
Web-Services zur Datenintegration mobiler Endgeräte
Benutzeranforderungen
Umgesetzt in Entwickleranforderung
FBA1
FEA1
FBA2
FEA2
FBA3
FEA3
FBA4
FEA3
FBA5
FEA7
FBA6
FEA8
FBA7
FEA9 (FEA10)
FBA8
FEA11
FBA9
FEA12
FBA10
FEA13
Die vorliegenden Entwickleranforderungen werden in Kapitel 5 in Komponentenbeschreibungen
umgesetzt. Auf Grundlage dieses Kapitels wird ein Gesamtbild des zu erstellenden Systems
hergeleitet, das dann in Kapitel 6 direkt in Code umgesetzt werden kann.
Seite 72
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 5: Realisierung
Realisierung der Anforderungen
Dieses Kapitel erläutert die Implementierung aller Aspekte, die in Kapitel 4 an das zu
implementierende System gestellt wurden. Analog zu Kapitel 4 werden auch hier drei Komponenten
unterschieden:
mobiles Endgerät/Daten Server,
Middleware und
Client
5.1 Mobiles Endgerät
Im vorherigen Kapitel wurden vier Anforderungen an ein mobiles Endgerät gestellt, deren
Implementierung im Folgenden besprochen wird. Im Bereich des Aufbereitens der Daten fließen
neben den Anforderungen an ein mobiles Endgerät auch die Anforderungen an einen Daten-Server
ein.
5.1.1 Erfassen der Daten
In diesem Abschnitt wird die Implementierung der Datenerfassung der Daten erläutert. Die Erfassung
der Daten bezieht das Aufbereiten der Daten mit ein, somit werden in einem Schritt die Messung der
Daten und ein lokales Ablegen der Daten in Form von XML-Dateien abgehandelt. Das folgende
Unterkapitel 5.1.2 beschäftigt sich mit dem Aussehen dieser XML-Dateien.
Die Implementierung basiert auf dem vorliegenden Hardware-Prototyp Beck Chip und berücksichtigt
dessen Einschränkungen hinsichtlich Speicherplatz und Entwicklungsumgebung (C/C++).
Das Erfassen der Daten beruht auf Dateien, die eine genaue Konfiguration der jeweiligen vorhandenen
Situation wiedergeben.
Für die Konfiguration des Beck Chip und seiner Sensoren müssen verschiedene Konfigurationsdateien
vorhanden sein, aus denen die korrespondierenden XML-Dateien erzeugt werden können. Diese
werden im Folgenden erläutert:
entity.ini
Jedes mobile Endgerät enthält eine solche Konfigurationsdatei, die allgemeine Informationen das
Endgerät betreffend wiedergibt.
Seite 73
Web-Services zur Datenintegration mobiler Endgeräte
Folgende Informationen sind enthalten:
Information
Beschreibung
ID
Identifikation des Endgeräts
NUMBER
Anzahl der Datenquellen
UPTIME
Zeitspanne, in der Aktualisierung erfolgt
GMT
Zeitzone relativ zu GMT
E-MAIL
E-Mail-Adresse des Administrators
TIMESERVER
Zeit-Server der zur Synchronisation der Zeit auf dem
SC12 verwendet werden kann.
Tabelle 14: entity.ini
sourcex.ini (x=1,…,NUMBER)
Zu jeder Datenquelle (Sensor) existiert eine sourcex.ini, die zum einen allgemeine Informationen
bezüglich der Quelle, zum anderen statische Informationen bezüglich der Messwerte (oder des
Messwerts) dieser Quelle enthält.
Information
Beschreibung
ID
Identifikation der Datenquelle
DESCRIPTION
Beschreibung der Datenquelle
STATUS
gibt an, ob die Datenquelle aktiv ist oder nicht
REFRESHRATE
Zeitspanne der Datenaktualisierung
NUMBER
Anzahl der zu speichernden Messergebnisse
Tabelle 15: Informationen zu einem Sensor in der sourcex.ini Datei
Information
Beschreibung
TYPE
Typ des Messwerts
DATATYPE
Datentyp des Messwerts
UNIT
Einheit des Messwerts
Tabelle 16: Informationen zu den Messwerten bezüglich eines Sensors in der sourcex.ini Datei
sourcepx.ini (x=1,…,NUMBER)
Zu jeder Datenquelle ist eine sourcepx.ini Datei vorhanden; der Nutzen dieser Datei wird im
folgenden Abschnitt erläutert.
Seite 74
Web-Services zur Datenintegration mobiler Endgeräte
Folgende Information ist enthalten:
Information
Beschreibung
ACTPOS
Position des nächsten zu ändernden Messwerts
Tabelle 17: Informationen zu dem nächsten zu ändernden Eintrag
Auf Grundlage dieser Dateien wird ein Programm erstellt, das ein regelmäßiges Messen und
Abspeichern der Daten erlaubt. Der Ablauf des Programms zur Erfassung und Aufbereitung der Daten
sieht wie folgt aus:
Seite 75
Web-Services zur Datenintegration mobiler Endgeräte
Abbildung 12: Ablauf des Messprogramms
Nach erfolgreicher Überprüfung der Konfigurationsdateien auf Fehler, werden die Daten des
Endgeräts, sowie die Daten der einzelnen Sensoren gelesen und in Form von XML-Dateien für den
Zugriff über den Web-Server abgelegt.
Nach dieser Initialisierungsphase, die einmalig zu Beginn ausgeführt wird, startet die Messphase, die
wiederholt in regelmäßigen Abständen durchlaufen wird. Während der Messphase werden die
eigentlichen Messergebnisse in Form von XML-Dateien erzeugt. Eine XML-Datei soll eine gewisse
Seite 76
Web-Services zur Datenintegration mobiler Endgeräte
Anzahl an Messergebnissen lokal auf einem Chip halten können. Diese Anzahl muss im Hinblick auf
den zu Verfügung stehenden Speicher festgelegt werden, um etwaige Probleme zu vermeiden. Dazu
werden die Ergebnisse mittels einer FIFO-Strategie (First-In-First-Out) verwaltet. Das jeweils älteste
Element (von der maximal möglichen Anzahl an zu speichernden Elementen) wird durch einen
neueren Wert ersetzt. Zu diesem Zweck wird die Datei sourcepx.ini für jeden Sensor benötigt. Diese
enthält einen Verweis auf das nächste zu ändernde Element innerhalb der Messwerte. Nach dem
Verarbeiten der alten XML-Datei wird die Position des nächsten zu ändernden Eintrags ermittelt. Der
entsprechende Messwerte wird aktualisiert und die XML-Datei wird gespeichert.
Vom Endgerät werden Vorkehrungen innerhalb des Messprogramms getroffen, welche fehlerhafte
Daten und fehlerhafte Konfigurationen erkennen. Da es nicht möglich ist, diese Fehler automatisch zu
beheben, wird das Programm bei Feststellen eines Fehlers beendet und der Benutzer (in diesem Fall
der Systemadministrator) aufgefordert, den entsprechenden Fehler zu korrigieren.
Bei einem Daten-Server sieht dies anders aus: Da die Daten nicht gemessen werden, sondern durch
den Benutzer veröffentlicht werden, kann es hier leicht zu fehlerhaften XML-Dateien kommen. Es
wird aus diesem Grund eine weitere Fehlerüberprüfung von der Middleware beim Abruf der Daten
durchgeführt. Die Beschreibung dieser Überprüfung wird im Abschnitt über die Middleware
durchgeführt.
5.1.2 Aufbereiten der Daten
Das Aufbereiten der Daten erfolgt in Form von XML-Dateien, die gewisse Informationen enthalten
(siehe hierzu Tabelle 4 und Tabelle 5 in Kapitel 4). Die Informationen bezüglich mobiler Endgeräte
und Daten-Servern werden in einem einheitlichen XML-Schema zusammengetragen, so dass eine
Verarbeitung in ähnlicher Form möglich ist.
Im Folgenden werden die XML-Schemata sowie beispielhafte XML-Dokumente erläutert. Die gröbste
Einheit ist eine entity, welche die Information der Endgeräte abbildet, die nächste Ebene ist eine
source, welche die Datenquellen widerspiegelt. An dieser Stelle wird darauf hingewiesen, dass
einige Attribute nur auf ein mobiles Endgerät zutreffen, allerdings auch bei Daten-Servern, aufgrund
der Korrektheit eines XML-Dokuments angegeben werden müssen, können aber auf den Wert 0
gesetzt werden.
Bevor die Schemata vorgestellt werden, wird eine Information noch weiter im Detail charakterisiert:
das Messergebnis (der Messwert), also die eigentlichen Daten. Diese wurde in den bisherigen
Anforderungen (siehe Tabelle) als eigener Typ charakterisiert.
Seite 77
Web-Services zur Datenintegration mobiler Endgeräte
Nun wird festgelegt, welche Informationen dieser eigene Typ enthält:
Information
Typ
Beschreibung
type
String
datatype
String
gibt den Datentyp des Messwerts an
unit
String
gibt die Einheit des Messwerts an
datetime
date
position
String
gibt eine Typenidentifikation den
Messwert betreffend an
gibt einen Zeitstempel an, zu dem die
Messung erfolgte
aktuelle GPS Position, an der der Wert
gemessen wurde
Tabelle 18: benötigte Informationen bezüglich eines Messwerts
Diese Informationen werden in ein XML-Schema sowie in ein Tabellen-Schema für die Datenbank
der Middleware umgesetzt.
Folgend werden die XML-Schemata der einzelnen Komponenten Endgerät, Datenquelle und
Messwert vorgestellt und jeweils anhand eines Beispiels (in Form einer XML-Datei, die eine Instanz
des entsprechenden Schemas darstellt) konkretisiert.
5.1.2.1 Endgerät
Das Schema für ein mobiles Endgerät sieht wie folgt aus:
entity.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="entity">
<xs:annotation>
<xs:documentation>Entity repraesentiert eine mob. Endgeraet oder einen DatenServer</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="id" type="xs:string"/>
<xs:element name="uptime" type="xs:int"/>
<xs:element name="number" type="xs:int"/>
<xs:element name="email" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Seite 78
Web-Services zur Datenintegration mobiler Endgeräte
Im folgenden Beispiel hat das mobile Endgerät "mobile1" drei Sensoren und liefert innerhalb von 30
Sekunden neue Daten.
entity.xml
<?xml version="1.0" encoding="UTF-8"?>
<entity xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://www.icsy.de/xml/entity.xsd">
<id>mobile1</id>
<uptime>30</uptime>
<number>3</number>
<email>[email protected]</email>
</entity>
Beispiel 16: Instanz des XML-Schemas entity
5.1.2.2 Datenquelle
Das Schema für eine Datenquelle (z.B. einen Sensor) sieht folgendermaßen aus:
source.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="source">
<xs:annotation>
<xs:documentation>beschreibt einen Sensor</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="id" type="xs:string"/>
<xs:element name="description" type="xs:string"/>
<xs:element name="status" type="xs:boolean"/>
<xs:element name="refreshrate" type="xs:int"/>
<xs:element name="measurement" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Ein Windsensor "wind1", dessen Messwerte in der Datei "meas3.xml" abgelegt sind und der alle 30
Sekunden neue Werte zur Verfügung stellt, wird wie folgt angegeben:
sensor1.xml
<?xml version="1.0" encoding="UTF-8"?>
<source xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://www.icsy.de/xml/source.xsd">
<id>wind1</id>
<description>Wind Sensor</description>
Seite 79
Web-Services zur Datenintegration mobiler Endgeräte
<status>1</status>
<refreshrate>30</refreshrate>
<measurement>MEAS3.XML</measurement>
</source>
Beispiel 17: Instanz des XML-Schemas source
5.1.2.3 Messwerte
Das Schema für die Messwerte wird folgendermaßen dargestellt:
measurement.xsd
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v4.4 U (http://www.xmlspy.com) by AG ICSY (FB
Informatik) -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="measurements">
<xs:annotation>
<xs:documentation>alle Messwerte</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="entry" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="measurement" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string"/>
<xs:attribute name="datatype" type="xs:string"/>
<xs:attribute name="unit" type="xs:string"/>
<xs:attribute name="datetime"
type="xs:dateTime"/>
<xs:attribute name="position" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
Im Folgenden wird eine Instanz eines solchen Schemas dargestellt. Es werden jeweils drei Messwerte
eines Windsensors im Rahmen der XML-Datei abgelegt. Jeder dieser Messwerte (Einträge) besteht
aus zwei Teilen, der Windstärke und der Windrichtung.
Seite 80
Web-Services zur Datenintegration mobiler Endgeräte
meas.xml
<?xml version="1.0" encoding="UTF-8"?>
<measurements xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://www.icsy.de/xml/measurement.xsd"
>
<entry>
<measurement type="Staerke" datatype="INT" unit="km/h"
datetime="2002-10-30 16:4:22" position="$GPGGA...*73">
22
</measurement>
<measurement type="Richtung" datatype="STRING" unit="richtung"
datetime="2002-10-30 16:4:23" position="$GPGGA...*73">
31
</measurement>
</entry>
<entry>
<measurement type="Staerke" datatype="INT" unit="km/h"
datetime="2002-10-30 15:45:14" position="$GPGGA...*73">
22
</measurement>
<measurement type="Richtung" datatype="STRING" unit="richtung"
datetime="2002-10-30 15:45:14" position="$GPGGA...*73">
31
</measurement>
</entry>
<entry>
<measurement type="Staerke" datatype="INT" unit="km/h"
datetime="2002-10-30 16:3:50" position="$GPGGA...*73">
10
</measurement>
<measurement type="Richtung" datatype="STRING" unit="richtung"
datetime="2002-10-30 16:3:50" position="$GPGGA...*73">
1
</measurement>
</entry>
</measurements>
Beispiel 18: Instanz des XML-Schemas measurement1
1
Zur besseren Übersicht wurden die GPS-Strings jeweils in gekürzter Fassung dargestellt. Ein GPS String sieht
beispielhaft wie folgt aus: $GPGGA,180432.00,4927.000000,N,0744.000000,E,1,05,1.0,210.00,M,31.81,M,4.2,0555*73
Seite 81
Web-Services zur Datenintegration mobiler Endgeräte
5.1.3
Anbieten der Daten
Das Messprogramm ermittelt die aktualisierten Werte und legt diese in XML-Dateien ab. Um ein
Verarbeiten der Daten zu ermöglichen, wurden in Kapitel 4 drei mögliche Realisierungsalternativen
vorgestellt: Web-Services, JINI und XML/HTTP. XML/HTTP stellt die zurzeit einzig mögliche
realisierbare Alternative auf dem Beck Chip dar. Das Anbieten der Daten erfolgt also über den WebServer des jeweiligen Endgeräts. Die XML-Dateien werden vom Messprogramm auf dem Web-Server
abgelegt, somit sind diese direkt für Middleware Plattformen verfügbar. Eine erstmalige Verarbeitung
der Dateien erfolgt nach Anmeldung eines Endgerät an einer Middleware, so wird die Bereitschaft zur
Kommunikation mitgeteilt.
5.1.3.1 Anmeldung
Diese Software-Komponente des mobilen Endgeräts führt eine Anmeldung bei allen Servern aus, die
einen entsprechenden Eintrag in der middle.ini Konfigurationsdatei vorweisen. Die middle.ini enthält
für jede Middleware folgende Einträge:
Information
Beschreibung
IPADDRESS
IP-Adresse der Middleware
ONPORT
OFFPORT
Port der Middleware an dem Anmeldungen
angenommen werden.
Port der Middleware an dem Abmeldungen
angenommen werden.
Tabelle 19: Informationen der middle.ini Konfigurationsdatei
5.1.3.2 Abmeldung
Um die Registrierung und somit die regelmäßige Aktualisierung der Daten zu beenden, wird eine
Abmeldung an allen genutzten Middleware-Plattformen durchgeführt. Die Middleware-Plattform
beendet nach einem Abmeldegesuch jegliche Kommunikation mit dem Endgerät bis zu einer erneuten
Anmeldung durch dieses.
5.1.4
Sicherheit
Die Sicherheitsanforderungen bezüglich eines Chips verlangen eine verschlüsselte Kommunikation
mit den Middleware-Plattformen, sowie einen autorisierten/authentisierten Zugriff diese Middleware
Plattformen.
Da die Daten über den Web-Server angeboten werden, müsste der Web-Server eine verschlüsselte
Kommunikation (beispielsweise) über SSL unterstützen. Der zum Standardumfang des Beck SC12
gehörende Web-Server unterstützt diese Möglichkeit jedoch nicht.
Seite 82
Web-Services zur Datenintegration mobiler Endgeräte
Ein Mini-Web-Server (der SSL unterstützt) wurde im Rahmen einer Diplomarbeit [ZiLeDA00],
[ZiLePa00] angefertigt. Eine Anfrage an den Autor zur Nutzung blieb aber bislang ohne Erfolg. Auf
Grundlage dieser Informationen wurden weitere Überlegungen im Bereich Sicherheit angestellt, die
vor allem die Autorisierung und die Authentisierung betreffen. Verschiedene Ansatzmöglichkeiten
resultieren aus diesen Überlegungen:
5.1.4.1 Lösung 1: Implementierung der Autorisierung /Authentisierung unabhängig von der
Verschlüsselung
Diese Lösung ist unabhängig von dem Aspekt der Verschlüsselung erstellt worden und basiert auf dem
eingesetzten Web-Server von Beck.
Folgende Graphik veranschaulicht die Autorisierung/Authentisierung eines Middleware-Servers bei
Zugriff auf Daten eines mobilen Endgeräts:
Mobiles
Endgeraet
Middleware
Komponente
Update
Zugriff auf Webserver (Datenabruf)
Webserver
Daten bereitstellen
(nach erfolgreicher
Kontrolle)
Zugriff
pruefen
Anfrage an Middleware
Komponente
Sicherheit
Sicherheitsmodul
Zugriffsberechtigung uebermitteln
Zugriffsberechtigung
mit vorhandener
Berechtigung
vergleichen
Konfigurations
datei
Abbildung 13: Interaktion mobiles Endgerät - Middleware zur Kontrolle der Sicherheit
Beim Zugriff auf den Web-Server erfolgt ein interner Methodenaufruf, der als Parameter unter
anderem die IP-Adresse des Servers enthält, der einen Zugriff auf die Daten wünscht.
Anschließend erfolgt eine Authentisierung/Autorisierung der Middleware in folgenden Schritten:
Seite 83
Web-Services zur Datenintegration mobiler Endgeräte
IP-Adresse in middle.ini enthalten?
Nein: Zugriff verweigern (unberechtigter Zugriff)
Ja: Gesuch an die Middleware (Sicherheitskomponente) übermitteln und auf Antwort
warten
Antwort (Zugriffsberechtigung) vergleichen mit vorhandener Berechtigung in
entsprechender
Konfigurationsdatei
für
die
spezifizierte
IP-Adresse.
Sind
Berechtigungen identisch?
Nein: Zugriff verweigern (unberechtigter Zugriff)
Ja: Zugriff gestatten
Das Problem dieser Lösung liegt eben in der unabhängigen Betrachtungsweise. Da völlig vom Aspekt
der Verschlüsselung abstrahiert wird, könnte diese Lösung eventuell Inkompatibilitäten erzeugen.
Wird der Aspekt der Verschlüsselung beispielsweise über den oben erwähnten Mini-Web-Server
realisiert, könnte es passieren, dass die beiden eingesetzten Komponenten inkompatibel sind und somit
die erforderliche Funktionalität nicht bereitstellen können. Eine Implementierung dieser Lösung wäre
somit eventuell unnötig. Wichtig ist jedoch, dass diese Lösung eine Komponente Sicherheit von der
Middleware erfordert, die eventuelle Gesuche wie oben beschrieben verarbeiten kann.
5.1.4.2 Lösung 2: Implementierung eines eigenen Web-Servers
Eine weitere denkbare Lösung wäre die Implementierung eines Web-Servers, der alle
Sicherheitsanforderungen erfüllen kann. Alle Inkompatibilitäten wären somit ausgeschlossen und eine
einwandfreie und sichere Umgebung könnte gewährleistet werden. Diese Lösung erfordert keine
weiteren Komponenten seitens der Middleware.
5.2 Daten-Server
Ein Daten-Server verwaltet analog zu einem mobilen Endgerät XML-Dateien, die über einen WebServer bereitgestellt werden.
Es gilt nur eine Kommunikation zu realisieren, die vom Benutzer angestoßen werden kann, sobald
eine Aktualisierung der Daten auf dem Server erfolgt ist.
Sicherheitsaspekte werden, wie schon erwähnt, auf den Web-Server ausgelagert, der die Autorisierung
und Authentisierung übernimmt.
Ein Daten-Server benötigt zum einen die Angabe einer Konfigurationsdatei (im Rahmen der
vorliegenden Implementierung, der MIDDLE.INI), um ein Update an den entsprechenden Plattformen
durchführen zu können, zum anderen wird bei der Kommunikation mit einer Middleware Plattform,
die Identifikation des Endgeräts übermittelt.
Seite 84
Web-Services zur Datenintegration mobiler Endgeräte
Update der Daten
Ein Update der Daten eines Daten-Servers erfolgt nur auf dessen Wunsch. Der Daten-Server stößt den
entsprechenden Vorgang in der Middleware an. Die Kommunikation zwischen Daten-Server und
Middleware erfolgt analog zu der Kommunikation zwischen mobilem Endgerät und Middleware beim
Anmeldevorgang über eine Socket-Kommunikation.
Die zu verwendende Programmiersprache kann völlig unabhängig gewählt werden, diese muss nur
eine Socket-Kommunikation gewährleisten. Im Rahmen vorliegender Arbeit wird folgender Ansatz
gewählt:
Ein Daten-Server beinhaltet immer einen Web-Server, über den die Daten angeboten werden. Es ist
somit möglich ein CGI-Programm (bei geeigneter Unterstützung durch den Web-Server) zu erstellen,
das über den Web-Server aufgerufen werden kann und den entsprechenden Update-Vorgang auslöst.
Es ist aber ebenfalls möglich, ein entsprechendes (Java-) Programm zu erstellen, das die gleiche
Funktionalität bereitstellt.
Wenn möglich, sollte dieses Anmeldemodul bereits eine Konsistenzüberprüfung der Daten beim
Daten-Server vornehmen. Die Fehlerüberprüfung wird zwar ebenfalls von der Middleware
vorgenommen, so könnte aber eine unnötige Kommunikation vermieden werden und zusätzliche
Sicherheit bezüglich Konsistenz und Korrektheit der Daten eingeführt werden.
5.3 Middleware
Die Anforderungen an die Middleware werden durch verschiedene Komponenten realisiert, die
parallel ausgeführt werden. Es werden drei Bereiche unterschieden, in denen verschiedene
Komponenten zur Realisierung der gestellten Anforderungen nötig sind:
mobiles Endgerät/Daten-Server,
Datenverwaltung und
Client
Der Bereich des mobilen Endgeräts/Daten-Servers beschäftigt sich dabei mit der Annahme von
Anmeldungen der Endgeräte. Notwendig ist hier die Realisierung folgender Komponenten:
Anmeldung,
Abmeldung,
Registrierung und
(Sicherheit)
Seite 85
Web-Services zur Datenintegration mobiler Endgeräte
Die Komponente Sicherheit muss nur in dem Fall realisiert werden, in dem eine Realisierung des in
Abschnitt 5.1.4.1 besprochenen Sicherheitskonzepts erfolgt.
Der Bereich der Datenverwaltung beschäftigt sich mit dem Abruf und der Verarbeitung der Daten der
mobilen Endgeräte sowie der Daten-Server, wobei folgende Komponente zu realisieren ist:
Update
Es müssen Anfragen des Client an den Datenbestand abgewickelt werden können. Folgende
Komponente muss realisiert werden:
Verwaltung
Diese Softwarekomponenten werden nachfolgend erläutert, davor sei darauf hingewiesen, dass die
Verwaltung des Datenbestandes sowie ein Teil der Kommunikation zwischen obigen Komponenten
auf Basis von Datenbanktabellen erfolgt, die Anforderungen an ein Datenbankschema wurden in
vorherigem Kapitel angeführt (siehe hierzu Tabelle 11, Tabelle 12 und Tabelle 13). Das folgende
Kapitel erläutert in einem ersten Schritt die zu implementierenden Komponenten. Diese werden
anhand von Flussdiagrammen vorgestellt. In diesen Implementierungen wird Bezug auf
Datenbanktabellen sowie darin enthaltene Attribute genommen. Neben bereits bekannten
Informationen (aus den oben angeführten Tabellen) werden weitere Attribute aufgeführt, deren
Einführung zum Zeitpunkt der Anforderungsrealisierung noch nicht bekannt war. Es handelt sich um
zusätzliche Entscheidungen, die zum Zeitpunkt der Implementierung relevant geworden sind. Das
Datenbankschema, also alle zu erstellenden Datenbanktabellen inklusive deren Attribute, wird im
Anschluss an die Komponentenbeschreibungen angeführt und erläutert.
In einem weiteren Abschnitt wird dann explizit der Bereich der Web-Services behandelt. Da die WebServices eine elementare Schnittstelle darstellen, werden diese gesondert besprochen.
5.3.1
Komponenten
5.3.1.1 Komponente "Anmeldung"
Diese Komponente wartet auf Anmeldungsgesuche von mobilen Endgeräten oder Update-Anfragen
eines Daten-Servers. Eine Anmeldung eines mobilen Endgeräts löst eine Registrierung des Endgeräts
aus. Die Komponente "Registrierung" übernimmt dann alle weiteren Koordinationsschritte. Sollte es
sich bei dem Gesuch um ein Aktualisierungsanfrage eines Daten-Servers handeln, wird die
Komponente "Update" angesprochen, die alle weiteren Schritte übernimmt.
Folgendes Diagramm veranschaulicht die Komponente "Anmeldung":
Seite 86
Web-Services zur Datenintegration mobiler Endgeräte
Abbildung 14: Ablauf der Komponente Anmeldung
5.3.1.2 Komponente "Abmeldung"
Die Komponente "Abmeldung" dient dazu, die Registrierung eines mobilen Endgeräts rückgängig zu
machen. Mittels der Identifikation des Endgeräts wird ermittelt, ob das Endgerät angemeldet ist, um
dann eine Abmeldung durchzuführen. Daten-Server werden von der Komponente Abmeldung nicht
berücksichtigt, da keine Registrierung während der Anmeldung erfolgt.
Folgend wird der Ablauf skizziert:
Seite 87
Web-Services zur Datenintegration mobiler Endgeräte
Abbildung 15: Ablauf der Komponente Abmeldung
5.3.1.3 Komponente "Registrierung"
Die Komponente "Registrierung" übernimmt die Koordination der regelmäßigen Aktualisierung der
Daten eines Endgeräts. Ein Bestandteil dieser Komponente ist die Aktualisierung der Daten, die an die
Komponente "Update" delegiert wird. Nach der Aktualisierung erfolgt eine Überprüfung des Status
der Aktualisierung. Sollte ein Fehler aufgetreten sein, wird dieser vermerkt. Treten wiederholt Fehler
bei der Aktualisierung eines Endgeräts auf (Überschreiten eines Schwellwerts), wird die Registrierung
des Endgeräts aufgehoben, die Aktualisierung der Daten beendet und eine Nachricht an einen
Administrator gesendet. Verlief die Überprüfung des Aktualisierungsvorgangs erfolgreich, wird die
Kommunikation für die angegebene Zeitspanne ausgesetzt. Der Ablauf der Komponente sieht wie
folgt aus:
Seite 88
Web-Services zur Datenintegration mobiler Endgeräte
Abbildung 16: Ablauf der Komponente Registrierung
Seite 89
Web-Services zur Datenintegration mobiler Endgeräte
5.3.1.4 Komponente "Update"
Die Komponente "Update" dient dazu, den eigentlichen Aktualisierungsvorgang der Daten
vorzunehmen. Durch Angabe einer IP-Adresse können die Daten eines Endgeräts abgeholt, verarbeitet
und in die Datenbank eingetragen werden.
Die Komponente "Update" wird von den Komponenten Anmeldung und Registrierung aufgerufen, sie
muss demzufolge eine Schnittstelle zur Verfügung stellen, welche den Bedürfnissen dieser
Komponenten entspricht.
Folgende Möglichkeiten müssen zur Verfügung stehen:
Daten eines Endgeräts aktualisieren,
Überprüfen ob Endgerät registriert ist,
Endgerät registrieren und
Registrierung eines Endgeräts aufheben und
Folgende Funktionen werden erstellt, um diesen Anforderungen zu genügen:
Funktion" isRegistered"
Diese Funktion ermittelt durch Überprüfen der Datenbank, ob eine Registrierung des Endgeräts
vorliegt.
Funktion " unregisterEntity"
Diese Funktion hebt die Registrierung eines Endgeräts in der Datenbank auf. Anzumerken ist hier,
dass es sich nur um den Registrierungseintrag in der Datenbank handelt, die eigentliche Registrierung
im Gesamtsystem wird durch die Komponente Registrierung verwaltet.
Funktion " updateData"
Die Funktion "updateData" realisiert eine Aktualisierung der Daten eines Endgeräts. Des Weiteren
wird die Anforderung der Registrierung eines Endgeräts ebenfalls durch diese Komponente gelöst.
Folgendes Diagramm erläutert den Ablauf der Subkomponente:
Seite 90
Web-Services zur Datenintegration mobiler Endgeräte
Abbildung 17: Ablauf der Funktion "UpdateData"
Seite 91
Web-Services zur Datenintegration mobiler Endgeräte
Datenbankschema
Die Komponente "Update" greift auf Datenbanktabellen zurück, um Informationen abzulegen und zu
verarbeiten. Das eigentliche Datenbankschema wird am Ende dieses Kapitels vorgestellt, es soll an
dieser Stelle nur erläutert werden, welche Informationen im Rahmen der Komponente "Update" zur
Verfügung stehen müssen. Neben den Daten, die bezüglich eines Endgeräts abgelegt werden (die
Anforderungen wurden im vorherigen Kapitel bereits strukturiert), ist an dieser Stelle eine weitere
Tabelle nötig, um die Registrierung eines Endgeräts zu verwalten. Diese Tabelle benötigt drei
Informationen, zum einen die IP-Adresse, dann die Identifikation des Geräts, sowie die Zeitspanne, in
der eine Aktualisierung nötig ist.
Fehlervermeidung
Abbildung 17: Ablauf der Funktion "UpdateData" enthält zwei Aktivitäten:
Überprüfe Daten des Endgeräts
Melde Statusinformationen
Diese Aktivitäten dienen der Fehlervermeidung. Innerhalb der Aktivität "Überprüfe Daten" werden
alle Daten des Endgeräts auf Konsistenz und Korrektheit überprüft. Daneben werden auch die Struktur
der XML-Dateien und die Erreichbarkeit des Endgeräts überprüft. Im Rahmen dieser Aktivität werden
dreistellige Statuscodes generiert und als Statusinformation ausgegeben.
In Anhang B befindet sich eine Tabelle, die alle möglichen Statuscodes und deren Bedeutung
zusammenfasst (Tabelle 30: Statuscodes der Middleware).
Erläuterungen zur Datenbank
Bei der Datenbank besteht das Problem, dass der zurzeit verwendete JDBC Treiber1 die SQL States
nicht zurückliefert und somit keine weitere Unterscheidung vorgenommen werden kann. In diesem
Bereich wird die Datenbankfehlernachricht direkt übermittelt.
Es ist natürlich unerlässlich, dass die entsprechenden Informationen an das mobile Endgerät
übertragen werden. Das Problem ist allerdings, dass keine entsprechenden Nachrichtenschnittstellen
vorhanden sind, um eine dementsprechende Kommunikation zu vollziehen. Folgende Art der
Benachrichtigung wird deshalb verwendet:
Sollte ein Fehler vorliegen, wird eine E-Mail-Nachricht an den (konfigurierbaren) Administrator des
Endgeräts und ebenfalls an den Administrator der Middleware gesandt. Diese Nachricht enthält die
nötigen Informationen zur Behebung des Problems.
1
Version PostgreSQL 7.3 JDBC 3
Seite 92
Web-Services zur Datenintegration mobiler Endgeräte
Fehlerbehandlung
Neben der Benachrichtigung des Administrators des Endgeräts ist natürlich ein Vorgehen seitens der
Middleware erforderlich. Es ist zu entscheiden, ob alle Daten bezüglich eines Endgeräts verworfen
werden oder nur Teile. Es wird nun die Granularität der Datenakzeptanz in den einzelnen
Fehlersituationen geschildert. Drei Maßnahmen können unterschieden werden:
Alle Daten werden verworfen
Es ist ein Problem aufgetreten, welches es unmöglich macht, die Daten zu akzeptieren. Auch wenn
alle weiteren Daten (der Quellen) korrekt sind, so ist eine Inkonsistenz festgestellt worden, welche die
Datenbank trotz Einlagerung der restlichen korrekten Daten in einen inkonsistenten Zustand versetzen
würde.
Daten der Quelle werden verworfen
Die Daten einer Quelle können nicht akzeptiert werden, da ansonsten eine unvollständige
Kombination Messwert-Quellinformation in der Datenbank eingefügt werden würde; dies würde einen
inkonsistenten Zustand der Datenbank zur Folge haben.
korrekte Daten werden angenommen
Alle Daten, die korrekt sind, werden angenommen. Dieser Fehler führt nicht zu Problemen in der
Datenbank, die korrekte Funktionsweise der Middleware ist weiterhin gewährleistet.
Falls ein Endgerät eine erstmalige Anmeldung durchführt und alle Sensoren abgelehnt werden, könnte
es passieren, dass ein verwaister Eintrag in der Datenbanktabelle vorliegt. Analog kann dies für einen
Sensor bei Ablehnung aller Messergebnisse passieren. Abbildung 17 enthält zu diesem Zweck zwei
Überprüfungen auf verwaiste Einträge, die diese bei Bedarf entfernen.
In Anhang B befindet sich eine Tabelle, die eine Abbildung aller möglichen Situationen zu der jeweils
zu treffenden Maßnahme enthält (Tabelle 31).
Seite 93
Web-Services zur Datenintegration mobiler Endgeräte
Erläuterungen zu den Messwerten:
Zu einem Messwert müssen die folgenden Attribute korrekt sein, da es andernfalls auf Seiten der
Web-Service-Funktionalität zu Fehlern kommen kann:
Type,
Datatype,
Unit,
Datetime,
Wert und
GPS Position.
5.3.1.5 Komponente "Sicherheit"
Diese Komponente wird erforderlich, wenn die Sicherheitsaspekte eines mobilen Endgeräts wie in
Abschnitt 5.1.4.1 beschrieben ablaufen sollen. Diese Komponente dient nur der Umsetzung der
Sicherheitsaspekte zwischen Middleware und Endgerät. Die Sicherheitsanforderungen die zwischen
Client und Middleware umgesetzt werden müssen, werden in Abschnitt 5.3.2 erläutert.
Die Komponente" Sicherheit" übernimmt die Autorisierung/Authentisierung der Middleware an einem
mobilen Endgeräts. Es müssen Gesuche seitens mobiler Endgeräte entgegengenommen werden. Die
Update-Komponente versucht auf den Web-Server eines mobilen Endgeräts zuzugreifen. Der Zugriff
erfolgt nur für zugriffsberechtigte Server. Diese Zugriffsberechtigung wird durch die Komponente
"Sicherheit" erteilt.
Annahme von Gesuchen seitens mobiler Endgeräte:
Bei Zugriff
überprüfe ob IP-Adresse der Middleware in Tabelle Update enthalten ist
Ja, übermittle die Zugriffsberechtigung an das mobile Endgerät
Nein, übermittle eine leere Zugriffsberechtigung (Zugriff findet nicht statt) potentieller Angriff mittels Täuschungsversuch.
5.3.1.6 Komponente "Verwaltung"
Die bisherigen Komponenten realisieren die Kommunikation zwischen Middleware und Endgerät, um
eine Datengrundlage zu schaffen. Diese Datengrundlage wird Clients zur Verfügung gestellt, um
mathematische Modelle oder andere mögliche Auswertungen zu unterstützen.
Zu diesem Zweck bietet die Komponente "Verwaltung" mehrere Web-Services, die unterschiedliche
Zugriffe auf die Daten eines Servers ermöglichen. Die Anforderungen und mögliche Zugriffe wurden
bereits in Kapitel 4.3.2.1 vorgestellt. Es geht in diesem Abschnitt darum, alle möglichen Zugriffe
durch Web-Services bereitzustellen. Die Wahl geeigneter Parameter und deren Kombination ist hier
von entscheidender Bedeutung. Die verschiedenen angebotenen Schnittstellen in Form von WebSeite 94
Web-Services zur Datenintegration mobiler Endgeräte
Services (mit unterschiedlichen Parametern) und alle weiteren Anforderungen und Erläuterungen
bezüglich der zu realisierenden Schnittstelle werden im Abschnitt 5.3.2 abgehandelt.
5.3.2
Web-Services
In diesem Abschnitt wird nun die Schnittstelle der Web-Services explizit angegeben. Zuvor werden
allerdings noch einige Erklärungen bezüglich des Aussehens der Schnittstelle gegeben.
Der Rückgabewert eines Web-Services muss allgemein sein, damit alle möglichen Informationen
übertragen werden. Es muss möglich sein, obige Statusinformationen und die Messwerte zu
übertragen. Das genaue Aussehen des Web-Services-Rückgabewerts wird im Folgenden erläutert.
Eine Restriktion seitens des JWSDP1 - also der JAX-RPC Schnittstelle - hat Einfluss auf das Aussehen
der Schnittstelle. JAX-RPC unterstützt nicht alle Java-Datentypen, sondern nur eine kleine Auswahl2.
Im Rahmen dieser Auswahl wird die Schnittstelle erstellt. Die Schnittstelle nutzt die Hashtable- und
ArrayList-Datentypen als Container. Eine sehr wichtige Entscheidung betrifft das Aussehen eines
Messwerts und seiner einzelnen Komponenten. Alle Komponenten werden als Strings abgelegt, um so
die einwandfreie Übertragung zu gewährleisten. Ein Umwandeln eines Strings (wenn nötig) in den
entsprechenden eigentlichen Datentyp stellt kein Problem dar. Ein Problem stellt der eigentliche
Messwert, also der "Value" Parameter dar. Es wäre von Vorteil diesen als Objekt Typ zu übertragen,
da vor allem komplexe Objekte, (etwa Pläne und Skizzen) in einfacher Art und Weise verarbeitet
werden könnten. Der Objekttyp ist allerdings ein zu allgemeiner Typ und wird seitens des JAX-RPC
nicht unterstützt, dieser wird somit auch als String abgelegt. Ein String enthält den eigentlichen Wert
(wenn es sich um einen einfachen Datentyp handelt, etwa double bei Temperaturangaben) oder aber
einen Verweis auf das eigentliche Objekt (wenn es sich um ein komplexes Objekt handelt, etwa einen
Plan oder eine Skizze).
Folgende Methoden stellen die Umsetzung der Anforderungen an eine Schnittstelle zu der
vorliegenden Datengrundlage dar:
Hashtable getMeasurementByEntity(
String entityid)
Hashtable getMeasurementByEntityPit(
String entityid,
String pit,
String difference)
Hashtable getMeasurementByEntityPeriod(
String entityid,
String startdate,
String enddate)
1
Java Web-Services Developer Pack
2
Es handelt sich um Standarddatentypen, sowie umeinige komplexe Datentypen (z.B. ArrayList, Hashtable etc.),
weitere Informationen diesbezüglich sind in [SunWt02] zu finden.
Seite 95
Web-Services zur Datenintegration mobiler Endgeräte
Hashtable getMeasurementByEntitySource(
String entityid,
String sourceid)
Hashtable getMeasurementByEntitySourcePit(
String entityid,
String sourceid,
String pit,
String difference)
Hashtable getMeasurementByEntitySourcePeriod(
String entityid,
String sourceid,
String startdate,
String enddate)
Hashtable getMeasurementByPosition(
String gps,
double distance)
Hashtable getMeasurementByPositionPit(
String gps,
double distance,
String pit,
String difference)
Hashtable getMeasurementByPositionPeriod(
String gps,
String startdate,
String enddate,
double distance)
Hashtable getMeasurementByType(
String type)
Hashtable getMeasurementByTypePit(
String type,
String pit,
String difference)
Hashtable getMeasurementByTypePeriod(
String type,
String startdate,
String enddate)
Hashtable getMeasurementByTypePosition(
String type,
String gps,
double distance)
Hashtable getMeasurementByTypePositionPit(
String type,
String gps,
double distance,
String pit,
String difference)
Seite 96
Web-Services zur Datenintegration mobiler Endgeräte
Hashtable getMeasurementByTypePositionPeriod(
String type,
String gps,
double distance,
String startdate,
String enddate)
Hashtable getEntitiesAtDistance(
String gps,
double distance);
Hashtable getSources(
String entityid);
Diese Methoden sind eine Umsetzung der in Abschnitt 4.3.2.1 gestellten Anforderungen. Der
Rückgabetyp der Web-Services ist in jedem Fall ein Objekt vom Typ Hashtable, dem eine gewisse
Struktur obliegt. Diese Struktur wird allerdings von einigen wesentlichen Aspekten beeinflusst. Bevor
also diese Struktur verständlich erläutert werden kann, müssen diese Aspekte in einem ersten Schritt
vorgestellt werden.
Die Anforderungen an ein Sicherheitskonzept wurden in Kapitel 4.3.2.3 erläutert. Eine Umsetzung
dieser Anforderungen unter Verwendung von Standards (etwa Autorisierung mittels Tomcat Server)
ist leider nicht möglich, da die Ebene der Autorisierung dann nur auf einen kompletten Web-Service
als tiefste Ebene der Granularität festgelegt werden kann. Dies reicht aber zur Umsetzung der
gestellten Anforderungen nicht aus. Da zu den Anforderungen neben Autorisierung und
Authentisierung auch eine Möglichkeit der Berücksichtigung von Zahlungsvorgängen zählt, wurde im
Rahmen der Diplomarbeit die Entscheidung getroffen, diese Sicherheitsanforderungen ohne
Verwendung von Standardmechanismen umzusetzen. Es mussten also bezüglich der erwähnten
Anforderungen weitere Komponenten realisiert werden, die die Web-Service-Methoden unterstützen.
Es ergeben sich folgende Anforderungen:
Erweiterung der Web-Service-Parameter (siehe 5.3.2.1) um zwei Parameter:
o
String username
o
String password
Komponente "Authorize"
Komponente "Payment"
Die Komponenten "Authorize" und "Payment" bilden direkt die Umsetzung der Autorisierungs- und
Zahlungsmechanismen ab. Der Zugriff auf einen Web-Service wird demzufolge intern erweitert. Nach
einer Autorisierung des Benutzers werden die Daten unter Berücksichtung eines Nutzungsschemas
zusammengetragen. Anschließend findet eine Überprüfung der Zahlungsfähigkeit dieser Daten Auf
Grundlage eines Kosten-Nutzungsschemas statt. Nach erfolgreicher Überprüfung werden die Daten
dann dem Benutzer zur Verfügung gestellt.
Seite 97
Web-Services zur Datenintegration mobiler Endgeräte
Die Schnittstellen (also die Komponenten) bieten folgende Funktionalität an:
Komponente "Authorize"
grantAccess (String username, String password)
Auf Basis des Benutzernamens wird überprüft, ob eine Autorisierung des Benutzers erfolgen kann.
Mittels eines Nutzungsprofils, das durch entsprechende Datenbanktabellen abgebildet wird, soll es
möglich sein, Endgeräte oder Quellen für verschiedene Rollen zu autorisieren.
Das Nutzungsschema wird unter Verwendung des Rollenbegriffs erstellt. Ein Benutzer kann einer
oder mehreren Rollen zugeordnet sein. Ein Endgerät-Quelle-Tupel wird dann den vorhandeneren
Rollen zugeordnet, um so eine Zuordnung von Benutzer zu Daten zu ermöglichen. Es ist folglich eine
Zuordnung einzelner Quellen zu Rollen möglich.
Komponente "Payment"
Anlog zu einem Nutzungsprofil - wie im Rahmen der Komponente "Authorize" vorgestellt - soll im
Rahmen der Komponente Payment ein Kostenprofil erstellt werden. Es wird eine Zuordnung von
Endgerät-Quelle-Tupel zu einem Kostenfaktor ermöglicht. Des Weiteren kann ein Faktor angegeben
werden, der angibt, ob die Kosten pro Datum ("PER") oder aber einmalig ("ONE") bei Nutzung der
entsprechenden Quelle anfallen.
getCost(ArrayList measurement)
Entsprechend der vorgegebenen Kostenprofile werden die Kosten für eine Liste mit Messergebnissen
ausgewertet.
isPaymentAccepted (ArrayList measurement, String username, String password)
Gibt an, ob die Zahlung des entsprechenden Betrags für eine Liste von Messergebnissen durch einen
Benutzer abgedeckt ist oder nicht.
Die entsprechenden Profile werden im Rahmen des Datenbankschemas in Abschnitt 5.3.3 umgesetzt.
Nachdem die Sicherheitsanforderungen überprüft wurden, kann ein Web-Service die gewünschten
Daten an einen Client zurückliefern. Während der Verarbeitung eines Web-Service-Aufrufs kann es
jedoch zu Fehlern kommen. Es werden dann keine Messergebnisse an den Client zurückgeliefert.
Dennoch wird eine Möglichkeit bereitgestellt, dem Client entsprechende Informationen bezüglich
seines Aufrufs mitzuteilen. Zu diesem Zweck werden dem Client neben den Messergebnissen weitere
Informationen den Status des Aufrufs betreffend zurückgeliefert.
Seite 98
Web-Services zur Datenintegration mobiler Endgeräte
Folgende Statusinformationen werden zurückgeliefert:
Information
Beschreibung
ERROR
Gibt an, ob ein Fehler vorliegt
STATUS
DBMESSAGE
Der Status ist eine erweiterte Informationsquelle, die genaue Ursachen bezüglich des
aufgetretenen Fehlers in Form von Statuscodes enthält
Liefert die Datenbank eine Fehlernachricht, wird diese ebenfalls zurückgeliefert
Tabelle 20: Statusinformationen des Web-Services
Die Status Information enthält dreistellige Statuscodes zu allen aufgetretenen Fehlern (falls mehrere
auftreten). Folgende Liste enthält alle möglichen Codes und deren Bedeutung:
Code
Bedeutung
100
Datenbankfehler: SQL-Statement führt zu Fehler in der Datenbank
401-409
GPS String nicht korrekt (siehe dazu Tabelle der Statuscodes der Middleware)
901
Autorisierung fehlgeschlagen
902
Bezahlung fehlgeschlagen
Tabelle 21: Statuscodes eines Web-Services
Die vorhergehenden Erläuterungen fassen alle Informationen zusammen, die im Rahmen der
Rückgabe an den Client berücksichtigt werden müssen. Der Rückgabewert der Daten ist sehr
allgemein, damit alle möglichen Informationen übertragen werden können. Zusätzlich ist die Struktur
der Rückgabe von den Aspekten Fehlerbehandlung und Sicherheit abhängig.
Die Rückgabe ist wie folgt gegliedert:
Seite 99
Web-Services zur Datenintegration mobiler Endgeräte
Hashtable
Hashtable
Sta tus
Messwerte
Arra yList
Hashtable
Abbildung 18: Rückgabe der Web-Service Methoden
Der Rückgabewert der Web-Services ist somit ein Element vom Typ Hashtable. Dieses Element
enthält zwei Einträge: zum einen einen Eintrag für Status Informationen (Schlüssel: "status"), zum
anderen einen Eintrag der die Messwerte enthält (Schlüssel: "meas"). Die Messwerte sind in Form
einer ArrayList vorhanden. Das ArrayList-Element enthält mehrere Datensätze in Form von
Hashtable-Elementen. Diese Hashtable-Elemente enthalten dann alle notwendigen Elemente eines
Messergebnisses.
Das Element Status beinhaltet Statusinformationen, die für den Benutzer von Interesse sein können. Es
werden ihm Informationen zu den Fehlermeldungen übertragen. Diese Fehlermeldungen beziehen sich
zum einen auf Probleme bezüglich übergebener Parameter (z.B. GPS-String etc.) zum anderen aber
sind auch Statusinformationen (Fehler) bezüglich der Sicherheitsaspekte (z.B. Authentisierung ist
fehlgeschlagen) enthalten.
Folgende Tabellen fassen obige Informationen anschaulich zusammen:
Typ
Key
Beschreibung
Hashtable
status
enthält Status Informationen bezüglich des Web-Service Aufrufs
ArrayList
meas
enthält die Messergebnisse
Tabelle 22: Web-Service-Rückgabe
Seite 100
Web-Services zur Datenintegration mobiler Endgeräte
Folgend wird erstes Element der Rückgabe veranschaulicht:
Typ
Key
String
error
String
status
String
dbmessage
Tabelle 23: Struktur des Statuselements
Das zweite Element enthält eine ArrayList, die wiederum Hashtable-Elemente enthält; eines dieser
Elemente sieht wie folgt aus:
Typ
Key
String
type
String
datatype
String
unit
String
pit
String
ipaddress
String
id
String
value
String
position
Tabelle 24: Struktur des Messergebniseintrags
Diese Elemente geben einen Messwert wieder, wie er im vorherigen Kapitel definiert wurde, die
Informationen entsprechen denen des Datenbankschemas der Tabelle "Data", die im folgenden Kapitel
definiert wird.
5.3.2.1 Interne Realisierung
Innerhalb eines Web-Services wird nach Überprüfung der Autorisierung eine Anfrage (unter
Berücksichtigung des Nutzungsschemas) an die Datenbank gestellt. Nach Überprüfung der
Zahlungsfähigkeit werden die Daten dann an den Benutzer zurückgeliefert. Treten während dieses
Prozesses Fehler auf, wird dies im Rahmen einer Nachricht an den Client übermittelt. Folgendes
Diagramm zeigt beispielhaft den internen Ablauf bei Aufruf eines Web-Services:
Seite 101
Web-Services zur Datenintegration mobiler Endgeräte
Abbildung 19: interner Ablauf eines Web-Services
Seite 102
Web-Services zur Datenintegration mobiler Endgeräte
5.3.3 Datenbankschema
Das Datenbankschema, das allen Anforderungen bezüglich der Realisierung vorhergehender
Komponenten genügt, wird anhand eines ER-Diagramms vorgestellt. Die Realisierung des ERDiagramms im Rahmen von Datenbanktabellen und weitere Informationen zu den einzelnen Tabellen
werden in Anhang C erläutert.
activeentity
1
1
data
N
N
P
entity
N
1
P
role
M
N
N
datasource
M
P
cost
N
bill
1
1
users
Abbildung 20: Entity Relationship Modell
5.4 Client
Auf der Seite des Clients besitzt die Implementierung große Freiheitsgrade. Einzig der Zugriff auf
Daten über Web-Services muss durch die eingesetzte Entwicklungsplattform möglich sein. Ein Client
kann somit optimal auf die Bedürfnisse des Benutzers angepasst werden.
Seite 103
Web-Services zur Datenintegration mobiler Endgeräte
5.4.1
Client API
Der direkte Zugriff auf Web-Services setzt gewisse Informationen bezüglich des Aufrufs voraus. Eine
Client-Schnittstelle dient dazu, von den Web-Service Details zu abstrahieren und dem Client eine
einfachen Zugriff auf die entsprechenden Methoden zu erlauben.
Dafür müssen alle in Abschnitt 5.3.2 gezeigten Web-Service-Methoden entsprechend umgesetzt
werden.
Weiterhin muss es im Rahmen der Schnittstelle möglich sein, den Benutzernamen und das Passwort
(mittels welcher der Zugriff auf die Web-Services erfolgen kann) innerhalb der Schnittstelle zu setzen.
Der Polling-Mechanismus, der es ermöglichen soll, neue Endgeräte in der Umgebung zu melden, wird
unterstützt. Mittels der Methode getEntitiesAtDistance können dann alle Endgeräte in einer
gewissen Umgebung ermittelt werden.
Die Schnittstelle soll ein Objekt bieten, das es ermöglicht, alle bisher verarbeiteten Endgeräte zu
protokollieren. Mittels einer Methode soll es dann möglich sein, ein Endgerät oder eine Liste von
Endgeräten zu diesem Objekt hinzuzufügen (doppelte Einträge werden überprüft).
Des Weiteren sollte die Möglichkeit bestehen, eine Liste von Endgeräten mit den bereits verarbeiteten
Endgeräten zu vergleichen und anschließend alle neugefundenen Endgeräte als Rückgabe zu liefern.
Dies ist insbesondere im Hinblick auf "mobile" – also sich bewegende – Clients notwendig.
Folgende Möglichkeiten stehen zur Verfügung:
Beschreibung der Operation
Eingabe
Ausgabe
Setze verarbeitete Endgeräte
Array mit Endgeräten
Vergleiche auf neue Endgeräte
Array mit Endgeräten
Hole verarbeitete Endgeräte
Array mit Endgeräten
Array mit Endgeräten
Tabelle 25: Polling-Mechanismus
Funktionen, die über (bestimmte Typen von) Datenquellen eines Endgeräts (falls es sich um einen
numerischen Wert handelt) statistische Werte ermitteln, werden zusätzlich bereitgestellt. Vier übliche
Funktionen dieses Typs werden zur Verfügung gestellt, um diesen Einsatz zu demonstrieren:
Methode
Eingabe
Ausgabe
Average
Typ
ArrayList mit Messwerten
Wert
Summe
Typ
ArrayList mit Messwerten
Wert
Maximum
Typ
ArrayList mit Messwerten
Wert
Minimum
Typ
ArrayList mit Messwerten
Wert
Tabelle 26: statistische Funktionen
Seite 104
Web-Services zur Datenintegration mobiler Endgeräte
Diese Operationen werden im Rahmen des "Client-API" für Java1 bereitgestellt.
5.4.2 GPS
Neben der Client-Schnittstelle werden Klassen zur GPS-Verarbeitung im Rahmen der Middleware
Implementierung erstellt. Diese können auch von einem Client genutzt werden.
Die Klassen unterstützen folgende Aspekte:
GPS-Fehlerverarbeitung
GPS-Längen- und Breitenangaben können ausgelesen werden
Möglichkeit zur Berechnung einer Distanz zwischen zwei Punkten
Nachfolgend werden die Klassen und deren Bedeutung erläutert:
5.4.2.1 GPSNMEA, GPSCheck
Die beiden Klassen GPSNMEA und GPSCheck sind fast identisch. Beide werden unter Angabe eines
GPS-Strings erstellt. Der GPS-String muss im NMEA-Format2 vorliegen, unterstützt werden die Type
GPGGA und GPGLL3. Die GPSCheck-Klasse dient einzig und allein der Überprüfung eines GPSStrings, während die GPSNMEA-Klasse zum einen auch diese Überprüfung beinhaltet, aber des
Weiteren im Rahmen der Erstellung ein EarthCoord-Objekt erzeugt.
5.4.2.2 EarthCoord
Das EarthCoord-Objekt dient als Eingabe für die Berechnung der Distanz zwischen zwei Punkten.
Wie bereits oben erläutert, wird ein solches Objekt von der Klasse GPSNMEA aus einem GPS String
erzeugt. Ein EarthCoord-Objekt enthält dann die Erd-Koordinaten eines GPS Strings.
5.4.2.3 CoordTransform
Auf Basis zweier EarthCoord-Objekte kann die Distanz zwischen diesen beiden Punkten ermittelt
werden. Folgendes Modell liegt der Berechnung zugrunde:
1
Für andere Programmiersprachen lässt sich die API entsprechend umsetzen.
2
Mögliches Format zur Angabe einer GPS-Position – wurde von der National Marine Electronics Association
eingeführt. Weiter Informationen zum NMEA-Protokollformat können in [Bad02] gefunden werden.
3
Die GPGGA- und GPGGL-Typen sind mögliche Datensätze in den eine GPS-Positionsangabe im Rahmen des
NMEA-Formats angegeben wird.
Seite 105
Web-Services zur Datenintegration mobiler Endgeräte
lat1
Breitengrad Punkt 1 in Grad
lat2
Breitengrad Punkt 2 in Grad
long1 Längengrad Punkt 1 in Grad
long2 Längengrad Punkt 2 in Grad
long2 – long1
D 1.852 60 arccossin lat1 sin lat 2 coslong1 coslong 2 cos
Bei dieser Methode der Distanzberechnung handelt es sich um die Great Circle Distance-Methode, die
aus der sphärischen Trigonometrie stammt. Informationen zu der Berechung der Distanz zweier
Koordinaten kann folgenden Referenzen entnommen werden: [Bib02], [Geo02].
5.4.3
Client-Anwendung
Es wird in dieser Arbeit beispielhaft ein Client implementiert, der mit einer Middleware
kommuniziert. Dieser Client ist eine sehr schlichte und einfache Anwendung, die einen Großteil der
möglichen Funktionalität beispielhaft nutzt und deren Einsatz demonstriert.
5.5 Gesamtsystem im Überblick
Alle bisher erwähnten Anforderungen an das Gesamtsystem - bestehend aus Endgerät, Middleware
und Client - und deren Umsetzung im Rahmen von Komponenten werden in folgendem Bild
zusammengefasst:
Seite 106
Web-Services zur Datenintegration mobiler Endgeräte
Sensor
Web Server
GPS
Mobiles
Endgeraet
Anmelden
Client
Update
Payment
Middleware
Registrierung
Verwaltung
Datenbank
Abmelden
Authorize
Update
Daten
Server
Client
Web Server
Abbildung 21: Gesamtsystem im Überblick
5.6 Erweiterung der Anforderungen
Analog zu
den
Entwickler- und
Benutzeranforderungen
könnten
an
dieser
Stelle
die
Komponentenanforderungen tabellarisch aufgelistet werden. Da diese jedoch im Rahmen dieses
Kapitels in den jeweiligen Abschnitten detailliert erläutert wurden, werden sie dieser Stelle nicht
nochmals explizit angeführt. Die Anforderungen ergeben sich direkt aus den Diagrammen und den
betreffenden Beschreibungen.
5.7 Verifikation
Die Entwickleranforderungen aus Kapitel 4 werden an dieser Stelle verifiziert. Es wird für jede
Entwickleranforderung (FEA1-FEA14, sowie IA1, IA2) überprüft, durch welche Komponente diese
Seite 107
Web-Services zur Datenintegration mobiler Endgeräte
umgesetzt wird. Es kann somit gewährleistet werden, dass alle gestellten Anforderungen umgesetzt
wurden.
Entwickleranforderung
Komponente (oder Funktion)
FEA1
Chip-Modul
FEA2
Chip-Modul
FEA3
Chip-Modul
FEA4
Chip-Modul
FEA5
CGI-Modul
FEA6
Anmelden
FEA7
updateData
FEA8
updateData
FEA9
Verwaltung
FEA10
Verwaltung
FEA11
SSL (Tomcat)
FEA12
Authorize
FEA13
Payment
FEA14
Abmeldung
IA1
updateData
IA2
Komponentenübergreifend
Die Realisierung der einzelnen Anforderungen wurde in diesem Kapitel beschrieben. Alle nötigen
Komponenten wurden vorgestellt und erläutert. Im Rahmen des folgenden Kapitels werden nun die
einzelnen Komponenten im Rahmen von Java-Klassen und C++-Modulen umgesetzt.
Seite 108
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 6: Implementierung
Implementierung der Komponenten
Auf Grundlage der Komponentenbeschreibungen des vorhergehenden Kapitels werden in diesem
Kapitel die Realisierungen im Rahmen von Java-Klassen und C++-Modulen erläutert. Die C++Module des Beck IPC SC12 wurden unter zu Hilfenahme von Quellbeispielen der Firma Beck erstellt,
weitere Informationen können unter [BeCb02] gefunden werden.
6.1 Mobiles Endgerät (C++ Komponenten)
Der als mobiles Endgerät in dieser Diplomarbeit eingesetzte Beck SC12, kann nur unter Verwendung
von C/C++ programmiert werden. Das Modul, das alle Anforderungen aus Kapitel 5 umsetzt, wird
somit mit C/C++ erstellt.
Die Komponente chipmodul (C++) besteht aus folgenden Komponenten:
Anmeldung,
Abmeldung,
Initialisierung und
Messen.
Die Komponenten werden lediglich durch ein Programm "Messen" realisiert, da eine Aufteilung in
mehrere Programme einen wesentlich höheren Speicherverbrauch bedeuten würde. Eine effiziente
Ausnutzung des Speicherplatzes ist nötig, um Messwerte (in Form von XML-Dateien) sowie
Konfigurationsdateien auf dem Chip abzulegen. Der Aufruf der einzelnen Teile erfolgt mittels
Parameter.
Folgende Zuordnung wurde gewählt:
Komponente
Parameter
Initialisierung
0
Zeit synchronisieren
1
Anmeldung
2
Messen
3
Abmeldung
4
Seite 109
Web-Services zur Datenintegration mobiler Endgeräte
6.1.1.1 Anmeldung
Es erfolgt zu Beginn des Anmeldevorgangs ein Synchronisieren der Datum/Zeit-Angabe des IPC
SC12 anhand eines Timeservers. Anschließend wird das mobile Endgerät an allen in der Datei
"middle.ini" angegebenen Middleware-Plattformen registriert (wenn möglich).
6.1.1.2 Abmeldung
Analog zur Anmeldung erfolgt die Abmeldung an allen Plattformen.
6.1.1.3 Initialisierung
Die Initialisierung wird bei Inbetriebnahme oder im Fehlerfall (XML-Dateien wurden zerstört) nötig.
Es werden alle XML-Dateien erzeugt, um so ein Verarbeiten der Daten seitens der Middleware zu
gewährleisten.
6.1.1.4 Messen
Die Komponente Messen ist die wichtigste Komponente, da Sie eine regelmäßige Aktualisierung der
Daten vornimmt und die entsprechenden XML-Dateien erzeugt.
6.2 Daten-Server (C++/CGI Komponente)
Das CGI-Modul kann über eine Webreferenz direkt aufgerufen werden:
http://ipaddress//update
Durch Aufruf dieser Referenz wird ein Update der Daten angestoßen. Informationen bezüglich des
Anmelde Vorgangs werden im Browser angezeigt.
6.3 Middleware (Java-Klassen)
Die folgenden Klassen wurden im Rahmen der Implementierung erstellt. Es handelt sich dabei zum
einen um direkte Umsetzungen der erforderlichen Komponenten, zum anderen um Klassen zur
Unterstützung der Bereitstellung der benötigten Funktionalität. Im Rahmen der Implementierung
wurde auf folgende Referenzen zurückgegriffen: [SunJt02], [SunJa02].
Die Klasse Update realisiert die Funktionen updateData, isRegistered und unregisterEntity, sowie
weitere unterstützende Methoden, die der Aktualisierung der Daten eines Endgeräts dienen. Unter
anderem wird die Fehlerverarbeitung und die Benachrichtigung im Fehlerfall von der Klasse Update
übernommen. Die Verarbeitung der XML-Dokumente (Endgerät, Datenquelle und Messwerte) - die
im Rahmen der Aktualisierung erfolgt - wird anhand der Klassen EntityHandler, SourceHandler,
Seite 110
Web-Services zur Datenintegration mobiler Endgeräte
MeaurementHandler und DataHandler durchgeführt, die somit eine weitere Unterstützung der
Realisierung der Komponente Update darstellen.
Für die Komponenten Anmeldung und Abmeldung ist es nötig, eine Klasse zu implementieren, die
Gesuche (zu jedem Zeitpunkt der Ausführung der Komponente entgegen nehmen kann). Die Klasse
Server realisiert diese Funktionalität Auf Grundlage des Client/Server-Prinzips. Diese Klasse wurde
basierend auf einer existierenden Client/Server-Komponente erstellt, Informationen diesbezüglich
können folgender Referenz entnommen werden: [Fla00]. Die Client/Server-Komponente ermöglicht es
Dienste (in Form von Klassen) zu spezifizieren und diese an beliebigen Ports1 anzubieten. Von diesem
Zeitpunkt an ist es Clients (in diesem Fall Endgeräten) möglich, im Rahmen einer SocketKommunikation die Anmelde- oder Abmelde-Komponente über den entsprechenden Port
anzusprechen und somit den jeweiligen Dienst in Anspruch zu nehmen. Die Komponenten
"Anmeldung" und "Abmeldung" wurden jeweils als eigene Klassen Anmeldung und Abmeldung
innerhalb der Klasse Server realisiert.
Ein mobiles Endgerät wird nach einer Anmeldung im System registriert (Komponente
"Registrierung") um eine regelmäßige Aktualisierung der Daten zu ermöglichen. Die Klasse
Registrierung dient dazu Threads zu erstellen, die eine entsprechende Aktualisierung der Daten
selbstständig ausführen. Eine Besonderheit dieser Klasse ist das Bereinigen nicht mehr aktiver oder
fehlerhafter Registrierungen. Sollte ein mobiles Endgerät deaktiviert worden sein ohne eine
Abmeldung durchzuführen oder beinhaltet ein Endgerät fehlerhafte XML-Daten, wird durch einen
Wert, der automatisch inkrementiert wird, eine Fehlerhäufigkeit protokolliert. Übersteigt dieser Wert
einen vorher definierten Schwellwert, wird eine automatische Abmeldung des Geräts durchgeführt.
Somit können Belastungen durch nicht mehr vorhandene oder fehlerhafte Endgeräte minimiert
werden.
Im Rahmen der Web-Services wird anhand der Klassen Verwaltung, Authorize und Payment die
benötigte Funktionalität bereitgestellt. Die Klasse Verwaltung realisiert eine direkte Umsetzung aller
Web-Service-Methoden. Die Sicherheits- und Zahlungsmechanismen werden während der
Verarbeitung eines Web-Services durch die Klassen Authorize und Payment berücksichtigt. Da der
Zugriff auf die Klasse Verwaltung zum Teil Wissen über eine Nutzung von Web-Services voraussetzt,
wird eine Klasse ClientAPI bereitgestellt, die von allen Details abstrahiert und dem Benutzer einen
möglichst einfachen Zugriff auf die entsprechenden Dienste erlaubt. Beispielhaft wurde eine
Anwendung geschrieben, die die Funktionalität der Web-Services anschaulich darstellt. (die Klasse
VerwaltungClientSwing greift unter Verwendung der ClientAPI Schnittstelle auf die Web-Services
zu).
Des Weiteren werden zur Unterstützung der Verarbeitung von GPS-Strings (die Funktionalität wird in
der vorliegenden Implementierung vor allem innerhalb der Middleware verwendet, kann jedoch auch
für Client-Anwendungen sinnvoll sein, z.B. zur Berechnung der Distanz zu den jeweiligen Endgerät1
ausgeschlossen sind vordefinierte und bereits belegte Ports
Seite 111
Web-Services zur Datenintegration mobiler Endgeräte
Positionen) die Klassen GPSCheck, GPSNMEA, EarthCoord, CoordTransform angeboten. Anhand
dieser Klassen ist es möglich Distanzen zwischen zwei Punkten (die als GPS-NMEA-String vorliegen)
zu berechnen, sowie einen GPS-NMEA-String (GPGGA und GPGLL Datensatz) auf syntaktische
Korrektheit zu überprüfen.
6.4 Verifikation
Dieses Kapitel verifiziert die Komponenten-Anforderungen gegen die realisierten Klassen. Es wird
somit gewährleistet, dass alle Komponenten im Code umgesetzt worden sind und die erwarteten
Anforderungen erfüllen.
Mobiles Endgerät
chipmodul
chipmodul
Datenserver
CGI-UpdateAnforderung
CGI-Modul
Middleware
Komponente
Realisiert durch Klassen
Anmeldung
Server, Anmeldung
Abmeldung
Server, Abmeldung
Registrierung
Registrierung
Update
Update
EntityHandler,
SourceHandler,
MeasurementHandler,
DataHandler
GPSNMEA,
EarthCoord,
CoordTransform
Authorize
Authorize
Payment
Payment
Verwaltung
Verwaltung
GPSCheck
6.4.1
Inverse Anforderungen
An dieser Stelle wird die Berücksichtigung der inversen Anforderungen analysiert.
6.4.1.1 IA1: ACID-Prinzip wahren
Die Daten werden vor Einlagerung in die Datenbank in einer ersten Instanz vollständig (soweit
möglich) überprüft. Die korrekten Daten werden dann in einem zweiten Schritt in die Datenbank
Seite 112
Web-Services zur Datenintegration mobiler Endgeräte
eingelagert. Die Einlagerung wird unter Deaktivierung der AutoCommit Einstellung durchgeführt. Ein
AutoCommit sorgt dafür, dass nach Einlagern jedes Einzelnen Datensatzes ein Commit erfolgt. Die
Granularität der Transaktion ist also eine einzelner Datensatz. Dieser Modus wird abgeschaltet und das
Commit wird manuell gesteuert. Die Granularität einer Transaktion ist nun nicht mehr ein einzelner
Datensatz sondern die komplette Folge von Daten. Sollte ein Fehler beim Einlagern der Daten
erfolgen, werden alle bis zu diesem Zeitpunkt seit Beginn der Einlagerung vorgenommen Änderungen
an der Datenbank rückgängig gemacht, so dass die Datenbank in ihren Ursprungsstatus zurückversetzt
wird.
6.4.1.2 IA2: Fehler abfangen und melden
Wie bereits in den Beschreibungen der Komponenten erläutert wurde werden Statuscodes für
entsprechende Fehler generiert und wenn möglich an den Administrator gemeldet.
Seite 113
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 7: Zusammenfassung und Ausblick
In dieser Diplomarbeit wurde theoretisch die Möglichkeit erarbeitet eine Datengrundlage zu schaffen,
die im Rahmen von Modellen zur Berechnung und Simulation von Prozessen verwendet werden kann.
Zu diesem Zweck wurde ein möglichst allgemeingültiges System konzipiert und entwickelt, das eine
entsprechende Verwendung ermöglicht. Nach Aufstellen der Anforderungen an das System wurden im Rahmen der Systemkonzeption - vorab theoretisch verschiedene Realisierungsalternativen zum
Datentransfer einerseits und zur Realisierung der Persistenz der Datenhaltung und des Anbietens der
Daten andererseits analysiert. Auf Grundlage dieser Analyse wurde dann eine Entscheidung betreffend
der beiden Aspekte getroffen, die anschließend in die Konzeption des Systems einfließen konnte. Die
Realisierungsentscheidungen und die erarbeiteten Anforderungen wurden dann in der Konzeption des
Systems umgesetzt. Diese wurde ausgehend von den Anforderungen bis auf die Komponentenebene
durchgeführt, auf der eine direkte Zuordnung der Komponenten zur Implementierung möglich war. Es
lag eine vollständige Konzeption des Systems im Rahmen von einzelnen Komponenten und deren
Zusammenspiel vor, die in der Implementierung durch Realisierung der einzelnen Komponenten und
geeigneter Schnittstellen umgesetzt werden konnte.
Während der Realisierung des Systems wurde ein geeignetes Szenario erstellt, das den Einsatz des
Systems demonstrieren konnte. Unter Verwendung einer beispielhaften Versuchsanordnung war es
möglich, zum einen das System vorzuführen, zum anderen aber auch eine Validierung der einzelnen
Komponenten und des gesamten Systems durchzuführen.
Die vorliegende Ausprägung des Systems (Endgeräte, Datengrundlage) ermöglicht es jedoch nicht das
System im Rahmen der Unterstützung von Modellen (z.B. im Bereich der Unterstützung des
Nachhaltigkeitsprinzips) zum Einsatz zu bringen, da die Datengrundlage aufgrund einer geringern
Aussagekraft in diesen Bereichen keine Schlussfolgerungen zulässt. Es obliegt dem jeweiligen
Anwender eine entsprechenden Datengrundlage als Basis für entsprechende Simulationen zu schaffen.
In dieser Domäne wäre es sinnvoll, eine Erweiterung des vorliegenden Systems in den Bereichen
Datengrundlage und demzufolge auch im Bereich der vorliegenden Hardware durchzuführen. Das
Erstellen eines komplexen Einsatz Szenarios im Bereich der Raum- und Umweltplanung könnte eine
Verwendung des Systems zur Unterstützung des Nachhaltigkeitsprinzips demonstrieren. Anhand
weiterer gezielt ausgewählter Sensoren (für diesen Bereich) könnten Wechselwirkungen verschiedener
Faktoren aufeinander abgestimmt und optimiert werden. Somit könnte ein direkter Einsatz im Rahmen
einer wesentlich komplexeren Anwendung aufgestellt werden.
Im Bereich der Anwendungen sind praxisnähere Anwendungen von essentieller Bedeutung. Im
Rahmen der Diplomarbeit wurde eine Anwendung erstellt, die die Funktionalität des Systems grob
widerspiegelt. In diesem Bereich wären weitere Szenarien vorstellbar:
Seite 114
Web-Services zur Datenintegration mobiler Endgeräte
Eine Person könnte sich anhand eines PDAs (auf dem eine entsprechende Anwendung ausgeführt
wird) in einem Gebiet bewegen (in dem sich mehrere Sensoren befinden) und je nach räumlicher Nähe
zu den einzelnen Sensoren die Daten zu den einzelnen Sensoren zur Verfügung gestellt bekommen.
Des Weiteren könnte eine entsprechende Anwendung auch im Bereich der virtuellen Realität
angesiedelt werden, somit wäre es denkbar im Rahmen einer virtuellen Welt Daten zu einzelnen
Gebieten (die virtuell dargestellt werden) anzuzeigen.
Die Szenarien in diesem Bereich sind beliebig komplex gestaltbar, da jegliche Funktionalität auf Basis
der Datengrundlage auf Seiten des Clients erstellt werden kann. Somit ist der Einsatz des Systems im
Bereich der Client-Anwendungen vielfältig möglich.
Eine Erweiterung oder Änderung der Hardware kann weitere Vorteile bringen. Der vorliegende SC12Chip von Beck könnte durch ein leistungsfähigere Variante ersetzt werden, die vor allem mehr
Speicherplatz bietet und die Entwicklung und Ausführung von 32bit-Anwendungen ermöglicht. Somit
wäre zum einen eine Umsetzung der Web-Service-Funktionalität auf Seiten eines Endgeräts denkbar,
zum anderen könnten wesentlich effizientere Sicherheitsmechanismen eingesetzt werden.
Insgesamt kann also durch eine Erweiterung des Systems auf der einen Seite eine fundierte
Datengrundlage zur Verwendung im Rahmen von Modellen geschaffen werden, zum anderen wird die
Erweiterung/Anpassung
des
Systems
im Rahmen
leistungsfähigerer Endgeräte) wesentlich vereinfacht.
Seite 115
der
Entwicklung (durch
den
Einsatz
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 8: Anhang A
Versuchsanordnung und Konfigurationen
8.1 Mobiles Endgerät
Das mobile Endgerät wird durch einen Prototyp realisiert. Es handelt sich dabei um ein Board, das
einen Beck IPC SC12 beinhaltet. Mehrere Schnittstellten nach außen (seriell, I2C) werden angeboten,
um entsprechende Quellen zu betreiben oder Werte zu beobachten. Neben dem Beck SC12 wird ein
GPS-Chip der Firma -blox verwendet, der intern über die serielle Schnittstelle mit dem SC12
verbunden ist. Es ist somit möglich die Positionsangabe an dieser Schnittstelle abzufragen. Des
Weiteren wird über die serielle Schnittstelle ein Temperaturmodul eingebunden, so dass eine weitere
Quelle verfügbar ist. Es können anhand dieser beiden Module Realdaten im System eingebunden
werden.
8.1.1
Versuchsanordnung:
Nach obiger kurzer Einführung wird die Versuchsanordung etwas detaillierter beschrieben. Es handelt
sich dabei um eine Beschreibung, die von allen Details abstrahiert, die für das Verständnis nicht nötig
sind.
Folgend wird die Versuchsanordnung graphisch dargestellt:
Seite 116
Web-Services zur Datenintegration mobiler Endgeräte
BUS
Temperaturmodul
LCD
X101
Board
GPS
SC12
IC109
Abbildung 22: Versuchsanordung
Da Board beinhaltet folgende wichtige Elemente:
GPS-Chip,
IPC SC12 und
IC109 Steuerungschip.
Auf diese Elemente wird in folgenden Sektionen Bezug genommen.
Die weiteren Module der Anordnung sind:
Temperaturmodul,
LCD und
BUS.
Seite 117
Web-Services zur Datenintegration mobiler Endgeräte
Die Einbindung der Module "Temperaturmodul" und "LCD" erfolgt über das Bus-Modul. Im
Normalzustand könnte nur jeweils eines der beiden Module betrieben werden, da nur eine X101Schnittstelle1 zur Verfügung steht. Mittels des Bus-Moduls können bis zu drei Geräte (in dieser
Versuchsanordung) betrieben werden. Angesprochen werden die Geräte mittels Adressen.
In der vorliegenden Versuchsanordnung gelten folgende Adressen:
Modul "LCD" an Adresse 1 und
Modul "Temperatur" an Adresse 2
Folgend werden nun weitere Erläuterungen zu den einzelnen Modulen, sowie wichtige Informationen
und nötige Einstellungen besprochen.
Informationen zu dm Beck SC12 können folgenden Referenzen entnommen werden:
[Küh01], [BeApi02], [SchGat01], [BeHw02], [BeDb02], [BeDb02], [BeDg02]
8.1.2
Konfiguration des Informationsflusses auf dem Board
Es gibt drei verschiedene Modi, in die das Board versetzt werden kann. Diese Modi werden aufgrund
von Jumper-Stellungen sowie von Hexadezimalen Statuscodes (die an einen auf dem Board
befindlichen Steuerungschip (IC109) gesendet werden) gesetzt.
Folgend werden die Modi aufgelistet:
Modus
Beschreibung
Hexadezimaler Code
Jumper Stellung
0x87
2 links
0x87
2 rechts
je nach Art des Zugriffs
Ohne
Dieser Modus dient zum
Term
Zugriff auf den SC 12
mittels der seriellen
Schnittstelle
In diesem Modus werden
die Informationen des
Monitor
GPS-Chips an die externe
serielle Schnittstelle
weitergereicht
Dieser Modus stellt den
Betriebsmodus dar in
Applikation
dem die GPSInformationen intern an
den SC12 geleitet
werden.
Tabelle 27: Modi der Platine
1
serielle Schnittstelle
Seite 118
Web-Services zur Datenintegration mobiler Endgeräte
Im Gegensatz zum Setzen der Jumper muss das Setzen des hexadezimalen Codes innerhalb eines
Programms, das auf dem Chip abläuft, erfolgen. Die hexadezimalen Codes werden an einen
Steuerungschip gesendet, der interne Schaltungen, sowie LEDs auf der Platine steuert.
Die hexadezimalen Codes entsprechen im Binärformat den zu setzenden Pins des Steuerungschips. Im
Programm werden diese Pins über Konstanten gesetzt um einen direkten Bezug zu erhalten:
Folgende Konstanten werden definiert (für die einzelnen Pins):
#define LED
0x80
#define HGB
0x04
#define GPS
0x02
#define TERM
0x01
Wichtig sind die Konstanten GPS und TERM, die die Steuerung des Datenflusses regeln. Anzumerken
ist, dass diese dann aktiv sind wenn der Übergabewert 0 ist, sie also nicht gesetzt werden.
Innerhalb des Modus Applikation werden zwei Zugriffe unterschieden:
Zugriff auf GPS-Chip und
Zugriff auf Temperatur Sensor.
Im "Normalbetrieb" alle obigen Konstanten gesetzt sind, also der Hexadezimal-Code 0x87 an den
Steuerungschip gesendet wird.
8.1.2.1 GPS-Chip
Der Zugriff auf den GPS-Chip erfolgt über die serielle Schnittstelle COM. Der GPS-Chip ist intern mit
dieser Schnittstelle verbunden. Es ist ein Umschalten des Datenflusses nötig, um die Daten des GPSChip an die serielle COM Schnittstelle des IPC SC12 zu leiten.
Folgender Hexadezimalcode wird gesendet:
HGB und
TERM.
Im Gegensatz zum oben angegebenen Normalbetrieb wird GPS auf 0 gesetzt und somit aktiv.
8.1.2.2 Temperaturmodul
Der Zugriff auf das Temperaturmodul erfolgt über die serielle COM Schnittstelle. Angeschlossen wird
das Modul über einen externen Port (X101) an diese Schnittstelle. Da das GPS-Modul ebenfalls an
dieser Schnittstelle betrieben wird, ist ein eventuelles Umschalten erforderlich. Der Code für den
"Normalbetrieb" muss an den Steuerungschip gesendet werden.
Seite 119
Web-Services zur Datenintegration mobiler Endgeräte
Der Steuerungschip wird mittels folgendem Kommando angesprochen
outportb(Adresse, zu setzende Pins(in hexadezimalem Format));
Die Adresse des Steuerungschips ist: 0x105
Folgenden Tabelle fasst die Codes für den Modus Applikation zusammen:
gewünschte Daten
Code
Befehl
GPS
0x5
outportb (0x105, HGB|TERM);
Temperatur
0x87
outportb(0x105, LED|TERM|GPS|HGB);
Tabelle 28: Hexadezimal-Codes im Modus Applikation
8.1.3
GPS-Chip
Der verwendete GPS-Chip ist ein GPS-MS1E der Firma -blox.
Der GPS-Chip gibt beim Start des Systems das SIRF Protokoll1 zur Positionsangabe auf der
Schnittstelle aus. Diese Einstellung muss geändert werden, da in vorliegender Diplomarbeit das
Gesamtsystem nur GPS-Angaben in Form des NMEA-Protokolls unterstützt (GPGGA, GPGLL). Da
die GPGGA-Nachricht mehr Informationen enthält als die GPGLL-Nachricht wird erstere Variante
verwendet. Die Seiten des Herstellers enthalten das Kommunikationsprotokoll des GPS-Chips
[Ubl00]. Folgende Nachrichten müssen an den GPS-Chip übermittelt werden, damit eine einwandfreie
Übermittlung der GPS-Position in Form eines NMEA GPGGA Strings möglich ist.
Message ID 135 Set Protocol
Message ID 134 Set Main Serial Port
Message ID 129 Switch to NMEA Protocol
Anmerkung: Die Firma -blox teilte auf Anfrage mit, das nur die Nachricht mit ID 129 nötig sei, um
den Chip korrekt einzubinden. Dies konnte leider im Rahmen der Arbeit nicht bestätigt werden, da
nach einem Kaltstart des Systems und der Übermittlung dieser Nachricht, das System bei der
Ermittlung der Positionsangabe zum Stillstand kam. Erst obiger Ansatz konnte dieses Problem lösen.
Die Daten des GPS-Chip werden gepollt, um somit unnötige Daten auf der seriellen COMSchnittstelle zu verhindern und den reibungslosen Einsatz des Temperaturmoduls zu gewährleisten. Im
Rahmen obiger Nachricht (ID 129), die ein Umschalten auf das NMEA-Protokoll bewirkt, werden alle
1
Protokoll mittels welchem ein GPS Receiver angesteuert werden kann und eine GPS Position angegeben kann
Seite 120
Web-Services zur Datenintegration mobiler Endgeräte
Nachrichten deaktiviert. Somit sendet der GPS-Chip selbstständig keine Daten. Es muss allerdings
dann bei Bedarf folgende Nachricht an den GPS-Chip gesendet werden:
$PSRF103 Query / Rate Control
Erst dann sendet der Chip den geforderten Wert an den IPC SC12.
8.1.4 Temperaturmodul
Das Temperaturmessmodul wird ähnlich wie das GPS-Modul auch abgefragt.
Das Temperaturmodul ist ein externes Modul, das über die externe COM-Schnittstelle mit dem PC
SC12 verbunden ist.
Folgendes Format muss auf die serielle Schnittstelle gelegt werden um die Daten abzufragen:
<STX><ADR><ENQ><ETX><BCC>
Die Adresse des Temperaturmoduls ist 2.
Um Daten anzufordern, wird folgendes Kommando auf die serielle COM-Schnittstelle geschrieben:
"\x02""2""\x05\x03""0"
Dann werden die Daten in folgendem Format geliefert:
<STX><ADR><VZ><T1><T2><.><T3>
Wichtig sind in diesem Fall VZ, T1, T2, <.>, T3, die die eigentlichen Daten darstellen.
Ausgelesen werden müssen also aus dem Array, dass als Ergebnis zurückgeliefert wird, nur die
Positionen 2,3,4,5,6 um das eigentliche Ergebnis zu erhalten.
8.1.5 LCD Modul
Analog zu dem Temperatur-Modul kann auch das LCD Modul angesprochen werden.
Das Format in welchem eine Anfrage zur Darstellung eines Textes erfolgt sieht wie folgt aus:
<STX><ADR><...DATA...><ETX><BCC>
Innerhalb des Datenblocks DATA wird zu Beginn mittels zweier Zahlen, die Spalte und die Zeile
übermittelt in welcher der Text dargestellt werden soll.
Beispiel:
"\x02""1""05TEXT""\x03""0"
In diesem Beispiel wird der Text "TEXT" in Spalte 0 Zeile 5 geschrieben.
8.2 Konfigurationsdateien
8.2.1 Mobiles Endgerät
Der Beck SC12 muss Konfigurationsdateien enthalten, die den gewünschten Datenbestand
bereitstellen.
Folgend werden Beispiele für alle in Sektion 5.1.1 angeführten Konfigurationsdateien aufgeführt.
Seite 121
Web-Services zur Datenintegration mobiler Endgeräte
Es ist sehr wichtig, am Ende der Konfigurationsdateien, die letzte Zeile jeweils immer mit einem
Zeilenumbruch abzuschließen, da ansonsten die letzte Zeile nicht gelesen werden kann. Diese
Konfigurationsdateien müssen nach diesem Schema vorliegen, da bereits geringste Abweichungen zu
Fehlfunktionen führen können.
entity.ini
ID=mobile1
NUMBER=3
UPTIME=30
GMT=+1
TIMESERVER=xxx.xxx.xxx.xxx
source3.ini
ID=wind1
DESCRIPTION=Wind Sensor
STATUS=1
REFRESHRATE=30
NUMBER=3
TYPE=Staerke
DATATYPE=INT
UNIT=km/h
TYPE=Richtung
DATATYPE=STRING
UNIT=richtung
Sourcep.ini
ACTPOS=1
middle.ini
[MIDDLEWARE1]
IPADDRESS=131.246.103.124
ONPORT=3001
OFFPORT=3002
[MIDDLEWARE2]
IPADDRESS=131.246.103.105
ONPORT=3001
OFFPORT=3002
Seite 122
Web-Services zur Datenintegration mobiler Endgeräte
8.2.2 Middleware
Die Middleware benötigt ebenfalls die Angabe gewisser Informationen innerhalb einer
Konfigurationsdatei. Diese Konfigurationsdatei muss in einem Unterverzeichnis sfb im HOME
Verzeichnis des aktuellen Benutzers zu finden sein und den Namen middleware.properties tragen.
Folgende Informationen werden angegeben:
Parameter
Ausprägungen Erläuterung
Beispiel
gibt an, ob Debug
debug
1,0
Ausgaben erfolgen
debug=1
sollen oder nicht
gibt an, ob
messaging
1,0
Nachrichten
ausgegeben werden
messaging=0
oder nicht
Schwellwert bei
limit
Integer
driver
String
Datenbanktreiber
usr
String
Datenbankpfadangabe
usr
String
pwd
String
mailhost
String
Auftreten von Fehlern
5
jdbc:postgresql://...testuser
Benutzername für
Datenbankzugriff
testuser
Passwort für
Datenbankzugriff
E-Mail Host
somepassword
url
E-Mail des
adminemail
String
Middleware
[email protected]
Administrators
Port an dem
portlogin
Integer
Anmeldungen
entgegengenommen
5001
werden
Port an dem
portlogoff
Integer
Abmeldungen
entgegengenommen
5002
werden
Name des
billdirectoryname String
Verzeichnisses in
dem Rechnungen
Seite 123
bills
Web-Services zur Datenintegration mobiler Endgeräte
abgelegt werden
Tabelle 29: Middleware Konfigurationsdatei
8.3 Web-Services
Die Web-Services können mittels des Werkzeugs "ant" kompiliert, veröffentlicht und benutzt werden.
Das ant-Werkzeug vereinfacht die genannten Vorgänge wesentlich, da diese anhand von simplen
Kommandos und Konfigurationsdateien ausgeführt werden.
8.3.1
ant
Das ant-Werkzeug wird mittels drei Dateien administriert:
build.xml,
build.properties und
targets.xml.
8.3.1.1 build.xml
Die Datei build.xml verweist auf den Standort der beiden Dateien build.properties sowie targets.xml
und sieht wie folgt aus:
<!DOCTYPE project [
<!ENTITY commonTargets SYSTEM "../mw_config/targets.xml">
]>
<project name="Middleware Web-Service" default="build" basedir=".">
<property file="../mw_config/build.properties"/>
&commonTargets; <!-- The ant targets are in ../mw_config/targets.xml
-->
<target name="build" depends="build-service"
description="Executes the targets needed to build the service.">
</target>
</project>
Diese
Konfigurationsdatei
verweist
zum
einen
auf
eine
build.properties
Datei,
die
Konfigurationseinstellungen enthält, zum anderen auf eine targets.xml, die folgend erläutert werden.
8.3.1.2 build.properties
Die
Datei
build.properties
enthält
Konfigurations-Einstellungen,
wie
Ordner-Angaben,
Namensgebung, Benutzer/Passwort-Angaben, sowie weitere projektrelevante Variablen.
Folgender Auszug zeigt einige Variablendefinitionen:
project=middleware
client-class=middleware.VerwaltungClient
Seite 124
Web-Services zur Datenintegration mobiler Endgeräte
client-jar=${example}-client.jar
Diese Variablen werden im Rahmen der targets.xml verwendet um den Web-Service erstellen und
veröffentlichen zu können.
Ein Web-Service muss angepasst werden sollte er in einer anderen Umgebung zum Einsatz kommen:
Angabe der Paketstruktur
project=de/icsy/sfb/middleware
Pfadangabe der Web-Service-Url
context-path=middleware
Die Url über die der Web-Service erreichbar ist, sieht wie folgt aus:
tomcat-url/context-path/ServiceName
Einstellungen bezüglich des Clients:
client-class=de.icsy.sfb.middleware.VerwaltungClient
Namensgebung (willkürlich)
client-jar=$middleware-client.jar
portable-war=$middleware-portable.war
deployable-war=${context-path}.war
Pfadangaben:
Kompletter Pfad zu den Web-Service Dateien (inklusive Paketstruktur)
project -path=C:/Java/j2sdk1.4.0_01/de/icsy/sfb/middleware
Pfad zum Wurzelverzeichnis des Web-Services (ohne Paketstruktur)
root-path=C:/Java/j2sdk1.4.0_01
Pfad zum Distributionsverzeichnis des Web-Services
war-path=C:/Java/j2sdk1.4.0_01/de/icsy/sfb/middleware/dist/${deployable-war}
8.3.1.3 targets.xml
Die Datei targets.xml definiert mehrere "Tasks" die das ant-Werkzeug anschließend ausführen kann.
Ein Task stellt einen Vorgang (oder auch mehrere Vorgänge) dar die das System ausführen soll.
Beispielsweise ist im Bereich Web-Services der Vorgang deploy angelegt worden, der wie folgt in der
Datei targets.xml definiert ist.
Seite 125
Web-Services zur Datenintegration mobiler Endgeräte
<target name="deploy"
description="Deploys a Web application">
<deploy url="${url}" username="${username}"
password="${password}"
path="/${context-path}" war="file:${war-path}" />
</target>
Durch den Aufruf ant deploy wird dieser Vorgang ausgelöst. Der entsprechende Web-Service wird
durch diesen Aufruf veröffentlicht.
Obiges Beispiel zeigt neben den Tasks auch den Einsatz der Variablen (hier username, url, password)
innerhalb der targets.xml.
Die targets.xml musste für den vorliegenden Fall angepasst werden.
Die tasks "compile-server" und "compile-client" mussten ergänzt werden:
<target name="compile-server" depends="prepare"
description="Compiles the server-side source code">
<echo message="Compiling the server-side source code...."/>
<javac
srcdir="."
destdir="${build}/shared"
includes="Verwaltung*.java,EarthCoord.java,CoordTransform.jav
a,GPSNMEA.java,Authorize.java"
excludes="*Client.java"
/>
</target>
<target name="compile-client" depends="prepare"
description="Compiles the client-side source code"
>
<echo message="Compiling the client source code...."/>
<javac
srcdir="."
destdir="${build}/client"
classpath="${root-path}:${jwsdp-jars}:${examplepath}:c:\java\jsuite\jsuite\jars\pvxChart.jar:build/shared:bu
ild/client"
includes="clientAPI.java,VerwaltungClient.java"
/>
</target>
Das Attribute includes musste jeweils um alle einzubeziehenden Komponenten ergänzt werden.
Das Attribut classpath enthält zusätzliche Pakete die nötig sind um den Client zu erstellen.
In diesem Beispiel sind dies die Infragistics 1Komponenten.
1
Die Infragistics Komponenten bieten die Möglichkeit Graphiken und Diagramme in Swing Anwendungen
einzusetzen
Seite 126
Web-Services zur Datenintegration mobiler Endgeräte
8.3.2 Web-Service konfigurieren
Die Konfiguration eines Web-Service erfolgt über folgende XML-Dateien:
jaxrpc-ri.xml
web.xml
8.3.2.1 jaxrpc-ri.xml
Diese XML-Datei kann wie folgt aussehen:
<?xml version="1.0" encoding="UTF-8"?>
<Web-Services
xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/dd"
version="1.0"
targetNamespaceBase="http://com.test/wsdl"
typeNamespaceBase="http://com.test/types"
urlPatternBase="/ws">
<endpoint
name="MyVerwaltung"
displayName="Middleware WebService"
description="Middleware WebService"
interface="middleware.VerwaltungIF"
implementation="middleware.Verwaltung"/>
<endpointMapping
endpointName="MyVerwaltung"
urlPattern="/Verwaltung"/>
</Web-Services>
Die Datei enthält wichtige Informationen den Web-Service-Endpunkt betreffend, neben der URL also hier /Verwaltung über den der Web-Service auf dem Server veröffentlicht wird, werden
Informationen wie Interface und Implementierung angegeben, die die Umsetzung des Web-Services
betreffen.
Seite 127
Web-Services zur Datenintegration mobiler Endgeräte
8.3.2.2 web.xml
Die Datei web.xml wird automatisch erzeug und kann wie folgt aussehen:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">
<web-app>
<display-name>Middleware Web-Service</display-name>
<description>DA Web-Service</description>
<session-config>
<session-timeout>60</session-timeout>
</session-config>
</web-app>
8.3.3
Erstellen, Veröffentlichen und Aufrufen eines Web-Services
Folgende Aufrufe des ant Werkzeuges müssen erfolgen:
ant build – Kompilieren der Server-Dateien – Erstellen des WAR-Archivs
ant deploy – Veröffentlichen des Web-Service auf dem Tomcat Server
ant build-dynamic – Kompilieren der Client-Dateien – Erstellen des JAR-Archivs
ant run – Ausführen des Client
8.3.4
Datenbank
Der vorliegende Web-Service greift auf eine Datenbank über einen JDBC-Treiber zu. Um diesen
Zugriff zu ermöglichen, müssen folgende Einstellungen erfolgen. Dies wird beispielhaft für den
Zugriff auf PostgreSQL beschrieben verläuft aber für andere Datenbanktreiber analog.
Der Datenbanktreiber, der in einer JAR-Archivdatei namens postgresql.jar enthalten ist, muss
installiert werden. Alle Dateien im JAR-Archiv müssen in einen Ordner extrahiert werden, der in der
PATH-Variable referenziert wird. (Leider ist eine Aufnahme der JAR-Archivdatei in den
CLASSPATH ohne Erfolg geblieben, so dass auf erstere Variante zurückgegriffen wurde).
Seite 128
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 9: Anhang B
Statuscodes im Fehlerfall
9.1 Statuscodes der Middleware und ihre Bedeutung
Statuscodes allgemein
Status Code
Beschreibung
000
Alles in Ordnung
Statuscodes des Endgeräts
Status Code
Beschreibung
101
Endgerät nicht erreichbar
102
XML-Datei kann nicht verarbeitet werden
103
URL fehlerhaft
104
Attribut ID fehlerhaft
105
Attribut Uptime fehlerhaft
106
Attribut Number fehlerhaft
107
Attribut E-Mail fehlerhaft
Statuscodes einer Datenquelle (x gibt die Nummer der betroffenen Quelle an)
Status Code
Beschreibung
2x1
Endgerät nicht erreichbar
2x2
XML-Datei kann nicht verarbeitet werden
2x3
URL fehlerhaft
2x4
Attribut ID fehlerhaft
2x5
Attribut Status fehlerhaft
2x6
Attribut Refreshrate fehlerhaft
2x7
Attribut Measurement fehlerhaft
Statuscodes der Messwerte bezüglich einer Datenquelle (x gibt die Nummer der betroffenen Quelle an, y die
Nummer des betroffenen Messwerts)
Status Code
Beschreibung
3x1
Endgerät nicht erreichbar
3x2
XML-Datei kann nicht verarbeitet werden
3x3
URL fehlerhaft
3xy4
Attribut Type fehlerhaft
3xy5
Attribut Datatype fehlerhaft
Seite 129
Web-Services zur Datenintegration mobiler Endgeräte
3xy6
Attribut Unit fehlerhaft
3xy7
Attribut Datetime fehlerhaft
3xy8
Attribut Wert fehlerhaft
3xy9
Attribut Position fehlerhaft
Statuscodes des GPS Strings eines Messwerts bezüglich einer Datenquelle (x gibt die Nummer der betroffenen
Quelle an, y die Nummer des betroffenen Messwerts)
Status Code
Beschreibung
4xy1
GPS Struktur fehlerhaft
4xy2
4xy3
4xy4
4xy5
4xy6
4xy7
4xy8
4xy9
GPS Breitengrad nicht in korrektem Format
DD.MMMMMM
GPS Breitengrad Gradangabe DD keine Zahl
GPS Breitengrad Minutenangabe MMMMMM keine
Zahl
GPS Breitengrad Richtungsangabe nicht korrekt
(muss N oder S sein)
GPS Längengrad nicht in korrektem Format
DD.MMMMMM
GPS Längengrad Gradangabe DD keine Zahl
GPS Längengrad Minutenangabe MMMMMM keine
Zahl
GPS Längengrad Richtungsangabe nicht korrekt
(muss W oder E sein)
Statuscodes der Datenbank
Status Code
Beschreibung
701
Datenbanktreiber nicht korrekt
702
Datenbankverbindung kann nicht hergestellt werden
710-dbmessage
72x
73xy
Fehler bei Einlagern der Daten der entity.xml Datei
- dbmessage enthält weitere Angaben
Fehler bei Einlagern der Daten der sourcex.xml
Datei – dbmessage enthält weitere Angaben
Fehler bei Einlagern des Messeintrags x in der
Messdatei y – dbmessage enthält weitere Angaben
Tabelle 30: Statuscodes der Middleware
Seite 130
Web-Services zur Datenintegration mobiler Endgeräte
9.2 Statuscodes und zu treffende Maßnahmen
Statuscodes allgemein
Status Code
Beschreibung
000
Alles in Ordnung
Statuscodes des Endgeräts
Status Code
Beschreibung
101
Alle Daten werden verworfen
102
Alle Daten werden verworfen
103
Alle Daten werden verworfen
104
Alle Daten werden verworfen
105
Alle Daten werden verworfen
106
Alle Daten werden verworfen
korrekte Daten werden angenommen
107
Attribut E-Mail wird nicht in der Datenbank abgelegt
(es findet somit nur eine Benachrichtigung statt, falls
der Wert bereits in der Datenbank verzeichnet ist)
Statuscodes einer Datenquelle (x gibt die Nummer der betroffenen Quelle an)
Status Code
Beschreibung
2x1
Daten der Quelle werden verworfen
2x2
Daten der Quelle werden verworfen
2x3
Daten der Quelle werden verworfen
2x4
Daten der Quelle werden verworfen
2x5
Daten der Quelle werden verworfen
2x6
Daten der Quelle werden verworfen
2x7
Attribut Measurement fehlerhaft
Statuscodes der Messwerte bezüglich einer Datenquelle (x gibt die Nummer der betroffenen Quelle an, y die
Nummer des betroffenen Messwerts)
Status Code
Beschreibung
3x1
Daten der Quelle werden verworfen
3x2
Daten der Quelle werden verworfen
3x3
Daten der Quelle werden verworfen
3xy4
Daten der Quelle werden verworfen
3xy5
Daten der Quelle werden verworfen
3xy6
Daten der Quelle werden verworfen
Seite 131
Web-Services zur Datenintegration mobiler Endgeräte
3xy7
Daten der Quelle werden verworfen
3xy8
Daten der Quelle werden verworfen
3xy9
Daten der Quelle werden verworfen
Statuscodes des GPS Strings eines Messwerts bezüglich einer Datenquelle (x gibt die Nummer der betroffenen
Quelle an, y die Nummer des betroffenen Messwerts)
Status Code
Beschreibung
4xy1
Daten der Quelle werden verworfen
4xy2
Daten der Quelle werden verworfen
4xy3
Daten der Quelle werden verworfen
4xy4
Daten der Quelle werden verworfen
4xy5
Daten der Quelle werden verworfen
4xy6
Daten der Quelle werden verworfen
4xy7
Daten der Quelle werden verworfen
4xy8
Daten der Quelle werden verworfen
4xy9
Daten der Quelle werden verworfen
Statuscodes der Datenbank
Status Code
Beschreibung
7x1
Alle Daten werden verworfen
7x2
Alle Daten werden verworfen
7x3
Alle Daten werden verworfen
Tabelle 31: Zuordnung Statuscode - zu treffende Maßnahme
Seite 132
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 10:
Anhang C
Erläuterungen zum Datenbankschema
Das Entity Relationship Modell (ERM) aus Abbildung 20 wird in ein Datenbankschema überführt.
Die im ERM befindlichen werden bis auf zwei Ausnahmen (cost und bill) durch gleichnamige
Tabellen abgebildet. Dazu werden die einzelnen Relationen entweder anhand von FremdschlüsselEinträgen in den vorhandenen Tabellen oder durch Einfügen neuer Tabellen (die die entsprechenden
Fremdschlüssel-Abbildungen enthalten) realisiert.
Folgend werden die einzelnen Tabellen (inklusive aller Attribute erläutert), die Abbildung der
einzelnen Relationen des ERM wird jeweils dargelegt.
entity
Die Tabelle entity verwaltet alle Endgeräte die zu irgendeinem Zeitpunkt an der Middleware
angemeldet waren.
Name
Typ
Beschreibung
id
VARCHAR(100)
Identifikation des Endgeräts
ipaddress
VARCHAR(50)
IP-Adresse des Endgeräts
email
VARCHAR(100)
E-Mail Adresse des Endgeräte
Administrators
activeentity
Die Tabelle activeentity verwaltet alle Endgeräte die zum aktuellen Zeitpunkt angemeldet sind.
Name
Typ
id
VARCHAR(100)
uptime
int4
Beschreibung
IP-Adresse des Endgeräts –
Fremdschlüssel – bildet Relation zwischen entity und activeentity ab
Zeitspanne nach der Endgerät zur Verfügung steht - Zeitrahmen in dem
Update erfolgt (in Sekunden)
Seite 133
Web-Services zur Datenintegration mobiler Endgeräte
datasource
Die Tabelle datasource verwaltet alle Datenquellen (Sensoren etc.) der Endgeräte.
Name
Typ
Beschreibung
id
VARCHAR(100)
Identifikation der Datenquelle
Verweis auf die IP-Adresse des Endgeräts, dem die
entityid
VARCHAR(100)
Datenquelle angehört
Fremdschlüssel – bildet Relation zwischen entity und
datasource ab
description
int4
Beschreibung bezüglich der Datenquelle
status
boolean
Status der Datenquelle, steht die Datenquelle zur Verfügung
refreshrate
int4
Zeitspanne nach der Datenquelle neue Daten zur Verfügung
stellt (in Sekunden)
data
Die Tabelle data enthält alle gemessenen Werte, sowie Daten aller Endgeräte die zur Verfügung
stehen.
Name
Typ
Beschreibung
type
VARCHAR(20)
Typ der Messung
datatype
VARCHAR(30)
Datentyp des Messwerts
unit
VARCHAR(30)
Einheit des Messwerts
date
date
Zeitpunkt der Messung
time
time
Zeitpunkt der Messung
value
VARCHAR(200)
Daten
position
String
GPS-Position der Datenquelle
id
VARCHAR(100)
Verweis auf die Datenquelle der die Daten angehören
Fremdschlüssel
Verweis auf die IP-Adresse des Endgeräts, dem die
entityid
VARCHAR(100)
Datenquelle angehört
Fremdschlüssel
Anhand der Einträge id und entityid (Fremdschlüssel) wird die Relation zwischen entity, datasource
und data realisiert.
users
Die Tabelle users verwaltet alle Benutzer die Zugriff auf die Daten der Middleware haben
Seite 134
Web-Services zur Datenintegration mobiler Endgeräte
Name
Typ
Beschreibung
username
VARCHAR(100)
Benutzername
password
VARCHAR(100)
Passwort des Benutzers
role
Die Tabelle role verwaltet alle Rollen
Name
Typ
Beschreibung
rolename
VARCHAR(100)
Rolle
description
VARCHAR(100)
Beschreibung der Rolle
users2Role
Die Tabelle users2Role ordnet den Benutzern Rollen zu.
Diese Tabelle realisiert die Relation zwischen users und role
Name
Typ
username
VARCHAR(100)
rolename
VARCHAR(100)
Beschreibung
Benutzer
Fremdschlüssel
Rolle
Fremdschlüssel
data2Role
Die Tabelle Data2Role ordnet Dateneinträgen Rollen zu.
Diese Tabelle realisiert die Relation zwischen role, entity und datasource
Name
Typ
entityid
VARCHAR(100)
sourceid
VARCHAR(100)
rolename
VARCHAR(100)
Beschreibung
Identifikation eines Endgeräts
Fremdschlüssel
ID einer Quelle
Fremdschlüssel
Rolle
Fremdschlüssel
data2Cost
Die Tabelle Data2Cost ordnet Dateneinträgen Kosten zu.
Diese Tabelle realisiert zum einen die Tabelle cost durch die Einträge cost und type, zum anderen die
Relation zwischen cost, entity und datasource
Seite 135
Web-Services zur Datenintegration mobiler Endgeräte
Name
Typ
Beschreibung
entityid
VARCHAR(100)
id
VARCHAR(100)
type
VARCHAR(5)
ONE, PER
cost
VARCHAR(100)
Kosten
Identifikation eines Endgeräts
Fremdschlüssel
ID einer Quelle
Fremdschlüssel
bill2User
Die Tabelle bill2User verwaltet angefallen Rechnungen und ordnet diesen Benutzern zu.
Diese Tabelle realisiert die Tabelle bill und die Relation zwischen bill und users.
Name
Typ
billname
VARCHAR(100)
username
VARCHAR(100)
pit
VARCHAR(5)
Beschreibung
IP Adresse eines Endgeräts
Fremdschlüssel
Benutzername
Fremdschlüssel
Zeitpunkt des Eintrags
Seite 136
Web-Services zur Datenintegration mobiler Endgeräte
Kapitel 11:
Anhang D
Validierung anhand von Testfällen
Dieser Anhang enthält eine Reihe von Testfällen, anhand welcher die einzelnen Funktionen der
Komponenten und zum Teil auch direkt ganze Komponenten validiert wurden. Es handelt sich
keinesfalls um eine vollständige Validierung. Es wurde versucht zu den einzelnen Funktionen alle
möglichen Eingabeklassen zu unterscheiden und anhand von Beispielwerten aus diesen Klassen die
einzelnen Funktionen zu testen. Das Ergebnis dieser Tests wird folgend dargestellt.
11.1 Validierung
Gegenstand der Validierung sind:
Komponente
Test
Authorize
Middleware
OK
CoordTransform
Middleware
OK
DataHandler
Middleware
OK
EarthCoord
Middleware
OK
EntityHandler
Middleware
OK
GPSCheck
Middleware
OK
GPSNMEA
Middleware
OK
MeasHandler
Middleware
OK
Payment
Middleware
OK
Server
Middleware
OK
SourceHandler
Middleware
OK
Update
Middleware
OK
Registrierung
Middleware
OK
Verwaltung
Middleware
OK
ClientAPI
Middleware
OK
Registrierung
Middleware
OK
Config
Middleware
OK
chipmodul
Mobiles Endgerät
OK
CGI-Modul
Daten-Server
OK
Seite 137
Web-Services zur Datenintegration mobiler Endgeräte
11.1.1 Middleware Komponente Server, Komponente Registrierung
Diese beiden Komponenten werden im Zusammenspiel mit der Komponente Update getestet
11.1.2 Middleware Komponente Update
Methode
Beschreibung
Test
parseEntityConfig
OK
checkEntityHandler
OK
parseSourceConfig
OK
checkSourceHandler
OK
parseMeasurementConfig
OK
checkMeasurementHandler
OK
notifyAdmin
OK
emptyTable
OK
getEMail
OK
getLimit
OK
getRefreshrate
OK
isRegistered
OK
unregisterEntity
OK
werden durch einen
Validierungsschritt
main
abgedeckt
updateData
Im Rahmen dieser
writetoDB
Methoden wird die
Klasse Server, sowie die
Klasse Registrierung
getestet.
Seite 138
OK
Web-Services zur Datenintegration mobiler Endgeräte
11.1.2.1 Methoden main, updateData, writeDB
Testfall 1: Server Komponente wird durch einen Daten-Server angestoßen, der ein Update seiner
Daten anfordert
Erwartetes Verhalten
Tatsächliches Verhalten
Update Result: 000 und falls nötig Daten in
Datenbank einbinden
Fehler: NumberFormatException
Komponente EntityHandler – falsches zuweisen
der E-Mail Adresse
Ursache
Aufgefallen ist des Weiteren, dass bei
Überprüfung des Endgerättypus eine falsche
Prüfung stattfindet
Nach beheben der Fehler
Erwartetes Verhalten
Update Result: 000 und falls nötig Daten in
Datenbank einbinden
Tatsächliches Verhalten
Datenbank Fehler: ) Syntax error
Ursache
Methode writeDB ')' unnötig in SQL Anfrage
Nach beheben des Fehlers
Erwartetes Verhalten
Tatsächliches Verhalten
Ursache
Update Result: 000 und falls nötig Daten in
Datenbank einbinden
Fehler: E-Mail wird an Administrator gesendet,
obwohl kein Fehler vorliegt
Fehlercode wird im Erfolgsfall nicht auf OKWert "000" gesetzt
Nach beheben des Fehlers
Erwartetes Verhalten
Tatsächliches Verhalten
Update Result: 000 und falls nötig Daten in
Datenbank einbinden
Update Result: 000 – Daten nicht eingebunden da
bereits vorhanden
Testfall 2: Server Komponente wird durch ein mobiles Endgerät angestoßen, das eine Registrierung
anfordert
Erwartetes Verhalten
Tatsächliches Verhalten
Registrierung annehmen und in regelmäßigen
Abständen Update Vorgang anstoßen
Tritt ein
Seite 139
Web-Services zur Datenintegration mobiler Endgeräte
Testfall 3: basiert auf Testfall 2 : Endgerät wird ausgeschaltet
Nach dreimaligem Überprüfen muss die
Erwartetes Verhalten
Registrierung des Geräts rückgängig gemacht
werden
Tatsächliches Verhalten
Tritt ein
Testfall 4: basiert auf Testfall 2 : Endgerät wird abgemeldet
Erwartetes Verhalten
Registrierung muss aufgehoben werden
Tatsächliches Verhalten
Tritt ein
11.1.2.2 Methode getEMail
IP-Adresse 131.246.103.162 wird übergeben
Erwartetes Verhalten
E-Mail zurückliefern
Tatsächliches Verhalten
E-Mail zurückgeliefert
11.1.2.3 Methode getLimit
Limit ermitteln(Limit Parameter ist auf 3 gesetzt)
Erwartetes Verhalten
Limit 3 liefern
Tatsächliches Verhalten
Limit 3 geliefert
11.1.2.4 Methode getRefreshrate
IP-Adresse 131.246.103.162 wird übergeben
Erwartetes Verhalten
Refreshrate liefern
Tatsächliches Verhalten
Refreshrate zurückgeliefert
11.1.2.5 Methode isRegistered
IP-Adresse 131.246.103.162 wird übergeben (diese ist nicht registriert)
Erwartetes Verhalten
false liefern
Tatsächliches Verhalten
false zurückgeliefert
IP-Adresse 131.246.103.162 wird übergeben (diese ist registriert)
Erwartetes Verhalten
true liefern
Tatsächliches Verhalten
true zurückgeliefert
Seite 140
Web-Services zur Datenintegration mobiler Endgeräte
11.1.2.6 Methode unregisterEntity
IP-Adresse 131.246.103.162 wird übergeben
Erwartetes Verhalten
Registrierung des Endgeräts aufheben
Tatsächliches Verhalten
tritt ein
11.1.2.7 Methode notfiyAdmin
Alle Parameter OK
Erwartetes Verhalten
E-Mail an entsprechenden Empfänger senden
Tatsächliches Verhalten
E-Mail an entsprechenden Empfänger gesendet
Parameter recipient oder Parameter mailhost nicht vorhanden
Erwartetes Verhalten
tue nichts
tut nichts
Hier wird eine NullPointerException ausgegeben,
Tatsächliches Verhalten
obwohl diese explizit abgefangen wird, dies
beeinträchtigt das Verhalten des Systems nicht.
11.1.2.8 Methode emptyTable
Tabelle activeEntity enthält einen Eintrag
Erwartetes Verhalten
Tabelle ist leer
Tatsächliches Verhalten
Tabelle ist leer
11.1.2.9 Methode parseEntityConfig, Methode checkEntityHandler, Objekt EntityHandler
XML-Dokument nicht vorhanden
Erwartetes Verhalten
Statuscode 101 liefern
Tatsächliches Verhalten
Statuscode 101
XML-Dokument leer oder fehlerhaft
Erwartetes Verhalten
Statuscode 102 liefern
Tatsächliches Verhalten
Statuscode 102
XML-Dokument Attribut Tag fehlt oder ist leer
Erwartetes Verhalten
Statuscode 104 liefern
Tatsächliches Verhalten
Statuscode 104
Seite 141
Web-Services zur Datenintegration mobiler Endgeräte
XML-Dokument Attribut Tag fehlt oder ist leer oder ist keine Zahl
Erwartetes Verhalten
Statuscode 105 liefern
Tatsächliches Verhalten
Statuscode 105
XML-Dokument Attribut Tag fehlt oder ist leer oder ist keine Zahl
Erwartetes Verhalten
Statuscode 106 liefern
Tatsächliches Verhalten
Statuscode 106
XML-Dokument Attribut Tag fehlt oder ist leer
Erwartetes Verhalten
Statuscode 107 liefern
Tatsächliches Verhalten
Statuscode 106-106-107
EntityHandler
Ursache
der Wert des Attributs email wird in Variable
number gespeichert.
Nach beheben des Fehlers:
Erwartetes Verhalten
Statuscode 107 liefern
Tatsächliches Verhalten
Statuscode 107
XML-Dokument enthält keines der Tags id, uptime, number, email
Erwartetes Verhalten
Statuscode 104-105-106-107 liefern
Tatsächliches Verhalten
Statuscode 104-105-106-107
XML-Dokument korrekt
Erwartetes Verhalten
Statuscode 000 liefern
Tatsächliches Verhalten
Statuscode 107
checkEntityHandler() in Update
Ursache
überflüssiges Zeile die bei leerem Statuscode den
Statuscode auf 107 gesetzt
Nach beheben des Fehlers:
Erwartetes Verhalten
Statuscode 000 liefern
Tatsächliches Verhalten
Statuscode 000
11.1.2.10 Methode parseSourceConfig, Methode checkSourceHandler, Objekt SourceHandler
XML-Dokument nicht vorhanden
Erwartetes Verhalten
Statuscode 211 liefern
Tatsächliches Verhalten
Statuscode 211
Seite 142
Web-Services zur Datenintegration mobiler Endgeräte
XML-Dokument leer oder fehlerhaft
Erwartetes Verhalten
Statuscode 212 liefern
Tatsächliches Verhalten
Statuscode 212
XML-Dokument Attribut id fehlt oder ist leer
Erwartetes Verhalten
Statuscode 214 liefern
Tatsächliches Verhalten
Statuscode 214
XML-Dokument Tag status fehlt oder ist leer oder ist keine Zahl
Erwartetes Verhalten
Statuscode 215 liefern
Tatsächliches Verhalten
Statuscode 215
XML-Dokument Tag refreshrate fehlt oder ist leer oder ist keine Zahl
Erwartetes Verhalten
Statuscode 216 liefern
Tatsächliches Verhalten
Statuscode 216
XML-Dokument Tag measurement fehlt oder ist leer
Erwartetes Verhalten
Statuscode 217 liefern
Tatsächliches Verhalten
Statuscode 217
XML-Dokument enthält keines der Tags id, status, refreshrate, measurement
Erwartetes Verhalten
Statuscode 104-105-106-107 liefern
Tatsächliches Verhalten
Statuscode 104-105-106-107
XML-Dokument korrekt
Erwartetes Verhalten
Statuscode 000 liefern
Tatsächliches Verhalten
Statuscode 000
11.1.2.11 Methode parseMeasurementConfig, Methode checkMeasurementHandler, Objekt
MeasurementHandler
XML-Dokument nicht vorhanden
Erwartetes Verhalten
Statuscode 3111 liefern
Tatsächliches Verhalten
Statuscode 3111
XML-Dokument leer oder fehlerhaft
Erwartetes Verhalten
Statuscode 3112 liefern
Tatsächliches Verhalten
Statuscode 3112
Seite 143
Web-Services zur Datenintegration mobiler Endgeräte
XML-Dokument Attribut type fehlt oder ist leer
Erwartetes Verhalten
Statuscode 3114 liefern
Tatsächliches Verhalten
Statuscode 3114
XML-Dokument Attribut datatype fehlt oder ist leer
Erwartetes Verhalten
Statuscode 3115 liefern
Tatsächliches Verhalten
Statuscode 3115
XML-Dokument Attribut unit fehlt oder ist leer
Erwartetes Verhalten
Statuscode 3116 liefern
Tatsächliches Verhalten
Statuscode 3116
XML-Dokument Attribut datatype fehlt oder ist leer
Erwartetes Verhalten
Statuscode 3117 liefern
Tatsächliches Verhalten
Statuscode 3114
checkEntityHandler() in Update
Ursache
überflüssiges Zeile die bei leerem Statuscode den
Statuscode auf 107 gesetzt
Nach beheben des Fehlers:
Erwartetes Verhalten
Statuscode 3117 liefern
Tatsächliches Verhalten
Statuscode 3117
XML-Dokument Attribut position fehlt oder ist leer
Erwartetes Verhalten
Statuscode 3115 liefern
Tatsächliches Verhalten
Exception IndexoutOfBounds
Ursache
Else Verzweigung fehlt bei Überprüfung ob
Variable position leer ist
Nach beheben des Fehlers:
Erwartetes Verhalten
Statuscode 3117 liefern
Tatsächliches Verhalten
Statuscode 3117
An dieser Stelle wird nun die Komponente GPSCheck mit in die Tests einbezogen, die eine exakten
Hinweis auf den Fehler in einem GPS NMEA String liefern kann:
XML-Dokument Attribut position: Struktur des GPS NMEA Strings fehlerhaft
Erwartetes Verhalten
Statuscode 3119-4111 liefern
Tatsächliches Verhalten
Statuscode 3119-4111
Seite 144
Web-Services zur Datenintegration mobiler Endgeräte
XML-Dokument Attribut position: GPS NMEA String Breitengrad falsches Format
Erwartetes Verhalten
Statuscode 3119-4112 liefern
Tatsächliches Verhalten
Statuscode 3119-4112
XML-Dokument Attribut position: GPS NMEA String Breitengrad Grad Angabe keine Zahl
Erwartetes Verhalten
Statuscode 3119-4113 liefern
Tatsächliches Verhalten
Statuscode 3119-4113
XML-Dokument Attribut position: GPS NMEA String Breitengrad Minuten Angabe keine Zahl
Erwartetes Verhalten
Statuscode 3119-4114 liefern
Tatsächliches Verhalten
Statuscode 3119-4114
XML-Dokument Attribut position: GPS NMEA String Breitengrad Richtungsangabe fehlerhaft
Erwartetes Verhalten
Statuscode 3119-4115 liefern
Tatsächliches Verhalten
Statuscode 3119-4115
XML-Dokument Attribut position: GPS NMEA String Längengrad falsches Format
Erwartetes Verhalten
Statuscode 3119-4116 liefern
Tatsächliches Verhalten
Statuscode 3119-4116
XML-Dokument Attribut position: GPS NMEA String Längengrad Grad Angabe keine Zahl
Erwartetes Verhalten
Statuscode 3119-4117 liefern
Tatsächliches Verhalten
Statuscode 3119-4117
XML-Dokument Attribut position: GPS NMEA String Längengrad Minuten Angabe keine Zahl
Erwartetes Verhalten
Statuscode 3119-4118 liefern
Tatsächliches Verhalten
Statuscode 3119-4118
XML-Dokument Attribut position: GPS NMEA String Längengrad Richtungsangabe fehlerhaft
Erwartetes Verhalten
Statuscode 3119-4119 liefern
Tatsächliches Verhalten
Statuscode 3119-4119
XML-Dokument enthält keines der tags type, datatype, unit, datetime, position
Erwartetes Verhalten
Statuscode 104-105-106-107 liefern
Tatsächliches Verhalten
Statuscode 104-105-106-107
Seite 145
Web-Services zur Datenintegration mobiler Endgeräte
XML-Dokument korrekt
Erwartetes Verhalten
Statuscode 000 liefern
Tatsächliches Verhalten
Statuscode 000
11.1.3 Middleware Komponente Config
11.1.3.1 Methode loadConfig
Konfigurationsdatei nicht vorhanden
Erwartetes Verhalten
Fehlermeldung liefern
Tatsächliches Verhalten
Fehlermeldung geliefert
Parameter adminemail fehlt oder ist leer
Erwartetes Verhalten
Tatsächliches Verhalten
Fehlermeldung liefern
Komponente beenden
Fehlermeldung geliefert
Komponente beendet
Parameter mailhost fehlt oder ist leer
Erwartetes Verhalten
Tatsächliches Verhalten
Fehlermeldung liefern
Komponente beenden
Fehlermeldung geliefert
Komponente beendet
Parameter db_driver fehlt oder ist leer
Fehlermeldung liefern
Erwartetes Verhalten
E-Mail an Admin senden
Komponente beenden
Fehlermeldung geliefert
Tatsächliches Verhalten
E-Mail an Admin gesendet
Komponente beendet
Seite 146
Web-Services zur Datenintegration mobiler Endgeräte
Parameter db_url fehlt oder ist leer
Fehlermeldung liefern
Erwartetes Verhalten
E-Mail an Admin senden
Komponente beenden
Tatsächliches Verhalten
Fehlermeldung geliefert
E-Mail an Admin gesendet
Parameter db_usr fehlt oder ist leer
Fehlermeldung liefern
Erwartetes Verhalten
E-Mail an Admin senden
Komponente beenden
Fehlermeldung geliefert
Tatsächliches Verhalten
E-Mail an Admin gesendet
Komponente beendet
Parameter db_pwd fehlt oder ist leer
Fehlermeldung liefern
Erwartetes Verhalten
E-Mail an Admin senden
Komponente beenden
Fehlermeldung geliefert
Tatsächliches Verhalten
E-Mail an Admin gesendet
Komponente beendet
Parameter db_driver ist fehlerhaft (entsprechende Klasse kann auf System nicht gefunden werden)
Fehlermeldung liefern
Erwartetes Verhalten
E-Mail an Admin senden
Komponente beenden
Fehlermeldung geliefert
Tatsächliches Verhalten
E-Mail an Admin gesendet
Komponente beendet
Seite 147
Web-Services zur Datenintegration mobiler Endgeräte
Parameter db_driver fehlt oder ist leer
Fehlermeldung liefern
Erwartetes Verhalten
E-Mail an Admin senden
Komponente beenden
Fehlermeldung geliefert
Tatsächliches Verhalten
E-Mail an Admin gesendet
Komponente beendet
Verbindung zu Datenbank kann aufgrund eines der Parameter db_url, db_usr, db_pwd nicht
hergestellt werden
Fehlermeldung liefern
Erwartetes Verhalten
E-Mail an Admin senden
Komponente beenden
Fehlermeldung geliefert
Tatsächliches Verhalten
E-Mail an Admin gesendet
Komponente beendet
Parameter limit nicht vorhanden oder leer
Fehlermeldung liefern
Erwartetes Verhalten
E-Mail an Admin senden
Komponente beenden
Fehlermeldung geliefert
Tatsächliches Verhalten
E-Mail an Admin gesendet
Komponente beendet
11.1.4 Middleware Komponente Authorization
Methode
Test
grantAccess
OK
11.1.4.1 Methode grantAccess
Durch verschiedene Datenbankkonfigurationen und Übergaben wird überprüft ob in diesen
Situationen der Zugriff erlaubt oder verweigert wird.
Benutzername nicht in Datenbank enthalten
Erwartetes Verhalten
false zurückliefern
Tatsächliches Verhalten
false zurückgeliefert
Seite 148
Web-Services zur Datenintegration mobiler Endgeräte
Passwort nicht korrekt
Erwartetes Verhalten
false zurückliefern
Tatsächliches Verhalten
false zurückgeliefert
Alles korrekt
Erwartetes Verhalten
true zurückliefern
Tatsächliches Verhalten
true zurückgeliefert
11.1.5 Middleware Komponente Payment
Methode
Beschreibung
wurde bereits in Update
notifyAdmin
getestet
wurde bereits in Update
loadConfig
getestet
Test
OK
OK
Diese Methoden werden
getCost
durch einen
getCost
Validierungsschritt
OK
abgedeckt.
Diese Methoden werden
getBill
durch einen
getBill
Validierungsschritt
writeBill
OK
abgedeckt.
isPaymentGranted
nicht möglich
*
Im Rahmen dieser Validierungstests werden gewisse Zustände vorausgesetzt:
Da diese Komponente immer der Komponente Authorize folgt, werden immer nur autorisierte
Messergebnisse übergeben. Dieser Zustand wird in die Generierung der Tests mit einbezogen.
11.1.5.1 Methoden getCost, getCost
Testfall 1
Es wird eine Messergebnis-Liste mit folgenden Einträgen übergeben:
IP-Adresse
ID
Anzahl
131.246.103.160
temp1
31
131.246.103.160
regen1
37
131.246.103.162
temp1
2
Seite 149
Web-Services zur Datenintegration mobiler Endgeräte
131.246.103.162
regen1
2
Folgendes Kostenprofil wird zugrunde gelegt:
IP-Adresse
ID
Typ
Kosten
131.246.103.160
temp1
Zahlung pro Datenquelle
2
131.246.103.160
regen1
Zahlung pro Eintrag
2
131.246.103.162
temp1
Zahlung pro Eintrag
2
131.246.103.162
regen1
Zahlung pro Eintrag
2
Theoretisch ergäben sich folgende Kosten:
IP-Adresse
ID
Kosten
131.246.103.160
temp1
1*2
131.246.103.160
regen1
37*2
131.246.103.162
temp1
1*2
131.246.103.162
regen1
1*2
80
Erwartetes Verhalten
Wert 80 liefern
Tatsächliches Verhalten
Wert 80 geliefert
Testfall 2
Wie Testfall 1 nur , dass nun folgendes Kostenprofil zugrunde gelegt wird:
IP-Adresse
ID
Typ
Kosten
131.246.103.160
temp1
Zahlung pro Datenquelle
2
131.246.103.160
regen1
Zahlung pro Eintrag
2
131.246.103.162
temp1
Zahlung pro Eintrag
2
Es wurde also das Kostenprofil für 131.246.103.160 regen1 gelöscht.
Dies bedeutet, dass die entsprechenden Daten kostenfrei sind und dementsprechend nicht in die
Berechnung eingehen dürfen.
Theoretisch ergäben sich folgende Kosten:
IP-Adresse
ID
Kosten
131.246.103.160
temp1
1*2
131.246.103.160
regen1
0
131.246.103.162
temp1
1*2
Seite 150
Web-Services zur Datenintegration mobiler Endgeräte
131.246.103.162
regen1
1*2
6
Erwartetes Verhalten
Wert 6 liefern
Tatsächliches Verhalten
Wert 6 geliefert
Testfall 3
Die öffentliche Methode getCost wird mit einer leeren Messergebnis-Liste aufgerufen
Erwartetes Verhalten
Wert 0.0 liefern
Tatsächliches Verhalten
Wert 0.0 geliefert
11.1.5.2 Methode getBill, getBill, writeBill
Obige Konstellationen werden erneut verwendet um diese drei Methoden zu testen.
Testfall 1
PDF Dokument generieren, dass obige Einträge
Erwartetes Verhalten
sowie die Endsumme enthält
Datenbankeintrag für diese PDF Datei
vornehmen
Tatsächliches Verhalten
PDF Dokument erstellt und Datenbankeintrag
korrekt vorgenommen
Testfall2
PDF Dokument generieren, dass obige Einträge
Erwartetes Verhalten
sowie die Endsumme enthält
Datenbankeintrag für diese PDF Datei
vornehmen
Tatsächliches Verhalten
PDF Dokument erstellt und Datenbankeintrag
korrekt vorgenommen
Testfall 3
Die öffentliche Methode writeBill wird mit einer leeren Messergebnis-Liste aufgerufen
Erwartetes Verhalten
nichts machen
Tatsächliches Verhalten
nichts gemacht
Seite 151
Web-Services zur Datenintegration mobiler Endgeräte
11.1.6 Middleware Komponente ClientAPI
Methode
Test
getErrorString
getMeasurementList
getStatus
OK
isEmpty
isErroneous
checkStatus
OK
getMeasurementbyEntity
OK
getMeasurementbyEntityPit
OK
getMeasurementbyEntityPeriod
OK
getMeasurementbyPosition
OK
getMeasurementbyPositionPit
OK
getMeasurementbyPositionPeriod
OK
getMeasurementbyEntitySource
OK
getMeasurementbyEntitySourcePit
OK
getMeasurementbyEntitySourcePeriod
OK
getMeasurementbyType
OK
getMeasurementbyType
OK
getMeasurementbyType
OK
getMeasurementbyTypePosition
OK
getMeasurementbyTypePositionPit
OK
getMeasurementbyTypePositionPeriod OK
getProcessedEntities,
addtoProcessedEntities,
OK
getNewEntities, containsEntity
Ein Reihe von Methoden wird unter Verwendung der unten aufgeführten Methoden validiert, da es
sich um unterstützende Methoden handelt. Es handelt sich um:
getErrorString
getMeasurementList
getStatus
isEmpty
isErroneous
Seite 152
Web-Services zur Datenintegration mobiler Endgeräte
11.1.6.1 Methode checkStatus
Rückgabe enthält kein Ergebnis
Endgerät
board1
Benutzername
tkoenig
Erwartetes Verhalten
Ausgabe : kein Ergebnis
Tatsächliches Verhalten
Ausgabe : kein Ergebnis
Eingabe war fehlerhaft (Benutzername kann nicht autorisiert werden)
Endgerät
board
Benutzername
tkoenig2
Erwartetes Verhalten
Ausgabe : 901
Tatsächliches Verhalten
Ausgabe : 901
11.1.6.2 Methode getMeasurementbyEntity
Endgerät
board
Benutzername
tkoenig
Erwartetes Verhalten
12 Ergebniseinträge liefern
Tatsächliches Verhalten
Ergebniseinträge geliefert
11.1.6.3 Methode getMeasurementbyEntityPit
IP-Addresse
131.246.103.160
Zeitpunkt
2003-01-20 11:06:19
Zeitdifferenz
5 Minuten
Benutzername
tkoenig
Erwartetes Verhalten
17 Ergebniseinträge liefern
Tatsächliches Verhalten
17 Ergebniseinträge geliefert
11.1.6.4 Methode getMeasurementbyEntityPeriod
IP-Adresse
131.246.103.160
Zeitraum
2003-01-01 bis 2003-01-18
Benutzername
tkoenig
Seite 153
Web-Services zur Datenintegration mobiler Endgeräte
Erwartetes Verhalten
9 Ergebniseinträge liefern
Tatsächliches Verhalten
9 Ergebniseinträge geliefert
11.1.6.5 Methode getMeasurementbyEntitySource
Endgerät
board
Quelle
temp1
Benutzername
tkoenig
Erwartetes Verhalten
471 Ergebniseinträge liefern
Tatsächliches Verhalten
471 Ergebniseinträge geliefert
11.1.6.6 Methode getMeasurementbyEntitySourcePit
Endgerät
board
Quelle
temp1
Zeitpunkt
2003-01-20 11:06:19
Zeitdifferenz
5 Minuten
Benutzername
tkoenig
Erwartetes Verhalten
5 Ergebniseinträge liefern
Tatsächliches Verhalten
5 Ergebniseinträge geliefert
11.1.6.7 Methode getMeasurementbyEntitySourcePeriod
Endgerät
board
Quelle
hell1
Zeitraum
21-1-2003 8:00:00 – 21-1-2003 10:00:00
Benutzername
tkoenig
Erwartetes Verhalten
24 Ergebniseinträge liefern
Tatsächliches Verhalten
24 Ergebniseinträge geliefert
11.1.6.8 Methode getMeasurementbyPosition
GPS Angabe
$GPGLL,4925.000000,N,0744.000000,E,180432.00,A,D*7A
Radius
15 Kilometer
Benutzername
tkoenig
Erwartetes Verhalten
852 Ergebniseinträge liefern
Tatsächliches Verhalten
852 Ergebniseinträge geliefert
Seite 154
Web-Services zur Datenintegration mobiler Endgeräte
11.1.6.9 Methode getMeasurementbyPositionPit
GPS Angabe
$GPGLL,4925.000000,N,0744.000000,E,180432.00,A,D*7A
Radius
15 Kilometer
Zeitpunkt
2003-01-16 22:40:00
1 Minute
Benutzername
tkoenig
Erwartetes Verhalten
2 Ergebniseinträge liefern
Tatsächliches Verhalten
2 Ergebniseinträge geliefert
11.1.6.10 Methode getMeasurementbyPositionPeriod
GPS Angabe
$GPGLL,4927.000000,N,0744.000000,E,180432.00,A,D*7A
Radius
15 Kilometer
Zeitraum
21-1-2003 8:00:00 – 21-1-2003 10:00:00
Benutzername
tkoenig
Erwartetes Verhalten
72 Ergebniseinträge liefern
Tatsächliches Verhalten
72 Ergebniseinträge geliefert
11.1.6.11 Methode getMeasurementbyType
Typ
temp
Benutzername
tkoenig
Erwartetes Verhalten
5 Ergebniseinträge liefern
Tatsächliches Verhalten
5 Ergebniseinträge geliefert
11.1.6.12 Methode getMeasurementbyTypePit
Typ
temp
Zeitpunkt
20-1-2003 11:06:19
Zeitdifferenz
5 Minuten
Benutzername
tkoenig
Erwartetes Verhalten
5 Ergebniseinträge liefern
Tatsächliches Verhalten
5 Ergebniseinträge geliefert
Seite 155
Web-Services zur Datenintegration mobiler Endgeräte
11.1.6.13 Methode getMeasurementbyTypePeriod
Typ
temp
Zeitraum
16-1-2003 – 17-1-2003
Benutzername
tkoenig
Erwartetes Verhalten
3 Ergebniseinträge liefern
Tatsächliches Verhalten
3 Ergebniseinträge geliefert
11.1.6.14 Methode getMeasurementbyTypePosition
Typ
temp
GPS Angabe
$GPGLL,4925.000000,N,0744.000000,E,180432.00,A,D*7A
Radius
15 Kilometer
Benutzername
tkoenig
Erwartetes Verhalten
31 Ergebniseinträge liefern
Tatsächliches Verhalten
31 Ergebniseinträge geliefert
11.1.6.15 Methode getMeasurementbyTypePositionPit
Typ
temp
Zeitpunkt
20-1-2003 11:06:19
Zeitdifferenz
5 Minuten
GPS Angabe
$GPGLL,4925.000000,N,0744.000000,E,180432.00,A,D*7A
Radius
15 Kilometer
Benutzername
tkoenig
Erwartetes Verhalten
1 Ergebniseinträge liefern
Tatsächliches Verhalten
1 Ergebniseinträge geliefert
11.1.6.16 Methode getMeasurementbyTypePositionPeriod
Typ
temp
Zeitraum
16-1-2003 – 17-1-2003
GPS Angabe
$GPGLL,4925.000000,N,0744.000000,E,180432.00,A,D*7A
Radius
15 Kilometer
Benutzername
tkoenig
Erwartetes Verhalten
3 Ergebniseinträge liefern
Tatsächliches Verhalten
3 Ergebniseinträge geliefert
Seite 156
Web-Services zur Datenintegration mobiler Endgeräte
11.1.6.17 Methode getEntitiesatDistance
ID
temp
Benutzername
tkoenig
Erwartetes Verhalten
2 Endgeräte liefern
Tatsächliches Verhalten
3 Endgeräte geliefert
11.1.6.18 Methode getSources
ID
temp
Endgerät
board
Benutzername
tkoenig
Erwartetes Verhalten
3 Quellen liefern
Tatsächliches Verhalten
3 Quellen geliefert
11.1.6.19 Methoden getProcessedEntities, addtoProcessedEntities, getNewEntities, containsEntity
Folgendes Szenario wird verwendet:
getEntitiesatDistance wird aufgerufen, Endgerät board wird als verarbeitet dem Objekt
ProcessedEntities hinzugefügt. Mittels getNewEntities und getProcessedEntities wird überprüft wie
der Status des Objekts ist:
ID
temp
Endgerät
board
Benutzername
tkoenig
Erwartetes Verhalten
Tatsächliches Verhalten
Processed Entities : board
New Entities : ds1
Processed Entities : board
New Entities : ds1
11.1.6.20 Methode getSum, getAverage, Methode getMax, Methode getMin
Es werden aufgrund der Web-Services Messergebnisse geholt und auf diese werden die Methoden
dann angewandt.
Seite 157
Web-Services zur Datenintegration mobiler Endgeräte
Typ
temp
Benutzername
tkoenig
Testfall 1: Aufruf der Methoden mit folgenden Parametern:
Endgerät
board
Quelle
temp1
Liste
Rückgabe der Methode getMeasurement
SUM: 11271.5
AVG: 23,765
Erwartetes Verhalten
MIN: 20,4
MAX: 24,9
SUM: 11271.5
AVG: 23,765
Tatsächliches Verhalten
MIN: 20,4
MAX: 24,9
Testfall 2: Aufruf der Methoden mit folgenden Parametern:
Endgerät
board
Zeitpunkt
2003-01-20 11:06:19
Zeitdifferenz
5 Minuten
Quelle
temp1
Liste
Rückgabe der Methode getEntityPit
SUM: 107,6
Erwartetes Verhalten
AVG: 21,52
MIN: 21,4
MAX: 21,7
SUM: 107,6
Tatsächliches Verhalten
AVG: 21,52
MIN: 21,4
MAX: 21,7
Seite 158
Web-Services zur Datenintegration mobiler Endgeräte
11.1.7 Middleware Komponente EarthCoord, Komponente GPSCheck, Komponente
GPSNMEA, Komponente CoordTransform
Das Konzept dieser Komponenten sieht wie folgt aus:
Ein GPS-String (in NMEA-Format GPGLL oder GPGGA) wird an die Komponente GPSNMEA
übergeben. Diese Komponente erzeugt bei Aufruf ein EarthCoord-Objekt, das die Positionsangaben in
Form von Erd-Koordinaten enthält.
Die Komponente CoordTransform bietet schließlich eine Methode an, die die Distanz zwischen zwei
Objekten des Typs EarthCoord bestimmen kann. Das Objekt EarthCoord ist somit nur nötig, um eine
Distanz zu ermitteln und wird ansonsten nicht verwendet.
Die Komponente GPSCheck dient der Überprüfung eines GPS-Strings, (die Komponenten GPSCheck
und GPSNMEA sind bis auf die Erzeugung eines Objekts EarthCoord identisch, überprüft werden
muss hier nur eine der beiden Komponenten, in diesem Fall GPSNMEA, da diese eine größere
Funktionalität bietet)
Komponente
Methode
Beschreibung
Test
prüft einen GPS-String, die
Validierung dieser Komponente
GPSNMEA
checkCoord
wurde bereits im Rahmen der
OK
Update Komponente (Angabe
falscher GPS Strings) überprüft
GPSNMEA
GPSNMEA
Diese beiden Methoden werden in
EarthCoord
setCoord
einem Schritt überprüft
CoordTransform getDistance
OK
OK
11.1.7.1 Methode GPSNMEA, Methode setCoord
Testfall 1: GPS String $GPGLL,4925.000000,L,0744.000000,E,180432.00,A,D*7A
Die GPSNMEA Komponente enthält die Längen- und Breitengradangaben:
Seite 159
Web-Services zur Datenintegration mobiler Endgeräte
lat_value = 4925.00000
Erwartetes Verhalten
lat_dir = N
long_value = 0744.000000
long_dir= E
lat_value = 4925.00000
Tatsächliches Verhalten
lat_dir = N
long_value = 0744.000000
long_dir= E
Die Komponente EarthCoord wird durch die Komponente GSNMEA erzeugt und enthält die Längenund Breitengradangaben nun in Form von Erd-Koordinaten:
lat_deg = 49
lat_min= 25
Erwartetes Verhalten
lat_dir=1
long_deg= 07
long_min= 44
long_dir=1
lat_deg = 49
lat_min= 25
Tatsächliches Verhalten
lat_dir=1
long_deg= 07
long_min= 44
long_dir=1
Testfall 1: GPS String $GPGGA,180432.00,4925.000000,N,0743.000000,E,1,05,1.0,210.00,M,31.81,M,4.2,0555*73
Die GPSNMEA Komponente enthält die Längen- und Breitengradangaben:
lat_value = 4925.00000
Erwartetes Verhalten
lat_dir = N
long_value = 0743.000000
long_dir= E
lat_value = 4925.00000
Tatsächliches Verhalten
lat_dir = N
long_value = 0744.000000
long_dir= E
Seite 160
Web-Services zur Datenintegration mobiler Endgeräte
Die Komponente EarthCoord wird durch die Komponente GSNMEA erzeugt und enthält die Längenund Breitengradangaben nun in Form von Erd-Koordinaten:
lat_deg = 49
lat_min= 25
lat_dir=-1
Erwartetes Verhalten
long_deg= 07
long_min= 44
long_dir=1
lat_deg = 49
lat_min= 25
lat_dir=-1
Tatsächliches Verhalten
long_deg= 07
long_min= 44
long_dir=1
11.1.7.2 Methode getDistance
Die Methode getDistance wird anhand verschiedener Eingaben überprüft. Zur Überprüfung wird eine
Web Seite herangezogen, die eine Distanzberechnung Online zur Verfügung stellt, es ist möglich hier
Koordinaten anzugeben und die Distanzen zwischen diesen berechnen zu lassen. Es werden
verschiedene Testfälle erstellt. Mittels der implementierten Methode wird die Distanz berechnet und
anschließend verglichen.
Es gilt zu bemerken, dass aufgrund möglicher unterschiedlicher Berechnungsverfahren und
Rundungsfehler die Ergebnisse leicht abweichen. Eine gewisse Toleranzschwelle wird hier
vorausgesetzt.
http://www.wcrl.ars.usda.gov/cec/java/lat-long.htm
Testfall 1: Frankfurt-Berlin – mittlere Distanz
Frankfurt:
$GPGLL,5007.000000,N,0841.000000,E,180432.00,A,D*7A
Berlin:
$GPGGA,180432.00,5232.000000,N,1325.000000,E,1,05,1.0,210.00,M,31.81,M,4.2,0555*73
Erwartetes Verhalten
Distanz = 424,281537
Distanz = 424,281539
Tatsächliches Verhalten
Abweichung von 0,000002 (0,0002m) innerhalb
des Akzeptanzbereichs
Testfall 2: Kaiserslautern (Punkt1) – Kaiserslautern(Punkt2) – kleine Distanz
Punkt1:
$GPGLL,4925.000000,L,0744.000000,E,180432.00,A,D*7A
Punkt2:
$GPGLL,4927.000000,L,0743.000000,E,180432.00,A,D*7A
Seite 161
Web-Services zur Datenintegration mobiler Endgeräte
Erwartetes Verhalten
Distanz = 3,89489827
Distanz = 3,89489828
Tatsächliches Verhalten
Abweichung von 0,0000001(0,0001m) innerhalb
des Akzeptanzbereichs
Testfall 3: London – Kaiserslautern- mittlere Distanz – verschiedene Richtungsangaben
London:
$GPGLL,5130.000000,N,0010.000000,W,180432.00,A,D*7A
Kaiserslautern: $GPGLL,4927.000000,L,0743.000000,E,180432.00,A,D*7A
Erwartetes Verhalten
Distanz = 601,8493996
Distanz = 580,xxx
Abweichung von ~20 km nicht innerhalb des
Akzeptanzbereichs
Tatsächliches Verhalten
Fehlerursache: Richtungsangabe für Punkt
London ist West – muss also Negativ in die
Berechnung eingehen – if Abfrage setzt falsches
Attribut
Erwartetes Verhalten
Distanz = 601,8493996
Distanz = 601,8494
Tatsächliches Verhalten
Abweichung von 0,0001 (0,1m) liegt im
Akzeptanzbereich
Testfall 4: Frankfurt-Berlin – sehr große Distanz– verschiedene Richtungsangaben
Brasilia:
$GPGLL,1547.000000,S,4755.000000,W,180432.00,A,D*7A
Hamburg:
$GPGGA,180432.00,5333.000000,N,1002.000000,E,1,05,1.0,210.00,M,31.81,M,4.2,0555*73
Erwartetes Verhalten
Distanz = 9461,5413
Distanz = 9461,5414
Tatsächliches Verhalten
Abweichung von 0,0001 (0,1m) innerhalb des
Akzeptanzbereichs
11.1.8 Mobiles Endgerät: Komponente chipmodul
Die Komponente chipmodul besteht aus mehreren Modulen, die wiederum aus mehreren Funktionen
bestehen. Die einzelnen Funktionen wurde während der Erstellung gestestet, es werden an dieser
Stelle nur die Ergebnisse zu den Tests der einzelnen Komponenten dargelegt.
Seite 162
Web-Services zur Datenintegration mobiler Endgeräte
Folgende Komponenten werden implementiert:
Anmeldung,
Abmeldung,
Initialisierung und
Messen.
11.1.8.1 Komponente Anmeldung
Anmeldung auf Basis der middle.ini
Erwartetes Verhalten
Tatsächliches Verhalten
an einer Middleware Plattform registrieren
Meldung zweite Middleware nicht vorhanden
Tritt ein
11.1.8.2 Komponente Abmeldung
Abmeldung auf Basis der middle.ini
Erwartetes Verhalten
Tatsächliches Verhalten
an einer Middleware Plattform abmelden
Meldung zweite Middleware nicht vorhanden
Tritt ein
11.1.8.3 Komponente Initialisierung
Anmeldung auf Basis der middle.ini
XML Daten erzeugen
Erwartetes Verhalten
insbesondere für measx.xml Dateien einen
Messwert erzeugen und vervielfältigen
Tatsächliches Verhalten
Tritt ein
11.1.8.4 Komponente Messen
Anmeldung auf Basis der middle.ini
XML Daten erzeugen
Erwartetes Verhalten
in regelmäßigen Abständen aktualisieren (GGT)
freier Speicher bleibt konstant über Zeit
(~12Stunden)
Tatsächliches Verhalten
erfolgt
Seite 163
Web-Services zur Datenintegration mobiler Endgeräte
11.1.9 Daten-Server : Komponente CGI-Modul
Update Vorgang auf Basis der middle.ini
Erwartetes Verhalten
Tatsächliches Verhalten
Update an Middleware anstoßen
zweite Middleware Plattform nicht vorhanden
Tritt ein
Seite 164
Literaturverzeichnis
[Bad02]
Glenn Baddeley , GPS NMEA sentence Information
http://home.mira.net/~gnb/gps/nmea.html
[BaEb01]
Baier, Ebert et. al.
XML Schema Teil 0: Einführung - Deutsche Übersetzung
XML Schema Teil 1: Strukturen - Deutsche Übersetzung
XML Schema Teil 2: Datentypen - Deutsche Übersetzung
http://www.edition-w3c.de/TR/2001/REC-xmlschema-0-20010502/
http://www.edition-w3c.de/TR/2001/REC-xmlschema-1-20010502/
http://www.edition-w3c.de/TR/2001/REC-xmlschema-2-20010502/
Originaldokumente des W3C
http://www.w3.org/TR/xmlschema-0/
http://www.w3.org/TR/xmlschema-1/
http://www.w3.org/TR/xmlschema-2/
[BeApi02]
Beck IPC GmbH , IPC@Chip Documentation – Chip RTOS, November 2002
http://www.bcl.de
[BeCb02]
Beck IPC SC12, Code Beispiele, 2002
http://www.bcl.de
[BeDb02]
Beck IPC GmbH, Datenblatt SC12, Februar 2002
http://www.bcl.de
[BeDg02]
J. Gatrost , Debug@Chip Users Guide, November 2001, Beck IPC GmbH
http://www.bcl.de
[BeHw02]
Beck IPC GmbH , Hardware Manual [SC12], Februar 2002
http://www.bcl.de
[Bib02]
Bibrand, Formel zur Berechnung der Distanz, 2002
http://www.bibrand.de/GPS/formeln.htm
[BrPaSp98]
W3C, Extensible Markup Language (XML) 1.0, W3C Recommendation
Februar 1998;
http://www.w3.org/TR/1998/REC-xml-19980210.html
[Cha02]
David Chappell, .NET verstehen Einführung und Analyse, 2002
Addison-Wesley
[ChCu01]
Erik Christensen, Francisco Curbera et al., Web-Service Description Language 1.1, 2001
http://www.w3.org/TR/wsdl
[ChJe02]
David Chappell, Tyler Jewell, Java Web-Services, March 2002, O'Reilly
[Ebx02]
ebxml.org
www.ebxml.org
[Fla00]
David Flanagan , Java Examples in a nutshell, Oktober 2000, O'Reilly
[Geo02]
GeoScience Australia, Calculating distances between two points (Great Circle
Distance), Oktober 2002
http://www.auslig.gov.au/geodesy/datums/distance.htm#circle
[GuHe02]
Gudgin, Hedley et. al., SOAP Messaging Framework, Juni 2002
http://www.w3.org/TR/2002/WD-soap12-part1-20020626/
[Koe00]
Tom Koenig, Internet-basiertes Knowledge Management (XML,RDF), 2000
http://wwwagr.informatik.uni-kl.de/~bergmann/KMSem2k/pdf
[Kru02]
Andre Kruetzfeldt, Sun ONE vs .NET, 2002, Sun Microsystems
[Küh01]
Claus Kühnel, Embedded Web-Server mit Single Chip Controller, 2001,
Skript-Verlag Kühnel
[Nwg97]
Network Working Group, Hypertext Transfer Protocol HTTP/1.1, Januar 1997
http://www.ietf.org/rfc/rfc2068.txt
[OrMa02]
Kathy Walsh, Sang Shin, Discover and publish Web-Services with JAXR,
June 2002, JavaWorld
http://www.javaworld.com/javaworld/jw-06-2002/jw-0614-jaxr_p.html
[OaWo00]
Scott Oaks, Henry Wong, Jini in a nutshell, März 2000, Oreilly
[Mic02]
Microsoft, Microsoft Developer Network
http://msdn.microsoft.com/
[Qua02]
Qusay H. Mahmoud , Registration and Discovery of Web-Services, June 2002
http://developer.java.sun.com/developer/technicalArticles/WebServices/jaxrws/
[SchGat01]
Ing. E. Schlösser, J. Gatrost, Getting Started (SC12), Oktober 2001, Beck IPC
GmbH
http://www.bcl.de
[Schu01]
Stefan Schumacher, Namensräume in XML - Deutsche Übersetzung,
Juni 2001
http://www.schumacher-netz.de/TR/1999/REC-xml-names-19990114-de.html
Originaldokument des W3C
http://www.w3.org/TR/REC-xml-names/
[ScSt00]
Kennard Scribner, Mark C. Stiver, SOAP devleoper's guide - professionelle
XML-Anwendung, Dezember 2000, Markt und Technik
[ShMo02]
Humphrey Sheil, Michael Monteiro Rumble in the jungle: J2EE versus .NET
Part 1 and Part 2, 2002, Javaworld
http://www.javaworld.com/javaworld/jw-06-2002/jw-0628-j2eevsnet.html
[SunAg02]
Sun, Sun ONE Architecture Guide, 2002
http://wwws.sun.com/software/sunone/docs/arch/S1-arch-guide.pdf.zip
[SunDg02]
Sun Developer's Guide to Building XML-based Web-Services with J2EE[tm],
2002
http://www.theserverside.com/resources/pdf/J2EE-Web-ServicesDevGuide.pdf
[SunDp02]
Sun, Java Web-Services Developer Pack, 2002
http://java.sun.com/Web-Services/downloads/Web-Servicespack.html
[SunDw02]
Developing Web-Services with the Sun[tm] Open Net Environment, 2002
http://wwws.sun.com/software/sunone/wp-spine/spine.pdf
[SunJa01]
Sun, Jini Architecture Specification
http://wwws.sun.com/software/jini/specs/jini1.2html/jini-spec.html
[SunJa02]
Sun, Java API, 2002
http://java.sun.com/j2se/1.4/docs/api/
[SunJt02]
Sun, Java Tutorial, 2002
http://java.sun.com/docs/books/tutorial/
[SunWs02]
Sun, Web-Services Made Easier, June 2002 Technical White Paper
http://java.sun.com/Web-Services/downloads/Web-Servicestutorial.html
[SunWt02]
Sun, Java Web-Services Tutorial, 2002
http://java.sun.com/Web-Services/docs/1.0/tutorial/index.html
[Tra00]
Marcus Trapp, XML Techniken und Anwendung, 2000
http://wwwdbis.informatik.uni-kl.de/staff/Ritter/seminarws9900.html
[Ubl00]
GPS u-blox Protocol Specification, April 2000, u-blox
http://www.u-blox.de/customersupport/docs_g1.html
[Wes02]
Ralf Westphal, .NET kompakt, 2002, Spektrum akademischer Verlag
[Xim02]
Mono, Ximian 2002
http://www.go-mono.com/
http://www.javaworld.com/javaworld/jw-07-2002/jw-0726-j2eevsnet2.html
[ZiLeDa00]
A. Zingg, B. Lenzlinger, Mini Web-Server supporting SSL (Diplomarbeit)
[ZiLePa00]
A. Zingg, B. Lenzlinger, Mini Web-Server mit SSL (Projektarbeit)
Abbildungsverzeichnis
Abbildung 1: allgemeine Struktur eines WSDL-Dokuments ................................................................ 22
Abbildung 2: Struktur eines UDDI Dokuments .................................................................................... 27
Abbildung 3: SOAP Nachricht .............................................................................................................. 30
Abbildung 4: ADO.NET-Datenprovider ............................................................................................... 39
Abbildung 5: Zugriff auf einen Web-Service........................................................................................ 41
Abbildung 6: Sun ONE-Plattformarchitektur........................................................................................ 44
Abbildung 7: Daten des mobilen Endgerätes ........................................................................................ 57
Abbildung 8: Kommunikation Mobiles Endgerät – Middleware .......................................................... 58
Abbildung 9: Kommunikation Daten-Server - Middleware.................................................................. 62
Abbildung 10: Realisierung des "positionsspezifischen Anbietens" durch die Middleware ................ 67
Abbildung 11: Realisierung des "positionsspezifischen Anbietens" durch den Client ......................... 68
Abbildung 12: Ablauf des Messprogramms .......................................................................................... 76
Abbildung 13: Interaktion mobiles Endgerät - Middleware zur Kontrolle der Sicherheit .................... 83
Abbildung 14: Ablauf der Komponente Anmeldung ............................................................................ 87
Abbildung 15: Ablauf der Komponente Abmeldung ............................................................................ 88
Abbildung 16: Ablauf der Komponente Registrierung ......................................................................... 89
Abbildung 17: Ablauf der Funktion "UpdateData" ............................................................................... 91
Abbildung 18: Rückgabe der Web-Service Methoden........................................................................ 100
Abbildung 19: interner Ablauf eines Web-Services............................................................................ 102
Abbildung 20: Entity Relationship Modell ......................................................................................... 103
Abbildung 21: Gesamtsystem im Überblick ....................................................................................... 107
Abbildung 22: Versuchsanordung ....................................................................................................... 117
Tabellenverzeichnis
Tabelle 1: mögliche Nachrichtenkommunikation innerhalb des <PortType> Elements ....................... 25
Tabelle 2: Bewertung allgemeiner Aspekte der .NET und ONE-Plattformen ...................................... 53
Tabelle 3: Bewertung von Implementierungsaspekten der .NET und ONE-Plattformen ..................... 53
Tabelle 4: Informationen über das mobile Endgerät ............................................................................. 56
Tabelle 5: Informationen über einen Sensor.......................................................................................... 57
Tabelle 6: Informationen, die bei einer Anmeldung eines mobilen Endgeräts übertragen werden ....... 58
Tabelle 7: Informationen über Middleware-Server ............................................................................... 59
Tabelle 8: Abmelde-Informationen ....................................................................................................... 60
Tabelle 9: Informationen über einen Daten-Server ............................................................................... 61
Tabelle 10: Informationen über die Datenquellen ................................................................................. 61
Tabelle 11: Anforderungen an ein Datenbankschema bezüglich des mobilen Endgeräts ..................... 63
Tabelle 12: Anforderungen an ein Datenbankschema bezüglich der Sensoren..................................... 64
Tabelle 13: Anforderungen an ein Datenbankschema bezüglich der Messergebnisse .......................... 64
Tabelle 14: entity.ini .............................................................................................................................. 74
Tabelle 15: Informationen zu einem Sensor in der sourcex.ini Datei ................................................... 74
Tabelle 16: Informationen zu den Messwerten bezüglich eines Sensors in der sourcex.ini Datei ........ 74
Tabelle 17: Informationen zu dem nächsten zu ändernden Eintrag....................................................... 75
Tabelle 18: benötigte Informationen bezüglich eines Messwerts.......................................................... 78
Tabelle 19: Informationen der middle.ini Konfigurationsdatei ............................................................. 82
Tabelle 20: Statusinformationen des Web-Services .............................................................................. 99
Tabelle 21: Statuscodes eines Web-Services......................................................................................... 99
Tabelle 22: Web-Service-Rückgabe .................................................................................................... 100
Tabelle 23: Struktur des Statuselements .............................................................................................. 101
Tabelle 24: Struktur des Messergebnisseintrags.................................................................................. 101
Tabelle 25: Polling-Mechanismus ....................................................................................................... 104
Tabelle 26: statistische Funktionen ..................................................................................................... 104
Tabelle 27: Modi der Platine ............................................................................................................... 118
Tabelle 28: Hexadezimal-Codes im Modus Applikation .................................................................... 120
Tabelle 29: Middleware Konfigurationsdatei ...................................................................................... 124
Tabelle 30: Statuscodes der Middleware ............................................................................................. 130
Tabelle 31: Zuordnung Statuscode - zu treffende Maßnahme............................................................. 132
Beispielverzeichnis
Beispiel 1: XML-Dokument .................................................................................................................. 15
Beispiel 2: Dokumenttyp-Definition ..................................................................................................... 16
Beispiel 3: Deklaration eines XML Namespace .................................................................................... 17
Beispiel 4: Konflikt durch Mehrdeutigkeit ............................................................................................ 17
Beispiel 5: Auflösung eines Konflikts durch Deklaration geeigneter Namensräume ........................... 17
Beispiel 6: XML Schema ...................................................................................................................... 19
Beispiel 7: XML-Dokument abgeleitet von einem XML Schema ........................................................ 20
Beispiel 8: definitions-Element ............................................................................................................. 23
Beispiel 9: types-Element ...................................................................................................................... 24
Beispiel 10: Beispiel-Einträge für message-Elemente .......................................................................... 24
Beispiel 11: PortType-Element ............................................................................................................. 24
Beispiel 12: binding-Element ................................................................................................................ 25
Beispiel 13: service-Element ................................................................................................................. 26
Beispiel 14: SOAP HTTP-Anfrage ....................................................................................................... 31
Beispiel 15: SOAP HTTP-Rückmeldung .............................................................................................. 31
Beispiel 16: Instanz des XML-Schemas entity...................................................................................... 79
Beispiel 17: Instanz des XML-Schemas source .................................................................................... 80
Beispiel 18: Instanz des des XML-Schemas measurement ................................................................... 81
