Td corrigé projet lmd-j2ee - Free pdf

projet lmd-j2ee - Free

Sa programmation se fait en Java/XML/XSLT/JavaScript/JSP. .... contenir d'autres éléments pédagogiques, ou être un élément atomique (exemple : TD ALG).




part of the document



ns le cadre de la première année de Master informatique, les étudiants sont amenés à réaliser un projet en groupe de quinze à dix-huit personnes. Ainsi, les étudiants apprennent à travailler en équipe, à partager et gérer leurs ressources, à assumer les responsabilités liées à un tel projet et à faire preuve d’indépendance décisionnelle. Tout ceci permet aux étudiants de se rendre compte de l’ampleur d’un tel projet et de la nécessité d’une bonne organisation.

Le projet LMD-J2EE a pour principal objectif la création d'une application répartie. L'utilisation de la technologie J2EE (Java2 Enterprise Edition) met à notre disposition une architecture ainsi qu'un ensemble d'outils qui permettent d'assurer la robustesse et la richesse d'une application lourde.
La création d'un portail d'information sur les différentes offres de formation universitaire est une des possibilités de mise en oeuvre de notre application. En effet, une telle architecture nous offre de multiples possibilités d'évolution. Par exemple : l'intégration d'un intranet, d'un service de gestion d'emploi du temps, etc.

Depuis la mise en place de la réforme LMD, les universités rencontrant des obstacles pour adapter leur système ont besoin d’une centralisation de leurs données pour proposer une représentation plus claire de leurs formations.

Le portail devra permettre les actions suivantes :
Ajout, modification et consultation des formations et des ressources les constituant.
Recherche au sein des ressources et des formations.
Gestion des différents types d’utilisateurs (lecteurs, enseignants, administrateurs).

Après cette brève description de notre application, nous verrons en premier lieu le travail de recherche concernant les outils que nous avons etudié afin de préparer la phase de développement. Dans un second temps, nous détaillerons l'organisation du site internet : le contenu et l'apparence du site. Ensuite, nous exposerons la conception de l'application : les diagrammes organisationnels, la définition des différents objets métiers et leur contenu. Puis, nous décrirons globalement le fonctionnement du noyau de l'application. Enfin, nous présenterons les différentes méthodes d'organisation et le planning suivi.

Pour réaliser notre étude, après s'être placés dans le contexte du projet, nous avons souhaité partir d'une vue globale avant d'analyser les choix techniques et les problèmes qui y sont liés.

Le travail de recherche

Le travail de recherche était une étape importante du projet pour, tout d’abord, s’informer sur ces technologies nouvelles pour nous, et ensuite choisir entre les différents outils concurrents existants. Ces choix étaient basés sur des critères tels que : Open Source, portabilité, facilité d’utilisation, etc.

Les CMS
Un CMS (Content Management System) est un outil devant entre autre permettre à plusieurs
individus de travailler simultanément sur un ensemble de documents.
Il est possible de structurer le contenu tout en séparant les opérations de gestion de la forme et du fond, et de fournir une chaîne de publication. C'est le principe fondamental de la gestion de contenu ; il garantit la cohérence, l'évolutivité et la robustesse de l'information.
Il offre, par l'intermédiaire d'un ensemble de scripts accessibles en général par un navigateur web, la possibilité d'administrer un site internet de façon dynamique (contrairement aux sites purement HTML, totalement statiques).
A travers cet outil, les administrateurs d'un site web ont donc, sans connaissances techniques spécifiques, la possibilité de créer, de manière intuitive, de nouvelles pages, de nouveaux chapitres, de supprimer ou de modifier certains contenus.

Magnolia

Points positifs
Magnolia rend possible une édition en ligne simultanée, assurant ainsi la disponibilité du projet lors d'une phase d'écriture. Il permet aussi un suivi d'édition et un contrôle d'accès aux informations, grâce à un système d'identification.
Magnolia dispose, selon le constructeur, d'un service de cache efficace. Sa programmation est basée sur les technologies JSP et Servlets.
Le développement de Magnolia en Java donne aux développeurs l'assurance que ce CMS peut fonctionner avec un serveur d'application développé selon la technologie J2EE.
Enfin, Magnolia est le premier CMS à s'appuyer sur la norme JSR 170 (Java specification request) et à définir une API pour permettre l'accès au référentiel de contenu nommé JCR.
Ce standard a été défini pour que tous ceux souhaitant développer de nouveaux CMS, se mettent en conformité avec les spécifications définies par SUN pour l'accès au contenu. En réalité, la grande majorité des gestionnaires de contenus ont différents formats de données, ainsi que des plates-formes d'exécutions variées. Les problèmes d'accès aux données sont donc dûs à ces différences. Le but de la définition de ce standard est donc de remédier à ces problèmes.

Points négatifs
Il s'agit d'un CMS écrit en Java nécessitant le JDK 1.4.1 au minimum. De plus, il ne semble pas fonctionner correctement avec tous les navigateurs. Enfin, comme nous voulons avoir un CMS assurant de bonnes montées en charge, l'absence de documentation concernant ce point ne nous permet d'utiliser Magnolia que comme outil de gestion de documents internes.


Lenya

Points positifs
Lenya supporte tous les types de base de données. Il supporte l'identification des utilisateurs(LDAP et technologie constructrice) et permet donc un contrôle des accès aux informations.
De plus, Lenya dispose d'un support commercial. Sa programmation se fait en Java/XML/XSLT/JavaScript/JSP.

Lenya dispose d'un système de cache avancé et paramétrable.
– supporté par la fonction Apache
– pas de base de données interne (stockage sous forme de fichiers XML)
– basé sur les standards : J2EE, XML, Cocoon, Lucène, Tomcat XSL
– types de contenus paramétrables
– gestion des droits d'édition
– gestion des accès concurrents
– éditeurs XLM et XHTML intégrés
– prévisualisation avant production
– export PDF des contenus « à la volée »
– moteur de recherche intégré avec Lucene

Points négatifs
Lenya ne dispose d'aucune documentation. De plus, il ne fournit pas le support FTP.

OpenCMS

Points positifs
OpenCMS est un CMS puissant, multi-plateforme et déjà éprouvé.

Points négatifs
Il est incompatible avec les JCR.

Les serveurs d'application


Parmi les serveurs d'application les plus utilisés, nous pouvons noter WebSphere (IBM),Weblogic (BEA), Oracle (Oracle Corporation), .NET (Microsoft), JBoss (JBoss Inc.), et JOnAS (ObjectWeb).
Dans le cadre de ce projet, nous avons étudié les deux serveurs gratuits : JBoss et JOnAS.

JBoss

Points positifs
Nous avons choisi JBoss pour son évolutivité, sa facilité d'utilisation. De plus, il est peu gourmand en ressources, compatible avec J2EE et simple d'installation.

Points négatifs
A ce jour, aucun problème n'a été soulevé. JOnAS

Points positifs
C'est un des meilleurs serveurs à l'heure actuelle.

Points négatifs
Il connaît ces derniers temps un sérieux ralentissement dans son développement, ce qui le rend moins attractif.
Les plugins d'Eclipse
Description d'Eclipse
Eclipse est une interface de développement extensible (IDE). De par cette extensibilité, nous avons l'opportunité d'installer des plugins de natures diverses qui nous permettront d'ajouter des fonctionnalités annexes pouvant s'avérer utiles et de simplifier la mise en oeuvre de notre application, par exemple avec Lomboz ou JBoss IDE.

Le plugin Lomboz
Lomboz, plugin open source à destination des développeurs J2EE, ajoute à Eclipse des assistants pour la création de Servlets, de pages JSP et d'EJB. Une des directives du projet est d'ailleurs l'utilisation de la technologie J2EE ( Java 2 Enterprise Edition ). La plateforme J2EE permet de simplifier le développement d'applications multi-tiers. Elle met à notre disposition un ensemble d'API et une infrastructure d’exécution pour héberger des applications.

Points positifs
Lomboz est un très bon plugin J2EE Open Source pour Eclipse, il est intuitif, léger et muni d'un assistant de génération de code très pratique.

Points négatifs
Son principal défaut par rapport à un de ses rivaux, MyEclipse (qui n'est pas gratuit) se situe au niveau de la génération des EJBs, il ne faut pas oublier de les régénérer à chaque modification de code.

Le plugin JBoss IDE
JBoss IDE est un plugin développé par l'équipe de JBoss afin de permettre une gestion simplifiée des serveurs JBoss. Il met également à disposition des outils de développement utiles au déploiement d'application sur le serveur JBoss (créateur de scripts de « packaging », et créateur de scripts de configuration XDoclet).

Points positifs
Il s'agit d'un plugin simple d'utilisation et très efficace.
Points négatifs
Quelques bugs concernant la gestion des serveurs subsistent.

Le site internet

Lors de la conception d'un site internet, il est important de mettre au point une ébauche de son architecture et de son esthétique. Pour y parvenir, nous nous sommes inspirés d'un site analogue à notre projet, celui de l'université de Jussieu (Paris V). Il nous a semblé correspondre à nos objectifs. Cependant, ce n'est qu'un exemple représentatif, il pourra être sujet à des modifications ultérieures.
Le contenu
Page d'accueil

Une présentation générale du LMD,

liens vers les cycles licence, master et doctorat,

lien vers l'offre de toutes les formations,

lien pointant sur une page d’authentification (enseignants/administrateurs),

lien vers une FAQ,

zone de navigation .
Présentation générale du LMD

Description générale des modifications apportées par la réforme. Liens vers les cycles

Liens vers les formations et leurs spécialités.

Schéma supplémentaire sur les poursuites d'étude pour Licence & Master.
Liens vers toutes les formations

Liens par ordre alphabétique de toutes les formations et de leurs spécialités.
Lien vers une page d’authentification

Zone d'entrée du login et du mot de passe.

Lien vers la FAQ

Affichage des questions fréquemment posées, relatives au site et à son contenu.

Organigramme du site

 L'apparence du site
Utilisation de « templates » pour les mentions et spécialités
Un template est un modèle de document HTML composé de balises constituant l'ossature du document final et les directives de notre application permettant de compléter ce document.


Description du template

Titre de la mention ou spécialité

Objectifs et descriptions

Débouchés professionnels

Organisation

Public visé

Prérequis

Responsable

Contact

Le site de la mention

Liens vers toutes les UE disponibles pour la spécialité.

Utilisation de « templates » pour les unités d'enseignement
Description du template :
Titre de la mention ou spécialité
Objectifs et descriptions
Débouchés professionnels
Organisation
Publics visés
Prérequis
Responsable
Contact

Conception de l'application

L'ensemble des informations contenues dans le portail est accessible par les objets métiers. Ces derniers sont des éléments atomiques faisant le lien entre ce que l'utilisateur voit dans le navigateur et les informations stockées dans les bases de données.
Grâce aux propositions faites par notre encadrant, une première version de ces objets métiers a pu être réalisée. Ceux-ci sont constitués d'attributs élémentaires qui seront enrichis lors du développement par la mise en place des liaisons entre les différents objets métiers. Tout cela est modélisé dans le diagramme UML.
Le modèle UML
Diagramme UML du portail LMD
 Diagramme des liaisons inter-packages – Objets métiers

Chaque objet métier est représenté par un package. Il existe des liaisons qui seront implémentées par l'application lors du développement.



Explication des packages – Objets métiers
Tous les objets métiers possèdent directement ou pas un attribut « id » de type entier généré automatiquement.
Ressources pédagogiques
Ce package constitue l'ensemble des ressources pédagogiques. Chaque collection de ressources concerne un élément pédagogique (matière, unité d'enseignement, ...). Plusieurs collections différentes de ressources peuvent être liées à un même élément pédagogique pour les distinguer en fonction de leur thème.
Références bibliographiques
Ce package, par analogie avec celui des ressources pédagogiques, constitue les références bibliographiques ; chaque collection de références bibliographiques concerne un élément pédagogique.
Questions souvent posées – FAQ
Ce package constitue la FAQ du portail d'information LMD. Les questions sur le même thème sont regroupées aux seins de collections.


