paper

Transcription

paper

TU Wien
Business Informatics Group
Institut für Softwaretechnik und Interaktive Systeme
Ubiquitäre Web-Anwendungen
Entwicklung endgeräteunabhängiger Lösungsansätze
Magisterarbeit zur Erlangung des akademischen Grades eines
Magister der Sozial- und Wirtschaftswissenschaften
(Mag. rer. soc. oec.)
eingereicht bei o. Univ.-Prof. Mag. Dipl.-Ing. Dr. Gerti Kappel
Mitbetreuung: Mag. Andrea Schauerhuber
Rudolf Mayer
Wien, 2. Februar 2007
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne
fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die
den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche
kenntlich gemacht habe.
Wien, 2. Februar 2007
ii
Danksagung
Ich danke meinen Eltern Inge und Rudolf Mayer dafür, dass sie mir durch ihre
finanzielle und moralische Unterstützung mein Studium ermöglicht haben.
Für die gute Betreuung und die nützlichen Anregungen bei der Erstellung
dieser Magisterarbeit möchte ich mich bei Mag. Andrea Schauerhuber und
o. Univ.-Prof. Mag. Dipl.-Ing. Dr. Gerti Kappel bedanken.
Ein ganz besonderes Dankeschön geht an Arnold Weissensteiner und Petra
Brosch für die gute Zusammenarbeit während der gesamten Studienzeit und speziell während dieser Magisterarbeit.
iii
Kurzfassung
Ubiquitäre Web-Anwendungen haben das anytime/anywhere/anymedia Paradigma zugrunde liegen, und sollen dem Anwender, egal wann, wo und mit welchem
Gerät er diese nutzt, einen individuell abgestimmten und auf die Rahmenbedingungen des Benutzers angepassten Inhalt bieten.
Im Rahmen einer Kooperation von drei Magisterarbeiten, [Bros06,Weis06] und
der vorliegenden Arbeit, wurde ein ubiquitäres Tourismusinformationssystem entwickelt. Das Ziel dieses umfangreichen Projekts war die Konzeption, Modellierung
und Implementierung einer Web-Anwendung mit Customizationunterstützung,
dh. einer Web-Anwendung, die aufgrund mehrerer Kontextfaktoren wie Benutzer, Zeit, Ort, Gerät, etc., mit der Adaptierung ihrer Dienste reagiert. Die Implementierung der Customizationfunktionalität ist allerdings komplex, da sie an
vielen Stellen der Web-Anwendung Berücksichtigung finden muss und sich quer
durch den Code des Systems zieht. Separation of Concerns ist daher im Sinne der
Wartbarkeit, Erweiterbarkeit und Änderbarkeit eines Systems anzustreben.
Im speziellen Fokus dieser Arbeit stand der anymedia Aspekt von ubiquitären
Web-Anwendungen. Die Anpassung der Web-Anwendung an die technischen Kontextfaktoren des Endgeräts unter besonderer Berücksichtigung der verschiedenen
Techniken zur Erkennung der Eigenschaften des Endgeräts, wurde untersucht.
Anschließend wurden die Adaptierungstechniken für die Anpassung der Inhalte
evaluiert und im Rahmen eines praktischen Prototyps umgesetzt.
Die Adaptierung an das Endgerät ist Teil der Customization der ubiquitären
Web-Anwendung und zieht sich somit als Crosscutting Concern durch die gesamte
Anwendung. Speziell im Hinblick auf die Endgerätunabhängigkeit gilt es schon
von Beginn an genau festzulegen, welche Inhalte wie granular und mit welchen
Metainformationen gespeichert werden. Weiters ist es wichtig, im Hinblick auf
die nötigen Adaptierungstechniken festzulegen, welche Authoring Methode zum
Einsatz kommt. Ebenso notwendig für die Adaptierung ist die Erkennung der
Geräteeigenschaften, denn in Abhängigkeit dieser erfolgt die eigentliche Selektion
und Aggregation der Inhalte und anschließend die Transformation der Darstellung
an die Einschränkungen des Endgeräts.
iv
Abstract
Ubiquitous web applications adhering to the anytime/anywhere/anymedia paradigm are required to yield a customized service in respect of the user’s context.
As a cooperation of three master theses, [Bros06,Weis06] an my own thesis, we
have developed a ubiquitous tourism information system. Our intention was to
design and implement a ubiquitous web application with customization support,
i.e., a web application which adapts its services according to several context
properties such as user, time, location, device, etc. However implementation of
customization support is complex. Customization has to be considered at many
places throughout the web application and thus, is scattered across the code of
the whole system. To reach better maintainability, extensibility and changeability
of the system, one should thus aspire separation of concerns.
The main focus of this work was the anymedia aspect of ubiquitous web applications, including the adaptation of the web application’s services according to
several technical context properties. In this respect, techniques for detecting the
distinguishing capabilities of mobile devices as well as the evaluation and implementation of an appropriate combination of several adaptation techniques have
been considered.
Adaptation of a web application’s services with respect to the device used to access the web application is part of the customization process, which is a so-called
crosscutting concern, meaning it can’t be encapsulated by conventional methods
of modularization. Due to this fact it is necessary to determine the level of granularity in the data model and what metainformation is required in the beginning of
the development process. Focusing on the need of appropriate adaptation techniques, it is also essential to choose a proper authoring method. Furthermore
detecting the device context is the most essential issue and represents the basis
of the adaptation process. Depending on the device context at runtime, the selection and aggregation of content takes place, as well as the following selection
of a proper layout or presentation template and the concluding transformation of
content.
v
1
Inhaltsverzeichnis
1 Einleitung
1.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ziel der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Web Engineering
2.1 Historische Entwicklung von Web-Anwendungen
2.1.1 Generationen von Web-Anwendungen . .
2.2 Ubiquitäre Web-Anwendungen . . . . . . . . . .
2.2.1 Customization . . . . . . . . . . . . . . .
2.2.2 Kontext . . . . . . . . . . . . . . . . . .
2.2.3 Adaptierung . . . . . . . . . . . . . . . .
2.2.4 Mapping - Customizationregeln . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
7
8
8
9
10
15
19
19
3 Endgeräteunabhängige Lösungsansätze
21
3.1 Methoden zur Erkennung der Geräteeigenschaften von Endgeräten 22
3.1.1 HTTP Request Header . . . . . . . . . . . . . . . . . . . . 23
3.1.2 Composite Capabilities/Preferences Profile . . . . . . . . . 25
3.1.3 User Agent Profile . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Techniken zur Erstellung von Inhalten für ubiquitäre WebAnwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Adaptierungsansätze für Endgerätunabängigkeit von ubiquitären
Web-Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 Ort der Adaptierung . . . . . . . . . . . . . . . . . . . . . 32
3.3.2 Adaptierungstechniken . . . . . . . . . . . . . . . . . . . . 34
4 Technische Konzeption und Funktionsumfang des entwickelten Tourismusinformationssystems
4.1 Allgemeine Beschreibung . . . . . . . . . . . . . . . . . . . . . . .
4.2 Basisfunktionalität . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Funktionen für den Endbenutzer (Frontend) . . . . . . . .
4.2.2 Funktionen für die Redaktion (Backend) . . . . . . . . . .
4.3 Evaluierung der Customizationfunktionalität . . . . . . . . . . . .
40
40
41
41
44
46
Inhaltsverzeichnis
.
.
.
.
.
.
46
50
55
55
56
59
.
.
.
.
.
.
.
.
.
.
.
63
63
68
70
70
72
73
75
75
78
83
85
6 Conclusio
6.1 Erfahrungsbericht . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
87
88
A Sourcecode Statistik
90
B Ant Build Konfiguration
91
C Screenshots Frontend
94
D Screenshots Backend
97
4.4
4.5
4.3.1 Charakteristik des Kontext . . . . . .
4.3.2 Charakteristik der Adaptierung . . .
Architektur . . . . . . . . . . . . . . . . . .
4.4.1 Schichten-Architektur der realisierten
4.4.2 Datenbank-Schema . . . . . . . . . .
Adaptierungsszenario . . . . . . . . . . . . .
2
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
Web-Anwendung
. . . . . . . . . .
. . . . . . . . . .
5 Implementierung
5.1 Verwendete Technologien . . . . . . . . . . . . . . . . . . .
5.2 Allgemeine Beschreibung . . . . . . . . . . . . . . . . . . .
5.3 Adaptierung hinsichtlich des Endgeräts . . . . . . . . . . .
5.3.1 Erkennung der Kontextfaktoren . . . . . . . . . . .
5.3.2 Aggregation und Selektion von Inhalten und Layout
5.3.3 Transformation . . . . . . . . . . . . . . . . . . . .
5.4 Implementierung der Adaptierung mit Hilfe von Aspekten
5.4.1 Kontextaspekt . . . . . . . . . . . . . . . . . . . . .
5.4.2 Adaptierung des Inhalts . . . . . . . . . . . . . . .
5.4.3 Transformationsaspekt . . . . . . . . . . . . . . . .
5.5 Kritische Würdigung . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
E Relevante MIME-Typen
101
F UAProf Profil des Nokia 6230i
102
Tabellenverzeichnis
110
Listings
111
Abbildungsverzeichnis
112
Inhaltsverzeichnis
Literaturverzeichnis
3
114
4
Kapitel 1
Einleitung
Die immer weiter steigende Verbreitung des World Wide Web bringt ständig
neue Herausforderungen mit sich. War es früher das Ziel mit einer umfassenden
Web-Anwendung die Anforderungen möglichst vieler Benutzer auf einmal abzudecken, so versucht man heute vermehrt, jedem Benutzer seine eigene, speziell auf
ihn abgestimmte, Web-Anwendung zu liefern. Diese Art von Web-Anwendungen
nennt man ubiquitäre Web-Anwendungen, ihnen liegt das anytime/anywhere/anymedia Paradigma zugrunde. Während die permanente Verfügbarkeit (anytime) in der Natur des Webs liegt und nichts Neues ist, werden ubiquitäre WebAnwendungen durch die Charakteristika anywhere und anymedia geprägt. Diese
Arbeit beschäftig sich vor allem mit dem anymedia Aspekt von ubiquitären WebAnwendungen.
Die Anpassung einer Web-Anwendung an ihren Nutzungskontext heißt Customization. Customization beinhaltet die Akquisition und Aufbereitung des aktuellen Kontext, sowie die Adaptierung, also die eigentliche Anpassung. Diese
Adaptierung erfolgt mit Hilfe eines Regelsystems, in dem sinnvolle Anpassungen
der Web-Anwendung aufgrund verschiedener Kontextfaktoren definiert sind.
1.1 Problem
Die Entwicklung von ubiquitären Web-Anwendungen ist komplex. Das liegt daran, dass Customization an jeder Stelle der Web-Anwendung denkbar ist. Bei der
Entwicklung ubiquitärer Web-Anwendungen muss daher nach [FSK+ 02,SSK+ 06],
im Vergleich zum herkömmlichen“ Web-Engineering, zusätzlich zu den be”
kannten Dimensionen Levels (dh. Content-, Hypertext-, und PräsentationsLevels von Web-Anwendungen), Features (dh. Struktur und Verhalten von WebAnwendungen) und Phases (dh. die Entwicklungsphasen von Web-Anwendungen)
die Customization als eigene Dimension berücksichtigt werden.
1 Einleitung
5
Customization zieht sich durch die gesamte Web-Anwendung. Beginnend mit
der Erkennung des Nutzungskontext, der Auswertung der relevanten Kontextfaktoren, Selektion der passenden Inhalte und Adaptierung der Darstellung an das
jeweilige Endgerät. Gerade die Adaptierung an das Endgerät des Benutzers stellt
eine besondere Herausforderung dar. Denn die Vielfalt an möglichen Endgeräten
nimmt ein immer größeres Maß an. Die Erkennung der Eigenschaften des Endgeräts ist somit eine wichtige Grundvoraussetzung für die Customization, denn in
Abhängigkeit von den erkannten Eigenschaften des Geräts sollen Struktur, Inhalt
und Darstellung entsprechend adaptiert werden.
1.2 Ziel der Arbeit
In dieser Arbeit werden verschiedene Ansätze zur Endgerätunabhängigkeit von
Web-Anwendungen evaluiert. Endgerätunabhängige Lösungsansätze für ubiquitäre Web-Anwendungen sind ein Teil der Customization und ziehen sich somit
durch die ganze Web-Anwendung.
Die schon erwähnte Erkennung der Geräteeigenschaften ist ein wichtiger Teil
davon. Dennoch besteht der Prozess der Adaptierung einer ubiquitären WebAnwendung an die Eigenschaften des Endgeräts aus mehreren mindestens ebenso
wichtigen Schritten. Das umfasst auch Entscheidungen die schon bei der Konzeption und dem Design der Web-Anwendung getroffen werden müssen. Dabei
ist es vor allem wichtig wie die Inhalte für die Web-Anwendung erstellt werden.
In weiterer Folge ist es aber auch nötig zu wissen welche verschiedenen Arten
von Inhalten existieren, um die richtigen Adaptierungstechniken zu wählen, welche für die Transformation der Darstellung verantwortlich sind. Dennoch ist die
Adaptierung an das Endgerät nur ein Teil der Customization einer ubiquitären
Web-Anwendung in der neben dem technischen Kontext des Endgeräts auch der
soziale Kontext des Benutzers und der natürliche Kontext der Nutzungsumgebung eine zentrale Rolle spielen.
Im Zuge dieser Arbeit wurde ein ubiquitäres Tourismusinformationssystem konzipiert und implementiert. Die Entwicklung des Tourismusinformationssystems
geschah in Zusammenarbeit mit Petra Brosch [Bros06] und Arnold Weissensteiner [Weis06]1 .
Bevor das Tourismusinformationssystem und seine Funktionalitäten vorgestellt
werden (Kapitel 4), gibt diese Arbeit eine Einführung in die theoretischen Grundlagen von ubiquitären Web-Anwendungen (Kapitel 2) und eine Vorstellung der
1
Aus dieser Zusammenarbeit resultieren zudem teilweise ähnliche bzw. idente Texte, deshalb
findet sich eine genaue Zuordnung von Textpassagen zum jeweiligen Autor in Tabelle B.1.
1 Einleitung
6
möglichen Ansätze zur Adaptierung des Tourismusinformationssystems an die
Engeräte der Benutzer (Kapitel 3). Die Implementierungsdetails zur Customization und im Speziellen der Adaptierung des Tourismusinformationssystems an
die Engeräte sind Gegenstand von (Kapitel 5). In Kapitel 6 werden die gewonnen Erkenntnisse bezüglich der Endgerätunabhängigkeit von ubiquitären WebAnwendungen abschließend zusammengefasst.
7
Kapitel 2
Web Engineering
Das Internet, im Speziellen das World Wide Web (WWW), ist aus unserem Alltag
kaum mehr wegzudenken. Das WWW ist bereits in nahezu allen Bereichen unseres
Lebens ein fester Bestandteil, ganz gleich ob in Beruf oder Freizeit. Es hat nicht
nur unsere Gesellschaft nachhaltig beeinflusst, sondern hat auch eine neue Ära
der Informatikdisziplin eingeleitet. Zu Beginn stellte das WWW ein dokumentenzentriertes read-only“ Informationsmedium mit statischen Inhalten dar. Heute
”
wird das Web immer mehr für vollwertige, komplexe Anwendungen genutzt, die
interaktive, datenintensive und personalisierbare Dienste zur Verfügung stellen
und über verschiedene Endgeräte erreicht werden können. Web-Anwendungen
unterscheiden sich von herkömmlichen Softwaresystemen in erster Linie durch
ihren Einsatz im Web. In [KPRR04] wird der Begriff Web-Anwendung wie folgt
definiert:
Eine Web-Anwendung ist ein Softwaresystem, das auf Spezifikationen des World Wide Web Consortium (W3C) beruht und Webspezifische Ressourcen, wie Inhalte und Dienste bereitstellt, die über
eine Benutzerschnittstelle, den Web-Browser, verwendet werden.
Eine Web-Anwendung ist somit ein Softwaresystem, das von Beginn an für den
Einsatz im WWW entwickelt wird und somit den Hypermedia Aspekt1 , also
die Kombination von Hypertext, Multimedia und Anwendungslogik, mit einbezieht. Eine Menge von Web-Seiten sind erst dann eine Web-Anwendung, wenn sie
über das klassische Request-Response Paradigma hinausgehen und zustandsbasiert sind, also den Einsatz einer Session erfordern [FSK+ 02].
1
In diesem Kapitel wird der Aspekt-Begriff im herkömmlichen Sinn und nicht im Sinne der
Aspektorientierung verwendet.
2 Web Engineering
8
2.1 Historische Entwicklung von
Web-Anwendungen
Web-Anwendungen werden aufgrund ihres Komplexitätsgrades und der Entwicklungshistorie in verschiedene Kategorien gegliedert, denen eindeutige Beispiele
zugeordnet werden können. Wie Abbildung 2.1 aus [KPRR04] veranschaulicht,
steigt der Komplexitätsgrad mit der zeitlichen Entwicklung, dh. höhere Entwicklungsstufen bauen auf den ihnen vorangegangenen auf.
Abbildung 2.1: Kategorien von Web-Anwendungen
2.1.1 Generationen von Web-Anwendungen
Generell können diese Kategorien in drei Generationen von Web-Anwendungen
eingeteilt werden, die sich vor allem durch die verwendete Technologie und den
angebotenen Services voneinander abheben [HKRS02]. Die erste Generation umfasst read-only“ Web-Seiten, die anonymen Benutzern der Informationsgewin”
nung dienen. Die zweite Generation sind bereits laut obiger Definition echte“
”
2 Web Engineering
9
Web-Anwendungen, also zustandsbasierte Softwaresysteme mit zugrunde liegender Datenbank, die Dienste mit Benutzertransaktionen zur Verfügung stellen.
Hierzu gehören auch E-Commerce Anwendungen, die durch personalisierte Services, also auf den jeweiligen Benutzer angepasste Dienste, diese Generation besonders geprägt haben. Derzeit aktuell ist die dritte Generation, welche durch
ubiquitäre Web-Anwendungen charakterisiert ist. Ubiquitäre Web-Anwendungen
gehen einen Schritt weiter als Web-Anwendungen der zweiten Generation und
bieten kontextabhängige Dienste über jedes beliebige Endgerät an, wodurch der
Zugriff allgegenwärtig wird.
2.2 Ubiquitäre Web-Anwendungen
Ubiquitäre Web-Anwendungen sind spezielle Web-Anwendungen, die das
anytime/anywhere/anymedia Paradigma umsetzen. Während die permanente
Verfügbarkeit (anytime) in der Natur des Web liegt und nichts Neues ist, werden
ubiquitäre Web-Anwendungen durch die Charakteristika anywhere und anymedia geprägt. Die Bezeichnung ubiquitär leitet sich vom lateinischen Wort ubique
ab und bedeutet allgegenwärtig. Den Terminus Ubiquitous Computing hat Mark
Weiser in seinem Artikel The Computer for the 21st Century“ geprägt [Weis91].
”
Darin betont Mark Weiser die automatische Anpassung des Verhaltens von
Computern an den aktuellen Standort (anywhere).
[...] We have found two issues of crucial importance: location and
scale. Little is more basic to human perception than physical juxtaposition, and so ubiquitous computers must know where they are.
(Today’s computers, in contrast, have no idea of their location and
surroundings.) If a computer merely knows what room it is in, it can
adapt its behavior in significant ways without requiring even a hint
of artificial intelligence. [...] [Weis91]
Bei ubiquitären Web-Anwendungen spielt der Standort eine zentrale Rolle. Allerdings steht im Gegensatz zur Theorie von Mark Weiser nicht der Standort
des Web-Servers, auf dem die Web-Anwendung installiert ist, im Vordergrund,
sondern der Standort des Benutzers, der die Web-Anwendung nutzt.
Weiters beschreibt Mark Weiser seine Vision der totalen, unsichtbaren Vernetzung, in der jeder Gegenstand intelligent“ ist (anymedia).
”
[...] When almost every object either contains a computer or can
have a tab attached to it, obtaining information will be trivial: Who
”
2 Web Engineering
10
made that dress? Are there any more in the store? What was the
name of the designer of that suit I liked last week?“ The computing
environment knows the suit you looked at for a long time last week
because it knows both of your locations, and, it can retroactively
find the designer’s name even if it did not interest you at the time.
[...] [Weis91]
Ubiquitäre Web-Anwendungen können über jedes beliebige Endgerät (Handies,
PDAs, PCs, etc.) benutzt werden. Sie passen ihre Darstellung und ihr Verhalten an die zur Verfügung stehenden Ressourcen der unterschiedlichsten Zugriffsmedien an. Dazu gehören unter anderem die Größe und Farbunterstützung des
Displays, die Möglichkeiten zur Dateneingabe, Netzwerkverbindung und lokaler
Speicherplatz.
Ubiquitäre Web-Anwendungen bieten neben der angepassten Darstellung auch
an den aktuellen Nutzungskontext angepasste Inhalte. Der Nutzungskontext
enthält Faktoren wie Ort, Zeit, Benutzer, etc. Die Aquisition dieser Kontextfaktoren und die daraus resultierende Adaptierung der Web-Anwendung heißt
Customization.
2.2.1 Customization
Customization ist der Schlüssel für individuell auf den Benutzer abgestimmte
Web-Anwendungen. Bei der Customization wird, basierend auf dem aktuellen
Nutzungskontext (siehe 2.2.2), mittels einem Regelsystem (Mapping) (siehe 2.2.4)
die Web-Anwendung spezifisch auf den jeweiligen Benutzer und seinen bekannten
Kontext abgestimmt. Der Umfang der Customization kann hierbei sehr stark variieren. So ist von einer einfachen Anpassung der Darstellung der Web-Anwendung
an das entsprechende Gerät des Benutzers bis hin zu einer kompletten Adaptierung von Content-, Hypertext- und Präsentations-Levels der Web-Anwendung
alles möglich.
Ursprung der Customization
Historisch gesehen wurde der Begriff der Customization vor allem von der Personalisierung und dem Mobile-Computing beeinflusst [KPRS03]. In Folge wird auf
einzelne Bereiche aus Abbildung 2.2 in Anlehnung an [KPRS03] eingegangen.
Personalisierung. Die Personalisierung war eine der ersten Customizationsaktionen die angedacht und umgesetzt worden ist und hat ihre Ursprünge
2 Web Engineering
11
Abbildung 2.2: Ursprünge der Customization [KPRS03]
in den früheren Achtzigern. Hierbei stand zuerst die Anpassung des UserInterfaces im Mittelpunkt des Interesses. Das Ziel war, die Interfaces der
Anwendungen an die Fähigkeiten, Aufgaben und Wünsche des Benutzers
anzupassen [GoWJ84] beziehungsweise das Interface für den Benutzer anpassbar zu machen.
Danach folgten im Bereich der Personalisierung intelligente Lehr- und Hilfssysteme, welche ihre Funktion und Lehrstrategien auf die individuellen
Bedürfnisse der Benutzer, je nach Wissensstand und Lernfortschritt, automatisch abstimmen.
Weiters kommen von der Personalisierungsseite die für die Customization
immens wichtigen Bereiche der Informationsfilterung [AvZe97,LoTe92] und
Adaptive Hypermedia [BrMa02]. Das finale Ziel dieser beiden Bereiche ist es,
aus dem umfassenden Pool an Daten einer Web-Anwendung einerseits genau
jene Informationen zu liefern, welche für den Benutzer interessant sind und
diese andererseits auch benutzerspezifisch aufzubereiten und darzustellen.
Mobile-Computing. Das Mobile-Computing kann als zweites großes Standbein
der Customization gesehen werden. Hierbei wurden die ersten Ansätze in
den frühen Neunzigern gemacht, wobei zu Beginn alles im Zeichen von ortsabhängigen Diensten gestanden ist [WaSc01]. Dies ist naheliegend, da sich
hierfür eine Fülle von Anwendungsgebieten geboten haben und noch immer
bieten.
2 Web Engineering
12
Ortsbasierte Dienste. Das Ergebnis dieser Entwicklung zeigt sich
heute in der Vielzahl von ortsbasierten Diensten. Solche sind zum Beispiel
im Outdoorbereich Flottenmanagementsysteme, Verkehrskontroll-, Leitund Notrufsysteme sowie im Indoorbereich elektronische Museumsführer.
Weitere Beispiele zu ortsbasierten Diensten findet man in [ChKo00,EPS+ 01,
KPRS03, KDJ+ 04].
Für die Ermittlung der benötigten Ortsdaten stehen eine Reihe von Technologien zur Verfügung, welche sich je nach Anwendungsfall unterschiedlich
gut eignen, wobei hier vor allem zwischen der Erfassung der Ortsdaten im
Freien oder innerhalb von Gebäuden differenziert werden muss. Als Auswahl
können hier GPS, Mobilfunkanlangen, Kameras, RFID, Magnetkarten und
Barcodesysteme genannt werden [BaDR06].
Multi Channel Delivery. Ein weiterer wichtiger Bereich von Mobile Computing ist das so genannte Multi Channel Delivery. Hiermit wird
es ermöglicht, die Web-Anwendung auf unterschiedlichsten (mobilen) Endgeräten nutzen zu können. Dabei müssen die verschiedenen Spezifikationen
der Endgeräte auf Hardware- und auf Softwareseite erfasst und berücksichtigt werden, um eine angemessene Adaptierung der Web-Anwendung in
Bezug auf die grafischen Benutzeroberfläche, Interaktionsmöglichkeiten für
den Benutzer und den Inhalt an sich durchführen zu können. Solche Spezifikationen umfassen beispielsweise die Display-Größe und Auflösung, die
Farbtiefe, die Speichergröße und Rechenleistung sowie das Betriebssystem
und den verwendeten Browser des Endgerätes.
Um den Aufwand für die Erkennung der entsprechenden technischen Daten und Funktionen nicht ausufern zu lassen, haben schon sehr früh Standardisierungsbemühungen eingesetzt. Das The World Wide Web Consortium (W3C)2 bietet mit seinen Device Independence Aktivitäten eine Reihe
von Standardisierungsansätzen [W3C003], wobei hier speziell das Composite Capability/Preference Profile (CC/PP) [W3C004b] hervorzuheben ist,
welches standardisierte Profile für Endgerätespezifikationen und Benutzerpräferenzen darstellt. Für die Profilerstellung wird das Ressource Description Framework (RDF)3 benutzt. Hierfür existiert bereits ein umfangreiches
Vokabular für die Spezifikation der einzelnen Eigenschaften der Geräte.
Network Adaptation. Nachdem Mobile-Computing mit drahtloser
Datenübertragung einhergeht, bei welcher verschiedene Netzwerkbedingun2
3
http://www.w3.org/
http://www.w3.org/RDF/
2 Web Engineering
13
gen zu berücksichtigen sind, liegt es nahe, dass auch diese bei der Customization mit berücksichtigt werden. Dieser immer bedeutender werdende
Forschungsbereich nennt sich Network Adaptation.
Hierbei waren die ersten Ansätze darauf ausgelegt die Web-Anwendungen
und Dienste so robust zu machen, dass diese mit unerwarteten Verbindungsabbrüchen umgehen und sich an diese anpassen können. Solche Abbrüche
können bewusst durch den Benutzer herbeigeführt werden, in dem dieser
zum Beispiel einfach die Anwendung beendet oder das Endgerät ausschaltet,
oder aber auch durch einen leeren Akku oder einem Verbindungsabbruch
im Netzwerk auftreten.
Darüber hinaus muss man davon ausgehen, dass die Bandbreiten der Datenübertragung zu unterschiedlichen Endgeräten verschieden hoch sind und
auch fortwährenden Schwankungen unterliegen [BFK+ 00]. Darum soll man
auch dieses Faktum bei der Customization mit einbeziehen und den Inhalt,
welcher übertragen werden soll, entsprechend anpassen. Dies kann einerseits durch verschiedene Kompressionsmechanismen erreicht werden oder
aber auch durch eine Filterung des Inhalts an sich. So kann man bei einer niedrigen Bandbreite zum Beispiel auf multimediale Inhalte komplett
verzichten.
Wie man hier sieht, hat Customization in gewissem Maße in einzelnen Bereichen der Informatik schon lange fußgefasst. Der Punkt hierbei ist jedoch dass in
Forschungsarbeiten genauso wie im Einsatz in der Produktivumgebung meist nur
Teilgebiete der Customization umgesetzt werden. Hier bietet die Customization
noch ein großes Potential für zukünftige Anwendungen.
Definition des verwendeten Customization Begriffes
In dieser Arbeit wird der Customization Begriff verwendet, wie er in [KaRS00]
definiert worden ist:
[...] In our terms, customization specializes a web application called core web application towards the particular circumstances of consumption called context. The result of the customization process represents a customized web application. [...]
Aus dieser Definition geht bereits hervor, wie umfassend sich der Einbezug von
Customization auf die Entwicklung einer Web-Anwendung auswirken kann. In
Abbildung 2.3 wird dies noch deutlicher gezeigt. Hierbei wird klar, dass sich die
2 Web Engineering
14
Abbildung 2.3: Umfang der Customization anhand der Modellierungsdimensionen von Web-Anwendungen [KaRS00]
Customization über alle bekannten Dimensionen bei der Entwicklung von WebAnwendungen erstreckt. Die Customization muss also für alle Levels, Features
und Phases einer Web-Anwendung mitberücksichtigt werden. Daher ist es nur
sinnvoll, die Customization als eigene Dimension in die Entwicklung von WebAnwendungen einzuführen [KaRS00].
Customization wird, wie in Abbildung 2.4 dargestellt, im Prinzip durch zwei
Hauptcharakteristika bestimmt. Einerseits durch die Umstände der Verwendung
der Web-Anwendung, was dem Nutzungskontext, auch kurz Kontext genannt, entspricht und andererseits durch die möglichen Änderungen an der Web-Anwendung
an sich, der so genannten Adaptierung [KaRS00]. Beide Charakteristika können
entweder statisch oder dynamisch sein, was sich direkt auf den Grad der Anpassbarkeit auswirkt. Web-Anwendungen, welche nur statischen Kontext und/oder
statische Adaptierung unterstützen werden oft als adaptable bezeichnet wobei
hingegen Anwendungen mit dynamischem Kontext/Adaptierung als adaptive bezeichnet werden [FiKS97]. Kontext und Adaptierung bestimmen gemeinsam das
Ergebnis der Customization, wobei diese das Mapping zwischen den beiden Bereichen abbildet.
2 Web Engineering
15
Abbildung 2.4: Customization
2.2.2 Kontext
Das anytime/anywhere/anymedia Paradigma von ubiquitären WebAnwendungen und die damit verbundene Anpassung an den Kontext (Customization) stellt eine bei weitem größere Herausforderung dar, als die reine
Personalisierung einer Web-Anwendung. Während bei der Personalisierung
nur auf den Benutzer bzw. auf sein Verhalten Rücksicht genommen wird,
bieten ubiquitäre Web-Anwendungen auch zeitabhängige, ortsabhängige, netzwerkabhängige und endgeräteunabhängige Services an [KPRS03], welche in
Summe eine nach allen technisch machbaren Faktoren adaptierte und personalisierte Web-Anwendung ergeben.
Für die Adaptierung ist es somit wichtig zu wissen unter welchen Umständen
die Anwendung verwendet wird. Diese Umstände (zB mit welchen Browser, auf
welchem Gerät, zu welcher Zeit) werden im Folgenden als Kontext bezeichnet.
Prinzipiell kann jede nur irgendwie verfügbare Information für die Adaptierung
benutzt werden, aber natürlich sind nicht alle Informationen relevant. Es gilt
somit zuerst herauszufinden, welche Kontextfaktoren relevant sind und wie sie
für die Customization der Anwendung verwendet werden können [KaRS00]. Im
Folgenden werden die allgemein für ubiquitäre Web-Anwendungen interessanten
Kontextfaktoren in Anlehnung an [KRK+ 02] kurz dargestellt, wobei grundsätzlich
zwischen dem physischen Kontext und dem daraus abgeleiteten logischen Kontext
unterschieden wird.
Physischer Kontext
Der physische Kontext ist prinzipiell nicht modifizierbar und wird nicht von der
Anwendung kontrolliert. Er bezieht sich auf die Umgebung und die Umstände un-
2 Web Engineering
16
ter denen die Anwendung verwendet wird, welche sich natürlich in unregelmäßigen
Abständen ändern können. Da die physischen Kontextfaktoren großteils anwendungsunabhängig bzw. generisch sind, können die für die Anwendung relevanten
Faktoren je nach Art und Zweck der Anwendung unterschiedlich sein.
Natürlicher Kontext Der natürliche Kontext besteht aus den natürlichen Gegebenheiten, wie Ort oder Zeit, unter denen die Web-Anwendung verwendet
wird.
Ort. Informationen über den Standort des Benutzers, von welchem aus
er die Anwendung verwendet. Die Kenntnis über diesen Standort ist für
’Location Based Services’ unabdingbar. Diese Informationen werden in der
Regel nicht vom Endgerät selbst zur Verfügung gestellt, sondern werden
von so genannten ’Location Server’ abgefragt. Dazu kann einerseits die IPAdresse oder bei mobilen Endgeräten, die über das GSM oder UMTS Netz
eine Verbindung zum Internet herstellen, auch die ’CellId’ ihrer Mobilfunkzelle verwendet werden.
Zeit. Der Kontextfaktor Zeit ermöglicht die Customization der Anwendung in Abhängigkeit bestimmter zeitlicher Einschränkungen, wie zum
Beispiel die Öffnungszeiten von Geschäften oder die Fahrpläne von öffentlichen Verkehrsmitteln. Dabei ist zu beachten, dass sich der Benutzer der
Anwendung durchaus in einer anderen Zeitzone befinden kann und somit
die ’Serverzeit’ nur bedingt verwendet werden kann.
Sprache. Informationen über die bevorzugte Sprache des Benutzers.
Mit Hilfe dieser Informationen kann die Sprache der Anwendung an die des
Benutzers angepasst werden. Die vom Benutzer bevorzugte Sprache hat er
entweder selbst bekannt gegeben (siehe sozialer Kontext) oder wurde über
den Browser automatisch festgestellt (siehe technischer Kontext).
Wetter. Das derzeitige Wetter, sowie die Vorhersage für eine bestimmte Anzahl an Tagen, für den Standort, an dem sich der Benutzer befindet.
Diese Informationen, die in Abhängigkeit des Kontextfaktors Ort von einem ’Wetterserver’ abgefragt werden, sind besonders für Tourismus und
Freizeitportale interessant, denn damit kann das dem Benutzer präsentierte
Angebot detaillierter angepasst werden.
Technischer Kontext Der technische Kontext besteht aus Informationen über
den verwendeten Browser, das Endgerät, Netzwerk und die Anwendung
selbst.
2 Web Engineering
17
Endgerät. Wie bereits zuvor erwähnt, ist dieser Kontextfaktor besonders für mobile Endgeräte wichtig, denn diese verfügen oft nur über sehr
beschränkte Ressourcen (zB Bildschirmgröße, Tastatur, etc.) für die Darstellung von Webseiten. Speziell Mobiltelefone, sind in der Regel nicht für
die Dartstellung bzw. Eingabe längerer Texte geeignet. Somit ist es notwendig die Web-Anwendung jeweils speziell für diese, aber auch andere mögliche
Endgeräte anzupassen.
Browser. Um dem anymedia-Anspruch von ubiquitären WebAnwendungen gerecht zu werden, ist es notwendig, auch Informationen
über das verwendete Endgerät (siehe Kontextfaktor Endgerät) und den
Browser für die Customization auszuwerten. So können gerade Browser auf
mobilen Endgeräten, wie Mobiltelefone oder Handheld-Computer, nicht
immer Frames darstellen oder verfügen nur über einen geringen Speicher
für die Darstellung von Webseiten.
Netzwerk. Dieser Kontextfaktor enthält Informationen über die Bandbreite der Netzwerkverbindung mit der die Anwendung verwendet wird.
Gerade bei mobilen Endgeräten aber auch bei Computern, die eine Modemverbindung verwenden, spielt dies eine wichtige Rolle. So kann bei der
Customization für Endgeräte mit geringer Bandbreite auf speicherintensive
Elemente wie Videos oder Bilder nach Möglichkeit verzichtet werden.
Anwendung. Geben die bisherigen Kontextfaktoren nur Aufschluss
über die Umgebung der Anwendung, so ist es für die Customization auch
wichtig, Informationen über die Anwendung selbst zu haben. Beispielsweise
über die derzeitige Server- oder Datenbankauslastung oder ob alle Komponenten der Anwendung fehlerfrei arbeiten.
Sozialer Kontext Der Soziale Kontext umfasst alle Informationen über den Benutzer, beziehungsweise welche den Benutzer direkt betreffen. Diese können
sowohl von ihm selbst zur Verfügung gestellt als auch, bis zu einem gewissen
Grad, automatisch von der Anwendung abgeleitet worden sein. Sie werden
unter dem Kontextfaktor Benutzer zusammengefasst.
Benutzer. Für die Personalisierung der Anwendung ist es notwendig
den Benutzer der Anwendung zu identifizieren. Dies kann je nach dem verwendeten Endgerät über eine Vielzahl von Techniken geschehen. Bei Mobiltelefonen über die Telefonnummer, bei normalen Computern über die
IP-Adresse oder ein Cookie. Diese Methoden sind allerdings nicht hundertprozentig zuverlässig. Somit wird der Benutzer in der Regel durch einen
2 Web Engineering
18
Benutzernamen und ein Passwort, die er beide selbst eingeben muss, identifiziert. Unabhängig davon wie der Benutzer identifiziert wird, müssen der
Anwendung natürlich seine Daten bekannt sein. Diese werden in einem Benutzerprofil gespeichert, welches in der Regel selbst vom Benutzer angelegt wird und neben seinen Zugangsdaten auch Informationen über seine
persönlichen Präferenzen bezüglich der Sprache der Anwendung, seine Interessensgebiete oder demographische Daten über ihn beinhalten. Mit Hilfe
dieser Daten ist je nach Zweck der Anwendung und Qualität der Angaben
im Benutzerprofil eine Adaptierung möglich.
Logischer Kontext
Wie bereits erwähnt, wird der logische Kontext aus dem physischen abgeleitet,
um abstraktere Informationen für die Customization der Web-Anwendung zu
erhalten. Beispielsweise ist die IP-Adresse des Benutzers als solche nicht besonders
aussagekräftig. Kann man die IP-Adresse jedoch einem Ort bzw. einer Addresse
zuordnen so kann dies für die Adaptierung durchaus sehr nützlich sein.
Der logische Kontext kann auf verschiedene Arten abstrahiert werden. Ist es
möglich mehrere IP-Adressen einem Ort zuzuordnen, so wäre dies ein Beispiel
für eine Aggregation. Auch die Fusion verschiedener Kontextfaktoren ist möglich.
’Wien bei Nacht’ ist ein Beispiel für die Fusion der Kontextfaktoren Ort und Zeit.
Weiters wird beim logischen Kontext zwischen dem anwendungsspezifischen Teil
und dem anwendungsunabhängigen Teil unterschieden, welcher generisch ist und
meist von externen Dienstleistern zur Verfügung gestellt wird (zB die Zuordnung
von IP-Adressen zu Orten).
So wie die physischen Kontextfaktoren hauptsächlich automatisch aus den Umgebungsbedingungen der Anwendung gewonnen werden, sollte auch der logische
Kontext automatisch abgleitet werden. In den zuvor angeführten Beispielen war
dies immer möglich. Aber nicht immer sind alle Kontextinformationen vollständig
vorhanden. Zum Beispiel wenn eine IP-Adresse nicht eindeutig einem Ort zugeordnet werden kann oder wenn ein Benutzer die Anwendung zum ersten Mal
besucht und noch kein Benutzerprofil mit seinen Präferenzen angelegt hat. Für
diesen Fall ist es notwendig allgemeine Default-Werte für die fehlenden Kontextinformationen bereit zu halten oder den Benutzer dazu aufzufordern die fehlenden
Informationen zu ergänzen. Dennoch darf man nicht außer Acht lassen, dass gerade ubiquitäre Web-Anwendungen hochgradig dynamisch sind [KPRS03] und
daher auch die Akquisition der Kontextinformationen dynamisch erfolgen sollte.
Denn auch der Nutzungskontext eines der Anwendung bereits bekannten Nutzers kann sich ’unvorhergesehen’ ändern. Zusätzlich hat sich auch gezeigt, dass es
2 Web Engineering
19
nützlich ist nicht nur aktuelle Kontextinformationen zu speichern sondern auch
’historische’ um Veränderungen im Nutzungsverhalten besser nachvollziehen zu
können, aber auch um Vorhersagen bezüglich einzelner Kontextfaktoren (zB der
Bandbreite) treffen zu können.
2.2.3 Adaptierung
Wie schon für die Customization im Allgemeinen, gilt auch für die Adaptierung,
dass diese sich über alle Dimensionen der Web-Anwendungsentwicklung erstreckt.
Als Beispiel kann hier die Anpassung des User Interfaces auf Präsentationsebene
oder die Anpassung der Linkstruktur auf Hypertextebene genannt werden. Wie
bereits angesprochen, kann die Adaptierung statisch oder dynamisch ausfallen.
Bei einer statischen Adaptierung wird lediglich aus einem Set an vorgefertigten
Versionen der Web-Anwendung, beziehungsweise des zu adaptierenden Teils, eine passende gewählt. So können für unterschiedliche Endgeräte jeweils passende
Templates für das User Interface vorliegen, wobei bei der Adaptierung lediglich
das für das Endgerät zutreffende Template gewählt wird.
Im Gegensatz dazu wird bei einer dynamischen Adaptierung die angepasste
Web-Anwendung zur Laufzeit generiert. So werden hier Bilder entsprechend verkleinert oder ausgeblendet, Inhalte ausgewählt, Linkstrukturen angepasst, etc.,
und das Alles genau abgestimmt auf den aktuellen Nutzungskontext des Benutzers.
Eine weitere Stufe bei der Adaptierung ist die “lernende Adaption“, auch Adaption of Adaption genannt [KaRS00]. Hierbei soll die Adaptierung die Customization selbst automatisch an sich ändernde Rahmenbedingungen anpassen. Das kann
von einer Anpassung der Adaptierungsregeln an sich, also zum Beispiel deaktivieren, aktivieren oder ändern der Parametern von Regeln, bis hin zur Änderung
der Gewichtung der, für die Customization wichtigen, Kontextfaktoren gehen.
2.2.4 Mapping - Customizationregeln
Wie bereits angesprochen, bietet das Customization ein Mapping zwischen Kontextfaktoren und entsprechenden Customizationregeln. Ein möglicher Ansatz dazu ist basierend auf [KaRe98, FSK+ 02], so genannte Event/Condition/Action
Regeln zu verwenden (siehe Abbildung 2.5). Hierbei drückt der Event mit der
Condition den Kontext aus und die Action führt die Adaptierung durch.
Als Beispiel kann der Event einfach der Aufruf einer Website durch einen Benutzer sein, die Condition ist zum Beispiel die aktuelle Tageszeit und die Action
führt die Anpassung an sich durch, wobei in diesem Fall ein, auf die Tageszeit
2 Web Engineering
20
Abbildung 2.5: event/condition/action [FSK+ 02]
abgestimmter Content geliefert wird.
Customization wird in dieser Arbeit sehr umfassend gesehen, wie auch
in [FSK+ 02]. Wie dort beschrieben muss Customization Personalisation und
Context-Aware Computing gleichermaßen beinhalten.
Personalisation liefert jedem Benutzer einen individuell abgestimmten Inhalt
und bietet ihm somit einen erheblichen Mehrwert. Darüber hinaus liefert aber
die Customization dem Benutzer das Angebot auch auf diverse total verschiedene
Endgeräte. Hier kann zwar die Darstellung aufgrund der technischen Gegebenheiten unterschiedlich ausfallen, aber der Punkt ist, dass der Inhalt und der durch
die Customization gebotene Mehrwert bei jedem Endgerät gleich ist und nicht
verloren geht.
21
Kapitel 3
Endgeräteunabhängige
Lösungsansätze
Die meisten traditionellen Web-Anwendungen werden (zurecht) primär für normale PCs entwickelt und anfangs auch nur auf solchen getestet. Bei der Entwicklung einer ubiquitären Web-Anwendung ist aber schon von Beginn an klar, dass
diese auch auf mobilen Endgeräten zumindest den Großteil der Funktionen der
PC-Version aufweisen muss. Die wesentlichen Unterschiede von PCs und mobilen
Endgeräten im Bezug auf die Verwendung von Web-Anwendungen sind [Noki04]:
• Mobile Endgeräte haben kleinere Displays und eine größere Vielfalt an verschiedenen Auflösungen.
• Seit einigen Jahren werden mobile Geräte nur mehr mit Farbdisplays angeboten, dennoch können diese nur 4.096 (12 bit) oder 65.536 (16 bit) Farben
darstellen, wohingegen Desktop Monitore über 16 Millionen 32 bit Farben
darstellen können.
• Die Texteingabe mit Telefontastaturen oder Touchscreentastaturen ist
mühsamer als mit einer normalen Tastatur
• Mobile Geräte haben in der Regel keine Maus, was die Aktivierung von
Objekten wie Links schwieriger macht.
• Manche Browser, speziell für Mobiltelefone, unterstützen nur in der vertikalen Achse Scrollbalken.
• Anstelle einer Maus werden Softkeys (in der Regel die Tasten direkt unter
dem Display) für die Aktivierung von Objekten verwendet. Die Anzahl und
Funktion dieser Tasten kann je nach Hersteller stark variieren, was die Entwicklung einheitlicher User-Interfaces starkt einschränkt bzw. erschwert.
22
• Die Übertragungsraten der Internet-Verbindung zum Server sind in der Regel geringer als bei einer fixen Anbindung.
• Es steht nur wenig Platz zum Speichern von Cookies zur Verfügung.
• Die Internet-Verbindung wird meist nach der Menge an übertragenen Daten
verrechnet, wobei die Kosten pro Megabyte um ein Vielfaches höher sind,
als bei festen Leitungen.
Die Unterschiede zeigen größtenteils Besonderheiten der mobilen Endgeräte
auf, dennoch werden Web-Anwendungen für unterwegs immer beliebter. Derzeit
verfügen ca. 80% der Österreicher über ein Mobiltelefon und nur ca. 2% benutzen
das Web bzw. Web-Anwendungen am Mobiltelefon. Auch wenn dies nur ein sehr
geringer Anteil ist, wird davon ausgegangen, dass sich die Nutzung des Internets
am Mobiltelefon in Zukunft weiter verstärkt. Die Fähigkeiten der Endgeräte werden immer besser und die Datentarife immer günstiger, was ein weiterer Grund
ist, die Entwicklung von ubiquitären Webanwendungen zu forcieren [STAT05].
Dieses Kapitel beschäftigt sich mit dem anymedia Aspekt von ubiquitären
Web-Anwendungen und der damit verbundenen Adaptierung der Anwendung für
mobile Endgeräte. Für die Adaptierung ist es zuerst wichtig die Eigenschaften
des jeweiligen Endgeräts zu kennen (siehe 3.1). Weiters muss man wissen bzw.
festlegen wie die Inhalte erstellt werden (siehe 3.2) um dann eine oder mehrere
Adaptierungstechniken (siehe 3.3) zu implementieren.
3.1 Methoden zur Erkennung der
Geräteeigenschaften von Endgeräten
Das wohl größte Problem bei der Entwicklung von ubiquitären WebAnwendungen für mobile Endgeräte ist die Vielfalt der möglichen Endgeräte und
die unterschiedlichen Eigenschaften dieser Geräte. Gerade bei Mobiltelefonen gibt
es im Vergleich zu anderen mobilen Endgeräten wie zB PDAs eine Vielzahl an
verwendeten Browsern und auch meist sehr unterschiedliche Bildschirmauflösungen.
Dieser Abschnitt beschäftigt sich mit der Erkennung dieser Geräteeigenschaften. Hierzu gibt es mehrere Möglichkeiten von denen im Folgenden die drei
gängigsten vorgestellt werden.
23
3.1.1 HTTP Request Header
Die Analyse der Header-Felder des HTTP-Requests ist die einfachste und beliebteste Methode um Informationen über das verwendete Endgerät bzw. den
Browser zu erfahren. Die möglichen Header-Felder des HTTP 1.1. Protokolls sind
in [RFC2] definiert. Für die Identifikation der Geräteeigenschaften sind folgende
Felder nützlich.
Accept Dieses Feld enthält eine Liste von MIME-Typen [RFC2] die vom Browser
akzeptiert werden. Mit ihrer Hilfe kann man feststellen, welche Arten von
Dateien das Endgerät unterstützt. Bei einem Request auf eine XHTML
Datei könnte der Accept-Header zum Beispiel folgende Werte enthalten:
application/vnd.wap.wmlscriptc, text/vnd.wap.wml,
application/vnd.wap.xhtml+xml, application/xhtml+xml,
text/html, multipart/mixed, */*
Daraus kann man nun erkennen, dass der Browser des Endgeräts WML, XHTML-, HTML-Dateien usw. unterstützt. Bei einem Request auf eine
Grafikdatei könnte der Accept-Header folgendermaßen aussehen:
image/vnd.wap.wbmp, image/gif, image/jpg,
image/jpeg, image/png, image/bmp, image/x-bmp
Somit weiß der Server nun welche Arten von Bildern der Browser unterstützt. Da es eine Vielzahl an verschiedenen MIME-Typen gibt, findet
sich eine Liste aller für mobile Endgeräte interessanten MIME-Typen in
Anhang E.
User-Agent Dieses Feld kann dazu verwendet werden den Browser und das Endgerät selbst zu identifizieren. Meist finden sich darin Informationen über
den Hersteller, das Modell und das Betriebssystem. Folgend zwei Beispiele,
einmal der User-Agent-Header des Nokia 6600 Mobiltelefons:
Nokia6600/1.0 (4.03.24) SymbianOS/6.1 Series60/2.0
Profile/MIDP-2.0 Configuration/CLDC-1.0
und des Internet Explorers 6:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
24
Wie man aus den beiden Beispielen bereits erkennen kann gibt es keinen
einheitlichen Standard bezüglich des Inhalts dieses Feldes. Da die Angaben
je nach Hersteller sehr stark variieren, ist es nicht immer einfach die Informationen für Browser, Modell, Hersteller und Betriebssystem zuverlässig
festzustellen, was vor allem daran liegt, dass es keine einheitliche Formatierung dieses Felds gibt. Beim ersten Beispiel kann man als Mensch leicht
erkennen, dass es sich um ein Nokia 6600 mit Symbian OS Serie 60 2nd Edition handelt, beim zweiten Beispiel ist der Browser der Microsoft Internet
Explorer am Betriebssystem Windows XP. Für die Adaptierung währen diese Informationen grundsätzlich ausreichend, allerdings sind sie auf Grund
der vielen möglichen Ausprägungen des Header-Felds nur sehr schwer zu
erkennen.
Accept-Charset Das Accept-Charset Feld gibt an welcher Zeichensatz für die
Response bevorzugt wird, was vor allem für Inhalte mit Sonderzeichen (wie
zum zB Ä,Ö,Ü,ß) wichtig ist. Das Accept-Charset-Header Feld könnte zB
so aussehen:
ISO-8859-1, UTF-8; q=0.8,
ISO-10646-UCS-2; q=0.6
Die verschiedenen Charsets sind, wie auch die verschiedenen Sprachen in der
Regel in der Reihe der Präferenzen des Benutzers geordnet. Diese kann der
Benutzer im Browser konfigurieren. Zusätzlich wird noch ein Qualitäts”
Wert“ (zB q=0.8) angegeben, wobei der Default Wert 1 ist. Im obigen
Beispiel bevorzugt der Benutzer also den Zeichensatz ISO-8859-1 mit einer
Qualität von 1, vor dem Zeichensatz UTF-8 mit einer Qualität von 0.8 usw.
Das gleiche System gilt analog für die Angabe der bevorzugten Sprache im
Accept-Language Header-Feld.
Accept-Language Dieses Feld gibt die bevorzugte Sprache für die Response an.
Vor allem für mehrsprachige Webseiten ist dieses Feld von besonderem
Interesse, da anhand der Angaben automatisch entschieden werden kann,
in welcher Sprache die Seite angezeigt wird. Ein Beispiel für das AcceptLanguage-Header Feld:
de, en-us; q=0.8, en; q=0.6
25
Aus den HTTP Header-Feldern kann man zwar einige für die Adaptierung
nützliche Informationen erfahren, aber über die tatsächlichen Eigenschaften des
Endgeräts erfährt man leider nur wenig. Aus diesem Grund haben einige Hersteller eigene Header-Erweiterungen eingeführt. Dabei handelt es sich um nicht
standardisierte Felder, die je nach Hersteller unterschiedlich benannt sein können
oder unter dem gleichen Namen unterschiedliche Werte enthalten können. Microsoft hat zB beim Pocket Internet Explorer [Msdn06] solche Header-Erweiterungen
eingeführt. Listing 3.1 zeigt einen Auszug aus dem Request-Header des Pocket
Internet Explorers. Neben den bereits vorgestellten Feldern finden sich die folgenden proprietären Felder:
UA-OS Gibt das Betriebssystem des Endgeräts an.
UA-color Gibt die unterstützte Farbtiefe des Displays an.
UA-pixels Gibt die Auflösung des Displays an.
UA-UPU Gibt den verwendeten Prozessor an.
UA-Language Gibt an, welche Skriptsprachen der Browser unterstützt.
Listing 3.1: Request Header Pocket Internet Explorer
1
2
3
4
5
6
7
8
9
GET http: // localhost:8080 / tip / main . do HTTP /1.1
Accept: */*
UA - OS: Windows CE ( POCKET PC ) - Version 3.0
UA - color: color16
UA - pixels: 240 x320
UA - CPU: ARM SA1110
UA - Language: JavaScript
User - Agent: Mozilla /2.0 ( compatible ; MSIE 3.02; Windows CE ;
240 x320 )
3.1.2 Composite Capabilities/Preferences Profile
Wie bereits zuvor erwähnt, bieten die Request Header nur sehr beschränkte
Möglichkeiten zur Erkennung der Geräteeigenschaften. Darum hat das World
Wide Web Consortium (W3C) 2004 den auf RDF [RDF04] basierenden Standard
Composite Capabilities/Preferences Profile (CC/PP) [W3C004b] verabschiedet.
Ein CC/PP Profil enthält die Geräteeigenschaften und eventuelle Benutzerpräferenzen mit deren Hilfe sowohl die geräteabhängige, als auch die inhaltliche Adaptierung vereinfacht wird. Es besteht aus verschiedenen Komponenten, in denen
eine beliebige Anzahl an Attributen und Werten von einem Vokabular definiert
werden. Der Vorteil besteht darin, dass diese Vokabularien beliebig definiert werden können, man ist somit bei der Beschreibung der Geräteeigenschaften nicht auf
26
eine fixe Anzahl an vielleicht nicht zutreffender Attribute beschränkt. Listing 3.2
zeigt ein Beispiel für ein CC/PP Profil. Es besteht aus Komponenten (im Beispiel
die Komponente HardwarePlatform) die wiederum Attribute (zB displayWidth)
und deren Werte (zB 320) enthalten. Ein Profil muss mindestens eine Komponente mit einem Attribut enthalten [W3C004b]. Das Beispiel zeigt die Komponente
HardwarePlatfom in der die Eigenschaften des Geräts wie zB Auflösung des Bildschirms definiert werden und danach jene des Betriebssystems und des Browsers.
In Abschnitt 3.1.3 werden die möglichen Komponenten ausführlicher dargestellt.
Listing 3.2: Request Beispiel eines CC/PP Profils
1
2
3
4
<? xml version = " 1.0 " ? >
< rdf:RDF xmlns:rdf = " http: // www . w3 . org /1999/02/22 - rdf - syntax - ns # "
xmlns:ccpp = " http: // www . w3 . org /2002/11/08 - ccpp - schema # "
xmlns:ex = " http: // www . example . com / schema # " >
5
6
7
< rdf:Description
rdf:about = " http: // www . example . com / profile # MyProfile " >
8
9
10
11
12
13
14
15
16
17
< ccpp:component >
< rdf:Description
rdf:about = " http: // www . example . com / profile # T e r m i n a l H a r d w a r e " >
< rdf:type
rdf:resource = " http: // www . example . com / schema # H a r d w a r e P l a t f o r m " / >
< ex:displayWidth > 320 </ e x : d i sp l a y W i d t h >
< ex:d isp layH eigh t > 200 </ e x : d i s p l a y H e i g h t >
</ rdf:Description >
</ ccpp:component >
18
19
20
21
22
23
24
25
26
27
28
< ccpp:component >
< rdf:Description
rdf:about = " http: // www . example . com / profile # T e r m i n a l S o f t w a r e " >
< rdf:type
rdf:resource = " http: // www . example . com / schema # S o f t w a r e P l a t f o r m " / >
< ex:name > EPOC </ ex:name >
< ex:version > 2.0 </ ex:version >
< ex:vendor > Symbian </ ex:vendor >
</ ccpp:component >
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
< ccpp:component >
< rdf:Description
rdf:about = " http: // www . example . com / profile # T e r mi n a l B r o ws e r " >
< rdf:type
rdf:resource = " http: // www . example . com / schema # BrowserUA " / >
< ex:name > Mozilla </ ex:name >
< ex:version > 5.0 </ ex:version >
< ex:vendor > Symbian </ ex:vendor >
< ex:htmlVersionsSupported >
< rdf:Bag >
< rdf:li > 3.2 </ rdf:li >
< rdf:li > 4.0 </ rdf:li >
</ rdf:Bag >
</ e x : h t m l V e r s i o n s S u p p o r t e d >
45
27
</ ccpp:component >
46
47
48
</ rdf:RDF >
3.1.3 User Agent Profile
Der User Agent Profile (UAProf) Standard wurde von der Open Mobile Alliance
basierend auf dem CC/PP Framework entwickelt. UAProf definiert unter anderem ein fixes Vokabularium für mobile Endgeräte und kann somit als Implementierung von CC/PP gesehen werden [OMA006]. Nahezu alle Mobiltelefonhersteller
und auch ein Großteil der PDA Hersteller stellen mittlerweile UAProf-Profile für
ihre Geräte zur Verfügung. Diese werden in einem Repository gespeichert, das
meist auch vom jeweiligen Hersteller betrieben wird. Die URL zu dem jeweiligen
Profil findet sich im Header des HTTP-Requests in dem Feld x-wap-profile.
Hier ein Beispiel für das Nokia 6230 Mobiltelefon.
x-wap-profile: "http://nds1.nds.nokia.com/uaprof/N6230ir200.xml"
Wie das CC/PP Profil besteht das UAProf Profil auch aus Komponenten mit
Attributen und Werten. Diese sind jedoch vorgegeben um sicherzustellen, dass
die Hersteller nicht verschiedene Komponenten und Attribute für den selben Wert
definieren. Im Folgenden wird ein Teil der möglichen Komponenten und Attribute
kurz beschrieben. Listing 3.3 zeigt einen Auszug aus dem UAProf Profil des Nokia
6230i. Das vollständige Profil findet sich in Anhang F.
Listing 3.3: Request Beispiel eines CC/PP Profils
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
xmlns:prf = " http: // www . o p e n m o b i l e a l l i a n c e . org / tech / profiles / UAPROF / ccppschema
-20021212# "
xmlns:mms = " http: // www . wapforum . org / profiles / MMS / ccppschema -20010111# " >
< rdf:Description rdf:ID = " Profile " >
< prf:component >
< rdf:Description rdf:ID = " H a r d w a r e P l a t f o r m " >
< rdf:type rdf:resource = " http: // www . o p e n m o b i l e a l l i a n c e . org / tech /
profiles / UAPROF / ccppschema -20021212# H a r d w a r e P l a t f o r m " / >
< prf:BluetoothProfile >
< rdf:Bag >
< rdf:li > Headset Profile </ rdf:li >
< rdf:li > Handsfree Profile </ rdf:li >
< rdf:li > SIM Access Profile </ rdf:li >
< rdf:li > Dial - up Networking Profile </ rdf:li >
< rdf:li > Object Push Profile </ rdf:li >
< rdf:li > File Transfer Profile </ rdf:li >
< rdf:li > Generic Access Profile </ rdf:li >
< rdf:li > Serial Port Profile </ rdf:li >
< rdf:li > General Object Exchange Profile </ rdf:li >
</ rdf:Bag >
28

