vers une architecture J2EE à base open source

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

Migration du portail de gestion des licences produits de Software AG B. Post – Software AG France - 2002

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 B. Post – Software AG France - 2002

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 de l'application de gestion des licences produits de Software AG B. Post – Software AG France - 2002

5

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.


6

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é :

§ 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.

étude de cadres de développementaide à l'extension B2B, étude de moteurs de servlets. durée effective : 3 semainesanalyse 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)

11/0207/02 08/02 09/02 10/0203/02 04/02 05/02 06/02


7

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 Java-based 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


8

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 4e 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.


9

§ 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.

BIS Philippe TOUBERT

Directeur de projets Joël MILGRAM

Contrôle de gestion Hanifa BOUASSRIA

Commercial Gilbert TOMASSO

Professional Services (en cours de pourvoi)

BITS Philippe TOUBERT

BOS François-Xavier DELASSUS

Responsable d'agence Sylvie MORANGE

Responsable d'agence Dominique HUBERT

Directeur de projets Philippe BUISSON

Directeur de projets Isabelle BERTINET

Assistantes

Support Michel DOUCET


10

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 plate-forme 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).


11

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

CSCs R&D Quality Engineering

Product Manager

LSCs

Serveur de test LK

Serveur de prod. LK

Dév. SAGF

Admin. CIS

Tamino XML DB Tamino XML DB


12

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).


13

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).


14

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


15

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).


16

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.


17

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.


18

§ 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


19

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 ;


20

- 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 <servlet-mappings /> le tag <servlet-name> a pour valeur "action" pour les ActionServlets, le tag <url-pattern> 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).


21

Par exemple le code suivant : servlet.getServletConfig().getServletContext().getRequestDispatcher("menu.JSP").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)

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)

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

Nécessite un .jar non inclus dans la distribution 1.1b1 : jakarta-regexp-1.2.jar, de http://jakarta.apache.org/regexp


22


Rôle

Avantages

Inconvénients

Précautions

Dynabeans Bean dont les propriétés sont dynamiques

Pas besoin d'écrire une classe java par bean, possibilité de changement de type des propriétés

ActionServlet Controller Gestion de l'enchaînement des actions

- Ne pas mettre de business logic dans cette classe

Forwards Indique l'étape suivante (JSP après action)

Gestion des noms réels des JSP au niveau du fichier de configuration XML, écriture allégée.

-

Beans de présentation leurs propriétés sont récupérées dans les JSPs par les tags <bean />

Inclusion facilitée La propriété doit être de type String

Le getter de "value" doit être obligatoirement "getValue()" (respect du standard java)

Gestion du multilangage Retour à l'utilisateur en fonction de la Locale choisie

- limité au niveau présentation et fichiers properties

-

BasicDataSource et struts datasource manager

Accès à une base de données relationnelle

Flexibilité de configuration dans struts-config.xml

taglibs <html /> Principalement encapsulation des éléments de formulaire en tant que propriétés d'un bean de type ActionForm

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)

- 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 /> Utilisation des propriétés de beans de présentation

Peut remplacer les scriptlets

- -

taglibs <logic /> Action ou insertion de code conditionnelle, itération

Moins de JSPs à écrire, flexibilité

Présence de scriptlets possible, peut devenir confus (morcellement)

Limiter aux cas simples, bien commenter

taglibs <template /> Insertion dynamique de JSP/HTML

Permet de bien séparer la JSP conteneur et les JSPs contenu.

Equivalent dans certains cas à des séries de <JSP:include />

-

taglibs <nested /> Gestion de beans de présentation imbriqués

Simplification des relations parent-enfant

- N'apparaît officiellement que dans Struts 1.1 beta 1

custom tags 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

-


23

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é.


24

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.


25

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.


26

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).


27

Elles ont pour fonction d'effectuer quelque chose par utilisation de beans de business logic, et en retour renseigner une map (ensemble de paires clé – valeur) qui définit l'état du système. En cas d'erreur le retour est une map nulle, même si on peut programmer l'inverse dans les actions définies par un développeur pour un projet spécifique : retourner null en cas de succès, sinon un code d'erreur.

3.2.3.2.3.2. Liaison avec le sitemap La map permet la communication entre les actions et le sitemap. Ce dernier utilise la valeur des paramètres de la map en tant que variables, par exemple : <map:act type="my-action"> <map:generate src="{source}"/> <map:transform src="doc2{theme}"/> <map:serialize/> </map:act> La valeur de l'attribut src est celle du paramètre "source" de la map retournée par l'action. De plus, si la map est nulle, le contenu du tag <map:act /> n'est pas exécuté. Il y a donc un contrôle de flux par le sitemap.

3.2.3.2.3.3. Persistance d'états Les maps successives sont "empilées", accessibles par une expression de chemin (path) {../../ …}. Cette expression contient le nom du paramètre ou le code logique (nombre entier) lui correspondant (position de(s) étoile(s) dans la ligne antérieure match pattern="…"). Si des paires clés-valeurs correspondent à la même clé dans des maps successives, seule la dernière valeur est gardée. Cette persistance de paramètres n'est valable qu'à l'intérieur d'un tag <map:match />.

3.2.3.2.3.4. Remarques Les Actions ne peuvent en principe gérer que des paramètres de sitemap et des traitements java, pas s'occuper de génération d'XML. Il y a donc une bonne séparation des notions, les Actions réalisant un bon Controller. Cependant il existe des Actions utilisant DOM, alors il y a manipulation d'XML. On rappelle que Cocoon est basé sur un traitement SAX des flux XML (plus rapide, consomme moins de mémoire que DOM).

3.2.3.2.3.4. Action-sets On peut définir des action-sets, c'est-à-dire un ensemble d'actions, chacune appelée par un champ HTML input de type submit différent, sur une même page (définie par une URI).

3.2.3.2.3.5. Avantages L'intérêt des actions est donc d'avoir un composant Controller permettant : - l'appel au business logic, - la simplicité d'écriture de la logique des opérations à entreprendre et du retour d'informations, - la persistance d'informations contenues dans une map (état présent et états antérieurs). Par ailleurs, les paramètres d'une map peuvent être récupérés par une feuille de style XSL. (partie View).

3.2.3.2.4. Pipelines La logique de traitement est incluse dans la structure du pipeline (ains que les éventuelles logicsheets). Les pipelines peuvent en utiliser d'autres, ce qui permet une réutilisation maximale ainsi qu'une granularité du système.


28

3.2.3.2.5. Matchers Ils permettent de décider conditionnellement de l'exécution d'un fragment de pipeline, en fonction de l'URI de requête.

3.2.3.2.6. Selectors Ils étendent les matchers : la logique n'est plus booléenne mais multiple.

3.2.3.2.7. Multilangage Le multilangage est géré par un transformer i18nTransformer. Les tags XML dont le contenu dépend de la langue ont pour namespace i18n. Le terme i18n vient du nombre de caractères entre "i" et "n" dans l'alphabet européen, et i18n correspond à une standardisation de la gestion du multilangage. Le transformer i18n récupère les valeurs dans un dictionnaire au format XML (structure en annexe 9.3.3.), et les dictionnaires sont déclarés par ordre de préférence. Des paramètres peuvent être pris en compte dans le texte à traduire (dans un tag <i18n:text />), et eux-mêmes traduits ou non (généralement pas nécessaire). De même, une date (par exemple) peut être formatée en utilisant une Locale.

3.2.3.2.8. Portail d'authentification Dans la version 2.1 de Cocoon, un portail d'authentification est à présent complètement intégré aux autres composants de Cocoon (au niveau de la syntaxe, namespaces). Il s'agissait, dans la version 2.0.3 étudiée au préalable, de composants du "scratchpad" (pièces de projet non complètement intégrées ou sujettes à évolutions majeures). Ce portail, anciennement connu sous le nom de SunRise Portal ou SunRise Components, est un projet stable et indépendant offert au projet Cocoon en janvier 2002, et permettant de gérer : une session, différents mécanismes d'authentification des utilisateurs par handlers, des rôles d'utilisateurs. Ainsi on peut avoir, dans un même pipeline, des parties protégées par des moyens d'authentification différents : base de données, LDAP, voire simple test, ainsi que des parties accessibles sans authentification. L'écriture et la lecture des informations de session (session context) se fait à l'aide de code XML et d'un transformer (session). De même, d'autres contexts peuvent être définis, et sont persistants comme la session. Il est ainsi facile de gérer des informations devant être transmises au-delà d'une simple section de pipeline (map:match).

3.2.3.2.9. Intégration du standard XForms Les XML Forms de Cocoon (d'après le standard XForms du W3C, Working Draft 1.0 publié en août 2002) permettent une liaison facilitée entre un formulaire au format XML, un contrôle de formulaire à l'aide de schémas XML, et un passage des informations entrées sur ce formulaire vers des beans java. Ce composant est lors de la rédaction de ce document (octobre 2002) en phase d'élaboration donc pas immédiatement utilisable.


29

3.2.3.3. Conclusions - Tableau récapitulatif Le tableau suivant récapitule les éléments-clés ou fonctions de Cocoon.


Rôle

Avantages

Inconvénients

Précautions

Sitemap définition et logique des processus

format XML décomposable en sous-sitemaps (un par répertoire). appel direct aux bases de données XML peut être rechargé sans avoir à redémarrer le moteur de servlets en cas de changement

- structure assez lourde (nombreuses sections), quelquefois bugs lors d'utilisation de sous-sitemaps et de liaisons vers le sitemap principal.

Actions Appelle et contrôle le business logic, renseigne un état (map)

Persistance des informations de la map Possibilité d'usage d'un état antérieur

- Lors d'actions empilées, accès au bon paramètre par un path

Transformers Applique une feuille de style à un document XML

Possibilité d'emploi en cascade Très grande modularité de la fonction effectuée

- -

Matchers, selectors Conditionnent l'exécution d'un fragment de pipeline en fonction de l'URI de requête

Usage possible de wildcards ou de paths

- -

Gestion du multilangage Utilisation de la langue et/ou de la Locale spécifiées

Utilisation de dictionnaires au format XML pour la langue Préciser le formatage initial (date etc.) élimine des risques d'erreur

- -

Contrôle de formulaire par expression régulière (fichier XML) et code java dans une XSP

- -

Le code java de contrôle est mêlé à l'écriture en elle-même du formulaire (XSP)

-

Contrôle de formulaire par FormValidator Action et fichier descriptif XML

- Format XML logique booléenne globale lisible dans le sitemap

Nécessité de répéter dans le sitemap la partie de code générant le formulaire (première génération, générations suivantes)

Associer un SimpleForm Transformer pour conserver les paramètres de requête http

Accès à une base de données

- API XML:DB, ou taglibs ESQL facilitant les requêtes

Nécessité d'utiliser les XSPs pour accéder aux BDD relationnelles

-

Système d'authentification

Gestion de ressources protégées par authentification et session

Flexibilité du mode d'authentification par handlers qui peuvent varier suivant les bouts de pipeline. Entre la phase de test et celle d'authentification réelle, seul besoin de modifier un handler.

- -


30


Rôle

Avantages

Inconvénients

Précautions

Portail d'authentification Personnalisation en fonction des utilisateurs et gestion de leurs droits

Rapidité de mise en œuvre Grande flexibilité et interactivité

3.2.4. Comparaison de Struts et Cocoon

3.2.4.1. Cinématique – partie Controller On considère l'enchaînement des états d'une application. Pour Struts, cela est géré par les Actions, pour Cocoon, soit par le sitemap, ses paramètres et les Actions, soit par l'association XSPs-logicsheets.

3.2.4.1.1. Détermination de l'état suivant Dans Struts, c'est le code java du ActionServlet qui gère l'état suivant (lien logique vers une JSP), le mapping par les fichiers struts-config.xml et web.xml définit quelle classe ou JSP est associée au mapping.findForward([nom_logique]) renvoyé par ActionServlet. Les XSPs – logicsheets de Cocoon déterminent l'état suivant par logique booléenne associée à des traitements. Avec les Actions, en revanche, un état (map) est retourné au sitemap, et c'est ce dernier qui gère à la fois l'action suivante ainsi que le mapping de nom logique.

3.2.4.1.2. Flexibilité de configuration Si on veut modifier l'issue de l'exécution d'une action, par exemple : § avec Struts il faudra modifier au moins le nom de la JSP associée au mapping choisi dans

struts-config.xml, sinon le code java. § avec Cocoon, utilisant les Actions, il suffit d'éditer le pipeline considéré en modifiant l'URI appelée.

Le fichier XML est automatiquement rechargé par Cocoon si les attributs reload-method et check-reload du sitemap sont correctement spécifiés (ils le sont par défaut). Il n'y a donc qu'un fichier XML à modifier.

3.2.4.1.3. Cardinalité de la logique Une Action de Struts permet de sélectionner un état suivant parmi les n définis dans le mapping de cette Action. L'association Action – sitemap de Cocoon agit à deux niveaux : § sélection de un état parmi n suivant les paramètres de la map (par le sitemap) ; § logique booléenne supplémentaire : si l'action renvoie une erreur (map nulle) alors le sitemap

n'exécute pas une partie de pipeline.

3.2.4.2. Présentation – partie View Les XSPs de Cocoon associées aux logicsheets étendent en quelque sorte le concept des JSPs et des tags struts-logic, pour un contenu XML au lieu de HTML, mais ne sont pas la phase finale du processus (transformers, serializers), contrairement aux JSPs.


31

Cocoon, de part sa structuration en couches successives de transformation / formatage, offre une plus grande modularité et permet par exemple aussi bien d'appliquer une feuille de style CSS classique à un document HTML ou XML que XSL à un document XML. Il peut produire un grand nombre de formats de sortie (extensible). Struts en revanche ne permet qu'une sortie HTML, si on n'utilise pas l'extension proposée par Julien Mercay et Gilbert Bouzeid (annexe 9.2.3.).

3.2.4.3. Fréquence et type d'usage sur les sites internet

3.2.4.3.1. Cocoon

3.2.4.3.1.1. Historique d'expansion Dès juin 2001 on trouve des annonces datées de mises en ligne de sites construits avec Cocoon (à 95% la version 2) sur la mailing-list, en plus de sites non datés sur le site d'Apache. L'existence effective de ces sites a été vérifiée début novembre 2002. 71 sites permettent une évaluation de la situation. Période (trimestre) Q2-01 Q3-01 Q4-01 Q1-02 Q2-02 Q3-02 ? Q4-02 Nb de nouveaux sites annoncés au moins 3 5 6 8 27 21 2 au moins 3 Dans la moitié des cas on peut rattacher un site à un pays, par une extension de domaine nationale ou la langue d'origine non anglaise. On peut caractériser un usage par : - l'Allemagne, en nombre (à cause de l'origine du portail "Sunrise" ou d'un fort usage de l'open source

?) ; - le reste de l'Europe par ordre d'importance : Grande-Bretagne, Espagne, Portugal, France,

Belgique, Autriche, (Grèce, Norvège, Pays-Bas, Suisse : un seul site) ; - la Russie.

3.2.4.3.1.2. Types de sites On reprend les données du point précédent. Cocoon est utilisé en majorité pour des sites à contenu informationnel : corporate, d'actualités, présentant un catalogue, autres catégories.

Trimestre Q2 01

Q3 01

Q4 01

Q1 02

Q2 02

Q3 02

Q4 02

? Total

annuaire 1 1 1 1 4 content management system 1 1 2 catalogue 5 7 1 1 14 e-commerce (avec catalogue) 1 1 2 information généralis te, actualités 1 1 8 3 1 14 information corporate 2 4 2 8 3 1 20 information associative, éducative, scientifique (sites plus petits que info. généraliste)

1 4 4 9

place de marché - emploi 2 2

3.2.4.3.2. Struts

3.2.4.3.2.1. Historique d'expansion Dans le cas de Struts, on dispose d'une liste de sites en ligne avant juillet 2002, et des informations de la mailing-list après cette date. L'existence des sites est vérifée début novembre 2002. Période avant juillet 2002 juillet-novembre 2002 Nb de nouveaux sites annoncés 20 6


32

3.2.4.3.2.2. Types de sites Struts est utilisé principalement pour des portails d'information généraliste ou corporate, des sites d'e-commerce ou affiliés, des places de marché.

Trimestre avant juillet 2002

juillet-novembre 2002

Total

catalogue 1 0 1 e-commerce (avec catalogue) 1 3 4 transactionnel 2 0 2 information généraliste, actualités 3 1 4 information corporate 8 0 8 information associative, éducative, scientifique (sites plus petits que info. généraliste)

1 0 1

e-gouvernement 0 2 2 place de marché – emploi, biens 3 0 3

3.2.4.4. Conclusion – différences techniques entre les deux frameworks

Elément Struts Cocoon

Méthode et format de sortie Taglibs dans des JSPs. Granularité au niveau des JSPs. HTML (tous formats avec une extension supplémentaire)

Une ou plusieurs transformations suivies d'une sérialisation. Granularité au niveau des morceaux de pipeline et des feuilles de style XSL. tous formats

Gestion de la granularité de la succession d'actions / transformations

Au niveau du code java avec association nom logique – fichier dans struts-config.xml

Centralisée au niveau du ou des sitemaps (clarté) sitemap.xmap

Flux géré par des actions successives

Flux créé par chaque JSP, un servlet ne pouvant processer l'output d'un autre servlet

Un seul flux XML (évènements SAX)

Contrôle de formulaires Par code java spécifique (ActionForm) ou fichiers XML (expressions régulières) Problème de charge possible par utilisation d'objets de session

Par code java spécifique (XSP) et fichiers XML (expressions régulières) Par Form Validator et fichier XML (expressions régulières) Par XForms

Persistance Attributs de session Paramètres de map

Eléments du multilangage stockés dans :

fichiers properties dictionnaire xml

Le développement utilise : Java, taglibs spécifiques, JSP Java, XML, XSL

Extensibilité Taglibs ou actions Tous les composants MVC Accès à une base de données - Accès facilité par l'API XML:DB pour les BDDs

XML, ou ESQL pour les BDDs relationnelles Système de portail avec gestion de session, de l'authentification et du rôle des utilisateurs, de ressources

- Composants issus d'un projet indépendant et stable (prévu au départ pour être commercial), donné au projet Cocoon en janvier 2002

3.2.5. Conclusions – comment choisir

3.2.5.1. Approche composants ou documents Une approche documents (Cocoon) est plus riche. Elle semble avoir le plus d'avenir (traitement de bout en bout de flux XML) et proposer le plus de modularité (justement parce qu'elle repose sur un standard ouvert et en évolution). De plus, de nombreux éléments facilitant les développements sont intégrés au projet : portail d'authentification depuis janvier 2002, transformers permettant l'utilisation facilitée de LDAP et bases de données…


33

