JusCMS Architecture Feasibility Study Concept 1.6

JusCMS,MPDL

=Machbarkeitsanalyse für Konzept 1.6= =Grafik=

thumb|left|Datenhaltung PubMan, Eingabe Wiss. oder ZS, Ausg. Objekt

=Szenario=

Die primäre Datenhaltung findet in eSciDoc / PubMan statt.

Die Eingabe kann sowohl durch den Wissenschaftler als auch durch eine zentrale Stelle (ZS) erfolgen.

Die Architektur-Option soll 3 mögliche Workflows abbilden:


 * 1) rudimentäre Eingabe der Publikationsdaten durch den Wissenschaftler (in PubMan, im "Look & Feel" von Contens)
 * 2) vollständige Eingabe der Publikationsdaten durch den Wissenschafter (in PubMan, im "Look & Feel" von Contens)
 * 3) vollständige Erfassung der Publikationsdaten durch eine zentrale Stelle (in PubMan, im "Look & Feel" von Contens) - nur in Ausnahmefällen

1. Rudimentäre Eingabe der Publikationsdaten durch den Wissenschaftler:
 * Der Wissenschaftler meldet sich im CMS an und ruft die Seite mit seiner Publikationsliste auf
 * Auf der Publikatiosliste befinden sich zwei Objekte: ein Publikationseingabeobjekt und ein Publikationsdatenlistenobjekt
 * Der Wissenschaftler klickt das Publikationseingabeobjekt an- dies löst die Anzeige der Publikationseingabe in PubMan aus, deren "Look & Feel" dem CMS entspricht. Eine erneute Identifikation in PubMan ist nicht nötig, da die Systeme über OAuth miteinander verbunden sind
 * Der Wissenschaftler hat die Wahl zwischen "rudimentärer" und "vollständiger" Eingabe
 * Er wählt "rudimentäre Eingabe"
 * Das Speichern des Formulars "rudimentäre Eingabe" erzeugt eine Information für die zentrale Stelle, dass ein Datensatz angelegt wurde, der vervollständigt werden muss
 * Die zentrale Stelle loggt sich in PubMan ein und vervollständigt den Datensatz
 * Die zentrale Stelle gibt den Datensatz frei
 * Die Freigabe löst einen Export von PubMan zu Contens aus (es sollte auch die Möglichkeit zur Unterdrückung des Exports geben, z.B. durch Deaktivierung einer Checkbox im Eingageformular)
 * Die Freigabe löst außerdem die Benachrichigung (z.B. E-Mail oder über Contens-Messaging) an den Wissenschaftler aus, dass die Eingabe erfolgt ist und er das Ergebnis sofort (bzw. in einigen Minuten- ja nach technischer Umsetzung) in Contens prüfen kann
 * Wenn sich der Wissenschaftler die Vorschau seiner Publikationsliste anzeigen lässt, enthält sie bereits die in PubMan erfassten neuen /geänderten Objekte. Dargestellt werden diese im jurisitschen Zitierstil- unter Verwendung von Contens-Outputtypes
 * Änderungswünsche werden der zentralen Stelle gemeldet, die diese in PubMan einpflegt
 * Wiederholung des Workflows
 * Abschließendes Publizieren durch den Wissenschaftler

2. Vollständige Eingabe der Publikationsdaten durch den Wissenschafter:
 * Der Wissenschaftler meldet sich im CMS an und ruft die Seite mit seiner Publikationsliste auf
 * Auf der Publikatiosliste befinden sich zwei Objekte: ein Publikationseingabeobjekt und ein Publikationsdatenlistenobjekt
 * Der Wissenschaftler klickt das Publikationseingabeobjekt an- dies löst die Anzeige der Publikationseingabe in PubMan aus, deren "Look & Feel" dem CMS entspricht. Eine erneute Identifikation in PubMan ist nicht nötig, da die Systeme über OAuth miteinander verbunden sind
 * Der Wissenschaftler hat die Wahl zwischen "rudimentärer" und "vollständiger" Eingabe
 * Er wählt "vollständige Eingabe"
 * Er erfasst sämtlich Datenfelder und gibt den Datensatz frei
 * Die Freigabe löst einen Export des Datensatzes von PubMan zu Contens aus
 * Wenn die Vorschauseite dargestellt wird, enthält sie bereits die in PubMan erfassten neuen /geänderten Objekte. Dargestellt werden diese unter Verwendung von Contens-Outputtypes im jurisitschen Zitierstil
 * Für Änderungen muss der Wissenschaftler in PubMan zurückkehren, wenn die Änderung auch in PubMan sichtbar sein soll (Jahresbericht), wenn es nur lokal sichtbar sein soll, kann er auch lokal das Objekt ändern
 * Abschließendes Publizieren durch den Wissenschaftler

