Conception et Implémentation d un serveur d applications dans le cadre du projet EISMO

Transcription

1 L Y O N MASTERE SPECIALISE EN INFORMATIQUE Année 2003/2004 Conception et Implémentation d un serveur d applications dans le cadre du projet EISMO Par Pierre-Henri FONTANAUD Soutenu le 23 Novembre 2004 Devant le jury composé de : Responsable INSA : Mme Nabila BENHARKAT Responsable stage: Membres : M. Rami RIFAIEH M. Mohamed OU-HALIMA (Responsable du Mastère Informatique) Projet EISMO Page 1 sur 50

2 REMERCIEMENTS Avant d entrer dans le déroulement de mon stage, je tiens particulièrement à remercier Nabila Benharkat et Rami Rifaieh. Tout au long de ces cinq mois de stage, ils ont su me laisser un grand degré d autonomie, tout en suivant de très près l avancement du projet et les difficultés que je rencontrais. J ai apprécié leur disponibilité ainsi que l aide qu ils ont su m'apporter ou me trouver lorsque j en ai eu besoin. Je tiens également à remercier tous les gens de l INSA qui ont, d une manière ou d une autre, contribué au bon déroulement de mon stage (administrateurs, étudiants du Liris). Je voudrais enfin remercier Patricia Varet, pour tous les problèmes d'ordre administratif qu'elle a pu m'éviter ou régler tout au long de l'année. Projet EISMO Page 2 sur 50

3 SOMMAIRE REMERCIEMENTS... 2 SOMMAIRE... 3 INTRODUCTION... 5 I. Contexte du projet EISMO... 5 II. Présentation du projet EISMO... 5 II.1. Objectifs du projet... 5 II.2. Etude de Faisabilité... 6 II.3. Implémentation... 6 II.4. Principe du serveur et le scénario de l étude de cas... 8 II.5. Les étapes du projet... 9 III. Définitions... 9 III.1. Définition d une ontologie... 9 III.2. Définition d une étude de faisabilité TECHNOLOGIES MISES EN ŒUVRE I. La couche KB Server I.1. Logique de description et langages I.2. Etude de faisabilité : choix du serveur I.3. Utilisation et comportement de Racer I.4. Utilisation de JRacer II. La plateforme J2EE II.1. Choix du serveur II.2. Installation et utilisation de Jonas II.3. Les EJB SCENARIO I. Les Systèmes d Information utilisés II. Le déroulement du scénario II.1. L administrateur et le serveur II.2. Le client L IMPLEMENTATION DU SERVEUR EISMO I. L administration d EISMO I.1. Présentation I.2. L architecture I.3. Le développement des différentes classes II. Le package coreservices II.1. Présentation II.2. L architecture II.3. Les différentes classes III. Les EJB III.1. Les différents EJB du serveur III.2. L installation et le déploiement IV. Etudes de faisabilité IV.1. La transformation de diagrammes de classes en ontologies IV.2. La recherche des EJB du serveur et de leurs méthodes IV.3. La connexion du client et le partage des données Projet EISMO Page 3 sur 50

4 L'IMPLENTATION DU CLIENT I. Présentation II. L'architecture III. Le développement des différentes classes PERSPECTIVES ET CONCLUSIONS I. Perspectives II. Conclusions ANNEXES I. ANNEXE 1 : Diagramme de classes du SI Data Warehouse II. ANNEXE 2 : Diagramme de classes du SI EDI III. ANNEXE 3 : Diagramme de classes du serveur IV. ANNEXE 4 : Diagramme de classes du package administration V. ANNEXE 5 : Diagramme de classes du package coreservices VI. ANNEXE 6: Diagramme de classes du client VII. Annexe 7 : Diagramme des Cas d'utilisation VIII. ANNEXE 8: Diagramme de séquences de l'administrateur IX. ANNEXE 9: Diagramme de séquences du client X. BIBLIOGRAPHIE Projet EISMO Page 4 sur 50