Une approche components peut nécessiter une extension XSLT comme proposé pour Struts, mais alors le modèle perd une part de son intérêt puisqu'il est hybride, l'approche documents pourrait faire la même chose plus efficacement (pas de passage explicite de java beans à de l'XML). Cette approche est intéressante pour l'adoption du modèle MVC pour des applications de petite taille, où les données XML sont réduites en taille et en nombre.

3.2.5.2. Eléments de choix d'un framework ou d'un autre On peut caractériser les projets par leur type, ce qui est plus parlant pour la plupart des clients, ou par une analyse de leurs caractéristiques. Le tableau suivant détermine quelles approches sont valables pour certains types de projets.

Type de projet

Exemples Documents avec Cocoon

Exemples Composants avec Struts

Approches recommandées

Content management http://www-eng.tp.edu.sg www.guene-fraktion.de

? Documents recommandée : - plus axée sur le format XML que l'approche composants - meilleure intégration avec des bases de données - intégration de composants hétérogènes autour du format XML

Catalogue http://damocles.uc3m.es/TC www.cupva.cbim.it www.ccel.org

www.amalregistry.webhop.org

Documents recommandée : - plus axée sur le format XML que l'approche composants - meilleure intégration avec des bases de données

Site web d'information type annuaire

http://dir.salon.com, www.segelflug.de/vereine

Au choix, mais l'approc he documents permet : - meilleure prise d'information à partir d'autres sites - peut-être rapidité d'exécution plus grande

e-gouvernement ?

www.myfloridacounty.com


Site web d'information type portail – corporate, culturel, politique…

www.teratext.com www.cbossbilling.com www.corrocean.com

www.basebeans.com www.bug-track.com www.jcorporate.com www.reviewalert.com

Au choix

Site d'e-commerce www.orderupdelivery.com www.lofex.de

www.brittania-music.co.uk http://shop-t-mobile.com

Au choix

Place de marché – emploi, biens

www.workthing.com www.bethe1.com

www.readymindsjob.com www.militaryhire.com www.ironmax.com


Customer Relationship Management

sites d'e-commerce sites d'e-commerce Au choix

Site transactionnel License Key Application www.fixafest.nu www.ipipi.com

Documents recommandée en cas de : - forte flexibilité nécessaire au niveau du format - existence d'une base de données XML

e-learning http://zeus.fullcoll.edu/timekeeper ? Au choix

Le tableau suivant s'efforce de cerner les besoins rencontrés dans la plupart des projets, ainsi que la manière dont Cocoon et Struts y répondent ou non.


34

Besoin du projet

Struts (approche components)

Cocoon (approche documents)

Points forts Points faibles Points forts Points faibles

Format de sortie : HTML

Ecriture simplifiée de code HTML

limité à l'usage de JSPs avec leur inconvénient : si la page de sortie nécessite de nombreux beans : long à coder, charge mémoire, risques d'erreurs accrus

Traitement direct d'une page XML par une feuille de style XSL

-

Autres formats de sortie : PDF, XML, WML, texte…

- Génération annexe d'autres formats

Génère nativement des formats diversifiés : XML, HTML, PDF, WML, texte…

-

Contrôle de formulaire

Séparation claire du contenu du formulaire, du message à renvoyer en cas d'erreur, du code de contrôle

Contrôle par code java ou expression régulière (un choix par formulaire). Problème de charge mémoire possible si nombreux formulaires (attributs de session)

Contrôle par code java si nécessaire en plus d'expression régulière Autres solutions : Form Validator, XForms

Une partie du code de contrôle peut être mêlée au contenu du formulaire (XSP) pour la première solution

Rendu final en plusieurs langues

Un fichier properties par locale Messages peu structurés Messages structurés dans un dictionnaire XML Traduction très granulaire possible

Dans la version 2.0.3 un seul dictionnaire est supporté, mais il existe un outil de concaténation de dictionnaires

Accès LDAP - - LDAP Transformer : tags simplifiant l'écriture des fonctions LDAP

Accès à une base de données

Le composant Controller peut accéder à une base de données relationnelle de manière facilitée par BasicDataSource (configuration flexible)

Performance non optimisée pour ce composant

Facilitation d'écriture de XSP par ESQL. Résultat de requêtes au format XML grâce à SQL Transformer Intégration avec toute base de données XML (Xindice, Tamino...) si le driver XML:DB existe.

-

Système de portail personnalisable

- - Inclus dans le framework

Moteur de recherche

- - Intégration avec Lucene

-

Développement en parallèle

Grâce aux Application Modules

Nécessite beaucoup de coordination et de rigueur

Facilité par : - le fonctionnement

des feuilles de style XSL

- la structuration des parties de pipeline

-

3.2.5.3. Extensibilité des frameworks étudiés Les frameworks étudiés ont une certaine extensibilité, autre que celle apportée par les changements de version : un développeur peut, pour Struts, créer ses propres tags, et pour Cocoon définir ses propres components. Des fonctionnalités très intéressantes sont disponibles dans les versions beta, par exemple struts-nested à partir de Struts 1.1 beta. Cela m'a conduite à étudier finalement cette version de Struts, ayant démarré avec la version 1.0.2.


35

De même, pour Cocoon, de nouveaux transformers sont disponibles et stables dans la version 2.1-dev. Il y a quelques autres fonctionnalités intéressantes, pas forcément finalisées (global-parameters de sitemap, Input Modules, support du standard XForms…). De plus, Cocoon semble plus facilement intégrable avec d'autres outils open-source du groupe Apache qui reposent sur des standards récents : base de données XML Xindice, moteur de recherche Lucene, utilisation directe du standard XForms du W3C par les XMLForms (dès la version 2.1) … Comme ces outils sont développés en open-source, il est possible de prendre le tout dernier état de développement (le code étant le plus souvent fonctionnel) (nightly build ou dans le serveur de développement partagé CVS (concurrent version sharing, voir annexe 9.7.1.) ou bien une version beta ou non. Les développements spécifiques réalisés peuvent être soumis à la communauté de développeurs pour approbation. De même, des développements spécifiques peuvent être éventuellement spécialement effectués pour résoudre un problème posé, ou un développeur peut aiguiller un utilisateur vers un composant ou un autre, lors d'échanges sur la mailing-list. La réactivité de la communauté est très grande.

3.2.5.4. Remarques sur l'intégration § Les deux types de frameworks présentent une facilité d'intégration semblable avec les serveurs

d'application, mais cela est dû à leur adoption du standard J2EE. § Etant deux projets Apache avec une licence de style BSD, il n'y a aucun problème en ce qui

concerne leur usage au sein d'un projet commercial. La licence Apache doit seulement être maintenue dans le code originel du framework.

3.2.5.5. Organisation, point de vue personnel Lors de cette étude menée seule j'ai réalisé quelques développements afin de mieux appréhender le fonctionnement du framework (struts nested…). J'ai passé beaucoup de temps à échanger avec les autres utilisateurs de Struts (mailing-list), tant au niveau de l'aide demandée que de discussions de concepts plus généraux. En ce qui concerne Cocoon, la mailing-list m'a également été d'une grande utilité puis, maîtrisant le produit, j'ai pu à mon tour assister les utilisateurs novices. Par ailleurs, lors de la mise en place de Tomcat et Cocoon, un collègue, Jérôme Marc, m'a aidée à résoudre une incompatibilité de parseur XML (Xerces).


36

4. Migration du projet License Key Application/BAE Le portail BAE est utilisé par les centres logistiques et de support client de Software AG ainsi que des partenaires (B2B) afin de gérer les licences produits. Software AG France en est le maître d'œuvre. Le passage de l'environnement de développement Bolero à un standard J2EE reposant sur un framework open source a nécessité plusieurs étapes :

- analyse de ce système complexe ; - évaluation, en collaboration avec M. Milgram, de la faisabilité et la charge de la refonte

d'architecture basée sur l'un ou l'autre des frameworks précédemment étudiés ; - exposition des éléments caractéristiques de la nouvelle architecture ; - documentation technique du développement que j'ai réalisé ; - critique, sur demande de M. Milgram, des outils et méthodes que j'ai utilisés, dans la perspective

d'autres projets ; - chiffrage de l'ensemble du projet, réalisé par M. Milgram ; - planning prévisionnel et calendrier, en collaboration avec M. Milgram.

4.1. Description et analyse de l'existant Je me suis basée sur le manuel administrateur pour avoir une vue d'ensemble du projet puis sur le code afin d'en appréhender tous les éléments et fonctions. J'en expose les fonctionnalités, l'exploitation, les données et leurs traitements, les changements induits par l'extension B2B. Enfin je caractérise le niveau de séparation des concepts MVC. En annexe 9.4.1 quelques copies d'écran donnent une idée de l'aspect visuel de l'application.

4.1.1. Architecture

4.1.1.1. But Le portail License Key Application permet une administration sur plusieurs plans : - les licences qui peuvent être créées, invalidées/revalidées, envoyées par email ou affichées après

recherche… ; - les modèles de document (templates) définissant les licences ; - les acteurs habilités à gérer ces licences, par le biais d'un annuaire LDAP.

4.1.1.2. Outils L'ensemble est un serveur d'application, organisé autour de : - IIS 4 : serveur web ; - JRun 2.3.3 : moteur de servlets ; - Tamino 3.1.1 : base de données XML de Software AG ; - Netscape Directory Server 4.2 : annuaire LDAP ; - Bolero 2.1.1 : environnement de développement (IDE) de Software AG dont le langage est proche

de java, et qui permet de produire du bytecode, et si besoin des sources java (formatage imparfait, classes spécifiques à Bolero).

Bolero permet le développement et la compilation des classes du projet. JRun assure l'exécution de sa partie dynamique en mode client-serveur et IIS est la façade HTTP. Tamino et Netscape Directory Server stockent des informations dynamiques relatives aux objets (licences, structures) ou utilisateurs du projet.


37

4.1.1.3. Fonctionnalités

4.1.1.3.1. Sécurité, authentification, persistance La sécurité, l'authentification est gérée par la connexion à l'annuaire LDAP. SSL est implémenté pour l'utilisation en web service (B2B). La persistance des informations est assurée par une session HTTP, sans usage de cookies. Un seul cookie est utilisé par un code javascript assurant la présentation du menu principal de l'application : les sous-menus apparaissent dans l'état précédent (masqués ou visibles) lorsque le client revient à ce menu. Si les cookies ne sont pas acceptés par l'utilisateur cela signifie simplement que le menu reprend son aspect par défaut.

4.1.1.3.2. Génération de licences Une série de formulaires permet de générer les licences, les télécharger ou envoyer par email. Il y a plusieurs cas de figure :

- licences normales ; - licences "free" générées seulement par les CSCs et la R&D. Dans ce type de licences tous les

champs de formulaire sont modifiables, ce qui permet de faire des tests sans avoir besoin de définir de nouveaux templates de licences ;

- licences en masse, dans le cas d'un ensemble de licences pour un même produit.

4.1.1.3.3. Recherche de licences Une série de formulaires permet d'effectuer des recherches puis télécharger ou envoyer par email le résultat (licences). Il y a plusieurs cas de figure : recherche simple ou multiple, par remplissage de formulaire ou ligne de commande X-Query.

4.1.1.3.4. Administration de licences Une licence peut être annulée, réactivée. On peut aussi consulter les statistiques relatives aux licences.

4.1.1.3.5. Administration du site La partie administration du site permet, d'une part, de modifier la plupart des structures des documents XML (par templates), assurant une flexibilité maximale et une bonne évolutivité au niveau des produits, d'autre part, par accès administrateur LDAP, de consulter et gérer les utilisateurs et droits.

4.1.1.4. Exploitation Plusieurs serveurs configurés identiquement pour JRun, IIS, Tamino, LDAP, sont utilisés, ils appartiennent à l’intranet de Software AG (localisés en Allemagne) : - "server 16" : serveur d'homologation ; - "server 17" : serveur de production ; - "server 11" : serveur utilisé pour les partenaires ; - "server 12" : serveur de test temporaire. La maintenance suppose donc une bonne documentation des procédures de mise à jour, et que celle-ci soit réalisable rapidement et de manière fiable.


38

4.1.1.5. Structure et organisation des données

4.1.1.5.1. Annuaire LDAP Il contient les informations nominatives (société, nom, langue, login, password…) ainsi que les droits d'accès, de chaque utilisateur autorisé. Des droits sont affectés à chaque groupe d'utilisateurs (= société), et au sein d'un groupe un utilisateur peut avoir des droits supplémentaires.

4.1.1.5.2. Fichiers XML dans Tamino Les documents XML contenus dans cette base de données sont de plusieurs ordres, correspondant à l'usage et à l'administration. Il y a : § la description de :

- produits et plug-ins (<licKeyCatalog/>), environ 190 produits détaillés (version, système d'exploitation, fonctionnalités…) ; - plate-formes (<productPlatform />) ; - templates (<Template/>), qui définissent la structure des données de produit, plate-forme… (tags, valeurs par défaut, dépendance entre certaines valeurs) ;

- la structure du sommaire de l'aide en ligne (<OLH_DocList />) § l'énumération des droits d'utilisateur (items du menu, fichier access.xml) § les codes et messages d'erreur, gérés en plusieurs langues, avec action d'envoyer un e-mail ou

non à l'administrateur du site (error.xml) § les labels et messages interactifs gérés en plusieurs langues (mlForm.xml) § l'arborescence du menu et les éléments (niveau, image, lien, message d'aide) associés à chaque

item (mlMenu.xml)

4.1.1.5.3. Fichiers de traitement Ils sont composés de servlets (classes java), qui utilisent des beans de business logic pour traiter les données : input utilisateur, données issues de ou vers LDAP et Tamino. De plus, deux dlls (saglic.dll et SAGLICWrap.dll) permettent de générer une signature MD5 (chiffrement) à partir d’un fragment de document XML (passé en tant que chaîne texte) représentant les informations spécifiques à une clé de licence. La signature est ensuite ajoutée à ce document et constitue la clé de licence proprement dite. Ces dlls sont dans le path de l’application, des méthodes java natives permettent de les appeler.

4.1.1.5.4. Fichiers de présentation L'essentiel de la présentation est assuré par les servlets (code HTML et données issues des traitements). Ils utilisent du contenu statique : une page HTML de démarrage, des feuilles de style XSL, une feuille de style css, un fichier javascript externe (.js), des images.

4.1.1.5.5. Composants annexes § un fichier bae.properties placé à la racine du disque C: contient des paramètres généraux

spécifiques au serveur utilisé. § une ASP redirige vers la page d'accueil par IIS en cas de mauvaise URL demandée. § un contrôle ActiveX est utilisé pour personnaliser l'impression de la carte de licence.


39

4.1.1.5.6. Sur les serveurs Les données présentes sur le disque dur des serveur et utilisées par les serveur web et moteur de servlets sont structurées de la manière suivante, sachant que le dossier BAE est un dossier racine du système de fichiers Windows, mais pas dans la partition C: : § les classes sont dans BAE\Classes. § les jars sont pour partie dans BAE\Classes, pour partie dans les répertoires d'installation des

logiciels Bolero et Tamino. § les dlls sont dans BAE\licenseKey. § le contenu hors classes servi par le serveur web est dans BAE\wwwroot. § le fichier bae.properties est en revanche à la racine de C:.

4.1.1.6. Traitement et présentation des données

4.1.1.6.1. Données au format XML L'accès en lecture-écriture aux données stockées dans Tamino se fait par requêtes X-Query à l'intérieur des servlets. Ce langage est proche de la norme XQuery (basée sur XPath) du W3C (Working Draft 1.0 XQuery du 16 août 2002). L'API Tamino Http Client est utilisée, or son développement est abandonné au profit de Tamino API For Java, qui sera la seule API utilisée par les versions ultérieures de Tamino.

4.1.1.6.2. Moteur de servlets (JRun) et serveur web (IIS) JRun (version 2.3.3) est un moteur de servlets, qui permet d'exécuter du code java compilé du côté serveur dans le modèle client-serveur. L'utilisation d'un filtre ISAPI permet à JRun d'intercepter les requêtes vers des servlets (URL commençant par /servlet/), le serveur web IIS (version 4) assurant le service des pages (statiques ou dynamiques).

4.1.1.6.3. Accès LDAP L'annuaire LDAP utilisé est Netscape Directory Server 4.2 (LDAP v 3.0), et les classes java utilisées font partie du Netscape SDK 3.0. Les données sont formatées ensuite en un document XML. Cependant il y a un accès LDAP à chaque fois qu'un droit doit être vérifié, les droits ne sont pas stockés au cours d'une session.

4.1.1.7. Modification : ajout de l’extension B2B, passage à JRun 3.1 L'extension B2B ne pouvait fonctionner avec la version 2.3.3 de JRun. J'ai réalisé une étude et des tests concluants de compatibilité de l'existant sous JRun 3.1 (voir annexe 9.5.1. pour la configuration que j'ai définie), L'existant a été structuré en partie en web application : tous les jars ont été rassemblés dans BAE\wwwroot\WEB-INF\lib, le dossier BAE\wwwroot étant à la fois la racine de la web application et celle du site pour le serveur web. Pour le B2B, un produit de Software AG : EntireX XML Mediator v7.1.2 (appelé anciennement EntireX Orchestrator XML) a pu être utilisé. Il permet la structuration de web services, de rediriger les messages SOAP entrants (issus de clients sur les sites partenaires) en fonction de leur contenu, vers le bon servlet pour traitement.


40

4.1.1.8. Caractérisation du respect du modèle MVC Avant toute chose et comme je me base sur un modèle MVC pour la nouvelle structure, j'ai estimé utile de comparer l'existant à ce modèle. De plus, la lecture méthodique permet de préciser les fonctions de chaque élément. Les deux types de classes, beans et servlets, sont organisés en packages. Les rôles de chaque composant au sens MVC sont parfois mal définis. Un inventaire est proposé en annexe 9.4.2. Il y a une cinquantaine de beans et une centaine de servlets. Pour chaque composant on indique son type, son package, son nom (court), la fonction qu'il réalise, s'il est plutôt au niveau Model, Controller ou View, ainsi que le servlet qui l'appelle, s'il s'agit d'un servlet. L'annexe 9.4.3. propose un schéma récapitulant l'enchaînement fonctionnel des servlets.

4.1.1.8.1. Beans : essentiellement Model Les beans sont des classes exécutant un traitement, et dont les propriétés sont normalement accessibles par des méthodes get / set. En réalité d'autres méthodes de traitement retournent des résultats. Ces objets ne renvoient cependant rien directement au client. Certains beans effectuent suivant les méthodes du traitement pur ou du traitement et de la présentation (ex. : code HTML généré puis renvoyé au servlet par baepp.licenseKey.LicKeyTools). Les beans sont donc presque tous des composants du Model et il y a peu de beans View.

4.1.1.8.2. Servlets : plusieurs types Les servlets exécutent le traitement de requêtes HTTP issues du client (formulaires HTML). Ils effectuent des requêtes Tamino, appellent les traitements de beans et assurent une partie présentation (code HTML "en dur"). La plupart des servlets effectue donc les rôles de Controller (les requêtes Tamino étant cependant souvent nécessaires à ce rôle) et View (retour de code HTML). Certains servlets ont un rôle plus limité à Controller (au sens strict : récupération de paramètres de requête HTTP, navigation d'un servlet à l'autre avec ou sans passage d'information autre que les attributs de session). D'autres contiennent une part de traitements assez importante (Model) et gèrent un retour HTML (View). De rares autres sont complètement des éléments Model ou complètement View.

4.1.1.8.3. Conclusion L'architecture n'est donc pas vraiment 3-tiers : on a les rôles suivants pour les servlets : - Controller et View ; - Model et View ; - Controller (rare) ; - Model (rare) ; - View (rare)

… tandis que les beans sont essentiellement des éléments Model.


41

4.1.2. Problèmes posés La maintenance et l'extension de l'application sont difficiles.

4.1.2.1. Editeur/compilateur Bolero

4.1.2.1.1. Fonctionnalités utiles manquantes § Pas d'intégration des web services, or ceux -ci deviennent prépondérants dans les évolutions du

portail ; § Pas d'outils de débogage/optimisation ; § Pas de lien avec un outil de versionnage, obligeant à une manipulation lourde : importation avant

modification et compilation, puis exportation du source ; § Coloration syntaxique pauvre, éditeur de texte sans recherche intelligente.

4.1.2.1.2. Non évolutivité § Plus d'évolution après la version 3.2, la maintenance ne sera plus assurée après 2005 ; § On ne peut pas changer de JDK pour une version donnée de Bolero, or le passage à une version

plus récente de Bolero (version 3) ne garantit pas la portabilité du code de l'application.

4.1.2.1.3. Consommation de ressources § Interface "lourde" en Java Swing ; § Fragilité en cas de plantage, récupération d'un état de marche long après plantage sévère :

importation de bolero archive, fichier .bar, mais aussi des .jar nécessaires. Cette procédure utilise une base de donnés Adabas D interne à Bolero pour stocker les données de travail (repository). Les transactions d'importation ou de mise à jour demandent donc du temps et des ressources ;

§ Apprentissage supplémentaire (langage propriétaire proche de java) ;

4.1.2.2. Faible structuration des rôles MVC La confusion des rôles MVC amène à une lecture du code laborieuse en renvoyant d'un élément à un autre suivant le type d'interaction servl et-beans, donc cela ne facilite pas de nouveaux développements. Chaque évolution de l'application demande donc beaucoup de ressources, ne fût-ce par exemple que pour changer une virgule de code HTML. De plus l'IDE utilisé ne permet que le modèle des servl ets java.

4.2. Evaluation de solutions

4.2.1. Struts 1.1 b1

4.2.1.1. Avantages Le code HTML des servlets peut être réutilisé tel quel pour la plus grande partie avec assez peu de réécriture (ôter le formatage dû aux println). Ceci implique une rapidité de développement. Le modèle servlet-JSP est proche de celui des servlets seuls, on peut donc garder globalement un enchaînement des noms de fichiers proches de ceux que l'on a déjà (les JSP prenant le nom des servlets existants).


42

4.2.1.2. Inconvénients De nombreux beans sont à écrire (beans View, beans de formulaire). Les messages d'erreur de remplissage de formulaires peuvent être récupérés dans un fichier properties ou XML, mais celui-ci doit être physique (donc non stocké dans Tamino). On peut avoir un problème d'attributs de session encombrant la mémoire.

4.2.1.3. Faisabilité Une rapide description permet d'évaluer la charge de réécriture du code : § des JSPs reprenant l'essentiel du code HTML des servlets existants (une par page HTML finale) ; § des beans View (ActionForm) à créer (un par JSP plus quelques-uns réutilisables, par exemple

pour le titre de la page) ; § le code business logique des servlets ou des beans existants peut être déplacé sans grand

changement vers les ActionServlets et de nouveaux beans Model (en plus de conserver ou optimiser des beans Model existant) ;

§ le fichier de configuration struts-logic.xml définissant principalement toutes les actions et les ActionForms.

J'ai testé les éléments de Struts en réalisant le développement de l'authentification LDAP et du menu principal du projet BAE, afin de voir si la solution retenue était réaliste. Cela m'a permis de mieux mettre en évidence les limitations du framework en deux semaines de développement et d'échanges avec les autres utilisateurs.

4.2.2. Cocoon 2.1-dev

4.2.2.1. Avantages Le composant de gestion de session permet de gérer facilement, de manière transparente, la session (début, fin, persistance d'informations modifiables facilement par l'usage du format XML), les ressources nécessitant une authentification. Les flux XML issus de Tamino peuvent être traités directement. Le traitement DOM est remplacé par des instructions XSL plus faciles à développer au niveau logique.

4.2.2.2. Inconvénients Les traitements DOM sont à redévelopper en traitement par des feuilles de style XSL. Il faut une feuille de style par page HTML finale. Le fichier XML permettant la validation de formulaire doit la plupart du temps être généré dynamiquement.

4.2.2.3. Faisabilité Une rapide description permet d'évaluer la charge de réécriture du code : § le sitemap gère la logique de l'ensemble, c'est la partie qui demande le plus de réflexion

(optimisation des enchaînements, réutilisation, lisibilité) ; § pour chaque page HTML finale, un morceau de pipeline (<match />)contenant, suivant les

besoins : - un generator, généralement un ensemble de requêtes Tamino agrégées, ainsi que les informations de session ;


43

- au moins l'Action de vérification de l'authentification de l'utilisateur. Dans ce cas si on veut conserver les paramètres de requête HTTP lorsque l'utilisateur n'est pas authentifié, on utilise aussi une Actions permettant de conserver ces paramètres (map act type="request") ;

- d'autres Actions avec une double logique possible au niveau du sitemap : booléenne (réussite / échec), redirection suivant les paramètres définis par l'action. Il n'y a pas de limite à l'imbrication d'Actions ;

- des feuilles de style XSL assurant la présentation, et pouvant assurer une part de controller : par exemple si un droit n'est pas présent dans le document XML de départ, alors un élément ne sera pas affiché. Lors de l'élaboration de ces feuilles de style, on recherche une réutilisabilité maximale par utilisation de paramètres d'entrées ;

- un minimum de beans java, qui peuvent être soit utilisés par les Actions (si la fonction est réutilisable par plusieurs actions), soit en tant qu'extension java dans une feuille de style XSL, ce que permet l'usage de Xalan comme processeur XSLT. Dans ce cas, la feuille de style initialise un bean, le bean réalise un traitement, la feuille de style récupère une valeur d'une variable ;

- des transformers, permettant d'appliquer une feuille de style XSL, ou de récupérer/écrire dans les informations de session ;

- un serializer, généralement HTML, mais aussi XML ou FO2PDF (document PDF en sortie).

4.2.3. Conclusions Struts apporte essentiellement une nouvelle structuration au deux extrémités de l'échange client-serveur : au niveau du contrôle de formulaire côté serveur, et du retour d'information par des beans View inclus dans des JSPs. En revanche, les parties accès LDAP et traitement de données issues de Tamino restent inchangés. Cocoon implique une réécriture plus poussée du code et traite le flux XML nativement donc on gagne en efficacité par rapport à l'usage de DOM pour parser l'XML. La réécriture se fait essentiellement en XSL, le code java étant "masqué" par l'usage de composants prédéfinis. Quelques Actions personnalisées, (code java) ainsi que des extensions java utilisables dans les feuilles de style, sont nécessaires. L'accès à LDAP est simplifié. Lors de cette évaluation, j'ai tout d'abord trouvé la solution Cocoon compliquée à mettre en œuvre parce que modifiant fortement l'existant, mais une réunion avec M. Milgram nous a décidés à relever le défi. Cependant je me suis heurtée rapidement à la nécessité de l'adaptation du driver Tamino XML:DB qui n'était pas fonctionnel, tâche assumée par un collègue.

4.3. Eléments stratégiques

4.3.1. Solution retenue Cocoon 2.1-dev (version CVS du 2 octobre 2002) est retenu, comme les éléments précédents plaident en sa faveur plutôt que Struts : même si la réécriture est plus poussée, de nombreux points peuvent être optimisés, que ce soit en terme de facilité d'écriture de code par l'abandon de DOM, d'accès à Tamino et LDAP, de maintenance. Comme cette version n'est pas encore officielle, il convient que les développeurs restent en liaison étroite avec la mailing-list d'Apache Cocoon, et lors de la mise à jour via CVS, un backup doit être réalisé, ainsi que le test de toutes les fonctionnalités.

4.3.2. Modification de fichiers XML

4.3.2.1. Menu principal réorganisé De l'aveu même des développeurs initiaux, le menu principal donnant accès aux différentes fonctions de l'application a été réalisé en plusieurs fois, suivant l'ajout de fonctionnalités. Il convient donc de le réorganiser en regroupant certains items par thème. D'autre part quelques éléments sont supprimés.


44

Ceci implique une nouvelle version du fichier mlMenu.xml (stocké dans Tamino en tant que document existant <mlMenu />). Voir annexe 9.4.4.1. avec copie d'écran.

4.3.2.2. Document "access" et droits LDAP Les éléments permettant de définir et gérer les droits d'accès sont dépendants du menu principal, lorsqu'il y a vérification d'un droit sur un élément de ce menu. Afin de simplifier l'application, on met à jour et harmonise les noms des éléments stockés dans LDAP et représentant les droits utilisateurs, et des éléments du document <access /> (access.xml). Plus de détails en annexe 9.4.4.2.

4.3.3. Gestion des accès à Tamino Les accès à Tamino utilisent soit des requêtes directes (HTTP), soit l'API de haut niveau Tamino API For Java, et nous pouvons utiliser cette dernière de deux manières : § dans un bean java ordinaire, ou une Action, en utilisant les classes de Tamino API For Java. Cette

API étant déjà de haut niveau, l'idée retenue a été de réaliser une classe gérant la connexion / déconnexion et les requêtes, et des classes appelant cette classe et gérant le traitement du résultat des requêtes ainsi que les exceptions.

§ par l'API XML:DB intégrée dans Cocoon (annexe 9.6.1.) On utilise alors une API intermédiaire,

Tamino XML:DB. Cette API est disponible sur le site de la communauté des développeurs (Tamino Developper Community).

Les accès à Tamino se font alors au niveau de feuilles de style XSL pour l'insertion ou la suppression de document (xmldb transformer à appliquer après la feuille de style). La mise à jour n'est pas implémentée dans l'API Tamino XML:DB, alors qu'elle l'est au niveau de l'API XML:DB (XUpdate). Cela est dû au mode de fonctionnement de la version 3 de Tamino utilisée, et le développement nécessaire du driver Tamino XML:DB pour Tamino n'a pas été réalisé parce que les Actions suffisent pour cette tâche, et que la version 4 de Tamino prévue pour décembre 2002 permettra une mise à jour partielle de document, comme l'API XML:DB. Voir annexe 9.6.1. pour plus de détail.

4.3.4. Gestion de l'accès à LDAP L'accès à LDAP est géré par l'usage de feuilles de style XSL ainsi que du LDAP transformer. Les droits sont récupérés lors de la connexion initiale et stockés en tant qu'attribut de session (session context).

4.3.5. Autres choix stratégiques Le multilangage a continué à être géré par le même document XML <mlForm />. Ce dernier est stocké sur le disque dur du serveur et non plus dans Tamino, comme il est statique et les accès y sont fréquents. En revanche, pour l'envoi d'emails, la solution réalisable en respectant le modèle MVC proposé par Cocoon reprend l'existant, les documents XML, PDF et en plus le corps du message HTML de l'email sont écrits sur le disque. Ceci conduit à une simplicité de compréhension/développement et une rapidité d'exécution.


45

4.4. Développement réalisant une fonction dans son ensemble : génération de licences par défaut Cette partie s'attache à documenter le développement que j'ai réalisé, et traite : - de la configuration spécifique que j'ai utilisée ; - des éléments de Cocoon que j'ai utilisés et des fichiers que j'ai développés ; - de la procédure de mise à jour de Cocoon et maintenance du projet.

4.4.1. Généralités Ce développement implémente les fonctions essentielles de l'application et réalise une étude de faisabilité ainsi qu'un modèle d'utilisation de ce framework. La dernière version de Cocoon 2.1-dev CVS intégrée au projet est du 2 octobre 2002. L'ensemble des fonctions (au moins au stade de test) que devra supporter l'application finale est présent : - interaction avec l'utilisateur via formulaires ; - interaction avec la base de données ; - gestion de la session et des informations y afférent ; - formats finaux variés (XML et PDF en complément de HTML) ; - envoi d'email avec fichiers joints.

Le poids fonctionnel du code réalisé est pour 25% dans le sitemap, 65% dans les XSL et 10% dans les Actions ou extensions java. La structure des fichiers de la web application est présentée en annexe 9.4.5.

4.4.2. Modifications apportées à la configuration par défaut de Cocoon

4.4.2.1. Au niveau des archives jar Des jars ont été ajoutés dans le répertoire WEB-INF\lib de la web application : - pour l'usage de Tamino, issus de Tamino API For Java : jdom.jar, log4j-core.jar,

TaminoAPI4J.jar ; - pour l'usage de Tamino via l'API XML:DB : tamino_xmldb.jar ; - pour l'usage de l'API JavaMail et de JAF : mail.jar, mailapi.jar, smtp.jar, (pop3.jar,

imap.jar non ajoutés), activation.jar.

4.4.2.2. Au niveau des fichiers de configuration

4.4.2.2.1. cocoon.xconf § Ajout du driver Tamino XML:DB dans WEB-INF\cocoon.xconf à l'emplacement adéquat : <driver class="com.softwareag.tamino.xmldb.api.base.TDatabase" type="tamino"/>. § Pour l'usage de input modules (voir 2e point du paragraphe 4.4.3.1.4.2) on ajoute un

composant, redéclaré avec un attribut name spécifique : <component-instance class="org.apache.cocoon.components.modules.input.DefaultsMetaModule" logger="core.modules.input" name="baepp">

<input-module name="request-param"/> <values>

46

<taminoserver>i3in0</taminoserver> <taminodatabase>BAEPP</taminodatabase> <taminocollection>BAEPP</taminocollection> <cocoonport>9090</cocoonport> <hostbase>baepp</hostbase>

<adminemailfrom>[email protected]</adminemailfrom>

<adminemailto>[email protected]</adminemailto> <smtp>10.41.20.3</smtp> </values> </component-instance>

4.4.2.2.2. logkit.xconf § Modification de la configuration des loggers dans WEB-INF\logkit.xconf afin de ne loguer, en

phase de production, que les niveaux "error", dans le tag <categories>. § Modification de l'emplacement des fichiers de log, dans ${context-root}/logs/ au lieu de

${context-root}/WEB-INF/logs/.

4.4.2.2.3. sitemap.xmap § Précision du format de sortie des serializers XML et HTML par le tag <encoding>iso-8859-1</encoding>. En effet l'encodage par défaut est UTF -8, ce qui provoque des problèmes d'affichage dans le navigateur (testé avec Internet Explorer 5.5). § Ajout de la déclaration d'Actions réalisées, ainsi que du transformer xmldb : <map:transformer name="xmldb" src="org.apache.cocoon.transformation.XMLDBTransformer">

<driver>com.softwareag.tamino.xmldb.api.base.TDatabase</driver>  <base>xmldb:tamino://i3in0/tamino/BAEPP/BAEPP</base>

</map:transformer> § Remplacement de la section <pipelines /> par une propre à l'application. § Mise en commentaire du générateur suivant : <map:generator name="parentcm"

src="org.apache.cocoon.samples.parentcm.Generator"/>

4.4.3. Documentation des fichiers réalisés

4.4.3.1. Sitemap Le sitemap principal est présenté (source commenté) en annexe 9.3.1. Par abus de langage, lorsqu'il n'y a pas de confusion possible on dit "un pipeline" au lieu de "une section de pipeline (définie par un tag <map:match />)". Un sitemap secondaire est utilisé afin de rassembler toutes les requêtes sur Tamino. Il est dans le répertoire ino. Le sitemap principal devient ainsi plus lisible, en utilisant des noms logiques à la place de requêtes complètes.

4.4.3.1.1. Structuration des morceaux de pipeline Pour chaque page HTML, XML ou PDF finale, il y a une section <map:match /> qui correspond à une URI. Il y a quelques exceptions : certains pipelines spécifiques sont commentés ci-après :


47

§ <map:match pattern="getxml" /> : pipeline interne utilisé pour obtenir les informations de session. Cependant ce pipeline n'est pas utilisé tel quel, en effet une agrégation de ce pipeline (par cocoon://getxml) et d'autres documents provoque une boucle infinie (bug). Ce pipeline sert donc essentiellement au débogage. Chaque pipeline utilisant une agrégation et les informations de session nécessite l'usage du document getxml.xml et un session transformer.

§ <map:match pattern="httprequest" /> : pipeline interne générant un document XML à partir d'une requête http, comme les paramètres ne sont pas connus en nombre mais ont un format spécifique.

§ <map:match pattern="getcheckedplugs" /> : Rôle semblable au pipeline précédent, avec filtrage des paramètres HTTP.

§ <map:match pattern="getdescriptor/*" /> : pipeline interne comme il n'a pas lieu d'être accessible directement, retourne un descripteur XML correspondant à un template de produit donné, pour usage avec la validation de formulaire.

§ <map:match pattern="mlform" /> : fichier gérant le multilangage et servi à partir du disque pour des raisons de performances.

§ Le dernier pipeline du sitemap : <map:match pattern="*" /> redirige l'utilisateur qui demande une URI inexistante, soit vers le menu principal s'il est logué, soit vers la page d'accueil l'invitant à s'authentifier.

4.4.3.1.2. Rôles des actions utilisées

4.4.3.1.2.1. Actions de Cocoon § request permettant de conserver les paramètres HTTP lorsqu'une action d'authentification

(première action incluse) échoue, afin d'avoir un message d'erreur multilingue (il n'y a alors pas de session).

§ actions permettant l'authentification et protégeant les pipelines externes : auth-login, auth-protect, ainsi que de contrôle de l'état logué : auth-loggedIn, et de déconnexion : auth-logout.

§ form-validator : valide le contenu d'un formulaire par rapport à un descripteur XML. L'utilisation conjointe du transformer SimpleFormTransformer est nécessaire pour renvoyer un formulaire incorrect conservant les valeurs déjà entrées par l'utilisateur.

§ request-exists : permet de vérifier qu'un certain paramètre est présent dans la requête HTTP.

4.4.3.1.2.2. Actions réalisées § genlickey : récupère le numéro de série de la licence dans Tamino (compteur) puis le met à

jour en l'incrémentant du nombre de licences produites. Détermine d'autres paramètres de sitemap (date de licence…).

§ xmldocexists : vérifie l'existence d'un document XML dans Tamino, renvoie null si ce document n'existe pas. Cette action sert à la gestion d'erreurs.

§ sendmail : envoie un email au format HTML avec pièces jointes et images incluses dans le corps du message.

4.4.3.1.3. Rôles des transformers utilisés Les types de transformers suivants, sauf le dernier, s'appliquent à un document XML dont une partie est liée à un namespace précis, cette partie est alors consommée par le transformer. § xmldb : permet l'insertion, la suppression, la mise à jour de documents dans une base de

données XML via l'API XML:DB. § session : permet d'accéder aux informations de session en lecture/écriture. § write-source : permet d'écrire un fichier sur le disque, le paramètre serializer permet de

préciser le format. § simple-form : conserve les paramètres HTTP sauf celui de type "errror", lors de l'échec d'un

contrôle de formulaire par exemple.


48

4.4.3.1.4. Paramètres à adapter à l'environnement

4.4.3.1.4.1. Eléments définitifs § Dans la déclaration du xmldb transformer, une bonne valeur pour le tag <base /> doit être

codée. Voir le paragraphe 4.4.2.2.3.

4.4.3.1.4.2. Eléments provisoires Les deux points suivants correspondent à des possibilités de configuration de Cocoon par l'usage de paramètres globaux. Cependant les composants utilisés sont soit non finalisés (global parameters) soit sujets à changement (input modules) jusqu'à la version finale. § Les paramètres globaux : <map:global-parameters>, utilisables dans tout le sitemap et

normalement accessibles par un chemin simple : {/parametre}, ne sont pas encore complètement fonctionnels dans la version CVS de début octobre 2002 donc pour l'instant on se passe de cette fonctionnalité. En effet on doit pour le moment utiliser des chemins de style {../../parametre} utilisant la pile de paramètres, ce qui est assez peu lisible et source d'erreur.

Les paramètres globaux suivants doivent donc être adaptés à l'environnement utilisé et sont déjà définis afin de faciliter la migration lorsque la fonction sera opérationnelle. D'autres paramètres sont à ajouter en fonction du contenu du fichier bae.properties du projet initial (serveur LDAP…). <map:global-parameters>

<map:parameter name="taminoserver" value="i3in0"/> <map:parameter name="taminodatabase" value="BAEPP"/> <map:parameter name="taminocollection" value="BAEPP"/> <map:parameter name="cocoonport" value="9090"/> <map:parameter name="hostbase" value="baepp"/> <map:parameter name="adminemailfrom"

value="[email protected]"/> <map:parameter name="adminemailto" value="[email protected]"/> <map:parameter name="smtp" value="10.41.20.3"/>

</map:global-parameters> Les éléments concernés sont les suivants : - URL utilisée lors de l'accès à Tamino :

<map:generate src="http://{/taminoserver}/tamino/{/taminodatabase}/{/taminocollection}/?_ …" > ;

- paramètres passés à la feuille de style dbresp.xsl dans le pipeline defaultgenerationform2fill, et errorpage.xsl dans le pipeline error ;

- paramètres passés à l'action sendmail dans le pipeline sendlicense. § Une autre solution provisoire consiste à utiliser un input module, dans cocoon.xconf. Les

paramètres sont ensuite préfixés par le nom de cet input module (en l'occurrence baepp). Les éléments concernés sont les suivants : - URL utilisée lors de l'accès à Tamino :

<map:generate src="http://{baepp:taminoserver}/tamino/{baepp:taminodatabase}/{baepp:taminocol-lection}/?_ …" > ;

- paramètres passés à la feuille de style dbresp.xsl dans le pipeline defaultgenerationform2fill, et errorpage.xsl dans le pipeline error ;

- paramètres passés à l'action sendmail dans le pipeline sendlicense.


49

On retient cette solution afin de donner un peu plus de souplesse à l'application, en conservant une bonne lisibilité.

4.4.3.2. Feuilles de style XSL Elles gèrent l'affichage d'un document HTML, XML ou PDF, peuvent contenir des extensions java, effectuent une vérification des droits de l'utilisateur (informations de session récupérées au format XML et agrégées au document principal).

4.4.3.2.1. Parties réutilisables resources.xsl contient des templates appelés par plusieurs feuilles de style, auxquels sont passés ou non des paramètres, et déterminant :

- le contenu de la partie <head> de la page HTML, - le haut et le pied de page, - le contenu de la page d'erreur.

4.4.3.2.2. Autres feuilles de style Le code des feuilles de style est commenté, cependant certaines fonctions méritent d'être expliquées plus en détail. Les feuilles de style sont récapitulées ci-après dans l'ordre d'apparition dans le sitemap. § checkedplugs.xsl : produit un document XML à partir des paramètres de requête http, sert de

filtre pour le traitement suivant. § formvaldesc_genlickey.xsl : produit un descripteur XML utilisé par la validation de

formulaire, à partir d'une requête Tamino d'un certain template de licence. § copy.xsl : recopie le contenu du document auquel elle est appliquée, sans modifications. § login.xsl : formate la page d'accueil (non multilingue). § error.xsl : formate la page d'erreur à partir d'une requête Tamino et d'un paramètre de

langage. Pas de session présente. § user.xsl : formate les informations relatives à l'utilisateur avant l'application du transformer de

session. Ces informations sont stockées en session et ont obligatoirement la structure suivante. Les tags notés (1) sont nécessaires de par la structure du portail d'authentification, les autres de part le choix d'implémentation de l'application. Lors du développement réalisé les informations ont été codées "en dur" et mono-utilisateur. (voir le fichier de développement user.xml). <authentication> (1) <ID> … </ID> (1) par commodité, on prendra l'UID de l'utilisateur LDAP,

comme cet identifiant est unique <role> … </role> (1) utilisé dans le cadre du portail mais pas de

l'authentification seule (cas présent) <data> (1) informations complémentaires

<company> … </company> <or_lang> … </or_lang> langue d'origine de l'utilisateur (LDAP), peut être

différente de celle dans laquelle il a choisi de visualiser le portail

<lang> … </lang> langue de visualisation du portail <fullname> … </fullname> nom complet, correspond au DN de LDAP <email> … </email> issu de LDAP <menu_rights> liste des droits de l'utilisateur, issus de LDAP

<right> … </right> …

</menu_rights> </data> (1) </authentication> (1)


50

§ menu_rights_….xsl : le menu le plus étendu possible est filtré par trois feuilles de style, comparant les éléments présents dans le document XML du menu et les éléments autorisés pour l'utilisateur (présents en session). Ce moyen est le plus efficace et le plus rapide de gérer simplement un menu à trois niveaux, les droits s'appliquant, avec priorité, sur chaque niveau.

§ menu_main.xsl : formate la page du menu principal, une fois les filtres de droits appliqués. § familiesandplatforms.xsl : formate la liste des familles de produits et plates-formes

disponibles. § lkgproductcatalog.xsl : formate une liste de produits versionnés disponibles après choix. § genliccheckplug.xsl : Les plugs associés à chaque produit sont issus d'une deuxième

requête Tamino, cette feuille de style permet de transmettre les paramètres HTTP déjà définis au niveau du choix de licence par l'utilisateur (listes déroulantes page précédente), ainsi que d'ajouter des paramètres au format standardisé (PLUGxxx:yyy:zzz) selon les plugs cochés par l'utilisateur, xxx, yyy et zzz étant des informations relatives au plug choisi.

§ genlickey.xsl : génère un document XML correspondant aux informations de licence, sauf la clé de licence déterminée plus tard. Plusieurs éléments sont dépendants les uns de autres, ou dépendent des plugs choisis. Le manuel administrateur réalisé lors de la conception initiale du projet BAE détaille ces dépendances.

§ MD5.xsl : la clé de licence étant déterminée par le traitement d'une chaîne de caractères issus des informations de licence (tags XML compris) passés à une dll, cette feuille de style parse le document XML et appelle une extension java qui appelle la dll. La clé de licence est retournée et placée au bon endroit dans le document.

§ insertandkeep.xsl : usage de l'API XML:DB et recopie du document initial afin de réaliser d'autres transformations.

§ addsessioninfo.xsl : ajoute les informations de session à un document existant, avec application du session transformer, dans le cas où une agrégation de ce document et des informations de session n'est pas possible.

§ dbresp.xsl : cette feuille de style est particulière : comme on a choisi d'insérer le document XML dans Tamino à l'aide de l'API XML:DB, le traitement complet de la réponse (succès ou échec) doit se faire à l'aide d'XSL. Il y a usage d'extension java.

§ genlicform2fill.xsl : formate le formulaire à remplir pour générer une licence. Contient une partie de code nécessaire à l'usage d'une validation de formulaire, utilise des extensions java.

§ filledlicense.xsl : formate les informations d'une licence pour récapitulatif après génération de celle-ci.

§ htmlcard.xsl : formate la carte de licence au format html, avec inclusion d'un contrôle ActiveX. § dllicense.xsl : formate la page de téléchargement de la licence. Utilise une extension java. § sendlickeyform.xsl : formate le formulaire d'envoi de licence par email. Utilise une extension

java. § writelicensehtmlbody.xsl : contient le code du corps de message email ainsi que les tags

spécifiques interprétés par le write-source transformer. § cleanxml.xsl : formate le résultat d'une requête Tamino afin d'afficher les informations de

licence sans les tags induits par l'usage de l'API XML:DB. § pdfcard.xsl : formate le document PDF de licence. § writeandkeep.xsl : contient le document initial XML encadré par les tags spécifiques

interprétés par le write-source transformer, ainsi qu'une recopie du document initial. § writeandpdfcard.xsl : contient le code de formatage XSL FO (production d'un document

PDF) ainsi que les tags spécifiques interprétés par le write-source transformer. § errorpage.xsl : formate une page d'erreur à partir des informations de session et d'une

requête Tamino.

4.4.3.2.3. Extensions java J'ai préféré utiliser une classe Java dont les méthodes sont appelées au cours du traitement XSLT que coder mon propre transformer, pour gagner du temps de développement et peut -être une certaine performance, lorsqu'il y a lieu de réaliser une fonction "simple" et non répétitive, du moins assez peu réutilisable parce que spécifique à cette application.


51

On peut distinguer plusieurs rôles : § Information complémentaire apportée à une feuille de style XSL et obtenue plus rapidement par

un traitement java : baepp.MyDate. § Mémoire tampon alimentée progressivement par une XSL et traitement de ces données : baepp.genlickey.MD5, baepp.Plug. § Accès à Tamino non réalisable plus tôt avec un generator : baepp.genlickey.FileName, baepp.Error. § Appel direct comme on ne peut passer par une Action Cocoon. Ce bean est aussi utilisé par une

Action : baepp.MailerBean.

4.4.3.3. Remarques complémentaires

4.4.3.3.1. URIs et sous-sitemaps Comme une image est incluse dans le haut de page (sortie HTML), ceci suppose que son chemin soit toujours du même ordre de profondeur. Si le projet doit être découpé en sous-sitemaps pour une meilleure gestion du développement ultérieur et de la maintenance, les URIs appelant ces sous-sitemaps doivent être de même ordre au niveau des slashes. Cette même restriction a conduit à utiliser des matchings sur une URI "simple", les informations complémentaires étant passées en paramètres, de préférence par la méthode POST. Cependant dans le cas de simples requêtes HTTP sur Tamino rassemblées dans un sous-sitemap ce problème ne se pose pas.

4.4.3.3.2. Dualité de certains traitements Certains traitements sont préférentiellement, soit des accès à Tamino utilisant l'API XML:DB, soit des Actions Cocoon, afin de rendre le maximum de logique visible dans le sitemap. Dans certains cas cela n'a pas été possible de par l'enchaînement des traitements, c'est ce qui justifie l'usage d'extensions java. § Dans le cas de l'accès à Tamino, un même bean d'accès est utilisé par une extension java ou

une classe mettant à jour des données dans la base, il y a donc une légère abstraction supplémentaire, ainsi qu'une réutilisation de code.

§ Dans le cas de l'envoi d'email, un bean, MailerBean, est utilisé avec plusieurs méthodes

suivant le type d'email envoyé (format, pièces jointes). Il est soit utilisé directement en tant qu'extension java soit par l'action MailerAction.

4.4.3.3.3. Mise à jour de schémas / documents Tamino Un document XML important a été modifié : mlMenu. Le nouveau contenu est présenté en annexe 9.4.3. Par ailleurs, pour plus de performance, des index ont été ajoutés à certains schémas. Il convient donc de remettre à jour les schémas (puis éventuellement les données XML) dans Tamino.

4.4.3.3.4. Développements ultérieurs Une réutilisation maximale des feuilles de style est favorisée par l'usage de paramètres. De même les requêtes Tamino dans le sitemap doivent être les plus complètes possibles.


52

4.4.3.4. Points non satisfaisants, problèmes § Une nouvelle fonctionnalité mineure demandée lors de la migration, au niveau présentation, n'a

pas encore été réalisée : elle concerne le tri des versions de produits une fois les produits triés globalement par description. Voir des solutions possibles en annexe 9.4.6.

§ La nécessité de vérifier qu'un document existe dans Tamino implique de passer une requête en tant que paramètre à une Action. Si la structure des documents venait à être fortement modifiée il faudrait modifier ces valeurs de paramètres ainsi que les requêtes regroupées dans le sous-sitemap (donc deux endroits).

§ Un bug lors de l'association d'un pipeline interne générant les informations de session et de l'agrégation de ce pipeline avec d'autres (boucle infinie) oblige à répéter le session transformer dans chaque pipeline.

§ L'utilisation de requêtes Tamino dans un sous-sitemap pour générer un flux XML entraîne un bug au niveau du SourceWritingTransformer : l'emplacement de l'écriture des fichiers est par défaut le niveau du sous-sitemap et donc pas celui attendu a priori (niveau du sitemap principal).

4.4.4. Maintenance, procédure de mises à jour

4.4.4.1. Cocoon Lors des mises à jour de Cocoon à partir de CVS (annexe 9.5.5) il faut toujours conserver une sauvegarde des fichiers suivants : sitemap, contenu de WEB-INF (à la racine, fichiers de configuration de Cocoon et de la webapp) et WEB-INF\lib. Des modifications sur les nouveaux fichiers respectant le point 4.4.2.2. doivent ensuite être réalisées. De même, les jars spécifiques à Cocoon sont remplacés, on conserve les autres (voir 4.4.2.1.). Une recompilation des Actions développées pour le projet est recommandée.

On le répète, les développeurs doivent rester en relation avec la mailing-list d'utilisateurs (annexe 8.4.2).

4.4.4.2. Projet § En cas de modification de la structure globale des templates de produits, il se peut qu'il n'y ait plus

de champ obligatoire. Dans ce cas un contrôle supplémentaire est nécessaire pour ne pas effectuer de validation de formulaire qui échouerait. Toute autre modification de champs soumis à contrôle doit être répercuté dans la feuille de style formvaldesc_genlickey.xsl.

§ Par ailleurs, si on souhaite tester une version postérieure à Tamino XML:DB 3.2.1 du 24

septembre 2002 (voir liens en 8.6.), le plus simple est d'utiliser le pipeline tamino/** puis de générer une licence afin de vérifier que l'insertion dans Tamino est réalisable.

4.4.4.3. Vérification des fonctionnalités Il faut d'abord s'assurer, lors de la mise à jour, que les solutions de global parameters et/ou input modules sont fonctionnelles ou non, avec ou sans changement de configuration. Le reste de l'application doit être testé ensuite.

4.5. Outils et méthodes de développement Cette partie s'attache à évaluer l'adéquation des outils logiciels que j'ai utilisés, aux besoins généraux d'un projet de même ordre (web application). Je présente également rapidement les méthodes de débogage et de logging.


53

4.5.1. Editeur/debugger XSLT : Excelon Stylus Studio

4.5.1.1. Fonctionnalités recherchées - édition et correction de syntaxe facilitée, XML, XSLT, XSL FO (clôture automatique de tag, sensibilité

au contexte lors de l'édition : liste de choix) ; - débogage avec messages explicites ; - intégration de FOP ; - support de processeurs XSLT configurable (Xalan, MSXML…) ; - debugger Java avec back-mapping (extensions java) ; - validation de fichiers par DTD, Schémas ; - support de requêtes XPath ; - client SOAP (1) ; - éditeur WSDL (web service description language) (1) ; - génération de code Java/C++ à partir de XML Schemas (1) ; - migration HTML vers XML facilitée (1) ; - accès direct à Tamino (toutes requêtes) (1).

4.5.1.2. Fonctionnalités apportées par le produit Stylus Studio 4.0 remplit tous les critères énoncés ci-dessus sauf ceux marqués par (1), satisfaits seulement par XML Spy Suite 5.0.

4.5.1.3. Inconvénients Stylus Studio offre beaucoup moins de fonctionnalités que XML Spy Suite dans sa version Enterprise.

4.5.1.4. Raisons du choix / autre choix recommandé Le choix de Stylus Studio s'est fait sur le conseil d'un collègue, la version 4.3 de XML Spy Suite testée n'étant pas satisfaisante au niveau du débogage XSLT. Ce choix est donc à revoir au profit de XML Spy Suite 5.0, et ne s'est effectué que par manque de recherches préalables. Autres outils en annexe 8.7.2.

4.5.2. Editeur et compilateur java : JBuilder

4.5.2.1. Fonctionnalités recherchées

4.5.2.1.1. Edition - syntaxe en couleurs et éditeur personnalisable (formatage de code) ; - proposition de correction orthographique (3) ; - proposition de méthodes applicables à un objet lors de la frappe ; - affichage de javadoc relative à l'objet ou la méthode en cours d'édition (3) ; - proposition de templates de code, par exemple syntaxe de la boucle "for" (3) ; - refactoring (modification de structure globale, gestion d'erreurs, variables…) de code existant (1) ; - optimisation des importations ; - prévisualisation de refactoring (3) ; - rapidité de réactivité de l'interface de même ordre que celle du système d'exploitation (3).

4.5.2.1.2. Compilation - débuggeur efficace lors de la compilation : message explicite, numéro de ligne ; - possibilité de contrôle fin de l'exécution du code (points d'arrêt avec visibilité des variables

locales…), de tests de performance (JUnit) (1) ; - compilation automatique lors de la sauvegarde de code ;


54

- code exécutable partiellement même en cas d'erreur de compilation (3).

4.5.2.1.3. Intégration - intégration avec moteur de servlets et autres produits (CVS, outil modélisant des schémas

UML…) (1) ; - intégration avec Ant, d'Apache (outil open source permettant de personnaliser la compilation d'un

projet suivant l'environnement, basé sur un fichier XML) (2) ; - intégration d'un décompilateur spécifique.

4.5.2.1.4. Déploiement - structuration du projet en web application (1, 4), - création d'archive web .war personnalisable (exclusions de fichiers…) qui sera déployée simplement

par la suite (1),

4.5.2.1.5. Documentation - simplicité relative de configuration, - création automatique de javadoc (1), - facilité à trouver des solutions aux problèmes (documentation, forums spécifiques).

4.5.2.2. Fonctionnalités apportées par le produit pas d'annotation : satisfait par la version "Personal" 6 ou 7(gratuite) de JBuilder, (1) : satisfait au moins par la version 6 "Enterprise" de JBuilder, (2) : satisfait au moins par la version 7 "Enterprise" de JBuilder.

4.5.2.3. Comparaisons avec d'autres produits Le choix a été fait d'axer la comparaison sur un outil commercial, JBuilder, et un outil open source, Eclipse (voir annexe 9.7.2 pour la présentation, 9.5.4 pour la configuration). Ainsi d'autres critères ne sont satisfaits que par Eclipse : (3) : satisfait par Eclipse 2.0 seulement (version de base), (4) : nécessite un plug-in pour Eclipse. D'autres outils commerciaux offrent le même niveau de fonctionnalité que JBuilder 7 Enterprise, référencés en annexe 9.9 (comparaison de prix). La partie 8.7.1 de la bibliographie répertorie des liens utiles (sites des éditeurs, comparatifs).

4.5.2.4. Inconvénients § J'ai trouvé que l'utilisation d'un moteur de servlets (Tomcat 4.0) intégré à l'éditeur est globalement

plus lent que celle d'un moteur séparé et quelquefois sujet à plantage de l'éditeur entier, donc j'ai utilisé les éléments séparément. En effet le moteur intégré est relancé à chaque fois.

Cependant, dans le cas de Tomcat externe, la fonction "build " doit être utilisée avec précaution : si le moteur de servlets recharge automatiquement les classes ou jars modifiés et si les jars de WEB-INF\lib sont tous mis à jour, Tomcat 4.0 / 4.1 peut quelquefois planter. Il convient donc, dans cette association, de ne recopier que les classes modifiées, manuellement, dans WEB-INF\lib. Ce problème ne se pose pas avec d'autres éditeurs / compilateurs ou moteurs. § Le prix d'une licence est très élevé.


55

4.5.2.5. Raisons du choix / autre choix recommandé J'ai choisi cet outil pour plusieurs raisons dont certaines triviales : je le connais déjà, il est déjà utilisé dans une version ou une autre au sein de l'entreprise, il satisfait globalement les attentes pour ce projet. Cependant j'ai dû opter pour une version payante (6 Enterprise), la version gratuite n'offrant pas assez de fonctionnalités. J'ai essayé Sun One Studio versions 3 et 4 (pre-version), il est "trop" consommateur de ressources (lenteur d'exécution et de compilation). Eclipse 2.0 me satisfait cependant. Ce choix est donc acceptable quoique coûteux si on veut une version commerciale (voir une comparaison de prix en annexe 9.9), sinon il vaut mieux choisir Eclipse (voir en annexe 9.7.3. une description détaillée de ce produit).

4.5.2.6. Configuration Le projet a été configuré de telle sorte que le .war produit contienne les fichiers requis et en exclue d'autres. Voir annexe 9.5.4. De plus j'ai jugé utile d'intégrer le décompilateur java reconnu comme un des meilleurs, JAD, le décompilateur inclus dans JBuilder étant incomplet.

4.5.3. Moteur de servlets : Tomcat 4.1.

4.5.3.1. Fonctionnalités recherchées - simplicité de configuration, - rapidité d'initialisation, - consommation mémoire "raisonnable", - rechargement automatique de classes / jars modifiés, - déploiement automatique ou facilité de .war, - support de connecteur à un serveur web, SSL, - gestion de l'état (démarré ou non, nombre de sessions en cours) de web applications, - console d'administration (accès, rôles, configurations…), - administration à distance, - support de web services (1), - load balancing (1).

4.5.3.2. Fonctionnalités apportées par le produit Tomcat 4.0 / 4.1 satisfaits les points énoncés ci-dessus sauf ceux notés (1). Tomcat 4.1 est une amélioration au niveau performances de Tomcat 4.0 : gestion de la mémoire, rapidité, gestion du rechargement automatique de classes. J'ai utilisé les deux dans le cadre du projet.

4.5.3.3. Inconvénients § Le déploiement de webapps ou war via Tomcat Manager n'est pas assez intuitif, il faut écrire le

chemin, on ne peut sélectionner un répertoire ou un .war. On utilise alors la méthode de déploiement automatique.

§ Un mauvais fonctionnement du module de rechargement de classes (classloader) peut entraîner des erreurs telles que IllegalStateException de Cocoon, ou ClassCastException, voire OutOfMemoryError. De plus lors du rechargement automatique de classes modifiées, on perd non seulement la session HTTP en cours, mais Tomcat tente de recharger les dlls déjà chargées, donc elles ne fonctionnent plus.

§ En cas de problèmes, stopper Tomcat, effacer son dossier work, le relancer. Il y a alors recompilation de tous les éléments nécessaires à l'exécution de la webapp.


56

4.5.3.4. Raisons du choix J'ai choisi ce produit, pour la phase de développement parce qu'il est déjà utilisé ici, m'a paru robuste à l'usage, et sa gratuité m’a tentée. L'application ne fonctionne d'ailleurs pas sous JRun 3.1 et le driver Tamino XML:DB ne fonctionne pas sous JRun 4. J'ai commencé le développement avant que la version 4.1 ne soit officiellement sortie, donc j'ai pu suivre l'évolution du produit (plus performant dans la version 4.1).

4.5.3.5. Configuration Il convient de configurer Tomcat pour un bon fonctionnement, ainsi que pour l'application proprement dite. Les détails sont en annexe 9.5.3. NB : Pour lancer Tomcat, au lieu d'utiliser le raccourci sur startup.bat, on peut ouvrir une console et écrire : catalina run. Ceci permet d'avoir plus d'informations de débogage ainsi que la sortie System.out.println.

4.5.4. Débogage J'ai effectué un débogage (recherche et correction minutieuses des erreurs) en deux étapes : § Au niveau d'une feuille de style XSLT, vérification de la bonne marche d'une transformation à

l'aide d'un éditeur XSLT, en utilisant un document XML statique issu de Tamino ou de Cocoon, une sortie XML étant possible à n'importe quel moment après au moins un transformer, d'où l'intérêt de copy.xsl.

Comme on utilise le même processeur XSLT, Xalan, on n'a pas plus de renseignement sur l'erreur (message + stack trace java) que si on utilisait un pipeline test de Cocoon. Il est juste plus pratique de rester dans le cadre de l'éditeur XSLT (rapidité relative d'exécution, si besoin modification du document XML initial dans le même éditeur). § Modification des informations apportées à un pipeline Cocoon pour vérifier sa bonne exécution, et

utilisation d'un log transformer afin de lire les informations du flux XML dans un pipeline dont on ne veut plus modifier la structure.

Il est à noter que si la structure du pipeline comporte des erreurs, les messages de Cocoon peuvent quelquefois ne pas être explicites, il convient donc d'apporter le plus grand soin à ses évolutions, le suivi des versions peut parfois être essentiel. J'ai utilisé pour cela Microsoft Visual Source Safe, outil en usage ici.

4.5.5. Logging Un processus de logging (écriture dans un fichier de log) est intégré dans Cocoon, toute classe faisant partie des Components, des Actions, ou même une simple classe appelée par une Action peuvent donc bénéficier d'une procédure simplifiée de log. En revanche, il faut définir son propre logging pour les extensions java, comme elles ne sont rattachées à Cocoon d'aucune manière. D'après la structure du projet et le rôle des extensions java, un parti pris, a été, dans un premier temps, de ne pas utiliser de logging pour les extensions java, leur rôle étant mineur et leur fonctionnement solidement testé.


57

4.6. Chiffrage Le client dispose d'un budget de 150 000 euros devant couvrir l'ensemble des tâches énumérées au point 2.3.3.2. ainsi que la maintenance. Ceci représente environ 150 jours-hommes de travail pour SAGF.

4.7. Planning prévisionnel de développement J'ai réalisé l'estimation du temps nécessaire et le planning en collaboration avec M. Milgram qui disposait de plus d'informations que moi sur les compétences disponibles au sein de l'entreprise, ainsi que sur le déroulement d'un projet. Ainsi ces informations peuvent être présentées au client.

4.7.1. Temps nécessaire

4.7.1.1. Préalable Cette estimation se base sur le travail que j'ai effectué en mono-développeur, avec un niveau de compétences moyen (Java, XSL). Le développement réalisé a demandé 5 semaines, soit 25 jours, incluant les tests et la configuration. La rédaction de la documentation structurée a pris un peu plus d'une semaine supplémentaire. Une partie non négligeable de la logique et des feuilles de style est réutilisable. Le travail est divisible, une "fonction" (voir tableau du 4.7.1.3) représentant une section de pipeline et un ensemble de tâches élémentaires peut être attribué à un développeur. Comme la structure globale est déjà définie par l'existant, une tâche non divisible se compose d'analyse puis de reformulation (développement).

4.7.1.2. Indices d'estimation – phases temporelles § Il peut y avoir nécessité de formation préalable pour la compréhension des principaux concepts,

rôles des éléments, et fonctionnement de Cocoon, ainsi qu'une mise à niveau éventuelle pour la programmation XSL. En effet la plupart des développeurs connaissent déjà bien XSL. On peut donc estimer que deux à trois jours sont nécessaires pour une autoformation sur Cocoon, et moins de deux jours pour la partie XSL. On prévoit donc trois jours en autoformation sur Cocoon et deux sur XSL.

§ Pour estimer la réalisation du projet, j'ai au départ compté environ une journée et demie par feuille

de style XSL principale, ou "unité logique", sachant que ceci n'est qu'un indice rapidement calculable d'estimation, et assez fiable. Une feuille de style correspondant en général à une étape élémentaire. Même si des éléments sont réutilisables, d'autres demanderont plus de réflexion. Il y a donc une correction pondérale par la suite de tâches suivant la difficulté et la dépendance.

Pour chaque partie élémentaire la durée prend en compte les éléments suivants : - lecture et analyse du code Bolero / Java issu de Bolero, existant ; - détermination des éléments à développer (Action, XSL) et de la structure du pipeline, des

paramètres. On cherche une réutilisation si possible ; - codage des éléments, le code étant bien sûr commenté ; - tests des cas de figure, erreurs, et de la robustesse.

§ La phase de documentation demande 20% du temps de développement (structuration de notes

réparties dans les commentaires du code, remarques additionnelles). § On prévoit 20% du temps de développement pour une intégration finale des éléments ainsi que

des test globaux sur l'ensemble de l'application. § On prévoit un jour de gestion de projet par semaine de délai (délai = charge / nb de

développeurs). § On ajoute par précaution 5% de marge.


58

4.7.1.3. Charge avant livraison

4.7.1.3.1. Formation Cinq jours de formation par personne sont prévus, couvrant globalement les besoins en ce qui concerne XSL et Cocoon. Pour ce dernier, ce document complète le code réalisé. Des ressources internet sont également disponibles.

4.7.1.3.2. Eléments à réaliser Le tableau suivant récapitule pour chaque fonction de l'application les tâches élémentaires à réaliser avec une estimation de leur durée. Les dépendances entre tâches sont de deux ordres : strictes, au sens temporel, ou bien recommandées, un modèle étant réutilisable (avec une astérisque). La charge globale est estimée à 54 jours-hommes, dont 16.5 déjà réalisés.

Code tâche élémentaire

Fonction de l'application Elément de fonction

Temps (jour)

Cumul (jours)

Dépendance (doit être fait

après la tâche)

Remarques sur la réutilisation

1 Menu principal (déjà réalisé) menu principal 1,5 1,5

2 Authentification LDAP

authentification LDAP / session, modification de fichiers XML et vérification de la cohérence

1,5 3

3 Prise en compte et paramétrage du système d'authentification de Cocoon (déjà réalisé) 1 4

4.1 Default generation (déjà réalisé)

listes déroulantes produits et plate-formes 1,5 5,5 3

4.2 affichage liste de produits avec version 1,5 7

4.3 choix de plugins 1,5 8,5

4.4 formulaire à remplir 1,5 10

4.5 génération de licence 2 12

4.6 récapitulation des informations de licence

1,5 13,5

4.7 page de téléchargement ou envoi par email

1,5 15

4.8 carte de licence HTML 1 16

4.9 affichage XML 0,5 16,5

4.10 affichage PDF 0,5 17

4.11 formulaire d'envoi par email + envoi d'email 1,5 18,5

5.1 Free generation tâches 5.1 à 5.11 similaires à 4.1 à 4.11 0,3 18,8 4.1

Essentiellement modifications de requête Tamino (paramètre "free"), feuilles de style peu ou pas modifiées

6.1 Mass generation tâches 6.1 à 6.6 similaires à 4.1 à 4.11 0,5 19,3 4.1

Essentiellement modifications de requête Tamino (paramètre "free"), modifications variables des feuilles de style

6.7 page de téléchargement et création de fichier zip

0,5 19,8


59



Temps (jour)

Cumul (jours)


après la tâche)


7.1 Tracking de licence formulaire de recherche 0,7 20,5

7.2 liste de licences trouvées 1,5 22

7.3 affichage d'une licence 0,1 22,1 4.6 feuille de style inchangée

8.1 Interactive Query formulaire de recherche 0 22,1 7.1 feuille de style inchangée


9.1 Command-line Query formulaire de recherche 0,5 22,7


10.1 Annulation / réactivation de licence

formulaire de recherche 0 22,8 7.1 feuille de style inchangée

10.2 listes de licences trouvées 0 22,8 7.2 feuille de style inchangée

10.3 affichage des informations de licence 0 22,8 4.6 feuille de style inchangée

10.4 annulation de licence + affichage du résultat 0,2 23 4.6

11.1 License set management affichage de liste 1,5 24,5

11.2 formulaire de modification + action

1,5 26

11.3 formulaire d'ajout + action 0,5 26,5 11.2

12.1 Platform management affichage de liste 1 27,5 11.1*

12.2 formulaire d'ajout + action 0,5 28 11.2* feuille de style et action peu changées

13.1 Product Family Management affichage de liste 0,5 28,5 12.1*

feuille de style et action peu changées

13.2 formulaire d'ajout + action 0,5 29 12.2*

14.1 Product Management

liste déroulante de recherche 0,1 29,1 4.1 feuille de style inchangée

14.2 affichage de résultats de recherche 1,5 30,6

14.3 formulaire de modification + action 1,5 32,1

feuille de style et action peu changées

14.4 formulaire d'ajout + action 0,2 32,3 14.3 feuille de style et action peu changées

15.1 Plug Management affichage de liste 0,5 32,8 12.1*

15.2 formulaire de modification + action

0,5 33,3 12.2*

15.3 formulaire d'ajout + action 0,2 33,5 15.2 feuille de style et action peu changées

16.1 Plug Type Management affichage de liste 0,5 34 12.1*

16.2 formulaire de modification 0,5 34,5 12.2*

17.1 Plug Assignment formulaire de sélection 1 35,5

17.2 partie sélection 1,5 37 17.1

17.3 partie ajout d'ID et de description 1,5 38,5 17.2

18.1 Template affichage de liste 1 39,5 12.1*


60



Temps (jour)

Cumul (jours)


après la tâche)


Management

18.2 formulaire présentant les informations du template 3 42,5

18.3 modification des informations (popups)

2 44,5 18.2

18.4 ajout de Tag 1,5 46 18.2

18.5 ajout de Composant 1,5 47,5 18.2

18.6 édition directe de l'XML 1,5 49

19.1 Statistiques de licences page de choix 0,2 49,2

19.2 affichage du résultat 0,2 49,4 19.2

20.1 Modification du mot de passe page d'entrée utilisateur 0,1 49,5

20.2 action de mise à jour 1 50,5 20.1

21.1 Modification de l'email page d'entrée utilisateur 0,1 50,6

21.2 action de mise à jour 0,5 51,1 21.1, 20.2

22.1 Gestion de partenaires et utilisateurs

page de login et action de login LDAP 0,5 51,6 2

22.2 pages de choix + action de mise à jour 1,5 53,1 2, 22.1

23 Aide en ligne page principale (table des matières) + statique HTML

0,5 53,6

24 Bug report formulaire + action 0,5 54,1

4.7.1.4. Charge, délai, gestion de projet NB : j-h : jour-homme. Formation Cocoon et XSL 5 jours au plus par personne Développement global à réaliser 37.5 j-h Intégration et tests finaux (20% du dév.) 7.5 j-h Supplément documentaire global (20% du dév.) 7.5 j-h Marge de 5% du développement 2 j-h

4.7.1.4.1. Deux développeurs Charge totale : 2*5 + 37.5 + 7.5*2 + 2 = 64.5 j-h. Délai : 32.3 jours. Gestion de projet : 1 jour pour 5 jours de délai soit : 6.5 jours. Soit : Formation Cocoon et XSL 5 jours au plus par personne Développement global 19 jours Intégration et tests finaux (20% du dév.) 4 jours Supplément documentaire global (20% du dév.) 4 jours Marge de 5% du développement 2 jours Total développement et intégration 29 jours Gestion de projet 6.5 jours


61

4.7.1.4.2. Trois développeurs Charge totale : 3*5 + 37.5 + 7.5*2 + 2 = 69.5 j-h. Délai : 23.2 jours. Gestion de projet : 1 jour pour 5 jours de délai soit : 4.5 jours. Soit : Formation Cocoon et XSL 5 jours au plus par personne Développement global 12.5 jours Intégration et tests finaux (20% du dév.) 2.5 jours Supplément documentaire global (20% du dév.) 2.5 jours Marge de 5% du développement 1 jour Total développement et intégration 18.5 jours Gestion de projet 4.5 jours Il est important de noter qu'une durée globale aussi réduite de projet peut poser des problèmes au niveau de la gestion de projet (niveaux de compétences différents, communication) et que les retards sont facilement accumulables. Donc le calendrier global prend trois semaines pour le développement proprement dit, soit 15 jours.

4.7.1.5. Après livraison Comme tout projet, il y a deux phases après livraison : § Vérification d'aptitude (VA), entre la livraison et la mise en production, d'une durée estimée à 15

jours par M. Milgram. Pendant cette période des tests sont effectués sur le site de production. § Vérification de service régulier (VSR) correspondant à une garantie. La durée proposée par M.

Milgram pour un projet de cette importance est de trois mois. Les durées habituelles varient de un à trois mois.

VA 15 jours VSR 3 mois Pendant cette période une personne doit être disponible dans un délai raisonnable.

4.7.2. Exemple de répartition des tâches – 3 développeurs Il semble raisonnable de mettre deux ou trois développeurs sur ce projet : durée globale courte, optimisation du relationnel et communicationnel avec cet effectif, bonne capacité de partage des tâches. La répartition des éléments à réaliser serait alors équilibrée, avec cependant des fonctions entières (groupes de tâches) attribuées à l'un ou l'autre développeur.

développeur 1 100 hr

2. auth. Ldap 12 hr

5. - free generation - total 8 hr

10 Annulation/réactivation 1,6 hr

12.1 Platform mgt 8 hr

12.2 Platform mgt 4 hr

13.1 P-F mgt 4 hr

13.2 P-F mgt 4 hr

14.1 Product mgt 0,8 hr

14.2 Product mgt 12 hr

14.3 Product mgt 12 hr

14.4 Product mgt 1,6 hr

17.1 Plug ass. 8 hr


62

17.2 Plug ass. 12 hr

17.3 plug ass. 12 hr

développeur 2 100 hr

18.1 Template mgt 8 hr






22 Gestion LDAP 16 hr

développeur 3 102,8 hr

6. Mass gen. - total 8 hr

7.1. Tracking, form 6 hr

7.2. Tracking 12 hr

7.3 Tracking 0,8 hr

8. Interactive query 0,8 hr

9. Command-line query 4,8 hr

11.1. License set mgt 12 hr

11.2 License set mgt 12 hr

11.3 License set mgt 4 hr

15.1 Plug mgt 4 hr

15.2 Plug mgt 4 hr

15.3 Plug mgt 1,6 hr

16.1 Plug type mgt 4 hr

16.2 Plug type mgt 4 hr

19.1 Stats 1,6 hr

19.2 Stats 1,6 hr

20 Modif. Mot de passe 8,8 hr

21 Modif email 4,8 hr

23 Aide en ligne 4 hr

24 Bug report 4 hr

4.7.3. Calendrier global Le calendrier détaillé, journalier, des tâches effectuées par chacun des trois développeurs n'est pas inclus dans ce document. Le travail de développement est réparti au total sur 14 jours ouvrés. L'ensemble des tâches est résumé ci-dessous. Activité / temps en semaines

to to+1 to+2 to+3 to+4 to+5 to+6 to+7 … to+19

Formation

Développement

Intégration, tests finaux, documentation

Livraison

VA

Mise en production

VSR – 12 sem.

Gestion de projet


63

4.8. Conclusions

4.8.1. Une nouvelle application plus efficace Globalement, la nouvelle architecture garantit plus de constance dans le temps de réponse des différentes pages, par rapport à l'application actuelle. Le gain de temps peut aller jusqu'à 300% sur les pages dont les traitements sont les plus simples. Des élément importants de cette rapidité sont l'accès direct à Tamino par requête HTTP, en lecture, ainsi que le traitement SAX. Cependant l'écriture de fichier sur disque se révèle aussi lent.

4.8.2. Une prise de risques nécessaire D'après les éléments dont je disposais, j'ai estimé nécessaire d'utiliser la version 2.1-dev et j'ai assumé la responsabilité d'un échec éventuel qui aurait conduit à une perte de temps. Par exemple, après avoir cherché une alternative à l'écriture de fichiers sur le disque pour envoi par email, j'ai choisi d'utiliser le SourceWritingTransformer. Or je ne pouvais intégrer ce composant de manière correcte à Cocoon 2.0.3. C'est donc l'élément déterminant du passage vers une version en cours de développement.

4.8.3. Une documentation réalisée variée Ayant travaillé sur ma tâche majeure d'analyse et développement ainsi que secondairement participé au développement basé sur l'existant j'ai produit plusieurs sortes de documents : - documentation fonctionnelle du projet (document séparé du mémoire et intégré à celui-ci) ; - document d'installation et déploiement sur un serveur d'applications de mes réalisations ; - javadoc du projet ; - fichier .war regroupant les sources, les classes, les autres éléments de la web application ainsi que

la javadoc et le document d'installation ; - documents souvent en anglais, traitant des moteurs de servlets JRun (plusieurs versions) et

Tomcat, ainsi que de l'API Tamino XML:DB. Mon rôle a été de déterminer si l'existant pouvait être porté sous JRun 3.1 et 4, ainsi que de comparer JRun 3.1, 4, et Tomcat 4.0. D'autre part, j'ai expliqué comment faire fonctionner l'API Tamino XML:DB et Cocoon. Quelques informations jugées utiles sont reportées en annexes ;

- planning détaillé du développement avec MS Project.

4.8.4. Quelques problèmes rencontrés § Des conflits entre les différentes versions de Xerces, parseur XML, sont très répandus. La version

1 utilise l'APIs SAX1, et la version 2 l'API SAX2 plus riche que SAX1 (gestion des namespaces). Les incompatibilités sont rencontrées lorsque par exemple le moteur de servlet utilise une version 1 de Xerces et la web application une version 2, ce qui fut le cas lorsque j'ai utilisé Tomcat 4.0.3 et Cocoon 2.0.3. Dans ce cas il a fallu mettre à jour le parseur de Tomcat, comme celui-ci est chargé en premier en mémoire. Cocoon ne supporte que des parseurs version 2, de même pour le driver Tamino XML:DB.

En passant à la version 4.0.5 puis 4.1.12 de Tomcat ce problème ne s'est plus posé, le moteur utilisant une version 2 de Xerces. Un collègue, M. Marc m'a aidée à mieux comprendre et résoudre le phénomène au niveau des .jar. § Un moteur de servlets est un élément fragile, s'i l y a incohérence, à la suite de recompilations

partielles par exemple, dans les fichiers qu'il doit exécuter, il y aura des erreurs. Il faut donc nettoyer le cache du moteur (pour Tomcat c'est le dossier work).


