les variantes de YASA-M offrent un meilleur rappel que la variante Logic et la variante JS de SAWSDL-MX.
La valeur moyenne de rappel en SAWSDL-MX et YASA-M varie proportionnellement au nombre de services et de requêtes. Min-Average offre un meilleur rappel que les variantes Com- binatory et Cupid de YASA-M, ainsi que la variante basée sur l’approche logique et la variante JS de SAWSDL-MX, et offre de très proche valeurs de rappel des valeurs retournées par les va- riantes Combinatory et Cupid de YASA-M lorsque le nombre de requêtes et de services candidats augmente.
En conclusion, YASA-M offre un meilleur rendement en termes de rappel par rapport à SAWSDL-MX si le nombre de services et de requêtes augmente.
7.3.6
Rapport Rappel/Précision
En se basant sur les résultats des évaluations en termes de précision et les résultats des évaluations en termes de rappel, nous dressons un schéma illustrant le rapport de performance Rappel/Précision.
La Figure 7.10 montre le rapport "Rappel/Précision" pour chacune des variantes (Min- Average, Combinatory et Cupid) de notre approche et des variantes SAWSDL-MX (celle basée sur une approche logique et la variante JS). Ces valeurs sont calculées pour les quatre collec- tions de tests TC1, TC2, TC3 et TC4. La figure affiche en axe des X les valeurs de rappel et en axe des Y les valeurs de précision, de chaque variante. Exemple, le point de coordonnées proche de (0.2,0.2) qui correspond à la variante JS de SAWSDL-MX est construit à partir de la
7.4 Exploitation de la réalisation dans un cas d’utilisation 135
valeur de rappel ˜0.2 de JS pour la TC1 sur la Figure 7.9 d’évaluation de rappel, et à partir de la valeur de précision ˜0.2 de JS pour TC1 sur la Figure 7.8. Le point suivant (0.3,0.1) de JS sur la Figure 7.10 correspond à la même chose mais pour TC2. Le point suivant ( ˜0.4,0.03) de JS sur la Figure 7.10 correspond à la même chose mais pour TC3. Le dernier point de la courbe de JS sur la Figure 7.10 correspond à la même chose mais pour TC4. De même pour les autres variantes.
Les courbes du rapport Rappel/Précision des variantes de chaque approche sont proches. Les meilleures courbes sont celles de l’approche de découverte offertes par les variantes de YASA-M. Bien que la courbe de la variante Combinatory soit légèrement meilleure que les autres, les variantes Min-Average et Cupid offrent aussi de très bonnes valeurs en termes de rapport Rappel/Précision qui restent proches de celles de la courbe de valeurs de la variante Combina- tory.
Sur la Figure 7.10, on distingue bien la différence de performances de découverte des deux approches YASA et SAWSDL pour l’ensemble des collections de ce banc d’essai. YASA offre des variantes nettement plus performantes que celles de SAWSDL.
FIGURE7.10 – Rapport Rappel/Précision.
7.4
Exploitation de la réalisation dans un cas d’utilisation
Dans cette section, je présente une vue globale des résultats du travail de développement réalisé afin d’implémenter nos contributions. Puis, je présente le processus de déploiement de l’annuaire sémantique des services Web. Ensuite, j’introduis brièvement le cas d’utilisation dans lequel notre approche de découverte sémantique de services Web a été exploitée. Enfin, je pré- sente l’intégration de l’architecture de l’annuaire sémantique des services Web afin d’être utilisée dans l’étude de cas et par le bus de services sémantiques.
136 Réalisation
7.4.1
Développement de l’annuaire sémantique de services Web
Sans entrer dans les détails, je présente ici les principaux packages implémentant nos méca- nismes de stockage et d’appariement, l’API développée pour utiliser l’annuaire et la construction du store sémantique. Ensuite, je présente la démarche de déploiement de notre approche de publication et découverte à travers l’annuaire sémantique SemeuseRegistry.
Principaux packages et classes
Tous les packages sont organisés et groupés selon leurs fonctionnalités dans les trois projets Java suivants :
– SemeuseRegistry : ce projet contient les interfaces et les classes de l’API de l’annuaire sémantique ainsi que celles en relation avec l’API de l’annuaire syntaxique,
– SemeuseRegistryFunctionalColleage : ce projet contient tous les packages qui traitent di- rectement des composants fonctionnels de l’architecture de l’annuaire,
– SemeuseRegistryUse : Ce projet peut servir à la publication et à la découverte des fichiers WSDL des services Web sémantiques pour toute étude de cas.
Les principaux packages implémentant notre approche sont : – eu.itsudparis.semeuse.registry.api – eu.itsudparis.semeuse.registry.impl – eu.itsudparis.semeuse.registry.functional.discovery – eu.itsudparis.semeuse.registry.functional.discovery.matching – eu.itsudparis.semeuse.registry.functional.publication – eu.itsudparis.semeuse.registry.functional.semanticstore – eu.itsudparis.semeuse.registry.functional.discovery.semanticdb – eu.itsudparis.semeuse.registry.api.dragonClient
Comme leurs noms l’indiquent, ces packages concernent respectivement l’API de l’annuaire, l’implémentation de l’API, la découverte, l’appariement, la publication, le stockage sémantique, et enfin l’interaction avec la base sémantique et l’annuaire syntaxique PetalsMaster (anciennement nommé Dragon).
Le package "eu.itsudparis.semeuse.registry.api" contient des interfaces de l’annuaire, dont voici les principales d’entre elles :
– DiscoveryMediator : l’interface minimale que doit implémenter le médiateur de découverte, – PublicationMediator : l’interface minimale que doit implémenter le médiateur de publication, – SemeuseRegistry : l’interface de l’annuaire sémantique.
Le package "eu.itsudparis.semeuse.registry.functional.discovery.matching" contient des classes traitant l’appariement sémantique dont voici les principales d’entre elles :
– SemanticMatching : cette classe assure l’appariement élémentaire sémantique, – YasaMatching : cette classe assure l’appariement sémantique global,
– ResultObject : cette classe retourne les résultats de la découverte ainsi que des éléments d’informations qui représentent une trace de l’appariement tels que les degrés d’appariement de chaque service avec la requête ainsi que la correspondance entre les
7.4 Exploitation de la réalisation dans un cas d’utilisation 137
éléments de chaque service et ceux de la requête.
La Figure 7.1 présente l’API développée pour exploiter l’annuaire et exécuter la publication et la découverte.
TABLE7.1 – API de l’annuaire sémantique.
void closeSession() : calls the close session methods of the mediators.
DiscoveryResult[] discover( java.lang.String wsdlDescription, java.lang.String slaDescription)
discovers a set of services that matches with the given wsdl description. java.lang.String getWSDL(java.lang.String dragonId)
It gets the complete WSDL description from the UDDI registry thanks to its dragonId and returns it as a string.
void openSession() : calls the open session methods of the mediators, provi-
ding them the resources they require. java.lang.String publish(java.lang.String wsdlDescription)
publishes the service of given URL sent as string.
Préparation du store sémantique RDF
Pour publier les données sémantiques des descriptions de services, nous avons besoin d’un registre RDF. Aujourd’hui, il existe deux implémentations open source de registre RDF : Jena3 et Sesame4. Nous ne reprenons pas ici toutes les comparaisons que nous avons faites entre les deux implémentations mais nous donnons un résumé pour justifier le choix que nous fai- sons. Toutes les deux permettent le stockage de graphes RDF et d’ontologies, ainsi que l’exécu- tion de requêtes sur les données stockées. Avec Jena, nous utilisons le langage d’interrogation SPARQL5qui est un standard W3C, alors que Sesame utilise SERQL qui n’est pas un standard (c’est uniquement en 2011 que Sesame 2 commence à supporter SPARQL6). En plus de cela, nous notons que pour inférer les propriétés des graphes RDF, Jena utilise un moteur d’inférence (Reasoner ) dont l’implémentation est bien séparée de l’implémentation du store sémantique.
En résumé, le fait que Jena utilise le standard W3C SPARQL est très important pour nous. Un autre point que nous considérons est le fait qu’il est plus facile avec Jena qu’avec Sesame de changer de moteur d’inférence. Ceci est important à partir du moment que différents moteurs d’inférence peuvent offrir différents types d’inférences et qu’un moteur devrait être choisi selon les résultats attendus.
Une fois créé un store sémantique RDF qui est basé sur Jena, nous entamons la démarche de publication des descriptions de services dans le store. Pour cela, nous développons un Parser de descriptions sémantiques YASA. Le Parser doit stocker les descriptions dans des instances Java conformément au "modèle objet" de la spécification YASA. La Figure 7.11 résume comment nous préparons un Parser de descriptions sémantiques de services Web YASA.
3. Jena : A Semantic Web Framework for Java (http ://jena.sourceforge.net) 4. Sesame (http ://www.openrdf.org/sesame1.jsp)
5. SPARQL Query Language for RDF (http ://www.w3.org/TR/rdf-sparql-query/) 6. Sesame2 (http ://www.openrdf.org/download.jsp)
138 Réalisation