Um eine wiederverwendbare Oberfläche einzubinden, wird eine Schnittstelle angelegt (siehe Bild \ref{figure:klassenRequest}). Die Schnittstelle wird aufgerufen, sobald der Nutzer einen Task absendet und bei der Auswahl einer Region. Das CSD Plugin des Geoviewers implementiert diese Schnittstelle. Region-Anfragen werden direkt bearbeitet und der Task Request wird an den CSD-Adapter gesendet. Im SBA wird das Interface von der CSDRequestAction implementiert. Der Regionsaufruf wird falls möglich an das CSDPlugin über ein DirectRequest weitergeleitet. Die Antwort darauf erhält der SBA erneut über einen DirectRequest. Eine DirectMessage ist im System des Backends nicht vorhanden und wird deshalb an dieser Stelle über zu Request gelöst. Wir können nicht nur einen Request verwenden, da der Nutzer beliebig lange zum Einzeichnen brauchen kann. Nutzt man einen einzigen DirectRequest so müsste die Antwort der Plugins innerhalb des Timeouts von 5 Sekunden erfolgen.
Um eine wiederverwendbare Oberfläche einzubinden, wird eine Schnittstelle angelegt (siehe Abbildung \ref{figure:klassenRequest}). Die Schnittstelle wird aufgerufen, sobald der Nutzer einen Task absendet und bei der Auswahl einer Region. Das CSD Plugin des Geoviewers implementiert diese Schnittstelle. Region-Anfragen werden direkt bearbeitet und der Task Request wird an den CSD-Adapter gesendet.
Im SBA wird das Interface von der CSDRequestAction implementiert. Der Regionsaufruf wird falls möglich an das CSDPlugin über ein DirectRequest weitergeleitet. Die Antwort darauf erhält der SBA erneut über einen DirectRequest. Eine DirectMessage ist im System des Middleware nicht vorhanden und wird deshalb an dieser Stelle über zu Request gelöst. Wir können nicht nur einen Request verwenden, da der Nutzer beliebig lange zum Einzeichnen brauchen kann. Nutzt man einen einzigen DirectRequest so müsste die Antwort der Plugins innerhalb des Timeouts von 5 Sekunden erfolgen.
\caption{Das Generieren von Tasks hat eine einheitliche Schnittstelle}
\caption{Das Generieren von Tasks hat eine einheitliche Schnittstelle. Diese wird im SBA und CSDPlugin implementiert und so kann der RequestDialog wiederverwendet werden}
\label{figure:klassenRequest}
\end{figure}
\subsection{Task ausführen}
Die Isaac.lib unterstützt 2 Arten von Anfragen an die CSD. Ein CSD-Request ist eine einmalige Abfrage des Servers, übergibt alle Treffer an einen mit übergebenen ResultHandler und ist dann beendet. Eine Subskription liefert auch nach dem Abfragezeitpunkt Ergebnisse. Wird zum Beispiel ein neuer Datensatz hinzugefügt, der auf die Abfrage passt, so wird dieser auch an den ResultHandler übergeben. Beide Abfragen unterscheiden sich bei der Erstellung nur in der eigentlichen Abfrage. Deshalb wurde die abstrakte Klasse CSDTask angelegt (siehe Abbildung \ref{figure:klassenTask}). Die Methode startRequest startet einen neuen Thread. Zuerst wird die abstrakte Methode beforeTask aufgerufen, um Vorbereitungen zu treffen, zum Beispiel Ergebnisse von einem alten Task zu löschen. TODO local Request??.
Die Ausfürhung der CSD-Abfrage erfolgt in 3 Schritten. Erst wird der CSD Querry String generiert. Anschließend folgt eine Abfrage über die Anzahl der erwarteten Ergebnisse. Die Methode isValidTaskSize überprüft nun, ob der Task ausgeführt werden soll oder ob das Ergebnis zu lange brauchen würde. Die Standard-Implementierung vergleicht die erwarteten Ergebnisse mit einem Wert aus der Konfigurationsdatei. Ist der Task nicht zu groß, wird die Methode queryCSD aufgerufen.
Die Methode wird von den beiden Klassen CSDRequst und CSDSubscription, die vom CSDTask erben, implementiert. % Hab ich den vorherigen Satz richtig korrigiert?
In dieser Methode wird die Verbindung zur CSD aufgebaut und durchsucht. Die Ergebnisse der Abfrage werden alle an den übergebenden Result Handler weitergeleitet.
Die Isaac.lib unterstützt 2 Arten von Anfragen an die CSD. Ein CSD-Request ist eine einmalige Abfrage des Servers, übergibt alle Treffer an einen mit übergebenen ResultHandler und ist dann beendet. Eine Subskription liefert auch nach dem Abfragezeitpunkt Ergebnisse. Wird zum Beispiel ein neuer Datensatz hinzugefügt, der auf die Abfrage passt, so wird dieser auch an den ResultHandler übergeben. Beide Abfragen unterscheiden sich bei der Erstellung nur in der eigentlichen Abfrage. Deshalb wurde die abstrakte Klasse CSDTask angelegt (siehe Abbildung \ref{figure:klassenTask}). Die Methode startRequest startet die Abfrage in einen neuen Thread. Zuerst wird die abstrakte Methode beforeTask aufgerufen, um Vorbereitungen zu treffen, zum Beispiel Ergebnisse von einem alten Task zu löschen.
Die Ausführung der CSD-Abfrage erfolgt in 3 Schritten. Erst wird der CSD Querry String generiert. Anschließend folgt eine Abfrage über die Anzahl der erwarteten Ergebnisse. Die Methode isValidTaskSize überprüft nun, ob der Task ausgeführt werden soll oder ob das Ergebnis zu lange brauchen würde. Die Standard-Implementierung vergleicht die erwarteten Ergebnisse mit einem Wert aus der Konfigurationsdatei. Ist der Task nicht zu groß, wird die abstrakte Methode queryCSD aufgerufen.
Die Methode wird von den beiden Klassen CSDRequst und CSDSubscription, die vom CSDTask erben, implementiert. In dieser Methode wird die Verbindung zur CSD aufgebaut und durchsucht. Die Ergebnisse der Abfrage werden alle an den übergebenden Result Handler weitergeleitet.
Um in Präsentationen Fehler zu vermeiden wurde die Möglichkeit eines lokalen Request aus dem CSD Adapter übernommen. Dieser Lokale Request lässt sich im Konfigurationsfile aktivieren und führt dazu das die Ergebnisse aus einer Datei geladen und direkt an den ResultHandler übergeben werden.
\caption{Vererbungs-Hirachie des CSDTasks. Die ASuführung des Task wird in der Superklasse gestartet und dei eigentliche Funktionalität ist in den eigentlichen Klassen implementiert }
\label{figure:klassenTask}
\end{figure}
\subsection{ResultHandling}
Die Ergebnisse aus einer CSD-Abfrage werden als Liste aus XML-Dokumenten an die Methode newResults(List<Documents>) übergeben. Diese ist ein Teil des Interfaces isaac.lib.ResultHandler. Für den SBA und den CSDAdapter müssen zunächst einige allgemeine Informationen aus dem XML Dokument ausgelesen werden. Deshalb wurde die abstrakte Klasse ResultHandler in der CSDCommon Bibliothek angelegt (siehe Abbildung \ref{figure:klassenResult}. Für jedes neue Ergebnis werden zunächst alle allgemeinen Felder ausgelesen und anschließend die Methode newResult aufgerufen, um das Ergebnis genau zu verarbeiten. Außerdem wird jeder Fehler abgefangen, der bei der Auswertung passieren könnte. Bricht die Verarbeitung eines Ergebnisses ab, so wird die Methode storeErrorProduct aufgerufen. In der Standard-Implementierung wird das XML-Dokument in einem Ordner abgelegt.
Die Ergebnisse aus einer CSD-Abfrage werden als Liste aus XML-Dokumenten an die Methode newResults(List<Documents>) übergeben. Diese ist ein Teil des Interfaces isaac.lib ResultHandler. Für den SBA und den CSDAdapter müssen zunächst einige allgemeine Informationen aus dem XML Dokument ausgelesen werden. Deshalb wurde die abstrakte Klasse ResultHandler in der CSDCommon Bibliothek angelegt (siehe Abbildung \ref{figure:klassenResult}. Für jedes neue Ergebnis werden zunächst alle allgemeinen Felder ausgelesen und anschließend die Methode newResult aufgerufen, um das Ergebnis genau zu verarbeiten. Außerdem wird jeder Fehler abgefangen, der bei der Auswertung passieren könnte. Bricht die Verarbeitung eines Ergebnisses ab, so wird die Methode storeErrorProduct aufgerufen. In der Standard-Implementierung wird das XML-Dokument in einem Ordner abgelegt.
Ist ein Ergebnis verarbeitet, wird im zugehörigen Task die Methode resultFinished aufgerufen. So kann der Task, nachdem alle Ergebnis ausgewertet sind, die Methode afterTask aufrufen, um einen eventuelle Nachbearbeitung durchzuführen.
\begin{figure}
...
...
@@ -39,18 +44,29 @@ Ist ein Ergebnis verarbeitet, wird im zugehörigen Task die Methode resultFinish
\subsection{CSDAdapter}
Im CSD-Adapter wird ein CSDRequest genutzt. Die Methoden beforeTask wird verwendet, um alte Daten zu löschen. Außerdem wird wie auch in beforeTask und resultFinished eine Nachricht an den Goeviewer gesendet, um ein visuelles Feedback an den Nutzer zu geben, wie weit die Bearbeitung des Tasks vorangeschritten ist.
Zur Kommunikation implementiert der CSDAdapter einen ConnectionServer und der Geoviwer einen ConnectionManager aus den MiddlewareTools. Das heißt, die Kommunikation über neue Tasks und den Fortschritt läuft nicht über das Backend, sondern direkt zwischen den Programmen. Im Gegensatz dazu werden alle erstellten Datenobjekte zusätzlich an das Backend gesendet, sodass diese im System sind und alle angeschlossenen Programme die Daten darstellen könnten.
Die Verarbeitung der Ergebnisse im ResultHandler wird zunächst aufgeteilt. Der MainResultHandler erhält alle Ergebnisse und gibt diese je nach Typ des Ergebnisses an einen genaueren ResultHandler weiter. % In welchem Sinne ``genauer''?
Sowohl der MainResultHandler als auch die spezifischen Handler erben von der allgemeinen Implementierung in der CSDCommons Bibliothek. In MainResultHandler wird die Methode newResults überschrieben, um die Ergebnisse weiterzureichen.
\subsection{SBA}
Im SBA ist die Auswahl-Oberfläche zunächst nur auf Bilder eingeschränkt. Andere Datentypen können nicht verarbeitet werden und sind deshalb auch nicht abfragbar.
Zur Kommunikation implementiert der CSDAdapter einen ConnectionServer und der Geoviwer einen ConnectionManager aus den MiddlewareTools. Das heißt, die Kommunikation über neue Tasks und den Fortschritt läuft nicht über das Backend, sondern direkt zwischen den Programmen. Die erstellten Datenobjekte werden über die an das Backend gesendet, sodass diese im System sind und alle angeschlossenen Programme die Daten darstellen könnten.
Die Verarbeitung der Ergebnisse im ResultHandler wird zunächst aufgeteilt. Der MainResultHandler erhält alle Ergebnisse und gibt diese je nach Typ des Ergebnisses an einen ResultHandler für die typ spezifischen Daten weiter.
Sowohl der MainResultHandler als auch die spezifischen Handler erben von der allgemeinen Implementierung in der CSDCommons Bibliothek. Im MainResultHandler wird die Methode newResults überschrieben, um die Ergebnisse weiterzureichen.
\subsection{SBA}
Im SBA ist die Auswahl-Oberfläche auf Bilder eingeschränkt. Andere Datentypen können nicht verarbeitet werden und sind deshalb auch nicht abfragbar.
Bei der Verarbeitung der Bilder werden alle wichtigen Informationen in einem CSDData Objekt gespeichert. Falls ein Vorschau Bild vorhanden ist wird dieses heruntergeladen. Auch Vorschaubilder liegen in der CSD als NSIF Bild vor und werden deshalb in PNG Bild umgewandelt. Alle Ergebnisse werden dem CSDDataStore hinzugefügt und der Nutzer kann sich in der ResultUI ein Bild aussuchen.
Sobald der Nutzer ein Bild aus der Datenbank Öffnen möchte, wird dieses herunter geladen und vom NSIF Format in den SBA importiert.
\section{Daten auswerten}
Weglassen?
\section{Asugewertete Daten speichern}
Das Exportiern von Daten war im SBA im allgemeinen vorhanden. Die ExportAction fragt den Nutzer nach einem Speicherort und rendert das Bild.
\subsection{Export in \rec}
Um den Export in den \rec zu gestalten wurde das Rendern der ExportAction umgebaut das es wiederverwendbar ist. Die ExportAction in \rec überschreibt die Standard Export Action. Die Auswahl des Nutzers wurde ersetzt durch einen Ordnerpfad der aus der Konfigurationsdatei gelesen werden kann.
\subsection{Export in CSD}
Der Export in die CSD erbt auch von der ExportAction. Zunächst muss der Nutzer alle nötigen Informationen zum Speichern in die CSD eingeben. Die Informationen werden auf Richtigkeit und Notwendigkeit überprüft. Wurde das Editierte Bild aus der CSD geladen so wird die Oberfläche mit den Informationen aus dem geladenen XML File ausgefüllt. Ist das Bild nicht aus der CSD werden falls möglich Standard Werte gesetzt. Diese Werte sind in der Konfigurationsdatei editierbar.
Nachdem der Nutzer die Informationen editiert hat wird das temporäre Bild mit dem Nsif Creator zur einem NSIF Bild konvertiert. Die nötigen Metadaten zuer erstellung des Bildes werden aus der Nutzeroberfläche geladen und in ein XML Dokument geschrieben. Sind im SBA Geoinformationen vorhanden werden diese ebenfalls angefügt.
Mit den restlichen Informationen wird das XMLDokument für die CSD erstellt und zusammen mit dem NSIF Bild an die Isaac.lib übergeben. Ist das Bidl aus der CSD geladen, wird darauf geachtet das alle Informationen aus dem alten XML Dokument übernommen werden, da die Eingabe nicht alle Felder die in dem XML Dukument vorhanden sein können umfasst. Bei der Erstellung des neuen Dokuments wird in diesem Fall das alte kopiert, alle Felder die vom Server generiert werden gelöscht und alle Änderungen aus der Nutzereingabe eingetragen. Sind keine Informationen vom vorherigen Bild vorhanden, wird ein neuse XML Dokument generiert.
Der CSDWritingClient übernimmt das übertragen des Meta Dokuments. Das NSIF Bild stellt die Bibliothek in einem HttpServer zur Verfügung. Der CSD Server lädt sich diese Datei herunter.
In der Implementierung sind beim bereitstellen des Bildes einige Probleme aufgetreten. Zum einen ist darauf zu achten das die Infrastruktur erlaubt das der Server eine Rückverbindung zum Client aufbaut. Ist diese Funktionalität durch eine Firewall blockiert kann das Bild nicht übertragen werden. Außerdem überträgt die Isaac.lib nicht die IP des Clients als download URL sondern den DNS Namen. Dies kann ebenfalls dazu führen das der Server das Bild nicht herunterladen kann.
