Architekturkonzept - Geodateninfrastruktur

Transcrição

Referenzmodell der
Geodateninfrastruktur
Sachsen
Architekturkonzept
Version: 1.0
Stand: 23.07.2009
gdi.initiative.sachsen
Projektgruppe/Teilprojekt:
Arbeitskreis Referenzmodell
Expertengruppe Architekturkonzept
Version
1.0
verantwortlich
Prof. Dr. F.
Schwarzbach
Beginn QS-Verfahren:
Telefonnummer 0351 / 462 - 3149
[email protected]
Email
09.04.2009
Datum Freigabe:
Mitglieder Expertengruppe
Bereich
Name
LfULG
Astrid Ment
IDU mbH
Dr. Dietmar Bothmer
Landkreis Görlitz
Sven Hölzel
GeoSN
Alexander Horn
HTW Dresden
André Müller
Landeshauptstadt Dresden
Andreas Schmidt
SAKD
Klaus Sandmann
HTW Dresden
Prof. Dr. Frank Schwarzbach
SMI
Jörg Taggeselle
conterra GmbH
Christoph Uhlenküken
Weitere Beteiligte
Bereich
Name
TU Dresden
Prof. Dr. Lars Bernard
TU Dresden
Johannes Brauner
ehem. KoBIT
Peter Schmädicke
Dokumentenhistorie
Bemerkung
Einarbeitung Ergebnisse öffentliches Re23.07.2009
view
09.04.2009 Vorlage für öffentliches Review
Version
bearbeitet von Datum
1.0
Sb/Mue
1.0 Entw. Expertengr.
Architekturkonzept GDI Sachsen, Version 1.0
Seite 2 von 96
Inhaltsverzeichnis
1 1.1 1.2 2 3 4 4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.4 4.4.1 4.4.2 4.4.3 5 5.1 5.1.1 5.1.1.1 5.1.1.2 5.1.1.3 5.1.1.4 5.1.1.5 5.1.1.6 5.1.2 5.1.2.1 5.1.2.2 5.1.2.3 5.1.2.4 5.1.2.5 5.1.2.6 5.1.2.7 5.1.3 5.1.3.1 5.1.3.2 5.1.3.3 5.1.3.4 5.1.3.4.1 5.1.3.4.2 Einordnung des Architekturkonzepts ...................................................... 5 Einordnung in die GDI Sachsen ............................................................. 5 Einordnung in die GDI-DE sowie INSPIRE............................................. 6 Grundsätze, Methodik und Aufbau des Architekturkonzepts .................. 7 Referenzen........................................................................................... 10 Fachliche Sicht ..................................................................................... 11 Ist- und Bedarfsanalyse........................................................................ 11 Komponenten der GDI Sachsen........................................................... 12 Nutzungswege...................................................................................... 15 Bedienung sächsischer Anwendungen und übergeordneter GDI durch
dezentrale Geodatendienste ................................................................ 15 Zugang zur sächsischen Geodateninfrastruktur über ein zentrales GDI
Sachsen-Portal ..................................................................................... 16 Integration von zentral bereitgestellten Komponenten in sächsische
Anwendungen und Geoportale ............................................................. 16 Verwendung zentraler Dienste der GDI Sachsen ................................. 17 Benutzung von zentral zur Verfügung gestellten Serverkomponenten . 18 Weitere Anforderungen ........................................................................ 18 Dienstequalität ...................................................................................... 18 Orchestrierung ...................................................................................... 18 Absicherung von Geodatendiensten ..................................................... 19 Funktionale Sicht .................................................................................. 20 Strukturelle Sicht .................................................................................. 20 Anwendungsschicht .............................................................................. 21 INSPIRE/GDI-DE.................................................................................. 21 Sächsische und weitere Anwendungen/Portale ................................... 21 Sachsenatlas ........................................................................................ 21 GDI Sachsen-Portal.............................................................................. 22 Registry Clients .................................................................................... 24 Administration....................................................................................... 25 Anwendungs- und GeoDRM-Komponenten (durch GDI Sachsen
bereitgestellt) ........................................................................................ 25 Karten-Client ........................................................................................ 26 Recherche-Client.................................................................................. 26 Location Finder Client........................................................................... 27 Order Client .......................................................................................... 28 Koordinatentransformations-Client ....................................................... 28 GeoDRM Client .................................................................................... 28 Protokoll-Wandlung .............................................................................. 28 Diensteschicht....................................................................................... 28 Dezentrale Geodatendienste................................................................ 31 Externe Dienste .................................................................................... 37 Externe Registry Services .................................................................... 38 Zentrale Dienste ................................................................................... 38 Darstellungs- und Downloaddienste ..................................................... 39 Transformationsdienste ........................................................................ 44 Architekturkonzept GDI Sachsen, Version 1.0
Seite 3 von 96
5.1.3.4.3 5.1.3.4.4 5.1.3.4.5 5.1.3.4.6 5.1.3.5 5.1.3.5.1 5.1.3.5.2 5.1.3.5.3 5.1.3.5.4 5.1.4 5.1.5 5.1.5.1 5.1.5.1.1 5.1.5.1.2 5.1.5.1.3 5.1.5.1.4 5.1.5.2 5.1.5.3 5.1.5.3.1 5.1.5.3.2 5.1.5.3.3 5.1.6 5.1.6.1 5.1.6.2 5.1.6.3 5.1.6.4 5.1.6.5 5.1.6.6 5.1.6.7 5.1.6.8 5.1.6.9 5.1.6.10 5.1.6.11 5.2 5.2.1 5.2.2 5.2.3 5.2.4 6 7 8 9 10 Dienste zum Abrufen von Geodatendiensten ....................................... 47 Weitere Dienste .................................................................................... 48 Registry Services.................................................................................. 52 GeoDRM Services................................................................................ 54 Service Management nach ITIL............................................................ 54 IT Infrastructure Library (ITIL)............................................................... 54 Zentrale Dienste der GDI Sachsen....................................................... 55 Dezentrale Geodatendienste................................................................ 55 Monitoring und Reporting ..................................................................... 55 Serverkomponenten (durch GDI Sachsen bereitgestellt)...................... 58 Datenschicht ......................................................................................... 60 Sächsische INSPIRE- und andere Ressourcen (Originaldaten) ........... 60 Metadaten ............................................................................................ 60 Geodaten.............................................................................................. 60 Produktbeschreibungen und Preismodelle ........................................... 61 Nutzerdaten .......................................................................................... 61 Sächsische INSPIRE- und andere Ressourcen (Kopien) ..................... 61 Externe und GDI Sachsen Registries ................................................... 61 Registries und Repositories.................................................................. 61 Nutzer, Lizenzen, Rechte ..................................................................... 62 Zentrales Diensteverzeichnis ............................................................... 63 GeoDRM Layer und -Komponenten...................................................... 64 Überblick über die Komponenten ......................................................... 65 GeoDRM Client .................................................................................... 67 Identity Repository Client...................................................................... 67 Authentication Service.......................................................................... 68 Dezentrale Identy Repositories ............................................................ 69 Zentrales Identity Repository................................................................ 69 Authorization Service............................................................................ 70 License Broker Service......................................................................... 70 Licence Manager Service / Zentrales Policy Repository....................... 71 Gatekeeper Service.............................................................................. 72 Verteilung der GeoDRM-Komponenten................................................ 72 Dynamische Sicht (Auswahl) ................................................................ 74 Anwendungsfall „Bedienung INSPIRE Request“................................... 75 Anwendungsfall „Orchestrierung von Diensten“.................................... 76 Anwendungsfall „Eintragung eines Benutzers am zentralen Identity
Repository“ ........................................................................................... 77 Anwendungsfall „Zugriff auf geschützten Dienst“.................................. 78 Abkürzungsverzeichnis......................................................................... 80 Glossar Architekturkonzept .................................................................. 82 Vorschläge für ein zentrales Glossar.................................................... 85 Quellenverzeichnis ............................................................................... 88 Anlagen ................................................................................................ 91 Architekturkonzept GDI Sachsen, Version 1.0
Seite 4 von 96
1 Einordnung des Architekturkonzepts
1.1 Einordnung in die GDI Sachsen
Der Auftrag, ein Architekturkonzept der GDI Sachsen zu entwickeln, geht auf die
Maßnahmen M 10 bis M 17 des Aufgabenkatalogs der Strategischen Leitlinien zum
Gemeinsamen Aufbau einer Geodateninfrastruktur im Freistaat Sachsen
(Strategische Leitlinien der gdi.initiative.sachsen [1]) zurück. Aus den in den Strategischen Leitlinien genannten Maßnahmen folgt die Notwendigkeit des Entwurfs und
der Implementierung einer IT-Landschaft, mit der die sächsischen GI-Ressourcen
(Geodaten, Geodatendienste, Metadaten) für GI-Anwendungen in Sachsen und darüber hinaus verfügbar gemacht werden. Das Zusammenwirken der technischen, organisatorischen und politischen Zusammenhänge in der GDI Sachsen soll in einem
Referenzmodell dargestellt und beschrieben werden. Das vorliegende Architekturkonzept ist Bestandteil des Referenzmodells der GDI Sachsen und „... beschreibt die
zur Implementierung des Referenzmodells erforderliche IT-Architektur entsprechend
dem aktuellen Stand von Wissenschaft und Technik. Insofern klammert das Architekturkonzept fachpolitische Fragen wie die Durchsetzbarkeit oder Finanzierung dieses
Konzepts aus und fokussiert auf (fach-)technische Aspekte.“ [2]
Abbildung 1: Einordnung des Architekturkonzepts im Referenzmodell der GDI Sachsen [2]
Das Architekturkonzept berücksichtigt, dass in den letzten Jahren in Sachsen bereits
eine dienstebasierte GDI-Landschaft entstanden ist. Hervorzuheben ist die im Rahmen der E-Government-Aktivitäten des Freistaates Sachsen entstandene Basiskomponente Geodaten (GeoBAK).
Die Sächsische Staatsregierung beabsichtigt, durch Gesetz den rechtlichen Rahmen
für den Betrieb der GDI Sachsen zu schaffen. Vor diesem Hintergrund hat das Architekturkonzept grundsätzlich den Charakter einer Empfehlung. Im Hinblick auf den
Ausbau und den Betrieb der GDI Sachsen stellt es den Akteuren eine Richtlinie für
die Implementierung der erforderlichen IT-Komponenten im jeweiligen Zuständigkeitsbereich zur Verfügung. Das Sächsische Staatsministerium des Innern als das im
Rahmen der GDI Sachsen federführende Ressort beabsichtigt, im Rahmen seiner
Vorschriftenkompetenz auf Teile des Architekturkonzepts zu referenzieren, so dass
diese Teile Bestandteil der Umsetzung des geplanten Sächsischen Geodateninfrastrukturgesetzes [3] werden. Insofern sollte das Architekturkonzept insbesondere im
Rahmen von Ausschreibungen von GDI-relevanten IT-Komponenten berücksichtigt
werden.
Seite 5 von 96
1.2 Einordnung in die GDI-DE sowie INSPIRE
Im Architekturkonzept GDI-DE [4] wird ein Konzept für den Zugriff auf die dezentral
verteilten Geodaten und Geodatendienste in der Bundesrepublik Deutschland im
Rahmen der Geodateninfrastruktur Deutschland (GDI-DE) beschrieben. Das Architekturkonzept GDI-DE definiert die wichtigsten Regeln, um die Interoperabilität der
die GDI-DE konstituierenden Komponenten sicherzustellen und definiert konkrete
Realisierungsschritte zur Umsetzung der GDI-DE in eine operationell verfügbare,
länderübergreifende Geodateninfrastruktur in einem Masterplan. Die GDI Sachsen
versteht sich als elementarer Bestandteil der GDI-DE. Das vorliegende Architekturkonzept berücksichtigt daher die technischen Anforderungen der Architektur der GDIDE.
Der rechtliche Rahmen der GDI Sachsen wird im Wesentlichen durch die am 15. Mai
2007 in Kraft getretene Richtlinie 2007/2/EG des Europäischen Parlaments und des
Rates zur Schaffung einer Geodateninfrastruktur in der Europäischen Gemeinschaft
(INSPIRE) bestimmt. Die europäische Geodateninfrastruktur soll sich dabei auf die
von den Mitgliedsstaaten geschaffenen Geodateninfrastrukturen stützen, die anhand
gemeinsamer fachlich-inhaltlicher und technischer Festlegungen interoperabel gemacht werden. Aufgrund dieser Konstellation kommt den Anforderungen, die in den
Durchführungsbestimmungen zu INSPIRE festgelegt sind, eine hervorgehobene Bedeutung zu.
Es sei jedoch explizit darauf hingewiesen, dass dieses Konzept nicht ausschließlich
die INSPIRE-Anforderungen abbildet, sondern die weitere Entwicklung des
sächsischen Geoinformationswesens in seiner Gesamtheit unterstützen soll.
Seite 6 von 96
2 Grundsätze, Methodik und Aufbau des Architekturkonzepts
Der hier betrachtete technische Aspekt der sächsischen Geodateninfrastruktur kann
nur nach dem Muster einer Service-orientierten Architektur (SOA) entworfen werden.
Die wichtigsten Gründe für diese Entwurfsentscheidung sind neben dem allgemeinen
IT-Paradigmenwechsel hin zu SOA die räumliche und administrative Verteilung der
GI-Ressourcen, übergeordnete Anforderungen an die sächsische Geodateninfrastruktur (Bereitstellung von Diensten für INSPIRE und GDI-DE) sowie die Existenz
bestehender Dienste und zugehöriger Clients. Der Schwerpunkt dieses Konzepts
liegt somit in der Definition von Diensten (Services) 1 , 2 und deren Schnittstellen
(interfaces). Um die Ziele der GDI Sachsen zu erreichen, sollen die Dienste interoperabel sein und daher auf Normen und Standards basieren.
Durch das vorliegende Architekturkonzept werden existierende Anwendungen und
Geoportale nicht reglementiert. Ebenso wenig enthält dieses Konzept Vorgaben zu
den dezentralen 3 Geodatendiensten. Hier wird lediglich erwartet, dass diese Dienste
die eingeführten OGC interfaces unterstützen. Die Spezialisierung der Schnittstellen
durch Profile (i. d. R. basierend auf Profilen übergeordneter GDI) wäre aus Sicht der
Benutzung der Dienste zwar wünschenswert, vom Standpunkt der hier vorgeschlagenen Architektur jedoch nicht zwingend erforderlich.
Auf Grundlage der entsprechenden Prinzipien und Vereinbarungen der
gdi.initiative.sachsen hat das vorliegende Konzept den Anspruch, die Architektur
firmenunabhängig zu beschreiben. Dies wird vor allem dadurch erreicht, dass allgemein anerkannte Normen und Standards verwendet werden. Allerdings sind die benötigten Implementierungsspezifikationen nicht in allen Bereichen verabschiedet, so
dass notgedrungen auf Konzepte (z. B. OGC discussion papers) zurückgegriffen
werden muss, die in einem stärkeren Maße die Sicht einzelner Unternehmen bzw.
deren Produkte widerspiegeln.
Bei der Entwicklung des Architekturkonzepts der GDI Sachsen diente das „Reference Model of Open Distributed Processing (RM-ODP)“ [11] als Grundlage. Von den im
RM-ODP definierten Sichten auf den Gegenstand eines Informationssystems sind im
Rahmen des Konzeptes vorrangig die fachliche („Enterprise Viewpoint“) und funktio-
1
In diesem Dokument sind die Begriffe „Dienst“ und „Service“ Synonyme. Deren konkrete Verwendung richtet sich nach dem jeweiligen sprachlichen Kontext (z. B. „Fachdienst“, „Service Management“). Gleiches gilt für „Schnittstelle“ und „interface“.
2
Dabei darf der Begriff des „Dienstes“ nicht auf OGC Web Services reduziert werden, sondern bezeichnet allgemein eine (i. d. R. Software-)Komponente, die unter vereinbarten Bedingungen eine
definierte Funktionalität über Schnittstellen zur Verfügung stellt. Daten und Abläufe hinter dieser
Schnittstelle sind grundsätzlich nicht definiert und bleiben der Komponente, die den Dienst nutzt, verborgen („black box“).
3
Die Begriffe „zentral“ bzw. „dezentral“ werden benutzt, um die Zuweisung von Komponenten zu
Schichten der gdi.Sachsen-Architektur zu kennzeichnen und dienen nicht primär als Unterscheidungsmerkmal. Insofern wird beispielsweise von einem „Zentralen Policy Repository“ gesprochen,
obwohl es in diesem Konzept kein „dezentrales“ Gegenstück dazu gibt.
Seite 7 von 96
nale („Computational Viewpoint“) Sicht relevant 4 . Es wird darauf hingewiesen, dass
die Verwendung von RM-ODP zu einer gewissen Redundanz der Darstellung führt,
weil identische Sachverhalte mehrfach aus unterschiedlichen Sichten und in unterschiedlichen Detaillierungsgraden betrachtet werden. Die Fokussierung auf die genannten Sichten führt dazu, dass Gesichtspunkte wie die Integration der geplanten
Komponenten in die bestehende sächsische IT-, insbesondere E-GovernmentLandschaft, z. B. die Benutzung des Sächsischen Verwaltungsnetzes, der
E-Government-Plattform mit dem zentralen CMS und der Basiskomponenten Zahlungsverkehr, nicht betrachtet werden.
Die Beschreibungstiefe dieses Dokumentes entspricht der eines Grobkonzeptes. Eine Feinspezifikation sollte im Zusammenhang mit der Implementierung erfolgen. Zu
beachten ist, dass wesentliche Softwarekomponenten, die in diesem Konzept beschrieben werden, voraussichtlich neu zu implementieren sind. Soweit die fachlichen
[Kapitel 4] und funktionalen Vorgaben [Kapitel 5] umgesetzt werden, sollen bei Entwurfsentscheidungen die bestehenden Freiheiten im Detail nicht eingeengt werden.
Außerdem liegen wichtige Fachspezifikationen [Kapitel 3], die Auswirkungen auf das
Architekturkonzept haben, gegenwärtig nicht abschließend vor. Deren Fortschreibungen sollen in zukünftigen Versionen Berücksichtigung finden.
Auch aus der zukünftigen Erarbeitung der genannten Konzepte der GDI Sachsen
und anderer Rahmenbedingungen (z. B. Verabschiedung des sächsischen Geodateninfrastrukturgesetzes und weiterer INSPIRE-Spezifikationen) folgt die Notwendigkeit, das hier in der Version 1.0 vorliegende Konzept zu versionieren.
Aufgrund der Tatsache, dass zum Zeitpunkt der Veröffentlichung dieses Dokumentes
die in Abbildung 1 genannten begleitenden Konzepte noch nicht vorliegen, muss dieses Architekturkonzept in der Version 1.0 noch Passagen enthalten, die bei strenger
Sichtweise nicht Bestandteil eines Architekturkonzepts sind.
Das Architekturkonzept ist wie folgt aufgebaut:
Kapitel 3
Kapitel 4
4
Es werden die wichtigsten Grundlagen für das Architekturkonzept
(Rechtsgrundlagen, Normen, Standards, Konzepte) genannt. Im Interesse einer möglichst komprimierten Darstellung wird im Rahmen dieses Konzeptes im Wesentlichen auf die Wiedergabe von Inhalten dieser
Dokumente verzichtet.
Dieses Kapitel beschreibt die fachliche Sicht im Sinne des RM-ODP. Es
wird zunächst kurz die Bedeutung einer Analyse der gegenwärtigen Situation (Ist- und Bedarfsanalyse) als wichtige Quelle für dieses (Soll-)
Konzept herausgearbeitet [Abschnitt 4.1]. Anschließend werden unter
4.2 die existierenden und geplanten Schichten der sächsischen Geodateninfrastruktur in stark generalisierter Form eingeführt. Auf dieser
Grundlage werden in 4.3 die wichtigsten Nutzungswege innerhalb der
sächsischen Geodateninfrastruktur beschrieben.
Eine kompakte Darstellung der fünf Sichten des RM-ODP ist beispielsweise in SAGA [5] enthalten.
Seite 8 von 96
Kapitel 5
Dieses Kapitel enthält zunächst unter 5.1 mit der Beschreibung der
strukturellen Sicht (Definition der Komponenten) den Kernabschnitt des
Architekturkonzepts. Darin werden die relevanten Anwendungen, die
zentral bereitgestellten Dienste, Client- und Serverkomponenten sowie
die zugrundeliegende Ressourcenschicht beschrieben. Abschnitt 5.2
(„Dynamische Sicht“) bildet ausgewählte Anwendungsfälle auf diese
Komponenten ab und beschreibt deren Zusammenwirken.
Seite 9 von 96
3 Referenzen
Strategische Ziele
 Strategische Leitlinien der gdi.initiative.sachsen [1]
Rechtsgrundlagen
 Richtlinie 2007/2/EG des Europäischen Parlaments
und des Rates zur Schaffung einer Geodateninfrastruktur in der Europäischen Gemeinschaft (INSPIRE)
 Verordnung (EG) Nr. 1205/2008 der Kommission vom
3. Dezember 2008 zur Durchführung der Richtlinie
2007/2/EG des Europäischen Parlaments und des
Rates hinsichtlich Metadaten (Durchführungsbestimmung Metadaten)
 Durchführungsbestimmung nach Artikel 16 INSPIRE
(Technische Spezifikation und Mindestleistungskriterien für Suchdienste sowie Darstellungsdienste)
 Durchführungsbestimmung nach Artikel 21 Abs. 4
INSPIRE (Überwachung und Berichtswesen)
 Entwurf für eine Verordnung der Kommission zur
Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich Interoperabilität von Datensätzen und Diensten (Durchführungsbestimmung Datenspezifikationen)
 Entwurf für eine Verordnung der Kommission zur
Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich der
Netzdienste (Durchführungsbestimmung Netzdienste)
 Entwurf eines Gesetzes über die Geodateninfrastruktur im Freistaat Sachsen (E-SächsGDIG) [3]
GI-Normen und
-Standards
 ISO 191xx – Serie
 Spezifikationen des OGC
 Technische Richtlinien zu den INSPIREDurchführungsbestimmungen (INSPIRE technical
guidelines)
 Standards und Konzepte der GDI-DE
 Standards und Konzepte der GDI Sachsen
allgemeine IT-Standards  W3C-Standards (z. B. XML)
 OASIS-Standards (z. B. WS-Security, BPEL, ebRIM
[28])
E-Government
 SAGA [5]
 Konzepte zur E-Government-Basiskomponente
„Geodaten“ (GeoBAK) des Freistaates Sachsen [48]
Seite 10 von 96
4 Fachliche Sicht
4.1 Ist- und Bedarfsanalyse
Grundsätzlich sollte die Architektur einer GDI aus den Ergebnissen einer Analyse der
vorhandenen GI-Ressourcen (Ist-Analyse) und deren Bedarf im Rahmen von Geschäftsprozessen und bei der Erzeugung von GI-Produkten abgeleitet werden. Dem
steht jedoch entgegen, dass zum derzeitigen Zeitpunkt


weder ein verlässlicher Überblick darüber vorliegt, an welchen Stellen gegenwärtig Geodaten gespeichert und verarbeitet werden sowie welche GI-Produkte mit
welchen Mitteln bereitgestellt werden,
noch eine Übersicht darüber exisiert, worin der tatsächliche Bedarf an Geodaten
bzw. -informationen besteht.
Diese Situation führt derzeit zu einer gewissen Unschärfe des Konzepts. Zu einem
späteren Zeitpunkt können jedoch die Informationen des landesweiten Metadateninformationsystems (GeoMIS.Sachsen) sowie die Ergebnisse des Projektes „Analyse
des Geodatenbedarfs“ genutzt werden, um diese Situation zu verbessern.
Allerdings lassen sich aus den bislang bekannten Anforderungen aus INSPIRE bereits heute (zunächst allgemeine) Anforderungsfälle ableiten. Als Grundlage hierfür
dienen die in Kapitel 3 der Vorstudie zum Betriebskonzept der GDI Sachsen [9] beschriebenen generellen Geschäftsprozesse:



