Web Engineering für asynchrone Anwendungen

Inhaltsverzeichnis

1 Motivation

2 Webanwendungen
2.1 De nition und Klassi zierung
2.2 Unterschiede zu Standard-Applikationen
2.3 Request Cycle Prinzip
2.4 Überblick über aktuelle Web-Technologien

3 Asynchrone Webanwendungen
3.1 Das Web 2.0
3.2 Unterschiede zu herkömmlichen Webanwendungen
3.3 Asynchrone Kommunikation im Web durch AJAX

4 UML Web Engineering
4.1 Allgemeines zu Web Engineering
4.2 UWE

5 Fallstudie: IT-Atlas
5.1 Beschreibung
5.2 Verteilter Aspekt
5.3 Nicht-Funktionale Anforderungen

6 Analyse
6.1 Use Case Modell
6.2 Content Modell
6.3 Datenhaltung regionaler/zentraler Daten
6.4 Modellierung und Einsatz asynchroner Kommunikation .

7 Entwurf
7.1 Navigationsmodell
7.2 Präsentationsmodell
7.3 Modellierung des Verhaltens
7.4 Entwurf des Web Service

8 Implementierung
8.1 Einsatz der AJAX-Technologie
8.2 Der Web Service
8.3 Probleme/Hindernisse

9 Test
9.1 Testen asynchroner Anwendungen
9.2 Testen der IT-Atlas Anwendung
9.3 Testen des Web Service

10 Der Prototyp
10.1 Das Modul Suchen
10.2 Das Modul Eintragen
10.3 Das Modul Bearbeiten
10.4 Der Web Service

11 Fazit/Ausblick

ERKLÄRUNG ZUR DIPLOMARBEIT

Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbstständig und ohne Be- nutzung anderer als der angegebenen Quellen angefertigt habe. Die den benutzten Quel- len wörtlich oder inhaltlich entnommenen Stellen habe ich als solche kenntlich gemacht. Diese Arbeit hat bisher noch keiner anderen Prüfungskommission zur Begutachtung vor- gelegen.

München, 28. Februar 2006

Zusammenfassung

Die vorliegende Arbeit beschreibt eine Evaluierung der besonderen Anforderungen, welche der Einsatz eines neuartigen Konzepts zur Realisierung asynchroner Kommu- nikation innerhalb von Webanwendungen an einen Web Engineering-Prozess stellt. Das World Wide Web, ursprünglich eine Ansammlung miteinander verlinkter Infor- mationsseiten, vollzieht durch aktuelle Entwicklungen und Tendenzen eine grund- legende Veränderung des eigenen Charakters als passive Informationsquelle und Plattform für HTTP-basierte Applikationen. Dieses als Web 2.0 bezeichnete neue Verständnis des Webs de niert dieses als vollwertige Anwendungsplattform für hoch entwickelte Software und Dienste.

Im Sinne von Web 2.0 sind Webapplikationen interaktiv, auf den Endbenutzer zuge- schnitten und fühlen sich wie Desktop-Anwendungen an. Einzelne Anwendungen sollen nicht für sich alleine stehen, sondern Daten über Web Services zur Verfügung stellen bzw. nutzen, um so neue, übergeordnete Dienste zu ermöglichen. Eine wichtige Säule in diesem Ansatz stellt der AJAX ( Asynchronous Javascript and XML )-Ansatz dar. Dieser ermöglicht eine asynchrone Kommunikation zwi- schen Browser und einem Server ohne explizite Au orderung durch den Benutzer, und bewirkt damit einen massiven Einschnitt in das Kommunikationsparadigma, auf welchem alle Web Engineering Ansätze aufbauen.

Innerhalb dieser Diplomarbeit sollen daher die Möglichkeiten, aber auch Gren- zen der AJAX-Technologie sowie die Anwendbarkeit der Techniken und metho- dischen Schritte des Web Engineerings für diese neue Generation von Webanwen- dungen anhand einer Beispielanwendung und UWE als Vorgehensmodell ermittelt werden. Dafür wird ein Fallbeispiel-Projekt, eine Datenbankanwendung zur Suche, Verwaltung und Eintragung von IT-Firmen, dem UWE-Prozessmodell folgend mo- delliert und anschlieÿend ein Prototyp vorgestellt. Die Anwendbarkeit der UWE- Diagrammtypen wird dabei in den Phasen Analyse, Navigations- und Präsentati- onsmodellierung untersucht und bewertet.

1 Motivation

Das Internet hat sich im Laufe der letzten Jahre nachhaltig von einem reinen Informationsmedium zu einem Anwendungsmedium entwickelt - Webanwendungen sind mittlerweile vollwertige, komplexe Softwaresysteme, deren Entwicklung eine ingenieursmäÿige und methodisch fundierte Herangehensweise erfordert.

Die formalen und praktischen Methoden des traditionellen Software Engineering können aufgrund der besonderen Charakteristika von Webanwendungen nicht unverändert auf das Webumfeld übernommen werden, daher wurden im Zuge der neu entstandenen Dis- ziplin Web Engineering systematische und quanti zierbare Ansätze für die Entwicklung qualitativ hochwertiger Webanwendungen ermittelt. Insbesondere auf Modellierungsebe- ne existiert eine Vielzahl verschiedenster Ansätze für Webanwendungen, darunter das UML-based Web Engineering (UWE), welches am Lehrstuhl für Programmierung und Softwaretechnik der Ludwig-Maximilians-Universität München entwickelt wurde. UWE setzt bei der Modellierung auf eine Erweiterung der UML und begegnet den speziellen Anforderungen von Webanwendungen mit einer separaten Modellierung von Content, Navigation und Präsentation.

Die altbekannte Hypertext-Struktur des Webs, d.h. die Verknüpfung von Informationsein- heiten (im traditionellen Sinne Seiten) durch Links, auf der UWE und alle weiteren Web Engineering Ansätze aufbauen, ist durch neueste Entwicklungen im Webumfeld allerdings ins Wanken geraten: Der Web 2.0-Ansatz, von den Befürwortern als Zukunft des Inter- nets propagiert, de niert das Web als vollwertige Anwendungsplattform und beschreibt zwei zentrale zugrundeliegende Konzepte: Zum Einen wird gefordert, dass Webanwen- dungen Daten über Web Services zur Verfügung stellen, um so neue, übergeordnete Applikationen zu ermöglichen. Die zweite Forderung ist die Angleichung des Niveaus der Benutzerschnittstellen von Webanwendungen an das von Desktop-Applikationen. Die gröÿten Probleme des Webumfelds in dieser Hinsicht ergeben sich dabei durch die Sei- tengebundenheit sowie den synchronen Charakter der Kommunikation zwischen Client und Server. Dieses statische Prinzip, Request Cycle genannt, beschreibt den traditio- nellen Kommunikationsablauf innerhalb von Webanwendungen: Nach einem Aufruf für eine Serveranfrage seitens des Benutzers wird diese vom Browser abgeschickt und auf die Antwort gewartet. Auf Serverseite wird die Anfrage verarbeitet und eine HTML-Seite als Ausgabe generiert, welche anschlieÿend im Browser des Clients angezeigt wird.

Dieses Konzept stellt eine deutliche Benachteiligung von Webanwendungen bezüglich Benutzerfreundlichkeit und Interfacegestaltung dar und bedarf dementsprechend im Sinne von Web 2.0 einer Alternative.

Der AJAX-Ansatz, eine Form der asynchronen Kommunikation im Rahmen des HTTP- Protokolls, kommt hierbei als Lösung in Frage. AJAX ermöglicht asynchrone Kommu- nikation ohne Leerzeit auf Clientseite und eine Loslösung vom seitenorientierten Dar- stellungsprinzip von Webanwendungen, ohne dabei externe Plugins oder Bibliotheken zu erfordern. Dadurch o enbaren sich Entwicklern von Webanwendungen völlig neue Mög- lichkeiten hinsichtlich Benutzerfreundlichkeit, Kontextsensitivität und Design der Benut- zerschnittstelle.

Aufgrund der massiven Einschnitte, welche der Einsatz der AJAX-Technologie in das bekannte Kommunikationsparadigma des Webs vornimmt, stellt sich die Frage, ob diese neue Generation von Webanwendungen innerhalb der bekannten formalen Konzepte ausreichend modelliert werden kann.

Die zentrale Aufgabe dieser Diplomarbeit teilt sich daher in zwei Aspekte auf, zum Einen die Ermittlung der Möglichkeiten, aber auch Grenzen der AJAX-Technologie, zum Ande- ren die Evaluierung der Modellierbarkeit von asynchron kommunizierenden Webanwen- dungen im Rahmen bekannter Web Engineering Methoden am konkreten Beispiel von UWE.

