Vous êtes sur la page 1sur 50

L Y O N

MASTERE SPECIALISE EN INFORMATIQUE


Anne 2003/2004

Conception et Implmentation dun serveur dapplications


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 Mastre Informatique)

Projet EISMO

Page 1 sur 50

REMERCIEMENTS

Avant dentrer dans le droulement de mon stage, je tiens particulirement remercier Nabila
Benharkat et Rami Rifaieh. Tout au long de ces cinq mois de stage, ils ont su me laisser un
grand degr dautonomie, tout en suivant de trs prs lavancement du projet et les difficults
que je rencontrais. Jai apprci leur disponibilit ainsi que laide quils ont su m'
apporter ou
me trouver lorsque jen ai eu besoin.
Je tiens galement remercier tous les gens de lINSA qui ont, dune manire ou dune autre,
contribu au bon droulement de mon stage (administrateurs, tudiants du Liris).
Je voudrais enfin remercier Patricia Varet, pour tous les problmes d'
ordre administratif
qu'
elle a pu m'
viter ou rgler tout au long de l'
anne.

Projet EISMO

Page 2 sur 50

SOMMAIRE
REMERCIEMENTS ................................................................................................................. 2
SOMMAIRE .............................................................................................................................. 3
INTRODUCTION ..................................................................................................................... 5
I.
II.

Contexte du projet EISMO ..................................................................................................... 5


Prsentation du projet EISMO ............................................................................................... 5

II.1.
II.2.
II.3.
II.4.
II.5.

III.

III.1.
III.2.

Objectifs du projet........................................................................................................................... 5
Etude de Faisabilit ......................................................................................................................... 6
Implmentation ............................................................................................................................... 6
Principe du serveur et le scnario de ltude de cas ........................................................................ 8
Les tapes du projet......................................................................................................................... 9

Dfinitions............................................................................................................................. 9
Dfinition dune ontologie .............................................................................................................. 9
Dfinition dune tude de faisabilit ............................................................................................. 10

TECHNOLOGIES MISES EN UVRE ............................................................................... 12


I.

II.

La couche KB Server ............................................................................................................. 12

I.1.
I.2.
I.3.
I.4.

Logique de description et langages ............................................................................................... 12


Etude de faisabilit : choix du serveur .......................................................................................... 13
Utilisation et comportement de Racer ........................................................................................... 13
Utilisation de JRacer ..................................................................................................................... 14

La plateforme J2EE ............................................................................................................... 15

II.1.
II.2.
II.3.

Choix du serveur ........................................................................................................................... 16


Installation et utilisation de Jonas ................................................................................................. 17
Les EJB ......................................................................................................................................... 17

SCENARIO.............................................................................................................................. 20
I.
II.

Les Systmes dInformation utiliss ..................................................................................... 20


Le droulement du scnario .................................................................................................. 20

II.1.
II.2.

Ladministrateur et le serveur........................................................................................................ 20
Le client......................................................................................................................................... 20

LIMPLEMENTATION DU SERVEUR EISMO ................................................................. 22


I.

II.

Ladministration dEISMO................................................................................................... 22

I.1.
I.2.
I.3.

Prsentation ................................................................................................................................... 22
Larchitecture ................................................................................................................................ 23
Le dveloppement des diffrentes classes..................................................................................... 24

Le package coreServices ........................................................................................................ 27

II.1.
II.2.
II.3.

Prsentation ................................................................................................................................... 27
Larchitecture ................................................................................................................................ 27
Les diffrentes classes................................................................................................................... 28

III.

Les EJB ............................................................................................................................... 30

IV.

Etudes de faisabilit ........................................................................................................... 32

III.1.
III.2.
IV.1.
IV.2.
IV.3.

Les diffrents EJB du serveur ....................................................................................................... 31


Linstallation et le dploiement..................................................................................................... 32

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


La recherche des EJB du serveur et de leurs mthodes ................................................................. 33
La connexion du client et le partage des donnes ......................................................................... 34

Projet EISMO

Page 3 sur 50

L'IMPLENTATION DU CLIENT ......................................................................................... 36


I.

Prsentation ............................................................................................................................ 36

II.

L'architecture ......................................................................................................................... 36

III.

Le dveloppement des diffrentes 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 squences de l'administrateur .......................................... 48

IX.

ANNEXE 9: Diagramme de squences du client............................................................. 49

X.

BIBLIOGRAPHIE ................................................................................................................. 50

Projet EISMO

Page 4 sur 50

INTRODUCTION
I.

Contexte du projet EISMO

es Systmes dInformation, ainsi que les Bases de Donnes, sont de plus en plus prsents
dans les entreprises. Leurs besoins de communication et dchanges de donnes ne
cessent de crotre, en mme temps que leur utilisation. Ces changes ncessitent une certaine
interoprabilit entre les systmes, qui doivent pouvoir interprter et transmettre des
informations ou des requtes. Mais ces systmes sont dvelopps dans des environnements
trs htrognes (langages de programmation, bases de donnes, matriel sont totalement
htroclites). De plus, un mme systme ou des systmes semblables peuvent avoir des
reprsentations diffrentes, lorigine de nombreuses difficults dans la communication. En
effet, comment savoir que plusieurs modles reprsentent en ralit en ralit le mme objet ?
Par exemple, ce problme de multi reprsentation 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 premire rponse ces problmes a t trouve sur les plans physique et syntaxique, avec
le dveloppement de technologies telles que CORBA, Java, XML, etc. Mais elles ne rsolvent
quune partie du problme, celle des langages de programmation et de la communication,
laissant entire celle de la multi reprsentation.
Le projet EISMO (Enterprise Information System Multi representation Ontology) propose
une rponse ce problme de multi reprsentation : lutilisation des ontologies.

II. Prsentation du projet EISMO

I un Systme dInformation ou une Base de Donnes est reprsent par un modle (un
schma UML par exemple pour un SI), il peut aussi ltre par une ontologie. Cette
dernire sera facilement utilisable par plusieurs systmes et applications. EISMO se propose
dutiliser ce concept afin de rsoudre le problme dinteroprabilit.
EISMO est un projet de recherche, qui a pour but de dfinir une plateforme pour la
coopration des Systmes dInformation dEntreprises.

II.1.

Objectifs du projet

Lobjectif majeur de ce projet est de valider le modle conceptuel propos pour solutionner le
problme de la multi reprsentation en sappuyant sur une tude de cas, qui permettrait
galement dexplorer les impacts sur la rutilisabilit et le partage dinformations. Un second
objectif vise fournir une comprhension globale des Systmes dInformation dEntreprise
afin de pouvoir amliorer la communication.
Il sagit donc de construire une reprsentation ontologique partage pour tous les Systmes
dInformation dEntreprise, en gardant lesprit deux buts fondamentaux : la rutilisabilit et
linteroprabilit.
Ce projet comprend deux parties essentielles :
Projet EISMO

Page 5 sur 50

Une tude de faisabilit

Limplmentation du serveur

II.2.

Etude de Faisabilit

Une tude de faisabilit permettra de slectionner les technologies utiliser et de dfinir la


manire dimplmenter le serveur EISMO. Cette tude de faisabilit portera sur les serveurs
utiliser (serveur dapplication et de bases de connaissances), sur les diffrents services offerts
par ce serveur et leurs composants.
Elle sera mene en parallle lavancement du projet, au dbut de chaque tape du
dveloppement.
Cette tude vise :
Dune part dmontrer la faisabilit globale du projet, sur un plan technique mais
aussi en termes de planning.
Dautre part dfinir non seulement les composants mais aussi les modes opratoires
et les conditions de ralisation.
Enfin elle permettra de chercher des solutions chaque problme rencontr, qui
peuvent tre ventuellement des solutions de rechange en cas dimpossibilit
technique.

II.3.

Implmentation

En termes informatiques, EISMO repose sur une plateforme J2EE et une conception
"ontologique" des Systmes dInformation. Il conjugue lutilisation dun langage de
programmation (Java), dun langage terminologique, dun serveur de bases de connaissances
et dun serveur dapplications.
Il est constitu de 3 couches :

