Java 2 Enterprise Edition
Support de formation          Architecture J2EE             Version 1.0


           Auteur : Ludovic MAITRE - ludovic.mai...
Support de formation                                  Architecture J2EE                                       Version 1.0
...
Support de formation                 Architecture J2EE                     Version 1.0



.IGÉNÉRALITÉS


.I.1Architecture...
Support de formation                 Architecture J2EE                      Version 1.0




.I.2Motivations pour les serve...
Support de formation                  Architecture J2EE                     Version 1.0




.I.3Programmation par composan...
Support de formation              Architecture J2EE                   Version 1.0




Composants

 Un composant est un mod...
Support de formation                 Architecture J2EE                      Version 1.0



Conteneur

  Un conteneur encap...
Support de formation              Architecture J2EE                  Version 1.0



Modèles de composants

  Ils fournisse...
Support de formation                  Architecture J2EE                        Version 1.0



.IIINTRODUCTION À J2EE

.II....
Support de formation                Architecture J2EE                    Version 1.0




.II.2Technologies de composants u...
Support de formation   Architecture J2EE   Version 1.0




                       Composants J2EE




                    ...
Support de formation                 Architecture J2EE                      Version 1.0




Clients J2EE

  La plateforme ...
Support de formation               Architecture J2EE                    Version 1.0



Composants web

 Un composant web e...
Support de formation                 Architecture J2EE                     Version 1.0



  Conteneur de composants web

 ...
Support de formation                  Architecture J2EE                Version 1.0



Beans de session (session bean)

Un ...
Support de formation               Architecture J2EE                    Version 1.0


Composants, conteneurs et services

...
Support de formation                Architecture J2EE                    Version 1.0




.II.3Rôles

  J2EE définit différ...
Support de formation                Architecture J2EE                   Version 1.0




.II.4Contrats

  L’architecture J2...
Support de formation                  Architecture J2EE                    Version 1.0



Le contrat côté client

  Il pré...
Support de formation        Architecture J2EE   Version 1.0



.IIITOPOLOGIE(S) D'UNE APPLICATION J2EE
                   ...
Support de formation         Architecture J2EE   Version 1.0




.III.2Client autonome




Client autonome "EJB-centric"

...
Support de formation        Architecture J2EE   Version 1.0




.III.3Application web




Détails application web




.III...
Support de formation               Architecture J2EE                     Version 1.0



.IVTECHNOLOGIES J2EE

 La platefor...
Support de formation               Architecture J2EE                   Version 1.0




.IV.3Java Naming and Directory Inte...
Support de formation                Architecture J2EE                    Version 1.0




.IV.4Java DataBase Connectivity (...
Support de formation                  Architecture J2EE                      Version 1.0




.IV.5Servlets

 Les servlets ...
Support de formation                Architecture J2EE                    Version 1.0




.IV.7Enterprise Java Beans
 Le te...
Support de formation                  Architecture J2EE                        Version 1.0



.VCOMPOSANTS D'UNE APPLICATI...
Support de formation                  Architecture J2EE                     Version 1.0


Considérations sur la plateforme...
Support de formation                 Architecture J2EE                    Version 1.0



Règles de conception pour les nav...
Support de formation                 Architecture J2EE                    Version 1.0




Validation des saisies utilisate...
Support de formation                  Architecture J2EE                    Version 1.0




Communication avec le serveur

...
Support de formation                 Architecture J2EE                     Version 1.0




Conserver les informations d’ét...
Support de formation                 Architecture J2EE                     Version 1.0




Règles de conception des client...
Support de formation                   Architecture J2EE                       Version 1.0




Présentation de l’interface...
Support de formation                   Architecture J2EE                 Version 1.0



Clients web

Comme les navigateurs...
Support de formation               Architecture J2EE                      Version 1.0


Servlet chargé de récupérer une re...
Support de formation               Architecture J2EE                   Version 1.0




 Gestion des informations d’état

 ...
Support de formation                Architecture J2EE                     Version 1.0




.V.2Composants web (web tier)

 ...
Support de formation                Architecture J2EE                     Version 1.0




Technologies utilisées sur le se...
Support de formation                  Architecture J2EE                     Version 1.0




Le conteneur web

Une applicat...
Support de formation                 Architecture J2EE                     Version 1.0


Les balises JSP sont de 3 types :...
Support de formation                Architecture J2EE                     Version 1.0



Les balises personnalisées procur...
Support de formation                 Architecture J2EE                    Version 1.0




Règles de conception des composa...
Support de formation                Architecture J2EE                     Version 1.0



Exemple de servlet génératrice de...
Support de formation                 Architecture J2EE                    Version 1.0




Utiliser les redirections et inc...
Support de formation                   Architecture J2EE                      Version 1.0




Utiliser les JSP pour génére...
Support de formation                 Architecture J2EE                      Version 1.0



La directive JSP d'inclusion se...
Support de formation   Architecture J2EE   Version 1.0


<%}%>




                                50/77
Support de formation                  Architecture J2EE                      Version 1.0



Résumé

 Le serveur web d’une ...
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Document sur l'architecture J2EE
Prochain SlideShare
Chargement dans…5
×

Document sur l'architecture J2EE

3 867 vues

Publié le

