State-of-the-Art-Softwareentwicklung
history repeating
von Tim Bautz
Immer wieder entpuppen sich aktuelle Trends in der Softwareentwicklung bei genauerer Betrachtung als Variationen längst bekannter Themen. Dies gilt auch für den derzeitigen Top-Trend bei Software, der ganz klar in Richtung serverbasierter Applikationen geht – und zwar sowohl bei Anwendungen für Endkunden als auch bei Geschäftssoftware.
Die Hauptargumente der Anhänger serverbasierter Anwendungen sind stets die Gleichen: die zentrale Wartung und Datenhaltung. Schließlich erfolgt der Rollout einer neuen Software durch die Veröffentlichung auf den Server-Systemen. Zur Nutzung der Anwendung genügt ein Browser, die Installation auf jedem einzelnen Rechner erübrigt sich. Die Anwendung wird so auf einfachste Weise plattformübergreifend verfügbar. Das auf den Client-Rechnern laufende Betriebssystem wird damit zunehmend bedeutungslos.
Die Bedienung einer „klassischen“ Webapplikation läuft stets gleich ab: Ein Server stellt eine HTML-Seite zusammen. Die wird in den Browser geladen und dort dargestellt. Jede Benutzeraktion löst eine neue Anfrage an den Server aus, der daraufhin, anhand der in der Anwendungslogik fixierten Kriterien, eine neue Seite erstellt. Diese wird wiederum in den Browser des Benutzers geladen und durch diesen dargestellt. Klingt doch irgendwie bekannt!
Begeben wir uns also auf eine kleine Zeitreise:
Das noch heute beispielsweise an Flughäfen im Einsatz befindliche IBM 360 Mainframe System verfügt über eine Benutzerschnittstelle namens CICS. CICS besteht aus einem 80 * 24 Zeichen großen Bildschirm – selbstverständlich im Textmodus. Sendet der Mainframe ein Formular an ein „Smart Terminal“, so wird dies dort interpretiert und dargestellt. Sobald ein Benutzer seine Eingaben mittels der Taste „Send“ an den Mainframe zurückschickt, berechnet der Mainframe ein neues Formular und sendet dies an das Terminal zurück – und immer so weiter. Die „modernen“ webbasierten Applikationen in ihrer klassischen Form sind das exakte Äquivalent zu CICS, lediglich angereichert mit Fonts und Bildern. Bei den klassischen Anwendungen wurde der nächste Evolutionsschritt durch die zunehmende Verbreitung von PCs und Workstations ausgelöst: Die Anwendungen wurden interaktiv. Die Programme waren nämlich in der Lage, unmittelbar auf Benutzereingaben zu reagieren. Anwendungen wie Textverarbeitung, Tabellenkalkulation oder grafische Benutzeroberflächen wären mit dem Mainframe Anwendungsmodell schlichtweg undenkbar.
Doch der nächste Evolutionssprung steht schon bevor. Schließlich werden klassische Webapplikationen bereits heute zunehmend als „legacy“, teilweise sogar als altbacken betrachtet. Von modernen Webanwendungen werden Eigenschaften erwartet, die auf dem Desktop schon lange selbstverständlich sind: Interaktivität, Reaktivität und ein „schnelles“ Benutzer-Interface. Populäre Vertreter dieser neuen Anwendungsgeneration sind beispielsweise Gmail, Flickr, Google Maps oder iGoogle. Aber auch viele Web-2.0-Plattformen wie beispielsweise Xing und Facebook gehören zu diesen Anwendungen.
Asynchrones JavaScript und XML
Zumindest aus Sicht des Benutzers wird mithilfe von AJAX das Anwendungsmodell „Server sendet Seite – Browser fordert neue Seite an“ durchbrochen. Ein Stück JavaScript, das im Hintergrund eine XMLbasierte Anfrage an den Server stellt, ermöglicht dies. Der Server sendet ein kleines Stück XML als Antwort, daraufhin baut das JavaScript einen Teil der Antwort dynamisch in die dargestellte Website ein. Ein ordentliches Stück der Anwendungslogik wird so in das vom Browser ausgeführte JavaScript ausgelagert. Das Ergebnis für den Benutzer, den diese technischen Details nicht interessieren: Eine AJAXApplikation „fühlt“ sich schneller und reaktiver an als eine klassische Webanwendung.
Dass dabei das gleiche Request/Response- Ablaufschema „unter der Haube steckt“ wie bei einer klassischen Website, sei nur als Detail am Rande erwähnt.
Portabilität oder die Spezialitäten der Plattformen
Bei der Entwicklung von AJAX-Anwendungen ergibt sich jedoch ein Kernproblem: die zahlreichen Spezialitäten der verschiedenen Browser. Handgeschriebenes JavaScript, das die Eigenarten verschiedener Browser berücksichtigt, ist enorm arbeits- und zeitintensiv.
Aufgrund der browserspezifischen Eigenarten ist es also notwendig, Anwendungen intensiv für Firefox, Internet Explorer 6, Internet Explorer 7, Internet Explorer 8, Safari und Opera zu testen. Damit ist die Effizienz dieses Entwicklungsansatzes zumindest als fragwürdig zu bewerten.
Doch auch hier lohnt ein kleiner Blick in die Geschichte! 1978 wurde an den Bell Labs die Programmiersprache C entwickelt. Die Zielsetzung: Eine portable und effiziente Programmierumgebung sollte entstehen, die den Entwickler von den Spezialitäten der Rechnersysteme und Architekturen entkoppelt. Die Arbeit der Anpassung an die Zielplattform wurde einfach an den Compiler delegiert – konsistent und beweisbar korrekt.
Geht man also davon aus, dass sich die Geschichte wiederholt, dann wird es zu einer ähnlichen Entwicklung wie 1978 kommen. Es wird ein SDK (Software Development Kit) geben, das aus einer höheren Sprache nativen Code erzeugt – in diesem Falle JavaScript und DOM. Dieser Code wird für jede Plattform separat erzeugt. Das SDK generiert automatisch performanten und für die Zielplattform angepassten Code. Händisch durchgeführte Optimierungen seitens des Entwicklers sind nicht mehr notwendig.
Das Google-Web-Toolkit
Ein solches SDK in vollem Funktionsumfang existiert derzeit noch nicht. Es gibt jedoch bereits einige vielversprechende Ansätze in dieser Richtung. Das Google- Web-Toolkit (GWT) ist hierbei bislang am ausgereiftesten. Das GWT bietet die meisten Features und wird von einer großen Anzahl von Entwicklern akzeptiert.
Das auf den Client-Rechnern laufende Betriebssystem wird zunehmend bedeutungslos.
Beim Google-Web-Toolkit werden die Applikationen nativ in Java entwickelt. Hierzu wird der sogenannte Hosted Mode bereitgestellt. Im Hosted Mode kann die zu entwickelnde Webanwendung wie eine Java-Anwendung debuggt und kompiliert werden. Dazu beinhaltet das GWT speziell angepasste Versionen von Firefox und Tomcat. Sie fungieren als Browser bzw. Webserver/ Servlet Container im Hosted Mode. Ist eine Anwendung fertig entwickelt, wird sie mittels eines Compilers in pures HTML und JavaScript auf der Client-Seite überführt. Auf der Server-Seite werden spezielle Servlets generiert, die als Eintrittspunkt für die asynchronen XML-Aufrufe dienen. Das Google-Web-Toolkit beinhaltet eine komplette Bibliothek der zur Erstellung von Userinterfaces notwendigen Komponenten wie Drop-down-Listen, Buttons, Reiter, Menüs etc. Die clientseitige Komponente einer AJAX-Anwendung kann so elegant mithilfe des Google-Web-Toolkits realisiert werden.
Für die serverseitige Komponente der Anwendung bietet sich das Facade-Pattern an. Hierbei werden die vom GWT generierten Servlets als Eintrittspunkte der Server-Anwendung verwendet. Diese sitzen vor einer klassischen Java-Enterprise- Anwendungsarchitektur und delegieren die Anfragen und Requests an diese weiter. Mithilfe der vorgestellten Technik ist es möglich, effiziente Anwendungen wirtschaftlich zu entwickeln. Zwar stellt das GWT noch nicht das erwartete SDK in seinem ganzen Funktionsumfang dar, es markiert jedoch einen großen Schritt in die richtige Richtung.
Alternative Technologien
AJAX beruht auf Features, die zu den Bordmitteln jedes modernen Browsers gehören. Es stellt nur eine einzige Anforderung: die Aktivierung von JavaScript im Browser. Allen Alternativtechnologien gemein ist die Notwendigkeit der Installation von Browsererweiterungen.
Ausblick
Zurzeit hat das Google-Web-Toolkit die besten Chancen, zum Platzhirsch unter den AJAX-SDKs zu werden. Die Bedeutung serverbasierter Applikationen wird nicht zuletzt durch die Bemühungen Googles unterstrichen, mit Chrome einen eigenen Browser zu veröffentlichen. Das eigentliche Betriebssystem auf den Client-PCs verliert zunehmend an Bedeutung und Browser werden zum „Betriebssystem“ für webbasierte Anwendungen. Dass diese Anwendungen auf eine permanente Verbindung zum Server angewiesen sind, um zu funktionieren, ist jedoch ihr größter Nachteil. Aber: Auch hier gibt es bereits technologische Ansätze, um zumindest eine temporäre Unabhängigkeit vom Server zu erreichen – zum Beispiel Google Gears. Dabei wird ein noch größerer Teil der Anwendungslogik in das clientseitige JavaScript verlagert: Der Datenbestand wird in einer lokalen Datenbank gecacht und mit dem Server abgeglichen. Die Rolle des Servers besteht nun in der Datenhaltung sowie der Provisionierung der Anwendungen. Das Google Gears Framework wird in der kommenden Ausgabe vorgestellt.