Technische Beschreibung: Modul Datei und Ordnerverwaltung

Transkript

1 EPOD Encrypted Private Online Disc Technische Beschreibung: Modul Datei und Ordnerverwaltung Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für Wirtschaftsinformatik Data & Knowledge Engineering Dr. Michael Karlinger Dokument Metadaten Workpackage A 5 Status Öffentlich Dokument Name D5.2 T Modul Datei und Ordnerverwaltung v1.5.docx Version 1.5 Autor Klaus Ettmayer, Michael Karlinger Letzte Änderung 23. Jänner 2012

2 Inhalt 1. Überblick und Einleitung Verwaltung von Knoten im Generic Client Artefakt Manager Log Manager Client API Verwaltung von Dateien und Ordnern im EPOD Explorer Client Config Attribut name Attribut creation date Attribut modification date Attribut size Attribut language Attribut extension Inhalt Core Config Log Config Undo Config Content Config Structure Config Attribute Config Server Config Struktur Container Attribut Container Inhalt Container Log Container Metadata Container D5.2 Version 1.5 Seite 2/15

3 1. Überblick und Einleitung Aufgrund der Aufgliederung des EPOD Systems in Domain Client und Generic Client, ist das ursprünglich monolithisch konzipierte Modul zur Verwaltung von Dateien und Ordnern wie folgt gegliedert: Verwaltung von Inhalts und Strukturknoten im Generic Client Verwaltung von Dateien und Ordnern im EPOD Explorer Im Kapitel 1 ist die technische Umsetzung der domänenunabhängigen Verwaltung von Inhalts und Strukturknoten im Generic Client beschrieben. Da die Verwaltung von Knoten nebenläufig realisiert wurde, wird in diesem Kapitel auch insbesondere auf das Log des Generic Clients eingegangen. Des Weiteren wird die, einem Domain Client vom Generic Client zur Verfügung gestellte Schnittstelle zur domänenabhängigen Verwaltung von Knoten beschrieben. Im Kapitel 2 wird die Verwendung des Moduls zur Verwaltung von Inhalts und Strukturknoten des Generic Clients im EPOD Explorer, einem Domain Client für die Verwaltung von Dateien und Ordnern, beschrieben. Es wird insbesondere auf die dafür notwendige Konfiguration des Generic Clients eingegangen. 2. Verwaltung von Knoten im Generic Client Die Konzeption der Komponenten zur Verwaltung von Inhalts und Strukturknoten durch den Generic Client sowie die Spezifikation der dafür notwendigen Algorithmen sind der Dokumentation der Arbeitspakete 1 und 2 insbesondere der Systemspezifikation zu entnehmen. In diesem Kapitel ist die technische Umsetzung dieser Komponenten beschrieben. Im Abschnitt 2.1 ist die technische Umsetzung der sogenannten Artefakt Manager zur Verwaltung der Struktur, Inhalte und Attribute von Knoten beschrieben. Im Abschnitt 2.2 ist die technische Umsetzung des Log Mechanismus im Generic Client näher beschrieben Artefakt Manager Die Artefakt Manager sind im package epod.core.management enthalten und durch die folgenden Klassen realisiert: StructureManager AttributeManager ContentManager MetadataManager Die Klassen AttributeManager und ContentManager stellen die Funktionalität für das Verwalten der Attribute und Inhalte von Knoten zur Verfügung. Um die eigentlichen Attributwerte bzw. den eigentlichen Inhalt zu speichern greifen sie auf die jeweils in der Server Config konfigurierten Container zurück. Das Lesen und Schreiben von Entries in Containern ist näher im Dokument D4.2 T Modul Kommunikation und Verschlüsselung beschrieben. D5.2 Version 1.5 Seite 3/15

