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

21 La liste des concepts utilisés est alors affichée dans la fenêtre client. Le développeur choisit alors un concept qu il souhaite utiliser. A cette étape, une recherche de tous les concepts équivalents doit être effectuée, puis de tous les EJB utilisant au moins l'un de ces concepts. Le client récupère cette liste d'ejb et l affiche. Le développeur va à ce moment pouvoir sélectionner un EJB et obtiendra la liste des méthodes contenues dans cet EJB. Le développeur peut enfin sélectionner la méthode qui l intéresse et récupérer le code de celle-ci, qui va s'afficher dans une fenêtre où il pourra être modifié avant d'être sauvegardé. Projet EISMO Page 21 sur 50

22 L L IMPLEMENTATION DU SERVEUR EISMO a première phase de cette implémentation consiste à installer et configurer les serveurs Racer et Jonas sur la machine. Il faudra ensuite développer les différents programmes de l application : la partie administration du serveur et la partie client, ainsi que différents composants de coreservices. L application contiendra donc deux packages : le package administration et le package coreservices. Le développement se fera à l aide de l environnement de développement intégré Eclipse, qui est Open Source et dispose de nombreux plugins. Le développement du serveur a soulevé un certain nombre de problèmes, ce qui a conduit à des études de faisabilité, qui sont expliquées dans le paragraphe IV. Les différents diagrammes sont donnés en annexe. I. L administration d EISMO L I.1. Présentation administration de EISMO est une application graphique. Elle doit couvrir toutes les couches du serveur, qu elle doit permettre de démarrer et d arrêter. Elle intègrera JRacer, de façon à pouvoir utiliser les services de Racer. Ses fonctions seront les suivantes : Démarrer et arrêter le serveur Racer Charger des ontologies à partir de fichiers locaux ou distants Démarrer et arrêter le serveur Jonas Démarrer et arrêter la console d administration de Jonas Afficher les ontologies ouvertes et les fermer Saisir les liens entre concepts Saisir les liens entre concepts et EJB Quitter EISMO Cette application est créée sous le nom de Serveur_EISMO. Il s agit d un projet conçu pour contenir des EJB et pouvoir évoluer vers une application Web. C est également une application multi threads, les serveurs étant lancés par des threads séparés. De plus, certaines méthodes font appel à des commandes système et utilisent des process pour gérer ces commandes système. D une manière générale, les attributs des classes sont privés et les méthodes publiques. Il existe des méthodes permettant d obtenir la valeur des attributs ou de la modifier. L utilisation du multi threads Pour pouvoir faire une application multi threads, les méthodes devant être appelées par un thread doivent être dans une classe héritant de Thread. Cette classe a alors une structure particulière : Elle contient obligatoirement une méthode run(), (public void run()). Cette méthode est appelée par la classe utilisatrice, et lance le thread. Elle contient les instructions à exécuter au lancement de la tâche. La classe utilisatrice doit créer un nouveau thread par un new thread, qui sera du type de la classe contenant la méthode run(). Puis elle lance le thread par la méthode start(). Exemple : la classe Racer hérite de Thread. Elle possède une méthode run() qui permet le démarrage de Racer. Elle est appelée par une méthode de la classe EISMO_Admin de la manière suivante : Thread racer = new Racer(). Cette commande crée un nouveau thread de type Racer racer.start() Cette commande démarre le thread (appelle la méthode run()). Projet EISMO Page 22 sur 50

23 L utilisation de process L exécution d une commande système se fait par l intermédiaire de la commande exec(), à laquelle on passe la commande à exécuter en paramètres. Exemple : Process p = Runtime.getRuntime ().exec(«racer»). Lorsque l on veut arrêter un process, on utilise la commande destroy (exemple p.destroy()). I.2. L architecture Elle contient 1 package nommé administration dans lequel se trouvent les différentes classes nécessaires à l administration du système, 1 package JRacer contenant les classes utiles à la communication avec Racer. Les fenêtres ne contiennent que les parties graphiques et les appels de méthodes. Toutes les méthodes utilisées dans ces fenêtres sont contenues dans des classes spécifiques. Le package coreservices est utilisé par l administrateur, dans certaines opérations telles que la création des liens. Figure 6 : diagramme de classes simplifié du package administration Projet EISMO Page 23 sur 50

