Introduction
L'API servlet n'a été définie qu'en 1998, et dès l'année 2000, une majorité de grandes entreprises avaient fait le choix du développement Java serveur pour leurs applications Intranet.

Pendant une longtemps, beaucoup de ces entreprises ne se sont pas préoccupées de la manière dont il convenait d'utiliser ces APIs. Aujourd'hui, les entreprises mesurent l'importance des normes, et surtout des frameworks.

Le choix du framework de développement Java serveur est absolument stratégique pour une entreprise. Il sera déterminant pour la qualité, la productivité et la pérennité des développements Intranet pour de longues années. Nous revenons ici sur l'importance de ce choix, et nous essayons de démontrer pourquoi les frameworks issus de l'OpenSource restent un choix indéniable.

Normes et frameworks
Quels que soient les outils de développement, du Cobol au Visual Basic, le respect de normes de développement a toujours revêtu une grande importance. La norme visait deux objectifs :
- d'une part, de généraliser les 'bonnes pratiques' et donc de promouvoir une programmation de qualité,
- d'autre part, d'harmoniser les développements au moins au sein d'une même entreprise, ce qui faciliterait la maintenance.
La mise en pratique de normes de développement est passé dans les mœurs des grandes entreprises depuis plus d'une vingtaine d'années. Mais avec le développement Java serveur, il ne s'agit plus seulement de normes, mais de frameworks, accompagnés eux-mêmes de normes.

Pourquoi cette distinction ?
La différence vient du langage Java qui est orienté objet et souvent considéré comme le premier langage orienté objet qui soit véritablement déployé au sein de l'entreprise. Comme on le sait, l'orienté objet offre des possibilités décuplées en matière de mutualisation et de réutilisation de composants. Pour coder en Cobol sous CICS ou en C sous Tuxedo, quelques normes existantes étaient suffisantes. Quelques librairies de fonctions pouvaient aider, mais elles intervenaient en tant qu'outils, et non en tant que socle. Pour coder en Java serveur, ces normes sont loin d'être suffisantes.

Qu'est-ce qu'un framework ?
Un framework est un ensemble d'outils et de composants qui aident au développement d'application, pour un contexte donné.

Comment différencier un framework d'une simple bibliothèque de composants ?
Par définition, un framework est structurant pour l'application, c'est à dire qu'une application développée pour tel framework n'est pas aisément transposable sur un autre framework.

Pourquoi faut-il des frameworks pour le développement web en particulier ?
Si les frameworks ont pris une telle importance dans le développement Java serveur, c'est que la définition initiale de l'API servlet était de très bas niveau et laissait donc un fossé énorme à combler. Tous les développeurs arrivaient rapidement à la conclusion qu'il était aberrant de développer une application sérieuse en n'utilisant que l'API servlet.

NB : la situation est assez différente dans le domaine du développement d'interfaces utilisateurs en environnement graphique. Les composants Swing constituent d'entrée de jeu un véritable framework, complet et mature. Les concepts fondamentaux des interfaces graphiques, qui remontent à X-Windows, Motif, MacOS et Windows, sont déjà stabilisés et Swing offre une implémentation Java de ces concepts.

En 1998, le développement d'applications Web n'avait pas atteint la même maturité, et l'API servlet a été définie comme l'API CGI, c'est à dire comme reflet direct de la RFC HTTP. Progressivement, les concepts ont émergés, les meilleures pratiques se sont dégagées et le fossé a ainsi été comblé avec l'apparition de frameworks Java de haut niveau.

Un choix indispensable et critique
Il faut bien comprendre à quel point le choix d'un framework est indispensable et critique.

Indispensable, parce qu'il est impossible de réaliser de grandes applications maintenables sans un framework. Critique, parce que le choix du framework aura un impact énorme sur les performances, la productivité, la qualité, la maintenabilité de vos applications. Et puisque le framework deviendra le socle sur lequel un important patrimoine logiciel sera construit, sa pérennité est elle-même fondamentale.

Framework maison
Un framework 'maison', propre à l'entreprise, n'est pas la meilleure solution.