Élément pédagogique
Ce package regroupe tout ce qui constitue à proprement parler les enseignements, un élément pédagogique est un bloc qui peut : contenir d'autres éléments pédagogiques, ou être un élément atomique (exemple : TD ALG). Les éléments pédagogiques peuvent être regroupés dans deux types de collection : les « collections et » qui regroupent des éléments de telle façon que si un étudiant est inscrit à la collection, il suit tous les éléments qui la composent, les « collections ou » qui regroupent les éléments de telle façon que si un étudiant suit la collection il suit l'un ou l'autre des éléments qui la compose.

Exemple d'architecture d'éléments pédagogiques :



Personne
Ce package contient les données des utilisateurs du portail et permet d’identifier le type d’utilisateurs et le groupe auquel ils appartiennent. Ce sont les droits d’accès qui différencient les utilisateurs.
La classe « user » est une interface créée pour identifier les différents types d’utilisateurs du portail. Un utilisateur du portail peut être quelqu’un qui fait partie du personnel de l’université ou de simples visiteurs n'ayant que droit de consultation.
Un visiteur est un utilisateur se connectant au site pour simplement consulter des données. Une personne peut être un professeur ou bien un administrateur.
La classe « professeur » représente les enseignants, qui peuvent selon leurs droits d’accès gérer les ressources pédagogiques ainsi que des éléments pédagogiques. Chaque professeur peut être affecté à une ou plusieurs unités de formation et faire partie d’un ou plusieurs groupes de recherche.
Un administrateur peut être un professeur ou une tierce personne. Il est chargé de gérer les informations publiées dans le portail.


Mot clé
Ce package représente la liste de mots clés utilisés pour faire des recherches et des tables d’index. Un mot clé peut aussi être un sigle par exemple STS. Chaque mot clé donne accès à une liste de composants. Une collection de mots clés représente une liste de mots clés, qui sont regroupés selon différents critères.
Définition
Ce package stocke la définition d’un mot clé ou d’un sigle. Une collection de définitions est un glossaire. Une définition peut appartenir à plusieurs glossaires.
Adresse
Ce package contient les données principales de la ville ainsi que les coordonnées géographiques utilisées dans une représentation graphique. Une adresse est composée par le nom de la rue, le numéro et le code postal de la ville à laquelle elle appartient.
Unités de formation
Ce package représente l'ensemble des filières et des établissements. Une unité de formation élémentaire représente une filière (Licences, Masters et doctorats) proposée par un établissement. Une collection d’unités de formation représente un établissement d’enseignement supérieur, telles que les universités, écoles et instituts supérieurs (Rennes1, IFSIC, IGR…). Les unités de formation contiennent une liste du personnel affecté, tel que les responsables, les secrétaires, etc.

Spécification des attributs – Dictionnaire de données
Ressource pédagogique
titre : titre de la ressource pédagogique qui peut être une vidéo, une image, un document texte, représenté par un StringBuffer.
description : description de la ressource pédagogique, représenté par un StringBuffer.
lien : lien d'accès à la ressource, représenté par un StringBuffer.
Références bibliographiques
titre : titre de la référence bibliographique (livre), représenté par un String.
isbn : International Standard Book Numbering, code d'identification des livres, représenté par un entier de 10 chiffres.
Questions souvent posées – FAQ
question : énoncé de la question, représenté par un StringBuffer
detail : énoncé détaillé du problème, représenté par un StringBuffer.
explication : cause du problème, représentée par un StringBuffer.
correction : solution pour résoudre le problème, représentée par un StringBuffer.


Personne
id
nom : nom de la personne
prenom : prénom de la personne
tel : numéro de téléphone de la personne
email : adresse e-mail de la personne
page_perso : adresse de la page personnel de la personne
photo : nom du fichier qui contient la photo de la personne
nom_usager : nom d' utilisateur qui peut être le code sésame
mot_de_passe : mot de passe confidentiel
Professeur
batiment : nom du bâtiment où se trouve le bureau du professeur.
bureau : numéro de bureau du professeur.
Partition de groupe
id
groupe_pere : identifiant du groupe auquel appartient la partition de groupe
Groupe
id
Clé
id
nom : le mot clé
Collection de clés
id
nom : nom de la collection de mots clés
Définition
id : identifiant unique généré automatiquement pour chaque définition
mot : le mot clé ou sigle
description : signification du mot clé ou sigle
Collection de définitions
id : identifiant unique généré automatiquement pour chaque groupe de définitions
description : description du groupe de définitions
Ville
insee : code INSEE de la ville. Les 2 premiers et les 3 derniers chiffres forment le code postal de la ville.
nom_long : nom de la ville
nom_court : nom court de la ville, c'est celui qui s’affichera sur le navigateur
code_postal : numéro de code postal de la ville (les 2 premiers chiffres représentent le numéro de département auquel appartient la ville)
departement : nom du département auquel appartient la ville
x : coordonnée X de la ville pour localiser sa position sur une carte
y : coordonnée Y de la ville pour localiser sa position sur une carte
Adresse
id
rue : nom de la rue
numero : numéro dans la rue
cp : code postal auquel appartient la rue
Collection d'unités de formation
id
nom_court : nom court du groupe d'unités de formation, celui qui s'affichera sur le navigateur
nom : nom du groupe d'unités de formation
Unité de formation élémentaire
id
nom_court : nom court de l'unité de formation élémentaire, celui qui se affichera sur le navigateur
nom : nom de l'unité de formation élémentaire
Contact
id
fonction : fonction du contact
nom : nom du contact
tel : numéro de téléphone du contact
email : adresse électronique du contact

Noyau de l'application

Après avoir vu les objets métiers nécessaires, nous allons maintenant nous intéresser au fonctionnement interne de l'application les implémentant et faisant la liaison entre chaque package présenté ci-dessus.

Le projet utilise le modèle des architectures trois-tiers. En effet le serveur web correspond au tiers «interface», le serveur d'EJB (JBoss) représentant lui le tiers «traitement». Le tiers «persistance» étant lui assuré par un stockage dans les bases de données.

La machine du client communique avec le serveur web via le protocole HTTP; le serveur web et le serveur d'application communiquent entre eux via le protocole RMI.

Lorsque le client fait une demande d'accès à une page de notre site via son navigateur Internet, le serveur web (nous utiliserons TOMCAT car il est intégré à Jboss) se charge de lui envoyer la page JSP correspondante traduite en HTML. Ces pages JSP sont basées sur le modèle vue-contrôleur STRUTS qui permet de traiter aisément tous les formulaires de saisie et de consultation de données.

Qu'il s'agisse d'une saisie ou d'une simple consultation, les informations de nos formulaires JSP sont sauvegardées dans un JAVABEAN (classe Java respectant des normes) qui a la possibilité de tester les valeurs des champs afin de détecter tous les cas d'erreurs (champ non renseigné, lien invalide, etc.). Cette détection est faite lors de l'appel à la fonction de validation du formulaire via le bouton de soumission des données qui se trouve sur la page web. Si une erreur est détectée, on réaffiche le formulaire en indiquant les erreurs à corriger, sinon on affiche une page de succès et le JAVABEAN est automatiquement serialisé en XML grâce à CASTOR ou DOM4J sur le serveur WEB.
Un EJB correspondant au JAVABEAN sur le serveur d'EJB est ensuite directement rempli avec les valeurs du bean du serveur web. Cet EJB sera chargé de sauvegarder les informations soit dans une base de données de type SGBD ou bien LDAP, soit dans des fichiers XML contenant les informations de tous les utilisateurs.

Dans le sens inverse, lorsqu'il s'agit d'une simple consultation des données, l'XMLIZER (chargé de traduire des beans en XML) transforme les données récupérées dans la base de données, via un EJB, en un fichier XML. Il soumet ensuite les données à la servlet correspondante du serveur web. Celui-ci se charge ensuite d'envoyer la page web complétée au client, au format HTML ou PDF, en utilisant le moteur de traitement des fichiers XML adéquat : XSLT HTML ou XSLT PDF (NB : pour qu'un traitement XSLT soit possible, les fichiers XML devront avoir été générés par DOM4J).


Organisation du projet
Organisation du premier semestre
Méthode de travail
On peut l'avouer, le démarrage a été difficile. Une fois la présentation du projet faite, beaucoup d'idées ont circulé dans tous les sens mais sans organisation.
L'idée d'un chef de projet n'est pas venue tout de suite par manque de connaissance du sujet. Ainsi, pendant deux ou trois semaines le groupe s'est organisé pour faire un maximum de recherches sur le projet LMD de l'année passée et les nouvelles technologies qui seraient utilisées.
En raison du nombre important de personnes, nous avons envisagé de diviser le groupe en deux projets concurrents. L'avancement étant plus lent que prévu, le groupe n'a finalement pas été scindé mais l'idée pourra sans doute être reprise au second semestre.
Le fond du projet n'étant pas très clair, l'utilisation de l'eXtreme Programming nous a permis de débuter rapidement tout en impliquant tout le monde.
En effet, cette méthode suppose la gestion de petits groupes qui travaillent par couche, c'est à dire en partant d'une entité simple jusqu'à un système compliqué, tout cela en procédant à un roulement.

Planning