64

§ Pour l'interaction de Cocoon et Tamino via l'API XML:DB, j'ai fait appel à M. Marc, qui a modifié le driver Tamino XML:DB qui était non fonctionnel pour Cocoon.

§ J'ai également dû apporter une attention particulière à la sécurité de l'exécution de l'application :

Tomcat 4.0 et JRun 3.1 sont sujets à des failles de fonctionnement, j'ai donc cherché les correctifs à appliquer. J'ai eu à préparer un CD contenant tous les fichiers nécessaires à l'installation de l'exécutable de JRun 3.1.


65

5. L'Open source : présentation et enjeux Comme mon projet s'est basé aussi bien sur des logiciels commerciaux qu'open source, j'ai jugé utile d'étendre ma réflexion à un état de l'art sur ce type de licence : - un panorama diversifié de licences : différents besoins, différentes stratégies ; - où en est le marché en 2002 ? - le développeur open source : mythes et réalités ; - quel positionnement dans le cadre du génie logiciel ? - des modèles économiques possibles ; - utilisateurs : le choix d'utiliser l'outil ou de changer de modèle économique ; - pour conclure, quelques exemples et éléments juridiques.

5.1. Présentation Cette partie traite de : - la définition de l'open source ; - un bref historique ; - les différents types de licences - implications et brièvement les modèles économiques associés ; - quelques acteurs importants et leur rôles, historiquement ou de nos jours ; - une brève comparaison des éléments essentiels du logiciel open source et propriétaire.

5.1.1. Définition de l'open source Eric Raymond, acteur depuis de nombreuses années dans le milieu de l'open source, définit, dans son livre La cathédrale et le bazar, deux types de valeurs économiques : la valeur d'usage en tant qu'outil, et la valeur de vente. La définition de l'open source n'est pas une licence de logiciel en soi. C'est une spécification de ce qu'on autorise aux licences de logiciels pour qu'elles méritent le nom d'open source. Cette définition est en quelque sorte une "déclaration des droits de l'utilisateur d'ordinateur". La version 1.0 établie en 1998 par Bruce Perens en rassemble les concepts et indique qu'on peut : - exécuter le logiciel sans contrainte ; - le modifier pour qu'il corresponde mieux à nos besoins ; - disposer pour ce faire, facilement et sans frais supplémentaires, de son code source ; - en redistribuer des copies (binaire, source) de manière gratuite ou non, intégrées ou non dans une

distribution ; - en distribuer des versions modifiées. La licence choisie définit quelles licences peuvent s'appliquer

aux travaux dérivés. Par ailleurs, la licence ne doit pas comporter de restriction sur l'identité de l'utilisateur ou le domaine d'application. Le graphique suivant place le logiciel open source (dit aussi libre) au sein des différentes catégories de logiciels. (source : Free Software Foundation).


66

Remarques : § Les logiciel open source n'est pas comparable à celui relevant du domaine public et sur lequel

aucune licence ne s'applique, ou du moins sur lequel l'auteur ne fait valoir aucun droit. Cependant cette notion de domaine public a un sens plus strict aux USA qu'en France où la propriété intellectuelle est inaliénable.

§ On entend par "commercial" : dont on peut tirer profit, et "propriétaire", qu'on ne peut modifier librement. Un logiciel open source peut être commercial (ex. distributions Linux).

§ Il n'y a aucune relation entre open source et "freeware" : logiciel gratuit mais dont les sources ne sont pas disponibles.

§ Un shareware est un logiciel propriétaire particulier présentant une version gratuite à usage limité dans le temps ou fonctionnalités réduites, ainsi qu'une version payante.