Zu diesem Zweck wird eine Beispielanwendung auf AJAX-Basis mit integriertem Web Service von der Anforderungsspezi kation bis zum Entwurf dem UWE Prozessmodell entsprechend modelliert und anschlieÿend implementiert. Die Erkenntnisse und entste- henden Probleme sowie deren Lösungen werden dabei in jeder Prozessphase festgehalten. Um den Einstieg in das Thema zu erleichtern, wird in Kapitel 2 zunächst ein Überblick über traditionelle und in Kapitel 3 über Web 2.0-Anwendungen gegeben. Kapitel 4 bietet dem Leser eine Einführung in die grundlegenden Konzepte von UWE, Kapitel 5 stellt das für diese Arbeit verwendete Beispielprojekt vor. Kapitel 6, 7, 8 und 9 befassen sich mit den Entwicklungsschritten Analyse, Design, Implementierung und Test und deren Anwendbarkeit für asynchron kommunizierende Anwendungen, der im Rahmen dieser Arbeit entwickelte Prototyp wird in Kapitel 10 präsentiert. Kapitel 11 liefert schlussend- lich ein Fazit und einen Ausblick auf zukünftige Arbeiten in diesem Gebiet.

2 Webanwendungen

2.1 De nition und Klassi zierung

Die groÿ ächige Verbreitung und breite Akzeptanz des Internets hat im Laufe der letzten Jahre zu einem groÿen Umbruch im Konzept von Client/Server-Applikationen geführt: Anstelle einer mühsamen Installation und Wartung von lokalen Clients auf den Rech- nern der Benutzer eines Systems werden in den meisten Fällen Applikationen dieser Art als Webanwendung realisiert. Die gröÿten Vorteile liegen dabei im komfortablen und einheitlichen Zugri unabhängig von einem lokalen Client (ein kompatibler Browser ge- nügt) sowie in der Erschlieÿung gröÿerer potentieller Nutzerkreise durch die globale und permanente Verfügbarkeit des Webs. Im Allgemeinen beschreibt die Bezeichnung We- banwendung ein Softwaresystem, auf welches folgende De nition zutri t (Kappel u. a., 2004):

Software-Anwendung, die auf Technologien und Standards des World Wide Web Consortium (W3C) beruht und webspezi sche Ressourcen wie Inhalte und evtl. auch Dienste bereitstellt, die über eine Benutzerschnittstelle (Webbrowser) verwendet werden

Diese De nition klingt sehr allgemein, inkludiert aber explizit zwei wichtige Aspekte zur Eingrenzung der de nierten Domäne:

Software-Aspekt: Die ausdrückliche Verwendung der Begri e Software und Anwendung impliziert die Fokussierung der De nition auf softwareintensive Systeme, rein statische Seiten erfüllen zwar die De nitions-Kriterien, können aber in den wenigsten Fällen als Anwendung aufgefasst werden.

Benutzerschnittstellen-Aspekt: Das Vorhandensein einer Benutzerschnittstelle wird explizit gefordert, d.h. ein Web Service, welcher Daten zur maschinellen Weiterverarbei- tung liefert, stellt für sich alleine keine Webanwendung gemäÿ der obigen De nition dar. Anwendungen, die obiger De nition genügen, existieren in verschiedensten Komplexi- tätsgraden, weswegen eine Klassi zierung in Kategorien unumgänglich erscheint. Nach aufsteigender Komplexität sowie Aktualität lassen sich Webanwendungen gem. Kappel u. a. (2004) folgendermaÿen unterteilen:

- Dokumentzentriert (Statische Homepage)
-Interaktiv (z.B. News-Site, Fahrplanauskunft)
-Transaktional (z.B. Online-Banking, Reservierungssystem)
- Work ow-basiert (z.B. E-Government, Patienten-Work ow)
-Kollaborativ (z.B. Chatroom, virtueller gemeinsamer Arbeitsplatz)
- Portalorientiert (z.B. Community- oder Unternehmensportal)
-Ubiquitär (Personalisierte, ortsabhängige Multi-Plattform-Dienste)
- Semantisches Web (Recommendation Systems, Wissensmanagement)

Da das Thema dieser Diplomarbeit die Untersuchung der Möglichkeiten von asynchroner Kommunikation innerhalb von Webanwendungen ist, stellt sich naturgemäÿ die Frage nach der Einordnung dieser Technologie in die eben genannten Kategorien. Jede der ge- nannten Kategorien baut zu einem groÿen Teil auf Technologien der vorangegangen auf, de niert jedoch eine neue Zielrichtung der beschriebenen Webanwendungen. Asynchrone Kommunikation ist eng mit dem Web 2.0-Konzept (siehe Kapitel 3) verknüpft, welches sich aber nicht wirklich als eigenständige Kategorie mit neuer Zielvorgabe präsentiert.

Einige der in der Kategorisierung von Webanwendungen enthaltenen Aspekte (Kollabo- ration bzw. sozialer Charakter, Semantisches Web) tauchen zwar in der Idee zu Web 2.0 auf, aber mehr als eine neue Ausrichtung und damit einer eigenständigen Kategorie werden gewisse Richtlinien und Qualitätsstandards für Webanwendungen formuliert. Ähnlich verhält es sich mit der asynchronen Kommunikation, die Technologie kann sehr wohl genutzt werden um die bestehenden Arten von Webanwendungen qualitativ zu verbessern, de niert jedoch nach Meinung des Autors nicht zwingend eine eigenständige Kategorie von Webapplikationen.

Der Nutzen sowie die E zienz des Einsatzes asynchroner Kommunikation steigt mit der Komplexität der Anwendung, in welcher diese eingesetzt wird. In einfachen Anwendungen besteht der Gewinn aus einer reinen Erhöhung des Benutzerkomforts, wahrhaft neue Möglichkeiten ergeben sich allerdings in komplexen Umfeldern: So kann beispielsweise ein Recommendation System seine Empfehlungen sofort an aktuelle Benutzer-Aktivitäten anpassen beziehungsweise sehr komplexe statistische Berechnun- gen asynchron durchführen, während der Benutzer die Seite weiter nutzt, und die ermittelten Empfehlungen nachreichen .

Gemäÿ der oben genannten De niton ist zur Nutzung von Webanwendungen lediglich ein kompatibler Browser nötig, was eine Bindung an bestimmte Standards (Aufruf über URL), Kommunikationsprotokolle (HTTP, TCP/IP) und Darstellungsmöglichkeiten (HTML) nötig macht. Dieser und andere Aspekte (z.B. bezüglich Nutzung und Entwick- lung) führen zu einigen grundlegenden Unterschieden zwischen Webanwendungen und Standard-Applikationen, daher wird diese Di erenzierung im folgenden Unterkapitel näher beleuchtet.

2.2 Unterschiede zu Standard-Applikationen

Webanwendungen weisen eine ganze Reihe eigener Charakteristika auf, welche gegenüber Standard-Applikationen entweder

- Webanwendungen völlig vorbehalten sind, wie z.B. die nicht-lineare Naviga- tion durch die Anwendung, bedingt durch deren Hypertextstruktur, oder

-in Webanwendungen besonders stark ausgeprägt sind, wie z.B. die Häu g- keit von Änderungen.

Das Vorhandensein sowie die Intensität eines Charakteristikums ist natürlich abhän- gig von der Art und Komplexität der Anwendung. Eine interaktive, webbasierte News- Anwendung unterliegt naturgemäÿ sehr häu gen Änderungen des Content, während eine transaktionale E-Commerce-Applikation mehr Augenmerk auf Sicherheit und Konsistenz der Daten legen muss. Diese Charakteristika sind auch der Grund, weshalb Konzepte, Methoden, Techniken und Werkzeuge des traditionellen Software Engineering im Web- Umfeld entweder angepasst werden müssen, oder sich als gänzlich ungeeignet erweisen. Der in dieser Arbeit verwendete und untersuchte Ansatz zur Entwicklung von Weban- wendungen, das UML-basierte Web Engineering, wird in Kapitel 4 eingehend vorgestellt. Die besonderen Eigenschaften von Webanwendungen lassen sich im Groben in drei Ka- tegorien einordnen (Kappel u. a., 2004):

- Produktbezogene Charakteristika
- Nutzungsbezogene Charakteristika
- Entwicklungsbezogene Charakteristika

Da diese drei Ebenen die kritischen Punkte von Webanwendungen beleuchten, wird auf diese im Folgenden detailliert eingegangen:

2.2.1 Produktbezogene Charakteristika

Aus produktbezogener Sicht liefert eine Webanwendung Content, welcher durch eine Hypertext-Navigation zugreifbar ist, und stellt diesen über eine bestimmte Präsentation dem Benutzer zur Verfügung. Diese 3 elementaren Bestandteile beinhalten Eigenschaften, die für Webanwendungen im Allgemeinen charakteristisch sind:

- Content

Content, also Inhalte einer Webapplikation, kann in verschiedenster medialer Form vorliegen. Content kann Tabellen, Texte, Gra ken, aber auch Animationen oder Audio und Video beinhalten, dabei müssen die verschiedenen multimedialen Inhalte ansprechend kommuniziert und aufbereitet werden, was hohe Ansprüche an die Usability einer Webanwendung stellt.

Desweiteren muss Content hohen Qualitätsansprüchen hinsichtlich Aktualität, Genauigkeit, Konsistenz, Verlässlichkeit und Umfang genügen, da die Qualität der Inhalte ein kritischer Faktor für die Akzeptanz einer Webanwendung ist. Bestimmte Arten von Content haben bei unzureichender Qualität beziehungsweise Konsistenz sogar fatale Folgen, zum Beispiel die Preis- und Verfügbarkeitsinformationen in einem E-Shopping-System.

- Hypertext

Hypertext beschreibt die Organisation von Inhalten innerhalb einer Webanwen- dung, deren Struktur durch logische Verbindungen (Links) hergestellt wird. Damit ist es dem Benutzer möglich, sich nicht-linear durch den Informationsraum zu bewegen, abhängig von Interesse oder Vorwissen. Diese Tatsache kann allerdings auch zu Desorientierung und erhöhter kognitiver Belastung führen, eine benut- zerfreundliche Hypertext-Struktur ist dadurch eine groÿe Herausforderung für die Autoren von Webanwendungen.

- Präsentation

Was der Benutzer von einer Webanwendung innerhalb seines Browsers sieht, wird als Präsentation bezeichnet. Natürlich sind im Kontext der Präsentation gewisse ästhetische Aspekte zu berücksichtigen, wichtiger ist jedoch eine gewisse Benut- zerfreundlichkeit der Schnittstelle, da für Webanwendungen im Allgemeinen keine Benutzerdokumentation vorliegt. Allzu komplexe Benutzerschnittstellen schrecken im Web-Umfeld die Benutzer ab, daher ist auf eine einheitliche Benutzungslogik zu achten.

2.2.2 Nutzungsbezogene Charakteristika

Die nutzungsbezogenen Charakteristika von Webanwendungen werden von drei Aspekten geprägt, einem sozialen, einem technischen und einem natürlichen Kontext:

- Sozialer Kontext: Benutzer

Benutzer einer Webanwendung können diese völlig spontan aufsuchen, aber auch verlassen, durch diesen spontanen Charakter der Nutzung ist eine Anzahl der Be- nutzer eines Systems sehr schwer einschätzbar. Durch die globale Verfügbarkeit des

Webs ist eine gewisse Multikulturalität der Benutzer unumgänglich, was beim An- forderungserwerb die De nition eines repräsentativen Nutzerkreises der Anwendung erschwert.

• Technischer Kontext: Netzwerke und Endgeräte

Die Güte einer Webanwendung hinsichtlich Performanz und Antwortzeit ist stark abhängig von der Qualität der zugrundeliegenden Netzwerkeigenschaften. Diese können von der Applikation nicht abgefragt oder ermittelt werden, um gegebenenfalls entsprechend darauf zu reagieren. Aus diesem Grunde kann eine Webapplikation bei Abfrage aus verschiedenen Netzen eine hohe Diskrepanz in der Antwortzeit aufweisen. Ebenso unterschiedlich wie die Netzeigenschaften sind die Endgeräte der Benutzer - diese müssen lediglich einen kompatiblen Browser enthalten, können aber hinsichtlich entscheidender Leistungsmerkmale sehr unterschiedlich sein.

- Natürlicher Kontext: Ort und Zeit

Eine Webanwendung ist weltweit zur Nutzung verfügbar, will man als Entwickler keine Nutzergruppen ausschlieÿen, so müssen entsprechende Maÿnahmen hinsicht- lich regionaler, kultureller und linguistischer Unterschiede getro en werden. Ein Beispiel wäre, die Webanwendung zu einem ortsabhängigen Dienst zu erweitern. Hinsichtlich der Verfügbarkeit gibt es für eine Webanwendung keine bewusst kalku- lierten Down-Zeiten oder Wartungs-Fenster , eine solche Applikation muss sofort und permanent verfügbar sein.

2.2.3 Entwicklungsbezogene Charakteristika

Bei der Entwicklung von Webanwendungen gibt es einige Merkmale, die sich vom Ent- wicklungsprozess von Standardapplikationen unterscheiden. Insbesondere hervorzuheben wären dabei die Aspekte der Projektmitarbeiter, der technischen Infrastruktur sowie des Prozesses:

- Projektmitarbeiter

Durch die besonderen Eigenschaften des Produkts Webanwendung (siehe 2.2.1) arbeiten in einem Entwicklerteam Mitarbeiter aus verschiedensten Disziplinen zu- sammen. Eine fertige Webapplikation stellt eine Mischung dar aus Printpublishing und Softwareentwicklung, Marketing und Informatik, Kunst und Technologie. Für jeden Aspekt der Anwendung (Software, Hypertext, Design und betre ende Do- main) sind während der Entwicklung Experten vonnöten, eine erfolgreiche Koordi- nation dieses multidisziplinären Teams ist für den Projekterfolg entscheidend. Da die Technologie der Webanwendungen sehr jung ist, sind sowohl die Entwickler als auch die eingesetzten Technologien und Vorgehensmodelle meist unerfahren bzw. wenig erprobt, was eine besondere Aufmerksamkeit der Projektleitung hinsichtlich des Prozessfortschritts erfordert.

- Technische Infrastruktur

Eine Webanwendung ist stark abhängig von zwei Fremdkomponenten, welche zur Ausführung benötigt werden: Einem Webserver, welcher aber in der Regel zumin- dest selbst kon guriert und bedient werden kann, und einem Webbrowser, dessen Einstellung und Kon guration jedoch dem Benutzer obliegt. Daher ist es vonnöten, die Webanwendung nicht auf eine mögliche Kon guration zuzuschneiden, sondern diese möglichst Browser-unabhängig zu gestalten um keine Nutzerkreise auszu- schlieÿen. Dennoch ist eine Webanwendung von beiden Komponenten abhängig, sind diese fehlerbehaftet ist auch die Anwendung nicht zu benutzen.

- Prozess

Der Entwicklungsprozess von Webanwendungen beinhaltet keine starr vorgegebenen Prozessschemata, alle Ansätze für Web-Vorgehensmodelle sind exibel gestaltet und erlauben viel Raum für eigene Entscheidungen. Einzelne Teile der Anwendung, aber auch ganze Phasen können dabei parallel bearbeitet werden.

2.3 Request Cycle Prinzip

Das Request Cycle Prinzip beschreibt den klassischen Ablauf der Kommunikation zwi- schen Client (Browser) und einem Server im Umfeld von Webapplikationen (s. Abbildung 1). Um eine Kommunikation auszulösen bedarf es dabei immer einer expliziten Aktion des

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Client/Server-Kommunikation in Webanwendungen

Benutzers innerhalb dessen Browser, wie das Anklicken eines Links oder das Ausfüllen und Absenden eines Formulars. Eine Anfrage an einen Webserver kann zwar auch über Javascript ohne explizite Benutzeraktion geschehen (durch einen Timer beispielsweise), da im Resultat aber immer eine neue HTML-Seite generiert wird, würde ein solches Verhalten den Benutzer verwirren oder gar abschrecken.

Ist auf Seite des Clients ein Aufruf an einen Webserver erfolgt, wird ein Request Cycle ausgelöst, der sich folgendermaÿen darstellt:

- Der Webserver erhält die HTTP-Request mit bestimmten Parametern
- Die Anforderung wird innerhalb einer Anwendung, die auf dem Webserver läuft, verarbeitet
- Die Anwendung generiert eine Antwort in Form einer HTML-Seite
- Die Antwort-Seite wird im Browser des Clients angezeigt

Der entscheidende Nachteil dieses Konzepts liegt im synchronen Charakter der Kommu- nikation (vgl. Abbildung 2): Der Client (und damit auch der Benutzer) ist zum Warten

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Synchrone Kommunikation mit Leerzeiten auf beiden Seiten