4 Die Klasse StructureManager stellt die Funktionalität für das Verwalten der Knotenstruktur in einer Hierarchie (Primärhierarchie oder Sekundärhierarchie) zur Verfügung. Im Unterschied zum Attributbzw. Content Manager greift der Structure Manager nicht direkt auf den für die Speicherung der Struktur in der Server Config konfigurierten Container zu. Der Grund dafür ist, dass der Strukturbaum nicht direkt in Entries gespeichert wird, sondern davor in eine, im Dokument D1.1a D Interne Datenstrukturen und Algorithmen der Primärhierarchie genauer beschriebene, komprimierte Repräsentation umgewandelt wird. Diese Umwandlung und die Aufteilung der komprimierten Repräsentation auf Entries des Struktur Containers wird vom Structure Monitor im package epod.core.management übernommen. Der Structure Monitor überwacht entsprechend dem Observer Pattern die vom Structure Manager am Strukturbaum vorgenommenen Änderungen, erzeugt je nach Bedarf die komprimierte Repräsentation des Strukturbaums und veranlasst dessen Speicherung im Struktur Container. Der MetadataManager stellt letztlich die Funktionalität für das Lesen und Schreiben von Metadaten zur Verfügung. Solche Metadaten sind zum Beispiel die höchste bisher für einen Knoten vergebene ID oder auch die Information darüber ob der EPOD Client nach dem letzten Start ordnungsgemäß beendigt wurde Log Manager Die Verwaltung des Logs wird von der Klasse epod.core.management.logmanager übernommen. Diese Klasse ist zentral für den gesamten Log Mechanismus, da sie auch die Funktionalität für den Wiederanlauf sowie das Rückgängigmachen von Benutzeraktionen beinhaltet. Für jede Benutzeraktion wird ein Logeintrag erzeugt und dem LogManager bekanntgegeben. Logeinträge werden durch Objekte der Klasse epod.core.log.logentry repräsentiert. Detaillierte Informationen zum Aufbau von Logeinträgen befinden sich im Dokument D1.1 D Interne Datenstrukturen und Algorithmen für die nebenläufige Abarbeitung von Benutzeraktionen. Wird dem Log Manager ein neuer Logeintrag bekanntgegeben, so priorisiert der Log Manager die Durchführung der, entsprechend der zugrundeliegenden Benutzeraktion, an den einzelnen Artefakten (Struktur, Attribute, Inhalt und Indizes) durchzuführenden Änderungen. Die Regeln der Priorisierung lauten wie folgt: Stehen für einen Knoten noch Änderungen aufgrund eines früheren Logeintrags aus, so werden die Änderungen aufgrund des neuen Logeintrags mit geringerer Priorität versehen. Innerhalb der Änderungen aufgrund des neuen Logeintrags gilt: 1. Aktualisieren der Struktur 2. Aktualisieren der Attribute und des Inhalts 3. Aktualisieren der Indizes Nach der Priorisierung prüft der Log Manager pro Artefakt ob die Anzahl der, entsprechend der Priorisierung durchführbaren Aktionen den in der Core Config für das jeweilige Artefakt festgelegten Schwellwert erreicht hat. Ist dies der Fall, so werden die Änderungen nebenläufig durchgeführt. D5.2 Version 1.5 Seite 4/15

