Verifikation der Auswahl von Open Source Produkten für OpenGIS Webservices

Transkript

1 Verifikation der Auswahl von Open Source Produkten für OpenGIS Webservices von Lydia Gietler Diplomarbeit zur Erlangung des akademischen Grads Diplom-Ingenieur (FH) an der Fachhochschule Technikum Kärnten im Studiengang Geoinformation Betreuer: Dr. Adrijana Car Fachhochschule Technikum Kärnten Prof. Dr. Wolfgang Reinhardt Universität der Bundeswehr München Neubiberg, im August 2004

2 EIDESSTATTLICHE ERKLÄRUNG Ich erkläre hiermit, dass ich die vorliegende Diplomarbeit selbständig verfasst und alle benutzten Quellen und Hilfsmittel angegeben habe. Wörtliche und sinngemäße Zitate sind als solche gekennzeichnet. Neubiberg, 9. August 2004 (Ort, Datum) Lydia Gietler (Unterschrift)

3 DANKSAGUNG Ich bedanke mich bei meiner Studiengangsleiterin, Frau Dr. Adrijana Car, für die hervorragende Betreuung dieser Diplomarbeit. Spezieller Dank geht an Herrn Prof. Dr.- Ing. Wolfgang Reinhardt für die Möglichkeit, diese Arbeit an der Arbeitsgemeinschaft GIS (AGIS) an der Universität der Bundeswehr durchzuführen, und für seine ebenfalls außerordentliche Betreuung. Herrn Dr.-Ing. Oliver Plan, dem Projektleiter des Projekts Weiterentwicklung von Geodiensten, danke ich für die konstruktiven Diskussionen rund um diese Arbeit. Ich bedanke mich bei allen Mitgliedern des Projektteams, namentlich M. Sc. Fei Wang, M.Sc. Admire Kandawasvika, Dipl.-Geol. Simone Stürmer, Dipl.-Ing. Stephan Mäs und Mag. rer. nat. Roland Helmich, sowie bei allen weiteren Mitarbeitern der AGIS, die ich hier nicht namentlich erwähne, für die positive Zusammenarbeit. Weiterer Dank geht an Herrn Dr.-Ing. Gerhard Joos für die kreativen Gespräche.

4 ABSTRACT This diploma thesis describes the methods and results of a project accomplished by the authoress at the GIS Lab (AGIS) at the University of the Bundeswehr Munich. The translated name of the project is OpenGIS Concepts for Geoservices. It deals with investigations on existing OGC web service specifications and their open source implementations with regard to the special requirements of a mobile multidimensional data acquisition system based on the Internet. OpenGIS Concepts for Geoservices is part of the project Advancement of Geoservices carried out by the AGIS in cooperation with several research institutes during the period of the thesis and beyond. The project Advancement of Geoservices is sponsored by the German Federal Ministry of Education and Research. It aims to develop an overall concept for mobile online-acquisition, maintenance, usage and visualization of multidimensional geodata. The development of a prototype shows the technical feasibility of this system. First step in the subproject OpenGIS Concepts for Geoservices is the identification of the requirements of the service. The next step is to find out which OGC web service specifications meet these requirements. A market analysis is accomplished to give an overview on available open source implementations of those OGC web services. As an open source product which fulfills the identified requirements the product deegree is chosen. A series of functional testing verifies this selection. Besides functionality the performance of a web service is an important factor to its success. To examine the performance of the chosen open source product benchmarks for OGC conformant web mapping and web feature services are developed. Up to now no such benchmarks existed. The results of the benchmarks carried out at the chosen product help to estimate the capacity of the hardware for productive use. i

