Universit Nancy 2 UFR Mathmatiques et Informatique 13 rue Michel Ney case officielle n 75 54037 Nancy cedex

Digital Museum

Rapport de stage en entreprise de DESS SID Stage effectu au LORIA

Julien DUCRET

Promotion 2002-2003 Universit Nancy 2 UFR Mathmatiques et Informatique 13 rue Michel Ney case officielle n 75 54037 Nancy cedex

Digital Museum

Rapport de stage en entreprise de DESS SID 1er avril 30 septembre 2003 Stage effectu au : LORIA Campus Scientifique B.P. 239 54506 VANDOEUVRE-ls-NANCY CEDEX Tuteur en entreprise : Samuel CRUZ-LARA Julien DUCRET Promotion 2002-2003

Je tiens remercier Samuel Cruz-Lara, mon responsable de recherche pour son accueil et sa bienveillance, Jonathan Faivre-Vuillin stagiaire de DUT avec qui jai travaill de faon remarquable sur ce projet, Odile Thiery, ma responsable de stage et Kalid Benali le responsable du DESS pour mavoir permis de raliser mon stage au LORIA.

Sommaire
1 2 Introduction .................................................................................................. 7 Le LORIA ....................................................................................................... 8 2.1 Prsentation................................................................................................. 8 2.2 Organisation ................................................................................................ 8 2.3 Personnels ................................................................................................... 8 3 Lquipe....................................................................................................... 10 3.1 Prsentation............................................................................................... 10 3.2 Axes de recherche ...................................................................................... 11 3.2.1 Fondements scientifiques ................................................................... 11 3.2.2 Domaines d'application ...................................................................... 13 3.3 Relations scientifiques et industrielles ............................................................ 16 4 Le point sur la technologie .......................................................................... 17 4.1 Historique des rseaux ................................................................................ 17 4.1.1 Le systme central ............................................................................ 17 4.1.2 Le modle client serveur .................................................................... 17 4.1.3 Le modle Internet............................................................................ 19 4.1.4 Le modle WebServices ..................................................................... 20 4.2 La technologie JWSDP ................................................................................. 21 4.2.1 Gnralits ...................................................................................... 21 4.2.2 Les API............................................................................................ 22 4.2.3 Installation du JWSDP........................................................................ 23 4.2.4 Server Administration ........................................................................ 24 4.2.5 Web Application Manager ................................................................... 25 5 Le projet Digital Museum ...................................................................... 26 5.1 Prsentation............................................................................................... 26 5.2 Architecture gnrale .................................................................................. 27 5.3 La couche de Persistance (connection) ........................................................... 27 5.3.1 Le concept ....................................................................................... 27 5.3.2 Larchitecture ................................................................................... 27 5.3.3 La grammaire ................................................................................... 28 5.3.4 Les difficults rencontres .................................................................. 28 5.3.5 Un exemple de code .......................................................................... 29 5.4 Ladministration des donnes (admin)............................................................ 29 5.4.1 Le concept ....................................................................................... 29 5.4.2 Larchitecture ................................................................................... 29 5.4.3 Les java Beans ................................................................................. 29 5.4.4 Lorganisation des JSP ....................................................................... 30 5.4.5 Linterface........................................................................................ 31 5.5 Le Web Service Museum (DigitalMuseum) ...................................................... 33 5.5.1 Le concept ....................................................................................... 33 5.5.2 Larchitecture ................................................................................... 34 5.5.3 Linterfaage et limplmentation du service .......................................... 34 5.5.4 Les types supports .......................................................................... 34 5.5.5 Les fichiers de configuration ............................................................... 36 5.5.6 La Compilation et le dploiement du service.......................................... 37 5.5.7 Le Fichier WSDL : ............................................................................. 37 5.5.8 La publication ................................................................................... 38 5.6 Le Designer................................................................................................ 39 5.6.1 Le concept ....................................................................................... 39 5.6.2 Larchitecture ................................................................................... 39 5.6.3 Le tutorial ........................................................................................ 45 5.7 Larchitecture finale..................................................................................... 51

Perspectives ................................................................................................ 52 6.1 Les ressources multimdia ........................................................................... 52 6.2 Uddi.......................................................................................................... 52 6.3 Base de donne XML ................................................................................... 52 6.4 Editeur de prsentation multimdia ............................................................... 52 6.5 Format multimdia...................................................................................... 52 6.6 Programmation........................................................................................... 53 7 Conclusion ................................................................................................... 54

1 INTRODUCTION
Mon stage au LORIA a t pour moi loccasion de dcouvrir le milieu de la recherche en informatique. En effet, jai dj eu plusieures reprises loccasion de travailler en entreprise, mais je navais encore jamais travaill dans un centre de recherche. Ceci ma permi dapprhender ltendue des domaines couverts par le LORIA. Par ailleurs, ce stage ma fourni loccasion dencadrer un stagiaire IUT pendant trois mois. Cette exprience ma fait ctoyer de prs les difficults de lencadrement et de la gestion de projet. En effet, lors de mes prcdents stages en entreprise, jai toujours eu un suprieur qui savait assez prcisment ce dont il avait besoin. Javais un cahier des charges strict, imposant de nombreuses contraintes. Quand javais oprer des choix techniques ayant des implications sur le rsultat final, je pouvais demander mes collaborateurs leur avis, et choisir ainsi la solution la plus profitable. Pour la premire fois, personne ne pouvait me donner dorientation lorsquil fallait choisir entre deux possibilits ayant chacune des rpercussions diffrentes. Il ne mtait encore jamais arriv de prendre par moi-mme des dcisions influenant aussi profondment le rsultat final. Enfin, dans le cadre de ce projet jai pu mettre en pratique les connaissances en programmation distribue acquises au cours de ma formation, les concepts et pratiques de la modlisation oriente objet et, pour finir, mettre en avant mes qualits dencadrement et de gestion de projet.

2 LE LORIA
2.1 PRESENTATION
Le Laboratoire Lorrain de Recherche en Informatique et ses Applications (LORIA) est une unit mixte de recherche (UMR 7503) commune au CNRS (Centre National de la Recherche Scientifique), l'INRIA (Institut National de Recherche en Informatique et en Automatique), l'INPL (Institut National Polytechnique de Lorraine), et aux universits Henri Poincar, Nancy 1 et Nancy 2. Cette unit, dont la cration a t officialise le 19 dcembre 1997 par la signature du contrat quadriennal avec le Ministre de l'ducation Nationale, de la Recherche et de la Technologie et par une convention entre les cinq partenaires, succde ainsi au Centre de Recherche en Informatique de Nancy (CRIN), et aux quipes communes entre celui-ci et l'Unit de Recherche INRIA de Lorraine. Le LORIA est situ sur le campus de la facults de sciences de Nancy, ct de la bibliothque universitaire.

2.2 ORGANISATION
Depuis le 1er janvier 2001, c'est Hlne KIRCHNER qui dirige le LORIA. Actuellement plus de 300 personnes travaillent dans le laboratoire. Ces personnels sont rpartis en 21 quipes de recherche et 7 services d'aide la recherche. Chaque quipe rassemble des chercheurs, des doctorants et des assistants techniques ou administratifs, pour la ralisation d'un projet de recherche. Cinq instances ont t mises en place pour assister le directeur du laboratoire, garantir la cohrence de la politique scientifique et le bon fonctionnement au quotidien : l'quipe de Direction : compose de plusieurs membres du laboratoire, elle assiste la Directrice dans ses fonctions ; le Comit de Gestion : compos des chefs de service, il assiste le directeur dans le fonctionnement journalier du LORIA ; le Comit des Projets : il conseille le Directeur sur la politique scientifique du LORIA, participe l'valuation des projets/quipes, et instruit les restructurations ncessaires ; le Conseil du LORIA : il met des avis sur la politique scientifique mise en uvre par le Comit des Projets. Sa composition est fixe par les statuts d'UMR. ; le Conseil des Orientations Scientifiques : compos de reprsentants des quipes de recherche, il conseille la Direction dans la gestion scientifique du laboratoire.

2.3 PERSONNELS
Le LORIA est une Unit Mixte de Recherche (UMR 7503) associant les personnels et les moyens des cinq tablissements suivants : CNRS : Centre National de la Recherche Scientifique INPL : Institut National Polytechnique de Lorraine INRIA :Institut National de Recherche en Informatique et en Automatique UHP : Universit Henri Poincar, Nancy 1 Nancy 2 : Universit Nancy 2 Le LORIA regroupe plus de 300 personnes rpartis comme le montrent les Figure 1 et Figure 2.