3. Vollständige Erfassung der Publikationsdaten durch eine zentrale Stelle (nur im Ausnahmefall!):
 * Die zentrale Stelle erhält die Information über eine neue Publikation außerhalb von Contens oder PubMan (als Ausdruck, per E-Mail etc.)
 * Die zentrale Stelle loggt sich in PubMan ein
 * Die zentrale Stelle erfasst sämtliche Datenfelder und gibt den Datensatz frei
 * Die Freigabe erzeugt den Export und die Benachrichtigung des Wissenschaftlers, dass er das Ergebnis in seiner Publikationsliste prüfen kann
 * Der Wissenschaftler kann in Contens die Darstellung seiner neuen Publikation prüfen
 * Änderungswünsche werden der zentralen Stelle gemeldet, die diese in PubMan einpflegt
 * Wiederholung des Workflows
 * Abschließendes Publizieren durch den Wissenschaftler

Für alle drei Workflows gilt:
 * Anforderung an "Speichern"/"Submit"-Funktion in PubMan:
 * Check bei Auslösen der Funktion:
 * wenn Erfasser und Autor identisch, dann keine Nachricht
 * wenn Erfasser und Autor nicht identisch, dann Nachricht an den/die Autor/en (E-Mail aus Benutzerkonto des Autors)
 * wenn Erfasser mit einem Autor identisch, dann Nachricht an alle anderen Autoren (E-Mail aus Benutzerkonto der anderen Autoren)
 * trotz Einsatz von OAuth ist vermutlich eine Benutzer- und Rechte/Rollen-Administration in beiden Systemen notwendig
 * lokale Änderung der Publikationsobjekte ohne Datensynchronisation soll zusätzlich möglich sein (werden beim nächsten Export aus PubMan ggf. überschrieben)

Listengenerierung (citation lists):
 * Auf Contens-Seite werden die Publikations-Objekte unter Verwendung von Outputtypes im juristischen Zitierstil auf der Mitarbeiterseite dargestellt.
 * Ab Contens 3.x ist voraussichtlich eine automatische Listengenerierung möglich. Auf Contens-Seite sollen somit künftig weitere Publikationslisten im jurisitschen Zitierstil (Verwendung Outputtypes) für Projekte oder nach Veröffentlichungsdatum erstellte werden (z.B. Liste "Neue Publikationen").

Tätigkeitsbericht (reports):
 * Aus den Objekten wird auf Contens-Seite unter Verwendung der Outputtypes und zusätzlicher Layoutangaben die Publikationsliste für den Tätigkeitsbericht erzeugt
 * entsprechend Prototyp Hamburg
 * Skripte werden für andere Teilnehmerinstitute angepasst und dokumentiert

Max-Planck-Jahrbuch (reports):
 * Für die Erzeugung der Jahrbuch-Publikationsliste werden auf PubMan-Seite direkt die in PubMan erfassten Datensätze verwendet

Upload zu SSRN (interoperability):
 * Der Upload zu SSRN wird auf PubMan-Seite generiert

Nachweis in Google / Google Scholar (interoperability):
 * Muss noch überprüft werden. Laut Bedingungen für Bibliotheken nur Zeitschriftenartikel können bei Google Scholar verlinkt werden.

--Gergana 09:06, 13 May 2009 (UTC)

=Vor- und Nachteile= --Gergana 14:06, 12 May 2009 (UTC) strukturiert nach Vergleichsanalyse.xls vom Architektur-Workshop

Bemerkung:
 * IST - Betrachtung des aktuellen Zustandes; IST H - Hambrug; IST M - München
 * SOLL - Betrachtung des gewünschten Zustands

Faktoren der Anforderungen:
 * 3 - Sehr wichtig
 * 2 - wichtig
 * 1 - Nicht ganz so wichtig

=Funktionelle Anforderungen= (mit Angaben von Personentagen/-monaten) PubMan / eSciDoc:

Annahmen

 * Für die Dateneingabe auf PubMan wird der Standard Workflow genutzt, i.e. der Eingeber (Depositor) gibt den Datensatz rudimentär und/oder komplett ein (submit). Der Moderator (zentrale Stelle oder Wissenschaftler) kann den Datensatz in seinem QA Workspace prüfen und ggf. ergänzen. Die Kommunikation zwischen Depositor und Moderator erfolgt über den Workflow bzw. die entsprechenden Workspaces (My items, QA Workspace).


 * Für den Datenaustausch mit Contens wird das Search&Export Interface (REST) genutzt (siehe die Ausführung zur Alternativ-Option mit SWORD im entsprechenden Arbeitspaket)


 * Für die Hilfefunktion pro Feld wird die aktuelle Tool-Tip Funktionalität benutzt.


 * Alle Änderungen an bibliographischen Angaben werden in PubMan gemacht. Zusätzliche Änderungen im CMS an den Contens-Objekten haben keine Auswirkung auf das publication item in PubMan. Es muss auf CMS Seite definiert werden, ob ein neuer Export von PubMan die möglichen Änderungen am CMS Objekt überschreibt oder nicht.
 * --Gergana 09:18, 13 May 2009 (UTC) Es muss definiert werden, ob nur die "neuen" Objekte in CMS hinzugefüt werden oder ob alle Objekte überschrieben werden. Kennzeichnung der Objekte als neu bzw. Timestamp für die Selektion der "neuen" Objekte nutzen.
 * --Hmartens 06:22, 14 May 2009 (UTC) Zu jedem Datensatz in PubMan gibt es eine Schaltfläche welche es erlaubt, zu jeder Zeit einzelne Datensätze nach Contens zu übertragen. Änderungen an Datensätzen in PubMan und anschließende Übertragung nach Contens ändern die Objekte in Contens.
 * Rechte und Privilegien für PubMan Ressourcen werden in PubMan/eSciDoc definiert. Contens CMS Privilegien werden nicht in PubMan/escidoc abgebildet.


 * Nur jene Datensätze, die in PubMan freigeschalten wurden (i.e. released), können exportiert werden. Der Publishing Prozess auf seiten Contens kann unabhängig vom PubMan Release Prozess gestaltet werden.
 * --Gergana 09:21, 13 May 2009 (UTC) Auf Seite von Contents gibt es keinen Publishing Prozess, der Eintrag wird nur von ZS überprüft. Dies wird jetzt auf Seite von PubMan erfolgen.
 * --Natasa 07:37, 15 May 2009 (UTC) In this case the Publishing process is the "ZS Überprüfung" point, is that correct?
 * --Hmartens 06:22, 14 May 2009 (UTC) Anmerkung: Sobald ein Datensatz von PubMan nach Contens übertragen wurde, ist dieser als Objekt im CMS verfügbar. Auf der Mitarbeiterseite in Contens wird er durch die Listengenerierung in der Edit-Ansicht automatisch angezeigt. Diese Mitarbeiterseite muss jetzt in Contens neu publiziert werden.
 * Das Jahrbuch der MPG wird bis 2011 über eDoc generiert: Die Daten werden in PubMan selektiert und nach eDoc exportiert. Der eigentliche Jahrbuch-Workflow passiert auf eDoc.