Une premire couche base sur une implmentation J2EE, constitue dun serveur
dapplications et reposant sur larchitecture Java. Cette couche permet un client de se
connecter au systme.

Une seconde couche, que nous appellerons "Core Services". Cette couche contient les
diffrents services offerts aux clients. Elle sera entirement dveloppe.

La troisime couche est le serveur de Bases de Connaissance, qui sera charg de la


gestion des ontologies. Elle permettra notamment de charger des ontologies en
mmoire, et de leur passer des requtes.

Une interface administrateur permettra de grer ce serveur EISMO. Elle devra tre
entirement dveloppe. Elle permettra de dmarrer les serveurs dapplications et de Bases de
Connaissances, de charger des ontologies dans le serveur ou directement des diagrammes de
classes UML de Systmes dInformation
Enfin, une interface client permettra ce dernier de se connecter au serveur et dy effectuer
les oprations offertes par celui-ci, et implmentes dans "Core Services".
Cette architecture est prsente de manire simplifie sur la figure 1 et sera dveloppe dans
les chapitres suivants.

Projet EISMO

Page 6 sur 50

Projet EISMO

EISMO
KB
Server

EISMO
Core
Services
Figure 1

J2EE
Platform

EISMO Ontology

Description Logic
Server

Reasoning System
(Inference Engine)

Applications ressources
provider

Applications Integrator

Query Resolver

Model Integrator

EJB Creator / dispatcher

Ontology Integrator

Pattern Designer

Schema Generator

EJB Container

Distant Objects
Access

Transactions
service

KB Server
Interface

Knowledge Manager
Ontology Manager
Ambiguity Resolver
Semantic Interoperability
Manager

JSP Container
Data Bases
Access

Security

Page 7 sur 50

Data Bases
Clients
S.I.

Admin.

II.4.

Principe du serveur et le scnario de ltude de cas

Le but du serveur est de fournir un dveloppeur des mthodes prises dans des Systmes
dInformation existants, mais slectionnes partir dun concept contenu dans un de ces S.I.
La couche KB Server contiendra des ontologies, qui sont en ralit les diagrammes de classes
de ces SI, et qui contiennent des concepts.
Notre dveloppeur cherchera obtenir, pour concevoir sa nouvelle application, des mthodes
dj codes, 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 mthodes rpondant
ces critres. Le principe est dcrit dans la figure 2
ON1

Admin

O
N
1

O
N
2

Fichier XML :
Liens entre
concepts

ON2

Serveur
KB

Moteur

Gestion des Ontologies :


Ontologies ouvertes
Concepts de ces
ontologies

Gestion des EJB


EJB dploys
Concepts utiliss
Mthodes

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

Conteneur EJB

Couche
Core Services

Couche
J2EE

RMI

ON1
ON2

Valider

Concept1
Concept2
Concept3

EJB1
EJB2
EJB3

Valider

Valider

CLIENT

Figure 2 : le principe du serveur EISMO

Ltude de cas permettra de mettre en application ce serveur en utilisant deux SI : Data


Warehouse et EDI, dont les diagrammes de classes sont donns en annexes 1 et 2. Le scnario
est dcrit en dtail dans le chapitre qui lui est consacr (voir page 20)
Projet EISMO

Page 8 sur 50

II.5.

Les tapes du projet

La ralisation de ce serveur EISMO se droulera en plusieurs tapes qui consisteront tudier


et choisir les diffrents composants, tels que les serveurs de bases de connaissance et
dapplications, et dvelopper les applications et services ncessaires :
Etude de faisabilit, choix et installation du serveur de Bases de Connaissances
Etude de faisabilit, choix et installation du serveur dapplications
Dveloppement des classes ncessaires la communication avec le serveur de Bases
de Connaissances
Etudes de faisabilit portant sur limportation de schmas UML dans le serveur de
Bases de Connaissances
Etude de faisabilit portant sur lutilisation des EJB et le dveloppement de ces EJB
Dveloppement de linterface administrateur
Dveloppement de la couche Core Services aprs tude de faisabilit.
Le planning :
Nom de la tche

Juin
Juillet
Aot
Septembre
Octobre
31/05
07/06
14/06
21/06
28/06
05/07
12/07
19/07
26/07
02/08
09/08
16/08
23/08
30/08
06/09
13/09
20/09
27/09
04/10
11/10
18/10

Apprentissage logique de description


Dveloppement serveur
Dveloppement administration
Dveloppement com avec Racer
Dveloppement admin
Dveloppement core Services
Etudes de faisabilit
Codage classes
Dveloppement des EJB
Dveloppement Application Client
Fentre Principale
Mthode affichage EJB du serveur
Mthode affichage Mthodes EJB
Mthode affichage code EJB
Tests

III.

Dfinitions

termes et notions utiliss dans le projet sont dfinis de faon assez sommaire dans
Quelques
ce paragraphe, mais de manire dfinir la faon dont elles sont traites ou utilises tout

au long de cette tude.

III.1.

Dfinition dune ontologie

Il sagit dune dfinition trs sommaire car elle pourrait faire lobjet de nombreuses pages et
ne constitue pas lobjet du projet EISMO. Dans ce projet, nous nous bornerons utiliser
certaines "fonctionnalits" des ontologies.
Ontologie : du latin Ontologia : Thorie de ltre.
Projet EISMO

Page 9 sur 50

Une ontologie dfinit les termes utiliss


pour dcrire et reprsenter un champ
d'
expertise. Les ontologies sont utilises
par les personnes, les bases de donnes, et
les applications qui ont besoin de partager
des informations relatives un domaine
bien spcifique, comme la mdecine, la
fabrication d'
outils, l'
immobilier, la
rparation d'
automobiles, la gestion de
finances, etc. Les ontologies associent les
concepts de base d'
un domaine prcis et les
relations entre ces concepts, tout cela d'
une
manire comprhensible 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 rutilisables.
(Source : W3C)

Une ontologie est une conceptualisation


formelle du monde.
Elle permet didentifier et de modliser les
concepts dun domaine ainsi que les
relations conceptuelles. Elle permet
galement de se mettre daccord sur les
termes employs. Par exemple, les termes
chat, matou, minet, etc. dsignent tous la
mme chose. En revanche, des termes
identiques peuvent reprsenter des choses
totalement diffrentes (par exemple, le mot
bureau peut tre utilis soit pour la pice,
soit pour le meuble). Lontologie permettra
de dfinir une formalisation afin de lever
toute ambigut.
Elle peut utiliser des langages appropris,
appels logique de description et manipule
de nombreuses notions tels que les
concepts, les individus, les relations entre

individus, etc. Elle peut galement tre modlise par un schma UML.
Elle est constitue essentiellement de concepts et de liens entre concepts, qui peuvent tre, par
exemple, des liens dgalit ou dappartenance. Une ontologie est peuple dindividus, qui
appartiennent un ou plusieurs concepts, ces individus constituant les donnes de cette base.

III.2.

Dfinition dune tude de faisabilit

Il parait important de bien dfinir au dpart ce que lon attend dune tude de faisabilit. En
rgle gnrale, ses buts sont de vrifier si un projet peut tre ralis et de suggrer des
solutions alternatives ralistes, l'
objectif final tant pour un dcideur de lancer ou d'
arrter le
projet.
Dune manire gnrale, les critres tudier sont les suivants :
L'
organisation du systme actuel s'
il existe
Les problmes rencontrs
Les objectifs d'
un nouveau systme
Les contraintes
Les alternatives possibles.
Les conclusions tirer de cette tude sont :
Faisabilit du projet
Alternative retenue
Elle fait apparatre 4 points importants :
Faisabilit oprationnelle: explore l'
urgence du projet et l'
acceptabilit de
chaque solution.
Faisabilit technique: le projet est-il ralisable dans les limites de la
technologie actuelle? Est-ce que qu'
il est ralisable en respectant les contraintes
lies aux ressources?
Faisabilit en termes de planning: la solution est-elle ralisable dans les dlais
Faisabilit conomique: le projet est-il raliste, compte tenu des contraintes
budgtaires? Quels bnfices vont en rsulter? Quels sont les cots de
dveloppement et de dploiement
Projet EISMO

Page 10 sur 50