Rpartition du personnel par statuts

53

Chercheurs permanents
61 109

Thsards ITA Post-Doc, ingnieurs experts, membres associs

94

Figure 1 : rpartition du personnel par statuts (Les chiffres de la Figure 1 ne comprennent pas les projets INRIA Messins et de l'IECN)

Rpartition du personnel par tablissement de rattachement

73 24 40 165

INRIA UHP INPL

43

CNRS Nancy 2 Divers

64

Figure 2 : rpartition du personnel par tablissement de rattachement

LEQUIPE
3.1 PRESENTATION
L'objectif du projet Langue et Dialogue est de dfinir des modles et des techniques permettant de mettre en uvre court, moyen ou long terme des systmes de dialogue homme machine finaliss reposant sur une forte composante langagire. Dans ce cadre, son activit se dveloppe dans trois directions complmentaires : l'tude des mcanismes fondamentaux de la communication en langue naturelle seule ou accompagne d'une dsignation gestuelle (dialogue multimodal). Cette recherche s'effectue dans un contexte pluri-disciplinaire alliant linguistique et informatique principalement ; la ralisation de systmes de dialogue effectifs dans le cadre notamment de collaborations industrielles. Cette activit permet par ailleurs de disposer d'une plate-forme d'exprimentation pour la validation des diffrents modles conus par lquipe ; la dfinition d'outils et de mthodes gnriques permettant d'tudier de faon fine des situations de dialogues rels, issus de la transcription d'expriences de simulation ou d'observations directes. Ce travail s'appuie sur une exprience acquise depuis plusieurs annes sur la normalisation et la manipulation de ressources linguistiques (en particulier des corpus ). Lquipe restreint son ambition du DHM finalis, c'est--dire ddi la commande, l'apprentissage ou la recherche d'informations dans un domaine clairement spcifi ; cela suppose que l'on peut expliciter compltement l'action - ou plus gnralement l'intention - vise par l'utilisateur, de manire ce qu'elle puisse tre ralise par le systme . Il ne s'agit, cependant, pas de se limiter l'emploi de quelques bribes de langage naturel pour apporter une consonance naturelle. Les recherches que lquipe mne visent long terme mettre en uvre une vritable communication en langue naturelle entre un usager et une machine. Le choix de partir de l'hypothse d'un dialogue oral - mme si lquipe n'effectue pas de recherche sur la parole proprement dite - rsulte de la volont de grer au plus prs la dynamique de la tche et correspond l'exprience acquise par les chercheurs du groupe dans la prise en compte des aspects temporels dans la langue ainsi que de phnomnes plus particuliers tels que la dixis, que l'on peut observer par exemple dans des expriences de simulation de dialogues oraux. De fait, il semble important, dans un souci de respect de la spontanit des utilisateurs potentiels de leurs systmes, de savoir modliser les modes de rfrenciation immdiate aux diffrentes composantes d'une tche donne, notamment quand celle-ci est visualise sur un cran.

10

3.2 AXES DE RECHERCHE

3.2.1 FONDEMENTS SCIENTIFIQUES 3.2.1.1 BASES THEORIQUES
De quelle faon fonctionne le langage humain ? Quels sont les processus impliqus lorsque deux personnes engagent un dialogue ? Comment font-ils exactement pour se comprendre ? Est-il possible de modliser de telles interactions sur ordinateur, et dans l'affirmative, quels sont les mthodes et outils dfinir? De telles questions soulvent tout un ensemble de problmes scientifiques, relatifs par exemple au fonctionnement sonore des langues humaines (phonologie), ou l'organisation de leurs structures grammaticales (syntaxe). L'quipe Langue et Dialogue sintresse plus particulirement aux aspects smantiques et pragmatiques associs ces questions, et aux problmes informatiques associs.

3.2.1.2 SEMANTIQUE ET INFERENCE

Les progrs venir dans le domaine de la smantique des langues naturelles dpendent troitement de la comprhension du rle jou par les phnomnes d'infrence. Au niveau le plus simple, l'infrence peut tre vue comme un mcanisme de dsambigusation. Les noncs en langue naturelle sont en effet extrmement ambigus: les opration d'infrence, notamment lexicale, permettent ainsi d'liminer les reprsentations incorrectes (d'un point de vue smantique). Mais l'infrence peut aussi tre utilise pour des processus plus subtils, pour par exemple intgrer des informations nouvelles dans un contexte dj connu. Inversement, dans le cas de la gnration d'noncs en langue naturelle, comment s'assurer que l'noncs courant convient, tant donn les connaissances pralables du locuteur et du destinataire? L'quipe Langue et Dialogue explore ces problmes sous plusieurs perspectives et ce sur la base d'approches mthodologiques complmentaires (modlisation base de logiques modales, ou tudes de donnes exprimentales).

3.2.1.3 MULTIMODALITE
Les langues s'emploient toujours dans des contextes rels qui sont par essence multimodaux, c'est--dire intgrant d'autres canaux de communication que la parole ou le texte proprement dit. Pour le moins, des interlocuteurs en situation de dialogue sont toujours situs dans un endroit identifis, un certain moment dans le temps, et ont une conscience mutuelle de leur environnement. L'exploitation de ces informations dans le dialogue leur permet de communiquer avec plus d'efficacit. Les thories contemporaines en smantique commencent peine intgrer ces. L'approche envisage par Langue et Dialogue de la multimodalit reste fortement ancre sur la complmentarit des autres informations avec le matriau linguistique. Elle vise dfinir une description unifie des diffrentes sources d'information qui puisse conduire au dveloppement d'un modle d'interprtation d'noncs en contexte qui soit indpendant des

11

modes de ralisation. Par ailleurs, l'utilisation des logiques de description semble un cadre adquat pour l'intgration des modes sur la base de modles conceptuels unifis.

3.2.1.4 INGENIERIE LINGUISTIQUE

Les implmentations ralises au sein de l'quipe ont un rle important au del du simple apport de nouvelles applications. Elles permettent d'apprhender rellement la complexit inhrente la gestion des phnomnes smantiques et pragmatiques des langues naturelles. Lquipe peut ainsi exprimenter les interactions entre diffrentes sources d'information (par exemple entre contenus lexicaux et ontologies propres un domaine d'application). L'approche envisage au sein de l'quipe est de dvelopper des plates-formes ouvertes intgrant des composants ou des outils correspondant l'tat de l'art en la matire. Cette approche, qui s'applique tout aussi bien la dfinition de systme de traitement des langues naturelles qu' l'intgration de systmes de dialogue homme-machine, repose la fois sur des protocoles standards (par exemple SOAP) et sur des donnes parfaitement spcifies (pour la reprsentation des contenus multimodaux par exemple). Par itration, on peut ainsi intgrer des composants de plus en plus riches d'un point de vue conceptuel et tendre vritablement vers une ingnierie linguistique raisonne. De faon complmentaire, une telle approche ne fait sens que s'il existe des normes internationales pour la reprsentation des donnes linguistiques, ce qui explique l'implication forte de l'quipe dans cette direction.

3.2.1.5 ETUDES EMPIRIQUES

Le rle des mthodes empiriques (apprentissage de modles, extraction de connaissances partir de corpus, valuation) n'a fait que crotre dans le domaine de l'informatique linguistique au cours des 15 dernires annes. L'quipe Langue et Dialogue est dans ce cadre reconnue depuis des annes pour avoir uvr la cration, la gestion et la diffusion de ressources linguistiques rutilisables par la communaut scientifique, qu'il s'agisse dans le cadre de la mise en uvre de serveurs de donnes (par exemple au travers du projet SILFIDE), ou de la dfinition de formats de reprsentation standardise (par exemple TAGML). Ses travaux dans ce sens accompagnent constamment son projet scientifique, qu'il s'agisse au niveau de la description de donnes lexicales rutilisables (pour la paramtrisation de systmes de dialogue homme-machine par exemple), l'tude de phnomnes fins en smantique (par la constitution de suites de test), ou l'annotation de corpus dans le cadre d'tudes en analyse ou en gnration (tude de la rfrence).

12

3.2.2 DOMAINES D'APPLICATION 3.2.2.1 ANALYSE

Depuis plusieurs annes (et la suite de la thse de Patrice Lopez), l'quipe LED travaille l'analyse syntaxique des langues naturelles. Dans ce cadre, ils maintiennent un analyseur de grammaires d'arbres adjoints permettant l'analyse partielle d'noncs. Cet analyseur est par exemple utilis dans le projet XMiner (analyse de dossiers mdicaux) o on a affaire des noncs trs incomplets. Connexe cet analyseur, LED dveloppe des outils permettant la maintenance de grammaires. C'est dans ce cadre que quelle vise l'intgration de logiques modales de description d'arbres, soit en vue de dcrire une grammaire TAG de faon plus abstraite, soit en vue de faire directement de l'analyse. L'analyse syntaxique n'tant pas une fin en soi, notre souci est de travailler sur des modles permettant le plus facilement possible de construire une interprtation smantique. De l notre intrt pour l'utilisation de grammaires d'arbres adjoints dans l'analyse syntaxique intgre des systmes de dialogue homme-machine.

3.2.2.2 GENERATION
Pour de nombreuses applications informatiques, les donnes de toutes natures qui sont produites sont des donnes complexes difficiles interprter par le non expert. Un gnrateur de textes, qui prend en entre ces donnes et produit un texte exprimant le contenu de ces donnes en langue naturelle, permet d'adresser ce problme. Le problme de la gnration de texte est essentiellement un problme de choix: tant donns une multitude de paramtres linguistiques (e.g. , ordonnancement des phrases et des constituants, choix des units et des catgories lexicales) et extra-linguistiques (contexte situationel, connaissance du monde, profil de l'utilisateur), le problme est de fixer les bonnes valeurs pour l'ensemble de ces paramtres. Un texte de bonne qualit sera alors un texte pour lequel le gnrateur a fait les bons choix. Comme l'a montr en particulier le travail de Matthew Stone, la ralisation de textes de bonne qualit passe en outre par une interaction troite entre gnration, reprsentation des connaissances et infrence. On a besoin de cette interaction par exemple pour : vrifier que les prsuppositions du texte gnr soient satisfaites par le contexte nonciatoire ; pour dcider des mots les plus appropris tant donn ce contexte (problme de la lexicalisation) ; construire des rponses dites coopratives cest--dire des rponses qui vont au-del du simple oui / non ou de l'numration et soit corrigent une mauvaise conception de l'utilisateur, soit fournissent une rponse partielle lorsqu'une rponse directe la question pose n'est pas possible.

