Wer sich ernsthaft mit RIAs beschäftigt, kommt derzeit um Flex nicht herum: Das Flex 3 SDK von Adobe ist nach wie vor der Platzhirsch und ist auch den Konkurrenten Silverlight aus dem Hause Microsoft und JavaFX von Sun um einiges voraus. Insbesondere das Programmiermodell von Flex ist für Java-Entwickler attraktiv und mit BlazeDS stellt Adobe eine Open-Source-Java-EE-Messaging-Lösung bereit, um Flex-Clients an Java-EE-Backends anzubinden. Das fehlende Glied war bisher eine "runde" Anbindung an Spring. Mit dem neu erschienenen Spring-BlazeDS-Integration-Projekt wurde diese Lücke nun geschlossen.
Seit der Veröffentlichung des Flex 3 SDKs als quelloffene Software im Februar 2008 erfreut sich das Flex-Framework zunehmender Beliebtheit, wenn es um die Realisierung von Rich-Internet-Anwendungen geht. Wohlwollend hat die anfangs skeptische Community zur Kenntnis genommen, dass Adobe es mit seiner Open-Source-Strategie offensichtlich ernst meint. Mittlerweile ist die Entwicklergemeinde in den einschlägigen Open Source Communities wie Sourceforge und Google Code fleißig damit beschäftigt, das SDK zu erweitern oder neue Integrationsmöglichkeiten mit anderen Technologien zu entwickeln. Eine der interessantesten Neuigkeiten in dieser Hinsicht war die im Dezember 2008 veröffentlichte Ankündigung von Springsource über den ersten Meilenstein des Spring-BlazeDS-Integration-Projekts, das eine einfache Anbindung von Flex-Clients an Spring verspricht. Zunächst aber ein kurzer Blick auf Flex und BlazeDS.
Flex
Flex (oder genau genommen das Flex SDK) stellt ein Programmiermodell und verschiedene Tools bereit, um RIAs zu erstellen und zu kompilieren. Das Modell besteht dabei aus einem deklarativen XML-Namespace (MXML) und der objektorientierten, strikt typisierten Programmiersprache ActionScript 3, die auf dem ECMAScript-262-Edition-4-Entwurf basiert. Während mit MXML das eher statische Layout einer Flex-Anwendung beschrieben wird, codiert man clientseitige Logik wie Validierung oder komplexe Datenfilterung in ActionScript 3. Neben den typischen UI-Komponenten wie Button-, TextInput-, oder List-Controls stellt das Flex-Framework auch eine Vielzahl an nicht visuellen Klassen wie clientseitigen Proxies für den Aufruf von entfernten Web Services oder XML-RPC-Endpunkten zur Verfügung.
Mit dem Kommandozeilen-Compiler mxmlc schließlich wird der Quellcode in eine SWF-Datei kompiliert und kann dann auf einem Webserver deployt werden. Wer übrigens vor der Kommandozeile zurückschreckt und die Annehmlichkeiten einer IDE bei der Entwicklung nicht missen möchte, kann auf den Eclipse-basierten Flex Builder 3 zurückgreifen, der eine nahtlose Integration mit dem SDK und dem Framework bietet.
Um die Flex-Anwendung ausführen zu können, wird als Laufzeitumgebung ein Flash Player benötigt, der mindestens in der Version 9 auf dem Clientrechner installiert sein muss. Die SWF-Datei wird dann in der Regel durch den Browser auf den Rechner heruntergeladen und über das Flash Player Plug-in (bzw. ActiveX Control im IE) ausgeführt. Ein JIT-Compiler sorgt für das Extra an Performance auf dem Zielsystem. Die aktuelle Version 10 des Flash Players ist für Windows, Mac OS X sowie Linux verfügbar. Die Solaris-Version befindet sich derzeit in einem Public-Beta-Stadium.
Flex und SOA
Während das Flex-Framework über die clientseitigen Serviceklassen mx.rpc.http.HTTPService und mx.rpc.soap.WebService einen einfach zu realisierenden Zugriff auf entfernte HTTP-basierte Dienste wie XML-RPC-Endpunkte oder SOAP Web Service ermöglicht, so stellt sich in der Praxis schnell ein wesentliches Manko dieses Ansatzes heraus: Die vom Flex-Client zur Laufzeit erhaltenen Daten sind nur bedingt typisiert und müssen in der Regel manuell über ActionScript geparst und in eine typisierte Form gebracht werden. Die aus der Java-Welt bekannte vielfältige Unterstützung durch entsprechende Tools oder Stub-Generatoren vermisst man in der aktuellen Version von Flex schmerzlich.
Zwar kann Flex Builder 3 mit einem auf Axis basierenden "WSDL Import Wizard" aufwarten, der anhand einer WSDL den ActionScript-Stub-Code generiert und so eine strikt typisierte Kommunikation ermöglicht, das Ergebnis erfordert in den meisten Fällen aber manuelle Überarbeitung bzw. ist oftmals schlichtweg nicht brauchbar. Somit stellt XML-RPC und SOAP zwar eine einfache Möglichkeit dar, Flex an vorhandene Services anzubinden, in der Praxis ist man aber gut beraten, auf eine andere Form der Datenübertragung und -serialisierung auszuweichen.