< prf: Bit sPer Pixe l > 16 
< prf: Col orCa pabl e > Yes 
< prf: Ima geCa pabl e > Yes 
< prf: Inp utCh arSe t >
< rdf:Bag >
< rdf:li >ISO -8859 -1 </ rdf:li >
< rdf:li >ISO -10646 - UCS -2 </ rdf:li >
< rdf:li >US - ASCII </ rdf:li >
< rdf:li >UTF -8 </ rdf:li >
</ rdf:Bag >
</ pr f:I nput Char S e t >
< prf:Keyboard > PhoneKeyPad </ prf:Keyboard >
< prf:Model > 6230 i </ prf:Model >
3 

< rdf:Bag >
< rdf:li >ISO -8859 -1 </ rdf:li >
</ rdf:Bag >
</ pr f: O ut pu t Ch a r S e t >
1 x1 
< prf:ScreenSize > 208 x208 
 18 x5 
 Yes 
 Yes 
 Yes 
< prf:Vendor > Nokia </ prf:Vendor >
 Yes 
</ prf:component >
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
HardwarePlatform Beinhaltet die Beschreibung der Hardwareeigenschaften des
mobilen Endgeräts. Zum Beispiel Bildschirmauflösung, Bezeichnung des
Geräts, Name des Herstellers und Informationen über Tastaur, Farb- und
Bilddarstellung.
SoftwarePlatform Diese Komponente enthält Informationen über die Softwareeigenschaften des Geräts, wie zB Name und Version des Betriebssystems,
Java-Unterstützung, die akzeptierten MIME Typen und Schriftsätze.
NetworkCharacteristics Gibt Auskunft über die Netzwerkfähigkeiten des
Geräts, wie zB die möglichen Übertragungsarten (GPRS1 , CSD2 , EGPRS3 ,
HSCSD4 , WLAN5 , EDGE6 ,...) und die unterstützten Verschlüsselungsme1
General Packet Radio Service
Circuit Switched Data
3
Enhanced General Packet Radio Service
4
High Speed Circuit Switched Data
5
Wireless Local Area Network
6
Enhanced Data Rates for GSM Evolution
2
29
thoden (SSL7 , TSL8 , WTSL9 ,...).
BrowserUA Enthält Informationen über die Fähigkeiten des verwendeten Browsers. Zum Beispiel Name und Version des Browsers, unterstütze HTML und
XHTML Version, sowie Informationen zu den JavaScript-Fähigkeiten.
WapCharacteristics Enthält Informationen über die unterstützten WAP-Fähigkeiten des Geräts, zB die WAP Version und die unterstützten WML Script
Libraries, sowie die DRM10 -Fähigkeiten.
Neben den vorgestellten Ansätzen, die mehr oder weniger auf Standards des
W3C beruhen, gibt es noch das Open Source Projekt WURFL. WURFL steht für
Wireless Universal Resource FilLe und ist eine Datenbank, die die Eigenschaften
von derzeit ca. 4500 mobilen Endgeräten enthält [wurf06]. Da WURFL ein Open
Source Projekt ist, kann jeder die Informationen zu den jeweiligen Endgeräten
selbst bearbeiten und ergänzen. Die Datenbank liegt im XML-Format vor, die jeweiligen Endgeräte werden darin anhand ihres User-Agent Felds aus dem Request
eindeutig identifiziert.
3.2 Techniken zur Erstellung von Inhalten für
ubiquitäre Web-Anwendungen
Nachdem der technische Kontext bekannt ist, gilt es für die ubiquitäre WebAnwendung nun, die sich daraus ergebenden Einschränkungen auf die Inhalte
und Darstellung dieser anzuwenden. Dieser Vorgang der Adaptierung steht in engem Zusammenhang mit der angewandten Authoring-Technik. Unter Authoring
wird die Erstellung von Inhalten für Webseiten verstanden [W3C004a]. Generell
kann man sagen, dass es für die Entwicklung von ubiquitären Web-Anwendungen
im Bezug auf die Endgerätunabhängigkeit zwei Authoring-Ansätze gibt: Multiple Authoring mit kontextabhängiger Selektion und Single Authoring mit kontextabhängiger Adaptierung. Diese beiden Ansätze stellen sozusagen die Extreme
dar. Denn die Verantwortung für die Endgerätunabhängigkeit liegt entweder ausschließlich beim Autor oder der Anwendung. Bei einfachen Anwendungsfällen mag
dies durchaus sinnvoll und nützlich sein, dennoch wäre eine flexible Kombination
der beiden Ansätze im Sinne eines Flexible Authoring wünschenswert.
7
Secure Sockets Layer
Transport Layer Security
9
Wireless Transport Layer Security
10
Digital Rights Management
8
30
Multi Authoring Dabei werden die Inhalte für mögliche Klassen von Endgeräten
(zB PCs, PDAs, Mobiltelefone) jeweils eigens erstellt. Es existieren also
mehrere Versionen des gleichen Inhalts. Da es natürlich nicht möglich ist
verschiedene Versionen für alle Endgeräte zu erstellen, besteht die Möglichkeit, dass Geräte, die nicht einer vorhandenen Klasse zugeordnet werden
können, nicht alle Inhalte korrekt darstellen können. Weiters ist die Wartung der Inhalte mit größerem Aufwand verbunden, da die Daten der verschiedenen Versionen untereinander konsistent gehalten werden müssen. Allerdings ist die Implementierung bzw. Erstellung der Web-Anwendung mit
relativ geringem Aufwand verbunden, da keine komplizierten Adaptierungsmechanismen notwendig sind. Vorteile hat Multi Authoring vor allem bei
Webseiten mit einem großen Anteil an Multimedia-Inhalten, wie zum Beispiel Videos die in verschiedenen Größen und Qualitätsstufen zur Verfügung
gestellt werden. Die eigentliche Adaptierung beschränkt sich auf die Auswahl einer der verschiedenen Versionen.
Single Authoring Beim Single Authoring wird im Gegensatz zum Multi Authoring nur eine Version des Inhalts erstellt. Mit Hilfe von verschiedenen
Adaptierungstechniken wird dieser dann für die jeweiligen Endgeräte angepasst. Um dies zu ermöglichen ist es in der Regel notwendig, dass der Autor
auch noch zusätzliche Metainformation bei der Erstellung des Inhalts angibt. Dies können beispielsweise spezielle Tags oder Kommentare im Inhalts
sein, die wichtige Stellen oder Absätze markieren, die auf jeden Fall nach
der Adaptierung noch vorhanden sein müssen. Der Aufwand, sowohl bei der
Erstellung der Inhalte als auch bei der Implementierung der Anwendung,
ist bei Single Authoring in der Regel größer als beim Multi Authoring. Die
Vorteile bestehen daher in der relativ einfachen Erweiterbarkeit der Anwendung im Hinblick auf neue Endgeräte und der unkomplizierten Wartung der
Inhalte.
Flexible Authoring Beim Flexible Authoring hat der Autor die Möglichkeit Single und Multi Authoring Techniken zu kombinieren. So kann er zum Beispiel
Inhalte wie reine Texte nur einmalig erstellen, welche dann für das jeweilige Endgerät adaptiert werden, oder er kann zum Beispiel bei Mutlimedia
Inhalten verschiedene Versionen für die jeweiligen Endgeräte erstellen. Vor
allem bei größeren Portalen kommt Flexible Authoring zum Einsatz, denn
dort werden die Inhalte für eine Seite aus vielen Teilen (zB Schlagtexten
von Artikeln und Bildern) zusammengestellt.
31
Flexible Authoring soll somit die Vorteile aus den beiden Extremen vereinen.
Für die Entwicklung eines Authoring Ansatzes, der alle Vorteile des Multi und
Flexible Authorings vereint und somit auch gleichzeitig die bestmögliche Lösung
für eine ubiquitäre Web-Anwendung darstellt, ist es notwendig alle Aspekte des
Authoring zu kennen. Im Folgenden werden die teilweise überlappenden Aspekte
des Authoring [W3C004a] definiert.
Style Die optische Darstellung des Texts (zB Schriftart oder Farbe), sowie die
Ausrichtung oder Einrückung.
Layout Das Aussehen und die optische Beziehung zwischen den einzelnen Elementen der Seite.
Content Der eigentliche Text bzw. andere Ressourcen wie Bilder Videos und
Dateien.
Structure Beziehungen zwischen den verschiedenen Inhalten, zB Reihenfolge von
Bildern oder Artikel in einer Übersicht usw.
Navigation Sollte dem Benutzer die Möglichkeit bieten mit dem geringstmöglichen Aufwand die verschiedenen Inhalte zu finden.
Application Interaction Die Art, wie der Benutzer mit der Anwendung interagiert, zB nur über Links oder über Formulare, in denen er mehrere Informationen eingibt, und wie die Anwendung darauf reagieren soll.
Für jeden dieser Aspekte gibt es verschiedene Möglichkeiten der Adaptierung.
In Abschnitt 3.3.2 werden verschiedene Adpatierungsansätze vorgestellt, mit deren Hilfe die Adaptierung all dieser Aspekte möglich ist.
32
3.3 Adaptierungsansätze für Endgerätunabängigkeit
von ubiquitären Web-Anwendungen
3.3.1 Ort der Adaptierung
Die eigentliche Adaptierung auf das Endgerät kann, wie bereits erwähnt mit Hilfe
von verschiedenen Techniken erfolgen. Welche Techniken zum Einsatz kommen
hängt nicht nur von der eingesetzten Authoring Methode ab, sondern auch davon
wo die Adaptierung stattfindet.
Abbildung 3.1: Intermediate Adaptation
Intermediate Adaptation Wird hauptsächlich für die Adaptierung von bereits
vorhandenen Anwendungen eingesetzt und wenn man Änderungen an der
Anwendung generell vermeiden möchte [BGGW02]. Für die Adaptierung
werden der Request des Clients und der Response des Webserver über einen
Proxy Server geleitet (siehe Abbildung 3.3.1). Generell ist dabei nur eine
eingeschränkte Art der Adaptierung möglich weil der Proxy Server in der
Regel keine Informationen über die Inhalte hat. So kann der Proxy Bilder
ohne Probleme in ihrer Auflösung verändern oder teilweise auch HTML in
zB Compact HTML (cHTML) transformieren, jedoch nur bedingt für mobile Endgeräte unwichtige Teile des Inhalts entfernen oder die Navigation an
die Anforderungen für mobile Endgeräte anpassen. Dies wäre nur möglich,
wenn der Proxy in die Entwicklung der Anwendung logisch miteinbezogen
würde und somit eventuelle Metainformationen über den Inhalt kennt und
auch verarbeiten kann. In diesem Fall hätte eine Proxy Architektur durchaus Sinn, da sie den Server bzw. Client entlasten würde.
33
Abbildung 3.2: Client Side Adaptation
Client Side Adaptation Hier findet die Adaptierung direkt am Endgerät bzw.
meistens direkt im Webbrowser statt (siehe Abblidung 3.3.1). Der Vorteil
besteht darin, dass der Client in der Regel seine Fähigkeiten kennt und
daher eine aufwändige Erkennung der Geräteeigenschaften durch den Web
Server oder Proxy Server entfällt [BGGW02]. Der Nachteil ist, dass möglicherweise eine große Menge an Daten an den Client gesendet wird von
denen er aber nur einen Teil darstellen kann. Gerade bei Mobiltelefonen,
bei denen die Bandbreite in der Regel nicht besonders hoch ist und nach
Datenvolumen abgerechnet wird, kann dies problematisch werden. Die Adaptierung am Client erfolgt in der Regel durch verschiedene CSS Stile [CSS]
die abhängig von den CSS Media Typs angewendet werden (siehe Listing
3.4). Im Gegensatz zur Adaptierung am Proxy Server hat der Autor einfach
die Möglichkeit die Adaptierung durch die Definition eines Styles zu beeinflussen. Dabei ist zu beachten, dass Inhalt und Layout streng von einander
getrennt werden.
Listing 3.4: CSS Stil mit Styledefinitionen für die verschiedenen Endgeräte
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/* media - dependent foreground / background colours */
@media screen , print , handheld
{ body { color: black ; background - color: white } }
@media projection , tv
{ body { color: white ; background - color: blue } }
/* media - dependent font family */
@media screen , handheld , tv , projection
{ body { font - family: helvetica , sans - serif } }
@media print
{ body { font - family: times , serif } }
/* media - dependent text appearance */
@media screen , print
{ body { font - size: 12 pt } }
@media handheld
{ body { font - size: 10 pt ; line - height: 80% } }
@media projection , tv
{ body { font - size: 16 pt ; font - weight: bold } }
/* increase width of borders on tv to avoid flicker */
@media tv
{ body { border - width: thick } }
34
Abbildung 3.3: Server Side Adaptation
Server Side Adaptation Hierbei hat man fast alle nur denkbaren Möglichkeiten
zur Adaptierung, die nur durch den Implementierungsaufwand (Kosten/Nutzen) eingeschränkt werden. Die Adaptierungsmethoden sind in der Regel speziell für die Anwendung entwickelt und man muß nur wenige Kompromisse in Kauf nehmen. Nur bei der serverseitigen Adaptierung ist es
möglich eine speziell für den Client angepasste Version unter Berücksichtigung aller Kontextfaktoren, zur Verfügung zu stellen. Für ubiquitäre WebAnwendungen ist Server Side Adaptation daher die einzig praktikable Vorgehensweise.
Da bei der Entwicklung einer ubiquitären Web-Anwendung schon von Beginn
an klar ist, dass die Inhalte auch mobilen Endgeräten in großen Umfang zugänglich gemacht werden müssen, ist in diesem Fall die serverseitige Adaption die beste
Lösung. Aus diesem Grund wird im Folgenden speziell auf die Adaptierungstechniken für serverseitige Adaptierung eingegangen. Auch bei dem entwickelten Prototyp wurden ausschließlich serverseitige Adaptierungstechniken eingesetzt (siehe
Kapitel 5).
3.3.2 Adaptierungstechniken
Im folgenden Abschnitt werden einige Adaptierungstechniken für die Endgerätunabhängigkeit von ubiquitären Web-Anwendungen bei serverseitiger Adaptierung
vorgestellt. Jede dieser Techniken kann entweder einzeln zum Einsatz kommen
oder in Kombination mit anderen Techniken.
Aggregation
Bei der Aggregation werden mehrere Inhalte von verschiedenen Quellen zu einer
Seite zusammengestellt. Dabei wird davon ausgegangen, dass die Inhalte einer
35
Seite (zB der Artikel eines Redaktionsystems) sich aus verschiedenen Komponenten zusammensetzen und diese Komponenten wieder in verschiedenen Versionen
für die jeweiligen Endgeräte existieren. Je nach Fähigkeiten des Endgeräts werden nur die vom Endgerät unterstützten Komponenten ausgewählt und so der
eigentliche Inhalt der Seite erstellt. Dabei ist natürlich zu beachten, dass der
Sinn des Inhalts nicht verloren geht. Aggregation kann auch gut mit den anderen
im Folgenden vorgestellten Adaptierungstechniken kombiniert werden.
Dekomposition
Unter Dekomposition wird die Aufteilung der Inhalte eine Seite in kleinere dem
Endgerät angepasste Einheiten verstanden [W3C004a]. Da mobile Endgeräte in
der Regel über kleinere Bildschirme verfügen, ist es sinnvoll die Darstellung einer
Seite die für eine normale Auflösung entwickelt wurden, in kleinere Einheiten zu
unterteilen. Dadurch werden einerseits die Ladezeiten verkürzt und lange unangenehme Scrollbalken vermieden. Für die Implementierung der Dekomposition gibt
es eine Vielzahl an Ansätzen. So kann man den Text zB automatisch nach einer
beliebigen Anzahl an Sätzen abbrechen, was aber unter Umständen dazu führen
kann, dass der Sinn des Inhalts oder der Lesefluss beeinträchtigt werden. Um
dies zu vermeiden kann man Techniken einführen die es dem Autor erlauben auf
die Dekomposition Einfluss zu nehmen. Drei mögliche Ansätze, d.h. Kommentare mit Page Breaks, Absätze bzw. Sektionen und Regions, werden im Folgenden
kurz vorgestellt.
Kommentare mit Page Breaks Dies ist der gängigste Ansatz. Der Autor fügt
an der Stelle im Text an der die Seite umbrechen soll (zB nach einem Absatz) einen vordefinierten Kommentar oder ein anders vordefiniertes Zeichen ein. Bei der Adaptierung wird die Seite dann genau an dieser Stelle
umgebrochen. Abbildung 3.3.2 veranschaulicht dieses Konzept.
Abbildung 3.4: Dekomposition mit Hilfe von Kommentaren
36
Absätze bzw. Sektionen Dabei werden die Seiten nach den HTML Überschrift
Tags <hn> über jedem Absatz aufgeteilt (siehe Abbildung 3.3.2). Somit
kann auch gleich automatisch anhand der Überschriften ein (hierarchisches)
Inhaltsverzeichnis erstellt werden. Dieses Konzept kann auch auf die in
XHTML 2.0 neu eingeführten Sektionen (siehe Listing 3.5) angewandt werden.
Abbildung 3.5: Dekomposition mit Hilfe von Überschriften
Listing 3.5: Überschriften vs. Sektionen in XHTML 2.0
1
2
3
HTML / XHTML
< h1 > Überschrift 1 </ h1 >
< h2 > Überschrift 2 </ h2 >
4
5
6
7
8
9
10
11
XHTML 2.0
< section >
<h > Titel </ h >
< section >
<h > Titel </ h >
</ section >
</ section >
Regions Regions sind Teile im Text, die durch ein Beginn und ein Endzeichen
markiert sind. Dies können entweder proprietäre Zeichen wie spezielle Kommentare sein oder HTML Tags wie oder <div>, die auch durch ihr
ID Attribut eindeutig identifiziert werden können. Abbildung 3.3.2 veranschaulicht dieses Konzept mit proprietären Anweisungen.
Transcoding
Unter Transcoding versteht man die Veränderung des HTML-Codes an die Anforderung des jeweiligen Endgeräts. So könnte man zB HTML in cHTML transformieren. cHTML ist eine kleinere Teilmenge von HTML bei der auf komplizierte
und unflexible Präsentationsstrukturen wie zB Tabellen verzichtet wird. Generell ist das Transcoding der mit Abstand komplizierteste Vorgang im gesamten
37
Abbildung 3.6: Dekomposition mit Hilfe von Regions
Prozess der endgerätunabhängigen Adaptierung. Um ein zufriedenstellendes Ergebnis zu erhalten sind genaue Regeln notwendig, die angeben wie die einzelnen
Codefragmente transformiert werden sollen und dennoch müssen sie auch eine
gewisse Fehlertoleranz zulassen. Im Folgenden werden zwei verschiedene Transcodingansätze vorgestellt.
XSLT XSLT steht für Extensible Stylesheet Laguage Transformation [W3CX99]
und ist eine Sprache zur Transformation von XML Dokumenten. Dabei
werden Templates, die Transformationsregeln enthalten, auf die Knoten
des XML-Dokuments angewandt. Die Knoten werden mit Hilfe von Patterns selektiert, die auf XPath basieren. Die Ausgabe eines solchen XSLTStylesheets kann wieder XML sein aber auch (X)HTML, RDF, CSV, oder
jedes andere Textformat.
Listing 3.6: XHTML Dokument vor der Transformation
1
2
3
4
5
6
7
8
9
10
11
<? xml version = " 1.0 " ? >
<! DOCTYPE html PUBLIC " -// W3C // DTD XHTML 1.1// EN " " http: // www . w3 . org / TR /
xhtml11 / DTD / xhtml11 . dtd " >
< html xmlns = " http: // www . w3 . org /1999/ xhtml " xml:lang = " en " >
< head >
< title > Test document </ title >
</ head >
< body >
< h1 > Test document </ h1 >
 This paragraph indicates the rest of the document . 