13

Cette interaction entre gnration et infrence constitue l'un des thmes de recherche de LED.

3.2.2.3 INFERENCE ET DISCOURS

Pour simplifier, faire une infrence signifie extraire de l'information implicite partir d'une information explicite. Il existe diffrents types d'infrences. Par exemple, l'infrence statistique utilise un ensemble large de schmas trouvs dans des corpus afin de dterminer l'information qu'on aura probablement propos d'un petit exemple. Un autre type d'infrence est l'infrence logique. Par exemple, si notre base de connaissances contient explicitement que "tous les tueurs gage sont violents" et que "Vincent est un tueur gages", alors elle contient implicitement l'information que "Vincent est violent". L'infrence logique et l'infrence statistique (et, en ralit, beaucoup d'autres formes d'infrences) sont pertinentes dans le discours. L'quipe Langue et Dialogue tudie actuellement l'utilisation de l'infrence logique. Ces dernires annes, les performances des outils de raisonnement automatis (c'est dire des logiciels qui traitent les diffrents types d'infrence logique) ont considrablement augment. Les prouveurs de thormes atteignent des niveaux de performance inimaginables il y a dix ans. De plus, la technologie de construction de modles, bien que moins avance, a atteint un stade o elle constitue un intressant outil d'exprimentation. Ces progrs ont t faits pour un grand nombre de formalismes de reprsentation smantique utiles comme la logique du premier ordre, les logiques de descriptions ou les logiques hybrides. L'utilisation la plus vidente de l'infrence logique dans le discours est la dsambigusation. Les noncs en langue naturelle sont trs frquemment ambigus. En fait, l'interaction entre l'ambigut lexicale, l'ambigut syntaxique et l'ambigut de porte peut amener une phrase avoir une centaine d'interprtations possibles, mme si la plupart de ces interprtations sont absurdes tant donn nos connaissances encyclopdiques d'arrire-plan. Les prouveurs de thormes et les gnrateurs de modles vrifient les diffrentes interprtations et liminent celles qui sont incompatibles avec le reste du discours. Parfois, il est aussi intressant de tester si la reprsentation nous apporte quelque chose de vraiment nouveau ou si elle provient de ce que nous savons dj. Les prouveurs de thormes et les gnrateurs de modles sont aussi utiles pour accomplir ce type de tche. Les programmes CURT (Blackburn et Bos) constituent une srie de programmes qui illustrent ces diverses possibilits. L&D est aussi concerne par des utilisations plus exprimentales de ces technologies. Par exemple, elle essaye d'utiliser les gnrateurs de modles pour deviner quoi ressemble une situation dcrite (en gnrant le plus petit modle possible pour cette situation). De telles approches constituent une faon intressante de traiter des problmes comme les infrences mises en jeu dans les anaphores associatives.

3.2.2.4 DIALOGUE MULTIMODAL

La conception de systmes de dialogues multimodaux s'appuie sur une tude fine des phnomnes de co-articulation entre langue et geste.

14

Dans le type de dialogue considr (dialogue de commande), la rfrence aux objets et aux actions constitue l'lment fondamental de toute interprtation. Par ailleurs, il apparat clairement que l'on ne peut tudier les actes de rfrence sans se proccuper de la manire dont l'utilisateur peroit visuellement les objets dont il parle. Ceci amne tout naturellement l'tude conjointe des acteurs que sont : la langue, le geste et la perception visuelle. La langue : on s'intresse spcifiquement aux noncs accompagns d'un geste de dsignation et plus prcisment aux expressions rfrentielles servant de support au geste de dsignation. Le geste : l'objectif est de pouvoir partir de donnes fournies par un dispositif gestuel (ex. souris, cran tactile, interface haptique) de reconstituer une trajectoire partir de laquelle les objets susceptibles d'tre dsigns sont mis en vidence. La perception visuelle : on s'intresse ici la configuration spatiale des objets affichs sur une scne. Il est vident que cette dernire conditionne la forme de la trajectoire mais aussi le choix de l'expression rfrentielle. L'tude de ces trois acteurs fournit des informations essentielles quant au rle de chacun d'entre eux dans l'acte de co-rfrence, informations partir desquelles il est possible de proposer une modlisation du processus d'interprtation menant de l'nonc multimodal l'identification des rfrents (rsolution des rfrences). Depuis environ une dizaine d'anne, LED mne des travaux en ce sens qui ont permis d'apporter des avances diffrents niveaux de conception des systmes de dialogues multimodaux. Aujourd'hui, ses priorits de recherche peuvent se dcliner comme suit : Description gnrale du geste : il s'agit de proposer une modlisation du geste indpendante du dispositif c'est--dire de mettre en vidence les mcanismes fondamentaux qui rgissent la forme des trajectoires en fonction du contexte visuel. Smantique formelle : l'objectif est ici de proposer une modlisation abstraite des contraintes issues des diffrents acteurs intervenant dans l'acte de co-rfrence : a. Focalisation du geste : le geste de dsignation a pour objet de fournir une focalisation sur un sous-espace de l'espace visuel partag entre l'utilisateur et la machine. Cette focalisation prend appuie sur la forme de la trajectoire et sur les caractristiques de la configuration spatiale ; Structuration de l'espace visuel : pour interprter un geste, il est indispensable de disposer d'une modlisation de ce que peroit l'utilisateur de la scne affich sur l'cran de la machine. En effet, un geste vague ne pourra tre compris que si cette imprcision est compense soit par une information prcise de l'nonc langagier qui l'accompagne soit par des caractristiques de saillance forte de la scne. Classification fournie par la langue : le type des rfrents est souvent contenu dans l'expression rfrentielle langagire et donne un

b.

c.

15

lment de filtrage appliquer sur les objets candidats la rfrence. Quand ce n'est pas le cas, cette information peut aussi tre recherche au niveau du prdicat de l'nonc. Intgration smantique des modalits : disposant des diffrentes contraintes nonces prcdemment (contraintes de focalisation, contraintes de saillance, contraintes de type) se pose la question de dterminer le principe qui va guider l'intgration de toutes ces contraintes pour aboutir l'interprtation de l'nonc multimodal. Ainsi LED sappuie sur la thorie de la pertinence qui fournit des heuristiques permettant de rduire l'espace de recherche aux lments les plus pertinents par rapport au contexte d'nonciation. Architecture : l'implantation d'un systme de dialogue multimodal repose sur un ensemble de modules ddis la ralisation de tches spcifiques (tels que traitement des entres : parole, geste, gestion du dialogue, ) mais qui sont nanmoins coopratifs. Cette coopration suppose la circulation d'un flux d'information qui pour tre possible doit s'appuyer sur un langage homogne d'interfaage entre les modules tel que le langage MIL.