24 I.3. Le développement des différentes classes L étude menée sur le serveur Racer amène à certaines conventions en matière de programmation : Un fichier sera associé à une connexion à Racer Un objet RacerClient ne contiendra qu un seul fichier. Ces règles sont très importantes, car Racer ne communique avec l extérieur que par le moyen de l objet RacerClient, qui est une connexion. Dans le cas ou plusieurs ontologies sont ouvertes par le même objet RacerClient, Racer ne travaillera que sur le dernier fichier ouvert. a La fenêtre GUI_Admin C est la fenêtre principale de l application. Elle contient la méthode main(). Elle présente à l utilisateur tous les boutons et affichages nécessaires à l administration du serveur. Le clic sur un bouton de cette fenêtre appelle une méthode contenue dans la classe EISMO_Admin. Figure 7 : fenêtre administration b La classe EISMO_Admin Cette classe contient pratiquement toutes les méthodes du serveur appelées par GUI_Admin. Elle permet l appel des méthodes servant à arrêter et démarrer les 2 serveurs, la gestion de Projet EISMO Page 24 sur 50

25 l ouverture et de la fermeture des fichiers. Elle appelle également les méthodes permettant la saisie des différents liens. Elle a différents attributs, permettant de conserver la liste des ontologies ouvertes et des connexions à Racer associées, ainsi qu une instance de la classe OntoManager qui permet la saisie des liens. c La classe RacerConnection Elle hérite de RacerClient. Elle a en attributs l adresse du serveur et le port sur lequel se connecter. Elle permet de créer une connexion à Racer, de l ouvrir et de la fermer. d La classe Racer Cette classe hérite de Thread. En effet, Racer est lancé par une commande système en mode DOS et s arrête dès la fin de la tâche. Il est donc indispensable de recourir à une tâche indépendante qui restera active jusqu à ce qu on la tue volontairement. Sa méthode run () contient le code nécessaire au démarrage de Racer. Elle utilise un process qui permettra d arrêter le serveur, car l arrêt du serveur se fait par l arrêt du thread (lorsque on utilise Racer à partir d une console DOS, l arrêt se fait par fermeture de la fenêtre). e La classe Jonas Cette classe hérite elle aussi de Thread, comme la classe Racer. Elle permet de démarrer et d arrêter le serveur JOnAS. Elle utilise deux process : un premier assurant le démarrage de JOnAS, grâce à la commande jonas start, le second s occupe de l arrêt avec la commande jonas stop. f La classe JonasAdmin Elle hérite elle aussi de Thread. Elle permet de démarrer la console d administration de JOnAS en utilisant la commande jonasadmin dans un process. L arrêt se fait par la commande destroy. Le démarrage intègre le démarrage d un navigateur Internet, car cette console se connecte en mode http à Jonas. Il faut lui passer en paramètres l adresse du serveur (IP ou nom) ainsi que le port. g La classe Filtre La fenêtre GUI_Admin offre la possibilité d ouvrir un fichier (ontologie). Cette ouverture de fichier se fait par l intermédiaire d un composant standard Java : JFileChooser. La classe filtre hérite de FileFilter. Elle contient les 2 méthodes accept() et getdescription(). JFileChooser : Celui-ci permet de chercher dans l arborescence du disque ou du réseau un fichier à ouvrir. Une possibilité de filtrer les fichiers que l on affiche existe. Elle fait appelle à une classe qui doit hériter de la classe javax.swing.filechooser.filefilter. Elle doit impérativement contenir les 2 méthodes accept() et getdescription(). La classe GUI_Admin appelle le constructeur de Filtre pour créer un nouveau filtre, en lui passant en paramètres une description du fichier filtré et l extension. Par exemple : Projet EISMO Page 25 sur 50

26 Filtre filtre_owl = new Filtre( Fichier OWL, owl ) permettra d afficher les fichiers avec l extension owl, et de mettre dans le menu déroulant des choix Fichier OWL. Cette classe Filtre est instanciée autant de fois que l on veut sélectionner d extensions possibles. h La classe KB_Manager Cette classe est destinée à gérer l ouverture et la fermeture des ontologies. Sur demande de la classe EISMO_Admin, elle crée une connexion à Racer (par l intermédiaire de la classe RacerConnection) i Les classes TreeEJB et TreeSP Ces deux classes permettent la saisie des liens entre concepts (TreeSP) ou entre concepts et EJB (TreeEJB). Elles sont réalisées selon le même principe. Elles sont découpées en 3 parties verticales : la partie gauche permettant l affichage d un arbre source, la partie droite d un arbre destination et la partie centrale permettant l affichage des liens entre ces 2 arbres grâce à des lignes. Ces 2 classes font appel à la classe JTree de Java. JTree Cette classe permet de représenter une hiérarchie sous la forme d un arbre. Elle crée des nœuds, qui peuvent contenir des nœuds ou des éléments. Il existe toujours un nœud racine (root) ayant des enfants. Ex : Les enfants peuvent avoir ou non des enfants. Un JTree ne contient pas les données, mais en est simplement une représentation. Projet EISMO Page 26 sur 50