5 Die nebenläufige Durchführung von Änderungen wird von sogenannten Workern im package epod.core.log.worker vorgenommen. Pro Artefakt steht ein entsprechender Worker zur Verfügung der als Java Thread realisiert ist. Durch Aufruf der Methode run() beginnt der Worker mit der Abarbeitung der ihm zugeteilten Logeinträge. Nach dem ein Worker die Logeinträge fertig abgearbeitet hat benachrichtigt er den LogManager durch einen Aufruf der Methode notifyall() darüber und steht dem LogManager dadurch wieder zur Verfügung um weitere Logeinträge abzuarbeiten. Während der nebenläufigen Abarbeitung werden die Status der Änderungen in den entsprechenden Logeinträgen aktualisiert. Es wird allerdings nicht bei jeder Statusänderung der jeweilige Logeintrag sofort am EPOD Server aktualisiert. Stattdessen überwacht der Log Monitor, realisiert in der Klasse epod.core.log.logmonitor, entsprechend dem Observer Pattern die Statusänderungen und veranlasst das Persistieren der aktualisierten Logeinträge am EPOD Server, sofern deren Anzahl den in der Core Config eingestellten Schwellwert erreicht ist. Der Log Monitor läuft, um die Verfügbarkeit des LogManagers nicht einzuschränken in einem eigenständigen Thread Client API Die Client API stellt die Funktionalität des Generic Clients für die Verwaltung von Knoten in Hierarchien für Domain Clients zur Verfügung. Diese Schnittstelle ist im package epod.disc enthalten. Den zentralen Einstiegspunkt stellt die Klasse epod.disc.disc dar, welche im Wesentlichen die folgende Funktionalität bietet: Auf und Abbau einer Verbindung zu einer EPOD Disc Zugriff auf die Primärhierarchie Verwalten von Sekundärhierarchien Für die eigentliche Verwaltung von Knoten wird die Klasse epod.disc.primaryhierarchy bzw. epod.disc.secondaryhierarchy zur Verfügung gestellt. Diese Klassen bieten die Funktionlität zum Erzeugen, Löschen, Kopieren, Verschieben und Ändern von Knoten. Für die Repräsentation von Knoten stellt die Client API die Klassen Node, ContentNode und StructuralNode im Package epod.client.model zur Verfügung. 3. Verwaltung von Dateien und Ordnern im EPOD Explorer Der Domain Client EPOD Explorer wurde in der Klasse epod.explorer.explorer implementiert. Diese Klasse implementiert das Interface epod.client.domainclient und stellt die, vom Generic Client benötigte, domänenabhängige Funktionalität, wie zum Beispiel das zur Verfügung stellen domänenspezifischer Repräsentationen von Inhalts und Strukturknoten beim Import von Knoten, zur Verfügung. Dateien und Ordner werden durch Objekte der Klassen epod.explorer.model.file und epod.explorer.model.directory repräsentiert. Diese Klassen erben von den Klassen epod.client.model.contentnode bzw. epod.client.model.structuralnode und können deshalb direkt in der Client API zum Zwecke der Kommunikation zwischen EPOD Explorer und Generic Client verwendet werden. D5.2 Version 1.5 Seite 5/15

6 In den folgenden Abschnitten sind die für den EPOD Explorer verwendete Client Config, Core Config und Server Config beschrieben Client Config In der Client Config des EPOD Explorers werden, hinsichtlich der Verwaltung von Knoten, die Eigenschaften der Attribute von Inhalts und Strukturknoten sowie die Eigenschaften des Inhalts von Inhaltsknoten festgelegt. Die Eigenschaften der Attribute werden im Abschnitt attributeconfig der Client Config festgelegt. Die Eigenschaften des Inhalts von Inhaltsknoten werden im Abschnitt contentconfig der Client Config festgelegt. Diese beiden Abschnitte werden im Folgenden erläutert Attribut name Das Attribut name ist sowohl für Struktur als auch für Inhaltsknoten definiert und wird verschlüsselt gespeichert. Es ist als String mit einer maximalen Länge von 64 Zeichen konfiguriert. Die Namen von Dateien und Ordnern im EPOD Explorer dürfen deshalb maximal 64 Zeichen lang sein. <attribute> <name>name</name> <datatype>string</datatype> <minlength>1</minlength> <maxlength>64</maxlength> <encrypted>true</encrypted> </attribute> Attribut creation date Das Attribut creation date ist sowohl für Struktur als auch für Inhaltsknoten definiert. Es ist als Date fixer Länge konfiguriert. Das Erstellungsdatum wird im Klartext gespeichert, da es als nicht sensibel eingestuft wird. <attribute> <name>creationdate</name> <datatypeconfig xsi:type="fixlengthdatatypeconfig"> <datatype>date</datatype> <encrypted>false</encrypted> </attribute> D5.2 Version 1.5 Seite 6/15

7 3.1.3 Attribut modification date Das Attribut modification date ist sowohl für Struktur als auch für Inhaltsknoten definiert. Es ist als Date fixer Länge konfiguriert. Das Datum der letzten Änderung an einer Datei bzw. einem Ordner wird im Klartext gespeichert, da es als nicht sensibel eingestuft wird. <attribute> <name>lastmodified</name> <datatypeconfig xsi:type="fixlengthdatatypeconfig"> <datatype>date</datatype> <encrypted>true</encrypted> </attribute> Attribut size Das Attribut size ist nur für Inhaltsknoten definiert, da die Größe von Ordnern abhängig von der Größe der darin gespeicherten Dateien ist. Es ist als Integer fixer Länge konfiguriert und wird verschlüsselt gespeichert. <attribute> <name>size</name> <datatypeconfig xsi:type="fixlengthdatatypeconfig"> <datatype>integer</datatype> <encrypted>true</encrypted> <nodetype>content_node</nodetype> </attribute> Attribut language Das Attribut language ist nur für Inhaltsknoten definiert, da für Ordner keine Sprache sinnvoll festgelegt werden kann. Es ist als String mit einer maximalen Länge von 5 Zeichen konfiguriert und wird verschlüsselt gespeichert. <attribute> <name>language</name> <datatype>string</datatype> <minlength>0</minlength> <maxlength>5</maxlength> <encrypted>true</encrypted> <nodetype>content_node</nodetype> </attribute> D5.2 Version 1.5 Seite 7/15

