Allgemeines zur Implementierung

MyCoRe ist entgegen anderen Projekten kein monolitisches Objekt. Vielmehr wurde ein mehrstufiger Ansatz gewählt, um die Vielfalt der Einsatzgebiete sinnvoll abzudecken. Dabei wird strikt zwischen allgemeingültigen Kernbestandteilen und Funktionalitäten und der schlussendlichen Anwendung, welche ggf. mehrstufig sein kann, unterschieden. Innerhalb dieser Bereiche gibt es wieder Teile, welche unabdingbar erforderlich sind und solche, die im Bedarfsfall in die Endanwendung integriert werden können. Ziel der Struktur ist es, in der Anwendung nur noch das Archiv mycore.jar sowie die erforderlichen weiteren externen *.jar Dateien in die Anwendung integrieren zu müssen. Damit ist die Schnittstelle zwischen dem MyCoRe-Kern und den Anwendungen klar definiert. Details des Aufbaus und der Struktur des MyCoRe-Kerns und der Anwendung werden im nächsten Abschnitt detailliert behandelt. Sowohl die benötigte mycore.jar Datei in ihrer entsprechenden Version wie auch die erforderlichen weiteren *.jar-Bibliotheken anderer Hersteller in den passenden Versionen werden über Maven-Repositories durch die Anwendung angefordert und integriert.

Das MyCoRe-Projekt bemüht sich, bereits etablierte Techniken und Implementationen zu benutzen, um einerseits den eigenen Entwicklungsaufwand so gering wie möglich zu halten, andererseits dem Nachnutzer den Einstieg durch die Verwendung bekannter Komponenten zu erleichtern.

Der Folgende Abschnitt beschreibt alle eingesetzten Bibliotheken. Dabei ist die Lizenzpolitik der Hersteller sehr unterschiedlich. Gemeinsam ist allen jedoch, dass sie den Open Source Gedanken vertreten und für nichtkommerzielle Einsätze frei verfügbar sind. Die Nutzung von MyCoRe unter wirtschaftlichen Aspekten bedarf also einer gesonderten Betrachtung der Lizenzrechte durch den Anwender. Ob hier Rechte verletzt werden, ist im Einzelfall abzuklären.

Tabelle: Übersicht der benutzten externen Bibliotheken

Lizenzen:

• AL 2.0 - Apache License Version 2.0, January 2004
  http://www.apache.org/licenses/
• ASM - Copyright (c) 2000-2005 INRIA, France Telecom
  http://asm.objectweb.org/license.html
• BSD - Copyright (c) 2002,2003,2004,2005,2006 Atsuhiko Yamanaka, Jcraft,Inc.
• CPL – Common Public License Version 1.0
  http://www.oopensource/licenses/cpl.php
• HS - Copyright (c) 1995-2000 by the Hypersonic SQL Group.
  http://www.hsqldb.org/web/hsqlLicense.html
• IBM – Special license for Open Soucre of IBM like LGPL
• JDOM - Copyright (C) 2000-2002 Brett McLaughlin & Jason Hunter.
  http://www.jdom.org
• LGPL - GNU Library or Lesser General Public License 2.1
• SUN – Sun.com Terms of Use -
  http://www.sun.com/termsofuse.html
• W3C - W3C® SOFTWARE NOTICE AND LICENSE Copyright © 1994-2001 World
  http://www.w3.org/Consortium/Legal/copyright-software-19980720

Definitionen

