Java EE 7

Java EE 7 Enterprise Edition

Génie Logiciel 2013-2014

Meryam Belhiah [email protected]

Objectifs pédagogiques du cours 1. Se familiariser avec les termes et les concepts les plus importants ; 2. Apprendre davantage sur l’architecture Java EE et les API (Application Programming Interfaces) ; 3. Passer en revue les bases de développement d’applications Java EE.

Outline (1/2) 1. 2. 3. 4. 5.

Étude de cas Comparaison (presque objective) de quelques aspects entre Java EE et .NET Pourquoi Java EE Java EE Application Model Application distribuée multi-tiers 5.1.Clients Java EE 5.1.1. Client léger 5.1.2. Client lourd 5.2. Serveurs Java EE 5.2.1. Composants métier 5.2.2. Composants Web • Servlet • Pages Web 5.3. Systèmes d’Information d’Entreprise

Outline (2/2) 6.

API (Application Programming Interfaces) Java EE 7 6.1. JPA / Hibernate 6.2. Bean validation / Hibernate Validator

7.

Quelques bases de développement d’applications Java EE 7.1. Utilisation des design pattern : • •

DAO (Data Access Object ) Singleton

7.2. Utilisation des frameworks : • • • •

Hibernate MVC 2 JSF 2 Spring MVC

7.3. Autres outils : • Apache Maven

8.

Travaux Pratiques

1. Étude de cas

1. Étude de cas Mandat : Développer une application d’entreprise pour gérer une compagnie aérienne internationale. Cette application doit gérer : • • • •

les clients (données clients, réservations, etc.) ; les employés ; les fournisseurs et le stock ; les partenaires commerciaux (agences de voyage, hôtels, etc.).

Elle doit permettre également à d’autres parties tierces, comme les autorités de régulation (ex : autorités aéroportuaires, direction des impôts, caisse de sécurité sociale), d’échanger des données avec la compagnie via le Web.

1. Étude de cas Les parties prenantes : 1. le client (la compagnie aérienne) ; 2. les prestataires : • interne : la Direction des Systèmes d’Information (DSI) de la compagnie aérienne ; • externe : un cabinet XYZ (manager(s) de projets, architecte(s), analyste(s), développeurs, intégrateurs, testeurs).

1. Étude de cas Étape 1 - Élaborer le cahier des charges, qui est un contrat (au sens légal du terme) et qui définie entre autres : • • • •

les interfaces ; les fonctionnalités ; le (s) modèle (s) de données ; le flux.

Étape 2 - Définir les technologies à utiliser : • • • • •

la nature du projet à développer ; les compétences et l’expérience de l’équipe déjà en place ; la courbe d’apprentissage pour les nouvelles technologies ; l’expérience avec d’autres projets antérieurs ou des projets similaires ; la compatibilité avec les systèmes déjà en place (l’intégration est importante).

1. Étude de cas Depuis les années 90, les deux tendances en développement des applications d’entreprises sont : • Java Enterprise Edition (Oracle) ; • Microsoft .NET (Microsoft)

2. Comparaison de quelques aspects entre Java EE et Microsoft .NET

2. Comparaison de quelques aspects entre Java EE et Microsoft .NET Aspects

Java EE

Microsoft .NET

Environnement de Développement Intégré (IDE)

Eclipse : l’IDE le plus populaire pour le développement d’AE, open source, gratuit

VisualStudio.NET est un IDE complet mais payant

Communauté des développeurs

Une communauté imposante

Microsoft Developers Network (MSDN)

Language de programmation

#2 : Java

#5 : C#

Productivité

Dans le planning, prévoir du temps pour décider des technologies

Les solutions technologiques sont arrêtées

UI best practices

JSP, JSF, Wicket, Struts

ASP.NET MVC

Mapping Objet Relationnel (ORM)

Spéc. JPA Framework Hibernate

Entity framework NHibernate

(1) : http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Observations

déc. 2013 (1)

Les outils d’ORM sont plus matures en Java EE

2. Comparaison de quelques aspects entre Java EE et Microsoft .NET • Coût de l’acquisition de l’IDE et des serveurs ; • Technologies open source v/s propriétaires

