JusCMS Architecture Options Figures

JusCMS,MPDL

Architekturoptionen in graphischer Darstellung: Einführung

Nachstehend Grafiken zu optionalen Workflows und den bei der Umsetzung anfallenden Aufgaben = TASKs. Die TASKs sind den einzelnen Workflow-Stationen zugeordnet.

Bei jedem Modell treten einige generelle Nachteile auf, die nicht- oder nur langfristig- durch Programmierung behoben werden können und kontinuierlich Ressourcen binden. Diese Nachteile sind also keine Tasks, die (im Projektverlauf) gelöst werden können und sind daher nicht in den Grafiken enthalten. Sie sollten aber bei einer Entscheidungsfindung berücksichtigt werden.

Legende Grafiken:

ROT Programmieraufgaben, die zu erledigen sind
 * alle TASKS sind gleich groß dargestellt. Das heißt aber nicht, dass der Aufwand gleich hoch ist. Hier wäre von den zuständigen Personen eine Aufwand- und Machbarkeitsschätzung pro Task vorzunehmen (Projekt-Programmierer, MPDL, Contens)

GELB Tasks oder Funktionen, die bereits im Ansatz (auf PubMan oder Contens-Ebene) bearbeitet bzw. vorhanden sind und daher vermutlich „nur“ noch angepasst oder erweitert werden müssen

GRÜN Tasks, die bereits erledigt wurden (für Hamburg) und weitergegeben werden können, noch vorhandener Anpassungsbedarf ist ggf. GELB gekennzeichnet

Genereller Task (dessen Umfang nicht zu unterschätzen ist), der auch für die grünen Bereiche gilt: DOKUMENTATION Sinnvolle Dokumentation unterstützt die langfristige Lauffähigkeit jedes Modells. Es sollte auch für Personen, die aktuell nicht in das Projekt involviert sind, in einigen Jahren nachvollziehbar sein, was wo wie passiert. Ggf. werden noch nicht involvierte Personen Änderungen und/oder Erweiterungen organisieren oder selbst vornehmen müssen.

''Es ist sicher nicht an alle Aufgaben und Nachteile gedacht worden. Daher sind Ergänzungen und Kommentare zu den einzelnen Abschnitten gern willkommen. Es kann z.B. durchaus sein, dass im PubMan-Bereich etwas "gelb" gekennzeichnet wurde, das längst "grün" ist.''

=Konzept 1: Primäre Datenhaltung in eSciDoc / PubMan (entspr. Konzept I des Papiers "Optionen")=

Eingabe durch Wissenschaftler, Ausgabe der Publ. als HTML-Seite
thumb|left|Datenhaltung PubMan, Eingabe Wiss., Ausg. HTML-Seiten

Generelle Nachteile:
 * Komplette Benutzerverwaltung in PubMan UND Contens (ev. mittel- bis langfristig durch Shibboleth lösbar, aber nur wenn PubMan UND Contens angebungen sind)
 * Wissenschaftler müssen in zwei Systemen arbeiten
 * Einführung neuer Wissenschaftler in zwei Systeme kontinuierlich notwendig
 * Bei Ausfall PubMan:
 * keine Änderungs- / Ergänzungsmöglichkeiten Publikationen
 * ev. fehlerhafte Anzeige im CMS


 * Korrekt angezeigte Mitarbeiter- u. Publikationsseiten sind vom Funktionieren zweier Systeme abhängig
 * Wartezeit, bis Eingabeergebnis für Wissenschaftler auf Homepage sichtbar ist

--Kortuem 09:14, 16 April 2009 (UTC)Anmerkung MPI GE: Welche Vorteile gibt es?

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

Eingabe durch Zentrale Stelle, Ausgabe der Publ. als HTML-Seite
thumb|left|Datenhaltung PubMan, Eingabe ZS, Ausg. HTML-Seiten

Generelle Nachteile:
 * Zentrale Stelle 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- / Ergänzungsmöglichkeiten Publikationen
 * ev. fehlerhafte Anzeige im CMS


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

--Kortuem 09:14, 16 April 2009 (UTC)Anmerkung MPI GE: Welche Vorteile gibt es?

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

--Kortuem 08:28, 16 April 2009 (UTC)Erweiterung MPI GE:
 * Erster Schritt: Zentrale Stelle muss von Wissenschaftler den ersten Anstoss 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 schliesst die Ausgabe der Publikation als HTML-Seite aus--Kortuem 08:28, 16 April 2009 (UTC)

Eingabe durch Wissenschaftler, Ausgabe der Publ. als CMS-Objekt
thumb|left|Datenhaltung PubMan, Eingabe Wiss., Ausg. Objekt

Generelle Nachteile:
 * Komplette Benutzerverwaltung in PubMan UND Contens (ev. mittel- bis langfristig durch Shibboleth lösbar)
 * Wissenschaftler müssen in zwei Systemen arbeiten
 * Einführung neuer Wissenschaftler in zwei Systeme kontinuierlich notwendig
 * 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
 * Wartezeit, bis Eingabeergebnis für Wissenschaftler auf Homepage sichtbar ist