5.1.2. Une stratégie gagnante D'après Bruce Perens, "gourou" de l'open source : les droits [évoqués ci-dessus] comptent pour celui qui contribue à améliorer des logiciels car ils maintiennent tous les développeurs au même niveau. Quiconque le souhaite a le droit de vendre un programme open source, aussi les prix seront-ils bas et le développement destiné à conquérir de nouveaux marchés sera-t-il rapide. Quiconque investit de son temps à construire des connaissances sous la forme d'un programme open source peut fournir de l'aide sur ce dernier, et cela fournit aux utilisateurs la possibilité de mettre en place leur propre assistance technique, ou de choisir parmi des assistances techniques en concurrence les unes avec les autres. Tout programmeur peut spécialiser un programme open source pour le rendre utilisable dans des marchés spécifiques afin d'atteindre de nouveaux consommateurs. Ceux qui se lancent dans de telles entreprises ne sont pas tenus d'acquitter des royalties ni la moindre licence. La raison de la réussite de cette stratégie qui semble s'inspirer du communisme, alors que le communisme est lui-même un échec patent dans le monde entier, vient du fait que l'économie de l'information est fondamentalement différente de l'économie qui règle la consommation des autres produits . (source : "Open Sources: Voices of the Open Source Revolution", O'Reilly, 1999).

5.1.3. Bref historique

5.1.3.1. La pratique avant la théorie La définition de l'open source a vu le jour dans un document présentant les grandes lignes d'un logiciel libre : distribution Debian de GNU/Linux, en 1997. Debian, un système Linux de la première heure, toujours populaire de nos jours, était entièrement constitué de logiciels libres. La définition finale, plus générale, a été entérinée en 1998. En revanche sa pratique a été bien antérieure, sous le nom de free software, dès les années 1970, et tire son origine du principe de fonctionnement à temps partagé des systèmes d'exploitation d'alors,


67

ainsi que du manque de ressources et de la nécessité d'entraide entre programmeurs. Et aussi d'une certaine éthique.

5.1.3.2. 1984, premier coup d'éclat En 1984, Richard Stallman, membre de l'Institut de Technologie du Massachusetts (MIT), fonde la Free Software Foundation (FSF) et créé le système GNU (ensemble de logiciels GNU et autres). C'est un militant de l'open source, opposant à la commercialisation des technologies mises au point par le MIT. Dans le même temps, le Computer Science Research Group (CSRG) lance sur la Côte Ouest ce qui deviendra le projet BSD. A cette époque apparaissent les premiers systèmes Unix propriétaires, ainsi qu'un abandon des technologies libres à temps partagé en faveur d'autres propriétaires. De bons éléments des laboratoires de Berkeley et du MIT rejoignent des sociétés commerciales. C'est aussi le début des stations de travail individuelles. Trois courants de pensées s'affrontent, liées à des technologies : ARPAnet/PDP-10, Unix/langage C, enthousiastes des premiers ordinateurs individuels.

5.1.3.3. 1989, la licence BSD née sous la pression de constructeurs 1989 voit le premier code librement redistribuable produit par les laboratoires de Berkeley, initiateurs de la licence BSD. En effet les constructeurs de produits réseaux pour PCs trouvaient trop chères les licences délivrées par AT&T pour l'obtention de binaires et de sources. Le code réseau et les programmes utilitaires associés furent donc "libérés" sous le nom de Networking Release 1. L'obtention directe de Berkeley coûtait 1000 dollars, la redistribution était gratuite. Les solutions proposées par BSD se sont répandues rapidement grâce au réseau internet et ont donné naissance à divers projets : NetBSD, FreeBSD, OpenBSD.

5.1.3.4. 1991, le premier système d'exploitation libre complet Linus Torvalds proposa, cette année-là, la somme d'efforts basés sur la boîte à outils de la FSF, son apport personnel résidant dans le noyau Linux. Le système GNU/Linux (licence GPL) marqua un tournant sociologique : un système d'exploitation peut être développé de manière décentralisé grâce à l'internet, et se révéler de qualité comparé aux offres commerciales, malgré sa complexité intrinsèque.

5.1.3.5. 1998, maturité sémantique et commerciale Sous l'influence de Bruce Perens, la communauté adopta le terme "open source" afin de lever l'ambiguïté du mot "free" en anglais, qui évoque la gratuité. Elle tient également à promouvoir le message de capacité à produire un logiciel puissant et de qualité. La licence GPL entravant les projets commerciaux, celle BSD ne valorisant pas assez les efforts de la communauté, Netscape a mis au point cette même année la licence NPL (Netscape Public License) devenue Mozilla (MozPL ou MPL). Des 1995 d'autres projets commerciaux de grande ampleur médiatique (Red Hat) avaient vu le jour auparavant, mais la licence MPL comble un vide dans le cadre de l'open source commercial.

5.1.4. Différentes licences Il existe principalement deux types de licences : copyleftées telles que la General Public Licence (GPL) et non copyleftées (possibilité d'ajout de restrictions, tendant vers un système propriétaire). Les points importants déterminés par une licence sont : - la nécessité ou non de fournir les modifications apportées au code source ; - la possibilité ou non d'intégration du produit libre avec un produit propriétaire ; - les conditions de commercialisation.


68

Il y a trois "ancêtres", General Public License, BSD, Mozilla, ainsi que d'autres versions dignes d'intérêt. En tout il existe, en 2002, une trentaine de licences satisfaisant tous les points de la définition de l'open source. En général une licence n'est modifiable de façon limitée que par l'organisme qui l'a créée.

5.1.4.1. GNU General Public License (GPL), version 2, 1991

5.1.4.1.1. Définition § Cette licence est la plus ancienne et aussi la plus "politique", lancée à partir des idées de Richard

Stallman en 1984. § Elle permet la libre copie, distribution et modification du logiciel. Elle précise explicitement que si

le code ne peut être distribué en même temps que le logiciel, il doit y avoir une garantie de disponibilité du code à la demande pendant trois ans ou la fourniture d'un lien sur une source du code.

§ Chaque développeur garde la reconnaissance individuelle (copyright) de la version du logiciel qu'il a adaptée/réalisée.

§ Si des lois gouvernementales l'exigent, des restrictions d'usage ou de redistribution géographiques peuvent être incluses.

§ Seule la Free Software Foundation peut réviser cette licence.

5.1.4.1.2. Commercialisation – modèle économique § La commercialisation de logiciels sous licence GPL est possible uniquement dans des versions :

- propriétaires, le code personnalisé ne devant pas dépendre du code produit sous licence GPL au niveau de la compilation et des liens statiques. Le logiciel GPL est alors intégré dans un package ; - personnalisées, le code sous licence GPL n'étant pas prépondérant.

§ Le fait de distribuer un logiciel sous licence GPL, ou d'en assurer la garantie, peut faire l'objet d'un acte commercial.

§ Un modèle économique viable existe et repose sur l'association d'une branche séparée du projet non protégée par la GPL, et alors brevetable. L'auteur doit s'assurer que tout code apporté par des tiers est explicitement rendu disponible pour cette branche commerciale en déclarant qu'il en reste seul auteur et libre d'y intégrer tout code soumis pour intégration dans la version sous GPL.

5.1.4.1.3. Avantages - inconvénients § Cette licence est la plus ouverte et permet une distribution la plus large possible, la communauté

de développeurs sous licence GPL étant la plus grande. § La commercialisation est très limitée, de part le caractère "viral" de cette licence (copyleft), mais

une entreprise utilisant un produit sous licence GPL et fournissant des services ne peut être concurrencée sur le plan technique, elle conserve donc un avantage. En effet une amélioration par modification nécessiterait le passage des concurrents sous licence GPL.

5.1.4.1.4. Remarque § La licence GPL n'exige pas, comme la section 4 de la définition officielle de l'open source, de

distribuer de manière identifiable, d'une part, le code original, d'autre part les modifications (patches). Ce point est donc facultatif.

§ Tout produit ayant changé de licence en faveur de la GPL ne peut plus faire marche arrière.


69

5.1.4.2. Licences X : BSD, révision 1999

5.1.4.2.1. Définition § La licence BSD, de la famille X, apparue à la fin des années 1980 et révisée en 1999, permet la

libre modification du logiciel, les changements apportés pouvant cependant rester privés. A l'origine elle couvrait des programmes financés par le gouvernement américain.

Il est interdit d'utiliser, sans autorisation préalable, les noms de l'organisation ou des contributeurs d'une version du produit pour promouvoir une version dérivée. § La modification de 1999 a visé à ne plus avoir l'obligation de reporter les noms de tous les

contributeurs précédents.

5.1.4.2.2. Commercialisation – modèle économique La commercialisation est favorisée par ce type de licence : la licence BSD offre le meilleur contexte légal à tout nouveau participant, car elle ne laisse peser aucune inquiétude quant aux restrictions d'utilisation ou de redistribution. Il est possible pour l'entrepreneur de mélanger ou comparer ce logiciel avec son code propriétaire, et ne publier que ce qui, selon lui, fait progresser le projet et aide en retour.

5.1.4.2.3. Avantages – inconvénients § Il n'y a pas d'obligation de redistribuer le code source, juste une incitation implicite lorsque les

changements sont imités par des concurrents. Ainsi l'initiateur du changement, n'ayant alors plus d'intérêt commercial, peut libérer le code pour se consacrer à d'autres modifications qui lui apportent toujours un avantage compétitif. Il n'a plus à assurer la maintenance.

§ Ce type de licence ne convient pas pour les projets dont la viabilité n'est pas garantie, de part le petit nombre de développeurs initiaux.

§ Cette licence ne comporte aucune incitation à encourager les entreprises à améliorer le code.

5.1.4.3. Mozilla Public License (MozPL ou MPL), version 2, 1998

5.1.4.3.1. Définition La MPL ressemble à la licence BSD, mais elle requiert que les modifications apportées à la distribution (dénotant ici les fichiers du code source distribués) soient aussi publiées sous MPL, et restent ainsi intégrables au projet. Cela permet à une entreprise d'ajouter une interface à une bibliothèque de code propriétaire sans exiger que les autres bibliothèques de code soient aussi diffusées sous MPL, elle ne concerne que l'interface. Plusieurs clauses de la MPL protègent à la fois le projet dans son ensemble et ses développeurs contre un brevet déposé sur le code contribué. Elle impose que l'entreprise ou la personne contribuant au projet abandonne tout droit découlant du code. Remarque : La Netscape Public Licence (NPL), version antérieure de la MPL, autorisait Netscape à placer des parties de son produit, Mozilla, ne relevant pas de code original ou modifié ultérieurement, sous une autre licence.

5.1.4.3.2. Commercialisation – modèle économique La MPL permet une commercialisation par intégration de composants open source et propriétaires et laisse libre cours au développement de fonctionnalités à valeur ajoutée.


70

5.1.4.3.3. Avantages – inconvénients § Cette licence favorise un usage commercial de l'open source. § Elle tient compte de la menace que constitue le système de brevets (gel temporel de l'usage par

d'autres personnes d'innovations à des fins de modifications) même si la section 2.2 est critiquable, concernant le renoncement aux droits sur toute partie de Mozilla et non seulement sur le code soumis. Cette section reste cependant spécifique à l'entreprise Netscape, initiateur de la licence.

5.1.4.3.4. Remarques La licence MPL est au départ spécifique à Netscape avec certaines clauses définies sur mesure pour protéger ses droits, elle a été par la suite adoptée par d'autres entreprises qui n'hésitent pas à l'adapter à leur situation.

5.1.4.4. GNU Library General Public Licence (LGPL), version 2.1, 1999

5.1.4.4.1. Définition Nommée aussi General Lesser Public Licence, c'est un hybride de GPL et de BSD : elle s'applique plus spécifiquement à des bibliothèques logicielles (collection de fonctions et données prévues pour être associées à un programme et former un exécutable). Elle autorise la liaison de bibliothèques sous cette licence avec des produits commerciaux. Si des portions de bibliothèques sont intégrées à un logiciel alors il faut que la licence choisie permette le reverse engineering de ce logiciel.

5.1.4.4.2. Commercialisation – modèle économique Les produits utilisant les bibliothèques sous cette licence ne sont pas liés à cette licence, il y a donc commercialisation possible. En revanche, si leur développement est basé sur ces bibliothèques ils doivent être soumis à cette licence et donc non commercialisables. Le modèle économique repose sur l'intégration de bibliothèques open source au sein d'un produit commercial, tout en pouvant se passer des fonctionnalités apportées par celles -ci.

5.1.4.4.3. Avantages - inconvénients § Cette licence est utilisée dans le cas où on souhaite que des bibliothèques libres deviennent un

standard de par l'usage, ou remplacent des bibliothèques propriétaires (non limitation aux produits libres).

§ Elle peut promouvoir l'usage d'autres produits libres par satisfaction de besoins.

5.1.4.5. Zoom sur quelques autres licences J'ai utilisé dans le cadre de mon travail des produits soumis à des licences spécifiques, je les évoque donc dans ce paragraphe.

5.1.4.5.1. Common Public License, version 1.0, 2001-2002 § La CPL est dérivée de la IBM Public License, certifiée en 1999. § Si le code original est modifié mais non distribué, il n'y a pas obligation de rendre publiques les

modifications, dans le cas contraire oui. § Les travaux dérivés peuvent être placés sous une autre licence mais celle-ci doit être compatible

avec la CPL en ce qui concerne la partie de code original. En revanche, l'ajout d'un module indépendant à un code licencié CPL n'implique pas que ce module passe sous CPL.


71

§ Dans le cadre de la commercialisation, un contributeur de modifications ne peut pas faire dépendre sa responsabilité (garantie facultative, stabilité) d'autres contributeurs, vis-à-vis du récipiendaire final du produit.

5.1.4.5.2. Licence Apache, version 1.1, 2000 § Elle est dérivée de la BSD. La redistribution des produits est libre à condition d'inclure la licence

dans chaque source ou texte, et une version plus courte dans la documentation destinée à l'utilisateur final. Les noms "Apache", "Apache Software Foundation" sont des marques réservées, leur utilisation dans le cadre de produits dérivés est soumise à approbation.

5.1.4.5.3. Licences utilisées par Sun ©

5.1.4.5.3.1. Sun Industry Standards Source License, version 1.2, 2000 § La SISSL est certifiée OSI et représente le type de licence principal. Les différents produits de

Sun peuvent cependant avoir chacun leurs licences spécifiques (donc pas forcément open source).

§ La SISSL se comporte essentiellement comme une licence BSD, autorisant la réutilisation de code tant qu'on ne s'écarte pas des standards (APIs, formats de fichiers…). Un délai de 120 jours est donné avant la commercialisation. Dans le cas contraire de non-respect des standards, elle a certaines conséquences d'une licence GPL : l'auteur doit révéler publiquement le code ou des spécifications et références d'implémentation (délai de 30 jours après commercialisation). Cette dernière alternative est prévue pour encourager l'utilisation de SISSL sans crainte de devoir révéler tous les "secrets" d'innovations, parce que la publication d'une référence d'implémentation suffit pour permettre l'utilisation de nouveaux formats ou APIs.

§ La SISSL autorise l'intégration du code source original (de Sun, sous SISSL) à un développement plus large. Les produits dérivés ainsi crées peuvent être placés sous n'importe quelle licence. La part de code original doit rester sous licence SISS, ou à défaut, les limitations doivent être indiquées dans un fichier "LEGAL".

§ La partie "Exhibit A" de la licence doit être incluse dans chaque élément de code, ou à défaut un emplacement où elle est susceptible d'être trouvée facilement par l'utilisateur final.

§ La responsabilité en terme de garantie, support, etc., incombe au dernier contributeur qui ne peut se défausser sur l'initial.

§ Sun est seul responsable de placer le code original sous une version ou une autre de ses licences, et de les réviser.

5.1.4.5.3.2. Sun Community Source License, hybride d'open source et propriétaire Afin de télécharger le code à partir du centre de téléchargement Sun Download Center, le demandeur doit s'enregistrer auprès de Sun Community en fournissant des informations nominatives ainsi que sur son entreprise et sa fonction occupée. Cet acte correspond aussi à la nécessité de respecter les lois gouvernementales régulant l'exportation et la distribution de logiciels. Cela équivaut à souscrire au Sun Community Source Licensing (SCSL), qui est un mélange de principes de licences :

- open source : il existe une communauté d'accès ouvert et reposant sur une infrastructure, avec trois niveaux de license : pour la recherche, pour un déploiement interne, pour un usage commercial ;

- propriétaires : la compatibilité entre toutes les versions du logiciel déployées est requise et testée par Sun.

Par exemples, quelques restrictions propriétaires s'appliquent suivant les produits : § L'exécutable (binaire) du J2SE (anciennement nommé JDK ) est redistribuable librement à

condition d'être associé à un élément à valeur ajoutée : applet, application, magazine. § Un logiciel non encore officiel (version beta du Java SDK) n'est pas redistribuable librement et ne

peut faire l'objet de modifications extérieures à Sun Community.


72

§ Le code source du Java 2 SDK n'est pas accessible pour un certain nombre de pays dont les termes de protection de la propriété intellectuelle sont jugés trop limités. De ce fait une détermination du domaine et du pays associé à l'ordinateur visiteur du site est effectuée par requête DNS. En octobre 2002, 45 pays figurent ainsi sur la liste des autorisés, parmi les 192 du monde (selon CountryWatch.com).

5.1.4.5.3.3. Commercialisation La partie du code placé sous licences open source par Sun est nommée "Sun Community Source Code". Dans le cadre de l'association de ce code avec un code sous une autre licence pour un projet commercial, un accord doit être signé entre Sun et l'entrepreneur. La licence originelle de Sun s'applique aux travaux réalisés dans le cadre d'un usage de recherche, la licence signée avec l'entrepreneur s'applique pour tout autre usage (commercial).

5.1.4.6. Résumé des caractéristiques des principales licences

Licence Obligation de

fournir le code source

Peut être mélangé avec du logiciel

propriétaire

Les modifications peuvent être

rendues secrètes

On peut placer les travaux dérivés sous une nouvelle licence

Privilèges particuliers pour le détenteur du copyright, qui peuvent s'appliquer à vos

modifications GPL x LGPL x x BSD x x x NPL x x x compatible NPL x MPL x x x compatible MPL

SISSL x x selon le cas avec limitations

éventuelles clairement indiquées

CPL x x si pas de distribution compatible CPL Apache x x x Domaine

public x x x

Par ailleurs il n'y a aucune garantie sur le code original, la garantie est supportée par le dernier contributeur, qui dans certains cas ne peut explicitement se défausser sur d'autres contributeurs.

5.1.5. Quelques acteurs actuels et historiques

5.1.5.1. Free Software Foundation, sponsor du projet GNU La FSF a été fondée en 1985 par Richard Stallman, c'est le principal sponsor sur le plan organisationnel du projet GNU. Sa mission est de préserver et promouvoir le logiciel open source, ainsi que les droits des utilisateurs de ce type de logiciel. Elle s'appuie sur des donations individuelles aussi bien que la vente de distributions, documentation et produits promotionnels. La FSF Europe a été lancée en 2001. Elle collabore activement avec des juristes afin de faire respecter et influencer les lois relatives à l'open source.

5.1.5.2. Open Source Initiative : certifier et promouvoir l'open source Cette organisation non gouvernementale sans but lucratif a été fondée en 1998 à l'initiative de Bruce Perens et Eric Raymond. Elle comporte un board de sept directeurs exécutifs. Son seul but est de gérer la promotion de l'open source et sa marque de certification. Le processus de certification nécessite la comparaison de la licence proposée aux licences existantes et à la définition officielle de l'open source.


73

5.1.5.3. Red Hat Software Inc., pionnier de la distribution d'open source Red Hat a été fondé en 1994 par Bob Young et Marc Ewing et s'est rapidement imposé médiatiquement comme un pionnier ainsi qu'une réussite commerciale. Son rôle est de travailler avec toutes les équipes de développement sur l'internet afin de rassembler quelque 400 outils open source en un système d'exploitation utilisable. Il est ainsi intégrateur et fournisseur de services. Il adapte le produit aux besoins de l'application que le client met en place. Il teste le produit fini et propose assistance technique et aide à l'installation et l'utilisation. Les mots-clés qui lui correspondent sont Confort et Confiance, aussi bien de l'utilisateur final que des autres entrepreneurs (fabricant d'ordinateurs…). Grâce à la vente de ses distributions et services, il peut financer une infrastructure pour la communauté open source. Parmi d'autres acquisitions, citons, en novembre 1999, Cygnus, un autre pionnier de l'open source commercial fondé en 1989. Red Hat a été introduite sur le marché du NASDAQ cette même année 1999.

5.1.5.4. Apache Software Foundation La Fondation Apache a été fondée en 1999, suite au projet de serveur HTTP open source Apache (1995). Son rôle est de fournir un support organisationnel, légal et juridique aux projets open source sous sa responsabilité. La Fondation remplace le Groupe Apache en tant qu'organisation à but non lucratif. Basée sur l'appartenance d'individus - les sociétés pouvant être représentées -, elle a pour but d'assurer la pérennité de projets et leur croissance, la collecte de dons afin de les financer, ainsi qu'un cadre de protection juridique. Depuis l'an 2000 elle organise, aussi bien aux USA qu'en Europe, ApacheCon, un rassemblement rassemblant les experts de la communauté ainsi que le grand public.

5.1.5.5. SourceForge, hébergement et centralisation de projets SourceForge (noms de domaines enregistrés en 1994 puis 1999) est le plus grand site web développé par et pour la communauté open source. Propriété de l'Open Source Development Network (OSDN), il offre aux projets open source un serveur web avec hébergement de domaines ainsi qu'une structuration de l'organisation et du fonctionnement du projet grâce à de nombreux outils. A fin 2000, on comptait 10 000 projets, le double mi-2001, et près de 50 000 fin 2002, avec un demi-million d'utilisateurs enregistrés. Les projets hébergés le sont sous de nombreuses licences, certifiées OSI ou non, et couvrent des applications pour une large gamme de plates-formes : Linux, Windows, Mac, Palm… Par ailleurs, des indexations de projets existants sont maintenues par Freshmeat.net et OpenSourceDirectory.org.

5.1.5.6. Internet Engineering Task Force, la force des standards par une documentation ouverte L'IETF, fondée en 1986, est un organisme à statut associatif composé de nombreux groupes de travail où sont présentes des personnes liées aux réseaux, à la vente et à la recherche. Elle a favorisé le concept de logiciel libre avant que le mouvement en lui-même se soit réellement formé, par une politique de documentation ouverte à toute phase d'élaboration des standards.


74

5.1.6. Quelques points de comparaison avec le logiciel propriétaire Le tableau suivant résume un comparatif issu du site adullact.org.

Logiciel propriétaire Logiciel libre Droits usage maîtrise plus large

Mutualisation des développements sous le contrôle de l'éditeur, choix des évolutions par l'éditeur

sous le contrôle de la communauté, choix des évolutions par les utilisateurs

Garanties clause de non-garantie. Toute garantie est liée à un surcoût

non garantie. obtenue de manière contractuelle après avoir fait jouer la concurrence

Mise en concurrence du support technique

éditeur différentes sociétés

Administration démarches administratives liées aux licences

Interopérabilité la taille du parc est un élément décisionnel

5.2. L'open source et le marché en 2002 Le marché de l'open source est comparable à un marché de produits destiné au grand public. La force des acteurs vient de la gestion de la marque : un marketing cohérent et un contact avec la communauté. La confiance de celle-ci ainsi que du consommateur sont essentielles. Nous verrons : les produits, les clients, les revenus et les tendances de ce marché.

5.2.1. Evolution structurelle des logiciels : du "back-end" vers le "front-end" On peut classer les logiciels en général suivant une ligne directrice, de l'infrastructure - produits implémentant les systèmes et plates-formes, jusqu'au noy au voire le matériel (pilotes) -, à l'application : produits de haut niveau d'abstraction, avec environnement graphique, et destinés à l'utilisateur non technicien. Le défi du logiciel open source a été, à partir des applications back-end (plus faciles à implémenter en respectant les standards, et correspondant aux besoins des ingénieurs), de s'ouvrir vers le front-end. En effet dans ce domaine les produits propriétaires ont pris une avance technologique vers le milieu des années 1980. Sur toute la gamme, mais de façon temporellement non synchrone, l'open source a sans cesse accru ses parts de marché en terme du nombre d'utilisateurs et de revenus générés.

5.2.2. Produits actuels Il existe des produits open source non cités pour des applications médicales, d'enseignement etc. Seuls les principaux secteurs sont passés en revue.

5.2.2.1. Systèmes d'exploitation

5.2.2.1.1. Du gros au petit système Le domaine des systèmes d'exploitation est varié et couvre aussi bien les besoins de serveurs et gros systèmes que stations de travail, et aussi les systèmes embarqués. § Serveurs : FreeBSD, OpenBSD, NetBSD… § Stations de travail : distributions Linux : Red Hat, Debian, Mandrake…


75

§ Systèmes embarqués, solutions Linux : PeeWee Linux, RTLinux et RTAI, TUXIA, Red Hat Embedded Linux, µC/Linux, Embedix, Hard Hat Linux.

5.2.2.1.2. Jusqu'à un tiers du marché

5.2.2.1.2.1. Estimation globale incertaine En 1997 les systèmes Unix/Linux représentaient 6% du marché. Il est assez difficile d'estimer à l'heure actuelle le pourcentage de ces systèmes, les indicateurs de vente et de téléchargement n'étant pas fiables. La part de marché globale en termes d'usage doit être de l'ordre de 10 à 20%.

5.2.2.1.2.2. Stations de travail : encore minoritaire Au niveau des stations de travail la part de marché est passée de 3% en 1997 à 10% en 2001.

5.2.2.1.2.3. Serveurs : la moitié du marché Linux : en 1997 : 6% du marché, 1998 : 15%, 2002 : 27%. Plus précisément, en 1999 17.5% des entreprises disposent d'au moins un serveur sous Linux, 36% en décembre 2000. Unix : en 1996 : 36% du marché, 1998 : 43%. Ce marché peut être lui-même découpé en acteurs principaux, les parts de marché variant suivant les pays et la gamme (entrée, milieu ou haut de gamme) : Sun, HP, IBM. Il y a un tassement de croissance à partir de l'an 2000.

5.2.2.1.2.4. Systèmes embarqués : un tiers du marché En 2001, 15% de systèmes Linux/Unix, 2002 : au moins 30% (prévision).

5.2.2.1.3. Zoom sur Linux : 18 millions d'utilisateurs Un graphique suivant, issu de http://counter.li.org, permet d'estimer la croissance de l'utilisation de Linux, même si Linux n'est qu'un système d'exploitation libre parmi d'autres, et que ces données sont issues d'enregistrements volontaires. Selon l'auteur du site, il y aurait 18 millions d'utilisateurs à fin 2002.

5.2.2.2. Serveurs universels

5.2.2.2.1. Trois fonctions essentielles Sous ce terme on regroupe : les serveurs de fichiers, les bases de données, et les serveurs d'application, ceci en opposition aux purs serveurs web.


76

§ Serveurs de fichiers : Samba. § Bases de données : des bases de données aussi bien relationnelles (MySQL, PostgreSQL,

Informix d'Oracle, Interbase) que natives XML (Xindice, eXist) ont conquis le marché depuis 1999. § Serveurs d'application : Zope (non J2EE, solution commerciale devenue open source en 1999),

Enhydra, Tomcat, Caucho, JBoss, Jonas.

5.2.2.2.2. Un cinquième du marché ? D'après une étude d'Unysis pour la Commission Européenne en 2001, environ 8% de ces serveurs sont open source dans le secteur public européen. Il est très difficile d'estimer la part de marché de ces serveurs.

5.2.2.3. Serveurs web : deux tiers du marché Les graphiques suivants, issu du site NetCraft.com, résument bien les choses : cet élément central de l'internet, aussi bien au niveau des protocoles que des contenus, est en écrasante majorité open source depuis des années (Apache principalement). Parts de marchés des différents types de serveurs web :

Nombre de serveurs web par type :

Par ailleurs, environ 40% des serveurs web reposent sur un système d'exploitation open source.


77

5.2.2.4. Réseaux et télécoms L'open source a une place prépondérante :

- fonctions utiles dans le cadre réseau (GLP) : BIND (95% du marché), Sendmail, Squid, gFTP, wget, Ipchains, OpenLDAP, OpenSSL, OpenSSH (deux tiers du marché)…

- outils de contrôle du bon fonctionnement du réseau (GPL) : Advanced Intrusion Detection Environment, Security Analysis Tool for Auditing Networks, Diald, GNU AWACS, Multi Router Traffic Grapher…

- serveur streaming multimédia : Gnucomm (GPL) ; - serveur de téléphonie multi-lignes : Bayonne (GPL).

Cependant ces produits ne fonctionnent souvent que dans des environnements Linux/Unix.

5.2.2.5. Aide à la programmation et à la modélisation Dans ce domaine, l'open source a une longueur d'avance, de part la couverture historique de leurs propres besoins par les développeurs. Des outils performants sont disponibles au niveau de :

- l'édition (GPL) : Emacs, Quanta+ ; - la compilation (GPL): GCC, Kaffee, FreePascal, GNU-Smalltalk, make… - le déboguage : gdb (GPL) ; - la programmation utilisant des circuits électroniques et langages associés : Electric, gEDA,

Alliance ; - la création d'interfaces graphiques : Qt (dérivé LGPL) ; - les environnements intégrés de développement : Kdevelop pour le C++ (GPL), Eclipse pour Java

(CPL)… - la gestion de versions : CVS (GPL).

Certains langages de programmation open source sont devenus des standards, tels que Perl (licence Artistic), PHP (licence PHP), Python (licence Python).

5.2.2.6. Applications à environnement graphique Le défi auquel doivent faire face ces applications est que l'utilisateur peut être attaché à son environnement propriétaire dans le cadre de systèmes existants, ou bien peut formuler des craintes d'incompatibilité de formats. Par ailleurs, des applications ajoutant une couche graphique à une fonction en ligne de commande (DDD (GPL) pour gdb par exemple) existent depuis longtemps.

5.2.2.6.1. Interfaces graphiques Deux interfaces graphiques sous GPL pour Linux connues, GNOME et KDE, ont nécessité du temps avant d'être matures. Une autre interface les a précédé : Open Motif (OGPL), similaire à la version commerciale de Motif (devenu standard d'interface graphique). GTK+ (LGPL) est par ailleurs une librairie associée au système X Window.

5.2.2.6.2. Suites bureautiques : timide mais prometteur Des processeurs de texte open source tels que AbiWord (LGPL) et LyX (GPL) ont existé avant les suites bureautiques.


78

Ces dernières sont présentes depuis 1996 avec WordPerfect de Corel (version pour Linux adaptée par Caldera, d'autres versions restant propriétaires). Cependant leur véritable essor repose depuis l'adoption du standard XML en 1999. Star Office (libre depuis 2000, GPLx) et OpenOffice (créé en 2000, GPL) sont des modèles de réussite. D'autres suites sont intégrées de base dans les distributions Linux (KOffice). On peut constater que deux suites majeures (Star Office, WordPerfect) sont passées d'un modèle propriétaire à open source, dès qu'elles ont visé le marché des systèmes d'exploitation libres. D'après une étude d'Unysis pour la Commission Européenne en 2001, la pénétration des suites open source dans le secteur publique européen est de l'ordre de 1%. D'autres applications à la frontière de la bureautique existent, tels que HylaFAX, depuis 1995 (licence type BSD) pour l'envoi de fax.

5.2.2.6.3. Imagerie et multimédia L'offre couvre l'essentiel des besoins même si elle reste méconnue en dehors des utilisateurs de systèmes d'exploitation libres, et si certaines solutions propriétaires professionnelles à fonctions multimédia avancées ne sont pas encore concurrencées par manque de bibliothèques libres :

- GNU Image Manipulation Program pour la retouche d'image (GPL) ; - Sketch pour le dessin vectoriel (LGPL) ; - SANE ("scanner access now easy" sous GPL), équivalant à Twain, pour communication avec un

scanner ; - Xanim, Xmovie (licences type BSD) : lecteurs vidéo et audio.

5.2.2.7. Zoom sur Linux : quoi et pour quoi ? Les deux tableaux suivants sont basés sur l'analyse des statistiques collectées par le site http://counter.li.org à la date d'octobre 2002. L'usage se répartit pour deux tiers en stations de travail, un tiers en serveurs web, avec un usage étendu de nombreuses applications réseau. Les distributions les plus prisées sont celles de Red Hat et Mandrake, suivies par Debian, Slackware, SuSE. § Distributions Distribution Nombre Pourcentage red hat 31569 29.65 mandrake 20232 19.00 debian 14273 13.41 slackware 12763 11.99 s.u.s.e 12354 11.60 diy 1438 1.35 conectiva 1402 1.32 others 13920 13.07

§ Usages But Nombre Pourcentage

workstation 64201 61.16 programming 45562 43.41

learning 40933 39.00 www server 35056 33.40

toy 28737 27.38 ftp server 26442 25.19 f ile server 25950 24.72

firewall 24935 23.75 mail server 24434 23.28

router 19072 18.17 dns server 18862 17.97 other server 16817 16.02

Others 13103 12.48

5.2.4. Clients, utilisateurs On peut entendre le terme "client" à deux niveaux :

- ceux qui utilisent directement l'open source et sont clients de la communauté, plus ou moins directement, même si ce n'est pas toujours au sens financier.

- les utilisateurs finaux : entreprises, particuliers.


79

5.2.4.1. De la communauté à la valeur ajoutée Une part des acteurs évoqués ici sont clients des distributeurs, lesquels sont le plus en amont dans la relation avec la communauté.

5.2.4.1.1. Distributeurs Les distributeurs Linux, tels que Red Hat, SuSE, Mandrake, sont au contact direct de la communauté. Ils vendent des packages contenant le logiciel et un contrat annuel de support. Ils sont en capacité de personnaliser au mieux le logiciel pour correspondre aux besoins des clients. Ils peuvent s'associer aux constructeurs d'ordinateurs (Dell, HP…) et aux éditeurs de solutions propriétaires portées sous Linux (Oracle). La valeur ajoutée est forte.

5.2.4.1.2. Distributeurs à valeur ajoutée (VARs) Leur offre inclut des composants propriétaires et open source, dans le cadre d'infrastructures existantes complexes. La valeur ajoutée réside dans leurs compétences métier. Ce sont IBM, Unysis, Accenture, CSC, Cap Gemini…

5.2.4.1.3. Intégrateurs système (SIs) Ils incluent un système d'exploitation, souvent Linux, dans leur offre logicielle. Leur force réside dans leur base client et leur réputation. Ils jouent un rôle non négligeable dans le passage de solutions Unix propriétaire vers Linux. Ce sont IBM, HP…

5.2.4.1.4. Editeurs indépendants de logiciels (ISVs) Ils veillent, dans le cadre d'un partenariat, à ce que leurs solutions soient certifiées compatibles avec des systèmes open source, et portées vers ces environnements. Ce sont Oracle, Veritas, BEA, IBM, Novell, Checkpoint, BMC, Tibco…

5.2.4.1.5. OEMs Les équipementiers informatiques associent le logiciel open source à leur offre matérielle. Ce sont IBM, HP, Dell, Compaq… Pour IBM le soutien actif et financement de Linux sont un moyen d'harmoniser les systèmes d'exploitation associés à ses serveurs.

5.2.4.1.6. Sociétés de service logiciel libre (SSLL) Souvent des start-ups, ces sociétés spécialisées peuvent être plus fragiles que les SSII classiques parce qu'elles s'appuient uniquement sur des solutions libres (pas de partenariats avec des solutions propriétaires). Leurs atouts sont l'indépendance vis-à-vis des vendeurs de logiciels, et le support de plusieurs distributions. Ce sont Alcove, Arkane, Linbox, Thisens, Abas Software…

5.2.4.1.7. Editeurs-libraires et organisateurs de conférences Pour eux, l'open source représente une opportunité de revenus supplémentaires.

5.2.4.2. Utilisateurs finaux Il est plus facile de quantifier les utilisateurs professionnels de l'open source que les particuliers.


80

5.2.4.2.1. Usage professionnel

5.2.4.2.1.1. Globalement Une étude réalisée en juin 2002 par l'International Institute of Infonomics pour la Commission Européenne, sur trois pays : la Grande-Bretagne, l'Allemagne, la Suède, caractérise l'usage de l'open source suivant la taille de l'entreprise (100 à 500 employés, plus de 500) et son secteur, plus ou moins orienté technologies de l'information. Suivant les "cellules" définies par l'étude, le taux varie entre 15 et 69%, avec une moyenne entre 25 et 45%. Le tableau suivant tiré de cette étude détaille les principaux usages de l'open source.

Les entreprises sont demandeuses de services variés liés à l'open source. Se référer aux modèles économiques du 5.5.

5.2.4.2.1.2. Secteur privé à haut niveau IT : quelques tendances L'étude suivante s'appuie sur l'interview de 40 Chief Technology Officiers du réseau InfoWorld, en 2001. Les informations qu'on peut en tirer donnent une bonne idée de l'usage de l'open source en entreprise privée à haut niveau de technologies internet et télécoms. § Usage actuel ou prévu de l'open source Serveur web 65% Système d'exploitation de serveur 63% Serveur d'application web 45% Test de déploiement d'application 45% Système d'exploitation de station de travail 38% Email, messagerie, collaboration 30% Gestion de réseau 25% Gestion de bases de données 25% Sécurité réseau 25% Gestion de stocks 10% E-commerce 10% Autres 8% Aucun 28%


81

5.2.4.2.1.3. Zoom sur le secteur public 5.2.4.2.1.3.1. Situation européenne D'après une étude réalisée en juin 2001 par Unisys pour la Commission Européenne. Six pays sur quinze, la Belgique, la France, l'Allemagne, l'Italie, l'Espagne, la Suède et les institutions de la Commission sont concernés par cette étude. Les logiciels libres sont employés dans tous les pays visités mais de manières clairement différentes :

§ La France et l'Allemagne sont les deux leaders innovateurs (l'Allemagne pour les réalisations concrètes et les directives, la France pour un appui croissant du gouvernement à l'utilisation des standards ouverts et des logiciels libres).

§ L'Espagne suit activement, notamment dans certains secteurs où des partisans du logiciel libre ont démontré leur efficacité, leur bon rapport qualité-prix et leur maintenabilité.

§ En Belgique, en Italie et en Suède, les réalisations existantes résultent d'efforts individuels qui ne sont pas - jusqu'à présent - activement soutenus par une politique de gouvernement.

Les sept premières raisons avancées pour l'usage de l'open source sont : l'interopérabilité, la sécurité, le respect des standards, les fonctionnalités, la facilité d'utilisation, le faible prix, la disponibilité du code source.

§ L'open source est généralement assez peu utilisé en raison d'investissements récents en infrastructures en partie propriétaires et couvrant les besoins.

§ D'autre part, les départements IT des différents acteurs du service public craignent qu'avec des prix de revient d'acquisition plus faibles les budgets ne soient réduits, ce qui empêcherait les investissements nécessaires en terme de ressources humaines.

§ Enfin, dans certains cas les solutions open source manquent de systèmes préinstallés, au niveau des stations de travail par exemple.

5.2.4.2.1.3.2. Administration française : obligatoire à partir de 2004 ? Dans une proposition de loi déposée au Sénat le 28 octobre 2002, il est souhaité de créer une Agence du Logiciel Libre, visant à contrôler l'usage rendu obligatoire, à partir de janvier 2004, de l'open source dans l'administration française. L'Agence doit étudier les cas dérogatoires, ainsi que veiller à la diffusion des modifications apportées au code source. Par ailleurs, des portails génériques open source (Lutèce) de gestion de documents (SDX, basé sur Cocoon et Lucene) sont promus respectivement par la ville de Paris et le ministère de la Culture.

5.2.4.2.2. Usage privé Les particuliers sont plutôt clients des distributeurs, recherchant des packages logiciels et des services tels que support et maintenance. Une grande partie, cependant, acquiert directement l'open source via internet. Les chiffres qu'on peut obtenir ne sont pas significatifs, en partie parce que l'immense majorité (90%) des ordinateurs vendus à destination du grand public sont associés à une offre logicielle Windows.

5.2.5. Revenus L'open source génère des revenus, essentiellement au niveau de l'intégration et des services associés. Citons quelques distributeurs Linux et leurs chiffres d'affaire :

- Turbolinux, 12 millions de dollars (2002). Points forts : distributions, association avec des SIs (IBM, Dell…) ;


82

- Caldera, 40 millions de dollars (2001). Points forts : distributions, services, support ; - Red Hat, 90 millions de dollars (2001). Points forts : distributions, services, support, association

avec des ISVs ; - SuSE Linux AG, 50 millions de dollars (prévisions 2002). Points forts : intégration Linux, vente

directe et par redistributeurs, support de tous les "eServers" d'IBM ;

5.2.6. Tendances

5.2.6.1. De plus en plus de serveurs Les solutions serveurs, quelle que soit la gamme, et middleware, devraient connaître une expansion non négligeable.

source : Gartner, 2001 Les serveurs devant connaître le plus de croissance sont ceux dédiés à satisfaire un besoin précis et personnalisés pour cela. De même on pourrait assister à une généralisation de serveurs d'entrée de gamme s'appuyant sur Apache ou Samba, destinés aux petites administrations et entreprises.

5.2.6.2. Systèmes d'exploitation : extension et remplacement Dans l'étude réalisée par Unysis et déjà citée, les systèmes les plus menacés avant Microsoft Windows sont les Unix propriétaires (migration plus facile). D'après une étude plus récente, en 2002, de Morgan Stanley, un tiers des acquisitions de systèmes d'exploitation open source sert à l'extension de capacité, un tiers au remplacement de systèmes Windows, et un quart au remplacement de systèmes Unix.

5.2.6.3. La conquête des stations de travail grâce aux standards et à l'e-gouvernement La force de l'open source est de satisfaire et d'accompagner les nouveaux standards menant à plus d'interopérabilité. C'est dans ce mouvement que les applications "desktop" pourront prendre de l'importance sur les stations de travail. D'autre part, la mise en place du concept d'e-gouvernements s'accompagne d'un choix politique de solutions non propriétaires.

5.3. L'open source et le développeur Ce paragraphe traite du développeur de logiciels open source, en y incluant des éléments d'analyse anthropologique par Eric Raymond. La dernière partie concerne mon expérience personnelle.


83

Pour les données chiffrées, il s'appuie sur une étude réalisée en juin 2002 par l'International Institute of Infonomics de Maastricht, et concernant des développeurs à 70% l'Europe et 14% des USA.

5.3.1. Profil et motivations

5.3.1.1. Démarche intellectuelle et "sociale" Sur le plan psychologique, la plupart de ces gens ne voient pas la programmation comme une chose ennuyeuse ou un travail. Ils recherchent la satisfaction intellectuelle. D'autres se considèrent comme des scientifiques préférant la connaissance au profit matériel. La démarche peut procéder de la quête d'une réputation, la programmation étant vécue comme une culture du don, la valeur d'un travail provenant du fait qu'il est partagé par d'autres. Cela peut aussi être vécue comme une prise de pouvoir, réalisation d'outils à partir d'un sentiment de frustration face à l'existant.

5.3.1.2. Le pragmatisme de mise De nombreux développeurs open source sont historiquement des étudiants qui ont appris l'informatique sous l'influence de GNU et lors de leur passage dans l'industrie ont continué à promouvoir l'open source afin de disposer des meilleurs outils. Les quatre cinquièmes des développeurs open source ont débuté cette activité afin de développer leurs compétences, un tiers par "militantisme" pour la liberté du logiciel.

5.3.1.3. Qui sont-ils ? § 98% des développeurs sont des hommes. La plupart ont entre 19 et 33 ans. Les deux tiers ont le

statut d'employé, un sixième indépendant, un sixième étudiant. Un tiers sont des ingénieurs en génie logiciel.

§ 70% passent jusqu'à dix heures par semaine sur des projets open source. § La moitié des développeurs sont également impliqués dans des projets de logiciels propriétaires.

5.3.2. Outils et méthodes Les développeurs utilisent des outils de travail collaboratif tels que CVS, et communiquent par le biais d'emails, de listes de discussion et de forums. Les outils sont évoqués sur le plan organisationnel et technique dans la partie 5.4.2. Quelques rôles relatifs à la maintenance peuvent être dégagés dans le cadre d'un projet : § Coordination par mise en place des serveurs web et CVS, de la base de données et de

l'infrastructure de rapport de bugs § Coordination de code et résolution des incompatibilités § Maintenance de la base de données de bugs § Maintenance de la documentation et du site web § Stratège/évangéliste/commercial. Cette mission nécessite de savoir placer le projet dans une vue

d'ensemble, en direction des utilisateurs et d'autres développeurs

5.3.3. A la frontière de la communauté – expérience personnelle J'ai été utilisatrice des frameworks Struts puis Cocoon 2, tout autant que de modules java à usage plus large : Xalan, Xerces, Fop, ainsi que du serveur Tomcat . J'ai pris conscience de l'organisation et des ressources – outils, aide, développements spécifiques, débats philosophiques – qui constituent la richesse de la communauté open source.


84

Au bout de quelques temps un fort courant de sympathie circule entre les utilisateurs, et cela peut être source d'opportunités professionnelles lors d'une recherche d'emploi, mais dans mon cas la localisation géographique proposée ne convenait pas. Inutile de dire qu'un certain sentiment de fierté est présent, vis-à-vis des réalisations de chacun et de l'expansion de Cocoon à travers le monde, tels que le témoignaient les publications de conférences en Europe ainsi que les liens vers de nouveaux sites web réalisés avec Cocoon. De plus, comparé à un simple forum d'aide sur un outil propriétaire, le forum des utilisateurs sait qu'il est soutenu par celui des développeurs, et à condition de disposer des ressources nécessaires chacun peut devenir développeur à son tour. Ce sentiment est très présent.

5.4. L'open source et le génie logiciel

5.4.1. Le logiciel open source

5.4.1.1. Pas toujours en phase mais… L'analyse suivante reprend celle de Paul Vixie, plaçant le logiciel open source dans le cadre des étapes classiques du génie logiciel.

5.4.1.1.1. Expression des besoins et dossier de spécification La constitution d'un "DSLL" (Dossier de Spécification d'un logiciel libre) s'effectue généralement grâce à une liste de diffusion ou à un groupe de discussion où utilisateurs et développeurs discutent directement. Le consensus se fait sur ce que les développeurs ont retenu de la discussion ou sur ce avec quoi ils sont d'accord. Si un consensus suffisant ne peut être obtenu, il va en résulter un "embranchement dans le code" où d'autres développeurs se mettront à diffuser leurs propres versions. L'équivalent du DSL dans le cas du logiciel libre peut être très enrichissant mais peut créer des conflits aigus dont la résolution n'est pas possible (ou pas tentée).