3. Pourquoi Java EE ?

3.

Pourquoi Java EE ?

Permettre le développement d’applications critiques pour l’entreprise qui sont: • distribuées ; • transactionnelles ; • portables. Qui en même temps sont : • rapides ; • sécurisées ; • fiables.

3.

Pourquoi Java EE ?

Fournir aux développeurs d’applications d’entreprise un ensemble complet d’API pour : • • • •

réduire la compléxité des applications ; réduire le temps de développement ; augmenter la productivité ; améliorer les performances.

4. Java EE Application Model

4.

Java EE Application Model Middle-tier : un environnement clos qui est entièrement contrôlé par la DSI d’un organisme/entreprise.

fig1. Architecture distribuée multi-tiers

Les services du middle-tier tournent sur des serveurs dédiés et ont accès à tous les autres services de l’entreprise.

4.

Java EE Application Model

Ce modèle divise le travail nécessaire à l’implémentation d’une application multitièrce comme suit : • •

la présentation et la logique métier incombent aux développeurs; les services système standards sont fournis par la plateforme Java EE.

Dans le cas de la compagnie aérienne : • la gestion des réservations, des clients , les échanges avec les agences de voyage, etc. (le middle-tier) et le UI incombent aux développeurs ; • la gestion des ressources, aspects standards de la sécurité, persistance, répartition de la charge, reprise sur panne par exemple, sont pris en charge par la plateforme.

5. Application distribuée multi-tiers 5.1.Clients Java EE 5.1.1. Client léger 5.1.2. Client lourd

5.2. Serveurs Java EE 5.2.1. Composants métier 5.2.2. Composants Web • Servlet • Pages Web

5.3. Systèmes d’Information d’Entreprise

5.

Architecture distribuée multi multi--tiers

fig2. Architecture distribuée multi-tiers

5.

Architecture distribuée multi-tiers

Une application distribuée multi-tiers est une application qui est développée et distribuée sur au moins deux couches. L’architecture n-tiers Java EE la plus commune est la 3-tiers : • Clients Java EE ; • Serveurs Java EE (composants Web, composants métier) ; • Systèmes d’Information d’Entreprise (EIS).

5.1.1.

Clients Java EE - Clients léger

Un client léger (thin client) n’exécute pas de règles métier complexes, n’interroge pas les bases de données et ne se connecte pas aux systèmes hérités (legacy systems). Les opérations lourdes sont exécutées par des composants métier au niveau du serveur (enterprise beans). Exemple de client léger : un client Web constitué de pages Web dynamiques contenant différents types de langage de markup (ex : HTML, XML.) et qui sont générés par les composants Web s'exécutant au niveau container Web. Un navigateur Web affiche les pages reçues du serveur.

5.1.2.

Clients Java EE - Client lourd

Un application cliente lourde (fat/thick client) s'exécute sur le client et fournit un moyen pour les utilisateurs de gérer des tâches qui nécessitent une interface utilisateur plus riche, que ce qui peut être fourni par un langage de balisage. Une application cliente lourde a généralement une GUI (Graphic User Interface). Les applications clientes lourde accèdent directement aux enterprise beans de la couche métier. Une application cliente lourde peut ne pas être écrite en Java et accéder quand même aux enterprise beans au niveau du serveur Java EE.

5.2. Serveur Java EE Un serveur d'application fournit les services middleware les plus courants, permettant ainsi de se focaliser sur l'application que l'on développe, sans s'occuper du reste. La séparation est nette entre la logique métier et les services middleware.

fig3. Serveur Java EE

5.2.1.

Serveur Java EE - composants métier C’est un programme informatique qui résout des problématiques ou répond à des besoins spécifiques à un domaine d’activités particulier. Ex: commerce de détail, banques, finance, etc.

fig4. Serveur Java EE - Composants Java EE

5.2.1. Composants métier - Enterprise JavaBeans (EJB) EJB est une architecture de composants logiciels, hébérgés sur des serveurs Java EE distribués. Cette architecture permet de : • gérer les sessions et les états : EJB session ; • accomplir des tâches de manière asynchrone : message driven beans ; • représenter les données : entity beans.

5.2.1.

Composants métier - EJB session

