Web- statt Desktop-Framework: Umstieg mit System

Inhaltsverzeichnis

Immer mehr IT-Anwendungen werden nicht mehr für den Desktop-PC programmiert, sondern als Webanwendung konzipiert und entwickelt. Vorreiter ist Google: Ein besonders gutes Beispiel ist die Produktpalette rund um Google Docs, die immer mehr den Komfort und Umfang von Office-Paketen erreicht. Der Suchmaschinenanbieter hat damit den Softwareriesen Microsoft gezwungen, mit seiner Office-Suite auch ins Web zu gehen. Der Umstieg auf webbasierte Softwareprogramme ist allerdings nicht ohne Tücken. Die PPI AG, ein Consulting- und Software-Unternehmen der Banken- und Versicherungsbranche, bereitete die Entwicklung ihrer webbasierten Software intensiv und vor allem systematisch vor.

Bei der Entwicklung einer klassischen Desktopanwendung entscheidet man sich einfach für eine Technologie und Programmiersprache, beispielsweise C# mit .NET oder Java. Auf dieser Basis können Entwickler eine Anwendung schreiben, die mehr oder weniger auf allen Windowsrechnern oder, beim Einsatz von Java, auf allen Desktop-Systemen läuft. Nachteil ist, dass der Kunde die Anwendung häufig auf tausenden Systemen ausliefern muss. Regelmäßige Updates werden dann schnell zur Kostenfalle.

Webanwendungen erfordern viel Vorarbeit

Als brauchbare Alternative haben sich in den letzten Jahren sogenannte Rich Internet Applications (RIA) hervorgetan. Die webbasierten Anwendungen sollen den Komfort von lokal installierten Programmen auf den Browser übertragen. Dadurch entfällt die aufwendige Einrichtung der Anwendung auf verschiedenen Systemen, und Updates spielt man nur einmal an zentraler Stelle ein.

Damit webbasierte Anwendungen genauso schnell und ruckelfrei ablaufen, setzen Programmierer meist die Übertragungstechnologie AJAX ein. Dabei kombiniert man meist serverseitige Programmiersprachen wie PHP oder ASP.Net mit weiteren Sprachen wie Javascript. Zudem muss die Anwendung auf mehreren Browsern mit unterschiedlichen Versionen lauffähig sein. Eine Anwendung, die unter solchen Vorraussetzungen entwickelt wird, erfordert ein deutlich breiter gefächertes Know-how seitens des Entwicklungsteams.

Die Auswahl der richtigen Technologie ist bei Webanwendungen daher deutlich schwieriger als bei klassischen Desktop-Anwendungen. Viele der in Frage kommenden Frameworks sind noch nicht so ausgereift wie ihre Desktop-Pendants. Zudem macht die technische Komplexität von RIA-Anwendungen solche Software fehleranfälliger und wartungsintensiver. Daher kommt der Wahl des Frameworks besondere Bedeutung zu.

Den unübersichtlichen Markt eingrenzen

PPI stand bei der Programmierung der webbasierten Version seiner Software Rating Flex vor dieser Herausforderung und ging dabei systematisch vor. Um sicherzustellen, dass das Produkt mit der am besten geeigneten Technologie programmiert wird, erstellten die Entwickler eine Liste mit möglichen Frameworks und Auswahlkriterien wie "Gibt es professionellen Support?", "Seit wann existiert das Framework?" oder "Wie groß ist die User-Community?". Den Umfang der Kriterien begrenzten die Verantwortlichen auf 15 bis 20 Kriterien, um den Arbeitsaufwand in Grenzen zu halten und den Überblick zu wahren. Trotz dieser Eingrenzung wurden für eine umfassende Bewertung bis zu zwei Arbeitstage eingeplant.

Bei den Frameworks wurde dagegen ein breites Feld von Anbietern betrachtet: Zum Spektrum gehörten klassische JavaScript-Frameworks, Technologien wie Flash mit Flex sowie Java-JavaScript-Hybride, beispielsweise das Google Web Toolkit. Die Entwickler legten besonderen Wert auf ein Open-Source-Framework, um Teile davon an die eigenen Bedürfnisse anpassen zu können. Darüberhinaus ist die Nutzergemeinde bei Open Source in der Regel aktiver als die von Standardlösungen.

Anhand der Kriterien kamen drei Favoriten mit unterschiedlichen Entwicklungsansätzen in die engere Auswahl: Dojo, die Eclipse Rich Ajax Platform sowie das Google Web Toolkit. Deren Vor- und Nachteile wurden im Praxiseinsatz näher untersucht, indem mit jedem dieser Favoriten bei PPI ein Prototyp entstand. Dadurch ließ sich bei vertretbaren Kosten feststellen, welche Performance erreichbar ist, wie die Benutzerfreundlichkeit ausfällt und ob die Dokumentation ausreicht.

Die Kandidaten

Bei Dojo handelt es sich um eine reine JavaScript-Bibliothek, die seit 2004 entwickelt wird und unter BSD-Lizenz steht. Dojo liefert bereits mehrere vorgefertigte Widgets mit; zu diesen Minianwendungen gehören unter anderem Menüs und Tabs. Die reine JavaScript-Bibliothek erfordert allerdings, dass noch eine serverseitige Technologie, zum Beispiel PHP, ausgewählt werden muss.

