MEMOIRE INDUSTRIEL ESIEA Barbara POST Migration de l'application internet de gestion des licences Software AG : vers une architecture J2EE à base open source Software AG France Responsable Software AG : M. Joël Milgram, directeur de projets Président du jury : M. Lamine Abdat Parrain : M. Gil Largeaud 15 janvier 2003
Migration de l'application internet de gestion des licences Software AG : vers une architecture J2EE à base open source Etude de composants permettant de structurer un développement (frameworks) : Struts, Cocoon 2 Analyse fonctionnelle, développement, chiffrage et planning prévisionnel du projet L'open source : présentation et enjeux REMERCIEMENTS... 5 1. INTRODUCTION... 6 ABSTRACT... 7 2. PRESENTATION DE LA SOCIETE ET DU PROJET... 8 2.1. SOFTWARE AG : EDITEUR DE LOGICIELS D'INFRASTRUCTURE ET INTEGRATEUR DE SOLUTIONS COMPLETES..8 2.2. LA FILIALE FRANÇAISE...8 2.3. LE PROJET BUSINESS ALLIANCES EUROPE LICENSE KEY APPLICATION...10 2.3.1. Besoins, buts...10 2.3.2. Fonctionnement...10 2.3.3. Historique du projet...12 2.4. MES MISSIONS...12 2.4.1. Un défi...12 2.4.2. Organisation...12 2.4.3. Tâches annexes...13 2.4.4. Documents produits...13 3. ETUDE DE FRAMEWORKS MVC...14 3.1. POURQUOI UN FRAMEWORK MVC ET J2EE?...14 3.1.1. Architecture MVC ou "Model 2"...14 3.1.2. Un framework J2EE...15 3.2. ETUDE DE DEUX FRAMEWORKS...16 3.2.1. Pourquoi Struts et Cocoon?...16 3.2.2. Struts 1.1 b1...17 3.2.3. Cocoon 2.1-dev...23 3.2.4. Comparaison de Struts et Cocoon...30 3.2.5. Conclusions comment choisir...32 4. MIGRATION DU PROJ ET LICENSE KEY APPLICATION/BAE...36 4.1. DESCRIPTION ET ANALYSE DE L'EXISTANT...36 4.1.1. Architecture...36 4.1.2. Problèmes posés...41 4.2. EVALUATION DE SOLUTIONS...41 4.2.1. Struts 1.1 b1...41 4.2.2. Cocoon 2.1-dev...42 4.2.3. Conclusions...43 4.3. ELEMENTS STRATEGIQUES...43 4.3.1. Solution retenue...43 4.3.2. Modification de fichiers XML...43 4.3.3. Gestion des accès à Tamino...44 4.3.4. Gestion de l'accès à LDAP...44 4.3.5. Autres choix stratégiques...44
4.4. DEVELOPPEMENT REALISANT UNE FONCTION DANS SON ENSEMBLE : GENERATION DE LICENCES PAR DEFAUT...45 4.4.1. Généralités...45 4.4.2. Modifications apportées à la configuration par défaut de Cocoon...45 4.4.3. Documentation des fichiers réalisés...46 4.4.4. Maintenance, procédure de mises à jour...52 4.5. OUTILS ET METHODES DE DEVELOPPEMENT...52 4.5.1. Editeur/debugger XSLT : Excelon Stylus Studio...53 4.5.2. Editeur et compilateur java : JBuilder...53 4.5.3. Moteur de servlets : Tomcat 4.1...55 4.5.4. Débogage...56 4.5.5. Logging...56 4.6. CHIFFRAGE...57 4.7. PLANNING PREVISIONNEL DE DEVELOPPEMENT...57 4.7.1. Temps nécessaire...57 4.7.2. Exemple de répartition des tâches 3 développeurs...61 4.7.3. Calendrier global...62 4.8. CONCLUSIONS...63 4.8.1. Une nouvelle application plus efficace...63 4.8.2. Une prise de risques nécessaire...63 4.8.3. Une documentation réalisée variée...63 4.8.4. Quelques problèmes rencontrés...63 5. L'OPEN SOURCE : PRES ENTATION ET ENJEUX...65 5.1. PRESENTATION...65 5.1.1. Définition de l'open source...65 5.1.2. Une stratégie gagnante...66 5.1.3. Bref historique...66 5.1.4. Différentes licences...67 5.1.5. Quelques acteurs actuels et historiques...72 5.1.6. Quelques points de comparaison avec le logiciel propriétaire...74 5.2. L'OPEN SOURCE ET LE MARCHE EN 2002...74 5.2.1. Evolution structurelle des logiciels : du "back -end" vers le "front-end"...74 5.2.2. Produits actuels...74 5.2.4. Clients, utilisateurs...78 5.2.5. Revenus...81 5.2.6. Tendances...82 5.3. L'OPEN SOURCE ET LE DEVELOPPEUR...82 5.3.1. Profil et motivations...83 5.3.2. Outils et méthodes...83 5.3.3. A la frontière de la communauté expérience personnelle...83 5.4. L'OPEN SOURCE ET LE GENIE LOGICIEL...84 5.4.1. Le logiciel open source...84 5.4.2. Le projet basé sur le logiciel open source...85 5.5. DES MODELES ECONOMIQUES BASES SUR L'OPEN SOURCE...86 5.5.1. Vue d'ensemble...86 5.5.2. Cinq modèles, quelquefois pour un même acteur...87 5.5.3. Un modèle pour Software AG?...89 5.6. "DE L'ERE DES EDITEURS COMMERCIAUX DE LOGICIELS A CELLE DES ENTREP RISES D'INFORMATION"...89 5.6.1. Utilisateurs professionnels...89 5.6.2. ou changement de modèle économique?...91 5.6.3. Evocation de différentes problématiques...91 5.6.4. Positionnement de Software AG...92 5.7. L'OPEN SOURCE ET LE JURISTE...93 5.7.1. Délivrer un logiciel open source, quelle responsabilité?...93 5.7.2. Dissémination de secrets industriels?...94 5.7.3. Forcer l'adoption de standards...94 5.7.4. Les brevets : combat des titans...94 5.8. CONCLUSIONS...95 6. CONCLUSION GENERALE...96 Migration du portail de gestion des licences produits de Software AG
7. GLOSSAIRE...97 8. BIBLIOGRAPHIE...101 9. ANNEXES...107 9.1. AUTRES FRAMEWORKS... 107 9.2. STRUTS... 107 9.3. COCOON... 109 9.4. PROJET BAE LICENSE KEY APPLICATION... 124 9.5. CONFIGURATIONS... 145 9.6. APIS... 149 9.7. OPEN SOURCE... 149 9.8. ETUDE DES MOTEURS DE SERVLETS... 151 9.9. COMPARAISON DE PRIX DE QUELQUES EDITEURS / COMPILATEURS JAVA COMMERCIAUX... 152 Migration du portail de gestion des licences produits de Software AG
Remerciements Je remercie Software AG France de m'avoir accueillie pour mon stage de fin d'études et m'avoir donné l'opportunité, non seulement d'évoluer dans un cadre technologique passionnant, mais d'exercer mes compétences en collaboration, sur l'ensemble des phases d'un projet. Et malgré la conjoncture difficile, de m'avoir permis de terminer le stage. Je remercie plus particulièrement mon responsable, M. Joël Milgram, directeur de projets, pour sa supervision efficace et la grande autonomie qu'il m'a laissée, ainsi que pour l'orientation qu'il a donnée à mon mémoire. Mes pensées se tournent également vers mon suiveur, M. Gil Largeaud, pour ses conseils constructifs concernant mon mémoire, ainsi que M. Jérôme Marc, expert technique de Software AG, pour son assistance lorsque j'en avais besoin, et les quelques échanges que nous avons eus sur Cocoon. 5
1. Introduction Aujourd'hui les technologies, les compétences, les besoins évoluent rapidement. Deux défis majeurs, dans le cadre de systèmes existants, sont leur évolution structurelle ainsi que leur pérennité fonctionnelle. Software AG, éditeur de logiciels, utilise depuis mi-2000 un système de production et gestion de licences de ses produits, "License Key Application" (anciennement "Business Alliances Europe"). Il permet, outre la sécurisation contre le piratage, une meilleure répartition de l'information. Cela prend la forme d'un portail intranet (centres logistiques allemand et américain) et internet (partenaires autorisés). Le projet initial a été réalisé par six ingénieurs pendant sept mois, à l'aide d'un outil de développement conçu par Software AG : Bolero. Son évolution et support technique ne seront plus assurés en 2005. La question suivante s'est alors posée : comment garantir la pérennité du système indépendamment de l'outil de développement spécifique et des développeurs initiaux? Ma tâche a donc consisté à réaliser une preuve de faisabilité de la migration de cette application vers le standard J2EE, en choisissant un cadre de développement adapté. Ce mémoire présente : brièvement Software AG et sa filiale française, mon étude de deux cadres de développement open source, les étapes du projet auxquelles j'ai participé : 03/02 04/02 05/02 06/02 07/02 08/02 09/02 10/02 11/02 étude de cadres de développement aide à l'extension B2B, étude de moteurs de servlets. durée effective : 3 semaines analyse de l'existant (structure, fonctions) analyse fonctionnelle développement (preuve de faisabilité) documentation du développement analyse des outils utilisés pour le dév. rédaction du mémoire réunions importantes (compte-rendu, prises de décisions, planification) un bilan des outils et méthodes que j'ai utilisés, une réflexion personnelle sur les licences open source dont l'enjeu est des plus importants pour un éditeur de produits commerciaux. Remarque : les termes explicités dans le glossaire (partie 7) voient leur première occurrence dans le corps du document soulignée en pointillés. 6
Abstract In today s digital world, technologies, skills, and needs are constantly evolving. Important challenges are how to modify the architecture of an existing system, and how to preserve long-term functional capabilities. Software AG develops and licenses cross-enterprise system software products for electronic business, enterprise application integration, and online transaction processing. Management of its software licenses has been handled since mid-2000 by License Key Application (former Business Alliances Europe). BAE is an intranet-based portal used by German and US logistic centres, and an internet -enabled portal for granted partners. BAE's portal allows centres and partners to generate licenses, as well as perform searches, change license status, gather statistics, and manage users' and partners' information. The initial project required six software engineers for a period of seven months. The system continued to evolve with additional developments up to this year during my internship. Bolero, a proprietary Javabased tool developed by Software AG, is the main development software that was utilized for years. However its evolution has ceased and technical support will become ineffective in 2005. Therefore the challenge that I was presented with in working on this project was how to keep the system working, while detaching it from the initial team and software. This document provides an overview and summary of: Software AG and its French subsidiary my study of two open source frameworks that I deemed suitable for the redesign parts of the project I realized, mostly on my own : mainly analysis of existing code and functionalities, functional analysis for the new architecture, some development as feasibility proof, and an estimation of time and cost for the whole project analysis and criticism of the development tools I used personal thoughts, from open source licensing system to software editor's viewpoint 7
2. Présentation de la société et du projet Software AG est leader du marché des bases de données XML natives et a de fortes compétences en intégration (solutions middleware). Elle se présente comme "The XML Company" et participe activement à l'élaboration de standards au sein des consortiums internationaux. La filiale française réalise l'implémentation de solutions utilisant les produits Software AG. Dans ce cadre, j'ai été chargée d'étudier et de proposer des solutions techniques pérennes sur le changement d'architecture du portail d'application gérant les licences produits 2.1. Software AG : éditeur de logiciels d'infrastructure et intégrateur de solutions complètes Software AG, éditeur de logiciels fondée en 1969 à Darmstadt, emploie 3000 personnes dont un peu plus du tiers en Allemagne, le reste étant réparti dans 70 pays. Le chiffre d'affaires s'élève à 589 millions d'euros en 2001, réparti assez équitablement entre revenus de licences, contrats de maintenances, et services. Partie du développement d'environnement de développement tel que Natural (langage de 4 e génération), ou de base de données comme Adabas, la société s'est tournée au milieu des années 1990 vers les technologies XML et l'intégration d'applications (EAI : Enterprise Application Integration). Ses produits phares sont actuellement Tamino : base de données native XML, leader sur son marché, et EntireX, outil d'intégration middleware de flux de données hétérogènes. En plus de la vente directe, une politique soutenue de partenariats et contrats a été mise en place, intéressant d'autres éditeurs de logiciels (independent software vendors ("ISVs'')), des distributeurs à valeur ajoutée (value added resellers ("VARs'')), et des intégrateurs (system integrators ("SIs'')). Par ailleurs Software AG est membre de plusieurs organismes ou projets importants : W3C, World Wide Web Consortium, groupes de travail suivants : XML Schema, XML Query, XSLT, XML Protocol, XML DOM, XML InfoModel, Web Services Architecture. Software AG a été éditeur ou co-éditeur de Working Drafts sur : Quilt puis XQuery 1.0, XPath 2.0, XSLT 2.0, Web Services Architecture. OASIS (membre et sponsor). OASIS est un organisme qui aide au développement, à la convergence et à l'adoption de standards d'e-commerce. Unicode, standard permettant la représentation indépendamment de la plate-forme et du langage de n'importe quel caractère. UDDI : Universal Description, Discovery and Integration, standard ouvert de description, recherche et intégration de services e-business sur le réseau internet. Edifrance, groupes de travail autour de l'échange de documents électroniques (EDI). Seulement la filiale française de Software AG est concernée. WS-I, Web Services Interoperability Organization. XML France, association d'utilisateurs de XML. De plus, la "XML Academy" fondée par Software AG propose un cycle de formation complet sur XML en partenariat avec HP. 2.2. La filiale française Software AG France (abrégé : SAGF) dirigée par Philippe Lerer depuis mai 2002, emploie 150 personnes et génère en 2001 un chiffre d'affaires de 21 millions d'euros. L'activité s'est orientée vers la commercialisation, le support et les services intégrant les produits et solutions de Software AG. Des formations sur tous les produits sont assurées. 8
Le département services est organisé comme suit, en entité tripartite : - BIS : Business Innovation Services, dirigé par Philippe Toubert. Gère l'avant-projet : consulting, formation - BITS : Business Integration Technology Services, dirigé par Philippe Toubert. Gère les projets. Il est divisé en deux agences se répartissant les projets suivants qu'ils sont orientés bases de données ou administration système. Les responsables sont respectivement Sylvie Morange et Dominique Hubert. - BOS : Business Operation Services, dirigé par François-Xavier Delassus. Gère l'après projet : hotline, maintenance, installation sur site. De ce fait la prise en charge globale de projets basés sur des standards tels que XML, J2EE,.NET, CORBA est assurée par SAGF de manière structurée. L'agence de Dominique Hubert compte un directeur de projets : Isabelle Bertinet, tandis que celle de Sylvie Morange en compte deux : Joël Milgram et Philippe Buisson. Un directeur de projet gère au plus 5 projets à la fois, ainsi que des réponses à des appels d'offres. J'ai eu la chance d'évoluer sous la responsabilité de M. Milgram. Professional Services (en cours de pourvoi) Commercial Gilbert TOMASSO Contrôle de gestion Hanifa BOUASSRIA Assistantes BIS Philippe TOUBERT BITS Philippe TOUBERT BOS François-Xavier DELASSUS Support Michel DOUCET Responsable d'agence Sylvie MORANGE Responsable d'agence Dominique HUBERT Directeur de projets Joël MILGRAM Directeur de projets Philippe BUISSON Directeur de projets Isabelle BERTINET 9
2.3. Le projet Business Alliances Europe License Key Application Cette partie reprend les informations tirées d'un document "License Key Application Business Case", d'avril 2002, réalisé par Reinhard Fox, chef de projets au sein du Customer Service Systems, département de Corporate Information Services (informatique interne de Software AG). M. Reinhard Fox est chargé de la maîtrise d'œuvre de License Key Application et de la liaison avec la filiale française qui en assure le développement et la maintenance. Le terme "License Key Application" est préféré à celui de "BAE" surtout depuis les dernières modifications apportées au portail. Cependant dans ce document on trouve les deux termes (souci de prononciabilité). 2.3.1. Besoins, buts Software AG, pour protéger ses produits logiciels contre le piratage, utilise une clé de licence unique par produit vendu. La société a décidé de généraliser l'automatisation de cette pratique en l'an 2000. En effet la progression des ventes de Tamino a entraîné un besoin de standardiser le mécanisme de production et gestion des licences. Le projet License Key Application a plusieurs buts : - générer une clé unique pour chaque produit ; - permettre une homogénéité dans la manière de produire les licences ; - pouvoir licencier modulairement tous les produits SAG, ainsi que les sous-produits et produits dérivés ; - favoriser le marketing par proposition de licences à durée limitée, avec fonctionnalité entière du produit ; - assurer un service technique pour les clients, la clé de licence servant d'identifiant ; - contrôler les installations de test ; - contrôler les revenus issus des partenariats avec les ISVs, VARs, SIs ; - obtenir des statistiques en général et ceci accessible par des services répartis géographiquement de par le monde afin d'assurer un service permanent. 2.3.2. Fonctionnement 2.3.2.1. Acteurs et rôles 2.3.2.1.1. Centres logistiques Deux centres logistiques (LSC, Logistic Service Center) ont la charge de traiter les demandes de clients. Suivant la procédure standard, ils sont habilités à générer des licences et à les expédier sur disquettes accompagnées du CD du produit. Les LSC sont situés à Alsbach en Allemagne (pour les régions Europe-Asie-Pacifique) et Dulles aux USA (région Amériques). 2.3.2.1.2. Centres de support client Les CSC, Customer Support Center, sont habilités à générer des licences "d'urgence" pour les clients ayant un contrat de maintenance 24h/24, 7j/7, et lorsqu'il y a besoin de licences pour une autre plateforme ou version que celle demandée au départ. Les licences sont alors envoyées par email. Ils peuvent par ailleurs effectuer des recherches sur les licences. Les CSC sont situés à Darmstadt (Allemagne), Denver (USA), Manille (Philippines). 10
2.3.2.1.3. Partenaires Certains partenaires habilités, tels que Altova (Autriche) et Tridion (Pays-Bas), peuvent générer des licences pour les produits partenaires incluant une licence Tamino. 2.3.2.1.4. Corporate Information Services Le service de l'informatique interne de Software AG, Corporate Information Services, est basé en Allemagne. Une de ses tâches est d'assurer l'administration du portail BAE (gestion de la bonne marche du serveur, mise en production ). CIS est le client du projet, ainsi que le maître d'ouvrage. 2.3.2.1.5. SAGF Une équipe d'ingénieurs de la filiale française assure le développement, la maintenance et les tests, avec accès aux serveurs de tests (identiques à ceux de production). Elle est le maître d'œuvre. 2.3.2.2. Eléments caractéristiques 2.3.2.2.1. Identifiant de licence Les informations produits sont stockées au départ dans le Project Planning Database (PPD). Ils ont pour principale caractéristiques le code produit (ex. INO pour Tamino), et la plate-forme (ex. WNT pour Windows NT4). Ces informations ainsi que d'autres renseignements (techniques, financiers) sont insérés dans SAP/R3 qui est chargé de retourner un identifiant par type de licence : License Material Number. 2.3.2.2.2. Structure d'une licence et protection Une licence se présente sous la forme d'un fichier XML contenant des informations sur : - le client à partir de SAP ; - la licence (clé unique sur 32 bits, type et aspect financier) ; - le produit et les fonctionnalités que la licence autorise. L'intégrité d'une licence est assurée par un algorithme, appelé SAGLIC, qui calcule la clé en fonction du contenu du fichier. Si le fichier est modifié, la clé n'est plus valide. 2.3.2.2.2.3. Environnement R&D Quality Engineering Product Manager LSCs CSCs Serveur de test LK Dév. SAGF Serveur de prod. LK Tamino XML DB Admin. CIS Tamino XML DB 11
Légende : CIS : Corporate Information Services CSC : Customer Support Center LK : License Key LSC : Logistic Service Center R&D : Recherche et développement SAGF : Software AG France XML DB : base de données XML 2.3.3. Historique du projet L'ajout de fonctionnalités a été progressif, ce qui rend le système complexe. Fin 2002, l'ensemble des réalisations se monte à 387 000 euros. 2.3.3.1. Développement réalisé Le développement du projet a connu plusieurs phases importantes, et a occupé un nombre variable d'ingénieurs : de six pendant les sept premiers mois à deux pour l'extension B2B en 2002. Les durées incluent aussi bien la conception que la réalisation et les tests précédant la livraison. juillet-décembre 2000 (cinq mois) : génération de licences et fonction de recherche janvier-février 2001 (deux mois) : gestion des droits utilisateurs mars-septembre 2001 (six mois) : gestion de templates, ajout de nouvelles méthodes de recherche, modification de l'administration octobre-novembre 2001 (deux mois) : ajout de la fonctionnalité de plug-ins décembre 2001-février 2002 (trois mois) : migration de la version 2.2.1 à 3.1.1 de Tamino mars-juin 2002 (trois mois) : extension B2B permettant aux partenaires de se servir du système 2.3.3.2. Développement prévu pour 2003 premier trimestre : fonctionnalité multi plug-ins nécessaire au passage vers Tamino 4.1 deuxième trimestre : License Key Bundle troisième trimestre : migration de Windows NT4 à Windows 2000 quatrième trimestre : mise à jour de l'algorithme SAGLIC, migration de Bolero vers Java, nouvelle interface de connexion avec SAP Un budget de l'ordre de 150 000 euros est prévu pour ces tâches. 2.4. Mes missions 2.4.1. Un défi J'ai été enthousiasmée à l'idée de relever le défi qui m'a été proposé : faire évoluer une application d'importance stratégique, basée sur un langage de programmation proche de java, vers le standard J2EE, en recherchant les outils les mieux adaptés pour cela. Mon travail devait servir de preuve de faisabilité et permettre d'estimer les besoins temporels et financiers pour la migration proprement dite, sachant que mon stage se terminait avant la budgétisation du projet, et que la conjoncture ne me permettait pas d'être embauchée. De plus l'étude réalisée en première partie devait être générale et applicable à d'autres projets. 2.4.2. Organisation La majorité du travail a été réalisé de manière autonome, j'ai donc eu toute latitude pour m'organiser au mieux. Des réunions régulières ont permis une planification des grandes étapes : étude des frameworks, réalisation de la preuve de faisabilité, recherches annexes. Les délais étaient implicites, ou précisés avec une marge d'une à deux semaines, sachant qu'à la fin de mon stage on devait avoir tous les éléments décisionnels (études et réalisations), et tout avoir prévu pour soumission au client (maître d'ouvrage). 12
J'ai eu à ma disposition : - une station de travail sous Windows NT4, sur laquelle Tamino était déjà fonctionnel. J'ai dû y installer d'autres éléments : Bolero, Microsoft Visual Source Safe (outil de travail en collaboration), ainsi que les outils que j'ai choisis pour mes réalisations. - la documentation technique du projet, dont le manuel utilisateur expliquant en détail le fonctionnement. Dans la phase d'analyse de l'existant je me suis appuyée sur une lecture méthodique du code Bolero. Pendant le début du stage j'ai partagé durant quelques semaines un bureau avec un stagiaire qui avait commencé en même temps que moi et était là pour 2 mois et demi. Nous avons pu nous entraider pour la compréhension du système basé sur les servlets java, ainsi que la programmation. 2.4.3. Tâches annexes J'ai pu aider, dans la mesure de mes moyens et en continuant ma tâche principale, à l'extension B2B : les partenaires ont accès à l'application via web service. J'ai aidé au codage en Bolero et aux tests. Lors de cette phase on m'a aussi demandé d'étudier des moteurs de servlets, le client devant changer de version à cause de la plate-forme de communication XML utilisée pour le B2B, EntireX XML Mediator. J'ai donc testé le fonctionnement de l'application existante sous divers environnements (JRun et Tomcat). L'annexe 9.8 fait référence à cette étude. 2.4.4. Documents produits Le corps des études et de la documentation principale du projet est directement structuré et intégré au mémoire. Une partie des autres documents produits, en français ou anglais, ont été intégrés dans le corps ou en annexe, lorsqu'ils ont un intérêt pour le lecteur. Il s'agit principalement de directives d'installation et de configuration de l'application ou de logiciels, ainsi que la comparaison de moteurs de servlets. Par ailleurs mon développement s'accompagne de javadoc (non présentée ici). Les éléments laissés sur le serveur Odin à disposition des futurs développeurs du projet comportent : - les fichiers du projet sous forme de web archive (.war); - une procédure d'installation et de configuration de l'application ; - une documentation du projet ; - un planning global ; - un planning détaillé (MS Project). 13
3. Etude de frameworks MVC J'ai réalisé une étude qui se voulait non seulement base de mon travail mais aussi réutilisable pour d'autres projets. Je me suis appuyée sur de nombreuses sources documentaires internet. De petits développements tests m'ont permis de mieux appréhender certains concepts. Cette étude présente d'abord les concepts Modèle (Model), Vue (View) et Contrôleur (Controller) ainsi que la notion de standard J2EE. Puis les deux cadres de développements retenus, Struts et Cocoon 2, sont étudiés sur plusieurs plans : - pourquoi ai-je retenu ces versions? - quels sont les éléments M, V, C de chaque framework? - quels sont les éléments décisionnels et les éventuels problèmes posés? - comparaison de leurs fonctions essentielles - conclusion : récapitulatif des éléments décisionnels et typologies de projets 3.1. Pourquoi un framework MVC et J2EE? 3.1.1. Architecture MVC ou "Model 2" 3.1.1.2. Introduction Le modèle MVC (Model-View-Controller) permet de séparer les traitements de données effectués (Model), de ce qui correspond à ce que le client reçoit et qui est dépendant de l'interface finale adoptée (View). La partie Controller assure la synchronisation. Ces composants sont décrits plus précisément ci-après. source : http://java.cnam.fr/public_html/iagl99/dazy/uml_mvc/mvc/mvc.htm 14
L'intérêt majeur du modèle MVC réside en la facilité à construire un projet, appréhender l'existant ou le faire évoluer, en s'appuyant sur des structures standard. 3.1.1.3. Partie Model C'est la partie "back-end" du système, qui peut être subdivisée en concepts : l'état interne du système, et les actions qui peuvent être entreprises pour le modifier. Les beans ou EJBs (Enterprise Java beans) représentent cet état, et leurs propriétés les détails de cet état. Une autre partie de cet état est souvent contenue dans des bases de données, dans ce cas les beans réalisent l'interfaçage. Le "business logic" ("comment cela s'effectue") est donc assuré par ces composants. 3.1.1.4. Partie Controller Cette partie a pour rôle de recevoir les requêtes du client, de décider quelle fonction de business logic doit être exécutée, déléguer la production de ce qui est renvoyé au client au composant View approprié. Il s'agit le plus souvent de servlets. 3.1.1.5. Partie View Cette partie "front -end" gère la présentation des données et résultats envers le client. Les JSPs (Java Server Pages) sont indiquées pour ce rôle, contenant du code HTML statique et du contenu dynamique issu de traitements. Les servlets sont également utilisables, mais moins pratiques pour du contenu répétitif. Une autre approche utilise des feuilles de style XSL. 3.1.1.6. Remarques Il faut bien noter que les beans sont divisés en beans de présentation : interfaçage Controller (servlet) et View (JSP), et en beans de traitement (accès aux données, business logic) : interfaçage entre Controller et Model ou bien composants à part entière du Model. 3.1.2. Un framework J2EE Le standard Java 2 Enterprise Edition J2EE simplifie le développement et le déploiement d'applications multi-tiers : - basé sur un ensemble de composants modulaires standards ; - ensemble de services liés à ces composants ; - prise en charge automatique de comportements de l'application sans besoin de programmation complexe. Ce type de framework présente alors de nombreux intérêts : - intégration des APIs existantes, extensibilité facilitée ; - modularité par intégration d'autres outils (ex. projets du groupe Apache) ; - portabilité maximale, déploiement sur de nombreux serveurs d'application (structure en web application, configuration "minimale" à réaliser sur les moteurs de servlets tels que JRun, Tomcat). 15
3.2. Etude de deux frameworks 3.2.1. Pourquoi Struts et Cocoon? 3.2.1.1. Besoins Dans le cadre de notre problématique de structuration d applications web s appuyant sur les standards J2EE (extensibilité et interopérabilité accrues), il me semble intéressant de distinguer deux approches à prendre en compte : la première est orientée composant (components), la seconde documents. Ce découpage permet naturellement de couvrir une large gamme de projet. Le choix a aussi été conforté par la taille du framework proposé, sa fréquence d'utilisation, la documentation disponible (site d'origine, mailing-list d'utilisateurs, sources diverses), l'activité des développeurs (correction de bugs, nouvelles fonctionnalités). 3.2.1.2. Décisions 3.2.1.2.1. Types de frameworks retenus Le framework orienté composants qui a retenu notre attention est Struts (Apache Jakarta). Il correspond à l'association de servlets et beans pour la partie MC, et de JSPs et beans pour la partie présentation. Le framework orienté documents est Cocoon 2 (Apache Xml). Il est modulaire et permet deux orientations pour la partie Controller (utilisation d'extensible server pages, XSP, ou d'actions). 3.2.1.2.2. Versions choisies pour ces frameworks Les deux solutions retenues pour étude sont open-source et en évolution constante. Ce document risque donc de perdre assez vite une partie de son intérêt, même si la maturité de ces deux frameworks semble très bonne. Afin de mieux coller à la réalité actuelle et à venir proche, les versions les plus avancées disponibles ont été étudiées, et j'ai étudié les versions suivantes avec date de cessation de mise à jour du document : - Struts 1.1 au stade beta 1 (jusqu'à juin 2002), - Cocoon 2.1-dev (jusqu'à septembre 2002). La version de Cocoon retenue n'est pas encore largement distribuée mais disponible via CVS, les fonctionnalités nouvelles par rapport à la version 2.0.3 étant encore en développement. On peut donc parler d'une version alpha tout en sachant qu'elle est parfaitement utilisable après tests en phase de production (d'après discussions avec des utilisateurs, voir annexe 9.3.4.). J'ai commencé l'étude et la phase de développement m'appuyant sur Cocoon 2.0.3, puis décidé d'utiliser la version 2.1, sans garantie autre que la vigilance et l'évitement de composants connus comme étant encore non fonctionnels. Ces composants sont évoqués plus rapidement dans l'étude, car soumis à changements possibles. J'aurais prévu de toute façon une migration vers la version 2.1 de Cocoon dès que possible, les changements de structure de 2.0.3 à 2.1 n'étant pas très importants d'après les composants retenus. Je compte sur l'activité des développeurs de la communauté jusqu'à la mise en production du projet, afin de corriger quelques bugs. En revanche, l'évolution du projet en utilisant par exemple les XML Forms (non finalisé en septembre 2002) suppose un développement conséquent. J'anticipe donc assez peu au final, sans avoir de regrets en termes d'information des lecteurs de ce document. 16
3.2.2. Struts 1.1 b1 Remarque : cette version n'est pas la version la plus récente à la clôture de ce document (décembre 2002). 3.2.2.1. Présentation 3.2.2.1.2. Déclinaison du modèle MVC Struts a été développé pour les projets qui choisissent l'association servlets / JSPs, avec plusieurs ambitions: Ne plus utiliser les scriptlets : code java dans les JSPs, ce qui est peu lisible au milieu du code HTML, moins facilement développable, mêle une partie du traitement à la présentation. Ainsi des tags respectant globalement la norme d'écriture de XML sont utilisé lorsque les JSPs ont besoin : - d'inclure des éléments issus des beans de présentation ; - d'effectuer, non pas des traitements, mais des choix plus complexes qu'une simple inclusion. Faciliter la logique temporelle des séries d'appels entre le Controller et les deux autres couches, et la séparation du contrôle des formulaires et du traitement des informations de ceux-ci. Struts comporte donc des éléments MVC dans les trois parties : Partie Controller : servlet controller, servlets de classe ActionServlet. Partie View : JSPs incluant des tags spécifiques à Struts. Partie Model : beans de type Action et ActionForm et beans ordinaires (business logic et présentation). Le graphique suivant est issu d'une présentation de Struts par Sun en décembre 2002. 17
Diagramme de classes : Relation entre la partie Controller et Model, redessiné d après : http://www- 106.ibm.com/developerworks/library/j-struts/?dwzone=java. Diagramme de séquence : source : http://rollerjm.free.fr/pro/struts.html 18
3.2.2.1.3. Partie Controller Ce rôle est assuré par une classe dérivée des servlets : ActionServlet. Un ActionServlet est associé à un formulaire HTML (avec des tags Struts pour définir les champs) référencé par un bean de type ActionForm. Un ActionServlet est configuré par un ActionMapping. Cette configuration, définie dans struts-config.xml, permet de savoir quels éléments sont associés au ActionServlet : JSP appelante URI (path) pour l'appeler bean ActionForm pour contrôler un formulaire forwards (ActionForward) pour rediriger vers une JSP ou une autre à l'issue du traitement et suivant son résultat. 3.2.2.1.4. Partie Model Les ActionForm permettent de contrôler les formulaires : en effet dans le cas où il ne s'agit pas d'un simple contrôle de remplissage et de type des champs, la validation côté serveur est recommandée. Les erreurs sont gérées par l'ajout d'objets ActionError à une liste ActionErrors(). Cette liste est ensuite retournée à l'actionservlet. 3.2.2.1.5. Partie View Les tags utilisables dans les JSPs sont définis dans des taglibs. Il y a cinq famille de taglibs : struts-bean, struts-html, struts-logic, struts-template, struts-nested. struts-bean : permet, à l'instar de <JSP:useBean>, de manipuler les beans de présentation. struts-html : permet de simplifier la création de formulaires HTML et la gestion de leurs erreurs de remplissage en les liant à un ActionForm et un MessageResources.properties. struts-logic : permet des évaluations logiques de propriétés de beans, suivies d'actions ou d'insertion de code, à la place de scriptlets. struts-template: permet d'inclure du contenu (JSP, HTML) dans une JSP, un peu comme la directive <JSP:include>, mais en permettant de bien différencier la JSP conteneur et les JSPs contenu. struts-nested : permettent d'utiliser facilement les propriétés de beans imbriqués (le bean B est une propriété du bean A), par exemple pour construire graphiquement une structure récursive ou complexe (menu etc.). 3.2.2.1.6. Fichier de configuration Le fichier struts-config.xml contient : les mappings des actions: (section <action-mappings />) pour chaque tag <action />. Les attributs sont les suivants : - type : nom de la classe Action implémentée pour ce mapping ; - name : nom du form bean (validation de formulaire) défini par l'attribut que cette action utilise ; - path : URI de la requête qui active la sélection de ce mapping. (nom logique) ; - unknown : si à true, cette action est l'action par défaut de l'application ; - validate : si à true, la méthode validate() de l'action associée à ce mapping est appelée, c'est-à-dire qu'une validation de formulaire est effectuée ; - forward : URI de requête vers laquelle le contrôle est passé lorsque le mapping est invoqué. Alternative à la déclaration de l'attribut type ; 19
- input : URL de la JSP appelante, d'où le client envoie des paramètres ; - scope : persistance du bean : session, requête, page. les mappings des beans (section <form-beans />), associant un nom (name) à une classe (type) pour chaque tag <form-bean>. la déclaration de message-resources : fichier.properties contenant des messages texte qui seront inclus par des tags <bean:message key=" "> dans une JSP. la déclaration de data-sources permettant une liaison avec une base de données relationnelle. la déclaration de global-forwards, mapping d'uris valables quelles que soient l'action. D'autre part le descripteur de déploiement de la web application : web.xml est modifié pour que les ActionServlet soient mappés sur l'extension.do (URL d'appel) : dans la section <servletmappings /> le tag <servlet-name> a pour valeur "action" pour les ActionServlets, le tag <urlpattern> correspondant a pour valeur " *.do". En annexe 9.2.1., un exemple de fichier de configuration. 3.2.2.2. Eléments décisionnels dans le cadre d'un projet Certains éléments tel que ceux gérant l'accès à une base de données relationnelle, ou les DynaBeans (beans flexibles), ne sont pas détaillés, seulement évoqués dans le tableau du 3.2.2.4. 3.2.2.2.1. Typologie du projet Struts convient à un projet présentant une ou plusieurs des caractéristiques suivantes : - présence de formulaires à remplir par l'utilisateur avec contrôle des types/valeurs entrés dans les champs ; - une partie du code qui sera retourné à l'utilisateur est statique (HTML) ; - interaction avec une base de données relationnelles ; - présence d'un menu avec présentation visuelle différente par niveaux (usage de struts-nested). 3.2.2.2.2. Form beans Ils servent à la validation de formulaire côté serveur, c'est-à-dire qu'un traitement peut être effectué avant de retourner un message d'erreur. Les classes ActionForm permettant la vérification de formulaires retournent des objets ActionError, qui utilisent un fichier properties pour stocker les messages retournés au client lorsqu'une erreur est détectée. Ces messages peuvent être formatés en HTML (style local dans le fichier.properties). Lorsque ActionForm est défini, la méthode reset() est appelée et les données entrées dans les champs texte du formulaire d'origine sont perdues si on renvoie à l'issue de l'action sur la JSP d'origine. Or pour un utilisateur il semble normal de retrouver les données entrées en plus du message d'erreur. Une solution est de conserver les données entrées en placant le ActionForm considéré en tant qu'attribut de session et d'ôter cet attribut avant le/les forward. 3.2.2.2.3. Forwards Ce sont des facilitations d'écriture qui associent un nom logique à une URL. Ainsi le code java ne contient pas de nom de JSP "en dur". Les forwards globaux (global-forwards) sont utiles pour gérer la déconnexion ou le retour à un menu principal par exemple (scope=session, sinon scope=request). 20
Par exemple le code suivant : servlet.getservletconfig().getservletcontext().getrequestdispatcher("menu.j SP").forward(request,response); devient : mapping.findforward("menu"); 3.2.2.2.4. Taglibs Leur apport est de plusieurs ordres : - syntaxe XML dont plus facilement gérable au niveau de la maintenance du code, - remplacent les scriptlets dans certains cas, - appel "intuitif" de propriétés d'objets java, - gestion de conditions logiques à l'intérieur d'une JSP, - nesting de beans, qui associé à un appel récursif de JSP permet de faciliter la création de menus. 3.2.2.2.5. Gestion du multilangage Le multilangage n'est géré qu'au niveau de la présentation (vers l'utilisateur), et pas au niveau de l'entrée des données par l'utilisateur. Struts utilise des fichiers properties, déclarés en tant que message-resources, qui contiennent des messages plus ou moins formatés HTML, mais il est recommandé que leur longueur soit raisonnable. L'utilisation d'un fichier properties ou un autre (nom du fichier suffixé par un identifiant langue_pays d'après les codes ISO 639 et 3166) dépend de la Locale (modifiable en tant qu'attribut de session). 3.2.2.3. Addendums 3.2.2.3.1. Model 2X, extension de la partie View Une extension proposée par Julien Mercay et Gilbert Bouzeid peut être utilisée afin d'enrichir le format de sortie autorisé par Struts. Un article de février 2002 explique son fonctionnement : ajout d'un élément XSL Servlet en partie View, vers lequel le Controller (ActionServlet) redirige. Voir annexe 9.2.3. pour plus de détails. 3.2.2.4. Conclusions - Tableau récapitulatif Le tableau suivant récapitule les éléments et fonctions importantes de Struts. Elément ou fonction Rôle Avantages Inconvénients Précautions form beans, ActionForm Contrôle de formulaire (messages d'erreur inclus dans un fichier properties) ValidatorForm ValidatorActionForm Contrôle de formulaire (description du champ dans un fichier XML en utilisant les expressions régulières) contrôle complexe de champ Facilitation du contrôle de champs de formulaire Facilitation du contrôle de champs de formulaire Codage du contrôle à développer soi-même Ne convient pas aux systèmes à forte charge (un objet attribut de session par formulaire) Nécessite un.jar non inclus dans la distribution 1.1b1 : jakarta-regexp- 1.2.jar, de http://jakarta.apache.org /regexp 21
Elément ou fonction Rôle Avantages Inconvénients Précautions Dynabeans Bean dont les propriétés Pas besoin d'écrire une sont dynamiques classe java par bean, possibilité de changement de type des propriétés ActionServlet Controller Gestion de l'enchaînement des actions Forwards Beans de présentation Indique l'étape suivante (JSP après action) leurs propriétés sont récupérées dans les JSPs par les tags <bean /> Gestion du multilangage Retour à l'utilisateur en fonction de la Locale choisie BasicDataSource et struts datasource manager taglibs <html /> Accès à une base de données relationnelle Principalement encapsulation des éléments de formulaire en tant que propriétés d'un bean de type ActionForm Gestion des noms réels des JSP au niveau du fichier de configuration XML, écriture allégée. Inclusion facilitée - Ne pas mettre de business logic dans cette classe - La propriété doit être de type String - limité au niveau présentation et fichiers properties Flexibilité de configuration dans struts-config.xml Facilitation d'écriture, permet le contrôle de formulaire Méthode POST utilisée par défaut : paramètres non visibles dans l'url Gestion de l'url de base HTML (réécriture de liens, maintien de la session client sans cookies) Le getter de "value" doit être obligatoirement "getvalue()" (respect du standard java) - Confusion possible de certains attributs avec ceux du standard HTML 4.0 (même nom mais pas même fonction), rigueur nécessaire - taglibs <bean /> taglibs <logic /> Utilisation des propriétés Peut remplacer les de beans de scriptlets présentation Action ou insertion de code conditionnelle, itération taglibs <template /> Insertion dynamique de JSP/HTML taglibs <nested /> Gestion de beans de présentation imbriqués custom tags Moins de JSPs à écrire, flexibilité Permet de bien séparer la JSP conteneur et les JSPs contenu. Simplification des relations parent-enfant - - Présence de scriptlets possible, peut devenir confus (morcellement) Equivalent dans certains - cas à des séries de <JSP:include /> Limiter aux cas simples, bien commenter - N'apparaît officiellement que dans Struts 1.1 beta 1 Extension de tags à partir de javax.servlet.jsp. tagext.tagsupport Remplace des scriptlets Développement supplémentaire La fonction alors développée manque à la version de Struts utilisée - 22
3.2.3. Cocoon 2.1-dev 3.2.3.1. Présentation 3.2.3.1.1. Déclinaison du modèle MVC Cocoon est un framework ayant une approche orientée document, c'est-à-dire qu'une succession d'opérations est appliquée à un fichier ou un flux XML. Ceci est assuré par des pipelines, qui sont des suites de : - génération de flux XML à partir de sources diverses ; - transformations, par application de feuilles de style XSL ; - sérialisation, par rendu du document dans un format final. La structure de Cocoon amène le développeur à réaliser : - une structuration du sitemap (fichier de configuration) pour la logique du site ; - du code java pour les parties Model (business logic) et Controller (actions) ; - des feuilles de style XSL pour la partie View. 3.2.3.1.2. Partie Model Elle est assurée par les generators, qui produisent un flux XML à partir de : - fichier XML ou URL (file generator) ; - requête HTTP ordinaire (request generator) ; - requête HTTP (POST) avec contenu au format XML (stream generator) ; - JSP (JSP generator) ; - XSP (serverpages generator) 3.2.3.1.3. Partie Controller Les selectors, matchers, actions sont les éléments assurant la partie Controller au niveau d'un pipeline donné. 23
Si on les utilise, les pages XSP (XML Server Page) peuvent être associées à une logicsheet (XSL) : dans ce cas la logicsheet est un élément Controller et la page XSP élément Model. 3.2.3.1.4. Partie View Les transformers (XSLT, i18n, sql, log ) puis les serializers (XML, HTML, WML, fop, text ) ont pour rôle d'assurer le traitement du document XML suivant la configuration définie par un pipeline du sitemap. Ils transforment le flux d'évènements SAX en document XML (transformation) puis en document dans un format spécifique (sérialisation). En plus de transformers prédéfinis, des feuilles de style XSL sont aussi utilisables. 3.2.3.1.5. Fichiers de configuration 3.2.3.1.5.1. cocoon.xconf Ce fichier définit les composants utilisés par Cocoon (parseur XML, processeur XSLT, loggers, compilateur java, sitemap, components, gestion de la mémoire et de la recompilation ). Il sert à l'initialisation de CocoonServlet, point de départ du lancement du framework. 3.2.3.1.5.2. sitemap.xmap Un ou plusieurs sitemaps définissent l'enchaînement des opérations au niveau du site par pipelines. Il y a plusieurs sitemaps si on divise l'application en parties logiques, lesquelles se retrouvent dans l'arborescence des fichiers pour plus de clarté. La structure XML d'un sitemap comporte les éléments suivants : <?xml version="1.0"?> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0"> <map:components/> <map:views/> <map:resources/> <map:action-sets/> <map:pipelines/> </map:sitemap> Les components sont les éléments de la partie Model (generators), Controller (selectors, matchers, aggregators, actions ), View (transformers, serializers). Les views permettent de définir des "vues" orthogonales aux pipelines et indépendant d'eux (vision partielle du document, formatage spécifique). Les resources sont des définitions de pipelines réutilisables. Les action-sets sont des ensembles d'actions liées à une page. Les pipelines sont des séries d'opérations associant les différents components MVC dans un ordre défini. En annexe 9.3.2. le détail de la structure d'un pipeline. 3.2.3.1.5.3. logkit.xconf Il gère les options d'écriture de fichiers de logs, avec définition des chemins de fichiers, catégories et niveau de logging. 3.2.3.1.5.4. instrumentation.xconf Apparu courant septembre 2002, ce fichier paramètre le rapport de surveillance de la charge mémoire. 24
3.2.3.2. Eléments décisionnels dans le cadre d'un projet 3.2.3.2.1. Typologie du projet Cocoon 2 est utilisable pour un projet présentant une ou plusieurs des caractéristiques suivantes : - format final des données retournées au client diversifié : XML, HTML, PDF - présence de données déjà au format XML (facilite les choses), - base de données XML ou relationnelle (requêtes facilitées, directement à partir du sitemap pour la première, par les XSPs ou un transformer pour la seconde), - présence de formulaires à remplir par l'utilisateur avec contrôle des types/valeurs entrés dans les champs, - ressources protégées par différents moyens d'authentification. 3.2.3.2.2. XSP et Logicsheets 3.2.3.2.2.1. XSP Les pages XSP sont des documents XML sur lesquels une logique est appliquée, qu'elle soit intégrée ou externe (recommandé). Dans ce dernier cas, une XSP est plus précisément au sens strict le résultat de l'assemblage de documents XML et XSL (logicsheet). Il y a génération de contenu dynamique par association de deux types de markup XML : éléments XSP : tags de logique (xsp:logic) et de structure (xsp:structure). Ils permettent une écriture simplifiée (déclarative) de code qui sera généré lors de la compilation (au niveau du generator). Ces tags correspondent essentiellement à une logique intégrée. élément "utilisateur", de contenu (données dans le document XML produit), avec un autre namespace que xsp. Cet élément devient la racine du document XML produit. D'autres tags (issus de logicsheets) permettent de remplacer dans la mesure du possible l'écriture de fonctions (java par exemple). Ils étendent les tags XSP. 3.2.3.2.2.2. Logicsheets Les logicsheets sont des feuilles de style XSL servant de filtres XML. Elles s'appliquent à un document XML et trans forment des tags XML en bouts de code dans le langage de programmation choisi (généralement java). Le résultat intermédiaire est sous forme de XSPs avec code (java) intégré. Il existe plusieurs types de logicsheets fournies par Cocoon : accès aux données d'environnement, "utilitaires" et accès aux données et bases de données. Ces deux dernières catégories permettent de limiter l'écriture de code (java) par écriture déclarative. Une logicsheet est liée à un document XSP (XML avec namespace xsp) Soit la logicsheet est appliquée à un document XML donné par l'instruction : <?xml-logicsheet href="logicsheet..xsl"?>, soit la logicsheet est built-in, déclarée dans cocoon.xconf. 25
3.2.3.2.2.3. Méthodes de création d'une XSP Logicsheet externe Usage de taglibs 3.2.3.2.2.4. Remarques Si on utilise des instructions intégrées aux XSPs, elles ressemblent un peu aux JSPs (association de code exécutable et de markup statique) mais diffèrent essentiellement par la génération de données dynamiques et non de présentation. De plus, java n'est pas le seul langage disponible pour la partie code. D'après plusieurs débats récurrents (voir quelques extraits en annexe 9.3.5.) entre les utilisateurs de Cocoon, les XSPs devraient n'être utilisées qu'avec des taglibs, sans insertion de morceaux de code java. De même, si un projet utilise à la fois des XSPs et des Actions, comme ces éléments peuvent jouer des rôles identiques, une certaine confusion d'architecture est possible. En effet les Actions sont inscrites dans une logique lisible dans un pipeline du sitemap tandis que les XSPs réalisent une logique à un moment donné. On peut complètement se passer des XSPs dès lors qu on utilise des Actions. Personnellement j'ai choisi cette approche, mes développements nécessitent alors une plus grande variété de transformers, et aussi des extensions java si je ne développe pas de transformers spécifiques à mon application. 3.2.3.2.3. Actions 3.2.3.2.3.1. Fonctionnement Les actions (traitement par une classe java dérivée de org.apache.cocoon.acting.composeraction) ont été introduites dans Cocoon 2.0 pour mieux respecter le modèle MVC (composant Controller). 26