JusCMS Architecture Options Advantages/Disadvantages

JusCMS,MPDL

=Allgemeine Anmerkungen und Fragen= '''(a) Ist primäre Datenhaltung/Dateneingabe damit gleichzusetzen, dass in diesem System auch alle notwendigen Indexierungen / Suchanfragen vorgenommen werden? Was können die jeweiligen Systeme in diesem Bereich bereits jetzt? Ist es sinnvoll einzelne Aufgaben auf zwei (drei?) Systeme zu verteilen?''' (b) Kann eine Dublettenkontrolle in dem einen oder anderen System umgesetzt werden? (c) Wie autonom ist eine Speziallösung JusCMS in PubMan (während des Projekts, im Produktivbetrieb)? (d) Synchronisation (Anmerkung von Herrn Leitl)
 * Anmerkung Herr Weber.: Worin liegt Unterschied zu Konzept 3 = echte doppelte Datenhaltung; welche Vorteile hätte diese Lösung gegenüber Konzept 3?
 * Neben der, allen Konzepten zugrunde liegenden Annahme, die Daten an die nichtprimären Systeme zu exportieren bzw. zu importieren, sollten wir eine echte Synchronisation ins Auge fassen, welche vom Datenbanksystem aus "verwaltet" wird. Vielleicht kann uns die MPDL über diese Möglichkeit näher informieren (ich bin mir insbesondere nicht klar, welche Schwierigkeit hierbei unterschiedliche Datenbanksysteme auftreten könnten). Auch wenn damit zusätzliche Felder eine Abstimmung mit PubMan erfordern oder gleich, um schnell reagieren zu können vielleicht ebenso wie "Sonderanforderungen" möglicherweise eine extra Repository, halte ich die Vorteile für sehr groß z.B.
 * Anmerkung Herr Weber.: Hat man so nicht doch ein weiteres Problemfeld, wenn Störungen auftreten – Fehlersuche? Sind die beschriebenen Vorteile wirklich so relevant? Geht man von einer guten Performanz der primären Datenquelle aus, so liegen die Vorteile doch allein in der Unabhängigkeit von einer stets verfügbaren Internetverbindung?
 * nur lokale Probleme beim Ausfall einer Instanz (sei dies nun PubMan, der Redaktionsserver, oder der Webserver)
 * es kann leicht eine weitere Kopie erstellt werden, um den lokalen Webserver völlig unabhängig zu machen, bzw. falls mit dynamischen Sites gearbeitet werden soll, kann eine deutliche Beschleunigung erreicht werden.
 * keine Eigenprogrammierung des Exports notwendig (und damit später auch keine Ergänzungen, ...)
 * nahezu unabhängig von PubMan oder Contens, da die Datenbank identisch ist und SQL-Abfragen (nahezu) gleich sind
 * die Frage der primären Datenhaltung spielt so gut wie keine Rolle

(e) Weitere Datenbank (Randgedanke Herr Leitl)
 * Anmerkung Herr Weber: Worin liegt genau der Unterschied zur Synchronisation: Müsste nicht auch die weitere Datenbank permanent mit der primären Datenquelle synchronisiert werden?
 * In den Architekturkonzepten ist nur von PubMan oder dem Redaktionsserver die Rede. In bestimmten Fällen kann es sinnvoll werden, auch beim Webserver eine DB zu haben (s.o.).
 * Anmerkung Frau Kortüm: Um welche Fälle handelt es sich genau?
 * Dies würde die Möglichkeit eröffnen, dort auch die Eingabe der Daten durchzuführen (beim MPI GE praktisch erprobt mit dem Stipendienworkflow und der Publikationseingabe für Stipendiaten).
 * Anmerkung Frau Kortüm: Um welche Fälle handelt es sich genau?
 * Anmerkung Herr Weber: Worin liegt für diese 3. Option der Vorteil und bedingt dies nicht eine Synchronisation in eine bzw. zwei Richtungen?
 * Ein weiterer Vorteil wäre, dass dort keine Benutzerverwaltung aufgebaut werden müsste, da einer LDAP-Abfrage kaum Sicherheitsbedenken entgegenstehen.

=Vor- und Nachteile der Dateneingabe= (beziehen sich auf die Konzepte 1. und 2. ; siehe auch Jus CMS Architecture Figures, dort wird von „primärer Datenhaltung“ gesprochen)

