Jalios JCMS est un outils exceptionnel permettant de réaliser des sites Intranet, Internet et Extranet. Lorsque j'ai découvert cet outil en 2003, j'ai tout de suite aimé son architecture particulière issue d'un projet de recherche entre Bull et l'INRIA. Par ailleurs, il proposait nativement, déjà à l'époque, un ensemble de fonctionnalités de hautes productivités, comme le scaffolding, l'approche convention over configuration qui ne se sont répandus dans l'industrie logicielle que ces toutes dernières années. C'est pourquoi j'ai rejoint les équipes de Jalios, son éditeur, d'abord comme consultant, puis comme Ingénieur Logiciel R&D.

Les CMS (Systèmes de gestion de contenus) open-sources ayant atteint une certaine maturité, JCMS reste un outil nettement plus avancé, pour plusieurs raisons.

La première est la prise en compte des demandes clients, autant pour des besoins propres à leur métier, que pour des évolutions générales, ainsi que des demandes des partenaires intégrateurs. La seconde est son architecture originale.

La prise en compte des besoins

Les clients apprécient tous particulièrement:

• les possibilités de prototypage rapide et de visibilité d'avancement des mises en oeuvre cela même en dehors d'une quelconque démarche de processus agile;
• l'intégration native de plusieurs dimensions: Gestion de contenus, GED, collaboratif, réseau social, bureau virtuel, portail;
• les connecteurs à différents composants de SI classiques des grands comptes (comme les SSO, cf modules JCMS);
• le choix de la plateforme Java, connu par les équipes techniques internes au client, et l'écosystème des développeurs disponibles;
• l'ergonomie des composants natifs de l'application;
• les performances.

En dépit de son architecture hybride et du large spectre de fonctionnalités couvert nativement par l'outil, les retours des développeurs JCMS montrent qu'ils aiment travailler avec:

• ce qui est simple à spécifier est en général simple à développer: le temps de formation initial est faible pour les développements courants;
• le scaffolding, ayant bénéficié d'une dizaine années de retours utilisateurs, est très avancé;
• le développement de gabarit de présentation (templates) des contenus est très simples;
• les deux derniers points induisent que les temps de prototypage sont très faibles: l'outil est propice à une démarche agile;
• JCMS est très ouvert à toutes forme d'intégration, en particulier grace à son API REST, et au principe de Hollywood (ou Inversion de contrôle) appliqué au niveau de tous les composants logiciels;
• JCMS est extensible à l'aide d'une architecture de modules propre et simple à mettre en oeuvre;
• JCMS comprend de nombreux composants facilitant de développement de fonctionnalités Web 2.0 ou RIA, en particulier l'API Ajax-Refresh;
• JCMS est un "framework full stack", de la présentation à la persistence, en passant par l'intégration (par web service);
• les partenaires apprécient la relation avec Jalios.

L'architecture de persistance de JCMS

Je ne vais pas décrire le détail du mécanisme de peristance de JCMS, mais uniquement expliquer pourquoi, à mon sens, celui-ci permet à JCMS d'être plus agile et plus réactif que les autres ECM ou CMS open sources. La lecture de cette section suppose une bonne connaissance des mécanismes de persistance habituels dans les Frameworks Java.

Dans sa version initiale, JCMS était l'implémentation de la thèse d'Olivier Dedieu, Directeur Technique et Responsable de la R&D de Jalios. Cette thèse décrit JStore, une solution de persistance par journalisation XML et d'accès aux données tout en mémoire. Ces données forment un graphe et des index réciproques sont automatiquement générés pour déterminer les liens inverses. Les problématiques d'accès concurrents sont gérés par copy-on-write. Le clustering est possible à l'aide d'un mécanisme natif de réplication sur HTTP dite optimiste.

La version suivante apportait le scaffolding, tout en restant compatible avec la persistance JStore.

JStore n'a pas les caractéristiques d'une solution NoSQL (représentation JSON des données, API accessibles uniquement par REST, donnée en mémoire uniquement transitoire), mais il y a un certain nombre de points dans JStore qui font penser aux bases NoSQL:

• pas d'accès SQL, uniquement par les API Java ou REST;
• persistance dans un fichier de journalisation, en append;
• pas de transactions, atomicité de la persistance au niveau d'une opération sur une donnée.

De manière générale, au niveau des bases NoSQL, c'est l'affaiblissement du support des transactions (consistance immédiate remplacée par consistance finale) qui permet de bénéficier d'un meilleur support du partitionnement. En ce qui concerne JCMS, l'absence de support de transaction alors que le modèle de données est en mémoire permet de bénéficier de bonnes performances pour l'accès aux données en écriture (en plus des excellentes performances pour la lecture).

Contrairement aux bases classiques NoSQL, JStore a un schéma, mais contrairement aux bases SQL, JStore supporte des refactorings simples (ajout, suppression de colonnes, certaines modifications de type de champs) du schéma sans effectuer de migration des données.

Les versions ultérieures ont apportés différentes fonctionnalités et améliorations techniques liées ou non avec la persistance. La version 6.0 apportait une nouveauté, un mode de persistance hybride entre la persistance historique de JCMS: JStore et une persistance en base de donnée SQL classique. Cela permet de bénéficier des performances exceptionnelles d'accès aux données et des fonctionnalités natives additionnelles (metadonnées, historique, catégories, droits complexes, indexations...) du JStore pour certaines données et de la volumétrie habituelle des bases SQL pour les autres.

Le scaffolding de JCMS est plus puissant fonctionnellement que les solutions de scaffolding que l'on trouve actuellement:

• pour un type de donné particulier, on choisit son mode de persistance (dans JStore ou en base);
• la définition du schéma est définie par une interface graphique: cela permet d'interagir agilement avec les MOA pour la définition du schéma et des interfaces de contribution;
• car les interfaces de contribution sont générées (le scaffolding va de la présentation, à la persistance): on a par exemple des choix de plusieurs éditeurs pour un type de champ, et des options supplémentaire pour l'éditeur choisi;
• tout ces choix sont persistés dans un fichier xml, ce qui permet (avec certaines restrictions toutefois) d'empaqueter un type dans un module pour le déployer sur plusieurs applications;
• la persistance en base repose sur Hibernate, mais les meta-données de définition sont elle-même générées, ce qui fait que JCMS contient une interface graphique de définition des meta-données Hibernate;
• le scaffolding repose sur une génération de code, ce qui permet de meilleures performances à l’exécution et moins de manipulation de bytecode (il y en a néanmoins, puisque Hibernate est utilisé en couche inférieure).

Globalement, avec ces mécanismes de persistance et de scaffolding matures et full-stack (inutile de modifier les interfaces de contribution), les développeurs peuvent se concentrer sur le développement proprement applicatif et les problématiques d'intégration avec d'autres systèmes.

Comme par ailleurs, il est possible de capitaliser sur ces développements en utilisant l'architecture de modules, il y a déjà des applications prêtes à l'emploi, et seuls les développements vraiment spécifiques sont à réaliser pour tel ou tel projet (intégration de la charte graphique, ou d'un système legacy maison).