5.4.1.1.2. Conception préliminaire au niveau système Cette étape est soit implicite - une idée "géniale" - soit progressive au cours des développements. De cette conception résulte cependant la qualité finale du logiciel.

5.4.1.1.3. Conception détaillée L'open source pèche sur ce plan. De même une documentation insuffisante peut empêcher une compréhension et réutilisation optimale du code.

5.4.1.1.4. Implémentation C'est la partie la plus motivante pour les développeurs. La principale différence dans une réalisation de logiciel libre non financé vient de ce que la revue du code est informelle. Il n'y a généralement pas de supérieur ou de pair pour regarder le code avant qu'il ne soit diffusé. Il n'y a habituellement pas de test unitaire, de non-régression ou quoi que ce soit d'autre.

5.4.1.1.5. Intégration Elle consiste essentiellement en l'écriture de fichiers d'aide, en tests de construction du projet sur les plates-formes auquel le développeur a accès, et en la diffusion du produit fini. Il n'y a pas, habituellement, de plan de test au niveau du système et pas de tests unitaires. En général les efforts consentis pour les tests sont très limités. Des exceptions existent, telles que Perl et PostgreSQL. Cependant ce manque des tests avant diffusion n'est pas une faiblesse.


85

5.4.1.1.6. Tests in situ C'est un point fort des logiciels libres, de part l'implication des utilisateurs souvent développeurs eux-mêmes. L'accessibilité du code favorise les corrections rapides. De même, le risque d'éventuels actes de malveillance à la suite de failles de sécurité détectées non signalées est minime.

5.4.1.1.7. Maintenance et assistance Plusieurs facteurs entrent en compte : § Il n'y a pas de planification possible dans le cas où de nombreuses personnes modifient le code § Il existe un modèle économique pour des distributeurs et cabinets de conseil, à condition de :

- reprendre le logiciel en interne et l'intégrer dans une démarche qualité ou - assurer les "meilleurs efforts" au lieu de "résultats garantis",

généralement sur une version modifiée.

5.4.1.2. … des outils "remarquables"

5.4.1.2.1. Partage du code : CVS Concurrent Versions System, évoqué plus en détail en annexe 9.7.1, permet le partage du code source et sa mise à jour concurrente. D'autre part, les questions importantes et les descriptions commentées et raisonnées d'innovations majeures peuvent être intégrées au reste des fichiers par le biais de cet outil. Enfin, la structuration en branches permet de gérer les divergences éventuelles.

5.4.1.2.2. Communication : forums et listes En général il y a une liste de discussion pour chaque sous-groupe cohérent de développeurs ainsi qu'une liste pour chaque projet grâce à laquelle le serveur CVS diffuse des avis de changements effectués. Des projets très actifs séparent une liste pour les développeurs, et une autre pour les utilisateurs. Les archives sont publiques.

5.4.1.2.3. Suivi et identification : bases de données Les bugs et versions sont suivis et archivés. Le projet Apache utilise Bugzilla et GNATS. Le projet Mozilla utilise Bonsai et Tindexbox, gérant les dépôts de contributions par modules sous la responsabilité d'un "propriétaire de module". Dans ce projet, les tronçons de code sont identifiés par auteur, ainsi que l'état, fonctionnel ou non, des fichiers. Les actes de malveillance sont ainsi identifiés et condamnés.

5.4.2. Le projet basé sur le logiciel open source

5.4.2.1. Conserver les points forts Par rapport à un projet basé uniquement sur des solutions propriétaires, un projet de développement et intégration basé en partie ou totalement sur des solutions open source mais réalisé en environnement "classique" ne connaît pas certaines des faiblesses évoquées dans les paragraphes précédents. Le dossier de spécification, la conception préliminaire et la conception détaillée se font de la même manière que les projets propriétaires, avec sans doute toutefois plus d'attention quant aux capacités et limitations éventuelles du logiciel open source.

5.4.2.2. Tester plus souvent ? L'intégration suppose quelquefois plus de tests, surtout si le logiciel open source est mis à jour souvent. Les tests en continu semblent le plus recommandés, si possibles.


86

5.4.2.3. Bien cerner les responsabilités Le contrat lié à la recette doit spécifier la part de responsabilité acceptée par le développeur-intégrateur. Par exemple pour l'étendue de la garantie et la couverture des coûts éventuels entraînés par les tests et adaptations à réaliser suite une mise à jour de la partie open source par le client.

5.4.2.4. Adopter les outils ? Les outils de la communauté tels que CVS, les principes de communication et suivi des bugs, semblent utilisables sans problème par les développeurs de solutions propriétaires ou mixtes. Il convient de juger l'apport fonctionnel et le coût éventuel initial (faible) entraîné par l'abandon de solutions propriétaires existantes.

5.5. Des modèles économiques basés sur l'open source Le défi de ces modèles est de trouver des moyens efficaces de gagner de l'argent tout en laissant au client les avantages de l'open source.

5.5.1. Vue d'ensemble

5.5.1.1. Chaîne de valeur ajoutée du logiciel

Les éléments pour lesquels on peut quantifier une différence entre logiciel open source et propriétaire sont : § développement, en général moins centralisé pour l'open source § documentation, en général associée au logiciel propriétaire et suffisante pour ce dernier § promotion et vente : dans le cadre de l'open source, elles concernent les distributions, produits

complémentaires et services § support, par la communauté open source et plusieurs types d'entreprises

5.5.1.2. Distributeurs, revendeurs, et services Les modèles économiques suivants sont purement basés sur l'open source et ne pourraient exister sans lui. Une même entreprise peut utiliser plusieurs modèles en même temps. C'est d'ailleurs recommandé afin de générer assez de bénéfices.


87

5.5.2. Cinq modèles, quelquefois pour un même acteur

5.5.2.1. Distributeurs Linux

5.5.2.1.1. Produits et services Ils vendent le système d'exploitation complet, assemblage d'éléments réalisé par leurs soins, aux utilisateurs finaux ; ou bien des outils d'administration adaptés à une application, aux administrateurs IT. Ils proposent généralement des services associés : consulting, intégration, support, formation, ainsi que des produits dérivés.

5.5.2.1.2. Quel marché ? Deux segments de marché sont couverts : § Marché de masse, avec produits standardisés, que ce soit pour serveurs ou stations de travail.

Les clients sont des PME aussi bien que des particuliers. § Marché de "solutions individuelles", incluant une part non négligeable de services, envers les

moyennes et grandes entreprises.

5.5.2.1.3. Image de marque et réseaux de distribution

Points forts du modèle Points faibles du modèle Les distributeurs s'appuient sur des VARs Le profit engendré par unité est faible

La différentiation des dis tributeurs dépend de leur image de marque

Les distributeurs doivent avoir des compétences supplémentaires en consulting et processus business

5.5.2.2. Distributeurs hors système d'exploitation

5.5.2.2.1. Produits et services Il s'agit d'applications et outils open source excluant les systèmes d'exploitation, qui peuvent être en partie propriétaires. Ces distributeurs emploient une partie des développeurs d'un projet open source particulier. Par exemple le serveur d'application Zope, la base de données MySQL, le serveur web Apache.


88

5.5.2.2.2. Quel marché ? La plupart de ces produits sont en position dominante sur leur marché. Les clients principaux sont les VARs et les OEMs.

5.5.2.2.3. Pas des "pure players" Ces distributeurs ne sont pas des "pure players" open source, s'ils veulent assurer des bénéfices suffisants. Ils doivent donc gérer cette problématique vis-à-vis de la communauté qu'ils supportent.

5.5.2.3. Détaillants de distributions et produits complémentaires

5.5.2.3.1. Produits et services Ils sont en aval des distributeurs et représentent leurs canaux de vente principaux. Ils vendent les produits logiciels de ces derniers, ou des documentations. Par exemple O'Reilly est spécialisé open source et édite et vend des livres documentaires et de formation.

5.5.2.3.2. Quel marché ? Le marché de masse est visé, et plus spécifiquement les utilisateurs à compétences techniques modérées et souhaitant les améliorer.

5.5.2.3.3. Répondre au besoin de documentation Ces acteurs jouent sur leur image de marque pour réaliser leurs ventes, en couvrant de nombreux projets open source. En général ce type d'activité est un revenu additionnel pour les distributeurs.

5.5.2.4. Places de marché et organisateurs de conférences

5.5.2.4.1. Produits et services § Les places de marché servent de points de rencontre entre les acheteurs potentiels

(organisations, individus) et les vendeurs. Les demandes des premiers peuvent être agrégées. § Les organisateurs de conférences sont soit spécialisés dans l'open source soit en tirent une part

de leurs revenus. Les éditeurs documentaires entrent souvent dans cette catégorie.

5.5.2.4.2. Quel marché ? Les pures places de marché ne se révèlent commercialement pas viables, d'une part parce que ce modèle ne se conforme pas à la philosophie open source, d'autre part parce que la valeur ajoutée de ces services est estimée insuffisante. Les organisateurs de conférences ont une place grandissante avec la popularisation de l'open source, cependant leur succès dépend autant de leur capacité à trouver les sujets attractifs du moment que de leurs capacités organisationnelles. Ils doivent cependant maintenir des prix bas.

5.5.2.5. Services et support

5.5.2.5.1. Produits et services L'offre couvre toute la gamme post-vente : consulting, intégration de systèmes, support, maintenance, administration distante, formation, gestion d'applications. Ces entreprises ne se limitent pas forcément à l'open source.


89

5.5.2.5.2. Quel marché ? Les clients sont des entreprises ne pouvant se satisfaire du support amené par la communication avec la communauté (rapport de bug…). Les services sont liés à un projet précis et incluent des garanties (niveau de support, délai…). L'offre peut aussi concerner des OEMs, ISVs.

5.5.2.5.3. Compétences produits ou processus Les sociétés de services peuvent se diviser en deux groupes : § les entreprises à expérience open source ancienne, possédant une expertise sur des produits et

techniques, et construisant leurs services à partir de ces bases § les entreprises sans vraie expérience de l'open source, mais avec de fortes compétences de

services, les étendant vers celui-ci La part de marché de chacun de ces groupes dépend de la demande en compétences produits (product know-how) ou en savoir-faire et méthodologies (process and methodology know-how). La réussite dépend de la demande du segment sur lequel s'est placé l'entreprise suivant ses capacités.

5.5.3. Un modèle pour Software AG ? En plus de ses solutions propriétaires, Software AG pourrait éventuellement infléchir sa politique vers les modèles de : § "distributeur hors système d'exploitation" (5.5.2.2.), afin de bénéficier de l'expertise technique de

développeurs open source § "services et support" (5.5.2.5.). Ceci concernerait plus la filiale française par exemple.

5.6. "De l'ère des éditeurs commerciaux de logiciels à celle des entreprises d'information" De plus en plus d'entreprises, à partir de modèles économiques propriétaires, se tournent vers l'open source pour une raison ou une autre, soit en tant que stratégie business, soit en tant qu'utilisateurs finaux. Quelques questions spécifiques sont également évoquées.

5.6.1. Utilisateurs professionnels…

5.6.1.1. Avantages § Points forts de l'open source : innovation, robustesse du code (qualité logicielle), facilité de

correction rapide de bugs, flexibilité et créativité pour l'adaptation aux besoins… § Le logiciel à faible coût ou gratuit permet au client de conserver son budget pour des services, du

conseil etc. § Les coûts de développement et correction des bugs sont généralement plus faibles. § L'extension de l'usage du logiciel facilitée ainsi que celle de nouveaux standards. § Il y a possibilité de vendre plus de matériel ou logiciel propriétaires en portant des solutions vers

des plates-formes open source. § Cela peut être une deuxième chance pour un logiciel propriétaire qui est au départ un échec

commercial, par exemple XEmacs de Lucid.


90

5.6.1.2. Critères décisionnels retenus Le tableau suivant est issu d'une étude de juin 2002 concernant le secteur public et privé de trois pays d'Europe : Grande-Bretagne, Suède, Allemagne, pour les éléments qui ont motivé le passage à des solutions open source. Les points mis en avant sont la stabilité, la sécurité, la performance ainsi que les économies de frais de licences ou indirectes, avant la possibilité de modifier le code source.

5.6.1.3. Avantages réellement retirés L'étude suivante s'appuie sur l'interview de 40 directeurs informatiques du réseau InfoWorld, en 2001. Les informations qu'on peut en tirer donnent une bonne idée des avantages qui priment pour les entreprises. § Bénéfices principaux retirés : Réduction des coûts de développement ou acquisition d'application 93% Réduction du temps de développement ou intégration 72% Réduction des coûts de maintenance 52% Meilleure qualité logicielle 45% Possibilité d'adapter et réutiliser le code 45% Mises à jour et patches sans délai 34%


91

5.6.1.4. Des inquiétudes, fondées ou non ?

5.6.1.4.1. Quelle maîtrise sur un projet ? Les entreprises souhaitent garder le contact avec les projets open source dynamiques dont elles tirent des revenus. Elles craignent qu'un concurrent ne pénètre le projet, aboutissant à une embranchement du code et incompatibilités finales, comme par exemple les systèmes d'exploitation BSD.

5.6.1.4.2. Support : assez développé de nos jours… Le support et l'assistance doivent être correctement assurés, or de nos jours l'offre de sociétés compétentes est suffisante en qualité et quantité.

5.6.1.4.3. Actes de malveillance ? Des personnes malveillantes pourraient profiter du libre accès au code pour profiter de failles de sécurité voire en créer. Or le code est suffisamment revu et les changements contrôlés pour que de tels actes tombent sous le coup de la loi. Les médias témoignent régulièrement de la rapidité de réaction de la communauté open source face aux agressions. On l'oppose, en partie polémiquement, à celle des systèmes propriétaires.