Dans le cadre du projet EISMO, nous ne tiendrons pas compte de laspect oprationnel. En
effet, il sagit dun projet de recherche, qui vise valider une architecture, donc une solution.
Le critre conomique sera un lment important, le budget tant trs faible. En revanche,
aucun bnfice financier ntant attendu de ce projet, ce critre sera ignor.
La partie technique de cette tude consistera valider larchitecture technique et choisir les
composants logiciels (serveurs, langages, etc.), le tout dans la dure du stage, c'
est--dire cinq
mois.

Projet EISMO

Page 11 sur 50

TECHNOLOGIES MISES EN UVRE

architecture du serveur EISMO est donc constitue de 3 couches (voir figure 1). Ces
couches devront communiquer les unes avec les autres par lintermdiaire de divers
programmes et interfaces, mais galement permettre des clients de lapplication dutiliser les
diffrents services proposs par EISMO.

I.

La couche KB Server

Cette couche est base sur un serveur de Base de Connaissances. Elle contient :
la ou les ontologies utilises par le serveur
le systme terminologique avec sa logique descriptive et son moteur
dinfrence.
linterface avec les autres couches.

I.1.

Logique de description et langages

La logique de description est une reprsentation des connaissances. Cest un modle orient
objets. Elle fait intervenir les notions de concept, de rle, dindividu.

a Quelques dfinitions
Concept : reprsentation mentale gnrale et abstraite dun objet (Le Petit Robert).
Dans le domaine de la modlisation informatique, on a besoin de reprsenter une situation en
termes de :
Objets
Classes
Relations (ou associations)
La logique de description est conue pour reprsenter une situation en termes de :
Objets
Classes, qui sont appeles concept dans ces logiques de description
Relations appeles rles.
Rle : relation binaire entre individus
Individu : ce sont les donnes de la base
Tbox : contient la terminologie (peut tre compar au diagramme de classes dun SI)
Abox : contient les individus (peut tre compare aux donnes dun SI)
Relation de subsomption : consiste organiser les concepts par niveau de gnralit. U
concept A subsume B si lensemble des individus reprsents par B est inclus dans lensemble
des individus de A : A est plus gnral que B

b Langages
Les langages utiliss par les serveurs de Bases de Connaissances sont bass sur la logique de
description. Il existe plusieurs langages :
DAML+ OIL (Darpa Agent Markup Language + Ontology Inference Layer)
Projet EISMO
Page 12 sur 50

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 rpondent 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 prsentent des fonctionnalits similaires.
Fact sappuie sur une architecture Corba, tandis que Racer est bas sur une architecture RMI.
Les deux serveurs ncessitent peu de ressources : ils peuvent tre installs sur un PC de
bureau.
Corba tant un peu plus lourd mettre en uvre, et racer disposant dune interface crite en
Java (JRacer) permettant une utilisation trs simple dans le cadre de notre projet, le choix
sest port sur Racer

I.3.

Utilisation et comportement de Racer

a Installation et dmarrage
Linstallation de Racer est trs simple : il suffit de tlcharger sur le site Internet
http://www.sts.tu-harburg.de/~r.f.moeller/racer/download.html et de dcompresser un fichier
nomm "racer.exe". Le serveur est alors prt fonctionner.
On peut le dmarrer de deux manires : soit par un double clic sur le fichier "racer.exe", soit
en ouvrant une console et en tapant la commande racer. Au dmarrage, Racer naffiche que
les quelques informations de la figure 3.
Il est intressant de noter quil supporte les protocoles TCP et http.
Lorsque lon dmarre le serveur, aucune ontologie nest charge en mmoire.

Projet EISMO

Page 13 sur 50

;;; RACER Version 1.7.19


;;; RACER: Reasoner for Aboxes and Concept Expressions Renamed
;;; Supported description logic: ALCQHIr+(D);;; Copyright (C) 1998-2004, 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
;;; 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 dontologies
Il existe plusieurs formats de fichiers utilisables par Racer : "racer", ".daml", ".rdfs", ".owl".
Les formats de ces fichiers correspondent au langage utilis.
Louverture dune ontologie peut se faire de plusieurs faons :
Lorsque lon dmarre 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 dmarrer Racer, et se connecter au serveur via le port TCP pour
ouvrir le fichier, soit par lintermdiaire dune interface graphique, soit grce une
application permettant de se connecter et douvrir des fichiers.
Ces fichiers peuvent tre ouverts localement (ils sont sur un disque dur de la machine), soit
sur un rseau (Internet ou rseau local). Racer utilise alors le protocole http. Plusieurs fichiers
peuvent ainsi tre ouverts. En revanche, une requte ne portera que sur une seule ontologie, la
dernire ouverte.

I.4.

Utilisation de JRacer

Dans notre application, nous allons implmenter JRacer. Il sagit dun ensemble de classes
dveloppes en Java et contenant toutes les mthodes ncessaires la connexion, la cration
et linterrogation des ontologies.
Projet EISMO

Page 14 sur 50

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 utilises : la classe RacerClient et la classe


RacerException. En effet, ces deux classes permettent de grer la connexion, les requtes
ainsi que les exceptions gnres.

b Comment utiliser JRacer ?


Avant de pouvoir ouvrir un fichier ou dinterroger une ontologie, il faut crer une connexion
au serveur. Il faut instancier la classe RacerClient (par la commande new) en passant en
paramtres au constructeur ladresse IP de la machine (ou son nom) ainsi que le port TCP
(8088 par dfaut, mais ce numro de port est configurable). Il faut ensuite ouvrir la connexion
par la commande openConnection() applique lobjet cr prcdemment. La connexion est
alors ralise.
Pour ouvrir un fichier, on appliquera cet objet une des mthodes de JRacer. Par exemple, si
lobjet RacerClient cr prcdemment sappelle 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
requtes permises par Racer (exemple : obtenir la liste des concepts de lontologie).
Lorsque lon na plus besoin de ce client, il faut le fermer par la commande close.

II.

La plateforme J2EE

otre application tant une application distribue, un serveur dapplications 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 donnes et
contenir des conteneurs EJB.
Un serveur dapplications est constitu dun ensemble de services et dAPI permettant
lhbergement dapplications distribues.
Projet EISMO

Page 15 sur 50

Figure 4 : Architecture J2EE

Parmi les serveurs dapplication du march les plus connus, trois ont t retenus sur le critre
du cot :
Tomcat
JBoss
JOnAS (Java Open Application Server)

II.1.

Choix du serveur

Tomcat
JBoss
JOnAS

JDK
1.3 & 1.4.1
1.3.1 & 1.4.1
1.3.1 & 1.4.1

EJB
NON
2
2

JSP
1.2
1.2
1.2

JMS
NON
1.0.2
1.1

OS
Tous
Tous
Tous

JBoss a t dvelopp par Jboss Inc. (Matrix Partners, accel Partners, Intel)
JOnAS a t dvelopp par WebObject (Bull, France Tlcom, INRIA, puis Red Hat en 2003
et maintenant Apache )
Remarque : JBoss et JonAS intgrent tous les deux Tomcat.
Tomcat nintgre pas les services lis aux EJB, et ne peut donc pas tre utilis seul.
JBoss et Jonas sont quivalents pour notre application sur le plan des fonctionnalits
offertes.
Divers comparatifs parus sur Internet font apparatre que JOnAS est plus performant
en charge et mieux document que JBoss.
Le choix du serveur dapplications sest donc port sur JOnAS.
Projet EISMO

Page 16 sur 50

II.2.

Installation et utilisation de Jonas

Avant dinstaller JOnAS, il faut avoir install :