</ body >
</ html >
Listing 3.7: XSLT Dokument
1
2
3
4
5
<? xml version = " 1.0 " ? >
< xsl:stylesheet version = " 2.0 "
xmlns:xhtml = " http: // www . w3 . org /1999/ xhtml "
xmlns = " http: // www . w3 . org /1999/ xhtml "
xmlns:xsl = " http: // www . w3 . org /1999/ XSL / Transform "
6
7
8
9
10
38
xmlns:xs = " http: // www . w3 . org /2001/ XMLSchema "
xmlns:fn = " http: // www . w3 . org /2005/02/ xpath - functions "
xmlns:xdt = " http: // www . w3 . org /2005/02/ xpath - datatypes "
exclude - result - prefixes = " xhtml xsl fn xs xdt " >
< xsl:output method = " xml " version = " 1.0 " encoding = " UTF -8 " doctype - public = " -//
W3C // DTD XHTML 1.1// EN " doctype - system = " http: // www . w3 . org / TR / xhtml11 /
DTD / xhtml11 . dtd " indent = " yes " / >
11
12
13
14
15
16
17
<! -- the identity template -- > < xsl:template match = " @ *| node () " >
< xsl:copy >
< xsl:apply - templates select = " @ *| node () " / >
</ xsl:copy >
</ xsl:template >
18
19
20
21
22
23
24
< xsl:template match = " xhtml:head " >
< xsl:copy >
< link rel = " StyleSheet " href = " xhtml_test . css " type = " text / css " / >
</ xsl:copy >
</ xsl:template >
25
26
27
28
29
30
31
32
33
34
< xsl:template match = " xhtml:body " >
< xsl:copy >
< div class = " menu " >
 <a href = " home " > Homepage </ a > & gt ; Test document 
</ div >
</ xsl:copy >
</ xsl:template >
</ xsl:stylesheet >
Listing 3.8: XHTML Dokument nach der Transformation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<? xml version = " 1.0 " ? >
<! DOCTYPE html PUBLIC " -// W3C // DTD XHTML 1.1// EN " " http: // www . w3 . org / TR /
xhtml11 / DTD / xhtml11 . dtd " >
< html xmlns = " http: // www . w3 . org /1999/ xhtml " xml:lang = " en " >
< head >
< link rel = " StyleSheet " href = " xhtml_test . css " type = " text / css " / >
< title > Test document </ title >
</ head >
< body >
< div class = " menu " >
 <a href = " home " > Homepage </ a > & gt ; Test document 
</ div >
< h1 > Test document </ h1 >
 This paragraph indicates the rest of the document . 
