Diplomarbeit - der ganze bazen

Transcription

Eidesstattliche Erklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig erstellt, keine
anderen als die angegebenen Quellen benutzt und keine fremde Hilfe in Anspruch
genommen habe.
Felix Krüger
Hamburg, den 29.09.09
Hochschule für Angewandte Wissenschaften Hamburg
Fakultät Design, Medien und Information
Studiengang Medientechnik
Konzeption und Entwicklung einer
webbasierten Medienbibliothek
Diplomarbeit
verfasst und vorgelegt von
Felix Krüger
zur Erlangung des akademischen Grades
Diplom-Ingenieur (FH)
durchgeführt bei
TUDOCK – Pahlmann und Wolf GbR, Hamburg
betreut von
Niels Pahlmann, TUDOCK – Pahlmann und Wolf GbR
Prof. Andreas Plaß, HAW Hamburg
Hamburg, September 2009
I
Inhaltsverzeichnis
1 Einleitung...................................................................................................................1
1.1 Zielsetzung..................................................................................................................................1
1.2 Auswahl der technischen Mittel.........................................................................................2
1.3 Methodisches Vorgehen.........................................................................................................3
2 Anforderungen.........................................................................................................4
2.1 Anwendungsfälle/Anforderungen Benutzersicht.......................................................4
2.1.1 Hosting Service ................................................................................................................4
2.1.1.1 Benutzer kann über Webinterface zugreifen..............................................4
2.1.1.2 Hochgeladene Dateien können importiert werden..................................4
2.1.1.3 Die Metadaten werden automatisch importiert........................................5
2.1.1.4 Metadaten können bearbeitet werden..........................................................5
2.1.1.5 Einträge werden in Listenform dargestellt.................................................5
2.1.1.6 Die Einträge der Bibliothek sind filterbar....................................................5
2.1.1.7 Einträge können sortiert werden....................................................................5
2.1.1.8 Reiter ermöglichen paralleles Arbeiten........................................................5
2.1.1.9 Wiedergabelisten können angelegt werden...............................................5
2.1.1.10 Benutzer kann Musik abspielen lassen......................................................6
2.1.1.11 Einzelne Titel können bewertet werden....................................................6
2.1.2 Community.........................................................................................................................6
2.1.2.1 Benutzer kann sich registrieren.......................................................................6
2.1.2.2 Dateien können über den Browser importiert werden..........................6
2.1.2.3 Bibliotheken können mit anderen Nutzern geteilt werden..................7
2.1.2.4 Playlisten können verschickt werden............................................................7
2.1.2.5 Metadaten können übergreifend bearbeitet werden..............................7
2.1.2.6 Es kann auf externe Datenquellen zugegriffen werden..........................7
2.1.2.7 Verschiedene Datenformate..............................................................................7
2.1.2.8 Weitere Community-Funktionen.....................................................................8
2.1.3 Online-Vertrieb.................................................................................................................8
2.1.3.1 Es kann ein Account erstellt werden..............................................................8
2.1.3.2 Benutzer kann auf Bibliothek des Dienstleisters zugreifen..................8
2.1.3.3 Der Zugriff kann über verschiedenen Clients erfolgen...........................8
II
2.2 Anforderungen aus Entwicklersicht.................................................................................9
2.2.1 Benutzeroberfläche........................................................................................................9
2.2.1.1 Bedienkonzept ähnlich wie bei Desktop-Anwendungen.......................9
2.2.1.2 Rückmeldung bei Fehlern...................................................................................9
2.2.1.3 Browserkompatibilität......................................................................................10
2.2.1.4 Verschiedene Auflösungen..............................................................................10
2.2.2 Erweiterbarkeit/Flexibilität.....................................................................................11
2.2.2.1 Modularität............................................................................................................11
2.2.2.2 Multi-Client-Fähigkeit........................................................................................11
2.2.2.3 Austauschbare Persistenzschicht.................................................................11
2.2.2.4 Weitere Datenformate.......................................................................................12
2.2.3 Daten..................................................................................................................................12
2.2.3.1 Normalisierung ...................................................................................................12
2.2.3.2 Variable Filterung................................................................................................12
2.2.3.3 Flexibilität der Datenstruktur........................................................................12
2.2.3.4 Speicherort der Medien....................................................................................13
2.2.4 Sicherheit.........................................................................................................................13
2.2.4.1 Authentifizierung................................................................................................13
2.2.4.2 Validierung.............................................................................................................13
2.2.4.3 Zugriffsrechte........................................................................................................13
2.2.5 Trennung von Server und Client.............................................................................13
2.2.6 Client..................................................................................................................................14
2.2.7 Performance....................................................................................................................14
2.2.7.1 Scriptlaufzeiten....................................................................................................14
2.2.7.2 Datentransfer........................................................................................................14
2.2.8 Import................................................................................................................................14
3 Konzept....................................................................................................................16
3.1 Technologiewahl.....................................................................................................................16
3.1.1 Webserver........................................................................................................................16
3.1.2 PHP Framework............................................................................................................17
3.1.3 JavaScript Framework................................................................................................17
3.1.4 Medienwiedergabe.......................................................................................................17
3.2 Programmierrichtlinien......................................................................................................17
III
3.2.1 PHP.....................................................................................................................................18
3.2.2 Javascript..........................................................................................................................18
3.2.3 Dateistruktur..................................................................................................................19
3.3 Grafische Benutzeroberfläche...........................................................................................20
3.3.1 Aufbau/Funktionalität................................................................................................20
3.3.2 Single Page Interface...................................................................................................21
3.3.3 MVC.....................................................................................................................................22
3.4 Anwendungsarchitektur.....................................................................................................23
3.4.1 Datenstruktur.................................................................................................................23
3.4.2 Schichtenarchitektur...................................................................................................24
3.4.3 Server - Client Schnittstelle Ext Direct.................................................................26
3.4.4 Sicherheitsmechanismen...........................................................................................27
3.4.5 Fehlerbehandlung.........................................................................................................28
3.4.6 Module...............................................................................................................................28
3.4.7 Datenfluss........................................................................................................................29
3.4.7.1 Client.........................................................................................................................29
3.4.7.2 Server.......................................................................................................................30
4 Entwicklung der Anwendung...........................................................................31
4.1 Serverseitige Programmierung........................................................................................31
4.1.1 Start der Anwendung..................................................................................................31
4.1.1.1 Bootstrap-Datei und Htaccess........................................................................31
4.1.1.2 Initialisierung........................................................................................................31
4.1.1.3 Konfiguration........................................................................................................31
4.1.1.4 Aufruf der Front-Controller ...........................................................................32
4.1.1.5 Authentifizierung................................................................................................32
4.1.2 Front-Contoller/Views...............................................................................................33
4.1.3 Controller.........................................................................................................................33
4.1.4 Models/Filter..................................................................................................................35
4.1.4.1 Items.........................................................................................................................36
4.1.4.2 Listen........................................................................................................................38
4.1.4.3 Request....................................................................................................................40
4.1.4.4 Filter.........................................................................................................................42
4.1.4.5 Response.................................................................................................................43
IV
4.1.4.6 Verwendete Entwurfsmuster.........................................................................43
4.1.4.6.1 Fluent Interfaces.........................................................................................43
4.1.4.6.2 Lazy Acquisition.........................................................................................43
4.1.5 Backend............................................................................................................................44
4.1.5.1 Definition der Schnittstelle..............................................................................44
4.1.5.2 Implementierung.................................................................................................44
4.1.5.3 Konfiguration........................................................................................................45
4.1.6 Module...............................................................................................................................46
4.1.6.1 Core...........................................................................................................................46
4.1.6.2 Ext..............................................................................................................................47
4.1.6.2.1 Der Index-Controller.................................................................................47
4.1.6.2.2 Ext Direct.......................................................................................................48
4.1.6.3 Audio, Playlist und Import...............................................................................49
4.1.7 Helfer.................................................................................................................................49
4.1.7.1 Debugging...............................................................................................................49
4.1.7.2 Minify........................................................................................................................50
4.2 Clientseitige Anwendung....................................................................................................50
4.2.1 Initialisierung.................................................................................................................50
4.2.2 Zusammenspiel der MVC-Komponenten.............................................................50
4.2.3 Controller.........................................................................................................................51
4.2.4 Models...............................................................................................................................51
4.2.5 View....................................................................................................................................52
4.2.6 Ext Direct..........................................................................................................................53
4.2.7 Module (Auszug)...........................................................................................................54
4.2.7.1 Bibliothek...............................................................................................................54
4.2.7.2 Player........................................................................................................................55
5 Erweiterbarkeit der Anwendung....................................................................57
5.1 Zusätzliche Clients mit XML-RPC Webservice............................................................57
5.2 Neues Datenformat aus externer Quelle.......................................................................58
6 Vor- und Nachteile der Anwendung...............................................................60
6.1 Schichtenarchitektur............................................................................................................60
6.2 Trennung von Server- und Client-Anwendung..........................................................61
6.3 MVC im Browser.....................................................................................................................62
V
6.4 Vergleich mit Desktop-Applikationen............................................................................64
7 Fazit/Ausblick........................................................................................................68
8 Anhang.....................................................................................................................71
A Literaturverzeichnis...............................................................................................................72
B Tabellenverzeichnis................................................................................................................76
C Abbildungsverzeichnis...........................................................................................................77
D Datenstruktur............................................................................................................................78
E API..................................................................................................................................................81
F Anwendungsbeispiel...............................................................................................................82
G Verwendete Internet-Techniken........................................................................................83
G.1 HTTP....................................................................................................................................83
G.2 PHP ......................................................................................................................................84
G.3 MySQL.................................................................................................................................85
G.4 Javascript/Ajax................................................................................................................85
G.5 Audio und Video im Browser.....................................................................................86
Einleitung
1
1 Einleitung
1.1 Zielsetzung
Seit einigen Jahren lässt sich beobachten, dass für immer mehr Desktop-Anwendungen webbasierte Äquivalenzen entstehen. Vorreiter wie Google entwickeln
webbasierte Office-Anwendungen, Kalender oder Projektverwaltungen, die vom
Desktop bekannte Funktionalitäten in den Webbrowser verlagern und mit zusätzlichen Features anreichern. Alle diese webbasierten Anwendungen verlangen eine
neue Art, Webseiten zu entwickeln. Sie verlangen Benutzeroberflächen, die denen
von Desktop-Anwendungen in nichts nachstehen. Durch den Gebrauch von Ajax ist
es möglich, nicht mehr nur einzelne Webseiten auszuliefern, die über Links miteinander verbunden sind, sondern Applikationen zu erstellen, die im Client ausgeführt werden und bei Bedarf Daten vom Server laden.
In dieser Diplomarbeit wird eine solche Rich Internet Application konzeptioniert
und entwickelt. Ziel ist es, eine grundlegende Lösung für eine webbasierte Medienbibliothek zu entwerfen und aufzuzeigen welche Möglichkeiten dieser Ansatz bietet. Dabei wird angestrebt, eine Software zu entwickeln, die als Basis für weitere
Entwicklungsstufen dienen kann, in denen die spezifischen Vorteile einer webbasierten Anwendung zum Tragen kommen. Dazu gehört z.B. die Interaktion der
Benutzer untereinander, die Vielfalt der möglichen Datenquellen und die zunehmende Mobilität der Internet-fähigen Endgeräte (Stichwort UMTS). Die Betrachtungen und auch die Entwicklung werden anhand des Medientyps Audio ausgeführt, was nicht heißt, dass die Konzepte nicht auch für andere Medientypen angewendet werden können.
Eine webbasierte Medienbibliothek bringt mehrere Vorteile für den Benutzer mit
sich. Die steigende Anzahl der von einer Person verwendeter Computer macht es
oft mühsam, die eigenen Mediendateien zwischen all diesen zu synchronisieren.
Ein Server, auf den von überall aus zugegriffen werden kann, bietet hier eine zentrale Schnittstelle für die verschiedenen Clients und gleichzeitig eine sichere
Einleitung
2
Backup-Lösung. Bei der Konzeption der Serveranwendung muss allerdings darauf
geachtet werden, dass die verschiedenartigen Endgeräte über unterschiedliche
Technologien verfügen und somit auch unterschiedliche Implementierungen der
clientseitigen Anwendung verlangen.
Ein weiterer Vorteil bietet sich durch die Verbindung der webbasierten Medienbibliothek mit Community-Funktionen. Das gegenseitige Vorstellen der eigenen Lieblingsmusik oder einfach nur das gemeinsame Pflegen der Metadaten stellen einen
Mehrwert für den Benutzer dar. Diese Möglichkeiten sind nur ein Beispiel für den
erweiterten Nutzen der hier zu entwickelnden Anwendung. Sie müssten ggf. auf
ihre medienrechtliche Legalität hin überprüft werden.
1.2 Auswahl der technischen Mittel
Die Entscheidung bei der Wahl technischen Mittel für diese Diplomarbeit beruht
im Wesentlichen auf drei Faktoren.
Die verwendeten Mittel sollen möglichst weit verbreitete Open-Source-Produkte
sein, damit die Entwicklung lizenzkostenfrei erfolgen kann, keine Abhängigkeiten
von Herstellerfirmen entstehen können und für eine Weiterentwicklung alle Möglichkeiten offen stehen.
Des Weiteren sind die Vorkenntnisse des Diplomanden in Bezug auf die jeweilige
Software/Programmiersprache und die im betreuenden Betrieb verwendeten
Technologien ein Auswahlkriterium. Bei guten Vorkenntnissen kann die Anwendung effizienter entwickelt werden und eine hochwertigere Lösung erzielt werden.
Der letzte und natürlich wichtigste Faktor ist, dass die Technologien für das Vorhaben geeignet sind.
Eine genaue Beschreibung, welche Technologien für welchen Bereich gewählt wurden, findet sich im Konzept unter 3.1 .
Einleitung
3
1.3 Methodisches Vorgehen
Zunächst werden drei mögliche Anwendungsfälle für die Software dargestellt,
wobei nur einer davon konkret ausgearbeitet werden soll und die weiteren insofern eine Rolle spielen, als dass sie mit der hier vorgestellten Entwicklung in einem
weiteren Schritt umgesetzt werden können sollen. Aus den Anwendungsfällen
werden technische Anforderungen abgeleitet, die als Grundlage für das Konzept
und die Entwicklung gelten.
Im konzeptionellen Teil wird die Software-Architektur erläutert. Ein wesentlicher
Fokus liegt hier auf der Erweiterbarkeit und der Trennung zwischen Server- und
Client-Anwendung.
Im nächsten Schritt werden die vorgestellten Konzepte umgesetzt und ihre Implementierung vorgestellt. Hier wird Wert darauf gelegt, keinen Quelltext aufzulisten,
sondern die Zusammenhänge der einzelnen Komponenten und ihre Funktionsweise darzustellen.
Im Folgenden wird an zwei Beispielen aufgezeigt, wie sich die Anwendung erweitern lässt und wo die Vor- und Nachteile der hier entwickelten Software liegen. Das
Fazit fasst die gewonnenen Erkenntnisse bezüglich des Nutzens der entwickelten
Rich Internet Application zusammen und mündet in einer abschließenden Bewertung.
Anforderungen
4
2 Anforderungen
In diesem Abschnitt werden zunächst verschiedene Anwendungsfälle skizziert, die
für eine webbasierte Medienbibliothek grundsätzlich denkbar sind. Anhand dieser
Use-Cases werden die Anforderungen an die Anwendung zunächst aus Benutzersicht und anschließend aus Sicht des Entwicklers hergeleitet. Der Fokus der
Diplomarbeit liegt dabei auf der Ausarbeitung des ersten Anwendungsfalls. Die
beiden weiteren kurz skizzierten Anwendungsfälle verdeutlichen zusätzliche
Anforderungen, die es im Hinblick auf eine spätere Erweiterung der Software zu
berücksichtigen gilt.
2.1 Anwendungsfälle/Anforderungen Benutzersicht
2.1.1 Hosting Service
Der erste Anwendungsfall beschreibt den Nutzen einer webbasierten Medienbibliothek als Hosting Service. Der Benutzer kann hier ein Online-Backup seiner
Musiksammlung anlegen und die Titel über ein Webinterface unabhängig von Ort,
Betriebssystem und installierter Software (mit Ausnahme eines Browsers) verwalten und anhören.
2.1.1.1 Benutzer kann über Webinterface zugreifen
Zunächst ruft der Benutzer die entsprechende Internetadresse der Webanwendung in seinem Browser auf und meldet sich über ein Login-Formular an. Nach
dem ersten Einloggen findet er eine leere Bibliothek vor.
2.1.1.2 Hochgeladene Dateien können importiert werden
Um die eigene Bibliothek zu befüllen lädt der Benutzer mit einem FTP-Programm
beliebig viele Audiodateien auf den Server. Im Webinterface gibt es einen Menüpunkt „Bibliothek Synchronisieren“, über den die hochgeladenen Dateien in die
Anwendung importiert werden können. Es wird sichergestellt, dass keine Titel
doppelt importiert werden.
Anforderungen
5
2.1.1.3 Die Metadaten werden automatisch importiert
Die Anwendung liest die vorhandenen Metadaten (Id3-Informationen) aus den
Audiodateien aus und importiert sie in die Datenbank der Anwendung.
2.1.1.4 Metadaten können bearbeitet werden
Ein Kontextmenü bietet dem Benutzer die Möglichkeit, die Metadaten von einzelnen Einträgen zu bearbeiten. Es öffnet sich ein Fenster, in dem die vorhandenen
Daten dargestellt und verändert werden können.
2.1.1.5 Einträge werden in Listenform dargestellt
Die Einträge der Datenbank werden in einer Listenform dargestellt, die dem
Benutzer einen übersichtlichen Zugriffspunkt auf die Medien ermöglicht.
2.1.1.6 Die Einträge der Bibliothek sind filterbar
Über verschiedene, in Reihe geschaltete Filter kann der Benutzer durch seine
Musiksammlung navigieren. Es ist möglich nach Genre, Interpret, Album und
einem Suchwort zu filtern.
2.1.1.7 Einträge können sortiert werden
Die angezeigten Einträge lassen sich über verschiedene Kriterien sortieren, einzelne Spalten können aus- und eingeblendet und in der Breite verändert werden.
2.1.1.8 Reiter ermöglichen paralleles Arbeiten
Die verschiedenen Ansichten laden sich in einzelnen Tabs, zwischen denen hin und
her gesprungen werden kann.
2.1.1.9 Wiedergabelisten können angelegt werden
Weiterhin besteht die Möglichkeit, Wiedergabelisten anzulegen. Beliebig viele Titel
können in eine bestehende Liste hineingezogen werden. Beim Klicken auf eine
Liste öffnet sich ein zusätzlicher Tab. So kann leicht zwischen der Bibliothek und
den verschiedenen Playlisten hin und her geschaltet werden. In diesem Tab können die Titel umsortiert und abgespielt werden.
Anforderungen
6
2.1.1.10 Benutzer kann Musik abspielen lassen
Der integrierte Player verfügt neben den Standardfunktionen wie Start, Stopp, Vor
und Zurück über einen Lautstärke-Regler und eine Zeitleiste. Durch einen Doppelklick können einzelne Titel abgespielt werden. Ist ein Song zu Ende, werden die
weiteren Titel anhand der gewählten Filtereinstellungen bzw. der Wiedergabeliste
automatisch abgespielt. Eine zuschaltbare Zufallsfunktion kann bei Bedarf Variation in die Abspielreihenfolge bringen. Eine Anzeige verrät, welcher Titel gerade
abgespielt wird.
2.1.1.11 Einzelne Titel können bewertet werden
Der aktuell laufende Titel kann vom Benutzer bewertet werden. Die aktuelle
Bewertung wird jeweils angezeigt.
2.1.2 Community
Ein weiterer Anwendungsfall ist, die Medienbibliothek in ein Community-Portal
einzubinden. Hier hat der Benutzer nicht nur Zugriff auf seine eigene Musik. Er
kann zusätzlich auf die Sammlung von seinen Freunden in der Community zugreifen und Wiedergabelisten teilen. Dieser Anwendungsfall baut auf den Funktionalitäten von 2.1.1 auf, die hier nicht noch einmal aufgeführt werden.
2.1.2.1 Benutzer kann sich registrieren
Zuerst muss sich der Benutzer registrieren. In einem Formular müssen alle als
Pflichtangaben markierten Informationen angegeben werden.
2.1.2.2 Dateien können über den Browser importiert werden
Nach dem ersten Einloggen hat der Benutzer die Möglichkeit, Musikdateien zu seinem Account hinzuzufügen. Er wählt die gewünschten Dateien über ein Formular
von der Festplatte aus und lädt sie anschließend hoch.
Anforderungen
7
2.1.2.3 Bibliotheken können mit anderen Nutzern geteilt werden
Der Benutzer kann seine eigene Bibliothek für andere Mitglieder freigeben.
Dadurch ergeben sich weitere Funktionalitäten: Als Einschränkung für die Anzeige
der Bibliothek kann angegeben werden, ob nur die eigenen Dateien oder auch die
von Freunden freigegebenen angezeigt werden sollen.
2.1.2.4 Playlisten können verschickt werden
Angelegte Wiedergabelisten können an andere Mitglieder verschickt werden. Sie
erscheinen beim anderen Benutzer in einer entsprechenden Tabelle.
2.1.2.5 Metadaten können übergreifend bearbeitet werden
Einzelne Einträge der Bibliothek können im Kollektiv bearbeitet werden, sodass
ein anderer Benutzer zum Beispiel weitere Schlüsselwörter hinzufügen oder einen
Song bewerten kann. Der Besitzer einer Datei kann einsehen, wer wann welche
Änderungen an den Metainformationen seiner Inhalte vorgenommen hat und sie
ggf. rückgängig machen.
2.1.2.6 Es kann auf externe Datenquellen zugegriffen werden
Über eine zusätzliche Ansicht kann auf externe Quellen zugegriffen werden. Denkbar ist beispielsweise eine Anbindung an die API von Youtube.
2.1.2.7 Verschiedene Datenformate
Es gibt die Möglichkeit, Videodateien in die Bibliothek zu importieren. Dazu wird
der Player um ein Videofenster erweitert, welches sich bei Bedarf öffnet. Über
einen weiteren Menüpunkt können verschiedene Internetradios durchsucht und
abgespielt werden. Hierbei handelt es sich um bestehende Radio-Streams, die von
der Anwendung verlinkt werden.
Anforderungen
8
2.1.2.8 Weitere Community-Funktionen
Es ist denkbar, dass weitere Community-Funktionen in die Anwendung integriert
werden, die nicht direkt mit der Bibliothek zu tun haben. Im Rahmen dieser
Diplomarbeit soll darauf jedoch nicht weiter eingegangen werden, da sie mit dem
Thema nur indirekt zu tun haben.
2.1.3 Online-Vertrieb
Der letzte hier vorzustellende Anwendungsfall bezieht sich auf die Integration der
Medienbibliothek in einen Onlineshop für Mediendateien. Der Benutzer kann hier
über ein Webinterface auf die über ein Online-Portal erworbene Musik zugreifen,
ohne sie zuerst hochladen zu müssen. Dieser Anwendungsfall schließt die Funktionen von 2.1.1 mit ein, sie werden hier nicht erneut aufgeführt.
2.1.3.1 Es kann ein Account erstellt werden
Der Benutzer muss zuerst einen Account für den Onlineshop erstellen. Sobald dieser Vorgang abgeschlossen ist und der Kunde sich für ein Angebot des Anbieters
entschieden hat, kann er auf das Web-Interface zugreifen.
2.1.3.2 Benutzer kann auf Bibliothek des Dienstleisters zugreifen
Das Hochladen der eigenen Dateien entfällt in diesem Anwendungsfall. Dafür kann
ein Benutzer auf die vom Dienstleister zur Verfügung gestellten, kostenpflichtigen
Inhalte zugreifen. Der Benutzer hat die Möglichkeit zu wählen, ob er die komplette
Bibliothek für einen monatlichen Festpreis zur Verfügung gestellt bekommt oder
ob er alternativ nur auf die einzeln bezahlten Inhalte zugreifen kann.
2.1.3.3 Der Zugriff kann über verschiedenen Clients erfolgen
Zusätzlich zum Zugriff über den Browser hat der Benutzer die Möglichkeit über
andere Clients, wie z.B. einer AIR1 oder Java Applikation auf dem Handy auf die
Bibliothek zuzugreifen und die gewünschten Titel abzuspielen.
1 Mit AIR (Adobe Integrated Runtime) lassen sich Rich Internet Applications für den Desktop
erstellen, die ohne Browser auskommen. [WIKI06]
Anforderungen
9
2.2 Anforderungen aus Entwicklersicht
Die abgeleiteten Anforderungen beziehen sich konkret auf den in 2.1.1 vorgestellten Anwendungsfall (Hosting Service). Die anderen Anwendungsfälle spielen insofern eine Rolle, als dass sie in einer späteren Ausbaustufe ohne grundlegende
Änderungen an der Architektur umgesetzt werden können sollen.
2.2.1 Benutzeroberfläche
Die Anforderungen an die Benutzeroberfläche, die aus dem Anwendungsfall 2.1.1
Hosting Service hervorgehen, ergeben sich aus Benutzergewohnheiten beim
Umgang mit computerbasierten Medienbibliotheken und der geforderten Flexibilität im Hinblick auf die Erweiterbarkeit.
2.2.1.1 Bedienkonzept ähnlich wie bei Desktop-Anwendungen
Um die in 2.1.1.8 und 2.1.1.9 beschriebenen Funktionalitäten umsetzen zu können,
müssen bewährte Bedienkonzepte von gewohnten Desktop-Anwendungen verwendet werden. Dazu gehören z.B. Drag'n'Drop- und Tab-Funktionen.
2.2.1.2 Rückmeldung bei Fehlern
Falls es Fehler bei der Kommunikation mit dem Server gibt, muss der Benutzer
darüber aufgeklärt werden, damit er sich ggf. an den Administrator wenden kann.
Anforderungen
10
2.2.1.3 Browserkompatibilität
Abbildung 1: Verbreitung der verschiedenen Browserversionen [WWW29]
Da die Anwendung zunächst in einem Browser ausgeführt wird, muss eine möglichst hohe Kompatibilität mit den gängigen Browsern und Betriebssystemen
erreicht werden. Es kann davon ausgegangen werden, dass veraltete Browser wie
z.B. der Internet Explorer 5 nur noch einen sehr geringen Marktanteil besitzen und
somit vernachlässigt werden können. Außerdem wird für die Benutzung der
Medienbibliothek ein Flash-Plugin sowie aktiviertes Javascript vorausgesetzt.2
2.2.1.4 Verschiedene Auflösungen
Die Anwendung muss auf unterschiedlichen Auflösungen bedienbar bleiben. Dazu
muss das Interface so gestaltet werden, dass es sich an die jeweilige Auflösung des
Browser-Fensters anpasst.
2 Die aktuelle Verbreitung von Flash und Javascriipt liegt bei ca. 87% und 98% [WWW30].
Anforderungen
11
2.2.2 Erweiterbarkeit/Flexibilität
Da sich die Anwendung in verschiedenen Use-Cases einsetzen lassen soll, ist es
erforderlich eine flexible Anwendungsarchitektur zu entwerfen, mit der es möglich
ist, Erweiterungen vorzunehmen, ohne bestehende Teile modifizieren zu müssen
(Offen/Geschlossen Prinzip [FRE08]). Diese Grundannahme ist gleichzeitig Basisvoraussetzung für die weiteren technischen Anforderungen.
2.2.2.1 Modularität
Die Anwendung muss möglichst modular aufgebaut sein, so dass einzelne Module
einfach hinzugefügt oder entfernt werden können, ohne dass dies Auswirkungen
auf andere Programmteile hat.
2.2.2.2 Multi-Client-Fähigkeit
Es muss sichergestellt werden, dass später weitere Schnittstellen für verschiedene
Clients, wie sie im Anwendungsfall 2.1.3 gefordert sind, einfach hinzugefügt werden können.
Dazu muss das Ausgabeformat der Daten unabhängig von der eigentlichen Programmlogik (Domäne) sein. Verschiedene Webservices können so den jeweiligen
Client mit den Controllern der eigentlichen Applikation verbinden. Auch die
Authentifizierung ist dadurch auf unterschiedliche Weise möglich.
2.2.2.3 Austauschbare Persistenzschicht
Die Persistenzschicht3 muss austauschbar sein, weil beispielsweise ein Onlineshop
(Anwendungsfall 2.1.3 ) erwartungsgemäß seine eigene Datenstruktur mit sich
bringt. Es gilt: Die Quelle der Daten soll nicht die Anwendungslogik beeinflussen
und umgekehrt.
3 Der Begriff Persistenz benennt in der Informatik die dauerhafte Speicherung von Daten in einer
Datenbank oder einem Dateisystem. [WIKI16]
Anforderungen
12
2.2.2.4 Weitere Datenformate
Wie in 2.1.2.7 beschrieben, muss es die Möglichkeit geben, weitere Datenformate
(z.B. für Videos) anzulegen. Die bestehende Architektur darf davon nicht beeinflusst werden.
2.2.3 Daten
Bei der Struktur der Datenspeicherung muss ein möglichst optimaler Kompromiss
zwischen Flexibilität und Performance sowie Wartbarkeit gefunden werden.
2.2.3.1 Normalisierung
Um Redundanzen zu vermeiden, sollten die Daten möglichst normalisiert vorliegen.
2.2.3.2 Variable Filterung
Es soll möglich sein, die Musikdatenbank in möglichst kurzer Zeit über bestimmte
Attribute zu Filtern und durch Suchbegriffe einzugrenzen (siehe 2.1.1.6). Eine flexible Umsetzung soll es einfach machen, neue Filter hinzuzufügen.
2.2.3.3 Flexibilität der Datenstruktur
Aus 2.1.2.6 und 2.1.2.7 ergibt sich die Notwendigkeit, die Persistenzschicht unabhängig von der Anwendungslogik selbst zu gestalten, so dass ggf. auf eine systemfremde bzw. geänderte Datenbank zugegriffen werden kann.
Der Zugriff auf die Daten muss so flexibel gestaltet sein, dass es relativ einfach ist,
die Datenstruktur zu verändern, ohne Änderungen im Quellcode der Models vorzunehmen. Das Bewertungssystem einer Single-User-Application kommt beispielsweise mit einem einzelnen Datenfeld aus. Bei mehreren Benutzern muss hier die
Datenstruktur entsprechend geändert werden können, ohne dass dies Auswirkungen auf die restliche Anwendung hat.
Anforderungen
13
2.2.3.4 Speicherort der Medien
Der Speicherort der Mediendateien darf nicht fest in den Datensätzen stehen,
damit die Dateien bei Bedarf auch über einen anderen Server ausgespielt werden
können.
2.2.4 Sicherheit
2.2.4.1 Authentifizierung
Grundlegende Mechanismen stellen sicher, dass das System nur mit authentifizierten Benutzern kommuniziert.
2.2.4.2 Validierung
Benutzereingaben werden auf ihre Validität überprüft und nur im Erfolgsfall an die
Datenhaltungsschicht weitergegeben.
2.2.4.3 Zugriffsrechte
Da es sich bei den Mediendateien um urheberrechtlich geschütztes Material handeln kann, muss sichergestellt werden, dass jeweils nur dazu autorisierte Benutzer
Zugriff auf sie erhalten. Genauso dürfen Einträge in der Datenbank nur von berechtigten Benutzern gelesen, bzw. bearbeitet werden.
2.2.5 Trennung von Server und Client
Damit es später einfach ist, neue Clients für die Anwendung zu programmieren,
wird eine strikte Trennung von Server und Client angestrebt. Das bedeutet, dass
die grafische Benutzeroberfläche möglichst unabhängig arbeiten muss und nur
Daten in vorgegebenen Formaten mit dem Server austauscht. Hier ist also ein serviceorientierter Ansatz4 zu wählen, der maximale Flexibilität gewährleisten kann.
4 „Services sind (...) als Softwarekomponenten zu verstehen, die so konstruiert sind, dass sie sich
auf einfache Weise mit anderen Softwarekomponenten verbinden lassen.“ [WWW33]
Anforderungen
14
2.2.6 Client
Der Client muss flexibel anpassbar sein, damit er auf möglichst einfache Weise in
verschiedene Kontexte wie z.B. eine bestehende Community eingebunden werden
kann. Demzufolge muss die Architektur modular aufgebaut sein und das Design so
weit wie möglich von den Funktionalitäten getrennt vorliegen.
Webseiten laden sich standardmäßig komplett neu, sobald man auf einen Link
klickt. Damit der Wiedergabefluss der Medien nicht gestört wird (2.1.1.10), ist dieses Verhalten zu unterbinden. Es darf beim Navigieren durch die verschiedenen
Funktionen der Anwendung nicht zu einer Unterbrechung der Wiedergabe kommen.
2.2.7 Performance
Die Anwendung muss möglichst performant arbeiten, damit der Benutzer nicht
von langen Ladezeiten abgeschreckt wird.
2.2.7.1 Scriptlaufzeiten
Die Scriptlaufzeiten auf dem Server inklusive Datenbankabfragen und der Ausführung von Javascript-Quellcode im Browser müssen für eine maximale Performance
optimiert sein.
2.2.7.2 Datentransfer
Die zwischen Client und Server ausgetauschten Daten müssen auf das Wesentliche
beschränkt werden. Dazu gehört, dass möglichst wenig redundante Daten übertragen werden.
2.2.8 Import
Der automatische Import (2.1.1.2 und 2.1.1.3) muss die in den Audiodateien vorhandenen Informationen auslesen und daraus die für die Anwendung benötigten
Daten extrahieren und speichern. Es muss sichergestellt werden, dass die gleichen
Anforderungen
15
Dateien nicht mehrfach importiert werden, d.h. dass es für eine Audiodatei jeweils
nur einen Eintrag in der Datenbank geben darf, auch wenn der Benutzer, die Datei
ein zweites Mal importiert.
Konzept
16
3 Konzept
3.1 Technologiewahl
Wie schon in der Einleitung angedeutet wurde, handelt es sich bei der Wahl der
Technologien um einen pragmatischen Ansatz. Ein wissenschaftlicher Vergleich
würde den Rahmen dieser Diplomarbeit übersteigen, stattdessen fließen vor allem
Erfahrungen aus der Praxis in die Entscheidungen ein. Aus Kostengründen kommen nur Open-Source-Technologien in Frage.
3.1.1 Webserver
Die Basis für die Anwendung bildet eine LAMP (Linux, Apache, MySQL, PHP)
Umgebung. Diese weit verbreitete Lösung zeichnet sich durch ihre hohe Verfügbarkeit und einen großen Rückhalt in der Open-Source-Community aus. Des Weiteren
setzen auch viele andere Webanwendungen auf diesem System auf. [WWW06]
Außerdem kommt vorteilhaft hinzu, dass diese Kombination von Software auf den
meisten Webpaketen von Internet Service Providern bereits installiert ist.
Die Scriptsprache PHP ist im Gegensatz zu C# oder Java speziell auf das Erstellen
von Webseiten zugeschnitten und es gibt viele Frameworks und Bibliotheken, die
auch in dieser Webanwendung zum Einsatz kommen.
Konzept
17
3.1.2 PHP Framework
Um das Programmieren des PHP-Quellcodes effizient zu gestalten, bietet es sich an,
ein Framework zu verwenden. Das Zend Framework ist ein von vielen getestetes
und bewährtes PHP-Framework. Viele Entwurfsmuster5 wie z.B. das MVC-Konzept
sind hier schon integriert und lassen sich komfortabel verwenden. [MOE08, Seite
13-14]
3.1.3 JavaScript Framework
Für das komplexe Benutzerinterface der Medienbibliothek reichen HTML und CSS
nicht aus. Zum Erstellen von Desktop-ähnlichen Webanwendungen, stellt die Klassenbibliothek Ext JS eine umfangreiche Sammlung von GUI-Komponenten mit AjaxUnterstützung zur Verfügung [WIKI05]. Die Komponenten von Ext JS bilden viele
der geforderten Funktionalitäten ab (siehe 2.1.1.6, 2.1.1.7, 2.1.1.8 und 2.1.1.9) und
lassen sich mit geringfügigen Erweiterungen in die Anwendung einbinden.
3.1.4 Medienwiedergabe
Zum Abspielen der Medien im Browser wird ein Plugin benötigt, da der neue
HTML-5 Standard leider noch nicht von allen Browsern unterstützt wird
[WWW08]. Es bietet sich an den JW FLV Player zu verwenden, da er viele MedienFormate verarbeiten kann und eine Javascript-API zur Verfügung stellt, mit der
man den Player über ein Javascript Interface steuern kann [WWW09].
3.2 Programmierrichtlinien
Programmierrichtlinien legen den Grundstein für übersichtliche und wartbare
Software. Sie erleichtern es später anderen Entwicklern, sich in das System einzuarbeiten. In den Richtlinien soll auch festgehalten werden, wie die Verzeichniss5 „Entwurfsmuster (engl. design patterns) sind bewährte Lösungs-Schablonen für
wiederkehrende Entwurfsprobleme in Softwarearchitektur und Softwareentwicklung. Sie
stellen damit eine wiederverwendbare Vorlage zur Problemlösung dar, die in einem
bestimmten Zusammenhang einsetzbar ist.“ [WIKI17]
Konzept
18
truktur der Anwendung aufgebaut ist, damit leicht herauszufinden ist, welche Programmteile an welchem Ort zu finden sind. Als einheitlicher Namensraum wird
„Mel“ (Abk. für Media Library) verwendet.
3.2.1 PHP
Der Coding Standard des PHP-Quellcodes basiert im Wesentlichen auf dem von
Zend definierten Standard des Zend-Frameworks. Dies ist sinnvoll, da sich eine
Vielzahl von Entwicklern diesem Standard angeschlossen hat und der Programmierstil so auch mit dem verwendeten Framework konsistent ist. [WWW03]
Die wichtigsten Punkte seien hier kurz beschrieben:
Klassennamen müssen mit dem Verzeichnis, in dem sie sich befinden, übereinstimmen. Der Klassenname einer Datei in „Mel/Core/Helper.php“ lautet demzufolge
„Mel_Core_Hepler“. Variablen und Funktionsnamen werden im „camelCase“-Format notiert. Konstanten werden komplett groß geschrieben.
Für Klassen und Methoden müssen Kommentare im phpDocumenter-Format
erstellt werden [WWW04].
3.2.2 Javascript
Mit ein paar Modifikationen wird bei der Javascript-Programmierung der gleiche
Standard wie bei PHP angewendet.
Klassen werden hier in assoziativen Arrays definiert. Das heißt, eine Datei
„Mel/Helper.js“ würde als „Mel.Helper“ definiert. Das entspricht dem bei Ext JS
angewendeten Prinzip.
Konzept
19
3.2.3 Dateistruktur
Abbildung 2: Screenshot Dateisystem
Die Anwendung selbst befindet sich im Verzeichnis „app“. Darunter liegend wird
zwischen „client“ und „server“ unterschieden. Dann kommt der Name der Anwendung und der Modulname. Anschließend erfolgt die Einordnung in die verschiedenen Zuständigkeiten (z.B. Controller und Models). Beispiel: Das PHP-Model „Item“
aus dem Modul „Audio“ ist über folgenden Dateipfad zu erreichen:
„app/server/Mel/Playlist/Models/Item.php“.
CSS und Bilddateien werden unterhalb des „skin“-Ordners abgelegt. Durch eine
zusätzliche Ordnerebene haben es Entwickler später einfacher, weitere Skins zu
erstellen und einzubinden.
Einstellungen finden sich im „conf“-Ordner und Bibliotheken in „lib“.
Zu importierende Mediendateien werden im Ordner „upload“ hinterlegt. Von dort
aus werden sie während des Importierens in den „media“ Ordner kopiert. Damit
das Verzeichnis nicht irgendwann so viele Einträge hat, dass es die Performance
beeinträchtigt, werden die Dateien nach Jahr, Monat und Tag einsortiert.
Konzept
20
3.3 Grafische Benutzeroberfläche
3.3.1 Aufbau/Funktionalität
Abbildung 3: Grundlayout
Die Hauptanwendung besteht aus vier Grundelementen. Links befinden sich der
Player und eine Auflistung der Playlisten. Daneben ist Platz für variablen Inhalt,
der in Reitern dargestellt wird. Über diesen beiden Elementen befindet sich eine
Toolbar.
Der Reiter „Bibliothek“ besteht aus einer Toolbar mit einem Suchfeld. Darunter
befinden sich drei Filter mit vorgegebenen Auswahlmöglichkeiten. Klickt man im
ersten Filter einen Wert an, so aktualisieren sich die weiteren Filter entsprechend
der nun vorhandenen Möglichkeiten. Unter den Filtern befindet sich eine Liste der
gefundenen Einträge aus der Datenbank. Die einzelnen Spalten können vom Benutzer über Haltepunkte in der Kopfzeile angepasst werden und nach der entsprechenden Spalte sortiert werden. Mit einem Rechtsklick können einzelne Datensätze bearbeitet werden. Dazu öffnet sich ein zusätzliches Fenster mit Bearbei-
Konzept
21
tungsoptionen. Außerdem hat der Benutzer die Möglichkeit, einzelne Titel der
Liste per Drag'n'Drop nach links in einer bereits vorhandene Wiedergabeliste zu
ziehen.
Die Ansicht einer Wiedergabeliste entspricht der des Medienbrowsers, nur dass
das Suchfeld und die Filter ausgeblendet sind.
Der Player besteht aus einem Statusfeld, in dem in der Regel der aktuell gespielte
Titel angezeigt wird. Direkt darunter sind die verschiedenen Kontrollelemente für
den Player angeordnet.
3.3.2 Single Page Interface
Abbildung 4: Single Page Interface-Elemente innerhalb einer Seite [WWW05]
Die Wiedergabe des aktuellen Titels im Player darf beim Stöbern durch die Bibliothek nicht unterbrochen werden (siehe 2.2.6 ). Beim herkömmlichen Ansatz von
Multi Page Interfaces stellt dies ein Problem dar, da der Browser bei jedem Aufruf
einer neuen Seite die aktuelle Wiedergabe unterbrechen würde. Dieses Problem
ließe sich durch ein Einbinden der Hauptseite als Inlineframe zwar umgehen, eine
Ajax-basierte Lösung ist in diesem Fall jedoch die zeitgemäßere Variante, ein Single
Page Interface umzusetzen. Denn hier kommen außerdem weitere Vorteile zum
Tragen: Durch Ajax ist es möglich, nur einzelne Daten vom Server nachzuladen.
Konzept
22
Dies steigert einerseits die Performance und senkt zudem den Programmieraufwand, da bei Verwendung eines Frameworks wie Ext JS auf das manuelle Erstellen
von HTML-Seiten komplett verzichtet werden kann. [WWW05]
3.3.3 MVC
Der Client der webbasierten Medienbibliothek stellt eine eigenständige Anwendung dar, die lediglich Daten und Einstellungen mit der Serveranwendung austauscht. Von daher macht es Sinn bewährte Programmierkonzepte für grafische
Benutzeroberflächen, wie sie z.B. aus der JAVA-Welt bekannt sind, zu verwenden.
Abbildung 5: Aufbau des Clients
In dieser Anwendung wird das komplette MVC auf dem Client implementiert, da es
unabhängig vom Server (abgesehen von Daten) arbeiten soll. Das Fachkonzept
beinhaltet die gesamte Daten-, Zustands- und Anwendungslogik. Es bildet die Basis
der Anwendung und ist durch eine Schnittstelle mit den Daten des Servers verbunden. Hier wird z.B. die gesamte Logik des Players abgebildet. Die Präsentationsschicht stellt die Benutzeroberfläche grafisch dar – die Aufgabe der Steuerung und
somit die Verbindung zwischen Fachkonzept und Präsentation übernimmt der
Controller. Der Controller hat außerdem die Möglichkeit mit dem Server zu kommunizieren. [FRE08, Seite 529-550]
Konzept
23
3.4 Anwendungsarchitektur
3.4.1 Datenstruktur
Abbildung 6: Datenstruktur
Die wesentlichen Daten, die für die Applikation nach Anwendungsfall 2.1.1 benötigt werden, sind Musiktitel, Playlisten und Benutzer. Sie werden in MySQL-Tabellen mit der Speicher-Engine MyISAM hinterlegt. Da es sich nicht um sensible Daten
handelt, kann bei dieser Anwendung auf eine Transaktionssicherheit zugunsten
der Performance verzichtet werden. Die Tabelle „audio“ enthält alle wichtigen
technischen Daten und die Metainformationen, die sich aus den Id3-Tags von Mp3Dateien auslesen lassen. Zusätzlich werden der relative Speicherpfad, eine Verknüpfung zum Benutzer, ein „deleted“-Flag, sowie Erstellungs- und Änderungszeit
Konzept
24
gespeichert. Nutzer sollen außerdem für jeden Titel Stichworte eingeben können.
Dafür werden zwei zusätzliche Tabellen angelegt, die eine m:n Verknüpfung realisieren.
Bei diesem Entwurf wird an einer Stelle bewusst die dritte Normalform verletzt,
was folgende Gründe hat: Die Attribute Künstler und Genre hängen theoretisch
direkt vom Album ab und müssten eigentlich in eine andere Relation ausgelagert
werden. Da aber nicht davon auszugehen ist, dass die Metainformationen aller zu
importierenden Audiodateien korrekt gepflegt sind, stellt dies ein Risiko beim
automatischen Import dar. Nur weil an einer Stelle der Künstlername falsch
geschrieben wurde, soll nicht ein weiterer Datensatz für ein Album angelegt werden, dass vielleicht schon existiert. Des Weiteren ist es möglich, dass eine Datei
zwar einen Künstler hat, aber zu keinem Album gehört. Aus diesen Gründen ist es
sinnvoller, die entsprechenden Attribute nicht auszulagern. Das hat zusätzlich den
Vorteil, dass die Datenstruktur einfacher bleibt und die Datenabfragen nicht durch
eine zusätzliche Verknüpfung verlangsamt werden.
Die Speicherung der Wiedergabelisten wird in zwei Tabellen aufgespalten. „playlists“ enthält Titel und den Besitzer. Die einzelnen Einträge werden in der Tabelle
„playlists_entries“ gespeichert. Hier wird auf die Audio-ID und die Wiedergabeliste
verwiesen. Eine Spalte „sorting“ ermöglicht das manuelle Sortieren von Einträgen.
Die Tabelle für den Benutzer besteht nur aus den wichtigsten Daten: E-Mail, Passwort und Upload-Verzeichnis sowie „deleted“-Flag und Erstellungs- und Änderungsdatum.
Die Datenbankstruktur als MySQL-Export befindet sich im Anhang D.
3.4.2 Schichtenarchitektur
Da der Client eine eigenständige Applikation mit MVC-Muster darstellt, entspricht
das hier verwendete Schema nicht dem normalerweise angewendeten Model 2Muster [FRE08, Seite 549], das von vielen Webseiten benutzt wird. Da außerdem
vom Server keine HTML-Seiten ausgeliefert werden (mit Ausnahme der Startseite),
Konzept
25
gibt es keine Notwendigkeit für eine serverseitige Präsentationsschicht. Stattdessen wird vor den eigentlichen Controller eine zusätzliche Schicht gesetzt. Das Frontend oder auch die Serviceschicht stellt eine austauschbare Schnittstelle zwischen
Client und serverseitigem Controller dar. Es ist für die Umwandlung der verschiedenen Daten zuständig und ruft nach erfolgreicher Authentifizierung den Controller auf, um die eigentlichen Aktionen auszuführen. Die zurückgegebenen Daten
werden wieder in das entsprechende Format umgewandelt und an den Client
übermittelt. Da der Server hauptsächlich für die Bereitstellung von Daten zuständig ist, enthalten die Models vor allem die nötigen Daten und weniger eine
Geschäftslogik. Die Persistenzschicht der Models (im Weiteren auch Backend
genannt) ist austauschbar und entkoppelt sie von der Art der Datenspeicherung.
Abbildung 7: Anwendungsschichten
Die zusätzliche Serviceschicht ist notwendig, um der geforderten Flexibilität im
Umgang mit verschiedenen Clients gerecht zu werden. So muss bei der Implementierung eines neuen Clients nur eine zusätzliche Frontend-Klasse erstellt werden,
die für die Implementierung eines Webservices und evtl. für die Auslieferung der
Client-Anwendung zuständig ist. Diese Struktur entspricht dem Adapter-Entwurfsmuster: „Das Adapter-Muster konvertiert die Schnittstelle einer Klasse in die
Schnittstelle, die der Client erwartet. Adapter ermöglichen die Zusammenarbeit
von Klassen, die ohne nicht zusammenarbeiten könnten, weil sie inkompatible
Schnittstellen haben“ [FRE08, Seite 243].
Konzept
26
Der Controller ist für die eigentliche Steuerung des Programmablaufs zuständig. In
ihm werden Models instanziiert und entsprechende Operationen aufgerufen. In
der Regel implementieren die Controller hauptsächlich CRUD6-Funktionen. Dazu
werden die Models entweder mit den Daten, die vom Frontend übergeben werden,
gefüllt oder die Daten werden aufgrund verschiedener Bedingungen über die Persistenzschicht geladen. Wie die Models wiederum mit der Persistenzschicht
zusammenarbeiten, ist für den Controller nicht sichtbar.
Die Aufgabe der verschiedenen Models in dieser Anwendung ist hauptsächlich die
Datenhaltung. Sie enthalten die benötigten Informationen über den Datentyp und
sind verantwortlich für die Validierung der Daten, bevor sie gespeichert werden.
Für das Lesen oder Schreiben der Daten, ist die zugewiesene Persistenzschicht
zuständig. Das jeweilige Backend kann über eine Konfigurationsdatei festgelegt
werden. Zusätzlich ist es möglich, das Backend zur Laufzeit zu ändern. Dies ist zum
Beispiel nötig, wenn verschiedene Quellen in einer Anwendung die Daten liefern.
Die Datenschicht sorgt für eine persistente Datenhaltung. Sie enthält die nötige
Logik, um aus übergebenen Parametern beispielsweise Datenbankbefehle zu generieren und sie auszuführen. Durch ein Austauschen dieser Schicht können auch
andere Datenquellen verwendet werden. Möglich wäre es, die Daten über einen
Webservice oder oder aus der Datenbank einer anderen Anwendung wie beispielsweise iTunes7 zu beziehen .
3.4.3 Server - Client Schnittstelle Ext Direct
Die aktuelle Version von Ext JS bietet die neue Schnittstelle Ext Direct, mit der man
direkt aus dem Javascript Quellcode heraus auf Funktionen des Servers zugreifen
kann [WWW10]. Dieses Verfahren soll die konkrete Schnittstelle zwischen Server
und Client bereit stellen. Der Vorteil dieser Vorgehensweise ist, dass bei der Programmierung des Clients auf sehr einfache Weise mit dem Server kommuniziert
werden kann. Ein weiterer Vorteil ist, dass mehrere Abfragen in zeitlich kurzen
6 CRUD steht für Create, Read, Update und Delete [WIKI07]
7 Medienbibliothek von der Firma Apple
Konzept
27
Abständen getätigt werden sollen, automatisch zu einem HTTP-Request zusammengefasst werden. Bei der Aktualisierung mehrerer Filter kann dies zum Beispiel
einen Performance-Vorteil bringen.
Um die erwähnten Funktionen für den Client zur Verfügung zu stellen, müssen in
der Serveranwendung drei Voraussetzungen geschaffen werden. Zunächst muss
definiert werden, welche Methoden aufrufbar sein sollen. Dann muss der Server
dem Client eine Liste verfügbarer Methoden zur Verfügung stellen. Um diese Funktionen dann auch wirklich aufrufbar zu machen, muss der Server die eingehenden
Anfragen an die entsprechenden Klassen und ihre Methoden weiterleiten.
Damit das Zend-interne Routing weiterhin verfügbar bleibt, wird diese Funktionalität in ein eigenes Modul ausgelagert.
3.4.4 Sicherheitsmechanismen
Liest man die Top-Ten der Sicherheitsprobleme in Webanwendungen der OWASP
(Open Web Application Security Project), fällt einem schnell auf, dass die meisten
Sicherheitslücken durch fehlende Überprüfung von eingehenden Daten entstehen
[WWW11]. Diese Aufgabe wird in der hier zu entwickelnden Webanwendung auf
verschiedene Schichten verteilt: Das Frontend muss überprüfen, dass eingehende
Parameter mit denen der aufzurufenden Controller übereinstimmen. Ist dies nicht
der Fall, wird ein entsprechender Fehler zurückgegeben. Im weiteren Programmverlauf muss in den Models eine Validierung der Daten stattfinden, sodass sie nur
an die Datenschicht weitergegeben werden, wenn sie den Erwartungen entsprechen. Ansonsten wirft das System eine Exception. Um Cross-Site-Scripting vorzubeugen, werden HTML-Zeichen von Strings maskiert, so dass keine fremden
HTML-Befehle und somit auch keine Script-Anweisungen in den Browser gelangen
können. Gleichzeitig muss die Datenschicht dafür sorgen, dass keine datenbankspezifischen Manipulationen möglich sind (Stichwort SQL-Injections [T3N, Seite
54]).
Konzept
28
Da die Anwendung nur für registrierte Benutzer zugänglich ist, muss bei jedem
HTTP-Request festgestellt werden, mit welchem Client der Server gerade kommuniziert und ob dieser dazu berechtigt ist. Um einen einmal authentifizierten Benutzer wieder zu erkennen, werden Cookies verwendet, die vom Client im HTTP-Header mitgesendet werden. Diese Überprüfung und die Initialisierung der Benutzerund Sitzungsdaten ist Aufgabe des Frontends. Schlägt die Authentifizierung fehl,
wird der Programmablauf abgebrochen.
3.4.5 Fehlerbehandlung
Es ist immer möglich, dass beim Programmablauf auf dem Server Fehler auftreten.
Damit der Benutzer trotz eines Fehlers eine Rückmeldung über diesen Umstand
erhalten kann, müssen die einzelnen Komponenten aussagekräftige Fehler werfen.
Diese Fehler werden vom Frontend abgefangen und an den Client zurückgegeben.
Der Client wiederum ist dafür zuständig, den Benutzer über den aufgetretenen
Fehler zu informieren und ihm ggf. Handlungsalternativen bereit zu stellen. So
kann zum Beispiel bei einem abgelaufenen Login eine Möglichkeit zum erneuten
Einloggen dargestellt werden.
3.4.6 Module
Um eine möglichst lose Kopplung zu erreichen, werden die Programmteile zusätzlich in Module eingeteilt. In jedem Modul werden die einzelnen Schichten implementiert, sie müssen im Wesentlichen eigenständig arbeiten können.
Es gibt nur ein übergeordnetes Module, von dem alle anderen abhängen: Das CoreModul beinhaltet Funktionalitäten und abstrakte Klassen, bzw. Interfaces, die von
allen anderen Modulen benutzt werden können und müssen. Es bildet die Grundlage für die Anwendung. Ein weiteres, für die erfolgreiche Benutzung der Anwendung benötigtes Modul ist ein aktiviertes Frontend-Modul, welches eine eigene
Schicht bildet und sich als Schnittstelle vor den Controllern der verschiedenen
Module befindet. In diesem Modul befinden sich lediglich Frontend-Controller, die
jeweils für die Implementation eines Services verantwortlich sind.
Konzept
29
3.4.7 Datenfluss
3.4.7.1 Client
Abbildung 8: Datenfluss Client
Die Schnittstelle der Ein- und Ausgabe von Daten in der Client-Anwendung entspricht der View-Komponente. Eingehende Daten werden nach erfolgreicher Validierung an den Controller übergeben. Genauer gesagt registriert sich der Controller beim View für entsprechende Ereignisse und holt sich die Daten beim Eintreffen derselben ab. Der Controller weiß, wie er mit diesen Daten umgehen soll und
manipuliert im Normalfall das Model. Das Model ist über die Ext Direct-Komponente mit dem Server verbunden. Aus Sicht des clientseitigen Models stellt Ext
Direct die Persistenzschicht dar. Wie der Server die Daten behandelt, ist hier nicht
erheblich. Wichtig für das Model ist, dass die Daten persistent vorliegen.
Ext Direct ist in der Lage mehrere Aufrufe parallel zu verarbeiten. Ein entsprechend zu definierendes Zeitintervall legt fest, wie lange gewartet wird, bevor ein
Request abgesendet wird. Die Antworten werden in der gleichen Reihenfolge weiterverarbeitet. Wirft der Server bei einem der Methodenaufrufe eine Ausnahme,
wird diese explizit abgefangen und dem Benutzer dargestellt (Anforderung
2.2.1.2). Im Erfolgsfall werden die Daten an das Model zurückgegeben, welches
wiederum eine Aktualisierung des Views zur Folge hat.
Konzept
30
3.4.7.2 Server
Abbildung 9: Datenfluss Server
Die serverseitige Anwendung nimmt alle eingehenden Daten über die FrontendSchicht auf. Diese sorgt für dem Aufruf des entsprechenden Controllers und die
Übergabe der Variablen. Der Controller hat die Möglichkeit, Models zu erstellen
und auf ihnen verschiedene Operationen auszuführen. Auf das Backend haben die
Controller keinen direkten Zugriff. Soll ein Model beispielsweise gespeichert werden, kommuniziert es selbst mit dem aktuellen Backend. Tritt hier irgendwo ein
Fehler auf (in der Regel beim Validieren der Models) fängt das Frontend diesen ab
und gibt die entsprechende Meldung an den Client zurück.
Entwicklung der Anwendung
31
4 Entwicklung der Anwendung
4.1 Serverseitige Programmierung
4.1.1 Start der Anwendung
4.1.1.1 Bootstrap-Datei und Htaccess
Die Anwendung wird bei jeder Anfrage über eine Bootstrap8 Datei gestartet. Damit
auch jeder Request von dieser Datei bearbeitet werden kann, wird in einer .htaccess-Datei9 eine „RewriteRule“ definiert, die jede Anfrage, die nicht auf eine Bildoder Javascript-Datei zeigt, an die „index.php“ weiterleitet. In letzterer werden
lediglich die Pfade zu den Klassendateien definiert. Mit einem Aufruf der statischen
Methode „Mel::run()“ wird die Applikation gestartet.
4.1.1.2 Initialisierung
In der beschriebenen Funktion „Mel::run()“ wird zunächst der Zend-Autoloader
initiiert. Dieser sorgt im folgenden Ablauf dafür, dass Dateien automatisch inkludiert werden, wenn ein Objekt der beinhaltenden Klasse erstellt wird. Damit der
Autoloader funktioniert, ist es wichtig, dass die Dateinamen mit den Klassennamen
überstimmen (siehe 3.2.3 ).
Die Startklasse „Mel“ fungiert gleichzeitig als zentrales Register. Hier wird zum
Beispiel das Datenbankobjekt abgelegt, welches die Zugriffe zur Datenbank steuert.
4.1.1.3 Konfiguration
Im Konfigurationsverzeichnis befinden sich drei Dateien, in denen sich Konfigurationen einstellen lassen:
8 Als „Bootstrapping“ bezeichnet man das Starten einer Anwendung durch ein Startscript.
[WIKI15]
9 Mit .htaccess-Dateien lassen sich verzeichnisweise Einstellungen für den Apache-Webserver
vornehmen. [WWW12]
32
Eine Datei ist dafür zuständig, die Verbindungsparameter für die Instanziierung
des Datenbankobjekts zur Verfügung zu stellen. Hier werden der Adapter und die
Zugangsdaten zur Datenbank definiert.
In der Datei „app.php“ werden alle Einstellungen für die Anwendung vorgenommen. Hier sind viele Parameter einzustellen, auf die die einzelnen Module später
zurückgreifen können.
In einer Sprachdatei werden schließlich Benennungen von einzelnen GUI-Komponenten definiert. So werden sie von der eigentlichen Anwendung abgekoppelt und
lassen sich später einfach ändern.
Alle Konfigurationsdateien verfügen über ein Format, dass sich durch die PHP
Funktion „parse_ini_file()“ auslesen lässt.
4.1.1.4 Aufruf der Front-Controller
Für das Routing und Aufrufen der Front-Controller wird die im Zend Framework
enthaltene Klasse „Zend_Controller_Front“ verwendet. Sie ist Teil des integrierten
MVC-Patterns und ruft einen Dispatcher [WWW13] auf, der die Initialisierung der
Front-Controller übernimmt und die entsprechenden Aktionen ausführt.
http://www.domain.tld/[module]/[controller]/[methode]/
Der erste Teil des Url-Pfads unter der Hauptseite gibt das aufzurufende Modul an.
Dieser Parameter ist optional, als Fallback-Variante wird immer das Default-Modul
ausgewählt (einzustellen über die Konfigurationsdatei). Der zweite Teil gibt den
aufzurufenden Front-Controller und der dritte die aufzurufende Methode an.
4.1.1.5 Authentifizierung
Ein Plugin im Dispatcher leitet das Routing zur Laufzeit mit Berücksichtigung auf
die (nicht) vorhandene Autorisierung ggf. um. Falls Benutzername und Passwort
angegeben wurden, wird überprüft, ob die Kombination gültig ist. Bei erfolgreicher
Prüfung der Zugangsberechtigung, wird ein Objekt mit den Daten des Benutzers
erstellt und in der Registry gespeichert. Falls die Autorisierung fehlgeschlagen ist,
wird überprüft, ob der Controller eine Authentifizierung verlangt. Wenn dies der
33
Fall ist, wird das Routing auf eine Methode umgelenkt, die die entsprechende Meldung an den Benutzer zurück gibt. Dazu muss der Controller das Interface
„Mel_Core_FrontendController_Interface“ implementieren.
4.1.2 Front-Contoller/Views
Die Funktion der Views wird in dieser Anwendung nur bei der Auslieferung der
Startseite und einiger statischer Informationsseiten verwendet. Die eigentliche
Benutzeroberfläche wird durch den Javascript-Quellcode im Browser erzeugt.
Beim Ausliefern von Daten wird die Funktionalität des Views serverseitig nicht
benötigt. Die Front-Controller müssen lediglich dafür sorgen, dass die Daten im
entsprechenden Format ausgegeben werden.
Die Front-Controller bieten den Einstiegspunkt für die eigentliche Anwendung. Sie
sind abgeleitet von der Klasse „Zend_Controller_Action“ und werden vom Dispatcher aufgerufen. In der Initialisierungs-Methode kann definiert werden, ob der
Controller einen View zur Ausgabe benötigt oder nicht. Des Weiteren können Helfer initialisiert werden, die in den View-Scripten zur Verfügung stehen sollen.
View-Scripte bestehen aus PHTML-Dateien, die sowohl HTML als auch PHP-Code
enthalten können. Sie werden von den Front-Controllern ggf. automatisch inkludiert und können auf Variablen zugreifen, die dem View im Controller zugeteilt
wurden.
Grundsätzlich unterschieden wird zwischen geschützten Front-Controllern, die
Methoden implementieren müssen, die bei fehlgeschlagener Authentifizierung aufgerufen werden und solchen, die keine weitere Zugriffskontrolle benötigen.
4.1.3 Controller
Die eigentlichen Controller der Anwendung können von den Front-Controllern aufgerufen werden. Die Controller implementieren aus zwei Gründen das Singleton
Entwurfsmuster [SCH09, Seite 164-172]: Zum einen wird pro Serveraufruf nur
eine Instanz des Controllers benötigt. Bei mehreren Aufrufen kann so Speicher
34
gespart werden. Zum anderen kann durch das Singleton-Pattern eine verlässliche
Zugriffskontrolle realisiert werden. Die statische Methode „getInstance()“, die eine
Instanz der Klasse zurückgeben soll, tut dies nur, wenn ein gültiges BenutzerObjekt initialisiert wurde. Andernfalls wird eine Exception geworfen und keine
Instanz zurückgegeben, da sonst trotz Exception weiter mit der Instanz gearbeitet
werden könnte. Bei Controllern, die keine Zugriffskontrolle benötigen, kann dieses
Verhalten mit Hilfe eines zusätzlichen Parameters in der zu implementierenden
Methode „getInstance()“ unterdrückt werden.
Abbildung 10: UML Diagramm - Umsetzung Singleton Pattern
Welche Methoden generell vom Client aufgerufen werden dürfen, wird durch
Annotations festgelegt, die in PHP in Form von PHP-Doc-Kommentaren realisiert
werden können [SCH09, Seite 141]. Diese Kommentare können mit Hilfe von
Reflections10 ausgelesen werden. Webservices (als Front-Controller) nutzen die so
gewonnenen Informationen, um eine dynamische Liste der zur Verfügung stehenden Methoden zu erstellen.
10 PHP stellt Möglichkeiten zum Auslesen von Klasseninformationen bereit [WWW14].
4.1.4 Models/Filter
Abbildung 11: UML Sequenzdiagramm - Controller, Models, Backend
35
36
Die Geschäftslogik der Anwendung besteht im Wesentlichen aus fünf verschiedenen Arten von Models: Das ist zum einen das Item, welches einen einzelnen Datensatz repräsentiert und die List, die eine Sammlung von Items enthalten kann. Weitere Models dienen der Kommunikation zwischen List und Backend: Das RequestObjekt teilt der Datenhaltungschicht in einer einheitlichen Form mit, welche Parameter bei der Datenabfrage berücksichtigt werden sollen. Dieses Request-Objekt
kann verschiedene Typen von Filter-Objekten enthalten, welche Bedingungen für
die zurückzugebenden Daten enthalten. Als Ergebnis liefert das Backend ein
Response-Objekt, welches die List zur Initialisierung der Items verwendet.
4.1.4.1 Items
Abbildung 12: UML Mel_Core_Model_Item_Abstract
Items haben die Aufgabe, einen einzelnen Datensatz zu repräsentieren. Welche Felder und Feldtypen ein Item enthält, wird in der zentralen Konfigurationsdatei definiert. Auch Verknüpfungen mit anderen Items können in der Konfiguration angegeben werden.
Das Backend, mit dem das Item zum Lesen und Schreiben kommuniziert, kann
konfiguriert werden. Sollte es nötig sein, das Backend während der Laufzeit zu
wechseln, kann das über die Methode „setBackend()“ realisiert werden.
37
Ein Item lässt sich durch verschiedene Methoden initiieren: Es gibt die Möglichkeit,
nur einen eindeutigen Bezeichner oder eine andere Bedingung anzugeben, die an
das Backend weitergereicht wird. Alle Daten werden in diesem Fall vom Backend
zur Verfügung gestellt. Wenn ein neuer Datensatz erstellt oder ein bestehender
verändert werden soll, kann das Item durch ein Array mit Key/Value Paaren mit
Werten befüllt werden.
Bevor ein Item zum Speichern an das Backend weitergegeben werden kann, müssen die enthaltenen Daten validiert werden. Dazu werden die vom Zend Framework zur Verfügung gestellten Validatoren verwendet, die einheitliche Interfaces
für verschiedene Datentypen zur Verfügung stellen. Soll ein Item gespeichert werden und es ist nicht valide, wird eine Exception mit den entsprechenden Validierungsfehlern geworfen.
38
4.1.4.2 Listen
Abbildung 13: UML-Diagramm - Zusammenhang List und Item
Listen repräsentieren einen Satz von Items. Sie stellen gleichzeitig die Schnittstelle
zum Backend dar, um sie zu laden. Genauso wie bei den Items lässt sich das
Backend konfigurieren und zur Laufzeit austauschen. Um dem Backend mitzuteilen, welche Daten geladen werden sollen, wird vom Controller ein Request-Objekt
angefordert, welches bearbeitet werden kann und dann über eine commit-Funktion der List an das Backend zur Datenabfrage weitergereicht wird. Das Backend
gibt ein Response-Objekt zurück, das die angefragten Daten enthält. Aufgrund dieses Objekts initialisiert die Liste die einzelnen Items, auf die im weiteren Verlauf
zugegriffen werden kann.
Die abstrakte Klasse „Mel_Core_Model_List“ implementiert das Iterator-Muster,
welches es möglich macht, über die enthaltenen Elemente mit einer foreachSchleife zu iterieren [FRE08 Seite 316-386].
Das Speichern einer Liste wird an die einzelnen Items delegiert.
39
40
4.1.4.3 Request
Abbildung 14: UML Diagramm - Request und Filter
Ein Problem der konzeptionierten Schichtenarchitektur ergibt sich dadurch, dass
der Controller keine Kenntnis über das verwendete Backend besitzt. Demzufolge
lassen sich keine SQL-Abfragen aus dem Controller heraus erstellen, die die
gewünschten Daten von der Datenbank abfragen. Damit nicht für jede Abfrage eine
neue Methode in List und Backend erstellt werden muss, die die Daten über eine
maßgeschneiderte SQL-Abfrage liefert, wurde das Request-Objekt entwickelt. Es
41
fungiert als Vermittler zwischen Controller und Backend, welcher von der List
initialisiert wird und danach vom Controller mit den gewünschten Parametern
befüllt wird. Danach wird das Request-Objekt vom Controller zurück an die Liste
gegeben, die es dann wiederum mit ihrem Backend gegen die zurückzugebenden
Daten austauscht.
Das Request-Objekt wurde in Anlehnung an das „Zend_Db_Select“-Objekt [MOE08,
Seite 78-88] entwickelt, welches eine objektorientierte Erstellung von SQL-Abfragen ermöglicht.
Das hier verwendete Abfrage-Objekt unterstützt dagegen keine SQL-spezifischen
Funktionen. Es kennt lediglich die vorhandenen Datenfelder (Konfiguration der
Items). Diese werden ihm beim Initialisieren von der List übergeben. Sie werden
zur Validierung der vom Controller angeforderten Daten benötigt.
Der Controller kann folgende Parameter im Request-Objekt einstellen (in Klammern jeweils der korrespondierende MySQL-Befehl):
– Es kann ausgewählt werden, welche Datenfelder ausgelesen werden sollen
(SELECT).
– Es können Filter hinzugefügt werden, aus denen das Backend AbfrageBedingungen generiert (WHERE).
– Es kann definiert werden wie viele Datensätze ab welcher Stelle abgefragt
werden sollen (LIMIT).
– Es kann eine Sortierung angegeben werden (ORDER BY).
– Es kann angegeben werden, nach welchem Feld gruppiert werden soll
(GROUP BY).
– Eltern-Datensätze eines Feldes mit eigenem Model können über loadParentData() geladen werden (einfache Variante von JOIN).
42
In der Liste der gängigen SQL-Befehle zum Abfragen von Datensätzen fehlen hier
nur FROM (um anzugeben, welche Tabelle abgefragt werden soll) und die verschiedenen Varianten von JOIN. Beide verlangen (mit Ausnahme der im letzten Stichpunkt genannten) Kenntnisse über die Datenstruktur. Diese soll aber unabhängig
von der Anwendung sein (siehe 2.2.3.3). Deshalb muss das Backend die dafür
benötigten Informationen selber generieren.
4.1.4.4 Filter
Zur Generierung der Bedingungen der Abfrage in einem Response-Objekt werden
Filter eingesetzt, die über ein einheitliches Interface
(„Mel_Core_Model_Filter_Interface“) verfügen. Die Filter werden über die statische
Methode einer Klasse zum Initialisieren der verschiedenen Typen erstellt (Fabrik),
die aus dem zu übergebenen Filternamen und der Konfiguration einen neuen Filter
erzeugt und zurück gibt.
Name
Parameter
Beschreibung
SQL-Befehl
IsEqual
Feldname,
Das Feld muss einen bestimmten
field = value
Wert
Wert haben.
Feldname,
Das Feld muss mit einem Teil des
Wert
Wertes übereinstimmen.
Feldname,
Das Feld, muss mit einem der
field IN (value1,
Werte
Werte übereinstimmen.
value2 ...)
Wert
Ein durchsuchbares Feld muss
field1 LIKE value OR
dem Wert entsprechen.
field2 = value ...
IsLike
IsIn
Search
field LIKE value
Tabelle 1: Liste der implementierten Filter
Jeder Filter muss eine „isValid()“-Methode implementieren, die aufgrund der übergebenen Feldnamen feststellen kann, ob die Filterbedingung über ein gültiges Feld
filtert. Das Backend hat die Aufgabe, gültige Filter in die Datenabfrage einzubeziehen.
43
4.1.4.5 Response
Das Response-Objekt enthält eine Reihe von Datensätzen, mit denen eine Liste ihre
Items erstellen kann. Als weiteres Attribut wird die zur Verfügung stehende
Gesamtzahl der Einträge mitgeführt. Das Objekt ist die Rückgabe eines Request
von der List an das Backend. Es bildet eine einheitliche Schnittstelle zwischen den
beiden Schichten.
4.1.4.6 Verwendete Entwurfsmuster
4.1.4.6.1 Fluent Interfaces
Alle Klassen der Domänenschicht sind mit Fluent Interfaces ausgestattet. Das
bedeutet, dass alle Methoden, die eigentlich ohne Rückgabewerte auskommen,
eine Referenz des Objekts („$this“) zurückgeben. So ist es möglich, mehrere Funktionsaufrufe miteinander zu verketten, ohne für jeden Aufruf eine neue Zeile Quellcode beginnen zu müssen. Das macht den Quelltext schlanker und leichter les- und
wartbar. [WIKI08]
4.1.4.6.2 Lazy Acquisition
Die verschiedenen Models machen Gebrauch vom Entwurfsmuster Lazy Acquisition. [WWW15] So werden Objekte und Daten erst dann geladen, wenn sie wirklich
benötigt werden. Als Beispiel sei hier die Initialisierung des Backends genannt:
Angenommen, eine Liste initialisiert eine Reihe von Items mit Hilfe den vom
Backend gelieferten Daten, um Sie an das Frontend weiterzugeben. Ohne Lazy
Instantiation würde jedes Item sein eigenes Backend initiieren, ohne dass es im
weiteren Verlauf benötigt wird. Um dies zu verhindern, wird das Backend immer
erst beim ersten Aufruf der zugehörigen Getter-Methode „getBackend()“ initialisiert. Das spart in vielen Fällen Ressourcen und verringert die Scriptlaufzeiten
(Anforderung 2.2.7.1).
Auch die Felddefinitionen und Validatoren werden auf diese Art und Weise geladen.
44
4.1.5 Backend
4.1.5.1 Definition der Schnittstelle
Die Persistenzschicht hat die Aufgabe, eine zuverlässige Datenspeicherung und
Datenabfrage zu gewährleisten. Über festgelegte Schnittstellen können die Daten
mit der Anwendungsschicht ausgetauscht werden. Alle Backend-Klassen müssen
das Interface „Mel_Core_Backend_Interface“ implementieren.
Zur Abfrage von Daten werden zwei Grundfunktionen verwendet. Für die Abfrage
einzelner Datensätze wird entweder eine ID oder ein anderes Wert-Attribut-Paar
an das Backend als Parameter übergeben. Diese Methode ist für das Initialisieren
einzelner Items vorgesehen. Die Methode „getResult()“ erwartet ein RequestObjekt. Dieses muss vom Backend ausgelesen werden und bei der Abfrage der
zugrunde liegenden Ressource berücksichtigt werden. Als Rückgabewert wird ein
Response-Objekt mit den einzelnen Datensätzen und einer Gesamtanzahl der mit
den entsprechenden Filtern zur Verfügung stehenden Datensätzen erwartet.
Für die Speicherung muss jedes Backend öffentliche „update()“- und „create()“Methoden implementieren. Als Eingabeformat wird ein Objekt des Typs
„Mel_Core_Model_Item_Interface“ erwartet.
4.1.5.2 Implementierung
Das für die Anwendung entwickelte Backend greift auf eine MySQL-Datenbank
zurück. Es wurde eine abstrakte Klasse entwickelt, die die Grundfunktionalitäten
für das Lesen und Speichern in unterschiedlichen Tabellen zur Verfügung stellt. In
den abgeleiteten Klassen müssen lediglich einige Konfigurationsparameter wie
Tabellenname und spezielle Felddefinitionen für verknüpfte Tabellen erstellt werden. Für Anforderungen, die nicht von der abstrakten Klasse abgedeckt werden,
können vorhandene Methoden überladen oder hinzugefügt werden.
Die aufwändigste Aufgabe, die das Backend in diesem Fall zu leisten hat, ist die allgemeine Umwandlung des Request-Objekts in eine passende SQL-Abfrage. Für das
Erstellen der SQL-Abfrage wird eine Erweiterung der schon in Kapitel 4.1.4.3
45
erwähnten Klasse „Zend_Db_Select“ verwendet. Um die Abfrage generieren zu können, wird eine Kenntnis der verwendeten Datenstruktur benötigt. Wie sich diese
gestaltet, kann in der Konfigurationsdatei (siehe 4.1.5.3)definiert werden.
Nach der Erstellung des Select-Objekts wird aufgrund der Konfiguration evaluiert,
welche vom Request-Objekt geforderten Felder in der Haupttabelle liegen. Als
nächstes werden die Werte des Paginators an das Select-Objekt übergeben und die
Filter in WHERE-Bedingungen umgewandelt. Eventuell angegebene Gruppierungsfelder werden ebenfalls an das Select-Statement übergeben.
Falls die Datenstruktur Besonderheiten aufweist, die sich nicht durch die vorhandenen Konfigurationsmöglichkeiten abbilden lassen, wird zusätzlich eine Methode
aufgerufen, die von den abgeleiteten Klassen überschrieben werden kann. In dieser Methode kann das so erstellte Select-Objekt individuell manipuliert werden.
Für das Abfragen einzelner Datensätze werden einfache Select-Statements erstellt,
die den geforderten Bedingungen der Abfrage gerecht werden. Falls diese Bedingungen auf mehrere Datensätze zutreffen, wird der Erste zurückgegeben.
Das Anlegen und Aktualisieren von bestehenden Datensätzen erfolgt über die
„update()“- und „insert()“-Methoden des MySQL-Adapters. Die aktualisierten
Daten werden an den Aufrufer zurückgegeben.
4.1.5.3 Konfiguration
Grundlage der Konfiguration bilden die Felder des übergeordneten Items. Für alle
Felder, in denen für das Backend nichts anderes definiert wurde, wird davon ausgegangen, dass sie sich mit dem gleichen Namen in der definierten Stammtabelle
befinden. Wenn ein Feld auf eine andere Weise abgefragt werden muss oder sich
zusätzliche Daten in einer verknüpften Tabelle befinden, lässt sich dies mit den in
Tabelle 2 aufgeführten Parametern konfigurieren.
Parameter
Mögliche
46
Beschreibung
Werte
tableField
Spaltenname Weicht der Name der Spalte in der Tabelle von dem
einer Tabelle Feldnamen ab, kann der Spaltenname hier
eingetragen werden.
parentTable
table
Gültige
Tabelle, in der sich übergeordnete Informationen
MySQL-
befinden – Wie die Tabelle verknüpft wird, muss in
Tabelle
dem Parameter tableWhere angegeben werden.
Gültige
Tabelle, in der sich das Feld befindet. Wie die Tabelle
MySQL-
verknüpft wird, kann in dem Parameter tableWhere
Tabelle
angegeben werden. Wenn es zusätzlich eine
mxmTable gibt, muss tableWhere nicht angegeben
werden.
mxmTable
tableWhere
Gültige
Tabelle, über die eine Verknüpfung zu table
MySQL-
hergestellt wird. Die Bedingung dafür muss in
Tabelle
mxmWhere angegeben werden.
Gültiger
Bedingung für die Verknüpfung mit parentTable
MySQL-
oder table
Ausdruck
mxmWhere
Gültiger
Bedingung für die Verknüpfung mit mxmTable und
MySQL-
table
Ausdruck
searchable
true/false
Ist dieses Feld gesetzt, wird es bei einer Suchabfrage
berücksichtigt.
Tabelle 2: Liste der verfügbaren Konfigurationseinstellungen für Datenfelder
4.1.6 Module
4.1.6.1 Core
Das Core-Modul enthält alle Klassen und Interfaces, die für die grundlegenden
Funktionalitäten der verschiedenen Anwendungsschichten und deren Kommunikation untereinander benötigt werden. Das sind im Wesentlichen abstrakte Klassen, die die zugehörigen Interfaces implementieren und von anderen Modulen
47
durch Vererbung verwendet werden können. Zusätzlich befinden sich hier konkrete Implementierungen der Klassen für die Kommunikation zwischen den verschiedenen Schichten (z.B. Request und Response sowie Filter) und Klassen, die
modulübergreifende Funktionen zur Verfügung stellen. Dazu gehören Helfer-Funktionen für die Initialisierungs- und Registry-Klasse Mel und die gesamte Logik der
Benutzersteuerung. Auf die einzelnen Klassen wird hier nicht weiter eingegangen,
da sie in den vorhergehenden Abschnitten bereits beschrieben wurden.
4.1.6.2 Ext
Das Modul Ext stellt alle Funktionalitäten zur Verfügung, die für die Auslieferung
des auf Ext JS basierenden Clients benötigt werden. Dazu gehören im Wesentlichen
die Frontend-Controller sowie einige Helfer und View-Scripte.
4.1.6.2.1 Der Index-Controller
Der Index-Controller ist für die Auslieferung der Webseite zuständig und implementiert das Interface „Mel_Core_FrontendController_Interface“. Das bedeutet,
dass er die nötigen Methoden zum Einloggen implementieren muss und nur bei
authentifizierten Benutzern die eigentlichen Methoden aufgerufen werden können.
Hat der Benutzer sich über die Login-Maske autorisiert, wird die eigentliche IndexSeite dargestellt. Diese besteht aus einer normalen HTML-Seite mit inkludierten
JavaScript- und CSS-Dateien, die über die Konfigurationsdatei festgelegt werden
können. Über einen Autoload-Konfigurationsparameter können alle JavascriptDateien eines bestimmten Verzeichnisses automatisch einbezogen werden und
müssen nicht einzeln angegeben werden.
Im Hauptteil des HTML-Markups steht lediglich eine Meldung, die dem Benutzer
mitteilt, dass die Applikation geladen wird. Denn die eigentliche Benutzeroberfläche wird durch den Aufruf der clientseitigen Anwendung erstellt. Bei diesem Aufruf werden die Konfigurationseinstellungen und einige Initialisierungsparameter
vom Server an den Client übergeben.
Eine zusätzlich Methode erstellt eine Sprachdatei, über die sich das Vokabular des
Clients einstellen lässt.
48
4.1.6.2.2 Ext Direct
Ext JS stellt mit Ext Direct eine Technologie zur Verfügung, mit der serverseitige
Funktionen vom Client aus direkt aufgerufen werden können (siehe 4.2.6 ). Um
dieses Verhalten zu ermöglichen, muss der Server zwei Anforderungen erfüllen: Er
muss dem Client eine Liste der zur Verfügung stehenden Methoden anbieten (API)
und er muss bei eingehende Anfragen, die entsprechenden Methoden auf dem Server aufrufen und im JSON-Format11 zurückgeben (Routing). Diese beiden Funktionalitäten sind im Direct-Controller implementiert. Grundlage dafür bildet eine von
Tommy Maintz entwickelte Bibliothek12, die an einer Stelle leicht erweitert wurde.
Um die API zu erstellen, muss ein Objekt des Typs „ExtDirect_API“ instanziiert werden, dem einige Parameter übergeben werden. Mit der Methode „add()“ kann man
ein Array von Klassennamen übergeben, die vom Client aus aufrufbar sein sollen.
Den Methoden dieser Klasse müssen bestimmte PHP-Doc Kommentare vorangestellt werden, damit sie erkannt werden (siehe 4.1.3 letzter Absatz). Damit das
Auslesen der PHP-Doc-Kommentare nicht bei jedem Aufruf neu gestartet werden
muss, werden die Ergebnisse in einer Datei zwischengespeichert und nur bei
Änderungen erneuert.
Die so erstellte API wird als Javascript-Datei in den Header der Hauptseite eingebunden und steht somit der clientseitigen Anwendung zur Verfügung.
Anfragen des Clients an die serverseitige Anwendung werden von der Methode
„indexAction()“ des Front-Controllers angenommen. Der Router „Mel_Ext_Router“
kümmert sich um die Erstellung der benötigten Objekte, das Aufrufen der
gewünschten Methode und das Zurückgeben des Ergebnisses an den Browser. Tritt
bei der Ausführung der Methode ein Fehler auf, wird dieser von einem Try-CatchBlock abgefangen und kann so als Fehlermeldung zurückgegeben werden. Der Client hat daraufhin die Möglichkeit, entsprechend auf den Fehler zu reagieren. Die
Klasse „Mel_Ext_Router“ ist eine Erweiterung von „ExtDirect_Router“, die die
11 JSON steht für JavaScript Object Notation und wird für den Datenaustausch zwischen Server
und Client eingesetzt. [FLA07, Seiten 538-539]
12 Eine Liste verschiedener „Server-side-Stacks“ für Ext Direct wird im Forum von Ext JS frei zur
Verfügung gestellt. [WWW16]
49
Methode „rpc()“ (Abk. für remote procedur call) überlädt. Dies war nötig, da die
aufzurufenden Controller das Singleton Pattern implementieren und nicht über
den „new“-Operator, sondern nur über die statische Methode „getInstance()“
initialisiert werden können. Zusätzlich wurde zu der im Fehlerfall generierten Antwort der Typ der geworfenen Exception hinzugefügt.
4.1.6.3 Audio, Playlist und Import
Das Modul Audio ist zuständig für die Verwaltung der Musikdatenbank. Es stellt
dem Client die zum Abspielen, Filtern und Anzeigen benötigten Daten zur Verfügung und bietet zudem die Möglichkeit einzelne oder mehrere Datensätze zu verändern. Dementsprechend finden sich in diesem Modul alle serverseitigen Anwendungsschichten mit Ausnahme des Frontends wieder.
Die serverseitige Anwendungslogik für die Funktionen rund um die Wiedergabelisten steckt in dem Modul Playlist.
Die Importfunktion der Audiodateien wurde in ein eigenes Modul ausgelagert. Hier
werden die einzelnen Dateien ausgelesen. Mit Hilfe einer externen Bibliothek13
werden die Id3-Metatags ausgewertet und entsprechende Audio-Items erstellt und
gespeichert.
4.1.7 Helfer
4.1.7.1 Debugging
Für das Debugging einer Ajax-Applikation eignen sich keine normalen Befehle zum
Ausgeben von Variablen (z.B. „echo()“ oder „print_r()“), da sie das Format der
zurückgegeben Daten zerstören und so in der Client-Anwendung einen Fehler produzieren würden. Als Alternative bietet sich eine Extension namens Firephp14 für
13 Weitere Informationen zur verwendete Bibliothek GetId3 finden sich auf der Projektseite
www.getid3.org [WWW17]
14 Firebug [WWW18] ist ein Tool für Webentwickler, mit dem der im Browser generierte Quelltext
inspiziert, Javascript debuggt und Ajax-Requests verfolgt werden können. Mit der Extension
FirePHP [WWW19] können zusätzlich serverseitige Variablen in der Konsole angezeigt werden.
50
den Firefox an, mit der sich Variablen anzeigen lassen, die im HTTP-Header mitgesendet werden. Um diese Header zu erzeugen stellt das Zend Framework einen
Klasse zur Verfügung, die in der Medienbibliothek Anwendung findet.
4.1.7.2 Minify
Um die Performance der Auslieferung der Anwendung an den Client zu steigern
wird die Applikation Minify [WWW20] verwendet. Sie erlaubt das serverseitige
Komprimieren und Zusammenfügen von Javascript- und CSS-Dateien.
4.2 Clientseitige Anwendung
4.2.1 Initialisierung
Die Initialisierung des User-Interfaces erfolgt über einen Aufruf der Starter- und
Registry-Klasse „Mel“. Die Instanz des Objekts wird in einer globalen Variable
abgelegt und ist so von allen Stellen der Anwendung aus erreichbar.
Beim Aufruf wird ein Start-Controller festgelegt, der für die eigentliche Initialisierung der Controller, Models und GUI-Komponenten zuständig ist.
4.2.2 Zusammenspiel der MVC-Komponenten
Wie im Konzept unter 3.3.3 nachzulesen ist, basiert die clientseitige Anwendung
auf dem MVC-Konzept. Die Ausgestaltung dieses Konzepts wird im Folgenden kurz
beschrieben, um die anschließenden Abschnitte leichter verständlich zu machen.
Jede GUI-Komponente wird durch ein Triple von Controller, Model und View repräsentiert. Der Controller ist für die Initialisierung zuständig und bietet Schnittstellen für andere Komponenten. Jeder Controller initialisiert eine Instanz des zugehörigen Models. Im Model werden wiederum die einzelnen Teile der GUI-Komponente initiert. Controller und View implementieren das Observer-Muster. Der View
ist in diesem Fall das Beobachtungssubjekt, welches allen Beobachtern Mitteilungen macht, sobald der Benutzer eine bestimmt Aktion ausgeführt hat. Der Control-
51
ler registriert sich beim View, um auf diese Ereignisse mit einem Methodenaufruf
zu reagieren. Innerhalb des Aufrufs lassen sich der Status des Models oder direkt
andere View-Komponenten anpassen.
4.2.3 Controller
In der Anwendung gibt es drei verschiedene Arten von Controllern. Die Start-Controller sind zuständig für die Initialisierung von Ext Direct und die Erstellung des
Viewports (Grundlayout). Die einzelnen Komponenten des Viewports werden von
den untergeordneten Controllern erstellt. Die Instanzen der verschiedenen Controller werden in dem Registry-Objekt „MEL“ gehalten und können so als Singletons aufgerufen werden. Die Controller der einzelnen Tabs der Anwendung (siehe
2.1.1.8) sind keine Singletons, da für jeden Tab ein eigener Controller zuständig ist.
Die einzelnen Controller können über das Model des übergeordneten Tabs-Controllers angesprochen werden (hier werden die Instanzen gehalten). Die verschiedenen Controller können sich bei den zugehörigen View-Komponenten für Benutzeraktionen registrieren und so darauf reagieren. Die Controller selbst sind
zustandslos, Statusinformationen werden im Model gespeichert.
4.2.4 Models
Die Models beinhalten die eigentliche Anwendungslogik. Sie erstellen die benötigten Komponenten des Views und bieten Schnittstellen für Controller an, um Statusänderungen zu vollziehen bzw. bestimmte Aktionen auszuführen. Sie können bei
Zustandsänderungen direkt auf den untergeordneten View zugreifen und ihn so
manipulieren.
52
4.2.5 View
Abbildung 15: Baumstruktur der View-Komponenten
Die einzelnen View-Komponenten erweitern in der Regel bestehende Ext JS-Komponenten. Dabei handelt es sich hauptsächlich um verschiedene Formen von PanelObjekten, die in einer Baumstruktur (Composite-Muster15, siehe Abbildung 15)
angeordnet sind. Diese Baumstruktur findet sich auch in der Benennung/Ordnerstruktur wieder, so dass einzelne Komponenten leicht wieder zu finden sind. In
Tabelle 3 sind die erweiterten View-Komponenten aufgelistet.
15 Die Baumstruktur des View entspricht dem Composite-Entwurfsmuster [FRE08, Seite 533]
Name
Funktion
Viewport
Der Viewport bildet das oberste Element der GUI-Komponenten.
53
Verschiedene Grundlayouts können definiert werden. Er bildet das
Gerüst für die untergeordneten Elemente.
Panel
Ein einfaches Panel kann verschiedene Inhalte darstellen oder
weitere Panels beinhalten.
TabPanel
Ein TabPanel kann mehrere Panels enthalten, zwischen denen über
Reiter hin- und hergeschaltet wird.
EditorGrid
Das EditorGrid ist die Erweiterung eines Panels. Es stellt Daten in
Form einer Tabelle (Grid) dar. Wie die Daten darzustellen und zu
laden sind, wird in den enthaltenen Store- und ColumnModelObjekten definiert.
DirectStore
Der DirectStore lädt Daten über eine Schnittstelle vom Server und
stellt sie dem Grid zur Verfügung.
ColumnMod Im ColumnModel werden die Datenformate und spezielle
el
Darstellungsoptionen für die einzelnen Spalten eines Grids
definiert.
Toolbar
Eine Toolbar bietet die Möglichkeit, einzelne Buttons oder
Dropdown-Menüs in den oberen Teil eines Panels einzubinden.
Flashpanel
Das Flashpanel ist eine Erweiterung von Ext JS, mit der sich
Flashobjekte einbinden lassen.
Tabelle 3: Verwendete View-Komponenten der Ext JS Library
4.2.6 Ext Direct
Die Nutzung der „Remoting API“ Ext Direct mit Ext JS gleicht einem normalen
Funktionsaufruf. Über einen zu definierenden Namensraum können die serverseitig implementierten Methoden der verschiedenen Controller aufgerufen werden.
Zusätzlich zu den Parametern, die an den Server weitergegeben werden, kann eine
Callback-Funktion angegeben werden, die den Rückgabewert weiterverarbeitet.
Der aufgerufenen Javascript-Funktion ist es nicht möglich den entsprechenden
Wert direkt zurückzugeben, da die Kommunikation via Ajax asynchron ist.
[WWW21] Werden mehrere Aufrufe innerhalb eines bestimmten Intervalls getä-
54
tigt, sorgt Ext Direct dafür, dass sie zusammen in einem einzigen Ajax-Request
abgesendet werden. Das verringert nicht nur den Datenverkehr und die Serverlast,
sondern hat zusätzlich den Vorteil, dass die Reihenfolge der Bearbeitung auf dem
Server mit relativ großer Wahrscheinlichkeit erhalten bleibt und auch der Client
die Callback-Funktionen in entsprechender Reihenfolge aufruft. Hierdurch kann
z.B. das Aktualisieren eines Datensatzes und das Laden des aktualisierten Datenbestandes direkt hintereinander erfolgen. Würde man zwei einzelne Ajax-Requests
hintereinander ausführen, dürfte der zweite Aufruf erst bei Rückkehr des ersten
geschehen, da sonst nicht ausgeschlossen werden könnte, dass der zweite den ersten überholt. So würden die veralteten Daten zurückgegeben werden, was zu
Inkonsistenzen der Datenbestände führen würde.
4.2.7 Module (Auszug)
Eine vollständige Beschreibung der einzelnen Module der clientseitigen Anwendung würde an dieser Stelle den Rahmen sprengen. Deswegen seien hier nur einzelne zentrale Komponenten aufgeführt, um an diesen Beispielen den Inhalt der
vorigen Abschnitte zu verdeutlichen.
4.2.7.1 Bibliothek
Die Bibliothek ist der zentrale Zugriffspunkt für den Benutzer auf seine Musikdatenbank. Sie wird in einem Tab aufgerufen und kann so parallel mit anderen Inhalten angezeigt werden. Sie besteht aus den Filtern im oberen Bereich und dem zentralen Grid, welches die einzelnen Datensätze anzeigt.
Damit der Benutzer die Möglichkeit hat, sukzessive seine Musikauswahl weiter
einzuschränken, sind die Filter in Reihe geschaltet: Zuerst kommt der Suchfilter,
dann Genre, Künstler und Album. Die einzelnen Filter bestehen aus Models, die den
aktuellen Zustand speichern und den jeweils nötigen View-Komponenten. Die
Instanzen der Filter sind im Model der Bibliothek verortet. Der Controller der
Bibliothek registriert sich bei den Filtern als Beobachter. Stellt der Benutzer einen
Filter an bzw. um, sorgt der Controller dafür, dass alle nachgelagerten Filter und
die Liste der Musiktitel neu geladen werden.
55
Das Grid, welches die Einträge aus der Datenbank enthält, verfügt über verschiedenen Funktionalitäten:
– Sortierung der Spalten in auf- und absteigender Reihenfolge
– Einzelne Spalten können in der Breite verändert und ein oder ausgeblendet
werden.
– Die Einträge können selektiert werden.
– Die Einträge können per Drag'n'Drop in eine bestehende Playliste geschoben werden.
– Drückt man mit der rechten Maustaste auf selektierte Einträge, können einzelne oder mehrere Einträge gleichzeitig bearbeitet werden. Dazu öffnet
sich ein Fenster, in dem die Attribute über ein Formular editiert werden.
– Mit Doppelklick wird der entsprechende Eintrag im Player abgespielt. Ein
kleines Symbol kennzeichnet den aktuell gespielten Titel
4.2.7.2 Player
Der Controller des Players bietet Schnittstellen an, um die Wiedergabe des Players
steuern zu können. Der eigentliche Algorithmus, welcher Titel z.B. bei dem Befehl
„next()“ abgespielt wird, befindet sich im zugehörigen Model, da es hierfür nötig
ist, auf den aktuellen Status einzugehen. Bei aktivierter Zufallsfunktion wird beispielsweise ein anderer Auswahl-Algorithmus verwendet als im Standardmodus.
Der Zugriff auf den Flashplayer wird über die API des eingebundenen JW FLV
Media Players realisiert. Diese API ermöglicht es, den Player mittels Javascript zu
steuern, sowie bestimmte Ereignisse abzufangen und darauf zu reagieren.16 So feuert der Flashplayer beispielsweise nach dem Beenden des gerade abgespielten
Titels ein Ereignis. Dieser Vorgang wird vom Controller überwacht. Tritt das Ereignis ein, ruft der Controller die „next()“-Methode des Models auf, um den nächsten
Song abzuspielen.
16 Mehr Informationen zum verwendeten Flashplayer befinden sich unter 3.1.4
56
Die Ansicht des Players besteht aus einer Statusanzeige, dem Flashplayer und einigen Steuerelementen, die das Verhalten des Players regeln. Die einzelnen Komponenten werden vom Model aktualisiert, sobald ein neuer Titel abgespielt wird.
Erweiterbarkeit der Anwendung
57
5 Erweiterbarkeit der Anwendung
Eine wesentliche Anforderung an die zu entwickelnde Anwendung war es, eine flexible Software zu entwickeln, auf deren Basis es möglich wäre, weitere Anwendungsfälle zu realisieren. In diesem Abschnitt soll anhand von zwei Beispielen
untersucht werden, inwiefern diese Anforderung erfüllt wurde. Dazu wird erläutert, wie ein weiterer Client erstellt werden könnte und wie es möglich ist, ein weiteres Datenformat aus einem externen Webservice in die Anwendung zu integrieren.
5.1 Zusätzliche Clients mit XML-RPC Webservice
Der in der Medienbibliothek integrierte Webservice für Ext Direct ist speziell für
den Ext JS-Client entworfen worden. Dieser Webservice kann generell auch von
anderen Clients angesprochen werden, nur müsste dafür in der jeweiligen Programmiersprache ein Adapter entwickelt werden, der die entsprechenden Aufrufe
generiert. Eine komfortablere Lösung für die Entwicklung weiterer Clients wäre es,
an dieser Stelle einen weit verbreiteten Standard einzusetzen. Wie in 3.4.2
beschrieben, können durch die verwendete Schichtenarchitektur verschiedene
Webservices parallel betrieben werden.
XML-RPC ist eine Methodik für das entfernte Aufrufen von Methoden. Die Kommunikation basiert auf dem HTTP-Protokoll und benutzt XML-Strukturen zum Formatieren der Daten. [WIKI09] Da der Standard auf HTTP aufsetzt, lassen sich Cookies
für die Authentifizierung verwenden. Für den Einsatz von XML-RPC gibt es Implementationen in fast allen Programmiersprachen, die einfach zu verwenden sind.17
Ein weiterer Grund für die Verwendung von XML-RPC ist, dass das Zend Framework eine Klasse zum Erstellen eines XML-RPC-Servers anbietet.
17 Implementationen für XML-RPC gibt es z.B. in Perl, Python, Java, C/C++, PHP, Microsoft .NET,
Delphi, WebObjects, Zope [WWW22] und ActionScript 3 [WWW23]
58
Die einzige Voraussetzung für die serverseitige Implementierung des Webservices
ist, dass ein neues Modul angelegt wird, welches einen Frontend-Controller beinhaltet. In diesem muss ein XML-RPC-Server erstellt werden, dem die nötigen Controller-Klassen der Anwendung übergeben werden. Das reicht aus, um einer beliebigen Client-Anwendung den Zugriff auf die gleichen Daten/Funktionen zu erlauben wie der in dieser Arbeit vorgestellten Ext JS Anwendung. So ist es denkbar,
eine iPhone-Application, eine Java-Anwendung oder ein Plugin für DesktopAnwendungen wie z.B. Songbird18 zu entwickeln, die es dem Benutzer ermöglichen, unterwegs oder zu Hause auf unterschiedliche Weise auf ihre Musikdatenbank zuzugreifen.
5.2 Neues Datenformat aus externer Quelle
Das Anlegen eines neuen Datenformats soll anhand der Youtube-API19 zum Auslesen und Hochladen von Videos dargestellt werden.
Für die Implementierung des neuen Datenformats muss zunächst ein neues Modul
angelegt werden, welches einen Controller, die notwendigen Models und ein
Backend für die Verarbeitung der Daten zur Verfügung stellt.
Der Controller stellt wie im Modul Audio den Zugriffspunkt für die Client-Anwendung dar. Denkbare Methoden wären hier z.B. „getList()“ oder „upload()“.
Das Model entspricht dem Audio-Model, nur dass ein Video natürlich etwas andere
Attribute vorhält, wie z.B. Thumbnails. Die Einstellungen können wie bei den anderen Models über die Konfigurationsdatei vorgenommen werden. Der einzige
wesentliche Unterschied zum Audio-Modul tritt bei der Implementierung des
Backends auf. Hier wird nicht auf die eigene Datenbank zugegriffen. Stattdessen
wird die Youtube-API verwendet, um die Daten zu lesen und zu schreiben. Auch
hierfür stellt das Zend Framework eine Bibliothek zur Verfügung. So kann mit Hilfe
18 Sonbird ist ein Musicplayer von Mozilla, der mit Plugins erweitert werden kann. [WWW24]
19 Youtube stellt eine API zur Verfügung, über die die Inhalte der Webseite mittels eines
Webservices für andere Anwendungen abrufbar sind. Auch das hinzufügen von Videos ist mit
diesem Webservice möglich. [WWW25]
59
der Klasse „Zend_Gdata_Youtube“ auf einfache Weise auf den Webservice zugegriffen werden. Das Backend kann also diese Klasse benutzen, um die Daten auszulesen und kann sie daraufhin in gewohnter Form an die Anwendungsschicht zurückgeben. Auch zum Speichern von neuen Videos kann das Backend auf die externe
Schnittstelle zurückgreifen.
Für die clientseitige Implementierung wird empfohlen, einen neuen Controller mit
zugehörigem Model und View anzulegen, der den Inhalt eines weiteren Tabs darstellt. So kann ein Interface erstellt werden, das es ermöglicht, nach Videos auf
Youtube zu suchen oder z.B. nach bestimmten Kanälen zu filtern. Zum Abspielen
der Videos kann der bereits integrierte JW FLV Media Player verwendet werden.
Er müsste lediglich etwas vergrößert dargestellt werden, um das Video sichtbar zu
machen. Zusätzlich verfügt der Player über einen Vollbild-Modus, so dass die
Videos trotz der beschränkten Breite in der linken Spalte auch in Großformat angesehen werden können.
Vor- und Nachteile der Anwendung
60
6 Vor- und Nachteile der Anwendung
In diesem Kapitel werden noch einmal die Besonderheiten der entwickelten
Anwendung beschrieben und auf ihre Vor- und Nachteile hin untersucht.
6.1 Schichtenarchitektur
Die für die serverseitige Anwendung zum Einsatz gekommene Schichtenarchitektur hat sich als sehr nützlich erwiesen, um die Anwendung so flexibel zu gestalten,
dass sie sehr einfach zu erweitern ist (siehe Abschnitt 5 ). Die Trennung der einzelnen Zuständigkeiten gibt der Applikation zudem eine klare Struktur und macht sie
einfach wartbar und für andere Entwickler leichter zu verstehen. Außerdem ist der
Datenfluss der Anwendung klar ersichtlich, da jede Schicht nur mit der jeweils
unter ihr liegenden kommuniziert.
Diese Limitierung bringt allerdings auch ein paar Nachteile mit sich. So ist es z.B.
nicht möglich, spezielle Datenbankabfragen direkt im Controller zu realisieren,
was in anderen Anwendungen oft der Fall ist. Für jede noch so kleine Abfrage von
Daten müssen Methoden in jeder einzelnen Schicht der Anwendung implementiert
werden. Es wurde zwar versucht, entsprechende Abfragen mit einem RequestObjekt (siehe 4.1.4.3) zu abstrahieren, sodass nicht in jedem Fall eine neue
Methode angelegt werden muss. Doch es hat sich herausgestellt, dass es kompliziert ist, die vielfältigen Möglichkeiten einer SQL-Abfrage auf diese Weise zu verallgemeinern. Eine Anforderung an die Software war (siehe 2.2.2.3), die Persistenzschicht austauschen zu können. Folglich führte an der Schichtenarchitektur kein
Weg vorbei. Flexibilität heißt in diesem Fall also auch, sich auf den kleinsten
gemeinsamen Nenner zu einigen und Funktionen, die nur bestimmte Persistenzschichten unterstützen, nicht allgemein verwenden zu können.
Ein weiterer Nachteil an der starren Schichtenarchitektur ist, dass die Geschäftslogik mit Funktionalitäten ausgestattet werden muss, die eigentlich nur an das
Backend weitergegeben werden. Eine mögliche Alternative wäre es, die Schichtenarchitektur an dieser Stelle aufzuheben und dem Controller direkten Zugriff auf die
61
Persistenzschicht zu gewähren. Dieses Verfahren wird z.B. im PHP-Framework
Flow320 und in Tine 2.021 angewendet. Aus Gründen der Übersichtlichkeit und der
Vereinfachung der Aufgaben der Controller wurde diese Methode hier nicht angewendet.
6.2 Trennung von Server- und Client-Anwendung
Die strikte Trennung von Server und Client ist eine Konsequenz der geforderten
Multi-Client-Fähigkeit (2.2.2.2) und der Anforderung, dass sich die Webseite ähnlich wie eine Desktop-Anwendung bedienen lassen soll (2.2.1.1). Die so entstandene RIA (Rich Internet Application) hat einige Vor- und Nachteile gegenüber herkömmlichen Internetseiten. Ein Nachteil besteht darin, dass die anfängliche Ladezeit relativ hoch ist, da zunächst die komplette Javascript-Anwendung heruntergeladen werden muss (im gepackten Zustand ca. 210kb). Dieser Nachteil wird im folgenden Verlauf allerdings vermindert, da nur noch Daten vom Server geladen werden müssen und keine komplexen HTML-Dokumente. Das macht die Bedienung
insgesamt flüssiger. Ein weiterer Punkt, der bei Javascript-Anwendungen im Browser beachtet werden muss, ist, dass der Browser nur begrenzten Arbeitsspeicher
zur Verfügung hat und das Ausführen von Javascript unter Umständen sehr langsam ist22. Da die aktuelle Version des verwendeten Javascript-Frameworks Ext JS
speziell daraufhin optimiert wurde, macht sich dieses Problem allerdings kaum
bemerkbar. Es ist jedoch davon auszugehen, dass eine Medienbibliothek mit tausenden von Einträgen, die gleichzeitig angezeigt werden sollen, für PerformanceProbleme sorgt. Eine Abhilfe hierfür könnte sein, dass die Bibliothek zukünftig mit
einem Pagebrowser ausgestattet wird, der dafür sorgt, dass immer nur eine
begrenzte Anzahl von Einträgen auf einmal angezeigt wird.
20 Flow3 ist ein PHP Framework, dass für die neue Typo3 Version 5 entwickelt wurde. Das hier
verwendete Persistenz-Framework liefert dem Controller die aggregierten Models. [WWW26]
21 Tine 2.0 ist eine webbasierte Groupware, in der der Controller direkten Zugriff auf das Backend
hat. [WWW27]
22 Es gibt im Internet viele Blog-Einträge, die sich mit dem Thema befassen, z.B.: [WWW28].
Speziell der Internet Explorer ist in einigen Bereichen sehr langsam, was das Ausführen von
Javascript angeht.
62
Als Nachteil kann noch betrachtet werden, dass für die Verwendung der Anwendung ein moderner Browser benötigt wird, wobei die in 2.2.1.3 aufgeführten Statistiken belegen, dass der Großteil aller Internetnutzer über einen solchen Browser
verfügt.
Trotz dieser Probleme ist festzuhalten, dass die Benutzeroberfäche einige Funktionen bietet, die über den Umfang einer normalen Webseite deutlich hinausgeht. Da
ist z.B. die flüssige Bedienung, die nur möglich ist, weil sich die Webseite nicht bei
jedem Klick neu laden muss. Da sind auch verschiedene Bedienkonzepte wie
Rechtsklick und Drag'n'Drop, die ohne Javascript im Browser nicht realisierbar
wären. Des Weiteren kann ein ununterbrochenes Abspielen von Audiodateien nur
gewährleistet werden, wenn die Anwendung als Single Page Interface realisiert ist
(siehe 3.3.2 ).
6.3 MVC im Browser
Vergleicht man die Anzahl der auf Wikipedia gelisteten MVC-Frameworks für PHP
und Javascript, fällt einem auf, dass es fast zehn mal mehr Frameworks für PHP
gibt (46 zu 5) und dass keines der gängigen Javascript-Frameworks ein eigenes
MVC-Konzept verwendet. [WIKI12] Das liegt vor allem daran, dass es wesentlich
mehr Webseiten gibt, die hauptsächlich mit PHP generiert werden und Javascript
nur als in den Views eingekapselte Code-Schnipsel verwenden. Trotzdem zeigt
diese Tatsache auf, dass der generelle Trend hin zu Webseiten mit Ajax [WWW32]
anscheinend noch nicht dazu geführt hat, die Anwendung im Browser als eigenständig zu betrachtet und dementsprechend bewährte Entwurfsmuster wie MVC
auch dort anzuwenden. An der hier entwickelten Webanwendung kann jedoch
gezeigt werden, dass es durchaus Sinn macht, die Komplexität des Javascript-Codes
durch das MVC-Pattern zu verringern und klarer zu strukturieren. Ursprünglich
wurde das MVC-Muster für grafische Benutzeroberflächen entwickelt23, warum
sollte man es also nicht gerade hier anwenden?
23 Das serverseitig oft verwendete MVC-Muster ist eigentlich eine Abwandlung des urspünglichen
Musters und nennt sich Model 2 [FRE08, Seite 549]
63
Bei genauer Betrachtung der in der RIA verwendeten Javascript Bibliothek Ext JS
kann man erkennen, dass für einen speziellen Anwendungsfall eine Trennung zwischen View und Model implementiert wurde. Die verschiedenen Varianten des
Store-Objekts können als Model betrachtet werden, denn sie repräsentieren eine
bestimmte Form von Daten, die die Grundlage für eine View-Komponente bilden
(z.B. für ein Grid). Es ist jedoch so, dass diese Stores relativ stark an eine
bestimmte, eindimensionale Form der Daten und an ihre Resource (meist auf dem
Server liegende Daten) gebunden sind. Um eine eigene Anwendungslogik (für z.B.
den Player) zu implementieren, braucht es an dieser Stelle zusätzlich eigene
Models. Controller gibt es in Ext JS nicht und man wird durch den Aufbau der ViewKomponenten oft dazu verleitet, Funktionalitäten, die eigentlich in einen Controller gehören, im View zu implementieren. Denn was bei einem bestimmten Ereignis
passieren soll, kann in der View-Komponente selbst definiert werden. Dem MVCMuster entsprechender wäre es, an dieser Stelle einen Controller zu erstellen, der
die entsprechende Komponente beobachtet und auf Ereignisse reagieren kann.
Aus diesen Gründen wurden eigene Controller und Models entwickelt, die die von
Ext JS bereit gestellten Komponenten (hauptsächlich View-Komponenten) ergänzen. So sind die Zuständigkeiten der verschiedenen Module klar getrennt und die
verschiedenen Vorteile des MVC-Entwurfsmuster kommen zum Tragen.
Die Implementierung wurde an einer Stellen etwas anders realisiert, als das Entwurfsmuster normalerweise vorsieht. „The model and controller have no direct
knowledge of the view“ [WIKI12]. Aus verschiedenen Gründen wurde das MVCEntwurfsmuster hier etwas anders interpretiert. Aus Gründen der Praktikabilität
und Flexibilität ist der Controller das übergeordnete Element, welches das Model
initialisiert. Das Model wiederum initialisiert die View-Komponenten. So besteht
die Möglichkeit, dass der Controller und das Model Einfluss darauf nehmen können, auf welche Weise der View erstellt wird. Sie können bei Bedarf direkt auf den
View zugreifen und ihn manipulieren. Das verstößt an dieser Stelle zwar gegen das
Observer-Muster zwischen Model und View, vereinfacht dafür aber an vielen Stel-
64
len die Programmierung. Das Muster ist auch deswegen nicht nötig, da es in der
Anwendung nicht vorkommt, dass ein Model auf verschiedene Arten repräsentiert
wird.
6.4 Vergleich mit Desktop-Applikationen
Der Vergleich der entwickelten webbasierten Medienbibliothek mit entsprechenden Desktop-Applikationen soll weniger auf die konkrete Implementierung als auf
die generellen, strukturellen Unterschiede abzielen. Es soll aufgezeigt werden, wo
die jeweiligen Anwendungen an ihre Grenzen stoßen, für welchen Anwendungszweck sie am ehesten geeignet sind und wie die verschiedenen Vorteile miteinander verbunden werden könnten. Verglichen werden die Grundfunktionalitäten der
Webanwendung mit denen von Desktop-Anwendungen wie Itunes, Windows
Media Player, Winamp, Songbird oder Real Media.
Abbildung 16: Screenshot der entwickelten Anwendung
65
Die wesentlichen Limitierungen der webbasierten Medienbibliothek bestehen
darin, dass sie in einem Browser ausgeführt wird, der für die Javascript-Anwendung eine Art Sandbox24 darstellt. Es ist z.B. nicht möglich, direkt auf das Dateisystem zuzugreifen oder mit anderen Anwendungen zu interagieren. Das hat zur
Folge, dass es z.B. nicht umsetzbar ist, Dateien per Drag'n'Drop in die Anwendung
zu ziehen oder per Kontextmenü aus dem Dateibrowser mit der Webapplikation zu
starten. Das Importieren von Audio-CDs in die Medienbibliothek – ein wesentliches Feature der genannten Desktop-Anwendungen – ist somit auch nicht machbar. Der umgekehrte Prozess – das Brennen einer Audio-CD – ist auf diesem Weg
natürlich genauso wenig realisierbar. Ein weiterer Nachteil ist, dass die Webanwendung nur mit einem nicht allzu langsamen Internetanschluss benutzt werden
kann und dass die Musikdateien, bevor sie online gehört werden können, zunächst
hoch geladen werden müssen. Das kann je nach Internetanschluss und Größe der
Musiksammlung einige Zeit in Anspruch nehmen und erfordert in der jetzigen Version ein FTP-Programm. Ein derzeit noch bestehendes Manko ist auch, dass die
online editierten Dateien nicht einfach zurück transferiert werden können, um sie
beispielsweise auf einem MP3-Player abzuspielen. Durch entsprechenden Programmieraufwand könnte hierfür aber eine Lösung geschaffen werden.
Die Limitierungen der Desktop-Anwendungen entstehen vor allem durch die
lokale Datenhaltung. Die Daten liegen alle nur lokal vor und müssen bei Benutzung
verschiedener Rechner hin und her kopiert werden. Das ist nicht nur aufwändig,
sondern kann bei großen Sammlungen auch viel Platz auf der Festplatte in
Anspruch nehmen. Hinzu kommt, dass bei der Neuinstallation eines Betriebssystems oder einem Wechsel der Anwendung in der Regel die kompletten Dateien neu
indiziert werden müssen, da jede Anwendung eine interne Datenbank aufbaut. Ein
weiteres Problem ist, dass die Abfrage dieser Datenbank den eigenen Rechner
belastet, was manche Systeme bei vielen Einträgen extrem langsam macht. Bei
einem verteilten System wie der Webanwendung können die Lasten (GUI und
Datenbank) besser verteilt werden, da sie auf verschiedenen Prozessoren laufen.
24 Der Begriff Sandbox bezeichnet in der IT eine Software, die abgeschirmt vom eigentlichen
System ausgeführt wird. [WIKI13]
66
Hinzu kommt, dass der Benutzer bei einer webbasierten Lösung von jedem Rechner mit Internetanschluss aus ohne Installation einer Software auf die Medienbibliothek zugreifen kann.
Vorteile der Webanwendung bestehen in den möglichen Erweiterungen, die in den
Anwendungsfällen 2.1.2 und 2.1.3 sowie im Kapitel 5 kurz erläutert werden und
nicht direkter Bestandteil der hier vorgestellten Medienbibliothek sind. Trotzdem
sind diese Optionen hier aufzuführen, da sie die prinzipiellen Unterschiede zwischen Desktop- und Webanwendung deutlich machen.
Mit der RIA ist es möglich, die Inhalte nicht nur selber zu verwenden, sondern sie
auch mit anderen Benutzern zu teilen. Auf dieser Basis sind viele Funktionen denkbar, die mit einer normalen Desktop-Anwendung nicht realisierbar sind bzw. bis
jetzt nicht realisiert wurden. Ein paar Beispiele sind z.B.:
– Verschicken von Wiedergabelisten/Titeln an andere Benutzer
– Gegenseitiges Vorstellen von neuer Musik
– Gemeinsames Pflegen der Metainformationen
Die Verknüpfung der Anwendung mit einem Online-Vertrieb bringt für den Benutzer außerdem die Möglichkeit, zeitlich begrenzt auf eine umfassende Bibliothek
zuzugreifen (Flatrate). In diesem Fall macht es aufgrund der Masse wenig Sinn, die
kompletten Daten auf den lokalen Rechner herunterzuladen und sie mit DRM25 zu
schützen.
Ein großer Pluspunkt der webbasierten Anwendung ist es schließlich, dass verschiedene Clients dafür entwickelt werden können. So ist es z.B. möglich, einen Client auf Basis von Adobe AIR zu erstellen. Ein solcher Client hebt gleichzeitig die
Limitierungen der Javascript-Anwendung auf, da mit Adobe AIR Webanwendungen
programmiert werden können, die in den Desktop eingebunden sind. Der Zugriff
auf das Dateisystem und die Interaktion mit anderen Betriebssystem-spezifischen
25 DRM steht für Digital Rights Managment, eine Möglichkeit, die Benutzung digitaler Inhalte auf
bestimmt Verwendungszwecke zu limitieren [WIKI14]
67
Komponenten ist somit machbar. Ein weitere Client könnte dieselbe Musiksammlung außerdem auf das Handy bringen, sie somit mobil und herkömmliche MP3Player damit überflüssig machen.
Fazit/Ausblick
68
7 Fazit/Ausblick
In dieser Diplomarbeit wurde vorgestellt, wie sich mit Hilfe von Open-Source-Produkten eine gewöhnliche Desktop-Anwendung – konkret eine Medienbibliothek –
in den Browser bringen lässt. Die für die serverseitige Anwendung entwickelten
Konzepte sind so allgemein, dass sie auch für viele ähnliche Problemfälle verwendet werden können.
Es hat sich gezeigt, dass die konzeptionierte Schichtenarchitektur die Anwendung
sehr flexibel und übersichtlich strukturiert und eine einfache Erweiterbarkeit
gewährleistet. Der einzige Nachteil, der dadurch entsteht, ist, dass Datenbankabfragen abstrahiert werden müssen. Dies führt dazu, dass die Funktionalitäten auf
den kleinsten gemeinsamen Nenner verschiedener DBMS (Datenbank Management Systeme) reduziert werden müssen, was in der entwickelten Anwendung
jedoch zu keinen Problemen geführt hat.
Die umgesetzte Trennung von Server- und Client-Anwendung führt dazu, dass die
Struktur der Software auf dem Server vereinfacht werden kann, da sie im Wesentlichen nur noch für den Datenaustausch zwischen Client und Datenbank zuständig
ist. Ein weiterer Vorteil ist, dass die Anwendung unabhängig von dem eingesetzten
Client verwendet werden kann.
Um die geforderten, umfangreichen Funktionalitäten der Client-Anwendung
umsetzen zu können, wurde auf das Javascript Framework Ext JS gesetzt und das
MVC-Entwurfsmuster in den Browser integriert. Diese Kombination hat gezeigt,
dass es möglich ist, Rich Internet Applications im Browser zu erstellen, die in
puncto Bedienbarkeit und Anwendungsarchitektur mit Desktop-Anwendungen
ebenbürtig sind.
Wie in Abschnitt 6.4 beschrieben, bestehen jedoch einige grundsätzliche Limitierungen in Browser-Anwendungen, da sie aus Sicherheitsgründen keinen kompletten Zugriff auf den Client-Rechner haben. Sehr interessant wäre es hier, eine Verschmelzung von Desktop- und Webanwendung zu schaffen um die jeweiligen
Fazit/Ausblick
69
strukturellen Nachteile zu überwinden. Möglich wäre es z.B. einen AIR-Client für
die Medienbibliothek zu entwickeln, da Adobe mit dieser Technik genau den
Ansatz verfolgt, Webanwendungen in den Desktop zu integrieren.
Dass die Anforderung der einfachen Erweiterbarkeit (2.2.2 ) erfüllt ist, wurde im
Abschnitt 5 an zwei Beispielen verdeutlicht. Ob dies auch für andere Beispiele gilt,
lässt sich natürlich erst im konkreten Fall beurteilen. Dennoch wurde hier aufgezeigt, welche prinzipiellen Möglichkeiten bestehen und wie sie genutzt werden
können.
Interessant wäre es, die beiden in dieser Diplomarbeit nicht näher ausgeführten
Anwendungsfälle umzusetzen, da sie die wesentlichen Vorteile einer webbasierten
Anwendung deutlicher ausspielen könnten und dem Benutzer Funktionalitäten
bereit stellen würden, die derzeit keine aktuelle Medienbibliothek bieten kann.
Die parallel zur schriftlichen Arbeit entwickelte Software lässt auf den ersten Blick
keine Unterschiede der Bedienbarkeit im Vergleich zu Desktop-Anwendungen
erkennen (siehe Link in Anhang F). Diese Betrachtung ist natürlich erstmal nur
subjektiv und wäre in einem weiteren Schritt von geeigneten Testpersonen zu
belegen. Ob sich die Performance in der Praxis auch mit vielen Datensätzen halten
lässt, bleibt ebenso zu untersuchen. Die kurze Entwicklungszeit von nur zwei
Wochen kann als Beleg dafür gewertet werden, dass die aufgestellten Konzepte
funktionieren. Trotzdem ist die jetzige Version nur als Beta-Version zu verstehen,
da davon auszugehen ist, dass sie noch einige Bugs enthält, die mit ausführlichem
Testen aufgespürt werden müssen.
Für die zukünftige Verwendung der Entwicklung gibt es generell zwei unterschiedliche Lösungen. Die eine wäre zu versuchen, sie kommerziell zu vertreiben. Es
bedeutet allerdings noch einige Arbeit, eine marktreife Version fertigzustellen.
Gerade die Variante als Teil eines Online-Vertriebs könnte hier jedoch sehr viel versprechend sein, da bisher kein Anbieter von Audio-Inhalten mit einem ausgereiften
Software-Konzept für Flatrate-Angebote aufwarten kann.
Fazit/Ausblick
70
Die andere Möglichkeit wäre, das Projekt unter einer Open-Source Lizenz zu veröffentlichen. Auch dieser Schritt setzt weitere Maßnahmen voraus: So müsste eine
Installationsroutine erstellt werden und eine Art Extension-Manager programmiert werden, mit dem es möglich ist, Erweiterungen aus der Open-Source-Community in die Anwendung zu integrieren. Wichtig wäre es auch, die Applikation
ausreichend bekannt zu machen, damit sich eine lebhafte Gemeinde um das Projekt bilden kann, die die möglichen Erweiterungen in Angriff nimmt.
Welche der beiden Ansätze verfolgt werden kann/soll, ist durch Gespräche mit der
betreuenden Firma und geeigneten Experten zu diskutieren, um rechtliche und
wirtschaftliche Aspekte der Varianten näher zu durchleuchten.
Abschließend ist festzuhalten, dass der in dieser Diplomarbeit vorgestellte Ansatz,
Open-Source-Produkte wie Apache, Zend Framework, Ext JS und JW FLV Media
Player mit einer flexiblen Software-Architektur zu verbinden, eine extrem leistungsstarke Möglichkeit bietet, browserbasierte Anwendungen zu erstellen.
Anhang
71
8 Anhang
A Literaturverzeichnis...............................................................................................................72
B Tabellenverzeichnis................................................................................................................76
C Abbildungsverzeichnis...........................................................................................................77
D Datenstruktur............................................................................................................................78
E API..................................................................................................................................................81
F Anwendungsbeispiel...............................................................................................................82
G Verwendete Internet-Techniken........................................................................................83
G.1 HTTP....................................................................................................................................83
G.2 PHP ......................................................................................................................................84
G.3 MySQL.................................................................................................................................85
G.4 Javascript/Ajax................................................................................................................85
G.5 Audio und Video im Browser.....................................................................................86
Anhang
72
A
Literaturverzeichnis
BAR05:
PHP - Einstieg für Anspruchsvolle (2005)
Andreas Barchfeld - Addison-Wesley
ISBN: 3-8273-2181-6
FLA07:
JavaScript - Das umfassende Referenzwerk (2007)
David Flanagan - O'Reilly Verlag
ISBN: 978-3-89721-491-0
FRE08:
Entwurfsmuster von Kopf bis Fuß (2008)
Eric Freeman, Elisabeth Freeman - O'Reilly
ISBN: 3-89721-421-0
MOE08:
Zend Framework - Grundlagen und Referenz (2008)
Carsten Möhrke - Galileo Computing
ISBN: 978-3-8362-1068-3
SCH09:
PHP Design Patterns (2009)
Stefan Schmidt - O'Reilly Verlag
ISBN: 978-3-89721-864-2
T3N:
t3n 06/2007 - 08/2007 (2007)
yeebase media solution GbR
TAN01:
Computernetzwerke (2000)
Andrew S. Tanenbaum - Markt und Technik
ISBN: 3827295688
WIKI01:
Hypertext Transfer Protocol (2009)
http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol
WIKI02:
Hypertext Transfer Protocol (2009)
http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol
WIKI03:
MySQL (2009)
http://de.wikipedia.org/wiki/Mysql
WIKI04:
JavaScript (2009)
http://de.wikipedia.org/wiki/JavaScript
WIKI05:
Ext (JavaScript library) (2009)
http://en.wikipedia.org/wiki/Ext_JS
WIKI06:
Adobe Integrated Runtime (2009)
http://de.wikipedia.org/wiki/Adobe_Integrated_Runtime
WIKI07:
CRUD (2009)
http://de.wikipedia.org/wiki/CRUD
WIKI08:
Fluent Interface (2009)
http://de.wikipedia.org/wiki/Fluent_Interface
Anhang
WIKI09:
73
XMP-RPC (2009)
http://de.wikipedia.org/wiki/XML-RPC
WIKI11:
Ogg Controversy (2009)
http://en.wikipedia.org/wiki/Ogg_controversy
WIKI12:
Wikipedia: Model-view-controller (2009)
http://en.wikipedia.org/wiki/Model-view-controller
WIKI13:
Sandbox (2009)
http://de.wikipedia.org/wiki/Sandbox
WIKI14:
Digitale Rechteverwaltung (2009)
http://de.wikipedia.org/wiki/Digitale_Rechteverwaltung
WIKI15:
Bootstrapping (2009)
http://de.wikipedia.org/wiki/Bootstrapping_(Informatik)
WIKI16:
Persistenz (2009)
http://de.wikipedia.org/wiki/Persistenz_(Informatik)
WIKI17:
Entwurfsmuster (2009)
http://de.wikipedia.org/wiki/Entwurfsmuster
WWW01:
MySQL-Tabellentypen: Ein Vergleich (2009)
http://phpperformance.de/mysql-tabellentypen-ein-vergleich/
WWW02:
Speicher-Engines und Tabellentypen: (2009)
http://dev.mysql.com/doc/refman/5.1/de/storage-engines.html
WWW03:
Zend Framework: Documentation (2009)
http://framework.zend.com/manual/de/coding-standard.html
WWW04:
phpDocumentor (2009)
http://manual.phpdoc.org
WWW05:
Cutting EdgeSingle Page Interface und AJAX-Muster (2009)
http://msdn.microsoft.com/de-de/magazine/cc507641.aspx
WWW06:
LAMP (2009)
http://de.wikipedia.org/wiki/LAMP
WWW08:
Was in einem Web ohne Flash möglich ist (2009)
http://www.netzwelt.de/news/80040-webstandards-web-ohne-flash-moeglich.html
WWW09:
JW FLV Media Player 4.5 (2009)
http://www.longtailvideo.com/players/jw-flv-player/
WWW10:
Ext.Direct Remoting Specification (2009)
http://extjs.com/products/extjs/direct.php
WWW11:
Top 10 2007 OWASP (2007)
http://www.owasp.org/index.php/Top_10_2007
WWW12:
Apache Tutorial: .htaccess files (2009)
http://httpd.apache.org/docs/2.2/howto/htaccess.html
Anhang
WWW13:
74
Der Dispatcher (2009)
http://framework.zend.com/manual/de/zend.controller.dispatcher.html
WWW14:
Reflection (2009)
http://www.php.net/manual/de/language.oop5.reflection.php
WWW15:
Lazy Acquisition (2001)
http://www.kircher-schwanninger.de/michael/publications/LazyAcquisition.pdf
WWW16:
Ext.Direct - Server-side Stacks (2009)
http://www.extjs.com/forum/showthread.php?t=67992
WWW17:
getID3() (2009)
http://getid3.org/
WWW18:
Firebug (2009)
https://addons.mozilla.org/de/firefox/addon/1843
WWW19:
FirePHP (2009)
http://www.firephp.org/
WWW20:
Minify (2009)
http://code.google.com/p/minify/
WWW21:
Ext.Direct (2009)
http://www.extjs.com/products/extjs/direct.php
WWW22:
XML-RPC Homepage (2009)
http://www.xmlrpc.com/
WWW23:
XMLRPC for Actionscript 3.0 (2009)
http://danielmclaren.net/2007/08/03/xmlrpc-for-actionscript-30-free-library/
WWW24:
Songbird (2009)
http://getsongbird.com/
WWW25:
Developer's Guide: Data API Protocol (2009)
http://code.google.com/intl/de-DE/apis/youtube/2.0/developers_guide_protocol_audience.html
WWW26:
Flow3 Persistence (2009)
http://flow3.typo3.org/documentation/manuals/flow3/flow3.persistenceframework/
WWW27:
Tine 2.0 Application Layout (2009)
http://www.tine20.org/wiki/index.php/Developers/Concepts/Application_Layout
WWW28:
A Study of Ajax Performance Issues (2009)
http://www.coachwei.com/blog/_archives/2008/1/22/3480119.html
WWW29:
Browser Verbreitung (2009)
http://gs.statcounter.com/#browser_version-ww-daily-20090321-20090321-bar
WWW30:
Verbreitung von Webtechnologien (2009)
http://www.webmasterpro.de/portal/webanalyse-technologien.html
WWW32:
Keeping Up With The Ajax Trend (2009)
http://www.developer.com/services/article.php/3562876/Keeping-Up-With-The-Ajax-Trend.htm
Anhang
WWW33:
75
SOA (2009)
http://www.computerwoche.de/soa-expertenrat/faq/
Anhang
B
76
Tabellenverzeichnis
Tabelle 1: Liste der implementierten Filter..............................................................................42
Tabelle 2: Liste der verfügbaren Konfigurationseinstellungen für Datenfelder........46
Tabelle 3: Verwendete View-Komponenten der Ext JS Library........................................53
Anhang
C
77
Abbildungsverzeichnis
Abbildung 1: Verbreitung der verschiedenen Browserversionen [WWW29]...........10
Abbildung 2: Screenshot Dateisystem........................................................................................19
Abbildung 3: Grundlayout...............................................................................................................20
Abbildung 4: Single Page Interface-Elemente innerhalb einer Seite [WWW05].......21
Abbildung 5: Aufbau des Clients...................................................................................................22
Abbildung 6: Datenstruktur............................................................................................................23
Abbildung 7: Anwendungsschichten...........................................................................................25
Abbildung 8: Datenfluss Client......................................................................................................29
Abbildung 9: Datenfluss Server.....................................................................................................30
Abbildung 10: UML Diagramm - Umsetzung Singleton Pattern.......................................34
Abbildung 11: UML Sequenzdiagramm - Controller, Models, Backend........................35
Abbildung 12: UML Mel_Core_Model_Item_Abstract............................................................36
Abbildung 13: UML-Diagramm - Zusammenhang List und Item.....................................38
Abbildung 14: UML Diagramm - Request und Filter.............................................................40
Abbildung 15: Baumstruktur der View-Komponenten.......................................................52
Abbildung 16: Screenshot der entwickelten Anwendung..................................................64
Abbildung 17: Funktionsweise von PHP [WIKI02]...............................................................84
Anhang
D
---------
78
Datenstruktur
phpMyAdmin SQL Dump
version 3.1.2deb1ubuntu0.1
http://www.phpmyadmin.net
Host: localhost
Erstellungszeit: 21. September 2009 um 14:43
Server Version: 5.0.75
PHP-Version: 5.2.6-3ubuntu4.2
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
--- Datenbank: `mel`
-CREATE DATABASE `mel` DEFAULT CHARACTER SET latin1 COLLATE
latin1_swedish_ci;
USE `mel`;
-- ---------------------------------------------------------- Tabellenstruktur für Tabelle àudio`
-CREATE TABLE IF NOT EXISTS àudio` (
ìd` int(11) NOT NULL auto_increment,
ùser` int(11) NOT NULL,
`crdate` int(11) NOT NULL,
`tstamp` int(11) NOT NULL,
`deleted` tinyint(1) NOT NULL,
`filesize` int(11) NOT NULL,
`fileformat` varchar(20) NOT NULL,
`filename` varchar(255) NOT NULL,
`directory` varchar(255) NOT NULL,
`bitrate` float NOT NULL,
`length` float NOT NULL,
`title` varchar(255) NOT NULL,
àrtist` varchar(255) NOT NULL,
àlbum` varchar(255) NOT NULL,
`genre` varchar(255) NOT NULL,
`comment` text NOT NULL,
`cover` varchar(255) NOT NULL,
`favorite` tinyint(1) NOT NULL,
`vote` int(11) NOT NULL,
`track` varchar(11) NOT NULL,
`bpm` float NOT NULL,
Anhang
79
`year` int(11) NOT NULL,
`hits` int(11) NOT NULL,
PRIMARY KEY (ìd`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
AUTO_INCREMENT=240 ;
-- ---------------------------------------------------------- Tabellenstruktur für Tabelle àudio_tags`
-CREATE TABLE IF NOT EXISTS àudio_tags` (
PRIMARY KEY (ìd`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=6 ;
-- ---------------------------------------------------------- Tabellenstruktur für Tabelle àudio_tags_mxm`
-CREATE TABLE IF NOT EXISTS àudio_tags_mxm` (
àudio` int(11) NOT NULL,
`tag` int(11) NOT NULL,
PRIMARY KEY (àudio`,`tag`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
-- ---------------------------------------------------------- Tabellenstruktur für Tabelle `playlists`
-CREATE TABLE IF NOT EXISTS `playlists` (
ùser` int(11) NOT NULL,
`deleted` tinyint(1) NOT NULL,
PRIMARY KEY (ìd`)
-- ---------------------------------------------------------- Tabellenstruktur für Tabelle `playlists_entries`
Anhang
80
-CREATE TABLE IF NOT EXISTS `playlists_entries` (
`playlist` int(11) NOT NULL,
àudio` int(11) NOT NULL,
`sorting` int(11) NOT NULL,
PRIMARY KEY (ìd`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
AUTO_INCREMENT=238 ;
-- ---------------------------------------------------------- Tabellenstruktur für Tabelle ùsers`
-CREATE TABLE IF NOT EXISTS ùsers` (
ùpload_dir` varchar(255) NOT NULL,
èmail` varchar(255) NOT NULL,
`name` varchar(255) NOT NULL,
`deleted` int(11) NOT NULL,
`password` varchar(40) NOT NULL,
PRIMARY KEY (ìd`)
Anhang
E
81
API
Eine mit dem phpDocumenter [WWW04] erstellte API ist auf der beiliegenden CD
zu finden oder im Web aufrufbar unter:
http://www.felixkrueger.net/mel/api
Anhang
F
82
Anwendungsbeispiel
Die installierte Anwendung ist im Web aufrufbar unter:
http://www.felixkrueger.net/mel/melone
Email: diplom@felixkrueger.net
Passwort: melone
Anhang
G
83
Verwendete Internet-Techniken
G.1
HTTP
Das Hypertext Transfer Protocol bildet die Grundlage für den Austausch von Daten,
die zum Aufbau einer Webseite benötigt werden. Es befindet sich auf der Schicht 7
(Anwendungsschicht) des Internetprotokollstapels TCP/IP.
HTTP ist ein verbindungsloses Protokoll. Damit es Anwendungen möglich ist, Sitzungsdaten zu speichern, kann eine Session-ID erzeugt werden. Diese wird in den
Header-Daten als Cookie mitgesendet und erlaubt so das Entwickeln von Anwendungen, die sitzungsspezifische Daten benötigen.
Die wichtigsten HTTP-Request Methoden sind GET und POST. Mit ihnen fragt ein
Client eine bestimmte Datei mittels einer URL an und bekommt Sie vom Webserver
ausgeliefert. Es ist möglich, diesen Anfragemethoden Parameter zu übergeben, die
die Ausgabe steuern.
Verschiedene Statuscodes im Header geben an, ob die Anfrage erfolgreich war
(200), die Datei z.B. nicht gefunden wurde (404) oder ein nicht autorisierter
Zugriff vorliegt (403). [TAN01, Seite 129], [WIKI01]
Anhang
G.2
84
PHP
Abbildung 17: Funktionsweise von PHP [WIKI02]
PHP (PHP Hypertext Preprocessor) ist eine weit verbreitete Open-Source-Scriptsprache zum dynamischen Generieren von Webseiten. Der Quelltext wird zur Laufzeit ausgeführt und muss nicht vorher kompiliert werden.
Im Wesentlichen wird PHP dazu benutzt, serverseitig Textdateien zu generieren,
die über das Hypertext Transfer Protocol von einem Client abgerufen werden. Die
Übergabe von GET- oder POST-Parametern kann dabei zu Steuerungszwecken verwendet werden (beispielsweise eine Seiten-ID). Es ist z.B. auch möglich PDFDateien oder Bilder mit PHP zu erzeugen.
PHP unterstützt eine große Anzahl von Datenbanken (wie z.B. MySQL), mit deren
Hilfe eine Trennung von Programmierung und Inhalt geschaffen werden kann.
In früheren Versionen wurde PHP hauptsächlich zur Bearbeitung von Formulardaten verwendet. Seit Version 5 besitzt PHP alle wichtigen Funktionen, die zum
objektorientierten Programmieren benötigt werden. Durch neue Sprachkonstrukte wie z.B. Überladung, Exceptions und Reflections ist die Scriptsprache PHP
so mächtig geworden, dass viele Webseiten komplett mit ihr generiert werden.
[BAR05 / Seite 68]
Anhang
G.3
85
MySQL
MySQL ist ein relationales Datenbank Management System und ist mit über sechs
Millionen Installationen das weltweit am meisten verbreitete System seiner Art. Es
wird häufig in Verbindung mit PHP eingesetzt und stellt mit seiner Structured
Query Language (SQL) ein flexibles System zur Speicherung von Daten dar.
[WIKI03]
Die Daten werden in einzelnen Tabellen gespeichert, die über Schlüssel mit einander verknüpft werden können.
Es gibt verschiedene Speicherengines für MySQL. Die am häufigsten verwendeten
sind MyISAM und InnoDB, wobei MyISAM schneller, aber nicht-transaktionssichere ist und InnoDB transaktionssicher, dafür aber etwas langsamer ist.
[WWW01, WWW02]
G.4
Javascript/Ajax
JavaScript ist eine clientseitige Scriptsprache, die heutzutage vor allem für DOMManipulationen im Browser oder das clientseitige Überprüfen von Formulardaten
verwendet wird. Es ist eine „moderne, schlanke, dynamisch typisierte, objektorientierte, aber klassenlose Skriptsprache, die dennoch allen objektorientierten Programmierparadigmen unter anderem auch – aber eben nicht ausschließlich – auf
der Basis von Prototypen gerecht wird.“ [WIKI04]
Ajax (Asynchronous Javascript and XML) ist eine Technik, mit der per JavascriptAufruf Daten für eine Webseite nachgeladen werden, ohne dass dafür die komplette Webseite aktualisiert werden muss. Die Daten werden dabei in Form von
XML kodiert. In der Praxis wird anstatt von XML oft JSON (Javascript Object Notation) als Schnittstellenformat verwendet.
Es existieren zahlreiche Frameworks für Java Script, die die Programmierarbeit
wesentlich vereinfachen und mit wenigen Befehlen komplexe Animationen ermöglichen.
Anhang
G.5
86
Audio und Video im Browser
Die bisher einzig mögliche Variante um audiovisuelle Medien im Browser auszugeben, war es ein Plugin dafür einzusetzen. Solche gibt es für verschiedene Audiound Videoformate, die bekanntesten darunter sind Windows Media, Quicktime und
Real Media. Der Trend geht jedoch in die Richtung, ein Flash-Plugin zum Abspielen
solcher Medien zu verwenden, welches mittlerweile den höchsten Verbreitungsgrad besitzt. [WWW30] Neben dem Vorteil der hohen Reichweite besteht zudem
die Möglichkeit, das Aussehen des Players zu gestalten, was in den anderen Fällen
nur schwer bis gar nicht realisierbar ist.
Mit HTML 5 wird es bald eine zusätzliche Variante geben Audio und Video in den
Browser einzubetten. Der neu entwickelte Standard sieht vor, dass Browser diese
Medien in Zukunft ohne Plugin abspielen können. Die aktuellen Versionen von
Firefox und Safari haben diese Technologie bereits eingeführt, doch gibt es noch
Streitigkeiten zwischen den Browser-Herstellern bezüglich der unterstützten Formate, sodass ein einheitlicher Standard noch etwas auf sich warten lassen wird.
[WIKI11]

Diplomarbeit - der ganze bazen

Transcription

Similar documents

Betriebsinformatik-Projekt — Virtuelle und simulierte Realitäten

PDF der Sonderpublikation

Rangliste Gesamt für Mittwoch - MOPO Team

Transformation SSA-basierter Zwischensprachen

Gemeinde Sylt

Suchmaschinenmarketing - Controlling im SEM