Vous êtes sur la page 1sur 184

Numro 125

Version du 25 novembre 2009

THESE
Prpare LUniversit de Technologie de Belfort-Montbliard

Pour obtenir le grade de

Docteur de lUniversit de Technologie de Belfort-Montbliard et lUniversit de Franche-Comt

Spcialit Informatique

Par

Ana ROXIN

PROTOCOLE DE DECOUVERTE SENSIBLE AU CONTEXTE POUR LES SERVICES WEB SEMANTIQUES


Soutenue publiquement le 30 novembre 2009

Composition du jury: Daniel JOLLY, Professeur, Universit dArtois, Bthune (France) Rapporteurs : Jean-Marie PINON, Professeur, INSA, Lyon (France) Alexandre CAMINADA, Professeur, UTBM, Belfort (France) Jacques SAVOY, Professeur, UNINE, Neuchtel (Suisse) Maxime WACK, Matre de confrences HDR, UTBM, Belfort (France) Jaafar GABER, Matre de confrences, UTBM, Belfort (France)

Examinateurs : Directeur de thse : Co-encadrant :

Page 2

REMERCIEMENTS
Le prsent travail a t men au sein du laboratoire Systmes et Transports (SeT), de lUniversit de Technologie de Belfort-Montbliard (UTBM), sous la direction de Monsieur Maxime WACK, pour la partie scientifique, en collaboration avec la socit PIMENTIC, spcialise dans les systmes embarqus, prside par Monsieur Jean-Claude RAGRIS, pour lindustrialisation des rsultats scientifiques obtenus. Je leur adresse ma profonde gratitude pour mavoir permis dintgrer leurs structures respectives dans le cadre de mon contrat CIFRE. Nous sommes particulirement sensibles lhonneur que nous font Messieurs les Professeurs Jacques SAVOY et Alexandre CAMINADA en acceptant dtre membres du jury. Je remercie chaleureusement Messieurs les Professeurs Jean-Marie PINON et Daniel JOLLY pour avoir accept la charge de travail quimplique la lecture critique du prsent mmoire. Leurs remarques pertinentes et conseils aviss nous ont amen de nouvelles rflexions et perspectives de recherche. Je remercie vivement mon directeur de thse, Monsieur WACK, Matre de Confrences HDR lUTBM, ainsi que mon co-encadrant, Monsieur Jaafar GABER, Matre de Confrences, pour la qualit de leur encadrement. Tous deux mont initi la recherche et mont guid tout au long de llaboration de ce travail. Ils mont encourag mimpliquer dans leurs thmatiques de recherche sur la dcouverte de services Web smantiques. Je remercie galement les enseignants et administratifs de lUTBM, notamment Monsieur Ahmed NAIT-SIDI-MOH pour sa relecture attentive et ses conseils aviss. Je remercie galement mes collgues de travail de PIMENTIC pour leur chaleureux accueil. Ils mont permis deffectuer mes recherches dans une ambiance conviviale. Monsieur Ioan SZILAGY, doctorant lUniversit de Franche-Comt, ma en outre t dun immense secours et je len remercie cet gard. Enfin, mes parents et mon fianc mont support tout au long de ces trois annes et ont volontiers relu mon mmoire avec lil du nophyte.

Ana ROXIN

Page 3

RESUME
Le Web daujourdhui reprsente un espace o les utilisateurs recherchent, dcouvrent et partagent des informations. Dans ce cadre, les processus de dcouverte de services Web jouent un rle fondamental. Un tel processus permet de faire le lien entre des informations publies par des fournisseurs de services et des requtes cres par les internautes. Gnralement, un tel processus repose sur une recherche textuelle ou base de mots-cls . Or, ce type de recherche ne parvient pas toujours identifier les services les plus pertinents. Notre ide est de concevoir un systme plus intelligent , permettant dutiliser, lors du processus de dcouverte, une base de connaissances associes aux informations, comme cest le cas pour le Web smantique. Cette thse prsente un prototype pour la dcouverte de services Web smantiques, utilisant des caractristiques non-fonctionnelles (descriptives) des services. Notre approche emploie le langage OWL-S (Web Ontology Language for Services) pour dfinir un modle de description des paramtres non-fonctionnels des services. Ce modle a pour but de faciliter la dcouverte de services Web smantiques. Ce modle reprsente le centre de notre contribution, tant utilis pour la conception des interfaces et des requtes. Deux interfaces sont dveloppes, lune sadressant aux fournisseurs de services, alors que la deuxime interface est conue pour lutilisateur final. Lalgorithme de recherche prsent dans cette thse a pour but damliorer la prcision et la compltude du processus de dcouverte de services.

MOTS-CLES
Web smantique, RDF, OWL, services Web smantiques, dcouverte de services, dcouverte de services Web smantiques.

Page 4

ABSTRACT
The Web of today represents a broad space where users research, discover and share information. In this contexte, the process of Web service discovery plays a significant role. Indeed, such process allows linking the information published by service providers and the requests of users, looking for information. Generally, such process involves text or keyword-based techniques. Still, this kind of discovery fails in retrieving only relevant information. Our approach is to design a more intelligent system that allows using a knowledge base during the service discovery process, as it is done in the Semantic Web vision. This thesis presents a framework for semantic Web service discovery using non-functional service characteristics. The framework relies on the Web Ontology Language for Services (OWL-S) to design a template for describing non-functional service parameters in a way that facilitates service discovery. Our model is designed to facilitate the discovery of semantic Web services. This service description model is used as a core for designing the interfaces and the querries. Two interfaces are developped : one for the service providers, and one for the final users. The search algorithm presented in this thesis is designed to maximize precision and completeness of service discovery.

KEYWORDS
Semantic Web, RDF, OWL, semantic Web service, service discovery, semantic Web service discovery.

Page 5

TABLE DES MATIERES


Chapitre 1. Introduction _________________________________________________ 12
1.1 Problmatique _____________________________________________________________ 15 1.2 Objectifs __________________________________________________________________ 18
1.2.1 Objectifs concernant la description de services __________________________________________ 19 1.2.2 Objectifs concernant le moteur de dcouverte __________________________________________ 19

1.3 Contributions ______________________________________________________________ 19


1.3.1 Contribution concernant la description de services_______________________________________ 20 1.3.2 Contribution concernant la dcouverte de services ______________________________________ 20

1.4 Plan du rapport _____________________________________________________________ 21

Chapitre 2.

Etat de l'art des technologies impliques __________________________ 23

2.1 Les services Web ____________________________________________________________ 24


2.1.1 Dfinition ________________________________________________________________________ 24 2.1.2 Composants de base d'un service Web ________________________________________________ 24 2.1.3 Conclusion _______________________________________________________________________ 33

2.2 Les principes du Web smantique ______________________________________________ 33


2.2.1 Vision du Web smantique __________________________________________________________ 33 2.2.2 Les mtadonnes __________________________________________________________________ 34 2.2.3 Les ontologies - vocabulaires pour les mtadonnes _____________________________________ 35 2.2.4 Conclusion _______________________________________________________________________ 46

2.3 Les services Web smantiques _________________________________________________ 46


2.3.1 Smantiques des services Web _______________________________________________________ 47 2.3.2 Description des services Web smantiques _____________________________________________ 47 2.3.3 L'approche OWL-S _________________________________________________________________ 49

2.4 Conclusion _________________________________________________________________ 52

Chapitre 3.

Approches pour la dcouverte de services sensibles au contexte _______ 53

3.1 Services sensibles au contexte _________________________________________________ 54


3.1.1 Dfinitions du contexte _____________________________________________________________ 54 3.1.2 Modlisation du contexte ___________________________________________________________ 55 3.1.3 Services sensibles au contexte _______________________________________________________ 57

3.2 Protocoles de dcouverte de services sensibles au contexte _________________________ 59


3.2.1 Context Aware Service Discovery (CASD) _______________________________________________ 59 3.2.2 A Context- And QoS-Aware Service Discovery (ConQo) ____________________________________ 60 3.2.3 Context-Aware, Ontology-based, Semantic Service Discovery (COSS) ________________________ 62

3.3 Problmes non adresss par les approches actuelles _______________________________ 64

Page 6

Chapitre 4.

Approche contextuelle pour la dcouverte de services Web smantiques 66

4.1 Rle de la description de service _______________________________________________ 67


4.1.1 Composants fonctionnels et non-fonctionnels __________________________________________ 67 4.1.2 Fonctionnalits couvertes par les descriptions standard de services Web _____________________ 67

4.2 Rle de la description de service dans le processus de dcouverte ____________________ 69


4.2.1 Description smantique et dcouverte de service ________________________________________ 70 4.2.2 Limites de la description smantique avec OWL-S________________________________________ 71

4.3 Modle de description de services sensibles au contexte avec OWL-S tendu ___________ 72
4.3.1 Cration d'une hirarchie de services _________________________________________________ 73 4.3.2 Intgration dans le modle OWL-S ____________________________________________________ 80

4.4 Protocole de dcouverte de service sensibles au contexte avec OWL-S tendu __________ 86

Chapitre 5.

Prsentation du prototype ______________________________________ 90

5.1 L'architecture ______________________________________________________________ 91 5.2 Les interfaces ______________________________________________________________ 92


5.2.1 Interface pour la publication de service ________________________________________________ 92 5.2.2 Interface pour la requte de service___________________________________________________ 95 5.2.3 Avantages de cette approche ________________________________________________________ 96

5.3 Le moteur dcouverte _______________________________________________________ 97

Chapitre 6.

Dveloppement et implmentation du prototype ___________________ 98

6.1 La plate-forme Android _____________________________________________________ 99


6.1.1 Prsentation gnrale ______________________________________________________________ 99 6.1.2 Anatomie d'une application Android ________________________________________________ 100

6.2 Dveloppement du moteur dcouverte ________________________________________ 101


6.2.1 Les classes Java __________________________________________________________________ 103 6.2.2 L'implmentation ________________________________________________________________ 106

6.3 Dveloppement des interfaces _______________________________________________ 110


6.3.1 Interface Utilisateur final _______________________________________________________ 110 6.3.2 Interface Fournisseur de services _________________________________________________ 120

Chapitre 7.

Evaluation du prototype _______________________________________ 126

7.1 Mesures de performance ____________________________________________________ 127


7.1.1 Mesures de rapidit ______________________________________________________________ 127 7.1.2 Mesures de pertinence ____________________________________________________________ 130

7.2 Mesures relatives lutilisateur final___________________________________________ 133 7.3 Conclusion ________________________________________________________________ 134

Page 7

Chapitre 8.

Conclusion gnrale et perspectives _____________________________ 136

8.1 Perspectives ______________________________________________________________ 137


8.1.1 Perspectives applicatives __________________________________________________________ 137 8.1.2 Perspectives scientifiques __________________________________________________________ 138

Annexes

___________________________________________________________ 139

Bibliographie

___________________________________________________________ 171

Production scientifique personnelle __________________________________________ 181


Publications dans des journaux __________________________________________________ 181 Publications dans des confrences internationales avec comit de lecture _______________ 182 Publications dans des livres _____________________________________________________ 184

Page 8

TABLE DES FIGURES


Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8. Figure 9. Figure 10. Figure 11. Figure 12. Figure 13. Figure 14. Figure 15. Figure 16. Figure 17. Figure 18. Figure 19. Figure 20. Figure 21. Figure 22. Figure 23. Figure 24. Figure 25. Figure 26. Figure 27. Figure 28. Figure 29. Figure 30. Figure 31. Figure 32. Figure 33. Dcouverte de services intgrant des informations contextuelles. ___________________ 17 Modle architectural des services Web. ________________________________________ 24 Principe de fonctionnement du protocole SOAP. _________________________________ 27 Structure dun message SOAP. ________________________________________________ 27 Structure dun document WSDL. ______________________________________________ 28 Liens entre les lments WSDL et une classe Java. ________________________________ 29 Entits de base du registre UDDI. ______________________________________________ 30 Fonctionnement du modle UDDI. _____________________________________________ 32 Exemple de requte service UDDI. _____________________________________________ 32 Architecture du Web smantique (adapt depuis (ALESSO 2006)). __________________ 37 Graphe RDF dcrivant trois noncs RDF. _______________________________________ 39 Notation XML pour la description des noncs RDF. ______________________________ 39 Vocabulaire RDF pour la rification. ___________________________________________ 40 Relations de classe entre les constructeurs OWL et RDF(S). ________________________ 44 Relations entre les diffrents langages de description dontologies _________________ 45 Concepts de base de lontologie OWL-S. ________________________________________ 49 Classes de lontologie ServiceProfile (MARTIN 2004). ________________________ 50 Types dinformations contextuelles. ___________________________________________ 55 Modlisation UML du contexte dans le cadre du systme Hydrogen (HOFER 2003). ____ 56 Services traditionnels et services sensibles au contexte. ___________________________ 58 Comparaison des proprits service aux proprits requte. _______________________ 63 Ontologies utilises par lapproche COSS (BROENS 2004).__________________________ 63 Niveaux dabstraction dune description de service. ______________________________ 67 Exemples de requtes qualitatives. ____________________________________________ 69 Illustration des proprits de la classe ServiceCategory. ______________________ 74 Classe NAICS du modle OWL-S. ______________________________________________ 75 Classe UNSPSC du modle OWL-S. _____________________________________________ 75 Notre classification hirarchique de profils service. _______________________________ 80 Interface de lditeur Protg pour la cration de hirarchies de classes. _____________ 81 Dfinition de la proprit aAdresse. _________________________________________ 82 Dfinition de la proprit aTelephone. _______________________________________ 82 Notre extension de la classe Profile. ________________________________________ 82 Contenu de la classe ServiceContext. ______________________________________ 83

Page 9

Figure 34. Figure 35. Figure 36. Figure 37. Figure 38. Figure 39. Figure 40. Figure 41. Figure 42. Figure 43. Figure 44. Figure 45. Figure 46. Figure 47. Figure 48. Figure 49. Figure 50. Figure 51. Figure 52. Figure 53. Figure 54. Figure 55. Figure 56. Figure 57. Figure 58. Figure 59. Figure 60. Figure 61.

Restriction de la proprit aContexte. _______________________________________ 84 Attributs contextuels de la classe Service_Restaurant_Context. _____________ 86 Notre protocole de dcouverte de services sensibles au contexte. __________________ 87 Algorithme pour le calcul du niveau de pertinence dun attribut service. _____________ 88 Architecture de notre prototype. ______________________________________________ 92 Etapes de la publication dune description de service. _____________________________ 93 Exemple dun formulaire pour la publication de services. __________________________ 94 Etapes du processus de publication de service. __________________________________ 94 Etapes du processus de requte de service. _____________________________________ 96 Fonctionnement du Moteur Dcouverte . ____________________________________ 97 Points forts de la plate-forme Android ________________________________________ 99 Architecture Android. ______________________________________________________ 99 Elments dune application Android. ________________________________________ 101 Architecture du Moteur Dcouverte ._______________________________________ 102 Diagramme des classes du Moteur Dcouverte .______________________________ 103 Cycle de vie dune Activit. __________________________________________________ 112 Illustration des relations entre les diffrents composants dune Vue. _______________ 113 Illustration des diffrents crans composant linterface Utilisateur final . _________ 115 Liste des catgories de services dfinies dans notre modle. ______________________ 116 Navigation parmi les catgories de services ____________________________________ 116 Rcupration de la valeur du slider. ___________________________________________ 118 Affichage dune adresse grce au module GoogleMaps. _________________________ 119 Composition dun numro de tlphone. ______________________________________ 120 Traduction WSDL en OWL-S (PAOLUCCI 2003). __________________________________ 122 Graphe RDF illustrant les informations contextuelles dun service de restauration. ____ 123 Affichage des catgories de services dfinies dans le modle ontologique.___________ 124 Formulaire permettant de publier un service. __________________________________ 125 Mesures de lutilit et de lusabilit dune application (B. SENACH 1990). ____________ 134

Page 10

LISTE DES TABLEAUX


Tableau 1. Tableau 2. Tableau 3. Tableau 4. Tableau 5. Tableau 6. Tableau 7. Tableau 8. Tableau 9. Tableau 10. Tableau 11. Tableau 12. Tableau 13. Tableau 14. Tableau 15. Tableau 16. Tableau 17. Tableau 18. Tableau 19. Tableau 20. Tableau 21. Tableau 22. Tableau 23. Tableau 24. Tableau 25. Tableau 26. Tableau 27. Tableau 28. Tableau 29. Elments de la dcouverte de services et fonctionnalits associes __________________ 18 Exemples dnoncs RDF. ____________________________________________________ 38 Constructeurs de classe du langage OWL. _______________________________________ 42 Vocabulaire OWL pour la dfinition de proprits. _______________________________ 43 Proprits OWL permettant de statuer sur l galit entre concepts. _____________ 44 Extensions du Web smantique par rapport au Web actuel. ________________________ 46 Caractristiques de lapproche CASD. __________________________________________ 60 Caractristiques de lapproche ConQo. _________________________________________ 62 Caractristiques de lapproche COSS. __________________________________________ 64 Classification des urgences de police. __________________________________________ 78 Classification des urgences hpital. ____________________________________________ 79 Classification des urgences pompiers. __________________________________________ 79 Requte utilisateur. _________________________________________________________ 87 Valeurs des attributs contextuels de deux services. _______________________________ 88 Algorithme pour la comparaison et lordonnancement des services. _________________ 89 Liste des mthodes de la classe OwlTools. ___________________________________ 104 Liste des mthodes de la classe OwlInterfacer. _____________________________ 105 Liste des mthodes de la classe OwlLoader. __________________________________ 105 Liste des mthodes de la classe SimpleEngine. _______________________________ 106 Premier test Temps dexcution dune requte utilisateur. ______________________ 128 Premier test Rpartition (en %) des dures correspondant chacune des tapes. ___ 128 Deuxime test Temps dexcution dune requte utilisateur. ____________________ 129 Comparaison entre les deux sries de tests. ____________________________________ 129 Valeurs des attributs contextuels des services crs. _____________________________ 131 Requte utilisateur TEST1. __________________________________________________ 132 Requte utilisateur TEST2. __________________________________________________ 132 Scores des services pour chacune des deux requtes test. ________________________ 132 Liste ordonne des services retourne pour chaque requte test. __________________ 132 Calcul de la prcision moyenne. ______________________________________________ 133

Page 11

CHAPITRE 1. INTRODUCTION
Lorsque nous parcourons le Web, lorsque nous remplissons un formulaire ou lorsque nous effectuons un achat, nous prenons partie dans une opration distribue, dont nous connaissons que trs peu les composants. Les services Web sont intressants en cela qu'ils fournissent une approche pour construire et dployer de telles oprations distribues, tout en amliorant la productivit des programmeurs, mais aussi celle des utilisateurs. La plupart des chercheurs et des praticiens sont d'accord pour dire que le Web d'aujourd'hui, mme s'il est une russite, a de nombreuses limitations. L'information n'est pas organise sur le Web; elle peut tre imprcise, incomplte ou mme, pire, incomprhensible. Les techniques actuelles pour rechercher des informations manquent dcouvrir certaines informations pertinentes. Le Web est sans autorit centrale et implique des composants htrognes et autonomes. Aujourd'hui ces composants sont principalement des pages Web, mais, avec le temps, ce seront des programmes en gnral. En d'autres mots, le Web actuel fournit la fois du contenu et des services. Le Web est dynamique tant donn les changements arbitraires que peuvent subir ses composants. Toutefois, cette dynamique est limite, puisque les composants ne peuvent ngocier l'ensemble des aspects dfinissant leurs interactions. La principale vision de l'avenir du Web est la vision du Web Ubiquitaire. En effet, Mark Weiser a dfini la vision dite de l'informatique ubiquitaire (ou ubiquitous computing) : l're de l'informatique ubiquitaire est caractrise par lenfouissement des diffrentes technologies d'accs l'information1, dans notre environnement de tous les jours (WEISER 1991). L'une des promesses de l'informatique ubiquitaire est de permettre aux utilisateurs d'tre en permanence connects avec d'autres utilisateurs, mais aussi avec des applications et des services Internet (BAKHOUYA 2008). Dans la vision de Weiser, le Web actuel reprsente une transition des connexions du type un--un (entre utilisateurs et ordinateurs) vers des connexions du type un--plusieurs, qui permettront une multitude d'ordinateurs de rpondre aux besoins d'un utilisateur, tout moment et quelque soit son environnement. Le Web ubiquitaire est une vision moyen terme, centre sur l'utilisateur, et transparente pour celui-ci. Dans la vision du Web smantique, la page Web contient des annotations concernant les aspects de prsentation, mais aussi des annotations fournissant une reprsentation, part, du sens du contenu de la page Web. Ceci permet de passer d'une approche syntaxique (ne capturant que la structure de l'information) une approche smantique (capturant le sens de l'information). L'volution des paradigmes de communication est une autre ide gagnant en popularit (BAKHOUYA 2008). Actuellement, le Web est utilis travers des interactions du type client-serveur: l'information est stocke du ct serveur et l'intelligence est stocke du ct client. Cette asymtrie entre les deux
1

The most profound technologies are those that disappear (WEISER 1991)
Page 12

parties dnote le fait que l'information a tendance tre stocke dans de grands serveurs, qui deviennent vitaux pour le fonctionnement du systme entier. Si ces serveurs sont amens subir une panne, l'ensemble du systme est affect. Si les serveurs sont compromis, la scurit du systme lest aussi. La vision du Web pair--pair (de langlais peer-to-peer - P2P) considre les diffrentes entits (ou composants) du Web en tant que pairs, chaque composant tant l'gal d'un autre. Chaque entit comprend la fois des aspects serveur et client. Dans cette vision, le Web n'est plus un ensemble de pages statiques auxquelles des programmes accdent. Le Web pair--pair est constitu de programmes actifs, qui communiquent entre eux. Ces programmes peuvent mener des ngociations entre eux ou encore se transmettre des suggestions entre eux. Toutefois, les approches P2P actuelles n'intgrent pas l'approche smantique (BAKHOUYA 2008) : les applications P2P doivent spcifier leurs interactions travers des codages en dur . Les applications P2P ne peuvent pas mener des ngociations flexibles, la vole . C'est pour cette raison quactuellement, les approches P2P se limitent des applications simples, dans lesquelles les utilisateurs fournissent les smantiques, telles des applications de partage de fichiers. Lorsque les visions prsentes ci-dessus sont rassembles, nous obtenons la vision plus globale dun Web permettant de supporter des processus dans un contexte. Cette vision est celle dun Web actif, pouvant tre utilis, la fois, par les humains et les ordinateurs. Les principales caractristiques de cette vision du Web sont (ROXIN et al. 2008a): L'automatisation pour permettre le passage de l'humain l'ordinateur. Les annotations riches pour capturer les smantiques (ou le sens formel) des documents et des structures. Les nouveaux paradigmes d'interaction pour passer du modle client/serveur vers un modle coopratif. La prise en compte du contexte, travers la smantique, pour fournir une comprhension mutuelle entre les entits du Web. Cette vision du Web rejoint la vision plus gnrale de Weiser. Dans les deux visions, il s'agit de passer de systmes et d'interfaces fixes et priori connus, des environnements ncessairement personnels chaque utilisateur (VALLEE 2006). Or ces nouveaux environnements doivent faire preuve d'une grande flexibilit et d'une grande rsistance aux pannes. Pour ce faire, il faut pouvoir fournir aux utilisateurs des services prenant en compte leur contexte d'utilisation. Ces services doivent intgrer des informations dfinissant le contexte de l'utilisateur (sa position, ses prfrences, les caractristiques de son terminal mobile, etc.) afin de s'y adapter, et ce quelque soit le type de rseau ou le type de terminal mobile utilis. Afin d'illustrer cette ide, nous pouvons prendre un exemple de notre vie quotidienne. En effet, lors de conversations, il nous arrive souvent d'omettre certaines informations pouvant tre dduites des circonstances dans lesquelles la conversation se droule. Par exemple, nous allons rarement dire Il pleut. Il faut prendre un parapluie. , mais Je vais prendre un parapluie . C'est la conscience que l'on a de notre environnement (ou contexte), qui permet un change efficace des ides. Nous retrouvons ici l'ide de base de la vision du Web futur: la prise en compte du contexte permet une comprhension mutuelle entre des entits.

Page 13

De la mme manire, les systmes informatiques doivent tre rceptifs aux dsirs de l'utilisateur, notamment en dduisant les intentions de l'utilisateur partir d'informations auxiliaires mais pertinentes par rapport au but envisag. Ces informations sont appeles informations contextuelles et les applications ragissant en fonction de ce type d'information sont appeles applications sensibles au contexte. Il s'agit d'applications rseau fournissant aux utilisateurs des services sensibles au contexte. Les services sensibles au contexte sont par dfinition de nature htrogne. Chaque service a des proprits, des capacits, des interfaces et des schmas d'invocation qui lui sont propres. La fourniture de tels services pose de nombreuses questions: comment standardiser la description de ces services, comment capturer leur smantique, comment prendre en compte les besoins utilisateur et comment les traiter? Rpondre ces questions est une tche d'autant plus difficile que les services sensibles au contexte possdent des caractristiques bien particulires (LASSILA 2005) : Mobilit - Il s'agit d'avoir une capacit de calcul continue lors des dplacements d'une position l'autre. Les besoins associs sont ceux de l'informatique mobile sur des terminaux portables avec des logiciels embarqus. Sensibilit au positionnement - Il s'agit de pouvoir dtecter et identifier des positions de terminaux et/ou personnes. Les besoins associs sont ceux du positionnement l'intrieur et l'extrieur (ROXIN et al. 2007). Interoprabilit - Il s'agit de permettre des oprations interoprables entre diffrents standards d'changes de ressources, de composition et d'intgration de services. Les besoins associs sont ceux des standards de contenu, services et protocoles de communication. Sans coutures - Il s'agit de proposer des sessions de service continues, avec n'importe quel type de connexion et sur n'importe quel type de terminal mobile. Sensibilit la situation - Il s'agit de pouvoir dtecter et identifier des scnarios de situations. Les besoins impliquent la capacit de connatre l'activit d'une personne et son contexte (quand, o, avec qui, etc.) (ROXIN et al. 2008). Adaptation dans le temps - Il s'agit de permettre un ajustement dynamique du service et/ou de son contenu, en fonction des besoins de l'utilisateur. Les besoins associs impliquent la connaissance du niveau d'accessibilit et des prfrences de l'utilisateur. Pervasivit - Il s'agit de permettre un accs transparent au service et/ou son contenu. Les besoins associs renvoient la capacit de dterminer les besoins de l'utilisateur avant que celui-ci ne les ait exprims. Ces caractristiques posent des dfis considrables et soulvent de nombreuses questions: Comment dcouvrir les ressources ncessaires ? Comment les utiliser ? Comment vrifier qu'elles rpondent telle ou telle contrainte ? Parmi ces questions, celle soulevant le problme de la dcouverte des ressources dans un environnement ouvert et, de par ce fait, htrogne, constitue la problmatique centrale de cette thse. Elle est explique plus en dtail dans la partie suivante.

Page 14

1.1 PROBLEMATIQUE
La vision du Web futur est centre sur l'utilisateur et non-obstrusive. Avec l'augmentation du nombre de capteurs et de terminaux mobiles, cette vision est devenue une vision moyen terme. La technologie existante aujourd'hui permet l'informatique de rentrer dans nos vies, de manire transparente, et donc de mettre en place un Web tel que dcrit plus haut. Or, un des principaux dfis dun tel environnement ubiquitaire est le dveloppement de protocoles de dcouverte de services permettant aux applications et utilisateurs de dcouvrir et interagir avec les services qui rpondent le mieux leurs requtes. La difficult rside non seulement dans la multitude de fournisseurs de services prsents aujourd'hui sur le march, mais aussi dans la dynamique des environnements ubiquitaires (ZHU et al. 2005). En effet, un service donn peut ne pas tre disponible tout moment, et un utilisateur peut tout moment dconnecter son terminal du rseau. De plus, les services disponibles ont chacun des proprits, des capacits, des interfaces et des schmas d'invocation diffrents. Les diffrents standards pour la description des services ne russissent pas capturer lensemble de ces diffrences. Ceci est une des principales raisons pour lesquelles, les protocoles de dcouverte actuels ne suffisent plus pour les services de demain. Dans (ZHU et al. 2005), les auteurs tudient les diffrents protocoles de dcouverte de services proposs, conus et implments. Leur analyse est que mme s'ils partagent tous le mme but de fournir un mcanisme pour la publication et la dcouverte de services, ils sont trs diffrents par rapport des aspects tels l'architecture dploye ou l'environnement dans lequel ils fonctionnent (rseaux LAN, rseaux mobiles, Internet, etc.). Les protocoles de dcouverte actuels ne correspondent pas aux environnements ubiquitaires, et ce pour les raisons suivantes: Premirement, plusieurs descriptions de services peuvent tre syntaxiquement diffrentes, mais smantiquement quivalentes (synonymes) (Synonymes 2009), (ZHU et al. 2005). Or, les protocoles de dcouverte actuels sont bass sur une description syntaxique des services et n'intgrent que des mcanismes de recherche du type motscls . Par consquent, en cherchant un service Restaurant , l'utilisateur ne pourra pas trouver un service Fast food . Les requtes ainsi construites fournissent des rsultats peu prcis et ne permettent de dcouvrir qu'un faible nombre de rsultats pertinents parmi l'ensemble des rsultats correspondants. Deuximement, plusieurs descriptions de services peuvent tre quivalentes du point de vue de la syntaxe, mais diffrentes du point de vue de la smantique. En effet, deux mots peuvent avoir la mme forme graphique (s'crivent de la mme manire) et des sens diffrents; dans ce cas, ils sont dits homographes (Homographe 2009). Un protocole bas sur une recherche de type mots-cls ne prend pas en compte ce type de situation et de ce fait peut retourner des rsultats non-pertinents par rapport une requte utilisateur. Par exemple, en cherchant un service Bois (nom propre), le protocole de dcouverte peut identifier comme pertinents des services incluant le mot bois (verbe boire conjugu limpratif). Troisimement, les protocoles de dcouverte actuels ne sont pas sensibles au contexte, c'est--dire qu'ils n'intgrent pas des informations contextuelles dans le processus de dcouverte de services. C'est pour cette raison qu'ils ne permettent pas de dcouvrir les services les plus pertinents et les plus appropris (CUDDY 2005), (ZHU et al. 2005). Or, ce problme est crucial pour les environnements ubiquitaires. Si l'on considre un utilisateur

Page 15

recherchant un restaurant, le protocole de dcouverte devrait prendre en compte la position et les prfrences de l'utilisateur, afin d'identifier les services les plus pertinents. Il s'agit en l'occurrence, de permettre la dcouverte d'un restaurant situ proximit de l'utilisateur, proposant un style de cuisine apprci de l'utilisateur. Si des informations contextuelles sont ignores lors du processus de dcouverte, la tche d'identifier les services les plus pertinents revient l'utilisateur. Par rapport l'exemple prcdent, si l'utilisateur reoit une liste de restaurants situs plus ou moins loin et proposant divers styles de cuisine, il va devoir luimme trier la liste en fonction de ses critres, afin de choisir le restaurant qui lui convient le mieux. La rponse ces problmes se trouve dans la description smantique des services. Afin d'illustrer les avantages d'une telle approche, prenons l'exemple suivant: un utilisateur souhaite trouver un restaurant proximit de sa position actuelle. Il recherche un restaurant proposant des spcialits mexicaines. Il souhaiterait y rserver une table pour six personnes. Aussi, il aimerait savoir si le restaurant dispose d'un parking, et, si oui, combien de places sont disponibles sur ce parking. L'utilisateur a la possibilit de dfinir des pondrations pour chacune des contraintes dfinies cidessus. En utilisant un protocole de dcouverte de services bas sur une recherche par mots-cls, l'utilisateur reoit une liste de restaurants, avec pour chaque restaurant une description contenant des informations telles son adresse, son style de cuisine ou encore l'existence d'un parking propre au restaurant. C'est l'utilisateur de parcourir l'ensemble des descriptions de la liste, afin d'identifier le restaurant qui correspond le mieux sa requte. De plus, l'utilisation d'un tel protocole de dcouverte ne garantit pas la dcouverte de tous les services pertinents. Si, un service ne contient pas le mot restaurant dans sa description, il ne sera pas inclus dans la liste finale. Or, il se peut trs bien qu'au lieu de restaurant , la description du service contienne des mots tels brasserie ou taverne ou fast-food . Si par contre, le protocole de dcouverte utilise des informations contextuelles (de l'utilisateur et du service), il peut, par exemple, dterminer la position de l'utilisateur, ainsi que le fait qu'il prfre les spcialits mexicaines (voir Figure 1). Ce type d'information peut tre obtenu partir du profil utilisateur. Les informations relatives au restaurant (style de cuisine, position, parking) seront obtenues partir du profil de service. Lors de la cration de la liste de services rpondant la requte de l'utilisateur, les services seront tris en fonction des critres utilisateur. Cela revient dire que tous les services dans la liste seront des restaurants (mme si le mot restaurant n'apparat pas dans la description du service) situs proximit, proposant des spcialits mexicaines et ayant six places disponibles. Pour les restaurants disposant d'un parking, le nombre de places disponibles sera aussi indiqu. Si l'utilisateur a dfini comme principale contrainte le nombre de places disponibles dans le restaurant, les premiers lments de la liste seront des restaurants remplissant ce critre, mme s'ils ne sont pas situs proximit de l'utilisateur. Il est ds lors vident que le premier service de cette liste a de fortes chances d'tre LE service recherch par l'utilisateur. Ce dernier passera donc moins de temps rechercher le service qui lui convient le mieux, puisque des informations dcrivant son contexte et celui du service ont t prises en compte, analyses et compares.

Page 16

Figure 1.Dcouverte de services intgrant des informations contextuelles.

Ce scnario a permis d'illustrer les lacunes d'une dcouverte de services base sur une recherche par mots-cls. Il nous a aussi permis d'identifier les avantages de la prise en compte d'informations contextuelles du service et de l'utilisateur. Dans un environnement mobile, o tout est en constant changement, la prise en compte du contexte d'un service permet la dcouverte de services plus pertinents et plus proches des besoins de l'utilisateur. La gestion des informations contextuelles dfinissant un service apparat alors comme essentielle, dans le cas de l'informatique pervasive. Un protocole de dcouverte de services, intgrant le contexte de ces services, repose sur les lments suivants: Une description de service bien dfinie permet aux utilisateurs de rechercher des services selon des caractristiques qualitatives (ou non-fonctionnelles), telles la position, le prix ou le style de cuisine, comme illustr par l'exemple ci-dessus. Un vocabulaire (ou des smantiques), dcrivant les caractristiques des services, permettent de rduire le nombre de rsultats non-pertinents et donc d'identifier un maximum de rsultats rpondant au besoin de l'utilisateur. Une architecture unifie du moteur de recherche elle doit permettre une recherche simultane de services fournis par diffrents fournisseurs de services, et ce sans avoir connaissance des moyens d'accs ces fournisseurs de services. Le Tableau 1 reprend les lments cls d'un tel moteur de dcouverte, et indique les fonctionnalits supportes actuellement par les standards existants, ainsi que celles qui restent implmenter.

Page 17

lment

Fonctionnalits supportes Description fonctionnelle bien dfinie travers le langage WSDL.

Fonctionnalits non-supportes

Description de service

Smantiques Recherche unifie


Tableau 1.

Description non-fonctionnelle limite ( travers des proprits du registre UDDI, telles "provider" ou "category"). Recherche base de mots-cls, sur un ensemble limit de paramtres. Chaque fournisseur de service dispose de son propre registre de services. Ces registres peuvent tre rpliqus.

Pas de support pour les informations non-fonctionnelles.

Peu de support pour les descriptions smantiques. Il faut effectuer des recherches spares sur chaque registre. Il n'existe pas de registre universel de ces registres.

Elments de la dcouverte de services et fonctionnalits associes

Les objectifs de cette thse concernent les fonctionnalits non-adresses par les protocoles de dcouverte actuels. Ces objectifs sont prsents dans les paragraphes suivants.

1.2 OBJECTIFS
Actuellement, la grande majorit des protocoles de dcouverte existants ne concerne que les interfaces fonctionnelles des services (CUDDY 2005). Les standards actuels des services Web ne fournissent qu'un support limit pour la prise en compte de requtes non-fonctionnelles, telles qu'illustr par lexemple de la recherche de restaurant, cit prcdemment. Nous souhaitons donc mettre en place un prototype pour la dcouverte de services Web, intgrant des informations contextuelles2. Afin datteindre cet objectif, nous devons dvelopper deux principaux composants: Un modle de description de service, qui utilise des outils smantiques pour dcrire les aspects non-fonctionnels d'un service; Un moteur de dcouverte, qui permet une recherche parmi l'ensemble des descriptions de services et qui emploie un algorithme utilisant le modle de description de service propos. Ce moteur implique le dveloppement de deux interfaces: la premire permet aux fournisseurs de services de crer des descriptions de services conformes notre modle, et la deuxime est destine aux utilisateurs finaux, utilise pour la cration de requtes, toujours bases sur notre modle de description de services. L'objectif principal de notre travail de recherche est divis en deux sous-objectifs, prsents dans ce qui suit. Le but est de tirer parti des outils existants, en les tendant et les combinant de manire originale et innovante. Les objectifs cls du prototype ainsi spcifi sont la simplicit de conception, d'implmentation et de dploiement.

Le prsent travail de recherche a t men dans le cadre dun contrat CIFRE avec lentreprise belfortaine PIMENTIC. Malheureusement, cette entreprise nexiste plus depuis le mois davril 2009. Nous navons donc pas pu bnficier dune aide pour lindustrialisation des rsultats scientifiques prsents ici.
Page 18

1.2.1 OBJECTIFS CONCERNANT LA DESCRIPTION DE SERVICES


Avant de pouvoir dcouvrir des services, ceux-ci doivent tre dcrits d'une manire qui facilite leur recherche et dcouverte. La plupart des algorithmes de recherche de service (tels la recherche Web ou UDDI) est base sur une recherche par mots-cls. Une telle recherche n'est pas suffisante pour la dcouverte de services, puisque deux mmes mots peuvent avoir des sens diffrents (homographes) (Homographe 2009) ou encore des mots diffrents peuvent avoir le mme sens (synonymes) (Synonymes 2009). A cela, nous pouvons ajouter les problmes gnrs par les fautes dorthographe lors de la saisie ou encore le sens des mots qui volue. Lors du choix du modle de description de service, il est donc important d'outrepasser les mots-cls et de tirer parti des descriptions smantiques. Un autre facteur prendre en compte est la flexibilit du modle de description choisi. Ce modle devra pouvoir tre tendu, par exemple en y intgrant des schmas dcrivant de nouveaux types de services.

1.2.2 OBJECTIFS CONCERNANT LE MOTEUR DE DECOUVERTE


Les protocoles de dcouverte de services peuvent tre classs dans deux catgories (ZHU et al. 2005): Protocoles sans registre dans ce type de protocole de dcouverte, les messages (notamment les publications et requtes de services) s'changent directement entre les fournisseurs de services et les utilisateurs. Protocoles base de registre ce type de protocole implique pour les fournisseurs de service d'enregistrer leurs services dans un registre ou annuaire. C'est le type d'architecture propos dans cette thse. L'utilisateur cre une requte de service, qui est ensuite adresse au registre. Un protocole de dcouverte est ds lors ncessaire pour parcourir ces registres et identifier les services rpondant la requte de l'utilisateur. En gnral, les protocoles de dcouverte traitent la requte utilisateur puis renvoient une liste de services jugs pertinents par rapport cette requte. Ensuite, c'est l'utilisateur de parcourir cette liste et de choisir le service qui rpond le mieux sa requte. Si le service ainsi choisi n'est pas satisfaisant, l'utilisateur parcourt nouveau la liste des services et en choisit un autre. Ce processus de slection de service est long et fastidieux. De plus un utilisateur peut tre novice et ne pas arriver diffrentier les services retourns par le protocole de dcouverte (ZHU et al. 2005). Le moteur de dcouverte de services dvelopp dans cette thse devra proposer lutilisateur une liste de services, ordonns selon leur degr de pertinence. Pour ce faire, le moteur de dcouverte devra calculer ce degr de pertinence pour chaque service rpondant la requte initiale de lutilisateur. Le but est de faciliter au maximum la recherche de lutilisateur et de toujours lui retourner en premier les rsultats les plus pertinents. Les interfaces dveloppes devront tre claires et permettre la cration de requtes diffrentes (simples ou complexes).

1.3 CONTRIBUTIONS
Dans cette partie, le but est d'exposer les principales contributions apportes par cette thse. Ces contributions concernent deux principaux domaines de recherche, savoir la description de services et la dcouverte de services.

Page 19

1.3.1 CONTRIBUTION CONCERNANT LA DESCRIPTION DE SERVICES


Traditionnellement, les descriptions de services Web sont des documents WSDL, dfinissant l'interface et les fonctionnalits du service. Ce type de description n'est pas suffisamment expressif en ce qui concerne les capacits non-fonctionnelles d'un service. Afin de rendre plus efficace la recherche et la dcouverte de services, il est ncessaire d'intgrer la smantique dans ces processus. La smantique doit tre utilise pour exprimer les informations non-fonctionnelles caractrisant un service. Toutefois, dans les traitements classiques, l'emploi de la smantique est souvent synonyme de problmes d'interoprabilit lors de l'change de donnes (WELTY 2000). Dans des domaines tels que la modlisation et la reprsentation des connaissances, de nombreuses recherches ont t menes afin d'identifier des outils et mthodes permettant d'exprimer cette smantique de manire explicite et non-ambigu (GUARINO 1997). Parmi les diffrentes approches ainsi identifies, l'utilisation des ontologies pour la reprsentation des connaissances a t identifie comme la plus prometteuse (STRANG 2004). Les ontologies peuvent rpondre au besoin d'exprimer les attributs non-fonctionnels ou contextuels d'un service. En effet, une ontologie permet de dfinir une structure de donnes complexe. Une ontologie modlise un ensemble de concepts, existants dans un domaine de connaissance donn, ainsi que les diffrentes relations reliant ces concepts. Des travaux de recherche ont abouti la mise en place de plusieurs ontologies dcrivant un service Web. Les diffrentes initiatives dans ce domaine sont listes dans la sous-section 2.2.3.2. Dans cette thse, nous avons choisi de baser notre approche sur le modle OWL-S. La principale raison motivant ce choix dcoule du fait que le schma de description de services dfini par le langage OWL-S (MARTIN 2004) encapsule la description WSDL (CHINNICI 2007) du service et facilite la dfinition d'attributs service non-fonctionnels. Dans le cadre de notre tude, nous proposons un schma structur pour la description d'attributs service non-fonctionnels, sur la base de la trame OWL-S. L'ide sous-jacente est d'tendre ainsi l'expressivit d'une description de service, afin d'obtenir des rponses plus pertinentes, par rapport une requte initiale. Une hirarchie de catgories de services sera dfinie, permettant d'tendre la dfinition donne par le modle OWL-S. De plus, nous tendons le modle OWL-S en dfinissant un nouveau concept, regroupant les informations contextuelles relatives aux diffrentes catgories de services.

1.3.2 CONTRIBUTION CONCERNANT LA DECOUVERTE DE SERVICES


Comme prcis plus haut, la deuxime contribution de cette thse concerne la dfinition et l'implmentation d'un prototype d'application, qui utilise la trame de description de service dfinie. Une fois la trame de description de services dfinie, elle sera intgre dans un prototype global, permettant la dcouverte de services sur la base de notre modle. Une interface utilisateur intuitive et simple sera dveloppe. Cette interface permettra l'utilisateur de saisir sa requte service, puis traduira cette requte en description de service ou en requte service. A travers cette interface, l'utilisateur peut dcrire quel serait le service idal rpondant sa demande. Cette description de service servira de rfrence lors de la recherche de services correspondant la requte utilisateur. L'interface utilisateur est prsente dans le Chapitre 5 (soussection 5.2.2) et son dveloppement est expliqu dans le Chapitre 6 (sous-section 6.3.1).

Page 20

Une deuxime interface sera dveloppe. Elle s'adresse aux fournisseurs de service souhaitant crer des descriptions de services conformes notre modle ontologique. Tout en gardant un lien avec les descriptions WSDL (supposes existantes pour chaque service), cette interface permettra de dcrire un service en utilisant le vocabulaire dfini dans notre ontologie. Nous la dcrivons dans la soussection 5.2.1, du Chapitre 5 et son implmentation est dtaille dans la sous-section 6.3.2, du Chapitre 6. Le moteur de dcouverte a pour but de trouver, dans le registre, les services correspondant la requte utilisateur. La sous-section 4.4 prsente en dtail lalgorithme qui est la base de ce moteur. Le dveloppement du moteur est prsent dans le Chapitre 6 (sous-section 6.2). Chacun des composants utilise une combinaison innovante d'outils, choisis de manire tre les plus adapts par rapport la description des services dfinie. Le moteur de dcouverte exploite efficacement les proprits de la trame de description des services. L'interface utilisateur est structure afin de permettre des requtes dtailles (portant sur un grand nombre d'attributs service), mais aussi des requtes plus simples. En se rapportant notre modle ontologique (voir le sous-section 4.3), le moteur de dcouverte peut prendre en compte plusieurs types de services, qui auraient t ignors dans le cas d'une recherche base de mots-cls. Grce au modle de description de services, le moteur de dcouverte peut dterminer qu'un utilisateur recherchant un restaurant peut tre intress par un tablissement de type relais ou encore auberge . Une recherche base uniquement sur des mots-cls n'aurait pris en compte que les services incluant le mot restaurant dans leur description.

1.4 PLAN DU RAPPORT


Cette thse comprend sept chapitres : Chapitre 1 Introduction et contributions gnrales; Chapitre 2 Etat de lart des technologies impliques ; Chapitre 3 Approches pour la dcouverte de services sensible au contexte ; Chapitre 4 Approche contextuelle pour la dcouverte de services Web smantiques ; Chapitre 5 Prsentation du prototype ; Chapitre 6 Dveloppement et implmentation du prototype ; Chapitre 7 Evaluation du prototype Chapitre 8 Conclusion gnrale et perspectives. Ce premier chapitre a t ddi prsentation de la problmatique et des principales contributions de ce travail de recherche. Le deuxime chapitre est un tat de l'art des technologies et concepts auxquels il est fait rfrence dans le restant de cette thse. Il traite des technologies impliques dans la dfinition et l'implmentation des services Web, mais aussi des technologies du Web smantique. Finalement, le chapitre prsente le concept des services Web smantiques et les technologies qui s'y relatent. Le troisime chapitre est une analyse des travaux prcdemment raliss dans le domaine de la dcouverte de services sensible au contexte. Aprs une introduction aux principes et concepts lis ce type de services, nous allons investiguer les diffrentes approches dcrites dans la littrature pour la dcouverte sensible au contexte de ces services. Ces travaux sont compars ensuite l'approche
Page 21

propose dans cette thse. Les points forts de cette approche seront mis en vidence par rapport aux solutions dj existantes. Le quatrime chapitre discute le rle d'une description de services et formalise la trame propose pour la description de paramtres service non-fonctionnels, ou autrement dit informations contextuelles . Ce modle repose sur la trame OWL-S, mais augmente cette dernire en introduisant de nouveaux concepts. Ce chapitre prsente aussi notre contribution concernant le moteur dcouverte, notamment l'algorithme sous-jacent. Le cinquime chapitre prsente le prototype que nous avons dvelopp, afin de mettre en uvre notre modle de description de services et notre Moteur Dcouverte . Y sont prsents l'architecture du prototype, les diffrentes interfaces, ainsi que l'architecture propose pour le moteur dcouverte. Le sixime chapitre prsente l'implmentation de notre approche. Notre prototype repose sur la plate-forme mobile Android ; nous commenons donc par prsenter les caractristiques de cette dernire. Nous nous intressons ensuite au dveloppement du moteur dcouverte, puis au dveloppement des deux interfaces, que nous appelons Interface utilisateur final et Interface fournisseur de services . Le septime chapitre prsente une mthode dvaluation de notre prototype, ainsi que les rsultats associs. Il sagit dvaluer le prototype en fonction du temps ncessaire lexcution dune requte de lutilisateur. Nous y discutons aussi lvaluation de notre prototype par rapport la satisfaction des utilisateurs. Le dernier chapitre rsume les recherches prsentes et traite des travaux futurs ncessaires pour amliorer notre prototype. Nous discutons aussi les principales perspectives (applicatives et acadmiques) concernant nos travaux de recherche. Finalement, et titre d'illustration, les diffrentes annexes prsentent quelques exemples de descriptions de services, ainsi que quelques fragments des ontologies dveloppes dans cette thse. Nous y listons aussi des fragments de code Java, extraits des fichiers dvelopps pour notre prototype.

Page 22

CHAPITRE 2. ETAT DE L'ART DES TECHNOLOGIES IMPLIQUEES

Ce chapitre prsente les technologies et les standards qui ont t choisis comme base de dpart pour ce travail de recherche. Il s'agit notamment des standards des services Web et des outils du Web smantique. Nous souhaitons ainsi dfinir l'arrire-plan (technique et scientifique) ncessaire pour la comprhension de rsultats prsents.

2.1 Les services Web ____________________________________________________________ 24


2.1.1 Dfinition ________________________________________________________________________ 24 2.1.2 Composants de base d'un service Web ________________________________________________ 24 2.1.3 Conclusion _______________________________________________________________________ 33

2.2 Les principes du Web smantique ______________________________________________ 33


2.2.1 Vision du Web Smantique __________________________________________________________ 33 2.2.2 Les mtadonnes __________________________________________________________________ 34 2.2.3 Les ontologies - vocabulaires pour les mtadonnes _____________________________________ 35 2.2.4 Conclusion _______________________________________________________________________ 46

2.3 Les services Web smantiques _________________________________________________ 46


2.3.1 Smantiques des services Web _______________________________________________________ 47 2.3.2 Description des services Web Smantiques _____________________________________________ 47 2.3.3 L'approche OWL-S _________________________________________________________________ 49

2.4 Conclusion _________________________________________________________________ 52

Page 23

2.1 LES SERVICES WEB


2.1.1 DEFINITION
Les services reprsentent un concept trs en vogue dans l'informatique d'aujourd'hui, mais peu de personnes peuvent en donner une dfinition claire et exacte. Non seulement les dfinitions varient en fonction du domaine d'application, mais mme pour un mme domaine d'application, plusieurs dfinitions similaires existent. Il est communment sous-entendu qu'un service reprsente un travail effectu pour une autre partie, avec ou sans contrepartie (Service 2009). Par contre dans des domaines bien prcis, tels l'conomie, la cuisine ou encore le sport, un service ne correspond pas cette dfinition (Service 2009). Dans le domaine du Web, le W3C (World Wide Web Consortium) dfinit un service comme tant une application logicielle, identifie par une URI (Unified Ressource Identifier), dont les interfaces et connexions sont dfinies, dcrites et dcouvertes par des artfacts XML (Service 2009a). Le W3C spcifie que les interactions entre services sont directes et reposent sur des messages de type XML, envoys via des protocoles Internet. Un des points communs parmi ces dfinitions est le fait qu'un service reprsente une fonctionnalit fournie et exploite, souvent, mais pas toujours, distance. A partir de l, un service Web est dfini en tant que fonctionnalit pouvant tre engage (invoque, recherche, excute, etc.) travers le Web. Nous allons donner plus dexplications de cette dfinition dans les paragraphes suivants.

2.1.2 COMPOSANTS DE BASE D'UN SERVICE WEB


Le modle architectural des services Web est illustr par la Figure 2.

Figure 2.Modle architectural des services Web.

Trois entits distinctes peuvent tre identifies: Les fournisseurs de services, qui crent et publient des services Web pour des utilisateurs potentiels.

Page 24

Les demandeurs de services, qui recherchent travers les registres des courtiers de services, pour trouver des fournisseurs de services rpondant leur demande. Les agents de services ( service broker en anglais), qui grent un registre de publications de services, et dont la mission est de mettre en relation les fournisseurs de services avec les demandeurs de services. Le modle architectural des services Web est bas sur les principes suivants (Figure 2): Connexion afin que les fournisseurs et demandeurs de services puissent se connecter et changer des informations entre eux, un langage commun est ncessaire. Il s'agit du langage XML (voir 2.1.2.1). Communication la communication entre les diffrentes entits dcrites plus haut, ncessite elle aussi un protocole commun. Il s'agit principalement des protocoles XML-RPC (voir 2.1.2.2.1) et SOAP (voir 2.1.2.2.2). Description la description des services (noms des fonctions, paramtres, rsultats, etc.) doit utiliser un langage commun, afin de pouvoir tre interprte et comprise par l'ensemble des entits du systme. Le langage permettant de dcrire les services est le langage WSDL (voir 2.1.2.3). Dcouverte les demandeurs de services doivent pouvoir rechercher les services, travers une structure accessible tous. Ceci est ralis par le registre UDDI (voir 2.1.2.5), qui spcifie un registre pour les services. Mis part ces composants de base, il est ncessaire d'tablir une entente pralable, concernant les smantiques utiliser. Diffrentes approches existent pour la reprsentation des smantiques des services. Ces aspects seront traits plus loin dans ce chapitre (voir 2.2). Le but de cette partie est d'introduire les lments cls des services Web, et c'est ce que nous dtaillons dans les paragraphes suivants. 2.1.2.1 L E LANGAGE XML Le langage XML reprsente le langage fondamental pour le dploiement de services Web. Le XML rgularise la syntaxe HTML, en la rendant plus facile analyser et traiter. Le langage XML offre les avantages suivants (BRAY 2008): Il peut tre tendu de nouvelles applications; Il supporte, la fois, les donnes non-structures (par exemple les documents) et les donnes structures (par exemple bases de donnes); Il permet des requtes en fonction de la structure d'un document - il est possible d'crire une requte pour un document XML en prcisant sa structure ou alors la valeur de certains de ses champs. Les donnes tiquetes base XML peuvent tre valides mcaniquement. Le langage XML fournit un formatage de donnes (structures ou non), mais ne prcise pas les smantiques de ce formatage. Afin de partager des informations et des connaissances entre diffrentes applications, il faut un ensemble partag de termes, dcrivant le domaine de l'application. La sous-section 2.2.3 prsente des langages formels, pouvant tre utiliss en ce sens. Ces langages peuvent tre exprims en XML, mais conceptuellement parlant, ils sont situs un niveau suprieur au XML.

Page 25

2.1.2.2 P ROTOCOLES DE COMMUNICATION Il existe deux mthodes pour dialoguer avec un service Web, le protocole XML-RPC et le protocole SOAP. 2.1.2.2.1 L E PROTOCOLE XML-RPC XML-RPC est le plus simple des formats d'change. Le principe de base est le suivant (WINER 1999): Sur le poste client, une bibliothque encode les paramtres de la requte en XML ; Sur le poste serveur, une (autre) bibliothque les dcode et les transmet l'application. La procdure inverse a lieu lors de l'envoi de la rponse la requte vers le poste client. En dfinitive, le programmeur n'a jamais besoin de coder lui-mme le format de sortie en XML, puisque, dans le cadre du langage de programmation qu'il utilise, des fonctions se chargent des oprations sa place. Il n'en voit que le rsultat final. Le systme a malheureusement des limites. En thorie, par exemple, les seuls transferts autoriss se font sous le format ASCII, mme si des extensions non officielles autorisent les transferts en Unicode. De plus, ce format n'est pas normalis par un organisme indpendant et neutre (comme le W3C). 2.1.2.2.2 L E PROTOCOLE SOAP Il s'agit du protocole actuellement le plus en vogue; il est promu par le W3C lui-mme, ainsi que par Microsoft. La premire recommandation date de juillet 2002 (GUDGIN 2007). Le principe est le mme que pour le XML-RPC (GUDGIN 2007) : le programmeur ne voit jamais le fichier XML que son poste met ou reoit, car tout est gr par une bibliothque de fonctions et procdures, dont il ne peroit que le rsultat final, avec le format habituel de son langage de programmation favori. Un message SOAP peut tre compar une lettre poste. Ceci est illustr par la Figure 3.

Page 26

Figure 3.Principe de fonctionnement du protocole SOAP.

En effet, lorsque nous crivons une lettre, nous la mettons dans une enveloppe sur laquelle nous indiquons le nom et l'adresse du destinataire, sans oublier d'y joindre un timbre. Lorsque ce processus est compar au processus d'envoi d'un message SOAP, nous remarquons plus d'un aspect commun. En effet, dans le cas de SOAP, la lettre devient un document XML qui est inclus dans une enveloppe SOAP. Cette enveloppe SOAP contient donc le document XML, mais aussi une en-tte avec des informations de routage et/ou de scurit. Une fois cette enveloppe cre, elle est convertie en une requte SOAP et envoye un client SOAP, afin d'tre achemine vers sa destination. Cela revient poster une lettre dans une bote aux lettres. Le client SOAP reoit le message et l'achemine vers sa destination. Lors de cette tape, le message peut traverser plusieurs serveurs SOAP intermdiaires. Le routage du message SOAP dpend des informations de routage renseignes dans l'en-tte du message. Lorsque le message SOAP arrive destination, il est reu par un serveur SOAP. Le serveur SOAP ouvre l'enveloppe et transfre le message qu'elle contient au service Web concern. Comme nous l'avons indiqu ci-dessus, un message SOAP est un document XML. Ce document XML contient les lments suivants (schmatiss par la Figure 4) (GUDGIN 2007) : Une Enveloppe (Envelope) permet d'identifier le document XML en tant que message SOAP; Une En-tte (Header) contient des informations concernant la requte dfinie dans le corps du message SOAP. Elle peut contenir d'ventuelles informations de scurit ou routage, ou encore des informations contextuelles ou en lien avec le profil utilisateur; Le Corps (Body) du message contient le document envoyer, c'est--dire la requte et une trame XML pour la rponse; L'lment Faute (Fault) contient des informations sur les erreurs pouvant tre rencontres lors du traitement du message.

Figure 4.Structure dun message SOAP.

La spcification SOAP est en perptuelle rvision. Elle ne dcrit pas encore la communication bidirectionnelle ou multi-parties, aspects qui pourraient tre utiles la composition de services Web en provenance de diffrents fournisseurs. De plus, SOAP ne permet pas le transfert des smantiques de la transaction. Ce protocole n'est donc efficace que pour une interoprabilit simple, impliquant un seul client et un seul serveur.

Page 27

2.1.2.3 WSDL Le modle architectural des services Web (dcrit dans la sous-section 2.1.2) suppose que les services peuvent tre trouvs et utiliss. Ceci suppose en retour que chaque service est dcrit avec prcision . Ceci est ralis grce au langage WSDL qui est un langage XML permettant de dcrire des interfaces de programmation pour un service Web. Une description WSDL inclut des dfinitions de types de donnes, de messages d'entre et sortie, d'oprations fournies par le service, d'adresses rseau, etc. En d'autres termes, le langage de description de services Web (WSDL) dcrit une interface abstraite pour les services Web, tout en permettant d'y relier un protocole de transport spcifique, tel HTTP. Ceci permet d'avoir plusieurs implmentations systme pour une mme interface abstraite. La description d'un service Web peut donc tre comprise et interprte par des systmes diffrents. A l'image d'un message SOAP, qui est encapsul dans un lment <enveloppe>, les documents WSDL sont encapsuls dans un lment appel <definitions>. Un document WSDL peut ainsi tre vu comme un ensemble de dfinitions (CHRISTENSEN 2001). Les documents WSDL contiennent cinq parties distinctes, tel qu'illustr par la Figure 5.

Figure 5.Structure dun document WSDL.

Un des lments importants de cette description est l'lment portType. Cet lment peut tre apparent une interface Java, puisqu'il permet de dfinir un ensemble d'oprations. La Figure 6 met en vidence les similitudes entre l'lment portType et une classe Java. L'lment portType contient un ensemble d'lments operation , chacun de ces lments dfinissant une fonction spcifique de l'lment portType. Ceci peut tre apparent une mthode dans une classe.

Page 28

Figure 6.Liens entre les lments WSDL et une classe Java.

Le standard WSDL dfinit quatre types d'oprations3: Opration sens unique (one way) - recevoir un message; Opration de notification ( notification) - envoyer un message; Opration requte/rponse (Request-response) - recevoir une requte, puis mettre la rponse correspondante; Opration sollicitant une rponse (Solicit-response) - mettre une requte et recevoir la rponse correspondante. Chaque lment <operation> a des lments <message> associs. Un lment <message> est une dfinition abstraite de donnes et types de donnes. Un lment <message> dcrit un message sens unique: soit une requte (input), soit une rponse (output). Un lment <message> dfinit le nom du message et peut contenir zro ou plusieurs lments de partie de message (se rfrant des paramtres du message ou des valeurs de retour du message). Les lments <message> peuvent tre apparents des arguments d'une mthode Java (voir Figure 6). 2.1.2.4 L ES SERVICES REGISTRE Le but d'un service de registre est de permettre des composants ou des participants de se localiser les uns les autres. Les composants ou participants peuvent tre des applications, des agents, des fournisseurs de services Web ou des demandeurs de services Web. Les registres rassemblent et organisent des informations d'identification (adresses sur le rseau, descriptions, etc.), puis les mettent disposition des clients. Les registres reposent sur deux principaux standards: ebXML (ebXML 2009) et UDDI (BELLWOOD 2004). Malheureusement, aucun de ces standards ne prend en compte les descriptions smantiques des services. Ils ne supportent pas non plus les recherches smantiques de fonctionnalits. Les seules mthodes de recherche implmentes sont bases sur des mots-cls, tels le nom du service ou du fournisseur de service. Seul le standard ebXML permet d'effectuer des recherches de type requte SQL, mais ces recherches ne considrent que les mots-cls.

Dans sa version 2.0, le WSDL (CHINNICI 2007) offre un ensemble plus riche de primitives, permettant entre autres de recevoir ou d'envoyer des rponses multiples une seule requte. Mais ces dtails ne sont pas importants par rapport au but de ce chapitre.
Page 29

Dans ce qui suit, nous allons nous intresser de plus prs aux fonctionnalits du standard UDDI. 2.1.2.5 UDDI La spcification UDDI (BELLWOOD 2004) dcrit un mcanisme permettant de rfrencer des services Web. Le standard UDDI a t publi par Ariba, Microsoft, IBM et une trentaine dautres entreprises, en septembre 2000. Le schma XML de l'UDDI dfinit quatre principaux types de donnes pour les entreprises et les informations services. Pour chacun de ces types, il existe une structure XML prcisant les champs obligatoires et les champs optionnels. Les quatre entits ainsi dfinies sont: businessEntity, businessService, bindingTemplate et tModel. La Figure 7 illustre ces quatre entits de base, ainsi que leurs relations.

Figure 7.Entits de base du registre UDDI.

Ces quatre entits permettent de reprsenter trois types d'information: Les Pages Blanches contiennent des adresses, des contacts et d'autres informations gnrales, concernant des entreprises ou des individus. Par exemple, les Pages Blanches peuvent tre utilises afin de rechercher une entreprise dont on connat le nom. C'est la structure l'entit businessEntity qui est utilise afin de reprsenter ce niveau d'information. Un registre UDDI de type Pages Blanches contient les champs d'information suivants: o Nom de l'entreprise ; o Description textuelle de l'entreprise ; o Des informations de contact (noms, numros de tlphone, sites Web, etc.) ;

Page 30

o Des identifiants de l'entreprise (D-U-N-S4 ou Thomas Register5). Les Pages Jaunes contiennent des classifications industrielles pour les entreprises, en fonction de taxonomies standard telles le NAICS (NAICS 2009) ou la classification de Nice (Classfication de Nice 2009). C'est la structure de l'entit businessService qui est utilise afin de reprsenter ce niveau de classification. Une entit businessEntity peut rfrencer plusieurs structures businessService. Un registre UDDI de type Pages Jaunes contient les champs d'information suivants: o Un identifiant dans une classification internationale pour l'entreprise (par exemple un code NAICS ou un code de la classification de Nice); o Un identifiant dans une classification internationale pour chaque type de service et/ou produit offert par l'entreprise; o Une position gographique respectant un format standard6. Les Pages Vertes contiennent des informations techniques concernant les services fournis par les entreprises. Il s'agit, entre autres, de rfrences des spcifications d'interfaces pour les services Web. Le modle des Pages Vertes est plus compliqu, car il contient des informations plus varies (processus mtier, descriptions de services, informations de liaison, etc.). Afin de mieux comprendre le fonctionnement du modle UDDI, nous allons prendre l'exemple d'une entreprise nomme Mon Entreprise qui offre un service d'actualits. Ceci est illustr par la Figure 8. L'lment businessEntity fournit une cl ( ABCD ) et un nom ( Mon Entreprise ). La structure de l'lment businessService reprsente le service actualits de Mon Entreprise . Elle rfrence l'lment businessEntity en utilisant sa cl, puis dfinit une cl pour le service lui- mme ( EFGH ). La structure de l'lment businessService est rfrence travers deux lments bindingTemplate. Le premier d'entre eux est une page Web disponible l'adresse "http://infos.monentreprise.com". Le deuxime d'entre eux est un service Web disponible l'adresse: "http://monentreprise.com/infos". Les deux lments bindingTemplate rfrencent l'lment serviceTemplate en utilisant sa cl de service, tout en fournissant eux-mmes des cls de liaison. Llment bindingTemplate du service Web fournit plus d'informations relatives aux mthodes d'invocation pour ce service. Ceci est ralis rfrenant une entit tModelInstanceInfo, qui fournit une cl de type tModel ( QRST ). Cette entit tModelInstanceInfo est contenue dans une structure tModelInstanceDetails qui permet le rfrencement de plusieurs cls de type tModel. La structure tModel dont la cl est QRST contient une URL indiquant l'emplacement de la description WSDL du service ("http://monentreprise.com/infos?wsdl").

Le Numro D-U-N-S est une squence didentification unique neuf chiffres qui garantit une identification sre et unique de chaque entreprise et permet de dcouvrir des structures d'apparentement l'chelle mondiale. (D&B 2009) 5 Considr comme le plus grand annuaire pages vertes au monde, ce registre couvre plus de 650000 fournisseurs de services, classs dans plus de 67000 catgories industrielles (Thomas Register 2009). 6 La norme ISO 3166 dfinit un code pour la quasi totalit des pays du monde (ISO 3166 2009).
Page 31

Figure 8.Fonctionnement du modle UDDI.

La spcification UDDI offre un ensemble limit de moyens pour permettre aux utilisateurs finaux de rechercher des services. Afin d'illustrer les contraintes de la recherche dans un registre UDDI, la Figure 9 donne un exemple de requte pour le service d'information dfini plus haut.
<find_business> <findQualifiers> <findQualifier> Uddi :uddi.org :findQualifier :exactMatch </findQualifier> </findQualifiers> <name> Mon Entreprise </name> </find_business> Figure 9.Exemple de requte service UDDI.

La requte ainsi dcrite illustre une structure find_business qui filtre la requte afin de dterminer une correspondance exacte sur le nom de l'entreprise. Une telle requte est achemine vers la structure businessEntity du registre UDDI. Le protocole UDDI dfinit des requtes quivalentes pour les trois autres structures (businessService, bindingTemplate and tModel). Le modle de dcouverte UDDI est bas sur le principe du parcours du registre: un utilisateur peut parcourir l'ensemble des services mis disposition par une entreprise donne ou alors l'ensemble des services existant dans une catgorie donne. Ce type de recherche a deux principaux inconvnients:

Page 32

Elle peut retourner un nombre ingrable de rsultats; Elle ncessite une grande implication/participation de la part de l'utilisateur final. Un autre problme de la recherche dans un registre UDDI est constitu par le fait que les fournisseurs de services interprtent de manire errone les champs dans les structures de donnes UDDI (ERL 2005). Les informations manquantes, couples des paramtres de recherche hautement structurs et ncessaires pour effectuer une recherche dans un registre UDDI, jouent au dtriment de la compltude de la dcouverte de services.

2.1.3 CONCLUSION
Telle que nous l'avons prsente ci-dessus, la notion de service Web repose sur des standards bien connus. Le modle ainsi dcrit est dj mis en uvre par une multitude d'acteurs. Ce modle repose sur des technologies et protocoles issus du monde de l'Internet, et dfinit une architecture distribue. L'implmentation de ce modle est relativement peu complexe et donc aisment accessible aux fournisseurs de services. Le principal inconvnient de ce modle est que les technologies inhrentes ne prennent pas en compte les aspects non-fonctionnels des services Web. Des efforts de recherche et de standardisation existent et sont mens travers le monde, avec pour but d'tendre la description des composants technologiques des services Web en utilisant des vocabulaires prcis de termes. La partie suivante prsente ces approches plus en dtail.

2.2 LES PRINCIPES DU WEB SEMANTIQUE


Le but de cette partie est de permettre la comprhension de la nature des donnes et contenus du Web smantique, ainsi que de discuter les approches permettant de reprsenter des mtadonnes. Le principal but du Web smantique est de se construire, au dessus du Web actuel (ou Web syntaxique), afin de donner chaque donne un sens bien dfini, pouvant tre interprt par un ordinateur. Dans ce qui suit, nous allons prsenter le rle que jouent les descriptions de mtadonnes et les ontologies dans l'atteinte de ce but.

2.2.1 VISION DU WEB SEMANTIQUE


C'est en 2001 que les auteurs Berners-Lee, Hendler et Lassila publient un article rvolutionnaire, dans le journal Scientific American , intitul The Semantic Web: A New Form of Web Content That Is Meaningful to Computers Will Unleash a Revolution of New Possibilities (BERNERS-LEE et al. 2001). Dans cet article, les auteurs dfinissent la vision du Web smantique, travers des scnarios. Un des scnarios prsente Lucy qui a besoin de programmer une srie de consultations mdicales pour sa mre. Plusieurs contraintes doivent tre prises en compte, dont des contraintes gographiques, des contraintes concernant les qualifications des mdecins, ou encore des contraintes lies au calendrier de Lucy. Afin d'aider Lucy trouver une solution, un agent peut mener des ngociations entre les diffrentes parties: les mdecins, l'agenda de Lucy et le registre de services mdicaux, entre autres. L'ide cl derrire cet exemple est d'affirmer que, mme si chacune de ces parties code son information d'une manire diffrente, c'est la couche smantique qui rend possibles les interactions et les changes de donnes entre ces parties. De plus, les donnes

Page 33

changes peuvent tre comprises par un programme informatique (l'agent). Les auteurs appellent Web smantique la technologie permettant d'atteindre cette vision7. Afin d'organiser le contenu du Web actuel, les chercheurs dans l'intelligence artificielle ont propos une srie de modles conceptuels. L'ide centrale est de structurer l'information en catgories, de manire faciliter son accs. Or, cette ide est similaire la solution utilise pour classifier les tres vivants en biologie. En effet, les biologistes utilisent une taxonomie bien dfinie, la taxonomie de Linn (Taxinomie 2009). En s'inspirant de cette approche, les chercheurs en informatique essayent de trouver un modle similaire permettant de structurer le contenu du Web actuel. Toutefois, il a toujours t dit que le Web a connu un grand succs justement cause du degr de libert qu'il permet. Il est en effet possible de trouver, dans un mme environnement, des pages Web sophistiques, cres par des spcialistes, et des pages Web personnelles, cres par des personnes ayant peu de connaissances en informatique. Il n'existe pas de censure quant la qualit de l'information prsente dans une page Web. Dans un tel environnement, chacun est libre d'exprimer ce qu'il veut et ce concernant n'importe quel sujet8. Il est ds lors difficile d'imaginer avoir un unique modle organisationnel pour l'ensemble du Web. D'aprs ces quelques considrations, il est vident que les mtadonnes forment un aspect cl dans l'application de la vision du Web smantique. Toutefois, les descriptions travers les mtadonnes doivent respecter des rgles prcises. Le Web smantique a besoin de modles permettant d'organiser les connaissances d'une manire souple et non-contraignante. Les technologies permettant d'atteindre cette vision sont dcrites dans ce qui suit.

2.2.2 LES METADONNEES


Nous venons de voir que, dans la vision du Web smantique, il s'agit de cataloguer une quantit norme de ressources, virtuelles pour la plupart d'entre elles, rparties travers le monde, et codes avec des langages diffrents. Une solution ce problme est reprsente par l'usage de mtadonnes. Les mtadonnes sont dfinies en tant que donnes ou informations concernant d'autres donnes9. Berners-Lee donne toutefois une dfinition des mtadonnes qui est mieux adapte au cadre du Web smantique10: (dans la conception Web) les mtadonnes reprsentent des informations comprhensibles par des ordinateurs et qui concernent des ressources Web ou dautres choses (BERNERS-LEE 1998). Cette dfinition nous amne vers le concept de donnes comprhensibles par un ordinateur. En effet, le but ultime des mtadonnes identifi par Berners-Lee est la production d'informations qui s'auto-dcrivent. Pour ce faire, les mtadonnes doivent contenir une rfrence vers une spcification des smantiques qui leurs sont associes (BERNERS-LEE 1998). La smantique
Toutefois, les auteurs prcisent que les actions dcrites dans les scnarios peuvent tre ralises en utilisant les technologies du Web actuel (syntaxique), mais avec des efforts considrables. La promesse du Web Smantique est de librer les utilisateurs des tches encombrantes et pnibles. 8 Il s'agit en fait du slogan AAA: Anyone can say Anything about Any topic (ALLEMANG 2008). 9 La fdration IFLA donne la dfinition suivante: Metadata is data about data. The term refers to any data used to aid the identification, description and location of networked electronic resources. Many different metadata formats exist, some quite simple in their description, others quite complex and rich (METADATA 2005). 10 (BERNERS-LEE 1998) (in Web design) Metadata is machine understandable information about Web resources or other things.
Page 34
7

des ressources du Web actuel doit donc tre rendue comprhensible pour les ordinateurs. Pour ce faire, il faut dterminer une reprsentation formelle et standardise qui puisse tre utilise par les machines lors de l'change d'informations. Il sagit donc de spcifier un vocabulaire (ou des smantiques) utiliser. Dans le cas du Web smantique, cette spcification repose sur l'usage d'ontologies.

2.2.3 LES ONTOLOGIES - VOCABULAIRES POUR LES METADONNEES


2.2.3.1 D EFINITIONS Le mot ontologie vient du grec ontos (tre) et logos (mot). Au 19me sicle, il est introduit en philosophie par des philosophes allemands afin de pouvoir diffrencier l'tude de l'tre en tant que tel, de l'tude, dans les sciences naturelles, de diffrents tres vivants. Dans (SOWA 1997), Sowa dfinit l'ontologie en tant que discipline philosophique: Le sujet de l'Ontologie est l'tude des catgories de choses/objets existant ou pouvant exister dans un domaine donn. Le produit d'une telle tude, appel ontologie, est un catalogue des types d'objets existant dans un domaine D du point de vue d'une personne utilisant un langage L pour parler de D11. En informatique, les ontologies ont t adoptes dans le domaine de l'intelligence artificielle pour faciliter le partage et la rutilisation de connaissances (ALESSO 2006). Aujourd'hui, leur usage se rpand dans divers domaines tels l'intgration d'informations intelligentes, les systmes d'information coopratifs, le commerce lectronique ou encore dans le dveloppement de logiciels base d'agents. Les ontologies sont des modles conceptuels capturant et rendant explicite le vocabulaire utilis dans des applications smantiques. Les ontologies garantissent une communication sans ambiguts. Elles sont considres en tant que lingua franca 12 du Web smantique. Dans (ALESSO 2006), les auteurs dfinissent une ontologie en tant qu'entente entre des agents changeant des informations. Cette entente porte sur un modle pour la structure et l'interprtation des informations changes, ainsi que sur un vocabulaire dlimitant les changes13. La dfinition donne par le W3C (MCGUINESS 2004) est la suivante: Le terme d'ontologie est un terme emprunt la philosophie qui fait rfrence la science de dcrire les types d'entits du monde et les relations qu'elles ont entre elles14 . Les entits composant une ontologie sont les suivantes: Des concepts dans un domaine d'intrt donn; Des relations entre ces objets; Des proprits (ou attributs) que possdent les objets ;

The subject of Ontology is the study of the categories of things that exist or may exist in some domain. The product of such a study, called ontology, is a catalogue of the types of things that are assumed to exist in a domain of interest D from the perspective of a person who uses a language L for the purpose of talking about D. 12 Le terme de lingua franca dsigne une langue vhiculaire utilise par une population donne pour communiquer. (Lingua franca 2009). 13 An ontology is an agreement between agents that exchange information. The agreement is a model for structuring and interpreting exchanged data and a vocabulary that constrains these exchanges. 14 Ontology is a term borrowed from philosophy that refers to the science of describing the kinds of entities in the world and how they are related.
Page 35

11

Des instances reprsentant des objets concrets (nomms et identifiables) dans le domaine dintrt vis. Ces entits constituent un vocabulaire ontologique, pour un domaine dintrt donn. Une ontologie peut ds lors tre vue en tant quun ensemble dnoncs, exprims en utilisant les termes de ce vocabulaire. Ces noncs sont souvent appels axiomes (GRIMM et al. 2007a). Lnonc Madame X est une employe constitue un exemple daxiome simple, impliquant un concept ( employe ) et une instance ( Madame X ). Dans (MAEDCHE et STAAB 2001) les auteurs dfinissent une ontologie en tant quun ensemble , , , , , o: reprsente l'ensemble des concepts ; reprsente l'ensemble des relations ; reprsente une hirarchie de concepts ou encore une taxonomie (Taxinomie 2009). La notation , dfinit le concept C1 en tant que sous-concept de C2 ; : est une fonction reliant les concepts d'une manire non-taxonomique ; reprsente l'ensemble des axiomes de l'ontologie, exprims en utilisant un langage logique et dcrivant des contraintes supplmentaires pour l'ontologie. Indpendamment de la dfinition adopte, il est important de noter que les ontologies sont utilises afin de dcrire une grande varit de modles. Gnralement, les ontologies sont diffrencies des bases de connaissances, dont le rle est de dcrire la connaissance en termes de taxonomies conceptuelles et dnoncs gnraux (GRIMM et al. 2007a). Dans notre vision, une ontologie reprsente un ensemble de connaissances pouvant tre utilis par une application base de connaissances, et ce parmi dautres ensembles de connaissances (notamment dautres ontologies ou des mtadonnes). A chaque fois que lapplication base de connaissances doit consulter lontologie, elle charge une partie des spcifications de lontologie dans une base de connaissances. Une base de connaissances est ds lors constitue dun ensemble dontologies (ou fragments dontologies), chacune concernant un domaine de connaissance diffrent. 2.2.3.2 L ANGAGES DE DESCRIPTION D ' ONTOLOGIES Nous venons de dfinir les principaux composants d'une ontologie comme tant les concepts, les relations, les proprits et les instances. Ces lments permettent de constituer un vocabulaire ontologique pour un domaine donn. Une ontologie peut alors tre vue comme un ensemble de propositions exprimes utilisant les termes de ce vocabulaire. A premire vue, modliser une ontologie semble tre similaire la modlisation de logiciels orientsobjet ou encore la conception de diagrammes de type entit-relation pour les bases de donnes. Il y a cependant deux diffrences majeures (GRIMM et al. 2007a) : Premirement, les langages de description d'ontologies fournissent des smantiques formelles plus riches que celles fournies par les formalismes orients-objet ou lis aux bases de donnes. Une ontologie spcifie une axiomatisation de connaissances dans un certain domaine, plutt qu'un modle de donnes ou qu'un modle objet. Deuximement, les ontologies sont gnralement dveloppes des fins diffrentes par rapport aux modles orients-objet ou par rapport aux diagrammes entits-relations.

Page 36

Alors que les derniers dcrivent des composants d'un systme d'information, ou alors un schma pour le stockage de donnes, une ontologie capture la connaissance d'un certain domaine en tant que telle et permet de raisonner propos de cette connaissance. Afin de rendre les ontologies disponibles pour des systmes d'information, plusieurs langages d'ontologie ont t conus et proposs des fins de standardisation. Un langage de description d'ontologie est conu pour dfinir des ontologies. Ces langages reoivent une attention croissante depuis l'mergence de la vision du Web smantique. L'architecture en couches du Web smantique (ALESSO 2006) (voir Figure 10) permet d'avoir une vue d'ensemble de la relation entre les diffrents langages de description d'ontologies. La couche infrieure contient les mcanismes de rfrencement (URI) et d'encodage des caractres (Unicode). La deuxime couche introduit le langage XML en tant que standard pour l'change de documents. La troisime couche comprend les langages RDF (Ressource Description Framework) et RDF Schema en tant que mcanismes pour dcrire les ressources disponibles sur le Web. Ces deux langages sont ainsi considrs en tant que langages simples. Les langages complets apparaissent dans la quatrime couche, en permettant de capturer plus de smantiques. Enfin, la dernire couche introduit les langages base de rgles, dont l'tude est en dehors des objectifs de cette thse.

Figure 10.

Architecture du Web smantique (adapt depuis (ALESSO 2006)).

Dans ce qui suit, nous allons prsenter un bref aperu des langages RDF et RDF Schema (RDFS), puis nous allons dcrire les concepts de base du langage OWL (Ontology Web Language), actuellement considr comme le standard pour la description des ontologies Web. 2.2.3.2.1 L ES LANGAGES RDF ET RDFS Une des premires initiatives de standardisation d'un langage permettant les annotations smantiques de ressources Web, a t celle initie par le W3C et qui a donne naissance aux langages RDF et RDF Schema. Publis le 10 Fvrier 2004, ces deux langages concernent plus particulirement les annotations de ressources Web identifiables, telles le titre ou l'auteur d'une page Web. Le langage RDFS est une extension du langage RDF, introduisant les notions de classes de ressources et de hirarchie de classes. L'usage combin de RDF et RDFS est souvent rfrenc en tant que RDF(S) et fournit un langage d'ontologie simple pour des modlisations conceptuelles. L'approche RDF(S) utilise pour la reprsentation d'annotations de ressources est base sur les ides suivantes (BREITMANN 2007) :

Page 37

Les ressources sont identifies grce des URI (Uniform Resource Identifier). Une ressource dispose ainsi d'un identifiant unique sur le Web. Ceci permet une organisation dcentralise de la connaissance des ressources. Une URI permet d'identifier les types suivants de ressources: des individus, des types d'objets, ou encore des proprits de ces objets. Un nonc RDF est un triplet , , . Un triplet , , permet de relier un Sujet un Objet , par l'intermdiaire d'un Prdicat . Ces lments (Sujet, Prdicat, Objet) reprsentent des ressources, identifies par des URI. Le Sujet reprsente la ressource dcrire; le Prdicat reprsente une proprit particulire de cette ressource. L'Objet dun nonc RDF peut tre une URI (et dans ce cas il est appel objet de lnonc) ou une valeur littrale (et dans ce cas il reprsente la valeur de la proprit). Le Tableau 2 illustre plusieurs noncs RDF. Lnonc E1 dfinit lauteur du document dont l'URI est "http://www.gsem.fr/documents#D42305". Les noncs E2 et E3 dfinissent respectivement le titre et la date15 de ce document ( Liste Publications Roxin et 11-112009 ). Sujet Enonc E1 Prdicat Objet (une URI) Sujet Enonc E2 Prdicat Objet (une valeur) Sujet Enonc E3 Prdicat Objet (une valeur) http://www.gsem.fr/documents#D42305 http://purl.org/dc/elements/1.1/creator http://www.gsem.fr/auteur#ROX639 http://www.gsem.fr/documents#D42305 http://purl.org/dc/elements/1.1/title Liste Publications Roxin http://www.gsem.fr/documents#D42305 http://purl.org/dc/elements/1.1/date 11-11-2009
Exemples dnoncs RDF.

Le document D42305 a t cr par lauteur ROX639. Le document D42305 a pour titre Liste Publications Roxin . Le document D42305 a pour date le 11 Novembre 2009.

Tableau 2.

Plusieurs triplets RDF forment un graphe RDF. Les nuds dun graphe RDF reprsentent des URI de ressources et les arcs des proprits de ces ressources. Les graphes RDF peuvent contenir des nuds vides, reprsentant des ressources anonymes (des ressources qui n'ont pas d'URI). La Figure 11 prsente un exemple de graphe RDF. Ce graphe dcrit les trois noncs illustrs par le Tableau 2.

Ici nous utilisons une PURL (Persistent Uniform Ressource Locator) qui est un identificateur permanent de resource. Il sagit dURIs qui ne dcrivent pas directement lemplacement de la resource, mais un emplacement intermdiaire permanent. Lorsque la resource est appele travers une PURL, il y a une redirection vers son emplacement actuel (PURL 2009).
Page 38

15

Figure 11.

Graphe RDF dcrivant trois noncs RDF.

Les graphes RDF sont encods suivant le format XML permettant leur traitement et transport travers le rseau. La Figure 12 prsente le fichier XML associ au graphe RDF prsent dans la Figure 11. Les descriptions de ressources sont encodes en utilisant des tiquettes XML particulires, issues du vocabulaire RDF prdfini.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Description rdf:about="http://www.gsem.fr/documents#D42305"> <dc:creator>rdf:resource="http://www.gsem.fr/auteur#ROX639" </dc:creator> </rdf:Description> <rdf:Description> rdf:about="http://www.gsem.fr/documents#D42305 <dc:title>Liste Publications Roxin</dc:title> </rdf:Description> <rdf:Description> rdf:about="http://www.gsem.fr/documents#D42305"> <dc:date>11-11-2009</dc:date> </rdf:Description> </rdf:RDF> Figure 12. Notation XML pour la description des noncs RDF.

Le langage RDF permet de formuler des noncs concernant d'autres noncs. Ce procd est appel rification (Rification 2009). La rification est particulirement intressante dans le contexte du Web smantique, puisqu'elle permet de formuler des noncs concernant des objets ayant t noncs ailleurs, en y faisant rfrence en tant que

Page 39

ressource (MCGUINESS 2004). RDF dispose des termes suivants pour le procd de rification : rdf:Statement, rdf:subject, rdf:predicate et rdf:objet. La Figure 13 illustre lusage de ces termes, travers la rification de lnonc prsent au Tableau 2.
Enc:E1 Enc:E1 Enc:E1 Enc:E1 rdf:type rdf:Statement . rdf:subject docid:D42305 . rdf:predicate dc:creator . rdf:object authid:ROX639 . Figure 13. Vocabulaire RDF pour la rification.

En rsum, le langage RDF(S) dfinit les bases de la reprsentation et du traitement des mtadonnes. Le modle de donnes RDF(S) est base de graphes. Ses concepts cls sont les ressources, les proprits et les noncs (ALESSO 2006). La syntaxe du langage RDF(S) est base sur le langage XML. Le XML permet une interoprabilit syntaxique, alors que le RDF(S) permet une interoprabilit smantique; les deux langages sont donc complmentaires. 2.2.3.2.2 L E LANGAGE OWL Au dessus des standards RDF(S), les efforts de standardisation du W3C ont produit la famille de langages OWL (Web Ontology Language). Le langage OWL est actuellement le langage le plus populaire pour la cration d'ontologies. OWL a t construit sur la base du langage RDF(S). Le langage OWL est dfini de la mme manire qu'a t dfini le langage RDF(S), mais intgre des smantiques plus riches. Une ontologie OWL est un ensemble de triplets RDF(S), utilisant le vocabulaire OWL (HERMAN 2007). Les classes et proprits fournies par RDF(S) peuvent donc tre utilises pour crer un document OWL. Toutefois, compar RDF(S), OWL permet d'exprimer des relations plus complexes et plus riches. C'est pour cette raison quOWL est beaucoup plus utilis pour le dveloppement d'ontologies. RDF(S) demeure un choix valide, mais ses limitations videntes par rapport l'OWL en font un deuxime choix . Le langage OWL est organis sous la forme de trois sous-langages avec des niveaux d'expressivit diffrents. Ces sous-langages sont (MCGUINESS 2004) : OWL Full est destin aux utilisateurs recherchant un maximum d'expressivit coupl la libert syntaxique offerte par le RDF. OWL Full est compatible avec RDF(S), la fois du point de vue smantique que syntaxique: chaque document RDF(S) est un document OWL Full. OWL DL prend en compte l'ensemble des constructions OWL, mais leur utilisation doit respecter certaines restrictions. OWL DL emploie des logiques de description (description logic) [22322_9], et c'est pour cette raison qu'il porte ce nom. OWL DL est un sous-langage dOWL Full. OWL DL restreint l'usage des constructeurs OWL et RDF. L'avantage de ce langage est de permettre un raisonnement efficace. Son dsavantage est de ne pas tre totalement compatible avec RDF. Un document RDF devra tre tendu de certains points de vue, et restreint partir d'autres points de vue, et ce afin d'tre considr comme un document OWL DL. Par contre, tout document OWL DL est un document RDF. OWL Lite restreint le langage OWL DL un ensemble limit de constructeurs, notamment en excluant les numrations de classes ou les cardinalits arbitraires. OWL DL comprend les hirarchies de classes et de proprits, ainsi que les contraintes simples, permettant de

Page 40

modliser des thsaurus ou des ontologies simples. Le principal avantage de ce langage est d'tre facile comprendre pour les utilisateurs et facile implmenter pour les programmeurs. Son dsavantage est, bien sr, son expressivit restreinte. Nous prsentons dans ce qui suit un aperu de la syntaxe OWL. 2.2.3.2.2.1 EN-TETE D'UNE ONTOLOGIE OWL Les documents OWL sont gnralement appels ontologies OWL et sont des documents RDF. Une ontologie OWL dbute gnralement avec un ensemble de dclarations de noms de domaines et inclut un ensemble de propositions concernant l'ontologie elle-mme (regroupes sous l'tiquette owl:Ontology). De telles propositions contiennent des informations de versionnage et d'ventuels commentaires. Elles peuvent indiquer si l'ontologie courante importe d'autres ontologies. Lorsqu'une ontologie O1 importe une autre ontologie O2, alors l'ensemble des dclarations constituant O2 est ajout O1. L'import d'ontologies se fait travers une dclaration de nom de domaine pointant vers l'URI rfrenant O2, de faon ce quO1 puisse utiliser le vocabulaire dO2 dans ses propres dclarations. Il est noter que les noms de domaines sont utiliss afin de limiter l'ambigit, alors que les ontologies importes fournissent des dfinitions pouvant tre utilises. Considrons le fragment d'ontologie suivant:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. <?xml version="1.0"?> <!DOCTYPE rdf:RDF [ <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> <rdf:RDF xml:base="http://www.gsem.fr/owl-schema/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <owl:Ontology rdf:about=""> <rdfs:comment>Hierarchie de profils service </rdfs:comment> <rdfs:label>Hierarchie services</rdfs:label> <owl:priorVersion rdf:resource="http://www.gsem.fr/schema/"/> <owl:imports rdf:resource="http://www.gsem.fr/auth/"/> </owl:Ontology>

A la ligne 3, nous observons la dfinition de "xsd" en tant qu'abrviation pour le vocabulaire XML Schema. Vient ensuite l'lment racine d'une ontologie OWL, savoir l'lment rdf:RDF, l'intrieur duquel sont dfinis les noms de domaine utiliss par lontologie (lignes 5 9). La valeur de l'attribut rdf:about de l'lment owl:ontology indique l'URI servant de rfrence l'ontologie. Si cette valeur est vide, comme dans l'exemple ci-dessus, l'URI de rfrence est considre comme tant l'URI de base du document. La ligne 11 dfinit un commentaire sur l'ontologie. La ligne 13 dfinit un nom plus lisible pour l'ontologie. Les lignes 14 et 15 indiquent l'URI rfrenant une version prcdente de l'ontologie. Enfin, les lignes 16 et 17 dfinissent l'import dans l'ontologie actuelle de l'ontologie rfrence par l'URI fournie dans l'lment owl:imports. Il est noter que la proprit owl:imports est transitive: si une ontologie O1 importe une ontologie

Page 41

O2 et que l'ontologie O2 importe elle aussi une ontologie O3, alors l'ontologie O1 importe aussi l'ontologie O3. 2.2.3.2.2.2 LES CLASSES OWL En OWL, les classes sont dfinies en utilisant l'lment owl:Class. Une classe peut tre dfinie comme disjointe d'une autre classe, en utilisant l'lment owl:disjointWith. L'lment owl:equivalentClass permet de dfinir une relation d'quivalence entre des classes. Il existe seulement deux classes prdfinies: la classe owl:Thing et la classe owl:Nothing. La classe owl:Thing est la classe la plus gnrale, puisque c'est la classe qui contient l'ensemble des objets (tout objet est un objet). La classe owl:Nothing est une classe vide. Pour rsumer, toute classe OWL est une sous-classe de owl:Thing et une superclasse de owl:Nothing. L'exemple de code suivant dfinit la classe "Vehicule", disjointe de la classe "Velo". La classe "Vehicule" a pour classe quivalente la classe "Voiture".
<owl:Class rdf:ID="Vehicule"> <rdfs:subClassOf rdf:resource="#MoyensDeTransport"/> </owl:Class> <owl:Class rdf:about="#Vehicule"> <owl:disjointWith rdf:resource="#Velo"/> </owl:Class> <owl:Class rdf:ID="Voiture"> <owl:equivalentClass rdf:resource="#Vehicule"/> </owl:Class>

Le Tableau 3 regroupe l'ensemble des constructeurs de classes OWL: Terme


owl:Thing owl:Nothing owl:oneOf rdfs:subClassOf <owl:Restriction> R </owl:Restriction> owl:equivalentClass owl:intersectionOf owl:unionOf owl:complementOf owl:disjointWith Tableau 3.

Thorie des ensembles

,,

Description Lensemble de tous les individus. Lensemble vide. Lensemble , , . A est un sous-ensemble de B. Lensemble des objets satisfaisant la condition R. A est gal B. A intersection B A union B Le complment de B dans U. Le complment de B dans A. A et B sont disjoints.

Constructeurs de classe du langage OWL.

2.2.3.2.2.3 LES PROPRIETES OWL Le langage OWL dfinit deux types de proprits: Les proprits objet sont des proprits reliant des objets entre eux. Le code suivant prsente un exemple d'une telle proprit. Les lments rdfs:domain et rdfs:range correspondent au Sujet et respectivement Objet d'un triplet RDF(S). La dfinition d'une proprit objet correspond donc un triplet RDF, o la proprit joue le rle de Prdicat.

Page 42

<owl:ObjectProperty rdf:ID="estEnseignePar"> <rdfs:domain rdf:ressource="#cours"/> <rdfs:range rdf:resource="#membrePersonnelEnseignant"/> </owl:ObjectProperty>

Les proprits donnes ou "data" (datatype) relient des objets des valeurs de types de donnes. L'OWL ne dfinit pas des types de donnes et ne fournit pas non plus de outils pour dfinir ces types. L'OWL utilise les types de donnes dfinis par le langage XML Schema (en utilisant de cette manire l'architecture par couches du Web smantique) (SPERBERG-MCQUENN 2008). Le code suivant illustre la dfinition d'une proprit data.
<owl:DatatypeProperty rdf:ID="age"> <rdfs:range rdf:resource= #nonNegativeInteger"/> </owl:DatatypeProperty>

"http://www.w3.org/2001/XMLSchema

Le langage OWL permet de dfinir des proprits de proprits (aussi appeles mta-proprits ou caractristiques). Ces types de proprits sont prsents dans le tableau suivant (Tableau 4): Terme
owl:TransitiveProperty owl:SymmetricProperty owl:FunctionalProperty owl:InverseFunctionalProperty owl:InverseOf Tableau 4.

Dfinition , , , , , . , , , , , , , , , , , , ,

, , , , .

, , , . ,

Vocabulaire OWL pour la dfinition de proprits.

2.2.3.2.2.4 LES INDIVIDUS OWL En OWL, les instances de classes sont appeles individus. Leur dfinition respecte les mmes rgles qu'en RDF(S). L'exemple suivant dfinit un individu de la classe "Vehicule": <rdf:Description rdf:ID="5641-XK-25" <Vehicule rdf:ID="5641-XK<rdf:type 25"/> rdf:resource="#Vehicule"/> </rdf:Description> Contrairement aux systmes de bases de donnes, ce n'est pas parce que deux URI sont diffrentes qu'elles font rfrence des individus forcment diffrents. L'OWL dfinit donc des proprits supplmentaires permettant de statuer sur l' galit entre deux concepts. Ces proprits sont listes dans le tableau suivant (Tableau 5): Nom proprit
owl:sameAs

Description Permet de dclarer deux URI faisant rfrence un mme individu. Permet de dclarer deux URI faisant rfrence des individus diffrents.

Exemple
<owl:Thing rdf:about="#Rio-deJaneiro-Brazil"> <owl:sameAs rdf:resource="#CidadeMaravilhosa" /> </owl:Thing> <owl:Thing rdf:about="#Rio-deJaneiro-Brazil"> <owl:differentFrom rdf:resource="#Rio-de-Janeiro-Peru"/> </owl:Thing>

owl:differentFrom

Page 43

owl:AllDifferent

Tableau 5.

<owl:AllDifferent> <owl:distinctMembers rdf:parseType="Collection"> <cs:City rdf:about="#Rio-dePermet de dclarer Janeiro-Brazil"/> <cs:City rdf:about="#Rio-deun ensemble d'URI Janeiro-Peru"/> toutes diffrentes. <cs:City rdf:about="#Rio-deJaneiro-Colombia"/> </owl:distinctMembers> </owl:AllDifferent> Proprits OWL permettant de statuer sur l galit entre concepts.

Les constructeurs OWL (comme owl:Class, owl:DatatypeProperty et owl:ObjectProperty) sont des spcialisations de leurs quivalents en RDF. La Figure 14 illustre les relations de classe entre ces constructeurs.

Figure 14.

Relations de classe entre les constructeurs OWL et RDF(S).

Pour rsumer, le langage OWL est le standard propos pour les ontologies Web. Ce langage a t construit au dessus du langage RDF(S). C'est pour cette raison qu'il emploie la syntaxe base de XML, utilise par le langage RDF(S). Les instances ou individus sont dfinis en utilisant les descriptions RDF et la majorit des primitives RDF sont aussi utilises. Le langage OWL supporte les smantiques et les raisonnements formels grce aux prdicats logiques et aux logiques descriptives. Ces lments permettent de dfinir des rgles entre les concepts d'une ontologie OWL. 2.2.3.2.3 A UTRES LANGAGES Il existe d'autres langages permettant la description d'ontologies. Ici, nous n'allons en donner qu'un bref aperu, car l'tude de ces langages est en dehors des objectifs de cette thse. Dans la recherche concernant les formalismes de reprsentation de la connaissance, une tendance actuelle est d'intgrer des ontologies employant des logiques descriptives (DL-style ontologies) des rgles de programmation logique (LP-style rules). Une des tentatives dans ce domaine est le langage SWRL (Semantic Web Rule Language) (HORROCKS et al. 2004) qui tend l'ensemble des axiomes OWL en incluant des rgles de Horn (Horn-like rules). L'interoprabilit avec les ontologies OWL est assure en rfrenant les concepts et proprits OWL l'intrieur des rgles SWRL. Le langage DLsafe rules (BAADER 2002) reprsente une autre tentative de mlanger les ontologies OWL et les rgles (MOTIK 2005).

Page 44

Le langage WSML (Web Service Modeling Language) (DE BRUIJN 2008) constitue la tentative la plus rcente de standardisation des langages d'ontologie pour le Web. Ce langage concerne plus particulirement l'annotation de services Web smantiques. Il s'agit en fait d'une famille de langages, chaque langage couvrant un formalisme diffrent de reprsentation de la connaissance. Les membres de cette famille sont: Le modle conceptuel WSMO (Web Service Modeling Ontology) considr en tant qu'ontologie de haut-niveau pour les services Web smantiques; Le language WSML (Web Service Modeling Language) permettant de dcrire formellement les lments dfinis dans le modle WSMO; L'environnement d'excution WSMX (Web Service Execution Model). La Figure 15 (GRIMM et al. 2007a) illustre les diffrents langages de description d'ontologies et les relations qui les relient. Puisque certains langages sont construits partir d'autres langages et sur la base de prcdents standards, cette illustration peut tre perue comme une hirarchie des langages du Web smantique. Toutefois, cette illustration ignore certains dtails de ces langages et est expressment imprcise.

Figure 15.

Relations entre les diffrents langages de description dontologies (GRIMM et al. 2007a).

Page 45

2.2.4 CONCLUSION
Dans cette partie, nous avons discut la vision du Web smantique par rapport au Web actuel. Cette analyse nous a permis d'identifier le rle fondamental jou par les mtadonnes. Nous avons ensuite dfini les ontologies comme tant un type de mtadonnes, spcifiques un domaine de connaissance donn. Deux principaux langages permettant de dfinir des ontologies, RDF(S) et OWL, ont t prsents. Pour rsumer, le Tableau 6 illustre les extensions du Web smantique par rapport au Web actuel.

Web actuel Recherche base de mots-cls Interprtable par un humain HTML/HTTP URL Ressources (pages Web, services, etc.)
Tableau 6.

Web smantique Recherche intgrant raisonnement et smantiques Interprtable par des ordinateurs XML/RDF(S)/OWL URI Ressources smantiquement annotes

Extensions du Web smantique par rapport au Web actuel.

Nous remarquons l'annotation smantique des ressources. Le modle de mtadonnes RDF et des ontologies au format OWL sont utiliss pour encoder ces smantiques. Cette annotation des ressources permet des recherches plus efficaces, souvent utilisant des raisonnements sur les concepts dfinis dans les ontologies. Dans notre cas, la recherche d'informations est synonyme de dcouverte de services. Or, l'utilisation d'annotations smantiques implique l'utilisation de standards et procds diffrents de ceux utiliss par le Web actuel. Nous allons donc nous intresser aux services Web smantiques et aux technologies sous-jacentes.

2.3 LES SERVICES WEB SEMANTIQUES


Comme nous l'avons vu dans les paragraphes prcdents, les technologies lies au Web smantique uvrent vers un Web dont le sens pourrait tre interprt par les ordinateurs. D'autre part, les technologies inhrentes aux services Web ont pour but de crer un environnement permettant aux fournisseurs de services de rendre leurs comptences accessibles sur la Toile. Pour ce faire, l'approche utilise est d' envelopper les capacits des services Web dans une interface. C'est cette interface que les utilisateurs vont rechercher (via un registre de type UDDI) et c'est avec cette interface qu'ils vont interagir (via WSDL). La vision des services Web smantiques est de combiner ces deux technologies de manire rendre possible l'interaction automatique et dynamique entre diffrents systmes logiciels (BREITMANN 2007). D'abord, nous allons nous intresser aux raisons dterminant l'existence des services Web smantiques, ainsi qu'aux principales amliorations qu'ils apportent par rapport aux services Web

Page 46

classiques. Ensuite, nous allons investiguer les approches de dveloppement de services Web smantiques, s'inspirant du Web smantique16.

2.3.1 SEMANTIQUES DES SERVICES WEB


Nous avons vu que les technologies inhrentes aux services Web dcrivent une interface standard. Ces technologies permettent de crer un service Web, mais ne suffisent pas atteindre l'interoprabilit et l'automation entre services. En effet, le standard WSDL ne permet quune spcification syntaxique des fonctionnalits d'un service Web. Le sens de ces fonctionnalits n'est pas dcrit, et donc il est impossible pour d'autres applications dutiliser cette information sans l'intervention dun humain. Ces lacunes peuvent tre combles grce aux technologies du Web smantique. Les fonctionnalits des services peuvent tre dcrites dans un langage comprhensible par un ordinateur. Les ontologies sont le chanon manquant; elles constituent des descriptions de services, pouvant tre publies, recherches, mais surtout interprtes par des ordinateurs. La vision des services Web smantiques repose sur les concepts suivants (BREITMANN 2007) : Un service Web smantique est dfini comme la ralisation d'une ou plusieurs actions par une entit, et ce pour une autre entit. Un service est dfini dans un domaine donn (transport, e-commerce, etc.); ce domaine s'appelle le domaine de valeur du service. L'entit ralisant les actions du service est appele fournisseur de service, l'autre entit tant le demandeur de service. Ces dfinitions correspondent celles des services Web. Un service Web smantique peut tre considr diffrents niveaux d'abstraction. Un service concret est la ralisation spcifique de certaines actions d'une entit pour une autre. Un service abstrait correspond un ensemble de services concrets. Les services abstraits permettent de faire rfrence des services hypothtiques, sans avoir spcifier l'ensemble des aspects les dfinissant. Une reprsentation de service pouvant tre interprte par un ordinateur est appele description de service. Diffrents formalismes ont t dfinis pour les descriptions de services. Il s'agit d'ontologies, chacune offrant des vocabulaires diffrents. Le processus de mdiation consiste traduire une description de service d'un vocabulaire un autre. Dans la suite, nous tudions les technologies permettant de crer de telles descriptions de services.

2.3.2 DESCRIPTION DES SERVICES WEB SEMANTIQUES


Plusieurs approches existent pour la description de services Web smantiques. Il s'agit principalement de soumissions de membres du W3C: WSMO (DE BRUIJN et al. 2005), OWL-S (MARTIN 2004), SWSF (BATTLE 2005) et WSDL-S (AKKIRAJU 2005). Ces propositions diffrent, tant dans le but vis, que dans l'approche de modlisation ou dans les langages utiliss pour les descriptions de services. Dans ce qui suit, nous allons donner une brve prsentation pour chaque approche, mais seule l'approche OWL-S sera dtaille.
Dautres technologies alternatives permettent de capturer les smantiques d'un service, mais leur tude est en dehors du sujet de cette thse.
Page 47
16

L'approche WSMO (Web Service Modeling Ontology) (DE BRUIJN et al. 2005) est une initiative pour crer une ontologie dcrivant les diffrents aspects en lien avec les services Web smantiques. Le but est de rsoudre le problme d'intgration de ces services. Cette approche a t dveloppe par le groupe de travail Semantic Web Services17 du cluster ESSI18. Linitiative WSMO a pour but la fourniture dune plate-forme complte pour manipuler les services Web smantiques. Cette plateforme comprend un langage de modlisation, le WSML et un environnement dexcution, le WSMX. Un modle conceptuel, lontologie WSMO, est aussi fourni. Le langage WSML est utilis pour dcrire formellement les lments dfinis dans lontologie WSMO. Le principal avantage de cette approche est le langage WSML, qui fournit des termes spcifiques aux services Web smantiques, tels que : goal, web service, interface, choreography ou capability. A la manire du langage OWL, le langage WSML possde plusieurs variantes, chacune respectant diffrents formalismes de reprsentation des connaissances. Les inconvnients de cette approche rsident dans sa relative nouveaut ; en effet, il existe peu doutils de dveloppement permettant la manipulation et la cration dontologies WSML (Web Service Modeling Language) (LAUSEN 2007). L'approche SWSF (Semantic Web Services Framework) (BATTLE 2005) est une tentative relativement rcente, dont le but est de fournir une plate-forme d'annotation de services Web smantiques. Cette approche s'est grandement inspire de travaux prcdents, notamment ceux concernant l'OWL-S et le langage PSL19 (Process Specification Language). Cette plate-forme est une proposition du Semantic Web Services Language Comittee, et a t soumise au W3C en septembre 2005. Cette approche repose sur l'ontologie SWSO (Semantic Web Service Ontology), qui peut tre vue comme une extension de l'ontologie OWL-S. La principale diffrence rside dans le fait que l'ontologie SWSO repose sur un langage plus riche du point de vue smantique par rapport l'OWL, savoir le SWSL (Semantic Web Service Language). Toutefois, contrairement aux autres approches, nous n'avons pas connaissance d'efforts d'implmentation bass sur l'approche SWSF (LAUSEN 2007). L'approche WSDL-S (Web Service Semantics) (AKKIRAJU 2005) est plutt minimaliste, en ce sens qu'elle propose une extension des descriptions WSDL traditionnelles , en utilisant des tiquettes d'annotation spcifiques. L'approche est similaire lapproche WSMO ou encore l'OWL-S, puisqu'elle prend en compte les pr-conditions et les effets d'un service. Le principal inconvnient de cette approche est d'tre indpendante de tout langage de reprsentation d'ontologie. WSDL-S ne prconise aucun formalisme pour les descriptions smantiques. Il s'agit seulement d'ajouter quelques attributs utiles aux tiquettes XML du WSDL, de manire rfrencer des annotations smantiques. L'approche OWL-S dfinit une ontologie pour l'annotation smantique des services Web. Le but d'OWL-S est de rendre possible une dcouverte, invocation, composition et excution automatiques de services Web (MARTIN 2004). Nous avons choisi de baser notre approche sur cette ontologie, car elle est suffisamment dtaille et gnrale pour permettre la description de tout service. De plus, elle reprsente aujourd'hui l'ontologie standard pour la description des proprits et fonctionnalits des services Web. Dans les paragraphes suivants, nous investiguons les concepts de haut niveau de l'ontologie OWL-S.

17 18

Voir http://www.wsmo.org Voir http://www.essi-cluster.org 19 Standardis par ISO 18269.


Page 48

2.3.3 L'APPROCHE OWL-S


OWL-S est une ontologie OWL, permettant de dcrire les diffrents aspects d'un service Web. A l'origine de cette initiative se trouve l'ontologie service DAML (DAML-S), publie pour la premire fois au mois de mai 2001. A l'poque, cela reprsentait le premier effort vers l'annotation smantique des services Web. OWL-S en est actuellement sa version 1.2 (MARTIN 2008), la premire version ayant t soumise pour acceptation au W3C en novembre 2004 (MARTIN 2004). L'approche OWL-S tient compte des recommandations actuelles du Web smantique, tout en gardant des liens avec le monde du Web traditionnel, notamment en reliant les descriptions OWL-S aux descriptions WSDL existantes. Cest aussi une des raisons qui a motiv notre choix dutiliser cette ontologie comme point de dpart de notre contribution.

Figure 16.

Concepts de base de lontologie OWL-S.

L'ontologie OWL-S dfinit le concept de "Service"20 comme tant le concept de plus haut niveau (MARTIN 2004). Le concept "Service" est utilis en tant que rfrence dans l'organisation des dclarations de services Web. Chaque service est dclar en crant une instance de ce concept. Le concept "Service" est lui-mme divis en trois sous-concepts, lists ci-dessous et illustrs par la Figure 16 (MARTIN 2004). Le concept de "Service Profile"21 reprsente une ontologie qui dcrit ce que fait le service, notamment travers ses fonctionnalits et ses proprits non-fonctionnelles. C'est ce concept qui est utilis pour rendre automatique la dcouverte des services Web. Lontologie sous-jacente est dtaille au paragraphe 2.3.3.1. Le concept de "Service Model"22 reprsente aussi une ontologie qui dcrit comment le service ralise ses fonctionnalits. Les diffrents processus constituant le service sont dcrits au paragraphe 2.3.3.2. C'est ce concept qui est utilis pour rendre automatique la composition de services Web.
20 21

http://www.daml.org/services/owl-s/1.2/Service.owl http://www.daml.org/services/owl-s/1.2/Prole.owl 22 http://www.daml.org/services/owl- s/1.2/Process.owl


Page 49

Le concept de "Service Grounding"23 est une ontologie dont les concepts dcrivent comment utiliser un service, autrement dit comment un client peut invoquer le service. Cette ontologie est utilise pour automatiser l'invocation de services Web. Elle est dtaille au paragraphe 2.3.3.3. Le concept de "Resource" reprsente le fournisseur de service. Dans le formalisme OWL-S, une Ressource fournit un ou plusieurs Services. Chacun des concepts du formalisme OWL-S dfinit une ontologie (ou un vocabulaire de termes) permettant de dcrire diffrents aspects du service. Dans ce qui suit, nous allons prsenter chacune de ces ontologies. 2.3.3.1 L' ONTOLOGIE S ERVICE P ROFILE Nous avons indiqu prcdemment que chaque service est dclar en tant qu'instance du concept "Service". Chacune de ces instances prsente (presents) zro ou plusieurs profils de service (ServiceProfile). Un profil de service exprime ce que fait le service et est utilis pour la publication du service dans un annuaire. Un profil de service est utilis en tant que modle pour les requtes de service. C'est cette description du service qui est utilise pour la dcouverte et la comparaison de services. La Figure 17 illustre les principales classes de lontologie ServiceProfile (MARTIN 2004).

Figure 17.

Classes de lontologie ServiceProfile (MARTIN 2004).

Un profil de service contient des informations relatives, la fois, aux aspects fonctionnels et nonfonctionnels du service. Les informations non-fonctionnelles comprennent notamment des rfrences vers des classifications existantes (par exemple NAICS (NAICS 2009) ou la classification de Nice (Classfication de Nice 2009) voir 4.3.1), des informations concernant le fournisseur du service et des informations concernant l'valuation qualitative du service. Dans lapproche OWL-S, le profil dun service offre une description non-fonctionnelle de ce service par rapport trois types
23

http://www.daml.org/services/owl-s/1.2/Grounding.owl
Page 50

dinformation (MARTIN 2008) : quelle entreprise ou organisation fournit le service, quelles oprations sont ralises par le service et quelles sont les caractristiques du service. La description des caractristiques du service (voir Figure 17) comprend la catgorie du service (ServiceCategory), une description textuelle (textDescription), des informations de contact et un ensemble non-restreint de paramtres service (ServiceParameters). Ces paramtres service ne font pas rfrence aux entres et sorties du service, mais concernent, par exemple, la qualit du service ou son temps de rponse. L'information la plus importante demeure toutefois la spcification des lments fonctionnels du service (ou IOPEs). Ces IOPEs reprsentent un sous-ensemble des IOPEs dfinis par la classe ServiceModel (MARTIN 2004). Les entres et sorties du service reprsentent les oprations effectues par le service. Les pr-conditions et les effets du service indiquent les changements, produits suite l'excution du service. Les entres et les sorties du service font rfrence des concepts OWL (voir 2.2.3.2.2) dcrivant les types d'instances envoyes au service et, respectivement les rponses fournies par le service. Les pr-conditions et les effets ne doivent pas respecter un format impos. Il peut s'agir d'expressions SWRL (HORROCKS et al. 2004), DRS (MCDERMOTT 2004) ou encore KIF (GENESERETH 1994). Un des problmes soulevs par cette approche est le fait de ne pas spcifier les smantiques des prconditions et effets en utilisant l'ontologie OWL-S (LAUSEN 2007). Ce sont les langages cits ci-dessus qui permettent de spcifier ces conditions. Durant le processus de dcouverte de service, les parties utilisant OWL-S doivent se mettre d'accord sur le langage utiliser pour l'expression des conditions et des comparaisons de services. 2.3.3.2 L' ONTOLOGIE S ERVICE M ODEL Un service peut tre dcrit par (described by) un modle de service, spcifiant comment le service fonctionne . Un modle de service rend possible l'invocation, la composition, ou encore la rcupration de services. Le modle de service dfinit les interactions du service en tant que processus. Ces interactions sont exprimes laide des concepts d entre , sortie , prcondition et effet du service. Ces concepts sont appels IOPEs (Inputs, Outputs, Preconditions, Effects). Pour connecter ces IOPEs un processus donn, le formalisme OWL-S dfinit les proprits : hasInput, hasOutpupt, hasPrecondition, et hasResult (voir Figure 17) (MARTIN 2004). Un processus (Process) n'est pas ncessairement un programme excuter, mais plutt une spcification des mthodes qu'un client peut utiliser pour interagir avec un service. L'approche OWLS fait la distinction entre des processus atomiques, des processus simples et des processus composs (MARTIN 2008) : Les processus atomiques (AtomicProcess) sont des oprations simples. Ces processus peuvent tre invoqus, nont pas de sous-processus, et, du point de vue du client, ils sexcutent en une tape. Etant une sous-classe de la classe Process, chaque processus atomique peut spcifier ses propres IOPEs. Lexemple suivant illustre la dfinition dun processus atomique permettant de slectionner un restaurant depuis une liste de restaurants.
<process:AtomicProcess rdf:ID=ChoixRestaurant> <process:hasInput rdf:resource=#RestaurantsDisponibles /> <process:hasOutput rdf:resource=#RestaurantChoisi />

Page 51

</process:AtomicProcess>

Les processus simples (SimpleProcess) reprsentent des vues de processus atomiques ou complexes. Ces processus ne peuvent pas tre invoqus, et sont aussi perus par le client comme sexcutant en une seule tape. Ces processus sont utiliss en tant qulments dabstraction. Un tel processus est utilis dans le cas o il reprsente le seul processus du service et lorsquil na pas de description WSDL associe. Les processus composs (CompositeProcess) sont construits partir de processus atomiques ou simples. Le formalisme OWL-S fournit des mthodes pour contrler les flux lintrieur de tels processus, mais leur tude est en dehors des objectifs de cette thse. Un processus a des rsultats et des sorties, qui peuvent tre fonction d'une condition, encore une fois exprime utilisant un langage logique tel SWRL, KIF ou DRS. Ceci amne encore le problme des smantiques de ces conditions (LAUSEN 2007). 2.3.3.3 L' ONTOLOGIE S ERVICE G ROUNDING Afin de garder un lien vers le monde des services Web, un service OWL-S supporte (supports) une implmentation (grounding) qui relie les constructions du modle de processus des spcifications dtailles des formats de messages, de protocoles, etc. L'approche OWL-S permet donc de dfinir des liens entre (MARTIN 2008) : des processus atomiques et des oprations WSDL; des entres/sorties de processus et des messages WSDL. Il est noter que mme si le langage WSDL est la seule implmentation dfinie en OWL, l'approche OWL-S n'est pas restreinte au WSDL en tant que technologie service. L'approche OWL-S propose une description de service gnrale, tout en restant extensible d'autres mcanismes d'implmentation (MARTIN 2004).

2.4 CONCLUSION
Dans ce chapitre, nous avons prsent les technologies de base concernant notre domaine de recherche. Il s'agit des principes et des technologies du Web smantiques, notamment l'architecture du Web smantiques, les ontologies, et les langages de description d'ontologies. Nous avons ensuite tudis les services Web smantiques, notamment les langages permettant leur description smantique. Nous avons justifi pourquoi notre choix de modlisation s'est port sur le langage OWL-S, et nous avons prsent les principes sous-jacents cette approche. Dans ce qui suit, nous nous intressons la dfinition des services sensibles au contexte. Nous tudions comment les technologies dcrites prcdemment peuvent tre employes pour modliser un contexte, puis pour prendre en compte ce contexte lors du processus de dcouverte de services. Le but de cette thse tant de proposer un protocole de dcouverte pour des services sensibles au contexte, nous devons dabord d'examiner les travaux existants dans ce domaine, avec leurs avantages et inconvnients.

Page 52

CHAPITRE 3. APPROCHES POUR LA DECOUVERTE DE SERVICES SENSIBLES AU CONTEXTE

Dans ce chapitre, nous prsentons une analyse des travaux existants dans le domaine de la dcouverte de services sensible au contexte. Ce chapitre introduit les concepts de service sensibles au contexte (service SC) et de dcouverte de services sensibles au contexte (dcouverte SC). Ce chapitre dfinit ce qu'est le contexte et explique comment la sensibilit au contexte peut amliorer la dcouverte de services. Sont ensuite tudies les principales approches dcrites dans la littrature pour la dcouverte SC. Ces travaux sont compars ensuite l'approche propose dans cette thse. Les points forts de notre approche seront mis en vidence par rapport aux solutions prsentes dans ce chapitre.

3.1 Services sensibles au contexte _________________________________________________ 54


3.1.1 Dfinitions du contexte _____________________________________________________________ 54 3.1.2 Modlisation du contexte ___________________________________________________________ 55 3.1.3 Services sensibles au contexte _______________________________________________________ 57

3.2 Protocoles de dcouverte de services sensibles au contexte _________________________ 59


3.2.1 Context Aware Service Discovery (CASD) _______________________________________________ 59 3.2.2 A Context- And QoS-Aware Service Discovery (ConQo) ____________________________________ 60 3.2.3 Context-Aware, Ontology-based, Semantic Service Discovery (COSS) ________________________ 62

3.3 Problmes non adresss par les approches actuelles _______________________________ 64

Page 53

3.1 SERVICES SENSIBLES AU CONTEXTE


3.1.1 DEFINITIONS DU CONTEXTE
Lorsque nous cherchons une dfinition du mot contexte , nous pensons presqu'instantanment des mots tels temps et position . Ce sont en effet deux exemples presqu'vidents de contexte. Il en existe toutefois de nombreux autres, plus ou moins intuitifs. Donner une dfinition prcise du mot contexte n'est pas une tche facile, et a t un sujet de recherche dans de nombreux domaines scientifiques (intelligence artificielle, informatique ubiquitaire, etc.) (SCHILIT 1994), (DEY 2001). Dans le cadre de cette thse, nous adoptons une des dfinitions les plus cites dans le domaine de l'informatique pervasive. Il s'agit de la dfinition donne par Abowd (ABOWD 1999) selon laquelle le contexte reprsente toute information pouvant tre utilise pour caractriser la situation d'une entit. Une entit peut tre une personne, un endroit ou un objet, qui est considr comme relevant par rapport l'interaction entre un utilisateur et une application, en incluant l'utilisateur et l'application24 . Toujours dans (ABOWD 1999), la sensibilit au contexte est dfinie comme tant une proprit d'un systme, utilisant le contexte pour fournir des informations et/ou des services pertinents par rapport l'utilisateur, o la pertinence dpend de la tche ralise par l'utilisateur25 . Plusieurs chercheurs ont tent de classifier les diffrents types de contextes pouvant tre pertinents pour un utilisateur au moment d'accder un service d'information. Dans (DEY 2001), les auteurs soulignent trois composantes importantes du contexte: Le contexte spatial o est-ce que l'utilisateur se trouve ; Le contexte social quelles sont les autres personnes qui se trouvent proximit ; Le contexte informatif quelles sont les ressources disponibles proximit. Dans (ROXIN et al. 2008a), nous avons propos une classification plus rcente des informations contextuelles. Deux principaux types d'informations contextuelles sont dfinis, tel qu'illustrs par la Figure 18: L'information contextuelle primaire, ou de base, est constitue par l'information spatiale: identit, temps et position. Ce type d'information contextuelle peut tre utilis afin d'indexer des entits. L'information contextuelle secondaire contient des aspects supplmentaires pouvant caractriser une entit. Ces informations sont classes en fonction du type de contexte auquel elles font rfrence (selon la classification donne dans (ABOWD 1999)): contexte personnel, technique, spatial, social ou encore physique.

Information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to interaction between a user and an application including the user and application themselves. (ABOWD 1999) 25 a property of a system that uses context to provide relevant information and/or service to the user, where relevancy depends on the users task. (ABOWD 1999)
Page 54

24

Figure 18.

Types dinformations contextuelles.

La Figure 18 illustre comment le type dinformations contextuelles utilises par un service en dtermine lappellation. Les services base de position utilisent seulement les informations du contexte spatial, alors que les services sensibles au contexte font usage de lensemble des informations contextuelles, tant donn la diversit d'informations contextuelles, une modlisation du contexte est ncessaire et ce afin de pouvoir dfinir et stocker les donnes dans une forme pouvant tre interprte par un ordinateur. La partie suivante prsente les diffrentes modlisations de contexte prsentes dans la littrature.

3.1.2 MODELISATION DU CONTEXTE


Les modles contextuels reposent sur diffrents types de structures de donnes. Les auteurs de (STRANG 2004) listent les principales approches de modlisation du contexte. Ce sont ces approches que nous prsentons dans les paragraphes suivants. Les modles cl/valeur reprsentent la structure la plus simple permettant de modliser un contexte. Les capacits d'un service sont modlises travers des paires du type cl/valeur . Les services sont ensuite dcouverts en effectuant des recherches sur ces paires cl/valeur . L'une des premires approches dans ce domaine a t celle de Schilit (SCHILIT 1994), qui a fait appel aux paires cl/valeur pour associer une valeur un type d'information contextuelle. Ces modles cl/valeur sont simples grer, mais ne permettent pas une structure sophistique, ncessaire l'application d'algorithmes efficaces pour le renvoi de contexte.

Page 55

Les modles utilisant des schmas de balisage utilisent une structure de donnes hirarchique, constitue d'tiquettes de balisage avec leurs attributs et contenus. Les profils constituent un exemple typique de ces modles. Ils reposent principalement sur des drives du langage XML. D'autres exemples incluent le modle capacits/prfrences CC/PP (Composite Capability/Preference Profiles) (KLYNE 2004) ou encore le modle UAProf (User Agent Profile) (UAProf 2001) Le but de lapproche CC/PP est de permettre au client dexprimer les capacits logicielles et matrielles de son terminal, ainsi que des prfrences. Le modle UAProf a pour but de crer des spcifications en vue de dvelopper des protocoles orients mobilit. Ces deux modles atteignent le mme niveau d'expressivit que pour le langage RDF(S), puisquils reposent sur le langage RDF. Dans ce domaine, une des approches les plus innovantes est celle prsente dans (HENRICKSEN et al., Generating Context Management Infrastructure from High-Level Context Models 2003) Les auteurs y dfinissent des profils contextuels comprhensibles et structurs (CSCP - Comprehensive Structure Context Profiles). Cette approche est innovante car les auteurs n'y dfinissent pas de structure hirarchique fixe. Le but est de tirer avantage de la flexibilit du langage RDF(S) afin d'exprimer les informations de profil ou contextuelles. De manire similaire, les auteurs de (INDULSKA 2003) proposent d'tendre le modle CC/PP. Leur approche, CC/PP Context Extension, permet d'tendre le vocabulaire de base des modles CC/PP et UAProf, et ce en intgrant des arbres du type composantattribut en lien avec des aspects contextuels. Les modles orients-objet utilisent les techniques de la programmation orientes-objet afin de tirer parti de leurs avantages, notamment l'encapsulation, la rutilisation des ressources ou encore l'hritage. Les approches existantes reprsentent les lments contextuels sous la forme d'objets, encapsulant ainsi les dtails relatifs au traitement et la reprsentation du contexte. Ce type de modlisation repose souvent sur un formalisme UML, textuel ou graphique. En effet, la structure de l'UML est adapte la modlisation du contexte, et, dans la littrature, il existe plusieurs approches reposant sur ce principe (HENRICKSEN et INDULSKA 2006), (GRIMM 2007). Un des exemples les plus connus de ce type de modlisation est constitu par le systme Hydrogen (HOFER 2003). Les auteurs y dfinissent le contexte en tant que modle UML, employant plusieurs classes. La Figure 19 illustre cette modlisation du contexte.

Figure 19.

Modlisation UML du contexte dans le cadre du systme Hydrogen (HOFER 2003).

Page 56

Les modles base de logique emploient des expressions et des rgles pour dfinir des modles contextuels. Une logique permet de dfinir les conditions utilises pour dduire une information partir d'un ensemble d'informations existant. Ces conditions sont dfinies dans le cadre d'un systme formel. L'information contextuelle est donc modlise de manire formelle, en utilisant des expressions ou des conditions. L'ensemble des systmes reposant sur ce type de modlisation prsente un haut degr de formalisme. (MCCARTHY 1997), (GHIDINI 2001) et (GRAY 2001) prsentent quelques exemples d'approches de modlisation appliques dans ce domaine. Leur tude est en dehors des buts poursuivis dans cette thse. Les modles base d'ontologies dfinissent le contexte en utilisant des concepts et des relations entre concepts. Les ontologies constituent une alternative trs prometteuse pour la modlisation des informations contextuelles. Elles permettent d'atteindre un haut niveau d'expressivit, mais aussi d'utiliser des techniques de raisonnement particulires. Il existe aujourd'hui plusieurs plateformes sensibles au contexte reposant sur ce type de modlisation (WANG 2004), (BROENS 2004). Dans (STRANG 2004), les auteurs valuent les approches listes ci-dessus. Ils dfinissent une liste des besoins cls, adapts aux environnements ubiquitaires, auxquels les modlisations de contexte doivent rpondre. Il s'agit, entre autres, de la richesse et la qualit de l'information, l'ambigut, le niveau de formalisme et l'applicabilit aux environnements existants. Dans leur analyse, les auteurs identifient la modlisation base d'ontologies comme l'approche la plus expressive et rpondant au plus grand nombre de besoins (STRANG 2004). En effet, le principal avantage des modles cl/valeur est leur simplicit (notamment au niveau de la gestion et du risque derreur), mais cette simplicit devient un inconvnient lorsquil sagit prendre en compte des mtadonnes ou de l'ambigut. La seule force de ce type de modlisation demeure en son applicabilit aux environnements ubiquitaires existants. Les modles reposant sur des schmas de balisage prsentent les mmes lacunes, notamment dues aux contraintes lies l'usage de l'XML et du RDF(S). Leur principal avantage est leur applicabilit dans le cadre d'infrastructures existantes et reposant sur des langages base de balises (notamment dans le domaine des services Web). Les modles orients-objet atteignent un haut niveau de formalisme, mais sont difficilement intgrables dans les environnements existants (car ils demandent beaucoup de ressources machine). Ils sont gnralement utiliss pour dcrire la structure du contexte Le niveau de formalisme atteint est encore plus haut pour les modles logiques, mais il est difficile d'envisager leur application aux terminaux mobiles d'aujourd'hui. En effet, les modles logiques ont besoin d'un raisonneur permettant de valider les informations contextuelles, or ceci est difficilement intgrable dans les terminaux mobiles actuels. Les modles base d'ontologies constituent donc l'approche la plus prometteuse pour les environnements ubiquitaires. C'est pour cette raison que l'approche prsente dans cette thse utilise des ontologies pour la modlisation des informations contextuelles (et plus particulirement le modle OWL-S). Ces informations sont utilises afin de dlivrer des services sensibles au contexte. Dans ce qui suit, nous allons dfinir ce que sont ces services, puis nous allons tudier les approches existantes permettant la dcouverte de tels services.

3.1.3 SERVICES SENSIBLES AU CONTEXTE


Nous venons de voir que les services traditionnels sont bass sur des entres explicites et ne tiennent pas compte du contexte. Si on considre un service traditionnel de type Pages Jaunes , il

Page 57

ne prend en compte que l'information saisie par l'utilisateur (par exemple un nom de restaurant). Le service retournera une liste de restaurants qui correspondent la requte de l'utilisateur (soit ils ont le mme nom, soit proposent le style de cuisine recherch). Le protocole de dcouverte sous-jacent ne prend en compte quun nombre limit dinformations dfinissant le service. Il ne prendra pas en compte le nombre de tables disponibles dans le restaurant ou encore la distance qui spare l'utilisateur du restaurant. Un service sensible au contexte peut prendre en compte ces informations et donc fournir une rponse plus adapte aux besoins de l'utilisateur. La Figure 20 schmatise les diffrences entre ces deux types de services.

Figure 20.

Services traditionnels et services sensibles au contexte.

Les services sensibles au contexte considrent la fois les entres fonctionnelles et contextuelles (ou non-fonctionnelles). La sortie d'un tel service dpend donc des informations contextuelles fournies. Ces informations sont fournies au service soit travers des fournisseurs de contexte (tel un quipement de positionnement, des capteurs, etc.), soit par l'utilisateur lui-mme (gnralement en remplissant un profil utilisateur ou un formulaire spcifique), soit par le service lui-mme (un service parking peut diffuser le nombre de places restantes dans le parking). La recherche de service confronte deux acteurs, chacun ayant un problme diffrent : le fournisseur de service essaie d'annoncer du mieux possible ses services et lutilisateur ne sait pas o trouver le service voulu. L'introduction des services sensibles au contexte ne rsoud pas le problme de la recherche de services. De plus, les mcanismes utiliss pour la dcouverte de services Web traditionnels ne permettent pas la dcouverte de services sensibles au contexte. C'est le processus de dcouverte qui doit intgrer cette sensibilit aux informations contextuelles. Ceci constitue lide matresse de notre travail de recherche. La partie suivante tudie les principaux protocoles de dcouverte utilisant des informations contextuelles.

Page 58

3.2 PROTOCOLES DE DECOUVERTE DE SERVICES SENSIBLES AU CONTEXTE


Diffrentes approches ont t proposes dans la littrature pour permettre la dcouverte de tels services et l'intgration d'informations contextuelles (CHEN et KOTZ 2000), (MITCHELL 2002), (KLYNE 2004), (SHENG 2005). Comme nous l'avons prcis plus haut, ce sont les modlisations base d'ontologies qui permettent de mieux utiliser et intgrer les informations contextuelles. Or, actuellement, il n'existe que peu darchitectures qui prennent en compte les informations contextuelles dans le processus de dcouverte de services (GRIMM 2007). La prise en compte du contexte lors du processus de dcouverte permet le dveloppement d'applications spcifiques des environnements et des conditions donns. De telles applications ne sont pas conues en vue d'tre flexibles et extensibles . Elles reposent par contre sur des infrastructures gnriques permettant l'accs aux donnes contextuelles, leur dcouverte et leur publication. Dans ce qui suit, nous prsentons les principales approches proposes pour la dcouverte de services sensibles au contexte, reposant sur une modlisation du contexte travers des ontologies. Ces approches seront tudies en fonction des aspects suivants: Modlisation du contexte comment sont modlises les informations contextuelles ; Publication de service quels mcanismes sont utiliss pour publier l'offre d'un fournisseur de services ; Dcouverte de service quels mcanismes permettent l'utilisateur de dcouvrir des services. Les paragraphes suivants tudient les rponses ces questions dans le cadre de chaque approche.

3.2.1 CONTEXT AWARE SERVICE DISCOVERY (CASD)


3.2.1.1 P RESENTATION DE L APPROCHE Dans (PAWAR 2006), les auteurs prsentent une approche dans le cadre de laquelle les informations contextuelles sont fournies par des sources de contexte. Chaque service et chaque client peuvent avoir une ou plusieurs sources de contexte. Les services et les sources de contexte sont rfrencs dans un registre services, afin d'tre dcouverts. La description d'un service contient des rfrences ses sources de contexte. La dcouverte de service est ralise par le biais du service CASD. Ce service renvoie, depuis le registre de services, une liste de services correspondant au type de service spcifi par le client dans sa requte. Les services composant cette liste sont appels services de base. Ce sont des services dcouverts en utilisant des protocoles basiques, c'est--dire des protocoles qui ne prennent pas en compte les informations contextuelles. Une fois cette liste construite, le service CASD collecte les informations contextuelles relatives aux services dans la liste, mais aussi celles qui sont relatives au client. La liste de services de base est ensuite filtre en fonction de ces informations contextuelles, et seul le service le plus adapt est retourn au client (PAWAR 2006). Le contexte est modlis travers une ontologie OWL. Les informations contextuelles des services de base sont stockes dans un graphe, appel graphe service. Ce sont les sources de contexte qui transforment les informations contextuelles de l'ontologie en graphe service (semblable un graphe
Page 59

RDF voir 2.2.3.2.1.) Pour ce faire, une source de contexte transforme les individus de l'ontologie en nuds du graphe service. Ces nuds sont relis entre eux par des arcs, reprsentant les proprits reliant les individus dans l'ontologie. 3.2.1.2 D ISCUSSION DE L APPROCHE Le Tableau 7 rsume les principales caractristiques de cette approche. Modlisation du contexte Publication de service Dcouverte de service Le contexte est modlis travers une ontologie OWL. Les informations contextuelles sont ensuite extraites sous la forme d'un graphe. Les services sont publis dans un registre de services. Le service CASD est responsable du traitement de la requte client, de la constitution de la liste de services basiques, puis du tri de cette liste en fonction des informations contextuelles fournies par les sources de contexte de chaque service.
Tableau 7. Caractristiques de lapproche CASD.

Le principal avantage de cette solution est de faciliter la conception de la dcouverte de services dans les environnements pervasifs. Il ne s'agit plus de rechercher les meilleurs services chaque changement de contexte. L'utilisateur est averti, de manire dynamique, lorsque les meilleurs services correspondant sa requte sont disponibles. Les auteurs introduisent ainsi le concept de dcouverte persistante. Le graphe modlisant la requte utilisateur est gard en mmoire. A chaque changement de contexte, l'algorithme de dcouverte s'y rfre pour dcouvrir de meilleurs services. Cette approche prsente toutefois des inconvnients importants. En effet, l'algorithme de dcouverte de services ne renvoie qu'un seul service l'utilisateur. De plus, si aucun service, correspondant la fois la requte et au contexte utilisateur, n'est disponible au moment de la requte, l'utilisateur n'obtient aucune rponse. Par contre, lorsque son contexte change, l'algorithme de dcouverte recherche de nouveaux services, mieux adapts la requte de l'utilisateur et son nouveau contexte. La dcouverte du meilleur service est conditionne par la prsence de l'utilisateur dans le meilleur contexte. Or cette approche semble incompatible avec le comportement d'un utilisateur dans un environnement pervasif. Si celui-ci cherche un restaurant l'instant t, et si le programme lui en propose un, il ne sera trs certainement pas intress d'en dcouvrir un autre lorsquil sera dj en train de djeuner.

3.2.2 A CONTEXT- AND QOS-AWARE SERVICE DISCOVERY (C ONQO)


3.2.2.1 P RESENTATION DE L APPROCHE Le protocole de dcouverte SC prsent ci-dessous est bas sur l'approche prsente dans le cadre d'un projet de recherche europen, le projet DIP (Data, Information, and Process Integration with Semantic Web Services). Le but de ce projet a t de dvelopper et d'tendre les technologies du Web smantique et des services Web, afin de produire une nouvelle infrastructure technologique pour les services Web smantiques (DIP 2004). Le projet a choisi de se baser sur l'architecture propose par le modle WSML. L'architecture ConQo emploie donc l'environnement d'excution WSMX de l'ontologie WSMO. Ce choix est justifi par le fait que l'approche WSMO intgre un environnement ncessaire la publication, la recherche et la

Page 60

dcouverte de services Web. Les descriptions de services sont bases sur le langage WSML et sont rfrences dans un registre de services Web. L'approche ConQo (BRAUN 2008) utilise des ontologies pour modliser les proprits fonctionnelles et non-fonctionnelles des services. L'ontologie WSMO est utilise en tant qu'ontologie service de haut niveau et elle reprsente la rfrence utiliser pour la modlisation des smantiques du service. D'autres ontologies, spcifiques des domaines particuliers, sont utilises afin d'exprimer les fonctionnalits d'un service, en termes de domaine de valeur d'un service. L'ide de base est de considrer que seules ces informations sont primordiales dans la dcouverte de services. En effet, le protocole de dcouverte ne prend pas en compte des informations concernant l'invocation du service, par exemple. Les services sont modliss en termes de fonctionnalits ralises et en termes de domaines de valeur, c'est--dire les domaines d'application associs chaque fonctionnalit. Ces descriptions de service sont utilises en tant qu'entre lors du processus de dcouverte. L'ide est encore une fois de comparer la description fournie par le demandeur de service celles publies par les fournisseurs de services. Ces derniers disposent d'une interface leur permettant de publier et de mettre jour les descriptions des services qu'ils offrent. Le protocole de dcouverte ainsi conu, comporte quatre phases distinctes: a. Dfinition d'un but il s'agit de rechercher dans un registre un but prdfini (exprim en WSMO) qui servira en tant que critre de recherche. La description de ce but pourra tre paracheve par l'utilisateur. Ce processus de recherche de buts prdfinis repose sur des techniques de recherche base de mots-cls dans les ontologies. b. Dcouverte de services il s'agit de comparer une description abstraite de service (autrement dit un lment but WSMO) avec des descriptions de services prsentes dans le registre (autrement dit un lment web service WSMO). Le processus de dcouverte prend en compte uniquement les fonctionnalits des services. Le protocole de dcouverte ne traite que des services abstraits. c. Dfinition/slection de service aprs la phase prcdente, un ensemble de services candidats a t construit. Dans cette phase sont pris en compte les paramtres des services, leurs interfaces. Il s'agit ici d'essayer de dfinir un service concret (avec une configuration concrte des paramtres), et ce parmi l'ensemble de candidats. Or, ce n'est pas parce que des services candidats ont t identifis qu'ils peuvent rellement tre dlivrs l'utilisateur final. En effet, il se peut que, parmi l'ensemble des services candidats, aucun service ne puisse dfinir un service concret convenant la fois au fournisseur et au demandeur de service. d. Excution du service cette phase comprend l'ensemble des tapes ncessaires l'invocation et l'excution du service concret slectionn prcdemment. 3.2.2.2 D ISCUSSION DE L APPROCHE Le Tableau 8 rsume les caractristiques de cette approche.

Page 61

Modlisation du contexte

Publication de service

Dcouverte de service

Le contexte est modlis travers une ontologie WSMO-Context. Chaque lment contextuel est classifi en l'une des deux catgories suivantes: donnes mesurables et donnes non-mesurables. Une deuxime classification verticale dfinit des donnes statiques ou dynamiques. L'ontologie WSMO-QoS contient des concepts permettant aux fournisseurs de services de spcifier des besoins spcifiques quant l'excution du service (bande passante minimum, nombre de couleurs de l'cran, etc.) Les services sont publis dans un registre de services. Chaque concept de l'ontologie WSMO-Context est utilis dans les descriptions abstraites de services, afin de formuler les offres et les besoins de services. La dcouverte de services est base sur la comparaison de descriptions abstraites de services. Suite une srie de comparaisons, les services rpondant la requte de l'utilisateur sont ordonns dans une liste. Chaque service prsent dans la liste rpond aux critres contextuels et QoS dfinis par l'utilisateur
Tableau 8. Caractristiques de lapproche ConQo.

La principale diffrence par rapport aux approches bases sur l'ontologie OWL rside dans la modlisation des services en termes de buts atteindre. De cette manire, l'utilisateur peut dfinir sa requte en parcourant un registre de buts ou alors en utilisant un masque de saisie permettant d'affiner cette spcification. Pour ce faire, l'approche ConQo repose sur des techniques de recherche et de navigation dans les ontologies, bases sur des mots-cls. L'ide est d'obtenir un but spcifi de manire abstraite, qui est ensuite utilis en tant que critre de recherche pour la dcouverte de services. Or, c'est dans cette utilisation de buts abstraits en tant que critres de recherche que rside le principal inconvnient de cette approche. Comme nous l'avons indiqu plus haut, mme si une liste de services compatibles est construite partir de la requte, rien ne garantit que ces services puissent tre invoqus et excuts. Pour l'utilisateur final, ceci reprsente un grand dsavantage, puisque le programme lui indique l'existence de services rpondant sa requte, mais ne lui indique pas lesquels sont compatibles avec son terminal mobile.

3.2.3 CONTEXT-AWARE, ONTOLOGY-BASED, SEMANTIC SERVICE DISCOVERY (COSS)


3.2.3.1 P RESENTATION DE L APPROCHE Dans (BROENS 2004), l'auteur prsente une architecture qui permet d'intgrer des informations contextuelles dans le processus de dcouverte de services smantiques. Cette approche utilise des ontologies OWL pour modliser les requtes utilisateur et les services existants. Chaque service et requte sont modliss en fonction du type de service, des sorties et des entres du service, et en fonction des attributs du service. La description d'un service et la description d'une requte sont toutes les deux des ontologies OWL, qui doivent tre compares afin de dterminer leur degr de compatibilit (voir la Figure 21).

Page 62

Figure 21.

Comparaison des proprits service aux proprits requte.

Dans l'approche dveloppe ici, l'auteur cre ses propres ontologies OWL (voir Figure 22): une ontologie modlise la structure d'un service, une autre modlise les types de services, une autre les attributs d'un service, etc. L'approche COSS repose donc sur un ensemble d'ontologies, chacune modlisant un concept participant dans le processus de dcouverte.

Figure 22.

Ontologies utilises par lapproche COSS (BROENS 2004).

3.2.3.2 D ISCUSSION DE L APPROCHE Le Tableau 9 rsume les caractristiques de cette approche.

Page 63

Modlisation du contexte Publication de service

Dcouverte de service

Le contexte est modlis travers des ontologies OWL, cres par l'auteur. Les services sont stocks dans un registre de services. Le protocole de dcouverte envoie d'abord une requte MySQL au registre de services, afin de rcuprer l'ensemble des services correspondant un type de service donn. Cette requte retourne l'ensemble des descriptions OWL des services correspondants. Ces descriptions sont fusionnes en un seul modle d'ontologie en utilisant la plate-forme Jena. Les descriptions de services contenues dans cette ontologies sont ensuite parcourues une par une, afin d'identifier les services prsentant une correspondance exacte ou approximative. Les services sont stocks dans les listes de correspondance selon l'ordre dans lequel ils ont t dcouverts.
Caractristiques de lapproche COSS.

Tableau 9.

Le choix de crer ces ontologies partir de rien se rvle tre assez limitant. En effet, seule une dizaine dattributs contextuels est dfinie et le concept de contexte utilisateur se base seulement sur les concepts de position, intervalle de temps et date. Non seulement les ontologies dfinissent un nombre restreint de concepts, mais en plus ces concepts sont exploits de manire binaire lors du processus de comparaison. Les ontologies cres par l'auteur permettent d'affirmer si un service est proximit de l'utilisateur, mais il est impossible de quantifier cette proximit. Donc lorsqu'il faudra choisir entre deux services tous les deux situs proximit de l'utilisateur, il sera impossible de dterminer lequel est le plus proche de l'utilisateur. De la mme manire, cette modlisation permet d'affirmer qu'un service dispose d'un parking, mais elle ne permet pas de statuer sur la capacit du parking ou le nombre de places disponibles sur ce parking. L'algorithme de comparaison permet seulement de diffrencier les correspondances exactes des correspondances approximatives. Une correspondance approximative entre un service et une requte signifie que le service ne prsente pas l'ensemble des entres de la requte. L'algorithme de comparaison renvoie alors une liste compose de deux parties. La premire partie (affiche en premier) est constitue des services prsentant une correspondance exacte avec la requte de l'utilisateur. La deuxime partie est constitue des services ayant des correspondances approximatives. Les services sont donc ordonns en fonction de deux niveaux de correspondance: exacte ou approximative. Le principal inconvnient de cette approche se situe donc au niveau des ontologies et au niveau du moteur de comparaison. Les ontologies limitent l'utilisateur lors de la formulation de sa requte. Par exemple, l'utilisateur peut demander les restaurants proximit (selon la dfinition), dont le prix se situe dans un des trois intervalles de prix dfinis dans l'ontologie. Il ne peut pas spcifier une autre valeur ou dfinir une distance maximale ne pas dpasser. Il ne peut pas non plus spcifier que pour lui, le critre primordial est la distance.

3.3 PROBLEMES NON ADRESSES PAR LES APPROCHES ACTUELLES


Dans ce chapitre, nous avons examin les principales rfrences prsentes dans la littrature par rapport la modlisation et la dcouverte des services sensibles au contexte. L'tude de ces approches nous a permis de dterminer un ensemble de caractristiques et techniques prendre en compte dans notre approche.

Page 64

Lors de l'tude des approches permettant de dcrire des services sensibles au contexte, nous avons identifi les modlisations base d'ontologies comme tant les plus prometteuses. L'ontologie OWLS (prsente dans 2.3.3.) tant considre comme lontologie standard pour la description des proprits et fonctionnalits des services Web, nous allons baser notre description des services sur cette modlisation. De plus, comme prcis prcdemment, elle est suffisamment dtaille et gnrale pour permettre la description de tout service, notamment des services sensibles au contexte. En tudiant les principales initiatives dans le domaine de la dcouverte de services sensibles au contexte, nous avons isol les problmes suivants: Les utilisateurs ont des difficults spcifier une requte il leur est impossible de dfinir des critres de recherche spcifiques, ou de dfinir une pondration pour un critre en particulier; Les moteurs de comparaison ne permettent pas d'ordonner les services dcouverts en fonction de leur relevance par rapport la requte initiale, ou alors en fonction de critres spcifis par l'utilisateur; Les lments contextuels sont souvent interprts de manire binaire les ontologies utilises sont souvent construites partir de zro, donc elles ne sont pas assez gnrales pour permettre une recherche prcise. Notre solution rpond ces problmes, en proposant une approche simple et efficace qui permet une recherche plus prcise. En se basant sur l'ontologie OWL-S et en l'tendant, notre solution a su tirer parti des inconvnients et des lacunes d'approches prcdentes. La partie suivante prsente les contributions de cette thse, savoir la conception dun modle de description de services et la dfinition dun protocole de dcouverte tirant parti de cette description.

Page 65

CHAPITRE 4. APPROCHE CONTEXTUELLE POUR LA DECOUVERTE DE SERVICES WEB SEMANTIQUES

Dans ce chapitre, nous allons prsenter en dtail les contributions amens par notre recherche, notamment concernant la description de services et son rle dans la dcouverte de services. Nous allons ainsi mettre en vidence le fait que les spcifications actuelles telles le WSDL, l'UDDI ou l'OWLS, supportent mal l'intgration d'lments contextuels dans la recherche de services. La partie 4.1 identifie les buts viss par les diffrents composants dune description de service. Il s'agit de prsenter comment ces buts sont raliss travers les actuels standards des services Web, tout en mettant en vidence la diffrence entre les composants fonctionnels et non-fonctionnels. La section 4.2 tudie plus en dtail les rles jous par une description de services lors du processus de dcouverte de services. Pour ce faire, nous allons souligner les diffrents types de recherches pouvant tre raliss dans un registre de services, puis nous identifions les lacunes de chaque solution. Nous discutons en dtail les avantages des descriptions smantiques et des ontologies dans la dcouverte de services, tout en identifiant l'approche OWL-S comme tant un outil prometteur, mais pas assez dtaill. La section 4.3 prsente notre extension de l'ontologie OWL-S. Notre approche repose sur la dfinition d'une description smantique des informations contextuelles associes aux services. Il s'agit de modliser la fois les informations dynamiques et statiques dfinissant le contexte d'un service. La section 4.4 dfinit l'algorithme utilis dans la dcouverte de services utilisant notre modle. Cet algorithme, ainsi que le modle de description de services dfini, constituent la base de notre protocole de dcouverte.

4.1 Rle de la description de service........................................................................................ 67


4.1.1 Composants fonctionnels et non-fonctionnels ................................................................................... 67 4.1.2 Fonctionnalits couvertes par les descriptions standard de services Web ......................................... 67

4.2 Rle de la description de service dans le processus de dcouverte ..................................... 69


4.2.1 Description smantique et dcouverte de service .............................................................................. 70 4.2.2 Limites de la description smantique avec OWL-S .............................................................................. 71

4.3 Modle de description de services sensibles au contexte avec OWL-S tendu ..................... 72
4.3.1 Cration d'une hirarchie de services ................................................................................................. 73 4.3.2 Intgration dans le modle OWL-S ...................................................................................................... 80

4.4 Protocole de dcouverte de service sensibles au contexte avec OWL-S tendu ................... 86

Page 66

4.1 ROLE DE LA DESCRIPTION DE SERVICE


Les descriptions de services visent plusieurs buts. Certains de ces buts pourvoient les humains: en effet, les descriptions de services dcrivent des attributs et des fonctionnalits du service en utilisant des termes comprhensibles par des humains. D'autres buts visent l'usage des services par les machines: les descriptions de services dcrivent l'interface service et facilitent l'excution des services Web. Gnralement, les descriptions de services visent faciliter les fonctions suivantes (MARTIN 2008) : la dcouverte, l'invocation et la composition de services Web. Dans ce qui suit, nous examinons les lments composant une description de service, ainsi que le rle quils jouent dans la dcouverte de services. Il s'agit de diffrencier les attributs fonctionnels et non-fonctionnels d'un service, tudier leur rle dans la description du service, puis de comprendre comment ces rles sont remplis par les standards actuels.

4.1.1 COMPOSANTS FONCTIONNELS ET NON-FONCTIONNELS


Les descriptions de services contiennent des lments fonctionnels et des lments nonfonctionnels. Les lments fonctionnels comprennent les informations ncessaires l'excution du service: la spcification de l'interface, les protocoles associs, ainsi que les IOPEs (voir 2.3.3.2) du service. Les lments non-fonctionnels comprennent des informations descriptives, qui ne relvent pas directement de l'excution du service. Il s'agit d'informations concernant le fournisseur du service, le cot du service, la zone gographique laquelle le service s'applique, ainsi que des descriptions abstraites telles disponible en Franais, Anglais et Allemand ou encore fournit une rsolution GPS de 3m .

4.1.2 FONCTIONNALITES COUVERTES PAR LES DESCRIPTIONS STANDARD DE SERVICES WEB


La description standard de service, comprenant la fois des lments fonctionnels et nonfonctionnels, a plusieurs niveaux d'abstraction: le langage de base commun, les interfaces, les protocoles mtier26, ainsi que les proprits et smantiques du service. Ces niveaux sont illustrs par la Figure 23 (LAUSEN 2007) et dcrits ci-dessous.

Figure 23.

Niveaux dabstraction dune description de service.

Gnralement, pour les descriptions de services, le langage commun de base est le langage XML.

26

En anglais: business protocols.


Page 67

Les interfaces sont communment dcrites en utilisant le langage WSDL. Ce niveau d'abstraction dfinit comment les utilisateurs finaux doivent interagir avec le service. Ce niveau est principalement utilis lors de l'invocation du service. Il est aussi utile lorsqu'il s'agit d'tudier la composition des services. La couche protocole mtier est utilise pour dfinir des flux de services mtiers, de manire aider la composition et la chorgraphie des services. Il s'agit de langages tels WSCL (Web Service Conversation Language), BPEL (Business Process Execution Language for Web Services) ou encore WS-CDL (Web Services Choreography Description Language) (KAVANTZAS 2004). La couche Proprits et smantiques dfinit les proprits non-fonctionnelles d'un service, telles le cot ou la qualit du service. Ces proprits sont essentielles lors du processus de dcouverte. C'est au niveau de cette couche que notre approche va intervenir. Les trois premiers niveaux d'abstraction (le langage commun de base, les interfaces et les protocoles mtier) peuvent tre vus en tant que composants fonctionnels d'une description de service. La couche Proprits et smantiques reprsente la fois le plus haut niveau d'abstraction et le seul niveau contenant des proprits non-fonctionnelles. Les standards actuels des services Web dfinissent surtout des composants fonctionnels dcrivant des interfaces. Il s'agit de standards tels SOAP (voir 2.1.2.2.2) et WSDL (voir 2.1.2.3), dont le but est de fournir des descriptions des mcanismes de transport de messages et des interfaces utilises par chaque service. Toutefois, l'approche UDDI (voir 2.1.2.5) n'est pas suffisamment flexible dans la description des composants non-fonctionnels d'un service. L'approche UDDI fournit seulement un moyen de traitement rudimentaire de ces composants, puisqu'elle ne prend en compte que des lments tels la catgorie ou le fournisseur d'un service. De manire similaire, ni le protocole SOAP, ni le protocole WSDL ne permettent la dcouverte de services Web sur la seule base de leurs fonctionnalits ou capacits (OWL-S Matchmaker 2002). Comme c'est le cas pour UDDI et WSDL, la grande majorit des composants de l'ontologie OWL-S (les ontologies ServiceModel, ServiceGrounding ou encore les IOPEs inclus dans l'ontologie ServiceProfile) concerne la dfinition des attributs fonctionnels d'un service. Toutefois, comme soulign dans la sous-section 2.3.3.1, l'ontologie ServiceProfile offre quelques fonctions primitives permettant une description non-fonctionnelle du service. Les quelques lments prdfinis (serviceName, textDescription, contactInformation et serviceCategory) offrent peu de flexibilit en plus de ce que permet l'approche UDDI. De plus, la majorit des composants non-fonctionnels d'une description de service Web sont destins aux utilisateurs humains. La plupart d'entre eux ne peuvent donc pas tre compris par une machine. Afin de rendre la dcouverte de services plus efficace et plus pertinente, ces composants nonfonctionnels doivent tre dcrits en utilisant des smantiques. Ceci permettra un ordinateur de comprendre ces informations, et donc den tirer avantage lors du processus de dcouverte. Dans notre approche, l'ensemble des lments non-fonctionnels dcrivant un service constitue le contexte de ce service. Pour dcrire le contexte d'un service de manire comprhensible pour un ordinateur, nous utilisons le standard OWL-S. Nous nous intressons l'extension de ce standard, afin de fournir plus de possibilits pour dcrire le contexte des services. Pour ce faire, nous utilisons les outils smantiques fournis par les langages OWL et RDF. Dans la suite de ce chapitre, nous

Page 68

montrons comment la smantique applique aux composants non-fonctionnels d'un service peut amliorer la dcouverte du service.

4.2 ROLE DE LA DESCRIPTION DE SERVICE DANS LE PROCESSUS DE DECOUVERTE


L'un des rles les plus importants jous par une description de service est d'tre stocke dans un registre afin de permettre la dcouverte du service. Le processus de dcouverte de services peut tre ralis: soit au moment de l'implmentation, en parcourant le registre et en identifiant les services pertinents, soit au moment de l'excution, en utilisant des techniques dattachement dynamique de la programmation oriente-objet (Dynamic binding 2009). Dans cette thse, nous nous intressons au processus de dcouverte de services initi par l'utilisateur et bas sur des composants non-fonctionnels dcrivant le service. En effet, lors de la recherche d'un service, il est peu probable que l'utilisateur puisse spcifier sa requte en utilisant des composants fonctionnels (par exemple en spcifiant des interfaces service ou des types d'entres du service). Au contraire, il est vraisemblable que l'utilisateur spcifie sa requte en utilisant des lments qualitatifs, tel qu'illustr par la Figure 24.

Figure 24.

Exemples de requtes qualitatives.

Les exemples de requtes qualitatives illustrent le fait que les services Web reprsentent non seulement des entits logicielles, mais aussi une manire d'interagir avec des occurrences de ces entits dans le monde rel (un service d'achat de places de cinma reprsente un cinma du monde rel). Notre objectif est de proposer une application permettant de spcifier des requtes service, tout en utilisant des lments non-fonctionnels dfinissant le contexte du service. De cette faon, l'utilisateur peut dfinir des requtes semblables celles prsentes par la Figure 24. Mais avant de traiter le problme de la spcification des requtes, nous allons discuter des diffrents types de recherche pouvant tre effectus sur un registre de services.

Page 69

La recherche base de mots-cls reprsente une recherche textuelle. Il s'agit de retrouver les services contenant un ou plusieurs mots-cls. Ce type de recherche est principalement utilis par les moteurs de recherche Internet. La recherche de type browsing ou survol consiste laisser l'utilisateur parcourir manuellement l'ensemble des services prsents dans un registre. L'ensemble des services parcourir peut tre rduit en utilisant des tris selon des attributs donns (par exemple en fonction du nom du fournisseur de service ou alors en fonction de la catgorie du service). La recherche base de couples attribut-valeur revient comparer les descriptions de services entre elles, sur la base d'un ensemble de couples du type attribut-valeur . La recherche base de smantiques est un mlange entre la recherche base de mots-cls et la recherche base de couples attribut-valeur . Ce type de recherche repose sur des rgles smantiques pour dterminer si un service est pertinent par rapport une requte donne. Lorsqu'il s'agit de dcouverte de service, l'approche UDDI se limite une recherche base de motscls, ou encore une comparaison de descriptions de service. L'UDDI ne supporte aucun type de traitement smantique, ce qui permettrait une comparaison flexible entre les services publis et les requtes de services (BALZER 2004). Comme prcis dans le Chapitre 2, la recherche dans un registre UDDI se rsume au parcours d'un ensemble de descriptions de services, limit un fournisseur de service ou une catgorie de service donne. tant donn un ensemble bien connu de catgories, ainsi qu'un ensemble limit de services, rduire la recherche une catgorie de service peut s'avrer suffisant pour une premire tape du processus de dcouverte. Toutefois, lorsqu'il s'agit de parcourir un grand registre, la recherche par catgorie peut se rvler soit trop limite, soit trop tendue. Une telle recherche savre tre trop limite, notamment dans le cas o plusieurs systmes de classification des services sont utiliss. Cela fait que des services similaires peuvent tre classs dans des catgories ayant des noms diffrents. Dans un tel cas, il est prfrable de rechercher un service en fonction de ses proprits, ou alors d'implmenter des rgles pouvant relier les catgories de services entre elles. De la mme manire, une recherche par catgories peut renvoyer un ensemble de services trop tendu, puisqu'une telle recherche peut retourner des services ayant la bonne catgorie, mais pas les proprits dsires. Les rsultats pertinents se perdent alors parmi les rsultats qui ne le sont pas.

4.2.1 DESCRIPTION SEMANTIQUE ET DECOUVERTE DE SERVICE


Lors de la mise au point d'une description de service, le but est de la rendre suffisamment dtaille et structure afin qu'un utilisateur n'ait pas parcourir l'ensemble des services avant de dcouvrir le service dsir. Afin de permettre une dcouverte de service oriente utilisateur qui soit plus sophistique et plus flexible, nous devons trouver l'quilibre entre la flexibilit d'une recherche adhoc base de mots-cls et la prcision d'une recherche hautement structure, comme c'est le cas pour les registres UDDI (voir 2.1.2.5). L'impact de la smantique sur le vocabulaire des descriptions de service prsente deux aspects importants, chacun affectant l'efficacit d'une recherche base d'attributs: l'aspect limitant et l'aspect largissant.

Page 70

L'aspect limitant consiste en l'utilisation d'une ontologie commune pour le vocabulaire de la description de service. L'ontologie commune permet de dfinir un contexte de service (tel que dfini plus haut), mais elle limite le vocabulaire aux seuls termes dfinis dans l'ontologie. L'usage d'une ontologie limite la recherche base d'attributs, en liminant les attributs hors contexte. L'usage d'URIs et de noms de domaine XML fournit les outils permettant d'atteindre l'aspect limitant. En effet, chaque concept est identifi de manire unique par une URI, et ce dans un domaine de travail donn (identifi par un nom de domaine XML). L'aspect largissant consiste fournir une relation entre diffrents concepts du vocabulaire. Pour un concept donn, ceci permet de dfinir des synonymes. Cet aspect largit la recherche base d'attributs en incluant dans les rsultats un ensemble spcifique de concepts lis entre eux (par exemple, en utilisant la relation d'inclusion entre les concepts de l'ontologie). L'implmentation de cet aspect largissant demande des outils plus sophistiqus permettant d'exprimer des relations entre mots-cls, ou entre concepts. Il s'agit d'outils tels les langages RDF et OWL. Afin de tirer avantage de l'expressivit du langage OWL, tout en limitant la description de service un format standard, nous choisissons de baser notre modle sur l'approche OWL-S. Dans ce qui suit, nous allons tudier les limitations du standard OWL-S, de manire mettre en vidence le besoin d'une description plus dtaille.

4.2.2 LIMITES DE LA DESCRIPTION SEMANTIQUE AVEC OWL-S


Comme dcrit plus haut (voir 2.3.3), le langage OWL-S dfinit une ontologie pour les services Web. Etant donne notre problmatique, les deux principaux avantages de ce langage, en rapport avec celle-ci, sont (MARTIN 2008) : La dcouverte automatique de services Web ceci est rendu possible par la prise en charge, travers le langage OWL-S, de requtes smantiques. L'invocation automatique de services Web ceci est rendu possible travers l'ensemble d'APIs fourni avec le langage OWL-S. Toutefois, l'ontologie OWL-S n'est pas assez dtaille. Elle contient trop d'ambigut, et manque de prcision quant certains concepts. En effet, le concept ServiceModel (voir 2.3.3.2) dcrit un processus, et ce processus possde des pr-conditions, des effets, des entres et des sorties, la manire du concept ServiceProfile (voir 2.3.3.1). Les concepts ServiceProfile et ServiceModel semblent tre des entits non-disjointes. En ralit, le concept ServiceProfile est souvent crit la main , donc ne contient pas l'intgralit des fonctionnalits du service, alors que c'est le cas pour le concept ServiceModel. Ceci s'explique par le fait que le concept ServiceProfile est surtout utilis des fins de dcouverte. C'est pour cette raison que cette classe ne contient pas l'ensemble des fonctionnalits du service, mais seulement celles qui le caractrisent. Par contre, ce manque de prcision de l'OWL-S fait que cette ontologie, dans sa version originale, ne permet pas une description rigoureuse des lments non-fonctionnels d'un service, tels sa localisation par exemple. Les principaux inconvnients du standard OWL-S sont donc les suivants: Faible degr daxiomatisation de nombreuses relations et/ou concepts pointent vers la classe owl:Thing (voir 2.2.3.2.2).

Page 71

Trop dambigut et manque de rigueur dans la dfinition de certains de ses concepts en particulier, une approche plus structure est ncessaire pour la conception et lorganisation des ontologies reposant sur le modle OWL-S. Afin de permettre un meilleur traitement et raisonnement automatiques, des liens doivent tre dfinis entre lontologie OWL-S et les ontologies de base (par exemple lontologie DOLCE (DOLCE 2006)). Ainsi, la fois les proprits fonctionnelles et non-fonctionnelles dun service pourront tre dcrites avec plus de rigueur. Les services ne sont pas associs une zone gographique donne, et peuvent tre invoqus de n'importe quel endroit il n'existe aucun concept dans l'ontologie OWL-S permettant de dfinir une zone d'action ou une zone de valabilit pour un service. Ajouter ce type d'information permet de rpondre des requtes spcifiant une zone gographique, comme par exemple Lister l'ensemble des restaurants italiens moins de 2 Km . Pas de description smantique d'informations dcrivant le contexte du service seule la proprit serviceParameters permet de dfinir une liste expansible de proprits pouvant accompagner une description de service. Pour palier ces lacunes, notre approche est d'tendre l'ontologie OWL-S afin de tirer parti des informations contextuelles d'un service lors du processus de dcouverte de services. Notre approche consiste : a. Dfinir une hirarchie de types de services; b. Dfinir une description smantique d'attributs contextuels pour chaque catgorie de services; c. Dvelopper une interface permettant de renseigner des valeurs pour ces attributs contextuels ou encore de dfinir de nouveaux attributs; d. Dvelopper une interface permettant de spcifier une requte tout en utilisant les attributs contextuels dfinis dans notre modle; e. Dfinir un algorithme permettant d'utiliser les attributs contextuels des services pour calculer un score de pertinence du service par rapport la requte de l'utilisateur. Dans ce qui suit, nous prsentons notre modle de description de services, autrement dit les amliorations apportes l'ontologie OWL-S. Ensuite, nous tudions les avantages de ce modle en rapport avec le processus de dcouverte de services.

4.3 MODELE DE DESCRIPTION DE SERVICES SENSIBLES AU CONTEXTE AVEC OWL-S ETENDU


Comme nous l'avons prcis plus haut, l'ontologie OWL-S comporte plusieurs lacunes qui ne la rendent pas adapte la prise en compte, lors du processus de dcouverte, d'informations contextuelles caractrisant le service. En vue de rendre ceci possible, notre approche se dcompose en deux phases. Dans un premier temps, il s'agit de dfinir une hirarchie de types de services. Ceci permet d'avoir des catgories de services bien distinctes, chacune tant caractrise par des proprits diffrentes. Dans un deuxime temps, il s'agit de spcifier les caractristiques ou attributs contextuels pour chaque catgorie de services. Il s'agit ensuite de spcifier comment le modle ainsi dfini et construit va tre utilis lors du processus de dcouverte de services.

Page 72

4.3.1 CREATION D'UNE HIERARCHIE DE SERVICES


4.3.1.1 C LASSIFICATIONS STANDARD DES SERVICES Comme nous l'avons expliqu plus haut, le profil d'un service est utilis pour le caractriser des fins de publication, dcouverte et slection. Les profils de services peuvent tre publis dans diffrents types de registres, dcouverts en utilisant diffrents outils et slectionns grce de multiples techniques de comparaison. L'ontologie OWL-S ne limite ou n'impose pas la manire d'utiliser les profils de service, mais cherche fournir une base pour leur construction, une base qui soit suffisamment flexible pour s'adapter aux divers contextes et mthodes d'usage de ces profils de service. Gnralement, une telle caractrisation de service doit situer le service parmi le vaste ensemble de services disponibles, que ce soit dans un domaine donn ou pas. La construction d'une hirarchie de classes, avec un hritage de proprits entre classes, est une des techniques les plus videntes qui permette ce type de positionnement des services. A l'origine, cette technique est utilise dans la conception et la programmation oriente-objet, mais les langages base de logique descriptive permettent aussi de l'appliquer. Le but est de construire une catgorisation de services semblable celle des annuaires de type Pages Jaunes , mais dont la structure serait plus formelle et supporterait des requtes plus complexes. Nous cherchons donc une caractrisation de service permettant de situer le service parmi le vaste ensemble de services disponibles, que ce soit dans un domaine donn ou pas. Plusieurs standards de classification des services, ou des taxonomies de services, existent aujourdhui. Parmi elles, nous pouvons citer: Standard Industrial Classification (SIC) - il s'agit de la classification normalise des industries, tablie par le gouvernement des tats-Unis dans les annes 1930. Ce modle utilise cinq chiffres pour identifier un service (SIC 2008) : les deux premiers chiffres dfinissent la catgorie principale du service, le troisime chiffre dfinit la catgorie industrielle, le quatrime chiffre le groupe de services, et finalement le cinquime chiffre identifie le service lui-mme. Aujourd'hui, cette classification a t remplace par le modle NAICS (North American Industry Classification System) tabli en 1997. Similaire au modle SIC, le modle NAICS est bas sur une classification des services en utilisant 6 chiffres. La classification NAICS est utilise dans le standard OWL-S. La Nomenclature Statistique des Activits conomiques (NACE) est l'quivalent europen du systme NAICS. Ce systme utilise un code form d'une lettre, d'un nombre et plusieurs chiffres (NACE 2009). La classification United Nations standard Products and Services Code (UNSPSC) (UNSPSC 2009) permet de classifier la fois les produits et les services, en visant une utilisation dans les systmes de commerce lectronique. Cre en 1998, ce systme propose des codes disponibles en plusieurs langues, dont le franais. Cette classification qui est utilise par le standard OWL-S. Il existe donc plusieurs modles de classification et le standard OWL-S utilise deux d'entre eux. Nous allons brivement expliquer comment ceci est ralis et quelles ont t les raisons motivant notre choix de crer une autre classification des services.

Page 73

4.3.1.2 C LASSIFICATIONS UTILISEES PAR LE STANDARD OWL-S Dans le standard OWL-S, c'est la classe ServiceCategory qui permet de dcrire des catgories de services sur la base d'une classification standard, telles celles listes plus haut. La proprit objet (voir 2.2.3.2.2.3) serviceCategory relie la classe ServiceProfile la classe ServiceCategory (la valeur de la proprit serviceCategory est une instance de la classe ServiceCategory). Une catgorie de services ainsi dfinie dispose des proprits donnes suivantes, telles quillustres par la Figure 25 (MARTIN 2004): categoryName cette proprit permet de dfinir le nom de la catgorie, qui peut tre soit une chane de caractres soit une URI; taxonomy cette proprit dfinit une rfrence vers un schma de taxonomie. Il peut s'agir soit de l'URI de la taxonomie, soit d'une URL vers cette taxonomie, ou encore du nom de la taxonomie; value cette proprit pointe vers une valeur dans une taxonomie donne; code cette proprit dfinit le code d'une catgorie de service, par rapport une taxonomie donne.

Figure 25.

Illustration des proprits de la classe ServiceCategory.

Par exemple, un service de collection des dchets peut tre class selon les codes NACE, en spcifiant les valeurs suivantes pour les proprits listes ci-dessus:
taxonomy = "http://ec.europa.eu/competition/mergers/cases/index/nace_all.html" value = "Treatment and disposal of non-hazardous waste" code = "E38.2.1"

Page 74

Le fait d'affecter une valeur aux proprits listes ci-dessus, cre une instance de la classe ServiceCategory, autrement dit cela dfinit une catgorie de services. Cependant, le standard OWL-S utilise principalement les classifications NAICS et UNSPSC. La classe ServiceCategory contient deux sous-classes "NAICS" et "UNSPSC", dfinies par une instanciation des proprits listes ci- dessus, comme indiqu sur la Figure 26 et la Figure 27. De plus, deux autres proprits dfinies par le standard OWL-S, serviceClassification et serviceProduct, peuvent tre utilises afin de spcifier le type d'un service et du produit concern. Ces proprits sont similaires aux proprits dcrites plus haut, mais elles diffrent au niveau des valeurs possibles. En effet, les valeurs des ces proprits sont des instances OWL, au lieu d'tre des chanes de caractres faisant rfrence des taxonomies non-OWL (MARTIN 2004) : La proprit serviceClassification dfinit un lien entre un profil de service (Profile) et une ontologie des services OWL, telle la spcification OWL de la classification NAICS. La proprit serviceProduct dfinit un lien entre un profil de service (Profile) et une ontologie de produits OWL, telle la spcification OWL de la classification UNSPSC.

Figure 26.

Classe NAICS du modle OWL-S.

Figure 27.

Classe UNSPSC du modle OWL-S.

L'ensemble de ces classes et proprits permettent en effet de classifier des services et produits existants, mais cette classification ne peut pas tre utilise lors du processus de dcouverte. En effet,

Page 75

le parcours d'une classification aussi complexe que le systme NAICS ou UNSPSC se rvle impossible, et ce pour plusieurs raisons: Le nombre de codes parcourir est norme - Un utilisateur mobile disposant d'un temps limit, ainsi que d'un terminal mobile avec une capacit de traitement limite, perdra patience avant d'avoir trouv le service recherch. Les classifications ne sont pas intuitives pour un utilisateur non-averti - ces systmes dfinissent de nombreuses catgories dont le nom n'est pas toujours vocateur pour un utilisateur quelconque. Les classifications concernent surtout des services de l'industrie - la grande majorit des catgories dfinies par les systmes cits plus haut, concernent le monde de l'industrie et de l'agriculture. Il est peu probable que des catgories telles l'industrie du poisson (code NACE 152Z) ou l'extraction d'ardoise (code NACE 141E) reprsentent des catgories de services frquemment recherches par les utilisateurs. A partir de ces quelques remarques, nous pouvons conclure quant la non-adquation de ces systmes de classification par rapport notre but initial, savoir classer les services afin de faciliter leur dcouverte. Dans ce qui suit, nous prsentons notre approche et ses avantages par rapport aux solutions existantes. 4.3.1.3 N OTRE APPROCHE Gnralement, une telle caractrisation de service doit situer le service parmi le vaste ensemble de services disponibles, que ce soit dans un domaine donn ou pas. Nous cherchons donc identifier une manire de caractriser les services, afin de pouvoir les dcouvrir parmi l'ensemble des services disponibles. Notre approche est de nous baser sur une catgorisation de services semblable celle des annuaires de type Pages Jaunes , mais dont la structure serait plus formelle et supporterait des requtes plus complexes. La construction d'une hirarchie de classes, avec un hritage de proprits entre classes, est une des techniques les plus videntes qui permette ce type de positionnement des services. A l'origine, cette technique est utilise dans la conception et la programmation oriente-objet, mais les langages base de logique descriptive permettent aussi de l'appliquer. L'ide de dfinir une hirarchie de types de services dans le standard OWL-S a t une initiative de la Coalition OWL-S (MARTIN 2008), un groupe de 14 chercheurs internationaux, travaillant dans le domaine du Web smantique. A partir de l'ontologie de base OWL-S, ils ont tendu la classe ServiceProfile, en crant une hirarchie de catgories de services. Le but recherch tait de permettre la spcification d'informations non-fonctionnelles caractrisant les services, informations qui s'avrent utiles lors du processus de dcouverte. Cette initiative a dbouch sur la cration d'une ontologie, appele ProfileHierarchy.owl et disponible en ligne27. Comme le prcisent les auteurs, cet exemple est volontairement simpliste et limit. Son but est juste d'illustrer l'hritage de proprits entre classes, ainsi que la catgorisation de deux exemples de services de commerce en ligne (e-commerce).

27

Voir http://www.ai.sri.com/daml/services/owl-s/1.2/ProfileHierarchy.owl
Page 76

En se basant sur cet exemple, nous avons dfini une classification hirarchique de profils de services plus avance et plus dtaille. Cette classification est illustre par la Figure 28. Les catgories dfinies sont les suivantes: Service ECommerce cette catgorie regroupe l'ensemble des services de vente, dans le sens gnral du terme. Les informations contextuelles d'un service E-Commerce sont la marchandise concerne (ou le produit vendre) et le type de commerce. Les diffrents types de commerce envisags donnent naissance des sous-catgories de services, chacune caractrisant un type de commerce. Ces sous-catgories dfinissent des services plus spcifiques. o Service Achat le contexte d'un tel service est dfinit par des attributs concernant le produit vendre (cot produit, garantie produit) et la livraison de ce produit (mode de livraison, cot de livraison, dure de livraison et pays concerns par la livraison). Il n'est pas ncessaire de spcifier ici le type de produit concern. En effet, cette information est dj dans les attributs d'un service ECommerce, et le service Achat hrite de cette proprit. o Service Location le contexte d'un tel service est dfini par des attributs concernant la dure de la location et les conditions de location. Il n'est pas ncessaire de spcifier ici le type de produit concern. En effet, cette information est dj dans les attributs d'un service ECommerce, et le service Location hrite de cette proprit. o Service Vente aux Enchres le contexte d'un tel service est dfinit par des attributs concernant le type de vente aux enchres (enchre ascendante ou enchre descendante), le nombre de participants la vente, le prix de dpart du produit, le prix limite et l'enchre en cours. Service Information cette catgorie regroupe les services informatifs. Les informations contextuelles d'un tel service sont la date, la source et le sujet de l'information. Il s'agit aussi de la catgorie de l'information (nationale, internationale, sciences, sport ou mto) et du type de l'information (de dernire minute, communiqu de presse, etc.) Service Urgence cette catgorie regroupe l'ensemble des services en lien avec des situations d'urgence. Il s'agit principalement des services hospitaliers, ainsi que des services de pompiers et de police. Ces services doivent permettre l'utilisateur de remonter rapidement des informations importantes pour les secours. Les informations contextuelles dfinissant cette catgorie de services sont la position de l'utilisateur et le niveau d'urgence. o Service Police les informations contextuelles dfinissant un service police concernent le type d'infraction/agression dont l'utilisateur a t victime. L'ide est de permettre l'utilisateur de pouvoir choisir dans une liste d'infractions celle dont il a t victime. Il se peut aussi que l'utilisateur ne puisse pas prciser le type d'infraction dont il a t victime. il s'agit pour lui alors de dfinir la catgorie gnrale. La classification des infractions et dlits a t construite partir de celle fournie par Jeremy Bentham, dans son Trait de lgislation civile et pnale (BENTHAM 2009). Dans ce document, plusieurs niveaux de classification sont dfinis. Dans notre approche, nous avons volontairement rduit ces niveaux, en n'en gardant que trois. Il s'agit des catgories suivantes: Crimes et dlits contre la personne , Vols/recels et Autres infractions . Chaque catgorie a un niveau d'urgence

Page 77

associ et contient plusieurs types d'infractions et/ou dlits. La Tableau 10 illustre notre classification. Niveau Urgence 1 1 1 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 Nom Niveau Urgence Autres infractions Autres infractions Autres infractions Vols / recels Vols / recels Vols / recels Vols / recels Vols / recels Vols / recels Vols / recels Vols / recels Vols / recels Crimes et dlits contre la personne Crimes et dlits contre la personne Crimes et dlits contre la personne Crimes et dlits contre la personne Crimes et dlits contre la personne Crimes et dlits contre la personne Crimes et dlits contre la personne Description Urgence Infractions lies aux stupfiants Destruction/dgradation de biens Dlits divers Vol main arme Vol avec violence sans arme feu Vol avec entre par ruse Cambriolage Vol li l'automobile Vol li aux deux roues moteur Vol la tire Vol l'talage Vol sur chantier Homicide Tentative d'homicide Coups et blessures volontaires Squestration Violation de domicile Atteinte aux murs Infractions contre la famille et l'enfant

Tableau 10.

Classification des urgences de police.

Service Hpital de la mme manire, nous avons class en trois catgories les diffrents maux dont un patient peu souffrir. tant donne la diversit de ces maux , les catgories portent le nom du niveau d'urgence. Il s'agit des catgories normal ou assez lev , lev et trs lev . Cette classification se base sur la classification clinique des malades des urgences en France (CCMU 2009). Sans tre aussi exhaustive, elle a pour but d'informer les secours sur la nature du problme dont souffre le patient. Le Tableau 11 prsente notre classification plus en dtail. Niveau Urgence 1 1 1 1 Nom Niveau Urgence Normal Normal Assez Elev Assez Elev Description Urgence Intoxication mdicamenteuse Intoxication thylique Angine Gastro-entrite simple

Page 78

1 1 1 1 2 2 2 2 2 2 2 2 3 3 3
Tableau 11.

Assez Elev Assez Elev Assez Elev Assez Elev Elev Mdical Elev Mdical Elev Chirurgical Elev Chirurgical Elev Chirurgical Elev Chirurgical Elev Chirurgical Elev Chirurgical Trs Elev Mdical Trs Elev Mdical Trs Elev Chirurgical

Otite Plaie sans suture Piqure d'insecte Accouchement Lombo-sciatique Broncho-pneumopathie Plaie suturer Entorse Fracture ferme Luxation Fracture des ctes Brlure 2me degr Douleur thoracique Crise d'asthme Fracture ouverte

Classification des urgences hpital.

Service Pompiers l'image des deux services dfinis prcdemment, les informations contextuelles du service visent aider les pompiers et secouristes dans leur intervention. Nous avons donc class les diffrentes interventions des sapeurspompiers en trois catgories d'urgence (listes ici par niveau d'urgence dcroissant): Secours la personne , Incendies et Oprations diverses . Cette classification se base sur l'dition 2008 des statistiques des services d'incendie et de secours (Pompiers 2009). Le Tableau 12 prsente le dtail de cette classification. Niveau Urgence 1 1 1 1 2 2 2 2 3 3 3 3 3 3
Tableau 12.

Nom Niveau Urgence Oprations diverses Oprations diverses Oprations diverses Oprations diverses Incendies Incendies Incendies Incendies Secours la personne Secours la personne Secours la personne Secours la personne Secours la personne Secours la personne

Description Urgence Faits d'animaux Fuite d'eau Inondation Fuite/odeur de gaz Feux d'habitations Feu de vhicules Feux de vgtations Feux sur voie publique Malaise / maladie domicile Accident sur voie / lieux publics Malaise sur voie publique Accident domicile Accident lieu de travail Accidents de circulation

Classification des urgences pompiers.

Page 79

Service Personnel cette catgorie regroupe l'ensemble des services concernant l'individu. catgorie Nous y avons class les services permettant de trouver des restaurants, des htels, des garages ou encore des centres de lavage. Les informations contextuelles sont diffrentes pour chaque service. Nous allons dtailler seulement les informations caractrisant le service e. restaurant. o Service Restaurant ce type de service est caractris par les informations contextuelles suivantes: la catgorie du restaurant (brasserie, caftria, traditionnel, etc.), le style de cuisine (cuisine africaine, europenne, asiatique, etc.), le prix du repas, le nombre de places parking disponibles et le nombre de tables disponibles. Un tel service est aussi caractris par la prsence ou non d'un accs handicaps ou d'une climatisation. o Service Divertissement cette catgorie regroupe l'ensemble des services permettant l'utilisateur de se divertir. Nous y avons class les services permettant de trouver des salles de cinma, de thtre ou de concert. Les informatio informations contextuelles de ces services concernent le type du spectacle (film, pice de thtre, concert, exposition, etc.), l'heure de dbut et l'heure de fin du spectacle, le nombre de places disponibles dans la salle, le nombre de places disponibles dans le parking, o Service Transport cette catgorie regroupe l'ensemble des services permettant l'utilisateur de se dplacer d'un point A vers un point B. Les informations contextuelles caractrisant ces services sont le point de dpart, la destination, le prix du voyage, et la dure du voyage. D'autres informations contextuelles sont dfinies pour chaque type de service. Ceci constitue donc notre hirarchie de types de services (Figure 28).

Figure 28.

Notre classification hirarchique de profils service. rarchique

Elle n'est volontairement pas exhaustive, car cela reviendrait construire une taxonomie de services, ce qui n'est pas le but de cette thse. Cette classification peut tre facilement tendue dautres domaines et/ou services. En effet, cette hirarchie est dfinie sur le principe dune ontologie, donc il es. est ais dy inclure des rfrences ou des liens vers dontologies classifiant les services. Dans la suite, nous prsentons les outils permettant de renseigner des services par rapport cette hirarchie, mais aussi d'y ajouter des catgories services qui n'existent pas encore. Mais avant cela, nous allons tudier la construction de cette hirarch par rapport au standard OWL-S. hirarchie

4.3.2 INTEGRATION DANS LE MODELE OWL-S ODELE


Nous avons mis en vidence les lacunes du modle OWL S quant la prise en compte d'informations OWL-S contextuelles caractrisant un service donn (voir 4.3.1.2). Nous avons aussi prsent notre ).

Page 80

proposition pour une hirarchie de profils service, chacun tant caractris par diffrentes informations contextuelles (voir 4.3.1.3). Dans ce qui suit, nous allons dtailler l'intgration de notre approche dans le modle OWL-S. Pour ce faire, deux tapes sont ncessaires: Dans un premier temps, il s'agit de crer les classes correspondant notre hirarchie. Ces classes sont cres en tant que sous-classes de la classe ServiceProfile, puisque chacune d'entre elles dfinit un profil de service. Ensuite, il est ncessaire de dfinir les informations contextuelles associes chaque profil de service. Nous dtaillons la ralisation de ces deux tapes dans les paragraphes suivants. 4.3.2.1 E XTENSION DE LA CLASSE S ERVICE P ROFILE L'extension de la classe ServiceProfile revient y crer des sous-classes, chacune d'entre elles correspondant un type de profil de service dfini au paragraphe 4.3.1.3. Pour ce faire, nous utilisons l'diteur Protg (Protg 2009) et sa fonction permettant de crer des hirarchies de classes. La Figure 29 illustre l'interface propose par cet diteur.

Figure 29.

Interface de lditeur Protg pour la cration de hirarchies de classes.

Il s'agit d'entrer le nom des diffrentes classes, en utilisant des tabulations pour dfinir des relations d'inclusion entre classes. La fonction prfixe permet de dfinir un prfixe pour l'ensemble des classes ainsi cres. Les caractres renseigns dans le champ "Prefix" vont prcder le nom de chaque classe. L'ensemble des classes ainsi cres sont dfinies comme tant disjointes. Cela veut dire que l'intersection entre deux classes prises au hasard est vide. En d'autres termes, un service ne peut appartenir qu' un type de profil de service. Une fois cette hirarchie de classes cre, nous dfinissons les deux proprits suivantes pour la classe Profile (classe contenant l'ensemble des classes listes plus haut):

Page 81

aAdresse chaque service est associ une adresse dans le monde rel, du type Numro, Rue, Ville, Code Postal, Pays. La proprit aAdresse est une proprit de type donnes , qui n'accepte que des chanes de caractres (voir Figure 30).
<owl:DatatypeProperty rdf:about="#aAdresse"> <rdfs:comment xml:lang="fr">Cette propriete permet de definir ladresse dun service.</rdfs:comment> <rdfs:domain rdf:resource="&Service;ServiceProfile"/> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty> Figure 30. Dfinition de la proprit aAdresse.

aTelephone chaque service est associ un numro de tlphone. De la mme manire, la proprit aTelephone est une proprit de type donnes , qui n'accepte que des chanes de caractres (voir Figure 31).
<owl:DatatypeProperty rdf:about="#aTelephone"> <rdfs:comment xml:lang="fr">Cette propriete permet de definir le numero de telephone dun service.</rdfs:comment> <rdfs:domain rdf:resource="&Service;ServiceProfile"/> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty> Figure 31. Dfinition de la proprit aTelephone.

La Figure 32 illustre lextension de la classe ServiceProfile. Nous y remarquons des catgories de services supplmentaires (par rapport celles illustres par la Figure 28). Ceci prouve la flexibilit du modle et la facilit avec laquelle de nouvelles catgories de services peuvent tre ajoutes notre hirarchie.

Figure 32.

Notre extension de la classe Profile.

Page 82

4.3.2.2 C REATION DE LA CLASSE S ERVICE C ONTEXT Une fois notre hirarchie cre, il s'agit de dfinir, pour l'ensemble des classes la constituant, les attributs contextuels qui les caractrisent. Plusieurs options s'offrent nous: Nous pouvons dfinir chaque attribut contextuel en tant que proprit donnes pour chaque profil de service. Nous pouvons dfinir ces attributs en tant qu'lments d'une classe part. Nous avons choisi la deuxime option, et ce pour les raisons suivantes: Nous avons dj tendu la classe Profile, en y crant notre hirarchie de profils. Nous ne voulons pas charger encore cette classe. Nous souhaitons pouvoir utiliser les attributs contextuels des services lors du processus de dcouverte des services. En outre, nous souhaitons pouvoir manipuler ces attributs, notamment leur associer des pondrations (indiquant leur importance dans la recherche). Or, ceci est impossible si ces attributs sont dfinis en tant que proprits donnes OWL. En effet, OWL ne permet pas de dfinir des proprits pour des proprits. Les attributs contextuels d'un service sont donc dfinis dans une classe part, que nous appelons ServiceContext.
<owl:Class rdf:about="&Service;ServiceContext"> <rdfs:subClassOf rdf:resource="&owl;Thing"/> </owl:Class>

Cette nouvelle classe contient les attributs contextuels associs aux services, classs par classes, chaque classe correspondant un profil de service. Pour ce faire, nous utilisons nouveau l'outil Protg permettant de crer une hirarchie de classes. Nous obtenons une hirarchie similaire celle cre prcdemment, tel qu'illustr par la Figure 33.

Figure 33.

Contenu de la classe ServiceContext.


Page 83

Cette nouvelle classe, ServiceContext, est relie la classe ServiceProfile par la proprit aContexte. Cette proprit objet permet d'associer une ou plusieurs informations contextuelles un profil de service. Les restrictions OWL permettent de limiter les valeurs de cette proprit une sous-classe donne de la classe ServiceContext. Une restriction de classe est dfinie en OWL en utilisant le mot-cl owl:onProperty (MCGUINESS 2004). Ainsi on spcifie quelle proprit doit tre utilise dans la dfinition de la restriction de classe. L'appartenance une restriction de classe est soumise au respect des conditions dtermines par le type de restriction (owl:allValuesFrom, owl:someValuesFrom ou owl:hasValue) et la spcification onProperty. Dans notre cas, nous utilisons la restriction owl:allValuesFrom, qui produit des restrictions de la forme l'ensemble des individus pour lesquels l'ensemble des valeurs de la proprit P appartiennent la classe C . Une telle restriction est dfinie comme suit (MCGUINESS 2004) :
[ a owl:Restriction; owl:onProperty P; owl:allValuesFrom C]

Nous utilisons donc ce type de restriction pour affirmer que l'ensemble des services de type restaurant ont des attributs contextuels appartenant la classe Service_Restaurant_Context (voir Figure 34). Nous appliquons ce type de restriction pour l'ensemble des profils service dfinis.
<owl:Class rdf:about="&Service;Service_Restaurant"> <rdfs:subClassOf rdf:resource="&Service;Service_Personnel"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="&Service;aContexte"/> <owl:allValuesFrom rdf:resource="&Service;Service_Restaurant_Context"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> Figure 34. Restriction de la proprit aContexte.

Nous avons dit vouloir pondrer les diffrents attributs d'un service lors de la formulation d'une requte. Nous voulons aussi pouvoir dfinir des valeurs pour ces attributs et avoir des indications quant l'ordre de grandeur de ces attributs. Pour ce faire, pour chaque lment de la classe ServiceContext nous dfinissons les proprits suivantes: aQuantificateur - cette proprit indique la valeur souhaite de l'attribut contextuel considr. Cette proprit est de type boolen. Lorsque la valeur de cette proprit est "VRAI", cela indique que l'on souhaite une valeur leve pour cette proprit, et vice et versa lorsqu'elle a la valeur "FAUX". Par exemple, si la proprit aQuantificateur est dfinie "VRAI" pour l'attribut contextuel PlacesParkingDisponibles, cela veut dire que pour cet attribut contextuel on souhaite avoir des valeurs leves. La valeur de cette proprit est dfinie par le fournisseur de service, au moment de la cration de la description du service.
<owl:DatatypeProperty rdf:about="&Service;aQuantificateur"> <rdfs:domain rdf:resource="&Service;ServiceContext"/> <rdfs:range rdf:resource="&xsd;boolean"/> </owl:DatatypeProperty>

Page 84

aValeur - cette proprit indique la valeur actuelle de l'attribut contextuel. Il est noter que dans la dfinition de cette proprit, nous ne spcifions pas le type de valeurs quelle peut prendre (ou rdfs:range). Ceci est ralis en utilisant les restrictions OWL, et ce pour chaque attrobut contextuel. De cette manire, il est possible de restreindre la valeur d'un attribut contextuel un type de donnes. Par exemple, pour l'attribut contextuel PlacesParkingDisponibles, la proprit aValeur peut seulement prendre des valeurs entires. C'est la restriction "aValeur only integer" qui permet cela.
<owl:DatatypeProperty rdf:about="&Service;aValeur"> <rdfs:domain rdf:resource="&Service;ServiceContext"/> </owl:DatatypeProperty>

aPonderation - cette proprit permet l'utilisateur de dfinir les attributs contextuels qui ont le plus d'importance dans sa recherche. Elle permet de dfinir une pondration, allant de 1 5 (du moins important au plus important).
<owl:DatatypeProperty rdf:about="#aPonderation"> <rdf:type rdf:resource="&owl;FunctionalProperty"/> <rdfs:domain rdf:resource="&Service;ServiceContext"/> <rdfs:range rdf:resource="&xsd;float"/> </owl:DatatypeProperty>

Une fois dfinies notre hirarchie de classes d'attributs contextuels et les proprits de ces attributs, il s'agit d'y dfinir les attributs contextuels proprement dit. Nous prenons toujours l'exemple d'un service de type restaurant. Nous avons dfini une restriction indiquant que les proprits d'un service de ce type sont contenues dans la classe Service_Restaurant_Context. Nous y dfinissons donc les attributs contextuels identifis dans la sous-section 4.3.1.3, savoir: Le nom du restarant La catgorie du restaurant plusieurs catgories de restaurants sont dfinies ici, dont restaurant brasserie, restaurant thme, restaurant traditionnel, restaurant rapide, etc. Les valeurs de la proprit aValeur de cet lment sont restreintes des chanes de caractres. Les places de parking disponibles les valeurs de la proprit aValeur de cet lment sont restreintes des entiers. Les tables disponibles les valeurs de la proprit aValeur de cet lment sont restreintes des entiers. Le style cuisine du restaurant plusieurs styles de cuisine sont dfinis ici, parmi lesquels la cuisine asiatique, la cuisine europenne ou la cuisine africaine. Les valeurs de la proprit aValeur de cet lment sont restreintes des chanes de caractres. L'accs pour personnes handicapes les valeurs de la proprit aValeur de cet lment sont restreintes des boolens. La climatisation les valeurs de la proprit aValeur de cet lment sont restreintes des boolens. Le prix du repas les valeurs de la proprit aValeur de cet lment sont restreintes des entiers. La Figure 35 illustre le rsultat final. Nous pouvons remarquer le fait que les classes CategorieRestaurant et StyleCuisine contiennent chacune un ensemble de sous-classes.

Page 85

Cette spcification des attributs contextuels dun service de restauration a lavantage de permettre la cration de requtes simples ou complexes. Si lutilisateur souhaite prciser un style de cuisine ou une catgorie de restaurant, il peut ainsi crer des requtes complexes. Par contre, il lui est aussi possible de ne pas spcifier ces attributs, et donc deffectuer des requtes plus simples.

Figure 35.

Attributs contextuels de la classe Service_Restaurant_Context.

Nous venons de spcifier et de construire notre modle tendu de description de services. Ce modle permet d'avoir des catgories de services, chacune avec des attributs contextuels diffrents. Les restrictions dfinies sur les diffrentes proprits assurent la cohrence du modle. Nous devons maintenant spcifier comment ce modle est utilis lors du processus de dcouverte.

4.4 PROTOCOLE DE DECOUVERTE DE SERVICE SENSIBLES AU CONTEXTE AVEC OWL-S


ETENDU Dans cette partie, il sagit de spcifier le protocole de dcouverte qui permet dutiliser le modle de description de service prsent ci-dessus. Nous proposons un protocole de dcouverte permettant d'ordonner les services dcouverts selon leur degr de pertinence par rapport la requte de lutilisateur. Les diffrentes tapes du processus de dcouverte sont illustres par la Figure 36.

Page 86

Figure 36.

Notre protocole de dcouverte de services sensibles au contexte.

Lors de la premire tape, lon considre la requte de l'utilisateur en tant que description du service parfait. En effet, dans sa requte l'utilisateur prcise des valeurs et des pondrations pour les attributs contextuels dfinissant un service donn. L'ensemble de ces attributs, accompagns de leurs valeurs et pondrations respectives, forme une description dfinissant le service idal recherch par l'utilisateur. Les services renseigns dans le registre seront compars cette description idale. Cette description de service est ensuite transforme sous la forme d'un tableau, rcapitulant les informations contenues dans la requte initiale. Ceci est illustr par le Tableau 13. Il s'agit de rcuprer les valeurs des proprits aQuantificateur, aPonderation et aValeur de chaque attribut contextuel dfini dans l'ontologie pour le type de service recherch par l'utilisateur. Pour rappel, les valeurs de la proprit aQuantificateur sont dfinies lors de l'enregistrement du service dans le registre (voir 4.3.2.2). Les valeurs des proprits aPonderation et aValeur sont dfinies par l'utilisateur, lors de la formulation de sa requte (voir 4.3.2.2). Attribut contextuel CategorieRestaurant Places_Parking_Disponibles Places_Tables_Disponibles PrixRepas Climatisation AccesHandicapes StyleCuisine aQuantificateur OUI OUI NON Requte utilisateur.

aPonderation 5 5 3 1 1 1

aValeur Brasserie 1 2 15 OUI -

Tableau 13.

La deuxime tape consiste obtenir une liste de services rpondant la requte utilisateur. Pour ce faire, nous renvoyons les services ayant la mme catgorie que celle dfinie par l'utilisateur dans sa requte. Par exemple, si l'utilisateur recherche un service de type restauration, seuls les services ayant cette mme catgorie seront considrs l'intrieur de cette liste de services. Si cette liste contient plus d'un lment, le Moteur Dcouverte extrait les informations contextuelles de chaque service. Si l'on considre l'exemple de requte prsent par le Tableau 13, il s'agit ici de retourner la liste des services restaurant dont la catgorie est Brasserie .

Page 87

La troisime tape vise construire, pour chaque service, un tableau contenant la valeur de chaque attribut contextuel du service. Le Tableau 14 illustre un exemple d'un tel tableau. Il n'est pas ncessaire ici de rcuprer les valeurs de la proprit aQuantificateur, car ces valeurs sont identiques celles de la requte utilisateur. En effet, ces valeurs tant dfinies lors de la cration du service par le fournisseur de service, elles sont les mmes pour un type de service donn. Il n'est pas non plus possible de rcuprer les valeurs de la proprit aPonderation, car ces valeurs sont dfinies par l'utilisateur, au moment de la requte. Les proprits aQuantificateur et aPonderation sont exclusivement utilises lors du calcul du niveau de pertinence d'un service. Elles permettent de situer un service par rapport une requte. Attribut contextuel Service_restaurant_1 aValeur CategorieRestaurant Brasserie Places_Parking_Disponibles 6 Places_Tables_Disponibles 5 PrixRepas 30 Climatisation OUI AccesHandicapes OUI StyleCuisine Tableau 14.

Service_restaurant_2 aValeur Brasserie 0 2 10 NON NON -

Valeurs des attributs contextuels de deux services.

Une fois ce tableau construit, les informations contenues dans la requte utilisateur sont compares aux informations de chaque service. Il s'agit de calculer un score pour chaque service prsent dans la liste de services construite lors de la deuxime tape. Ce score est calcul en fonction des pondrations dfinies par l'utilisateur, et en fonction des valeurs que prsente chaque service pour les diffrents attributs contextuels considrs par l'utilisateur. Pour le calcul du degr de pertinence d'un service par rapport une requte, nous dfinissons l'algorithme ci-dessous (Figure 37). L'algorithme diffre selon le type de valeur qu'un attribut contextuel peut prendre.
Si valeur boolenne Si Valeur(Service)=Valeur(Requete) -> Pondration Sinon -> (-1) Pondration Si valeur numrique Si (aQuantificateur = VRAI ET Valeur(Service)/Valeur(Requete) (aQuantificateur = FAUX ET Valeur(Service)/Valeur(Requete) 1) -> Pondration Valeur(Service)/Valeur(Requete) Sinon -> (-1) Pondration Valeur(Service)/Valeur(Requete) Si valeur ontologique Si Valeur(Service) = Valeur(Requete) -> Pondration Si Valeur(Service) subClassOf Valeur(Requete), -> Pondration/2 Figure 37.

1) OU

Algorithme pour le calcul du niveau de pertinence dun attribut service.

Le niveau de pertinence d'un service par rapport une requte est dfini comme la somme des scores du service par rapport chaque attribut contextuel. Si l'on suppose n comme tant que le nombre d'attributs contextuels pour un service donn, le score du nime attribut est Sn. Le niveau de pertinence du service est dfini par l'quation suivante:

Page 88

Par exemple, pour les services lists dans le Tableau 14, il s'agit de dterminer leur pertinence par rapport la requte initiale. Le calcul du score de chaque service est ralis en appliquant l'algorithme de la Figure 37 chacun des attributs. Pour chacun des deux services lists dans le Tableau 14, nous calculons donc leur niveau de pertinence (ou leur score) par rapport la requte utilisateur :
1 5 6 , 5 , 2,5 , 3 2 ,1 , , , ,

37,5

2 0, 5 1 , 3

, 0,67 , 1

Ceci permet de construire une liste ordonne de services, par ordre dcroissant du niveau de pertinence. Cette liste est ensuite retourne l'utilisateur, qui n'a plus qu' choisir un service. Ce protocole de dcouverte permet de toujours avoir en tte de la liste le service rpondant le mieux la requte utilisateur. L'algorithme utilis par ce protocole est dcrit dans la Tableau 15. Algorithme pour la comparaison et lordonnancement de services 1. Rception de la requte utilisateur, dfinissant le profil de service recherch SP. 2. Traitement de la requte et cration dune requte SPARQL Q 3. Excution de la requte Q, et obtention de la liste des services SR rpondant la requte. 4. Si (card(SR)>1) 4.1. Pour chaque service Si dans SR 4.1.2. Pour chaque attribut contextuel Ai(S) 4.1.2.1. Obtenir la valeur de Ai(S) 4.1.3. Construire le tableau de valeurs pour Si 4.1.4. Calculer le score de Si 4.2. Retourner la liste de services SR ordonne
Tableau 15. Algorithme pour la comparaison et lordonnancement des services.

Maintenant que nous avons prsent notre modle de description de service et notre protocole de dcouverte, nous allons tudier la ralisation d'un prototype permettant ce genre de recherche. Comme dcrit dans l'introduction, notre contribution vise proposer une interface utilisateur claire et intuitive ( la fois pour l'utilisateur final, mais aussi pour le fournisseur de services qui souhaite rfrencer un service dans le registre), ainsi qu'un moteur de dcouverte de services. Le chapitre suivant prsente l'implmentation de ces deux lments, dans le cadre de notre prototype.

Page 89

CHAPITRE 5. PRESENTATION DU PROTOTYPE

Dans ce chapitre, nous prsentons notre prototype, qui comprend une interface permettant de rfrencer un service dans un registre, une interface permettant de spcifier une requte service et un moteur dcouverte permettant une dcouverte sensible au contexte des services. L'architecture envisage est prsente en premier, puis nous dtaillons les fonctionnalits que devront supporter les deux interfaces et le moteur dcouverte.

5.1 L'architecture .................................................................................................................... 91 5.2 Les interfaces .................................................................................................................... 92


5.2.1 Interface pour la publication de service .............................................................................................. 92 5.2.2 Interface pour la requte de service ................................................................................................... 95 5.2.3 Avantages de cette approche .............................................................................................................. 96

5.3 Le moteur dcouverte ....................................................................................................... 97

Page 90

5.1 L'ARCHITECTURE
Le prototype envisag ici doit permettre la ralisation de deux principales fonctionnalits: Rfrencer un service dans le registre de services (F1) - cette premire fonctionnalit s'adresse aux fournisseurs de services. Le but est de permettre la cration de nouvelles descriptions de services, sur la base du modle dfini dans la sous-section 4.3. Nous faisons ici l'hypothse que le fournisseur de services dispose dj d'un fichier WSDL dcrivant son service. A partir de ce fichier WSDL et de notre modle, le fournisseur de services doit pouvoir crer une description de service intgrant la fois les informations contenues dans le fichier WSDL et les informations dfinissant le contexte du service. Pour ce faire, nous devons mettre au point une interface permettant la cration de telles descriptions de service et leur rfrencement dans le registre de services. Dterminer un ensemble de services rpondant une requte cre par l'utilisateur (F2) - cette fonctionnalit s'adresse l'utilisateur final. Le but est de lui permettre de crer une requte de service, puis de visualiser la liste de services rpondant cette requte. Les actions disponibles pour les services prsents dans cette liste sont dfinies dans la sous-section 5.2.2. Nous devons donc dvelopper une interface assurant ces fonctionnalits, et ce d'une manire intuitive pour l'utilisateur. Notre prototype peut donc tre dcompos en deux parties que nous appelons la partie Fournisseur de services et la partie Utilisateur final . L'architecture du prototype, ainsi que les lments le composant sont illustrs par la figure ci-dessous (Figure 38). Les deux parties impliquent une interface utilisateur. Dans les deux cas, il s'agit de formulaires dynamiques, gnrs partir d'informations contenues dans des fichiers passs en paramtre. Le formulaire Fournisseur de service permet de gnrer une description de service conforme notre modle OWL-S tendu. Le formulaire Utilisateur final permet de gnrer une requte de service, qui n'est en fait qu'une description d'un service idal, toujours en conformit avec le modle OWL-S tendu dfini plus haut. Ces deux interfaces sont dtailles dans la partie suivante de ce chapitre. Nous pouvons observer que le registre de services reprsente l'lment commun entre la partie Fournisseur de services et la partie Utilisateur final . Les descriptions de services gnres par les fournisseurs de services y sont rfrences. Le moteur de dcouverte rcupre depuis ce mme registre les services correspondant une requte donne.

Page 91

Figure 38.

Architecture de notre prototype.

Dans ce qui suit, nous tudions les principales fonctionnalits que doivent supporter les deux interfaces. Leur ralisation sera dtaille au Chapitre 6.

5.2 LES INTERFACES


Comme prcis dans l'introduction, le but ici est de crer des interfaces utilisateur claires et intuitives. Le but de ces interfaces est de rendre la publication et la requte de services aussi simples que possible du point de vue de l'utilisateur. Dans cette partie, une publication de service consiste en un document OWL-S dcrivant un service selon le modle dfini au paragraphe 4.3. Dans un tel document, le fournisseur de service dfinit des valeurs pour les proprits aQuantificateur et aValeur, de chaque attribut contextuel. Une requte de service est aussi un document OWL-S correspondant au modle dfini, mais la diffrence de la publication de service, ce document spcifie aussi la pondration des attributs contextuels (en dfinissant des valeurs pour la proprit aPonderation).

5.2.1 INTERFACE POUR LA PUBLICATION DE SERVICE


Lors de la publication d'un service par un fournisseur de service, nous avons voulu prserver la description WSDL du service, et l'encapsuler dans la description OWL-S de ce mme service. Comme dcrit dans la sous-section 2.1.2.3, le langage WSDL dcrit de manire abstraire les oprations et les messages d'un service Web. WSDL permet d'invoquer un service sans que le fournisseur de service et le client aient connaissance l'un de l'autre. Un deuxime avantage est le fait que la plupart des

Page 92

fournisseurs de services disposent d'ores et dj de descriptions WSDL pour leurs services. Le standard WSDL tant antrieur au standard OWL-S, la plupart des services Web disposent aujourd'hui d'une description WSDL. Il convient donc de tirer parti des avantages d'une description WSDL, lors de la cration de la description OWL-S. Pour ce faire, nous adoptons la dmarche suivante, illustre par la Figure 39.

Figure 39.

Etapes de la publication dune description de service.

Sont rcupres en premier les informations dcrivant le service de manire abstraite. Il s'agit de lire ces informations depuis un fichier WSDL fourni par l'utilisateur. Ces informations dfinissent des caractristiques du service, tel son nom, ses entres et sorties, etc. Deuximement, il faut lire notre modle de description de service et d'en extraire la liste des attributs contextuels dfinis pour le type de service considr. Pour chaque attribut contextuel, il faut aussi extraire le type de valeur qu'il accepte en entre. Ceci est dfini travers la proprit aValeur. Pour chaque attribut, cette proprit peut prendre des types de valeurs diffrents. Ceuxci sont spcifis dans notre modle de description de service. Une fois les attributs contextuels identifis, le fournisseur de service n'a plus qu' leur dfinir une valeur. Dans l'idal, la valeur de ces attributs contextuels peut tre dynamique (par exemple le nombre de tables disponibles) ou statique (par exemple le prix moyen d'un repas). Dans la pratique, nous avons choisi de considrer l'ensemble de ces attributs comme tant statiques. Il est aisment imaginable d'avoir des capteurs permettant de rcuprer la valeur d'attributs contextuels dynamiques, tels le nombre de places disponibles sur un parking. Notre objectif n'tant pas la collecte des informations

Page 93

contextuelles, mais bien leur traitement et utilisation, nous ne traitons pas le cas des attributs dynamiques. Une fois les informations WSDL rcupres et les valeurs des attributs contextuels dfinies, il faut gnrer une description de service OWL-S englobant l'ensemble de ces informations. Ce fichier constitue une publication de service. La Figure 40 ci-dessous illustre un exemple d'un formulaire permettant de gnrer un tel fichier.

Figure 40.

Exemple dun formulaire pour la publication de services.

Les diffrentes tapes dcrites ci-dessus sont rsums dans la figure suivante (Figure 41):

Figure 41.

Etapes du processus de publication de service.

Une fonctionnalit importante de cette interface est la possibilit, pour le fournisseur de service, de modifier notre modle en ajoutant de nouvelles catgories de services. En effet, lors du processus de rfrencement d'un service dans l'annuaire, le fournisseur de service commence par balayer la liste
Page 94

des catgories de services disponibles. Il en choisit une, l'intrieur de laquelle son service sera rfrenc. Si le fournisseur de service ne trouve pas de catgorie correspondant son service, il peut en crer une nouvelle. Dans ce cas, il devra dfinir les attributs contextuels de cette nouvelle catgorie, ainsi que le type de valeur que ces attributs peuvent prendre. Grce l'usage des ontologies, il peut mme spcifier une ontologie dfinissant la nouvelle catgorie de services. Il est aisment imaginable d'avoir rfrencer un service spcifique un domaine donn. Dans ce cas, des ontologies spcifiques ce domaine peuvent tre utilises dans la dfinition du contexte du ce service. Ce sont de telles ontologies, spcifiques un domaine, qui constituent une base de connaissances. L'implmentation de l'interface et du moteur permettant la ralisation des oprations sus mentionnes seront dtailles dans le chapitre suivant (Chapitre 6).

5.2.2 INTERFACE POUR LA REQUETE DE SERVICE


Une requte de service doit satisfaire les conditions suivantes: Une requte de service doit tre exprime de manire simple et claire. Le protocole de dcouverte ne doit pas imposer l'utilisateur la construction de requtes trop longues ou trop complexes. Par exemple, si les descriptions de services sont stockes dans une base de donnes relationnelle, il est incommode pour l'utilisateur de crer des requtes SQL complexes pour dcouvrir des services. Idalement, les utilisateurs doivent pouvoir spcifier les attributs/proprits des services travers une interface simple et intuitive. C'est au protocole de dcouverte de transformer la demande de l'utilisateur en une requte correspondant au modle de description de services. Une requte de service doit tre flexible. Elle doit permettre l'utilisateur de rechercher un service en combinant plusieurs critres. Le systme ne devra pas imposer des restrictions quant au format de la requte. Une requte de service doit utiliser des smantiques, afin d'amliorer la prcision du processus de dcouverte. Dans notre approche, l'utilisateur commence par parcourir la liste des catgories de services, telle que dfinie dans notre hirarchie de profils service (voir 4.3.1.3). Pour ce faire, le programme analyse notre modle de description de services, afin d'en extraire la liste des profils service. Lorsque l'utilisateur choisit une catgorie, le programme vrifie si cette catgorie prsente des souscatgories ou pas. Si oui, l'utilisateur le programme renvoie la liste des sous-catgories, et l'utilisateur en choisit une. Il continue ainsi jusqu' arriver une catgorie qui ne possde pas de sous-catgories. A tout moment, l'utilisateur peut arrter ce processus et passer l'tape suivante. Cela veut dire que l'utilisateur n'est pas oblig de spcifier intgralement la catgorie de service qu'il recherche. Il est possible de dfinir une catgorie spcifique (telle la catgorie Brasserie ) ou une catgorie gnrale (en prcisant seulement la catgorie de service, Restaurant par exemple). Une fois une catgorie de service spcifie, les attributs contextuels de cette catgorie sont affichs. Pour chaque attribut contextuel, l'utilisateur dispose d'un champ texte, lui permettant de saisir une valeur, ainsi que d'un slider , lui permettant de dfinir une pondration l'attribut considr. L'utilisateur valide ensuite sa requte. Ceci a pour effet de gnrer un fichier OWL-S, contenant les spcifications de l'utilisateur. La Figure 42 ci-dessous illustre les tapes de ce processus.

Page 95

Figure 42.

Etapes du processus de requte de service.

Notre approche tient compte des conditions nonces plus haut, puisqu'elle permet d'exprimer une requte de service de manire simple et intuitive. L'utilisateur effectue des slections, mais peut aussi en ignorer, ce qui rend la requte plus rapide. L'utilisation de pondrations pour les diffrents attributs contextuels permet la construction de requtes flexibles. L'ensemble du processus de requte est bas sur notre extension de l'ontologie OWL-S, ce qui permet de construire une requte de service en utilisant des smantiques.

5.2.3 AVANTAGES DE CETTE APPROCHE


Un des principaux avantages de notre approche est sa simplicit. Les interfaces dcrites plus haut sont intuitives pour l'utilisateur: Pour le fournisseur de service, notre interface lui vite d'crire une description de service la main . Pour l'utilisateur final, la construction d'une requte travers notre interface est de loin plus aise que la cration d'une requte en utilisant des langages tels XQuery (BOAG 2007), XPath (CLARK 1999) ou mme SQL (SQL 2009). De plus, notre approche est transparente: les diffrentes tapes et l'ensemble de choix que l'utilisateur doit faire refltent la structure de notre modle ontologique. Ceci a aussi une valeur ducative ou pdagogique. En effet, cela permet de rduire le temps d'apprentissage pour l'utilisateur. En outre, la hirarchie de profils service est facilement transposable dans une interface Web ou encore dans une interface d'application mobile. Cette interface peut tre affiche dans un navigateur web, un terminal mobile ou un ordinateur. Une fois les publications et requtes de service ainsi construites, elles peuvent tre utilises par le moteur dcouverte. Ceci est prsent dans le chapitre suivant.

Page 96

5.3 LE MOTEUR DECOUVERTE


Nous avons vu comment les deux interfaces Fournisseur de service et Utilisateur final permettent de crer des descriptions de services, que ce soient des publications de services ou des requtes de services. Le Moteur Dcouverte a pour principale fonction la comparaison de descriptions de services. Pour ce faire, il repose sur l'algorithme dfini dans la sous-section 4.4. La Figure 43 prsente le fonctionnement de ce moteur.

Figure 43.

Fonctionnement du Moteur Dcouverte .

Le Moteur Dcouverte ainsi que le registre de services reprsentent la partie serveur de notre prototype. Ces composants doivent en effet manipuler des fichiers d'ontologie, et cela implique l'utilisation d'outils particuliers, dont l'implmentation sur une plate-forme mobile serait trop lourde. Les dtails relatifs l'implmentation de ces composants sont donns dans le chapitre suivant.

Page 97

CHAPITRE 6. DEVELOPPEMENT ET IMPLEMENTATION DU PROTOTYPE

Ce chapitre a pour but de dtailler l'implmentation du prototype dcrit prcdemment. L'implmentation du prototype a t effectue en Java. La partie Utilisateur final (ou terminal mobile) a t dveloppe sur la base de la plate-forme Android de Google. La partie Fournisseur de service a t implmente sous la forme d'un formulaire Web. Dans un premier temps, nous tudions les dtails d'implmentation relatifs au Moteur Dcouverte . Ce moteur, tout comme l'interface Fournisseur de service , repose sur l'API Jena, qui permet de manipuler des ontologies. Dans un deuxime temps, nous examinons le dveloppement et l'implmentation des deux interfaces correspondant chacune des deux parties susmentionnes. Nous y prsentons les technologies sur lesquelles ces interfaces reposent. Il s'agit, entre autres, de prsenter les caractristiques de la plate-forme Android et de justifier pourquoi notre choix s'est port vers cette plate-forme.

6.1 La plate-forme Android _____________________________________________________ 99


6.1.1 Prsentation gnrale ______________________________________________________________ 99 6.1.2 Anatomie d'une application Android ________________________________________________ 100

6.2 Dveloppement du moteur dcouverte ________________________________________ 101


6.2.1 Les classes Java __________________________________________________________________ 103 6.2.2 L'implmentation ________________________________________________________________ 106

6.3 Dveloppement des interfaces _______________________________________________ 110


6.3.1 Interface Utilisateur final _______________________________________________________ 110 6.3.2 Interface Fournisseur de services _________________________________________________ 120

Page 98

6.1 LA PLATE-FORME ANDROID


6.1.1 PRESENTATION GENERALE
Android est un systme dexploitation lanc par Google, en 2007, qui a t conu pour fonctionner sur des plateformes mobiles, telles les Smartphones ou les PDA. Le systme est bas sur un noyau Linux et est disponible via une licence Apache version 2. Il s'agit d'une plate-forme logicielle qui n'est nible forme logicielle, pas lie un appareil donn. Au contraire, elle est voue tre intgre dans diffrents appareils mobiles, par diffrents constructeurs. Les raisons qui ont port notre choix sur cette plate forme concernent principalement sa grande plate-forme flexibilit, son accessibilit tous les intgrateurs et dveloppeurs, ainsi que le fait qu'elle fasse profiter l'utilisateur de la convergence mobile/Web. De plus, cette plate-forme es facilement forme est programmable, et Google a fourni un SDK Java, un plugin Eclipse, des mulateurs pour tests, ainsi qu'une documentation tendue. De plus, la stratgie de Google vise un grand nombre d'utilisateurs, de la mme manire que notre application. Pour rsumer, la figure suivante (Figure 44 prsente les Figure 44) avantages de cette plate-forme, du point de vue des utilisateurs et des dveloppeurs. forme,

Figure 44.

Points forts de la plate-forme Android

Ces sont ces lments qui nous ont fait choisir cette alternative. De plus, l'intgration de composants Google tels GoogleMaps, facilitent la localisation et l'accs aux services. La plate-forme Android a une architecture en couches, tel qu'illustr pa la Figure 45 ci par igure ci-dessous.

Figure 45.

Architecture Android.

Page 99

Le systme d'exploitation se situe au plus prs de la partie matrielle, et reprsente un noyau Linux 2.6 amlior par Google, aux niveaux de la gestion de l'nergie et de la communication interprocessus. La seconde couche est la couche des bibliothques, notamment la bibliothque C bionic, crite par Google spcialement pour Android et dont la taille rduite est adapte un environnement embarqu (MEIER 2009). Le runtime Android, c'est--dire la machine virtuelle Java et ses bibliothques, est situ au-dessus de la couche bibliothques. Il s'agit d'une machine virtuelle spcialement conue pour les environnements embarqus, la Dalvik Virtual Machine (MEIER 2009). La troisime couche est la couche plate-forme applicative qui contient, entre autres, la bote outils graphiques, permettant l'affichage de botes de dialogue, de menus, etc. C'est cette couche qu'il faudra accder afin de dvelopper l'interface utilisateur pour notre prototype. Ceci est ralis travers un ensemble d'APIs. La dernire couche est la couche application. Une application est reprsente par un paquet *.apk, ce qui permet une installation/dsinstallation facilites. La ralisation des interfaces sous Android est prsente dans ce qui suit.

6.1.2 ANATOMIE D'UNE APPLICATION ANDROID


Une application Android est crite en Java. Le code compil, les donnes et les fichiers ressources requis par lapplication sont packags dans un fichier archive Paquet Android ayant pour suffixe .apk . Par dfaut, chaque application a son processus Linux et chaque processus possde sa propre machine virtuelle Java. Une application Android repose sur les concepts suivants (MURPHY 2009): Le concept d' Activit (Activity) est le concept de base d'une interface utilisateur. Une activit peut tre vue en tant qu'analogie d'une fentre ou d'une bote de dialogue dans une application bureautique. C'est en utilisant des activits qu'il est possible de dfinir des interfaces graphiques permettant l'utilisateur d'interagir avec l'application. Le concept de Fournisseur de contenu (Content Provider) fournit un niveau d'abstraction pour tous types de donnes stockes sur le terminal mobile, et accessible par plusieurs applications. En effet, le modle de dveloppement Android encourage la rutilisation des donnes entre applications. La cration d'lments Fournisseurs de contenu permet de raliser ceci, tout en gardant le contrle quant au mode d'accs aux donns. Le concept d' Intention (Intent) reprsente des messages systme, s'excutant l'intrieur du terminal mobile, et notifiant les applications de divers vnements, allant de modifications hardware (insertion d'une carte SD) des vnements d'application (lancement d'une activit depuis le menu principal du terminal mobile). Dans une application Android il est non seulement possible de rpondre des intentions, mais aussi d'en crer des nouvelles. Les intentions permettent de lancer d'autres activits ou d'informer sur des situations spcifiques (par exemple, lorsque l'utilisateur se rapproche moins de 100m d'une position donne). Le concept de Services (Service) se diffrencie des autres concepts lists ci- dessus par sa dure de vie. Les activits, fournisseurs de contenu et intentions sont censs avoir une courte dure de vie et peuvent tre quitts ou ferms tout moment. Les services sont au contraire conus pour s'excuter en continu, et si ncessaire, indpendamment de toute autre activit. Il est par exemple possible d'utiliser un service pour vrifier des mises jour

Page 100

de flux RSS ou alors pour continuer jouer de la musique mme lorsque l'activit contrlant le lecteur (contrle du volume, passage au morceau suivant, etc.) n'est plus en excution. Ces concepts sont tudis plus en dtail dans la partie Prsentation des concepts Android . Pour le moment, nous nous intressons la structure d'un projet Android. Cette structure reprend une structure d'arbre, comme c'est le cas pour un projet Java. Lors de la cration d'un nouveau projet Android, plusieurs lments sont prsents la racine du projet (MURPHY 2009). Le rpertoire /bin/notreapp-debug.apk ou /bin/notreapp-unsigned.apk constitue la vritable application Android.

Figure 46.

Elments dune application Android.

Le fichier .apk est une archive ZIP contenant un fichier .dex, qui est le rsultat de la compilation des ressources (resources.arsc), des ressources non-compiles (contenues dans le rpertoire /res/raw/) et du fichier AndroidManifest.xml. Ce dernier fichier reprsente la base d'une application Android. C'est l'intrieur de ce fichier qu'il faut dclarer les lments composant notre application (les activits, les services, les intentions, etc.). Il faut aussi y dclarer comment ces lments interagissent entre eux et comment ces lments sont attachs au systme Android en gnral. Il s'agit par exemple de spcifier quelles activits doivent apparatre sur le menu principal du terminal mobile. La Figure 46 ci-dessus illustre les lments entrant dans la composition d'une application Android.

6.2 DEVELOPPEMENT DU MOTEUR DECOUVERTE


Ayant prsent les principes de dveloppement Android, nous nous intressons maintenant au dveloppement du Moteur Dcouverte . Comme indiqu prcdemment, le Moteur Dcouverte a pour but de comparer la requte utilisateur aux descriptions de services prsentes dans le registre. Cela revient comparer des fichiers ontologies entre eux. Pour cette premire implmentation de notre prototype, nous avons choisi d'utiliser l'API Jena (Jena 2009). Notre choix a t principalement motiv par la gratuit de cette API, mais aussi par le fait qu'elle repose sur le langage Java (tout comme la plate-forme Android).

Page 101

L'API Jena permet la cration, la gestion et la manipulation des ontologies travers les graphes RDF. Tel que prcis dans la sous-section 2.2.3.2.2, toute ontologie OWL est une ontologie RDF. Les formalismes OWL utiliss dans notre modle de description de services sont construits au dessus du langage RDF et peuvent tre manipuls grce cette API (Jena 2009). Jena permet, entre autres, de rcuprer les URIs des classes et des proprits dfinies dans notre modle. Nous utilisons donc cette API afin d'extraire les informations ncessaires des fichiers dcrivant la requte utilisateur et les diffrents services, afin de les comparer entre eux. Or, les outils ncessaires pour la comparaison d'ontologies ne sont pas adapts une plate-forme mobile, telle la plate-forme Android. Nous avons donc dvelopp une couche logicielle qui fournit un ensemble de mthodes pour la partie interface. De cette faon, la partie utilisateur final (ou terminal utilisateur ) de l'application ne manipule pas directement le concept d'ontologie. L'interface utilisateur emploie seulement des chanes de caractres et des URIs. De cette manire, le concept d'ontologie est transparent pour les dveloppeurs d'interfaces. Nous avons donc implment l'architecture suivante (Figure 47):

Figure 47.

Architecture du Moteur Dcouverte .

Nous prsentons les dtails relatifs la conception de ces classes dans les paragraphes suivants.

Page 102

6.2.1 LES CLASSES JAVA


La Figure 48 illustre le diagramme des classes implmentes. Pour plus de simplicit, la classe OwlServer n'est pas reprsente sur cette figure.

Figure 48.

Diagramme des classes du Moteur Dcouverte .

Comme indiqu par la Figure 48, les classes OwlLoader et OwlInterfacer hritent de la classe OwlTools. Cette classe contient les mthodes ncessaires la manipulation des ontologies. Les mthodes de cette classe sont dtailles dans le Tableau 16. Nom classe
private OntModel inputModel public OntModel getInputModel() private OntModel OutpoutModel public OntModel getOutputModel() public OwlUtils(String inputFileName) public void listAllClass() public Vector<String> getSubClassAsString(String uri) public Vector<OntClass> getSubClass(String uri) public void

Description / Rle Rfrence le modle d'entre Jena (autrement dit le fichier *.owl pass en entre). Permet d'accder l'inputModel. Rfrence le modle de sortie Jena (autrement dit le fichier *.owl gnr). Permet d'accder l'outputModel. Constructeur de la classe, auquel il faut passer en paramtre le fichier *.owl reprsentant la requte utilisateur. Liste l'ensemble des classes du modle. Renvoie, sous la forme d'un vecteur, l'ensemble des sous-classes d'une classe dont l'URI est passe en paramtre. Renvoie, sous la forme d'un vecteur, l'ensemble des sous-classes d'une classe dont l'URI est passe en paramtre. Affiche, sous forme d'arbre, l'ensemble des sous-

Page 103

displayTheServiceTree_recursive(S tring rootURI) public OntClass getOntology(String uri) public OntProperty getOntologyProperty(String uriOntClass,String uriProperty) public LinkedList<OntProperty> getOntologyProperties(String uri) public LinkedList<String> getOntologyPropertiesAsString(Str ing uri) public void getDescription(String uri) public String getOntologyPropertyValue(String ontClass, String field) public void setOntologyPropertyValue(String uri, String field, String value) public String getContext(String uri)

classes d'une classe dont l'URI est passe en paramtre. Renvoie l'OntClass asscoie l'URI passe en paramtre. Renvoie l'OntProperty associe aux URI passes en paramtre. Renvoie l'ensemble des proprits d'une classe ou d'une ontologie, dont l'URI est passe en paramtre. Renvoie une liste chane d'URIs de proprits. Affiche la description d'une classe, dont l'URI est passe en paramtre. Renvoie une chane de caractres reprsentant la valeur d'une proprit, dont le nom est pass en paramtre. Permet de dfinir la valeur d'une proprit. Cette mthode permet de renvoyer le contexte d'un profil de service, dont l'URI est passe en paramtre. Cette mthode renvoie, sous la forme d'une liste chane, l'ensemble des informations contextuelles pouvant tre modifies par l'utilisateur lors de la recherche de services. Permet de dfinir une valeur pour la proprit aQuantificateur d'une classe dont l'URI est passe en paramtre. Permet de dfinir une valeur pour la proprit aPondration d'une classe dont l'URI est passe en paramtre. Permet de dfinir une valeur pour la proprit aValeur d'une classe dont l'URI est passe en paramtre.

public LinkedList<String> UserRequestCriteria(String uri) public void setAQuantificateur(String userURI, String uri, String value) public void setAPonderation(String userURI,String uri, String value) public void setAValeur(String userURI,String uri, String value)

protected void copyOntClass(OntModel Permet de copier une ontClass d'un modle fromModel,OntModel toModel,String un autre. uri, String rootUri) protected void Gnre un fichier *.owl, vers une adresse passe generateUserRequestOwl(String en paramtre. uri, String ouputPath) Tableau 16. Liste des mthodes de la classe OwlTools.

La classe OwlInterfacer hrite de la classe OwlTools. Cette classe est utilise lors de la cration de l'interface utilisateur, pour la plate-forme Android (voir 6.3.1). Les mthodes fournies par cette classe sont dtailles dans le Tableau 17.

Page 104

Nom classe
public OwlInterfacer(String inputFile) public Vector<String> getSubClassAsString(String uri)

public LinkedList<String> UserRequestCriteria(String uriServiceChosenByUser)

Description / Rle Constructeur de la classe, auquel il faut passer en paramtre le fichier *.owl reprsentant notre modle de description de service. Renvoie, sous la forme d'un vecteur, l'ensemble des sous-classes d'une classe dont l'URI est passe en paramtre. Renvoie, sous la forme d'une liste chane, les informations contextuelles paramtrables par l'utilisateur, dans sa requte. Elle reoit en paramtre l'URI du type de service choisi par l'utilisateur.

public void Permet d'affecter le triplet de valeurs utiles setCriteriaToSubClass(String <aPonderation, aQuantificateur, uriServiceChosenByUser,String subClassUri, String aValeur> pour une proprit dont l'URI est aPondValue,String passe en paramtre. aQuantiValue,String aValeurValue) public void generateUserRequestOwl(String Gnre le fichier *.owl correspondant la uriServiceChosenByUser, String requte utilisateur. ouputPath) Tableau 17. Liste des mthodes de la classe OwlInterfacer.

La classe OwlLoader permet de communiquer avec le registre de services. Elle permet de rcuprer les descriptions de services correspondant aux critres dfinis par l'utilisateur dans sa requte, puis d'en extraire les valeurs des diffrentes informations contextuelles (sous la forme d'un vecteur). Les mthodes de cette classe sont dtailles dans le Tableau 18. Nom classe
public OwlLoader(String path, String servicePath)

public void getCriteriaLoad()

Description / Rle Constructeur de la classe, auquel il faut passer en paramtre l'adresse du fichier *.owl reprsentant la requte utilisateur. Permet de rcuprer les valeurs et pondrations des diffrentes informations contextuelles prsentes dans la requte utilisateur. Cette fonction est utilise par le constructeur de la classe. Il s'agit de la requte SPARQL adresse au registre de services. Cette mthode permet de rcuprer les services dont le nom de la catgorie est pass en paramtre.

public ResultSet getService(String serviceName)

Tableau 18.

Liste des mthodes de la classe OwlLoader.

La classe SimpleEngine contient l'algorithme de comparaison. Elle contient le cur du moteur de dcouverte. Les mthodes de cette classe sont dtailles dans le Tableau 19.

Page 105

Nom classe
public SimpleEngine() public void loadEngine(String path,String servicePath)

Description / Rle Constructeur de la classe. Permet de lancer le moteur dcouverte, en lui passant l'adresse du fichier requte utilisateur, ainsi que l'adresse du service auquel il faut la comparer. Calcule le niveau de pertinence d'un service. Implmente l'algorithme de comparaison dfini au paragraphe 4.4. Cette mthode parcourt la liste des services chargs par le moteur dcouverte, depuis le registre de services. Pour chaque service, elle fait appel la mthode computePropertyScore, afin de dterminer le niveau de pertinence du service. Permet de calculer le niveau de pertinence pour une proprit donne, comme dfini dans l'algorithme de comparaison dfini au paragraphe 4.4.

public void Compute()

public Vector<ServiceScore> algoImplementation(Vector<ServiceS core> services)

public Long computePropertyScore(String fieldName, String fieldValue,int criteriaIndice) Tableau 19.

Liste des mthodes de la classe SimpleEngine.

Dans ce qui suit, nous prsentons l'implmentation du moteur dcouverte par rapport la plateforme Android, notamment ct serveur et ct client.

6.2.2 L'IMPLEMENTATION
Pour pouvoir utiliser le Moteur Dcouverte dcrit prcdemment, il faut le voir en tant qu'un Service Dcouverte . L'utilisateur interroge ce service, en lui adressant sa requte, et ce Service Dcouverte rpond l'utilisateur en lui renvoyant la liste des services correspondant sa requte. L'application utilisateur doit donc savoir o trouver ce Service Dcouverte , comment y accder et comment l'utiliser correctement. La plate-forme Android ne propose aucune bibliothque permettant de communiquer avec un service Web, que ce soit pour le protocole SOAP (voir 2.1.2.2.2) ou pour le protocole XML-RPC (voir 2.1.2.2.1). Il est donc ncessaire de palier ce problme, soit en utilisant des bibliothques dj existantes, soit en en codant une partir de rien . La raison de l'absence de bibliothques dans Android est trs probablement lie au trs fort intrt que Google porte aux REST-based services qui utilisent JSON pour l'encapsulation des donnes (FIELDING 2000). l'heure actuelle, travailler avec des services Web bass sur du XML n'est pas vident, puisque la machine virtuelle Java (JVM) prsente dans Android ne permet pas d'utiliser facilement les bibliothques disponibles. 6.2.2.1 C OTE SERVEUR L'application a donc pour objectif de se connecter un service Web afin de rcuprer l'ontologie ncessaire son fonctionnement. Il s'agit du fichier *.owl dfinissant notre modle de description de service. Par simplicit, c'est la mthode SOAP qui a t retenue. Du ct serveur, il est ncessaire de rceptionner les requtes mises par l'application et d'y rpondre. Une seule fonction est ncessaire pour la ralisation de ce service Web. Ce service Web est dfini par le fichier WSDL suivant :
Page 106

<?xml version="1.0"?> <definitions name="CSP" targetNamespace="urn:CSP" xmlns:tns="urn:CSP" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:typens="urn:CSP" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:CSP"> <xsd:complexType name="MyResults"> <xsd:all> <xsd:element name="owl" type="xsd:string"/> </xsd:all> </xsd:complexType> </xsd:schema> </types> <message name="getowl"> <part name="none" type="xsd:int"/> </message> <message name="getowlResponse"> <part name="value" type="typens:MyResults"/> </message> <portType name="CspPorts"> <operation name="getowl"> <input message="getowl"/> <output message="getowlResponse"/> </operation> </portType> <binding name="MyBinding" type="typens:CspPorts"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <operation name="getowl"> <soap:operation soapAction="http://www.gsem.fr/webservice/WS.wsdl"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="getOntology"> <documentation>Service web permettant d identifier l ontologie</documentation> <port name="CspPorts" binding="typens:MyBinding"> <soap:address location="http://www.gsem.fr/webservice/index.php"/> </port> </service> </definitions>

Le serveur est ralis en PHP. Son fonctionnement est bas sur la librairie "SoapServer" prsente dans PHP5. Le fonctionnement de ce serveur se dcompose en une classe "handler" qui implmente les fonctions mises disposition par le service Web. Dans notre cas, elle fournira l'adresse de l'ontologie utiliser. Cette classe est ensuite transmise au "SoapServer" qui se charge de grer les requtes de l'utilisateur ainsi que de la formulation des rponses.

Page 107

<? // Definition de la classe handler class ServiceWeb { public function getowl() { return array('owl'=>'http://..../ontologie.owl'); } } // Desactivation du cache pouvant causer des erreurs en reception client ini_set("soap.wsdl_cache_enabled", "0"); // Instantiation du serveur defini par le schema wsdl $server = new SoapServer('WS.wsdl'); // Association de la classe "handler" $server->setClass('ServiceWeb'); // Gestion des requetes en POST if ($_SERVER['REQUEST_METHOD'] == 'POST') { $server->handle(); } // Affichage des fonctions disponibles else { echo '<strong>Ce serveur SOAP peut traiter les fonctions suivantes: </strong>'; echo '<ul>'; foreach($server -> getFunctions() as $func) echo '<li>'.$func.'</li>'; echo '</ul>'; } ?>

6.2.2.2 C OTE CLIENT Nous avons d effectuer le portage de deux librairies permettant d'effectuer des requtes travers un service Web, selon le protocole XML. Il s'agit des librairies RPC et SOAP. Pour la librairie XML-RPC, nous avons choisi la librairie kXML-RPC (kXML-RPC 2002). Cette librairie est conue pour Java ME et donc relativement lgre. De plus cette bibliothque est disponible sous licence GPL et permet donc la rutilisation, la modification, la redistribution. Parmi ses principaux avantages, nous pouvons citer le fait qu'elle ait t spcialement conue pour les applications mobiles (GABHART 2007). Nous avons aussi besoin des sources de la bibliothque kXML (kXML 2005), dont dpend kXML-RPC (kXML-RPC 2002). L encore on bnficie d'une licence GPL. Afin de permettre ces deux librairies de fonctionner avec la machine virtuelle Java propose par Android, il a t ncessaire de raliser un certain nombre de patchs les rendant ainsi pleinement oprationnelles. Pour ce qui est de la communication SOAP, il suffit d'importer la bibliothque "ksoap" (kSOAP 2003). Contrairement au XML-RPC, il n'est pas ncessaire de modifier le code de cette librairie, en vue de l'adapter la plate-forme Android. 6.2.2.3 R ECUPERATION DE L ' ONTOLOGIE Par soucis de cohrence avec le ct serveur, nous avons retenu la mthode SOAP. De plus, pour la ralisation du service Web, nous avons utilis le protocole SOAP. En outre, vu la simplicit de la requte finale, nous avons choisi de ne pas dployer une librairie complte.
Page 108

La requte auprs du service Web s'effectue donc de la manire suivante :


public class Client { private static final String URL = "http://urlduwebservice"; private static final String WSDL = "http://urlduwsdl"; private String owl = ""; private String url = ""; public Client() { String request = "<?xml version=\"1.0\" encoding=\"UTF-8\"?><SOAPENV: Envelope xmlns:SOAP-ENV=\"http://schemas.xmlsoap.org/soap/envelope/\"><SOAPENV: Body><SOAP-ENV:getowl><none/></SOAP-ENV:getowl></SOAP-ENV:Body></SOAPENV: Envelope>"; HttpClient c = new DefaultHttpClient(); HttpPost m = new HttpPost(URL); String _owl = ""; try { m.setHeader("SOAPAction", WSDL); m.setHeader("Content-Type", "text/xml; charset=utf-8"); m.setEntity(new StringEntity(request)); ResponseHandler<String> responseHandler = new BasicResponseHandler(); _owl = c.execute(m, responseHandler); c.getConnectionManager().shutdown(); } catch (Exception E) { return; } // On recupere l'url de l'ontologie if (_owl.length() > 0) { url = _owl.substring(_owl.indexOf("<owl>") + 5, _owl.indexOf("</owl>")); } // On telecharge cette ontologie c = new DefaultHttpClient(); HttpGet g = new HttpGet(url); try { ResponseHandler<String> responseHandler = new BasicResponseHandler(); owl = c.execute(g, responseHandler); c.getConnectionManager().shutdown(); } catch (Exception E) { } } public String getOWL() { return owl; } public String getURL() { return url; } }

Cette requte permet de rcuprer le fichier ontologie correspondant notre modle de description de services. Dans le paragraphe suivant, nous tudions comment cette ontologie est envoye au moteur dcouverte.

Page 109

6.2.2.4 E NVOI DE L ' ONTOLOGIE AU MOTEUR DECOUVERTE Le moteur de dcouverte n'est en mesure que de lire un fichier. Nous avons donc modifi la classe OwlTools (voir ci-dessous) afin de rendre possible la transmission d'un XML sous forme de chane de caractres, et donc d'viter le stockage de fichiers sur le mobile.
public OwlTools(String xml, String URL) { try { inputModel = ModelFactory.createOntologyModel(); OutpoutModel = ModelFactory.createOntologyModel(); inputModel.read( new StringReader( xml ), URL, "RDF/XML" ); } catch (Exception e) { } }

L'ontologie, une fois traite par le parseur, permet de gnrer l'arborescence des menus de l'interface utilisateur. Dans ce qui suit, nous allons dcouvrir comment cette interface est ralise.

6.3 DEVELOPPEMENT DES INTERFACES


6.3.1 INTERFACE UTILISATEUR FINAL
6.3.1.1 L A CREATION D ' INTERFACES UTILISATEUR SOUS A NDROID Sous Android, les interfaces utilisateur peuvent tre conues de deux manires diffrentes: De manire procdurale, c'est--dire en crivant du code, Java par exemple, pour crer et manipuler les objets d'interface; De manire dclarative, travers des fichiers XML spcifiant les lments que l'on dsire voir apparatre dans l'interface. Les deux manires sont valides, mais Google avise d'utiliser les dclarations XML autant que possible. Les raisons motivant ce choix concernent la complexit du code Java et la stabilit du XML. En effet, il est beaucoup plus facile et plus rapide de comprendre un fichier XML, plutt que le code Java correspondant. De plus, compare la syntaxe Java, la syntaxe XML est moins sujette des changements. Nous utilisons donc la programmation base de dclarations XML, comme indiqu au paragraphe prsentant le concept de Vue ( 6.3.1.1.1.2). Android introduit aussi de nouveaux concepts pour la cration d'interfaces: Activities - Les activits reprsentent la fentre ou l'cran affich l'utilisateur. Les Activits sont les quivalents Android d'un formulaire. Pour afficher une interface utilisateur, il faut affecter une vue une activit. Views - Les vues reprsentent le type de base d'lments d'interface utilisateur. Il s'agit d'lments visuels d'interface, aussi appels widgets. L'ensemble des contrles interface utilisateur, ainsi que les classes de layout drivent de la classe Views. ViewGroups - Les ViewGroups reprsentent des extensions de la classe Views pouvant contenir plusieurs vues enfants. En tendant la classe ViewGroups il est possible de crer des contrles composs, forms par un ensemble de vues enfants interconnectes.

Page 110

6.3.1.1.1 P RESENTATION DES CONCEPTS A NDROID 6.3.1.1.1.1 LE CONCEPT D' ACTIVITE Les activits permettent de crer des crans d'interface utilisateur. Chaque activit reprsente une fentre que l'application peut prsenter l'utilisateur (comparable un formulaire dans un environnement bureautique). Il s'agit donc de crer des activits pour chaque fonctionnalit de l'application. Cela ncessite au moins une fentre d'interface de base pour grer ces fonctionnalits. Les fonctionnalits reprsentent des activits telles la saisie de texte ou l'affichage des rsultats. Pour passer d'une fentre une autre, il faut soit dmarrer une nouvelle activit, soit revenir depuis une activit. Une activit peut tre dans plusieurs tats diffrents : Active quand elle est au premier plan sur lcran. Mise en pause quand elle est recouverte par une autre activit qui noccupe pas lintgralit de lcran ou qui est transparente. Ltat et les donnes internes sont conservs mais le systme pourra tuer lactivit si les ressources systme sont extrmement faibles. Stoppe quand elle est nest plus visible pour lutilisateur, ltat et les donnes internes sont conserves mais le systme pourra tuer lactivit sil a besoin de mmoire pour dautres tches. Le passage dun tat un autre est gr grce des mthodes protges :
void void void void void void void onCreate(Bundle savedInstanceState) onStart() onRestart() onResume() onPause() onStop() onDestroy()

La Figure 49 reprsente le cycle de vie dune activit.

Page 111

Figure 49.

Cycle de vie dune Activit.

Pour crer une nouvelle activit, il faut tendre la classe Activity, en dfinissant l'interface utilisateur et en implmentant nos fonctionnalits. Un squelette de code permettant de dfinir une nouvelle activit est prsent ci-dessous.
import android.app.Activity ; import android.os.Bundle ; public class MyActivity extends Activity { //appele lorsque lactivit est cre pour le premire fois @Override public void onCreate(Bundle icicle) { super.onCreate(icicle) ; } }

Ceci permet de crer un cran vide, encapsulant les fonctionnalits manipulant l'affichage de la fentre. Une activit vide n'tait pas trs utile, nous devons dfinir l'interface de l'cran en utilisant des Vues . C'est ce que nous tudions dans ce qui suit. 6.3.1.1.1.2 LE CONCEPT DE VUE Linterface graphique dune activit est dfinie grce des objets de type View et ViewGroup. Les vues sont des contrles d'interface utilisateur, qui permettent d'afficher des donnes et de fournir des interactions avec l'utilisateur. L'ensemble des lments visuels d'une interface proviennent de la classe View et sont appels vues .

Page 112

La classe ViewGroup est une extension de la classe View conue pour contenir des vues multiples. Gnralement, ces groupements de vues sont utiliss: pour construire des composants atomiques rutilisables (ou des widgets), ou pour grer la disposition (ou le layout) des vues enfants. Les ViewGroup utiliss en ce sens sont appels dispositions ou layouts. La Figure 50 illustre la hirarchie entre ces diffrents lments. Un contrle est une extension de la classe View implmentant une fonctionnalit basique ou relativement simple. Un widget reprsente la fois des contrles composs et des extensions plus complexes de la classe View.

Figure 50.

Illustration des relations entre les diffrents composants dune Vue.

Pour notre application, la manire la plus simple de crer linterface est de dcrire un layout compos de diffrents objets View dans un fichier XML. Nous donnons ci-dessous un exemple de fichier XML permettant de crer une disposition simple, qui place un lment TextView au dessus d'un contrle EditText. La disposition ainsi dcrite est base sur celle d'un LinearLayout orient verticalement.
<?xml version=1.0 encoding=utf-8?> <LinearLayout xmlns:android=http://schemas.android.com/apk/res/android android:orientation=vertical android:layout_width=fill_parent android:layout_height=fill_parent> <TextView android:layout_width=fill_parent android:layout_height=wrap_content android:text=Saisissez votre texte ci-dessous /> <EditText android:layout_width=fill_parent android:layout_height=wrap_content android:text=Le texte est ici /> </LinearLayout>

Cependant, si lon a besoin de rajouter un lment dinterface dynamiquement, on peut le faire directement dans le code Java. C'est ce qui est dcrit dans la partie Ralisation de l'interface utilisateur (voir 6.3.1.2).

Page 113

6.3.1.1.1.3 LE CONCEPT D' INTENTION Maintenant que nous avons prsents les concepts de base de la cration d'interfaces sous Android, nous allons nous intresser comment ces lments sont relis l'application et comment ils communiquent entre eux. Les intentions sont des mcanismes permettant de dclarer l'action raliser par rapport des donnes. Les intentions sont communment utilises pour dmarrer de nouvelles activits: soit de manire explicite (en spcifiant la classe charger),
Intent intent = new Intent(MyActivity.this, MyOtherActivity.class); startActivity(intent);

soit de manire implicite (en demandant d'effectuer une action sur des donnes)
if (quelqueChoseEtrange && caNeSemblePasCorrect) { Intent intent = new Intent(Intent.ACTION_DIAL, Uri.parse(tel:555-2368)); startActivity(intent); }

L'utilisation d'intentions pour propager des activits mme l'intrieur d'une mme application reprsente un concept fondamental d'Android. Ceci encourage le dcouplage des composants, afin de permettre un remplacement sans coutures des lments de l'application. Ceci reprsente aussi la base d'un modle simple permettant tendre les fonctionnalits d'une application. 6.3.1.2 R EALISATION DE L ' INTERFACE UTILISATEUR Pour le dveloppement de notre application, nous avons besoin de plusieurs fentres, chacune correspondant une fonctionnalit de l'application. Ces fentres sont illustres par la Figure 51, et sont dtailles dans ce qui suit: Une fentre pour naviguer dans lontologie, notamment pour choisir une catgorie de service - Fentres 1A, 1B et 1C; Une fentre permettant lutilisateur de pondrer et de dfinir des valeurs pour les diffrentes informations contextuelles associes au type de service choisi (par exemple, pour un service restaurant, l'utilisateur doit pouvoir dfinir un prix, un type de restaurant, etc.) Fentres 2A et 2B; Une fentre pour afficher la liste des rsultats, tris en fonction de leur niveau de pertinence - Fentre 3; Une fentre pour afficher l'itinraire vers une adresse donne - Fentre 4; Une fentre pour afficher les dtails concernant un rsultat en particulier (par exemple, pour un service restaurant, il faut afficher son adresse, numro de tlphone, ainsi que ses informations contextuelles) - Fentre 5; Une fentre pour lancer l'appel d'un numro de tlphone donn cette fentre n'est pas illustre par la Figure 51, mais elle correspond l'interface Android de base, pour le module Tlphonie (voir 0).

Page 114

Figure 51.

Illustration des diffrents crans composant linterface Utilisateur final .

Comme nous l'avons prcis, chacune de ces fentres implmente une ou plusieurs fonctionnalits bien distinctes. Les fentres 1A, 1B et 1C concernent la navigation dans une liste, alors que les fentres 2A et 2B impliquent la dfinition de layouts personnaliss et reposent sur l'utilisation de sliders. Nous dtaillons la ralisation de ces fonctionnalits dans les paragraphes suivants. 6.3.1.2.1 N AVIGATION DANS UNE LISTE Il existe une activit spciale qui permet de grer un affichage par liste. Notre activit doit hriter de l'activit ListActivity, afin d'avoir accs un ensemble de mthodes permettant la gestion des interactions de l'utilisateur avec les diffrents lments de la liste. Il est ainsi possible de dfinir le rsultat d'un clic sur un lment de la liste. Les donnes sont importes depuis l'ontologie sous la forme de chanes de caractres. Pour pouvoir afficher ces donnes, il faut utiliser un adapter qui va mettre les donnes sous une forme convenant laffichage.

Page 115

ArrayAdapter<String> itemsList = new ArrayAdapter<String>( this, android.R.layout.simple_list_item_1, items); setListAdapter(itemsList);

Le code affich ci-dessus utilise les lments suivants: this correspond lactivit en cours. android.R.layout.simple_list_item_1 correspond au layout que lon souhaite utiliser pour linterface. Ici, il s'agit d'un layout standard, correspondant un mode liste. items reprsente notre tableau de chanes de caractres contenant les catgories de services. Une fois ladapter cr, on affiche les donnes dans la liste grce la mthode setListAdapter(). La Figure 52 illustre le rsultat obtenu.

Figure 52.

Liste des catgories de services dfinies dans notre modle.

Notre activit hrite de la classe ListActivity ce qui nous permet dutiliser les mthodes de cette classe, notamment pour capturer les vnements de clic. Avec la mthode onListItemClick() il est possible de savoir, par exemple, sur quel lment lutilisateur clique. Il est ds lors possible de naviguer dans la hirarchie de profils service dfinie par notre modle ontologique (voir Figure 53).

Figure 53. Navigation parmi les catgories de services - ici, affichage des diffrents types dinformations (nous sommes ici dans la mme activit, nous avons seulement rafrachi la liste).

Page 116

Dans le droulement de lapplication, lutilisateur doit pouvoir choisir les dtails vis--vis dun service donn comme par exemple limportance du prix dun restaurant. Le comportement de cette activit est diffrent de la navigation dans lontologie, nous allons donc crer une activit supplmentaire. 6.3.1.2.2 A JOUT ET APPEL D ' UNE NOUVELLE ACTIVITE Pour ajouter une activit, il faut tout dabord crer une nouvelle classe qui hrite de la classe Activity. Il faut aussi modifier le fichier AndroidManifest.xml dans lequel sont rpertories toutes les activits et les autorisations de chacune des activits. Le code ci-dessous prsente un extrait de ce fichier. Le fichier complet est prsent dans lAnnexe D. Fichiers de l'interface Utilisateur final .
<manifest ... <application ...> <activity ... android:name=".activity.ServiceList"> ... </activity> <activity android:name=".activity.ServiceDetail"></activity> </application> </manifest>

On peut voir ici que notre application contient pour le moment deux activits : ServiceList et ServiceDetail. Pour appeler cette nouvelle activit, on utilise une intention (appele de manire implicite) et la mthode startActivity() :
Intent i = new Intent(this, ServiceDetail.class); startActivity(i);

Ainsi, nous avons cre une nouvelle activit, appele ServiceDetail et qui est dmarre par l'intention i. Dans ce qui suit, nous expliquons la cration d'un layout personnalis pour cette activit. 6.3.1.2.3 C REATION D ' UN LAYOUT PERSONNALISE Pour notre nouvelle activit ServiceDetail, nous avons besoin de crer une nouvelle interface, et ce partir de rien . En effet, nous devons crer un affichage personnalis, comprenant une liste compose de champs de texte et de sliders (comme l'indique l'Ecran 2A, dans la Figure 51). Pour ce faire, nous dcrivons notre interface dans un nouveau fichier *.xml, stock dans le rpertoire /res/layout/details.xml. Le code ci-dessous prsente un extrait de ce fichier. Le fichier complet est prsent en annexe (voir Annexe D. Fichiers de l'interface Utilisateur final ).
<LinearLayout <TextView android:text="TextView01" android:id="@+id/TextView01" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView> <fr.utbm.android.view.Slider android:id="@+id/slider" android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="Slide me..." /> </LinearLayout>

Page 117

Nous voyons ici que notre layout est constitu dun objet de type TextView et dun objet de type Slider. Ces deux objets ont pour classe mre la classe View. Nous dfinissons les attributs de chaque objet, notamment son identifiant (proprit id), sa largeur (proprit layout_width) et son hauteur (proprit layout_height). partir de notre activit, il nous suffit maintenant dappliquer ce layout, travers la commande :
setContentView(R.layout.details);

6.3.1.2.4 L E SLIDER Android implmente par dfaut une vue de type SeekBar, dont le fonctionnement s'apparente un slider. Aprs avoir instanci notre slider, il est possible de capturer les vnements dus aux mouvements et ainsi rcuprer la valeur correspondant la position du curseur. Ceci est illustr par le code suivant:
// On active l'coute des vnements mSlider.setOnPositionChangedListener( new OnPositionChangedListener() { // Pendant le mouvement public void onPositionChanged(Slider slider, int oldPosition, int newPosition) { int newPos = newPosition; // position en temps rel } // Quand le mouvement est termin public void onPositionChangeCompleted() { int newPos = mSlider.pos; // position la fin du mouvement } });

La Figure 54 affiche le rsultat ainsi obtenu.

Figure 54.

Rcupration de la valeur du slider.

Nous observons que les valeurs sont comprises entre 0 et 100. Or, nous n'avons nul besoin d'une telle prcision, car nous n'avions dfini que 5 niveaux de pondration, pouvant tre associs une information contextuelle. Nous normalisons donc les valeurs selon 5 paliers de 20 units. Une valeur de 40 va correspondre un niveau de pondration de 2 , et une valeur de 68 va correspondre un niveau 4 de pondration (voir Fentre 2B, dans la Figure 51).

Page 118

6.3.1.2.5 I NTEGRATION DU MODULE "A FFICHAGE CARTE " Grce aux API fournies par le SDK Android, il est possible d'utiliser l'application GoogleMaps, pour afficher une adresse ou un itinraire vers une adresse donne. Il faut dabord obtenir la longitude et la latitude correspondant une adresse donne. Pour ce faire, nous utilisons le geocoder intgr l'application GoogleMaps:
if (address != null) { Geocoder geocoder = new Geocoder(context, Locale.getDefault()); try { addressResult = geocoder.getFromLocationName(address, 1); if (!addressResult.isEmpty()) { Address resultAddress = addressResult.get(0); location.setLatitude(resultAddress.getLatitude()); location.setLongitude(resultAddress.getLongitude()); } } catch (IOException e) { Log.d("Lieu non dtermin", e.getMessage()); } }

Il reste ensuite appeler l'activit map, qui permet d'afficher la position correspondant l'adresse initiale:
try { final Intent myIntent = new Intent(android.content.Intent.ACTION_VIEW, Uri.parse("geo:"+location.getLatitude + "," + location.getLongitude)); startActivity(myIntent); } catch (URISyntaxException e) { }

La Figure 55 illustre le rsultat obtenu.

Figure 55.

Affichage dune adresse grce au module GoogleMaps.

Page 119

6.3.1.2.6 I NTEGRATION DU MODULE T ELEPHONIE Le SDK fourni par Google offre une activit dj prte pour pouvoir simplement appeler un numro de tlphone. Le fonctionnement est le mme que pour les autres modules, nous utilisons une intention pour appeler cette activit.
public void callNumber(String number) { Intent intent = new Intent(Intent.ACTION_DIAL, Uri.parse("tel:" + number)); startActivity(intent); }

Ici, laction excute est ACTION_DIAL. Quand cette fonction est excute, le module de tlphonie est lanc et le numro est compos directement (voir Figure 56).

Figure 56.

Composition dun numro de tlphone.

6.3.1.3 C ONCLUSIONS CONCERNANT LE DEVELOPPEMENT DE L ' INTERFACE U TILISATEUR F INAL Le principal avantage du systme Android est d'tre trs modulaire, ce qui facilite grandement l'intgration des diffrents composants et fonctionnalits. Toutefois, au moment de la rdaction de ce chapitre, le dveloppement de l'application n'est pas encore termin. Nous sommes en train de terminer la description de l'affichage personnalis correspondant la cration de la requte utilisateur. Par la suite, nous n'aurons plus qu' raliser diffrents tests pour vrifier le bon fonctionnement de l'application. La dure restante est estime environ 6 semaines.

6.3.2 INTERFACE FOURNISSEUR DE SERVICES


Nous avons prsent l'interface permettant la cration de requtes utilisateur. Ces requtes sont adresses un registre de services, contenant un ensemble de descriptions de services. En d'autres termes, nous avons dvelopp une interface permettant de rechercher travers le registre, mais nous ne nous sommes pas intresss la manire de remplir ce registre avec des descriptions de services conformes notre modle. Pour le moment, il n'existe pas d'outil permettant de crer une telle description de service. Il faut donc dvelopper une interface claire et intuitive, qui puisse permettre aux fournisseurs de services de crer de telles descriptions, puis de les enregistrer dans le registre de services. Traditionnellement, la dcouverte et l'invocation de services Web reposent sur l'usage de fichiers WSDL. Comme dfini prcdemment (voir 2.1.2.3), un document WSDL spcifie de manire abstraite, les oprations et messages dfinissant un service Web. Des nos jours, lors du processus de

Page 120

dcouverte de services Web, le client recherche les services pertinents parmi un ensemble des documents WSDL publis dans un annuaire de type UDDI. Chaque document WSDL correspond la spcification d'un service Web. Donc, il apparat vident d'intgrer les descriptions WSDL dans notre approche. En effet, la plupart des fournisseurs de services disposent aujourd'hui de descriptions de leurs services, conformment au standard WSDL. Nous souhaitons nous baser sur ces descriptions, puis de les complter, selon notre modle de description. Il s'agit donc de proposer au fournisseur de service un formulaire, lui permettant de prciser le fichier WSDL contenant les informations service, telles le nom ou l'adresse du service (voir Figure 39). Nous supposons que le fournisseur de service possde dj un tel fichier WSDL. Une fois ce fichier charg, les informations qu'il contient sont extraites et remplissent les champs correspondants du formulaire. Les autres champs du formulaire sont obtenus par requtes SPARQL depuis notre ontologie de description de service. Il s'agit donc d'un formulaire dynamique, construit partir du fichier WSDL et de l'ontologie. Dans les paragraphes suivants, nous prsentons sa ralisation et son fonctionnement. 6.3.2.1 R ECUPERATION DES INFORMATIONS WSDL Pour rcuprer les informations service contenues dans un fichier WSDL, il faut pouvoir analyser ce fichier. Or, pour ce faire, il existe plusieurs programmes. De plus, il existe mme des programmes permettant de traduire une description WSDL en une description OWL-S. Nous avons choisi d'utiliser le programme WSDL2OWL-S (GIAMPAPA 2005), dvelopp par le laboratoire Softagent Lab, de l'universit Carnegie Mellon28. Ce programme fournit une traduction partielle entre les descriptions WSDL et OWL-S d'un mme service. Les rsultats d'une telle traduction consistent en une spcification complte de la classe ServiceGrounding, une spcification partielle des classes ServiceProcess et ServiceProfile. Cette spcification partielle s'explique par les diffrences des informations contenues dans une description OWL-S et une description WSDL. En effet, une description WSDL ne fournit aucune information quand la composition de processus, donc la classe ServiceProcess gnre ne pourra contenir de telles informations. De la mme manire, les fonctionnalits du service ne sont pas dcrites dans un fichier WSDL. Cela veut dire que, pour tre complte, la classe ServiceProfile gnre doit tre complte par l'utilisateur (PAOLUCCI 2003). Nous reprenons donc les sources de ce programme, puis nous les adaptons notre application. Ayant tendu la description de la classe ServiceProfile, travers la cration de catgories de services, il est ncessaire de prciser quel type de profil de service est vis. Pour ce faire, le fournisseur de services commence par choisir le type de service qu'il souhaite spcifier. Une fois dfini le profil de service, le fournisseur spcifie le fichier WSDL dcrivant son service. Nous analysons donc ce fichier, puis en extrayons les informations ncessaires, telles le nom et l'adresse du service. La Figure 57 prsente la traduction en OWL-S des informations contenues dans un fichier WSDL.

28

Voir : http://www.cs.cmu.edu/~softagents/
Page 121

Figure 57.

Traduction WSDL en OWL-S (PAOLUCCI 2003).

Nous nous intressons maintenant la manire de rcuprer les informations contextuelles depuis notre modle de description de services. 6.3.2.2 R ECUPERATION DES INFORMATIONS CONTEXTUELLES Nous venons de prsenter comment les informations WSDL sont obtenues depuis le fichier correspondant. Nous avons toutefois prcis qu'avant d'obtenir ces informations, le fournisseur de services doit spcifier le profil du service qu'il souhaite dcrire. Or, pour ce faire, il est ncessaire de parcourir notre modle ontologique, puis d'en tirer les diffrents types de profils service dfinis. Le programme doit donc construire le graphe RDF illustr par la Figure 58. Afin damliorer la lisibilit du graphique, nous navons pas affich lensemble des proprits contextuelles dfinies pour un service de restauration.

Page 122

Figure 58.

Graphe RDF illustrant les informations contextuelles dun service de restauration.

Pour manipuler les fichiers ontologie, nous utilisons encore l'API Jena. Nous crons le package OWL qui contient les fichiers: ManipulerOWL.java (voir Annexe C. Fichiers de l'interface Fournisseur de services ), MODELONT.java, PropertyService.java et ServiceOWL.java. La classe ServiceOWL repose sur le modle d'un nud RDF, tel que dfini par l'API Jena. Cette classe est utilise pour reprsenter les diffrents types de services dfinis par notre modle. Les proprits (ou informations contextuelles) associes chaque type de service sont reprsentes grce la classe PropertyService. Pour parcourir l'ontologie et rcuprer les informations contextuelles qui nous intressent, nous crons la classe ManipulerOWL. Elle utilise l'API Jena et son moteur ARQL pour les requtes SPARQL. SPARQL (PRUD'HOMMEAUX 2008) reprsente un langage et un ensemble de protocoles de requtes, permettant l'interrogation de mtadonnes, en utilisant des triplets RDF (voir 2.2.3.2.1). Une requte SPARQL est constitue d'une chane de caractres dlimite par des accolades {}. La requte suivante permet d'obtenir la liste des profils service dfinis dans notre modle:
"PREFIX owl: <http://www.w3.org/2002/07/owl#> " + "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> "+ "PREFIX prof: <http://www.daml.org/services/owl-s/1.2/Profile.owl#Profile>"+ "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>"+ "SELECT ?subClass " + "WHERE {" + " ?subClass rdfs:subClassOf prof" . " + " }";

Les trois premires lignes prcisent l'espace de nom (le namespace) pour les prfixes rdfs, prof, et rdf. La clause SELECT nomme la variable qui sera renvoye, ici il s'agit de la variable subClass (les variables SPARQL sont toujours prcdes par ? (PRUD'HOMMEAUX 2008)). La clause WHERE dfinit la clause RDF que l'on cherche satisfaire, sous la forme d'un triplet RDF du type Sujet, Prdicat, Objet . Ici, il s'agit de renvoyer l'ensemble des sous-classes de la classe Profile, dont l'URI (<http://www.daml.org/services/owl-s/1.2/Profile.owl#Profile>) est associe au prfixe prof. De la mme manire, pour obtenir les informations contextuelles associes un service donn, nous utilisons la requte suivante:
"PREFIX owl: <http://www.w3.org/2002/07/owl#> " + "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> "+ "SELECT ?subClass ?proper ?value " + "WHERE {" + " ?subClass rdfs:subClassOf <http://www.daml.org/services/owl-s/1.2/ Service.owl#"+NameService+">; " + " rdfs:subClassOf [ a owl:Restriction; owl:onProperty ?proper; owl:allValuesFrom ?value].}";

Ici, nous souhaitons renvoyer l'ensemble des sous-classes de la classe NameService, puis pour chacune de ces sous-classes, on renvoie le type de valeur attendu, dfini par la restriction OWL prsente dans l'ontologie. En pratique, les classes vises par cette requte sont les sous-classes de la classe ServiceContext. Chacune de ces classes a trois proprits: aValeur, aPonderation et aQuantificateur. Ici, ce qui nous intresse c'est la restriction dfini pour la proprit

Page 123

aValeur, qui dtermine le type de valeur attendu pour l'information contextuelle (ou la proprit service) considre (voir 4.3.2.2). Cette requte SPARQL permet donc de rcuprer l'ensemble des informations contextuelles dfinies pour un contexte de service donn (par exemple Service_Restaurant_Context), ainsi que les types de valeurs attendus pour ces informations. 6.3.2.3 C REATION DE L ' INTERFACE F OURNISSEUR DE SERVICE Pour crer notre interface, nous utilisons la technologie JSP (Java Server Pages) (JSP 2009). Les JSP reprsentent des pages Web gnres dynamiquement, dont la prsentation (code HTML) est spare des traitements (code Java). Au premier appel d'une page JSP, le moteur JSP gnre et compile automatiquement une Servlet Java, permettant la gnration de la page Web proprement dite (JSP 2009). La Servlet reprend entirement le code HTML, et excute le code Java, dfinis dans la classe Java associe. Pour notre interface, nous utilisons trois Servlets: une pour afficher la liste des types de services (fichier service_jsp.java) , une pour gnrer le formulaire permettant de dfinir les valeurs des diffrentes proprits contextuelles dfinies pour le type de service choisi (fichier recepservice_jsp.java) une pour enregistrer un fichier OWL partir des informations contenues dans le formulaire (fichier CreateOWL.java) 6.3.2.4 A PERU DE L ' INTERFACE "F OURNISSEUR DE SERVICE " Ayant prsent les diffrentes technologies et mthodes utilises pour mettre en place notre interface, nous nous intressons maintenant au rsultat final. Le premier cran prsente la liste des catgories de services, telles que dfinies par notre modle de description de service (Figure 59).

Figure 59.

Affichage des catgories de services dfinies dans le modle ontologique.

Page 124

Pour choisir la catgorie de service qu'il souhaite renseigner, le fournisseur de service doit cliquer sur le nom de cette catgorie. Cela a pour effet de gnrer un formulaire contenant le nom des informations contextuelles dfinissant le service, avec pour chaque information le type de donnes attendu, et un champ de saisie. Le fournisseur de service peut ainsi saisir les valeurs des diffrentes proprits contextuelles du service. Ce formulaire est aussi utilis pour spcifier le fichier WSDL associ au service. La Figure 60 illustre le formulaire gnr pour un service de type restaurant.

Figure 60.

Formulaire permettant de publier un service.

Lorsque le fournisseur de service a termin la saisie, il clique sur le bouton Crer Service . Ceci a pour effet de gnrer un fichier OWL, contenant les informations extraites depuis le fichier WSDL et les proprits contextuelles du service, instancies avec les valeurs saisies par le fournisseur de service. Un exemple d'un tel fichier est prsent par les annexes (voir Annexe C. Fichiers de l'interface Fournisseur de services ). Dans ce qui suit, nous discutons des limitations de cette approche et des volutions envisageables. 6.3.2.5 C ONCLUSIONS CONCERNANT LE DEVELOPPEMENT DE L ' INTERFACE F OURNISSEUR DE SERVICE Pour le moment, les valeurs des diffrentes proprits sont saisies manuellement, mais il est ais d'imaginer une future volution de l'application, dans laquelle ces valeurs seraient transmises par des capteurs (notamment pour les informations contextuelles dynamiques, telles le nombre de places disponibles dans le parking d'un restaurant). De plus, en l'tat actuel, lors de la gnration de la description de service, le programme gnre l'ontologie dans son intgralit, en y ajoutant seulement des valeurs pour les proprits modifies. Il serait intressant de ne gnrer que les classes utilises dans la description du service, afin de minimiser la taille du fichier final. De cette manire, le temps de traitement d'un tel fichier est rduit. De plus, plus la taille du fichier est rduite, plus le fichier est adapt tre utilis sur une plate-forme mobile. Il s'agit donc d'optimiser la gnration du fichier final, dcrivant le service, en vue de son utilisation sur une plate-forme mobile, de type Android. Une dernire limitation de cette approche est constitue par le besoin d'un serveur, o l'ensemble des descriptions ainsi gnres sont stockes et enregistres. Ceci constitue le registre de services, qui sera interrog par le Moteur Dcouverte .
Page 125

CHAPITRE 7. EVALUATION DU PROTOTYPE


Cette partie a pour objectif dvaluer le fonctionnement du prototype propos dans cette thse. Ce prototype est valu en regard de la principale contrainte pour une application mobile, le temps. Il sagit ici dtudier le temps dexcution dune requte utilisateur, et ce, en prenant en compte, comme paramtre, le nombre de services valuer pour cette requte.

7.1 Mesures de performance ____________________________________________________ 127


7.1.1 Mesures de rapidit ______________________________________________________________ 127 7.1.2 Mesures de pertinence ____________________________________________________________ 130

7.2 Mesures relatives lutilisateur final___________________________________________ 133 7.3 Conclusion ________________________________________________________________ 134

Page 126

7.1 MESURES DE PERFORMANCE


7.1.1 MESURES DE RAPIDITE
7.1.1.1 E TAPES COMPOSANT L EXECUTION D UNE REQUETE Avant de prsenter notre protocole de test, nous rappelons que dans notre approche, les services sont premirement slectionns en fonction de leur catgorie dans la hirarchie de services dfinie au paragraphe 4.3.1.3. Un algorithme est ensuite appliqu lensemble des services ainsi slectionns, et ce afin de calculer le degr de pertinence de chaque service, par rapport aux critres spcifis par la requte utilisateur. Lexcution dune requte utilisateur est donc dcompose selon les tapes suivantes : Etape 1 slection et chargement des services prsents dans la catgorie spcifie par lutilisateur dans sa requte. Etape 2 rcupration des valeurs de chaque service, pour les proprits nonfonctionnelles spcifies par lutilisateur dans sa requte. Cette tape a pour but de construire le tableau dordonnancement illustr par le Tableau 14. Etape 3 calcul du degr de pertinence de chaque service par rapport la requte de lutilisateur. Cette tape consiste appliquer lalgorithme dfini au Tableau 15, pour lensemble des services slectionns durant la premire tape. Le temps total dexcution dune requte utilisateur est ds lors la somme des temps correspondants aux tapes listes ci-dessous. 7.1.1.2 P ROTOCOLE DE TEST Linterface Utilisateur final ntant pas encore termine au moment de lvaluation, nous avons mis en place une interface JSP permettant de crer une requte utilisateur. Une fois la requte cre et valide, nous demandons au programme de nous afficher lheure chaque fois quil dbute une nouvelle tape, parmi celles listes ci-dessus. La diffrence entre lheure de fin et lheure de dbut dune tape, nous permet dobtenir la dure de cette tape. Pour ces tests, nous utilisons un ordinateur portable MacBook Pro, avec un processeur Intel Core 2 Duo, tournant la frquence de 2,53 GHz et disposant de 3Gb de mmoire RAM. Nous tudions ces temps en fonction du nombre de services traiter pour la requte. En effet, une fois la requte utilisateur valide, le programme cherche dterminer combien de services permettent de rpondre la requte (de manire partielle ou pas). Notre algorithme de comparaison est appliqu cet ensemble de services. 7.1.1.3 R ESULTATS Pour chacun de ces cas, nous effectuons plusieurs tests, en calculant la dure de chaque tape. Nous effectuons des tests o le nombre de services prsents dans lannuaire varie. Nous choisissons de tester les cas o lannuaire contient : un, trois, cing et dix services. Pour les tests comprennant respectivement un et trois services dans lannuaire, nous effectuons deux sries de tests. Les rsultats ainsi obtenus sont illustrs dans le Tableau 20.

Page 127

Nombre services

Etape 1

Etape 2

Etape 3

Dure totale

1 1 3 3 5 10

00:00:00,162 00:00:00,158 00:00:00,444 00:00:00,461 00:00:00,795 00:00:01,533


Tableau 20.

00:00:00,023 00:00:00,005 00:00:00,021 00:00:00,018 00:00:00,025 00:00:00,070

00:00:00,014 00:00:00,011 00:00:00,018 00:00:00,016 00:00:00,014 00:00:00,045

00:00:00,199 00:00:00,174 00:00:00,465 00:00:00,479 00:00:00,834 00:00:01,648

Premier test Temps dexcution dune requte utilisateur.

A la suite de ce premier test, nous pouvons faire les remarques suivantes : La dure du premier test avec un seul service (la premire ligne du Tableau 20) est suprieure la dure des deux autres tests effectus avec un seul service (ligne 2 du Tableau 20). Ceci sexplique par le chargement en mmoire de lensemble des librairies ncessaires notre prototype. Ce premier temps dexcution est plus long que les autres temps, car ce test reprsente la phase dinitialisation du prototype. Cest la raison pour laquelle nous avons effectus plusieurs tests dans ce cas de figre. Dailleurs, cest pour cette raison que les temps obtenus, pour le deuxime test avec un seul service, sont infrieurs aux temps obtenus lors du premier test. La dure dexcution de lalgorithme issu de notre travail de recherche (Etape 3) semble tre constante et ne reprsente pas la principale partie du temps total dexcution dune requte. Pour mieux illustrer ceci, nous calculons la part (en pourcentage) de chaque temps, par rapport la dure totale (Tableau 21). Nous observons alors que le chargement des services en mmoire occupe le plus de temps.
Nombre services Etape 1 Etape 2 Etape 3

1 1 3 3 5 10
Tableau 21.

81,41 90,80 95,48 96,24 95,32 93,02

11,56 2,87 4,52 3,76 3,00 4,25

7,04 6,32 3,87 3,34 1,68 2,73

Premier test Rpartition (en %) des dures correspondant chacune des tapes.

Ce premier test permet de mettre en vidence lefficacit de nottre algorithme. Son temps dexcution est compatible avec les contraintes de temps des algorithmes dappareillement dontologies (EUZENAT 2007). En effet, dans (EUZENAT 2007), les auteurs prsentent une valuation dtaille de ces diffrents algorithmes, en termes de pertinence, rapidit et efficacit. Mme sils ne donnent que quelques mesures de rapidit, ils indiquent le besoin davoir des algorithmes rapides notamment lorsquil sagit de rpondre une requte utilisateur. Dans notre cas, les temps dexcution de notre algorithme de comparaison ne reprsentent quun faible pourcentage du temps total dexcution de la requte. Cela prouve sa rapidit. Nous souhaitons toutefois essayer damliorer ces dures dexcution des requtes. Pour ces tests, les requtes et lalgorithme de comparaison sont excuts sur la mme machine, ce qui rduit dj considrablement le temps dexcution total. En effet, lors de limplmentation de linterface mobile, les utilisateurs seront tributaires des caractristiques de leur connexion rseau (Edge/GPRS/UMTS ou encore WiFi, voire mme WiMax). Ces technologies ne possdent pas les mmes caractristiques et il

Page 128

est fort probable que lutilisateur aura attendre plus ou moins longtemps, pendant que linterface mobile communique avec le registre et le serveur. Nous voulons donc rduire ces temps dexcution leur valeur minimale. Pour ce faire, nous modifions la description des fichiers, de manire ne contenir que les concepts utiliss par notre prototype. En dautres termes, nous supprimons de notre modle de description de services les concepts OWL-S qui ne sont pas ncessaires notre prototype. Il sagit de concepts tels ServiceModel (nous navons pas besoin de modliser les traitements du service, puisque lensemble des services qui nous concernent neffectuent aucun traitement) ou encore les concepts ayant un lien avec la spcification de rgles logiques (Expression et LogicLanguage). Nous rduisons ainsi la taille du fichier *.owl dcrivant chaque service. Dans la premire srie de tests, ce fichier faisait environ 196kb, alors quaprs rduction il nen fait plus que 112kb. Nous relanons donc une nouvelle srie de tests, avec les mmes paramtres que prcdemment. Seule la taille des fichiers traiter a t rduite, afin de dterminer le gain de temps que cela induit. Les rsultats de ces tests sont indiqus dans le Tableau 22.
Nombre services Etape 1 Etape 2 Etape 3 Dure totale

1 1 3 3 5 10

00:00:00,055 00:00:00,056 00:00:00,173 00:00:00,165 00:00:00,295 00:00:00,715


Tableau 22.

00:00:00,005 00:00:00,004 00:00:00,017 00:00:00,014 00:00:00,027 00:00:00,054

00:00:00,007 00:00:00,008 00:00:00,011 00:00:00,011 00:00:00,013 00:00:00,019

00:00:00,067 00:00:00,068 00:00:00,201 00:00:00,190 00:00:00,335 00:00:00,788

Deuxime test Temps dexcution dune requte utilisateur.

Les dures dexcution des requtes sont ici beaucoup plus courtes. La dure dexcution de lalgorithme de comparaison demeure quasi-constante, par rapport la premire srie de tests. La dure de chargement des services est cependant rduite denviron la moiti. Nous construisons le Tableau 23 afin dillustrer la comparaison entre les temps obtenus dans les deux sries de tests. A titre de repre, nous notons quentre les deux sries de tests, nous avons rduit la taille des fichiers services denviron 42,8%, en la diminuant de 84kb.
Gain Etape 1 Gain Etape 2 Gain Etape 3 Gain Total

Nombre de services 1 1 3 3 5 10

(en s) 00:00:00,160 00:00:00,106 00:00:00,271 00:00:00,296 00:00:00,492 00:00:00,818

(%) 74,42 65,43 61,04 64,21 62,52 53,36

(en s) 00:00:00,007 00:00:00,019 00:00:00,004 00:00:00,004 00:00:00,006 00:00:00,016

(%) 58,33 82,61 19,05 22,22 18,18 22,86

(en s) 00:00:00,060 00:00:00,006 00:00:00,007 00:00:00,005 00:00:00,003 00:00:00,026

(%) 89,55 42,86 38,89 31,25 18,75 57,78

(en s) 00:00:00,227 00:00:00,131 00:00:00,264 00:00:00,289 00:00:00,501 00:00:00,860

(%) 77,21 65,83 56,77 60,33 59,93 52,18

Tableau 23.

Comparaison entre les deux sries de tests.

Nous remarquons dimportantes rductions des temps dexcution pour lensemble des tests composant cette deuxime srie. Les rductions les plus considrables sont toutefois atteintes pour

Page 129

lEtape 1, autrement dit pour le chargement des descriptions de services (fichiers *.owl). En pourcentage, ces rductions sont toutefois suprieures la rduction de la taille de chaque fichier. La dure dexcution de notre algorithme se retrouve aussi amliore. Cette dure demeure la dure la plus courte entrant dans le calcul du temps dexcution final. Nous pouvons donc conclure quant la rapidit et lefficacit de notre algorithme. Son temps dexcution est rduit et ne reprsente quune faible partie (en dessous de 8%) du temps dexcution total. Nous soulignons le fait que ce sont les temps de chargement des fichiers qui sont les plus importants. Cela reprsente le temps ncessaire au programme pour rcprer les valeurs des diffrentes proprits contextuelles des services. Pour rduire ces temps, nous envisageons une tude approfondie des requtes SPARQL. La cl rside en effet dans une formulation efficace de ces requtes. A la manire des requtes SQL, celles-ci doivent tre optimises pour permettre une rduction supplmentaire de ces temps. Cela dit, les temps obtenus lors de ces deux sries de tests sont tout fait corrects, et nempchent pas lutilisation de notre prototype dans un environnement mobile. En rduisant la taille des fichiers, nous arrivons rduire lensemble de ces temps en dessous dune seconde, ce qui semble adquat pour un temps dattente en environnement mobile.

7.1.2 MESURES DE PERTINENCE


Les mesures prsentes ci-dessus prouvent la rapidit de notre algorithme. Nous voulons cependant noter quil ne sagit pas de son seul avantage. Tel que le remarquent les auteurs de (EUZENAT 2007), la plupart des algorithmes permettant lappareillement dontologies chouent dans la comprhension des concepts, et ds lors ne permettent pas dobtenir des rsultats solides et pertinents. Lintrprtation et la comprhension des concepts dmeurent dans la tte du dveloppeur, et il est quasi impossible de programmer un ordinateur afin dapprendre ces concepts. Notre algorithme pallie ces manquements, et permet de retourner une liste ordonne de services pertinents par rapport la requte de lutilisateur. Afin de mesurer la qualit de lalgorithme, nous devons nous intresser aux cots et aux bnfices quil implique pour lutilisateur final. Le renvoi dun rsultat pertinent reprsente un avantage (ou un bnfice) pour lutilisateur, tandis quun rsultat hors sujet a un certain cot pour lutilisateur (notamment le temps pass lire une information non pertinente). Le bnfice dun rsultat dpend de sa position sur la liste de rsultats renvoye lutilisateur. Les rsultats situs au dbut de la liste sont ds lors trs importants, car il est trs probable que lutilisateur les lise ou traite. Un rsultat pertinent situ au dbut dune telle liste apporte un plus grand bnfice, quun rsultat pertinent situ vers la fin de la liste. De la mme manire, un rsultat non-pertinent plac en haut dune telle liste reprsente un cot, lui aussi plus important que si ce mme rsultat aurait t plac vers la fin de la liste. En outre, plus le nombre de rsultats nonpertinents est important et plus ces rsultats se retrouvent en tte de liste, moins lutilisateur aura envie de parcourir la liste dans son ensemble, pour peut-tre dcouvrir dhypothtiques rsultats pertinents. Aussi, il existe un cot associ au non-renvoi dun rsultat pertinent. Nous souhaitons aussi valuer le degr de prcision de notre algorithme. Cette mesure est utile car elle prend des valeurs comprises dans lintervalle [0;1], et qui peuvent ainsi tre compares des mesures similaires pour dautres algorithmes. La prcision est une mesure qui permet de statuer

Page 130

quant lutilit dune liste de rsultats (MAHESH 2001). La prcision de lalgorithme est dfinie de la manire suivante(MAHESH 2001):

Or, nous avons conu notre algorithme de manire prendre en compte lensemble des services prsents dans le registre, pour un profil de service donn. Si nous prennons lexemple dune requte utilisateur prcisant que ce dernier est la recherche de restaurants de type brasserie , lalgorithme ne va pas ignorer les services restaurants ayant dautres catgories que Brasserie . Lalgorithme calcule un score pour chaque service de type restaurant , et retourne une liste de services classs selon leur score dcroissant. Si dans sa requte lutilisateur a affect une pondration importante au critre catgorie du restaurant , il y a de fortes chances que parmi les premiers rsultats retourns, il y en ait qui soient du type Brasserie . Il est ds lors difficile dutiliser comme seul indicateur, la mesure de prcision telle que dfinie plus haut. Nous souhaitons appliquer une nouvelle mesure, appele prcision moyenne, qui est un indicateur idal pour les moteurs de recherche (ZHU 2004). La prcision moyenne est dfinie de la manire suivante (MAHESH 2001) : Soit N le nombre dlments dans la liste de rsultats ; Soit R[i] le ime rsultat dans la liste de rsultats ; Soit P[i]=1, si le R[i] est pertinent, sinon P[i]=0 ; Soit P le nombre de services du registre, pertinents par rapport la requte initiale.
..

..

Pour pouvoir calculer cette valeur, nous creons plusieurs descriptions de services restaurants, chacune avec des caractristiques diffrentes. Elles sont dtailles dans le Tableau 24.
Attribut contextuel Service 1 Service 2 Service 3 Service 4 Service 5 Service 6 Service 7

Catgorie du restaurant Style de cuisine Places de parking disponibles Tables disponibles Climatisation Accs handicaps Prix du repas

Trad29. Fr31. 4 2 OUI OUI 20

Rapide Europe 10 2 NON OUI 13

Brasserie Fr. 0 4 OUI OUI 10

Trad. Europe 6 3 OUI OUI 35

Pizza Europe 0 6 NON NON 15

Gast30. Fr. 7 5 OUI NON 30

A Thme Fr. 15 10 NON OUI 14

Tableau 24.

Valeurs des attributs contextuels des services crs.

29 30

Traditionnel Gastronomique 31 Franaise


Page 131

Nous creons ensuite deux requtes utilisateur diffrentes, telles quillustres par le Tableau 25 et le Tableau 26. Attribut contextuel CategorieRestaurant StyleCuisine Places_Parking_Disponibles Places_Tables_Disponibles Climatisation AccesHandicapes PrixRepas
Tableau 25.

aQuantificateur OUI OUI NON

aPonderation 5 1 5 4 3 1 2

aValeur Trad. Europe 2 4 OUI NON 25

Requte utilisateur TEST1.

Attribut contextuel CategorieRestaurant StyleCuisine Places_Parking_Disponibles Places_Tables_Disponibles Climatisation AccesHandicapes PrixRepas


Tableau 26.

aQuantificateur OUI OUI NON

aPonderation 1 5 1 5 1 1 5

aValeur Trad. Franaise 2 2 NON NON 15

Requte utilisateur TEST2.

Nous appliquons finalement notre algorithme, pour chacune des deux requtes utilisateur. Les scores de chaque service sont lists ci-dessous (Tableau 27). La liste de services retourne par le programme est illustre par le Tableau 28.
Requte utilisateur Service 1 (S1) Service 2 (S2) Service 3 (S3) Service 4 (S4) Service 5 (S5) Service 6 (S6) Service 7 (S7)

TEST1 TEST2

-3 11
Tableau 27.

-3 1
er

4 7
me me

-1 18
me me

5 20
me me

7 22

9 21

Scores des services pour chacune des deux requtes test. 1 2 3 4 5 6 7

Requte utilisateur

TEST1 TEST2
Tableau 28.

S7 S6

S6 S7

S5 S5

S3 S4

S4 S1

S2 S3

S1 S2

Liste ordonne des services retourne pour chaque requte test.

Nous calculons ensuite les valeurs de prcision et de prcision moyenne pour les deux listes de rsultats ainsi obtenues. Pour ce faire, nous devons dfinir une rgle permettant de statuer sur la pertinence dun rsultat donn. Nous choisissons dappliquer la rgle suivante : 2

Nous commenons par appliquer cette dfinition pour calculer les valeurs de prcision associes aux deux requtes, TEST1 et TEST2. 3 7 0,43

Page 132

5 7

0,71

Pour un mme algorithme, nous obtenons deux prcisions diffrentes. Do lintrt de calculer une prcision moyenne. Selon la dfinition de la prcision moyenne donne plus haut, nous avons les valeurs suivantes : N=7 1 , 0 Nombre de services pertinents par rapport la requte TEST1 PTEST1 = 3 Nombre de services pertinents par rapport la requte TEST2 PTEST2 = 5 Pour le calcul de la prcision moyenne, nous devons calculer la prcision de chaque rsultat. Nous reportons les rsultats de nos calculs dans le tableau suivant.
TEST 1
er

me

me

me

me

me

me

TEST1

R[i] SCORE(R[i]) P[i] Prcision[i] Prcision moyenne

S7 9 1 1

S6 7 1 2 2
..

S5 5 1 3 3 S5 20 1 3 3

S3 4 0 3 4 3 S4 18 1 4 4 5

S4 -1 0 3 5

S2 S1 -3 -3 0 0 3 3 6 7 3 1 3 S3 S2 7 1 0 0 5 5 6 7 5 1 5

TEST2

R[i] SCORE(R[i]) P[i] Prcision[i] Prcision moyenne

S6 22 1 1

S7 21 1 2 2
..

S1 11 1 5 5

Tableau 29.

Calcul de la prcision moyenne.

Nous observons que cette fois-ci, les deux valeurs obtenues sont identiques, ce qui est logique tant donn le fait que nous testons le mme algorithme. De plus, nous obtenons une valeur de 1, ce qui veut dire que notre algorithme renvoie lensemble des rsultats pertinents, par rapport une requte donne, et prsents dans le registre. Cette mesure indique aussi le fait que notre algorithme ordonne parfaitement les rsultats, selon leur degr de pertinence.

7.2 MESURES RELATIVES A LUTILISATEUR FINAL


Jusquici, nous avons voques des mesures relatives lalgorithme de comparaison lui-mme. Nous nous intressons maintenant aux mesures permettant lvaluation de lexprience utilisateur. Or, le dveloppement de linterface Utilisateur Final ntant pas encore abouti, nous ne pouvons quvoquer ces mesures titre informatif. Elles seront intgres lvaluation de lapplication finale, et font ds lors partie des perspectives applicatives de notre prototype. Une premire mesure concerne les informations demandes lutilisateur (EUZENAT 2007). Cette mesure concerne notre application puisque, lors de la cration de la requte utilisateur, nous

Page 133

demandons lutilisateur dentrer des informations. Il sagit de dterminer si cette quantit informations. dinformations peut tre optimise ou rduite, mais aussi de voir comment cela affcte lexprience de lutilisateur. 2007). Il sagit ensuite dvaluer le niveau de satisfaction global de lutilisateur (EUZENAT 2007) Nous devons prendre en compte des indicateurs tels la rapidit de lapplication, la consommation de indicateurs, ressources, la comprhension des rsultats, ainsi que de lapplication globale, ou encore les niveaux dutilit et dusabilit de lapplication (B. SENACH 1990). En effet, alors que lutilit dune application sabilit indique si cette dernire permet lutilisateur datteindre ses objectifs, lusabilit dune application est une mesure la frontire entre utilit potentielle et utilit relle (B. SENACH 1990) Lusabilit e 1990). dune application ne dpend pas des caractristiques locales de lapplication, mais bien de ses proprits gnrales. Pour ce faire, des tudes doivent tre menes auprs dune population doivent dutilisateurs tests. Cette population devra tre dfinie en faisant attention des critres tels que lge, le sexe ou encore la catgorie socio professionnelle de lutilisateur. Ces critres nous socio-professionnelle permettront didentifier le niveau dacceptation ou de comprhension de lapplication, par rapport ifier diffrents types dutilisateurs.

7.3 CONCLUSION
La Figure 61 liste quelques unes des mesures que nous souhaitons utiliser lors de lvaluation de lapplication. Pour dterminer lutilit de notre application, nous utilisons des mesures des performances systme, telles les mesures de rapidit et de pertinence prsentes dans la soussection 7.1. Pour stimer lusabilit de notre application, nous devons estimer la facilit . notre dapprentissage, la facilit dutilisation ou encore la qualit de la documentation mise disposition de lutilisateur final (mode demploi, questions frquemment poses, etc.) (B. SENACH 1990) 1990).

Figure 61.

Mesures de lutilit et de lusabilit dune application (B. SENACH 1990) 1990).

Page 134

Ces deux types de mesures (mesures de lutilit et mesures de lusabilit) reprsentent des mesures complmentaires. Les mesures de lutilit comprennent des mesures des performances, alors que les mesures de lusabilit concernent des mesures subjectives. Les diffrentes mesures mentionnes ci-dessus posent plusieurs problmes, notamment au niveau de leur validit, de leur fidlit ou encore au niveau de leur prcision. En effet, lvaluation dune application est toujours dirige par le contexte. Le choix de mesures pertinentes pour un diagnostic de qualit ergonomique dpend non seulement des objectifs de lvaluation, mais aussi des caractristiques de la population et des exigences des tches (B. SENACH 1990). Par exemple, la qualit de linterface est essentielle pour certaines applications, alors que dautres ont pour facteur critique le temps dexcution. Notre premier dfi sera de choisir des mesures judicieuses, en fonction du contexte dutilisation de notre application. Il sagit ensuite dintgrer ces mesures lexprience utilisateur de notre application. Notre deuxime dfi sera de recueillir et danalyser des donnes comportementales, rendant compte de lutilisation de lapplication. Cette tape nous permettra didentifier les difficults rencontres par les utilisateurs, puis de dvelopper des solutions pour les rduire.

Page 135

CHAPITRE 8. CONCLUSION GENERALE ET PERSPECTIVES


Dans la vision du Web de demain, les tches seront automatises et transparentes pour l'utilisateur. Contrairement aux paradigmes traditionnels, notamment client-serveur, o linformation est centralise par un serveur, le paradigme de linformatique ubiquitaire sous-entend une omniprsence de rseaux de communication et dlments logiciels et matriels. Dans un tel environnement, les utilisateurs se retrouvent au centre des applications. Munis de terminaux mobiles, ils excutent des services, subordonns aux ressources et/ou services disponibles. Chacun de ces services est caractris par des besoins fonctionnels et non-fonctionnels, exprims souvent en termes de fiabilit ou performance. Il est ds lors vident que satisfaire lensemble des besoins caractrisant un service, dans un environnement hautement htrogne et dynamique, reprsente une tche difficile. Pour intgrer les ressources fournies par lenvironnement, une des approches moderne consiste utiliser les smantiques pour la description de ces ressources. Lusage des smantiques permet de rendre ces ressources comprhensibles et manipulables par des ordinateurs. Dans la vision du Web smantique, les ontologies reprsentent le principal vecteur permettant de reprsenter et manipuler les annotations smantiques entourant les ressources et les connaissances. Hritant de l'htrognit du Web smantique, les ontologies sont donc nombreuses et varies. Les travaux de recherche prsents ici ont t mens autour dune problmatique qui trouve son origine dans cette htrognit. En effet, les techniques traditionnelles de recherche dinformations ne suffisent plus face la diversit et au nombre croissant dinformations disponibles aujourdhui sur le Web. Dans notre approche, nous avons choisi les ontologies afin de modliser un service en termes de besoins non-fonctionnels. Le modle de base des services Web permet de rpondre aux problmes dinteroprabilit, mais ne permet pas une dcouverte automatique de ces services. Ce sont principalement les standards WSDL et UDDI qui sont aujourdhui utiliss pour dfinir les fonctionnalits des services, et ce de manire syntaxique. Ces descriptions suffisent pour des applications prconues , mais ne permettent pas aux ordinateurs de comprendre les informations ainsi dcrites. Cest lannotation des services Web traditionnels avec des smantiques qui a permis la cration de services Web smantiques. Afin d'atteindre le but vis dans ce travail de recherche, nous avons propos un modle ontologique pour la description des services Web smantiques. Sur la base de ce modle, nous avons ensuite dvelopp une plate-forme pour la recherche et la dcouverte de services ainsi dcrits. Cette plateforme introduit donc des fonctionnalits qui sont actuellement absentes dans les travaux concernant la description et la dcouverte de services Web smantiques. Il s'agit d'abord du modle dcrivant les attributs contextuels du service, mais aussi d'un protocole de dcouverte de services faisant appel ces attributs contextuels. Notre modle de description de services impose une structure cohrente pour l'ensemble des services. Non seulement ce modle facilite l'analyse et le traitement des descriptions de services, mais il permet aussi la cration d'interfaces utilisateur intuitives. Des interfaces bases sur ce modle
Page 136

permettent la cration de descriptions de services et de requtes, profitant la fois aux fournisseurs de services et aux utilisateurs finaux. Lutilisateur peut affecter diffrentes pondrations ses critres de recherche, et notre algorithme intgre ces pondrations dans la recherche du service le plus pertinent. En plus de permettre la construction d'une telle interface, le modle de description de service fait le lien avec des ontologies spcifiques des domaines prcis, et permet dincorporer les termes de ces ontologies dans la description du service. L'utilisateur final obtient donc des rsultats plus complets et prcis, que c'est le cas pour la recherche base de mots-cls. En outre, le fournisseur de services a sa disposition un outil lui permettant de fournir des descriptions de services utilisant un mme vocabulaire, sans avoir besoin de traduire chaque description de service. Enfin, dans la dernire partie de ce manuscrit, nous avons prsent une valuation de notre prototype, plus particulirement une valuation des temps associs lexcution dune requte utilisateur. La discussion qui clt cette thse est une opportunit didentifier les perspectives applicatives et acadmiques, des travaux de recherche prsents ici.

8.1 PERSPECTIVES
8.1.1 PERSPECTIVES APPLICATIVES
Cette section a pour but de discuter les quelques lacunes du prsent prototype, dans le cadre d'ventuels travaux futurs, qui permettraient de les rsoudre. En effet, dans les travaux de recherche discuts dans ce manuscrit, nous nous sommes concentrs sur la description des proprits nonfonctionnelles dun service et sur la dcouverte de services intgrant ces proprits. Limplmentation de notre modle peut toutefois tre amliore, en intgrant notamment les lments suivants : Donner un fournisseur de services la possibilit dajouter une catgorie de services, dans la taxonomie dj prsente en effet, linterface fournisseur de service permet de crer des descriptions de services conformes notre modle, mais ne permet pas dajouter une nouvelle catgorie de services ce modle. Stocker les prfrences utilisateur dans un profil utilisateur pour linstant, chaque nouvelle requte, lutilisateur doit saisir ses prfrences et ses pondrations. Il serait intressant de pouvoir stocker, dans un profil utilisateur, ces prfrences et pondrations, de manire faciliter la saisie dune requte. Le profil utilisateur contiendrait des requtes types, avec des valeurs et des pondrations prdfinies pour les catgories de services les plus recherches par lutilisateur. Optimiser lchange de donnes avec le terminal mobile en effet, lors des valuations de notre prototype, nous avons identifi la taille des fichiers comme le principal facteur impactant sur la dure dexcution dune requte. Plus la taille des fichiers changs est importante, plus le temps dexcution est long. Il sagit donc doptimiser ces envois et rceptions de fichiers, entre le terminal mobile et la plate-forme fixe. Lide serait de ne pas transfrer des fichiers OWL dcrivant entirement le service, mais de faire des requtes afin dobtenir seulement les informations ncessaires (notamment les valeurs des proprits non-fonctionnelles telles ladresse, le nom ou le numro de tlphone). Ceci permettrait une

Page 137

implmentation beaucoup plus lgre et efficace de lapplication sur une plate-forme mobile. Il sagit aussi doptimiser la syntaxe des requtes SPARQL. Evaluer lexprience utilisateur il sagit dvaluer linterface homme-machine dcrite dans ce travail de recherche, travers les mesures suivantes: tablir un diagnostic dusage de lapplication, comparer les avantages et inconvnients de cette application par rapport des applications similaires, et enfin contrler lergonomie de lapplication. Enfin un dernier travail raliser concerne lautomation des requtes. Il serait intressant, lorsque lon affiche un itinraire dun point A vers un point B, de pouvoir gnrer automatiquement une requte pour un service Taxi , par exemple, avec comme paramtres les points de dpart et darrive. De cette manire, en visualisant litinraire, lutilisateur peut lancer une nouvelle recherche de services. Dautres considrations regardent lamlioration du registre de services, la fin du dveloppement de lapplication mobile, lamlioration de linterface serveur, puis lintgration des retours utilisateurs (dfinition dune population test, dfinition de questionnaires utilisateurs, traitement des retours, amlioration de lapplication en consquence).

8.1.2 PERSPECTIVES SCIENTIFIQUES


Notre approche reprsente un lien entre deux domaines : linformatique diffuse et les services Web. Dans ce manuscrit, nous avons expliqu comment les services Web peuvent tre modliss ou dcrits afin dintgrer leurs caractristiques non-fonctionnelles (ou contextuelles) dans leur dcouverte. Nous avons propos une approche permettant de constituer une description de service conforme notre modle et ceci partir de la description WSDL du service. Notre proposition est intressante car elle permet de profiter de la diversit de services existant actuellement, et nimplique pas un dpart de zro . A court terme, ce travail peut tre complt par limplmentation dun autre algorithme de comparaison, afin dvaluer lefficacit de notre algorithme. A long terme, plus de perspectives peuvent tre envisages. Nous pensons, par exemple, la dfinition et limplmentation de mcanismes permettant le dialogue ou la collaboration entre services. Une autre perspective concerne ltude dautres langages de description des services, plus particulirement lapproche WSMO, qui gagne en popularit aujourdhui. Nous pouvons aussi envisager lintroduction de raisonnements base de logique floue, qui aurait pour rsultat lamlioration de notre prototype en outil daide la dcision, et ce sur la base de requtes prcdentes de lutilisateur. Si, par exemple, lapplication dtermine que lutilisateur a souvent pour habitude de chercher un restaurant aux alentours de midi, lutilisateur se verra suggrer un restaurant, en fonction des paramtres quil dfinit habituellement dans ses requtes. La logique floue sera utilise afin de crer des rgles permettant dinterprter les habitudes de lutilisateur, par rapport un contexte donn (position gographique, intervalle de temps, etc.). Finalement, lensemble des contributions prsentes ici a t introduit dans le dveloppement de la plate-forme TransportML (ROXIN et al. 2009). Le but de cette plate-forme sera de rendre automatique la dcouverte de services Web, sur la base du modle de description propos dans ce manuscrit. Ce modle sera aussi utilis afin de favoriser la collaboration entre les diffrents services.

Page 138

ANNEXES
Annexe A Modle OWL-S tendu (extraits de lontologie) ___________________________ 140 Annexe B. Fichiers du moteur dcouverte _________________________________________ 145
SimpleEngine.java _____________________________________________________________________ 145

Annexe C. Fichiers de l'interface Fournisseur de services ___________________________ 149


ManipulerOWL.owl ____________________________________________________________________ 149 CreateOWL.java ______________________________________________________________________ 157 Recupservice.java _____________________________________________________________________ 160 Serviceont.java _______________________________________________________________________ 161 Extrait dun fichier OWL gnr __________________________________________________________ 162

Annexe D. Fichiers de l'interface Utilisateur final _________________________________ 164


AndroidManifest.xml __________________________________________________________________ 164 res/layout/details.xml _________________________________________________________________ 164

Page 139

ANNEXE A MODELE OWL-S ETENDU (EXTRAITS DE LONTOLOGIE)


<?xml version="1.0"?>

<!DOCTYPE rdf:RDF [ <!ENTITY owl "http://www.w3.org/2002/07/owl#" > <!ENTITY swrl "http://www.w3.org/2003/11/swrl#" > <!ENTITY dc "http://purl.org/dc/elements/1.1/" > <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" > <!ENTITY owl2xml "http://www.w3.org/2006/12/owl2-xml#" > <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" > <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" > <!ENTITY time-entry "http://www.isi.edu/~pan/damltime/time-entry.owl#" > <!ENTITY Service "http://www.daml.org/services/owl-s/1.2/Service.owl#" > <!ENTITY Country "http://www.daml.org/services/owl-s/1.2/Country.owl#" > <!ENTITY Profile "http://www.daml.org/services/owl-s/1.2/Profile.owl#" > <!ENTITY Process "http://www.daml.org/services/owl-s/1.2/Process.owl#" > <!ENTITY Grounding "http://www.daml.org/services/owl-s/1.2/Grounding.owl#" > <!ENTITY drsonto040520 "http://cs-www.cs.yale.edu/homes/dvm/daml/drsonto040520.owl#" > <!ENTITY ObjectList "http://www.daml.org/services/owl-s/1.2/generic/ObjectList.owl#" > <!ENTITY Expression "http://www.daml.org/services/owl-s/1.2/generic/Expression.owl#" > <!ENTITY ProfileAdditionalParameters "http://www.daml.org/services/owls/1.2/ProfileAdditionalParameters.owl#" > <!ENTITY Ontology1239957158891 "http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#" > ]>

<rdf:RDF xmlns="http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#" xml:base="http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl" xmlns:owl2xml="http://www.w3.org/2006/12/owl2-xml#" xmlns:Process="http://www.daml.org/services/owl-s/1.2/Process.owl#" xmlns:drsonto040520="http://cs-www.cs.yale.edu/homes/dvm/daml/drsonto040520.owl#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:time-entry="http://www.isi.edu/~pan/damltime/time-entry.owl#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:ProfileAdditionalParameters="http://www.daml.org/services/owls/1.2/ProfileAdditionalParameters.owl#" xmlns:ObjectList="http://www.daml.org/services/owl-s/1.2/generic/ObjectList.owl#" xmlns:Profile="http://www.daml.org/services/owl-s/1.2/Profile.owl#" xmlns:Service="http://www.daml.org/services/owl-s/1.2/Service.owl#" xmlns:Expression="http://www.daml.org/services/owl-s/1.2/generic/Expression.owl#" xmlns:Country="http://www.daml.org/services/owl-s/1.2/Country.owl#" xmlns:swrl="http://www.w3.org/2003/11/swrl#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:Ontology1239957158891="http://www.semanticweb.org/ontologies/2009/3/Ontology12399571 58891.owl#" xmlns:Grounding="http://www.daml.org/services/owl-s/1.2/Grounding.owl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <owl:Ontology rdf:about=""/> <!-/////////////////////////////////////////////////////////////////////////////////////// // // Object properties // /////////////////////////////////////////////////////////////////////////////////////// -->
Page 140

<!-- http://www.daml.org/services/owl-s/1.2/Service.owl#aContexte --> <owl:ObjectProperty rdf:about="&Service;aContexte"> <rdfs:range rdf:resource="&Service;ServiceContext"/> <rdfs:domain rdf:resource="&Service;ServiceProfile"/> </owl:ObjectProperty> <!-- http://www.daml.org/services/owl-s/1.2/Service.owl#vend --> <owl:ObjectProperty rdf:about="&Service;vend"> <rdfs:range rdf:resource="&Service;Produit"/> <rdfs:domain rdf:resource="&Service;Service_Achat_Produit"/> </owl:ObjectProperty> <!-/////////////////////////////////////////////////////////////////////////////////////// // // Data properties // /////////////////////////////////////////////////////////////////////////////////////// -->

<!-- http://www.daml.org/services/owl-s/1.2/Service.owl#aQuantificateur --> <owl:DatatypeProperty rdf:about="&Service;aQuantificateur"> <rdfs:domain rdf:resource="&Service;ServiceContext"/> <rdfs:range rdf:resource="&xsd;boolean"/> </owl:DatatypeProperty> <!-- http://www.daml.org/services/owl-s/1.2/Service.owl#aValeur --> <owl:DatatypeProperty rdf:about="&Service;aValeur"> <rdfs:comment xml:lang="fr" >Cette propriete permet de definir la valeur dun element du contexte service.</rdfs:comment> <rdfs:domain rdf:resource="&Service;ServiceContext"/> </owl:DatatypeProperty> <!-- http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#aAdresse --> <owl:DatatypeProperty rdf:about="#aAdresse"> <rdfs:comment xml:lang="fr" >Cette propri&#233;t&#233; permet de d&#233;finir l&#39;adresse d&#39;un service.</rdfs:comment> <rdfs:domain rdf:resource="&Service;ServiceProfile"/> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty>

<!-- http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#aPonderation -> <owl:DatatypeProperty rdf:about="#aPonderation"> <rdf:type rdf:resource="&owl;FunctionalProperty"/> <rdfs:comment xml:lang="fr" >Permet de pond&#233;rer les diff&#233;rentes propri&#233;t&#233;s d&#39;un service.</rdfs:comment> <rdfs:domain rdf:resource="&Service;ServiceContext"/> <rdfs:range rdf:resource="&xsd;float"/> </owl:DatatypeProperty>

<!-- http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#aTelephone --> <owl:DatatypeProperty rdf:about="#aTelephone">

Page 141

<rdfs:comment xml:lang="fr" >Cette propri&#233;t&#233; permet de d&#233;finir t&#233;l&#233;phone d&#39;un service.</rdfs:comment> <rdfs:domain rdf:resource="&Service;ServiceProfile"/> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty>

le

num&#233;ro

de

<!-/////////////////////////////////////////////////////////////////////////////////////// // // Classes // /////////////////////////////////////////////////////////////////////////////////////// --> <!-- http://www.daml.org/services/owl-s/1.2/Service.owl#CategorieRestaurant --> <owl:Class rdf:about="&Service;CategorieRestaurant"> <rdfs:subClassOf rdf:resource="&Service;Service_Restaurant_Context"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="&Service;aValeur"/> <owl:allValuesFrom rdf:resource="&xsd;string"/> </owl:Restriction> </rdfs:subClassOf> <dc:description xml:lang="fr" >Definit plusieurs categories de restaurants.</dc:description> </owl:Class> <!-- http://www.daml.org/services/owl-s/1.2/Service.owl#Places_Parking_Disponibles --> <owl:Class rdf:about="&Service;Places_Parking_Disponibles"> <rdfs:subClassOf rdf:resource="&Service;Service_Restaurant_Context"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="&Service;aValeur"/> <owl:allValuesFrom rdf:resource="&xsd;integer"/> </owl:Restriction> </rdfs:subClassOf> <dc:description xml:lang="fr" >Indique le nombre de places parking disponibles.</dc:description> </owl:Class>

<!-- http://www.daml.org/services/owl-s/1.2/Service.owl#Places_Tables_Disponibles --> <owl:Class rdf:about="&Service;Places_Tables_Disponibles"> <rdfs:subClassOf rdf:resource="&Service;Service_Restaurant_Context"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="&Service;aValeur"/> <owl:allValuesFrom rdf:resource="&xsd;integer"/> </owl:Restriction> </rdfs:subClassOf> <dc:description xml:lang="fr" >Indique le nombre de places/tables restantes dans restaurant.</dc:description> </owl:Class> <!-- http://www.daml.org/services/owl-s/1.2/Service.owl#ServiceContext --> <owl:Class rdf:about="&Service;ServiceContext"> <rdfs:subClassOf rdf:resource="&owl;Thing"/> </owl:Class> <!-- http://www.daml.org/services/owl-s/1.2/Service.owl#Service_Personnel -->
Page 142

le

<owl:Class rdf:about="&Service;Service_Personnel"> <rdfs:subClassOf rdf:resource="&Profile;Profile"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="&Service;aContexte"/> <owl:allValuesFrom rdf:resource="&Service;Service_Personnel_Context"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class>

<!-- http://www.daml.org/services/owl-s/1.2/Service.owl#Service_Personnel_Context --> <owl:Class rdf:about="&Service;Service_Personnel_Context"> <rdfs:subClassOf rdf:resource="&Service;ServiceContext"/> </owl:Class>

<!-- http://www.daml.org/services/owl-s/1.2/Service.owl#Produit --> <owl:Class rdf:about="&Service;Produit"> <rdfs:subClassOf rdf:resource="&owl;Thing"/> </owl:Class> <!-http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#AccesHandicapes --> <owl:Class rdf:about="#AccesHandicapes"> <rdfs:subClassOf rdf:resource="&Service;Service_Restaurant_Context"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="&Service;aValeur"/> <owl:allValuesFrom rdf:resource="&xsd;boolean"/> </owl:Restriction> </rdfs:subClassOf> <owl:incompatibleWith xml:lang="fr" >Indique si le restaurant dispose ou non dun acces handicapes.</owl:incompatibleWith> </owl:Class> <!-- http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#Climatisation --> <owl:Class rdf:about="#Climatisation"> <rdfs:subClassOf rdf:resource="&Service;Service_Restaurant_Context"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="&Service;aValeur"/> <owl:allValuesFrom rdf:resource="&xsd;boolean"/> </owl:Restriction> </rdfs:subClassOf> <owl:incompatibleWith xml:lang="fr" >Indique si le restaurant dispose ou pas dune climatisation.</owl:incompatibleWith> </owl:Class> <!-- http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#PrixRepas --> <owl:Class rdf:about="#PrixRepas"> <rdfs:subClassOf rdf:resource="&Service;Service_Restaurant_Context"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="&Service;aValeur"/> <owl:allValuesFrom rdf:resource="&xsd;integer"/> </owl:Restriction> </rdfs:subClassOf> <owl:incompatibleWith xml:lang="fr" >Definit le prix moyen dun repas pour le restaurant.</owl:incompatibleWith>
Page 143

</owl:Class>

Page 144

ANNEXE B. FICHIERS DU MOTEUR DECOUVERTE


SIMPLEENGINE.JAVA
public class SimpleEngine { public String textResults = ""; public String formatTime = "hh:mm:ss:SSS"; class ServiceScore { public Vector<Vector<String>> service; public Long score; public ServiceScore() { service = new Vector<Vector<String>>(); score = null; } } private OwlLoader loader; private Vector<Vector<String>> result; public SimpleEngine() { result = new Vector<Vector<String>>(); } public void loadEngine(String path, String servicePath) { loader = new OwlLoader(path, servicePath); } public void Compute() { System.out.println("Start Utils.DateTimeNow(formatTime));

computing!

Compute

start

time

is:

"

Vector<ServiceScore> results = algo1Implementation2((getServiceScoreForServiceName("Service_Restaurant"))); Iterator<ServiceScore> i = results.iterator(); int k = 0; while (i.hasNext()) { String txtTemp = "Service " + ++k + " a le score: " + i.next().score + " <br/>"; textResults += txtTemp; } System.out.println("Stop Computing! Compute end time is : " + Utils.DateTimeNow(formatTime) ); }

public Vector<ServiceScore> getServiceScoreForServiceName(String serviceName) { Vector<ServiceScore> vss = new Vector<ServiceScore>(); ManipulerXML manipXML = new ManipulerXML(Config.BASE_INDEX_FILES); System.out.println(serviceName); String[] fileList = new String[10]; fileList = manipXML.getFileListArray(serviceName); System.out.println("trouvee : " + fileList.length + " fichiers"); if (fileList.length == 0) { textResults = "There are no registered services!"; }

for (int i = 0; i < fileList.length; i++) {

Page 145

System.out.println("File "+Utils.DateTimeNow(formatTime));

"+fileList[i]+"

started

to

load

at:

ServiceScore ss = new ServiceScore(); ManipulerOWL manipOWL = new Config.BASE_SERV_ONTOLOGY_PATH + fileList[i]); System.out.println("File "+fileList[i]+" Utils.DateTimeNow(formatTime)); ManipulerOWL("file:///" end load at : " + +

List<PropertyService> serviceProps = manipOWL.getPropertyService(serviceName, manipOWL.getInternalModel()).get(0).getProps(); System.out.println("File "+Utils.DateTimeNow(formatTime)); "+fileList[i]+" start query at :

for (int j = 0; j < serviceProps.size(); j++) {

String values[] = new String[2]; values = serviceProps.get(j).getName().toString()); manipOWL.getValuePropertyService(serviceName,

String propertyName = values[0]; String propertyValue = values[1]; Vector<String> vs = new Vector<String>(); vs.add(propertyName); vs.add(propertyValue); ss.service.add(vs); } System.out.println("File "+Utils.DateTimeNow(formatTime)); vss.add(ss); } return vss; } public Vector<ServiceScore> algo1Implementation2(Vector<ServiceScore> services) { System.out.println("Algoritm started at time : "+Utils.DateTimeNow(formatTime)); Iterator<ServiceScore> iService = services.iterator(); while (iService.hasNext()) { //niveau service ServiceScore ss = iService.next(); Iterator<Vector<String>> iVector = ss.service.iterator(); Long scoreService = Long.parseLong("0"); //pour retirer le +1 accorder pour le critere categorie restaurant while (iVector.hasNext()) { //niveau tableau service Vector<String> iServiceLine = iVector.next(); Iterator<String> iString = iServiceLine.iterator(); Long scoreLine = Long.parseLong("0"); while (iString.hasNext()) { //niveau champs String fieldName = iString.next(); String fieldValue = iString.next(); int i = 0; "+fileList[i]+" terminated query at :

Page 146

//on cherche le critere dans le userCriteria while (i < loader.getUserCriteria().size() loader.getUserCriteria().get(i).get(0).compareTo(fieldName) != 0) { i++;

&&

if (loader.getUserCriteria().get(i).get(0).compareTo(fieldName) == 0) { //************************************************************************************ scoreLine = computePropertyScore(fieldName, fieldValue, i); //************************************************************************************ } } } scoreService += scoreLine; } ss.score = scoreService; } System.out.println("Algoritm ended at time : "+Utils.DateTimeNow(formatTime)); return services; }

public Long criteriaIndice) {

computePropertyScore(String

fieldName,

String

fieldValue,

int

if (fieldValue.compareTo("TRUE") == 0 || fieldValue.compareTo("FALSE") == 0) { //boolean value if (loader.getUserCriteria().get(criteriaIndice).get(1).compareTo(fieldValue) == 0) { return Long.parseLong(loader.getUserCriteria().get(criteriaIndice).get(3)); } }

if (isLong(fieldValue)) { if ((loader.getUserCriteria().get(criteriaIndice).get(2).compareTo("TRUE") == 0 && Long.parseLong(fieldValue) / Long.parseLong(loader.getUserCriteria().get(criteriaIndice).get(1)) >= 1) || loader.getUserCriteria().get(criteriaIndice).get(2).compareTo("FALSE") == 0 && Long.parseLong(fieldValue) / Long.parseLong(loader.getUserCriteria().get(criteriaIndice).get(1)) <= 1) { return Long.parseLong(loader.getUserCriteria().get(criteriaIndice).get(3)) * Long.parseLong(fieldValue) / Long.parseLong(loader.getUserCriteria().get(criteriaIndice).get(1)); } else { return Long.parseLong("-1") * Long.parseLong(loader.getUserCriteria().get(criteriaIndice).get(3)) * Long.parseLong(fieldValue) / Long.parseLong(loader.getUserCriteria().get(criteriaIndice).get(1)); } } else { //ontology case if (loader.getUserCriteria().get(criteriaIndice).get(1).compareTo(fieldValue) == 0) { return Long.parseLong(loader.getUserCriteria().get(criteriaIndice).get(3)); } //for the subclass
Page 147

OntClass ont = loader.getInputModel().getOntClass(fieldValue); if (ont != null) { Iterator<OntClass> i = ont.listSubClasses(true); while (i.hasNext()) { if (i.next().getURI().compareTo(loader.getUserCriteria().get(criteriaIndice).get(1)) == 0) { return Long.parseLong(loader.getUserCriteria().get(criteriaIndice).get(3)) / 2; } } } return Long.parseLong("0"); } } public static boolean isLong(String st) { try { Long.parseLong(st); } catch (NumberFormatException e) { return false; } return true; } public Vector<ServiceScore> ResultSetToVectorServiceScore(Iterator it) { return null; } public static void main(String[] args) { SimpleEngine se = new SimpleEngine(); se.loadEngine("file:///"+Config.BASE_USR_ONTOLOGY_FILE, Config.BASE_MAIN_ONTOLOGY_FILE); se.Compute(); } } "file:///" +

Page 148

ANNEXE C. FICHIERS DE L'INTERFACE FOURNISSEUR DE SERVICES


MANIPULEROWL.OWL
public class ManipulerOWL { private String fileUrl; private Model model; public ManipulerOWL(){ } public ManipulerOWL(String fileUrl) { this.fileUrl = fileUrl; try{ loadModel(fileUrl); //System.out.println("Your file is: "+fileUrl); } catch(Exception e){ System.out.println(e); } } public ManipulerOWL(Model model){ this.model = model; } public Model getInternalModel(){ return this.model; } public String getFileUrl() { return fileUrl; } public void setFileUrl(String fileUrl) { this.fileUrl = fileUrl; } public void loadModel(String storageFile) throws Exception, ClassNotFoundException { if (storageFile == null) { throw new Exception("Missing Storage File"); } model = ModelFactory.createMemModelMaker().createDefaultModel(); InputStream in = FileManager.get().open(storageFile); //read the model model.read(in, null); in.close(); } public void loadModel(){ try { loadModel(this.fileUrl); } catch (Exception e){ System.out.println(e); } } public String getXMLAboutService(String serviceType, String serviceName){ String xmlStr = "";

Page 149

try { InputStream in = FileManager.get().open(this.fileUrl); Model model = ModelFactory.createMemModelMaker().createDefaultModel(); model.read(in, null); in.close(); String queryString = "PREFIX owl: <http://www.w3.org/2002/07/owl#> " + "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> " + "PREFIX prof: <http://www.daml.org/services/owl-s/1.2/Profile.owl#> " + "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> " + "PREFIX serv: <http://www.daml.org/services/owl-s/1.2/Service.owl#> " + "PREFIX xmlsch: <http://www.w3.org/2001/XMLSchema> " + "SELECT DISTINCT ?serviceContext ?property ?subClass ?valueType " + "WHERE {" + " serv:" + serviceName + " rdfs:subClassOf serv:"+serviceType+" ; " + // " a ?type ; " + " rdfs:subClassOf [ a owl:Restriction; owl:onProperty ?onProp; owl:allValuesFrom ?serviceContext]. " + " ?property rdfs:subClassOf ?serviceContext . " + " ?property rdfs:subClassOf [ a owl:Restriction; owl:onProperty ?onProp1; owl:allValuesFrom ?valueType]. " + " OPTIONAL { ?subClass rdfs:subClassOf ?property . }" + // " " }"; ?type2 a ?type3 ." +

Query query = QueryFactory.create(queryString); // Execute the query and obtain results QueryExecution qe = QueryExecutionFactory.create(query, model); ResultSet results = qe.execSelect(); xmlStr = ResultSetFormatter.asXMLString(results); qe.close(); } catch (Exception e) { e.printStackTrace(); } return xmlStr; } /* recuperer la liste des services */ public List<ServiceOwl> getService(Model localModel) { List<ServiceOwl> servs = new ArrayList<ServiceOwl>(); try { String queryString = "PREFIX owl: <http://www.w3.org/2002/07/owl#> " + "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> " + "PREFIX prof: <http://www.daml.org/services/owl-s/1.2/Profile.owl#>" +
Page 150

"PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>" + "PREFIX serv: <http://www.daml.org/services/owl-s/1.2/Service.owl#>" + "SELECT ?class " + "WHERE {" + " ?class rdfs:subClassOf prof:Profile . " + " }";

Query query = QueryFactory.create(queryString); // Execute the query and obtain results QueryExecution qe = QueryExecutionFactory.create(query, localModel); ResultSet results = qe.execSelect(); // Output query results qe.close(); while (results.hasNext()) { ServiceOwl ser = new ServiceOwl(); QuerySolution sol = results.nextSolution(); for (Object var : results.getResultVars()) { //System.out.println(sol.get(var.toString()).toString()); if (sol.get(var.toString()) != null) { ser.setURI(sol.get(var.toString().toString())); String str[] = ser.getURI().toString().split("#"); ser.setName(str[1].toString()); } } servs.add(ser); } } catch (Exception e) { e.printStackTrace(); } return servs; }

/* recuperer les services a partir d'un autre service */ public List<ServiceOwl> getService(String service, Model currentModel) { List<ServiceOwl> servs = new ArrayList<ServiceOwl>(); try { String queryString = "PREFIX owl: <http://www.w3.org/2002/07/owl#> " + "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> " + "PREFIX prof: <http://www.daml.org/services/owl-s/1.2/Profile.owl#>" + "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>" + "PREFIX serv: <http://www.daml.org/services/owl-s/1.2/Service.owl#>" + "SELECT ?subClass " + "WHERE {" + " ?subClass rdfs:subClassOf serv:" + service + ". " + " }";
Page 151

Query query = QueryFactory.create(queryString); // Execute the query and obtain results QueryExecution qe = QueryExecutionFactory.create(query, currentModel); ResultSet results = qe.execSelect(); // Output query results qe.close(); while (results.hasNext()) { ServiceOwl ser = new ServiceOwl(); QuerySolution sol = results.nextSolution(); for (Object var : results.getResultVars()) { if (sol.get(var.toString()) != null) { ser.setURI(sol.get(var.toString().toString())); String str[] = ser.getURI().toString().split("#"); ser.setName(str[1].toString()); } } servs.add(ser); } } catch (Exception e) { } return servs; } /* recuperer les proprietets des services */ public List<PropertyService> getPropertyService(String currentModel) {

ServiceName,

Model

List<PropertyService> propers = new ArrayList<PropertyService>(); try { String queryString = "PREFIX owl: <http://www.w3.org/2002/07/owl#> " + "PREFIX skos: <http://www.w3.org/2004/02/skos/core#> " + "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> " + "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>" + "PREFIX : <http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#> " + "SELECT DISTINCT ?subClass ?proper ?value " + "WHERE {" + " <http://www.daml.org/services/owl-s/1.2/Service.owl#" + ServiceName + "> rdfs:subClassOf ?y; " + " rdfs:subClassOf [ a owl:Restriction; owl:onProperty ?proper; owl:allValuesFrom ?value]. " + "}"; Query query = QueryFactory.create(queryString); QueryExecution qe = QueryExecutionFactory.create(query, currentModel); ResultSet results = qe.execSelect(); while (results.hasNext()) {

PropertyService prop = new PropertyService(); QuerySolution sol = results.nextSolution();


Page 152

for (Object var : results.getResultVars()) { if (sol.get(var.toString()) != null) { if (var.toString().equals("proper")) { prop.setURI(sol.get(var.toString())); String str[] = prop.getURI().toString().split("#"); prop.setName(str[1].toString()); } if (var.toString().equals("value")) { prop.setType(sol.get(var.toString()).toString()); String value = sol.get(var.toString()).toString(); prop.setType(value); String str1[] sol.get(var.toString().toString()).toString().split("#"); prop.setURIType(sol.get(var.toString())); if (str1[0].equals("http://www.w3.org/2001/XMLSchema")) { String str[] = prop.getURIType().toString().split("#"); prop.setType(str[1].toString()); } else { String str[] = prop.getURIType().toString().split("#"); prop.setType(str[1].toString()); prop.setProps(this.getPorService(prop.getType())); } } } } propers.add(prop); } // Output query results } catch (Exception e) { e.printStackTrace(); } return propers; } /// get property recursive public List<PropertyService> getPorService(String NameService) { List<PropertyService> props = new ArrayList<PropertyService>(); try { String queryString = "PREFIX owl: <http://www.w3.org/2002/07/owl#> " + "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> " + "PREFIX prof: <http://www.daml.org/services/owl-s/1.2/Profile.owl#>" + "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>" + "SELECT ?subClass ?proper ?value " + "WHERE {" + " ?subClass rdfs:subClassOf <http://www.daml.org/services/owls/1.2/Service.owl#" + NameService + ">; " + " rdfs:subClassOf [ a owl:Restriction; owl:onProperty ?proper; owl:allValuesFrom ?value].}";

Query query = QueryFactory.create(queryString);


Page 153

// Execute the query and obtain results QueryExecution qe = QueryExecutionFactory.create(query, model); ResultSet results = qe.execSelect(); // Output query results qe.close(); while (results.hasNext()) { PropertyService proser = new PropertyService(); QuerySolution sol = results.nextSolution(); for (Object var : results.getResultVars()) { if (sol.get(var.toString()) != null) { if (var.toString().equals("subClass")) { proser.setURI(sol.get(var.toString().toString())); String str[] = proser.getURI().toString().split("#"); proser.setName(str[1].toString()); } if (var.toString().equals("value")) { String str1[] sol.get(var.toString().toString()).toString().split("#"); if (str1[0].equals("http://www.w3.org/2001/XMLSchema")) { proser.setURIType(sol.get(var.toString().toString())); String str[] = proser.getURIType().toString().split("#"); proser.setType(str[1].toString()); } else { proser.setURIType(sol.get(var.toString().toString())); String str[] = proser.getURIType().toString().split("#"); proser.setType(str[1].toString()); } } proser.setProps(this.getPorServicecollection(proser.getName())); } } props.add(proser); } } catch (Exception e) { e.printStackTrace(); } return props; } //returner la collection public List<PropertyService> getPorServicecollection(String NameService) { List<PropertyService> props = new ArrayList<PropertyService>(); try { String queryString = "PREFIX owl: <http://www.w3.org/2002/07/owl#> " + "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> " + "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>" + "SELECT ?subClass " + "WHERE {" + " ?subClass rdfs:subClassOf <http://www.daml.org/services/owls/1.2/Service.owl#" + NameService + ">; " + " }";

Query query = QueryFactory.create(queryString);


Page 154

// Execute the query and obtain results QueryExecution qe = QueryExecutionFactory.create(query, model); ResultSet results = qe.execSelect(); // Output query results qe.close(); while (results.hasNext()) { PropertyService proser = new PropertyService(); QuerySolution sol = results.nextSolution(); for (Object var : results.getResultVars()) { if (sol.get(var.toString()) != null) {

proser.setURI(sol.get(var.toString().toString())); String str[] = proser.getURI().toString().split("#"); proser.setName(str[1].toString()); //System.out.println(proser.getName()); proser.setProps(this.getPorServicecollection(proser.getName())); } } props.add(proser); } } catch (Exception e) { e.printStackTrace(); } return props; } //-----------------------------------------------------------------------// //get values for service name in order to calculate the score of the service public String[] getValuePropertyService(String nameService, String propertyService) { String[] values = new String[2]; try { String queryString = "PREFIX owl: <http://www.w3.org/2002/07/owl#> " + "PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> " + "PREFIX prof: <http://www.daml.org/services/owl-s/1.2/Profile.owl#>" + "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>" + "PREFIX serv: <http://www.daml.org/services/owl-s/1.2/Service.owl#>"+ "SELECT ?type ?value " + "WHERE {" + " serv:hasvalue" + propertyService + " a ?type;" + " serv:aValeur ?value.}";

Query query = QueryFactory.create(queryString); // Execute the query and obtain results QueryExecution qe = QueryExecutionFactory.create(query, model); ResultSet results = qe.execSelect(); // Output query results qe.close(); while (results.hasNext()) { QuerySolution sol = results.nextSolution(); for (Object res : results.getResultVars()) { if (sol.get(res.toString()) != null) {
Page 155

Node valueNode = sol.get(res.toString()).asNode(); if (res.toString().equals("value")) { values[1] = valueNode.getLiteralValue().toString(); } else { values[0] = valueNode.getURI(); } } } } } catch (Exception e) { e.printStackTrace(); } //return props; return values; } }

Page 156

CREATEOWL.JAVA
package Servlet; import import import import import import import import import import OWL.ManipulerOWL; OWL.MODELONT; OWL.PropertyService; WSDL.ManipulerWsdl; java.io.IOException; java.io.PrintWriter; javax.servlet.ServletException; javax.servlet.http.HttpServlet; javax.servlet.http.HttpServletRequest; javax.servlet.http.HttpServletResponse;

import import import import import import import import import import import import import import import import import import import import import import import import import import import import import import import import import import import import

com.hp.hpl.jena.query.*; com.hp.hpl.jena.query.ResultSet; com.hp.hpl.jena.mem.ModelMem; com.hp.hpl.jena.ontology.OntClass; com.hp.hpl.jena.ontology.OntModel; com.hp.hpl.jena.ontology.Ontology; com.hp.hpl.jena.rdf.model.*; com.hp.hpl.jena.util.FileManager; com.hp.hpl.jena.vocabulary.*; java.io.File; java.io.FileInputStream; java.io.FileWriter; java.io.IOException; java.io.InputStream; java.io.PrintWriter; java.io.Reader; java.util.*; com.hp.hpl.jena.ontology.Individual; com.hp.hpl.jena.ontology.OntClass; com.hp.hpl.jena.ontology.OntModel; com.hp.hpl.jena.ontology.OntProperty; com.hp.hpl.jena.rdf.model.*; com.hp.hpl.jena.util.FileManager; com.hp.hpl.jena.rdf.model.Model; java.io.FileWriter; java.io.IOException; java.io.InputStream; java.io.PrintWriter; java.util.*; java.net.URI; java.net.URL; java.net.URLConnection; java.util.ArrayList; javax.servlet.ServletContext; javax.xml.registry.infomodel.User; org.mindswap.pellet.jena.PelletReasonerFactory;

public class CreateOWL extends HttpServlet {

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html");

Page 157

PrintWriter out = response.getWriter(); try { String serviceprof= request.getParameter("servicename").toString(); String inputFileName="Ontologie_Service_Profile_Hierarchy_150509.owl"; OntModel m = ModelFactory.createOntologyModel(); InputStream in = CreateOWL.class.getResourceAsStream(inputFileName); if (in == null) { throw new IllegalArgumentException( "File: " + inputFileName + " not found"); } // read the OWL file m.read(in, "");

List<PropertyService> props = new ArrayList<PropertyService>(); ManipulerOWL manip = new ManipulerOWL(this.getServletContext().getRealPath("/")+"Ontologie_Service_Profile_Hierarch y_150509.owl"); props = manip.getPropertyService(serviceprof).get(0).getPorps(); for (int i = 0; i < props.size(); i++) { // if (props.get(i).getSizeProperty()==0){ if (props.get(i).getType().equals("boolean")){ OntClass largeFormat = m.getOntClass( props.get(i).getURI().toString()); boolean varbool= true; if(request.getParameter(props.get(i).getName()).toString().equals("oui")){ varbool= true; } else{ varbool= false; } Iterator it = largeFormat.listDeclaredProperties(); while (it.hasNext()) { OntProperty prop = (OntProperty) it.next(); if (prop.getURI().equals("http://www.daml.org/services/owls/1.2/Service.owl#aValeur")) { Individual ind = m.createIndividual("http://www.daml.org/services/owls/1.2/Service.owl#hasvalue"+props.get(i).getName().toString(),largeFormat); ind.addLiteral(prop, varbool);

} } } if (props.get(i).getType().equals("integer")){ OntClass largeFormat = m.getOntClass(props.get(i).getURI().toString()); int nbr Integer.parseInt(request.getParameter(props.get(i).getName()).toString());


Page 158

Iterator it = largeFormat.listDeclaredProperties(); while (it.hasNext()) { OntProperty prop = (OntProperty) it.next(); if (prop.getURI().equals("http://www.daml.org/services/owls/1.2/Service.owl#aValeur")) { Individual ind = m.createIndividual("http://www.daml.org/services/owls/1.2/Service.owl#hasvalue"+props.get(i).getName().toString(),largeFormat); ind.addLiteral(prop, nbr);

} } } if (props.get(i).getType().equals("string")){ OntClass largeFormat = m.getOntClass( props.get(i).getURI().toString()); String str = request.getParameter(props.get(i).getName()).toString(); Iterator it = largeFormat.listDeclaredProperties(); while (it.hasNext()) { OntProperty prop = (OntProperty) it.next(); if (prop.getURI().equals("http://www.daml.org/services/owls/1.2/Service.owl#aValeur")) { Individual ind = m.createIndividual("http://www.daml.org/services/owls/1.2/Service.owl#hasvalue"+props.get(i).getName().toString(),largeFormat); ind.addLiteral(prop, str); } } } OntClass service = s/1.2/Service.owl#ServiceProfile"); m.getOntClass("http://www.daml.org/services/owl-

OntProperty proper = m.getOntProperty("http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#a Telephone"); String tele = request.getParameter("telephone").toString(); Individual ind = m.createIndividual("http://www.daml.org/services/owls/1.2/Service.owl#hasvaluetelephone",service); ind.addLiteral(proper, tele); OntProperty properadrres = m.getOntProperty("http://www.semanticweb.org/ontologies/2009/3/Ontology1239957158891.owl#a Telephone"); String adresse = request.getParameter("adresse").toString(); Individual indadrees m.createIndividual("http://www.daml.org/services/owls/1.2/Service.owl#hasvalueadresse",service); indadrees.addLiteral(properadrres, adresse); =

FileWriter fileWriter = new FileWriter(getServletContext().getRealPath("/") File.separator + "WEB-INF" + File.separator + "text1.owl"); m.write(fileWriter, "RDF/XML-ABBREV");

// }
Page 159

} out.println("Le fichier est genere"); } catch (Exception e) { out.println(e.getMessage()); } } }

RECUPSERVICE.JAVA
package Servlet; import WSDL.ManipulerWsdl; import import import import javax.servlet.ServletException; javax.servlet.http.HttpServlet; javax.servlet.http.HttpServletRequest; javax.servlet.http.HttpServletResponse;

import javax.servlet.RequestDispatcher; import javax.servlet.ServletContext; import org.apache.commons.fileupload.*; import import import import public org.apache.commons.fileupload.disk.*; org.apache.commons.fileupload.servlet.*; java.util.*; java.io.*; class Recupservice extends HttpServlet {

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); try { String nom=""; /** l'enregistrement du photo du site out.println("oui save file"); */

boolean isMultipart = ServletFileUpload.isMultipartContent(request); FileItemFactory factory = new DiskFileItemFactory(); ServletFileUpload upload = new ServletFileUpload(factory); List items = upload.parseRequest(request);

Iterator iter = items.iterator(); while (iter.hasNext()) { FileItem item = (FileItem) iter.next(); if (item.isFormField()) { String fieldName = item.getFieldName(); if(fieldName.equals("name")) System.out.println(fieldName); } else {

Page 160

File fullFile = new File(item.getName()); nom=fullFile.getName(); File savedFile = File(this.getServletContext().getRealPath("/")+"service\\", fullFile.getName()); out.println(this.getServletContext().getRealPath("/")+"service\\"+fullFile.getName()); item.write(savedFile); } } out.println("oui save file"); ManipulerWsdl manp = ManipulerWsdl(this.getServletContext().getRealPath("/")+"service\\"+nom); manp.getWSDLService().getName(); new new

ServletContext sc = this.getServletContext(); RequestDispatcher rd sc.getRequestDispatcher("/recepservice?nameserv="+manp.getWSDLService().getName()); rd.forward(request, response); } catch (Exception e) { out.println(e.getMessage()); } } }

SERVICEONT.JAVA
public class serviceont extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); try { String nom=""; /** l'enregistrement du photo du site out.println("Oui, sauvegarder fichier"); */

boolean isMultipart = ServletFileUpload.isMultipartContent(request); FileItemFactory factory = new DiskFileItemFactory(); ServletFileUpload upload = new ServletFileUpload(factory); List items = upload.parseRequest(request); Iterator iter = items.iterator(); while (iter.hasNext()) { FileItem item = (FileItem) iter.next(); if (item.isFormField()) { String fieldName = item.getFieldName(); if(fieldName.equals("name")) System.out.println(fieldName);

Page 161

} else { File fullFile = new File(item.getName()); nom=fullFile.getName(); File savedFile = File(this.getServletContext().getRealPath("/")+"service\\", fullFile.getName()); out.println(this.getServletContext().getRealPath("/")+"service\\"+fullFile.getName()); item.write(savedFile); } } out.println("Oui, sauvegarder fichier"); InputStream in = serviceont.class.getResourceAsStream(nom); if (in == null) { throw new IllegalArgumentException( "File: " + nom + " not found"); } // read the OWL file new

ManipulerWsdl manp = ManipulerWsdl(this.getServletContext().getRealPath("/")+"service\\"+nom); out.println( manp.getWSDLService().getName()); /* ServletContext sc = this.getServletContext(); RequestDispatcher rd sc.getRequestDispatcher("/recepservice?nameserv="+manp.getWSDLService().getName()); rd.forward(request, response);*/ } catch (Exception e) { out.println(e.getMessage()); } } }

new

EXTRAIT DUN FICHIER OWL GENERE

Page 162

Page 163

ANNEXE D. FICHIERS DE L'INTERFACE UTILISATEUR FINAL


ANDROIDMANIFEST.XML
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="utbm.SEM" android:versionCode="1" android:versionName="1.0"> <application android:icon="@drawable/icon" android:label="@string/app_name" android:debuggable="true"> <activity android:label="@string/app_name" android:name=".SEM"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity android:name=".activity.ServiceDetail"></activity> </application> <uses-sdk android:minSdkVersion="2" /> <uses-permission android:name="android.permission.INTERNET"></uses-permission> </manifest>
RES/ LAYOUT / DETAILS.XML

<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="fill_parent" android:layout_height="fill_parent"> <TextView android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="@string/hello" /> <TextView android:id="@+id/lblStatus" android:layout_width="fill_parent" android:layout_height="fill_parent" android:text="... editing ..." /> <Button android:id="@+id/cmdCalculate" android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Calculate" /> </LinearLayout>

Page 164

GLOSSAIRE
A ACAN Ad Hoc Context Aware Network ADSL Asymmetric Digital Subscriber Line API Applications Programming Interface ASCII American Standard Code for Information Interchange Axiome Il sagit soit dun nonc dont la vracit est vidente, soit dun nonc qui ne peut pas tre ni sans avoir une contradiction.. B BPEL Business Process Execution Language BPEL4WS Business Process Execution Language for Web Services C CAS Context-Aware Service CASD Context-Aware Service Discovery CC/PP Composite Capabilities / Preference Profile CC Context Client CIS Contextual Information Service CIDS Context Information Distribution System CIB Context Information Base CIDS Context Information Dissemination System CIS Context Information Source CM Context Mediator ConQo Context- and QoS- Aware Service Discovery Contexte Le contexte est dfini comme lensemble des informations pouvant tre utilises pour caractriser la situation dune entit (personne, endroit, objet, etc.) CORBA Common Object Request Broker Architecture COSS Context-aware, Ontolgy-based Semantic Service discovery

Page 165

CPU Central Processing Unit CSA Context Service Adapter D DARPA Defence Advance Research Projects Agency DDRD Dynamic Decentralized Resource Discovery DiffServ Differentiated Service DMC Decision Making Component DMTF Distributed Management Task Force DSCP Differentiated Services Code Point E ebXML electronic business eXtensible Markup Language EE Execution Environment F FTP File Transport Protocol G GUI Graphical User Interface GPRS General Packet Radio Service H HTTP Hyper Text Transfer Protocol HCI Human Computer Interface I IETF Internet Engineering Task Force IFLA International Federation of Library Associations I/O Input/Output IOPEs Inputs, Outputs, Preconditions, Effects J

Page 166

JVM Java Virtual Machine JPEG Joint Photographic Experts Group K KIF Knowledge Interchange Format L LAN Local Area Network M MAC Media Access Control MDA Model-Driven Architecture N NACE Nomenclature Statistique des Activits Economiques NAICS North American Industry Classification System O OASIS Organization for the Advancement of Structured Information Standards OGSA Open Grid Service Architecture For Distributed Systems Integration OMG Object Management Group Ontologie Une ontologie reprsente un ensemble structur de termes et concepts, en lien avec un champ dinformations donn. Une ontologie est un modle de donnes illustrant les concepts dun domaine de connaissance, ainsi que les relations entre ces concepts. Une ontoogie permet de raisonner propos des concepts ainsi dfinis. OWL Web Ontology Language OWL-S Web Ontology Language for Services P PACL Permitted Access Control List PDA Personal Digital Assistant PKI Public Key Infrastructure PM Policy Manager P2P Peer-To-Peer ou Pair--pair

Page 167

PURL Persistent Uniform Ressource Locator Q QoS Quality of Service QoC Quality of Context R RDF Resource Description Framework RDF(S) Rification En informatique, la rification est le procd qui consiste transformer un concept en un objet informatique. Dans le cadre de la gestion des connaissances, la rification permet de transformer linformation en connaissance. REST Representational State Transfer RPC Remote-Procedure Call S SDD Service Denition Document SDF Service Deployment Framework SDK Software Development Kit Smantique En linguistique, la smantique reprsente une branche qui tudie les signifis (signification des mots composs, rapport de sens entre les mots, etc.). En informatique, la smantique fait rfrence des rgles formelles, dfinies afin de permettre aux ordinateurs de comprendre les informations manipules. En informatique, ce terme est utilis en opposition celui de syntaxe (pour les langages de programmation). Entre les deux concepts, il y a la mme diffrence quentre les concepts de fond et forme . Sensibilit au contexte Il sagit dune proprit dun systme, qui utilise le contexte pour furnir des informations et/ou des services pertinents par rapport la situation de lutilisateur. Service Web Un service Web est dfini comme la ralisation dune ou plusieurs actions par une entit, pour une autre entit. Un service Web est dfini dans un domaine donn. Lentit ralisant les acions du service est appele fournisseur de service, lautre entit tant le demandeur de service. Service Web smantique Un service Web smantique respecte la dfinition dun service Web, mais sa reprsentation peut tre interprte par un ordinateur. Un service Web smantique a plusieurs niveaux dabstraction. Un service concret est la ralisation spcifique de certaines actions dune entit pour une autre. Un service abstrait correspond un ensemble de services concrets. Lavantage dun service abstrait cest quil peut faire rfrence dautres services, sans avoir spcifier lensemble des aspects dfinnissant ces services.

Page 168

SIC Standard Industrial Classification SICE Service Invocation Condition Evaluator SIP Session Initiation Protocol SLO Service Logic Object SL Service Layer SLA Service Level Agreement SMTP Simple Mail Transfer Protocol SNMP Simple Network Management Protocol SOAP Simple Object Access Protocol SQL Structured Query Language SPARQL SPARQL Protocol And RDF Query Language SWRL Semantic Web Rule Language SWSF Semantic Web Services Framework T TINA Telecommunication Information Networking Architecture TCP Transport Protocol U UBL Universal Business Language UCL URL Class Loader UDDI Universal Description, Discovery And Integration UML Unified Modeling Language UN/CEFACT United Nations Center for Trade Facilitation and Electronic Business UNSPSC United Nations Standard Products and Services Code URI Universal Ressource Identifier URL Uniform Resource Locator V VLAN Virtual Local Area Network

Page 169

VoIP Voice Over Internet Protocol VPN Virtual Private Network W W3C World-Wide Web Consortium WiFi Wireless Fidelity WIMAX IEEE 802.16 Standard WLAN Wireless Local Area Network WSCI Web Service Choreography Interface WSCL Web Service Conversation Language WSCL Web Service Choreography Language WS-CDL Web Services Choreography Description Language WSDL Web Service Definition Language WSDL-S Web Services Semantics WS-I Web Services Interoperability Organization WSMO Web Service Modeling Ontology WSML Web Service Modeling Language WSMX Web Service eXectution Model WWW World Wide Web X XML Extensible Markup Language XML-RPC Extensible Markup Language Remote Proceduring Calling Protocol XSL Extensible Stylesheet Language XSP Extensible Service Protocol

Page 170

BIBLIOGRAPHIE
(ABOWD 1999) ABOWD, G.D., DEY, A.K., BROWN, P., DAVIES, N., SMITH, M., STEGGLES, P. Towards a Better Understanding of Context and Context-Awareness. Lecture Notes in Computer Science (LNCS) - Proceedings of the 1st International Syposium on Handheld and Ubiquitous Computing. Karlsruhe, Allemagne: Springer-Verlag, 1999. 304-307. AKKIRAJU, R., et al.,. Web Service Semantics - WSDL-S. Vers. 1.0. 5 Novembre 2005. http://www.w3.org/Submission/WSDL-S/ (accs le Novembre 10, 2009). ALESSO, H.P, SMITH C.F.,. Thinking on the Web - Berners-Lee, Gdel and Turing. dit par John Wiley & Sons. Hoboken, New Jersey: Wiley Interscience, 2006. ALLEMANG, D., HENDLER J.,. Semantic Web for the Working Ontologist Effective Modeling in RDFS and OWL. Copyright by Elsevier Inc. Burlington MA 01803: Morgan Kaufmann Publishers, 2008. Autorit de mise jour de l'ISO 3166 (ISO 3166/MA) point focal de l'ISO pour les codes de pays. 2009. http://www.iso.org/iso/fr/country_codes.htm (accs le Novembre 9, 2009). B., SENACH. Evaluation ergonomique des interfaces homme-machine: une revue de la littrature. Rapport de recherche, Institut National de Recherche en Informatique et en Automatique (INRIA), 1990. BAADER, F., CALVANESE, D., MCGUINNESS, D.L., NARDI, D., PATEL-SCHNEIDER, P., et al. The Description Logic Handbook: Theory, Implementation and Applications. dit par Aachen University of Technology BAADER Franz. Cambridge University Press, 2002. BAKHOUYA, M., GABER J. Approaches for Ubiquitous Computing. dit par LABIOD H. Wireless Ad-hoc and Sensor Networks (ISTE Hermes Science and Lavoisier), 2008: 111-142. BALZER, S., LIEBIG T., WAGNER M.,. Pitfalls of OWL-S: a practical semantic web use case. Proceedings of the 2nd International Conference on Service-oriented Computing (ICSOC'04). New York, NY, USA: ACM, 2004. 289-298. BATTLE, S., et al.,. Semantic Web Services Framework (SWSF) Overview. 9 Septembre 2005. http://www.w3.org/Submission/SWSF/ (accs le Novembre 10, 2009). BECHHOFER, S., VAN HARMELEN, F., HENDLE, J., HORROCKS, I., MCGUINNESS, D.L., PATEL-SCHNEIDER, P.F., STEIN, L.A.,. OWL Web Ontology Language Reference. dit par M., SCHREIBER, D., DEAN. 10 Fvrier 2004. http://www.w3.org/TR/owl-ref/ (accs le Novembre 9, 2009).

(AKKIRAJU 2005)

(ALESSO 2006)

(ALLEMANG 2008)

(ISO 3166 2009)

(B. SENACH 1990)

(BAADER 2002)

(BAKHOUYA 2008)

(BALZER 2004)

(BATTLE 2005)

(BECHHOFER 2004)

Page 171

(BELLWOOD 2004)

BELLWOOD, T., et al.,. UDDI Spec Technical Committee Draft. Copyright OASIS Open 2002-2004. 19 10 2004. http://uddi.org/pubs/uddi_v3.htm (accs le Novembre 9, 2009). BENTHAM, J. La classification des crimes et dlits. dit par DOUCET J.P. 7 Novembre 2009. http://ledroitcriminel.free.fr/la_science_criminelle/les_sciences_juridiques/la_l oi_penale/infraction/bentham_classification_delits.htm (accs le Novembre 10, 2009).

(BENTHAM 2009)

(BERNERS-LEE 1998) BERNERS-LEE, T. Axioms of Web Architecture. 1998. http://www.w3.org/DesignIssues/Principles.html (accs le Novembre 9, 2009). (BERNERS-LEE et al. 2001) BERNERS-LEE, T., et al. The Semantic Web: a New Form of Web Content that is Meaningful to Computers will unleash a Revolution of new Possibilitis. Scientific American 284, n 5 (Mai 2001): 34-43. BOAG, S., et al. XQuery 1.0: An XML Query Language. Vers. 1.0. 23 Janvier 2007. http://www.w3.org/TR/xquery/ (accs le Novembre 10, 2009). BRAUN, I., STRUNK A., STOYANOVA G., BUDER B.,. ConQo A Context- And QoS-Aware Service Discovery. Proceedings of IADIS International Conference on WWW/Internet. Freiburg, Allemagne, 2008. BRAY, T., PAOLI J., SPERBERG-MCQUEEN C.M., MALER E., YERGEAU F.,. Extensible Markup Language (XML) 1.0 (Fifth Edition). 26 Novembre 2008. http://www.w3.org/TR/xml/ (accs le Novembre 9, 2009). BREITMANN, K.K., CASANOVA, M.A., TRUSZKOWSKI, W.,. Semantic Web: Concepts, Technologies and Applications. NASA Monographs in Systems and Software Engineering. dit par Professor Michael Hinchey. Londres: Springer-Verlag, 2007. BROENS, T. Context-aware, Ontology based, Semantic Service (COSS) Discovery. Thse de doctorat, Universit de Twente, Enschede, Pays-Bas, 2004, 87.

(BOAG 2007)

(BRAUN 2008)

(BREITMANN 2007)

(BROENS 2004)

(CHEN et KOTZ 2000) CHEN, G., et D. KOTZ. A Survey of Context-Aware Mobile Computing Research. Rapport Technique, Hanover, NH, USA: Darmouth College, 2000. (H. CHEN 2004) CHEN, H.,. Context Broker Architecture (CoBrA). http://cobra.umbc.edu/ (accs le Novembre 10, 2009). 15 Juillet 2004.

(CHINNICI 2007)

CHINNICI, R., MOREAU J.J., RYMAN A., WEERAWARANA S.,. Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. W3C. 26 Juin 2007. http://www.w3.org/TR/wsdl20/ (accs le Novembre 9, 2009).

(CHRISTENSEN 2001) CHRISTENSEN, E., CURBERA F., MEREDITH G., WEERAWARANA S.,. Web Services Description Language (WSDL) 1.1. W3C. 15 Mars 2001. http://www.w3.org/TR/wsdl (accs le Novembre 9, 2009). (CLARK 1999) CLARK, J., DEROSE S.,. XML Path Language (XPath). Vers. 1.0. 16 Novembre 1999. http://www.w3.org/TR/xpath (accs le Novembre 10, 2009).

Page 172

(Classfication de Nice Classification internationale des produits et des services aux fins de 2009) l'enregistrement international des marques tablie en vertu de l'Arrangement de Nice. 2009. http://www.wipo.int/classifications/nice/fr/ (accs le Novembre 9, 2009). (Contexte 2009) Contexte. Wikipdia. 23 Septembre 2009. http://fr.wikipedia.org/wiki/Contexte (accs le Novembre 10, 2009). CUDDY, S., KATCHABAW M., LUTYYa H. Context-aware service selection based on dynamic and static service attributes. Proceedings of the IEEE International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob). Montral, Canada, 2005. 13-20. D&B. Numro D-U-N-S. 2009. http://dbfrance.dnb.com/French/default.htm?Loc=/French/DataBase/duns.htm (accs le Novembre 9, 2009). Data, Information, and Process Integration with Semantic Web Services. 9 Juillet 2004. http://dip.semanticweb.org/ (accs le Novembre 10, 2009). DE BRUIJN, J. The Web Service Modeling Language (WSML). 8 Aot 2008. http://www.wsmo.org/wsml/wsml-syntax (accs le Novembre 9, 2009). DE BRUIJN, J., et al. Web Service Modeling Ontology (WSMO). dit par H., POLLERES, A., ROMAN, D., LAUSEN. 3 Juin 2005. http://www.w3.org/Submission/WSMO/ (accs le Novembre 10, 2009). DEY, A.K.,. Understanding and Using Context. Personal and Ubiquitous Computing (Springer-Verlag) 5, n 1 (2001): 4-7. Digital Libraries Metadata Resources. 24 Octobre http://archive.ifla.org/II/metadata.htm (accs le Novembre 9, 2009). DIMARZIO, J.F. Android - a Programmer's Guide. McGraw-Hill, 2008. DOLCE : a Descriptive Ontology for Linguistic and Cognitive Engineering. 7 Juillet 2006. http://www.loa-cnr.it/DOLCE.html (accs le Novembre 10, 2009). Dynamic binding. 27 Octobre 2009. http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 (accs le Novembre 10, 2009). ebXML Specs. Copyright OASIS Open 2006. http://www.ebxml.org/specs/index.htm (accs le Novembre 9, 2009). 2009. 2005.

(CUDDY 2005)

(D&B 2009)

(DIP 2004)

(DE BRUIJN 2008)

(DE BRUIJN et al. 2005)

(DEY 2001)

(Metadata 2005)

(DIMARZIO 2008) (DOLCE 2006)

(Dynamic binding 2009)

(ebXML 2009)

(efurgences 2007)

efurgences. Scores et classification des malades aux urgences. 2007. http://www.efurgences.net/index.php/scores/85-scores-classification-urgences (accs le Novembre 10, 2009). ERL, Thomas,. Service-Oriented Architecture: Concepts, Technology, and Design. Copyright 2005 Pearson Education, Inc. Vol. I. Prentice Hall PTR, 2005. EUZENAT, J., SHVAIKO P. Ontology Matching. Berlin: Springer-Verlag, 2007.

(ERL 2005)

(EUZENAT 2007)

Page 173

(FIELDING 2000)

FIELDING, R.T. Architectural Styles and the Design of Network-based Software Architectures. Thse de doctorat, University of California, Irvine, USA, 2000, 180. GABHART, K., JOHNSON D. kXML-RPC Enables Service-Oriented Mobile Computing. devx.com. 13 Juillet 2007. http://www.devx.com/Java/Article/34963 (accs le Novembre 10, 2009).

(GABHART 2007)

(GENESERETH 1994) GENESERETH, M.R., FIKES, R.E., et al. Knowledge Interchange Format (KIF) Reference Manual. Vers. 3.0. 7 Dcembre 1994. http://logic.stanford.edu/kif/Hypertext/kif-manual.html (accs le Novembre 10, 2009). (GHAFOUR 2004) GHAFOUR, S.A.,. Mthodes et outils pour l'intgration des ontologies. Mmoire de stage de DEA "Documents Multimdia, Images, et Systmes dInformation Communicants", Laboratoire dInfoRmatique en Images et Systmes dinformation (LIRIS), Ecole Doctorale "nformatique et Information pour la Socit" (EDA 335), 2004, 51. GHIDINI, C., GIUNCHIGLIA F. Local models semantics, or contextual reasoning = locality + compatibility. Artificial Intelligence (Elsevier Science Publishers Ltd.) 127, n 2 (Avril 2001): 221-259. GIAMPAPA, J., PAOLUCCI M., SRINIVASAN N., VACULIN R., et al. Translator from WSDL to OWL-S. 6 Juin 2005. http://www.semwebcentral.org/projects/wsdl2owl-s/ (accs le Novembre 10, 2009). GRAY, P.D., SALBER D. Modelling and Using Sensed Context Information in the Design of Interactive Applications. Lecture Notes in Computer Science (LNCS) Proceedings of the 8th International Conference on Engineering for HumanComputer Interaction (IFIP). Londres, Angleterre: Springer-Verlag, 2001. 317336. GRIMM, S. Discovery - Identifying Relevant Services. Chap. 8 dans Semantic Web Services - Concepts, Technologies and Applications, de GRIMM S., ABECKER A. d. par STUDER R. Berlin: Springer-Verlag, 2007.

(GHIDINI 2001)

(GIAMPAPA 2005)

(GRAY 2001)

(GRIMM 2007)

(GRIMM et al. 2007a) GRIMM, S., et al. Knowledge Representation and Ontologies - Logic, Ontologies and Semantic Web Languages. Chap. 3 dans Semantic Web Services - Concepts, Technologies and Applications, de R., GRIMM, S., ABECKER, A. d. par STUDER, 51-105. Berlin: Springer-Verlag, 2007a. (GUARINO 1997) GUARINO, N.,. Understanding, Building and Using Ontologies. International Journal of Human Computer Studies - Special Issue on using Explicit Ontologies in KBS Development (Academic Press, Inc.) 46, n 2-3 (Fvrier-mars 1997): 293-310. GUDGIN, M., HADLEY M., MENDELSON N., MOREAU J.J., NIELSEN H.F., KARMARKAR A., LAFON Y.,. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). Vers. 2me. W3C. 27 Avril 2007. http://www.w3.org/TR/soap12-part1/ (accs le Novembre 9, 2009).

(GUDGIN 2007)

Page 174

(HELD 2002)

HELD, A., BUCHHOLZ S., SCHILL A.,. Modeling of Context Information for Pervasive Computing Applications. Proceedings of SCI 2002 / ISAS 2002. Orlando, USA, 2002. HENDLER, J. Agents and the Semantic Web. IEEE Intelligent Systems 16, n 2 (Mars-avril 2001): 30-37. HENRICKSEN, K., et al. Generating Context Management Infrastructure from High-Level Context Models. Proceedings of the 4th International Conference on Mobile Data Management (MDM'03). Melbourne, Australia, 2003. 1-6. HENRICKSEN, K., et J. INDULSKA. Developing context-aware pervasive computing applications: Models and approach. Pervasive and Mobile Computing (Elsevier) 2, n 1 (Fvrier 2006): 37-64. HERMAN, I.,. Web Ontology Language (OWL). dit par W3C. 15 Octobre 2007. http://www.w3.org/2004/OWL/ (accs le Novembre 9, 2009). HOFER, T., SCHWINGER W., PICHLER M., LEONHARTSBERGER G. Proceedings on the 36th Annual Hawaii International Conference on System Sciences (HICSS'03). Big Island,Hawaii: IEEE Computer Society, 2003.

(HENDLER 2001)

(HENRICKSEN et al. 2003)

(HENRICKSEN et INDULSKA 2006)

(HERMAN 2007)

(HOFER 2003)

(Homographe 2009) Homographe. 4 Octobre 2009. http://fr.wikipedia.org/wiki/Homographe (accs le Novembre 5, 2009). (HORROCKS et al. 2004) HORROCKS, I., et al. SWRL: A Semantic Web Rule Language Combining OWL and RuleML. dit par W3C. 21 Mai 2004. http://www.w3.org/Submission/SWRL/ (accs le Novembre 9, 2009). INDULSKA, J., ROBINSONA R., RAKOTONIRAINY A., HENRICKSEN K.,. Experiences in Using CC/PP in Context-Aware Systems. Lecture Notes in Computer Science (LNCS) - Proceedings of the 4th International Conference on Mobile Data Management. Springer-Verlag, 2003. 247-261. JavaServer Pages. 5 Novembre 2009. http://fr.wikipedia.org/wiki/JavaServer_Pages (accs le Novembre 10, 2009). JavaServer Pages Technology. 2009a. http://java.sun.com/products/jsp/index.jsp (accs le Novembre 10, 2009). Jena A Semantic Web Framework for Java. 2009. http://jena.sourceforge.net/ (accs le Novembre 10, 2009). KAVANTZAS, N., BURDETT D., RITZINGER G., FLETCHER T., LAFON Y.,. Web Services Choreography Description Language (WS-CDL). Vers. 1.0. W3C. 11 Dcembre 2004. http://www.w3.org/TR/2004/WD-ws-cdl-10-20041217/ (accs le Novembre 10, 2009). KLYNE, G., REYNOLDS, F., WOODROW, C., OHTO, H., HJELM, J., BUTLER, M.H., TRAN, L. Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies. Vers. 1.0. W3C. 15 Janvier 2004. http://www.w3.org/TR/CCPPstruct-vocab/ (accs le Novembre 10, 2009).

(INDULSKA 2003)

(JSP 2009)

(JSP 2009a)

(Jena 2009)

(KAVANTZAS 2004)

(KLYNE 2004)

Page 175

(KORPIPAA 2003)

KORPIPAA, P., MANTYJARVI J., KELA J., KERANEN H., MALM E.J.,. Managing context information in mobile devices. IEEE Pervasive Computing (IEEE Computer Society) 2, n 3 (Juillet-septembre 2003): 42-51. kXML. 4 Dcembre 2005. http://kxml.sourceforge.net/index.shtml (accs le Novembre 10, 2009). La Classification Clinique des Malades des Urgences modifie. Observatoire des Urgences de Midi-Pyrnes. 15 Octobre 2009. http://www.orumip.fr/docs/ccmu.pdf (accs le Novembre 10, 2009). LASSILA, O. Using the semantic web in mobile and ubiquitous coputing. Proceedings of the Working Conference on Industrial Applications of Semantic Web. Jyvaskyla, Finlande: International Federation of Information Processing (IFIP), 2005. LAUSEN, H., LARA R., POLLERES A., DE BRUIJN J. Description. Chap. 7 dans Semantic Web Services - Concepts, Technologies and Applications, de GRIMM S., ABECKER A. d. par STUDER R., 402. Berlin: Springer-Verlag, 2007. Les statistiques des services d'incendie et de secours dition 2009. Ministre de l'Intrieur, de l'Outre-Mer et des Collectivits Territoriales. 6 Aot 2009. http://www.interieur.gouv.fr/sections/a_votre_service/statistiques/securite_civ ile/2008/statistiques-2008/view (accs le Novembre 10, 2009).

(kXML 2005)

(CCMU 2009)

(LASSILA 2005)

(LAUSEN 2007)

(Pompiers 2009)

(Lingua franca 2009) Lingua franca. 14 Octobre 2009. http://fr.wikipedia.org/wiki/Lingua_franca (accs le Novembre 9, 2009). (NACE 2009) List of NACE codes. 9 Novembre 2009. http://ec.europa.eu/competition/mergers/cases/index/nace_all.html (accs le Novembre 10, 2009).

(MAEDCHE et STAAB MAEDCHE, A., et S. STAAB. Ontology Learning for the Semantic Web. dit par 2001) IEEE Educational Activities Department. IEEE Intelligent Systems 16, n 2 (Mars 2001): 72-79. (MAHESH 2001) MAHESH, K. Text Retrieval: a Primer. Rapport de recherche, Oracle Corporation, 2001. MARTIN, D., et al. OWL-S: Semantic Markup for Web Services. 22 Novembre 2004. http://www.w3.org/Submission/OWL-S/ (accs le Novembre 9, 2009). . OWL-S: Semantic Markup for Web Services. Dcembre 2008. http://www.ai.sri.com/daml/services/owl-s/1.2/overview/ (accs le Novembre 10, 2009). MCCARTHY, J., BUVAC S.,. Formalizing Context (Expanded Notes). Working Papers of the AAI Fall Symposium on Context in Knowledge Representation and Natural Language. California: American Association for Artificial Intelligence (AAAI), 1997. 99-135.

(MARTIN 2004)

(MARTIN 2008)

(MCCARTHY 1997)

Page 176

(MCDERMOTT 2004) MCDERMOTT, D.,. DRS: A Set of Conventions for Representing Logical Languages in RDF. 12 Janvier 2004. http://www.cs.yale.edu/homes/dvm/daml/DRSguide.pdf (accs le Novembre 10, 2009). (MCGUINESS 2004) MCGUINESS, D.L., VAN HARMELEN F.,. OWL Web Ontology Language. dit par W3C. 10 Fvrier 2004. http://www.w3.org/TR/owl-features/ (accs le Novembre 9, 2009). MEIER, R. Professional Android Application Development. Indianapolis, Indiana: Wiley Publishing, 2009. MITCHELL, K. Supporting The Development of Mobile Context-Aware Systems. Thse de doctorat, Computer Department, Lancaster University, Lancaster, Angleterre, 2002, 224. MOTIK, B., SATTLER, U., STUDER, R.,. Query Answering for OWL-DL with rules . Web Semantics: Science, Services and Agents on the World Wide Web (Elsevier) 3, n 1 (Juillet 2005): 41-60. MURPHY, M.L. Beginning Android. Apress, 2009. NAICS. North American Industry Classification System (NAICS). U.S. Census Bureau. 11 Juin 2009. http://www.census.gov/eos/www/naics/ (accs le Novembre 9, 2009). NARAYANAN, S., MCILRAITH, S.A.,. Simulation, verification and automated composition of web services. dit par ACM (Association for Computing Machinery). Proceedings of the 11th international conference on World Wide Web. Honolulu, Hawa, 2002. 77-88. PAOLUCCI, M., SRINIVASAN N., SYCARA K., NISHIMURA T. Towards a Semantic Choreography of Web Services: from WSDL to DAML-S. Proceedings of the 1st International Conference on Web Services (ICWS). Las Vegas, NV, USA, 2003. PAWAR, P., TOKMAKOFF A.,. Ontology-Based Context-Aware Service Discovery for Pervasive Environments. Proceedings of the 1st IEEE International Workshop on Services Integration in Pervasive Environments (SIPE'2006). Lyon, France, 2006. Persistent Uniform Resource Locator. 19 Avril 2009. http://en.wikipedia.org/wiki/Persistent_Uniform_Resource_Locator (accs le Novembre 10, 2009). Protg. 2009. http://protege.stanford.edu/ (accs le Novembre 10, 2009). PRUD'HOMMEAUX, E., SEABONE A. SPARQL Query Language for RDF. 15 Janvier 2008. http://www.w3.org/TR/rdf-sparql-query/ (accs le Novembre 10, 2009). Rification. 12 Septembre 2009. http://fr.wikipedia.org/wiki/Rification (accs le Novembre 9, 2009).

(MEIER 2009)

(MITCHELL 2002)

(MOTIK 2005)

(MURPHY 2009) (NAICS 2009)

(NARAYANAN 2002)

(PAOLUCCI 2003)

(PAWAR 2006)

(PURL 2009)

(Protg 2009) (PRUD'HOMMEAUX 2008) (Rification 2009)

Page 177

(ROXIN et al. 2008)

ROXIN, A., et et al. Location Models for Pervasive Road Networks. (Journal of International Transactions on Systems Science and Applications) 4, n 2 (Mai 2008): 162-166.

(ROXIN et al. 2008a) . Middleware Models for Location-Based Services: a Survey. Proceedings of the 2nd International Workshop on Agent-oriented software engineering challenges for Ubiquitous and Pervasive Computing (AUPC). Sorrento, Italy, 2008a. 35-40. (ROXIN et al. 2007) . Survey of wireless geolocation techniques. IEEE Globecom Workshops. Washington DC, USA, 2007. 1-9. . TransportML: a Middleware for Location-Based Services Collaboration. IEEE Proceedings of the 2nd International Workshop on Service-computing, Context-aware, Location-aware and Positioning techniques (SCLP'09). Cairo, Egypt., 2009. SCHILIT, B., ADAMS, N., WANT, R.,. Context-aware computing applications. Proceedings of the Workshop on Mobile Computing Systems and Applications. Santa Cruz, CA, USA: IEEE Computer Society, 1994. 85-90. SENACH, B. Evaluation ergonomique des interfaces homme-machine: une revue de la littrature. Rapport de recherche RR-1180, INRIA, 1990. Service. 6 Octobre 2009. http://fr.wikipedia.org/wiki/Service (accs le Novembre 9, 2009). Service. Barry & Associates, Inc. 2009a. http://www.servicearchitecture.com/web-services/articles/service.html (accs le Novembre 9, 2009). SHENG, Q.Z., BENATALLAH B.,. ContextUML: A UML-Based Modeling Language for Model-Driven Development of Context-Aware Web Services Development. Proceedings of the International Conference on Mobile Business (ICMB). IEEE Computer Society, 2005. 206-212. SOWA, J.F. Principles of Ontology. Knowledge Systems, AI Laboratory Stanford University. 3 Dcembre 1997. http://www-ksl.stanford.edu/ontostd/mailarchive/0136.html (accs le Novembre 9, 2009). SPERBERG-MCQUENN, C.M., THOMPSON, H.,. XML Schema. dit par W3C. 24 Dcembre 2008. http://www.w3.org/XML/Schema (accs le Novembre 9, 2009). Standard Industrial Classification (SIC) Code List. 13 Mai 2008. http://www.sec.gov/info/edgar/siccodes.htm (accs le Novembre 10, 2009). STRANG, T., POPIEN, C.L.,. A Context Modeling Survey. Workshop on Advanced Context Modelling, Reasoning and Management - The Sixth International Conference on Ubiquitous Computing (UbiComp). 2004. Structured Query Language (SQL). 8 Novembre 2009. http://fr.wikipedia.org/wiki/Structured_Query_Language (accs le Novembre 10, 2009).

(ROXIN et al. 2009)

(SCHILIT 1994)

(B. SENACH 1990)

(Service 2009)

(Service 2009a)

(SHENG 2005)

(SOWA 1997)

(SPERBERGMCQUENN 2008) (SIC 2008)

(SQL 2009)

Page 178

(Synonymes 2009)

Synonymes. 9 Novembre 2009. http://fr.wikipedia.org/wiki/Synonymes (accs le Novembre 5, 2009). Taxinomie. 2009 Octobre 2009. http://fr.wikipedia.org/wiki/Taxonomie (accs le Novembre 9, 2009). The home of kSOAP. 25 Aot 2003. http://ksoap.objectweb.org/ (accs le Novembre 10, 2009). The home of kXML-RPC. 2002. http://kxmlrpc.objectweb.org/ (accs le Novembre 10, 2009).

(Taxinomie 2009)

(kSOAP 2003)

(kXML-RPC 2002)

(Intelligent Software The Intelligent Software Agents Lab. 2009. http://www.cs.cmu.edu/~softagents/ Agents 2009) (accs le Novembre 10, 2009). (OWL-S Matchmaker The OWL-S Matchmaker. Carnegie Mellon University. 2002. 2002) http://www.cs.cmu.edu/~softagents//daml_Mmaker/daml-s_matchmaker.htm (accs le Novembre 10, 2009). (Thomas Register 2009) (UNSPSC 2009) Thomas Register. 2009 Wikpedia Foundation. 5 Novembre 2009. http://en.wikipedia.org/wiki/Thomasnet (accs le Novembre 9, 2009). United Nations Standard Products and Services Code (UNSPSC). 2009. http://www.unspsc.org/ (accs le Novembre 10, 2009). VALLEE, M., RAMPARANY F., VERCOUTER L. Composition et adaptation contextuelle de services pour la communication ambiante: un tat de l'art. Centre G2I de l'ENSM, 2006. WAG UAProf. Open Mobile Alliance. 2001, Wireless Application Forum, Ltd. 20 Octobre 2001. http://www.openmobilealliance.org/tech/affiliates/wap/wap248-uaprof-20011020-a.pdf (accs le Novembre 10, 2009). WANG, X.H., ZHANG D.Q., GU T., PUNG H.K. Ontology-based context modeling and reasoning using OWL. Proceedings of Workshops of the Second IEEE Annual Conference on Pervasive Computing and Communications. IEEE Computer Society, 2004. WEISER, M. The Computer for the Twenty-First Century. Scientific American (Scientific American) 265, n 3 (1991): 94-104. WELTY, C.,. Towards a Semantics for the Web. Proceedings of Invited Presentation at the Dagstuhl Symposium on Semantics for the Web. Dagstuhl: Schloss Dagstuhl, 2000. WINER, D.,. XML-RPC Specification. 2004-2009 Scripting News, Inc., 1998-2004 UserLand Software, Inc. 15 Juin 1999. http://www.xmlrpc.com/spec (accs le Novembre 9, 2009). ZHU, M.,. Recall, Precision and Average Precision. Rapport de recherche, Department of Statistics and Actuarial Science, Canada: University of Waterloo, 2004.

(VALLEE 2006)

(UAProf 2001)

(WANG 2004)

(WEISER 1991)

(WELTY 2000)

(WINER 1999)

(ZHU 2004)

Page 179

(ZHU et al. 2005)

ZHU, F., MUTKA M.W., NI L.M.,. Service Discovery in Pervasive Computing Environments. IEEE Pervasive Computing (IEEE Computer Society) 4, n 4 (Octobre-dcembre 2005): 81-90.

Page 180

PRODUCTION SCIENTIFIQUE PERSONNELLE


PUBLICATIONS DANS DES JOURNAUX
LOCATION MODELS FOR PERVASIVE ROAD NETWORKS ROXIN A., WACK M. Journal of International Transactions on Systems Science and Applications (ITSSA) May 2008 Vol.4, n 2, p. 162-166. Context-aware mobile computing aims at designing applications that automatically adapt their behaviors to the available location information and the available nearby sensors and devices. This is done in order to fulfill tasks in a way that suits users' current context best. To achieve this, context representation and manipulation are important issues, so as to establish formal context models. In this paper, basic elements of context-aware systems are described with an emphasis on location information representations. Space models for location-based applications are presented. Considered realistic applications concern intelligent vehicles and pervasive road networks.

SEMANTIC WEB SERVICE DISCOVERY ROXIN A., WACK M. Journal of Web Semantics Identifiant article : JWS-D-09-00140 Soumis en aot 2009. This article is a survey of main existing approaches in Semantic Web Services discovery process. The first part of the article presents main definitions regarding Semantic Web Services. Next are discussed main aspects of a discovery framework, notably architectural components and matching algorithms. Main discovery approaches, WSDL-S, OWL-S, WSMO and SWSF are addressed. Finally, key challenges as well as remaining open issues are briefly identified. The scope of this article is to provide the reader with the necessary knowledge about current and future research in semantic-based service discovery.

Page 181

PUBLICATIONS DANS DES CONFERENCES INTERNATIONALES AVEC COMITE DE LECTURE


TRANSPORTML: A MIDDLEWARE FOR LOCATION-BASED SERVICES COLLABORATION ROXIN A., DUMEZ C., COTTIN N., WACK M., GABER J., IEEE 2nd International Workshop on Service-computing, Context-aware, Location-aware and Positioning techniques (SCLP09) December 20-23, 2009 Cairo, Egypt Location-Based Services (LBS) are information and entertainment services, accessible with mobile devices and making use of the position of the mobile device. GNSS is usually used to deliver location information. Although LBS are now widely used, better results could be obtained by merging information issued by several services. Inter-LBS collaboration is still uncommon although a lot of work is done on service orchestration languages such as WS-BPEL 2.0. One of the obstacles is that LBS are created and updated on the fly. This dynamism makes manual composition scenario update difficult. To tackle this problem, we introduce TransportML, a middleware for inter-LBS collaboration, in an automatic fashion. TransportML relies on technologies such as semantic Web services and semantic Web. In this platform, services are discovered and collaboration scenarios are elaborated on the fly. As a consequence, the platform is auto-adaptive and composition scenario maintenance is no longer required.

MIDDLEWARE MODELS FOR L OCATION-BASED SERVICES : A SURVEY ROXIN A., DUMEZ C., WACK M., GABER J., ICPS Proceedings of the 2nd international workshop on Agent-oriented software engineering challenges for ubiquitous and pervasive computing (AUPC) 6-10 July, 2008 Sorrento, Italy ISBN : 978-1-60558-206-1 p. 35-40. Embedded computing systems, sensor networks, LBS pervasive deployment environments, and worldwide computing systems have common characteristics. They are large scale, decentralized and dynamic networks, and needing context-awarness to automatically adapt their behaviour and continue their execution despite network dynamics. Identifying innovative software engineering approaches that take into account all the above mentionned characteristics is a real challenge. This paper focuses on LBS applications and the middleware models required for supporting their operation and characteristics.

Page 182

MODELING OF COOPERATIVE NAVIGATION IN PERVASIVE E-LEARNING APPLICATIONS USING (MAX, PLUS) ALGEBRA NAIT-SIDI-MOH A., ASSOUSSOU D., ROXIN A., WACK M. IEEE Globecom Workshops 26-30 November, 2007 Washington DC, USA DOI : 10.1109/GLOCOMW.2007.4437808 ISBN : 978-1-4244-2024-7 p. 1-7. This paper presents a new approach based on (max, plus) algebra to model cooperative navigation in pervasive e- learning applications. This modeling approach is appropriate for modeling these systems that are governed, on the one hand, by events occurrence in a discrete state space, and on the other hand, by synchronization and parallelism phenomena. In addition, this approach enables to verify in a formal way the model consistency.

SURVEY OF WIRELESS GEOLOCATION TECHNIQUES ROXIN A., GABER J., WACK M., NAIT-SIDI-MOH A. IEEE Globecom Workshops 26-30 November, 2007 Washington DC, USA DOI: 10.1109/GLOCOMW.2007.4437809 ISBN : 978-1-4244-2024-7 p. 1-9. Ubiquitous and pervasive networks and applications include a growing number of research themes. In most use cases, applications require location information to interpret their environment and behave accordingly. In this paper, location algorithms and positioning methods that can be used for wireless geolocation are presented.

LOCATION-BASED MODELS FOR PERVASIVE ROAD NETWORKS ROXIN A., WACK M., GABER J., International Conference on Pervasive Services (ICPS'07) 15-20 July, 2007 Istanbul, Turkey ISBN : 1-4244-1325-7 DOI: 10.1109/PERSER.2007.4283954 p. 443-447. Context-aware mobile computing aims at designing applications that automatically adapt their behaviors to the available location information and the available nearby sensors and devices. This is done in order to fulfill tasks in a way that suits users' current context best. To achieve this, context representation and manipulation are important issues, so as to establish
Page 183

formal context models. In this paper, basic elements of context-aware systems are described with an emphasis on location information representations. Space models for location-based applications are presented. Considered realistic applications concern intelligent vehicles and pervasive road networks.

PUBLICATIONS DANS DES LIVRES


LINFORMATION GEOGRAPHIQUE ROXIN A., Gopositionnement et mobilits / ed. par UTBM 2009 ISBN : 978-2-914279-40-6 p. 57-91. Ce chapitre prsente les diffrents types de reprsentation de linformation gographique, ainsi que les modlisations standardises de ce type dinformation (SVG, GML, GDF ou UML). Nous nous intressons ensuite aux diffrents procds permettant la collecte de ces informations (photogrammtrie, laser scanning). Finalement, nous listons les principales sources dinformations gographiques (sources de rfrence, sources thmatiques, etc.).

COMMUNICATIONS INTER-VEHICULES ROXIN A. Gopositionnement et mobilits / ed. par UTBM 2009 ISBN : 978-2-914279-40-6 p. 163-186. Ce chapitre traite des principaux standards permettant la communication inter-vhicules. Il sagit notamment du DSRC (Dedicated Short Range Communications), WAVE (Wireless Air Vehicular Environment) et CALM (Continuous Air Long Medium interface). Les principaux projets europens ayant implement la communication inter-vhicules sont aussi prsents.

Page 184