Heiko Hüter arbeitet seit über 10 Jahren bei der Firma NOVASIB und beschäftigt sich mit Themen rund um die Straßeninformationsbank. Aktuell arbeitet er als Projektleiter für Themen im Bereich offener, serviceorientierter Architekturen. Diese waren eine wesentliche Grundlage der neu geschaffenen Version TT-SIB 5. Fachliche Standards wie der OKSTRA sind hier von großer Bedeutung.

Die Dienstbesprechung „IT-Koordinierung im Straßenwesen“ (kurz: IT-KO) legt verschiedene Grundsätze für die Umsetzung neuer IT-Vorhaben im Straßenwesen fest. Diese sind in den „Entwicklungsgrundsätzen für IT-Vorhaben im Straßenwesen“ in der Version 1.0 vom 09.01.2008 dokumentiert. Im Bereich der Allgemeinen Grundsätze legt der Grundsatz 5 fest, dass neue Softwareprojekte auf Grundlage einer mehrschichtigen Architektur bestehend aus Datenhaltung, Datenbereitstellung, Datenaufbereitung und Datenpräsentation umgesetzt werden müssen. In weiteren Grundsätzen wird die Umsetzung der verschiedenen Schichten technisch vertieft. So legt der Grundsatz 20 zur Datenbereitstellung fest, dass der Zugriff auf die Datenhaltung über eine standardisierte Klassebibliothek (im Folgenden die OKLABI) erfolgen muss. Der Grundsatz 21 legt weiter fest, dass die öffentliche Schnittstelle der Datenbereitstellung in Form OKSTRA konformer Webservices erfolgen muss.

Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

Für die Umsetzung der Datenbereitstellung ergibt sich damit die im Folgenden beschrieben Struktur. Zum einen ist es notwendig, eine Schnittstelle „Nach Unten“ für den Zugriff auf die Datenhaltung zu definieren. Zum anderen muss die Schnittstelle „Nach Oben“, hin zur Datenaufbereitung und -präsentation, definiert werden. Das Bindeglied zwischen diesen beiden Schnittstellen stellt die OKLABI dar. Die Schnittstelle „Nach Oben“ ist als OKSTRA konformer Webservice definiert. Hierfür hat der IT-KO eine Arbeitsgruppe eingerichtet, die eine Beschreibung dieser Schnittstelle erarbeitet hat. Das Ergebnis der Arbeitsgruppe steht mit dem Dokument „Datenbereitstellungs-Schnittstelle für OKSTRA-Daten auf Basis des OGC Web Feature Service - OKSTRA-WFS“ zur Verfügung. Dieses wurde in der Version 1.0.2 am 09.12.2008 durch die OKSTRA Pflegestelle im Auftrag der Bundesanstalt für Straßenwesen verabschiedet. Die Umsetzung der Schnittstelle „Nach Unten“ muss abhängig von der jeweiligen Datenhaltung individuell angepasst werden. Für die Datenhaltung sind in der Praxis unterschiedliche Systeme im Einsatz, die auch jeweils unterschiedliche Plattformen und Datenstrukturen verwenden. Dies ist fachlich notwendig, um die unterschiedlichen Arbeitsprozesse optimal unterstützen zu können. Für eine Standardisierte Datenbereitstellung ist es notwendig, diese Proprietären Strukturen in ein einheitliches, fachliches Modell, wie es der OKSTRA bereitstellt, zu transformieren. Die notwendigen Abbildungsvorschriften müssen fachlich für jede Datenhaltung definiert werden. Die technische Umsetzung muss danach unter Einbindung des jeweiligen Herstellers für die Datenhaltung erfolgen. Diese müssen Ihre Systeme an die definierte Schnittstelle der OKLABI anbinden.

