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