Remote Object Service in Flex

» 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.

Das POJO auf dem Tomcat

Um den Remote Object Service zu verwenden, muss zunächst ein Service Objekt in Java implementiert werden, welches die auf dem Client benötigten Methoden zur Verfügung stellt. Die Methoden, die der Client später verwenden soll, müssen als public deklariert werden. Die Klasse muss sich zudem im CLASSPATH des Flex Data Service befinden und einen leeren Konstruktor haben. Eine simple Testanwendung könnte wie folgt aussehen:

 Die Service Klasse auf dem Tomcat
      
         public class RemoteObjectService {
      
              public RemoteObjectService() {}
           
              public String sayHello() {
                  return "Hallo Flexwelt";
              }
         }
         

Bekanntmachen der Klasse

Damit der Flex Data Service die erzeugte Klasse als RemoteObject erkennt, muss diese in der remote-config.xml bekannt gemacht werden. Die remote-config.xml befindet sich, genau wie die proxy-config.xml, im Verzeichnis WEB-INF/flex unterhalb des Context-Root.
Für die erzeugte Service Klasse wird eine neue Destination angelegt. Diese bekommt eine eindeutige Id, die später in der Flex Anwendung zur Referenzierung des entfernten Objektes gebraucht wird. Zusätzlich wird der vollständige Klassenname und der Scope deklariert.

 Auszug aus der remote-config.xml        

         
              
                  org.fleksray.samples.RemoteObjectService
                  application
              
          
          

Scoping

Die drei Möglichkeiten um einen Scope zu definieren sind application, session und request. Diese Varianten den Scope zu definieren sind Java Entwicklern hinreichend bekannt, deshalb hier nur eine kurze Erklärung.
Wird für das RemoteObject der Scope application definiert, wird für jede Serverinstanz nur eine einzige Klasse instantiiert. Alle Anwender der Applikation greifen also auf das gleiche Objekt zu. Im session Scope wird für jeden User ein eigenes Objekt angelegt. Dieser Scope wird deshalb in der Regel für Session Tracking, das Speichern von Warenkörben und Ähnlichem verwendet. Im request Scope wird für jeden HTTP Request ein neues Objekt erzeugt. Dieser Scope erhöht die Rechenlast des Servers empfindlich und sollte nur, wenn unbedingt notwendig angewendet werden.

21. Oktober 2007

» Aufruf entfernter Methoden

Verarbeiten der Daten auf dem Client mit Hilfe der Binding Expressions

Um die vom RemoteObject bereitgestellten Daten zu verarbeiten, stehen dem Entwickler zwei Möglichkeiten zur Verfügung: Binding Expressions und in ActionScript geschriebene Event Handler. Erstere Methode ist einfacher und weniger verbose. Werden dagegen eigene Event Handler benutzt stehen mehr Möglichkeiten zur Verfügung, die Daten zu verarbeiten.
Mit Hilfe der Binding Expression ist das entgegennehmen der Daten recht einfach.

 Auszug aus der MXML Datei die das RemoteObject verwendet
 
               
                
               
               
         

Verwenden der Event Handler

Das RemoteObject löst bei erfolgreicher Datenübertragung ein ResultEvent aus. Lief etwas schief wird ein FaultEvent getriggert. Innerhalb der Event Handler können die Ergebnisse des entfernten Methodenaufrufes vielfältiger gehandhabt werden, als mit den Binding Expressions.

 Die MXML Datei verwendet nun Event Handler
       
     
      
          
               handleResult(ev:ResultEvent):void {
                       _message = ev.result.toString();
                   }

                   private function handleFault(ev:FaultEvent):void {
                       _message = "das ging daneben: "
                       + ev.fault.faultCode + " :: "
                       + ev.fault.faultDetail + " :: "
                       + ev.fault.faultString;
                   }
               ]]>
           

           result="handleResult(event)"
               fault="handleFault(event)"/>
            
           
           
       
        

