La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "JEE Java Enterprise Edition Riadh Ouersighni Maître de Conférence en Informatique Isitcom - 2010 1."— Transcription de la présentation:

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

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 dapplication 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 2

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 ) 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 3

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.3 plateforme pour la création dapplication RIA (Rich Internet Application) basé sur le langage Java FX Script 4

5 Quest ce que le Java EE (ou J2EE) La Plateforme JEE désigne les technologies Java utilisées pour le développement d'applications «dentreprise » 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 : 1. 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. 2. un ensemble d'API qui peuvent être obtenu et utilisé séparément. 5

6 Quest ce que le JEE Un ensemble de spécifications dAPI, une architecture distribuée et une méthode de packaging et de déploiement des composants. Cest 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 dune architecture standardisée 6

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

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 lapplication, les parties manquantes sont exécutées sur les autres systèmes participants à lapplication et les informations sont échangées par le réseau 8

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

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 dune application fonctionnent sur des machines différentes Séparation logique fonctionnelle OU séparation physique des couches ? 10

11 Répartition des fonctions 1. sur la couche présentation, une application cliente est chargée de laffichage et de la saisie des données Client web léger, Application java client ou applets (RMI), Application client CORBA (IIOP ) 2. sur la couche application, un serveur dapplication maintient des composants métiers utilisés pour modéliser sous forme dobjet les processus de lapplication Serveurs de: présentation, outils métiers, servlets,JSP, EJB 3. sur la couche données, les serveurs du système dinformation dentreprise stockent les composants métiers bases de données relationnelles ou objets, intégrés (ERP), annuaires dentreprise LDAP,… IIOP : lInternet Inter-Orb Protocol (IIOP) utilisé pour transmettre des objets sur le réseau. RMI : Remote Method Invocation..de java 11

12 12 Répartition des fonctions La division du logiciel en plusieurs couches facilite la maintenance des applications et leurs permet de mieux sadapter 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 utilisateur Couche Métier Couche daccès aux données (DAO) Données

14 Exemple : Couche accès aux données utilisateur 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 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]. 14 Couche Interface Couche Métier Couche daccès aux données (DAO) 123 Couche JDBC Base de données

15 Couche Hibernate Objets image de la BD Couche daccès aux données (DAO) Couche JDBC BD Pour isoler la couche [dao] des aspects propriétaires des SGBD. Une solution est celle du Framework Hibernate ou (JPA, TopLink dans JEE) 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 Suite Exemple : Couche accès aux données

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) 16

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 lapplication (présentation, application, données), construction des objets utilisées sur les couches, la structure de lapplication est peu visible et particulière à chaque application ( pas de généricité) lévolution de lapplication est difficile: ajout de fonctionnalités, modification des conditions dinstallation, changement de la BD le développement, la génération des exécutables et leur déploiement ne sont pas standardisés 17

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. Cest le concept du programming in the large où lon définit des composants génériques qui sont ensuite réutilisables dans plusieurs applications. 18

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 dune application par composition. Parmi les différentes technologies de composants on peut citer : JavaBeans, Enterprise Java Beans, composants CORBA Etc. 19

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

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

22 22

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 23

24 Les conteneurs JEE Eléments fondamentaux de larchitecture JEE Les conteneurs JEE fournissent une interface parfaitement définie ainsi quun 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 Lidentification et la localisation des ressources 24

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 sintéressent aux activités dune application liées: au développement, au déploiement, à lexécution 25

26 26 JEE 4 types de Conteneur Conteneur d'applet Java SE Conteneur d'applet Java SE Applet Conteneur du client de l'application Java SE Conteneur du client de l'application Java SE Client de l'applicatio n JMSJAVAJAXPJDBC Conteneur Web Java SE Conteneur Web Java SE JMSJAVAJTA Java Mail JSP Servlet JAF JAXPJDBCJCX Conteneur d'EJB Java SE Conteneur d'EJB Java SE JMSJAVAJTA Java Mail EJB JAF JAXPJDBCJCX Base de données Couche client Couche Web Couche métier Couche SI

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 27

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) 28

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) 29

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,...) 30

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 31

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) 32

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). 33

34 Composants Enterprise JavaBeans Les EJB : un des points forts du J2EE, cest 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 34

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 35

