Ein "übergeordneter GeoShop", im Weiteren als Portalserver bezeichnet, vereint die Funktionalität von verteilten und unabhängig betriebenen GeoShop Servern, hier als Datenserver bezeichnet. Bemerkung: In der Studie [1] wurden die Begriffe "primärer Server" für den Portalserver und "sekundärer Server" für die Datenserver benutzt. Der Portalserver und die an im angeschlossenen Datenserver bilden ein Netz von untereinander verbunden GeoShop Servern. Der Portalserver enthält bis auf wenige Ausnahmen (z.B. Metadaten oder Rasterdaten) keine eigenen Daten. Die Daten sind ausschliesslich in den angeschlossenen Datenservern in Form von INTERLIS .itf Dateien abgelegt. Für den Benutzer eines Portalserver ist kein Unterschied zu der Benutzung eines lokalen Datenserver feststellbar. Der Portalserver leitet z.B. Datenbestellungen automatisch an die angeschlossenen lokalen Datenserver weiter, mischt dann die Teilresultate und liefert das Gesamtresultat an den Benutzer. Auf dem Portalserver stehen ausserdem die gleichen Werkzeuge für die Datenbestellung und Visualisierung wie auf einem lokalen Datenserver zur Verfügung. Im Folgenden sind die Funktionalitäten des Portalserver in der hier beschriebenen Version zusammengestellt:
Verteilt Datenbestellung über die angeschlossenen lokalen Datenserver.
Mischt die Teilresultate der angeschlossenen lokalen Datenserver zu einem Gesamtresultat.
Visualisiert die Metadaten der angeschlossenen lokalen Datenserver.
Berechnet den Gesamtpreis einer Bestellung.
Hat selber die volle Funktionalität eines Datenserver.
Kann selber wieder ein Datenserver in einem übergeordneten Netz sein.
Obwohl die einzelnen Datenserver unabhängig von einander betrieben werden, müssen gewisse Bedingungen innerhalb der Datenserver eines Netzes erfüllt sein, damit sie an einen gemeinsamen Portalserver angeschlossen werden können:
Es müssen die gleichen INTERLIS Datenmodelle auf den Datenservern wie auf dem Portalserver implementiert sein.
Es müssen die gleichen Datenprodukte auf den Datenservern wie auf dem Portalserver vorhanden sein.
Bei globalen Visualisierungen müssen die gleichen Darstellungsmodelle auf den Datenservern wie auf dem Portalserver vorhanden sein.
Nur wenn diese Bedingungen erfüllt sind (vor allem die 2. Bedingung), können auch Datenbestellungen mit einem homogenen Gesamtresultat vom Portalserver erwartet werden. Obwohl das nicht zwingend notwendig ist empfiehlt es sich daher einen standardisierten GeoShop als lokalen Datenserver zu definieren welcher von allem am Netz beteiligten GeoShop Betreibern einheitlich mit Daten gefüllt wird. Dieser lokale Standard Datenserver (manchmal auch als Datenrucksack bezeichnet) enthält alle Definitionen (Datenmodelle, Produkte, Darstellungen) welche vom globalen Portalserver erwartet werden (s.a. Figur).
 |