5 INHALTSVERZEICHNIS 1. EINLEITUNG PROJEKTHINTERGRUND HYPOTHESE VORHABEN ERWARTETE ERGEBNISSE LESEPUBLIKUM INHALT UND ORGANISATION DER DIPLOMARBEIT GRUNDLAGEN DIE EXTENSIBLE MARKUP LANGUAGE WEBSERVER UND MAPSERVER RELEVANTE OGC SPEZIFIKATIONEN Das Web Map Service Interface Das Web Feature Service Interface LEISTUNGSBEWERTUNG VON WEBSERVICES Theorie der Leistungsbewertung von Computersystemen Leistungsbewertung von Geo-Webservices OPENGIS KONZEPTE FÜR GEODIENSTE PROBLEMSTELLUNG VORGEHENSWEISE DIE TESTDATEN BENCHMARKING MIT APACHE JMETER ERGEBNISSE ANFORDERUNGEN AN DEN SERVER OWS SPEZIFIKATIONEN OPEN SOURCE IMPLEMENTIERUNGEN DES WMS UND DES WFS INTERFACES Marktanalyse Die Auswahl Funktionstests BENCHMARKS Modell der Benchmarks WMS Benchmarks WFS Benchmarks ERGEBNISSE DER BENCHMARKS Ergebnisse der WMS Benchmarks Ergebnisse der WFS Benchmarks ANALYSE DER ERGEBNISSE ANALYSE DER ANFORDERUNGEN AN DEN SERVER VERIFIKATION DER AUSWAHL ANALYSE DER BENCHMARKS ANALYSE DER ERGEBNISSE DER BENCHMARKS ZUSAMMENFASSUNG, DISKUSSION, AUSBLICK ZUSAMMENFASSUNG DISKUSSION AUSBLICK...61 LITERATUR...64 INTERNETRESSOURCEN...66 ANHANG ANHANG ANHANG ii

6 ABBILDUNGSVERZEICHNIS Abbildung 1: Eingliederung der einzelnen Teilprojekte in das Verbundprojekt Weiterentwicklung von Geodiensten...3 Abbildung 2: Client-Server-Architektur in Netzwerken...9 Abbildung 3: Zeitliche Abläufe bei der Bereitstellung von Karten im Internet...11 Abbildung 4: Vier gleichwertige Aspekte der Leistungsbewertung von Computersystemen...21 Abbildung 5: Architektur kommerzieller Web Map Server...23 Abbildung 6: Verteilte Systeme...34 Abbildung 7: Modell der entwickelten Benchmarks...35 Abbildung 8: Netzwerkarchitektur für die Benchmarks...36 Abbildung 9: Ergebnisse der WMS Benchmarks - Karten pro Stunde in Abhängigkeit der Anzahl der gleichzeitigen Zugriffe Abbildung 10: Ergebnisse der WMS Benchmarks - Mittlere Antwortzeiten in Sekunden in Abhängigkeit der gleichzeitigen Zugriffe...54 Abbildung 11: Ergebnisse der WFS Benchmarks - Featurecollections pro Stunde in Abhängigkeit der Anzahl der gleichzeitigen Zugriffe...55 Abbildung 12: Ergebnisse der WFS Benchmarks - Mittlere Antwortzeiten in Sekunden in Abhängigkeit der gleichzeitigen Zugriffe...56 iii

7 TABELLENVERZEICHNIS Tabelle 1: OGC Webservices für den standardisierten Zugriff auf Geodaten im Internet...12 Tabelle 2: Die Requests des Web Map Service Interfaces...14 Tabelle 3: Die Parameter des GetMap Requests...16 Tabelle 4: Die Requests des Web Feature Service Interfaces...17 Tabelle 5: Die Parameter des GetFeature Requests...19 Tabelle 6: Die Testdaten...26 Tabelle 7: Die neun Datenbasen für die Benchmarks...27 Tabelle 8: Open Source Implementierungen des WMS und des WFS Interfaces...32 Tabelle 9: Parameter der in den WMS Benchmarks angewandten GetMap Requests 37 Tabelle 10: Die WMS Benchmarks...38 Tabelle 11: Ergebnisse der WMS Benchmarks bei einem Zugriff...42 Tabelle 12: Ergebnisse der WMS Benchmarks bei zwei gleichzeitigen Zugriffen...42 Tabelle 13: Ergebnisse der WMS Benchmarks bei vier gleichzeitigen Zugriffen...43 Tabelle 14: Ergebnisse der WMS Benchmarks bei acht gleichzeitigen Zugriffen...44 Tabelle 15: Ergebnisse der WMS Benchmarks bei 16 gleichzeitigen Zugriffen...44 Tabelle 16: Ergebnisse der WMS Benchmarks bei 32 gleichzeitigen Zugriffen...45 Tabelle 17: Ergebnisse der WMS Benchmarks bei 64 gleichzeitigen Zugriffen...45 Tabelle 18: Ergebnisse der WFS Benchmarks bei einem Zugriff...46 Tabelle 19: Ergebnisse der WFS Benchmarks bei zwei gleichzeitigen Zugriffen...47 Tabelle 20: Ergebnisse der WFS Benchmarks bei vier gleichzeitigen Zugriffen...47 Tabelle 21: Ergebnisse der WFS Benchmarks bei acht gleichzeitigen Zugriffen...48 Tabelle 22: Ergebnisse der WFS Benchmarks bei 16 gleichzeitigen Zugriffen...49 iv