verurteilt, während Verarbeitungen auf Server-Seite durchgeführt werden, da die An- wendung bis zum Abschluss der Prozedur nicht genutzt werden kann. Serverseitig muss mit der Verarbeitung von Eingaben gewartet werden, bis der Benutzer diese explizit ab- schickt, selbst wenn eine sinnvolle Vorverarbeitung bereits eingetragener Daten möglich gewesen wäre, wie beispielsweise beim Ausfüllen eines komplexen Web-Formulars. Der Aspekt der Leerzeiten auf beiden Seiten, welcher durch die technische Infrastruktur von bisher bekannten Webanwendungen unvermeidlich ist, ist hinsichtlich der Benutzer- führung ein groÿer Nachteil gegenüber Standard-Applikationen, deren Kommunikations- art und -ablauf von den Entwicklern frei bestimmt und an die spezi schen Gegebenheiten der Applikation angepasst werden können. Das Prinzip der asynchronen Kommunikation, welches in Kapitel 3 näher vorgestellt wird, ist ein Konzept, das entwickelt wurde um den starren Charakter des Request Cycle Prinzips aufzubrechen und damit diese kla en- de Lücke zwischen der Usability von Webanwendungen und Standard-Applikationen zu schlieÿen.

2.4 Überblick über aktuelle Web-Technologien

Im Zuge der immer weiter wachsenden Bedeutung von Webanwendungen haben sich in den vergangenen Jahren verschiedene Technologien und Ansätze zur Entwicklung und Umsetzung von Applikationen auf der Plattform Internet etabliert. Jede dieser Techno- logien trägt naturgemäÿ diverse Vor- aber auch Nachteile in sich, daher ist es bei der Implementierung einer Webanwendung von groÿer Bedeutung, die Anforderungen genau zu analysieren, um anschlieÿend die passendste Entwicklungs- sowie Laufzeitumgebung und Programmiersprache für das anvisierte Projekt zu wählen. Das folgende Kapitel soll einen kurzen Überblick über aktuelle Technologien in der Sektion der Webanwendungen verscha en.

In erster Linie, und darin unterscheiden sich Webanwendungen in keinster Weise von Standard Desktop-Applikationen, wird zur Implementierung der de nierten Ziele eine geeignete Programmiersprache gewählt. Bei Webanwendungen ist dabei zu beachten, dass jede Implementierungssprache dabei in ein Framework bzw. eine Umgebung einge- bettet ist beziehungsweise sein muss, um die Erreichbarkeit über die Plattform Internet trotz verschiedenster Ressourcen und Clients zu gewährleisten. Manche zur Umsetzung von Webanwendungen etablierte Sprachen (wie z.B. Java) existieren eingebettet in ver- schiedene Frameworks, welche wiederum eigene Stärken und Schwächen aufweisen. Die Komplexität eines Frameworks für Webanwendungen reicht dabei von einem simplen Webserver bis hin zu Applikationsservern zur Synchronisation und Integration verschie- denster Anwendungen. Die Kommunikationsprotokolle innerhalb von Webanwendungen sind fest vorgegeben und standardisiert, die Einhaltung und Abwicklung dieser Protokolle bei der Kommunikation zwischen Client und Server wird dabei vom Webserver in Zusam- menarbeit mit dem Framework übernommen, und muss daher nicht extra implementiert werden. Entwickler einer Webanwendung konzentrieren sich darauf, die Anwendungslo- gik innerhalb der von Internet-Standards gegebenen Architektur umzusetzen sowie die Benutzerschnittstelle im Rahmen der Möglichkeiten, die ein Browser vorgibt, so komfor- tabel und zugänglich wie möglich zu gestalten.

Folgende Ansätze haben in den letzten Jahren (nach aufsteigender Aktualität) eine Rolle in der Entwicklung von Webanwendungen gespielt:

- CGI/Perl

Das Common Gateway Interface (CGI) ist die Basis aller Technologien für We- banwendungen, erst durch die Einführung der CGI-Technologie für Webserver im Jahr 1993 wurden grundlegende Funktionalitäten (wie z.B. Datenbankanbindung) zur Umsetzung von Webanwendungen ermöglicht. Waren bis dahin Webserver auf Darstellung statischer HTML-Seiten beschränkt, ermöglichte die CGI-Technologie erstmals den Aufruf eines externen Programms zur Verarbeitung von Daten durch einen Webserver. Die beliebteste Programmiersprache zur Umsetzung der dynami- schen Verarbeitung der Daten und anschlieÿender Ausgabe des Resultats in HTML war und ist Perl, auch wenn ein Hauptziel von CGI die Unabhängigkeit von ei- ner bestimmten Programmiersprache ist. Mit wachsender Komplexität der Weban- wendungen hat CGI in Verbindung mit Perl an Attraktivität verloren, modernere Frameworks nutzen zwar weiterhin die CGI-Basis-Funktionalitäten innerhalb von Webservern, bieten jedoch durch objektorientierte sowie mehrschichtige Architek- turen eine weit bessere Skalierbarkeit bezüglich Gröÿe und Komplexität einer We- banwendung.

- ColdFusion

Der ColdFusion Application Server war bei seinem Erscheinen 1995 der erste Ap- plikationsserver überhaupt und ist bis heute einer der erfolgreichsten weltweit. Die Logik einer Anwendung wird bei ColdFusion über eine eigene tag-basierte Sprache CFML (ColdFusion Markup Language) implementiert, wodurch die Entwicklung von Webanwendungen mit ColdFusion die wohl geringste Lernkurve aller aktuellen Webtechnologien aufweist.

2001 wurde das ColdFusion-Framework völlig neu implementiert und die zugrun- deliegende Engine auf J2EE umgestellt, wodurch Anwendungen nicht mehr zwin- gend auf den eigenen Application Server angewiesen sind, sondern in jeder Java- Webumgebung (Websphere, SunOne, Tomcat) lau ähig bleiben. Aufgrund der einfachen, weil HTML ähnlichen Syntax existiert eine groÿe Gemein- de von ColdFusion-Anhängern unter Web-Entwicklern. Die Grenzen der Sprache wurden durch die Umstellung auf J2EE-Basis aufgebrochen, was ColdFusion durch Java-Integration auch für mittlere bis groÿe Projekte zumindest zu einer überle- genswerten Alternative macht. Denkbar ist dabei die Entwicklung von einfachen Komponenten eines Systems in CFML bei gleichzeitig sauber gekapselter und nach objektorientierten Grundprinzipien implementierter Kernlogik der Anwendung.

- ASP

Active Server Pages (ASP) ist eine von Microsoft entwickelte Erweiterung für Webserver, die mit Einsatz einer Skriptsprache wie VBScript oder JScript dyna- misch Webseiten erzeugt. Bei der Verö entlichung 1996 wurde ASP nur vom Micro- soft Internet Information Server (IIS) interpretiert, mittlerweile existieren jedoch Portierungen auf andere Webserver (wie z.B. Apache). Dennoch ist die Betriebssys- temgebundenheit von ASP der Hauptgrund für eine mangelnde Akzeptanz unter Entwicklern von Webanwendungen, trotz diverser Vorteile wie leichte Erlernbarkeit. Folgerichtig wird ASP heute von Microsoft nicht mehr weiterentwickelt, die o zi- elle Nachfolgetechnologie ASP.NET wurde mit dem Release des .NET Framework 2002 vorgestellt.

- PHP

PHP steht als rekursives Akronym für Hypertext Preprocessor. Der Ansatz erschien in der ersten stabilen Version 1997 und wird seither fortlaufend unter Open Source Lizenz weiterentwickelt. PHP selbst ist eine serverseitig interpretierte Sprache und zeichnet sich positiv durch breite Datenbankunterstützung, Betriebssystemunab- hängigkeit, leichte Erlernbarkeit sowie ein groÿes Portfolio an erhältlichen Funkti- onsbibliotheken aus.

Nachteilig wirkt sich bei groÿen Projekten der Aufbau von PHP als prozedurale Sprache aus. Objektorientierte Aspekte wie Kapselung von Daten beziehungsweise ganzer Komponenten oder saubere Fehlerbehandlung durch Exceptions sind Aspekte, die andere Ansätze (wie beispielsweise Java) für den Einsatz in groÿen Projekten sinnvoller erscheinen lassen. Der PHP-Kern wird jedoch stetig um objektorientierte Konzepte weiterentwickelt, und gerade in kleinen bis mittleren Projekten erfreut sich PHP groÿer Beliebtheit unter Web-Entwicklern.