Publié dans : Technologie
0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 867
Sur SlideShare
0
Issues des intégrations
0
Intégrations
3
Actions
Partages
0
Téléchargements
338
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Document sur l'architecture J2EE

  1. 1. Java 2 Enterprise Edition
  2. 2. Support de formation Architecture J2EE Version 1.0 Auteur : Ludovic MAITRE - ludovic.maitre@sophia.inria.fr 2/77
  3. 3. Support de formation Architecture J2EE Version 1.0 .I Généralités.......................................................................................................................................4 .I.1 Architectures distribuées...........................................................................................................4 .I.2 Motivations pour les serveurs d’application...............................................................................5 .I.3 Programmation par composants ...............................................................................................6 .II Introduction à J2EE.......................................................................................................................10 .II.1 Principes de J2EE..................................................................................................................10 .II.2 Technologies de composants utilisées dans J2EE.................................................................11 .II.3 Rôles......................................................................................................................................18 .II.4 Contrats..................................................................................................................................19 .III Topologie(s) d'une application J2EE ...........................................................................................21 .III.1 Application multitiers..............................................................................................................21 .III.2 Client autonome....................................................................................................................22 .III.3 Application web.....................................................................................................................23 .III.4 Application Business-to-business..........................................................................................23 .IV Technologies J2EE .....................................................................................................................24 .IV.1 Remote Method Interface (RMI)............................................................................................24 .IV.2 JavaBeans............................................................................................................................24 .IV.3 Java Naming and Directory Interface (JNDI).........................................................................25 .IV.4 Java DataBase Connectivity (JDBC).....................................................................................26 .IV.5 Servlets ................................................................................................................................27 .IV.6 Java Server Pages ...............................................................................................................27 .IV.7 Enterprise Java Beans .........................................................................................................28 .V Composants d'une application J2EE............................................................................................29 .V.1 Composants d'application client (client tier)...........................................................................29 .V.2 Composants web (web tier)....................................................................................................40 .V.3 Composants Enterprise Java Beans (enterprise java beans tier)...........................................52 .V.4 Session .................................................................................................................................63 .V.5 Entités ...................................................................................................................................65 .V.6 Implémenter et utiliser un bean..............................................................................................67 .V.7 Serveur d’EJB........................................................................................................................68 .V.8 Conteneurs d'EJB..................................................................................................................68 .VI Connection aux ressources de l'entreprise .................................................................................72 .VI.1 Types d’objets pour l’accès aux données..............................................................................72 .VII Implémentations.........................................................................................................................74 .VII.1 Open source ........................................................................................................................74 .VII.2 Commerciales .....................................................................................................................74 .VIII Bibliographie..............................................................................................................................75 3/77
  4. 4. Support de formation Architecture J2EE Version 1.0 .IGÉNÉRALITÉS .I.1Architectures 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. Une architecture distribuée typique est l’architecture client-serveur, où les fonctions sont réparties entre un système client (station de travail, terminal,…) et un système serveur (serveur PC, Unix, mainframe…). Les fonctions d’une application sont généralement réparties en 3 catégories : - fonctions de présentation - fonctions applicatives / orientées métier - fonctions de stockage Plusieurs systèmes coopèrent pour réaliser toutes les fonctions d’une application distribuée : - sur la couche présentation, une application cliente est chargée de l’affichage et de la saisie des données : browsers web (http/HTML), applets (RMI), contrôles ActiveX (DCOM), clients 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 (ex : factures, caddies,…). Serveurs de : présentation, outils métiers, CGI, servlets… - 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), legacy (mainframe), annuaires d’entreprise,… L’objectif des serveurs d’application est de simplifier le développement des applications à architecture distribuée, en permettant une séparation plus grande entre les 3 couches de l’application (présentation, logique et données). Le développeur peut alors se concentrer sur la logique de son application, le reste étant pris en charge par la structure d’accueil : - sessions - transactions, - persistance, - sécurité - nommage, - charge Plusieurs voies existent pour programmer par composants sur la couche applications, les plus connues étant DCOM et EJB . 4/77
  5. 5. Support de formation Architecture J2EE Version 1.0 .I.2Motivations pour les serveurs d’application Productivité En fournissant des services standards pour le développement d'application multi-tiers et le support de plusieurs clients, les serveurs d'application permettent de développer plus rapidement les applications et de se focaliser sur la logique métier de l'application plutôt que sur des tâches de bas niveau (communication entre composants,…). Augmenter la productivité permet aussi de mettre plus rapidement sur le marché les applications et ainsi de réduire les risques de créer une application en retard sur le marché. Intégration avec l’existant La plupart des données des entreprises ont été amassées au cours des années par les systèmes d'information existants de l'entreprise. L' un des objectifs des serveurs d'application est de mettre à la disposition des développeurs des moyens standards d'accès aux données de ces systèmes. Liberté de choix La rapidité de développement d'une application dépend de plus en plus de la mise en œuvre de solutions hétérogènes au sein d'un même application. La grande diversité de serveurs J2EE permet d'adapter le système sur lequel fonctionnera l'application en fonction de la charge et des demandes des utilisateurs en matière de temps de réponses. J2EE mets en place des mécanismes et technologies standards pour la création d'application, ce qui permet d'utiliser des produits d'éditeurs différents, par exemple des environnements de développements et des serveurs J2EE issus de plusieurs éditeurs. L'utilisation de standards permet d'utiliser ses propres composants pour les fonctiosn spécifiques de l'application et d'utiliser des composants crées par des éditeurs de logiciels pour les fonctions de base. Réponse adaptée à la demande Les architectures avec serveurs d'applications permettent la mise en place d'applications qui supportent facilement la montée en charge, sans avoir à recoder l'application. Traditionnellement, l'utilisation de serveurs supplémentaires pour traiter un plus grand nombre de clients demandait un recodage complet des applications, tandis que l'architecture J2EE met en place des mécanismes simples pour répartir la charge entre plusieurs serveurs, sur les différentes couches de l'application. Maintenance et sécurité L'un des objectifs des serveurs d'application est mettre en place une architecture de sécurité qui soit efficace sur tous les tiers d'une application. Avec les applications webs, cela est plus difficile à mettre en place car si l'entreprise à le contrôle sur toute la partie serveur, elle n'a que peu de possibilité pour mettre en place la sécurité au niveau du client, sauf dans le cas de clients Java. 5/77
  6. 6. Support de formation Architecture J2EE Version 1.0 .I.3Programmation par composants Les limites de la programmation usuelle Elle est plus adaptée à la programmation de « petits projets » (programming in the small) car - tout est à la charge du programmeur : de la liaison entre les différentes couches de l’application (présentation, application, données), la construction de objets utilisées sur les couches, la définition des fonctions… - la structure de l’application est peu visible et particulière à chaque application (fichiers…) - l’évolution de l’application est difficile : ajout de fonctionnalités, modification des conditions d’installation… - le développement, la génération des exécutables et leur déploiement ne sont pas standardisés La 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. Dans cette approche on décrit l’architecture de l’application à l’aide d’un langages déclaratif qui permet de préciser : - le modèle de construction des composants : o interfaces o attributs o implèmentation - la description des interactions entre composants (connecteurs) - la description de variables d’environnement (placement, sécurité…) 6/77
  7. 7. Support de formation Architecture J2EE Version 1.0 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 - est capable de s’auto-décrire (introspection) Les composants sont les briques de bases configurables d’une application par composition. Parmi les différentes technologies de composants on peut citer COM /DCOM, Java Beans, Enterprise Java Beans et les composants CORBA. Un composant peut dépendre d’autres composants et servir d’entrée à d’autres composants. Les connecteurs utilisés par le composant pour communiquer avec son environnement peuvent être synchrones (flux avec attente de réponse) ou asynchrones (flux sans attente de réponse). Le composant fournit des entrées sur ses composantes et opérations et peut être paramétré via ses propriétés configurables (informations sur le déploiement…). Le composant doit supporter des contraintes techniques en rapport avec : - le middleware (placement, sécurité, transaction), - le fonctionnement interne du composant (persistance, gestion du cycle de vie) - les contraintes liées à l’implémentation : OS, bibliothèques, versions,… 7/77
  8. 8. Support de formation Architecture J2EE Version 1.0 Conteneur Un conteneur encapsule les composants et prend en charge les services liés au système : nommage, sécurité, transaction, persistance, …. Le conteneur gère aussi en partie les connecteurs, car c’est lui qui est responsable du déclenchement des événements et des instanciations de composants. Techniquemment cela se produit par délégation ou interposition, les appels des composants transitent par le conteneur qui y répond lorsqu’il en a la charge ou les transmet au destinataire. Structures d’accueil Les structures d’accueil sont les espaces d’exécution des conteneurs et des composants, elles servent de médiateur entre les conteneurs et les services systèmes (sandbox). Certaines peuvent prendre en charge le téléchargement de code additionnel (navigateur web…). La Java Virtual Machine est la structure d’accueil d’une application J2EE. 8/77
  9. 9. Support de formation Architecture J2EE Version 1.0 Modèles de composants Ils fournissent des spécifications pour : - l’installation de composants : technologie de packaging, production des conteneurs - la création des composants : fabriques de composants (maisons / « home ») et configuration des valeurs initiales - la recherche des composants : services de nommage des composants (ou techniques maison dans les composants) - l’utilisation des composants : invocation synchrone et déclenchement par événements - l’introspection : fonctions pour découvrir les fonctions et les connecteurs des composants (structure) 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 Des langages de description d’architecture on été mis au point (IDL : interface description language). Ces langages permettent : - de capturer les fonctionnalités et besoins de chaque composant - de décrire les connecteurs : o composition et modes de communication, o impédance entre composants et adaptateurs 9/77
  10. 10. Support de formation Architecture J2EE Version 1.0 .IIINTRODUCTION À J2EE .II.1Principes de J2EE L’architecture J2EE est une architecture d’application distribuée à base de composants. Elle identifie et donne les spécifications des composants de l’application : - composants logiciels ou beans (EJB), - conteneur - serveurs - clients Les conteneurs isolent les beans du client et d’une implémentation spécifique du serveur. Les beans sont installés dans la partie serveur d’une application J2EE. Communications au sein d’une application J2EE - vue générale 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 10/77
  11. 11. Support de formation Architecture J2EE Version 1.0 .II.2Technologies de composants utilisées dans J2EE Un composant est une unité logicielle de niveau applicatif. En plus des JavaBeans, qui font partie du J2SE, J2EE supporte les typesde composants suivants : - applets, - application clientes, - composants Enterprise JavaBeans (EJB), - composants Web, - composants adaptateurs de resource Les applets et applications clientes sont exécutées sur le poste du client tandis que les composants EJB, Web et adaptateurs de ressources fonctionnent sur le serveur. A léxception des adaptateurs de ressources, les concepterus et développeurs d'application développents les composants d'une application J2EE. Les adapteurs de ressources et logiciels associés sont en géneral vendu par les forunisseurs de systèmes d'information de l'entreprise et ensuite déployés sur les serveurs pour accèder aux données. Tous les composants J2EE dépendent à l'exécution d'un entité système baptisée conteneur (container). Les conteneurs fournissent aux composants des services de bases comme la gestion du cycle de vie, la sécurité, le déploiement et l'exécution en thread. Comme cést le conteneur qui gère ces services, la plupart des paramètres de configuration de ces services peuvent être configurés lors du déploiement des omcposants en fonction de la plateforme d'accueil. Par exemple un fournisseur d'Enterprise JavaBean peut spécifier un nom de base de données auquel le composant doit accéder et c'est seulement lors du déploiement que les informations d'accès à la base (nom d'utilisateur et mot de pase ) seront configurés. Les sections suivantes donnent un bref apercu des composants, qui seront étudiés plus en détail par la suite. 11/77
  12. 12. Support de formation Architecture J2EE Version 1.0 Composants J2EE 12/77
  13. 13. Support de formation Architecture J2EE Version 1.0 Clients J2EE La plateforme J2EE prévoit que plusieurs types de clients puissent accéder à une même application et interagir avec les composants côté serveur. Applets Les Applets sont des clients Java qui s'exécutent habituellement dans un navigateur web et qui ont accès à toutes les possibilités du langage Java. Les applications J2EE peuvent utiliser des clients applets pour avoir des interfaces utilisateurs plus puissantes que celles conues en HTML. Les applets communiquent avec le serveur par HTTP. Applications clientes Des applications clientes s'exécutent dans leur propre conteneur client. (le conteneur client est un jeu de librairies et d'API qui supportent le code client). Les applications clients ont des interfaces utilisateurs qui peuvent directment interagir avec le tier EJB en utilisant RMI-IIOP. Ces clients ont un accès complet.aux services de la plateforme J2EE comme les services de nommage JNDI, l'envoi de messages et JDBC. Le conteneur client gére l'accès à ces services et les communications RMI-IIOP. Applications clientes Java Web Start Les applications clients Java Web Start sont des applications autonomes reposant sur les JFC et Swing et capables d'utiliser les services de la plateforme J2EE par l'intermédiaire de la technologie Java WebStart. Ces applications peuvent être installées par le web et comuniquent avec le servuer en utilisant du XML encapsulé dans du HTTP(S). Clients sans fil Les clients sans fil sont basés sur la technologie Mobile Information Device Profile (MIDP), en conjonction avec Connected Limited Device Configuration (CLDC), qui fournissent un environnement J2ME complet pour les dispositifs sans fil. 13/77
  14. 14. Support de formation Architecture J2EE Version 1.0 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 plateforme J2EE définit deux types de composants web : les servlets et les JavaServer Pages (JSP). La section suivante donne un apercu de ces composants qui sont détaillés utlérieurement. Servlets 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 container web. Le serveur web associe un e 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 recoit une requête du client, elle génére une réponse, éventuellement en utilisant la logique métier contenue dans des EJBs ou en interrogeant directement une base de données. Elle retourne alors une réponse HTML ou XML au demandeur. Un développeur de servlet utilise l'API servlet pour : - Initialiser et finaliser la servlet - Accéder à lénvironnement de la servlet - Recevoir ou rediriger les requêtes et envoyer les réponses - Interagir avec d'autres serlvets 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 tier web JavaServer 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 est un document texte qui décrit comment traiter la requête d'un client et comment créer une réponse. Une page JSP contient : - des informations de formatage (modèle) du document web, hqbituellement 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 élements JSP et de script pour générer le contenu dynamique du document Web. La plupart des pages JSP utilise 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élecharger des applets. La technologie JSP est extensible en utilisant des balises personnalisées qui peuvent être encapsuler dans des bibliothèques de balises personnaliées (taglibs) 14/77
  15. 15. Support de formation Architecture J2EE Version 1.0 Conteneur de composants web Les composants webs sont hébergés dans des conteneurs de servlets, conteneurs de JSP et conteneurs web. 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). Composants Enterprise JavaBeans L'architecture Enterprise JavaBeans est une technologie côté serveur pour développer et déployer des composants contenant la logique métier d'une application d'entreprise. Les composants Enterprise JavaBeans, aussi appelé Enterprise Beans, sont scalables, transactionnel et supporte l'accès concurrent. Il y a 3 types d'enterprise beans : les beans de sessions, d'entité et de messages. Les bean 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 bean. L'interface de composant définit les méthodes métiers du bean. Le bean à message n'ont pas d'interfaces home et composant. Les interfaces composant et home d'un bean sont locales ou distantes. Les interfaces distantes (remote interface) sont des interfaces RMI qui permettent au client du bean d'être situé n'importe où. Dans ce cas les arguments et valeurs de retour communiquées entre le client et le bean 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 bean soient localisés dans la même machine virtuelle que le bean. 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 apercu des composants EJB. Ils sont décrits en détail dans la suite du document. 15/77
  16. 16. Support de formation Architecture J2EE Version 1.0 Beans de session (session bean) Un bean de session fournit un service au lcient et habituellement n'existe que le temps d'une session cliente. Un bean de session accompli des opérations de calcul ou d'accès à une base de données pour le client. Bien qu'un bean de session puisse être transactionnel, il ne dispose pas de mécanismes de reprise sur erreur en casde plantage du serveur. Les beans de session peuvent être sans état (stateless) ou peuvent maintenir des informations d'état entre les appels de méthode et les transactions (stateful). Si le bean maintient des informations d'état, c'est au container d'EJB de garder ces informations lorsque le bean est déchargé de la mémoire du serveur. Cependant c'est au bean lui-même de gérer la persistance des données si il y a lieu. Beans d'entité (entity bean) Un bean d'entité est un objet persistant qui représente des données stockés dans une entrepôt de données. Un bean d'entité est identifié par sa clé primaire (primary key). Un bean d'entité peut assurer lui-même la persistance de ses données ou la déléguer au conteneur d'EJB. Les beans dont la persistance est gérée par le conteneur sont plus portables et peuvent maintenir des relations entre eux. Cette fonction permet de joindre plusieurs tables de bases de données. Si le bean gére lui-même sa persistance, alors le programmeur devra surement changer une partie du code SQL en changeant de base de données. Bean à message (Message-Driven Beans) Un bean à message permet à un client asynchrone d'accéder à la logique métier d'un tier EJB. A message-driven bean enables asynchronous clients to access the business logic in the EJB tier. Les beans à messages sont activés uniquement par des messages recus d'une file de message JMS qu'ils écoutent. Les clients n'accèdent pas directement au bean à message mais envoient un message à la file JMS. Comme les beans à messages n'ont pas besoin d'exposer leurs méthodes à un client ils n'implémentent pas les interface composants ou home. Ils ne maintiennent pas non plus d'information d'état sur le client. Conteneur d'EJB (EJB Component Containers) Les Enterprise beans sont hébergés dans des conteneurs d'EJB (EJB container). En plus des services traditionnels d'un conteneur, un conteneur EJB fournit des services de transaction et de persistance aux beans qu'il héberge, ainsi qu'un accès qaux services J2EE et aux APIs de communication. 16/77
  17. 17. Support de formation Architecture J2EE Version 1.0 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. Application API Applet Web EJB Client JDBC 2.0 Extension N Y Y Y JTA 1.0 N N Y Y JNDI 1.2 N Y Y Y Servlet 2.3 N N Y N JSP 1.2 N N Y N EJB 2.0 N Y1 Y2 Y RMI-IIOP 1.0 N Y Y Y JMS 1.0 N Y Y Y JavaMail 1.2 N N Y Y JAF 1.0 N N Y Y JAXP 1.1 N Y Y Y JAAS 1.0 N Y Y Y Connector 1.0 N N Y Y 1 Les application clientes peuvent utiliser uniquement les API EJB clientes. 2 Les Servlets et pages JSP peuvent utiliser uniquement les API EJB clientes. 17/77
  18. 18. Support de formation Architecture J2EE Version 1.0 .II.3Rôles J2EE définit différents rôles associés aux différentes parties intervenant dans la production d’une application 18/77
  19. 19. Support de formation Architecture J2EE Version 1.0 .II.4Contrats L’architecture J2EE définit des contrats associés à un bean. Ces contrats sont passés entre le conteneur et les clients qui utilisent le bean. Ce sont des règles obligatoires qui doivent être respectées par le fournisseur de l’EJB et le conteneur. Le but des contrats est de fournir une modèle de développement standard pour les applications qui utilisent les composants EJBs. En particulier, 3 contrats sont définis : - le contrat côté client doit permettre de fournir une vue uniforme du bean au client, indépendante de la plate-forme de déploiement - le contrat côté conteneur doit permettre la portabilité des beans sur différents serveurs EJBs - le contrat côté déploiement : fournir un format de fichier standard pour distribuer les beans ; ce format doit être supporté par tous les outils liés aux EJBs. 19/77
  20. 20. Support de formation Architecture J2EE Version 1.0 Le contrat côté client Il précise que le beans doit pouvoir être localisé en utilisant JNDI. Il précise une interface standard d’accès au bean qui doit être fournie par le fournisseur d’EJBs (EJB provider). L’interface standard définit en fait 2 interfaces à implémenter par les beans : - l’interface Home contient les méthodes liées à la gestion du bean : create, remove, finder,… - l’interface Remote contient les méthodes de l’application Le conteneur doit implémenter un mécanisme de délégation pour faire suivre les appels au bean. Il n’y a pas de communication directe entre le client et le bean mais une communication entre le client et le conteneur, ce dernier se chargeant de retransmettre les messages au bean. Le contrat du conteneur Le conteneur doit gérer le cycle de vie et l’état des beans, la sécurité, les transactions distribuées, la concurrence et l’extensibilité. Le conteneur appelle des méthodes fournies par le bean lorsque c’est nécessaire (callback methods). Le conteneur doit gérer plusieurs types de bean : - beans de session (session beans) - beans d’entité (entity beans) Les spécifications EJB 2.0 ajoutent une 3ème type de bean, les beans à message (message driven beans). 20/77
  21. 21. Support de formation Architecture J2EE Version 1.0 .IIITOPOLOGIE(S) D'UNE APPLICATION J2EE Schéma général .III.1Application multitiers 21/77
  22. 22. Support de formation Architecture J2EE Version 1.0 .III.2Client autonome Client autonome "EJB-centric" 22/77
  23. 23. Support de formation Architecture J2EE Version 1.0 .III.3Application web Détails application web .III.4Application Business-to-business 23/77
  24. 24. Support de formation Architecture J2EE Version 1.0 .IVTECHNOLOGIES J2EE La plateforme J2EE comme la plateforme 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 lestransactions entre une 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'annaire 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 emails. - Java IDL est utilisé 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 webservices dans la plateforme J2EE. .IV.1Remote Method Interface (RMI) Interface pour les méthodes distantes. Le package java correspondant est javax.rmi. Le principe de RMI est de rendre possible l’accès aux méthodes d’un objet distant en établissant une connexion réseau (socket) entre le client et le serveur où sont stockés les objets. Le client connaît les méthodes de l’objet distant au moyen des classes stubs qui contiennent les signatures des méthodes distantes. Les classes javax.rmi sont utilisées pour chercher l'interface home d'un bean de session et l'activer sur le serveur distant. .IV.2JavaBeans Il est possible d’utiliser la technologie JavaBeans (package Beans.*) entre une page JSP et un bean pour obtenir une meilleure séparation entre Modèle, Vue et Contrôleur (Model View Controller – MVC). Le modèle MVC est un patron de conception (design pattern) qui consiste en 3 types d’objets : - le Modèle procure la logique métier de l’application, - la Vue est la présentation de l’application, - le Contrôleur est un objet qui gère les interactions entre l’utilisateur et la Vue. Un patron de conception décrit un problème récurrent et ses solutions, les solutions ne sont jamais exactement les mêmes pour chaque occurrence du problème mais le patron de conception donne une solution générale au problème qu’il suffit d’adapter i. 24/77
  25. 25. Support de formation Architecture J2EE Version 1.0 .IV.3Java Naming and Directory Interface (JNDI) La technologie JNDI est utilisée dans J2EE pour localiser les objets sur un serveur et accéder aux objets externes à partir des composants J2EE. Chaque conteneur stocke une référence aux objets qu’il peut créer et instancie ces objets à la demande des clients ou des applications qui fonctionnent sur le serveur. Le conteneur met aussi à la disposition des composants un jeu de ressources JNDI initial, issu de la configuration du serveur et/ou des applications web (via les descripteurs de déploiement). Un ojbet InitialContext est crée par le conteneur lorsqu'une webapplication est déployée. Cet objet est accessible par les composants, en lecture seulement. Dans Tomcat, ces ressources JDNI initiales sont accessibles dans l'espace de nommage java:comp/env. Exemple d'accès à une ressource JDBC par JNDI : // Obtain our environment naming context Context initCtx = new InitialContext(); Context envCtx = (Context) initCtx.lookup("java:comp/env"); // Look up our data source DataSource ds = (DataSource) envCtx.lookup("jdbc/EmployeeDB"); // Allocate and use a connection from the pool Connection conn = ds.getConnection(); ... use this connection to access the database ... conn.close(); L'API JNDI est définie dans le package javax.naming. L'autre rôle de JNDI dans une application J2EE est la localisation des interfaces distantes des beans. 25/77
  26. 26. Support de formation Architecture J2EE Version 1.0 .IV.4Java DataBase Connectivity (JDBC) Cette API est développée par Sun en collaboration avec les grands éditeurs de SGBD. Elle supporte plus de 50 drivers, permettant de se connecter aux bases de 40 éditeurs parmis lesquels Oracle, Informix, Postgres, Ingres, Sybase ... JDBC supporte le SQL 2 ANSI pour l’écriture des requêtes plus des extensions spécifiques à chaque base de données. Les tâches assurées par JDBC sont : – Gestion des connexions et transactions – Préparation de requêtes SQL – Accès aisé aux résultats JDBC est une architecture “bas niveau”, qui est utilisée dans les applications J2EE pour assurer les fonctions de persistance des donnéees. L’utilisation de JDBC est faite soit par le conteneur d’application (Container Managed Persistence) soit directement dans le bean (Bean Managed Persistence). L’utilisation typique de JDBC dans une classe java est la suivante : - Chargement du driver - Connection à la base (classe Connection) - Expression d’une requête (classes Statement et PreparedStatement) - Analyse du résultat (classe ResultSet) Ex. de connection JDBC : String url = “jdbc:postgresql://murphy/towns” Connection c = DriverManager. getConnection( url); Statement s = c. createStatement(); ResultSet r = s. executeQuery(“ SELECT * FROM VILLES”); while (r. next()) { int i = r. getInt(" Population"); String s = r. getString(" Ville"); System. out. println(“ Ville “+ s+” a “+ i+” hab.”); ...... } 26/77
  27. 27. Support de formation Architecture J2EE Version 1.0 .IV.5Servlets 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éneral 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 erreur d'entrée-sortie. .IV.6Java 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 par un navigateur web, 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. 27/77
  28. 28. Support de formation Architecture J2EE Version 1.0 .IV.7Enterprise Java Beans 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 Javabeans 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 plateforme 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. 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é serveurs (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 EBs résident sur le serveur d'EJB. Leurs méthodes sont accessibles aux clients (tier web, application autonome) en utilisant l'interface distante home du bean. Cette interface décrit les méthodes du bean (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. 28/77
  29. 29. Support de formation Architecture J2EE Version 1.0 .VCOMPOSANTS D'UNE APPLICATION J2EE .V.1Composants d'application client (client tier) Du point de vue du développeur une application J2EE peut supporter de nombreux types de clients : stations de travails, assistants numériques, téléphones cellulaires… Ces clients peuvent accèder à l’application par l’intranet ou le World Wide Web, et par des médiums différents : connexions sans ou avec fil, ou combinaison des deux. Du point de vue de l’utilisateur, le client est l’application. Elle doit être utile, utilisable et avoir de bons temps de réponse. Les programmes d’exemples utilisées dans ce chapitre sont tirées de l’application d’exemple Java Pet Store, disponible en ligne sur le site de Sun, et du site web Java Blue Prints. 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éseaux impactent le développement de la partie cliente : - le temps de latence du réseaux 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éal se 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. Considérations sur la sécurité Chaque type de réseau comporte des mesures de sécurité différentes, qui limitent la façcon don’t 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 tandis que 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. 29/77
  30. 30. Support de formation Architecture J2EE Version 1.0 Considérations sur la plateforme d’exécution du client Chaque plateforme 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 plateformes doit mettre en place des stratégies spécifiques pour distribuer les ressources en fonction du type de terminal client. 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…) Les sections suivantes présentent les règles de conception pour les deux types de clients les plus répandus : les navigateurs web et les applications Java. 30/77
  31. 31. Support de formation Architecture J2EE Version 1.0 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’aplication, 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 plateformes, notamment sur les terminaux mobiles Présentation de l’interface utilisateur Les navigateurs téléchargent les documents à partir d’un serveur. Ces documents contiennent les données ainsi que des instructions pour présenter les données. Ces docuements 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)). Les navigateurs présentent aussi 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 JavaScript en combinaison avec d’autres standards comme les Cascading Style Sheets (CSS) et le Document Object Model (DOM), on parle alors de Dynamic HTML (DHTML). Cependant le support de ces technologies est très inégal suivant les navigateurs, même si la situation tend à s’améliorer (Netscape 6, Internet Explorer 6). 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. En conséquence, le client crée une connexion avec le serveur à chaque fois, ce qui peut induire des problèmes de temps de latence. De plus le fait d’envoyer les informations de présentation en même temps que les données peut entraîner une plus grande consommation de bande passante. 31/77
  32. 32. Support de formation Architecture J2EE Version 1.0 Validation des saisies utilisateur Si l’on considère une formulaire HTML, le navigateur ne peut pas appliquer de vérification des information seul. Il est cependant possible d’inclure quelques vérifications simples sur le navigateur pour éviter des connexions inutiles vers le serveur. Il est possible d’utiliser des fonctions Javascript pour effectuer des vérifications sommaires avant l’envoi des données vers le serveur. Les fonctions Javascripts peuvent être générées par des JSP par exemple. Exemple : Formulaire HTML : <form name="account_form"method="POST" action="http://acme.sun.com/create_account" onSubmit="return checkFamilyName();"> <p>Family name:<input type="text"name="family_name"></p> <!-...--> <p><input type="submit"value="Send it!"/></p> </form> Fonction Javascript de validation : <script language="JavaScript"> <!-- function checkFamilyName(){ var familyName = window.document.account_form.family_name.value; if (familyName ==""){ alert("You didn't enter a family name."); return false; } else { return true; } } --> </script> Les EJBs et le serveur de données doivent eux aussi valider les données, et on ne doit jamais faire exclusivement confiance au client pour la validation : celui-ci peut facilement être détourné. 32/77
  33. 33. Support de formation Architecture J2EE Version 1.0 Communication avec le serveur Les navigateurs se connectent à une application J2EE par le web et pour cela utilise le protocole http. Quand des interfaces de navigateurs sont utilisées dans une application, cela impacte la façon dont l’utilisateur interagit avec l’application : on utilise alors des hyperliens, des images et textes cliquables et des formulaires pour recueillir les actions de l’utilisateur. Le navigateur traduit ces actions en requêtes HTTP transmises au serveur web. Les requêtes de l’utilisateur pour demander des ressources sont en général des requête HTTP GET. L’URL des requêtes peut inclure des paramètres pour indiquer les données à envoyer. Par exemple la requête pour afficher tous les chiens dans l’application Pet Store est : http://javapetstore.sun.com/product.screen?category_id=DOGS Les requêtes pour modifier des données sur le serveur sont en général des requêtes HTTP POST. Ce type de requête emploie le type MIME application/x-www-form-urlencoded . Par exemple une requête pour une commande peut utiliser l’URL : http://javapetstore.sun.com/cart.do Le corps de la requête pourrait inclure la ligne suivante : action=add&itemId=EST-27 La Servlet API fournit une interface simple pour capturer les requêtes entrants de type GET et POST et pour en extraire les paramètres. Après qu’un serveur aie traité la requête d’un client, il doit retourner une réponse http qui contient en général un document HTML généré à partir de pages JSP. 33/77
  34. 34. Support de formation Architecture J2EE Version 1.0 Conserver les informations d’état Comme HTTP est un procotole à base de requêtes et de réponses, chaque requête est traitée individuellement. Il a donc été nécessaire de développer des mécanismes pour identifier un client particulier et conserver l’état de la conversation avec le client. Une extension au protocole HTTP (HTTP State Management Mechanism) introduit la notion de session et d’état de session (session state). Une session est une séquence de demandes de services provenant d’un même utilisateur sur une courte durée. Les informations d’état d’une session permettent de conserver les informations d’une session entre plusieurs requêtes. Par exemple, un caddy utilise les informations d’état pour garder une trace des articles sélectionnées par l’utilisateur. Deux moyens existent pour maintenir les informations d’états avec un navigateur : les cookies et la réécriture d'URL. Cookies Les cookies sont des données que le serveur envoie au client. A chaque fois que le client envoie des informations au serveur, il inclut les cookies reçus du serveur . Malheureusement, certains utilisateurs désactivent les cookies, certains firewalls ou passerelles filtrent les cookies et certains navigateurs ne les prennent pas en charge. On ne peut donc pas toujours compter sur ce système pour conserver les informations de session. De plus seule une petite quantité d’information peut être stockée sur le client par ce moyen ( 4Ko est la taille habituelle supportée par les navigateurs) Réécriture d'URL La ré-écriture d’URLs (URL rewriting) stocke les informations de session dans l’URL, ainsi lorsque l’utilisateur demande une URL les informations de session sont incluses dans l’URL. Cette technique peut être utilisée dans la plupart des environnements mais consomme plus de bande passante et demande au serveur de récrire l’URL à chaque requête, ce qui augmente la taille de la réponse envoyée au client Ces deux techniques sont vulnérables : les cookies sont stockés dans le système de fichiers du terminal de l’utilisateur, et un utilisateur malveillant pourrait les modifier. De plus les mécanismes de cache au niveau du client peuvent avoir des effets de bord, il faut donc veiller à permettre l’effacement des cookies. 34/77
  35. 35. Support de formation Architecture J2EE Version 1.0 Règles de conception des clients Java Les clients Java peuvent être divisés en trois grandes catégories : les applications, les applets et les MIDlets. Ces trois types de clients utilisent des librairies communes mais diffèrent dans leur déploiement. Applications clientes Les applications clientes utilisent le Java 2 Runtime Environment, Standard Edition (JRE). Elles sont très similaires aux applications autonomes et dépendent moins des serveurs que les navigateurs. Les applications clientes sont distribuées dans des fichiers JAR et peuvent être explicitement installées sur les postes clients ou installées à la demande en utilisant la technologie Java Web Start. Applets Les applets sont des composants qui prennent en charge l’interface utilisateur et s’exécutent dans un navigateur web. Elles dépendent plus d’un serveur que les applications et sont aussi distribuées sous forme de fichiers JAR. Les applets sont exécutées avec le Java Plug-In, qui fournit les mêmes classes que le JRE. MIDlets Les MIDlets sont de petites applications programmées pour le Mobile Information Device Profile (MIDP), un jeu d’API Java qui en conjonction avec le Connected Limited Device Configuration (CLDC), fournit un environnement d’exécution Java 2 Micro Edition (J2ME) pour les terminaux mobiles. Ce type d’application est distribué dans un fichier JAR qui contient à la fois les classes et les ressources utilisées par l’application et avec une fichier de description de l’application (Java Application Descriptor (JAD) ). 35/77
  36. 36. Support de formation Architecture J2EE Version 1.0 Présentation de l’interface utilisateur Bien qu’un client Java contienne l’interface de l’application, la logique derrière l’interface peut en fait provenir du serveur comme c’est le cas pour un navigateur ou être entièrement incluse dans l’application. C’est ce cas qui est présenté ici. Les applets et applications Java peuvent utiliser les Java Foundation Classes (JFC)/l’API Swing,un ensemble de composants pour la création d’interfaces client tandis que les MIDlets, utilisent la MIDP User Interface API, une API dédiée à la création d’interface pour des terminaux mobiles. La création d’interface pour des clients Java demandent habituellement plus de travail que la création d’une interface de navigateur, mais les bénéfices ergonomiques sont substantiels et les capacités de programmation sont plus vastes. De plus ce type de client réclame moins de bande passante, car seules les données sont échangées entre le serveur et le client, la présentation étant prise en charge par ce dernier. Validation des saisies de l’utilisateur Les clients Java peuvent embarquer une partie de la logique applicative pour vérifier les données côté client et ainsi réaliser des vérifications plus poussées sur les données avant de les envoyer au serveur. Exemple : public void validateAll()throws ApplicationException { if (username.size()<4){ /*Complain about username being too short...*/ } if (password.size()<6){ /*Complain about password being too short...*/ } if (zipCode.size()!=5){ /*Complain about ZIP code not having 5 characters...*/ } if (creditCard.size()!=12){ /*Complain about credit card number not having 12 digits...*/ } } Evidemment la manière la plus simple de réduire les validations côté client consiste à rendre impossible la saisie de données erronées, par exemple en privilégiant l’utilisation de listes déroulantes et cases à cocher pour recueillir les informations de l’utilisateur. Communication avec le serveur Les clients Java peuvent accèder à l’application J2EE de plusieurs façons : - en tant que client web, en passant par un serveur web - en tant que client EJB, en communiquant directement avec un serveur d’EJB - en tant que client du serveur d’entreprise, en se connectant directement aux serveurs du système d’information de l’entreprise 36/77
  37. 37. Support de formation Architecture J2EE Version 1.0 Clients web Comme les navigateurs, les clients Java peuvent se connecter au serveur web d’une application J2EE en utilisant le protocole HTTP. Cela est particulièrement utile car c’est souvent le seul protocole disponible pour atteindre le serveur. Dans ce cas, à la différence des navigateurs qui transforment automatiquement les actions de l’utilisateur en requêtes HTTPs, c’est au développeur d’implémenter l’envoi des requêtes. L’un des aspects essentiels est le format des messages employé entre le client Java et le serveur. Le client peut envoyer les données au serveur sous forme de flux binaire par exemple ou envoyer une liste des données séparées par des virgules par exemple : 1,Big and Badder,2,The Dot,4,Invasion of the Dots Ou le client peut utiliser des paires clé-valeur : id=1,title="Big and Badder" id=2,title="The Dot" id=4,title="Invasion of the Dots" Ou utiliser du XML : <movies> <movie> <id>1</id> <title>Big and Badder</title> </movie> <movie> <id>2</id> <title>The Dot</title> </movie> <movie> <id>4</id> <title>Invasion of the Dots</title> </movie> </movies> Les possibilités sont infinies, c’est au développeur de choisir le format des messages en fonction de l’application. L’utilisation de messages binaires consomme peu de bande passante. Exemple de code pour émettre une requête binaire (transmission du nom d’un utilisateur) : Côté client : static final int LOGIN_USER =1; //... HttpConnection c; DataOutputStream out; String username,password; /*Construct the body of the HTTP POST request using out...*/ out.write(LOGIN_USER); out.writeUTF(username); out.writeUTF(password); /*Send the HTTP request...*/ 37/77
  38. 38. Support de formation Architecture J2EE Version 1.0 Servlet chargé de récupérer une requête binaire, côté serveur : public void doPost(HttpServletRequest req, HttpServletResponse resp)throws IOException,ServletException { /*Interpret the request.*/ DataInputStream in = new DataInputStream(req.getInputStream()); int command =in.readInt(); resp.setContentType("application/binary"); DataOutputStream out = new DataOutputStream(resp.getOutputStream()); byte command =in.read(); switch (command){ case LOGIN_USER: String username =in.readUTF(); String password =in.readUTF(); /*Check username and password against user database...*/ } } Les technologies Java pour XML permettent de simplifier l’opération de lecture d’une requête en XML, notamment en utilisant la Java API for XML Parsing (JAXP). D’autres APIs permettent de traiter automatiquement les messages XML, en utilisant le format Simple Object Access Protocol (SOAP). Cette possibilité réduit le temps de développement et les tests de cette partie de l’application. L’utilisation de XML permet de s’adresser à d’autres types de clients comme Flash ou StarOffice qui sont capable de lire certains dialectes de XML . Un client C++ peut aussi utiliser SOAP pour effectuer des appels de procedure distante (remote procedure calls (RPC)) vers une application J2EE. Clients EJB Ils est possible de créer une connection directe entre une application ou une applet Java et un serveur d’EJB, en utilisant des appels Remote Method Invocation (RMI). Cependant ce type de communication n’est pas toujours possible, notamment lorsque les communications passent par Internet (firewalls) et que le protocole IIOP est filtré (ce protocole est utilisé pour le transport des appels RMI). Ce type de client requiert l’installation d’un conteneur EJB côté client sur le poste de l’utilisateur et ce type de client n’est pas encore clairement défini dans les spécifications EJB. Clients de serveurs d’entreprise Habituellement les clients Java ne communiquent pas directement avec les serveurs du système d’information de l’entreprise (bases de données, annuaires LDAP…) car un client mal configuré ou mal programmé pourrait endommager les données contenue dans le système d’information de l’entreprise. De plus ce type de client doit implémenter la logique métier de l’application et cela peut être difficile à implémenter suivant le type de clients. 38/77
  39. 39. Support de formation Architecture J2EE Version 1.0 Gestion des informations d’état Là où les navigateurs demandent de robustes dispositifs côté serveur pour maintenir les informations de session, les clients Java peuvent gérer eux-même les informations de session, car ils disposent de plus de ressources (mémoire). Il est ainsi possible d’implémenter des modes de fonctionnement non-connecté le client Java gardant en cache les informations nécessaires et les transmettant en temps utile au serveur. Cela implique que le client Java embarque une partie de la logique applicative et puisse mettre à jour les données lorsque l’utilisateur (ou un autre utilisateur de l’application) les modifie. Résumé La plateforme J2EE supporte une large gamme de terminaux d’accès et de stratégies de développement des parties clientes de l’application. 39/77
  40. 40. Support de formation Architecture J2EE Version 1.0 .V.2Composants web (web tier) Le serveur web d’une application J2EE (web tier) rend disponible la logique d”une application sur le web. C’est le serveur web qui gère la communication avec les clients webs et qui répond à leurs requêtes. Cette section décrit les technologies utilisées sur le serveur web dans le cadre d’une application J2EE. Les rôles du serveur web Un serveur web traîte des requêtes http. Dans le cadre d’une application J2EE le serveur web (web tier) gère les relations entre les clients web et l’application. Le serveur web produit typiquement du contenu HTML ou XML, bien qu’il puisse générer d’autres types de contenu. L’architecture J2EE préconise d’implémenter la logique métier dans le serveur d’EJB mais il est possible d’implémenter la logique métier directement sur le serveur web. Le serveur web assure lesfonctions suivantes dans une application J2EE : - mise à disposition de la logique métier sur le web : le serveur web gère les relations entre les clients web et la logique métier de l’application - création dynamique de contenu : le serveur web génére dynamiquement du contenu, dans n’importe quel type de format : HTML, images, sons, video,… - présentation et collecte des données : le serveur web transforme les requêtes HTTP PUT et GET dans une forme compréhensible par la couche métier de l’application et présente les résultats - contrôle du flux de navigation : la logique implantée dans le serveur web détermine quel écran de l’application envoyer au client. En effet c’est souvent le serveur web qui adapte la présentation et l’enchaînement des écrans en fonction des capacités du client - maintien des informations d’état : le serveur web dispose d’un mécanisme simple et flexible pour conserver des informations durant toute la durée d’une session utilisateur - support de plusieurs clients : par le biais des types MIME un serveur web peut envoyer de l’information vers n’importe quel type de client et étendre les capacités de publication - implémentation de la logique métier 40/77
  41. 41. Support de formation Architecture J2EE Version 1.0 Technologies utilisées sur le serveur web Technologies “traditionnelles” La génération de contenu dynamique sur le web a d’abord utilisé la technologie Common gateway interface (CGI). Cette technologie permet de déclencher des programmes lors de requêtes HTTP, le résultat du programme étant alors renvoyé comme réponse. L’inconvénient de cette technologie est qu’à chaque appel du CGI, le programme externe doit être rechargé ce qui représente une perte de temps non-négligeable. Les limitations des CGIs ont ensuite été palliées en utilisant des extension propre à chaque serveur web. On parle de NSAPI (pour les serveurs Netscape), de modules d’extension pour le serveur Apache Apache), et d’ISAPI (pour Microsoft Internet Information Server). L’inconvénient de ces techniques étant qu’elles sont spécifiques à chaque serveur et donc non- portables. Technologies web spécifiques à J2EE Les technologies web utilisées sur un serveur J2EE présente l’avantage d’être des solutions portables, sécurisées et standardisées. Une application web est un assemblage de composants de serveurs webs, de contenu et d’inofrmations de configuration. L’environnement d’exécution d’une application web est appelé de contenuer 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 platefrome J2EE définissent une contrat en le conteneur web et les composants webs, 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. Les spécifications J2EE définissent 2 types de composants webs : - 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. 41/77
  42. 42. Support de formation Architecture J2EE Version 1.0 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. Servlets Java 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 Serlvets Java) qu’au niveau binaire (car elles sont compilées en byte-code Java, par définition portable d’une plateforme à l’autre sans modification). En plus de produire du contenu dynamiquement, les servlets supportent plusieurs fonctionnalités applicatives. On peut ainsi déclencher des servlets en fonction d’évenements, 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 noeuds 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 corretment lors du déplcement d’un noued de cluster à l’autre. JavaServer Pages (JSP) La plupart des applications web produisent des pages HTML dynamiquement en modifiant uniquement les champs de données et pas la structure de base de la page. Les JSP sont la technologie la plus appropriée pour ce type de contenu. 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. 42/77
  43. 43. Support de formation Architecture J2EE Version 1.0 Les balises JSP sont de 3 types : - des directives : ce sont des instructions qui contrôlent le comportement du compilateur de pages JSP, et qui sont donc évaluées avant la compilation, - des éléments de scripts : ce sont des blocs d’instructions Java inclus dans la page JSP entre des délimiteurs <% et %>. - des balises personnalisées (custom tags ou custom actions) : elles sont définis par le programmeur et génèrent du contenu dynamique lorsque la page est demandée. 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 quell 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 car elles ressemblent à des documents structurés classiques et sont manipulable dans des environnements d’édition web classiques (Marcomedia Dreamweaver MX par exemple). En général les pages JSP sont compilées en servlets lors du déploiement. Syntaxe XML pour les JSP Les spécifications JSP définissent une syntaxe XML alternative pour les pages JSP. Les pages en syntaxe JSP standard ne sont en effet pas conformes à XML. Les pages JSP écrites en syntaxe XML peuvent être validées avec un schéma XML pour vérifier les erreurs les plus fréquentes. Ce type de syntaxe peut aussi faciliter l'intégration avec les outils de développement. Un fichier JSP ne peut pas mélanger les 2 types de syntaxe. Ecrire les pages JSP en XML n'est pas la même chose que de générer du XML à partir de pages JSP. La syntaxe XML pour JSP n'est qu'une manière différente d'écrire une page JSP, le contenu généré par une page JSP en XML est en tout point identique à celui d'une page JSP traditionnelle équivalente. Balises personnalisées La technologie JSP permet au programmeur de définir leurs propres bibliothèques de balises, ce type de balises est remplacé par du contenu dynamique lorsque la page est envoyée au client. Le contenu dynamique est crée par un gestionnaire de balises, que le programmeur crée et distribue dans un fichier archive de biblitohèque de balises. Le programmeur définit la syntaxe pour chaque balises et implémente le comportement à effectuer pour chaque balise dans la classe de gestion des balises (tag handler class). Les auterus de pages peuvent ensuite importer et utiliser les balises définies dans les bilbiothèques de balises comme s'ils utilisaient des balises traditionnelles. 43/77
  44. 44. Support de formation Architecture J2EE Version 1.0 Les balises personnalisées procurent plusieurs avantages dans la conception d'une application J2EE : - les balises personnalisées sont réutilisables alors que les élements de script ne le sont pas en général - les bibliothèques de balises personnalisées permettent de définir des services de haut niveau portables entre conteneur de JSP - les balises personnalisées facilitent la maintenance d'une application, en évitant de répéter du code de pages en pages. Il suffit de modifier en un endroit le comportement d'une balise pour que toutes les pages contenant la balise soient modifiées - les balises personnalisées permettent aux développeurs de se focaliser sur leur métier de base. Les auteurs de page peuvent utiliser des balises standards et personalisées plutôt que d'avoir à jongler avec des balises et des éléments de scripts qui leurs sont étrangers. - les balises personnalisées offrent aux auteurs de pages un moyen simple d'utiliser la logique métier dans leurs pages - les balises personnalisées permettent une séparation plus claire entre présentation des données et logique métier, ce qui simplifie la maintenance, montre plus clairement l'utilité de chaque composant et permet aux programmeurs et auteurs de pages de travailler plus indépendamment. Bibliothèques de balises standard (stantard tag libraries) Les bibliothèques de balises standard sont des jeux de balises qui fournissent un jeu de fonctionnalités basiques pour les pages JSP. Les balises standards fournissent typiquement des fonctions de : - inclusion de ressources web, - chaînage de requête (request frowarding), - logique conditionnelle, - itérations sur des collections d'objets, - transformations XSLT, - internationnalisation, - gestion des informations d'état, - formulaires HTML. Certaines compagnies ont produit leurs propres bibliothèques de balises profondèment intégrées dans leurs outils de développement et J2EE. D'autres organisations produisent des bibliothèques de balises génériques pour les applications J2EE. C'est le cas par exemple de l'Apache Taglibs, qui est une bibliothèque Open source contenant des douzaines de balises personnalisées. La Java Standard Tag Library (JSTL) fait maintenant partie du Java Community Process (sous la référence JSR-52, A Standard Tag Library for JavaServer Pages). Après sa standardisation, JSTL fournira une riche couche de fonctionnalités de haut niveau et portables pour tous les conteneur web comptabiles JSP. Les librairies standard fournissent souvent la plupart des fonctionnalités requises pour le développement de pages JSP et sont testées et optimisées par la communauté des développeurs. Utiliser une librairie de balises standard de haute qualité permet ainsi de gagner un précieux temps en développement. 44/77
  45. 45. Support de formation Architecture J2EE Version 1.0 Règles de conception des composants web Quand utiliser des servlets ? Les servlets sont la plupart du temps utilisées pour implémenter la logique de l'application et générer des données binaires. Utiliser les servlets pour implémenter des services Les servlets ne sont habituellement pas des composants visuels, à l'exception de certaines qui générent du contenu binaire. En fait les servlets sont surtout utilisées comme un service d'accès aux informations de l'application. Une servlet peut ainsi rendre n'importe quel service (application de modèles, sécurité, personnalisation, contrôle de l'application) et ensuite choisir un composant de présentation (souvent une page JSP) pour lui transmettre la requête et s'occuper de sa présentation. Comme une servlet peut être assimilée à un service, un filtre de servlet peut être assimilé à une extension ou une personnalisation du service fournit par la servlet. Utilisation de servlets comme contrôleurs Les servlets sont la technologie de prédilection pour implémenter un contrôleur sur le tier web, qui déterminera comment traiter une requête et choisira la prochaine vue à afficher. Un contrôleur active les opérations d'une application et prend des décisions, qui sont essentiellement des tâches procédurales bien adaptées à l'intégration dans le code d'une servlet. Les pages JSP ne doivent pas être utilisées comme contrôleur car si l'on mélange les balises et le code du programme, elles deviennent difficiles à lire et à maintenir, particulièrement pour les concepteurs webs, qui ne sont pas des programmeurs. Exemple de Servlet contrôleur public class extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse res)throws...{ String creditCard = req.getParameter("creditCard"); String jspPage ="/process"+creditCard +".jsp"; ServletContext sc =getServletContext(); RequestDispatcher rd =getRequestDispatcher(jspPage); rd.forward(req,res); } } Utiliser des servlets pour générer du contenu binaire Le contenu binaire doit être généré par des servlets. Les servlets qui générent ce type de contenu doivent définir l'entête HTTP Content-Type pour préciser le type MIME du contenu généré. Une servlet écrit ses données binaires dans un objet OutputStream récupéré à partir de l'objet ServletRequest , comme montré dams l'exemple de code suivant. 45/77
  46. 46. Support de formation Architecture J2EE Version 1.0 Exemple de servlet génératrice de contenu binaire public class JpgWriterServlet extends HttpServlet { public void service(HttpServletRequest req, HttpServletResponse rsp)throws...{ rsp.setHeader("Content-type","image/jpg"); OutputStream os =rsp.getOutputStream(); //...now write binary data to the OutputStream... } } Une servlet peut écrire soit sur un objet OutputStream soit sur un objet PrintWriter , mais pas les deux. Une JSP ne peut pas créer du contenu binaire. Eviter les servlets qui générent principalement du texte statique Les servlets composées principalement d'instructions println sont de préférence implémentées sous forme de pages JSP. Il faut utiliser des pages JSP pour créer du contenu textuel et le combiner avec un modèle et des valeurs obtenues dynamiquement. Il est en effet beaucoup plus aisé de maintenir une JSP qu'une servlet pour ce genre de tâches. Exemple de Servlet utilisée à mauvais escient pour génèrer du texte public class PopulateServlet extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res)throws ...{ ... if (dbConnectionClosed){ PrintWriter out =response.getWriter(); out.println("<html>"); out.println("<body bgcolor=white>"); out.println("<font size="+5 "color="red ">Can't connect</font>"); out.println("<br>Confirm your database is running"); out.println("</body></html>"); } } La bonne technique est de détecter l'erreur dans la servlet et de rediriger la requête vers une page JSP si c'est le cas. Ce principe permet de maintenir une bonne spéparation entre les fonctions et la présentation. PopulateServlet.java: public class PopulateServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse res)throws ...{ ... if (dbConnectionClosed){ ServletContext ctx =getServletContext(); ctx.getRequestDispatcher("/db_failed.jsp").forward(req,res); } } db_failed.jsp: <html> <body> <br><font color="red">Unable to Connect</font> <br>Confirm that your database is running </body> <html> 46/77
  47. 47. Support de formation Architecture J2EE Version 1.0 Utiliser les redirections et inclusions à bon escient Une servlet peut utiliser deux méthodes de l'objet RequestDispatcher, forward et include , pour créer une réponse en faisant appel à d'autres composants. Ces deux méthodes sont concues avec des intentions fondamentalement différentes : - RequestDispatcher.forward() délégue totalement le traitement d'une requête à un autre composant. Dans ce cas il faut veiller à ce que le corps de la servlet soit vide sinon une exception et générée, - RequestDispatcher.include() construit une réponse contenant les résultats à partir de plusieurs ressources web Où utiliser les JSP ? Les pages JSP sont habituellement utilisées pour créer du contenu structuré où 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). 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'un 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émentes 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 subsitué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 redirection de requêtes, on préferera 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. 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. 47/77
  48. 48. Support de formation Architecture J2EE Version 1.0 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 emails à envoyer aux clients d'une application. 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. 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 envodé, mais cela à un impact : l'encodage automatique du texte empêche de produire du contenu bianire à partir d'une JSP. 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 et 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 enterprise bean. Ainsi une fine couche de code (le gestionnaire de balises ou tag handler) lie la balise personnalisée à un bean 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 bean), permettant ainsi de conserver la logique et la présentation séparées. 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 : <%@include file="header.jsp"@%> La balise JSP include inclut du contenu dynamique ou statique à chqaue fois que la page est servie et permet donc d'inclure du contenu dynamique à l'exécution (à chaque fois que la page est servie). Exemple : <jsp:include page="/servlets/currentUserInfoServlet"/> 48/77
  49. 49. Support de formation Architecture J2EE Version 1.0 La directive JSP d'inclusion sert plutôt pour réutiliser du contenu et rendre modulaire ses pages webs, tout en réduisant leur taille. Il faut prendre en compte que le fait que 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 redé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'internationnalisation. 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'implementation: 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. 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 blises personnalisée on dispose de composants personnalisés prêt à subir des tests unitaires Eviter de rediriger des requêtes à partir de pages JSP Quand une page JSP appelle RequestDispatcher.forward elle se somporte 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. 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"/> 49/77
  50. 50. Support de formation Architecture J2EE Version 1.0 <%}%> 50/77
  51. 51. Support de formation Architecture J2EE Version 1.0 Résumé 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 webs 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 webs 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. Le serveur web d’une application est une couche de service neutres, 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 individeulles en une vue composée sur l’application. Les servlets sont principalement utilisées pour générer des données binaries et contrôler l’application. Les pages JSP sont principalement utilisées pour créer ducontenu textuel et des référnces à des données externes. Les filtres de servlets peuvent être utilisées pour étendre les fonctionnalités d’une servlet existante, d’un JSP ou d’un autre filtre de servlet. Les états d’une applications 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 aplication web distribuable doivent respecter des contraintes supplémentaires. 51/77

×