8 1. EINLEITUNG Die Nutzung des Internets als Plattform für die Verbreitung von Geodaten hat in den letzten Jahren rasant zugenommen. Einer Schätzung zufolge wurden im Jahr 2001 ca. 200 Millionen Karten pro Tag im Internet dargestellt [Peterson, 2001]. Neben derartigen Diensten für die Veröffentlichung der visuellen Repräsentation von Geodaten, haben sich auch Services für die Verbreitung der Geodaten selbst etabliert [Riecken, 2004], [Internetressourcen /17/]. Als problematisch hat sich dabei die Vielzahl nicht interoperabler Geo- Webservices erwiesen. Aufgrund unterschiedlicher Schnittstellendefinitionen, die im Allgemeinen nicht offen gelegt sind, können Services verschiedenerer Hersteller nicht miteinander kommunizieren. In vielen Fällen sind die Nutzer solcher Dienste auch hinsichtlich des Datenformats an einen Hersteller gebunden. Dies führt dazu, dass Geodaten oftmals mit nur einer Geoinformationssoftware nutzbar sind. Sollen sie auch für Software anderer Hersteller genutzt werden, ist meist großer Aufwand für die Konvertierung von Daten und Anwendungsschemata notwendig. Derartigen Entwicklungen wirkt das Open GIS Consortium (OGC) entgegen. Durch die Standardisierung von Schnittstellen soll Interoperabilität zwischen Software und Daten verschiedener Hersteller über Geo-Webservices ermöglicht werden. Um dies zu erreichen, erarbeitet und veröffentlicht das OGC eine Reihe von frei zugänglichen Spezifikationen, die von Softwareherstellern implementiert werden können [Internetressourcen /9/]. Häufig wird kommerzielle Software zum Aufbau von Services für die Verbreitung von Geodaten im Internet benutzt. Die Anschaffungskosten derartiger Server können Höhen erreichen, die von klein- und mittelständischen Betrieben, Start-Up- Unternehmen und Non-Profit Organisationen in einem nicht akzeptablem Kosten/Nutzenverhältnis stehen. Bedingt durch die schlechte wirtschaftliche Lage, die seit Jahren anhält, sind auch öffentliche Verwaltungen zu Sparmaßnahmen gezwungen, 1

9 weshalb der Aufbau eines Dienstes zur Verbreitung von Geodaten im Internet auch in diesem Bereich oft verzögert wird. Dem gegenüber stehen Open Source Produkte, für die keine Lizenzgebühren zu bezahlen sind. Es gibt Open Source Produkte für GIS-Anwendungen, die die vom OGC vorgeschlagenen Spezifikationen für Geo-Webservices implementieren. Dienste, die mit diesen Produkten aufgebaut werden, liefern Daten in Ausgabeformaten, die ebenfalls den vom OGC vorgeschlagenen Standards entsprechen. Dadurch wird eine interoperable Aneinanderkopplung verschiedener Server und Clients unabhängig von den Herstellern ermöglicht. Die vorliegende Arbeit befasst sich mit der Einsetzbarkeit solcher Open Source Produkte am Beispiel des Projekts Weiterentwicklung von Geodiensten, das im folgenden Abschnitt näher erläutert wird. 1.1 PROJEKTHINTERGRUND Das Ziel des Projekts Weiterentwicklung von Geodiensten ist die Entwicklung eines Gesamtkonzepts zur mobilen Online-Erfassung, Verwaltung, Nutzung und Visualisierung von mehrdimensionalen Geodaten. Die Entwicklung eines prototypischen Systems zeigt die technische Durchführbarkeit des Konzepts. Die Arbeitsgemeinschaft GIS (AGIS) an der Universität der Bundeswehr ist einer von vier Projektpartnern dieses vom deutschen Bundesministerium für Bildung und Forschung geförderten Forschungsvorhabens. Die Aufgabe der AGIS in Zusammenarbeit mit der European Media Laboratory GmbH in Heidelberg besteht im genannten Verbundprojekt aus der Entwicklung eines mobilen Erfassungssystems für mehrdimensionale Geodaten. Die mobile Komponente dieses Erfassungssystems stellt den Client in einer netzbasierten Client-Server- Architektur dar. Der Server ist das Zwischenstück zwischen dem mobilen Client und einer Geodatenbank für mehrdimensionale Geodaten, wie beispielsweise georeferenzierte 3D Objekte. Die Geodatenbank als Verwaltungseinheit wird im Rahmen des 2