5 INTRODUCTION I. Contexte du projet EISMO L es Systèmes d Information, ainsi que les Bases de Données, sont de plus en plus présents dans les entreprises. Leurs besoins de communication et d échanges de données ne cessent de croître, en même temps que leur utilisation. Ces échanges nécessitent une certaine interopérabilité entre les systèmes, qui doivent pouvoir interpréter et transmettre des informations ou des requêtes. Mais ces systèmes sont développés dans des environnements très hétérogènes (langages de programmation, bases de données, matériel sont totalement hétéroclites). De plus, un même système ou des systèmes semblables peuvent avoir des représentations différentes, à l origine de nombreuses difficultés dans la communication. En effet, comment savoir que plusieurs modèles représentent en réalité en réalité le même objet? Par exemple, ce problème de multi représentation est maintenant bien connu dans le monde du e-commerce, du fait de quelques facteurs tels que la diversité des organisations, des utilisateurs, des applications, etc. Une première réponse à ces problèmes a été trouvée sur les plans physique et syntaxique, avec le développement de technologies telles que CORBA, Java, XML, etc. Mais elles ne résolvent qu une partie du problème, celle des langages de programmation et de la communication, laissant entière celle de la multi représentation. Le projet EISMO (Enterprise Information System Multi representation Ontology) propose une réponse à ce problème de multi représentation : l utilisation des ontologies. II. Présentation du projet EISMO S I un Système d Information ou une Base de Données est représenté par un modèle (un schéma UML par exemple pour un SI), il peut aussi l être par une ontologie. Cette dernière sera facilement utilisable par plusieurs systèmes et applications. EISMO se propose d utiliser ce concept afin de résoudre le problème d interopérabilité. EISMO est un projet de recherche, qui a pour but de définir une plateforme pour la coopération des Systèmes d Information d Entreprises. II.1. Objectifs du projet L objectif majeur de ce projet est de valider le modèle conceptuel proposé pour solutionner le problème de la multi représentation en s appuyant sur une étude de cas, qui permettrait également d explorer les impacts sur la réutilisabilité et le partage d informations. Un second objectif vise à fournir une compréhension globale des Systèmes d Information d Entreprise afin de pouvoir améliorer la communication. Il s agit donc de construire une représentation ontologique partagée pour tous les Systèmes d Information d Entreprise, en gardant à l esprit deux buts fondamentaux : la réutilisabilité et l interopérabilité. Ce projet comprend deux parties essentielles : Projet EISMO Page 5 sur 50

6 Une étude de faisabilité L implémentation du serveur II.2. Etude de Faisabilité Une étude de faisabilité permettra de sélectionner les technologies à utiliser et de définir la manière d implémenter le serveur EISMO. Cette étude de faisabilité portera sur les serveurs à utiliser (serveur d application et de bases de connaissances), sur les différents services offerts par ce serveur et leurs composants. Elle sera menée en parallèle à l avancement du projet, au début de chaque étape du développement. Cette étude vise : D une part à démontrer la faisabilité globale du projet, sur un plan technique mais aussi en termes de planning. D autre part à définir non seulement les composants mais aussi les modes opératoires et les conditions de réalisation. Enfin elle permettra de chercher des solutions à chaque problème rencontré, qui peuvent être éventuellement des solutions de rechange en cas d impossibilité technique. II.3. Implémentation En termes informatiques, EISMO repose sur une plateforme J2EE et une conception "ontologique" des Systèmes d Information. Il conjugue l utilisation d un langage de programmation (Java), d un langage terminologique, d un serveur de bases de connaissances et d un serveur d applications. Il est constitué de 3 couches : Une première couche basée sur une implémentation J2EE, constituée d un serveur d applications et reposant sur l architecture Java. Cette couche permet à un client de se connecter au système. Une seconde couche, que nous appellerons "Core Services". Cette couche contient les différents services offerts aux clients. Elle sera entièrement développée. La troisième couche est le serveur de Bases de Connaissance, qui sera chargé de la gestion des ontologies. Elle permettra notamment de charger des ontologies en mémoire, et de leur passer des requêtes. Une interface administrateur permettra de gérer ce serveur EISMO. Elle devra être entièrement développée. Elle permettra de démarrer les serveurs d applications et de Bases de Connaissances, de charger des ontologies dans le serveur ou directement des diagrammes de classes UML de Systèmes d Information Enfin, une interface client permettra à ce dernier de se connecter au serveur et d y effectuer les opérations offertes par celui-ci, et implémentées dans "Core Services". Cette architecture est présentée de manière simplifiée sur la figure 1 et sera développée dans les chapitres suivants. Projet EISMO Page 6 sur 50

7 Projet EISMO Page 7 sur 50 Figure 1 EISMO KB Server EISMO Core Services J2EE Platform EISMO Ontology Applications ressources provider Query Resolver EJB Creator / dispatcher Pattern Designer EJB Container Clients Distant Objects Access Security Description Logic Server Applications Integrator Model Integrator Ontology Integrator Schema Generator Transactions service Reasoning System (Inference Engine) JSP Container KB Server Interface Knowledge Manager Ontology Manager Ambiguity Resolver Semantic Interoperability Manager Data Bases Access Data Bases Admin. S.I.

8 II.4. Principe du serveur et le scénario de l étude de cas Le but du serveur est de fournir à un développeur des méthodes prises dans des Systèmes d Information existants, mais sélectionnées à partir d un concept contenu dans un de ces S.I. La couche KB Server contiendra des ontologies, qui sont en réalité les diagrammes de classes de ces SI, et qui contiennent des concepts. Notre développeur cherchera à obtenir, pour concevoir sa nouvelle application, des méthodes déjà codées, et utilisant soit le concept sur lequel il doit travailler, soit un concept équivalent. Le serveur va donc interroger pour lui les ontologies et lui proposer les méthodes répondant à ces critères. Le principe est décrit dans la figure 2 Admin ON1 ON2 Moteur Serveur KB O N 1 O N 2 Gestion des Ontologies : Ontologies ouvertes Concepts de ces ontologies Gestion des EJB EJB déployés Concepts utilisés Méthodes Couche Core Services Fichier XML : Liens entre concepts Conteneur EJB Fichiers XML : Liens entre EJB et concepts, liste des ontologies ouvertes, Liste des EJB Couche J2EE RMI ON1 ON2 Concept1 Concept2 Concept3 EJB1 EJB2 EJB3 Valider Valider Valider CLIENT Figure 2 : le principe du serveur EISMO L étude de cas permettra de mettre en application ce serveur en utilisant deux SI : Data Warehouse et EDI, dont les diagrammes de classes sont donnés en annexes 1 et 2. Le scénario est décrit en détail dans le chapitre qui lui est consacré (voir page 20) Projet EISMO Page 8 sur 50

9 II.5. Les étapes du projet La réalisation de ce serveur EISMO se déroulera en plusieurs étapes qui consisteront à étudier et choisir les différents composants, tels que les serveurs de bases de connaissance et d applications, et à développer les applications et services nécessaires : Etude de faisabilité, choix et installation du serveur de Bases de Connaissances Etude de faisabilité, choix et installation du serveur d applications Développement des classes nécessaires à la communication avec le serveur de Bases de Connaissances Etudes de faisabilité portant sur l importation de schémas UML dans le serveur de Bases de Connaissances Etude de faisabilité portant sur l utilisation des EJB et le développement de ces EJB Développement de l interface administrateur Développement de la couche Core Services après étude de faisabilité. Le planning : Nom de la tâche Apprentissage logique de description Développement serveur Développement administration Développement com avec Racer Développement admin Développement core Services Etudes de faisabilité Codage classes Développement des EJB Développement Application Client Tests Fenêtre Principale Méthode affichage EJB du serveur Méthode affichage Méthodes EJB Méthode affichage code EJB Juin Juillet Août Septembre Octobre 31/0507/0614/0621/0628/0605/0712/0719/0726/0702/0809/0816/0823/0830/0806/0913/0920/0927/0904/1011/1018/10 III. Définitions Q uelques termes et notions utilisés dans le projet sont définis de façon assez sommaire dans ce paragraphe, mais de manière à définir la façon dont elles sont traitées ou utilisées tout au long de cette étude. III.1. Définition d une ontologie Il s agit d une définition très sommaire car elle pourrait faire l objet de nombreuses pages et ne constitue pas l objet du projet EISMO. Dans ce projet, nous nous bornerons à utiliser certaines "fonctionnalités" des ontologies. Ontologie : du latin Ontologia : Théorie de l être. Projet EISMO Page 9 sur 50

10 Une ontologie définit les termes utilisés pour décrire et représenter un champ d'expertise. Les ontologies sont utilisées par les personnes, les bases de données, et les applications qui ont besoin de partager des informations relatives à un domaine bien spécifique, comme la médecine, la fabrication d'outils, l'immobilier, la réparation d'automobiles, la gestion de finances, etc. Les ontologies associent les concepts de base d'un domaine précis et les relations entre ces concepts, tout cela d'une manière compréhensible par les machines. Elles encodent la connaissance d'un domaine particulier ainsi que les connaissances qui recouvrent d'autres domaines, ce qui permet de rendre les connaissances réutilisables. (Source : W3C) individus, etc. Elle peut également être modélisée par un schéma UML. Une ontologie est une conceptualisation formelle du monde. Elle permet d identifier et de modéliser les concepts d un domaine ainsi que les relations conceptuelles. Elle permet également de se mettre d accord sur les termes employés. Par exemple, les termes chat, matou, minet, etc. désignent tous la même chose. En revanche, des termes identiques peuvent représenter des choses totalement différentes (par exemple, le mot bureau peut être utilisé soit pour la pièce, soit pour le meuble). L ontologie permettra de définir une formalisation afin de lever toute ambiguïté. Elle peut utiliser des langages appropriés, appelés logique de description et manipule de nombreuses notions tels que les concepts, les individus, les relations entre Elle est constituée essentiellement de concepts et de liens entre concepts, qui peuvent être, par exemple, des liens d égalité ou d appartenance. Une ontologie est peuplée d individus, qui appartiennent à un ou plusieurs concepts, ces individus constituant les données de cette base. III.2. Définition d une étude de faisabilité Il parait important de bien définir au départ ce que l on attend d une étude de faisabilité. En règle générale, ses buts sont de vérifier si un projet peut être réalisé et de suggérer des solutions alternatives réalistes, l'objectif final étant pour un décideur de lancer ou d'arrêter le projet. D une manière générale, les critères à étudier sont les suivants : L'organisation du système actuel s'il existe Les problèmes rencontrés Les objectifs d'un nouveau système Les contraintes Les alternatives possibles. Les conclusions à tirer de cette étude sont : Faisabilité du projet Alternative retenue Elle fait apparaître 4 points importants : Faisabilité opérationnelle: explore l'urgence du projet et l'acceptabilité de chaque solution. Faisabilité technique: le projet est-il réalisable dans les limites de la technologie actuelle? Est-ce que qu'il est réalisable en respectant les contraintes liées aux ressources? Faisabilité en termes de planning: la solution est-elle réalisable dans les délais Faisabilité économique: le projet est-il réaliste, compte tenu des contraintes budgétaires? Quels bénéfices vont en résulter? Quels sont les coûts de développement et de déploiement Projet EISMO Page 10 sur 50

11 Dans le cadre du projet EISMO, nous ne tiendrons pas compte de l aspect opérationnel. En effet, il s agit d un projet de recherche, qui vise à valider une architecture, donc une solution. Le critère économique sera un élément important, le budget étant très faible. En revanche, aucun bénéfice financier n étant attendu de ce projet, ce critère sera ignoré. La partie technique de cette étude consistera à valider l architecture technique et à choisir les composants logiciels (serveurs, langages, etc.), le tout dans la durée du stage, c'est-à-dire cinq mois. Projet EISMO Page 11 sur 50

12 L TECHNOLOGIES MISES EN ŒUVRE architecture du serveur EISMO est donc constituée de 3 couches (voir figure 1). Ces couches devront communiquer les unes avec les autres par l intermédiaire de divers programmes et interfaces, mais également permettre à des clients de l application d utiliser les différents services proposés par EISMO. I. La couche KB Server Cette couche est basée sur un serveur de Base de Connaissances. Elle contient : la ou les ontologies utilisées par le serveur le système terminologique avec sa logique descriptive et son moteur d inférence. l interface avec les autres couches. I.1. Logique de description et langages La logique de description est une représentation des connaissances. C est un modèle orienté objets. Elle fait intervenir les notions de concept, de rôle, d individu. a Quelques définitions Concept : représentation mentale générale et abstraite d un objet (Le Petit Robert). Dans le domaine de la modélisation informatique, on a besoin de représenter une situation en termes de : Objets Classes Relations (ou associations) La logique de description est conçue pour représenter une situation en termes de : Objets Classes, qui sont appelées concept dans ces logiques de description Relations appelées rôles. Rôle : relation binaire entre individus Individu : ce sont les données de la base Tbox : contient la terminologie (peut être comparé au diagramme de classes d un SI) Abox : contient les individus (peut être comparée aux données d un SI) Relation de subsomption : consiste à organiser les concepts par niveau de généralité. U concept A subsume B si l ensemble des individus représentés par B est inclus dans l ensemble des individus de A : A est plus général que B b Langages Les langages utilisés par les serveurs de Bases de Connaissances sont basés sur la logique de description. Il existe plusieurs langages : DAML+ OIL (Darpa Agent Markup Language + Ontology Inference Layer) Projet EISMO Page 12 sur 50

13 RDF et RDFS OWL Ces langages ont une syntaxe respectant le standard XML I.2. Etude de faisabilité : choix du serveur Pour cette partie, il existe deux serveurs qui répondent au besoin : FACT (Fast Classification of Terminologies) RACER (Renamed ABox and Concept Expression Reasoner) Ce sont deux serveurs issus de projets de recherche. Tous les deux sont en Open Source et gratuits. Ils présentent des fonctionnalités similaires. Fact s appuie sur une architecture Corba, tandis que Racer est basé sur une architecture RMI. Les deux serveurs nécessitent peu de ressources : ils peuvent être installés sur un PC de bureau. Corba étant un peu plus lourd à mettre en œuvre, et racer disposant d une interface écrite en Java (JRacer) permettant une utilisation très simple dans le cadre de notre projet, le choix s est porté sur Racer I.3. Utilisation et comportement de Racer a Installation et démarrage L installation de Racer est très simple : il suffit de télécharger sur le site Internet et de décompresser un fichier nommé "racer.exe". Le serveur est alors prêt à fonctionner. On peut le démarrer de deux manières : soit par un double clic sur le fichier "racer.exe", soit en ouvrant une console et en tapant la commande racer. Au démarrage, Racer n affiche que les quelques informations de la figure 3. Il est intéressant de noter qu il supporte les protocoles TCP et http. Lorsque l on démarre le serveur, aucune ontologie n est chargée en mémoire. Projet EISMO Page 13 sur 50