27 Figure 8 : Fenêtre permettant la saisie des liens entre concepts de 2 ontologies Pour le stockage des liens, un vecteur contient le nom source (côté gauche de la fenêtre), un second vecteur contient la destination (côté droit de la fenêtre). Ces deux noms occupent les mêmes positions dans leurs vecteurs respectifs. Un clic sur le bouton "Terminer" de la classe TreeEJB appelle la méthode de la classe EJBManager qui permet de sauvegarder ces liens dans un fichier xml. Cette classe EJBManager fait partie du package coreservices. Pour la classe TreeSP, un clic sur "Terminer" appelle le constructeur de la classe SemanticMapper, classe du package coreservices. Cet appel s effectue en passant en paramètres les vecteurs contenant les noms source et destination, ainsi que les noms des deux ontologies concernées. II. Le package coreservices II.1. Présentation Ce package est destiné à la gestion des données partagées avec les clients du serveur. Par exemple, il crée et met à jour des fichiers XML contenant des informations qui pourront être récupérées par le client grâce à un parseur. II.2. L architecture Ce package est constitué de 5 classes, dont certaines sont appelées uniquement par des classes du package administration. Elles permettent le stockage et le partage des données. Projet EISMO Page 27 sur 50

28 Figure 9 : Diagramme de classes simplifié du package coreservices II.3. Les différentes classes a La classe EJBManager L'objectif de cette classe est de lister les EJB présents sur le serveur ainsi que les concepts utilisés par ces EJB. Elle est appelée par la classe TreeEJB, qui fait partie du package administration. Lors de cet appel, elle appelle elle-même le constructeur de la classe ExploreEJB, ce qui lui permettra la mise à jour de la liste des méthodes. EJBManager cherche dans le répertoire contenant les EJB (le répertoire ejbjars de Jonas) la liste des archives jar et extrait des ces archives les noms des EJB, qu'elle renvoie à TreeEJB. Cette dernière, après un clic sur son bouton "Terminer", fait appel à la méthode d'écriture dans le fichier XML de EJBManager, en lui passant en paramètres le nom de l'ontologie, ainsi que les deux vecteurs contenant les liens entre EJB et concepts. Ce fichier est réalisé de la façon suivante (voir figure 10): Son nom est créé à partir du nom de l ontologie. Par exemple, si l on veut créer des liens entre les concepts de DW et les EJB, le fichier s appellera DWEJB.XML Une balise fichier permet de stocker le nom du fichier, le second étant systématiquement EJB Ensuite, une balise nature permet d identifier le type de lien Une balise concept qui permet de stocker le nom du concept Une balise EJB qui permet de stocker le nom de l EJB <?xml version="1.0" encoding="iso "?> <Document> <fichier namesource="dwv1" namedestination="ejb"> <lien nature="utilise"> <concept name="( )"/> <EJB name="mapping/mappingejb.class"/> </lien> <lien nature="utilise"> <concept name="( )"/> <EJB name="conceptmanager/getconceptsejb.class"/> </lien> </fichier> </Document> Figure 10 : fichier XML contenant les liens entre les concepts d une ontologie et les EJB Projet EISMO Page 28 sur 50

