Objets autonomes

Sur un Hôte ℎ, les tâches réalisées par chaque Agent 𝑎 s’inscrivent dans le cycle normal d’opérations de ℎ. Certaines opérations sur ℎ doivent par contre être réalisées hors de ce cadre itératif régulier : des interactions avec un usager dans une application reposant sur ContextAA, par exemple; la mise à jour de 𝑁ℎ lors de la disparition ou de l’apparition d’Hôtes voisins; la

transmission et la réception de Contexte entre Hôtes; l’exposition ou la consommation de services en interaction avec des composants tiers; les opérations d’entrée/ sortie autres que celles requises au démarrage ou lors de l’arrêt d’un Hôte; etc.

142

Pour ces tâches, ContextAA utilise des objets autonomes. Un objet autonome est une entité encapsulant une unité d’exécution concurrente (fils d’exécution, protothread, processus, etc.) et réalisant une tâche qui ne s’intègre pas harmonieusement dans le cycle normal d’opération des Agents (§5.3). Une tâche ne s’intègre pas harmonieusement dans le cycle normal d’opérations si elle réduirait alors la réactivité de son Hôte; il s’agit donc typiquement d’une tâche dont l’exécution peut être longue ou bloquante.

Les objets autonomes peuvent être vus comme des satellites d’un Hôte, au sens où ils opèrent surtout dans sa périphérie, selon des modalités qui leur sont propres (outre la contrainte de communiquer par des canaux de Contexte, décrits à la section suivante).

5.2.1 Canaux de Contexte

Chaque objet autonome d’un Hôte ℎ s’exécute indépendamment des autres, et à un rythme indépendant du rythme d’opération de ℎ en tant que tel, ce qui assujettirait les interactions entre l’Hôte et ses objets autonomes à des conditions de course si ces interactions se faisaient directement et sans synchronisation. Pour cette raison, un lien de communication synchronisé mais permettant des accès non-bloquants est placé entre un objet autonome et son Hôte.

Chacun de ces liens est constitué d’un canal de Contexte, et se positionne techniquement entre un objet autonome et un Agent standard, ou (plus rarement) entre deux objets autonomes d’un même Hôte.

Un canal de Contexte est un lien unidirectionnel synchronisé sur lequel transite du Contexte, semblable en partie au système de boîtes postales du modèle d’acteurs de Hewitt et al. [44] ou aux canaux du langage Go. Lorsque cela s’avère pertinent, une communication bidirectionnelle entre un Agent standard et un objet autonome repose simplement sur une paire de canaux de Contexte.

5.2.2 Canaux de Contexte et isolement des Agents

Un effet de bord appréciable de l’isolement des questions de concurrence en périphérie d’un Hôte est qu’outre le passage par des canaux de Contexte dans le cas de certains Agents standards, un Agent ne réalise pas de lui-même de tâches concurrentes au cycle normal d’opérations de son Hôte. Conséquemment, aucune synchronisation n’est requise lors d’accès aux espaces contextuels, ce qui accélère les accès à cette importante structure de données.

Hôte h Sh Recepteur a : ProxyAgent Sa Sa Sa ... Objet autonome Canal de Contexte

143

La figure 13 présente un exemple où un objet autonome Recepteur consomme du Contexte d’une source susceptible d’être bloquante. Le Contexte ainsi consommé est projeté sur un canal de Contexte pour être éventuellement consommé par un Agent standard 𝑎 (ProxyAgent dans la figure). Lors de sa prochaine itération, 𝑎 pourra consommer ce Contexte du canal pour l’intégrer aux espaces contextuels appropriés.

5.2.3 Gestionnaire d’Agents

Le gestionnaire d’Agents d’un Hôte est l’entité qui donne directement à chaque Agent l’opportunité de réaliser ses tâches; il sollicite directement les services des Agents et ne passe pas par des canaux de Contexte. Le gestionnaire d’Agents peut donc être vu comme le seul objet autonome qui n’est pas tant un satellite de l’Hôte qu’une entité qui participe directement à la réalisation de ses fonctions essentielles.

5.2.4 Communicateur et autres objets autonomes associés à la communication

Sur chaque Hôte ℎ se trouve un objet autonome nommé Communicateur, dont le rôle est d’orchestrer une fédération d’objets autonomes assurant le fonctionnement des divers mécanismes de communication avec le monde extérieur à ℎ, en particulier ∀ℎ′_{∈ 𝑁}

ℎ.

Le Communicateur d’un Hôte ℎ partage des canaux de communication avec divers Agents standards. Là où le Communicateur et les objets autonomes sous sa gouverne prennent en charge les opérations concurrentes au cycle normal d’opérations du gestionnaire d’Agents (§5.2.3), les Agents avec lesquels le Communicateur transige du Contexte interagissent quant à eux avec 𝑆ℎ et

accomplissent les tâches qui sont préférablement faites à l’intérieur de ce cycle.

Le Communicateur est lancé et arrêté par son Hôte, et est en soi responsable du démarrage et de l’arrêt éventuel de trois types d’objets autonomes :

 les Découvreurs, responsables de détecter les nouveaux arrivants dans 𝑁_ℎ et de constater les Hôtes quittant 𝑁_ℎ;

 les Émetteurs, responsables de transmettre du Contexte vers un Hôte de 𝑁_ℎ; et  les Récepteurs, responsables de consommer du Contexte provenant d’un Hôte de 𝑁_ℎ.

Le Contexte destiné à être transmis par chaque Émetteur doit d’abord passer par les canaux de Contexte du Communicateur. De même, le Contexte consommé par chaque Récepteur doit transiter par le Communicateur pour être intégré à 𝑆ℎ.

Le Communicateur participe à deux canaux de Contexte, soit un canal entrant pour envoyer du Contexte vers un Agent standard sur son Hôte, et un canal sortant pour recevoir du Contexte d’un Agent standard sur son Hôte. La dénomination entrant / sortant adoptée ici s’exprime en fonction de la perspective de l’Hôte, pas de celle du Communicateur. Une seule paire de canaux suffit pour un Hôte donné; le Communicateur assure la répartition entrante et sortante du Contexte à travers ses Émetteurs et ses Récepteurs.

5.2.4.1 Découvreur

Un Découvreur est un objet autonome chargé de tenir à jour le voisinage réseau 𝑁ℎ d’un Hôte ℎ. Il

a donc pour rôle de chercher à entrer en contact avec des Hôtes susceptibles de faire partie de 𝑁ℎ

144

En pratique, l’implémentation d’un Découvreur dépend fortement des réseaux auxquels participe ℎ. Sur le plan général, un Découvreur typique sur ℎ sonde périodiquement l’environnement pour découvrir des Hôtes susceptibles de faire partie de 𝑁_ℎ, bien que d’autres modalités, par exemple réactives, puissent être implémentées sans perte de généralité puisqu’en pratique, le Découvreur informe le Communicateur d’une nouvelle connexion de manière événementielle, et ce dernier relaie cette information à son Hôte par un canal de Contexte.

Des mécanismes sont mis en place pour éviter que des Découvreurs sur ℎ et ℎ′_{, s’ils s’entre-}

découvrent mutuellement, ne créent une double connexion entre eux. 5.2.4.2 Émetteur

Pour chaque Hôte ℎ′_{∈ 𝑁}

ℎ, suite à la découverte de ℎ′ par un Découvreur sur ℎ et à son insertion

subséquente dans 𝑁ℎ, le Communicateur lance un objet autonome Émetteur ayant pour rôle de faire

suivre à ℎ′ _{le Contexte qui lui est destiné, qu’il s’agisse de requêtes pour du Contexte, produites}

sur ℎ ou ayant transité par ℎ, ou encore de réponses à des requêtes reçues antérieurement de ℎ′_.

5.2.4.3 Récepteur Pour chaque Hôte ℎ′_{∈ 𝑁}

ℎ, suite à la découverte de ℎ′ par un Découvreur sur ℎ et à son insertion

subséquente dans 𝑁_ℎ, le Communicateur lancera aussi un objet autonome Récepteur ayant pour rôle de consommer le Contexte reçu de ℎ′_{, qu’il s’agisse de requêtes pour du Contexte, ou encore}

de réponses à des requêtes envoyées antérieurement par ℎ vers ℎ′_.

5.2.5 Interaction avec des composants tiers

Puisque le monde extérieur à un Hôte est fait de composants de diverses natures, soutenues par une variété de technologies, il ne serait pas raisonnable de présumer que toutes les technologies tierces adoptent, du moins à court terme, une interface basée sur du Contexte au sens où l’entend ContextAA.

Pour cette raison, il incombe à ContextAA de faire le pont avec les technologies tierces et d’offrir des composants à double vocation, exposant sous forme de Contexte les métaphores, interfaces et données de ces technologies et traduisant du Contexte vers ces autres formats.

Les objets autonomes que sont les Découvreurs, les Récepteurs et les Émetteurs sont des exemples concrets de telles interfaces pour fins protocolaires. La métaphore d’accès à un actuateur, décrite dans §5.5, peut être traduite sans peine en un appel de service. De même, l’annexe J montre comment il est possible de traduire de Contexte à XML et inversement, alors que l’annexe K montre comment il est possible de faire de même entre Contexte et JSON.

Nous avons espoir que la banque d’interfaces entre Contexte et formats tiers croîtra rapidement avec l’utilisation de ContextAA, mais soulignons qu’il existe déjà des ponts simples entre ContextAA et des technologies répandues; par exemple, Ponce et al. [82] construit un cadriciel, AmI-DEU, ajoutant une couche sémantique sur la base de ContextAA, alors que Ponce et al. [81] construit sur ce cadriciel un modèle d’activité facilitant la contribution d’experts de domaines autres que celui de l’informatique. L’implémentation proposée par cet article utilise d’ailleurs un objet autonome assurant le pont entre le protocole MQTT [48] et le milieu pur-Contexte de ContextAA.

145

Cycle de vie d’un Agent

L’une des responsabilités d’un Hôte est de prendre en charge le cycle de vie des Agents qui y sont déployés. Le cycle de vie d’un Agent standard est le même que celui d’un Agent du domaine : la distinction essentielle entre les deux catégories d’Agents reposant sur leurs privilèges respectifs et non pas sur les étapes par lesquelles un Agent passe dans chaque cas.

Le cycle de vie s’exprime en deux temps. Tout d’abord, la vie d’un Hôte s’inscrit dans une séquence d’étapes telle que celle présentée à la figure 14.

É ta p es de f in a lisa tio n É ta p es d in iti a lisa tio

n Charger les Agents standards

Activer les Agents standards Charger les Agents du domaine

Cycle normal d opération

Activer les Agents du domaine

Suspendre les Agents du domaine

Suspendre les Agents standards Persister les Agents du domaine

Persister les Agents standards

L’initialisation des Agents standards précède celle des Agents du domaine, ces derniers étant susceptibles de compter sur les services des Agents standards dans l’exercice de leur fonction, mais cet ordonnancement n’est pas essentiel du fait que les divers Agents n’entrent vraiment en fonction que lorsque débute le cycle normal d’opération du gestionnaire d’Agents. Pour la même raison, la suspension des Agents standards suit celle des Agents du domaine. Par conséquent, du point de vue d’un Agent du domaine, les Agents standards sont en place en tout temps sur l’Hôte, quel qu’il soit.

Concrètement, le fait que les Agents standards soient initialisés avant les Agents du domaine et finalisés après les Agents du domaine n’a, dans la majorité de cas, pas d’impact direct sur l’ordre d’exécution des Agents dans le cycle normal des opérations. En effet, les Agents standards sont subdivisés en deux groupes, soit ceux qui, à chaque itération du cycle de vie, doivent s’exécuter avant les Agents du domaine et ceux qui doivent s’exécuter après. Selon la perspective des Agents du domaine, cette distinction est surtout importante lors de la première itération du cycle et vie et lors de la dernière, mais il se trouve que les Agents standards s’offrent aussi mutuellement des services, et que leur position dans le cycle normal d’opérations peut être établie selon les besoins de l’Hôte qui les accueille.

Dans quelques cas toutefois, en particulier celui du gestionnaire de Contexte, la position dans le cycle a une importance du fait qu’il importe que les autres Agents standards tenus responsables de traiter le Contexte en soutien aux Agents du domaine soient intervenus entre le moment où les Agents du domaine ont publié leur Contexte et celui où le gestionnaire de Contexte prend en charge les méta-Contextes susceptibles de faire en sorte que ces Contextes soient oubliés.

146