8 3.1.6 Attribut extension Das Attribut extension ist nur für Inhaltsknoten definiert, da für Ordner offensichtlich keine Dateiendungen existieren. Es ist als String mit einer maximalen Länge von 8 Zeichen konfiguriert und wird verschlüsselt gespeichert. <attribute> <name>extension</name> <datatype>string</datatype> <minlength>0</minlength> <maxlength>8</maxlength> <encrypted>true</encrypted> <nodetype>content_node</nodetype> </attribute> Inhalt Der Inhalt von Dateien wurde als Binärdaten mit einer maximalen Länge von 400 Millionen Bit konfiguriert. Dateien im EPOD Explorer können daher eine maximale Größe von rund 50 MByte aufweisen. <contentconfig> <minlength>0</minlength> <maxlength> </maxlength> <encrypted>true</encrypted> </contentconfig> 3.2. Core Config In der Core Config des EPOD Explorers werden, hinsichtlich der Verwaltung von Knoten, die Eigenschaften der Primärhierarchie festgelegt. Insbesondere wird pro Artefakt der für die Speicherung vorgesehene Container bestimmt. Die konkrete Konfiguration der Primärhierarchie im EPOD Explorer ist in den folgenden Abschnitten dargestellt Log Config Das Log wird in einem Container mit dem Namen c_log gespeichert. Die Schwellwerte für die nebenläufige Abarbeitung von Logeinträgen sind wie folgt festgelegt: Änderungen an Indizes bzw. an Inhalten werden einzeln durchgeführt und am EPOD Server persistiert. Änderungen an der Struktur werden pro 20 Logeinträgen durchgeführt. Das heißt, erst wenn 20 Änderungen an der Struktur vorgenommen wurden, wird der Strukturbaum am jeweiligen EPOD Server wieder persistiert. Änderungen an Attributen werden pro 10 Logeinträgen durchgeführt. Das heißt, erst wenn sich die Attribute von 10 Knoten geändert haben werden diese Änderungen am jeweiligen EPOD Server persistiert. D5.2 Version 1.5 Seite 8/15

9 <logconfig> <logcontainer>c_log</logcontainer> <defermentthresholdconfig> <logupdatethreshold>5</logupdatethreshold> <indexupdatethreshold>1</indexupdatethreshold> <contentstoragethreshold>1</contentstoragethreshold> <structurestoragethreshold>20</structurestoragethreshold> <attributestoragethreshold>10</attributestoragethreshold> </defermentthresholdconfig> </logconfig> Undo Config Der EPOD Explorer ist so konfiguriert, dass die letzten drei Benutzeraktionen rückgängig gemacht werden können. <undoconfig> <undosize>3</undosize> </undoconfig> Content Config Der Inhalt von Dateien wird in einem Container mit dem Namen c_content gespeichert. Das Löschen von Inhalten ist verzögert, wodurch der Container für die Speicherung des Inhalts einen Papierkorb aufweisen muss. Die Inhalte von Dateien werden im EPOD Explorer nicht in den Cache aufgenommen, da diese zu groß für den Hauptspeicher sind. <contentconfig> <contentcontainer>c_content</contentcontainer> <deletiondefered>true</deletiondefered> <cachingenabled>false</cachingenabled> </contentconfig> Structure Config Der Strukturbaum wird in einem Container mit dem Namen c_ph_str gespeichert, wobei die IDs von jeweils 200 Knoten pro Entry im Struktur Container gespeichert werden. <structureconfig> <structurecontainer>c_ph_str</structurecontainer> <splitthreshold>200</splitthreshold> </structureconfig> Attribute Config Die Attribute von Dateien und Ordnern warden in einem Container mit dem Namen c_ph_attr gespeichert. <attributeconfig> <attributecontainer>c_ph_attr</attributecontainer> </attributeconfig> 3.3. Server Config In der Server Config des EPOD Explorers werden, hinsichtlich der Verwaltung von Knoten, die Eigenschaften der, für die Speicherung des Strukturbaums sowie der Attribute und Inhalte vorgesehenen Containern konfiguriert. Des Weiteren werden die Eigenschaften der, für die Speicherung des Logs D5.2 Version 1.5 Seite 9/15