Les EJB session proposent un certain nombre de méthodes à leurs clients. Il existe deux types d’EJB session : •

stateless : ne conservent pas leur état entre deux appels ;

•

stateful: conservent leur état entre deux appels.

5.2.1.

Composants métier - MDB

Terminologies : •

Expéditeur JMS (JMS Producer/sender) : une application qui envoie des messages JMS ;

•

Consommateur JMS (JMS Consumer/receiver) : une application qui reçoit des messages JMS ;

•

Message JMS : un message qui respecte les spécifications JMS ;

•

Destination : des objets servant à identifier la cible (domaine : queue ou topic) des messages à envoyer ou à recevoir.

fig5. Architecture JMS

5.2.1.

Composants métier - MDB

• Un MDB est un composant permettant de traiter les messages arrivant sur une destination ; • Le MBD s’inscrie à une Queue, reçoie un message et le traite ; • L’envoie/réception des messages utilisent l’API JMS qui permet une communication asynchrone entre les expéditeurs (fournisseurs de messages) et les destinataires (consommateurs de messages).

5.2.1.

Composants métier - entity beans

Les entity beans sont des objets métier qui servent d’interface entre l’application écrite en Java et le système d’information de l’entreprise (en général, des bases de données relationnelles) ; Depuis la version EJB 3.0, les entity beans utilisent les annotations de l’API JPA pour la persistance. Exemples : • @Entity : définir un bean comme étant de type Entity ; • @Id : définir un champ comme un identifiant unique ; • @Table : mapper la table d’une BD avec un bean ; • @Column : mapper le champ d’une table avec une propriété du bean ; • Etc.

5.2.1.

Composants métier - entity beans

Depuis la version EJB 3.0, les entity beans n’implémentent aucune interface spécifique aux EJB. Selon les spécifications, ils doivent avoir un constructeur sans arguments et doivent implémenter l'interface “Serializable” ; La classe “EntityManager” est responsable des opérations de gestion des opérations sur une entité. Exemples : • persist ; • remove ; • find ; • createQuery ; • Etc.

5.2.2.

Serveur Java EE - Composants Web

Les composants Web : •

Servlets : un programme Java hébérgé dans le serveur d’application. Il reçoit une requête du client, effectue un traitement et renvoie une réponse dynamique sous forme de page HTML (dans le cas d’un serveur Web). Généralement en utilisant le protocole HTTP, mais d’autres protocoles peuvent également être utilisés. Le fait que les servlets soient écrite en Java leur permet entre autres: la portabilité et l’accèes aux API Java dont JDBC.

•

Pages Web crée en utilisant les technologies JSP (Java Server Pages) ou JSF (Java Server Faces).

5.2.2.

Composants Web -Servlet

fig6. Cycle de vie d’une servlet

La servlet repose sur un modèle de programmation requête-réponse (request-response). C’est une API qui s’exécute sur le serveur Web. Un serveur Web fait généralement deux choses: • Intercepte les requêtes du client ; • Traite la requête (ex : accède à la base de données, fait des traitements métier) et retourne une réponse bien formattée au client.

5.2.2.

Composants Web - Servlet

fig7. Exemple d’une servlet avec la méthode doGet

5.2.2.

Composants Web - Servlet

fig7. Exemple d’une servlet avec la méthode doPost

5.2.2.

Composants Web - Servlet

La partie d’un serveur reponsable de la gestion du cycle de vie d’une servlet est le Web container ou le servlet Container. Le servlet Container est la partie responsable pour fournir une implémentation de l’API javax.servlet.*;

5.2.2.

Composants Web - Servlet

Typologie des containers: 1. Serveur Java EE : fournit les containers Enterprise JavaBeans (EJB) et les containers Web ; •

•

Container EJB : gère l’exécution des enterprise beans pour les applications Java EE. Les enterprise beans et leur container s’exécutent dans le serveur Java EE ; Container Web : gère l’exécution des pages Web et des servlets. Les composants Web et leur conteneur s’exécutent sur le serveur Java EE .

2. Clients Java EE : •

•

