Rich Internet Application

Der Begriff Rich Internet Application (RIA; engl. „reichhaltige Internet-Anwendung“) ist nicht eindeutig definiert oder standardisiert, sondern aus der Evolution des Internets entstanden und wird im Verlauf der Entwicklung dieses Mediums immer öfter eingesetzt.

In der Regel versteht man unter diesem Begriff Internetanwendungen, die eine reiche (vielfältige) Menge an Interaktionsmöglichkeiten mit ihrer Benutzeroberfläche bieten. Insbesondere RIAs, die in Webbrowsern laufen, ähneln eher dynamischen Desktopanwendungen als klassischen (statischen) Webseiten. Eine RIA ermöglicht dem Besucher einer Webseite z. B. Drag and Drop, 3D-Effekte, Animationen und Unterstützung diverser Videoformate und anderer Medien.

Rich Internet Applications müssen allerdings nicht zwangsläufig im Browser laufen, sondern können auch als Desktopanwendung eingesetzt werden, da die Umgebung, in der RIAs laufen, für deren Bezeichnung irrelevant ist. Vielmehr müssen die Anforderungen der Reichhaltigkeit sowie Verbindung mit dem Internet erfüllt sein.

Erkennungsmerkmale

RIAs erkennt man daran, dass

  • sie Benutzeroberflächen anbieten, die reich an Interaktionsmöglichkeiten sind,
  • sie entweder über das Internet kommunizieren (zum Beispiel mit Servern) oder zumindest über dieses ausgeliefert werden.

Beispiele für reichhaltige Interaktionsmöglichkeiten sind Drag-and-Drop-Fähigkeit oder Bedienbarkeit über Tastenkombinationen.

Eigenschaften

Rich Internet Applications beinhalten in der Regel mehr Anwendungslogik als statische Webseiten, die zum Beispiel auf reinem HTML basieren. Dies kann zu einer erhöhten Ladezeit beim ersten Aufruf führen. Durch Einsatz von Techniken wie z. B. Ajax kann jedoch die Performance sowie Benutzerfreundlichkeit im Gegensatz zu klassischen Webanwendungen spürbar verbessert werden.

Zu den RIAs werden auch Anwendungen gezählt, die Technologien von Drittanbietern erfordern (z. B. den Flash-Player oder die Java Virtual Machine). Diese werden auf dem lokalen Rechner installiert. Andere basieren ausschließlich auf Web-Technologien (wie HTML, CSS, JavaScript, Ajax), die von den meisten gängigen Browsern ohne zusätzliche Plugins unterstützt werden.

Der Begriff Rich Internet Application bezeichnet somit lediglich ein Konzept und keine bestimmte Technologie. Theoretisch wäre es also auch möglich, mit Technologien wie z. B. C/C++, die nicht ausdrücklich für die Erstellung von RIAs konzipiert wurden, eben solche zu erstellen, solange die Voraussetzungen „Reichhaltigkeit der Bedienoberfläche“ sowie „Verbindung mit dem Internet“ erfüllt sind. Trotzdem ist der Einsatz von speziellen Plattformen, wie zum Beispiel Adobes AIR oder Microsoft Silverlight, sinnvoll, da diese Frameworks bereits zahlreiche UI-Komponenten mitbringen.

Reine Animationen stellen keine RIAs dar, da klassische Voraussetzungen wie Interaktionen mit dem Nutzer fehlen.

Technologien

Zur Erstellung von RIAs kommt oft Flash oder DHTML zum Einsatz. Inzwischen gibt es jedoch immer mehr Frameworks und Bibliotheken. Einige davon sind:

Plug-in-basiert

  • JavaFX (Oracle/SUN)
  • OpenDolphin (Canoo Engineering AG)
  • IMTF RIA-Suite (Informatique-MTF AG)
  • Silverlight (Microsoft)
  • Flex und AIR (Adobe)
  • OpenLaszlo, mit dem Compiler-Flag „Flash“ (LaszloSystems)
  • uniPaaS (Magic Software Enterprises)
  • Omnis Studio (TigerLogic)
  • Remote Application Platform (RAP) von Eclipse

HTML/JavaScript-basiert

Vor- und Nachteile

Vorteile

  • Oft benutzerfreundlicher als klassische Webanwendungen durch die Verwendung moderner Interaktionstechniken (z. B. Drag and Drop).
  • Schnellere Reaktion auf Benutzereingaben durch lokale, client-seitige Verarbeitung.
  • Keine „Cross-browser issues“ (durch den Einsatz von speziellen RIA-Frameworks).
  • Reduzierte Server- und Netzwerklast durch lokale Berechnungen.
  • Gegebenenfalls Zugriff auf lokales Dateisystem und Peripherie.
  • Oft einfache GUI-Entwicklung durch reichhaltige UI-Komponenten, die in RIA-Frameworks enthalten sind („Viel WOW!-Effekt ohne viel Aufwand“).
  • Bei Plug-in-basiertem System mehr Performance möglich im Gegensatz zu reinen DHTML-Varianten. Keine Abhängigkeit von der JavaScript-engine des Browsers.

