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.
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.
Im SBA wird das Interface der CSDRequestAction implementiert.
Der Aufruf der Region wird falls möglich über einen DirectRequest an das CSDPlugin weitergeleitet.
Die Antwort darauf erhält der SBA erneut über einen DirectRequest. % Warum ``erneut''?
Eine DirectMessage ist im System der Middleware nicht vorhanden. Deshalb werden an dieser Stelle ersatzweise Requests verwendet.
Wir können nicht nur einen einzigen Request absetzen, da nicht bekannt ist, wie lange der Nutzer zum Einzeichnen benötigt.
Nutzt man lediglich einen DirectRequest, so müsste die Antwort der Plugins innerhalb des Timeouts von 5 Sekunden erfolgen.
\begin{figure}
\begin{figure}
\centering
\centering
...
@@ -16,22 +23,46 @@ Im SBA wird das Interface von der CSDRequestAction implementiert. Der Regionsauf
...
@@ -16,22 +23,46 @@ Im SBA wird das Interface von der CSDRequestAction implementiert. Der Regionsauf
\end{figure}
\end{figure}
\subsection{Task ausführen}
\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 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 Isaac.lib unterstützt 2 Arten von Anfragen an die CSD.
Ein CSD-Request ist eine einmalige Abfrage des Servers, die alle Treffer an einen im Request definierten ResultHandler übergibt und sich dann beendet.
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.
Eine Subskription liefert auch nach dem Abfragezeitpunkt Ergebnisse.
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.
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 durch die eigentlichen Abfrage. % Was bedeutet das? ``Die ABFRAGEN unterscheiden sich NUR durch die ABFRAGE'' Bitte den geringen Unterschied klarer darstellen.
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.
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 ``klein genug'', wird die abstrakte Methode queryCSD aufgerufen.
Die Methode wird implementiert von den beiden Klassen CSDRequst und CSDSubscription, die vom CSDTask erben.
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. % Du meinst wahrscheinlich Präsentationen = Demonstrationen beim Kunden, wo keine Verbindung zum Backend besteht. Ich habe zuerst an die Präsentationsschicht im GUI gedacht. Sollten wir vielleicht klarer schreiben.
Dieser lokale Request lässt sich im Konfigurationsfile aktivieren und führt dazu, dass 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 }
\caption{Vererbungs-Hirachie des CSDTasks.
Die Ausführung des Task wird in der Superklasse gestartet.
Die Funktionalität ist in den eigentlichen Klassen implementiert. % Ist die Formuilierung ``die eigentlichen Klassen'' gut? Wie wäre: in den ``spezialisierten Klassen''? }
\label{figure:klassenTask}
\label{figure:klassenTask}
\end{figure}
\end{figure}
\subsection{ResultHandling}
\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 CSD-Adapter 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. %Was meinst du mit ``genau verarbeiten''?
Außerdem wird jeder Fehler abgefangen, der bei der Auswertung passieren könnte. % ``jeder Fehler wird abgefangen''. Bist du sicher das du ALLE Fehler abfängst? Wenn nicht würde ich schreiben ``Außerdem werden Fehler abgefangen''
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.
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.
...
@@ -42,31 +73,58 @@ Ist ein Ergebnis verarbeitet, wird im zugehörigen Task die Methode resultFinish
...
@@ -42,31 +73,58 @@ Ist ein Ergebnis verarbeitet, wird im zugehörigen Task die Methode resultFinish
\label{figure:klassenResult}
\label{figure:klassenResult}
\end{figure}
\end{figure}
\subsection{CSDAdapter}
\subsection{CSD-Adapter}
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.
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. Die erstellten Datenobjekte werden über die an das Backend gesendet, sodass diese im System sind und alle angeschlossenen Programme die Daten darstellen könnten.
Zur Kommunikation implementiert der CSD-Adapter 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 % hier fehlt ein wichtiges Wort
an das Backend gesendet, sodass diese im System sind und alle angeschlossenen Programme die Daten darstellen können.
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.
Die Verarbeitung der Ergebnisse im ResultHandler wird zunächst aufgeteilt.
Der MainResultHandler erhält alle Ergebnisse und gibt diese an einen auf den jeweiligen Datentyp spezialisierten ResultHandler 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.
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}
\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.
Im SBA ist die Auswahl-Oberfläche auf Bilder eingeschränkt.
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.
Andere Datentypen können nicht verarbeitet werden und sind deshalb auch nicht abfragbar.
Sobald der Nutzer ein Bild aus der Datenbank Öffnen möchte, wird dieses herunter geladen und vom NSIF Format in den SBA importiert.
Bei der Verarbeitung der Bilder werden alle wichtigen Informationen in einem CSDData-Objekt gespeichert.
Falls ein Vorschaubild vorhanden ist, wird dieses heruntergeladen.
\section{Asugewertete Daten speichern}
Auch Vorschaubilder liegen in der CSD als NSIF-Bilder vor und werden deshalb in PNG-Bilder umgewandelt.
Das Exportiern von Daten war im SBA im allgemeinen vorhanden. Die ExportAction fragt den Nutzer nach einem Speicherort und rendert das Bild.
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 heruntergeladen und aus dem NSIF-Format in den SBA importiert.
\section{Ausgewertete Daten speichern}
Das Exportieren von Daten war im SBA im Allgemeinen vorhanden. %Im Allgemeinen - im Speziellen nicht? Ich verstehe nicht warum du die Formulierung ``im Allgemeinen'' verwendest.
Die ExportAction fragt den Nutzer nach einem Speicherort und rendert das Bild.
\subsection{Export in \rec}
\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.
Um den Export in den \rec zu gestalten, wurde das Rendern der ExportAction umgebaut, so dass 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}
\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.
Der Export in die CSD erbt auch von der ExportAction.
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.
Zunächst muss der Nutzer alle nötigen Informationen zum Speichern in die CSD eingeben.
Die Informationen werden auf Richtigkeit und Notwendigkeit überprüft.
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.
Wurde das editierte Bild aus der CSD geladen, so wird die Oberfläche mit den Informationen aus dem geladenen XML-File ausgefüllt.
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.
Ist das Bild nicht aus der CSD, werden falls möglich Standardwerte gesetzt.
Diese Werte sind in der Konfigurationsdatei editierbar.
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.
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 zur 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 XML-Dokument für die CSD erstellt und zusammen mit dem NSIF Bild an die Isaac.lib übergeben. % Welche Informationen können zu den ``restlichen'' gehören?
Ist das Bild aus der CSD geladen, wird darauf geachtet, dass alle Informationen aus dem alten XML-Dokument übernommen werden, da die Eingabe nicht alle Felder umfasst, die in dem XML-Dokument vorhanden sein können.
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 neues XML-Dokument generiert.
Der CSDWritingClient übernimmt das Übertragen des Meta-Dokuments.
Das NSIF-Bild stellt die Bibliothek in einem HttpServer zur Verfügung. % Dieser Satz scheint logisch verdreht.
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, dass die Infrastruktur erlaubt, dass 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-Adresse des Clients als Download-URL, sondern den DNS-Namen. Dies kann ebenfalls dazu führen, dass der Server das Bild nicht herunterladen kann.