36 Les API Java EE 36 APIRôle Entreprise Java Bean (EJB) Servlets et JSPContenu web dynamique RMI (Remote Method Invocation) et RMI-IIOP objet Java distribué. RMI-IIOP est une extension de RMI pour utiliser avec CORBA. JNDI Java Naming and Directory Interface Accès aux services de nommage et aux annuaires d'entreprises, LDAP JDBC (Java Database Connectivity)Accès aux bases de données. J2EE intègre une extension de cette API Java Transaction API (JTA) Java Transaction Service (JTS) Support des transactions Java Messaging service (JMS)Support de messages via des MOM (Messages Oriented Middleware) JavaMailEnvoie et réception d' JPAJava Persistence API un ensemble d'API qui peuvent être obtenu et utilisé séparément.

37 37 APIRôle JSF (Java Server Faces)API pour le développement d'applications web (Interface graphique riche) avec JSP, la JSTL (JavaServer Pages Standard Tag Library) Swing, Ajax, WML Java API for XML Parsing (JAXP)Analyse et exploitation de données au format XML Java Authentication and Authorization Service (JAAS) Echange sécurisé de données Java API for XML-based RPC (JAXP-RPC) API XML SOAP with Attachments API for Java (SAAJ) Web services J2EE Connector Architecture (JCA)Connecteurs pour accéder à des ressources du système d'information de l'entreprises ERP ou progiciel intégré Java IDLUtilisation de CORBA Les API Java EE

38 Technologies J2EE 38

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. 39

40 Le Design Pattern MVC Le design pattern Modèle–vue–Contrôleur permet dorganiser une application en 3 composants principaux. le Modèle correspond aux données de lapplication (récupérées suite à l invocations des EJB, JavaBeans) la Vue est la présentation visuelle de lapplication (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 lopération à executer,etc Cest une architecture logiciel : découpages et organisation des fonctionnalités de lapplication selon des rôles bien définis 40

41 JavaBeans Il est possible dutiliser 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). 41

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. 42

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 dautres 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 dun objet requête (request) pour un protocole donné. Le traitement dune page JSP peut entraîner la création et/ou lutilisation dautres objets. Le protocole HTTP est le protocole utilisé par défaut. 43

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. 44

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. 45

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. 46

47 Enterprise Java Beans (1/2) Le terme Enterprise Java Bean recouvre deux notions: cest le nom générique dune architecture permettant la programmation répartie en Java cest le nom de composants exécutés sur un serveur et appelés par un client distant Les EJBs nont 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 dexécution, étant écrits en Java: le déploiement dun EJB se fait sans recompilation ni modification du code- source. Les spécifications EJB définissent une architecture pour la construction dapplications Java dont la partie serveur est construite à partir de composants Enterprise Beans. 47

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. 48

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 nest pas nulle, la bande passante nest pas infinie, le réseau nest 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 cest nécessaire, transmets le minimum de données et se comporte raisonnablement bien lorsque la connexion avec le serveur est rompue. 49

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 lInternet 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 lidentification 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, lauthentification peut être très simple et utiliser le système dauthentification de lentreprise dans le cas dune application Internet les mécanismes à mettre en place sont nettement plus sophistiqués. Larchitecture J2EE propose des mécanismes standards pour lauthentification. IIOP : Internet Inter-Orb Protocol (RMI over IIOP)Internet Inter-Orb Protocol CORBA : Common Object Request BrokerCommon Object Request Broker 50

51 Considérations sur la plate-forme dexécution du client Chaque plate-forme cliente à des capacités propres qui influencent la conception de lapplication. Par exemple un navigateur ne peut pas générer des graphiques et a besoin dun serveur pour obtenir les graphiques sous forme dimages téléchargées à partir du serveur. Un client programmable peut télécharger uniquement les données numériques et construire lui-même un graphique. Une autre chose à prendre en compte est la prise en charge des formulaires par le client, qui varie suivant le type de terminal (grands écrans, souris et clavier sur une station de travail, petits écrans et boutons pour des téléphones portables…), et qui impose des limitations à la quantité de données manipulée par lutilisateur sur son terminal. Une application qui gère plusieurs types de plates-formes doit mettre en place des stratégies spécifiques pour distribuer les ressources en fonction du type de terminal client. 51

52 Règles de conception générales des clients J2EE Larchitecture J2EE encourage lutilisation de clients légers, ce qui nempêchent pas daccomplir plusieurs fonctions sur le client J2EE: présentation de linterface utilisateur: les vues de lapplication peuvent être téléchargées à partir du serveur (navigateur) ou traitée sur le client (application), validation des saisies de lutilisateur: bien que le serveur dEJB ou le serveur de données dentreprise puissent vérifier eux aussi les données, une première validation peut avoir lieu sur le client, communication avec le serveur: quand lutilisateur sollicite une fonction gérée par le serveur, le client doit envoyer une requête vers le serveur dans un protocole compréhensible par les deux parties, gestion des états de lapplication: les applications doivent conserver des informations détats sur ce que fait lutilisateur dans lapplication (garder trace que lutilisateur effectue un processus particulier…) 52

53 Règles de conception pour les navigateurs web Les navigateurs sont le type de client le plus léger. Ils présentent les données à lutilisateur et reposent sur le serveur pour les fonctionnalités de lapplication. Du point de vue du déploiement de lapplication, les navigateurs sont la solution la plus attrayante: ils permettent de mettre à jour lapplication le plus facilement, quand lapplication change seul le côté serveur est modifié, ils sont présent sur un très grand nombre de plates-formes, notamment sur les terminaux mobiles 53

54 Présentation de linterface utilisateur 1/2 Les navigateurs téléchargent les documents à partir dun serveur. Les documents contiennent les données ainsi que des instructions pour présenter les données. Ces documents sont en général construits dynamiquement à partir de pages JSP (et moins souvent à partir de servlets) et écrits dans un langage à balise tel que lHypertext Markup Language (HTML). Les langages à balises permettent davoir une présentation raisonnable quel que soit le navigateur utilisé. Il y a des alternatives à HTML particulièrement pour les terminaux mobiles (Wireless Markup Language (WML), Compact HTML, (CHTML), Extensible HTML (XHTML) Basic, et Voice Markup Language (VoiceML)). 54

55 Présentation de linterface utilisateur 2/2 Les navigateurs présentent lavantage davoir une interface familière pour les utilisateurs et dêtre largement déployés en entreprise. Linconvénient de ce type de client réside dans le manque de possibilité dinteractions avec lutilisateur. Il est possible dutiliser des technologies comme AJAX, JavaScript en combinaison avec dautres standards comme les CSS et le Document Object Model (DOM), et le XmlHttprequest. Un autre problème plus important est le temps de réponse potentiellement faible des navigateurs. Le client dépend du serveur pour la présentation donc il doit contacter le serveur à chaque modification de linterface. Le client crée une connexion avec le serveur à chaque fois, ce qui peut induire des problèmes de temps de latence. Envoyer les informations de présentation en même temps que les données peut entraîner une plus grande consommation de bande passante. 55

56 Technologies web spécifiques à J2EE 1/2 Les technologies web utilisées sur un serveur J2EE sont portables, sécurisées et standardisées. Une application web est un assemblage de composants de serveurs web, de contenu et dinformations de configuration. Lenvironnement dexécution dune application web est appelé le conteneur web (web container). Tous les fichiers dune application web sont contenus un fichier Web Application Archive (WAR) qui contient également un fichier de description de dépliement rédigé en XML. Les spécifications de la plate-forme J2EE définissent un contrat entre le conteneur web et les composants web, qui définit le cycle de vie des composants, les comportements que le composant implémente et les services que le serveur rend aux composants. 56

57 Technologies web spécifiques à J2EE 2/2 Les spécifications J2EE définissent 2 types de composants web : les Servlets Java (servlets) et les JavaServer Pages (pages JSP) Une servlet est une classe Java qui étend un serveur J2EE, produisant du contenu dynamique en réponse aux requêtes du serveur. Le serveur transmet les requêtes de services à la servlet via linterface standard javax.servlet, que chaque servlet doit implémenter. Une page JSP est une page HTML qui comporte des balises spéciales qui produisent du contenu dynamique personnalisé en fonction de la requête. Les pages JSP sont habituellement transformées en servlets lors du déploiement. La technologie JSP permet davoir une approche centrée sur le document (document centric) plutôt que sur la programmation lors de la conception dune application. 57

58 Le conteneur web Une application J2EE est exécutée à lintérieur dun conteneur web. Le conteneur web gère le cycle de vie des composants web et distribue les requêtes aux composants. Il fournit aussi des interfaces standards pour accéder au contexte, notamment aux informations de session et aux informations sur la requête courante. Le conteneur web fournit une interface consistante aux composants, indépendamment du serveur web, cest ce qui permet de porter et déployer un composant sur différents serveurs web Java sans modification du code. 58

59 Servlets Java 1/2 Les servlets Java sont des classes qui étendent les serveurs web compatibles J2EE. Une servlet produit du contenu dynamique en réponse aux requêtes portant sur une ou plusieurs URLs. Les servlets sont des classes Java compilées portables tant au niveau du code source (car elles respectent les spécifications sur les Servlets Java) quau niveau binaire (car elles sont compilées en byte-code Java, par définition portable dune plate-forme à lautre sans modification). En plus de produire du contenu dynamiquement, les servlets supportent plusieurs fonctionnalités applicatives. 59

60 Servlets Java 2/2 On peut ainsi déclencher des servlets en fonction dévènements, en implémentant linterface listener, ou déclencher un ou plusieurs servlets filters, des classes chargées de pré- ou post- traiter la requête ou la réponse dune servlet lors de lappel à sa méthode service. Les servlets peuvent aussi être distribuables, le serveur web peut alors supporter des mécanismes déquilibrage de charge et transmettre les informations de sessions entre les différents nœuds dun cluster ; pour cela les servlets doivent être marquées comme distributable dans le descripteur de déploiement de lapplication web et respecter des contraintes propres aux servlets distribuables. Ces contraintes assurent que le code de la servlet continue à fonctionner correctement lors du déplacement dun nœud de cluster à lautre. 60

61 JavaServer Pages (JSP) (1/2) Les JSP sont la technologie la plus appropriée pour les applications web qui produisent des pages Web dynamiquement en modifiant uniquement les champs de données et pas la structure de base de la page. Une page JSP contient un modèle de document statique et des balises spécifiques pour inclure du texte ou exécuter une partie de la logique applicative. Le contenu statique est servi comme du HTML normal. 61

62 JavaServer Pages (JSP) (2/2) Les spécifications JSP définissent un jeu de balises standards implémentées par toutes les implémentations de serveurs web Java. Les balises personnalisées et les éléments de script génèrent du contenu dynamique inclus dans la page lorsquelle est demandée. Les pages JSP peuvent générer nimporte quel type de contenu textuel,mais sont à lorigine prévues pour générer du contenu structuré tel que du HTML, XML, XHTML,…. Les pages JSP sont plus faciles à écrire que les servlets Cours JSP Cours JSP 62

63 Où utiliser les JSP ? Les pages JSP sont habituellement utilisées pour créer du contenu structuré ou des données textuelles non-structurées. Elles sont particulièrement adaptées lorsque la valeur des données change entre les requêtes mais que leur structuration ne change pas (ou peu). 63

64 Utiliser les JSP pour la présentation des données Les pages JSP sont particulièrement appropriées pour produire du contenu structuré. Les vues pour visualiser les données d'une application d'entreprise sont traditionnellement en HTML, XHTML et DHTML. Les pages JSP sont utilisées lorsque le contenu est partiellement statique, avec quelques éléments remplis dynamiquement à l'exécution. Une page JSP contient une partie fixe appelée "template data" (à ne pas confondre avec les mécanismes de modèles décrits par la suite). Les balises personnalisées ou les éléments de script sont peuvent être placés à divers endroits des données statiques et sont substitués à l'exécution par du contenu dynamique. Les pages JSP ne peuvent pas produire de contenu binaire et ne sont pas très adaptées à la production de contenu à grande variabilité ou à la direction de requêtes, on préférera utiliser des servlets dans ce cas. Les pages JSP peuvent accéder facilement à la logique métier d'une application, en incluant des beans par exemple. 64

65 Utiliser les JSP pour générer du XML Les pages JSP sont une bonne technologie pour générer du XML avec une structure fixe. Elles sont particulièrement adaptées pour générer des messages XML dans des formats standards, où les balises sont fixes et où seules les valeurs d'attribut ou les données brutes varient entre les appels à la page. Les documents XML peuvent aussi être générés à partir de modèles, en agrégeant par exemple plusieurs documents XML pour constituer un seul document composite. 65

66 Utiliser les JSP pour générer du texte non-structuré Il est tout à fait possible de générer du texte brut (ASCII, Postscript) à partir d'une JSP. Par exemple une JSP peut générer les mails à envoyer aux clients d'une application. 66

67 Utiliser les JSP comme modèles (templates) Les JSP peuvent aussi être utilisées pour agréger du contenu provenant de plusieurs sources, comme cela est expliqué par la suite. 67

68 Encodage des pages JSP Les JSPs utilisent la classe javax.servlet.jsp.JSPWriter pour écrire le contenu sur le flux de sortie (la réponse envoyée au client). Cette classe s' assure que le contenu envoyé au client est correctement encodé, mais cela à un impact : l'encodage automatique du texte empêche de produire du contenu bianire à partir d'une JSP. 68

69 Eviter d'utiliser trop de balises logiques Les bibliothèques de balises standard fournissent des balises dites logic tags qui permettent de faire des boucles, des itérations, d'évaluer des expressions et de prendre des décisions conditionnelles. Il faut éviter ce genre de balises qui finalement apportent peu de bénéfices car elles entraînent une séparation moins claire entre la présentation et la logique de l'application. A la place, il vaut mieux implémenter la logique dans une balise personnalisée qui fait appel à un entreprise beans. Ainsi une fine couche de code (le gestionnaire de balises ou tag handler) lie la balise personnalisée à un beans et utilise ses méthodes. Cette approche permet de lier la vue (page JSP ou servlet) à un accès direct au modèle de données (contenu dans le beans), permettant ainsi de conserver la logique et la présentation séparées. 69

70 Utiliser les directives d'inclusion et les balises d'inclusion JSP à bon escient La directive include des JSP et la balise jsp:include ont la même syntaxe mais des buts différents. Une directive d'inclusion incluse le texte littéralement dans la page et ne permet pas de traiter du contenu dynamique. L'inclusion a lieu lorsque la page JSP est compilée. Par exemple l'instruction suivante inclut une page dans la JSP lors de la compilation : La balise JSP include inclut du contenu dynamique ou statique à chaque fois que la page est servie et permet donc d'inclure du contenu dynamique à l'exécution (à chaque fois que la page est servie). 70