- Java/J2EE

Die objektorientierte Programmiersprache Java wurde seit der ersten Verö entli- chung 1996 stetig an die Entwicklung des Internets angepasst. Während der groÿe Durchbruch im Umfeld der kommerziellen Desktopanwendungen kaum erfolgt ist, so ist in Web-Umgebungen Java spätestens seit der Einführung der dreischichtigen Web-Architektur mit JSP und Servlets eine der erfolgreichsten Programmierspra- chen. Die verschiedenen Technologien, die Java für das Internet anbietet, sollen hier im Einzelnen vorgestellt werden:

Applets

Im Allgemeinen Sinne bezeichnet ein Applet eine Softwarekomponente, wel- che nicht alleine lau ähig ist, sondern im Kontext eines anderen Programms ausgeführt wird. Im konkreten Fall der Java Applets bedeutet das die Aus- führung von Java-Code innerhalb eines Web Browser, welcher ein Plugin und damit einen Container für die Applet-Technologie zur Verfügung stellen muss.

Da Applets Programme sind, welche über das Web geladen und anschlieÿend auf dem Rechner des Anwenders lokal ausgeführt werden, werden Java Ap- plets im Browser in einer abgeschotteten Laufzeitumgebung ( Sandbox ) mit strengen Sicherheitsrichtlinien gestartet, um Schaden durch böswillige Ap- plets zu vermeiden. Abgesehen von diesen Sicherheitseinschränkungen (wie beispielsweise Zugri auf lokale Dateien) können alle Java Bibliotheken und Funktionalitäten bei der Programmierung von Applets verwendet werden, was diese Technologie in der Theorie sehr mächtig macht, da die Gestaltung von Benutzerschnittstellen nicht mehr den Richtlinien von HTML und dem HTTP- Kommunikationsprotokoll unterliegt.

Diese Freiheit in der Interface- und Kommunikationsgestaltung einer Webanwendung deckt sich weitestgehend mit der Thematik dieser Diplomarbeit, verfolgt jedoch einen anderen Ansatz zur Erreichung dieses Ziels: Während asynchrone Kommunikation, wie sie in dieser Arbeit vorgestellt wird, auf Standards beruht, die in jedem aktuellen Browser implementiert sind, benötigt ein Java Applet eine spezielle Laufzeitumgebung.

An ebendiesem Punkt ist die Applet-Technologie weitestgehend gescheitert. So benutzte der weitverbreiteste Web Browser der 90er Jahre, der Internet Explo- rer von Microsoft als Laufzeitumgebung Microsoft's hauseigene Java Virtual Machine, welche in vielen Punkten inkompatibel zur Java Virtual Machine von Sun ist. Bedingt durch diese Kompatibilitätsprobleme wird bei Applet- gestützten Applikationen ein Grundprinzip von Webanwendungen, die globale Verfügbarkeit aus unterschiedlichsten technischen Infrastrukturen, in einem Groÿteil der Fälle verletzt. Ein weiterer negativer Aspekt ist der Performanz- verlust, welcher durch das Nachladen der Laufzeitumgebung und des Applet- Codes in vielen Fällen entsteht.

Servlets, JSP

Mit der Einführung von Servlets in Verbindung mit JSP (Java Server Pages) wurde das Model-View-Controller Pattern, welches eine strikte Trennung von Darstellung, Logik und Daten einer Applikation vorschreibt, in das Umfeld von Webanwendungen übernommen. Während andere Konzepte zur Erzeu- gung dynamischer Web-Inhalte (CGI, PHP, ASP etc.) Logik und Präsentati- on gar nicht oder nur kaum trennen, übernimmt in diesem Ansatz das Servlet die Rolle des Controllers und delegiert eine Anfrage an eine entsprechende JSP-Datei, welche die Darstellung übernimmt. Die Anwendungsdaten werden durch Daten-Objekte, so genannte Java Beans repräsentiert. Eine Java Be- an ist eine in Java geschriebene Softwarekomponente, welche eine Container- Funktion in der Übertragung von Daten übernimmt. Um diese Rolle angemes- sen auszufüllen realisiert eine Java Bean eine verbesserte Serialisierung und damit Netzwerkfähigkeit, Wiederverwendbarkeit, Portabilität sowie Interope- rabilität. Für den Zugri auf die Eigenschaften eines Daten-Objekts de niert eine Java Bean spezielle Zugri soperationen, welche auf einer in der Weban- wendung instanziierten Bean ausgeführt werden können.

Die JSP- und Servlettechnologie benötigt eine eigene Laufzeitumgebung, einen so genannten Servlet Container, welcher entweder neben dem Webserver laufen oder direkt in diesen integriert sein kann. Die bekannteste und weitverbreiteste Implementierung eines solchen Containers ist wohl das Jakarta Tomcat Pro- jekt, ein Open Source Web Container für Servlets und JSP's. Durch die Trennung von Logik, Präsentation und Daten einer Anwendung skaliert das Servlet-/JSP Konzept weit besser bezüglich der Anwendungskom- plexität als die bisher vorgestellten Skriptsprachen-basierten Ansätze wie PHP oder ASP. Der Ansatz wurde geschlossen in das J2EE-Konzept integriert, wo JSP's und Servlets jedoch eine leicht veränderte Rolle einnehmen.

J2EE

Im Jahr 2000 wurde die Java 2 Plattform, Enterprise Edition (J2EE) vorge- stellt. In der aktuellen Version 5.0 wurde der Name auf Java Enterprise Edition (JEE) vereinfacht. Das in dieser Spezi kation de nierte Konzept beschreibt einen allgemeinen Rahmen, auf dessen Basis aus modularen Komponenten be- stehende verteilte und mehrschichtige Anwendungen entwickelt werden kön- nen. Klar de nierte Schnittstellen zwischen den Komponenten und Schichten sollen dafür sorgen, dass Softwarekomponenten unterschiedlicher Hersteller interoperabel sind, sofern sie sich an die Spezi kation halten, und dass die verteilte Anwendung gut skalierbar ist.

JEE-Komponenten erfordern als Laufzeitumgebung eine spezielle Infrastruktur, einen so genannten Application Server. Dieser Server stellt technische Funktionalitäten wie

- Sicherheit

-Transaktionsmanagement

-Namens- und Verzeichnisdienste

- Kommunikation zwischen JEE-Komponenten

- Management der Komponenten über den gesamten Lebenszyklus (inklu- sive Instanziierung)

-Unterstützung für die Installation (Deployment)

zur Verfügung. Des Weiteren kapselt der Server den Zugri auf die Ressourcen des zugrundeliegenden Betriebssystems (Dateisystem, Netzwerk ...). Die JEE-Architektur beschreibt eine Aufteilung einer verteilten Anwendung in mehrere Schichten ( Tier ):

- Client Tier: Clients verschiedener Art (Browser, Mobile Geräte, Desktop- Clients..), welche auf die Anwendung zugreifen können.
-Middle Tier: Ein Server, welcher einen Web Container für Servlets und JSP's, über welche die Präsentation abgehandelt wird, sowie einen EJB (Enterprise Java Beans) Container für die Applikationslogik bereitstellt.
- EIS Tier: Backend der Anwendung, beispielsweise eine Datenbank und/oder eine ERP (Enterprise Resource Planning) Anwendung.

Neben dem schon beschriebenen Konzept von Servlets im Zusammenspiel mit JSP-Dateien, welches in der JEE-Spezi kation die Abwicklung der Präsenta- tion einer Anwendung übernimmt, wird die Applikationslogik über Enterprise Java Beans gesteuert. Diese sind standardisierte Komponenten, welche im Ge- gensatz zu herkömmlichen Java Beans wichtige Konzepte für Unternehmens- anwendungen wie Transaktions-, Namens- oder Sicherheitsdienste, die für die Geschäftslogik einer Anwendung benötigt werden, bereitstellen.

Enterprise Java Beans gibt es in mehreren unterschiedlichen Ausprägungen für verschiedene Klassen von Anwendungsfällen:

- Entity Beans: Modellieren persistente Daten des Systems, z.B. einen Da- tensatz in einer Datenbank.
- Session Beans: Bilden Vorgänge ab, welche der Benutzer mit dem Sys- tem durchführt. Dabei werden zustandslose (können keine Informationen speichern) und zustandsbehaftete (können Informationen über die Dauer einer Session speichern) Session Beans unterschieden.
-Message Driven Beans: Ermöglichen asynchrone Kommunikation zwi- schen EJB-Komponenten und werden häu g für die Kommunikation mit Legacy-Systemen eingesetzt. Nicht zu verwechseln mit der in dieser Arbeit thematisierten asynchronen Kommunikation, da Message Driven Beans nicht zur Kommunikation zwischen Client und Server innerhalb einer Webanwendung eingesetzt werden.
- Webservice Beans: Seit der Spezi kation 1.4 können Enterprise Java Be- ans auch als Web Services aufgerufen werden. Somit kann die Schnittstelle eines Web Service auf die Schnittstelle einer Enterprise Java Bean abge- bildet werden.

Mittlerweile existieren mehrere Implementierungen von Application Servern, welche die JEE-Spezi kation komplett oder zum gröÿten Teil vollständig umsetzen, sowohl kommerzielle und damit lizenzkostenp ichtige Systeme(BE Weblogic, Websphere) als auch open source Lösungen (Jboss) sind für das Deployment von JEE-Applikationen verfügbar.

Die JEE-Spezi kation beschreibt einen extrem breit gefächerten Ansatz für Webanwendungen, der dazu noch beliebig erweitert werden kann. Entspre- chend komplex und langwierig gestaltet sich auch die Einlernphase für Ent- wickler, sehr solide Java-Kenntnisse sind dabei nur eine Grundvoraussetzung, um das Zusammenspiel der Komponenten in der JEE-Spezi kation richtig und zum eigenen Vorteil umzusetzen. Dafür skalieren Anwendungen, die dem JEE-Konzept folgen, in Komplexität sowie Anzahl der Benutzer beinahe be- liebig. Neue Software-Komponenten lassen sich durch die strenge Kapselung einfach in bestehende Anwendungen integrieren und bestehende Komponenten können leicht ausgetauscht werden. Ebenso lassen sich auf Server-Ebene bei Überlastung eines Application Servers weitere Server hinzufügen, um die Last entsprechend aufzuteilen. Diese Punkte sowie der Faktor der langen Einarbei- tungszeit machen das JEE-Konzept insbesondere für groÿe, komplexe Projek- te relevant, die Spezi kation ist zwar sehr exibel und lässt dem Entwickler auch den Freiraum für eine schlanke Lösung mit JEE, dennoch ziehen viele Entwickler für kleinere bis mittlere Projekte einen der vorher vorgestellten, einfacheren Ansätze vor.

- ASP.NET

ASP.NET trat mit dem Release 2002 die Nachfolge von ASP an und stellt eine von Microsoft entwickelte serverseitige Technologie für Webanwendungen auf Basis von Microsoft's .NET-Framework dar. Mit dem ursprünglichen ASP-Konzept hat dieser Ansatz auÿer der Namensgebung nichts mehr zu tun, die gravierendsten Unterschiede sind dabei:

-ASP.NET-Anwendungen werden kompiliert und nicht zeilenweise interpre- tiert, was einen gehörigen Sprung bezüglich der Performance ermöglicht.
-Anwendungen sind nicht auf eine Sprache beschränkt, es können mehrere vom .NET-Framework unterstütze Sprachen wie z.B. C#, VB.NET oder J# ein- gesetzt werden.

Trotz diverser unbestreitbar positiver Aspekte wie die erwähnte Sprachunabhän- gigkeit, Trennung von Präsentation und Logik oder starker Unterstützung durch eine gra sche Entwicklungsumgebung (Microsoft Visual Studio .NET) bleibt das altbekannte Problem der Betriebssystemgebundenheit. Diese Tatsache macht den ASP.NET-Ansatz lediglich für stark kommerziell orientierte Projekte mit vorge- schriebener Windows-Umgebung interessant. Entwickler, die dagegen Wert auf of- fene Standards und Plattformunabhängigkeit legen, ziehen in der Regel einen Be- triebssystemunabhängigen Ansatz vor.

- Ruby/Ruby on Rails

Ruby ist eine objektorientierte, interpretierte Sprache und hat ihre Wurzeln in Perl, Smalltalk, Python und LISP. Die Sprache wurde 1995 in Japan vorgestellt und blieb lange Zeit wegen unzureichender englischer Dokumentation in ihrer Verbrei- tung auf Japan beschränkt, erfreut sich dort allerdings gröÿter Beliebtheit. Seit der Jahrtausendwende bemühen sich die Entwickler von Ruby auch um eine Verbrei- tung auÿerhalb Japans, und insbesondere auf dem Sektor von Webanwendungen erfreuen sich in Ruby implementierte Webframeworks in den letzten Jahren stei- gender Beliebtheit auch auÿerhalb Japans.

Die erfolgreichste in Ruby entwickelte Umgebung für Webanwendungen trägt die Bezeichnung Ruby on Rails (Kurzform: Rails) und wurde 2004 erstmals vorgestellt. Rails folgt in seinem Grundkonzept streng dem Model-View-Controller Prinzip und besteht aus den folgenden Komponenten:

Active Record: Ein in das Framework integrierter objektrelationaler Mapper, welcher es ermöglicht, auf Datenbankeinträgen wie auf Objekten zu arbeiten.
Action Pack: Erledigung von Request-Behandlung und Response-Ausgabe. Anfragen werden von einer ö entlichen Methode eines Controllers angenom- men, verarbeitet und an ein Template zur Anzeige der Ausgabe delegiert.
Action Mailer: Komponente für den Empfang/Versand von Emails.
Action Web Service: Unterstützung von Web Service-Programmierung auf Basis von SOAP und XML-RPC.
Active Support: Ruby-Erweiterungen von Rails.

Rails versteht sich als Gegenstück zu schwergewichtigen Webframeworks und ver- meidet an allen möglichen Punkten eine aufwändige Kon guration der Webserver- Umgebung. Die im Framework integrierte Trennung zwischen Daten, Logik und Präsentation erzwingt quasi eine Kapselung der Programmkomponenten und bie- tet damit auch eine einfache Erweiterbarkeit einer Anwendung um neue Funktio- nalitäten. Trotz der relativ unbekannten Ruby-Syntax steigt die Beliebtheit von Rails als Webframework stetig an, sicher auch bedingt durch die integrierte Unter- stützung und im Vergleich zu JEE einfacheren Integration neuester Entwicklungen wie Web Services und auch asynchroner Kommunikation (siehe Thomas und Hans- son (2005)). Die Skalierbarkeit bezüglich aufwändiger und komplexer Projekte lässt sich zum derzeitigen Zeitpunkt leider schwer einschätzen, da der Ansatz sehr jung ist und daher wenig Erfahrungsberichte existieren. Rails wird jedoch als Vorreiter bezüglich Web 2.0-Anwendungen (siehe folgendes Kapitel) gesehen, so dass mit ei- ner verstärkten Anzahl von in Rails entwickelten Anwendungen in naher Zukunft gerechnet werden kann.

3 Asynchrone Webanwendungen

3.1 Das Web 2.0

Der Begri Web 2.0 wurde von Dale Dougherty von der Firma O'Reilly Media ins Leben gerufen und hat sich in der letzten Zeit als Synonym für eine starke Veränderung der Sichtweise des World Wide Webs etabliert. In der Anfangszeit war das Internet eine Ansammlung statischer und miteinander verlinkter Informationsquellen, seit Mitte/Ende der neunziger Jahre nimmt die Entwicklung dynamischer Internet-Seiten jedoch zu. Technologien für dynamischen Web-Content existieren mittlerweile in groÿer Anzahl und haben sich auch auf breiter Ebene durchgesetzt (vgl. Kapitel 2.4).

Die Idee von Web 2.0 beschreibt keine spezi sche Technologie, sondern vielmehr einen Perspektivenwechsel im Verständnis des World Wide Web: Anstelle einer passiven Infor- mationsquelle wird das WWW als vollwertige Plattform für benutzerde nierte Dienste und Anwendungen gesehen. Starke Verfechter dieses Gedankens sehen sogar eine voll- ständige Ersetzung von Desktop-Anwendungen durch Webapplikationen in den meisten Anwendungsbereichen. Der hohe Abstraktionsgrad und die Neuartigkeit des Begri s Web