--Kortuem 09:14, 16 April 2009 (UTC)Anmerkung MPI GE: Welche Vorteile gibt es?

Frage:
 * an Contens: Performance bei zahlreichen Objeken auf einer Seite?

Eingabe durch Zentrale Stelle, Ausgabe der Publ. als CMS-Objekt
thumb|left|Datenhaltung PubMan, Eingabe ZS, Ausg. Objekt

Generelle Nachteile:


 * Zentrale Stelle muss stets besetzt sein
 * Diverse Rücksprachen zwischen ZS und Wiss. nötig- ggf. hierdurch Verlängerung des Geschäftsgangs
 * 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
 * Wartezeit, bis Eingabeergebnis für Wissenschaftler auf Homepage sichtbar ist

--Kortuem 09:14, 16 April 2009 (UTC)Anmerkung MPI GE: Welche Vorteile gibt es?

Frage:
 * an Contens: Performance bei zahlreichen Objeken auf einer Seite?

--Kortuem 08:28, 16 April 2009 (UTC)Erweiterung MPI GE: --Kortuem 08:28, 16 April 2009 (UTC)
 * Erster Schritt: Zentrale Stelle muss von Wissenschaftler den ersten Anstoss 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)

Eingabe durch Wissenschaftler ODER Zentrale Stelle, Ausgabe der Publ. als HTML-Seite
thumb|left|Datenhaltung PubMan, Eingabe Wiss./ZS, Ausg. HTML-Seiten

Generelle Nachteile:(je nach Geschäftsgang) ODER UND
 * Zentrale Stelle muss stets besetzt sein
 * Diverse Rücksprachen zwischen ZS und Wiss. nötig- ggf. hierdurch Verlängerung des Geschäftsgangs
 * Stets Einführung neuer Wissenschaftler in die Publikationenerfassung in PubMan notwendig
 * Wartezeit, bis Eingabeergebnis für Wissenschaftler auf Homepage sichtbar ist

--Kortuem 09:14, 16 April 2009 (UTC)Anmerkung MPI GE: Welche Vorteile gibt es?

Fragen:
 * s. oben (Konzept 1.1)

--Kortuem 08:28, 16 April 2009 (UTC)Erweiterung MPI GE:
 * Alternative Wahlmöglichkeiten Eingabe über Wissenschaftler oder ZS nicht ganz eindeutig erkennbar
 * Stimmt- das ODER fehlt leider in der Grafik. S. hierzu Grafik 2.3 Iarndt 13:55, 19 April 2009 (UTC)


 * Erster Schritt (sofern Wissenschaftler Eingaben macht; hier schon abgebildet): Zentrale Stelle muss von Wissenschaftler den ersten Anstoss 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 schliesst die Ausgabe der Publikation als HTML-Seite aus--Kortuem 08:28, 16 April 2009 (UTC)
 * Nur dann, wenn folgende Funktion ein Muss ist: "...und Möglichkeit zum sofortigen Publizieren)" Iarndt 13:53, 19 April 2009 (UTC)

--Kortuem 08:28, 16 April 2009 (UTC)Zusatzkonzept 1.6 MPI GE: Eingabe durch Wissenschaftler ODER Zentrale Stelle, Ausgabe als CMS-Objekt --Kortuem 08:28, 16 April 2009 (UTC)
 * Vereinigung der Konzepte 1.5, 1.3 bzw. 1.4
 * Darstellung der Vor- und Nachteile offen
 * Derzeit präferiertes Konzept MPI GE innerhalb des Konzeptes 1 (=Primäre Datenhaltung/Primäre Eingabe in eSciDoc/PubMan)

=Konzept 2: Primäre Datenhaltung im CMS (=entspr. Konzept II aus dem Papier "Optionen")=

Eingabe durch Wissenschaftler
thumb|left|Datenhaltung Contens, Eingabe Wiss., Upload in PubMan

Generelle Nachteile:


 * Stets Einführung neuer Wissenschaftler in die Publikationenerfassung im CMS notwendig

--Kortuem 09:14, 16 April 2009 (UTC)Anmerkung MPI GE: Welche Vorteile gibt es?

Fragen:


 * an Contens: Performance bei zahlreichen Objeken auf einer Seite?

Eingabe durch Zentrale Stelle
thumb|left|Datenhaltung Contens, Eingabe ZS, Upload in PubMan

Generelle Nachteile:
 * Zentrale Stelle muss stets besetzt sein
 * Diverse Rücksprachen zwischen ZS und Wiss. nötig- ggf. hierdurch Verlängerung des Geschäftsgangs
 * Wartezeit, bis Eingabeergebnis für Wissenschaftler auf Homepage sichtbar ist

--Kortuem 09:14, 16 April 2009 (UTC)Anmerkung MPI GE: Welche Vorteile gibt es?

Fragen:
 * an Contens: Performance bei zahlreichen Objeken auf einer Seite?