Eine geodatenhaltende Stelle stellt ihre Geodaten über eigene Geodatendienste
INSPIRE-konform bereit.
Eine geodatenhaltende Stelle macht ihre Geodaten über eigene
Geodatendienste, die jedoch nicht INSPIRE-konform sind, verfügbar. Unter Verwendung zentraler Dienste (insbesondere Transformationsdienste) werden
Diensteketten aufgebaut, die nach außen INSPIRE-konforme Dienste bereitstellen.
Eine geodatenhaltende Stelle stellt ihre Geodaten über die Geodatendienste einer zentralen Stelle bereit.
Seite 11 von 96
4.2 Komponenten der GDI Sachsen
In der Vorstudie zum Betriebskonzept [9] wurde die abstrakte Architektur der GDI
Sachsen dargestellt:
Abbildung 2: Schematische Darstellung der abstrakten Architektur der GDI Sachsen [9]
Sächsische und externe Anwendungen
GDI SachsenAnwendungen
Anwendungs- und Clientkomponenten
(durch GDI Sachsen bereitgestellt)
Anwendungsschicht
In Abbildung 3 werden die in Abbildung 2 gezeigten Elemente in verallgemeinerter
Form dargestellt, um die vorhandenen und die in diesem Konzept entworfenen Komponenten voneinander abzugrenzen.
Vorhandene
(„dezentrale“)
Komponenten
GDI Sachsen-Plattform
Sächsische
INSPIREund
andere
Ressourcen
(Hosting)
Externe
Registry
Services
Externe
und
GDI SachsenRegistries
Datenschicht
Externe
Dienste
Serverkomponenten
(durch GDI Sachsen
bereitgestellt)
Sächsische INSPIRE- und
andere Ressourcen
(Originaldaten)
Diensteschicht
Zentrale Dienste der GDI Sachsen
Dezentrale Geodatendienste
Legende
„zentrale“
Komponenten,
die der Freistaat
Sachsen nach
Maßgabe des
Lizenz- und
Bepreisungsmodells als
staatliche Infrastrukturmaßnahme implementiert und
pflegt
Abbildung 3: Architektur (generalisiert)
Seite 12 von 96
Die Komponenten werden in diesem Abschnitt zunächst grob und in den nachfolgenden Abschnitten detailliert beschrieben:
Serverkomponenten
nste
(durch GDI Sachsen
bereitgestellt)
Die im Freistaat Sachsen betriebenen dezentralen
Geodatendienste werden in unterschiedliche Anwendungen eingebunden, die bezogen auf diese Dienste
die Rolle von Clients innehaben. Es handelt sich dabei i. d. R. entweder um GIS, um Geoportale oder
wiederum um Dienste, die zentrale und dezentrale
Dienste nutzen.
Die GDI Sachsen stellt ausgewählte Komponenten
zur Verfügung, die in die sächsischen Anwendungen
und Portale integriert werden können.
Dieses Konzept sieht keine speziellen Anwendungen
vor. Insofern wird neben den notwendigen Administrations-Clients lediglich eine Webseite im Sinne
eines zentralen Einstiegspunktes mit den Verweisen
zu den vorhandenen Portalen aufgebaut.
Als Kernstück der Architektur der GDI Sachsen wird
eine zentrale GDI Sachsen-Plattform betrieben.
Mehrheitlich handelt es sich um sogenannte
Querschnittsdienste, mit denen die dezentralen
Geodatendienste aufgewertet und zu neuen Diensten
verkettet werden. Zudem stellt die Plattform Dienste
für das zentrale OWS Hosting und solche, mit denen
die GDI Sachsen-Registries verfügbar gemacht werden, bereit.
Hier handelt es sich um gegenwärtig und zukünftig (insbesondere im INSPIRE-Kontext) in Sachsen betriebene
Geo Web Services unterschiedlichen Typs (WMS, WFS,
WCS, CSW, WPS, WPOS, SOS, …), die i. d. R. die entsprechenden OGC interfaces unterstützen. Diese
dezentralen Geodatendienste werden von der jeweils
zuständigen Stelle unmittelbar auf die Originaldaten 5
aufgesetzt.
Die GDI Sachsen stellt Serverkomponenten zur Verfügung, wenn deren Betrieb nicht auf der zentralen GDI
Sachsen-Plattform, sondern auf einer der dezentralen
Dienste-Plattformen erforderlich ist. Dies betrifft im Wesentlichen GeoDRM-Komponenten.
5
„Originaldaten“ ist nicht mit „Produktionsdaten“ gleichzusetzen. Es kann sich dabei durchaus um
Kopien der Produktionsdaten handeln, die z. B. aus Sicherheits- oder Performanzgründen getrennt
von den Produktionsdaten für Präsentations- oder Datenabgabezwecke gehalten werden.
Seite 13 von 96
andere Ressourcen
(Originaldaten)
HTW Dresden (FH)
4/3
Die für INSPIRE und andere Anwendungen relevanten
Geo- und Metadaten werden primär über Dienste
verfügbar gemacht, welche auf die Originaldaten
zugreifen. Weitere in diesem Konzept beschriebene
Zugriffswege bilden das zentrale OWS Hosting und die
Bereitstellung der Geodaten über den GeoShop.
Externe
Dienste
Soweit Dienste, die für den Betrieb der GDI Sachsen
erforderlich sind, an externer Stelle (übergeordnete GDI,
Betreiber von IT-Diensten außerhalb der GI Community,
private Diensteanbieter, …) in der erforderlichen Qualität
angeboten werden und ihre Benutzung durch die GDI
Sachsen gesichert ist, können diese externen Dienste
anstelle zentraler Dienste genutzt werden. Es handelt
sich dabei in erster Linie um Processing Services (z. B.
Koordinatentransformationen), aber auch um allgemeine
IT-Services (z. B. einen TimeStamp Service).
Externe
Registry
Services
Es handelt sich um externe Dienste, mit denen Register
(siehe 5.1.5.3.1) übergeordneter GDI zugänglich
gemacht werden.
Sächsische
INSPIREund
andere
Ressourcen
(Hosting)
Es kann die Situation gegeben sein, dass geeignete
Geodaten (digital) vorliegen, der jeweilige
Dateneigentümer jedoch nicht über eine adäquate
Infrastruktur zum Betrieb entsprechender Dienste
verfügt. Um der Verpflichtung bzw. dem Wunsch zur
dienstebasierten Veröffentlichung dieser Geodaten
nachkommen zu können, unterbreitet GDI Sachsen ein
OWS Hosting-Angebot. Die dazu durch GDI Sachsen
betriebenen Geodatendienste greifen i. d. R. auf Kopien
der Originaldaten zu.
Externe
und
Zahlreiche Ressourcen einer GDI brauchen (oder sollen,
um eine einheitliche Verwendung sicherzustellen) innerhalb einer GDI nur einmal an zentraler Stelle vorliegen,
beispielsweise Koordinatenreferenzsysteme (CRS),
Transformationsparameter, Styles, Legenden, konzeptuelle Schemata der verschiedenen Anwendungen,
XML-Schemata, Stylesheets, Codelisten, Fachwörterbücher, Thesauri, ... . Die hier genannten Ressourcen werden in Registries nachgewiesen. Vorzugsvariante ist die
Benutzung externer, übergeordneter Registries. Die Alternative dazu besteht im Aufbau zentraler sächsischer
Registries. Weitere, innerhalb der GDI zentrale Ressourcen beschreiben Nutzer und deren Rechte, Lizenzen oder dienen der Verwaltung der Dienste.
Seite 14 von 96
4.3 Nutzungswege
4.3.2
4.3.3, 4.3.4
Anwendungsschicht
Die folgende Abbildung ergänzt die Abbildung 3 um die wichtigsten Nutzungswege,
die durch die geplanten Komponenten ermöglicht werden (außer 4.3.1). Die Nutzungswege können durch Anwendungsfälle weiter spezialisiert werden. Ein Beschreiten der Nutzungswege setzt voraus, dass rechtliche Grundlagen existieren
oder entsprechende Vereinbarungen auf der Basis des Lizenz- und Bepreisungsmodells getroffen wurden.
Diensteschicht
4.3.5
Externe
Dienste
Serverkomponenten
(durch GDI Sachsen
bereitgestellt)
andere Ressourcen
(Originaldaten)
Sächsische
INSPIREund
andere
Ressourcen
(Hosting)
Externe
Registry
Services
Externe
und
Datenschicht
4.3.1
Abbildung 4: Nutzungswege der GDI Sachsen
4.3.1 Bedienung sächsischer Anwendungen und übergeordneter GDI
durch dezentrale Geodatendienste
Dezentrale Geodatendienste können durch beliebige Anwendungen direkt und ohne
Benutzung der zentralen Dienste der GDI Sachsen genutzt werden.
Auch INSPIRE lässt in den Durchführungsbestimmungen offen, ob die zur Verfügung
zu stellenden Daten direkt über die zugehörigen Dienste in eine europäische Plattform eingebunden werden oder ob eine kaskadierende Struktur (beispielsweise
INSPIRE/GDI-DE – Knoten ↔ zentraler GDI Sachsen-Knoten ↔ LfULG-WMS) aufgebaut wird. Gleiches dürfte zukünftig für die Anforderungen aus GDI-DE zutreffen.
Voraussetzung für ein direktes Einbinden ist, dass alle Anforderungen seitens
INSPIRE bzw. GDI-DE hinsichtlich der Dienstequalität erfüllt sind.
Seite 15 von 96
4.3.2 Zugang zur sächsischen Geodateninfrastruktur über ein zentrales
GDI Sachsen-Portal
Als Einstiegsknoten für Nutzer, die sich die sächsische Geodateninfrastruktur interaktiv an einem browserbasierten Web Client erschließen, soll ein zentrales Web-Portal
betrieben werden. Bezüglich der Funktionalität dieses Portals vertreten die Verfasser
dieses Konzeptes die Auffassung, dass die existierenden sächsischen Geoportale
das Anwendungsspektrum hinreichend abdecken und insofern keine Notwendigkeit
besteht, ein „Über-Portal“ GDI Sachsen aufzubauen. Um der o. g. Anforderung zu
genügen, wird jedoch eine zentrale Einstiegsseite bereitgestellt, auf der der Nutzer
komprimiert Informationen zu den sächsischen Geoportalen erhält und zu diesen per
Link weitergeleitet wird. Umgekehrt wird angeregt, diese Einstiegsseite seitens der
diversen sächsischen Geoportale zu verlinken. Dadurch können Nutzer auf weitere
sächsische Portale aufmerksam gemacht werden.
4.3.3 Integration von zentral bereitgestellten Komponenten in sächsische
Anwendungen und Geoportale
Durch die GDI Sachsen werden umfassend Dienste bereitgestellt. Die Nutzung dieser Dienste erfolgt primär innerhalb der sächsischen GI-Anwendungen und Portale
und damit außerhalb der hier definierten GDI Sachsen-Architektur. In diesem Zusammenhang kann jedoch die Situation auftreten, dass Dienste nur deshalb nicht
genutzt werden, weil die Beschaffung zugehöriger Clients im Einzelfall unwirtschaftlich wäre. Um dies zu verhindern, stellt GDI Sachsen performant und hochverfügbar
Clientkomponenten zur Nutzung dieser Dienste zur Verfügung. Diese Clients können
parametriert aufgerufen und so in die Web-Anwendungen integriert werden.
Mit dieser Bereitstellung sollen folgende Ziele erreicht werden:
 Die Benutzung der zentralen und dezentralen sächsischen Geodatendienste,
speziell auch in „GIS-fernen“ Bereichen, wird befördert.
 Die Gesamtkosten für die Entwicklung von Anwendungen können reduziert werden.
Praktische Erfahrungen liegen in diesem Zusammenhang bei der Integration des
Sachsenatlas-Karten-Clients in externe Webseiten, z. B. die des Sächsischen Oberbergamtes, vor.
Die zentrale Bereitstellung von Clientkomponenten ist ebenfalls im Zusammenhang
mit der Absicherung von Diensten relevant, da hier (noch) keine innerhalb der GI
Community allgemein anerkannten Implementierungsspezifikationen vorliegen. Das
Zusammenwirken verteilter Komponenten innerhalb der GDI kann temporär bis zum
Vorliegen von Implementierungsspezifikationen durch die Verwendung von proprietären, jedoch untereinander interoperablen Produkten erreicht werden.
Seite 16 von 96
4.3.4 Verwendung zentraler Dienste der GDI Sachsen
Die Benutzung der zentral angebotenen Dienste stellt den Hauptnutzungsweg der
GDI Sachsen dar. Das Diensteangebot stellt in umfassender Weise Dienste über
(mehrheitlich) standardisierte Schnittstellen (interfaces) zur Integration in GIAnwendungen zur Verfügung. Über diesen Nutzungsweg erfolgt auch der Zugriff auf
die Ressourcenschicht der GDI Sachsen-Plattform (zentral gehostete Kopien von
Geodaten und zentrale Registries).
Weiterhin bedienen zentrale Dienste die (Dienste-) Anforderungen aus INSPIRE und
GDI-DE (außer Nutzungsweg 4.3.1), insbesondere durch Aggregation der entsprechenden sächsischen Ressourcen und Transformation in die geforderten Schnittstellen. Vereinfacht kann folgender Workflow identifiziert werden:
1. Auftreffen eines INSPIRE-Request an einem INSPIRE-Knoten (siehe
5.1.3.4.1) der GDI Sachsen
2. Umwandlung des Request in OWS-Requests an die dezentralen
Geodatendienste bzw. den OWS Hosting Service
3. Transformation des Service Responses (z. B. CRS, Schema) durch zentrale
und/oder externe Transformationsdienste
4. Aggregation und Absetzen des INSPIRE Response
Die Infrastruktur dient auch dazu, um möglichst kurzfristig, flexibel und ohne Entwicklungsarbeiten auf aktuelle Anforderungen reagieren zu können, z. B. im Rahmen des
Katastrophenmanagements:
1. Eintreffen der Anforderung nach einem GI-Produkt 6 bei GDI Sachsen
2. Identifizierung der betroffenen Geodaten und Geodatendienste
(GeoMIS.Sachsen)
3. ggf. Auslösen der Workflows zum Aufsetzen eines neuen / Erweiterung eines
bestehenden OWS Hosting Services
4. Modellierung, formale Beschreibung der Dienstekette, Bereitstellen des neuen
Dienstes
5. Metadatenbeschreibung und Veröffentlichung im GeoMIS.Sachsen
6. Ausführung des Dienstes, damit Bereitstellung des Produktes
In geringfügig modifizierter Form wäre dieser Workflow auch geeignet, um Anforderungen nach neuen Diensten aus INSPIRE zu erfüllen. Die Grundlagen für den beschriebenen Aufbau neuer Dienste durch die Kombination bestehender Dienste werden unter 4.4.2 behandelt.
6
Ein GI-Produkt könnte beispielsweise ein Link zu einer Karte, welche die bei einem bestimmten Pegelstand überschwemmten Gebiete zeigt, sein.
Seite 17 von 96
4.3.5 Benutzung von zentral zur Verfügung gestellten Serverkomponenten
Im Grundsatz greift GDI Sachsen nicht in die dezentral bestehende sächsische
Dienstelandschaft ein. Wenn Dienste jedoch abgesichert werden sollen, so werden
sie hinter einem sog. Gatekeeper Service verborgen. Dieser Dienst kann prinzipiell
entweder auf der zentralen GDI Sachsen-Plattform oder auf den Plattformen der
dezentralen Dienstebetreiber installiert sein. In letzterem Falle sollte der Gatekeeper
inkl. eines ggf. separat implementierten Protokollwandlungsdienstes zentral bereitgestellt werden. In Analogie zu den zugehörigen Clientkomponenten (siehe 4.3.3) muss
damit auch hier Interoperabilität innerhalb der GDI Sachsen temporär bis zum Vorliegen von entsprechenden Implementierungsspezifikationen durch den Einsatz von
proprietären Produkten "aus einer Hand" sichergestellt werden.
Weiterhin werden zwei Dienste zur dezentralen Benutzung bereitgestellt, durch die
die Größe einer XML-Datei und damit die Übertragungsdauer entscheidend reduziert
werden können (XML-Komprimierungsdienst und XML-Whitespace).
4.4 Weitere Anforderungen
4.4.1 Dienstequalität
In Service-orientierten Architekturen sind Anwendungen von verteilten Diensten abhängig. An die Qualität der Dienste sowie der zugrundeliegenden Netzinfrastruktur
sind daher erhebliche Anforderungen zu stellen. INSPIRE (z. B. in [16], Seite 8; [15],
Seite 21) definiert dazu die Qualitätsparameter Performanz, Kapazität, Verfügbarkeit,
Verlässlichkeit, Sicherheit sowie Konformität, fordert deren Überwachung und arbeitet an der Festlegung entsprechender Grenzwerte. Die Feinspezifikation dieses Konzeptes muss daher für die genannten Parameter dienstetyp-spezifische, teilweise
auch dienste-spezifische Vorgaben enthalten. Die Position des jeweiligen Dienstes
innerhalb einer Dienstekette ist zu berücksichtigen (An einen Dienst, der unmittelbar
durch INSPIRE aufgerufen wird, sind geringere Performanceanforderungen zu stellen als an einen, der beispielweise über GDI Sachsen und GDI-DE kaskadiert wird.).
4.4.2 Orchestrierung
Ein wesentlicher Mehrwert innerhalb einer SOA kann dadurch erreicht werden,
schnell und flexibel neue Dienste bereitzustellen. Unter Orchestrierung wird die Erstellung eines neuen, höherwertigen Dienstes durch eine intelligente Verkettung von
vorhandenen Diensten verstanden. Diese resultierenden Dienste werden in INSPIRE
als „Invoke Spatial Services Services“ klassifiziert und mit „Dienst zum Abrufen von
Geodatendiensten“ übersetzt. Entsprechend der Taxonomie aus ISO 19119 handelt
es sich um Geographic workflow/task management services.
Seite 18 von 96
Eine Verknüpfung von Diensten erfolgt bereits innerhalb von GDI Frameworks: Beispielsweise bilden WFS, WCTS und WMS interne Diensteketten. Da in diesem Fall
die Nutzeranforderung a priori bekannt ist („Bereitstellung einer Karte“), sind die beteiligten Dienste „fest“ miteinander verknüpft. Jedoch kann einerseits davon ausgegangen werden, dass die Anzahl der angebotenen (OGC) Web Service-Typen und
-Instanzen, insbesondere im Bereich der Processing Services perspektivisch stetig
ansteigt. Andererseits besteht die Notwendigkeit, flexibel neue höherwertige
Geodatendienste bzw. im Ergebnis der Abarbeitung neue GI-Produkte anbieten zu
können. Diese Flexibilität kann erreicht werden, indem auf der GDI SachsenPlattform Werkzeuge bereitstehen, mit denen Fachadministratoren ohne Entwicklungsarbeiten neue Dienste durch den Aufbau von Diensteketten generieren können.
Somit kann rasch auf aktuelle Nutzeranforderungen reagiert werden. Dies ermöglicht
auch eine schnelle Reaktion auf kurzfristige Anforderungen, welche beispielweise im
Katastrophenfall entstehen können. Werkzeuge zur Orchestrierung werden durch
Standard-IT bereitgestellt.
4.4.3 Absicherung von Geodatendiensten
Bisherige GDI integrieren in der Mehrheit Geodatendienste, die frei zugänglich sind.
Dies spiegelt die Tatsache wider, dass das Schutzbedürfnis in der Mehrzahl der
Dienste, insbesondere bei den INSPIRE-Themen, schwach ausgeprägt ist. Dieses
Schutzbedürfnis lässt sich oftmals durch einfache Maßnahmen befriedigen, beispielsweise durch Einfügen eines Wasserzeichens in die Karte.
Die Realisierung eines höherwertigen Zugriffsschutzes verlangt dagegen den Aufbau
einer vergleichsweise umfangreichen Infrastruktur, die mit erheblichen Investitionen
verbunden ist. Zusammen mit dem erstgenannten Aspekt führt dies dann dazu, dass
diese Investitionen wegen des ungünstigen Kosten-Nutzen-Verhältnisses oft unterbleiben. Die betroffenen Ressourcen stehen dann über Geodatendienste gar nicht,
auch nicht für berechtigte Nutzer, zur Verfügung.
In dieser Situation bietet sich eine gezielte staatliche Investition an, um die Softwarekomponenten zur Absicherung von Geodatendiensten zentral bereitzustellen.
Da, wie eingangs dargelegt, die Anzahl freier Themen überwiegt, liegt diesem Konzept der Ansatz zugrunde, dass alle Dienste zunächst als frei nutzbar angesehen
werden und damit ungeschützt sind. Wird jedoch ein Dienst als „geschützt“ 7 klassifiziert, kehrt sich dieser Ansatz um: A priori werden dann alle Zugriffe auf den Dienst
abgewiesen und nur im Rahmen von (positiven) Rechten ermöglicht. Dabei wird
deutlich werden, dass auch die Durchsetzung sehr geringer Einschränkungen (beispielsweise soll der Benutzer vor Nutzung eines Dienstes Nutzungsbedingungen bestätigen) eines erheblichen Workflows bedarf. Insofern wird empfohlen, Dienste so
weit wie möglich „offen“ zu halten und ggf. notwendige Einschränkungen im Rahmen
eines allgemeinen Nutzungs- und Lizenzkonzeptes auf ein Minimum zu reduzieren.
7
Bietet ein OWS sowohl eingeschränkt zugänglichen als auch freien Inhalt an, so gilt er als geschützter Dienst.
Seite 19 von 96
5 Funktionale Sicht
Dieses Kapitel beschreibt die Komponenten der GDI Sachsen (Abschnitt 5.1) und
exemplarisch deren Interaktionen (5.2). Dazu werden die Komponenten aus der
Abbildung 3 in Abbildung 5 detailliert dargestellt und im Text weiter verfeinert. Die
aus Sicht der GDI Sachsen dezentralen und externen Komponenten (in den Abbildungen grau dargestellt) werden der Vollständigkeit halber mit aufgeführt. Der Abschnitt 5.1 ist entsprechend den in Abbildung 5 dargestellten Schichten gegliedert.
Lediglich die für Sicherheitsaspekte relevanten Komponenten werden aus Gründen
der Übersichtlichkeit unter 5.1.6 schichtübergreifend dargestellt.
5.1 Strukturelle Sicht
Sächsische und weitere
Anwendungen/Portale
INSPIRE/GDI-DE
GDI Sachsen-Portal
„Sachsenatlas“
GeoDRM Client und Anwendungskomponenten
Protokoll-Wandlung
HTTP GET/POST  SOAP
Darstellungs- und
Download-Dienste
OWS Hosting
Koordinaten„Sachsenatlas“
transformation
Karte
Recherche
GeoDRM Client
Administration
TransformationsDienste
Shop
Dienste zum Abrufen
von Geodiensten
(Orchestrierte Dienste)
Protokoll-Wandlung
HTTP GET/POST  SOAP
Serverkomponenten
(durch GDI Sachsen
bereitgestellt)
Gatekeeper
XML Komprimierung
Proprietärer
DRM Layer
Weitere Dienste
OWS Hosting
Registry
Services
GeoDRM
Services
Externe
Dienste
Service
Management
Externe
Registry
Services
(WMS, WFS, WCS, CSW, WPS, WPOS, SOS…)
Registries
MetaDaten
GeoDB
Preismodelle
Nutzer
Sächsische INSPIRE- und andere Ressourcen (Originale)
…
…
Geodaten
(Kopien)
Nutzer, Lizenzen
Rechte
zentrales Diensteverzeichnis
Abbildung 5: Komponenten der GDI Sachsen
Seite 20 von 96
5.1.1 Anwendungsschicht
5.1.1.1
INSPIRE/GDI-DE
Aus einer technischen Sicht seitens GDI Sachsen handelt es sich bei den
INSPIRE/GDI-DE - Komponenten um Web Service Clients. Deren Schnittstellen
bauen auf den entsprechenden OGC Spezifikationen auf, verlangen jedoch Erweiterungen (z. B. Mehrsprachigkeit aus INSPIRE) bzw. schränken diese ein („Profile“).
Dabei sind zwei Aspekte relevant:


Der Prozess der Spezifizierung dieser Schnittstellen ist gegenwärtig im Gange
und bei Weitem noch nicht abgeschlossen.
Dezentrale OWS-Dienste (dezentrale Geodatendienste) bedienen die genannten interfaces nur in Ausnahmefällen, so dass Transformationen benötigt werden.
Daraus kann geschlussfolgert werden:

Wenn INSPIRE/GDI-DE auf mehrere dezentrale Geodatendienste gleichen
Typs zugreifen, ist es wirtschaftlich sinnvoll, die erforderlichen Transformationen einmal zentral auf der GDI Sachsen-Plattform zu implementieren.
Diese Implementierung soll in einem hohen Maße parametrierbar sein, um die zu
erwartenden Weiterentwicklungen der Dienstespezifikationen kostengünstig realisieren zu können.
5.1.1.2
Sächsische und weitere Anwendungen/Portale
Wie bereits ausgeführt, reglementiert dieses Architekturkonzept bestehende Anwendungen und Portale nicht. Zentrale Dienste können jeweils integriert werden und sollen daher zunächst die in den eingesetzten Produkten und Lösungen überwiegend
implementierten OGC interfaces unterstützen. Perspektivisch wird erwartet, dass
Anwendungen und Portale SOAP-basierte Schnittstellen unterstützen werden.
5.1.1.3
Sachsenatlas
Dieses Architekturkonzept geht davon aus, dass die einzelnen zentralen Dienste je
nach Bedarf und auf freiwilliger Basis durch Anwendungen und Portale genutzt werden. Es ist jedoch sinnvoll, die für die Benutzung der Dienste erforderlichen Clients
einschließlich der zugehörigen Benutzer-Schnittstellen an mindestens einer Stelle zu
bündeln. Es liegt nahe, diese Aufgabe dem vom Freistaat Sachsen bereits betriebenen Geoportal „Sachsenatlas“ zuzuweisen. Dazu wären die entsprechenden Teile
der „Basiskomponente Geodaten (GeoBAK)“ weiterzuentwickeln bzw. zu ersetzen.
Der Sachsenatlas ist insofern, bezogen auf die sonstigen sächsischen Geoportale,
„primus inter pares“.
Seite 21 von 96
5.1.1.4
GDI Sachsen-Portal
Mit www.gdi.sachsen.de betreibt die gdi.initiative.sachsen eine Homepage, die als
zentrale Einstiegsseite in die sächsische Geodateninfrastruktur gesehen werden
kann. Dabei handelt es sich nicht um ein Geoportal im klassischen Sinne. Bezüglich
typischer Funktionalitäten wie die Anzeige von Karten oder die Recherche nach
Geodaten wird direkt auf die entsprechenden einschlägigen Portale wie den
Sachsenatlas oder das GeoMIS.Sachsen verlinkt.
Dieser Ansatz soll ausgebaut werden. Auf www.gdi.sachsen.de wird ein Link
„Geoportale“ gesetzt, der auf eine Seite verweist, die ausgewählte Metadaten zu den
sächsischen Portalen enthält, z. B.:




Titel, Logo und Link,
eine Kurzbeschreibung zum Portal,
seine räumliche Ausdehnung 8 sowie
die Verknüpfung zur vollständigen Beschreibung des Portals.
Die folgenden Screenshots enthalten Vorschläge für den Aufbau dieses Portals:
GDI Portal
Anwendungen
Kartenübersicht
Datenblätter
Ausdehnung
Suche:
Erweiterte Suche
Themenbrowser
Nutzerverwaltung
Ausdehnung
Registrierung
Anmeldung (LogIn)
Ausdehnung
Koordinierungsstelle
gdi.Sachsen
Ausdehnung
Ausdehnung
Ausdehnung
Abbildung 6: GDI Sachsen-Portal - Überblick
8
Darunter wird hier der geographische Bereich verstanden, der durch das jeweilige Geoportal primär
abgedeckt werden soll: z. B. Sachsen, eine Kommune oder eine Region.
Seite 22 von 96
GDI Portal
Anwendungen
Kartenübersicht
Datenblätter
Suche:
Erweiterte Suche
Themenbrowser
Nutzerverwaltung
Registrierung
Anmeldung (LogIn)
gdi.Sachsen
Abbildung 7: GDI Sachsen-Portal - Beschreibung
GDI Portal
Anwendungen
Kartenübersicht
Datenblätter
Sachsenatlas
Basiskarte
Stadtplan Dresden
Suche:
Geopoprtal NOL
Erweiterte Suche
Themenbrowser
….
Nutzerverwaltung
Registrierung
Anmeldung (LogIn)
gdi.Sachsen
Abbildung 8: GDI Sachsen-Portal - Ausdehnung
Seite 23 von 96
GDI Portal
Anwendungen
Kartenübersicht
Datenblätter
Suche:
Erweiterte Suche
Themenbrowser
Nutzerverwaltung
Registrierung
Anmeldung (LogIn)
gdi.Sachsen
speichern
drucken
Abbildung 9: GDI Sachsen-Portal - vollständige Metadaten
Die Beschreibungen der Portale werden nicht separat vorgehalten und gepflegt, sondern direkt aus dem Suchdienst des GeoMIS.Sachsen bezogen. Dazu werden die
Metadaten aus einem CSW Response mittels eines zentralen
Transformationsdienstes (XSL-Transformation) zum Zwecke der Darstellung nach
HTML gewandelt. Dieses Vorgehen setzt voraus, dass die Portale im
GeoMIS.Sachsen oder in einem daran angeschlossenen MIS mit den hier benötigten
Metadaten beschrieben sind.
Das GDI Sachsen-Portal integriert weiterhin einen Client zur Verwaltung der Einträge
in der zentralen Nutzerverwaltung (siehe Abschnitt 5.1.6.3).
5.1.1.5
Registry Clients
Für die Benutzung und Pflege von Registries sollen Clients bereitgestellt werden.
Das Rollenkonzept aus ISO 19135 [30] definiert für die Benutzung von Registries
den Register User, für die technische Pflege der Registries den Registry Manager.
Soweit die zugrunde liegenden Register in der fachlichen Zuständigkeit der GDI
Sachsen liegen, sollen die entsprechenden Registry Clients durch die GDI Sachsen
bereitgestellt werden. Die Clients für die Pflege der Registries (bzw. der jeweiligen
Bereiche von zentralen oder externen Registries – vgl. 5.1.5.3.1) sollen abgesichert
sein.
Seite 24 von 96
5.1.1.6
Administration
Die Verwaltung der einzelnen Komponenten erfordert Administrations-Clients z. B.



zur Administration der zentralen Dienste und des GDI Sachsen-Portals,
zur Parametrierung und Auswertung des Service Monitoring oder
zur Orchestrierung von Diensten.
Administrations-Clients sind abzusichern.
5.1.2 Anwendungs- und GeoDRM-Komponenten (durch GDI Sachsen
bereitgestellt)
Seitens GDI Sachsen werden Komponenten zur Verfügung gestellt, die in WebAnwendungen integriert werden können. Bei den Anwendungskomponenten handelt
es sich um HTML Clients, die von einem Server der GDI Sachsen-Plattform mittels
parametrierter Hyperlinks angefordert und in die umgebende Seite als iFrameElement integriert werden. Dabei kann sowohl der Inhalt der Clients variiert als auch
deren Layout mittels Stylesheets an die Zielumgebung angepasst werden.
Vorgesehen sind die in den Unterpunkten zu 5.1.2 genannten Clienttypen.
Zur besseren Veranschaulichung werden jeweils eine Ausprägung des Karten-, des
Recherche- und des Location Finder Clients, die durch die Basiskomponente
Geodaten (GeoBAK) aktuell in mehreren Ausprägungen zur Integration in externe
Webanwendungen zur Verfügung gestellt werden, im Sinne einer best practiceLösung gezeigt. Die entsprechenden Ausführungen zu 5.1.2.1 bis 5.1.2.3 sind aus
dem GeoBAK-Integrationsleitfaden [8] entnommen. Nicht eingegangen wird an dieser Stelle auf die zugrundeliegenden Dienste.
Die nachfolgend gezeigten Clients sind nicht im Sinne einer abgeschlossenen Liste
zu verstehen. Beispielsweise können weitere Kartenclients vorgesehen werden, die
u.a. auf Tile Caching Services (vgl. 5.1.3.4.1, Tabelle 12) zugreifen und clientseitig
cachen können. Diese Lösungen bieten gegenüber den eingeführten OGC WMS
Clients nur eingeschränkte Möglichkeiten zur Überlagerung von Kartenebenen, erfüllen jedoch die Erwartungen von GIS-Laien bzgl. Performance und Useability weit
besser. Solche Kartenclients sind somit insbesondere für sog. "Publikumsportale"
oder für mobile Anwendungen geeignet.
Weiterhin werden in den Abschnitten 5.1.2.7 und 5.1.2.6 mit dem ProtokollWandlungs-Dienst sowie dem GeoDRM Client-Komponenten genannt, die logisch an
der Schnittstelle zwischen der GDI Sachsen-Plattform und den Anwendungsplattformen platziert sind. Sie können sowohl auf der GDI Sachsen-Plattform als auch auf
den Anwendungsplattformen installiert sein.
Seite 25 von 96
5.1.2.1 Karten-Client
Abbildung 10 zeigt den erweiterten HTML Client des Sachsenatlas. Die hervorgehobenen Elemente (Übersichtskarte, Kartenansicht mit Navigationselementen und
Ebenensteuerung) können in externe Webseiten integriert werden.
Abbildung 10: Integration Kartenclient [8]
Parametrierbar sind dabei u.a.:
 der Inhalt (z. B. Auswahl der Bedienelemente) und das Layout des Clients,
 die initial darzustellenden Geodatendienste und Ebenen,
 das Koordinatensystem und
 die Bounding Box.
