Introduction

La découverte des SWSs est le processus qui permet de localiser tous les services web qui matchent les besoins fonctionnels du demandeur (requête) [1], à cause du nombre important de services qui offrent des fonctionnalités similaires, cette phase peut retourner un nombre important de services comme résultat. En fait, même si un SWS matche les fonctionnalités demandées par l'utilisateur, il peut encore être inacceptable par un autre utilisateur en considérant d'autres paramètres (par exemple, le coût est trop élevé ou la localisation n'est pas adéquate).

La découverte personnalisée des SWSs vise à complémenter la phase de découverte par une phase de sélection et de rangement en tenant compte des préférences de l'utilisateur. Ces préférences sont exprimées comme des contraintes numériques dans le cas des applications utilisant le QoS ou comme un ensemble de paramètres qui caractérisent l'environnement de l'utilisateur (par exemple la localisation) dans le cas des applications utilisant le contexte.

Dans cet article , nous utilisons les NFPs pour personnaliser la découverte des SWSs. Ces NFPs sont spécifiées en utilisant une ontologie générique qu'on a nommée NFPservice, les offres de NFPs (NFPo) et les préférences du demandeur (NFPr) sont des instances de cette ontologie. Dans notre approche, la sélection est basée sur des règles déclaratives énonçant les conditions pour la réussite du matching logique. Ces règles sont basées sur la description ontologiques des individus représentant les NFPo et NFPr. Notre approche présente les avantages suivants:

• Prise en charge des valeurs quantitatives (QoS) et qualitatives issues des ontologies de domaine (contexte). • Les NFPs sont exprimées sous forme de contraintes en utilisant des opérateurs (> , < , =). • L'ontologie NFPservice proposée peut être utilisée avec plusieurs descriptions fonctionnelles de SWSs (OWL -S [13], WSMO [14], SAWSDL [15]). • La procédure de sélection peut être personnalisée sans changer le code : l'utilisateur peut exprimer ses propres préférences de sélection sous forme de règles. Le matching est réalisée par le raisonnement sur la base de connaissances construite à partir de ces préférences.

Cet article est organisé comme suit: la section 2 présente quelques travaux qui visent la personnalisation de la découverte des SWSs. Dans le section 3, nous présentons le modèle des NFPs et de sélection et dans le section 4 l'implémentation du modèle des NFPs en utilisant OWL-DL. La section 5 présentent les règles utilisées pour sélectionner les services et dans la section 6 nous présentons l'implémentation et l'expérimentation. Enfin nous finirons avec la conclusion et les perspectives dans la section 7.

État de l'Art

Plusieurs approches pour la personnalisation de la découverte des SWSs ont été proposées. La découverte des services web basée sur le contexte se focalise sur l'utilisateur et son environnement. Dans [2], les services web qui participent dans une composition sont sélectionnés en matchant leur contexte avec le contexte de l'utilisateur. Les éléments du contexte (représenté par un schéma XML) sont définis comme paires (nom, valeur), le matching des paramètres est basé sur l'équivalence logique alors que le matching des valeurs est basé sur l'inclusion. Dans [3], le contexte (localisation) est représenté par une ontologie générique qui peut connectée plusieurs ontologies de domaine. Le matching est basé sur la distance sémantique.

Certaines approches exploitent les propriétés existantes dans la description des SWSs. Dans [4], les paramètres utilisés pour la personnalisation sont groupés dans une ontologie générique, chaque paramètre est un sous concept du concept ServiceParameters du profil OWL-S, les valeurs de ces paramètres sont des instances dans une ontologie de domaine, le matching utilisé est logique. Dans [5], L'algorithme de matching utilise plusieurs filtre pour sélectionner les services en se basant sur les propriétés non fonctionnelles représentées par la région géographique, le QoS, le nom du service et le nom du fournisseur.

Les approches utilisant le QoS sont nombreuses. Dans [6], les auteurs proposent OWL-Q une extension pour OWL-S et un algorithme basé sur les règles pour matcher deux métriques. Dans [7], une approche similaire est présentée, l'ontologie proposée pour le QoS peut être utilisée avec plusieurs descriptions fonctionnelles de SWSs. L'utilisateur peut spécifier le modèle de matching. Dans [11], les auteurs présentent WSMO-QoS qui raffine la classe des propriétés non fonctionnelles dans WSMO, ils utilisent un algorithme de normalisation pour la sélection d'un service. D'autres approches ne font pas de distinction entre FPs et NFPs. Dans [8], les auteurs présentent une upper ontologie qui décrit les offres, les requêtes et les services web possédant plusieurs configurations. Dans [9], les auteurs proposent une ontologie pour les WS-Policy et [10] propose une autre pour WS-Agreement, le matching dans ces deux derniers est basé sur ABLE Rule Language (ARL).

Nous présentons la différence entre les approches citées et notre approche (voir Table 1) en se basant sur les dimensions suivantes :

• D_FP_NFP : distinction entre FPs et NFPs.

• V_Qant : prise en charge des valeurs quantitatives .

• V_Qalt : prise en charge des valeurs qualitatives .

• Op : prise en charge des opérateurs (> , < , =).

• Alg_Per: l'algorithme de sélection peut être personnalisé sans changer le code.

• Rank: prise en charge du Ranking.

• Autres_descr: possibilité d'utiliser l'approche avec d'autres descriptions de SWSs comme OWL-S,WSMO ou SAWSDL. 3 Les Modèles utilisés

Modèle des NFPs

Inspirés de [7], [8] et [9] , nous proposons un modèle conceptuel pour les NFPs qui pourra être utilisé pour la sélection des services web. Les propriétés non fonctionnelles d'un service sont modélisées par un ensemble de contraintes C (P , V, OP, poids) :

• P représente le paramètre à traiter, il peut être un concept dans une ontologie pour le QoS (Price, ResponseTime, etc.) ou un concept dans une ontologie de contexte (Location, etc.). • V représente la valeur offerte ou demandée, elle peut être une valeur quantitative ou qualitative (instance ou concept dans une ontologie de domaine).

• Op est un opérateur relationnel (=, < ou >), il est utilisé uniquement dans la requête .Dans le cas d'une offre de NFPs la valeur V est interprétée comme la valeur minimale ou maximale supporté par le fournisseur du service. • Le poids représente l'importance d'une contrainte de la requête.

Par exemple une contrainte de NFPr peut se présenter comme Cr1 (Price, 200, <, 2) ou comme Cr2 (Location, Algeria, =, 4) alors qu'une contrainte de NFPo peut se présenter comme Co1 (Price, 100, 'NULL', 'NULL') et Co2 (Location, Africa, 'NULL', 'NULL'). Dans ces exemples Price représente un concept dans l'ontologie QoS, Location un concept dans l'ontologie géographie (Geo) alors que Algeria et Africa sont des instances dans l'ontologie géographie.

Modèle de selection

Dans cet article, nous considérons uniquement le matching et le rangement des NFPo. Etant donné un ensemble de services web qui matchent les propriétés fonctionnelles, le matching entre n'importe quel NFPr (demande) et les NFPo (offres) est décomposé en un ensemble de matching simple entre une une seule contrainte demandée Cr(Pr,OP,Vr,poids) et une contrainte offerte Co(Po, Vo).

Pour calculer le degré de match des paramètres et des valeurs, on se base sur des notions bien connues de matching pour les SWSs comme "plugin" basé sur la subsomption et "exact" basé sur l'équivalence [23].

Calcul du degré de match des paramètres

Le calcul du degré de match des paramètres Po et Pr (en supposant qu'ils sont des concepts dans l'otologie OntoP) est réalisé par la fonction DoMp tel que :

Calcul du degré de match des valeurs

Pour le calcul du degré de match des valeurs Vo et Vr, nous utilisons la fonction DoMv. Plusieurs cas se présentent • Si Vo et Vr sont des valeurs numériques (5)

⎪ ⎪ ⎪ ⎪ ⎩ ⎪ ⎪ ⎪ ⎪ ⎨ ⎧ > > = − − − < < = − − − = = = ≠ = = ≤ > = ≥ < = = ) ( ) " " ( min max max 1 ) ( ) " " ( min max min 1 ) ( ) " " (1)) ( ) " " (()) ( ) " " (( )) ( ) " " (( 0 )

La Représentation de l'ontologie

Pour l'implémentation du modèle des NFPs, nous utilisons OWL (Web Ontology Language) [16]. Pour la formulation déclarative des directives de matching sous la forme de règles, nous avons besoin de primitives additionnelles de modélisation non fournis par OWL. Nous nous servons de SWRL [17] (Semantic Web Rule Language). Dans ce travail nous nous limitons à DL-safe rules [18] qui un fragment décidable de SWRL et qui est supporté par des moteurs d'inférence tels que KAON2 1 . Le modèle présenté dans la section 3.1 est représenté par une ontologie générique nommée NFPservice (voir figure 1). Les NFPo et NFPr sont des instances de l'ontologie générique NFPservice. Chaque NFPo est représentée par un fichier .owl, NFPr est représenté par le fichier request.owl qui contient en plus les règles de matching.

Pour des raisons de simplicité, nous présentons l'ontologie NFPservice informellement par l'intermédiaire d'un diagramme de classes UML, où les classes UML correspondent aux concepts OWL, les associations UML aux propriétés objet, l'héritage UML à la relation de subconcept et les attributs UML aux propriétés datatype de OWL [19].La propriété hasConstraint permet de relier une instance du concept NFP à plusieurs contraintes (instances de Constraint) , chaque contrainte est reliée à un paramètre (instance de Parameter) dont la propriété hasParameterType pointe vers un concept dans une ontologie .La propriété hasValue permet de stocker la valeur du paramètre , cette valeur peut être de type xsd(string,int,float,…) comme elle peut être un concept ou une instance dans une ontologie , dans ces deux derniers cas hasValue contiendra l'URI du concept ou de l'instance. La propriété hasValueType relie la contrainte à une instance (owl ou xsd) du concept ValueType, nous utilisons cette propriété pour décider quel type de comparaison doit être effectué pour matcher deux valeurs Vo et Vr : comparaison numérique ou comparaison basée sur le raisonnement logique. La propriété hasOperator relie une contrainte à une instance (less_than, equals_to , greater_than ) du concept Operator , cette propriété est utilisée pour savoir si le demandeur préfère la valeur minimale ou maximale parmi les valeurs offertes .La propriété hasResult permet de relier une contrainte à une instance (exact , plug_in) du concept Result et la propriété hasDoM permet de stocker le degré de match pour une contrainte (DoMc). Les valeurs de ces deux dernières propriété sont inférées par les règles DL-safe rules. La valeur de la propriété vMatch =1.0 dans l'instance exact et 0.5 da l'instance plug_in, ces valeurs peuvent être modifier par le demandeur , par exemple en attribuant la valeur 0 à vMatch dans l'instance plug_in une contrainte qui a un match plug_in aura automatiquement un DoMc = 0.

Sélection De Service

Le modèle de sélection présenté dans la section 3.2 est implémenté en utilisant des règles DL-safe rules. L'utilisation des règles au lieu d'écrire du code java nous permet d'assurer une certaine flexibilité. L'utilisateur peut adapter la procédure de sélection selon ses préférences en exprimant ses propres règles de matching. Dans l'exemple de la section 3.2 ,pour la propriété locatedin un utilisateur peut avoir une règle qui spécifie que locatedin(Algeria , Africa) vaut 1, alors qu'un autre peut attribuer la valeur 0.5 ou même 0.

La procédure de sélection peut être décomposée en deux phases principales, la première phase détermine les contraintes qui matchent les contraintes de NFPr, la seconde phase consiste à trier le résultat obtenu à partir de la première phase (voir algorithme 1). La requête NFPr est extraite à partir du profil utilisateur ou elle est générée automatiquement à partir des informations fournies par l'utilisateur. La base de connaissance est construite en important les NFPo i .

Pour l'exemple de la section 3. et Reputation (voir Table 2).On a introduit ces paramètres comme concepts dans l'ontologie "QoS middle ontology" [12]. Nous avons développé cinq ontologies NFPo1.owl, NFPo2.owl, NFPo3.owl, NFPo4.owl et request.owl qui sont des instances de l'ontologie générique NFPservice. Les résultats obtenues sont conformes avec [11] car le service 1 est sélectionné (voir figure 2). La différence entre les degrés de match des services dans [11] et nos résultas peut s'expliquer par : (1) une contrainte de service qui ne matche aucune contrainte de la requête a un degré de match dans [11] alors que dans notre approche elle est éliminée durant la procédure de match par les règles, (2) dans notre approche si l'opérateur utilisé est ' = ' et Vo ≠ Vr pour un paramètre alors le DoMv=0 alors que dans [11] il peut avoir une valeur > 0. Dans ce travail, nous avons proposé de personnaliser la découverte des SWSs en utilisant les propriétés non fonctionnelles (NFPs). Ces NFPs sont spécifiées en utilisant une ontologie générique qu'on a nommée NFPservice, les offres de NFPs (NFPo) et les préférences du demandeur (NFPr) sont des instances de cette ontologie . Nous avons proposée aussi un algorithme de sélection basé sur des règles déclaratives énonçant les conditions pour la réussite du matching logique. L'utilisateur peut personnaliser la procédure de sélection selon ses préférences en exprimant ses propres règles de matching.

Comme perspectives, nous projetons d'appliquer notre méthode sur un plus grand nombre de propriétés non fonctionnelles dont les valeurs sont de différents types (numériques, individus ou concepts d'ontologies) avec un nombre important de services afin de faire une étude comparative effective.

Nous travaillons actuellement sur l'introduction de l'unité de mesure dans l'ontologie NFPservice ainsi que la spécification de règles pour la conversion des valeurs d'une unité de mesure vers une autre.