5.6.2. … ou changement de modèle économique ? Pourquoi ne pas envisager de tirer plus de revenus de solutions open source au détriment de celles propriétaires ? Au niveau du produit logiciel en lui-même, un certain nombre de questions se posent alors, en examinant plus spécifiquement les licences possibles (d'après Bruce Perens) : § Les termes sont-ils en accord avec vos objectifs à long terme ? § Pouvez-vous légalement y ajouter du code sous cette licence ? § Encourage-t-elle suffisamment les développeurs ? Sont-ils prêts, sinon, à vous ménager une

place en modifiant la licence ? § Votre contribution est-elle assez générale pour apporter une valeur ajoutée aux développeurs et

aux utilisateurs du projet existant ? Si elle ne constitue que l'implémentation d'une interface vers votre code propriétaire, elle ne sera probablement pas acceptée.

§ Si votre contribution est importante, pouvez-vous obtenir un statut équivalent à celui des autres développeurs, pour pouvoir effectuer ensuite directement des corrections de bogues et des améliorations ?

§ Pouvez-vous collaborer avec les autres développeurs ? § Vos développeurs peuvent-ils collaborer avec d'autres ? D'autre part, le développement de services basés sur l'open source doit se déterminer après étude de marché et des compétences disponibles : la stratégie de l'entreprise est-elle plus orientée produits ou processus ? Cependant certains coûts d'infrastructure restent incompressibles : mise en place de canaux de communication entre développeurs et mode extérieur, support de l'effort de développement open source.

5.6.3. Evocation de différentes problématiques

5.6.3.1. Vendeurs indépendants de logiciels Pour sortir du modèle du système propriétaire sur lequel fonctionnent leurs applications, les ISVs ont besoin d'un système :

- dont l'éditeur n'a pas le contrôle ; - dont le fournisseur n'endosse que la maintenance ;


92

- pour lequel ils commercialisent leurs applications en étant assurés que l'éditeur ne deviendra jamais un concurrent sérieux.

On trouve dans cette catégorie Corel (WordPerfect sous Linux), Oracle (DB2 sous Linux), IBM (soutient d'Apache)…

5.6.3.2. Assistance et support Si le logiciel libre est sans service d'assistance et qu'il ne correspond pas aux attentes du client, il est dans la même position que le logiciel propriétaire inadapté, à ceci près que le client a l'avantage de disposer des sources. Mais a-t-il le temps nécessaire et les compétences pour les valoriser ? Cependant cette situation se retrouve moins dès lors que les solutions open source gagnent du terrain.

5.6.3.3. RealNetworks Dès juillet 2002, cette société annonce une ouverture du code source de son serveur streaming multimédia (Helix DNA Server) puis de son lecteur multimédia (Helix DNA client) supportant tous les formats propriétaires et open source. Des liens en fin d'annexe 8.5.5. Il y a deux types de licences, comme dans le cas de Sun : - RealNetworks Public Source Licence (RPSL), soumise à la certification de OpenSouce.org, proche

de la GPL. Les travaux dérivés incluant du code modifié et du code indépendant doivent respecter la RPSL pour le premier, une licence open source compatible (liste donnée) pour le second. Cependant certaines parties de code sous RPSL sont brevetées.

- RealNetworks Community Source License (RCSL), proche de la BSD, divisée en six catégories. Elle présente des restrictions propriétaires au niveau des codecs (éléments de base définissant un format audio/vidéo).

L'usage de code sous RCSL dans des produits propriétaires est payant. L'argument principal avancé par RealNetworks est de ne plus avoir à supporter de coût de développement important pour ses produits, et de conquérir plus de parts de marché face à Microsoft.

5.6.4. Positionnement de Software AG

5.6.4.1. Niveau éditeur de logiciels Software AG a déjà des relations sur plusieurs plans avec l'open source : - logiciels propriétaires mais reposant sur des normes ouvertes (W3C) : une substitution de produits

est facilitée ; - mise en partage des sources de X-Application Framework via la Tamino Developper Community.

Ce composant permet à une variété d'interfaces web de se connecter à Tamino ; - compatibilité testée et usage encouragé de serveurs open source. La base de données Tamino peut fonctionner avec le serveur web Apache, le middleware EntireX avec le serveur d'application Tomcat… ; - partenariats permettant le support de systèmes d'exploitation open source (Linux), - portage de tous les nouveaux produits sous Linux.

Pour ma part, je verrais une possibilité de libération partielle du code de Bolero après 2005, puisque la maintenance ne sera plus assurée. Il convient de bien quantifier les dépendances avec des parties de code telles que le System Management Hub qu’il serait a priori moins judicieux commercialement d’open sourcer.


93

5.6.4.2. Niveau services Lorsque c'est possible, on peut favoriser l'utilisation de systèmes d'exploitation, serveurs, frameworks open source, dans les projets réalisés pour différents clients. Le coût global plus faible ainsi que la qualité de service reconnu de Software AG permettraient une plus grande compétitivité.

5.7. L'open source et le juriste Il convient de rappeler que toutes les licences open source s'inscrivent dans le cadre pénal légal, et donc toute action malveillante qui pourrait leur être liée tombe également sous le coup de la loi, dès lors qu'une responsabilité peut être déterminée, ce qui est le plus souvent le cas. Cette partie s'appuie sur quelques exemples significatifs, quelquefois à la frontière d'une action pénale.

5.7.1. Délivrer un logiciel open source, quelle responsabilité ?

5.7.1.1. Dommages et responsabilité Les dommages causés par un logiciel peuvent être de deux ordres :

- directs : perte ou corruption d'informations, avec coûts et temps liés à leur récupération ; - indirectes : perte de productivité, image de marque, coûts liés à trouver une solution

alternative… Le cabinet de consulting Giga Information Group estime que les licences open source, de part leurs termes, n'impliquent ni responsabilités spécifiques ni protection contre l’absence totale de responsabilités.

5.7.1.2. Validité de la licence Le problème de la validité du contrat de licence entre le distributeur et l'utilisateur se pose plus souvent dans le cas de l'open source comme celui-ci est en libre téléchargement. Dans ce cas, la disponibilité de la licence – le plus souvent en anglais quelle que soit la langue de l'utilisateur – sur le même site web n'est pas considéré comme suffisante. La généralisation en cours de la signature électronique doit résoudre ce problème.

5.7.1.3. Vente ou version gratuite - Cas des virus § La vente de logiciels open source (packages) obéit aux règles habituelles de protection du

consommateur, avec durée de garantie minimale incluant un droit de remboursement. § Un logiciel donné gratuitement n'implique la responsabilité du distributeur que lorsque celui-ci est

"vecteur de dommages par nature", par exemple lors de la contamination par un virus. § Le niveau de responsabilité dépend du "niveau de faute" : intentionnelle, négligence grave, simple

négligence, mise en danger involontaire.

5.7.1.4. Identification du distributeur et des législations s'appliquant Dans le cadre d'un téléchargement de logiciel produit coopérativement, seul le code source accompagné du copyright donne des informations pas toujours suffisantes. La nature du distributeur : agence de secteur public ou vendeur commercial, permet de déterminer les responsabilités afférentes. Les entreprises liées aux technologies de l'information sont supposées agir avec compétence et expérience, et sont donc plus exposées aux poursuites.


94

Les administrations ne peuvent licencier un logiciel que si celui-ci est fortement lié à leur rôle, cependant il est recommandé qu'elles ne licencent pas les utilisateurs finaux mais plutôt un premier niveau de licenciés : agence publique compétente, groupe de vendeurs open source, association. Toute licence doit par ailleurs spécifier : - la législation s'appliquant : dans le cadre européen, directives européennes et législation nationale

d'un état membre. Les termes doivent éviter les références aux lois américaine (USA) ou non européenne ;

- la cour de justice compétente, dans le cas européen située dans une ville d'un état membre. Elle peut ne pas appartenir au pays dont dépend la législation choisie ci-dessus.

5.7.2. Dissémination de secrets industriels ? C'est une accusation répandue de la part de sociétés éditant des logiciels propriétaires. En 1992, aux USA, Unix System Laboratories (USL) accuse Berkeley Software Design Inc. (BSDI) d'utiliser du code propriétaire USL dans son produit "Networking Release 2". Les arguments retenus par la Cour Fédérale furent que les notices de copyright ne contenaient pas les mentions appropriées, et qu'il y avait possibilité de pertes consécutives à la dissémination de secret industriel. Après passage devant la Cour d'Etat il y eu ajout de notices de copyright d'USL et suppression de quelques fichiers de la distribution.

5.7.3. Forcer l'adoption de standards En 1996 une querelle opposa AOL et Apache au sujet du protocole internet HTTP 1.1. AOL ne souhaitait en effet pas faire les efforts pour l'implémenter et faisait preuve de mauvaise foi dans le message d'erreur renvoyé aux utilisateurs de son navigateur propriétaire. Cette inertie technologique suivie de tentatives d'arrangements techniques de la part des serveurs Apache s'est finalement conclue par l'adoption amiable du nouveau standard par AOL, la perte en terme d'image et de revenus étant trop grande.

5.7.4. Les brevets : combat des titans Les brevets logiciels sont susceptibles de placer des algorithmes et fonctionnalités hors de portée du logiciel libre pendant une période qui peut atteindre vingt ans. C'est par exemple le brevet sur l'algorithme LZW de compression d'image au format GIF déposé en 1983 pour vingt ans par Unysis. De même le format musical MP3 est breveté depuis 1998. La Mozilla Public Licence prend en compte de façon plus explicite que les autres licences cette problématique pour le logiciel open source. Cependant en Europe le problème est moins aïgu qu'aux USA, les législations européennes restreignant l'usage du brevet sur le logiciel. En 2001 la Commission Européenne a renoncé, après pressions de nombreuses associations, la plupart associées au logiciel libre, à rapprocher ses positions de celles de Business Software Alliance (groupe de grands éditeurs de logiciels propriétaires). En novembre 2002 le W3C a repoussé la possibilité de déposer des brevets sur des standards liés à l'internet.


95

5.8. Conclusions Aujourd'hui, l'open source est un univers varié, en terme d'offres, de demandes, d'acteurs. Il est vecteur de schémas économiques profitables. § Les licences existantes couvrent l'ensemble des besoins et problématiques philosophiques et

commerciales tout en restant fidèles aux principes historiques ; § En 2002 le marché a une maturité certaine, impliquant de nombreux produits et acteurs dans la

chaîne de la valeur ajoutée. Il reste des terrains d'innovation et d'expansion ; § Le développeur open source est avant tout un pragmatique même si un certain idéalisme militant

demeure visible sur de nombreux sites internet ; § Même en ne respectant pas très bien le schéma classique du génie logiciel le produit fini libre

s'avère plus robuste que son équivalent propriétaire. Quant aux projets qui utilisent des logiciels open source, ils y gagnent en général plus que sur le seul plan financier ;

§ Des modèles économiques généralement complexes associent produits modifiés et services de haut niveau. Software AG peut y trouver une place ;

§ Il est en général – psychologiquement et en terme de réalisations – plus facile d'adopter l'open source en tant qu'outil de travail que changer de modèle économique ;

§ L'open source est un acteur juridique certain. Il doit s'intégrer dans le cadre existant, incite quelquefois à le préciser par de nouvelles législations. Un lobbyisme de la part d'associations du "monde libre" permet de protéger la liberté de la propriété intellectuelle face aux systèmes de brevets et pressions de grands éditeurs de logiciels propriétaires.


96

6. Conclusion générale J'ai atteint les objectifs que l'on m'avait fixés au début et au cours de mon stage. J'ai travaillé en autonomie, m'appuyant pour l'essentiel de mon travail sur : - mon organisation et ma motivation ; - les échanges avec d'autres utilisateurs de Cocoon ; - l'assistance limitée en temps mais précieuse en conséquences d'un collègue de Software AG ; - une collaboration efficace avec mon responsable directeur de projets.

J'ai trouvé enrichissant d'être également impliquée en parallèle dans un développement actuel du projet et de voir les technologies mises en œuvre dans le cadre B2B. Globalement j'ai : - amélioré mes compétences techniques ; - assumé des responsabilités décisionnelles ; - su communiquer avec mes collègues ; - eu la chance de jouer un rôle important au niveau de la maîtrise d'œuvre, suivant un projet

quasiment de bout en bout. Cependant la continuation du développement en équipe de ce que j'ai commencé seule, ainsi que la participation à la mise en exploitation, sortent du cadre de ma présence. Des facteurs décisionnels et budgétaires aussi bien que conjoncturels en sont responsables. Cela m'a donc laissé le temps en fin de stage de mener une étude aussi complète que possible sur l'open source, ce qui est important aussi bien pour la valeur intrinsèque de ce mémoire que pour les conclusions que peut en tirer Software AG / Software AG France en tant qu'éditeur de logiciels et fournisseur de services.


97

7. Glossaire § Adabas D : base de données hiérarchique de Software AG. § agrégation : action d'assembler. Dans le cas de Cocoon, le contenu de deux fichiers XML est

rassemblé en un seul. § Ant : élément logiciel open source permettant une compilation de projets (web applications…)

dans différents environnements : Windows, Unix, le fichier de configuration étant au format XML (simplicité de gestion).

§ APFA : Association pour la Promotion du Français des Affaires, recommandations de termes plus ou moins techniques francisés.

§ API : Application Programming Interface, ensemble d'éléments de code permettant de réaliser une fonction en masquant les éléments de bas niveau à l'utilisateur.

§ B2B : Business to Business, qualifie les échanges entre deux entreprises dans un cadre commercial, en opposition à Business to Consumer etc.

§ back-mapping : visualisation des liens logiques inverses de ceux définies par le programmeur etc. § BAE : Business Alliance Europe. Système basé sur un serveur d'application et permettant la

gestion des licences de Software AG. Désignation recommandée : License Key Application. § base de données relationnelle : base de données où l'information est stockée en tables,

l'information de tables différentes peut être liée par colonnes communes ou clés. § base de données XML : base de données où l'information est structurellement stockée au format

XML, les requêtes utilisent XPath/XQuery. La base de données peut être native XML (Tamino, Xindice, TextML…) ou bien être relationnelle avec couche logicielle XML (Oracle).

§ bean, EJB (Enterprise Java Bean) : objets java qui peuvent être persistants (stockages et récupérables par le mécanisme de sérialisation), dont les propriétés sont private et peuvent être manipulées par les méthodes get/set. Un EJB fait partie d'une application spécifique : un container.

§ bytecode : Exécutable multi plate-forme et pour une ou plusieurs machine virtuelle Java spécifiques, issu de la compilation de code source Java.

§ CIS : Corporate Information Service, département gérant l'informatique interne de Software AG. § code ISO : code édicté par l'ISO (International Organization for Standardization, www.iso.org). § cookie : petit fichier texte envoyé d'un serveur web au navigateur du client, et permettant de

stocker des informations concernant le client et récupérables par le serveur. § CSS : Cascading Style Sheet, document permettant de lier un style à un élément HTML. § CVS : Concurrent Version System, programme dont la partie serveur fonctionne sous Unix,

permettant à plusieurs développeurs de télécharger et sauvegarder le même code source. Un contrôle de versions est effectué. Voir annexe 9.7.1 pour plus de détails.

§ DLL : dynamic link library : collection de petits programmes pouvant être appelés par un exécutable.

§ DN (LDAP) : Distinguished Name, identifi ant unique d'un élément à un niveau hiérarchique donné dans un annuaire LDAP. Point de départ d'une recherche LDAP.

§ DOM : Document Object Model. API de programmation pour les documents HTML et XML et décrivant la manière d'accéder au document et de le manipuler. La structure logique des documents est représentée sous forme d'un arbre.

§ driver (en français : pilote) : programme interagissant avec un élément matériel ou logiciel précis. Le driver possède des informations que n'ont pas les programmes qui s'en servent pour accéder à l'élément qu'il pilote.

§ DTD : Document Type Definition, fichier décrivant la structure d'un document XML. § EAR ou .ear : Enterprise Application. Fichier à déployer sur un serveur d'application contenant un

fichier .war ainsi que des .jar et modules d'application client (déf. J2EE). § Edifrance : représentation des utilisateurs français de l'EDI auprès du CEFACT, organisme de

l'ONU qui normalise EDIFACT et bâtit le framework ebXML aux côtés de l'OASIS. § encodage : code définissant le jeu de caractères utilisés pour représenter des données. § extension java : classe java utilisée à partir d'une feuille de style XSL, Xalan étant le processeur

XSLT. Un namespace précis est utilisé : http://xml.apache.org/xslt/java. § formulaire (HTML, XML) : objet (page HTML par exemple) par lequel un client peut soumettre de

manière structurée des informations envers un serveur. § framework : cadre de développement. Ensemble d'outils permettant une structuration et

abstraction d'un système.


98

§ granularité : degré d'interactivité d'un programme, représenté par la quantité de points décisionnels qu'il comporte. Un programme interactif à granularité faible présente un réseau plus clairsemé de relations entre les nœuds, et moins de nœuds. (d'après le dictionnaire des arts médiatiques).

§ HTML : Hypertext Markup Language. Langage permettant le formatage visuel de données, communément utilisé sur internet. Version 4.01 de 1997.

§ IDE : Integrated Development Environment. En français : environnement (intégré) de développement.

§ J2EE : Java 2 Enterprise Edition. Standard pour les applications multi-tiers. § JAF : Java Activation Framework, API fonctionnant en association avec JavaMail. § JavaMail : API permettant la création, l'envoi et la réception d'emails par un programme Java. § javadoc : documentation spécifique à une API Java et présentée au format HTML. § JSP : Java Server Page. Fichier contenant du code HTML et Java, compilé par un serveur

d'application pour exécution sous forme de servlet. § LDAP : Lightweight Directory Access Protocol. Protocole permettant de localiser sur un réseau

internet ou intranet des personnes, organisations, ressources. § load-balancing : répartition de la charge d'exécution. § locale : ensemble de conventions de langages constitué à partir du langage/dialecte, territoire.

Elles incluent des informations sur la classification des caractères, la représentation temporelle (date et temps), numérique, monétaire…

§ log, logging : résultat physique et action de consigner des informations relatives à l'exécution d'un processus. Terme recommandé par l'APFA pour "log" : journal, historique.

§ mailing-list : liste de diffusion dans le cadre du courrier électronique. § maître d'œuvre : personne physique ou morale qui doit fournir un service à son client, alors appelé

maître d'ouvrage. Il réalise le développement, l'intégration, le chiffrage d'un projet. Il peut sous-traiter la réalisation du projet.

§ maître d'ouvrage : client (personne physique ou morale) auquel le maître d'œuvre doit fournir son service. Le maître d'ouvrage est à la fois initiateur et destinataire du projet. Il a trois responsabilités majeures : définition des objectifs et exigences du système, validation des solutions proposées et élaborées, préparation et pilotage du changement induit.

§ map : carte, plan. Dans le cadre de Cocoon, ensemble de paramètres de sitemap. § mapping : action de relier deux éléments par liaison logique. Terme recommandé par l'APFA :

mappage. § moteur de servlets : serveur permettant l'exécution de classes Java compilées côté serveur, en

opposition aux applets. La plupart des moteurs de servlets du marché ont des fonctionnalités supplémentaires, ce sont alors aussi des serveurs d'application,

§ MD5 (signature) : Message Digest 5. Algorithme de chiffrement créé par R. Rivest en 1992 et utilisé pour garantir l'intégrité des données.

§ namespace (XML) : collection de noms identifiés par une URI et utilisés dans des documents XML en tant que types d'éléments et noms d'attributs (déf. W3C).

§ native (méthode java) : fonction d'un programme réalisée dans un autre langage de programmation (par exemple C, C++).

§ OASIS : organisme qui aide au développement, à la convergence et à l'adoption de standards d'e-commerce.

§ parseur (anglais : parser) : programme recevant les données en entrée sous forme d'instructions séquentielles, de commandes interactives, de tags de markup (symboles spécifiques encadrant les données) et les sépare en éléments qui peuvent être traités par un autre programme. Il peut également vérifier que toutes les données nécessaires en entrée ont bien été fournies. Un parseur XML permet de parcourir un document XML et vérifier sa syntaxe. Il vérifie aussi la conformité à une DTD ou un schéma s'il y a validation. Ex. : Xerces, XP, Crimson, Expat (non validant)…

§ PDF : Portable Document Format. § plug, plug-in : élément logiciel que l'on adjoint à une application pour en étendre les fonctions.

Termes recommandés : module d'extension, extension (J.O. 1999). § processeur XSLT : élément logiciel permettant le processus de transformation d'un document

XML par une feuille de style XSL. Ex. : Xalan, Saxon, MSXML, XT, Sablotron, XSLTC… § requête HTTP : paramètres structurés envoyés par un client vers un serveur dans le cadre du

protocole HTTP. § SAGLIC : méthode de génération de clé de licence de Software AG basée sur un algorithme MD5.


99

§ SAP (R3) : logiciel ERP (Enterprise Resource Planning) permettant une gestion globale des données et processus.

§ SAX : Simple API for XML. Alternative à DOM pour interpréter un document XML. SAX est une interface event-driven : le programme spécifie un événement et s'il y a lieu une action est exécutée. SAX s'appuie directement sur un parseur XML.

§ schéma (Tamino) : basé sur un schéma XML, avec des informations supplémentaires spécifiques à la base de données d'où un namespace spécifique, tsd : http://namespaces.softwareag.com/tamino/TaminoSchemaDefinition.

§ schéma (XML) : en abrégé : WXS. Moyen de définir la structure, le contenu et la sémantique d'un document XML à l'aide de règles, ou fichier contenant ces informations. Plus complet que les DTDs. Spécifications publiées de 1999 à 2001. La version 1.1 en cours en octobre 2002. Namespace : xs : http://www.w3.org/2001/XMLSchema.

§ scriptlet : code Java dans une JSP. § serveur d'application : serveur au sein d'un réseau distribué, gérant : session client, charge et

reprise sur incident, accès à diverses sources de données. Intègre différents éléments : moteur de servlets (le serveur assure en plus la compilation), moteur d'EJB, serveur JNDI… La plupart des serveurs d'application du marché respectent le standard J2EE.

§ serveur web : serveur utilisant le protocole HTTP et le modèle client/serveur. § servlet : petit programme (souvent codé en Java) s'exécutant sur un serveur, dans le cadre de

l'échange client-serveur. § session (HTTP) : série d'interactions avec données persistantes du client, caractérisée par un

début et une fin. § SOAP : Simple Object Access Protocol. Protocole léger d'échange de données en environnement

décentralisé, basé sur XML. Version 1.1 de mai 2000. § SSL : Secure Sockets Layer, protocole permettant la sécurisation de messages sur l'internet.

Version 3.0 de1996. § template (XSL) : règle de transformation applicable à un élément donné. (signification générale :

moule, modèle). § UID (LDAP) : User Identification Code. § URI, URL, URN :

- Uniform Resource Identifier : syntaxe générale des chaînes texte URL, URN… (RFC 2396); - Uniform Resource Locator : adresse accessible via HTTP (RFC 1738); - Uniform Resource Name : identifiant, nom unique d'une ressource (RFC 2141).

§ VAR : Value Added Reseller. Distributeur (ou revendeur) à valeur ajoutée. Personne ou organisme qui ajoute quelque chose à un produit informatique pour le revendre sous sa propre raison sociale. (déf. Grand Dictionnaire Terminologique québécois).

§ W3C : Word Wide Web Consortium. Organisme qui émet des recommandations (non membre de l'ISO). Il vise à promouvoir des technologies interopérables standards (spécifications, lignes de conduite, logiciels, outils). Le W3C est un forum d'information, d'échanges et de discussions. Il est constitué de groupes de travail (Working Groups) et émet des documents : Working Drafts.

§ WAR ou .war : Web Archive. Fichier compressé à déployer sur un serveur d'application et contenant les éléments nécessaires au fonctionnement d'une web application dans un environnement ou un autre sans modification nécessaire. Les éléments qu'il peut contenir suivant le standard J2EE sont : servlets, JSP, classes et bibliothèques java, documents statiques tels que pages HTML, fichiers images et sons, et éléments à exécuter côté client : applets, beans, classes.

§ web application, webapp : application logicielle accessible par un client HTTP, et consistant typiquement en : client léger (navigateur), partie présentation (serveur web), partie application (serveur d'application), partie base de données. Les trois derniers éléments peuvent être multiples et répartis au sein du réseau.

§ web services : façon de présenter et d'utiliser des processus métiers qui peuvent être découverts et exécutés à travers les réseaux inter/intra/extranet, en utilisant des technologies standards d'internet.

§ WSDL : Web Service Descriptor Language. Langage au format XML décrivant les services en réseau en tant qu'entités opérant sur des messages dont l'information est orientée documents ou procédures. Version 1.1 de mars 2001.

§ XForms : standard basé sur XML et permettant de séparer la logique de la présentation d'un formulaire. Les données entrées sont récupérées au format XML (protocole XForms Submit Protocol). Version 1.0 (Working Draft) d'août 2002.

§ XML : Extensible Markup Language. Format de texte utilisant des balises, dérivé de SGML (ISO 8879). Version 1.0 seconde édition d'octobre 2000, release candidate 1.1 d' octobre 2002.


100

§ XML Forms : extension de formulaires propre à Cocoon 2.1 et inspirée de Struts et du standard XForms. Ceci permet un mapping entre le formulaire, les données au format XML et les beans java.

§ XPath : langage d'accès à des parties d'un document XML, résultant de la recherche d'une syntaxe commune pour les fonctionnalités partagées par XSLT et XP ointer. Version 1.0 de novembre 1999, version 2.0 (Working Draft) d'août 2002 (très proche de XQuery 1.0).

§ XSL(T) : Extensible Stylesheet Language (Transformation). XSLT est un langage permettant de transformer un document XML en un autre, XSL inclut de plus un vocabulaire pour spécifier la sémantique du formatage. Version 1.0 de novembre 1999.

§ XSP : Extensible Server Page. Technologie permettant l'inclusion de code exécutable par un serveur (Perl, Java…) dans un document XML. Ceci utilise du code imbriqué, des bibliothèques de tags extensibles (taglibs), des techniques de transformation. XSP a été originellement inventé par le projet Cocoon

§ X-Query : langage de requêtes vers une base de données Tamino (version 2 ou 3). S'appuie sur XPath 1.0.

§ XQuery : langage permettant d'effectuer des requêtes sur un document XML. Version 1.0 (Working Draft) d'août 2002. Très proche de XPath 2.0.


101

8. Bibliographie

8.1. Standards et technologies § JSP vs. XSL : http://softwaredev.earthweb.com/java/article/0,,12082_1380771_3,00.html § XForms : http://www.w3.org/MarkUp/Forms/ § XML Schema : http://www.w3.org/XML/Schema § Sites généraux sur XML : www.xml.com , www.xmlfr.org, www.zvon.org (tutoriels), www.w3.org (site du W3C). § DOM, introduction : http://www.w3.org/TR/WD-DOM/introduction.html § URI, URL et URN : http://www.arbortext.com/Think_Tank/XML_Resources/Issue_Three/issue_three.html

8.2. Frameworks et modèle MVC

8.2.1. Définitions, concepts généraux § Définition d'un framework : http://www.imakenews.com/fourthgen/e_article000040041.cfm

8.2.2. Java et MVC § Java et modèle MVC : http://www.computerheadline.com/TecSect/June2001/java.asp § Modèle HMVC (au niveau de l'interface utilisateur) : http://www.javaworld.com/javaworld/jw-07-2000/jw-0721-hmvc.html § Validation de formulaire avec Controller : http://www.sas.com/rnd/appdev/webAF/server/examples/formvalidation.htm

8.2.3. Frameworks MVC § Liste de frameworks MVC open source ou non : http://barracuda.enhydra.org/cvs_source/Barracuda/docs/landscape.html#Barracuda_Competitors § Discussion Cocoon – Enhydra : http://enhydra.enhydra.org/project/mailingLists/enhydra/200205/msg00093.html § Tapestry : http://tapestry.sourceforge.net/, http://www.onjava.com/pub/a/onjava/2001/11/21/tapestry.html § Struts et Tapestry : http://www.application-servers.com/articles/opensourcejava/

8.3. Struts

8.3.1. Site officiel et mailing-list § http://jakarta.apache.org/struts § struts [email protected]

8.3.2. Sites utiles pour la programmation § Description UML du framework. Site découvert en fin de mon étude, comme j'ai plutôt cherché à comprendre

par moi-même en priorité : http://rollerjm.free.fr/pro/Struts.html § Présentation du framework : http://www-106.ibm.com/developerworks/library/j-struts/?dwzone=java


102

§ Struts Validator : http://home.earthlink.net/~dwinterfeldt/overview.html § Site de Ted Husted, développeur Struts :

http://husted.com/struts § Java Guru : question sur les ActionForms :

http://www.jguru.com/faq/view.jsp?EID=827787 § Devx.com, « Struts, a solid web-app framework » : http://www.devx.com/premier/mgznarch/javapro/2002/04apr02/th0402/th0402-1.asp (lien devenu payant depuis consultation mais version imprimée sauvegardée) § Exemple d'usage des nested tags : http://www.keyboardmonkey.com/next/index.jsp § Whitepaper : http://stealthis.athensgroup.com/presentations/Model_Layer_Framework/Struts_Whitepaper.pdf § Extension de Struts avec XSLT : http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html § Extension par Adam Grohs permettant une validation côté serveur puis client (voir annexe 8.2.3.) : http://www.mail-archive.com/[email protected]/msg16093.html

8.4. Cocoon

8.4.1. Site officiel et mailing-lists § http://xml.apache.org/cocoon § Utilisateurs et archives utilisateurs : [email protected], http://www.mail-archive.com/[email protected]/ § Développeurs et archive développeurs : [email protected], http://www.mail-archive.com/[email protected]/, http://marc.theaimsgroup.com/?l=xml-cocoon-dev&r=1&w=2

8.4.2. Sites utiles pour la programmation § Cocoon Center : www.cocooncenter.de § Cocoon Wiki : http://outerthought.net/wiki/Wiki.jsp § Présentation de Cocoon 2 : http://www.info.unicaen.fr/~turbout/CNFPT/Cours.Cocoon2.pdf

8.4.3. Sunrise Portal / Sunrise Components / Cocoon authentication framework § Principe et donation au projet Cocoon en janvier 2002 : http://www.xml.com/pub/a/2002/07/24/xmlportal.html § Documentation et exemple : http://radio.weblogs.com/0103021/stories/2002/02/28/usingTheSunriseComponents.html § Propositions de modifications de structure dans la version 2.1-dev de Cocoon : http://www.mail-archive.com/[email protected]/msg13341.html § Intégration totale à Cocoon dans la version 2.1 (CVS) : nouvel usage (syntaxe) : http://xml.apache.org/cocoon/developing/webapps/authentication.html

8.5. Open source

8.5.1. Organismes de référence § Informations officielles et mailing-list associée (version archivée) : http://www.opensource.org, http://www.mail-archive.com/[email protected] www.fsf.org § Hébergement de nombreux projets : www.sourceforge.net


103

§ ADULLACT (Association des Développeurs et des Utilisateurs de Logiciels Libres pour les Administrations et les Collectivités Territoriales) :

http://www.adullact.org

8.5.2. Quelques projets § JetSpeed, système de portail : http://jakarta.apache.org/jetspeed/site/index.html § Avalon (Cocoon en est une application) : http://jakarta.apache.org/avalon/, et en particulier notion intéressante d'inversion du contrôle : http://jakarta.apache.org/avalon/framework/guide-patterns -ioc.html § Portail de gestion documentaire basé sur Lucene, SDX, par le ministère de la Culture : http://sdx.culture.fr/sdx/ § Lutèce, portail open source de la ville de Paris : http://www.lutece.paris.fr/en/jsp/site/Portal.jsp?article_id=1&portlet_id=47

8.5.3. Données chiffrées et études officielles § Usage de l'open source dans l'administration européenne (2001) : http://europa.eu.int/ISPO/ida/jsps/index.jsp?fuseAction=showChapter&chapterID=134&preChapterID=0-17 et résumé : http://www.atica.pm.gouv.fr/pages/documents/fiche.php?id=1185&id_chapitre=8&id_theme=55&letype=0 § Sondage DSIs du réseau InfoWorld, en 2001 : http://www.infoworld.com/articles/tc/xml/01/08/27/010827tcintro.xml § Free/Libre and Open Source Software : survey and study, juin 2002 : http://www.infonomics.nl/FLOSS/report/ et http://www.berlecon.de/studien/floss/FLOSS_Einsatz.pdf, http://www.berlecon.de/studien/floss/FLOSS_Grundlagen.pdf § Statistiques, usage et fiabilité de systèmes d'exploitation open source : http://www.dwheeler.com/oss_fs_why.html

8.5.4. Eléments juridiques § Proposition de loi, Sénat, 28 octobre 2002 : http://www.adullact.org/breve.php3?id_breve=16 § Messages d'élus français en juin 2002 contre la brevetabilité de logiciels en UE : http://europa.eu.int/comm/internal_market/en/indprop/comp/appendix17.pdf § L'Europe et les brevets logiciels, article de février 2002 : http://www.toolinux.com/lininfo/news/news/news20020220002151.htm § Le W3C contre les brevets : http://www.01net.com/rdn?oid=197709&thm=UNDEFINED

8.5.5. Autres informations § "Tribune libre, ténors de l'informatique libre", adaptation française conduite par O'Reilly, de "Open Sources:

Voices of the Open Source Revolution", ouvrage collectif sous la responsabilité de Richard Stallman, publié en 1999 par O'Reilly & Associates. Version en ligne :

http://www.oreilly.fr/divers/tribune-libre/index.html et version originale américaine en ligne : http://www.oreilly.com/catalog/opensources/book/toc.html § Bref historique de l'open source : http://eu.conecta.it/paper/brief_history_open_source.html § Les distributeurs Linux, vue d'ensemble et stratégie : http://www-1.ibm.com/partnerworld/pwhome.nsf/vAssetsLookup/LunchnLearn0619.pdf/$File/LunchnLearn0619.pdf § Solutions open source java dans le cadre d'une application web : http://www.application-servers.com/articles/opensourcejava/ § Bénéfices apportés par l'usage de l'open source : http://ebusiness.gbdirect.co.uk/OpenSourceMigration/benefit.html § Comment gagner sa vie avec l'open source : http://www-106.ibm.com/developerworks/linux/library/license.html?dwzone=linux § License SISSL 1.2 : http://wbemservices.sourceforge.net/sissl_1-2.html


104

§ Les logiciels libres, un modèle économique viable ? http://www.jcheritier.net/memoire § Real Networks, open sourçage du serveur multimédia Helix : http://www.01net.com/rdn?oid=189964 http://news.zdnet.fr/story/0,,t118-s2119942,00.html http://www.01net.com/rdn?oid=196640&thm=UNDEFINED www.helixcommunity.org § Yahoo se tourne vers le PHP : http://solutions.journaldunet.com/0211/021104_yahoo.shtml § Tableau de quelques solutions open source et propriétaires (page 6) : http://www.synaptique.com/download/opensource.pdf

8.6. Software AG § EntireX XML Mediator : http://www.softwareag.com/entireX/products/mediator.htm , http://www.softwareag.com/entireX/download/download_mediator.htm. § Forums Tamino : http://forums.tamino.com § Section publique de Tamino Developper Community : http://developer.softwareag.com/tamino § X-Application (sources partagées) : http://developer.softwareag.com/tamino/x-application/default.htm § Section intranet : Tamino Community Intranet Portal : http://taco.software-ag.de

8.7. Outils de développement / production

8.7.1. Développement / compilation java

8.7.1.1. Informations générales et intégration § JBuilder, de Borland : www.borland.com/jbuilder § Outils open source pour JBuilder : http://codecentral.borland.com/codecentral/ccweb.exe/prodcat?prodid=3&catid=11, en particulier : intégration de JBuilder et JAD : http://www.softamis.com/ie/ot/jad/highlight.html, http://www.softamis.com/ie/ot/jad/download.html, § Sun One Studio (anciennement Forté for Java), de Sun : http://www.sun.com/forte/ffj/ § Eclipse : www.eclipse.org § IDEA, d'IntelliJ : http://www.intellij.com/idea/ § VisualAge for Java, d'IBM : http://www-3.ibm.com/software/ad/vajava/ § VisualCafe, de WebGain : http://www.webgain.com/products/visual_cafe/ § Visual J++ / J#, de Microsoft : http://msdn.microsoft.com/vjsharp/ § Ant (compilateur avec fichier de configuration au format XML) : http://jakarta.apache.org/ant § Intégration avec Eclipse : http://dev.eclipse.org/newslists/news.eclipse.tools/msg15316.html (page protégé par mot de passe).

8.7.1.2. Comparaisons § Forté et JBuilder : http://c2.com/cgi/wiki?ForteForJava


105

8.7.1.3. Matrices de fonctionnalités § JBuilder 7 : http://www.borland.com/jbuilder/pdf/jb7_feamatrix.pdf § Sun One Studio 4 : http://wwws.sun.com/software/sundev/jde/editioncomp.html § VisualCafe 4.5.2 : http://www.webgain.com/products/visual_cafe/enterprise_edition/feature_matrix.html

8.7.2. Edition / transformation XSLT § Stylus Studio, de eXcelon Corporation : http://www.exln.com/products/stylusstudio/ § XML Spy, de Altova : www.xmlspy.com, matrice des fonctionnalités : http://www.xmlspy.com/matrix.html § XML CookTop (gratuit, Windows) : http://xmlcooktop.com , critique : http://www.nwfusion.com/newsletters/web/2002/01284834.html

8.7.3. Moteurs de servlets / serveurs d'application

8.7.3.1. Informations générales § JBoss (open source) : http://www.jboss.org/ § Tomcat, d'Apache : http://jakarta.apache.org/tomcat et liste de discussion archivée : http://www.mail-archive.com/[email protected] § JRun, de Macromedia : www.macromedia.com/jrun § WebLogic, de BEA : http://www.bea.com/products/weblogic/server/index.shtml § WebSphere, d'IBM: www.ibm.com/websphere

8.7.3.2. Comparaisons § JBoss peut-il battre BEA : http://www.theserverside.com/reviews/thread.jsp?thread_id=2918

8.7.4. Accès à CVS § WinCVS : http://www.wincvs.org/. Il existe aussi des versions Unix et Macintosh. § Fonctionnement de CVS : http://searchvb.techtarget.com/sDefinition/0,,sid8_gci211874,00.html et FAQ : http://www.cs.utah.edu/csinfo/texinfo/cvs/FAQ.txt

8.7.5. Forums § Forum Java Sun : http://forums.java.sun.com/ § Forums JBuilder : http://newsgroups.borland.com/cgi-bin/dnewsweb?cmd=listall&group=borland.public.jbuilder.&utag= § Forums JRun : http://webforums.macromedia.com/jrun/ § Forums Eclipse : http://www.eclipse.org/mail/index.html, http://www.eclipse.org/newsgroups/index.html


106

8.8. Outils de statistiques § Usage de différents serveurs web : http://www.netcraft.com/survey § Utilisateurs de Linux (estimation) : http://counter.li.org/

8.9. Divers § Nombreuses informations, outils de recherche : http://solutions.journaldunet.com , www.jguru.com , http://whatis.techtarget.com/ § Sites promouvant l'usage de termes francisés, entre autres techniques et des affaires : http://www.presse-francophone.org/apfa/index.html, www.granddictionnaire.com

107

9. Annexes

9.1. Autres frameworks Quelques autres frameworks dont l'utilisation est assez répandue mais moins que Struts et Cocoon, méritent qu'on y porte attention : - Turbine, d'Apache, similaire par certains points à Struts, est un framework riche en fonctionnalités,

permettant de construire des webapps sécurisées utilisant le modèle de servlets, et pouvant s'intégrer facilement à d'autres projets tels que Cocoon, Velocity… Ce frameworks est utilisable à la place de Struts si on ne veut pas utiliser largement les JSPs.

- Expresso, semblable à Turbine et pouvant s'intégrer avec Struts, - Tapestry, alternative aux JSPs, taglibs permettant de générer du code javascript, scripting propre, - Sitemesh, Maverick, orientés documents.

9.2. Struts

9.2.1. Exemple de fichier struts-config.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE struts-config PUBLIC <struts-config>  <data-sources/>  <form-beans type="org.apache.struts.action.ActionFormBean"> <form-bean name="authenticationForm" type="baepp.AuthenticationForm" /> </form-beans>  <global-forwards type="org.apache.struts.action.ActionForward"> <forward name="logoff" path="/logoff" /> <forward name="authentication" path="/authentication" /> <forward name="menu" path="/menu" /> </global-forwards>  <action-mappings type="org.apache.struts.action.ActionMapping">  <action path="/authentication" type="baepp.AuthenticationAction" name="authenticationForm" scope="request" validate="true" input="/authentication.JSP"> <forward name="menu" path="/menu.JSP" /> <forward name="error" path="/error.JSP" /> </action> </action-mappings>  <controller locale="true"> </controller>  <message-resources parameter="ApplicationResources" null="true" /> </struts-config>


108

9.2.2. Validation côté serveur et client de formulaire

9.2.2.1. Description et fonctionnement Adam Grohs a proposé (http://www.mail-archive.com/[email protected]/msg16093.html) une extension permettant, au lieu d'écrire du code HTML par le tag <html:errors />, d'écrire des fonctions javascript. Lors de la soumission du formulaire, en cas d'erreur, du code javascript est inséré dans la JSP (validation côté serveur), puis les soumissions suivantes, en cas d'erreur, utilisent une validation côté client par ledit javascript, autant de fois que nécessaire et avec remise à zéro d'un objet collecteur d'erreurs. Les composants supplémentaires sont : - un handler, par exemple error_lib.js, contenant les définitions de fonctions principales

throwError(…) et collectErrors(). L'objet collecteur d'erreurs lors de chaque soumission est géré à ce niveau,

- un script javascript dans un fichier .js (un par JSP/formulaire à contrôler), contenant les appels à une fonction javascript pour chaque champ à contrôler (check…()), ainsi que l'appel à validate() (soumission du formulaire),

- une page JSP (une par JSP/formulaire à contrôler et incluse dans celle-ci dans le head), contenant le code spécifique de la fonction associée à un champ (check…()) qui récupère dans le fichier ApplicationResources.properties le bon message. Ce message est un throwError(…) avec des paramètres spécifiques.

9.2.2.2. Avantages Il n'y a qu'un seul appel au serveur pour la validation d'un formulaire, ce qui réduit la charge. Ce principe est complémentaire de Struts Validator. Différents types de réponse (boîte d'alerte, message en rouge, insertion d'image…) sont possibles, mais en n'ayant pas de HTML à coder dans ApplicationResources.properties.

9.2.2.3. Inconvénients Il y a un bug à régler avec la méthode javascript document.write() qui n'écrit pas sur la JSP mais ouvre une nouvelle page, ce qui est logique puisque cette méthode s'exécute côté client alors que la JSP est compilée côté serveur, je n'ai pas réussi à faire fonctionner cette extension.

9.2.3. Extension XSLT XSL Servlet permet de générer un document XML à partir des beans de présentation, requête http, beans de session, puis d'appliquer une feuille de style XSLT. Il crée pour cela un DOM tree (arbre représentant le document), mais cette solution est consommatrice de ressources (dû au fonctionnement de DOM). Pour plus d'informations : http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt-p2.html http://www.javaworld.com/javaworld/jw-02-2002/strutsxslt/jw-0201-strutsxslt.zip

109

Schéma de fonctionnement :

9.3. Cocoon

9.3.1. Sitemap du développement réalisé La plupart des éléments semblables à ceux du sitemap initial de Cocoon (CVS HEAD du 2 octobre 2002) sont supprimés (commentaire entre crochets) pour plus de lisibilité. Les éléments présentés sont donc essentiellement ceux ajoutés. On ne présente que le sitemap principal. Le sitemap secondaire (appel par cocoon://ino/…) contient les requêtes Tamino écrites en XQL. <?xml version="1.0" encoding="UTF-8"?> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">  <map:components>

<map:generators default="file"> 

</map:generators>  <map:transformers default="xslt">   <map:transformer logger="sitemap.transformer.SimpleForm" name="simple-form" src="org.apache.cocoon.transformation.SimpleFormTransformer"/>  <map:transformer name="xmldb" src="org.apache.cocoon.transformation.XMLDBTransformer"> <driver>com.softwareag.tamino.xmldb.api.base.TDatabase</driver>  <base>xmldb:tamino://i3in0/tamino/BAEPP/BAEPP</base> </map:transformer> </map:transformers>  <map:readers default="resource">  </map:readers>   <map:serializers default="html"> <map:serializer logger="sitemap.serializer.links" name="links" src="org.apache.cocoon.serialization.LinkSerializer"/> <map:serializer logger="sitemap.serializer.xml" mime-type="text/xml" name="xml" src="org.apache.cocoon.serialization.XMLSerializer">

110

<encoding>iso-8859-1</encoding> </map:serializer> <map:serializer logger="sitemap.serializer.html" mime-type="text/html" name="html" pool-grow="4" pool-max="32" pool-min="4" src="org.apache.cocoon.serialization.HTMLSerializer"> <buffer-size>1024</buffer-size> <encoding>iso-8859-1</encoding> </map:serializer>  </map:serializers>  <map:matchers default="wildcard">  </map:matchers>  <map:selectors default="browser">  </map:selectors>  <map:actions>   <map:action logger="sitemap.action.genlickey" name="genlickey" src="baepp.licensekey.GenLicKey"/> <map:action logger="sitemap.action.xmldocexists" name="xmldocexists" src="baepp.tamino.XMLDocumentExistsAction"/> <map:action logger="sitemap.action.mailer" name="sendmail" src="baepp.MailerAction">   </map:action> </map:actions>  <map:pipelines default="caching">  </map:pipelines> </map:components> 

<map:views> </map:views>  <map:resources> </map:resources>  <map:action-sets> </map:action-sets>  <map:pipelines> <map:global-parameters>  <map:parameter name="taminoserver" value="i3in0"/> <map:parameter name="taminodatabase" value="BAEPP"/> <map:parameter name="taminocollection" value="BAEPP"/> <map:parameter name="cocoonport" value="9090"/> <map:parameter name="hostbase" value="baepp"/>

111

<map:parameter name="adminemailfrom" value="[email protected]"/> <map:parameter name="adminemailto" value="[email protected]"/> <map:parameter name="smtp" value="10.41.20.3"/> </map:global-parameters> <map:component-configurations>  <authentication-manager> <handlers> <handler name="baepphandler"> <redirect-to uri="cocoon://login"/>    <authentication uri="cocoon:raw://baepp-auth"/> </handler> </handlers> </authentication-manager> </map:component-configurations> <map:pipeline internal-only="true">   <map:match pattern="deletedoc/*">

<map:generate src="cocoon://ino/{1}"/> <map:transform src="xsl/deletedoc.xsl"/> <map:transform type="xmldb"/> <map:serialize type="xml"/> </map:match>  <map:match pattern="getxml"> <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/> <map:generate src="xml/getxml.xml"/> <map:transform type="session"/> <map:serialize type="xml"/> </map:act> </map:match> <map:match pattern="getcheckedplugs"> <map:generate type="request"/> <map:transform src="xsl/checkedplugs.xsl"/> <map:serialize type="xml"/> </map:match>  <map:match pattern="httprequest"> <map:generate type="request"/> <map:transform src="xsl/copy.xsl"/>  <map:serialize type="xml"/> </map:match>  <map:match pattern="getdescriptor/*"> <map:generate src="cocoon://ino/template/{1}"/> <map:transform src="xsl/formvaldesc_genlickey.xsl"/> <map:serialize type="xml"/> </map:match>  </map:pipeline>  <map:pipeline>  <map:match pattern="tamino/**"> <map:generate src="cocoon://ino/{1}"/> <map:serialize type="xml"/> </map:match> </map:pipeline> <map:pipeline>  <map:match pattern="mlform">

112

<map:generate src="xml/mlForm.xml"/> <map:transform src="xsl/copy.xsl"/> <map:serialize type="xml"/> </map:match>   <map:match pattern="login"> <map:generate src="xml/login.xml"/> <map:transform src="xsl/login.xsl"/> <map:transform type="encodeURL"/> <map:serialize type="html"/> </map:match>  <map:match pattern="dologin"> <map:act type="request">  <map:parameter name="parameters" value="true"/> <map:act type="auth-login"> <map:parameter name="handler" value="baepphandler"/> <map:parameter name="parameter_company" value="{request-param:company}"/> <map:parameter name="parameter_username" value="{request-param:username}"/> <map:parameter name="parameter_password" value="{request-param:password}"/> <map:parameter name="parameter_lang" value="{request-param:lang}"/> <map:redirect-to uri="menu"/> </map:act>  <map:aggregate element="page"> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="error" src="cocoon://ino/error/310001/{lang}"/> </map:aggregate> <map:transform src="xsl/error.xsl"> <map:parameter name="lang" value="{lang}"/> </map:transform> <map:serialize type="html"/> </map:act> </map:match>  <map:match pattern="baepp-auth">  <map:generate src="xml/user.xml"/> <map:transform src="xsl/user.xsl"> <map:parameter name="use-request-parameters" value="true"/> </map:transform>  <map:transform type="session"/>   <map:serialize type="xml"/> </map:match>  <map:match pattern="menu"> <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/> <map:aggregate element="page">  <map:part element="mlmenu" src="cocoon://ino/mlMenu"/> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> <map:transform type="session"/> <map:transform src="xsl/menu_rights_1.xsl"/> <map:transform src="xsl/menu_rights_2.xsl"/> <map:transform src="xsl/menu_rights_3.xsl"/> <map:transform src="xsl/menu_main.xsl"/> <map:serialize type="html"/> </map:act> </map:match>

113

 <map:match pattern="defaultgeneration"> <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/> <map:aggregate element="page"> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="products" src="cocoon://ino/products"/> <map:part element="platforms" src="cocoon://ino/platforms"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> <map:transform type="session"/> <map:transform src="xsl/familiesandplatforms.xsl"> <map:parameter name="free" value="0"/>  </map:transform> <map:serialize type="html"/> </map:act> </map:match>  <map:match pattern="defaultgen">  <map:act type="request"> <map:parameter name="parameters" value="true"/>  <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/>  <map:select type="request-parameter"> <map:parameter name="parameter-name" value="platform"/>  <map:when test="All"> <map:select type="request-parameter"> <map:parameter name="parameter-name" value="family"/>  <map:when test="All"> <map:aggregate element="page"> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="lickeymat" src="cocoon://ino/all_families_platforms"/> <map:part element="licenseset" src="cocoon://ino/LicenseSet"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate>  </map:when>  <map:otherwise> <map:aggregate element="page"> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="lickeymat" src="cocoon://ino/all_platforms_a_family/{../family}"/> <map:part element="licenseset" src="cocoon://ino/LicenseSet"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> </map:otherwise>  </map:select>  </map:when>

114

 <map:otherwise> <map:select type="request-parameter"> <map:parameter name="parameter-name" value="family"/>  <map:when test="All"> <map:aggregate element="page"> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="lickeymat" src="cocoon://ino/all_families_a_platform/{../platform}"/> <map:part element="licenseset" src="cocoon://ino/LicenseSet"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate>  </map:when>  <map:otherwise> <map:aggregate element="page"> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="lickeymat" src="cocoon://ino/a_family_a_platform/{../family}/{../platform}"/> <map:part element="licenseset" src="cocoon://ino/LicenseSet"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> </map:otherwise>  </map:select> </map:otherwise> </map:select> <map:transform type="session"/>  <map:transform src="xsl/lkgproductcatalog.xsl"> <map:parameter name="free" value="0"/> <map:parameter name="xnodeupgrade" value=""/> </map:transform> <map:serialize type="html"/> </map:act>  </map:act> </map:match>  <map:match pattern="defaultgenerationcheckplug"> <map:act type="request"> <map:parameter name="parameters" value="true"/>  <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/> <map:act type="xmldocexists"> <map:parameter name="taminoUri" value="http://{baepp:taminoserver}/tamino/{baepp:taminodatabase}/{baepp:taminocollection}"/> <map:parameter name="query" value="Template[@Id='{../template}']"/>  <map:act type="xmldocexists"> <map:parameter name="taminoUri" value="http://{baepp:taminoserver}/tamino/{baepp:taminodatabase}/{baepp:taminocollection}"/> <map:parameter name="query" value="Plugging[@product='{../../licKeyMat}' and @version='{../../version}']/Pluggs/Plug"/> <map:aggregate element="page"> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="plugging" src="cocoon://ino/plugging/{../../../licKeyMat}/{../../../version}"/>

115

<map:part element="plug" src="cocoon://ino/Plug"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> <map:transform type="session"/> <map:transform src="xsl/genliccheckplug.xsl"> <map:parameter name="use-request-parameters" value="true"/> </map:transform> <map:serialize type="html"/> </map:act>  <map:redirect-to uri="defaultgenerationform2fill?licKeyMat={../../licKeyMat}&template={../../template}&free={../../free}&platform={../../platform}&version={../../version}&xnodeupgrade={../../xnodeupgrade}&readMode=0"/> </map:act>  <map:redirect-to uri="error?code=421001"/> </map:act> </map:act> </map:match>   <map:match pattern="defaultgenerationform2fill">   <map:act type="request"> <map:parameter name="parameters" value="true"/>  <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/>  <map:act type="request-exists"> <map:parameter name="parameters" value="submittedOnce"/>  <map:act type="form-validator"> <map:parameter name="descriptor" value="cocoon://getdescriptor/{../../template}"/> <map:parameter name="validate-set" value="default"/>  <map:act type="genlickey"> <map:parameter name="taminoUri" value="http://{baepp:taminoserver}/tamino/{baepp:taminodatabase}/{baepp:taminocollection}"/> <map:aggregate element="page"> <map:part element="template" src="cocoon://ino/template/{../../../../template}"/> <map:part element="reqparam" src="cocoon://httprequest"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> <map:transform type="session"/>  <map:transform src="xsl/genlickey.xsl"> <map:parameter name="use-request-parameters" value="true"/>

116

<map:parameter name="serialNumber" value="{serialNumber}"/> <map:parameter name="timeStamp" value="{timeStamp}"/> <map:parameter name="dateLicense" value="{dateLicense}"/> <map:parameter name="error" value="{error}"/> </map:transform>  <map:transform src="xsl/MD5.xsl"/>  <map:transform src="xsl/insertandkeep.xsl"/> <map:transform type="xmldb"/>  <map:transform src="xsl/addsessioninfo.xsl"/> <map:transform type="session"/>  <map:transform src="xsl/dbresp.xsl"> <map:parameter name="taminoUri" value="http://{baepp:taminoserver}/tamino/{baepp:taminodatabase}/{baepp:taminocollection}"/> <map:parameter name="adminemailfrom" value="{baepp:adminemailfrom}"/> <map:parameter name="adminemailto" value="{baepp:adminemailto}"/> <map:parameter name="server" value="{baepp:taminoserver}"/> <map:parameter name="smtp" value="10.41.20.3"/> </map:transform> <map:serialize type="html"/> </map:act>  <map:redirect-to uri="error?code=422003"/> </map:act>  <map:aggregate element="page"> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="template" src="cocoon://ino/template/{../../template}"/> <map:part element="lickeymat" src="cocoon://ino/lickeymat/{../../licKeyMat}/{../../version}"/> <map:part element="plugging" src="cocoon://ino/{../../licKeyMat}/{../../version}"/> <map:part element="checked" src="cocoon://getcheckedplugs"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> <map:transform type="session"/>  <map:transform src="xsl/genlicform2fill.xsl"> <map:parameter name="use-request-parameters" value="true"/> </map:transform>  <map:transform type="simple-form"/> <map:serialize type="html"/> </map:act>  <map:aggregate element="page"> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="template" src="cocoon://ino/template/{../template}"/>

117

<map:part element="lickeymat" src="cocoon://ino/lickeymat/{../licKeyMat}/{../version}"/> <map:part element="plugging" src="cocoon://ino/{../licKeyMat}/{../version}"/> <map:part element="checked" src="cocoon://getcheckedplugs"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> <map:transform type="session"/>  <map:transform src="xsl/genlicform2fill.xsl"> <map:parameter name="use-request-parameters" value="true"/> </map:transform> <map:transform type="simple-form"/> <map:serialize type="html"/> </map:act> </map:act> </map:match>  <map:match pattern="showlicense"> <map:act type="request"> <map:parameter name="parameters" value="true"/>  <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/> <map:aggregate element="page"> <map:part element="license" src="cocoon://ino/licenseinfo/{../serialNumber}"/> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> <map:transform type="session"/>  <map:transform src="xsl/filledlicense.xsl"/> <map:serialize type="html"/> </map:act> </map:act> </map:match>  <map:match pattern="licensecard"> <map:act type="request"> <map:parameter name="parameters" value="true"/>  <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/> <map:generate src="cocoon://ino/licenseinfo/{../serialNumber}"/> <map:transform src="xsl/htmlcard.xsl"/> <map:serialize type="html"/> </map:act> </map:act> </map:match>  <map:match pattern="downloadlicense"> <map:act type="request"> <map:parameter name="parameters" value="true"/>  <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/>  <map:aggregate element="page"> <map:part element="license" src="cocoon://ino/licenseinfo/{../serialNumber}"/> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate>

118

<map:transform type="session"/> <map:transform src="xsl/dllicense.xsl"> <map:parameter name="taminoUri" value="http://{baepp:taminoserver}/tamino/{baepp:taminodatabase}/{baepp:taminocollection}"/> </map:transform> <map:serialize type="html"/> </map:act> </map:act> </map:match>  <map:match pattern="sendlicense"> <map:act type="request"> <map:parameter name="parameters" value="true"/>  <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/>  <map:act type="request-exists"> <map:parameter name="parameters" value="submittedOnce"/>  <map:act type="form-validator"> <map:parameter name="descriptor" value="xml/sendlicense_desc.xml"/> <map:parameter name="validate-set" value="default"/>  <map:act type="sendmail"> <map:parameter name="smtpHost" value="{baepp:smtp}"/> <map:parameter name="subject" value="{../../../subject}"/>  <map:parameter name="body" value="http://localhost:{baepp:cocoonport}/{baepp:hostbase}/licensekeys/{../../../licensekey}/htmlbody.html"/> <map:parameter name="emailTo" value="{../../../emailTo}"/> <map:parameter name="emailCc" value="{../../../emailCc}"/> <map:parameter name="emailFrom" value="{../../../emailFrom}"/> <map:parameter name="nameFrom" value="{../../../nameFrom}"/> <map:parameter name="dataSources" value="http://localhost:{baepp:cocoonport}/{baepp:hostbase}/images/links.gif;http://localhost:{baepp:cocoonport}/{baepp:hostbase}/images/leer.gif;http://localhost:{baepp:cocoonport}/{baepp:hostbase}/images/logo_www.gif"/> <map:parameter name="dsHeaders" value="abc@abc;abd@abc;abe@abc"/> <map:parameter name="file" value="http://localhost:{baepp:cocoonport}/{baepp:hostbase}/licensekeys/{../../../licensekey}/{../../../filename}.xml;http://localhost:{baepp:cocoonport}/{baepp:hostbase}/licensekeys/{../../../licensekey}/{../../../filename}lt.pdf"/> <map:parameter name="fileName" value="{../../../filename}.xml;{../../../filename}lt.pdf"/> <map:redirect-to uri="menu"/> </map:act> <map:redirect-to uri="error?code=422303"/> </map:act>  <map:aggregate element="page"> <map:part element="license" src="cocoon://ino/licenseinfo/{../../serialNumber}"/> <map:part element="mlform" src="cocoon://mlform"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> <map:transform type="session"/> <map:transform src="xsl/sendlickeyform.xsl">

119

<map:parameter name="use-request-parameters" value="true"/> <map:parameter name="taminoUri" value="http://{baepp:taminoserver}/tamino/{baepp:taminodatabase}/{baepp:taminocollection}"/> </map:transform> <map:transform type="simple-form"/> <map:serialize type="html"/> </map:act>  <map:aggregate element="page"> <map:part element="license" src="cocoon://ino/licenseinfo/{../serialNumber}"/> <map:part element="mlform" src="cocoon://mlform"/>  <map:part element="write" src="cocoon://writelicense?serialNumber={../serialNumber}"/>  <map:part element="htmlbody" src="cocoon://writehtmlbody?serialNumber={../serialNumber}"/> <map:part element="session" src="xml/getxml.xml"/> </map:aggregate> <map:transform type="session"/> <map:transform src="xsl/sendlickeyform.xsl"> <map:parameter name="taminoUri" value="http://{baepp:taminoserver}/tamino/{baepp:taminodatabase}/{baepp:taminocollection}"/> <map:parameter name="use-request-parameters" value="true"/> </map:transform> <map:transform type="simple-form"/> <map:serialize type="html"/> </map:act> </map:act> </map:match>  <map:match pattern="cancellicense"> <map:act type="request"> <map:parameter name="parameters" value="true"/>  <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/>  </map:act> </map:act> </map:match>  <map:match pattern="reactivatelicense"> <map:act type="request"> <map:parameter name="parameters" value="true"/>  <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/>  </map:act> </map:act> </map:match>  <map:match pattern="writehtmlbody"> <map:act type="request"> <map:parameter name="parameters" value="true"/> <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/> <map:generate src="cocoon://ino/licenseinfo/{../serialNumber}"/> <map:transform src="xsl/writelicensehtmlbody.xsl"/> <map:transform type="write-source"> <map:parameter name="serializer" value="html"/> </map:transform>

120

<map:serialize type="xml"/> </map:act> </map:act> </map:match>  <map:match pattern="getlicense"> <map:act type="request"> <map:parameter name="parameters" value="true"/> <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/>  <map:act type="xmldocexists"> <map:parameter name="taminoUri" value="http://{baepp:taminoserver}/tamino/{baepp:taminodatabase}/{baepp:taminocollection}"/> <map:parameter name="query" value="License_Info[@serialNumber='{../serialNumber}']"/> <map:generate src="cocoon://ino/licenseinfo/{../../serialNumber}"/> <map:transform src="xsl/cleanxml.xsl"/> <map:serialize type="xml"/> </map:act>  <map:redirect-to uri="error?code=321002"/> </map:act> </map:act> </map:match>  <map:match pattern="getpdflicense"> <map:act type="request"> <map:parameter name="parameters" value="true"/> <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/> <map:generate src="cocoon://getlicense?serialNumber={../serialNumber}"/> <map:transform src="xsl/pdfcard.xsl"/> <map:serialize type="fo2pdf"/> </map:act> </map:act> </map:match>  <map:match pattern="writelicense"> <map:act type="request"> <map:parameter name="parameters" value="true"/> <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/> <map:generate src="cocoon://getlicense?serialNumber={../serialNumber}"/> <map:transform src="xsl/writeandkeep.xsl"> <map:parameter name="taminoUri" value="http://{baepp:taminoserver}/tamino/{baepp:taminodatabase}/{baepp:taminocollection}"/> </map:transform> <map:transform type="write-source"> <map:parameter name="serializer" value="xml"/> </map:transform> <map:transform src="xsl/writeandpdfcard.xsl"/> <map:transform type="write-source"> <map:parameter name="serializer" value="fo2pdf"/> </map:transform> <map:serialize type="xml"/> </map:act> </map:act> </map:match>  <map:match pattern="disconnect"> <map:act type="auth-logout"> <map:parameter name="handler" value="baepphandler"/> <map:redirect-to uri="login"/> </map:act> </map:match>  <map:match pattern="error"> <map:act type="request">

121

<map:parameter name="parameters" value="true"/>  <map:act type="auth-protect"> <map:parameter name="handler" value="baepphandler"/> <map:aggregate element="page"> <map:part element="session" src="xml/getxml.xml"/> <map:part element="error" src="cocoon://ino/error/{../code}"/> <map:part element="label" src="cocoon://ino/mlForm/label[@ident='lkscBack']"/> </map:aggregate> <map:transform type="session"/> <map:transform src="xsl/errorpage.xsl"> <map:parameter name="use-request-parameters" value="true"/> <map:parameter name="adminemailfrom" value="{baepp:adminemailfrom}"/> <map:parameter name="adminemailto" value="{baepp:adminemailto}"/> <map:parameter name="server" value="baepp:taminoserver}"/> <map:parameter name="smtp" value="{baepp:smtp}"/> </map:transform> <map:serialize type="html"/> </map:act> </map:act> </map:match>  <map:match pattern="**/*.html"> <map:read mime-type="text/html" src="{1}/{2}.html"/> </map:match> <map:match pattern="**/*.xml"> <map:read mime-type="text/xml" src="{1}/{2}.xml"/> </map:match> <map:match pattern="**/*.pdf"> <map:read mime-type="application/pdf" src="{1}/{2}.pdf"/> </map:match> <map:match pattern="style/*.css"> <map:read mime-type="text/css" src="style/{1}.css"/> </map:match> <map:match pattern="images/*.gif"> <map:read mime-type="image/gif" src="images/{1}.gif"/> </map:match> <map:match pattern="images/*.jpg"> <map:read mime-type="image/jpg" src="images/{1}.jpg"/> </map:match> <map:match pattern="ActiveX/**"> <map:read mime-type="application/octet-stream" src="ActiveX/{1}"/> </map:match> <map:pipeline>  <map:match pattern="ino/**"> <map:mount check-reload="yes" src="ino/" uri-prefix="ino/"/> </map:match> </map:pipeline>  <map:match pattern="*"> <map:act type="auth-loggedIn"> <map:parameter name="handler" value="baepphandler"/> <map:redirect-to uri="menu"/> </map:act> <map:redirect-to uri="login" session="true"/> </map:match> <map:handle-errors> <map:transform src="xsl/error2html.xsl"/> <map:serialize status-code="500"/> </map:handle-errors> </map:pipeline> </map:pipelines> </map:sitemap>


122

9.3.2. Détail de la structure d'un pipeline D'après le site apache.org

Element Description

map:match Selects pipeline processing depending on matching

map:select, map:when, map:otherwise Selects pipeline processing depending on selecting map:mount Mounts a sub sitemap map:redirect-to Redirects to a another URI map:call Goto another pipeline fragment map:parameter Defines additional parameters for the sitemap components

map:act Peform action processing

map:generate Defines the generation step map:aggregate, map:part Defines an alternate generation step by mergine pipelines map:transform Defines zero or more transformation steps

map:serialize Defines the final serialization s tep map:handle-errors Handles processing errors

9.3.3. Structure d'un dictionnaire i18n <translations> <entry> <key>Some {0} was inserted {1}.</key> <translation lang="en">Some {0} was {1} inserted.</translation> <translation lang="de">Etwas {0} wurde {1} eingesetzt.</translation> … </entry> <entry> <key>…</key> <translation lang="en">…</translation> <translation lang="de">…</translation> … </entry> … </translations> Remarque : la valeur du tag <key /> est égale à celle de <i18n:text /> et ces valeurs peuvent aussi bien être une phrase qu'un identifiant arbitraire et unique.

9.3.4. Stabilité et usage en production de Cocoon 2.1-dev § Extrait d'un échange avec Carsten Ziegeler, développeur Cocoon, le 3 septembre 2002 : This is not easy to answer. Most main components are still stable in 2.1, but some core components have changed - and most of them are stable, too. But there seems to be some minor problems in the current caching implementation of 2.1 - which should be fixed soon - the more people try out 2.1, the more bugs are found, the stabler it gets. > What is the difference between 2.1-dev and 2.1 beta ? What's missing today from cvs-head ? There are no real plans for 2.1 beta yet. > What about sunRise, is it as stable as in 2.0.3 ? There is a NPE [NDLR : Null Pointer Exception] with 2.0.3, jdk 1.3.1 and sunrise-lougout action... I think sunRise, sunSpot and also the SourceWritingTransformer are more stable in 2.1 than in 2.0.3. § Extrait d'un échange avec Konstantin Piroumian, développeur Cocoon, le 7 octobre 2002 :


123

First of all I should warn you to be careful with InputModules until some oficial release, cause they are actively discussed right now at the dev list and they can be changed (names, behavior, interfaces). You have been warned.

9.3.5. "Du bon usage des XSPs" Cette discussion, "Is it a good idea to avoid the use of xsp?", s'est déroulée le 12 septembre 2002 sur la mailing-list cocoon-users. § Email de Lajos Moczar : Hi Gernot - Whether one method is a better or worse idea than another is largely dependent on how you implement it. Yes, XSPs do somewhat violate Separation of Concerns. And yes, you can compare XSPs to JSPs in terms of pitfalls. The fact is, that there are some things you can only do with XSPs. My own personal preference is to first look at alternatives to XSPs (like using SQLTransformer instead of XSP + ESQL logicsheet). Then, if I do use an XSP, I try to use logicsheets wherever possible. If I have <xsp:logic> blocks, I keep them TO A MINIMUM. If have more than say 2 such blocks, I typically make my own logicsheet. The extra time it takes to do this is well worth the savings in administration later on. Bottom line: there is no right or wrong way in Cocoon. Pick you approach, especially if you are comfortable with it. Just develop your own best practices to help you code cleanly and in a way that can easily be maintained later on. § Réponse de Leigh Dodds : If you strictly enforce that your XSP pages don't contain Java code, and only use custom tags (Logicsheets) then you don't necessarily have a problem.

Your efforts here should focus on creating a useful set of Logicsheets, but ones that have a declarative approach, rather than ending up with a series of procedural statements. The alternative approach is to rely more heavily on your pipeline components (Actions and Transformers). You're unlikely to use XSP pages here, but may have them in limited form, e.g. to parameterise your XML generation to add information from the request/session/etc. Often here the XML you're feeding into the pipeline provides cues to the downstream components. See the SQLTransformer for example. I think the best advice I would give at the moment is to choose ONE of these approaches rather than a mix-and-match situation. If you do then your application is partly specified in the sitemap (pipeline structures) and partly in XSP pages (XML + Logicsheets) which isn't nice for maintainance: everything isn't in a single place. The interesting aspect to all this is that if you look a bit closer they're actually equivalent: When an XSP page is transformed into Java code, Cocoon determines the correct logic sheet transform to apply for each of your tags. This is repeated until all thats left are XSP elements. At that point the final transformation is carried out to generate Java code. This is then compiled and execute. So you have a process which: determines the code required for this task, then executes it. When a Pipeline is triggered in the pipeline, Cocoon builds up the Pipeline components (perhaps affected by various Actions along the way). Once the pipeline is built its then executed. So a useful question to ask is: which approach give you the most flexibility? The advantages of putting things in the sitemap is that you're beginning to approach the "Holy Grail" of computing: component based development. Throw together a few pipeline components and you've got an application. Fantastic. But, personally (and this is probably Cocoon heresy!), I think that once you start introducing fairly specific Actions and Transformers -- i.e. ones that have limited reuse, or may be used only in one pipeline -- you're possibly going down the wrong path: there's little value in having these as components other than Java code, particularly because the sitemap gets so complicated that its difficult to see whats going on. So far I've tended to use the sitemap for only doing the association between requests/processing/response rather than defining the processing steps.


124

I'd be interested in what others think. § Extrait de la réponse de Gernot Koller, initiateur de la discussion : After quite some time discussing and evaluating we made a decision in favor of cocoon as presentation framework. One major argument for cocoon and against struts was that in jsp a strict seperation of logic (Java code) and presentation is not always encouraged. There was also fear that the same issues might apply to xsp and therefore the decision was made to use cocoon but to avoid the use of xsp.

9.4. Projet BAE – License Key Application

9.4.1. Aspect visuel : copies d'écran § Page d'accueil


125

§ Menu principal (ancienne version)

§ Menu principal (nouvelle version)


126

§ Choix de famille de produits et plate-forme


127

§ Formulaire de génération de licence

§ Formulaire d'envoi de licence par email


128

§ Réception d'email au format HTML

9.4.2. Inventaire des classes existantes Elles sont produites par Bolero sous forme .bolero ou .java. On spécifie si ces classes sont des beans (b) paramètres, ou des servlets (s), package par package, et on note (b:@p) si le bean ne possède pas de constructeur sans paramètre.

Type

Package

Classe (nom court)

Fonction Model (m),

Controller (c) ou

View (v)

Appelée par (principale -

ment)

Commentaire

b baepp Session Informations de session m utilisé pour test, non utile au projet

b " Config Contient des définitions de constantes en liaison avec un fichier properties

m

b:@p " TaminoXqlAccess Requête x-query sur Tamino m ?

s " Authentication Login, authentification LDAP m - c -

s baepp. administration

AdminUser Affiche un formulaire permettant d'entrer les informations d'un nouvel utilisateur à entrer dans LDAP

v AdminMenu

s " AdminPartner Affiche un formulaire permettant d'entrer les informations d'un nouveau groupe d'utilisateurs à entrer dans LDAP

v AdminMenu

s " AdminMenu Affiche le menu principal d'administration LDAP : menus déroulants de groupes et utilisateurs, avec actions possibles sur chaque item

c - v LdapAuthentication


129

Type

Package

Classe (nom court)

Fonction

Model (m),

Controller (c) ou

View (v)


ment)

Commentaire

s " Disconnect Invalide la session et renvoie à la page d'accueil

c Nombreux servlets

b:@p " HTMLError Affiche une page HTML d'erreur : le détail est récupéré dans Tamino d'après un code (paramètre)

v

s " LdapLogin Construit la page de login administrateur

v MainMenu

b:@p " Mailer Envoi d'email (nombreux constructeurs correspondant aux différents cas de figure)

m

s " MainMenu Contruit le menu après récupération des droits LDAP et requêtes Tamino

m - c - v Authentication + nombreux servlets

s " ModifyEmail Affiche le formulaire permettant à l'utilisateur de modifier son email

v MainMenu

s " LdapAuthentication Gère le login administrateur (authentifie)

m LdapLogin

s " ModifyPassword Affiche le formulaire permettant à l'utilisateur de modifier son mot de passe de login dans l'application

v MainMenu

s " ModifyUser Affiche le formulaire permettant la modification des informations d'un utilisateur LDAP

v AdminMenu

s " ModifyPartner Affiche le formulaire permettant la modification des informations relatives à un groupe d'utilisateurs LDAP

v AdminMenu

s " RemovePartner Supprime un groupe LDAP c AdminMenu

s " RemoveUser Supprime un utilisateur LDAP c AdminMenu

s " SapToTamino Initialise la base de données et affiche un message d'erreur ou succès

c - v MainMenu

s " SavePartner Met à jour les informations de groupe dans LDAP

c AdminPartner

s " SaveUser Met à jour les informations d'utilisateur dans LDAP

c AdminUser

s " UpdateEmail Met à jour le nouvel email dans LDAP

c ModifyEmail

s " UpdatePartner Met à jour les informations de groupe dans LDAP

c ModifyPartner

s " UpdatePassword Met à jour le nouveau password dans LDAP

c ModifyPassword

s " UpdateUser Met à jour les informations d'utilisateur dans LDAP

c ModifyUser

b " LdapClient Effectue les opérations de modification sur les groupes et utilisateurs LDAP (login administrateur), récupère une liste de groupes ou utilisateurs

m – v code java importé

b " LdapEntry Effectue des opérations sur un vecteur de données LDAP

m code java importé

b:@p " TaminoAccess Récupère dans Tamino les document décrivant les droits d'accès

m code java importé

s baepp. administration. bugReport

BugReport Affiche un formulaire (méthode GET) et appelle une méthode d'envoi d'email (méthode POST)

c - v MainMenu Par défaut GET est utilisé


130

Type

Package

Classe (nom court)

Fonction

Model (m),

Controller (c) ou

View (v)


ment)

Commentaire

s baepp. administration. Multilanguage

MlManagement

Affiche le menu permettant de gérer le multilangage de l'application, choix de modifier les informations puis de les valider (mise à jour dans Tamino)

c - v InitMlManage-ment + autres MainMenu à partir du menu Administration ?

Certains servlets updatent les informations dans Tamino, d'autres renvoient vers un autre servlet qui exécute cette tâche

b " Description Contient du texte m s " DisplayLabel Gère la récupération des

labels m MlManagement

s " InitMlManagement Supprime des attrbuts de session

c MlManagement, UpdateXmlInTamino

b " MlLabel Contient les données du label m

s " AddLanguage Modifie un document XML issu de Tamino (mlForm), le met à jour et le remet dans Tamino

m MlManagement

s " MlManagementMenu Affiche le menu permettant de gérer le multilangage de l'application

v InitMlManagement, AddLanguage, RemoveLanguage

s " RemoveLanguage Modifie un document XML issu de Tamino (mlForm), le met à jour et le remet dans Tamino

m MlManagement

b " SearchInfo Contient des données m

s " UpdateMlForm Met à jour une liste d'éléments puis renvoie vers MlManagement

m MlManagement

s " UpdateXmlInTamino Met à jour un document mlForm récupéré de Tamino et le remet dans Tamino

m MlManagement

s baepp.boxSales.gui OrderList Affiche l'état d'un ordre SAP m - v OrderListCriteria

s " Catalog Affiche le catalogue des produits disponibles

m – v Nombreux servlets

s " ConfirmOrder Récapitule le shopping cart, crée un ordre SAP, envoie un email de confirmation

c - v MakeOrder

s " LoadSave Récupère un shopping cart ou le sauvegarde dans Tamino

m ShoppingCart

s " MakeOrder Récapitule le shopping cart m – v ShoppingCart

b:@p " MlForm Retourne une String à partir d'une requête Tamino

v

s " AddPosition Ajoute un élément à SAP m ProductForm s " ProductForm Affiche le formulaire SAP d'un

produit m - v Catalog

s " RemoveOrderItem Efface un élément du shopping cart

m - c ShoppingCart

s " SalesOrderToXML Retourne au format XML l'ordre d'achat

m - v ? renommer en SalesOrderToXml

s " ShoppingCart Affiche le shopping cart m - v Catalog, MakeOrder, ConfirmOrder, LoadSave, RemoveOrderItem

s " UpdateSalesOrder Met à jour l'ordre d'achat m ShoppingCart


131

Type

Package

Classe (nom court)

Fonction

Model (m),

Controller (c) ou

View (v)


ment)

Commentaire

b baepp.boxSales.orderManagement

MaterialLicenseType Formate un document XML <materialLicenseType />

m

b " MaterialPricingItem Formate un document XML <materialPricingItem />

m

b " MaterialPricingQuantity

Formate un document XML <materialPricingQuantity />

m

b " MaterialPricingUnit Formate un document XML <materialPricingUnit />

m

b " MaterialVersion Formate un document XML <materialPricingVersion />

m

b " OrderItem Formate un document XML <orderItem />

m

b " OrderItemIn Formate un document XML orderItemIn />

m

b OrderItemOut Formate un document XML <orderItemOut />

b " OrderPartner Formate un document XML <orderPrtner />

m

b " Pricing Formate un document XML <pricing />

m

b " SalesItem Formate un document XML <salesItem />

m

b " SalesOrder Formate un document XML <salesOrder/>

m

b " SalesOrderEventHandler

Vérifie la structure du document XML

m

b " Total Formate un document XML <total />

m

b " VatAmount Formate un document XML <vatAmount/>

m

b baepp.ldap LdapUser Gère le login, récupère des informations utilisateur

m

b " LdapAccess Construit le document XML représentant les données utilisateur : groupe

m

b baepp. licenseKey

AppControlledValue Contient des données m – v

s " ChangeStatusLicKey Change le statut d'une licence c ? Redondance avec LicKeyCancel

b " Counter Gère l'unicité des numéros de licences

m

s " DefaultGeneration Affiche le catalogue de produits

c - v MainMenu Code HTML produit par LicKeyTools

s " FreeGeneration Affiche le catalogue de produits

c – v MainMenu Identique à DefaultGeneration mais la variable free a la valeur 1 au lieu de 0. Code HTML produit par LicKeyTools

s " GenLicKey Génère une licence, l'insère dans Tamino puis l'affiche

m - v LicKeyForm (LicKeyTools.upgradeXNode), LicenseLineDetail

Code HTML produit par LicKeyTools (displayLicKey et displayMassLicKey)


132

Type

Package

Classe (nom court)

Fonction

Model (m),

Controller (c) ou

View (v)


ment)

Commentaire

s " LicKeyCancel Change le statut d'une licence. Affiche un formulaire

c - v retour arrire : LicenseListCriteria avec cancel 1. (LicKeyTools.displayLicKey)

Redondance avec ChangeStatusLicKey

s " LicKeyCard Affiche une carte de licence v GenLicKey (LicKeyTools.displayLicKey)

s " LicKeyCatalog Affiche une liste de produits en fonction de la famille de produits et de la plate-forme choisies

m - v DefaultGeneration, FreeGeneration (LicKeyTools.selectCatalog)

s " LicKeyDownload Crée un fichier zip d'une licence et affiche un lien sur ce fichier

m - v GenLicKey (LicKeyTools.displayLicKey), LicenseLineDetail

s " LicKeyForm Affiche un formulaire correspondant à la génération de licence (défaut, free, en masse)

c - v LicKeyCatalog, LicKeyTools (searchSN)

Code HTML produit par LicKeyTools

s " LicKeyHTMLMail Crée un fichier XML, affiche un formulaire d'envoi de licence par email (POST) et envoi l'email (GET)

m - v GenLicKey (LicKeyTools.displayLicKey)

renommer en LicKeyHtmlMail

s " LicKeyMailing Crée un fichier XML, affiche un formulaire d'envoi de licence par email

c - v LicKeyTools.displayLicKey (non utilise), LicenseLineDetail,

Redondant avec LicKeyHTMLMail, champs supplémentaires

s " LicKeyMenu Affiche un menu c - v ? Non utilisé

s " LicKeyStats Récupère les statistiques (requête Tamino) et affiche le résultat

c - v MainMenu

b " LicKeyTools Réalise des opérations communes aux différents types de génération / recherche de licences (requêtes Tamino, formulaire de sortie)

m - v - c - Certaines méthodes renvoient du code HTML dynamique (String) qui est ensuite utilisé par les servlets. Ce composant est énorme, il serait bon de le subdiviser.

s " LicKeyUpgrade Génère une licence c - v LicKeyTools

s " MassGeneration Affiche le catalogue des produits

c - v MainMenu Identique à DefaultGeneration mais la variable free a la valeur 2 au lieu de 0. Code HTML produit par LicKeyTools

b " ParamRegistSheet Contient des données v


133

Type

Package

Classe (nom court)

Fonction

Model (m),

Controller (c) ou

View (v)


ment)