29 b La classe ExploreEJB Elle permet la création d un fichier XML contenant pour chaque EJB la liste des méthodes qu il contient. Elle est appelée de plusieurs manières : au démarrage du serveur, afin de rechercher tous les EJB présents et de mettre à jour le fichier, soit par l administrateur après qu il ait déployé de nouveaux EJB, soit par la classe EJBManager. Ce fichier, nommé "Methodes.xml", contient la liste des EJB déployés et des méthodes qu ils contiennent. La constitution de ce fichier est la suivante (voir figure 11): Une première balise ejb donnant le nom de l EJB (package.nomejb) Puis autant de balises méthodes que de méthodes trouvées dans cet EJB (le nom d une méthode comprend le type de retour de la méthode ainsi que tous les paramètres qui devront lui être passées, avec également leur type) <?xml version="1.0" encoding="iso "?> <Document> <ejb name="codemethodes.getcodemethodes"> <methode name = "public abstract java.util.vector codemethodes.getcodemethodes.getcode(java.lang.string,java.lang.string) throws java.rmi.remoteexception" /> <methode name = "public abstract boolean javax.ejb.ejbobject.isidentical(javax.ejb.ejbobject) throws java.rmi.remoteexception" /> </ejb> </Document> Figure 11 : Extrait du fichier Methodes.xml c La classe OntoManager Cette classe permet de stocker dans un fichier XML nommé "Onto.xml", la liste des ontologies ouvertes sur le serveur Racer et les concepts contenus par chacune. Il est construit en associant à une balise fichier autant de balises concepts qu il y en a dans l ontologie concernée (voir figure 12). Ce fichier est créé dès l ouverture de la première ontologie sur le serveur, et mis à jour à chaque opération d ouverture ou de fermeture de fichiers. <?xml version="1.0" encoding="iso "?> <Document> <fichier name="dwv1.xmi"> <concept name = "( )" /> <concept name = "( )" /> </fichier> <fichier name="ediv1.xmi"> <concept name = "( )" /> <concept name = "( )" /> </fichier> </Document> Figure 12 : le fichier Onto.XML Projet EISMO Page 29 sur 50

30 d La classe SemanticMapper Son but est de stocker les liens créés par l administrateur entre les concepts contenus dans les différentes ontologies (par exemple, l équivalence de 2 concepts). Ces liens sont également sauvegardés dans un fichier XML. Le fichier XML est réalisé ainsi (voir figure 13) : Son nom est créé à partir des noms des deux fichiers, séparés par le caractère "#". Par exemple, dans le cas de EDI et de DW le fichier s appellera "EDI#DW.XML". Une balise fichier permet de stocker le nom des deux fichiers (namesource et namedestination pour les noms des 2 fichiers) Ensuite, une balise nature permet d identifier le type de lien (le lien utilisé actuellement est un lien d équivalence, mais on peut ajouter d autres types tels que l inclusion, etc.) Enfin, une balise concept qui permet de stocker les noms des concepts (le premier correspond au premier fichier, le second au 2 ème fichier). <?xml version="1.0" encoding="iso "?> <Document> <fichier namesource="dwv1" namedestination="ediv1"> <lien nature="equivalence"> <concept name="( )"/> <concept name="( )"/> </lien> </fichier> </Document> Figure 13 : extrait du fichier XML contenant les liens entre concepts de 2 ontologies III. Les EJB L es EJB permettent à un client de se connecter à EISMO et de récupérer les données stockées dans le serveur. Ils assurent la connexion et l appel des méthodes par le client qui veut utiliser EISMO. Ces EJB ont pour but de fournir à ce client le code d EJB utilisés par les Systèmes d Information dont les diagrammes de classes sont ouverts par le serveur. EISMO comprend 5 EJB lui permettant de réaliser ces opérations : OuvreXML getconcept EJBRecherche getmethodes getcodemethodes Ces 5 EJB sont tous contenus dans le package components du serveur. Ils sont tous du type Session Statefull. La plupart des EJB de EISMO utilise un parseur XML, et en particulier SAX. Projet EISMO Page 30 sur 50

31 Parseur XML Un parseur XML permet la lecture et l'exploitation d'un document XML. Les 2 parseurs les plus couramment utilisés sont SAX et DOM. Dans l'application EISMO, c'est SAX qui sera utilisé. SAX est basé sur un modèle évènementiel, c'est-à-dire qu il déclenche un évènement à chaque fois qu il rencontre une balise. SAX impose d utiliser une classe héritant de DefaultHandler, et qui implémente les méthodes suivantes : startdocument qui marque le début du document enddocument marque la fin du document startelement permet de traiter les balises ouvrantes du fichier endelement permet de traiter les balises fermantes characters traite les données présentes entre 2 balises. III.1. Les différents EJB du serveur a OuvreXML Cet EJB, faisant partie du package info, est appelé par le client dès le lancement. Il permet de récupérer la liste des ontologies ouvertes sur le serveur ainsi que les concepts correspondants. Il contient 2 méthodes que le client peut appeler : extraitfichiers et extraitconcepts. La première fait appel à un parseur XML, et utilise la classe InfoHandler, qui permet de parser le fichier nommé «Onto.XML». Du fichier XML, elle extrait la liste des fichiers ouverts sur le serveur ainsi que, par fichier, les concepts utilisés. b getconcept Cet EJB du package conceptmanager permet de récupérer, pour un concept donné, la liste des concepts ayant un lien avec celui-ci. Il propose à son client une seuls méthode, nommée getconceptsequivalents et qui lui retourne la liste de tous les concepts équivalents à celui passé en paramètre. Comme le précédent, il utilise un parseur XML, qui va traiter tous les fichiers XML contenant des liens entre concepts. c EJBRecherche Son objectif est la recherche des EJB utilisant le concept passé en paramètre. Il présente une méthode au client : getlisteejb, qui retourne la liste des EJB, qui retourne la liste des EJB contenant le concept passé en paramètre. Il utilise SAX pour parser les fichiers contenant les liens entre les EJB et les concepts. C est la classe EJBHandler qui est chargée de cette recherche. d getmethodes Il offre une méthode, nommée getmethods, et qui retourne au client la liste des méthodes de l EJB passé en paramètre. Cette méthode utilise un parseur XML pour récupérer la liste des méthodes de l EJB, qui se trouve dans un fichier XML (Methodes.XML) qui contient la liste de toutes les méthodes des EJB. La classe MethodeHandler prend cette opération en charge. Projet EISMO Page 31 sur 50