</ body >
</ html >
Transcoding mit Annotationen Dabei wird das HTML Dokument mit Hilfe von
Annotationen, also Anmerkungen transformiert [IBM06]. Die Annotationen enthalten dabei Informationen zur Transformation. Diese können aber
39
nicht im HTML Dokument stehen, da sie dort den HTML-Standard verletzen würden. Darum werden die Annotationen in einer RDF [RDF04]
Datei gespeichert. Die Verbindung zwischen den Annotationen und dem
zu transformierenden Dokument bzw. Knoten im Dokument wird mit Hilfe
von XPointer [XPTR02] hergestellt. XPointer ist eine Weiterentwicklung
von XPath [XPAT99] um einzelne Elemente in HTML Dokumenten zu selektieren.
Medienadaptierung
Medienressourcen wie Bilder oder Videos werden bei der Medienadaptierung auf
die jeweiligen Anforderungen bzw. Einschränkungen des Endgeräts angepasst.
Die Adaptierung von Bildern ist in der Regel relativ einfach möglich. Dabei werden Auflösung, Kompression (Dateigröße) und Farbtiefe angepasst, aber auch
die Umwandlung in ein anderes Format (zB JPEG in WBMP) ist möglich. Die
Umwandlung der Bilder in ein bestimmtes Format erfolgt normalerweise nur einmal, wenn das Bild das erste Mal vom Server abgerufen wird, dann wird es aus
Performance Gründen zwischengespeichert. Ähnlich verhält es sich bei der Adaptierung von Videos, nur ist da die Umwandlung in verschiedene Größen noch
rechenaufwändiger und es werden meist spezielle Programme dazu benötig. Aus
diesem Grund werden Videos selten direkt von der Web-Anwendung umgewandelt, sondern der Autor stellt mehrere Versionen zur Verfügung aus denen dann
die passende selektiert wird.
In diesem Kapitel wurden eine Vielzahl von verschiedenen Ansätzen für die Adaptierung von Web-Anwendungen auf die Anforderungen von mobilen Endgeräten
vorgestellt. Welche Kombination aus den verschiedenen Ansätzen die beste ist,
hängt in der Regel stark von den Services ab, die die Anwendung den Benutzern zur Verfügung stellt und natürlich auch von dem Aufwand den man bei
der Entwicklung betreiben will. Wir haben uns für serverseitige Adaptierung in
Verbindung mit Flexible Authoring, und einer Kombination aus mehreren Adatierungstechniken die abhängig vom Nutzungskontext zum Einsatz kommen, entschieden. Diese Lösung für das Tourismusinformationssystem, das im Zuge dieser
Arbeit entwickelt wurde, wird in Abschnitt 5.3 vorgestellt.
40
Kapitel 4
Technische Konzeption und
Funktionsumfang des entwickelten
Tourismusinformationssystems
Im Zuge dieser Arbeit wurde eine praxisnahe, ubiquitäre Web-Anwendung entwickelt. Um möglichst viele Beispiele zur Customization zu zeigen, entschlossen
wir uns, als Forschungsprototyp ein Tourismusinformationssystem zu implementieren.
Gerade die Bedürfnisse eines Urlaubsgasts sind ein Paradebeispiel für die Notwendigkeit des anytime/anywhere/anymedia Paradigma von ubiquitären WebAnwendungen. Dieser hat den Wunsch, sich im Urlaub überall mit seinem Handy/PDA oder über einen beliebigen Internetzugang über Freizeitangebote und
aktuelle Angebote in seiner Urlaubsregion zu informieren. Die ubiquitäre WebAnwendung passt sich dabei immer an die momentane Situation des Benutzers an
und liefert ihm zusätzlich noch die für ihn interessantesten Informationen direkt
auf der Startseite.
4.1 Allgemeine Beschreibung
Die Grundidee besteht darin, ein Tourismusinformationssystem zu entwickeln,
das dem Benutzer objektive und tagesaktuelle Informationen zu den verschiedenen Urlaubsorten liefert. Es soll eine Plattform geboten werden, die dem Benutzer einerseits vor dem Urlaub eine Entscheidungshilfe, wo er seinen Urlaub
verbringen möchte, und andererseits während des Urlaubs ein ständiger Begleiter
und Ratgeber ist. Darin liegt auch der große Unterschied zu bereits vorhandenen
Tourismusinformationssystemen, da der Gast mit dem System umfangreiche und
tagesaktuelle Informationen zu allen möglichen Freizeitaktivitäten, dem Wetter,
4 Technische Konzeption und Funktionsumfang des entwickelten
41
der Schneelage, Events, Lokale, usw. einer Region seiner Wahl geliefert bekommt
und somit auch während seinem Aufenthalt eine ständige und zuverlässige zentrale Informationsquelle zur Verfügung hat.
Gerade im Vergleich mit anderen Tourismusinformationssystemen12 wird sofort
klar, dass diese großteils nur ’Presales’-Informationen zur Verfügung stellen. Bereits auf der Startseite finden sich eine Vielzahl an Preisen und Buchungsmöglichkeiten. Das erklärte Ziel der Anwendungen ist, den Benutzer auf Urlaub in Österreich zu schicken, aber man hat immer den Eindruck es soll primär ein bestimmtes
Angebot verkauft werden. Für detaillierte Informationen über einzelne Regionen und deren Angebote wird meist auf die Seite des lokalen Tourismusverbands
verwiesen. Das von uns entwickelte System sollte sich genau dieser Problematik annehmen und die Angebote abseits der Hotelzimmer zentral und objektiv
präsentieren. Mit Zusatzfunktionalitäten für registrierte Benutzer soll eine ’Community’ geschaffen werden, welche auch die Möglichkeit hat, einzelne Angebote
zu bewerten und zu kommentieren. Gerade der Kontrast von den aufdringlichen
Angeboten auf den bereits vorhandenen Anwendungen zu den eher unauffälligen
Möglichkeiten der gezielten Information bei einer ubiquitären Web-Anwendung
macht den Reiz an der Entwicklung eines solchen Systems aus.
4.2 Basisfunktionalität
Die Web-Anwendung teilt sich in zwei getrennte Anwendungsgebiete, die ContentErstellung (Backend ) und die Content-Nutzung (Frontend ). Das Frontend dient
primär dazu, dem Endbenutzer Informationen anzuzeigen, die im Backend von
Redakteuren und anderen Content-Erstellern eingegeben und gepflegt werden.
Der Funktionsumfang der Web-Anwendung wird im Folgenden anhand von UML
Use Case Diagrammen näher beschrieben.
4.2.1 Funktionen für den Endbenutzer (Frontend)
Abbildung 4.1 zeigt die möglichen Anwendungsfälle für Benutzer des Frontend.
Dieser Funktionsumfang steht im System angemeldeten Usern zur Verfügung.
Anonyme Benutzer können die Hauptfunktionalität - Content browsen, nach Informationen suchen, Sprache einstellen und Newsletter abonnieren - ausführen,
sowie sich als Benutzer anmelden um auch Ratings abgeben und den Reisekoffer
nutzen zu können.
1
2
http://www.tiscover.at/
http://www.austria.info/
42
Abbildung 4.1: Frontend Use Case
Content browsen. Content browsen ist die Grundfunktion im Frontend. Hier
kann der Benutzer nach Regionen oder Urlaubs- und Aktivitätsthemen gegliedert die verschiedenen Informationen durchstöbern. Die Informationen
werden in Form von Artikeln dargestellt und bestehen aus Text und optionalen Bildern. Die Artikel werden in einer an den Benutzer angepassten
Reihenfolge geliefert, dh. Artikel, die den Benutzer mehr interessieren könnten, werden in der Liste zuerst angezeigt.
Reisekoffer anzeigen. Angemeldete Benutzer können sich interessante Artikel in
ihrem persönlichen Reisekoffer“, ähnlich einem Warenkorb in bekannten
”
E-Commerce Anwendungen, speichern um später einfacher auf die Information zugreifen zu können.
43
Artikel drucken. Die Artikel können gedruckt werden.
Artikel löschen. Die Artikel im Reisekoffer können wieder gelöscht
werden.
Erinnerung aktivieren. Darüber hinaus können zu bestimmten Artikeln im Reisekoffer Erinnerungen aktiviert werden, wodurch der Benutzer
wahlweise per E-Mail oder SMS, rechtzeitig vor Beginn des Events, der
Aktivität, etc. informiert wird.
Kommentar abgeben. Angemeldete Benutzer können zu einem Artikel ein
Kommentar und eine Empfehlung für verschiedene Urlaubstypen“ abge”
ben. Urlaubstypen sind beispielsweise Familie mit Kindern“, Ältere Ur”
”
lauber“ oder Extremsportler“.
”
Artikel suchen. Der Benutzer kann eine Volltextsuche in allen Artikeln
durchführen.
Benutzer Anmelden. Um die Web-Anwendung noch besser auf seine persönlichen Anforderungen anzupassen und auch Ratings abgeben und den Reisekoffer nutzen zu können, kann sich der Benutzer im System anmelden. Vor
der ersten Anmeldung ist eine Registrierung notwendig.
Benutzer registrieren. Bei der Registrierung kann der Benutzer eine
bevorzugte Sprache und einen Urlaubstyp“ wählen, der auf ihn zutrifft.
”
Profil aktualisieren. Die gespeicherten Informationen können jederzeit wieder bearbeitet werden.
Newsletter abonnieren. Jeder Benutzer hat die Möglichkeit, sich zu einem
Newsletter an- und abzumelden. Basierend auf den erfassten Daten des
Benutzer und anderen Faktoren, wie zum Beispiel die aktuelle Jahreszeit,
spezielle Events, ... werden die Newsletter für den einzelnen Benutzer individuell vom System angepasst und in regelmäßigen Abständen versandt.
Sprache einstellen. Der Benutzer kann zwischen verschiedenen Sprachen
wählen, in denen die Web-Anwendung angezeigt wird. Dabei kann er
entweder direkt in der Weboberfläche umschalten. Wenn der Benutzer
angemeldet ist, kann er in seinem Profil die gewünschte Sprache speichern.
Beim Start der Web-Anwendung wird bei angemeldeten Benutzern die im
Profil eingestellte Sprache gewählt und bei nicht angemeldeten Benutzern
wird die Sprache aus dem Request Header erkannt.
44
Geplante Funktionen
Folgende Frontend-Funktionen sind für spätere Versionen der Web-Anwendung
geplant:
User-Page. Die User-Page ist eine Möglichkeit für den angemeldeten Benutzer,
seine Urlaubserfahrungen mit anderen zu teilen. Hier kann eine Liste der
Lieblings-Artikel veröffentlicht werden, Urlaubsberichte und Bildergalerien
erstellt werden, etc.
Wo kann ich ... Die Funktion Wo kann ich ...“ erweitert die Volltextsuche
”
und erlaubt eine spezielle Suche nach Orten und Regionen, in denen vom
Benutzer bevorzugte Aktivitäten möglich sind.
4.2.2 Funktionen für die Redaktion (Backend)
Das Backend stellt die Funktionalität zur Content-Erstellung bereit. Hier werden
zwei Rollen unterschieden, Redakteur“ und Tourismusverband“ (TVB). Die
”
”
Rolle Redakteur ist ein systeminterner Mitarbeiter und für die Administration
der Web-Anwendung zuständig. Der Redakteur verwaltet Kategorien, Benutzer
der Rolle TVB und kann das Layout und die Struktur der Web-Anwendung für
verschiedene Endgeräte anpassen. Benutzer mit der Rolle TVB können für ihre Region Inhalte erstellen und verwalten. In Abbildung 4.2 sind alle Anwendungsfälle dargestellt.
Artikel bearbeiten. Dies ist die Hauptfunktion des Backend und die einzige,
die ein Benutzer mit der Rolle TVB durchführen kann. Es können Artikel zu bestimmten Orten und Kategorien (zB Wintersport, Kultur, etc.)
in verschiedenen Sprachen angelegt, bearbeitet und gelöscht werden. Die
Informationen können durch verschiedene Contentparts strukturiert und
mit Hilfe eines in der Anwendung integrierten HTML WYSIWYG3 -Editors
formatiert werden. Contentparts sind Teile eines Artikels und können derzeit Text und Bild enthalten. Contentparts mit Multimediainhalten sind
ebenso denkbar. Die Bilder, die zu den Artikel gespeichert werden können,
werden automatisch in der Größe und im Corporate Design der Weboberfläche (Rahmen, Schlagschatten, leichte Drehung) angepasst. Auf Wunsch
wird ein kurzer Titel auf das Bild geschrieben. Zu jedem Artikel kann die
Kommentar-Funktion ein- oder ausgeschaltet werden und der Artikel als
unsichtbar markiert werden. Weiters kann eine Tageszeit angegeben werden, zu der der Artikel besonders interessant ist.
3
What You See Is What You Get
45
Abbildung 4.2: Backend Use Case
Artikelpositionen festlegen. Der Redakteur kann für bestimmte Artikel die an
den Benutzer angepasste Reihenfolge ausschalten und fix an die oberste
Stelle in der Artikelliste platzieren. Dies ist beispielsweise für bezahlte Inhalte (Werbung) nützlich.
Kategorien bearbeiten. Der Redakteur kann in verschiedenen Sprachen Kategorien anlegen, bearbeiten und löschen. Kategorien werden zu Saisonen (Sommer/Winter) zugeordnet und gliedern Urlaubs- und Aktivitätsthemen, zu
denen die Artikel angelegt werden können. Kategorien sind zB Schifahren,
Kultur oder Wellness.
Layout ändern. Der Redakteur kann das Layout, also die Struktur der WebAnwendung für verschiedene Endgeräten verändern. Die Struktur gibt die
Reihenfolge und Position der einzelnen Elemente der Web-Anwendung an.
TVB bearbeiten. Der Redakteur kann Benutzer der Rolle TVB anlegen, bearbeiten bzw. löschen und ihre Berechtigungen verwalten.
Frontend Benutzer löschen. Der Redakteur kann Benutzer des Frontends
löschen.
46
Anwendungsfälle, die keinen Einfluss auf die Customization haben, wurden
zwar in der Datenbank berücksichtigt, aber nicht implementiert. Nicht implementierte Use Cases im Frontend sind Artikel suchen, Newsletter abonnieren
und Erinnerung aktivieren, im Backend wurde auf die Anwendungsfälle TVB
bearbeiten, Frontend Benutzer löschen und Layout ändern verzichtet.
4.3 Evaluierung der Customizationfunktionalität
In diesem Kapitel wird der Umfang der Customizationfunktionalität des entwickelten Forschungsprototypen anhand des Evaluation-Frameworks für ubiquitäre
Web-Anwendungen aus [KPRS03] analysiert. Prinzipiell umfasst dieses Framework die beiden Dimensionen der Customization, namentlich den Kontext und
die Adaptierung, wobei diese anhand eines umfangreichen Kritierenkatalogs für
die jeweilige Web-Anwendung erfasst werden. Aus diesen Kriterien kann in Folge
der Umfang der Customization und allfällige Stärken und Schwächen abgeleitet
werden. Diese sind hierbei so gewählt, dass einerseits Anforderungen, welche bei
der Entwicklung von ubiquitären Web-Anwendungen umgesetzt werden sollten,
erfasst werden. Anderseits sind aber auch Kriterien aufgeführt, welche notwendig
sind, damit bestehende Ansätze in diesem Framework mit berücksichtigt werden
können und somit eine gemeinsame Basis für die Charakterisierung von WebAnwendungen unter dem Gesichtspunkt der Ubiquität möglich ist.
In Folge wird nun auf den Kontext, die Adaptierung und ihre Kriterien nach
[KPRS03] im Detail eingegangen und der Forschungsprototyp anhand dieser charakterisiert. In den Tabellen 4.1 und 4.2 werden die Ergebnisse übersichtlich zusammengefasst gezeigt.
4.3.1 Charakteristik des Kontext
Hierbei werden die Umstände der Benutzung der Web-Anwendung erfasst und
anhand von, im Framewerk vorgegebenen, Kriterien analysiert. Eine Beschreibung des Kontextes von ubiquitären Web-Anwendungen ist bereits in Kapitel
2.2.2 erfolgt. In dem Framework erfolgt eine Verdichtung des Gesamtkontextes
auf bestimmte Eigenschaften, welche die Umgebung der Anwendung und diese
selbst beschreiben und den Umfang der Customization bestimmen. Des Weiteren
werden die Kontext-bezogenen Kriterien anhand ihres Umfanges, ihrer Repräsentation, ihrer Akquisition und ihrer Zugriffsmechanismen unterteilt. In Tabelle 4.1
sind die Ergebnisse der Evaluierung des Forschungsprototypen hinsichtlich der
Kontextkriterien zusammengefasst.
47
Kontext Umfang
Dieser umfasst nicht nur die unterschiedlichen Kontext Eigenschaften, welche vom
System bei der Customization unterstützt werden und die damit verbundene
Erweiterbarkeit, sondern auch die Zeitdimension des Kontext in Bezug auf die
Chronologie und Gültigkeit.
Kontextfaktor Die relevanten Kontext Eigenschaften sind natürlich sehr stark
von der zu entwickelnden Web-Anwendung abhängig, jedoch haben sich
in der einschlägigen Literatur Standardfaktoren für ubiquitäre WebAnwendung herauskristallisiert, nämlich die Ort, Zeit, Gerät, Netzwerk, Benutzer und die Anwendung. (Für eine Erläuterung dieser Faktoren siehe
2.2.2.)
Andere Diese Kategorie existiert im Framework nicht. Um aber den
Kontextfaktor Wetter, welchem im Forschungsprototypen eine entscheidende Bedeutung zu kommt, abbilden zu können, wurde diese Kategorie eingeführt. Mit Ausnahme der Anwendung“ werden alle hier aufgezählten
”
Kontextfaktoren von der entwickelten Web-Anwendung berücksichtigt.
Erweiterbarkeit Dieses Kriterium wird dem Anspruch gerecht, dass zusätzliche
Kontextfaktoren, welche nicht zu den genannten Standardfaktoren zählen,
bei bestimmten Anwendungen mit berücksichtigt werden müssen. Nachdem nicht vorhergesehen werden kann, welche Faktoren das eventuell sein
könnten, muss es möglich sein das bestehende System mit zusätzlichen Kontextfaktoren zu erweitern. So können zum Beispiel die Schneelage oder die
Wassertemperatur für gewisse Anwendungen durchaus als wichtige Kontextfaktoren in Betracht kommen. Eine Erweiterung der Kontextfaktoren
bei dem Forschungsprototypen ist durch den Einsatz von aspektorientierter
Programmierung welche die Kontextdetektoren in das System einbindet und
in Kombination mit dem erweiterbar gestalteten Datenbankschema einfach
möglich. In diesem Zusammenhang ist natürlich auch die Einbindung von
externen Datenquellen möglich.
Chronologie Die Erfahrung hat gezeigt, dass nicht nur der aktuelle Kontext sondern auch der historische Kontext für die Customization eine entscheidende
Rolle spielt. So macht es Sinn, die Bandbreite der Verbindung des Benutzers über die Zeit zu verfolgen, um eine Durchschnittsbandbreite ermitteln
und somit die Anwendung darauf abstimmen zu können. So kann man gegebenfalls Bilder verkleinern oder multimedia Inhalte ausblenden, um den
Benutzer bei niedriger Bandbreite trotzdem eine schnelle Benutzung der
48
Web-Anwendung zu ermöglichen. Aber nicht nur der historische sondern
auch der zukünftige Kontext kann für bestimmte Anwendungen sehr wertvoll sein. So ist es beim Videostreaming neben der durchschnittlichen vergangenen Bandbreite genauso wichtig abzuschätzen wie sich diese in der
Zukunft entwickelt, um das Video so anzupassen, dass es zu keiner Unterbrechung und zu einer konstanten Übertragung kommt. Auch das historische
Benutzerverhalten liefert wichtige Daten für die Customization. So werden
im Rahmen des Forschungsprototpyen die Artikel, welche der Benutzer über
die Zeit aufgerufen oder in seinem Reisekoffer gegeben hat, gespeichert um
daraus ein Interessensprofil für die Adaptierung des Inhaltes ableiten zu
können. Die Chronologie der Endgerätnutzung wird jedoch nicht erfasst,
genausowenig wie die Vorhersage von zukünftigem Kontext implementiert
ist.
Gültigkeit Kontextfaktoren sind nicht immer unendlich gültig und können auf
eine ganz bestimmte Zeitspanne beschränkt sein. Im mobilen Bereich wäre
hierfür ein Beispiel, dass, wenn sich der Standort des Gerätes innerhalb einer bestimmten Zeitspanne nicht ändert, dieses vielleicht nicht mehr online
und somit die Ortsinformation nicht mehr gültig ist. Auch geänderte Öffnungszeiten zu verschiedenen Jahreszeiten stellen eine Einschränkung der
Gültigkeit dieser Information dar und führen dazu, dass für einzelne Kontextfaktoren Zeitperioden, innerhalb welcher diese valide sind, spezifiziert
und berücksichtigt werden müssen. Dieses Kriterium wird beim Forschungsprototypen bei dem logischen Kontextfaktor der Saison und tageszeitlich
eingeschränkten Artikel berücksichtigt.
Kontext Repräsentation
Die Repräsentation des Kontext verbindet zwei wichtige Themen, nämlich Mechanismen für die Verbesserung der Wiederverwendung der Kontextrepräsentation
und das Abstraktionsniveau des Kontexts.
Wiederverwendbarkeit Hierbei soll der Kontext explizit im System aufgeführt
sein und nicht nur vermischt mit der Adaptierung an sich vorliegen. Dies hat
den Vorteil, dass der Kontext in anderen Systemen einfach wiederverwendet
werden kann. Auch soll der Kontext, der durch den Customization Ansatz
geliefert wird, generisch sein, also anwendungsunabhängig, wobei ein solcher Kontext auch von externen Anbietern geliefert werden kann. So kann
hier zum Beispiel auf externe GIS4 Daten zurückgegriffen werden. Bei dem
4
Geografisches-Informationssystem
49
entwickelten Forschungsprototypen wurde hierfür auf Aspektorientierung
gesetzt, womit untersucht wurde, ob die angesprochene Trennung des Kontextes von der Programmlogik an sich mit AOP sinnvoll durchzuführen ist.
Mit diesem Ansatz ist auch die Wiederverwendung in anderen ubiquitären
Web-Anwendungen relativ einfach möglich.
Abstraktion Hierunter fallen die Unterscheidung und Behandlung von logischen
und physischen Kontext. Siehe hierzu 2.2.2. Als Beispiel im Forschungsprototypen kann hier einerseits für den physischen Kontext die IP, das Datum und die angesehenen Artikel aufgezählt werden. Der logische Kontext
umfasst unter anderem den aktuellen Standort in Form einer Adresse, die
Saison und das Wetter.
Kontext Akquisition
Hier wird der Grad der Automation und der Grad der Dynamizität der Kontext
Akquisition behandelt.
Automation Hierbei unterscheidet man wer für die Sammlung des Kontext verantwortlich ist. Ist es ein Mensch, so spricht man von manueller Akquisition, ist es ein System, dann ist es die automatische Akquisition. Im Falle einer Kombination von beiden nennt man es halbautomatische Akquisition. Prinzipiell ist es bei ubiquitären Web-Anwendungen erstrebenswert
soviel wie möglich an Information automatisch zu generieren, um die Benutzerinteraktion in diesem Bereich gering zu halten. Physischer Kontext
kann großteils automatisch von der Umgebung erfasst und der daraus resultierende logische Kontext vom System abgeleitet werden. Aber natürlich
funktioniert das nicht überall und so ist es oft nötig, die Kontextfaktoren
halbautomatisch zu erfassen. Dabei wird zum Beispiel vom Benutzer sein
Profil ausgefüllt, woraus das System den logischen Benutzer-Kontext ermittelt (zum Beispiel eine Benutzerkategorie) oder fehlende Daten zu ergänzen
versucht. In der realisierten Web-Anwendung werden zum Beispiel Benutzerdaten teilweise manuell erfasst, das heißt der Benutzer gibt Daten zu
seiner Person selbst ein wie zum Beispiel seinen Namen, sein Geburtsdatum
oder seinen Heimatort. Darüber hinaus wird zum Beispiel die Userkategorie
halbautomatisch, die Endgeräteeigenschaften und die maximale Auflösung,
automatisch erfasst.
Natürlich können wichtige Daten auch fehlen, wenn zum Beispiel der Benutzer zum ersten Mal die Web-Anwendung aufruft. Aus diesem Grund muss
das System so ausgelegt sein, dass es auch mit diesem Fall umgehen kann.
50
Ein Standardansatz hierbei ist es, einen im System definierten DefaultKontext zu benutzen, was auch beim Forschungsprototypen so umgesetzt
wurde.
Dynamizität Ein weiterer wichtiger Punkt ist, wann der Kontext erfasst wird.
Der statische Kontext wird nur einmal erfasst - also zum Beispiel beim Start
der Anwendung - und in Folge nicht mehr verändert, was zum Beispiel bei
der Ermittlung des Gerätes mit dem die Anwendung benutzt wird, ausreichend ist. Ist der Kontext dynamisch, so wird bei jeder Änderung während
der Laufzeit auch der Content angepasst, wobei hier wieder die Bandbreite
ein gutes Beispiel ist. Im Prinzip ist bei ubiquitären Web-Anwendungen
eine dynamische Kontextermittlung nötig, jedoch ist aufgrund von Performanzüberlegungen auch statischer Kontext in gewissem Maße sinnvoll.
Hierbei wird in der Anwendung wiederum beides erfüllt. So wird zum Beispiel das Gerät nur beim Start der Benutzersession ermittelt, wobei hingegen das Wetter bei jedem Request dynamisch erfasst wird.
Kontext Zugriff
Zugriffsmechanismus Hierbei wird die Art der Veranlassung der Adaptierung
auf Basis eines geänderten Kontextes betrachtet. Dies kann durch den push- oder pull -Ansatz realisiert werden. Bei dem push-Ansatz werden die
betreffenden “Clients“ im Falle einer Änderung des spezifizierten Kontextes
sofort automatisch verständigt. Beim pull-Ansatz hingegen muss der aktuelle Kontext von dem Adaptierungsmechanisums selbst angefordert werden,
wenn dieser benötigt wird. Aus Gründen der Flexibilität sind hier Systeme
die beide Ansätze unterstützen, die bessere Wahl. Beim Forschungsprototpyen wurde hier nur der pull-Ansatz verwirklicht. Dies hat auch zur Folge,
dass eine Customization nur auf einen Request vom Benutzer hin erfolgt
und nicht automatisch wenn sich ein Kontextfaktor ändert. So müssen zum
Beispiel bei einer einfachen Customization nach einem Ort, einem Benutzer
und einer Saison sämtliche benötigten Daten von der Adaptierung geholt“
”
werden.
4.3.2 Charakteristik der Adaptierung
In der zweiten Dimension des Evaluation-Frameworks von [KPRS03] wird die
Art der Adaptierung, also was für Operationen durchgeführt werden müssen,
der Gegenstand der Adaptierung und wie das zu geschehen hat, im Prozess der
Adaptierung behandelt.
51
Tabelle 4.1: Evaluierung der Kontext-Charakteristiken nach [KPRS03]
Art der Adaptierung
In Tabelle 4.2 sind die Ergebnisse der Evaluierung des Forschungsprototypen
hinsichtlich der Kontextkriterien zusammengefasst.
Operation Ubiquitäre Web-Anwendungen sollen zumindest eine Bibliothek an
Adaptierungsoperationen für die Behandlung der Standardkontextfaktoren
bieten. Beispiele aus dem entwickelten Forschungsprototypen hierfür sind
Contenfilterung, die Anpassung der Auflösung von Bildern oder die Anpassung der Navigation.
Erweiterbarkeit Gleich wie bei den Kontextfaktoren sollen auch die eingebauten
Adaptierungsvorgänge erweiterbar sein, um geänderten Anforderungen gerecht werden zu können. Dies wird in der Anwendung durch den Einsatz
von aspektorientierter Programmierung und des entwickelten Regelsystems
erreicht. Siehe 2.2.2 und 5.4.2.
Effekt Mit Hilfe der Adaptierungsoperation sollen zumindest drei unterschiedliche Ergebnisse erreicht werden können. Einerseits soll es möglich sein,
bestimmte Teile zur Anwendung hinzu zu fügen, die vorher nicht existent
waren, wie zum Beispiel eine personalisierte Werbung. Des Weiteren sollen
Teile entfernt werden können, wie zum Beispiel sämtlicher multimedialer
Inhalt oder angepasst werden können, wie zum Beispiel die Bildgröße und
Qualität an die Bandbreite der Verbindung des Benutzers. Dies Alles erfüllt
52
der Forschungsprototyp - es können zum Beispiel Contentparts hinzugefügt
oder gelöscht und Bilder an das jeweilige Endgerät angepasst werden.
Komplexität In der Customization sollen nicht nur einfache Adaptierungsoperationen, welche bei einem bestimmten Kontext greifen, möglich sein, sondern
auch komplexe Operationen, welche mehrere Adaptierungsvorgänge auf das
Selbe oder auch auf verschiedene Subjekte angewendet werden. Als Beispiel
kann hierfür die Transformation von der Web-Anwendung auf ein mobiles Endgerät mit einer kleinen Bandbreite, wo die Navigation, die grafische
Oberfläche und der Inhalt angepasst werden muss, genannt werden. Auch
diese beiden Arten der Adaptierung sind mit dem Forschungsprototypen
möglich. So kann eine Adaptierung definiert werden, welche sich nur den
Ort als Kontext heranzieht und auf diese Basis die Anwendung anpasst oder aber genauso komplexe Adaptierungen, welche zum Beispiel die Artikel auf Basis vielen Kontextfaktoren, wie der Saision, dem Ort, dem Wetter,
der Benutzerkategorie,... auswählen und auf Basis der Kontextfaktoren vom
Gerät anpassen.
Subjekt der Adaptierung
Das betroffene Subjekt der Adaptierung wird in dem, dieser Analyse zugrunde liegenden, Framework charakterisiert durch den Level der Web-Anwendung,
genauso wie durch konkrete Elemente und durch die Unterscheidung nach der
Anzahl der betroffenen Elemente, der Granularität.
Level Prinzipiell sollen alle Ebenen einer Web-Anwendung adaptierbar sein [BrMa02] [KaRS00]. Diese Forderung erfüllt auch der Forschungsprototyp. So
wird auf der Inhaltsebene die Artikelauswahl, auf Hypertextebene die Linkstruktur und auf der Präsentationsebene die Darstellung je nach Kontext
angepasst.
Element Jede Ebene einer Web-Anwendung beinhaltet eine Menge an Anwendungselementen, wie zum Beispiel Seiten, Links, Eingabefelder, Listen und
multimediale Inhalte. Jedes dieser Elemente sollte auch anpassbar sein.
In den Bereich Andere fällt bei dem Forschungsprototypen das RatingElement.
Granularity Gibt die Nummer der, durch eine Adaptierung, betroffenen Elemente einer Web-Anwendung an. Hier wird zwischen Mikroadaptierung, welche
nur eines oder wenige Elemente betrifft (wie zum Beispiel das Ausblenden eines Links) und Makroadaptierung, wobei viele, verschiedene Teile der
53
Anwendung verändert werden, unterschieden. Als Beispiel für eine Makroadaptierung kann hier das Ändern sämtlicher Texte, auch in Bildern und
der Navigation, auf der Website in eine andere Sprache herangezogen werden. Im Extremfall wäre eine Makroadaptierung auch die komplette Auswechslung einer Anwendung, wenn diese besser zu dem aktuellen Kontext
passt. Hierbei würde es zum Beispiel ein Anwendung für Desktopbenutzer und ein eigene Anwendung für Benutzer von mobilen Geräten geben.
Hier treffen auch wieder beide möglichen Ausprägungen auf die entwickelte
Web-Anwendung zu. Einerseits werden zum Beispiel einzelne Contentparts
oder Links ausgeblendet, was einer Mikroadaptierung entspricht, oder es
wird die ganze Seite verändert, wenn der Benutzer eben mit einem mobilen
Endgerät die Anwendung benutzt, was wiederum einer Makroadaptierung
entspricht.
Prozess der Adaptierung
Aufgaben Der Adaptierungsprozess umfasst eine Reihe von Aufgaben, welche
zum Zweck der gezielten Steuerung ihrer Automation und Dynamizität aufgeteilt werden sollen. Mit diesem Kriterium wird angegeben, ob die Adaptierung eine Unterteilung in Aufgaben vorsieht und unterstützt. Folgende
Aufgaben werden in dem Framework aus [KPRS03] genannt: Die Initiierung, welche angibt wer oder was den Adaptierungsprozess auslöst. Der
Adaptierunsvorschlag, also was für Möglichkeiten der Adaptierung bestehen, wie zum Beispiel drei unterschiedliche Bildervarianten (schwarzweiß,
klein, groß). Dann die Vorschlagsselektion, welche aufgrund des aktuellen
Kontextes einen Vorschlag auswählt, welcher in der Produktion entweder
dynamisch zur Runtime erstellt oder statisch durch das Laden einer vorgefertigen Version durchgeführt wird. Dies wird in der Präsentation dem
Benutzer angezeigt, welcher unter Umständen über die Revision die eben
durchgeführte Änderung wieder rückgängig machen kann.
Automation Vergleichbar mit der Automation bei dem Kontext wird auch hier
zwischen manueller, halbautomatischer und automatischer Adaptierung unterschieden (siehe auch 2.2.1). Hierbei macht es zum Beispiel Sinn, dem Benutzer zwar eine angepasste Version seiner Startseite einer Web-Anwendung
vorzuschlagen, diesem aber auch die Möglichkeit zu geben, diese nach seinem Willen zu verändern, was einer halbautomatischen Adaptierung entspricht. In dem Forschungsprototypen kann der Benutzer nur zum Teil eingreifen, rein manuell ist nicht möglich. So kann der Benutzer aber zum
54
Beispiel die Sprache oder eine Benutzerkategorie einstellen, was zu einer
halbautomatischen Adaptierung führt. Große Teile der Adaptierung laufen
jedoch vollkommen automatisch ab, als Beispiel sei hier die Anpassung an
das jeweilige Endgerät genannt.
Dynamizität Wie schon beim Kontext zwischen statisch und dynamisch unterschieden worden ist, so wird auch bei der Adaptierung zwischen statischer
und dynamischer Adaptierung unterschieden. Statische Adaptierung bedeutet, dass diese abghänig von gewissen Kontextfaktoren fix vordefiniert ist
und somit nicht geändert werden kann. Dynamische Adaptierung hingegen bedeutet, dass diese zur Runtime, abhängig von den gerade gegebenen Kontextfaktoren, durchgeführt wird. Ein Beispiel ist hier die Adaptierung von Bildern. Werden diese nur zum Beispiel in drei verschiedenen
Größen zur Verfügung gestellt, so spricht man von statischer Adaptierung
- wird die Bildgröße dynamisch, je nach aktueller Anforderung, erzeugt,
ist es hingegen die erwähnte dynamische Adaptierung. In der entwickelten
Web-Anwendung kommen beide Ansätze zum Einsatz. Einerseits werden
hierbei zwei Grundlayouts für die Darstellung der Web-Anwendung geboten, welche je nach Endgerät gewählt werden und statisch vorgegeben sind.
Andererseits wird der Inhalt, also die Auswahl der Artikel, aber auch die
Darstellung dieser, im entsprechenden Layout dynamisch generiert.
Adaptierungsschritte Die Adaptierung muss nicht jedesmal auf das Neue erfolgen. So kann das Ergebnis einer Adaptierung persistent gehalten werden
und muss bei einer erneuten Anforderung nicht nochmal durchgeführt werden, was eine erhebliche Performanzsteigerung bewirken kann. Als Beispiel
kann wieder die Kompression eines Videos genannt werden. Ansätze hierfür
sind im Forschungsprototypen umgesetzt. So wird zum Beispiel die Linkstruktur der Kategorien und Orte entsprechend der Sprache und vorhandenen Artikel zwischengespeichert und nur im Bedarfsfall, zum Beispiel bei
Änderungen im Backend, neu geladen und adaptiert.
55
Tabelle 4.2: Evaluierung der Adaptierungs-Charakteristiken nach [KPRS03]
4.4 Architektur
4.4.1 Schichten-Architektur der realisierten Web-Anwendung
Der Forschungsprototyp wurde nach dem MVC5 -Model 4.3 designt und implementiert eine Schichten-Architektur, welche die wohl gebräuchlichste Methode
ist, um komplexe Systeme in weniger komplexe Teile aufzuteilen. Der große Vorteil besteht darin, dass die eine Schicht immer nur mit der nächsten unter ihr
kommuniziert, aber nichts von den Funktionen der darunterliegenden Schicht
wissen muss. Das bedeutet, dass jede Schicht die Schichten unter ihr vor den
darüberliegenden Schichten verbirgt. Dadurch werden die Abhängigkeiten unter
den Schichten minimiert, jede Schicht ist ein in sich schlüssiges System und die
Möglichkeiten zur unabhängigen Modellierung, Enwicklung und eventuell späteren Standardisierung werden vereinfacht [Demo06].
Im Folgenden werden die Schichten des verwendeten Fünf-Schichten-Modells
kurz erläutert, siehe auch Abbildung 4.4.
Presentation Layer Ist jene Schicht, mit der der Benutzer interagiert. Im konkreten Fall sind dies JSP Seiten die HTML-Code erzeugen, der im Browser
des Benutzers dargestellt wird. Alle Eingaben und Aktionen werden vom
Benutzer auf dieser Schicht getätigt und dann von den darunter liegenden
Schichten ausgeführt bzw. bearbeitet.
Controller Layer Alle Benutzereingaben werden hier validiert und in die jewei5
Model View Controller
56
Abbildung 4.3: MVC-Modell
ligen Klassen der darunter liegenden Schicht, dem Business Layer weitergeleitet, danach entscheidet der Controller mit Hilfe der Informationen aus
der darunter liegenden Schicht, welche Seiten und Inhalte angezeigt werden
und in welcher Reihenfolge dies geschieht.
Business Layer Dieser ist der komplexeste Teil, hier befindet sich der Großteil
der Prozesslogik einer Anwendung. Alle Auswertungen finden auf dieser
Schicht statt, zum Beispiel das Erfassen des physischen Kontextes und die
darauf folgende Ableitung des logischen Kontextes.
Data Mapper Layer Diese Schicht kapselt die CRUD6 -Funktionen einer Datenbank wie insert, update, select oder delete von den Objekten des Business
Layers ab und stellt eigene Klassen zur Verfügung, die den Tabellen in der
Datenbank entsprechen. Somit sind alle datenbankspezifischen Funktionen
auf einer Schicht angesiedelt, ein nicht zu übertreffender Vorteil, wenn die
Anwendung beispielsweise mit Datenbanken verschiedener Hersteller funktionieren soll.
Data Layer Im Data Layer geschieht die eigentliche persistente Datenhaltung.
Dies kann auf verschiedenste Arten geschehen zum Beispiel durch Datenbanken, XML Dateien oder andere Dateisysteme.
4.4.2 Datenbank-Schema
Bei der Konzeption der Datenbank wurde speziell auf die Anforderungen eines
Tourismusinformationsystems eingegangen, wobei dies von Beginn an unter dem
Gesichtspunkt einer maximalen Customization erfolgt ist. Damit wurde sichergestellt, dass einerseits der von Anfang an geplante Kontext entsprechend gespeichert wird und so gestaltet ist, dass dieser auch im nach hinein einfach erweitert
6
Create Read Update Delete
57
Abbildung 4.4: Architektur
werden kann. Mit eine Folge von dieser Herangehensweise war es, dass bei dem
Entwurf des Datenbankschemas im Speziellen darauf geachtet wurde die Daten
gekapselt und möglichst redundanzfrei zu speichern, um auch auf der Ebene der
Datenbasis den Seperation of Concerns“ Gedanken umzusetzen.
”
In der Abbildung 4.5 ist die Datenbankstruktur dargestellt, wobei aus Gründen
der Übersichtlichkeit hierbei die Übersetzungstabellen für die einzelnen Entitäten
nicht abgebildet sind. Mit Hilfe dieser Übersetzungstabellen ist es möglich, das
System mit beliebig vielen Sprachen basierend auf beliebigen Zeichensätzen zu
erweitern. Welche Tabellen eine eigene Übersetzungstabelle besitzen wird durch
den Stereotyp dict angezeigt.
Die Kerndaten des Systems sind die Artikeldaten. Diese werden hierbei verteilt
auf mehrere Tabellen gespeichert, was den Vorteil hat, dass ein Artikel einfach
aus unterschiedlichen Teilen bestehen und je nach Anforderung zusammengestellt
werden kann. Das Grundgerüst eines Artikels ist der ArticleFrame, welcher auch
jene Metadaten zu einem Artikel beinhaltet, die sprachübergreifend gelten und
welche wiederum Einfluss auf die Customization haben. Ein Beispiel ist hier das
Attribut IsOutdoor : Bezieht sich ein Artikel auf eine Aktivität im Freien, so ist
dieses Attribut wahr - was bei schlechtem Wetter zur Folge hat, dass dieser Artikel
Abbildung 4.5: Datenbank-Schema
58
59
nicht oder zumindest nur nach Artikel, welche nicht im Freien sind, angezeigt
wird.
Der Inhalt eines Artikels an sich wird sprachspezifisch in der Article Tabelle
gespeichert.
Mit der Contentpart Tabelle und den damit verbundenen Tabellen ist es
möglich, einerseits einen Artikel um einzelne, vorgegebene Teile zu erweitern, wie
zum Beispiel einem Rating-Modul, oder aber auch einfach zusätzlich neue Module
für die Artikelgestaltung im Nachhinein zur Web-Anwendung hinzuzufügen, wie
zum Beispiel ein Galerie-Modul.
Benutzerdaten werden genauso erfasst, wie auch ein Benutzer einer Kategorie
zugewiesen wird, was wiederum, neben seinem aufgezeichnetem Interaktionsverhalten in der Web-Anwendung (angesehene Artikel, Artikel in seinem Reisekoffer, abgegebene Ratings), natürlich in die Customization einfließt. Hierbei spielen
natürlich auch die Kategorien, die Jahreszeit und der Ort eine wichtige Rolle.
4.5 Adaptierungsszenario
Im folgenden Abschnitt soll der Unterschied zwischen einer herkömmlichen und
einer ubiquitären Web-Anwendung verdeutlicht werden. Hierzu wird dasselbe Szenario einmal mit und einmal ohne, den für die Customization nötigen Modulen
und Daten, dargestellt. Abbildung 4.6 zeigt den Ablauf eines Requests ohne Customization. Dabei werden die ausgewählten Artikel nur nach den Navigationsparametern (wie zum Beispiel die Kategorie oder den Ort auf den der Benutzer
gerade geklickt hat) und gespeicherten Userdaten (wie zum Beispiel Usertyp) ausgewählt. Um die Unterschiede besser darstellen zu können wird folgendes Szenario
definiert.
• Ein dem System bereits bekannter Benutzer loggt sich am Donnerstag, dem
9.3.2006 um 09:00 Uhr von einem PC aus in die Web-Anwendung ein. Die
aktuelle Saison ist die Wintersaison, der Standort des Users ist Haus im
Ennstal. Das aktuelle Wetter: -6◦ C und leichter Schneefall. Der Terminal
verfügt über eine Internetverbindung mit hoher Bandbreite. Der User hat
in seinem Profil folgende Daten bekannt gegeben:
Alter:
Heimatregion:
Bevorzugte Sprache:
Ich würde mich selbst Charakterisieren als:
24
Mödling, Niederösterreich
Deutsch
Jung und Aktiv
60
Abbildung 4.6: Requestablauf ohne Adaptierung
Wird das definierte Szenario auf den Requestablauf in Abbildung 4.6 angewandt, so würden für eine Adaptierung nur die Benutzerdaten und jeweilige Navigationsparameter für die Artikelauswahl zur Verfügung stehen. Nach dem Login
würde der Benutzer wahrscheinlich die gleiche Startseite wie alle anderen Benutzer seiner Region erhalten. Das beschriebene Szenario lässt aber darauf schließen,
dass der Benutzer nicht auf der Suche nach, beispielsweise Wintersportangeboten
in Niederösterreich ist, sondern sich bereits auf Urlaub in Haus im Ennstal befindet und eventuell gerne Informationen über die Pistenverhältnisse und Events
in seinem Wintersportort hätte. Um das zu erreichen muss die Web-Anwendung
bei der Artikelauswahl für die Startseite mehr Informationen berücksichtigen.
Abbildung 4.7: Requestablauf mit Adaptierung
61
Abbildung 4.7 zeigt nun wie der Controller der Anwendung erweitert werden
muss, um dies zu erreichen. Die zusätzlichen Module werden über aspektorientierte Programmierung in die Anwendung eingebunden. Bei Instanzierung der
Session liest der Kontext Detector eventuelle CC/PP7 Informationen aus, diese
betreffen größten teils das verwendete Endgerät also Beispielsweise: Hersteller
und Typ des Geräts, Bildschirmauflösung und Art der Tastatur usw. Weiters
liest der Kontext Detector alle wichtigen Informationen aus dem Request Header, also IP-Addresse, bevorzugte Sprache, Browsersprache usw. All diese Kontext
Daten stehen die ganze Session über zur Verfügung. Zusätzlich zu den Kontextinformationen werden nun auch noch Daten aus dem Artikel-Benchmark und die
Adaptierungsregeln für die Auswahl der Artikel berücksichtigt. Sie werden mit
Aspekten direkt in den Content Selector eingebunden. Der Artikel-Benchmark
errechnet sich Nutzungsdaten zB wie oft ein Artikel angesehen wurde, oder wie
oft er zu einem Reisekoffer hinzugefügt wurde, und auch daraus wie die Benutzer den Artikel bewerten. Mit Hilfe der Adaptierungsregeln wird nun festgelegt
wie all diese Informationen für die Artikelauswahl untereinander gewichtet sind.
Sie sind sozusagen die Stellgrößen mit denen man die Auswahl zusätzlich manuell beeinflussen kann, um zB bestimmte bezahlte Artikel weiter nach oben zu
reihen. Zuletzt kommt der Transformer zum Einsatz, er passt den ausgewählten
Content an das Endgerät des Benutzers an, so werden zB Bilder verkleinert oder
komplett entfernt oder große Tabellen umstrukturiert damit sie auf einen kleinen
Bildschirm passen.
Für das zuerst definiert Szenario bedeutet das, dass nun alle zur Verfügung stehenden Informationen in die Artikelauswahl mit einfließen. Somit kann mit Hilfe
der IP-Addresse der Ort (Haus im Ennstal) festgestellt werden, damit kann bei
einem externen Anbieter das Wetter abgefragt werden (-6◦ C und leichter Schneefall) und auf Grund der hohen Bandbreite und den Informationen aus dem Request Header (unterstützte Plugins) weiß die Anwendung, dass sie dem User auch
Multimedia-Content anzeigen kann. Die somit am wahrscheinlichsten erstgereihten Artikel werden die aktuellen Pistenverhältnisse, die aktuelle Wettervorhersage
und eine der Webcams vom Hauserkaibling beinhalten. Danach würden aufgrund
des Alters (24) und der Benutzerkategorie (Jung und Aktiv) aktuelle Abendprogramme, wie zB spezielle Events in den lokalen Diskotheken, gereiht nach dem
Artikel-Benchmark angezeigt.
Dieses Beispiel zeigt, wie groß die Unterschiede zwischen einer adaptierten und
einer nicht bzw. nur personalisierten Web-Anwendung sind. Ohne dass der Benutzer zusätzliche Informationen preisgegeben hat (es wurden nur sowieso vorhan7
Composite Capabilities/Preferences Profile
62
dene Umgebungsfaktoren in die Artikelauswahl miteinbezogen), bekommt er den
für interessantesten Inhalt. Dies war nur eines von einer Vielzahl an möglichen
Adaptierungsszenarien, sofern die Anwendung über ausreichende Informationen
über den Nutzungskontext verfügt, ist jedes nur erdenktliche Szenario möglich.
63
Kapitel 5
Implementierung
In diesem Kapitel werden Details zur Implementierung des Forschungsprototypen aufgezeigt. Zuerst werden die verwendeten Technologien und Bibliotheken
kurz vorgestellt (siehe Abschnitt 5.1). Es folgt eine Beschreibung der grundlegenden Elemente der Web-Anwendung in Abschnitt 5.2. Der Abschnitt 5.3 gibt
einen Überblick über die eingesetzen Adaptierungstechniken zur Anpassung der
Web-Anwendung an das Endgerät. Die entwickelten Adaptierungstechniken werden mit Hilfe von aspektorientierter Programmierung in das System eingebunden.
In Abschnitt 5.4 werden die dazu notwendigen Aspekte vorgestellt. Das implementierte Regelsystem, das die Inhalte in Abhängigkeit der Einschränkungen des
Endgeräts, des Orts und der Benutzerpräferenzen selektiert, wird in Abschnitt
5.4.2 vorgestellt. Zum Abschluss werden in Abschnitt 5.5 Vor- und Nachteile der
Implementierung untersucht, insbesondere in Hinblick auf die entwickelte Adaptierungslösung für mobile Endgeräte.
5.1 Verwendete Technologien
Die verwendeten Technologien und Bibliotheken werden im Folgenden kurz beschrieben. Abbildung 5.1 zeigt, in welchen Schichten unserer Architektur diese
Technologien eingesetzt werden.
Java.
1
Der Forschungsprototyp wurde mit Java (J2SE 5.0 JDK) entwickelt. Die
Realisierung der Web-Schnittstelle basiert auf den Java Enterprise Technologien Servlet, JavaServer Pages (JSP) und Tag Libraries.
MySQL. 2 Die persistente Speicherung der Artikel-, User-, Kategorie-, Regionsund Trackingdaten erfolgt mit Hilfe der relationalen Datenbank MySQL
5.0.
1
2
http://java.sun.com
http://www.mysql.org
5 Implementierung
64
Abbildung 5.1: Eingesetzte Technologien
Hibernate. 3 Für den Datenbankzugriff wird das objekt-relationale PersistenzFramework Hibernate verwendet. Dies ermöglicht eine leichtgewichtige und
transparente Persistierung der Entitäten, die als Plain Old Java Objects
(POJOs) implementiert sind. Somit kann mit einem objektorientierten
Domänenmodell gearbeitet werden. Abfragen erfolgen entweder durch ein
Query Object, das Hibernate Criteria Object, mit dem schrittweise durch
Hinzufügen von Kriterien eine Abfrage zusammengebaut werden kann, oder
mit der Hibernate Query Language (HQL), die eine objektorientierte Erweiterung von SQL darstellt.
Bibliotheken. Folgende Third-Party Libraries kamen bei der Entwicklung des
Forschungsprototyps zum Einsatz:
FCKeditor.4 Die FCKeditor wird zum Anlegen/Bearbeiten von Artikel im Backend verwendet. Es stellt einen WYSIWYG5 oder einfachen Text
Editor in Form eines HTML Input Forms zur Verfügung.
3
http://www.hibernate.org
http://www.fckeditor.net
5
What You See Is What You Get
4
5 Implementierung
65
Apache Commons Fileupload.6 Diese Bibliothek kann Requests mit
MultipartContent verarbeiten. Dies wird im Backend benötigt, um Bilder
zu den Artikeln auf den Server zu laden.
JH Labs Java Image Filters.7 Die Bilder zu den Artikeln werden automatisch mit einem Rahmen, einem Schlagschatten und einer leichten Drehung versehen. Der Schlagschatten wird mit Hilfe der Klasse ShadowFilter
aus dem JH Labs Library realisiert.
MaxMind GeoIP.8 Die MaxMind GeoIP Bibliothek wird dazu eingesetzt, um den Standort der Benutzer im Frontend auf Basis der IP Adresse
zu erkennen.
DELI: Delivery context library.9 Diese Bibliothek dient dazu, Composite Capabilities/Preferences Profiles (CC/PP) aus dem Request Header
auszulesen. Dadurch kann das verwendete Endgerät des Benutzers erkannt,
und in weiterer Folge ein dafür geeignetes Template geladen werden.
AspectJ 5. Für die Entwicklung des Tourismusinformationssystems als Forschungsprototyp dieser Arbeit haben wir uns für AspectJ (Version 5) entschieden.
AspectJ wurde ursprünglich bei Xerox PARC von Cristina Lopes und Gregor Kiczales, dem Vater der aspektorientierten Programmierung“, entwi”
ckelt. Seit Ende 2002 wird AspectJ als Eclipse Projekt10 weiterentwickelt.
AspectJ ist eine aspektorientierte Erweiterung für Java, ersetzt Java also nicht, sondern baut darauf auf. AspectJ Programme sind weitestgehend
normale Java Programme mit Klassen, um Core Concerns zu strukturieren
und Aspekten, um Crosscutting Concerns zu modularisieren. Core Concerns
stellen in der Regel die Kernfunktionalität eines Systems dar. Crosscuttting
Concerns, wie z.B. Logging oder in unserem Fall Customization, hingegen,
kommen an vielen Stellen im Programm verstreut vor. Sie ziehen sich durch
(crosscut) die gesamte Anwendung, sind im Code der Core Concerns verteilt und können mit den Konzepten der objektorientierten Programmierung (OOP), dh. innerhalb von Klassen, nicht gekapselt werden.
AOP ermöglicht höhere Modularität durch Herausziehen der Crosscutting Concerns in ein neues Konzept, d.h. dem Aspekt, und automatischen
6
http://jakarta.apache.org/commons/fileupload
http://www.jhlabs.com/ip/filters/index.html
8
http://www.maxmind.com/app/ip-location
9
http://www.hpl.hp.com/personal/marbut/deli
10
AspectJ Project, http://www.eclipse.org/aspectj/
7
5 Implementierung
66
Einfügen dieser Funktionalitäten beim Kompilieren an die richtigen Stellen
im System durch einen sogenannten Weaver.
AspectJ erweitert Java daher um einige neue Konzepte. Die wesentlichsten
Begriffe werden im Folgenden kurz erläutert.
Aspekt. Aspekte sind eine Erweiterung des Klassen-Konzepts und dienen
als Container“ für AOP Code, können aber auch OOP Code enthal”
ten.
Joinpoint. Joinpoints (Verbindungspunkte) sind bestimmte Ereignisse im
Programmablauf, an denen der ursprüngliche Code - mit Hilfe von
AOP - manipuliert werden kann. Solche Ereignisse können beispielsweise der Aufruf einer Methode oder der Zugriff auf eine Variable sein.
Pointcut. Pointcuts (Schnittpunkte) selektieren beliebige Joinpoints, an
denen der Programmablauf manipuliert werden soll.
Advice. Advices (Empfehlungen) beschreiben die Manipulation am ursprünglichen Code, die bei einem, vom Pointcut selektierten, Joinpoint
durchgeführt werden soll. Ein Advice kann entweder vor (before), nach
(after ) oder statt bzw. rund um (around ) einen Joinpoint ausgeführt
werden.
Intertype Deklaration. Intertype Deklarationen ermöglichen die Erweiterung bestehender Klassen um Attribute, abstrakte oder konkrete Methoden und Konstruktoren. Weiters können dadurch DefaultImplementierungen für Interfaces in Aspekten hinterlegt werden.
Weaving. Ein eigener Compiler, bzw. Pre-Processor, der Aspect Weaver,
vereinigt den AOP Code mit dem OOP Code. Dieser Prozess wird in
Abbildung 5.2 veranschaulicht und heißt Weaving. Das Weaving kann
zu verschiedenen Zeitpunkten passieren: Compile-Time Weaving verbindet den Advice-Code bereits beim Kompilieren mit dem Byte-Code
der (Java-)Klassen, Post-Compile-Time Weaving wird eingesetzt um
bestehende Class- oder Jar-Dateien mit Aspekten anzureichern. Beim
Load-Time Weaving geschieht die Integration erst durch den Classloader, damit können zB fremde Bibliotheken angepasst werden, ohne sie
direkt zu verändern. Diese Ansätze werden als Static AOP“ bezeich”
net. Run-Time Weaving bindet den AOP Code erst zur Laufzeit in
der Virtual Machine ein und heißt Dynamic AOP“. Derzeit gibt es
”
nur wenige Produkte, die umfangreiche Unterstützung für Run-Time
Weaving bieten.
5 Implementierung
67
Abbildung 5.2: Weaving
5 Implementierung
68
Eine detaillierte Einführung in die Grundlagen der aspektorientierten Programmierung und ihrer Vor- und Nachteile findet sich in [Bros06].
5.2 Allgemeine Beschreibung
Abbildung 5.3 zeigt die Startseite des entwickelten Forschungsprototypen im Winterdesign. Die grundlegenden Elemente werden im Anschluss kurz beschrieben.
Die Zahlen der folgenden Aufzählung entsprechen jenen aus Abbildung 5.3.
Abbildung 5.3: Screenshot des Forschungsprototypen im Winterdesign
1. Hier wird die Übersicht eines besonders interessanten oder ev. bezahlten
Artikel angezeigt. Der Text wird automatisch vom Transformer 5.3.3 auf
eine passende Länge gekürzt.
2. Unter Regionen und Aktivitäten befinden sich JavaScript Menüs (in der
Abbildung nicht sichtbar) in denen die Regionen, Orte usw. bzw. Akti-
5 Implementierung
69
vitäten, Sportarten usw., zu denen Angebote vorhanden sind angezeigt und
ermöglichen eine schnelle Auswahl des gewünschten Angebots.
3. Das linke Menü dient zur Navigation durch die vorhandenen Artikel und
zeigt immer die jeweilige Kategorie oder den jeweiligen Ort zu dem in der
Mitte (Pkt. 6) angezeigten Inhalt an.
4. Registrierte Benutzer können sich hier mit ihrem Benutzernamen und Passwort anmelden oder registrieren, sie bleiben automatisch auch über die Session durch ein Cookie angemeldet, bis sie sich wieder abmelden.
5. Zeigt ein Beispiel für eine mögliche Werbeeinschaltung. Diese sind in den
beiden äußeren Spalten an den meisten Stellen problemlos möglich.
6. In der mittleren Spalte wird immer eine Liste von Artikel angezeigt, außer
der Benutzer wählt einen speziellen Artikel aus dann wird nur dieser angezeigt. Ein Artikel der Artikelliste besteht aus dem Schlagtext (bzw. der
Einführung), einem Bild das automatisch an die erforderliche Größe angepasst, mit einem Rahmen, Schatten und einer leichten Drehung versehen
wird, und der besten Durchschnittsbewertung anderer Benutzer. Weiters
werden auch noch der Inhalt des Reisekoffers11 und die Benutzerregistrierung in dieser Spalte angezeigt.
7. Das Wetter für den aktuellen Tag und die Vorhersage für den nächsten
Tag werden immer passend zu dem ausgewählten Artikel angezeigt oder
bei einer Artikelliste passend zum ersten.
8. Hier besteht die Möglichkeit die Sprache zu wechseln.
9. Die Volltextsuche sucht in allen Artikel und zeigt die Treffer in der mittleren
Spalte an.
10. Sowohl in der linken als auch in der rechten Spalte (in der Abbildung nur in
der rechten Spalte) besteht die Möglichkeit unter den bereits beschriebenen
Elementen eine Liste aus sehr kurzen Artikelvorschauen (mit/ohne Bild)
anzuzeigen.
11
Der Benutzer hat die Möglichkeit Artikel die ihn interessieren in einen Reisekoffer, ähnlich dem
Warenkorb bei einem Webshop, zu geben um sie später leichter wiederzufinden, auszudrucken
oder an Freunde zu versenden.
5 Implementierung
70
5.3 Adaptierung hinsichtlich des Endgeräts
Die Adaptierung hinsichtlich des technischen Kontext, also im wesentlichen die
Adaptierung auf das jeweilige Endgerät, wird aus einer Kombination der in Kapitel 3 vorgestellten Technologien realisiert. Die Adaptierung der Weboberfläche
an die möglichen Endgeräte findet im Wesentlichen automatisch in drei Schritten
statt. Zuerst werden alle, das Gerät betreffenden, Informationen gesammelt und
ausgewertet. Danach wird das Grundlayout an das Gerät angepasst bzw. ein passendes Layout aus den vorhandenen ausgewählt und die Inhalte geladen. Zuletzt
werden die anzuzeigenden Artikel in ihrem Format an das gewählte Layout angepasst. Im Folgenden werden die verschiedenen Schritte der endgerätespezifischen
Adaptierung beschrieben.
5.3.1 Erkennung der Kontextfaktoren
Der wahrscheinlich wichtigste Teil bei der Adaptierung an verschiedene Endgeräte
ist die Erkennung der Eigenschaften und Fähigkeiten des verwendeten Geräts.
Beim Start der Session werden alle bekannten und relevanten Kontextfaktoren
ausgewertet. Implementiert wird die Erkennung durch den Kontextaspekt 5.4.1,
er ruft die jeweiligen Mehtoden auf. Dabei werden sowohl die Header Informationen als auch eventuelle CC/PP bzw. UAProf Profile erkannt und ausgewertet.
Listing 5.1 zeigt am Beispiel des Accept-Language Header-Felds wie diese Auswertung geschieht. Dabei werden zuerst die nach Präferenzen geordneten Sprachen
aus dem Header extrahiert und mit den in der Datenbank verfügbaren Sprachen
abgeglichen. Dadurch erfolg automatisch die Adaptierung der Anwendung auf die
vom Benutzer bevorzugte Sprache.
Listing 5.1: Mehtode zum Erkennen der vom Benutzer bevorzugten Sprache
1
private long d o D e t e c t L a n g u a g e F r o m H e a d e r ( H t t p S e r v l e t R e q u e s t request ) {
2
3
4
5
6
// try to detect language from request header
String l = request . getHeader ( " Accept - Language " ) ;
// e . g . de - at , de ; q =0.8 , en ; q =0.7 , en - us ; q =0.5 , it - it ; q =0.3 , it ; q =0.2
l = l . replaceAll ( " [ q ][=]\\ d [.]\\ d [ ,]? " , " " ) ;
7
8
String [] acceptlang = l . split ( " ; " ) ;
9
10
11
12
13
tip . entity . Language langObj = null ;
int i = 0;
LanguageAction langAct = new L ang ua ge Ac tio n () ;
String code = " " ;
14
15
16
17
while ( langObj == null && i < acceptlang . length ) {
code = acceptlang [ i ];
if ( code . indexOf ( " -" ) > 0)
5 Implementierung
71
code = code . substring (0 , acceptlang [ i ]. indexOf ( " -" ) ) ;
if ( code . indexOf ( " ," ) > 0)
code = code . substring (0 , acceptlang [ i ]. indexOf ( " ," ) ) ;
18
19
20
21
i ++;
langObj = langAct . getLanguage ( code ) ;
22
23
}
// no suitable language available
if ( langObj == null ) {
code = " DE " ;
langObj = langAct . getLanguage ( code ) ;
}
24
25
26
27
28
29
30
return langObj . getId () ;
31
}
32
Für die Erkennung der eigentlichen Geräteeigenschaften wird wie schon
erwähnt das UAProf Profil des Endgeräts ausgewertet. Für das parsen des Profils
wird die Open Source Bibliothek DELI (Delivery Context Library For CC/PP
and UAProf) 12 verwendet. DELI extrahiert automatisch die URL zum jeweiligen
UAProf Profil aus dem Request und parst die Datei in ein Profil Objekt. Somit ist
es nun einfach möglich auf die jeweiligen Attribute und Werte zuzugreifen (siehe
Listing 5.2). Der Vorteil von DELI liegt aber auch darin, dass auch Geräte oder
Browser, die kein UAProf Profil haben, unterstützt werden. Dazu kann man selbst
Profile anlegen (zB für den Microsoft Internet Explorer). Anhand des User-Agent
Felds im Header wird dann erkannt welches am Server gespeicherte Profil geladen
werden soll. Somit kann man nach dem selben Schema, wie die Eigenschaften von
mobilen Endgeräten erkannt werden, auch die verschiedenen Desktop Browser
erkennen“, und bei der Adaptierung darauf Rücksicht nehmen. In dem entwi”
ckelten Forschungsprototypen werden dann alle Kontextinformationen in einem
ContextBean“, welches für die Geräteeigenschaften ein DeviceBean“ enthält
”
”
(siehe auch Listing 5.2), gespeichert und stehen, nachdem sie bei der Instanzierung der Session eingelesen wurden, allen Anwendungsmodulen zur Verfügung.
Listing 5.2: Ausschnitt aus der Methode zum Erkennen der Geräteeigenschaften
mit Hilfe von DELI
private DeviceBean /* doDetect Dev ic e */ do Pa rs ePr of il e ( H t t p S e r v l e t R e q u e s t request )
{
Profile profile = new Profile ( request ) ;
1
2
3
DeviceBean deo = new DeviceBean () ;
4
5
try {
System . out . println ( profile . getAttribute ( " ScreenSize " ) ) ;
String screen = ( String ) ( profile . getAttribute ( " ScreenSize " ) ) . getValue () .
elementAt (0) ;
6
7
8
9
12
http://delicon.sourceforge.net
5 Implementierung
72
String [] s = screen . split ( " x " ) ;
int w = Integer . parseInt ( s [0]) ;
int h = Integer . parseInt ( s [1]) ;
deo . setScreenHeight ( h ) ;
deo . setScreenWidth ( w ) ;
} catch ( Exception e ) {
deo . setScreenHeight (768) ;
deo . setScreenWidth (1024) ;
e . printStackTrace () ;
}
10
11
12
13
14
15
16
17
18
19
20
//.....
21
22
return deo ;
23
24
}
5.3.2 Aggregation und Selektion von Inhalten und Layout
Nachdem die Eigenschaften des Geräts bekannt sind wird ein dazu passendes Layout ausgewählt. Das Layout gibt die grobe Seitenstruktur vor und besteht aus
JSP Seiten, die wiederum Tags enthalten, durch die dann die eigentlichen Inhalte
erstellt werden. Für den entwickelten Forschungsprototypen wurden derzeit zwei
Templates bereitgestellt. Eines für alle herkömmlichen Browser und Bildschirme
mit einer Auflösung von mindestens 800px in der Breite, und eines für mobile
Endgeräte oder Bildschirmauflösungen unter 800px Breite. Theoretisch wäre es
möglich beliebig viele Templates zur Verfügung zu stellen, der praktische Nutzen sei jedoch dahingestellt. Die Kombination aus Templates und Tags macht es
möglich das komplette Layout zu ändern, ohne in die Programmlogik der Anwendung eingreifen zu müssen, denn das Template gibt nur die Struktur und
das Design vor. An den Stellen, an denen zB das Menü erscheinen soll, wird der
dementsprechende Tag eingebunden, welcher wiederum ausschließlich designunabhängiges HTML erzeugt. Die Entscheidung für das entsprechende Template
wird im Controller aufgrund der Informationen über das Endgerät und darauf
angewendeten Regeln (zB Bildschirmbreite < 800px: Template für PDAs) getroffen (siehe dazu auch Abschnitt 5.4.1 und Listing 5.6).
Nachdem die Seitenstruktur festgelegt, ist werden die Inhalte mit Hilfe des Adaptierungsaspekts geladen (siehe 5.4.2). Diese bestehen bei dem implementierten
Prototyp aus Artikeln, welche im Backend angelegt wurden. Das Backend wurde
grundsätzlich für Flexible Authoring (siehe 3.2) implementiert. Dazu besteht ein
Artikel mindestens aus einem Titel und optional aus einem Schlagtext und einem Bild. Ist diese Grundstruktur angelegt, kann man den Artikel mit mehreren
vorgefertigten Grundstrukturen (ContentParts) aufbauen. Diese können beliebig
miteinander kombiniert werden. Abbildung D zeigt, wie ein Artikel mit mehre-
5 Implementierung
73
ren ContentParts im Backend aussieht. Die ContentParts sind ein wichtiger Teil
der endgeräteabhängigen Adaptierung, denn aus der Definition des ContentParts
weiß man, wie der Inhalt adaptiert werden soll. So kann es zB ContentParts
für normalen Text, Text mit HTML, Text mit Bild, Tabellen, Linklisten, BildGalerien oder für Videos mit verschiedenen Qualitätsstufen geben. Beim Laden
des Artikels können nun schon in Abhängigkeit der Geräteeigenschaften gewisse ContentParts wie zB Bild-Galerien weggelassen werden oder gleich die dem
Endgerät entsprechende Version (zB bei Videos) selektiert werden.
5.3.3 Transformation
Die Transformation ist der letzte Schritt in der Adaptierung für verschiedene
Endgeräte. Die Transformation wird mit Hilfe des Adaptierungsaspekts eingebunden, dabei werden die aus der Datenbank geladenen Inhalte für das jeweilige
Endgerät aufbereitet. Dies ist notwendig, da das Backend, aus Gründen der besseren Benutzbarkeit, nur die Möglichkeit bietet Inhalte in einer Formatierung (für
herkömmliche Browser) zu speichern. Dabei steht im Backend ein WYSIWYGHTML-Editor zur Verfügung, mit dem der Benutzer die angelegten Artikel komfortabel und ohne HTML-Kenntnisse editieren kann. Die Formatierung, die der
Autor des Artikels vornimmt, wie zum Beispiel große Tabellen oder Bilder, können
aber nicht immer auf allen Endgeräten gleich angezeigt werden. Daher ist es notwendig diese in Abhängigkeit der Geräteeigenschaften zu transformieren.
Nachdem die Inhalte aus der Datenbank geladen wurden, wird nun überprüft,
ob sie Elemente enthalten, die für die Darstellung auf dem verwendeten Endgerät
problematisch sind. Wird ein solches Element gefunden, zB ein Bild, wird es
vom Transformator durch ein kleineres in der passenden Auflösung ersetzt. Dabei
gilt es zu beachten, dass alle Bilder mit einem weißen Rahmen, sowie einem
Schatten, einer leichten Drehung und optional mit einem Text im Rahmen unter
dem Bild versehen sein können. All diese Optionen sind im Backend beim Anlegen
eines Bildes konfigurierbar und werden vollautomatisch erstellt. Beim Verkleiner
müssen diese logisch“ mit verkleinert werden. Das bedeutet, der Rahmen muss
”
schmäler werden und ab einer bestimmten Größe die Schrift entfernt werden, da
sie nicht mehr lesbar wäre. Videos werden bei dieser Transformation ignoriert,
da diese ja schon bei der Selektion der Inhalte in der richtigen Größe geladen
wurden, bzw. sowieso nicht geladen wurden.
Der Transformator besitzt auch die Fähigkeit Texte logisch zu kürzen. Dies
kommt vor allem bei der Artikelübersicht zum Tragen, wo nur die Schlagtexte
zu den ersten 3-5 Artikeln angezeigt werden. Der Schlagtext, der die Einleitung
des Artikels darstellt, besteht zwar in der Regel nur aus 100 bis 200 Wörtern,
5 Implementierung
74
was auf einem herkömmlichen Bildschirm kein Problem darstellt. Für ein Gerät
mit einer Bildschirmhöhe von zum Beispiel nur 320 px ist dies, vor allem bei einer Übersicht, jedoch viel zu viel. Der Transformator kürzt den Schlagtext daher
je nach Möglichkeit auf 20-50 Wörter ab. Alternativ dazu besteht die Möglichkeit, dass der Autor durch einen Kommentar () bestimmt, wo der
Schlagtext in der Übersicht abgebrochen wird. Abbildung 5.4 zeigt das Ergebnis
der endgerätespezifischen Adaption auf einem PDA.
Abbildung 5.4: Screenshot der für einen PDA adaptierten Anwendung im Sommerdesign
5 Implementierung
75
5.4 Implementierung der Adaptierung mit Hilfe von
Aspekten
Bei der Entwicklung des Tourismusinformationssystems wurde großen Wert darauf gelegt die Customization der Web-Anwendung als Crosscutting Concern im
Sinne der aspektorientierten Programmierung zu behandeln. Um Separation of
Concerns zu erreichen, wird der Code, der zur Customization beiträgt und in
nahezu allen Komponenten der Web-Anwendung verteilt ist, in Aspekte ausgelagert. Die objektorientierten Komponenten der Web-Anwendung beinhalten nur
den Code, der zur grundlegenden Funktionalität nötig ist und in der Bestim”
mung“ der Komponente liegt, dh. im Controller Servlet werden Parameter aus
dem Request validiert und auf die entsprechende View weitergeleitet, in der JSP
Seite werden ein CSS Stylesheet und Tag Libraries eingebunden und in den Tag
Libraries werden die einzelnen Teile der HTML Seite erzeugt. Wenn die Customization in diesen Komponenten vermischt wäre, müsste das Controller Servlet
Informationen zum Kontext extrahieren, die Tag Libraries müssten Fallunterscheidungen zu den verschiedenen Darstellungen auf den unterschiedlichen Endgeräten beinhalten, die Adaptierung des Inhalts wäre starr in den Klassen der
Geschäftslogik verankert, usw. Änderungen und Erweiterungen wären dann nur
sehr schwer durchzuführen.
Unser Ansatz basiert auf den drei Aspekten Kontextaspekt, Transformationsaspekt und Adaptierungsaspekt um diese Bereiche zu kapseln. Abbildung 5.4 zeigt
das Zusammenspiel der Aspekte mit den objektorientierten Komponenten anhand
eines an das der UML-Notation angelehntes Sequenzdiagramms. Die Pfeile, die
von den Aspekten ausgehen, zeigen, dass ein Advice an dieser Stelle ausgeführt
wird. Interessante Teile daraus werden im Folgenden beschrieben.
5.4.1 Kontextaspekt
Der Kontextaspekt hat die Aufgabe, relevante Kontextfaktoren zu erfassen. Diese
Daten werden aus dem Request Header und der IP-Adresse des Benutzers extrahiert und umfassen derzeit das verwendete Endgerät und Browser, die verfügbare
Bandbreite, die bevorzugte Sprache und den aktuellen Standort des Benutzers.
Der Kontext wird beim Start der Session erfasst und in einem Objekt, dem ContextBean, gespeichert.
Der Joinpoint befindet sich im Controller Servlet beim Aufruf des UserDetectors, der auch für die herkömmliche Web-Anwendung aufgerufen wird.
Der UserDetector prüft, ob ein Cookie für die automatische Anmeldung
5 Implementierung
76
Abbildung 5.5: Requestablauf
5 Implementierung
77
vorhanden ist. Der Advice benötigt Zugriff auf den Request und auf
das ContextBean. Dieses Ereignis wird durch den nachstehenden Pointcut
detectContext selektiert. Durch args(ctx, request) werden die der Methode
detectUser(ContextBean, HttpServletRequest) übergebenen Parameter für
den Advice sichtbar gemacht.
Listing 5.3: Pointcut detectContext
1
2
3
public pointcut detectContext ( ContextBean ctx , H t t p S e r v l e t R e q u e s t request ) :
call ( ContextBean UserDetector . detectUser ( ContextBean , H t t p S e r v l e t R e q u e s t ) )
&& ( args ( ctx , request ) ) ;
Bei diesem Pointcut wird ein Around-Advice durchgeführt. Dadurch kann der
Rückgabewert der Methode detectUser() nach der Ausführung der Methode,
aber noch vor der tatsächlichen Rückgabe des Objekts und des Kontrollflusses,
verändert werden. Es werden Daten zum Endgerät, der Bandbreite und dem
Standort extrahiert und zusätzlich im ContextBean gespeichert. Wenn der Benutzer automatisch angemeldet werden kann, wird die im Profil gespeicherte Sprache
für die Darstellung der Web-Anwendung verwendet. Wenn kein Cookie existiert,
wird zusätzlich die Sprache aus dem Request Header gelesen. Passt keine Sprache aus dem Request Header mit den im System verfügbaren überein, wird die
Web-Anwendung in Deutsch angezeigt.
Listing 5.4: Advice detectContext
1
2
ContextBean around ( ContextBean ctx , H t t p S e r v l e t R e q u e s t request ) :
detectContext ( ctx , request ) {
3
ctx = proceed ( ctx , request ) ;
4
5
if ( ctx . getUser () == null ) {
long langId = d o D e t e c t L a n g u a g e F r o m H e a d e r ( request ) ;
ctx . setLanguage ( langId ) ;
}
ctx . setDeviceBean ( doParse Pr of il e ( request ) ) ; // CC / PP Infos Parsen
ctx . setDevice ( doDetectDev ice ( ctx . getDb () ) ) ;
String ip = request . getRemoteAddr () ;
ctx . setIp ( ip ) ;
ctx . setBandwith ( doDe tec t B a n d w i t h ( ip ) ) ;
ctx . setLocation ( doDe tec t L o c a t i o n ( ip ) ) ;
6
7
8
9
10
11
12
13
14
15
16
return ctx ;
17
18
}
Abhängig vom erkannten Endgerät wird die Web-Anwendung in einem passenden Layout dargestellt. Für jedes Layout existiert eine eigene View, das ist eine
JSP Seite, die HTML Code für das Design und Tag Libraries für dynamische
Inhalte enthält. Das Controller Servlet muss den Request auf die richtige View
weiterleiten. Um aber im Controller nicht die Concerns zu vermischen, wird die
Entscheidung, welche View die richtige ist, im Kontextaspekt getroffen.
5 Implementierung
78
Der Pointcut doForward aktiviert dazu beim Aufruf der Methode
getRequestDispatcher(), sofern sie innerhalb der Methode doGet() in
der Klasse FrontendControllerServlet aufgerufen wird, einen Around-Advice.
Listing 5.5: Pointcut doForward
1
2
3
4
public pointcut doForward ( H t t p S e r v l e t R e q u e s t request ) :
call ( R eq ue s tD i sp at c he r H t t p S e r v l e t R e q u e s t . g e t R e q u e s t D i s p a t c h e r (*) )
&& withincode ( protected void F r o n t e n d C o n t r o l l e r S e r v l e t . doGet (..) )
&& ( target ( request ) ) ;
Der Advice prüft, welcher Kategorie (groß/klein) das Gerät zugeordnet ist, und
liefert ein passendes RequestDispatcher Objekt zurück.
Listing 5.6: Advice doForward
1
R eq u es tD i sp at c he r around ( H t t p S e r v l e t R e q u e s t request ) : doForward ( request ) {
2
R eq ue s tD i sp at c he r dispatcher ;
ContextBean ctx = ( ContextBean ) request . getSession () . getAttribute ( " ctxBean " ) ;
3
4
5
if ( ctx . getDevice () == GlobalValues . Device . MIDI ) {
dispatcher = request . g e t R e q u e s t D i s p a t c h e r ( " index_mobile . jsp " ) ;
}
else {
dispatcher = request . g e t R e q u e s t D i s p a t c h e r ( " index_front . jsp " ) ;
}
return dispatcher ;
6
7
8
9
10
11
12
13
}
5.4.2 Adaptierung des Inhalts
Für die Auswahl und Reihung der Artikel im Forschungsprototypen wurde im
Rahmen dieser Arbeit ein eigenes Customizationregelsystem entwickelt, welches
in Abbildung 5.6 dargestellt ist und in Folge kurz erläutert wird. Das Customizationregelsystem nimmt bei der Auswahl der Artikel einerseits auf den technischen
Kontext des Endgeräts als auch auf den natürlichen und sozialen Kontext Rücksicht.
Selektion der Inhalte
Bei der Entwicklung der ubiquitären Web-Anwendung war es das Ziel, möglichst
viele Kontextfaktoren mit einzubeziehen und darüber hinaus das System so zu
gestalten, dass es leicht erweiterbar ist und dass eine Konfiguration des Einflusses
der Kontextfaktoren auf die Adaptierung von Außen“ möglich ist, also ohne
”
Eingriff in den Programmcode.
Mit diesem System wird die Artikelauswahl für die gesamte Web-Anwendung
getroffen und bietet damit jedem Benutzer jederzeit ein speziell abgestimmtes
5 Implementierung
79
Angebot, wobei natürlich ein Navigieren durch alle Artikel über die Kategorienoder Ortsnavigation trotzdem weiterhin möglich ist.
Dabei wird prinzipiell zwischen zwei unterschiedlichen Kontextfaktorengruppen hinsichtlich ihres Einflusses auf die Adaptierung unterschieden, nämlich den
Knock-Out Faktoren und den Reihungsfaktoren.
Abbildung 5.6: Schema Adaptierungsvorgang der Artikel basierend auf sozialen,
natürlichen und logischen Kontext
Knock-Out Faktoren Diese Kontextfaktoren entscheiden, welche Artikel überhaupt für eine Anzeige in Frage kommen. Es wird über diese Faktoren also eine Selektion von, auf den Kontext des Benutzers, passende Artikeln
durchgeführt. Zu dieser Faktorgruppe zählen im Forschungsprototypen der
Ort, die Saison, die Sprache und der Benutzertyp. Am Beispiel der Saison wird schon deutlich, warum dies ein Knock-Out Faktor ist: Im Winter
wird ein Benutzer mit großer Wahrscheinlichkeit nicht an Sommerangeboten interessiert sein, darum soll er diese überflüssige Information auch gar
5 Implementierung
80
nicht angezeigt bekommen. Eine ausführlichere Erklärung in dieser Gruppe
der Kontextfaktoren bedarf der Benutzertyp. Dieser gibt eine grobe Interessensausrichtung und Einstufung des Benutzers an. Mögliche Benutzertypen
sind hierbei Jung&Aktiv“, Familien mit Kindern“, Romantik&Wellness“
”
”
”
oder Ähnliche. Diesen Typen wiederum sind passende Kategorien von Artikeln zugeordnet, wie zum Beispiel Jung&Aktiv die Kategorien Sport, Nightlife und Szene, Action und Fun umfasst. Die Erfassung und Einstufung eines
Benutzers zu einem Benutzertypen erfolgt halbautomatisch, kann also über
den Benutzer selbst oder über das System automatisch erfasst werden.
Abhängig von der Einstellung der Gewichtung dieser Faktoren werden diese jedoch wiederum automatisch schrittweise zurückgenommen, wenn eine
Berücksichtigung aller Faktoren keine oder nur eine unzureichende Treffermenge an Artikeln ergibt.
Reihungsfaktoren Das durch die Knock-Out Faktoren vorgewählte Artikel-Set
wird über diese Faktoren, wie der Name schon sagt, gereiht. So werden
zum Beispiel bei schönem Wetter Outdoor Events nach vor, oder Artikel,
welche zur Zeit nicht aktuell sind, weil diese an Events mit Öffnungszeiten
gebunden sind, nach hinten gereiht. Ein besonderer Reihungsfaktor ist der
Artikelbenchmark.
Artikelbenchmark Hierbei werden Trackingdaten zu den einzelnen Artikeln über
ein Benchmarksystem, welches die erfassten Daten normalisiert und gewichtet, bewertet. Mit in diese Bewertung fließt auch ein Neuigkeitsbonus“ für
”
neu erstellte Artikel ein, damit diese prominent platziert und nicht unter Umständen vom Regelsystem übergangen werden. Der daraus erhaltene
Benchmarkwert pro Artikel dient unter Berücksichtigung der anderen Reihungsfaktoren, je nach Konfiguration des Regelsystems, für die Reihung des
vorgewählten Artikel-Sets.
Technische Umsetzung als Regelsystem
Das oben beschriebene System zur Adaptierung der Artikel besteht im Prinzip aus
drei Komponenten. Einerseits aus einer erweiterbaren Gruppe an Regelklassen,
einer Konfigurationsdatei für die Definition der Reihenfolge und Gewichtung der
anzuwendenden Regeln und einem Adaptierungsaspekt.
Regelklasse Je eine Regelklasse definiert für einen Kontextfaktor die, für
die Adaptierung benötigten, HQL13 FROM, WHERE und ORDER BY 13
Hibernate Query Language
5 Implementierung
81
Fragmente. Diese Regelklassen werden vom Adaptierungsaspekt über Reflection14 aufgerufen, was zur Folge hat, dass neue Regeln ganz einfach,
auch zur Runtime, hinzugefügt werden können. Einzige Bedingung hierfür
ist, dass diese in der Konfigurationsdatei enthalten sein müssen, da ansonsten der Aspekt nichts von der neuen Regel weiß.
Konfigurationsdatei In dieser XML15 -Datei sind die Regelklassen der Kontextfaktoren mit optionalen Gewichtungen enthalten. Über diese Datei erfährt
der Adaptierungsaspekt, welche Regelklassen in welcher Reihenfolge und zu
welcher Gewichtung anzuwenden sind.
Adaptierungsaspekt Die in der Konfigurationsdatei aufgeführten Regelklassen
werden von dem Adaptierungsaspekt ausgeführt und die erhaltenen HQLFragmente zu einem HQL-Statement zusammengeführt. Dieses wird in die
entsprechende Stelle im Contentselector eingefügt und von diesem ausgeführt. Daraufhin wird vom Aspekt geprüft, ob das erhaltene Artikel-Set
ausreichend groß ist um den Hauptcontent und die Side-Artikel zu befüllen.
Ist dies nicht der Fall wird ein neues HQL-Statement erstellt, welches die
am schwächsten gewichtete Regel verwirft und ein neues Artikel-Set liefert.
Aufgrund dieses modularen Aufbaues kann das Regelsystem einfach erweitert
werden, in dem man eine neue Regelklasse entsprechend den Vorgaben einfügt
und diese auch im Konfigurationsfile berücksichtigt. Am Quellcode an sich sind
somit keine Änderungen nötig.
Ausführlich wird das Thema der Kontextbehandlung und speziell auch dieses
hier vorgestellte System in [Weis06] behandelt.
Einbindung mittels Adaptierungsaspekt
Der Adaptierungsaspekt ist wie zuvor erwähnt das Bindeglied zwischen den Regeln der Customization bezüglich Inhalt und der Klasse ContentSelector, die für
Artikelabfrage und -aufbereitung, Navigation, sowie Breadcrumb Menü zuständig
ist. In diesem Aspekt existieren zwei einfache Pointcuts, doMainAdaptation()
und doSideAdaptation() mit jeweiligem Before-Advice, die die entsprechenden
Datenbank-Abfragen für die große Artikelliste in der mittleren Spalte und die
kleinen seitlichen Artikellisten zusammen bauen.
Der Pointcut selektiert die Ausführung der Methode getMainContent() in der
Klasse ContentSelector. Zusätzlich zu den Parametern der Methode wird eine
Referenz auf das ContentSelector Objekt dem Advice übergeben.
14
15
http://java.sun.com/docs/books/tutorial/reflect/index.html
Extensible Markup Language
5 Implementierung
82
Listing 5.7: Pointcut doMainAdaptation
1
2
3
4
5
6
public pointcut do Mai nAda pta t i o n ( C on t e n t S e le c t o r cs ,
ContentBean cb , ContextBean ctx ) :
execution ( private * tip . main . action . C o nt e n t S e l ec t o r
. getMainContent ( ContentBean , ContextBean ) )
&& ( this ( cs ) )
&& ( args ( cb , ctx ) ) ;
Der Before-Advice lädt mittels Dynamic Class Loading die Regelklassen, die
in der Konfigurationsdatei angegeben sind. Die einzelnen Regelklassen sind
von der abstrakten Klasse AbstractRule abgeleitet und implementieren somit alle die Methoden getHqlFrom(), getHqlWhere() und getHqlOrder(). Eine konkrete Instanz von AbstractRule ist zB LanguageRule, die als WHERE Klausel eine Einschränkung der Artikelsprache auf die vom Benutzer
gewählte Sprache erzeugt. Der so zusammen gestellte Query String wird durch
cs.hqlMain = hqlFrom + hqlWhere + hqlOrder; an die Variable hqlMain im
ContentSelector Objekt weitergegeben.
Listing 5.8: Advice doMainAdaptation
1
2
before ( ContentSelector cs , ContentBean cb , ContextBean ctx ) :
do Main Adap tati on ( cs , cb , ctx ) {
3
hqlFrom = " SELECT DISTINCT articles FROM Article articles " ;
hqlWhere = " WHERE " ;
hqlOrder = " " ;
4
5
6
7
// load rule - config
Properties prop = loadPr ope rt ie s () ;
Enumeration enumProp = prop . propertyNames () ;
8
9
10
11
while ( enumProp . hasMoreEl e m e n t s () ) {
try {
Object ruleClass = Class . forName ( " tip . customization . adaptation . rule . " +
( String ) enumProp . nextElement () ) . newInstance () ;
12
13
14
15
// invoke methods for generating query string ...
16
17
}
catch ( Exception ex ) { }
18
19
}
20
21
// set query string in C o nt e n t S e l ec t o r
cs . hqlMain = hqlFrom + hqlWhere + hqlOrder ;
22
23
24
}
Die Customization der seitlichen Artikellisten erfolgt analog dazu.
5 Implementierung
83
5.4.3 Transformationsaspekt
Im Transformationsaspekt werden eventuell notwendige Änderungen zur Anpassung des Layouts für mobile Endgeräte vorgenommen. Der Transformationsaspekt
befreit“ die Klassen der Tag Libraries von Entscheidungen zur Endgeräteanpas”
sung. Wie bereits erwähnt sollen beispielsweise in der Artikelliste auf kleinen
Endgeräten abhängig von der Bildschirmhöhe nur drei bis fünf Artikel angezeigt
werden, diese sollen wiederum in der Vorschau auf drei bis fünf Sätze gekürzt
werden. Listing 5.10 zeigt zB wie die Anzahl der Artikel in der Artikelübersicht
auf drei verringert werden kann.
Listing 5.9: Ponitcut doArticleCountTransformation
1
2
public pointcut d o A r t i c l e C o u n t T r a n s f o r m a t i o n ( Art ic le Lis tT ag alt ) :
set ( int ArticleListTag . articleCount ) && ( this ( alt ) ) ;
Listing 5.10: Advice doArticleCountTransformation
1
after ( ArticleListTag alt ) : d o A r t i c l e C o u n t T r a n s f o r m a t i o n ( alt ) {
2
Device d = alt . ub . getDevice () ;
int screenH = alt . ub . getDb () . g e t S cr e e n H e i gh t () ;
3
4
5
if ( alt . articleCount > 3 && d == GlobalValues . Device . MIDI && screenH < 320)
alt . articleCount = 3;
6
7
8
9
}
Listing 5.12 zeigt beispielsweise wie mit Hilfe des Advice
doTextTransformation der Schlagtext eines Artikels in der Artikelliste auf
drei Sätze gekürzt werden kann.
Listing 5.11: Pointcut doTextTransformation
1
2
3
4
5
public pointcut d o T e x t T r a n s f o r m a t i o n ( Article a , Ar ti cl eL ist Ta g alt ) :
call ( String Article . getText () )
&& ( withincode ( int ArticleL is tT ag . doStartTag () ) )
&& ( target ( a ) )
&& ( this ( alt ) ) ;
Listing 5.12: Advice doTextTransformation
1
2
String around ( Article a , A rti cl eL ist Ta g alt ) :
d o T e x t T r a n s f o r m a t i o n (a , alt ) {
3
4
5
6
String aText ;
Device d = alt . ub . getDevice () ;
int screenH = alt . ub . getDb () . g e t S cr e e n H e i gh t () ;
7
8
9
10
11
if ( d == GlobalValues . Device . MIDI && screenH < 320) {
String text = Util . stripHtml ( a . getText () ) ;
Se nten ceSp lit ter ss = new S e n t e n c e S p l i t t e r () ;
aText = ss . split ( ss . mark ( text , " $ " ) ,3 , " \\$ " ) ;
5 Implementierung
84
}
else {
aText = a . getText () ;
}
12
13
14
15
16
return aText ;
17
18
}
In der Artikelliste sollen auf kleinen Endgeräten keine Contentparts angezeigt
werden, die nur allgemeine Informationen beinhalten, wie zB die zusammengefasste Empfehlung aus den abgegebenen Ratings, für welchen Urlaubstyp ein Artikel geeignet ist. Der Pointcut doListSystemCPTransformation adressiert den
Aufruf der Methode CPTag.performContentparts(), die das Rendering aller
Contentparts für die Artikelliste veranlasst.
Listing 5.13: Pointcut doListSystemCPTransformation
1
2
3
public pointcut d o L i s t S y s t e m C P T r a n s f o r m a t i o n ( Art ic le Lis tT ag alt ) :
call ( String CPTag . p e r f o r m C o n t e n t p a r t s ( ArticleFrame , ..) )
&& ( this ( alt ) ) ;
Da auf mobilen Devices keiner der Contentparts in der Liste angezeigt werden
soll, bricht der Around-Advice entweder mit einem Leerstring das Rendern der
Contentparts ab, oder wenn es sich nicht um ein kleines Endgerät handelt, wird
durch den Aufruf von proceed() der Vorgang ordnungsgemäß durchgeführt.
Listing 5.14: Advice doListSystemCPTransformation
1
2
String around ( ArticleListT ag alt ) :
d o L i s t S y s t e m C P T r a n s f o r m a t i o n ( alt ) {
3
Device d = alt . ctx . getDevice () ;
4
5
if ( d == GlobalValues . Device . MIDI )
return " " ;
else
return proceed ( alt ) ;
6
7
8
9
10
}
In der Detailansicht eines Artikels werden alle abgegebenen Ratings inkl. Kommentar aufgelistet. Für kleine Endgeräte soll stattdessen ein Durchschnittsrating
angezeigt werden. Der Pointcut doRating adressiert die Ausführung der Rating
Rendering Methode innerhalb des Kontrollflusses des ArticleTag.
Listing 5.15: Pointcut doRatingCPTransformation
1
2
3
4
public pointcut d o R a t i n g C P T r a n s f o r m a t i o n ( ArticleTag at , ContextBean ctx ) :
execution ( String CPRating . p e r f o r m F u l l O u t p u t ( ContextBean ) )
&& cflowbelow ( execution ( public int ArticleTag . doStartTag () ) && ( this ( at ) ) )
&& ( args ( ctx ) ) ;
Der Around-Advice bewirkt bei mobilen Endgeräten die Anzeige des durchschnittlichen Ratings statt der gesamten Liste.
5 Implementierung
85
Listing 5.16: Advice doRatingCPTransformation
1
2
3
String around ( ArticleTag at , ContextBean ctx ) :
d o R a t i n g C P T r a n s f o r m a t i o n ( at , ctx ) {
Device d = ctx . getDevice () ;
4
if ( d == GlobalValues . Device . MIDI ) {
5
6
Object [][] articles = at . cb . g e t M a in A r t i c l es () ;
Article a = ( Article ) articles [0][0];
7
8
9
RatingBean rb = new RatingBean () ;
rb . loadAvgRating ( a . get A r t i c l eF r a m e () . getId () ) ;
10
11
12
RatingAction ra = new RatingAction () ;
return ra . g e t A v g R a t i n g C a t e g o r i e s ( rb , ctx ) ;
13
14
}
else
return proceed ( at , ctx ) ;
15
16
17
18
}
5.5 Kritische Würdigung
Die Bereiche der Customzation werden durch den Kontextaspekt, Adaptierungsaspekt und Transformationsaspekt vom Rest abgekapselt. Die großen Vorteile
sind, dass der Code nicht vermischt ist, jede Komponente nur die Funktionalität
beinhaltet, die auch in ihr vermutet wird und Änderungen an zentraler Stelle durchzuführen sind. Die Adaptierung an das Endgerät ist durch den Aufbau
der Artikel aus verschiedenen Contentparts sehr flexibel. Das Hinzufügen neuer
Contetparttypen zum System, ist durch den modularen Aufbau relativ einfach
möglich. Für neue Contentparts muss nur eine Entität in der Datenbank und eine Hibernate-Mapping Klasse angelegt werden. Diese Mapping Klasse implementiert das Interface IContentpart mit den Methoden performListOutput() und
performFullOutput() für das Rendering in der Artikelliste bzw. in der Vollansicht. Diese beiden Methoden dienen als Joinpoint. Eine Adaptierung für verschiedene Endgeräte erfolgt analog zu der Transformation des Ratings (siehe Listing
5.16), wobei je nach Contentparttyp zusätzlich noch andere Transformationen
einfach und an zentraler Stelle hinzugefügt werden können.
Die Adaptierung des Inhalts ist ebenfalls auf größtmögliche Flexibilität ausgelegt. Durch Hinzufügen neuer Regeln, beziehungsweise durch Ändern der Reihenfolge der Regeln in der Konfigurationsdatei, wird die Anpassung beeinflusst. Werden die Regeln in Zukunft so komplex, dass eine sequentielle Abarbeitung nicht
mehr effizient ist und ein RETE-basierter Baumansatz nötig ist, kann lediglich
durch Änderungen in den Advices doMainAdaptation und doSideAdaptation
5 Implementierung
86
eine professionelle Rule Engine, wie zB JBoss Rules16 , statt unserer Eigenentwicklung eingesetzt werden.
Schwieriger gestaltet sich das Hinzufügen neuer Kontextfaktoren. Hier genügt
es nicht, nur den Advice des Aspekts zu ändern, da die neuen Kontextfaktoren
im ContextBean gespeichert werden und in weiterer Folge für die Adaptierung
genutzt werden. Somit ist eine Erweiterung des ContextBeans und die Erstellung
neuer Regeln notwendig. Die Erweiterung des ContextBeans um Attribute für
die neuen Kontextfaktoren könnte entweder durch einen Aspekt instrumentiert
werden oder direkt in der Klasse erfolgen.
Änderungen bei der Extraktion der bestehenden Kontextfaktoren sind aber
relativ einfach möglich. Hier sind nur Änderungen im Kontextaspekt nötig. So
kann beispielsweise die Lokalisierung des Benutzers, die derzeit aufgrund der IPAdresse erfolgt, auch für die Verwendung von GSM oder GPS Informationen
ausgebaut werden.
16
http://labs.jboss.com/portal/jbossrules
87
Kapitel 6
Conclusio
Für die Adaptierung einer Web-Anwendung an das Endgerät gibt es eine Vielzahl
an Techniken und Methoden. Die zweckmäßige Kombination dieser Techniken ist
stark von der Art der Web-Anwendung und den angebotenen Services abhängig.
Bei der Entwicklung einer ubiquitären Web-Anwendung ist es notwendig schon
von Beginn an die verschiedenen Aspekte der Endgerätunabängigkeit zu berücksichtigen, denn es wird nicht nur die Präsentation an das Endgerät adaptiert,
sondern auch die Inhalte speziell an den Kontext des Nutzers und somit auch den
Kontext des Endgeräts angepasst.
Unser Fokus bei der Entwicklung des ubiquitären Tourismusinformationssystems lag bei der Customization. Dazu wurde ein eigenes Content Management
System entwickelt, das den speziellen Anforderungen der kontextabhängigen Customization entspricht. Schon bei der Konzeption das Datenbankmodells wurde
darauf Rücksicht genommen, dass bestimmte Teile der Web-Anwendung nur in
Abhängigkeit des Nutzungskontexts erstellt werden. Im Zuge der Implementierung wurde die Customization als eigene Dimension der Web-Anwendung betrachtet und auch im Programmcode durch den Einsatz der aspektorientierten
Programmiersprache AspectJ separiert. Es wurden verschiedene Techniken zur
Erkennung des Nutzungskontexts implementiert und ein eigenes Customizationregelsystem entwickelt mit dessen Hilfe die Inhalte in Abhängigkeit des Kontexts
selektiert werden. Für die Adaptierung der Darstellung an das Endgerät wurden zusätzlich eine Kombination aus Templates und Transformationstechniken
verwendet.
6.1 Erfahrungsbericht
Bei der Entwicklung der Endgerätunabängigkeit stellten sich folgende Punkte als
besonders wichtig dar:
6 Conclusio
88
• Einfaches modulares Konzept zur Erstellung und Speicherung der Inhalte
• Zuverlässige Erkennung der Eigenschaften des Endgeräts
• Selektion und Aggregation der Inhalte aufgrund des Nutzungskontexts
• Templates für die Präsentation und Fein-Transformation der Inhalte in
Abhängigkeit des Endgeräts
Die Aufteilung der Artikel in verschiedene Contentparts, d.h. Artikelteile, hat
sich als sehr einfaches und modulares Konzept herausgestellt, mit dessen Hilfe
leicht der Flexible Authoring Ansatz implementiert werden konnte. Für die Erkennung der Eigenschaften konzentrierten wir uns speziell auf das Auslesen der
UAProf und CC/PP Profile der Endgeräte, dabei hat sich das Open Source Library DELI1 als besonders nützlich erwiesen. Für die Auswahl der Inhalte wurde
ein eigenes Regelsystem, entwickelt das einfach durch Textdateien zu konfigurieren ist. Auf der Präsentationsebene wurden JSP-Templates für das Layout und
Design eingesetzt. Sie enthalten nur Tag-Libraries, die in Abhängikeit der Eigenschaften des Endgeräts den HTML-Code erzeugen und sind somit jederzeit
einfach erweiter- oder ersetzbar.
6.2 Ausblick
Mobile Endgeräte sind unumstreitbar weit verbreitet und nahezu jedes moderne Mobiltelefon verfügt schon über einen XHTML-fähigen Browser. Daraus ließe
sich schließen, dass die Endgerätunabhängigkeit bei der Entwicklung von WebAnwendungen einen immer größer werdenden Stellenwert einnehmen müsste.
Doch es gibt einige Argumente, warum dies nur bedingt der Fall sein könnte. Einerseits erfolgt die Weiterentwicklung der Endgeräte immer rasanter und
die Funktionen werden immer umfangreicher. Nicht nur die Software wie Browser werden immer besser, sondern auch die Geräte selbst haben immer schnellere Prozessoren und größere Displays. Andererseits ist die Entwicklung eines
durchgängigen Customization-Konzepts mit aufwändiger serverseitiger Adaptierung, wie von uns vorgestellt, nicht immer nötig. Bei den meisten herkömmlichen
Web-Anwendungen reicht es aus, nur die Präsentation auf das Endgerät zu adaptieren was zB mit CSS Stilen mit Media-Type bei weitem einfacher erreicht
werden kann. Bei ubiquitären Web-Anwendungen ist ein ganzheitlicher Ansatz
mit serverseitiger Adaptierung jedoch unumgänglich. Somit wird die Entwicklung
1
http://delicon.sourceforge.net/
6 Conclusio
89
neuer Ansätze für die Endgeräteunabhängigkeit auch stark davon abhängen, ob
sich ubiquitäre Web-Anwendungen in den nächsten Jahren durchsetzen.
90
Anhang A
Sourcecode Statistik
Dateien
Klassen
Methoden
Durchschnittliche Anzahl an Methoden pro Klasse
Maximale Anzahl an Methoden in einer Klasse
Minimale Anzahl an Methoden in einer Klasse
Codezeilen Total
Durchschnittliche Anzahl an Codezeilen pro Datei
Maximale Anzahl an Codezeilen pro Datei
Minimale Anzahl an Codezeilen pro Datei
132
128
1448
11
48
1
17624
135
883
7
Tabelle A.1: Statistik Java Dateien
Dateien
Zeilen Total
Durchschnittliche Anzahl an Zeilen pro Datein
Maximale Anzahl an Zeilen pro Datei
Minimale Anzahl an Zeilen pro Datei
16
1313
82
200
7
Tabelle A.2: Statistik JSP Dateien
Dateien
Zeilen Total
Durchschnittliche Anzahl an Zeilen pro Datein
Maximale Anzahl an Zeilen pro Datei
Minimale Anzahl an Zeilen pro Datei
Tabelle A.3: Statistik XML Dateien
54
2613
48
186
14
91
Anhang B
Ant Build Konfiguration
Listing B.1: Ant Build Konfiguration
1
<? xml version = " 1.0 " ? >
2
3
4
5
6
7
8
9
10
< project name = " AntBuild " default = " compile " basedir = " . " >
<! -- set global p r o p e r t i e s for this build -- >
< property name = " src " location = " src " / >
< property name = " ajsrc " location = " src / tip / customization " / >
< property name = " build " location = " build / classes " / >
< property name = " dist " location = " dist " / >
< property name = " webcontent " location = " WebContent / " / >
< property name = " tomcat . home " location = " path \ to \ apache - tomcat -5.5.17 " / >
11
12
13
14
<! -- TODO: update path -- >
< property name = " aspectj . home " value = " path \ to \ AspectJ " / >
< property name = " classpath " value = " path \ to \ TIP \ CODE \ WebContent \ WEB - INF \ lib " / >
15
16
17
18
19
20
< taskdef resource = " org / aspectj / tools / ant / taskdefs / a s p ec t j T a s k de f s . properties " >
< classpath >
< pathelement path = " ${ aspectj . home }/ lib / aspectjtools . jar " / >
</ classpath >
</ taskdef >
21
22
23
24
25
26
27
< target name = " init " >
<! -- Create the time stamp -- >
< tstamp / >
<! -- Create the build d i r e c t o r y s t r u c t u r e used by compile -- >
< mkdir dir = " ${ build } " / >
</ target >
28
29
30
31
32
33
34
35
36
37
38
39
40
< target name = " compile " depends = " clean , init " description = " compile with ajc " >
< iajc srcdir = " src " destdir = " ${ build } " source = " 1.5 " >
< classpath >
< pathelement path = " ${ aspectj . home }/ lib / aspectjrt . jar " / >
< fileset dir = " ${ classpath } " >
< include name = " *. jar " / >
</ fileset >
</ classpath >
< inpath >
< pathelement location = " ${ build } " / >
</ inpath >
</ iajc >
B Ant Build Konfiguration
41
42
43
44
45
46
< copy todir = " ${ build } " >
< fileset dir = " ${ src } " >
< exclude name = " **/*. java " / >
</ fileset >
</ copy >
</ target >
47
48
49
50
51
52
53
54
55
56
57
58
59
< target name = " war " depends = " compile " description = " generate the war file " >
< mkdir dir = " ${ dist } " / >
< war destfile = " ${ dist }/ tip . war " webxml = " ${ webcontent }/ WEB - INF / web . xml " >
< fileset dir = " ${ webcontent } " / >
< classes dir = " ${ build } " / >
</ war >
< copy todir = " ${ tomcat . home }/ webapps " >
< fileset dir = " ${ dist } " >
< include name = " tip . war " / >
</ fileset >
</ copy >
</ target >
60
61
62
63
64
65
66
< target name = " clean " description = " clean up " >
<! -- Delete the ${ build } and ${ dist } d i r e c t o r y trees -- >
< delete dir = " ${ build }/*. class " / >
< delete dir = " ${ dist } " / >
</ target >
</ project >
92
93
Kapitel und Autoren
Kapitel Petra Brosch Rudolf Mayer Arnold Weissensteiner
1
X
2.1
X
2.2.1
X
2.2.2
X
2.2.3
X
2.2.4
X
3
X
4.1
X
4.2
X
4.3
X
4.4
X
4.4.2
X
4.5
X
5.1
X
5.2
X
5.3
X
5.4
X
5.4.2
X
X
5.4.3
X
6
X
Tabelle B.1: Kapitel und Autoren
94
Anhang C
Screenshots Frontend
Abbildung C.1: Startseite
95
Abbildung C.2: Artikelansicht
Abbildung C.3: Artikelbewertung
Abbildung C.4: Reisekoffer ansehen
96
97
Anhang D
Screenshots Backend
Abbildung D.1: Artikelzentrale
98
Abbildung D.2: Artikelübersicht
Abbildung D.3: Artikel bearbeiten/anlegen
99
Abbildung D.4: Contentpart Text bearbeiten/anlegen
Abbildung D.5: Kategorien bearbeiten/anlegen
100
101
Anhang E
Relevante MIME-Typen
Dateityp
Audio 3GPP Dateien (.3gp)
Audio AMR Dateien (.amr)
Audio AMR (wideband) Dateien (.awb)
Audio MIDI Dateien (.mid oder .midi)
Audio MP3 Dateien (.mp3)
Audio MP4 Dateien (.mp4)
Audio WAV Dateien (.wav)
HTML Dateien (.html oder .htm)
Bild BMP Dateien (.bmp)
Bild GIF Dateien (.gif)
Bild JPEG Dateien (.jpg oder .jpeg)
Bild PNG Dateien (.png)
Bild TIFF Dateien (.tif oder .tiff)
Bild WBMP (Wireless BMP) Dateien (.wbmp)
Java application JAR Dateien (.jar)
Java application JAD Dateien (.jad)
Plain text Dateien (.txt)
Symbian application SIS Dateien (.sis)
Video 3GPP Dateien (.3gp)
Video MP4 Dateien (.mp4)
WML Dateien (compiled) (.wmlc)
WML Dateien (plain text) (.wml)
WMLScript Dateien (compiled) (.wmlsc)
WMLScript Dateien (plain text) (.wmls)
XHTML MP Dateien (.xhtml, .html or .htm)
MIME Medien Typ
audio/3gpp
audio/amr
audio/amr-wb
audio/midi
audio/mpeg
audio/mp4
audio/wav
audio/x-wav
text/html
image/bmp
image/x-bmp
image/gif
image/jpeg
image/png
image/tiff
image/vnd.wap.wbmp
application/java
application/java-archive
application/x-java-archive
text/vnd.sun.j2me.app-descriptor
text/plain
application/vnd.symbian.install
video/3gpp
video/mp4
application/vnd.wap.wmlc
text/vnd.wap.wml
application/vnd.wap.wmlscriptc
text/vnd.wap.wmlscript
application/vnd.wap.xhtml+xml
application/xhtml+xml
text/html
Tabelle E.1: Einige für die Erkennung der Geräteeigenschaften von Mobilen Endgeräten interessante MIME-Typen
102
Anhang F
UAProf Profil des Nokia 6230i
Listing F.1: UAProf Profil des Nokia 6230i
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
<? xml version = " 1.0 " ? >
<! -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- >
<! --- >
<! -- Copyright ( c ) 2003 Nokia . All rights reserved .
-- >
<! --- >
<! -- The contents of this document are provided " as is " .
-- >
<! -- No warranties of any kind , either express or implied , -- >
<! -- including , but not limited to , the implied warranties -- >
<! -- of merchantability and fitness for a particular
-- >
<! -- purpose , are made in relation to the accuracy ,
-- >
<! -- reliability or contents of this document . Nokia
-- >
<! -- reserves the right to revise this document or
-- >
<! -- withdraw it at any time without prior notice .
-- >
<! --- >
<! -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- >
<! -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- >
<! --- >
<! -- This file was generated using the UA Profile
-- >
<! -- generator provided by IOP Operations .
-- >
<! --- >
<! -- 2005.04.07 10 :12:05
-- >
<! --- >
<! -- Valid beginning from version 3.27
-- >
<! -- User Agent Header: Nokia6230i /2.0 (03.27) Profile /
-- >
<! -- MIDP -2.0 Configuration / CLDC -1.1
-- >
<! --- >
<! -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- >
xmlns:prf = " http: // www . o p e n m o b i l e a l l i a n c e . org / tech / profiles / UAPROF / ccppschema
-20021212# "
xmlns:mms = " http: // www . wapforum . org / profiles / MMS / ccppschema -20010111# " >
< rdf:Description rdf:ID = " Profile " >
< prf:component >
< rdf:Description rdf:ID = " H a r d w a r e P l a t f o r m " >
profiles / UAPROF / ccppschema -20021212# H a r d w a r e P l a t f o r m " / >
< prf:BluetoothProfile >
< rdf:Bag >
< rdf:li > Headset Profile </ rdf:li >
< rdf:li > Handsfree Profile </ rdf:li >
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
103
< rdf:li > SIM Access Profile </ rdf:li >
< rdf:li > Dial - up Networking Profile </ rdf:li >
< rdf:li > Object Push Profile </ rdf:li >
< rdf:li > File Transfer Profile </ rdf:li >
< rdf:li > Generic Access Profile </ rdf:li >
< rdf:li > Serial Port Profile </ rdf:li >
< rdf:li > General Object Exchange Profile </ rdf:li >
</ rdf:Bag >

