Développement Flex - Air - Java - RIA - Mashups Flex
Contrairement à AMFPHP, Zend AMF n’offre pas la possibilité de compresser en gzip les réponses, ce qui peut être très embêtant dans le cas de requêtes renvoyant un grand volume de données (il peut exister un facteur 100 entre une réponse standard et une réponse compressée).
Cette fonctionnalité peut facilement être ajoutée en utilisant gzcompress ou gzencode.
echo "x1fx8bx08x00x00x00x00x00".gzcompress($zendAmfServer->handle());
Si l’intérêt d’utiliser BlazeDS pour faire communiquer une application Flex avec des services distants n’est plus à prouver, il en résulte souvent un manque d’interopérabilité des services.
Dans le cas d’une application qui pourrait avoir des interfaces multiples (web, ajax, swing etc …) il est alors préférable d’utiliser des services de type SOAP ou REST. On peut par exemple imaginer une application Air et une application pour iPhone développée en Cocoa qui accèdent au même applicatif serveur et qui partagent la même session hibernate. Une solution simple serait alors de dupliquer les classes de services, mais cela engendrera par exemple la duplication de la connexion à la base de donnée. L’utilisation de Spring peut alors grandement nous faciliter la tâche, en effet il est possible de partager un contexte entre servlet et donc de n’accéder qu’à une seule instance que ce soit par Axis2 ou BlazeDS.
[Lire la suite...]
Dans la plupart des tutoriaux présents sur le net Zend AMF est utilisé pour un nombre très restreint de services et de classes. Les performances pour des petits projets restent acceptables cependant pour des projets nécessitant le chargement de beaucoup de VOs et de services les temps de réponse chutent considérablement. Ceci est tout simplement du au fait qu’à chaque requête le framework refait l’introspection des services et réimporte toutes les class.
Pour remédier à ce problème, nous avons modifié Zend AMF afin qu’il soit derrière une socket UNIX, Flex se connecte donc au enpoint qui va envoyer la requête à la class Server de Zend à travers la socket. Le endpoint attend une réponse du Server et affiche le résultat. Il n’y a donc plus d’introspection, une seule et même instance de l’AMF Server est utilisée.
Grâce à cette technique nous avons réussi à obtenir des gains de performance allant de 2000 à 3500 % , les temps de réponse sur des gros projets pouvant être divisés par plus de 30. (17 millisecondes en local pour récupérer 300 enregistrements dans un projet qui compte une trentaine de class). Des temps inférieurs à ceux qu’on enregistre avec BlazeDS et largement inférieurs à ceux enregistrés avec AMFPHP !!
On utilise déjà cette solution sur plusieurs projets et le gain côté utilisateur est assez bluffant. Bien évidemment cette solution ne fonctionne pas sur les serveurs mutualisés mais on trouve aujourd’hui des serveurs virtualisés très bon marché.
Peut être vous est déjà t’il arrivé d’avoir une VBox placée avec des contraintes du style Bottom + Top et/ou Left + Right, et que cette VBox contienne des éléments plus grands que la largeur maximum de ce conteneur. Ce qui devrait se passer logiquement, c’est qu’il devrait apparaitres des scrollbars. Et bien que néni, alors qu’avec un Canvas ou autre conteneur, il n’y a pas de problèmes, avec une VBox et HBox, il faut ruser pour pouvoir arriver à ses fins.
Comme l’illustre l’exemple suivant (les sources sont accessibles via un double click sur l’application), l’idée est d’englober ce conteneur par un autre du type « Canvas », et d’appliquer à cet autre conteneur les contraintes. Il suffit alors de laisser la VBox à 100% en width et height, et tout rentre dans l’ordre.
Commentaires