Dans les premières années du développement Java serveur (98-00), les équipes de développement ont très souvent commencé à se construire leur propres outils, qui pouvaient dans certains cas prendre l'envergure d'un framework. Certaines entreprises clientes ont estimé qu'il leur appartenait de faire le choix d'un framework, et de l'imposer à leurs fournisseurs, afin de garantir l'homogénéité de leur patrimoine applicatif. Et comme il existait alors peu d'offre en la matière, et qu'aucune ne semblait faire l'unanimité, de grandes entreprises ont entrepris parfois de se construire leur propre framework.

Nous pensons que ces entreprises devraient très rapidement abandonner leurs frameworks maison, pour retenir un framework OpenSource.

Pourquoi ? Parce qu'aucune entreprise, quelle que soit sa taille, ne pourra consacrer les efforts nécessaires, sur le long terme, pour avoir un framework à l'état de l'art.

Parce que la problématique des frameworks n'est pas stabilisée et que les meilleures approches de développement demandent un niveau exceptionnel d'expertise et de maturité, que seules quelques grandes entreprises peuvent avoir.

Parce que les frameworks OpenSource vont rapidement devenir des standards. Les développeurs seront formés, les applications seront de plus en plus nombreuses à être conformes. Dans ce contexte, le framework maison sera marginalisé et les compétences seront de plus en plus difficiles à trouver pour réaliser des applications selon ce framework.

Parce que la qualité et la robustesse d'un framework est proportionnelle au nombre de projets construits autour, et qu'à cet égard, les frameworks OpenSource sont validés à une échelle mondiale.

Frameworks d'éditeur
Les frameworks d'éditeurs, même réputés, constituent un choix plus risqué. Bien qu'il présente certaines imperfections, le framework maison reste la propriété de l'entreprise qui le déploie. Elle en possède les sources, donc elle est assurée de pouvoir au minimum recompiler les programmes de son patrimoine applicatif sans limite de durée. Les frameworks d'éditeurs, lorsqu'ils ont des bibliothèques livrées sans sources, n'offrent pas cette garantie fondamentale et présentent ainsi un risque réel pour le patrimoine applicatif de l'entreprise.

Le framework d'éditeur a toujours un objectif caché : celui de verrouiller l'entreprise sur les outils de l'éditeur. Ansi, les applications liées au framework - comme on l'a vu cela est inévitable - tendent à devenir indissociables de tel ou tel serveur d'application. Formidable régression !

Alors que Java a enfin rendu possible une réelle portabilité, que la normalisation des APIs J2EE permet d'étendre cette portabilité aux serveurs d'applications, se lier à un environnement unique serait une erreur fondamentale.

Les frameworks de l'OpenSource
Pas de framework maison, pas de framework d'éditeur, … restent les frameworks de l'OpenSource.

Turbine, objets métier issus de Torque, moteurs de template Velocity, Webmacro ou FreeMarker, bibliothèques de tags de Struts, ou Java Standard Tag Library, … la dynamique de développement autour de ces frameworks, est aujourd'hui extraordinaire.

Sur de nombreux thèmes, des projets concurrents de grande qualité s'opposent parfois pendant plusieurs mois. La meilleure voie se dégage progressivement, ou les meilleures idées de l'un et l'autre fusionnent pour une solution unique. C'est toute la démarche darwinienne qui a fait la force de l'OpenSource, qui est à l'œuvre ici. La rapidité, la qualité de ces travaux est du meilleur niveau, c'est cette même dynamique qui a fait naître Apache, le serveur présent dans plus de 65% des sites Internet. Une bonne part de ces projets est d'ailleurs issus de l'Apache project.

Des outils complexes
Les frameworks, quelles que soient leurs qualités et quelle que soit leur origine, restent des outils relativement complexes. Il n'est pas nécessaire d'en maîtriser les internes, mais il faut garder à l'esprit que les frameworks, mêmes structurants, peuvent toujours être mal utilisés. Les normes restent d'actualité, de même que les formations et audits. C'est pourquoi notre dernière recommandation, une fois le framework choisi, est de constituer une petite cellule d'expertise qui assurera l'assistance aux équipes de développement.