Cids ist eine Plattform für die Entwicklung von Informationssystemen, bei denen die den Nutzer unterstützenden Geschäftsprozesse eine Vielzahl von heterogenen Informationsquellen, Geschäftsprozessen und Werkzeugen zusammenführen müssen, darunter auch Geo-Daten und Geo-Daten-Dienste. Diese – cids genannte – Plattform findet Anwendung in unterschiedlichsten Projekte und Lösungen. Sie integriert Prinzipien und Werkzeuge des modernen Software-Engineerings mit der verteilten Welt moderner Geodienste.
Viele praktische Anwendungen in Unternehmen und Behörden erfordern die Integration von Geodaten, Faktendaten, anderen Artefakten sowie Prozessen aus unterschiedlichen Werkzeugen. Häufig werden die Ursprungsinformationen in unterschiedlichen Systemen gepflegt (GIS-Datenquellen, Datenbanken, Dokumenten-Managementsysteme, ERP-Systeme usw.). Oft werden auch Geschäftsprozesse in unterschiedlichen Werkzeugen abgewickelt (GIS-Systeme, ERP-Systeme, spezialisierte Software). Häufig existieren explizite oder implizite logische Beziehungen zwischen diesen verteilten Artefakten, welche für konkrete Geschäftsprozesse von Endnutzern maßgeblich sind (Abbildung 1).
Abb. 1: Systembarrieren
Durch die Systembarrieren der unterschiedlichen Systeme und Werkzeuge wird die Implementierung von Anwendungen, welche auf diesen logischen Beziehungen beruhen, i.d.R. massiv behindert. Dies führt oft zu zwei unterschiedlichen Situationen: a) der Geschäftsprozeß wird mit erheblichem Aufwand mit den Mitteln eines der Werkzeuge implementiert (z.B. mit GIS-basierten APIs, alles andere wird „dazu programmiert“); b) der Benutzer wird dazu gezwungen, manuell das System zu wechseln und jeweils das Originalsystem (welches die Originaldaten pflegt) zu verwenden. Während der zweite (häufige Fall) eigentlich Nutzern nicht zuzumuten ist (aber dennoch häufig vorkommt), führt der erste Fall einerseits zu erheblichen Integrationskosten, aber auch zu einem schwer zu wartenden „Zoo“ von einzeln integrierten Lösungen im Unternehmen, welche meist noch nicht einmal miteinander kompatibel sind.
Die in diesem Artikel vorgestellte Plattform cids geht ursprünglich auf ein Projekt zurück welches 1999 startete, und in welchem ein System namens WuNDa (Wuppertal Navigation and Data Management System, siehe (Güttler 2000)) entwickelt wurde. Erstes Ziel des Systems war es, eine Systemübergreifende Sicht über Datenbestände mit Bezug zu Umwelt- und Planungsfragen herzustellen, insbesondere zur einfachen Recherche auch durch Nutzer die wenig GIS-Erfahrung haben. Darüber hinaus war angestrebt eine einheitliche, generische Plattform zu schaffen, welche den erwähnten „Anwendungs-Zoo“ vermeiden hilft. WuNDa beinhaltet heute außer dieser generischen Plattform (aus der cids entstanden ist) eine Vielzahl von integrierten Fachverfahren, wird von Anwendern in unterschiedlichen Abteilungen genutzt und unterstützt die System-Manager bei der Pflege der angeschlossenen Systeme und Dienste. Abbildung 2 zeigt die Systemarchitektur der Plattform.
Abb. 2: Plattform-Architektur
Kern der Integrationsschicht ist eine Menge von Diensten, welche gemeinsam mit der sogenannten Integration Base verteilte Informationsquellen und Anwendungsprozesse in eine cids-SOA einbringt. Die logische Topologie dieser Vernetzung ist durch ein Domänenkonzept voll skalierbar, sowohl hinsichtlich der Verteilung von Lasten als auch hinsichtlich organisatorischer Aspekte. Es kann beliebig viele Domain Server geben, welche eine Integration Base publizieren. Die Intelligenz der Vernetzung steckt in der jeweiligen Integration Base, welche das Wissen über eines oder mehrere Quellsysteme abbildet. Die Integration Base beinhaltet auch umfangreiche Mechanismen für das Management von Nutzern, Gruppen, Rollen, deren Authentifizierung und Autorisierung sowie für die Personalisierung der Nutzersicht auf das Gesamtsystem. Ein Registry Server und ein Broker unterstützen die Anwendungen beim Zugriff auf die Dienste. Die angeschlossenen Quellsysteme können Systeme beliebigen Typs sein, darunter auch Geodaten-Dienste, welche über OGC-konforme Interfaces (WMS, WFS, SWE-Services und so fort) angesprochen werden. Für Endnutzeranwendungen gibt es in der nächst höheren Schicht drei unterschiedliche Typen: a) der Navigator, bzw. Navigatorbasierte Endanwendungen, b) rein Kartenbasierte Anwendungen (auf Basis von cismap) und c) spezialisierte Geo-Workflows (CustomApps). Sowohl der Navigator als auch die Geo-Komponente cismap sind generische Werkzeuge, welche alleine durch Konfiguration eines cids-Systems verwendbar sind. Auf der nächsthöheren Schicht können diese drei Anwendungstypen durch ein Plug-In-Konzept ineinander „gesteckt“ werden. Der simpelste Fall ist die Standard-Konfiguration des Navigators, welcher selbst eine Kartenkomponente beinhaltet, und welcher der Navigation und Recherche durch die gesamte verteilte Unternehmensinformation quer über alle Systeme dient, geographisch wie faktenbasiert. Darüber hinaus ist es möglich, daß CustomApps eine Kartenkomponente für die Geo-Navigation verwenden und es können auch komplette CustomApps in eine Navigator-Anwendung gesteckt werden. Mit diesem Mechanismus kann man nutzerspezifische Arbeitsumgebungen mit einem Navigator und mehreren Fachanwendungen bereitstellen.
CIDS-Systeme werden werkzeuggestützt analog zur üblichen Vorgehensweise in IDE-basierten Software-Projekten (Interactive Development Environment) entwickelt und als fertige Distributionen ausgeliefert. In einer Standard-IDE (NetBeans) werden Kunden- und Anwendungsspezifische Anpassungen des Navigators durchgeführt, oder es werden die Geo-Workflows der CustomApps auf Basis der vorhandenen cids-APIs entwickelt. Im CIDS-ABF werden komplette cids-Distributionen bearbeitet. Hier werden die Informationsmodelle entworfen, welche die Sichten auf die Quellsysteme abbilden, Zugriffe auf die Quellsysteme konfiguriert und Darstellungselemente für diese Informationsmodelle entwickelt. Hier werden auch Nutzer, Rechte, Konfigurationen für individuelle Nutzer und Gruppen sowie die gesamte Personalisierung verwaltet. Der ABF erzeugt auch die auslieferbaren Distributionen der Information Bases und der Dienste. Das Werkzeug JPresso ist ein mächtiges ETL-Werkzeug, mit dem die Synchronisation zwischen den Quellsystemen und der Information Base konfiguriert und gesteuert wird.
Ein entscheidendes Merkmal des Integrationskonzeptes ist es, daß cids im Gegensatz zu herkömmlichen Systemen keinerlei Informationsklassen vorschreibt. Es wird nicht vorab und durch das System definiert, welches Informationsmodell zu einem Grundstück, einem Abwasserkanal, einer Begrenzungsmauer, einer Altlast usw. gehört. Es gibt eine klare Vorgehensweise (deren Darstellung diesen Artikel sprengen würde), wie Informationsklassen ins System eingebracht, im ABF modelliert und konfiguriert werden. Dies kann auch die Anwendungsspezifische Programmierung bestimmter Komponenten beinhalten, allerdings nach klar vordefinierten software patterns. Das zentrale Element dieser Modellierung ist ein sogenanntes Thema. Ein Thema besteht aus dem Informationsmodell für einen Anwendungstyp (z.B. „Abwasser-Management“), und beinhaltet i.d.R. (aber nicht zwingenderweise) einer Menge von GUI-Klassen für die Interaktion mit dem Nutzer (sogenannte Renderer und Editoren). Ein Thema kann Informationen aus unterschiedlichen Quellsystemen zusammenführen (um die in Kapitel 1 erwähnten Verknüpfungen herzustellen), insbesondere auch Verknüpfungen der Informationen aus Geodaten-Diensten mit solchen aus Fachsystemen oder anderen Systemen (ERP, Dokumenten-Management etc.). Für einzelne Teilmodelle des Themas kann das Originalsystem das führende (also änderungsberechtigte) System sein, für andere Teile kann die Integration Base führend sein. Das gleiche Thema kann auch Klassen und Attribute beinhalten, die alleine in der Integration Base residieren. Das heißt konkret: ein Thema kann eine über mehrere Systeme verteilt gehaltene Datenbasis sein, inklusive Geo-Layers aus OGC-konformen Diensten sowie einzelnen lokalen oder im Netzwerk vorhandenen Geometrie-Ressourcen. Zusammen mit den GUI-Elementen bildet jedes Thema ein eigenes, manchmal einfaches, manchmal hochkomplexes Informationssystem. Insofern Teilmodelle (oder das gesamte Thema) in einem Quellsystem persistent residieren, werden durch JPresso Synchronisationsregeln definiert, welche einen Teil oder das ganze Informationsmodell vom Quellsystem in die Integration Base replizieren. Dies dient zwei Zwecken: a) der Beschleunigung von Recherchen (die Integration Base ist darauf hin optimiert), und b) der Entlastung der Originalsysteme, welche sonst bei jeder netzweiten Recherche-Anfrage belastet würden.
Der Navigator ist das „Schweizermesser“ der Plattform. Er wird bei jeder Distribution mit ausgeliefert, und bietet ein mächtiges generelles Recherche-Werkzeug, mit dem man das gesamte Informationsnetz über alle Quellsysteme recherchieren kann. Der Navigator beinhaltet einen Katalog (links), welcher Nutzerspezifisch konfiguriert werden kann, also nur die Themen anbietet welche der Nutzer benötigt oder auf die der Nutzer zugreifen darf. Die Recherche kann nach Fakten, nach Geographie, nach Artefakten, gemischt und nach Themen gefiltert geschehen. Suchergebnisse können unter Wahrung des Kontexts nach Fakten oder in der Geographie dargestellt werden. Sofern der Nutzer die entsprechenden Rechte besitzt, kann er auch Geometrien und Faktendaten modifizieren, die Faktendaten bearbeitet der Nutzer in besagtem Editor. Das rechte Beispiel aus Abbildung 3 zeigt daß es sich hier im Prinzip um ein eigenständiges Informationssystem handelt (das System wird derzeit für das Land Mecklenburg Vorpommern entwickelt und dient der Unterstützung von Vorgängen rund um die EU Wasserrahmenrichtlinie). Dieser Editor erscheint in der Nutzeroberfläche alternativ zur Kartenkomponente, wenn man einem Fachdatenobjekt manipuliert, Elemente solcher Editoren können auch Bilder, Diagramme, dynamische Webcams, wiederum Geometrien usw. sein.
Abb. 3: Der Navigator bei der Stadt Wuppertal (links), Editor zu einem komplexen Thema im System WRRL für das Land Mecklenburg Vorpommern (rechts)
Der Navigator kann als Einzelanwendung für die unternehmensweite Recherche eingesetzt werden. Er ist aber auch häufig (wie hier) der Rahmen für die gesamte Nutzeroberfläche. Durch das Plug-In-Konzept kann man Nutzern auch einen für sie konfigurierten Navigator anbieten, in dem (als weitere Tab-Fenster) eine oder mehrere CustomApps laufen. Damit gibt man Endnutzern eine für sie konfigurierte Workbench, welche den Navigator für die allgemeine Recherche sowie alle sie betreffenden Fachanwendungen beinhaltet. Selbstverständlich kann man dabei Selektionen, Suchergebnisse usw. vom Navigator in die Fachanwendungen übernehmen und umgekehrt, z.B. zum Zweck der Visualisierung.
Abbildung 4 zeigt zwei Beispiele von CustomApps. In beiden Fällen sieht man, daß die Workflows aus einer Kombination aus „datenbankartiger“ und geographischer Benutzeroberfläche besteht. Das BELIS-System ist ein städtisches Beleuchtungskataster. Das VERDIS-System dient der Berechnung von Abwassergebühren, welche aufgrund einer städtischen Satzung den Grad der Versiegelung von Grundstücken in die Gebührenberechnung einbeziehen muss. In der Oberfläche interagiert der Nutzer sowohl mit den Informationen des Quellsystems als auch mit den Geometrien, welche die einzelnen Versiegelungstypen auf dem Grundstück (Rasen, Dach, Beton,…) darstellen. Bei Änderungen werden Prozesse in einem ERP-System angestoßen (z.B. Versenden eines neuen Bescheids).
Abb. 4: CustomApps BELIS (links) und VERDIS (r)echts) ###Einbettung externer Rechenprozesse Es gibt Anwendungen bei denen numerische Modelle eine Rolle spielen. Auch diese Prozesse können mit der Plattform verknüpft werden. Beim System ANAITE wird der Gewässerschutz an einem Fluß in der Nähe eines Petro-Chemischen Komplexes in Mexiko unterstützt (DENZER 2011). Hydrologische Modelle werden als Dienste eingebunden. Im Projekt SUDPLAN (GIDHAGEN 2010, SANDER 2011) entsteht ein „Urban Climate Change Scenario Management System“, in welchem Nutzer außer Datenmanagement und Visualisierung auch Modelle, deren Konfigurationen und Scharen von parametrisierten model runs in mehreren Ausführungsmodi (on-the-fly, asynchron, vorberechnet) managen kann.
Literatur DENZER R. (2011), TORRES-BEJARANO F., HELL T., FRYSINGER S., SCHLOBINSKI S., GÜTTLER R., RAMIREZ H., An Environmental Decision Support System for Water Issues in the Oil Industry, Proceedings ISESS 2011, Springer, in press DENZER R. (2011), SCHLOBINSKI S., GIDHAGEN L., A Decision Support System for Urban Climate Change Adaptation, Proceedings of the 44th Hawaii International Con-ference on System Sciences (HICSS-44), CDROM, IEEE Computer Society GÜTTLER R. (2000), DENZER R., HOUY P., An EIS Called WuNDa, Environmental Software, in: DENZER R. et al (eds.) Systems Vol. 3 (2000) – Environmental Infor-mation and Decision Support, pp. 114-121, Kluwer Academic Publishers GIDHAGEN L. (2010), DENZER R., SCHLOBINSKI S., MICHEL F., KUTSCHERA P., HAVLIK D., Sustainable Urban Development Planner for Climate Change Adaptation (SUDPLAN), Proceedings of ENVIP’2010 workshop at EnviroInfo2010, ISSN 1613-0073, urn:nbn:de:0074-679-9 SANDER S. (2011), HOPPE H. F., SCHLOBINSKI S., Integrating Climate Change in the Urban Planning Process – A Case Study, Proceedings ISESS 2011, Springer, in press
Zurück zur Hauptseite