Arbeitspakete

 * Definition von neuen Publikationstypen plus deren Metadata, basierend auf dem eSciDoc Application Profile for publication items, i.e. Erweiterung des aktuellen eSciDoc Application Profiles
 * Aufwand PubMan: 1,5 PM (Personenmonate)


 * Definition von Validierungsregeln, i.e. Erweiterung der aktuellen Validierungsregeln pro Validierungspunkt (Eingabe/Submit und Freischaltung/Release)
 * Aufwand PubMan: 1 PM


 * Definition der Modification Workflows auf PubMan (abhängig von den verschiedenen Szenarien der Modifikation durch zentrale Stelle und/oder Wissenschaftler). Falls die aktuellen Workflows nicht ausreichen, müssen auf seiten PubMan Erweiterungen in der Kombination des Standard und Simple Modification Workflows gemacht werden.
 * Aufwand PubMan für Definition und Erweiterung: 1,5 PM


 * Eingabehilfe für Personen - Import Person data (Namen, Organisation,etc) in CoNe Datenbank
 * Aufwand PubMan: 5 PT (Personentage), falls die Daten strukturiert vorliegen
 * Aufwand PubMan: mind.1 PM (Personenmonat) falls die Daten händisch in CoNe eingetragen werden müssen (abhängig von Anzahl der Daten)


 * Definition von Hilfetexte pro Feld und /oder Dokumenttyp (in Englisch und Deutsch)
 * Aufwand lokale Experten: ca. 15 PT (hängt ab von Anzahl der Felder, die Hilfetext brauchen)
 * Aufwand PubMan: 5 PT für Generierung der spezifischen Ressource Bundles für die spezifischen Hilfetexte


 * Evaluierung von SSRN Schnittstellen, Authentifizierungsmöglichkeiten, Formate und Workflow
 * Aufwand PubMan: unklar (Informationen zu verfügbaren Schnittstellen, Formaten, Authentifizierungsmöglichkeiten sind bei SSRN angefragt)


 * Evaluation of OAuth, Shibboleth oder andere Single-Sign-on Technologien und Authorisierungsmöglichkeiten
 * Aufwand PubMan: 2-3 PM für Implementierung der erweiterten AA Komponente (abhängig von Ergebnis der Evaluierung)


 * "Look&feel CMS" während der Eingabe auf PubMan - Skin-Definition und Implementierung
 * Aufwand PubMan: 1 PM


 * Preview in Contens für neu eingegebenes PubMan item:
 * Option a): Pubman liefert reines XML (Metadata) ohne Zitierstil. Die Transformation in den gewünschten Zitierstil passiert auf Contens Seite
 * Aufwand Contens: unklar
 * Option b): Pubman liefert XML, angereichert mit einem Snippet, das den Zitierstil beinhaltet
 * Aufwand PubMan: unklar, ca. 15 PT für Definition und Implementierung per Style (Aufwand abhängig von Anzahl und Komplexität)
 * Aufwand Contens: ca. 1-2 PT (?) für Anpassung der Snippet Classes an den gewünschten HTML Output


 * Export nach Contens nach Freigabe auf PubMan
 * Version 1: Pushing Mechanismus, i.e. direkter Export von einzelnen Items (Anmerkung: Sollte die direkte Push-Funktionalität umgesetzt werden, werden auf PubMan nur Standard-Interfaces eingesetzt, um die Nachnutzung für andere Institutionen zu ermöglichen)
 * Aufwand PubMan: 1 PM für Implementierung des Standard-Push Client (e.g. SWORD Client), inkl. notwendiger Authorisation
 * Aufwand Contens: unklar, für Implementierung eines Standard-Server Interface (e.g. SWORD Server), inkl. notwendiger Authorisation
 * --Hmartens 06:41, 14 May 2009 (UTC) Standard-Interfaces, ein "einfacher" XML-Export ist ausreichend. Die Contens-Implementierung wird dadurch sicherlich wesentlich einfacher. Nachnutzungseffekt SWORD-Client nice to have, Aufwand Contens SWORD-Client: unklar.
 * --Natasa 07:27, 15 May 2009 (UTC) Siehe unten, Version 2
 * Version 2: Alternative zu Direkter Export über Pushing ist der Einsatz von Search&Export Interface: Auf seiten Contens wird ein Import angestossen (e.g. zweimal am Tag). Keine zusätzliche Authorisierung notwendig, da auf seiten PubMan das Search&Export Interface plus die Daten öffentlich sind, in Contens wird das Anlegen neuer Objekte über die vorhandene Authorisierungsfunktionlität geregelt.
 * Aufwand PubMan: 1 PT für Definition notwendiger Queries/Abfragen
 * Aufwand Contens: unklar
 * Optionale Zusatzfunktion bei Version 2: Zusätzlich kann auf Contens Seite eine Funktionlität eingebaut werden, womit der Nutzer explizit ein "refresh my page" anstossen kann. Nachteil: zusätzlicher Nutzer-Aktion, zusätzliche Definition von Abfragen für jeden einzelnen Nutzer nötig
 * Aufwand PubMan: 1 PT max. für Bereitstellung von Template Queries
 * Aufwand Contens: unklar


 * Unterdrückung von Export nach Contens:
 * kein Aufwand, kann durch den Nutzer über eine entsprechende Angabe in den Local Tags des PubMan items vorbereitet werden. Die Abfrage über Search&export kann diese Local tags beinhalten/ausschliessen.


 * Benachrichtigung des Autors nach Submit oder Freigabe des Datensatzes
 * Vorbereitung und Maintenance: Nachdem der Depositor eventuell unterschiedlich von den Autoren ist, brauchen wir für eine Benachrichtigung die email Accounts eines jeden Autors in den Person data in Cone, die auch gepflegt und aktualisiert werden müssen. Aufwand PubMan: Definition/Implementierung einer sicheren Nutzeroberfläche, wo ein Nutzer seine Person data aktualisieren/ändern kann. Zur Zeit haben dieses Privileg nur Moderatoren (i.e. meist Bibliothekare), ausserdem sind Person data noch öffentlich.
 * Aufwand PubMan: 1PM
 * Für die eigentliche Umsetzung der Benachrichtigung gibt es mehrere Möglichkeiten
 * Option a) (empfohlen): RSS feed für den Autor (Jeder Autor kann eine Suche nach seinen last released items über RSS liefern lassen, sofern er einen Feed Reader installiert hat.
 * Aufwand PubMan: 2PT für Erweiterung des Syndication Managers für beliebige Suchen
 * Option b): E-Mail Versand an bestimmten Punkten des Workflows, basierend auf verfügbaren Mail Accounts (e.g. in CoNe und/oder User preferences von user handles => Shibboleth)
 * Aufwand PubMan: 15PT