71 Exemple La directive JSP d'inclusion sert plutôt pour réutiliser du contenu et rendre modulaire ses pages web, tout en réduisant leur taille. Il faut prendre en compte que le fait que le fichier est inclus à la compilation et donc la servlet résultante est plus grosse qu'une servlet qui inclut les pages à l'exécution (mais cette dernière solution réclame plus de temps). A chaque fois qu'une page JSP est demandée dans le cas d'un inclusion par la balise JSP include, les pages liées ont recompilées. De plus les composants utilisés (par exemple des JavaBeans ou d'autres objets fournis par le conteneur) doivent être re-déclarés dans chacune des pages inclues et partagés entre les pages via l'utilisation de l'objet HttpSession. Les directives d'inclusion peuvent être problématiques pour supporter l'internationalisation. Ainsi le header HTTP contentType:charset des pages inclues ne peut être assigné différemment dans les pages inclues et la page qui inclut. (le contentType de cette page l'emporte) Note d'implémentation: certains conteneurs web comme Tomcat ne prennent pas automatiquement en compte les modifications faites aux fichiers inclus par la directive include. Si vous changez un fichier inclus, il faut "toucher" (modifier la date de dernière modification) les documents parents qui incluent le fichier. 71

72 Utiliser des balises personnalisées pour éviter les éléments de script Il est préférable d'utiliser des balises personnalisées plutôt que des éléments de script (scriptlets) pour les raisons suivantes : le code scriplet n'est pas réutilisable le code scriptlet mélange logique et présentation de l'application dans la même page le code scriptlet ne permet pas de bien séparer les rôles entre les développeurs de pages web et de code Java Un concepteur web aura par exemple du mal à modifier du code Java pour lui appliquer une présentation : "+text);%> le code scriptlet est plus difficile à lire et à maintenir que des balises personnalisées Les informations de débogage d'une scriptlet peuvent être difficiles à interpréter, en définissant du code associé à une balise personnalisée on peut localiser plus facilement l'erreur Le code de scriptlet est plus difficile à tester, avec des balises personnalisées, on dispose de composants personnalisés prêt à subir des tests unitaires Éviter de rediriger des requêtes à partir de pages JSP Quand une page JSP appelle RequestDispatcher.forward elle se comporte comme un contrôleur. Les contrôleurs sont de préférence implémentés dans des servlets, pas dans des composants de présentation. 72

73 Mauvais exemple de JSP se comportant comme un contrôleur <%String creditCard =request.getParameter("creditCard"); if (creditCard.equals("Visa")){%> 73

74 Résumé 1/3 Le serveur web dune application J2EE rend disponible les applications sur le World Wide Web. Les pages JSPs et les servlets sont des composants web qui succèdent aux anciennes technologies côté serveur telles que les CGIs et qui assurent une portabilité inégalée. Le conteneur web fournit des services de haut niveau aux composants web en matière de transactions,accès aux données, gestion des états, sécurité et distribution. Lutilisation de bibliothèques de balises personnalisées améliore la qualité du code source et facilite la maintenance des applications. Le patron de conception Modèle-Vue-Contrôleur est recommandé pour la plupart des applications web interactives car il permet de créer des applications réutilisables, et dajouter de nouveaux types de clients, processus et vues facilement. 74

75 Résumé 2/3 Le serveur web dune application est une couche de service neutre, habituellement conçu sur le modèle MVC, qui simplifie la création dapplications web interactives. Le modèle de conception le plus simple a un seul contrôleur qui reçoit les requêtes des navigateurs, les distribue dans lapplication et affiche les résultats. Il est possible dutiliser plusieurs contrôleurs web pour gérer nativement des clients web utilisant des protocoles différents. Un mécanisme de modèles (templates) permet daméliorer la mise en page des écrans de lapplication. Le mécanisme de modèle permet dutiliser un fichier modèle pour assembler des vues individuelles en une vue composée sur lapplication. Les servlets sont principalement utilisées pour générer des données binaires et contrôler lapplication. Les pages JSP sont principalement utilisées pour créer du contenu textuel et des références à des données externes. Les filtres de servlets peuvent être utilisés pour étendre les fonctionnalités dune servlet existante, dun JSP ou dun autre filtre de servlet. 75

76 Résumé 3/3 Les états dune application web ont 4 types de portées : portée application, portée session, portée requête et portée page. Les états de portée session ont le plus dimpact sur la charge engendrée par une application web car ils sont proportionnels au nombre dutilisateurs. Il est recommandé dutiliser des beans de session avec états pour conserver les données de session. Les applications uniquement web peuvent stocker les informations de session dans les attributs de session HTTP. Certains produits J2EE permettent à une application dêtre distribuée pour augmenter sa disponibilité et sa scalabilité mais cette possibilité nest pas encore standardisée. Les servlets, JSP et balises personnalisées dune application web distribuable doivent respecter des contraintes supplémentaires. 76

77 Composants Enterprise Java Beans (entreprise java beans tiers) Dans une application J2EE multi-tiers, le tiers Enterprise JavaBeans héberge la partie de lapplication concernant la logique métier et fournit les services systèmeainsi que la gestion de la concurrence, des transactions et de la sécurité. La technologie EJB fournit un modèle de composants distribués qui permet aux développeurs de se concentrer sur les problèmes liés à la logique métier de lapplication, en se reposant sur la plate-forme J2EE pour toutes les interactions complexes avec le système. Dans le modèle de programmation J2EE les composants EJB sont le lien fondamental entre les composants de présentation hébergés par le tiers web et les données de lapplication stockées sur les serveurs du système dinformation de lentreprise. 77

78 Types de beans Il y a 3 types de beans: les beans de sessions (session beans), les beans dentité (entity beans) et les beans à message (message-driven beans). Les beans de session sont des beans destinés à contenir des ressources privées concernant un seul client. Pour cette raison, les beans de session paraissent du point de vue du client comme anonymes. Les beans dentité sont des composants qui représentent la vue objet dune entité stockée dans un entrepôt de données persistant, comme une base de données. Par rapport au beans de session, chaque beans dentité peut être identifié par un attribut appelé la primary key. Les beans à messages sont une nouveauté de larchitecture EJB 2.0 et sont supportés à partir de la plate-forme J2EE 1.3. Les beans à message sont des composants qui traite de manière asynchrone des messages délivrés par lAPI Java Message Service (JMS). Les sections suivantes présentent les deux premiers types de beans et les principes généraux des beans. 78

79 Principe des beans Les EJBs sont des objets dérivés de la classe de base EJBObject, contenue dans le package javax.ejb. Les EJBs sont définies dans les spécifications EJB 2.0. Ce sont des composants capables dêtre exécutés en environnement distribué, avec des capacités transactionnelles et une gestion de la persistance. La philosophie WORA : Write Once, Run Anywhere a guidé la conception des EJBs. Ces composants permettent d'étendre dynamiquement le comportement d'un serveur et de connecter facilement des applications à une BD. Utiliser des EJB revient à enficher des entités autonomes sur une plate-forme applicative Java. Les beans doivent implémenter deux types d'interfaces : - une interface home, chargée de créer et gérer les beans - une interface "normale" qui implémente les méthodes métiers des beans. Ces interfaces peuvent être soient locales soit distantes. En plus d'implémenter ces interfaces un beans dispose des caractéristiques décrites ci-après. 79


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

Présentations similaires


Annonces Google