Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.
1. Einführung, Zielsetzung
Mit dem Ziel, den Zugriff auf das Bayerische Straßeninformationssystem zu öffnen, werden im Auftrag des Freistaats Bayern derzeit die Grundlagen einer allgemeinen Datenbereitstellung erarbeitet. Mit dieser soll über sog. OKSTRA-konforme XML-Web Services die vorhandene Geo-, Netz- und Fachdateninfrastruktur standardisiert genutzt werden (Vgl. Artikel „OKSTRA-konforme Web Services“ von Herr Roland Degelmann). Berechtigten Clientapplikationen wird somit ermöglicht, über das Internet lesend und schreibend auf die von der Straßenbauverwaltung vorgehaltenen Daten zuzugreifen. Grundlage für das Servicekonzept sind dabei die Ergebnisse des Bund-/Länderprojekts „Anforderungsprofil an eine Straßeninformationsbank der Zukunft“, welche mit dem „XML-Prototypen einer Straßeninformationsbank“ erfolgreich erprobt werden konnten. Die Spezifikationen der „Web Feature Services“ (WFS) definieren demnach die Services und OKSTRA beschreibt die Daten.
2. Grundlage der serviceorientierten Straßeninformationsinfrastruktur
Zentraler Bestandteil einer serviceorientierten Straßeninformationsstruktur sind „Dienste“, die von ein oder mehreren „Service Providern“ angeboten werden. Die Dienste könnten dabei verschiedenste Ausprägungen haben, die Verwendung vorhandener Standards (http(s), SOAP, WFS, OKSTRA) ist jedoch zielführend, um klare weiterverwendbare Strukturen zu erhalten, die Einstiegshürde für neue Entwicklungen zu minimieren und nicht zuletzt unnötige Kosten bei der Entwicklung von „Parallel- Standards“ einzusparen.
Das Konzept der hier vorgestellten serviceorientierten Straßeninformationsstruktur sieht eine Gliederung in fünf Schichten vor:
Präsentationsschicht
Die Präsentationsschicht ist clientseitig implementiert. Sie beinhaltet die Routinen zur anwenderfreundlichen Darstellung und Abfrage der Daten („Benutzeroberfläche“).
Datenaufbereitungsschicht
Innerhalb der Datenaufbereitungsschicht werden die OKSTRA-XML-Daten in die Datenstruktur des Clients übersetzt und umgekehrt. Zumeist ist die Datenaufbereitungsschicht clientseitig implementiert, im Falle komplexer, orchestrierter Services (wie z.B. Erstellung einer thematischen Karte) ist jedoch aus Gründen der Geschwindigkeit und des nur einmalig anfallenden Entwicklungsaufwands eine serverseitige Implementierung sinnvoll – der Server kann somit auch als Client agieren.
Datenbereitstellungsschicht
Die Datenbereitstellungsschicht, bzw. der Service Provider, ist die Kommunikationszentrale einer serviceorientierten Straßeninformationsstruktur. Er bietet auf der einen Seite standardisierte Web Services an und leitet diese auf der anderen Seite an die zuständige Stelle weiter. Die Implementierung der Datenbereitstellungsschicht erfolgt unabhängig von der Struktur der persistenten Datenhaltung; die einzige bekannte Struktur ist OKSTRA-XML.
OKSTRA-SIB-Mapping-Schicht
Die Übersetzungsarbeit zwischen OKSTRA und der in der jeweiligen persistenten Datenhaltung vorhandenen Struktur übernimmt die OKSTRA-SIB-Mapping-Schicht.
Datenhaltung
Innerhalb einer serviceorientierten Straßeninformationsstruktur können die persistenten Daten verteilt vorgehalten werden. Jedes Datenhaltungssystem enthält im Idealfall ausschließlich „seine“ Daten, wodurch Redundanzen und Inkonsistenzen zwischen den Systemen vermieden werden.
In der Abbildung 1 ist das Schichtenmodell der serviceorientierten Straßeninformationsstruktur schematisch dargestellt.
Abbildung 1: Serviceorientierte Straßeninformationsstruktur mit OKSTRA-konformen Web Services
3. Serverseitige Bereitstellung OKSTRA-konformer XML-Web Services
Die Serverapplikation zur Bereitstellung OKSTRA-konformer XML-Web Services besteht im Wesentlichen aus zwei Komponenten: der Datenbereitstellungsschicht und der OKSTRA-SIB- Mappingschicht. Erstere übernimmt sämtliche Kommunikationsaufgaben mit dem Client über Web Services. Sie ist OKSTRA-nativ, d. h. das ihr zugrunde gelegte Objektmodell wurde ohne weitere Modifikationen direkt aus den XML-Schemata mit Hilfe geeigneter Werkzeuge erstellt und um Web Feature Service-Methoden erweitert. Die Datenbereitstellungsschicht ist unabhängig von den vorhandenen persistenten Datenhaltungen (z.B. Datenbank, GIS-Systemen etc.) und einfach skalierbar – eine wesentliche Anforderung bei der Implementierung einer serviceorientierten Architektur.
Die zweite wesentliche Komponente der Serverapplikation stellt die OKSTRA-SIB-Mappingschicht dar. Sie verbindet die Datenbereitstellungsschicht mit den vorhandenen Datenhaltungen, in dem sie OKSTRA-XML in die „Sprache“ der jeweiligen Datenhaltungen „übersetzt“. Dieses Mapping ist unter fachlichen Gesichtspunkten der anspruchsvollste Teil innerhalb des Gesamtprozesses, da eine Vielzahl von fachlichen Transformationen vorgenommen und Anfragen des Clients, die zudem komplexen Filterkriterien genügen müssen, sinnvoll und performant abgearbeitet werden müssen.
4. Realisierung von Clientapplikationen
Im Vorfeld der Realisierung einer Fachanwendung sind, neben dem Entwurf des fachlichen Kernsystems, ebenso Fragen der lokalen persistenten Datenhaltung sowie der zu implementierenden Im- und Exportschnittstellen zu beantworten. Hier wurde mit dem OKSTRA ein neuer, universeller und moderner Standard geschaffen, der sich jedoch zur Modellierung persistenter Datenhaltungen – zumindest bei einer „eins-zu-eins“ Umsetzung – als wenig geeignet erwies (die Pflege der SQL- Schemata wurde aufgrund mangelnder Nachfrage eingestellt). Als Standard zum Datenaustausch gewinnt der OKSTRA zunehmend an Bedeutung.
Es soll jedoch an dieser Stelle betont werden, das die Realisierung von OKSTRA-konformen Schnittstellen, welche den zu recht hohen Anforderungen des Prüfwerkzeuges genügen, einen erheblichen initialen Entwicklungsaufwand bedingen, der oftmals nicht mit dem Leistungsumfang der Fachanwendung harmoniert. Somit werden noch immer Insellösungen geschaffen, obwohl dies durch die Entwicklung des OKSTRA vermieden werden sollte.
Effektiv wäre es, den OKSTRA als „verbindlich“ vorzuschreiben. Effizienter ist es hingegen, den Einstig in den OKSTRA zu vereinfachen, so dass bei der Entwicklung von Fachanwendungen der Fokus auf das Kernsystem und nicht auf die Schnittstellen gerichtet werden kann. Hierbei sind OKSTRA- konforme XML-Web Services hervorragend geeignet.
Grundvoraussetzungen für Clientanwendungen, welche die im Rahmen einer serviceorientierten Straßeninformationsinfrastruktur bereitgestellten Dienste nutzten möchten, sind eine Verbindung zum Internet/Intranet sowie eine Implementierung mittels einer modernen Entwicklungsumgebung (z.B. Microsoft .NET 2.0-Sprachfamilie). Die Web Services, die durch die Datenbereitstellungsschicht zur Verfügung gestellt werden, können in moderne Entwicklungsumgebungen einfach integriert und anschließend, analog zu traditionellen Datenquellen, abgefragt werden. Als geeignete Abfragesprache erwiesen sich die Filter-Spezifikationen des OpenGIS-Konsortiums, mit denen räumliche, vergleichende und logische Operationen intuitiv zusammengestellt werden können. Abbildung 2 enthält beispielhaft eine Abfrage, so wie sie auf Clientseite zusammengestellt und an den Server gesendet werden muss (für letzteres ist bei Verwendung von .NET 2.0 lediglich eine Zeile Programmcode erforderlich). Die aufgeführte Abfrage ist zwar recht lang, aber mit Grundkenntnissen in XML und SQL schnell verständlich.
Abbildung 2: Abfrage aller Abschnitte, die an einem bestimmten Nullpunkt beginnen oder enden und einem definierten Umkreis zugehörig sind
Ebenso wenig problematisch ist der Umgang mit den Ergebnissen in Form von OKSTRA-XML. Hierfür sind zwar OKSTRA-Kenntnisse erforderlich, jedoch müssen keine großen komplexen Austauschdatenbestände interpretiert werden, sondern nur das jeweilige Ergebnis der selbst definierten Abfrage (Abbildung 3).
Abbildung 3: OKSTRA-XML-Antwortobjekt zur Weiterverarbeitung im Client (Datenaufbereitungsschicht)
5. Fazit
Die Realisierung einer serviceorientierten Straßeninformationsstruktur auf Basis der vorhandenen Standards mit OKSTRA-konformen Web Services ist mit nicht unerheblichen Aufwendungen verbunden, die sich insbesondere aus der datenstrukturellen Diskrepanz zwischen OKSTRA und den verschiedenen persistenten Datenhaltungen ergeben. Ist diese Aufgabe jedoch „gestemmt“ ist der Weg für die Entwicklung (bzw. Anpassung) fachlich getriebener Clientanwendungen geebnet, in denen die Datenbank- und vor allem die Schnittstellenproblematik – so wie es durch den OKSTRA beabsichtigt war – in den Hintergrund tritt. |
