Referenzmodell der Geodateninfrastruktur Sachsen

Transkript

1 Referenzmodell der Geodateninfrastruktur Sachsen Architekturkonzept Version: 1.0 Stand:

2 Projektgruppe/Teilprojekt: Arbeitskreis Referenzmodell Expertengruppe Architekturkonzept Version 1.0 verantwortlich Prof. Dr. F. Telefonnummer 0351 / Schwarzbach schwarzbach@htw-dresden.de Beginn QS-Verfahren: Datum Freigabe: Bereich LfULG IDU mbh Landkreis Görlitz GeoSN HTW Dresden Landeshauptstadt Dresden SAKD HTW Dresden SMI conterra GmbH Mitglieder Expertengruppe Name Astrid Ment Dr. Dietmar Bothmer Sven Hölzel Alexander Horn André Müller Andreas Schmidt Klaus Sandmann Prof. Dr. Frank Schwarzbach Jörg Taggeselle Christoph Uhlenküken Bereich TU Dresden TU Dresden ehem. KoBIT Weitere Beteiligte Name Prof. Dr. Lars Bernard Johannes Brauner Peter Schmädicke Dokumentenhistorie Version bearbeitet von Datum Bemerkung Einarbeitung Ergebnisse öffentliches Review 1.0 Sb/Mue Entw. Expertengr Vorlage für öffentliches Review Architekturkonzept GDI Sachsen, Version 1.0 Seite 2 von 96

3 Inhaltsverzeichnis 1 Einordnung des Architekturkonzepts Einordnung in die GDI Sachsen Einordnung in die GDI-DE sowie INSPIRE Grundsätze, Methodik und Aufbau des Architekturkonzepts Referenzen Fachliche Sicht Ist- und Bedarfsanalyse Komponenten der GDI Sachsen Nutzungswege Bedienung sächsischer Anwendungen und übergeordneter GDI durch dezentrale Geodatendienste Zugang zur sächsischen Geodateninfrastruktur über ein zentrales GDI Sachsen-Portal Integration von zentral bereitgestellten Komponenten in sächsische Anwendungen und Geoportale Verwendung zentraler Dienste der GDI Sachsen Benutzung von zentral zur Verfügung gestellten Serverkomponenten Weitere Anforderungen Dienstequalität Orchestrierung Absicherung von Geodatendiensten Funktionale Sicht Strukturelle Sicht Anwendungsschicht INSPIRE/GDI-DE Sächsische und weitere Anwendungen/Portale Sachsenatlas GDI Sachsen-Portal Registry Clients Administration Anwendungs- und GeoDRM-Komponenten (durch GDI Sachsen bereitgestellt) Karten-Client Recherche-Client Location Finder Client Order Client Koordinatentransformations-Client GeoDRM Client Protokoll-Wandlung Diensteschicht Dezentrale Geodatendienste Externe Dienste Externe Registry Services Zentrale Dienste Darstellungs- und Downloaddienste Transformationsdienste Architekturkonzept GDI Sachsen, Version 1.0 Seite 3 von 96

4 Dienste zum Abrufen von Geodatendiensten Weitere Dienste Registry Services GeoDRM Services Service Management nach ITIL IT Infrastructure Library (ITIL) Zentrale Dienste der GDI Sachsen Dezentrale Geodatendienste Monitoring und Reporting Serverkomponenten (durch GDI Sachsen bereitgestellt) Datenschicht Sächsische INSPIRE- und andere Ressourcen (Originaldaten) Metadaten Geodaten Produktbeschreibungen und Preismodelle Nutzerdaten Sächsische INSPIRE- und andere Ressourcen (Kopien) Externe und GDI Sachsen Registries Registries und Repositories Nutzer, Lizenzen, Rechte Zentrales Diensteverzeichnis GeoDRM Layer und -Komponenten Überblick über die Komponenten GeoDRM Client Identity Repository Client Authentication Service Dezentrale Identy Repositories Zentrales Identity Repository Authorization Service License Broker Service Licence Manager Service / Zentrales Policy Repository Gatekeeper Service Verteilung der GeoDRM-Komponenten Dynamische Sicht (Auswahl) Anwendungsfall Bedienung INSPIRE Request Anwendungsfall Orchestrierung von Diensten Anwendungsfall Eintragung eines Benutzers am zentralen Identity Repository Anwendungsfall Zugriff auf geschützten Dienst Abkürzungsverzeichnis Glossar Architekturkonzept Vorschläge für ein zentrales Glossar Quellenverzeichnis Anlagen Architekturkonzept GDI Sachsen, Version 1.0 Seite 4 von 96

5 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. Architekturkonzept GDI Sachsen, Version 1.0 Seite 5 von 96

6 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 GDI- DE. 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. Architekturkonzept GDI Sachsen, Version 1.0 Seite 6 von 96

7 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. Architekturkonzept GDI Sachsen, Version 1.0 Seite 7 von 96

8 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-Government- Landschaft, 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 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. 4 Eine kompakte Darstellung der fünf Sichten des RM-ODP ist beispielsweise in SAGA [5] enthalten. Architekturkonzept GDI Sachsen, Version 1.0 Seite 8 von 96

9 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. Architekturkonzept GDI Sachsen, Version 1.0 Seite 9 von 96

