J2EE in practice Olivier Liechti Patrik Fuhrer Informatics Computer Science Master Course - SH 2004/05
Introduction Dans le cours ASE, nous avons: étudié une plate-forme de développement distribuée: Java 2 Enterprise Edition (J2EE); étudié un ensemble de technologies et d'apis; parlé d'architecture et de patterns, qui ont émergé au dessus de couche d'apis J2EE. Dans le cours d'aujourd'hui, nous allons: parler des projets de développement en général; parler de l'utilisation de J2EE dans la pratique; passer en revue un ensemble d'outils et de frameworks qui sont répandus dans l'industrie. 2/43
Agenda Projets de développement J2EE dans la pratique Survol d'outils et de frameworks 3/43
Agenda 1. Projets de développement 2. J2EE dans la pratique 3. Survol d'outils et de frameworks 4/43
Projets de développement Projets de développement 1. Définition 2. Caractéristiques des projets 3. Organisation du projet 4. Méthodologies de développement 5/43
Projets de développement Définition Un projet de développement consiste à concevoir et à réaliser un système plus ou moins complexe. Ce système sera mis à disposition d'utilisateurs. Il répond à un cahier des charges, avec des aspects fonctionnels (quoi) et non fonctionnels (comment). Souvent, le système doit s'intégrer techniquement et fonctionnellement dans un SI existant. La mise en oeuvre du système doit apporter un avantage à l'organisation. Cet avantage justifie le coût du projet. 6/43
Projets de développement Caractéristiques des projets (1) complexité effort requis importance des délais de livraison impact sur le business (aspects financiers) impact sur l'organisation (aspects processus) risques importance des aspects non fonctionnels (scalabilité, sécurité, gérabilité, etc.) budget et ressources humaines à disposition contexte organisationnel et politique contexte contractuel (interne, prix fixe, en régie) 7/43
Projets de développement Caractéristiques des projets (2) Les caractéristiques du projet ont un impact: sur l'organisation du projet et le choix d'une méthodologie de développement (qui fait quoi, comment?); sur le choix de technologies et d'outils (importance plus ou moins grande des standards, de la pérennité des fournisseurs, de la complexité des technologies, etc.); sur l'importance accordée à la modélisation et à la documentation du système. 8/43
Projets de développement Organisation du projet: rôle (qui?) Sponsor Représentant des utilisateurs Spécialiste métier Architecte Développeur Responsable qualité Testeur Chefs de projet Utilisateur 9/43
Projets de développement Organisation du projet: rôle (quoi?) Sponsor finance le projet; doit être convaincu que le système apportera un avantage à l'organisation; définit la vision du projet. Représentant des utilisateurs connaît la manière de travailler des utilisateurs; interface avec les utilisateurs. Spécialiste métier connaît les règles métiers qui seront modélisées puis implémentées dans le système. 10/43
Projets de développement Organisation du projet: rôle (quoi?) Architecte A une vue d'ensemble sur tout le système; connaît et choisit les technologies et outils en fonction des caractéristiques du projet; communique avec les sponsors, les spécialistes métiers, les utilisateurs, les équipes de développement, les équipes de QA. Développeur A une vue détaillée sur un sous-système; a une connaissance pointue sur les technologies et outils utilisés pour ce sous-système. 11/43
Projets de développement Organisation du projet: rôle (quoi?) Responsable qualité Met en oeuvre un ensemble d'actions qui permettent de vérifier que les spécifications fonctionnelles et nonfonctionnelles sont remplies; définit une stratégie de test, supervise la conception et la réalisation des tests, documente les tests; communique avec le sponsor, l'architecte, les utilisateurs. Testeur Conçoit et réalise un test particulier (partie du système, aspect). 12/43
Projets de développement Organisation du projet: rôle (quoi?) Chefs de projet Coordonne et planifie les activités du projet; très souvent: un chef de projet du côté "client" et un chef de projet du côté "fournisseur". Utilisateur Input pour les spécifications, participe aux tests. Comité de pilotage Régulièrement, un groupe se réunit pour faire le point sur le projet, statue sur les problèmes; sponsor, chef de projets, architecte, resp. QA. 13/43
Projets de développement Méthodologies de développement (1) Une méthodologie structure le projet: explicitant les rôles assignés aux personnes; définissant les étapes du projet; définissant les activités du projet, avec leurs délivrables et leurs interdépendances; Il existe différents types de méthodologies: plus ou moins itératives/incrémentales; plus ou moins formelles; adaptées à des projets plus ou moins "grands". adaptées à des équipes plus ou moins "expertes" 14/43
Projets de développement Méthodologies de développement (2) Méthodologies anciennes Exemple: "Waterfall" Cette méthodologie était appliquée à des projets nécessitant un effort important, dont le développement pouvait durer plusieurs années. Phase de spécification, phase de conception, phase de développement, phase de test, déploiement. Problème: difficile de modifier les spécifications en cours de projet, système livré ne répondant plus aux besoins des utilisateurs (qui ont changé). 15/43
Projets de développement Méthodologies de développement (3) Méthodologies itératives "formelles" Exemple: "Unified Process" 4 grandes phases: inception, élaboration, construction, transition Processus itératif et incrémental Importance des use cases Importance de l'architecture Importance de la modélisation (UML) UP fournit un cadre, qui doit être adapté par rapport aux caractéristiques du projet. 16/43
Projets de développement Méthodologies de développement (4) Méthodologies itératives "agiles" Exemple: "extreme Programming (XP)" Principes de base: Importance de la communication Développement incrémental, intégration continue Tests unitaires (unit testing) Programmation en paires (pair programming) Plus d'importance accordée au système (et au code) qu'à la documentation et aux modèles (attention: notion relative et en aucun cas une excuse pour ne pas modéliser!!) Bien adaptée aux petites équipes 17/43
Projets de développement Méthodologies de développement (5) Les méthodologies relativement "formelles" (comme UP) et celles plus "agiles" ne sont pas mutuellement exclusives. Exemple: UP utilisée pour structurer le projet global, avec des jalons, des délivrables, des échéances. XP utilisée (du moins en partie) à l'intérieur d'une itération, pour améliorer la qualité et la maintenabilité du code. 18/43
Agenda 1. Projets de développement 2. J2EE dans la pratique 3. Survol d'outils et de frameworks 19/43
J2EE dans la pratique J2EE dans la pratique 1. Pourquoi choisir J2EE? 2. Comment introduire J2EE dans une organisation? 3. J2EE vs. Microsoft.NET 20/43
J2EE dans la pratique Pourquoi choisir J2EE? Importance des standards ouverts J2EE est une norme, pas un produit; différents éditeurs (et communautés Open Source) proposent des produits compatibles avec la norme; l'organisation gagne en indépendance. Indépendance par rapport à la plate-forme J2EE est disponible pour une grande variété d'os et de plate-forme matérielles; l'organisation peut l'utiliser de manière uniforme. Popularité de Java et impact sur l'intégration 21/43
J2EE dans la pratique Comment introduire J2EE? (1) Remarque: Cette question se posait surtout il y a quelques années. Aujourd'hui, J2EE est devenu le standard dans beaucoup d'organisations. Choisir les plate-formes et les outils Comment choisir un container (commercial vs. open source, besoin de fonctions spéciales?) Comment choisir les frameworks qui complètent la plate-forme de base? 22/43
J2EE dans la pratique Comment introduire J2EE? (2) Gérer les compétences Passer de COBOL à J2EE n'est pas évident Souvent, les développeurs n'ont même pas d'expérience en développement orienté objet! Approche 1: former les employés à J2EE Approche 2: développer des outils et une couche d'abstraction au dessus de J2EE pour masquer les aspects techniques (=> frameworks/patterns) Les 2 approches sont souvent combinées, de manière non-uniforme sur l'ensemble des collaborateurs. 23/43
J2EE dans la pratique Comment introduire J2EE? (3) Approche recommandée création d'un groupe d'architecture, qui documente et distille les "best practices"; formation continue des collaborateurs, mise en oeuvre de programmes spéciaux et de coaching; réalisation de projets pilotes, qui deviennent une référence et permettent la rédaction de "blueprints" utilisés pour les projets futurs; mise à profit de l'expérience de spécialistes (consultants), de manière plus ou moins ponctuelle; activités de review d'architecture et de code. 24/43
J2EE dans la pratique J2EE vs..net (1) Deux plate-formes pour le développement d'applications multi-tiers. Beaucoup de notions similaires. Différent focus: J2EE part "du bas": grande importance accordée à l'infrastructure et aux qualités systémiques (scalabilité, robustesse, sécurité, etc.)..net part "du haut": focus sur les outils de développement qui sont "user friendly" (e.g. VB). Les 2 plate-formes évoluent. 25/43
J2EE dans la pratique J2EE vs..net (2) Différente philosophie: J2EE: standard ouvert.net: produit d'éditeur La réalité du marché. Actuellement: la plupart des grandes organisations, soucieuses de garder une indépendance par rapport aux fournisseurs, ont choisi J2EE; les organisations qui ont choisi.net l'ont souvent fait à cause de la productivité à court terme (outils); les offres d'emplois sur le marché local montrent que les compétences J2EE sont plus recherchées. 26/43
Agenda 1. Projets de développement 2. J2EE dans la pratique 3. Survol d'outils et de frameworks 27/43
Survol d'outils et de frameworks Survol d'outils et de frameworks 1. Environnement d'exécution: les containers 2. Autres composants de l'infrastructure 3. Gestion des identités 4. Outils de développement 5. Frameworks 28/43
Survol d'outils et de frameworks Les containers J2EE Comment choisir un container J2EE? Solution Open Source JBoss, Tomcat, Jonas, Geronimo,... Solution commerciale IBM Websphere, BEA Weblogic, Sun Java AS,... Critères de choix Besoin de fonctions spéciales (clustering, fail-over, performances, consoles d'administration, etc.) importance du support certification et adhérence aux standards raisons politiques et commerciales, coût 29/43
Survol d'outils et de frameworks Autres composants de l'infrastructure Base de données Annuaires Solution de gestion des identités et du SSO Portail d'entreprise Systèmes métier "legacy" devant être intégrés Technologies et outils d'intégration (e.g. bus)... 30/43
Survol d'outils et de frameworks Gestion des identités (1) Les applications utilisent des référentiels utilisateurs, pour l'identification et l'autorisation. Souvent, les applications ont été développées de manière plus ou moins anarchique: chaque application utilise son propre référentiel il y a donc plusieurs référentiels dans le système d'information, avec une redondance d'information chaque utilisateur a plusieurs IDs/mots de passe gérer les comptes est difficile est coûteux savoir qui a le droit de faire quoi est impossible!! 31/43
Survol d'outils et de frameworks Gestion des identités (2) Offrir un identifiant unique à l'utilisateur: en consolidant plusieurs référentiels dans un seul (e.g.: partager un annuaire LDAP) en fédérant plusieurs référentiels et en assurant la synchronisation transparente des mots de passe. Offrir une solution de Single Sign-On: les applications sont protégées par des "agents",qui vérifient que l'utilisateur est identifié; si ce n'est pas le cas, l'utilisateur est dirigé vers un service d'identification (page de login), où il peut obtenir un jeton SSO (token); 32/43
Survol d'outils et de frameworks Outils de développement Outils de modélisation (UML) Borland Together, Sun Java Studio Enterprise,... Environnements de développement intégrés: Open source: Eclipse, Netbeans,... Commercial: Borland JBuilder, Sun Java Studio,... Gestion du code et des versions CVS, subversion,... Gestion des builds ant, maven,... Autres: xwiki, bugzilla, scarab,... 33/43
Survol d'outils et de frameworks Concurrent Version System (CVS) Qu'est-ce que CVS? Système de gestion de versions des fichiers Open Source, gratuit: http://www.cvshome.org Gère l'historique d'une arborescence de fichiers typiquement les fichiers contenant le code source mais également des fichiers de configuration, etc. Permet de répondre à des questions du genre: Quelles modifications ont été apportées à ce fichier, quand, par qui et pourquoi? Quel était l'état du fichier à un temps t? 34/43
Survol d'outils et de frameworks Workflow de développement Dével.... CVS Build Test Validation Exécution Dével. Développement Repository Intégration Production 35/43
Survol d'outils et de frameworks Concurrent Version System (CVS) Créer un repository CVS Accéder à un repository CVS en utilisant le système de fichiers en utilisant le protocole client-serveur (év. + SSH) Clients CVS interface "ligne de commande" interface GUI interface web IDE (e.g. Netbeans, Eclipse, JBuilder, etc.) 36/43
Survol d'outils et de frameworks Quelques commandes CVS... Pour récupérer un module du repository cvs checkout module Pour mettre à jour le repository cvs commit -m "description des modifi..." Pour afficher l'historique des modifications cvs log hello.c Pour afficher les différences entre 2 versions cvs diff -c -r 1.1 -r 1.2 hello.c 37/43
Survol d'outils et de frameworks Quelques commandes CVS... Pour ajouter un fichier dans le repository cvs add hello.c Pour supprimer un fichier du repository cvs remove hello.c Pour tagger l'arborescence avec un nom de release cvs tag version-1-0 38/43
Survol d'outils et de frameworks Subversion Qu'est-ce que subversion: un autre système de gestion des versions, plus récent mais qui gagne en popularité Open source: http://subversion.tigris.org Objectif: offrir un "meilleur" CVS Meilleure gestion des répertoires, plus de flexibilité pour la réorganisation de l'arborescence 39/43
Survol d'outils et de frameworks Frameworks Frameworks d'applications Objectif: faciliter le développement d'applications en "masquant" certains aspects techniques ou métier; souvent, ces frameworks sont développés en combinant un ensemble de "design patterns". Frameworks de présentation Objectif: faciliter le développement des composants du tiers client/présentation: gestion du flux des pages, des composants GUI; souvent: implémentation du modèle MVC. Frameworks de persistance Objectif: faciliter la gestion de la persistance du modèle OO géré par le système. 40/43
Survol d'outils et de frameworks Frameworks de présentation Struts Modèle MVC Open Source, très populaire (standard de facto) Manque parfois de flexibilité Java Server Faces (JSF)... Standard JSR Conçu à la base pour permettre la conception d'outils de développement WYSIWYG Peut être utilisé en complément de Struts 41/43
Survol d'outils et de frameworks Frameworks de persistance EJB (CMP) Standard JSR Deviendra de plus en plus facile à utiliser (EJB 3.0) Java Data Object (JDO) Standard JSR Utilisé par certains containers J2EE pour implémenter le CMP, peut être utilisé en direct Hibernate Solution open source (pas un standard!) Très populaire... 42/43
Conclusion Conclusions Les projets de développement doivent être gérés avec rigueur et discipline, de manière à respecter budgets et délais. J2EE est une plate-forme riche, au dessus de laquelle ont été développés de nombreux outils et frameworks. L'ensemble des composants à disposition évolue constamment. Il est important de suivre cette évolution! Le choix de composants doit être fait par rapport à un ensemble de critères, qui doivent être pondérés en fonction du contexte du projet. 43/43