JEE

1. JEE Java Enterprise Edition Riadh Ouersighni Maître de Conférence en Informatique Isitcom - 2010

2. Pédagogie du cours • Pré-requis: • POO java, Architecture Répartie (Java RMI), COO, UML, • Web, Design Pattern MVC, • Cours : • Présentation des concepts, technologies, API, frameworks du J2EE pour le développement d’application distribuée • TD Etude de cas Architecture Logiciel • TP • Illustration des concepts vus en cours par des exemples pratiques • Environnement de Développement J2EE • Utilisation de frameworks (struts, hibernate, spring, etc.) • Etudes de cas

3. Introduction J2EE • 1998 : La plateforme J2EE (Java 2 Entreprise Edition) est née de besoins grandissant des entreprises pour développer des applications complexes distribuées et ouvertes sur l ’Internet, le mobile, etc. • Définie par Sun MicroSystems, basée sur Java • Site officiel (anciennement java.sun.com ) http://www.oracle.com/technetwork/java/index.html • J2EE est le terme utilisé dans les versions avant 2005 (JDK 1.4 ou antérieur) • J2SE (Java 2 Standard Edition) fournit le langage et la plateforme java sur lesquels est bâti J2EE • J2ME (Java 2 Micro Edition) pour les terminaux mobiles

4. Introduction Java EE • Depuis la sortie de la version 5 (en 2005, JDK 1.5), Le terme J2EE a été remplacé par Java EE • Actuellement (en 2010) Java EE 6 • Autres éditons : • Java SE 7 (Standard Edition) • Java ME 3.0 (Micro Edition) • Java FX 1.3plateforme pour la création d’application RIA (Rich Internet Application) basé sur le langage Java FX Script

5. Qu’est ce que le Java EE (ou J2EE) • La Plateforme JEE désigne les technologies Java utilisées pour le développement d'applications «d’entreprise » distribuées (Répartie, multi-couches, n-tiers) • JEE est une plate-forme fortement orientée serveur. Elle est composée de deux parties essentielles : • un ensemble de spécifications pour une infrastructure dans laquelle s'exécutent les composants écrits en Java : un tel environnement se nomme serveur d'application. • un ensemble d'API qui peuvent être obtenu et utilisé séparément.

6. Qu’est ce que le JEE • Un ensemble de spécifications d’API, une architecture distribuée et une méthode de packaging et de déploiement des composants. • C’est une collection de composants, de conteneurs et de services mis à disposition des applications permettant de créer et de déployer des applications distribuées au sein d’une architecture standardisée

7. Objectifs • Concevoir une infrastructure d’application distribuée n’est pas une mince affaire • Un des objectifs du JEE : faciliter la vie des développeurs en permettant l’encapsulation de la complexité inhérente aux environnements distribués. • Les développeurs se concentrent uniquement sur l’aspect logique (métier) des données et de leurs processus et ne pas perdre du temps à coder l’aspect technique de leurs activités: Threading, transactions, sécurité, maintenance, échange de données entre systèmes et compatibilité, etc.

8. Architectures distribuées • Les applications à architectures distribuées sont des applications dont les fonctions sont réparties entre plusieurs systèmes. On les appelle aussi architectures multi-tiers (ou multi-couches) • Chaque système contient une partie de l’application, les parties manquantes sont exécutées sur les autres systèmes participants à l’application et les informations sont échangées par le réseau

9. Architecture distribuée • Une application est composée de 3 couches fondamentales: • Couche de présentation • interface utilisateur... • Présenter les données à l’utilisateur • Couche Applicative / Logique métier : • validation et traitement des données • modélisation des processus métiers (règles métier) • Couche d’accès de données / Persistence

10. Architecture distribuée • Architecture simple tiers (monolithique, un seul poste) • Architecture 2 tiers ou client-serveur • Architecture 3 tiers • Architectures n-tiers (multiplication du nombre de couches fonctionnelles de plus en plus fines) • On impose pas que toutes les couches d’une application fonctionnent sur des machines différentes • Séparation logique fonctionnelle OU séparation physique des couches ?