32 e getcodemethodes Il ne contient qu une seule méthode, getcode, qui retourne le code de la méthode sélectionnée par le client et passée en paramètre. Il utilise les services de la classe LectureFichier, qui prend en charge l ouverture, la lecture et la recherche de la méthode sélectionnée dans le fichier source de l EJB sélectionné. III.2. L installation et le déploiement Les EJB propres au serveur EISMO se trouvent dans le package components de l application, et chacun dans son propre package. Une fois leur code écrit, il faut compiler ces EJB et les installer dans le bon répertoire. Ces EJB faisant partie du serveur, les archives les contenant seront stockées dans un répertoire particulier de Jonas : le répertoire Autoload, qui permet de les déployer de manière automatique au démarrage de Jonas, sans aucune intervention de l administrateur. Pour les autres EJB, c'est-à-dire ceux appartenant aux différents SI, une procédure d installation et de déploiement doit être respectée rigoureusement par l administrateur. Cette procédure est la suivante : Tout d abord, lors de l installation du serveur, il faut créer le répertoire Serveur_EISMO dans le répertoire d installation de Jonas (C:\JonAS \Serveur_EISMO), puis un sous répertoire nommé src. Dans ce dernier, il faut copier le fichier build.xml qui se trouve dans le répertoire lib du projet EISMO. Copier les packages complets contenant les sources des différents EJB dans le répertoire src. Ouvrir une console dos, aller dans le répertoire Serveur_EISMO\src et taper la commande ant find build.xml install. Cette commande lance la compilation et l installation des EJB, qu elle va placer dans le répertoire ejbjars de Jonas. Une fois ces opérations terminées, l administrateur n a plus qu à déployer ces EJB grâce à la console d administration de Jonas qu il peut lancer grâce à la fenêtre d administration du serveur EISMO. IV. C Etudes de faisabilité ertaines fonctionnalités du serveur ont été sources de problèmes à résoudre, comme par exemple la transformation de diagramme de classes en ontologies. Des études de faisabilité ont donc été menées pour trouver des solutions viables à ces problèmes. IV.1. La transformation de diagrammes de classes en ontologies Les objectifs de cette transformation sont : Utiliser des schémas UML existants pour créer les ontologies utilisées dans le projet Définir le processus et les logiciels utilisés pour transformer un schéma UML en ontologie Vérifier que les ontologies créées ainsi sont utilisables par Racer. a Le principe de cette transformation Au départ, il faut créer le diagramme de classes UML, à l aide d un logiciel. Puis il faut exporter ce schéma au format XMI (possibilité offerte par de nombreux logiciels, type Projet EISMO Page 32 sur 50

