imported>SchlurcherBot: Bot: http → https

2025-12-27T20:16:13Z

Bot: http → https

Neue Seite

{{Belege fehlen|2=Dieser Artikel}}
'''Rich Internet Application''' ('''RIA'''; {{enS}} für „reichhaltige Internet-Anwendung“) bezeichnet eine [[Webanwendung]] mit vielen Eigenschaften einer [[Desktopanwendung]]. Das Konzept steht in engem Zusammenhang mit der [[Single-Page-Webanwendung]] und bietet dem Benutzer interaktive Funktionen wie [[Drag and Drop]], [[Kontextmenü]]s, [[WYSIWYG]]-Bearbeitung usw. Der Begriff wurde erstmals 2002 vom Unternehmen [[Macromedia]] eingeführt, um ihr Produkt zu beschreiben, das später zu [[Adobe Flash]] wurde. Im Laufe der 2000er Jahre wurde der Begriff verallgemeinert und bezeichnete dann browserbasierte Anwendungen, die mit konkurrierenden [[Browser-Plug-in]]-Techniken wie [[Java-Applet]]s oder [[Microsoft Silverlight]] entwickelt wurden.

Mit der Abkehr von Browser-Plug-ins und dem Übergang zu standardisierten [[HTML5]]-Techniken wurden Rich Internet Applications durch [[JavaScript]]-basierte Webanwendungen ersetzt, darunter Single-Page-Anwendungen und [[Progressive Webanwendung]]en.

== 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|Drag-and-Drop]]-Fähigkeit oder Bedienbarkeit über [[Tastenkombination]]en.

== Eigenschaften ==
Rich Internet Applications beinhalten in der Regel mehr Anwendungslogik als statische Webseiten, die zum Beispiel auf reinem [[Hypertext Markup Language|HTML]] basieren. Dies kann zu einer erhöhten Ladezeit beim ersten Aufruf führen. Durch Einsatz von Techniken wie z. B. [[Ajax (Programmierung)|Ajax]] kann jedoch die Performance sowie [[Benutzerfreundlichkeit]] im Gegensatz zu klassischen [[Webanwendung]]en spürbar verbessert werden.

Zu den RIAs werden auch Anwendungen gezählt, die Technologien von Drittanbietern erfordern (z. B. den [[Adobe Flash|Flash]]-Player oder die [[Java Virtual Machine]]). Diese werden auf dem lokalen Rechner installiert. Andere basieren ausschließlich auf Web-Technologien (wie HTML, [[Cascading Style Sheets|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 [[Adobe Integrated Runtime|AIR]] oder [[Microsoft Silverlight]], sinnvoll, da diese [[Framework]]s bereits zahlreiche [[Benutzerschnittstelle|UI-Komponenten]] mitbringen.

Reine Animationen stellen keine RIAs dar, da klassische Voraussetzungen wie [[Interaktion#Informatik|Interaktionen]] mit dem Nutzer fehlen.

== Technologien ==
{{überarbeiten}}
Zur Erstellung von RIAs kommt oft [[Adobe Flash|Flash]] oder [[Dynamisches HTML|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)
* [[UltraLightClient|IMTF RIA-Suite]] (Informatique-MTF AG)
* [[Microsoft Silverlight|Silverlight]] (Microsoft)
* [[Apache Flex|Flex]] und [[Adobe Integrated Runtime|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 ===
* [[Google Web Toolkit]]
* [[jQuery]] oder [[Ext JS]] oder ähnliche JavaScript-Frameworks
* [[OpenLaszlo]], mit dem Compiler-Flag „DHTML“ (LaszloSystems)
* [[Vaadin]] (Java, Apache)

== Vor- und Nachteile ==
=== Vorteile ===
* Oft benutzerfreundlicher als klassische [[Webanwendung]]en 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 [[Grafische Benutzeroberfläche|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 [[World Wide Web Consortium|W3C]] in der HTML4 [[Dokumenttypdefinition|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 [[Dynamisches HTML|DHTML]]-basierte [[Webanwendung]]en oft am barriereärmsten sind. Der sog. [[Markup]] der Seite kann gut von [[Screenreader]]n 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 [[Adobe Flash|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 [[Semantik|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 [[Microsoft Silverlight|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 [[Indexierung|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 [[Webcrawler|crawlen]] sollen. Dies klappt allerdings nur, wenn der Inhalt zum einen [[Syntax|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 (Programmierung)|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 [[Webanwendung]]en 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. [[Surface Links und Deep Links|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är]]e oder [[Binärcode|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 [[Adobe Flash|Flash]]-Anwendungen, allerdings werden andere Formate (wie sie zum Beispiel von [[Java-Technologie|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 [[Webstandard]]s, 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 (Sicherheit)|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. [[Exploit]]s möglich. Das [[Sandbox]]-Modell hilft in diesem Fall nicht.

In der Vergangenheit ist besonders die [[Adobe Flash|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äftsmodell]]e die auf RIAs basieren, nennen sich oft [[Software-as-a-Service]] oder [[Application Service Provider|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 ==
* [[Accessible Rich Internet Applications]]

== Weblinks ==
* [https://www.w3.org/2006/appformats/ w3.org Web Application Formats Working Group]

=== Patentliteratur ===
United States Patent 7000180: Neil Balthaser, als Erfinder genannt in folgenden Links:
* {{Patent| Land=US| V-Nr=7000180B2| Titel=Methods, systems, and processes for the design and creation of rich-media applications via the internet| A-Datum=2001-02-09| V-Datum=2006-02-14| Anmelder=Balthaser Online Inc| Erfinder=Neil Balthaser}}
* http://www.golem.de/0602/43563.html
* http://blog.flashgen.com/2006/08/17/the-balthaser-ria-patent-revisited/

[[Kategorie:Webanwendung]]

Rich Internet Application - Versionsgeschichte

imported>SchlurcherBot: Bot: http → https