Der Vortrag zeigt, welche Anforderungen sich daraus für die OKLABI und weitere beteiligte Systeme ergeben. Danach wird ganz konkret gezeigt, wie die Umsetzung auf Grundlage einer konkreten Datenhaltung, der Straßeninformationsbank TT-SIB, erfolgen kann. Hierbei sind neben den organisatorischen auch einige interessante, technische Fragestellungen zu beachten.

Die Datenbereitstellung für eine SIB soll über OKSTRA konforme Webdienste in Form eines OKSTRA-WFS erfolgen. Dieser basiert auf dem WFS Standard des OGC ergänzt um den OKSTRA als Anwendungsschema. Gleichzeitig erfolgte ein Tailoring, um den zu unterstützenden Teil des Standards genauer zu beschreiben. Im Ergebnis dieses Tailorings wurde ein Profil für einen solchen Dienst durch eine Expertengruppe erarbeitet und über die OKSTRA Pflegestelle veröffentlicht.

Die Implementierung des OKSTRA-WFS soll allgemeingültig für alle Datenhaltungen erfolgen. Voraussetzung hierfür ist, dass die notwendige Schnittstelle (API) definiert wird. Diese Schnittstelle muss es der OKSTRA-WFS Implementierung ermöglichen, WFS Anfragen an die Datenhaltung zu stellen und das Ergebnis zu erhalten.
Dabei müssen die notwendigen WFS-Anfragen:

• GetCapabilities (teilweise)
• DescribeFeatureType (teilweise)
• GetFeature
• LockFeature
• GetFeatureWithLock
• Transaction (Insert / Delete / Update)

unterstützt werden. Diese API wird im Folgenden als Schnittstelle nach oben bezeichnet.

Die Ausführung der Anfragen erfolgt innerhalb der konkreten Datenhaltung und ist damit abhängig von den hier verwendeten Strukturen. Die Umsetzung muss durch den jeweiligen Hersteller der Datenhaltung erfolgen. Dafür muss eine API definiert werden, welche es den SIB Herstellern ermöglicht, ihre konkrete Umsetzung zu registrieren. Diese API wird im Folgenden als Schnittstelle nach unten bezeichnet. Beide Schnittstellen zusammen werden in einer neuen Bibliothek „OKSTRA-WFS Anfragen“ zusammengefasst. Soweit es sich um die direkte Verarbeitung von OKSTRA Objekten, deren Ein- und Ausgabe sowie Weitergabe handelt, werden die vorhandenen Funktionen der OKLABI verwendet. Diese wird in allen drei Ebenen eingesetzt. Somit ergibt sich der Folgende schematische Aufbau:

Die Umsetzung eines OKSTRA-WFS kann damit unabhängig von der zugrunde liegenden SIB erfolgen. Wichtig ist hierbei allerdings, dass die API hin zur SIB standardisiert ist und technisch in die bestehende Infrastruktur eingebunden werden kann. Hierfür sind einige interessante Inhaltliche und technische Fragestellungen zu beachten. 

Fachliche Abbildung (Mapping) der Datenhaltung in den OKSTRA

Die Strukturen in der Datenhaltung richten sich nach den geforderten Anwendungsfällen der Anwender. Hierfür müssen die konkreten Geschäftsprozesse unterstützt werden, welche in den einzelnen Bundesländern etabliert sind. Gleichzeitig ist auch sicherzustellen, dass dies mit einer ausreichenden Geschwindigkeit erfolgt. Dies bedingt teilweise auch, Felder vorzuhalten, welche über den Stand der ASB bzw. des OKSTRA hinausgehen oder auch die Objektbeziehungen anders abzulegen. Durch eine Denormalisierung des Datenmodells können z.B. in der Praxis Geschwindigkeitsvorteile in der täglichen Arbeit erreicht werden.