Das Google Web Toolkit (GWT) und die Eclipse Rich Ajax Platform (RAP) verfolgen einen komplett anderen Ansatz. Die gesamte Entwicklung findet in Java statt und erzeugt eine Server-Client-Anwendung, die zum Beispiel im Apache Tomcat-Server ausgeführt wird. Der Clou liegt darin, dass der clientseitige Code – eine Mischung aus HTML und JavaScript – vom Compiler automatisch aus dem Java-Code erzeugt wird. Somit muss man sich im besten Fall nicht mit JavaScript und den Tücken der einzelnen Browsern auseinandersetzen.

Das Eclipse-RAP-Projekt existiert seit 2007 und steht unter der Eclipse Public License (EPL). Eclipse RAP arbeitet auf Basis der Desktop-Entwicklungsumgebung Eclipse Rich Client Platform (RCP). Die dort eingesetzten Widgets, beispielsweise Buttons, Listen oder Menüs, lassen sich für die Webanwendung wiederverwenden. Eine Besonderheit von Eclipse RAP ist, dass sich die Webanwendung mit relativ geringem Aufwand in eine Desktopanwendung überführen lässt.

Das Google Web Toolkit befindet sich seit 2006 in der Entwicklung und verwendet die Apache 2.0-Lizenz. Auch GWT wird mit einer Reihe von Widgets ausgeliefert. Die Besonderheit ist, dass bei der Übersetzung in Programm-Code für jede Browser- und Sprachkombination eine eigene Clientversion erzeugt wird. Vorteil: Die Anwendung lädt schneller, weil der Anwender nur geringe Datenmengen herunterladen muss. Google setzt das GWT auch für sein neues Produkt Google Wave ein.

Die Entscheidung fiel auf Google

Beim Dojo-Prototyp zeigt sich schnell, dass eine gut skalierbare Enterprise-Anwendung mit einem JavaScript-Framework deutlich langsamer und teurer umzusetzen ist als mit einer Komplettlösung wie GWT. Natürlich haben JavaScript-Frameworks ihre Daseinsberechtigung und finden in anderen Bereichen ihren Verwendungszweck. Allerdings ließen sich sowohl mit Eclipse RAP als auch mit GWT in nur wenigen Tagen vielversprechende Prototypen erstellen, die problemlos in der Elicpse-Entwicklungsumgebung innerhalb eines größeren Teams komplett in Java entstanden.

GWT und Eclipse RAP sind sich sehr ähnlich. Das erschwerte die Entscheidung für eines der beiden Frameworks. Für unser Produkt Rating Flex haben wir uns für das Google Web Toolkit entschieden. Die Gründe: Die Community rund um GWT ist etwas größer und aktiver, die Möglichkeit zur Umwandlung als Desktopanwendung brauchen wir nicht, und das Framework wird von einem Unternehmen gepflegt und entwickelt, das außerordentliche Erfahrung mit Webanwendungen hat.

Was GWT kann – und was nicht

Neben den bereits genannten Vorteilen lassen sich in jede GWT-Anwendung auch nativer JavaScript-Code und JavaScript-Frameworks einbinden – für den Fall, dass die Grenzen von GWT erreicht werden. Dadurch geht allerdings die automatische Optimierung für die verschiedenen Browser verloren. Ein weiterer Vorteil von GWT: Alle Oberflächenobjekte lassen sich als Widget auch in anderen GWT-Projekten wiederverwenden, und trotz AJAX funktionieren der Zurück-Button des Browsers und die Browserhistorie.

Für die Server-Client-Kommunikation stellt GWT die Austauschformate XML, JSON und GWT RPC zur Verfügung. Bei GWT RPC definiert man die aufzurufenden Servermethoden über eine Schnittstelle. GWT serialisiert beim Aufruf die Argumente automatisch und löst die entsprechenden Methoden aus. So lassen sich auch das Prinzip der Polymorphie sowie Exceptions über die Server-Client-Kommunikation umsetzen. Durch die Unterstützung von JUnit-Tests ermöglicht GWT eine angemessene Qualitätssicherung.

Ein in der Praxis bedeutender Nachteil ist die Handhabung von Events. Diese werden clientseitig ausgeführt. Gleichzeitig treten gelegentlich Probleme durch die unterschiedlichen Browser auf. Zum Teil kommen sich Events gegenseitig in die Quere, was sich nur schwer durch den Debugger nachvollziehen lässt. Zudem generiert das Google Web Toolkit den HTML-Code der Anwendung automatisch. Der Aufbau ist dadurch unübersichtlicher, als wenn die Seite "per Hand" gebaut wird. Das macht es aufwendiger, eine Anwendung mit CSS einheitlich für alle Browser zu gestalten. Darüber hinaus gibt es keine automatische Behandlung von Window-Rezise-Events.

Insgesamt hat der tägliche Einsatz von GWT im Umfeld der Entwicklung von Unternehmenssoftware gezeigt, dass das Google Web Toolkit eine professionelle Open-Source-Lösung ist, die im kurzlebigen Softwaremarkt eine Zukunft haben dürfte. Einige seiner Schwächen wurden in der kürzlich veröffentlichen Version 2.0 von GWT behoben. (odi)