3.2.2.5 RESSOURCES LINGUISTIQUES ET MULTIMEDIAS

Grer des ressources linguistiques normalises reprsente pour LED la fois un moyen de valider, par l'observation, ses modles thoriques et une source gnrique d'information (par exemple lexicale) pour les prototypes quelle dveloppe. Plus globalement, lquipe pense quil est ncessaire, dune part, de contribuer activement la dfinition de normes plus approfondies dans le domaine de lingnierie linguistique et, dautre part de participer la dissmination des cadres normatifs existants. C'est ce titre que le projet Langue et Dialogue occupe ainsi une place active au sein de la communaut nationale et internationale dans le domaine de la normalisation des ressources linguistiques et de leur utilisation.

3.3 RELATIONS SCIENTIFIQUES ET INDUSTRIELLES

Conventions avec THOMSON-LCR, ALCATEL BS, la DGLF (Dlgation Gnrale la Langue Franaise), SHOM (Service Hydrographique et Ocanographique de la Marine). Projets internationaux : ELAN (programme MLIS), TMC (convention ESRC-CNRS), TELRI (Trans European Language Resource Infrastructure, programme Copernicus), SILFIDE (action commune lAUPELF UREF et au CNRS). Participation au GRD-PRC Communication homme-machine ; participation et animation du GIS "Sciences de la Cognition". Universits de Namur, Genve, College London, Southampton, Sheffield, HCRC Edinburgh, DFKI Sarrebruck, Institut f r Deutsche Sprache Mannheim,...

16

4 LE POINT SUR LA TECHNOLOGIE

4.1 HISTORIQUE DES RESEAUX
4.1.1 LE SYSTEME CENTRAL
Dans un systme central, la logique de traitement se situe sur la machine serveur ou hte, l'utilisateur interagissant avec celui-ci au travers d'un terminal PC ou passif en mode caractre gnralement.

Station de travail

Serveur

Station de travail

Station de travail

Figure 3 : le systme central Inconvnients : Cot exorbitant Systme propritaire

4.1.2 LE MODELE CLIENT SERVEUR

Le client-serveur est une volution du Mainframe et permet par l'utilisation de nouvelles mthodes et techniques de passer outre les limites que l'on connaissait avec l'environnement Mainframe et les systmes propritaires et ainsi d'amliorer l'interoprabilit, la flexibilit des systmes. Dans une architecture client-serveur, le client est dfini comme un demandeur de services auprs du serveur qui en est le fournisseur. L'architecture client-serveur gnralement utilise aujourd'hui repose sur un modle d'architecture distribue bipartite. L'interface graphique se situe sur le poste client et la base de donnes est localise sur le serveur. La logique de traitement pouvant se situer sur l'une ou l'autre des parties. L'utilisateur final contrle le poste client qui ralise une grande partie des traitements de l'application et sollicite des informations ou des traitements de la part dun ou plusieurs serveurs. Ce type d'architecture est une bonne solution d'informatique distribue lorsque le nombre d'utilisateurs ne dpasse pas une centaine d'utilisateurs, cependant il existe d'une part une limite tenant au fait que la connexion est maintenue en permanence entre le client et le serveur, mme si aucun travail n'est effectu. Dautre part les procdures d'accs aux donnes tant spcifiques aux moteurs de base de donnes, la flexibilit et le choix d'une base de donnes sont rduites. L'architecture tripartite permet de dpasser ces limites, et d'apporter une meilleure ractivit de l'entreprise en cas de changements.

17

Donnes

TCP/

IP

/IP TCP

Serveurs
TCP/IP

Windows
Figure 4 : le modle client-serveur bi-partite Dans l'architecture trois tiers ou multi-tiers, un niveau supplmentaire est ajout entre les deux niveaux prcdents, permettant de sparer les traitements de l'interface graphique et du serveur de base de donnes. Ce niveau intermdiaire peut tre implment de diffrentes manires entre moniteur transactionnel, serveur de messages, ou serveur d'applications. Le dialogue peut se faire en mode synchrone ou en mode asynchrone, dans ce cas l'utilisateur est inform lors d'une nouvelle connexion du rsultat de sa requte prcdente. L'architecture tripartite supporte de la centaine d'utilisateurs plusieurs milliers accdant plusieurs serveurs rpartis gographiquement. La division de l'application en couches distinctes, consacres l'interface utilisateur graphique, la logique de gestion (partitionne entre plusieurs processeurs) et aux traitements sur la base de donnes permet de faciliter l'extension et la maintenance des applications tout en offrant un moyen d'intgration des nouvelles applications aux systmes existants. Ce gain engendre toutefois des tches plus complexes d'administration des composants de l'architecture (clients, serveurs et quipement rseau) ou du dploiement de l'application vers les serveurs.

18

Donnes

Serveurs

TCP/I P

TCP

/IP

Serveurs
TCP/IP

Windows
Figure 5 : modle client-serveur tri-partite Avantages : Rapidit Optimisation des traitements Inconvnients : Choix de plateforme Evolutivit difficile Gourmand en ressources systmes

4.1.3 LE MODELE INTERNET

L'Internet est actuellement le plus grand rseau informatique sur la plante. Il peut tre considr comme le rseau des rseaux. Il est n en 1969, lorsque le dpartement Amricain de la dfense (DoD) dcida d'investir des fonds pour dvelopper un rseau exprimental permettant l'change d'informations entre des sites loigns de recherche et de dveloppement et pouvant fonctionner sans interruption, mme en cas de destruction partielle du rseau. Le rseau ARPANET (Advanced Research Projects Agency NETwork) est alors n. Cette technologie permet partir d'un logiciel client appel navigateur (ou browser) d'accder facilement des documents stocks sur un serveur distant connect l'Internet. Avec le Web, l'Internet s'ouvre au grand public et ne ncessite plus de connaissances spcifiques en informatique. Le modle Internet est celui du client-serveur, o un programme client permet un utilisateur de soumettre des requtes un serveur Web et de visualiser le rsultat, le serveur Web tant un programme qui tourne sur un ordinateur dans 19

le but de rpondre des requtes de logiciel client qui tournent sur d'autres ordinateurs.

Serveur Internet
HT

TP

TT P

HTTP

iMac

UNIX Windows MAC OS

Figure 6 : le modle Internet Avantages : Multi-plateforme Idale pour de la consultation Facilit de mise en uvre Maintenance aise Inconvnients : Petits fichiers Petits traitements Traitement local quasi inexistant

4.1.4 LE MODELE WEBSERVICES

Cest la synthse actuelle entre le modle client-serveur classique et le modle Internet. Cette architecture consiste mutualiser les traitements les plus communs (services) sur un serveur accessible depuis lInternet (WEB). Les clients qui effectuent des traitement spcifiques peuvent tout moment dlguer les tches gnrales un ou plusieurs WebServices et rintgrer le rsultat leur traitement de faon transparente. Cette technologie est trs rcente (2001 : Microsoft .NET, 2002 : SUN Java WebServices). Cependant, il est noter que cest la premire fois dans lhistoire de linformatique quun concept dcoule de lutilisation quon fait dune technologie. Jamais auparavant, la technique ntait l pour confirmer la thorie.

20

Serveurs Internet
SO AP

AP

SOAP

SO

iMac

UNIX MAC OS Windows Figure 7 : le modle WebServices

Avantages : Multi-plateforme Multi-application Grande volutivit Echange de donnes normalises Inconvenients : Technique relativement rcente

4.2 LA TECHNOLOGIE JWSDP

4.2.1 GENERALITES
Le "Java Web Services Developer Pack" (JWSDP) de Sun vous permet d'crire des applications de services web intgralement en langage de programmation Java; le nombre et la complexit des outils peuvent toutefois intimider les programmeurs JWSDP novices. JWSDP supporte les standards de l'industrie, garantissant l'interoprabilit avec les technologies et spcifications cres par les organismes de normalisation, tels que le consortium W3C (World Wide Web Consortium) et l'OASIS (Organization for the Advancement of Structured Information Standards). JWSDP fournit galement plusieurs outils annexes, tel qu'un compilateur d'lments de remplacement WSDL qui gnre un fichier WSDL pour un service web, ainsi qu'un registre UDDI 2.0 de service web autonome. Le JWSDP est fourni avec Apache Tomcat et certaines tches Ant, ce qui vous permet de rfrencer et de grer des services web dans Tomcat. Les interfaces de programmation de JWSDP sont gnralement classes en deux grandes catgories : celles qui concernent les documents XML et celles qui se rapportent aux procdures distance.

