Es gab Zeiten, da wurden komplexe Softwaresysteme über grün-schwarze Terminals bedient. Diese waren in ihren Darstellungs- und Interaktionsfähigkeiten sehr eingeschränkt, und so feierten ab Ende der 80er Jahre grafische Benutzeroberflächen ihren Siegeszug. Die Programmierung wurde durch Umgebungen wie Visual Basic oder Delphi stark vereinfacht.
Heute sind es die klassischen HTML-Seiten, die dem Benutzer nicht das wiedergeben, was er von einer modernen Benutzerschnittstelle erwartet. Die Ajax-Technologie macht es jedoch möglich, schick aussehende und interaktive Oberflächen für Internetbrowser zu entwickeln. Die neue Freiheit, innerhalb des Frontends entwickeln zu können, führt zu einer enormen Freisetzung von Kreativität bei der Entwicklung: Beispiele für die neuen Möglichkeiten sind Google Maps und Writely oder Web-2.0-Communities wie Flickr und Del.icio.us.
Für Unternehmen bietet Ajax inbesondere bei der Modernisierung von Bestandsanwendungen neue Möglichkeiten. Diese Legacy-Systeme erhalten durch Ajax rasch und effizient browserbasierende Oberflächen, die über den gleichen Bedienkomfort wie eine herkömmliche Desktop-Anwendung verfügen. So lässt sich die bestehende Geschäftslogik einer Mainframe-Anwendung weiterhin nutzen und der Anwender kann beispielsweise auch per Internet auf die Lösung zugreifen. Im Rahmen eines SOA-Projektes bietet Ajax die notwendigen Technologien, um die Modernisierung der Anwendungsarchitektur auch für den Anwender sichtbar zu machen. Nicht mehr das Erstellen von Services, sondern das Konsumieren derselben wird künftig bei einer SOA im Mittelpunkt stehen.
Die klassische SOA spielt sich weit hinter dem User-Interface ab: Neue Geschäftsabläufe werden auf Basis vorhandener Services definiert und unterstützen den Anwender an seinem IT-Arbeitsplatz. Hierzu gilt es, über einfache Mittel eine interaktive Oberfläche für den Geschäftsprozess zu gestalten. Dieses Szenario ist ein idealer Einsatzbereich für die Ajax-Technologie. Doch wo findet die Integration statt: im JavaScript des Browsers oder irgendwo im Backend? SOA spielt sich auch direkt im User-Interface ab: Zu einzelnen Services bietet Ajax ein adäquates GUI-Konzept. Was wäre Google Maps ohne seine gut gelungene Browsing-Komponente? Das Verbinden von Visualisierungen verschiedener Services realisieren so genannte Mashups. Diese Anwendungen laufen ohne Installationsaufwand im Browser und verhalten sich interaktiv wie eine Desktop-Anwendung.
Anwendungen mit Ajax lassen sich darüber hinaus wesentlich einfacher und schneller erweitern als mit vergleichbaren Technologien. Ajax-Anwendungen sind partiell aufgebaut und arbeiten auch so. Dadurch können Unternehmen neue Businessfunktionen, wie sie von der darunterliegenden SOA bereitgestellt werden, schnell und mit geringem Aufwand in bestehende Ajax-Anwendungen einbauen.
Die Verwendung von Ajax bringt in Bezug auf andere SOA-Front-
end-Technologien erhebliche Vorteile mit sich. Im Vergleich zu HTML müssen Nutzer Seiten seltener neu laden, um aktuelle Änderungen und neue Informationen einzusehen. Darüber hinaus bekommen die Ajax-Anwendungen das gleiche Look&Feel, wie es Benutzer von Desktopapplikationen gewohnt sind. Die Verwendung von Ajax hilft auch den Entwicklern. War die Programmierung von Java-GUIs noch sehr aufwendig und erforderte entsprechendes Know-how, so geht den Entwicklern die Arbeit mit Ajax leichter von der Hand.
Ein weiterer Vorteil von Ajax-Anwendungen für SOA-Front-Ends ist, dass diese keine clientseitige Installation benötigen. Dadurch entfällt die umständliche Ausrüstung der Clients mit speziellen Applikationen, ausserdem sinkt damit auch das Kompatibilitätsrisiko beim Client.
Am Markt existieren derzeit über 150 Ajax-Frameworks, die ent-
weder als Open-Source oder als kommerzielle Produkte verfügbar sind. Der Leistungs- und Funktionsumfang variiert erheblich und reicht von kompletten Design- und Runtime-Umgebungen über Snippet-Sammlungen bis zu Control-Bibliotheken. Auch befreien längst nicht alle Frameworks den Entwickler von JavaScript- und HTML-Programmierung, im Gegenteil: Häufig gilt es, die verschiedenen mitgelieferten Komponenten mit Hilfe von JavaScript in bewährter Manier manuell zusammenzufügen.
Weitere Unterschiede zwischen den diversen Frameworks sind Ausführungen als reines Client-Framework mit einem schwergewichtigen Ajax-Client oder als serverseitiges Framework mit einem Thin-Ajax-Client. Bei den Client-Frameworks enthalten sogenannte Fat-Ajax-Clients einen Grossteil der Programmlogik und binden die Backend-Server über SOAP- und XML-Calls ein. Die serverseitigen Frameworks arbeiten mit leichtgewichtigen Frontends: Hierbei wird ein Ajax-Frontend auf dem Server über eine Java-Klasse repräsentiert. Felder und Boxen innerhalb der Oberfläche entsprechen Eigenschaften und Methoden von Java-Klassen. Benutzeraktionen und Eingaben sendet das Frontend an den Server, der die weitere Verarbeitung übernimmt.
Klassische Web-Anwendung versus Ajax
Hinter Ajax verbirgt sich weitaus mehr, als der Begriff Asynchronous JavaScript und XML vermuten lässt. Allgemein beschrieben basiert die Technologie auf einer in JavaScript implementierten Engine, die in einem unsichtbaren Frame einer Webseite sitzt. Das System übersetzt XML-Scripts in XHTML und CSS und stellt die Inhalte im Browser dar. Die asynchrone Kommunikation mit dem Server erfolgt mit XMLHttpRequest. Diese API erlaubt die Übermittlung beliebiger Daten über HTTP – entweder als Plain-ASCII oder als DOM-Baumstruktur. Die Programmierschnittstelle DOM (Document Object Model) stellt dabei den Funktionsumfang bereit, der zum Aufbau dynamischer Webseiten notwendig ist. JavaScript dient schliesslich als übergreifende Schnittstelle, mit der alle Komponenten angesprochen und gesteuert werden. Da Ajax auf vorhandene Standards aufsetzt, lassen sich bestehende Web-Applikationen recht einfach mit der neuen Technologie erweitern. Im einfachsten Fall funktioniert dies über JavaScript Code Snippets, die in bestehende HTML-Seiten eingebunden werden.
