Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

• 1. Mai 2009: Woran erkennt man einen guten Entwickler?
• 1. April 2009: Interfaces vs abstrakte Basisklassen
• 1. März 2009: Sinn und Zweck von AOP
• 1. Februar 2009: Die Forderung nach Softwarequalität
• 1. Januar 2009: SOA vs WOA
• 1. Dezember 2008: Dynamic Language Runtime: .NET, quo vadis?

Heute, am 1. Juni 2009, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

Heißt die Zukunft RIA?

So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

Bevor man sich der Frage widmet, ob die Zukunft RIA heißt, gilt es zu klären, was sich überhaupt hinter diesem Begriff verbirgt: Laut Wikipedia handelt es sich bei einer RIA um

eine Anwendung, die Internet-Techniken benutzt und eine intuitive Benutzeroberfläche bietet.

Das Akronym RIA steht dabei für Rich Internet Application. Der englische Begriff Rich steht dabei laut Wikipedia für

die reichhaltigen Möglichkeiten wie zum Beispiel Drag-und-Drop-Fähigkeit oder Bedienbarkeit über Tastenkürzel, suggeriert dabei aber auch einen “Mehrwert” gegenüber herkömmlichen Webanwendungen.

Da die klassischen Webtechnologien die Erstellung solcher Benutzeroberflächen auf Grund von technischen Limitierungen nicht zulassen, assoziieren viele Entwickler RIAs mit solchen Anwendungen, die zwar innerhalb des Browsers laufen, in der Regel jedoch auf zusätzlichen und zumeist proprietären Addins wie beispielsweise Silverlight oder Flash basieren.

Der Einsatz eines solchen Addins ist jedoch keine zwingende Voraussetzung für die Entwicklung einer RIA. So können entsprechende UIs beispielsweise auch nur auf Basis von AJAX erstellt werden. Als Vorreiter für eine AJAX-basierte RIA kann dabei Outlook Web Access gelten, das einen webbasierten Zugriff auf Exchange Server ermöglicht und sich in seiner Bedienung an das Desktopprodukt Outlook anlehnt.

Die Addin-basierte Entwicklung von Anwendunen verfügt jedoch im Vergleich zu AJAX-basierten Varianten über einige Vorteile:

• Mächtigkeit: Da die Hersteller der Addins nicht an die von den Browsern gesetzten Grenzen gebunden sind, verfügen auf diesen Addins basierende Anwendungen häufig über erweiterte Fähigkeiten. Diese betreffen – da eine solche Anwendung in der Regel nur das webbasierte Frontend einer mehrschichtigen Anwendung darstellt – meistens grafische Aspekte einer Anwendung, wie beispielsweise Animationen, 3D-Grafik, Multimediafähigkeiten, …
• Plattformübergreifend: Da es zudem Aufgabe des Herstellers eines Addins ist, dafür zu sorgen, dass das Addin in allen verbreiteten Browsern funktioniert, stellt sich für den Entwickler die Frage nach der plattformübergreifenden Entwicklung nicht mehr. Da das Addin im Idealfall auf allen Browserplattformen gleich funktioniert, gibt es für den Entwickler keine Kompatibilitätsprobleme mit den verschiedenen Browsern mehr: Entweder läuft die Anwendung ganz oder gar nicht.
• Out of Browser: Mit zunehmender Reife ermöglichen es die Addins, für das Web konzipierte Anwendungen mit wenig Aufwand auf den Desktop zu portieren. Hierbei werden unter Umständen gänzlich verschiedene Ansätze verfolgt, wie beispielsweise ein Vergleich der Out of Browser-Features von Silverlight und AIR zeigt.
• Offline: Spätestens, sobald RIAs auch außerhalb eines Browsers ausgeführt werden können, stellt sich die Frage, inwiefern sie auch ohne bestehende Verbindung zum Internet lauffähig sind. Viele Frameworks unterstützen daher diese Offline-Fähigkeit durch entsprechende APIs und ermöglichen es einer Anwendung, die offline erstellten und geänderten Daten mit einem Server zu synchronisieren, sobald die Anwendung wieder über eine Internetverbindung verfügt.
• RAD: Im Vergleich zu AJAX-basierten Anwendungen können Addin-basierte Anwendungen wesentlich schneller entwickelt werden, da sich der Entwickler auf die eigentliche Anwendung konzentrieren kann, ohne sich zusätzlich noch um einen Teil der Infrastruktur kümmern zu müssen.

Nimmt man all diese Aspekte zusammen, und beachtet zusätzlich den seit Jahren bestehenden Trend, Anwendungen in das Internet zu verlagern, dann liegt auf der Hand, dass RIAs eine große Zukunft bevorsteht. Es fragt sich nur: Wofür?

Auf Grund der oben genannten Fähigkeiten zu glauben, RIAs seien die universelle Lösung und die Zukunft schlechthin, ist reichlich naiv: Egal, für welche Plattform man sich als Entwickler entscheidet – RIAs haben systembedingte, immanente Nachteile, die man mit gleich welcher RIA-Technologie nicht lösen können wird.

Allen voran sei hier die Sandbox genannt, welche die Addins den Anwendungen in der Regel setzen: Weder besteht direkter Zugriff auf die unter Umständen sehr spezielle Hardware des Clients, noch kann eine RIA Arbeits- und Festplattenspeicher in dem Maße nutzen wie dies für eine klassische Desktopanwendung möglich ist.

Führt man sich vor Augen, dass für viele Aufgaben Bedarf an spezieller Hardware besteht – man denke nur an Lesegeräte für Smartcards oder Chipkarten – oder dass viele Berechnungen große Mengen an Speicher und / oder Prozessorleistung benötigen, wird offensichtlich, dass RIAs hierfür weniger geeignet sind.

In der Praxis werden sich RIAs daher für komplexe Anwendungen insbesondere für die UI etablieren, denn genau hierin liegen die Stärken. Der Middletier sowie das Backend werden sich allerdings nach wie vor auf einem dedizierten Webserver und nicht auf dem lokalen System befinden – schlichtweg, weil dort mehr Möglichkeiten gegeben sind, die für die Businesslogik und ähnliche Bereiche einer Anwendung interessant sind.

Tritt man nun einen Schritt zurück, so erkennt man, dass weder RIAs noch einzelne Addins per se die Zukunft sind, sondern dass sie lediglich eine weitere Option für die Implementierung des Frontends und damit der UI einer Anwendung darstellen.

Und selbst hierfür muss je nach Kontext entschieden werden, ob eine RIA überhaupt Sinn ergibt: Nicht für jede Webseite und nicht für jede Anwendung ist es sinnvoll, diese zukünftig als RIA zu bauen – bloß, weil man nun die Möglichkeit dazu hat.

Langer Rede kurzer Sinn: Die Zukunft heißt nicht pauschal RIA – dafür sind die Konzepte zu sehr auf die Entwicklung von UIs ausgelegt. Doch beschränkt man die ursprüngliche Frage auf den Bereich der Frontends, so können RIAs ihre Fähigkeiten dort – den entsprechenden Kontext und damit den Sinn für den Einsatz einer RIA vorausgesetzt – perfekt ausspielen.