21

4.2.2 LES API

Les API orientes documents sont: Java API for XML Processing (JAXP); Java Architecture for XML Binding (JAXB). Les API orientes procdures distance sont: Java API for XML-based RPC (JAX-RPC); Java API for XML Registries (JAXR); Java API for XML Messaging (JAXM). Analysons en dtail chaque ensemble d'API et voyons ce que chacune peut nous permettre de faire.

4.2.2.1 JAXP
JAXP expose des API connectables d'analyse et de transformation de documents XML quel que soit le processeur XML.

4.2.2.2 JAXB
JAXB expose des API permettant le dveloppement d'applications Java XML. JAXB propose des outils, des API et des environnements pour mapper des documents XML et des objets Java. Un compilateur est fourni pour la conversion de schmas XML en classes Java. L'environnement de liaison permet de contrler les erreurs et la validit des documents XML entrants et sortants.

4.2.2.3 JAX-RPC
JAX-RPC expose des API pour dvelopper des clients et endpoints de service web bass sur SOAP. JAX-RPC est un package requis de la plateforme J2EE 1.4.

4.2.2.4 JAXR
JAXR expose des API pour l'accs, les requtes et l'dition de registres XML.

22

4.2.2.5 JAXM
Le package JAXM expose des API d'envoi et de rception de messages XML orients documents. JAXM supporte la messagerie SOAP 1.1 "with Attachments" (avec pices jointes). JAXM fonctionne avec des profils de messagerie, tel que le service de traitement des messages Transport, Routing & Packaging (transport, routage, enveloppe) d'ebXML. Ce concept ouvre la voie au support de protocoles de messagerie bass sur les standards.

4.2.2.6 SAAJ
SAAJ complte JAXM pour permettre aux dveloppeurs de produire et exploiter des messages SOAP "with Attachments".

4.2.3 INSTALLATION DU JWSDP 4.2.3.1 INSTALLATION DE JAVA

Installer le JDK 1.4.2 disponible sur java.sun.com.

4.2.3.2 INSTALLATION DU PACK

Installer le java web servicies http://java.sun.com/webservices/ developer pack 1.2 disponible sur

4.2.3.3 VARIABLES DENVIRONNEMENT

Dclarer les variables denvironnement suivante Sous Mac OsX et Linux edition du fichier .cshrc : setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.4.1/Home setenv JWSDP_HOME /jwsdp-1.2 setenv UNISTALL_JAR_FILE $JWSDP_HOME/_uninst/unistall.jar setenv ANT_HOME $JWSDP_HOME/apache-ant setenv path=($path $ANT_HOME/bin $JWSDP_HOME/bin $JWSDP_HOME/jwsdp-shared/bin $JWSDP_HOME/jaxrpc/bin) puis commande : source .cshrc Sous Windows 2000 JAVA_HOME C:\Dev\j2sdk1.4.1 JWSDP_HOME C:\Dev\jwsdp-1.2 UNINSTALL_JAR_FILE %JWSDP_HOME%\_uninst\unistall.jar ANT_HOME %JWSDP_HOME%\apache-ant PATH %JWSDP_HOME%\bin;%JWSDP_HOME%/jaxrpc/bin; %JWSDP_HOME%\jwsdp-shared\bin;%ANT_HOME%\bin;

4.2.3.4 LANCEMENT DU SERVEUR

Lancer le serveur Tomcat en excutant la commande startup.bat (Windows) ou ./startup.sh (MacOsX ou Linux) dans le rpertoire JWSDP_HOME/bin.

23

Vous pouvez maintenant accder la page daccueil du JWSDP via ladresse locale suivante : http://127.0.0.1:8080 (Figure 8 : la page d'accueil du JWSDP).

Figure 8 : la page d'accueil du JWSDP

4.2.4 SERVER ADMINISTRATION

Ladministration du serveur Tomcat se fait via une interface web en local. Cette interface est fournie avec Tomcat 5.0.

Cest avec cet outil que peuvent tre appliques, entre autres, les politiques de scurit, le dploiement des services, la redirection des erreurs, les sources de donnes.

24

4.2.5 WEB APPLICATION MANAGER

Le gestionnaire dapplication JWSDP permet de dployer rapidement des applications web sous JWSDP. Il suffit pour cela de disposer du .war de lapplication dployer et de le charger via linterface web du gestionnaire dapplication. On observera aussi en temps rel le fonctionnement des applications dployes et le nombre de sessions ouvertes par service.

25

5 LE PROJET DIGITAL MUSEUM

5.1 PRESENTATION
Le projet Digital Museum est un projet de muse numrique dvelopp en partenariat avec la National Chi Nan University de Tawan. Il sagit de mettre en uvre une architecture distribue base sur des serveurs de ressources multimdia. Les serveurs dissmins travers le monde et grs par des Administrateurs permettent aux Designers de crer des prsentations musographiques partir des ressources de leur choix. Cette architecture permettra par exemple un Designer de raliser une exposition sur la peinture du XIXe sicle autour du monde. Le projet repose sur le principe des caddies. Un caddie est comparable au caddie de supermarch, la diffrence prs que le designer remplit ses caddies de ressources multimdia collectes aux quatre coins de la plante. Une fois que le designer a charg ses caddies, il cr une prsentation musographique grce leur contenu.

Institut National de la Langue Franaise University of Birmingham, Department of English, School of Humanities

Ressources multimdia

Instituut voor Nederlandse Lexicologie

Ressources multimdia

SOAP

Ressources multimdia

Ressources multimdia

Instituto di Linguistica Computazionale

Figure 9 : schma du projet Digital Museum Mon travail : Conception et dveloppement d'une maquette de CMF (Content Management Framework) pour le partage de ressources multimdia. Projet "Digital Museum" avec la "National Chi Nan University" de Taiwan.

26

5.2 ARCHITECTURE GENERALE

Celle-ci se dcompose en 5 parties : La couche de persistance (connection) Ladministration des donnes (admin) Le Web service du muse (DigitalMuseum) Le proxy Le Designer
Museum Admin

Connection

HTTP Administrator

J S P

Data

DigitalMuseum XML

Exibition Designer

Proxy

SO AP

Designer

S W I N G

X H T M L SMIL

H TTP

HTTP RTSP client

Figure 10 : architecture gnrale du projet

5.3 LA COUCHE DE PERSISTANCE (CONNECTION)

5.3.1 LE CONCEPT
Crer une interface permettant de manipuler indiffremment plusieurs types de persistance des donnes (base relationnelle, XML)

5.3.2 LARCHITECTURE
La couche de persistance prend la forme dun package dans la partie administration. Nous avons choisi dappliquer le design pattern factory qui nous permet de manipuler indiffremment et dynamiquement lune ou lautre des implmentations de persistance (XML ou BDD). Voici le diagramme de classe correspondant :

27

ConnectionLayer getConnection(name : String, host : String, port : Integer, database : String, user : String, password : String) : ConnectionLayer connect(name : String) : ConnectionLayer insert(table : String, fields : Enumeration) : Boolean delete(table : String, id : Integer) : Boolean update(table : String, id : Integer, values : Enumeration) : Boolean select(table : String, fields : Enumeration, constraints : String) : Collection

ConnectionJDBC ConnectionJDBC()

ConnectionXind ConnectionXind()

JDBCKit make()

ConnectionDat a

XindKit make()

ConfigParser

ConnectionKit mak e()

5.3.3 LA GRAMMAIRE
Pour raliser cette interface il nous faut concevoir un langage dinterrogation et de manipulation commun aux diffrents types de persistance. Ce langage devra donc combiner des structures de type SQL et Xpath. Expression Constraint Link Colonne Digitoperator Digitval Alphaoperator Alphaval Lowalpha Digit Colchar ::= constraint | expression link expression | (expression) ::= colonne digitoperator digitval | colonne alphaoperator alphaval ::= and | or ::= (lowalpha|digit|colchar)* ::= <,>,>=,<=,!=,= ::= digit* ::= =,!=,~ ::= [<any char but brackets>*] ::= <a..z> ::= <0..9> ::= <_>

5.3.4 LES DIFFICULTES RENCONTREES