Commentaire

s " RegistrationSheet Affiche une page avec des données à compléter par le client s'il veut enregistrer son produit (imprimé)

m - v LicenseLineDetail

b " RequestParam Contient des données v s " SearchCatalog Affiche un formulaire v ? non utilisé

s " SearchSNForm Recherche une licence m ? non utilisé

s baepp. licenseKey.b2b

PartnerGetLicense Récupère une licence (requête Tamino) et l'affiche ou l'envoie

m - c lien externe

b:@p " PartnerGetLicenseOutput

Gère le formatage et l'écriture d'un fichier

m

s " B2BTracking Récupère des licences (requête Tamino) et les affiche ou envoie

c lien externe

b:@p " B2BTrackingOutput Recherche des licences m s " PartnerGeneration Récupère des informations

pour le génération de licence et une fois celle-ci générée l'affiche ou l'envoie par email

c lien externe

b " PartnerGenLicKey Génère des licences m

b " PartnerLicKeyMail Crée un fichier XML, envoie un email

m

s " B2BQuery Récupère des licences (requête Tamino) et les affiche ou envoie

c lien externe

b:@p " B2BQueryOutput Recherche des licences m b " MyException m Sous-classe

de Exception mais ne fait rien de particulier

s baepp. licenseKey. administration

CatalogEditing Modifie les produits du catalogue en fonction des paramètres de la requête http

m CatalogMgt

s " CatalogMgt Récupération du catalogue (requêtes Tamino) et affichage

m - v LicKeyTools, CatalogEditing

b:@p " Component Modification d'XML m

b:@p " ConvertFormat Modification de chaîne de texte, parsing d'XML

m

b " ConvertXLS Modification de données pour écriture de fichier au format CSV

m Ne sera plus utilisé (format CSV abandonné)

s " DetailListing Affiche le détail d'un template v TemplateEditing

s " LicSetEditing Modifie une licence et affiche le résultat

m - v LicSetMgt

s " LicSetMgt Affiche une liste de licences c - v MainMenu, PlatformEditing, LicSetMgt

s " PlatformEditing Modifie une plate-forme et affiche le résultat

m – v PlatformMgt

s " PlatformMgt Affiche une liste de plates-formes

c - v MainMenu, PlatformEditing

s " PlugAssignEditing Modifie le lien entre un plugin et un produit et affiche le résultat

m – v PlugAssignment

s " PlugAssignment Affiche une liste de plugins v MainMenu, PlugAssignEditing

s " PlugEditing Modifie un plugin et un produit et affiche le résultat

m v PlugMgt


134

Type

Package

Classe (nom court)

Fonction

Model (m),

Controller (c) ou

View (v)


ment)

Commentaire

s " PlugListing Affiche la liste des plugins m v PlugAssignment

s " PlugMgt Affiche un formulaire de gestion des plugins

c - v MainMenu

s " PlugTypeEditing Modifie les informations d'un plugin, met à jour dans Tamino et affiche un formulaire html (résultat)

m v PlugTypeMgt

s " PlugTypeMgt Affiche la liste des plugins c v MainMenu

s " ProdListing Liste les produits v LicSetMgt, TempMgt

s " ProductFamilyEditing Modifie les informations d'une famille de produits, met à jour dans Tamino et affiche un formulaire html (résultat)

m v ProductFamilyMgt

s " ProductFamilyMgt Affiche la liste des familles de produits

c v MainMenu

s " RepStatsCmdLineOutput

Exécute une requête Tamino (<License_Info/>), écrit un fichier XML et CSV, affiche une page avec liens sur ces fichiers

m - v RepStatsCmdLineQry

s " RepStatsCmdLineQry Affiche un formulaire de recherche de licence (command-line query)

v MainMenu

s " RepStatsCriteria Affiche un formulaire de recherche de licence (interactive query)

v MainMenu

s " RepStatsOutput Exécute une requête Tamino (<License_Info/>), écrit un fichier XML et CSV, affiche une page avec liens sur ces fichiers

m - v RepStatsCriteria

b:@p " Tag Formate un document XML <Tag/>

m

b:@p " Template Formate un document XML <Template/>

m

s " TemplateEditing Edite un template et affiche le résultat

c - v TempMgt

b " TemplateToTamino Met à jour un template dans Tamino

m

s " TempMgt Affiche une liste de templates v MainMenu

s " VersionListing Affiche les versions de produit v PlugAssignment s baepp.

licenseKey. licenseTracking

LicenseListCriteria Affiche un formulaire de recherche de licence – paramètre cancel à 0 pour recherche, à 1 pour gestion de statut de licence

c - v MainMenu, LicKeyCancel

s " LicenseListXSL Affiche le résultat de recherche de licence, avec paramètre de request cancel à 0 ou 1

c -v LicenceListCriteria, PartnerGetLicense

renommer en LicenseListXsl

s " LicenseLineDetail Affiche le détail d'une licence v ?


135

Type

Package

Classe (nom court)

Fonction

Model (m),

Controller (c) ou

View (v)


ment)

Commentaire

b:@p baepp. onlineHelp

LoadDocument Récupère une page de Tamino c une fois sous forme java, problèmes de compilation (classes non trouvées, laissé de côté pour l'instant, non étudié en détail)

s " OLH_TOC Récupère le sommaire de l'aide en ligne dans Tamino et l'affiche

c - v MainMenu renommer en OlhToc

s " OnlineHelp Récupère une url virtuelle dans Tamino et redirige vers celle-ci

m Nombreux servlets

s " PictureManager Affiche une page de gestion des images

c - v ? Menu Maintenance du menu principal serait approprié ?

s " RemoveJpeg Supprime une image du disque

m PictureManager

s " UploadJpeg Ajoute une image sur le disque m PictureManager b " RequestParser m source ?

b " Thumbnail m source ?

b " XmlPage m source ? s baepp.

orderTracking OrderList Affiche les ordres d'achat

correspondant aux critères m - v OrderListCriteria

s " OrderListCriteria Affiche une page de recherche d'ordre d'achat (tracking)

c - v MainMenu

s " OrderListXSL Applique une feuille de style XSL (prépare le document XML)

m OrderListCriteria

b " TransformationXSLT Effectue les opérations nécessaires à l'application d'une feuille de style XSL à un document XML

m

s " OrderLineDetail Affiche le détail d'un ordre d'achat

v OrderList renommer en TransformationXslt

b:@p baepp.sap R3Material m

b " R3MaterialList m b:@p " R3Order m

b:@p " R3System m

b " SapSimulation m b:@p " FileLog m

b baepp.tamino MaterialLicenseTypeDescriptions

Formate un document XML (<MaterialLicenseTypeDescriptions/>)

m

b " CatalogueEventHandler

Vérifie la structure du document XMl <Catalogue/>

m

b " InoConnection Définition des méthodes de connexion à Tamino

m impossible d'obtenir le .java correspondant à partir de Bolero

b " Material Formate un document XML (<Material/>)

m


136

Type

Package

Classe (nom court)

Fonction

Model (m),

Controller (c) ou

View (v)


ment)

Commentaire

b " MaterialDescriptions Formate un document XML (<MaterialDescriptions/>)

