%0 Journal Article %1 BeckR2007 %A Beck, Hendrik %A Rücker, Bernd %D 2007 %J c't %K Jackrabbit java jcr jsr170 %P 27 - 31 %T Mein Name ist Hase und ich weiß Bescheid %V 3 %X Der Artikel führt in das Thema des Java Content Repository (JCR) ein. Eine erste und noch aktuelle Spezifikation erfolgte über JSR170 und eine Überarbeitung durch JSR283 (JCR2.0). Eine OpenSource Implementierung ist Jackrabbit und findet sich auf jackrabbit.apache.org. Die Spezifikation bietet eine Einteilung der Implementationen in folgende Gruppen: + Level 1 nur lesender Zugriff + Level 2 schreibender Zugriff + optionale Funktionalitäten Jackrabbit ist JCR konvorm mit Level 1 und 2 sowie den optionalen Funktionen. Damit ist Jackrabbit eine vollständige Implementierung des JCR 1.0. Das JCR Repository Modell sieht folgende Elemente vor: + Workspace, ist ein abgeschlossener Bereich zur Speicherung von Content + Node, ist ein Verwaltungselement zur Strukturierung des Contents innerhalb eines Workspaces + Property, ist der Content selbst. Ein Property besitzt keine Kinder. Nodes werden nach Typen unterschieden. Hierbei gibt es einige vordefinierte Typen wie: + mix:versionable (für versionierbaren Content) + nt:file (Abbildung von Dateien) + nt:folder (Abbildung von Verzeichnissen) In der Regel müssen und sollen aber eigene Nodetypen definiert werden. Folgende Implementierungen existieren auf dem Markt: + Referenzimplementierung der Firma Day Software + Content Repository Extreme ebenfalls von Day Software + Apache Jackrabbit + Jeiceira, exoJCR, Alfresco und weitere Implementierungen Das zu implementierende API liegt im Package javax.jcr.* Zum Deployment sind 3 Varianten vorstellbar: + Reine Webanwendung mit im war integrierten Repository, das funktioniert auch ohne Applikation Server wie z.B. beim CMS Magnolia + Java EE Resource im Applikationsserver mit Zugriff aus allen dort verteilten Anwendungen + als dedizierter Server welcher einen einheitlichen Zugriff auf das CR bietet z.B. über RMI, WebdAV oder ähnlichem. Folgende Persistenzstrategien existieren: + In-Memory: Content wird nur im Speicher gehalten. Das genügt nur für Tests + ObjectPersistenceManager: Content wird in speziellen Datendateien im Filesystem gehalten. Diese Strategie hat Probleme bei der Verwendung von Clustern. Möglicher Ausweg Netzwerkfähiges Filesystem. + XMLPersistenceManager: Content wird in XML Dateien im Filesystem gehalten. Nachteile durch Probleme bei der Clusterung wie auch schlechte Performance. Nur für Testzwecke zu empfehlen. + SimpleDbPersistenceManager: Content wird per JDBC in einer Datenbank gehalten. Gute Performance aber komplexe Konfiguration. Fazit: JCR ist gut und Jackrabbit eine akzeptable Lösung.

@article{BeckR2007, abstract = {Der Artikel führt in das Thema des Java Content Repository (JCR) ein. Eine erste und noch aktuelle Spezifikation erfolgte über JSR170 und eine Überarbeitung durch JSR283 (JCR2.0). Eine OpenSource Implementierung ist Jackrabbit und findet sich auf jackrabbit.apache.org. Die Spezifikation bietet eine Einteilung der Implementationen in folgende Gruppen: + Level 1 nur lesender Zugriff + Level 2 schreibender Zugriff + optionale Funktionalitäten Jackrabbit ist JCR konvorm mit Level 1 und 2 sowie den optionalen Funktionen. Damit ist Jackrabbit eine vollständige Implementierung des JCR 1.0. Das JCR Repository Modell sieht folgende Elemente vor: + Workspace, ist ein abgeschlossener Bereich zur Speicherung von Content + Node, ist ein Verwaltungselement zur Strukturierung des Contents innerhalb eines Workspaces + Property, ist der Content selbst. Ein Property besitzt keine Kinder. Nodes werden nach Typen unterschieden. Hierbei gibt es einige vordefinierte Typen wie: + mix:versionable (für versionierbaren Content) + nt:file (Abbildung von Dateien) + nt:folder (Abbildung von Verzeichnissen) In der Regel müssen und sollen aber eigene Nodetypen definiert werden. Folgende Implementierungen existieren auf dem Markt: + Referenzimplementierung der Firma Day Software + Content Repository Extreme ebenfalls von Day Software + Apache Jackrabbit + Jeiceira, exoJCR, Alfresco und weitere Implementierungen Das zu implementierende API liegt im Package javax.jcr.* Zum Deployment sind 3 Varianten vorstellbar: + Reine Webanwendung mit im war integrierten Repository, das funktioniert auch ohne Applikation Server wie z.B. beim CMS Magnolia + Java EE Resource im Applikationsserver mit Zugriff aus allen dort verteilten Anwendungen + als dedizierter Server welcher einen einheitlichen Zugriff auf das CR bietet z.B. über RMI, WebdAV oder ähnlichem. Folgende Persistenzstrategien existieren: + In-Memory: Content wird nur im Speicher gehalten. Das genügt nur für Tests + ObjectPersistenceManager: Content wird in speziellen Datendateien im Filesystem gehalten. Diese Strategie hat Probleme bei der Verwendung von Clustern. Möglicher Ausweg Netzwerkfähiges Filesystem. + XMLPersistenceManager: Content wird in XML Dateien im Filesystem gehalten. Nachteile durch Probleme bei der Clusterung wie auch schlechte Performance. Nur für Testzwecke zu empfehlen. + SimpleDbPersistenceManager: Content wird per JDBC in einer Datenbank gehalten. Gute Performance aber komplexe Konfiguration. Fazit: JCR ist gut und Jackrabbit eine akzeptable Lösung.}, added-at = {2010-09-12T18:13:43.000+0200}, author = {Beck, Hendrik and Rücker, Bernd}, biburl = {https://www.bibsonomy.org/bibtex/2492e458fc9482567445b43674a91eadb/funthomas424242}, interhash = {a67ecd545bb66a1bba16c1f74bb30001}, intrahash = {492e458fc9482567445b43674a91eadb}, journal = {c't}, keywords = {Jackrabbit java jcr jsr170}, pages = {27 - 31}, timestamp = {2016-02-21T15:19:06.000+0100}, title = {Mein Name ist Hase und ich weiß Bescheid}, volume = 3, year = 2007 }