Nous avons souhait implanter la partie Xindice (Base de donne en XML) mais il semble que la version 1.0 ne soit pas au point. Par exemple, la slection avec discriminent ne marche pas. De plus le modle XML a tendance fusionner les tables lors de relations 1n. Il faudra donc trouver une grammaire et un parser suffisamment souples pour interprter correctement lunion.

28

5.3.5 UN EXEMPLE DE CODE

ConnectionKit connKit=new JDBCKit(); ConnectionLayer conn = connKit.make(); String table = "resource"; String constraints = "(type=[img] or type=[video])"; Collection resultat = conn.select(table,null,constraints);

5.4 LADMINISTRATION DES DONNEES (ADMIN)

5.4.1 LE CONCEPT
Obtenir une interface dadministration centralise et scurise. Nous avons choisi dutiliser des Java Server Pages (JSP) en complment de JavaBean afin de construire la partie dadministration des ressources multimdias.

5.4.2 LARCHITECTURE
La partie administration est une interface entre les JSP et la couche de persistance. Elle est compose de 3 Java Beans jouant ainsi le rle de cache pour les donnes.

Figure 11 : architecture de la partie administration

5.4.3 LES JAVA BEANS

Les Java Beans sont une construction spcifique de classe Java, disposant de mthodes daccs (les getters et les setters ) pour chaque attribut. Les beans facilitent lintgration de classes Java dans les pages JSP. Vous pouvez voir sur le diagramme de classe suivant, lorganisation des 3 principaux beans utiliss par lapplication serveur :

29

User user_id user_name user_login user_pass user_email user_rights User() setUser_id() setUser_name() setUser_login() setUser_pass() setUser_email() setUser_rights() getUser_id() getUser_name() getUser_login() getUser_pass() getUser_email() getUser_rights() setAllValues() select() insert() update() delete()

Resource res _id : Integer res _type : String res _author : S tring res _year : Integer res _uri : String res _desc : St ring Resource() setRes _id() setRes _type() setRes _author() setRes _uri() setRes _desc() setRes _year() getRes _id() getRes _type() getRes _author() setRes _year() getRes _uri() getRes _desc() setAllValues() select() insert() update() delete()

QueryResource query : String queryType : String queryAut hor : String queryYear : St ring queryKeyW ords : S tring nbKey Words : int QueryResource() setQuery () setQuery Type() setQuery Author() setQuery Year() setQuery Key Words() setNbK eyWords() getQuery () getQuery Type() getQuery Author() getQuery Year() getQuery Key Words() getNbK eyWords() makeQuery() find()

5.4.4 LORGANISATION DES JSP

Le site est articul autour dune page principale, qui fait elle-mme appel (par inclusion) 4 autres pages. Les pages incluses sont : haut.jsp : une page contenant len-tte de la page (barre de menu, boutons). bas .jsp : une page contenant le pied de page courant (copyright). page.jsp : la page incluse dpend des actions de lutilisateur. Il peut par exemple sagir de la liste des ressources disponibles sur le serveur. action.jsp : cette page nest pas un lment graphique. Elle dpend de laction de lutilisateur, et il sagit toujours dune page dont la fonction est dinteragir avec le serveur (stockage). Par exemple, lorsque vous venez dajouter une nouvelle ressource sur le serveur, vous revenez la liste des ressources disponibles. La page est donc la partie affichant la liste des ressources, l action tant enregistre les information sur la nouvelle ressource dans le serveur .

30

/actions
haut.jsp

connection

Index.jsp

disconnection

Bas.jsp

saveresource

deleteresource

changeresource

/pages

home

about

query

editresource addresource

result

Figure 12: organisation des JSP

5.4.5 LINTERFACE
Page daccueil (Figure 13) : Descriptif du site Digital Museum Accs la rubrique A Propos Possibilit de saisie du login et du mot de passe pour authentification.

Figure 13 : page daccueil

31

Authentification russie (Figure 14): Apparition de 4 nouveaux icons (Recherche, Ajout, Outils et Deconnexion) Affichage dun message personnalis de bienvenue

Figure 14 : authentification russie Recherche (Figure 15) : Formulaire de recherche de ressources multimdia sur le serveur du muse par type et/ou par auteur et/ou par anne et/ou par mots cls (description).

Figure 15 : formulaire de recherche Rsultats (Figure 16) : Ajouter, supprimer, modifier (Figure 17 : modifier une ressource) ou visualiser des ressources multimdias.

Figure 16 : rsultat de recherche

32

Figure 17 : modifier une ressource Ajouter une nouvelle ressource (Figure 18) : Renseigner le type par combo box, lauteur de la ressource, sa date de cration, indiquer son uri et une description de la ressource.

Figure 18 : ajouter une nouvelle ressource

5.5 LE WEB SERVICE MUSEUM (DIGITALMUSEUM)

5.5.1 LE CONCEPT
Disposer dun service accessible depuis le web et destin rechercher des ressources multimdia sur un serveur indpendamment du langage de programmation.

33

5.5.2 LARCHITECTURE
Museum DigitalMuseum (Web Service) DigitalMuseumImpl Connection connection ConJDBC

Data

Remote

DigitalMuseumIF

ConXML

XML

WSDL

Figure 19 : architecture du WebService

5.5.3 LINTERFAAGE ET LIMPLEMENTATION DU SERVICE

Linterface de dfinition du service dclare les mthodes quun client distant (remote client) peut invoquer. Linterface doit tre conforme aux rgles suivantes : elle doit hriter linterface java.rmi.Remote elle ne doit pas dclarer de constantes de type public final static les mthodes doivent dclencher des java.rmi.RemoteException les paramtres et retour de mthodes doivent tre supporte par JAXRPC
<<Interface>> Remote
(from rmi)

<<Interface>> DigitalMuseumIF getResource(query : String) : Collection

DigitalMuseumImpl

5.5.4 LES TYPES SUPPORTES 5.5.4.1 J2SE SDK CLASSES

JAX-RPC supporte les classes J2SE SDK suivantes : java.lang.Boolean java.lang.Byte java.lang.Double java.lang.Float 34

java.lang.Integer java.lang.Long java.lang.Short java.lang.String java.math.BigDecimal java.math.BigInteger java.util.Calendar java.util.Date java.util.Collection Subinterface Implementation Classes : List, ArrayList LinkedList Stack Vector Map, HashMap Hashtable Properties TreeMap Set, HashSet TreeSet

5.5.4.2 PRIMITIVES
JAX-RPC supporte les primitives Java suivantes : boolean byte double float int long short

5.5.4.3 TABLEAUX
JAX-RPC supporte aussi les tableaux de types JAX-RPC types. Exemples de tableaux supports : int[], String[][].

5.5.4.4 APPLICATION CLASSES

JAX-RPC supporte aussi les classes spcialement crites pour votre application. Les spcifications de JAX-RPC se rapportent des classes telles que des types de valeur, parce que leurs valeurs (ou tats) peuvent tre passes entre les clients et les services distance comme paramtres de mthode ou valeurs de retour. Pour tre supporte par JAX-RPC, une classe applicative doit se conformer aux rgles suivantes : Possder un constructeur par dfaut public Ne pas implmenter (directement ou indirectement) linterface java.rmi.Remote Le type de ses attributs doit tre support par JAX-RPC

35

La classe peut contenir des attributs public, private, ou protected. Mais, pour que ces valeurs soient passes (ou retournes) pendant un appel remote, un attribut doit tre compatible avec les spcifications suivantes : Un attribut ne peut pas tre final ou transient Un attribut non public doit possder une mthode getter et setter

5.5.4.5 COMPOSANTS JAVABEANS

JAX-RPC supporte aussi les composants JavaBeans, qui doivent respecter les mmes rgles que les classes dapplication. En plus, un composant JavaBean doit possder un getter et un setter pour chaque proprit du bean. Le type de la proprit du bean doit tre compatible avec les types supports par Jax-RPC.

5.5.5 LES FICHIERS DE CONFIGURATION

Pour compiler correctement, le webservice DigitalMuseum a besoin de fichiers de configuration : Jaxrpc-ri.xml Web.xml

5.5.5.1 JAXRPC-RI.XML
Ce fichier dfinit diffrentes caractristiques du service. Il est utilis par l'outil wsdeploy fourni avec le Java Web Services Developer Pack (Java WSDP). L'attribut webServices doit contenir un ou plusieurs lments endpoint spcifiant la classe de l'implmentation du service, la classe de l'interface du service, le nom du service. L'attribut endpointmapping permet d'associer le service une URL.

Figure 20 : le fichier jaxrpc-ri.xml

5.5.5.2 LE FICHIER WEB.XML

Ce fichier est un descripteur pour la servlet qui va recevoir le service web.