m

b " MaterialFamily Formate un document XML (<MaterialFamily/>)

m

b " Catalogue Formate un document XML (<Catalogue/>)

m

b " MaterialLicenseTypes Formate un document XML (<MaterialLicenseTypes/>)

m

b " MaterialPricingQuantities

Formate un document XML (<MaterialPricingQuantities/>)

m

b " MaterialPricingUnitDescriptions

Formate un document XML (<MaterialPricingUnitDescriptions/>)

m

b " MaterialPricingUnits Formate un document XML (<MaterialPricingUnits/>)

m

b " MaterialVersions Formate un document XML (<MaterialVersions/>)

m

Etude de frameworks MVC - Analyse fonctionnelle de la migration du projet BAE vers J2EE B. Post – Software AG France - 2002

137 137

9.4.3. Enchaînement des servlets existants En bleu : appelé par d'autres servlets que ceux indiqués. (LCT) : transfert par du code HTML produit par LicKeyTools. Les servlets B2B sont standalone : appelées de l'extérieur.

Authentication -> MainMenu -> Catalog -> ProductForm -> AddPosition -> ShoppingCart -> UpdateSalesOrder

-> MakeOrder -> ConfirmOrder

-> LoadSave -> RemoveOrderItem

-> OrderListCriteria -> OrderList -> OrderLineDetail

-> OrderListXSL -> DefaultGeneration -> LicKeyCatalog

(LCT.selectCatalog) -> LicKeyForm -> GenLicKey

(LCT.displayLicKey) -> LicKeyHTMLMail

-> LicKeyCard

-> LicKeyDownload

-> FreeGeneration -> LicKeyCatalog (LCT.selectCatalog)

-> LicKeyForm -> GenLicKey (LCT.displayLicKey)

-> LicKeyHTMLMail

-> LicKeyCard -> LicKeyDownload

-> LicenseListCriteria?cancel=0 -> LicenseListXSL

-> LicSetMgt -> LicSetEditing -> ProdListing

-> PlatformMgt -> PlatformEditing

-> ProductFamilyMgt -> ProductFamilyEditing -> CatalogMgt -> CatalogEditing

-> PlugMgt -> PlugEditing -> PlugTypeMgt -> PlugTypeEditing

-> PlugAssignment -> PlugAssignEditing

-> PlugListing -> VersionListing

-> TempMgt -> TemplateEditing -> DetailListing

-> ProdListing -> RepStatsCriteria -> RepStatsOutput


138 138

-> RepStatsCmdLineQry -> RepStatsCmdLineOutput -> LicenseListCriteria?cancel=1 -> LicenseListXSL (LCT.displayLicKey) LicKeyCancel

-> LicKeyStats

-> MassGeneration -> LicKeyCatalog (LCT.selectCatalog)

-> LicKeyForm -> GenLicKey (LCT.displayMassLicKey)

-> ModifyPassword -> UpdatePassword

-> ModifyEmail -> UpdateEmail

-> LdapLogin -> LdapAuthentication -> AdminMenu -> AdminUser -> SaveUser -> AdminPartner -> SavePartner

-> ModifyUser -> UpdateUser

-> ModifyPartner -> RemovePartner

-> RemoveUser

-> OLH_TOC -> OnlineHelp

-> BugReport -> (javascript) SapToTamino

-> Disconnect

MlManagement -> DisplayLabel -> UpdateXmlInTamino ↓

-> InitMlManagement -> ↓

-> AddLanguage -> MlManagementMenu

-> RemoveLanguage -> ↑

-> UpdateMlForm

PictureManager -> RemoveJpeg

-> UploadJpeg


139 139

9.4.4. Nouveaux fichiers XML

9.4.4.1. Nouveau menu principal Le document XML suivant présente le menu principal réorganisé. La hiérarchie de 3 niveaux est conservée. <?xml version="1.0" encoding="ISO-8859-1" ?> <mlMenu> <language name="EN"> <menu name="main"> <level1 item="menu_licensekey"> <title1>License key</title1> <linkTo1></linkTo1> <picture1>puce2.gif</picture1> <level2 item="menu_licensekey_generation"> <title2>License key generation</title2> <linkTo2></linkTo2> <picture2>puce.gif</picture2> <level3 item="menu_licensekey_generateDefault"> <title3>Default Generation</title3> <linkTo3>defaultgeneration</linkTo3> <help3>Generate a new license key</help3> <picture3>key.gif</picture3> </level3> <level3 item="menu_licensekey_generateFree"> <title3>Free Generation</title3> <linkTo3>freegeneration</linkTo3> <help3>Generate a free license key</help3> <picture3>key.gif</picture3> </level3> <level3 item="menu_licensekey_massGeneration_sameLicense"> <title3>Mass generation : same License</title3> <linkTo3>massgeneration</linkTo3> <help3>Create mass licenses</help3> <picture3>key.gif</picture3> </level3> <level3 item="menu_licensekey_massGeneration_differentLicense"> <title3>Mass generation : different License</title3> <linkTo3>massgenfromfile</linkTo3> <help3>Create licenses from file</help3> <picture3>key.gif</picture3> </level3> </level2> <level2 item="menu_licensekey_lictrack"> <title2>License Tracking</title2> <linkTo2></linkTo2> <help2>Search, Display and Download license key file</help2> <picture2>puce.gif</picture2> <level3 item="menu_licensekey_LicenseTracking"> <title3>License Tracking</title3> <linkTo3>licensetracking</linkTo3> <help3>Search, Display and Download license key file</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_RepStatsCriteria"> <title3>Query and Report: Interactive Query</title3> <linkTo3>repstatscriteria</linkTo3> <help3>Interactive Query</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_RepStatsCmdLineQry"> <title3>Query and Report: Command Line Query</title3>


140 140

<linkTo3>/repstatscmdlineqry</linkTo3> <help3>Command Line Query</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_deleteLicenseKey"> <title3>Cancel / Reactivate license key</title3> <linkTo3>cancelreactivatelicense</linkTo3> <help3>Cancel or Reactivate a generated license</help3> <picture3>puce.gif</picture3> </level3> </level2> <level2 item="menu_licensekey_administration"> <title2>License administration</title2> <linkTo2></linkTo2> <help2></help2> <picture2>puce.gif</picture2> <level3 item="menu_licensekey_administration_licenseSetMgt"> <title3>License Set Management</title3> <linkTo3>licsetmgt</linkTo3> <help3>License set management</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_PlatformMgt"> <title3>Platform Management</title3> <linkTo3>platformmgt</linkTo3> <help3>Platform Management</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_ProductFamilyMgt"> <title3>Product Family Management</title3> <linkTo3>productfamilymgt</linkTo3> <help3>Product Family Management</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_productCatalogMgt"> <title3>Product Management</title3> <linkTo3>catalogmgt</linkTo3> <help3>Product catalog management</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_PlugMgt"> <title3>Plug Management</title3> <linkTo3>plugmgt</linkTo3> <help3>Plug management</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_PlugTypeMgt"> <title3>Plug Type Management</title3> <linkTo3>plugtypemgt</linkTo3> <help3>Plug Type Managment</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_PlugAssignment"> <title3>Plug Assignment</title3> <linkTo3>plugassignment</linkTo3> <help3>Plug Assignment</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_TemplateEditor"> <title3>Template Management</title3> <linkTo3>tempmgt</linkTo3> <help3>Template management</help3> <picture3>puce.gif</picture3> </level3> </level2> <level2 item="menu_licensekey_administration_statistic"> <title2>License statistics</title2> <linkTo2>lickeystats</linkTo2>


141 141

<help2>Count licenses by type and state</help2> <picture2>puce.gif</picture2> </level2> </level1> <level1 item="menu_userconfig"> <title1>User Config</title1> <linkTo1></linkTo1> <picture1>puce2.gif</picture1> <level2 item="menu_userconfig_passwordModification"> <title2>Password Modification</title2> <linkTo2>modifypassword</linkTo2> <help2>Modify your password</help2> <picture2>puce.gif</picture2> </level2> <level2 item="menu_userconfig_emailModification"> <title2>Email Modification</title2> <linkTo2>modifyemail</linkTo2> <help2>Modify your e-m@il address</help2> <picture2>puce.gif</picture2> </level2> </level1> <level1 item="menu_administration"> <title1>Administration</title1> <linkTo1></linkTo1> <picture1>puce2.gif</picture1> <level2 item="menu_administration_PartnersUsersManagement"> <title2>Partners and Users Management</title2> <linkTo2>ldaplogin</linkTo2> <help2>Manage users and groups</help2> <picture2>puce.gif</picture2> </level2> </level1> <level1 item="menu_onlineHelp"> <title1>Online Help</title1> <linkTo1>onlinehelp</linkTo1> <help1>Obtain online help about portal features</help1> <picture1>pucefaqtitre.gif</picture1> </level1> <level1 item="menu_bugReport"> <title1>Bug Report</title1> <linkTo1>bugreport</linkTo1> <help1>To report an anomaly in the application</help1> <picture1>bugreport.gif</picture1> </level1> <level1 item="menu_disconnect"> <title1>Disconnect</title1> <linkTo1>disconnect</linkTo1> <help1>Back to the portal entry page</help1> <picture1>door.gif</picture1> </level1> </menu> </language> <language name="FR"> <menu name="main"> <level1 item="menu_licensekey"> <title1>Clé de licence</title1> <linkTo1></linkTo1> <picture1>puce2.gif</picture1> <level2 item="menu_licensekey_generation"> <title2>Génération de clé de licence</title2> <linkTo2></linkTo2> <picture2>puce.gif</picture2> <level3 item="menu_licensekey_generateDefault"> <title3>Génération de licence</title3> <linkTo3>defaultgeneration</linkTo3> <help3>Génération de licence</help3> <picture3>key.gif</picture3> </level3> <level3 item="menu_licensekey_generateFree"> <title3>Génération de licence libre</title3> <linkTo3>freegeneration</linkTo3> <help3>Génération de licence libre</help3> <picture3>key.gif</picture3> </level3> <level3 item="menu_licensekey_massGeneration_sameLicense"> <title3>Licences identiques</title3>


142 142

<linkTo3>massgeneration</linkTo3> <help3>Génération de licence en masse</help3> <picture3>key.gif</picture3> </level3> <level3 item="menu_licensekey_massGeneration_differentLicense"> <title3>Licences différentes</title3> <linkTo3>massgenfromfile</linkTo3> <help3>Création de licences à partir d'un fichier</help3> <picture3>key.gif</picture3> </level3> </level2> <level2 item="menu_licensekey_lictrack"> <title2>Tracking</title2> <linkTo2></linkTo2> <help2>Rechercher, afficher et télécharger un fichier de clé de license</help2> <picture2>puce.gif</picture2> <level3 item="menu_licensekey_LicenseTracking"> <title3>Tracking</title3> <linkTo3>licensetracking</linkTo3> <help3>Rechercher, afficher et télécharger un fichier de clé de license</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_RepStatsCriteria"> <title3>Requête interactive</title3> <linkTo3>repstatscriteria</linkTo3> <help3>Requête en remplissant un formulaire</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_RepStatsCmdLineQry"> <title3>Requête par ligne de commande</title3> <linkTo3>/repstatscmdlineqry</linkTo3> <help3>Requête par ligne de commande</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_deleteLicenseKey"> <title3>Annulation / réactivation de licence</title3> <linkTo3>cancelreactivatelicense</linkTo3> <help3>changement de statut de licence générée</help3> <picture3>puce.gif</picture3> </level3> </level2> <level2 item="menu_licensekey_administration"> <title2>Administration de licence</title2> <linkTo2></linkTo2> <help2></help2> <picture2>puce2.gif</picture2> <level3 item="menu_licensekey_administration_licenseSetMgt"> <title3>Gestion des groupes de license</title3> <linkTo3>licsetmgt</linkTo3> <help3>Gestion des groupes de license</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_PlatformMgt"> <title3>Gestion de plate formes</title3> <linkTo3>platformmgt</linkTo3> <help3>Gestion de plate formes</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_ProductFamilyMgt"> <title3>Gestion de famille de produits</title3> <linkTo3>productfamilymgt</linkTo3> <help3>Gestion de famille de produits</help3> <picture3>puce.gif</picture3> </level3>


143 143

<level3 item="menu_licensekey_administration_productCatalogMgt"> <title3>Gestion des produits</title3> <linkTo3>catalogmgt</linkTo3> <help3>Gestion du catalogue de produits</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_newTemplate"> <title3>Gestion des templates</title3> <linkTo3>tempmgt</linkTo3> <help3>Créer un nouveau modèle</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_PlugAssignment"> <title3>Liaison plug-in / produit</title3> <linkTo3>plugassignment</linkTo3> <help3>Association d'un plug-in à un produit</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_PlugTypeMgt"> <title3>Gestion des types de Plug-Ins</title3> <linkTo3>plugtypemgt</linkTo3> <help3>Gestion des types de Plug-Ins</help3> <picture3>puce.gif</picture3> </level3> <level3 item="menu_licensekey_administration_PlugMgt"> <title3> Gestion des Plug-Ins</title3> <linkTo3>plugmgt</linkTo3> <help3>Gestion des Plug-Ins</help3> <picture3>puce.gif</picture3> </level3> </level2> <level2 item="menu_licensekey_administration_statistic"> <title2>Statistiques</title2> <linkTo2>lickeystats</linkTo2> <help2>Dénombrement des licences par type et statut</help2> <picture2>puce.gif</picture2> </level2> </level1> <level1 item="menu_userconfig"> <title1>Configuration utilisateur</title1> <linkTo1></linkTo1> <picture1>puce2.gif</picture1> <level2 item="menu_userconfig_passwordModification"> <title2>Modifier le mot de passe</title2> <linkTo2>modifypassword</linkTo2> <help2>Modifier le mot de passe</help2> <picture2>puce.gif</picture2> </level2> <level2 item="menu_userconfig_emailModification"> <title2>Modifier l'email</title2> <linkTo2>modifyemail</linkTo2> <help2>Modifier l'adresse email</help2> <picture2>puce.gif</picture2> </level2> </level1> <level1 item="menu_administration"> <title1>Administration</title1> <linkTo1></linkTo1> <picture1>puce2.gif</picture1> <level2 item="menu_administration_PartnersUsersManagement"> <title2>Gestion des partenaires et utilisateurs</title2> <linkTo2>ldaplogin</linkTo2> <help2>Gestion des utilisateurs et groupes</help2> <picture2>puce.gif</picture2> </level2> </level1> <level1 item="menu_onlineHelp"> <title1>Aide en ligne</title1> <linkTo1>onlinehelp</linkTo1> <help1>Aide en ligne et documentation</help1> <picture1>pucefaqtitre.gif</picture1>


144 144

</level1> <level1 item="menu_bugReport"> <title1>Notification de bug</title1> <linkTo1>bugreport</linkTo1> <help1>Rapporter une anomalie de l'application</help1> <picture1>bugreport.gif</picture1> </level1> <level1 item="menu_disconnect"> <title1>Déconnexion</title1> <linkTo1>disconnect</linkTo1> <help1>Retour à l'accueil</help1> <picture1>door.gif</picture1> </level1> </menu> </language> </mlMenu>

9.4.4.2. <access /> et LDAP Les éléments permettant de définir et gérer les droits d'accès sont dépendants du menu principal, lorsqu'il y a vérification d'un droit sur un élément de ce menu. § Eléments ajoutés à <mlMenu /> : - menu_licensekey_generation (élément de niveau 2) - menu_licensekey_lictrack (élément de niveau 2) § Eléments supprimés de <mlMenu /> : - menu_products - menu_products_boxSales - menu_products_viewOrder - menu_licensekey_massGeneration (scindé en 2 sous-éléments) - menu_training - menu_support - menu_maintenance - menu_administration_MaterialDatabaseManagement En conséquence, on doit modifier le document <access /> et les droits dans LDAP : § A ajouter : - menu_licensekey_generation - menu_licensekey_lictrack § A supprimer : - menu_products - menu_products_boxSales - menu_products_viewOrder - menu_licensekey_massGeneration (scindé en 2 sous-éléments) - menu_training - menu_support - menu_maintenance - menu_administration_MaterialDatabaseManagement

9.4.5. Structure des fichiers de la nouvelle web application Les éléments notés : (1) (fichiers annexes) sont inclus dans le .war mais ne servent pas ou pas directement au fonctionnement de l'application. (2) sont générés par l'application et non inclus. § A la racine : sitemap.xmap, build.xml § Dossier ActiveX § Dossier dlls (1, dlls et note)


145 145

§ Dossier doc (1, javadoc + doc. d'install.) § Dossier images § Dossier ino § Dossier licensekeys (2) § Dossier logs (2) § Dossier src (1, sources java) § Dossier style § Dossier tamino (1) § Dossier war (2, emplacement de génération du .war) § Dossier WEB-INF § Dossier xml § Dossier xsl

9.4.6. Tri des versions "3.1.1" et "3.1" § Une solution consiste à exploiter la fonction sortby() de requête Tamino (la requête utilise deux

fois cette fonction) et surtout utiliser un bon paramètre : tsd:collation, lorsqu'on définit le schéma Tamino.

§ Une autre solution issue de http://forums.tamino.com/3/OpenTopic?a=tpc&s=153292895&f=8142994291&m=4262938276 consiste à définir un schéma comme suit (réponse du 20 septembre 2002) :

Use the following schema: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tsd="http://namespaces.softwareag.com/tamino/TaminoSchemaDefinition"> <xs:annotation> <xs:appinfo> <tsd:schemaInfo name="string"> <tsd:collection name="types-string"/> <tsd:doctype name="types"> <tsd:logical> <tsd:content>closed</tsd:content> </tsd:logical> </tsd:doctype> </tsd:schemaInfo> </xs:appinfo> </xs:annotation> <xs:element name="string" type="xs:string"/> </xs:schema> with the following data: <string>2.1.1</string> <string>3.1.2</string> <string>3.1.1</string> <string>3.1</string> and _xql = string sortby(.)

9.5. Configurations

9.5.1. Configuration de l'existant BAE sous JRun 3.1 Cette annexe reprend quelques éléments d'un document "Migrating BAE from JRun 2.3.3 to 3.1" que j'ai rédigé et traitant du passage de JRun 2.3.3 à 3.1. La variable jrun.rootdir désigne le dossier d'installation de JRun, la variable jrun.server.rootdir le sous-dossier du dossier d'installation de JRun, correspondant à un serveur. Le fichier {jrun.rootdir}\lib\global.properties définit la configuration partagée, tandis que


146 146

le fichier {jrun.rootdir}\{jrun.server.rootdir}\local.properties définit la configuration d'un serveur. § Dans le fichier global.properties on précise le JDK :

java.exe=C:\\JDK13~1.1\\bin\\javaw.exe. § Classpath : avec la JMC : Java Settings -> Classpath, ou dans le fichier local.properties :

modifier la ligne user.classpath. en écrivant des paths avec des slashes. § Path : avec la JMC : Java Settings -> Library Path, ou dans le fichier local.properties :

modifier la ligne user.jnipath en écrivant des paths avec double antislashes. § Support de web application 2.3 : dans le fichier local.properties repérer la ligne contenant

"web-app_2_2.dtd" et ajouter les lignes ci-dessous au dessus : webapp.dtd-mapping.web-app_2_3.dtd={jrun.rootdir}/lib/web-app_2_3.dtd webapp.dtd-mapping.web-app_2.3.dtd={jrun.rootdir}/lib/web-app_2_3.dtd Copier web-app_2_3.dtd dans le répertoire {jrun.rootdir}\lib. § Avec la JMC, dans Session settings, mettre Use Session Persistence Engine à

false.

9.5.2. Configuration de JBuilder 6 Enterprise Afin de créer une web application on utilise l'assistant. § Menu Tools / IDE Options

Ajouter les extensions présentes dans le projet mais non visibles dans Tools / IDE Options / File Types. Sélectionner un type de fichier, cliquer sur le bouton add pour ajouter une extension. On associe alors : xconf, xmap à xml, cab, dll à generic binary file, doc à text file Ainsi les fichiers sont reconnus et peuvent être copiés lors de la compilation dans WEB-INF. § Project properties

- Vérifier dans Project / Project Properties / Build / Resource que les types de fichiers présents dans le projet et modifiés par la compilation doivent bien être copiés dans WEB-INF lors de celle-ci. ("Recognized Files Types"). Dans notre cas laisser par défaut. - Inclure en tant que "required libraries" tous les jars nécessaires, ils sont dans un dossier spécifique. Ils ne peuvent être dans le dossier WEB-INF\lib puisque JBuider les copie à cet endroit. - Définir l'emplacement de la documentation produite dans le dossier doc.

§ Webapp properties

Clic-droit sur le noeud webapp dans le panneau de gauche : - Onglet Webapp, cocher ce qui est nécessaire dans la liste des "Files Types included". Ils seront copiés dans le .war : dtd, gif, jpeg, generic binary file, HTML, Java source, javascript file, text file, XML. - Ne pas cocher "always create archive when building the project" (lent), cocher "compress the contents of the archive", définir l'emplacement dans le répertoire war (commodité). - Onglet Directories: cocher "include regular content of WEB-INF and subdirectories" et exclure : jar, war, jar_xerces_4_compil, licensekeys, logs, classes, defaultroot. - Onglet Classes: laisser "always include all classes and resources", § Autres éléments (optionnels)


147 147

L'intégration de JAD s'effectue en suivant les instructions : http://www.softamis.com/ie/ot/jad/highlight.html et en téléchargeant les fichiers requis : http://www.softamis.com/ie/ot/jad/download.html

9.5.3. Configuration de Tomcat 4.1 On désigne par %CATALINA_HOME% le répertoire d'installation de Tomcat. § Copier dans %CATALINA_HOME%\common\lib le fichier tools.jar qui se trouve dans le

répertoire lib du JDK utilisé. § Afin d'attribuer assez de mémoire à la JVM, ajouter la ligne suivante au fichier catalina.bat qui

se trouve dans le répertoire %CATALINA_HOME%\bin : set CATALINA_OPTS="-Xmx128m". § Copier dans le répertoire %CATALINA_HOME%\bin les dlls utilisées par le projet, et spécifier le

path dans %CATALINA_HOME%\bin\catalina.bat : set PATH=%JAVA_HOME%\bin;%CATALINA_HOME%\bin § Dans le fichier server.xml qui se trouve dans le répertoire %CATALINA_HOME%\conf : Le port 9090 est utilisé lors du développement, par défaut on peut laisser le port 8080 ou prendre le port 80. ligne : <Connector className="org.apache.catalina.connector.http.HttpConnector" port="8080" minProcessors="5" maxProcessors="75" …

§ La ligne suivante de %CATALINA_HOME%\conf\server.xml correspond au paramètre de

l'application : <Context path="/baepp" docBase="e:\developpement\baepp" debug="0" privileged="true" reloadable="true"/>. L'application a un attribut reloadable à true, ceci permet lors du développement de modifier une classe java et de la prendre en compte sans redémarrer Tomcat. NB : On peut avoir l'application placée dans %CATALINA_HOME%\webapps\baepp, dans ce cas docBase="baepp". NB2 : Afin de prendre en compte la variable PATH définie plus haut, il faut utiliser le fichier %CATALINA_HOME%\bin\startup.bat pour démarrer Tomcat, et non le raccourci placé dans le menu démarrer.

9.5.4. Configuration d'Eclipse Eclipse ne propose pas d'assistant, la structure de la web application est donc créée manuellement. § Dans les propriétés du projet (clic-droit sur le nœud du projet en perspective "resources") on

définit les points suivants : - on utilise les bibliothèques de WEB-INF\lib ; - le résultat des compilations doit être placé dans : WEB-INF\classes ; - l'emplacement de la javadoc est le répertoire doc (utiliser le menu file / export / javadoc pour la créer).

§ Dans le menu Run on peut définir le lancement du navigateur externe. § La création d'un .war s'effectue à l'aide d'un fichier build.xml et de Ant. Ce dernier est lancé

par clic-droit sur le fichier XML et la commande Run Ant…


148 148

Le fichier est présenté ci-dessous, le contenu des tags <property /> est adaptable à l'environnement local. Dans ce cas on a décidé de créer un .war, pas un .ear, alors que c'est possible également. <project name="BAEPP" default="create_war" basedir=".">

<property name="deploy" value="e:/developpement/baepp/war"/> <property name="webApp" value="e:/developpement/baepp"/> <property name="web-inf" value="${webApp}/WEB-INF"/> <property name="classes" value="${web-inf}/classes"/> <property name="lib" value="${web-inf}/lib"/> <target name="war">

<delete file="${deploy}/baepp.war"/> <war warfile="${deploy}/baepp.war" webxml="${web-inf}/web.xml">

<fileset dir="${webApp}"> <include name="sitemap.xmap"/> <include name="build.xml"/> <include name="dlls/**"/> <include name="doc/**"/> <include name="images/**"/> <include name="ino/**"/> <include name="resources/**"/> <include name="src/**"/> <include name="style/**"/> <include name="tamino/**"/> <include name="src/**"/> <include name="xml/**"/> <include name="xsl/**"/> <include name="WEB-INF/**.xconf"/>

</fileset> <classes dir="${classes}"/> <lib dir="${lib}"/>

</war> </target> </project> Si un problème du genre "Can not find the class file for java.lang.Object. Fix the classpath then try rebuilding this project" apparaît lors de la compilation, il convient, dans le menu Properties du projet, onglet Libraries, de vérifier que la variable JRE_LIB est bien incluse dans les fichiers requis (classpath).

9.5.5. CVS et Cocoon Si on n'utilise pas le lien direct (HTTP) : http://xml.apache.org/from-cvs/xml-cocoon2/, le logiciel d'accès à CVS sous Windows, WinCVS, doit être paramétré de la façon suivante :

1. Click on admin->preferences; 2. In "Enter the CVSROOT:" enter ":pserver:[email protected]:/home/cvspublic"

(without quotes); 3. In "Authentication:" choose ""passwd" file on the cvs server"; 4. Click "Ok"; 5. Click admin->login; 6. When asked for the password: answer "anoncvs" (without quotes); 7. Click "create->checkout module"; 8. Module name and path on the server is "xml-cocoon2" (no quotes); 9. Choose a dir to put the source code in; 10. Go to the "Checkout-options" tab and select "By revision/tag/branch" and enter

"HEAD"; 11. Click "Ok"; 12. If everything goes well, messages will start to appear in the log window; 13. Wait until you see "*****CVS exited normally with code 0*****" in the log window; 14. The Cocoon source is now on your harddrive.

Pour Unix voir cette page : http://xml.apache.org/cocoon/installing/index.html § Cocoon doit être compilé comme suit, à partir du fichier build.bat : build -Dinclude.webapp.libs=true -Dinclude.scratchpad.libs=true webapp Le fichier war est ensuite prêt à être déployé ou dézippé pour en récupérer les .jar et les fichiers de configuration.


149 149

9.6. APIs

9.6.1. XML:DB et Tamino XML:DB § Le projet XML:DB, depuis 2000, a pour but d'utiliser une seule API pour plusieurs bases de

données XML, telles que Xindice, eXist, Tamino…, avec la possibilité de réaliser toutes opérations sur un document : lecture, ajout, suppression, mise à jour, mise à jour partielle (XUpdate).

Différences avec Tamino 3 : - Des données non-XML peuvent être stockées mais ne sont pas différenciées des données XML

(contrairement à Tamino), en revanche dans ce cas le nom du document doit comporter son doctype. (ex. Image/doc1.jpg).

- L'identifiant unique d'un document est son docname noté oid, alors que pour Tamino cette donnée, aussi unique, est facultative. Tamino a son propre index, ino:id.

L'ensemble de classes de Tamino XML:DB permet l'usage de l'API XML:DB appliquée à Tamino. La version 3.1.2.1 pour Tamino 3.1, Windows et Solaris est sortie le 24 septembre 2002. Elle n'implémente pas la mise à jour partielle de document. Problèmes et solutions par M. Marc, pour mon projet : - Le mécanisme de génération d'un oid lors de l'insertion d'un document dans Tamino, à partir de XML:DB et Cocoon, n'était pas pleinement fonctionnel dans certains cas. Il a été modifié pour générer une clé qui soit unique et reprenne une information du document. - Le passage de DOM (interaction avec Tamino) vers SAX (Cocoon) n'était pas fonctionnelle, cela a

été résolu de manière satisfaisante mais non optimisée. En effet l'API XML:DB ainsi que Cocoon reposent sur un modèle SAX, alors que les développeurs de Tamino XML:DB ont utilisé DOM pour manipuler les données. Il y avait une mauvaise adaptation entre ces deux représentations d'un même document/flux XML.

9.7. Open source

9.7.1. Fonctionnement de CVS CVS : Concurrent Versions System, est un outil permettant à des développeurs de partager un même code dans un repository et de le faire évoluer, depuis le début des années 1990. La partie serveur tourne sous Unix, la partie clients sous plusieurs autres environnements possibles. CVS conserve une copie du fichier, la dernière en date, ainsi qu'un historique des changements effectuées, ce qui permet de reconstituer une version plus ancienne. CVS utilise un autre programme, RCS : Revision Control System, pour effectuer le contrôle des changements entre les versions proprement dit, au niveau d'un fichier. CVS apporte par rapport à RCS : des fichiers d'administration (pour les droits des utilisateurs etc), le contrôle groupé de fichiers, un schéma "copy-merge-modify", la détermination automatique de l'état d'un fichier. Les fichiers sont organisés en collections, une collection est représentée par un module qu'un développeur peut récupérer (checkout) ou mettre à jour (commit). Des branches permettent de définir plusieurs états définis par des noms symboliques (tags). Une branche est usuellement associée à une version majeure, à un développement temporaire… Elle contient plusieurs révisions. Par exemple, HEAD représente le dernier état de la branche considérée. L'un des principaux avantages de CVS est que les fichiers ne doivent pas être monopolisés en écriture pour modification. Le système peut concaténer les modifications opérées par deux développeurs sur des sections différentes d'un même fichier. Si en revanche c'est la même section il y a indication de conflit jusqu'à correction manuelle.


150 150

9.7.2. Eclipse 2.0

9.7.2.1. Historique Eclipse a été développé en tant que produit commercial par les équipes d'OTI et d'IBM à partir d'avril 1999, puis est devenu open source en novembre 2001, sous la licence Common Public Licence.

9.7.2.2. Interface graphique § Eclipse est basé sur l'intégration de :

- SWT : Standard Widget Toolkit, ensemble de classes Java permettant d'utiliser les widgets (éléments graphiques) natifs si disponibles, sinon de les émuler, ce qui aboutit à une rapidité d'interface sensible par rapport à AWT ;

- JFace, ensemble de classes permettant de réaliser l'interaction avec l'utilisateur au niveau de l'interface.

§ Le plan de travail (workbench) de la plate-forme Eclipse a pour éléments de base :

- les éditeurs (editors ), qui sont des fenêtres de menu ou permettant l'édition de code… ; - les vues (views ) qui étendent la possibilité des éditeurs en fournissant de l'information sur des

objets (projet ou propriété…) ; - les perspectives qui sont des arrangements spécifiques d'éditeurs et de vues, par exemple :

Java (orienté édition et compilation de code java), Java Browsing (vision de la structure des packages, classes et méthodes), Debug (variables et messages lors de compilation Java), Resources (orienté navigation et propriétés), XSLT Trace (exécution de transformation XSLT avec débogage)…

Ces composants sont tous hautement modifiables et chargés sélectivement en mémoire, à la demande. L'interface est aussi rapide qu'une application native du système d'exploitation.

9.7.2.3. Java Development Tools L'usage de JDT pour réaliser l'édition et la compilation de code Java permet d'offrir une très large gamme de fonctionnalités comparé à d'autres outils.

9.7.2.4. Intégration

9.7.2.4.1. Plug-ins Les plug-ins sont les éléments par lesquels de nouvelles fonctionnalités sont ajoutables au PDE : Plug-in Development Environment . Leur format est standardisé : descripteur XML, archives java, documentation. Une liste est disponible ici : http://www.eclipse-workbench.com/jsp/plugins.jsp Quelques plug-ins remarquables balayant une étendue de besoins : § X-Men, éditeur XML avec validation (alpha, open-source) : http://sourceforge.net/projects/xmen/ § VSS Plug-in, interaction avec Visual SourceSafe (stable, open-source) :

http://sourceforge.net/projects/vssplugin § Log4j accessible pour l'ensemble des plug-ins, AntView pour mieux intégrer Ant (stable, open

source) : http://sourceforge.net/projects/r2tech-eclipse/ § SunBow (stable, commercial) : XSLT transformer, éditeur XML, intégration avec Cocoon (stable,

commercial) : http://radio.weblogs.com/0108489/. § XML Buddy, simple éditeur/validateur XML (stable, commercial) : http://www.xmlbuddy.com/ § Collection de plug-ins afin de faciliter l'édition de web applications (alpha, open source) :

http://sourceforge.net/projects/solareclipse/ § Editeur de Struts-config (alpha, open source) : http://www.improve-technologies.com/alpha/struts-

config-editor/


151 151

§ Viewer WSDL (alpha, open source) : http://www.improve-technologies.com/alpha/wsdl-viewer/ § Mise à jour de zip / jar automatique (beta, open source) :

http://www7b.software.ibm.com/wsdd/library/techarticles/0112_deboer/deboer2.html § Intégration du décompilateur JAD (beta, open source) : http://sourceforge.net/projects/jadclipse/ § Web service extension, (pas de fichiers disponibles, open source) :

http://sourceforge.net/projects/wseclipseplugin/ § JXMLEditor, éditeur XML intégré basé sur Xerces, (pas de fichiers disponibles, open source) :

http://sourceforge.net/projects/jxmleditor/

9.7.2.4.2. Autres éléments De nombreux éléments open source ou commerciaux sont intégrés ou intégrables à Eclipse : Ant, pour la compilation, CVS et VSS pour le travail partagé, Lucene pour l'indexation de la documentation, Tomcat headless pour la présentation de cette même documentation.

9.7.2.5. Portabilité L'internationalisation des plug-ins est assurée (traductions fournies en plusieurs langues) et partageable entre eux. De nombreuses plate-formes sont supportées : Microsoft Windows, Linux Intel x86, Sun Solaris 8 Sparc, HP-UX 11iHP9000, IBM AIX 5.1 on PowerPC, Mac OS X PowerPC (en cours à la date de septembre 2002).

9.7.2.6. Extensibilité et robustesse La plate-forme Eclipse contient des templates (modèles) permettant de faciliter la création de nouveaux plug-ins. Un workbench Eclipse peut tester le bon fonctionnement d'un autre.

9.8. Etude des moteurs de servlets J'ai testé l'existant BAE, avant la modification pour l'extension B2B, sous JRun 3.1, JRun 4 et Tomcat 4.0. Avec JRun 4 on se heurte à des problèmes d'incompatibilité de JDK. J'ai réalisé plusieurs documents en anglais : "JRun 3.1 vs 4", "JRun vs Tomcat". M. Milgram a réalisé "Installation JRun 3.1".


152 152

9.9. Comparaison de prix de quelques éditeurs / compilateurs Java commerciaux Pour référence, les prix sont de septembre 2002. Les versions choisies des logiciels ont un niveau de fonctionnalité comparable. On note entre crochets des versions dont les fonctionnalitées sont moins poussées. Editeur Produit Version Date de

sortie Nombre de

licences Prix USD

IntelliJ IDEA 2.6 La version 3.0 est presque prête.

juin 2002 1-4 395

5-9 360 10-49 320 50+ 295

Borland JBuilder Enterprise 7.0 [Standard Edition 7.0] [Personal 7.0]

juin 2002 2999 [399] [0]

Mise à jour vers EE 7.0 à partir de toute version Professional ou Enterprise 1899

Sun Sun One Studio 4 (anciennement Forté for Java)

Enterprise Edition 4.0 Community Edition 4.0 juin 2002 1995

0 IBM VisualAge for Java Professional Edition, 4.0 août 2001 111 Upgrade vers PE 4.0 52

vers une architecture J2EE à base open source

Documents

Transcript of vers une architecture J2EE à base open source