La plupart des entreprises démarrant des projets d’envergure en Java ou ayant un retour d’expérience sur un premier projet dans cette technologie s’accordent sur le fait qu’il est indispensable d’avoir un framework technique pour normaliser les développements et assurer les évolutions futures des applications déployées. Le débat tourne aujourd’hui essentiellement sur le choix de ce framework technique : framework payant, framework open-source ou framework maison ?

La démarche framework
Tout d’abord, il est important de préciser que le framework technique est bien plus qu’une boîte à outils. Le framework technique doit s’intégrer dans une démarche globale couvrant les domaines des normes et méthodes, de la qualité, de l’architecture du SI, de la formation et, dans une certaine mesure, de la méthodologie de projet.

Normes, méthodes et qualité
S’il est complet et couvre toutes les couches d’une application (IHM, code métier, accès aux données, interfaçage aux systèmes externes), le framework technique amène des règles de structuration des applications qui s’imposent dès la phase de conception d’un projet. Ces règles doivent notamment définir les possibilités d’héritage des services applicatifs à partir d’une hiérarchie de classes mères lors de la phase de modélisation UML. Ces règles s’étendent ensuite aux équipes de développement.

L’entreprise s’assure alors une uniformité des développements et une plus grande qualité des applications en introduisant une forte réutilisation de composants déjà testés. On constate par expérience une diminution des erreurs techniques. Ceci permet aux équipes projet de rester focalisées sur les fonctionnalités métiers des applications.

Architecture du SI
La réutilisation de composants techniques entraîne la construction d’un socle solide servant de base à l’architecture du SI. Le framework ne doit cependant par contraindre l’architecture. Il doit être paramétrable pour autoriser différents types de déploiement (avec ou sans EJB par exemple) et rester indépendant des serveurs d’applications (en proposant une interface paramétrable à certains services spécifiques de ces serveurs comme le pool de connections à la source de données ou le cache d’objets par exemple). Il doit respecter les normes J2EE et ne pas introduire de run-time spécifique.

Si le framework est structurant, il est cependant faux de croire qu’il enferme définitivement l’entreprise. En effet, tous les frameworks et autres boîtes à outils reprennent généralement les mêmes concepts et ont notamment recours aux mêmes design patterns recommandés par SUN dans son catalogue (http://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html). Dès lors, si des frameworks sont bien conçus (utilisation systématique d’interfaces, de patterns tels que MVC ou Factory), il est possible de mixer des composants de plusieurs frameworks comme CGI France a eu l’occasion de le faire pour certains clients.

Formation
L’un des objectifs du framework étant de masquer la complexité technique des multiples spécifications J2EE (JSP, EJB, JMS, JCA, JDBC, etc.), il doit être accompagné d’une documentation (guides utilisateur et de référence, documentation HTML des APIs) et d’un plan de formation permettant de faire monter rapidement en puissance les équipes de développement. Cette formation doit être complétée par un plan d’accompagnement des équipes sur le démarrage d’un premier projet.

Méthodologie
Enfin, le framework structure aussi, dans une certaine mesure, l’approche méthodologique. Il impose souvent la mise en place d’une équipe dédiée au support des projets. Il peut offrir des facilités pour construire parallèlement plusieurs parties de l’application en spécialisant des équipes de développement (IHM, code métier, accès aux données par exemple). Il peut contenir des composants permettant de déléguer certaines tâches à des personnes moins techniques (intégration d’une bibliothèque de tags pour la construction des pages JSP par un designer plutôt que des javascripts complexes par exemple).

Mais avant tout, un framework doit être livré au minimum avec les métriques nécessaires au calcul préalable des charges de conception et développement d’un projet. Sans cela, comment une entreprise peut-elle se lancer sur un projet ?

Framework open-source, maison ou payant ?
Compte tenu de tous les éléments cités auparavant, il apparaît clairement que les frameworks open-source ne sont pas adaptés à des projets de grande taille. Ils sont construits par des passionnés et s’adressent à un public très technique capable de se débrouiller avec un minimum de documentation et de s’investir directement dans le code pour en comprendre les subtilités.

Il est utopique de penser pouvoir former une équipe complète de développement sur ce genre d’outils (surtout si les ressources à former viennent d’anciennes technologies comme chez bon nombre de grandes entreprises où les bases de données résident encore sur mainframe). Au mieux une entreprise pourra-t-elle constituer une équipe restreinte de trois ou quatre experts qui complètera et enrichira un framework open-source de base. C’est un scénario que CGI France a eu l’occasion de voir mis en œuvre chez certains de ses clients.

Il est alors tentant de construire un framework maison en utilisant une base open-source (en récupérant du code source ou en s’inspirant des concepts). Ceci est cependant à réserver aux entreprises capables de dédier une équipe dans le long terme pour la maintenance et l’évolution de ce framework (évolution des versions de J2EE, des serveurs d’applications, ajout de nouvelles normes, etc.) aussi bien au niveau du code que de la documentation l’accompagnant (charge de travail importante et souvent négligée).

Bien entendu, cela nécessite, de plus, d’avoir des ressources très matures, avec une large expérience des problématiques de construction par composants, d’architecture, etc. En effet, le choix même d’un framework open-source est problématique. Il suffit pour s’en convaincre de lire les forums dans lesquels des développeurs avertis ne parviennent pas à départager des frameworks similaires tels que Struts et Turbine ou encore Velocity et Cocoon (pourtant tous développés dans le cadre du projet Jakarta !). Sans parler du fait que certains projets open-source s’arrêtent parfois du jour au lendemain, faute de ressources ou suite à une " sélection naturelle " entre frameworks concurrents.

Seules quelques grandes entreprises (dans le domaine de l’assurance et de la banque souvent) disposent donc des moyens nécessaires à la construction d’un framework maison.

Dans les deux cas précédents, framework open-source et maison, on ne résout pas le problème de disposer de métriques fiables pour l’évaluation des charges d’un projet. Cela nécessite au minimum de faire un projet test (assez conséquent pour servir de référence) et donc, sans doute, d’y laisser quelques plumes.

Avec un framework payant, l’entreprise bénéficie de la capitalisation d’expérience d’une société spécialisée ayant souvent construit des frameworks dans d’autres technologies, comme CGI France a pu le faire en Forté, NatStar ou C++ par exemple. Le framework est packagé avec documentation, formation et accompagnement. Ce sont d’ailleurs principalement ces services qui sont payants. Une maintenance permet de s’assurer de la continuation des évolutions du framework. L’entreprise aura à cœur de choisir un framework édité par une société indépendante d’un éditeur de serveurs d’applications (et donc proposant des paramètres permettant le portage d’un serveur à un autre), livrant les sources du framework et n’imposant pas de run-time.

Un choix définitif ?
Il convient sans doute finalement d’adopter un juste milieu dans ce débat.

En effet, si le choix d’un framework payant semble être à privilégier pour une entreprise démarrant des projets d’une certaine taille, avec des équipes de développement à former, on peut tout de même y adjoindre certains outils du monde de l’open-source. Ces outils sont notamment ANT (scripts de compilation du code et génération des fichiers JAR ou WAR), Xerces et Xalan (parseur XML et transformation XSLT), FOP et Cocoon (production de documents PDF notamment à partir de données XML) et Tomcat (serveur de pages JSP).

Enfin, l’entreprise peut surcharger certains services du framework payant pour les adapter à des besoins spécifiques. Elle bénéficie alors d’un framework personnalisé, tout en profitant des évolutions futures du framework originel.