Java 2 Enterprise Edition

1. Java 2 Enterprise Edition Ludovic.Maitre@inria.fr 05/09/02

2. Plan • Rappels • Architectures distribuées • Programmation par composant • Principes de J2EE • Topologie(s) • Composants • Container • Serveurs • APIs • Composants • Clients • Web • Métiers • Accès au système d’information d’Entreprise • Sources de données relationnelles • Sources de données non-relationnelles

3. Rappels

4. Architectures distribuées • Les applications à architectures distribuées sont des applications dont les fonctions sont réparties entre plusieurs systèmes. On les appelle aussi architectures multi-tiers. • Dans une architecture distribuée typique les fonctions sont réparties entre un système client (station de travail, terminal,…) et un système serveur (serveur PC, Unix, mainframe…). • Chaque système contient une partie de l’application, les parties manquantes sont exécutées sur les autres systèmes participants à l’application et les informations sont échangées par le réseau

5. Fonctions d’une application • Elles sont généralement réparties en 3 catégories : • fonctions de présentation • interface utilisateur... • fonctions applicatives / orientées métier : • validation des données • modélisation des processus métiers (prise de commande,…) • fonctions de stockage

6. Répartition des fonctions • sur la couche présentation, une application cliente est chargée de l’affichage et de la saisie des données • 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étiersutilisé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,…

7. Motivations pour les serveurs d’application 1/3 • Simplifier le développement des applications à architecture distribuée • Apporter une séparation plus grande entre les 3 couches de l’application (présentation, logique et données). • Permettre au développeur de se concentrer sur la logique de son application, le reste est 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 : • DCOM • EJB.

8. Motivations pour les serveurs d’application 2/3 • Productivité • Fournir des services standards pour : • le développement d'application multi-tiers • le support de plusieurs types de client • Augmenter la productivité permet de mettre plus rapidement sur le marché les applications • Intégration avec l’existant • mettre à la disposition des développeurs des moyens standards d'accès aux données des systèmes déjà existants dans l’entreprise. • Maintenance et sécurité • mettre en place des mécanismes standard pour gérer la sécurité sur tous les systèmes d’une application distribuée • mais peu de possibilités pour mettre en place la sécurité au niveau du client, sauf dans le cas de clients Java.

9. Motivations pour les serveurs d’application 3/3 • Liberté de choix • grande diversité de serveurs J2EE commerciaux ou libres • mécanismes et technologies standards pour la création d'application : cela permet d'utiliser des produits d'éditeurs différents • environnements de développement et serveurs J2EE issus de plusieurs éditeurs. • utilisation de ses propres composants pour les fonctions spécifiques de l'application et de crées par des éditeurs de logiciels pour les fonctions de base. • Réponse adaptée à la demande • les applications supportent la montée en charge sans avoir à être recodées (dans les specs ;-) • mécanismes simples pour répartir la charge entre plusieurs serveurs, sur les différentes couches de l'application

10. Programmation par composants 1/2 • Limites de la programmation usuelle • plus adaptée à la programmation de “petits projets” (programming in the small) • tout est à la charge du programmeur: • la liaison entre les différentes couches de l’application (présentation, application, données), • construction 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

11. Programmation par composants 2/2 • Programmation par composition (ou constructive) • Elle est motivée par la réutilisation des logiciels déjà existants et propose de créer des applications réparties par assemblage de composants logiciels existants. • C’est le concept du “programming in the large” où l’on définit des composants génériques qui sont ensuite réutilisables dans plusieurs applications. • 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: • interfaces • attributs • implèmentation • la description des interactions entre composants (connecteurs) • la description de variables d’environnement (placement, sécurité…)

12. Composants 1/3 • 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, • JavaBeans, • Enterprise Java Beans, • composants CORBA

13. Composants 2/3

14. Composants 3/3 • 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 techniquesen 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,… • l'introspection

15. 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 il 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.

16. Structures d’accueil • Ce 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.

17. Architecture à base de composant

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

19. 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éveloppementclassique 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: • composition et modes de communication, • impédance entre composants et adaptateurs

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

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

22. Principes de J2EE (3/3)

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

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

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

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

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

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

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

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

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

32. Servlets (1/2) • Une servlet est un composant qui étend les fonctionnalités d'un serveur web de manière portable et efficace. • Un serveur web héberge des classes Java servlets qui sont exécutées à l'intérieur du 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.

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

34. JavaServer Pages (1/2) • 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.

35. JavaServer Pages (2/2) • 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)

36. Conteneur decomposants 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).

37. Composants Enterprise JavaBeans (1/3) • 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.

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

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

40. Beans de session (session beans) • Un beans de session fournit un service au client et habituellement n'existe que le temps d'une session cliente. • Un beans de session accompli des opérations de calcul ou d'accès à une base de données pour le client. • Bien qu'un beans de session puisse être transactionnel, il ne dispose pas de mécanismes de reprise sur erreur en cas de 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 beans maintient des informations d'état, c'est au container d'EJB de garder ces informations lorsque le beans est déchargé de la mémoire du serveur. Cependant c'est au beans lui-même de gérer la persistance des données s'il y a lieu.

41. Beans d'entité (entity beans) • Un beans d'entité est un objet persistant qui représente des données stockées dans un entrepôt de données. • Un beans d'entité est identifié par sa clé primaire (primary key). • Un beans 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 beans 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.

42. Bean à message (Message-Driven Beans) • Un beans à message permet à un client asynchrone d'accéder à la logique métier d'un tiers EJB. • Un beans à 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 beans à 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.

43. 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 aux services J2EE et aux APIs de communication.

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

45. API Applet Application Client Web EJB 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 API

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

47. Contrats • L’architecture J2EE définit des contrats associés à un beans. 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.

48. Contrats

49. 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 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 beans. • Il n’y a pas de communication directe entre le client et le beans mais une communication entre le client et le conteneur, ce dernier se chargeant de retransmettre les messages au beans.

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