INTÉGRITÉ D OBJETS PERSISTANTS JAVA

Transcription

1 HEG Genève Laboratoire de Technologies Objet Campus de Battelle Bâtiment F Route de Drize 7 CH-1227 Genève Tél : Fax : INTÉGRITÉ D OBJETS PERSISTANTS JAVA RAPPORT DÉTAILLÉ Projet déposé dans le cadre du programme de la réserve stratégique de la HES-SO Mars 2005 Sous la direction de Peter DAEHNE, professeur HES

2 TABLE DES MATIÈRES 1 Introduction Contexte Problème Objectifs Persistance des données Modèle relationnel Modèle objet Conception du logiciel Anomalie d impédance Solutions Mapping Problèmes Choix de la représentation Technologies de persistance existantes Enterprise JavaBeans (EJB) Architecture Structure générale d un objet métier distribué Infrastructure et EJB Les différents types de composants serveur Architecture d un bean entité Instances distantes Autres types de bean Que fait le développeur? Déploiement Le rôle du conteneur Les outils En conclusion Java Data Objects (JDO) Architecture Objets persistants Interfaces de programmation Principe de fonctionnement Méta données L enhancement

3 3.2.7 Que fait le développeur Déploiement Les outils En conclusion Autres technologies Intégrité Intégrité statique Intégrité comportementale Problème de l implantation Méthodologie Choix de la source Règles de correspondance retenues Expression de la sémantique Technologies de persistance existantes OCL Types de contraintes Contexte d une contrainte Exemples Problème des contraintes non satisfaites Génération de code Prototype Outil de modélisation Cible base de données Génération Implantation Une solution alternative Conclusion Bibliographie

4 1 INTRODUCTION 1.1 Contexte La conception de l architecture du système d information informatisé d une entreprise moderne est en général une opération complexe au cours de laquelle il faut prendre en compte les nombreux aspects du métier exercé par cette entreprise ainsi que les attentes des acteurs économiques 1 avec lesquels celle-ci est en relation. En raison de la généralisation des échanges d informations électroniques entre les acteurs économiques, de l avènement de l Internet et de la banalisation des transactions effectuées en ligne ou de façon nomade [Tra03] cette architecture est presque forcément multi-tiers 2. Un élément central de cette architecture est la base de données mémorisant les informations métier de l entreprise, informations vitales pour le fonctionnement de cette dernière. Notons que cette base de données peut éventuellement, pour diverses raisons d efficacité, être distribuée 3. De nos jours, l analyse et la conception de logiciel s effectuent en employant l approche objet [Mey88] ; de nouvelles méthodologies de développement ainsi que des langages adaptés à cette approche ont fait leur apparition dès le début des années Les méthodologies actuellement les plus populaires sont toutes plus ou moins dérivées du processus unifié 4 ; l un des langages les plus employés pour la réalisation effective du logiciel conçu est Java [Fla99]. Ces techniques se sont imposées principalement en raison de la puissance de modélisation du réel que fournit le modèle objet et de l expressivité des langages de programmation orientés objet. Les logiciels de gestion de bases de données ont évidemment suivi cette évolution. Le modèle relationnel [Cod70] a évolué vers le modèle objet-relationnel [Sou99] qui est une extension du premier intégrant les concepts du paradigme objet 5. Ces logiciels sont hybrides en ce sens qu ils font cohabiter les deux concepts. Il est en effet essentiel de prendre en considération le fait que des centaines de milliers d'applications métier en production de nos jours ont été conçues dans le cadre du modèle relationnel. De même, il est indispensable que de nouvelles applications métier puissent être développées en mettant en œuvre les techniques de construction de logiciel les plus modernes. Enfin, il est fondamental que des logiciels métier issus des deux processus de développement puissent accéder aux mêmes informations sans redondance de la mémorisation des données d entreprise [Dae01]. 1 Filiales, partenaires, fournisseurs, clients, administrations, particuliers, etc. 2 Pour mémoire, notons que les principaux tier sont : la présentation des informations (sous forme de pages WEB ou d écrans interactifs), la logique applicative et la logique métier, la gestion des données. 3 Dans la mesure où la distribution de la base de données est implantée de façon transparente pour ses clients ce qui est en général le cas dans un système construit selon les règles de l art, cette distribution n a aucune influence sur notre propos. 4 Le processus unifié [Jac99] est un modèle de développement générique, basé sur le langage UML [Rum04]. 5 Ce sont : l abstraction des données, l encapsulation, le masquage d information [Par72], l héritage et la liaison dynamique. 4