< prf: Bit sPer Pixe l > 16 
< prf: Col orCa pabl e > Yes 
< prf: Ima geCa pabl e > Yes 
< prf: Inp utCh arSe t >
< rdf:Bag >
< rdf:li >ISO -8859 -1 </ rdf:li >
</ rdf:Bag >
</ pr f:I nput Char S e t >
< prf:Keyboard > PhoneKeyPad </ prf:Keyboard >
< prf:Model > 6230 i </ prf:Model >
3 

< rdf:Bag >
< rdf:li >ISO -8859 -1 </ rdf:li >
</ rdf:Bag >
</ pr f: O ut pu t Ch a r S e t >
1 x1 
< prf:ScreenSize > 208 x208 
 18 x5 
 Yes 
 Yes 
 Yes 
< prf:Vendor > Nokia </ prf:Vendor >
 Yes 
</ prf:component >
< prf:component >
< rdf:Description rdf:ID = " S o f t w a r e P l a t f o r m " >
profiles / UAPROF / ccppschema -20021212# S o f t w a r e P l a t f o r m " / >
 Yes 
< prf:AudioInputEncoder >
< rdf:Bag >
< rdf:li > AMR </ rdf:li >
< rdf:li > EFR </ rdf:li >
< rdf:li > FR </ rdf:li >
< rdf:li > HR </ rdf:li >
</ rdf:Bag >