10 Projekts vom Forschungszentrum für Geoinformatik und Fernerkundung an der Hochschule Vechta entwickelt. Das Teilprojekt OpenGIS Konzepte für Geodienste befasst sich mit der Konzeption und der Implementierung der Server-Komponente dieses Systems. Dieses Teilprojekt wurde von der Autorin an der AGIS durchgeführt und wird in der vorliegenden Arbeit beschrieben. Abbildung 1 illustriert die Integration der einzelnen Teilprojekte in das Verbundprojekt Weiterentwicklung von Geodiensten. Abbildung 1: Eingliederung der einzelnen Teilprojekte in das Verbundprojekt Weiterentwicklung von Geodiensten Allgemeine Informationen zum Projekt Weiterentwicklung von Geodiensten finden sich unter [Internetressourcen /11/ und /12/] und bei [Breunig et al, 2003a]. Eine Beschreibung des von der AGIS durchgeführte Teilprojekts ist unter [Internetressourcen /13/] zu finden. Detaillierte Beschreibungen des Projektes Weiterentwicklung von Geodiensten, von der Idee bis zur Vorgehensweise bei der Entwicklung sind in [Breunig et al, 2003b] und [Breunig et al, 2003c] zusammengefasst. Keine der erwähnten Quellen beschäftigt sich detailliert mit den einzusetzenden Servern. Vor dem Hintergrund der Projektanforderungen ergab sich die folgende Hypothese. 3

11 1.2 HYPOTHESE Es existieren Open Source Implementierungen von OGC Web Services (OWS), die den Anforderungen an den Server für das Projekt Weiterentwicklung von Geodiensten für zweidimensionale Geodaten genügen. 1.3 VORHABEN Die erste Aufgabe im Teilprojekt OpenGIS Konzepte für Geodienste ist, im Sinne einer Anforderungsanalyse, die Identifikation der notwendigen Funktionalitäten des Services. Im Anschluss daran wird untersucht, ob und wie weit diese Funktionalitäten von OGC Spezifikationen abgedeckt werden können. Es wird ein Marktüberblick über die Open Source Implementierungen der entsprechenden Spezifikationen geschaffen. Entsprechend den Kriterien der Aufgabenstellung wird ein Open Source Produkt ausgewählt. Die Durchführung von Funktionstests entsprechend der identifizierten Anforderungen verifiziert die getroffene Auswahl. Performancetests ermöglichen die Abschätzung der erforderlichen Hardwarekapazität für den produktiven Einsatz des gewählten Produktes. Es werden keine Untersuchungen hinsichtlich der notwendigen Fachkompetenz sowie des Zeit- und Kostenaufwandes beim Einsatz von Open Source Produkten für derartige Dienste durchgeführt. Entsprechende Abschätzungen für eine Open Source Implementierung des Web Map Service Interfaces findet sich in [Gietler et al, 2003]. 1.4 ERWARTETE ERGEBNISSE Ausgehend von den Spezifikationen kann man erwarten, dass Open Source Produkte genauso wie kommerzielle Produkte die Anforderungen des Projektes erfüllen. Dies muss aber durch praktische Tests unter den vorgegebenen Projektbedingungen verifiziert werden. Aus diesem Grund stehen als weiteres Ergebnis dieser Arbeit funktionsfähige Open Source Implementierungen des Web Map und Web Feature Service Interfaces zur Verfügung, die die Darstellung von interaktiven Karten im Internet und den 4

12 Zugriff auf Vektordaten über das Internet erlauben. Diese Server werden im Rahmen des Projekts Weiterentwicklung von Geodiensten zur Entwicklung eines mobilen Clients, sowie für spätere Tests des Gesamtsystems genutzt. Es wird eine Einschätzung der Eignung verfügbarer OWS Spezifikationen für das Projekt Weiterentwicklung von Geodiensten durchgeführt. Des Weiteren werden Javabasierte Open Source Implementierungen der identifizierten Services zu Testzwecken bei der Client-Entwicklung und für die späteren Tests des Gesamtsystems bereitgestellt. Funktionstests bestätigen die getroffen Auswahl. Um die notwendige Hardwarekapazität des Servers für den produktiven Betrieb abschätzen zu können, werden Performancetests entwickelt und an den genannten Diensten durchgeführt. Diese Tests sowie die bei der Durchführung der Tests benutzten Daten werden nach Abschluss der Diplomarbeit im Internet zur Verfügung gestellt [Internetressourcen /5/]. Somit erfüllen die Tests die Anforderungen von Benchmarks nach [Bode und Hellwagner, 1999]. Bisher gibt es keine Benchmarks für OGC konforme Webservices, damit sind die im Rahmen dieser Arbeit entwickelten Tests einzigartig. Die Performancetests sind nicht an spezielle Produkte gebunden und können zum Test von beliebigen OGC konformen Web Mapping bzw. Web Feature Services verwendet werden. 1.5 LESEPUBLIKUM Primär richtet sich diese Diplomarbeit an die Projektpartner im Projekt Weiterentwicklung von Geodiensten. Sie dient als Dokumentation der von der Autorin im Rahmen dieses Projektes durchgeführten Arbeiten. Durch den Einsatz von Open Source Produkten ist diese Arbeit auch für andere Geodatenanbieter interessant. Beispielsweise können Institutionen, die bisher durch hohe Lizenzkosten und wegen befürchteter Abhängigkeiten von Herstellern vom Einsatz von Geo-Webservices abgeschreckt waren, durch diese Arbeit zum Aufbau eines vergleichbaren Dienstes ermuntert werden. 5