Semaine39du20/09au26/09Présentation du projet (compte rendu du projet lmd 2003/2004)
Proposition d'un règlement intérieurSemaine40du27/09au03/10Découverte de nouveaux outils (JBoss, Eclipse, plugins Eclipse)
Tutorial JBoss/Tusc (manipulation JBoss, outils J2EE)
Proposition de scinder le groupe en deux groupes concurrents en raison du nombre élevé de personnes (17)Semaine41du04/10au10/10Séance TP découverte Eclipse/Lomboz/JBoss
Division en 4 sous groupes : J2EE, Jboss/Lomboz, CVS, les CMS.Semaine42du11/10au17/10Cours XML
Exposé J2EE
Exposé Jboss/Lomboz
Première version du règlement intérieur
Election de 2 chefs de projet Semaine43du18/10au24/10Cours XPATH
Exposé sur CVS
Exposé sur les CMS : Magnolia, Open-CMS, Apache Lenya
-> élimination de Apache Lenya
Tutorial Jboss/Tusc Chap.1, 2 et 3 en français
Poly Concepts de base du projet LMDSemaine44du25/10au31/10Cours XSLT
Exposé sur les CMS : Open-CMS ou Magnolia ?
Documentations J2EE, Jboss/Lomboz, CVS, CMS corrigées et en ligne au format pdf.
Mise en route du projet sur projet.univ-rennes1.fr, mise en place du nom des utilisateurs, forums...
Tutorial chap.0 : configuration Eclipse/Lomboz
Mise en ligne du règlement intérieur et d'un modèle de document pour les comptes-rendu et la documentation produiteSemaine45du01/11au07/11Férié : réunion le vendredi 5 nov à 10h15
Recherche avancées sur LDAP/JNDI, STRUTS, DOM4J
Mise en place du site du projet LMD sur projet.univ-rennes1.frSemaine46du08/11au14/11Exposé avancé sur LDAP
Découverte de Castor
Approfondissement de Magnolia et JCR
Intégration de STRUTS aux EJBs
Tutorial StrutsSemaine47du15/11au21/11Exposé rapide sur l'Extreme Programming
Première version d'un EJB avec STRUTS (formulaire)
Réunion sur le rapport de spécifications (Mise au clair de la forme des spécifications, du fonctionnement générale de l'application générale)

-> Division en 3 groupes :
Cahier des charges/spécifications:
Synthèse de l'étude (Technologies exclues/retenues)
Organisation du 1er et 2nd semestreSemaine48du22/11au28/11Premières versions papier de la soutenance (1 par groupe)
Doc Extreme Programming (annexes)
Doc Magnolia (à inclure dans le schéma structurel)
Mise en commun des informations pour ajuster le travail de chaque groupe
Choix des personnes représentant le groupe à la soutenance semaine 51 (4 ou 5 personnes)Semaine49du29/11au05/12Version papier DEFINITIVE du rapport de spécifications (intégrant le planning du premier et second semestre, les documentations produites, un dossier expliquant les choix/orientations, les méthodes de recherche, l'organisation et enfin le travail à faire)
Travail de relecture des précédents documents produitsSemaine50du6/12au12/12Soutenance blanche
Rendu du rapport de spécificationsSemaine51du13/12au19/12Soutenance

-> Séance suivante : (janvier 2005)
La répartition du travail
Le travail du premier semestre porte essentiellement sur les spécifications du projet, le groupe a donc été divisé en sous-groupes de recherche sur diverses technologies.
A chaque recherche, de nouveaux groupes ont été reconstitués de manière à impliquer au maximum tous les membres.

La répartition du travail de recherche lors de cette phase d'analyse nous a conduit à une estimation du temps de travail effectué de Septembre à Décembre.



Le travail en groupe comprend les séances communes rassemblant tous les membres du projet et les recherches effectuées par sous-groupe.
Le travail individuel correspond à la contribution moyenne de chaque membre en dehors des séances de projet. Le schéma nous montre certaines disparités quant au volume horaire consacré à chaque tache. Cela s'explique par :
une répartition inéquitable entre les groupes. Par exemple, dans le cas de Gforge seulement deux personnes ont contribué à la mise en place de l'environnement en ligne, ce qui explique le nombre important d'heures passées
une mauvaise estimation des priorités
la découverte tardive de certaines technologies offrant un intérêt majeur au développement futur de notre application (par exemple JBoss IDE)
l'absence de documentations suffisantes sur des outils récents. C'est le cas par exemple du CMS Magnolia 2.0 qui il y a peu était encore en phase de réalisation.

Toutefois nous avons privilégié la mise en commun des recherches en multipliant les réunions non encadrées, afin que chacun ait une connaissance globale de l'avancement et des choix faits.


Le suivi du travail
Le principal souci des chefs du projet est de mesurer le travail réalisé et les problèmes rencontrés par le groupe. Une mise en commun des informations durant chaque séance a été faite grâce à divers exposés et autres brainstorming autour des problèmes et des choix à effectuer. L'accent a été mis sur la communication afin que chaque membre du groupe ait une vision globale du projet.
Une synthèse est demandée à chaque exposé ou recherche, ce qui permet un gain de temps lors de la production du rapport final.
Organisation du second semestre
Planning prévisionnel

Semaine01du03/01au09/01Examens du premier semestreSemaine02du10/01au16/01S’assurer que tout le monde a configuré les outils nécessaires au développement.
Mettre au point l’architecture des dossiers sous CVS et les conventions de codage.
Définir les roulements de binôme jusqu’à la semaine 15.
Rôles à redéfinir : équipe CVS, équipe CMS, responsable documentation.Semaine03du17/01au23/01Création par binômes des EJB, avec rémanence SGBDR, LDAP ou XML
Utilisation de Struts.
Une fois les EJB créés et testés, mise au point des référencements croisés.Semaine04du24/01au30/01Intégration des EJBs (1ère couche).Semaine05du31/01au06/02Définition de l’aspect visuel de l’application.
Accord sur la création graphique avec les webmestres du portail.Semaine06du07/02au13/02Création des feuilles de style (XSLT pour visualisation HTML et visualisation PDF)
Création de formulaires de saisie.Semaine07du14/02au20/02Création d'une équipe chargée de récolter, auprès des responsables, des informations sur leurs formations.
Intégration EJBs (2ème couche).Semaine08du21/02au27/02Semaine09du28/02au06/03Vacances de FévrierSemaine10du07/03au13/03Semaine11du14/03au20/03 Semaine12du21/03au27/03Tests de structure : fonctionnement de l’interaction des composants entre eux.
Une équipe dédiée au déboguage.
Une équipe dédiée à la préparation de la rédaction du rapport. Semaine13du28/03au03/04Fin de la rédaction du rapport. (reprise du premier rapport, bilan sur l’application en l’état, évolution du projet, conclusions sur la méthode d’organisation d’un projet à 15…)
Préparation de la présentation finale.Semaine14du04/04au10/04Préparation et répétition de la présentation finale.
Organisation pour la démonstration.Semaine15du11/04au17/04Présentation
DémonstrationSemaine16du18/04au24/04Vacances de PrintempsSemaine17du25/04au01/05Examens du deuxième semestre


Conclusion

Le travail de recherche est une partie très importante dans le développement d'un projet, et prend beaucoup de temps ; voire plus que nous ne l'aurions pensé.
Tout d'abord, toutes les technologies abordées sont très récentes. Ainsi, les documentations complètes en ligne et les avis sont peu exhaustifs.
Ensuite, les compétences de chacun et leur implication (difficilement appréciables) ne permettent pas de faire de prévision fiable sur ce qui pourra être fait la semaine suivante.
Enfin, la réalisation d'un portail d'information de cette ampleur demande beaucoup d'investissement personnel.

Le bilan est donc assez difficile à dresser : même si l'eXtreme Programming nous permet d'avancer, il n'en reste pas moins difficile pour nous d'avoir une idée du travail à faire.
Nous avons une idée générale assez précise du fonctionnement final de l'application, de son apparence, de la plupart des technologies et outils à utiliser, et des spécifications de base.
Cependant, le travail réalisé est très satisfaisant globalement. Les objectifs du premier semestre sont dans l'ensemble atteints, ce qui reflète bien la motivation du groupe et la prise de conscience que le projet est une expérience de travail intéressante. C'est une vision enrichissante du monde professionnel.















ANNEXES


J2EE
JBoss-Lomboz
CMS
STRUTS
CVS
eXtreme Programming






Les annexes ci-après sont un support de documentation sur les technologies et outils qui permettront de construire ainsi qu'administrer le portail.
Pour découvrir ces technologies et outils nous avons dans un premier temps réalisé des exposés. Le groupe s'est pour ce faire divisé en sous-groupes de recherches de cinq à sept personnes. Ces présentations ont permis d'homogénéiser les connaissances de chacun, elles constituent la base de nos annexes.
En parallèle d'autres documents, plus techniques, ont été écrits, ceux-ci nous permettront de démarrer le développement au second semestre.


CVS

CVS sous Eclipse

Introduction
CVS (Concurrent Versions System) est un outil permettant de garder l'historique des modifications de fichiers (binaires ou ASCII). Il conserve les modifications effectuées et permet d'avoir toujours accès aux versions antérieures du travail réalisé.
CVS est multi-utilisateur. Plusieurs personnes peuvent travailler sur un même projet, c'est-à-dire modifier « en même temps » un fichier donné. Ce « en même temps » existe réellement, chaque utilisateur travaillant sur une copie de l'original.
En fait, personne ne travaille jamais sur les versions originales (même l'administrateur du projet) ; toutes les modifications des fichiers originaux passent par CVS. Ils sont modifiés quand un utilisateur renvoie ses nouvelles versions. Les anciens fichiers ne sont jamais détruits (ce qui évite l'écrasement d'un projet par un utilisateur peu scrupuleux) ; seules les différences sont enregistrées, il est alors toujours possible de revenir en arrière, et ce indépendamment pour chaque fichier.
Chaque fichier possède donc son propre historique, et il est possible de conserver une trace, à l'aide d'une marque, d'une version de projet à un moment donné pour pouvoir revenir dans un état original en une seule opération, si nécessaire.


Utilisation de CVS sous Eclipse
 La perspective CVS
La perspective «Exploration du référentiel CVS» permet de gérer les échanges et le contenu des projets stockés sous CVS. Ces projets peuvent avoir deux statuts : modifiable ou non modifiable (une version fonctionnelle du projet). La communication entre le référentiel et les clients du plan du travail est assurée par des réseaux locaux ou longue distance.
Le repository/Référentiel
C’est un système de fichier. Le repository correspond au répertoire distribué dans lequel sont stockés tous les fichiers et répertoires sous le contrôle de CVS. Il contient entre autres tous les modules, historiques de fichiers ainsi que les fichiers d’administration développés avec le logiciel CVS.

Principes et définition

Les Branches
Une branche peut être vue comme une bifurcation du développement principal d'un projet, permettant de faire une parenthèse, de tester une modification avant de décider de son intégration dans le développement principal.

Voici la représentation d’une branche :



Les nombres dans les cases sont les numéros de révision des fichiers.
Le tronc commun est l'état « standard » de développement des fichiers dans notre projet, les modifications sont normalement effectuées à ce niveau-là. La branche représente une version marquée par l'utilisateur, mais aussi par CVS : c'est le numéro de révision 1.1.2.1. Si vous développez dans une branche, alors vos modifications porteront sur cette branche uniquement et n'affecteront pas le tronc commun.
Les branches sont utilisées essentiellement pour deux raisons :
1. Corriger un bug sur une ancienne version de votre programme. Par exemple, un utilisateur vous fait part d'un bug sur une ancienne version et vous voulez, dans un premier temps, réparer ce bug puis pouvoir répercuter ces modifications sur la nouvelle version.
2. Créer un remaniement important sur la dernière version du programme sur laquelle vous travaillez, mais cela prendra du temps, et vous n’êtes pas sûrs que cela donnera de bons résultats. En tout cas, cela risque de déstabiliser le programme pendant un certain temps et vous ne voulez pas appliquer ces modifications avant d'être sûr que cela marche vraiment ou laisser tomber parce que cela n'a pas donné les résultats escomptés.


La vue Référentiel
La vue Référentiels CVS contient les emplacements de référentiels que vous avez ajoutés dans le plan de travail.
Lorsque vous développez un emplacement, le principal branchement (HEAD), ainsi que les versions et les branches de projet s’affichent dans ce référentiel. Vous pouvez alors développez Les versions et les branches de projet pour connaître les dossiers et les fichiers qu’elles contiennent.
Le menu en incrustation de cette vue permet également d’indiquer de nouveaux emplacements de référentiels. Utilisez la vue référentiel CVS pour réserver des ressources du référentiel vers le plan de travail, pour configurer les branches et les versions affichées par la vue, pour visualiser l’historique des ressources et pour comparer les versions de ressources.

Politique de synchronisation

Les mises à jour
La commande CheckOut permet de récupérer un projet dans sa version la plus récente, et de mettre à jour l’espace de travail local avec les modifications apportées par d’autres personnes dans une branche.
Une fois la mise à jour effectuée, vous pouvez modifier les fichiers à votre guise, les tester et soumettre les modifications avec la commande commit.
Lorsque les modifications sont validées dans la branche, celles-ci sont copiées de l’espace de travail local vers la branche.

 EMBED Image Microsoft Word 
Les conflits
Un conflit se produit lorsque deux utilisateurs ont modifié la même partie d’un fichier. Sa résolution est toujours à la charge du second utilisateur ayant réalisé la dernière modification. Pour éviter les conflits, une mise à jour régulière du serveur est nécessaire. Ce dernier garde toujours la version intègre du fichier qui ne prend pas en compte les conflits.
Le second utilisateur dispose en local des deux versions annotées par CVS. Il doit résoudre le conflit avec le premier utilisateur puis faire une mise à jour du serveur pour résoudre le conflit.

La synchronisation
Mettre à jour fréquemment sa copie locale permet d’éviter :
les collisions
de travailler en décalage avec les autres membres du projet.

Lors de la mise à jour de votre espace de travail vous pouvez rencontrer trois types de synchronisation :
Mode entrant : modifications contenues dans le référentiel à intégrer dans le workspace.
Mode sortant : modifications contenues dans le workspace à intégrer dans le référentiel.
Mode entrant/sortant : modifications dans le workspace et le référentiel à intégrer dans l'un et l'autre.
La vue de synchronisation permet de visualiser les conflits et met à disposition des outils pour les traiter.

 JBoss – Lomboz

Introduction

JBoss est un serveur d’applications Open Source créé par un français, Marc Fleury, qui vient concurrencer des produits tels que Websphere, Weblogic ou JOnAS. La philosophie de JBoss est la suivante: accroître la productivité des développeurs en centralisant autour de lui l'ensemble des technologies Java et des connecteurs aux différents systèmes externes, tout en respectant rigoureusement l'évolution et les orientations de SUN. JBoss essaye de rendre transparente cette complexité et il s'oriente ainsi vers une informatique plus souple. Cette souplesse permet à chacun d'adapter le serveur d'applications à ses besoins.
Comme tout serveur, un serveur d'applications fournit des réponses à des clients par l'intermédiaire de requêtes. Ces requêtes utilisent un service que JBoss met à disposition par le biais d'un port de communication en utilisant un protocole précis. Ces services peuvent fournir des EJB, des JSP, des messages... Mais la singularité du serveur d'applications, à la différence d'un serveur tel qu'apache, est de fournir non pas des pages HTML, mais des applications Web Java regroupant au sein d'un même « package » l'ensemble des services à fournir. Cette archive pourra être ainsi déployée sur l'ensemble des autres serveurs d'applications compatibles J2EE.
Un serveur d'applications est essentiellement un conteneur d'EJB (Entreprise JavaBean) c'est ce à quoi JBoss est destiné à la base. La force d'un tel produit réside dans sa capacité à ne laisser à la charge du développeur que l'écriture de l'EJB.

Le serveur s'occupera de tous les autres aspects de façon transparente :
Le déploiement et l'administration
La sécurité
Les transactions et la concurrence
Le management et le traçage
Le nommage des EJB
La persistance et les relations entre EJB

JMX (Java Management Extensions)

JMX est une interface permettant d'administrer des applications logicielles et des équipements ainsi qu'un bus de liaison entre les différents services de base. Son but est de fournir une API Java standard pour la gestion et la supervision des ressources.

Il définit une architecture de gestion sur trois niveaux d'abstraction :
Instrumentation : capacité à gérer tout objet (Mbean).
Agents de gestion : conteneurs hébergeant des services de gestion et pouvant les mettre à jour dynamiquement (Mbean server).
Services distribués : services de JBoss accessibles par un navigateur Web.
Si on édite le fichier de configuration de JMX (on accède à celle ci par le biais d'un navigateur web en tapant l'adresse : HYPERLINK "http://localhost:8080/"http://localhost:8080 ), on constate par ailleurs que, de manière évidente, chacun des services de JBoss (persistance, transaction, sécurité, interaction avec .net, ...) est vu comme un Mbean.
Un des atouts de JMX est sa gestion de la sécurité facilitant ainsi le codage. En effet, on peut se contenter de vérifier auprès du Mbean sécurité, que l'utilisateur appelant dispose bien du droit d'écriture en cas de modification d'EJB. Ce qui limite les soucis d'implémentation ou de respect d'une interface.
Les différents services de JBoss sont donc des Mbeans, ce qui donne une grande flexibilité et une grande adaptabilité à la plateforme JBoss. Il est par exemple possible, en cours d'exécution de JBoss, de modifier par le biais de la console d'administration JMX, les paramètres de fonctionnement d'un service.

JBoss, un ensemble de projets

JBoss n'est pas qu'un projet unique, mais plusieurs 'petits' projets qui se complètent les uns les autres. En voici une liste non exhaustive :

JBoss Server : c'est le coeur de JBoss. Son rôle est de gérer le noyau par l'intermédiaire du JMX mais également de fournir les conteneurs d'EJB.
JBoss MQ : c'est le composant implémentant l'API JMS, c'est à dire l'échange de messages entre applications et composants.
JBossDO : persistance des objets.
JBoss IIOP : mise en oeuvre de iiop qui est le protocole de communication entre un client et un EJB.
JBoss CMP : module permettant de gérer la connexion aux bases de données grâce à l'API JDBC.
JBossTX : il permet le support des moniteurs de transaction avec les API JTA/JTS.
JBoss JCA : implémentation de l'interface de connectivité JCA qui est une interface de communication (au même titre que JDBC pour les bases de données).
Tomcat : serveur Web utilisé par JBoss.
JBoss SX : composant dont le rôle est de gérer la sécurité grâce à l'ensemble d'API JAAS.
JBoss cache : gestion du cache afin d'améliorer les performances (notamment l'exploitation mémoire du serveur).
JBoss Xdoclet : afin de permettre un développement facilité des EJB grâce à une génération automatique de code.
JBoss IDE : intégration (par un plug-in) à l'IDE Eclipse.
Nukes on JBoss : système de gestion de contenu inspiré de Postnuke (PHP).

Comparatif des serveurs d'application

Parmi les serveurs d'applications les plus utilisés, nous trouvons WebSphere (IBM), Weblogic (BEA), Oracle (Oracle Corporation), .NET (Microsoft), JBoss (JBoss Inc.), et JOnAS (ObjectWeb).
Les tarifs pratiqués par les éditeurs de ces serveurs (hormis JBoss et JOnAS) sont relativement élevés (entre 10,000 et 16,000 ¬ ). Seuls JBoss et JOnAS sont sous licence GPL et sont gratuits, ce qui explique pourquoi ce sont les serveurs d'applications les plus utilisés malgré le fait qu'ils soient aussi parmi les moins performants d'entre tous.
Cependant, il est important de noter que JBoss et JOnAS sont totalement multi plates-formes, alors que les autres serveurs cités précédemment ne sont pas compatibles avec la plate-forme Mac.
Nous avons dû faire un choix entre JBoss et JOnAS. Nous avons choisi d'utiliser JBoss car ce serveur est en constante évolution, contrairement à JOnAS dont le développement n'est plus très actif à l'heure actuelle. De plus, JBoss est facile à installer, est certifié J2EE 1.4, et est peu gourmand en ressources.


Lomboz

Lomboz est un plug-in open-source pour Eclipse à destination des développeurs J2EE.
Il ajoute à Eclipse des assistants(cf. capture d'écran ci-dessous) pour la création de Servlets, de pages JSP (avec soulignage syntaxique et vérification de syntaxe) et d'EJB.

Assistants rajoutés par Lomboz dans Eclipse
Lors de l'utilisation d'un assistant, Lomboz génère automatiquement du code Java afin d'augmenter la productivité du développeur. A ces fins, ils génère plusieurs fichiers dont :
web.xml qui indique au serveur d'applications (Tomcat), entre autre, l'url du JSP à servir.
build.xml qui est un script Ant utilisé par Lomboz pour le déploiement et la construction de conteneurs.
target.xml qui contient la liste des serveurs d'applications cible du code J2EE
les autres fichiers servant en « interne » à Lomboz pour la génération de code.
CMS

Description d'un CMS

Un CMS (Content Management System) est un outil qui permet à plusieurs individus de travailler simultanément sur un ensemble de documents.
Il est possible de structurer le contenu tout en séparant les opérations de gestion de la forme et du fond, et de fournir une chaîne de publication. C'est le principe fondamental de la gestion de contenu pour garantir la cohérence, l'évolutivité et la robustesse.
Il offre, par l'intermédiaire d'un ensemble de scripts accessibles en général par un navigateur web, la possibilité d'administrer un site internet de façon dynamique (contrairement aux sites purement HTML, totalement statiques).
A travers cet outil, les administrateurs d'un site web ont donc, sans connaissances techniques spécifiques, la possibilité de créer, de manière intuitive, de nouvelles pages, de nouveaux chapitres, de supprimer ou de modifier certains contenus.
 EMBED OutPlace Object 

La conception se base sur les mécanismes suivants :

Utilisation d'interface web
Le web, accessible par tous à l'aide d'un browser (Netscape/Mozilla/Internet Explorer...), offre donc une présentation unifiée des données. La lecture, l'impression et le stockage sont ainsi autorisés ce qui facilite l'échange et l'accessibilité des documents.

Templates (Gabarits ou mise en page)
L'utilisation des Templates dans les langages de création de pages dynamiques sur Internet, autorise un modèle de document pour lequel on peut travailler indépendamment sur le contenu et la forme. Ils permettent aussi à l'utilisateur de personnaliser l'apparence, la structuration et la pertinence des informations à afficher. Une même mise en page partagée par plusieurs pages web, facilite l'évolution et contribue à l'homogénéité du site. L'aspect visuel doit pouvoir évoluer sans tenir compte du contenu, de même le contenu doit pouvoir être modifié sans changement de mise en page.

Syntaxe simplifiée
Grâce à une syntaxe simplifiée, l'utilisateur peut se concentrer sur le contenu. Les langages utilisés par les rédacteurs sont ainsi simplifiés. Le système de templates se chargeant de la plupart des opérations de mises en page, les indications de mise en page ne sont pas nécessaires.

Utilisations de base de données
Pour gérer l'information, il faut la stocker et pouvoir la retrouver rapidement. Tout cela sera géré par des bases de données . Il importera cependant de pouvoir accéder aux données contenues et de pouvoir les exploiter efficacement par l'intermédiaire du CMS choisi. La gestion de versions concurrentes est pour sa part assurée par les bases de données.

De multiples méthodes de rangement de l'information
Une grande abondance de données va rendre plus complexe la recherche d'une information parmi celles-ci. Un système de CMS doit donc posséder de multiples mécanismes de tri plus ou moins complexes comme :
les hyperliens
un moteur de recherche sur le texte,

Pour rendre plus accessible l'information, certains CMS offrent des moyens pour améliorer les méthodes de recherche (catégoriser l'information, l'indexer, utiliser des principes de classification systématiques), la multiplication des vues, des mécanismes de choix (diminue la profondeur de l'information, par rapport à la page d'entrée, en multipliant les chemins) ou encore une organisation du contenu sous forme de structures hiérarchiques arborescentes

Gestion des droits
Il est nécessaire de créer des associations entre droits de lecture, écriture ou entre validation de contenu et un utilisateur (selon son identité).
Sur la plupart des CMS doté d'une interface web, l'emplacement où le contenu est publié et celui permettant aux auteurs d'accéder à sa gestion sont identiques.

Existence de Workflows
Il existe dans les CMS divers outils participant à la gestion de la qualité de l'information (Workflow). L'un d'eux, la validation, pouvant s'échelonner à plusieurs niveaux (validation hiérarchique) permet de garder un certains contrôle sur les contenus, ce qui est très utile lorsque le nombre de contributeurs devient trop important.

Cycle de vie
Dans un CMS, un cycle de vie peut être associé aux éléments du contenu : une date de publication prévisionnelle, une date de fin de vie.
Finalement, une gestion très complète des documents dans le temps peut être définie.

Le framework
Certains CMS peuvent être utilisés comme plate-forme de développement.
Ces CMS, surtout développés en Java, disposent d'un socle de composants où sont greffés ses propres outils de gestion de contenu et de publication. En proposant une documentation complète, il est parfaitement envisageable de construire ses propres outils spécifiques. Il est aussi envisageable de modifier les composants de base propre au CMS.


 Le CMS, évolution convergente de la société de l'information

On peut dresser un historique sommaire des CMS :
Dans les années 90, l'arrivée de la notion WYSIWYG (« What You See Is What You Get ») constitua une révolution de la création de contenu.
La séparation du contenu et de la forme sera, plus tard, partiellement réalisée au moyen de feuilles de style (feuilles CSS ou Content Sheet Style en html).
L'introduction de documents hétérogènes, nécessitant une gestion unifiée des pièces incluses, nous amènera à l'utilisation de logiciels combinés dits systèmes de gestion électronique de documents et à l'édiction de normes de travail.

Evolution des CMS
Le CMS s'inscrit dans cette évolution générale, en combinant la création de contenu avec sa gestion, son archivage, et sa publication. Ainsi, nous répondons aux besoins suivants :
Gestion de versions concurrentes
Pour plusieurs personnes travaillant sur un même document, on voudrait savoir de qui provient une modification. Ceci est réalisé par un outil traçant les évolutions .
Multiplication des vues
Elle garantit un contenu personnalisé tout en exploitant le même contenu original en fonction des utilisateurs par exemple.
Travail collaboratif (groupware)
En cas de travail en équipe, il est intéressant de garder une trace historique matérialisable (par la couleur) permettant de connaître l'origine des modifications.

Multiplication des sources de contenu (syndication de site)
La syndication de site autorise la mutualisation des contenus de plusieurs organisations tout en présentant le contenu d'informations issues de sources différentes avec leur mise en page.

Commentaires devenant eux-mêmes sources d'information
Le commentaire, quand il est pertinent, fait évoluer les outils logiciels d'édition, et ceux-ci deviennent eux-même des sources d'information.

L'amélioration qualitative
Ce type de logiciel devrait améliorer certaines qualités :
la sécurité informatique
la qualité du code
la qualité des documents publiés
le respect des normes du web et de l'accessibilité
l'ergonomie.

Dix Critères pour bien choisir un CMS

La capacité des entreprises à communiquer sur le web dépend en partie d’un choix de CMS pertinent. Par conséquent, les critères de choix doivent être correctement pondérés en fonction de la nature de chaque projet.

1. Personnalisation éditoriale et fonctionnelle du front office (interface d'échange).
Il convient de créer une structure éditoriale, puis d'ajouter des modules fonctionnels spécifiques (sondages, annuaires, etc), afin de conserver la maîtrise du graphisme et des fonctionnalités.
Critère à ne pas négliger : Il est important de comparer la liste des besoins exprimés avec les fonctionnalités proposées par les solutions étudiées.

2. Personnalisation graphique du front office
L'architecture des templates graphiques est aussi un point sensible, car elle détermine une part importante des coûts de maintenance et d'évolution.

3. Personnalisation du back office
Grâce aux CMS, on obtient une bonne finesse de gestion des droits utilisateurs et de personnalisation des workflows offerts. Cependant, deux approches sont possibles : soit s’adapter à la logique du CMS choisi, soit être complètement libre, c'est-à-dire que la logique de l'entreprise ne dépend pas de celle du CMS.

4. Multilinguisme
Une autre fonctionnalité des CMS à prendre en compte est sa capacité à gérer plusieurs langues. Pour favoriser une bonne appropriation, le back office doit lui aussi être multilingue, ce qui n'est pas toujours le cas.

5. Choix de la plateforme technique
Un autre critère est de choisir la plateforme technique la plus adaptée, ce qui assure une bonne intégration au système d’information, la pérennité, l’ouverture, le respect des standards.

6. Choix de la base de données et format d'export
Le choix de la base de données utilisée est laissé à l'Entreprise selon son CMS.
Il y a aussi possibilité d'importer ou d'exporter le contenu de la base dans un format pivot, type XML, pour faciliter la reprise de l'existant importante.

7. Capacité à monter en charge
La capacité à monter en charge est fondamentale pour les sites à fort trafic. Il faut, par exemple pouvoir gérer un afflux massif de visiteurs sur un site web donné sur une période très courte.

8. Coût de création
Ce coût est à évaluer en regard du coût de possession.
Il correspond au budget qui sera alloué à l'achat du matériel, les coûts de licences et enfin les coûts de développement. Cela conduit donc à comparer la charge nécessaire à la mise en oeuvre de chaque solution ainsi que le coût des profils qui réaliseront le travail.

9. Coût de possession
Le calcul du coût de possession consiste à faire la somme des coûts de licences annuelles, des coûts d'hébergement et des coûts de maintenance. Moins la solution est répandue, plus son hébergement coûte cher.

10. Appropriation
Il s'agit du dernier critère présenté, mais peut-être un des plus importants pour les projets isolés, engendré par le risque humain lié à la mise en place du nouvel outil. En pratique, il s’agit de mesurer l’écart entre les habitudes des futurs utilisateurs et les nouveaux processus. Il peut être LE facteur clef de succès.

Montée en charge des CMS

La plupart des CMS proposent un système de cache qui répond au problème, en précalculant les pages et en les stockant au format HTML. Dans ce cas, les éléments à analyser sont l'architecture du cache et ses performances réelles, via des tests de montée en charge par exemple. Dans le cas contraire, il faut s'assurer qu'un système externe puisse être ajouté sans difficultés pour y pallier.
En ce qui concerne la montée en charge des CMS, il nous semble opportun de faire de plus amples tests en l'absence d'informations suffisamment pertinentes.

Conclusion

Le choix d'un CMS n'est pas trivial. Il est impossible de le choisir sans une étude d'opportunités, un cahier des charges et une idée réaliste de l'organisation cible.

C'est donc une décision devant associer le client interne à l'origine du besoin, la DSI (Direction des services d'information) et les futurs animateurs/producteurs de contenu. Il convient particulièrement de bien prendre garde à l'adéquation entre le CMS choisi, son ergonomie et les habitudes de développement des utilisateurs.

Enfin, un point à ne surtout pas négliger est le comportement du CMS cible face à des situations de montée en charge importante. Ils ne sont en effet pas tous égaux selon les contextes d'utilisation. L'usage qui en sera fait devra donc être clairement spécifié.


LENYA

Lenya est un logiciel de documents développé en Java, basé sur le framework Cocoon et manipulant des contenus XML. L'une des particularités de Lenya est que les données qu'il gère sont stockées dans des fichiers XML. Lenya ne nécessite pas de base de données pour fonctionner. Même les informations de structure comme les groupes et utilisateurs sont gérés en fichiers XML.
Une interface web permet la manipulation de documents XML, la gestion des utilisateurs et des groupes, la gestion des versions, la gestion des accès concurrents, la publication HTML, PDF, texte, éditeur WYSIWYG (pour du XML ou XHTML).

Lenya est puissant et paramétrable :
Le moteur de workflow est représentatif des possibilités de paramétrage de l'outil. Un workflow est défini dans un fichier xml, et définit tous les états possibles d'un document, avec toutes les transitions possibles et les droits d'actions.
N'importe quel workfow est alors possible, en parallèle, en série, avec n niveaux
de validation, avec la possibilité de rejet, d'archivage, de suppression,...

Apache Lenya est un gestionnaire de documents XML, avec les outils nécessaires d'édition et de publication. Il est entièrement adapté pour la gestion de documentation structurée ou non structurée, en environnement multi-utilisateurs.

CMS Magnolia 2.0


Généralités

Magnolia est un CMS open-source développé en Java par la société Obinary puis, repris par la société Magnolia International. Il est l'un des tous premiers CMS à avoir été développé pour respecter les spécifications définies par la JSR 170 qui permet un accès au contenu de façon standardisée. Cette nouvelle norme est la JCR Java Content Repository.

La JSR 170 (Java specification request) permet de définir une API pour permettre l'accès au référentiel de contenu nommé JCR. Ce standard a été défini dans le but de permettre à tous ceux qui souhaitent développer de nouveaux CMS, de se mettre en conformité avec les spécifications définies par SUN pour l'accès au contenu. En réalité, la grande majorité de gestionnaires de contenus ont des données de différents formats, ainsi que des plates-formes d'exécution variées. Les problèmes d'accès aux données proviennent de ces différences. La définition de ce standard est donc de remédier à ces problèmes.

Caractéristiques

Le CMS magnolia 2.0 nécessite un environnement de programmation JDK 1.4.1 ou ultérieur. Il fonctionne avec quasiment tous les navigateurs récents.



Caractéristiques côté Administrateur
Édition en ligne instantanée : pas besoin de mettre certaines pages d'un site hors ligne pour pouvoir les modifier. Il suffit de remettre à jour le site avec les nouvelles pages ainsi modifiées.

Gestion des rôles d'utilisateurs : l'administrateur peut définir des rôles et les attribuer aux clients pour contrôler l'accès à certaines données. Utile pour un site gérant les droits d'accès à certaines de ses sous- parties.

Enregistrement automatique des meta-data : les meta-data sont des données sur les données. C'est à dire des informations sur le contenu : nom d'auteur, numéro de version d'un document, de la date de saisie, etc. Une sauvegarde automatique des meta-data est possible avec Magnolia.

Adresses web virtuelles statiques: les adresses web définies par Magnolia ne sont pas distinguables des adresses statiques classiques. Cela permet d'avoir les même fonctionnalités sur ces adresses que pour les adresses classiques : communication, bookmark, indexation dans les moteurs de recherche. La liste de ces fonctionnalités n'est pas exhaustive.

Caractéristiques côté Développeurs
Modèle standards (templates) : ils sont basés sur les normes d'écritures JSP et Servlets. Facile d'emploi même pour un non informaticien.

Librairies personnalisables : on peut se constituer une librairie qui permet de personnaliser l'environnement et de supporter des librairies importées (third-party tag libraries) afin de réutiliser des environnement pré-existant et ainsi de limiter le code à écrire.

Technologie JCR : comme expliqué précédemment, Magnolia a été développé pour une complète compatibilité et standardisation avec la norme JCR.

Java/J2EE : Magnolia étant un logiciel écrit en Java, il est compatible avec la technologie J2EE.

Caractéristiques concernant la Montée en charge
La capacité de Magnolia à supporter une fréquentation engendrant une forte demande d'accès au contenu d'un site (montée en charge) n'étant pas connue, la prudence est toujours de rigueur, même s'il apparaît possible de réaliser cela (à l'image du site de HYPERLINK "http://www.Magnolia.info/"www.Magnolia.info réalisé avec ce même logiciel). Magnolia offre un système de cache minimisant les temps d'accès aux données. J2EE
Java 2 Entreprise Edition

La plate-forme J2EE

La plate-forme J2EE est essentiellement un environnement de serveurs d’applications distribuées, c’est-à-dire un environnement Java fournissant les outils suivants :
Une infrastructure d’exécution pour héberger des applications;
Un ensemble d’API Java pour concevoir des applications.
Dans les applications à architecture distribuée, les fonctions sont réparties entre plusieurs systèmes. On les appelle aussi architectures multi-tiers.



La plate-forme J2EE offre de nombreux avantages aux entreprises :
Elle propose des normes pour l'informatique d'entreprise comme la connectivité aux bases de données, les composants métier, le middleware (logiciel intermédiaire) orienté message (MOM), les composants liés au Web, les protocoles de communication et l'interopérabilité de tous ces composants.
Elle permet de promouvoir de meilleures implémentations, sur la base de standards ouverts, protégeant ainsi d'éventuels investissements technologiques.
Elle offre un espace standard de travail destiné à la création de composants logiciels portables sur diverses implémentations.
Elle permet de réduire le temps de développement. La plus grande partie de l'infrastructure et de l'activité de liaison est fournie par les produits des fabricants, implémentés selon la spécification J2EE. Les sociétés de service sont maintenant à même de se décharger des activités liées au middleware et de se concentrer sur la création d'applications spécifiques.
Elle améliore la productivité des développeurs, ceux-ci pouvant apprendre plus facilement les technologies J2EE basées sur le langage Java. L'ensemble du développement de logiciels d'entreprise peut désormais s'accomplir en Java sur plate-forme J2EE.
Elle favorise aussi l'interopérabilité entre environnements hétérogènes existants.

Environnement d’exécution : les conteneurs

Un conteneur J2EE offre de nombreuses fonctionnalités. C'est un environnement d’exécution Java chargé de gérer des composants applicatifs et de donner accès aux API J2EE.
Il existe deux types de conteneurs:
Conteneurs Web utilisés pour héberger des servlets ou des pages JSP.
Conteneurs EJB utilisés pour héberger des composants Entreprise Java Bean.
J2EE comporte également deux autres types de conteneurs :
Un conteneur d’applets permettant d’exécuter des applets Java.
Un conteneur d’applications clientes permettant d’exécuter des applications classiques côté client.
Un conteneur offre des interfaces définissant les spécificités du composant (Contrat Container).
Il gère :
- des API :
API de services : accès SGBD, annuaires, gestionnaires de transactions...
API de communication : protocole Internet, envoi de messages ou de mail, accès à des objets distants...
- des composants d’application :
Servlets
JSP
EJB.
- des descripteurs de déploiement :
Fichier XML décrivant le composant d’application.
Informations additionnelles requises par le container pour gérer les composants d’application.

J2EE est une norme définissant une infrastructure et des services via une API normalisée.





LES API J2EE

Ce sont des interfaces de programmation fournissant un ensemble de fonctions ou de classes normalisées et documentées. Ceci permet à des applications d’utiliser les fonctionnalités offertes par un produit, un composant, ou une librairie.
Les différentes API :
Java Servlet : services web.
JSP : présentation des pages web.
EJB : les beans.
JAF : intégration des JavaBeans.
JDBC : accès aux bases de données.
RMI : accès et exécution distants.
JNDI : gestion de noms et d’annuaire.
JMS : gestion de messages.
JTA/JTS : gestion de transactions.
JavaMail : gestion du courrier électronique.
JAAS : gestion de la sécurité, authentification et droits d’accès.
JAXP : gestion de documents XML.

Servlets

Qu'est-ce qu'une servlet ?
C’est une technologie JAVA destinée à réaliser des traitements « côté serveur » sans interface utilisateur, en réponse aux requêtes de postes distants.
Une servlet est une classe Java qui étend de manière dynamique les fonctions d’un serveur Web. Elle offre accès à toutes les APIs des classes JAVA.
Elle est invoquée pour traiter une requête formulée via un client Web (requête HTTP). Le serveur Web associe une ou plusieurs URLs à chaque servlet et lorsque ces URLs sont appelées (requête HTTP), la servlet est déclenchée.
Elle s’exécute dans le contexte d’une machine virtuelle Java gérée par le moteur de servlets. Une servlet chargée dans la machine virtuelle est mise en cache, en attente d’autres requêtes.

Cycle de vie d'une servlet
Tout comme les applets du côté client, les servlets adoptent du côté serveur un cycle de vie parfaitement défini. Trois types d’événements peuvent survenir durant la vie d’une servlet. Chacun correspond à une méthode invoquée par le moteur de servlets :
init() : le moteur de servlet appelle une et une seule fois la méthode init(), au premier chargement de celle-ci.
Service() : c’est le cœur de la servlet, l’endroit où les requêtes sont traitées. Pour chaque requête adressée à la servlet, le moteur de servlet appelle la méthode service() de cette dernière en lui passant des références sur un objet requête et un objet réponse.
Destroy() : cette méthode est appelée par le moteur de servlets quand celle-ci est sur le point d’être déchargée. Elle s'occupe de la libération des ressources allouées lors de l’appel à init().

Un développeur de servlet utilise l'API servlet pour :
Initialiser et finaliser la servlet.
Accéder à l’environnement de la servlet.
Recevoir ou rediriger les requêtes et envoyer les réponses.
Interagir avec d'autres servlets ou composants.
Maintenir les informations de sessions du client.
Filtrer avant ou après traitement les requêtes et les réponses.
Implémenter la sécurité sur le tiers web (dans l'architecture multi-tiers).

JSP (Java Server Pages)

Besoins
JSP (Java Server Pages) est un standard permettant de développer des applications Web interactives (dont le contenu est dynamique).

Fonctionnalités
JSP est un langage de script puissant exécuté du côté du HYPERLINK "http://www.commentcamarche.net/initiation/client.php3"serveur (au même titre que les scripts HYPERLINK "http://www.commentcamarche.net/cgi/cgiintro.php3"CGI, HYPERLINK "http://www.commentcamarche.net/php/phpintro.php3"PHP,...) et non du côté client. Les scripts écrits en HYPERLINK "http://www.commentcamarche.net/jsp/javascript/jsintro.php3"JavaScript ou les applets HYPERLINK "http://www.commentcamarche.net/java/javaintro.php3"Java s'exécutent dans le navigateur du client.
Une page JSP (d'extension .jsp) a un contenu variant selon certains paramètres (informations stockées dans une base de données, préférences de l'utilisateur...), tandis qu’une page Web "classique" (d'extension .htm, .html...) affichera toujours la même information.
Les JSP sont intégrables au sein d'une page Web en HYPERLINK "http://www.commentcamarche.net/html/htmlintro.php3"HTML à l'aide de balises spécifiques permettant au serveur Web de savoir que le code compris entre celles-ci doit être interprété afin de renvoyer du code HTML au navigateur du client.
Ainsi, les Java Server Pages s'inscrivent dans une « architecture trois-tiers » : un serveur supportant les Java Server Pages peut servir d'intermédiaire (serveur applicatif) entre le navigateur du client et une base de données (serveur de données), permettant un accès transparent à celle-ci. JSP fournit ainsi les éléments nécessaires à la connexion au système de gestion de bases de données.
Fonctionnement
Les JSP sont un moyen d'écrire des servlets. En effet, lors d'une requête utilisateur à une page JSP, celle-ci est exécutée par un moteur JSP, fonctionnant avec le serveur Web ou le serveur applicatif. Ce moteur crée un code source Java à partir du script JSP, compile la classe afin de fournir un fichier compilé (d'extension .class), générant ainsi une servlet.
Constitution d' une servlet à partir du script JSP :
1. Ecriture du code source d'une servlet.
2. Compilation du code source.
3. Chargement de la servlet compilée et traitement de la demande du client.
4. Retour au client de la réponse de la servlet générée.
En réalité, ce processus est un peu plus perfectionné. Le moteur de JSP vérifie la correspondance de date entre le fichier .jsp et le fichier .class. Le moteur JSP ne transforme et ne compile la classe qu'en cas de modification du script JSP. Finalement, cette technologie est une des plus rapides pour créer des pages dynamiques, la compilation n'ayant lieu qu'en cas de mise à jour du script JSP.

Caractéristiques
Les JSP facilitent l'écriture des servlets en incluant dans des balises spécifiques le code JSP au sein du fichier HTML. De cette façon, elles fournissent une technologie rapide afin de créer des pages dynamiques.
De plus, les JSP possèdent toutes les caractéristiques faisant la force de Java :
portabilité
orientation objet
sécurité ...

EJB

Les composants
Définition usuelle et propriétés
module logiciel autonome installable sur différentes plates-formes
export de différents attributs, propriétés ou méthodes
configurable

Intérêt
Les composants sont des briques de base permettant la construction d’une application par composition.

Les EJBs
Il s’agit d’une architecture adaptée à la création d’applications réparties. Chaque composant, appelé client distant, est exécuté sur un serveur. Ils n’ont rien à voir avec les JavaBeans, qui sont eux des composants situés côté client.
Ceci rend une application facile à développer, déployer et administrer, le tout indépendamment de sa plate-forme d´exécution. Le déploiement d’une Entreprise Bean (EB) s'effectue sans recompilation ni modification du code source.
Une spécification EJB est ainsi la définition d’une architecture pour construire une application en Java dont la partie serveur est construite à l’aide de composants appelés Entreprise Bean (EB).
 On peut alors dire que EJB est la partie centrale de la plate-forme J2EE.

Architecture du serveur EJB

L’architecture EJB identifie les éléments suivants :
Composants logiciels ou EB,
Conteneurs,
Serveurs,
Clients.
Les conteneurs isolent les beans du client et ceux d’une implémentation spécifique d’un serveur. Les conteneurs et serveurs implémentent des mécanismes de bas niveau utilisés par les applications.

Caractéristiques principales
Les composants EJB sont structurés en hiérarchie. Au premier niveau, on compte trois catégories de composants EJB:

Les EJB Session Beans sont utilisés pour représenter les données d'un client et les comportements qui leur sont associés. Comparer ce type d'objets à la notion de session au niveau des conteneurs de servlets est relativement réducteur. Par exemple, un conteneur de servlets ne gère pas l'activation/passivation de vos sessions au contraire d'un conteneur d'EJB. Il en va de même pour la gestion de la sécurité et des transactions. Ainsi, un caddie virtuel, pour un site marchand, pourrait être implémenté sous forme d'EJB session.
· Les EJB Entity Bean permettent de représenter une donnée persistante ayant une existence sur un support de stockage comme une base de données relationnelle. Ainsi, les articles stockés dans le caddie virtuel peuvent être implémentés sous forme de composants EJB entités.
Enfin, les EJB Messages Beans, apparus avec le standard EJB 2.0, permettent la mise en œuvre d'applications basées sur un traitement asynchrone de messages. Pour fonctionner, une application utilisant ce type de composants devra s'appuyer sur un service JMS (Java Messages Service).
Les EJB sessions
Les catégories présentées sont elles-mêmes subdivisées en sous catégories. Deux sous-catégories coexistent parmi les EJB Sessions : les EJB Session avec état et ceux sans état.
Les EJB Session avec état (stateful) : Ce type d'objet EJB maintient des données en mémoire pour un client. Un tel objet est unique pour chaque utilisateur. En cas de défaut de mémoire, le conteneur d'EJB peut passiver (décharger de la mémoire vers un support de stockage secondaire) les EJB momentanément inutilisés. Lors de la manipulation de ces objets, le conteneur pourra les activer (recharger d'un support de stockage secondaire vers la mémoire). Il est donc possible d'avoir une gestion rationnelle de la mémoire avec ce type de composant. Il n'est pas nécessaire de savoir où sont passivés les objets momentanément inutilisés : le conteneur d'EJB s'en charge. Dans l'exemple du caddie virtuel, il y a autant d'objets Session avec états instanciés (activés ou passivés) que d'utilisateurs.
Les EJB Session sans états (stateless) sont utilisés pour représenter un client le temps d'un traitement. Seul le comportement de l'EJB nous intéresse et l'état de l'objet ne pourra être garanti. Dans ce cas, il est envisageable d'utiliser l'EJB pour un client, et ensuite pour un autre. Cela limite le nombre d'instances créées et détruites, le conteneur pouvant gérer un pool de composants EJB stateless.
Les EJB entité
Les EJB entités sont eux aussi divisés en deux sous-catégories : les beans entités CMP (Container Managed Persistance) et les beans entités BMP (Bean Managed Persistance).
- Les EJB entités CMP délèguent la persistance des données au conteneur d'EJB. Aucun code JDBC n'est à fournir.
- Les EJB entités BMP prennent en charge l'accès aux bases de données. Les périodes de synchronisation de l'EJB avec la base sont gérées par le container.
Une autre caractéristique des EJB est la définition de contrats associés à un bean. Ces contrats sont passés entre le conteneur et le client utilisant le bean.
Côté client, le contrat présente une vision uniforme du bean au client. Celle-ci est indépendante de la plate-forme de déploiement. Le conteneur implémente le mécanisme de délégation permettant de faire suivre l’appel au bean. Ainsi, le client ne communique pas directement avec le bean mais avec le conteneur.
L’EJB conteneur permet pour sa part la gestion du cycle de vie, la gestion de l’état, la sécurité, l’extensibilité. Ces services font appel à des méthodes fournies par le bean, le conteneur gérant la vie du bean.

Mise en oeuvre d'un EJB
Tout EJB est constitué de trois fichiers (voire de cinq). Une unique classe est en fait fournie, les autres fichiers permettant de spécifier des interfaces distantes (tout comme avec RMI).
- Une interface dite "de fabrique" : elle permet la construction d'un composant EBJ (factory).
- Une interface dite "métier" : elle permet de définir les services que propose le composant EJB.
- Le bean à proprement parlé, implémente les deux interfaces précédentes.

Un autre fichier peut être utile : le descripteur de déploiement non intégré au bean. Ce fichier contient des informations nécessaires au conteneur d'EJB qui va recevoir le bean. Ce fichier qualifiera la nature du bean d'entreprise et décrira les aspects liés à la sécurité d'utilisation de ce dernier et son utilisation au sein de transactions. De manière générale, les différents serveurs d'applications fournissent des outils d'édition pour ce fichier structuré en HYPERLINK "http://www.infini-fr.com/Sciences/Informatique/Reseaux/Internet/WorldWideWeb/Xml/index.html"XML.
Empaquetage et déploiement des applications J2EE
A l'instar des servlets des pages jsp, les composants EJB seront empaquetés dans des archives Java de façon à être déployés sur un serveur d'applications J2EE.
Les EJB sont stockés dans une archive d'objet métier (d'extension ".jar"). Un descripteur de déploiement est requis : les outils de développement utilisés sont capables de générer ces fichiers. Cette archive doit être stockée dans une archive d'entreprise d'extension ".ear" (Enterprise ARchive). Au final, c'est ce fichier qui sera déployé sur le serveur d'applications.
JDBC (Java Database Connectivity)

La technologie JDBC est une API fournie avec HYPERLINK "http://www.commentcamarche.net/java/javaintro.php3"Java permettant de se connecter à des bases de données, elle constitue un ensemble de HYPERLINK "http://www.commentcamarche.net/java/javaclass.php3"classes permettant de développer des applications aptes à se connecter à des serveurs de HYPERLINK "http://www.commentcamarche.net/bdd/bddintro.php3"bases de données (HYPERLINK "http://www.commentcamarche.net/bdd/bddintro.php3"SGBD).
L'API JDBC a été développée afin d'offrir une interface normalisée de connexion vers n'importe quelle base de données (l'API JDBC est indépendante du SGBD).
De plus, JDBC bénéficie des avantages de Java, dont la portabilité du code, offrant l'indépendance vis à vis de la base de données et de la plate-forme d'exécution.

Pilote de base de données :
Les pilotes JDBC actuels sont classés en quatre catégories :
Type 1 : Un pont JDBC-ODBC convertissant les appels JDBC en appel ODBC (Open Database Connectivity). ODBC assure la connexion à des bases de natures diverses (Access, SQL Server, Oracle, ...).
Type 2 : Des pilotes d'API natifs. Il s'agit d'un mélange de pilotes natifs et de pilotes Java. Les appels JDBC sont convertis en appels natifs pour le serveur de bases de données (Oracle, Sybase, ou autres).
Type 3 : Des pilotes convertissant les appels JDBC en un protocole indépendant traduit ensuite en protocole du SGBD par un serveur.
Type 4 : Des pilotes convertissant les appels JDBC directement dans le protocoles de communication utilisés par le SGBD.

Les pilotes JDBC sont fournis par le fabricant de bases de données. Il est donc possible de réutiliser une application avec une autre base de données, en basculant simplement vers un autre pilote JDBC.

Utilisation de JDBC :
L’utilisation de JDBC est faite soit par le conteneur d’application (Container Managed Persistence) soit directement dans le bean (Bean Managed Persistence).
L’utilisation typique de JDBC dans une classe java est la suivante :
Chargement du driver
Connexion à la base
Expression d’une requête
Analyse éventuelle du résultat
Déconnexion

RMI (accès/exécution d'appels distants (Remote Methode Invocation)

Qu'est-ce que RMI ?
RMI est une API Java de manipulation d'objets distants (objet instancié sur une autre machine virtuelle, éventuellement sur une autre machine du réseau) de manière transparente pour l'utilisateur, de la même façon que si l'objet était sur la machine virtuelle (JVM) de la machine locale.

Ainsi un serveur permet à un client d'invoquer des méthodes à distance sur un objet qu'il instancie. Deux machines virtuelles sont donc nécessaires (une sur le serveur et une sur le client) et l'ensemble des communications se fait en Java.

RMI est une solution "tout Java", contrairement à la norme Corba de l'OMG (Object Management Group) permettant de manipuler des objets à distance avec n'importe quel langage. Corba est toutefois assez compliqué à mettre en oeuvre, c'est la raison pour laquelle de nombreux développeurs se tournent généralement vers RMI.

Les connexions et les transferts de données dans RMI sont effectués par Java sur TCP/IP grâce à un protocole propriétaire (JRMP, Java Remote Method Protocol) sur le port 1099.A partir de Java 2 version 1.3, les communications entre client et serveur s'effectuent grâce au protocole RMI-IIOP (Internet Inter-Orb Protocol), un protocole normalisé par l'OMG (Object Management Group) et utilisé dans l'architecture CORBA.

Structure des couches RMI
Le stub (traduisez souche) et le skeleton (traduisez squelette), respectivement sur le client et le serveur, assurent la conversion des communications avec l'objet distant.
La couche de référence (RRL, remote Reference Layer) est chargé du système de localisation afin de fournir aux objets un moyen d'obtenir une référence à l'objet distant. Elle est assurée par le package java.rmi.Naming. On l'appelle généralement registre RMI car elle référence les objets.
La couche de transport sert à écouter les appels entrants ainsi qu'à établir les connexions et le transport des données sur le réseau par l'intermédiaire du protocole TCP. Les packages java.net.Socket et java.net.SocketServer assurent implicitement cette fonction.

Ainsi, une application client-serveur basé sur RMI met en oeuvre trois composantes :
une application cliente implémentant le stub
une application serveur implémentant le skeleton (squelette)
une application médiatrice (le registre RMI) servie par un processus tiers (rmiregistry)

Architecture de RMI
L'architecture de RMI est schématisée ci-dessous :

Lorsqu'un objet instancié sur une machine cliente désire accéder à des méthodes d'un objet distant, il effectue les opérations suivantes :
1. il localise l'objet distant grâce à un service de désignation : le registre RMI
2. il obtient dynamiquement une image virtuelle de l'objet distant (appelée stub). Le stub possède exactement la même interface que l'objet distant.
3. Le stub transforme l'appel de la méthode distante en une suite d'octets (sérialisation), puis la transmet au serveur instanciant l'objet sous forme de flot de données. On dit que le stub "marshalise" les arguments de la méthode distante.
4. Le squelette instancié sur le serveur "désérialise" les données envoyées par le stub (il les "démarshalise"), puis appelle la méthode en local
5. Le squelette récupère les données renvoyées par la méthode (type de base, objet ou exception) puis les « marshalise »
6. le stub « démarshalise » les données provenant du squelette et les transmet à l'objet faisant l'appel de méthode à distance.

Mise en oeuvre de RMI
Pour créer une application avec RMI il suffit de procéder comme suit :
1. définir la classe distante. Celle-ci doit dériver de java.rmi.server.UnicastRemoteObject (utilisant elle-même les classes Socket et SocketServer, permettant la communication par protocole TCP)
2. définir l'interface pour la classe distante. Celle-ci doit implémenter l'interface java.rmi.Remote et déclarer les méthodes publiques globales de l'objet, c'est-à-dire les méthodes partageables. De plus ces méthodes doivent pouvoir lancer une exception de type java.rmi.RemoteException.
3. créer les classes pour le stub et le squelette grâce à la commande rmic
4. Lancer le registre RMI et lancer l'application serveur, c'est-à-dire instancier l'objet distant. Lors de l'instanciation celui-ci créera un lien avec le registre
5. Créer un programme client capable d'accéder aux méthodes d'un objet sur le serveur grâce à la méthode Naming.lookup()
6. Compiler l'application cliente
7. Instancier le client

Documentation :
“Thread/rmi” de Y. Bekkers dans le polycopié POP (C103).
JNDI : gestion de noms et d’annuaire

JNDI (Java Naming and Directory Interface) est une API ( Application Programming Interface)définie dans le package javax.naming.

Qu’est ce que JNDI ?
C’est une interface conçue de manière à être indépendante de tout service de noms ou d’annuaires spécifiques (NDS, ADS, LDAP …). Ainsi, par analogie avec JDBC capable d’utiliser n’importe quelle SGBD, une application Java est capable d’utiliser tout service de noms et d’annuaires. De la même manière, une application java est capable, grâce à JDBC, d’utiliser n’importe quelle SGBD.

Utilisation :
Tout serveur d’application dispose d’un service d’association de noms symboliques à des objets, facilitant ainsi leur utilisation: Les objets métier, que les applications d’entreprise manipulent, possèdent leurs propres identités, présentés sous la forme d’identificateurs d’objets compliqués (dans le sens où ils ont la forme de centaines de caractères, sans sémantique pour l'utilisateur).

Les services d’annuaire (ex : LDAP):
Un service d’annuaire associe non seulement des références d’objets à des noms, mais en plus autorise de tels objets à avoir des attributs. Ainsi, en plus de la recherche des objets par leurs noms, l’utilisateur peut rechercher des objets en fonction des valeurs de leurs attributs.
Un objet d’annuaire peut être n’importe quel type d’objet de l’entreprise (ex: imprimante, ordinateur, réseau..). Les attributs de ces objets peuvent être les couleurs, la résolution et la vitesse (imprimante), le n° de téléphone ou le mail de l’utilisateur.

Documentation:
LDAP: service d’annuaire HYPERLINK "http://www.openldap.org/"http://www.openldap.org

Java Authentification and Authorization Service (JAAS)

JAAS est un ensemble d’API pouvant être utilisées pour deux choses :
L’identification d’utilisateurs, afin de connaître l'utilisateur d'une portion de code, que ce code soit inclus dans une application, une applet, un bean ou une servlet…
L’autorisation des utilisateurs pour gérer les droits d’accès à certaines actions.

La gestion de l’identification par l’API JAAS peut être faite de façon indépendante de la technologie utilisée.
Les classes et les interfaces utilisées par l’API JAAS peuvent être classées en 3 catégories :
Les classes communes utilisées à la fois pour l’identification et l’autorisation. La classe principale est javax.security.auth.Subject. Elle représente un groupement d’informations utiles pour une entité comme une personne. Pour autoriser l’accès à des ressources , les applications ont besoin d’authentifier la source de la requête. L’API JAAS définit cette source par le terme Subject . Ce peut être une personne ou un service. Une fois que le subject est authentifié, il est associé à une identité, dénommée Principals par la classe Javax.security.auth.Subject. Un Subject peut avoir bien entendu plusieurs Principals. Un subject peut aussi avoir des attributs de sécurité appelés credentials.
Les classes et interfaces d’authentification. Pour authentifier un subject, l’application utilise un LoginContext contenant les méthodes usuelles pour authentifier une personne ou un service. Le LoginContext va alors consulter la Configuration où sont répertoriés les LoginModules dont l’application aura besoin, et qui permettront d’authentifier chaque utilisateur. Il peut y avoir plusieurs modules, chacun ayant la possibilité d'utiliser une technologie différente.


Les classes d’autorisation: Pour autoriser des accès sur des personnes ou des services avec l'API JAAS, il faut que l’utilisateur soit authentifié et que le résultat de l’authentification rattache l’utilisateur à une identité. Ensuite, les droits d’accès sont configurés par la classe Policy et AuthPermission.

JAXP: Java API for XML Parsing
Qu’est-ce que XML ?
L’abréviation signifie Extensible Markup Language.
C’est un standard de représentation des données. Comme son nom l’indique, XML est un langage extensible; il est par conséquent problématique d’en donner une définition précise, celui-ci étant en constante évolution et de nouvelles techniques s’y ajoutant sans cesse.
On peut toutefois définir plus précisément ce qui constitue la notion centrale d’XML, à savoir le document XML. Celui-ci peut-être visualisé de deux façons:
comme une séquence linéaire de caractères contenant des données textuelles et des balises de structuration.
comme une structure abstraite de données en arborescence de nœuds
Pour passer d’une vue à l’autre, on utilise un parseur XML, autrement dit un analyseur syntaxique.

Analyse syntaxique du XML
Le terme ‘Parsing’ signifiant analyse syntaxique, cela donne une idée sur l’utilité de l’API JAXP. Plus précisément, JAXP permet d’informatiser le traitement des documents XML, lesquels sont analysés au moyen des API SAX (Simple API for XML) et DOM (Document Object Model) puis transformés grâce à l’API XSLT.
SAX est une API ‘orientée flux’, elle transmet aux applications les informations et la structure des documents XML au fur et à mesure de leur analyse syntaxique. Ses principaux avantages sont la facilité avec laquelle on peut chaîner différentes opérations sur les structures XML et l'absence de nécessité de conserver en mémoire le document complet. Son principal inconvénient viendra des difficultés de manipulation de documents.
DOM utilise SAX pour représenter un document XML sous la forme d’un arbre en mémoire et de manipuler cet arbre de façon simple à implémenter. Le document étant accessible en mémoire dans une structure d’objet, un des principaux avantages est de pouvoir le manipuler de manière très sophistiquée. Son principal inconvénient est que le document complet doit rester en mémoire. Enfin, XSLT permet le passage de XML à HTML ou XHTML. STRUTS

Struts est un projet open-source géré par le groupe Jakarta, responsable entre autre de PHP et du serveur HTTP Apache. Jakarta est un groupe dédié aux technologies Java côté serveur. Struts est un environnement de développement Java combinant deux technologies, JSP et Servlets, en une implémentation MVC (Modèle-Vue-Contrôleur, ou Model-View-Controler), dans le but de séparer la présentation, les données et les transactions.

Les Frameworks
Les frameworks sont des squelettes d'application qui définissent des cadres dans lesquels viennent s'insérer les objets et concepts spécifiques à une application.
En pratique, un framework est un ensemble de classes et de mécanismes associés à une architecture logicielle qui fournissent aux applications un ou plusieurs services techniques.
Alors qu'un framework métier fournit des services à forte plus value fonctionnelle (gestion de clients, d'abonnements, de news, …), un framework technique apporte les concepts, entités et mécanismes qui permettent, dans le cadre d'une architecture logicielle retenue, de s'abstraire d'un certain nombre de problématiques conceptuelles et techniques récurrentes.

La conception MVC
Le modèle de conception Modèle-Vue-Contrôleur se décompose, comme son nom l'indique, en trois composants:

ComposantDescriptionModèle Contient les objets représentant les données, c'est à dire toutes les fonctionnalités de l'application.Vue Représente l'état actuel du modèle, son aspectContrôleur Gère les interactions utilisateur/interface, créé et manipule le modèle et ses
objets.

Le Modèle
Celui d'une application est composé de deux sous-systèmes: l'état interne du système et les actions possibles pour modifier cet état. Struts permet d'utiliser de nombreuses approches différentes pour accéder au Modèle, comme les JavaBeans (ou les EJB), les classes ou une base de données. Cela dépend généralement de la taille du projet et de l'approche la plus adaptée.

La Vue
Elle est construite à l'aide de pages JSP contenant du texte HTML ou XML statique, et ayant la capacité d'y insérer selon les requêtes du contenu dynamique. Struts comprend une bibliothèque interne de balises qui facilitent la création d'interfaces utilisateur, et interagissent sans problème avec le Modèle. C'est généralement une page JSP.

Le Contrôleur
C'est le composant le plus important d'une application Struts, c'est lui le centre névralgique. Ce Servlet délègue les requêtes HTTP vers le gestionnaire approprié, qui est lié à un Modèle. Ainsi, chaque gestionnaire agit comme un adaptateur entre la requête et le Modèle. Le Contrôleur passe ensuite par la Vue pour gérer le Modèle, ce qui créé une forme de liaison entre Vue et Modèle. Les composants de STRUTS dans un exemple
La classe servant de contrôleur principal est déjà fournie dans les archives du framework : il s'agit de la classe org.apache.struts.action.ActionServlet
Dans le cas de la création d'un formulaire de saisie, les données sont transférées à l'action en utilisant une instance dérivée d'ActionForm. L'association entre cette instance, l'URL demandée et l'action est définit dans le fichier de configuration Struts-config.xml.

Les vues sont mises en œuvre par l'intermédiaire de JSP, de même l'association, l'action et la vue présentant le résultat sont configurés au niveau du fichier Struts-config.xml.

On peut noter aussi que ce modèle nous laisse la liberté d'utiliser des composants EJB (Enterprise Java Bean) qui permet principalement de dégager le développeur du codage de certains services d'infrastruture : gestion de la persistance des informations, gestion de la sécurité, gestion de transactions logicielles, utilisation de services d'envoie des messages, … Ces services sont fournis par le serveur d'applications qui se configure par l'intermédiaire de descripteurs de déploiement (fichiers XML).
Dans ce cas, un simple conteneur d'objets Web tel que Tomcat n'est plus suffisant : Un serveur d'applications complet tel que JBoss est obligatoire.


Struts permet donc aux développeurs de construire des services sans se soucier du HTML qui l'entoure. Plusieurs Vues peuvent être utilisées, permettant l'accès à l'application pour un plus grand nombre de plate-formes, du Web traditionnel (HTTP) aux technologies sans fil (WAP, iMode, Palm). De plus, le développement peut ainsi totalement être dissocié entre contrôleur (Java) et vues (HTML + JSP).


Les répertoires
L'une des spécificités de Struts est la structure des répertoires d'une application, qui provient des applications web définies par Sun dans sa spécification des Servlets. Cette structure se décompose principalement en un répertoire racine, un répertoire secondaire et deux sous-répertoires:



RépertoiresDescription /monApplication  fichiers HTML et JSP /monApplication/WEB-INF ressources de l'application /monApplication/WEB-INF/classes servlets et classes /monApplication/WEB-INF/lib fichier JAR
Le fichier web.xml, qui se trouve dans le répertoire /monApplication/WEB-INF, est le descripteur de déploiement: il décrit tous les composants de l'application Web.

exemple :




action

org.apache.struts.action.ActionServlet


config
/WEB-INF/struts-config.xml



action
*.do


/WEB-INF/struts-html.tld
/WEB-INF/struts-html.tld


L' Extreme Programming (XP)

Introduction
L'Extreme Programming (XP) est une méthode de développement dédiée à de petites équipes confrontées à un environnement changeant ou des besoins mal connus. Cette méthode est née sur le terrain, à partir des observations et recherches de développeurs expérimentés soucieux de se concentrer sur les nécessités élémentaires du développement :
Développer vite : s'assurer que les changements restent toujours faciles pour conserver une vitesse de développement soutenue tout au long du projet.
Développer juste : éliminer tout travail inutile en se focalisant sur les besoins réels du client.

Comment ?
Elle s'appuie sur :
Une forte réactivité au changement des besoins du client (ou changements technologiques) au plus tôt dans le cycle de vie du logiciel
Un travail d'équipe : combinaison de l'effort des développeurs, de l'encadrement et du client
La qualité du code : norme de spécification et de programmation
La qualité des tests effectués au plus tôt
Une intégration permanente.

Intérêt ?
Elle est basée sur l'examen des pratiques de développement logiciel
C'est une méthodologie logicielle allégée destinée à réduire le coût du logiciel.

Quand l'utiliser ?
Dans un milieu où les besoins changent
Pour faire face aux risques liés aux projets et augmenter les chances de succès.
Cette méthodologie est adaptée aux petits groupes de projet comprenant de 2 à 10 personnes .

Méthode
Chaque équipe XP regroupe des développeurs, de l'encadrement et des clients qui ensemble, posent les questions, définissent les plannings et rédigent des tests fonctionnels
Le domaine en question doit rendre possible l'automatisation des tests unitaires et des test fonctionnels.
Déplacer les membres au sein du projet
Le travail en binôme
Réunions courtes et très régulières.

Cette approche a pour conséquence de favoriser la productivité des développeurs, sans pour autant être un but.
 PAGE \*ARABIC 1


 :