< prf:CcppAccept >
< rdf:Bag >
< rdf:li > application / java </ rdf:li >
< rdf:li > application / java - archive </ rdf:li >
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
104
< rdf:li > application / sdp </ rdf:li >
< rdf:li > application / vnd . met . ticket </ rdf:li >
< rdf:li > application / vnd . met . receipt </ rdf:li >
< rdf:li > application / vnd . nok - s40theme </ rdf:li >
< rdf:li > application / vnd . nokia . ringing - tone </ rdf:li >
< rdf:li > application / vnd . nokia . radio - preset </ rdf:li >
< rdf:li > application / vnd . nokia . radio - presets </ rdf:li >
< rdf:li > application / vnd . oma . dd + xml </ rdf:li >
< rdf:li > application / vnd . oma . drm . content </ rdf:li >
< rdf:li > application / vnd . oma . drm . message </ rdf:li >
< rdf:li > application / vnd . oma . drm . rights + xml </ rdf:li >
< rdf:li > application / vnd . oma . drm . rights + wbxml </ rdf:li >
< rdf:li > application / vnd . syncml - xml </ rdf:li >
< rdf:li > application / vnd . syncml - wbxml </ rdf:li >
< rdf:li > application / vnd . wap . cert - response </ rdf:li >
< rdf:li > application / vnd . wap . connectivity - wbxml </ rdf:li >
< rdf:li > application / vnd . wap . hashed - certificate </ rdf:li >
< rdf:li > application / vnd . wap . sic </ rdf:li >
< rdf:li > application / vnd . wap . signed - certificate </ rdf:li >
< rdf:li > application / vnd . wap . slc </ rdf:li >
< rdf:li > application / vnd . wap . xhtml + xml </ rdf:li >
< rdf:li > application / vnd . wap . wmlscriptc </ rdf:li >
< rdf:li > application /x - java - archive </ rdf:li >
< rdf:li > application /x - wallet - appl . user - data - provision </ rdf:li >
< rdf:li > application /x - wap - prov . browser - bookmarks </ rdf:li >
< rdf:li > application / xhtml + xml </ rdf:li >
< rdf:li > application / m3g </ rdf:li >
< rdf:li > audio /3 gpp </ rdf:li >
< rdf:li > audio / aac </ rdf:li >
< rdf:li > audio / amr </ rdf:li >
< rdf:li > audio / amr - wb </ rdf:li >
< rdf:li > audio / mid </ rdf:li >
< rdf:li > audio / midi </ rdf:li >
< rdf:li > audio / mp3 </ rdf:li >
< rdf:li > audio / mpeg </ rdf:li >
< rdf:li > audio / sp - midi </ rdf:li >
< rdf:li > audio /x - mid </ rdf:li >
< rdf:li > audio /x - midi </ rdf:li >
< rdf:li > image / bmp </ rdf:li >
< rdf:li > image / gif </ rdf:li >
< rdf:li > image / jpeg </ rdf:li >
< rdf:li > image / jpg </ rdf:li >
< rdf:li > image / png </ rdf:li >
< rdf:li > image / vnd . nok - oplogo - color </ rdf:li >
< rdf:li > image / vnd . nok - wallpaper </ rdf:li >
< rdf:li > image / vnd . wap . wbmp </ rdf:li >
< rdf:li > multipart / mixed </ rdf:li >
< rdf:li > text / css </ rdf:li >
< rdf:li > text / html </ rdf:li >
< rdf:li > text / plain </ rdf:li >
< rdf:li > text / vnd . sun . j2me . app - descriptor </ rdf:li >
< rdf:li > text / vnd . wap . si </ rdf:li >
< rdf:li > text / vnd . wap . sl </ rdf:li >
< rdf:li > text / vnd . wap . wml </ rdf:li >
< rdf:li > text /x - co - desc </ rdf:li >
< rdf:li > text /x - vCalendar </ rdf:li >
< rdf:li > text /x - vCard </ rdf:li >
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
< rdf:li > video /3 gpp </ rdf:li >
< rdf:li > video / mp4 </ rdf:li >
</ rdf:Bag >
</ prf:CcppAccept >
< prf:CcppAccept - Charset >
< rdf:Bag >
< rdf:li >ISO -8859 -1 </ rdf:li >
</ rdf:Bag >
</ prf:CcppAccept - Charset >
< prf:CcppAccept - Encoding >
< rdf:Bag >
< rdf:li > base64 </ rdf:li >
</ rdf:Bag >
</ prf:CcppAccept - Encoding >
< prf:JavaEnabled > Yes 
< prf: Jav aPla tfor m >
< rdf:Bag >
< rdf:li > CLDC </ rdf:li >
< rdf:li > MIDP </ rdf:li >
< rdf:li > MIDP /1.0 - compatible </ rdf:li >
< rdf:li > Profile / MIDP -2.0 </ rdf:li >
< rdf:li > Configuration / CLDC -1.0 </ rdf:li >
< rdf:li > Configuration / CLDC -1.1 </ rdf:li >
</ rdf:Bag >
</ pr f:J avaP latf o r m >

