Web Engineering für asynchrone Anwendungen

Zahalka, Jan

Web Engineering für asynchrone Anwendungen

Zusammenfassung

Inhaltsangabe:Einleitung:
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 Disziplin Web Engineering systematische und quantifizierbare Ansätze für die Entwicklung qualitativ hochwertiger Webanwendungen ermittelt. Insbesondere auf Modellierungsebene 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 Informationseinheiten (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 Internets propagiert, definiert das Web als vollwertige Anwendungsplattform und beschreibt zwei zentrale zugrundeliegende Konzepte: Zum Einen wird gefordert, dass Webanwendungen 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 Seitengebundenheit sowie den synchronen Charakter der Kommunikation zwischen Client und Server. Dieses statische Prinzip, Request Cycle genannt, beschreibt den traditionellen 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 […]

Leseprobe

Inhaltsverzeichnis

ID 9471

Zahalka, Jan: Web Engineering für asynchrone Anwendungen

Druck Diplomica GmbH, Hamburg, 2006

Zugl.: Ludwig-Maximilian-Universität München, Diplomarbeit, 2006

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2006

Printed in Germany

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 deniert 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 Auorderung 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.

Inhaltsverzeichnis

1 Motivation

2 Webanwendungen

2.1 Denition und Klassizierung . . . . . . . . . . . . . . . . . . . . . . . . .

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Unterschiede zu herkömmlichen Webanwendungen . . . . . . . . . . . . . 16

3.3 Asynchrone Kommunikation im Web durch AJAX . . . . . . . . . . . . . 17

4 UML Web Engineering

4.1 Allgemeines zu Web Engineering . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 UWE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Fallstudie: IT-Atlas

5.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Verteilter Aspekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.3 Nicht-Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 32

6 Analyse

6.1 Use Case Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2 Content Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.3 Datenhaltung regionaler/zentraler Daten . . . . . . . . . . . . . . . . . . . 43

6.4 Modellierung und Einsatz asynchroner Kommunikation . . . . . . . . . . . 48

7 Entwurf

7.1 Navigationsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.2 Präsentationsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.3 Modellierung des Verhaltens . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.4 Entwurf des Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

8 Implementierung

8.1 Einsatz der AJAX-Technologie . . . . . . . . . . . . . . . . . . . . . . . . 70

8.2 Der Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

8.3 Probleme/Hindernisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

9 Test

9.1 Testen asynchroner Anwendungen . . . . . . . . . . . . . . . . . . . . . . 77

9.2 Testen der IT-Atlas Anwendung . . . . . . . . . . . . . . . . . . . . . . . 78

9.3 Testen des Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

10 Der Prototyp

10.1 Das Modul Suchen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

10.2 Das Modul Eintragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

10.3 Das Modul Bearbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10.4 Der Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

11 Fazit/Ausblick

1 Motivation

Das Internet hat sich im Laufe der letzten Jahre nachhaltig von einem reinen Informa-

tionsmedium zu einem Anwendungsmedium entwickelt - Webanwendungen sind mittler-

weile 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 quantizierbare 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

wvEsed e ingineering (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, deniert 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 Be-

nutzerfreundlichkeit 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 oenbaren 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 die-

se 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 Anforderungsspezikation 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 Denition und Klassizierung

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 Denition zutrit (Kappel u. a.,

2004):

oftwreEenwendungD die uf ehnologien und tndrds des orld ide e

gonsortium @QgA eruht und wespezi(she essouren wie snhlte und evtlF uh

hienste ereitstelltD die üer eine fenutzershnittstelle @erowserA verwendet werden

Diese Denition klingt sehr allgemein, inkludiert aber explizit zwei wichtige Aspekte zur

Eingrenzung der denierten Domäne:

Software-Aspekt: Die ausdrückliche Verwendung der Begrie Software und Anwen-

dung impliziert die Fokussierung der Denition auf softwareintensive Systeme, rein stati-

sche Seiten erfüllen zwar die Denitions-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 Denition dar.

Anwendungen, die obiger Denition genügen, existieren in verschiedensten Komplexi-

tätsgraden, weswegen eine Klassizierung 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)

Workow-basiert (z.B. E-Government, Patienten-Workow)

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,

deniert 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.

2.2 Unterschiede zu Standard-Applikationen

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, deniert jedoch nach Meinung des Autors nicht zwingend eine eigenständige

Kategorie von Webapplikationen.

Der Nutzen sowie die Ezienz 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 Deniton 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 Dierenzierung 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äug-

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äugen Ä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

2.2 Unterschiede zu Standard-Applikationen

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äsenta-

tion dem Benutzer zur Verfügung. Diese 3 elementaren Bestandteile beinhalten Eigen-

schaften, die für Webanwendungen im Allgemeinen charakteristisch sind:

Content

Content, also Inhalte einer Webapplikation, kann in verschiedenster medialer

Form vorliegen. Content kann Tabellen, Texte, Graken, 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

2.2 Unterschiede zu Standard-Applikationen

Webs ist eine gewisse Multikulturalität der Benutzer unumgänglich, was beim An-

forderungserwerb die Denition 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 getroen 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 betreende 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 konguriert und bedient werden kann, und einem Webbrowser, dessen

Einstellung und Konguration jedoch dem Benutzer obliegt. Daher ist es vonnöten,

die Webanwendung nicht auf eine mögliche Konguration 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.

2.3 Request Cycle Prinzip

Prozess

Der Entwicklungsprozess von Webanwendungen beinhaltet keine starr vorgegebe-

nen 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 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 Ver-

halten 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

2.4 Überblick über aktuelle Web-Technologien

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 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 spezischen 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 klaen-

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

2.4 Überblick über aktuelle Web-Technologien

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

verschaen.

In erster Linie, und darin unterscheiden sich Webanwendungen in keinster Weise von

Standard Desktop-Applikationen, wird zur Implementierung der denierten 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-

2.4 Überblick über aktuelle Web-Technologien

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 ozi-

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 Aspek-

te, 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.

2.4 Überblick über aktuelle Web-Technologien

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 Weban-

wendung deckt sich weitestgehend mit der Thematik dieser Diplomarbeit, ver-

folgt jedoch einen anderen Ansatz zur Erreichung dieses Ziels: Während asyn-

chrone 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 deniert

eine Java Bean spezielle Zugrisoperationen, 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

2.4 Überblick über aktuelle Web-Technologien

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 Spezikation denierte Konzept beschreibt

einen allgemeinen Rahmen, auf dessen Basis aus modularen Komponenten be-

stehende verteilte und mehrschichtige Anwendungen entwickelt werden kön-

nen. Klar denierte Schnittstellen zwischen den Komponenten und Schichten

sollen dafür sorgen, dass Softwarekomponenten unterschiedlicher Hersteller

interoperabel sind, sofern sie sich an die Spezikation halten, und dass die

verteilte Anwendung gut skalierbar ist.

JEE-Komponenten erfordern als Laufzeitumgebung eine spezielle Infrastruk-

tur, 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-Spezikation 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äug für die Kommunikation mit

2.4 Überblick über aktuelle Web-Technologien

Legacy-Systemen eingesetzt. Nicht zu verwechseln mit der in dieser Ar-

beit thematisierten asynchronen Kommunikation, da Message Driven Be-

ans nicht zur Kommunikation zwischen Client und Server innerhalb einer

Webanwendung eingesetzt werden.

Webservice Beans: Seit der Spezikation 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-Spezikation komplett oder zum gröÿten Teil vollständig um-

setzen, sowohl kommerzielle und damit lizenzkostenpichtige Systeme(BE We-

blogic, Websphere) als auch open source Lösungen (Jboss) sind für das De-

ployment von JEE-Applikationen verfügbar.

Die JEE-Spezikation 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-Spezikation 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 Spezikation 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 grasche 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.

2.4 Überblick über aktuelle Web-Technologien

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 vorge-

stellt. Rails folgt in seinem Grundkonzept streng dem Model-View-Controller Prin-

zip 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 Ba-

sis 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 Konguration 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 Le-

ben 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. Tech-

nologien für dynamischen Web-Content existieren mittlerweile in groÿer Anzahl und ha-

ben sich auch auf breiter Ebene durchgesetzt (vgl. Kapitel 2.4).

Die Idee von Web 2.0 beschreibt keine spezische 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 benutzerdenierte 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 Begris Web

2.0 hat zur Folge, dass bisher noch keine allgemein gültige Denition oder Standardisie-

rung existiert, daher wird hier eine Quintessenz der Vielzahl der laufenden Diskussionen

und Einordnungsversuchen, wie sie in (Wikipedia Web2.0 Denition), (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 Syndica-

tion und Aggregation) zu gewährleisten, sollen zur Beschreibung der Daten oene

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 ezient unterstützen. Auf lange Sicht sollen Anwendungen,

die bisher rein auf Desktop-Ebene verfügbar waren (wie z.B. Oce-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 (wwwF)ikrFom) , 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

3.2 Unterschiede zu herkömmlichen Webanwendungen

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 oenen 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 betroenen Charakteristika unter dem Aspekt der

asynchronen Kommunikation:

Produktbezogene Charakteristika

Aus Produktsicht hat asynchrone Kommunikation Auswirkungen auf alle drei be-

schriebenen 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: Betroene Informationen (wie

z.B. die Verfügbarkeit eines Artikels) können asynchron und ohne Auorde-

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

3.3 Asynchrone Kommunikation im Web durch AJAX

beschreibt. Dadurch ist es möglich, den Hypertext-Aspekt weitestgehend vor

dem Benutzer zu verbergen, da er sich innerhalb einer festen Benutzerschnitt-

stelle (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 asyn-

chroner Kommunikation ähnlich wie beim Hypertext-Aspekt. Die Benutzer-

schnittstelle kann bei gröÿerer Komplexität weit intuitiver gestaltet werden,

da sich die Webanwendung ähnlich wie dem Benutzer bekannte Desktop-

Applikationen verhält. Durch die Entkräftung des Hypertext-Aspekts kann

bei der Gestaltung der Benutzerschnittstelle auf Erfahrungen und Richtlinien

aus dem Desktop-Bereich zurückgegrien 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 betroen, 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 betroen. 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 oensichtliche Fehler) als auch jeglicher Nachrichtenaustausch zwischen der

Anwendung und einem Server oder Fremddiensten (z.B. einem Web Service). Durch den

3.3 Asynchrone Kommunikation im Web durch AJAX

Abbildung 3:

Die Client- und Serverkommunikation im AJAX-Modell

asynchronen Kommunikationsaufruf sowie Datenempfang bleibt es dem Benutzer verbor-

gen, 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 hyw die für die Anfrage notwendigen Daten aus.

2. Mit der Anfrage und deren Parametern wird ein wvrttpequest-Objekt initiali-

siert und von diesem eine Anfrage an den betreenden Server geschickt.

3. Nach der Verarbeitung schickt der Server die Antwort-Daten in XML-Form an die

Anwendung zurück, wo diese vom wvrttpequest-Objekt in Empfang genommen

werden.

4. Die AJAX engine liest die Antwort-Daten aus und aktualisiert über das hyw die

betreenden Dokument-Teile der Webanwendung.

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2006
ISBN (eBook): 9783832494711
ISBN (Paperback): 9783838694719
DOI: 10.3239/9783832494711
Dateigröße: 5.5 MB
Sprache: Deutsch
Institution / Hochschule: Ludwig-Maximilians-Universität München – Fakultät für Mathematik, Informatik und Statistik, Informatik
Erscheinungsdatum: 2006 (März)
Note: 1,0
Schlagworte: ajax web2 webentwicklung ruby rails

Autor

Jan Zahalka (Autor:in)

Web Engineering für asynchrone Anwendungen

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Jan Zahalka (Autor:in)