Découverte de services web basée sur l’indexation

Découverte de services web basée sur l’indexation

Nous décrivons dans ce chapitre nos approches d’indexation de découvertede services qui reposent sur la construction d’index à plusieurs niveauxque nous avons appelées ITACOM (Indexation de Tous les Arbres des ser-vices web COMposites) pour l’indexation des services web composites stockés dans le registre UDDI de composition(voir l’architecture chapitre 6) et INWEB (Indexation des arbres d’eNtrées des services WEB), INOWEB (Indexation des arbres d’eNtrées et de sOrties des services WEB) pour l’indexation de services web simples stockés dans Nos deux approches d’indexation de services web simples se concentrent sur les paramètres des services web et se présentent sous forme d’un index à plusieurs ni- veaux. Nos index représentent chaque service par chacun de ses paramètres et pour optimiser la recherche, nous avons décidé de trier les paramètres de chaque service puis de construire un arbre avec les dits paramètres où chaque nœud de l’arbre est re- présenté par un paramètre alors que chaque feuille est un ensemble de services ayant comme paramètres les clés des nœuds nous ayant conduit à cette feuille. Le fait de trier les paramètres nous permet de choisir lequel représenter en premier dans l’arbre mais aussi, à l’arrivée d’une requête, de savoir lequel rechercher. Nous rajoutons deux ni- veaux supérieurs afin de faciliter la recherche de la bonne feuille. Le premier consiste au regroupement des services ayant le même nombre de paramètres dans un même arbre (un sous arbre est construit pour chaque nombre de paramètres existants dans le répertoire).

Le second facilite la détection du bon arbre grâce à la mise en place d’une structure de recherche liant chaque arbre au nombre de paramètres que contient les services qu’il regroupe. Le choix de la clé de chaque AE est crucial dans cette méthode car il dirige la construction de l’index et par conséquent la recherche. Comme expliqué pré- cédemment, nous avons choisi d’adopter l’ordre alphabétique dans notre cas, ce qui veut dire que lorsque nous voulons choisir une clé nous prenons la clé la mieux classée alphabétiquement si l’index se construit de haut en bas pour représenter un AE, et l’inverse dans le cas où l’index se construit de bas en haut (cela importe peu tant que nous respectons l’ordre choisi dans la recherche).figure 7.4). Cela peut être intéressant s’il y a une grande redondance dans la fonc- tionnalité globale des SW dans le répertoire. Cela conduira aussi à une utilisation assez grande en ressource mémoire. Dans la première variante, l’accès aux sorties des services web se faisait séquentiellement lorsque nous atteignons la feuille de l’arbo- rescence AE, à la recherche des différentes configurations des paramètres de sorties caractérisant les services de la classe de services recherchée.

Cela peut prendre énor- mément de temps si le nombre de services web par feuille classe de services est très grand. L’ajout des profondeurs de sorties pour dénoter le nombre de paramètres de sor- ties et des Arbres de sorties pour construire l’arborescence des chemins, permet d’ac- célérer l’accès aux listes de services ayant les mêmes entrées et sorties. Les niveaux 4 et 5 sont introduits pour affiner l’index. Le niveau 4 contient les profondeurs de sorties. Le niveau 5 les Arbres de sorties menant vers les classes de services.Contrairement à INWEB où l’accès aux services est effectué en parcourant de ma- nière séquentielle la table du dernier niveau ( Classe de services) à la recherche de la clé du services web correspondant aux paramètres de sortie, dans INOWEB, l’accès est indexé par le chemin de l’ Arbre de sorties qui conduit aux classe de services correspon- dant aux paramètres de sortie inclus dans ce même chemin.est le nombre de paramètres qui composent les entrées ou sorties d’un serviceou d’une requête. Ce nombre ne dépasse généralement pas les 8 paramètres et a une moyenne encore plus faible. le nombre moyen de services dans une classe de paramètres.

Ce nombre varie en fonction du nombre total de services dans l’index et de la diversité fonctionnelle que proposent ses services. Le but princi- pal d’un index étant de faciliter la recherche dans des répertoires volumineux, nous pouvons supposer que est largement plus grand que . donc ( ) ceLa création d’une approche d’indexation pour les services web composites pour notre approche du chapitre 6 (communautés) permet d’accélérer le processus de dé- couverte et de sélection de services web composites. Cependant la création d’une telle approche est relativement complexe. Le problème principal d’indexation de services composites est qu’un service composite est représenté par la combinaison de plusieurs arbres de services (une foret). Cela nous oblige à parcourir tous les arbres à plusieurs reprises (suivant le nombre d’arbres du service composite recherché) ensuite faire l’union des différents résultats ce qui peut être extrêmement coûteux dans le temps. Pour éviter ce problème, nous décidons de proposer un algorithme de transforma- tion de la représentation de services composites sous formes de chemins, ensuite, ces chemins seront regroupés sous formes d’arbres suivant les profondeurs triées par le nombre de services web. Chaque nœud de l’arbre représente un service web. Chaque feuille est un ensemble de services web composites ayant pour paramètres les clés des nœuds ayant en tête cette feuille. Le tri suivant la profondeur nous permet, lorsqu’une requête arrive, de savoir dans quel arbre rechercher le service composite requis.