Diplomarbeit - der ganze bazen
Transcription
Diplomarbeit - der ganze bazen
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] Entwicklung der Anwendung 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 Entwicklung der Anwendung 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 Entwicklung der Anwendung 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]. Entwicklung der Anwendung 4.1.4 Models/Filter Abbildung 11: UML Sequenzdiagramm - Controller, Models, Backend 35 Entwicklung der Anwendung 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. Entwicklung der Anwendung 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. Entwicklung der Anwendung 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. Entwicklung der Anwendung 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 Entwicklung der Anwendung 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 Entwicklung der Anwendung 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). Entwicklung der Anwendung 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. Entwicklung der Anwendung 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. Entwicklung der Anwendung 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 Entwicklung der Anwendung 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. Entwicklung der Anwendung 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 Entwicklung der Anwendung 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. Entwicklung der Anwendung 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] Entwicklung der Anwendung 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. Entwicklung der Anwendung 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- Entwicklung der Anwendung 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. Entwicklung der Anwendung 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] Entwicklung der Anwendung 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ä- Entwicklung der Anwendung 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. Entwicklung der Anwendung 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 Entwicklung der Anwendung 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] Erweiterbarkeit der Anwendung 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] Erweiterbarkeit der Anwendung 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 Vor- und Nachteile der Anwendung 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. Vor- und Nachteile der Anwendung 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] Vor- und Nachteile der Anwendung 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- Vor- und Nachteile der Anwendung 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 Vor- und Nachteile der 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] Vor- und Nachteile der Anwendung 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] Vor- und Nachteile der Anwendung 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 `audio` -CREATE TABLE IF NOT EXISTS `audio` ( `id` int(11) NOT NULL auto_increment, `user` 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, `artist` varchar(255) NOT NULL, `album` 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 (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=240 ; -- ---------------------------------------------------------- Tabellenstruktur für Tabelle `audio_tags` -CREATE TABLE IF NOT EXISTS `audio_tags` ( `id` int(11) NOT NULL auto_increment, `title` varchar(255) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=6 ; -- ---------------------------------------------------------- Tabellenstruktur für Tabelle `audio_tags_mxm` -CREATE TABLE IF NOT EXISTS `audio_tags_mxm` ( `audio` int(11) NOT NULL, `tag` int(11) NOT NULL, PRIMARY KEY (`audio`,`tag`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1; -- ---------------------------------------------------------- Tabellenstruktur für Tabelle `playlists` -CREATE TABLE IF NOT EXISTS `playlists` ( `id` int(11) NOT NULL auto_increment, `title` varchar(255) NOT NULL, `user` int(11) NOT NULL, `deleted` tinyint(1) NOT NULL, `tstamp` int(11) NOT NULL, `crdate` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=17 ; -- ---------------------------------------------------------- Tabellenstruktur für Tabelle `playlists_entries` Anhang 80 -CREATE TABLE IF NOT EXISTS `playlists_entries` ( `id` int(11) NOT NULL auto_increment, `playlist` int(11) NOT NULL, `audio` int(11) NOT NULL, `sorting` int(11) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=238 ; -- ---------------------------------------------------------- Tabellenstruktur für Tabelle `users` -CREATE TABLE IF NOT EXISTS `users` ( `id` int(11) NOT NULL auto_increment, `upload_dir` varchar(255) NOT NULL, `email` varchar(255) NOT NULL, `name` varchar(255) NOT NULL, `deleted` int(11) NOT NULL, `crdate` int(11) NOT NULL, `tstamp` int(11) NOT NULL, `password` varchar(40) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=2 ; 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: [email protected] 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]