14 ;;; RACER Version ;;; RACER: Reasoner for Aboxes and Concept Expressions Renamed ;;; Supported description logic: ALCQHIr+(D)- ;;; Copyright (C) , Volker Haarslev and Ralf Moeller. ;;; RACER comes with ABSOLUTELY NO WARRANTY; use at your own risk. ;;; Commercial use is prohibited; contact the authors for licensing. ;;; RACER is running on IBM PC Compatible computer as node Unknown ;;; The XML/RDF/RDFS/DAML parser is implemented with Wilbur developed ;;; by Ora Lassila. For more information on Wilbur see ;;; ;;; The store/restore facility is based on software developed ;;; by Michael Wessel. ;;; The solver for nonlinear inequations over the complex numbers ;;; is based on CGB by Marek Rychlik, University of Arizona. ;;; For more information on CGB see ;;; The HTTP interface based on DIG is implemented with CL-HTTP developed and ;;; owned by John C. Mallery. For more information on CL-HTTP see ;;; [ :33:43] HTTP service enabled for: [ :33:43] TCP service enabled on port 8088 Figure 3 : écran de Racer b Ouverture d ontologies Il existe plusieurs formats de fichiers utilisables par Racer : "racer", ".daml", ".rdfs", ".owl". Les formats de ces fichiers correspondent au langage utilisé. L ouverture d une ontologie peut se faire de plusieurs façons : Lorsque l on démarre Racer dans une console, on peut lui donner le nom du fichier en arguments (ex.. racer -f c:/racer/examples/family-3.racer) On peut également démarrer Racer, et se connecter au serveur via le port TCP pour ouvrir le fichier, soit par l intermédiaire d une interface graphique, soit grâce à une application permettant de se connecter et d ouvrir des fichiers. Ces fichiers peuvent être ouverts localement (ils sont sur un disque dur de la machine), soit sur un réseau (Internet ou réseau local). Racer utilise alors le protocole http. Plusieurs fichiers peuvent ainsi être ouverts. En revanche, une requête ne portera que sur une seule ontologie, la dernière ouverte. I.4. Utilisation de JRacer Dans notre application, nous allons implémenter JRacer. Il s agit d un ensemble de classes développées en Java et contenant toutes les méthodes nécessaires à la connexion, à la création et à l interrogation des ontologies. Projet EISMO Page 14 sur 50

15 a Organisation de JRacer o class java.lang.object o class jracer.assertion (implements java.io.serializable) o class jracer.attributeassertion o class jracer.conceptassertion o class jracer.roleassertion o class jracer.didda o class jracer.racerconstants o class jracer.racersocketclient o class jracer.racerclient o class jracer.racertermparser o class jracer.testracerclient o class java.lang.throwable (implements java.io.serializable) o class java.lang.exception o class jracer.racerexception o class jracer.racerillegalconstruction Deux classes seront essentiellement utilisées : la classe RacerClient et la classe RacerException. En effet, ces deux classes permettent de gérer la connexion, les requêtes ainsi que les exceptions générées. b Comment utiliser JRacer? Avant de pouvoir ouvrir un fichier ou d interroger une ontologie, il faut créer une connexion au serveur. Il faut instancier la classe RacerClient (par la commande new) en passant en paramètres au constructeur l adresse IP de la machine (ou son nom) ainsi que le port TCP (8088 par défaut, mais ce numéro de port est configurable). Il faut ensuite ouvrir la connexion par la commande openconnection() appliquée à l objet créé précédemment. La connexion est alors réalisée. Pour ouvrir un fichier, on appliquera à cet objet une des méthodes de JRacer. Par exemple, si l objet RacerClient créé précédemment s appelle client, on utilisera : client.owlreadfile(nomfichier) pour un fichier de type owl client.racerreadfile(nomfichier) pour un fichier de type racer client.damlreadfile(nomfichier) pour un fichier de type daml Une fois ce client créé et un fichier ouvert et associé à ce client, on pourra lui passer toutes les requêtes permises par Racer (exemple : obtenir la liste des concepts de l ontologie). Lorsque l on n a plus besoin de ce client, il faut le fermer par la commande close. II. N La plateforme J2EE otre application étant une application distribuée, un serveur d applications devra être installé. Il devra offrir la possibilité à un client de se connecter, que ce soit une application, ou un SI. Il devra de plus permettre la connexion à des bases de données et contenir des conteneurs EJB. Un serveur d applications est constitué d un ensemble de services et d API permettant l hébergement d applications distribuées. Projet EISMO Page 15 sur 50

16 Figure 4 : Architecture J2EE Parmi les serveurs d application du marché les plus connus, trois ont été retenus sur le critère du coût : Tomcat JBoss JOnAS (Java Open Application Server) II.1. Choix du serveur JDK EJB JSP JMS OS Tomcat 1.3 & NON 1.2 NON Tous JBoss & Tous JOnAS & Tous JBoss a été développé par Jboss Inc. (Matrix Partners, accel Partners, Intel) JOnAS a été développé par WebObject (Bull, France Télécom, INRIA, puis Red Hat en 2003 et maintenant Apache ) Remarque : JBoss et JonAS intègrent tous les deux Tomcat. Tomcat n intègre pas les services liés aux EJB, et ne peut donc pas être utilisé seul. JBoss et Jonas sont équivalents pour notre application sur le plan des fonctionnalités offertes. Divers comparatifs parus sur Internet font apparaître que JOnAS est plus performant en charge et mieux documenté que JBoss. Le choix du serveur d applications s est donc porté sur JOnAS. Projet EISMO Page 16 sur 50