5 1.2 Problème À l issue d un processus d analyse et de conception orienté objet, les ingénieurs responsables de l implantation du logiciel se trouvent en présence d un ensemble de classes produites (automatiquement ou non) par ce processus. Au cours de ce processus, ils mettent en évidence un sous-ensemble éventuellement vide de ces classes dont certaines instances devront être persistantes, c est-à-dire survivre à l exécution de l application. Le langage Java est l un des langages les plus employés actuellement pour implanter effectivement des classes résultant d un processus d analyse et de conception orienté objet 6. La plupart des outils implantant les méthodologies de conception basées sur le processus unifié génèrent entre autres du code Java ; ils permettent également, pour les classes persistantes, de construire plus ou moins automatiquement soit un modèle objet pour une base de données orientée objet, soit un modèle relationnel pour une base de données relationnelle. Si la tendance est la croissance du nombre de projets développés en Java [Lab04], ce sont surtout les projets nouvellement initiés qui sont concernés. Parallèlement, les entreprises continuent de faire évoluer et de maintenir des projets existants à l aide des outils plus conventionnels avec lesquels ils ont été réalisés. Tous ces projets s appuient sur les données d entreprise mémorisées dans une base de données relationnelle et/ou relationnelle-objet 7 ; or, il est vital qu aucune application métier (en production ou future) ayant accès à ces informations n en altère l intégrité. 1.3 Objectifs En premier lieu, nous étudierons le problème de la persistance des données en toutes généralité ainsi que les problèmes spécifiques qui se posent lorsqu on s intéresse en particulier à la persistance d objets métiers issus d un processus d analyse et de conception orientée objet. Nous proposerons des solutions adaptées à ce contexte. Dans un second temps, nous examinerons les principales technologies de persistance disponibles sur le marché et leurs caractéristiques. Nous verrons quels sont leurs forces et leurs faiblesses ainsi que leur adaptation aux cas particuliers qui nous intéressent et qui font l objet de cette étude. Ensuite, nous nous intéresserons aux divers aspects de l intégrité des objets persistants, en particulier à celui de la définition de l intégrité comportementale et de ses implications. Puis, nous allons concevoir et décrire un processus générique de définition des contraintes d intégrité pour les objets Java persistants de telle sorte que celles-ci soient vérifiées automatiquement en toutes circonstances, en particulier lorsque des applications tierces accèdent aux mêmes informations. 6 Le nombre de projets développés en Java est en forte croissance ces dernières années, contrairement à d autres langages comme le montre [Lab04] basé sur des statistiques de SOURCEFORGE.net ( 7 On peut noter que ce secteur est également en forte croissance [Gar03] et donc, que les bases de données relationnelles et relationnelles-objet continueront à constituer la référence en matière de mémorisation de données métier. 5

6 Le support de mémorisation des objets sera une base de données relationnelleobjet 8. Nous comparerons notre processus aux solutions existant sur le marché ; nous aurons ainsi l occasion de montrer quelles en sont les principales innovations. Nous élaborerons un cahier des charges spécifiant les caractéristiques d un prototype automatisant le processus décrit. Cet outil permettra d associer de façon permanente les contraintes d intégrité aux objets persistants. Puis, nous développerons un prototype implantant effectivement le processus. Nous verrons alors que l intégrité de ces données ne peut plus être mise à mal, même par une application tentant d y accéder sans en respecter la sémantique. Enfin, nous examinerons comment notre processus peut être mis en œuvre dans le cadre d une petite ou moyenne entreprise, sans qu il soit nécessaire de déployer des technologies lourdes, ni de disposer de compétences humaines spécialisées dans la gestion spécifique de ce problème. Nous placerons la solution proposée en perspective et étudierons les développements qui pourraient être envisagés. 8 La représentation que nous définissons est indépendante du choix du logiciel de gestion de base de données, pour autant que celui-ci soit muni d une implantation standard de PL/SQL ou équivalent. Les principaux acteurs payants du marché (Oracle [Ora05a], DB2 [DB205], SQL-Server [SQL05]) ainsi que les fournisseurs du domaine open source (MySQL [MyS05]) satisfont en général ces contraintes. 6

7 2 PERSISTANCE DES DONNÉES Lorsque des données survivent à l exécution des programmes qui les créent et/ou les traitent, on dit qu elles sont persistantes. C est le cas de toutes les informations métier gérées par le système d information informatisé de l entreprise. Bien que cette persistance puisse théoriquement être assurée en mémorisant les informations dans de simples fichiers, dès les années 1970 des logiciels spécialisés dans cette tâche voient le jour. Il s agit en effet, non seulement de mémoriser des informations de façon durable, mais également de représenter les associations qui les lient. Des applications différentes doivent pouvoir partager ces informations, y accéder de manière simultanée, rapide et sûre. Le concept de transaction 9 permet de garantir l intégrité des données. De nos jours, cette persistance est assurée par des systèmes de gestion de base de données relationnelles (SGBDR) ; cette technologie a encore un bel avenir devant elle comme le montre [Gar03]. 2.1 Modèle relationnel Les concepts mis en œuvre dans le modèle relationnel sont fondés sur une théorie mathématique directement issue de l algèbre relationnelle, de la théorie des ensembles et de la logique formelle. Ces concepts ont été définis et formalisés en 1970 par E. Codd [Cod70]. Une relation est une structure de données tabulaire. Elle est composée d attributs ; chaque attribut prend sa valeur dans un domaine. Une relation est donc un sous-ensemble du produit cartésien des domaines des attributs. Des opérateurs algébriques permettent d effectuer des opérations 10 entre les relations. Les contraintes d intégrité sont des assertions s appliquant à une ou plusieurs relations et qui doivent toujours être vérifiées. Un processus de normalisation permet de construire des modèles de données sans redondance d information. Un SGBDR est un logiciel spécialisé qui implante ces concepts Modèle objet Lorsqu un ingénieur en électronique conçoit un nouveau circuit imprimé, il ne commence pas par extraire d un tas de sable le silicium nécessaire à sa fabrication. Il construit un système en assemblant des composants existants, chacun étant chargé 9 Une transaction est un ensemble d opérations atomique (toutes les opérations sont exécutées ou aucune ne l est), cohérent (la base de données passe d un état cohérent à l autre), isolé (aucun effet n est visible tant que la transaction n est pas terminée) et durable (les effets des transactions terminées sont conservés, même si le système tombe en panne) acronyme : ACID. 10 Les principales opérations sont ensemblistes (union, différence, produit cartésien) et relationnelles (projection, restriction) ; on peut en dériver d autres opérations telles que l intersection ou la division. 11 En plus de la gestion du partage d information et des transactions. 7

8 d une fonction particulière et fournissant un ensemble de services à travers une interface définie. Les concepts du modèle objet sont issus de l observation du fait que, contrairement au concepteur de matériel électronique, l ingénieur informaticien repart toujours plus ou moins de l équivalent du tas de sable lorsqu il conçoit un nouveau logiciel 12. Dans le modèle objet, le monde réel est modélisé en entités regroupant données et opérations, puis en factorisant les propriétés communes à ces entités en classes 13. Une classe est une description de type. Celle-ci est composée d attributs 14 et de méthodes 15. Un objet est une instance 16 d une classe. Les attribut sont les données représentant l état de l objet. Les méthode sont les actions que l objet est à même de réaliser ; elles caractérisent son comportement et permettent à l objet d agir sur d autres objets ou de réagir à des sollicitations extérieures 17. Une classe peut être étendue par héritage définissant ainsi une nouvelle classe compatible avec la classe de base. La nouvelle classe ainsi créée, également appelée classe dérivée, est munie de toutes les caractéristiques de la classe de base ainsi que de méthodes et d attributs supplémentaires ; certaines méthodes héritées peuvent être redéfinies pour spécifier un nouveau comportement. Lors de l exécution, les méthodes sont activées par liaison dynamique 18. Enfin, tout objet possède une identité qui permet de le distinguer des autres objets, indépendamment de son état. Un système de gestion de base de données orienté objet (SGBDOO) implante directement ces concepts Conception du logiciel La conception de logiciel mettant en œuvre le modèle relationnel repose sur le principe de la séparation de l analyse des données et de l analyse des traitements 20. Dans la phase d analyse des données, on s applique à modéliser les informations du système indépendamment des traitements que ces données vont éventuellement subir. 12 Les solutions à des problèmes déjà résolus par les milliers de programmeurs qui les ont précédés sont continuellement reprogrammées en tant que parties de logiciels plus généraux. 13 Les premiers outils implantant ces concepts apparaissent dès 1967 dans le milieu académique ; mais ce sont les langages Smalltalk dès 1976 et surtout C ++ en 1984 ainsi que l avènement des modèles de développement basés sur cette approche qui vont consacrer l emploi de la technologie objet dans le développement de logiciels d entreprise. 14 Appelés également données membres. 15 Appelées également fonctions membres. 16 Variable du type de la classe. 17 Les méthodes sont étroitement liées aux attributs, leurs actions pouvant modifier ou dépendre des valeurs de ceux-ci. 18 La compatibilité d une classe dérivée avec sa classe de base a pour conséquence qu une référence à une instance est caractérisée par deux types éventuellement distincts : le type statique qui est celui de sa déclaration dans le texte du programme et le type dynamique qui est celui de l instance effectivement référencée. Lorsqu une méthode est invoquée, le choix de la méthode effectivement appelée est fait à l exécution en fonction du type dynamique de la référence par liaison dynamique. 19 Ces systèmes ne sont pas très répandus (voir [Gar03]) bien que des standards [Cat97] aient été définis pour les spécifier. Par contre, les principaux acteurs du marché des SGBDR intègrent les concepts objets (voir [Sou99]). 20 Comme par exemple la méthode Merise [Tar91]. 8

9 Dans la phase d analyse de traitements, on s intéresse à la modélisation des actions que l application devra être capable d accomplir ; les fonctions du logiciel sont décrites globalement relativement aux données modélisées précédemment. Les traitements modélisés permettent de valider le fait que les informations qu ils nécessitent ont bien été définies lors de la première phase ; aucun lien explicite n est établi entre les données et les traitements qui les affectent 21. Dans la conception de logiciel orientée objet, l attention est centrée sur les données et leurs comportements [Mey88]. Les données et les traitements sont regroupés en entités modélisées par des classes. Une classe définit une catégorie de données par les services que cette catégorie est capable de fournir. La phase d analyse consiste en l identification des diverses entités concernées par l application qu on est en train de concevoir. Lors de cette identification, on inventorie aussi bien les données que les traitements que celles-ci vont subir. Les éléments communs des entités identifiées sont ensuite factorisés, produisant des hiérarchies de classes modélisant les objets du domaine de gestion couvert par l application Anomalie d impédance Le paradigme objet est fondé sur des principes de génie logiciel éprouvés alors que le paradigme relationnel est fondé sur une théorie mathématique. En raison du fossé conceptuel existant entre les deux paradigmes, les deux technologies ne cohabitent pas sans problèmes 23. On dit qu il y a anomalie d impédance 24 lorsqu une application dispose d un modèle de données différent de celui de la base de données. Cette différence peut être forte ou faible ; elle dépend de la méthode de conception mise en oeuvre d une part, de la cible base de données d autre part. Lorsque la conception s effectue en mettant en œuvre le modèle relationnel, on obtient, après normalisation 25, un modèle de données qu il est possible d implanter directement dans une base de données relationnelle. L anomalie d impédance est donc, dans ce cas, faible, voire inexistante. À l issue du processus de conception mettant en œuvre le modèle objet, les classes obtenues sont liées par des associations qui donneront lieu, en cours d exécution, à un graphe complexe d objets reliés entre eux par des références. Il n est en général pas possible de représenter directement un tel graphe sous la forme de relations. Si la base de données cible est une base de données relationnelle, l anomalie d impédance sera donc très forte. 21 L approche est descendante, par raffinements successifs (top-down) ; la conception s effectue du général au particulier. 22 L approche est ascendante (bottom-up) ; la conception s effectue du particulier au général. 23 Voir [Dae01]. 24 Impedance mismatch. 25 Le processus de normalisation permet d éliminer algorithmiquement les redondances d information tout en préservant la cohérence des données mémorisées dans la base de données. Ce processus réduit les sources d erreur mais grève le coût d interrogation de la base de données en multipliant le nombre de jointures nécessaires à la satisfaction des requêtes. 9

10 À titre d illustration, considérons le modèle physique relationnel de la figure 2.1 et le modèle objet de la figure 2.2. Fig. 2.1 : Modèle physique relationnel. Fig. 2.2 : Modèle objet. Les deux diagrammes modélisent, dans leur formalisme propre, le fait qu un étudiant suit un certain nombre de cours. On peut identifier les similarités suivantes : Les deux diagrammes expriment de la structure. Le modèle physique relationnel est constitué de trois tables reliées par des associations ; le modèle objet représente deux classes et l association qui les relie. Les deux diagrammes représentent des informations. Le modèle physique relationnel les représente sous la forme de colonnes des tables et le modèle objet les représente sous la forme d attributs des classes. Le diagramme objet exprime du comportement. On ne représente pas de comportement dans le modèle physique relationnel bien que du comportement puisse être associé à une table sous la forme de triggers 26. Bien que la notation soit finalement similaire et l expressivité semblable, la distance conceptuelle qui sépare les deux modèles est grande. Elle dépend de la méthode de conception 27 dont le modèle est issu. En mettant en œuvre le modèle relationnel, on 26 Le comportement ne peut pas être spécifié aussi librement dans le modèle relationnel que dans le modèle objet. Les seuls comportements qu on peut définir sont associés à des événements de changement d état de la base de données (création, modification, suppression d informations). 27 Voir 2.3 Conception du logiciel. 10

11 ne détermine aucun chemin d accès 28 alors qu en employant méthodologie objet, le sens de navigation des associations devra être défini 29. Pour mesurer l importance de cette différence, il suffit de considérer l approche choisie pour accéder aux informations : dans le cadre du modèle objet, on parcourt le graphe d objets en suivant les références implantant les associations alors que dans le cadre du modèle relationnel, on effectue des opérations algébriques avec des lignes de tables. 2.5 Solutions Dans le contexte objet, on pourrait avoir une anomalie d impédance faible en employant une base de donnée orientée objet. Néanmoins, principalement pour des raisons stratégiques 30, le concepteur d une application mettant en œuvre le modèle objet sera amené à envisager la gestion de la persistance de ses objets au moyen d une base de données relationnelle. Dans le but de réduire l importance de cette anomalie d impédance entre le modèle objet et la base de données 31, les principaux éditeurs de systèmes de gestion de base de données relationnelles ont fait évoluer leurs produits en tentant de réunir les concepts présents dans les deux modèles 32. Cette réunion est réalisée en étendant le modèle relationnel pour lui conférer un certain nombre de qualités reconnues du modèle objet ; la totalité des fonctions d un SGBDR classique est préservée et les concepts qui font le succès de l approche objet y sont intégrés 33. Un dernier aspect qu il est intéressant de relever est qu outre l anomalie d impédance technologique présentée ci-dessus, on identifie une anomalie d impédance culturelle entre la communauté des développeurs orientés objet et celle des développeurs orientés données 34. Certains développeurs objet considèrent que la technologie relationnelle n est simplement pas adaptée à la représentation de leurs concepts et des développeurs orientés données considèrent que le modèle de composants objets doit être asservi à leurs modèles de données. 28 À l issue de l analyse, tous les accès restent possibles. 29 Dans la figure 2.2, le sens de l association entre Etudiant et Cour sera défini dans un raffinement ultérieur du modèle. Dans le cas présent, le sens de navigation sera défini de l Etudiant vers les Cours qu il suit. 30 L entreprise possède de nombreuses applications existantes développées selon le modèle relationnel, les données métier traitées par l application développée en mettant en œuvre le modèle objet doivent être partagées par d autres applications de l entreprise, etc. 31 La motivation est bien sûr principalement commerciale ; il s agit de préserver l ensemble des acquis du modèle relationnel de manière à ne pas se couper de l énorme segment de marché occupé par cette technologie (voir [Gar03]) tout en prenant le virage de la modernité en proposant des standards en vogue dans la conception d applications distribuées et accessibles par le Web. 32 Les fondements théoriques de cette technologie ont été définis par M. Stonebaker [Sto91] dans le développement du projet Postgres. Finalement, la publication du troisième manifeste par C. Date et H. Darwen [Dat98] et la normalisation de SQL en 1999 [SQL99] stabilisent les concepts de la technologie implantée par les SGBDRO modernes. 33 Ces systèmes sont appelés systèmes de gestion de base de données relationnelle-objet (SGBDRO). 34 Voir à ce propos (Crossing the Object-Data divide de S. Ambler, 2000). 11

12 2.6 Mapping Dans le contexte faisant l objet de cette étude, le modèle de développement concerné est le modèle objet et la cible base de données est une base de données relationnelle-objet. L anomalie d impédance est donc relativement faible. Cette différence entre les paradigmes exige tout de même de mettre en place un système de mise en correspondance des deux modèles. Ce système de mise en correspondance est appelé mapping ou encore mapping relationnel-objet. Il permet de représenter des graphes d objets et des valeurs complexes dans la base de données. Notons que pour implanter cette mise en correspondance, il est nécessaire d ajouter du code aux objets métier de l application 35, code dont l exécution impactera évidemment les performances de l application. Bien que ce fait puisse fonder l argumentation d un puriste en faveur d une solution tout objet 36, les besoins réels du marché 37 nous amènent à considérer la réalité où technologies objet et relationnelle cohabitent nécessairement Problèmes Il convient tout d abord de définir une stratégie effective de persistance des objets métier. Il est nécessaire de mémoriser de façon permanente tant les valeurs des attributs des objets individuels que les associations qui existent entre objets, héritage inclus. Les objets métier doivent ensuite être implantés dans la représentation choisie. Enfin, la performance de l implantation choisie doit être mesurée, des optimisations de représentation éventuellement effectuées (adjonction d index, attributs calculés, etc.) Choix de la représentation Il existe de nombreuses solutions commerciales ou open source implantant automatiquement une stratégie de persistance 38. Comme l un de nos objectifs principaux est la définition d une méthodologie de spécification de contraintes d intégrité comportementale, nous avons choisi les outils de mise en œuvre les plus répandus du marché. De toutes manières, notre propos ne dépend pas directement de ce choix. Nous avons donc retenu une solution de mapping simple et robuste ; celle-ci ne permet pas au développeur de personnaliser la mise en correspondance. Le SGBDRO que nous avons choisi est Oracle 9i 39 car c est l un des acteurs principaux du marché 35 En général, ce code n est pas directement intégré au code de l objet métier ; il se présente sous la forme d une couche logicielle chargée de la gestion de l interface entre les deux mondes. 36 Modèle objet et SGBDOO (Système de bases de données orienté objet). 37 Voir [Gar03]. 38 Voir à ce propos le chapitre suivant. 39 Voir [Ora05a] 12

13 des bases de données 40 et parce qu une suite d outils très complète et compatible avec Java l accompagne 41. Nous pourrons alors utiliser l outil JPublisher [Men04] pour automatiser le processus de mapping et nous concentrer sur le problème de la définition et de la génération des règles d intégrité. 40 On considère qu Oracle occupe environ un tiers du marché des bases de données. Les rares discussions portent sur quelques pourcents (voir [Won02] par exemple). 41 Oracle dispose de sa propre JVM (Java Virtual Machine) et le langage Java peut être employé, dans certaines conditions, pour définir des triggers et des procédures stockées. 13

14 3 TECHNOLOGIES DE PERSISTANCE EXISTANTES L architecture d un système d information informatisé moderne est organisée en plusieurs couches fonctionnelles indépendantes. La figure 3.1 montre un exemple d une architecture possible. Fig. 3.1 : Architecture logicielle multi niveaux (n-tiers). Le rôle de chaque couche est d abstraire un concept du système sous forme de services qu elle est capable de rendre aux couches de même niveau ou de niveau directement adjacent. La couche Client est chargée de l interaction avec l utilisateur final du système 42. La Couche de Présentation est responsable 43 de la génération des pages Web à partir des informations qu elle obtient de la Couche Services. La couche Objets Métiers s occupe de la gestion des données d entreprise ; elle implante également la logique business de l application. La couche Bases de Données représente l ensemble des dispositifs de stockage dont l application a besoin pour mener à bien sa tâche 44. Reste enfin la Couche d Accès aux Données qui est chargée de la gestion de l interaction entre les dispositifs de stockage et la paire Couche Services couche Objets Métier. Dans une application développée selon une méthodologie objet et employant une base de données relationnelle pour la gestion de la persistance, c est cette couche qui est chargée d interfacer le monde objet le côté de l application et le monde relationnel le côté de la base de données. C est elle qui implante, entre autres, la stratégie de persistance des objets métier. Les principaux avantages d une architecture en couches indépendantes comme celle qui vient d être décrite sont de permettre le développement des composants par des équipes différentes à partir de leurs spécifications ainsi que de simplifier les 42 Cette interaction peut avoir lieu par l intermédiaire d un navigateur Internet (browser) ; on parle alors de client léger. Elle peut également avoir lieu par l intermédiaire d une application déployée sur le poste de travail de l utilisateur, on parle alors de client lourd. 43 Le client lourd n emploie pas les services de la couche de présentation ; s occupant lui-même de la présentation des informations, il s adresse directement à la Couche Services. 44 On y trouve bien sûr des SGBD, mais aussi des progiciels de gestion ou encore des services d annuaires, etc. 14

15 opérations de maintenance évolutive et corrective. L application obtenue est également plus robuste. Les solutions logicielles du marché que nous allons décrire implantent toutes une Couche d Accès aux Données plus ou moins générique, plus ou moins paramétrable. Certaines automatisent également une partie de la Couche Services. Étant donné le contexte dans lequel nous nous plaçons, nous nous sommes bien sûr limités aux outils qui s interfacent avec Java du côté de l application. Ces frameworks de persistance sont bien plus que de simples wrappers 45 de tables fournissant des primitives d accès aux colonnes de celles-ci. La stratégie de persistance ainsi que les outils associés offerts varient fortement d un framework à l autre. La palette des outils du marché s étend du simple traducteur modèle objet modèle relationnel déclenché en batch sur la base de règles de traduction plus ou moins spécifiables à des outils couvrant une partie du cycle de développement et permettant de modéliser un système en UML ou en XML. Les outils les plus complets permettent, en général via une interface graphique conviviale, de générer les objets métiers d une part, la structure de la base de données relationnelle d autre part. En général, le mapping proposé est configurable. Parmi les services fournis automatiquement on peut encore citer la prise en charge de concepts avancés tels que la gestion d un cache d objets, l accès concurrent, les transactions distribuées, l accès aux informations au moyen d un langage de requête objet, etc. Le système devrait en outre être le plus indépendant possible du moteur de bases de données ; les applications construites seront ainsi très faiblement couplées au SGBDR déployé. 3.1 Enterprise JavaBeans (EJB) Les Enterprise JavaBeans est un modèle de composants côté serveur 46 qui s intègre à l architecture J2EE, la solution complète et portable de Sun Microsystems. Cette technologie, introduite comme un avant-projet à la fin de 1997, voit sa spécification stabilisée avec la version 1.1 dès 1999 [Ejb99] 47 ; celle-ci définit l architecture dans les termes suivants : L architecture des Enterprise JavaBeans est une architecture de composants pour le développement et le déploiement d applications d entreprise distribuées basées sur des composants. Les applications écrites en utilisant l architecture des Enterprise JavaBeans sont évolutives, transactionnelles et sûres. Ces applications peuvent être écrites une fois, puis déployées sur toute plate-forme serveur qui supporte la spécification des Enterprise JavaBeans. 45 Classe encapsulant une table de la base de données et les instructions SQL nécessaires à sa gestion. Mise en œuvre du Design Pattern Adapter décrit dans [Gam98]. 46 Attention, ces composants n ont rien à voir avec les JavaBeans qui sont des composants côté client. 47 La version actuelle est la version 2.0 [Ejb01]. 15

16 On peut en donner une définition un peu plus succincte [Mon01] : Les Enterprise JavaBeans sont un modèle de composants côté serveur standard pour des moniteurs de composants transactionnels 48 (CTM). Un CTM est un serveur d applications fournissant un environnement complet pour les composants côté serveur en prenant en charge automatiquement la concurrence, les transactions, la distribution des objets, l équilibrage de charge, la sécurité et la gestion des ressources Architecture Les services offerts par les EJB s intègrent à la solution complète J2EE ainsi : Couche d'accès Couche Client Couche de présentation Objets Métier aux données Bases de données Web container EJB container JSP Servlet EJB JDBC Browser JSP SGBDR(O) Servlet Browser HTML Connector WebService client Servlet EJB Application Client Container EJB Legacy application RMI / IIOP client Connector JMS client MDB JMS Provider Client Serveur Fig. 3.2 : Architecture de J2EE 49. SI Le conteneur EJB est le serveur d application. Les EJB sont les objets distribués. Le protocole d objets distribués est construit de telle sorte qu un objet présent sur un ordinateur soit vu comme résidant sur un ordinateur différent 50. Un EJB est principalement constitué de trois parties : l objet métier, le squelette et le stub. L objet métier réside sur le serveur. Il s agit d une instance d un objet qui modélise l état et la logique d un concept du monde réel. À chaque classe d objet 48 Component Transaction Moniteur (CTM) : technologie fournissant une plate-forme d objets distribués robuste et puissante. 49 D après Developper s Guide Sun One Application Server 7 [Sun02]. 50 C est bien sûr le cas de tout protocole à objets distribués. 16

17 métier correspondent une classe stub et une classe squelette spécifiques. Le stub et le squelette ont pour charge de montrer l objet métier, qui vit dans le conteneur EJB, comme s il s exécutait localement sur la machine cliente ou le conteneur Web. Cela se fait au travers du protocole d invocation de méthode distante (RMI 51 ) qui est utilisé pour communiquer les invocations de méthodes sur un réseau Structure générale d un objet métier distribué La logique métier est modélisée par une interface publique 52. L objet métier est une implantation concrète de cette interface. Chaque instance de l objet métier dans le conteneur d EJB est enveloppée par une instance de sa classe squelette. Le squelette attend les requêtes provenant du stub. Le stub réside sur la machine du client et agit comme un représentant de l objet métier pour le client (il implante l interface publique). Il communique les requêtes du client au squelette et retourne les réponses du squelette au client. Fig. 3.3 : Structure d un objet métier distribué diagramme de classes. Le client peut obtenir des instances du stub et en invoquer les méthodes. Le stub route l invocation via RMI au squelette résidant sur le serveur qui délègue l invocation de celle-ci à l instance concrète qu il encapsule. Le résultat suit le chemin inverse. Le résultat retourné par la méthode de l instance concrète est routé par le squelette via RMI au stub qui retourne la valeur au client. Le diagramme de séquence de la figure 3.4 illustre ce comportement. 51 RMI = Remote Method Invocation. 52 Ici : XXX. 17

18 Fig. 3.4 : Invocation d une méthode d un objet distribué diagramme de séquence. Comme on peut l observer, le RMI est au cœur du système à objets distribués et sa fonction est de rendre les objets transparents à leur localisation. Cela signifie que la localisation réelle de l objet serveur est inconnue et n est pas importante pour le client qui l utilise. Le couplage entre les clients et l objet métier est faible. Remarquons enfin qu il faudra mettre en place une structure et un mécanisme analogue pour une classe associée à l objet métier chargé d en gérer les instances (création, références distantes, etc.) Infrastructure et EJB Le serveur d application est un CTM. Ses principales fonctions sont la gestion d objets distribués ainsi qu une infrastructure qui inclut la gestion des transactions et d autres services, et un modèle de composants côté serveur. Un objet distribué s exécute sous le contrôle d un CTM. Les fonctionnalités que nous avons décrites sont supportées à des niveaux variés par les produits du marché. Les EJB sont un modèle de composants côté serveur normalisé. Cela signifie qu il est possible de développer des objets métier en utilisant le modèle de composants Enterprise JavaBeans et de s attendre à ce qu ils fonctionnent sous le contrôle de tout CTM supportant la spécification des EJB Les différents types de composants serveur Les composants sont de trois types fondamentaux : les beans entité, les beans session, et les beans message. 53 Il est ainsi possible d utiliser un CTM compatible EJB tout en sachant qu il sera possible d en employer un meilleur, dès que celui-ci sera disponible. De plus, l entreprise n est plus enchaînée à un fournisseur (pour autant qu elle n emploie pas des extensions spécifiques de tel ou tel fournisseur mais ce problème n est pas nouveau). 18

19 Un bean entité modélise un objet du monde réel et les processus qui lui sont associés ; son état est persistant. Sa persistance peut être gérée par le développeur ou par le serveur. Usuellement, cette gestion est laissée au serveur, mais la possibilité pour le développeur d intervenir dans cette gestion permet de traiter d éventuels cas particuliers 54. Un bean session modélise une fonctionnalité de l application résidant sur le serveur ; son état est transitoire. Il s agit d une extension de l application responsable de la gestion d un processus métier sur le serveur. Il joue le rôle de chef d orchestre. En réponse à une demande du client, il délègue le travail aux beans entité adéquats ; il connaît l enchaînement des tâches et les délègue aux objets capables de les réaliser. Il joue le rôle de façade entre le processus métier et le client 55. Un bean message traite les messages asynchrones reçu par le biais de l API Java Messaging System (JMS) ; son état est transitoire. Il s agit d une nouveauté introduite dès la version 2.0 qui permet à un client d envoyer un message sans en attendre la réponse et aux objets distribués de s inscrire pour répondre à un message. Ils permettent l intégration des EJB à des systèmes hétérogènes Architecture d un bean entité Au paragraphe 3.1.2, nous avons décrit le principe général de fonctionnement d une architecture à objets distribués. Le modèle de composants Enterprise JavaBeans définit une couche d abstraction supplémentaire sous la forme de deux classes : javax.ejb.ejbobject qui est la racine des interfaces modélisant les objets métiers distants ; elle s appuie sur RMI pour ses communications avec le client (elle étend donc java.rmi.remote). javax.ejb.enterprisebean qui est la racine des différents beans. Cette classe se dérive en javax.ejb.entitybean qui est la racine des beans entités et en javax.ejb.sessionbean qui est la racine des beans session. Si maintenant nous voulons modéliser un objet métier persistant XXX, nous le représenterons par un bean entité dans notre système. Le modèle de composants Enterprise JavaBeans correspondant est représenté par la figure Le code qu il devra produire sera plus complexe et plus long, puisqu il devra lui-même s occuper de réaliser l interfaçage avec le SGBDR cible employé pour la persistance. 55 Il s agit d une instance du design pattern Facade décrit dans [Gam98]. 19

20 Fig. 3.5 : Modèle de composants bean entité (côté serveur). L interface distante (XXXRemote sur la figure 3.5) définit les méthodes métier d un bean auxquelles peuvent accéder les applications clientes 56 : les méthodes que l objet métier présente au monde extérieur afin d effectuer son travail. La classe XXXProxyEJB est le squelette qui encapsule l objet métier concret XXXConcret auquel il délègue l exécution des méthodes. C est au travers d une instance de XXXRemote que le client va interagir avec l objet métier. La persistance de XXXConcret étant, elle, automatiquement gérée par le conteneur Instances distantes Dans le paragraphe précédent, nous avons examiné la représentation d un objet métier distribué dans le modèle de composants Enterprise JavaBeans. Pour qu un tel objet soit utilisable hors du conteneur d EJB, il est nécessaire de fournir au client un outil lui permettant de gérer le cycle de vie du bean : des méthodes pour créer de nouveaux beans, pour les supprimer et pour les retrouver. Cet outil est appelé le Home dans la terminologie des EJB. 56 En fait, toute application s exécutant hors du conteneur EJB. 57 Nous avons vu plus haut que cette persistance pouvait également, à la demande, être gérée par le développeur. 20

21 Le modèle de composants Enterprise JavaBeans définit une couche d abstraction modélisant la gestion du cycle de vie des objets distribués sous la forme de la classe : javax.ejb.ejbhome qui est la racine des interfaces modélisant les factories distantes d objets métiers distants ; elle s appuie sur RMI également sur RMI pour ses communications avec le client (elle étend donc java.rmi.remote). Fig. 3.6 : Architecture du Home (factory d instances distantes). À chaque objet métier XXX est donc associé une interface distante qui définit les méthodes permettant d en gérer le cycle de vie (XXXHomeRemote sur la figure 3.6). La classe XXXHomeEJB est le squelette qui encapsule la référence au squelette représentant l objet métier concret auquel XXXHomeRemote est associé. Lorsqu une méthode de création de l interface distante est invoquée, XXXHomeEJB crée une instance de XXXProxyEJB qui fait référence à la classe de l objet métier du bon type. La valeur retournée est une référence distante (c est-à-dire un stub) sur le XXXProxyEJB. Ce stub implémente l interface distante correspondante, dans notre cas XXXRemote (voir figure 3.5). La factory elle-même (la classe créant des instances de XXXHomeRemote) est localisée via JNDI 58. L enregistrement de l objet distant factory a quant à lui été réalisé au moment du déploiement de l application sur le serveur. Cet objet est la seule 58 Java Naming and Directory Interface. 21

22 instance de la classe factory pour un objet métier du type auquel il est associé. Habituellement, on choisit le nom de l objet métier pour l enregistrement JNDI Autres types de bean Pour les beans session, l architecture est identique à celle décrite pour un bean entité. La différence principale résidant dans le fait que les beans session n ont pas d état persistant. Notons toutefois qu un bean session peut avoir un état transitoire qu il conserve tout au long de son existence 59 une valeur globale à la «session». Les beans session ont également une factory (un Home) qui leur est associé, sous la même forme que celle des beans entité. Les beans message ont été introduits dès la version 2.0 des EJB. Ils permettent l interopérabilité avec d autres applications en échangeant des messages asynchrones via JMS. Leur description sera omise ici Que fait le développeur? On voit que l architecture mise en place est relativement complexe et comprend un grand nombre de classes. Pour une classe métier XXX (définie par une interface publique comme dans la figure 3.5), il se trouvera à la tête de : XXXConcret qui est l implantation concrète de la logique métier définie par l interface publique. XXXProxyEJB qui est le squelette encapsulant XXXConcret. XXXHomeEJB qui est le squelette encapsulant un XXXProxyEJB. XXXRemote qui est l interface 60 représentant l objet distribué et employé par le client. XXXHomeRemote qui est l interface 61 représentant la factory d instances de XXXRemote employé par le client. Il est bien clair que le développeur ne doit pas créer toutes ces classes lui-même. Le fournisseur du conteneur d EJB, outre le serveur d application lui-même, met à disposition du développeur un certain nombre d outils qui vont lui permettre de générer automatiquement la plupart de ces classes à partir de la description de l objet métier XXX. Soit le développeur emploie dans son application cliente des beans déjà présents 62 dans le conteneur d EJB et dont il connaît les désignations JNDI. En ce cas toutes ces classes existent déjà dans son environnement et il les utilise pour construire son application comme décrit plus bas. Soit le développeur a défini de nouveaux objets métier et, dans ce cas, il devra bien évidemment fournir l implantation concrète de la logique métier sous la forme de la 59 Un bean session peut être avec et sans état. Lorsqu il est avec état, cet état est valide pour la durée de vie du bean et permet donc d implanter ce qu on appelle usuellement des variables de session. 60 Interface distante du bean. 61 Interface distante du home (d un bean). 62 Voir paragraphe Déploiement. 22

23 classe XXXConcret. Toutes les autres classes pourront être générées automatiquement par les outils à partir de la description de XXX 63. Pour réaliser une application cliente employant l objet métier distribué XXX, le développeur devra obtenir une référence distante du home de XXX via JNDI (une instance de XXXHomeRemote) avec laquelle il pourra obtenir une référence distante de l objet distribué lui-même (une instance de XXXRemote). Avec cette dernière, il pourra ensuite interagir avec l objet distribué. Avec la référence distante XXXHomeRemote il pourra également contrôler le cycle de vie du bean qui lui est associé. import javax.rmi.* ; import javax.naming.* ; /* L obtention du contexte JNDI dépend du fournisseur d EJB */ Context jndicontext = new InitialContext(...); /*... */ Object ref = jndicontext.lookup("xxx") ; XXXHomeRemote xxxhome = (XXXHomeRemote)PortableRemoteObject.narrow(ref, XXXHomeRemote.class); /*... */ XXXRemote xxx0 = xxxhome.findbyprimarykey(...); /*... */ xxx0.set(...); /*... */ SomeType y = xxx0.get(); /*... */ XXXRemote xxx1 = xxxhome.create(...); /*... */ xxx0.remove(); Fig. 3.7 : Emploi de l objet métier par une application cliente. Notons encore que depuis la spécification Enterprise JavaBeans 2.0, le système génère également des interfaces locales (XXXLocal l interface de l objet métier et XXXHomeLocal l interface de la factory). Celles-ci permettent à un bean du conteneur de communiquer avec d autres beans du même conteneur sans passer par la couche RMI, optimisant ainsi l accès aux ressources Déploiement Le déploiement des différents composants décrits est assuré automatiquement par des outils qui sont livrés avec le conteneur d EJB. Le problème est de répartir les différentes classes sur les serveurs de l environnement distribué, d enregistrer celles-ci dans le conteneur d EJB et de définir leur désignation JNDI. La description de cette répartition est effectuée au moyen de fichiers XML 64. Les classes sont quant à elles empaquetées (avec le fichier XML) dans des fichiers JAR 65. Les outils qui permettent la gestion du déploiement tout comme ceux qui permettent de générer les classes à partir de la description de l objet métier sont en général 63 Les classes générées devront ensuite être déployées. Voir paragraphe Voir [Xml02]. 65 Format d empaquetage de classes et de leurs hiérarchies de packages. 23

24 conviviaux, munis d une interface graphique claire et intuitive. La description de telles interfaces graphiques, pas plus que celle de la structure des fichiers XML générés pour le déploiement n entre dans le contexte de notre étude Le rôle du conteneur Nous avons vu 66 que la spécification du conteneur d EJB était indépendante du CTM qui le supportait. Néanmoins, la spécification des EJB a été définie de telle sorte qu ils puissent exploiter les services usuels fournis par un CTM. Ces derniers sont conçus pour prendre en charge de façon simultanée des milliers d objets distribués. Pour assurer cette tâche de façon robuste, ils doivent faire preuve d une gestion intelligente des ressources mémoire, des connexions à la base de données, de la puissance du processeur, etc. L une des techniques mises en œuvre par le conteneur d EJB pour gérer les montées en charge tout en maintenant des performances élevées est la gestion d une réserve d instances. Le conteneur d EJB crée plusieurs instances d une classe de bean et les conserve jusqu à ce qu elles soient demandées 67. Quand des clients effectuent des requêtes de méthodes métier, les instances sont prises dans la réserve et attribuées aux proxies d EJB associés aux clients 68. Quand le proxy n a plus besoin de l instance, celle-ci retourne dans la réserve. Cette technique réduit le nombre d instances de composants, et donc de ressources mémoire, nécessaires au service des demandes des clients ; de plus, il est moins coûteux en ressources processeur de réutiliser les instances de la réserve plutôt que d en créer et d en détruire fréquemment 69. Un CTM EJB aide non seulement les clients à localiser les objets distribués dont ils ont besoin, mais il leur fournit aussi un certain nombre de services qui en facilitent l utilisation. En général, ce sont six services de base qui sont offerts : la concurrence, la gestion des transactions, la persistance, la distribution d objets, le nommage et la sécurité. La concurrence est prise en charge automatiquement par les serveurs d EJB 70 et les méthodes d un bean n ont pas à être sûres vis-à-vis des threads. Par défaut, les accès concurrents aux instances d un bean sont interdits ; un seul client peut accéder à l instance d un bean à la fois : si un client invoque une méthode d un bean, aucun autre client ne peut accéder à cette instance tant que l invocation de la méthode n est pas terminée. La gestion des transactions est également prise en charge automatiquement par les serveurs d EJB 71. Le développeur d applications n a pas à utiliser une API spécifique pour prendre en charge et gérer le ou les beans impliqués dans une transaction. Une transaction commence juste avant l exécution d une méthode et se termine à la fin de celle-ci. Les transactions sont déclaratives, c est-à-dire que le développeur déclare 66 Au paragraphe Infrastructure et EJB. 67 Le serveur d EJB maintient des réserves d instances pour chaque type de bean déployé. 68 Voir Architecture d un bean entité. 69 On évite ainsi de stresser le gestionnaire de mémoire et son garbage collector dont on sait qu ils sont gourmands en ressources processeur. 70 L accès concurrent aux beans session n a pas de sens et cela se comprend dans la mesure où un bean session est une extension d un client et ne sert que ce client. 71 Il est également possible, si nécessaire, de permettre au bean de gérer explicitement les transactions. 24