(a) Konzept 1: Primäre „Datenhaltung“ in eSciDoc/PubMan
(das Konzept Primäre „Datenhaltung in eDoc aus dem Antrag wird nicht mehr diskutiert)

Allgemeine Vorteile:

 * keine neuen Server nötig
 * Nutzung der Möglichkeiten der MPDL
 * definierte Felder bzw. Inhalte für Im-/Export vorhanden
 * geringerer Aufwand und niedrigere Kosten für Planung und Entwicklung als in allen anderen Konzepten

Allgemeine Nachteile:

 * Wartezeit, bis Eingabeergebnis für Wissenschaftler auf Homepage sichtbar ist

Sonstige allgemeine Nachteile:

 * eSciDoc noch in Entwicklungsphase: Realisierung und Zeitpunkt einer Nutzbarkeit ungewiss (aber: schriftliches Konzept vorhanden und „working prototype“ in der Testphase, so dass sich eine Konkretisierung abzeichnet)
 * Anmerkung MPI Priv.: Zeitpunkt der Nutzbarkeit ist erreicht


 * bei „early adopter“ Prozess: aufgrund grundsätzlich unterschiedlicher Ansätze (CMS-Projektgruppe: Darstellung der Daten nach juristischer Zitierweise; eSciDoc/PubMan: Darstellung der Daten im Stil eines Bibliothekskatalogs) fraglich, ob konzeptionelle Anforderungen erfüllt werden können
 * Anmerkung MPI Priv.: nach Aussage MPDL jetzt machbar


 * bei „early adopter“ Prozess: Lösung technisch aufwendig und Umsetzung aufgrund Abhängigkeit externer Datenhaltung sowie Vorgaben für Datenstruktur und Inhalte als eigene Datenbank (siehe unten Konzept 3) problematischer
 * Einsatz eigener Mitarbeiter und Contens (und/oder andere Fremdfirma) für „Verbindungen“ zu den Verwendungen (z.B. Anzeige auf den Webseiten der Institute mittels Referenzierung) erforderlich: Kosten möglicherweise nicht geringer als bei Aufbau einer eigener Datenbank (siehe unten Konzept 3) – mit Prüfungsvorbehalt
 * eSciDoc/PubMan Grundkonzept angeblich mit Mängeln behaftet: Eindeutigkeit der Datensätze, Performanz und Konsistenz (informelle Hintergrundinformation über MPI Sozialrecht; siehe Gesprächnotiz Florian Bruder und Sylvia Kortüm vom Termin 11.09.07, Kritikpunkte MPI Sozialrecht, E-mail vom 02.10.07 sowie Bewertung durch Jochen Jähnke, E-mail vom 08.10.07); weitere technische Überprüfung wäre erforderlich und sinnvoll
 * Anmerkung Herr Weber: Wie autonom ist eine Speziallösung JusCMS in Pubman (während des Projekts, im Produktivbetrieb)?