17 II.2. Installation et utilisation de Jonas Avant d installer JOnAS, il faut avoir installé : Java J2SE Ant, qui est un make basé sur Java (à télécharger sur BCEL, qui est une librairie nécessaire à Ant pour compiler (que l on récupère sur le site Sur le site d ObjectWeb, on trouve plusieurs variantes de JOnAS : JOnAS seul, JOnAS et Tomcat, JOnAS et Jetty. La version utilisée dans EISMO est JOnAS + Tomcat. Après avoir décompressé et lancé le programme d installation, il faut configurer les variables d environnement. Le lancement de Jonas se fait par la commande jonas start, l arrêt par jonas stop. Après le démarrage, la console d administration est accessible par la commande jonasadmin. II.3. Les EJB Les EJB (ou Enterprise Java Beans) sont des composants serveur distribués écrits en Java. Ce sont en fait des objets distants utilisant RMI/IIOP, qui est un mélange entre la syntaxe de RMI et le protocole de communication utilisé par Corba, ce qui permet de garantir que ces objets pourront être utilisés quelque soit le code client. Celui-ci aura recours au service JNDI (Java Naming and Directory Interface) pour localiser ces objets distants. Le développeur d un EJB n aura pratiquement à s occuper que de l aspect métier de son application. En effet, la plateforme J2EE sur laquelle ils seront déployés gère les services système tels que la sécurité, les transactions, les messages, etc. a Catégories d EJB Il existe 3 catégories d EJB : Les EJB "Session", qui sont utilisés pour représenter les données et les comportements qui leur sont associés. Les EJB "Entity" qui permettent la représentation de données persistantes ayant une existence au niveau d un support de stockage tel qu une base de données. Les EJB "Message Driven" permettent la mise en œuvre d applications basées sur le traitement de messages. Les EJB Session : Il existe 2 types d EJB Session : avec état ("statefull") ou sans état ("stateless") "Statefull" : Ce type d EJB permet de maintenir en mémoire les données utilisées par le client. Il est donc utilisable par un client unique, et sera donc instancié autant de fois qu il y a de clients. "Stateless" : Cet EJB ne maintient pas les données en mémoire, mais peut être utilisé par plusieurs clients simultanément. Les EJB Entity Il existe également de type d Entity Beans : Les EJB de type CMP (Container Managed Persistance) délèguent au conteneur la gestion de la persistance (le programmeur ne s occupe pas du code JDBC) Projet EISMO Page 17 sur 50

18 Les EJB Message Driven Les EJB de type BMP (Bean Managed Persistance) prennent en charge l accès aux bases de données. Dans ce cas, c est le programmeur qui écrit le code JDBC. Ces EJB sont sans état et utilisent des messages asynchrones délivrés par JMS (Java Message Service). Ces messages asynchrones permettent à des applications de communiquer en échangeant des messages de telle façon que le récepteur est totalement indépendant de l émetteur du message. Ainsi, l émetteur envoie son message et n a pas besoin d attendre que le récepteur l ait reçu ou traité. b Composition d un EJB Un EJB est constitué d un minimum de 5 fichiers : Une interface locale Une interface distante La classe d implémentation de l EJB Un descripteur de déploiement Un descripteur de déploiement spécifique au serveur d applications. En plus de ces 5 fichiers, on peut trouver autant de classes que nécessaire au fonctionnement. L interface locale, également appelée interface de fabrique, qui permet la construction de l EJB grâce à sa méthode create(). Cette interface hérite de EJBHome. C est elle qui est appelée par le client. L interface distante, ou interface métier, permet de définir les méthodes que va proposer l EJB au client. Elle hérite de EJBObject. La classe d implémentation contient toutes les méthodes et les appels aux différentes classes nécessaires. Elle hérite de SessionBean ou d EntityBean. Les descripteurs de déploiement sont des fichiers xml. Ils contiennent toutes les informations nécessaires pour le déploiement de l EJB. (Informations telles que le type de l EJB, son nom, etc.). Ils sont au nombre de deux: un descripteur de déploiement général, qui contiendra toutes les informations propres à l'ejb, et un descripteur propre au serveur d'applications. c Principe d utilisation Après avoir écrit le code de l EJB, il faut le compiler. Sa compilation va générer une archive jar, cette archive portant le nom de l EJB. Au cours de cette compilation, un certain nombre de fichiers sont générés, dont des fichiers particuliers qui sont le "stub"» et le "skeleton". Ce sont eux qui vont permettre l utilisation de l EJB. Ce sont ces deux fichiers qui permettent l utilisation distante. Le serveur disposera du "skeleton", tandis que le client disposera du "stub". Lors d un appel d un EJB par le client, c est en fait le "stub" qui va dialoguer avec le "skeleton" du serveur. Projet EISMO Page 18 sur 50

19 Figure 5 : Stub et Skeleton Pour mettre en œuvre un EJB, il faudra copier dans l application cliente le "stub" ainsi que l interface locale de l EJB, qui permettra au client de créer l EJB. Projet EISMO Page 19 sur 50

20 E SCENARIO ISMO est avant tout un prototype, dont le but principal est de démontrer la réutilisabilité des méthodes d un SI par un autre SI. Pour effectuer cette démonstration, un scénario a été étudié. Il consiste à écrire quelques méthodes dans des EJB, et à faire utiliser ces méthodes par un autre SI, qui traite d un sujet similaire. Mais cette réutilisation se fait à travers le serveur, qui met à disposition du développeur le code des méthodes existantes, et lui permet de le modifier selon ses besoins et de recréer de nouveaux composants à partir de ce code existant. I. Les Systèmes d Information utilisés D ans ce scénario, on utilise deux SI différents. Ces deux systèmes d information seront modélisés sous la forme de diagrammes de classes UML, puis, par un mécanisme intégré au serveur, ces diagrammes seront transformés en ontologies utilisables par Racer. Les diagrammes de classe de ces deux SI sont donnés en Annexes 1 et 2. Ces deux applications présentent des similitudes. Le premier, EDI, contient une fonction de mapping. Le second, Data Warehouse, contient également une fonction de mapping. Mais ces deux fonctions, dont la finalité est très proche, sont modélisées différemment. II. Le déroulement du scénario P II.1. L administrateur et le serveur our que le serveur EISMO puisse être utilisé par des clients, l administrateur doit auparavant avoir effectué quelques opérations. Celles-ci ont pour but de charger les ontologies dans le serveur et de définir les liens existant entre ontologies ainsi qu entre ontologies et EJB. Le déroulement de ces opérations est le suivant (voir diagrammes de séquences en annexes 8 et 9): L administrateur démarre le serveur EISMO Il démarre ensuite les serveurs Racer et Jonas Il charge les schémas UML des Systèmes d Information Il déploie les EJB si ceux-ci ne le sont pas. Il définit les liens entre ces applications ainsi que les liens entre chaque application et les EJB s ils n ont pas déjà été définis. Le serveur se charge du stockage des différents liens (entre ontologies, entre EJB et concepts, etc.). II.2. Le client Lorsque ces opérations sont terminées, le développeur peut alors utiliser le serveur. Pour cela, il va procéder ainsi : Il démarre l application cliente. Celle-ci utilise un EJB qui permet, de façon automatique, la connexion au serveur EISMO. Cet EJB retourne à l application cliente la liste des ontologies ouvertes sur le serveur. Cette application affiche cette liste. Le développeur choisit dans cette liste le fichier correspondant au SI sur lequel il désire travailler et valide son choix. Projet EISMO Page 20 sur 50