WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception et implémentation d'une application de gestion des dossiers d'équivalence

( Télécharger le fichier original )
par Brice Arsene GBITHICKI NDANGA
Université de Maroua/ Institut Supérieur du Sahel - Ingénieur de Conception en informatique 2013
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

Chapitre II : GENERALITES DE LA PLATE FORME J2EE

Dans ce chapitre nous allons décrire les principales généralités de la plate forme J2EE nécessaires à la mise en place du système. Nous commencerons par une présentation de J2EE, ensuite le constructeur de projet maven. Nous continuerons par la description du gestionnaire de version svn, ensuite du conteneur léger Spring, le Framework composant Wicket et enfin le mapping objet/relationnel de hibernate/ JPA.

II.1. Présentation de J2EE

Le terme « Java EE » signifie Java Enterprise Edition, et était anciennement raccourci en « J2EE ». Il fait quant à lui référence à une extension de la plate-forme standard. Autrement dit, la plate-forme Java EE est construite sur le langage Java et la plate-forme Java SE (Java Standard Edition), et elle y ajoute un grand nombre de bibliothèques remplissant tout un tas de fonctionnalités que la plate-forme standard ne remplit pas d'origine. L'objectif majeur de Java EE est de faciliter le développement d'applications web robustes et distribuées, déployées et exécutées sur un serveur d'applications (MOLIERE, 2005).

II.1.1. Concept de la plate forme J2EE

La figure suivante présente les différentes technologies utilisées par la plate forme J2EE.

Source : (ROQUES, 2002). Figure 2-1 : Outils J2EE

5

6

Avec le langage Java est apparue une nouvelle technologie : les servlets. Ces petits «serveurs» ou «services» sont écrits en langage Java et utilisent une API spécifique. Les performances sont améliorées par les fonctionnalités multithreads des serveurs J2EE, évitant la création de processus externes (MOLIERE, 2005).

Cependant, le développeur doit toujours mixer le code Java et HTML. De plus, la moindre modification oblige à recompiler la servlet et à la recharger. Les JSP, ou Java Server Pages, viennent résoudre ces problèmes de recompilation. Ici, c'est le code Java que l'on incorpore dans la page HTML avec des techniques de scripting. Le serveur compile automatiquement la page en une servlet et l'exécute ensuite. Les approches à base de scripting nécessitent l'incorporation importante de code applicatif dans le HTML. Ces techniques limitent aussi la réutilisation de code (MOLIERE, 2005).

Pour ce qui est du monde Java, il a donc été proposé de faire collaborer les servlets et les JSP dans les applications. Les servlets sont utilisées par les développeurs pour gérer les aspects programmation d'une application web et les JSP sont utilisées par les infographistes pour effectuer l'affichage. On retrouve ainsi une servlet et une JSP par requête possible sur le site web. La servlet ne contient plus de HTML, et la JSP contient juste le code nécessaire à l'affichage. Ce style de programmation respecte le paradigme MVC.

II.1.2. Le paradigme MVC (Modèle-Vue-Contrôleur)

Le paradigme MVC est un schéma de programmation qui propose de séparer une application en trois parties :

· le modèle, qui contient la logique et l'état de l'application ;

· la vue, qui représente l'interface utilisateur ;

· le contrôleur, qui gère la synchronisation entre la vue et le modèle.

Le point essentiel consiste à séparer les objets graphiques des objets métier, afin de pouvoir les faire évoluer indépendamment et les réutiliser.

7

On peut également gérer facilement plusieurs vues du même modèle.

Au final, une telle séparation favorise le développement et la maintenance des applications :

· Le modèle étant séparé des autres composants, il est développé indépendamment. Le développeur du modèle se concentre sur le fonctionnel et le transactionnel de son application.

· Le modèle n'est pas lié à une interface, il peut donc être réutilisé (passage d'une application avec interface en Java à une application avec interface web). Dans les applications J2EE, le modèle est assuré par des EJB et/ou des JavaBeans, le contrôleur est assuré par des servlets et la vue par des JSP (voir la figure 2-2 suivante).

Figure 2-2 : Architecture d'une application J2EE

Source : (ROQUES, 2002)

II.2. Apache Maven 2 : Outil de build Apache Maven 2 est un outil « open source » de Apache Jakarta. Il permet de faciliter et d'automatiser la gestion et la construction d'un projet java (VONGVILAY Michel, 2004). Le premier but de Maven est de permettre aux

développeurs de connaitre rapidement l'état global du développement du projet. C'est dans ce but que Maven :

· Facilite le processus de construction

· Fournit un système de construction uniforme

· Fournit des informations utiles sur le projet

· Fournit clairement les grandes lignes directrices de développement

· Fournit les éléments nécessaires pour faire des tests complets

· Fournit une vision cohérente et globale du projet

· Permet d'ajouter de nouvelles fonctionnalités de façon transparente