36

Figure 21 : le fichier web.xml

5.5.6 LA COMPILATION ET LE DEPLOIEMENT DU SERVICE

La compilation et le dploiement du service se font en plusieures tapes : compilation de *IF.java et de *Impl.java (ant compile-server) cration du fichier WAR (ant setup-web-inf, ant package) gnration des noeuds et le fichier WSDL (ant process-war) dploiement du service (ant deploy) vrification du dploiement sur http://localhost:8080/museum-jaxrpc/museum

Figure 22 : descripteur du dploiement Toutes les tapes de compilation et dploiement ont t rsumes dans un fichier build.xml appel par ANT.

5.5.7 LE FICHIER WSDL :

Pour faciliter la description des mthodes fournies par un Web Service, le W3C a normalis WSDL (Web Services Description Language). Comme l'IDL pour Corba ou DCOM, WSDL dfinit le contrat de service d'un Web Service. Un fichier WSDL dcrit l'ensemble des mthodes accessibles d'un Web Service ainsi que leur prototypage. Le premier intrt de WSDL est de faciliter la tche aux dveloppeurs. Si un dveloppeur souhaite intgrer un appel un Web Service dans son application, il suffira de lui transmettre le WSDL pour qu'il puisse formuler correctement ses requtes SOAP. Un deuxime intrt est de permettre l'appel dynamique de Web Services. On peut imaginer qu'une application demande le fichier WSDL un Web Service et construise dynamiquement l'appel au service distant.

37

Figure 23 : fichier WSDL du WebService

5.5.8 LA PUBLICATION
Le rfrenceur de services porte le nom d'annuaire UDDI (Universal Description Discovery and Integration). L'objectif de ces annuaires est de rfrencer des services au sein d'une mme entreprise ou sur Internet. L'UDDI Business registry contient une srie d'informations accessibles par trois moyens : les pages blanches donnent les noms, adresses, contacts ... des entreprises rfrences et proposant des Web Services, les pages jaunes informent sur le mtier des entreprises, les types de services que ces dernires proposent, les pages vertes apportent les informations ncessaire l'utilisation des services (description fonctionnelle des mthodes, adresse des services, ...). La publication du WebService permet de le rfrencer sur un serveur distant (UDDI) et ainsi le rendre accessible via des outils de recherche. Dans notre architecture, la dcouverte des WebServices se fait par lintermdiaire du Registry Browser et leur sauvegarde dans le systme via linstanciation dun objet java nomm Server Nous avons choisi de publier notre WebService sur le serveur UDDI de microsoft. Pour cela il faut crer un passeport Microsoft et accder au serveur via une interface web. Ensuite il faut enregistrer le provider (fournisseur de service : lorganisation), un contact, le nom du WebService et enfin le ou les access points

38

Figure 24 : l'interface web de microsoft uddi Lors de la description du webservice il ne faut pas oublier de spcifier une langue (en ou fr) pour chaque sous rubrique car cela a des consquences sur la visibilit du webservice lors de la recherche. Si le Registry Browser est paramtr en franais, seul les webservices dont il existe une description en franais seront visibles.

5.6 LE DESIGNER
5.6.1 LE CONCEPT
Disposer dun module de gestion des ressources par caddies et proposer une interface ddition simple des fichiers SMIL.

5.6.2 LARCHITECTURE
Le designer est une application indpendant compose de 4 parties distinctes : Le Registry Browser Le proxy Le noyau (core) Linterface utilisateur (UI)

39

Designer proxy UI
DigitalMuseumClient

Resource

ProjectsView Combo OLModel CartEditor

Server

Cart Observer

CartViewTab ProjectView Combo CartViewTree

Servers

Carts Observable SmilEditor

S W I N G

SmilView Project Projects Observable List

ServerView

SMIL core

Figure 25 : architecture du designer (proxy, core et UI) On peut tout de suite remarqu lapplication du design pattern Observer permettant ainsi le dcouplage entre le noyau de lapplication (core) et son interface (UI). En effet, on peut ainsi modifier compltement linterface graphique sans tre oblig de toucher au noyau de lapplication. Enfin, cette construction permet de rafrachir automatiquement laffichage en cas de modification.

5.6.2.1 LE REGISTRY BROWSER

Cette application, fournie par le JWSDP, a t intgre au Designer et lgrement modifie afin de permettre la sauvegarde des WebServices dcouverts. Cette interface autonome nous sert instancier les objets de type server , afin de crer des requtes multi-serveur (une requte envoye plusieurs WebServices en mme temps).

40

Figure 26 : interface du registry browser

5.6.2.2 LE CLIENT JAX-RPC (PROXY)

Le DigitalMuseumClient est un objet proxy qui est instanci lors de la recherche. Sa structure est assez simple. Cest un objet java qui implmente linterface DigitalMuseumIF (Figure 27)
<<Interface>> DigitalMuseumIF
(from museum)

getResource()

DigitalMuseumClient query(String query) : Collection

