Architektur und Design eines PHP4

Transcrição

Architektur und Design eines
PHP4-basierten Frameworks für
Webapplikationen
Andreas Langegger
DIPLOMARBEIT
eingereicht am
Fachhochschul-Diplomstudiengang
Medientechnik und -design
in Hagenberg
im August 2003
© Copyright 2003 Andreas Langegger
Alle Rechte vorbehalten
ii
Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und
ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht
benutzt und die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet
habe.
Hagenberg, am 3. September 2003
Andreas Langegger
iii
Inhaltsverzeichnis
Erklärung
iii
Vorwort
vii
Kurzfassung
viii
Abstract
ix
1 Einleitung und Motivation
1.1 Das dynamische World Wide Web
1.2 Einsatz von Webapplikationen . . .
1.3 Frameworks für Webapplikationen
1.4 Warum PHP? . . . . . . . . . . . .
1.4.1 PHP ist erwachsen . . . . .
1.4.2 PHP im Web-tier . . . . . .
1.4.3 Kosten . . . . . . . . . . . .
1.4.4 PHP Version . . . . . . . .
1.5 Kapitelbeschreibung . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
3
4
5
6
6
7
8
2 Problemstellung
2.1 Begriffsdefinition: Framework . . . . . . . . . . . . .
2.2 Anforderungen an ein Framework . . . . . . . . . . .
2.2.1 Handhabung und Effizienz . . . . . . . . . . .
2.2.2 Erweiterungs- und Integrationsmöglichkeiten
2.2.3 Sicherheitsaspekte . . . . . . . . . . . . . . .
2.3 Bestehende Frameworks für Webappikationen . . . .
2.3.1 Frameworks für PHP . . . . . . . . . . . . . .
2.3.2 Frameworks für Java . . . . . . . . . . . . . .
2.3.3 Ergebnis der Analyse . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
10
11
11
11
12
16
17
3 Entwicklung von Webapplikationen
3.1 Web Engineering . . . . . . . . . . . . .
3.2 Architektur von Webapplikationen . . .
3.2.1 Client/Server-Kommunikation . .
3.2.2 Zustandslose Verbindung . . . .
3.2.3 Mehrschichtige Architektur . . .
3.2.4 Website und Webapplikation . .
3.2.5 Skript-basierte Webapplikationen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
20
21
22
22
23
24
25
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
3.3
3.4
v
Modellierungskonzepte . . . . . . . . . . . . . . . . . . .
3.3.1 Dimensionen und Ebenen im Web Engineering .
3.3.2 Historischer Überblick . . . . . . . . . . . . . . .
3.3.3 Das OOHDM-Konzept . . . . . . . . . . . . . . .
3.3.4 Das Konzept von J. Conallen . . . . . . . . . . .
Modellierung auf Basis der Architektur von DaVinci . .
3.4.1 Vereinfachung der Architektur . . . . . . . . . . .
3.4.2 Überwindung des Hyper-Paradigmas . . . . . . .
3.4.3 Model-View-Controller Pattern . . . . . . . . . .
3.4.4 Modellierung auf Basis des DaVinci Frameworks
4 Framework für Webapplikationen
4.1 Architektur im Überblick . . . . . . . . . . . .
4.1.1 Komponenten . . . . . . . . . . . . . . .
4.2 Benutzerinteraktion . . . . . . . . . . . . . . . .
4.2.1 FrontController . . . . . . . . . . . . . .
4.2.2 Abbildung von URLs auf Aktionsklassen
4.2.3 Die Klasse ActionManager . . . . . . . .
4.2.4 DaVinci Aktionsklassen . . . . . . . . .
4.2.5 Rechteverwaltung . . . . . . . . . . . . .
4.3 Applikationslogik . . . . . . . . . . . . . . . . .
4.3.1 DaVinci Model-Klassen . . . . . . . . .
4.4 Darstellung von Inhalten . . . . . . . . . . . . .
4.4.1 Szenegraph-Modell und View-Bäume . .
4.4.2 Daten für Views . . . . . . . . . . . . .
4.4.3 View-Skripts . . . . . . . . . . . . . . .
4.4.4 Der View-Generator . . . . . . . . . . .
4.4.5 Unterschiedliche Ausgabeformate . . . .
4.5 Datenhaltung . . . . . . . . . . . . . . . . . . .
4.5.1 Repositories . . . . . . . . . . . . . . . .
4.5.2 Die Klasse StorageBridge . . . . . . . .
4.5.3 Verwaltung der Datenbankverbindungen
4.5.4 Datenbankabstraktion . . . . . . . . . .
5 DaVinci in der Praxis
5.1 Anforderung . . . . . . . . . . . . . . . . . . . .
5.2 Modellierung einer Webapplikation mit DaVinci
5.2.1 Die Benutzeroberfläche . . . . . . . . . .
5.2.2 Erforderliche Aktionen . . . . . . . . . .
5.2.3 Repositories zur Datenhaltung . . . . .
5.2.4 Applikationslogik . . . . . . . . . . . . .
5.3 Implementierung . . . . . . . . . . . . . . . . .
5.3.1 Konfiguration und Benutzeroberfläche .
5.3.2 Aktionsklassen . . . . . . . . . . . . . .
5.3.3 Repositories . . . . . . . . . . . . . . . .
5.3.4 Implementierung der Models . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
28
31
35
38
39
41
44
47
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
50
51
51
53
54
54
57
57
59
60
60
63
64
64
65
65
65
67
68
68
.
.
.
.
.
.
.
.
.
.
.
69
69
69
70
72
73
74
74
74
76
76
76
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
vi
6 Evaluierung
6.1 Qualitative Beurteilung anhand der definierten Anforderungen .
6.1.1 Handhabung und Effizienz . . . . . . . . . . . . . . . . .
6.1.2 Erweiterungs- und Integrationsmöglichkeiten . . . . . .
6.2 Stärken und Schwächen . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Stärken . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Schwächen . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
77
77
77
78
78
78
79
7 Ausblick
7.1 Erweiterungsmöglichkeiten . . . . . . . . . .
7.1.1 Framework Architektur . . . . . . .
7.1.2 Unterschiedliche Ausgabeformate . .
7.1.3 Verwaltung und Werkzeuge über eine
7.1.4 Integration eines Applikationsservers
7.1.5 Webservices . . . . . . . . . . . . . .
7.2 Zusammenfassung . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
81
81
82
82
82
83
83
A Details zum DaVinci Framework
A.1 Verzeichnisstruktur der DaVinci Distribution . . . . . .
A.1.1 Mehrere Webapplikationen auf einem Server . . .
A.1.2 DaVinci bei einem Webspace-Provider betreiben
A.2 Umgebungsvariablen . . . . . . . . . . . . . . . . . . . .
A.3 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . .
A.3.1 Konfiguration des Servers: davinci.xml . . . . . .
A.3.2 Konfiguration der Webapplikation . . . . . . . .
A.4 DaVinci Datentypen . . . . . . . . . . . . . . . . . . . .
A.4.1 Typenkonvertierung von Request-Parametern . .
A.4.2 Typenkonvertierung von und zu Datenbanken . .
A.5 Repository API . . . . . . . . . . . . . . . . . . . . . . .
A.5.1 Erstellen von repositories . . . . . . . . . . . . .
A.5.2 Offline-Manipulation von Einträgen . . . . . . . .
A.5.3 DB-Manipulation von Einträgen . . . . . . . . .
A.5.4 Die Klasse RepositoryManager . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
85
85
86
86
87
87
88
90
90
90
91
91
92
93
94
B Quellcode
B.1 Hilfsaktion zum Erstellen der repositories . . . . . . . . . . . . . . .
B.2 SetModule als beispielhafte Aktionsklasse . . . . . . . . . . . . . . .
B.3 Links model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
97
98
99
. . . . .
. . . . .
. . . . .
Konsole
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
Inhalt der CD-ROM
102
Literaturverzeichnis
103
Vorwort
Die Philosophie des World Wide Webs im Allgemeinen, die Architektur, die Möglichkeiten im weltweiten Netzwerk und seine Zukunft beschäftigen mich bereits über
mehrere Jahre. Ich bin überzeugt, dass Web-basierten Applikationen und den sogenannten Webservices in nächster Zukunft noch eine größere Bedeutung zukommen wird. Das WWW ist die weltgrößte Internet-Applikation welche auf einem
einheitlichen Standard beruht. Der Browser dient als einheitliche Benutzerschnittstelle und HTTP als uniformes Kommunikationsprotokoll. Webapplikationen ermöglichen im Vergleich zu anderen Client/Server-Anwendungen eine viel kostengünstigere und schnellere Implementierung von kollaborativen und ubiquitären Anwendungen. Durch die wachsende Bandbreite des Internets und durch Erweiterungen der
Browserfunktionalität werden in Zukunft die zur Zeit noch existierenden Nachteile
beseitigt werden.
Ich hoffe dass das DaVinci Framework weiterlebt und sich einige Open Source
Entwickler finden, die sich am Projekt beteiligen möchten.
Abschließend möchte ich vor allem meinen Eltern für die Geduld, Liebe und moralische Unterstützung während meines gesamten Studiums danken. Großer Dank
gilt meinem Vater, für das Korrekturlesen der Arbeit und meinem Freund Gerald für
den genialen Projektnamen DaVinci. Außerdem möchte ich auch meinem Professor Dipl. -Ing. Rimbert Rudisch für die große Unterstützung während meiner Arbeit
danken. Ich bedanke mich bei all meinen Freunden, welche mich während den arbeitsreichen Monaten immer wieder für Freizeitaktivitäten zum Ausgleich begeistern
konnten.
vii
Kurzfassung
Aktuelle Technologien und Entwicklungen im World Wide Web eröffnen zahlreiche
neue Möglichkeiten für ubiquitäre Client/Server-Anwendungen. So machen sich bereits viele vernetzte Anwendungen das standardisierte Internetprotokoll HTTP zu
Nutze und verwenden den Webbrowser als uniforme Benutzerschnittstelle. Kollaborationstools, Warenwirtschaftssysteme, business-to-business Anwendungen, Portale
und Web-basierte Informationsdienste seien als Beispiele für derartige Webapplikationen genannt.
Die vorliegende Diplomarbeit befasst sich mit der Entwicklung eines sogenannten Frameworks als Entwicklungsumgebung für Webapplikationen. Ein Schwerpunkt
wird unter anderem auf die Modellierung und den Engineering-Prozess von Webapplikationen im Allgemeinen gelegt. Dazu werden auch einige vorliegende Konzepte
diskutiert und bewertet.
Was die Architektur des Frameworks betrifft, wird auf das aus der Computergrafik bewährte Szenengraphen-Modell zurückgegriffen. Es wird für die Verwaltung
der Benutzeroberfläche eingesetzt. Die Interaktion zwischen Browser und Webapplikation erfolgt nach einem speziellen Schema. Web-Adressen verweisen nicht wie
gewohnt auf einzelne Seiten oder Dateien, sondern spezifizieren Interaktionen. Eine
Interaktion kann beispielsweise eine Änderung der Navigation sein, wobei in diesem
Fall die Benutzeroberfläche durch eine Modifikation des Szenegraphen geändert wird.
Eine Interaktion kann aber auch Daten zum Server übertragen. Interessant ist auch,
dass eine Interaktion durch ein Webservice implementiert werden kann.
Das Framework wurde für Skript-basierte Sprachen entwickelt und im Konkreten für PHP4 implementiert. Es wurde im April 2003 unter dem Namen DaVinci
als Open Source Projekt gestartet. Es wird beabsichtigt das Projekt auch in Zukunft weiter zu entwickeln. Dazu wurde unter http://phpdavinci.sf.net eine eigene
Homepage eingerichtet.
viii
Abstract
Recent developments in the area of web technology are opening new opportunities
for the deployment of ubiquitous client/server applications. Today many networked applications make use of the standardized Hypertext Transfer Protocol and web
browsers for the user interface since these technologies are accessible from all around
the world. The World Wide Web was originally developed to display web pages and
share information. Different strategies are currently evolving to expand the possibilities of the WWW. Collaborative tools, business-to-business applications, portals
and Web-based information services are considered to be examples for such Web
applications.
This diploma thesis deals with the development of a so-called framework as a
development environment for Web applications. Since the modelling and engineering
process is a very important aspect, some different modelling concepts are analysed
and evaluated.
The architecture of the framework also plays an important role. Concerning
this, various concepts are being derived, in some cases from other fields of research.
For instance, the scenegraph-model, which is used in computer graphics, has been
adapted for the user interface displayed by the Web browser. For the interaction
between browser and Web server Java’s extended Model-View-Controller Model 2
concept is being used. Internet addresses no longer refer to file-based document
resources, rather they define a specific action which can be performed in the system.
This can be an action modifying application state (for example the scenegraph) or an
action which sends data to the server. More sophisticated actions could implement
XML-based Web Services.
The framework is designed for script-based server-side programming languages
and has been implemented for PHP4 in particular. The project started in April,
2003 under the name DaVinci at SourceForge.net and is licensed as Open Source
software under the GPL. Since further development of the framework is intended,
there is also a website accessible at http://phpdavinci.sf.net.
ix
Kapitel 1
Einleitung und Motivation
War das World Wide Web (WWW oder auch Web genannt) anfangs für kooperative Arbeit und den Austausch von Textdokumenten, Bildern und Datei-Downloads
entworfen worden, so hat es sich bis heute soweit entwickelt, dass vollständige Anwendungen per Browser weltweit erreichbar sind. Die Entwicklung derartiger Webapplikationen unterscheidet sich heute kaum mehr vom traditionellen Software Engineering, und es lassen sich auch sämtliche Werkzeuge und bewährte Design- und
Entwicklungstechniken, in einer für das Web Engineering1 adaptierten Form, anwenden.
Die Entwicklung einer Programmierumgebung für Webapplikationen soll Thema
dieser Diplomarbeit sein. Im Rahmen der Arbeit wurde die Entwicklung des DaVinci Frameworks begonnen. Es wurde als Open Source Projekt unter der GNU
General Public Licence2 zur Verfügung gestellt. Die Projekt-Homepage ist auf SourceForge.net3 unter der URL http://phpdavinci.sf.net erreichbar.
1.1
Das dynamische World Wide Web
Durch die Entwicklung von Server-seitigen Skript- und Programmiersprachen hat
sich das World Wide Web vom statischen Informationsmedium, welches vorwiegend aus HTML-Seiten bestand, zu einem interaktiven Informationsnetzwerk weiterentwicklet (siehe dazu [LCC+ 03, KRP+ 02]). Zahlreiche Skript- und Programmiersprachen ermöglichen die Bereitstellung von dynamischen und in hohem Maße
interaktiven Webseiten [Zol01]. Abbildung 1.1 zeigt verschiedene Technologien der
Webserver-Programmierung und Datenbankanbindung.
HTTP4 als weltweit verwendetes Internetprotokoll und der Webbrowser als plattformunabhängige Clientsoftware werden heute häufig für Applikationen mit unterschiedlicher Komplexität verwendet. Im heutigen World Wide Web wird Information nicht nur mehr bloß dargestellt, sondern dynamisch generiert und verarbeitet.
1
Der aus dem Englischen übernommene Begriff engineering verdeutlicht den Entwicklungsprozess
hinter der Erstellung von Webapplikationen, ähnlich wie im Software Engineering.
2
Siehe http://www.opensource.org/licenses/gpl-license.php.
3
SourceForge.net ist die weltgrößte Plattform für Open Source Entwicklung im Internet. Von den
Betreibern werden für Open Source Projekte neben einem Webspace zahlreiche nützliche Werkzeuge
gratis zur Verfügung gestellt.
4
Hypertext Transfer Protocol, Spezifikation in RFC2616 [FGM+ 99].
1
KAPITEL 1. EINLEITUNG UND MOTIVATION
2
Abbildung 1.1: Webserver-Programmierung. Aus [Con03].
firewall
EJB Container
enterprise bean
client
client
enterprise bean
enterprise bean
Enterprise
Information
Systems
(RDBMS,
ERP, Legacy
Applications)
Web
Container
(Servlets,
JSP Pages,
HTML, XML)
JNDI,
JMS,
JavaMail
client
Client Tier
Middle Tier
EIS Tier
Abbildung 1.2: Java-basierte Multi-tier Umgebung. Aus [SSJ02, S. 6].
Webserver stellen nicht nur statische Dateien wie etwa HTML-Texte und Bilder bereit, sondern ermöglichen die Einbindung von Skripten und (kompilierten) Programmen. Neuere Technologien, wie etwa Java-Servlets, welche in einem sogenannten
Servlet Container (siehe [SSJ02, Kap. 4]) persistent laufen, sprengen die Grenzen
der einfachen, zustandslosen HTTP-Verbindung und ermöglichen die Implementierung von aufwändigen Webapplikationen. In Abbildung 1.1 ist eine Java-basierte
Architektur für Webapplikationen dargestellt. Die Grafik zeigt eine mehrschichtige
Umgebung mit Client Tier, Web- und Applikationsserver (Middle Tier) und einer
Datenbank-/Integrationsschicht (EIS Tier 5 ).
Integrationstechnologien (vgl. CORBA6 , DCOM7 , SOAP8 ) verschmelzen unterschiedliche Plattformen und ermöglichen die Integration verschiedenster, auch veral5
Enterprise Information Systems: das IT-System eines Unternehmens.
Common Object Request Broker Architecture der Object Management Group (OMG), siehe
http://www.omg.org.
7
Distributed Component Object Model von Microsoft, siehe http://www.microsoft.com/com/
tech/DCOM.asp.
8
Simple Object Access Protocol, siehe http://www.w3.org/TR/SOAP.
6
3
teter Ressourcen in die Applikation.
Die Idee von sogenannten selbstorganisierenden Web Services [Cer02, Pre02] verdeutlicht eine Entwicklung des WWW zu einem dynamischen Applikationsnetzwerk.
Natürlich wird es auch in Zukunft weiterhin statische Informationsseiten geben.
Diese sind jedoch häufig bereits selbst Produkt von dynamischen Prozeduren in
Web-basierten Applikationen (man denke etwa an Web Content Management Systeme oder auch an kleinere, Datenbank-gestützte Websites).
1.2
Einsatz von Webapplikationen
Das World Wide Web eignet sich hervorragend als Netzwerk für verteilte, gemeinsam
genutzte Anwendungen. So ist die Software über den Webbrowser weltweit und auf
vielen verschiedenen Plattformen verfügbar [St02]. Da dieselben Technologien zumeist auch auf mobilen Geräten (PDAs, Mobiltelefonen) verfügbar sind, können die
Anwendungen realtiv leicht auch für diese Clients angepasst werden. Vor allem im
Intra- und Extranet hat sich die Verwendung von Webapplikationen stark verbreitet.
Die Palette reicht von Web-basierten E-Mail Clients und Projektmanagement-Tools
bis zu aufwändigen Warenwirtschaftssystemen im B2B-Bereich9 . Tabelle 1.1 zeigt
einige klassische Szenarien für Webapplikationen, in verschiedenen Kategorien gegliedert.
1.3
Frameworks für Webapplikationen
Da Webapplikationen immer komplexer werden und damit deren Einsatz für geschäftliche Zwecke kritischer wird, ist auch die Planung und Modellierung solcher Applikationen wichtiger denn je [GM01, Ude02, PSRO02]. Design- und Entwicklungsmethoden des traditionellen Software Engineerings können, kombiniert mit HypermediaModellierungsmethoden für die Entwicklung von Webapplikationen herangezogen
werden.
Eine weitere Notwendigkeit ist, dass der Implementierungsaufwand derartiger
Projekte möglichst niedrig bleibt. Einmal entwickelte Komponenten sollten auch für
weitere Projekte adaptiert und wieder verwendet werden können [CFM02]. Im ITMarkt ist eine just-in-time Produktion bei möglichst geringen Kosten die Grundvorraussetung für den Erfolg eines Produktes. Mehrfach benötigte Softwarekomponenten
müssen wiederverwendet werden können und Architekturen sollten nicht ständig neu
erfunden werden müssen. Entwicklungsumgebungen unterstützen den Engineeringprozess und bieten zahlreiche Werkzeuge und APIs10 für die Implementierung neuer
Applikationen. Solche Umgebungen bauen auf einer bewährten Architektur auf und
ermöglichen in Folge die adaptive Entwicklung verschiedenster Anwendungen.
Im Zusammenhang mit dieser Arbeit sei als Framework eine derartige Entwicklungsumgebung für Webapplikationen gemeint. Der Entwurf und die Implementierung eines Frameworks für Webapplikationen mit PHP4 ist Teil dieser Diplomarbeit.
Das entwickelte Framework trägt den Namen DaVinci und wurde als Open Source
9
Business-to-business (B2B) steht im Gegensatz zu B2C (business-to-consumer) für Geschäfte
zwischen Unternehmen.
10
API steht für application programming interface und stellt eine Bibliothek an Funktionen dar,
welche die Einbindung einer Softwarekomponente ermöglichen.
Content
Management
Kommunikation,
Communities
Marketing,
Promotion
Online-Handel,
Online
Versandhäuser
Support und
Kundenbetreuung
Projektmanagement,
Intranets
Frontends zu
verschiedener
Software im
Unternehmen
4
klassische Homepage, Internet-Präsenz
Nachrichten, Magazine
Dokumentenverwaltung, Mediendatenbanken
Suchmaschinen, Verzeichnisdienste
Chat, Foren, Web-basiertes E-Mail, etc.
Newsletter
E-Cards
Web-basierte Support Center, Customer Relationship
Online Werbung, Bannerdienste
Gewinnspiele, Aktionen
Produktpromotions, Ankündigungen
Anmeldesysteme für Veranstaltungen, Kongresse
klassisches E-Commerce
Auktionsplattformen (wie z.B. ebay)
E-Procurement (Anschaffung von Sekundärgütern)
Business-to-business Handel
Internet Banking, Electronic Cash
Call-Centers, Support-Centers
Software Download-Centers
Informationsdienste
Öffentliche Dienste, Bürgerservice
Kollaborationstools, Intra-/Extranets
Messaging Server
Bugtracking Systeme
Zeit- und Ressourcenplanung
Termine, Kalender
Community Tools (vgl. auch Kategorie Kommunikation)
Warenwirtschaft, Logistik, Supply-Chain Management
Kundendatenbanken, Produktdatenbanken
Marketing und Vertrieb (vgl. Kategorie Marketing
Lohnverrechnung, Urlaubsplanung
Projektmanagement
vgl. auch Software von SAP (http://www.sap.de)
Tabelle 1.1: Szenarien verschiedener Webapplikationen
Projekt unter der GNU General Public License auf SourceForge.net veröffentlicht.
Es wird damit beabsichtigt, interessierte Entwickler anzusprechen, die sich an der
Weiterentwicklung des Frameworks beteiligen wollen. Die Homepage des Projekts
ist unter http://phpdavinci.sf.net erreichbar.
1.4
Warum PHP?
PHP bietet als Skriptsprache zur Erzeugung von dynamischen Webseiten sehr viele
Vorteile und hat bereits einen beachtlichen Funktionsumfang, welcher mit neuen
5
Abbildung 1.3: Integration von Java. Aus [Sun02a].
Erweiterungen (Extensions11 ) auch selbst erweitert werden kann. Als Skriptsprache
für Webapplikationen ist PHP bestens geeignet und die Geschwindigkeit von PHP ist
ein weiterer Pluspunkt. Yahoo! startete beispielsweise im September 2002 mit dem
Einsatz von PHP für die von 1,4 Millionen Usern pro Tag besuchte Plattform [Rad02].
PHP eignet sich durch seine Stärken in der dynamischen Generierung von Content
und durch die vielseitigen Integrationsmöglichkeiten vor allem für den Einsatz im
Frontend-Bereich (Web-tier, siehe auch Abschnitt 1.4.2) und 3.2.3).
1.4.1
PHP ist erwachsen
Viele der gegen PHP gerichteten Argumente sind sehr oft unrichtig und resultieren aus einer unzureichenden Kenntnis und einem falschen Eindruck der Sprache.
PHP hinterlässt bei Außenstehenden oft den Eindruck als „Kindersprache“. Dies
rührt vor allem daher, dass sich PHP durch die einfache Erlernbarkeit sehr rasch
an großer Beliebtheit erfreute und somit auch viele Amateur-Programmierer angezogen hat. Die professionellen Möglichkeiten von PHP bleiben dabei oft unbeachtet.
Björn Schotte, Gründer der deutschen Firma ThinkPHP (http://www.thinkphp.de)
und seit 1998 Mitglied der PHP Community, hat in einer Präsentation über PHP im
E-Business [Sch03] auf der CeBit 2003 viele dieser falschen Argumente widerlegen
können. Auch er ist der Meinung, dass die Bedeutung von PHP (v.a. ab der neuen
Version 5) in den nächsten Jahren stark zunehmen wird.
Durch die Möglichkeit der Integration von Java12 kann auch ein Java-basierter
Applikationsserver angebunden werden. Abbildung 1.3 zeigt ein solches Szenario.
Die Applikationslogik befindet sich hier auf einem J2EE-Applikationsserver. Über
11
PHP Extensions erweitern als C-basierte Funktionsbibliotheken den Befehlssatz.
Dank Sam Ruby gibt es eine PHP Extension, die es erlaubt Java-Objekte einzubinden. Die
Erweiterung ist im PHP-Quellcode enthalten und muss beim Kompillieren aktiviert werden.
12
6
die Java Extension kann PHP Java-Objekte ansprechen. Die Ausgabeseiten werden
dann beispielsweise mit PHP generiert.
Es ist auch möglich PHP als Servlet in einem Servlet-fähigen Webserver zu verwenden [The03a, Abschnitt XLVII.]. Sogar die Integration von SAP/R3 Systemen
ist mit PHP möglich13 . Externe Komponenten können auch über diverse Integrationstechnologien wie z. B. XML/RPC oder SOAP angebunden werden.
1.4.2
PHP im Web-tier
Da PHP eine Skriptsprache ist und jedes PHP-Skript nach dem Ausführen zur Gänze
aus dem Hauptspeicher gelöscht wird, ergeben sich allerdings einige Probleme bei
der Implementierung eines rein auf PHP basierten Applikationsservers. Der gesamte
Applikationsstatus und alle Daten, die während einer Sitzung fortwährend benötigt
werden, müssen bei jeder HTTP-Anfrage neu initialisiert und in den Hauptspeicher
zurückgeholt werden. Diese Daten müssen vorübergehend im Dateisystem oder etwa
in einer Datenbank zwischengespeichert werden. Die Verwendung von Shared Memory Funktionen [SS02] bietet im Übrigen nicht ausreichend Stabilität und kann
jenes Manko nicht ersetzen.
Aufgrund dieser Nachteile ist der Einsatz von PHP auf einem reinen Applikationsserver weniger geeignet. Da der business state (der „Status“ der Applikation zu
einem bestimmten Zeitpunkt) über längere Zeit erhalten bleiben muss – auch außerhalb einzelner HTTP-Anfragen – ist ein PHP-basierter Applikationsserver prinzipiell
tabu. Im Allgemeinen sind alle Skriptsprachen für Applikationen mit aufwändiger
business logic ungeeignet, da die Laufzeit zur Ausführung des Skripts begrenzt ist.
PHP ist hingegen für den Einsatz im Frontend (Web-tier) bestens geeignet. Die
größte Stärke von PHP liegt in der Generierung von dynamischen Webseiten. Skriptsprachen und vor allem jene, die Skriptlet-Elemente unterstützen (damit ist die Einbettung von Code-Elementen innerhalb einer HTML-Datei gemeint, wie sie auch
bei JSP-Seiten möglich ist) bieten im Web-Einsatz einige Vorteile. Zudem müssen
Skriptdateien nicht ständig neu kompiliert werden.
Jenes Ausmaß an Applikationslogik, welches im Web-tier benötigt wird, kann
auch sehr gut mit PHP realisiert werden. Durch die zahlreichen Integrationsmöglichkeiten können verschiedenste externe Ressourcen angebunden werden.
1.4.3
Kosten
Der große Vorteil von PHP (meist in Verbindung mit dem Open Source Datenbanksystem MySQL14 ) ist immer noch der weitverbreitete Einsatz auf Servern von
Webspace-Providern (siehe Abbildung 1.4). Heute findet sich kaum noch ein Webspace ohne PHP/MySQL-Unterstützung. Die PHP/MySQL-Kombination ist momentan die kostengünstigste Lösung für dynamische Websites mittlerer Größe.
Viele Webapplikationen mittlerer Komplexität können auch ohne kostenintensivem Applikationsserver in einer zusätzlichen Mittelschicht (Middle-tier), implementiert werden. Vor allem in Zeiten stagnierender Konjunktur, welche insbesondere
im IT-Sektor momentan sehr stark zu spüren ist, spielen die Entwicklungskosten
13
Hartmut Holzgraefe begann 2001 die Entwicklung einer Extension für die Anbindung an
SAP/R3-Systeme. Das Projekt ist unter http://saprfc.sourceforge.net zu finden.
14
Siehe http://www.mysql.com.
7
Abbildung 1.4: Anzahl an Hosts mit Unterstützung von PHP. Aus [The03b].
derartiger Anwendungen eine entscheidende Rolle. Die Kosten von PHP-Lösungen
sind für den Endkunden in der Regel niedriger als beispielsweise für Java-Lösungen,
da viele PHP Extensions und Bibliotheken gratis zur Verfügung stehen [Sch03]. Ist
eine aufwändige business logic gefordert, kann diese auch integriert werden. Eine
derartige Lösung würde beispielsweise den Anforderungen vieler Klein- und Mittelunternehmen genügen.
Um die Vorteile von PHP nocheinmal zu summieren:
• PHP ist plattformunabhängig und unterstützt zahlreiche Webserver.
• PHP hat eine sehr gute Performance.
• Die Implementierung ist kostengünstig.
• PHP bietet umfangreiche Funktionalität und ist erweiterbar.
• PHP ist auf Servern von Webspace-Providern sehr weit verbreitet.
• PHP wird sich vorraussichtlich noch weiter verbreiten.
1.4.4
PHP Version
Die Implementierung des DaVinci Frameworks erfolgte in der Version 4.3.x. Mit
Version 4 werden grundlegende Funktionen der objektorientierten Programmierung
unterstützt. Ab der Version 4.3 wird der PEAR-Installer, mit dem sich Pakete des
PEAR Projektes15 bequem per Kommandozeile verwalten lassen, mitgeliefert. Da
das DaVinci Framework einige dieser Pakete bzw. diverse Befehle die erst ab Version
4.3 zur Verfügung stehen, verwendet, fiel die Entscheidung auf die Version 4.3.x.
Frühere Versionen werden nicht mehr unterstützt.
Natürlich wäre eine Implementierung mit PHP5 und der neuen Zend Engine
2 [Zen01] (siehe auch http://www.zend.com/zend/future.php und http://www.php.
15
Das PEAR Projekt bietet eine umfangreiche Bibliothek an Erweiterungen und Klassen und gibt
unter anderem auch Notations- und Dokumentationrichtlinien vor. Siehe dazu http://pear.php.net.
8
net/zend-engine-2.php) wünschenswert. Da die Entwicklung eines stabilen PHP5 Release noch einige Monate in Anspruch nehmen wird, und eine Implementierung mit
nicht getestetem Code zu viel Zeit in Anspruch nehmen würde, wurde von dieser Möglichkeit jedoch abgesehen. Außerdem wird es nach der Veröffentlichung mindestens
noch ein Jahr dauern, bis sich PHP5 auch bei Webservice Providern durchgesetzt
hat.
Es wurde aber dennoch versucht, die Klassen bereits im Hinblick auf die neuen
Fähigkeiten von PHP5 zu erstellen um zu einem späteren Zeitpunkt das Framework
leichter portieren zu können.
1.5
Kapitelbeschreibung
Die vorliegende Arbeit unterteilt sich in sieben Kapitel. Das erste Kapitel dient
zur Motivation und führt in das Thema der Arbeit ein. Im zweiten Kapitel wird
die eigentliche Problemstellung erörtert. Zu Beginn wird der Begriff Framework im
gegebenen Kontext definiert. Anschließend werden Anforderungen an ein solches
Framework für Webapplikationen besprochen. Schließlich werden einige existierende
Projekte für Java und PHP erwähnt.
Der Inhalt des dritten Kapitels beschreibt Modellierungskonzepte welche die Entwicklung von Webapplikationen unterstützen. Solche Konzepte sind als Grundlage
für ein Framework von entscheidender Bedeutung. Es wird unter anderem auf die
Wichtigkeit der Modellierung und des gesamten Entwicklungsprozesses, welcher neuerdings auch mit dem Begriff Web Engineering bezeichnet wird, hingewiesen. Zwei
Modellierungskonzepte werden näher beleuchtet: OOHDM (Object-oriented Hypermedia Design Method) [RSG99] als Repräsentant eines aus der Hypermedia-Domäne
stammenden Konzepts und das Konzept nach Jim Conallen [Con03], welches eher
der Software Engineering Domäne entspringt. Abschließend wird versucht ein einfaches Modellierungskonzept zu finden, welches auf Basis von UML für das Framework
eingesetzt werden kann.
In Kapitel vier wird das DaVinci Framework entworfen. Ausgehend von den
Erkenntnissen aus Kapitel vier wird die Architektur mit ihren Komponenten spezifiziert. Die einzelnen Komponenten zur Benutzerinteraktion, Applikationslogik,
Darstellung von Inhalten und Datenhaltung werden in einzelnen Abschnitten erläutert.
Die Demonstration des Frameworks anhand einer kleinen Webapplikation ist Inhalt des fünften Kapitels. Es wird eine Art „persönliche Startseite“ entwickelt, welche
als Startseite im Browser eingerichtet werden kann und neben einer definierbaren
„Homepage“ ein Adressbuch und eine Link-Datenbank zur Verfügung stellt.
Im sechsten Kapitel wird das Framework anhand der im zweiten Kapitel definierten Anforderungen evaluiert. Es werden außerdem einzelne Stärken und Schwächen
aufgezeigt.
Das letzte Kapitel schließt die Arbeit mit einem Ausblick ab. Da beabsichtigt
wird das Framework als Open Source Projekt weiterzuentwickelen wurden einige Erweiterungsmöglichkeiten beschrieben, welche in Zukunft implementiert werden sollen. Die Zusammenfassung bietet einen abschließenden Überblick über die vorliegende Diplomarbeit.
Kapitel 2
Problemstellung
Ein Framework für Webapplikationen soll die Implementierung eines möglichst breiten Spektrums an Szenarien ermöglichen. Es muss eine grundlegende Softwarearchitektur auf Basis von bewährten Entwurfsmodellen geschaffen werden. Unter Verwendung des Frameworks soll der Entwickler nicht mehr mit alltäglichen Aufgaben
wie Entgegennahme von HTTP-Anfragen, Session-Behandlung, Datenbankverbindung, etc. konfrontiert werden, sondern er soll Webapplikationen auf einer höheren
Ebene modellieren können. Einmal implementierte Komponenten sollten außerdem
für weitere Projekte adaptiert werden können.
2.1
Begriffsdefinition: Framework
Das Oxford Quick Reference Dictionary [Tho96] übersetzt das Wort Framework kurz
als „Essential supporting structure, basis system“ (zu Deutsch: essentielles, unterstützendes Gerüst, Basissystem). Diese einfache Übersetzung ist eigentlich schon
sehr aussagekräftig, denn ein Framework ist im Allgemeinen nichts anderes, als ein
Grundgerüst. Das Grundgerüst einer Baustelle, das Skelett eines Menschen oder
aber auch die einer Applikation zugrundeliegende Architektur werden im Englischen
als Frameworks bezeichnet.
IBM versteht unter einem Applikationsframework folgendes [FV01]:
„An application framework describes a set of interacting components and
services available to an application, describes the responsibilities of components and services, and describes the interactions between the components and services. A developer creates an application by composing
and extending the components and services available in the application
framework.“
Demnach besteht ein Framework aus verschiedenen Softwarekomponenten, die
interagieren und voneinander abhängig sind und vom Entwickler je nach Bedarf
zusammengesetzt und erweitert werden können.
Die folgende Beschreibung eines Framework (hier konkret: Web-tier application
framework) ist noch eine Spur restriktiver und erhebt denn zusätzlichen Anspruch,
einer der Applikation zugrundliegenden Softwarearchitektur [SSJ02, Seite 92]. Die
Definition ist in diesem Kontext zwar speziell auf Java ausgerichtet, sie ist jedoch
generell von Bedeutung:
9
KAPITEL 2. PROBLEMSTELLUNG
10
„A Web-tier application framework sits on top of the J2EE platform, providing common application functionality such as dispatching requests, invoking model methods, and selecting and assembling views. Framework
classes and interfaces are structural; they are like the load-bearing elements of a building, forming the application’s underpinnings. Application
developers extend, use, or implement framework classes and interfaces to
perform application-specific functions. For example, a framework may
offer an abstract class that a developer may extend to execute business
logic in response to application events. A Web-tier application framework
makes Web-tier technologies easier to use, helping application developers
to concentrate on business logic.“
Ins Deutsche übersetzt, ist ein Web-tier application framework hier jene Schicht,
welche auf einem (hier: Java-basiertern) Applikationsserver aufsetzt und von dort
aus grundlegende Funkionalität für die Interaktion zwischen dem Browser und dem
Applikationsserver bereitstellt. Dazu gehören unter anderem die Behandlung eingehender HTTP-Anfragen, das Ausführen von Funktionen in den richtigen Komponenten und schließlich die Auswahl der entsprechenden Ansicht (HTML-Seite), welche
dem Benutzer nach der Interaktion zur Verfügung gestellt wird. Alle Klassen des Frameworks sind strukturell aufgebaut und können vom Entwickler je nach Anforderung
erweitert und adaptiert werden.
2.2
Anforderungen an ein Framework für Webapplikationen
Ein Framework für Webapplikationen muss eine rasche und kostengünstige Implementierung von Webapplikationen ermöglichen, sollte in der Praxis leicht anzuwenden sein und muss für eine Vielzahl an möglichen Applikationsszenarien tauglich
sein. Das Framework sollte zudem nicht nur eine Bibliothek an Klassen und Komponenten bereitstellen, sondern auch eine grundlegende Architektur vorgeben. Die
Architektur muss auf bewährte Modelle des Hypermedia- und Software Engineerings
zurückgreifen. Die Modellierung neuer Anwendungen auf Basis des Frameworks soll
in Folge auf einer höheren Ebene möglich sein.
2.2.1
Handhabung und Effizienz
Um auch für den praktischen Einsatz tauglich zu sein, darf das Framework nicht bloß
in der Theorie funktionieren. Gefordert wird nicht nur eine einfache Handhabung,
sondern auch eine möglichst hohe Effizienz bei der Implementierung neuer Anwendungen auf Basis des Frameworks. Es kann allerdings keine Umgebung geben, die
für alle nur denkbaren Problemstellungen Lösungen bietet. Es muss daher ein Kompromiss zwischen den Möglichkeiten des Frameworks und seiner Praxistauglichkeit
und Handhabung gefunden werden.
Das Framework soll vor allem auch den Modellierungsprozess neuer Applikationen
unterstützen, da mit dem Framework als Basis nicht mehr jedesmal ganz von vorne
begonnen werden muss. Die Modellierung muss auf einer höheren Ebene stattfinden
können, wodurch sich in Folge Zeit und Kosten einsparen lassen. Für das DaVinci
Framework wird ein Vorschlag für ein solches Konzept auf Basis von UML entwickelt.
2.2.2
11
Erweiterungs- und Integrationsmöglichkeiten
Vor allem bei einem Einsatz einer eigenen Web-tier Schicht, müssen verschiedene
externe Ressourcen, wie Datenbanksysteme oder (Java-basierte) Applikationsserver
integriert werden können. Insbesondere B2B-Applikationen erfordern oft die Integration fremder Ressourcen. Um die Integrationsmöglichkeiten zu gewährleisten, sollten
wenn möglich stets offene Standards verwendet werden. Dadurch werden Kompatibilität, eine gute Akzeptanz und Zukunftssicherheit erreicht.
Die Umgebung soll des Weiteren Möglichkeiten für zukünftige, zusätzliche Erweiterungen anbieten. Die Architektur muss daher so entworfen werden, dass zusätzliche
Komponenten zu einem späteren Zeitpunkt integriert werden können.
2.2.3
Sicherheitsaspekte
Der Einsatz von Webapplikationen erfordert, vor allem auch für geschäftliche Anwendungen, die Einbeziehung bestimmter Sicherheitsrichtlinien1 . Sicherheitsaspekte
sind unter anderem Zugriffsbeschränkungen für bestimmte Interaktionen, Authentifizierung des Benutzers und die Verschlüsselung von sensiblen Daten bei der Übertragung zwischen Client und Server.
Für die Authentifizierung kann sich eine Webapplikation das im HTTP-Protokoll
bereits vorgesehene Authentifizierungskonzept, welches z.B. von Apache unterstüzt
wird, zu Nutze machen [Cym00]. Die Zugriffsbeschränkung muss durch eine geeignete
Benutzer- und Rechteverwaltung realisiert werden. Sinnvoll scheint hier auch die
Integration von offenen Standards wie etwa LDAP2 . Die Verschlüsselung zwischen
Client und Server kann beispielsweise über das SSL-Protokoll stattfinden.
2.3
Bestehende Frameworks für Webappikationen
Für die Recherche wurden PHP- und Java-basierte Projekte betrachtet. Man erkennt
nach kurzer Zeit, dass es unter Entwicklern unterschiedliche Vorstellungen gibt was
ein Framework im Detail nun ausmacht. So beschränken sich vor allem viele PHPbasierte Frameworks lediglich auf eine Ansammlung von Klassen, die wiederverwendbare Utilites enthalten. Wo manche Entwickler derartige Klassenbibliotheken bereits
als Framework bezeichnen, ist für andere ein Framework eine grundlegende Applikationsarchitektur, nach der HTTP-Anfragen abgearbeitet und Seiten dargestellt
werden.
Es fällt auf, dass viele Java-Lösungen eher den zweiten Anspruch erheben. Viele
Java Frameworks basieren bereits auf dem Model-View-Controller Pattern3 (kurz
MVC) [SSJ02, Kap. 11.1.1] und sind modular aufgebaut. Dieser MVC Pattern gliedert Applikationen in drei Schichten: das model beschreibt und verwaltetet Daten,
views repräsentieren Daten und stellen Benutzerschnittstellen zur Verfügung, und
der controller übernimmt Benutzeranfragen und steuert die Interaktion und Manipulation der Daten (siehe dazu Abschnitt 3.4.3).
1
Siehe The Open Web Application Security Project: http://www.owasp.org.
Mit dem Lightweight Directory Access Protocol (LDAP) ist die Verwendung eines standardisierten, öffentlichen, gemeinsamen Adressbuches (Verzeichnisdienst) möglich. Siehe http://www.
openldap.org bzw. [WHK97].
3
Sogenannte Software design patterns dienen als Lösungsmuster für immer wiederkehrende Problemstellungen bei der Softwareentwicklung.
2
Projekt
Ampoliros
Ariadne
BinaryCloud
Blueshoes
eXtreme PHP
Horde
Liquid Bytes
Netautor
12
Internetadresse
http://www.ampoliros.com
http://freshmeat.net/projects/ariadne
http://www.binarycloud.com
http://www.blueshoes.org
http://www.extremephp.org
http://www.horde.org/horde
http://www.liquidbytes.net
http://www.netautor.com
Tabelle 2.1: PHP-basierte Frameworks für Webapplikationen.
Da Java von Grund auf objektorientiert ist, ist man von vornherein an eine
ordentliche Klassenstruktur gebunden. Doch es gibt auch einige PHP Projekte, die
zur Gänze objektorientiert programmiert sind und zumindest teilweise auch auf Basis
des MVC Patterns entworfen wurden.
2.3.1
Frameworks für PHP
Es verwundert nicht, dass gerade für PHP sehr viele Projekte zu finden sind. PHP
kann leicht erlernt werden und hat dadurch auch sehr viele Hobbyprogrammierer angezogen. Aber noch weniger überrascht, dass wirklich gute Lösungen für PHP kaum
vorhanden sind. In Tabelle 2.1 sind einige Projekte von PHP-basierten Frameworks
aufgelistet. Eine Auswahl davon wird im Folgenden kurz näher betrachtet.
BinaryCloud
Dennoch gibt es einige professionelle PHP-Lösungen, welche auch im E-Business
erfolgreich eingesetzt werden. Ein Beispiel dafür ist das Open Source Framework
BinaryCloud, welches im April 2000 von der kalifornischen Firma Touring Studio4
initiert wurde. Mittlerweile beteiligen sich an dem Projekt mehrere IT-Firmen. Die
Idee von BinaryCloud entspringt einer relativ abstrakten Analyse von dynamischen
Websites. Der Inhalt einer Website wird hier in mehrere nodes zerlegt, welche in
Summe eine hierarchische application pipeline bilden.
Es gibt application nodes, widgets und entities. Application nodes sind kompakte
Teile der Website, wie zum Beispiel die Navigation, ein Container mit News oder
Formulare. Widgets stellen Interaktionselemente, wie z. B. Formularelemente dar.
Entities repräsentieren Objekte der Applikationslogik (business objects) und werden
mehr oder weniger durch eine Datenbank-Relation und einigen Funktionen implementiert. Für alle drei nodes gibt es vordefinierte Komponenten, die adaptiert und
erweitert werden können.
Das Framework verwendet für jegliche Definitionen XML als Beschreibungssprache. Als Template Engine wird Smarty5 verwendet. Es ist aber laut Dokumentation
auch die Ausgabe über eine XSL-Transformation möglich. Die Klassen sind zur
4
5
Die Homepage der Firma ist unter http://www.turingstudio.com erreichbar.
Smarty ist die bekannteste Template Engine für PHP. Siehe http://smarty.php.net.
Name
Sprache
Beschreibung
Projekt-URL
Lizenz
Charakteristik
Features
Besonderheit
Schwächen
Anwendungen
13
BinaryCloud
PHP4
Das Projekt wurde 2000 gestartet. Es wird nun von mehreren vorwiegend kalifornischen IT-Unternehmen weiterentwickelt. Es hat bei der Recherche den besten Eindruck unter
den PHP Projekten hinterlassen.
http://www.binarycloud.com
GNU Lesser General Public License
Das Framework ist von Grund auf objektorientiert. Websites werden in mehrere funktionelle Komponenten (nodes)
hierarchisch unterteilt. Nodes sind beispielsweise Unterbereiche auf einer Seite (application nodes), Interaktionselemente
(widgets) oder entities welche in Datenbanken gespeichert
werden. Das Framework ist sehr komplex und unvollständig
dokumentiert.
Metabase als Datenbank-Abstraktionsschicht (siehe http://
freshmeat.net/projects/metabase)
Lokalisation
vordefinierte Widgets
Template Engine: Smarty, XSLT
Authorisierungskonzept
Caching der Ausgabe
Exception Handling
BinaryCloud ist eines der wenigen Frameworks, deren Architektur sich auch um die Entgegennahme der HTTP-Anfragen
und die Strukturierung der Webapplikation kümmert. Es
wird somit der Bezeichnung Framework am Besten gerecht.
Als Schwäche lässt sich bloß die wirklich hohe Komplexität
anführen und die schlechte Dokumentation.
Die beteiligten Firmen verwenden das Framework selbst intensiv für ihre eigenen Produkte.
Tabelle 2.2: BinaryCloud Steckbrief.
Gänze mit PHPDoc6 dokumentiert und bereits so programmiert, dass der bevorstehende Umstieg auf PHP5 möglich ist. Tabelle 2.2 enthält eine Auflistung der
Funktionen von BinaryCloud.
Da das Framework relativ komplex und die öffentliche Dokumentation unvollständig ist, ist die Adaption des Projektes äußerst schwierig. Ohne Mailingliste und
Kontakt zu den Entwicklern ist die Verwendung des Frameworks beinahe unmöglich.
Das Framework und vor allem der Programmierstil hinterließen aber insgesamt einen
sehr guten Eindruck.
6
PHPDoc ist ein Port der Javadoc Dokumentations-API für PHP. Die Homepage des Projekts
ist unter http://www.phpdoc.de zu finden.
14
Horde
Das Horde Projekt wurde hauptsächlich durch den relativ weit verbreiteten Webbasierten E-Mail Client Horde IMP bekannt. Das Projektteam bezeichnet die Basisklassen des Projekts selbst als Horde Application Framework. Dieses Framework
stellt Basisfunktionen und Werkzeuge für alle weiteren Applikationen zur Verfügung.
Eine Applikationsarchitektur wird vom Framework nicht vorgegeben. Das Projekt
umfasst bereits zahlreiche Webapplikationen. Es gibt unter anderem einen E-Mail
Client, einen CVS-Browser und einen Terminplaner. Die Homepage des Projekts ist
unter der Adresse http://www.horde.org erreichbar.
Blueshoes
Das Blueshoes Framework bietet umfangreiche Funktionen und einige Applikationen
welche des Framework verwenden. Darunter befinden sich ein Content Management
System, eine Shop-Lösung, ein Bildarchiv und ein Web-basierter Dateimanager. Das
Projekt wird von zwei Schweizer Firmen betrieben und wird unter einer Open Source
und einer kommerziellen Lizenz angeboten.
Im Vergleich zu BinaryCloud is das Framework eine reine Klassenbibliothek und
es erscheint auch etwas veraltet. Es sind keine XML-Standards wie XSLT, WDDX
oder SOAP implementiert. Es gibt bloß einen einfachen XML-Parser, der jedoch von
keiner Komponente verwendet wird. Es wird auch keine generelle Applikationsarchitektur definiert, nach der die Interaktion abläuft. Vielmehr handelt es sich ähnlich
wie bei Horde um eine Ansammlung von zur Verfügung stehenden Komponenten.
Auffallend ist beim Blueshoes Framework die übertriebene Anlehnung an Java. So
wird jedes Objekt von der Basisklasse bs_Object abgeleitet, was sehr oft keinen Sinn
macht. Das Framework wurde mit dem PHP Debugger 7 unter die Lupe genommen
und hat eine relativ schlechte Performance. Grund dafür ist die große Anzahl von
Klassen, wobei jede Klasse als eigenes Skript mit jeder HTTP-Anfrage neu geladen
werden muss. Tabelle 2.3 zeigt einen Steckbrief des Frameworks.
php.MVC
Das php.MVC Projekt ist eine sehr interessante Adaption des Java Servlet Paradigmas für PHP und basiert auf dem MVC Model 2 Design Pattern (siehe Abschnitt
3.4.3). PHP-Skripte die für die Darstellung verantwortlich sind (vgl. JSP-Seiten)
und alle statischen Daten wie etwa Grafiken, werden im Hauptordner einer Webapplikation platziert. Alle Klassen und Bibliotheken werden in einem Unterorder namens
„WEB-INF/“ bereitgestellt. Und schließlich gibt es auch eine XML-Datei in diesem
Unterordner, mit der die Webapplikation konfiguriert wird.
Das Framework wurde im Juni 2002 auf SourceForge.net von John Wildenauer
gestartet. Zur Zeit ist eine Anwendung für komplexe Webapplikationen noch eher
unrealistisch. Doch die Projektaktivität nimmt laut Statistik, welche auf SourceForge.net zur Verfügung steht, stetig zu. Da das Framework von Grund auf durchdacht ist, lässt sich seine künfigte Bedeutung vermuten. Dem Projekt fehlen momentan hauptsächlich noch Möglichkeiten zur komplexen Darstellung und Verschachtelung von Ansichten. Ohne diese ist beispielsweise die Realisierung eines Content
7
Dieser Debugger wird als Extension in den PHP-Interpreter kompiliert und kann anschließend
fürs Debugging und Profiling von PHP-Skripts verwendet werden. Siehe http://dd.cron.ru/dbg.
Framework
Sprache
Beschreibung
Projekt-URL
Lizenz
Charakteristik
Features
Besonderheit
Schwächen
Anwendungen
BlueShoes
PHP4
Dieses Framework ist eine Co-Produktion der beiden Schweizer Firmen Optimaize GmbH und Infeer GmbH. Es besteht
aus einer umfangreichen Klassenbibliothek und gibt der Webapplikation keine generelle Architektur vor.
http://www.blueshoes.org
Open Source, Commercial
Die Klassen wurden sehr in Anlehnung an Java implementiert und bieten eine umfangreiche Bibliothek an Funktionen.
Eine PHPDoc Dokumentation ist, wenn auch nicht ganz vollständig, vorhanden.
eigene Datenbank-Abstraktionsschicht
Dateisystem-Funktionen
Microsoft Excel-Konverter
Chart-Grafiken und Text-Renderer
Formular Funktionen mit komplexen Formular-Objekten
Netzwerkfunktionen
E-Mail Funktionen (inkl. MIME Unterstützung)
Exception Handling
Im Großen und Ganzen sticht keine besondere Funktion hervor, die das Framework als einzigartig kennzeichnen könnte.
Bemerkenswert ist allerdings wohl der von Java übernommene Stil, indem alle PHP-Klassen implementiert wurden.
Teilweise übertriebene Adaption von Java. So werden zum
Beispiel alle (auch die einfachen) Objekttypen in Klassen gekapselt, die von der Basisklasse Bs_Object (vgl.
java.lang.Object) abgeleitet werden, wodurch ein relativ
großer, unnötiger Overhead entsteht. Außerdem besteht das
Framework auch nur aus einigen Paketen und Klassen, ohne
jedoch eine grundlegende Architektur zu definieren. Eine
weitere Schwäche ist die unsaubere und unvollständige PHPDoc Dokumentation.
Blueshoes bietet auf seiner Webseite selbst Anwendungen auf
Basis des Frameworks zum Kauf an. So gibt es laut Webseite
u.a. ein Content Management System, einen Web-basierten
Datenbank-Editor, ein Shop, einen Dateimanager und ein
Bildarchiv.
Tabelle 2.3: BlueShoes Framework Steckbrief.
15
Framework
Sprache
Beschreibung
Projekt-URL
Lizenz
Charakteristik
Features
Besonderheit
Schwächen
Anwendungen
16
php.MVC
PHP4
Das Projekt ist dem Apache Struts Framework für Java relativ ähnlich. Es basiert auf dem MVC Model 2 Design Pattern.
http://phpmvc.sourceforge.net
GNU General Public License
Das Framework ist sehr stark an das Java Servlet Paradigma angelehnt. Für komplexe Webapplikationen erscheint
das Projekt momentan noch nicht genug ausgereift. Es existieren auch noch keine brauchbaren Applikationen die auf
dem Framework aufsetzen. Aufgrund des durchdachten Konzepts, lässt sich seine zukünfigte Bedeutung neben anderen
Projekten vermuten.
Trennung von Funktionalität und Darstellung
Formbeans
Datenobjekte und Datenbank-Unterstützung
Konfiguration über eine XML-Datei
Werkzeuge für Datumsfunktionen, Dateisystem, etc.
Das Framework adaptiert das Java Servlet Paradigma. Die
vollständige MVC Implementierung ermöglicht eine effektive Trennung von Daten, Funktionalität und Ansichten.
Alle HTTP-Anfragen werden über einen sogenannten FrontController an die zuständige Aktion weitergeleitet.
Das Projekt ist zum jetzigen Zeitpunkt noch zu wenig ausgereift um für komplexe Anwendungen herhalten zu können.
Es gibt auf der Projekt-Homepage drei kleine beispielhafte
Applikationen. Diese dienen bloß zur Demonstration des
Framework.
Tabelle 2.4: php.MVC Framework Steckbrief.
Management Systems unmöglich. Weitere Informationen sind im Steckbrief in Tabelle 2.4 zu finden.
2.3.2
Frameworks für Java
Für Java sind ebenfalls Frameworks mit jeweils sehr unterschiedlicher Ausrichtung
und Funktionsumfang verfügbar. In Tabelle 2.5 sind einige Java Frameworks für
Webapplikationen aufgelistet.
Das Projekt Tapestry 8 (ein Unterprojekt von Apache’s Jakarta-Entwicklung9 ) ermöglicht die Programmierung von Webapplikationen mit Hilfe von wiederverwendbaren Objekten, Methoden und Eigenschaften, anstatt einzelne HTML-Seiten, Servlets
und JSP-Seiten manuell verknüpfen zu müssen. Auch das Struts Projekt10 der Apa8
Siehe http://jakarta.apache.org/proposals/tapestry.
Siehe http://jakarte.apache.org.
10
Siehe http://jakarta.apache.org/struts.
9
Projekt
ActionServlet
Apache Cocoon
Apache Struts
Apache Turbine
Barracuda
Expresso
IBM Sash
JOT
JPublish
JWIG
KONA
Maverick
OpenSymphony
Sun JATO
Wafer Project
17
Internetadresse
http://www.actionframework.org
http://xml.apache.org/cocoon
http://jakarta.apache.org/struts
http://jakarta.apache.org/turbine
http://barracuda.enhydra.org
http://www.jcorporate.com/html/products/expresso.html
http://sash.alphaworks.ibm.com
http://www.jotobjects.com
http://www.jpublish.org
http://www.brics.dk/JWIG
http://www.aki.com/kona
http://mav.sourceforge.net
http://www.opensymphony.com/webwork
http://developer.iplanet.com/tech/appserver/framework
http://www.waferproject.org
Tabelle 2.5: Java Frameworks für Webapplikationen.
che Foundation verfolgt ein ähnliches Ziel. Beiden Projekten liegt der MVC Design
Pattern zugrunde. Die beiden Projekte sind steckbriefartig in den Tabellen 2.6 und
2.7 beschrieben.
2.3.3
Ergebnis der Analyse
Es läßt sich feststellen, dass es für PHP kein professionelles, objektorientiertes lowlevel Framework gibt. Die vorhandenen Projekte beschränken sich großteils auf Klassenbibliotheken. Das BinaryCloud und das php.MVC Projekt sind die einzigen beiden
Frameworks welche auch eine grundlegende Architektur definieren. Die wenigsten
PHP-basierten Frameworks sind objektorientiert und php.MVC ist vermutlich das
einzige Projekt, welches auf dem MVC-Pattern basiert. Das Projekt ist aber zur
Zeit in der Praxis noch keineswegs einsatzfähig. Diese Feststellung dient zusätzlich
als Motivation zur Entwicklung eines objektorientierten low-level Frameworks für
PHP.
Framework
Sprache
Beschreibung
Projekt-URL
Lizenz
Charakteristik
Features
Besonderheit
Schwächen
Anwendung
Anmerkungen
Struts
Java
Framework auf Basis von MVC Model 2
http://jakarta.apache.org/struts
Apache Software License 1.1
Struts besteht aus drei Hauptkomponenten: einem Servlet
Controller, JSP Seiten (views) und der business logic (model). Alle HTTP-Anfragen werden über den Servlet Controller abgesetzt, welcher anschließend entsprechende Aktionen
in der business logic ausführt und zu JSP-Seiten weiterleitet.
Implementierung durch abgeleitete JavaBeans, ActionKlassen und JSP-Seiten
Errorhandling (inkl. Anzeigen)
JSP-Form Beans und Custom Tags
Internationalisierung (Java built-in)
zahlreiche Extensions sind verfügbar (v.a. Taglibs)
Struts verwendet den MVC-Pattern von Grund auf und ist
dadurch sehr universell einsetzbar. Außerdem wird Struts,
wie man aus einigen Foren und Artikeln im Internet erfährt,
relativ gut von Entwicklern aufgenommen, was für die Zukunft breite Akzeptanz, Integration und Weiterentwicklung
bedeutet.
Es gibt keine höhere Entwicklungsunterstützung (Wizards,
etc.). Alle Objekte, Klassen und Views müssen durch Ableitung von abstrakten Klassen erst implementiert werden.
Da Struts als leightweight Framework bloß grundlegende
Funktionalitäten erfüllt bzw. nur die Architektur der Webapplikation vorgibt und für bestimmte Anwendungen erst
erweitert werden muß, können mit Struts so gut wie alle nur
denkbaren Applikationen geschaffen werden.
Sinnvoll ist der Einsatz vor allem dann, wenn bereits ein
J2EE-Server im Einsatz ist.
Das Projekt Expresso von Jcorporate (http://www.jcorporate.
com/html/products/expresso.html) erweitert Struts um wichtige Features für Sicherheit, Logging, Backgroundjobs,
Datenbank-Verbindungspools, E-Mail, Caching, Internationalisierung, Workflow Management, etc.
Tabelle 2.6: Struts Framework Steckbrief
18
Framework
Sprache
Beschreibung
Projekt-URL
Lizenz
Charakteristik
Features
Besonderheit
Schwächen
Anwendungen
Tapestry
Java
Framework auf Basis des MVC Patterns, ähnlich wie Struts.
Tapestry wurde im Jänner 2003 ins Apache Jakarta Projekt
aufgenommen und genießt zur Zeit noch die Proposal-Phase.
http://jakarta.apache.org/proposals/tapestry
Apache Software License 1.1
Bei Tapestry werden wie bei Struts alle HTTP-Anfragen
über ein zentrales ApplicationServlet ausgeführt, welches
die nötigen Action-Klassen ausführt. Zur Anzeige werden
HTML-Dateien, welche Tapestry Template-Scripts enthalten verarbeitet und an den Browser zurückgesendet.
Die Implementierung erfolgt in Form von wiederverwendbaren Objekten, Methoden und Parametern (Ableitung von
BaseComponents, BasePages, etc.)
Alle Komponenten werden mittels XML-Datein, HTMLTemplates und abgeleiteten Klassen erstellt.
Die URL-Generierung und der page-flow erfolgen im Hintergrund transparent.
Internationalisierung
Java Script/DHTML Support: es gibt eine umfangreiche
Auswahl an dynamischen HTML-Komponenten (FormulareElemente wie z.B. eine Mehrfachauswahl mit zwei Listboxen). Die nötigen JavaScripts und Formular-tags werden
automatisch zusammengestellt.
Proprietäre Skriptsprache in den HTML-Templates anstelle
von Custom Tags
Durch die umfangreichen Template-Funktionen und der
DHTML-Unterstützung eignet sich Tapestry hervorragend
für komplexe GUI-Frontends von Applikationen. Außerdem
macht sich auch die Verwendung wiederverwendbarer Komponenten langfristig bezahlt und man behält bei größeren
Projekten leichter die Übersicht.
Der Einsatz von Tapestry lohnt sich v.a. dann, wenn die restliche Applikationslogik bereits auf einem J2EE-Server läuft.
Tabelle 2.7: Tapestry Framework Steckbrief
19
Kapitel 3
Entwicklung von
Webapplikationen
Dieses Kapitel behandelt Entwicklungskonzepte und Entwurfsmethoden des Web Engineerings. Es wird vorerst auf die Wichtigkeit der Planung und Modellierung von
Webapplikationen hingewiesen und anschließend konkret auf Konzepte eingegangen.
Handelt es sich um komplexe Webapplikationen (im Gegensatz zu einfacheren Websites), werden Lösungsmuster des Software Engineerings immer wichtiger. Neuere
Konzepte stützen sich deshalb auf das aus Smalltalk bekannte MVC-Paradigma.
Das im Rahmen der Arbeit entwickelte DaVinci Framework basiert im Übrigen auch
auf diesem Konzept.
Am Ende des Kapitels wird versucht, die Komplexität der Modellierung und
Implementierung durch Eliminierung des Hyper-Paradigmas (der Verknüpfung von
Ressourcen jeglicher Form in einem weltweiten Netz aus Hyperlinks) zu vereinfachen.
So wird für die Darstellung das aus der Computergrafik bekannte SzenengraphenModell adaptiert. Die Modellierung der Hypertext-Ebene (der netzartigen Navigationsstruktur) wird durch die Verlagerung der Navigation in die Applikationslogik mit
Methoden des traditionellen Software Engineerings ermöglicht.
Zuletzt werden einige Ideen für ein UML-basiertes Modellierungskonzpet für
DaVinci-basierte Webapplikationen vorgestellt.
3.1
Web Engineering
Web-basierte Applikationen erfuhren in den letzten Jahren einen starken Zuwachs,
sowohl im Gebrauch als auch in ihrer Akzeptanz. Doch die Entwicklung solcher
Systeme erfolgte bislang eher planlos, was sich meist später in der Qualität der
Produkte bemerkbar machte [Ude02]. Ein ingenieursmäßiger Ansatz, wie er an sich
in jeder Branche gefordert wird, fehlte bislang in diesem Bereich. Durch die einerseits
noch relativ junge Technologie und dem raschen Marktwachstum, wurde in kurzer
Zeit viel entwickelt, produziert und verkauft, ohne dieses komplexe System überhaupt
richtig verstanden zu haben [PSRO02].
Es gibt im Übrigen einige Begriffe in der Branche, die nicht ganz klar definiert
sind. Dazu gehören etwa Webdesign, Web-Entwicklung oder das Web Engineering.
Ohne nun eine Begriffsdefinition im Detail anzustellen, sei angemerkt, dass sich letztere Bezeichnung auf das Ingenieurwesen, welches hinter der Entwicklung von Web20
KAPITEL 3. ENTWICKLUNG VON WEBAPPLIKATIONEN
21
basierten Anwendungen steckt, bezieht. Wie auch im Software Engineering sind
Techniken zur Entwicklung von Webapplikationen und einheitliche Qualitätsstandards gefordert. Es bedarf einerseits Modellen und Techniken, die zum Verständnis
der Komplexität einer vorhandenen Problemstellung dienen und andererseits Techniken, die den Prozess der Entwicklung unterstützen [Ude02]. Einige wichtige Aspekte
des Web Engineerings, welche sehr oft unterschätzt wurden sind:
Der Engineering Prozess: Um die Entwicklung planen und organisieren zu können, bedarf es eines Prozesses, der alle Phasen, Schritte und Aktivitäten der
Entwicklung festlegt [GM01, S. 22]. Dieser Aspekt wurde noch am ehesten beachtet, da er vom traditionellen Projektmanagement ausgeht. Trotz allem gibt
es zumeist in der zeitlichen Planung noch Schwierigkeiten. Diese Tatsache lässt
sich vermutlich auch auf unzureichende technische Planung und Modellierung
der Applikation zurückführen. Projektmanagement alleine ist kein Patentrezept.
Die Modellierung: Dieser Aspekt ist Teil des Engineering Prozesses. Um die Komplexität einer Webapplikation verstehen zu können, ist der Entwurf und die
Modellierung des Systems vor der eigentlichen Implementierung von entscheidender Bedeutung. Die Wichtigkeit dieses Aspekts wurde im Entwicklungsprozess bislang am meisten unterschätzt. Sehr oft wurde bereits nach der Anforderungsanalyse direkt bei der Implementierungsphase fortgesetzt. Ad-hoc
Methoden werden sich aber auf Dauer nicht halten können [REL01].
Die Qualitätssicherung: Die Qualitätssicherung von Prozessen und Produkten in
Organisationen ist heute alltäglich geworden und gilt daher auch fürs Web Engineering [PSRO02, Kap. 4] bzw. [RO02]. Die Qualitätssicherung begleitet
den Gesamtprozess und vergleicht zuvor definierte Qualitätskriterien mit dem
aktuellen Status des Produkts bzw. des gesamten Prozesses. Es wird einerseits
der Prozess und andererseits das Produkt selbst kontrolliert. Webapplikationen können außerdem auf verschiedenste Arten evaluliert werden, z. B. mittels
Usability Tests oder auch mit heuristischen Methoden [Nie99].
Das Prozess- und Qualitätsmanagement wird in diesem Kontext nicht weiter behandelt. Die Modellierung von Webapplikationen, als Basis der Spezifikation eines
generischen Frameworks, sei im Folgenden das Thema. Die Architektur von Webapplikationen spielt bei der Modellierung eine entscheidende Rolle. Deshalb werden
im Anschluss das Wesen einer Webapplikation und die zugrundeliegende Architektur
erörtert.
3.2
Architektur von Webapplikationen
Das Verständnis der einer Webapplikation zugrundeliegenden Architektur, ist Vorraussetzung für die Entwicklung derartiger Anwendungen. Webapplikationen sind
durch ihren Ursprung in der Hypertext- bzw. Hypermedia-Domäne ein relativ komplexes System. Hyperlinks bewegen den Benutzer durch ein interaktives Netz mit
exponentieller Größe. Das Zusammenwachsen von traditionellen Websites und Applikationen, welche aufwändige Applikationslogik (business logic) erfordern, machen
22
mobile
Clients
WWW
HTTP
Webserver
PC Client
Abbildung 3.1: Einfache Client/Server-Architektur einer Webapplikation.
den Entwurf und die Modellierung äußerst schwierig. Die Architektur einer Webapplikation soll im Folgenden betrachtet werden.
3.2.1
Client/Server-Kommunikation
Die Grundstruktur einer Webapplikation ist jene einer klassischen Client-Server Anwendung (Abb. 3.1) mit ein paar Ausnahmen [Con99]. Ein großer Unterschied liegt
beispielsweise in der Art der Einrichtung und Implementierung. Bei klassischen
Client/Server-Anwendungen müssen beide Seiten aufgesetzt werden. Das Einrichten einer Webapplikation erfordert hingegen bloß das Aufsetzen der Server-seitigen
Komponenten. Da der Browser eine universelle Schnittstelle ist, ist keine weitere
Konfiguration auf der Client-Seite erforderlich [Con99]. Allerdings ist es notwendig
auf Browser-spezifische Eigenschaften Rücksicht zu nehmen.
Ein weiterer Unterschied liegt in der Natur dieser Browser/Server-Verbindung.
Das zugrunde liegende Kommunikationsprotokoll ist HTTP – ein zustandloses Protokoll, welches ursprünglich für Robustheit und Fehlertoleranz entwickelt wurde und
nicht für maximalen Datendurchsatz und dauerhafte Verbindungen [Con99]. Die
Kommunikation erfolgt daher typischerweise durch Navigieren zwischen Hyperlinks
und nicht über eine permanente Client/Server-Verbindung.
3.2.2
Zustandslose Verbindung
Jede Benutzerinteraktion muss über einen eigenen HTTP-Request1 erfolgen. Es
gibt keine für Client und Server gemeinsam erreichbaren Ressourcen oder Objekte
wie beispielsweise bei Java RMI2 oder DCOM3 . Die Möglichkeit der Verwendung
von Client-seitigen Java Applets oder ActiveX Komponenten, welche eine parellele
Socketverbindung zum Server aufbauen können, sei hier erstmal dahingestellt.
Roy Thomas Fielding hat in seiner Dissertation über netzwerkbasierte Softwarearchitekturen [Fie00] die Funktionsweise der Interaktion über HTTP und ähnliche
1
Die Anfrage des Browsers beim Webserver um eine HTTP-Ressource; Es wird in dieser Arbeit
fallweise auch der englische Begriff verwendet.
2
Remote Method Invocation ermöglicht den Zugriff auf entfernte Objekte und den Aufruf von
Methoden dieser. Siehe http://java.sun.com/products/jdk/rmi.
3
Das Distributed Component Object Model wurde von Microsoft entwicklet und funktioniert
ähnlich wie Java RMI. Siehe http://www.microsoft.com/com/tech/DCOM.asp.
23
stateless Protokolle Representational State Transfer, kurz REST genannt. Stateless
bedeutet, dass die einzelnen Requests aus Sicht des Servers nichts gemein haben.
Dem Server ist es prinzipiell egal, wer die Seite angefordert hat. Er führt bloß die
Anfrage aus und gibt die gewünschte Seite zurück, ohne zu wissen, dass ein bestimmter Request wieder vom selben Benutzer stammte. Ohne den Benutzer eindeutig
wiedererkennen zu können, wären Webapplikationen jedoch nicht realisierbar.
Die Anwendung aus Sicht des Benutzers beginnt daher immer mit der Initialisierung einer sogenannten Session (Sitzung). Dabei wird für den Benutzer eine eindeutige Kennung generiert (Session-ID), mit der alle nachfolgenden Requests identifiziert werden können. Diese Kennung wird dann bei jeder neuen Anfrage vom
Browser mitgesendet [Kra00, Kap. 4].
Die Tatsache, dass für jede Interaktion ein neuer Request erforderlich ist, bringt
für den Benutzer der Web-Anwendung Nachteile mit sich. So kann es bei einer
schlechten Netzwerkverbindung mitunter mehrere Sekunden dauern, bis der Request
beim Server angekommen ist und die Antwort als neue HTML-Seite beim Benutzer
erscheint. Die Verwendung von Programmcode auf Seite des Clients (vgl. Java
Script, Java Applets oder ActiveX-Komponenten) ermöglicht es, Applikationslogik
auf den Client zu verlagern. Dadurch können Requests eingespart werden [Con03,
Kap. 3]. Durch Verlagerung von Applikationslogik auf eine andere Schicht, wird
allerdings die Modellierung der Applikation wieder um eine Dimension komplexer.
Der Entwickler ist im Übrigen gefordert, die Benutzerinteraktion so sinnvoll wie
möglich zu gestalten, um trotzdem ein komfortables Arbeiten zu ermöglichen. Generell ist die Gestaltung von Benutzeroberflächen für Webapplikationen um einiges
schwieriger, zumal man auch bei der Auswahl der GUI-Elemente (hier in Form von
HTML-Elementen) sehr eingeschränkt ist (funktionell sowie visuell). Es muss auch
stets ein Kompromiss zwischen Verwendung von Client-seitigen Erweiterungen und
Kompatibilität zu den verschiedenen existierenden Browsern gemacht werden.
3.2.3
Mehrschichtige Architektur
Im einfachsten Fall teilt sich eine Webapplikation also in die beiden Schichten Webserver und Client. Viele Webapplikationen dienen allerdings bloß als Schnittstelle zu
einem eigenen Applikationsserver. Man spricht in diesem Fall auch vom Web-tier
der eigentlichen Applikation (vgl. [SSJ02, Kap. 4]). Vor allem für Java gibt es von
führenden Unternehmen Applikationsserver-Software mit integriertem Web-tier (vgl.
IBM WebSphere, BEA WebLogic, Sun ONE Servers4 ). Es existieren jedoch auch einige Open Source Projekte, wie etwa der Applikationsserver JBoss5 in Kombination
mit Tomcat6 oder Jetty7 als Webserver.
In den meisten Fällen wird auch die Datenbankschicht auf einen anderen Rechner
ausgelagert. Abbildung 3.2 zeigt eine Multi-tier Architektur mit Client, Webserver,
Applikationsserver, Dateisystem, Datenbank und externen Ressourcen als logische
Schichten. Diese Schichten können physikalisch auch auf dem gleichen Rechner un4
siehe http://www.ibm.com/websphere, http://www.bea.com/products/weblogic/platform/index.
shtml, bzw. http://wwws.sun.com/software.
5
Siehe http://www.jboss.org.
6
Siehe http://jakarta.apache.org/tomcat.
7
Siehe http://jetty.mortbay.com. Mit JBoss Version 3.0 wird Jetty als Standardsoftware im Webtier mitgeliefert (siehe auch http://www.coredevelopers.net/technology/jetty/jetty-jboss-faq.jsp.
24
Abbildung 3.2: Multi-tier Architektur. Aus [Boo01].
tergebracht sein (etwa Webserver und Dateisystem).
Je nach Einsatzgebiet und Anforderungen werden auch Datenbankcluster und
mehrere Webserver-Instanzen verwendet [SW00, Li03]. Eine solche skalierbare Architektur ist allerdings nur bei wirklich großen Anwendungen vonnöten (z. B. bei
Portalen internationaler Konzerne). Zwischen den Schichten sind in der Regel Firewalls platziert.
3.2.4
Website und Webapplikation
Die Unterscheidung zwischen einer Website und einer Webapplikation ist nicht ganz
einfach. Die zugrundeliegende Architektur ist im Prinzip die gleiche [LCC00]. Auf
einer abstrakten Ebene kann die gesamte Kommunikation in einer Webapplikation
als das Anfragen und Empfangen von einzelnen Webseiten angesehen werden. Es
stellt sich daher die Frage, ab wann von einer Webapplikation gesprochen werden
kann, bzw. was eine Webapplikation eigentlich ist.
Eine einheitliche Begriffsdefinition für Webapplikation ist in der Literatur nicht zu
finden. Die Definitionen variieren im Detail. Eine mögliche Definition wurde einem
Buch über Java Servlet Programmierung entnommen [HC98]:
„While a web page merely displays static content and lets the user navigate through that content, a web application provides a more interactive
experience. A web application can be as simple as a keyword search on
a document archieve or as complex as an electronic storefront.“
Diese Definition unterscheidet statische Websites von Webapplikationen im Grad
der Interaktion. Webapplikationen erlauben neben dem Navigieren zwischen Hyperlinks eine zusätzliche Interaktion, durch die der Inhalt dynamisch zusammengestellt
und verändert werden kann. Eine einfache Suchabfrage in einem Dokumentenbestand wäre also bereits eine Webapplikation. Die folgende Definition aus [FSK+ 02]
geht einen Schritt weiter:
„A Web application is an application, not just a set of Web pages. In
particular, this implies that it enforces the notion of a session, which
differentiates it from the ordinary request-response Web paradigm. In
this context, even a Web service that dynamically generates pages may
not be considered a Web application.“
25
Eine Webapplikation erfordert laut dieser Definition die Existenz einer Session
(Sitzung), die den Benutzer über mehrere Requests hinweg identifiziert. Andernfalls
wird hier maximal von einem „Web-based service“ gesprochen. Eine Suchmaschine ist
in diesem Zusammenhang also keine Webapplikation. Der entscheidende Faktor ist
das Vorhandensein eines bestimmten business state, also eines Status in dem sich die
Applikation zu einem bestimmten Zeitpunkt befindet [Con99, LCC00]. Und dieser
Status kann durch Benutzerinteraktion geändert werden [Con99]: „[...] where user
input (navigation and data input) affects the state of the business.“
3.2.5
Skript-basierte Webapplikationen
Es gibt einen schwerwiegenden Unterschied in der Laufzeit zwischen kompilierten
und Skript-basierten Programmiersprachen. Bei einer kompilierten Webapplikation
(vgl. ISAPI, NSAPI, Java Servlets bzw. Abb. 1.1, Seite 2) beginnt die Laufzeit mit
Inbetriebnahme des Servers. Dieser wartet nun auf Anfragen von unterschiedlichen
Clients. Die Applikation bleibt solange der Server läuft im Hauptspeicher. Skriptbasierte Programmiersprachen haben diesbezüglich einen entscheidenden Nachteil.
Mit PHP können keine eigenständigen Applikationen mit einer Laufzeit ausserhalb von HTTP-Requests realisiert werden. Diese Tatsache erschwert die Implementierung, da bestimmte persistente Ressourcen, wie beispielsweise Objekte der
Applikationslogik und Datenbankverbindungen, bei jedem Request neu initialisiert
werden müssen.
Script Running Magic
Um für PHP-basierte Webapplikationen persistente Objekte zu ermöglichen, wurde
im Herbst 2000 das Projekt Script Running Magic8 (kurz SRM) ins Leben gerufen.
Die SRM läuft als eigenständiger Server, welcher in C implementiert wurde und
erlaubt persistente Objekte, sogenannte Bananas in den SRM-Container zu laden.
Diese Bananas sind nichts anderes als Instanzen von PHP-Klassen und können nach
Installation der zugehörigen PHP Extension mit SRM-spezifischen PHP-Befehlen
angesprochen werden. Die Wahl des Namens für solche persistenten Objekte soll die
Verwandtschaft zu Java’s Beans verdeutlichen. Mit solchen Bananas könnten nun
auf eine etwas professionellere Art persistente Sessions, Datenbankverbindungen und
applikationsübergreifende Objekte (z. B. ein Chat) realisiert werden.
Die SRM wurde im Rahmen der Diplomarbeit für ihre Tauglichkeit getestet. Da
die Entwicklung jedoch sehr langsam fortschreitet, noch viele Bugs vorhanden sind
und das Framework durch die Integration der SRM stark von diesem Projekt abhängig wäre, wurde von der Integration vorerst abgesehen. Ein weiterer Nachteil wäre,
dass das Framework nicht mehr zu den üblichen Webserver-Setups von Providern
kompatibel wäre.
Session als Zwischenspeicher
Um bestimmte Objekte und Ressourcen über mehrere Requests hinweg persistent
zu halten, werden diese bei DaVinci innerhalb der Session gespeichert. Innerhalb
einer Session können allerdings bloß Schlüssel/Wert-Paare gespeichert werden und
8
Die Projekt-Homepage ist unter http://www.vl-srm.net erreichbar.
26
alle Parameter eines Objektes müssen als String serialisiert werden. Es ergeben sich
dadurch einige Probleme. Man muss zwischen Objekten, welche sich tatsächlich im
Hauptspeicher des Rechner befinden und über Speicherreferenzen andere Objekte
referenzieren können und als Strings serialisierten Objekten unterschieden. So gehen
bei DaVinci nach dem Request zwangsweise wieder alle Speicherreferenzen zwischen
den Objekten verloren. Somit sind auch persistente Speicherressourcen sowie Datenbankverbindungen nicht möglich.
Dies ist der Grund warum sich PHP und Skriptsprachen überhaupt für eigenständige Applikationsserver schlecht eignen (siehe Abschnitt 1.4.2). Bei DaVinci wird die
Objekthierarchie im Speicher bei jedem Request neu aufgebaut. Die Applikationslogik im Web-tier ist somit realisierbar. Für komplexe Anwendungen sollte allerdings
eine der SRM ähnliche Lösung angedacht werden oder ein Applikationsserver (z. B.
Java) integriert werden.
3.3
Modellierungskonzepte
Die Modellierung von Webapplikationen ist vielschichtig und komplex. Konzepte des
Hypermedia Designs und des Software Engineerings werden versucht zu kombinieren
um die Komplexität einer Webapplikation erfassen zu können. Die folgende abstrakte, jedoch relativ umfassende Veranschaulichung des Webengineering-Prozesses
soll einen ersten Überblick geben. Im Anschluss werden einige Konzepte genauer
besprochen. Konkret wird auf das OOHDM-Konzept (Object-oriented Hypermedia
Design Method) [RSG99] und auf die Methoden von Conallen [Con99, Con03] eingegangen. OOHDM führt als eines der ersten Konzepte objektorientierte Methoden
ein, die Methoden von Conallen sind ausschließlich auf UML basiert und bieten ein
Konzept, mit dem sich auch Webapplikationen mit komplexer Applikationslogik modellieren lassen.
3.3.1
Dimensionen und Ebenen im Web Engineering
Der Entwicklungsprozess von Webapplikationen kann aus einer abstrakten Sicht im
Allgemeinen in drei orthogonale Dimensionen geteilt werden (vgl. dazu Abb. 3.3):
Levels (Ebenen), Aspects (dynamische Aspekte) und Phases (Entwicklungsphasen).
Die Einteilung wurde aus [RS00] übernommen. Die Entwicklungsphasen geben die
zeitliche Dimension vor, also den gesamten Entwicklungsprozess im Zeitverlauf. In
jeder Entwicklungsphase müssen verschiedene Aspekte der orthogonalen Ebenen beachtet werden. Diese sehr abstrakte, aber realtiv aufschlussreiche Visualisierung
zeigt, wie komplex der Entwicklungsprozess in der Tat ist.
Ebenen: Content, Hypertext und Präsentation
Die erste Dimension der Modellierung besteht aus den Ebenen Content, Hypertext
und Präsentation. Diese Dreiteilung erinnert an das MVC-Konzept aus der objektorientierten Programmierung (siehe Abschnitt 3.4.3). Die Modellierung in dieser Dimension erfolgt zuerst auf einer konzeptuellen, inhaltlichen Ebene (Content), welche
alle Entitäten der Applikation erfasst (z. B. Bücher und Autoren in einer Literaturdatenbank). Im nächsten Schritt (Hypertext Level) werden die logische Komposition
der einzelnen Seiten und die Navigation modelliert. Der letzte Schritt definiert die
27
Präsentation des Hypertext Levels, also alle Ansichten. Diese Ansichten sind jene
Seiten, die der Benutzer am Ende im Browser sieht. Sie bestehen aus verschiedenen
Inhalten und Interaktionselementen (z. B.. Formular-Elemente und Links).
Es ist notwendig, dass alle drei Ebenen möglichst voneinander getrennt modelliert werden [RS00]. Es soll z. B. möglich sein, für ein und denselben Content unterschiedliche Hypertext-Modelle entwickeln zu können. Genauso soll es möglich sein,
verschiedene Ansichten demselben Hypertext-Modell zuweisen zu können. Dadurch
werden beispielsweise eine persönlich angepasste Navigation bzw. personalisierte Ansichten ermöglicht. Eine Kompatibilität zu verschiedenen Clients (z. B. PDAs und
andere mobile Geräte) kann nur durch eine Entkoppelung der Hypertext-Ebene von
der Präsentationsebene erreicht werden.
Es bleibt anzumerken, dass neben einem top-down Design, welches von der Content Ebene ausgehen würde, natürlich auch ein buttom-up Design möglich ist. Je
nach Anforderung bzw. Ausgangssituation, empfielt sich die eine oder andere Variante. Soll beispielsweise eine existierende Webseite in einer Datenbank erfasst werden, muss von den Ebenen Präsentation und Hypertext ausgehend, die entsprechende
Content-Ebene modelliert werden.
Dynamische Aspekte: Struktur und Verhalten
Diese Dimension besteht aus den Aspekten Struktur und Verhalten (Behaviour) und
ist orthogonal zu den drei Ebenden der ersten Dimension. Was den Content betrifft, muss für den strukturellen Aspekt ein statisches Modell, im Sinne von EntityRelationen und Klassendiagrammen (UML9 ), entwickelt werden. Mit Einbeziehung
des Behaviour-Aspekts erhält die Anwendung erst ihren sogenannten business state.
Das statische Modell [RJB99, S. 41] als strukturelle Basis der Applikationslogik wird
durch den Behaviour-Aspekt um eine zeitliche Dimension, in der sich der Status
der Applikation ändern kann, erweitert. Hier dienen ebenfalls UML-Diagramme
zum Entwurf (etwa Statechart, sequence und collaboration Diagramme [RJB99, Kap.
6–8]). Die Vorschläge von Lowe et al. [LHSG02a] bzw. Knight und Dai [KD02] basieren auf dem MVC-Prinzip und bieten Konzeptentwürfe, welche die Struktur und
das Verhalten aller Ebenen der ersten Dimension am Besten miteinbeziehen. Die
Content-Ebene wurde von den ersten Hypermedia-Konzepten so gut wie gar nicht
berücksichtigt. Bei aufwändigen Webapplikationen mit inhärenter business logic ist
diese Ebene jedoch die Wichtigste überhaupt. Sie bildet quasi das Herz der Anwendung und ermöglicht die Veränderung des Zustands der Applikation (application
oder business state).
Die Hypertext-Ebene wird ähnlich für den strukturellen und dynamischen Aspekt
modelliert. Das strukturelle Modell beschreibt die statische Zusammensetzung der
Hypertext-Seiten und die dazwischenliegenden Referenzen (Hyperlinks). Das Verhaltensmodell der Hypertext-Ebene berücksichtigt beispielsweise dynamisch generierte
Links. Durch Behaviour im Hypertext-Modell kann sich die Struktur und Zusammensetzung der einzelnen Seiten während dem Benutzen der Applikation verändern.
Der Aspekt kommt z. B. zum Tragen, wenn sich der Benutzer durch ein Suchergebnis
bewegt. Die Navigation wurde in diesem Fall dynamisch durch die vorausgehende
Suchabfrage generiert.
9
Die Unified Modeling Language ist eine objektorientierte Modellierungssprache für Software
Systeme [RJB99].
28
Das strukturelle Modell der Präsentation beschreibt die Ansicht der HypertextEbene (also Inhalte und Navigationselemente) im Browser. Die Ansicht kann im
Sinne von Webapplikationen genauso auch als Benutzeroberfläche betrachtet werden,
welche normalerweise in Form einer HTML-Seite vom Browser interpretiert wird. Der
Behaviour-Aspekt bezieht sich hier auf dynamische Elemente der Benutzeroberfläche,
welche beispielsweise mittels Client-seitigen Skripts möglich sind. Die Veränderung
von HTML-Elementen (Dynamic HTML), z. B. von Menüleisten oder Formularen
wird im Verhaltensmodell des Content modelliert. Da durch Verwendung von Clientseitigem Programmcode ein entprechender Teil der Applikationslogik auf den Client
ausgelagert werden kann, sollte dies im Modell berücksichtigt werden können.
Um die Struktur und das Verhalten von Content, Hypertext und Präsentation
modellieren zu können bedarf es eines einheitlichen Formalismus. Viele Konzepte
bedienen sich eines objektorientierten Ansatzes und verwenden als Grundlage UML.
Durch die in UML bereits vorgesehenen Erweiterungskonzepte (stereotypes, tagged
values und constraints [RJB99, Kap. 11]) können UML-Modelle auch für Webapplikationen verwendet werden [PSRO02].
Für die Navigation im Hypertext-Level ist die Verwendung von vordefinierten
Hypermedia Design Patterns10 möglich [GC00]. Solche Design Patterns sind z. B.
verschiedene Navigationstopologien (vgl. Buch, Baum, Netz, etc.).
Entwicklungsphasen
Auf dieser Achse ist der zeitliche Ablauf des gesamten Prozesses im Web Engineering von der Anforderungsanalyse bis zur Implementierung dargestellt. Für jeden
Aspekt der anderen Ebenen muss der jeweilige Subprozess durchgeführt werden. So
sind zum Beispiel für den strukturellen Entwurf des Content als Subprozesse eine
Analysephase, mehrere Entwicklungsphasen und schließlich die Implementierung erforderlich. Der Gesamtprozess besteht im Allgemeinen nicht aus einem einzigen
Durchlauf dieses Zyklus, sondern aus mehreren Iterationen, wobei jeder Durchlauf
das Detail um eine Stufe erhöht [RS00].
Im Beispiel von [RS00] (Abb. 3.3) wurde der Gesamtprozess in einen groben,
konzeptuellen Entwurf (Analyse), eine Technologie-unabhängige Modellierung (Logical Modeling), eine Technologie-spezifische Modellierung (Physical Modelling) und
die Implementierung unterteilt. Da es keinen allgemeingültigen, standardisierten
Entwicklungsprozess im Web-Enginieering gibt, findet man auch sehr verschiedene
Lifecycle-Modelle für den gesamten Engineering-Prozess [GM01, Ude02, Con03].
3.3.2
Historischer Überblick
Die Historie von Entwicklungskonzepten und -modellen für Webseiten reicht laut
vorliegender Literatur in die 90er-Jahre zurück. Abbildung 3.4 (aus [RS00]) zeigt
die Evolution in drei Generationen. Die ersten Konzepte dienten der Modellierung
von Hypermedia Anwendungen, also hauptsächlich Websites ohne Applikationslogik. Sie versuchten die Verknüpfung der Seiten darzustellen. Der Schwerpunkt lag
im Modellieren der Navigation und der Präsentation (vgl. HDM – Hypermedia Design Method [GPS95]). Die nachfolgenden Konzepte, wie beispielsweise OOHDM
10
Software Design Patterns sind Musterlösungen für häufig vorkommende, ähnliche Problemstellungen.
29
Levels
Presentation
Hypertext
Content
Structure
Phases
Implementation
Conceptual Logical
Physical
Modeling Modeling Modeling
Behavior
Aspects
Abbildung 3.3: Dimensionen der Modellierung von Webapplikationen. Aus [RS00].
Traditional Modeling
Methods
ER
Dexter
1st Generation DataWeb
Modeling Methods
OMT
Conallen
HDM
2nd Generation DataWeb
Modeling Methods
RMM
HDM lite
3rd Generation DataWeb
Modeling Methods
Araneus
W3I3
UML
OOHDM
Baumeister et al.
Abbildung 3.4: Modellierungskonzepte im evolutionären Überblick (aus [RS00]).
Die meisten der Konzepte in dieser Abbildung werden im Text erwähnt. Weitere
sind: HDM lite (Fraternali [Fra00]), Araneus (Atzeni et al. [AMM98]) und W3I3
(Web-based Intelligent Information Infrastructure, Ceri et al. [CFP99]).
verfolgten bereits einen objektorientierten Ansatz. Neuere Modelle sind zumeist auf
UML basiert (vgl. Baumeister et al. [BKM99], Conallen [Con99, Con03], Koch und
Kraus [KK02] bzw. Lowe et al. [LHSG02a]).
Hypermedia Modellierungskonzepte
Die ersten Konzepte zur Entwicklung von Hypermedia Applikationen, wie etwa HDM
boten kaum Modelle für die Content-Ebene der Levels-Dimension (Abb. 3.3, S. 29).
Das Design beschränkt sich bei HDM bloß auf die Ebenen Hypertext und Presentation, also hauptsächlich auf die Darstellung und Modellierung der Verknüpfungen
zwischen den einzelnen Ansichten. Die Modellierung von Datenbank-gestützten Websites ist dadurch nicht möglich. HDM baut auf dem Dexter Reference Model [HS94]
auf und adaptiert das Konzept für die Modellierung von Hypermedia Anwendungen [RS00].
30
Die Modellierung der Content-Ebene als Basis aller Entitäten und Daten der
Webapplikation wurde in einer ersten, einfachen Form in einer nächsten Generation
z. B. von RMM unterstützt. RMM baut auf HDM und dem Entity-Relationship
Model [Che76] auf und ermöglicht eine getrennte Modellierung der Content- und
Hypertext-Ebene [RS00]. Die Content-Ebene kann bei RMM allerdings bloß statisch
modelliert werden. Da für die Modellierung einer Applikationslogik mit business
state allerdings der Behaviour-Aspekt entscheidend ist, reicht das Modell für richtige
Webapplikationen noch nicht aus.
Objektorientierte Konzepte
Für eine Webapplikation, wie sie von [LCC00] (siehe Abschnitt 3.2.4) definiert wird,
bieten reine Hypermedia-Entwurfskonzepte, die in erster Linie auf die Informationsarchitektur fokussiert sind, nicht genügend Detail [LHSG02a]. Mit Einzug des
objektorientierten Paradigmas im Web Engineering enstanden auch Modellierungskonzepte für die Entwicklung von richtigen Webapplikationen mit gegebener business
logic im Kern der Anwendung (vgl. OOHDM [RSG99], Conallen [Con99], Baumeister
et al. [BKM99] und W2000 [BGP01]).
Die Object-oriented Hypermedia Design Method (OOHDM) [RSG99] trennt alle
Ebenen der Levels-Dimension (Abb. 3.3, S. 29). Auf Content-Ebene wird die Modellierungsmethode OMT11 verwendet, wobei neben der Structure auch das Behaviour
berücksichtigt wird [RS00]. Im nächsten Abschnitt wird auf das OOHDM-Konzept
etwas näher eingegangen.
Einige weitere objektorientierte Ansätze bauen teilweise auf OOHDM auf, verwenden jedoch als Notation statt OMT die neuere UML-Notation und erweitern
zumeist UML mit den vorgesehenen stereotypes. Einige Konzepte führten allerdings auch völlig neue Diagramm-Typen ein (vgl. [LHSG02a]), was durch die Vielseitigkeit von UML und dem bereits vorgesehenen Erweiterungskonzept (stereotypes, tagged-values und constraints) grundsätzlich unnötig und nicht zielführend ist
(siehe [PSRO02, Abschnitt 2]).
Durch die völlige Integration des MVC-Konzeptes in die Levels-Dimension (Abb.
3.3, S. 29) ist die getrennte Behandlung der Ebenen Content, Hypertext und Presentation am zielführendsten [LHSG02a,KD02]. Durch Verwendung des MVC-Konzepts
wird neben der konzeptuellen Modellierung auch ein ordentliches Logical und Physical
Modeling ermöglicht. Es kann also nicht nur das logische Konzept modelliert werden, sondern auch die resultierende Software-Architektur (meist bereits in Form von
Klassendiagrammen und component- bzw. deployment-Diagrammen [RJB99, Kap.
9]. Dieser Aspekt ist vor allem für die Modellierung eines Frameworks, wie es in
dieser Arbeit versucht wird, von entscheidender Notwendigkeit. Die Architektur, auf
welcher eine mit dem Framework entwicklete Webapplikation aufbaut, muss bereits
vordefiniert werden. Bei der Konzeption neuer Anwendungen auf Basis des Frameworks entfällt schließlich ein großer Teil an nötigen Aspekten der Modellierung,
wodurch Zeit und Kosten eingespart werden.
11
Die von Rumbaugh et al. entwickelte Object-oriented Modeling Technique, war eine der ersten
objektorientierten visuellen Modellierungssprachen für Software Systeme [RBP+ 91].
31
Conceptual Model
Navigational
Models
another
interface
Interface (presentation) Model
Abbildung 3.5: Überblick über die drei OOHDM-Modelle. Aus [SRB03].
3.3.3
Das OOHDM-Konzept
Da OOHDM die wichtigsten Aspekte berücksichtigt und bereits einen Objekt-orientierten Ansatz verfolgt, soll dieses Konzept in seinen Grundzügen kurz betrachtet
werden. Das OOHDM-Konzept besteht aus drei grundlegenden Modellen: dem konzeptuellen Modell (conceptual model), dem Navigationsmodell (navigational model)
und dem Interface-Modell (interface model). Für jedes Modell gibt es verschiedene
vordefinierte Objekte, welche mittels OMT-Notation kombiniert und modelliert werden [RSG99]. Abbildung 3.5 gibt einen Überblick über die drei Modelle.
Diese Dreiteilung des Entwurfs bei OOHDM ist auch in der Veranschaulichung
von [RS00] (Abb. 3.3, S. 29) in der Levels -Dimension erkennbar. Die Bezeichnung
conceptual model bei OOHDM entspricht hier allerdings nicht so sehr der konzeptuellen Entwurfsphase (auf der Phases -Achse), sondern dem Entwurf der Content -Ebene
(Levels -Achse). Analog dazu entspricht das Navigationsmodell von OOHDM der Hypertext -Ebene und das Interface -Model der Presentation -Ebene. Die Phases - und
Aspects -Dimensionen fallen bei OOHDM also mehr oder weniger zusammen.
Konzeptuelles Modell
In diesem Modell wird im Großen und Ganzen die Grundfunktionalität der Applikation festgelegt. Es werden funktionale Objekte als Einheiten (vgl. Entities im ERSchema) und ihre Relationen zueinander definiert. Die Modellierung erfolgt schwerpunktmässig über UML-ähnliche Klassendiagramme mit ähnlichen Methoden der
Vererbung und Referenzierung (association, generalisation, etc. [RJB99, Kap. 4]).
Abb. 3.6 zeigt ein konzeptuelles Modell als Beispiel. Das Beispiel wurde von [REL01]
übernommen und bezieht sich auf eine einfache Webapplikation, welche Rezensionen
zu Konferenzbeiträgen verwaltet. Es gibt unterschiedliche Rollen von Personen (PC
chair, PC member und Reviewer). Eine Person kann einerseits Beiträge (Papers)
verfassen und andererseits Rezensionen (Reviews) zu anderen Beiträgen erstellen.
32
Expertise
Degree:
[High, Medium, Low]
Topic
IsAbout
Name
Description
HasInterest
Knows
Interest
Degree:
[High, Medium, Low]
Person
Paper
IsAuthorOf
Name
Address
E-mail
Password
HasConflict
Makes
Reviews
Title
Type: [Full, Short, Poster]
Status: [Accepted,
Rejected,
ToBeDiscussed]
Content
CameraReadyContent
Review
PC chair
PC member
Coordinates
Reviewer
Confidence:
[High, Medium, Low]
Technical quality
Relevance
CommentsPC
CommentsAuthors
Recommendation:
[Accept, Weak Accept,
Neutral, Weak Reject,
Reject]
Final?: [Yes, No]
PC Program committee
Abbildung 3.6: Konzeptuelles Modell einer Rezensionsverwaltung für Konferenzbeiträge. Aus [REL01].
Navigationsmodell
Das Navigationsmodell beschreibt die Struktur der Website in Form von Sichten auf
die Applikationslogik (Abb. 3.7) und definiert die Navigation. Es werden zuerst mit
Hilfe von Klassendiagrammen Sichten auf die Datenebene (conceptual model) gelegt,
für die genauere Darstellung der Navigation werden Kontext-Schemas (navigational context schemes) erstellt und schließlich wird mittels Navigationstransformation
(navigational transformation) das Verhalten (Behaviour) der Applikation spezifiziert.
Ein Klassendiagramm des Navigationsmodells besteht aus sogenannten nodeKlassen. Jede node-Klasse enthält Attribute aus verschiedenen Objekten des konzeptuellen Modells. Eine Person im Klassendiagramm des Navigationsmodells (Abb.
3.7) enthält beispielsweise Informationen zu der Person selbst, die Kategorie („PC
member“, etc.), seine Sachverständigkeit (expertise degree) und alle Beiträge, an denen die Person interessiert ist. Die Klasse „Person“ im Navigationsmodell ist Beobachter (observer) der Klassen „Person“, „Expertise“ und „Topic“ des konzeptuellen
Modells. Die Verbindungslinien (links) zwischen den node-Klassen stehen für semantische Verknüpfungen. Die Bedeutung des Navigationsmodells ist im Unterschied
zum konzeptuellen Modell von semantischer Natur.
Für die genauere Darstellung der gesamten Navigation werden Kontext-Schemas
(navigational context schemes) verwendet. Abbildung 3.8 (S. 34) zeigt ein solches Kontext-Schema. Die grau hinterlegten Kästen zeigen node-Klassen aus dem
Klassendiagramm und enthalten mehrere Kontext-Elemente (contexts). KontextElemente geben bestimmte Instanzen der jeweiligen Klasse wieder, wobei die Auswahl der Instanzen über bestimmte Kritierien, wie etwa „Person – alphabetisch“
Person
33
Coordinates
Name
Address
E-mail
Password
Category: [PC chair, PC member
reviewer]
Expertise:
{<T: Topic, self Knows T,
Knows.Expertise.Degrees>}*
InterestedPapers:
{<P: Paper,
self HasInterest P,
HasInterest.Interest.Degree>}*
IsAuthorOf
HasInterest
Paper
HasConflict
Makes
Reviews
Review
Title
Abstract
Type: [Full, Short, Poster]
Topics:
{T: Topic, self IsAbout T}*
Status: [Accepted, Rejected,
ToBeDiscussed]
Content
CameraReadyContent
Reviewer: P.name, P:Person, P makes self
Paper: P.id, P: Paper, self reviews P
Confidence
Technical quality
Originality
Relevance
CommentsPC
CommentsAuthors
Recommendation:
[Accept, Weak Accept, Neutral, Weak
Reject, Reject]
Final?: [Yes, No]
Abbildung 3.7: Klassen des Navigationsmodells. Aus [REL01].
erfolgt. Ein bestimmter Kontext gibt also beispielsweise alle Personen alphabetisch
aus. Kontext-Elemente werden üblicherweise in einer bestimmten Reihenfolge, durch
eine Benutzeranfrage oder dynamisch (hier ändern sich die Instanzen während der
Navigation, z. B. Elemente in einem Warenkorb) generiert.
Strichlierte Kästen repräsentieren Indizes (indexes) oder Zugriffsstrukturen (control structures). Gemeint sind damit konkret „Sichten“, meist in Form einer Seite.
Gestartet wird im Beispiel beim Index „Main menu“. Von dort aus gelangt man zu
den Indizes „Persons“, „Review status“, „Topics“, „Paper IDs“ und „Review/acceptance status“.
Die abgerundeten (oft auch zylindrischen) Symbole stehen für dynamische Kontext-Elemente (dynamic contexts). Diese erlauben das Erstellen neuer Instanzen der
zugehörigen node-Klasse. So kann beispielsweise über den Pfad „Main menu“–„Paper
Creation“ ein neuer Beitrag erfasst werden.
Durch die Spezifikation mehrerer unterschiedlicher Navigationsmodelle können
Rollen-basierte Applikationen erstellt werden. Je nach Berechtigung kann eine andere Navigationsstruktur angeboten werden. Ein beliebiger Gast, hat z. B. keinen
Zugriff auf die dynamischen Kontext-Elemente und kann somit keine neue Einträge
im System tätigen. Genausogut können adaptive, personalisierte Applikationen erstellt werden, wobei die Navigation dynamisch, aufgrund von Informationen über
den Benutzer (welche im Übrigen in den nodes des konzeptuellen Modells erfasst
werden), zusammengestellt wird.
In einem dritten Modell (navigational transformations) kann das Verhalten der
Applikation beschrieben werden. Navigationsobjekte können z. B. aktiviert und deaktiviert werden.
Main menu
34
Review
Creation
Paper IDs
By paper
By reviewer
Paper
Creation
Person
Creation
By ID
Persons
Alphabetical
Topics
By topic
By topic
By reviewer
By paper
By author
Review
status
By review status
By reviewer
interest
Persons
By coordinator
By review status
Review/
acceptance
status
By acceptance
status
Abbildung 3.8: Kontext-Schema des Navigationsmodells. Aus [REL01].
Interface-Modell
Das Interface-Modell definiert schließlich die Benutzerschnittstelle durch Zusammensetzen von verschiedenen vordefinierten Elementen (Abb. 3.9). Je nach Client-Gerät
(PC, PDA, Mobiltelefon, etc.) kann ein anderes Interface verwendet werden. Die
Elemente im Interface-Modell werden, ähnlich wie nodes im Klassendiagramm des
Navigationsmodells, als „Beobachter“ jener nodes definiert, von denen sie Daten zur
Anzeige erhalten (Abb. 3.10).
Bewertung von OOHDM
Die Trennung in ein konzeptuelles Modell, ein Navigationsmodell und ein InterfaceModell bei OOHDM errinnert an das MVC-Konzept: es wird die klare Trennung
zwischen einem konzeptuellen Datenmodell (model, bzw. Content laut Abb. 3.3, S.
29), der Navigation (control bzw. Hypertext) und der Darstellung (view bzw. Präsentation) ermöglicht. Das MVC-Konzept wird bei OOHDM allerdings nur zur Modellierung adaptiert. Die zugrundeliegende Softwarearchitektur (Emfpang der Re-
<<text>>
<<anchor>>
<<button>>

35
<<Audio>>
<<Video>>
<<form>>
<<collection>>
<<anchored collection>>
Abbildung 3.9: Stereotypen für das Interface-Modell. Aus [BM98].
<<navigational class>>
<<ADV>>
ADV Book
<<text>>
...
Book
title: String
price: Number
/publisher: String
/genre: String
...
Abbildung 3.10: Einfache Verknüpfung eines Interfaces mit der entsprechenden
Navigationsklasse. Aus [BM98].
quests, Session-Behandlung, Deployment 12 u.ä.) der endgültigen Anwendung wird
nicht ausreichend definiert.
Das Konzept eignet sich am Besten für die Entwicklung von Dokument-zentrischen Webapplikationen mit Datenbank-gestütztem Inhalt. Ein Nachteil ist allerdings, dass die Notation relativ komplex wird (was sich jedoch durch die gegebene
Komplexität einer Webapplikation grundsätzlich kaum vermeiden lässt). Bei aufwändigen Webapplikationen scheitert jedoch auch OOHDM [LHSG02a]. Des Weiteren
ist kaum Literatur über OOHDM zu finden und die Formalismen und Notationen ändern sich ständig durch neue Anpassungen, Erweiterungen und Ideen anderer Leute.
3.3.4
Das Konzept von J. Conallen
Jim Conallen, Software-Architekt bei der nun zu IBM gehörenden Rational Software
Corporation13 , hat bereits 1998 mit der Entwicklung von UML-basierten Modellen
für Webapplikationen begonnen [Con03, Vorwort]. Durch seine Arbeit bei Rational
und den richtigen Leuten im Umfeld (u. a. Grady Booch – einer der Three Amigos,
welche seit Beginn der 90er Jahre UML entwickelten), konnte er sein UML-basiertes
Modell zur Modellierung von Web-spezifischen Anwendungen entwicklen. Von Conallen gibt es u. a. auch das einzige Buch über Web Engineering mit UML, welches
bereits in einer zweiten Auflage erschienen ist [Con03].
Conallen verwendet UML von Grund auf und erweitert den Formalismus mit
sterotypes und tagged values14 . Nach Abb. 3.3 (S. 29) werden bis auf den Behaviour12
Unter to deploy versteht man das Aufsetzen der gesamten Software mit all ihren Komponenten
[Con03, S. 128].
13
Siehe http://www.rational.com.
14
Mit stereotypes lassen sich neue Modellelemente, durch die Zuweisung eines zusätzlichen, frei
definierbaren Charakters an das Basiselement, bilden. Tagged values erlauben die Assoziation von
36
Aspekt so gut wie alle Ebenen und Aspekte gleichermaßen berücksichtigt. Die Analyse von [RS00] aus dem Jahre 2000 ist für den aktuellen Entwicklungsstand der Methode Conallens allerdings nicht mehr relevant. Laut [RS00] bietet Conallen keine
Methode zur Modellierung des Behaviour-Aspekts außerhalb der vordefinierten Stereotypen (Abb. 3.3, S. 29). Das heißt der Behaviour-Aspekt in der Hypertext- und
Präsentationsebene wäre bloß über die Verwendung von Stereotypen (z. B. für ClientScript Elemente) berücksichtigt. Was jedoch in der Navigationsstruktur bzw. in der
Ansicht genau passiert, könne demnach nicht modelliert werden. Conallen’s Modell
unterstützt die Modellierung des Behaviour-Aspekts aber nun mittels den passenden
UML-Diagrammen: sequence und collaboration diagram. Sein Konzept unterscheidet
sich grundlegend von OOHDM, RMM u.a. und verwendet vorrangig Methoden aus
dem traditionellen Software-Engineering anstelle von Hypermedia-Konzepten. Er
berücksichtigt vor allem auch die Möglichkeit von Applikationslogik am Client in
Form von Scripts, ActiveX-Ojekten oder Applets [Con03, Kap. 3–4].
In der zweiten Auflage seines Buchs [Con03] liegt ein Schwerpunkt in der Definition des gesamten Web Engineering Prozesses, wobei auch hier durchgehend UMLNotationen verwendet werden [Con03, S. 112]. Der Gesamtprozess wird bei Conallen
in verschiedene Pakete (artifact sets) gegliedert, welche im Übrigen in einem model
management view [RJB99, Kap. 10] dargestellt sind. Jedes dieser artifact sets besteht bei Conallen aus mehreren passenden Werkzeugen, Modellen und Methoden.
Er definiert auch Rollen (z. B. Software Architekten, Designer, Implementers, etc.)
und weist jeder dieser Rollen in jedem Paket Aufgaben zu. Bei Conallen gibt es im
Prozess keine sichtbare Trennung der Ebenen Content, Hypertext und Präsentation.
Die Entwicklung erfolgt über die Pakete Analysis set, Design set und Implementation
set.
Analysis set
Das Analysis set definiert unter anderem die Architektur der Applikation und teilt
diese in kleinere Sub-Systeme. Kaum ein Kozept (einschließlich OOHDM) definiert
die zugrundeliegende Architektur des Systems, welche für die Spezifikation eines Framework von entscheidender Bedeutung ist. Im Analysis set werden weiters beispielhafte Anwendungsfälle (use cases) analysiert und es wird bereits ein grober Ablauf
(abstraktes Behaviour) mittels sequence-Diagramme definiert [Con03, S. 119].
Design set
Die Hauptaufgabe in diesem Schritt ist, die in der Analyse erarbeiteten Modelle
softwaretechnisch umzusetzen. Software-Architekten definieren in diesem Workflow
eine Prozessansicht, die die Softwarearchitektur in Untersysteme teilt. Es wird auch
festgelegt, welche Komponenten und Objekte sich in welcher Architektur-Schicht
(Application tier, Data tier, etc. ) befinden. Diese Phase kann noch am ehesten mit
der Content-Ebene aus Abb. 3.3 (S. 29) verglichen werden, ist jedoch viel genauer und
berücksichtigt auch die Architektur und die Umgebung. Die Modellierung kann hier
konsequent mit allen UML-Notationen erfolgen. Eine komplexe Applikationslogik ist
damit modellierbar.
Schlüssel/Wert-Paaren an ein Modellelement [RJB99, Kap. 10].
37
Abbildung 3.11: Einfache Verknüpfung von Seiten auf Basis der WAE für UML.
Aus [Con03, Kap. 11].
Das Design-Team modelliert die einzelnen Untersysteme der Prozessansicht mittels Klassen. Diese Klassen (design-level classes [Con03, S. 120]) enthalten allerdings
noch keine Details zur Implementierung. Die Aufgabe dieser Klassendiagramme ist
das Verhalten der Applikation (business behaviour) auf einer höheren Abstraktionsstufe festzulegen. Anschließend erfolgt die Modellierung aller einzelnen Webseiten.
Webseiten werden bei Conallen jeweils in einer Server-seitigen und in einer Clientseitigen Instanz modelliert. Er erweitert den Formalismus mit sterotypes und eigenen
Icons (Abb. 3.11).
Die Erweiterungen nennt Conallen WAE (Web Application Extension) für UML15 .
Eine Client-Seite wird hier stets von ihrer zugehörigen Server-Seite generiert. Eine
Server-Seite kann allerdings mehrere unterschiedliche Instanzen der Client-Seite erstellen. Als Assoziationen (Hyperlinks) zwischen den Seiten werden sterotypes wie
etwa link, build (Erstellung einer Client-Seite), oder submit (bei Eingaben über Formulare) verwendet. Conallen’s Modell erlaubt auch die Verwendung von mehreren
Fenster-Instanzen und Frames, was in der Praxis relativ häufig gefordert ist.
Implementation set
Schließlich können auf Basis der Design-Modelle alle Komponenten implementiert
werden. Soweit dies möglich ist, können hier auch CASE tools 16 eingesetzt werden.
Als wichtigen Teil des Implementierungsprozesses erwähnt Conallen auch das Testen,
welches ein essentieller Bestandteil im eXtreme Programming17 Paradigma ist.
Am Ende der Kette steht bei Conallen’s Model noch das Deployment set. In
diesem Prozess wird die fertig entwickelte Anwendung in der zuvor definierten Umgebung aufgesetzt.
15
Dazu unterhält Jim Conallen auch eine Website unter der URL http://www.wae-uml.org.
Computer-aided Software Engineering tools sind Werkzeuge, die die Erstellung von Quellcode
anhand von Modellen ermöglichen.
17
XP ist eine Methode, bei der das Programmieren an sich im Vordergrund steht. Die Methode
kann in gewisser Hinsicht als konträr zur Modell-untersützten Programmierung angesehen werden
[HL02, Kap. 1].
16
38
Bewertung des Modells nach J. Conallen
Conallen’s Modell ist relativ mächtig. Es behandelt alle Ebenen und Aspekte aus der
Analyse von [RS00] und ermöglicht auch die Modellierung von Applikationen mit aufwändiger Applikationslogik. Das Konzept entstammt eher der Software-Engineering
als der Hypermedia-Engineering Domäne (vgl. Abb. 3.13, S. 40). Die Modellierung
der Hypermedia-Ebene erfolgt bei Conallen zum Teil innerhalb der Applikationslogik. Abbildung 3.12 zeigt einen Ausschnitt aus dem Design Modell einer Katalogsuche. Die Server-Seite „Listing“ (Server-Seiten werden mit einem Zahnrad als Icon
notiert) enthält beispielsweise einen Parameter „index“, welcher die aktuelle Seite
des Suchergebnisses speichert. Es gibt zwei Aktionen „next“ und „prev“ (als Links
dargestellt), über welche die Seiten des Suchergebnisses durchgeblättert werden können. Die Server-Seite generiert nach der Aktion die jeweils aktuelle Client-Seite. Die
Modellierung erfolgt ausschließlich mit UML.
Conallen bietet durch zahlreiche Modelle und die durchgehende UML-Notation
ein umfassendes Konzept zur Beschreibung von Webapplikation. Er geht auch auf
die Umgebung und die Architektur als Basis der Applikation ein. Er ermöglicht
die Modellierung von Client-seitiger Appliaktionslogik, sowie die Verwendung von
mehreren Browser-Instanzen und Framesets.
Ein Nachteil der Methode von Conallen ist ihre Komplexität. Vom Entwickler
wird eine detaillierte Kenntnis von UML gefordert. Die Methode Conallens eignet
sich auf Grund ihrer Komplexität und des damit verbundenen Modellierungsaufwandes auch nur für wirklich große Projekte. Da bei kleineren bis mittelgroßen
Applikationen mit einem zu großen Overhead zu rechnen ist, wird die Methode bei
solchen Projekten weniger nützlich sein.
3.4
Modellierung auf Basis der Architektur von DaVinci
Viele Entwicklungskonzepte für Webapplikationen beruhen durch ihren Ursprung in
der Hypertext- bzw. Hypermedia-Domäne traditionell auf der Navigation in einem
Netz aus Hyperlinks. Diese Tatsache ist ein Grund, warum viele Versuche ein Konzept zu finden, welches alle Dimensionen aus Abb. 3.3 (Seite 29) berücksichtigt und
dennoch einfach und überschaubar bleibt, scheitern. Webapplikationen sind durch
die Kombination des Hyper-Paradigmas (der Verknüpfung von Ressourcen jeglicher
Form in einem weltweiten Netz aus Hyperlinks), und der nötigen Applikationslogik äußerst schwierig zu planen und zu konzipieren. Anwendungen mit komplexer
business logic sind mit Hypermedia-Techniken kaum konzipierbar. Auch OOHDM
würde trotz der seperaten Modellierung der Content-Ebene (in ihrer Struktur, sowei
im Verhalten) bei aufwändigen Webapplikationen scheitern [LHSG02b]. Techniken,
die eher mit dem traditionellen Software-Engineering verwandt sind (vgl. Conallen),
bieten eventuell ausreichend Komplexität, sind aber dadurch im praktischen Einsatz
im Nachteil.
Grundsätzlich können zwei Richtungen der Annäherung zur Webapplikation identifiziert werden. Die einen Konzepte wurzeln im Hypermedia-Bereich und näherten
sich von ursprünglich statischen Hypertext-Anwendungen über dynamische Websites
in Richtung Webapplikation. Der andere Ursprung liegt im traditionellen SoftwareEngineering, wo Applikationen auf die Web-Schiene verlagert wurden, da sich dadurch erhebliche Möglichkeiten auftun [LHSG02a].
39
Abbildung 3.12: Design-Modell einer Katalogsuche. Aus [Con03, S. 251].
Jene Applikationen, welche dem Hypermedia-Bereich entstammen sind von Natur
aus Dokument-zentrisch und fokussieren die Informationsarchitektur. Webapplikationen welche aus dem Software-Engineering stammen, sind traditionell auf die funktionelle Architektur spezifiziert [LHSG02a, S. 105]. Abbildung 3.13 (aus [LHSG02b])
zeigt die Annäherung aus beiden Domänen grafisch. Die Autoren konnten keine Konzepte identifizieren, welche mächtig genug für die Erfüllung beider Anforderungen
(die Berücksichtung der Informations-Architektur gleichsam wie die der funktionellen Architektur) erschienen.
3.4.1
Vereinfachung der Architektur
Ein anderer Ansatz, welcher im Rahmen dieser Arbeit für das DaVinci Framework
verfolgt wird, ist, anstatt neue, bessere Modelle für die vorliegende Architektur zu
finden, die Architektur von Webapplikationen auf bestimmte Weise zu vereinfachen,
40
High
Existing Modelling Approach Gap Analysis
Modelling Language Support
for Functional Architecture
Target Zone
Conallen [11]
UML [10]
W2000 [9]
HDM-lite [8]
Li [12]
OOHDM [7]
WebML [6]
Koch [5]
RMM [4]
Low
HDM [3]
Low
Modelling Language Support
for Information Architecture
High
Abbildung 3.13: Analyse existierender Versuche für Modellierungskonzepte (aus
[LHSG02a]). Auffallend ist, dass die Autoren keine Konzepte identifizieren konnten,
welche die Informationsarchitektur sowie die funktionelle Architektur gleichermaßen
berücksichtigen.
dass einfachere Modelle möglich sind bzw. bei der Modellierung auf traditionelle Mechanismen aus dem Software-Engineering zurückgegriffen werden kann, ohne diese
erweitern zu müssen. Jeder Versuch der Erweiterung der traditionellen Modelle für
Hypermedia-Umgebungen wird zwangsweise äußerst komplex. Durch die Vielzahl an
Versuchen, solche Konzepte zu finden (wobei nur eine kleine Auswahl auch wirklich
von praktischem Nutzen ist), existieren nun zahlreiche halbfertige, nicht standardisierte Konzepte, welche teilweise wieder verändert und erweitert werden. Einige
Konzepte erfinden neue Notationen und Diagramme (u. a. auch OOHDM), obwohl
UML eigentlich genügend Erweiterungsmethoden des Basis-Konzepts zur Verfügung
stellt [PSRO02, Kap. 2]. Die Akzeptanz der Konzepte läßt dadurch zu wünschen
übrig.
Die meisten der vorliegenden Konzepte geben kein klares Architekturkonzept vor,
nach dem der technische Ablauf der Applikation stattfindet. Conallen geht zumindest
auf die Architektur ein und behandelt in seinem Buch zahlreiche Aspekte der Architektur von Webapplikationen. Sein Modellierungskonzept ist jedoch völlig allgemein
gehalten und ermöglicht die Modellierung von Applikationen in jeder Umgebung.
Dadurch ist sein Konzept äusserst komplex. Fast alle anderen Konzepte (OOHDM,
RMM, Baumeister et al. etc. – vgl. dazu Abb. 3.4, S. 29) legen den Schwerpunkt auf
die Modellierung der Applikation. Will man ein Framework für Webapplikationen
entwickeln, muss man sich neben der Modellierung auch intensiv mit der Architektur
41
von Webapplikationen auseinandersetzen (siehe Abschnitt 3.2. Eine Vereinfachung
der Architektur muss allerdings nicht unbedingt auch eine Einschränkung an Möglichkeiten bedeuten.
3.4.2
Überwindung des Hyper-Paradigmas
Die Kombination des Hyper-Paradigmas mit traditionellem Software-Engineering
ist eine Herausforderung bei der Modellierung von Webapplikationen. Im Folgenden wird versucht, die Architektur des Frameworks so zu spezifizieren, dass die
Modellierung mit etablierten Methoden des Software-Engineerings ermöglicht wird
und das Hypermedia Paradigma mehr oder weniger entfällt. Die Berücksichtigung
des Hypermedia-Charakters soll natürlich nicht ganz auf der Strecke bleiben, zumal sich eine Webapplikation im WWW befindet. Es wird jedoch versucht, die
Hypermedia-Aspekte als Teil der Applikationslogik zu definieren. Die Navigation
soll beispielsweise innerhalb der Applikationslogik modelliert werden. Typische Hypermedia Design Patterns (vgl. Buch-, Netz- oder hierarchische Navigation [GC00])
können dann von spezifischen Klassen mit traditionellen UML-Notationen modelliert werden. Auch die gesamte Benutzeroberfläche, also die Zusammensetzung einer
Seite im Browser mit verschiedenen Unterelementen (z. B. Navigation, eigene TextContainer und -Boxen, etc.), soll als Teil der Applikationslogik entwickelt werden
können.
Die folgenden Überlegungen sollen dabei helfen:
Interaktion über Hyperlinks
Die Tatsache, dass die grundlegende Benutzerschnittstelle über HTTP gegeben ist
und Interaktion meist nur unidirektional vom Client zum Browser erfolgt (die Möglichkeit von Server-Objekten über RMI oder ActiveX [Con03, Kap. 4] wird vorerst
ausgeschlossen), provoziert folgende Überlegung:
Bei Webapplikationen wird jede Interaktion durch eine URL spezifiziert. Diese
URL kann für die Interaktion erforderliche Parameter enthalten und ist immer auf
eine bestimmte Aktion ausgerichtet, welche den Applikationsstatus (business state)
ändert. Als Beispiel sei die Suchabfrage in einer Mediendatenbank erwähnt. Ein
HTTP-Request enthält hier beispielsweise als Parameter die Suchkriterien. Durch
Senden des Requests wird in der Applikation das aktuelle Suchergebnis produziert
und ausgegeben. Handelt es sich nun um eine richtige Webapplikation sollte das
Suchergebnis nach weiterem Durchstöbern noch erhalten bleiben. Die Session-Behandlung sorgt für die Identifikation des Benutzers über mehrere Requests hinweg
und speichert das Abfrageergebnis.
Auf einer abstrakten Ebene kann die Interaktion bei Webapplikationen folgendermaßen definiert werden. Es gibt einerseits das System (die Webapplikation) und
den Benutzer (als Akteur). Jede Interaktion (HTTP-Request) verändert den Status
des Systems (siehe Abb. 3.14). Betrachtet man das Hypermedia-Modell einer Webapplikation als ein Netz aus verschiedenen Knotenpunkten, wobei jeder Knoten eine
bestimmte Ansicht repräsentiert, so kann die Navigation auch durch den aktuellen
Knotenpunkt, bei dem sich der Benutzer zu einer bestimmten Zeit aufhält, definiert
werden. Somit ist sie Teil der Applikationslogik und kann mit ihr in Kombination
modelliert werden, ohne dass eine komplexe Verschmelzung des Hyper-Paradigmas
Sicht des Benutzers
42
System-Sicht
Darstellung von Daten
und Interaktionselementen
Datenbanken
Benutzer
oberfläche
Daten
Applikationslogik
persistente
Objekte
Benutzer
(ist evtl.
Mitglied in
Benutzergruppe)
Rechte
verwaltung
führt
Aktion
aus
Interaktion
Benutzerschnittstelle
Webapplikation
Abbildung 3.14: Interaktion bei Webapplikationen.
mit der Applikationslogik notwendig ist. Eine Klasse, welche z. B. für die Navigation
in Form eines Baum-Patterns zuständig ist, implementiert Funktionen wie „next“,
„previous“, „levelup“ oder „leveldown“ und speichert die jeweilige Position innerhalb
des Baumes.
Ein Hyperlink definiert demnach eine eindeutige Funktion mit zugehörigen Parametern welche etwa über die GET- oder POST-Methode mitgesendet werden. In
Kombination mit dem MVC-Pattern wird ein zentraler Controller definiert, der alle
Aktionen entgegennimmt und entsprechend ausführt. Eine Rollen-basierte Interaktion ist bei diesem Konzept äußerst einfach zu realisieren, da alle Requests an einer
zentralen Stelle behandelt werden. Bestimmte Aktionen können beispielsweise nur
für eine ausgewählte Benutzergruppe definiert werden.
Szenegraph-Modell für Ansichten
Da die Benutzeroberfläche einer Webapplikation in der Regel nicht aus einer einzigen
Ansicht besteht, sondern aus verschiedenen Containern, Boxen und Rahmen, muss
eine hierarchische Verschachtelung mehrerer Ansichten (views) möglich sein. Zusätzlich muss der aktuelle Status der gesamten Benutzeroberfläche ebenfalls innerhalb der
Applikationslogik gespeichert werden können. Für diesen Zweck eignet sich ein sogenanntes Szenegraph-Modell, welches auch in der Computergrafik (VRML, Java3D,
diverse OpenGL APIs 18 ) eingesetzt wird . Ein Szenegraph ist ein hierarchisches
Modell in Form eines Baumes. An bestimmten Knotenpunkten können beispielsweise Ansichten angebunden werden, oder aber auch andere funktionale Elemente.
Solche funktionalen Elemente sind beispielsweise Schalter, welche ganze Sub-Bäume
aktivieren und deaktivieren können.
18
Siehe z. B. http://openscenegraph.sourceforge.net.
43
Browser-Fenster
Navigationsleiste
Hauptnavigation
Seitenkörper
Fußleiste
Sub-Navigation
Content
News-Box
Schalter
Content-Modul
Produktinfo
News-Artikel
E-Mail
Kontaktformular
Abbildung 3.15: Beispiel für einen einfachen Szenengraphen für Web-Oberflächen
Die Verwendung eines solchen Modells ist auch für Webapplikationen denkbar.
Die Grundstruktur der Benutzeroberfläche kann beispielsweise als Szenegraph modelliert werden, wobei an bestimmten Stellen Schalter angebracht sind. Diese Schalter
erlauben etwa das Aktivieren und Deaktivieren von Unterbäumen. Das Umschalten der Unterbäume geschieht durch Interaktion (also über URLs) und der aktuelle
Status des Szenegraphen wird im Applikationsstatus gespeichert. Die Navigation
funktioniert in diesem Fall anders als bei traditionellen Webseiten. Eine URL ist
hier kein Verweis auf ein einzelnes Dokument, sondern auf eine Interaktion, welche die Anzeige verändert. Die Anzeige wird beispielsweise dahingehend verändert,
dass in einem bestimmten Bereich der Benutzeroberfläche eine anderes Dokument
dargestellt wird. In Abbildung 3.15 ist ein einfaches Szenengraph-Modell für eine
Webapplikation dargestellt. Es repräsentiert die Oberfläche einer Website für Produktinfos, welche von einem Content Management System gespeist wird. Die Seite
unterteilt sich in eine Navigation, einen Seitenkörper in der Mitte und eine Fußleiste.
Der Content im Seitenkörper kann über einen Schalter je nach Bedarf gewechselt werden. Produktseiten werden beispielsweise von einem Content-Modul erstellt, andere
Module sind etwa für die Anzeige von News-Artikeln, Kontaktformularen, etc. . verantwortlich. Außerdem werden die aktuellsten Neuigkeiten neben dem Seiteninhalt
in einer kleinen Box (News-Box) angezeigt.
Die im Baum als Knoten definierten Views können etwa als JSP-Seiten oder
im Fall von PHP als ganz normale Skripts erstellt werden. Innerhalb dieser ViewSkripts sind bestimmte Daten (eventuell in Form von eigenen Objekten) aus der
Applikation erforderlich. JSP-Seiten verwenden dafür häufig sogenannte Custom
tags (benutzerdefinierte Markup-Elemente), welche die Kapselung von Java-Code in
HTML-ähnliche Elemente ermöglicht. Dadurch soll es Designern, welche in der Praxis die Ansichten entwerfen, ermöglicht werden, ohne Programmierkenntnisse CodeElemente zu platzieren [Sun03].
Eine genauere Beschreibung des Modells ist anhand des DaVinci Konzepts in
44
Abschnitt 4.4.1 zu finden.
Modellierung
Durch Integration der Benutzerinteraktion und der Ansichten in die Applikationslogik, können alle drei Komponenten des MVC-Patterns mit klassischen Methoden
und auch sehr gut mit UML modelliert werden. Die Strategie eignet sich im Übrigen hervorragend für Webapplikationen mit Schwerpunkt auf den Applikationsteil.
Eine traditionelle, lokal ausgeführte Anwendung wie etwa Microsoft Word, besitzt
genauso eine persistente Benutzeroberfläche mit verschiedenen Menüleisten und Unterfenstern usw., welche ein- und ausgeblendet werden können. Bei Java AWT19
wird auf ähnliche Weise eine hierarchische, grafische Benutzeroberfläche zusammengestellt. Applikationen mit vorwiegend unterschiedlichen und ständig wechselnden
Ansichten, würden zwar ein relativ komplexes Szenegraph-Modell erfordern, solche
Anwendungen können jedoch auch mit anderen Methoden nur mit viel Aufwand
modelliert werden.
3.4.3
Model-View-Controller Pattern
Das Model-View-Controller Konzept, meist einfach als MVC abgekürzt, stammt ursprünglich aus der Programmierumgebung Smalltalk und dient seit Smalltalk-80 zur
Implementierung von grafischen Benutzeroberflächen (GUI) [Hun97, S. 266ff]. Die
Grundidee ist die Trennung von Anwendung und Benutzerschnittstelle. Das Konzept
besteht aus den folgenden Objekten, wobei jedes einen bestimmten Aufgabenbereich
erfüllt:
Model – das „Datenmodell“ der Anwendung. Es dient einerseits zur Datenhaltung
und Speicherung und auch zur Datenverarbeitung. Es beinhaltet den Großteil
des „Verhaltens“ (behaviour bzw.business state) der Applikation.
View – dient zur Präsentation der Daten. Dieser Teil stellt die Ansichten der Benutzerschnittstelle dar, das was der Benutzer sieht.
Controller – dieser Teil der Benutzerschnittstelle stellt Interaktionsmöglichkeiten
zur Verfügung. Er kontrolliert das model.
Das MVC-Konzept ist heute in der objektorientierten Programmierung allgegenwärtig und wird auch von den Sun Java Blueprints20 für die J2EE-Umgebung als
Design Pattern vorgeschlagen [Sun02b]. In [SSJ02, Abschnitt 4.4] empfiehlt Sun
(BluePrints) beispielsweise zur Implementierung des Web-tiers einer Geschäftsapplikation die Verwendung des MVC-Patterns.
Alan Knight und Naci Dai, beide Smalltalk- und Java-Entwickler und Mitglieder
der ACM21 , haben ebenfalls eine Architektur für Webapplikationen auf Basis des
19
Der Java Abstract Windowing Toolkit dient ähnlich wie Java Swing zur Erstellung von grafischen
Benutzeroberflächen für Java-Anwendungen (siehe Java Dokumentation unter http://java.sun.com/
docs).
20
Die Java BluePrints bieten Best Practise-Lösungen für den Einsatz von Java Technologien.
Siehe http://java.sun.com/blueprints.
21
Die Association for Computing Machinery wurde bereits 1947 gegründet und ist die älteste und
größte Vereinigung für Forschung und Lehre der Informatik. Siehe http://www.acm.org.
WAP
45
WAP input
controller
Input
controller
HTTP
HTTP input
controller
Application
controller
Finds and executes
Action
XML view
XML
JavaServer
Page view
JavaServer
Page
View
Abbildung 3.16: Web-tier Architektur auf Basis des MVC-Patterns nach [KD02, S.
54].
MVC-Patterns veröffentlicht [KD02]. Abbildung 3.16 zeigt die Architektur schematisch. Der controller teilt sich hier in einen input und application controller.
Alle HTTP-Anfragen werden vom Input controller (bei Sun auch FrontController
genannt [SSJ02, S. 97]) empfangen, welcher die Anfrage an den application controller weiterleitet. Dieser hat Zugriff zur Applikationslogik und dem model (welches in
der Abbildung innerhalb des application controller gedacht werden muss) und führt
die gewünschte Aktion aus. Views dienen am Ende des Requests zur Darstellung von
Daten im Browser. Das Konzept von [KD02] verwendet für jeden Client-Typ einen
eigenen input controller. Als Client-Typen sollen dadurch nicht nur unterschiedliche
HTTP-Clients, sondern sogar auf anderen Protokollen basierende Clients tauglich
sein.
Durch die Trennung von Datenhaltung, Applikationslogik/Interaktion und Präsentation in drei Schichten kann – wie im Übrigen auch im OOHDM-Konzept erkannt
wurde – jede Schicht durch eine andere ausgetauscht werden. Es kann beispielsweise
eine Präsentationsschicht für unterschiedliche Clients definiert werden.
MVC als Pattern zur Modellierung und in der Architektur
Die Java BluePrints [SSJ02] und das Konzept von [KD02] verwenden den MVCPattern direkt in Bezug auf die Architektur einer Webapplikation. Bei OOHDM
wird der Patterns hingegen für die Modellierung adaptiert. Es wird bei OOHDM
zwar nicht direkt auf den MVC-Pattern verwiesen, es lassen sich allerdings Parallelen erkennen. Die Architektur wird bei OOHDM nicht spezifiziert. Ein anderes
Konzept, von David Lowe et al. [LHSG02a], verwendet den MVC-Pattern bewusst als
Basis eines erweiterten konzeptuellen Modells (extended conceptual model, siehe Abb.
46
Extended Conceptual Model
Model
Controlle
r
View
Composition
Presentation
Information Architecture
Navigation
Operation
Functional Architecture
Abbildung 3.17: Erweitertes konzeptuelles Modell nach Lowe et al. Aus [LHSG02a].
3.17). Für die Modelle wird allerdings UML um neue Diagramme ergänzt, was prinzipiell nicht nötig wäre, da UML genug Erweiterungsmethoden bietet [PSRO02]. Das
Konzept stützt sich zwar deutlicher auf die Vorteile von MVC und legt einen Schwerpunkt auf die Applikationslogik, bietet aber auch keine konkrete Softwarearchitektur
auf Basis des Patterns. Eine solche Architektur sollte beispeilsweise definieren, wie
HTTP-Anfragen verarbeitet werden, wie und wo das model verwaltet wird und wie
die Zusammenstellung und Auswahl der views erfolgt. Die Softwarearchitektur ist
für die Implementierung eines Frameworks ausschlaggebend.
Model 1 und Model 2 Architektur
Im Vorschlag der Java BluePrints [SSJ02] wird die Softwarearchitektur einer Webapplikation spezifiziert. Es werden zwei unterschiedliche Anwendungskonzepte des
MVC-Patterns für Webapplikationen vorgestellt, welche ursprünglich in der Spezifikation von JSP definiert wurden [Qus03]:
Model 1: Hier werden für jede Webseite am Server JSP-Seiten verwendet (Abb.
3.18). JSP-Seiten enthalten (ähnlich wie ASP oder PHP) HTML-Code und
spezielle Skript-Elemente. In einer Model 1 Architektur wird die Benutzerinteraktion über JSP-Seiten abgewickelt. Controller und view sind hier nicht
ordentlich getrennt. Diese Methode eignet sich bei kleineren dynamischen
Websites, wie etwa für ein Gästebuch oder ein E-Mailformular. Für größere
Webapplikationen ist die Model 2 Architektur jedoch besser geeignet.
Model 2: Bei dieser Architektur dient ein Servlet als controller (Front-Controller,
Abb. 3.19). Es übernimmt alle HTTP-Anfragen und führt in der Applika-
47
Abbildung 3.18: Model 1 Architektur. Aus [Qus03].
Abbildung 3.19: Model 2 Architektur. Aus [Qus03].
tionslogik die entsprechenden Aktionen aus, bevor es am Ende an ein view
weiterleitet. Views werden mittels JSP-Seiten realisiert.
Zur Erstellung von Webapplikationen ist grundsätzlich nur Model 2 interessant,
da eine strikte Trennung nach dem MVC-Konzept angestrebt werden muss. Das
DaVinci Framework basiert auf dieser Model 2 Architektur. Auch das Java-basierte
Struts Framework (siehe Abschnitt 2.3.2) verwendet dieses Konzept.
3.4.4
Modellierung auf Basis des DaVinci Frameworks
Das DaVinci Framework nimmt einen Großteil der Modellierungstätigkeit ab, da die
Architektur im Großen und Ganzen bereits vorgegeben ist. Die Benutzerinteraktion,
die Darstellung und ein Teil der Applikationslogik sind von der Softwarearchitektur her bereits festgelegt. Die Modellierung neuer Webapplikationen auf Basis des
Frameworks wird erheblich vereinfacht. Im Folgenden wird ein Konzept angedacht,
nachdem die Modellierung für DaVinci -basierte Anwendungen auf Basis von UML
erfolgen könnte.
Es wird hier nicht der gesamte Entwicklungsprozess definiert, sondern bloß der
Teil der DaVinci -spezifischen Modellierung. Der Gesamtprozess kann nach einer beliebigen Methode erfolgen. Nach der Anforderungsanalyse müssen folgende Schritte
der Modellierung behandelt werden:
Grober, funktioneller Entwurf: Ein grober Entwurf der nötigen Funktionalität
hilft, einen Überblick über die erforderlichen Komponenten zu schaffen. Er
48
soll die gesamte Applikationslogik auf einer überschaubaren Abstraktionsstufe
spezifizieren. UML-Diagramme (vorwiegend use case- und einfache Klassendiagramme) können verwendet werden.
Szenegraph: Conallen nennt in seinem Prozess den Anwender-zentrischen Entwurf
UX model (User-Experience Model) [Con03, Kap. 9]. In diesem Schritt wird
u. a. die gesamte view-Komponente modelliert, der wichtigste Teil der Benutzerschnittstelle. Ein schlechtes UX-Modell wirkt sich auf die Ergonomie und
Benutzerfreundlichkeit der Anwendung aus. Auch für DaVinci -basierte Webapplikationen ist es ratsam, nach dem groben funktionellen Entwurf den Szenegraph zu entwerfen. Dafür eignet sich ein UML-Klassendiagramm mit definierten Stereotypen. View- und switch-Knoten werden als Klassen dargestellt.
Die für ein view zur Anzeige von Daten benötigten Objekte können als Parameter definiert werden.
Aktionen: Nach Konzeption der view-Hierarchie wird der Szenengraph um das Interaktionmodell erweitert. Da Aktionen immer über views angesprochen werden (also über in views enthaltene Hyperlinks oder HTML-Formulare), können
Aktionen auch als Methoden der views angesehen werden. Für jede Aktion wird
daher eine eigene Methode mit den erforderlichen Parametern der betroffenen
view-Klasse definiert.
Verhalten: Im DaVinci Framework wird für jede Aktion eine eigene Klasse verwendet. Eine solche Aktionsklasse enthält eine bestimmte Funktion (execute ()),
welche beim Ausführen dieser Aktion vom Framework aufgerufen wird. Einfache Aktionen verändern beispielsweise bloß den Szenegraph durch Umschalten
eines Unterbaumes und dienen somit nur zur Navigation. Aktionen welche
mehr bewirken, können in diesem Schritt mittels activity-, statechart- oder
sequence-Diagramm veranschaulicht werden. Auch der Rest der Applikationslogik wird nun mit dynamischen Ansichten modelliert. Für persistente Objekte
steht bei DaVinci ein eigener model-Stereotyp zur Verfügung. Model-Klassen
existieren über einzelne Requests hinaus und werden in der Session gespeichert.
Für die Datenhaltung wird im DaVinci Framework auch noch ein repositoryStereotyp verwendet. Über ein solches repository können Daten nach einem relationalen Schema (vgl. Relationale Datenbank [Sau94]) temporär für die Dauer der
Sitzung, oder in einer angebunden Datenbank gespeichert werden. Am Ende der
Modellierung kann die Implementierung beginnen. In Kapitel 5 wird anhand eines
Praxisbeispiels nochmals im Detail auf die Modellierung mit DaVinci eingegangen.
Kapitel 4
Design und Architektur eines
Frameworks für Webapplikationen
Dieses Kapitel beschreibt das im Rahmen der Diplomarbeit konzipierte DaVinci
Framework. Es werden die Architektur der Umgebung und die wichtigsten Komponenten und Klassen beschrieben. Eine detaillierte Beschreibung aller Klassen, deren
Eigenschaften und Funktionen, würde den Rahmen der Arbeit sprengen. Das Framework ist bereits relativ umfangreich. Dieses Kapitel beschränkt sich daher bloß
auf das grundlegende Konzept und die Architektur von DaVinci.
Im ersten Abschnitt wird die Architektur im Überblick beschrieben. Die weiteren
Abschnitte beschreiben die Komponenten zur Benutzerinteraktion, Applikationslogik, Darstellung und Datenhaltung genauer.
4.1
Architektur im Überblick
Das DaVinci Framework basiert im Wesentlichen auf zwei spezifischen Eigenschaften. Zum einen ist die Verwendung des im vorigen Kapitel beschriebenen SzenegraphModells für die Darstellung der Benutzeroberfläche, also der jeweiligen Seite im Browser, wesentlich. Die zweite Besonderheit ist die Festlegung, dass jede Benutzerinteraktion durch eine eigene URL definiert wird. Das heißt auch, es muss für jede unterschiedliche Interaktion eine eigene URL und ihre zugehörige Aktionsklasse festgelegt
werden. Für die Administration einer Kundendatenbank wären etwa die Aktionen
„neuen Kunden anlegen“, „Kundendaten bearbeiten“, „geänderte Daten speichern“,
„Kunde löschen“ von Nöten, wobei für jede dieser Aktionen jeweils eine eigene URL
mit einer eingenen Aktionsklasse verwendet wird. Jede URL in der Webapplikation
entspricht daher stets einer eigenen Aktion.
Andere Webapplikationen verwenden für die jeweiligen Interaktionen zum Teil
verschiedene Skripts bzw. Servlets (im Fall von Java). Die URL besteht meist aus
dem Servlet-Mapping und einigen Parametern (vgl. Java, [SSJ02]). Bei DaVinci
besteht die URL aus dem sogenannten Action-Mapping und den entsprechenden Parametern, welche in der Aktionsklasse zuvor definiert werden (siehe Abschnitt 4.2.2).
Alle möglichen Parameter für eine Interaktion werden damit strikt vordefiniert.
49
KAPITEL 4. FRAMEWORK FÜR WEBAPPLIKATIONEN
View
Generator
Model
Manager
generate view change scenegraph
get model
native conn
50
Storage
Bridge
create/update/delete
load
Applikationslogik
execute action
close
Console
Front
Controller
Repository
Manager
open
execute command
Administrator
request action
WWW-Benutzer
Abbildung 4.1: Framework-Architektur, Komponenten.
4.1.1
Komponenten
Die Architektur des Frameworks basiert auf den Überlegungen aus Abschnitt 3.4.2.
Die Benutzerinteraktion kann auf einer abstrakten Ebene nach Abbildung 3.14 (Seite
42) veranschaulicht werden. Das System besteht aus folgenden Komponenten, welche
auch in Abbildung 4.1 anhand eines UML-Komponentendiagramms dargestellt sind:
Controller: Der controller ist die zentrale Schnittstelle der Benutzerinteraktion im
MVC Model 2 (siehe Abschnitt 3.4.3). Hier werden alle HTTP-Anfragen platziert. Da der controller an vorderster Front der Anwendung sitzt, wird er in
diesem Zusammenhang auch als FrontController bezeichnet. Er führt die entsprechende Aktion in der Applikationslogik aus und beauftragt anschließend
den ViewGenerator mit der Generierung der aktuellen Benutzeroberfläche (zumeist eine HTML-Seite).
Applikationslogik: Die Applikationslogik besteht aus den Objekten der Applikation (business objects) und diversen weiteren Klassen und Paketen. Sie ermöglicht durch die Verwendung von speziellen model-Klassen (siehe Abschnitt
4.3.1), welche persistent in der Session gespeichert werden, den für eine Webapplikation erforderlichen Applikationsstatus (business state). Models können
vom ModelManager angefordert werden. Der View-Baum kann beispielsweise
von Aktionen aber auch von anderen Objekten der Applikationslogik geändert
werden. Es können außerdem native Datenbankverbindungen über die StorageBridge hergestellt werden.
ModelManager: Der ModelManager verwaltet bei DaVinci alle persistenten modelObjekte. Diese werden zu Beginn der Session angelegt und bei jedem weiteren
51
Request automatisch re-initialisiert. Über eine öffentliche Funktion kann die
Instanz eines bestimmten models retourniert werden.
RepositoryManager: Dieser Manager verwaltet repositories, welche Daten nach
einem relationalen Schema speichern können. Über die StorageBridge-Komponente als Datenbank-Abstraktionsschicht können an repositories relationale
Datenbanken angebunden werden. Zur Zeit wird nur MySQL unterstützt.
StorageBridge: Diese Komponente dient als Adapter zu verschiedenen Datenbanken. Sie verwendet intern einen Verbindungspool und stellt außerdem native
Datenbankverbindungen zur Verfügung (siehe Abschnitt 4.5.2).
ViewGenerator: Der ViewGenerator verwaltet den View-Baum (Szenegraphen,
siehe Abschnitt 3.4.2) und generiert die Ausgabe am Ende eines Requests.
Über öffentliche Methoden können Schalter geändert werden. Der ViewGenerator kann in bestimmten Fällen auch deaktiviert werden (beispielsweise wenn
Inhalte eines anderen MIME-Typs als HTML ausgegeben werden sollen).
Console: Es wäre auch möglich durch eine eigene Console als zusätzliche Benutzerschnittstelle zur Applikation diverse Aktionen auszuführen. Die Console ist in
der momentanen Version noch nicht implementiert, wird jedoch in Zukunft von
Bedeutung sein, um beispielsweise neue repositories erstellen zu können (siehe
Erweiterungen, Abschnitt 7.1.3).
In den folgenden Abschnitten werden diese Komponenten näher erklärt. Die
Abschnitte wurden in die Aufgabengebiete Benutzerinteraktion, Applikationslogik,
Darstellung und Datenhaltung gegliedert.
Anhang A enthält zusätzliche Erklärungen des DaVinci Frameworks zum besseren Verständnis. Es werden die Verzeichnisstruktur der Distribution, die wichtigsten
Umgebungsvariablen, die Konfiguration des Frameworks und neuer Webapplikationen und die DaVinci-eigenen Datentypen beschrieben.
4.2
Benutzerinteraktion
Das Framework basiert auf dem MVC Model 2 Konzept. Alle Anfragen, die bei
einer DaVinci -basierten Webapplikation eingehen, werden über ein zentrales Script,
dem FrontController abgewickelt. Jede Interaktion wird durch eine eigene URL
repräsentiert, wobei für jede URL eine Aktionsklasse existiert.
4.2.1
FrontController
Der FrontController dient als Schnittstelle zum Browser. Eine HTTP-Anfrage stößt
vorerst auf ein Skript (index.php) welches als einzige Datei globalen PHP-Code enthält. Dieser Code ist notwendig, da PHP nicht von Grund auf objektorientiert ist
und es keine Hauptklasse gibt, mit der die Ausführung des Skript beginnt. Innerhalb
des Index-Skripts wird der FrontController initialisiert und gestartet. Der FrontController wird von der Klasse DaVinci implementiert. Die Klasse dient nicht nur als
FrontController, sondern enthält auch einige wichtige Funktionen, die das Framework
52
Abbildung 4.2: UML Klassendiagramm zur Benutzerinteraktion.
Abbildung 4.3: UML Sequenzdiagramm zur Benutzerinteraktion.
insgesamt betreffen. So beispielsweise Funktionen zur Initialisierung des Frameworks
bei einer neuen Anfrage, zur Fehlerbehandlung und zum Debugging.
Das Klassendiagramm in Abbildung 4.2 zeigt die an der Benutzerinteraktion beteiligten Klassen. Der zeitliche Ablauf einer Interaktion ist in Abbildung 4.3 als
Sequenzdiagramm dargestellt. Bevor die gewünschte Interaktion stattfindet, wird
das Framework für die Verarbeitung der neuen Anfrage re-initialisiert. Alle persistenten Objekte und die gesamte Applikationslogik werden in diesem Schritt neu
aufgebaut.
53
Initialisierung des Frameworks
Die Funktion DaVinci:: init () bereitet zu Beginn eines neuen Requests alle benötigten Ressourcen für die Webapplikation vor. Der Ablauf sieht so aus, dass zuerst
allgemeine Konfigurationswerte eingelesen werden. Anschließend werden alle benötigten Singleton-Klassen instanziert. Darunter fallen sämtliche Manager-Klassen,
welche z. B. persistente Objekte verwalten, und die Klasse StorageBridge. Die StorageBridge dient als Brücke von den repositories zur jeweiligen Datenbank. Sie übernimmt die korrekte Übernahme aller Daten, legt Tabellen an und löscht diese (siehe
Abschnitt 4.5.2).
Wird nun erstmals mit dem Webbrowser auf den Applikationsserver zugegriffen,
wird eine neue Session generiert. Ansonsten wird die aktuelle Session wiederverwendet. Nun können alle persistenten Objekte, welche der aktuellen Session angehören
re-initialisiert werden.
Ausführen des Requests
Nach der Initialisierung wird mit dem Aufruf von DaVinci::service () (innerhalb des
Skripts index.php) die eigentliche Requestbehandlung gestartet und die gewünschte
Interaktion kann durchgeführt werden. Die Funktion besteht aus zwei Schritten. Im
ersten Schritt wird, falls nötig, die im Request angegebene Aktion ausgeführt und im
zweiten Schritt wird die Folgeseite generiert, welche an den Browser zurückgegeben
wird (siehe Abschnitt 4.4).
Aktionen werden durch jene HTTP-Requests angestoßen, welche in der URL
nach dem Dateinamen des FrontController-Scripts eine Aktion spezifizieren (action
mapping). Wird keine Aktion angegeben, wird bloß die Anzeige neu generiert. Die
Abbildung von URLs auf Aktionen funktioniert im Detail wie folgt.
4.2.2
Abbildung von URLs auf Aktionsklassen
Eine HTTP-URL hat laut RFC2616 [FGM+ 99, Abschnitt 3.2.2] die allgemeine Form:
"http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
Sie referenziert somit ein eindeutiges Hypertextdokument im World Wide Web.
Da jedoch bei Verwendung der MVC Model 2 Strategie alle Requests zum selben
Dokument zeigen, muss man die zusätzliche Information, welches Dokument angefordert werden soll, beispielsweise per Query-String (jener Teil der URL nach dem
„?“) übergeben. Da jedoch viele Suchmaschinen den Query-String ignorieren, würde
eine Indizierung der Website nicht möglich sein, weil der Robot der Suchmaschine
nach dem Durchsuchen der Startseite (das FrontController-Script) abbrechen würde.
Abbhilfe schafft hier die Verwendung der sogenannten Pfadinfo (eng. pathinfo).
Wird nach dem Dokument in der URL noch ein weiterer Pfad angegeben, wird dieser
von den meisten Webservern (u.a. von Apache) ausgelesen und als Umgebungsvariable zur Verfügung gestellt. Am Beispiel der URL http://phpdavinci.sf.net/davinci.
php/show.Content ist die Pfadinfo durch die Zeichenkette „show.Content“ gegeben.
Die allgemeine Notation der Zeichenkette abs_path aus obiger Definition wäre genauer ausgedrückt, folgende:
abs_path = directory_path "/" file_name "/" path_info
54
Nun werden bei DaVinci anstatt einzelner Dokumente vielmehr Aktionen mit
URLs referenziert. Das bedeutet etwa, dass eine bestimmte Webseite nicht über eine
URL wie zum Beispiel http://phpdavinci.sf.net/showuserdetails.php?uid=34 sondern
etwa über die URL http://phpdavinci.sf.net/davinci.php/users.ShowDetails/34 referenziert wird. Die Pfadinfo liefert in diesem Beispiel den Wert „users.ShowDetails/34“
und enthält vor dem „/“ den Verweis auf die auszuführende Aktion. Die URL verweist also auf die Aktion „users.ShowDetails“. Für diese Aktion muss eine zugehörige
action-Klasse vorhanden sein. Anschließend sind alle für die Aktion benötigten Parameter mit weiteren Schrägstrichen getrennt zu finden.
Der Wert „users.ShowDetails“ wird im DaVinci Framework auch als action mapping bezeichnet. Jede Aktion wird durch einen eindeutigen Pfad im System referenziert. Alle Parameter, welche auf das action mapping folgen, werden vorher in der
Aktionsklasse definiert (siehe Abschnitt 4.2.4). Jede Aktion verlangt also, ähnlich
wie eine PHP-Funktion, bestimmte Parameter.
4.2.3
Die Klasse ActionManager
Jede Interaktion mit dem DaVinci Framework erfolgt über eine zugehörige Aktionsklasse. Jede Aktionsklasse besitzt eine Funktion namens execute (), welche den
auszuführenden Code enthält. Die Aktionsklassen sind dabei in einer Verzeichnishierarchie ähnlich den packages bei Java organisiert (siehe Abschnitt 4.2.4). Die
Klasse ActionManager verwaltet als statische Singleton-Klasse alle Aktionen. Sie erstellt bei Bedarf Instanzen von Aktionsklassen und führt außerdem alle Parameter,
welche mit POST oder über die Pfadinfo mitgesendet wurden, in die Instanz der
Aktionsklasse über.
Bei DaVinci werden im Übrigen alle Klassen, die zur Verwaltung von anderen Instanzen dienen, als Manager-Klassen bezeichnet. Dazu gehören neben dem
Action-Manager auch noch der Model-Manager, der Component-Manager und der
Repository-Manager.
4.2.4
DaVinci Aktionsklassen
Aktionsklassen werden vom Entwickler für jede einzelne Interaktion erstellt. Eine
Aktionsklasse muss von der abstrakten Klasse AbstractAction abgeleitet werden. Im
Konstruktor der Aktionsklasse können ihre erforderlichen Pfadinfo-Parameter definiert werden. Jede Aktionsklasse implementiert in der Funktion execute () den Programmcode, der ausgeführt werden soll. Am Ende dieser Funktion muss ein boolscher
Wert, der den Erfolgsstatus angibt, zurückgegeben werden. Die Aktionsklasse erbt
als Instanzvariable ein assoziatives Array namens $parameters, indem später bei der
Ausführung der Aktion alle benötigten Pfadinfo- und POST-Parameter enthalten
sind. Quellcode 4.1 zeigt eine beispielhafte Aktionsklasse.
In dem Beispiel gibt es ein model, welches unter anderem die aktuelle Seite eines angebundenen Content-Moduls speichert. Die Aktion definiert im Konstruktor
den Pfadinfo-Parameter page_id, welcher der ID der aktuellen Seite entspricht. Wird
hier die URL http://intrante.mycompany.org/davinci.php/content.ShowPage/17 aufgerufen, so wird im Content-model die aktuelle Seiten-ID auf 17 gesetzt. Anschließend
wird mittels ViewGenerator::setSwitch() jener View-Knoten, welcher den Content
anzeigt aktiviert (siehe Abschnitt 4.4).
55
c l a s s ShowPage e x t e n d s A b s t r a c t A c t i o n {
f u n c t i o n ShowPage ( ) {
$ t h i s −>_addPathParamDef ( ' page_id ' , DATATYPE_INTEGER) ;
}
function execute () {
i f ( $ t h i s −>p a r a m e t e r s [ ' h a n d l e ' ] ! = n u l l ) {
$model =& ModelManager : : getModel ( ' c o n t e n t . Content ' ) ;
$model−>changePage ( $ t h i s −>p a r a m e t e r s [ ' page_id ' ] ) ;
}
ViewGenerator : : s e t S w i t c h ( ' mainframe . page_body ' , ' c o n t e n t ' ) ;
r e t u r n true ;
}
}
Quellcode 4.1: Beispiel einer Aktionsklasse.
Parameterdefinitionen im Konstruktor
Um in einer Aktionsklasse Parameterdefinitionen anzugeben, stehen innerhalb der
Klasse zwei private Funktionen zur Verfügung: „_addPathParamDef()“ und „_addParamDef()“. Mit der ersten Funktion werden Pfadinfo-Parameter definiert und mit
der zweiten POST-Parameter. Die Besonderheit bei der Verwendung von PfadinfoParametern ist, dass in der Pfadinfo keine Variablenbezeichnung enthalten ist. Die
Parameter werden in der Pfadinfo stets in jener Abfolge angenommen, wie sie im
Konstruktor der Aktionsklasse definiert wurden.
Ein Aufruf mit dem action mapping „show.Content/34/de/compact“ enthält in
der Pfadinfo drei Parameter: „34“, „de“ und „compact“. Mit der zugehörigen Parameterdefinition ist die Bedeutung der Parameterfolge eindeutig:
$ t h i s −>_addPathParamDef ( ' page_id ' , DATATYPE_INTEGER) ;
$ t h i s −>_addPathParamDef ( ' l a n g u a g e ' , DATATYPE_VARCHAR, ' de ' ) ;
$ t h i s −>_addPathParamDef ( ' l a y o u t ' , DATATYPE_VARCHAR, ' f u l l ' ) ;
Die Definitionsfunktionen erfordern drei Funktionsparamter: einen Schlüssel, den
Datentyp und wahlweise einen Standardwert für den Parameter. DaVinci verwendet eigene Datentypen, welche die korrekte Konvertierung von Werten aus HTMLFormularen und aus den verschiedenen Datenbanken sicherstellen (siehe Anhang
A.4).
In der execute ()-Funktion sind über das assoziative Array $parameters laut obigem Beispiel die Werte der Schlüssel page_id, language und layout verfügbar. Auch
alle POST-Parameter, welche gleichermaßen mit der Funktion _addParamDef() definiert wurden sind im selben Array verfügbar. Die Zusammenführung aller Parameter,
egal ob Pfadinfo oder POST-Parameter in ein und dasselbe Array hat den Vorteil,
dass Doppeldefinitionen nicht möglich sind. Denn in der Regel sollte ein Wert entweder per Pfadinfo oder per POST-Parameter übergeben werden. Im Zweifelsfall wird
der Wert des POST-Parameters in das Array geschrieben.
56
Funktion execute()
Die execute ()-Funktion enthält in den meisten Fällen den gesamten Quellcode der
Aktionsklasse. Es können allerdings auch weitere private Hilfsfunktionen erstellt
werden, welche in weiterer Folge von der execute ()-Funktion aufgerufen werden. Die
execute ()-Funktion ist jedoch stets der Einstiegspunkt der Aktionsklasse, die diese
Funktion innerhalb von DaVinci::executeAction() aufgerufen wird.
Der Spielraum, den man in Aktionsklassen hat ist groß. So können etwa models
und registrierte repositories angesprochen werden, neue repositories erstellt werden
oder etwa der View-Baum (siehe Abschnitt 4.4.1) verändert werden. Grundsätzlich
sollte aber die Applikationslogik innerhalb von models implementiert werden. Aktionsklassen dienen primär der Schnittstelle zwischen den MVC-Schichten controler
und model.
Content kann fallweise auch direkt, ohne Verwendung des View-Generators ausgegeben werden. Das Ausschalten des View-Generators ist vor allem bei der Generierung von Bildern und Ausgabeformaten mit einem anderen MIME-Typ als HTML,
von Bedeutung.
Möglichkeiten von Aktionsklassen
Im Folgenden sollen einige Möglichkeiten die sich für Aktionsklassen anbieten, beispielhaft behandelt werden. All diese Möglichkeiten gelten prinzipiell für alle Klassen
im Framework und sind im Speziellen auch für models von Bedeutung. Alle öffentlichen Manager-Funktionen wurden als statische (static) Funktionen implementiert
und können von jeder Klasse aus aufgerufen werden (vgl. Operator „::“, [The03a, Kap.
14]).
Anbindung von registrierten repositories: Der Repository-Manager stellt unter anderem Funktionen zum Öffnen und Schließen registrierter repositories
zur Verfügung (siehe Abschnitt 4.5.1. Registrierte repositories sind dem Framework bekannt und können so über einen einfachen Bezeichner angesprochen
werden. Die Funktion RepositoryManager::open() gibt zu einem bestimmten
Bezeichner die Instanz des entsprechenden repositories zurück. Anschließend
können alle öffentlichen Funktionen der repository-Klasse verwendet werden.
temporäre repositories: Repositories können auch temporär verwendet werden.
Sie können neu erstellt werden, in ein model abgelegt werden und zu einem
späteren Zeitpunkt wieder gelöscht werden. Der Unterschied liegt darin, dass
das repository nicht dauerhaft gespeichert wird. Der Warenkorb bei einem
Shop-System wäre etwa ein Beispiel für ein solches repository. Eine API zum
Arbeiten mit repositories ist im Anhang A.5 zu finden.
Anbindung von models: Sehr ähnlich funktioniert die Anbindung von models.
Mit der Funktion ModelManager::getModel() kann eine Referenz der zugehörigen model-Instanz geholt werden. Als Parameter muss die mapping des models
angegeben werden.
Verändern des View-Baums: Mit den öffentlichen Funktionen die der View-Generator bereitstellt, kann der Ausgabe-Baum verändert werden. Mittels ViewGenerator
::setSwitch() können Teilbäume umgeschaltet werden. Falls mehrere View-
57
Bäume definiert wurden, kann mit ViewGenerator::setViewTree() der aktuelle View-Baum gesetzt werden. Die Funktion ViewGenerator::disableOutput()
schaltet, wie der Name bereits verrät, die Generierung von views gänzlich aus.
Die Funktionen sind im Detail im Abschnitt 4.4.4 beschrieben.
Ausgabe von Content: Normalerweise wird in einer Aktionsklasse kein Content
ausgegeben. Der Content wird erst später vom View-Generator erzeugt. Zur
Generierung von binärem Content (z.B. Bilder) oder XML-Dokumenten (z.B.
SOAP) kann der View-Generator deaktiviert werden, und Content kann direkt
in der Aktion ausgegeben werden. Mittels der PHP-Funktion header() sollte
vor der Ausgabe jedoch der richtige MIMI-Typ festgelegt werden.
Gliederung der Aktionsklassen
Alle Aktionen, die im Framework zur Verfügung stehen, werden mit einem eindeutigen action mapping spezifiziert. Dieser String ist ähnlich wie die Klassenpakete
bei Java aufgebaut. Die Gliederung aller Aktionsklassen in Unterverzeichnisse hat
mehrere Vorteile. Zum einen erleichtert dies den Überblick und zum anderen kann
sich später eine Rechteverwaltung an dieser hierarchischen Struktur orientieren. Das
action mapping sieht im Allgemeinen Fall folgendermaßen aus:
directory.sub-directory.[sub-sub...].ClassName
Die zu diesem action mapping gehörende Aktionsklasse muss nun im Verzeichnis
„directory/sub-directory/[sub-sub...]“ liegen. Der Dateiname muss gleich lauten wie
die Klasse und auf „.class“ enden („ClassName.class“).
4.2.5
Rechteverwaltung
In der Regel wird eine Webapplikation von mehreren Benutzern verwendet. Eine
Rechteverwaltung ermöglicht für unterschiedliche Benutzergruppen, bestimmte Aktionen zu erlauben und andere zu sperren. Durch die Verwendung der MVC Model 2
Architektur mit einem zentralen FrontController ist die Rechteverwaltung relativ einfach zu implementieren. Der FrontController muss vor Ausführung einer Aktion die
Authorisierung des Benutzers überprüfen. Ist der Benutzer nicht authorisiert, wird
entweder eine Fehlermeldung ausgegeben oder der Benutzer kann sich authorisieren.
Eine Rechteverwaltung wurde zur Zeit noch nicht implementiert.
4.3
Applikationslogik
Die Applikationslogik besteht aus verschiedensten Klassen und besitzt als Schnittstelle zur Benutzerinteraktion auch einige Aktionsklassen. Abbildung 4.4 zeigt ein
Klassendiagramm jenes Teils der Applikationslogik, der Aktionsklassen und models
betrifft. In der Mitte ist eine Aktionsklasse dargestellt, welche in ihrer execute ()
-Funktion Zugriff auf sämtliche Komponenten hat. Die restliche Applikationslogik
kann mit beliebigen eigenen Klassen realisiert werden. Für spezielle model- und
action-Klassen wurden die Stereotypen action und model eingeführt:
Model-Klassen sind persistent und werden vom ModelManager innerhalb der Session verwaltet. Sie besitzen bestimmte Parameter, implementieren in der
58
Abbildung 4.4: Aktionsklassen und models im Klassendiagramm.
Regel eine interne Logik und stellen nach außen hin öffentliche Methoden
zur Verfügung. Diese Methoden können beispielsweise von actions aufgerufen werden. Ein Warenkorb etwa bietet Funktionen an, wie addToCart() und
removeFromCart(). Wie die interne Logik im model des Warenkorbs aussieht
ist jedoch egal. Das model Warenkorb wird höchstwahrscheinlich intern ein
repository verwalten, indem die Produkte gespeichert sind. Dieses repository
ist aber letztlich nur für den Warenkorb relevant und nach außen hin nicht
sichtbar.
Aktionsklassen oder einfach actions dienen als Schnittstellen zwischen Browser
und Server. Jede URL verweist auf eine eigene Aktionsklasse (siehe Abschnitt
4.2). Diese Klassen zählen u. a. auch zur Applikationslogik. Sie sollten jedoch
möglichst wenig Code selbst implementieren. Typischer Code in Aktionsklassen betrifft die Modifizierung des View-Baumes, etwa für eine Interaktion zur
Navigation. Der Großteil der Applikationslogik wird mittels models und beliebigen weiteren Klassen realisiert.
Für alle Klassen der Applikationslogik gelten die im vorigen Abschnitt für Aktionen beschriebenen Möglichkeiten (Abschnitt 4.2.4). Es können also repositories
verwendet werden, alle models angesprochen werden und der View-Baum verändert
werden.
Vorraussetzung für die Persistenz von models ist die Session-Behandlung. Die
von PHP4 zur Verfügung stehenden Routinen zur Behandlung von Sessions wurden
weitgehend verwendet und in eine eigene Klasse namens Session gekapselt. Diese
statische Klasse dient zum Initialiseren und Wiederverwenden einer bereits vorhandenen Session.
59
<?php
c l a s s Content e x t e n d s AbstractModel {
var $pageID ;
f u n c t i o n Content ( ) {
$ t h i s −>pageID = 1 ;
}
function r e q u e s t I n i t () {}
f u n c t i o n changePage ( $pageID ) {
$ t h i s −>pageID = $pageID ;
}
f u n c t i o n getViewData ( $ v i e w I d ) {
$ r e p =& RepositoryManager : : open ( ' c o n t e n t ' ) ;
$numRows = $rep−>loadWhere ( " h a n d l e ␣LIKE␣ ' $ t h i s −>pageID ' " ) ;
i f ( $numRows == 0) trigger_error ( " Content ␣ model : ␣ page ␣ not ␣ found
.",
E_USER_ERROR) ;
r e t u r n $rep−>getWhere ( ' h a n d l e ' , $ t h i s −>pageID ) ;
}
}
?>
Quellcode 4.2: Beispiel einer model -Klasse.
4.3.1
DaVinci Model-Klassen
Ein model wird durch eine Klasse, welche von der abstrakten Klasse AbstractModel
abgeleitet werden muss, implementiert. Quellcode 4.2 definiert eine beispielhafte
model-Klasse. Das Beispiel zeigt ein Content-model, welches ein repository anbindet,
indem einfache Textseiten gespeichert sind. Die ID der aktuellen Seite ist im model
als Parameter gespeichert und kann über die Funktion changePage() etwa von einer
Aktion geändert werden.
Persistenz von models
Beim ersten Request, wird die Session initialisiert und alle definierten models werden
instanziert. Für die Dauer der Session sind die model-Instanzen anschließend immer verfügbar. Eine Referenz kann stets über den ModelManager über die Funktion
getModel() zurückgeholt werden. Models sollten stets einen Konstruktor definieren
und müssen die Funktion requestInit () bereitstellen. Während der Re-initialisierung
der Folge-Requests wird in allen models die Funktion requestInit () aufgerufen. In
dieser Funktion können beispielsweise bestimmte, für den Request benötigte Ressourcen, neu aufgebaut werden.
60
Bereitstellen von Daten für views
Eine zusätzliche Aufgabe der models ist, Daten für die Generierung der Ausgabe
bereitszustellen. Im View-Baum kann für jedes view-Objekt ein zugehöriges model
definiert werden, welches die entsprechenden Daten liefert (siehe Abschnitt 4.4.2).
Die abstrakte Funktion getViewData() wird vom Framework vor dem Parsen des
jeweiligen view-Knoten aufgerufen und liefert die geforderten Daten für das aktuelle
view-Script. Im view-Skript sind die Daten anschließend im Array $data verfügbar.
Models können, aber müssen nicht unbedingt als Daten-Lieferant dienen. Andererseits können theoretisch auch models definiert werden, deren Aufgabe ausschließlich die Bereitstellung von Daten für views ist. Es kann auch ein und dasselbe model
als Daten-Lieferant für mehrere unterschiedliche views verwendet werden.
Oberserver Pattern
Um den Status zwischen models synchronisieren zu können, wurde der Observer
Pattern eingeführt [Gam94]. Jedes model erweitert die Klasse ObservableListener.
Es ist somit observierbar und kann auch selbst andere models „beobachten“. Mit der
Funktion notifyAll () kann eine Nachricht an alle registrierten Beobachter gesendet
werden. Ein model kann die Referenz eines anderen models mittels ModelManager::
getModel() erhalten und sich anschließend mit der Funktion registerListener () dort
als Listener registrieren. Es bleibt zu beachten, dass dieses model in Folge auch
die Funktion receiveMessage() implementieren muss. Diese Funktion wird von der
observierten Klasse beim Aufruf von notifyAll () aufgerufen und liefert die gesendete
Nachricht.
4.4
Darstellung von Inhalten
Der sogenannte View-Baum ist das Herzstück der Benutzeroberfläche. In einer Art
Szenegraph werden alle Ansichten bereits vordefiniert, die im Verlauf der Applikation
dargestellt werden können. Die Generierung der grafischen Oberfläche, also der Seite
im Browser, erfolgt am Ende einer jeden HTTP-Anfrage. Inhalt und Applikationslogik sind völlig voneinander getrennt. Erst wenn die Aktion – falls überhaupt eine
angegeben wurde (auch eine einfache Aktualisierung der Ansicht ist somit möglich)
– ausgeführt worden ist, wird die Ansicht neu generiert und an den Browser zurückgegeben. Im Normalfall wird als Ausgabeformat HTML bzw. XHMTL verwendet.
Es ist jedoch jedes XML-basierte Format ohne Weiteres möglich. In weiterer Zukunft soll das Framework die Verwendung von XSLT zur gleichzeitigen Generierung
verschiedener Ausgabeformate ermöglichen.
4.4.1
Szenegraph-Modell und View-Bäume
Das Szenegraphen-Modell wurde bei DaVinci in Form eines XML-basierten, sogenannten View-Baumes implementiert. Ein solcher View-Baum wird in der Konfigurationsdatei der Webapplikation definiert (usr/webapp/webapp.xml, siehe Anhang
A.3.2). An den Knotenpunkten des Baumes (nodes) können entweder sogenannte
View-Skripts, welche für die Darstellung verantwortlich sind (vgl. JSP-Seiten im
61
MVC Model 2), oder Schalter (switches) spezifiziert werden, welche das Umschalten zwischen mehreren Unterbäumen ermöglichen. Jeder Knoten erhält über seinen
hierarchischen Pfad eine eindeutige ID, mit der er später angesprochen werden kann.
Schalter dienen zum Umschalten ganzer Teilbäume. Es ist somit möglich, in
einem bestimmten Bereich der Benutzeroberfläche Ansichten zu wechseln. Bei einer
einfachen Homepage kann beispielsweise bei gleichbleibender Navigationsleiste im
oberen Bereich der Seite, der Inhalt im mittleren Bereich gewechselt werden. Schalter
können an jedem Knoten verwendet werden. Sie müssen mindestens ein weiteres
view-Element enthalten. Auch Schalter können untereinander verschachtelt werden.
Es können im Übrigen auch mehrere View-Bäume definiert werden. Der aktuelle
Baum kann im Verlauf der Applikation gewechselt werden. Dieses Feature wird
beispielsweise bei mehreren parallelen Browser-Fenstern und Framesets benötigt.
Zum besseren Verständnis ist in Abbildung 4.5 ein Biespiel für einen View-Baum
als UML-Klassendiagramm dargestellt. Quellcode 4.3 enthält die zugehörige XMLNotation. Abbildung 4.6 zeigt die entsprechende Benutzeroberfläche im Browser
mit allen Ansichten in ihrem Initialstatus. Das Beispiel bezieht sich auf die DemoApplikation aus Kapitel 5. Die Applikation dient als persönliche Startseite und bietet
neben einer Homepage, deren URL festgelegt werden kann, ein einfaches Adressbuch
und eine Link-Datenbank. Es wurde insofern vereinfacht, als dass der Baum in
seiner Tiefe etwas gekürzt wurde. Alle Knoten unterhalb von addressbook und links
wurden nicht mehr dargestellt. Zur Darstellung des Baumes wurde auf das UMLKlassendiagramm zurückgegriffen. Für die Knoten wurden die Stereotypen view-tree,
view und switch eingeführt.
UML-Notation des View-Baumes
Zur Notation von View-Bäumen können auch UML-Klassendiagramme verwendet
werden. Somit müssen keine neuen Diagrammtypen erfunden werden. Die automatische Generierung von Sourcecode macht in diesem Fall freilich wenig Sinn. Die
Klassen werden bei der Implementierung nicht zu konkreten PHP-Klassen. Es wäre
allerdings möglich, einen Generator zu schreiben, der anhand des Diagramms automatisch alle zugehörigen Aktionsklassen, models und Konfigurationsdateien erstellt.
Das Diagramm aus Abbildung 4.5 beinhaltet folgende Informationen:
View-Baum Hierarchie: Das Diagramm definiert die gesamte Hierarchie eines
View-Baumes. Da es durchaus Sinn macht, wenn alle Unterknoten die Eigenschaften ihrer Eltern erben, wurde die Notation für Vererbung (generalisation)
verwendet.
Knoten-Definitionen: Die privaten Parameter einer Klasse (z. B.file und model)
geben Konfigurationsparameter des Knotens an, welche in der XML-Spezifikation definiert werden. Sie konfigurieren den Knoten und geben z. B. die zugehörige view-Script Datei oder ein model an, welches die Daten für das Skript
liefert (siehe Abschnitt 4.4.2. Schalter haben einen öffentlichen Parameter currentView, welcher den aktuellen Unterbaum angibt.
View-Daten: Alle anderen öffentlichen Parameter geben Daten an, welche vom jeweiligen View zur Anzeige benötigt werden. Das können beispielsweise ganze
62
Abbildung 4.5: Beispiel eines View-Baumes. Das Beispiel bezieht sich auf die
Demo-Applikation aus Kapitel 5 und wurde etwas vereinfacht. Die Unterbäume der
Knoten addressbook und links wurden entfernt. Die XML-Notation in Quellcode 4.3
abgedruckt.
Datensätze von repositories oder auch einzelne Variable, wie etwa der Seitentitel im View header sein. Werden Daten im View benötigt, muss in der Definition des Knotens ein model angegeben werden, welches diese Daten liefert
(siehe Abschnitt 4.3.1).
Interaktionen: Interaktion findet bei DaVinci durch Aufruf von Aktionen über
ein action mapping in der URL statt (siehe Abschnitt 4.2.2). Interaktionselemente wie beispielsweise Links und Formularelemente werden über ViewKnoten bereitgestellt. Das zugehörige View-Skript enthält den entsprechenden
HTML-Code, welcher diese Elemente erzeugt. Die Interaktionselemente eines View-Knotens können im UML-Diagramm mit Hilfe von Methoden modelliert werden. Die Attribute definieren die für eine Aktion benötigten PfadinfoParameter.
63
<viewTree i d="main_window" default=" t r u e ">
<view i d=" mainframe " f i l e =" mainframe . php">
<view i d=" h e a d e r " f i l e =" h e a d e r . php" />
<view i d=" n a v i g a t i o n _ b a r " f i l e =" n a v i g a t i o n . php" />
<s w i t c h i d=" body " default=" homepage ">
<view i d=" homepage " f i l e =" homepage . php"
model=" L i n k s " />
<view i d=" a d d r e s s b o o k " f i l e =" s p l i t _ c a n v a s . php">
[...]
</ view>
<view i d=" l i n k s " f i l e =" s p l i t _ c a n v a s . php">
[...]
</ view>
</ s w i t c h>
<view i d=" f o o t e r " f i l e =" f o o t e r . php" />
</ view>
</ viewTree>
Quellcode 4.3: XML-Notation zum View-Baum aus Abb. 4.5.
<<view>> mainframe
<<view>> header (unsichtbar)
<<view>> navigation_bar
<<switch>> body
<<view>>
homepage
<<view>>
adressbook
<<view>>
links
<<view>> footer
Abbildung 4.6: Benutzeroberfläche zum View-Baum aus Abb. 4.5.
4.4.2
Daten für Views
Jedes View-Element kann bestimmte Daten der Applikation (mehr oder weniger
formatiert) darstellen. So bestehen einzelne Einträge (Datensätze) in einem NewsModul, welches Neuigkeiten anzeigt, beispielsweise aus einer Überschrift, einem kurzen Text und etwa dem Datum der Publikation. Diese Daten müssen dem ViewSkript zur Verfügung stehen, damit sie beim Generieren der Oberfläche eingefügt
werden können. Im UML-Diagramm aus Abbildung 4.5 wurden diese als öffentliche
Variablen der Knoten-Klassen notiert.
Im DaVinci-Framework werden derartige Daten von speziellen model-Objekten,
welche Teil der Applikationslogik sind, bereitgestellt. Bei der Definition des View-
64
Baumes kann daher für einen View-Knoten ein zugehöriges model definiert werden,
welches die Daten für das entsprechende View-Skript liefert.
4.4.3
View-Skripts
Jeder View-Knoten des Baumes verweist auf ein View-Skript, welches in der XMLKonfiguration angegeben werden muss. Ein solches Skript ist eine PHP-Datei und
enthält hauptsächlich (X)HTML-Code und einige PHP-Elemente. Eine grundsätzliche Festlegung bei der Entwicklung von DaVinci war, keine Templating- bzw. Metasprachen zu verwenden. Das heisst, dass jeglicher Code in View-Skripts (dazu
zählen etwa Schleifen, Abfragen und die Ausgabe von PHP-Variablen) aus nativen
PHP-Code besteht. PHP hat ohnehin eine einfache Syntax und ist leicht zu erlernen. Die im Baum definierten Sub-Knoten müssen im jeweiligen Skript positioniert
werden. Das heißt im View-Skript selbst wird an der richtigen Stelle der nächste
Knoten platziert, der an an dieser Position in der Oberfläche inkludiert wird. Dies
geschieht über den Aufruf der Funktion ViewGenerator::includeViewNode(), wobei
als Parameter die jeweilige ID des zu platzierenden Knotens angegeben wird. Es
spielt dabei keine Rolle, ob es sich beim einzufügenden Knoten um einen View- oder
um einen switch-Knoten handelt. Der Generator setzt die Traversierung des Baumes
automatisch beim platzierten Sub-Knoten fort.
4.4.4
Der View-Generator
Die Klasse ViewGenerator ist für die Generierung der Benutzeroberfläche verantwortlich. Der FrontController startet am Ende des Requests über den Aufruf von
ViewGenerator::generateView() die Ausgabe des View-Baumes. In dieser Funktion
wird der aktuell gewählte View-Baum traversiert. Stößt der Generator auf einen
View-Knoten, wird das entsprechende View-Skript inkludiert. Falls ein model als
Daten-Lieferant spezifiziert wurde, werden die Daten des models in eine spezielle
Variable ($data) geschrieben, welche anschließend im Wertebereich des View-Skripts
zur Verfügung steht.
Die folgenden Funktionen der Klasse stehen zur Verfügung:
setViewTree(): Die Funktion erfordert als Parameter die ID des View-Baumes
und setzt den aktuellen Baum. Über einen zweiten optionalen Parameter kann
angegeben werden, ob der Baum permanent oder nur für diesen Request umgeschaltet werden soll.
setSwitch(): Diese Funktion setzt den aktuellen View-Knoten eines Schalters. Als
Parameter werden der Pfad zum Schalter und die ID des Sub-Knotens benötigt.
Über einen optionalen dritten Parameter kann die ID des View-Baums angegeben werden, dessen Schalter gemeint ist. Standardmässig wird der aktuelle
Baum angenommen.
getSwitchState(): Die Funktion gibt die ID des aktuell gewählten View-Knotens
eines Schalters zurück.
disableOutput(): Diese Funktion dient zum Deaktivieren des View-Generators.
Wurde in der Aktion diese Funktion aufgerufen, wird keine Ausgabe erzeugt.
4.4.5
65
Unterschiedliche Ausgabeformate
Zur Zeit ist das Ausgabeformat auf XML-Formate begrenzt. Das Framework wurde
zur Zeit nur für die Ausgabe von HTML/XHTML und ähnlichen XML-Formaten
spezifiziert. Je nachdem, welcher Code von den View-Skripts generiert wird, können
zur Zeit verschiedene XML-basierte Dokumente erzeugt werden. Für die Ausgabe
von Bildern und binären Multimedia-Formaten kann in einer Aktion der Generator
deaktiviert werden und die (binären) Daten können direkt ausgegeben werden.
Eine Abstraktionsschicht über XSLT ist zur Zeit nicht implementiert. Durch die
Vielseitigkeit der XSLT-Ausgabe ist jedoch in weiterer Zukunft die Implementierung
eines XSL-Transformators für das DaVinci Framework angedacht.
4.5
Datenhaltung
Daten, deren gemeinsame Struktur in Form einer Entität (vgl. [Sau94, Kap. 1]) identifiziert werden kann, können in dafür vorgesehene repositories gespeichert werden.
Repositories können einerseits temporär für eine bestimmte Dauer während der Sitzung verwendet werden, die enthaltenen Daten können aber auch dauerhaft in einer
angebunden Datenbank gespeichert werden. Artikel in einem Warenkorb können,
da es sich um Einträge mit gleichartiger Datenstruktur handelt, beispielsweise als
Entität definiert und in ein repository abgelegt werden. Der Warenkorb muss jedoch
nicht in einer Datenbank abgespeichert werden, da er nur für die Dauer der Sitzung
relevant ist. Die getätigte Bestellung würde schließlich dauerhaft in ein repository
mit Datenbankanbindung gespeichert werden.
4.5.1
Repositories
Repositories sind vergleichbar mit Relationen einer relationalen Datenbank. Zur
Zeit gibt es allerdings noch keine Möglichkeit repositories bereits in ihrer Definition
untereinander zu verknüpfen. Auch die Angabe von sogenannten Check-Constraints
(siehe [Sau94, S. 76ff]) ist nicht möglich. Die referenzielle Integrität muss zur Zeit
noch über Programmcode überprüft werden. Die Implementierung im Rahmen dieser
Diplomarbeit hätte den zeitlichen Rahmen gesprengt.
Das Klassendiagramm in Abbildung 4.7 zeigt die an der Datenhaltung beteiligten
Klassen. Ausgegangen wird von einer beliebigen Aktion. Repositories können von
Aktionen sowie von models verwendet werden. Ein repository wird im einfachsten
Fall durch Instanzieren einer von AbstractRepository abgeleiteten Klasse erstellt. Die
Felder von einem repository werden über ein spezielles RepositoryLayout-Objekt definiert. Soll das repository auch von anderen Komponenten verwendet werden können,
kann es beim RepositoryManager registriert werden. Dieser Manager liefert dann
auf Aufrage eine Referenz auf das gewünschte repository zurück.
Es gibt zur Zeit zwei unterschiedliche Arten von repositories: Collections und
SimpleTrees. Eine Collection ist eine einfache flache Tabelle. Bäume sind selbstreferenzierende Tabellen, mit denen sich hierarchische Strukturen bilden lassen, wie etwa
eine Gliederung für Dokumente oder ein Navigationsbaum. Alle repository-Klassen
sind von der abstrakten Klasse „AbstractRepository“ abgeleitet. Die Unterklassen
erweitern die abstrakte Klasse durch spezifische Funktionen. So stellt die Klasse SimpleTree zum Beispiel Funktionen zum Traversieren des Baumes und zum Anknüpfen
66
Abbildung 4.7: Klassendiagramm zur Datenhaltung.
von Teilbäumen bereit.
Jedes repository erbt unter anderem folgende Parameter:
handle: Der Bezeichner von dem repository ist eine eindeutige Kennung. Er muss
beim Erstellen eines neuen repository im Konstruktur angegeben werden.
DSN: Der DSN-Parameter (data source name) dient zur Anbindung einer beliebigen
Datenbank im Hintergrund. Innerhalb einer Zeichenkette werden DBMS, Host,
Port, Benutzername, Passwort und die Datenbank definiert. Die Syntax des
DSN ist in Abschnitt A.5.1 spezifiziert. Der Wert kann über die öffentliche
Funktion setDSN() gesetzt werden.
layout: Dieser Parameter enthält eine Instanz der Klasse RepositoryLayout und
definiert alle Felder von einem repository. Das Layout kann über die öffentliche
Funktion setLayout() gesetzt werden.
67
Transparenter Primärschlüssel
Alle Datensätze eines repository werden über eine eindeutige ID (vom Typ Integer)
angesprochen, welche im Hintergrund auch als Primärschlüssel dient. Die Festlegung
auf einen fix definierten Primärschlüssel erleichtert die Handhabung der Daten für
das Framework. Es kann zur Zeit kein eigener Primärschlüssel definiert werden. Das
ID-Attribut trägt im Übrigen stets den Namen id. Wird ein neuer Eintrag angelegt,
wird vorerst vom Framework eine eindeutige Kennung vergeben. Wenn der Datensatz
in einer Datenbank gespeichert wurde, wird dem Eintrag die ID, welche von der
Datenbank vergeben wurde zugewiesen. Die automatische Durchnummerierung der
ID muss von der jeweiligen Datenbankklasse erfüllt werden (siehe Abschnitt 4.5.4).
MySQL stellt dieses feature beispielsweise bereits zur Verfügung. Bei Verwendung
von anderen Datenbanksystemen muss ggf. die Datenbankklasse beim Initialisieren
der Tabelle erforderliche Sequences und Triggers erstellen.
Repositories bieten zahlreiche Funktionen an. Grundsätzlich könnte man die
Funktionen in drei Kategorien einteilen. Es gibt Funktionen zur:
Erstellung von repositories: Sie dienen zum Erstellen und zum Setzen der notwendigen Parameter (wie etwa Layout und DSN). Dazu gehört der Konstruktor
und die Funktionen setLayout() und setDSN().
offline-Manipulation: Funktionen die zum Erstellen, Verändern und Löschen von
Datensätzen dienen, wenn keine Datenbank angegeben wurde. Dazu gehören
die Funktionen newRecord() und alle get -, walk - und delete -Funktionen.
DB-Manipulation: Diese Funktionen greifen über die StorageBridge auf die angebundene Datenbank zu. Zu dieser Kategorie zählen alle load -, unload -, save und delete -Funktionen. Die delete -Funktionen gehören beiden Kategorien der
Manipulationsfunktionen an. Sie entscheiden selbst, ob auch ein Datenbankeintrag gelöscht werden muss oder nicht. Außerdem gehören in diese Kategorie
auch noch die beiden Funktionen initTable () und dropTable().
Eine genauere Beschreibung der API für repositories ist im Anhang A.5 zu finden.
4.5.2
Die Klasse StorageBridge
Diese Klasse übernimmt alle Datenbank-Operationen für repositories. Die meisten
ihrer Funktionen werden von den repository-Klassen (CollectionRepository, etc.) intern angesprochen und sind für den Entwickler einer Webapplikationen nicht relevant.
Die Funktionen sind stets so aufgebaut, dass unter den erforderlichen Parametern
auch eine Referenz auf die repository-Instanz mitgegeben wird. Die Klasse StorageBridge baut intern eine entsprechende Datenbankverbindung auf, führt die Abfragen
und Operationen aus, gibt die Verbindung wieder frei und speichert oder löscht die
Einträge im repository, je nach Ergebnis der SQL-Abfrage.
Außerdem stellt die StorageBridge die beiden Funktionen getConnection() und
returnConnection() zur Verfügung. Fallweise sind native SQL-Abfragen unablässig.
In diesem Fall, kann über den Aufruf von StorageBridge::getConnection() eine Datenbankverbindung zu dem im Parameter als Referenz angegebenen repository hergestellt werden. Die Verbindung ist eine Instanz der jeweiligen Datenbank-Klasse,
68
welche von der Klasse AbstractConnection abgeleitet wurde. Es ist notwendig, die
Verbindung nach Verwendung über die Funktion returnConnection() wieder zurückzugeben, da sie ansonsten nicht neu vergeben werden kann.
4.5.3
Verwaltung der Datenbankverbindungen
Da bei PHP alle Ressourcen bei jedem Request neu aufgebaut werden müssen, sind
keine persistenten Datenbankverbindungen möglich. Die Verwendung von persistenten Verbindungen, wie sie beispeilsweise mit MySQL möglich sind1 , stellen keine
professionelle Lösung für das Manko dar, da die Verbindungen nicht direkt kontrolliert werden. Außerdem gibt es für viele andere DBMS das feature garnicht.
Es ist jedoch sinnvoll, auch während eines Requests Datenbankverbindungen wieder zu verwenden. Wird die Verbindung nach der Benützung stets wieder freigegeben
und weiterverwendet, ist theoretisch pro Datenbank (DSN) nur ein Verbindungsaufbau notwendig. In der Regel stellt der Aufbau einer neuen Verbindung den größten
Engpass dar. Somit kann man hier Zeit einsparen.
Im DaVinci Framework werden alle Verbindungen über die Klasse ConnectionPool aufgebaut. Der Pool baut bei Bedarf transparent und dynamisch neue Verbindungen auf und gibt diese frei. Falls bereits eine Verbindung zur gleichen Datenbank
(beziehungsweise zum gleichen data source name, DSN) besteht, wird diese wiederverwendet. Am Ende des Requests schließt der Pool alle offenen Datenbankverbindungen.
Ein weiterer Vorteil des Pools ist, dass die maximale Anzahl an Verbindungen zu
einer Datenbank bereits im Framework begrenzt werden kann. So kann es zu keinem
Überlauf oder Absturz kommen, der durch zu viele Verbindungsanfragen verursacht
wurde. Ein DBMS sollte jedoch ohnehin selbst Sicherheitsfunktionen bereitsstellen,
die einen solchen Absturz verhindern.
4.5.4
Datenbankabstraktion
Um mehrere unterschiedliche Datenbanken unterstützen zu können, muss für jedes
DBMS eine eigene Datenbankklasse implementiert werden. Zur Zeit gibt es nur eine
Klasse für MySQL (MysqlConnection). Alle Datenbankklassen werden von der abstrakten Klasse AbstractConnection abgeleitet. In dieser Klasse sind alle Funktionen
vorgegeben, die implementiert werden müssen. Beim Anfordern einer Datenbankverbindung über die Klasse ConnectionPool, muss ein data source name (DSN) angegeben werden. Entsprechend des enthaltenen DBMS-Parameters, wird die korrekte
Datenbankklasse instanziert und zurückgegeben.
1
Siehe mysql_pconnect(), [The03a, Abschnitt LXIII.].
Kapitel 5
DaVinci in der Praxis
In diesem Kapitel wird das Framework anhand einer kleinen Webapplikation demonstriert. Die dargestellte Beispielapplikation ist auf der beiliegenden CD-ROM im
Verzeichnis phpdavinci/usr/ zu finden. Als Beispiel wurde eine „persönliche Startseite“ mit Adressbuch und Link-Datenbank realisiert. Die realtiv einfache Applikation zeigt die Anwendung der wichtigsten Komponenten von DaVinci.
5.1
Anforderung
Als Beispielapplikation soll eine „persönliche Startseite“ entwickelt werden. Die Applikation kann im Browser als Startseite konfiguriert werden und soll als persönliches
Portal dienen. Die Applikation soll aus drei Modulen bestehen. Das erste Modul
soll eine beliebig definierbare Startseite anzeigen (z.B. Google als Suchmaschine).
Die beiden anderen Module sollen die Verwaltung persönlicher Links und Adressen
erlauben. Wurde bei einem Adress-Eintrag eine E-Mailadresse angegeben, soll an die
Person eine E-Mail gesendet werden können. Die Organisation aller Einträge soll in
Form eines Baumes möglich sein.
5.2
Modellierung einer Webapplikation mit DaVinci
Natürlich gibt es mehrere Wege, wie man Webapplikationen mit dem DaVinci Framework entwickeln kann. Die hier dargestellte Vorgehensweise sei eine Möglichkeit
dafür und richtet sich nach dem Konzept aus Abschnitt 3.4.4. Auf den groben,
funktionellen Entwurf wurde jedoch verzichtet, da die Anwendung relativ kompakt
ist und die Anforderungen bereits im Detail definiert wurden. Ausgehend von der
Benutzeroberfläche und den erforderlichen Ansichten, werden die nötigen Aktionen,
repositories und models spezifiziert. Zum Schluss erfolgt die eigentliche Implementierung der Klassen und View-Skripts.
Der Quellcode wurde in diesem Dokument nicht abgedruckt und ist auf der beiliegenden CD-ROM im Ordner phpdavinci/usr/ zu finden. Die Beschreibung in diesem
Kapitel möge als untersützende Ergänzung zum Verständnis des vorliegenden Quellcodes dienen.
69
KAPITEL 5. DAVINCI IN DER PRAXIS
70
<viewTree i d="main_window" default=" t r u e ">
<view i d=" mainframe " f i l e =" mainframe . php">
<view i d=" h e a d e r " f i l e =" h e a d e r . php" />
<view i d=" n a v i g a t i o n _ b a r " f i l e =" n a v i g a t i o n . php" />
<s w i t c h i d=" body " default=" homepage ">
<view i d=" homepage " f i l e =" homepage . php" model=" L i n k s "
<view i d=" a d d r e s s b o o k " f i l e =" s p l i t _ c a n v a s . php">
<view i d=" t r e e " f i l e =" a d d r e s s b o o k / t r e e . php"
model=" Addressbook " />
<s w i t c h i d=" r i g h t _ c a n v a s " default=" f o l d e r ">
<view i d=" f o l d e r " f i l e =" a d d r e s s b o o k / f o l d e r . php"
<view i d=" r e c o r d " f i l e =" a d d r e s s b o o k / r e c o r d . php"
<view i d=" e d i t _ f o l d e r " f i l e =" a d d r e s s b o o k /
e d i t _ f o l d e r . php"
<view i d=" e d i t _ r e c o r d " f i l e =" a d d r e s s b o o k /
e d i t _ r e c o r d . php"
<view i d=" m a ilf o rm " f i l e =" a d d r e s s b o o k / m a ilf o rm . php"
</ s w i t c h>
</ view>
<view i d=" l i n k s " f i l e =" s p l i t _ c a n v a s . php">
<view i d=" t r e e " f i l e =" l i n k s / t r e e . php" model=" L i n k s " />
<s w i t c h i d=" r i g h t _ c a n v a s " default=" f o l d e r ">
<view i d=" f o l d e r " f i l e =" l i n k s / f o l d e r . php" model="
L i n k s " />
<view i d=" e d i t _ f o l d e r " f i l e =" l i n k s / e d i t _ f o l d e r . php"
<view i d=" e d i t _ r e c o r d " f i l e =" l i n k s / e d i t _ r e c o r d . php"
</ s w i t c h>
</ view>
</ s w i t c h>
<view i d=" f o o t e r " f i l e =" f o o t e r . php" />
</ view>
</ viewTree>
Quellcode 5.1: View-Baum der Demo-Applikation als XML-Notation.
5.2.1
Die Benutzeroberfläche
Begonnen wird nun bei der Spezifikation des View-Baumes (siehe Abschnitt 4.4.1).
Abbildung 5.1 zeigt den View-Baum der Webapplikation in einem UML-Klassendiagramm. Die Notation erfolgte wie in Abschnitt 4.4.1 beschrieben.
Die XML-Definition des Baumes wird in der Konfigurationsdatei der Webapplikation festgelegt (zur Konfiguration einer Webapplikation siehe Anhang A.3.2). Die
Definition ist im Quellcode 5.1 abgedruckt. Es wurden in der Definition bereits
models als Daten-Lieferanten für View-Skripts angegeben.
Abbildung 5.1: View-Baum der Beispielapplikation als UML-Klassendiagramm.
71
72
Der View-Knoten mainframe.body enthält unter anderem einen Schalter mit den
drei weiteren Knoten homepage, addressbook und links. Je nachdem welches Modul
vom Benutzer gerade gewählt wurde, wird der Schalter auf das entsprechende Unterelement gesetzt. Der Unterknoten homepage enthält keine weiteren View-Elemente.
Das Modul bindet ganz einfach eine externe Internet-Adresse als IFRAME 1 ein.
Die beiden anderen Unterknoten binden das Adressbuch bezeihungsweise die LinkDatenbank ein. Da hier weitere Ansichten benötigt werden, gibt es weitere Unterknoten.
Das View-Skript split_canvas.php teilt das Browserfenster mit Hilfe einer Tabelle
in zwei Spalten. Auf der linken Seite werden in Form eines Baumes die jeweiligen
Link- bzw. Adress-Kategorien mit Ordnern dargestellt. Auf der rechten Seite werden
verschiedene weitere Ansichten über einen Schalter eingebunden. Dazu gehören im
Fall des Adressbuch-Moduls die Ansichten für „alle Adressen im aktuellen Ordner
auflisten“, „Adress-Eintrag anzeigen“, „Adress-Eintrag editieren“, „Ordner editieren“
und „E-Mail erstellen“. Die Unteransichten der Link-Datenbank auf rechter Seite
sind ähnlich.
5.2.2
Erforderliche Aktionen
Für jede Ansicht wurden in einem weiteren Schritt nun erforderliche Aktionen festgelegt. Die Aktionen wurden im UML-Klassendiagramm (Abb. 5.1, Seite 71) bereits
als Methoden definiert. Folgende View-Knoten enthalten Interaktionselemente und
somit Verweise auf Aktionen:
mainframe.navigation_bar: Die an oberster Stelle liegende Navigationsleiste soll
das Auswählen der Module ermöglichen Es werden drei Buttons benötigt, für
die Auswahl von Homepage, Adressbuch und Link-Datenbank. Die Aktion heisst
im Beispiel SetModule und erfordert als Pfadinfo-Parameter ein Kürzel, welches
das gewünschte Modul referenziert. Die Aktionsklasse setzt je nach Auswahl
den Schalter mainframe.body an die richtige Position.
mainframe.body.addressbook.tree: In dieser Ansicht sind zum einen Buttons
für die Anzeige des Inhalts eines Ordners erforderlich. Es wurde dafür die
Aktion addressbook.ShowFolder definiert. Zum anderen können neue Ordner erstellt, geändert und gelöscht werden. Dafür wurden die Aktionen addressbook.CreateFolder, addressbook.EditFolder und addressbook.DeleteFolder
festgelegt.
mainframe.body.addressbook.folder: Diese Ansicht zeigt den Inhalt des aktuell
gewählten Ordners. Mit Klick auf einen Eintrag kann dieser angzeigt werden oder es kann eine E-Mail an die Person verfasst werden. Dafür wurden
die Aktionen addressbook.ShowRecord und addressbook.CreateEmail festgelegt.
Außerdem sind hier Buttons für die Aktionen addressbook.CreateRecord, addressbook.EditRecord und addressbook.DeleteRecord vorhanden.
mainframe.body.addressbook.edit_folder: In dieser Ansicht gibt es eine Aktion addressbook.SaveFolder die zum Speichern des geänderten Eintrages aufgerufen wird.
1
Mit sogenannten IFrames lassen sich in HTML andere Internet-Ressourcen im eigenen Fenster
einbinden (siehe [W3C99, Abschnitt 16.5]). Seit HTML 4.0 gehören sie zum HTML-Standard.
73
Abbildung 5.2: Repositories und Layouts.
mainframe.body.addressbook.edit_record: Analog zum vorigen View-Knoten,
gibt es hier die Aktion addressbook.SaveRecord.
mainframe.body.addressbook.mailform: Nach Verfassen der E-Mail wird mit
der Aktion addressbook.SendEmail die E-Mail versandt.
mainframe.body.links.tree: Analog zur linken Fensterseite im Adressbuch sind
hier die Aktionen links.ShowFolder, links.CreateFolder, links.EditFolder und
links.DeleteFolder vorgesehen.
mainframe.body.links.folder: Ähnlich wie beim Adressbuch gibt es in diesem
View-Knoten die Aktionen links.ShowRecord zum Anzeigen eines Datensatzes
und links.CreateRecord, links.EditRecord und links.DeleteRecord für die Verwaltung von Einträgen.
mainframe.body.links.edit_folder: Die Aktion links.SaveFolder dient zum Speichern des Eintrages.
mainframe.body.links.edit_record: Mit der Aktion links.SaveRecord wird ein
Link-Eintrag gespeichert.
Die Konzeption von DaVinci Applikationen ist relativ strikt. Jede zusätzliche
Ansicht müsste nun im Baum eingetragen werden.
5.2.3
Repositories zur Datenhaltung
Für die Speicherung der Links und Adressen werden zwei repositories benötigt. Da
die Einträge in einer Baumstruktur organisiert werden sollen, sind repositories vom
Typ SimpleTree erforderlich. Die beiden Repositories und ihre zugehörigen Layouts
wurden als UML-Klassen in Abbildung 5.2 dargestellt.
5.2.4
74
Applikationslogik
Die Applikationslogik wird in diesem Beispiel von den beiden models Links und
Addressbook realisiert. Es werden keine weiteren Klassen benötigt. Die entsprechende
Modifikation des View-Baumes erfolgt zum Teil auch nur durch Aktionsklassen (z. B.
durch die Aktionsklasse SetModule).
Das model Addressbook verwaltet das Adressbuch. Es dient einerseits zum Laden der jeweils benötigten Daten aus dem Adressbuch-repository. Andererseits werden über dieses model auch neue Einträge erstellt, vorhandene geändert oder gelöscht. Das model Links ist ähnlich aufgebaut, und verwaltet alle Einträge der LinkDatenbank. Zusätzlich bietet das model eine Funktion, die die als Homepage definierte URL zurückgibt. Jener Eintrag im repository, dessen Feld is_homepage auf
„true“ gesetzt ist, wird als Homepage verwendet. Die Funktion wird vom View-Skript
des Homepage-Moduls (siehe Abb. 5.1, Seite 71) benötigt. Die Anzeige der Homepage (View-Knoten mainframe.body.homepage benötigt deshalb auch kein eigenes
model.
Die Applikationslogik für das Beispiel ist relativ einfach. Abbildung 5.3 zeigt
ein Klassendiagramm der benötigten models mit den angebundenen repositories. Es
sind darin u. a. die öffentlichen Funktionen der models definiert, welche von den
jeweiligen Aktionsklassen aufgerufen werden. Diese Funktionen stellen sozusagen
die Schnittstelle zwischen controller und model nach dem MVC-Prinzip dar.
Um auch die zeitliche Ebene zu modellieren könnten für jede Interaktion Sequenzdiagramme erstellt werden. Das wäre vor allem bei aufwändigen Interaktionen unbedingt notwendig. In Abbildung 5.4 ist als Beispiel der Ablauf der Aktion
links.CreateRecord als Sequenzdiagramm dargestellt. Auf weitere Diagramme wird
nun verzichtet. Alle anderen Interaktionen finden auf ähnliche Weise statt. Zumeist
holt sich die Aktionsklasse die entsprechende model-Instanz, führt eine der öffentlichen Funktionen aus und ändert anschließend den View-Baum, wenn dieser nicht
bereits vom model geändert wurde.
5.3
Implementierung
Nach der Modellierung kann mit der Implementierung der Applikation begonnen
werden. Zuerst muss eine neue Webapplikation angelegt werden. Anschließend wird
die Konfigurationsdatei der Webapplikation erstellt, in der auch alle View-Bäume (in
diesem Beispiel wird nur einer benötigt) definiert werden.
Es ist ratsam zuerst alle View-Skripts zu erstellen, welche keine Daten ausgeben
bzw. deshalb kein model benötigen. Für alle anderen View-Skripts können bereits
leere Dateien angelegt werden. Dies schafft bereits die Struktur der Benutzeroberfläche. Als nächsten Schritt werden die Aktionsklassen der Reihe nach erstellt. Begonnen wird am Besten mit der Klasse SetModule. Diese Vorgehensweise ermöglicht
das Testen der Applikationslogik. Anschließend kann die Erstellung der repositories
und die Implementierung der models und ggf. auch anderen Klassen erfolgen.
5.3.1
Konfiguration und Benutzeroberfläche
Zu Beginn der Implementierung muss eine neue Webapplikation angelegt werden. Als
Ausgangspunkt kann das Verzeichnis usr/ der Distribution herangezogen werden.
Abbildung 5.3: Klassendiagramm der models.
Abbildung 5.4: Sequenzdiagramm der Aktion links.CreateRecord.
75
76
Nähere Details sind im Anhang A.1 und Abschnitt A.3.2 zu finden. Es muss die
Konfigurationsdatei der Webapplikation angelegt werden. In dieser Datei wird neben
diversen Einstellungen der View-Baum definiert.
Anschließend können alle View-Skripts angelegt werden. Das Layout und das
Design der Anwendung kann momentan noch vernachlässigt werden. Diese Aufgabe
sollte von einem Designer erledigt werden. Der Designer entwirft die Layouts und
schreibt die zugehörigen View-Skripts mit dem Wissen, welche Daten und Interaktionselemente wo eingebaut werden müssen. Leider gibt es für PHP noch keine
ausgereiften Tag libraries, wie etwa für JSP-Seiten [Sun03].
Bei der Entwicklung des Frameworks wurde bewußt auf die Verwendung eigener
Templating oder Makro-Befehle verzichtet. PHP ist relativ leicht zu erlernen. Ob
der Designer nun zusätzliche HTML-ähnliche Tags erlernen muss oder einige PHPBefehle, ist gewissermaßen gleichgültig. Die Verwendung von höheren Metasprachen
zur Erstellung von Vorlagen für Ansichten führt sehr oft zu Einschränkungen.
5.3.2
Aktionsklassen
Als zweiten Schritt bietet sich die Erstellung aller Aktionsklassen an. Sie definieren
nun alle Interaktionen aus Sicht des Benutzers (vgl. UX-Model [Con03]). Die Aktionsklassen sprechen die jeweils relevanten models und ihre öffentlichen Funktionen
an und verändern anschließend den View-Baum.
Der Quellcode der Aktionsklasse SetModule ist im Anhang B.2 als Beispiel abgedruckt.
5.3.3
Repositories
Für die Erstellung der repositories wurde eine Hilfsaktion verwendet. Diese Aktionsklasse definiert über die zur Verfügung stehende API das Layout (also alle Felder),
initialisiert die angebundenen Datenbanktabellen und registriert die repositories beim
RepositoryManager. Der Quellcode der Aktionsklasse ist in Anhang B.1 abgedruckt.
Die Aktionsklasse wurde über den Browser einmal aufgerufen und somit ausgeführt. In Zukunft soll das Erstellen und Verwalten von repositories über eine
Administratorenkonsole möglich sein (siehe dazu Abschnitt 7.1.3).
5.3.4
Implementierung der Models
Die Klassenrümpfe können anhand der Klassendiagramme aus Abb. 5.3 (Seite 75)
bereits erstellt werden. Es gilt nun die nötigten Funktionen zu implementieren. Der
Quellcode des models Links ist als Beispiel in Anhang B.3 zu finden.
Die Applikation ist nun soweit fertig. Am Ende sollte im Übrigen durch Ausführen aller Aktionen die Applikation ausreichend getestet werden. Aufgrund der
Wichtigkeit des Testens sei abschließend auf die Konzepte der Extreme ProgrammingGemeinde verwiesen [HL02].
Kapitel 6
Evaluierung
Abschließend soll das DaVinci Framework evaluiert werden. Es wird einerseits eine
qualitative Beurteilung anhand der zuvor definierten Anforderungen aus Abschnitt
2.2 angestrebt, andererseits werden einige Stärken und Schwächen des Frameworks
gegenübergestellt. Da in der vorhandenen DaVinci Version noch keine Sicherheitsaspekte berücksichtigt wurden, wird hier nicht näher auf die Erfüllung von Sicherheitsrichtlinien eingegangen.
6.1
Qualitative Beurteilung anhand der definierten Anforderungen
Die wahrscheinlich wichtigste Anforderung für ein Framework für Webapplikationen
ist die Effizienz und Geschwindigkeit mit der neue Webapplikationen entwickelt werden können. Vorraussetzung für eine effiziente Entwicklung ist die möglichst detaillierte Modellierung der Applikation vor ihrer Implementierung (siehe Abschnitt 3.1).
Die im vorigen Kapitel vorgestellten UML-basierten Konzepte unterstützen den Modellierungsprozess und erlauben die detaillierte Konzeption DaVinci -basierter Applikationen.
6.1.1
Handhabung und Effizienz
Durch die bereits vorgegebene Architektur kann der Focus direkt auf die Anforderungen der Applikation gelegt werden, ohne dass sich der Entwickler um ein grundlegendes Architekturkonzept kümmern muss. Die Modellierung neuer Webapplikationen
ist somit bereits auf einer höheren Ebene möglich. Es ist beispielsweise die Interaktion und die Behandlung von HTTP-Anfragen vorgegeben. Auch persistente Objekte
werden als model Stereotypen automatisch vom Framework verwaltet und es muss
keine Session-Behandlung implementiert werden. Für die Datenhaltung bieten die
vorgestellten repositories vorerst ausreichend Flexibilität. In Zukunft sollen von DaVinci außerdem weitere Datenbanksysteme unterstützt werden und es sollen auch
CHECK-Constraints (siehe [Sau94, S. 76ff]) und Beziehungen zwischen repositories
möglich sein.
77
KAPITEL 6. EVALUIERUNG
6.1.2
78
Erweiterungs- und Integrationsmöglichkeiten
Das Framework wurde im Hinblick auf spätere Erweiterbarkeit entworfen. Zu diesem Zweck wurden deshalb drei verschiedene Ebenen festgelegt, welche eine unterschiedliche Tiefe der Programmierung erlauben. Die unterste Schicht (der DaVinci
Core Layer) wird von den Basiskomponenten gebildet und soll nur von einem kleinen, überschaubaren Team verwaltet und erweitert werden, damit das Projekt auch
in der Zukunft überschaubar bleibt. Die eigentliche Entwicklungsschicht (Development Layer) ist jene Implementierungsebene, auf der Webapplikationen mit Hilfe
von DaVinci aufgesetzt werden. In dieser Schicht werden z. B.models, actions, ViewSkripts und weitere benutzerdefinierte Klassen erstellt. Es wurde noch eine dritte
Schicht (Distribution Layer) vorgesehen, welche die Distribution und den Austausch
von gebündelten Modulen (packages) erlauben. Solche Pakete sollen später über die
Projekt-Homepage publiziert und getauscht werden können.
Durch die Integrationsmöglichkeiten von PHP ist auch das DaVinci Framework
relativ gut für neue zukünftige Anforderungen vorbereitet. Durch Integration von
Unternehmensressourcen über verschiedenste Datenbanken, Java-Schnittstellen oder
XML-Technologien können eigenständige Applikationsserver angebunden werden.
Die Webapplikation läuft dann im Web-tier und enthält nur die notwendigste Applikationslogik für den Frontend-Einsatz. Eine solche Lösung wäre eine kostengünstige
Alternative zu kompletten Java-Umgebungen (siehe Abschnitt 1.4).
Auch die Integration von Webservices [Cer02] wäre eine wichtige Erweiterung für
das DaVinci Framework. Da es für XML und SOAP bereits PHP-Erweiterungen
gibt, wäre diese Erweiterung relativ wenig Aufwand. Die Architektur von DaVinci
eignet sich zudem hervorragend für die Integration von Webservices. Ein Webservice
wird ähnlich wie eine Interaktion bei DaVinci durch eine eindeutige URL spezifiziert.
Webservices können deshalb durch Aktionsklassen bereitgestellt werden.
Mit dem MVC-Konzept als Basis ist von Haus aus eine relativ gute Erweiterbarkeit gegeben. Daten, Ansichten und Interaktion sind im Framework völlig voneinander getrennt. Durch den zentralen FrontController können verschiedene Clients
(z. B. eine Unix Shell Console) integriert werden. Ein Benutzermanagement welches direkt beim FrontController ansetzt, ermöglicht benutzerdefinierte Rechte für
bestimmte Interaktionen. Das Framework ist auch bereits für die Anbindung verschiedener Datenbanksysteme vorbereitet. Verschiedene Ausgabeformate über XSLT
wären möglich.
6.2
Stärken und Schwächen
In diesem Abschnitt werden einige Stärken und Schwächen des DaVinci Konzepts
besprochen.
6.2.1
Stärken
Die Stärken von DaVinci liegen auf alle Fälle in der Effizienz der Entwicklung neuer
Anwendungen. Des Weiteren bietet DaVinci einige wichtige Features, wie etwa die
Datenhaltung in Form von repositories, welche Entitäten als flache Tabellen oder in
Form von Baum-Strukturen ermöglicht.
79
Modellierung und Implementierung
Das vorgestellte Konzept zur Modellierung neuer Anwendungen (siehe Abschnitt
3.4.4 bzw. Kapitel 5) ermöglicht einen relativ effizienten Entwicklungsprozess. Die
Trennung von Modellierung und Implementierung ist eine wichtige Vorraussetzung
dafür. Bevor die eigentliche Programmierung stattfindet, kann die Applikation über
UML-Diagramme entworfen werden.
Die Entwicklung neuer Anwendungen erfolgt nicht mehr von Grund auf, sondern auf einer abstrakten Ebene. Durch das Szenegraphen-Konzept wird eine relativ
strikte Modellierung der Benutzeroberfläche erreicht. Dies hat zur Folge, dass nicht
willkürliche Masken und Fenster erstellt werden können, was in der Praxis oft zur
Folge hat, dass schnell und schlampig (quick & dirty) neue Seiten und Formulare
angefügt werden. Alle Ansichten werden bereits vordefiniert. Die möglichen Interaktionen können in einem weiteren Schritt pro Ansicht spezifiziert werden. Durch
ein striktes Modell wird zumeist auch eine saubere Implementierung erreicht.
Entwicklung auf Basis einer vorgegebenen Architektur
Die Entwicklung neuer Webapplikationen erfolgt auf Basis einer vorgegebenen Architektur. Die Architektur gibt u. a. die Benutzerinteraktion vor, ermöglicht die
Persistenz von Objekten innerhalb einer Session und auch die Datenhaltung in Form
von repositories. Die Entwicklung von Basiskomponenten fällt deshalb aus.
Der MVC-Pattern ist ein grundlegendes Konzept in der Architektur von DaVinci. Dadurch ergeben sich vielfältige Erweiterungsmöglichkeiten. Erweiterungsund Integrationsmöglichkeiten wurden bereits in Abschnitt 6.1.2 besprochen.
Weitere Stärken
Das Framework wurde im Allgemeinen im Hinblick auf spätere Erweiterungen konzipiert. Viele Stärken und Möglichkeiten sind in der vorliegenden Version noch
nicht implementiert. Einige dieser Stärken, etwa die XSLT-Transformation für unterschiedliche Ausgabeformate, wurden bereits erwähnt.
6.2.2
Schwächen
Da sich das Framework zur Zeit noch keineswegs in Produktreife befindet, ist ein
Stärken/Schwächen-Profil grundsätzlich nicht einfach zu erstellen. In der vorliegenden Version wurde außerdem erst ein sehr geringer Funktionsumfang implementiert.
Aufgrund des offenen Konzepts von DaVinci sind viele Erweiterungen möglich. Ein
Mangel an Funktionalität kann deshalb wahrscheinlich durch eine Erweiterung behoben werden.
Persistenz von Objekten im Speicher
Die größte Schwäche des Frameworks ist allerdings das Fehlen der Laufzeit außerhalb
von HTTP-Anfragen. Diese Tatsache beruht darauf, dass PHP eine Skriptsprache ist
und daher keine Laufzeit und somit auch keine Persistenz von Objekten im Speicher
außerhalb von Anfragen ermöglicht. Das Problem wurde ausführlich in Abschnitt
3.2.5 besprochen.
80
Nachteile von PHP4
Da bei DaVinci -basierten Webapplikationen sehr oft Objekte per Referenz übergeben werden müssen, gibt es mit PHP4 schwerwiegende Probleme. Bei PHP4 werden
Objekte beim Übergeben an Funktionen bzw. als Rückgabewert von Funktionen standardmässig kopiert. Dies bedeutet, dass die Referenz auf das Objekt dabei verloren
geht. Wird beispielsweise ein model-Objekt beim ModelManager angefordert, wird
eine Referenz auf das Objekt zurückgegeben. Es ist wichtig, dass jede Komponente
mit derselben Instanz arbeitet. Es kann daher vorkommen, dass durch Vergessen
einer einzigen Pointer-Anweisung (mit &) schwerwiegende Folgefehler auftreten, die
nicht sofort bemerkt werden.
In der Version 5 wird dieses Problem nicht mehr existieren, da bei PHP5 standardmässig die Referenz eines Objekts übergeben wird.
Einschränkung durch die vorgegebene Architektur
Durch die bereits vordefinierte Architektur des Frameworks ist der Entwickler in
manchen Fällen in seinem Spielraum eingeschränkt. Das Modellierungskonzept berücksichtigt zur Zeit auch noch keine Client-seitige Applikationslogik. Interaktionen
finden momentan ausschließlich über die URL statt.
Framesets und mehrere Browserfenster
Grundsätzlich wurde die Möglichkeit der Verwendung mehrerer Browserfenster und
somit auch Framesets und Popup-Fenster angestrebt. Es können deshalb mehrere
View-Bäume definiert werden, wobei für jedes Fenster ein Baum benötigt wird.
Durch die Verwendung von Cookies zur Session-Behandlung ist allerdings die Identifizierung des jeweiligen Browserfensters problematisch. Der Browser schickt, egal über
welches Fenster Interaktion stattfindet, die im Cookie gespeicherte Session-Kennung
mit zum Server. Das Framework kann deshalb nicht feststellen, von welchem Fenster
die Anfrage gesendet wurde. Folglich ist dem ViewGenerator nicht bekannt, welchen
View-Baum er nun für die Generierung der Benutzeroberfläche verwenden soll. Zur
Zeit muss daher von der jeweiligen Aktionsklasse der View-Baum explizit gewählt
werden, falls die Interaktion über ein anderes Fenster stattfinden sollte.
Eine mögliche Lösung wäre, die Session-Kennung direkt über die URL (GETMethode) oder in einem versteckten Formularfeld (über die POST-Methode) mitzusenden. Die erste Variante würde allerdings keine schönen URLs produzieren. Die
zweite Variante scheint am günstigsten zu sein.
Kapitel 7
Ausblick
Das im Rahmen dieser Diplomarbeit entwickelte Framework wurde im April 2003
als Open Source Projekt gestartet. Die Homepage des Projekts ist unter der URL
http://phpdavinci.sf.net erreichbar. Es wird beabsichtigt das Projekt weiter zu entwickeln und andere interessierte Entwickler daran zu beteiligen. Zur Zeit ist das
Framework allerdings als Prototypen zu betrachten. Wichtige Funktionen, wie etwa
ein Benutzermanagement oder die Ausgabe über XSLT sind noch nicht realisiert
worden.
Die Softwarearchitektur von DaVinci wurde in drei Schichten unterteilt (siehe
Abschnitt 6.1.2). Vor allem für die Weiterentwicklung des Core Layers soll ein
überschaubares Entwicklerteam gefunden werden. Jene Entwickler, welche das Framework für ihre eigenen Projekte einsetzen (Entwicklung im Development Layer),
sollen in Zukunft einzelne Komponenten als Erweiterungspakete über die ProjektHomepage anderen Entwicklern zur Verfügung stellen können.
7.1
Erweiterungsmöglichkeiten
Wie bereits bei der Evaluierung im vorigen Kapitel erwähnt, gibt es zahlreiche Erweiterungsmöglichkeiten. Einige davon, vor allem jene welche in naher Zukunft entwickelt werden sollen, werden im Anschluss kurz beschrieben.
7.1.1
Framework Architektur
Was die Architektur ganz allgemein betrifft, so sollten folgende Erweiterungen implementiert werden. Zur Zeit ist die Verwendung mehrerer Browserfenster, Pop-ups
und Framesets nicht sinnvoll einsetzbar (siehe Abschnitt 6.2.2). Die Identifikation
des aktiven Fensters, beispielsweise über ein verstecktes Formularelement in jeder
Seite, muss möglich sein. Auch einige Erweiterungen in der API des ViewGenerators
wären gegebenenfalls notwendig.
Im Modell ist momentan auf der Client-Seite keine Applikationslogik, etwa über
JavaScript, etc. modellierbar. Für bestimmte Interaktionen (z. B. eine BaumNavigation) wäre es sinnvoll den am Client erforderlichen JavaScript Code automatisch zu generieren. Für solche Anwendungsfälle sollte eine Erweiterung der Interaktionsschnittstelle ins Auge gefasst werden.
81
KAPITEL 7. AUSBLICK
7.1.2
82
Unterschiedliche Ausgabeformate
Sehr nützlich wäre die Ausgabe der Inhalte in unterschiedlichen Formaten (XHTML,
PDF, SVG, WML oder anderen spezifischen XML-Dokumenten) bzw.. in unterschiedlichen Vorlagen desselben Formats (z. B. für Browser auf verschiedenen Geräten). Dafür müsste der ViewGenerator um einen XSLT-Parser erweitert werden.
Zusätzlich müssten für jeden View-Knoten eines View-Baumes mehrere AusgabeVorlagen erstellt werden, je nachdem in welchen Formaten die Ansicht zur Verfügung
stehen soll.
7.1.3
Verwaltung und Werkzeuge über eine Konsole
Bereits mehrmals angesprochen wurde auch die Integration einer eigenen Administratorenkonsole. Will man neue repositories anlegen, muss zur Zeit noch eine Hilfsaktion erstellt werden, welche mit Hilfe der API für repositories (Anhang A.5) die
erforderlichen Layouts erstellt, die repositotires initialisiert und evtl. beim RepositoryManager registriert. Das ist nur ein Beispiel für Funktionen, die über eine Konsole
zur Verfügung stehen sollten. Die Konsole soll eine schnelle und sichere Schnittstelle
zur Applikation darstellen, welche für administrative Zwecke genutzt werden kann.
Es wäre natürlich auch eine Administrationsapplikation über den Browser denkbar. Administrative Tätigkeiten sollten aber möglichst effizient und rasch erfolgen
können. Die Ergonomie einer grafischen Oberfläche muss nicht immer gegeben sein.
Sinnvoller erscheint deshalb die Integration einer Konsole (vgl. Komponentendiagramm aus Abb. 4.1, Seite 50).
Über die Konsole können zumdem auch Shell-Skripts ausgeführt werden, welche
in einer Linux-Umgebung etwa von Cron-Jobs angestoßen werden. Somit wären
zeitlich gesteuerte und periodische Funktionsaufrufe möglich.
7.1.4
Integration eines Applikationsservers
PHP ist als Skriptsprache für aufwändige Webapplikationen mit komplexer Applikationslogik grundsätzlich weniger gut geeignet. Andererseits bieten Skriptsprachen und vor Allem solche, welche innerhalb von HTML-Code sogenannte SkriptletElemente erlauben, im Web-Bereich einige Vorteile (siehe Abschnitt 1.4.2).
Für aufwändige Web-basierte Anwendungen sollte daher ein eigenständiger Applikationsserver angebunden werden können. Die Entwicklung eines Web-Frontends
für bestimmte Anwendungen mit Hilfe von DaVinci ist durchaus erfolgversprechend.
Das Szenegraphenkonzept und die Interaktion über einen strikten URL-Formalismus
hat sich als sehr nützlich erwiesen. Die Entwicklung wäre gegebenenfalls kostengünstiger als eine komplette Java-Lösung [Sch03].
Die Integration eines Applikationsservers wäre zum einen über XML-Protokolle
wie SOAP oder XML/RPC möglich. Eine andere Möglichkeit bietet sich für Java
durch die Java-Unterstützung von PHP an (siehe Abschnitt 1.4.1). Die Java-Integration wäre etwa über bestimmte models möglich, welche Zugriff auf bestimmte JavaObjekte haben.
PHP bietet in seinem Funktionsumfang bereits viele Möglichkeiten zur Integration von diversen Standards und Umgebungen an. Man braucht sich dazu bloß die
Dokumentation [The03a] anzusehen. Sinnvoll wäre etwa in Zukunft auch die Integration eines LDAP-Servers fürs Benutzermanagement.
KAPITEL 7. AUSBLICK
7.1.5
83
Webservices
Die Unterstützung von Webservices [Cer02] wäre eine nützliche Erweiterung für das
Framework. Dazu können u. a. die von PHP zur Verfügung stehenden Funktionen für
XML und SOAP verwendet werden. Die Architektur von DaVinci eignet sich sehr
gut für die Integration von Webservices. Da ein Webservice laut Definition [W3C02]
über eine eindeutige URL referenziert wird, kann es sehr einfach von einer Aktionsklasse bereitgestellt werden. Die Aktionsklasse kann Komponenten zur Generierung
von WSDL-Dokumenten verwenden. Verschiedene Daten können über repositories
integriert werden.
7.2
Zusammenfassung
Abschließend bleibt zu sagen, dass die Entwicklung von Webapplikationen mit DaVinci bereits relativ komfortabel ist. Nach der Modellierung kann die Entwicklung
relativ rasch durch Erstellen der einzelnen Klassen und Skripts erfolgen. Das Framework erfüllt seinen Zweck als Prototyp hervorragend. Die reine Entwicklungsdauer
der Demo-Applikation umfasste etwa einen halben Tag, wenn man von vom Design
und auch einigen Bugs, die während der Entwicklung in der Framework API beseitigt
werden mussten, absieht.
Erhebliche Probleme gibt es allerdings noch mit der Persistenz von repositories.
Grundsätzlich werden model -Klassen innerhalb der Session persistent verwaltet. Besitzt ein model als Variable eine Referenz auf ein repository, so wird dieses jedoch
nicht offen gehalten. Zur Zeit werden vom Manager alle repositories am Ende eines
Requests geschlossen. Es muss also vom model beim nächsten Request wieder geöffnet werden. Grund dafür ist, dass die hierarchische Datenstruktur des verwendeten
SimpleTree repository beim Speichern der Instanz innerhalb der Session zerstört wird.
Das Problem wurde auch in Abschnitt 3.2.5 angesprochen.
Ein weiteres Problem stellt die Übergabe von Objekten bei PHP4 dar. Objekte werden nämlich standardmäßig by-value übergeben, was soviel bedeutet, dass
Objekte beim Übergeben an Funktionen kopiert werden. Bei der neuen PHP5 Version werden Objekte standardmäßig by-reference übergeben. Aus mehreren weiteren
Gründen, wird deshalb die Portierung von DaVinci nach PHP5 in den nächsten
Monaten ins Haus stehen. Es wäre auch sinnvoll, die Integration einer der Script
Running Magic (siehe Abschnitt 3.2.5) ähnlichen Komponente, nochmals zu überdenken.
Anhang A
Details zum DaVinci Framework
Anhang A enthält einige Details, die das DaVinci Framework näher beschreiben. Es
werden hier die Verzeichnisstruktur der Distribution (welche im Übrigen auf der beiliegenden CD-ROM enthalten ist), DaVinci Umgebungsvariablen und Datentypen,
die Konfiguration und die API für repositories erklärt.
84
ANHANG A. DETAILS ZUM DAVINCI FRAMEWORK
A.1
85
Verzeichnisstruktur der DaVinci Distribution
In Abbildung A.1 ist die Verzeichnisstruktur der DaVinci Distribution dargestellt.
Die wichtigsten Ordner in der ersten Ebene sind conf/, lib/ und usr/. Der Ordner conf/ enthält zur Zeit eine Datei namens davinci.xml, welche Server-spezifische
Parameter enthält (siehe Abschnitt A.3.1). Im Verzeichnis lib/ befinden sich alle
Basisklassen des Frameworks. All diese Klassen sind Bestandteil des Core Layers
(siehe Abschnitt 6.1.2). Die Framework-API wird ausschließlich durch diese Klassen gebildet. Alle Klassen und Scripts einer konkreten Webapplikation befinden sich
im Verzeichnis der Distribution unter usr/. Zu diesen benutzerspezifischen Dateien
gehören alle actions, models, views und diverse XML-Konfigurationsdateien. Die
Definitionen der repositories einer Webapplikation befinden sich nicht in Dateien,
sondern sind im sogenannten Master-repository gespeichert (siehe Abschnitt A.5.4).
Die weiteren Ordner der Distribution enthalten verschiedene Konsolenscripts
(bin/), diverse temporäre Dateien (z. B. Datenbank-Inhalte als SQL-Skripts) und
eine Dokumentation (docs/). Eine Ausführliche Installationsanleitung befindet sich
in der Datei INSTALL im Hauptverzeichnis der Distribution.
A.1.1
Mehrere Webapplikationen auf einem Server
Um auf einem Webserver fallweise mehrere DaVinci-basierte Webapplikationen parallel betreiben zu können, wurden die benutzerspezifischen Klassen und Scripts vom
restlichen Programmcode des Frameworks getrennt und im Ordner usr/ abgelegt.
Dieser Ordner enthält die beiden weiteren Ordner htdocs/ und webapp/. Der Ordner htdocs/ gleicht dem öffentlichen Ordner des Webservers (beziehungsweise eines
virtuellen Hosts, falls diese verwendet werden) und enthält nichts weiteres als ein
Index-Script und die Datei index.php (siehe 4.2.1). Fallweise können auch statische
Dateien wie Cascading Stylesheets oder Bilddateien hier abgelegt werden. Dieser
Ordner ist im Web öffentlich und sichtbar. Alle Klassen und Scripts der zugehörigen Webapplikation befinden sich hingegen im Ordner webapp/. Somit sind auch
Sicherheitsrisiken aus dem Weg geräumt. Dateien der Webapplikation können dadurch nicht über einen expliziten GET-Request von außen erreicht werden, sondern
werden bei Bedarf vom Framework selbst eingebunden. Nach Installation des Frameworks kann der usr/-Ordner an jede beliebige Stelle am Server verschoben werden.
|-|-|-|-|
|
|
|-‘--
bin
conf
docs
lib
|-- common
|-- core
‘-- storage
tmp
usr
|-- htdocs
‘-- webapp
diverse Konsolenscripts
allgemeine Konfigurationsdateien
Dokumentation
Basisklassen des Frameworks
diverse Hilfsklassen
Hauptklassen, u.a. Manager-Klassen
Klassen für die Datenbankanbindung
temporäre Daten
benutzerspezifische Dateien
Index-Script, FrontController und statische Daten
Klassen und Scripts der Webapplikation
Abbildung A.1: Verzeichnisstruktur der DaVinci Distribution.
/usr/local/phpdavinci/
Framework Distribution
/var/www
|-- [virtual_host_1]
|
|--htdocs
|
|--webapp
|
‘--logs
|-- [virtual_host_2]
|
|--htdocs
|
|--webapp
|
‘--logs
virtuelle Hosts mit versch. Webapplikationen
86
öffentliches Verzeichnis
Webapplikation
eventuell Log-Dateien des Webservers
Abbildung A.2: Mehrere Webapplikationen auf einem Server.
In einer Linux-Umgebung wäre zum Beispiel eine Verzeichnisstruktur gemäß Abb.
A.2 sinnvoll.
A.1.2
DaVinci bei einem Webspace-Provider betreiben
Möchte man das Framework bei einem Webspace-Provider einrichten, hat man nicht
die nötigen Zugriffsrechte für die Installation des Frameworks unter /usr/local (unter
Linux). In diesem Fall müsste man die Distribution wenn möglich außerhalb des
öffentlichen Ordners im Home-Verzeichnis ablegen. Hat man nur für den öffentlichen
Ordner (bei Apache zumeist htdocs/) Schreibrechte, sollte der Zugriff auf den Ordner
welcher die Distribution enthält für HTTP-Requests unbedingt gesperrt werden.
Die Verzeichnisstruktur sieht möglicherweise dann so aus:
/home/kunde001/www
|--htdocs
|--logs
|--phpdavinci
‘--webapp
A.2
öffentliches Verzeichnis
eventuell Log-Dateien des Webservers
Framework Distribution
Webapplikation
Umgebungsvariablen
PHP4 stellt alle globalen Parameter in einem assoziativen Array namens $GLOBALS
zur Verfügung. Dieses Array kann für bestimmte Zwecke sehr dienlich sein. Es eignet
sich unter anderem hervorragend für Konfigurationsparameter, die global benötigt
werden. Da PHP4 noch keine statischen Instanzvariablen unterstützt, kann man mit
Hilfe dieses globalen Arrays auch statische Variablen simulieren, indem man sie darin
ablegt. Im DaVinci Framework wurde das $GLOBALS Array einerseits für Umgebungsvariablen verwendet und andererseits enthält es alle vorhandenen statischen
Instanzvariablen.
Das Array enthält in der ersten Ebene die für DaVinci relevanten Schlüssel application, request, session und static. Diese Struktur wurde mit Absicht an die application, request und session scopes, wie sie bei Java Servlets verwendet werden,
angelehnt [Hun01]. Der Schlüssel application zeigt auf ein assoziatives Array, welches applikationsübergreifende Parameter enthält und der Schlüssel request auf ein
weiteres Array, welches requestbezogene Parameter enthält. Der Schlüssel session
87
enthält alle Session-Variablen. Alle statischen Instanzen von Klassen (insbesondere
Singleton -Klassen) sind unter static zu finden. Diese können und sollen allerdings
unbeachtet bleiben. Die Verwendung der Variablen erfolgt nämlich von den zugehörigen Klassen transparent und ist nach außenhin ohnehin nicht relevant.
A.3
Konfiguration
Alle Konfigurationsparameter sind im DaVinci Framework in XML-Dateien definiert. Im Rahmen dieser Diplomarbeit wurde für die Konfigurationsdateien weder
eine DTD (Document Type Definition), noch ein XML-Schema spezifiziert, da der
verwendete Parser (Expat 1 ) ohnehin keine Validierung vornimmt. Die Klasse ConfigFileParser, welche die Konfigurationsdateien einliest, gibt allerdings bei den meisten
fehlerhaften Angaben eine Fehlermeldung aus.
Nach Installation der Distribution (die Einrichtung ist u. a. in Abschnitt A.1
beschrieben bzw. als Readme-Datei in der Distribution) sollte vorerst die Datei conf/davinci.xml angepasst werden. Sie enthält allgemeine Werte, die den Applikationsserver betreffen. Jede einzelne Webapplikation erfordert im Stammverzeichnis des
webapp/-Ordners eine weitere Konfigurationsdatei. Diese Datei muss webapp.xml
heißen. Sie wird vom Framework bei jedem Request eingelesen.
A.3.1
Konfiguration des Servers: davinci.xml
Die Datei conf/davinci.xml enthält als Wurzelelement das Element <DaVinci>. Innerhalb dieses Elements können verschiedene Parameter über Unterelemente definiert
werden. Zur Zeit ist die Angabe der beiden folgenden Elemente erlaubt:
• <phpIncludePath>
• <dsnMapping>
Zusätzlicher include-Pfad
DaVinci benutzt einige Pakete des PEAR Projektes und erfordert deshalb eine Installation von PEAR am Webserver. Es kann jedoch vorkommen, dass bei einem
Webservice-Provider kein PEAR installiert ist. In diesem Fall können die benötigten PEAR-Pakete auch manuell ins eigene Home-Verzeichnis gespeichert werden.
Mit dem folgenden Parameter kann ein zusätzlicher include-Pfad definiert werden.
DaVinci versucht dann diesen Pfad dem include_path von PHP (siehe [The03a, Abschnitt I.4]) hinzuzufügen. Es können auch mehrere Pfade, mit Doppelpunkten getrennt, angegeben werden. Das Element ist optional und darf nur einmal vorkommen.
<phpIncludePath> [ i n c l u d e _ p a t h ]</ phpIncludePath>
< !−− B e i s p i e l : −−>
<phpIncludePath>/ u s r / s h a r e / p e a r : / u s r / l i b /php</ phpIncludePath>
1
Expat ist ein relativ einfacher und dafür sehr schneller XML-Parser, der keine Validierung
durchführt. Er ist als Extension bereits in der PHP-Distribution enthalten.
88
Globale DSN-Kürzel
Registrierte repositories erfordern die Angabe einer Datenbank, in der die Daten
des repositories gespeichert werden. Die Angabe dieser Datenbank erfolgt über data
source names (DSN) wie in Abschnitt 4.5.1 beschrieben. Um eine Webapplikation
besser portieren zu können, wurden sogenannte DSN-Kürzel (shortcuts) eingeführt.
Anstatt eines DSN kann nämlich auch ein Kürzel mit einer Raute als Prefix angegeben werden. Das Kürzel #local_mysql zeigt etwa, laut obigen Beispiel, auf die
Datenbank mysql://user:pwd@localhost/davinci. Will man eine Webapplikation auf
einen anderen Server transferieren muss bloß das Kürzel über den Eintrag in der Konfigurationsdatei geändert werden. Zudem erspart man sich die Angabe des langen
DSN-Pfades bei repositories, die alle in der selben Datenbank untergebracht sind.
Das Element ist optional und kann mehrmals vorkommen.
<dsnMapping i d=" [ s h o r t c u t ] "> [ dsn_mapping ]</ dsnMapping>
< !−− B e i s p i e l : −−>
<dsnMapping i d=" l o c a l _ m y s q l ">
m y s q l : // u s e r : p w d @ l o c a l h o s t / d a v i n c i
</ dsnMapping>
A.3.2
Konfiguration der Webapplikation
Die Konfigurationsdatei der Webapplikation muss sich im Stammverzeichnis des Applikationsordners befinden (webapp/) und webapp.xml heißen. Alle Konfigurationsparameter müssen innerhalb des Elements <DaVinciConfiguration> angegeben werden.
Folgende Elemente sind zulässig:
• <indexFile>
• <masterRepository>
• <dsnMapping>
• <include>
• <viewTree>
• <model>
Für jede einzelne Webapplikation können in der weitere DSN-Kürzel mit dem
Element <dsnMapping> definiert werden. Die Syntax ist gleich wie bei der ServerKonfigurationsdatei. Wurde in der Server-Konfigurationsdatei bereits ein Kürzel mit
dem selben Namen definiert, hat dieses Vorrang.
Dateiname des Front-Controller Skripts
Der folgende Parameter definiert den Dateinamen des Front-Controller Scripts. In
der Distribution heißt das Script davinci.php. Eine besonders schöne URL erhält
man, wenn man das Script davinci (ohne Endung) nennt. Dies ist allerdings nur
möglich, wenn sich beim Webserver der standardmäßige MIME-Typ für Dateiformate
ohne Endung angeben lässt. Hat man bei Apache Zugriff auf die Konfigurationsdatei
(httpd.conf), läßt sich das mit der Zeile
89
DefaultType application/x-httpd-php
erreichen. Der Parameter ist erforderlich und darf nur einmal vorkommen.
<i n d e x F i l e> [ s c r i p t _ f i l e n a m e ]</ i n d e x F i l e>
< !−− B e i s p i e l : −−>
<i n d e x F i l e>d a v i n c i . php</ i n d e x F i l e>
Master-Repository festlegen
Im Master-repostiory speichert der Repository-Manager die Definitionen aller registrierten repositories (siehe Abschnitt A.5.4). Es dürfen keine Webapplikationen die
selbe Datenbank für ihr Master-Repository verwenden. Der Parameter ist erforderlich und darf nur einmal vorkommen.
<m a s t e r R e p o s i t o r y> [ dsn | s h o r t c u t ]</ m a s t e r R e p o s i t o r y>
< !−− B e i s p i e l e : −−>
<m a s t e r R e p o s i t o r y>#l o c a l _ d a v i n c i _ i n t r a n e t</ m a s t e r R e p o s i t o r y>
<m a s t e r R e p o s i t o r y>m y s q l : // user:pwd@mysql / d a v i n c i _ i n t r a n e t</
m a s t e r R e p o s i t o r y>
Einbindung weiterer Konfigurationsdateien
Mit dem <include>-Parameter können weitere Konfigurationsdateien eingebunden
werden. Der Parser setzt beim Einlesen in der angegebenen Datei fort. Das Element
ist optional und kann mehrmals, auch verschachtelt vorkommen.
<i n c l u d e> [ f i l e n a m e ]</ i n c l u d e>
< !−− B e i s p i e l : −−>
<i n c l u d e>u i . xml</ i n c l u d e>
Definition von View-Bäumen
Alle benötigten View-Bäume müssen über <viewTree>-Elemente in der Konfigurationsdatei spezifiziert werden. Die Definition der View-Bäume wurde bereits in
Abschnitt 4.4.1 behandelt.
Spezifikation von models
Alle models die verwendet werden, müssen mit je einem eigenen <model>-Element
angegeben werden. Ansonsten wird das model nicht initialisiert und ist somit nicht
verfügbar. Wurde ein model bereits für einen Knoten in einem View-Baum angegeben, ist die explizite Angabe nicht mehr erforderlich. Eine doppelte Spezifikation ist
jedoch unproblematisch.
<model> [ model_mapping ]</ model>
< !−− B e i s p i e l : −−>
<model>c o n t e n t . N a v i g a t i o n</ model>
A.4
90
DaVinci Datentypen
Bei PHP werden grundsätzlich alle Typen von Variablen dynamisch umgewandelt
(dynamic type casting, siehe [The03a, Abschnitt II.7]). Diese Eigenschaft ermöglicht
zwar vor allem bei kleineren, unkritischen Scripts eine bequeme Handhabung von
Variablen, macht jedoch bei größeren Projekten viele Probleme. Vor allem auch
bei der Datenbankanbindung ist es unbedingt notwendig, dass der Applikation der
richtigen Typ einer Variablen bekannt ist.
Bei DaVinci wird deshalb der Typ aller ein- und ausgehenden Variablen vordefiniert. Alle Variablen die über den Request in das Framework eingehen und alle
Variablen die aus der Datenbank gelesen und in die Datenbank geschrieben werden, erhalten eine eindeutige Typenbezeichnung und werden je nach Bedarf korrekt
umgewandelt.
Die Typen werden über Konstanten angegeben, welche in jener Datei definiert
sind, in der sich die Klasse DaVinci befindet. Die folgenden Typen wurden vorerst
definiert:
DATATYPE_BOOLEAN
DATATYPE_INTEGER
DATATYPE_FLOAT
DATATYPE_VARCHAR
DATATYPE_TEXT
DATATYPE_BLOB
DATATYPE_SIMPLETIME
DATATYPE_SIMPLEDATE
DATATYPE_ISO8601DATE
DATATYPE_UNIXTIMESTAMP
DATATYPE_HASHTABLE
A.4.1
boolscher Wert (true/false)
Ganzzahl (plattformabhängige Größe)
Fließkommazahl (plattformabhängige Größe)
kurze Zeichenkette (max. 255 Bytes)
lange Zeichenkette (String)
Bytefolgen (wie TEXT)
Uhrzeit im Format HH:MM:SS
Datum im Format YYYY:MM:DD
Datumsformat nach ISO8601
Unix-Zeitstempel in Sekunden
(assoziatives) Array
Typenkonvertierung von Request-Parametern
Alle erforderlichen Pfadinfo- und POST-Parameter einer Aktion werden im Konstruktor der Aktionsklasse vordefiniert. Dabei muss auch der Typ dieser Parameter angegeben werden. Bei eingehenden Requests werden vom Action-Manager die
Pfadinfo- und POST-Parameter in die entsprechenden DaVinci Datentypen konvertiert. Die im Array $parameters befindlichen Werte innerhalb der Aktionsklasse sind
bereits im richtigen Datentyp verfügbar. Die Abbildung zwischen den DaVinci Typen und den nativen PHP-Datentypen ist in der privaten Funktion _typeCast() der
Klasse ActionManager fix definiert.
A.4.2
Typenkonvertierung von und zu Datenbanken
Ähnlich wie bei Request-Parametern werden auch Datenbank-Werte auf dem Weg
ins Framework bzw. in die Datenbank zurück konvertiert. Jede Datenbankklasse
muss drei Funktionen implementieren, die für diese Typenumwandlung verantwortlich sind:
91
typeCast(): Die Funktion dient wie die gleichnamige Funktion im Action-Manager
zur Typenkonvertierung von Werten die von der Datenbank ins Framework
eingelesen werden.
convert2dbType(): Diese Funktion wird für die Erstellung der Datenbanktabelle
benötigt. Beim Ausführen des SQL CREATE-Kommandos müssen die Datentypen aller Attribute der Relation definiert werden. Da jedes Datenbanksystem
verschiedene Datentypen verwendet bzw. die Bezeichnungen sehr stark variieren, muss für jeden DaVinci Datentyp ein passender Datenbank-Datentyp
angegeben werden.
prepare4db(): Die Funktion bereitet den Wert eines DaVinci Datentyps auf eine
SQL-Abfrage vor.
A.5
Repository API
Die API zur Verwendung von repositories ist bereits sehr komplex. Es Bedarf einiger
Übung, um repositories richtig einsetzen zu können. Als Beispiel der Anwendung
sei auch auf den Quellcode im Abschnitt B.1 verwiesen. Der Code erstellt die zur
Demo-Applikation aus Kapitel 5 benötigten repositories.
A.5.1
Erstellen von repositories
Repositories werden ganz einfach über die entsprechende Klasse (zur Zeit CollectionRepository oder SimpleTreeRepository) erstellt. Der eindeutige Bezeichner muss
bereits im Konstruktur angegeben werden. Das Layout (die Feld-Definitionen) wird
über eine RepositoryLayout -Instanz definiert und mit der Funktion setLayout() dem
repository zugewiesen. Soll das repository an eine Datenbank angebunden werden,
muss mittels der Funktion setDSN() ein DSN-Parameter angegeben werden.
Folgendes Beispiel demonstriert das Erstellen einer neuen Collection mit der Bezeichnung simple_textpages:
$ t r e e = new C o l l e c t i o n R e p o s i t o r y ( ' s i m p l e _ t e x t p a g e s ' ) ;
$ l a y o u t = new R e p o s i t o r y L a y o u t ( ) ;
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' t i t l e ' , DATATYPE_VARCHAR,
Array (FIELDOPTION_LENGTH = > 255) ) ;
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' image ' , DATATYPE_BLOB) ;
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' t e x t ' , DATATYPE_TEXT) ;
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' l a s t _ u p d a t e ' , DATATYPE_UNIXTIMESTAMP) ;
$ t r e e −>s e t L a y o u t ( $ l a y o u t ) ;
$ t r e e −>setDSN ( '#l o c a l _ m y s q l ' ) ;
Dieses CollectionRepository hat als Attribute die Felder title, image, text und
last_update. Die Funktion addFieldDefinition () der Klasse RepositoryLayout erfordert als Parameter den Feldnamen, den DaVinci Datentyp (siehe Abschnitt A.4) und
ein optionales, assoziatives Array mit zusätzlichen Optionen. Folgende Optionen sind
zur Zeit erlaubt:
FIELDOPTION_NOTNULL: Gleicht der Option NOT NULL des SQL Create
Befehls. Die Option erfordert einen boolschen Wert (true oder false).
92
FIELDOPTION_LENGTH: Gleicht der Option LENGTH des SQL Create Befehls. Es wird ein Integer-Wert erwartet. Bei Verwendung des Typs DATATYPE_VARCHAR muss diese Option angegeben werden.
FIELDOPTION_DEFAULT: Gleicht der Option DEFAULT des SQL Create
Befehls. Mit dieser Option kann ein Standardwert für das Attribut definiert
werden.
DSN-Notation
Wurde der DSN-Parameter im repository gesetzt, kann eine Datenbank angebunden werden. Es stehen dann weitere Funktionen zur Verfügung, mit denen Datensätze geladen, gespeichert und gelöscht werden können. Die Spezifikation des
DSN-Parameters erfolgt gemäß der folgenden Notation:
dbms://[username]:[password]@host[:port]/database
Beispiel:
mysql://davinci:passme@localhost/intranet
Die in eckige Klammern gesetzten Parameter sind optional und können ausgelassen werden. Zur Zeit ist als DBMS nur das Kürzel mysql für MySQL erlaubt, da
noch keine anderen Datenbanksysteme unterstützt werden.
A.5.2
Offline-Manipulation von Einträgen
Die Funktionen zur Offline-Manipulation sind:
newRecord(): Die Funktion dient zum Erstellen eines neuen Datensatzes. Zurückgegeben wird eine Referenz des neu erzeugten Eintrags. Die ID des neuen
Datensatzes wird vom Framework vergeben.
get(): Die Funktion liefert eine Referenz zum Datensatz der angegebenen ID zurück.
getAll(): Diese Funktion liefert eine Referenz auf den internen Datensatz-Container
zurück, indem alle Einträge enthalten sind.
getWhere(): Die Funktion liefert einen Datensatz zurück, bei dem ein bestimmtes
Feld einen bestimmten Wert hat. Es wird allerdings nur immer der erste gefundene Eintrag zurückgegeben. Das bedeutet, dass die Funktion nur auf ein
Feld angewendet werden sollte, welches eindeutige Einträge (unique) enthält.
getSize(): Die Funktion gibt die Anzahl der vorhandenen (geladenen) Datensätze
zurück.
beginWalk(): Datensätze können mit dieser Funktion durchwandert werden. Der
Aufruf von beginWalk() startet die Sequenz und setzt intern einen Zeiger auf den
ersten Datensatz. Anschließend kann mit der Funktion nextRecord() stets der
nächste Datensatz abgeholt werden, solange bis die Funktion false zurückliefert.
beginWalkWhere(): Diese Funktion erlaubt zusätzlich die Angabe einer Bedingung. Es werden nur jene Datensätze durchwandert, bei denen ein bestimmtes
Feld einen bestimmten Wert aufweist (vgl. getWhere()).
93
delete(): Mit dieser Funktion kann ein Eintrag gelöscht werden. Wurde eine Datenbank angebunden wird auch der Eintrag in der Datenbank gelöscht. Wurde
keine Datenbank angebunden, gleicht die Funktion der Funktion unload().
dump(): Diese Funktion dient vorwiegend zum Debugging. Alle vorhandenen Einträge werden ähnlich wie bei DaVinci::dump() formatiert dargestellt. Die
Funktion ist deshalb notwendig, da in den Datensätzen Referenzen zum eigenen repository vorhanden sind und DaVinci::dump() (bzw. in Folge die PHPFunktion var\_dump()) nicht angewendet werden kann.
Alle Datensätze eines repositories sind Objekte einer dem Typ des repositories zugehörigen Datensatz-Klasse (CollectionRecord bzw. SimpleTreeRecord). Will
man einen Datensatz auslesen, wird über die get ()-Methode des repositories das
Datensatz-Objekt zurückgegeben. Anschließend können einzelne Werte über set ()Methoden der Datensatz-Klasse verändert werden.
A.5.3
DB-Manipulation von Einträgen
Bei einer angebundenen Datenbank stehen einige weitere Funktionen zur Verfügung
mit denen Einträge geladen, gespeichert oder gelöscht werden können. Bevor eine
Datenbank verwendet werden kann, muss die zugehörige Tabelle initialisiert werden.
Folgende Funktionen können im Fall einer angebundenen Datenbank verwendet werden:
initTable(): Die Funktion erstellt die zugehörige Tabelle im jeweiligen Datenbanksystem.
dropTable(): Die Funktion löscht die Tabelle mitsamt den Daten.
load(): Lädt einen bestimmten Datensatz ins repository. Als Parameter muss die
ID übergeben werden.
loadAll(): Diese Funktion lädt alle vorhandenen Datensätze ins repository. Als
Parameter können optional eine SQL ORDER BY- und eine LIMIT-Syntax
angegeben werden.
loadWhere(): Die Funktion lädt alle Datensätze, die bestimmte Vorraussetzungen
erfüllen. Es muss zumindest ein Parameter angegeben werden, welcher der SQL
WHERE-Syntax entspricht. Die optionalen Parameter von loadAll () sind auch
hier möglich.
unload(): Entfernt einen Datensatz aus dem repository. Ist der Eintrag auch in der
Datenbank vorhanden, wird dieser beibehalten.
unloadAll(): Entfernt alle Einträge aus dem repository.
unloadWhere(): Entfernt Einträge, bei denen ein bestimmtes Feld einen bestimmten Wert enthält. Hinweis: Die Funktion loadWhere() erfordert zum Unterschied von dieser Funktion und getWhere() einen Parameter in der Form der
SQL-WHERE Syntax.
94
modified(): Diese Funktion dient zum Überprüfen, ob ein bestimmter Eintrag geändert wurde, seitdem er von der Datenbank geladen wurde.
stored(): Die Funktion dient zum Überprüfen ob ein bestimmter Eintrag bereits in
der Datenbank gespeichert ist.
save(): Die Funktion speichert den Datensatz einer bestimmten ID, welche als Parameter angegeben werden muss.
saveAll(): Die Funktion erfordert keinen Parameter und speichert automatisch alle
geöffneten und geänderten Datensätze. Das repository merkt sich intern, ob
Einträge geändert wurden und speichert diese.
delete(): Mit dieser Funktion wird ein einzelner Eintrag aus der Datenbank und
dem repository gelöscht.
Anschließend sei ein Beispiel dargestellt, indem ein Datensatz aus einer angebundenen Datenbank eingelesen und geändert wird, ein neuer Eintrag erstellt und
alle Einträge gespeichert werden. Zuletzt wird der zuvor erstellte Eintrag wieder
gelöscht. Dieses Beispiel bezieht sich wiederum auf das repository aus den letzten
Code-Beispielen:
$ c o n t e n t −>l o a d ( 1 2 ) ;
$ r e c o r d 1 =& $ c o n t e n t −>g e t ( 1 2 ) ;
$ r e c o r d 1 −>s e t ( ' l a s t _ u p d a t e ' , time ( ) ) ;
$ r e c o r d 2 =& $ c o n t e n t −>newRecord ( ) ;
$ r e c o r d 2 −>s e t ( ' t i t l e ' , ' Welcome , ' ) ;
$ r e c o r d 2 −>s e t ( ' t e x t ' , ' t h i s ␣ i s ␣ a ␣ s i m p l e ␣ t e s t ␣ page . ' ) ;
$ c o n t e n t −>s a v e A l l ( ) ;
$newID = $ r e c o r d 2 −>i d ;
$ c o n t e n t −>delete ( $newID ) ;
A.5.4
Die Klasse RepositoryManager
Der Repository-Manager verwaltet alle registrierten repositories einer Webapplikation. Er bietet Funktionen zum Öffenen und Schließen von repositories. Benötigt eine Aktionsklasse oder ein model ein repository, kann mit dem Aufruf von
RepositoryManager::open() eine Referenz abgeholt werden. Alle geöffneten repositories bleiben während eines Requests offen. Wird dasselbe repository von einer
anderen Komponente benötigt, bekommt es vom Manager einen Referenz auf die
gleiche Instanz zurück. Somit kann von verschiedenen Ressourcen auf die selbe Instanz zugegriffen werden. Die öffentlichen Funktionen des Managers sind:
open(): Die Funktion öffnet ein registriertes repository über den angegebenen eindeutigen Bezeichner und gibt eine Referenz auf die Instanz zurück.
close(): Mit dieser Funktion kann ein repository geschlossen werden. Genaugenommen wird einfach die Instanz wieder gelöscht.
95
register(): Mit dieser Funktion können neue repositories beim Manager registriert
werden.
deregister(): Diese Funktion entfernt ein registriertes repository aus dem Masterrepository.
initMasterRepository(): Initialisiert das Master-repository. Diese Funktion muss
beim Erstellen einer neuen Webapplikation einmal aufgerufen werden. Die
Tabelle für das Master-repository wird dadurch erstellt. Die Datenbank wird
in der Konfigurationsdatei über den Parameter <masterRepository> (siehe
Abschnitt A.3.2).
Repositories registrieren
Will man ein repository dauerhaft verwenden, sollte es beim Repository-Manager
registriert werden. Das bedeutet, dass das repository anschließend über den Funktionsaufruf RepositoryManager::open() geöffnet werden kann. Im Hintergrund wird
dabei die repository-Definition samt Layout in ein spezielles Master-repository gespeichert, welches intern vom Manager verwaltet wird. Die Datenbank, indem dieses
Master-repository liegt, muss in der Konfigurationsdatei der Webapplikation über das
Element <masterRepository> angegeben werden (siehe Abschnitt A.3.2). Jede Webapplikation hat ihr eigenes Master-repository. Werden mehrere Webapplikationen
am selben Server betrieben, muss sichergestellt sein, dass für jedes ihrer Masterrepositories eine eigene Datenbank verwendet wird. Ansonsten kommt es zu Konflikten bei den Tabellen.
Die Layout-Definition wird beim Registrieren vom Framework in eine eigene
XML-Definition umgewandelt und als Textfeld im Master-repository gespeichert.
Beim Öffenen eines repositories über den Manager, wird die XML-Definition geparst
und das entsprechende Layout wird dem repository wieder zugewiesen.
Die für eine neue Webapplikation erforderlichen repositories können einerseits
direkt mit SQL-Befehlen über die Konsole des DBMS in die Tabelle geschrieben
werden. In diesem Falle muss sehr darauf geachtet werden, dass die XML-Definition
des Layouts fehlerfrei ist. Ein repository kann andererseits auch mit der vom Framework bereitgestellten API erstellt werden. Durch die API als Basis, können sehr
einfach auch dynamisch neue repositories angelegt werden.
Anhang B
Quellcode
In diesem Anhang sind einige Quellcodes der Demo-Applikation aus Kapitel 5 zum
Nachschlagen abgedruckt. Es handelt sich dabei um die Hilfsfunktion zum Erstellen
der beiden repositories, um eine Aktionsklasse und um eine model-Klasse.
96
ANHANG B. QUELLCODE
B.1
97
Hilfsaktion zum Erstellen der repositories
Der folgende Code generiert die beiden repositories links und addressbook. Es wird
ein Objekt der Klasse SimpleTree instanziert. Anschließend wird der erforderliche
data source name zugewiesen. Für das Kürzel #local_homebase existiert in der
Konfigurationsdatei der Webapplikation (siehe Anhang A, Abschnitt A.3.2, Seite
88ff) der folgende Eintrag:
<dsnMapping i d=" local_homebase ">
m y s q l : // www:www@localhost / homebase
</ dsnMapping>
Die Definition des Layouts erfolgt über eine Instanz der Klasse RepositoryLayout.
Nach Erstellen der Feld-Definitionen wird das Layout dem repository zugewiesen.
Zum Schluss wird das repository für die Verwendung der angebundenen Datenbank
initialisiert und beim Repository-Manager registriert. Die beiden repositories sind
dann über den Aufruf von RepositoryManager::open() für immer verfügbar.
// c r e a t e a d d r e s s b o o k
$ r e p = new S i m p l e T r e e R e p o s i t o r y ( ' a d d r e s s b o o k ' ) ;
$rep−>setDSN ( '#local_homebase ' ) ;
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' i s _ f o l d e r ' , DATATYPE_BOOLEAN) ;
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' folder_name ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' f i r s t n a m e ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' secondname ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' s t r e e t ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' z i p c o d e ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' c i t y ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' phone ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' c e l l p h o n e ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' e m a i l ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' i c q ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' p i c t u r e ' , DATATYPE_BLOB) ;
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' comment ' , DATATYPE_TEXT) ;
$rep−>s e t L a y o u t ( $ l a y o u t ) ;
// i n i t r e p o s i t o r y and r e g i s t e r a t manager
$rep−>i n i t T a b l e ( ) ;
RepositoryManager : : r e g i s t e r ( $rep , ' a ␣ s i m p l e ␣ a d d r e s s b o o k ' ) ;
// c r e a t e l i n k r e p o s i t o r y
$ r e p = new S i m p l e T r e e R e p o s i t o r y ( ' l i n k s ' ) ;
$rep−>setDSN ( '#local_homebase ' ) ;
ANHANG B. QUELLCODE
98
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' i s _ f o l d e r ' , DATATYPE_BOOLEAN) ;
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' is_homepage ' , DATATYPE_BOOLEAN) ;
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' folder_name ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' t i t l e ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' u r l ' , DATATYPE_VARCHAR,
$ l a y o u t −>a d d F i e l d D e f i n i t i o n ( ' comment ' , DATATYPE_TEXT) ;
$rep−>s e t L a y o u t ( $ l a y o u t ) ;
// i n i t r e p o s i t o r y and r e g i s t e r a t manager
$rep−>i n i t T a b l e ( ) ;
RepositoryManager : : r e g i s t e r ( $rep , ' s i m p l e ␣ l i n k s ␣ c o l l e c t i o n ' ) ;
r e t u r n true ;
}
B.2
SetModule als beispielhafte Aktionsklasse
Die folgende Klasse definiert die Aktion SetModule/[module_id]“ und dient zur Wahl
zwischen den Modulen homepage, [addressbook und links. Die Aktion steht über
das View-Skript mainframe.navigation_bar zur Verfügung. Es wurde ein PfadinfoParameter definiert, anhand dessen der Schalter mainframe.body im View-Baum geändert wird.
c l a s s SetModule e x t e n d s A b s t r a c t A c t i o n {
f u n c t i o n SetModule ( ) {
$ t h i s −>_addPathParamDef ( ' module_id ' , DATATYPE_VARCHAR, '
homepage ' ) ;
}
i f ( $ t h i s −>p a r a m e t e r s [ ' module_id ' ] ! = n u l l ) {
switch ( $ t h i s −>p a r a m e t e r s [ ' module_id ' ] ) {
case ' homepage ' :
ViewGenerator : : s e t S w i t c h ( ' mainframe . body ' , '
homepage ' ) ; break ;
case ' a d d r e s s b o o k ' :
ViewGenerator : : s e t S w i t c h ( ' mainframe . body ' , '
a d d r e s s b o o k ' ) ; break ;
case ' l i n k s ' :
ViewGenerator : : s e t S w i t c h ( ' mainframe . body ' , ' l i n k s ' )
; break ;
}
}
r e t u r n true ;
}
}
ANHANG B. QUELLCODE
B.3
99
Links model
Das Links-model implementiert die Applikationslogik für die Link-Datenbank. Es
bindet das links-repository an, liefert Daten an die entsprechenden View-Skripts und
verwaltet die Datenbankeinträge.
<?php
c l a s s L i n k s e x t e n d s AbstractModel {
var $ l i n k s R e p o s i t o r y ;
var $homepageUrl ;
var $ s e l e c t e d F o l d e r ;
var $ s e l e c t e d R e c o r d ;
/∗ implement c o n s t r u c t o r and a b s t r a c t f u n c t i o n s ∗/
f u n c t io n Links ( ) {
// c h e c k f o r r o o t node , c r e a t e i f i t doesn ' t e x i s t
$ t h i s −>l i n k s R e p o s i t o r y =& RepositoryManager : : open ( ' l i n k s ' ) ;
i f ( $ t h i s −>l i n k s R e p o s i t o r y −>l o a d T r e e ( ) == f a l s e )
$ t h i s −>_ i n i t L i n k s T r e e ( ) ;
// i n i t f i r s t −time s e l e c t e d f o l d e r
$ r o o t =& $ t h i s −>l i n k s R e p o s i t o r y −>getRootNode ( ) ;
$ t h i s −>s e l e c t e d F o l d e r = $ r o o t −>i d ;
// i n i t homepage u r l
$ r e c o r d =& $ t h i s −>l i n k s R e p o s i t o r y −>getWhere ( ' is_homepage ' , true
);
i f ( $ r e c o r d ! = n u l l ) $ t h i s −>homepageUrl = $ r e c o r d −>g e t ( ' u r l ' ) ;
}
function requestInit () {
$ t h i s −>l i n k s R e p o s i t o r y =& RepositoryManager : : open ( ' l i n k s ' ) ;
}
f u n c t i o n _loadTree ( ) {
i f ( $ t h i s −>l i n k s R e p o s i t o r y −>l o a d T r e e ( ) == f a l s e )
$ t h i s −>_ i n i t L i n k s T r e e ( ) ;
}
f u n c t i o n requestEnd ( ) { }
/∗ p r i v a t e f u n c t i o n s ∗/
function _initLinksTree () {
$ r o o t =& $ t h i s −>l i n k s R e p o s i t o r y −>createRootNode ( ) ;
$ r o o t −>s e t ( ' i s _ f o l d e r ' , true ) ;
$ r o o t −>s e t ( ' is_homepage ' , f a l s e ) ;
$ r o o t −>s e t ( ' folder_name ' , ' bookmarks ' ) ;
$ t h i s −>l i n k s R e p o s i t o r y −>s a v e A l l ( ) ;
$ t h i s −>s e l e c t e d F o l d e r = $ r o o t −>i d ;
}
/∗ s e r v e v i e w d a t a ∗/
f u n c t i o n getViewData ( $ v i e w I d ) {
switch ( $ v i e w I d ) {
ANHANG B. QUELLCODE
100
case " mainframe . body . l i n k s . t r e e " :
$ t h i s −>_loadTree ( ) ;
r e t u r n Array ( ' c u r r e n t _ f o l d e r ' => $ t h i s −>s e l e c t e d F o l d e r
, ' t r e e ' => $ t h i s −>l i n k s R e p o s i t o r y ) ;
break ;
case " mainframe . body . l i n k s . r i g h t _ c a n v a s . f o l d e r " :
$ r e c o r d s = Array ( ) ;
$ t h i s −>l i n k s R e p o s i t o r y −>beginTreeWalkWhere ( ' i s _ f o l d e r '
, f a l s e , $ t h i s −>s e l e c t e d F o l d e r , f a l s e , 1 ) ;
while ( $ r e c o r d =& $ t h i s −>l i n k s R e p o s i t o r y −>nextNode ( ) )
$records [ ] = $record ;
r e t u r n Array ( ' r e c o r d s ' => $ r e c o r d s , ' f o l d e r ' => $ t h i s −>
l i n k s R e p o s i t o r y −>g e t ( $ t h i s −>s e l e c t e d F o l d e r ) ) ;
break ;
case " mainframe . body . l i n k s . r i g h t _ c a n v a s . e d i t _ f o l d e r " :
$ t h i s −>l i n k s R e p o s i t o r y −>l o a d ( $ t h i s −>s e l e c t e d F o l d e r ) ;
$ r e c o r d = $ t h i s −>l i n k s R e p o s i t o r y −>g e t ( $ t h i s −>
selectedFolder ) ;
return $record ;
break ;
case " mainframe . body . l i n k s . r i g h t _ c a n v a s . e d i t _ r e c o r d " :
$ t h i s −>l i n k s R e p o s i t o r y −>l o a d ( $ t h i s −>s e l e c t e d R e c o r d ) ;
$ r e c o r d = $ t h i s −>l i n k s R e p o s i t o r y −>g e t ( $ t h i s −>
selectedRecord ) ;
return $record ;
break ;
case " mainframe . body . homepage " :
r e t u r n ( s t r l e n ( $ t h i s −>homepageUrl ) > 0) ? $ t h i s −>
homepageUrl : ' about : b la n k ' ;
break ;
default : r e t u r n n u l l ;
break ;
}
}
/∗ p u b l i c f u n c t i o n s ∗/
function s e l e c t F o l d e r ( $id ) {
$ t h i s −>s e l e c t e d F o l d e r = $ i d ;
}
function selectRecord ( $id ) {
$ t h i s −>s e l e c t e d R e c o r d = $ i d ;
}
function createRecord () {
$ p a r e n t =& $ t h i s −>l i n k s R e p o s i t o r y −>g e t ( $ t h i s −>s e l e c t e d F o l d e r ) ;
$ r e c o r d =& $ t h i s −>l i n k s R e p o s i t o r y −>c r e a t e C h i l d N o d e ( $ p a r e n t ) ;
$ r e c o r d −>s e t ( ' i s _ f o l d e r ' , f a l s e ) ;
$ r e c o r d −>s e t ( ' is_homepage ' , f a l s e ) ;
$ r e c o r d −>s e t ( ' t i t l e ' , ' new␣ l i n k ' ) ;
$ t h i s −>s e l e c t e d R e c o r d = $ r e c o r d −>i d ;
}
function createFolder () {
ANHANG B. QUELLCODE
101
$ p a r e n t =& $ t h i s −>l i n k s R e p o s i t o r y −>g e t ( $ t h i s −>s e l e c t e d F o l d e r ) ;
$ r e c o r d =& $ t h i s −>l i n k s R e p o s i t o r y −>c r e a t e C h i l d N o d e ( $ p a r e n t ) ;
$ r e c o r d −>s e t ( ' i s _ f o l d e r ' , true ) ;
$ r e c o r d −>s e t ( ' is_homepage ' , f a l s e ) ;
$ r e c o r d −>s e t ( ' folder_name ' , ' new␣ f o l d e r ' ) ;
$ t h i s −>s e l e c t e d F o l d e r = $ r e c o r d −>i d ;
}
f u n c t i o n s a v e F o l d e r ( $folder_name ) {
$node =& $ t h i s −>l i n k s R e p o s i t o r y −>g e t ( $ t h i s −>s e l e c t e d F o l d e r ) ;
$node−>s e t ( ' folder_name ' , $folder_name ) ;
}
f u n c t i o n saveRecord ( $ t i t l e , $ u r l , $comment , $is_homepage ) {
$node =& $ t h i s −>l i n k s R e p o s i t o r y −>g e t ( $ t h i s −>s e l e c t e d R e c o r d ) ;
$node−>s e t ( ' t i t l e ' , $ t i t l e ) ;
$node−>s e t ( ' u r l ' , $ u r l ) ;
$node−>s e t ( ' comment ' , $comment ) ;
$prevHome =& $ t h i s −>l i n k s R e p o s i t o r y −>getWhere ( ' is_homepage ' ,
true ) ;
i f ( $is_homepage ) {
$ t h i s −>homepageUrl = $ u r l ;
i f ( $prevHome ) $prevHome−>s e t ( ' is_homepage ' , f a l s e ) ;
} else {
i f ( ! $prevHome | | $prevHome−>i d == $node−>i d ) $ t h i s −>
homepageUrl = ' ' ;
}
$node−>s e t ( ' is_homepage ' , $is_homepage ) ;
}
}
?>
Inhalt der CD-ROM
Die CD-ROM enthält zum einen die Diplomarbeit im PDF-Format und einige zitierte
Dokumente, sofern im Literaturverzeichnis angegeben. Zum anderen ist darauf die
Distribution des DaVinci Prototypen zu finden. Eine kurze Installationsanweisung
befindet sich in der Datei README im Verzeichnis der Distribution.
Die Verzeichnisinhalte im Detail:
phpdavinci: Der DaVinci Prototyp inklusive Installationsanweisung.
thesis: Die Diplomarbeit als PDF-Dokument und zitierte Dokumente.
essentials: Einige tools wie Apache, MySQL und PHP.
102
Literaturverzeichnis
[AMM98] Atzeni, P., G. Mecca und P. Merialdo: Design and Implementation of Data-Intensive Web Sites. In: Conference On Extended Database
Technology (EDBT’98), Valencia, Spanien, März 1998.
[BGP01] Baresi, Luciano, Franca Garzotto und Paolo Paolini: Extending
UML for Modeling Web Applications. In: 34th Hawaii International Conference on System Sciences (HICSS-2001), Maui, Hawaii, Januar 2001. IEEE
Internet Society. Kopie auf CD-ROM.
[BKM99] Baumeister, Hubert, Nora Koch und Luis Mandel: Towards a
UML Extension for Hypermedia Design. In: UML ’99, Seiten 28–30, Fort
Collins, Colorado, USA, Oktober 1999. Kopie auf CD-ROM.
[BM98]
Baumeister, Hubert und Christoph Maier: Description Techniques
for Distributed Hypermedia Systems. Technischer Bericht 9808, Institut für
Informatik der Ludwig Maximilian Universität München, München, 1998.
Kopie auf CD-ROM.
[Boo01]
Booch, Grady: The architecture of Web applications. URL, http://www.
ibm.com/developerworks/library/it-booch_web/, Juni 2001. Kopie auf CDROM.
[Cer02]
Cerami, Ethan: Web Services Essentials. O’Reilly, Sebastopol, CA,
USA, 2002.
[CFM02] Cero, Stefano, Piero Fraternali und Maristella Matera: Conceptual Modeling of Data-Intensive Web Applications. In: IEEE Internet
Computing, Seiten 20–30. IEEE Computer Society, Los Alamitos, CA,
USA, Juli/August 2002. Kopie auf CD-ROM.
[CFP99] Ceri, S., P. Fraternali und S. Paraboschi: Design Principles for
Data-Intensive Web Sites. In: SIGMOD Record, Band 24. März 1999.
[Che76]
Chen, P.: The Entity-Relationship Model – Toward a Unified View of
Data. ACM Transactions on Database Systems, 1(1):9–36, März 1976.
Kopie auf CD-ROM.
[Con99] Conallen, Jim: Modeling Web Applications with UML. In: Communications of the ACM, Band 42, Seiten 63–70. ACM Press, New York, Oktober
1999. Kopie auf CD-ROM.
103
LITERATURVERZEICHNIS
104
[Con03] Conallen, Jim: Building Web Applications with UML. Addison-Wesley,
Boston, MA, USA, 2 Auflage, 2003.
[Cym00] Cymerman, Michael:
Secure a Web application, Java-style.
URL, http://www-106.ibm.com/developerworks/java/library/j-jw-javastyle.
html, Mai 2000. Kopie auf CD-ROM.
[FGM+ 99] Fielding, R., J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach und T. Berners-Lee: Hypertext Transfer Protocol –
HTTP/1.1. URL, http://www.ietf.org/rfc/rfc2616.txt, Juni 1999. Kopie
auf CD-ROM.
[Fie00]
Fielding, Roy Thomas: Architectural Styles and the Design of Networkbased Software Architectures. Doktorarbeit, University of California, 2000.
[Fra00]
Fraternali, P.: Tools and Approaches for Data-intensive Web applications: A Survey. In: ACM Computing Society. ACM Press, 2000.
[FSK+ 02] Finkelstein, Anthony, Andrea Savigni, Gerti Kappel, Werner Retschitzegger, Brirgit Pöll, Wieland Schwinger, Thomas
Hofer und Christian Feichtner: Ubiquitous Web Application Development – A Framework for Understanding. In: The 6th Multiconference
on Systemics, Cybernetics and Informatics (SCI2002), Web-Engineering
Track, Orlando, Florida, USA, Juli 2002. Kopie auf CD-ROM.
[FV01]
Flurry, Greg und Wayne Vicknair: Technology for e-busines: The
IBM Application Framework for e-business. IBM Systems Journal, 40(1),
[Gam94] Gamma, Erich: Design Patterns: Elements of Reusable Object-Oriented
Software. Addison-Wesley, Boston, MA, USA, 1994.
[GC00]
German, D. und D. Cowan: Towards a Unified Catalog of Hypermedia Design Patterns. In: 33rd Hawaii International Conference on System
Sciences (HICSS 2000), Band 6, Maui, Hawaii, Jänner 2000. Kopie auf
CD-ROM.
[GM01]
Ginige, Athula und San Murugesan: The Essence of Web Engineering. In: IEEE MultiMedia, Seiten 22–25. IEEE Computer Society, Los
Alamitos, CA, USA, April-Juni 2001. Kopie auf CD-ROM.
[GPS95] Garzotto, F., P. Paolini und D. Schwabe: HDM – A Model-Based
Approach to Hypertext Application Design. In: ACM Transactions on Information Systems, Band 11. ACM Press, New York, Januar 1995.
[HC98]
Hunter, Jason und William Crawford: Java Servlet Programming.
O’Reilly, Sebastopol, CA, USA, 1998.
[HL02]
Hightower, Richard und Nicholas Lesiecki: Java Tools for Extreme
Programming. Wiley, New York, 2002.
[HS94]
105
Halasz, Frank und Mayer Schwartz: The Dexter hypertext reference
model. Communications of the ACM, 37(2):30–39, 1994. Kopie auf CDROM.
[Hun97] Hunt, J.: Smalltalk and Object Orientation: An Introduction. Springer,
1997.
[Hun01] Hunter, Jason: Java Servlet Programming. O’Reilly, Sebastopol, CA,
USA, 2. Auflage, 2001.
[KD02]
Knight, Alan und Naci Dai: Objects and the Web. In: IEEE Software,
Seiten 51–59. IEEE Computer Society, Los Alamitos, CA, USA, März/April 2002. Kopie auf CD-ROM.
[KK02]
Koch, N. und A. Kraus: The Expressive Power of UML-based Web Engineering. In: CYTED (Herausgeber): Second Int. Workshop on WebOriented Software Technology (IWWOST ’02), Seiten 105–120, Malaga,
Juni 2002.
[Kra00]
Krause, Jörg: PHP 4 – Grundlagen und Profiwissen. Hanser, München,
2000.
[KRP+ 02] Kappel, Gerti, Werner Retschitzegger, Birgit Pröll,
Rainer Unland und Bahram Vojdani: Architektur von WebInformationssystemen. In: Rahm, Erhard und Gottfried Vossen
(Herausgeber): Web & Datenbanken. Dpunkt Verlag, Heidelberg, 2002.
Kopie auf CD-ROM.
[LCC00] Li, Jingfeng, Jian Chen und Ping Chen: Modeling Web Application
Architecture with UML. In: 36th International Conference on Technology
of Object-Oriented Languages and Systems (TOOLS-Asia’00), Seiten 265–
274, Xi’an, China, Oktober/November 2000. Kopie auf CD-ROM.
[LCC+ 03] Leiner, Barry M., Vinton G. Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock, Daniel C. Lynch, Jon Postel,
Larry G. Roberts und Stephen Wolff: A Brief History of the Internet. URL, http://www.isoc.org/internet/history/brief.shtml, August 2003.
Kopie auf CD-ROM.
[LHSG02a] Lowe, David, Brian Henderson-Sellers und Alice Gu: Web Extensions to UML: Using the MVC Triad. In: Lecturer Notes in Computer
Science, Band 2503, Seiten 55–69. Springer Verlag, Heidelberg, 2002. Kopie
auf CD-ROM.
[LHSG02b] Lowe, David, Brian Henderson-Sellers und Alice Gu: Web Modelling Languages: the gap between requirements and current exemplars. In:
Australien Web Conference (AUSWEB02), Queensland, Juli 2002. Kopie
auf CD-ROM.
[Li03]
Li, Sing: High-impact Web tier clustering, Part 1: Scaling Web services and applications with JavaGroups. URL, http://www-106.ibm.com/
developerworks/java/library/j-cluster1/, Juli 2003. Kopie auf CD-ROM.
106
[Nie99]
Nielsen, J.: Designung Web Usability. New Riders Publishing, Indianapolis, 1999.
[Pre02]
Prescod, Paul: Second Generation Web Services. URL, http://
webservices.xml.com/pub/a/ws/2002/02/06/rest.html, Februar 2002. Kopie
auf CD-ROM.
[PSRO02] Pastor, Oscar, Daniel Schwabe, Gustavo Rossi und Luis Olsina:
Web-Oriented Software Technolgy. In: Hernàndez, J. und A. Moreira
(Herausgeber): ECOOP 2002 Workshops, Band 2548 der Reihe Lecture
Notes in Computer Science. Springer-Verlag, Heidelberg, 2002. Kopie auf
CD-ROM.
[Qus03]
Qusay, H. Mahmoud:
Servlets and JSP Pages Best Practices.
URL, http://developer.java.sun.com/developer/technicalArticles/
javaserverpag%es/servlets_jsp/, März 2003. Kopie auf CD-ROM.
[Rad02] Radwin, Michael J.: Making the Case for PHP at Yahoo! Vortrag auf
der PHP Conference 2002 in Millbrae, Kalifornien, Oktober 2002. Kopie
der Folien auf CD-ROM.
[RBP+ 91] Rumbaugh, James, Michael Blaha, William Premerlani, Frederick Eddy und William Lorensen: Object-Oriented Modeling and
Design. Prentice Hall, New York, 1991.
[REL01] Rossi, Gustavo, Luiselena Esmeraldo und Fernando Lyardet:
Engineering Web Applications for Reuse. In: IEEE MultiMedia, Seiten 20–
31. IEEE Computer Society, Los Alamitos, CA, USA, Januar-März 2001.
Kopie auf CD-ROM.
[RJB99] Rumbaugh, James, Ivar Jacobson und Grady Booch: The Unified
Modeling Language Reference Manual. Addison-Wesley, Boston, MA, USA,
1999.
[RO02]
Rossi, G. und L. Olsina: A Quantitative Method for Quality Evaluation of Web Sites and Applications. In: IEEE MultiMedia, Band 9. IEEE
Computer Society, Los Alamitos, CA, USA, 2002. Kopie auf CD-ROM.
[RS00]
Retschitzegger, Werner und Wieland Schwinger: Towards Modeling of Data Web Applications – A Requirements’ Perspective. In: Proceedings of the Americas Conference on Information Systems (AMCIS 2000),
Band 1, Seiten 149–155, Long Beach, CA, USA, August 2000. Kopie auf
CD-ROM.
[RSG99] Rossi, G., D. Schwabe und A. Garrido: Designing Computational Hypermedia Applications. In: Journal of Digital Information (JODI), Band 1.
Department of Information and Library Studies, Loughborough University,
UK, Februar 1999.
[Sau94]
Sauer, Hermann: Relationale Datenbanken:
Addison-Wesley, München, 3. Auflage, 1994.
Theorie und Praxis.
[Sch03]
107
Schotte, Björn: PHP im E-Business. Vortrag auf der CeBit 2003 in
Hannover, 2003. Kopie der Folien auf CD-ROM.
[SRB03] Schwabe, Daniel, Gustavo Rossi und Simone Barbosa: Abstraction, Composition and Lay-Out Definition Mechanisms in OOHDM. URL,
http://www-di.inf.puc-rio.br/∼schwabe//MM95/MainPage.html, Juli 2003.
Kopie auf CD-ROM.
[SS02]
Schmidt, Stephan und Gerd Schaufelberger: Brücke an Maschinenraum: Interprozesskommunikation mit PHP4 und Shared Memory.
PHP Magazin, 1, 2002.
[SSJ02]
Singh, Inderjeet, Beth Stearns und Mark Johnson: Designing
Enterprise Applications with the J2EE Platform. Addison-Wesley, Boston,
MA, USA, 2002. Kopie auf CD-ROM.
[St02]
Schwinger, Wieland und the UWA Consortium: Ubiquitous Web
Applications. In: Proceedings of the eBusiness and eWorks Conference (e2002), Prag, Oktober 2002. Kopie auf CD-ROM.
[Sun02a] Sun Microsystems: Dynamic Web Applications at a Glance. URL,
http://java.sun.com/programs/solution-templates/pdf/DynamicWebR4.pdf,
[Sun02b] Sun Microsystems: Java BluePrints – Model-View-Controller. URL,
http://java.sun.com/blueprints/patterns/MVC-detailed.html, 2002. Kopie
auf CD-ROM.
[Sun03]
Sun Microsystems: Java Server Pages – Tag Libraries. URL, http:
//java.sun.com/products/jsp/taglibraries.html, Juli 2003.
[SW00]
Smith, Conny U. und Lloyd G. Williams: Building Responsive and
Scalable Web Applications. In: Computer Measurement Group’s 2000 International Conference (CMG2000), Orlando, Florida, USA, Dezember 2000.
Software Engineering Research and L&S Computer Technology, Inc. Kopie
auf CD-ROM.
[The03a] The PHP Group: PHP Dokumentation. URL, http://www.php.net/
manual/de/, August 2003. Kopie auf CD-ROM.
[The03b] The PHP Group: PHP Usage for June 2003. URL, http://www.php.
net/usage.php, Juni 2003.
[Tho96] Thompson, Della (Herausgeber): The Oxford Quick Reference Dictionary. Oxford University Press, 1996.
[Ude02]
Uden, Lorna: Design Process for Web Applications. In: IEEE MultiMedia, Seiten 47–55. IEEE Computer Society, Los Alamitos, CA, USA,
Oktober-Dezember 2002. Kopie auf CD-ROM.
[W3C99] W3C: HTML 4.01 Specification. URL, http://www.w3.org/TR/HTML4,
Dezember 1999. Kopie auf CD-ROM.
108
[W3C02] W3C: Web Services Architecture Requirements. URL, http://www.w3.org/
TR/wsa-reqs, November 2002.
[WHK97] Wahl, M., T. Howes und S. Kille: Lightweight Directory Access Protocol (v3). URL, http://www.ietf.org/rfc/rfc2251.txt, Dezember 1997. Kopie
auf CD-ROM.
[Zen01]
Zend Technologies Ltd.: Zend Engine 2.0 Design Draft. URL, http:
//www.zend.com/engine2/ZendEngine-2.0.pdf, 2001. Kopie auf CD-ROM.
[Zol01]
Zoltan, Erik: Server-side scripting languages. URL, http://www-106.
ibm.com/developerworks/web/library/wa-sssl.html, April 2001. Kopie auf
CD-ROM.