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

(1)

Projet EISMO Page 1 sur 50

Année 2003/2004

Conception et Implémentation d’un serveur d’applications Conception et Implémentation d’un serveur d’applications Conception et Implémentation d’un serveur d’applications Conception et Implémentation d’un serveur d’applications

dans le cadre du projet EISMO dans le cadre du projet EISMO dans le cadre du projet EISMO 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: M. Rami RIFAIEH

Membres : M. Mohamed OU-HALIMA (Responsable du Mastère Informatique)

MASTERE SPECIALISE EN INFORMATIQUE

L Y O N

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

(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é ... 10

TECHNOLOGIES MISES EN ŒUVRE ... 12

I. La couche KB Server ... 12

I.1. Logique de description et langages ... 12

I.2. Etude de faisabilité : choix du serveur ... 13

I.3. Utilisation et comportement de Racer ... 13

I.4. Utilisation de JRacer ... 14

II. La plateforme J2EE ... 15

II.1. Choix du serveur ... 16

II.2. Installation et utilisation de Jonas ... 17

II.3. Les EJB ... 17

SCENARIO... 20

I. Les Systèmes d’Information utilisés ... 20

II. Le déroulement du scénario ... 20

II.1. L’administrateur et le serveur... 20

II.2. Le client... 20

L’IMPLEMENTATION DU SERVEUR EISMO ... 22

I. L’administration d’EISMO... 22

I.1. Présentation... 22

I.2. L’architecture ... 23

I.3. Le développement des différentes classes... 24

II. Le package coreServices ... 27

II.1. Présentation... 27

II.2. L’architecture ... 27

II.3. Les différentes classes... 28

III. Les EJB ... 30

III.1. Les différents EJB du serveur ... 31

III.2. L’installation et le déploiement... 32

IV. Etudes de faisabilité ... 32

IV.1. La transformation de diagrammes de classes en ontologies... 32

IV.2. La recherche des EJB du serveur et de leurs méthodes... 33

IV.3. La connexion du client et le partage des données ... 34

(4)

L'IMPLENTATION DU CLIENT ... 36

I. Présentation ... 36

II. L'architecture ... 36

III. Le développement des différentes classes ... 37

PERSPECTIVES ET CONCLUSIONS ... 40

I. Perspectives... 40

II. Conclusions ... 40

ANNEXES ... 41

I. ANNEXE 1 : Diagramme de classes du SI Data Warehouse... 41

II. ANNEXE 2 : Diagramme de classes du SI EDI... 42

III. ANNEXE 3 : Diagramme de classes du serveur... 43

IV. ANNEXE 4 : Diagramme de classes du package administration ... 44

V. ANNEXE 5 : Diagramme de classes du package coreServices... 45

VI. ANNEXE 6: Diagramme de classes du client ... 46

VII. Annexe 7 : Diagramme des Cas d'Utilisation ... 47

VIII. ANNEXE 8: Diagramme de séquences de l'administrateur ... 48

IX. ANNEXE 9: Diagramme de séquences du client... 49

X. BIBLIOGRAPHIE... 50

(5)

INTRODUCTION

I. Contexte du projet EISMO

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

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 :

L

S

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

(7)

Projet EISMOPage 7 sur 50 Figure 1

EISMO Server KB

EISMO Ontology Description Logic

Server Reasoning System

(Inference Engine) KB Server Interface

Applications ressources provider

Query Resolver EJB Creator / dispatcher

Pattern Designer

Applications Integrator

Model Integrator Ontology Integrator

Schema Generator

Knowledge Manager Ontology Manager Ambiguity Resolver Semantic Interoperability

Manager

Admin.

EISMO Core Services

J2EE Platform

EJB Container Distant Objects Access Security

Transactions

service JSP Container

Data Bases Access

S.I.

Clients

Data Bases

(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

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)

ON1 ON2

Admin

ON 1

ON 2

Fichier XML : Liens entre

concepts

Serveur KB

Couche Core Services Gestion des Ontologies :

Ontologies ouvertes Concepts de ces ontologies

Couche J2EE Moteur

Conteneur EJB

RMI

ON1 ON2

Valider

Concept1 Concept2 Concept3 Valider

EJB1 EJB2 EJB3

Valider Fichiers XML : Liens entre EJB et concepts, liste des ontologies ouvertes, Liste des EJB

CLIENT

Gestion des EJB EJB déployés Concepts utilisés Méthodes

(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

Fenêtre Principale

Méthode affichage EJB du serveur Méthode affichage Méthodes EJB Méthode affichage code EJB Tests

31/05Juin07/0614/0621/0628/06Juillet05/0712/0719/0726/0702/08Août09/0816/0823/0830/08Septembre06/0913/0920/0927/09Octobre04/1011/1018/10

III. Définitions

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.

Q

(10)

Projet EISMO Page 10 sur 50 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)

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 individus, etc. Elle peut également être modélisée par un schéma UML.

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

(11)

Projet EISMO Page 11 sur 50 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.

(12)

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)

L

(13)

Projet EISMO Page 13 sur 50 RDF et RDFS

Ces langages ont une syntaxe respectant le standard XML OWL

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 http://www.sts.tu-harburg.de/~r.f.moeller/racer/download.html 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.

(14)

;;; RACER Version 1.7.19

;;; RACER: Reasoner for Aboxes and Concept Expressions Renamed

;;; Supported description logic: ALCQHIr+(D)-

;;; 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

;;; http://wilbur-rdf.sourceforge.net/.

;;; 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 http://alamos.math.arizona.edu/~rychlik/.

;;; 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

;;; http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html.

[2004-08-10 14:33:43] HTTP service enabled for: http://127.0.0.1:8080/

[2004-08-10 14: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.

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

N

(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 & 1.4.1 NON 1.2 NON Tous

JBoss 1.3.1 & 1.4.1 2 1.2 1.0.2 Tous

JOnAS 1.3.1 & 1.4.1 2 1.2 1.1 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.

(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 http://ant.apache.org) BCEL, qui est une librairie nécessaire à Ant pour compiler (que l’on récupère sur le site http://jakarta.apache.org).

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)

(18)

Projet EISMO Page 18 sur 50 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.

Les EJB Message Driven

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.

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

(20)

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

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

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.

E D

P

(21)

Projet EISMO Page 21 sur 50 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é.

(22)

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

L

(23)

Projet EISMO Page 23 sur 50 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

(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

(25)

Projet EISMO Page 25 sur 50 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 :

(26)

Projet EISMO Page 26 sur 50 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.

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

(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-8859-15"?>

<fichier nameSource="DWv1"

nameDestination="EJB">

</lien>

</lien>

</fichier>

</Document>

Figure 10 : fichier XML contenant les liens entre les concepts d’une ontologie et les EJB

(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)

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

</fichier>

</fichier>

</Document>

Figure 12 : le fichier Onto.XML

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

<fichier nameSource="DWv1"

nameDestination="EDIv1">

</lien>

</fichier>

</Document>

Figure 13 : extrait du fichier XML contenant les liens entre concepts de 2 ontologies

III. Les EJB

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.

L

(31)

Projet EISMO Page 31 sur 50 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.

(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- 4.0.0\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. 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

C

(33)

Projet EISMO Page 33 sur 50 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