13 Auch für Organisationen, in denen die Entscheidung für den Einsatz von OGC konformen Diensten bereits getroffen ist, enthält diese Arbeit relevante Informationen. Die Ergebnisse der durchgeführten Performancetests können, sofern dieselben Produkte eingesetzt werden, bei der Dimensionierung der Hardware für derartige Dienste herangezogen werden. Auch wenn die Wahl auf Produkte anderer, auch kommerzieller Hersteller gefallen ist, können die hier entwickelten Benchmarks aufgrund der standardisierten Schnittstellen auch für diese Services durchgeführt werden. Dadurch wir ein Vergleich von Diensten unterschiedlicher Hersteller ermöglicht. 1.6 INHALT UND ORGANISATION DER DIPLOMARBEIT In Kapitel 2 werden die technischen und wissenschaftlichen Grundlagen, auf denen diese Diplomarbeit basiert, beschrieben. Dazu zählen die Extensible Markup Language (Kapitel 2.1), Grundlagen zum Verständnis von Webservern und Mapservern (Kapitel 2.2), die für diese Arbeit relevanten OGC Spezifikationen (Kapitel 2.3), sowie Theorie und Praxis der Leistungsbewertung von Computersystemen im Allgemeinen und von Geo-Webservices im Speziellen (Kapitel 2.4). Kapitel 3 beschreibt das von der Autorin im Rahmen dieser Arbeit durchgeführte Projekt OpenGIS Konzepte für Geodienste. Es beginnt mit einer detaillierten Erklärung des zu bearbeitenden Problems (Kapitel 3.1), gefolgt von der Beschreibung der Vorgehensweise zur Lösung dieses Problems (Kapitel 3.2). Anschließend werden die Testdaten (Kapitel 3.3) sowie die für die Performancetests benutzte Software (Kapitel 3.4) beschrieben. In Kapitel 4 werden die in diesem Projekt erzielten Ergebnisse faktisch beschrieben. Dies beginnt mit den Ergebnissen der durchgeführten Anforderungsanalyse (Kapitel 4.1) mit anschließender Identifizierung der diese Anforderung erfüllenden OGC Webservices (Kapitel 4.2). In Kapitel 4.3 wird ein Überblick über Open Source Implementierungen dieser Webservices gegeben und es werden die Auswahl eines dieser Produkte sowie die Ergebnisse der Funktionstests an diesem Produkt beschrieben. Die 6

14 entwickelten Benchmarks sind in Kapitel 4.4, und deren Ergebnisse in Kapitel 4.5 beschrieben. In Kapitel 5 werden die in Kapitel 4 beschriebenen Ergebnisse analysiert. Es gliedert sich in Kapitel 5.1, eine Analyse der Anforderungen an den Server sowie der diese Anforderungen erfüllenden OWS Spezifikationen, gefolgt von der Verifikation der Auswahl eines Open Source Produktes, das diese Spezifikationen implementiert (Kapitel 0). In Kapitel 5.3 werden die entwickelten Benchmarks kritisch betrachtet. Die Ergebnisse dieser Benchmarks, durchgeführt am ausgewählten Open Source Produkt, werden in Kapitel 5.4 analysiert. Kapitel 6 beinhaltet eine Zusammenfassung der Arbeit (Kapitel 6.1) gefolgt von einigen kritischen Anmerkungen (Kapitel 6.2). Im Ausblick (Kapitel 6.3) wird beschrieben wie die Benchmarks auf andere WMS und WFS Produkte übertragen werden können. Außerdem wird diskutiert wie die Ergebnisse innerhalb des Projektes und für ähnlich geartete Projekte zur Abschätzung der Kapazität der Hardware genutzt werden können. Es werden Lösungsvorschläge zur Erweiterung der Indexstruktur von objektbasierten Geodaten gegeben. 7