Eingabe durch Wissenschaftler ODER Zentrale Stelle
thumb|left|Datenhaltung Contens, Eingabe Wiss./ZS, Upload in PubMan

Generelle Nachteile:(je nachdem, welchen Geschäftsgang man einsetzt) ODER
 * Zentrale Stelle muss stets besetzt sein
 * Diverse Rücksprachen zwischen ZS und Wiss. nötig- ggf. hierdurch Verlängerung des Geschäftsgangs
 * Wartezeit, bis Eingabeergebnis für Wissenschaftler auf Homepage sichtbar ist
 * Stets Einführung neuer Wissenschaftler in die Publikationenerfassung im CMS notwendig

--Kortuem 09:14, 16 April 2009 (UTC)Anmerkung MPI GE: Welche Vorteile gibt es?

Fragen:
 * an Contens: Performance bei zahlreichen Objeken auf einer Seite?

--Kortuem 08:28, 16 April 2009 (UTC)Erweiterung MPI GE: --Kortuem 08:28, 16 April 2009 (UTC)
 * Alternative Wahlmöglichkeiten Eingabe über Wissenschaftler oder ZS nicht ganz eindeutig erkennbar
 * Derzeit präferiertes Konzept MPI GE innerhalb des Konzeptes 2 (=Primäre Datenhaltung/Primäre Eingabe in CMS)

=Kombinationen (neue Variante, ohne Entsprechung im Papier "Optionen")=

--Kortuem 09:24, 16 April 2009 (UTC)Hinweis: Konzept III - Datenhaltung in eigentstäniger SQL-Datenbank bzw. eigenständigem Repository ist hier nicht dargestellt

Kombination "synchronisierte Datenbank": Eingabe in PubMan ODER Contens, Eingabe durch Wiss. ODER ZS
thumb|left|Datenhaltung PubMan/Contens, Eingabe Wiss./ZS, Objekte

Erläuterung:
 * die Grafik basiert auf der Ausgabe als Objekt, nicht als HTML-Seite
 * auf eine Auflistung der Tasks wurde in der Grafik verzichtet, da dies den Rahmen der Folie gesprengt hätte
 * es fallen sämtliche Tasks für die Lösungen 1.3 (plus zusätzliche Tasks für Alternativeingabe Wissenschaftler oder zentrale Stelle) und 2.3 an
 * hinzu kommt der äußerst aufwändige TASK "Synchronisierung der Datenbanken PubMan/Contens"

Generelle Nachteile:
 * äußerst aufwändige Realisierung
 * fehleranfälliger Betrieb
 * wartungsintensiv
 * darüber hinaus je nach gewähltem Geschäftsgang die oben aufgelisteten Nachteile

--Kortuem 09:14, 16 April 2009 (UTC)Anmerkung MPI GE: Welche Vorteile gibt es?

--Leitl 16 April 2009 (UTC)Anmerkung MPI GE: =weitere grundsätzliche Überlegungen=

Synchronisation
Neben der, allen Optionen zugrundeliegenden 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 hier bei unterschiedliche Datenbanksysteme auftreten könnten).  Auch wenn damit zusätzliche Felder einer Abstimmung mit PubMan erfordern oder gar eine extra Repository wegen "Sonderanforderungen" oder um schnell reagieren zu können, halte ich die Vorteile für sehr groß z.B.
 * Unabhängigkeit von PubMan oder Contens, da die Datenbank identisch ist, und SQL-Abfragen (nahezu) gleich sind und damit das Projekt leicht angepasst / nachprogrammiert werden kann
 * 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, ...)
 * die Frage der primären Datenhaltung spielt so gut wie keine Rolle.

Weitere Datenbank beim Webserver(nur ein Randgedanke)
In den Architekturoption ist nur von PubMan oder dem Redaktionsserver die Rede. In bestimmten Fällen kann es sinnvoll werden, auch beim Webserver eine DB zu haben (Unabhängigkeit von PubMan oder Redaktionsserver). Dies würde auch die Möglichkeit eröffnen, dort auch die Eingabe der Daten für die Publikationen durchzuführen (beim GE praktisch erprobt mit dem Stipendienworkflow und der Publikationseingabe für Stipendiaten). Ein weiterer Vorteil wäre, dass dort keine Benutzerverwaltung aufgebaut werden müßte, da einer LDAP-abfrage kaum Sicherheitsbedenken entgegenstehen. bereits in frühen Überlegungen zu dem Gesamtprojekt wurden folgende Nachteil aufgezeigt, die durch eine DB-Kopie beim Webserver aufgehoben würden:
 * 100%ige Abhängigkeit CMS und / oder PubMan
 * Performanz wird in Frage gestellt
 * hohe Fehleranfälligkeit (ev. fehlerhafte Anzeige im CMS)
 * globale Suche bedeutet aufwändige Programmierung über zwei Systeme

=Zugehörige Seiten=

JusCMS Architecture Options JusCMS Architecture Options Overview JusCMS Architecture Options Advantages/Disadvantages