Java J2SE
Ant, qui est un make bas sur Java ( tlcharger sur http://ant.apache.org)
BCEL, qui est une librairie ncessaire Ant pour compiler (que lon rcupre
sur le site http://jakarta.apache.org).
Sur le site dObjectWeb, on trouve plusieurs variantes de JOnAS : JOnAS seul, JOnAS et
Tomcat, JOnAS et Jetty. La version utilise dans EISMO est JOnAS + Tomcat.
Aprs avoir dcompress et lanc le programme dinstallation, il faut configurer les variables
denvironnement.
Le lancement de Jonas se fait par la commande jonas start, larrt par jonas stop. Aprs le
dmarrage, la console dadministration est accessible par la commande jonasAdmin.

II.3.

Les EJB

Les EJB (ou Enterprise Java Beans) sont des composants serveur distribus crits en Java. Ce
sont en fait des objets distants utilisant RMI/IIOP, qui est un mlange entre la syntaxe de RMI
et le protocole de communication utilis par Corba, ce qui permet de garantir que ces objets
pourront tre utiliss quelque soit le code client. Celui-ci aura recours au service JNDI (Java
Naming and Directory Interface) pour localiser ces objets distants.
Le dveloppeur dun EJB naura pratiquement soccuper que de laspect mtier de son
application. En effet, la plateforme J2EE sur laquelle ils seront dploys gre les services
systme tels que la scurit, les transactions, les messages, etc.

a Catgories dEJB
Il existe 3 catgories dEJB :
Les EJB "Session", qui sont utiliss pour reprsenter les donnes et les
comportements qui leur sont associs.
Les EJB "Entity" qui permettent la reprsentation de donnes persistantes
ayant une existence au niveau dun support de stockage tel quune base de
donnes.
Les EJB "Message Driven" permettent la mise en uvre dapplications bases
sur le traitement de messages.
Les EJB Session :
Il existe 2 types dEJB Session : avec tat ("statefull") ou sans tat ("stateless")
"Statefull" : Ce type dEJB permet de maintenir en mmoire les donnes
utilises par le client. Il est donc utilisable par un client unique, et sera donc
instanci autant de fois quil y a de clients.
"Stateless" : Cet EJB ne maintient pas les donnes en mmoire, mais peut tre
utilis par plusieurs clients simultanment.
Les EJB Entity
Il existe galement de type dEntity Beans :
Les EJB de type CMP (Container Managed Persistance) dlguent au
conteneur la gestion de la persistance (le programmeur ne soccupe pas du
code JDBC)
Projet EISMO
Page 17 sur 50

Les EJB de type BMP (Bean Managed Persistance) prennent en charge laccs
aux bases de donnes. Dans ce cas, cest le programmeur qui crit le code
JDBC.
Les EJB Message Driven
Ces EJB sont sans tat et utilisent des messages asynchrones dlivrs par JMS (Java Message
Service). Ces messages asynchrones permettent des applications de communiquer en
changeant des messages de telle faon que le rcepteur est totalement indpendant de
lmetteur du message. Ainsi, lmetteur envoie son message et na pas besoin dattendre que
le rcepteur lait reu ou trait.

b Composition dun EJB


Un EJB est constitu dun minimum de 5 fichiers :
Une interface locale
Une interface distante
La classe dimplmentation de lEJB
Un descripteur de dploiement
Un descripteur de dploiement spcifique au serveur dapplications.
En plus de ces 5 fichiers, on peut trouver autant de classes que ncessaire au fonctionnement.
Linterface locale, galement appele interface de fabrique, qui permet la construction de
lEJB grce sa mthode create(). Cette interface hrite de EJBHome. Cest elle qui est
appele par le client.
Linterface distante, ou interface mtier, permet de dfinir les mthodes que va proposer
lEJB au client. Elle hrite de EJBObject.
La classe dimplmentation contient toutes les mthodes et les appels aux diffrentes classes
ncessaires. Elle hrite de SessionBean ou dEntityBean.
Les descripteurs de dploiement sont des fichiers xml. Ils contiennent toutes les informations
ncessaires pour le dploiement de lEJB. (Informations telles que le type de lEJB, son nom,
etc.). Ils sont au nombre de deux: un descripteur de dploiement gnral, qui contiendra toutes
les informations propres l'
EJB, et un descripteur propre au serveur d'
applications.

c Principe dutilisation
Aprs avoir crit le code de lEJB, il faut le compiler. Sa compilation va gnrer une archive
jar, cette archive portant le nom de lEJB. Au cours de cette compilation, un certain nombre
de fichiers sont gnrs, dont des fichiers particuliers qui sont le "stub" et le "skeleton". Ce
sont eux qui vont permettre lutilisation de lEJB. Ce sont ces deux fichiers qui permettent
lutilisation distante. Le serveur disposera du "skeleton", tandis que le client disposera du
"stub". Lors dun appel dun EJB par le client, cest en fait le "stub" qui va dialoguer avec le
"skeleton" du serveur.

Projet EISMO

Page 18 sur 50

Figure 5 : Stub et Skeleton

Pour mettre en uvre un EJB, il faudra copier dans lapplication cliente le "stub" ainsi que
linterface locale de lEJB, qui permettra au client de crer lEJB.

Projet EISMO

Page 19 sur 50

SCENARIO

ISMO est avant tout un prototype, dont le but principal est de dmontrer la rutilisabilit
des mthodes dun SI par un autre SI. Pour effectuer cette dmonstration, un scnario a
t tudi. Il consiste crire quelques mthodes dans des EJB, et faire utiliser ces mthodes
par un autre SI, qui traite dun sujet similaire. Mais cette rutilisation se fait travers le
serveur, qui met disposition du dveloppeur le code des mthodes existantes, et lui permet
de le modifier selon ses besoins et de recrer de nouveaux composants partir de ce code
existant.

I.

Les Systmes dInformation utiliss

ans ce scnario, on utilise deux SI diffrents. Ces deux systmes dinformation seront
modliss sous la forme de diagrammes de classes UML, puis, par un mcanisme intgr
au serveur, ces diagrammes seront transforms en ontologies utilisables par Racer. Les
diagrammes de classe de ces deux SI sont donns en Annexes 1 et 2. Ces deux applications
prsentent 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 trs proche,
sont modlises diffremment.

II.

Le droulement du scnario
II.1.

Ladministrateur et le serveur

our que le serveur EISMO puisse tre utilis par des clients, ladministrateur doit
auparavant avoir effectu quelques oprations. Celles-ci ont pour but de charger les
ontologies dans le serveur et de dfinir les liens existant entre ontologies ainsi quentre
ontologies et EJB. Le droulement de ces oprations est le suivant (voir diagrammes de
squences en annexes 8 et 9):
Ladministrateur dmarre le serveur EISMO
Il dmarre ensuite les serveurs Racer et Jonas
Il charge les schmas UML des Systmes dInformation
Il dploie les EJB si ceux-ci ne le sont pas.
Il dfinit les liens entre ces applications ainsi que les liens entre chaque application et
les EJB sils nont pas dj t dfinis.
Le serveur se charge du stockage des diffrents liens (entre ontologies, entre EJB et
concepts, etc.).

II.2.

Le client

Lorsque ces oprations sont termines, le dveloppeur peut alors utiliser le serveur. Pour cela,
il va procder ainsi :
Il dmarre lapplication cliente.
Celle-ci utilise un EJB qui permet, de faon automatique, la connexion au serveur
EISMO. Cet EJB retourne lapplication cliente la liste des ontologies ouvertes sur le
serveur. Cette application affiche cette liste.
Le dveloppeur choisit dans cette liste le fichier correspondant au SI sur lequel il
dsire travailler et valide son choix.
Projet EISMO

Page 20 sur 50

La liste des concepts utiliss est alors affiche dans la fentre client.
Le dveloppeur choisit alors un concept quil souhaite utiliser.
A cette tape, une recherche de tous les concepts quivalents doit tre effectue, puis
de tous les EJB utilisant au moins l'
un de ces concepts.
Le client rcupre cette liste d'
EJB et laffiche.
Le dveloppeur va ce moment pouvoir slectionner un EJB et obtiendra la liste des
mthodes contenues dans cet EJB.
Le dveloppeur peut enfin slectionner la mthode qui lintresse et rcuprer le code
de celle-ci, qui va s'
afficher dans une fentre o il pourra tre modifi avant d'
tre
sauvegard.

Projet EISMO

Page 21 sur 50

LIMPLEMENTATION DU SERVEUR EISMO

a premire phase de cette implmentation consiste installer et configurer les serveurs


Racer et Jonas sur la machine. Il faudra ensuite dvelopper les diffrents programmes de
lapplication : la partie administration du serveur et la partie client, ainsi que diffrents
composants de coreServices. Lapplication contiendra donc deux packages : le package
administration et le package coreServices. Le dveloppement se fera laide de
lenvironnement de dveloppement intgr Eclipse, qui est Open Source et dispose de
nombreux plugins. Le dveloppement du serveur a soulev un certain nombre de problmes,
ce qui a conduit des tudes de faisabilit, qui sont expliques dans le paragraphe IV.
Les diffrents diagrammes sont donns en annexe.

I.

Ladministration dEISMO
I.1.

Prsentation

administration de EISMO est une application graphique. Elle doit couvrir toutes les
couches du serveur, quelle doit permettre de dmarrer et darrter. Elle intgrera JRacer,
de faon pouvoir utiliser les services de Racer. Ses fonctions seront les suivantes :
Dmarrer et arrter le serveur Racer
Charger des ontologies partir de fichiers locaux ou distants
Dmarrer et arrter le serveur Jonas
Dmarrer et arrter la console dadministration 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 cre sous le nom de Serveur_EISMO. Il sagit dun projet conu pour
contenir des EJB et pouvoir voluer vers une application Web. Cest galement une
application multi threads, les serveurs tant lancs par des threads spars. De plus, certaines
mthodes font appel des commandes systme et utilisent des process pour grer ces
commandes systme.
Dune manire gnrale, les attributs des classes sont privs et les mthodes publiques. Il
existe des mthodes permettant dobtenir la valeur des attributs ou de la modifier.
Lutilisation du multi threads
Pour pouvoir faire une application multi threads, les mthodes devant tre appeles par un
thread doivent tre dans une classe hritant de Thread. Cette classe a alors une structure
particulire :
Elle contient obligatoirement une mthode run(), (public void run()). Cette mthode est
appele par la classe utilisatrice, et lance le thread. Elle contient les instructions excuter
au lancement de la tche.
La classe utilisatrice doit crer un nouveau thread par un new thread, qui sera du type de
la classe contenant la mthode run(). Puis elle lance le thread par la mthode start().
Exemple : la classe Racer hrite de Thread. Elle possde une mthode run() qui permet le
dmarrage de Racer. Elle est appele par une mthode de la classe EISMO_Admin de la
manire suivante :
Thread racer = new Racer(). Cette commande cre un nouveau thread de type Racer
racer.start() Cette commande dmarre le thread (appelle la mthode run()).
Projet EISMO

Page 22 sur 50

Lutilisation de process
Lexcution dune commande systme se fait par lintermdiaire de la commande exec(),
laquelle on passe la commande excuter en paramtres.
Exemple : Process p = Runtime.getRuntime ().exec( racer ).
Lorsque lon veut arrter un process, on utilise la commande destroy (exemple p.destroy()).

I.2.

Larchitecture

Elle contient 1 package nomm administration dans lequel se trouvent les diffrentes classes
ncessaires ladministration du systme, 1 package JRacer contenant les classes utiles la
communication avec Racer. Les fentres ne contiennent que les parties graphiques et les
appels de mthodes. Toutes les mthodes utilises dans ces fentres sont contenues dans des
classes spcifiques.
Le package coreServices est utilis par ladministrateur, dans certaines oprations telles que la
cration des liens.

Figure 6 : diagramme de classes simplifi du package administration

Projet EISMO

Page 23 sur 50

I.3.

Le dveloppement des diffrentes classes

Ltude mene sur le serveur Racer amne certaines conventions en matire de


programmation :
Un fichier sera associ une connexion Racer
Un objet RacerClient ne contiendra quun seul fichier.
Ces rgles sont trs importantes, car Racer ne communique avec lextrieur que par le moyen
de lobjet RacerClient, qui est une connexion. Dans le cas ou plusieurs ontologies sont
ouvertes par le mme objet RacerClient, Racer ne travaillera que sur le dernier fichier ouvert.

a La fentre GUI_Admin
Cest la fentre principale de lapplication. Elle contient la mthode main(). Elle prsente
lutilisateur tous les boutons et affichages ncessaires ladministration du serveur. Le clic
sur un bouton de cette fentre appelle une mthode contenue dans la classe EISMO_Admin.

Figure 7 : fentre administration

b La classe EISMO_Admin
Cette classe contient pratiquement toutes les mthodes du serveur appeles par GUI_Admin.
Elle permet lappel des mthodes servant arrter et dmarrer les 2 serveurs, la gestion de
Projet EISMO

Page 24 sur 50

louverture et de la fermeture des fichiers. Elle appelle galement les mthodes permettant la
saisie des diffrents liens. Elle a diffrents attributs, permettant de conserver la liste des
ontologies ouvertes et des connexions Racer associes, ainsi quune instance de la classe
OntoManager qui permet la saisie des liens.

c La classe RacerConnection
Elle hrite de RacerClient. Elle a en attributs ladresse du serveur et le port sur lequel se
connecter. Elle permet de crer une connexion Racer, de louvrir et de la fermer.

d La classe Racer
Cette classe hrite de Thread. En effet, Racer est lanc par une commande systme en mode
DOS et sarrte ds la fin de la tche. Il est donc indispensable de recourir une tche
indpendante qui restera active jusqu ce quon la tue volontairement.
Sa mthode run () contient le code ncessaire au dmarrage de Racer. Elle utilise un process
qui permettra darrter le serveur, car larrt du serveur se fait par larrt du thread (lorsque on
utilise Racer partir dune console DOS, larrt se fait par fermeture de la fentre).

e La classe Jonas
Cette classe hrite elle aussi de Thread, comme la classe Racer. Elle permet de dmarrer et
darrter le serveur JOnAS. Elle utilise deux process : un premier assurant le dmarrage de
JOnAS, grce la commande jonas start, le second soccupe de larrt avec la commande
jonas stop.

f La classe JonasAdmin
Elle hrite elle aussi de Thread. Elle permet de dmarrer la console dadministration de
JOnAS en utilisant la commande jonasAdmin dans un process. Larrt se fait par la
commande destroy.
Le dmarrage intgre le dmarrage dun navigateur Internet, car cette console se connecte en
mode http Jonas. Il faut lui passer en paramtres ladresse du serveur (IP ou nom) ainsi que
le port.

g La classe Filtre
La fentre GUI_Admin offre la possibilit
douvrir un fichier (ontologie). Cette
ouverture de fichier se fait par
lintermdiaire dun composant standard
Java : JFileChooser.
La classe filtre hrite de FileFilter. Elle
contient les 2 mthodes accept() et
getDescription().

JFileChooser : Celui-ci permet de


chercher dans larborescence du disque ou
du rseau un fichier ouvrir. Une
possibilit de filtrer les fichiers que lon
affiche existe. Elle fait appelle une classe
qui
doit
hriter
de
la
classe
javax.swing.filechooser.FileFilter. Elle doit
imprativement contenir les 2 mthodes
accept() et getDescription().

La classe GUI_Admin appelle le constructeur de Filtre pour crer un nouveau filtre, en lui
passant en paramtres une description du fichier filtr et lextension. Par exemple :
Projet EISMO
Page 25 sur 50

Filtre filtre_owl = new Filtre(Fichier OWL, owl) permettra dafficher les fichiers avec
lextension owl, et de mettre dans le menu droulant des choix Fichier OWL.
Cette classe Filtre est instancie autant de fois que lon veut slectionner dextensions
possibles.

h La classe KB_Manager
Cette classe est destine grer louverture et la fermeture des ontologies. Sur demande de la
classe EISMO_Admin, elle cre une connexion Racer (par lintermdiaire 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 ralises selon le mme principe. Elles sont dcoupes en 3 parties
verticales : la partie gauche permettant laffichage dun arbre source, la partie droite dun
arbre destination et la partie centrale permettant laffichage des liens entre ces 2 arbres grce
des lignes. Ces 2 classes font appel la classe JTree de Java.
JTree
Cette classe permet de reprsenter une hirarchie sous la forme dun arbre. Elle cre des
nuds, qui peuvent contenir des nuds ou des lments. Il existe toujours un nud racine
(root) ayant des enfants. Ex :

Les enfants peuvent avoir ou non des enfants. Un JTree ne contient pas les donnes, mais en
est simplement une reprsentation.

Projet EISMO

Page 26 sur 50

Figure 8 : Fentre permettant la saisie des liens entre concepts de 2 ontologies

Pour le stockage des liens, un vecteur contient le nom source (ct gauche de la fentre), un
second vecteur contient la destination (ct droit de la fentre). Ces deux noms occupent les
mmes positions dans leurs vecteurs respectifs.
Un clic sur le bouton "Terminer" de la classe TreeEJB appelle la mthode 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 seffectue en passant en paramtres les vecteurs contenant les noms
source et destination, ainsi que les noms des deux ontologies concernes.

II.

Le package coreServices
II.1.

Prsentation

Ce package est destin la gestion des donnes partages avec les clients du serveur. Par
exemple, il cre et met jour des fichiers XML contenant des informations qui pourront tre
rcupres par le client grce un parseur.

II.2.

Larchitecture

Ce package est constitu de 5 classes, dont certaines sont appeles uniquement par des classes
du package administration. Elles permettent le stockage et le partage des donnes.

Projet EISMO

Page 27 sur 50

Figure 9 : Diagramme de classes simplifi du package coreServices

II.3.

Les diffrentes classes

a La classe EJBManager
L'
objectif de cette classe est de lister les EJB prsents sur le serveur ainsi que les concepts
utiliss par ces EJB. Elle est appele par la classe TreeEJB, qui fait partie du package
administration. Lors de cet appel, elle appelle elle-mme le constructeur de la classe
ExploreEJB, ce qui lui permettra la mise jour de la liste des mthodes. EJBManager cherche
dans le rpertoire contenant les EJB (le rpertoire ejbjars de Jonas) la liste des archives jar et
extrait des ces archives les noms des EJB, qu'
elle renvoie TreeEJB. Cette dernire, aprs un
clic sur son bouton "Terminer", fait appel la mthode d'
criture dans le fichier XML de
EJBManager, en lui passant en paramtres le nom de l'
ontologie, ainsi que les deux vecteurs
contenant les liens entre EJB et concepts.
Ce fichier est ralis de la faon suivante (voir figure 10):
Son nom est cr partir du nom de lontologie. Par exemple, si lon veut crer des
liens entre les concepts de DW et les EJB, le fichier sappellera DWEJB.XML
Une balise fichier permet de stocker le nom du fichier, le second tant
systmatiquement EJB
Ensuite, une balise nature permet didentifier 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 lEJB
<?xml version="1.0" encoding="ISO-8859-15"?>
<Document>
<fichier nameSource="DWv1"
nameDestination="EJB">
<lien nature="Utilise">
<concept name="(|http://owl.from.uml#Mapping|)"/>
<EJB name="mapping/MappingEJB.class"/>
</lien>
<lien nature="Utilise">
<concept name="(|http://owl.from.uml#Entity|)"/>
<EJB name="conceptManager/getConceptsEJB.class"/>
</lien>
</fichier>
</Document>
Figure 10 : fichier XML contenant les liens entre les concepts dune ontologie et les EJB

Projet EISMO

Page 28 sur 50

b La classe ExploreEJB
Elle permet la cration dun fichier XML contenant pour chaque EJB la liste des mthodes
quil contient. Elle est appele de plusieurs manires : au dmarrage du serveur, afin de
rechercher tous les EJB prsents et de mettre jour le fichier, soit par ladministrateur aprs
quil ait dploy de nouveaux EJB, soit par la classe EJBManager.
Ce fichier, nomm "Methodes.xml", contient la liste des EJB dploys et des mthodes quils
contiennent.
La constitution de ce fichier est la suivante (voir figure 11):
Une premire balise ejb donnant le nom de lEJB (package.nomEJB)
Puis autant de balises mthodes que de mthodes trouves dans cet EJB (le nom dune
mthode comprend le type de retour de la mthode ainsi que tous les paramtres qui
devront lui tre passes, avec galement leur type)
<?xml version="1.0" encoding="ISO-8859-15"?>
<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 quil y en a dans
lontologie concerne (voir figure 12). Ce fichier est cr ds louverture de la premire
ontologie sur le serveur, et mis jour chaque opration douverture ou de fermeture de
fichiers.
<?xml version="1.0" encoding="ISO-8859-15"?>
<Document>
<fichier name="DWv1.xmi">
<concept name = "(|http://owl.from.uml#File|)" />
<concept name = "(|http://owl.from.uml#Aggregation|)" />
</fichier>
<fichier name="EDIv1.xmi">
<concept name = "(|http://owl.from.uml#Entity|)" />
<concept name = "(|http://owl.from.uml#Selection_stat|)" />
</fichier>
</Document>
Figure 12 : le fichier Onto.XML

Projet EISMO

Page 29 sur 50

d La classe SemanticMapper
Son but est de stocker les liens crs par ladministrateur entre les concepts contenus dans les
diffrentes ontologies (par exemple, lquivalence de 2 concepts). Ces liens sont galement
sauvegards dans un fichier XML.
Le fichier XML est ralis ainsi (voir figure 13) :
Son nom est cr partir des noms des deux fichiers, spars par le caractre "#". Par
exemple, dans le cas de EDI et de DW le fichier sappellera "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 didentifier le type de lien (le lien utilis
actuellement est un lien dquivalence, mais on peut ajouter dautres types tels que
linclusion, etc.)
Enfin, une balise concept qui permet de stocker les noms des concepts (le premier
correspond au premier fichier, le second au 2me fichier).
<?xml version="1.0" encoding="ISO-8859-15"?>
<Document>
<fichier nameSource="DWv1"
nameDestination="EDIv1">
<lien nature="Equivalence">
<concept name="(|http://owl.from.uml#Mapping|)"/>
<concept name="(|http://owl.from.uml#Mapping|)"/>
</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 rcuprer les donnes


stockes dans le serveur. Ils assurent la connexion et lappel des mthodes par le client
qui veut utiliser EISMO. Ces EJB ont pour but de fournir ce client le code dEJB utiliss par
les Systmes dInformation dont les diagrammes de classes sont ouverts par le serveur.
EISMO comprend 5 EJB lui permettant de raliser ces oprations :
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

Parseur XML
Un parseur XML permet la lecture et l'
exploitation d'
un document XML. Les 2 parseurs les
plus couramment utiliss sont SAX et DOM. Dans l'
application EISMO, c'
est SAX qui sera
utilis.
SAX est bas sur un modle vnementiel, c'
est--dire quil dclenche un vnement chaque
fois quil rencontre une balise. SAX impose dutiliser une classe hritant de DefaultHandler,
et qui implmente les mthodes suivantes :
startDocument qui marque le dbut 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 donnes prsentes entre 2 balises.

III.1.

Les diffrents EJB du serveur

a OuvreXML
Cet EJB, faisant partie du package info, est appel par le client ds le lancement. Il permet de
rcuprer la liste des ontologies ouvertes sur le serveur ainsi que les concepts correspondants.
Il contient 2 mthodes que le client peut appeler : extraitFichiers et extraitConcepts. La
premire 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 utiliss.

b getConcept
Cet EJB du package conceptManager permet de rcuprer, pour un concept donn, la liste des
concepts ayant un lien avec celui-ci. Il propose son client une seuls mthode, nomme
getConceptsEquivalents et qui lui retourne la liste de tous les concepts quivalents celui
pass en paramtre. Comme le prcdent, 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 paramtre. Il prsente une
mthode au client : getListeEJB, qui retourne la liste des EJB, qui retourne la liste des EJB
contenant le concept pass en paramtre. Il utilise SAX pour parser les fichiers contenant les
liens entre les EJB et les concepts. Cest la classe EJBHandler qui est charge de cette
recherche.

d getMethodes
Il offre une mthode, nomme getMethods, et qui retourne au client la liste des mthodes de
lEJB pass en paramtre. Cette mthode utilise un parseur XML pour rcuprer la liste des
mthodes de lEJB, qui se trouve dans un fichier XML (Methodes.XML) qui contient la liste
de toutes les mthodes des EJB. La classe MethodeHandler prend cette opration en charge.

Projet EISMO

Page 31 sur 50

e getCodeMethodes
Il ne contient quune seule mthode, getCode, qui retourne le code de la mthode slectionne
par le client et passe en paramtre. Il utilise les services de la classe LectureFichier, qui
prend en charge louverture, la lecture et la recherche de la mthode slectionne dans le
fichier source de lEJB slectionn.

III.2.

Linstallation et le dploiement

Les EJB propres au serveur EISMO se trouvent dans le package components de lapplication,
et chacun dans son propre package. Une fois leur code crit, il faut compiler ces EJB et les
installer dans le bon rpertoire. Ces EJB faisant partie du serveur, les archives les contenant
seront stockes dans un rpertoire particulier de Jonas : le rpertoire Autoload, qui permet de
les dployer de manire automatique au dmarrage de Jonas, sans aucune intervention de
ladministrateur.
Pour les autres EJB, c'
est--dire ceux appartenant aux diffrents SI, une procdure
dinstallation et de dploiement doit tre respecte rigoureusement par ladministrateur. Cette
procdure est la suivante :
Tout dabord, lors de linstallation du serveur, il faut crer le rpertoire
Serveur_EISMO dans le rpertoire dinstallation de Jonas (C:\JonAS4.0.0\Serveur_EISMO), puis un sous rpertoire nomm src. Dans ce dernier, il faut
copier le fichier build.xml qui se trouve dans le rpertoire lib du projet EISMO.
Copier les packages complets contenant les sources des diffrents EJB dans le
rpertoire src.
Ouvrir une console dos, aller dans le rpertoire Serveur_EISMO\src et taper la
commande ant find build.xml install. Cette commande lance la compilation et
linstallation des EJB, quelle va placer dans le rpertoire ejbjars de Jonas.
Une fois ces oprations termines, ladministrateur na plus qu dployer ces EJB
grce la console dadministration de Jonas quil peut lancer grce la fentre
dadministration du serveur EISMO.

IV.

Etudes de faisabilit

ertaines fonctionnalits du serveur ont t sources de problmes rsoudre, comme par


exemple la transformation de diagramme de classes en ontologies. Des tudes de
faisabilit ont donc t menes pour trouver des solutions viables ces problmes.

IV.1.

La transformation de diagrammes de classes en ontologies

Les objectifs de cette transformation sont :


Utiliser des schmas UML existants pour crer les ontologies utilises dans le projet
Dfinir le processus et les logiciels utiliss pour transformer un schma UML en
ontologie
Vrifier que les ontologies cres ainsi sont utilisables par Racer.

a Le principe de cette transformation


Au dpart, il faut crer le diagramme de classes UML, laide dun logiciel. Puis il faut
exporter ce schma au format XMI (possibilit offerte par de nombreux logiciels, type
Projet EISMO

Page 32 sur 50

ArgoUML). Il faut enfin effectuer la transformation du fichier XMI en un fichier utilisable par
Racer.
Il est donc prvu dutiliser ArgoUML pour raliser les diagrammes, et un programme annonc
sur le site de Racer permettant deffectuer la transformation.

b Les problmes rencontrs


Le programme annonc sur le site Internet demeure introuvable, et il existe peu dapplications
de ce type sur Internet, et les quelques programmes trouvs ne fonctionnent pas toujours sur
notre machine. De plus, avec certains programmes, il faut utiliser des versions trs prcises de
XMI, qui ne sont pas gnres par ArgoUML.

c La solution retenue
Il existait alors deux possibilits pour rsoudre ce problme : soit dvelopper une nouvelle
application, soit trouver une application qui fonctionne et arriver gnrer la bonne version
de fichier XMI. Or dvelopper une nouvelle application aurait t trop long et le dlai naurait
pas t respect.
Sur le plan technique, ltude de faisabilit a consist essayer des applications trouves sur
Internet, et de dfinir les versions de fichier XMI compatibles.
Nous avons finalement trouv une application qui faisait cette conversion, mais qui ne
fonctionnait pas correctement. Cette application possdait une feuille de style XSLT, que
nous avons utilis avec le logiciel Microsoft MSxsl.
Cette feuille de style impose dutiliser un fichier XMI version 1.1 ou 1.2, avec au dpart un
diagramme ralise avec une version UML 1.4. Or ArgoUML travaille avec UML 1.3 et
gnre un fichier XMI 1.0. En revanche, le logiciel Posidon gnre les bonnes versions.
Cest donc ce logiciel qui a t utilis.

d L'utilisation par l'application EISMO


Une fois le schma UML ralis laide du logiciel Posidon, et le fichier XMI gnr par ce
logiciel, cest le serveur qui effectue la transformation de faon automatique. Dans la classe
KB_Manager, lextension du fichier ouvrir est contrle. Sil sagit dun fichier XMI, on
appelle une mthode, nomme XmiToOwl, qui lance MSxsl dans un process, en lui passant
en paramtres 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 mthodes

Le problme consiste ici trouver les EJB qui sont dploys et les mthodes qui les
composent. Cette recherche doit tre entirement automatise, car elle est le but mme de tout
le projet.
Les EJB dploys sont stocks dans un rpertoire trs prcis, 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 mthodes.

a La recherche des EJB dans Jonas


Pour connatre les EJB prsents, il va falloir extraire des archives diffrents fichiers. Java
permet de raliser cette extraction grce une classe spcifique, la classe JarFile. Cette classe
Projet EISMO
Page 33 sur 50

propose des mthodes permettant de lister et de filtrer le contenu d'


une archive. Cette
recherche se droule selon plusieurs tapes:
La premire tape consiste crer une url, en lui passant comme paramtre le chemin
complet du fichier cherch (dans notre cas, C:\JonAS-4.0.0\ejbjars\nom du fichier).
Ensuite, il faut crer une instance de JarURLConnection en appliquant l'
url
prcdemment cre la mthode openConnection.
On peut alors appliquer celle-ci la mthode getJarFile, qui retourne un objet de type
JarFile
A cet objet, il suffit d'
appliquer la mthode entries qui, elle, retourne une numration.
Cette numration est le contenu de l'
archive.
Chaque lment de cette numration doit tre modifi en String pour tre exploitable
par le filtre
On applique alors un filtre permettant de ne rcuprer que les fichiers voulus, dont la
liste sera stocke dans un vecteur.

b La recherche des mthodes des EJB


Maintenant que nous avons trouv les EJB dploys et rcupr la liste de leurs noms, le
second problme qui se pose est de pouvoir obtenir les mthodes qui les composent, ainsi que
le code de ces mthodes.
Pour accder au code de ces mthodes, il y a un impratif auquel il est difficile de droger: il
faut avoir les fichiers source. Une convention a donc du tre dfinie: le code source de chaque
EJB est stock dans le rpertoire C:\JonAS-4.0.0\Serveur_EISMO\src. C'
est partir de ce
rpertoire, qui contient le fichier build.xml, que seront compils les EJB dployer sur le
serveur.
Pour trouver les mthodes, nous allons utiliser la classe reflect.Method, ainsi que la classe
Class. Celle-ci, grce sa mthode "forName", laquelle on passe en paramtre une String
reprsentant dans notre cas le nom d'
une classe d'
un EJB, retourne un objet associ la classe
de mme nom. On peut alors appliquer cet objet une mthode nomme "getMethods", qui
retourne un tableau de mthodes, qu'
il est ensuite ais d'
exploiter. Ce tableau contient, pour
chaque mthode, 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 mthode
La liste des arguments (type et nom).

IV.3.

La connexion du client et le partage des donnes

e client est install sur une machine distante: il va donc sappuyer sur un protocole distant
pour utiliser les services dEISMO : RMI. Cest ce protocole qui est la base du
fonctionnement des EJB du serveur. Ces EJB sont physiquement installs dans le serveur
dapplication (JonAS) du serveur EISMO et appels par le client. Ils permettent de partager
les mthodes implmentes sur le serveur entre plusieurs clients distants.

Projet EISMO

Page 34 sur 50

Figure 14 : principe de RMI

En revanche, ils ne permettent pas le partage de donnes. En effet, mme si les EJB et tout le
reste du code sont dans le mme projet, ils ne sont pas excuts sur la mme machine
virtuelle Java, et ne peuvent donc partager aucune donne. Ce problme peut tre rsolu de
deux manires : soit par lutilisation de bases de donnes, soit par lutilisation de fichiers.
Compte tenu de la nature des donnes et des liens existant entre elles, et de leur quantit
relativement peu importante, lutilisation de fichiers XML parait approprie. Ces fichiers sont
crs, mis jour et ventuellement dtruits par les diffrentes classes de la couche
coreServices. Ils sont ensuite, la demande du client, exploits par les EJB du serveur.

EISMO
KB Server
Applications
ressources provider

Applications
Integrator

EISMO
core-Services

Plateforme
J2EE
(JOnAS)

Knowledge Manager
Ecriture

Ecriture

EJB

Containe

Lecture

Donnes

Skeleton

Stub
Client
Figure 15 : processus de mise jour et dutilisation des fichiers

Il existe plusieurs fichiers xml dans le serveur. Certains dentre eux nexistent que pendant le
temps o le serveur est actif, car leur contenu est trs li lutilisation du serveur. Cest le cas
du fichier Onto.xml, qui ne dpend que des fichiers ouverts. Dautres, au contraire, sont
conservs aprs larrt du serveur, car ils contiennent des informations qui voluent peu. Cest
le cas des fichiers contenant les liens entre concepts, ou entre concepts et EJB, ou celui
contenant la liste des mthodes des EJB.

Projet EISMO

Page 35 sur 50

L'
IMPLENTATION DU CLIENT

aintenant que le serveur est dvelopp, et que tous les composants de ce serveur sont
installs, il faut crer l'
application cliente qui va permettre un dveloppeur de se
connecter au serveur et d'
utiliser les services que lui propose ce dernier.

I.

Prsentation

Le client est une application graphique comportant plusieurs fentres: une premire fentre,
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
slections effectues et valides, une nouvelle fentre s'
ouvrira, contenant la liste des
mthodes de l'
EJB slectionn prcdemment. Enfin, la slection d'
une mthode et le clic sur
le bouton permettront l'
ouverture d'
une fentre contenant le code de la mthode.
Cette application est cre 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 fentres ne contiennent que les
parties graphiques et les appels de mthodes. Toutes les mthodes utilises dans ces fentres
sont contenues dans des classes spcifiques.

Figure 16: Diagramme de classes simplifi du client

Projet EISMO

Page 36 sur 50

III.

Le dveloppement des diffrentes classes


a La fentre Fenetre_Client

C'
est la fentre principale de l'
application. Elle contient la mthode main(), et prsente
l'
utilisateur tous les boutons et affichages qui lui permettent d'
effectuer ses diffrentes
slections. A l'
ouverture, cette fentre appelle le constructeur de la classe Client, qui contient
les mthodes.

Figure 17 : La fentre du client (lancement de lapplication)

b La classe Client
Cette classe contient la plupart des mthodes utilises par la classe prcdente. Cette classe va
notamment, de manire entirement automatique, instancier l'
EJB OuvreXML, qui permet de
rcuprer 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 rcuprer 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 rcuprer la liste des
Projet EISMO

Page 37 sur 50

concepts quivalents celui pass en paramtre et la liste des EJB ayant un lien avec ces
concepts.

d La classe Fenetre_EJB
Il s'
agit d'
une nouvelle fentre, qui est ouverte chaque fois que l'
utilisateur clique sur le
bouton CodeEJB. Cette fentre permet l'
affichage de la liste des mthodes de l'
EJB
slectionn.

Figure 18 : Fentre affichant la liste des mthodes de lEJB slectionn

e La classe Methodes
Son constructeur est appel en mme temps que la fentre prcdente. Cette classe utilise
l'
EJB getMethodes pour rcuprer la liste des mthodes de l'
EJB slectionn et la retourner
Fentre_EJB.

f La classe CodeMethodes
Appele en mme temps que la classe fentre_Code chaque clic de l'
utilisateur sur le bouton
"Valider" de Fentre_EJB, cette classe se charge de rcuprer le code de la mthode
slectionne dont le nom lui est pass en paramtre.
Projet EISMO

Page 38 sur 50

g La fentre Fenetre_Code
Cette fentre est donc appele avec la classe CodeMethodes. Elle permet l'
affichage du code
de la mthode slectionn, 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 rpertoire o le sauvegarder.

Figure 19 : Fentre affichant le code de la mthode slectionne

h La classe Filtre
Elle hrite de JFileChooser.FileFilter et permet de slectionner l'
extension souhaite.

Projet EISMO

Page 39 sur 50

PERSPECTIVES ET CONCLUSIONS
I.

Perspectives

Un certain nombre dvolutions peuvent tre apportes lapplication. Elles concernent


notamment lautomatisation des tches de saisie des liens entre concepts, qui peuvent trs
probablement tre ralises directement par Racer.
Cette application peut galement voluer vers une application Web, plus simple mettre en
uvre du ct client, car accessible simplement par un navigateur.
Lutilisation dune base de donnes pourrait galement tre envisage pour grer la
persistance dans le cas o un grand nombre de SI serait utiliss.

II.

Conclusions

Ces cinq mois de stage ont t pour moi loccasion de mettre en pratique certaines
connaissances thoriques, notamment en dveloppement. Jai eu la chance davoir un sujet
suffisamment vaste et intressant, qui ma permis de toucher diffrentes technologies, telles
que les bases de connaissances, les serveurs dapplication et les technologies Java. Jai
galement pu accomplir diffrents travaux dtude et de recherche de solutions aux diffrents
problmes poss par le dveloppement de cette application, et mettre en uvre ces solutions.
Jai particulirement apprci la grande autonomie dont jai pu bnficier, qui ma permis
dvoluer considrablement dans le dveloppement, ainsi que la confiance qui ma t
accorde, et la qualit de lencadrement qui ne sest jamais relch, du dbut la fin.

Projet EISMO

Page 40 sur 50

ANNEXES
I.

ANNEXE 1 : Diagramme de classes du SI Data Warehouse

Projet EISMO

Page 41 sur 50

II.

ANNEXE 2 : Diagramme de classes du SI EDI

Projet EISMO

Page 42 sur 50

III.

ANNEXE 3 : Diagramme de classes du serveur

Projet EISMO

Page 43 sur 50

IV.

ANNEXE 4 : Diagramme de classes du package administration

Projet EISMO

Page 44 sur 50

V.

ANNEXE 5 : Diagramme de classes du package coreServices

Projet EISMO

Page 45 sur 50

VI.

ANNEXE 6: Diagramme de classes du client

Projet EISMO

Page 46 sur 50

VII. Annexe 7 : Diagramme des Cas d'Utilisation

Projet EISMO

Page 47 sur 50

VIII. ANNEXE 8: Diagramme de squences de l'administrateur

Projet EISMO

Page 48 sur 50

IX.

ANNEXE 9: Diagramme de squences du client

Projet EISMO

Page 49 sur 50

X.

BIBLIOGRAPHIE

http://java.sun.com/ est le site officiel de Sun pour tlcharger Java mais aussi trouver toute la
documentation ncessaire pour tout ce qui touche Java et aux serveurs J2EE.
Serveurs de bases de connaissance:
http://www.sts.tu-harburg.de/~r.f.moeller/racer fournit toutes les informations sur Racer ainsi
que des liens vers des sites fournissant des applications et de la documentation.
http://www.cs.man.ac.uk/~horrocks/FaCT/ est l'
quivalent du prcdent pour fact.
Serveurs d'applications:
http://www.objectweb.org/ est le site officiel du consortium fournissant le serveur Jonas.
http://www.application-servers.com/ pour les comparatifs entre serveurs d'
applications
publis
Dveloppement:
http://www.developpez.com/ site sur lequel on trouve des rfrences bibliographiques, des
cours, des forums.
http://www.infini-fr.com/ est l'
quivalent du prcdent
Divers:
http://www.exff.org/ est le site du projet exff qui a t utilis pour la transformation de
diagrammes de classes en ontologies.
http://www.w3.org/ site du W3C (World Wide Web Consortium) site indispensable pour xml,
mais aussi les langages de description et les ontologies.
http://www.inria.fr/ pour ses publications sur diffrents thmes

Projet EISMO

Page 50 sur 50