Flex Data Service Tomcat

Um erste erfolgreiche Gehversuche mit dem Flex Data Service zu unternehmen, sollte man sich den FDS-Tomcat von der Adobe Website herunterladen. Dabei handelt es sich um einen Tomcat in der Version 5.5.20, auf dem der Flex Data Service mit allen Abhängigkeiten vorinstalliert ist.

Zu diesen Abhängigkeiten gehört unter anderem JOTM, eine JTA-Implementation. Nimmt man den Flex Data Service auf eigene Faust auf dem Tomcat oder einen anderen Webapplication-Server in Betrieb, kann man die Installation von JOTM leicht vergessen. Das resultiert dann in einem: "Unable to access UserTransaction in DataService" error.

Außerdem sind noch Spring 2.0, Hibernate 3.2 und HSQLDB 1.8 auf dem vorkonfigurierten Tomcat installiert. Diese Pakete sind nicht nötig für den Betrieb des Flex Data Service, einige der mit mitgelieferten Anwendungsbeispiele basieren jedoch auf diesen Technologien.

Der FDS-Tomcat wird, wie erwartet, über das startup.bat bzw. startup.sh Skript gestartet. Über http://localhost:8600 kann nun auf die mitgelieferten Beispielanwendungen zugegriffen werden.
Vorinstalliert sind zehn kleinere Anwendungen, die selten aus mehr als drei Quelldateien bestehen und einen wirklich guten Überblick über die Facetten des Flex Data Service liefern. Die Minianwendungen geben Einblick in die Verwendung von Web Services, Java RPC, Data Push und in andere Implementierungsansätze.
Zwei komplexere Anwendungen zeigen den Einsatz von Hibernate und Spring zusammen mit dem Flex Data Service.

Zuletzt gibt es noch ein Tutorial für Java Entwickler, die erste eigene Schritte mit dem Flex Data Service von Adobe unternehmen wollen.

„Zusammengebaut“ wurde der FDS-Tomcat von Christophe Coenraets, der auch an der Entwicklung JRun beteiligt war und nun bei Adobe arbeitet.

Flex DataManagement Service und Hibernate

Um Hibernate und Adobe Flex in einfacher Weise miteinander zu verbinden, empfiehlt es sich, auf den DataManagement Service des LiveCycle Data Service zurückzugreifen. Damit lassen sich in Java entwickelte Klassen eins zu eins in eine Flex Anwendung übernehmen. Alle Änderungen an Objekten im Flex Client werden direkt auf die Java Objekte übertragen.

Wird der DataManagement Service in Verbindung mit Hibernate verwendet, ist es nicht einmal nötig DataAccess Klassen zu entwickeln. Alle Create-, Update- und Delete-Operationen werden direkt auf die Java Objekte angewendet (hinter den Kulissen führt die Klasse flex.data.adapters.JavaAdapter des DataManagement Service die CRUD Operationen aus).
Diese Vorgehensweise vereinfacht den Entwicklungsaufwand enorm. Die Programmierung von DAO's entfällt.

Die Verwendung des DataManagement Service bringt aber auch Nachteile mit sich. Der Service verwendet das Real Time Messaging Protokol, das im Normalfall Port: 2038 verwendet. Aufrufe über diesen Port werden an den meisten Firewalls scheitern.
Der Einsatz beschränkt sich deshalb mehr oder weniger auf Intranet Anwendungen. Soll Hibernate in klassischen Internet Applikationen eingesetzt werden, kommt man nicht umhin, Data Access Klassen zu implementieren und deren Interface per WebService im Netz zur Verfügung zu stellen.

Weitere Informationen zur Entwicklung einer Flex Anwendung unter Verwendung von Hibernate und dem DataManagement Service finden sich auf http://fleksray.org/flex_datamanagement_service_hibernate.html

Channel.Connect.Failed error undefined url: rtmp://localhost:2038

Ist der Data Management Service des Flex LiveCycle Services (unter Verwendung des rtmp Channels) für den Client nicht erreichbar, erscheint die Fehlermeldung: undefined url: rtmp://localhost.
Im Klartext heisst das, daß der Flex Data Service den Channel für das Real Time Messaging Protokoll nicht initialisiert hat.
Die Ursachen dafür können vielfältig sein. Zuerst sollte versucht werden, die URL localhost:[port] im Browser aufzurufen. Das "rtmp" am Anfang lässt man weg, da der Browser das Real Time Messaging Protokoll nicht kennt. Hinter localhost muss der entsprechende Port angegeben werden, meist ist das 2038. Ist man nicht sicher, hilft ein Blick in die [SERVERROOT]/webapps/[CONTEXT]/WEB-INF/flex/services-config.xml Datei. In der Channeldeklartion my-rtmp ist der tatsächlich verwendete Port zu finden.
Bringt der Browser nach Eingabe der URL localhost:2038 innerhalb kurzer Zeit die Fehlermeldung "Seite nicht erreichbar" o.ä ist der Real Time Messaging Service down. Versucht der Browser endlos lange eine Seite zu laden, ist der RTMP Channel in in Betrieb (Die Seite bleibt natürlich leer).
Der erste Fall ist wahrscheinlicher (sonst würde ja die Fehlermeldung nicht kommen). Die Ursachen können von Server zu Server unterschiedlich sein und werden nicht immer mit einer Exception im Logfile quittiert. In Verbindung mit Hibernate kann der Fehler in der Deklaration der Hibernate Destination in der data-management-config.xml die Ursache sein . Wird Hibernate nicht initialisiert kann das dazu führen, dass der RTMP Service nicht gestartet wird.
Für die weitere Fehlersuche lohnt es sich, den FDS-Tomcat von Adobe herunterzuladen.
http://www.adobe.com/devnet/flex/articles/java_testdrive.html
Probeweise sollte versucht werden auf diesem Server die Problemapplikation zu deployen. Ebenfalls zu empfehlen ist in Blick in die [SERVERROOT]/webapps/[CONTEXT]/WEB-INF/lib und [SERVERROOT]/common/lib Verzeichnisse des Adobe Tomcat zu werfen. Fehlen in der eigenen Serverinstallation Jar Files, die im FDS-Tomcat vorhanden sind, kann das ebenfalls zu der Fehlermeldung: Channel.Connect.Failed error undefined url: rtmp://localhost:2038 führen.

Der Remote Object Service in Flex

Was unterscheidet den Remote Object Service vom HTTPService oder dem WebService?
Wie auch der HTTPService und der WebService greift der Remote Object Service über das HTTP Protokoll auf die Ressourcen des Servers zu.
Im Gegensatz zu den erst genannten Services benutzt der RemoteObject Service aber nicht das auf Text basierende XML Format für den Informationsaustausch, sondern das proprietäre AMF (Action Message Format). Dieses codiert die auszutauschenden Informationen binär, die gesendete Nachricht wird dadurch wesentlich kleiner und kann schneller übertragen werden.
Java Entwickler mag diese Technik an die RMI API erinnern und der Vergleich ist durchaus angebracht. RMI nutzt jedoch statt des HTTP Protokolls (Port 80) ein eigenes Übertragungsprotokoll, scheitert damit an den meisten Firewalls und macht deshalb nur in firmeninternen (oder anderen geschlossenen) Umgebungen Sinn. Im Gegensatz dazu kann der Remote Object Service ohne Einschränkungen auch im Internet verwendet werden.