Java Enterprise Edition

Présentation au sujet: "Java Enterprise Edition"— Transcription de la présentation:

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

2 Pédagogie du cours Pré-requis: Cours :
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 ) J2EE est le terme utilisé dans les versions avant (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 Autres éditons :
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 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 : Remote Method 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 utilisateur Couche Métier Couche d’accès aux données (DAO) 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) 1 2 3 Couche JDBC Base de données utilisateur 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 Couche d’accès aux données (DAO)
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 Hibernate Objets image de la BD Couche d’accès aux données (DAO) 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) 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 Conteneur EJB Composant Métier Bean Serveur de bases de données Applet Composant Client Applet/ Html/wml Web Composant Web Servlet/JSP Internet Tiers Interface Tiers Services Web Données Tiers Métier Serveur d’application Serveur Web Navigateur Exemple Composants d’une application Web J2EE

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

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 du client de l'application Client de l'application
JEE 4 types de Conteneur Conteneur d'applet Java SE Applet du client de l'application Client de l'application JMS JAVA JAXP JDBC Conteneur Web JTA Java Mail JSP Servlet JAF JCX Conteneur d'EJB EJB 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

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. API Rôle Entreprise Java Bean (EJB) Servlets et JSP Contenu 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) JavaMail Envoie et réception d' JPA Java Persistence API

37 Les API Java EE API Rô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 IDL Utilisation de CORBA

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

51 Considérations sur la plate-forme d’exécution du client
Chaque plate-forme cliente à des capacités propres qui influencent la conception de l’application. Par exemple un navigateur ne peut pas générer des graphiques et a besoin d’un serveur pour obtenir les graphiques sous forme d’images 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 l’utilisateur 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.

52 Règles de conception générales des clients J2EE
L’architecture J2EE encourage l’utilisation de clients légers, ce qui n’empêchent pas d’accomplir plusieurs fonctions sur le client J2EE: présentation de l’interface utilisateur: les vues de l’application peuvent être téléchargées à partir du serveur (navigateur) ou traitée sur le client (application), validation des saisies de l’utilisateur: bien que le serveur d’EJB ou le serveur de données d’entreprise puissent vérifier eux aussi les données, une première validation peut avoir lieu sur le client, communication avec le serveur: quand l’utilisateur 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 l’application: les applications doivent conserver des informations d’états sur ce que fait l’utilisateur dans l’application (garder trace que l’utilisateur effectue un processus particulier…)

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 à l’utilisateur et reposent sur le serveur pour les fonctionnalités de l’application. Du point de vue du déploiement de l’application, les navigateurs sont la solution la plus attrayante: ils permettent de mettre à jour l’application le plus facilement, quand l’application 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

54 Présentation de l’interface utilisateur 1/2
Les navigateurs téléchargent les documents à partir d’un 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 l’Hypertext Markup Language (HTML). Les langages à balises permettent d’avoir 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)).

55 Présentation de l’interface utilisateur 2/2
Les navigateurs présentent l’avantage d’avoir une interface familière pour les utilisateurs et d’être largement déployés en entreprise. L’inconvénient de ce type de client réside dans le manque de possibilité d’interactions avec l’utilisateur. Il est possible d’utiliser des technologies comme AJAX, JavaScript en combinaison avec d’autres 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 l’interface. 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.

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 d’informations de configuration. L’environnement d’exécution d’une application web est appelé le conteneur web (web container). Tous les fichiers d’une 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.

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 l’interface 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 d’avoir une approche centrée sur le document (document centric) plutôt que sur la programmation lors de la conception d’une application.

58 Le conteneur web Une application J2EE est exécutée à l’intérieur d’un 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, c’est ce qui permet de porter et déployer un composant sur différents serveurs web Java sans modification du code.

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) qu’au niveau binaire (car elles sont compilées en byte-code Java, par définition portable d’une plate-forme à l’autre sans modification). En plus de produire du contenu dynamiquement, les servlets supportent plusieurs fonctionnalités applicatives.

60 Servlets Java 2/2 On peut ainsi déclencher des servlets en fonction d’évènements, en implémentant l’interface 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 d’une servlet lors de l’appel à 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 d’un cluster ; pour cela les servlets doivent être marquées comme distributable dans le descripteur de déploiement de l’application 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 d’un nœud de cluster à l’autre.

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.

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 lorsqu’elle est demandée. Les pages JSP peuvent générer n’importe quel type de contenu textuel ,mais sont à l’origine 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

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

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.

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.

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.

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.

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.

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.

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

71 Exemple <jsp:include page="/servlets/currentUserInfoServlet"/>
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.

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 : <%out.println("<a \"href=\""+url +"\">"+text);%></a> 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.

73 Mauvais exemple de JSP se comportant comme un contrôleur
<%String creditCard =request.getParameter("creditCard"); if (creditCard.equals("Visa")){%> <jsp:forward page="/processVisa.jsp"/> <%}else if (creditCard.equals("American Express")){%> <jsp:forward page="/processAmex.jsp"/> <%}%>

74 Résumé 1/3 Le serveur web d’une 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. L’utilisation 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 d’ajouter de nouveaux types de clients, processus et vues facilement.

75 Résumé 2/3 Le serveur web d’une application est une couche de service neutre, habituellement conçu sur le modèle MVC, qui simplifie la création d’applications 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 l’application et affiche les résultats. Il est possible d’utiliser plusieurs contrôleurs web pour gérer nativement des clients web utilisant des protocoles différents. Un mécanisme de modèles (templates) permet d’améliorer la mise en page des écrans de l’application. Le mécanisme de modèle permet d’utiliser un fichier modèle pour assembler des vues individuelles en une vue composée sur l’application. Les servlets sont principalement utilisées pour générer des données binaires et contrôler l’application. 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 d’une servlet existante, d’un JSP ou d’un autre filtre de servlet.

76 Résumé 3/3 Les états d’une 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 d’impact sur la charge engendrée par une application web car ils sont proportionnels au nombre d’utilisateurs. Il est recommandé d’utiliser 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é n’est pas encore standardisée. Les servlets, JSP et balises personnalisées d’une application web distribuable doivent respecter des contraintes supplémentaires.

77 Composants Enterprise Java Beans (entreprise java beans tiers)
Dans une application J2EE multi-tiers, le tiers Enterprise JavaBeans héberge la partie de l’application 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 l’application, 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 l’application stockées sur les serveurs du système d’information de l’entreprise.

78 Types de beans Il y a 3 types de beans: les beans de sessions (session beans), les beans d’entité (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 d’entité sont des composants qui représentent la vue objet d’une 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 d’entité peut être identifié par un attribut appelé la primary key. Les beans à messages sont une nouveauté de l’architecture 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 l’API Java Message Service (JMS). Les sections suivantes présentent les deux premiers types de beans et les principes généraux des beans.

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.