Maven est basé sur le concept de « Project Object Model » (POM). Le développement et la gestion du projet sont contrôlés depuis le POM.

II.2.1. Principe de fonctionnement

La figure 2-3 suivante illustre le principe de fonctionnement du constructeur de projet maven.

Figure 2-3 : Maven.

8

Source : linsolas.developpez.com/articles/java/builds

1. Maven commence par définir la liste des dépendances nécessaires au projet, via la lecture du fichier pom.xml du projet ;

2. Maven interroge alors le repository local afin de trouver les dépendances utilisés ;

3. Si la dépendance n'est pas trouvée, alors maven va interroger les repositories distants ;

4. les dépendances absences du repository local sont alors téléchargées depuis les repositories distants, de telles façon a ce qu'elles disponibles lors des prochains builds ;

5. Maven peut alors utiliser la dépendance pour la construction du projet.

L'intérêt de ce mécanisme, en plus de sa simplicité, est que nous ne définissons plus que les dépendances directes de notre projet. Les dépendances de nos dépendances, autrement appelées dépendances transitives sont directement gérées par Maven2, et ne préoccupent plus l'esprit du développeur (VONGVILAY Michel, 2004).

II.2.2. La structure de répertoires

Une partie de la puissance de Maven vient des pratiques standardisées qu'il encourage. Un développeur qui a déjà travaillé sur un projet Maven se sentira tout de suite familier avec la structure et l'organisation d'un autre projet Maven. Il n'y a pas besoin de gaspiller du temps à réinventer des structures de répertoires, des conventions, et à adapter des scripts de build Ant pour chaque projet (SMART, 2005). Même s'il est possible de redéfinir l'emplacement de chacun des répertoires vers une localisation spécifique, il est réellement intéressant de respecter la structure de répertoire standard de Maven 2 autant que possible, et ce pour plusieurs raisons :

· Cela rend le fichier POM plus court et plus simple ;

· Cela rend le projet plus simple à comprendre et rend la vie plus simple au pauvre développeur qui devra maintenir le projet quand vous partirez ;

·

9

Cela rend l'intégration de plug-ins plus simple.

II.3. 10

Le serveur SVN

SVN signifie Subversion est un système de gestion de version, conçu pour remplacer CVS. Concrètement, ce système permet aux membres d'une équipe de développeur de modifier le code du projet quasiment en même temps. Le projet est en effet enregistré sur un serveur SVN et à tout moment, le développeur peut mettre à jour une classe avant de faire des modifications pour bénéficier de la dernière version et a la possibilité de comparer deux versions d'un même fichier.

Le principe de fonctionnement est le suivant :

Figure 2-5 : fonctionnement du serveur svn

II.4.

Spring : Faciliter le développement et les tests

Le Framework Spring est un conteneur dit « léger », c'est-à-dire une infrastructure similaire à un serveur d'application J2EE (FERRAN, 2008). Il prend donc en charge la création d'objets et la mise en relation d'objets par l'intermédiaire d'un fichier de configuration qui décrit les objets à fabriquer et les relations de

11

dépendances entre ces objets (IoC - Inversion of Control). Le gros avantage par rapport aux serveurs d'application est qu'avec SPRING, les classes n'ont pas besoin d'implémenter une quelconque interface pour être prises en charge par le Framework. C'est en ce sens que SPRING est qualifié de conteneur « léger ». L'idée du pattern IoC est très simple, elle consiste, lorsqu'un objet A à besoin d'un objet B, à déléguer à un objet C la mise en relation de A avec B (FERRAN, 2008).

II .5. Apache Wicket : Mettre en place le MVC

Apache Wicket est un Framework pour la création d'applications web qui repose presque entièrement sur Java et HTML comme moyens pour bâtir ses interfaces. Wicket est YAJF (Yet Another JavaEE Framework), mais orienté composants. Il se distingue par certaines grandes particularités :

· Pas de JSP !

· Aucun tag de logique (boucle, condition) mélangé au HTML

· Les composants web sont créés dans des classes Java "à la Swing" avant d'être simplement placés aux endroits souhaités dans le fichier HTML ;

· Une gestion particulièrement simple de tâches récurrentes dans le développement de sites web comme la validation de formulaires, le passage de paramètres entre les pages et la navigation ;

· Un Framework créé dans l'idée de vouloir faciliter le développement de composants réutilisables.

II.6. Hibernate et DAO : le mapping objet/relationnel

Les difficultés de cohabitation entre les mondes objets et relationnels sont résolues grâce au concept de Mapping objet-relationnel (O/R Mapping), qui est le nom donné aux techniques de transformation des modèles objets en modèles relationnels (ROS, 2003).

Les choix architecturaux d'une application sont décisifs dès lors qu'ils interviennent sur les performances, l'évolutivité, les temps de développement, et bien sûr les coûts.

Les sages d'aujourd'hui prônent une séparation en différentes couches des applications, et parlent alors d'applications multi niveaux (n-tier applications) voir figure 2-6.

 

