services [3]. Dans ce paradigme, l’objectif n’est plus de construire l’architecture organique d’une application par la connexion d’un ensemble de composants. Il s’agit de réutiliser un ensemble de fonctionnalités, fournies par un ensemble de serveurs, par la définition de processus contrôlant l’invocation des fonctionnalités pour produire des fonctionnalités de plus haut niveau. En fonction de la logique d’exécution du processus, centralisée ou distribuée, ces processus sont appelés des orchestrations ou des chorégraphies de ser-vices. L’approche SCA (Service Component Architecture) [110] propose une convergence entre les paradigmes composants et services. Un service y est représenté par un compo-sant possédant une interface fournie documentant le service. Une orchestration de ser-vice est encapsulée dans un composant exposant sous forme d’interfaces requises tous les services qui doivent être invoqués par l’orchestration. Il est alors possible de mettre en
CHAPITRE 2. SYNTHÈSE DES CONTRIBUTIONS
œuvre une orchestration de services par la connexion d’un ensemble de composants. Nous avons étudié la conception et l’implémentation d’architectures SCA pour contrô-ler des environnements intelligents, reposant sur l’utilisation des fonctionnalités fournies par un ensemble d’objets connectés. Nous avons adapté une partie de ces travaux, dans le contexte des webservices, pour proposer la gestion d’orchestrations BPEL génériques et de mécanismes de remplacement dynamiques de services [23][24][22].
Ces environnements intelligents ont pour caractéristique d’être dynamiques, ouverts et partagés. Ces environnements sont ainsi soumis à de nombreux changements : dis-ponibilité des objets connectés et de leurs services (fiabilité et mobilité) ; évolution des besoins des utilisateurs (déploiement de nouvelles orchestrations ou modification des orchestrations existantes). Pour maintenir la continuité des services rendus aux utilisa-teurs, il est nécessaire que les applications (orchestrations) s’adaptent automatiquement aux changements qui surviennent dans leurs contextes d’exécution. Nous avons ainsi étu-dié les concepts de sensibilité au contexte [108] et d’adaptation autonomique [105].
Notre conception de ces mécanismes a été fortement influencée par les systèmes multi-agents [56][124], dont le paradigme repose sur la capacité des agents à percevoir leur environnement, à raisonner sur ces perceptions et à agir de manière autonome pour réaliser un ensemble d’objectifs. Notre idée est de concevoir des agents capables de per-cevoir les changements du contexte d’exécution et d’y réagir de manière autonome en adaptant les architectures logicielles afin de maintenir la continuité de leurs fonctionna-lités.
Dans SAASHA [66][67][65], nous avons étudié une forte intégration des paradigmes agents et composants. Les agents sont définis par une architecture interne à base de composants (voir la figure2.19). Parmi ces composants, on distingue premièrement les composants d’infrastructure (en gris clair) gérant le modèle d’agents. Le composant De-tector gère la sensibilité au contexte et permet à l’agent de détecter automatiquement la présence d’objets intelligents et d’autres agents dans son environnement (par utilisa-tion du protocole UPnP [71]). Les composants Registry gèrent les informations recueillies par l’agent sur son environnement (AgentRegistry, DeviceRegistry, ScenarioRegistry) mais également sur son architecture interne (ComponentRegistry). Les agents ont la capacité de modifier de manière réflexive leur architecture interne pour l’adapter aux change-ments de leur environnement (en utilisant le support du framework OSGi [64]). Ainsi, le composant ComponentGenerator a la capacité de générer des composants permettant de contrôler les objets intelligents détectés (composants en bleu moyen sur la figure 2.19). De même, il génère des composants coordinateurs (en bleu foncé sur la figure), chargés d’exécuter des orchestrations de services correspondant aux scénarios définis par les uti-lisateurs.
Ces scénarios sont définis sous la forme d’ensembles de règles ECA (Evenement, Condi-tion, Action) diffusés aux agents contrôleurs et enregistrés dans leur composant Scenario-Registry. Ces règles utilisent une typologies des services fournis par les objets connectés distinguant les services permettant de détecter des événements, d’obtenir une informa-tion ou de réaliser une acinforma-tion (voir la figure2.20). Saasha propose ainsi un framework per-mettant de définir, déployer et exécuter des scénarios définis par les utilisateurs. L’exécu-tion des scénarios peut être distribuée sur l’ensemble des agents présents dans
l’environ-CHAPITRE 2. SYNTHÈSE DES CONTRIBUTIONS
FIGURE2.19 – Architecture interne des agents du framework Saasha
nement, par exemple en fonction de leur capacité à contrôler certains objets (localisation) ou de leur charge.
Nous avons prolongé ces travaux en travaillant sur le framework SAAS [54][55][53]. SAAS propose un langage d’orchestration, basé sur un ensemble classique de structures de contrôle, permettant de définir des scénarios plus élaborés (voir la figure2.21). Ces or-chestrations, encapsulées dans des composants orchestrateurs générés dynamiquement, peuvent être éventuellement réutilisées en tant que service à part entière. Ces orches-trations supportent directement la sensibilité au contexte en proposant des formes de quantification universelle ou existentielle dans la définition des invocations de services (invocation d’une instance quelconque d’un certain type de service ou de toutes les ins-tances disponibles d’un certain type de service). On peut ainsi définir des scénarios du type "quand un service de type horloge indique qu’il est 19h, déclencher tous les services de type fermeture de volets disponibles" (la portée du scénario étant alors limitée par le réseau local sur lequel la détection des services est réalisée).
SAAS propose également un modèle de contrôle permettant l’exécution transaction-nelle, pas-à-pas, des orchestrations. Ainsi, l’exécution des orchestrations peut-être sus-pendue en cas de problème d’invocation d’un service et reprise lorsque le service est dis-ponible. SAAS supporte ainsi la mobilité des objets ou des utilisateurs mais également le partage des services et la distribution de l’exécution, autant d’éléments pouvant in-fluencer la disponibilité des services invoqués. En fonction de la déclaration du service attendu, le service initialement associé à l’orchestration peut être remplacé par un ser-vice équivalent. En cas d’indisponibilité prolongée, dépassant une limite de temps fixée, l’exécution de l’orchestration est abandonnée et son échec est signalé.
CHAPITRE 2. SYNTHÈSE DES CONTRIBUTIONS
FIGURE2.20 – Définition de scénario à l’aide de règles ECA dans Saasha
propose de définir le comportement du système à l’aide d’un langage de missions (voir la figure 2.22). Le comportement du système est structuré en un ensemble de modes. Chaque mode représente le comportement attendu du système pour gérer une situa-tion donnée. Un ensemble de règles, déclenchées par des évènements et condisitua-tionnées par des gardes, gère les changements de modes. Ils constituent un premier mécanisme d’adaptation du comportement.
Chaque mode est défini par un ensemble de missions représentant les différentes ac-tivités que le système doit réaliser dans le mode courant. Les missions sont réparties en trois niveaux de priorité. En fonction des ressources disponibles, le système maintient de manière préférentielle les missions obligatoires (mandatory), importantes (high) puis les missions de routine (normal). Pour permettre un ajustement plus fin du déploiement des missions en fonction des ressources, chaque mission est décrite par un ensemble de stra-tégies. Une stratégie décrit non seulement une solution de déploiement de la mission, définie par comme un ensemble de tâches consommant des ressources matérielles, mais également l’efficacité de la solution, exprimée comme l’utilité du service rendu aux utili-sateurs (en d’autres termes une mesure agrégée de qualité de service). Etant donné l’en-semble des missions à réaliser dans le mode courant, l’objectif du système Arold est de déployer l’ensemble des missions qui maximise l’utilité du système pour les utilisateurs, compte tenu de la priorité des missions du système et des ressources éventuellement li-mitées.
CHAPITRE 2. SYNTHÈSE DES CONTRIBUTIONS
FIGURE2.21 – Le langage d’orchestration de services SAS SDL
Grâce au langage de missions, nous avons conçu le mécanisme de déploiement comme un problème d’optimisation combinatoire de type sac à dos (knapsack problem)[74]. Le mécanisme de déploiement est géré par un système multi-agents capable de calculer un (re)-déploiement des missions pour l’adapter aux changements du contexte d’exécution (disponibilité des agents et des ressources). Chaque agent est embarqué sur une plate-forme matérielle et dispose d’un ensemble de composants lui permettant de contrôler les périphériques connectés à la plateforme (voir la figure2.23). Par détection ou configu-ration, chaque agent dispose d’une liste des autres agents présents dans leur environne-ment. Lors de leur activation, les agents exécutent un protocole de formation de commu-nauté et élisent pour leader l’agent disposant des meilleures ressources. Le leader collecte les informations sur les capacités (composants) et les ressources des autres agents de la communauté. Il calcule alors un déploiement optimisé des missions du système, à l’aide d’un algorithme glouton s’appuyant sur une estimation probabiliste de consommation de ressources. Ce mécanisme de déploiement, conçu de manière centralisés et gloutonne pour limiter le temps de calcul et la consommation de ressources, est adaptée aux sys-tèmes embarqués et à une gestion dynamique de la reconfiguration du système en fonc-tion des changements de contexte.
Une fois le calcul du déploiement réalisé, le leader indique à chaque agent de la com-munauté les différentes tâches qu’il doit exécuter pour participer à l’exécution des stra-tégies qui ont été sélectionnées. Le leader exécute alors une tâche de surveillance de la communauté et de l’exécution des missions. En cas de changement, le leader calcule un nouveau déploiement des missions. Ce redéploiement s’appuie éventuellement sur un modèle de tâches mobiles pouvant migrer entre les agents. Les agents de la communauté testent régulièrement la présence du leader. En cas de défaillance, le processus d’élection d’un nouveau leader est déclenché.
CHAPITRE 2. SYNTHÈSE DES CONTRIBUTIONS
FIGURE2.22 – Exemple d’un descripteur de missions Arold
Arold propose ainsi différents mécanismes permettant aux agents de prendre en charge de manière autonome l’adaptation du comportement du système en fonction du contexte : localisation des périphériques, consommation des ressources matérielles (CPU, mémoire, disque, batterie, réseau, ...), communications réseau perturbées (apparition/disparition d’agents).
SAASHA et SAAS sont destinés à contrôler des objets connectés dans des environne-ments intelligents d’assistances aux personnes (Ambient Assisted Living). Arold est des-tiné à gérer un réseau de balises de surveillance de risques hydrologiques. Les implémen-tations prototypes de ces systèmes utilisent les technologies OSGi [64], pour la gestion des composants, et UPnP [71], pour la gestion des services. Nous nous sommes
égale-CHAPITRE 2. SYNTHÈSE DES CONTRIBUTIONS
FIGURE2.23 – Architecture du système Arold
ment appuyés sur les travaux que nous avons menés sur la fiabilisation des systèmes multi-agents, par la gestion des exceptions concurrentes dans les middlewares orientés messages [114][116][115][117][36][51] et les systèmes multi-agents répliqués [50].
Les travaux sur SAAS sont détaillés en partie par l’article présenté dans la section4.2.5
et inclus dans l’annexeF.