33 ArgoUML). Il faut enfin effectuer la transformation du fichier XMI en un fichier utilisable par Racer. Il est donc prévu d utiliser ArgoUML pour réaliser les diagrammes, et un programme annoncé sur le site de Racer permettant d effectuer la transformation. b Les problèmes rencontrés Le programme annoncé sur le site Internet demeure introuvable, et il existe peu d applications de ce type sur Internet, et les quelques programmes trouvés ne fonctionnent pas toujours sur notre machine. De plus, avec certains programmes, il faut utiliser des versions très précises de XMI, qui ne sont pas générées par ArgoUML. c La solution retenue Il existait alors deux possibilités pour résoudre ce problème : soit développer une nouvelle application, soit trouver une application qui fonctionne et arriver à générer la bonne version de fichier XMI. Or développer une nouvelle application aurait été trop long et le délai n aurait pas été respecté. Sur le plan technique, l étude de faisabilité a consisté à essayer des applications trouvées sur Internet, et de définir les versions de fichier XMI compatibles. Nous avons finalement trouvé une application qui faisait cette conversion, mais qui ne fonctionnait pas correctement. Cette application possédait une feuille de style XSLT, que nous avons utilisé avec le logiciel Microsoft MSxsl. Cette feuille de style impose d utiliser un fichier XMI version 1.1 ou 1.2, avec au départ un diagramme réalisée avec une version UML 1.4. Or ArgoUML travaille avec UML 1.3 et génère un fichier XMI 1.0. En revanche, le logiciel Poséidon génère les bonnes versions. C est donc ce logiciel qui a été utilisé. d L'utilisation par l'application EISMO Une fois le schéma UML réalisé à l aide du logiciel Poséidon, et le fichier XMI généré par ce logiciel, c est le serveur qui effectue la transformation de façon automatique. Dans la classe KB_Manager, l extension du fichier à ouvrir est contrôlée. S il s agit d un fichier XMI, on appelle une méthode, nommée XmiToOwl, qui lance MSxsl dans un process, en lui passant en paramètres la feuille xslt et le nom du fichier (avec le chemin). Il est alors transformé en un fichier OWL. IV.2. La recherche des EJB du serveur et de leurs méthodes Le problème consiste ici à trouver les EJB qui sont déployés et les méthodes qui les composent. Cette recherche doit être entièrement automatisée, car elle est le but même de tout le projet. Les EJB déployés sont stockés dans un répertoire très précis, sous forme d'archives jar. Il s'agit donc ici d'extraire de ces archives les noms des EJB et de chercher dans le code source les méthodes. a La recherche des EJB dans Jonas Pour connaître les EJB présents, il va falloir extraire des archives différents fichiers. Java permet de réaliser cette extraction grâce à une classe spécifique, la classe JarFile. Cette classe Projet EISMO Page 33 sur 50

34 propose des méthodes permettant de lister et de filtrer le contenu d'une archive. Cette recherche se déroule selon plusieurs étapes: La première étape consiste à créer une url, en lui passant comme paramètre le chemin complet du fichier cherché (dans notre cas, C:\JonAS-4.0.0\ejbjars\nom du fichier). Ensuite, il faut créer une instance de JarURLConnection en appliquant à l'url précédemment créée la méthode openconnection. On peut alors appliquer à celle-ci la méthode getjarfile, qui retourne un objet de type JarFile A cet objet, il suffit d'appliquer la méthode entries qui, elle, retourne une énumération. Cette énumération est le contenu de l'archive. Chaque élément de cette énumération doit être modifié en String pour être exploitable par le filtre On applique alors un filtre permettant de ne récupérer que les fichiers voulus, dont la liste sera stockée dans un vecteur. b La recherche des méthodes des EJB Maintenant que nous avons trouvé les EJB déployés et récupéré la liste de leurs noms, le second problème qui se pose est de pouvoir obtenir les méthodes qui les composent, ainsi que le code de ces méthodes. Pour accéder au code de ces méthodes, il y a un impératif auquel il est difficile de déroger: il faut avoir les fichiers source. Une convention a donc du être définie: le code source de chaque EJB est stocké dans le répertoire C:\JonAS-4.0.0\Serveur_EISMO\src. C'est à partir de ce répertoire, qui contient le fichier build.xml, que seront compilés les EJB à déployer sur le serveur. Pour trouver les méthodes, nous allons utiliser la classe reflect.method, ainsi que la classe Class. Celle-ci, grâce à sa méthode "forname", à laquelle on passe en paramètre une String représentant dans notre cas le nom d'une classe d'un EJB, retourne un objet associé à la classe de même nom. On peut alors appliquer à cet objet une méthode nommée "getmethods", qui retourne un tableau de méthodes, qu'il est ensuite aisé d'exploiter. Ce tableau contient, pour chaque méthode, un prototype complet, c'est-à-dire: Visibilité: public, protected ou private Modificateurs: abstract, static, etc. Le type de retour: void, int, etc. Le nom de la méthode La liste des arguments (type et nom). IV.3. La connexion du client et le partage des données L e client est installé sur une machine distante: il va donc s appuyer sur un protocole distant pour utiliser les services d EISMO : RMI. C est ce protocole qui est à la base du fonctionnement des EJB du serveur. Ces EJB sont physiquement installés dans le serveur d application (JonAS) du serveur EISMO et appelés par le client. Ils permettent de partager les méthodes implémentées sur le serveur entre plusieurs clients distants. Projet EISMO Page 34 sur 50