< rdf:Bag >
< rdf:li >1 </ rdf:li >
< rdf:li >3 </ rdf:li >
</ rdf:Bag >

< prf:MexeSpec > 22.057 </ prf:MexeSpec >
 Yes 
< prf:VideoInputEncoder >
< rdf:Bag >
< rdf:li >H .263 </ rdf:li >
</ rdf:Bag >

< prf:Email - URI - Schemes >
< rdf:Bag >
< rdf:li > pop </ rdf:li >
< rdf:li > imap4 </ rdf:li >
</ rdf:Bag >
</ prf:Email - URI - Schemes >
< prf:JavaPackage >
< rdf:Bag >
< rdf:li > javax . bluetooth </ rdf:li >
< rdf:li > WMA 1.1 </ rdf:li >
< rdf:li > MMAPI 1.1 </ rdf:li >
</ rdf:Bag >
</ prf:JavaPackag e >
< prf: Jav aPro toco l >
< rdf:Bag >
< rdf:li > file /1.0 </ rdf:li >
</ rdf:Bag >
105
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
106
</ pr f:J avaP roto c o l >
</ prf:component >
< prf:component >
< rdf:Description rdf:ID = " N e t w o r k C h a r a c t e r i s t i c s " >
profiles / UAPROF / ccppschema -20021212# N e t w o r k C h a r a c t e r i s t i c s " / >
 1.1 