15 2. GRUNDLAGEN Kapitel 2 enthält jene wissenschaftlichen und technischen Grundlagen, auf denen diese Diplomarbeit basiert. Die Extensible Markup Language ist notwendig für das Verständnis von OGC Spezifikationen und wird in Kapitel 2.1 erläutert. Kapitel 2.2 beschäftigt sich mit der Theorie von Webservices und Mapservices, ebenfalls Voraussetzung für das Verständnis der OGC Spezifikationen. Im Kapitel 2.3 wird näher auf die relevanten OGC Spezifikationen eingegangen. Kapitel 2.4 betrachtet zunächst die theoretischen Aspekte der Leistungsbewertung von Computersystemen und gibt anschließend einen Überblick über verschiedene Veröffentlichungen zu Performancetests bei Geo-Webservices. 2.1 DIE EXTENSIBLE MARKUP LANGUAGE Die Extensible Markup Language (XML) ist eine standardisierte Markup Sprache [Teege, 2003]. Ein XML-Markup, auch XML-Element genannt, versieht beliebige Inhalte mit Zusatzinformationen, die eine formale Strukturierung dieser Inhalte ermöglichen. Die formale Struktur erlaubt die maschinelle Interpretation der Inhalte, indem das XML-Element die Semantik des enthaltenen Textes festlegt. XML-Elemente können auch in einander geschachtelt werden. Um die Semantik des Inhaltes eines Elementes festzulegen, werden diese in einem so genannten XML-Schema definiert. Darin wird der Name des Elementes, dessen Datentyp und Bedeutung eindeutig festgelegt. XML-Elemente können auch Attributangaben enthalten, deren Namen, Datentypen und Bedeutung ebenfalls im XML- Schema definiert werden. XML wurde für generisches Markup entwickelt. Das bedeutet, dass mit Hilfe von XML spezialisierte, XML-basierten Markup Sprachen definiert werden können. Die Syntax dieser Elemente ist einheitlich, sie unterscheiden sich durch die ihnen zu Grunde liegende Semantik. 8

16 Eine Menge von inhaltlich zusammengehörigen Element- und Attributnamen wird zu einem Namensraum oder Namespace zusammengefasst. Dies ermöglicht die Verwendung mehrerer XML-basierter Markup Sprachen innerhalb eines Dokumentes, indem der Namespace als Attribut der einzelnen Elemente benutzt wird. 2.2 WEBSERVER UND MAPSERVER Eine heute weit verbreitete Architektur für Anwendungen in einem Netzwerk ist die so genannte Client-Server-Architektur [Floyd und Züllighoven, 1999]. Hierbei sind mindestens zwei Rechner über ein Netzwerk wie z.b. das Internet miteinander verbunden (Siehe Abbildung 2). Auf einigen dieser Rechner laufen Programme, die bestimmte Aufgaben auf Anfrage erfüllen. Diese Programme werden als Server, Service oder Dienst bezeichnet. Die Anfrage, die von einem Programm auf einem Rechner, dem Client, an einen anderen Rechner, den Server, gesandt wird, nennt man Request. Der Server erfüllt seine Aufgabe und sendet die angeforderte Antwort, auch Response genannt, an den Client. Abbildung 2: Client-Server-Architektur in Netzwerken Das senden von Daten vom Client zum Server, Beispielsweise des Requests, wird auch Upload oder Hochladen genannt. Das Gegenteil, der Download oder das Herunterladen von Daten bezeichnet die Übertragung von Daten, wie etwa der Response, vom Server zum Client. 9

