Blog RIA.do.be

Depuis l’annonce faite par Adobe en décembre de passer une partie de LiveCycle DataServices (anciennement Flex DataServices ou FDS) en open source et gratuit sous le nom de BlazeDS, de nombreux clients nous interrogent sur leur différence.

Facteur aggravant, en cherchant sur la toile, on trouve souvent le schéma ci-dessous à gauche. Même s’il n’est pas faux, il occulte un aspect clé de l’offre LCDS : la montée en charge et les performances du protocole RTMP sur toute la partie remoting. A droite, le même schéma, mention faite des deux protocoles utilisés.

Les protocoles

LCDS dispose de plusieurs techniques et protocoles pour délivrer ses services : RTMP, RTMPT (tunneling rtmp sur HTTP), AMF/HTTP (en polling simple ou long), text/HTTP. Lors du déploiement d’un service LCDS/BlazeDS, on paramètre une liste ordonnée par préférence. Le serveur peut se rabattre sur un protocole de second choix si le premier n’est pas opérationnel. BlazeDS partage ce mécanisme mais il est confiné au protocole HTTP.

Temps de réponse et montée en charge

Avec LCDS, le protocole RTMP peut être utilisé pour maintenir une connexion par socket en duplex. Si l’on fait abstraction du temps de transport sur le réseau, on peut risquer un “temps-réel”. La déconnexion d’un client est immédiatement connue du serveur, celui-ci peut donc optimiser, entre autres choses, l’allocation de ses ressources. C’est ce protocole qui est de préférence utilisé par le bloc ‘Data Management’, notamment pour la synchronisation des données entre clients (la mise en place d’un système de notification et de mises à jour automatisé entre tiers clients est loin d’être triviale).
Ce mécanisme permet d’atteindre plusieurs milliers de connexions simultanées car le serveur de socket RTMP est beaucoup moins gourmant que son compère du serveur web http : il a été implémenté en utilisant Java NIO, présent depuis le Jdk1.4, rompant avec les accès bloquants et le modèle 1 socket / 1 thread.

Conclusion

BlazeDS est parfait pour la multitude de projets d’intégration java que l’on peut avoir à réaliser sur de petites échelles de montée en charge. Si tôt que l’on souhaitera une meilleure résistance sur la volumétrie, des temps de réponses proches du temps-réel, des fonctionalités supplémentaires comme la mise à jour instantanée de postes clients ou encore la génération de PDF, il vaudra mieux se tourner vers LCDS / RTMP.

Pour finir, Christophe Conraets présentera le futur de LCDS/blazeDS durant l’évènement Flex 360 à Atlanta, les 26-27 février 2008.

Resources (en anglais) :

http://labs.adobe.com/technologies/blazeds/
http://www.adobe.com/fr/products/flex/dataservices/
http://www.dcooper.org/blog/… - détail des channels utilisés par blazeds et la prochaine version de LCDS
http://sujitreddyg.wordpress.com/…/blazeds-and-lcds-feature-difference/
http://en.wikipedia.org/wiki/Comet - Comet et les techniques de polling
http://cometdaily.com/ - site d’experts Comet

http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf (Pdf)

http://jcp.org/en/jsr/detail?id=315 - JSR 315: Java TM Servlet 3.0 Specification
http://java.sun.com/developer/technicalArticles/releases/nio/

Articles relatifs

• LiveCycle DataServices 2.6beta et autres nouveautés (0)
• Digest estival de news Adobe (1)
• BlazeDS / Adobe frappe encore très fort (0)
• Utiliser le framework Cairngorm pour Flex 2(3/4) (1)
• Utiliser le framework Cairngorm pour Flex 2 (4/4) : Remarques et Add-On (6)