35 Figure 14 : principe de RMI En revanche, ils ne permettent pas le partage de données. En effet, même si les EJB et tout le reste du code sont dans le même projet, ils ne sont pas exécutés sur la même machine virtuelle Java, et ne peuvent donc partager aucune donnée. Ce problème peut être résolu de deux manières : soit par l utilisation de bases de données, soit par l utilisation de fichiers. Compte tenu de la nature des données et des liens existant entre elles, et de leur quantité relativement peu importante, l utilisation de fichiers XML parait appropriée. Ces fichiers sont créés, mis à jour et éventuellement détruits par les différentes classes de la couche coreservices. Ils sont ensuite, à la demande du client, exploités par les EJB du serveur. EISMO KB Server EISMO core-services Applications ressources provider Applications Integrator Ecriture Knowledge Manager Ecriture Plateforme J2EE (JOnAS) EJB Containe Lecture Données Skeleton Stub Client Figure 15 : processus de mise à jour et d utilisation des fichiers Il existe plusieurs fichiers xml dans le serveur. Certains d entre eux n existent que pendant le temps où le serveur est actif, car leur contenu est très lié à l utilisation du serveur. C est le cas du fichier Onto.xml, qui ne dépend que des fichiers ouverts. D autres, au contraire, sont conservés après l arrêt du serveur, car ils contiennent des informations qui évoluent peu. C est le cas des fichiers contenant les liens entre concepts, ou entre concepts et EJB, ou celui contenant la liste des méthodes des EJB. Projet EISMO Page 35 sur 50

36 M L'IMPLENTATION DU CLIENT aintenant que le serveur est développé, et que tous les composants de ce serveur sont installés, il faut créer l'application cliente qui va permettre à un développeur de se connecter au serveur et d'utiliser les services que lui propose ce dernier. I. Présentation Le client est une application graphique comportant plusieurs fenêtres: une première fenêtre, contenant le main, s'ouvre au lancement de l'application. Elle permettra la connexion au serveur, l'affichage des ontologies ouvertes, l'affichage des concepts et des EJB. Une fois les sélections effectuées et validées, une nouvelle fenêtre s'ouvrira, contenant la liste des méthodes de l'ejb sélectionné précédemment. Enfin, la sélection d'une méthode et le clic sur le bouton permettront l'ouverture d'une fenêtre contenant le code de la méthode. Cette application est créée sous le nom de "Client_EISMO". II. L'architecture Cette application ne contient qu'un unique package, nommé client. Ce package contient 8 classes Comme pour le package administration du serveur, les fenêtres ne contiennent que les parties graphiques et les appels de méthodes. Toutes les méthodes utilisées dans ces fenêtres sont contenues dans des classes spécifiques. Figure 16: Diagramme de classes simplifié du client Projet EISMO Page 36 sur 50

37 III. Le développement des différentes classes a La fenêtre Fenetre_Client C'est la fenêtre principale de l'application. Elle contient la méthode main(), et présente à l'utilisateur tous les boutons et affichages qui lui permettent d'effectuer ses différentes sélections. A l'ouverture, cette fenêtre appelle le constructeur de la classe Client, qui contient les méthodes. Figure 17 : La fenêtre du client (lancement de l application) b La classe Client Cette classe contient la plupart des méthodes utilisées par la classe précédente. Cette classe va notamment, de manière entièrement automatique, instancier l'ejb OuvreXML, qui permet de récupérer la liste des ontologies ouvertes sur le serveur, ainsi que les concepts de chacune d'entre elles. Son constructeur va également appeler le constructeur de la classe AffichageEJB, qui va lui permettre de récupérer la liste des EJB avec les concepts qu'ils utilisent. c La classe AffichageEJB Cette classe fournit à la classe Client des connexions au serveur. Elle instancie 2 EJB, getconcepts et EjbRecherche, qui permettent respectivement de récupérer la liste des Projet EISMO Page 37 sur 50

