L’architecture J2EE ludovic.maitre@free.fr.

Présentation au sujet: "L’architecture J2EE ludovic.maitre@free.fr."— Transcription de la présentation:

1 L’architecture J2EE

2 Plan (1/3) Principes de J2EE Composants, conteneurs et services API
Rôles Contrats Le contrat côté client Le contrat du conteneur

3 Plan (2/3) Topologie(s) d'une application J2EE Composants J2EE
Application multitiers Application web Application Business-to-business Composants J2EE Conteneur de composants J2EE Clients J2EE Composants web Composants Enterprise JavaBeans

4 Plan (3/3) Technologies J2EE Remote Method Interface (RMI) JavaBeans
Java Naming and Directory Interface (JNDI) Java DataBase Connectivity (JDBC)

5 Principes de J2EE (1/3) 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.

6 Principes de J2EE (2/3) 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

7 Principes de J2EE (3/3)

8 Rôles J2EE définit différents rôles associés aux différentes parties intervenant dans la production d’une application

9 Contrats (1/2) 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 beans. 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 un 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 beans 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.

10 Contrats (2/2)

11 Le contrat côté client Il précise que le bean doit pouvoir être localisé en utilisant JNDI. Il précise une interface standard d’accès au beans 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 beans: 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.

12 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 beans: Beans de session (session beans) Beans d’entité (entity beans) Les spécifications EJB 2.0 ajoutent un 3ème type de beans, les beans à message (message driven beans).

13 Topologie(s) d'une application J2EE
Schéma général

14 Application multi-tiers

15 Client autonome

16 Client autonome "EJB-centric"

17 Application web

18 Détails application web

19 Application Business-to-business

20 Composants J2EE (1/2) Un composant est une unité logicielle de niveau applicatif. En plus des JavaBeans, qui font partie du J2SE, J2EE supporte les types de composants suivants : applets, application clientes, composants Enterprise JavaBeans (EJB), composants Web, composants adaptateurs de ressource

21 Composants J2EE (2/2) 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'exception des adaptateurs de ressources, les concepteurs et développeurs d'application développent les composants d'une application J2EE. Les adapteurs de ressources et logiciels associés sont en général vendus par les fournisseurs de systèmes d'information de l'entreprise et ensuite déployés sur les serveurs pour accèder aux données.

22 Conteneur de composants J2EE
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'est 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 composants en fonction de la plateforme d'accueil. Un fournisseur d'Enterprise Java Bean 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 passe ) seront configurées. Les sections suivantes donnent un bref apercu des composants, qui seront étudiés plus en détail par la suite.

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

24 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 connues en HTML. Les applets communiquent avec le serveur par HTTP.

25 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, et mettent à sa disposition un moyen d'accéder aux composants métiers de l'application). Les applications clientes ont des interfaces utilisateurs qui peuvent directement interagir avec le tier EJB en utilisant RMI-IIOP. Les 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.

26 Applications clientes Java Web Start
Les applications clientes 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. Elles communiquent avec le serveur en utilisant du XML encapsulé dans du HTTP(S).

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

28 Composants web Un composant web est une entité logicielle qui fournit une réponse à une requête. Les composants web génèrent habituellement l'interface utilisateur d'une application web. La plate-forme J2EE définit deux types de composants web : les servlets et les JavaServer Pages (JSP). La section suivante donne un aperçu de ces composants qui sont détaillés ultérieurement.

29 Servlets (1/3) 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 reçoit une requête du client, elle génère une réponse, éventuellement en utilisant la logique métier contenue dans des EJBs ou en interrogeant directement une base de données. Elle retourne alors une réponse HTML ou XML au demandeur.

30 Servlets (2/3) Un développeur de servlet utilise l'API servlet pour :
Initialiser et finaliser la servlet Accéder à l'environnement de la servlet Recevoir ou rediriger les requêtes et envoyer les réponses Interagir avec d'autres servlets ou composants Maintenir les informations de sessions du client Filtrer avant ou après traitement les requêtes et les réponses Implémenter la sécurité sur le tiers web

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

32 JavaServer Pages (1/3) 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.

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

34 Java Server Pages (3/3) 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.

35 Conteneur de composants web
Les composants web 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).

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

37 Enterprise Java Beans (2/5)
Leurs caractéristiques principales sont les suivantes: les composants EB sont “écrits une fois, exécutable partout” (write once, run anywhere) ces composants sont des composants côtés serveur (analogues aux objets métiers de CORBA) Les EJBs ne sont pas les seuls composants exploités dans une application J2EE mais ils en sont la partie centrale. Les EJBs résident sur le serveur d'EJB. Leurs méthodes sont accessibles aux clients (tiers web, application autonome) en utilisant l'interface distante home du beans. Cette interface décrit les méthodes du 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.

