fle[ks]ray

Der Adobe LiveCycle Dataservice besteht aus vier Komponenten, die hier ausführlich erklärt werden.
Mit dem Service sind Flex Anwendungen in der Lage, die volle Power von Enterprise Serverapplikationen zu nutzen.
• Installation, Proxy Service
• RemoteObject Service

Der Proxy Service erlaubt es, den so genannten Sandkasten, in dem Browseranwendungen laufen zu umgehen.
Webservices werden von der Client Applikation nun über den Umweg des Homeservers und nicht direkt aufgerufen.
Der Flex Data Service, der auf dem Homeserver läuft, (also dem Server, von dem die Flex Applikation aufgerufen wurde) leitet die Anfragen an den Server weiter, auf dem der eigentliche Webservice läuft.

Flex Data Service ist jetzt Livecycle Data Service Express

Adobe hat mit der Veröffentlichung des Flexbuilders 3 beta dem Flex Data Service einen neuen Namen gegeben. Die Serverkomponente des Flex Frameworks nennt sich nun Adobe LiveCycle Data Service.
Zu den schon bekannten Komponenten des Flex Data Service gesellen sich nun die Features des LiveCycle Services, wie Dokumenten- und Formularprocessing. LiveCycle war vorher eine eigenständige Software, die hauptsächlich mittlere und große Firmen als Kunden im Visier hatte.
Die Express Version der Software kann kostenlos von der Adobepage heruntergeladen werden. Im folgenden Artikel sollen die Teile des Service vorgestellt werden, die auch schon im Flex Data Service enthalten waren und eben für Flex Entwickler interessant sind.
Adobe nennt die Software abwechselnd "Flex Data Service" oder "LiveCycle Data Service Express". Beide Begriffe werden hier synonym verwendet.

Der Flex Dataservice kann unter der URL http://www.adobe.com/cfusion/tdrc/index.cfm?product=livecycle_dataservices für unterschiedliche Betriebssysteme heruntergeladen werden. Für den Download muss man sich einen Account bei Adobe einrichten und anschließend mit Email und Passwort einloggen.
Im Folgenden wird die Installation unter Windows und gängigen JEE Servern beschrieben. Grundsätzlich lassen sich zwei Arten der Installation unterscheiden.
Der Flex Dataservice kann als Komplettpaket installiert werden. Diese Variante enthält JRun als Java Server Runtime. Dieses Paket steht als *.exe-Datei zu Verfügung und installiert eine ready to go Version der Adobe Software.
Für den Einsatz in einer Produktionsumgebung kommt eher die Installation als *.war-File auf einem existierenden JEE-Applicationsserver in Frage, da JRun nur als Entwicklungsumgebung kostenlos zu haben ist.

Installation des vorkonfigurierten Komplettpaketes

Ein Doppelklick auf die ausführbare Datei öffnet einen Wizard der durch die Installation führt. Nach dem Bestätigen der Lizenzbestimmungen wird der Benutzer nach einer Seriennummer gefragt. Für die Installation der Expressversion wird dieses Feld frei gelassen. Die Expressversion des Data Service ist voll funktionsfähig und kann auch für kommerzielle Projekte genutzt werden, ist jedoch auf die Nutzung einer CPU beschränkt. Die genauen Bestimmungen zur Nutzung finden sich auf der Adobe Seite.
Anschließend wird das Installationsverzeichnis gewählt (alle weiteren Angaben im Artikel beziehen sich auf das Standard Installationsverzeichnis c:\lcds). Dann hat der User die Wahl, den Dataservice mit integriertem JRun Servlet Container oder als JEE Applikation zu installieren. Als Entwicklungsumgebung ist JRun ausreichend, als Produktionsserver sollte jedoch einer der Standard JEE Applicationserver zum Einsatz kommen. Es erscheinen noch die üblichen Standardabfragen, dann beginnt die Installation.

Nach Beendigung der Installation befindet sich im Verzeichnis c:\lcds ein Unterordner JRun/bin. Wird die im Verzeichniss befindliche jrun.exe ausgeführt, öffnet sich der JRun Launcher, mit der sich der Server starten, restarten und stoppen lässt. Nach Selektieren des default-Eintrages und einem Klick auf den Start Button fährt der Server hoch.
Unter der Adresse http://localhost:8700 kann nun die lokale Instanz von JRun angesprochen werden.

