Migration de l`application internet de gestion des licences Software AG

Transcription

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 A LLIANCES 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. M ES MISSIONS................................................................................................................................................................12
2.4.1. Un défi ...................................................................................................................................................................12
2.4.2. Organisation........................................................................................................................................................12
2.4.3. Tâches annexes....................................................................................................................................................13
2.4.4. Documents produits............................................................................................................................................13
3. ETUDE DE FRAMEWORKS MVC...........................................................................................................................14
3.1. POURQUOI UN FRAMEWORK MVC ET J2EE ?...........................................................................................................14
3.1.1. Architecture MVC ou "Model 2"......................................................................................................................14
3.1.2. Un framework J2EE ...........................................................................................................................................15
3.2. ETUDE DE DEUX FRAMEWORKS...................................................................................................................................16
3.2.1. Pourquoi Struts et Cocoon ?.............................................................................................................................16
3.2.2. Struts 1.1 b1.........................................................................................................................................................17
3.2.3. Cocoon 2.1-dev....................................................................................................................................................23
3.2.4. Comparaison de Struts et Cocoon....................................................................................................................30
3.2.5. Conclusions – comment choisir........................................................................................................................32
4. MIGRATION DU PROJ ET LICENSE KEY APPLICATION/BAE................................................................36
4.1. DESCRIPTION ET ANALYSE DE L 'EXISTANT ................................................................................................................36
4.1.1. Architecture..........................................................................................................................................................36
4.1.2. Problèmes posés..................................................................................................................................................41
4.2. EVALUATION DE SOLUTIONS.......................................................................................................................................41
4.2.1. Struts 1.1 b1.........................................................................................................................................................41
4.2.2. Cocoon 2.1-dev....................................................................................................................................................42
4.2.3. Conclusions..........................................................................................................................................................43
4.3. ELEMENTS STRATEGIQUES...........................................................................................................................................43
4.3.1. Solution retenue...................................................................................................................................................43
4.3.2. Modification de fichiers XML ...........................................................................................................................43
4.3.3. Gestion des accès à Tamino..............................................................................................................................44
4.3.4. Gestion de l'accès à LDAP ................................................................................................................................44
4.3.5. Autres choix stratégiques...................................................................................................................................44
4.4. DEVELOPPEMENT REALISANT UNE FONCTION DANS SON ENSEMBLE : GENERATION DE LICENCES PAR DEFAUT
.................................................................................................................................................................................................45
4.4.1. Généralités...........................................................................................................................................................45
4.4.2. Modifications apportées à la configuration par défaut de Cocoon............................................................45
4.4.3. Documentation des fichiers réalisés................................................................................................................46
4.4.4. Maintenance, procédure de mises à jour........................................................................................................52
4.5. OUTILS ET METHODES DE DEVELOPPEMENT .............................................................................................................52
4.5.1. Editeur/debugger XSLT : Excelon Stylus Studio...........................................................................................53
4.5.2. Editeur et compilateur java : JBuilder............................................................................................................53
4.5.3. Moteur de servlets : Tomcat 4.1.......................................................................................................................55
4.5.4. Débogage..............................................................................................................................................................56
4.5.5. Logging.................................................................................................................................................................56
4.6. CHIFFRAGE .....................................................................................................................................................................57
4.7. PLANNING PREVISIONNEL DE DEVELOPPEMENT .......................................................................................................57
4.7.1. Temps nécessaire ................................................................................................................................................57
4.7.2. Exemple de répartition des tâches – 3 développeurs....................................................................................61
4.7.3. Calendrier global................................................................................................................................................62
4.8. CONCLUSIONS................................................................................................................................................................63
4.8.1. Une nouvelle application plus efficace ...........................................................................................................63
4.8.2. Une prise de risques nécessaire .......................................................................................................................63
4.8.3. Une documentation réalisée variée..................................................................................................................63
4.8.4. Quelques problèmes rencontrés.......................................................................................................................63
5. L'OPEN SOURCE : PRES ENTATION ET ENJEUX ...........................................................................................65
5.1. PRESENTATION..............................................................................................................................................................65
5.1.1. Définition de l'open source................................................................................................................................65
5.1.2. Une stratégie gagnante......................................................................................................................................66
5.1.3. Bref historique.....................................................................................................................................................66
5.1.4. Différentes licences.............................................................................................................................................67
5.1.5. Quelques acteurs actuels et historiques..........................................................................................................72
5.1.6. Quelques points de comparaison avec le logiciel propriétaire...................................................................74
5.2. L'OPEN SOURCE ET LE MARCHE EN 2002 ...................................................................................................................74
5.2.1. Evolution structurelle des logiciels : du "back -end" vers le "front-end" ..................................................74
5.2.2. Produits actuels...................................................................................................................................................74
5.2.4. Clients, utilisateurs.............................................................................................................................................78
5.2.5. Revenus.................................................................................................................................................................81
5.2.6. Tendances.............................................................................................................................................................82
5.3. L'OPEN SOURCE ET LE DEVELOPPEUR.........................................................................................................................82
5.3.1. Profil et motivations...........................................................................................................................................83
5.3.2. Outils et méthodes...............................................................................................................................................83
5.3.3. A la frontière de la communauté – expérience personnelle.........................................................................83
5.4. L'OPEN SOURCE ET LE GENIE LOGICIEL......................................................................................................................84
5.4.1. Le logiciel open source......................................................................................................................................84
5.4.2. Le projet basé sur le logiciel open source......................................................................................................85
5.5. DES MODELES ECONOMIQUES BASES SUR L'OPEN SOURCE .....................................................................................86
5.5.1. Vue d'ensemble....................................................................................................................................................86
5.5.2. Cinq modèles, quelquefois pour un même acteur..........................................................................................87
5.5.3. Un modèle pour Software AG ?........................................................................................................................89
5.6. "DE L'ERE DES EDITEURS COMMERCIAUX DE LOGICIELS A CELLE DES ENTREP RISES D'INFORMATION "...........89
5.6.1. Utilisateurs professionnels…............................................................................................................................89
5.6.2. … ou changement de modèle économique ?...................................................................................................91
5.6.3. Evocation de différentes problématiques........................................................................................................91
5.6.4. Positionnement de Software AG.......................................................................................................................92
5.7. L'OPEN SOURCE ET LE JURISTE ....................................................................................................................................93
5.7.1. Délivrer un logiciel open source, quelle responsabilité ? ...........................................................................93
5.7.2. Dissémination de secrets industriels ? ............................................................................................................94
5.7.3. Forcer l'adoption de standards........................................................................................................................94
5.7.4. Les brevets : combat des titans.........................................................................................................................94
5.8. CONCLUSIONS................................................................................................................................................................95
6. CONCLUSION GENERALE .......................................................................................................................................96
Migration du portail de gestion des licences produits de Software AG
B. Post – Software AG France - 2002
7. GLOSSAIRE......................................................................................................................................................................97
8. BIBLIOGRAPHIE.........................................................................................................................................................101
9. ANNEXES ........................................................................................................................................................................107
9.1. A UTRES FRAMEWORKS.............................................................................................................................................. 107
9.2. STRUTS ........................................................................................................................................................................ 107
9.3. COCOON ...................................................................................................................................................................... 109
9.4. PROJET BAE – LICENSE KEY APPLICATION .......................................................................................................... 124
9.5. CONFIGURATIONS ...................................................................................................................................................... 145
9.6. API S ............................................................................................................................................................................. 149
9.7. OPEN SOURCE ............................................................................................................................................................. 149
9.8. ETUDE DES MOTEURS DE SERVLETS........................................................................................................................ 151
9.9. COMPARAISON DE PRIX DE QUELQUES EDITEURS / COMPILATEURS JAVA COMMERCIAUX............................. 152
Migration du portail de gestion des licences produits de Software AG
Remerciements
Je remercie Software AG France de m'avoir accueillie pour mon stage de fin d'études et m'avoir
donné l'opportunité, non seulement d'évoluer dans un cadre technologique passionnant, mais
d'exercer mes compétences en collaboration, sur l'ensemble des phases d'un projet. Et malgré la
conjoncture difficile, de m'avoir permis de terminer le stage.
Je remercie plus particulièrement mon responsable, M. Joël Milgram, directeur de projets, pour sa
supervision efficace et la grande autonomie qu'il m'a laissée, ainsi que pour l'orientation qu'il a donnée
à mon mémoire.
Mes pensées se tournent également vers mon suiveur, M. Gil Largeaud, pour ses conseils
constructifs concernant mon mémoire, ainsi que M. Jérôme Marc, expert technique de Software AG,
pour son assistance lorsque j'en avais besoin, et les quelques échanges que nous avons eus sur
Cocoon.
Migration de l'application de gestion des licences produits de Software AG
5
1. Introduction
Aujourd'hui les technologies, les compétences, les besoins évoluent rapidement. Deux défis majeurs,
dans le cadre de systèmes existants, sont leur évolution structurelle ainsi que leur pérennité
fonctionnelle.
Software AG, éditeur de logiciels, utilise depuis mi-2000 un système de production et gestion de
licences de ses produits, "License Key Application" (anciennement "Business Alliances Europe"). Il
permet, outre la sécurisation contre le piratage, une meilleure répartition de l'information. Cela prend
la forme d'un portail intranet (centres logistiques allemand et américain) et internet (partenaires
autorisés).
Le projet initial a été réalisé par six ingénieurs pendant sept mois, à l'aide d'un outil de
développement conçu par Software AG : Bolero. Son évolution et support technique ne seront plus
assurés en 2005.
La question suivante s'est alors posée : comment garantir la pérennité du système indépendamment
de l'outil de développement spécifique et des développeurs initiaux ?
Ma tâche a donc consisté à réaliser une preuve de faisabilité de la migration de cette application vers
le standard J2EE, en choisissant un cadre de développement adapté.
Ce mémoire présente :
§
§
§
brièvement Software AG et sa filiale française,
mon étude de deux cadres de développement open source,
les étapes du projet auxquelles j'ai participé :
03/02
04/02
05/02
06/02
07/02
08/02
09/02
10/02
11/02
étude de cadres de développement
aide à l'extension B2B, étude de
moteurs de servlets. durée effective :
3 semaines
analyse de l'existant (structure,
fonctions)
analyse fonctionnelle
développement (preuve de faisabilité)
documentation du développement
analyse des outils utilisés pour le dév.
rédaction du mémoire
réunions importantes (compte-rendu,
prises de décisions, planification)
§
§
un bilan des outils et méthodes que j'ai utilisés,
une réflexion personnelle sur les licences open source dont l'enjeu est des plus importants pour
un éditeur de produits commerciaux.
Remarque : les termes explicités dans le glossaire (partie 7) voient leur première occurrence dans le corps du document
soulignée en pointillés.
6
Abstract
In today’s digital world, technologies, skills, and needs are constantly evolving. Important challenges
are how to modify the architecture of an existing system, and how to preserve long-term functional
capabilities.
Software AG develops and licenses cross-enterprise system software products for electronic
business, enterprise application integration, and online transaction processing.
Management of its software licenses has been handled since mid-2000 by License Key Application
(former Business Alliances Europe). BAE is an intranet-based portal used by German and US logistic
centres, and an internet -enabled portal for granted partners.
BAE's portal allows centres and partners to generate licenses, as well as perform searches, change
license status, gather statistics, and manage users' and partners' information.
The initial project required six software engineers for a period of seven months. The system continued
to evolve with additional developments up to this year during my internship. Bolero, a proprietary Javabased tool developed by Software AG, is the main development software that was utilized for years.
However its evolution has ceased and technical support will become ineffective in 2005.
Therefore the challenge that I was presented with in working on this project was how to keep the
system working, while detaching it from the initial team and software.
This document provides an overview and summary of:
§
§
§
§
§
Software AG and its French subsidiary
my study of two open source frameworks that I deemed suitable for the redesign
parts of the project I realized, mostly on my own : mainly analysis of existing code and
functionalities, functional analysis for the new architecture, some development as feasibility proof,
and an estimation of time and cost for the whole project
analysis and criticism of the development tools I used
personal thoughts, from open source licensing system to software editor's viewpoint
7
2. Présentation de la société et du projet
Software AG est leader du marché des bases de données XML natives et a de fortes compétences en
intégration (solutions middleware). Elle se présente comme " The XML Company" et participe
activement à l'élaboration de standards au sein des consortiums internationaux. La filiale française
réalise l'implémentation de solutions utilisant les produits Software AG.
Dans ce cadre, j'ai été chargée d'étudier et de proposer des solutions techniques pérennes sur le
changement d'architecture du portail d'application gérant les licences produits
2.1. Software AG : éditeur de logiciels d'infrastructure et intégrateur
de solutions complètes
Software AG, éditeur de logiciels fondée en 1969 à Darmstadt, emploie 3000 personnes dont un peu
plus du tiers en Allemagne, le reste étant réparti dans 70 pays. Le chiffre d'affaires s'élève à 589
millions d'euros en 2001, réparti assez équitablement entre revenus de licences, contrats de
maintenances, et services.
e
Partie du développement d'environnement de développement tel que Natural (langage de 4
génération), ou de base de données comme Adabas, la société s'est tournée au milieu des années
1990 vers les technologies XML et l'intégration d'applications (EAI : Enterprise Application
Integration). Ses produits phares sont actuellement Tamino : base de données native XML, leader sur
son marché, et EntireX, outil d'intégration middleware de flux de données hétérogènes.
En plus de la vente directe, une politique soutenue de partenariats et contrats a été mise en place,
intéressant d'autres éditeurs de logiciels (independent software vendors ("ISVs'')), des distributeurs à
valeur ajoutée (value added resellers ("VARs'')), et des intégrateurs (system integrators ("SIs'')).
Par ailleurs Software AG est membre de plusieurs organismes ou projets importants :
§ W3C, World Wide Web Consortium, groupes de travail suivants : XML Schema, XML Query,
XSLT, XML Protocol, XML DOM, XML InfoModel, Web Services Architecture.
Software AG a été éditeur ou co-éditeur de Working Drafts sur : Quilt puis XQuery 1.0, XPath 2.0,
XSLT 2.0, Web Services Architecture.
§ OASIS (membre et sponsor). OASIS est un organisme qui aide au développement, à la
convergence et à l'adoption de standards d'e-commerce.
§ Unicode, standard permettant la représentation indépendamment de la plate-forme et du langage
de n'importe quel caractère.
§ UDDI : Universal Description, Discovery and Integration, standard ouvert de description,
recherche et intégration de services e-business sur le réseau internet.
§ Edifrance, groupes de travail autour de l'échange de documents électroniques (EDI). Seulement
la filiale française de Software AG est concernée.
§ WS-I, Web Services Interoperability Organization.
§ XML France, association d'utilisateurs de XML.
De plus, la "XML Academy" fondée par Software AG propose un cycle de formation complet sur XML
en partenariat avec HP.
2.2. La filiale française
§
Software AG France (abrégé : SAGF) dirigée par Philippe Lerer depuis mai 2002, emploie 150
personnes et génère en 2001 un chiffre d'affaires de 21 millions d'euros.
L'activité s'est orientée vers la commercialisation, le support et les services intégrant les produits et
solutions de Software AG. Des formations sur tous les produits sont assurées.
8
§
Le département services est organisé comme suit, en entité tripartite :
-
BIS : Business Innovation Services, dirigé par Philippe Toubert. Gère l'avant-projet : consulting,
formation…
-
BITS : Business Integration Technology Services, dirigé par Philippe Toubert. Gère les projets. Il
est divisé en deux agences se répartissant les projets suivants qu'ils sont orientés bases de
données ou administration système. Les responsables sont respectivement Sylvie Morange et
Dominique Hubert.
-
BOS : Business Operation Services, dirigé par François-Xavier Delassus. Gère l'après projet :
hotline, maintenance, installation sur site.
De ce fait la prise en charge globale de projets basés sur des standards tels que XML, J2EE, .NET,
CORBA… est assurée par SAGF de manière structurée.
§
L'agence de Dominique Hubert compte un directeur de projets : Isabelle Bertinet, tandis que celle
de Sylvie Morange en compte deux : Joël Milgram et Philippe Buisson.
Un directeur de projet gère au plus 5 projets à la fois, ainsi que des réponses à des appels d'offres.
J'ai eu la chance d'évoluer sous la responsabilité de M. Milgram.
Professional Services
(en cours de pourvoi)
Commercial
Gilbert TOMASSO
Contrôle de gestion
Hanifa BOUASSRIA
Assistantes
BIS
Philippe TOUBERT
BITS
Philippe TOUBERT
BOS
François-Xavier DELASSUS
Support
Michel DOUCET
Responsable d'agence
Sylvie MORANGE
Directeur de projets
Joël MILGRAM
Responsable d'agence
Dominique HUBERT
Philippe BUISSON
Isabelle BERTINET
9
2.3. Le projet Business Alliances Europe – License Key Application
Cette partie reprend les informations tirées d'un document "License Key Application – Business
Case", d'avril 2002, réalisé par Reinhard Fox, chef de projets au sein du Customer Service Systems,
département de Corporate Information Services (informatique interne de Software AG).
M. Reinhard Fox est chargé de la maîtrise d'œuvre de License Key Application et de la liaison avec la
filiale française qui en assure le développement et la maintenance. Le terme "License Key Application"
est préféré à celui de "BAE" surtout depuis les dernières modifications apportées au portail.
Cependant dans ce document on trouve les deux termes (souci de prononciabilité).
2.3.1. Besoins, buts
Software AG, pour protéger ses produits logiciels contre le piratage, utilise une clé de licence unique
par produit vendu. La société a décidé de généraliser l'automatisation de cette pratique en l'an 2000.
En effet la progression des ventes de Tamino a entraîné un besoin de standardiser le mécanisme de
production et gestion des licences.
Le projet License Key Application a plusieurs buts :
-
générer une clé unique pour chaque produit ;
permettre une homogénéité dans la manière de produire les licences ;
pouvoir licencier modulairement tous les produits SAG, ainsi que les sous-produits et produits
dérivés ;
favoriser le marketing par proposition de licences à durée limitée, avec fonctionnalité entière du
produit ;
assurer un service technique pour les clients, la clé de licence servant d'identifiant ;
contrôler les installations de test ;
contrôler les revenus issus des partenariats avec les ISVs, VARs, SIs ;
obtenir des statistiques en général
… et ceci accessible par des services répartis géographiquement de par le monde afin d'assurer un
service permanent.
2.3.2. Fonctionnement
2.3.2.1. Acteurs et rôles
2.3.2.1.1. Centres logistiques
Deux centres logistiques (LSC, Logistic Service Center) ont la charge de traiter les demandes de
clients. Suivant la procédure standard, ils sont habilités à générer des licences et à les expédier sur
disquettes accompagnées du CD du produit.
Les LSC sont situés à Alsbach en Allemagne (pour les régions Europe-Asie-Pacifique) et Dulles aux
USA (région Amériques).
2.3.2.1.2. Centres de support client
Les CSC, Customer Support Center, sont habilités à générer des licences "d'urgence" pour les clients
ayant un contrat de maintenance 24h/24, 7j/7, et lorsqu'il y a besoin de licences pour une autre plateforme ou version que celle demandée au départ. Les licences sont alors envoyées par email. Ils
peuvent par ailleurs effectuer des recherches sur les licences.
Les CSC sont situés à Darmstadt (Allemagne), Denver (USA), Manille (Philippines).
10
2.3.2.1.3. Partenaires
Certains partenaires habilités, tels que Altova (Autriche) et Tridion (Pays-Bas), peuvent générer des
licences pour les produits partenaires incluant une licence Tamino.
2.3.2.1.4. Corporate Information Services
Le service de l'informatique interne de Software AG, Corporate Information Services, est basé en
Allemagne. Une de ses tâches est d'assurer l'administration du portail BAE (gestion de la bonne
marche du serveur, mise en production…). CIS est le client du projet, ainsi que le maître d'ouvrage.
2.3.2.1.5. SAGF
Une équipe d'ingénieurs de la filiale française assure le développement, la maintenance et les tests,
avec accès aux serveurs de tests (identiques à ceux de production). Elle est le maître d'œuvre.
2.3.2.2. Eléments caractéristiques
2.3.2.2.1. Identifiant de licence
Les informations produits sont stockées au départ dans le Project Planning Database (PPD). Ils ont
pour principale caractéristiques le code produit (ex. INO pour Tamino), et la plate-forme (ex. WNT
pour Windows NT4).
Ces informations ainsi que d'autres renseignements (techniques, financiers) sont insérés dans
SAP/R3 qui est chargé de retourner un identifiant par type de licence : License Material Number.
2.3.2.2.2. Structure d'une licence et protection
Une licence se présente sous la forme d'un fichier XML contenant des informations sur :
-
le client à partir de SAP ;
la licence (clé unique sur 32 bits, type et aspect financier) ;
le produit et les fonctionnalités que la licence autorise.
L'intégrité d'une licence est assurée par un algorithme, appelé SAGLIC, qui calcule la clé en fonction
du contenu du fichier. Si le fichier est modifié, la clé n'est plus valide.
2.3.2.2.2.3. Environnement
R&D
Quality
Engineering
LSCs
Product
Manager
Serveur de
test LK
Dév.
SAGF
CSCs
Serveur de
prod. LK
Admin.
CIS
Tamino XML DB
Tamino XML DB
11
Légende :
CIS : Corporate Information Services
CSC : Customer Support Center
LK : License Key
LSC : Logistic Service Center
R&D : Recherche et développement
SAGF : Software AG France
XML DB : base de données XML
2.3.3. Historique du projet
L'ajout de fonctionnalités a été progressif, ce qui rend le système complexe. Fin 2002, l'ensemble des
réalisations se monte à 387 000 euros.
2.3.3.1. Développement réalisé
Le développement du projet a connu plusieurs phases importantes, et a occupé un nombre variable
d'ingénieurs : de six pendant les sept premiers mois à deux pour l'extension B2B en 2002. Les durées
incluent aussi bien la conception que la réalisation et les tests précédant la livraison.
§
§
§
§
§
§
juillet-décembre 2000 (cinq mois) : génération de licences et fonction de recherche
janvier-février 2001 (deux mois) : gestion des droits utilisateurs
mars-septembre 2001 (six mois) : gestion de templates, ajout de nouvelles méthodes de
recherche, modification de l'administration
octobre-novembre 2001 (deux mois) : ajout de la fonctionnalité de plug-ins
décembre 2001-février 2002 (trois mois) : migration de la version 2.2.1 à 3.1.1 de Tamino
mars-juin 2002 (trois mois) : extension B2B permettant aux partenaires de se servir du système
2.3.3.2. Développement prévu pour 2003
§
§
§
§
premier trimestre : fonctionnalité multi plug-ins nécessaire au passage vers Tamino 4.1
deuxième trimestre : License Key Bundle
troisième trimestre : migration de Windows NT4 à Windows 2000
quatrième trimestre : mise à jour de l'algorithme SAGLIC, migration de Bolero vers Java, nouvelle
interface de connexion avec SAP
Un budget de l'ordre de 150 000 euros est prévu pour ces tâches.
2.4. Mes missions
2.4.1. Un défi
J'ai été enthousiasmée à l'idée de relever le défi qui m'a été proposé : faire évoluer une application
d'importance stratégique, basée sur un langage de programmation proche de java, vers le standard
J2EE, en recherchant les outils les mieux adaptés pour cela. Mon travail devait servir de preuve de
faisabilité et permettre d'estimer les besoins temporels et financiers pour la migration proprement dite,
sachant que mon stage se terminait avant la budgétisation du projet, et que la conjoncture ne me
permettait pas d'être embauchée. De plus l'étude réalisée en première partie devait être générale et
applicable à d'autres projets.
2.4.2. Organisation
La majorité du travail a été réalisé de manière autonome, j'ai donc eu toute latitude pour m'organiser
au mieux. Des réunions régulières ont permis une planification des grandes étapes : étude des
frameworks, réalisation de la preuve de faisabilité, recherches annexes. Les délais étaient implicites,
ou précisés avec une marge d'une à deux semaines, sachant qu'à la fin de mon stage on devait avoir
tous les éléments décisionnels (études et réalisations), et tout avoir prévu pour soumission au client
(maître d'ouvrage).
12
J'ai eu à ma disposition :
-
-
une station de travail sous Windows NT4, sur laquelle Tamino était déjà fonctionnel. J'ai dû y
installer d'autres éléments : Bolero, Microsoft Visual Source Safe (outil de travail en collaboration),
ainsi que les outils que j'ai choisis pour mes réalisations.
la documentation technique du projet, dont le manuel utilisateur expliquant en détail le
fonctionnement. Dans la phase d'analyse de l'existant je me suis appuyée sur une lecture
méthodique du code Bolero.
Pendant le début du stage j'ai partagé durant quelques semaines un bureau avec un stagiaire qui
avait commencé en même temps que moi et était là pour 2 mois et demi. Nous avons pu nous
entraider pour la compréhension du système basé sur les servlets java, ainsi que la programmation.
2.4.3. Tâches annexes
J'ai pu aider, dans la mesure de mes moyens et en continuant ma tâche principale, à l'extension B2B :
les partenaires ont accès à l'application via web service. J'ai aidé au codage en Bolero et aux tests.
Lors de cette phase on m'a aussi demandé d'étudier des moteurs de servlets, le client devant changer
de version à cause de la plate-forme de communication XML utilisée pour le B2B, EntireX XML
Mediator. J'ai donc testé le fonctionnement de l'application existante sous divers environnements
(JRun et Tomcat). L'annexe 9.8 fait référence à cette étude.
2.4.4. Documents produits
Le corps des études et de la documentation principale du projet est directement structuré et intégré au
mémoire.
Une partie des autres documents produits, en français ou anglais, ont été intégrés dans le corps ou en
annexe, lorsqu'ils ont un intérêt pour le lecteur. Il s'agit principalement de directives d'installation et de
configuration de l'application ou de logiciels, ainsi que la comparaison de moteurs de servlets. Par
ailleurs mon développement s'accompagne de javadoc (non présentée ici).
Les éléments laissés sur le serveur Odin à disposition des futurs développeurs du projet comportent :
-
les fichiers du projet sous forme de web archive (.war);
une procédure d'installation et de configuration de l'application ;
une documentation du projet ;
un planning global ;
un planning détaillé (MS Project).
13
3. Etude de frameworks MVC
J'ai réalisé une étude qui se voulait non seulement base de mon travail mais aussi réutilisable pour
d'autres projets. Je me suis appuyée sur de nombreuses sources documentaires internet. De petits
développements tests m'ont permis de mieux appréhender certains concepts.
Cette étude présente d'abord les concepts Modèle (Model), Vue (View) et Contrôleur (Controller) ainsi
que la notion de standard J2EE. Puis les deux cadres de développements retenus, Struts et Cocoon
2, sont étudiés sur plusieurs plans :
-
pourquoi ai-je retenu ces versions ?
quels sont les éléments M, V, C de chaque framework ?
quels sont les éléments décisionnels et les éventuels problèmes posés ?
comparaison de leurs fonctions essentielles
conclusion : récapitulatif des éléments décisionnels et typologies de projets
3.1. Pourquoi un framework MVC et J2EE ?
3.1.1. Architecture MVC ou "Model 2"
3.1.1.2. Introduction
Le modèle MVC (Model-View-Controller) permet de séparer les traitements de données effectués
(Model), de ce qui correspond à ce que le client reçoit et qui est dépendant de l'interface finale
adoptée (View). La partie Controller assure la synchronisation. Ces composants sont décrits plus
précisément ci-après.
source : http://java.cnam.fr/public_html/Iagl99/dazy/UML_MVC/MVC/mvc.htm
14
L'intérêt majeur du modèle MVC réside en la facilité à construire un projet, appréhender l'existant ou
le faire évoluer, en s'appuyant sur des structures standard.
3.1.1.3. Partie Model
C'est la partie "back-end" du système, qui peut être subdivisée en concepts : l'état interne du système,
et les actions qui peuvent être entreprises pour le modifier.
Les beans ou EJBs (Enterprise Java beans) représentent cet état, et leurs propriétés les détails de cet
état. Une autre partie de cet état est souvent contenue dans des bases de données, dans ce cas les
beans réalisent l'interfaçage.
Le "business logic" ("comment cela s'effectue") est donc assuré par ces composants.
3.1.1.4. Partie Controller
Cette partie a pour rôle de recevoir les requêtes du client, de décider quelle fonction de business logic
doit être exécutée, déléguer la production de ce qui est renvoyé au client au composant View
approprié.
Il s'agit le plus souvent de servlets.
3.1.1.5. Partie View
Cette partie "front -end" gère la présentation des données et résultats envers le client. Les JSPs (Java
Server Pages) sont indiquées pour ce rôle, contenant du code HTML statique et du contenu
dynamique issu de traitements. Les servlets sont également utilisables, mais moins pratiques pour du
contenu répétitif. Une autre approche utilise des feuilles de style XSL.
3.1.1.6. Remarques
Il faut bien noter que les beans sont divisés en beans de présentation : interfaçage Controller (servlet)
et View (JSP), et en beans de traitement (accès aux données, business logic) : interfaçage entre
Controller et Model ou bien composants à part entière du Model.
3.1.2. Un framework J2EE
Le standard Java 2 Enterprise Edition J2EE simplifie le développement et le déploiement
d'applications multi-tiers :
- basé sur un ensemble de composants modulaires standards ;
- ensemble de services liés à ces composants ;
- prise en charge automatique de comportements de l'application sans besoin de programmation
complexe.
Ce type de framework présente alors de nombreux intérêts :
- intégration des APIs existantes, extensibilité facilitée ;
- modularité par intégration d'autres outils (ex. projets du groupe Apache) ;
- portabilité maximale, déploiement sur de nombreux serveurs d'application (structure en web
application, configuration "minimale" à réaliser sur les moteurs de servlets tels que JRun, Tomcat).
15
3.2. Etude de deux frameworks
3.2.1. Pourquoi Struts et Cocoon ?
3.2.1.1. Besoins
Dans le cadre de notre problématique de structuration d’applications web s’appuyant sur les
standards J2EE (extensibilité et interopérabilité accrues), il me semble intéressant de distinguer deux
approches à prendre en compte : la première est orientée composant (components), la seconde
documents. Ce découpage permet naturellement de couvrir une large gamme de projet.
Le choix a aussi été conforté par la taille du framework proposé, sa fréquence d'utilisation, la
documentation disponible (site d'origine, mailing-list d'utilisateurs, sources diverses), l'activité des
développeurs (correction de bugs, nouvelles fonctionnalités).
3.2.1.2. Décisions
3.2.1.2.1. Types de frameworks retenus
§
Le framework orienté composants qui a retenu notre attention est Struts (Apache Jakarta). Il
correspond à l'association de servlets et beans pour la partie MC, et de JSPs et beans pour la
partie présentation.
§
Le framework orienté documents est Cocoon 2 (Apache Xml). Il est modulaire et permet deux
orientations pour la partie Controller (utilisation d'eXtensible server pages, XSP, ou d'Actions).
3.2.1.2.2. Versions choisies pour ces frameworks
Les deux solutions retenues pour étude sont open-source et en évolution constante. Ce document
risque donc de perdre assez vite une partie de son intérêt, même si la maturité de ces deux
frameworks semble très bonne. Afin de mieux coller à la réalité actuelle et à venir proche, les versions
les plus avancées disponibles ont été étudiées, et j'ai étudié les versions suivantes avec date de
cessation de mise à jour du document :
-
Struts 1.1 au stade beta 1 (jusqu'à juin 2002),
Cocoon 2.1-dev (jusqu'à septembre 2002).
La version de Cocoon retenue n'est pas encore largement distribuée mais disponible via CVS, les
fonctionnalités nouvelles par rapport à la version 2.0.3 étant encore en développement. On peut donc
parler d'une version alpha tout en sachant qu'elle est parfaitement utilisable après tests en phase de
production (d'après discussions avec des utilisateurs, voir annexe 9.3.4.).
J'ai commencé l'étude et la phase de développement m'appuyant sur Cocoon 2.0.3, puis décidé
d'utiliser la version 2.1, sans garantie autre que la vigilance et l'évitement de composants connus
comme étant encore non fonctionnels. Ces composants sont évoqués plus rapidement dans l'étude,
car soumis à changements possibles.
J'aurais prévu de toute façon une migration vers la version 2.1 de Cocoon dès que possible, les
changements de structure de 2.0.3 à 2.1 n'étant pas très importants d'après les composants retenus.
Je compte sur l'activité des développeurs de la communauté jusqu'à la mise en production du projet,
afin de corriger quelques bugs. En revanche, l'évolution du projet en utilisant par exemple les XML
Forms (non finalisé en septembre 2002) suppose un développement conséquent.
J'anticipe donc assez peu au final, sans avoir de regrets en termes d'information des lecteurs de ce
document.
16
3.2.2. Struts 1.1 b1
Remarque : cette version n'est pas la version la plus récente à la clôture de ce document (décembre
2002).
3.2.2.1. Présentation
3.2.2.1.2. Déclinaison du modèle MVC
Struts a été développé pour les projets qui choisissent l'association servlets / JSPs, avec plusieurs
ambitions:
§
Ne plus utiliser les scriptlets : code java dans les JSPs, ce qui est peu lisible au milieu du code
HTML, moins facilement développable, mêle une partie du traitement à la présentation.
Ainsi des tags respectant globalement la norme d'écriture de XML sont utilisé lorsque les JSPs ont
besoin :
d'inclure des éléments issus des beans de présentation ;
d'effectuer, non pas des traitements, mais des choix plus complexes qu'une simple inclusion.
§
Faciliter la logique temporelle des séries d'appels entre le Controller et les deux autres couches,
et la séparation du contrôle des formulaires et du traitement des informations de ceux-ci.
Struts comporte donc des éléments MVC dans les trois parties :
§
§
§
Partie Controller : servlet controller, servlets de classe ActionServlet.
Partie View : JSPs incluant des tags spécifiques à Struts.
Partie Model : beans de type Action et ActionForm et beans ordinaires (business logic et
présentation).
Le graphique suivant est issu d'une présentation de Struts par Sun en décembre 2002.
17
§
Diagramme de classes :
Relation entre la partie Controller et Model, redessiné d’après : http://www106.ibm.com/developerworks/library/j-struts/?dwzone=java.
§
Diagramme de séquence :
source : http://rollerjm.free.fr/pro/Struts.html
18
3.2.2.1.3. Partie Controller
Ce rôle est assuré par une classe dérivée des servlets : ActionServlet. Un ActionServlet est
associé à un formulaire HTML (avec des tags Struts pour définir les champs) référencé par un bean
de type ActionForm.
Un ActionServlet est configuré par un ActionMapping. Cette configuration, définie dans
struts-config.xml, permet de savoir quels éléments sont associés au ActionServlet :
§
§
§
§
JSP appelante
URI (path) pour l'appeler
bean ActionForm pour contrôler un formulaire
forwards (ActionForward) pour rediriger vers une JSP ou une autre à l'issue du traitement et
suivant son résultat.
3.2.2.1.4. Partie Model
Les ActionForm permettent de contrôler les formulaires : en effet dans le cas où il ne s'agit pas d'un
simple contrôle de remplissage et de type des champs, la validation côté serveur est recommandée.
Les erreurs sont gérées par l'ajout d'objets ActionError à une liste ActionErrors(). Cette liste
est ensuite retournée à l'ActionServlet.
3.2.2.1.5. Partie View
Les tags utilisables dans les JSPs sont définis dans des taglibs. Il y a cinq famille de taglibs :
struts-bean, struts-html, struts-logic, struts-template, struts-nested.
§
§
§
§
§
struts-bean : permet, à l'instar de <JSP:useBean>, de manipuler les beans de présentation.
struts-html : permet de simplifier la création de formulaires HTML et la gestion de leurs
erreurs de remplissage en les liant à un ActionForm et un MessageResources.properties.
struts-logic : permet des évaluations logiques de propriétés de beans, suivies d'actions ou
d'insertion de code, à la place de scriptlets.
struts-template: permet d'inclure du contenu (JSP, HTML) dans une JSP, un peu comme la
directive <JSP:include>, mais en permettant de bien différencier la JSP conteneur et les JSPs
contenu.
struts-nested : permettent d'utiliser facilement les propriétés de beans imbriqués (le bean B
est une propriété du bean A), par exemple pour construire graphiquement une structure récursive
ou complexe (menu etc.).
3.2.2.1.6. Fichier de configuration
Le fichier struts-config.xml contient :
§
les mappings des actions: (section <action-mappings />) pour chaque tag <action /> . Les
attributs sont les suivants :
- type : nom de la classe Action implémentée pour ce mapping ;
- name : nom du form bean (validation de formulaire) défini par l'attribut que cette action utilise ;
- path : URI de la requête qui active la sélection de ce mapping. (nom logique) ;
- unknown : si à true, cette action est l'action par défaut de l'application ;
- validate : si à true, la méthode validate() de l'action associée à ce mapping est appelée,
c'est-à-dire qu'une validation de formulaire est effectuée ;
- forward : URI de requête vers laquelle le contrôle est passé lorsque le mapping est invoqué.
Alternative à la déclaration de l'attribut type ;
19
- input : URL de la JSP appelante, d'où le client envoie des paramètres ;
- scope : persistance du bean : session, requête, page.
§
les mappings des beans (section <form-beans />), associant un nom (name) à une classe
(type) pour chaque tag <form-bean>.
§
la déclaration de message-resources : fichier .properties contenant des messages texte qui
seront inclus par des tags <bean:message key="…"> dans une JSP.
§
la déclaration de data-sources permettant une liaison avec une base de données relationnelle.
§
la déclaration de global-forwards, mapping d'URIs valables quelles que soient l'action.
D'autre part le descripteur de déploiement de la web application : web.xml est modifié pour que les
ActionServlet soient mappés sur l'extension .do (URL d'appel) : dans la section <servletmappings /> le tag <servlet-name> a pour valeur "action" pour les ActionServlets, le tag <urlpattern> correspondant a pour valeur " *.do".
En annexe 9.2.1., un exemple de fichier de configuration.
3.2.2.2. Eléments décisionnels dans le cadre d'un projet
Certains éléments tel que ceux gérant l'accès à une base de données relationnelle, ou les DynaBeans
(beans flexibles), ne sont pas détaillés, seulement évoqués dans le tableau du 3.2.2.4.
3.2.2.2.1. Typologie du projet
Struts convient à un projet présentant une ou plusieurs des caractéristiques suivantes :
- présence de formulaires à remplir par l'utilisateur avec contrôle des types/valeurs entrés dans les
champs ;
- une partie du code qui sera retourné à l'utilisateur est statique (HTML) ;
- interaction avec une base de données relationnelles ;
- présence d'un menu avec présentation visuelle différente par niveaux (usage de struts-nested).
3.2.2.2.2. Form beans
Ils servent à la validation de formulaire côté serveur, c'est-à-dire qu'un traitement peut être effectué
avant de retourner un message d'erreur.
Les classes ActionForm permettant la vérification de formulaires retournent des objets
ActionError, qui utilisent un fichier properties pour stocker les messages retournés au client
lorsqu'une erreur est détectée. Ces messages peuvent être formatés en HTML (style local dans le
fichier .properties).
Lorsque ActionForm est défini, la méthode reset() est appelée et les données entrées dans les
champs texte du formulaire d'origine sont perdues si on renvoie à l'issue de l'action sur la JSP
d'origine. Or pour un utilisateur il semble normal de retrouver les données entrées en plus du
message d'erreur. Une solution est de conserver les données entrées en placant le ActionForm
considéré en tant qu'attribut de session et d'ôter cet attribut avant le/les forward.
3.2.2.2.3. Forwards
Ce sont des facilitations d'écriture qui associent un nom logique à une URL. Ainsi le code java ne
contient pas de nom de JSP "en dur".
Les forwards globaux (global-forwards) sont utiles pour gérer la déconnexion ou le retour à un
menu principal par exemple (scope=session, sinon scope=request).
20
Par exemple le code suivant :
servlet.getServletConfig().getServletContext().getRequestDispatcher("menu.J
SP").forward(request,response);
devient :
mapping.findForward("menu");
3.2.2.2.4. Taglibs
Leur apport est de plusieurs ordres :
-
syntaxe XML dont plus facilement gérable au niveau de la maintenance du code,
remplacent les scriptlets dans certains cas,
appel "intuitif" de propriétés d'objets java,
gestion de conditions logiques à l'intérieur d'une JSP,
nesting de beans, qui associé à un appel récursif de JSP permet de faciliter la création de menus.
3.2.2.2.5. Gestion du multilangage
Le multilangage n'est géré qu'au niveau de la présentation (vers l'utilisateur), et pas au niveau de
l'entrée des données par l'utilisateur.
Struts utilise des fichiers properties, déclarés en tant que message-resources, qui contiennent des
messages plus ou moins formatés HTML, mais il est recommandé que leur longueur soit raisonnable.
L'utilisation d'un fichier properties ou un autre (nom du fichier suffixé par un identifiant langue_PAYS
d'après les codes ISO 639 et 3166) dépend de la Locale (modifiable en tant qu'attribut de session).
3.2.2.3. Addendums
3.2.2.3.1. Model 2X, extension de la partie View
Une extension proposée par Julien Mercay et Gilbert Bouzeid peut être utilisée afin d'enrichir le format
de sortie autorisé par Struts. Un article de février 2002 explique son fonctionnement : ajout d'un
élément XSL Servlet en partie View, vers lequel le Controller (ActionServlet) redirige.
Voir annexe 9.2.3. pour plus de détails.
3.2.2.4. Conclusions - Tableau récapitulatif
Le tableau suivant récapitule les éléments et fonctions importantes de Struts.
Elément ou fonction
Rôle
form beans, ActionForm Contrôle de formulaire
(messages d'erreur
inclus dans un fichier
properties)
Avantages
Facilitation du contrôle
de champs de
formulaire
ValidatorForm
Contrôle de formulaire Facilitation du contrôle
(description du champ de champs de
dans un fichier XML en formulaire
utilisant les expressions
régulières)
ValidatorActionForm
contrôle complexe de
champ
Inconvénients
Codage du contrôle à
développer soi-même
Précautions
Ne convient pas aux
systèmes à forte charge
(un objet attribut de
session par formulaire)
Nécessite un .jar non
inclus dans la
distribution 1.1b1 :
jakarta-regexp1.2.jar, de
http://jakarta.apache.org
/regexp
21
Dynabeans
ActionServlet
Rôle
Avantages
Inconvénients
Bean dont les propriétés Pas besoin d'écrire une
sont dynamiques
classe java par bean,
possibilité de
changement de type des
propriétés
Controller
Gestion de
l'enchaînement des
actions
Forwards
Indique l'étape suivante Gestion des noms réels (JSP après action)
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
Gestion du multilangage Retour à l'utilisateur en fonction de la Locale
choisie
BasicDataSource et Accès à une base de
données relationnelle
struts datasource
manager
Principalement
taglibs <html />
encapsulation des
éléments de formulaire
en tant que propriétés
d'un bean de type
ActionForm
Précautions
Ne pas mettre de
business logic dans
cette classe
La propriété doit être de Le getter de "value" doit
type String
être obligatoirement
"getValue()"
(respect du standard
java)
limité au niveau
présentation et fichiers
properties
-
-
Confusion possible de
certains attributs avec
ceux du standard HTML
4.0 (même nom mais
pas même fonction),
rigueur nécessaire
-
-
Présence de scriptlets
possible, peut devenir
confus (morcellement)
Limiter aux cas simples,
bien commenter
Flexibilité de
configuration dans
struts-config.xml
Facilitation d'écriture,
permet le contrôle de
formulaire
Méthode POST utilisée
par défaut : paramètres
non visibles dans l'URL
Gestion de l'URL de
base HTML (réécriture
de liens, maintien de la
session client sans
cookies)
taglibs <bean />
taglibs <logic />
Utilisation des propriétés Peut remplacer les
de beans de
scriptlets
présentation
Action ou insertion de Moins de JSPs à écrire,
code conditionnelle,
flexibilité
itération
taglibs <template /> Insertion dynamique de Permet de bien séparer Equivalent dans certains JSP/HTML
la JSP conteneur et les cas à des séries de
JSPs contenu.
<JSP:include />
taglibs <nested />
Gestion de beans de
présentation imbriqués
Simplification des
relations parent-enfant
custom tags
Extension de tags à
Remplace des scriptlets
partir de
javax.servlet.JSP.
tagext.TagSupport
-
N'apparaît officiellement
que dans Struts 1.1 beta
1
Développement
supplémentaire
La fonction alors
développée manque à la
version de Struts utilisée
22
3.2.3. Cocoon 2.1-dev
3.2.3.1. Présentation
3.2.3.1.1. Déclinaison du modèle MVC
Cocoon est un framework ayant une approche orientée document, c'est-à-dire qu'une succession
d'opérations est appliquée à un fichier ou un flux XML.
Ceci est assuré par des pipelines, qui sont des
suites de :
- génération de flux XML à partir de sources
diverses ;
- transformations, par application de feuilles de
style XSL ;
- sérialisation, par rendu du document dans un
format final.
La structure de Cocoon amène le développeur à réaliser :
- une structuration du sitemap (fichier de configuration) pour la logique du site ;
- du code java pour les parties Model (business logic) et Controller (actions) ;
- des feuilles de style XSL pour la partie View.
3.2.3.1.2. Partie Model
Elle est assurée par les generators, qui produisent un flux XML à partir de :
- fichier XML ou URL (file generator) ;
- requête HTTP ordinaire (request generator) ;
- requête HTTP (POST) avec contenu au format XML (stream generator) ;
- JSP (JSP generator) ;
- XSP (serverpages generator)…
3.2.3.1.3. Partie Controller
Les selectors, matchers, actions sont les éléments assurant la partie Controller au niveau
d'un pipeline donné.
23
Si on les utilise, les pages XSP (XML Server Page) peuvent être associées à une logicsheet
(XSL) : dans ce cas la logicsheet est un élément Controller et la page XSP élément Model.
3.2.3.1.4. Partie View
Les transformers (XSLT, i18n, sql, log…) puis les serializers (XML, HTML, WML, fop, text…)
ont pour rôle d'assurer le traitement du document XML suivant la configuration définie par un pipeline
du sitemap. Ils transforment le flux d'évènements SAX en document XML (transformation) puis en
document dans un format spécifique (sérialisation). En plus de transformers prédéfinis, des feuilles de
style XSL sont aussi utilisables.
3.2.3.1.5. Fichiers de configuration
3.2.3.1.5.1. cocoon.xconf
Ce fichier définit les composants utilisés par Cocoon (parseur XML, processeur XSLT, loggers,
compilateur java, sitemap, components, gestion de la mémoire et de la recompilation…). Il sert à
l'initialisation de CocoonServlet, point de départ du lancement du framework.
3.2.3.1.5.2. sitemap.xmap
Un ou plusieurs sitemaps définissent l'enchaînement des opérations au niveau du site par pipelines. Il
y a plusieurs sitemaps si on divise l'application en parties logiques, lesquelles se retrouvent dans
l'arborescence des fichiers pour plus de clarté.
La structure XML d'un sitemap comporte les éléments suivants :
<?xml version="1.0"?>
<map:sitemap
xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<map:components/>
<map:views/>
<map:resources/>
<map:action-sets/>
<map:pipelines/>
</map:sitemap>
§
§
§
§
§
Les components sont les éléments de la partie Model (generators), Controller (selectors,
matchers, aggregators, actions…), View (transformers, serializers).
Les views permettent de définir des "vues" orthogonales aux pipelines et indépendant d'eux
(vision partielle du document, formatage spécifique).
Les resources sont des définitions de pipelines réutilisables.
Les action-sets sont des ensembles d'actions liées à une page.
Les pipelines sont des séries d'opérations associant les différents components MVC dans un
ordre défini. En annexe 9.3.2. le détail de la structure d'un pipeline.
3.2.3.1.5.3. logkit.xconf
Il gère les options d'écriture de fichiers de logs, avec définition des chemins de fichiers, catégories et
niveau de logging.
3.2.3.1.5.4. instrumentation.xconf
Apparu courant septembre 2002, ce fichier paramètre le rapport de surveillance de la charge
mémoire.
24
3.2.3.2. Eléments décisionnels dans le cadre d'un projet
3.2.3.2.1. Typologie du projet
Cocoon 2 est utilisable pour un projet présentant une ou plusieurs des caractéristiques suivantes :
- format final des données retournées au client diversifié : XML, HTML, PDF…
- présence de données déjà au format XML (facilite les choses),
- base de données XML ou relationnelle (requêtes facilitées, directement à partir du sitemap pour la
première, par les XSPs ou un transformer pour la seconde),
- présence de formulaires à remplir par l'utilisateur avec contrôle des types/valeurs entrés dans les
champs,
- ressources protégées par différents moyens d'authentification.
3.2.3.2.2. XSP et Logicsheets
3.2.3.2.2.1. XSP
Les pages XSP sont des documents XML sur lesquels une logique est appliquée, qu'elle soit intégrée
ou externe (recommandé). Dans ce dernier cas, une XSP est plus précisément au sens strict le
résultat de l'assemblage de documents XML et XSL (logicsheet).
Il y a génération de contenu dynamique par association de deux types de markup XML :
§ éléments XSP : tags de logique (xsp:logic) et de structure (xsp:structure). Ils permettent une
écriture simplifiée (déclarative) de code qui sera généré lors de la compilation (au niveau du
generator). Ces tags correspondent essentiellement à une logique intégrée.
§ élément "utilisateur", de contenu (données dans le document XML produit), avec un autre
namespace que xsp. Cet élément devient la racine du document XML produit.
D'autres tags (issus de logicsheets) permettent de remplacer dans la mesure du possible l'écriture de
fonctions (java par exemple). Ils étendent les tags XSP.
3.2.3.2.2.2. Logicsheets
Les logicsheets sont des feuilles de style XSL servant de filtres XML. Elles s'appliquent à un
document XML et trans forment des tags XML en bouts de code dans le langage de programmation
choisi (généralement java). Le résultat intermédiaire est sous forme de XSPs avec code (java) intégré.
Il existe plusieurs types de logicsheets fournies par Cocoon : accès aux données d'environnement,
"utilitaires" et accès aux données et bases de données. Ces deux dernières catégories permettent de
limiter l'écriture de code (java) par écriture déclarative.
Une logicsheet est liée à un document XSP (XML avec namespace xsp) Soit la logicsheet est
appliquée à un document XML donné par l'instruction :
<?xml-logicsheet href="logicsheet.….xsl"?>,
soit la logicsheet est built-in, déclarée dans cocoon.xconf.
25
3.2.3.2.2.3. Méthodes de création d'une XSP
Logicsheet externe
Usage de taglibs
3.2.3.2.2.4. Remarques
Si on utilise des instructions intégrées aux XSPs, elles ressemblent un peu aux JSPs (association de
code exécutable et de markup statique) mais diffèrent essentiellement par la génération de données
dynamiques et non de présentation. De plus, java n'est pas le seul langage disponible pour la partie
code.
D'après plusieurs débats récurrents (voir quelques extraits en annexe 9.3.5.) entre les utilisateurs de
Cocoon, les XSPs devraient n'être utilisées qu'avec des taglibs, sans insertion de morceaux de code
java. De même, si un projet utilise à la fois des XSPs et des Actions, comme ces éléments peuvent
jouer des rôles identiques, une certaine confusion d'architecture est possible. En effet les Actions sont
inscrites dans une logique lisible dans un pipeline du sitemap tandis que les XSPs réalisent une
logique à un moment donné.
On peut complètement se passer des XSPs dès lors qu’on utilise des Actions. Personnellement j'ai
choisi cette approche, mes développements nécessitent alors une plus grande variété de
transformers, et aussi des extensions java si je ne développe pas de transformers spécifiques à mon
application.
3.2.3.2.3. Actions
3.2.3.2.3.1. Fonctionnement
Les actions (traitement par une classe java dérivée de
org.apache.cocoon.acting.ComposerAction) ont été introduites dans Cocoon 2.0 pour mieux
respecter le modèle MVC (composant Controller).
26
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.
27
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.
28
3.2.3.3. Conclusions - Tableau récapitulatif
Le tableau suivant récapitule les éléments-clés ou fonctions de Cocoon.
Sitemap
Rôle
Avantages
Inconvénients
définition et logique des format XML
processus
décomposable en soussitemaps (un par
répertoire).
Précautions
structure assez lourde
(nombreuses sections),
quelquefois bugs lors
d'utilisation de soussitemaps et de liaisons
vers le sitemap principal.
appel direct aux bases
de données XML
peut être rechargé sans
avoir à redémarrer le
moteur de servlets en
cas de changement
Actions
Appelle et contrôle le
Persistance des
business logic,
informations de la map
renseigne un état (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
-
Matchers, selectors
Conditionnent
l'exécution d'un
fragment de pipeline en
fonction de l'URI de
requête
Possibilité d'emploi en
cascade
-
Très grande modularité
de la fonction effectuée
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
Contrôle de formulaire par expression régulière
(fichier XML) et code
java dans une XSP
Préciser le formatage
initial (date etc.) élimine
des risques d'erreur
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
Accès à une base de
données
-
API XML:DB, ou taglibs Nécessité d'utiliser les ESQL facilitant les
XSPs pour accéder aux
requêtes
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.
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
-
Entre la phase de test et
celle d'authentification
réelle, seul besoin de
modifier un handler.
29
Rôle
Avantages
Inconvénients
Précautions
Portail d'authentification Personnalisation en
Rapidité de mise en
fonction des utilisateurs œuvre
et gestion de leurs droits
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.
30
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)
Nb de nouveaux sites annoncés
Q2-01
au moins 3
Q3-01
5
Q4-01
6
Q1-02
8
Q2-02
27
Q3-02 ?
21
2
Q4-02
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
annuaire
content management system
catalogue
e-commerce (avec catalogue)
information généralis te, actualités
information corporate
information associative, éducative, scientifique (sites plus
petits que info. généraliste)
place de marché - emploi
Q2
01
1
Q3
01
1
2
Q4
01
1
1
Q1
02
1
1
Q2
02
Q3
02
Q4
02
1
4
5
1
8
8
7
1
1
2
3
3
1
1
1
4
4
? Total
1
1
2
4
2
14
2
14
20
9
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
Nb de nouveaux sites annoncés
avant juillet 2002
20
juillet-novembre 2002
6
31
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'ecommerce ou affiliés, des places de marché.
Trimestre
catalogue
e-commerce (avec catalogue)
transactionnel
information généraliste, actualités
information corporate
information associative, éducative, scientifique
(sites plus petits que info. généraliste)
e-gouvernement
place de marché – emploi, biens
avant juillet
2002
1
1
2
3
8
juillet-novembre
2002
0
3
0
1
0
Total
1
0
1
0
3
2
0
2
3
1
4
2
4
8
3.2.4.4. Conclusion – différences techniques entre les deux frameworks
Elément
Méthode et format de sortie
Gestion de la granularité de la
succession d'actions /
transformations
Flux géré par des actions
successives
Contrôle de formulaires
Struts
Taglibs dans des JSPs.
Granularité au niveau des JSPs.
HTML (tous formats avec une
extension supplémentaire)
Au niveau du code java avec
association nom logique – fichier
dans struts-config.xml
Flux créé par chaque JSP, un servlet
ne pouvant processer l'output d'un
autre servlet
Par code java spécifique
(ActionForm) ou fichiers XML
(expressions régulières)
Problème de charge possible par
utilisation d'objets de session
Cocoon
Une ou plusieurs transformations suivies d'une
sérialisation. Granularité au niveau des morceaux
de pipeline et des feuilles de style XSL.
tous formats
Centralisée au niveau du ou des sitemaps (clarté)
sitemap.xmap
Un seul flux XML (évènements SAX)
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é
Accès à une base de données
Taglibs ou actions
-
Système de portail avec gestion de
session, de l'authentification et du
rôle des utilisateurs, de ressources
-
Tous les composants MVC
Accès facilité par l'API XML:DB pour les BDDs
XML, ou ESQL pour les BDDs relationnelles
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…
32
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.
Exemples Documents
avec Cocoon
Type de projet
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
www.amalregistry.webhop.org Documents recommandée :
Catalogue
http://damocles.uc3m.es/TC
www.cupva.cbim.it
www.ccel.org
Site web d'information type
annuaire
http://dir.salon.com,
www.segelflug.de/vereine
e-gouvernement
?
www.myfloridacounty.com
Site web d'information type
portail – corporate, culturel,
politique…
www.teratext.com
www.cbossbilling.com
www.corrocean.com
Au choix
Site d'e-commerce
www.orderupdelivery.com
www.lofex.de
www.basebeans.com
www.bug-track.com
www.jcorporate.com
www.reviewalert.com
www.brittania-music.co.uk
http://shop-t-mobile.com
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
e-learning
http://zeus.fullcoll.edu/timekeeper ?
Documents recommandée en
cas de :
- forte flexibilité nécessaire au
niveau du format
- existence d'une base de
données XML
Au choix
Au choix, mais l'approc he
documents permet :
- meilleure prise d'information
à partir d'autres sites
- peut-être rapidité d'exécution
plus grande
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.
33
Besoin du projet
Struts (approche components)
Points forts
Points faibles
Format de sortie : Ecriture simplifiée de code
HTML
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
Autres formats de sortie : PDF, XML,
WML, texte…
Génération annexe
d'autres formats
Contrôle de
formulaire
Rendu final en
plusieurs langues
Cocoon (approche documents)
Points forts
Traitement direct
d'une page XML par
une feuille de style
XSL
Génère nativement
des formats diversifiés
: XML, HTML, PDF,
WML, texte…
Séparation claire du contenu du Contrôle par code java ou Contrôle par code java
formulaire, du message à
expression régulière (un si nécessaire en plus
renvoyer en cas d'erreur, du
choix par formulaire).
d'expression régulière
code de contrôle
Problème de charge
Autres solutions :
mémoire possible si
Form Validator,
nombreux formulaires
XForms
(attributs de session)
-
Un fichier properties par locale Messages peu structurés
Dans la version 2.0.3
un seul dictionnaire est
supporté, mais il existe
un outil de
concaténation de
dictionnaires
Messages structurés
dans un dictionnaire
XML
Traduction très
granulaire possible
Accès LDAP
Points faibles
-
-
-
Accès à une base Le composant Controller peut Performance non
de données
accéder à une base de données optimisée pour ce
relationnelle de manière
composant
facilitée par
BasicDataSource
(configuration flexible)
Une partie du code de
contrôle peut être
mêlée au contenu du
formulaire (XSP) pour
la première solution
LDAP Transformer :
tags simplifiant
l'écriture des fonctions
LDAP
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 Grâce aux Application
parallèle
Modules
-
Nécessite beaucoup de
Facilité par :
coordination et de rigueur - 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 strutsnested à 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.
34
De même, pour Cocoon, de nouveaux transformers sont disponibles et stables dans la version 2.1dev. Il y a quelques autres fonctionnalités intéressantes, pas forcément finalisées (globalparameters 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).
35
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.
36
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 celleci soit réalisable rapidement et de manière fiable.
37
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.
38
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.
39
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.
40
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).
41
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.
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 ;
42
- 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 clientserveur : 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.
43
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.
44
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"/>.
§
e
Pour l'usage de input modules (voir 2 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>
45
<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 :
46
§
§
§
§
§
§
<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, authprotect, ainsi que de contrôle de l'état logué : auth-loggedIn, et de déconnexion : authlogout.
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.
47
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: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.
48
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.
(1)
Les tags notés 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)
<role> … </role>
(1)
(1)
<data>
<company> … </company>
<or_lang> … </or_lang>
par commodité, on prendra l'UID de l'utilisateur LDAP,
comme cet identifiant est unique
utilisé dans le cadre du portail mais pas de
l'authentification seule (cas présent)
informations complémentaires
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)
49
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
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.
50
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 soussitemaps 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.
51
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 soussitemap (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.
52
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 ;
(1)
- 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) .
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
seulement par XML Spy Suite 5.0.
(1)
, satisfaits
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.1. Edition
- syntaxe en couleurs et éditeur personnalisable (formatage de code) ;
(3)
- proposition de correction orthographique
;
- proposition de méthodes applicables à un objet lors de la frappe ;
(3)
- 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" ;
- refactoring (modification de structure globale, gestion d'erreurs, variables…) de code existant
- optimisation des importations ;
(3)
- prévisualisation de refactoring
;
(3)
- rapidité de réactivité de l'interface de même ordre que celle du système d'exploitation .
(1)
;
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
(1)
locales…), de tests de performance (JUnit)
;
- compilation automatique lors de la sauvegarde de code ;
53
- 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
(1)
UML…) ;
- intégration avec Ant, d'Apache (outil open source permettant de personnaliser la compilation d'un
(2)
projet suivant l'environnement, basé sur un fichier XML)
;
- intégration d'un décompilateur spécifique.
4.5.2.1.4. Déploiement
(1, 4)
- structuration du projet en web application
,
- création d'archive web .war personnalisable (exclusions de fichiers…) qui sera déployée simplement
(1)
par la suite ,
4.5.2.1.5. Documentation
- simplicité relative de configuration,
(1)
- création automatique de javadoc ,
- facilité à trouver des solutions aux problèmes (documentation, forums spécifiques).
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)
(4)
: satisfait par Eclipse 2.0 seulement (version de base),
: 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).
§ 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 WEBINF\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é.
54
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.
- 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,
(1)
- support de web services ,
(1)
- load balancing .
(1)
Tomcat 4.0 / 4.1 satisfaits les points énoncés ci-dessus sauf ceux notés . 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.
§
§
§
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.
55
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é.
56
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.
57
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 Cumul
(jour) (jours)
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
1
d'authentification de Cocoon (déjà réalisé)
4
4.1
Default generation listes déroulantes produits
1,5
(déjà réalisé)
et plate-formes
5,5
4.2
affichage liste de produits
1,5
avec version
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
tâches 5.1 à 5.11
similaires à 4.1 à 4.11
1
6.1
6.7
Free generation
0,3
tâches 6.1 à 6.6 similaires
Mass generation à 4.1 à 4.11
0,5
page de téléchargement
et création de fichier zip
0,5
18,8
19,3
Dépendance
(doit être fait
après la tâche)
Remarques sur la
réutilisation
3
4.1
Essentiellement
modifications de requête
Tamino (paramètre "free"),
feuilles de style peu ou pas
modifiées
4.1
Essentiellement
modifications de requête
Tamino (paramètre "free"),
modifications variables des
feuilles de style
19,8
58
Code tâche
élémentaire
7.1
Fonction de
l'application
Tracking de
licence
formulaire de recherche
Temps Cumul
(jour) (jours)
0,7
Dépendance
(doit être fait
après la tâche)
Remarques sur la
réutilisation
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
0
22,1
7.1
0,1
22,2
4.6
0,5
22,7
0,1
22,8
4.6
0
22,8
7.1
10.2
listes de licences
trouvées
0
22,8
7.2
10.3
affichage des
informations de licence
0
22,8
4.6
10.4
annulation de licence +
affichage du résultat
0,2
23
4.6
affichage de liste
1,5
24,5
8.1
Interactive Query formulaire de recherche
8.2
9.1
Command-line
Query
9.2
10.1
11.1
Annulation /
réactivation de
licence
License set
management
formulaire de modification
1,5
+ action
26
formulaire d'ajout + action 0,5
26,5
11.2
affichage de liste
27,5
11.1*
28
11.2*
feuille de style et action peu
changées
affichage de liste
28,5
12.1*
changées
29
12.2*
liste déroulante de
recherche
0,1
29,1
4.1
14.2
affichage de résultats de
recherche
1,5
30,6
14.3
1,5
+ action
32,1
14.4
32,3
14.3
0,5
32,8
12.1*
15.2
0,5
+ action
33,3
12.2*
15.3
33,5
15.2
affichage de liste
34
12.1*
34,5
12.2*
11.2
11.3
12.1
Platform
management
12.2
13.1
Product Family
Management
13.2
14.1
15.1
16.1
Product
Management
Plug Management affichage de liste
Plug Type
Management
16.2
17.1
1
0,5
0,5
formulaire de modification 0,5
changées
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
affichage de liste
1
39,5
12.1*
18.1
Plug Assignment formulaire de sélection
Template
changées
changées
59
Code tâche
élémentaire
Fonction de
l'application
Temps Cumul
(jour) (jours)
Dépendance
(doit être fait
après la tâche)
Remarques sur la
réutilisation
Management
18.2
formulaire présentant les
3
informations du template
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
page de choix
0,2
49,2
affichage du résultat
0,2
49,4
page d'entrée utilisateur
0,1
49,5
action de mise à jour
1
50,5
page d'entrée utilisateur
0,1
50,6
action de mise à jour
0,5
51,1
21.1, 20.2
page de login et action de
0,5
login LDAP
51,6
2
53,1
2, 22.1
19.1
Statistiques de
licences
19.2
20.1
Modification du
mot de passe
20.2
21.1
Modification de
l'email
21.2
22.1
Gestion de
partenaires et
utilisateurs
22.2
23
Aide en ligne
24
Bug report
pages de choix + action
1,5
de mise à jour
page principale (table des
matières) + statique
0,5
HTML
formulaire + action
0,5
19.2
20.1
53,6
54,1
4.7.1.4. Charge, délai, gestion de projet
NB : j-h : jour-homme.
Formation Cocoon et XSL
Développement global à réaliser
Intégration et tests finaux (20% du dév.)
Supplément documentaire global (20% du dév.)
Marge de 5% du développement
5 jours au plus par personne
37.5 j-h
7.5 j-h
7.5 j-h
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 :
Développement global
Total développement et intégration
Gestion de projet
19 jours
4 jours
4 jours
2 jours
29 jours
6.5 jours
60
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 :
Développement global
Total développement et intégration
Gestion de projet
12.5 jours
2.5 jours
2.5 jours
1 jour
18.5 jours
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
VSR
15 jours
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
61
17.2 Plug ass.
12 hr
17.3 plug ass.
12 hr
développeur 2
100 hr
18.1 Template mgt
8 hr
18.2 Template mgt
24 hr
18.3 Template mgt
16 hr
18.4 Template mgt
12 hr
18.5 Template mgt
12 hr
18.6 Template mgt
12 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
62
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'il 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).
63
§
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.
64
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).
65
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,
66
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.
67
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.
68
5.1.4.2. Licences X : BSD, révision 1999
§
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.
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
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.
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.
69
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
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.
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.
70
§
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.
71
§
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
x
x
x
x
x
x
x
x
GPL
LGPL
BSD
NPL
MPL
x
x
x
x
x
x
x
x
SISSL
x
x
CPL
Apache
Domaine
public
x
x
x
x
Privilèges particuliers pour le
détenteur du copyright, qui
peuvent s'appliquer à vos
modifications
compatible NPL
compatible MPL
avec limitations
selon le cas
éventuelles
clairement indiquées
si pas de distribution
compatible CPL
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.
72
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 demimillion 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.
73
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
Droits
usage
Mutualisation des développements
sous le contrôle de l'éditeur, choix
des évolutions par l'éditeur
Garanties
clause de non-garantie. Toute
garantie est liée à un surcoût
Mise en concurrence du support
technique
éditeur
Administration
démarches administratives liées aux
licences
la taille du parc est un élément
décisionnel
Interopérabilité
Logiciel libre
maîtrise plus large
sous le contrôle de la communauté,
choix des évolutions par les
utilisateurs
non garantie. obtenue de manière
contractuelle après avoir fait jouer la
concurrence
différentes sociétés
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…
74
§
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.
75
§
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.
76
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.
77
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
red hat
mandrake
debian
slackware
s.u.s.e
diy
conectiva
others
Nombre
31569
20232
14273
12763
12354
1438
1402
13920
Pourcentage
29.65
19.00
13.41
11.99
11.60
1.35
1.32
13.07
Usages
But
workstation
programming
learning
www server
toy
ftp server
file server
firewall
mail server
router
dns server
other server
Others
Nombre
64201
45562
40933
35056
28737
26442
25950
24935
24434
19072
18862
16817
13103
Pourcentage
61.16
43.41
39.00
33.40
27.38
25.19
24.72
23.75
23.28
18.17
17.97
16.02
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.
78
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.
79
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
Système d'exploitation de serveur
Serveur d'application web
Test de déploiement d'application
Système d'exploitation de station de travail
Email, messagerie, collaboration
Gestion de réseau
Gestion de bases de données
Sécurité réseau
Gestion de stocks
E-commerce
Autres
Aucun
65%
63%
45%
45%
38%
30%
25%
25%
25%
10%
10%
8%
28%
80
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…) ;
81
- 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'egouvernement
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.
82
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.
83
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.
84
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 euxmê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.
85
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éveloppeurinté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.
86
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
Les distributeurs s'appuient sur des VARs
Points faibles du modèle
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
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.
87
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
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.
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
§
§
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.
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
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.
88
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.
89
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
Réduction du temps de développement ou intégration
Réduction des coûts de maintenance
Meilleure qualité logicielle
Possibilité d'adapter et réutiliser le code
Mises à jour et patches sans délai
93%
72%
52%
45%
45%
34%
90
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 ;
91
- 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.
92
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.
93
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.
94
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.
95
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.
96
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.
97
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
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 soustraiter 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'ecommerce.
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.
98
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
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.
99
§
§
§
§
§
§
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.
100
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
101
§
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
102
§
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://www1.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
103
§
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
104
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
105
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
106
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>
107
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.
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
108
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="simpleform" 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">
109
<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>
<!-The different pipeline implementations -->
<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"/>
110
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="getxml">
<map:act type="auth-protect">
<map:parameter name="handler" value="baepphandler"/>
<map:generate src="xml/getxml.xml"/>
<map:transform type="session"/>
</map:act>
</map:match>
<map:match pattern="getcheckedplugs">
<map:generate type="request"/>
<map:transform src="xsl/checkedplugs.xsl"/>
</map:match>

<map:match pattern="httprequest">
<map:generate type="request"/>
<map:transform src="xsl/copy.xsl"/>
<!-<map:transform type="log">
<map:parameter name="logfile"
value="logs/httprequest.log"/>
</map:transform>-->
</map:match>

<map:match pattern="getdescriptor/*">
<map:generate src="cocoon://ino/template/{1}"/>
<map:transform src="xsl/formvaldesc_genlickey.xsl"/>
</map:match>

</map:pipeline>

<map:pipeline>

<map:match pattern="tamino/**">
<map:generate src="cocoon://ino/{1}"/>
</map:match>
</map:pipeline>
<map:pipeline>

<map:match pattern="mlform">
111
<map:generate src="xml/mlForm.xml"/>
<map:transform src="xsl/copy.xsl"/>
</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: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:match>

<map:match pattern="menu">

<map:part element="mlmenu"
src="cocoon://ino/mlMenu"/>
<map:part element="session" src="xml/getxml.xml"/>
</map:aggregate>
<map:transform src="xsl/menu_rights_1.xsl"/>
<map:transform src="xsl/menu_main.xsl"/>
</map:act>
</map:match>
112

<map:match pattern="defaultgeneration">
<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 src="xsl/familiesandplatforms.xsl">
<map:parameter name="free" value="0"/>

</map:transform>
</map:act>
</map:match>

<map:match pattern="defaultgen">



<map:select type="request-parameter">
<map:parameter name="parameter-name"
value="platform"/>

<map:when test="All">
<map:select type="requestparameter">
<map:parameter
name="parameter-name" value="family"/>

<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
<map:part
element="lickeymat" src="cocoon://ino/all_platforms_a_family/{../family}"/>
<map:part
<map:part
</map:aggregate>
</map:otherwise>

</map:select>

</map:when>
113

<map:otherwise>
<map:select type="requestparameter">
<map:parameter
name="parameter-name" value="family"/>

<map:aggregate
element="page">
<map:part
<map:part
element="lickeymat" src="cocoon://ino/all_families_a_platform/{../platform}"/>
<map:part
<map:part
</map:aggregate>

</map:when>

<map:otherwise>
<map:aggregate
element="page">
<map:part
<map:part
element="lickeymat" src="cocoon://ino/a_family_a_platform/{../family}/{../platform}"/>
<map:part
<map:part
</map:aggregate>
</map:otherwise>

</map:select>
</map:otherwise>
</map:select>

<map:transform src="xsl/lkgproductcatalog.xsl">
<map:parameter name="free" value="0"/>
<map:parameter name="xnodeupgrade"
value=""/>
</map:transform>
</map:act>

</map:act>
</map:match>

<map:match pattern="defaultgenerationcheckplug">
<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}']"/>

value="Plugging[@product='{../../licKeyMat}' and @version='{../../version}']/Pluggs/Plug"/>
<map:part element="mlform"
src="cocoon://mlform"/>
<map:part element="plugging"
src="cocoon://ino/plugging/{../../../licKeyMat}/{../../../version}"/>
114
<map:part element="plug"
src="cocoon://ino/Plug"/>
<map:part element="session"
src="xml/getxml.xml"/>
</map:aggregate>
<map:transform
src="xsl/genliccheckplug.xsl">
<map:parameter name="userequest-parameters" value="true"/>
</map:transform>
</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>

<!-Create form validation descriptor
from template (tamino query)
then try to validate form.
If form validation fails generate form, if success
generate licence and license info form.
-->
<map:match pattern="defaultgenerationform2fill">



<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"
<map:aggregate
element="page">
<map:part
element="template" src="cocoon://ino/template/{../../../../template}"/>
<map:part
element="reqparam" src="cocoon://httprequest"/>
<map:part
</map:aggregate>
<map:transform
type="session"/>

<map:transform
src="xsl/genlickey.xsl">
<map:parameter
name="use-request-parameters" value="true"/>
115
<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"
<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:act>

<map:redirect-to
uri="error?code=422003"/>
</map:act>

<map:part element="template"
src="cocoon://ino/template/{../../template}"/>
<map:part element="lickeymat"
src="cocoon://ino/lickeymat/{../../licKeyMat}/{../../version}"/>
src="cocoon://ino/{../../licKeyMat}/{../../version}"/>
<map:part element="checked"
src="cocoon://getcheckedplugs"/>
</map:aggregate>

<map:transform
src="xsl/genlicform2fill.xsl">
<map:parameter name="use-requestparameters" value="true"/>
</map:transform>

<map:transform type="simple-form"/>
</map:act>

<map:part element="template"
src="cocoon://ino/template/{../template}"/>
116
<map:part element="lickeymat"
src="cocoon://ino/lickeymat/{../licKeyMat}/{../version}"/>
src="cocoon://ino/{../licKeyMat}/{../version}"/>
<map:part element="checked"
src="cocoon://getcheckedplugs"/>
</map:aggregate>

<map:transform src="xsl/genlicform2fill.xsl">
</map:transform>
</map:act>
</map:act>
</map:match>

<map:match pattern="showlicense">
<map:part element="license"
src="cocoon://ino/licenseinfo/{../serialNumber}"/>
</map:aggregate>

<map:transform src="xsl/filledlicense.xsl"/>
</map:act>
</map:act>
</map:match>

<map:match pattern="licensecard">
<map:generate
<map:transform src="xsl/htmlcard.xsl"/>
</map:act>
</map:act>
</map:match>

<map:match pattern="downloadlicense">

</map:aggregate>
117
<map:transform src="xsl/dllicense.xsl">
</map:transform>
</map:act>
</map:act>
</map:match>

<map:match pattern="sendlicense">

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

src="cocoon://ino/licenseinfo/{../../serialNumber}"/>
</map:aggregate>
<map:transform
src="xsl/sendlickeyform.xsl">
118
</map:transform>
</map:act>


<map:part element="write"
src="cocoon://writelicense?serialNumber={../serialNumber}"/>

<map:part element="htmlbody"
src="cocoon://writehtmlbody?serialNumber={../serialNumber}"/>
</map:aggregate>
<map:transform src="xsl/sendlickeyform.xsl">
</map:transform>
</map:act>
</map:act>
</map:match>

<map:match pattern="cancellicense">

</map:act>
</map:act>
</map:match>

<map:match pattern="reactivatelicense">

</map:act>
</map:act>
</map:match>

<map:match pattern="writehtmlbody">
<map:generate
<map:transform
src="xsl/writelicensehtmlbody.xsl"/>
<map:transform type="write-source">
<map:parameter name="serializer"
value="html"/>
</map:transform>
119
</map:act>
</map:act>
</map:match>

<map:match pattern="getlicense">

value="License_Info[@serialNumber='{../serialNumber}']"/>
<map:generate
src="cocoon://ino/licenseinfo/{../../serialNumber}"/>
<map:transform src="xsl/cleanxml.xsl"/>
</map:act>

<map:redirect-to uri="error?code=321002"/>
</map:act>
</map:act>
</map:match>

<map:match pattern="getpdflicense">
<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:generate
src="cocoon://getlicense?serialNumber={../serialNumber}"/>
<map:transform src="xsl/writeandkeep.xsl">
</map:transform>
value="xml"/>
</map:transform>
<map:transform src="xsl/writeandpdfcard.xsl"/>
value="fo2pdf"/>
</map:transform>
</map:act>
</map:act>
</map:match>

<map:match pattern="disconnect">
<map:act type="auth-logout">
<map:redirect-to uri="login"/>
</map:act>
</map:match>

<map:match pattern="error">
120
<map:part element="error"
src="cocoon://ino/error/{../code}"/>
<map:part element="label"
src="cocoon://ino/mlForm/label[@ident='lkscBack']"/>
</map:aggregate>
<map:transform src="xsl/errorpage.xsl">
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: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: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>
121
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
map:mount
map:redirect-to
map:call
map:parameter
Selects pipeline processing depending on selecting
Mounts a sub sitemap
Redirects to a another URI
Goto another pipeline fragment
Defines additional parameters for the sitemap components
map:act
Peform action processing
map:generate
map:aggregate, map:part
map:transform
Defines the generation step
Defines an alternate generation step by mergine pipelines
Defines zero or more transformation steps
map:serialize
map:handle-errors
Defines the final serialization s tep
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 :
122
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 mixand-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.
123
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
124
§
Menu principal (ancienne version)
§
Menu principal (nouvelle version)
125
§
Choix de famille de produits et plate-forme
126
§
Formulaire de génération de licence
§
Formulaire d'envoi de licence par email
127
§
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)
b
baepp
Session
Informations de session
b
"
Config
b:@p
"
TaminoXqlAccess
Contient des définitions de
m
constantes en liaison avec un
fichier properties
Requête x-query sur Tamino
m
?
s
"
Authentication
Login, authentification LDAP
-
s
baepp.
administration
AdminUser
AdminMenu
s
"
AdminPartner
Affiche un formulaire
v
permettant d'entrer les
informations d'un nouvel
utilisateur à entrer dans LDAP
v
permettant d'entrer les
informations d'un nouveau
groupe d'utilisateurs à entrer
dans LDAP
s
"
AdminMenu
Affiche le menu principal
c -v
d'administration LDAP : menus
déroulants de groupes et
utilisateurs, avec actions
possibles sur chaque item
LdapAuthenticati
on
m
m- c
Commentaire
utilisé pour
test, non utile
au projet
AdminMenu
128
Type
Package
Classe (nom court)
Model
(m),
Appelée par
Controller (principale (c) ou
ment)
View (v)
Invalide la session et renvoie à c
Nombreux
la page d'accueil
servlets
Affiche une page HTML
v
d'erreur : le détail est récupéré
dans Tamino d'après un code
(paramètre)
Fonction
Commentaire
s
"
Disconnect
b:@p
"
HTMLError
s
"
LdapLogin
Construit la page de login
administrateur
v
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
v
MainMenu
s
"
LdapAuthentication
Affiche le formulaire
permettant à l'utilisateur de
modifier son email
Gère le login administrateur
(authentifie)
m
LdapLogin
s
"
ModifyPassword
v
permettant à l'utilisateur de
modifier son mot de passe de
login dans l'application
MainMenu
s
"
ModifyUser
v
permettant la modification des
informations d'un utilisateur
LDAP
AdminMenu
s
"
ModifyPartner
AdminMenu
s
"
RemovePartner
v
permettant la modification des
informations relatives à un
groupe d'utilisateurs LDAP
Supprime un groupe LDAP
c
s
"
RemoveUser
Supprime un utilisateur LDAP c
AdminMenu
s
"
SapToTamino
Initialise la base de données et c - v
affiche un message d'erreur ou
succès
MainMenu
s
"
SavePartner
Met à jour les informations de c
groupe dans LDAP
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 c
groupe dans LDAP
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
m– v
code java
importé
b
"
LdapEntry
m
b:@p
"
TaminoAccess
code java
importé
code java
importé
s
baepp.
administration.
bugReport
BugReport
Effectue les opérations de
modification sur les groupes et
utilisateurs LDAP (login
administrateur), récupère une
liste de groupes ou utilisateurs
Effectue des opérations sur un
vecteur de données LDAP
Récupère dans Tamino les
document décrivant les droits
d'accès
Affiche un formulaire (méthode
GET) et appelle une méthode
d'envoi d'email (méthode
POST)
MainMenu
AdminMenu
m
c -v
MainMenu
Par défaut
GET est utilisé
129
Type
Package
Classe (nom court)
Model
(m),
Appelée par
ment)
View (v)
Affiche le menu permettant de c - v
InitMlManagegérer le multilangage de
ment + autres
l'application, choix de modifier
les informations puis de les
MainMenu à
valider (mise à jour dans
partir du menu
Tamino)
Administration ?
Fonction
s
baepp.
administration.
Multilanguage
MlManagement
b
s
"
"
Description
DisplayLabel
s
"
InitMlManagement
b
"
MlLabel
Contient les données du label m
s
"
AddLanguage
MlManagement
s
"
MlManagementMenu
Modifie un document XML issu m
de Tamino (mlForm), le met à
jour et le remet dans Tamino
Affiche le menu permettant de v
gérer le multilangage de
l'application
s
"
RemoveLanguage
Modifie un document XML issu m
de Tamino (mlForm), le met à
jour et le remet dans Tamino
MlManagement
b
"
SearchInfo
Contient des données
s
"
UpdateMlForm
Met à jour une liste d'éléments m
puis renvoie vers
MlManagement
MlManagement
s
"
UpdateXmlInTamino
MlManagement
s
baepp.boxSales.gui
OrderList
Met à jour un document
m
mlForm récupéré de Tamino et
le remet dans Tamino
Affiche l'état d'un ordre SAP
m- v
s
"
Catalog
Affiche le catalogue des
produits disponibles
Nombreux
servlets
s
"
ConfirmOrder
Récapitule le shopping cart,
c -v
crée un ordre SAP, envoie un
email de confirmation
MakeOrder
s
"
LoadSave
Récupère un shopping cart ou m
le sauvegarde dans Tamino
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
s
"
"
AddPosition
ProductForm
Ajoute un élément à SAP
m
Affiche le formulaire SAP d'un m - v
produit
ProductForm
Catalog
s
"
RemoveOrderItem
Efface un élément du shopping m - c
cart
ShoppingCart
s
"
SalesOrderToXML
Retourne au format XML
l'ordre d'achat
m- v
?
s
"
ShoppingCart
Affiche le shopping cart
m- v
s
"
UpdateSalesOrder
Met à jour l'ordre d'achat
m
Catalog,
MakeOrder,
ConfirmOrder,
LoadSave,
RemoveOrderIte
m
ShoppingCart
Contient du texte
Gère la récupération des
labels
Supprime des attrbuts de
session
m
m
c
Commentaire
Certains
servlets
updatent les
informations
dans Tamino,
d'autres
renvoient vers
un autre
servlet qui
exécute cette
tâche
MlManagement
MlManagement,
UpdateXmlInTam
ino
InitMlManageme
nt,
AddLanguage,
RemoveLanguag
e
m
m– v
OrderListCriteria
renommer en
SalesOrderTo
Xml
130
Type
b
b
Package
Classe (nom court)
Fonction
baepp.boxSales.order MaterialLicenseType Formate un document XML
Management
<materialLicenseType />
"
MaterialPricingItem Formate un document XML
<materialPricingItem />
Model
(m),
Controller
(c) ou
View (v)
m
"
MaterialPricingQuant Formate un document XML
ity
<materialPricingQuantity />
m
b
"
MaterialPricingUnit Formate un document XML
<materialPricingUnit />
m
b
"
MaterialVersion
Formate un document XML
<materialPricingVersion />
m
b
"
OrderItem
<orderItem />
m
b
"
OrderItemIn
orderItemIn />
m
OrderItemOut
<orderItemOut />
b
"
OrderPartner
<orderPrtner />
m
b
"
Pricing
<pricing />
m
b
"
SalesItem
<salesItem />
m
b
"
SalesOrder
m
b
"
b
"
b
"
b
baepp.ldap
<salesOrder/>
SalesOrderEventHandl Vérifie la structure du
er
document XML
Total
<total />
VatAmount
<vatAmount/>
LdapUser
Gère le login, récupère des
informations utilisateur
b
"
LdapAccess
m
b
baepp.
licenseKey
AppControlledValue
Construit le document XML
représentant les données
utilisateur : groupe
s
"
ChangeStatusLicKey
Change le statut d'une licence c
b
"
Counter
Gère l'unicité des numéros de m
licences
s
"
DefaultGeneration
Affiche le catalogue de
produits
s
"
FreeGeneration
Affiche le catalogue de
produits
s
"
GenLicKey
Génère une licence, l'insère
dans Tamino puis l'affiche
Commentaire
m
b
b
Appelée par
(principale ment)
m
m
m
m
m– v
?
Redondance
avec
LicKeyCancel
c -v
MainMenu
c–v
MainMenu
Code HTML
produit par
LicKeyTools
Identique à
DefaultGenera
tion mais la
variable free a
la valeur 1 au
lieu de 0.
m- v
Code HTML
produit par
LicKeyTools
LicKeyForm
Code HTML
(LicKeyTools.upg produit par
radeXNode),
LicKeyTools
LicenseLineDetai (displayLicKey
l
et
displayMassLi
cKey)
131
Type
Package
Classe (nom court)
Model
(m),
Appelée par
ment)
View (v)
Change le statut d'une licence. c - v
retour arrire :
LicenseListCriteri
a avec cancel 1.
(LicKeyTools.dis
playLicKey)
Fonction
Commentaire
s
"
LicKeyCancel
s
"
LicKeyCard
Affiche une carte de licence
s
"
LicKeyCatalog
Affiche une liste de produits en m - v
fonction de la famille de
produits et de la plate-forme
choisies
s
"
LicKeyDownload
Crée un fichier zip d'une
m- v
licence et affiche un lien sur ce
fichier
s
"
LicKeyForm
c -v
correspondant à la génération
de licence (défaut, free, en
masse)
LicKeyCatalog,
LicKeyTools
(searchSN)
s
"
LicKeyHTMLMail
Crée un fichier XML, affiche un m - v
formulaire d'envoi de licence
par email (POST) et envoi
l'email (GET)
GenLicKey
renommer en
(LicKeyTools.dis LicKeyHtmlMa
playLicKey)
il
s
"
LicKeyMailing
Crée un fichier XML, affiche un c - v
formulaire d'envoi de licence
par email
LicKeyTools.displ Redondant
ayLicKey (non
avec
utilise),
LicKeyHTMLM
LicenseLineDetai ail, champs
l,
supplémentair
es
s
"
LicKeyMenu
Affiche un menu
c -v
?
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
-
v
Redondance
avec
ChangeStatus
LicKey
GenLicKey
(LicKeyTools.dis
playLicKey)
DefaultGeneratio
n,
FreeGeneration
(LicKeyTools.sel
ectCatalog)
GenLicKey
(LicKeyTools.dis
playLicKey),
LicenseLineDetai
l
Code HTML
produit par
LicKeyTools
Non utilisé
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 à
DefaultGenera
tion mais la
variable free a
la valeur 2 au
lieu de 0.
Code HTML
produit par
LicKeyTools
b
"
ParamRegistSheet
v
132
Type
Package
Classe (nom court)
Fonction
Model
(m),
Appelée par Commentaire
ment)
View (v)
m- v
LicenseLineDetai
l
s
"
RegistrationSheet
Affiche une page avec des
données à compléter par le
client s'il veut enregistrer son
produit (imprimé)
b
s
"
"
RequestParam
SearchCatalog
v
v
?
non utilisé
s
"
SearchSNForm
Recherche une licence
m
?
non utilisé
s
baepp.
licenseKey.b2b
PartnerGetLicense
Récupère une licence (requête m - c
Tamino) et l'affiche ou l'envoie
b:@p
"
PartnerGetLicenseOut Gère le formatage et l'écriture m
put
d'un fichier
s
"
B2BTracking
Récupère des licences
c
(requête Tamino) et les affiche
ou envoie
b:@p
s
"
"
B2BTrackingOutput
PartnerGeneration
Recherche des licences
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
m
c
b
"
PartnerGenLicKey
Génère des licences
m
b
"
PartnerLicKeyMail
Crée un fichier XML, envoie un m
email
s
"
B2BQuery
Récupère des licences
c
(requête Tamino) et les affiche
ou envoie
b:@p
b
"
"
B2BQueryOutput
MyException
Recherche des licences
s
baepp.
licenseKey.
administration
CatalogEditing
s
"
CatalogMgt
b:@p
"
Component
Modifie les produits du
m
catalogue en fonction des
paramètres de la requête http
Récupération du catalogue
m- v
(requêtes Tamino) et affichage
Modification d'XML
m
b:@p
"
ConvertFormat
Modification de chaîne de
texte, parsing d'XML
b
"
ConvertXLS
Modification de données pour m
écriture de fichier au format
CSV
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 platesformes
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
s
"
PlugEditing
Modifie un plugin et un produit m v
et affiche le résultat
MainMenu,
PlugAssignEditin
g
PlugMgt
lien externe
lien externe
lien externe
lien externe
m
m
Sous-classe
de Exception
mais ne fait
rien de
particulier
CatalogMgt
LicKeyTools,
CatalogEditing
m
Ne sera plus
utilisé (format
CSV
abandonné)
133
Type
Package
Classe (nom court)
Fonction
Model
(m),
Appelée par Commentaire
ment)
View (v)
mv
PlugAssignment
s
"
PlugListing
Affiche la liste des plugins
s
"
PlugMgt
Affiche un formulaire de
gestion des plugins
s
"
PlugTypeEditing
PlugTypeMgt
s
"
PlugTypeMgt
Modifie les informations d'un m v
plugin, met à jour dans Tamino
et affiche un formulaire html
(résultat)
Affiche la liste des plugins
cv
s
"
ProdListing
Liste les produits
LicSetMgt,
TempMgt
s
"
s
"
s
"
ProductFamilyEditing Modifie les informations d'une m v
famille de produits, met à jour
dans Tamino et affiche un
formulaire html (résultat)
ProductFamilyMgt
Affiche la liste des familles de c v
produits
RepStatsCmdLineOutpu Exécute une requête Tamino m - v
t
(<License_Info/>), écrit un
fichier XML et CSV, affiche
une page avec liens sur ces
fichiers
s
"
RepStatsCmdLineQry
s
"
RepStatsCriteria
s
"
RepStatsOutput
b:@p
"
b:@p
c-v
v
MainMenu
MainMenu
ProductFamilyMg
t
MainMenu
RepStatsCmdLin
eQry
recherche de licence
(command-line query)
recherche de licence
(interactive query)
Exécute une requête Tamino
(<License_Info/>), écrit un
fichier XML et CSV, affiche
une page avec liens sur ces
fichiers
v
MainMenu
v
MainMenu
m- v
RepStatsCriteria
Tag
<Tag/>
m
"
Template
<Template/>
m
s
"
TemplateEditing
Edite un template et affiche le c - v
résultat
b
"
TemplateToTamino
Met à jour un template dans
Tamino
m
s
"
TempMgt
Affiche une liste de templates
v
s
s
"
baepp.
licenseKey.
licenseTracking
VersionListing
Affiche les versions de produit v
LicenseListCriteria Affiche un formulaire de
c -v
recherche de licence –
paramètre cancel à 0 pour
recherche, à 1 pour gestion de
statut de licence
s
"
LicenseListXSL
Affiche le résultat de recherche c -v
de licence, avec paramètre de
request cancel à 0 ou 1
LicenceListCriteri renommer en
a,
LicenseListXsl
PartnerGetLicens
e
s
"
LicenseLineDetail
Affiche le détail d'une licence
?
v
TempMgt
MainMenu
PlugAssignment
MainMenu,
LicKeyCancel
134
Type
Package
Classe (nom court)
Model
(m),
Controller
(c) ou
View (v)
Récupère une page de Tamino c
Fonction
Appelée par
(principale ment)
b:@p
baepp.
onlineHelp
LoadDocument
s
"
OLH_TOC
Récupère le sommaire de
c -v
l'aide en ligne dans Tamino et
l'affiche
MainMenu
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
?
Commentaire
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)
renommer en
OlhToc
Menu
Maintenance du
menu principal
serait approprié ?
s
"
RemoveJpeg
Supprime une image du
disque
m
PictureManager
s
b
"
"
UploadJpeg
RequestParser
Ajoute une image sur le disque m
m
PictureManager
b
"
Thumbnail
b
s
"
baepp.
orderTracking
XmlPage
OrderList
s
"
OrderListCriteria
s
"
OrderListXSL
b
"
TransformationXSLT
s
"
OrderLineDetail
b:@p
baepp.sap
R3Material
m
b
b:@p
"
"
R3MaterialList
R3Order
m
m
b:@p
"
R3System
m
b
b:@p
"
"
SapSimulation
FileLog
m
m
b
baepp.tamino
b
"
MaterialLicenseTypeD Formate un document XML
m
escriptions
(<MaterialLicenseTypeDescript
ions/>)
CatalogueEventHandle Vérifie la structure du
m
r
document XMl <Catalogue/>
b
"
InoConnection
Définition des méthodes de
connexion à Tamino
m
b
"
Material
(<Material/>)
m
source ?
m
m
Affiche les ordres d'achat
m- v
correspondant aux critères
Affiche une page de recherche c - v
d'ordre d'achat (tracking)
source ?
source ?
OrderListCriteria
MainMenu
Applique une feuille de style
m
XSL (prépare le document
XML)
Effectue les opérations
m
nécessaires à l'application
d'une feuille de style XSL à un
document XML
OrderListCriteria
Affiche le détail d'un ordre
d'achat
OrderList
v
renommer en
Transformatio
nXslt
impossible
d'obtenir le
.java
correspondant
à partir de
Bolero
135
Type
Package
Classe (nom court)
Fonction
MaterialDescriptions Formate un document XML
(<MaterialDescriptions/>)
MaterialFamily
(<MaterialFamily/>)
Model
(m),
Controller
(c) ou
View (v)
m
b
"
b
"
b
"
Catalogue
(<Catalogue/>)
m
b
"
MaterialLicenseTypes Formate un document XML
(<MaterialLicenseTypes/>)
m
b
"
MaterialPricingQuant Formate un document XML
ities
(<MaterialPricingQuantities/>)
m
b
"
MaterialPricingUnitD Formate un document XML
m
escriptions
(<MaterialPricingUnitDescriptio
ns/>)
b
"
MaterialPricingUnits Formate un document XML
(<MaterialPricingUnits/>)
m
b
"
MaterialVersions
(<MaterialVersions/>)
m
Appelée par
(principale ment)
Commentaire
m
136
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
-> ShoppingCart
-> AddPosition
-> UpdateSalesOrder
-> MakeOrder
-> ConfirmOrder
-> LoadSave
-> RemoveOrderItem
-> OrderListCriteria
-> OrderList
-> OrderLineDetail
-> DefaultGeneration
-> OrderListXSL
-> 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
-> CatalogMgt
-> ProductFamilyEditing
-> CatalogEditing
-> PlugMgt
-> PlugTypeMgt
-> PlugEditing
-> PlugTypeEditing
-> PlugAssignment
-> PlugAssignEditing
-> PlugListing
-> VersionListing
-> TempMgt
-> TemplateEditing
-> RepStatsCriteria
-> ProdListing
-> RepStatsOutput
Etude de frameworks MVC - Analyse fonctionnelle de la migration du projet BAE vers J2EE
-> DetailListing
137 137
-> RepStatsCmdLineQry
-> RepStatsCmdLineOutput
-> LicenseListCriteria?cancel=1 -> LicenseListXSL
(LCT.displayLicKey) LicKeyCancel
-> LicKeyStats
-> MassGeneration
-> ModifyPassword
-> LicKeyCatalog
(LCT.selectCatalog)
-> UpdatePassword
-> ModifyEmail
-> UpdateEmail
-> LdapLogin
-> LdapAuthentication
-> LicKeyForm
-> GenLicKey
(LCT.displayMassLicKey)
-> AdminMenu
-> AdminUser
-> AdminPartner
-> SaveUser
-> SavePartner
-> ModifyUser
-> UpdateUser
-> ModifyPartner
-> RemovePartner
-> RemoveUser
-> OLH_TOC
-> OnlineHelp
-> BugReport
-> (javascript) SapToTamino
-> Disconnect
MlManagement
-> DisplayLabel
-> UpdateXmlInTamino ↓
-> AddLanguage
-> ↓
-> MlManagementMenu
-> RemoveLanguage
-> ↑
-> InitMlManagement
-> UpdateMlForm
PictureManager -> RemoveJpeg
-> UploadJpeg
138 138
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>
</level3>
<level3
item="menu_licensekey_massGeneration_sameLicense">
<title3>Mass generation : same License</title3>
<linkTo3>massgeneration</linkTo3>
<help3>Create mass licenses</help3>
</level3>
<level3
item="menu_licensekey_massGeneration_differentLicense">
<title3>Mass generation : different
License</title3>
<linkTo3>massgenfromfile</linkTo3>
<help3>Create licenses from file</help3>
</level3>
</level2>
<level2 item="menu_licensekey_lictrack">
<title2>License Tracking</title2>
<linkTo2></linkTo2>
<help2>Search, Display and Download license key
file</help2>
<level3 item="menu_licensekey_LicenseTracking">
<title3>License Tracking</title3>
<linkTo3>licensetracking</linkTo3>
<help3>Search, Display and Download license key
file</help3>
</level3>
<level3
item="menu_licensekey_administration_RepStatsCriteria">
<title3>Query and Report: Interactive
Query</title3>
<linkTo3>repstatscriteria</linkTo3>
<help3>Interactive Query</help3>
</level3>
<level3
item="menu_licensekey_administration_RepStatsCmdLineQry">
<title3>Query and Report: Command Line
Query</title3>
139 139
<linkTo3>/repstatscmdlineqry</linkTo3>
<help3>Command Line Query</help3>
</level3>
<level3
item="menu_licensekey_administration_deleteLicenseKey">
<title3>Cancel / Reactivate license key</title3>
<linkTo3>cancelreactivatelicense</linkTo3>
<help3>Cancel or Reactivate a generated
license</help3>
</level3>
</level2>
<level2 item="menu_licensekey_administration">
<title2>License administration</title2>
<linkTo2></linkTo2>
<help2></help2>
<level3
item="menu_licensekey_administration_licenseSetMgt">
<title3>License Set Management</title3>
<linkTo3>licsetmgt</linkTo3>
<help3>License set management</help3>
</level3>
<level3
item="menu_licensekey_administration_PlatformMgt">
<title3>Platform Management</title3>
<linkTo3>platformmgt</linkTo3>
<help3>Platform Management</help3>
</level3>
<level3
item="menu_licensekey_administration_ProductFamilyMgt">
<title3>Product Family Management</title3>
<linkTo3>productfamilymgt</linkTo3>
<help3>Product Family Management</help3>
</level3>
<level3
item="menu_licensekey_administration_productCatalogMgt">
<title3>Product Management</title3>
<linkTo3>catalogmgt</linkTo3>
<help3>Product catalog management</help3>
</level3>
<level3 item="menu_licensekey_administration_PlugMgt">
<title3>Plug Management</title3>
<linkTo3>plugmgt</linkTo3>
<help3>Plug management</help3>
</level3>
<level3
item="menu_licensekey_administration_PlugTypeMgt">
<title3>Plug Type Management</title3>
<linkTo3>plugtypemgt</linkTo3>
<help3>Plug Type Managment</help3>
</level3>
<level3
item="menu_licensekey_administration_PlugAssignment">
<title3>Plug Assignment</title3>
<linkTo3>plugassignment</linkTo3>
<help3>Plug Assignment</help3>
</level3>
<level3
item="menu_licensekey_administration_TemplateEditor">
<title3>Template Management</title3>
<linkTo3>tempmgt</linkTo3>
<help3>Template management</help3>
</level3>
</level2>
<level2 item="menu_licensekey_administration_statistic">
<title2>License statistics</title2>
<linkTo2>lickeystats</linkTo2>
140 140
<help2>Count licenses by type and state</help2>
</level2>
</level1>
<level1 item="menu_userconfig">
<title1>User Config</title1>
<linkTo1></linkTo1>
<level2 item="menu_userconfig_passwordModification">
<title2>Password Modification</title2>
<linkTo2>modifypassword</linkTo2>
<help2>Modify your password</help2>
</level2>
<level2 item="menu_userconfig_emailModification">
<title2>Email Modification</title2>
<linkTo2>modifyemail</linkTo2>
<help2>Modify your e-m@il address</help2>
</level2>
</level1>
<level1 item="menu_administration">
<title1>Administration</title1>
<linkTo1></linkTo1>
<level2 item="menu_administration_PartnersUsersManagement">
<title2>Partners and Users Management</title2>
<linkTo2>ldaplogin</linkTo2>
<help2>Manage users and groups</help2>
</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>
<level2 item="menu_licensekey_generation">
<title2>Génération de clé de licence</title2>
<linkTo2></linkTo2>
<level3 item="menu_licensekey_generateDefault">
<title3>Génération de licence</title3>
<linkTo3>defaultgeneration</linkTo3>
<help3>Génération de licence</help3>
</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>
</level3>
<level3
item="menu_licensekey_massGeneration_sameLicense">
<title3>Licences identiques</title3>
141 141
<linkTo3>massgeneration</linkTo3>
<help3>Génération de licence en masse</help3>
</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>
</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>
<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>
</level3>
<level3
item="menu_licensekey_administration_RepStatsCriteria">
<title3>Requête interactive</title3>
<linkTo3>repstatscriteria</linkTo3>
<help3>Requête en remplissant un
formulaire</help3>
</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>
</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>
</level3>
</level2>
<level2 item="menu_licensekey_administration">
<title2>Administration de licence</title2>
<linkTo2></linkTo2>
<help2></help2>
<level3
item="menu_licensekey_administration_licenseSetMgt">
<title3>Gestion des groupes de license</title3>
<linkTo3>licsetmgt</linkTo3>
<help3>Gestion des groupes de license</help3>
</level3>
<level3
item="menu_licensekey_administration_PlatformMgt">
<title3>Gestion de plate formes</title3>
<linkTo3>platformmgt</linkTo3>
<help3>Gestion de plate formes</help3>
</level3>
<level3
item="menu_licensekey_administration_ProductFamilyMgt">
<title3>Gestion de famille de produits</title3>
<linkTo3>productfamilymgt</linkTo3>
<help3>Gestion de famille de produits</help3>
</level3>
142 142
<level3
item="menu_licensekey_administration_productCatalogMgt">
<title3>Gestion des produits</title3>
<linkTo3>catalogmgt</linkTo3>
<help3>Gestion du catalogue de produits</help3>
</level3>
<level3
item="menu_licensekey_administration_newTemplate">
<title3>Gestion des templates</title3>
<linkTo3>tempmgt</linkTo3>
<help3>Créer un nouveau modèle</help3>
</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>
</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>
</level3>
<level3 item="menu_licensekey_administration_PlugMgt">
<title3> Gestion des Plug-Ins</title3>
<linkTo3>plugmgt</linkTo3>
<help3>Gestion des Plug-Ins</help3>
</level3>
</level2>
<level2 item="menu_licensekey_administration_statistic">
<title2>Statistiques</title2>
<linkTo2>lickeystats</linkTo2>
<help2>Dénombrement des licences par type et
statut</help2>
</level2>
</level1>
<level1 item="menu_userconfig">
<title1>Configuration utilisateur</title1>
<linkTo1></linkTo1>
<level2 item="menu_userconfig_passwordModification">
<title2>Modifier le mot de passe</title2>
<linkTo2>modifypassword</linkTo2>
<help2>Modifier le mot de passe</help2>
</level2>
<level2 item="menu_userconfig_emailModification">
<title2>Modifier l'email</title2>
<linkTo2>modifyemail</linkTo2>
<help2>Modifier l'adresse email</help2>
</level2>
</level1>
<level1 item="menu_administration">
<title1>Administration</title1>
<linkTo1></linkTo1>
<level2 item="menu_administration_PartnersUsersManagement">
<title2>Gestion des partenaires et utilisateurs</title2>
<linkTo2>ldaplogin</linkTo2>
<help2>Gestion des utilisateurs et groupes</help2>
</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>
143 143
</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
(1, dlls et note)
Dossier dlls
144 144
§
§
§
§
§
§
§
§
§
§
§
§
Dossier
Dossier
Dossier
Dossier
Dossier
Dossier
Dossier
Dossier
Dossier
Dossier
Dossier
Dossier
(1, javadoc + doc. d'install.)
doc
images
ino
(2)
licensekeys
(2)
logs
(1, sources java)
src
style
(1)
tamino
(2, emplacement de génération du .war)
war
WEB-INF
xml
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</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
145 145
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)
146 146
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…
147 147
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.
148 148
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.
149 149
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/strutsconfig-editor/
150 150
§
§
§
§
§
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".
151 151
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
IntelliJ
Produit
IDEA
Borland JBuilder
Sun
IBM
Sun One Studio 4
(anciennement Forté for Java)
VisualAge for Java
Version
2.6
La version 3.0 est presque prête.
Enterprise 7.0
[Standard Edition 7.0]
[Personal 7.0]
Mise à jour vers EE 7.0 à partir de toute
version Professional ou Enterprise
Enterprise Edition 4.0
Community Edition 4.0
Professional Edition, 4.0
Upgrade vers PE 4.0
Date de
sortie
juin 2002
juin 2002
Nombre de
licences
Prix
USD
1-4
395
5-9
10-49
50+
360
320
295
2999
[399]
[0]
1899
juin 2002
août 2001
1995
0
111
52
152 152

Migration de l`application internet de gestion des licences Software AG

Transcription

Documents pareils

Procédure d`activation des cartes pour TomTom v7 Pour Go/one

2016 May 18-19

Guide à l`usage des employeurs d`apprentis IDE. V3

Imprimer en PDF - Ani

Dátum narodenia

C:\Documents and Settings\000125694\Local Settings\Temp

Evaluation - Anglais en LP

Système standardisé pour la production de

Madame, Monsieur, Vous souhaitez effectuer un séjour