11. Répartition des fonctions • sur la couche présentation, une application cliente est chargée de l’affichage et de la saisie des données • Client web léger, Application java client ou applets (RMI), Application client CORBA (IIOP ) • sur la couche application, un serveur d’application maintient des composants métiers utilisés pour modéliser sous forme d’objet les processus de l’application Serveurs de: • présentation, outils métiers, servlets,JSP , EJB • sur la couche données, les serveurs du système d’information d’entreprise stockent les composants métiers • bases de données relationnelles ou objets, intégrés (ERP), annuaires d’entreprise LDAP,… IIOP : l’Internet Inter-Orb Protocol (IIOP) utilisé pour transmettre des objets sur le réseau. RMI : RemoteMethod Invocation..de java

12. Répartition des fonctions La division du logiciel en plusieurs couches facilite la maintenance des applications et leurs permet de mieux s’adapter par exemple à une montée en charge

13. Exemple Répartition en couches : Cas du 3 Tiers • Considérons une architecture courante, celle à trois niveaux: • La couche [1], (User Interface) : dialogue avec l'utilisateur, via une interface. Elle a pour rôle de fournir des données provenant de l'utilisateur à la couche [2] ou bien de présenter à l'utilisateur des données fournies par la couche [2]. • La couche [2], appelée ici [Métier] est la couche qui applique les règles dites métier, c.a.d. la logique spécifique de l'application, sans se préoccuper de savoir d'où viennent les données qu'on lui donne, ni où vont les résultats qu'elle produit. • La couche [3], appelée ici [dao] (Data Access Object) est la couche qui fournit à la couche [2] des données pré-enregistrées et qui enregistre certains des résultats fournis par la couche [2]. Couche Interface Couche Métier Couche d’accès aux données (DAO) utilisateur Données 1 2 3

14. Exemple : Couche accès aux données Il existe différentes possibilités pour implémenter la couche accès aux données. Le développeur peut diviser en tiers dotés de fonctionnalités spécifiques Couche Interface Couche Métier Couche d’accès aux données (DAO) Couche JDBC Base de données utilisateur 1 2 3 La couche [JDBC] est la couche standard utilisée en Java pour accéder à des bases de données. Elle isole la couche [dao] du SGBD qui gère la base de données. On peut théoriquement changer de SGBD sans changer le code de la couche [dao].

15. Suite Exemple : Couche accès aux données Pour isoler la couche [dao] des aspects propriétaires des SGBD. Une solution est celle du Framework Hibernate ou (JPA, TopLink dans JEE) Couche d’accès aux données (DAO) Objets image de la BD Couche Hibernate Couche JDBC BD La couche [Hibernate] vient se placer entre la couche [dao] écrite par le développeur et la couche [Jdbc] Hibernate est un ORM (Object Relational Mapping), un outil qui fait le pont entre le modèle relationnel des bases de données et celui des objets manipulés par Java Le développeur ne voit plus la couche [Jdbc] ni les tables de la BD. Il ne voit que l'image objet de BD, fournie par la couche [Hibernate]. Le pont entre les tables de la BD et les objets manipulés par la couche [dao] est fait principalement de deux façons : • par des fichiers de configuration de type XML • par des annotations Java dans le code, technique disponible depuis le JDK 1.5

16. Framework • Il existe des frameworks pour lier ces couches entre-elles. Par exemple Spring • Le grand intérêt de Spring est qu'il permet de lier les couches par configuration et non dans le code • Avec Java EE , une autre solution existe : implémenter les couches [metier] et [dao] avec des Ejb3 (Enterprise Java Bean 3)

17. Programmation par composants 1/2 • Limites de la programmation usuelle • plus adaptée à la programmation de “petits projets” (programming in the small) • tout est à la charge du programmeur: • la liaison entre les différentes couches de l’application (présentation, application, données), • construction des objets utilisées sur les couches, • la structure de l’application est peu visible et particulière à chaque application ( pas de généricité) • l’évolution de l’application est difficile: ajout de fonctionnalités, modification des conditions d’installation, changement de la BD • le développement, la génération des exécutables et leur déploiement ne sont pas standardisés

18. Programmation par composants 2/2 • Programmation par composition (ou constructive) • Elle est motivée par la réutilisation des logiciels déjà existants et propose de créer des applications réparties par assemblage de composants logiciels existants. • C’est le concept du “programming in the large” où l’on définit des composants génériques qui sont ensuite réutilisables dans plusieurs applications.

19. Composants • Un composant est un module logiciel autonome, configurable et installable sur plusieurs plates-formes. • Un composant: • exporte des attributs, propriétés et méthodes, • peut être configurable • Les composants sont les briques de bases configurables d’une application par composition. • Parmi les différentes technologies de composants on peut citer : • JavaBeans, • Enterprise Java Beans, • composants CORBA • Etc.

20. Construction d’application par assemblage de composants • La création d’une application par assemblage de composants se distingue de l’ingénierie de développement classique car elle permet de: • réduire les besoins en compétences techniques • focaliser l’expertise sur les problèmes du domaine (logique métier) • Réduire les coûts de développement et de maintenance

21. Principes de JEE (1/3) Tiers Services Web Tiers Données Tiers Métier • L’architecture JEE est une architecture d’application distribuée à base de composants. Ces composants sont mis en œuvre par l’intermédiaire des conteneurs Tiers Interface Conteneur Applet Serveur d’application Conteneur EJB Navigateur Conteneur Web Serveur Web Serveur de bases de données Internet Composant Métier Bean Composant Client Applet/ Html/wml Composant Web Servlet/JSP Exemple Composants d’une application Web J2EE

23. Composants J2EE • Un composant est une unité logicielle de niveau applicatif. • JEE supporte les types de composants suivants : • applets, • application clientes, • JavaBeans • composants Enterprise JavaBeans (EJB), • composants Web, • composants adaptateurs de ressource • etc

24. Les conteneurs JEE • Eléments fondamentaux de l’architecture JEE • Les conteneurs JEE fournissent une interface parfaitement définie ainsi qu’un ensemble de services permettant aux développeurs de se concentrer sur la logique métier. • Les conteneurs et serveurs implémentent les services et mécanismes de bas niveau utilisés par les applications: • La communication entre les clients et les serveurs • Le contrôle de la sécurité • La gestion des transactions • L’identification et la localisation des ressources

25. Conteneurs JEE • Les conteneurs et serveurs implémentent les mécanismes de bas niveau utilisés par les applications: • transactions, • persistance, • gestion de la mémoire, • sécurité • Les spécifications J2EE s’intéressent aux activités d’une application liées: • au développement, • au déploiement, • à l’exécution

26. JEE 4 types de Conteneur Couche client Conteneur d'applet Java SE Couche Web Couche métier Applet Conteneur Web Java SE Conteneur d'EJB Java SE JSP Servlet EJB Java Mail Java Mail Conteneur du client de l'application Java SE JMS JAVA JTA JAXP JDBC JCX JMS JAVA JTA JAXP JDBC JCX JAF JAF Client de l'application Couche SI Base de données JMS JAVA JAXP JDBC

27. Clients JEE • La plateforme JEE prévoit que plusieurs types de clients puissent accéder à une même application et interagir avec les mêmes composants côté serveur: • JEE peut supporter de nombreux types de clients: Web, WAP, stations de travails, téléphones portables, PDA

28. Clients JEE • Client web (léger) • Client web RIA (Rich Internet Application) : Applets, Java Web Start, AJAX, Google Web Toolkit, Flex, JavaFX (autres version JavaFx pour mobile et pour TV) • Client lourd : des applications clientes s'exécutent dans leur propre conteneur client. Les applications clientes ont des interfaces utilisateurs qui peuvent directement interagir avec le tier EJB en utilisant RMI-IIOP (Remote Methode Invocation over Internet Inter-Orb Protocol) ou encore application C++ utilisant CORBA. • Clients sans fil (J2ME pour les dispositifs sans fil). WAP (Wireless Application Protocol) , wml (Wireless Markup Language)

29. Composants web • Un composant web est une entité logicielle qui fournit une réponse à une requête. • Les composants web génèrent habituellement l'interface utilisateur d'une application web. • La plate-forme JEE définit deux types de composants web : • les servlets ; • les JavaServer Pages (JSP). • JSF (Java Server Face)

30. Servlets (1/2) • Une « servlet » est un composant qui étend les fonctionnalités d'un serveur web de manière portable et efficace. • Un serveur web héberge des classes Java servlets qui sont exécutées à l'intérieur du conteneur web. Le serveur web associe une ou plusieurs URLs à chaque servlet et lorsque ces URLs sont appelées via une requête HTTP de l'utilisateur la servlet est déclenchée. • Quand la servlet reçoit une requête du client, elle génère une réponse, éventuellement en utilisant la logique métier contenue dans des EJBs classes javaBeans. Elle retourne alors une réponse HTML ou selon le client (XML, WML, javascript, ...)

31. Servlets (2/2) • 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

32. Java Server Pages • La technologie JavaServer Pages (JSP) fournit un moyen simple et extensible pour générer du contenu dynamique pour le client web. • Une page JSP contient : • Des informations de formatage (modèle) du document web, habituellement en HTML ou XML. • Les concepteurs web peuvent modifier cette partie de la page sans affecter les parties dynamiques. Cette approche permet de séparer la présentation du contenu dynamique. • Des éléments JSP et de script pour générer le contenu dynamique du document Web. • La plupart des pages JSP utilisent aussi des JavaBeans et/ou des Enterprise JavaBeans pour réaliser les opérations complexes de l'application. Les JSP permettent en standard d'instancier des beans, de modifier ou lire leurs attributs et de télécharger des applets. • La technologie JSP est extensible en utilisant des balises personnalisées qui peuvent être encapsulées dans des bibliothèques de balises personnalisées (taglibs)

33. Conteneur de composants web • Les composants web sont hébergés dans des conteneurs de servlets, conteneurs de JSP et conteneurs web (moteurs de servlets/jsp). • En sus des fonctionnalités normales d'un conteneur de composants, un conteneur de servlets (servlets container) fournit les services réseaux par lesquels les requêtes et réponses sont émises. • Il décode également les requêtes et formate les réponses dans le format approprié. • Tous les conteneurs de servlets doivent supporter le protocole HTTP et peuvent aussi supporter le protocole HTTPS. • Un conteneur de JSP (JSP container) fournit les mêmes services qu'un conteneur de servlets. • Ces conteneurs sont généralement appelés conteneurs web (Web containers).

34. Composants Enterprise JavaBeans • Les EJB : un des points forts du J2EE, c’est la pièce maitresse de la plateforme Java EE • L'architecture Enterprise JavaBeans est une technologie côté serveur pour développer et déployer des composants java contenant la logique métier d'une application d'entreprise. • Le conteneur EJB charge les composants à la demande et invoque les méthodes en appliquant les règles de sécurité et en contrôlant les transactions • A ne pas confondre avec les classes Java Beans

35. EJB EJB offre une gamme de services implicites • Gestion du cycle de vie (session) • Gestion de l’état • Sécurité • Transactions • Persistance • Localisation des composants transparente (comparable à objets distribués RMI, CORBA) • Répartition de charge => Le développeur se focalise sur les aspects métier

36. Les API Java EE • un ensemble d'API qui peuvent être obtenu et utilisé séparément.

37. Les API Java EE

38. Technologies J2EE

39. Technologies J2EE (1/2) • La plate-forme J2EE comme la plate-forme J2SE incluent un grand nombre de bibliothèques de code (API) prédéfinies pour les fonctions de base d'une application. • Les technologies mies en œuvre sont les suivantes : • L'architecture J2EE Connector est l'infrastructure pour interagir avec une grande variété de systèmes d'information d'entreprise tels que des ERPs, des CRM, et autres progiciels. • L'API JDBC est utilisée pour accéder à des données relationnelles à partir de programmes Java • La Java Transaction API (JTA) est utilisée pour gérer et coordonner les transactions entre un ensemble hétérogène de systèmes d'information d'entreprise. • L'API Java Naming and Directory Interface est utilisée pour accéder aux services de nommage et d'annuaire de l'entreprise. • L'API Java Message Service (JMS) est utilisée pour émettre et recevoir des messages via les systèmes de messagerie d'entreprise comme IBM MQ Series ou TIBCO Rendezvous. Dans l'architecture J2EE les Message Driven Beans fournissent une approche à base de composant pour encapsuler les fonctionnalités de messagerie. • La JavaMail API est utilisée pour émettre et recevoir des mails. • Java IDL est utilisée pour appeler des services CORBA • L'API Java pour XML (JAXP) est utilisée pour l'intégration avec les systèmes et applications existants et pour implémenter les web services dans la plate-forme J2EE.

40. Le Design Pattern MVC • Le design pattern Modèle–vue–Contrôleur permet d’organiser une application en 3 composants principaux. • le Modèle correspond aux données de l’application (récupérées suite à l’ invocations des EJB, JavaBeans) • la Vue est la présentation visuelle de l’application (JSP, Html) • le Contrôleur, qui définit l’état de la vue en fonction des données gérées par le modèle (Les Servlets). Traitement des requête du client, choix de l’opération à executer,etc • C’est une architecture logiciel : découpages et organisation des fonctionnalités de l’application selon des rôles bien définis

41. JavaBeans • Il est possible d’utiliser la technologie JavaBeans (package Beans.*) entre une page JSP et un beans pour obtenir une meilleure séparation entre Modèle, Vue et Contrôleur (Model View Controller – MVC).

42. Servlets • Les servlets sont des classes Java exécutées par le serveur web en réponse à une requête du client (en utilisant le protocole http). • Les servlets sont définies dans les packages suivants: • javax.servlet, contient les classes génériques (indépendantes du protocole) des servlets. La classe HTTPServlet utilise la classe ServletException de ce package pour indiquer un problème de servlet. • javax.servlet.http, contient la classe de serlvet concue pour le protocole HTTP (classe HttpServlet). • En général les servlets utilisent aussi le package java.io pour les entrées/sorties système. • La classe HttpServlet utilise la classe IOException de ce package pour signaler les erreurs d'entrée-sortie.

43. Java Server Pages • La technologie JavaServer Page (JSP) permet de mettre des fragments de code java dans une page HTML statique. • Lorsque la page JSP est chargée, le code java est exécuté sur le serveur. Celui-ci crée une servlet correspondante, qui est ensuite compilée et exécutée en tâche de fond. • La servlet retourne une page HTML ou un rapport en XML qui peut alors être transmis au client ou subir d’autres traitements. • Les JSP sont définies dans une classe d'implémentation appelée le package • Une page JSP est un document texte qui décrit comment créer un objet réponse (response) à partir d’un objet requête (request) pour un protocole donné. • Le traitement d’une page JSP peut entraîner la création et/ou l’utilisation d’autres objets. • Le protocole HTTP est le protocole utilisé par défaut.

44. Composants Enterprise JavaBeans (2/3) • Il y a 3 types d'entreprise beans : les beans de sessions, d'entité et de messages. • Les beans de session et d'entité comportent 2 interfaces : une interface de composant et une interface home. • L'interface home définit les méthodes pour créer, trouver, supprimer et accéder aux méta-données d'un beans. • L'interface de composant définit les méthodes métiers du beans. • Le beans à message n'ont pas d'interfaces home et composant. • Les interfaces composant et home d'un beans sont locales ou distantes.

45. Composants Enterprise JavaBeans (3/3) • Les interfaces distantes (remote interface) sont des interfaces RMI qui permettent au client du beans d'être situé n'importe où. Dans ce cas les arguments et valeurs de retour communiquées entre le client et le beans distant sont sérialisées pour être transportées sur le réseau, ce qui consomme des ressources. • Les interfaces locales impliquent que les clients du beans soient localisés dans la même machine virtuelle que le beans. Dans ces cas les arguments et valeurs de retours échangés sont transmis par référence. Cette méthode est plus performante que la méthode distante. • La section suivante donne un aperçu des composants EJB. Ils sont décrits en détail dans la suite du document.