• Common parts sind die Teile des MyCoRe-Kerns, welche von vielen/allen Komponenten und Modulen verwendet werden und die elementaren Grundfunktionalitäten von MyCoRe bereitstellen. U. a. beinhaltet dies die APIs zur Speicherung der Daten, Klassifikationen, der ACLs und Nutzer, Store-Zugriffe und Klassen, die allgemeiner Natur sind und als API-Funktionalitäten bereitgestellt werden (MCRServlet, XML-Parser usw.).
• Components sind Teile des MyCoRe-Kerns welche als Funktionalität in sich abgrenzbar sind. Sie bauen auf den Common parts auf und enthalten alle zur Funktionalität gehörenden Klassen und Dateien. Alle Komponenten haben eine fest vorgegebene Struktur (siehe unten) und können über ein Property ausgeschaltet werden (wie bisher bei den Modulen des Kerns). Die in den Komponenten enthaltenen Vorlagen (Templates) können durch anwendungsseitige Dateien überschrieben werden. Komponenten werden vom Entwickler-Team bereitgestellt und sind Bestandteil von mycore.jar. Komponenten werden über einen automatischen Prozess in die Anwendung integriert, wenn sie nicht explizit deaktiviert wurden.
• Modules sind austauschbare/abschaltbare Teile der Nutzeranwendung, welche alle wichtigen Dinge zur Gestaltung konkreter Anwendungen enthalten, die nicht als generisch anzusehen sind (Datenmodelle, statische Seiten, Layouts usw.). Module werden von den Anwendern entwickelt und bauen auf dem mycore.jar auf. Module können auch Komponenten überschreiben bzw. ergänzen. Die Dateibaumstruktur vom Modulen und Komponenten soll analog zueinander sein.

Aufbau der Datei mycore.jar

Die Datei mycore.jar ist die Schnittstelle des MyCoRe-Kerns zu den Anwendungen. Eine Anwendung integriert NUR diese Datei! Externe JAR-Files werden direkt über Maven von der Anwendung nachgeladen. Alle Komponenten werden per default integriert, auszuschaltende Komponenten müssen in der Anwendung spezifiziert werden. Welche Teile dabei von einer Komponente bei Nennung in der Konfiguration kopiert werden, zeigt die Tabelle.

Tabelle: Verwendung der Komponententeile

Der Aufbau der JAR-Datei für die JAVA-Klassen ist von uns nicht änderbar, sondern ergibt sich aus der Package-Struktur. Für Hibernate Mappings ist es gängiger Standard, dass diese genauso heißen wie die Klassen - mit der Endung .hbm.xml und in dem gleichen Package liegen, also zusammen mit den *.class-Dateien. Eine Komponente in MyCoRe enthält Klassen, Webseiten, I18N-Dateien, Properties, Hibernate-Mappings, Stylesheets, XSD- und DTD-Dateien.

    
  
     
     mycore.jar 
       \ META-INF 
       \ \ Manifest.mf (mit Datums- und Revisionangabe) 
       \ org.mycore (alle Klassen) 
       \ xsl (alle Stylesheets) 
       \ components 
       | \ [component] 
       |   \ config (Konfigurationen / Templates) 
       |   | \ mycore.properties 
       |   | \ messages_de.properties 
       |   | \ messages_en.properties 
       |   \ web 
       |   | \ css 
       |   | \ images 
       |   | \ js 
       |   \ integrate.xml 
       \ *.dtd | *.xsd (alle DTD- und XSD-Schema-Dateien) 
       \ license.txt 
       \ integrate.xml 
  
    
    

Festlegungen

• Die Dateien messages_xx.properties und mycore.properties werden erst durch die Anwendung abhängig von den verwendeten Komponenten zusammengefügt.
• Bei Updates von einer Version zur nächsten ist es notwendig alte Libs (inkl der alten MyCoRe-Version) zu entfernen, dafuer ist ein eigenes ant-target ant resolve vorhanden.

Die Struktur des mycore-Verzeichnisses

Die Struktur des mycore-Verzeichnisses ergibt sich aus der Struktur der MyCoRe-JAR-Datei und der eines Maven-Projektes.

    
  
     
    #####################################################
    # The component mycore.property file
    #####################################################
    
    MCR.[component-name].propertyName = ...
    
    
    

Festlegungen für den Aufbau der Anwendung

• Alle Anwendungsmodule sollten sich in ihrer Struktur an den Vorgaben für Komponenten orientieren.
• Der Mechanismus zur Integration der Komponenten in die Anwendung wird über ANT Tasks und entsprechende Targets realisiert.
• Die unten stehende Tabelle beschreibt die Integrationspunkte an Hand der öffentliche Targets, die eine Anwendung haben muss.
• Komponenten muessen explizit ausgeschalten werden via MCR.Components.Exclude.
• Die ImageViewer-Komponente ist ebenfalls per default aktiviert und prüft selbst, ob die entsprechenden Klassen verfügbar sind oder nicht.
• Alle I18N Properties haben eine feste Namenskonvention (siehe oben). Zur Anpassung an ältere Codestände gibt es einen deprecated.properties Mechanismus, so dass die Umbenennung ohne zwingenden Migrationsaufwand machbar ist.
• Alle I18N-Properties eines Modules haben den Namen modul.[modul-name].xxx
• Alle Properties eines Modules haben den Namen MCR.[modul-name].xxx .