Nachteile

  • Evtl. lange Download- und Ladezeiten.
  • Höhere Ressourcenbelastung des Clientrechners möglich.
  • Manchmal Installation eines Plug-ins notwendig.
  • Evtl. Sicherheitslücken durch installierte Plug-ins.

Barrierefreiheit

Unter Barrierefreiheit im Zusammenhang mit (Web-)Anwendungen versteht man in der Regel die Möglichkeit, diese auch ohne visuelle Wahrnehmung sowohl lesen als auch bedienen zu können. Menschen mit einer Sehbenachteiligung nutzen meist sog. Screenreader, um sich den Inhalt vorlesen zu lassen. Die Interpretation von Bildern ist dabei besonders kritisch, da sich diese nicht so einfach vorlesen lassen. Bei klassischen Webseiten auf HTML-basis ist es daher wichtig, diese mit dem alt-Attribut zu versehen (wie vom W3C in der HTML4 DTD vorgegeben) in der eine kurze textuelle Beschreibung enthalten ist, was das Bild zeigt. Zur Navigation innerhalb der Anwendung kann eine herkömmliche Tastatur verwendet werden, wobei hier der Tabulatortaste eine besondere Bedeutung zukommt, da mit dieser von einem Kontrollelement (z. B. ein Button oder Text-Eingabefeld) zum nächsten gesprungen werden kann.

Die Konsequenz daraus ist:

  • Der Inhalt von (Web-)Anwendungen muss durch Screenreader lesbar sein.
  • Die (Web-)Anwendung muss über die Tabulatortaste steuerbar sein.
  • Bilder müssen textuell beschrieben sein.

In Bezug auf RIAs bedeutet das, dass DHTML-basierte Webanwendungen oft am barriereärmsten sind. Der sog. Markup der Seite kann gut von Screenreadern gelesen werden. Über die Tabulatortaste lassen sich die meisten Elemente anspringen. Ist die Seite nun auch noch W3C-konform, d. h. entsprechend ihrer DTD-Definition valide, so kann sie als barrierearm bezeichnet werden.

Bei Plug-in basierten Rich Internet Applications ist dies allerdings problematischer, da diese Anwendungen oft in anderen Formaten ausgelieferten werden. So werden z. B. für Flash-Anwendungen *.swf Container verwendet während bei JavaFX *.class und *.jar Dateien zum Einsatz kommen. Dies führt zu mindestens zwei Problemen:

  • Sind diese Dateien nicht als reiner Text lesbar, so können sie nicht von Screenreadern erfasst werden.
  • Sind die Dateien lesbar, so heißt das nicht unbedingt, dass der Inhalt auch interpretierbar ist.

Letzterer Fall tritt immer dann auf, wenn die interpretierende Software (hier der Screenreader) kein Markup oder andere Markierungen im Text vorfindet, die ihm bei der semantischen Interpretation des Inhalts unterstützt.

In der Praxis ist die Unterstützung von Plug-in basierten RIAs noch durchwachsen umgesetzt. Der am weitesten verbreitete Screenreader „Windows Narrator“ unterstützt inzwischen das Parsen von Flash- sowie Silverlight-Inhalten. Die Navigation muss allerdings explizit vom Programmierer so angepasst werden, so dass sinnvolle Sprünge innerhalb der Benutzeroberfläche durch Drücken der Tabulatortaste möglich sind. Dies kommt allerdings, oft aufgrund von Zeit- und Geldmangel, noch viel zu selten vor.

Suchmaschinenoptimierung

Unter dem Begriff Suchmaschinenoptimierung (oder kurz SEO) versteht man die Optimierung von Webinhalten, sodass diese besser von Suchmaschinenbetreibern, wie zum Beispiel Google, gefunden, interpretiert und indiziert werden können.

Was bei „gewöhnlichen“, statischen Webseiten gut funktioniert, ist bei dynamischen Inhalten, wie sie typischerweise bei RIAs vorkommen, extrem problematisch. Grund hierfür ist, dass die Suchmaschinenbetreiber sog. „Bots“ losschicken, die Webseiten crawlen sollen. Dies klappt allerdings nur, wenn der Inhalt zum einen syntaktisch lesbar und zum anderen semantisch interpretierbar ist.

Bei dynamischen Webseiten scheitert dies daran, dass die erwähnten Bots keinen Scriptcode ausführen, der für die Kontrolle der Inhalte zuständig ist. Ein Link, der zum Beispiel über Ajax dynamisch Inhalte nachlädt und darstellt, kann von einem solchen Bot nicht gelesen werden. Damit scheitert logischerweise auch eine Indizierung. Im schlimmsten Fall taucht die Webseite gar nicht erst in den Suchergebnissen auf.

