This repository was archived by the owner on Dec 10, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathmethodik.tex
More file actions
207 lines (204 loc) · 14 KB
/
methodik.tex
File metadata and controls
207 lines (204 loc) · 14 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
\chapter{Methodik}
\section{Vergleich von Web-Frontend Sprachen}
Es gibt eine Vielzahl von möglichen Programmiersprachen zur Erstellung von
Web-Frontends. Zu Beginn des Projektes wurden daher verschiedene Sprachen
evaluiert. Nachfolgend die Ergebnisse unserer Betrachtungen.
\subsection{Javascript}
Nach dem ersten Erscheinen am 4. Dezember
1995\footnote{https://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrelease67.html}
entwickelte sich \ac{JS} neben \ac{HTML} und \ac{CSS} schnell zu einer der Kern
Technologien des Web.\\
Die Syntax von \ac{JS} basiert, genau wie etwa C oder
Java, auf geschweiften Klammern. Es werden diverse Paradigma wie Funktionale und
Objekt Orientierte Programmierung unterstützt. \acl{JS} liefert eine umfangreiche
Standardbibliothek mit einer einer Vielzahl von
\ac{API}s zum Manipulieren eines \ac{DOM}s. Die Sprache ist
dynamisch\footnote{https://en.wikipedia.org/wiki/Type\_system\#Combining\_static\_and\_dynamic\_type\_checking}
typisiert.
\subsection{\acl{TS}}
\ac{TS} ist ein von Microsoft entwickeltes Superset von
\acl{JS}\footnote{https://www.typescriptlang.org}. Es erweitert \ac{JS} um eine
optional verwendbare strikte Typisierung, die beim Übersetzen zu \ac{JS}
überprüft wird. Dies hat zwei Vorteile gegenüber einer dynamischen Sprache wie
beispielsweise \acl{JS}\footnote{https://pchiusano.github.io/2016-09-15/static-vs-dynamic.html}:
% TODO Find studies
\begin{description}
\item[Entdecken von Fehlern zur Kompilierzeit]{Viele semantische Fehler werden
während des Kompilierens erkannt. Hierzu gehören Fehler wie das Übergeben
von Parametern eines falschen Typs in eine Funktion oder das aufrufen einer
Funktion, die nicht existiert}
\item[Bessere Lesbarkeit]{Statisch typisierter Quellcode ist für den
Programmierer einfacher lesbar, da Typen von Parametern und Variablen
direkt ersichtlich sind und nichts aus dem Name oder dem Kontext
herausgefunden werden müssen}
\item[Bessere Editor Untersützung]{Dadurch, dass Typinformationen zur
Kompilierzeit zur Verfügung stehen, kann der Editor dem Programmierer eine
bessere Autovervollständigung bieten}
\end{description}
Ein Nachteil von \acl{TS} ist die Tatsache, dass Typinformationen von externen
Softwarebibliotheken für die vollständige Überprüfung des Typsystems
vorhanden sein müssen. Ein Großteil von \ac{JS} Bibliotheken wird ohne diese
Informationen geliefert, weshalb für diese Typinformationen von der Community
verwendet werden, die nicht zwingend auf dem gleichen Entwicklungsstand wie die
Bibliotheken sind. Dies kann zu ``false-positives'' in der Überprüfung der Typen
führen.\\
% TODO flesh this out
Da die Vorteile von statischer Typisierung den Nachteilen überwiegen, wurde
entschieden, \acl{TS} als Frontend-Sprache zu verwenden.
\section{Vergleich von Frontend-Frameworks}
Eines der Ziele von Chromstahl ist es, schnell auf Anforderungen reagieren zu
können. Somit stand bei der Entwicklung des Frontends die Auswahl eines
Frontend-Frameworks an, mit dem langfristig die Ziele des Projektes gesichert
werden können. Folgende Abwägungen wurden getroffen.
\subsection{JQuery}
JQuery, 2006 kreiert, ist eine JavaScript Bibliothek hauptsächlich für das
Durchlaufen und Verändern des \ac{DOM}s.\footnote{https://jquery.com} Sie
verbreitete sich schnell und ist zu einer der wichtigsten Bibliotheken im
Web-Frontend geworden. Eine Studie von W3Techs aus dem Jahre 2017\footnote{https://w3techs.com/technologies/overview/javascript\_library/all} bezeichnete
JQuery als die am meisten verwendete Bibliothek im Web bei einem Vorsprung von
55.1 Prozentpunken auf den zweiten Platz, der CSS Bibliothek Bootstrap\footnote{https://getbootstrap.com/}.\\
Die Kern Funktionen, inbesondere die \ac{DOM} \ac{API}, sind heute in allen Standardbibliotheken von
modernen Browsern sehr ähnlich implementiert zu finden.
\subsection{Vue.js}
Vue.js wird seit 2013 von Evan You entwicklet.\footnote{https://vuejs.org} Es
ist unter dem Gesichtspunkt, das Entwicklen von \acl{SPA} zu vereinfachen, ins
Leben gerufen worden. Im Gegensatz zu JQuery interagiert der Programmierer nicht
direkt mit dem \ac{DOM}. Vielmehr bietet Vue.js eine \ac{VDOM} Implementation
und ermöglicht Wiederverwendbarkeit von Code durch das Konzept von Komponenten.
Ein Router, der eine Navigation durch die Anwendungen ohne Aktualisierungen der
gesamten Seite ermöglicht, rundet das Framework für die Erstellung von \acl{SPA}s ab.
\subsection{Eigene Implementation}
Eine weitere Überlegung zu Beginn des Projektes war es, eine eigene Lösung für
ein \ac{SPA} Framework zu schreiben. Dies würde folgende Vorteile liefern:
% TODO: Add more reasons
\begin{description}
\item [Typsicherheit]{Durch die Entscheidung \acl{TS} als Frontend-Sprache zu
verwenden, würde auch das eigene Frontend-Framework vollständig in \acl{TS}
entwickelt werdem. Dies bietet eine vollständige Typsicherheit im Framework.
Hierduch wird der in der Erläuterung von \acl{TS} aufgeführte Nachteil über
das Fehlen von Typinformationen in Drittanbieter Frameworks gelöst}
\item[Keine Abhängigkeit zu Drittanbieter Bibliotheken]{Die Verwendung eines
bestehenden Frameworks bildet eine gewisse Abhängigkeit zu den Entwicklern
desselben. Wird im Laufe der Entwicklung klar, dass eine gewisse Funktion
nicht gegeben ist, führt dies entweder zu arbeitsintensiven Umbauten oder
der Eröffnung eines Feature Requests mit einer entsprechenden Wartezeit. Bei
einer eigenen Lösung lassen sich gewünschte Funktionen direkt in das Framework einbauen}
\end{description}
Unter Berücksichtigung der genannten Punkte wurde entschieden, eine eigene
Implementation zu enwickeln. Diese trägt den Namen ``eisen'' und ist ebenfalls
Open Source unter der Apache Lizenz verfügbar.\footnote{https://github.com/kloudsoftware/eisen}
\section{Vergleich von Web-Backend Sprachen}
Analog zum Frontend stehen auch im Backend verschiedene Sprachen zur
Implementierung zur Verfügung. Ebenfalls wurde auf eine langfrisitge Verwendung
einer Technolgie geachtet, um spätere arbeitsaufwendige Umentscheidungen zu verhindern.
\subsection{\acl{TS}}
\acl{TS} erlangt mehr und mehr Aufmerksamkeit als Śprache fürs Web-Backend. Die
Technologie nennt sich Node.js\footnote{https://nodejs.org/en/}. Hierbei wird
die Laufzeitumgebung, die sich normalerweise im Browser befindet, auf den Server
verlagert und die \ac{API} um Funktionen wie beispielsweise Zugriff auf das
Dateisystem erweitert. Auf dieser Umgebung kann \ac{JS} und \ac{JS} verwendet
werden, wodurch die gesamte Applikation in einer Sprache abgebildet werden kann.
Desweitern bietet Node.js asynchrones \ac{IO} wodurch eine hohe Performance bei
vielen gleichzeitigen Verbindungen erreicht werden kann.
\subsection{Go}
Mit dem Ziel Netzwerkpogrammierung zu vereinfachen und Skalierbarkeit über
mehrere CPU-Kerne oder gar ganze Rechenzentren sicherer zu
gestalten, began Google 2007 mit der Entwicklung von Go.\footnote{https://talks.golang.org/2012/splash.article} Das Ergebnis
ist eine kompilierte, ``garbage
collected''\footnote{https://en.wikipedia.org/wiki/Garbage\_collection\_(computer\_science)}
und statisch typisierte Sprache.\footnote{https://golang.org}\\
Großen Anklang fand Go im Bereich der Containersierung, beispielsweise ist die
Container Lösung Docker\footnote{https://www.docker.com} in Go implementiert, und in der Serverseitigen
Infrakstruktur: Der Cloud Infrakstruktur Anbieter Digitalocean hat große Teile
seiner Infrakstruktur in Go
implementiert.\footnote{https://speakerdeck.com/farslan/go-at-digitalocean}\\
Die Vorteile der Sprache sind die umfangreiche Standardbibliothek, vorallem im
Bereich der Netzwerkpogrammierung, die kurzen Kompilierzeiten und die hohe
Geschwindigkeit der Sprache geführt. Die, zum Zeitpunkt dieser Arbeit, nicht vorhandene Unterstützung von Generics\footnote{https://en.wikipedia.org/wiki/Generics\_in\_Java}
und teilweise umständliche Behandeln von Fehlerzuständen haben wir als Nachteile angesehen.
\subsection{Java}
Einer der Platzhirsche der Programmiersprachen. Sun Microsystems begann 1995 mit
der Entwicklung der Sprache, nach der Übernahme von Sun Microsystems durch Oracle wurde die
Entwicklung unter neuem Firmennamen weitergeführt. Unter dem Namen OpenJDK ist
eine OpenSource Implementation unter der \ac{GPL} verfügbar, die seit Version 7 als
Referenzimplementation gilt.\footnote{https://openjdk.java.net}\\
Als Vorteile der Sprache zählen vorallem das umfangreiche Typsystem mit
Unterstützung von Generics, die große Auswahl an Drittanbieter Bibliotheken und Frameworks und,
im Falle dieses Projektes, die fundierte Erfahrung beider Projektteilnehmer mit
der Sprache.\\
% TODO Add disadvantages
Unter Abwägung der genannten Vor- und Nachteile wurde entschiededn, Java als
Sprache für das Backend von Chromstahl zu verwenden.
\section{Vergleich von Backend-Frameworks}
Die Entscheidung, Java als Sprache für das Backend zu verwenden, zieht die Frage
mit sich, welches Framework verwendet werden soll. Nachfolgend werden drei
Kandidaten genauer betrachtet
\subsection{\acl{JakartaEE}}
\ac{JakartaEE} erweitert die Java Spezifikationen um weitere, hauptsächlich zum
Entwicklen von verteilten Systemen und Webanwendunge gedachten, Spezifikationen.\footnote{https://jakarta.ee/}
Oracle begann 1999 mit der
Enwticklung unter dem Namen ``Java 2 Platform, Enterprise Edition''. Im Jahre
2006 wurde der Name auf ``Java Platform, Enterprise Edition'' geändert. 2017
wurde die Entwicklung in die Hände der Eclipse Foundation übergeben und der Name
änderte sich zum heute gebräuchlichen
\acs{JakartaEE}.\footnote{https://adtmag.com/articles/2017/09/12/java-ee-moving-to-eclipse.aspx}\\
Da es sich hierbei jediglich um Spezifikationen handelt, bedarf es einer
Implementation. Damit eine Implementation kompatibel zu \ac{JakartaEE} ist, muss
sie alle geforderten Spezifikationen unterstützten. Unterschiede gibt es in
zusätzlichen Funktionen (Fehlertoleranz, Start-up Zeit, etc.) und in den
Lizenzen.\footnote{https://en.wikipedia.org/wiki/Java\_Platform,\_Enterprise\_Edition\#Certified\_referencing\_runtimes}\\
Mithilfe einer Implementation ist es bereits möglich, umfassende Webanwendungen
zu programmieren. Oftmals ist es jedoch gewünscht, Lösungen für bekannete
Probleme zu erhalten. Hier helfen auf \ac{JakartaEE} aufbauende Frameworks, wie
die nachfolgend betrachteten Vertreter Play und Spring.
\subsection{Play}
% TODO: Write something or remove
Play ist ein von Lightbend und Zengularity entwickeltes Webframework. Es ist in
Scala entwickelt, ist aber vollständig mit Java
kompatibel.\footnote{https://www.playframework.com/} Das Zeil des Projektes ist
es, die Produktivität von Entwicklern zu erhöhen. Dies wird umgesetzt durch
einfache Konfiguration, ``Hot code reloading''\footnote{Just-in-Time Kompilierung
und Nachladen von Code zur Entwicklungszeit} und die Darstellung von
Fehlermeldungen im Browser.
\subsection{Spring}
Das von Pivotal\footnote{https://pivotal.io/} entwickelte Framework kombiniert einen ``Dependency injection
Container''\footnote{https://en.wikipedia.org/wiki/Dependency\_injection}, Funktionen zum Zugriff auf diverse Datenbanken und ein \ac{MVC}
Webframework.\footnote{https://spring.io/}.\\
Der Streaming-Service
Netflix\footnote{https://www.netflix.com/de-en/} begann 2013 mit der Umstellung
seiner Infrakstruktur auf Microservices\footnote{https://en.wikipedia.org/wiki/Microservices} unter Kooperation mit dem Cloudcomputing
Anbieter \ac{AWS}\cite{cloud-native-java}. Als Technologie wurde auf Java und
Spring gesetzt. Zu dem Zeitpunkt war Netflix einer
der Pioniere im Bereich dieser Art von Architektur und prägte somit den Begriff
``Cloud-Native'' und, durch die Veröffentlichung der Lösungen und des erlangten
Wissens, das gesamte Ecosystem für die Entwicklung von Microservices, allem
voran das Spring Framework.\\
Das Framework erlangte daher schnell Aufmerksamkeit auch außerhalb von Netflix
und ist mittlerweile zu dem Industriestandard bei der Entwicklung von
Webanwendungen mit Java geworden. Pivotal erleichterte mit der Veröffentlichung
von Spring Boot\footnote{https://spring.io/projects/spring-boot} die Verwendung
von Spring mithilfe einer vorgefertigeten Konfiguration, eines eingebetteten
Webservers und einer Möglichkeit zur schnelllen Zusammenstellung von
Spring-Komponenten nochmals. Somit verwenden auch mehr und mehr mittelständische
Entwicklungsfirmen Spring zur Entwicklung von Web Lösungen.\\
Durch den großen Anklang ergibt sich ein großer Vorteil von Spring gegenüber
anderen Lösungen: Es hat sich ein großes Ecosystem mit unter verschiedensten
Bedingungen getesteten Bibiolotheken entwickelt. Diese reichen von Lösungen zur
Verbindungen mit Datenbanken, über Schnitstellen zu In-Memory Caches wie Redis
oder Konfigurations Management von Microservices bis hin zu Lösungen für
Auhentifkation und Authentisierung von Nutzern.\\
Es wurde entschieden, Spring als Basis des Backends von Chromstahl zu verwenden
- Nicht zuletzt auf Grund der positiven Erfahrungen aus der Umsetzung von
anderen Webprojekten mit diesem Framework.
\section{Vergleich von Datenbank-Lösungen}
Für ein \ac{CMS} wird, in der regel, eine Form von \ac{DBMS} benötigt, um Dokumente,
Nutzer und Inhalte zu verwalten. Hierbei musste zwischen zwei grundsätzlich verschiedenen Ansätzen entschieden werden.
\subsection{Relational Database}
Das relationales Datenbankmanagementsystem wurde von Edgar F. Codd 1970 vorgestellt. Das Prinzip der relationalen Datebnbank wurde entworfen um dem Nutzer das Verständnis der zugrundeliegenden Speicherarchitektur abzunehmen. Zugleich wurde von Codd eine Sprache vorgeschlagen um mit der Datenbank zu interagieren (Structured Query Language - SQL\footnote{https://de.wikipedia.org/wiki/SQL})
Eine relationale Datenbank bildet ``relationen'' zwischen Tabellen, so kann einfach vermieden werden, dass Daten
nicht mehrfach abbgebildet werden müssen.
\cite{codd}
Dies hat den Nachteil, dass eine komplexe Abfrage leicht langsam werden kann,
da viele Tabellen geladen und durchsucht werden müssen.
\subsection{Document Oriented Database}
Die Document Oriented Database