Eine lokale GeoShop Installation mit Betreiber spezifischen Konfigurationen beliefert den lokal vorhanden Standard Datenserver, welcher dann seinerseits mit dem Portalserver kommuniziert.
Oft werden die lokalen GeoShop Server in einem Intranet ohne direkte Zugriffsmöglichkeiten aus dem Internet betrieben. Der Standard Datenserver wird in diesem Fall in der DMZ (demilitarisierte Zone) aufgestellt (s.a. Figur). Damit ermöglichen die Standard Datenserver gleichzeitig auch den Zugriff auf die lokal vorhandenen Daten über das Internet.
![[Anmerkung]](images/note.png) | |
Auf der migelieferten Referenz CD ist bereits ein vollständig konfigurierter Vorschlag für einen Standard Datenserver und den dazugehörigen Portalserver enthalten (vorkonfiguriert für DM01AVCH24D bzw. SIA405 1998, s.a. Anhang). |
| |
Es ist grundsätzlich möglich die Installation des lokalen GeoShop mit der Installation des Standard Datenserver zu mischen und als einen einzigen GeoShop zu betreiben. Im Sinne der Klarheit und Einfachheit empfehlen wir das jedoch ausdrücklich nicht. Auch das in der Figur dargestellte Zugriffsproblem via die DMZ spricht gegen das Mischen der Installationen. |
In den folgenden Abschnitten sind die einzelnen Datenflüsse zwischen den Datenservern und dem Portalserver beschrieben (Upload, Löschen, Download).
Der Upload von Daten läuft wie folgt ab:
Die lokale GeoShop Installation produziert die Daten gemäss den Spezifikationen des Standard Datenserver und schickt die Daten in Form von INTERLIS .itf per FTP an den lokalen Standard Datenserver. Bei geeigneter Konfiguration des lokalen GeoShop erfolgt die Weiterleitung der .itf Dateien automatisch (s.a. unten).
Der Standard Datenserver übernimmt die .itf Daten und führt die üblichen Schritte durch, d.h. Indizierung der Daten (.idx Datei) und Generierung der Graphik (.geo Datei). Die einzige Schnittstelle zum lokalen GeoShop bilden also die per FTP übermittelten systemneutralen .itf Dateien. Es ist daher grundsätzlich denkbar, dass der lokale GeoShop auch ein anderes System (d.h. kein GeoShop) sein könnte, sofern das System in der Lage ist INTERLIS .itf Dateien zu liefern.
Je nach Konfiguration des Standard Datenserver wird die entstandene .idx Datei (= kompilierte Metadatei) und / oder die erzeugten .geo Dateien (Graphik) an den Portalserver weiter geleitet. Bemerkung: Falls dies gewünscht wird, ist auch die Weiterleitung von .itf Dateien an den Portalserver grundsätzlich möglich (Replikation der Originaldaten). Dieses Feature kann z.B. dazu benutzt werden um die Replikation der .itf Dateien vom lokalen GeoShop zum lokalen Standard Datenserver zu automatisieren. Die automatisierte Weiterleitung der Dateien (lokaler GeoShop => Standard Datenserver => Portalserver => übergeordneter Portalserver) wird von uns als Cascading Upload bezeichnet.
Aufgrund der erhaltenen .idx Dateien (= kompilierte Metadateien) ist der Portalserver im Bild welche Daten auf dem lokalen Standard Datenserver vorhanden sind. Falls an den Portalserver auch die .geo Dateien übermittelt werden, ist der Portalserver sogar in der Lage die lokal berechnete Graphik zu einer globalen Graphik über alle Datenserver zu vereinigen (ohne dass er im Besitz der Originaldaten sein muss).
Der Portalserver enthält immer nur eine Kopie der .idx bzw. .geo Dateien der Datenserver. Beim Löschen von Daten im Datenserver werden daher auch die entsprechenden Dateien im Portalserver automatisch gelöscht. Auch das Löschen kann über eine Kette von GeoShop Servern (z.B. lokaler GeoShop => Standard Datenserver => Portalserver => übergeordneter Portalserver) erfolgen und wird von uns daher als Cacading Delete bezeichnet. Werden umgekehrt Daten im Portalserver gelöscht werden trotzdem keine Daten im untergeordneten Datenserver gelöscht, weil die Datenhoheit immer beim lokalen Datenserver liegt.
Eine Datenbestellung läuft wie folgt ab:
Bei einer Bestellung werden die betroffenen Datenserver via die auf dem Portalserver vorhanden .idx Dateien ermittelt.
An die von der Bestellung betroffenen Datenserver werden Unterbestellungen aufgegeben. Welches Produkt erstellt werden soll, wird dem Datenserver über den auf allen Servern vorhandenen, einheitlichen Produktnamen mitgeteilt.
Die Datenserver berechnen das Produkt und liefern dieses per HTTP (gezippt) an den Portalserver.
Der Portalserver mischt die angelieferten Teilbestellungen zur Gesamtbestellung und benachrichtigt den Benutzer per E-Mail, dass die Daten zum Download bereit sind.
Bei verteilten Systemen ist auch ein wohl definiertes Fehlerverhalten der einzelnen Teilsysteme wichtig. Folgende Bemerkungen dazu:
Die Übermittlung der Dateien (.idx, .geo oder .itf) vom Datenserver an den Portalserver ist als eigener Jobtyp (PortalJob) implementiert. Falls z.B. der Portalserver beim Upload in den Datenserver nicht zur Verfügung steht, wird der PortalJob gestoppt und kann später wieder gestartet werden, wenn der Portalserver wieder zur Verfügung steht.
Datenbestellungen, bei welchen nicht alle betroffenen Datenserver zur Verfügung stehen, werden auf dem Portalserver gestoppt. Die Bestellung kann wieder gestartet werden, wenn die noch fehlenden Datenserver wieder zur Verfügung stehen. Mit diesem Feature können unvollständige Datenlieferungen vermieden werden.
Eine lokale Datei kann nur gelöscht werden, wenn der übergeordnete Server ebenfalls erreichbar ist (wegen Cascading Delete).