Granite DS est un framework qui à l'origine avait été développé pour faciliter la communication entre un serveur JAVA et un client Flex. Le framework utilise le protocole AMF qui offre des optimisations en cas de redondance de données ainsi que de forts taux de compressions. Avec les changements de politique d'Adobe par rapport à Flex, le framework réoriente et agrandit le panel de plate forme supportée.
A l'occasion de la sortie de la version 3.0.1-GA, InfoQ a pu rencontrer William Drai.
InfoQ : Bonjour William. Avant de débuter, pourrais-tu te présenter pour ceux qui ne te connaissent pas encore.
William : Je suis William Draï, un des fondateurs avec Franck Wolff du projet GraniteDS en 2007 et de la société du même nom depuis 2011. Ca va faire bientôt 15 ans que je travaille dans le monde Java, j’ai donc écumé un peu tous les frameworks imaginables depuis les applets, Struts 1 et les EJB.
InfoQ : Granite DS étant dédié à la communication Java / Flex, comment avez-vous vécu le changement de roadmap d'Adobe ?
William : Lorsqu’Adobe a décidé subitement fin 2011 de léguer le projet Flex à la fondation Apache, le framework est enfin devenu indépendant et les solutions serveurs traditionnelles d’Adobe n’ont plus représenté le choix par défaut des utilisateurs. En revanche, cette donation a créé une nette perte de confiance dans l’avenir de cette technologie, quoique le projet Apache Flex soit très actif avec des releases régulières. Même si Flex reste une des meilleures technologies de développement d’applications RIA, et même si AIR est régulièrement récompensé comme un des meilleurs frameworks de développement mobile multi-plateformes (qui n’a pas réellement d’équivalent actuellement), l’évolution rapide du marché nous a incité à accélérer notre ouverture vers d’autres technologies clientes.
InfoQ : Effectivement, quand on regarde vos release notes, depuis la version 3.0, vos efforts ont l'air de se concentrer vers de nouveaux clients. Peux tu nous parler de cette nouvelle orientation ?
William : Nous avions déjà envisagé depuis longtemps des évolutions vers d’autres technologies clientes, en particulier HTML5/JS et le mobile natif. Nous avions en effet deux problèmes avec la technologie Flex dès l’origine : c’était une technologie propriétaire, entièrement contrôlée par Adobe, et nous étions en concurrence avec certaines solutions Adobe comme LCDS.
Nous avons commencé assez tôt à travailler sur des clients mobiles natifs. Ça nous semblait une évolution naturelle pour Android en partant de notre librairie cliente Java existante et nous avons également travaillé en parallèle sur une première version d’un client natif iOS.
A côté de ça on suivait également l’évolution de JavaFX et lorsque JavaFX 2 est sorti, on l’a tout de suite trouvé vraiment bien conçu et agréable à utiliser, une sorte de Flex en Java avec une architecture très propre et qui de plus est directement intégré dans le JRE. Comme on travaillait déjà sur le client Java pour Android, il nous a semblé également intéressant de développer des librairies clientes pour JavaFX. Cela tombe finalement au bon moment puisqu’il semble qu’il commence à y avoir de plus en plus d’intérêt pour cette technologie depuis quelques mois.
Dans le même cadre des clients Android / JavaFX, Franck a également implémenté un nouveau format de sérialisation JMF (présenté ici) inspiré de l’AMF mais encore plus compact et optimisé, et surtout beaucoup plus adapté que l’AMF à de la sérialisation Java vers Java, avec une meilleure gestion des types de données qui évite les conversions de types.
Pour terminer sur Android, on a donc finalisé des librairies clientes quasi complètes, à ceci près que de nombreuses fonctionnalités avancées de GraniteDS comme le data management ou le lazy loading nécessitent un support du data-binding par le framework UI, ce qui n’est pas le cas avec Android. Nous sommes donc en train de travailler sur une implémentation très légère d’un système de data-binding pour Android que nous sortirons prochainement.
InfoQ : Vous n'avez toujours pas envie d'aller vers des clients HTML 5 en proposant une implémentation Javascript ? On commence à voir des projets comme JSON-R qui propose les optimisations du protocole AMF par rapport aux redondances.
William : Nos utilisateurs le demandent régulièrement, mais le monde HTML5/JS est encore très fragmenté, que ce soit au niveau des implémentations des navigateurs ou des frameworks JS. Cela fait finalement assez peu de temps que des frameworks JS performants et complets du style AngularJS sont apparus.
On a déjà fait plusieurs prototypes de sérialisation JS, notamment un en AMF et un avec une extension de JSON qu’on a appelé JSON-R (pour JSON-References, qui est un projet GraniteDS disponible sur notre GitHub), qui permet de gérer les circularités et qui est présenté dans cet article. Pour le moment aucun n’est entièrement satisfaisant et il nous reste encore pas mal de travail avant de pouvoir proposer une solution aboutie.
Comme je l’ai dit un peu avant, GraniteDS est également bien plus qu’un sérialiseur et certaines fonctionnalités de GraniteDS dépendent beaucoup des capacités du framework UI et de la plate forme. L’idée serait donc de développer une version de base de Granite/JS avec un système d’extensions pour différents frameworks comme AngularJS, GWT ou Sencha.
InfoQ : Peux-tu nous parler de la nouvelle version qui communique en UDP coté serveur ?
William : En fait, cette fonctionnalité de messaging UDP nous a été demandée et a été sponsorisée par un client qui travaille dans le trading de devises. Il y a de nombreux cas d’utilisations où on a besoin de recevoir des données en temps réel le plus à jour possible et le plus vite possible mais sans se soucier de perdre des paquets puisqu’ils seront vraisemblablement obsolètes en cas de retransmission : des données de marché pour le trading, des remontées de capteurs pour de la supervision, des positions de personnages pour des jeux en ligne, etc.
Contrairement à TCP qui garantit la transmission des paquets avec des réessais si nécessaire, l’absence de retransmission avec UDP permet également de ne pas engorger le réseau inutilement dans le cas de connexions lentes ou peu fiables (utilisateurs dans des pays ayant des réseaux de mauvaise qualité, clients mobiles, etc.)
Cette nouvelle fonctionnalité permet d’adresser tous ces cas d’utilisation sur les clients qui disposent d’un support UDP : Adobe AIR, Java/JavaFX et Android.
Combiné avec le support du long polling et des websockets, GraniteDS propose maintenant un panel complet de types de transports réseau adaptés à pratiquement tous les cas d’utilisation habituels.
InfoQ : Aujourd'hui, Granite DS fait partie des alternatives sérieuses à la sérialisation JSON. Peux-tu nous dire les cas d'utilisation pour lesquels Granite DS est plus adapté que JSON ?
William : Il est indéniable que JSON a plusieurs avantages majeurs : c’est un format très simple, compact, portable et disponible dans tous les langages et sur toutes les plateformes. Il est donc parfaitement adapté pour des APIs universelles.
Cela dit c’est un format arborescent comme XML qui ne permet pas de transmettre proprement des graphes d’objets avec des redondances ou des circularités, ce qui oblige à passer par des “value objects” intermédiaires dès que le modèle devient un peu complexe (et nos clients ont souvent des modèles très complexes).
Etant un format texte, JSON a également un nombre de types très limité qui implique une perte d’information et des conversions de chaque côté de la sérialisation. Il suffit de voir la complexité du mapping d’un modèle un tant soit peu évolué avec le sérialiseur Jackson par exemple. Ce petit nombre de types qui est un avantage pour une API externe devient un inconvénient dans un cadre plus contrôlé.
C’est là qu’un format de sérialisation tel que le JMF peut s’avérer à la fois plus simple lors du développement et plus performant car binaire et très compact. Le JMF est d’ailleurs également une alternative beaucoup plus performante et flexible à la sérialisation Java standard.
InfoQ : La nouvelle version que vous avez livré en début d'année s'accompagne également d'un changement de licence. Le projet reste open-source mais vous proposez également une nouvelle licence commerciale. Peux-tu nous en parler ?
William : Jusqu’à maintenant, la totalité de GraniteDS était sous licence LGPL 2 et nous avions un modèle commercial basé sur une souscription à une version entreprise de notre plate forme associée à du support. Ce modèle avait deux inconvénients majeurs, pour nous et pour nos clients : il nous obligeait à maintenir deux repositories (l’un pour la version communautaire, l’autre pour la version entreprise) et obligeait nos clients à changer leur version de GraniteDS lorsqu’ils voulaient obtenir du support. Nous avons donc décidé de simplifier notre offre en fusionnant ces deux versions, en passant nos modules avancés en double licence GPL 3 / commerciale et en proposant le support séparément.
Pour résumer, les modules bas niveau de remoting et messaging (y compris websocket) sont toujours en LGPL 2.1, et tous les modules avancés (data management, validation, lazy loading, UDP, etc.) sont en GPL 3.0. La licence GPL a un côté viral qui impose d’adopter une licence open-source compatible dans tout projet qui utilise une librairie GPL (donc de publier les sources de ce projet). Lorsque ce n’est pas souhaitable, ce qui est le cas pour la majorité des projets d’entreprise, nous proposons une licence commerciale qui libère totalement des contraintes de la GPL.
Nous estimons avoir trouvé un compromis tout à fait acceptable en restant complètement open source tout en ne pénalisant pas les utilisateurs commerciaux avec une tarification très raisonnable.
InfoQ : Si j'utilise dans mes projets une version précédente de Granite DS, est-ce que cette nouvelle politique de licence s'applique également ?
William : On ne peut sans doute pas modifier les licences rétroactivement. Cela ne change donc rien pour les utilisateurs de GraniteDS 2.x.
InfoQ : Merci William !