Tabelle: Application integration targets

Tabelle: Application internal targets

Antwendungs-Module als JAR-Datei

Anwendungsmodule können seit DocPortal 2.1 nicht nur im "modules"-Verzeichnis existieren, sondern auch als JAR-Datei eingebunden werden. Das geschieht über das "maven"-Modul, dass dafür in der mycore.private.properties Datei unter MCR.Modules.Application eingetragen werden muss.

Die Anwendungs-Module sind im Aufbau ähnlich den MyCoRe-Komponenten, d.h. sie enthalten alle Dateien die zur Build-Zeit und zur Laufzeit benötigt werden. Erkannt werden die JAR-Dateien an ihrem Manifest und Eigenschaft MCR-Application-Module, die den Namen des Moduls enthält. Über ant resolve werden alle Module unter build/modules entpackt. Dort werden aber nur die Verzeichnisse classifications, config und web entpackt.

    
  
     
     application-module.jar 
       \ META-INF 
       \ \ Manifest.mf (mit Datums- und Revisionangabe) 
       \ (alle Klassen) 
       \ xsl (alle Stylesheets)
       \ classifications (evtl. Klassifikationen) 
       \ config 
       | \ [module] 
       |   \ mycore.properties 
       |   \ messages_de.properties 
       |   \ messages_en.properties
       |   \ build.xml
       |   \ build.properties
       \ web 
       \ *.dtd | *.xsd (alle DTD- und XSD-Schema-Dateien) 
  
    
    

Die build.xml wird nur benötigt, wenn die targets create.users, create.default-rules erweitert werden sollen oder wenn create.webapp zusätzlich zum einfachen Kopieren der Daten aus dem web-Verzeichnis noch Aktionen ausführen soll.

In build.properties können Properties definiert werden, die beim Einbinden von Kommandos und XSL-Dateien helfen:

Ein großer Unterschied zu Modulen im moduldes-Verzeichnis ist, dass bei der JAR-Datei kein Build-Prozess mehr laufen muss, sondern nur noch ein Integrationsprozess, weswegen Java-Class- und Schema-Dateien schon fertig erzeugt in der JAR-Datei liegen.

Beispiele für Anwendungsmodule, die mittels Maven erstellt werden, finden sie hier:

• ImageViewer 2 Vorschau
• Archiv-Anwendung der Thüringer Universitäts- und Landesbibliothek

Das MyCoRe-Datenmodell kennt im seiner Grundkonzeption drei Komponenten. Zum einen gibt es Metadaten. Sie enthalten nur beschreibende Daten sowie ggf. strukturelle und organisatorische Informationen zu einem Datenobjekt. Dabei ist es nicht relevant, ob die Metadaten alleine stehen oder mit einem Anhang eines digitalen Objektes versehen werden sollen. Beispielsweise können Personendaten alleine existieren und die sie referenzierenden Dokumente besitzen noch zugeordnete digitale Objekte (Bilder, Dokumente, Videos usw.). Diese digitalen Objekte werden in MyCoRe als Derivate bezeichnet, da ein Objekt ggf. in mehreren Darstellungsvarianten an den selben Metadatensatz angebunden werden kann. Ein Derivat seinerseits besteht aus einem XML-Datensatz, welcher für den Im- und Export sowie die Präsentation der digitalen Objekte benötigt wird sowie den eigentlichen Daten in Form von Einzeldateien oder Dateibäumen. Im XML der Derivate wird zukünftig auch optional das METS-Format als Tag mit abgelegt. So wird eine direkte Nutzung von Bildbetrachtern wie dem DFG-Viewer einfach integrierbar sein. Die dritte Art von Daten stellen Klassifikationen (in Bibliothekskreisen auch als Normdateien bezeichnet) dar. Sie definieren Sammlungen feststehender Begriffe auf die seitens der anderen Metadaten referenziert werden kann.

