Résumé. La découverte des services web sémantiques (SWSs) peut retourner un nombre important de services qui offrent des fonctionnalités similaires. La découverte personnalisée 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. Nous proposons d'utiliser les propriétés non fonctionnelles (NFPs) pour personnaliser la découverte des SWSs. Dans cet article, nous présentons une ontologie pour la spécification des NFPs, les NFPs offertes (NFPo) et demandées (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 les descriptions ontologiques des individus représentant les NFPo et NFPr. L'utilisateur peut personnaliser la procédure de sélection selon ses préférences en exprimant ses propres règles de matching.
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. 2 É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.
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. 3.2
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].
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 : ⎧1 si ⎪ DoMp(Po, Pr) = ⎨0.5 si ⎪ ⎩0 sinon
OntoP |= equivalentClass(Po, Pr)
OntoP |= subClassOf (Pr,Po)
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 ⎧0 ⎪ ⎪ ⎪1 ⎪ DoMv (Vo,Vr ) = ⎨⎪1 − ⎪ ⎪1 − ⎪ ⎩
Vo − min Voi max Voi − min Voi
max Voi − Vo max Voi − min Voi si ((Op =" <" )et(Vo ≥ Vr ))ou ((Op =" >" )et (Vo ≤ Vr ))
ou ((Op =" =" )et (Vo ≠ Vr ))
si (Op =" =" )et(Vo = Vr )
si (Op =" <" )et(Vo < Vr )
si (Op =" >" )et(Vo > Vr )
(
OntoV |= sameAs(Vo,Vr)
OntoV |= prop(Pr,Po) prop (Vr, Vo) est une propriété dans l’ontologie OntoV qui exprime en quelque sorte la relation de spécialisation. Par exemple pour les contraintes Cr2 (Location, Algeria, =, 4) et Co2 (Location, Africa, 'NULL', 'NULL') s’il existe un fait Locatedin (Algeria, Africa) dans l’ontologie de domaine géographie alors DoMv=0,5.
On calcule le degré de macth pour une contrainte comme suit :
DoMc = DoMp * DoMv
Enfin on calcule le degré de macth DoMs pour une NFPo contenant n contraintes
Coi (Poi, Voi) ayant comme degré de match DoMci et wi comme poids tel que 1≤i≤n
comme suit :
(
i=1
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 KAON21. 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.
NFP hasConstraint hasOperator
Operator hasResult
Result vMatch(xsd: float) hasParameter
Parameter hasParameterType (xsd : URI)
Constraint hasWeight (xsd: float) hasDoM (xsd: float) hasValue (any) hasValueType
ValueType
Pour l’interconnexion de la description NFPo avec la description fonctionnelle FPo nous nous sommes inspirés de [20], nous stockons une correspondance entre l’URI de NFPo et l’URI de FPo dans une base de données composée d’une seule table nommée Table_NFP, cette solution nous permet d'utiliser la description NFPo avec plusieurs descriptions fonctionnelles comme OWL-S,WSMO ou SAWSDL.
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 NFPoi.owl. et request.owl dans KB.owl
ListeFP : liste des URI des services remplissant la fonctionnalité demandée. NFPr : représente les NFP demandées.
ListeServiceMatch : liste des services (URIservicei, DoMsi) remplissant NFPr triée par DoMsi 1- Pour chaque service i dans ListeFP extraire son URI_NFPoi à partir de
Table_NFP 2- Construire la base de connaissances KB = NFPr + NFPoi + ontologies relatives 3- Formuler la requête SPARQL
ListeNFPintermédiaire = SELECT ?S ?C ?P ?PT ?TypeMatchP ?DoMc ?DoMs WHERE { ?S hasConstraint ?C. ?C hasParameter ?P. ?P hasParameterType ?PT. ?C hasDoM ?DoMc. ?C hasResult ?TypeMatchP.
EVALUATE ?DoMs: = compute_DoMs (?DoMc, ?S)} 4- Construire ListeNFP (URI_NFPoi, DoMsi) à partir de ListeNFPintermédiaire triée par DoMsi 5- Extraire les URIservicei correspondant aux URI_NFPoi à partir de Table_NFP 6- Return ListeServiceMatch (URIservicei, DoMsi)
Cette phase consiste à comparer chaque contrainte Co représentée par un paramètre Po et sa valeur Vo d’une NFPo avec chaque contrainte Cr représentée par un paramètre Pr et sa valeur Vr de NFPr. Le résultat obtenu dans cette phase est un ensemble de contraintes Co qui matchent.
Le moteur d’inférence exécute chaque règle dont les critères sont vérifiés et infère automatiquement d’autres faits. Chaque fait inféré asserte un match (exact ou plug_in) entre une Co et une Cr (algorithme1 etape2). Nous avons spécifié différentes règles suivant la valeur de la propriété hasValueType. Le matching des valeurs numériques est réalisé par plusieurs règles et dépend de la propriété hasOperator. Par exemple la règle suivante permet de matcher deux contraintes numériques Co(Po,Vo) et Cr(Pr,Vr) avec un degré de match exact (Po et Pr sont des concepts dans l’ontologie OntoP.owl ) hasResult(?Co, exact) ← hasParameter(? Co, ? Po), hasParameterType(? Po, ? PTo), hasValueType(?Co,xsd),hasValue(?Co,?Vo),hasConstaint(request, ? Cr), hasOperator(?Cr,less_than),hasParameter(?Cr,?Pr), hasValue(?Cr, ?Vr), hasParameterType(?Pr,?PTr),hasValueType(?Cr,xsd), (?Vo < ?Vr), exact(? PTo, ? PTr)
⎧ true exact(x, y) = ⎨ ⎩ false
si sinon
OntoP |= equivalentClass(x, y)
(
Dans l’exemple de la section 3.1 (Cr2 et Co2) les valeurs de l’attribut Location ne représentent pas le même individu dans l’ontologie Geo.owl. Dans ce cas le modeleur peut spécifier le comportement de matching adapté aux besoins du client.
Pour l’exemple de la section 3.2, cette règle va produire un nouveau fait hasResult (Co1,exact) dans la base de connaissance KB qui asserte que Co1 est un exact match. Pour prendre en charge les autres opérateurs (equals_to , greater_than) ainsi que le degré de match plug_in , nous utilisons d’autres règles. Pour les contraintes dont la valeur de hasValueType est "owl" , d’autres règles ont été spécifiées. Par exemple la règle suivante permet de matcher deux contraintes Co(Po,Vo) et Cr(Pr,Vr) avec un degré de match exact ( Vo et Vr sont des individus dans l’ontologie OntoV.owl ) hasResult(?Co, exact) ← hasParameter(?Co, ? Po), hasParameterType(? Po, ? PTo), hasValueType(?Co,owl),hasValue(?Co,?Vo),hasConstaint(request, ?Cr), hasOperator(?Cr,equals _ to),hasParameter(?Cr,?Pr), hasValue(?Cr, ?Vr), hasParameterType(?Pr,?PTr),hasValueType(?Cr,owl), same _ individu(?Vo, ?Vr), exact(? PTo, ? PTr)
⎧ true same _ individu(x, y) = ⎨ ⎩ false
si sinon
OntoP |= sameAs(x, y) La règle 10 peut être utilisée pour réaliser le matching de ces deux valeurs. la contrainte Co2 va avoir un degré de match plugin puisque Algeria se trouve dans Africa selon l’ontologie Geo. hasResult(?Co, plug _ in) ← hasParameter(?Co,? Po),hasParameterType(? Po,? PTo), hasValueType(?Co,owl),hasValue(?Co,?Vo),hasConstaint(request,?Cr), hasOperator(?Cr,equals _ to),hasParameter(?Cr,?Pr), hasValue(?Cr,?Vr), hasParameterType(?Pr,?PTr),hasValueType(?Cr,owl), is _ located _ in(?Vr,?Vo),exact(? PTo,? PTr)
⎧ true is _ located _ in(x, y) = ⎨ ⎩ false
si sinon
Geo |= locatedin(x, y)
Les prédicats islocatedin , same_instance , plugin et exact sont implémentés comme fonction builtin en utilisant un appel séparé à un moteur d'inférence. 5.2
Dans cette phase les services sont rangés suivant leur degré de match (DoMs). Pour calculer le DoMs nous calculons le degré de match (DoMc) pour chaque contrainte Co issue de la phase de matching en utilisant la méthode citée dans la section 3.2. Le calcul du DoMc est réalisé par la règle suivante : hasDoM (?Co,? DoMc) ← hasResult(?Co,? R), hasResultValue(?Co,? RV ), hasValueType(?Co,?VT ), hasOperator(?Co,?OP), hasValue(?Co,?Vo), hasParameter(?Co,? Po), hasParameterType(? Po,? PTo), computeDoMc(? R,? RV ,?VT ,?OP,?Vo,? PTo,? DoMc) (10) (11) (12)
Enfin la requête SPARQL (algorithme 1) va générer pour chaque NFPo matchant NFPr un ensemble de tuples détaillé qui va être exploiter pour afficher le résultat final à l'utilisateur sous différentes formes.
L’approche proposée à été implémentée en Java .Comme moteur d’inférence nous utilisons KAON2 parce qu’il supporte les règles DL-safe rules et le langage d’interrogation pour RDF SPARQL [22]. Pour le matching de fonctionnalité nous utilisons l’API OWLS-MX [21]. Les ontologies utilisées sont stockées en tant que fichiers .owl dans le serveur web Apache Tomcat2.
Pour des raisons de comparaison nous avons utilisé les données de test de [11], ces données représentent quatre services et une requête avec sept critères de qualité : Price, Transaction, Time Out, Compensation Rate, Penalty Rate, ExecutionDuration
et Reputation (voir Table 2).On a introduit ces paramètres comme concepts dans
l’ontologie "QoS middle ontology" [12].
Paramètre Price Transaction TimeOut ComRat PenRat Execu Repu
requête 30 1 80 0,4 0,8 120 4,0
Poids 4 0 0 2 1 1 2
Opérateur < = = > > < >
NFPo1 25 1 60 0,5 0,5 100 2,0
NFPo2 40 1 200 0,8 0,1 40 2,5
NFPo3 28 1 140 0,2 0,8 200 3,0
NFPo4 55 1 180 0,6 0,4 170 4,0
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 : (
M o D 8,000 6,000 4,000 2,000 0,000 DoM de [11] 6,196 Notre DoM 5,625 1
2 5,500 3,000
3 5,600 3,600
4 3,951 1,334
Services
Fig. 2. Résultats de l'expérimentation
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.