3.1 Vers une gestion plus haut-niveau des services
3.1.1 Principe général
3.1.3 Intégration de besoins et de services à la volée . . . . 60
3.2 Construction et exécution d’un plan opportuniste . . . . 73
3.2.1 Approche générale . . . . 73 3.2.2 Algorithme d’exploration et de recherche d’optimum : vers un
choix optimisé . . . . 79 3.2.3 Autre algorithme témoin pour tests de performance : glouton 82 3.2.4 Évaluation de résultat des algorithmes et validation des
contraintes . . . . 84 3.2.5 Exemple complet d’application des algorithmes et comparaison
de résultats . . . . 84
Une première étape nécessaire pour le système était qu’il soit capable de ré-pondre à différentes problématiques, notamment la gestion de la dynamicité et la possibilité de définir des comportements haut-niveau. De plus, un point primordial est d’analyser les évènements qui occurrent sur le système supervisé et de déduire de manière autonome quels sont les éléments à récupérer, envoyer, contrôler, etc. Cet aspect fonctionnel a été mis en place à travers une architecture adaptée et l’instanciation de modèles sémantiques et de grammaires de graphes pour que le système puisse automatiquement analyser et déduire les informations nécessaires jusqu’à l’élaboration de plans d’exécution à base de services. Le système proposé est également capable de gérer la mutualisation de services dans les plans d’exécu-tion générés à l’aide d’un processus de transformad’exécu-tion de graphes.
Cependant, les services étaient considérés jusqu’à présent comme interopérables et étant directement utilisables. Par exemple, dans le cas où une personne est in-téressée par une donnée de qualité de l’air à une adresse spécifique, cette donnée est accessible directement par l’appel du service associé. Dans certains cas il se peut qu’un service (capteur) soit directement accessible à la position géographique
concernée mais dans d’autres situations cela peut être différent. Dans le cas où il n’y a pas de service directement accessible, il est cependant envisageable d’utiliser un service complexe qui devra être déterminé automatiquement par le système en se basant sur des services disponibles et des informations comme la position de l’utilisateur que ce dernier aura communiquée.
Ce comportement va se traduire par une intégration de besoins dans la RFC afin de remplir l’objectif initial dans le cas où il n’y a pas de services et de solution exécutable en l’état. Par exemple, si une personne est intéressée par une donnée de qualité de l’air à sa position, le système pourra générer un besoin possédant en entrée cette position et qui attend une donnée de qualité de l’air.
De plus, un aspect important qui n’était pas considéré jusqu’à présent sont les propriétés non fonctionnelles : comment intégrer dans cette architecture et ces modèles une considération de paramètres QoS comme le temps d’exécution, le coût énergétique ou encore le coût monétaire de l’exécution des plans produits.
Pour ce faire des enrichissement des modèles proposés dans le chapitre précédent sont nécessaires pour compléter le comportement existant et définir une grammaire de plus haut-niveau pour la gestion des services. Cette grammaire de graphes avan-cée est présentée afin de gérer la résolution de besoins générés à la volée par le système et d’intégrer des services complexes composites dans le plan d’exécution.
De plus, suivant les scénarios d’utilisation, il peut être important de réduire (optimiser) certains paramètres QoS mais aussi de contraindre le système. En consi-dérant différents paramètres non fonctionnels, il est alors possible de réaliser des choix optimisés lors de l’exécution des plans générés automatiquement pas le sys-tème. Pour ce faire des algorithmes d’exploration des graphes transformés sont proposés afin de déterminer quel plan exécuter dans le cas où il y aurait plusieurs possibilités. Un premier algorithme dit glouton permet de trouver de manière op-portune une solution dans le cas où il y a un plan exécutable et permet de servir de référence en terme de performance de résultat, et un algorithme plus complexe
op-timisé permet de trouver un optimum (global, et local dans un cas particulier) dans
les plans d’exécutions. Des contraintes sur ces paramètres sont également intégrées dans le modèle.
3.1 Vers une gestion plus haut-niveau des services
Ici, on se focalisera sur l’étape de génération de plans d’exécution qui implique le modèle à base de grammaires de graphes. Le principe étant à partir du graphe généré par l’analyseur, d’être capable de construire un pseudo-plan de composition et ensuite d’exécuter un plan optimisé si possible.3.1.1 Principe général
Jusqu’à présent les scénarios traités se concentraient sur une gestion de contenu que ce soit récupération de contenu ou diffusion aux cibles concernées en utilisant
3.1. Vers une gestion plus haut-niveau des services 57
les moyens à disposition et en considérant que les contenus étaient récupérables (resp. affichables) via l’utilisation directe d’un seul service.
Afin d’enrichir ce scénario il est possible de généraliser cette approche en incluant d’autres comportements liés à des services : services de déplacement, réservation, etc. De plus, il est également possible que les services de production de contenu nécessitent le recours à des services de traitement intermédiaire avant de transmettre le contenu aux services de consommation de contenu. Enfin, dans le cas où il n’y a pas de service qui réponde directement au besoin, le système peut chercher à construire un service composite dynamiquement en se basant sur les informations connues et le besoin à cet instant particulier. Un exemple simple réside dans le cas où un utilisateur souhaite accéder à une donnée de qualité de l’air à son adresse mais qu’aucun capteur ne couvre cette zone. Il peut alors partager sa position et le système va générer un besoin à l’aide de cette position qui attend une donnée de qualité de l’air. Ce besoin sera instancié via l’utilisation de plusieurs services qui vont permettre de récupérer la zone géographique correspondant à l’adresse donnée, puis récupérer la valeur de qualité de l’air connue ou estimée sur cette zone. (Principe présenté en Figure 3.1.)
S2 ?
Adresse Qualité del’air
S1 Sa S2
Adresse Qualité del’air
S1 Sb
Zone (localisation)
?
Figure 3.1 – Principe de besoin et de résolution dynamique
Dans ce contexte plus complexe, non seulement des contenus peuvent être utili-sés et diffuutili-sés mais aussi des besoins vont être récupérés et devront être traités. Par exemple un passager d’un bus intéressé dans certaines informations va pouvoir rece-voir le contenu suivant différents moyens mais aussi découvrir un nouvel évènement qui l’intéresse particulièrement et décider de s’y rendre. Pour ce faire il va générer dynamiquement un nouveau besoin de déplacement depuis sa position actuelle jus-qu’au lieu de l’évènement via les services de déplacement accessibles. Cependant, il est nécessaire qu’il soit sur place avant une certaine heure pour pouvoir accéder à l’évènement tant que celui-ci est accessible. De ce fait cela va pouvoir inclure des contraintes temporelles dans les différents services qui seraient utilisés.
Afin d’être capable de traiter ces différents éléments, le système a besoin d’une gestion plus complexe des services considérés ainsi que de prendre en compte des paramètres non-fonctionnels ou de QoS. De plus, les graphes vont être complexifiés en intégrant des possibilités plus riches entre les différents services via l’utilisation de nœuds supplémentaires dans les graphes à transformer et les plans d’exécution générés.
De nouveaux éléments vont être inclus dans le modèle : prise en compte de besoins à instancier, d’objectifs et de contraintes.