17 Ein spezieller Server ist ein Webserver, auch Webservice, WWW-Server oder http- Server genannt, wobei http für Hypertext Transfer Protocol steht. Dies ist das Protokoll für die Übertragung von Daten zwischen einem Webserver und einem Client. In diesem Fall ist der Request der Aufruf einer Webseite. Die angeforderte Ressource ist durch einen Uniform Ressource Locator (URL) weltweit eindeutig bezeichnet [The Internet Society, 1999]. Dieser URL definiert den Request und ist in diesem Fall die Webadresse, die der User in die Adresszeile des Browsers eintippt. Die Response ist die Webseite, die vom Server an den Client, in diesem Fall meistens ein Web- Browser, übertragen wird. Die Inhalte einer Webseite können unterschiedliche Formate haben [Teege, 2003]. Beispielsweise können Texte mit Bildern kombiniert werden. Zur Kennzeichnung der Formate der einzelnen Inhalte wird der Multipurpose Internet Mail Extensions (MIME) Standard benutzt. Dieser Standard definiert einen eindeutigen Namen, den Mimetype, für jedes mögliche Format. Der Mimetype wird mit den Inhalten gemeinsam übermittelt. Nur durch Übermittlung des Mimetypes der Inhalte ist der Client in Lage, die unterschiedlichen Inhalte einer Webseite richtig darzustellen. Webseiten können sowohl statischen als auch dynamischen Inhalt enthalten. Ein Webserver ist nur in der Lage statische Inhalte zu Verfügung zu stellen. Sollen dynamische Inhalte zur Verfügung gestellt werden, wird neben dem Webserver ein weiteres Service zur Erzeugung dieser Inhalte benötigt. Ein Beispiel für einen dynamischen Inhalt einer Webseite ist eine Karte, schließlich ist nicht jeder User an demselben Gebiet interessiert. In diesem Fall werden im Request eine Reihe von Parametern als Name-Wert Paare inkludiert, die das gewünschte Gebiet definieren. Dieser Request wird an einen Mapserver weitergeleitet. Der Mapserver bildet aus den im Request enthaltenen Parametern eine Datenbankabfrage und sendet diese an die Datenbank. In der Datenbank werden die innerhalb des gewählten Gebietes liegenden Daten ausgewählt und an den Mapserver geleitet. Aus diesen Daten wird vom Mapserver eine Karte in Form eines Bilds produziert und an 10

18 den Webserver weitergeleitet. Der Webserver bettet die Karte in eine Webseite ein und sendet diese an den Client. Abbildung 3 illustriert die zeitlichen Abläufe bei der Bereitstellung von Karten im Internet. Abbildung 3: Zeitliche Abläufe bei der Bereitstellung von Karten im Internet Das http stellt die Methoden GET und POST zur Verfügung. Die Methode GET ermöglicht die oben erläuterten Abläufe wobei die Parameter im URL codiert werden. Im Gegensatz dazu wird bei der Methode POST eine XML-Datei, die die entsprechenden Parameter in XML codiert enthält, vom Client an den Server gesandt. Die Antwortzeit einer Webapplikation ist die Zeitspanne zwischen Absenden des Requests und Erhalt der Response. Diese Dauer setzt sich aus folgenden Teilen zusammen: Dauer der Übertragung des Requests vom Client an den Server Wartezeit am Server Dauer der Bereitstellung der Response am Server Dauer der Übertragung der Response vom Server zum Client Zeitspanne vom Erhalt der Response am Client bis zu ihrer Darstellung am Bildschirm Untersuchungen zeigen, dass der Engpass in der Antwortzeit einer Webapplikation in den meisten Fällen die Leistungsfähigkeit der Internetanbindung des Users ist 11

19 [Nielsen, 2004]. Die Darstellung der Response am Bildschirm des Clients hängt von der Leistungsfähigkeit der Hardware des Users ab und nimmt nur einen marginalen Prozentsatz der Antwortzeit ein. Auf beide Größen hat der Bereitsteller von Webservices keinen Einfluss. Anbieter von Webapplikationen müssen durch entsprechende Vorkehrungen dafür sorgen, dass der Engpass nicht in der Internetanbindung des Servers und im Antwortzeitverhalten des Servers liegt. 2.3 RELEVANTE OGC SPEZIFIKATIONEN Das OGC stellt eine Reihe von Spezifikationen für den standardisierten Zugriff auf Geodaten über das Internet [Internetressourcen /6/]. Tabelle 1 gibt einen Überblick über diese Spezifikationen. In ihnen ist jeweils die Struktur einer Reihe von Requests und den entsprechenden Responses definiert. Einige der Requests sind zwingend vorgeschrieben, andere optional. Nebenher besteht für Softwarehersteller die Möglichkeit weitere Funktionalitäten in Form von zusätzlichen Requests zur Verfügung zu stellen. Zur Übertragung sowohl der Requests als auch der Responses wird von OGC das http unterstützt, wobei sowohl die GET als auch die POST Methode zum Einsatz kommen können. Name der Spezifikation Catalog Interface Coordinate Transformation Service Web Coverage Service Web Feature Service Web Map Service Beschreibung Ermöglicht das Auffinden von Diensten, die Geodaten im Internet bereitstellen [OGC, 2002b] Ermöglicht die Transformation von Koordinaten [OGC, 2001b] Ermöglicht den Zugriff auf Geodaten in Rasterformaten [OGC, 2003a] Ermöglicht den Zugriff auf Geodaten in einer Objektstruktur [OGC, 2002a] Ermöglicht den Zugriff auf die visuelle Repräsentation von Geodaten in Form von Karten [OGC, 2001a] Tabelle 1: OGC Webservices für den standardisierten Zugriff auf Geodaten im Internet 12