10 bzw. der Metadaten vorgesehenen Container festgelegt. Diese Konfigurationen werden in den nachfolgenden Abschnitten gezeigt. Allgemein ist festzuhalten, dass bei der gezeigten Konfiguration von der Verschlüsselung mit dem DES Algorithmus unter Verwendung eines 128 Bit Schlüssels ausgegangen wird. Die Länge des verwendeten Verschlüsselungsschlüssels ist zusammen mit dem gewählten Verschlüsselungsalgorithmus ausschlaggebend dafür, wie viel Speicherplatz für die Speicherung eines Items in Abhängigkeit von der Größe des darin zu speichernden Klartext Werts vorgesehen werden soll. Das Verhältnis zwischen der Größe eines Werts im Klartext und der für die verschlüsselte Speicherung benötigten Größe lässt sich nur schwer allgemein festlegen. Für die vorliegende Konfiguration wurden die benötigten Größen durch austesten erruiert Struktur Container <container xmlns:xsi="normalcontainer"> <name>c_ph_str</name> <entryid> </entryid> <itemconfig> <name>str</name> <maxlength>2048</maxlength> </itemconfig> </container> Attribut Container <container xmlns:xsi="groupedcontainer"> <name>c_ph_attr</name> <groupid> </groupid> D5.2 Version 1.5 Seite 10/15

11 <entryid> </entryid> <itemconfig> <name>name</name> <name>creationdate</name> <datatypeconfig xsi:type="fixlengthdatatypeconfig"> <datatype>date</datatype> <name>lastmodified</name> <name>size</name> <minlength>0</minlength> <maxlength>64</maxlength> D5.2 Version 1.5 Seite 11/15

12 <name>language</name> <minlength>0</minlength> <maxlength>64</maxlength> <name>extension</name> <minlength>0</minlength> <maxlength>64</maxlength> </itemconfig> </container> Inhalt Container <container xmlns:xsi=" NormalContainer"> <name>c_content</name> <entryid> <datatypeconfig xsi:type=" VarLengthDatatypeConfig"> </entryid> <itemconfig> <name>content</name> <datatypeconfig xsi:type=" VarLengthDatatypeConfig"> <maxlength>65536</maxlength> </itemconfig> </container> D5.2 Version 1.5 Seite 12/15

13 3.3.4 Log Container <container xsi:type="groupedcontainer"> <name>c_log</name> <groupid> <datatypeconfig xsi:type="ns4:varlengthdatatypeconfig"> </groupid> <entryid> <datatypeconfig xsi:type=" VarLengthDatatypeConfig"> <maxlength>128</maxlength> </entryid> <itemconfig> <name>action</name> <maxlength>128</maxlength> <name>actionid</name> <maxlength>128</maxlength> <name>nodeid</name> <maxlength>128</maxlength> D5.2 Version 1.5 Seite 13/15

14 <name>input</name> <minarity>0</minarity> <maxarity>3</maxarity> <name>status</name> <minarity>3</minarity> <maxarity>3</maxarity> <minlength>40</minlength> <maxlength>40</maxlength> <name>idxstatus</name> <minarity>4</minarity> <maxarity>4</maxarity> <minlength>40</minlength> <maxlength>40</maxlength> </itemconfig> </container> Metadata Container <container xsi:type=" NormalContainer"> <name>metadata</name> <entryid> <datatypeconfig xsi:type="ns4:varlengthdatatypeconfig"> <maxlength>128</maxlength> </entryid> D5.2 Version 1.5 Seite 14/15

15 <itemconfig> <name>metadata</name> <datatypeconfig xsi:type="ns4:varlengthdatatypeconfig"> <maxlength>2048</maxlength> </itemconfig> </container> D5.2 Version 1.5 Seite 15/15