38 Enterprise JavaBeans (3/5)
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.

39 Enterprise JavaBeans (4/5)
Il y a 3 types d'entreprise beans : les beans de sessions, d'entité et de messages. Les beans de session et d'entité comportent 2 interfaces : une interface de composant : l'interface de composant définit les méthodes métiers du bean, 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. Les beans à message n'ont pas d'interfaces home et composant. Les interfaces composant et home d'un bean sont locales ou distantes.

40 Enterprise JavaBeans (5/5)
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 beans distant sont sérialisées pour être transportées sur le réseau, ce qui consomme des ressources. Les interfaces locales impliquent que les clients du beans soient localisés dans la même machine virtuelle que le beans. Dans ce cas les arguments et valeurs de retours échangés sont transmis par référence. Cette méthode est plus performante que la méthode distante. La section suivante donne un aperçu des composants EJB. Ils sont décrits en détail dans la suite du document.

41 Beans de session (session beans)
Un bean de session fournit un service au client 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 cas de plantage du serveur. Les bean de session peuvent être sans état (stateless) ou peuvent maintenir des informations d'état entre les appels de méthode et les transactions (statefull). Si le beans 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 s'il y a lieu.

42 Beans d'entité (entity beans)
Un bean d'entité est un objet persistant qui représente des données stockées dans un 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 sûrement changer une partie du code SQL en changeant de base de données.

43 Bean à message (message-driven beans)
Un bean à message permet à un client asynchrone d'accéder à la logique métier d'un tiers EJB. Un bean à message permet à des clients asynchrones d'accéder à la logique métier du tiers EJB. 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 interfaces composant ou home. Ils ne maintiennent pas non plus d'information d'état sur le client.

44 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 auw beans qu’il héberge des services de : Transaction, Persistance, Accès aux services J2EE et aux APIs de communication

45 Technologies J2EE (1/4) La plate-forme J2EE comme la plate-forme J2SE incluent un grand nombre de bibliothèques de code (API) prédéfinies pour les fonctions de base d'une application. Les conteneurs fournissent aux composants un accès aux APIs du J2SE, ce qui inclut l'accès aux APIs Java IDL et JDBC 2.0 core. Le tableau suivant résume les APIs accessibles en fonction du type de conteneur.

46 Technologies J2EE (2/4) API Applet Application Client Web EJB
JDBC 2.0 Extension N Y JTA 1.0 JNDI 1.2 Servlet 2.3 JSP 1.2 EJB 2.0 Y1 Y2 RMI-IIOP 1.0 JMS 1.0 JavaMail 1.2 JAF 1.0 JAXP 1.1 JAAS 1.0 Connector 1.0

47 Technologies J2EE (3/4)

48 Technologies J2EE (4/4) L'architecture J2EE Connector (JCA) 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 Java Database Connectivity (JDBC) est utilisée pour accéder à des données relationnelles à partir de programmes Java La Java Transaction API (JTA) est utilisée pour gérer et coordonner les transactions entre un ensemble hétérogène de systèmes d'information d'entreprise. L'API Java Naming and Directory Interface (JNDI) est utilisée pour accéder aux services de nommage et d'annuaire de l'entreprise. L'API Java Message Service (JMS) est utilisée pour émettre et recevoir des messages via les systèmes de messagerie d'entreprise comme IBM MQ Series ou TIBCO Rendezvous. Dans l'architecture J2EE les Message Driven Beans fournissent une approche à base de composant pour encapsuler les fonctionnalités de messagerie d’entreprise. La JavaMail API est utilisée pour émettre et recevoir des mails. Java IDL est utilisée pour appeler des services CORBA L'API Java pour XML (JAXP) est utilisée pour l'intégration avec les systèmes et applications existants et pour implémenter les web services dans la plate-forme J2EE. JAX-RPC est utilisé pour les services web

49 Remote 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 beans de session et l'activer sur le serveur distant.

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

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

52 Java 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 objet InitialContext est crée par le conteneur lorsqu'une web application est déployée. Cet objet est accessible par les composants, en lecture seulement. 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.

53 Exemple d’utilisation de JNDI
Dans Tomcat, les 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();

54 Java 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ées. L’utilisation de JDBC est faite soit par le conteneur d’application (Container Managed Persistence) soit directement dans le beans (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)

55 Exemple 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.”); ...... }