46. Composants, conteneurs et services • Les conteneurs fournissent aux composants un accès aux APIs du J2SE, ce qui inclut l'accès aux APIs Java IDL et JDBC 2.0 core. • Le tableau suivant résume les APIs accessibles en fonction du type de conteneur.

47. Enterprise Java Beans (1/2) • Le terme Enterprise Java Bean recouvre deux notions: • c’est le nom générique d’une architecture permettant la programmation répartie en Java • c’est le nom de composants exécutés sur un serveur et appelés par un client distant • Les EJBs n’ont en commun que le nom avec les Java Beans traditionnels, qui sont des composants côté clients utilisés pour obtenir une meilleurs séparation suivant le modèle MVC ( model – view – controller). • Les Enterprise Java Beans ont pour but de rendre les applications faciles à développer, à déployer et à administrer. • Les EJBs sont indépendants de la plate-forme d’exécution, étant écrits en Java: le déploiement d’un EJB se fait sans recompilation ni modification du code-source. • Les spécifications EJB définissent une architecture pour la construction d’applications Java dont la partie serveur est construite à partir de composants Enterprise Beans.

48. Enterprise Java Beans (2/2) • Leurs caractéristiques principales sont les suivantes: • les composants EB sont “écrits une fois, exécutable partout” (write once, run anywhere) • ces composants sont des composants côtés serveur (analogues aux objets métiers de CORBA) • Les EJBs ne sont pas les seuls composants exploités dans une application J2EE mais ils en sont la partie centrale. • Les EJBs résident sur le serveur d'EJB. • Leurs méthodes sont accessibles aux clients (tiers web, application autonome) en utilisant l'interface distante home du beans. • Cette interface décrit les méthodes du beans (paramètres…) et permet au client de les appeler. • Lorsqu'une méthode est déclenchée, l'appel est enveloppé dans un message RMI transmis au serveur d'EJB, qui exécute alors la méthode de l'ÉB et retourne le résultat au client dans un autre message RMI.

49. Considérations sur les réseaux • Les clients J2EE peuvent être connectés par de nombreux types de réseaux. • La qualité de service sur ces réseaux peut varier considérablement, suivant le type de liaison (débit, connexion permanente ou intermittente). • Trois aspects du réseau impactent le développement de la partie cliente : • le temps de latence du réseau n’est pas nulle, • la bande passante n’est pas infinie, • le réseau n’est pas toujours fiable. • Une application bien conçue prend en compte ces problèmes et leur apporte des solutions. • Le client idéale connecte au serveur uniquement lorsque c’est nécessaire, transmets le minimum de données et se comporte raisonnablement bien lorsque la connexion avec le serveur est rompue.

50. Considérations sur la sécurité • Chaque type de réseau comporte des mesures de sécurité différentes, qui limitent la façon dont se connectent les clients. • Par exemple lorsque les clients se connectent par Internet, les communications transitent souvent par un firewall qui filtre laisse passer uniquement certains types de protocoles. • La plupart des firewalls sont configurés pour laisser passer le protocole hypertexte (HTTP) mais pas l’Internet Inter-Orb Protocol (IIOP) utilisé pour transmettre des objets sur le réseau. • Cet aspect incite à utiliser HTTP et non des services comme CORBA ou RMI qui utilisent le protocole IIOP pour le transport des données. • Les contraintes de sécurité affectent aussi l’identification des utilisateurs: • quand le client et le serveur sont dans le même domaine de sécurité, comme cela peut être le cas dans une application intranet, l’authentification peut être très simple et utiliser le système d’authentification de l’entreprise • dans le cas d’une application Internet les mécanismes à mettre en place sont nettement plus sophistiqués. L’architecture J2EE propose des mécanismes standards pour l’authentification. IIOP : Internet Inter-Orb Protocol(RMI over IIOP) CORBA : Common Object Request Broker