2.0 hat zur Folge, dass bisher noch keine allgemein gültige De nition oder Standardisie- rung existiert, daher wird hier eine Quintessenz der Vielzahl der laufenden Diskussionen und Einordnungsversuchen, wie sie in (Wikipedia Web2.0 De nition), (MacManus und Porter, 2005), (Kunze, 2005) und (O'Reilly, 2000) aufgeführt sind, vorgenommen. Die Anforderungen an eine Web 2.0-Applikation lassen sich grob in drei Sichten einteilen:

- Technische Sicht

Die Nutzung der Daten einer Webanwendung soll nicht auf diese selbst beschränkt sein, stattdessen ist Zugang zu Applikationsdaten aus verschiedensten Kontexten zu ermöglichen, sei dies ein anderer Webdienst oder gar eine Desktop-Applikation. Um sowohl dies als auch den Zugang zu Fremddaten (Stichwort: Content Syndication und Aggregation) zu gewährleisten, sollen zur Beschreibung der Daten o ene Standards wie XML (oder Ableger davon) verwendet und die Datenbestände über einen Web Service zugänglich gemacht werden.

Die Benutzerschnittstelle von Web 2.0-Anwendungen soll dem Qualitätsniveau von Desktop-Applikationen angeglichen werden und den Benutzer bei der Suche und Nutzung von Inhalten e zient unterstützen. Auf lange Sicht sollen Anwendungen, die bisher rein auf Desktop-Ebene verfügbar waren (wie z.B. O ce-Pakete) auf der Plattform Web realisiert werden. Ein wichtiger Aspekt dabei ist die Loslösung vom seitenorientierten Kommunikations- und Darstellungsprinzip, ein Ansatz, welcher dies möglich macht (AJAX-Technologie) wird als zentrales Thema dieser Arbeit im folgenden Kapitel im Detail vorgestellt.

- Soziale Sicht

Die Tatsache, dass Webanwendungen eigene Daten zugänglich machen und auf Da- ten von Fremd-Applikationen zugreifen können, bewirkt einen höheren Grad der Verwebung der im Web enthaltenen Informationen. Verschiedene Ansätze, die- se Informationsmasse zu strukturieren, werden im Web 2.0-Umfeld erwähnt, ein Aspekt, der dem Gedanken des Semantischen Webs sehr nahekommt. Vorreiter in diesem Bereich ist der Internetdienst Flickr (www. ickr.com ) , welcher es dem Be- nutzer erlaubt Web Content mit eigenen Meta-Tags zu versehen, und so der Vision von strukturiertem Web Content über den Community-Gedanken näherkommen will. Fest verankert im Web 2.0-Gedanken ist die aktive Teilnahme des Benutzers an Content-Erstellung und -Strukturierung, die Konzepte von Wikis und Bloggern sind fester Bestandteil einer Web 2.0-Seite.

- Geschäftliche Sicht

Der gröÿte Gewinn aus der Business-Perspektive ist die Tatsache, dass das Konzept der Web Services im Web 2.0-Ansatz fest verankert ist. Dadurch werden Inhalte von Web-Diensten nicht nur für Menschen, sondern auch für Maschinen nutz- und verwertbar, was die Möglichkeit der freien Nutzung beziehungsweise Weiterver- arbeitung der Anwendungsdaten aufbietet. Die Forderung zur Bereitstellung von Content in o enen Standard-Formaten (XML) soll dabei eine gröÿtmögliche Kom- patibilität und Interoperabilität gewährleisten. Diese Tatsache ermöglicht die Kom- bination von mehreren Webdiensten zu völlig neuen, übergeordneten Applikationen und Diensten.

Zur Umsetzung der eben genannten Aspekte nutzt eine Web 2.0-Anwendung (auf einem feinen Abstraktionsgrad betrachtet) einige oder alle der folgenden Techniken:

- CSS und semantisch gültiges XHTML Markup
-Verbesserung der Funktionalität auf Client-Seite, insbesondere durch asynchrone Kommunikation
-Nutzungsmöglichkeit von Anwendungsdaten durch Repräsentation dieser in XML oder XML-Ablegern (RSS,ATOM)
-XML Webservice API's
-Saubere und aussagekräftige URL's
-Möglichkeit der Kommunikation über einen Weblog

3.2 Unterschiede zu herkömmlichen Webanwendungen

In Kapitel 2.2 wurden die typischen Charakteristika von Webanwendungen bereits vor- gestellt. Diese sind natürlich auf Basis des traditionellen Kommunikationsprinzips aufge- baut, asynchrone Kommunikation bewirkt an bestimmten Aspekten jedoch einen massi- ven Eingri bzw. eine Abschwächung dieser Spezialeigenschaften. Daher an dieser Stelle noch einmal ein Überblick über die betro enen Charakteristika unter dem Aspekt der asynchronen Kommunikation:

- Produktbezogene Charakteristika

Aus Produktsicht hat asynchrone Kommunikation Auswirkungen auf alle drei beschriebenen Eigenschaften (Content, Hypertext und Präsentation):

Content: Der Content-Aspekt beschreibt die Wichtigkeit der Qualität sowie Aktualität der gelieferten Inhalte einer Webanwendung. Dabei variiert der Grad der Relevanz dieses Aspekts mit der Art der Anwendung und erreicht sein Maximum besonders bei transaktional orientierten Systemen. Bei hin- sichtlich der Aktualität kritischen Inhalten liefert asynchrone Kommunikation eine einschneidende Verbesserungsmöglichkeit: Betro ene Informationen (wie z.B. die Verfügbarkeit eines Artikels) können asynchron und ohne Au orde- rung durch den Benutzer laufend auf dem aktuellsten Stand gehalten werden, ohne den Benutzer in seiner gewohnten Nutzung der Anwendung zu beein- trächtigen.

Hypertext: Dieser Aspekt beschreibt die Organisation von Inhalten einer We- banwendung als Struktur von verlinkten Informationseinheiten und unterliegt der wohl massivsten Änderung durch asynchrone Kommunikation: Das Prinzip der Seite als Informationseinheit wird ersetzt durch einen weit feingliedrige- ren Ansatz, welcher Informationseinheiten als beliebig kleine Seitenfragmente beschreibt. Dadurch ist es möglich, den Hypertext-Aspekt weitestgehend vor dem Benutzer zu verbergen, da er sich innerhalb einer festen Benutzerschnittstelle ( Single Interface ) durch den Informationsraum bewegt. Dieser Ansatz dürfte die in 2.2.1 beschriebene Problematik der kognitiven Belastung sowie des Orientierungsverlusts eines Benutzers, bedingt durch die Navigation durch eine zu komplexe Hypertext-Struktur, entschärfen.

Präsentation: In diesem Punkt verhalten sich die Vorteile des Einsatzes asynchroner Kommunikation ähnlich wie beim Hypertext-Aspekt. Die Benutzerschnittstelle kann bei gröÿerer Komplexität weit intuitiver gestaltet werden, da sich die Webanwendung ähnlich wie dem Benutzer bekannte DesktopApplikationen verhält. Durch die Entkräftung des Hypertext-Aspekts kann bei der Gestaltung der Benutzerschnittstelle auf Erfahrungen und Richtlinien aus dem Desktop-Bereich zurückgegri en werden.

- Nutzungsbezogene Charakteristika

Aus dieser Sicht ist asynchrone Kommunikation lediglich innerhalb des technischen Kontexts relevant. Das darin beschriebene Qualitätskriterium der Performanz und Antwortzeit ist dahingehend betro en, dass zeitintensive Operationen asynchron durchgeführt werden können, und damit nicht mehr so schwer ins Gewicht fallen, da der Benutzer die Anwendung während der Verarbeitungszeit weiter nutzen kann.

- Entwicklungsbezogene Charakteristika

Diese Sicht auf Webanwendungen ist insbesondere bezüglich der Projektmitarbeiter durch asynchrone Kommunikation betro en. Diese müssen sich gezielt neues Wissen aneignen und alte, über Jahre verwurzelte Entwicklungsrichtlinien und Konzepte (insbesondere hinsichtlich Interfacegestaltung und Navigationsstruktur) müssen an die neuen Gegebenheiten angepasst werden.

3.3 Asynchrone Kommunikation im Web durch AJAX

3.3.1 Konzept und Arbeitsweise

Der Begri AJAX steht für Asynchronous Javascript and XML und wurde durch einen Essay (Garrett, 2005) von Jesse James Garrett von der Agentur Adaptive Path im Fe- bruar 2005 erstmals eingeführt. Mittlerweile hat sich AJAX als Synonym für asynchrone Kommunikation zwischen Client (Browser) und einem Server innerhalb von Webanwen- dungen etabliert und ndet mehr und mehr Beachtung in der Fachwelt. Wie bereits in 3.1. beschrieben, ist eine wichtige Komponente des Web 2.0-Gedankens die Angleichung der Qualität der Benutzerschnittstellen von Web- und Desktop- Applikationen. Das starre, weil synchrone Konzept des Request Cycles (siehe 2.3.) verhindert eine elegante und dynamische Benutzerführung mit herkömmlichen Web- Technologien weitestgehend. Ebendieses Konzept der synchronen Kommunikation wird durch den AJAX-Ansatz durchbrochen: Zwischen dem Browser als Client und dem Ser- ver wird eine so genannte AJAX engine auf Javascript-Ebene als Bindeglied eingeführt, welche den Nachrichtenaustausch sowie die Anzeige der Resultate ohne Leerzeiten auf Client-Seite abwickelt (siehe Abbildung 3).

Betritt ein Benutzer eine Webseite, welche eine AJAX-Anwendung beinhaltet, so wird zu Beginn clientseitig auf Javascript Ebene die AJAX engine geladen und aktiviert, welche ab sofort die Kommunikation des Benutzers mit der Applikation abwickelt. Dies beinhal- tet sowohl rein clientseitige Funktionalität (wie das Überprüfen von Eingaben in einem Textfeld auf o ensichtliche Fehler) als auch jeglicher Nachrichtenaustausch zwischen der Anwendung und einem Server oder Fremddiensten (z.B. einem Web Service). Durch den

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Die Client- und Serverkommunikation im AJAX-Modell

asynchronen Kommunikationsaufruf sowie Datenempfang bleibt es dem Benutzer verborgen, wann genau ein Datenaustausch erfolgt, da er ohne Leerzeiten weiterarbeiten kann (siehe Abbildung 4).

Eine Kommunikation mit einem Server kann dabei, anders als in herkömmlichen An- wendungen, keineswegs nur durch den Klick auf einen Link oder einen Submit -Knopf eines Formulars angeregt werden. Durch die AJAX engine sind weit kontextsensitive- re Auslöser einer Server-Kommunikation möglich, wie beispielsweise das Verlassen eines Eingabefeldes, da im AJAX-Modell bei einer Antwort nicht das gesamte Dokument (was ansonsten Verwirrung beim Benutzer erzeugen würde) sondern nur ein bestimmter Teil der Anwendung aktualisiert werden kann. Tritt ein solcher Auslöser ein, so wird anstelle des Versendens einer HTTP Request (mit anschlieÿendem Warten auf Client-Seite) ein Javascript-Aufruf an die AJAX- Engine durchgeführt, welche die Kommunikation durch diverse Teilschritte regelt:

1. Die AJAX engine liest über das DOM die für die Anfrage notwendigen Daten aus.
2. Mit der Anfrage und deren Parametern wird ein XMLHttpRequest -Objekt initiali- siert und von diesem eine Anfrage an den betre enden Server geschickt.
3. Nach der Verarbeitung schickt der Server die Antwort-Daten in XML-Form an die Anwendung zurück, wo diese vom XMLHttpRequest -Objekt in Empfang genommen werden.
4. Die AJAX engine liest die Antwort-Daten aus und aktualisiert über das DOM die betre enden Dokument-Teile der Webanwendung.

Diese Schritte geschehen für den Benutzer der Anwendung transparent, d.h. er kann während des Versendens der Daten sowie beim Warten auf die Antwort weiter die Anwendung nutzen und sogar neue Abfragen anstoÿen (siehe Abb.4).

Mittlerweile existieren mehrere populäre Webanwendungen, welche die AJAX- Technologie nutzen. Als Vorreiter darf dabei die Suchmaschine Google genannt wer- den, sämtliche Google-Produkte der neuesten Generation wie google suggest, google mail oder google maps nutzen asynchrone Kommunikation zur Verbesserung der Benutzer- führung. Auch der Online-Bilderdienst ickr (www. ickr.com) erntet für sein innovatives Benutzer-Interface auf AJAX-Basis allseits Lob.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Asynchrone Kommunikation ohne Leerzeiten im AJAX-Modell

3.3.2 Beschreibung verwendeter Techniken

Die beschriebene AJAX engine stellt keineswegs eine völlig neuartige Technologie dar (welche erst in die Browser integriert werden müsste), sondern besteht aus einem gezielten Einsatz sowie Kooperation von bereits bekannten und in allen modernen StandardBrowsern enthaltenen Techniken:

- Auf Standards basierende Präsentation durch XHTML und CSS
-Dynamische Anzeige und Benutzerinteraktion durch das Document Object Model (DOM )
-Datenaustausch sowie -Manipulation unter Nutzung von XML sowie XSLT
-Asynchroner Datenempfang durch XMLHttpRequest
- Javascript als Bindeglied aller eingesetzten Technologien

Das Document Object Model (DOM) ist ein Plattform- und Implementierungsunabhän- giger Ansatz, um sowohl dynamischen Zugri als auch Manipulation von Inhalt, Struk- tur und Aussehen von Dokumenten zu gewährleisten (siehe (W3C Document Object Model)) und ist als W3C-Standard in allen gängigen Browsern integriert. Betre enden Dokumentbestandteilen (z.B. einer Tabelle oder einem Eingabefeld in HTML) wird ein eindeutiger Bezeichner vergeben, über welchen anschlieÿend dynamischer Zugri auf das Dokument-Teilstück möglich ist. Innerhalb von AJAX-Applikationen wird das DOM ge- nutzt, um Resultate von Prozeduren oder Server-Anfragen dynamisch in die bestehende HTML-Seite zu integrieren, anstatt für die Anzeige der Ergebnisse eine neue Webseite zu generieren.

Das XMLHttpRequest-Objekt stellt die technische Grundlage für die asynchrone Kommunikation mit Webservern oder -diensten innerhalb von AJAX-Applikationen dar. Eingeführt wurde es von Microsoft mit dem Internet Explorer 5.0, bisher ist es noch nicht standardisiert, doch sowohl Mozilla- als auch Safaribasierte Browser enthalten eigene Im- plementierungen.

Ein grober Kommunikationsablauf über XMLHttpRequest stellt sich folgendermaÿen dar:

- Erzeugen des XMLHttpRequest-Objekts
-Öffnen einer Verbindung zu einem Dienst oder Prozess
-Senden einer Nachricht über die erzeugte Verbindung
- Starten eines EventListeners zur Überprüfung, ob eine Antwort auf die Anfrage erfolgt ist
- Integration der Antwort in die aktuelle Seite über das DOM

Für technisch interessierte Leser folgt nun eine detailliertere Ausführung des Kommuni- kationsablaufs über das XMLHttpRequest-Objekt:

Aufgrund der fehlenden Standardisierung muss bei der Erzeugung des Objekts eine Unterscheidung auf Client-Seite zwischen Internet Explorer (Realisierung als Active X- Objekt) und anderen Browsern (Natives Objekt) vorgenommen werden:

Abbildung in dieser Leseprobe nicht enthalten

Ist das XMLHttpRequest-Objekt einmal erzeugt, kann es einheitlich verwendet werden. Zum Ö nen einer Verbindung wird die open -Methode des Objekts aufgerufen, welche 3 Parameter enthält:

- Der Anfragen-Typ, welcher genutzt werden soll (POST oder GET)
-Das Ziel der Anfrage, zum Beispiel die URL und Port eines Webdienstes
- Ein Boolean-Flag, welches signalisiert ob die Anfrage asynchron (TRUE) oder syn- chron (FALSE) durchgeführt werden soll

Um eine asynchrone Verbindung für GET-Anfragen an den Dienst query.cgi zu ö nen, schreibt man also:

requester.open("GET","/query.cgi",TRUE);

Nun ist die Verbindung bereit, um über die send -Methode Nachrichten zu versenden, als Parameter können optional abfragerelevante Daten mit übergeben werden:

requester.send("name=Bob&email=bob@example.com");

Ist die send -Methode aufgerufen, so dauert es (je nach Performance/Komplexität der An- frage) eine gewisse Zeit bis die angeforderten Daten verfügbar sind. Daher wird nach dem Versand der Abfrage ein EventListener aktiviert, der den Status des XMLHttpRequest- Objekts auf erfolgreichen Erhalt der Daten überprüft:

requester.onreadystatechange = stateHandler();

Dies ruft bei jeder Änderung des Zustands des XMLHttpRequest-Objekts eine Funktion stateHandler auf, welche überprüft ob die Anfrage erfolgreich durchgeführt wurde. Ein XMLHttpRequest-Objekt kann sich in den Zuständen

- 0 - Uninitialized

- 1 - Loading

- 2 - Loaded

- 3 - Interactive

- 4 - Completed

be nden. Für den erfolgreichen Abschluss der Abfrage ist natürlich der Zustand 4 - Com- pleted relevant, daher wird der Abfragezustand bei jeder Änderung auf diesen abgefragt:

Abbildung in dieser Leseprobe nicht enthalten

[...]