< prf:SecuritySupport >
< rdf:Bag >
< rdf:li > SSL </ rdf:li >
< rdf:li > TLS </ rdf:li >
</ rdf:Bag >

< prf:SupportedBearers >
< rdf:Bag >
< rdf:li > GPRS </ rdf:li >
< rdf:li > SMS </ rdf:li >
< rdf:li > CSD </ rdf:li >
< rdf:li > USSD </ rdf:li >
< rdf:li > EGPRS </ rdf:li >
< rdf:li > HSCSD </ rdf:li >
< rdf:li > EDGE </ rdf:li >
</ rdf:Bag >

</ prf:component >
< prf:component >
< rdf:Description rdf:ID = " BrowserUA " >
profiles / UAPROF / ccppschema -20021212# BrowserUA " / >
< prf:BrowserName > Nokia 
 1.0 
 No 
< prf:HtmlVersion > 1.0 
 No 
 No 
 No 
 Yes 
< prf: Xht mlVe rsio n > 1.0 
< prf: Xht mlMo dule s >
< rdf:Bag >
< rdf:li > XHTML1 - struct </ rdf:li >
< rdf:li > XHTML1 - blkstruct </ rdf:li >
< rdf:li > xhtml - basic10 </ rdf:li >
</ rdf:Bag >
</ pr f:X html Modu l e s >
</ prf:component >
< prf:component >
< rdf:Description rdf:ID = " W a p C h a r a c t e r i s t i c s " >
profiles / UAPROF / ccppschema -20021212# W a p C h a r a c t e r i s t i c s " / >
C 
< prf:WapVersion > 2.0 
< prf:WmlDeckSize > 131072 
< prf:WmlScriptLibraries >
< rdf:Bag >
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
< rdf:li > Lang </ rdf:li >
< rdf:li > Float </ rdf:li >
< rdf:li > String </ rdf:li >
< rdf:li > URL </ rdf:li >
< rdf:li > WMLBrowser </ rdf:li >
< rdf:li > Dialogs </ rdf:li >
</ rdf:Bag >

< prf:WmlScriptVersion >
< rdf:Bag >
< rdf:li > 1.2.1 </ rdf:li >
</ rdf:Bag >

< prf:WmlVersion >
< rdf:Bag >
< rdf:li > 1.2.1 </ rdf:li >
</ rdf:Bag >
</ prf:WmlVersion >

< rdf:Bag >
< rdf:li > WTA . Public . makeCall </ rdf:li >
< rdf:li > WTA . Public . sendDTMF </ rdf:li >
< rdf:li > WTA . Public . addPBEntry </ rdf:li >
</ rdf:Bag >
</ pr f: W ta iL i br a r i e s >
< prf:DrmClass >
< rdf:Bag >
< rdf:li > ForwardLock </ rdf:li >
< rdf:li > C o m b i n e d D e l i v e r y </ rdf:li >
< rdf:li > S e p a r a t e D e l i v e r y </ rdf:li >
</ rdf:Bag >
</ prf:DrmClass >

< rdf:Bag >
< rdf:li > datetime </ rdf:li >
< rdf:li > interval </ rdf:li >
< rdf:li > count </ rdf:li >
</ rdf:Bag >

< prf:OmaDownload > Yes 
</ prf:component >
< prf:component >
< rdf:Description rdf:ID = " P u s h C h a r a c t e r i s t i c s " >
profiles / UAPROF / ccppschema -20021212# P u s h C h a r a c t e r i s t i c s " / >
< prf:Push - Accept >
< rdf:Bag >
< rdf:li > application / wml + xml </ rdf:li >
< rdf:li > text / html </ rdf:li >
</ rdf:Bag >
</ prf:Push - Accept >
< prf:Push - Accept - Charset >
< rdf:Bag >
< rdf:li >ISO -8859 -1 </ rdf:li >
107
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
</ rdf:Bag >
</ prf:Push - Accept - Charset >
< prf:Push - Accept - Encoding >
< rdf:Bag >
</ rdf:Bag >
</ prf:Push - Accept - Encoding >
< prf:Push - MsgSize > 1400 </ prf:Push - MsgSize >
< prf:Push - MaxPushReq > 30 </ prf:Push - MaxPushReq >
</ prf:component >
< prf:component >
< rdf:Description rdf:ID = " M m s C h a r a c t e r i s t i c s " >
< rdf:type rdf:resource = " http: // www . wapforum . org / profiles / MMS /
ccppschema -20010111# M m s C h a r a c t e r i s t i c s " / >
< m m s : M m s M a x M e s s a g e S i z e > 300000 </ m m s : M m s M a x M e s s a g e S i z e >
< m m s : M m s M a x I m a g e R e s o l u t i o n > 1280 x1024 </ m m s : M m s M a x I m a g e R e s o l u t i o n >
< m ms :M m sC c pp Ac c e p t >
< rdf:Bag >
< rdf:li > application / sdp </ rdf:li >
< rdf:li > application / smil </ rdf:li >
< rdf:li > application / vnd . nok - s40theme </ rdf:li >
< rdf:li > application / vnd . nokia . ringing - tone </ rdf:li >
< rdf:li > application / vnd . oma . drm . content </ rdf:li >
< rdf:li > application / vnd . oma . drm . message </ rdf:li >
< rdf:li > audio /3 gpp </ rdf:li >
< rdf:li > audio / aac </ rdf:li >
< rdf:li > audio / amr </ rdf:li >
< rdf:li > audio / amr - wb </ rdf:li >
< rdf:li > audio / mid </ rdf:li >
< rdf:li > audio / midi </ rdf:li >
< rdf:li > audio / mpeg </ rdf:li >
< rdf:li > audio / rmf </ rdf:li >
< rdf:li > audio / sp - midi </ rdf:li >
< rdf:li > audio /x - mid </ rdf:li >
< rdf:li > audio /x - midi </ rdf:li >
< rdf:li > image / bmp </ rdf:li >
< rdf:li > image / gif </ rdf:li >
< rdf:li > image / jpeg </ rdf:li >
< rdf:li > image / jpg </ rdf:li >
< rdf:li > image / png </ rdf:li >
< rdf:li > image / vnd . nokia . ota - bitmap </ rdf:li >
< rdf:li > image / vnd . nokia . wbmp </ rdf:li >
< rdf:li > image / vnd . nok - wallpaper </ rdf:li >
< rdf:li > image / vnd . nok - oplogo - color </ rdf:li >
< rdf:li > image / vnd . wap . wbmp </ rdf:li >
< rdf:li > image /x - ota - bitmap </ rdf:li >
< rdf:li > text / plain </ rdf:li >
< rdf:li > text /x - vCalendar </ rdf:li >
< rdf:li > text /x - vCard </ rdf:li >
< rdf:li > video /3 gpp </ rdf:li >
</ rdf:Bag >
</ mm s: M ms Cc p pA c c e p t >
< mms:MmsCcppAcceptCharSet >
< rdf:Bag >
< rdf:li >ISO -8859 -1 </ rdf:li >
108
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
</ rdf:Bag >
</ m m s : M m s C c p p A c c e p t C h a r S e t >
< mms:MmsCcppAcceptEncoding >
< rdf:Bag >
</ rdf:Bag >
</ m m s : M m s C c p p A c c e p t E n c o d i n g >
< mms:MmsVersion >
< rdf:Bag >
< rdf:li > 1.2 </ rdf:li >
</ rdf:Bag >
</ mms:MmsVersion >
</ prf:component >
</ rdf:RDF >
109
110
Tabellenverzeichnis
4.1
4.2
Evaluierung der Kontext-Charakteristiken nach [KPRS03] . . . .
Evaluierung der Adaptierungs-Charakteristiken nach [KPRS03] . .
51
55
A.1 Statistik Java Dateien . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Statistik JSP Dateien . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Statistik XML Dateien . . . . . . . . . . . . . . . . . . . . . . . .
90
90
90
B.1 Kapitel und Autoren . . . . . . . . . . . . . . . . . . . . . . . . .
93
E.1 Einige für die Erkennung der Geräteeigenschaften von Mobilen
Endgeräten interessante MIME-Typen . . . . . . . . . . . . . . . 101
111
Listings
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
B.1
F.1
Request Header Pocket Internet Explorer . . . . . . . . . . . . . . 25
Request Beispiel eines CC/PP Profils . . . . . . . . . . . . . . . . 26
Request Beispiel eines CC/PP Profils . . . . . . . . . . . . . . . . 27
CSS Stil mit Styledefinitionen für die verschiedenen Endgeräte . . 33
Überschriften vs. Sektionen in XHTML 2.0 . . . . . . . . . . . . . 36
XHTML Dokument vor der Transformation . . . . . . . . . . . . 37
XSLT Dokument . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
XHTML Dokument nach der Transformation . . . . . . . . . . . . 38
Mehtode zum Erkennen der vom Benutzer bevorzugten Sprache . 70
Ausschnitt aus der Methode zum Erkennen der Geräteeigenschaften mit Hilfe von DELI . . . . . . . . . . . . . . . . . . . . . . . . 71
Pointcut detectContext . . . . . . . . . . . . . . . . . . . . . . . . 77
Advice detectContext . . . . . . . . . . . . . . . . . . . . . . . . . 77
Pointcut doForward . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Advice doForward . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Pointcut doMainAdaptation . . . . . . . . . . . . . . . . . . . . . 82
Advice doMainAdaptation . . . . . . . . . . . . . . . . . . . . . . 82
Ponitcut doArticleCountTransformation . . . . . . . . . . . . . . 83
Advice doArticleCountTransformation . . . . . . . . . . . . . . . 83
Pointcut doTextTransformation . . . . . . . . . . . . . . . . . . . 83
Advice doTextTransformation . . . . . . . . . . . . . . . . . . . . 83
Pointcut doListSystemCPTransformation . . . . . . . . . . . . . . 84
Advice doListSystemCPTransformation . . . . . . . . . . . . . . . 84
Pointcut doRatingCPTransformation . . . . . . . . . . . . . . . . 84
Advice doRatingCPTransformation . . . . . . . . . . . . . . . . . 85
Ant Build Konfiguration . . . . . . . . . . . . . . . . . . . . . . . 91
UAProf Profil des Nokia 6230i . . . . . . . . . . . . . . . . . . . . 102
112
2.1
2.2
2.3
8
11
2.4
2.5
Kategorien von Web-Anwendungen . . . . . . . . . . . . . . . . .
Ursprünge der Customization [KPRS03] . . . . . . . . . . . . . .
Umfang der Customization anhand der Modellierungsdimensionen
von Web-Anwendungen [KaRS00] . . . . . . . . . . . . . . . . . .
Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
event/condition/action [FSK+ 02] . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
Intermediate Adaptation . .
Client Side Adaptation . . .
Server Side Adaptation . . .
Dekomposition mit Hilfe von
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Frontend Use Case . . . . . . . .
Backend Use Case . . . . . . . . .
MVC-Modell . . . . . . . . . . .
Architektur . . . . . . . . . . . .
Datenbank-Schema . . . . . . . .
Requestablauf ohne Adaptierung
Requestablauf mit Adaptierung .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
Kommentaren
Überschriften .
Regions . . . .
14
15
20
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
33
34
35
36
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
45
56
57
58
60
60
Eingesetzte Technologien . . . . . . . . . . . . . . . . . . . . . . .
Weaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Screenshot des Forschungsprototypen im Winterdesign . . . . . .
Screenshot der für einen PDA adaptierten Anwendung im Sommerdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Requestablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6 Schema Adaptierungsvorgang der Artikel basierend auf sozialen,
natürlichen und logischen Kontext . . . . . . . . . . . . . . . . . .
64
67
68
C.1 Startseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.1
5.2
5.3
5.4
74
76
79
113
C.2 Artikelansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.3 Artikelbewertung . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.4 Reisekoffer ansehen . . . . . . . . . . . . . . . . . . . . . . . . . .
D.1
D.2
D.3
D.4
D.5
Artikelzentrale . . . . . . . . . . . . .
Artikelübersicht . . . . . . . . . . . .
Artikel bearbeiten/anlegen . . . . . .
Contentpart Text bearbeiten/anlegen
Kategorien bearbeiten/anlegen . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
95
96
96
. 97
. 98
. 99
. 100
. 100
114
[AvZe97]
Avery, C. und Zeckhauser, R.: Recommender Systems for
Evaluating Computer Messages. Communications of the ACM
(CACM), 40(3), März 1997.
[BaDR06]
Baldauf, M., Dustdar, S. und Rosenberg, F.: A Survey on
Context-Aware Systems. International Journal of Ad Hoc and
Ubiquitous Computing, forthcoming, 2006.
[BFK+ 00]
Badrinath, B., Fox, A., Kleinrock, L., Popek, G., Reiher, P. und
Satyanarayanan, M.: A Conceptual Framework for Network and
Client Adaptation. IEEE Mobile Networks and Applications,
5(4):221–231, 2000.
[BGGW02] Butler, M., Giannetti, F., Gimson, R. und Wiley, T.: Device
Independence and the Web. Spotlight, Seiten 81–86, 2002.
[BrMa02]
Brusilovsky, P. und Maybury, T.: From adaptive hypermedia to
adaptive Web. Communications of the ACM (CACM), 45(5):31–33,
Dezember 2002. Special Issue on the Adaptive Web.
[Bros06]
Brosch, P.: Ubiquitäre Web-Anwendungen - Realisierung von
Adaptierung mit Hilfe aspektorientierter Programmierung.
Diplomarbeit, Technische Universität Wien, 2006.
[ChKo00]
Chen, G. und Kotz, D: A Survey of Context-Aware Mobile
Computing Research. Technischer Bericht TR2000-381, Dept. of
Computer Science, Dartmouth College, November 2000.
[CSS]
Cascading Style Sheets. http://www.w3.org/Style/CSS/.
[Demo06]
Demolsky, M.: State of the Art in Java Enterprise Web Application
Development. Diplomarbeit, Technische Universität Wien, 2006.
[EPS+ 01]
Espinoza, F., Persson, P., Sandin, A., Nyström, H., Cacciatore, E.
und Bylund, M.: GeoNotes: Social and Navigational Aspects of
115
Location-Based Information Systems. In: Proceedings of the 3rd
International Conference on Ubiquitous Computing, Atlanta,
Georgia, USA, Seiten 2–17. Springer Berlin / Heidelberg, 2001.
[FiKS97]
Fink, J., Kobsa, A. und Schreck, J.: Personalized Hypermedia
Information Provision Through Adaptive and Adaptable System
Features: User Modelling, Privacy and Security Issues. In:
Proceedings of the Fourth International Conference on Intelligence
in Services and Networks, Seiten 459–467. Springer Berlin /
Heidelberg, 1997.
[FSK+ 02]
Finkelstein, A., Savigni, A., Kappel, G., Retschitzegger, W.,
Schwinger, W. und Feichtner, C.: Ubiquitous Web Application
Development - A Framework for Understanding. In: Proceedings of
the 6th World Multiconference on Systemics, Cybernetics and
Informatics (SCI), Orlando, Florida, Seiten 431–438, 2002.
[GoWJ84] Good, M. D., Wixon, D. R. und Jones, S. J.: Building a
User-Derived Interface. Communications of the ACM (CACM),
27(10), Oktober 1984.
[HKRS02] Hitz, M., Kappel, G., Retschitzegger, W. und Schwinger, W.: Ein
UML-basiertes Framework zur Modellierung ubiquitärer
Web-Anwendungen. 2002.
[IBM06]
WebSphere Transcoding Publisher. http://www306.ibm.com/software/pervasive/transcoding publisher/,
2006.
[KaRe98]
Kappel, G. und Retschitzegger, W.: The TriGS Active
Object-Oriented Database System - An Overview. SIGMOD Rec.,
27(3):36–41, 1998.
[KaRS00]
Kappel, G., Retschitzegger, W. und Schwinger, W.: Modeling
Customizable Web Applications - A Requirement’s Perspective.
2000.
[KDJ+ 04]
Kerer, C., Dustdar, S., Jazayeri, M., Gomes, D., Szego, A. und
Caja, J. A. B.: Presence-aware infrastructure using web services
and RFID technologies. In: Proceedings of the 2nd European
Workshop on ObjectOrientation and Web Services, Oslo, Norway.
Springer LNCS, 2004.
116
[KPRR04] Kappel, G., Pröll, B., Reich, S. und Retschitzegger, W.: Web
Engineering, Band 1. dpunkt.verlag, Heidelberg, 2004.
[KPRS03]
Kappel, G., Pröll, B., Retschitzegger, W. und Schwinger, W.:
Customisation for Ubiquitous Web Applications - A Comparison of
Approaches. Int. Journal of Web Engineering and Technology
(IJWET), 1:79–111, 2003.
[KRK+ 02] Kappel, G., Retschitzegger, W., Kimmerstorfer, E., Pröll, B.,
Schwinger, W. und Hofer, T.: Towards a Generic Customisation
Model for Ubiquitous Web Applications. 2002.
[LoTe92]
Loeb, S. und Terry, D.: Information Filtering. Communications of
the ACM (CACM), 35(12), Dezember 1992.
[Msdn06]
Identifying Pocket Internet Explorer to a Web Server.
http://msdn.microsoft.com/library/default.asp?url=/library/en us/
wcepie/html/ceconIdentifyingPocketInternetExplorerToWebServer.asp,
2006.
[Noki04]
Nokia: Guidelines For Creating Web Content For Mobile And PC
Browsing. 2004.
[OMA006] User Agent Profile, Approved Version 2.0.
http://member.openmobilealliance.org/ftp/Public documents/BAC/
UAPROF/Permanent documents/OMA-TS-UAProf-V2 020060206-A.zip,
2006.
[RDF04]
Resource Description Framework (RDF).
http://www.w3.org/RDF/, 2004.
[RFC2]
Hypertext Transfer Protocol – HTTP/1.1.
http://www.ietf.org/rfc/rfc2616.txt.
[SSK+ 06]
Schauerhuber, A., Schwinger, W., Kapsammer, E., Retschitzegger,
W., Wimmer, M. und Kappel, G.: A Survey on Aspect-Oriented
Modeling. 2006.
[STAT05]
IKT-EINSATZ IN HAUSHALTEN, Ergebnisse der Europaeischen
Erhebung über den Einsatz von Informations - und
117
Kommunikationstechnologien in Haushalten 2005.
http://www.statistik.at/fachbereich forschung/ikt txt.shtml, 2005.
[W3C003]
Device Independence Principles. http://www.w3.org/TR/di-princ/,
September 2003. W3C Note.
[W3C004a] Authoring Techniques for Device Independence.
http://www.w3.org/TR/2004/NOTE-di-atdi-20040218/, Februar
2004. W3C Note.
[W3C004b] Composite Capabilities/Preference Profiles (CC/PP): Structure and
Vocabularies 1.0. http://www.w3.org/TR/CCPP-struct-vocab/,
Januar 2004. W3C Recommendation.
[W3CX99] XSL Transformations. http://www.w3.org/TR/xslt, 1999.
[WaSc01]
Want, B.N. und Schilit, B.N.: Expanding the Horizons of
Location-Aware Computing (Guest Editor’s Introduction).
Computer, 34(8):31–33, August 2001.
[Weis91]
Weiser, M.: The Computer for the 21st Century. Scientific
American, Seite 265, 1991.
[Weis06]
Weissensteiner, A.: Ubiquitäre Web-Anwendungen. Diplomarbeit,
Technische Universität Wien, 2006.
[wurf06]
Wireless Universal Resource File. http://wurfl.sourceforge.net/,
2006.
[XPAT99]
XML Path Language (XPath). http://www.w3.org/TR/xpath,
1999.
[XPTR02] XML Pointer Language (XPointer). http://www.w3.org/TR/xptr/,
2002.

paper

Transcription

Documents pareils

5. ¨Ubungsblatt: Musterl¨osung RDF Modellierung

Übung 7

Funktionär/Fonctionaire

plus-time Zeitmanagement bei der Aduno Gruppe

Benutzerverwaltung mit Zugriffsrechteverwaltung (optional

Urk. Lehmann 600 Ludwig Philipp von Pfalz

Nennungsformular für Mannschaften Kat - VMM-IS