"Bekannte Dinge" (IWellKnownType)

In einer komplexen Umgebung wie dem cardo System drängt sich zwangsläufig die Frage auf, wie die Komponenten, Module, Anwendungen (letztendlich meinen diese Begriffe alle das Gleiche: spezifischen ausführbaren Programmcode für die Erfüllung einer bestimmten Aufgabe) mit den im System befindlichen Gegenständen (sprich: den Daten) sinnvoll agieren können, bzw. ihre Dienste anbieten können.

cardo als Integrationssystem ist hier mit einer schier unbegrenzten Menge verschiedener Daten konfrontiert.

Vorbetrachtung

Die Strukturen, Speicherorte, Formate sind nahezu beliebig. Also muss ein Mechanismus geschaffen werden, der diese Spezifika abstrahiert und den eingangs genannten Softwarekomponenten einen gemeinsamen Nenner bietet.

Dazu eine Vorabbetrachtung, der „Dinge“ die es in cardo gibt:

• Einen strukturierten Inhaltsbaum mit Beschreibungen, Berechtigungen, Metadaten
• Vom Betreuer in diesen Inhaltsbaum eingestellte (Geo)Datenquellen (welche die oben genannten Eigenschaften erben) beliebigen Inhaltes
• Ad-Hoc „produzierte“ Datenquellen, z.B. Uploads, als Ergebnis von Abfragen oder als Ergebnis der Aktion von Anwendungen
• Ad-Hoc „produzierte“ Datensätze, z.B. als Ergebnis einer Abfrage einer Ortsinformation (wie dem cardo Gazetteer-Dienst, GSS etc.)
• Datenquellen mit Bearbeitungsmöglichkeiten (mit oder ohne Geometrie, bzw. mit spezifischen oder allgemeinen Anforderungen an die Geometrie, wie Topologie)
• Fachanwendungen

Diese Liste erscheint auf den ersten Blick nicht sehr umfangreich, ist aber tatsächlich vollständig. Der Leser möge bedenken, dass hinter den Genannten, im Detail eine Vielzahl an Thematiken steckt (die Liste der Flurstücke des Landes X, die Ergebnisse einer Eigentümerrechte, die Luftbilder als WMTS Dienst, WMS Dienst oder als lokale ECW Datei, ein B-Plan auf GML Basis, Daten einer Vermessung als DXF Datei, eine Fachschale „Baumkataster“, Daten aus einer Excel-Tabelle, ein komplexer View mit Daten aus dem internen Oracle Datawarehouse ….).

Im Gegenzug bietet das System programmtechnische Unterstützungen, implementiert im Kern oder durch Erweiterungen, um mit diesen Dingen umzugehen. Z.B:.

• Jede Geodatenquelle kann in der Karte dargestellt werden.
• Jedes Thema aus dem Inhaltsbaum hat Metadaten, diese können dargestellt oder erfasst werden.
• Jede (Geo)datenquelle kann als Sachdatentabelle dargestellt werden.
• Einzelne Datensätze mit Geometrie können als Objekt in der Karte dargestellt werden.
• Anwendungen können gestartet werden.
• Alle tabellenähnlichen Daten können, in z.B. CSV oder XLS, exportiert werden.
• Anwendungen können zu bestimmten Datensätzen mehr Details liefern (der Klassiker: Eigentümerliste zu Flurstücken).
• Alle tabellenähnlichen Datenquellen können durch quellenübergreifende Abfragen analysiert werden, usw.

Diese grundlegenden Möglichkeiten sind schon recht umfangreich, können aber natürlich im Ergebnis den gleichen Mechanismus weiternutzen und damit weitere Mehrwerte produzieren.

Beispielhaft erklärt

Greifen wir aus der Liste der beispielhaft genannten Möglichkeiten das letztgenannte, themenübergreifende Abfragen, heraus.

Das Ergebnis einer Abfrage ist meist, etwas tabellenähnliches, d.h. dieses Ad-Hoc Produzierte kann wiederum durch das Modul „Tabellenansicht“ oder „Tabellenexport“ weiterverarbeitet werden. Ist eine Geometriespalte enthalten, dann ist das Ergebnis auch durch das Modul „Karte“ nutzbar. Enthält bspw. das Ergebnis eine Spalte mit dem Namen „ALKNR“, dann kann dazu die Anwendung „ALKIS“ die Liste der Eigentümer zum dem (vermeintlichem) Flurstück beschaffen.

