Vor einiger Zeit sind haben wir ein größeres Projekt von WebORB auf RubyAMF umgebaut. Wir hatten die Anwendung zuerst mit WebORB aufgebaut, da das WebORB besser gepflegt schien und RubyAMF nicht mehr weiter entwickelt wird (jedenfalls nicht vom ursprünglichen Entwickler und nicht momentan, wer weis was die Zukunft bringt). Doch mit der Zeit stellten wir fest, dass WebORB seeehr langsam ist und ausserdem sehr speicherhungrig. Wir haben ein System mit mehreren Mongrel-Instanzen laufen, dass von einem monit überwacht wird.

Zur WebORB-Zeit hatten wir annähernd jeden Tag einen Mongrel-Neustart, da der Speicherbedarf zu groß geworden war. Durch den Umstieg auf RubyAMF hatten wir jetzt seit langem keinen Neustart mehr benötigt. Es scheint also, als wäre irgendwo in WebORB ein Speicherleck, dass schließlich die Mongrels volllaufen lässt. Ausserdem ist RubyAMF ca. 10mal schneller, was die Requests/sekunde an geht.

Ein weiterer schöner Vorteil von RubyAMF ist, dass es eindeutig mehr Ruby ist. Die Services die man mit WebORB schreibt sind im Stil von Java-Webservices aufgebaut, man hat einen eigenen Ordner “services” im Rails-Project in dem dann die Services zu finden sind. Die RubyAMF-Services sind aber normale Controller, die von ApplicationController abgeleitet sind, man kann Filter verwenden, sogar wieder logger.debug u.ä. was bei WebORB nur über Umwege (RAILS_LOGGER_DEFAULT.debug) möglich war. Die Parameter von Flex kommen jetzt als Hash (z.B. params[0][:username]) herein und können so schön weiterverwendet werden. Selbst ganze Objekte können so im Parameter-Hash übergeben werden: params[0][:user_object]

Insgesamt scheint mir RubyAMF eine sehr gute Wahl gewesen zu sein und ich würde ich freuen wenn jemand noch weitere Projekte für uns hat, die wir mit RubyAMF umsetzen können.

Wir sind also immer auf der Suche nach neuen Flex/Rails Projekten!

Durch die Möglichkeiten des ClassMappings haben wir ausserdem die Möglichkeit RubyObjekte zwischen Flex und RoR hin- und herzuschicken, anstatt POST-Variablen oder xml-Daten, was doch alles sehr vereinfacht. Ein Beispiel:

def updateUserData(user_object)
  user_object.save
end

Diese Funktion speichert die persönlichen Daten eines Users ab. Das interessante daran ist, dass wir nicht etwas einen Block an Variablen erhalten (den wir dann über params[...] speichern müssten), sondern wir erhalten von der Flex-Seite ein User-Objekt, welches wir auch sofort speichern können und können genauso einfach Objekte (die über das Classmapping definiert wurden) zurückschicken.

Was dabei herauskommt sieht man auf www.ligx.de