Im letzen Blogpost ging es um die zunehmende Bedeutung von Java-Script und Ajax im Bereich der Rich Internet Application Technologien. Bereits mehrfach bemängelt wurde das Entwicklungsmodell und der Toolsupport für Java-Script. Es gibt zwar mit Netbeans, Aptana u.v.a.m. Tools, die die Programmierung mit Java-Script unterstützen, sie sind aber von ihrem Featurereichtum meilenweit von dem entfernt, was bei anderen Sprachen möglich ist. Ein Grund liegt auch in der Sprache, die viele Dinge, die Integrated Development Environments (IDE) möglich machen, unterbindet. Und letztlich – ganz subjektiv – macht die Programmierung mit Java-Script nicht sonderlich viel Spaß und die vielen Frameworks lindern diese Not nur teilweise.
Google hat schon sehr früh das Potential von Ajax erkannt und gleichzeitig die oben genannten Problempunkte adressiert und eine Möglichkeit geschaffen, Ajax Anwendungen zu erzeugen, die Ihresgleichen sucht: Das Google Web Toolkit oder kurz GWT. GWT ist mittlerweile in Version 1.6 erschienen und man kann schon seit einiger Zeit von einer ausgereiften Technologie sprechen. Nahezu alle Google Webanwendungen (inklusive von Google Wave) sind mit GWT erstellt worden.
GWT löst die lästige Java-Script Programmierung indem man in einer ausgewachsenen Sprache – namentlich Java – programmiert und dann seine Java Sourcen in eine Ajax Anwendung “kompiliert” (wobei natürlich kein binäres Kompilat entsteht sondern nur hochoptimiertes Java-Script). Durch diesen Geniestreich löst Google die Unzulänglichkeiten von Java-Script, denn es wird ausschließlich in Java programmiert. Zum anderen löst Google die Unterstützung durch Tools, denn es liefert nicht nur ein GWT-PLugin für Eclipse mit, vielmehr sind auch alle anderen für Java gedachten Eclipse-Plugins möglich. Auch weitere Tools aus dem Java Umfeld wie Continious Integration, Code Metrics und Analyse sind möglich. Auch die weiteren Vorteile der Java-Technologie wie die leichte Backend-Integration, die Verfügbarkeit qualifizierter Entwickler und die umfangreichen Bibliotheken dienen dem GWT-Ansatz.
Mit dem GWT muss sich der Web 2.0 Entwickler nicht mit Java-Script beschäftigen, auch nicht mit Cross-Browser-Kompatibilität und den ganzen Folgeproblemen, sondern kann wie gewohnt seine Java-Klassen schreiben und entwickelt so mächtige Anwendungen wie GoogleMail etc.
Anlässlich des zehnten Geburtstags von XML, der sich diese Woche ereignet, einmal ein paar Gedanken zur Rolle von XML und Rich Internet Applications.
XML ist aus RIAs einfach nicht mehr wegzudenken und zwar in zweifacher Hinsicht.
Weiterlesen von ‘RIAs und XML’
Kurzvorstellung
JavaFX Script ist Sun Microsystems Beitrag im Wettbewerb um die beste RIA-Technologie.
JavaFX Script ist eine neu entwickelte Scriptsprache, die auf der Java Virtual Machine (JVM) läuft.
Der Hauptvorteil von JavaFX Script ist, dass es die Verwendung von fortgeschrittenem Swing deutlich vereinfacht, in dem es es eine deklarative Sprache verwendet, um User-Interface-Objekte und Animationen etc. zu erzeugen.
RIAs auf JavaFX Script benötigen ein Java Plugin (in Version 6+) denn letztlich handelt es sich bei dieser Art von RIAs um fortgeschrittene Applets, wenn die Anwendung im Browser läuft. RIAs auf JavaFX Script lassen sich aber auch als Desktop-Anwendung installieren und nutzen, etwa über Java-Webstart. Durch die Einbindung beliebiger Java-Bibliotheken lassen sich eine Vielzahl von Backend-Technologien nutzen. Weiterlesen von ‘RIA-Technologie: JavaFX Script’
Adobe hat heute erklärt, Teile seiner Live Cycle (vormals Flex) Data Services als Open Source zu veröffentlichen. Das neue Produkt erhält den Namen BlazeDS.
Momentan existiert nur eine Betaversion, die finale Version soll Anfang 2008 erscheinen.
BlazeDS wird bei Flex-Remoting benötigt, also wenn eine Flexanwendung auf ein Java Backend zugreift. BlazeDS vereinfachen die Zugriffe auf entfernte Javaklassen drastisch. Im weitern wird bei BlazeDS das Adobe Format AMF verwendet, was eine bis zu zehn mal schnellere Datenübertragung ermöglicht als XML oder SOAP. AMF wird in diesem Zusammenhang auch offiziell dokumentiert. Alternative Lösungen wie AMFPHP oder SabreAMF setzten bisher auf Reverse Engineering und werden von der Öffnung sicherlich profitieren.
Adobe macht aber nur den oben beschriebenen Teil der Flex Data Services / Live Cycle Data Services zu Open Source, andere Bestandteile (Real Time Messaging, PDF Generation etc.) bleiben weiterhin der kommerziellen Version vorbehalten.
Es ist davon auszugehen, dass durch diese Schritte die Verwendung des sehr performanten AMF Formats steigen wird und damit mehr RIAs auf Flexbasis deutlich datenintensiver und performanter werden. Auch können native Java-Backends nun für größere Installationen verwendet werden, ohne gleich in die “Kostenfalle” der Live Cycle Data Services zu laufen.