Rich Internet Applications (RIA) sind Web-Applikationen, die mit einer wesentlich interaktiveren Benutzerschnittstelle ausgestattet sind, als wir das bisher von den auf HTML basierten «poor ugly web applications» (PUWA) gewohnt waren. RIA sind allerorten auf dem Vormarsch – heute kann praktisch kein Anbieter seinen Anwendern die mühsame Benutzeroberfläche einer PUWA mehr zumuten.
RIA werden heute in den meisten Fällen mit Ajax gebaut. Einer der Hauptgründe dafür ist, dass diese Technologie ohne Installation eines Plug-in wie Flash oder Java auskommt. Aber diese Eigenschaft hat einen hohen Preis: Anbieter von Rich-Internet-Lösungen haben sehr hohe Entwicklungs- und Wartungskosten zu tragen und die Kunden sind mit dem Resultat oft nicht wirklich zufrieden.
Jörg Stuker von Namics hat anlässlich des Kick-off-Meetings der Special Interest Group RIA der Java User Group Switzerland (JUGS) trefflich die Leiden eines RIA-Anbieters zusammengefasst: ständig Performance-Probleme, Browser-Abhängigkeiten, Probleme mit der Darstellung internationaler Zeichensätze, mit der Anbindung von Datenbeständen und dem angemessenen Entwurf einer RIA-Benutzer-oberfläche. Bis auf den letzten Punkt sind alle Unwägbarkeiten verknüpft mit der üblicherweise verwendeten Technologie: Ajax.
Die Folge sind überteuerte und verspätete Lösungen – oder, falls der Anbieter sich dieser Schwierigkeiten zum Zeitpunkt des Angebots nicht bewusst war, defizitäre Projekte. Und falls das Projekt dann überhaupt noch geliefert wird, muss man als Anbieter trotz der inves-tierten Tränen und Mühen mit unzufriedenen Benutzern rechnen, die sich über lange Antwortzeiten beklagen oder feststellen müssen, dass die Anwendung auf ihrem Lieblingsbrowser nicht in der erwarteten Weise oder gar nicht funktioniert.
Warum nimmt man das alles auf sich? Die Lösung wäre eigentlich einfach: die Verwendung eines Java-Plug-ins. Die Entwicklung könnte dann in reinem Java erfolgen und man müsste sich nicht mit dem Ajax- oder dem Flash-Technologie-Mix (HTML, JavaScript oder ActionScript, CSS, XML, MXML, diverse Bibliotheken) herumschlagen. Die RIA würde in einer Java-Runtime-Umgebung (JRE) ausgeführt werden und wäre somit unabhängig von den diversen Spezialitäten der unterschiedlichen Browser. Zudem wäre sie in der Regel auch schneller, da sie nicht den inhärenten Limitierungen der Browser bei der Ausführung von JavaScript-Code unterläge. Der Browser wurde schliesslich für das Anzeigen von Hypertext-Dokumenten und nicht für die Ausführung komplexer Programmlogik entworfen.
Ein Java-Plug-in für eine Geschäftsanwendung im Unternehmen oder bei B2B-Anwendungen ist weitgehend akzeptiert, da man in Unternehmen auch die höhere Sicherheit einer RIA zu schätzen weiss, die in der abgeschotteten Zone eines Java-Plug-in ausgeführt wird. Aber ein Java-Plugin für jedermann zugängliche Webseiten? Die Installation eines Plug-in wird im allgemeinen – wobei man bei Flash gelegentlich eine milde Ausnahme macht – und bei Java im besonderen als unzumutbar und als Verstoss gegen die Barrierefreiheit angesehen.
Ferner werden oft Java-RIA mit Java-Applets gleichgesetzt – und diese haben seit ihren frühesten Tagen einen sehr schlechten Ruf. Einerseits sind Applets freilich nicht mehr so schlecht wie dieser Ruf, auch wenn der Java-Hauptsponsor Sun selbst das kaum erwähnt. Andererseits gibt es auch rein auf Java basierende RIA-Lösungen wie den Ultra Light Client von Canoo, die ohne Applets auskommen. Und sobald ein Java-Plug-in salonfähig wäre, würden sicher auch andere Anbieter von Consumer-Anwendungen auf Java setzen.
Betrachten wir nun etwas genauer die Höhe der Hürde einer Installation des Java-Plug-ins – und behalten dabei auch die Komplexität der Anwendung im Auge, die als RIA der Öffentlichkeit zur Verfügung gestellt werden soll. Oft sind Benutzerführungen und die Bedienung von Online-Portalen so komplex, dass bestimmte Gruppen wie ältere Leute mit wenig Computererfahrung oder Kinder von der Benutzung ausgeschlossen sind. Ein Plug-in würde diese Situation nicht verschlimmern, da die Barriere nicht durch das Plug-in, sondern durch die Anwendung selbst aufgestellt wird.
Auf der anderen Seite benutzen viele von uns Online-Fotolabore, um digitale Bilder auf Papier zu bannen. Viele dieser Anbieter arbeiten heute mit einer separat zu installierenden Anwendung, die mindestens so aufwendig zu installieren ist wie ein Plug-in – und bei der man dann auch noch jedes Update nachladen muss. Anwender, die solche Lösungen heute benutzen, hätten also auch keine Probleme mit der Installation eines Java-Plug-in.
Nicht jede Anwendung im Internet muss als RIA implementiert werden. In vielen Fällen wie Benutzer-Registrierung oder Kundenumfragen ist das klassische, formularorientierte Vorgehen von HTML-Anwendungen der Funktionalität angemessen, die man anbieten möchte. In diesem Fall wird in der Regel auch kein Ajax benötigt, oder nur sehr einfache Ajax-Elemente. Bei Anwendungen, die etwas komplexer sind, wie Online-Banking und Reise-Buchungen, können reichhaltigere Interaktionsmöglichkeiten die Bedienung erheblich vereinfachen. Hier fragt sich schon, ob sich der Aufwand und die Mühen lohnen, die vielfältigen technischen Probleme von Ajax-Anwendungen zu lösen, oder ob es nicht im Sinne des Benutzers wäre, die Installation eines Java-Plug-in in Kauf zu nehmen und sich dafür bei der Entwicklung auf die Anwendungsfunktionalität und eine benutzerfreundliche Oberfläche zu konzentrieren.