Details Kritikpunkte / Erfahrungsbericht'''
(Zusammentragung von Gesprächsnotizen aus 2007 von Mitarbeitern und Ehemaligen (aus Diskretionsgründen keine Namensnennung; Kritikpunkte wurden versachlicht))
 * Datenmigration eDoc/PubMan problematisch (Kommentar 2009: Migration für MPI PLI hat bereits stattgefunden. Probleme??)
 * Tabelle mit Kritikpunkten erstellt, spezifisch zu eDoc, aber evtl. auch relevant für eSciDoc
 * Anmerkung MPI Priv.: Tabelle liegt leider nicht vor


 * Kritik an Grundkonzeption eSciDoc (Probleme der Eindeutigkeit, Performanz, Konsistenz): XML-setup birgt Probleme der Eindeutigkeit und Klarheit in sich; fehlt und muss mit erheblichem Programmieraufwand hergestellt werden (eDoc als relationale Datenbank würde bei Anpassungen funktionieren)
 * Probleme: eindeutige Definition von Daten
 * eSciDoc wird ein großer Container; es wird schwierig sein, Daten wieder zu finden und konsistent zu halten
 * in der Vorversion angeblich schon Performanceprobleme – JAVA.
 * Jahrbuchdaten aus eDoc/PubMan: wie wird das laufen?
 * Grundproblem der Eindeutigkeit der Datensätze kann durch riesige Maschinerie kaschiert werden, aber Grundprobleme bleiben und kommen wieder hoch
 * Performanz und Konsistenz: kann nicht ordentlich erreicht werden
 * Risiko, dass eSciDoc nicht läuft
 * es bestehen Zweifel am Projekt "Fedora"
 * Anmerkung MPI Priv.: Worum geht's?


 * Updates / Upgrades: Das Hauptrepository ist ständiges Entwicklungssystem

Nachteile der Referenzierung:

 * 100%ige Abhängigkeit CMS/PubMan
 * Performanz wird in Frage gestellt
 * hohe Fehleranfälligkeit
 * globale Suche bedeutet aufwändige Programmierung über zwei Systeme

Vorteile:

 * Ausgabe als HTML-Seite – alles kommt aus einer Hand (wenn Datenhaltung in PubMan)
 * s.o. 2.a. allgemeine Vorteile

Nachteile:

 * Komplette Benutzerverwaltung in PubMan UND Contens (ev. mittel- bis langfristig durch Shibboleth lösbar, aber nur wenn PubMan UND Contens angebunden sind)
 * Wissenschaftler müssen in zwei Systemen arbeiten
 * Einführung neuer Wissenschaftler in zwei Systeme kontinuierlich notwendig
 * Bei Ausfall PubMan:
 * keine Änderungs- und Ergänzungsmöglichkeiten der Publikationen
 * ev. fehlerhafte Anzeige im CMS
 * Korrekt angezeigte Mitarbeiter- u. Publikationsseiten sind vom Funktionieren zweier Systeme abhängig
 * Ausgabe als HTML-Seite:
 * Keine rasche Anzeige (z.B. nach rudimentärer Eingabe)
 * Aufbau der Website aus verschiedenen Quellen (Redaktionsystem, Programme auf dem Webserver, PubMan)
 * Anpassung an unsere Stile erforderlich (auch später, z.B. relaunch zu barrierefrei)
 * s.o. 2.a. allgemeine Nachteile

Fragen:

 * an MPDL: Performance?
 * an MPDL/Contens: Seiteninhalte müssen für CMS-Webserver-Suche verfügbar sein. Wie lösen?

Vorteile:

 * Ausgabe HTML-Seite – alles kommt aus einer Hand (wenn Datenhaltung in PubMan), s.o. 2.a.aa
 * Später entfällt Korrektur der Daten, da Zentrale Stelle (ZS) bereits hier umfassend auf alle notwendigen Inhalte für verschiedene Verwendungen achtet
 * Keine Doppelschulung der Wissenschaftler
 * s.o. 2.a. allgemeine Vorteile

Nachteile:

 * ZS muss stets besetzt sein
 * Diverse Rücksprachen zwischen ZS und Wiss. nötig- ggf. hierdurch Verlängerung des Geschäftsgangs
 * Bei Ausfall PubMan:
 * keine Änderungs- und Ergänzungsmöglichkeiten der Publikationen
 * ev. fehlerhafte Anzeige im CMS, s.o. 2.a.aa
 * Korrekt angezeigte Mitarbeiter- u. Publikationsseiten sind vom Funktionieren zweier Systeme abhängig, s.o.2.a.aa
 * Ausgabe als HTML-Seite:
 * Keine rasche Anzeige (z.B. nach rudimentärer Eingabe)
 * Aufbau der Website aus verschiedenen Quellen (Redaktionsystem, Programme auf dem Webserver, PubMan)
 * Anpassung an unsere Stile erforderlich (auch später, z.B. relaunch zu barrierefrei), s.o. 2.a.aa
 * s.o. 2.a. allgemeine Nachteile

Fragen:

 * an MPDL: Performance?
 * an MPDL/Contens: Seiteninhalte müssen für CMS-Webserver-Suche verfügbar sein. Wie lösen?

Erweiterung:

 * Erster Schritt: ZS muss von Wissenschaftler den ersten Anstoß erhalten, dass eine neue Veröffentlichung vorliegt → Option der rudimentären Eingabe der Publikationsdaten im CMS durch den Wissenschaftler (=Anlegen eines einfachen Objekts und Möglichkeit zum sofortigen Publizieren)
 * Variante schließt aber die Ausgabe der Publikation als HTML-Seite aus (?)

Vorteile:

 * Ausgabe als CMS-Objekt
 * Gewohntes Arbeiten in CMS
 * Gleiches Erscheinungsbild
 * Bei den bisherigen Seiten muss vielleicht nur ein Link umgestellt werden
 * s.o. 2.a. allgemeine Vorteile

Nachteile:

 * Augabe als CMS-Objekt – wir müssen selber programmieren
 * Komplette Benutzerverwaltung in PubMan UND Contens (ev. mittel- bis langfristig durch Shibboleth lösbar), s.o. 2.a.aa
 * Wissenschaftler müssen in zwei Systemen arbeiten, s.o. 2.a.aa
 * Einführung neuer Wissenschaftler in zwei Systeme kontinuierlich notwendig, s.o. 2.a.aa
 * Bei Ausfall PubMan kein weiteres Anlegen von Publ.-Objekten möglich, in Contens vorgenommene Objektänderungen müssen manuell in PubMan nachvollzogen werden
 * Aktuelle Mitarbeiter- u. Publikationsseiten sind vom Funktionieren zweier Systeme abhängig
 * s.o. 2.a. allgemeine Nachteile

Frage:

 * an Contens: Performance bei zahlreichen Objekten auf einer Seite

Vorteile:

 * Ausgabe als CMS-Objekt
 * Gewohntes Arbeiten im CMS
 * Gleiches Erscheinungsbild
 * Bei den bisherigen Seiten muss vielleicht nur ein Link umgestellt werden s.o. 2.a.cc
 * Keine Doppelschulung der Wissenschaftler, s.o. 2.a.bb
 * Später entfällt Korrektur der Daten, da ZS bereits hier umfassend auf alle notwendigen Inhalte für verschiedene Verwendungen achtet
 * s.o. 2.a. allgemeine Vorteile

Nachteile:

 * Augabe als CMS-Objekt – wir müssen selber programmieren, s.o. 2.a.cc
 * ZS muss stets besetzt sein, s.o. 2.a.bb
 * Diverse Rücksprachen zwischen ZS und Wiss. nötig- ggf. hierdurch Verlängerung des Geschäftsgangs, s.o. 2.a.bb
 * Bei Ausfall PubMan kein weiteres Anlegen von Publ.-Objekten möglich, in Contens vorgenommene Objektänderungen müssen manuell in PubMan nachvollzogen werden, s.o. 2.a.cc
 * Aktuelle Mitarbeiter- u. Publikationsseiten sind vom Funktionieren zweier Systeme abhängig, s.o. 2.a.cc
 * s.o. 2.a. allgemeine Nachteile

Frage:

 * an Contens: Performance bei zahlreichen Objekten auf einer Seite

Erweiterung:

 * Erster Schritt: ZS muss von Wissenschaftler den ersten Anstoß erhalten, dass eine neue Veröffentlichung vorliegt → Option der rudimentären Eingabe der Publikationsdaten im CMS durch den Wissenschaftler (=Anlegen eines einfachen Objekts und Möglichkeit zum sofortigen Publizieren)

Vorteile:

 * Ausgabe HTML-Seite – alles kommt aus einer Hand (wenn Datenhaltung in PubMan), s.o. 2.a.aa
 * Später entfällt Korrektur der Daten, da ZS bereits hier umfassend auf alle notwendigen Inhalte für verschiedene Verwendungen achtet
 * s.o. 2.a. allgemeine Vorteile

Nachteile:
ODER
 * ZS muss stets besetzt sein, s.o. 2.a.bb
 * Diverse Rücksprachen zwischen ZS und Wiss. nötig- ggf. hierdurch Verlängerung des Geschäftsgangs, s.o. 2.a.bb
 * Stets Einführung neuer Wissenschaftler in die Publikationenerfassung in PubMan notwendig, s.o. 2.a.aa
 * Bei Ausfall PubMan:
 * ev. fehlerhafte Anzeige im CMS, s.o.2.a.aa
 * Korrekt angezeigte Mitarbeiter- u. Publikationsseiten sind vom Funktionieren zweier Systeme abhängig, s.o.2.a.aa
 * Ausgabe als HTML-Seite:
 * Keine rasche Anzeige (z.B. nach rudimentärer Eingabe)
 * Aufbau der Website aus verschiedenen Quellen (Redaktionssystem, Programme auf dem Webserver, PubMan), s.o. 2.a.aa
 * s.o. 2.a. allgemeine Nachteile

Fragen:

 * an MPDL: Performance?
 * an MPDL/Contens: Seiteninhalte müssen für CMS-Webserver-Suche verfügbar sein. Wie lösen?

Erweiterung:
(s.o. 2.a.bb und 2.a.dd; hier schon integriert)
 * Variante schließt aber die Ausgabe der Publikation als HTML-Seite aus (?)

Vorteile:

 * Ausgabe als CMS-Objekt
 * Gewohntes Arbeiten im CMS
 * Gleiches Erscheinungsbild
 * Bei den bisherigen Seiten muss vielleicht nur ein Link umgestellt werden, s.o. 2.a.cc
 * s.o. 2.a. allgemeine Vorteile

Nachteile:
ODER
 * Augabe als CMS-Objekt – wir müssen selber programmieren, s.o. 2.a.cc
 * ZS muss stets besetzt sein, s.o. 2.a.bb
 * Diverse Rücksprachen zwischen ZS und Wiss. nötig- ggf. hierdurch Verlängerung des Geschäftsgangs, s.o. 2.a.bb
 * Stets Einführung neuer Wissenschaftler in die Publikationenerfassung in PubMan notwendig, s.o. 2.a.aa
 * Bei Ausfall PubMan kein weiteres Anlegen von Publ.-Objekten möglich, in Contens vorgenommene Objektänderungen müssen manuell in PubMan nachvollzogen werden, s.o. 2.a.cc
 * Aktuelle Mitarbeiter- u. Publikationsseiten sind vom Funktionieren zweier Systeme abhängig, s.o. 2.a.cc
 * s.o. 2.a. allgemeine Nachteile

Erweiterung:
(s.o. 2.a.bb und 2.a.dd; hier schon integriert)

Allgemeine Vorteile:

 * Erforderliche Eigenleistung der CMS-Projektgruppe voraussichtlich am geringsten
 * Anmerkung MPI Priv.: Warum? Aufwand für Konzeptentwicklung gleich hoch
 * Darstellung auf Mitarbeiterseiten ist erprobt, abgestimmt und funktional Benutzerverwaltung nur 1x im CMS notwendig.Nur das Mapping müsste von eDoc auf PubMan umgestellt werden. Nur Skripte für Upload müssten angepasst werden.


 * Vertrautes System für Wissenschaftler
 * Auch später schnelle Reaktionszeit und relativ leichte Behandlung von Sonderfällen
 * „Nachnutzung“ des Hamburger Prototypen

Allgemeine Nachteile:

 * Ausweitung der „Monopolstellung“ von Contens bzgl. Entwicklung, Aufbau, Betrieb, Fehlerbehebung, Wartung, etc.
 * Programmierung kann nicht von MPDL nachgenutzt werden
 * mögliche Probleme bei späterer Anschaffung neuer Systeme bzw. Migration
 * zusätzliche Kosten einer externen Firma (hier: Contens) für Entwicklung und Betrieb
 * Contens Datenbank nicht für Publikationsverwaltung ausgelegt. Anforderungen an Langzeitnachweisbarkeit und Langzeitarchivierung können erst nach PubMan-Upload erfüllt werden
 * Eingabe bleibt benutzerunfreundlich wie bisher:
 * keine verbesserte Hilfe
 * optische Gestaltung bleibt wenig benutzerfreundlich
 * wenig selbsterklärend
 * keine Validierungsmechanismen
 * langfristig ressourcenbindend, da stets Hilfestellung nötig ist
 * langfristig ressourcenbindend, das stets Nachbesserungen an den Daten nötig sind
 * keine externen Schnittstellen der Contens-DB, nur rudimentärer XML-Export möglich

Vorteile:

 * s.o. 2.b. allgemeine Vorteile

Nachteile:

 * Stets Einführung neuer Wissenschaftler in die Publikationenerfassung im CMS notwendig
 * s.o. 2.b. allgemeine Nachteile

Frage:

 * an Contens: Performance bei zahlreichen Objekten auf einer Seite

Vorteile:

 * s.o. 2.b. allgemeine Vorteile

Nachteile:

 * ZS muss stets besetzt sein, s.o. 2.a.bb.
 * Diverse Rücksprachen zwischen ZS und Wiss. nötig- ggf. hierdurch Verlängerung des Geschäftsgangs, s.o. 2.a.bb
 * Wartezeit, bis Eingabeergebnis für Wissenschaftler auf Homepage sichtbar ist
 * s.o. 2.b. allgemeine Nachteile

Frage:

 * an Contens: Performance bei zahlreichen Objekten auf einer Seite

Vorteile:

 * s.o. 2.b. allgemeine Vorteile

Nachteile:
ODER
 * ZS muss stets besetzt sein, s.o. 2.a.bb
 * Diverse Rücksprachen zwischen ZS und Wiss. nötig- ggf. hierdurch Verlängerung des Geschäftsgangs, s.o. 2.a.bb
 * Wartezeit, bis Eingabeergebnis für Wissenschaftler auf Homepage sichtbar ist, s.o.
 * Stets Einführung neuer Wissenschaftler in die Publikationenerfassung im CMS notwendig, s.o. 2.a.aa
 * s.o. 2.b. allgemeine Nachteile

Frage:

 * an Contens: Performance bei zahlreichen Objekten auf einer Seite

Vorteile:

 * autonome Lösung, im Hinblick auf Betrieb und (Weiter-)entwicklung sowie Anschaffung neuer Systeme
 * Anforderungen der CMS-Projektgruppe können erfüllt und nachträglich verändert werden
 * Beauftragung einer Fremdfirma (neben Contens) für Entwicklung und Betrieb der Datenbank möglich, auch Einschaltung konkurrierender Firmen zu einem späteren Zeitpunkt denkbar

Nachteile:

 * Aufwand für Betreuung einer weiteren Datenbank, möglicherweise eines weiteren Systems
 * externe Kosten für Entwicklung (wie bei Konzept 2; aber: evtl. geringere Betriebskosten
 * „Verbindungen“, d.h. Eingabemaske – Daten/Repository - Referenzierungen der Internetseiten (Abfrage einer SQL-Datenbank zum Zeitpunkt der Publikation der Seite) müssen durch Drittfirma (Problem der Rechte von Contens) bzw. Contens aufgebaut werden (jedoch: kein großer technischer Aufwand zu erwarten)

Vorteile:

 * (relativ) autonome Lösung
 * Anforderungen der CMS-Projektgrupe können erfüllt und nachträglich verändert werden
 * Nutzung der Ressourcen der MPDL für den Aufbau (siehe ausführlich dazu Gesprächsnotiz vom 04.09.07)

Nachteile:

 * Aufwand für Betreuung einer weiteren Datenbank, möglicherweise eines weiteren Systems
 * „Verbindungen“, d.h. Eingabemaske – Daten/Repository - Referenzierungen der Internetseiten (Abfrage einer SQL-Datenbank zum Zeitpunkt der Publikation der Seite) müssen durch Drittfirma (Problem der Rechte von Contens) bzw. Contens aufgebaut werden (jedoch: kein großer technischer Aufwand zu erwarten)
 * Anmerkung MPI Priv.: Abhängigkeit der Systeme (Publikationen nicht mehr darstellbar, wenn PubMan-DB nicht erreichbar)


 * eDoc/PubMan Grundkonzept angeblich mit Mängeln behaftet: Eindeutigkeit der Datensätze, Performanz und Konsistenz (informelle Hintergrundinformation über MPI Sozial-recht; siehe Gesprächnotiz Florian Bruder und Sylvia Kortüm vom Termin 11.09.07)

(d) Kombination "synchronisierte Datenbank" - Eingabe in PubMan ODER Contens, Eingabe durch Wiss. ODER ZS
neue Variante

Nachteile:
=Zugehörige Seiten= JusCMS Architecture Options Overview JusCMS Architecture Options Figures
 * äußerst aufwändige Realisierung
 * fehleranfälliger Betrieb
 * wartungsintensiv
 * darüber hinaus je nach gewähltem Geschäftsgang die oben aufgelisteten Nachteile