Contens

 * Entwicklung Import-Schnittstelle, die die von PubMan gelieferte XML-Datei (einzelne items und alle items der affiliation als Liste) verarbeiten kann
 * Spezifikation Verarbeitung: Parsing in Contens-konformes Format; Ablage in der Contens-Datenbank als Objekt

=Fragen= zu OAuth:
 * Was genau wird über OAuth ausgetauscht?
 * siehe OAuth Protocol Workflow
 * wäre Teil des Arbeitspaketes Evaluierung von OAuth
 * Erfüllt das Protokoll die Sicherheitsanforderungen der Admins (vgl. Link)?
 * Ermöglichen die übermittelten Zugriffsrechte ein uneingeschränktes Arbeiten in beiden Systemen? Oder stößt der Nutzer immer wieder auf „No Access“-Meldungen, die er nicht erhalten würde, wenn er „richtig“ angemeldet wäre?
 * OAuth übernimmt keinerlei Verwaltungsoperationen (neue User anlegen, User löschen, Rechte ändern etc.), oder ?
 * Das bedeutet, dass auch der Einsatz von OAuth den generellen Nachteil der doppelten Benutzerverwaltung nicht aufhebt. Es bedeutet aber eine Steigerung der Benutzerfreundlichkeit.

zum Objektmodell in Contens:
 * was sind im Detail die Vorteile eines speziellen Objektmodells (relationales Objektmodell)?
 * nur die erhöhte Performaz bei Listengenerierungen? Gibt es weitere Vorteile?
 * Nachteil eines speziellen Objektmodells: zusätzliche Projektaufgabe "Migration der alten Contens-Publikations-Objekte zum neuen Objektmodell"
 * Oder kann Contens mit einer Mischform umgehen?

=Ergänzungen= Datenbank-Kopie Da der wichtigste Schwachpunkt dieses Modells die fehlende Autonomie ist, kam relativ schnell der Gedanke auf, eine zusätzliche Datenbank / Datenbankmodell zu schaffen. Die Aufstellung der Vor- und Nachteile ist jetzt erst einmal ein Schnellschuss. Vielleicht muss hierüber tatsächlich der Lenkungsausschuss intensiv beraten werden, denn dort ist die Autonomiebestrebung wahrscheinlich am Stärksten. Nachteile Vorteile
 * Eine zusätzliches Datenbankmodell muss designed werden
 * Diese Datenbank muss erstellt und entsprechende Exportmechanismen geschaffen werden
 * Inwieweit hier SWORD eine echte Hilfe sein kann, ist noch unklar
 * Diese Datenbank muss auch später gepflegt werden (neue Felder)