Was bei HTML-basierten Webanwendungen noch durch Techniken wie z. B. Hijax kompensierbar ist, funktioniert bei Plug-in basierten RIAs nicht mehr. Grund dafür ist, dass hier das sog. Deep Linking schwierig umsetzbar ist. Darunter versteht man die Möglichkeit bestimmte Inhalte über eine eindeutige URL direkt anspringen zu können. Da sich bei Plug-in basierten RIAs die Website-URL in der Regel nicht ändert, können die Inhalte keiner bestimmten Adresse zugewiesen werden. Weiterhin ist es für Suchmaschinen-Bots oft schwierig proprietäre oder binäre Formate zu öffnen bzw. zu lesen, ähnlich der zuvor erwähnten Problematik bezüglich Barrierefreiheit. Inzwischen unterstützt zwar zum Beispiel der Anbieter Google das Parsen von Flash-Anwendungen, allerdings werden andere Formate (wie sie zum Beispiel von Java genutzt werden) ignoriert. Zusätzlich besteht weiterhin das Problem des zuvor schon erwähnten Deep Linking, sofern der Programmierer nicht explizit dafür gesorgt hat (zum Beispiel mit Frameworks wie SWFAddress, die über die Manipulation der aktuellen URL mit Hilfe von JavaScript, eindeutige Adressen für dynamische Inhalte erzeugen können).

Die Alternative, dynamische Inhalte automatisch durch statische zu ersetzen, falls ein Such-Bot die Webseite besucht, ist nicht zu empfehlen. Zum einen bedeutet dies einen erheblichen Mehraufwand und zum anderen fordern Suchmaschinenbetreiber, wie zum Beispiel Google, dass für ihre Bots keine speziell angepasste Version der Seite ausgeliefert werden soll. Ist dies trotzdem der Fall, so kann es passieren, dass diese Inhalte aus dem Index des Suchmaschinenbetreibers gelöscht werden.

Sicherheit

Für alle Webanwendungen gilt generell, dass diese in der Regel in einer sog. Sandbox laufen. Das bedeutet, dass diese Applikationen nur eingeschränkte Rechte haben. Der Zugriff auf das Dateisystem oder die Ausführung von Programmen ist nicht möglich. Manche Technologien, wie zum Beispiel Java, unterstützen allerdings die Möglichkeit durch Vorlage eines Zertifikats an den Benutzer, zusätzliche Rechte zu erlangen. Dem Anwender wird in diesem Fall ein Dialog angezeigt und aufgefordert, das Zertifikat entweder anzunehmen oder abzuweisen. Stimmt er zu, gewährt er der Anwendung weitere Rechte auf seinem lokalen System. Dies sollte allerdings nur dann gemacht werden, wenn die Quelle der RIA als absolut vertrauenswürdig eingestuft werden kann.

RIAs, die auf Webstandards, wie HTML und JavaScript setzen, können normalerweise als relativ sicher angesehen werden. Ausnahmen bilden Sicherheitslöcher im verwendeten Webbrowser oder nicht technische Angriffe, wie zum Beispiel das sog. Social Engineering.

Bei Plug-in basierten RIAs ist das Ganze deutlich problematischer, da diese durch eigene Sicherheitslöcher das System des Benutzers gefährden können. Im schlimmsten Fall ist das Einschleusen sowie Ausführen von schadhaftem Code durch sog. Exploits möglich. Das Sandbox-Modell hilft in diesem Fall nicht.

In der Vergangenheit ist besonders die Flash-Plattform regelmäßig negativ durch schwerwiegende Sicherheitsmängel aufgefallen. Dies ist besonders problematisch, da Flash heute auf sehr vielen Computern, die im Web unterwegs sind, installiert ist. Angreifer müssen somit lediglich speziell präparierten Code auf ihrer Webseite platzieren und den Anwender auf diese locken. Besucht der Benutzer nun diese Seite, wird der Code eingeschleust und im schlimmsten Fall zur Ausführung gebracht.

Trends

Rich Internet Applications werden als die nächste Generation von Software-Anwendungen gesehen. Speziell im Intranet bietet dieses enorme Vorteile, da bei neueren Versionen die aktuelle Software nicht verteilt/installiert werden muss. Aber auch im Internet nutzen immer mehr Firmen RIAs. Geschäftsmodelle die auf RIAs basieren, nennen sich oft Software as a Service oder ASP-Dienstleistung.

Gerade in den Bereichen Mobile Devices (z. B. Funktelefone) und Embedded Devices (z. B. Navigationssystemen) ist der Bedarf nach mächtigeren Oberflächen, Standardisierung und Herunterladbarkeit (ohne Installation) groß. So bieten immer mehr Hochschulen Studiengänge in den Bereichen Game Design, Interactive Design und Mobile Design an.

Siehe auch

Weblinks

Patentliteratur

United States Patent 7000180: Neil Balthaser, als Erfinder genannt in folgenden Links: