Plate-forme ISICIL : choix techniques

Transcription

Plate-forme ISICIL :
choix techniques
Emetteurs
Relecteur
Date
Référence
Version
Destinataires
Nicolas DELAFORGE, Sébastien COMOS
Fabien GANDON, Frédéric HERLEDAN
09/06/2009
ISICIL-ANR-RA01-ChoixTechniques-0906
1.0
ANR
Projet ISICIL :
Intégration Sémantique de l'Information
par des Communautés d'Intelligence en Ligne
Appel ANR CONTINT 2008
ANR-08-CORD-011-05
ISICIL : Intégration Sémantique de l'Information
Document émis le : 09/06/2009
Réf : ISICIL-ANR-RA01-ChoixTechniques-0906
ANR-08-CORD-011-05
Sommaire
I. Contexte de l’étude ..................................................................................................................................... 3
A. Contraintes techniques liées au projet.................................................................................................... 3
B. Méthode de développement .................................................................................................................. 3
C. Technologies du web sémantique........................................................................................................... 4
D. Langage de programmation ................................................................................................................... 4
E. Architecture client-serveur ..................................................................................................................... 4
1. Spécificités de l’architecture 2-tier ..................................................................................................... 5
2. Spécificités de l’architecture 3-tier ..................................................................................................... 5
3. Spécificités de l’architecture N-tier sous l’approche SOA (Service Oriented Architecture) ................... 6
F. Hétérogénéité des données .................................................................................................................... 6
1. Sources multiples, formats et protocoles variés ................................................................................. 6
2. L’outil privilégié du veilleur : Le navigateur ......................................................................................... 6
II. Détails de l’architecture.............................................................................................................................. 8
A. Choix techniques dans un contexte SOA ................................................................................................. 8
1. Définition d’un framework ................................................................................................................. 8
2. Contexte ............................................................................................................................................ 8
3. Objectifs............................................................................................................................................. 8
4. Choix technologiques ......................................................................................................................... 9
5. Mise en œuvre des Web Services REST..............................................................................................11
6. Persistance........................................................................................................................................13
7. Gestion des accès ..............................................................................................................................14
B. Modules clients .....................................................................................................................................14
1. Les extensions ISICIL..........................................................................................................................14
2. Injection RDFa ...................................................................................................................................15
C. Perspectives ..........................................................................................................................................15
1. Gestionnaire de profil .......................................................................................................................16
2. Gestionnaire de ressources ...............................................................................................................16
D. Conclusion ............................................................................................................................................17
III. Annexes....................................................................................................................................................18
A. Outils annexes ......................................................................................................................................18
1. Outils de build ...................................................................................................................................18
2. Autres ...............................................................................................................................................18
B. Serveur d’application.............................................................................................................................19
C. Références ............................................................................................................................................20
Plate-forme ISICIL : Choix techniques
Page 2 sur 21
ANR-08-CORD-011-05
I. Contexte de l’étude
A. Contraintes techniques liées au projet
Le projet ISICIL vise à tester l'efficacité de l'intégration des technologies du web sémantique et des réseaux
sociaux au sein d'outils collaboratifs, notamment dans le cadre de la veille en entreprise.
Dans cette optique, différentes équipes scientifiques et deux partenaires industriels ont été rassemblés afin
de bénéficier à la fois d’un regard interdisciplinaire sur la question mais aussi d’un terrain expérimental varié.
En l’occurrence, dans ISICIL, les compétences techniques sont pour la plupart rassemblées à Sophia au sein
de l’équipe Edelweiss de l’INRIA et au sein de l’équipe KEWI du CNRS. Dans chacun de ces laboratoires,
plusieurs outils ont été développés au cours des travaux scientifiques précédents. C’est le cas par exemple de
SemTag, SemServices et SweetWiki qui sont tous basés sur le moteur de recherche sémantique Corese[1]
développé par l’INRIA et qui représente à lui seul 20 homme/ans de développement. ISICIL n’a pas vocation à
redévelopper ces solutions mais plutôt à les intégrer à des outils de veille collaborative.
Il était donc indispensable pour nous de nous appuyer sur ces outils à la fois pour capitaliser au patrimoine
scientifique et technique de ces institutions mais aussi pour se concentrer sur les véritables enjeux
scientifiques du projet. Néanmoins, la reprise de cet existant et son adaptation aux besoins d’ISICIL n’a pas
un coût nul en termes de développement et a imposé de perpétuer certains choix techniques historiques.
Une autre contrainte qui a pesé directement sur les choix techniques réside dans le déploiement de nos
solutions au sein des services informatiques de nos partenaires industriels. En effet, l’un des critères qui fera
le succès d’ISICIL sera sa capacité à expérimenter ses solutions directement sur le poste des veilleurs. Or cela
implique que la plate-forme soit déployée au sein des entreprises. Dès lors, il est impensable de se contenter
d’un prototype semi-fonctionnel ou d’une preuve de concept. La qualité des technologies développées, leur
attractivité pour l’utilisateur, la sécurité et la fiabilité de leur fonctionnement représentent des objectifs
essentiels sans quoi les résultats de l’étude seraient totalement faussés.
B. Méthode de développement
ISICIL, comme tout projet de recherche appliquée, redéfinit perpétuellement ses contours au fil des
discussions entre ses participants. Ainsi le cahier des charges de la plate-forme technique est amené à
évoluer continuellement.
La durée de trois ans représente à l’échelle du développement informatique une période assez longue pour
que le contexte technologique ait également évolué avant la fin du projet.
Il serait donc très difficile et assez peu judicieux de planifier le développement trois ans à l’avance. C’est
pourquoi nous avons opté pour une solution plus souple et d’une manière générale plus adaptée à la gestion
de projet informatique dans le contexte de la recherche : la méthode Agile.
Il s’agit d’un modèle de gestion basé sur des cycles courts, un modèle de développement itératif et
incrémental impliquant fortement l’utilisateur final. Cette méthode s’oppose au modèle traditionnel très
rigide pour lequel les besoins du client sont figés de façon contractuelle en début de projet.
Page 3 sur 21
ANR-08-CORD-011-05
C. Technologies du web sémantique
Le Web sémantique est fondé sur les protocoles et langages standards du Web (HTTP, URI, XML…) ainsi que
sur les technologies qui lui sont propres comme RDF[2], RDFS[3], OWL[4] et SPARQL[5].
L’ingénierie des connaissances a produit ces dernières années, avec l’essor des réseaux sociaux et du web dit
« 2.0 », un grand nombre de langages de modélisation comme FOAF[6], SKOS[7], SIOC[8], Relationship[9]…
Tous ces formalismes sont pour la plupart décrits en RDF et sont extensibles. Edelweiss et Kewi disposent
d’une connaissance et d’un savoir-faire importants autour de ces technologies. La primitive technique
transversale à tous les projets de ces équipes est incarnée par Corese. Il s’agit d’un moteur d’inférences
sémantiques capable de manipuler des graphes RDF en s’appuyant sur les graphes conceptuels pour
l’opérationnalisation. Corese implante aussi un moteur de requêtes SPARQL et l’a enrichi de nombreuses
fonctionnalités. De plus il dispose de plusieurs formats de sortie : JSON, XML, RDF…
Corese constituera donc la brique logicielle de base autour de laquelle toute la plate-forme technique sera
articulée.
D. Langage de programmation
Pour la partie serveur dans ISICIL, le choix s’est rapidement porté sur Java et cela pour plusieurs raisons.
Des raisons historiques tout d’abord. En effet, depuis quelques années, ce langage s’est imposé dans l’équipe
Edelweiss. Corese a été développé en Java et des outils comme Sewese, SemCore, SemTags et SemServices
qui sont des surcouches de Corese ont logiquement été développés avec ce langage.
Comme la plupart des projets de l’équipe reposent sur ces outils, l’utilisation du même langage nous est
apparue comme naturelle afin d’assurer une pérennité et une interopérabilité avec l’existant.
Les autres raisons de ce choix sont liées aux qualités intrinsèques de Java à savoir :
• Stabilité et fiabilité
• Richesse des API disponibles
• indépendance au système d’exploitation
• Paradigme objet adapté aux projets de développement modulaires.
De plus, Java a su s’imposer comme LE langage adapté aux projets de qualité industrielle ainsi que dans le
monde de la recherche.
Les nombreux outils qui permettent de fiabiliser le développement sont un gage de qualité vis-à-vis des
services informatiques de nos partenaires industriels qui seront chargés l’intégration de la plate-forme ISICIL
au sein de leur software bus.
E. Architecture client-serveur
Un des objectifs d’ISICIL est de transposer les facteurs clés du succès du modèle Web 2.0 dans le cadre intraorganisationnel en prenant comme domaine d’application le partage et la fertilisation de connaissances dans
la démarche de la veille.
Page 4 sur 21
ANR-08-CORD-011-05
Etant donné l’utilisation dans le projet du moteur sémantique Corese, l’architecture client/serveur s’est
imposée face à une architecture P2P. En effet, cette technologie nécessite de centraliser les données et
requiert une puissance de calcul supérieure à celle disponible sur un poste utilisateur standard.
Dès lors, trois types d’architectures client/serveur s’offrent à nous :
• 2-tier (client lourd)
• 3-tier (client web)
• N-tier sous l’approche SOA
1. Spécificités de l’architecture 2-tier
L’ensemble des traitements applicatifs est supporté par le client le serveur ne gérant que les données.
Problèmes :
• Le poste client est fortement sollicité, il devient de plus en plus complexe et doit être mis à jour
régulièrement pour répondre aux besoins des utilisateurs.
• Echanges intenses entre le client et le serveur. Solution mal adaptée à des bandes passantes étroites.
• Fort couplage client serveur amenant un coût de maintenance élevé.
• Client non standard
• Déploiement lourd sur les postes utilisateurs
2. Spécificités de l’architecture 3-tier
La logique applicative est prise en charge par un serveur intermédiaire.
Le client est de type léger comme par exemple un navigateur web.
On retrouve ainsi 3 niveaux :
• Le client léger en charge des problématiques d'affichage et de mise en forme
• Un serveur en charge des traitements applicatifs
• Un serveur en charge de la gestion des données
Avantages :
• Client moins complexe donc moins couteux
• Gestion des montées en charge simplifiée
• Mutualisation de ressources et traitements
• Etc.
Problèmes :
• répartition de la charge complexe (serveur fortement sollicité)
• intégration au poste utilisateur limitée par les API disponibles et leurs contraintes de sécurité
Page 5 sur 21
ANR-08-CORD-011-05
3. Spécificités de l’architecture N-tier sous l’approche SOA (Service Oriented
Architecture)
On a toujours les 3 niveaux d’une architecture 3-tier mais le serveur en charge des traitements applicatifs est
découpé en de multiples services (composants métiers réutilisables). Ces services peuvent communiquer
entre eux par le réseau et donc être répartis sur une ou plusieurs machines.
Avantages :
• Modularité
• Intégration
• Maintenance
• Réutilisabilité
• Interopérabilité
• Répartition de la charge
• Pallie les faiblesses des architectures précédentes
L’architecture N-tier par sa modularité nous semble particulièrement adaptée pour répondre aux besoins du
projet.
F. Hétérogénéité des données
1. Sources multiples, formats et protocoles variés
La pratique de veille implique la consultation de multiples sources d’information qu’elles soient instantanées
ou monolithiques. En entreprise, la veille peut être tournée vers l’extérieur ou vers l’intérieur selon ses
objectifs. Il faut donc tenir compte des spécificités des applications intra et extranet qui pour la plupart n’ont
(malheureusement) pas été développées de manière compatible avec tous les navigateurs.
Le web d’aujourd’hui est également très différent de ce qui avait été imaginé au commencement comme la
plus grande bibliothèque du monde. D’un simple réseau de documents, nous sommes passés à un vaste
réseau d’applications communicantes ou l’information est plus labile que jamais. Dans ce panorama, de
nombreux outils en ligne ont vu le jour, Netvibes, Delicious, Facebook, Twitter, Les « Google documents »…
De ce fait, le rayonnement applicatif de la veille dépasse largement le périmètre du poste de travail de
l’utilisateur dans son bureau. Le veilleur peut travailler à différents endroits géographiques, dispose de
multiples comptes sur les applications de son entreprise mais aussi sur les outils dits « 2.0 » en ligne comme
Google Reader ou Netvibes, un blog perso hébergé sur un serveur externe etc.
2. L’outil privilégié du veilleur : Le navigateur
Le veilleur est confronté à un large panel de formats numériques, de médias et d’outils. Ce contexte
technologique très hétérogène fait du navigateur web l’outil indispensable à toute activité de ce genre. En
effet, le navigateur web est conçu comme un lecteur universel extensible, capable de s’adapter à de
multiples formats et protocoles notamment grâce aux mécanismes de plugins audio/vidéo/flash/java.
Certains navigateurs récents proposent également des fonctionnalités avancées pour le développement
d’extensions visant à augmenter la consultation.
Page 6 sur 21
ANR-08-CORD-011-05
Dans le cadre d’ISICIL, le navigateur semble le support adapté pour nos développements côté « client ». En
effet, dans le processus de consultation, le navigateur se trouve précisément à l’interface entre le contenu et
l’utilisateur, entre l’intérieur et l’extérieur, entre le public et le privé. Cet outil stratégique nous permet d’agir
de façon « quasi-transparente » sur le contenu en cherchant à étendre le champ des possibles pour le
veilleur sans pour autant perturber sa pratique globale. Cet enrichissement de la veille passe le plus souvent
par les métadonnées issues des modèles formels mis à disposition par le serveur d’application dont nous
avons parlé plus tôt dans ce document.
Parmi tous les navigateurs du marché, le plus utilisé est encore Internet Explorer, tout simplement car il est
installé par défaut sur les postes sous Windows. Malheureusement, les versions installées sont rarement
mises à jour et les versions varient entre IE6.0 et IE8.0. De plus ces différentes versions implémentent
différemment les standards et sont d’une manière générale peu extensibles. Un autre facteur limitant quant
à l’utilisation d’IE pour nos développements réside dans son attachement à un seul système d’exploitation, or
nombre de veilleurs sont équipés d’ordinateurs sous MAC OS ou Linux.
Dans un cycle court d’expérimentation comme nous l’impose la méthode Agile, il était difficile d’envisager le
développement de plusieurs versions de nos outils en parallèle. C’est pourquoi nous avons favorisé le
navigateur Firefox qui est déjà largement utilisé, est disponible sur tous les OS, est respectueux de la plupart
des standards du web et qui est de plus facilement extensible.
Tout au long du projet, nous développerons donc des extensions Firefox connectées à nos services applicatifs
sémantiques côté serveur.
Page 7 sur 21
ANR-08-CORD-011-05
II. Détails de l’architecture
A. Choix techniques dans un contexte SOA
1. Définition d’un framework
Un framework est la concrétisation dans un squelette d’application d’un ensemble de choix techniques et
architecturaux sur lesquels les développements futurs seront basés.
2. Contexte
Les modules qui devront être développés ou repris sur la base du framework qui va être présenté
apparaissent dans le schéma suivant :
Figure 1 : Organisation des services ISICIL
3. Objectifs
A : Décharger des choix techniques et architecturaux les personnes amenées à développer et ainsi faciliter
l’intégration et la productivité.
Beaucoup de personnes seront amenées à participer aux phases de développement et notamment des
stagiaires. L’objectif est donc d’éviter que chacun perde du temps sur des questions de « comment faire » et
fasse ses choix techniques dans son coin pour éviter de se retrouver avec des problèmes de conception et
d’intégration.
Page 8 sur 21
ANR-08-CORD-011-05
Il faut également structurer les développements pour ne pas se retrouver avec des applications fortement
boguées et difficile voire impossible à maintenir et faire évoluer.
B. Assurer une interopérabilité et une compatibilité maximale entre les différents modules
Cette interopérabilité sera assurée par le biais de WebServices REST mais nous y reviendrons dans la suite du
document.
4. Choix technologiques
a) SemServices – SemCore – Corese
Comme évoqué dans la première partie de ce document, la partie sémantique sera gérée par Corese.
SemServices est une WebApp mettant à disposition des WebServices REST permettant d’accéder à Corese via
une API publique nommée SemCore
SemServices a été repris de manière à permettre à plusieurs clients de partager leurs données dans Corese,
d’améliorer son fonctionnement et de coller aux choix architecturaux du projet pour des questions de
cohérence, de performance et de maintenance.
b) Communication entre les couches
Dans une architecture SOA, le découplage entre les couches est essentiel. Or comme nous l’avons vu, pour
pouvoir faire face à des montées en charge, il a été prévu que les différents modules ou services puissent
être déployés sur des machines différentes.
Pour assurer la communication entre ces différentes couches diverses solutions s’offrent à nous :
Solutions
Corba
Avantages
• Indépendant du système d’exploitation et du langage de
programmation.
• Permet l’intégration des systèmes propriétaires grâce à
l’IDL
• CORBA standardisé par l’OMG
• CORBA intègre les aspects métiers.
Inconvénients
• Incompatibilité entre les implémentations
• CORBA complexe à appréhender et à mettre en
place.
• Problème de pare-feu
• Sécurité et administration
• Nécessite des changements dans les applications…
• La version 2.3 inter-opère avec RMI
RMI
• Plus simple que le développement des sockets JAVA
• Limité à la plate-forme JAVA
• Supporte la POO
• Architecture fortement couplée
• Transparence dans les communications entre objets
• Pas de gestion de session
• Gestion distribuée des ressources
COM/DCOM
• Simple d’utilisation.
• Spécifique à Microsoft
• Portabilité binaire
• Problème de gestion des états et de sessions
• Pas de portabilité du code
Services Web
• XML est utilisé pour l’échange des données et messages.
• Sécurité faible
• Ils permettent l’intégration de plateformes hétérogènes
• Inadapté à l’approche synchrone
Page 9 sur 21
ANR-08-CORD-011-05
via le protocole HTTP
• L’utilisation du protocole HTTP permet de passer les
pare-feux
• Les développeurs ont l’embarras du choix en matière de
langage de programmation : Java, C, C++, Perl, Python,
C#, et/ou Visual Basic,
• Peu ou pas de modification des applications existantes
• Permet une intégration faible, les composants sont
simples mais peuvent résoudre des problèmes
complexes
• Peuvent être créés facilement une fois l’application
terminée pour exposer un service sur le net
• Il n’existe pas de client propriétaire
• Outils de développement et de déploiement fournis par
les principales plateformes J2EE et Microsoft .NET
• Permettent la localisation et l’invocation dynamique
d’autres services à partir de registres privés ou publics
La solution des Services Web est celle qui présente le plus d’intérêt dans le contexte du projet du fait de ses
nombreux avantages.
Il existe toute fois deux types d’approches concernant les Services Web à savoir SOAP et REST.
L'introduction de la spécification Web Method dans SOAP 1.2 permet à SOAP de se conformer au style REST.
Cette faiblesse de SOAP ayant été comblée, le débat sur la différence entre ces deux approches est donc
devenu en partie sans objet.
Dans les 2 cas, les données sont échangées sous la forme de XML sur HTTP. Il n'y a donc pas, de ce point de
vue, de différence en termes de performance ou de fiabilité. Le fait d'ajouter une enveloppe SOAP autour des
données est neutre.
La plupart des grands sites qui offrent des services web aux développeurs comme Amazon ou eBay offrent
simultanément les deux types d'interfaces. L'écrasante majorité (plus de 85%) des centaines de milliers de
développeurs choisissent REST comme interface, essentiellement pour des raisons de simplicité. La barre
d’adresse d'un navigateur suffit pour écrire et tester une requête REST alors que SOAP impose l'emploi d'un
langage de programmation et de l'infrastructure correspondante. Ces sites ont par ailleurs unifié les données
manipulées par les services SOAP ou REST, ce qui réduit encore l'écart qui aurait pu exister.
La plus grande différence entre les deux styles est le nom de la ressource. Dans le style REST, le nom de la
ressource est dans l'URI alors que dans le style SOAP, tous les messages sont généralement envoyés vers
point d'entrée unique. Le nom de la fonction à effectuer est caché à l'intérieur de l'enveloppe. Cette manière
de faire peut présenter des avantages dans certains cas, en particulier quand certaines parties du message
doivent rester confidentielles. En revanche, dans la majorité des cas, c'est plutôt un inconvénient. Le point
d'entrée unique entraîne un couplage fort qui complique la gestion des priorités et des performances. Un
Page 10 sur 21
ANR-08-CORD-011-05
mécanisme simple pour assurer la sécurité d'accès ne peut plus être mis en œuvre. Avec SOAP, la sécurité
redevient donc fortement couplée avec l'application ce qui n’est pas le cas avec REST.1
Le style REST a donc été adopté.
5. Mise en œuvre des Web Services REST
Différentes implémentations de JAX-RS (JSR 311) existent pour construire des WebServices REST:
• CXF [10]
• Jersey [11]
• RESTeasy [12]
• Restlet [13]
Jersey est l’implémentation de référence de JAX-RS [14] (JSR 311), c’est dont celle-ci qui est retenue.
Pour faire face au besoin de générer des données XML à partir d’objet Java et inversement, l'API Java de Sun
JAXB [15] (Java Architecture for XML Binding) s’impose d’elle-même faute de concurrent sérieux.
a) Respect des couches : le modèle MVC
L’un des objectifs est de fournir des outils et méthodes pour construire des applications robustes.
Le modèle MVC permettant de bien structurer le code en différentes couches, chacune ayant un rôle bien
définit dans le but d’avoir un code facile à maintenir et à faire évoluer, ce modèle doit est implémenté dans
notre architecture.
1
Cette description a été largement inspirée du site : http://www.figer.com/Publications/SOA.htm
Page 11 sur 21
ANR-08-CORD-011-05
Figure 2 : Le modèle MVC
Après saisie d’une URL dans un navigateur, la requête est interceptée par le Contrôleur qui récupère des
données via la couche Modèle, qui les transmet ensuite à la Vue qui se charge de les mettre en forme et
renvoie le tout au navigateur pour affichage.
b) Spring MVC
Il existe de nombreux frameworks MVC, Struts [16], JSF [17] et Tapestry [18] font partie des plus connus.
Spring MVC [19] tout comme Jersey s’intègre naturellement avec Spring IOC [20] qui sera décrit plus loin et
est l’un des premiers à utiliser les annotations pour configurer la partie contrôleur.
Il est performant, relativement simple et il existe une communauté importante.
Figure 3 : Schéma d’architecture du serveur
La couche « Modèle »
Faisons maintenant un zoom sur cette couche Modèle.
Elle comporte 2 sous couches :
• Couche « Métier » : traitements
• Couche « DAO » (Data Access Object) : accès aux données (DataBase, Corese, XML, etc).
Accès aux différentes couches : Spring IOC
Spring IOC est un framework qui permet de découpler et de bien cloisonner les différentes couches.
Page 12 sur 21
ANR-08-CORD-011-05
6. Persistance
a) Base de données embarquée
Il est possible, voire probable, que le serveur de tags et le serveur de profiles aient besoin de stocker des
données ne pouvant être gérées par Corese.
Pour cela une base de données relationnelle doit être mise à disposition.
Dans le monde du logiciel libre plusieurs choix s’offrent à nous. On peut ainsi citer MySQL, PostgreSQL,
Ingres, Firebird.
Ce type de solutions est particulièrement adapté aux gros volumes de données. Le revers de la médaille
concerne la lourdeur, la difficulté d’installation, d’intégration et d’administration de ce type de système.
Dans le cadre du projet Isicil, le volume de données manipulées propres à chaque service (donc hors Corese)
ne devrait pas être très important.
De plus, l’intégration est une contrainte forte. Ces produits ne sont donc pas des solutions viables dans notre
contexte.
Le projet ISICIL et ses différents services devant être simples à déployer et la configuration de la base se
devant être d’intégration facile avec les frameworks de mapping objet relationnel (voir plus bas), 3 solutions
de type embarqué (création et initialisation au démarrage de l’application) se sont alors démarquées :
• HSQLDB [21], utilisée le plus souvent pour les tests unitaires possède des limitations en taille des
fichiers stockables par Blob. De plus les données étant stockées en mémoire, un problème de
persistance se pose en cas de redémarrage de l’application ou d’un redéploiement.
• JavaDB [22] intégré au JDK depuis la version 1.6 autorise le stockage de fichiers plus conséquents en
utilisant le disque dur. Cependant un bug Hibernate/Derby existe dans la génération de schémas pour
lequel les deux projets se renvoient la balle l'un à l'autre.
• H2 [23] qui semble particulièrement intéressante à la lecture de la documentation (assez fournie au
demeurant). La configuration est simple, les comparatifs élogieux et les fonctionnalités au rendezvous. De plus, les problèmes rencontrés avec le couple Hibernate/Derby ne se produisent pas ici. Elle
possède une console applicative embarquée accessible via un browser.
H2 semble donc être le meilleur choix.
b) Mapping relationnel
Pour faciliter la manipulation des données relationnelles avec Java qui est un langage objet des outils existent
qui sont des implémentations de JPA (Java Persistence API) [24] :
• EclipseLink [25]
• Hibernate [26]
• OpenJPA [27]
Les 2 premières solutions sont les plus populaires. Pour des raisons de connaissances avancées sur
l’utilisation d’Hibernate au sein de l’équipe, le choix s’est porté sur ce dernier.
Page 13 sur 21
ANR-08-CORD-011-05
7. Gestion des accès
Le projet Isicil comporte des contraintes de sécurité à savoir :
• Sécuriser l’accès par des utilisateurs aux URLs via un formulaire
• Sécuriser les WebServices REST Isicil.
Très souvent, la gestion des accès est gérée par le serveur d’application. Chaque serveur implémente sa
propre solution d’identification et d’autorisation ce qui entraîne des problèmes de compatibilités lorsqu’il
s’agit de migrer une application d’un serveur à un autre.
Pour pallier à ce problème nous faisons appel à Spring Security [28].
Ce framework permet donc de gérer les problématiques d’identification et d’autorisation de façon non
spécifique à un serveur d’application.
B. Modules clients
1. Les extensions ISICIL
a) Xml User interface Language (XUL)
Comme nous l’avons expliqué précédemment, le navigateur est l’outil privilégié dans l’activité de veille.
Après avoir étudié les diverses solutions notamment les userscripts de Greasemonkey, qui présentaient de
grands risques de sécurité et une incompatibilité avec IE, nous avons choisi de baser nos applications sur la
technologie XUL [29] issue du framework Mozilla/Firefox. Ce langage permet de développer des extensions
d’interface directement intégrées dans le navigateur. Celles-ci respectent totalement les caractéristiques
d’interface de l’OS sur lequel est installé le navigateur. Cette caractéristique de XUL nous semble intéressante
pour l’intégration « transparente » de nos solutions dans le poste de l’utilisateur.
Firefox dispose également d’un système éprouvé de mise à jour automatique de ses extensions. Ces
dernières peuvent être signées numériquement afin d’éviter tout risque lors de l’installation depuis
l’extérieur.
Le langage XUL est entièrement déclaratif, exprimé en XML et respectueux des standards du W3C. Il permet
de décrire entièrement une interface utilisateur, de l’organisation spatiale des éléments graphiques
jusqu’aux interactions avancées. Il est également possible de lier les composants graphiques à des sources de
données externes XML, bases de données ou RDF. XUL dispose également d’un système natif de gestion de la
localisation/internationalisation des applications basé sur la mécanique de définition des entités XML dans
une DTD.
XUL utilise ECMAScript [30] (la version standardisée de Javascript) pour programmer les interactions.
Ce langage est également extensible via la technologie XBL [31] proche des taglib Java qui permet de définir
ses propres balises XUL et des les programmer facilement en ECMAScript.
La librairie XPCOM[32], la bibliothèque « bas niveau » du framework Mozilla, est conséquente et bien
documentée. Elle dispose de nombreuses fonctions intéressantes pour ISICIL comme la gestion des différents
protocoles, l’accès au système de fichier du poste utilisateur, différents parseurs…
Page 14 sur 21
ANR-08-CORD-011-05
Cette librairie s’enrichit au fur et à mesure.
Toutes ces méthodes possèdent des interfaces IDL qu’il est possible de mobiliser selon les besoins dans le
code des extensions.
b) Couplage Client – Serveur d’Application
Le couplage faible entre les extensions et le serveur d’application ISICIL, se fera par des appels AJAX aux
services REST. Pour la plupart, ces services se contenteront de valider les droits de l’utilisateur, d’interroger
Corese et de renvoyer les résultats sous la forme demandée. Néanmoins, rien n’interdit avec ce système
d’interroger d’autres sources AJAX ou RSS, comme les web services Google, Delicious ou Twitter.
De plus, il est possible que, pour certaines tâches bien précises, les extensions Firefox soient inadaptées.
C’est le cas par exemple de l’édition riche de document. Dans ce cas, nous utiliserons plutôt des solutions
existantes et rôdées de type wiki.
2. Injection RDFa
La plupart des entreprises disposent déjà d’outils collaboratifs sur lesquels se trouve un contenu parfois
conséquent. Il est très délicat de demander à ces entreprises de changer leurs outils et d’abandonner leurs
contenus. Parfois des solutions de migration existent ou peuvent être développées, mais le coût peut
s’avérer élevé et souvent cette migration engendre une perte d’information (ne serait-ce que la mise en
forme).
ISICIL a fait le choix d’aborder le problème sous un autre angle. En effet, un des gros enjeux du projet
consiste à s’adapter à l’existant et à l’enrichir.
La plupart des gestionnaires de contenu (CMS) en entreprise sont écrits en PHP, ASP ou JSP et disposent d’un
système de templates destiné à factoriser la mise en forme. En agissant intelligemment sur ces templates et
en injectant des métadonnées dans la page, il est possible de « sémantiser » ce contenu.
Les métadonnées pourraient être exprimées sous différents formats déjà couramment utilisés comme
RDFa[33] ou Microformats[34]. Selon les besoins elles contiendront des informations concernant l’auteur, le
contenu ou encore les précédents lecteurs.
Nous faisons l’hypothèse que par cette mécanique d’injection en amont de la consultation, il est possible
d’augmenter considérablement les informations disponibles pour le lecteur. Là où la plupart des solutions de
veille existantes tentent de se substituer aux systèmes en place, ISICIL se place à un niveau d’abstraction
supérieur en proposant de faire le lien entre tous les outils disponibles.
Les premières expérimentations sur la plate-forme ISICIL viseront à évaluer et à valider ce positionnement
innovant.
C. Perspectives
A l’heure actuelle, le développement de la plate-forme ISICIL n’a pas réellement commencé.
Les entretiens et les observations faites par les ergonomes chez les veilleurs nous fourniront d’ici peu une
liste d’exigences sur laquelle il sera possible de construire un cahier des charges fonctionnel plus précis.
Néanmoins, la méthode agile, que nous nous efforçons de suivre pour la planification du développement,
Page 15 sur 21
ANR-08-CORD-011-05
nous donne la réactivité nécessaire pour s’adapter à des besoins qui seraient identifiés tardivement dans le
projet.
Pour l’instant nous avons mis en place une mécanique souple et adaptée au contexte technoscientifique du
projet. Même si nous ne savons pas encore précisément quels seront les services développés d’ici 2012,
l’orientation scientifique actuelle nous donne une visibilité assez bonne quant aux informations de base qui
seront indispensables à la plate-forme.
Par exemple, les notions de tag, ressource et utilisateur sont déjà clairement identifiées. C’est pourquoi les
premiers développements ISICIL se concentreront sur la mise en place de couples extension/webservice
basés sur ces concepts.
1. Gestionnaire de profil
Ce développement permettra tout simplement, aux utilisateurs de s’identifier au sein de la plate-forme.
A terme, ce gestionnaire de profil permettra à l’utilisateur, entre autres, de :
• renseigner ses compétences professionnelles,
• gérer ses multiples identités,
• renseigner des informations concernant ses réseaux professionnels, sociaux, groupes de travail,
• faire des recherches sémantiques parmi les informations publiques des autres utilisateurs de la
plateforme,
• visualiser des réseaux d’utilisateurs,
• partager ses informations,
• etc.
Le modèle utilisé pour la description des utilisateurs et des groupes sera basé sur FOAF et Relationship. Ce
modèle sera enrichi au fur et à mesure de l’avancement du projet, notamment par des indicateurs de
centralité ou de confiance implémentés suivant les travaux de Guillaume Erétéo (doctorant CIFRE
OrangeLabs/INRIA pour ISICIL) et Talel Abdessalem (Telecom ParisTech).
2. Gestionnaire de ressources
Le gestionnaire de ressources permettra à l’utilisateur de marquer n’importe quelle ressource à partir du
moment où elle dispose d’une URI. Ainsi selon les cas, il pourra s’agir d’une page web, d’un document PDF,
d’un flux RSS, d’un collègue, etc.
Ces tags auront une visibilité paramétrable selon les choix de l’utilisateur qui pourra décider de rendre son
tag public ou privé. Cet outil permettra également à l’utilisateur de faire des recherches évoluées parmi ses
tags ou ceux de son réseau et éventuellement parmi les concepts des ontologies ou thesaurus mis en place
au sein de son service.
Page 16 sur 21
ANR-08-CORD-011-05
D. Conclusion
La plate-forme logicielle ISICIL interviendra donc à plusieurs niveaux comme indiqué dans la figure suivante :
Figure 4 : Architecture générale de la plate-forme ISICIL
1. Au niveau des contenus existants, en enrichissant ceux dont les templates seront accessibles par des
annotations RDFa,
2. Dans le navigateur, par des extensions Firefox/XUL, qui augmenteront le travail de veille en
s’interfaçant avec le serveur ISICIL et en collectant selon le contexte de navigation les métadonnées
les plus pertinentes.
3. Au niveau infrastructure en mettant à disposition des outils ISICIL, un serveur d’applications Tomcat
dont les services seront publiés en REST et qui sera en charge du traitement sémantique des
requêtes, de la gestion des utilisateurs ainsi que de leurs droits d’accès.
Cette architecture nous paraît suffisamment souple et riche pour répondre entièrement aux besoins du
projet. Son intérêt majeur réside dans le couplage faible entre les services REST et leur matérialisation
dans les extensions Firefox. En effet, rien n’interdit ici de développer en parallèle des extensions ISICIL,
une plate-forme web qui proposerait une ergonomie différente et peut-être plus adaptée à certaines
activités ou contextes applicatifs.
Page 17 sur 21
ANR-08-CORD-011-05
III. Annexes
A. Outils annexes
1. Outils de build
Dans un souci de mise en place des bonnes pratiques de développement, un outil de build structurant,
performant et indépendant de l’EDI a été choisi.
Deux outils répondent à ces critères, à savoir :
• ANT
• Maven 2
Ant et Maven2 reposent sur une philosophie diamétralement opposée.
Le premier se comporte comme un makefile et impose donc de définir un ensemble d’opérations alors que le
second impose une description du projet sur laquelle il se basera pour réaliser les opérations dessus. Il est
capable de gérer tout le cycle de vie du projet.
Maven2 propose de renverser le problème. Ce ne sont plus les opérations à faire qui sont définies mais le
projet qui est décrit. En sachant où se trouvent les éléments dont il a besoin dans le projet, il est à même de
réaliser les opérations dessus. On n'écrit plus de script avec Maven. Maven propose une configuration par
défaut très complète qui permet une standardisation de la structure des projets Java. Au besoin, Maven
permet de surcharger les configurations pour s'adapter à plus de situations.
Les points forts de Maven2 sont les suivants :
• « Standardise » l’arborescence d’un projet (c’est donc très structurant)
• Simplifie la gestion des dépendances
• Unifie le système de build
• Intégration avec des gestionnaires de version comme CVS [35] et Subversion [35]
• Aide à construire des applications robustes
Pour l’ensemble de ces raisons Maven2 a été retenu.
2. Autres
a) Outil de log : Log4J
API permettant la gestion des logs
b) Tests unitaires : JUnit
Toujours dans un souci de réaliser des applications fiables, on fait appel à Junit.
Junit est un framework opensource permettant de réaliser des tests unitaires sur du code java.
Le test unitaire est le procédé permettant de s’assurer du bon fonctionnement d’une partie déterminée d’un
logiciel ou d’une portion d’un programme.
Page 18 sur 21
ANR-08-CORD-011-05
Le principal intérêt de ce type d’outil est de pouvoir s’assurer que le code réponde toujours au besoin même
après d’éventuelles modifications et d’éviter ainsi des régressions.
c) Client HTTP : HttpClient
Permet de créer et de gérer des requêtes http. HttpClient permet donc de créer des clients capables
de consommer des WebServices REST.
B. Serveur d’application
Les choix architecturaux et techniques présentés ici ne nécessitent pas de faire appel à un gros serveur
d’application J2EE. Un simple conteneur de servlets est suffisant pour nos besoins.
Les solutions open source en la matière sont parfaitement mûres. Glassfish et Tomcat sont les deux
représentants les plus performants et les plus diffusés à l’heure actuelle et sont sensiblement de même
valeur.
Actuellement au sein de l’équipe Edelweiss la totalité des projets tournent sur Tomcat. Pour des raisons de
cohérence et de maintenance le choix s’est porté sur ce dernier.
Page 19 sur 21
ANR-08-CORD-011-05
C. Références
[1] Corese, COnceptual REsource Search Engine, http://www-sop.inria.fr/edelweiss/software/corese/
[2] RDF, Resource Description Framework, http://www.w3.org/RDF/
[3] RDFs, RDF Schema, http://www.w3.org/TR/rdf-schema/
[4] OWL, Web Ontology Language, http://www.w3.org/TR/owl-features/
[5] SPARQL, Query Language for RDF, http://www.w3.org/TR/rdf-sparql-query/
[6] FOAF, The Friend of a Friend project, http://www.foaf-project.org/
[7] SKOS, Simple Knowledge Organisation System, http://www.w3.org/2004/02/skos/
[8] SIOC, Semantically-Interlinked Online Communities, http://sioc-project.org/
[9] Relationship, A vocabulary for describing relationships between people,
http://vocab.org/relationship/.html
[10] CXF, open source services framework, http://cxf.apache.org/
[11] Jersey, open source JAX-RS (JSR 311) Reference Implementation for building RESTful Web services,
https://jersey.dev.java.net/
[12] RESTeasy, Boss project that provides various frameworks to help us build RESTful Web Services,
http://www.jboss.org/resteasy/
[13] Restlet, open source framework for REST, http://www.restlet.org/
[14] JAX-RS, Java API for RESTful Web Services, https://jsr311.dev.java.net/
[15] JAXB, develops and evolves the code base for the reference implementation of the JAXB specification,
https://jaxb.dev.java.net/
[16] Struts, open-source framework for creating Java web applications, http://struts.apache.org/
[17] JSF, establishes the standard for building server-side user interfaces,
http://java.sun.com/javaee/javaserverfaces/
[18] Tapestry, open-source framework for creating dynamic, robust, highly scalable web applications in Java,
http://tapestry.apache.org/
[19] Spring MVC, open-source framework for creating Java web applications,
http://www.springsource.org/
[20] Spring IOC, inversion of Control, http://www.springsource.org/
[21] HSQLDB, HyperSQL DataBase, SQL relational database engine written in Java, http://hsqldb.org/
[22] JavaDB, SQL relational database engine written in Java, http://developers.sun.com/javadb/
[23] H2, SQL relational database engine written in Java, http://www.h2database.com/
Page 20 sur 21
ANR-08-CORD-011-05
[24] JPA, Java Persistence API, http://java.sun.com/javaee/overview/faq/persistence.jsp
[25] EclipseLink, open source Java persistence framework project, http://www.eclipse.org/eclipselink/
[26] Hibernate, open source Java persistence framework project, https://www.hibernate.org/
[27] OpenJPA,, open source Java persistence framework project, http://openjpa.apache.org/
[28] Spring Security, powerful and flexible security solutions for enterprise applications,
http://static.springsource.org/spring-security/site/
[29] XUL, Xml User interface Language, https://developer.mozilla.org/fr/XUL
[30] ECMAScript, ECMA scripting language, http://www.ecmainternational.org/publications/standards/Ecma-262.htm
[31] XBL, XML Binding Language, http://www.w3.org/TR/xbl/
[32] XPCOM, Mozilla API, https://developer.mozilla.org/fr/XPCOM
[33] RDFa, RDF Annotations, http://www.w3.org/TR/xhtml-rdfa-primer/
[34] Microformats, http://microformats.org/
[35] CVS, Concurrent Version System, http://www.cvshome.org/
[36] Subversion, Open Source version control system, http://subversion.tigris.org/
Page 21 sur 21

Plate-forme ISICIL : choix techniques

Transcription

Documents pareils

Alice Champagne Ardenne FORUM JOBS 2004

Offres d`emploi de Jobingé - Forum Entreprises JAVA DEVELOPER

Conception et développement Java/J2EE web

ingenieur java/j2ee h/f

Ingénieur Informatique Java-J2EE (HF) Conception et

Essalihe, M. STRUTS - Framework pour le développement d

Projet Gestion d`Utilisateurs en Java

REFERENCE : REC2017.StageG3.AirFret Contexte fonctionnel : l

Diplomatic-Cover - Top Interactive Agencies

Moteur de Recherche Corese Rapport d`Activité