Großer Beleg Konzeption und Integration der Open Geospatial Consortium Web Services in die Open Service Process Platform - TU Dresden
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
T ECHNISCHE U NIVERSITÄT D RESDEN
FAKULTÄT I NFORMATIK
I NSTITUT FÜR S OFTWARE - UND M ULTIMEDIATECHNIK
P ROFESSUR FÜR S OFTWARETECHNOLOGIE
Großer Beleg
Konzeption und Integration der Open Geospatial
Consortium Web Services in die Open Service Process
Platform
bearbeitet von
Daniel Kadner
geboren am 08.01.1983 in Plauen
Hochschullehrer: Prof. Dr. rer. nat. habil. Uwe Aßmann
Betreuer: Dipl.-Inf. Sebastian Richly
Abgabe: 31. Dezember 2009Selbstständigkeitserklärung
Hiermit erkläre ich, dass ich den von mir eingereichten Großen Beleg zum Thema:
KONZEPTION UND I NTEGRATION DER O PEN G EOSPATIAL C ONSORTIUM W EB S ERVICES IN DIE
O PEN S ERVICE P ROCESS P LATFORM
selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt, sowie
Zitate kenntlich gemacht habe.
Dresden, den 1. Januar 2010
Unterschrift1
Inhaltsverzeichnis
Tabellenverzeichnis 2
Abbildungsverzeichnis 3
1 Einleitung 4
1.1 Aufgabenbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Motivation & Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Open Geospatial Consortium Web Services 6
2.1 Open Geospatial Consortium (OGC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Einführung in die Open Geospatial Consortium Web Services . . . . . . . . . . . . . . . 8
2.3 Web Map Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 Schnittstellen des Web Map Service . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Web Feature Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Schnittstellen des Web Feature Service . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Web Coverage Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.1 Schnittstellen des Web Coverage Service . . . . . . . . . . . . . . . . . . . . . 22
2.6 Web Processing Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6.1 Schnittstellen des Web Processing Service . . . . . . . . . . . . . . . . . . . . . 25
2.7 Verkettung von OGC Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 Integrationskonzepte in die Open Service Process Platform 30
3.1 Service Orientierte Architekturen – SOA . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Web Service als Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2 Proxy Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.3 Einbinden eines Web Service als Proxy in OSPP . . . . . . . . . . . . . . . . . 44
3.3 RESTful Web Services in OSPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.1 REpresentational State Transfer – REST . . . . . . . . . . . . . . . . . . . . . . 452
3.3.2 Role Model Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.3 Einbinden eines RESTful Web Service . . . . . . . . . . . . . . . . . . . . . . 51
4 Implementierung 54
4.1 Erstellung der Open Geospatial Web Services . . . . . . . . . . . . . . . . . . . . . . . 54
4.2 Einbinden in OSPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.1 Erstellung eines Web Services als Proxy . . . . . . . . . . . . . . . . . . . . . . 57
4.2.2 Integration in OSPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5 Zusammenfassung und Ausblick 63
5.1 Ergebnisse der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6 Glossar 65
Literaturverzeichnis 67
A Quellcode 72
B CD-Inhalt 78Tabellenverzeichnis 3 Tabellenverzeichnis 2.1 Parameter des getMap Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Parameter des getFeatureInfo Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3 Parameter der describeFeatureType Operation . . . . . . . . . . . . . . . . . . . . . . . 18 2.4 Parameter der getFeature Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5 Parameterliste des lockFeature Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6 Parameter des describeCoverage Request . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.7 Parameter des getCoverage Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.8 Parameter des describeProcess Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.9 Parameter eines execute Aufrufes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.1 Stärken und Schwächen von SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Abbildungsverzeichnis 4 Abbildungsverzeichnis 2.1 Open Geospatial Consortium Web Service Komponentendiagramm . . . . . . . . . . . . 9 2.2 Systemarchitektur eines WMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3 Sequenzdiagramm eines WMS Request . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4 Zustandsdiagramm einer Sperrung, entnommen aus [Ope05b] . . . . . . . . . . . . . . 21 2.5 GetCoverage Anfrage als UML Klassendiagramm . . . . . . . . . . . . . . . . . . . . . 24 2.6 Sequenzdiagramm eines WPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.7 Client-koordinierte Diensteverkettung, entnommen aus [Ala03] . . . . . . . . . . . . . . 28 2.8 statische Verkettung eines Gesamtdienstes, entnommen aus [Ala03] . . . . . . . . . . . 29 3.1 publish-find-bind Prinzip eines Web Services . . . . . . . . . . . . . . . . . . . . . . . 32 3.2 Orchestrierung von Diensten in einer SOA, entnommen aus [Kos07] . . . . . . . . . . . 33 3.3 Choreographie von Diensten in einer SOA, entnommen aus [Kos07] . . . . . . . . . . . 34 3.4 Möglichkeiten der Konzeptionierung der Anbindung von OGC Web Services an OSPP . 36 3.5 Web Service Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.6 Aufbau einer SOAP-Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.7 Einordnung von SOAP in das OSI-Schichtenmodell . . . . . . . . . . . . . . . . . . . . 39 3.8 Aufbau eines WSDL-Dokumentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.9 Web Service Interaktionsschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.10 Das Proxy Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.11 Sequenzdiagramm eines OWS Aufrufs mittels Web Service Proxy . . . . . . . . . . . . 45 3.12 Role Model Abhängigkeiten, entnommen aus [RG98] . . . . . . . . . . . . . . . . . . . 50 3.13 Basis Role Space, entnommen aus [RGA09] . . . . . . . . . . . . . . . . . . . . . . . . 52
1. EINLEITUNG 5 1 Einleitung 1.1 Aufgabenbeschreibung Der vorliegende Beleg führt eine vergleichende Untersuchung vorhandener Web Services durch, die dem Standard des Open Geospatial Consortium unterliegen. Dabei erfolgt eine Beschränkung auf Web Ser- vices zur Visualisierung, zum Zugriff und zur Prozessierung von Geodaten. Im Anschluss werden diese Dienste exemplarisch implementiert. Der nächste Schritt ist die Integration dieser Dienste des Open Geospatial Consortium in die Open Service Process Plattform, um mit deren Hilfe eine Möglichkeit der Orchestrierung von Open Geospatial Consortium Web Services bereitzustellen. Zum Abschluss er- folgt eine Evaluierung der Services hinsichtlich der Einsetzbarkeit in Verbindung mit der Open Service Process Plattform und ein Vergleich zum Implementierungsaufwand zu REST Services. 1.2 Motivation & Ziel Als Motivation für dieses Vorhaben und Ziel der Orchestrierung von Open Geospatial Consortium Web Services dient das Projekt SoKNOS (Service-orientierte ArchiteKturen zur Unterstützung von Netzwer- ken im Rahmen öffentlicher Sicherheit). Ein Partner in diesem Projekt ist die Professur für Geoinfor- mationssysteme der TU Dresden. Als weitere Partner sind SAP, ESRI, die Berliner Feuerwehr und das Frauenhofer Institut vertreten. Ein kleineres Teilprojekt aus dieser Fachgruppe ist die Konzeptionierung und Realisierung einee Hoch- wassersimulation (HWSIM) als Simulationstool für den Katastrophenschutz. Hierbei werden aktuelle Hochwasserdaten, die mittels Sensoren gemessen wurden, entnommen, verarbeitet und anschließend zur weiteren Entscheidungsunterstützung im Katastrophenfall heran gezogen. Dabei ist die Bedingung, dass die Eingabedaten vor der Verarbeitung und Analyse in Form von Rasterdaten vorliegen. Mittels einer Prozessierung wird auf den vorhandenen Daten eine Hochwassersimulation gestartet und das Ergebnis in Form von Vektordaten für einen weiteren Zugriff gespeichert werden. Dieses komplette Teilprojekt lässt sich mittels standardisierter georäumlicher Dienste umsetzen, welche in Form eines ausführbaren Geschäftsprozesses genutzt werden. Die georäumlichen Dienste richten sich dabei nach den Web Ser-
1. EINLEITUNG 6 vice Standards des Open Geospatial Consortium (OGC). Für die effiziente Orchestrierung von Open Geospatial Consortium Web Services soll die Open Service Process Platform (OSPP) genutzt werden. Die Dienste des Open Geospatial Consortium stellen bereits Dienste zum Aufbewahren und zur Spei- cherung von Raster- beziehungsweise Vektordaten zur Verfügung. Die Prozessierung der Hochwasser- rohdaten in entscheidungsfördernde Daten und deren Visualisierung kann ebenfalls mit Hilfsmitteln des OGC bewerkstelligt werden. Diese liegen jedoch in Form einzelner Prozesse vor, die sich nur manuell zu Workflows zusammensetzen lassen. Mit Hilfe der Open Service Process Platform ist es dem Nutzer möglich Workflows unter Nutzung einer intuitiven und verständlichen Benutzeroberfläche zusammen zu stellen und auch für eine spätere Verwendung zu speichern. In der vorliegenden Version 2.0 von OSPP werden allerdings ausschließlich SOAP und WSDL basierende Dienste unterstützt. Im Kapitel 2 werden die einzelnen verwendeten Dienste des Open Geospatial Consortium, sowie deren Protokolle vorgestellt. Zur Integration der Open Geospatial Consortium Web Service wurden zwei Konzepte umgesetzt. Kapi- tel 3 betrachtet diese zwei Konzepte näher. In Abschnitt 3.2 wird die Möglichkeit der Erstellung eines WSDL und SOAP basierenden Dienstes als Konverter zwischen OSPP und OGC Web Service näher vorgestellt. Ein weiterer Ansatz, der in Abschnitt 3.3 vorgestellt wird, ist die direkte Integration des Pro- tokolls der Open Geospatial Consortium Web Services. Die Implementierung der Konzepte behandelt das Kapitel 4. Zuvor werden in dem gleichen Kapitel die genutzten Open Geospatial Consortium Web Services exemplarisch implementiert. Den Abschluß bildet das Kapitel 5 mit einer Zusammenfassung, einem Ausblick und dem Fazit.
2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 7 2 Open Geospatial Consortium Web Services 2.1 Open Geospatial Consortium (OGC) Entstehung des OGC Es existiert eine Vielzahl an unterschiedlichen Technologien und Software-Lösungen im Internet. Je un- übersichtlicher dieser Markt wird, desto bedeutsamer ist das Verabschieden und Entwickeln allgemein- gültiger Standards. Dabei spielt weniger die Realisierung konkreter Funktionalitäten in einer Softwarean- wendung eine Rolle, als vielmehr die Kompatibilität der Ausgangs- und Teilergebnisdaten Dementspre- chend besteht ein hoher Bedarf bei Softwareanbietern und -entwicklern sich an vorliegenden Standards zu orientieren. Dies können Standards für das Internet, wie zum Beispiel HTML, oder aber auch Ansätze aus dem Bereich der Geoinformationssysteme mit Netzwerkbezug sein. Da die Bedeutung der geoin- formationstechnischen Nutzung des Internets immer mehr zunahm, wurde im Jahre 1994 das OpenGIS Consortium (OGC) gegründet. Später erfolgte eine Umbenennung in das Open Geospatial Consorti- um [Ope]. Dessen Aufgabe ist die Entwicklung einer Infrastruktur für Geodaten zu unterstützen, die unabhängig von Software und Datenformaten nutzbar ist. Es soll möglich sein die unterschiedlichsten Diensteanbieter zu nutzen, aber immer mit der Bedingung, dass diese Dienste über die gleiche, standar- disierte Schnittstelle angesprochen werden können. Dafür werden bereits vorhandene Spezifikationen aus dem Bereich der Informationstechnologie genutzt und an die Anforderungen der Geoinformatik ad- aptiert. Ziele des OGC Das OGC verfolgt das Ziel die Entwicklung von raumbezogenen Daten, im speziellen Geodaten, auf Basis allgemeingültiger Standards, zum Zweck der Interoperabilität festzulegen. Es definiert die Dien- ste einer Komponente die von anderen Komponenten aufgerufen werden können, wofür wiederum eine offene Definition der Schnittstelle Vorraussetzung ist. Damit verfolgt das OGC die Vision eine vollstän- dige Integrierung des gesellschaftlichen, wirtschaftlichen und wissenschaftlichen Nutzens von elektroni- schen Standortdaten in den Handels- und Institutionsprozess zu schaffen. Die Entwicklung dieser Ziele in kommerziellen Produkten erfolgt durch die Mitglieder des OGC. Die 387 Mitglieder beziehungsweise
2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 8
Organisationen (Stand 03.10.2009) stammen aus den unterschiedlichsten Bereichen der Wirtschaft, In-
dustrie und staatlichen Einrichtungen. Als namhafte Vertreter sind ESRI, Google, Lufthansa, die NASA
und auch die Technische Universität Dresden zu nennen.
Arbeitsweise des OGC
Alle oben genannten Mitglieder sollen die Möglichkeit haben an der Entwicklung der verabschiede-
ten Spezifikation der OGC mit teilzunehmen. Die Basis für die Implementierungsspezifikationen bilden
dabei die abstrakten Spezifikationen. In diesen wird beschrieben welche Plattform mit welcher Schnitt-
stellenbeschreibungssprache und welche Objektklassen inklusive der Eigenschaften und Methoden zum
Einsatz kommen. Mitglieder, beziehungsweise auch Mitgliedergruppen, sind dazu aufgefordert eigene
Entwürfe zu entwickeln und zur Diskussion vorzulegen. Aus den entsprechenden Anmerkungen und Ver-
besserungsvorschlägen wird eine endgültige Version erarbeitet. Parallel zur Fertigstellung entwickeln die
Mitglieder ebenso einen Prototyp, der das Funktionieren der verabschiedeten Schnittstelle demonstrieren
soll. Parallel dazu standardisiert ein Technisches Komitee (TC 211) [ISO] der International Organisati-
on for Standardization (ISO) [Int] diese Spezifikationen, um daraus international Normen zu erstellen.
Neben diesem Specifications Programm existiert des weiteren das Interoperability Programm und das
Outreach Programm. Das Interoperability Programm dient zum Beschleunigen der Entwicklung und der
Akzeptanz der Open Geospatial Spezifications und das Oureach Programm erweitert die Spezifications
um entsprechende Testbeds und Referenzimplementierungen.
Überblick über OGC Implementation Specifications
Die OGC Implementation Specifications sind das Resultat des oben genannten Entwicklungsprozesses.
Dies sind Technikspezifikationen, die wiederum Teil der abstrakten Spezifikation sind. Es existieren
Implementation Spezifications im Bereich von Sensornetzen und dem Visualisieren und Bereitstellen
von Geodaten. Ebenfalls sind Standards zur Beschreibung und Definition von Geodaten hinterlegt. Das
Hauptaugenmerk der Spezifikationen liegt dabei in der Definition von webbasierten Diensten. Durch
diese Open Geospatial Consortium Web Services werden verteilte Datenquellen und Funktionalitäten
über das Internet zur Verfügung gestellt. Die wichtigsten OGC Web Service Spezifikationen sind:
1. Web Map Service (WMS): Ermöglicht das Visualisieren von Karten in Form von Bildern sowie
den Zugriff auf Sachinformationen von Geoobjekten.
2. Web Feature Service (WFS): Ermöglicht den lesenden und schreibenden Zugriff auf Geodaten
die in Form von Vektordaten vorliegen. Die Anfragen erfolgen mit einem fest definierten Ablauf
mittels XML-basierter Anfragesprache.2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 9
3. Web Coverage Service (WCS): Ermöglicht den lesenden und schreibenden Zugriff auf Rasterda-
ten, welche mehrdimensional sein können.
4. Web Catalog Service (WCAS): Ermöglicht die Recherche von Daten unter Berücksichtigung fach-
licher, zeitlicher und räumlicher Kriterien. Dabei werden nicht die Daten selbst verwaltet, sondern
deren Metadaten.
5. Web Coordinate Transformation Service (WCTS): Ermöglicht das Transformieren der gesendeten
Daten in Form vder Sprache Geography Markup Language (GML) in ein gewünschtes Raumbe-
zugssystem.
6. Web Processing Service (WPS): Ermöglicht den Zugriff auf Prozessierungsfunktionalitäten für
georeferenzierte Daten.
2.2 Einführung in die Open Geospatial Consortium Web Services
Bislang existiert bislang keine einheitliche Begriffsdefinition eines Web Services [Bet01]. Oftmals wer-
den Web Services als Softwaresystem mit dem Ziel eine Interaktion zwischen Maschinen über ein Netz-
werk zu erstellen. Dabei findet eine Kommunikation mit Hilfe der Extensible Markup Language (XML)
statt, welche vom World Wide Web Consortium (W3C) [Wor08] spezifiziert wurde. Ein weiterer Stan-
dards ist das Simple Object Access Protocol (SOAP), welcher eine Kommunikation zwischen dem Client
und dem Server mit bereits vorhandenen Web Standards ermöglicht. Ein weiterer Standard ist die Web
Service Description Language (WSDL), welche die Schnittstelle eines SOAP-kompatiblen Dienstes be-
schreibt. Aufgrund der allgemeingültigen Beschreibung und dessen technischer Umsetzung lassen sich
die auf obigen Standards basierten Dienste einfach in jedes Programmumfeld eingliedern. Unabhängig
vom World Wide Web Consortium hat sich die Entwicklung eines Standards zum Austausch von geo-
räumlichen Daten unabhängig von ihrem Datenformat vollzogen. Die Spezifikation dieser Dienste wurde
vom Open Geospatial Consortium entwickelt. Im Gegensatz zu einem W3C Web Service behandelt ein
OGC Web Service (OWS) nur einen bestimmten Typ an Daten. Zusätzlich werden OGC Web Services
von allen gängigen Geoinformationssystemen (GIS) unterstützt und erlauben somit GIS Nutzern den
Interface-basierten Umgang mit diesen Diensten. Geoinformationssysteme sind rechnergestützte Infor-
mationssysteme mit deren Hilfe raumbezogene Vektor- und Rasterdaten digital erfasst, verarbeitet, ana-
lysiert sowie grafisch dargestellt werden können. Abfrage- und das Antwortprotokoll eines OWS sind
standardisiert und die Funktionen, die ein Dienst zur Verfügung stellen muss, sind fest vorgegeben. Dies
vereinfacht die Verwendung von OGC Web Services im Gegensatz zu W3C Diensten. Web Services und
OGC Dienste sind allerdings zwei grundsätzlich verschiedene Standards die nicht problemlos miteinan-2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 10
Visualisierung von Geodaten
Zugriff auf Geodaten
GetCapabilities OGC Web
Service Prozessierung von Geodaten
Web Map Web Coverage Web Feature Web Processing
Service Service Service Service
GetMap GetCoverage GetFeature Execute
GetFeatureInfo DescribeCoverage DescribeFeatureType DescribeProcess
Transaction
Web Feature
Service
LockFeature
Transaction
Abbildung 2.1: Open Geospatial Consortium Web Service Komponentendiagramm
der verknüpfbar sind. Eine Interoperabilität zwischen diesen beiden Diensten zu schaffen ist weiterhin
ein Ziel des Open Geospatial Consortium und deren Mitgliedschaft, denn diese Dienste unterliegen einer
hohen Nachfrage, da sie einfach zu implementieren und anschliessend auch einfach zu nutzen sind. Aus
diesem Grund existieren nur wenige Umsetzungen von georäumlichen Diensten ohne die Unterstützung
des OGC Standards. Im Folgenden werden die verschiedenen Standards zur Visualisierung, Bearbeitung
und Prozessierung von Geodaten näher vorgestellt. Ein Überblick über die Abhängigkeiten der OGC
Web Service und der vorhandenen Operationen ist in Abbildung 2.1 dargestellt.2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 11
2.3 Web Map Service
Vor der Entwicklung des Web Map Service existierten bereits die verschiedensten Internet Map Servers
(IMS) zur Bereitstellung von Karten über das Internet. Diese sind sich zwar hinsichtlich ihrer Archi-
tektur sehr ähnlich, aber trotzdem ist zwischen den einzelnen Diensten keine Interoperabilität gewähr-
leistet. Ein Web Client konnte somit meist nur mit einem speziellen, auf ihn zugeschnitten, Typ von
Dienst arbeiten. Somit war es auch nicht möglich auf räumlich verteilte Systeme die von unterschiedli-
chen Anbieter erstellt wurden zuzugreifen und deren resultierenden Karten zu überlagern. Aus diesem
Grund wurde 1999 erstmals vom OGC ein Standard für einen interoperablen Map Server [Ope06] ent-
wickelt, welcher Anfang 2000 in der Version 1.0.0 verabschiedet wurde. Durch diese Standardisierung
der Zugriffsschnittstelle ergibt sich die Möglichkeit eine Interoperabilität zwischen den verschiedenen
Systemen der Hersteller zu gewähren, weil alle Komponenten beliebig austauschbar sind. In Abbildung
2.2 ist ein solches System dargestellt.
Applet Plugin
Web-Browser (z.B. Safari)
CLIENT
Applet Plugin GIS-Applikation
Web-Browser (z.B. Firefox) Workstation
Webserver (z.B. IIS, Apache)
SERVER
weitere
Web Map Server Administrationstools
Komonenten
Festplatte
Datenbank (z.B. Oracle, SQL)
Abbildung 2.2: Systemarchitektur eines WMS
2.3.1 Schnittstellen des Web Map Service
Bei der Implementierung eines WMS sind im Wesentlichen die drei standardisierten Schnittstellen get-
Capabilities, getFeatureInfo und getMap unterstützt werden. Mittels dieser Schnittstellen ist es möglich
georeferenzierte Daten, welche in Form von Vektor- beziehungsweise Rasterdaten vorliegen können, zu
visualisieren. Dies geschieht unabhängig von den Geodatenprovidern und systemen. Die Darstellung der2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 12 kartographischen Information kann in jedem Browser betrachtet werden, wobei Karten mit identischer Georeferenzierung von unterschiedlichen Servern aufgerufen und bei einem kaskadierenden Dienst in Form eines Ebenenmodells übereinander legbar sind. Werden andere Clients zur Kartendarstellung ge- nutzt, können verschiedene Dienste auch gleichzeitig genutzt werden und deren Karten in einem Ebe- nenmodell übereinander gelegt werden. Es werden dabei nur Bilder generiert und keine Rohdaten der Geodaten übermittelt. Der Aufbau eines WMS folgt dem Prinzip der Client-Server Architektur. Demzu- folge bedarf ein WMS-konformer Client eines beliebigen Herstellers lediglich einen WMS-konformen Server um mit diesem kommunizieren zu können. Die Hauptfunktion eines WMS liegt in der Abfragemöglichkeit von Datenbeständen und der Datenvi- sualisierung von Analyseergebnissen. Aufbau einer OGC-konformen WMS-Anfrage Der Aufbau der Anfrage ist bei allen drei standardisierten Schnittstellen des WMS gleich. Die Anfra- gen sind im CGI Standard Style geschrieben. Das heißt die Parameter werden aus Name-Wert-Paaren gebildet, welche mit einem “&”-Zeichen getrennt werden. Beispiel: http://141.30.100.137/cgibin/wms?Service=WMS&VERSION=1.1.1&Request= GetMap&LAYERS=buildings,streets&SRS=epsg:4326&BBOX= 13.715946,51.021249,13.734128,51.034957& FORMAT=image/jpeg& width=1024&height=768 Die Datenübertragung erfolgt über das HTTP-Protokoll. Allgemein ist der Aufruf von nachfolgender Form: http://server_adress/path/script?param1=value¶m2=value... Die ersten drei Parameter des Beispiels entsprechen den Basisparametern, die jeder WMS umsetzen kann. Der erste Parameter verlangt von dem Server die Funktion eines WMS nutzen zu dürfen. Der zweite Parameter hingegen ist erstmals für die Schnittstelle relevant, da dieser angibt welche vom WMS unterstützte Version genutzt werden soll. Mit dem Request-Parameter erfolgt die eigentliche Abfrage der gewünschten Schnittstelle. Die Schnittstellen getMap und getFeatureInfo verlangen eine Reihe wei- terer Eingabeparameter, wie in dem obigen GetMap-Beispiel veranschaulicht ist. Die Reihenfolge der Eingabeparameter ist für den WMS nicht von Bedeutung. Sollten Parameter vorkommen die aus Listen bestehen (siehe LAYERS), so werden diese durch ein Komma getrennt.
2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 13
1
2
3
4 application/vnd.ogc.wms_xml
5
6
7
8
9
10 ...
11
12
13
14
15
16 image/gif
17 image/png
18 image/jpeg
19 image/svg+xml
20 ...
21
22 ...
23
Listing 2.1: Beispiel eines getCapabilities Dokuments
getCapabilities-Methode
Der getCapabilities-Request ist der erste der drei standardisierten Schnittstellen und bezeichnet die ein-
zige Methode, die alle OGC Web Services unterstützen müssen [Ope07b]. Mit dieser Methode kann sich
der Client, im Falle der Kaskadierung auch ein Server, darüber informieren, welche Datenformate der
WMS Server interpretieren kann und welches Koordinatensystem verwendet wird. Dies ist beispiels-
weise für die Ausgabe der Karte bei einem getMap-Request bedeutsam. Mit Hilfe der getCapbilities-
Methode erfolgt somit eine Selbstbeschreibung des Servers. Die Beschreibung der eigenen Fähigkeiten
erfolgt durch die Anwendung der Sprache XML. Die zum Client zurück gelieferte XML Datei besteht
aus einem Service- und einem Capabilities-Teil. Der Capabilities-Teil beinhaltet zum einen den Request-
und zum anderen den Layer-Abschnitt. Im Requestblock werden Informationen zur URL des Dienstes
und zum Koordinatensystem der angebotenen Geodaten aufgeführt. In Listing 2.1 ist eine Antwort auf
eine getCapabilities Anfrage in Auszügen aufgeführt.
Durch die Angaben in dem Tag erhält der Nutzer eine Auskunft über die Ausgabeformate.
Innerhalb des Tags werden die nutzbaren Übertragungsprotokolle angegeben. Der zwei-
te Teil des Capabilities Abschnitts besteht aus dem Layer-Teil. In diesem werden die zur Darstellung2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 14
verfügbaren Layer, welche von einem WMS Client genutzt werden können, aufgezeigt sowie deren An-
ordnung angegeben. In dem unten aufgeführten Listing 2.2 wird ein Layer mit dem Namen “Streets”,
unter Zuhilfenahme verschiedener Parameter, wie Kartenausschnitt oder Sichtbarkeit beschrieben.
Beispiel:
1
2 Streets
3 Streets
4 epsg:4326
5
6
7
Listing 2.2: Ausschnitt aus einem getCapabilities Dokument
Jede Ebene die von dem WMS zur Verfügung gestellt wird erfolgt durch eine Beschreibung mit dem Tag
. Ist die angegebene Ebene ausserdem mit Sachdaten verknüpft, wird das Attribut queryable auf
1 gesetzt. Dadurch ist dieser Layer dann mittels getFeatureInfo abfragbar.
getMap-Methode
Mittels der getMap-Methode ist es dem Client möglich eine Karte beziehungsweise Grafik vom ange-
fragten Ausschnitt des Datenservers zu erhalten. In der URL sind die Übergabeparameter des Requests
sowie kartenspezifische Merkmale, wie zum Beispiel die Eckpunkte einer Boundingbox, das Koordina-
tensystemder Karte, die anzuzeigenden Layer, sowie das Ausgabeformat enthalten. Ein Beispiel für einen
solchen Aufruf wird in Kapitel 2.3.1 erläutert. In der folgenden Tabelle sind alle Parameter aufgeführt
die für einen getMap-Aufruf mandatorisch beziehungsweise optional sind.
getFeatureInfo-Methode
Mit dem getMap-Befehl ist es möglich Karten der gewünschten Daten im Client anzuzeigen. Ist es wei-
terhin notwendig Abfragen über die zur Verfügung gestellten Geodaten zu stellen, so liefert getFeatu-
reInfo entsprechende Informationen, wenn das Attribut queryable auf true gesetzt wurde. Die Anfrage
selbst beinhaltet die gemeinsamen Parameter und zusätzliche Informationen, wie eine Liste von Layern
über die eine Information abgefragt werden soll. Als Antwort erhält der Client eine XML Datei mit den
Informationen über die angefragten Features. Ein Feature beschreibt hierbei einen Fakt aus der realen
Welt innerhalb von Geoinformationssystemen. In der Tabelle 2.2 ist eine vollständige Auflistung über
die zu nutzenden Parameter des getFeatureInfo-Requests zu finden.2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 15
Request Parameter Beschreibung Mandatorisch/Optional
VERSION=version WMS Versionsnummer M
REQUEST=getMap WMS Schnittstellenname M
LAYERS=layers Liste der anzuzeigenden Ebenen M
SRS=epsg:4326 Koordinaten-Referenzsystem M
BBOX=minx,miny,maxx,maxy Boundingbox mit den Eckpunk- M
ten des umschließenden Recht-
ecks
WIDTH=output-width Breite des Ausgabebildes M
HEIGHT=output-height Höhe des Ausgabebildes M
FORMAT=output format Ausgabeformat M
TRANSPARENT=true/false Erzeugung eines transparenten O
Bildes
BGCOLOR=color_value Hintergrundfarbe des Bildes O
Tabelle 2.1: Parameter des getMap Request
Verarbeitung eines WMS Requests
Der Grundgedanke eines WMS ist einfach gehalten. Es wird ein mit Parametern angereicherter Request
an einen WMS-fähigen Server geschickt um ferner dem Client als Antwort eine XML-formatierte Datei,
die entweder nähere Informationen zum angeforderten Dienst liefert (getCapabilities), eine Karte zurück
gibt (getMap) oder ausführliche Informationen über ausgewählte Features ausgibt (getFeatureInfo), zu-
rück zu liefern. Diese Daten werden vom Client ausgewertet und anschliessend angezeigt. Es ist ebenfalls
möglich die Daten von verschiedener WMS Server zusammen zuführen und in Form einer Karte ausge-
ben zu lassen. Unternehmen können auf diese Weise Dienste anbieten, die sowohl auf Daten interner als
auch auf jene externer Anbieter aufbauen. Für den Endnutzer wiederum ist es unbedeutend, ob die Da-
ten zentral oder verteilt bei verschiedenen Anbietern vorliegen. Der Kommunikationsprozess wird somit
vereinfacht. Zudem werden auftretende Redundanzen bezüglich der Datenhaltung bereits von vornherein
weitestgehend vermieden. In Abbildung 2.3 ist eine getMap-Abfrage an einen WMS und deren Verlauf
exemplarisch dargestellt.
Bisher ist es dem Nutzer nur bedingt möglich selbst das Aussehen der Karte zu bestimmen. Er kann nur
dann grafische Manipulationen vornehmen, wenn vom Anbieter verschiedene Styles angeboten werden.
Dies wird durch die Erweiterung Styled Layer Descriptor (SLD) [Ope02], welche 2002 vom OGC ver-
abschiedet wurde, vereinfacht. Dieser Standard erlaubt es dem Benutzer das Layout der Karte individuell
anzupassen. Das SLD ist ein XML-Dokument welches vom Client bei einem Request dem WMS-Server2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 16
Request Parameter Beschreibung Mand./Opt.
VERSION=version WMS Versionsnummer M
REQUEST=getFeatureInfo WMS Schnittstellenname M
QUERY_LAYERS=layers_list Liste der Layer M
INFO_FORMAT=output_format Ausgabeformat M
FEATURE_COUNT Featurenummer O
X=pixel_Column X-Koordinate des Pixels M
Y=pixel_Row Y-Koordinate des Pixels M
Tabelle 2.2: Parameter des getFeatureInfo Requests
Abbildung 2.3: Sequenzdiagramm eines WMS Request
übergeben wird. Mit der GET-Methode beim HTTP-Verfahren kann dies durch den vollständigen Ein-
bau der einzelnen Parameter in die URL geschehen. Eine andere Möglichkeit ist das Bereitstellung eines
XML-Dokuments auf einer Webseite, welche dann innerhalb der Anfrage-URL referenziert wird. Sollte
die Übertragung mittels POST-Verfahren geschehen, können die Parameter des SLD in einem angehäng-
ten XML-Dokument mit transportiert werden. Zusammengefasst ist ein WMS mittels eigenen Styles
durch den Einsatz einer der drei nachfolgenden Verfahren erweiterbar:
• Normaler getMap und SLD als Verweis in der URL (SLD ist in diesem Fall meist fest)
• Normaler getMap mit SLD in URL (SLD oftmals sehr lang, wodurch die URL ebenfalls lang wird,
Sonderzeichen sind zu beachten)2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 17 • getMap als XML-Aufruf (Aufruf selbst und angehängte SLD)
2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 18 2.4 Web Feature Service Im vorherigen Teilkapitel wurde der Standard Web Map Service vorgestellt, mit dessen Hilfe es mög- lich ist sich clientseitig Karten verschiedener Server im Browser anzeigen zu lassen. Ein Web Feature Service liefert dem Client in einem speziellen XML-Syntax, der Geography Markup Language (GML) [Ope07a], die reinen Geodaten, also Daten, welche nicht visualisiert sind. In Geoinformationssystem werden Fakten aus der realen Welt als Feature beschrieben. Somit kann ein Feature beispielsweise ein Fluss, ein Flussabschnitt oder auch eine Brücke über einen Fluss beschreiben. Im Gegensatz zum oben erwähnten WMS wird der WFS allerdings noch nicht in einem großen Maße von kommerziellen Pro- dukten unterstützt. Durch dessen Implementierung würden sich die Geoinformationssysteme allerdings sehr weit öffnen. Die Anfrage an einen WFS erfolgt unter anderem über eine spezielle Form der XML- codierten Sprache, der Filter Encoding Implementation Specification [Ope05a], welche ebenfalls vom OGC standardisiert wurde. 2.4.1 Schnittstellen des Web Feature Service Im Jahr 2002 veröffentlichte das Open Geospatial Consortium den Standard des Web Feature Service [Ope05b], welches in version 1.0.0 aktuell ist. Mit Hilfe dieses Standards ist es möglich Geodaten welche an einen Web Feature Server angebunden sind in einem Webbrowsers des Client anzeigen und bearbeiten zu lassen. Die Form von Geodaten ist allerdings beschränkt auf vektorbasierte Daten. Diese werden mit- tels GML übertragen. Mit deren Hilfe wird die Speicherung und der Transport von geografischen Daten XML-basiert ermöglicht. Mittlerweile liegt der Standard in der Version 3.2.1 aus dem Jahre 2007 vor. Im Allgemeinen ist der Ablauf einer Web Feature Service Kommunikation wie folgt: Zunächst sendet der Client einen getCapabilities-Request und erhält daraufhin ein Capabilities-Dokument mit allgemeinen Informationen über die Funktionalität des Servers und dessen unterstützten Methoden. Danach erfolgt eine Anfrage auf die FeatureTypes, also Schemata in GML-Kodierung. Über die describeFeatureType Operation kann eine genauere Beschreibung des FeatureTypes angefragt werden. Anschließend findet eine Abfrage der gewünschten Features mit Hilfe der getFeature-Methode statt. Ist diese Transaktion abgeschlossen erstellt der Server einen Statusbericht und schickt diesen zurück an den Client. Im Falle eines Fehlers wird beispielsweise eine Exception inklusive einer Fehlerbeschreibung erzeugt. Die Imple- mentierung eines Web Feature Service ist in zwei Varianten möglich. Zum einen gibt es die “Read-only”- Version, den sogenannten Basic WFS. Mit ihm ist es lediglich möglich die Methoden getCapabilities, describeFeatureType und getFeature zu nutzen. Die andere Variante ist der Transaction WFS. Hierbei werden alle Methoden eines Basic WFS und die Transaction Operation unterstützt. Damit kann der Cli- ent Manipulationen an den Daten vornehmen, welche für die Laufzeit des Vorgangs gesperrt werden.
2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 19
Eine Veränderung der Daten ist mittels der Operationen CREATE, DELETE und UPDATE möglich. Mit
Hilfe der getCapabilities-Methode werden, genauso wie bei einem Web Map Service die Fähigkeiten des
Web Feature Service beschrieben. Unter anderem sind in dem Antwortdokument die Version, der Titel
und die Beschreibung des Dienstes, sowie eine Liste der unterstützten Methoden, Nutzungsgebühren
und Antwortformate zu finden. Im Folgenden werden die weiteren Operationen inklusive der benötigten
Parameter näher betrachtet.
describeFeatureType-Methode
Mittels der describeFeatureType-Methode erfolgt eine Anfrage auf die FeatureTypes des Servers. Als
Antwort wird eine nähere Beschreibung der vorhandenen FeatureTypes in Form eines XML Dokuments
mit einem GML Schema zurück an den Client geliefert. In Tabelle 2.3 sind alle benötigten Parameter
aufgeührt.
Request Parameter Beschreibung Mand./Opt.
VERSION=version WFS Versionsnummer M
REQUEST=describeFeatureType WFS Schnittstellenname M
TYPENAME= Liste der Features, die beschreiben M
werden sollen
Tabelle 2.3: Parameter der describeFeatureType Operation
getFeature-Methode
Die konkrete Abfrage auf ein oder mehrere spezielle Features erfolgt mit der getFeatureMethode. Der
Aufruf setzt sich aus einem oder mehreren QUERY-Elementen zusammen. In diesen werden die ge-
wünschten FeatureTypes, die ausgewählten Attribute und gegebenenfalls Auswahlbedingungen, soge-
nannte Filter, aufgeführt. Daraufhin wird dem Client ein GMLDokument zurück geliefert in dem, in
Form einer Collection, die angeforderten Features enthalten sind. In Tabelle 2.4 sind alle benötigten
Parameter für einen getFeature-Request aufgeührt.
getGMLObject-Methode
Die getGMLObject-Methode erlaubt die Abfrage von Features über deren ID, der sogenannten Featu-
reID. Die Anfrage ist ähnlich der oben aufgeführten getFeature-Methode und liefert ebenfalls ein XML
Dokument zurück, welches den Ergebnisdatensatz beinhaltet. Im Gegensatz zu der getFeature-Methode
ist diese Methode optional und kann zusätzlich angeboten werden. Sollte diese Methode implementiert
sein, so ist diese zwingend im Antwortdokument der getCapabilities Anfrage aufzuführen.2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 20
Request Parameter Beschreibung Mand./Opt.
VERSION=version WFS Versionsnummer M
REQUEST=getFeature WFS Schnittstellenname M
OUTPUTFORMAT= Ausgabeformat O
MAXFEATURES= Maximal Anzahl übergebener Featu- O
res
FEATUREVERSION=all [some] Alle Versionen von Eigenschaften ab- O
fragen
TYPENAME= Liste von Features die beschreiben M
werden sollen
SRSNAME= Referenzsystem O
Tabelle 2.4: Parameter der getFeature Operation
lockFeature-Methode
Kommunikation im Web erfolgt im Allgemeinen zustandslos. Dies kann jedoch vor allem bei parallelen
Schreibzugriffen auf einen Geodatensatz zu unerwarteten Problemen führen. Angenommen ein Client
ruft ein Feature ab und verändert dieses um es anschließend wieder in die Datenbasis zu übertragen. Die
Serialisierbarkeit geht verloren, wenn keine Möglichkeiten vorhanden sind, ein gleichzeitiges Verändern
desselben Datensatzes durch einen anderen Benutzer zu verhindern. Eine Möglichkeit diese Problematik
zu lösen ist die temporäre Sperrung ausgewählter Feature für andere Benutzer. Solange diese Sperre be-
steht ist einem anderen Benutzer ausschließlich lesender Zugriff erlaubt. Dies erfolgt analog zu Sperren
wie sie bereits in Datenbanksystemen oder Betriebssystemen angewandt werden. Eine realisierte Lösung
des Problems des parallelen Zugriffs auf Daten existiert in der Erweiterung des Web Feature Service, der
sogenannte Transactional WFS. Mit Hilfe der lockFeature-Methode werden Sperren auf aktuell verwen-
dete Daten gelegt. Dies erfolgt mit einer sogenannten „Langzeit-Feature-Sperre“ um die Konsistenz der
Daten beziehungsweise Dokumente zu erreichen. Netzwerkprobleme und Netzwerkwartezeiten erzwin-
gen in diesem Kontext eine längere Vorlaufzeit für Sperren als im Bereich der kommerziellen Datenbank-
systeme. Die Anfrage zur Sperrung einzelner Features erfolgt über eine Auswahl der IDs der Elemente
und enthält als Antwort ein XML-Dokument der verwendeten Lock-IDs, sowie optional eine Liste mit
den gesperrten FeatureIDs. Da die lockFeature-Methode optional ist, wird im Fall der Verwendung ein
entsprechender Vermerk im Capabilities-Dokument hinterlegt. In der Tabelle 2.5 ist die Parameterliste
des lockFeature-Requests abgelegt.
Ein Server kann zeitgleich mehr als nur einen Lock auf den von ihm verwalteten Daten haben. Jeder
dieser Locks ist unabhängig von den anderen. Im Zustandübergangsdiagramm (Abbildung 2.4 ist ein2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 21
Request Parameter Beschreibung Mand./Opt.
VERSION=version WFS Versionsnummer M
REQUEST=lockFeature WFS Schnittstellenname M
TYPENAME Liste von Features die gesperrt werden M
soll
EXPIRY Maximaldauer der Sperrung O
FILTER= Filter in XML O
LOCKACTION=all[some] Sperrung für alle oder ausgewählte O
Features
Tabelle 2.5: Parameterliste des lockFeature Requests
Aufruf eines Transaction Web Feature Service, unter der Annahme dass eine Transaktion von einem
Request ausgelöst wurde, aufgezeigt. Die fehlerfreie Ausführung dieses Requests führt zum Setzen der
entsprechenden Sperre, die bis zum Abschluss der Transaktion aufrechterhalten wird. Sobald der Über-
tragungsprozess abgeschlossen, oder der vorgegebene Zeitpunkt der Beendigung erreicht ist, wird die
Sperre aufgehoben und der WFS Lock ist terminiert. Sollten hingegen Fehler oder Ausnahmen auftreten
so führen diese, wie die nachfolgende Abbildung beschreibt, ebenfalls zu einer Beendigung der Sper-
rung.
In Abbildung 2.4 ist bereits ein Verweis auf die “transaction”-Methode gegeben, welche für die eigentli-
che Transaktion zuständig ist. Diese wird im folgenden Abschnitt näher beschrieben wird.
transaction-Methode
Mit Hilfe der transaction-Methode werden vom Client die neuen, veränderten, oder zu löschenden Fea-
tures an den Server übermittelt. Der Anfrage kann eine Referenz auf die im vorigen Schritt mit Hilfe
der lockFeature-Methode erzeugten SperrID beigefügt werden. Mit deren Hilfe ist ein direkter Bezug
auf die zu ändernden Elemente hergestellt. Auf diesen Datensätzen sind nach erfolgreicher Sperrung die
Operationen Insert, Update und Delete anwendbar. Dabei ist es möglich, dass der Web Feature Service
die Anfrage in die Anfragesprache der angebundenen Datenbasis übersetzt um die Anfrage auszuführen.
Nach der Beendigung der datenmanipulierenden Transaktion erzeugt der Server ein XML Antwortdoku-
ment, welches einen Bericht über die erfolgte Übertragung beinhaltet.2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 22
Abbildung 2.4: Zustandsdiagramm einer Sperrung, entnommen aus [Ope05b]2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 23 2.5 Web Coverage Service Während der im vorherigen Abschnitt beschriebene Web Feature Service für die Bereitstellung und den Zugriff auf Vektordaten genutzt wird, stellt der im Folgenden beschriebene Web Coverage Service (WCS) [Ope08b] Methoden bereit, die das Abrufen und Operieren auf großen, multidimensionalen Ra- sterdtaensätzen ermöglicht. Im Gegensatz zu einem Web Map Service, der zwar auch Rasterdaten zur Verfügung stellt um daraus statische Karten zu erzeugen, kann mit Hilfe des Web Coverage Service eine detaillierte Beschreibung der zugrundeliegenden Datenbasis zurück gegeben und ebenso komplexe An- fragen auf diesen Daten durchgeführt werden. Der WCS stellt neben der reinen Visualisierung der Daten auch Methoden zur Interpretation und Untersuchung der Daten zur Verfügung. Im Folgenden werden die einzelnen, zur Verfügung gestellten Methoden eines Web Coverage Service näher vorgestellt. 2.5.1 Schnittstellen des Web Coverage Service Wie alle Open Geospatial Consortium Web Services unterstützt auch dieser die Operation getCapabili- ties. In Analogie zu sämtlichen OGC Web Services werden damit Metadaten in Form eines XML Do- kuments an den Client zurückgeschickt. Von der inhaltlichen Seite unterscheidet sich dieses Dokument nicht wesentlich von den anderen Diensten. Allerdings werden in ihm rasterdatenbezogene Informatio- nen, wie zum Beispiel das Format der Daten, die räumliche Ausdehnung oder das unterstützte Referenz- system, transportiert. Um eine genauere Beschreibung eines gewünschten Rasterdatensatzes zu erhalten ist die Methode describeCoverage vorhanden. describeCoverage-Methode In den meisten Fällen benötigt der Client vor der Formulierung einer Abfrage auf den Rasterdaten eine genauere Beschreibung der angebotenen Daten. Diese Informationen können mit Hilfe der describeCo- verage-Operation vom Client abgefragt werden. Der Server liefert eine vollständige Beschreibung in Form eines XML Dokuments in dem genaue Angaben über die Beschaffenheit des Rasters angegeben sind. Eine zwingende Vorraussetzung für solch ein Beschreibungsdokument ist die Anfrage mittels ein- deutiger Identifizierer über die Informationen geliefert werden sollen. In der Tabelle 2.6 ist eine Übersicht der vorhandenen Aufrufparameter enthalten. getCoverage-Methode Die direkte Abfrage eines Datensatzes erfolgt mit der getCoverage-Operation. Vorteile dieser datenba- sierten direkten Abfrage sind beispielsweise die direkte Eingliederungsmöglichkeit der Ergebnisdaten in
2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 24
Request Parameter Beschreibung Mand./Opt.
VERSION=version WCS Versionsnummer M
REQUEST=describeCoverage WCS Schnittstellenname M
IDENTIFIER=[...] CoverageID von denen Informationen M
geholt werden sollen
Tabelle 2.6: Parameter des describeCoverage Request
weitere Berechnungen, da im Gegensatz zum WMS georeferenzierte Bilddaten bereitgestellt werden. In
der Tabelle 2.7 sind die zu verwendeten Anfrageparameter näher beschrieben.
Request Parameter Beschreibung Mand./Opt.
VERSION=version WCS Versionsnummer M
REQUEST=getCoverage WCS Schnittstellenname M
DENTIFIER=[...] CoverageID, die abgefragt werden sol- M
len
DOMAINSUBSET=domain Domain der Raster M
RANGESUBSET=range Definiert die Reihe der Raster O
OUTPUT=output Definiert Ausgabe M
Tabelle 2.7: Parameter des getCoverage Request
Die drei letztgenannten Parameter sind selbst wiederum eigene Datentypen. Die DomainSubset setzt sich
aus einer Boundingbox, die den zu betrachtenden Bereich eines Kartenausschnitts markiert, und einer op-
tional abzufragenden Zeitreihe zusammen. Über den Output Parameter werden die Einstellungen für die
auszugebende Datei definiert. Dort ist hinterlegt in welchem Referenzsystem und welchem Format die
Ausgabe erscheinen und ob diese lokal oder in einem per Netzwerk zugänglichem Ablageort gespei-
chert werden soll. Wie bereits oben schon erwähnt ist es weiterhin möglich direkte Berechnungen und
Analysen auf den Daten des WCS auszuführen. Hierfür wird die Eigenschaft des RangeSubset genutzt,
anhand dessen es möglich ist, nur bestimmte datentechnische Ausschnitte zu betrachten. Exemplarisch
kann bei einem mehrschichtigem Rasterdatensatz eine oder mehrere Ebenen zur Ansicht gewählt wer-
den. Bei erfolgreicher Abfrage erhält der Client die Daten im selbstgewählten Format. Im Falle eines
Fehlers während der Ausführung der Anfrage existieren diverse Exceptions, die dem Client anstelle der
Daten geliefert werden. Gründe für fehlerhafte Anfragen sind falsche oder fehlende Parameter, ungül-
tige Kombinationen des Ausgabeformats bzw. des Referenzsystems oder ein Mangel an zur Verfügung
stehendem Speicherplatz. In Abbildung 2.5 ist eine das UML-Diagramm zu einem getCoverage-Request
dargestellt.2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 25
WCSRequestBase
+service : String
+request : String
+version : String
1
GetCoverage Output
+request : String = "GetCoverage" +store : Boolean
1
1 +identifier : String +format : String
1 1
0..1
1 0..1
RangeSubset DomainSubset 1 GridCRS
1
0..1
1
BoundingBox TimeSequence
+lowerCorner : Number
+upperCorner : Number
+crs : URI
+dimensions : Integer
Abbildung 2.5: GetCoverage Anfrage als UML Klassendiagramm2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 26 2.6 Web Processing Service Mit den bisher vorgestellten Diensten ist es möglich Geodaten zu visualisieren und sich zur weiteren Verarbeitung von einem Server zu schicken zu lassen beziehungsweise die Daten direkt auf den entfern- ten Speicherorten zu verändern oder anzupassen. Die Umsetzung der vollständigen Funktionalität eines Geoinformationssystems erfordert allerdings auch die Analyse der Daten um diese für die weiteren Be- rechnungen nutzbar zu gestalten und Informationen aus den Daten zu generieren. Hierfür wurde vom Open Geospatial Consortium der Standard des Web Processing Service (WPS) [Ope07c] entwickelt. Ein WPS spezifiziert wie auf Geoprozessierungsfunktionalit ät zugegriffen werden kann, aber nicht welche Funktionalit ät zur Verf ügung gestellt werden müssen. Anhand dieses Dienstes ist es möglich die von den Anbietern bereitge- stellten Geoprozesse über eine einheitliche Schnittstelle zu nutzen. Als Modell eines Geoprozesses wird dabei ein solcher Prozess bezeichnet, der räumliche Daten verarbeitet. Diese Geoprozessierungsdien- ste sind in vier verschiedene Arten von Diensttypen unterscheidbar. Unter dem Begriff des räumlichen Dienstes werden alle Dienste zusammengefasst, bei denen räumliche Attribute der Geodaten, zum Bei- spiel in Form von Koordinatentransformationen oder Generalisierungen, verändert werden. Als zweite Klassifizierung existieren die zeitlichen Dienste bei denen die temporale Veränderung der Geodaten, wie zum Beispiel bei der Auswertung von Sensordaten erforderlich, im Vordergrund steht. Die dritte Gruppe der WPS bilden die thematischen Dienste. Hierbei werden alle Dienste vereinigt, bei denen fachliche Daten verändert oder herangezogen werden, wie etwa bei der Analyse eines Messnetzes zu einem fe- sten Zeitpunkt. Die letzte Kategorie ist die der Metadatendienste. In ihr werden alle Dienste eingeordnet, bei denen hauptsächlich statistische Kenngrößen genutzt werden, um mathematische Berechnungen wie beispielsweise für den Mittelwert oder die Standardabweichung vorzunehmen. 2.6.1 Schnittstellen des Web Processing Service Ein Web Processing Service muss zwingend drei Methoden zur Verfügung stellen die im Folgenden nä- her betrachtet werden. Mandatorisch ist die getCapabilities-Methode, die alle OGC-konformen Dienste bereitstellen müssen. Diese Methode liefert Metadaten über den angebotenen Dienst, sowie die zu nut- zenden Methoden. Außerdem werden die Prozessierungsfunktionalitäten als Liste mit den Namen der Prozesse sowie einer kurzen Beschreibung wiedergegeben. describeProcess-Methode Eine genauere Beschreibung eines bestimmten Prozesses liefert die describeProcess-Operation. In dem
2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 27
daraufhin zurück gelieferten XML-Dokument werden die benötigten Eingabeparameter inklusive derer
Formate und die zu erwartenden Ausgabeparameter mit wiederum deren Formaten aufgezeigt. Die Ein-
und Ausgabeparameter können für die Berechnung des WPS sowohl zwingend erforderlich als auch
optional gesetzt bzw. in ihrer Anzahl beschränkt werden. Dabei ist deren Form durch eine der drei fol-
genden Datenstrukturen geprägt. Als ComplexData wird eine komplexe Datenstruktur wie zum Beispiel
eine Binärdatei oder ein GML Dokument bezeichnet. Der Datentyp ComplexData besteht aus einem Me-
tadaten Triple, in dem Angaben zum Format (MIME Type), zur Enkodierung und bei GML zum Schema
enthalten sind. Die beiden letztgenannten sind optional zu füllen. Der zweite Datentyp ist das Literal-
Data. Mithilfe dieses Typs werden die Parameter, die in Form von primitiven Datentypen vorliegen,
angegeben. Diese enthaltenen primitiven Typen können wiederum auf bestimmte Werte oder Wertebe-
reiche beschränkt werden. Der letzte Parametertypus wird BoundingBoxData genannt und beschreibt
eine BoundingBox, die einem räumlichen Bezugssystem zugrunde liegen muss. Die Parameter eines
describeProcess Aufrufes werden in der Tabelle 2.8 erläutert.
Request Parameter Beschreibung Mand./Opt.
VERSION=version WPS Versionsnummer M
REQUEST=describeProcess WPS Schnittstellenname M
IDENTIFIER=[...] ProcessID, die abgefragt werden sol- M
len
LANGUAGE=de[...] Sprache der Beschreibung O
Tabelle 2.8: Parameter des describeProcess Requests
execute-Methode
Erfolgte eine genauere Beschreibung eines bestimmten Prozesses inklusive der benötigten Eingabepara-
meter ist es dem Client nun möglich die execute-Operation zu nutzen um einen Prozess zu starten. Die
erforderlichen Parameter werden entweder direkt in den Request, mittels Key/Value-Paaren, eingetragen
oder darin referenziert. Die Antwort kann ebenfalls direkt in das Ausgabe XML Dokument geschrieben
oder in Form von Rohdaten zurückgeliefert werden. Bei beiden Verfahren hat der Client die Möglich-
keit selbst zu entscheiden, ob die Daten zusätzlich auf dem Server gespeichert werden sollen oder nicht.
Entscheidet sich der Client für eine Speicherung erhält dieser eine URL unter der die Daten und der
aktuelle Status des Prozesses abgefragt werden kann. Da eine Prozessierung mitunter sehr zeitaufwendig
ist, wird mittels dieser Möglichkeit einem Time Out auf der Seite des Clients vorgebeugt. Die Parameter
eines execute-Requests werden in Tabelle 2.9 aufgelistet.
Im Allgemeinen verläuft eine Nutzung eines Web Processing Service nach dem nachfolgenden Schema2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 28
Request Parameter Beschreibung Mand./Opt.
VERSION=version WPS Versionsnummer M
REQUEST=execute WPS Schnittstellenname M
IDENTIFIER=[...] ProcessID, die genutzt werden soll M
LANGUAGE=de[...] Sprache der Beschreibung O
DATAINPUTS=[...] Liste an Inputs für den Prozess O
RESPONSEFORM=form Ausgabe XML oder Rohdaten O
Tabelle 2.9: Parameter eines execute Aufrufes
ab. Der Client schickt eine getCapabilities Anfrage an einen WPS und erhält daraufhin ein Capabi-
lities Dokument mit den zur Verfügung stehenden Prozessen. Im Anschluss erfolgt eine Abfrage der
genaueren Erläuterung eines Prozesses mittels der describeProcess-Operation auf einem oder mehreren
bestimmten Prozessen. Als Ergebnis erhält der Client eine genauere Beschreibung inklusive der Aufli-
stung der zwingend benötigenden Eingabeparameter. Diese werden dem Dienst anschließend mit Hilfe
der execute-Methode übergeben und resultieren in einem GML Dokument mit dem gewünschten Aus-
führungsergebnis. In Abbildung 2.6 ist ein beispielhafter Ablauf einer WPS-Kommunikation anhand
eines Sequenzdiagramms verdeutlicht.
Client Web Processing Service
1: GetCapabilities
Service=wps
2: Capabilities
intersection
buffer
3: DescribeProcess
identifier=buffer
4: DescribeProcess Document buffer
layer?
bufferdistanz?
5: Execute
identifier=buffer
layer=http://...
bufferdistance=100
6: GML
Abbildung 2.6: Sequenzdiagramm eines WPS2. OPEN GEOSPATIAL CONSORTIUM WEB SERVICES 29
2.7 Verkettung von OGC Web Services
In einer typischen Geoinformationssystem-Anwendung ist ein häufiger Bestandteil das Kombinieren und
Verketten von GIS und nicht-GIS Web Services. Hierfür existieren verschiedene Herangehensweisen die
ALAMEH [Ala03] in ihrem Paper näher erläutert. Die Grundfragen die dabei eine Rolle spielen sind
unter anderem die Transparenz, das Verfolgen der Daten und die Fehlerberichte. Unter Transparenz ist
zu verstehen wieviel der Client von der Komplexität der Verkettung sehen soll und wieviel Einfluß er
nehmen darf auf das Kreieren, Ausführen und Verwalten der Diensteverkettungen. Da es in Geoinforma-
tionssystemen wichtig ist auf Basis welcher geographischer Daten operiert wird, muss die Information
über deren Metadaten entlang der Verkettung immer mitgeführt werden. Diese Metadaten beinhalten bei-
spielsweise das verwendete Koordinatenrefernenzsystem oder die Auflösung der Daten. Sollten während
der Ausführung eines Prozesses Fehler bei der Übertragung oder Berechnung auftreten, so müssen Feh-
lerberichte erstellt, die folgenden Dienste der Kette darauf entsprechend reagieren und auch dem Client
einen Hinweis geliefert werden.
Im einfachsten Fall der Verkettung ist diese für den Client komplett transparent. In dieser Client-koordi-
nierten Diensteverkettung kontrolliert und definiert der Client vollständig die Reihenfolge des Ablaufs
der Verkettung. Dafür muss der Client allerdings bereits vorher Kenntnisse über die verwendeten Dienste
haben. Darüber welche Eingabeparameter benötigt werden und wie die darauf folgenden Ausgabewerte
zu nutzen sind. In Abbildung 2.7 ist eine solche Client-koordinierte Verkettung der Dienste dargestellt.
Catalog
Client
Service
Reprojection Web Mapping Address-matching
Service Service Service
(a)
Catalog
Client
Service
Reprojection Web Mapping Address-matching
Service Service Service
(b)
Abbildung 2.7: Client-koordinierte Diensteverkettung, entnommen aus [Ala03]
Im Teil (a) kann der Client alle benötigten Dienste direkt kontaktieren. Im Teil (b) kann der Client Aufru-
fe innerhalb der Dienste-Kette auch verschachteln, um sie undurchsichtiger zu machen. Der Client kann
damit den Output eines Dienstes zum direkten Input eines anderen Dienstes machen. Allerdings verber-
gen sich dahinter auch Probleme die einem Domino-Effekt ähneln. Entstehen Fehler bei der AusführungSie können auch lesen