5.1.2.2
Recherche-Client
Der Recherche-Client dient u.a. zur Suche nach Metadaten zu Geodaten,
Geodatendiensten und Geodatenanwendungen unter Benutzung der CSWSchnittstelle des GeoMIS.Sachsen (Suchdienst). Die Abbildung 11 zeigt den Client in
der Ausprägung „Erweiterte Suche“.
Seite 26 von 96
Abbildung 11: Recherche-Client [http://www.atlas.sachsen.de]
5.1.2.3
Location Finder Client
Mittels des Location Finder Clients wird die Nutzerinteraktion bei der Suche der zu
einem geographischen Namen zugehörigen Geometrie realisiert. In Abhängigkeit
vom jeweiligen location type (Adressen, Ortsnamen, Naturräume, Postleitzahlen,
Flurstücksbezeichnungen, …) ist der Location Finder Client unterschiedlich ausgeprägt:
Abbildung 12: Location Finder Client zur Adress- und Ortssuche [8]
Der Location Finder Client stellt Dialoge bei unvollständigen oder fehlerhaften Eingaben bereit. Die gefundene Geometrie kann beispielweise anschließend im Kartenclient visualisiert werden.
Seite 27 von 96
5.1.2.4
Order Client
In Analogie zu den vorab beschriebenen Clients ist die Bereitstellung eines Clients
zu dem im Aufbau befindlichen GeoShop vorgesehen [14].
5.1.2.5
Koordinatentransformations-Client
Transformationen sind üblicherweise als Dienste implementiert, die durch andere
Softwarekomponenten aufgerufen werden und i.d.R. über kein User interface verfügen. Transformationen zwischen verschiedenen Koordinatenreferenzsystemen werden jedoch auch interaktiv durchgeführt, so dass zusätzlich ein Client mit den benötigten Dialogen erforderlich ist.
5.1.2.6
GeoDRM Client
Alle GeoDRM-Komponenten werden geschlossen unter Abschnitt 5.1.6 dargestellt.
5.1.2.7
Protokoll-Wandlung
Unter Abschnitt 5.1.3.4.4 wird beschrieben und begründet, dass als Protokoll innerhalb der GDI Sachsen-Plattform SOAP (over HTTP POST) verwendet werden soll
und somit eine bidirektionale Wandlung zu HTTP GET/POST - basierten OGC
interfaces notwendig ist. Diese Protokollwandlung wird als Dienst auf der GDI Sachsen-Plattform bereitgestellt, kann jedoch auch auf den dezentralen Anwendungsplattformen installiert sein. Die letztere Variante ist zu wählen, wenn der GeoDRM Client
ebenfalls auf den dezentralen Anwendungsplattformen implementiert ist.
5.1.3 Diensteschicht
Grundlage einer SOA sind (Web-)Dienste. Diese Dienste sind durch ihre
Schnittstellen definiert, welche mittels WSDL zu beschreiben sind. Daten werden
zwischen den Diensten auf der Basis von SOAP ausgetauscht. „Atomare“
Basisdienste mit eingeschränkter Funktionalität, aber mit einem hohen Grad an Wiederverwendbarkeit werden zu höherwertigen Diensteketten aggregiert und damit Geschäftsprozesse abgebildet. Alle Techniken bauen auf dem IT-Standard XML auf.
Die konsequente Verwendung von Standard-IT-Technologien impliziert eine Reihe
von Vorteilen, von denen die Integration der Geodatendienste in E-GovernmentProzesse, die Vermeidung von Mehrfachentwicklungen durch die Verwendung eingeführter Technologien wie WS-Security oder XSLT und die Erleichterung der Orchestrierbarkeit die Wesentlichsten sind. Nachteilig sind die (gegenwärtig noch zusätzlich)
erforderliche Beschreibung der verbreiteten OWS mittels WSDL und die ProtokollWandlung (bidirektional) zu SOAP sowie die damit einhergehenden Performanzverluste. Die Vorteile überwiegen die Nachteile jedoch in einer solchen Weise, dass seitens INSPIRE auf die Verwendung von SOAP orientiert wird [15]. Zudem kann perspektivisch erwartet werden, dass auch OWS-Spezifikationen SOAP-Schnittstellen
beinhalten werden. Bereits heute verfügen Service-Implementierungen mehrerer
Hersteller über „einfache“ SOAP-Schnittstellen, deren XML-Strukturen jedoch nicht
standardisiert sind.
Seite 28 von 96
Die Identifizierung von Diensten kann auf verschiedenen Wegen erfolgen: Bei einem
sogenannten „bottom-up“-Ansatz werden Basisdienste zu höherwertigen Diensten
(„Mehrwertdienste“, „Integrationsdienste“) zusammengefasst, die wiederum in den
Anwendungen eingebunden sind. Das als „top-down“-Ansatz bezeichnete Gegenstück besteht darin, Geschäftsprozesse zu modellieren und in der Folge sukzessive
auf immer feingranularere Dienste abzubilden. Ein „meet-in-the-middle“-Ansatz kombiniert beide Strategien.
Aufgrund der Rahmenbedingungen (Existenz von Basisdiensten einerseits, fehlende
Prozessbeschreibungen andererseits) folgt dieses Konzept dem „bottom-up“-Ansatz.
Aufbauend auf den vorhandenen Basisdiensten werden insbesondere Querschnittsdienste auf der zentralen GDI Sachsen-Plattform bereitgestellt. Basis- und
Querschnittsdienste werden zu höherwertigen Diensten verkettet. Da dieses Konzept
wie eingangs erläutert Anwendungen nicht betrachtet, werden diese höherwertigen
Dienste explizit nicht beschrieben. Die Infrastruktur zu deren Erzeugung ist dagegen
vorgesehen.
Die in der Vorstudie zum Betriebskonzept [9] genannten abstrakten Diensttypen sind
wie folgt abgebildet:
Suchdienste sind als Katalogdienste der verteilten sächsischen MIS implementiert.
Eine hervorgehobene Rolle spielt das GeoMIS.Sachsen, dessen Suchdienst die in
den verteilten MIS vorliegenden Metadaten aggregiert. Im Sinne der GDI Sachsen ist
der Suchdienst des GeoMIS.Sachsen daher ein „zentraler“ Dienst, der jedoch
dezentral im GeoSN betrieben wird und in diesem Konzept auch so eingeordnet ist.
Darüber hinaus wird kein Suchdienst als zentraler Dienst implementiert.
Darstellungsdienste und Downloaddienste sind primär die dezentralen
Geodatendienste WMS bzw. WFS. Als zentrale Dienste werden weitere
Darstellungsdienste und Downloaddienste sowie Dienste im Zusammenhang mit
dem OWS Hosting und als orchestrierte Dienste angeboten.
Transformationsdienste unterschiedlichen Typs werden vorrangig als zentrale Dienste betrieben.
Dienste zum Abrufen von Geodatendiensten sind orchestrierte Dienste, die zentral
bereitgestellt werden.
Registerdienste (in diesem Konzept als Registry Services bezeichnet) werden vorrangig von übergeordneten GDI bereitgestellt und lediglich ersatzweise als zentrale
Dienste implementiert.
Die folgende Zusammenstellung nennt die aus heutiger Sicht wichtigsten Dienste
exemplarisch. Eine abschließende Aufzählung ist weder möglich noch beabsichtigt.
Im Gegenteil: Die Erweiterbarkeit der Dienstelandschaft um zusätzliche Diensttypen
und -Instanzen ist ein wesentliches Ziel dieses Konzeptes und der darauf aufbauenden Implementierung.
Seite 29 von 96
Die Gruppierung der Dienste folgt der Abbildung 5 und geht dabei von unten nach
oben vor. Da das Angebot an Basisdiensten, externen Diensten und Registry Services nicht vollständig bekannt und im Wachsen begriffen ist, ist die Zuordnung einzelner Dienste bzw. Diensttypen dynamisch und zum gegenwärtigen Zeitpunkt teilweise
willkürlich.
Folgende Vorlage wird für die Beschreibung der Dienste verwendet.
Bezeichnung
Klassifizierung
Bezeichnung des Dienstes
Klassifizierung nach ISO 19119 [55]
 Geographic human interaction services
 Geographic model/information management services
 Geographic workflow/task management services
 Geographic processing services
 Geographic processing services - metadata
 Geographic communication services
Klassifizierung nach INSPIRE
 Suchdienst (discovery service)
 Darstellungsdienst (view service)
 Downloaddienst (download service)
 Transformationsdienste (transformation services)
o Formattransformation (format transformation)
o Sprachübersetzung (language translation)
o Geometrische Transformation (geometric transformation)
o Schematransformation (schemas translation)
 Dienste zum Abrufen von Geodatendiensten (invoke spatial services services)
 Registerdienst (registry service)
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Klassifizierung nach GDI-DE (Verpflichtungsattribute)
 obligatorisch
 optional
 zukünftig
Verbale Beschreibung des Dienstes.
Unterscheidung, ob ein Typ oder eine Instanz beschrieben
wird.
Schnittstellenbeschreibung (verbal oder als Standard)
Zugrundeliegende Normen und Standards, weiterführende
Quellen. Die Angaben erfolgen als Kurzbezeichnungen und
Verweis auf das Literaturverzeichnis.
Nennen von vorhandenen Implementierungen und Anwendungen.
Ergänzende Angaben und Hinweise zum Dienst.
Tabelle 1: Vorlage Dienstebeschreibung
Seite 30 von 96
5.1.3.1
Die dezentralen („originären“) sächsischen Geodatendienste sind die Basis der
sächsischen Geodateninfrastruktur. Es handelt sich zunächst um OGC Web
Services, wobei die Integration weiterer Diensttypen möglich ist. Exemplarisch werden aus der Menge der OWS hier auf Typebene Web Map Services und Web Terrain
Services (Darstellungsdienste), Web Feature Services (Downloaddienste) und
WPOS sowie der Suchdienst als Instanz genannt.
Grundlage jeder Geodateninfrastruktur ist die Einhaltung einer definierten Dienstequalität 9 (Konformität, Performanz, Verfügbarkeit, …), wobei die Unterstützung von
standardisierten Schnittstellen eine herausgehobene Stellung einnimmt. Die Erfüllung aller diesbezüglichen Anforderungen (z. B. Unterstützung unterschiedlicher
OGC Versionen, der INSPIRE interfaces sowie von GDI-DE- und sächsischen
Profilen) dürfte jedoch die Leistungsfähigkeit der meisten Dienstebetreiber überfordern und in der Folge zu einer Einschränkung des Datenangebotes führen.
In dieser Frage liegt diesem Konzept daher die Strategie zugrunde, die Dienstebetreiber bei der Einhaltung der Qualitätsanforderungen (z. B. aus INSPIRE) bestmöglich durch die GDI Sachsen zu unterstützen. Beispielsweise verzichtet dieses
Grobkonzept darauf, die Schnittstellen bei den Anbietern der Basisdienste zu reglementieren. Vielmehr wird darauf vertraut, dass durch die Verwendung entsprechender OGC konformer Server in Verbindung mit einer geeigneten Parametrierung (z. B.
bei WMS Bedienung „sächsischer“ CRS, Unterstützung des PNG-Formats sowie von
Transparenz) ein Mindestmaß an Interoperabilität sichergestellt ist. Weitergehende
Anforderungen an die Bereitstellung spezieller Schnittstellen werden durch Diensteketten der GDI Sachsen-Plattform, insbesondere unter Verwendung von
Transformationsdiensten, sichergestellt. Qualitätsanforderungen (z. B. in den Kategorien Performanz und Verfügbarkeit) werden nur dann und in dem Maße an die Betreiber von Basisdiensten gestellt, wenn diese Anforderungen durch GDI Sachsen
allein nicht erfüllbar sind.
Dieser Ansatz setzt selbstverständlich voraus, dass die durch die dezentralen
Geodatendienste verfügbar gemachten Geo- und Metadaten inhaltlich den Anforderungen aus INSPIRE und GDI-DE entsprechen. Besonders ist an dieser Stelle auf
die INSPIRE-Forderung nach Mehrsprachigkeit hinzuweisen. Die Bereitstellung
mehrsprachiger Geo- und Metadaten sind bei der geodatenhaltenden Stelle selbst
sicherzustellen. Eine vollständige „on-the-fly-Übersetzung“ auf der GDI SachsenPlattform wird als nicht möglich eingeschätzt.
9
Die Festlegung von zulässigen Werten für Qualitätsparameter ist nicht Gegenstand dieses Konzepts.
Seite 31 von 96
Bezeichnung
Klassifizierung
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Darstellungsdienst – 2D (WMS)
ISO 19119: Geographic model/information management
services (map access service)
INSPIRE:
Darstellungsdienst
GDI-DE :
obligatorisch ([4] Abschnitt 5.2.1.4)
WMS geben Bilddaten (prinzipiell sind auch Grafikdaten, z. B.
im Format SVG möglich) und optional Sachdaten zu Positionen auf Kartenebenen ab.
Die grafische Ausprägung der Bilddaten ist clientseitig unter
Verwendung von SLD steuerbar. Zur Unterstützung einheitlicher Darstellungen sind die Symbology Encoding (SE) Styles
in einer (zentralen oder externen) Registry (siehe 5.1.5.3.1) zu
hosten.
Typ
gemäß Bezugsdokumenten
 OGC WMS Version: 1.0.0 - 1.3.0 ([33], [34], [35]) /
ISO 19128
 INSPIRE Implementing Rule [16]
 Architekturkonzept GDI-DE ([4] Abschnitt 5.2.1.4)
 GDI-DE – Profil [37]
 WMS Profil Sachsen [38]
 OGC SLD [36]
 OGC SE [27]
z.Zt. ca. 40 sächsische WMS (Quelle GeoMIS.Sachsen)
Nach INSPIRE sind für Dienste die Fehlermeldungen und die
Servicemetadaten mehrsprachig zu unterstützen [49].
In der von INSPIRE geforderten WMS Version 1.3 ist, im Gegensatz zu den früheren Versionen 1.1.0 und 1.1.1, SLD nicht
mehr explizit Bestandteil der WMS Spezifikation. In einer separaten Spezifikation (aktuell SLD 1.1.0) ist SLD als WMS
Profil angelegt. Seitens der WMS, die INSPIRE bedienen,
wird jedoch SLD-Fähigkeit erforderlich sein, um die geforderte
harmonisierte Darstellung zu erreichen. Aus diesem Grund ist
SLD seitens INSPIRE als optional vorgesehen [16].
Die bisherigen Implementierungen in Sachsen verwenden
mehrheitlich die WMS Version 1.1.1, was ein „Anheben“ der
Version durch einen zentralen Dienst erfordern kann.
Tabelle 2: Darstellungsdienst - 2D
Seite 32 von 96
Bezeichnung
Klassifizierung
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Darstellungsdienst – 3D
INSPIRE:
Darstellungsdienst
GDI-DE:
optional ([4] Abschnitt 5.3.1.1)
Der „Darstellungsdienst – 3D“ gibt gerenderte 3D-Ansichten
von Geodaten (Web Terrain Service) zurück.
Instanz
 OGC Web Terrain Server (WTS) [43]
3D Viewer Geoportal.Bund BKG (WTS)
Der WTS wird auch als Web Perspective View Service
(WPVS) bezeichnet.
Im Unterschied zum Web Terrain Service gibt ein Web 3D
Service (OGC Web 3D Service (W3DS) [44]) keine gerenderten Ansichten, sondern 3D-Grafikdaten zurück.
Tabelle 3: Darstellungsdienst - 3D
Seite 33 von 96
Bezeichnung
Klassifizierung
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Downloaddienst – Vektor (WFS)
services (feature access service)
INSPIRE:
Downloaddienst
GDI-DE :
obligatorisch ([4] Abschnitte 5.2.1.2 / 5.2.1.3 /
5.2.1.5)
Ein WFS liefert Geodaten im Format GML (Vektordaten, unpräsentiert). Die Selektion der gewünschten Daten erfolgt mit
den Mitteln von Filter Encoding (FE). Das den GML-Daten
zugrundeliegende Schema gibt der WFS als Response auf
den DescribeFeatureType Request als XML-Schema zurück.
Typ
 OGC WFS Implementation Specification 1.1.0 [39]
 OGC FE Implementation Specification 1.1.0 [40]
 OGC GML Encoding Specification 3.2.1 [41]
 Architekturkonzept GDI-DE ([4] Abschnitte 5.2.1.2 / 5.2.1.3
/ 5.2.1.5)
WFS NOL
Der WFS gibt die Daten im „eigenen“ Schema ab, wobei der
Verweis auf ein zentral registriertes Schema wünschenswert
wäre. Die Bedienung anderer Schemata erfordert eine Schematransformation. Diese Transformation von XML-Daten wird
als Dienst auf der GDI Sachsen-Plattform angeboten, wodurch die Bedienung spezieller Schemata möglich ist.
In der WFS Version 1.1.0 können die GML-Daten in verschiedenen CRS abgegeben werden. Unterstützt der WFS das angeforderte CRS und wird die Koordinatentransformation bereits innerhalb des WFS durchgeführt, kann die Transformation durch einen separaten Koordinatentransformationsdienst
entfallen. Zu beachten ist in diesem Fall, dass einheitliche
Transformationsparameter verwendet werden.
Ein transaktionaler WFS (WFS-T) dient als Schnittstelle für
den schreibenden Zugriff auf Datenquellen und ermöglicht
somit auch eine Dateneingabe an einem WFS-T Client.
WFS können auch als Gazetteer Services ausgeprägt sein
[31] und somit u. a. die Georeferenzierung geographischer
Namen unterstützen. In [15] zählt auch Gazetteer Services zu
den Downloaddiensten.
INSPIRE-Downloaddienste können auch implementiert sein
als Download vordefinierter Datensätze (Files) mittels Standard Internet Protokollen (z. B. FTP). Diese Variante wird
durch WPOS unterstützt (siehe Tabelle 5).
Tabelle 4: Downloaddienst - Vektor
Seite 34 von 96
Bezeichnung
Klassifizierung
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Web Pricing and Ordering Service (WPOS)
services (order handling service)
INSPIRE:
nicht klassifiziert (im GeoDRM Layer enthalten)
GDI-DE :
zukünftig ([4] Abschnitt 5.4.3.3)
Ein WPOS nennt die analogen und digitalen (Geo-)Produkte
eines Anbieters und stellt ausgewählte Metadaten sowie die
entsprechenden Preismodelle bereit. Nach Produktauswahlund Konfektionierung durch einen WPOS Client berechnet der
WPOS Einzel- und Gesamtpreise und legt anschließend alle
Parameter, die für die Bereitstellung, Bezahlung und Auslieferung der (Geo-)Produkte relevant sind, in einer XML-Datei
(XCPF-Datei) ab. Soweit digitale Produkte kostenfrei sind und
nicht konfektioniert werden müssen, unterstützt der WPOS
auch den Download dieser Produkte.
Typ
 Web Pricing & Ordering Service (WPOS), XML Configuration & Pricing Format (XCPF) [24]
eine Instanz beim GeoSN, weitere Instanzen (im Rahmen des
bestehenden OWS Hosting-Angebotes) auf der
E-Government-Plattform (jeweils im Aufbau)
keine
Tabelle 5: Web Pricing and Ordering Service
Bezeichnung
Klassifizierung
Beschreibung
Suchdienst (Katalogdienst, CSW (Catalogue Services for the
Web), Discovery Service)
services (catalogue service)
INSPIRE:
Suchdienst
GDI-DE:
obligatorisch ([4] Abschnitt 5.2.1.1)
Der Suchdienst ist die Schnittstelle zu Metadateninformationssystemen. Darin sind Metadaten zu Geodaten,
Geodatendiensten, Anwendungen und weiteren Ressourcen
mit Raumbezug gespeichert.
Die Schnittstelle des Suchdienstes lässt die Selektion nach
inhaltlichen und räumlichen Kriterien zu. Weiterhin wird eine
verteilte Suche unterstützt, so dass theoretisch die Suche in
beliebigen MIS-Topologien ermöglicht wird. Außerdem können bei der Datenabgabe konkrete Profilvorgaben berücksichtigt werden.
Typ/Instanz
Die abgegebenen Metadaten basieren konzeptuell auf ISO
19115 [54] und ISO 19119 [55], bzgl. der XML-Struktur der
abgegebenen Metadaten auf ISO 19139 [56].
Instanz
Seite 35 von 96
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
 OGC Catalogue Service [42]
 OpenGIS Catalogue Services Specification 2.0.2 - ISO
Metadata Application Profile (1.0.0) [6]
 DE-Profil des ISO19115/ISO19119 Anwendungsprofils für
OGC Web Catalogue Services (CSW-2.0) [7]
 Durchführungsbestimmung Metadaten [57]
 INSPIRE technical guidelines
GeoMIS.Sachsen, GeoMIS.Bund, geocatalog, INSPIRE Metadatencatalog, PortalU
Bezüglich der dienstebasierten Erschließung der sächsischen
Metadatenressourcen geht dieses Konzept von einem einzigen sächsischen Landesmetadatenknoten aus, der als Profil
der CSW-Schnittstelle des GeoMIS.Sachsen implementiert
ist.
Aus Sicht des Architekturkonzepts bleibt die gesamte
sächsische Metadatentopologie hinter diesem Knoten verborgen. Anforderungen aus INSPIRE/GDI-DE (und ggf. von weiteren Anwendungen) werden direkt durch diesen Knoten bedient. Insofern enthält dieses Konzept keine Festlegungen zu
einer sächsischen MIS-Topologie, zu Fragen der verteilten
Suche bzw. zum Zwischenspeichern der Metadaten oder zu
ggf. notwendigen Transformationen.
In einer GDI liegen Metadaten jedoch nicht ausschließlich in
MIS, sondern auch an anderen Stellen vor (vgl. 5.1.5.1.1).
Verantwortlich für die Metadaten sind jeweils die geodatenhaltenden Stellen und Dienstebetreiber, die damit auch für die
Konsistenz zwischen den Angaben zu sorgen haben.
Tabelle 6: Suchdienst
Seite 36 von 96
5.1.3.2
Externe Dienste
Wenn von übergeordneten GDI oder weiteren Service Providern extern bereitgestellte Dienste für den Betrieb der GDI Sachsen geeignet sind (Dienstequalität, insbesondere Performanz, Verfügbarkeit und Sicherstellung der Benutzung) so können
diese Dienste zentrale Dienste der GDI Sachsen unter Berücksichtigung von Wirtschaftlichkeitsaspekten 10 ersetzen. Der Aufbau solcher Dienste kann für die nächsten Jahre beispielsweise im Bereich der Processing Services erwartet werden, jedoch sind aktuell keine geeigneten Dienste im produktiven Einsatz bekannt.
Externe Dienste können weiterhin, wenn sie vergleichbare Inhalte über identische
Schnittstellen wie die sächsischen Dienste bereitstellen (und nicht kaskadierend auf
diese zugreifen), als Ausfallsicherung für die sächsischen Dienste fungieren und damit zur Erhöhung der Verfügbarkeit beitragen. Entsprechende Mechanismen wären
im Rahmen des Betriebskonzeptes zu beschreiben und einzurichten.
Stellvertretend sei hier ein Dienst beschrieben, der einen Zeitstempel zurückliefert.
Bezeichnung
Klassifizierung
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
TimeStamp Service
ISO 19119: Geographic processing services – temporal
INSPIRE:
nicht enthalten
GDI-DE:
nicht enthalten
Der Dienst gibt das aktuelle Datum und die aktuelle Zeit zurück. Dies ist für die Vergabe eines einheitlichen und synchronisierten Zeitstempels notwendig. Dieser kann einerseits
für Sicherheitsanforderungen, aber auch bei der Erstellung
von Geodokumenten oder Protokollen zum Einsatz kommen.
Instanz
In:
Der Request an den Dienst z. B. getTime enthält die Zeitzone
sowie zusätzliche Angaben wie Sommer-/Winterzeit. Ggf.
kann ein Dienst konfiguriert werden, der für Sachsen die aktuelle Zeit ohne Übergabe von Parametern übergibt.
Out:
Als Response wird die aktuelle Zeit im gewünschten Gebiet
als XML-built-in-Datentyp (XML-Standarddatentyp) geliefert.
Dabei werden die Parameter (Zeitzone usw.) ergänzend angegeben.
keine
http://www.earthtools.org/webservices.htm#timezone
keine
Tabelle 7: TimeStamp Service
10
Insofern ist die vorgenommene Unterscheidung in „zentrale“ [siehe 5.1.3.4] und „externe“ Dienste
im Rahmen dieses Konzeptes nicht zwangsläufig.
Seite 37 von 96
5.1.3.3
Externe Registry Services
Es kann davon ausgegangen werden, dass in überschaubarer Zeit übergeordnete
Registries (aus INSPIRE/GDI-DE) mit den zugehörigen Registry Services zu geospezifischen Datentypen aufgebaut werden. Wenn die benötigte Qualität und die Benutzung sichergestellt sind, ist der Verwendung dieser übergeordneten Registry Services der Vorzug gegenüber dem Aufbau eigener Registries und Dienste zu geben.
In diesem Zusammenhang ist zu prüfen, inwieweit Registries, die in Sachsen im
Rahmen des allgemeinen E-Government aufgebaut werden, benutzt werden können.
5.1.3.4
Zentrale Dienste
In diesem Gliederungspunkt werden diejenigen Dienste beschrieben, die für den
Zweck der sächsischen Geodateninfrastruktur notwendig und nicht bereits durch die
dezentralen Basisdienste abgedeckt sind. Wie bereits unter 5.1.3.2 ausgeführt, können zentrale Dienste bei Eignung durch externe ersetzt werden. Zentrale Dienste
werden auf einer GDI Sachsen-Plattform 11 betrieben und durch ein Service Management verwaltet.
Bestimmte spezialisierte Dienste stellen Schnittstellen bereit, die als „Fassade“ bezeichnet werden. Hinter Fassaden verbergen sich Dienste gleichen oder unterschiedlichen Typs. Ein Beispiel für einen solche Fassade wäre also eine INSPIREDownload-Fassade, die gemäß der Datenanforderung aus INSPIRE sächsische
WFS kaskadiert, deren Ergebnisse transformiert und unmittelbar die INSPIRE
interfaces bedient.
Ein weiterer Dienstetyp ist „sächsische OWS-Kaskade“. Im Falle von OGC WMS aggregiert eine solche WMS-Kaskade eine bestimmte Menge sächsischer WMS. WMS
Clients werden dadurch vom Zusammenfügen der Dienste, von notwendigen Transformationen und Bildüberlagerungen entlastet.
Die Mehrzahl der hier beschriebenen zentralen Dienste greift auf dezentrale
Basisdienste zu, so dass eine Dienstekette entsteht und Netzsegmente außerhalb
der zentralen GDI Sachsen-Plattform benutzt werden. Eine solche Konstellation ist
grundsätzlich als performanzkritisch einzuschätzen. Die Benutzung dezentraler oder
externer Dienste muss jedoch nicht zwangsläufig zur Laufzeit der Client-Anwendung
erfolgen. Insbesondere unter den Gesichtspunkten „Verfügbarkeit“ und „Performanz“
können ein zeitversetztes Aufrufen der Dienste und das clientseitige Zwischenspeichern der Ergebnisse („Harvesting“ bzw. „Caching“) sinnvoll sein. Dem so erreichten
Performanzgewinn stehen ein unter Umständen erheblich gestiegener Ressourcenbedarf (Speicherplatz und Verarbeitungskapazität) und eine eingeschränkte Aktualität der Daten gegenüber. Entsprechende Entwurfsentscheidungen sind im Zusammenhang mit der Implementierung zu treffen. Aus der dieses Grobkonzept dominierenden fachlichen und funktionalen Sicht sind jedoch Komponenten zum Zwischen11
In diesem Konzept wird nicht diskutiert, ob die hier abstrakt genannte GDI Sachsen-Plattform als
Teil der sächsischen E-Government-Plattform implementiert wird. Ebenfalls nicht betrachtet wird das
Verhältnis der existierenden GeoBAK-Dienste zu den hier definierten Diensten.
Seite 38 von 96
speichern (bis hin zu „Geodata-Warehouses“) nicht erforderlich, sondern bleiben (in
der Auflösungsstufe eines Grobkonzeptes) zunächst hinter den DiensteSchnittstellen verborgen. Eine Ausnahme von dieser Sichtweise bildet die Beschreibung des Tile Caching Service [siehe Tabelle 12].
Standardmäßig sollen alle Dienste als Protokoll SOAP unterstützen und werden
durch ein WSDL-Dokument beschrieben.
Weiterhin sei erneut darauf hingewiesen, dass die nachfolgende Aufzählung von
Diensten und Diensttypen nicht abschließend ist.
5.1.3.4.1 Darstellungs- und Downloaddienste 12
Bezeichnung
Klassifizierung
Beschreibung
OWS Hosting
ISO 19119: verschiedene Typen
INSPIRE:
verschiedene Typen
GDI-DE:
verschiedene Typen
Das OWS Hosting stellt Geodaten über OWS bereit, welche
von den Anbietern nicht über eigene OWS bereitgestellt werden. Die zugehörigen Geodaten liegen dabei i. d. R. als Kopien der Originaldaten zentral auf der GDI Sachsen-Plattform
und sind in einem definierten Prozess zu aktualisieren.
Als OWS-Typen sind mindestens WMS, WFS, WCS und
WPOS vorzusehen.
Im Unterschied zu den dezentralen OWS-Diensten sollten die
Diensteimplementierungen auf GDI Sachsen bereits die Anforderungen von übergeordneten GDI (z. B. unterstützte Referenzsysteme, Grafikformate) weitestgehend erfüllen, um unnötige Transformationen zu vermeiden. Dies stellt gleichermaßen bestimmte Anforderungen an die gelieferten Ausgangsdaten.
Die Anbindung an INSPIRE erfolgt jedoch nicht über das
OWS Hosting, sondern über die INSPIRE/GDI-DE – Knoten.
Typ/Instanz
Schnittstellen
Anbieter analoger und digitaler, kostenpflichtiger und kostenfreier (Geo-)Produkte können diese über einen zentralen
WPOS vertreiben. Voraussetzung ist, dass diese Ressourcen
WPOS-konform beschrieben sind (XCPF-Format) und ggf.
Web Services für (aus der Sicht des WPOS externe) Berechnungen, die beispielsweise zur Preisberechnung direkt auf
den Daten ausgeführt werden müssen, bereit stehen.
„Metatyp“
gemäß den jeweiligen OGC-Spezifikationen
12
Bei den hier aufgeführten „Metatypen“ OWS Hosting, OWS-Kaskade und INSPIRE/GDI-DE – Fassade handelt es sich mehrheitlich um Darstellungs- und Downloaddienste. Sie wurden daher diesem
Abschnitt zugeordnet.
Seite 39 von 96
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
OGC-Spezifikationen entsprechend OWS-Typ
Geofachdatendienst des SID
Die hier enthaltenen Darstellungs- und Downloaddienste werden auf der GDI Sachsen-Plattform auch benutzt, um innerhalb von Diensteketten Geodaten über die OGC-Schnittstellen
bereitzustellen.
Tabelle 8: OWS Hosting
Bezeichnung
Klassifizierung
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
OWS-Kaskade
INSPIRE:
verschiedene Typen
GDI-DE:
verschiedene Typen
Die OWS-Kaskade aggregiert ausgewählte OWS. Soweit
notwendig, werden dazu Transformationsdienste integriert.
Als OWS-Typen sind mindestens WMS, WFS und WCS vorzusehen.
„Metatyp“
gemäß den jeweiligen OGC-Spezifikationen
OGC-Spezifikationen entsprechend OWS-Typ
 GeoBAK WMS-Kaskade
 GDI-DE – Projekt Schutzgebiete
Unter einer OWS-Kaskade wird hier der am Ausgang der
Kaskade angebotene Dienst, nicht die gesamte Kaskade einschließlich der eingebundenen Dienste verstanden.
OWS-Kaskaden werden umgangssprachlich auch als OWS
Proxy bezeichnet.
Tabelle 9: OWS-Kaskade
Bezeichnung
Klassifizierung
Beschreibung
INSPIRE/GDI-DE – Fassade
INSPIRE:
verschiedene Typen
GDI-DE:
verschiedene Typen
Die INSPIRE/GDI-DE – Fassaden stellen übergeordneten
GDI die geforderten Zugriffspunkte auf sächsische Geodatendienste bereit.
I. d. R. werden dazu OWS eingebunden, unter Ausführung
der notwendigen Transformationen aggregiert sowie die durch
die übergeordneten GDI geforderten Schnittstellen bedient.
Als Diensttypen sind mindestens Darstellungsdienste und
Downloaddienste (Vektor-WFS, Raster-WCS) entsprechend
den Vorgaben aus INSPIRE/GDI-DE vorzusehen.
Typ/Instanz
Auch beim sächsischen INSPIRE Discovery Service
(Landesmetadatenknoten) handelt es sich um eine Fassade.
„Metatyp“
Seite 40 von 96
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
gemäß den jeweiligen INSPIRE/GDI-DE - Spezifikationen
 INSPIRE Network Services Architecture [15]
 INSPIRE technical guidelines
nicht produktiv: Geodatenkatalog - DE
Aus der Sicht der Netztopologie können Fassaden auch als
Knoten gesehen und entsprechend bezeichnet werden werden.
Tabelle 10: INSPIRE/GDI-DE – Fassade
Bezeichnung
Klassifizierung
Beschreibung
Portrayal Service
ISO 19119: Geographic processing services
INSPIRE:
nicht enthalten
GDI-DE :
nicht enthalten
Der „Portrayal Service“ wandelt unpräsentierte Geodaten in
Grafikdaten um und rendert diese (optional). Als Datenquelle
dienen dem Portrayal Service WFS, WCS oder GML-Daten.
Werden Grafikdaten angefordert, so ruft der Dienst den XMLSchematransformationsdienst auf und liefert im Ergebnis der
Stylesheet-Transformation das SVG-Format. Werden Bilddaten angefordert, so werden die verbreiteten Formate (mindestens PNG und JPG) unterstützt.
Die Darstellung wird durch Zeichenvorschriften auf der Basis
von OGC Symbology Encoding (SE) [27] gesteuert.
Da der Dienst GML-Daten mit einer Symbolisierung versehen
kann, kann er weiterhin für die Visualisierung von z. B. location markers genutzt werden.
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Der Dienst ist unter Benutzung des
Koordinatentransformationsdienst – Feature bzw. – Image
weiterhin in der Lage, unterschiedliche CRS zu unterstützen.
Instanz
 OGC WMS Version: 1.0.0 - 1.3.0 ([33], [34], [35]) /
ISO 19128
 OGC SLD [36]
 OGC SE [27]
 OGC GML [41]
Component SLD-WMS in GDI Frameworks
Bei Component SLD-WMS handelt es sich um SLD-fähige
WMS, die Remote WFS/WCS bzw. InlineFeature (für GML)
unterstützen. Die darzustellenden Geodaten werden durch
den WMS Client spezifiziert. Somit kann der WMS in der Rolle
eines Feature bzw. Coverage Portrayal Service
(„Darstellungsdienst“) genutzt werden.
Tabelle 11: Portrayal Service
Seite 41 von 96
Bezeichnung
Klassifizierung
Beschreibung
Tile caching Service
INSPIRE:
Darstellungsdienst
GDI-DE :
nicht enthalten
Tile caching Services stellen Bilddaten als vorprozessierte
Kacheln in festen Maßstabsstufen zur Verfügung.
Die Ressourcenschicht der Tile Services kann durch die
dezentralen WMS gebildet werden.
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Tile Services werden für auszuwählende Daten (beispielsweise Luftbilder) aufgebaut.
Typ
In:
URL mit Adresse der Kachel
Out:
Bilddaten als Kachel
OGC Tiled WMS [32]
Themenstadtplan Dresden (tile server (proprietär))
Der Tile caching Service verarbeitet Bilder vor und speichert
sie zwischen (Speichern von Bildpyramiden). Damit können
erhöhte Performanzanforderungen von Karten-Clients erfüllt
werden.
Der Service als zentraler Dienst kann für diejenigen Daten
entfallen, bei denen die geodatenhaltende Stelle den Tile caching Service selbst anbietet.
Es existiert ein OGC discussion paper [32], in dem ein „Tiled
WMS“ als Erweiterung des bekannten OGC WMS beschrieben wird. Auf diese Entwicklung wird auch durch INSPIRE
[49] referenziert.
Tabelle 12: Tile caching Service
Seite 42 von 96
Bezeichnung
Klassifizierung
Beschreibung
Geodokumente-Dienst
INSPIRE:
nicht enthalten
GDI-DE :
nicht enthalten
Ein Geodokument besteht aus einer Karte und optional zusätzlichen Elementen (Legende, Nordpfeil, Copyright, Wasserzeichen, location marker, Metadaten).
Der Geodokumente-Dienst greift auf die dezentralen WMS
bzw. auf die zentralen Darstellungsdienste zu.
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Die Formatierung des Geodokuments wird durch Formatvorlagen unterstützt. Das Standardformat des Geodokuments ist
PDF.
Instanz
In:
 Spezifizierung der Karte in Anlehnung an einen GetMapRequest
 optional Position (direkt/indirekt) des location markers
 Auswahl der weiteren Elemente (siehe oben)
 Auswahl einer Formatvorlage
Out:
Geodokument
GeoBAK Grobkonzept [48]
GeoBAK Geodokumente-Dienst
keine
Tabelle 13: Geodokumente-Dienst
Seite 43 von 96
5.1.3.4.2 Transformationsdienste
„Transformationsdienste“ ist die übergreifende Bezeichnung für eine Menge verschiedener Diensttypen. In [18], Folie 16 wird unterschieden zwischen Formattransformationen (format transformations), Sprachübersetzungen (language translations),
geometrischen Transformationen (geometric transformations) und Schematransformationen (schemas translations).
Die Transformationsdienste werden hier funktional beschrieben. In diesem Zusammenhang wird zunächst nicht unterschieden, ob ein Transformationsdienst innerhalb
eines anderen Dienstes eingebettet ist (z. B. der Koordinatentransformationsdienst –
Feature innerhalb eines WFS) oder als eigenständiger Dienst implementiert ist 13 .
Ebenfalls nicht unterschieden wird die Verwendung der Transformationsdienste für
„on-the-fly“-Transformationen oder für offline-Transformationen.
Bezeichnung
Klassifizierung
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Koordinatentransformationsdienst – Feature
ISO 19119: Geographic processing services – spatial
(coordinate conversion/transformation service)
INSPIRE:
Geometrische Transformation
GDI-DE:
nicht enthalten (vgl. Fußnote 13)
Der Dienst führt eine geometrische Transformation von Vektordaten (GML) zwischen verschiedenen Referenzsystemen
durch. Um einheitliche Transformationen sicherzustellen, sollte der Dienst auf eine Registry mit CRS-Transformationsparametern zugreifen.
Instanz
In:
 GML-Datei
 Ziel-CRS
 Transformationsverfahren und -parameter bzw. Verweis
auf Registry-Eintrag
Out:
Output-GML-Datei
 ISO 19111 [45]
 OGC WCTS, Version 0.3.0, 08-013 (verworfen) [50]
 Koordinatentransformation Web Service des BKG
http://www.bkg.bund.de bzw. http://crs.bkg.bund.de/crs-eu/
 WCTS in GDI Frameworks
Koordinatentransformationsdienste werden als Web Coordinate Transformation Services (WCTS) bezeichnet und aktuell
als Profile von Web Processing Services (WPS) angesehen.
Für die Datenabgabe in einem europäischen Referenzsystem
ist eine einheitliche Transformation notwendig.
Tabelle 14: Koordinatentransformationsdienst – Feature
13
Sichtweise GDI-DE: „Eine dabei eventuell erforderliche Transformation soll in der GDI-DE bereits
bei der Datenabgabe erfolgen. Deshalb werden hier keine eigenständigen Transformationsdienste
spezifiziert.“ [4]
Seite 44 von 96
Bezeichnung
Klassifizierung
Koordinatentransformationsdienst – Coverage/Image
ISO 19119: Geographic processing services – spatial
(image conversion service)
INSPIRE:
Geometrische Transformation
GDI-DE:
nicht enthalten (vgl. Fußnote 13, Seite 44)
Der Dienst führt eine geometrische Transformation von georeferenzierten Rasterdaten zwischen verschiedenen Referenzsystemen durch.
Beschreibung
Transformationen von Rasterdaten beinhalten Verfahren zum
Resampling. Um einheitliche Transformationen sicherzustellen, sollte der Dienst auf eine Registry mit CRSTransformationsparametern zugreifen.
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Bilddaten sind spezielle Rasterdaten.
Instanz
In:
 Raster-Datei
 Ziel-CRS
 Transformationsverfahren und -parameter bzw. Verweis
auf Registry-Eintrag
 Resamplingmethode
 Parameter der Output-Datei (z. B. Format, Parameter zu
Komprimierung)
Out:
Output-Datei
siehe Tabelle 14
nicht bekannt
Koordinatentransformationsdienste für Rasterdaten können
ebenfalls als Profile von Web Processing Services (WPS) angesehen werden.
Es ist möglich, dass in Randnähe Bereiche (Keile) entstehen,
welche nach der Bildtransformation keine Rasterwerte enthalten. Wenn möglich, kann dies durch die Transformation eines
entsprechend größeren Gebietes in der Ausgangsdatei vermieden werden. Alternativ sind die „leeren“ Bereiche mit sinnvollen Werten zu füllen (bei Bilddaten in Abhängigkeit vom
Bildformat transparent setzen).
Tabelle 15: Koordinatentransformationsdienst – Coverage/Image
Seite 45 von 96
Bezeichnung
Klassifizierung
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
(XML-)Schematransformationsdienst
ISO 19119: Geographic communication services
(geographic format conversion service)
INSPIRE:
Schematransformation
GDI-DE:
nicht enthalten
In einer Infrastruktur, in der der Austausch von Daten auf XML
basiert, sind Konvertierungen von XML-Daten mittels XSLTransformation von zentraler Bedeutung.
Anwendungen für diesen Dienst sind z. B. Schematransformation mit dem Ziel der virtuellen Harmonisierung von Geodaten, die Erzeugung von Grafikdaten aus GML oder die Generierung der Beschreibung der Portale im GDI Sachsen-Portal
aus den CSW-Daten des Landesmetadatenknoten.
Instanz
In:
 XML-Datei
 XSchema des Ziels
 XSL mit Abbildungsregeln
 optional Auswahl des XSLT-Prozessors
Out:
Textdatei
W3C XSL-Standards (http://www.w3.org/Style/XSL/)
XSL-Transformationen sind Standard-IT-Technologie und
werden durch XSLT-Prozessoren bereitgestellt. XSLTProzessoren werden von mehreren Anbietern zur Verfügung
gestellt. Der XML-Transformationsdienst kapselt deren Funktionalität als Dienst.
Die Funktionalität verschiedener XSLT Prozessoren (z. B.
Saxon, Altova, Oracle) bzw. deren Versionen unterscheidet
sich, so dass für bestimmte Transformationsaufgaben der geeignete Prozessor ausgewählt werden sollte.
Tabelle 16: (XML-)Schematransformationsdienst
Seite 46 von 96
Bezeichnung
Klassifizierung
Formattransformationsdienst – Coverage/Image
(geographic format conversion service)
INSPIRE:
Formattransformation
GDI-DE:
nicht enthalten
Der Dienst transformiert Rasterformate (PNG, JPG, GIF,
TIFF, ...). Er wird i. d. R. von anderen Darstellungsdiensten
benutzt.
Beschreibung
Bilddaten sind spezielle Rasterdaten.
Instanz
In:
 Rasterdatei
 Format der Input-Rasterdatei
 Darstellungsparameter (z. B. Transparenz)
 Format der Output-Datei
Out:
Output-Datei
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
z. B. innerhalb von WMS-Kaskaden
keine
Tabelle 17: Formattransformationsdienst – Coverage/Image
5.1.3.4.3 Dienste zum Abrufen von Geodatendiensten
Wie bereits unter 4.4.2 ausgeführt, sind „Dienste zum Abrufen von Geodatendiensten“ Dienste, die im Ergebnis einer Orchestrierung entstanden sind und insofern eine
Kette von Diensten geringerer Komplexität repräsentieren.
Die Beschreibung des neuen Prozesses, in dem die einzelnen Dienste zusammengefügt werden, erfolgt in der Business Process Execution Language (BPEL) und wird
durch eine Reihe grafischer Tools unterstützt. Der so definierte BPEL-Prozess, und
damit der neu definierte Dienst, kann dann (theoretisch) auf einer beliebigen BPELEngine (auch „BPEL Server“) ausgeführt werden. Eine solche BPEL Engine ist auf
der GDI Sachsen-Plattform zu installieren. Sie wird dann in erster Linie zur Bereitstellung von Diensteketten auf der GDI Sachsen-Plattform verwendet. Darüber hinaus
soll die BPEL-Engine auch für eine dezentrale Benutzung zur Verfügung stehen. 14
Die hier skizzierte Technologie setzt voraus, dass die zu verknüpfenden Dienste mittels WSDL [12] beschrieben sind sowie das SOAP-Protokoll [13] benutzen. Beide
Technologien werden gegenwärtig schrittweise auf OWS angewendet (z. B. in CSW
Applikation Profile, [6]). Dabei ist die WSDL-Beschreibung zwingend erforderlich, das
SOAP-Wrapping kann mit eingeschränkter Funktionalität auch durch die Tools selbst
erfolgen, so dass auch ein Anbinden HTTP GET/POST - basierter Dienste prinzipiell
möglich ist.
14
Dies ist im Lizenz- und Bepreisungsmodell zu regeln.
Seite 47 von 96
Die Schnittstellen der orchestrierten Dienste werden wiederum per WSDL beschrieben. Die Erstellung dieser WSDL-Datei erfolgt im Allgemeinen durch das Orchestrierungstool.
Die Nutzung der orchestrierten Dienste erfolgt entweder durch andere Dienste über
das SOAP interface der neu entstanden Dienste bzw. über Clients, die im Zuge der
Orchestrierung durch die BPEL-Engine oder durch eine Auswertung der WSDL-Datei
erzeugt werden.
Die WSDL-Datei und weitere Metadaten zum Dienst werden im zentralen Diensteverzeichnis (vgl. 5.1.5.3.3) eingetragen. Soweit es sich beim neu entstandenen
Dienst um einen Geodatendienst handelt, sind die Metadaten zum Dienst im
GeoMIS.Sachsen einzutragen.
5.1.3.4.4 Weitere Dienste
Bezeichnung
Klassifizierung
Beschreibung
Protokoll-Wandlung HTTP GET/POST  SOAP (bidirektional)
INSPIRE:
nicht enthalten
GDI-DE:
nicht enthalten (nur im Zusammenhang mit
Zugriffskontrolldienst, [4] Abschnitt 5.3.1.3)
Die Forderung nach der Verwendung von SOAP als Transportprotokoll ergibt sich aus mehreren Gründen:
 SOAP ist das Standard-Protokoll einer auf Web Services
basierenden SOA.
 Die Voraussetzungen zur Integration von GI-Diensten in
allgemeinen IT-Umgebungen werden verbessert.
 Aus INSPIRE und dem OGC heraus existieren gegenwärtig Absichtserklärungen bzw. Untersuchungen mit dem
Ziel, diese Standards perspektivisch verwenden zu wollen
(vgl. [51] und [52]).
In Richtung HTTP GET SOAP wird die empfangene URL so
zerlegt, dass die KVP als XML-Struktur abgebildet werden.
Typ/Instanz
Schnittstellen
Diese Abbildung kann nach unterschiedlichen Ansätzen erfolgen. Für die weitere Verwendung innerhalb der SOA ist eine
typspezifische XML-Struktur mit entsprechendem XSchema
aufbauend auf bereits vorhandenen OGC Standards wie z. B.
GML oder ISO 19139 vorzuziehen.
Instanz
In:
HTTP GET/POST - Nachricht
Out:
SOAP-Nachricht mit WSDL-Beschreibung
bzw. umgekehrt
Seite 48 von 96


Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
OWS 5 SOAP/WSDL Common Engineering Report [21]
OpenGIS Wrapping OGC HTTP-GET and -POST Services
with SOAP [20]
 OWS 1.2 SOAP Experiment Report [46]
 INSPIRE Network Services SOAP Framework [52]
Teilweise wird SOAP direkt durch OWS-Implementierungen
unterstützt.
Um unnötige Wiederholungen von Protokollwandlungen zu
vermeiden, sollte die Unterstützung von SOAP in der Prozesskette möglichst frühzeitig umgesetzt werden. Idealerweise unterstützen die dezentralen Basisdienste bereits diese
Kommunikationsschnittstelle. Insofern ist dieser Protokollwandlungsdienst in den Serverkomponenten enthalten, die
die GDI Sachsen den Betreibern dieser Dienste zur Verfügung stellt. Sollte dieses Angebot nicht genutzt werden, so
erfolgt die Wandlung auf der GDI Sachsen-Plattform.
Falls perspektivisch alle OWS über SOAP interfaces verfügen, ist der Dienst entbehrlich.
Tabelle 18: Protokoll-Wandlung HTTP GET/POST  SOAP
Seite 49 von 96
Bezeichnung
Klassifizierung
Beschreibung
Order Service
services (order handling service)
INSPIRE:
nicht klassifiziert (im GeoDRM Layer enthalten)
GDI-DE :
zukünftig ([4] Abschnitt 5.4.3.3)
Der Order Service ist (im Zusammenspiel mit dem
GeoMIS.Sachsen und den WPOS) die Grundlage für die Bestellung und ggf. Bepreisung von analogen und digitalen
(Geo-)Produkten.
Der Dienst unterstützt dabei auch die Bereitstellung von Daten insbesondere in vordefinierter (konfektionierter) Form sowie in proprietären Formaten (im Unterschied zum
Downloaddienst WFS). In dieser Rolle gehört der Order
Service entsprechend der INSPIRE Taxonomie ebenfalls zu
den Downloaddiensten.
Der Order Service ist das serverseitige Gegenstück zum Order Client (vgl. 5.1.2.4). Am Order Service sind die
sächsischen WPOS einschließlich des WPOS Hosting angeschlossen. Der Order Service aggregiert diese WPOS in
schwacher Form (gemeinsame Bestellungen über Anbietergrenzen hinweg sind nicht vorgesehen) und wertet die XCPFDateien aus. Gegenüber diesen WPOS ist der Order Service
in der Rolle des Client.
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Weiterhin bindet der Order Service die E-GovernmentBasiskomponente „Zahlungsverkehr“ ein.
Instanz
proprietäre Schnittstelle zum Order Client
 Web Pricing & Ordering Service (WPOS), XML Configuration & Pricing Format (XCPF) [24]
 Architekturkonzept GDI-DE ([4] Abschnitt 5.4.2)
GeoBAK Stufe 4
Eine Trennung der Funktionalität zwischen Order Service und
Order Client ist nicht zwangsläufig erforderlich.
Dienste zur Abwicklung eines elektronischen Geschäftsverkehrs sind von INSPIRE gefordert.
Tabelle 19: Order Service
Seite 50 von 96
Bezeichnung
Klassifizierung
Dienst zur Konsistenzprüfung der Dienste-Metadaten
ISO 19119: Geographic processing services – metadata
INSPIRE:
nicht enthalten
GDI-DE:
nicht enthalten
Innerhalb der GDI Sachsen liegen Metadaten zu Diensten
neben dem GeoMIS.Sachsen an verschiedenen Stellen vor
(zentrales Diensteverzeichnis inkl. WSDL-Datei, Capabilities.xml, XCPF-Datei der WPOS), die nicht in die Topologie
des GeoMIS.Sachsen eingebunden sind. Daher sind Widersprüche in den Metadaten infolge dieser Redundanz zu erwarten.
Beschreibung
Der hier beschriebene Dienst soll der geodatenhaltenden
Stelle, die für die Konsistenz „ihrer“ Metadaten verantwortlich
ist, unterstützen. Der Dienst wird durch die geodatenhaltende
Stelle aufgerufen oder zyklisch gestartet. Die geodatenhaltende Stelle erhält einen Bericht.
Die Metadatenelemente der genannten Quellen mit identischer Semantik werden verglichen und Abweichungen in einem Bericht zusammengestellt.
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Der Client zum Dienst ist Bestandteil der AdministrationsClients der GDI Sachsen (siehe 5.1.1.6).
Instanz
In:
Links zu den zu vergleichenden Ressourcen
Out:
Prüfbericht
Architekturkonzept GDI-DE ([4] Abschnitt 5.2.2.2)
nicht bekannt
Eine Prüfung setzt ein Mapping der Metadatenelemente der
verschiedenen Quellen sowie ein gemeinsames Verständnis
bzgl. deren Semantik voraus.
INSPIRE fordert die Synchronisierung der Metadaten zwischen der Dienstebeschreibung und der Angaben im MIS.
GDI-DE verlangt widerspruchsfreie Dienste-Metadaten.([4],
Seite 42)
Tabelle 20: Dienst zur Konsistenzprüfung der Dienste-Metadaten
Seite 51 von 96
Bezeichnung
Klassifizierung
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Web Processing Service (WPS)
ISO 19119: Geographic processing services
INSPIRE:
nicht enthalten
GDI-DE:
nicht enthalten
WPS können unterschiedliche Methoden zur Verarbeitung
raumbezogener Daten zur Verfügung stellen. Zu nennen sind
z. B. Koordinatentransformation, Verschneidungen, Pufferungen oder Schwerpunktberechnungen.
Ggf. kann eine Aufteilung der WPS-Instanz in mehrere Instanzen, die jeweils genau eine GI-Methode implementiert
haben, erfolgen.
Metatyp
gemäß Bezugsdokument
OpenGIS Web Processing Service [25]
ArcGIS Server (proprietär)
keine
Tabelle 21: Web Processing Service
Weiterhin benutzt die GDI Sachsen allgemeine E-Government-Querschnittsdienste,
wie sie beispielsweise als Basiskomponenten auf der E-Government-Plattform des
Freistaats Sachsen angeboten werden. Neben dem zentralen CMS, mit dem die statischen Inhalte des GDI Sachsen-Portals gepflegt werden können, ist die Basiskomponente „Zahlungsverkehr“ zu nennen, die durch den Order Service genutzt wird.
5.1.3.4.5 Registry Services
Der Registry Service dient der Nutzung und Pflege der unter 5.1.5.3.1 beschriebenen
Register bzw. der zugehörigen Registries.
Die hier vorgenommene Zuordnung zu den zentralen Diensten ist willkürlich. Vorzugsvariante ist die Mitbenutzung von übergeordneten Registry Services.
Seite 52 von 96
Bezeichnung
Klassifizierung
Beschreibung
Typ/Instanz
Schnittstellen
Bezugsdokumente
Registry Service
services (Registry Services)
INSPIRE:
Registerdienst
GDI-DE:
zukünftig ([4] Abschnitt 5.4.2)
Der Registry Service erlaubt die Recherche in Registries sowie die Pflege der Registry-Inhalte.
Instanz oder Typ
In 5.1.5.3.1 wird ausgeführt, dass für die sächsische Geodateninfrastruktur eine hierarchische, mehrteilige Registry mit
den entsprechenden Service interfaces benötigt wird. Alternativ wäre die Implementierung mehrerer Instanzen, z. B. entsprechend der Zuständigkeiten für unterschiedliche Register,
möglich. Aus technischer Sicht ist dies jedoch nicht erforderlich.
Die Beschreibung von Registries auf konzeptueller Ebene ist
enthalten in
 ISO 19135 [30]
 OASIS/ebXML Registry Information Model v2.0 [28]
Implementierungsspezifikation sind
 OASIS/ebXML Registry Services Specification v2.5 [53]
 OGC Catalogue Service – ebRIM profile of CSW [47]
In [29] wird die Verwendbarkeit der beiden Spezifikationen für
GI-spezifische Registries diskutiert.
Implementierungen/
Anwendungen
Bemerkungen
 Architekturkonzept GDI-DE ([4] Abschnitt 5.4.2)
AdV Registry Prototyp
Registry Services definieren nicht den Zugriff auf die Ressourcen (z. B. CRS-Beschreibungen) selbst, sondern enthalten lediglich Metadaten zur eindeutigen Identifizierung der
Elemente innerhalb der Ressource sowie ggf. einen Verweis
(z. B. durch einen Link) auf den Eintrag innerhalb der Ressource. Ressourcenspezifische Abfragen (etwa: „Welche CRS
basieren auf dem Bessel-Ellipsoid?“) können durch Registry
Services nicht beantwortet werden.
In stark vereinfachter Form und übergangsweise können
Registry Services auch durch den direkten Zugriff auf eine
Webressource implementiert sein.
Tabelle 22: Registry Service
Seite 53 von 96
5.1.3.4.6 GeoDRM Services
Die GeoDRM Services werden gemeinsam mit den anderen Security-Komponenten
im Abschnitt 5.1.6 beschrieben.
5.1.3.5
Service Management nach ITIL 15
5.1.3.5.1 IT Infrastructure Library (ITIL)
Die ITIL wurde von der CCTA (Central Computer and Telecommunications Agency),
heute OGC (Office of Government Commerce) entwickelt. CCTA und OGC sind
Dienstleistungsorganisationen der britischen Regierung. ITIL ist Eigentum des Office
of Government Commerce. Seit Anfang Juni 2007 ist die Version 3 gültig. ITIL ist ein
de-facto Standard in der IT-Verwaltung und wird von SAGA [5] empfohlen. Daher
sollen die für die Umsetzung dieses Konzeptes notwendigen IT-Dienste ITIL-konform
erbracht werden. Auf dieser Grundlage sollte die Zertifizierung der durch GDI Sachsen erbrachten Dienste nach der einschlägigen ISO-Norm (derzeit ISO 20000) angestrebt werden. Gegenwärtig wird ITIL beispielsweise im Rahmen des Betriebs der
E-Government-Plattform des Freistaats Sachsen eingesetzt.
Übergreifendes Ziel des Einsatzes von ITIL ist eine bessere Ausrichtung der ITOrganisation an den Geschäftsprozessen und Anforderungen des Kunden. Weitere
Ziele sind:
 IT-Dienstleistungen, die den Anforderungen entsprechen,
 höhere Kundenzufriedenheit,
 weniger Aufwand bei der Entwicklung von Prozessen, Prozeduren und Arbeitsanweisungen,
 höhere Produktivität und der gezielte Einsatz von Wissen und Erfahrung,
 Bereitstellung einer Grundlage für eine QM-Systematik im IT Service Management,
 bessere Kommunikation und Information zwischen den IT-Mitarbeitern und ihren
Kunden sowie
 höhere Mitarbeiterzufriedenheit und niedrigere Personalfluktuation.
Zur Erreichung dieser Ziele sind innerhalb von ITIL Konzepte und Rahmenrichtlinien
(Frameworks) von IT-Spezialisten aus der Praxis für die Praxis (best practices) beschrieben. Dabei wird hauptsächlich dargestellt, welche Maßnahmen ergriffen werden müssen, weniger wie diese realisiert werden sollen. Insofern werden diese Maßnahmen durch ITIL mit einem hohen Abstraktionsgrad beschrieben und müssen im
Rahmen eines konkreten Projekts spezialisiert werden.
Zentraler Begriff in ITIL ist der des „IT-Service“, der für einen oder mehrere Kunden
von einem Service Provider bereitgestellt wird, aus einer Kombination von Personen,
Prozessen und Technologie besteht sowie in einem Service Level Agreement (SLA)
definiert werden sollte. ITIL beschreibt den gesamten Lebenszyklus des Dienstes,
15
Die Beschreibung des Service Management gehört genaugenommen nicht zur funktionalen Sicht
nach RM-ODP, sondern zur Sicht auf die Infrastruktur (Engineering Viewpoint) bzw. in das Betriebskonzept.
Seite 54 von 96
angefangen von der Strategie (Service Strategy) über das Design (Service Design),
der Überführung in den Betrieb (Service Transition) zum operationellen Betrieb
(Service Operations). Diese Phasen sind umschlossen von einem kontinuierlichen
Verbesserungsprozess (Continual Service Improvement).
Zur Kontrolle der Wirksamkeit der Prozesse werden Kennzahlen erhoben und ausgewertet. Diese Kennzahlen sind teils in ITIL dokumentiert, sollen aber von jeder Organisation detaillierter spezifiziert werden.
5.1.3.5.2 Zentrale Dienste der GDI Sachsen
In Anlage 1 werden Phasen, Prozesse und Kennzahlen der Dienste beschrieben, die
in direkter Verantwortung der GDI Sachsen erbracht werden. Die Tabelle unterteilt
die o. g. Phasen (grau unterlegt) innerhalb des Dienste-Lebenszyklus in einzelne
Prozesse und nennt beispielhaft wichtige Kennzahlen.
Im Betriebskonzept sind Verantwortlichkeiten für die einzelnen Prozesse entsprechend den Vorgaben aus ITIL festzulegen.
5.1.3.5.3 Dezentrale Geodatendienste
Bezüglich dezentraler Geodatendienste befindet sich die GDI Sachsen in der Rolle
eines Kunden. Dezentrale Dienste selbst werden nicht durch ITIL Prozesse der GDI
Sachsen-Plattform verwaltet. Im Rahmen von Vereinbarungen über die Qualität der
Dienste (Operational Level Agreements – siehe oben) soll für betroffene Dienste deren Qualität sichergestellt werden. Das Monitoring der entsprechenden Kennzahlen
kann durch die GDI Sachsen erfolgen.
Der für die GDI Sachsen-Plattform aufzubauende Service Desk sollte zu einem zentralen Ansprechpartner für alle Dienste der sächsischen Geodateninfrastruktur profiliert werden. Die auf diesem Weg initiierten Fragen, Störungsmeldungen und Probleme sind ggf. an die Betreiber dezentraler Geodatendienste weiterzuleiten. Die GDI
Sachsen übernimmt in diesem Falle die Ablaufüberwachung.
5.1.3.5.4 Monitoring und Reporting
Die nachfolgende Tabelle stellt die INSPIRE-Anforderungen an das Monitoring und
Reporting zusammen und zeigt, wo diese zu erfüllen sind. Grundlage sind die Durchführungsbestimmung nach Artikel 21 Abs. 4 INSPIRE zur Überwachung und Berichterstattung [26]. GDI-DE klassifiziert das Dienstemonitoring als optional [4] Abschnitt
5.3.1.2. Die konkreten Abläufe und Verantwortlichkeiten im Rahmen des Monitoring
and Reporting sind im Betriebskonzept zu regeln. Die benötigten Softwarekomponenten sind in einer Fortschreibung dieses Konzeptes festzulegen.
Seite 55 von 96
Indikator
Erhebung
Überwachung der Existenz von Metadaten
(MDi1.*)
Monitoring und Reporting durch die
geodatenhaltende Stelle.
Überwachung der Konformität von
Metadaten
(MDi2.*)
Monitoring der Konformität durch GDI
Sachsen möglich.
Überwachung der räumlichen Abdeckung der Monitoring und Reporting durch die
Geodatensätze
(DSi1.*)
Überwachung der Konformität der Geodatensätze 16
(DSi2.*)
Monitoring der Konformität durch GDI
Sachsen möglich.
Überwachung der Zugänglichkeit von
Metadaten über Suchdienste
(NSi1.*)
Überwachung der Zugänglichkeit von GeoMonitoring and Reporting durch die
datensätzen über Darstellungs- und Downlo- geodatenhaltende Stelle.
ad-Dienste
(NSi2.*)
Überwachung der Nutzung von Netzdiensten Monitoring und Reporting durch die
(NSi3.*)
geodatenhaltende Stelle. Bestandteil
der Messungen in der ITIL-Phase
„Continual Service Improvement“ des
jeweiligen Diensteanbieters.
Überwachung der Konformität von Netzdiensten
(NSi4.*)
Monitoring und Reporting der
Metadaten durch die
Konformität der Dienste siehe Tabelle
24.
Tabelle 23: Monitoring Indikatoren laut INSPIRE und deren Erhebung
16
Die Indikatoren schließen die Konformität der Metadaten zum Datensatz ein.
Seite 56 von 96
Die im Entwurf der INSPIRE Network Service Architecture Version 3.0 [15] festgelegten Quality of Service Requirements sind in Service Level Agreements (SLA) zu
übernehmen. Diese SLA sind zwischen dem Diensteanbieter des INSPIRE-Dienstes
und dem jeweiligen Dienste-„Kunden“ (INSPIRE, GDI-DE), ersatzweise mit der für
INSPIRE verantwortlichen Stelle der GDI Sachsen zu schließen. Die Überprüfung
der Einhaltung der SLA obliegt dem Diensteanbieter. In einigen Fällen können Teile
dieser Überprüfung als Dienstleistung auf der GDI Sachsen-Plattform erfolgen. Da
das Service Management auf der GDI Sachsen-Plattform ITIL-konform implementiert
werden soll, sind die entsprechenden Strukturen und Prozesse im Plattformbetrieb
etabliert.
Quality of
Service
Requirement
Reporting
Monitoring
durch
GDI
Sachsen
Bemerkung
Performance Dienstebetreiber 17 (möglich) Der Referenzwert soll am Server,
also ohne Verzögerung durch das
Netzwerk gemessen werden. Dies ist
bei Messungen durch Tools auf der
GDI Sachsen-Plattform zu beachten.
Benötigte Tools sind im Freistaat
Sachsen vorhanden.
Capacity
Dienstebetreiber
möglich
Sachsen vorhanden.
Availability
Dienstebetreiber
möglich
Sachsen vorhanden.
Reliability
Dienstebetreiber
nicht
möglich
Security
Dienstebetreiber
nicht
möglich
Die System- und Anwendungssicherheit soll in speziellen Tests vor
der Inbetriebnahme des Dienstes
getestet werden. Während der
Produktivphase ist die Sicherheit
durch Audits zu überwachen.
Compliance
Dienstebetreiber
möglich
Kann in einer zentralen Test-Suite
der GDI Sachsen überprüft werden.
Tabelle 24: Monitoring und Reporting der Qualitätsparameter laut INSPIRE
17
geodatenhaltende Stelle oder GDI Sachsen (im Falle des OWS Hosting bzw. orchestrierter Dienste)
Seite 57 von 96
5.1.4 Serverkomponenten (durch GDI Sachsen bereitgestellt)
Unter 5.1.6.11 wird dargelegt, dass der Dienst, der OWS unmittelbar schützt (Gatekeeper Service (siehe 5.1.6.10)), sowohl auf der GDI Sachsen-Plattform als auch auf
der Plattform des OWS-Anbieters betrieben werden kann. Zur Entscheidung für eine
der beiden Varianten können sowohl (sicherheits-)technische Aspekte als auch Fragen der Verantwortlichkeit für die Sicherheit von Datenbeständen relevant sein. Falls
der Gatekeeper Service (inkl. des Protokollwandlungsdienstes) dezentral installiert
wird, so soll die Software aus bereits beschriebenen Gründen durch die GDI Sachsen bereitgestellt werden. Für die Installation, die fachliche Administration sowie den
Betrieb ist jedoch der Dienstebetreiber verantwortlich, wobei die GDI Sachsen technische Unterstützungsleistungen anbietet.
Weiterhin werden zwei Dienste zur XML-Verarbeitung für eine dezentrale Installation
bereitgestellt:
Bezeichnung
Klassifizierung
Beschreibung
XML-Komprimierungsdienst (bidirektional)
(Geographic compression service)
INSPIRE:
nicht enthalten
GDI-DE:
nicht enthalten
Der XML-Komprimierungsdienst komprimiert mittels ITStandardtechnologien XML-Dateien insbesondere zum Zweck
des Transports über Netzwerke. Vor der weiteren Verarbeitung muss eine Dekomprimierung erfolgen.
Der Dienst sollte bei der Verwendung auf jeder Serverinstanz
der verteilten Dienste, mindestens aber auf jeder Plattform
vorliegen.
Weiterhin kann bei der Komprimierung eine Verschlüsselung
benutzt werden.
Typ/Instanz
Schnittstellen
Der Dienst sollte vor der Komprimierung den XMLWhitespacedienst verwenden.
Typ
Der Dienst arbeitet bidirektional.
Der Dienst unterstützt sowohl die Komprimierung als auch die
Dekomprimierung.
In:
Der Dienst empfängt einen Request aus dem eigenen Netzwerk in Form einer SOAP-Nachricht mit XML-Envelope oder
direkt eine XML-Datei sowie die Parameter zur Auswahl der
Komprimierungsart.
Out:
Als Response wird eine SOAP-Nachricht mit einem Link zur
komprimierten XML-Datei, nur ein Link oder eine SOAPNachricht mit komprimiertem XML-Anhang als base64Datentyp versandt.
Seite 58 von 96
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen

W3C Recommendation: SOAP Message Transmission
Optimization Mechanism, 25.01.2005
 W3C Working Draft, MTOM Serialization Policy Assertion
1.1, 18.09.2007
keine bekannt
SAGA 4.0 nennt ZIP Version 2.0 als obligatorisch. Damit ist
eine Komprimierung von XML-Daten auf ca. 3 bis 5 Prozent
der Ursprungsgröße möglich.
Leistungsfähige Softwarekomponenten ermöglichen eine
Komprimierung/Dekomprimierung „on-the-fly“. In der Regel ist
der Mehraufwand des Processings gegenüber der sonst höheren Netzlast gerechtfertigt. Dies ist aber im Einzelfall zu
prüfen.
Aktuelle Entwicklungen (MTOM vom W3C) haben das Ziel,
die Komprimierung direkt als Teil von SOAP zu integrieren.
Der Dienst selbst sollte nicht per SOAP implementiert werden,
da eine optimale Komprimierung mit base64-Format (byvalue) nicht gewährleistet ist.
Alternativ könnte der Dienst die Ergebnisdatei (Response)
temporär speichern und einen Link zum Ergebnis per SOAP
versenden (by reference).
Tabelle 25: XML-Komprimierungsdienst
Bezeichnung
Klassifizierung
Beschreibung
XML-Whitespaceservice (bidirektional)
(encoding service)
INSPIRE:
nicht enthalten
GDI-DE:
nicht enthalten
Der Dienst ändert den Whitespace einer XML-Datei. Dabei
kann er einerseits Whitespace entfernen, um die Dateigröße
zu minimieren (als Ergänzung der Datenkomprimierung oder
weiteren serverseitigen Verarbeitung) oder Whitespace hinzufügen, um eine einheitliche und nutzerfreundliche Ansicht zu
erzielen.
Auch dieser Dienst sollte auf jedem Server, mindestens aber
auf jeder Plattform verfügbar sein und sollte mit dem XMLKomprimierungsdienst gemeinsam bei jeder SOAPKommunikation verwendet werden, welche große XML-Inhalte
enthalten (ca. 2 MB).
Typ/Instanz
Der Dienst ist ein XML-Schematransformationsdienst, welcher
eine definierte XSL verwendet.
Typ
Seite 59 von 96
Schnittstellen
Bezugsdokumente
Implementierungen/
Anwendungen
Bemerkungen
Der Dienst arbeitet bidirektional.
In:
Der Dienst empfängt einen Request aus dem eigenen Netzwerk in Form einer SOAP-Nachricht mit XML-Envelope oder
direkt eine XML-Datei sowie den Parameter zur Auswahl der
„Verarbeitungsrichtung“.
Out:
Als Response wird eine SOAP-Nachricht mit einem Link zur
transformierten XML-Datei, nur ein Link oder eine SOAPNachricht mit transformiertem XML-Anhang versandt.
keine
nicht bekannt
Whitespace im Dokument kann ca. ein Drittel der Dateigröße
ausmachen.
Tabelle 26: XML-Whitespaceservice
5.1.5 Datenschicht
5.1.5.1
Sächsische INSPIRE- und andere Ressourcen (Originaldaten)
5.1.5.1.1 Metadaten
Die Metadaten zu sächsischen Geodaten, -diensten und –anwendungen werden in
verschiedenen MIS nachgewiesen. Soweit darüber hinaus Metadaten gehalten und
veröffentlicht werden (in den Service Capabilities, als WSDL Beschreibungen, in einem zentralen Diensteverzeichnis oder in den XCPF-Dateien der WPOS), wird gefordert, dass diese verteilten Metadaten konsistent sind.
5.1.5.1.2 Geodaten
INSPIRE geht im Grundsatz davon aus, dass eine Erzeugung zusätzlicher Geodaten
zur Erfüllung der Anforderungen nicht erforderlich ist, sondern dass die geforderten
Daten „lediglich“ identifiziert, weiterhin bei der fachlich zuständigen Stelle gepflegt
und dort mittels interoperabler Dienste verfügbar gemacht werden.
Den Prinzipien folgt auch dieses Architekturkonzept, so dass hier keine Regelungen
zu den dezentralen („originären“) sächsischen Geodaten enthalten sind. Hinsichtlich
der Daten wird die angestrebte technische, d.h. syntaktische und semantische
Interoperabilität, soweit erforderlich, durch zentrale Transformationsdienste gewährleistet.
Seite 60 von 96
5.1.5.1.3 Produktbeschreibungen und Preismodelle
Produktbeschreibungen und Preismodelle sind die Ressourcenschicht von WPOS.
Im Rahmen des WPOS OGC discussion papers [24] liegt zu diesem Zweck die Spezifikation eines XML-Formates vor (XML Configuration & Pricing Format (XCPF)),
welches auch im Rahmen von GeoBAK verwendet wird.
5.1.5.1.4 Nutzerdaten
Dezentral gehaltene Nutzerdaten werden gemeinsam mit den anderen GeoDRMKomponenten im Abschnitt 5.1.6 beschrieben.
5.1.5.2
Sächsische INSPIRE- und andere Ressourcen (Kopien)
Zur Realisierung des OWS Hosting-Angebotes sind die betreffenden Ressourcen für
den zentral betriebenen OWS Hosting Service bereitzustellen. I. d. R. werden dazu
Kopien der originären Daten zentral vorgehalten. Bei den genannten Ressourcen
wird es sich vorrangig um Geodaten handeln, für die zentrale Darstellungs- und
Downloaddienste implementiert werden. Außerdem können Produktbeschreibungen
und Preismodelle zur Verfügung gestellt werden, auf deren Grundlage dann das
zentrale WPOS Hosting betrieben wird.
Metadaten sind vom OWS Hosting Service nicht betroffen. Betreibt eine
geodatenhaltende Stelle keinen eigenen Suchdienst, soll sie Ihre Metadaten in einem
vorhandenen MIS, vorzugsweise im GeoMIS.Sachsen, einpflegen.
Die Workflows zur Bereitstellung der Ressourcen sowie zur Erzeugung der erforderlichen Metadaten werden im Betriebskonzept beschrieben.
5.1.5.3
Externe und GDI Sachsen Registries
5.1.5.3.1 Registries und Repositories
Unter dem Blickwinkel einer interoperablen Nutzung von GI-Ressourcen ist es erforderlich, ausgewählte Ressourcen an zentraler Stelle bereitzustellen (vgl. 4.2 und
5.1.3.4.5). Die Ziele bestehen in erster Linie darin, diese Ressourcen verfügbar zu
halten und einheitlich zu benutzen. Die Metadaten zu diesen Ressourcen werden in
Registern bzw. Registries gehalten (ISO 19135 [30] versteht unter einer Registry die
(dv-technische) Implementierung eines Registers.). Diese Metadaten sind von den
Datentypen der eigentlichen Ressourcen (z. B. Beschreibung eines CRS nach ISO
19111) abstrahiert und können daher nach einem einheitlichen Schema gehalten
werden. Derzeit gibt es mit ISO 19135 [30] und ebRIM [28] zwei konkurrierende konzeptuelle Sichten auf Registries.
Aufgrund der Komplexität und der unterschiedlichen Datentypen können die relevanten Ressourcen nur in einfachen Fällen unmittelbar in der oder den Registries gehalten werden. In der Regel werden separate Quellen erforderlich. In [28] werden diese
Seite 61 von 96
Quellen als Repositories 18 bezeichnet. Dabei kann es sich beispielsweise um einfache Listen, XML-Dokumente oder Datenbanken handeln.
In [29] werden folgende Register genannt: Datenproduktspezifikationen, Objektartenund Datentypkataloge, Anwendungsschemata (UML), XSchema, Codelisten, Koordinatenreferenzsysteme und –operationen, Maßeinheiten, Namensräume für Objektidentifikatoren, Dienstetypen, Signaturierungsregeln und Symbole.
Weiterhin werden Register benötigt für:


XSL
XSL-Dateien enthalten die Abbildungsvorschriften, die im Rahmen von XMLTransformationen angewendet werden.
statische Legenden
Nicht-SLD-fähige WMS geben Legenden als Bilder ab. Es ist sinnvoll, diese Bilder innerhalb einer GDI zu harmonisieren, an zentraler Stelle zu hosten und in einer Registry nachzuweisen.
Weitere Ressourcen, für die die Einrichtung von Registries in Frage kommt, sind



mehrsprachige Begriffe im Sinne eines Fachwörterbuchs,
Thesauri (Architekturkonzept GDI-DE, [4] Abschnitt 5.4.1 zukünftig) sowie
Identifikatoren, die für einen übergreifenden Anwendungsbereich harmonisiert
zur Verfügung gestellt werden sollen.
Diese Zusammenstellung ist im Rahmen einer Feinkonzeptionierung zu konkretisieren.
Die oben erwähnte Abstraktion der Ressourcen von ihren Metadaten führt dazu,
dass auch im Falle unterschiedlicher Datentypen und verteilter Zuständigkeiten innerhalb einer GDI nur eine Registry benötigt wird ([29]: "eine Registry, viele
Register"). Diese Registry bildet dann ein mehrteiliges, hierarchisches Register (vgl.
[30] Abschnitt 7.1) ab.
Ergänzend sei darauf verwiesen, dass der Aufbau und Betrieb der Repositories,
Register und Registries umfangreiche organisatorische Vereinbarungen und Festlegungen im Rahmen des Betriebskonzeptes erfordert. Grundlage kann dabei das Rollenkonzept aus [30], Abschnitt 5 sein.
5.1.5.3.2 Nutzer, Lizenzen, Rechte
Zentrale Nutzerdaten, Lizenzen und Rechte werden gemeinsam mit den anderen
Security-Komponenten im Abschnitt 5.1.6 beschrieben.
18
Für das Verständnis ist grundlegend, zwischen den Ressourcen (z.B.CRS) selbst und den Metadaten zu den Ressourcen (insbesondere die zu deren Identifizierung notwendigen) zu unterscheiden.
Die Ressourcen werden in den Repositories, die Metadaten in den Registries gehalten.
Seite 62 von 96
5.1.5.3.3 Zentrales Diensteverzeichnis
Ein zentrales Diensteverzeichnis ist integraler Bestandteil jeder SOA. Zunächst wurde davon ausgegangen, weltweit einige wenige „zentrale“ Verzeichnisse (UDDI) aufzubauen.
Abbildung 13: SOA-Dreieck
Mittlerweile hat sich jedoch der Ansatz etabliert, innerhalb eines Anwendungsbereiches ein Diensteverzeichnis zu implementieren. Im Bereich der GDI Sachsen weist
das GeoMIS.Sachsen u. a. Metadaten zu Geodatendiensten nach. Zugrunde liegen
die konzeptuellen Schemata aus ISO 19115 [54] und ISO 19119 [55].
Aus fachlicher Sicht ist jedoch festzustellen, dass die im Rahmen dieses Konzeptes
konzipierte SOA Anforderungen an die Bereitstellung von Dienstemetadaten stellt,
deren Erfüllung durch das GeoMIS.Sachsen a priori nicht vorgesehen ist:



Das GeoMIS.Sachsen weist nur Geodatendienste und keine allgemeinen ITDienste nach. Letztere sind jedoch Bestandteile der Architektur der sächsischen
Geodateninfrastruktur.
Es werden Metadaten zu Diensten benötigt, die im Datenmodell nach ISO
19115/19119 nicht enthalten sind. Beispielhaft seien die WSDL-Datei, die zu einem Dienst angebotenen Service Level Agreements oder Informationen zum Lebenszyklus eines Dienstes genannt.
Das zentrale Diensteverzeichnis sollte direkt vom Orchestrierungstool aus benutzbar sein. Es wäre zu prüfen, ob die CSW-Schnittstelle diese Anforderung
prinzipiell erfüllen kann.
Im Zuge der Fortschreibung dieses Konzeptes sind die Metadaten, die zu den Geodaten- und IT-Diensten benötigt werden, im Detail zu spezifizieren. Anschließend ist
festzulegen, ob das GeoMIS.Sachsen entsprechend erweitert wird. Das zugrunde
Seite 63 von 96
liegende konzeptuelle Schema ließe diese Erweiterung zu. Alternativen wären der
Aufbau eines eigenen Diensteverzeichnisses oder die Nutzung eines zentralen
sächsischen E-Government-Diensteverzeichnis. In den letztgenannten Fällen sollen
die Metadaten zu den Geodatendiensten mit dem GeoMIS.Sachsen konsistent
gehalten werden.
Ergänzend sei darauf hingewiesen, dass SAGA [5] in diesem Zusammenhang das
Deutsche Verwaltungsdiensteverzeichnis (DVDV) nennt. Dieses enthält vorrangig
technische Beschreibungen der Dienste im WSDL-Format, aber auch die notwendigen kryptografischen Zertifikate als Grundlage für eine sichere und rechtsverbindliche Kommunikation. Technische Grundlage ist der Verzeichnisstandard LDAP.
5.1.6 GeoDRM Layer und -Komponenten
Im GeoDRM Layer sind die Regeln abgebildet, die die Benutzung ansonsten freier
Dienste aus rechtlicher oder kommerzieller Sicht einschränken. Der Begriff
„GeoDRM Layer“ verdeutlicht, dass die GeoDRM-Komponenten als zusätzliche
Schicht betrachtet werden, durch die die Funktionalität (und möglichst auch die Performanz) vorhandener Dienste und Anwendungen nicht beeinträchtigt werden (sollten).
Teilweise werden auch Bestell-, Berechnungs- und Bezahlfunktionen dem GeoDRM
Layer zugeordnet. Diese Sichtweise ist dann naheliegend, wenn Preismodelle existieren, welche die Bestellung und Bepreisung zur Laufzeit der Nutzung des Dienstes
vorsehen. Solche Preismodelle sind jedoch in Sachsen gegenwärtig nicht existent.
Der Zugang zu kostenpflichtigen Diensten wird im Vorfeld vereinbart und pauschal
abgerechnet („Flatrate“).
Die nachfolgend zugrunde gelegte konzeptuelle Sicht folgt der Darstellung eines entsprechenden OGC Discussion Papers [17], welches ihrerseits auf einer OGC Abstract Specification [19] sowie auf einschlägigen OASIS-Spezifikationen basiert und
hier stark vereinfacht wiedergegeben wird. Der Schwerpunkt liegt in der Integration
der Komponenten in die Architektur der GDI Sachsen. Dabei ist eine Reihe von
Rahmenbedingungen zu betrachten:




Existierende Anwendungen und Portale haben im GeoDRM-Kontext die Rolle
von OWS Clients. Diese Clients können i. d. R. nicht verändert (erweitert)
werden.
Es sollen sowohl zentrale Dienste als auch dezentrale Dienste gesichert werden.
Es existieren verschiedene Nutzerverwaltungen, jedoch noch kaum Verwaltungen von GI-spezifischen Lizenzen.
Trotz des zur Zeit noch fehlenden Lizenzkonzeptes ist absehbar, dass Berechtigungen nicht ausschließlich a priori, z. B. auf der Grundlage eines offline geschlossenen Vertrages, mit Nutzern verknüpft werden können. Berechtigungen für den Zugriff auf Dienste sollen auch vom Ergebnis von Lizenzverhandlungen zur Laufzeit der Nutzung des Dienstes abhängig sein können.
Seite 64 von 96
Die folgenden Darstellungen von Komponenten sind nicht so zu verstehen, dass alle
diese Komponenten gleichzeitig mit der vollständigen Funktionalität implementiert
werden müssen. Insbesondere hinsichtlich des Lizenzmanagements ist eine stufenweise Realisierung vorstellbar: Auf den License Broker kann zunächst auch verzichtet werden (dann erhält ein Nutzer die Berechtigungen ausschließlich aufgrund seiner Identität) oder am GeoDRM Client sind nur wenige vordefinierte Lizenzen auswählbar.
Implementierungsspezifikationen, die durch die GI Community adaptiert und allgemein anerkannt sind, sind bislang nicht verfügbar (Ausnahme GeoXACML). Auch
wenn in [17] allgemeine IT-Standards zugrunde gelegt sind, wird Interoperabilität
zwischen Komponenten verschiedener Hersteller nicht zu erwarten sein. Dieses
Konzept beschreibt daher zwar die Funktionalität der zu implementierenden Komponenten, es können jedoch keine konkreten Schnittstellen benannt werden. Falls zukünftig entsprechende Standards vorliegen, so sollen diese im Zuge der Fortschreibung und Implementierung dieses Konzeptes berücksichtigt werden.
5.1.6.1
Überblick über die Komponenten
In ([17], Seite 11) wird die folgende Architektur zugrunde gelegt:
Abbildung 14: OGC Security Architektur
Seite 65 von 96
Die folgende Abbildung zeigt das Mapping der Komponenten auf die Schichten des
Architekturkonzepts:
OWS
Client
IR Client
PR Client
GeoDRM Client
Authentication Service
License Broker
Authorization Service
License Manager
Gatekeeper
Zentrales
Policy
Repository
geschützte OWS
ungeschützte OWS
Identity
Repositories
Zentrales
Identity
Repository
Abbildung 15: Überblick über die GeoDRM-Komponenten
Es ist ersichtlich, dass der Zugriff von OWS Clients auf ungeschützte OWS direkt
erfolgen soll.
Sollen geschützte Dienste genutzt werden, kommunizieren OWS Client und OWS
nicht mehr direkt miteinander, sondern über Komponenten des GeoDRM Layers. Deren Funktionalität besteht grob verallgemeinert darin, den ursprünglichen OWSRequest um die Identität des Benutzers sowie die erworbenen Lizenzen anzureichern, auf dieser Grundlage die Berechtigung der Anfrage zu prüfen und diese Berechtigungen durchzusetzen.
In den einschlägigen Dokumenten wird davon ausgegangen, dass innerhalb des
GeoDRM Layers SOAP als Transportprotokoll benutzt wird. Dies impliziert, dass am
„Ein- und Ausgang“ des Layers eine Protokollwandlung zwischen SOAP und dem
von den OWS mehrheitlich benutzen HTTP GET/POST stehen muss („SOAP-(Un)
Wrapping“; vgl. [20] und [21] und Tabelle 18).
Die einzelnen Komponenten werden im Folgenden beschrieben, der Workflow beim
Zugriff auf einen geschützten Dienst wird unter 5.2.3 und 5.2.4 dargestellt.
Seite 66 von 96
5.1.6.2
GeoDRM Client
Der GeoDRM Client steht als Proxy vor dem eigentlichen OWS Client. Dieser wird in
seiner Funktionalität nicht verändert. Beim Zugriff auf ungeschützte Dienste wird der
GeoDRM Client nicht benötigt. Erst wenn der in diesem Fall durch den Gatekeeper
bereitgestellte Capability-Response auf einen geschützten Dienst hinweist, wird er
manuell oder automatisch gestartet. Der GeoDRM Client fängt zunächst die Requests des OWS ab und führt folgende Operationen aus:




Auswertung der GeoDRM-relevanten Metadaten des geschützten Dienstes
Akquisition der Identitäts- und Lizenz-Tokens einschließlich Bereitstellung der
erforderlichen Dialoge
Verwaltung der Tokens
SOAP-Wrapping des OWS-Requests und Anreicherung der SOAP-Nachricht
um die Tokens
Der GeoDRM Client beinhaltet die oben beschriebene Protokoll-Wandlung nach
SOAP (bidirektional). Diese Funktionalität wird jedoch im vorliegenden Fall auch außerhalb des GeoDRM Clients benötigt, so dass eine modulare Implementierung vorzuziehen ist.
Der GeoDRM Client ist so zu entwerfen, dass im Falle einer notwendigen Anmeldung
in einer dezentralen Nutzerverwaltung (Identity Repository) jeweils alternativ die Anmeldung an der zentralen Nutzerverwaltung ausgewählt werden kann.
In [17] sind drei Möglichkeiten zur Implementierung der GeoDRM ClientFunktionalität aufgezeigt:



Erweiterung bestehender OWS Clients
client side OWS Proxy
server side OWS Proxy
Die erste Variante ist, wie bereits ausgeführt, für die Architektur der GDI Sachsen
nicht relevant. Die beiden letzten Varianten werden unter 5.1.6.11 diskutiert.
5.1.6.3
Identity Repository Client
Der Identity Repository Client dient Benutzern dazu, sich an der zentralen Nutzerverwaltung (u. U. erstmalig) anzumelden und diesem zentralen Login weitere Identitäten aus dezentralen Nutzerverwaltungen zuzuweisen und zukünftig zu verwalten.
Praktisch bedeutet dies, dass beispielsweise der Nutzer „Zentrale_Nutzerverwaltung\Andre_Mueller“ festlegt, dass er bei einer Anmeldung an der
zentralen Nutzerverwaltung automatisch auch mit seinen Identitäten „Landkreis_Vogtland\Mueller_Andre“ und „GeoSN\HTW_17“ an den jeweiligen Nutzerverwaltungen angemeldet ist. Dienste, die eine Authentifizierung an den genannten Nutzerverwaltungen erfordern, können dann im Sinne eines Single-Sign-On (SSO) genutzt werden.
Seite 67 von 96
Dieser Client ist nicht in Anwendungen bzw. Portale eingebunden. Er wird im GDI
Sachsen-Portal (siehe 5.1.1.4) platziert. Der Identity Repository Client muss das Zugriffsprotokoll des zentralen Identity Repository bedienen können.
5.1.6.4
Der Authentication Service wird zunächst vom GeoDRM Client benutzt, um die Identität eines Benutzers zu überprüfen (interface „authenticate“). Im Rahmen dieses
Konzeptes wird zunächst davon ausgegangen, dass die Identität durch eine gültige
Domäne/Nutzerkennung/Passwort-Kombination nachgewiesen wird. Im Erfolgsfalle
wird ein Identity Token zurückgegeben.
Eine weitere Schnittstelle des Authentication Service löst das Token auf und gibt die
zugehörigen Nutzerdaten zurück („getUser“). Dieses interface wird vom Authorization
Service (siehe 5.1.6.7) benutzt, um den zu einem Identity Token gehörenden Nutzer
zu identifizieren und ihm somit Rechte zuweisen zu können.
Der Authentication Service greift nicht nur auf eine Nutzerverwaltung zu, sondern
aggregiert mehrere (vgl. 5.1.6.5). Dabei soll der Authentication Service beim Zugriff
auf die angeschlossenen Nutzerverwaltungen unterschiedliche Protokolle unterstützen (vgl. 5.1.6.5):
IR Client
GeoDRM Client
z.B. SQL
Identity
Repository
Y
z.B. LDAP
Identity
Repository
X
….
Zentrales
Identity
Repository
Abbildung 16: Zugriff des Authentication Service auf das zentrale sowie
auf dezentrale Identity Repositories
Seite 68 von 96
Die im Folgenden beschriebenen Identity Repositories (dezentral, zentral) bilden die
Datenschicht des Authentication Service.
5.1.6.5
Dezentrale Identy Repositories
Es muss davon ausgegangen werden, dass die potentiellen Benutzer der sächsischen Dienste (dezentrale und zentrale) in den unterschiedlichen Nutzerverwaltungen der einzelnen Diensteanbieter bereits eingetragen sind und dass die Dienstebetreiber die „Hoheit“ über die Verwaltung der „eigenen“ Nutzer nicht aufgeben wollen. Die Nutzerverwaltungen sind in unterschiedlichen Datenhaltungen mit verschiedenen Zugriffsprotokollen abgelegt, wobei die Kombinationen LDAP-Verzeichnis/
LDAP und RDB/SQL die Wichtigsten sein dürften. Eine Replikation der Nutzerdaten
in die zentrale Nutzerverwaltung der GDI Sachsen wäre wünschenswert, dürfte jedoch mit einem zu großen administrativen Aufwand verbunden sein. Um Benutzern
jedoch mit einer Anmeldung die Nutzung aller Dienste, für die sie eine Berechtigung
haben zu ermöglichen (SSO), wird unter Abschnitt 5.1.6.6 eine entsprechende Lösung vorgeschlagen. Voraussetzung ist, dass der Authentication Service (5.1.6.4)
lesenden Zugriff auf die dezentralen Identity Repositories erhält und dabei die verwendeten Protokolle unterstützt.
5.1.6.6
Zentrales Identity Repository
Nutzer von zentralen Diensten, für die eine Identifizierung des Nutzers notwendig ist,
werden in der zentralen Nutzerverwaltung geführt. Weiterhin können sich Nutzer von
dezentralen Geodatendiensten, deren Betreiber keine eigene Nutzerverwaltung unterhalten, hier eintragen.
Das Anwendungsschema des zentralen Identity Repository soll erlauben, neben der
(zentralen) Nutzerkennung und dem (zentralen) Passwort zusätzlich Nutzerkennungen und Passwörter aus weiteren Domänen zuzuordnen:
ist_identisch_mit_zentralem_Nutzer
Domäne
z. B.
GDI Sachsen
GeoSN
LfULG
Landkreis XY
…
1..1
0..*
Nutzer\Passwort
z. B.
Andre_Mueller\*******
Mueller_Andre\******
HTW_17\****
…
0..1
Abbildung 17: Anwendungsschema des zentralen Identity Repository
Die Zuordnung von Nutzerkennungen aus dezentralen Identity Repositories zu der
zentralen Nutzerkennung erlaubt dem Authentication Service die zusätzliche Anmeldung an den referenzierten Nutzerverwaltungen. Die Pflege dieser Zuordnung obliegt
dem Nutzer.
Mit dem hier zugrunde gelegten Nebeneinander von zentraler und dezentraler Nutzerverwaltung wird zunächst der status quo festgeschrieben: Nutzer, denen der ZuArchitekturkonzept GDI Sachsen, Version 1.0
Seite 69 von 96
griff auf dezentrale Geodatendienste gestattet wird, werden in den Nutzerverwaltungen dieser (dezentralen) geodatenhaltenden Stellen geführt. Zudem ermöglicht die
beschriebene Lösung die Authentifizierung ausschließlich auf der Basis von Nutzername und Passwort. Zukünftig soll diese Variante durch Technologien wie elektronische Signaturen, Chipkarten und anderen ergänzt werden. Diese Verfahren stellen
einen hohen Aufwand dar und sind deshalb nicht durch jede Verwaltung umsetzbar.
Somit ergibt sich die Notwendigkeit, zumindest auf Landesebene eine zentrale Authentifizierung für den gesamten E-Government-Bereich bereitzustellen, welche den
jeweils aktuellen Anforderungen und Vorschriften entspricht. Eine solche Lösung
entspräche dann einem „echten“ SSO. Zudem kann ein so qualifiziertes System ggf.
auch von anderen (übergeordneten) Systemen, z. B. des Bundes, genutzt werden.
Die im Rahmen dieses Konzepts dargestellte Lösung (vgl. Abbildung 16) wäre dann
wie folgt zu modifizieren:




Die Akquisition des Identitäts-Tokens wird nicht vom GeoDRM Client selbst
durchgeführt, sondern durch zentrale Clients des E-Government. Dieser übermittelt an den GeoDRM Client das Token zur zentralen Identität.
Der Authentication Service wird zentral auf der E-Government-Plattform bereitgestellt und ermöglicht alle zulässigen Verfahren der Anmeldung. Die Funktionalität
entspricht mindestens der unter Abschnitt 5.1.6.4 beschriebenen.
Der IR Client entfällt.
Die Zuordnung der dezentralen Identitäten zur zentralen Identität erfolgt nicht
durch die Nutzer am zentralen Identity Repository, sondern durch die jeweiligen
Administratoren der dezentralen IR. Insofern müsste das Datenmodell der
dezentralen Identity Repositories um die zentrale Identität erweitert werden.
Der Authorization Service (siehe 5.1.6.7) kann weiterhin GI-spezifisch implementiert
werden.
5.1.6.7
Authorization Service
Der Authorization Service entscheidet auf Anfrage des Gatekeepers (vgl. 5.1.6.10)
aufgrund des Inhalts eines OWS-Requests, der Identität des Benutzers und der erworbenen Lizenz über die Zulässigkeit einer Anfrage an den OWS (interface authorise). Zur Auslösung der Tokens interagiert der Authorization Service dazu mit dem
Licence Mangager und dem Authentication Service.
5.1.6.8
License Broker Service
Der License Broker Service stellt zunächst Vorlagen für Lizenzvereinbarungen (Lizenzmodelle) zur Verfügung und liefert im Ergebnis einer erfolgreichen Verhandlung
ein Lizenz-Token an den GeoDRM Client (interface „negotiate & agree“). Die notwendigen Lizenzen kennt der GeoDRM Client aus den GeoDRM-Elementen, mit denen der Gatekeeper die Capabilities des zu schützenden OWS anreichert.
Im einfachsten Fall, der jedoch viele Anwendungsfälle abdecken sollte, muss der
Benutzer lediglich Nutzungsbedingungen bestätigen („click through licence“). Im
Rahmen des Lizenz- und Bepreisungskonzepts wird zu prüfen sein, ob komplexere
Seite 70 von 96
Prozesse wie insbesondere das käufliche Erwerben einer Lizenz in den Workflow zu
integrieren sind.
Der Nachweis des Erwerbs der Lizenz wird im zentralen Policy Repository abgelegt
und dort benutzt, um die Zulässigkeit von Abfragen an den geschützten OWS zu prüfen.
Die benötigten Lizenz-Templates sind in einem Repository vorzuhalten. Dazu kann
das zentrale Policy Repository genutzt werden.
5.1.6.9
Licence Manager Service / Zentrales Policy Repository
Ein Policy Repository dient zur Verwaltung von Berechtigungen aufgrund der Identität der Benutzer sowie der abgeschlossenen Lizenzvereinbarungen. Der Licence
Manager Service stellt die zugehörigen interfaces zur Verfügung:



Einfügen, Ändern und Löschen von Benutzern und Zuweisung von Rechten
(durch den Administrator des zu schützenden Dienstes)
Einfügen der abgeschlossenen Lizenzvereinbarungen (durch den Licence
Broker)
Bereitstellung von Berechtigungen (insbesondere auf Anforderung des Authorization Service)
Im Gegensatz zu Nutzerverwaltungen liegt diesem Architekturkonzept zugrunde,
dass ein Aufbau von Repositories zur Verwaltung von Rechten zu GI-Diensten mit
dem hier beschriebenen Funktionsumfang in absehbarer Zeit in Sachsen dezentral in
nennenswerter Anzahl nicht erfolgen wird. Das Policy Repository soll daher zentral,
jedoch mandantenfähig aufgebaut werden. Zur dezentralen Pflege des Policy
Repository wird ein Web Client (siehe Abbildung 15) benötigt, dessen Zugang sowie
Netzverbindungen hinreichend gesichert sind.
Das dem Policy Repository zugrundeliegende Anwendungsschema ist in [22] definiert und beinhaltet im Kern die Zuweisung von Rechten an (Lizenz-)Nutzer bzw. deren Rollen. Die Rechte können dabei feingranular definiert werden. Beispielsweise
kann (auch in Kombinationen) festgelegt werden:




Zulassen des (zeitlich begrenzten) Zugriffs auf einen Dienst (z. B. WMS),
Zulassen einzelner Schnittstellen (z. B. GetFeatureInfo),
Zulassen einzelner Layer (WMS) oder Objektklassen (WFS) oder
Beschränkung auf räumliche Bereiche.
Die Einträge im zentralen Identity Repository und im Policy Repository sind hinsichtlich der Nutzer redundant. Um Inkonsistenzen zu vermeiden, sollte eine gemeinsame
Implementierung nach einem einheitlichen Schema erfolgen, in dem die Nutzer redundanzfrei abgelegt sind. Inkonsistenzen zwischen den dezentralen Identity
Repositories und dem Policy Repository sind dagegen durch einen geeigneten
Workflow zu vermeiden.
Weiterhin bestehen Redundanzen zu den verschiedentlich existierenden dezentralen
Rechteverwaltungen. Diese Beziehungen sind im Rahmen einer Feinspezifikation
Seite 71 von 96
genauer zu untersuchen. Aus heutiger Sicht lässt sich bereits die Forderung aufstellen, dass für das Policy Repository eine Schnittstelle (z. B. GeoXACML) festgelegt
werden soll, über die Rechte aus dezentralen Systemen importiert werden können.
5.1.6.10 Gatekeeper Service
Der Gatekeeper Service ist (aus Sicht der GDI Sachsen) einziger Zugangspunkt zum
geschützten OWS („single point of control“). Insofern ist dieser Zugang auch derjenige, der im MIS zu veröffentlichen ist. Die Kommunikation zwischen Gatekeeper
Service und OWS wird über die OGC interfaces geführt, so dass keine Anpassungen
am OWS selbst erforderlich sind.
Die Funktionalitäten des Gatekeepers sind mindestens:




Senden einer Service Exception mit den GeoDRM-Vorbedingungen (Verweis auf benötigte Authentifizierung und Lizenzen) auf GetCapabilityRequests
Übermittlung aller anderen Requests an den Authorization Service
Durchsetzung der erhaltenen Obligationen durch Filterung (z. B. Layeranforderungen löschen) bzw. Anpassung (z. B. Änderung der Bounding Box)
des OWS-Requests (Vorzugsvariante) und/oder Bearbeitung (z. B. Ausblenden von Bereichen) des OWS-Response
Rückgabe des Response und aktualisierter Tokens
In Analogie zum GeoDRM Client muss auch der Gatekeeper Service die Protokollwandlung entsprechend 5.1.2.7 unterstützen.
5.1.6.11 Verteilung der GeoDRM-Komponenten
Auch wenn Festlegungen zur Verteilung der Komponenten nicht Gegenstand dieses
Architekturkonzepts sind, soll die folgende Abbildung deutlich machen, dass es hinsichtlich der Verteilung des GeoDRM Clients und des Gatekeepers prinzipiell verschiedene Varianten gibt:
Seite 72 von 96
OWS
Client
OWS
Client
2
GeoDRM Client
GeoDRM Client
1
Gatekeeper
OWS
2
OWS
3
Gatekeeper
Gatekeeper
OWS
OWS
Abbildung 18: Verteilung der GeoDRM Proxies 19


GeoDRM Client und/oder Gatekeeper liegen außerhalb der GDI SachsenPlattform. Die GeoDRM-Komponenten werden jedoch durch die GDI Sachsen zur
Verfügung gestellt (2).
GeoDRM Client und/oder Gatekeeper werden auf der GDI Sachsen-Plattform betrieben (3).
Außerdem soll an dieser Stelle auf einen weiteren Aspekt hingewiesen werden: Es
wird davon ausgegangen, dass sich die zentralen Komponenten der GDI Sachsen in
einem geschützten Bereich befinden und Netzverbindungen nach außen hinreichend
abzusichern sind (z. B. über HTTPS, dies wiederum setzt eine entsprechende Infrastruktur voraus). Dies betrifft auch die Antwort des OWS. Es macht keinen Sinn, den
Zugang zu einem Dienst aufwendig zu sichern und anschließend die geschützten
Daten frei über das Internet zu verschicken. Daher sind die betroffenen Netzsegmente außerhalb der GDI Sachsen-Plattform entsprechend zu sichern.
19
Der Vollständigkeit halber ist der direkte Zugriff auf die ungeschützten zentralen oder dezentralen
OWS (über HTTP GET/POST) (1) ebenfalls dargestellt.
Seite 73 von 96
5.2 Dynamische Sicht (Auswahl)
Dieser Abschnitt enthält im Unterschied zu vergleichbaren Konzepten aus zweierlei
Gründen keine vollständige Zusammenstellung aller durch GDI Sachsen zu unterstützenden Abläufe, sondern lediglich exemplarisch ausgewählte Anwendungsfälle:


GDI Sachsen stellt primär keine Anwendungen zur Verfügung, sondern Dienste.
Das Aggregieren von Diensten zu Anwendungen ist Sache der Anwendungen
und Geoportale. Diese werden hier nicht betrachtet.
Wie bereits einleitend deutlich gemacht wurde, besteht das Ziel auf der GDI
Sachsen-Plattform zwar darin, Dienste zu kombinieren, jedoch nicht im Sinne der
Implementierung vordefinierter starrer Abläufe. Vielmehr sollen auf der GDI
Sachsen-Plattform Dienste flexibel zu neuen, höherwertigen Diensten verkettet
werden können (Orchestrierung) 20 .
20
In dieser Flexibilität besteht ein wesentlicher Unterschied der hier beschriebenen Architektur zur
Basiskomponente Geodaten in deren jetziger Umsetzung.
Seite 74 von 96
5.2.1 Anwendungsfall „Bedienung INSPIRE Request“
Es wird vereinfacht gezeigt, wie ein INSPIRE- oder GDI-DE-Download-Request bedient wird. Die Diensteanforderung kann durch
einen dezentralen WFS nicht bedient werden (Verteilung der angeforderten Daten auf zwei Dienste, Nichtübereinstimmung beim
angeforderten Schema und beim CRS).
INSPIRE
Client
INSPIRE Knoten
GDI Sachsen
Transformationsdienst
INSPIRE-OWS
dezentraler
WFS
OWS
Hosting
(WFS)
Koordinatentransformationsdienst
Feature
Schematransformationsdienst
CRS
Registry
Service
wa ndleR e que st
INSPIR E
R eque st
ge tFe a ture
getFe ature
transform ie re C R S
beziehe Transform ationspa ra m e te r
transform iereSche m a
INSPIR E
R esponse
INSPIR E
R e sponse
Abbildung 19: Sequenzdiagramm - INSPIRE Request 21
21
Legende siehe Anlage 2
Seite 75 von 96
be zie he XSL
XSL
Registry
Service
5.2.2 Anwendungsfall „Orchestrierung von Diensten“
Nutzer
Service Desk
GeoMIS.Sachsen/
zentrales Diensteverzeichnis
Orchestrierungstool
Anforde rung
Dienste re cherche
W SDL
P roze ssm odellie rung
BP EL-Proze ss
P roze ss hoste n
W SDL ne ue r Die nst
Metadaten neuer Die nst
Inform a tion
übe r Die nst
R e que st
R e sponse
Abbildung 20: Sequenzdiagramm - Orchestrierung
Seite 76 von 96
BPEL Server
Dienste
5.2.3 Anwendungsfall „Eintragung eines Benutzers am zentralen Identity Repository“
Nutzer
IR-Client
Zentrales Identity
Repository
A uthentication
Service
dezentrale Identity
Repositories
R e gistrie rung sta rte n
Nutze rda ten einge ben
verfügbare Dom ä ne n
Anze ige der Dom äne n
Eingabe we ite rer
Ide ntitäte n
Ide ntitä te n hinzufüge n
Te sta nm e ldung (Z_IR \Nutze rna m e \Pa sswort)
lie fe re
weite re Ide ntitä te n
X_IR \Nutze rna m eX\
PasswortX
Te sta nm e ldung
Bestä tigung
Te sta nm e ldung
Be stätigung
Be stä tigung
Be stätigung
Abbildung 21: Sequenzdiagramm - Eintragung eines Benutzers
Seite 77 von 96
5.2.4 Anwendungsfall „Zugriff auf geschützten Dienst“
OWS
Client
GeoDRM
Client
Protokollwandlung
clientseitig
A uthentification
Service
License
Broker
A uthorisation
Service
Licence
Manager
Protokollwandlung
serverseitig
O W S R equest
Ex ception
O W S Re que st
SO AP R e que st
Dom ä ne\Nutze rna m e \Pa sswort
Ide ntity Tok e n
Lize nzbe stätigung
Lize nz able gen
Be stätigung
Licence Tok e n
SO AP m it Tok e ns
Abfra ge O bliga tione n
Auflösung Ide ntity Tok e n
Nutzerdate n und Dom ä ne
Abfra ge
Be re chtigungen
O bliga tione n
O bliga tione n
Seite 78 von 96
Gate
keeper
geschützter
OWS
OWS
Client
GeoDRM
Client
Protokollwandlung
clientseitig
A uthentification
Service
License
Broker
A uthorisation
Service
Licence
Manager
Protokollwandlung
serverseitig
Gate
keeper
geschützter
OWS
O bliga tione n
Re questFilte rung
SO AP Re quest
O W S Re quest
O W S Re que st
O W S Re sponse
Re sponse Filte rung
O W S R esponse
SO AP Re sponse
SO AP Re sponse
SO AP Re sponse
O W S R e sponse
O W S R e sponse
Abbildung 22: Sequenzdiagramm - Zugriff auf geschützten Dienst
Seite 79 von 96
6 Abkürzungsverzeichnis
AdV
Arbeitsgemeinschaft der Vermessungsverwaltungen
der Länder der Bundesrepublik Deutschland
BKG
Bundesamt für Kartographie und Geodäsie
BPEL
Business Process Execution Language (Synonym für WS-BPEL)
CITE
Compliance and Interoperability Testing Initiative
CMS
Content Management System
CRS
Coordinate Reference System
CSW
Catalogue Services for the Web (Katalogdienst)
Digital Rights Management
DRM
ebRIM
electronic Business Registry Information Modell
FE
Filter Encoding [40]
FTP
File Transfer Protocol
GDI
Geodateninfrastruktur(en)
GDI-DE
Geodateninfrastruktur Deutschland
GeoBAK
Basiskomponente Geodaten des Freistaates Sachsen
GeoDRM
Geospatial Digital Rights Management
GeoSN
Staatsbetrieb Geobasisinformation und Vermessung Sachsen
GeoXACML Geospatial Extensible Access Control Markup Language [22]
GI
Geoinformation
GIF
Graphics Interchange Format
GIS
Geographisches Informationssystem (Geoinformationssystem)
GML
Geography Markup Language [41]
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
HTTPS
Hypertext Transfer Protocol Secure
INSPIRE
INfrastructure for SPatial InfoRmation in Europe (siehe Glossar)
IR
Identity Repository
ISO
International Organization for Standardization
IT
Informationstechnik
ITIL
IT Infrastructure Library
JPG/JPEG Joint Photography Group (Bildformat nach ISO/IEC 10918-1)
KVP
Key Value Pairs
LDAP
Lightweight Directory Access Protocol
LfULG
Sächsisches Landesamt für Umwelt, Landwirtschaft und Geologie
(ehemals LfUG und LfL)
MIS
Metadateninformationssystem (Metainformationssystem)
MTOM
Message Transmission Optimization Mechanism
NOL
(ehemaliger) Niederschlesischer Oberlausitzkreis
OASIS
Organization for the Advancement of Structured Information Standards
OGC
Open Geospatial Consortium
OLA
Operational Level Agreements
OWS
OGC Web Services
PDF
Portable Document Format
PNG
Portable Network Graphics
RDB
Relationale Datenbank
RM-ODP
Reference Model of Open Distributed Processing [11]
Seite 80 von 96
SächsGDIG
SAGA
SE
SID
SLA
SLD
SMI
SOA
SOAP
SOS
SQL
SSO
SVG
TIFF
UDDI
UML
W3C
WCS
WCTS
WFS
WMS
WPOS
WPS
WPVS
WS
WSDL
WTS
XCPF
XML
XSchema
XSL/XSLT
Sächsisches Geodateninfrastrukturgesetz
Standards und Architekturen für E-Government-Anwendungen [5]
Symbology Encoding [27]
Staatsbetrieb Sächsische Informatik Dienste
Service Level Agreement(s)
Styled Layer Descriptor [36]
Sächsisches Staatsministerium des Innern
Service-orientierte Architektur (Service Oriented Architecture)
kein Akronym - siehe Glossar
(ursprünglich Simple Object Access Protocol)
Sensor Observation Service
Structured Query Language
Single-Sign-On (Einmalanmeldung)
Scalable Vector Graphics
Tagged Image File Format
Universal Description, Discovery and Integration
Unified Modeling Language
World Wide Web Consortium
Web Coverage Service
Web Coordinate Transformation Service [50]
Web Feature Service [39]
Web Map Service [33], [34], [35]
Web Pricing and Ordering Service(s) [24]
Web Processing Service
Web Perspective View Service
Web Service (auch “Web service” oder “Webservice”)
Web Service Description Language
Web Terrain Service [43]
XML Configuration & Pricing Format [24]
Extensible Markup Language
XML-Schema (auch XSD - XML-Schema-Definition)
Extensible Stylesheet Language / -Transformation
Seite 81 von 96
7 Glossar Architekturkonzept
Dieses Kapitel enthält die Erläuterung von Begriffen,
 die innerhalb dieses Dokuments mit einer speziellen Bedeutung belegt sind
und/oder
 von denen nicht erwartet wird, dass sie Bestandteil eines zukünftigen zentralen Glossars der GDI Sachsen sein werden.
Dies schließt nicht aus, dass Begriffe dieses Glossars in das zentrale Glossar übernommen werden.
Basisdienst: Dienst, der unmittelbar auf den zugrundeliegenden Geodaten aufgesetzt
wurde und der (gegenüber zusammengesetzten Diensten) eine vergleichsweise
geringe Komplexität aufweist
BPEL: Synonym für WS-BPEL - Web Service Business Process Execution Language; Sprache zur Beschreibung von Geschäftsprozessen durch die Verkettung (Orchestrierung) von Webservices; OASIS-Standard
dezentral: bezeichnet sächsische Geodatendienste, Ressourcen und Anwendungen,
die nicht auf der zentralen GDI Sachsen-Plattform betrieben werden. Beispiele
sind die Basiskarte Sachsen des GeoSN oder die Geoportale von Landkreisen
extern: bezeichnet Geodatendienste, Ressourcen und Anwendungen außerhalb
Sachsens, insbesondere aus übergeordneten GDI
Fassade: Entwurfsmuster aus der objektorientierten Softwaretechnik. Fassaden werden verwendet, um spezialisierte Schnittstellenanforderungen, z. B. aus übergeordeten GDI, zu bedienen.
GDI Sachsen:
1. im abstrakten Sinne Akronym für „sächsische Geodateninfrastruktur“ (z. B.
in Überschrift 1.1)
2. im konkreten Sinne Instanz, die für den Betrieb der zentralen Komponenten
verantwortlich ist (Koordinierungsstelle entsprechend Vorstudie zum Betriebskonzept [9]) (z. B. in Überschrift 5.1.2)
GDI Sachsen-Plattform: Plattform, auf der die zentralen Dienste der GDI Sachsen
betrieben werden
GDI Sachsen-Portal: Webseite mit ausgewählten Metadaten zu sächsischen Geoportalen; Einstiegsseite in die sächsische Geodateninfrastruktur
GeoDRM Layer: (dt. Geo-Rechte-Management-Schicht) Gesamtheit aller Komponenten zur Absicherung von Diensten und zur Abwicklung des elektronischen Geschäftsverkehrs
Seite 82 von 96
GeoShop: Gesamtheit von Komponenten (XCPF-Dateien, WPOS, Order Service,
Order Client) zum Erwerb von kostenpflichtigen und kostenfreien GI-Produkten;
nicht zum GeoShop gehören Komponenten für den Erwerb des Zugangs zu
Diensten zur Laufzeit der Dienstenutzung
Kaskade: Verkettung (Integration, Aggregation) von Diensten gleichen Typs
Knoten: Position in einer (Dienste-)Topologie
Landesmetadatenknoten: Knoten, hinter dem sich die gesamte sächsische MISTopolgie verbirgt und an dem daher alle sächsischen Metadaten verfügbar sind.
Der sächsische Landesmetadatenknoten ist als Profil der CSW-Schnittstelle
des GeoMIS.Sachsen implementiert.
Monitoring: Beobachtung von Diensten nach den Qualitätskriterien Performanz, Kapazität, Verfügbarkeit, Verlässlichkeit, Sicherheit, Konformität; Unterscheidung
in internes und externes Monitoring
Orchestrierung: Prozess der Erzeugung höherwertiger Dienste durch die intelligente
Verkettung von vorhandenen Diensten
Originaldaten: Daten, die geodatenhaltende Stellen im Rahmen Ihrer Zuständigkeiten
bzw. Ihres Geschäftsmodells vorhalten; die technische Speicherung der Daten
kann dabei an Dritte delegiert sein
OWS Hosting: zentraler Betrieb von OGC Web Services stellvertretend für die geodatenhaltenden Stellen
Portrayal Service: Dienst, welcher unpräsentierte Geodaten (Features oder Coverages) unter Verwendung einer Zeichenvorschrift in Grafikdaten umwandelt und
(optional) rendert
Querschnittsdienst: vergleichsweise atomarer Dienst, der auf der GDI SachsenPlattform bereitgestellt wird und i. d. R. nicht direkt in Anwendungen eingebunden wird, sondern in Diensteketten integriert ist
Register: (eng. register) Menge von Daten, die Identifikatoren und definierte Metadaten zu Instanzen von Datentypen enthalten (z. B. CRS ID) (nach [30])
Registry (eng): (dt. Register oder Registry 22 ) Informationssystem, in dem ein Register
geführt wird [30]; Mehrzahl Registries
Registry Service: Dienst zur Pflege und Nutzung einer Registry (INSPIRE:
Registerdienst)
Repository: Verzeichnis
22
Übersetzung laut nationalen Vorwort zur DIN EN ISO 19135
Seite 83 von 96
sächsisch: Klassifizierung von Komponenten - Überbegriff zu „zentral“ und
„dezentral“; im Unterschied zu „extern“ (nicht-sächsisch)
SOAP: bezeichnet ein Netzwerkprotokoll (W3C-Standard) u. a. zum Austausch von
Nachrichten in serviceorientierten Architekturen; wird für INSPIRENetzwerkdienste empfohlen
Token: Zeichenkette zur Abbildung von Lizenz- und Identitätszuordnungen;
Plural: Tokens
Wrapping: Entwurfsmuster in der Softwareentwicklung zur Übersetzung von Schnittstellen
zentral: Dienste (Geodatendienste und andere Netzdienste) und Anwendungen, welche auf der GDI Sachsen-Plattform bereitgestellt werden
zentrales Diensteverzeichnis: Verzeichnis mit Metadaten zu Geodatendiensten und
anderen Netzdiensten, die für den Betrieb einer SOA erforderlich sind
Seite 84 von 96
8 Vorschläge für ein zentrales Glossar
Dieses Kapitel enthält eine Zusammenstellung von Begriffen, die innerhalb des Architekturkonzepts verwendet wurden. Die Erläuterungen an dieser Stelle dienen dem
Verständnis des Konzepts. Ungeachtet dessen wird erwartet, dass diese Begriffe
zukünfig Bestandteil eines zentralen Glossars der GDI Sachsen sein werden. In diesem Zusammenhang ist mit Änderungen der Erläuterungen zu rechnen.
gdi.initiative.sachsen : Koordinierung und Beförderung von verschiedenen staatlichen, kommunalen, wissenschaftlichen und privatwirtschaftlichen Vorhaben und
Aktivitäten sowie deren Integration in einen gemeinsamen Aufbau einer sächsichen Geodateninfrastruktur in einer durch Vertreter aus Wirtschaft, Wissenschaft und Verwaltung getragenen Initiative
Darstellungsdienst: (eng. view service) Geodatendienste, „die es zumindest ermöglichen, darstellbare Geodaten anzuzeigen, in ihnen zu navigieren, sie zu vergrößern und verkleinern, zu verschieben, Daten zu überlagern sowie Informationen
aus Legenden und sonstige relevante Inhalte von Metadaten anzuzeigen“
(SächsGDIG [3], §3); INSPIRE Dienst
Dienst: (eng. Service) abgrenzbarer Teil einer Funktionalität, welcher durch eine
Software-Komponenten über Schnittstellen bereitgestellt wird (nach ISO 19119
[55])
Dienst zum Abrufen von Geodatendiensten: (eng. invoke spatial services service)
Geodatendienste, „die es erlauben, Anforderungen an Geodaten zu bestimmen
und verschiedene Geodatendienste miteinander zu verbinden“ (SächsGDIG [3],
§3); entstehen im Ergebnis einer Orchestrierung; INSPIRE Dienst
Downloaddienst: (eng. download service) Geodatendienste, „die das Herunterladen
und, wenn durchführbar, einen direkten Zugriff auf Replikationen im Sinne von §
2 Abs. 4 von Geodaten ermöglichen“ (SächsGDIG [3], §3); INSPIRE Dienst
E-Government: “E-Government steht für eine Verwaltung, deren Abläufe insgesamt
effizient und kooperativ gestaltet sind. Sie nutzt dazu umfassend moderne Informationstechnologien, um ihre Mitarbeiter untereinander und mit ihren Kunden zu vernetzen.“ [Sächsisches Staatsministerium des Innern auf
http://www.egovernment.sachsen.de]
Seite 85 von 96
GDI: Geodateninfrastruktur, definiert als „die Gesamtheit aller Geodaten, Metadaten
und Netzdienste, insbesondere Geodatendienste, und Netztechnologien; Vereinbarungen über eine gemeinsame Nutzung, den Zugang und die Verwendung
und Koordinierungs- sowie Überwachungsmechanismen, -prozesse und –
verfahren mit dem Ziel, verteilt liegende Geodaten interoperabel verfügbar zu
machen“ (SächsGDIG [3], §3)
Geodaten: Daten mit direktem oder indirektem Raumbezug (SächsGDIG [3], §3)
Geodatendienst: „Geodatendienste sind spezielle Typen der Netzdienste für den Zugriff auf Geodaten und den Zugriff auf entsprechende Recherche-, Analyse- und
Darstellungsfunktionalitäten für Geodaten. … (verändert nach E-SächsGDIG
und der INSPIRE Richtlinie)“ (Vorstudie zum Betriebskonzept [9])
geodatenhaltende Stelle: Organisationseinheit, die originär Geodatenbestände (Originaldaten) führt. Im Unterschied zum SächsGDIG [3], §2 sind diese Geodatenbestände im Sinne dieses Konzeptes nicht auf die INSPIRE-Themen beschränkt.
GeoMIS.Sachsen: gegenwärtig beim GeoSN betriebenes Informationssystem, in
dem Metadaten zu Geodaten, Geodatendiensten und Geoanwendungen gespeichert und recherchierbar sind
Geoportal: „Ein Geoportal ist eine Kommunikations-, Transaktions- und Interaktionsplattform, die den Zugang zu Geodaten ermöglicht.“ (SächsGDIG [3], §3)
GI-Ressourcen: Geodaten, Geodatendienste und Anwendungen mit den zugehörigen Metadaten
INSPIRE: „Infrastructure for Spatial Information in the European Community: Der
Aufbau dieser Infrastruktur wird in der Europäischen Rahmenrichtlinie
2007/2/EC (kurz INSPIRE Direktive) für die Europäische Union gesetzlich definiert und die EU-Mitgliedstatten werden aufgefordert, die Komponenten dieser
Europäischen GDI umzusetzen (EC 2007).“ (Vorstudie zum Betriebskonzept
[9])
INSPIRE-Themen: (Umwelt-)Themen, die in den Annex I bis III der Richtlinie aufgezählt sind
Interoperabilität: “die Fähigkeit zur Kombination und Interaktion verschiedener Systeme, Techniken oder Daten unter Einhaltung gemeinsamer Standards“
(SächsGDIG [3], §3 nach GeoZG §3 Abs. 4)
Metadaten: „Daten über Geodaten und Geodatendienste, die deren Inhalte und Eigenschaften beschreiben und es ermöglichen, die Geodaten und
Geodatendienste zu ermitteln, in Verzeichnisse aufzunehmen und zu nutzen“
(SächsGDIG [3], §3)
Profil: Norm oder Standard, mit dem eine zugrundeliegende Norm bzw. ein Standard
spezialisiert wird (nach ISO 19101)
Seite 86 von 96
Registerdienst: (eng. Registry Service) Dienst zur Benutzung und Pflege von Registries; INSPIRE Dienst
Sachsenatlas: Synonym für das Geoportal innerhalb der sächsischen E-Government
Basiskomponente Geodaten (GeoBAK)
sächsische Geodateninfrastruktur: Die sächsische Geodateninfrastruktur ist integraler Bestandteil des E-Government im Freistaat Sachsen. Sie besteht sowohl
aus Komponenten der Landesverwaltung, Komponenten der Landkreise und
Kommunen sowie Komponenten der Wirtschaft.
Schnittstelle: (eng. interface) benannte Menge von Operationen, die das Verhalten
einer (Software-)Komponente charakterisieren (nach ISO 19119 [55])
Service-orientierte Architektur: (eng. Service Oriented Architecture) SoftwareArchitektur, in deren Zentrum das Anbieten, Suchen und Nutzen von Diensten
in einem Netzwerk steht.
Strategische Leitlinien: Grundsatzdokument der gdi.initiative.sachsen zum Gemeinsamen Aufbau einer Geodateninfrastruktur im Freistaat Sachsen durch
Verwaltung, Wirtschaft und Wissenschaft [1]
Suchdienst: (eng. discovery service) Geodatendienste, „die es ermöglichen, auf der
Grundlage des Inhalts entsprechender Metadaten nach Geodaten und Geodatendiensten zu suchen und den Inhalt der Metadaten anzuzeigen“ (SächsGDIG
[3], §3); INSPIRE Dienst
Transformationsdienste: (eng. transformation services) Geodatendienste „zur Umwandlung von Geodaten um Interoperabilität zu erreichen“ (SächsGDIG [3], §3);
INSPIRE Dienst;
Unterteilung in Formattransformationsdienst (format transformations), Sprachübersetzung (language translations), geometrische Transformation (geometric
transformations), Schematransformationsdienst (schemas translations)
Seite 87 von 96
9 Quellenverzeichnis
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
Strategische Leitlinien der gdi.initiative.sachsen,
http://www.gdi.sachsen.de/inhalt/init/Leit_GDI-Sachsen_070530.pdf
Projektsteckbrief AK Referenzmodell, EGr Architekturkonzept, 2008-02-04,
http://www.gdi.sachsen.de/inhalt/init/Steckbrief_AK_Referenzmodell.pdf
Entwurf eines Gesetzes über die Geodateninfrastruktur im Freistaat Sachsen
(E-SächsGDIG), http://www.gdi.sachsen.de/inhalt/info/aktuell/090508b/
4_Drs_15464_1_1_67.pdf
GDI-DE Architekturkonzept, Version 1.0, 2007-08-17,
http://www.gdi-de.de/de/download/GDI_ArchitekturKonzept_V1.pdf
SAGA 4.0, Standards und Architekturen für E-Government-Anwendungen,
März 2008, http://gsb.download.bva.bund.de/KBSt/SAGA/SAGA_v4.0.pdf
OpenGIS Catalogue Services Specification 2.0.2 - ISO Metadata Application
Profile, OGC Document 07-045, 2007-07-19,
http://portal.opengeospatial.org/files/?artifact_id=21460
DE-Profil des ISO19115/ISO19119 Anwendungsprofils für OGC Web Catalogue Services (CSW-2.0), Version 1.0.1, 2005-08-03,
http://www.atlas.sachsen.de/gps/download/GDI_DE_CSW_Profil.pdf
Integrationsleitfaden Sachsenatlas, Version 1.1 (Sächsische Staatskanzlei),
nicht öffentlich
Vorstudie zum Betriebskonzept der Geodateninfrastruktur des Freistaates
Sachsen (GDI Sachsen), 2008-11-10,
http://www.gdi.sachsen.de/inhalt/info/archiv/081127/VorstudieGDI_081110.pdf
OASIS Web Services Business Process Execution Language Version 2.0,
2007-04-11, http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf
ISO 10746 Information technology -- Open Distributed Processing -- Reference model, http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
W3C Web Services Description Language (WSDL) 1.1, 2001-03-15,
http://www.w3.org/TR/wsdl
W3C SOAP Version 1.2, 2007-04-27, http://www.w3.org/TR/soap
Grobkonzept GeoShop, Version 1.0, 2007-06-26, nicht öffentlich
INSPIRE Network Services Architecture, Version 3.0, 2008-07-19,
http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/network/
D3_5_INSPIRE_NS_Architecture_v3-0.pdf
INSPIRE Draft Implementing Rules for Discovery and View Services (IR1)
2007-12-17, http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/
network/D3.7_Draft_IR_Discovery_and_View_Services_v2.0.pdf
OpenGIS GeoDRM Engineering Viewpoint and supporting Architecture (OWS4 GeoDRM Interoperability Report), OGC Dokument 06-184r2, 2007-04-17,
INSPIRE DT on Network Services, Conference–Maribor–Slovenia–June 2008:
http://www.ec-gis.org/Workshops/inspire_2008/presentations/
03_01_Serrano.pdf
OpenGIS Abstract Specification Topic 18: Geospatial Digital Rights Management Reference Model (GeoDRM RM), OGC Dokument 06-004r4,
2006-12-29, http://portal.opengeospatial.org/files/?artifact_id=17802
Seite 88 von 96
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
OpenGIS Discussion Paper: Wrapping OGC HTTP-GET and -POST Services
with SOAP, OGC Dokument 07-158, 2008-01-24,
OpenGIS OWS 5 SOAP/WSDL Common Engineering Report, OGC Dokument
08-009r1, 2008-01-16, http://portal.opengeospatial.org/files/?artifact_id=26521
OpenGIS Geospatial eXtensible Access Control Markup Language (GeoXACML), OGC Dokument 07-026r2, 2008-02-20,
http://www.opengeospatial.org/standards/geoxacml
Ralf Buchsein, Frank Victor, Holger Günther, Volker Machmeier; ITManagement mit ITIL V3: Vieweg+Teubner Verlag
OpenGIS Discussion Paper: Web Pricing & Ordering Service (WPOS) XML
Configuration & Pricing Format (XCPF), OGC 02-039r1, 2002-11-18,
OpenGIS Web Processing Service, OGC Dokument 05-007r7, 2007-06-08,
http://www.opengeospatial.org/standards/wps
ENTSCHEIDUNG DER KOMMISSION vom 5. Juni 2009 zur Durchführung der
Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich
Überwachung und Berichterstattung, http://eur-lex.europa.eu/LexUriServ/
LexUriServ.do?uri=OJ:L:2009:148:0018:0026:DE:PDF
OpenGIS Symbology Encoding Implementation Specification, OGC Dokument
05-077r4, 2006-07-21, http://www.opengeospatial.org/standards/symbol
OASIS/ebXML Registry Information Model v2.0, April 2002,
http://www.oasis-open.org/committees/regrep/documents/2.0/specs/ebrim.pdf
AdV Registry Prototyp – Abschlussbericht zur Veröffentlichung, 2007-07-26,
http://www.adv-online.de/icc/extdeu/binarywriterservlet?imgUid=e9460faf3815-a411-a3b2-1718a438ad1b&uBasVariant=11111111-1111-1111-1111111111111111&isDownload=true
ISO 19135:2007 Geographic information - Procedures for item registration,
2007-02-25
OpenGIS Best Practices Document: Gazetteer Service - Application Profile of
the Web Feature Service Implementation Specification 0.9.3, OGC Dokument
05-035r2, 2006-06-05, http://portal.opengeospatial.org/files/?artifact_id=15529
OpenGIS Discussion Paper: Tiled WMS, Version 0.3.0, OGC Dokument 07057r2, 2007-08-14, http://portal.opengeospatial.org/files/?artifact_id=23206
OpenGIS Web Map Server Interface Implementation Specification, Revision
1.0.0, OGC Dokument 00-028, 2000-04-19,
http://www.opengeospatial.org/standards/wms
OpenGIS Web Map Service Implementation Specification, Version 1.1.0, OGC
Dokument 01-047r2, 2001-06-21,
http://www.opengeospatial.org/standards/wms
OpenGIS Web Map Server Implementation Specification, Version 1.3.0, OGC
Dokument 06-042, 2006-03-15, http://www.opengeospatial.org/standards/wms
OpenGIS Styled Layer Descriptor profile of the Web Map Service Implementation Specification, Version 1.1.0, OGC Dokument 05-078r4, 2007-06-29,
http://www.opengeospatial.org/standards/sld
GDI-DE Profil WMS-DE_1.0, Version 1.0, 2006-10-17,
http://www.gdi-de.de/de/download/WMS_DE_Profil_V1.pdf
WMS-Applikations-Profil Sachsen Standard für Geodienste, Version 1.1,
2007-07-31, http://www.atlas.sachsen.de/gps/download/WMS-ProfilSachsen_v1.1.pdf
Seite 89 von 96
[39]
[40]
[41]
[42]
[43]
[44]
[45]
[46]
[47]
[48]
[49]
[50]
[51]
[52]
[53]
[54]
[55]
[56]
[57]
OpenGIS Web Feature Service Implementation Specification, Version 1.1.0,
OGC Dokument 04-094, 2005-05-03,
http://www.opengeospatial.org/standards/wfs
OpenGIS Filter Encoding Implementation Specification, Version 1.1.0, OGC
Dokument 04-095, 2005-05-03, http://www.opengeospatial.org/standards/filter
OpenGIS Geography Markup Language (GML) Encoding Standard, Version
3.2.1, OGC Dokument 07-036, 2007-08-27,
http://www.opengeospatial.org/standards/gml
OpenGIS Catalogue Services Specification, Version 2.0.2, OGC Dokument
07-006r1, 2007-02-23, http://www.opengeospatial.org/standards/cat
OpenGIS Discussion Paper: OGC Web Terrain Server (WTS), Version 0.3.2,
OGC Dokument 01-061, 2001-08-24,
OpenGIS Discussion Paper: Web 3D Service, Version 0.3.0, OGC Dokument
05-019, 2005-02-02, http://portal.opengeospatial.org/files/?artifact_id=8869
ISO 19111:2005 Geographic information - Spatial referencing by coordinates,
November 2005
OpenGIS Discussion Paper: OWS 1.2 SOAP Experiment Report, Version 0.8,
OGC Dokument 03-014, 2003-01-15,
OpenGIS CSW-ebRIM Registry Service - Part 1: ebRIM profile of CSW, Version 1.0.1, OGC Dokument 07-110r4, 2009-02-05,
http://www.opengeospatial.org/standards/cat
Basiskomponente Geodaten des Freistaats Sachsen (GeoBAK) - Grobkonzept, Version 1.0, 2005-02-25, nicht öffentlich
INSPIRE Draft Technical Guidance - View Services, Version 1.0, 2008-10-17,
http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/network/
Draft_Technical_Guidance_View_Services_v1.0.pdf
OpenGIS Discussion Paper: Web Coordinate Transformation Service (WCTS),
Version 0.3.0, OGC Dokument 05-013, 2005-01-30,
OpenGIS Best Practices Document: Specification best practices, Version 1.0,
OGC Dokument 06-135r1, 2006-05-24,
INSPIRE NETWORK SERVICES SOAP Framework, technical report, 200812-16, http://inspire.jrc.ec.europa.eu/reports/ImplementingRules/network/
INSPIRE_NETWORK_SERVICES_SOAP_Framework.pdf
OASIS/ebXML Registry Services Specification v2.5, Juni 2003, http://
www.oasis-open.org/committees/regrep/documents/2.5/specs/ebrs-2.5.pdf
EN ISO 19115:2003 Geographic information – Metadata, Januar 2005
EN ISO 19119:2006 Geographic information – Services, Juni 2006
ISO 19139:2007 Geographic information -- Metadata -- XML schema implementation
Verordnung (EG) Nr. 1205/2008 der Kommission vom 3. Dezember 2008 zur
Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des
Rates hinsichtlich Metadaten (Durchführungsbestimmung Metadaten),
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=
OJ:L:2008:326:0012:0030:DE:PDF
Seite 90 von 96
10 Anlagen
Anlage 1: ITIL Phasen, Prozesse und Kennzahlen
Bezeichnung/Erläuterung
Beispielhafte Kennzahlen
Service Strategie
Diese Phase steht im Zentrum des Dienste-Lebenszyklus. Hier werden die strategischen Entscheidungen zu Design, Entwicklung und Implementierung des Service
Managements getroffen.
Financial Management
In der derzeitigen Abstraktionsstufe dieses
Konzepts ist die Budgetplanung noch nicht
implementiert. Auch die Planung der Dienstekosten ist noch nicht möglich.
Service Portfolio Management
 Anzahl Dienste im Portfolio
In diesem Prozess werden die Dienste insge Anteil gelieferter Dienste
samt zu den Geschäftsprozessen der GDI
 Veränderungen im ServiceportSachsen in Bezug gesetzt.
folio
 Status der Dienste
Demand Management
 Anzahl neuer Projekte
In diesem Prozess werden die Kunden (Nut Anzahl kurzfristiger Kapazitätszer-)anforderungen für jeden Dienst festgeanpassungen
stellt. Damit werden die benötigten Kapazitäten geplant und bereitgestellt, die den Forderungen entsprechen.
Service Design
Durch diese Phase wird die strukturelle Service-Integrität sichergestellt. Es werden
die Kundenanforderungen aufgenommen und daraus die geplanten Ergebnisse definiert.
Service Catalogue Management
 Anteil der betriebenen Services,
Dieser Prozess stellt die Entwicklung und Wardie im Servicekatalog aufgetung des Servicekatalogs (hier zentrales
nommen sind
Diensteverzeichnis nach 5.1.5.3.3) sicher. Der  inhaltliche Abweichungen zwiServicekatalog enthält genaue Informationen
schen Katalogbeschreibung
über alle aktuellen und geplanten operationelund Realität
len Services.
Service Level Management (SLM)
 Einhaltung der SLA
Das Service Level Management ist für das
 Anzahl der SLA-Reviews
Verhandeln und das Einhalten der Service Le-  Anteil der SLA-Verletzungen
vel Agreements (SLA) verantwortlich. Weiterdurch OLA Verletzungen
hin hat es sicherzustellen, dass alle externen
Leistungen mit Operational Level Agreements
(OLA) untersetzt sind, die den Zielen der Service Level entsprechen. In diesem Prozess
wird beispielsweise die Einhaltung der Vorgaben zum Service Monitoring aus INSPIRE
(Performance – Schnelligkeit, Reliability – AusArchitekturkonzept GDI Sachsen, Version 1.0
Seite 91 von 96
fallsicherheit, Capacity – Anzahl gleichzeitiger
Zugriffe, Availability – Verfügbarkeit, Security –
verfügbare Sicherheitsmaßnahmen und Regulatory – Standardeinhaltung) verantwortet. Das
SLM stellt die Einhaltung der Vorgaben aus
INSPIRE sicher und initiiert OLA gegenüber
Dienstebetreiber, die zur Erbringung der
INSPIRE-Vorgaben benötigt werden.
Capacity Management
Durch das Kapazitätsmanagement wird die
kostengünstige und rechtzeitige Bereitstellung
der zum Einhalten der Service Level Agreements benötigten Ressourcen sichergestellt.
Die Planung erfolgt auf der Basis der kurz-,
mittel- und langfristigen Geschäfts- und Kundenanforderungen.
Availability Management
Durch diesen Prozess wird sichergestellt, dass
die Verfügbarkeit der internen Systeme und
Prozesse den Service Level - Zielen hinsichtlich der Verfügbarkeit entspricht.
IT Service Continuity Management (ITSCM)
Durch diesen Prozess werden Risiken, die
schwere Auswirkungen auf den IT-Service haben können, auf ein akzeptables Level reduziert.
Information Security Management
Durch diesen Prozess werden Vertraulichkeit
und Integrität innerhalb des Service gewährleistet.
Supplier Management
Im Supplier Management werden die Lieferantenbeziehungen und -verträge so gestaltet und
gesteuert, dass die Serviceziele erreicht werden.















Anzahl SLA-Verletzungen durch
fehlende Kapazitäten
Anzahl und Anteil überwachter
Systeme
Kosteneinsparung durch Capacity Management
Anzahl von SLA-Verletzungen
durch mangelnde Verfügbarkeit
Verfügbarkeit in Hauptnutzungszeiten
Kosten der Nicht-Verfügbarkeit
Anzahl erfolgreicher Tests
Anzahl erfolgreicher Audits
Aufwand für Aktualisierung der
ITSCM-Pläne
Anzahl von Sicherheitsvorfällen
Anteil von SLA in denen besonderer Bezug zur Sicherheit besteht
Anzahl Sicherheitsaudits
Anzahl der Reviews mit Lieferanten
Anzahl der Streitfälle mit Lieferanten
Anzahl der Lieferanten im Vertragsmanagement
Service Transition
Diese Phase umfasst alle Prozesse, um Services in den produktiven Betrieb zu
übernehmen und produktive Services zu verändern.
Transition Planning und Support
 Anteil eingehaltener ReleaseDieser Prozess unterstützt und koordiniert alle
Vereinbarungen
Prozesse der Phase Service Transition.
 Kundenzufriedenheit mit den
Transition-Plänen
 Akzeptanz im Serviceteam
Change Management
 Anzahl der Changes
Aufgabe des Change Managements ist das
 Anteil fehlerfreier Changes
Organisieren vorteilhafter Änderungen in der
 Termin- und Kostentreue in
Service-Erbringung mit minimalen Störungen.
Changes
Seite 92 von 96
Ohne die Mitwirkung des Change Manage Anzahl offener Änderungsanments ist keine Änderung an Software, Hardforderungen (Request for
ware oder Abläufen möglich. Wenn neue
Changes (RFC))
Dienste im Ergebnis der Orchestrierung erzeugt werden sollen, ist dazu ein Change
Mangement Prozess zu implementieren.
Service Asset und Configuration Manage Anzahl CIs
ment
 Anteil nicht genutzter Lizenzen
Assets sind alle Güter und Finanzen, die zur
 Gesamtwert und Zunahme an
Service-Erbringung eingesetzt werden. Die
Wert der CIs
beteiligten Betriebsmittel werden als Konfigurationselemente (CI, Configuration Items) bezeichnet. Alle CIs werden in einer Configuration Management Datenbank (CMDB) verwaltet.
Release und Deployment Management
 Anzahl durchgeführter ReDas Release und Deployment Management
leases
verantwortet, unter Einbeziehung des Change  Anzahl von Störungen in Folge
Managements, die Planung und Steuerung
von Releases
von neuen Versionen, neuer Hardware, Pro Kundenzufriedenheit durchgezessänderungen und Dokumentationen in die
führter Releases
Test- oder Produktivumgebung.
Evaluation
 Anzahl der Störungen pro SerEvaluation stellt die Beurteilung geänderter
vice
Services dar. Es wird beurteilt, ob die geplan Anzahl der Abweichungen in
ten Ergebnisse der Änderungen erreicht wurder Performanz des Services
den. Im Zweifelsfall kann eine Änderung gestoppt oder rückgängig gemacht werden.
Knowledge Management
 Anzahl der Störungen durch
Das Wissensmanagement stellt einen überfehlendes Anwenderwissen
greifenden Prozess zum Sammeln, Analysie Anzahl der Zugriffe auf das
ren, Speichern und Bereitstellen der InformatiWissensmanagement-System
onen aus den Prozessen dar. Die einfache
 Kundenzufriedenheit mit dem
Verfügbarkeit der Informationen einer OrganiWissensmanagement-System
sation erhöht die Effizienz und vermeidet Doppelarbeit.
Service Operations
Die Phase Service Operations stellt die Prozesse des Service-Betriebs dar. Sie enthält Anleitungen für die effiziente Lieferung und Unterstützung des Services. Die
genauen Abläufe der Prozesse sind in einem Betriebs- und Servicekonzept zu regeln.
Event Management
 Anzahl Events
Als Event werden Vorfälle im laufenden Be Events mit Verfügbarkeitsaustrieb bezeichnet, die nicht von Anwendern erwirkung
kannt werden.
Incident Management
 Anzahl der Störungen
Ziel dieses Prozesses ist die möglichst schnel-  durchschnittliche Reaktionszeit
le Wiederherstellung des Services für die An durchschnittliche Lösungszeit
wender nach einer Störung.
 Anteil fehlerhafter Kategorisierung von Störungen
Seite 93 von 96
Request Fulfilment
Management aller aus den Prozessen resultierenden Service Requests im Sinne von Unterstützungsanforderungen. In diesem Prozess
werden die im Change und im Service Management geplanten Änderungen durchgeführt.
Problem Management
Ziel des Problem Management ist das nachhaltige Beheben und Verhindern von Störungen.

Access Management
Sichern des Zugriffs auf Services und Daten.









Bearbeitungszeit für Unterstützungsanforderungen
Einhaltung der vereinbarten
Zeiten
Kosten für Unterstützungsanforderungen
Anzahl der Probleme
Anzahl offener Probleme
RfC auf Grund von Problemen
Nutzungsgrad der dokumentierten bekannten Fehler
Anzahl von Zugriffsanforderungen
Störungen auf Grund falscher
Zugriffsrechte
Kosten für Zugriffsberechtigungen
Erstlösungsrate von Incidents
Anteil der korrekten Kategorisierungen
Einhaltung der SLA zur Eskalation von Incidents
Service Desk

Der Service Desk ist kein Prozess, sondern

eine organisatorische Anforderung. Aufgaben
sind:

 Entgegennahme von Störungsmeldungen
(Incidents) und Service Requests
 Kategorisierung von Störungsmeldungen
 erste Ebene der Problemlösung
 Verantwortlich bei Eskalationen
 Information des Meldenden über den Fortschritt
 Abschluss der Incidents und Requests
Continual Service Improvment (CSI)
In der Phase der kontinuierlichen Service-Verbesserung wird die Anpassung der
Services an Änderungen der Geschäftsprozesse beschrieben. Operative Änderungen werden in den Change Prozess übergeben. Die Gesamtschau wird regelmäßig
innerhalb der GDI Sachsen vorgestellt und für die Weiterentwicklung der Plattform
verwendet.
The 7 Step Improvement Process
 Anzahl der Änderungen im ProIn diesem Prozess werden die zu messenden
zess-Verbesserungs-Plan
Kennzahlen definiert, die Messungen durchge-  Anzahl der proaktiv gefundenen
führt, resultierende Aktivitäten beschrieben
Probleme
und korrigierende Aktionen eingeleitet.
Service Reporting
 Kundenzufriedenheit
Das Service Reporting ist für das Erstellen und  Termintreue
die Lieferung von Berichten über Leistung und
Trends verantwortlich. Format, Inhalt und Häufigkeit der Berichte an die Kunden werden
festgelegt.
Innerhalb dieses Prozesses wird beispielsweise das Reporting der von INSPIRE geforderArchitekturkonzept GDI Sachsen, Version 1.0
Seite 94 von 96
ten Kennzahlen erstellt.
Service Measurement
Die Ende-zu-Ende-Messung (aus Sicht des
Kunden: von der Auslösung des Services bis
zum Endergebnis) des Service in den Perspektiven Verfügbarkeit, Zuverlässigkeit und
Performanz ist Aufgabe dieses Prozesses.
Return on Investment for CSI
Ermittlung und Bewertung der Kosten für das
CSI in Bezug auf die Vorteile, die durch CSI
ermöglicht werden.
The Business Questions for CSI
Hier wird bewertet, welche Verbesserungsmaßnahmen aus der Geschäftssicht sinnvoll
sind.
Service Level Management
s. o.


Messergebnisse
Anteil SLA mit Ende-zu-Ende
Kriterien
Seite 95 von 96
Anlage 2: Legende Sequenzdiagramme
Objekt („Kommunikationspartner“) mit
Lebenslinie
Synchrone Nachricht/Operationsaufruf
(synchrone) Antwort
Asynchrone Nachricht/Operationsaufruf
(asynchrone) Antwort
Notiz
Rekursion (Objekt ruft eigene Methode auf)
Seite 96 von 96

Architekturkonzept - Geodateninfrastruktur

Transcrição

Documentos relacionados

Anlage A2c - Kassenärztliche Vereinigung Sachsen

25 Jahre Schachverband Sachsen e. V.

Datenblatt

FerienTicket Sachsen und SuperSommerFerienTicket

Schulabschluss nachholen

LAND TAGS - Der Sächsische Landtag

Marketingstrategie 2011 - Investieren in Sachsen

Fokus Mittelstand - LBBW Sachsen Bank

Asylbewerber und Flüchtlinge im Freistaat Sachsen

Steckbrief Geographische Bezeichnungen

music:match - Kultur Aktiv eV

deutsche Übersetzung der ISO-Felder