Figure 27 Linstanciation de cet objet se fait en plusieurs tapes et chaque fois que lon souhaite accder un web service. Tout dabord, il faut accder au descripteur de service (WSDL) pour pouvoir crer un objet proxy. Ensuite il faut obtenir un port sur le webservice et enfin la communication RPCSOAP peut alors commencer (

41

DigitalMuseum (Web Service n1) DigitalMuseumImpl

DigitalMuseum (Web Service n2) DigitalMuseumImpl

Remote

DigitalMuseumIF

Remote

DigitalMuseumIF

WSDL

WSDL

3 1
A SO P

4
SO AP

3 1

4 proxy

DigitalMuseumClient 2

1 Retreive 2 Instantiate 3 Get Port 4 RPC

Figure 28 La traduction en code machine JAVA des tapes dcrites prcdemment est illustre par le code suivant : public class DigitalMuseumClient { private String nameSpaceUri = "http://com.test/wsdl/MyDigitalMuseum"; private String serviceName = "MyDigitalMuseum"; private String portName = "DigitalMuseumQueryIFPort"; private URL museumWsdlUrl; private DigitalMuseumIF myProxy; //creation de lobjet public DigitalMuseumClient(URL server) throws Exception { this.museumWsdlUrl = server; ServiceFactory serviceFactory = ServiceFactory.newInstance(); Service museumService=ServiceFactory.createService(museumWsdlUrl, new QName(nameSpaceUri, serviceName)); this.myProxy = (DigitalMuseumIF) museumService.getPort(new QName(nameSpaceUri, portName), DigitalMuseumIF.class); } //mthode dinterrogation public Collection query(String query) throws Exception { return myProxy.getResource(query); } }

42

5.6.2.3 NOYAU
Voici comment sont organiss les diffrents objets formant le noyau (package core). Les objets dont la visualisation se fera laide dune liste limplmentent une ObservableList qui implmente elle mme une interface Observable. Cette architecture sinscrit dans la volont dappliquer le pattern Observer notre structure. Enfin, on remarquera le fait quun projet est serialisable.

Project Projects name fileName 1 1 Carts SMIL content

<<Interface>> Serializable
(from io)

Servers

Cart name

DigitalMuseum Client
(f ro m proxy )

Server name url

query() Resource res_id res_type res_author res_year res_uri res_desc

Obs ervableList vectorObject enumerationObject() : Enumeration size() : Integer addObject(object : Object, position : Integer) addObject(object : Object) deleteObject(object : Object) deleteObject(position : Integer) getObject(position : Integer) moveUp() : Boolean moveDown() : Boolean moveTo(position : Integer) : Boolean

Observable
(from util)

Observable() addObserver() deleteObserver() notifyObservers() notifyObservers() deleteObservers() setChanged() clearChanged() hasChanged() countObservers()

43

5.6.2.4 LINTERFACE (UI)

Elle correspond la deuxime partie de lapplication du pattern Observer. Sa complexit apparente vient du fait notre interface utilise des objets java de type ComboBox, Table, Tree qui nous imposent la cration de modles de donnes spcifiques. Tous ces modles spcifiques drivent dune Liste Observable (OLModel) qui implmente elle mme linterface Observer.

Observable
(from util)

ObservableList
(from core)

vect orObject enumerat ionObject () size() addObject() addObject() deleteObject() deleteObject() getObject() moveUp() moveDown() moveTo()

<<Interface>> Observer
(f ro m ut il)

update()

Observable() addObserver() deleteObserver() notifyObservers() notifyObservers() deleteObservers() setChanged() clearChanged() hasChanged() countObservers()

OLModel notifyListener() setList(ol : ObservableList) getList(argname) : ObservableList

<<Interface>> TableModel
(f ro m t abl e)

<<Int erface>> ListModel

(from swing)

OLListModel getSize() getElementAt() addListDataListener() removeListDataListener()

OLTableModel

ResourceOLTreeModel

getRowCount() getColumnCount() getColumnName() getColumnClass() isCellEditable() getValueAt() setValueAt() addTableModelListener() removeTableModelListener()

OLComboBoxModel

<<Interface>> TreeModel OLComboBoxModel Extendable

(from tree)

ResourceOLTableModel

getRoot () getChild() getChildCount() isLeaf() valueForPat hChanged() getIndexOfChild() addTreeModelList ener() removeTreeModelListener()

<<Interface>> ComboBoxModel
(from swing)

setSelectedItem() getSelectedItem()

44

5.6.3 LE TUTORIAL 5.6.3.1 LANCEMENT DE LAPPLICATION

Excutez DigitalMuseum.jar en tapant la commande java jar DigitalMuseum.jar. La fentre principale de lapplication apparat alors (Figure 29)

Figure 29

5.6.3.2 CONFIGURATION DE LAPPLICATION

Le programme a besoin de connatre les WebServices (serveurs) avec lesquels il va communiquer. Pour cela, allez dans le menu Settings | Add server (Figure 30).

Figure 30 Cette option ouvre une nouvelle fentre et appelle les Registry Browser (Figure 31).

45

Figure 31 Vous avez la possibilit de rechercher les WebServices par catgorie ou par organisation. Sur la Figure 31, on peut voir la recherche par catgorie qui nous a fait dcouvrir un enregistrement. En cliquant dessus, on dcouvre lorganisation LED (Figure 32)

Figure 32 Les services quelle propose (Figure 33).

46

Figure 33 Et enfin, les diffrents serveurs proposant ce service (Figure 34).

Figure 34 Cliquez sur le bouton Add pour ajouter le serveur slectionn dans la liste des serveurs de lapplication. Cette liste est srialise dans le fichier servers.cfg la racine de lapplication.

5.6.3.3 CREATION DUN PROJET

Chargement Pour cela cliquez sur Project | New (Figure 35) (ou bien Open et slectionnez un projet dj cre).

Figure 35 Nommez le nouveau projet (Figure 36).

Figure 36

47

Configuration Cette tape consiste associer des serveurs au projet afin de consulter simultanment plusieurs WebServices lors dune mme requte. Pour cela allez dans Project | Edit server list (Figure 37).

Figure 37 Slectionnez le ou les serveurs de lapplication qui seront utiliss par le projet dans la combo box global server et cliquez sur Add (Figure 38). Les serveurs ainsi slectionns sont automatiquement visibles dans la combo box project servers et peuvent tre supprims (ou rendus global si le projet a t charg depuis un fichier)

Figure 38 Cration dun cart Le cart est une liste de ressources multimdia obtenu aprs une interrogation sur un ou plusieurs WebService. Pour crer un nouveau cart associ au projet, selectionnez Cart | New dans le menu (Figure 39).

Figure 39 Une fentre apparat. Choisissez le projet en cours dans la combo box Please select a project puis entrez le nom de cart souhait et enfin crivez la requte de slection dans le champ please enter your query (pas de requte entrane une slection de toutes les ressources disponibles).(Figure 40)

48

Figure 40 Le cart NewCart est maintenant cr et associ au projet NewProject. Cration dune prsentation multimdia Ouvrir la fentre correspondant au projet NewProject et slectionnez, gauche, le cart contenant les ressources utilises pour la prsentation multimdia (Figure 41).

Figure 41 La fentre de droite est un diteur de texte. En double cliquant sur une ressource gauche, le code (SMIL) est automatiquement inscrit au niveau du curseur de lditeur. Une fois la prsentation SMIL termine on peut lenregistrer dans lapplication ou encore exporter son travail directement dans un fichier SMIL (Figure 42).

49

Figure 42 Gestion des carts Indpendamment dun projet lapplication propose une gestion des carts. La gestion des carts consiste nettoyer et fusionner les carts enregistrs dans diffrents projets. Slectionnez Cart | Edit dans le menu. Choisissez gauche le projet et un cart (ici Cart1) et droite un autre cart (Cart2) (Figure 43).

Figure 43 Les flches du bas permettent dordonner les ressources et passer les ressources dun cart lautre.

50

5.7 LARCHITECTURE FINALE

Museum admin connection

BeanQuery

HTTP

Admin

J S P

ConJDBC

Data

BeanResource

Connection

BeanUser

ConXML

XML

DigitalMuseum (Web Service) DigitalMuseumImpl

Remote

DigitalMuseumIF

WSDL Exhibition Designer proxy UI

DigitalMuseumClient

SO

AP

Resource

ProjectsView Combo OLModel CartEditor

Server

Cart Observer

CartViewTab ProjectView Combo CartViewTree

Servers

Carts Observable SmilEditor

S W I N G

Designer

SmilView Project Projects Observable List

ServerView

SMIL core

X H T M L

HTTP

SMIL

HTTP RTSP Visitors

Figure 44 : architecture finale du Digital Museum

51

6 PERSPECTIVES
Le prototype ralis est dj all trs loin dans loptimisation et limplmentation java. Cependant il convient de lister les amliorations encore possibles.

6.1 LES RESSOURCES MULTIMEDIA

Il conviendra de dfinir un schma cohrent et normalis afin de dfinir les ressources multimdia. En effet, nous avons du improviser une structure de donnes car Taiwan ne nous a pas fourni de spcifications prcises.

6.2 UDDI
DigitalMuseum utilise UDDI afin de rechercher les webservices disponibles mais ne teste pas la compatibilit avec notre systme. En effet, on peut rfrencer et tenter dutiliser un websevice totalement tranger au DigitalMuseum. De plus, cest lutilisateur qui est charg de rechercher manuellement les webservices. Il nous semble donc intressant de remplacer UDDI pour un systme hirarchique de SOAPCASTER charg de trouver automatiquement les webservices de type DigitalMuseum en bon tat de fonctionnement.

6.3 BASE DE DONNEE XML

Il serait utile de tester notre application avec des versions finalises de gestionnaire de base de donne tels que Exist ou Xindice. De plus, il faudra vrifier que notre grammaire na pas dquivalence et pourra tre remplac par un langage dinterrogation de type XQL (W3C).

6.4 EDITEUR DE PRESENTATION MULTIMEDIA

Une quipe de recherche de lINRIA de Grenoble a dj travaill sur un diteur de prsentation multimdia. Il serait peut tre bon de combiner nos effort afin de proposer un produit complet de la mise disposition des ressources jusqu ldition la publication des prsentations multimdia. Enfin, il serait bon dintroduire la ncessit de coopration dans llaboration des prsentations multimdia (outils coopratifs).

6.5 FORMAT MULTIMEDIA

Pour le moment la maquette prsente exporte les expositions virtuelles en SMIL. On peut envisager, dans un avenir proche, de proposer de nouveaux formats dexport comme MPEG 4 ou MPEG 7.

52

6.6 PROGRAMMATION
De nombreux modules sont crer ou amliorer : La rubrique Outils de linterface dadministration web devra tre cre (donnes orphelines, utilisateurs, nettoyage de la base de donne, gestion des connexion BDD) Le code correspondant au lien mot de passe perdu de linterface dadministration web devra tre cre La rubrique Ajouter et modifier devront offrir la possibilit de charger la ressource sur le serveur. Il faut supprimer les fichiers ConnectionData.java afin de modifier les paramtres de connexion sans tre oblig de recompiler.

53

7 CONCLUSION
Le but fix par le stage a t atteint et le rsultat obtenu dpasse largement nos esprances. En effet, cest bien plus quune maquette qui a t ralise, cest une application presque finalise et accompagne de toute la documentation technique et conceptuelle ncessaire sa bonne volution. Toutes les difficults techniques ne sont pas encore vaincues (Bases de donnes XML) mais tout porte croire quelles le seront bientt et sont en grande partie dues la jeunesse des produits. Lors de ce stage, jai dispos dun large espace de libert. Cest la bienveillance de Samuel CRUZ-LARA que je dois cet espace. Je suis fier des choix que jai pu prendre lors de ce stage car ils ont conduit le projet un haut niveau de qualit et de technicit. Une prolongation de stage a t conclue lissue de mes travaux afin de finaliser la documentation et prparer la publication et la prsentation des travaux sur les Web Services lquipe Langue et Dialogue et lIEEE.

54