10 3 Referenzen Strategische Ziele Strategische Leitlinien der gdi.initiative.sachsen [1] Rechtsgrundlagen GI-Normen und -Standards 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] ISO 191xx Serie Spezifikationen des OGC Technische Richtlinien zu den INSPIRE- Durchfü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] Architekturkonzept GDI Sachsen, Version 1.0 Seite 10 von 96

11 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. Architekturkonzept GDI Sachsen, Version 1.0 Seite 11 von 96

12 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] 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. Sächsische und externe Anwendungen Dezentrale Geodatendienste Sächsische INSPIRE- und andere Ressourcen (Originaldaten) Anwendungs- und Clientkomponenten (durch GDI Sachsen bereitgestellt) GDI Sachsen-Plattform Zentrale Dienste der GDI Sachsen Serverkomponenten (durch GDI Sachsen bereitgestellt) Sächsische INSPIREund andere Ressourcen (Hosting) GDI Sachsen- Anwendungen Externe Dienste Abbildung 3: Architektur (generalisiert) Externe Registry Services Externe und GDI Sachsen- Registries Datenschicht Diensteschicht Anwendungsschicht Legende Vorhandene ( dezentrale ) Komponenten zentrale Komponenten, die der Freistaat Sachsen nach Maßgabe des Lizenz- und Bepreisungsmodells als staatliche Infrastrukturmaßnahme implementiert und pflegt Architekturkonzept GDI Sachsen, Version 1.0 Seite 12 von 96

13 Die Komponenten werden in diesem Abschnitt zunächst grob und in den nachfolgenden Abschnitten detailliert beschrieben: Sächsische und externe Anwendungen Anwendungs- und Clientkomponenten (durch GDI Sachsen bereitgestellt) GDI Sachsen- Anwendungen GDI Sachsen-Plattform Zentrale Dienste der GDI Sachsen Dezentrale Geodatendienste 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. Architekturkonzept GDI Sachsen, Version 1.0 Seite 13 von 96

14 Sächsische INSPIRE- und andere Ressourcen (Originaldaten) HTW Dresden (FH) 4 /3 Externe Dienste Externe Registry Services Sächsische INSPIREund andere Ressourcen (Hosting) Externe und GDI Sachsen- Registries 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. 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). Es handelt sich um externe Dienste, mit denen Register (siehe ) übergeordneter GDI zugänglich gemacht werden. 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. 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. Architekturkonzept GDI Sachsen, Version 1.0 Seite 14 von 96

15 4.3 Nutzungswege 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 Sächsische und externe Anwendungen Dezentrale Geodatendienste Sächsische INSPIRE- und andere Ressourcen (Originaldaten) Anwendungs- und Clientkomponenten (durch GDI Sachsen bereitgestellt) GDI Sachsen-Plattform Zentrale Dienste der GDI Sachsen Serverkomponenten (durch GDI Sachsen bereitgestellt) Sächsische INSPIREund andere Ressourcen (Hosting) GDI Sachsen- Anwendungen 4.3.3, Externe Dienste Externe Registry Services Externe und GDI Sachsen- Registries Datenschicht Diensteschicht Anwendungsschicht Abbildung 4: Nutzungswege der GDI Sachsen 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. Architekturkonzept GDI Sachsen, Version 1.0 Seite 15 von 96

16 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 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. Architekturkonzept GDI Sachsen, Version 1.0 Seite 16 von 96

17 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 GI- Anwendungen 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 ) 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 behandelt. 6 Ein GI-Produkt könnte beispielsweise ein Link zu einer Karte, welche die bei einem bestimmten Pegelstand überschwemmten Gebiete zeigt, sein. Architekturkonzept GDI Sachsen, Version 1.0 Seite 17 von 96

18 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 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.) 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 handelt es sich um Geographic workflow/task management services. Architekturkonzept GDI Sachsen, Version 1.0 Seite 18 von 96

19 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 Sachsen- Plattform 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 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. Architekturkonzept GDI Sachsen, Version 1.0 Seite 19 von 96

20 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 schichtübergreifend dargestellt. 5.1 Strukturelle Sicht INSPIRE/GDI-DE Sächsische und weitere Anwendungen/Portale Sachsenatlas GDI Sachsen-Portal GeoDRM Client und Anwendungskomponenten (durch GDI Sachsen bereitgestellt) Protokoll-Wandlung HTTP GET/POST SOAP Koordinatentransformation Sachsenatlas Karte Administration GeoDRM Client Recherche Shop Darstellungs- und Download-Dienste OWS Hosting Transformations- Dienste Dienste zum Abrufen von Geodiensten (Orchestrierte Dienste) Weitere Dienste OWS Hosting Registry Services GeoDRM Services Service Management Protokoll-Wandlung HTTP GET/POST SOAP Serverkomponenten (durch GDI Sachsen bereitgestellt) Proprietärer DRM Layer Gatekeeper Dezentrale Geodatendienste XML Komprimierung Externe Dienste Externe Registry Services (WMS, WFS, WCS, CSW, WPS, WPOS, SOS ) Registries Meta- Daten Geo- DB Preismodelle Nutzer Sächsische INSPIRE- und andere Ressourcen (Originale) Geodaten (Kopien) Nutzer, Lizenzen Rechte zentrales Diensteverzeichnis Abbildung 5: Komponenten der GDI Sachsen Architekturkonzept GDI Sachsen, Version 1.0 Seite 20 von 96