Figure 2-6 : Mapping objet/relationnel

 

12

L'ORM est nécessaire parce la représentation sous forme Relationnelle n'entre pas en correspondance avec la représentation Objet.

· Objet : notions d'héritage et de polymorphisme ;

· Objet : pas d'identifiant (pointeur) ;

· Objet : les relations n:m sont modélisées par des containers.

II.6.1. Data Access Object (DAO)

Quel que soit le système sur lequel vous développez, vous pourrez toujours accéder à vos données relationnelles. Vous utiliserez alors des API telles que JDBC, ADO, ADO.Net, et pourrez alors exécuter des requêtes SQL, ou obtenir des objets représentant des tables et leurs champs.

Ces outils sont suffisants mais ne permettrons jamais à eux seuls une vraie abstraction de la base de données sous-jacente. Par exemple vous ne pourrez pas obtenir toutes les commandes d'un client donné avec une seule ligne de code. De plus, chaque fois que vous voudrez supprimer un client, vous devrez supprimer manuellement son adresse, alors que cela pourrait être fait automatiquement (ROS, 2003).

Tous ces problèmes doivent être gérés par une couche d'accès aux données chargée de communiquer avec le serveur de bases de données, et de renvoyer des objets

13

métiers au programmeur ; Ce denier n'aurait alors plus besoin de taper des requêtes SQL, comprendre les relations entre les tables, ou connaître tous les paramètres des procédures stockées, ou encore d'autres éléments. Lorsqu'on parle de séparation des couches par responsabilité, il y a va également de la séparation des compétences de chaque développeurs.

II.6.2. Hibernate

Outil de mapping objet/relationnel pour le monde Java. Le terme mapping objet/relationnel (ORM) décrit la technique consistant à faire le lien entre la représentation objet des données et sa représentation relationnelle basée sur un schéma SQL.

Non seulement, Hibernate s'occupe du transfert des objets Java dans les tables de la base de données (et des types de données Java dans les types de données SQL), mais il permet de requêter les données et propose des moyens de les récupérer. Il peut donc réduire de manière significative le temps de développement qui aurait été autrement perdu dans une manipulation manuelle des données via SQL et JDBC.

Le but d'Hibernate est de libérer le développeur de 95 pourcent des tâches de programmation liées à la persistance des données communes. Hibernate n'est probablement pas la meilleure solution pour les applications centrées sur les données qui n'utilisent que les procédures stockées pour implémenter la logique métier dans la base de données, il est le plus utile dans les modèles métier orientés objets dont la logique métier est implémentée dans la couche Java dite intermédiaire (ROS, 2003). Cependant, Hibernate vous aidera à supprimer ou à encapsuler le code SQL spécifique à votre base de données et vous aidera sur la tâche commune qu'est la transformation des données d'une représentation tabulaire à une représentation sous forme de graphe d'objets.

II.6.3. JPA Java Persistance API

JPA permet de manipuler des données en base de données relationnelle directement à partir d'objets Java sans écrire du code SQL. Comme pour JDBC,

14

l'utilisation de JPA nécessite un fournisseur de persistance qui implémente les les classes et méthodes de l'API lasses et méthodes de l'API.

Les classes dont les instances peuvent être persistantes sont appelées des entités dans la spécification de JPA Le développeur indique qu'une classe est une entité en lui associant l'annotation @Entity. Ne pas oublier d'importer javax.Persistence.Entity dans les classes entités (idem pour toutes les annotations).

~ Configuration de la connexion

Il est nécessaire d'indiquer au fournisseur de persistance comment il peut se connecter à la base de données. Les informations doivent être données dans un fichier persistence.xml situé dans un répertoire META-INF dans le classpath. Ce fichier peut aussi comporter d'autres informations.

~ Gestionnaire d'entités

Classe javax.persistence.EntityManager, le gestionnaire d'entités (GE) est l'interlocuteur principal pour le développeur. Il fournit les méthodes pour gérer les entités : les rendre persistantes, les supprimer de la base de données, retrouver leurs valeurs dans la base, etc.

~ Contexte de persistance

La méthode persist(objet) de la classe EntityManager rend persistant un objet. L'objet est ajouté à un contexte de persistance qui est géré par le GE (gestionnaire d'entités). Toute modification apportée à un objet du contexte de persistance sera enregistrée dans la base de données. L'ensemble des entités gérées par un GE s'appelle un contexte de persistance.

Dans le cadre d'une application autonome, la relation est simple : un GE possède un
contexte de persistance, qui n'appartient qu'à lui et il le garde pendant toute son
existence. Lorsque le GE est géré par un serveur d'applications, la relation est plus
complexe ; un contexte de persistance peut se propager d'un GE à un autre et il peut
être fermé automatiquement à la fin de la transaction en cours.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il ne faut pas de tout pour faire un monde. Il faut du bonheur et rien d'autre"   Paul Eluard