Cours analyse microéconomique, tutoriel & guide de travaux pratiques en pdf.

Architecture globale du systeme

L’architecture du systeme a et divisee en deux parties : une partie pour l’interrogation et l’autre pour l’indexation (Figure 3.1). Notre travail s’appui sur la partie d’interroga-tion dans laquelle l’utilisateur voit le systeme comme une seule interface du Service Web basee sur un systeme intermediaire qui est le systeme mediateur. Ce dernier joue le r^ole d’interface entre l’utilisateur et les sources d’information en donnant l’impression a l’utilisateur qu’il interroge un seul systeme centralis et homogene alors que les sources interrogees sont reparties, autonomes et heterogenes.
Le systeme mediateur est fonde sur la de nition d’un schema global qui fournit un vocabulaire unique pour l’expression des requ^etes des utilisateurs et pour la description des contenus des sources par un ensemble de vues. Il o re a l’utilisateur une vue uni-forme des sources de donnees qu’il exploite et permettre de les interroger d’une maniere transparente sans que l’utilisateur n’ait souci de la provenance des informations ni de leur format d’origine. L’interrogation des sources de donnees est e ectuee par le service d’interrogation QAS (Quering As a Service).
L’utilisateur exprime sa requ^ete en utilisant le vocabulaire fourni par une ontologie. La requ^ete posee sur le schema global necessite une combinaison des Services Web DaaS et de ce fait, elle doit ^etre reformulee par le mediateur en des sous requ^etes sur les sources de donnees (ce qui est necessaire en raison du fait que le schema global lui-m^eme ne contient aucune donnee). Le probleme de la reformulation de la requ^ete (Rewriting) est connu comme etant le probleme de reecriture de requ^ete en termes de vues pour lequel nous proposons un algorithme qu’on va le detailler par la suite.
Figure 3.1 { Architecture globale du systeme

Exemple de motivation

Un Service Web DaaS peut fournir des informations interessantes ; mais dans la plupart des cas, les requ^etes des utilisateurs exigent l’invocation de plusieurs services. Supposons que le medecin Yasmin a la requ^ete suivante Q :  » Donnez Les rapports fournis par le medecin ’p100’ des patients sou rant de la maladie du diabete identi ee par le code ’D5’ et qui sont suivis par des in rmiers travaillant dans le service ’S12’  » .
En e et, Yasmin dispose d’un ensemble de Services Web DaaS representes dans la table 3.1
Table 3.1 { Services Web DaaS proposes
Evidemment, Yasmin utilise ces services pour obtenir une reponse a sa requ^ete. Comme la montre la gure 3.2, Yasmin invoque le service S2 pour trouver la liste (L1) des rapports fournis par le medecin Youcef (etape1), ca veut dire que le code de notre medecin satis-fait la contrainte ’a<p150’. Dans la deuxieme etape, elle invoque le service S5 puisque le code du service concern satisfait la contrainte ’a<=S18’ et cela pour trouver la liste (L2) des in rmiers travaillant dans le service ’S12’. Notons que les etapes 1 et 2 peuvent ^etre executees en parallele. Ensuite, elle invoque le service S6 pour chaque in rmier de la liste (L2) pour obtenir la liste des patients (L3) qui les suit. Apres cette etape, elle invoque le service S3 pour chaque patient de la liste L3 a n de trouver la liste L4 contenant les maladies dont il sou re. Dans l’etape 5, elle va ltrer la liste L4 en prenant les tuples dont la deuxieme partie fait reference a ’D5’ ce qui nous donne la liste (L5). Yasmin va invoquer le service S7 pour chaque patient de L5 pour trouver les rapports qui lui concerne (etape 6), le resultat de cette etape est mis dans la liste L6. En n, Yasmin va e ectuer une intersection entre les listes L1 et L6 et donc, elle obtient une reponse a sa requ^ete posee.
Figure 3.2 { Scenario de motivation propose

Les enjeux

Notre scenario montre que Yasmin a besoin d’e ectuer plusieurs t^aches pour executer sa requ^ete. Ces t^aches peuvent notamment ^etre fastidieuses lorsque le nombre de services est important. Premierement, Yasmin a besoin de comprendre la semantique des services DaaS existants et les relations entre les parametres d’entree et de sortie pour chaque service. Deuxiemement, elle a besoin de selectionner manuellement les services qui sont pertinents a sa requ^ete et les invoquer dans le bon ordre. Elle doit aussi comprendre le plan d’execution pour sa requ^ete. Troisiemment, Yasmin a besoin de consolider les resultats et e ectuer manuellement des jointures potentielles ou un ltrage des resultats comme mentionn dans les etapes 5 et 7 du scenario.

Apercu de l’approche proposee

Nous proposons une approche de reecriture de requ^etes pour la composition automa-tique de Services Web DaaS comme la montre la gure 3.3. Elle suppose l’existence d’une ontologie de mediation pour capturer les connaissances consensuelles et partagees dans un domaine donne (domaine medical dans notre cas). Les Services Web DaaS sont mode-lises par des vues RDF a partir de l’ontologie de mediation. Les vues RDF capturent les relations semantiques entre les parametres d’entree et de sortie en utilisant les concepts ontologiques de nis dans l’ontologie de mediation, elles sont enregistrees dans l’annuaire des services.
Figure 3.3 { Apercu de l’approche proposee
Les utilisateurs posent leurs requ^etes en utilisant le langage de requ^ete SPARQL. Le WSMS (Web Service Management System) utilise un module de re ecriture de requ^ete RDF et les vues RDF existantes pour selectionner les services qui peuvent ^etre combines pour repondre a la requ^ete posee. Ensuite, il genere un service composite, il l’execute et il retourne les donnees demandees a l’utilisateur. Le service composite gener peut ^etre aussi deploy comme un nouveau service DaaS et utilise pour repondre a d’autres requ^etes.

Services DaaS et modele de requete

Ontologie de mediation

Dans l’approche proposee, les utilisateurs formulent leurs requ^etes a partir d’une onto-logie de mediation. Cette derniere est decrite en RDF/RDFS. Formellement, une ontologie de mediation OM est de nie par 6 tuples (C,D, T P , OP , SC, SP ) ou :
{ C est l’ensemble de Classes.
{ D est l’ensemble de DataTypes.
{ DP est l’ensemble de DataType Properties. Chaque DataType Property a un do-maine dans C et un co-domaine (range) dans D.
{ OP est l’ensemble des Object Properties. Chaque Object Property a son domaine et co-domaine dans C.
{ SC est une relation dans (C C), representant les relations sub-class of entre les classes. Par exemple, C2 SC C1 signi e que C2 est une sous classe de C1.
{ SP est une relation dans [(OP OP) [ (DP DP)]. Elle represente les relations sub-property of entre les Properties dans OP ou dans DP. Par exemple, p2 SP p1 signi e que p2 est une sous propriet de p1.
Figure 3.4 { Ontologie de mediation proposee
La gure 3.4 represente notre ontologie de mediation proposee concernant le domaine medical. Prenons les trois concepts Patient, Medecin et Service, notre ontologie speci e que le patient est traite par un medecin et ce dernier travaille dans un service. Un Service a deux caracteristiques (DataTypes) qui sont le Code et le N om. Les concepts sont relies entre eux par des Object Properties et aux DataTypes via les DataType Properties.

Requete

On considere les requ^etes conjonctives a partir d’une ontologie de mediation. Les re-qu^etes sont exprimees en utilisant SPARQL. Formellement une requ^ete Q a la forme suivante : Q(X) : G(X; Y ) ou
{ Q(X) est appel l’ent^ete de la requ^ete, elle a la forme d’un predicat relationnel. { X sont appelees les variables de l’ent^ete ou les variables distinguees.
{ Y sont appelees les variables existentielles.
{ G(X; Y ) est appel le corps de la requ^ete, et est un ensemble de triplets RDF ou chacun a la forme sujet.propriet .objet. Le corps peut egalement contenir des contraintes sur les variables du corps de la forme : x CONSTANT, ou : 2 f>, ,<, g:
Les deux gures 3.5 et 3.6 montrent la representation graphique et SPARQL de la requ^ete Q :  » Donnez Les rapports fournis par le medecin ’p100’ des patients sou rant de la maladie du diabete identi ee par le code ’D5’ et qui sont suivis par des in rmiers travaillant dans le service ’S12’  » .
Figure 3.5 { Representation graphique de la requ^ete Q
Figure 3.6 { Representation SPARQL de la requ^ete Q
Une requ^ete peut ^etre vue comme un graphe avec deux types de noeuds :
{ Noeuds Classe : un noeud classe se refere aux classes dans l’ontologie de media-tion (exemple : P et R). Ils sont relies via les Object Properties et representent les variables exitentielles de la requ^ete.
{ Noeuds Litteraux : ils representent les DataTypes (exemple : x2, y2,z2). Ils sont lies avec les noeuds classe via les DataType Properties. Les noeuds litteraux peuvent correspondre aux deux variables existentielles et distinguees.

Vue RDF Parametree (RPV)

Nous modelisons les Services DaaS par des RPVs 9 a partir de l’ontologie de mediation. Les RPVs utilisent les concepts et les relations de l’ontologie de mediation pour capturer la relation semantique entre l’entree et la sortie. Une RPV exige un ensemble particulier des entrees a n de recuperer un ensemble particulier des sorties. Ces dernieres ne peuvent pas ^etre recuperees sauf si les entrees sont liees.
Une RPV peut ^etre vue comme une requ^ete SPARQL parametree. Formellement, une RPV d’un Service DaaS Si a partir d’une ontologie de mediation est un predicat Si(Xi; Y i) : < (Xi; Y i; Zi); Cti >; ou :
{ Xi est l’ensemble des variables indiquant les parametres d’entree necessaires pour invoquer Si , elles sont appelees les variables d’entree.
{ Y i est l’ensemble des variables designant les litteraux retournes apres l’invocation du Si, elles sont appelees les variables de sortie. Les variables d’entree et de sortie sont egalement appelees les variables distinguees.
{ (Xi; Y i; Zi) represente la relation semantique entre les variables d’entree et de sortie. Zi est l’ensemble des variables existentielles reliant Xi et Y i. a la forme de triplets RDF ou chaque triplet a la forme sujet. propriet .objet.
{ Cti sont les contraintes imposees sur les variables Xi, Y i ou Zi. Une contrainte a la forme : CONSTANT, ou : x 2f>, ,<, g 9. RDF Parameterized Views
Nous presentons ci-dessous les RPVs de nos services DaaS representes dans le Tableau 3.1. Chaque RPV est caracterisee par un modele d’acces ; ce dernier speci e les parametres d’entree et de sortie. Les variables d’entree et de sortie sont pre xees respectivement par les symb^oles « $ » et « ? ».