Container d’applications clientes : gère l’exécution des composants des applications clientes. Les applications clientes et leur container s’exécutent sur le client ; Container pour les applets : gère l’exécution des applets. Il consiste en un navigateur Web et un Plug-in Java qui s’exécutent sur le client.

5.2.2.

Composants Web - Servlet

Fig 8. Serveur et containers Java EE

5.2.2.

Composants Web - JSP

Java Server Pages (JSP) est une technologie Java qui permet de générer des pages Web dynamique ; Les pages JSP se composent de : 1. contenu statique écrit avec des tags HTML ; 2. contenu dynamique : • Tags JSP ; • Code Java (scriptet) intégré à la JSP Un fichier JSP possède l’extension .jsp

5.2.2.

Composants Web - JSP

Fig 9. Exemple de page JSP

5.2.2.

Composants Web - JSP (Librairie JSTL)

JSTL (JSP Standard Tag Library) est une bibliothèque standard qui regroupe des fonctionnalités souvent rencontrées dans les JSP : • structure : itération, condition, etc. • internationalisation ; • manipulation de BD SQL ; • manipulation de documents XML. JSTL 1.2 nécessite un container Web qui implémente l’API JSP 2.1.

5.2.2.

Composants Web - JSP (Librairie JSTL)

Fonction

Tags

Gestion du flux (condition et itération)



Gestion des URL

Tableau1 : Tags de structure

5.2.2.

Composants Web - JSP (Librairie JSTL)

Fonction

Tags

Définition de la langue



Formatage de messages



Formatage de dates et nombres



Tableau2. Tags d’internationalisation

5.2.2.

Composants Web - JSP (Librairie JSTL)

Fonction

Tags

Définition de la source de données



Exécution de requêtes SQL



Tableau3. Tags de manipulation de BD avec SQL

5.2.2.

Composants Web - JSP (Librairie JSTL)

Fonction

Tag

Fondamentale



Gestion du flux (itération, condition)



Transformation XSTL (Extensible Stylesheet Language Transformations)



Tableau4. Tags de manipulation de documents XML

5.3. Système d’information d’entreprise La couche « Système d’Information d’Entreprise » comporte : • les systèmes d’infrastructure d’entreprise (ex : ERP); • les systèmes de bases de données (SGBD) ; • les systèmes hérités.

6. Quelques API Java EE 7 6.1. JPA / Hibernate 6.2. Bean validation / Hibernate Validator

6.

Quelques API Java EE 7

Fig 11. API Java EE 7

6.1. JPA / Hibernate JPA (Java Persistence API) est une spécification Java pour la gestion de la persistance. Il permet de combler le vide entre le modèle OO et le modèle des BD relationnelles, en utilisant un mapping objet-relationnel (ORM). Le mapping permet d’assurer la transaformation d’objets vers la BD et vice-versa pour les opérations CRUD (Create, Retrieve, Update, Delete).

6.1. JPA / Hibernate L’API repose sur : • des entités qui sont des POJOs (Plain Old Java Objects), déclaré avec l’annotation @Entity et qui possédent au moins une propriété annotée @Id et donc déclarée comme une clé primaire ; • un gestionnaire des entités (Entity Manager).

6.2. Bean Validation / Hibernate Validator • Permet d’exprimer les règles de validation de manière standard, en utilisant les annotations ; • Facile à intégrer à plusieurs Frameworks, parmi lesquels Spring MVC.

6.2. Bean Validation / Hibernate Validator

Fig 13. Exemple d’utilisation des annotations de l’API Hibernate Validator

7. Bases de développement d’applications Java EE : 7.1. Utilisation des design pattern : • •

DAO (Data Access Object ) Singleton

7.2. Utilisation des frameworks : • • • •

Hibernate MVC 2 JSF 2 Spring MVC

7.3. Autres outils : •

Apache Maven

7.1. Utilisation des design pattern - DAO DAO : Objets d’accès à la base de données (Data Access Object) est une stratégie de mapping entre des objets Java et la base de données. Avantages du design pattern DAO : • simple à écrire (une classe POJO + une classe DAO) ; • séparation de la données (data) et de la logique métier ; • possibilité de développer des applications distribuées, comme les DAO peuvent être des session beans ou des services Web ; • possibilité d’utiliser des joints et des procédures stockées.

