Anpassung am Expose + Versand V3
This commit is contained in:
marcodn
parent
e038b6b781
commit
f1e67c7514
3 changed files with 75 additions and 59 deletions
|
|
@ -1,41 +1,36 @@
|
|||
|
||||
\chapter{Expose}
|
||||
\label{ch:intro}
|
||||
|
||||
\section{Ausgangslage}
|
||||
|
||||
Die Editions- und Forschungsstelle Frank Wedekind (EFFW) wurde 1987 in der Hochschule Darmstadt gegründet. Ihr Intention
|
||||
ist es, den lange vernachlässigten Autor der europäischen Moderne in die öffentliche Aufmerksamkeit zu bringen. Die
|
||||
Publikation der >>Kritischen Studienausgabe der Werke Frank Wedekinds. Darmstädter Ausgabe<< im Verlag Jürgen Häuser
|
||||
wurde 1994 direkt nach der Erschließung der Wedekind-Nachlässe in Aarau, Lenzburg und München begonnen und im Jahre
|
||||
2013 abgeschlossen (8 Bände in 15 Teilbänden, jetzt in Wallstein Verlag). Die EFFW ist im Sommer 2015 an die
|
||||
Johannes Gutenberg-Universität Mainz umgezogen.
|
||||
Publikation der >>Kritischen Studienausgabe der Werke Frank Wedekinds. Darmstädter Ausgabe<<
|
||||
wurde direkt nach der Erschließung der Wedekind-Nachlässe in Aarau, Lenzburg und München begonnen und im Jahre
|
||||
2013 abgeschlossen.
|
||||
|
||||
Da Frank Wedekind heute zu einen der bahnbrechenden Autoren der literarischen Moderne zählt, aber bisher sehr
|
||||
Da der 1864 geborene Frank Wedekind heute zu einen der bahnbrechenden Autoren der literarischen Moderne zählt, aber bisher sehr
|
||||
wenig erforscht wurde, soll sich dies nun Ändern. Die nationalen und internationalen Korrespondenzen von und an Wedekind
|
||||
zeigen eine starke Vernetzung in der europäischen Avantgarde. Dies zeigt das die Wissenschaft um die Korrespondenzen
|
||||
von Wedekind eine immer größere Rolle spielen. Aktuell sind lediglich 710 der 3200 bekannten Korrespondenzstücke
|
||||
zeigen eine starke Vernetzung in der europäischen Avantgarde. Aktuell sind lediglich 710 der 3200 bekannten Korrespondenzstücke
|
||||
veröffentlicht worden.
|
||||
|
||||
Diese
|
||||
beinhalteten substantiell das literarhistorische und kulturgeschichtliche Wissen über die Kultur zwischen 1880 und 1918,
|
||||
indem das überlieferte Material zum einen transkribiert editiert und zum anderen editionswissenschaftlich kommentiert wurde.
|
||||
Inhaltlich erschlossen zusätzliche Kommentare den historischen Kontext.
|
||||
|
||||
Um jenes zu verändern entstand das Projekt >>Edition der Korrespondenz Frank Wedekind als Online-Volltextdatenbank<<
|
||||
\citep{EffwFrankWedekind}, welches bei der EFFW angesiedelt ist und als Kooperationsprojekt an der Johannes
|
||||
Gu\-ten\-berg-Universität Mainz, der Hochschule Darmstadt und der Fernuni Hagen umgesetzt und durch die Deutsch
|
||||
Forschungsgemeinschaft (Bonn) gefördert wird.
|
||||
|
||||
Hierbei wurden sämtliche bislang bekannten Korrespondenzen in die On\-line-Edi\-ti\-on überführt. Diese
|
||||
beinhalteten substantiell das literarhistorische und kulturgeschichtliche Wissen über die Kultur zwischen 1880 und 1918,
|
||||
indem das überlieferte Material zum einen transkribiert editiert und zum anderen editionswissenschaftlich kommentiert wurde.
|
||||
Inhaltlich erschlossen zusätzliche Kommentare den historischen Kontext.
|
||||
Das entstandene Pilotprojekt ist eine webbasiert Anwendung, die aktuell unter \url{http://briefedition.wedekind.h-da.de}
|
||||
eingesehen werden kann. Hierbei wurden sämtliche bislang bekannte Korrespondenzen in dem System digitalisiert. Die
|
||||
Briefe selbst werden im etablierten TEI-Format gespeichert und über einen WYSIWYG-Editor von den Editoren und
|
||||
Editorinnen eingegeben.
|
||||
|
||||
Hierfür entstand das Pilotprojekt der Online-Volltextdatenbank für Briefe von und an Frank Wedekind, welches 2015
|
||||
als Beta-Version freigeschalten wurde. Dieses Projekt kann aktuell unter http://briefedition.wedekind.h-da.de eingesehen
|
||||
werden.
|
||||
|
||||
Die benutzerfreundliche Erfassung und Annotation der Briefe, ist eines der Hauptziele der konzeptionierten technischen
|
||||
Architektur. Aus diesem Grund, wurde die Präsentation-, Recherche- und Erstellungsebene vollständig webbasiert umgesetzt.
|
||||
Die Briefe selbst, sind im etablierten TEI-Format gespeichert. Dies muss von den Editoren und Editorinnen nicht
|
||||
selbst eingepflegt werden, sondern kann über einen entstanden WYSIWYG-Editor direkt eingegeben werden, welcher dies bei
|
||||
der Speicherung in das TEI-Format umwandelt. Ebenfalls wurde hierbei auf eine modulare und unabhängige Architektur
|
||||
geachtet, wodurch die Komponenten im Nachgang auch von anderen Briefeditionen genutzt werden können.
|
||||
Das Projekte wurde anhand von bekannten und etablierten Entwurfsmustern umgesetzt um eine modulare und unabhängige
|
||||
Architektur zu gewährleisten, damit dies für weitere digitale Briefeditionen genutzt werden kann.
|
||||
|
||||
\section{Ziel}
|
||||
|
||||
|
|
@ -50,6 +45,61 @@ Hierbei ist auch ein Vergleich mit anderen Technologien angedacht.
|
|||
|
||||
\section{Aktueller Forschungsstand}
|
||||
|
||||
Da die Anwendung als Webseite umgesetzt ist, ist der zugehörige Client für den Benutzer ein Webbrowser. Dies bedeutet,
|
||||
das jeder Wechsel einer Seite oder eine Suchanfrage als Web-Request an den Server geschickt wird. Solch ein Web-Request
|
||||
geht durch mehrere Schichten des Server-System bis die Antwort an den Client zurückgesendet wird, wie in
|
||||
\ref{fig:webrequest} dargestellt.
|
||||
Angefangen bei der Anfrage die über den Webbrowser an den Server gestellt wird und vom \textit{Glassfish}-Server
|
||||
empfangen wird. In diesem wird anhand des definierten Routing entschieden, an welche \textit{Java Server Page} die
|
||||
Anfrage weitergeleitet und verarbeitet wird. In dieser wird die Darstellung der Webseite geladen und die Anfragen für
|
||||
den darzustellenden Datenbestand abgeschickt.
|
||||
Die Datenanfragen werden über die \textit{Enterprise Java Beans} an die \textit{Java Persistance API} weitergeleitet.
|
||||
Hier wird nun geprüft, ob die Daten aus dem \textit{OpenJPA Cache} direkt ermittelt werden können, oder ob die Abfrage
|
||||
an das unterlagerte Datenbankmanagementsystem \textit{PostgreSQL} weitergeleitet werden muss. Die ermittelten Daten vom
|
||||
DBMS werden bei Bedarf im \textit{OpenJPA Cache} aktualisiert.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\begin{tikzpicture}[node distance=5em,
|
||||
block/.style={rectangle, rounded corners,minimum width=3cm,minimum height=1cm,text centered, draw=black,fill=green!30},
|
||||
lineArrow/.style={arrows={-Latex[length=5pt 3 0]}},
|
||||
every fit/.style={inner sep=1em,draw}
|
||||
]
|
||||
%https://docs.oracle.com/javaee/6/tutorial/doc/bnacj.html
|
||||
\node (browser) [block] {WebBrowser};
|
||||
\node (fitClient) [fit=(browser)] {};
|
||||
\node [left] at (fitClient.west) {Client};
|
||||
|
||||
\node (JSP) [block,below of=browser,node distance=7em] {Java Server Pages};
|
||||
\node (EJB) [block,below of=JSP] {Enterprise Java Beans};
|
||||
\node (JPA) [block,below of=EJB] {Java Persistance API};
|
||||
\node (openJPA) [block, below of=JPA] {OpenJPA Cache};
|
||||
\node (fitGlassfish) [fit=(JSP) (EJB) (JPA) (openJPA)] {};
|
||||
\node [left] at (fitGlassfish.west) {Glassfish};
|
||||
|
||||
\node (database) [block, below of=openJPA] {Database};
|
||||
\node (fitPostgreSQL) [fit=(database)] {};
|
||||
\node [left] at (fitPostgreSQL.west) {PostgreSQL};
|
||||
|
||||
\node (fitServer) [fit=(fitGlassfish) (fitPostgreSQL),inner xsep=5em] {};
|
||||
\node [left] at (fitServer.west) {Server};
|
||||
|
||||
\draw[lineArrow] (browser)--(JSP);
|
||||
\draw[lineArrow] (JSP)--(EJB);
|
||||
\draw[lineArrow] (EJB)--(JPA);
|
||||
\draw[lineArrow] (JPA)--(openJPA);
|
||||
\draw[lineArrow] (openJPA)--(database);
|
||||
|
||||
\end{tikzpicture}
|
||||
\caption{Ablauf einer Web-Anfrage}
|
||||
\label{fig:webrequest}
|
||||
\end{figure}
|
||||
|
||||
Für eine Optimierung werden die Schichten einzeln betrachtet. Ein sinnvolles Vorgehen ist hierbei von
|
||||
unten nach oben vorzugehen. Dies bedeutet man beginnt mit dem Datenbankmanagementsystem, was in diesem Fall ein
|
||||
PostgreSQL-Server ist.
|
||||
|
||||
\subsection{PostgreSQL}
|
||||
|
||||
Die Speicherverwaltung des PostgreSQL-Servers muss für Produktivsysteme angepasst werden \citep[34-38]{Eisentraut2013}.
|
||||
Hierunter fallen die \textit{shared\_buffers} die bei ca. 10 bis 25 Prozent des verfügbaren Arbeitsspeichers liegen
|
||||
sollten. Mit dieser Einstellung wird das häufige Schreiben des Buffers durch Änderungen von Daten und Indexen auf die
|
||||
|
|
@ -103,6 +153,8 @@ Des Weiteren können über das Modul \texttt{pg\_stat\_statements} Statistiken d
|
|||
wurden, ermittelt werden \citep{PostgresF27:2023}. Hierbei können die am häufigsten Aufgerufenen und die Anfragen mit
|
||||
der längsten Ausführungszeit ermittelt werden.
|
||||
|
||||
\subsection{Glassfish}
|
||||
|
||||
% MÜllerWehr2012
|
||||
Die \textit{Java Persistence API (JPA)} wird als First-Level-Cache in Java-EE-An\-wen\-dung verwendet, hier nehmen die
|
||||
Objekte einen von vier Zuständen ein \citep[57]{MüllerWehr2012}. Im Zustand \textit{Transient} sind die Objekt erzeugt,
|
||||
|
|
@ -163,42 +215,6 @@ hierbei wird die Übertragung über das Netzwerk außer acht gelassen, da diese
|
|||
Anwendung abhängt. Ein geplantes Vorgehen ist hierbei die Überprüfung von >>unten nach oben<<,
|
||||
wie in \ref{fig:webrequest} dargestellt.
|
||||
|
||||
\begin{figure}
|
||||
\begin{tikzpicture}[node distance=5em,
|
||||
block/.style={rectangle, rounded corners,minimum width=3cm,minimum height=1cm,text centered, draw=black,fill=green!30},
|
||||
lineArrow/.style={arrows={-Latex[length=5pt 3 0]}},
|
||||
every fit/.style={inner sep=1em,draw}
|
||||
]
|
||||
%https://docs.oracle.com/javaee/6/tutorial/doc/bnacj.html
|
||||
\node (browser) [block] {WebBrowser};
|
||||
\node (fitClient) [fit=(browser)] {};
|
||||
\node [left] at (fitClient.west) {Client};
|
||||
|
||||
\node (JSP) [block,below of=browser,node distance=7em] {Java Server Pages};
|
||||
\node (EJB) [block,below of=JSP] {Enterprise Java Beans};
|
||||
\node (JPA) [block,below of=EJB] {Java Persistance API};
|
||||
\node (openJPA) [block, below of=JPA] {OpenJPA Cache};
|
||||
\node (fitGlassfish) [fit=(JSP) (EJB) (JPA) (openJPA)] {};
|
||||
\node [left] at (fitGlassfish.west) {Glassfish};
|
||||
|
||||
\node (database) [block, below of=openJPA] {Database};
|
||||
\node (fitPostgreSQL) [fit=(database)] {};
|
||||
\node [left] at (fitPostgreSQL.west) {PostgreSQL};
|
||||
|
||||
\node (fitServer) [fit=(fitGlassfish) (fitPostgreSQL),inner xsep=5em] {};
|
||||
\node [left] at (fitServer.west) {Server};
|
||||
|
||||
\draw[lineArrow] (browser)--(JSP);
|
||||
\draw[lineArrow] (JSP)--(EJB);
|
||||
\draw[lineArrow] (EJB)--(JPA);
|
||||
\draw[lineArrow] (JPA)--(openJPA);
|
||||
\draw[lineArrow] (openJPA)--(database);
|
||||
|
||||
\end{tikzpicture}
|
||||
\caption{Ablauf einer Web-Anfrage}
|
||||
\label{fig:webrequest}
|
||||
\end{figure}
|
||||
|
||||
Zuerst soll der Aufruf gegen die Datenbank geprüft und die Ausführungszeit sowie die Abfragepläne ermittelt und
|
||||
analysiert. Wenn sich hierbei größere Defizite erkennen lassen, werden die Abfragen direkt optimiert, indem der Aufbau
|
||||
der Abfrage, die Abfragekriterien und die Verwendung der Indexe betrachtet und in Frage gestellt werden.
|
||||
|
|
|
|||
BIN
expose.pdf
BIN
expose.pdf
Binary file not shown.
|
|
@ -19,7 +19,7 @@
|
|||
\newcommand{\myId}{8335710\xspace}
|
||||
\newcommand{\myProf}{Prof. Dr. Uta St\"orl\xspace}
|
||||
\newcommand{\referent}{Referentin\xspace}% Referentin/Referent, depending on the gender of your prof
|
||||
\newcommand{\mySupervisor}{Sebastian Bruchhaus\xspace}
|
||||
\newcommand{\mySupervisor}{Sebastian Bruchhaus, Tobias Holstein\xspace}
|
||||
\newcommand{\supervisor}{Betreuer\xspace}% Betreuerin/Betreuer, depending on the gender of your supervisor
|
||||
\newcommand{\myFaculty}{Fakult\"at f\"ur Mathematik und Informatik\xspace}
|
||||
\newcommand{\myUni}{FernUniversit\"at in Hagen\xspace}
|
||||
|
|
|
|||
Loading…
Reference in a new issue