Installation unter einem Java Web Application Server

Die Installation des Flex Data Service unter einem JEE Server ist ebenfalls leicht durchzuführen. Alle *.war Dateien, die sich nach der oben durchgeführten Installation in c:\lcds befinden, laufen ohne Probleme auch in den ensprechenden Deploy Verzeichnissen typischer JEE-Server.
Tomcat: $CATALINA_HOME/webapps
JBoss: $JBOSS_HOME/server/default/deploy
Wird beispielsweise das c:\lcds\samples.war in das webapps Verzeichniss des Tomcat kopiert, ist nach einem restart/redeploy die Applikation unter localhost:8080/samples zu erreichen.
Gleiches gilt für JBoss und andere JEE konforme Applicationserver. Für eigene Entwicklungen sind die mitgelieferten Anwendungen der Standardinstallation also ein guter Ausgangspunkt.

From the scratch

Soll eine Webanwendung, die den Flex Data Service nutzt, von Grund auf entwickelt werden, sind einige Kleinigkeiten zu beachten.
Im WEB-INF Verzeichniss muss ein Unterordner mit dem Namen flex existieren, der sämtliche Konfigurationsdateien des Dataservice enthält. Auch hier empfiehlt es sich, den Ordner aus einer Beispielanwendung zu kopieren.
Im WEB-INF/lib Verzeichniss müssen alle nötigen flex-*.jar Dateien vorhanden sein. Auch diese kopiert man am besten aus einer Beispielanwendung. Dann müssen noch sämtliche Eintragungen der web.xml, die sich im flex/WEB-INF Verszeichnis befindet, in die schon bestehende web.xml übernommen werden.
Ebenfalls eine gute Grundlage für Eigenentwicklungen ist der mit dem Dataservice vorkonfigurierte Tomcat, der auf der Adobe Seite unter http://www.adobe.com/devnet/flex/articles/java_testdrive.html heruntergeladen werden kann.

Der Flash Sandkasten

Jedem Flash und Java Applet Entwickler ist die Thematik der sogenannten Sandkastenumgebung der Standardbrowser bekannt. Applikationen, die über das Internet aufgerufen werden, haben nur eingeschränkte Zugriffsrechte auf dem Clientrechner.
Solche Anwendungen können nicht auf das lokale Dateisystem zugreifen und nur uneingeschränkt auf Resourcen des Servers zugreifen, von dem sie geladen wurden.
Mit der crossdomain.xml kann diese Einschränkung zwar umgangen werden, dafür braucht der Entwickler jedoch Zugriff auf den Server, auf dem die benötigten Resourcen installiert sind. Das ist jedoch in den seltensten Fällen so.
Ohne Proxy Service können die Services mx.rpc.http.HttpService und der mx.rpc.soap.WebService mit dem Parameter url nur Daten von dem Server abrufen, von dem sie selbst geladen wurden.
Mit dem Proxy können die Services auch auf Resourcen anderer Server zugreifen. Die Clientanwendung merkt davon nichts. Der Request wird nach wie vor an den eigenen Server gestellt. Die Proxy Kompenente des LiveCycle Dataservice nimmt die Anfrage entgegen und leitet sie an den entsprechenden Server im Netz weiter. Dafür muss die Eigenschaft useProxy auf true gesetzt werden, nur dann spricht der Proxy Service auch an und liest gegebenenfalls die Eigenschaft destination aus.

Der url Parameter

Im folgenden gehen wir von einer Applikation mit dem Namen myApplication aus, die einen HTTPService enthält. Der Sourcecode sieht vereinfacht so aus:

   
                   <?xml version="1.0" encoding="utf-8"?>
                       <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"">
                           <!-- ............ -->
                               <mx:HTTPService id="myService" url="data/myDataFile.xml" />
                           <!-- ............. -->
                       </mx:Application>
                       

Das Programm lädt die Daten vom eigenem Server, das Verzeichnis "data" befindet sich dabei auf der gleichen Ebene wie das swf-File der Flexapplikation.