7.1. Utilisation des design pattern - Singleton Singleton : en génie logiciel, il s’agit d’un design pattern qui permet de restreindre l’instanciation d’une classe à un seul objet, pendant toute la durée de vie de l’application. La méthode qui crée cette instance doit d’abord s’assurer qu’aucune autre instance n’existe déjà. Avantages : • Optimiser les performances par la réduction du nombre d’objets crées ; • S’assurer que des objets similaires et non nécessaires ne vont pas être crées dans la même application.

7.1. Utilisation des design pattern - Singleton

Fig 13. Exemple de classe Singleton

7.2. Utilisation des frameworks - Hibernate Hibernate est un framework de mapping objet-relationnel (ORM). Depuis la version 3.2, il fournie une implémentation de JPA. Le mapping avec Hibernate est réalisé : • Avec des annotations ; • Avec des fichiers XML.

7.2. Utilisation des frameworks - Hibernate

Fig 12. Exemple de fichier de mapping avec XML

7.2. Utilisation des frameworks - MVC2 Objectifs d’un framework : Standardiser et faciliter le développement d’application Web avec Java.

Fig 10. Modèle MVC

Répondre à des problèmes communs et inhérents aux développement d’applications : • l'accès aux données ; • l'internationalisation ; • la journalisation des événements (logging) ; • la sécurité (authentification identification) ; • le paramétrage de l'application.

7.2. Utilisation des frameworks - JSF JSF (Java Server Faces) : Un framework de la couche présentation orienté composants, pour construire des applications Web. JSF repose sur le modèle MVC 2 (Model View Controller). Les composants de la technologie JSF sont : • Un framework de composants GUI ; • Un modèle flexible pour renvoyer les élements à afficher dans différents langages de balisage (HMTL, XML, etc.) ; • Un kit standard pour générer des balises HTML.

7.2. Utilisation des frameworks - JSF Les composants GUI viennent avec : • La validation des inputs ; • La gestion des événements ; • La conversion de données entre le modèle objet et les composants ; • La configuration de la navigation entre les pages.

7.2. Utilisation des frameworks - JSF Le cycle de vie d’une requête traitée par une application utilisant la technologie JSF est le suivant : 1. 2. 3. 4. 5. 6.

Création de l'arbre de composants ; Extraction des données des différents composants de la page ; Conversion et validation des données ; Extraction des données validées et mise à jour du modèle de données (javabean) ; Traitements des événements liés à la page ; Génération du rendu de la réponse.

7.2. Utilisation des frameworks - Spring MVC Approche Spring MVC : • • •

Model : Objets POJO ; View : Différentes technologies : JSP, etc. ; Controller : Classes Spring Controller.

7.2. Utilisation des frameworks - Spring MVC Toutes les requêtes passent à travers la Spring’s Dispatcher Servlet : Request

Request

Response

Spring’s Dispatcher Servlet

Model object and view name

Controller

View name View

View Resolver

Model Response

View

Fig 14. Architecture Spring MVC

7.2. Utilisation des frameworks - Spring MVC Étapes pour créer une application Spring MVC de base : 1. 2. 3. 4. 5.

Écrire la classe du (es) modèle(s) de type POJO ; Écrire la classe du contrôleur ; Écrire les pages qui serviront de vues (en l’occurrence des pages jsp) ; Configurer la Spring’s dispatcher servlet dans le fichier “web.xml” ; Écrire le fichier de contexte de Spring “servlet.xml“ et y configurer le View Resolver.

7.3. Autres outils - Maven Maven : outil open source pour la gestion et automatisation de la production de projets en Java (build). Avantages : • La standardisation de la structure du projet et donc l’organisation du travail des développeurs ; • L’utilisation du fichier de configuration “pom.xml” (Project Object Model) : qui contient les informations nécessaires pour automatiser la production d’un projet : • • • • •

nom du projet , numéro de version, dépendances par rapport à d’autres projets, librairies nécessaires à la compilation (téléchargées à partir de Maven Central Repository : http://search.maven.org/), etc.

7.3. Autres outils - Maven

Fig 14. Structure d’un projet Maven

Fig 15. Aperçu d’un fichier “pom.xml”