Der OKSTRA stellt demgegenüber ein Modell zum Datenaustausch bereit. Hier geht es um ein möglichst einfaches Datenmodell, welches die Vorgaben der jeweiligen Regelwerke direkt umsetzt. Dabei sollen die Daten möglichst kompakt und ohne Redundanzen beschrieben werden. Die unterschiedlichen Ziele des OKSTRA und der Datenhaltung einer SIB bedingen auch eine unterschiedliche Modellierung. Um die Daten einer konkreten Datenhaltung über den OKSTRA bereitzustellen ist eine fachliche Abbildung notwendig. Diese muss in beide Richtungen möglich sein. Zum einen müssen die Daten aus der Datenhaltung in den OKSTRA abbildbar sein. Zum anderen müssen aber auch die Objekte des OKSTRA sich in die Strukturen der Datenhaltung abbilden lassen. Die dafür notwendigen fachlichen Regeln müssen mit den jeweiligen Anwendern abgestimmt und durch den Hersteller der Datenhaltung implementiert werden. Das Mapping erfolgt dabei immer auf Grundlage einer bestimmten Version der Datenhaltung und einer Version des OKSTRA. Damit wird die OKSTRA Version des OKSTRA-WFS durch die Datenhaltung festgelegt. Auf eine automatische Migration in eine andere Version sollte der Dienst verzichten, da dies zu Performanceeinbußen und ggf. einer Verfälschung der Daten führt. Wenn ein Anwender eine automatische Migration wünscht, kann er hierfür das Ergebnis der WFS Anfrage über die OKLABI in eine andere OKSTRA Version migrieren. 

Leistungsfähigkeit der OKLABI

Die OKSTRA Klassenbibliothek stellt die folgenden Funktionen bereit:

• Metadatenmodell
• Version, FblVersion
• Objektartfilter, Fachbedeutungsliste
• Objektart, Eigenschaft
• OKSTRA^® Objektmodell
• Datenbestand, Fachobjekt
• einfache Datentypen, Aufzählungen, Datum, Koordinate, Geometrie, AnyType
• Hilfsklassen
• Ein-/Ausgabekonverter für CTE und XML
• Dateieingabe, -ausgabe, Textpuffer, Binaerdaten
• Umgebung, Protokollant, Fortschrittswächter, Abbruchsignal, Ausnahme
• Transaktion, DBImporteuer, DBExporteur

Mit Hilfe dieser Klassen lassen sich OKSTRA^® Daten aus XML oder CTE Dateien importieren oder in diese exportieren. Des Weiteren können OKSTRA^® Objekte programmatisch erzeugt werden (z.B. aus dem Ergebnis einer Datenbankabfrage) oder aus der OKLABI abgefragt werden (z.B. um sie wieder in die Datenbank zu schreiben). Die dritte wesentliche Leistung der OKLABI betrifft die Versionsverwaltung des OKSTRA^®. Jedes Fachobjekt stellt die Funktion Migriere bereit. Damit lassen sich Fachobjekte aus einer OKSTRA^® Version in eine andere OKSTRA^® Version abbilden (soweit diese Abbildung technisch und fachlich möglich ist). 

Plattformneutralität der OKLABI

Die OKLABI ist keine rein konzeptionelle Schnittstelle, sondern ein konkretes Software-Produkt. Wird die OKLABI als Schnittstelle festgelegt, muss sichergestellt werden, dass sie sich in die bestehenden Anwendungen integrieren lässt. Dies wird dadurch erschwert, dass in der Praxis ein heterogenes Umfeld für die Softwareentwicklung und Laufzeitumgebung existiert. Im Wesentlichen gibt es die folgenden Entwicklungsumgebungen zu beachten:

• C / C++ Programmierung
• .NET Programmierspachen (z.B. C#)
• Java

Neben der Programmiersprache ist auch die Laufzeitumgebung zu beachten. Hier ist zwischen managed und unmanaged code zu unterscheiden. Managed Code bedeutet, dass dieser nicht direkt auf der Ebene des Betriebssystems aufsetzt, sondern nur innerhalb einer eigenen Laufzeitumgebung ausgeführt werden kann. Diese Laufzeitumgebung übernimmt bestimmte Teilaufgaben (z.B. die Speicherverwaltung) und entlastet die Anwendungsentwicklung davon. Aktuell gibt es im Wesentlichen zwei relevante Laufzeitumgebungen. Im Bereich der .NET Entwicklung ist dies die Common Language Infrastructure (CLI). Daneben gibt es die Java Laufzeitumgebung (JRE), welche im Bereich der Java Programmierung zum Einsatz kommt.

Unmanaged Code läuft unabhängig von einer eigenen Laufzeitumgebung und direkt innerhalb des jeweiligen Betriebssystems (als native Bibliothek). Beispiel hierfür ist die direkte Programmierung in C bzw. C++.

Ein dritter Aspekt neben der Programmiersprache und der Laufzeitumgebung betrifft die Wahl des Betriebssystems, auf dem die Anwendung installiert wird. Im Bereich der Cliententwicklung gibt es hier im Wesentlichen nur Microsoft Windows zu beachten (größtenteils auch noch 32bit). Serverseitig sind hier allerdings auch noch Unix basierte Betriebssysteme (z.B. Linux) im Einsatz. Darüber hinaus werden größtenteils 64bit Versionen verwendet.

Die OKLABI stellt Schnittstellen für diese unterschiedlichen Anwendungsfälle bereit. Die OKLABI selber ist dabei als C++ Bibliothek implementiert. Für die weiteren Zugriffsvarianten werden Wrapper bereitgestellt.

Entwicklung der Bibliothek für OKSTRA-WFS Anfragen:

Für die Entwicklung der OKLABI wurde sehr viel Arbeit dafür betrieben, die Verwendbarkeit in den unterschiedlichsten Umgebungen zu ermöglichen. Auf diese dadurch gewonnenen Erfahrungen soll auch für die neu zu schaffende Bibliothek zurückgegriffen werden. Diese wird zwar als eigenständige Bibliothek neben der OKLABI entwickelt, basiert aber auf den gleichen technologischen Ansätzen. Wo die OKLABI bereits die notwendigen Funktionen und Strukturen definiert, werden diese auch wiederverwendet. Im Folgenden wird das Design für diese neue API beschrieben. Im Anschluss daran, werden die auftretenden technischen Fragen behandelt.

Der OKSTRA-WFS muss die Möglichkeit erhalten, die Parameter einer Anfrage an die SIB Schicht weiterzuleiten. Danach ist es Aufgabe der SIB Anbindung die Abfrage auszuführen und das Ergebnis an den OKSTRA-WFS zurückzugeben. Die Schnittstellen für die Anfragen müssen SIB Neutral definiert werden. Je nachdem, auf welche konkrete Datenhaltung zugegriffen wird, müssen zur Laufzeit allerdings unterschiedliche Implementierungen verwendet werden. Eine Möglichkeit, dies zu modellieren stellt das Factory Entwurfsmuster dar. eine Factory definiert eine Schnittstelle, mit deren Hilfe Instanzen für die einzelnen Anfragen erzeugt werden können. Die Implementierung der Factory und der Schnittstellen für die Anfragen erfolgt durch den SIB Hersteller. Die Bibliothek muss die Möglichkeit bieten, die konkrete Implementierung zu registrieren. Der OKSTRA-WFS greift dann auf diese registrierte Factory zu. Die Folgende Abbildung zeigt ein Modell dieser Umsetzung:

Ein typischer Ablauf sieht dann vereinfacht wie folgt aus: Der OKSTRA-WFS erhält eine Anfrage vom Client. Er parst die übergebene XML-Anfrage und liest die Parameter ein. Danach holt er über die OKLABI die Implementierung für die RequestFactory und erzeugt damit eine konkrete Instanz für die Umsetzung der Anfrage. Danach initialisiert er diese Instanz mit den Parametern, die er vom Client erhalten hat. Als nächstes wird die Anfrage ausgeführt. Dabei übergibt der OKSTRA-WFS einen, am Anfang noch leeren, Datenbestand der OKLABI. Aufgabe der Implementierung des SIB Herstellers ist es, die Parameter der Anfrage auszuwerten, die gesuchten Objekte aus seiner Datenhaltung auszulesen, in den OKSTRA zu transformieren und damit den übergebenen Datenbestand zu füllen. Der OKSTRA-WFS erhält im Ergebnis den gefüllten Datenbestand und leitet ihn an den Aufrufer weiter. Hierfür kann er auf die Funktionalität der OKLABI zu Serialisierung eines Datenbestandes nach OKSTRA-XML zurückgreifen. 

Technische Fragestellung der Umsetzung

Die definierten Wrapper ermöglichen es einer bestehenden Anwendung, die OKLABI einzubinden und zu verwenden. So kann z.B. ein in C# programmiertes Werkzeug die OKLABI dazu verwenden, OKSTRA Objekte einzulesen, zu verarbeiten und wieder auszugeben. In gleicher Art und Weise ist dies auch für ein Java Programm möglich. Dieser Anwendungsfall wurde bereits mehrfach in der Praxis getestet und hat sich bewährt.

Für die beschriebene Umsetzung eines OKSTRA-WFS reicht dies alleine allerdings nicht aus. Bedingt durch die drei unterschiedlichen Ebenen mit jeweils drei unterschiedlichen Herstellern kann nicht erwartet werden, dass immer nur eine gemeinsame Laufzeitumgebung zum Einsatz kommt. Insbesondere für die Anbindung der unterschiedlichen SIBs ist nicht zu erwarten, dass es hier eine gemeinsame Laufzeitumgebung gibt. Hier sind sowohl Java basierte Umsetzung als auch .NET basierte Umsetzungen zu erwarten. Wichtig dabei ist, dass dies nicht nur eine unterschiedliche Programmiersprache, sondern auch unterschiedliche Laufzeitumgebungen bedeutet. Hier stellt sich die interessante technische Fragestellung, wie Instanzen zwischen verschiedenen Laufzeitumgebungen ausgetauscht werden können. Die folgende Abbildung zeigt die Variante, dass der OKSTRA-WFS in einer JRE läuft und ein SIB Hersteller seine Anbindung in einer managed .NET Umgebung (CLI) bereitstellt.

Der Ablauf sieht jetzt so aus, dass aus dem Java Prozess des OKSTRA-WFS heraus die RequestFactory Instanz aufgerufen werden muss, welche innerhalb der CLI läuft. Hierfür sind mehrere Übergänge zwischen den Laufzeitumgebungen notwendig. Zum einen muss aus Der Java Runtime auf den unmanaged code der OKLABI zugegriffen werden. Dieser Aufruf muss dann wieder auf den managed Code innerhalb der CLI zugreifen. Bei diesen Übergängen ist sicherzustellen, dass die Objektidentität erhalten bleibt.

Da diese mehrfachen Übergänge bisher noch nicht im Rahmen der OKLABI vorgekommen sind, soll die Machbarkeit im Vorfeld durch einen Prototyp untersucht werden. Danach kann die Entscheidung getroffen werden, ob die angestrebte Architektur realisierbar ist oder man andere Alternativen überprüfen muss.

Im Rahmen des Prototyps werden dabei exemplarisch zwei WFS Anfragen untersucht. Die erste Anfrage ist eine GetFeature Anfrage. Hiermit wird das Szenario abgedeckt, dass eine ggf. größere Menge von Daten aus der Datenhaltung abgerufen und an den Client übertragen werden soll. Der umgekehrte Fall wird durch die Transaction – Insert Operation abgedeckt. Hier schickt der Client eine größere Datenmenge an die Datenhaltung, welche diese dann übernehmen muss. Wenn beide Anwendungsfälle im Rahmen des Prototyps erfolgreich umsetzbar sind, ist die Umsetzung eines kompletten OKSTRA-WFS mit dieser Architektur möglich.