--Heiner 18 May 2009 --Heiner Ende --Heiner 18 May 2009 --Heiner Ende
 * Die Pflege neuer Felder ist voraussichtlich in einer eigenen Datenbank leichter als in der Contensdatenbank
 * Eine externe Datenbank kann "nach Contens" oder auch leicht von anderen Instituten genützt werden
 * Die relationale Datenbank kann vom Redaktionsserver genützt werden (s.o. Contens Objektmodell)
 * Die DB kann direkt vom Webserver genützt werden
 * dadurch ziemliche Unabhängigkeit von MPDL (Services), GWDG (Speicherung*Standard SQL - dadurch leichtes Outsourcing
 * Standard SQL - Administratoren oder eigene Programmierer können damit leichter umgehen
 * Schnelle Reaktionen auf Wünsche der Direktoren (wichtig für GE) - ggf. können benötigte zusätzliche Felder in PubMan nachgepflegt werden
 * Temporäre Aufgaben bzw. sogar Tests können leichter gemacht werden.
 * Falls am Standort des Webservers eine eigene DB gehalten wird, was leicht möglich ist:
 * Unabhängigkeit auch vom Redaktionsserver
 * deutlich höhere Performance (bei dynamischen Sites)

Datenbank-Kopie Kommentar Hamburg
 * aus Hamburger Sicht ist es ausreichend, wenn in dem bereits in der Contens Installation vorhandenen DMS auf dem Redaktionsserver eine Zusatz-Datenbank pro Institut eingerichtet wird, die Metadaten und Volltexte aufnehmen kann
 * eine weitere externe Datenbank ist unter dem Aspekt der Datensicherheit aus Hamburger Sicht NICHT notwendig
 * Eine eigene zusätzliche DB pro Institut innerhalb des vorhandenen DMS ist z.B. künftige Versionswechsel wünschenswert, da diese dann auch unabhängig voneinander vollzogen werden können

Datenbank-Kopie Kommentar München --Gergana 07:03, 18 May 2009 (UTC)
 * Einaml importierte Daten von PubMan in CMS bleiben in der Datenbank von CMS erhalten. Somit ist eine Abhängigkeit nur beim Importieren neuer Einträge von PubMan nach CMS gegeben.
 * Wofür genau ist diese Datenbank gedacht?
 * für Autonomie ? (Einmal importierte Daten liegen bereits im CMS). In diesem Fall muss die Synchronisation bedacht werden.
 * Veränderte Items in CMS sollen auch in PubMan verändert werden.
 * Veränderte Items in PubMan sollen die gleichen in CMS überschreiben.
 * für Backup ? Synchronisation nur evtl. mit PubMan oder mit CMS, oder beides? Welche ist hier die primäre Datenquelle?

Datenbank-Kopie - mögliche Lösungen --Gergana 12:50, 18 May 2009 (UTC) nach Absprache mit Frau Bulatovic
 * DB1. Kopie der Cache-DB vom PubMan (Aufwand 1 PT):
 * hält nur die letzte Version der Daten vom PubMan (aber keine Versionierung der Items)
 * hat die gleiche Architektur wie die Cache-Datenbank (Vorteil: Datenbank muss nicht neu designt werden)
 * ist eine redundante Kopie
 * enthält alle Daten vom PubMan (Nachteil: Daten, die CMS nicht braucht)


 * DB2. Auszug aus der Cache-DB vom PubMan (Aufwand 10 PT):
 * täglicher Export der neuesten Einträge vom Pubman (aber keine Versionierung der Items)
 * hat die gleiche Architektur wie die Cache-Datenbank (Vorteil: Datenbank muss nicht neu designt werden)
 * enthält nur auf CMS zugeschnittene Daten
 * Ein Filtermechanismus für die CMS-relevante Daten muss vorbereitet werden


 * DB3. Einrichtung eigener Datenbank (Aufwand ? unsicher):
 * Datenbank muss designt werden
 * ein Exportmechanismus von PubMan nach DB muss vorbereitet werden (Synchronisation)
 * Veränderungen in der Architektur der Daten in PubMan (müssen) in die neue Datenbank nachgebildet werden
 * Es werden parallel 3 Systeme zur Datenhaltung verwaltet (PubMan, CMS und lokale Datenbank). Diese Variante bringt mehr Aufwand für Pflege und Synchronisation aller Systeme als Erleichterung.

=Zugehörige Seiten= JusCMS_Architecture_Feasibility_Study_Concept_2.3 JusCMS_Architecture_Feasibility_Study_Concept_1.6.1