Die Verknüpfung der Metadaten untereinander und zu den Klassifikationen erfolgt mittels einer einheitlichen ID. Für Klassifikationen kommt hierzu noch die Kategorie-ID. Der Syntax einer MyCoReID - im Programmiergebrauch die Klasse MCRObjectID - hat folgenden Syntax:

Das Datenmodell ist durch seine Gestaltung in XML-Strukturen so angelegt, dass es leicht möglich ist, Informationen in mehreren Sprachen gemeinsam abzulegen. Hierfür wird konsequent eine Kodierung mit UTF-8 angewendet. Bei zunehmender Globalisierung ist die Mehrsprachigkeit für viele Projekte zwingend erforderlich. Auch die Klassifikationen können mehrsprachig gespeichert werden.

In MyCoRe ist innerhalb des Datenmodells für die Metadaten die Möglichkeit einer Vererbung vorgesehen. Diese ist fest in den Kern implementiert und wird ausschließlich durch die steuernden Metadaten des jeweiligen Datensatzes festgelegt. Das heißt, für eine Datenmodell-Definition (z.B. document) können Datensätze mit (Buch mit Kapiteln) und ohne (Dokument) nebeneinander eingestellt werden. Wichtig ist nur, dass die Vererbung nur innerhalb eines Datenmodells oder eines, welches die gleiche Struktur aufweist, jedoch andere Pflichtfelder hat, funktioniert. Vererbung zwischen Datenmodellen mit verschieden Metadaten ist ausgeschlossen.

Im Folgenden soll die Vererbung anhand der XML-Syntax zweier Metadaten-Objekte verdeutlicht werden. Beim Laden der Daten wird dann eine Eltern-Kind-Beziehung im System aufgebaut und abgespeichert.

Die beiden Datensätze (Abbildung 1.2 und 1.3) sollen folgendes Szenario widerspiegeln:

• Der Titel soll für die Kind-Daten übernommen werden und durch diese um die Kapitelüberschriften ergänzt werden.
• Die Autorendaten sind an alle Kinder zu vererben.
• Der Umfang des Werkes ist je nach Stufe anzugeben, also für das gesamte Buch die Gesamtzahl der Seiten und für ein Kapitel die Anzahl dessen Seiten.

Abbildung 1.2: Auszug aus dem Metadaten-Objektes des Elternsatzes

Entscheidend für die Umsetzung sind folgende Dinge:

• Das Attribut heritable sagt, ob ein Metadatum vererbbar (true) oder nicht (false) sein soll.
• Das Attribut notinherit sagt, ob das Metadatum von dem Elterndatensatz nicht geerbt werden soll (true). Andernfalls wird geerbt (false).
• Es muss erst der Elterndatensatz eingespielt werden. Anschließend können die Kinddatensätze der nächsten Vererbungsebene eingespielt werden. Enkeldatensätze folgen darauf, usw. Bitte beachten Sie das unbedingt beim Restore von Sicherungen in das System. MyCoRe ergänzt intern die Daten der Kind-Datensätze für die Suchanfragen um die geerbten Daten.
• Das Attribut inherited ist per Default auf 0 gesetzt und beschreibt die Anzahl der geerbten Daten. Das Attribut wird vom System automatisch gesetzt. Kinder erhalten, wenn sie Daten geerbt haben, inherited=1 usw., je nach Stufe.

Abbildung 1.3: Auszug aus dem Metadaten-Objektes des Kindsatzes

Die Ausgabe des Eltern-Datensatzes nach einer Query entspricht dem der Dateneingabe, lediglich im XML-structure-Teil wurde ein Verweis auf die Kinddaten eingetragen (siehe XML-Syntax im User Guide).

Abbildung 1.4: XML-Syntax eines Kind-Datensatzes als Query-Resultat

Die Abbildung 1.4 zeigt den Kind-Datensatz, wie er vom System nach einer erfolgreichen Anfrage im Resultats-Container zurückgegeben wird. Dabei ist deutlich die Funktionalität der MyCoRe-Vererbungsmechanismen zu erkennen.