38 concepts équivalents à celui passé en paramètre et la liste des EJB ayant un lien avec ces concepts. d La classe Fenetre_EJB Il s'agit d'une nouvelle fenêtre, qui est ouverte à chaque fois que l'utilisateur clique sur le bouton CodeEJB. Cette fenêtre permet l'affichage de la liste des méthodes de l'ejb sélectionné. Figure 18 : Fenêtre affichant la liste des méthodes de l EJB sélectionné e La classe Methodes Son constructeur est appelé en même temps que la fenêtre précédente. Cette classe utilise l'ejb getmethodes pour récupérer la liste des méthodes de l'ejb sélectionné et la retourner à Fenêtre_EJB. f La classe CodeMethodes Appelée en même temps que la classe fenêtre_code à chaque clic de l'utilisateur sur le bouton "Valider" de Fenêtre_EJB, cette classe se charge de récupérer le code de la méthode sélectionnée dont le nom lui est passé en paramètre. Projet EISMO Page 38 sur 50

39 g La fenêtre Fenetre_Code Cette fenêtre est donc appelée avec la classe CodeMethodes. Elle permet l'affichage du code de la méthode sélectionné, mais aussi de saisir du texte (c'est-à-dire de modifier le code affiché) et de l'enregistrer. La sauvegarde se fait via un JFileChooser, associé à la classe Filtre, qui permet de choisir un nom de fichier ainsi que le répertoire où le sauvegarder. Figure 19 : Fenêtre affichant le code de la méthode sélectionnée h La classe Filtre Elle hérite de JFileChooser.FileFilter et permet de sélectionner l'extension souhaitée. Projet EISMO Page 39 sur 50

40 PERSPECTIVES ET CONCLUSIONS I. Perspectives Un certain nombre d évolutions peuvent être apportées à l application. Elles concernent notamment l automatisation des tâches de saisie des liens entre concepts, qui peuvent très probablement être réalisées directement par Racer. Cette application peut également évoluer vers une application Web, plus simple à mettre en œuvre du côté client, car accessible simplement par un navigateur. L utilisation d une base de données pourrait également être envisagée pour gérer la persistance dans le cas où un grand nombre de SI serait utilisés. II. Conclusions Ces cinq mois de stage ont été pour moi l occasion de mettre en pratique certaines connaissances théoriques, notamment en développement. J ai eu la chance d avoir un sujet suffisamment vaste et intéressant, qui m a permis de toucher à différentes technologies, telles que les bases de connaissances, les serveurs d application et les technologies Java. J ai également pu accomplir différents travaux d étude et de recherche de solutions aux différents problèmes posés par le développement de cette application, et mettre en œuvre ces solutions. J ai particulièrement apprécié la grande autonomie dont j ai pu bénéficier, qui m a permis d évoluer considérablement dans le développement, ainsi que la confiance qui m a été accordée, et la qualité de l encadrement qui ne s est jamais relâché, du début à la fin. Projet EISMO Page 40 sur 50

41 ANNEXES I. ANNEXE 1 : Diagramme de classes du SI Data Warehouse Projet EISMO Page 41 sur 50

42 II. ANNEXE 2 : Diagramme de classes du SI EDI Projet EISMO Page 42 sur 50

43 III. ANNEXE 3 : Diagramme de classes du serveur Projet EISMO Page 43 sur 50

44 IV. ANNEXE 4 : Diagramme de classes du package administration Projet EISMO Page 44 sur 50

45 V. ANNEXE 5 : Diagramme de classes du package coreservices Projet EISMO Page 45 sur 50

46 VI. ANNEXE 6: Diagramme de classes du client Projet EISMO Page 46 sur 50

47 VII. Annexe 7 : Diagramme des Cas d'utilisation Projet EISMO Page 47 sur 50

48 VIII. ANNEXE 8: Diagramme de séquences de l'administrateur Projet EISMO Page 48 sur 50

49 IX. ANNEXE 9: Diagramme de séquences du client Projet EISMO Page 49 sur 50

50 X. BIBLIOGRAPHIE est le site officiel de Sun pour télécharger Java mais aussi trouver toute la documentation nécessaire pour tout ce qui touche à Java et aux serveurs J2EE. Serveurs de bases de connaissance: fournit toutes les informations sur Racer ainsi que des liens vers des sites fournissant des applications et de la documentation. est l'équivalent du précédent pour fact. Serveurs d'applications: est le site officiel du consortium fournissant le serveur Jonas. pour les comparatifs entre serveurs d'applications publiés Développement: site sur lequel on trouve des références bibliographiques, des cours, des forums. est l'équivalent du précédent Divers: est le site du projet exff qui a été utilisé pour la transformation de diagrammes de classes en ontologies. site du W3C (World Wide Web Consortium) site indispensable pour xml, mais aussi les langages de description et les ontologies. pour ses publications sur différents thèmes Projet EISMO Page 50 sur 50