Ein FaultEvent kann leicht ausgelöst werden, indem im click Handler des Buttons auf eine nicht existierende Methode des RemoteObject zugegriffen wird ( click="{myRemoteObject.sayGoodBye()}")

Result Handler Dispatching im RemoteObject

Wie geht man nun mit Service Objekten um, die dem Client eine ganze Reihe von Methoden zur Verfügung stellen. Im RemoteObject wird im oben gezeigten Beispiel nur einen Result Handler defininiert, der für genau eine Methode zuständig ist..
Ein erster, einfacher Ansatz wäre, im Result Handler eine switch-case Anweisung zu schreiben, die anhand des übergebenen Events die aufzurufende Methode erkennt.
Flex bietet eine elegantere Lösung. Innerhalb des RemoteObject können den Service Methoden jeweils unterschiedliche Result Handler zugeordnet werden.

 Dispatching der Events an unterschiedliche Handler
    
     
      
              
                  handleHelloResult(ev:ResultEvent):void {
                          _message = ev.result.toString();
                      }

                      private function handleDataResult(ev:ResultEvent):void {
                          _data = ev.result as ArrayCollection;
                      }

                      private function handleFault(ev:FaultEvent):void {
                          _message = "das ging daneben: "
                          + ev.fault.faultCode + " :: "
                          + ev.fault.faultDetail + " :: "
                          + ev.fault.faultString;
                      }
              ]]>
          

          
              name="sayHello" result="handleHelloResult(event)" />
              name="getTestData" result="handleDataResult(event)" />
          


          
          click="{myRemoteObject.sayHello()}"/>

          

          
          click="{myRemoteObject.getTestData()}"/>

     

Im gezeigtem Beispiel wird für jede Methode des Service Objektes ein eigener Result Handler deklariert, der Fault Handler wird von allen Methoden gemeinsam benutzt. Es ist auch möglich, jeder Methode einen eigenen Fault Handler zuzuweisen.

31. September 2007

» Übergabe von Argumenten

In den meisten Fällen wird von einer Applikation mehr verlangt, als nur einfache Methoden aufzurufen. In der realen Welt müssen Eingaben des Benutzers an den Server weitergeleitet werden und zu einer entsprechenden Response umgesetzt werden. Die Eingaben werden, wie in bei Html auch, oft über Formulare entgegengenommen und dann verarbeitet.
Das RemoteObject muss also auch in der Lage sein, Argumente zu verarbeiten. Im folgendem Beispiel soll das Service Objekt auf dem Server aus zwei übermittelten Strings ein personalisierte Begrüßung bauen.

 Die Java Klasse übernimmt Argumente
     
          public class AnsweringService {
       
              public AnsweringService() {}
           
              public String sayHello(String title, String name) {
                  return "Hallo " + title +" " + name;
              }
          }
          

In der MXML-Datei werden die Argumente innerhalb des <method> Tags deklariert. Hier können statische Werte oder Binding Expressions verwendet werden.
Das Tag erwartet ein Array mit Parametern. Wie diese Parameter benannt werden, ist unwesentlich. Der Konsistenz halber sollten sie aber wie die Argumente der Java Klasse benannt werden. Entscheidend ist die Reihenfolge der Argumente. Das zuerst deklarierte Element wird als erstes Argument an das Objekt auf dem Server übergeben.
Werden Argumente in der beschriebenen Weise übergeben, muss im Click EventHandler die Methode send() an der Remotemethode aufgerufen werden.

 Senden von Argumenten an das Objekt auf dem Tomcat Server
       
   
   
       
              
                  
                      
                          
                          
                             {myName.text}
                          
                     
                 
             

             
         
             
         
             
                 
                     id="title"
                         dataProvider="['Frau','Herr','Mrs.','Mr.']"/>
                 
                 
                     id="myName"/>
                 
            
         
           click="{myAnsweringObject.sayHello.send()}"/>