Eine letzte Überlegung dazu fehlt noch. Personalisierung ist ein wichtiges Thema als Schlüssel zu einer produktiven und komfortablen Nutzung eines Systems. Soll der letzte Sitzungszustand wiederhergestellt, eine Liste der persönlichen Favoriten bereitgestellt oder anderen Kollegen die Ergebnisse von Arbeitsschritten zur Verfügung gestellt werden, dann muss die Programmumgebung Möglichkeiten bereitstellen, die benutzten Daten, sowie die dafür verwendeten Anwendungen persistent zu speichern.

Für die Abbildung genau dieses Zusammenspiels zwischen „Dingen“, der Umgebung und dem auswertendem „Programmteil“ haben wir das Konzept der „WellknownTypes“ in cardo integriert. Benannte Dinge erlauben damit: Die eindeutige Kennzeichnung einer Datenquelle oder Anwendung Eine Semantik, die das Beschriebene funktional benennt Möglichkeiten zur Wiederherstellung (Ad-Hoc generierter Datenquelle)

Das System verfügt über verschiedene Mechanismen, die bei jeder Verwendung einer Instanz eines WellknownTypes greifen. Dazu gehört die Durchführung der Nutzung pro Anwender, die Wiederherstellung von produzierten Daten bei der ersten Wiederverwendung, die Bereitstellung von Methoden zur Serialisierung und Deserialisierung und vor allem der Ausführungsschicht, die Anwendungen im Kontext der Nutzung zum Start anbietet und den entsprechenden Aufruf initiiert.

Zum besseren Verständnis des eben Genannten, soll das Verhalten am Ablauf der Suchfunktion in cardo4 erläutert werden:

• Der Nutzer aktiviert das Suchfeld in der cardo4 Umgebung.
• Das System listet sofort alle zuletzt genutzten WellknownType Instanzen, sortiert nach der Häufigkeit der Benutzung auf.
• Der Nutzer gibt ein Suchwort ein, der Suchprozess wird serverseitig angestoßen, das System ruft nun alle bekannten Suchprovider mit dem eingegebenen Begriff auf, jeder antwortet mit einer Liste von WellknownType Instanzen

Clientseitig wird die Ergebnisliste präsentiert (jeder WellknownType hat einen Titel und ein Icon), bei der Anzeige der Treffer ruft das System für jede der so gefundenen Instanzen jede in der aktuellen Umgebung registrierte Anwendung/Modul auf und fragt, ob es mit der Instanz umgehen kann, und wenn ja, welche Optionen zum Starten angeboten werden soll.

Das Ergebnis wird dem Nutzer in Form der entsprechenden Startoptionen zum Suchtreffer präsentiert.

Der Nutzer wählt eine Aktion am jeweiligen Treffer aus.

Das System erhöht die Nutzungsstatistik für den WellknownType und ruft die Anwendung, ggf. mit der ausgewählten Option, auf (z.B.: „Ebene Flurstücke“ => „Anzeige in Karte, Zoom auf diese Ebene) und übergibt die gewählte Instanz des WellknownType an die Anwendung.

Dieser Mechanismus des Startens einer Aktion zu einer WellknownType Instanz ist an sehr vielen Stellen im Kernsystem und auch den Kernkomponenten in genau dieser Form verfügbar und steht als API Methode für Dritte zur Verfügung.

Zusammengefasst bedeutet dies, ein WellknownType …

• ist ein Zeiger auf ein Datum,
• stellt durch die Art des Typs die Semantik dessen dar, worauf gezeigt wird,
• ist serialisierbar,
• kann Ad-Hoc produziert werden,

kurzum: ist das zentrale Bindeglied zwischen Programmfunktionen und den Daten.

Interne Notizen

IduIT.cardo.Core.CoreModules.Personalization.PersonalizationManager

• wird durch deleteFavorites gelöscht

• Expliziter Aufruf von markWellknownTypeAsUsed

• beim Start einer Anwendung wird der Typ als "verwendet" markiert.

• beim Löschen eines WellknownTyp wird dieser aus der Liste entfernt

• Wird nicht gemacht, wenn die uniqueId == null ist