La phase de publication implique des interactions entre certains composants. Ces interactions ainsi que les détails concernant la publication des services et le stockage de leur sémantique sont présentés dans les paragraphes de cette section.
6.3.1
Interactions pour la publication
L’interface de publication permet à un fournisseur de publier les descriptions de ses services. La description des services sémantiques dans l’annuaire est spécifiée en YASAWSDL. L’annuaire accepte également des descriptions WSDL ou SAWSDL. La Figure 6.2 présente un diagramme de séquences pour la phase de publication.
FIGURE6.2 – Diagramme de séquences pour la phase de publication.
La phase de publication donne lieu à des interactions entre le registre sémantique fonctionnel (SemanticFunctionalRepository ), le registre syntaxique (SyntacticRepository ), l’annuaire séman- tique (SemanticRegistry ) et le courtier (Trader ).
La phase de publication débute quand un fournisseur de service (ServiceProvider ) envoie à l’annuaire sémantique une URL identifiant la description de son service. Pour cela, il utilise la mé- thode "publish" (Figure 6.2 , étape 1). L’annuaire sémantique appelle la méthode "publishWSDL" auprès du registre syntaxique (Figure 6.2 , étape 2). Pour chaque WSDL publié, le registre syn- taxique (SyntacticRepository ) lui associe une chaîne de caractères unique, appelée identifiant de service : ServiceID (Figure 6.2 , étape 3).
Le ServiceID est retourné au SemanticRegistry (Figure 6.2 , étape 4). Le SemanticRegistry renvoie la description de service et son identifiant unique au Mediator qui les renvoie à son tour au registre sémantique fonctionnel.
Ce dernier composant analyse la description ; les éléments sémantiques fonctionnels de la description sont extraits et préparés afin d’être stockés. Le même identifiant retourné par le re- gistre syntaxique servira de même comme identifiant et référence de la description sémantique dans le registre sémantique fonctionnel (Figure 6.2 , étape 5 et 6). Le Trader confirme le stockage
6.3 Phase de Publication 115
de la description sémantique à l’annuaire sémantique qui à son tour le confirme au fournisseur en lui renvoyant le ServiceID (Figure 6.2 , étape 7 et 8).
6.3.2
Stockage de la sémantique
Le registre sémantique fonctionnel est conçu dans l’objectif de rendre visibles et utiles les données sémantiques transparentes au niveau du registre syntaxique. Ainsi, le registre séman- tique fonctionnel fournit des capacités de stockage de l’aspect sémantique des descriptions de services Web.
En effet, le registre sémantique fonctionnel extrait les informations sémantiques de la descrip- tion YASAWSDL, ensuite, il crée à partir de ces données une description RDF. La description RDF ne reprend pas exactement tous les éléments de la description originelle. J’explique la pro- cédure de transformation et l’intérêt de mes choix à ce niveau en détails dans le paragraphe suivant. Pour le moment, je précise uniquement que les informations sémantiques récupérées sont transformées en triplets RDF. Chaque donnée sémantique (concept de service ou concept de domaine) est attachée à l’élément WSDL qu’elle annote dans la description YASAWSDL (e.g. interface, input, etc).
Dans la description RDF, le registre sémantique fonctionnel insère comme référence l’identi- fiant unique du service auprès du registre syntaxique. Ceci permettra de garder le lien entre la sémantique stockée et le service publié. Ainsi, au moment de la découverte, il sera très facile de retrouver la description syntaxique d’un service Web correspondant à la sémantique fonctionnelle requise. Entre autre, ce mécanisme permet aussi de garder une trace auprès de l’utilisateur et de maintenir la cohérence entre les registres de l’annuaire. Une fois les transformations faites et l’identifiant unique ajouté, les descriptions RDF sont prêtes à être stockées dans une base de connaissances (voir Figure 6.3).
FIGURE6.3 – Transformation de la description YASAWSDL en description sémantique RDF. Dans la suite, j’explique étape par étape comment créer une description RDF à partir d’une description YASAWSDL. En première étape, considérons l’exemple de description YASAWSDL
116 L’annuaire des services Web sémantiques
1 <interface name = "FileManagement"> 2 <operation name= "openRentalFile"/> 3
4 <input messageLabel= "custId"/> 5 <input messageLabel= "carId"
6 serviceconcept= "precondition" modelreference= "CarId"/> 7 <output messageLabel= "fileNb"/>
8
9 </operation> 10
11 <operation name= "closeRentalFile"
12 serviceconcept= "effect" modelreference= "RentalClosing"/> 13
14 <input messageLabel= "fileNb"/> 15 <output messageLabel= "success"/> 16
17 </operation> 18 </interface>
FIGURE6.4 – Exemple de description YASAWSDL.
FIGURE6.5 – Arbre sémantique complet de description YASAWSDL.
de la Figure 6.4) et son "arbre complet" représentatif de la Figure 6.5. D’après l’arbre représenta- tif complet qui est construit dans une première étape à partir de la description YASAWSDL, seuls deux éléments sont annotés. Les autres ne portent aucune donnée sémantique. Il est clair qu’il serait plus sensé d’éviter de les réintégrer dans la nouvelle description sémantique RDF, puis- qu’ils sont stockés dans l’annuaire syntaxique. Pour cela, dans la deuxième étape, je propose de construire un nouveau arbre dit "arbre sémantique réduit" en ne gardant que les chemins à partir de la racine et allant vers des nœuds avec des annotations sémantiques (voir Figure 6.6).
6.3 Phase de Publication 117
Dans la troisième étape, je transforme l’arbre sémantique réduit en triplets RDF qui réutilisent les noms des éléments WSDL non supprimés, les concepts de l’ontologie de services Web et les concepts de domaines (correspondants à chaque annotation). En effet, chaque nœud non supprimé se transforme en ressource RDF. Les noms des ressources remplacent les termes entre "[ ]" de la Figure 6.7 qui représente le graphe RDF générique.
FIGURE6.7 – Le graphe RDF générique.
FIGURE6.8 – Graphe RDF d’illustration.
FIGURE6.9 – Extrait de code d’une description RDF.
118 L’annuaire des services Web sémantiques