Im url Parameter kann auch eine absolute Adresse angegeben werden. Vorausgesetzt die Applikation wird über die URL http://localhost/myApplication aufgerufen, kann auch dieser Code verwendet werden.
<mx:HTTPService id="myService" url="http://localhost/data/myDataFile.xml" />

Das funktioniert nicht und löst einen Cross Domain Security Error aus!
<mx:HTTPService id="myService" url="http://127.0.0.1/data/myDataFile.xml" />

Die Default Destination

Unter einer Destination ist der Endpunkt einer Kommunikationskette zu verstehen. Auch in der Webservice Entwicklung wird der Begriff Endpunkt (natürlich in englisch -> endpoint ) verwendet. Damit eine bestimmte Ressource über den Proxy Service angesprochen werden kann, müssen in der proxy-config.xml einige Einstellungen vorgenommen werden. Die proxy-config.xml sieht im Normalfall so aus.

 Die proxy-config.xml
            
     <?xml version="1.0" encoding="UTF-8"?>

     <service id="proxy-service"   
         class="flex.messaging.services.HTTPProxyService" 
         messageTypes="flex.messaging.messages.HTTPMessage,flex.messaging.messages.SOAPMessage">
		 
         <properties>
             <connection-manager>
                 <max-total-connections>100</max-total-connections>
                 <default-max-connections-per-host>2</default-max-connections-per-host> 
             </connection-manager>
        </properties>
        
        <adapters>
            <adapter-definition id="http-proxy" 
                class="flex.messaging.services.http.HTTPProxyAdapter"
                default="true" />
            <adapter-definition id="soap-proxy" 
                class="flex.messaging.services.http.SOAPProxyAdapter" /> 
       </adapters>
         
       <default-channels>        
           <channel ref="my-http" /> 
           <channel ref="my-amf" /> 
       </default-channels>
         
       <destination id="DefaultHTTP">
           <!-- Einträge der Default Remoteserver -->
       </destination>
   </service>
    

Standardmäßig ist in der proxy-config.xml bereits ein Eintrag für die Default Destination vorhanden, dieser ist jedoch leer.
Um Proxy Zugriffe über den Flex Data Service zu ermöglichen, muss der Eintrag erweitert werden.

 Ergänzung der Destination
                
               <destination id="DefaultHTTP">
                   <properties>
                       <dynamic-url>http://127.0.0.1:8700/*</dynamic-url>     
                   </properties>
               </destination>
			

Der Stern am Ende der URL ermöglicht dem Flex Client auf jeden möglichen Webservice des (scheinbar) entfernten Servers zuzugreifen.


Nun muss noch im HTTPService die useProxy Eigenschaft auf true gesetzt werden.

          
          <mx:HTTPService
                 id="myService" 
                 url="http://127.0.0.1/data/myDataFile.xml"
                 useProxy="true" />
                

Der HTTPService ist nun in Lage die Resource myDataFile.xml über den Umweg des Proxy Service vom (vermeintlich) entfernten Server abzurufen.

Die Named Destination

Mit der named Destination entscheidet der Client nicht mehr selbst, welche URL, von welchen Remoteserver aufgerufen wird. Dem Client ist lediglich die Id des Services bekannt. Den Proxy Service mit der richtigen URL zu spezifizieren, liegt nun in der Hand der Servers. Dadurch wird die Sicherheit des Systems beachtlich erhöht. Anwendungen auf Clientseite können nicht mal eben verschiedene URL's ausprobieren.

 Der geanderte Eintrag in der proxy-config.xml
            
           <destination id="myProxyService">
               <properties>
                    <url>http://127.0.0.1:8700/flex/data/myService.xml</url> 
               </properties>
           </destination>
           

Statt einer URL wird im HTTPService jetzt der Parameter destination verwendet. Die Destination, die im HTTPService angegeben wird, muss mit der Destination Id in der proxy-config.xml übereinstimmen.

 Im HTTPService wird die enfernte Ressource uber die Id aufgerufen
           
            <mx:HTTPService
                 id="myService" 
                 destination="myProxyService"
                 useProxy="true" />