20 Neben den Web Service Interfaces definiert das OGC unter anderem die Simple Feature Specification und die Geography Markup Language (GML). Simple Features beschreiben zweidimensionale Vektordaten mit bestimmten Einschränkungen [OGC, 1999]. GML ist eine XML-basierte Sprache für die Modellierung, den Transport und die Speicherung von Geodaten [OGC, 2003b]. Beispielsweise beschränkt sich in GML in der Version 2 auf Simple Features. In GML Version 3 werden auch mehrdimensionale Geoobjekte definiert. Durch diese Sprache soll der modellbasierte Austausch von Geodaten zwischen Geoinformationssystemen unterschiedlicher Hersteller ermöglicht werden. Eine Menge von Geoobjekten, die in GML codiert sind, wird als Featurecollection bezeichnet. In den beiden folgenden Unterkapiteln werden die wichtigsten Requests des Web Map Service sowie des Web Feature Service beschrieben. Diese Interfaces sowie deren im Folgenden beschriebenen Requests sind für das Verständnis der späteren Abhandlungen notwendig DAS WEB MAP SERVICE INTERFACE Die Web Map Service Interface Specification Version spezifiziert den standardisierten Zugriff auf Dienste, die georeferenzierte Karten im Internet anbieten [OGC, 2001a]. Eine Karte ist hierin als die visuelle Repräsentation von Geodaten in Form eines Bildes definiert. Das Interface beschreibt die drei Requests GetCapabilities, GetMap und GetFeatureInfo. Diese Requests dienen der Beschreibung des Services selbst, der Erstellung von Karten sowie der Abfrage von Attributdaten von in der Karte dargestellten Objekten. Die Implementierung der ersten beiden Operationen ist vorgeschrieben, die letzte kann optional implementiert werden (siehe Tabelle 2). 13

21 vv Request optional Response GetCapabilities nein Metainformationen über den Server in XML GetMap nein Eine Karte GetFeatureInfo ja Attributinformationen zu dargestellten Geoobjekten Tabelle 2: Die Requests des Web Map Service Interfaces Der GetCapabilities Request dient der Anfrage von Metainformationen über den WMS. Die Antwort auf diesen Request ist ein Dokument, das allgemeine Informationen über den Dienst selbst sowie detaillierte Informationen zu den abrufbaren Karten enthält. Aufgrund seiner Codierung in XML ist dieses Dokument sowohl vom Mensch als auch vom Computer lesbar und kann dadurch automatisiert weiterverarbeitet werden. Der GetMap Request dient der Erstellung von Karten, deren Inhalt, Aussehen, Größe und Ausgabeformat durch eine Reihe von Parametern genau definiert ist. In Tabelle 3 sind diese Parameter gelistet. Die Parameter SERVICE, REQUEST und VERSION beschreiben das Interface sowie den Request. Die Werte dafür sind festgelegt (siehe Tabelle 3). Die Parameter LAYERS, SRS und BBOX definieren den Inhalt der Karte. Der Wert von LAYERS ist eine durch Kommata getrennte Liste der einzelnen Layer, die zu einer Karte kombiniert werden sollen. Hierbei sind sowohl Raster- als auch Vektordaten zugelassen. SRS bezeichnet das gewünschte Koordinatensystem der Karte. Der gewünschte Kartenausschnitt wird durch Angabe der minimalen sowie der maximalen X- und Y-Koordinaten als Wert für BBOX festgelegt. Das Layout der Karte ergibt sich aus dem Wert für den Parameter STYLES, der für jede abgefragte Featureklasse einen, bei der Darstellung anzuwendenden Stil beschreibt. Höhe und Breite der ausgegeben Karte in Pixels werden durch die Parameter HEIGHT und WIDTH definiert. Das Ausgabeformat der Karte wird durch einen Mimetype als Wert für den Parameter FORMAT festgelegt. Alle diese Parameter sind beim Aufruf des GetMap Request anzugeben. 14