IV.2.2. Agent administrateur
· visualise l'interface principale du système aux
utilisateurs ;
· lance les agents services pour les services
déjà sélectionnés ;
· lance l'agent médiateur et lui envoie la liste des
identificateurs des agents service ;
· lance un agent utilisateur lorsqu'un utilisateur
s'identifie et se connecte pour
passer une demande de service et lui envoie
l'identificateur de l'agent médiateur;
· vérifie identité administrateur lorsque
celui-ci veut se connecter.
1. Architecture interne
C'est un agent réactif. Selon sa perception, il agit. Il
contient les deux composantes suivantes lui facilitant son fonctionnement :
· Une base de connaissances : elle
contient les identificateurs de l'agent médiateur et des agents services
permettant leurs lancement et l'identificateur de l'administrateur du
système permettant la vérification de l'identité
entrée par l'administrateur (confidentialité).
· Une procédure de vérification :
c'est une procédure permettant de vérifier
l'identité de l'administrateur.
2. Fonctionnement
Perception :
- Réception d'une requête utilisateur ou
administrateur de connexion (depuis l'interface).
- Réception de l'identificateur de l'administrateur.
Raisonnement : son raisonnement consiste
à vérifier l'identificateur de l'administrateur et selon le
résultat de la vérification, il agit.
Action : il agit selon le diagramme
d'activités de la « figure 4.11 » suivante : IV.2.3.
Agent service
· C'est une entité très importante pour
l'élaboration du processus de planification ; il sert à enrichir
le domaine de planification du planificateur se trouvant au niveau de l'agent
médiateur ;
· Récupère la description OWL-S du service
qu'il représente de son fournisseur ;
· Il le convertit vers un ensemble d'opérateurs
PDDL ;
· Suite à la réception du problème
de planification (requête utilisateur) de l'agent médiateur, il
essaye à trouver une action permettant de le résoudre directement
: s'il le trouve, il l'indique à l'agent médiateur ; sinon il
cherche l'ensemble d'actions permettant de le résoudre partiellement et
il les envoie à l'agent médiateur.
Attente
Valide
Non valide
Afficher erreur
Afficher interface
Principale système
Lui envoyer l'ident
de l'agent médiateur
Recevoir demande connexion utilisateur
Lancer
un agent utilisateur
Lui envoyer les idents des agents service
Lancer
Agent médiateur
Lancer
Agents service
Recevoir demande
connexion administrateur
Recevoir Identificateur
administrateur
Afficher menu
système
Figure 4.11 : Diagramme d'activités pour
le fonctionnement de l'agent administrateur 1. Architecture
interne
Comme déjà indiqué
précédemment, cet agent est de type cognitif. En plus de son
module de communication, il contient : une base de connaissances, une base de
compétences, un traducteur des descriptions OWL-S vers des
opérateurs STRIPS et une procédure de parcours des
opérateurs dans le but de chercher un ensemble d'opérateurs
résolvant tout ou une partie du problème soumis par l'agent
médiateur. Une présentation de l'architecture interne de cet
agent est donnée dans la « figure 4.12 » suivante :
· La base de connaissances : chaque
agent service en plus de la description OWL-S est initialisé avec un
ensemble de données (issue d'une base de données par exemple)
permettant à l'agent de raisonner. Par exemple, un agent
représentant un service de réservation de transport aérien
dispose de la liste des trajets existants. Ces données forment la base
de connaissances de l'agent.
Service
Problème
OWL-S
Agent service
Procédure parcours
des opérateurs
Traducteur
OWL-S vers STRIPS
Ensemble De données
Opérateurs STRIPS
Base de
compétences
Base de
connaissances
Figure 4.12 : Architecture interne de <<
l'agent service >>
· La base de compétences :
À partir de la description sémantique, les agents
service vont créer leur domaine de planification qui regroupe, sous la
forme d'opérateurs STRIPS extraits des processus de la description
OWL-S, les actions réalisables par les agents, i.e., leur base de
compétences.
· Le traducteur OWL-S vers STRIPS :
puisqu'un modèle de composition par planification est
exploité l'une des phases les plus importantes dans le processus de
composition de services est la traduction des descriptions OWL-S des services
sélectionnés à des domaines de planification
(opérateurs STRIPS). C'est ce module de l'agent service que la
permet.
Les étapes de traduction seront détaillées
dans ce paragraphe.
Ce traducteur prend en entrée une description OWL-S du
<< model de processus >> (process model en anglais) du service
représenté par l'agent et produit en sortie un ensemble
d'opérateurs STRIPS (domaine de planification).
OWL-S Process model du service
Traducteur
OWL-S vers PDDL
Ensemble d'opérateurs STRIPS
Dans ce qui suit, nous donnerons premièrement un
ensemble de restriction que nous avons apportées aux descriptions OWL-S
des services, puis nous détaillerons l'algorithme de traduction.
· Restriction sur la sémantique
OWL-S
Le langage OWL-S qui permet d'annoter sémantiquement un
service web est très riche et n'impose que très peu de
contraintes sur la manière d'exprimer cette sémantique. Les
chercheurs dans ce domaine et parmi << J.Guitton >> [1] font
toujours donc un ensemble de restrictions et d'hypothèses. Vu du cadre
et de la période de l'étude, nous avons adoptées de faire
une restriction de la restriction de ce chercheur (l'objectif de notre travail
n'est pas en effet de faire quelque chose qui n'existe pas,
mais de prouver juste l'efficacité de la planification
pour la résolution du problème de composition de services
web).
- Un model de processus d'un service en OWL-S peut contenir
trois types de processus en savoir : les processus atomiques, composites ou
simples, mais seuls les processus atomiques sont pris en compte actuellement
dans notre modèle ;
- Plusieurs formalismes existent pour résoudre les
problèmes de planification, dans notre modèle le formalisme
STRIPS est celui qui a été utilisé, dont un
problème de planification est défini par un ensemble
d'opérateurs, d'un état initial et d'un but à
atteindre.
- nous spécifions les préconditions et les
effets des processus atomiques dans le formalisme STRIPS, comme
représenté dans l'extrait ci-dessous, afin de permettre leur
utilisation directement lors de la création du domaine ;
<process:hasPrecondition>
<expr:KIF-Condition rdf:ID="ExistTrain">
<expr:expressionBody rdf:
datatype="
http://www.w3.org/2001/XMLSchema#string">
(ExistTrain ?From ?To)
</expr:expressionBody>
</expr:KIF-Condition>
</process:hasPrecondition>
? Algorithme de traduction
La traduction de la description sémantique d'un service
vers un domaine de planification consiste à représenter les
processus atomiques OWL-S sous forme d'opérateurs.
L'algorithme « algorithme 4.1 » parcourt le model de
processus du service, chaque fois qu'il rencontre un processus atomique, il le
transforme à un opérateur.
|
Algorithme 4.1 : traduire OWL-S vers STRIPS(P)
Input : model de processus OWL-S « P » Output : ensemble
d'opérateurs STRIPS « OS » OS = Ø ;
Pour chaque processus atomique p
de P faire
Créer nouvel opérateur op ;
op.nom = p.nom ;
op. Paramètres = p.inputs + p.outputs ;
op.préconditions = p.précoditions ; ajouter op à OS
;
Fin pour
Retourner OS ;
Fin
|
En effet, la correspondance ici est directe. Un
opérateur de planification est créé, avec, comme
identifiant, l'identifiant de ce processus, c'est-à-dire le nom de
l'opération du service correspondant. Par exemple, le processus atomique
suivant :
<process:AtomicProcess rdf:ID="AgentTrainReservation">
...
</process:process>
Permet de définir l'opérateur :
(:operator (!AgentTrainReservation ...) ...
)
Puis les préconditions et les effets du processus atomique
sont ajoutés à l'opérateur correspondant.
La « figure 4.13 » suivante présente la
correspondance entre processus atomique OWL-S et un opérateur STRIPS
:
Processus atomique OWL-S
Nom processus atomique
Précondition
Output
Effet
Input
Opérateur STRIPS/PDDL
Nom opérateur
Précondition
Paramètres
Effet
Figure 4.13 : Correspondance processus atomique
OWL-S et opérateur STRIPS
Gestion des préconditions : Les
préconditions d'un processus ont une correspondance directe avec les
préconditions d'un opérateur, du fait de l'hypothèse
formulée sur l'écriture des préconditions et effets dans
la description OWL-S. Soit la précondition OWL-S suivante :
<process:hasPrecondition> <expr:KIF-Condition
rdf:ID="ExistTrain">
<expr:expressionBody rdf: datatype="
http://www.w3.org/2001/XMLSchema#string">
(ExistTrain ?From ?To) </expr:expressionBody>
</expr:KIF-Condition>
</process:hasPrecondition>
De cette précondition est extrait directement le
prédicat suivant :
(ExistTrain ?From ?To)
Gestion des effets : Tout comme les
préconditions, les effets d'un processus atomique sont traduits
directement. Mais ils doivent être distingués en effets positifs
et en effets négatifs au moment de la création de
l'opérateur. Nous choisissons de représenter les effets
négatifs, dans la description OWL-S par des prédicats
commençant par not [1]. Par exemple, la réservation d'un billet
de train a pour effet de déplacer l'utilisateur d'une ville à une
autre :
<expr:KIF-Expression rdf:ID="NotVoyagerAtFrom">
<expr:expressionBody rdf:
datatype="
http://www.w3.org/2001/XMLSchema#string">
(not(at ?User ?From ?Date))
</expr:expressionBody>
</expr:KIF-Expression>
· Le module de parcours : c'est une
procédure permettant de chercher soit une solution directe au
problème de planification envoyé par l'agent médiateur,
sinon de chercher l'ensemble d'opérateurs possibles pouvant servir
à la résolution du problème.
Comme nous avons déjà vu, le problème
à résoudre est représenté a travers un ensemble de
prédicats formant l'état initial (entrés par
l'utilisateur) et un ensemble d'autres prédicats formant le but à
réaliser (entrés aussi par l'utilisateur), ainsi, les
opérateurs STRIPS (extraits de la description OWL-S) sont aussi
représentés par un ensemble de prédicats formant ses
préconditions et un autre formant ses effets.
La recherche est donc faite par parcours des deux bases de
connaissances et de compétences, afin de trouver des correspondances
possibles entre les prédicats de l'état initial et du but avec
ceux des préconditions et des effets des opérateurs STRIPS
respectivement.
Trois cas sont possibles ici :
1. suite à la réception d'un problème de
planification (état initial et but) de l'agent médiateur, si une
correspondance entre l'état initial et l'ensemble des
préconditions d'un opérateur et une correspondance entre
l'état but et les effets de ce même opérateur sont
trouvées ; alors cet opérateur constitue une solution directe du
problème à retourner à l'agent médiateur.
2. Si ce n'est pas le cas, la procédure cherche alors
tous les opérateurs dont leurs effets sont correspondants à
l'état but du problème. La liste des opérateurs
trouvés ainsi que pour chacun la liste de ses préconditions sont
alors retournées à l'agent médiateur.
3. Si aucune des deux solutions précédentes n'est
trouvées, l'agent service retourne alors un message à l'agent
médiateur lui indiquant l'absence d'une solution.
2. Fonctionnement
Perception :
- Réception d'un message contenant le problème
à résoudre d'après l'agent médiateur.
- Réception d'un message de l'agent médiateur
pour arrêter le processus de recherche de la solution (dans le cas
où la solution est déjà trouvée ou l'utilisateur
demande d'annuler la résolution de son problème).
Raisonnement : suite à la
réception du problème à résoudre de l'agent
médiateur, cet agent exécute la procédure de parcours
énoncée précédemment. Le résultat de la
recherche : soit une solution directe, soit une liste d'actions est en suite
envoyé à l'agent médiateur. S'il n'y a pas de
résultats à retourner, l'agent envoie un message à l'agent
médiateur lui indiquant ceci.
Action : il agit selon le diagramme
d'activités suivant :
Attente
Recevoir problème
du médiateur
Recevoir demande
d'arrêt du médait
Exécuter procédure
de recherche
Arrêter procédure
de recherche
Solution directe trouvée
Non solution trouvée
Non solution directe trouvée
Envoyer solution directe au médiat
Envoyer liste
d'actions au médiat
Envoyer message (non solution)au médiat
Figure 4.14 : Diagramme d'activités pour
le fonctionnement de l'agent service
| 
