FR3006528A1 - Systeme et procede de supervision de communication entre composants applicatifs - Google Patents

Abstract

L'invention propose un système de supervision d'applications s'exécutant sur un ensemble de dispositifs électroniques (5) reliés entre eux par un ou plusieurs réseaux, caractérisé en ce que chaque dispositif (5) comprend une entité de supervision locale (6), les entités de supervision coopérant entre elles pour contrôler les applications s'exécutant sur les dispositifs électroniques (5), chaque application comprenant un ensemble de composants applicatifs, chaque composant applicatif (302) étant encapsulé dans un conteneur (305) et les composants étant reliés entre eux par des connecteurs (303), chaque conteneur de composant comprenant au moins une unité d'entrée pour recevoir les flux d'entrée, au moins une unité de sortie (42) pour recevoir les flux de sortie, et une unité de contrôle (40), l'entité de supervision du dispositif hébergeant un composant étant apte à contrôler le cycle de vie du composant entre les dispositifs (5) en utilisant ladite unité de contrôle (40), tandis que le composant est apte à accéder à ses données d'entrée et de sortie en utilisant les unités d'entrée et de sortie dudit conteneur (40).

Description

068714 Système et procédé de supervision de communication entre composants applicatifs Domaine technique La présente invention concerne généralement les dispositifs électroniques et en particulier un procédé et un système de supervision pour contrôler les composants applicatifs s'exécutant sur de tels dispositifs. Art antérieur et problème technique Les récentes avancées technologiques de ces dernières années ont mis l'accent sur la démocratisation des réseaux sans-fil et sur la miniaturisation des appareils de communication. Actuellement, il existe sur le marché une multitude de dispositifs électroniques personnels de plus en plus légers, compacts, mobiles et dotés de divers moyens de communication sans-fil, tels que les téléphones portables, les téléphones mobiles intelligents (« smartphones » en langue anglo-saxonne), les tablettes, les ordinateurs portables ou encore les capteurs. Ces dispositifs concentrent des fonctionnalités complexes et très diversifiées : téléphonie, messagerie instantanée, navigation Internet, système de localisation (GPS acronyme pour « Global Positioning System »), lecteur audio, etc. Ces dispositifs font l'objet d'une demande grandissante pour des services de plus en plus riches et personnalisés. Le défi est de pouvoir proposer des applications pour ces dispositifs qui s'adaptent tant aux souhaits des utilisateurs qu'à l'environnement physique dans lequel ils opèrent. Les dispositifs électroniques mobiles ont la capacité de pouvoir rendre compte non seulement de leur environnement matériel et logiciel mais aussi, avec l'arrivée de périphériques tels que les capteurs sans fils ou les capteurs intégrés aux téléphones portables, de pouvoir mesurer des grandeurs physiques liées à l'environnement du dispositif ou au dispositif lui-même, telles que la température, la pression ou encore la vitesse de déplacement. L'intégration des données issues de tels dispositifs dans les applications peut permettre de proposer aux utilisateurs des services mieux adaptés à leur situation courante. Cependant, ces dispositifs possèdent des caractéristiques (autonomie énergétique, mobilité, ressources limitées) qui nécessitent l'adaptation des applications ainsi que des services rendus par celles-ci pour assurer un fonctionnement correct pendant une durée suffisante, et une continuité de service en cas d'indisponibilité d'un périphérique du dispositif électronique, par exemple lorsqu'un périphérique du dispositif électronique ne possède plus suffisamment de batterie. En l'absence de continuité de service, tous les services offerts par le périphérique cessent alors de fonctionner impliquant une rupture de service. Il peut en résulter un confort d'utilisation limité pour l'utilisateur, notamment dans le cas où des applications sont en cours d'exécution. 068714 On connaît des systèmes de supervision sensibles au contexte qui réagissent aux changements de contexte pour fournir à l'utilisateur des services adaptés à la situation. De tels systèmes peuvent reposer sur différents types d'adaptations : adaptation de contenu, adaptation de présentation, adaptation de comportement, adaptation structurelle, adaptation de déploiement.

Ainsi, des systèmes de supervision existent pour adapter le contenu des applications qui s'exécutent sur les dispositifs électroniques en fonction du contexte, comme par exemple la solution décrite dans Christoph Dom, Richard N. Taylor - Co-adapting human collaborations and software architectures - ICSE 2012 Proceedings of the 2012 International Conference on Software Engineering - pp. 1277-1280. En fonction de la situation, les données peuvent être modifiées pour ne présenter à l'utilisateur que celles qui sont pertinentes à sa situation. D'autres systèmes connus sont configurés pour adapter la présentation dans le domaine des IHM (acronyme pour Interface Homme Machine). En fonction du statut hiérarchique de l'utilisateur, l'interface de l'application présentera ou non une information et proposera ou non une fonctionnalité, comme par exemple la solution décrite dans l'article de Y. Gabillon, G. Calvary, H.

Fiorino, intulé « Composition d'Interfaces Homme-Machine en contexte : approche par planification automatique >>, Revue TSI. Vol. 30,2011. Dans d'autres systèmes encore, il est prévu une adaptation de comportement qui repose sur l'adaptation des fonctionnalités fournies par un composant ou un service en fonction du contexte, comme par exemple la solution décrite dans l'article de Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor, intitulé « Runtime Software Adaptation: Framework, Approaches, and Styles >>, ICSE Companion '08 Companion of the 30th international conference on Software engineering, pp. 899-910. Dans d'autres approches encore, les systèmes de supervision réalisent une adaptation structurelle qui vise à modifier la composition de l'application et/ou les connexions entre les différents composants dans le but d'obtenir une application dont le comportement reste inchangé.

Ce type d'adaptation est le plus couramment utilisé dans le domaine des applications distribuées basées composants. On connaît également des systèmes de supervision qui adaptent le déploiement en fonction du contexte, comme proposé par exemple dans l'article de Ning Gui, Vincenzo De Florio, Hong Sun, Chris Blondia intitulé « Toward architecture-based context-aware deployment and adaptation >>, The Journal of Systems and Software 84 (2011) 185-197 - Elsevier, 2011. De tels systèmes mettent en oeuvre des déploiements qui prennent en compte les propriétés des périphériques supportant l'application. Ce type d'adaptation est souvent utilisé pour faire face aux problèmes engendrés par les limitations matérielles des dispositifs mobiles et contraints, massivement utilisés de nos jours. 068714 Les solutions existantes reposant sur l'adaptation de contenu, l'adaptation de présentation et l'adaptation de fonctionnalité sont essentiellement tournés vers l'utilisateur. Le contenu et les fonctionnalités sont adaptés en fonction de ses préférences et la présentation est adaptée en fonction de son statut par exemple. Les adaptations de structure et de déploiement conviennent particulièrement aux contraintes matérielles et aux contraintes réseaux. Toutefois, les fonctionnalités restent inchangées malgré les changements de contexte. Les solutions reposant sur l'adaptation structurelle et l'adaptation de déploiement permettent d'adapter les fonctionnalités en fonction du contexte. Une application est alors représentée par un assemblage de composants qu'il est possible de modifier par des opérations élémentaires telles que l'ajout, la suppression de composants ainsi que de connexions entre ces composants. Ces opérations élémentaires agissent sur la structure de l'application. Parmi les solutions basées sur une adaptation structurelle en fonction du contexte, l'article de O. Riva, T. Nadeem,C. Borcea, L. Iftode, Context-Aware Migratory Services, in Ad Hoc Networks IEEE Transactions on Mobile Computing, Vol. 6, No. 12, December 2007, propose un modèle de service permettant aux réseaux adhoc de fournir des services capables de s'adapter au contexte afin d'offrir une continuité de service au client. Un service de migration supervise les services et réagit en déclenchant des migrations de services chaque fois qu'un noeud n'est plus capable de supporter l'exécution du service, provoquant la poursuite du service sur un autre noeud. L'aspect migration est rendu invisible aux applications cliente par l'utilisation d'un unique terminal virtuel. On connaît également une approche basée sur des composants légers pour concevoir des services web composites, qui est décrite dans l'article de V. Maurin, N. Dalmasso, B. Copigneaux, S. Lavirotte, G. Rey, J. Y. Tigli, Simply engine-wcomp : plate-forme de prototypage rapide pour l'informatique ambiante basée sur une approche orientée services pour dispositifs réels/virtuels, David Menga and Florence Sedes, editors, UbiMob, volume 394 of ACM International Conference Proceeding Series, pages 83-86. ACM, 2009. Cette solution permet de construire des applications sous forme de graphes de services web basés sur le concept de conteneur. D'autre part, elle fournit un intergiciel basé sur le concept d'Aspects d'Assemblage permettant d'adapter les services web. Une telle solution permet la réutilisation des services et par suite une extensibilité et une communication basée sur les événements, ce qui garantit une forte réactivité du système. Un autre avantage de cette solution est qu'elle permet la mobilité des applications (paradigme services web) et apporte une flexibilité au niveau de la structure qu'il est possible d'adapter (paradigme composant). Le projet MUSIC (R. Rouvoy, P. Barone, Y. Ding, F. Eliassen, S. Hallsteinsen, J. Lorenzo, A.Mamelli, and U. Scholz. MUSIC: Middleware Support for Self-Adaptation in Ubiquitous and Service-Oriented Environments - Book on Software Engineering for Self-Adaptive Systems (SEfSAS). LNCS 5525 -2009) fournit un intergiciel permettant la reconfiguration d'applications 068714 mobiles et sensibles au contexte. Le processus d'adaptation défini dans MUSIC repose sur les principes de l'adaptation par planification (« planning based adaptation » en langue anglo-saxonne). L'adaptation par planification fait référence à la capacité de reconfiguration d'une application en réponse aux changements de contexte en exploitant les connaissances de sa composition et des métadonnées de Qualité de Service associées à chacun des services la constituant. Dans l'article de D. Ayed, C. Taconet, G. Bernard, and Y. Berbers. Cadecomp, Context-aware deployment of component-based applications", J. Network and Computer Applications, 31(3) 2008, un intergiciel est proposé pour le déploiement sensible au contexte des applications basées composants. Cet intergiciel étend les services de déploiement existants en y intégrant les capacités d'adaptation nécessaires au domaine des applications mobiles et des périphériques contraints. Il propose un déploiement automatique à la volée et sensible au contexte : une application est installée au moment de son accès et désinstallée juste après la fin de son utilisation. Les applications sont considérées comme une collection de composants distribués sur le réseau et reliés entre eux via des ports. Le déploiement est défini selon cinq paramètres : l'architecture de l'application, le placement des instances des composants, le choix de leur implémentation, les propriétés des composants et leurs dépendances. Cet intergiciel repose sur un modèle de données permettant de décrire le contexte qui agit sur le déploiement et de définir des contrats de déploiement qui associent à chaque situation de contexte toutes les variations possibles des paramètres de déploiement. Le contexte modélise essentiellement les caractéristiques des instances des composants. Ces informations sont collectées lors de la spécification et du développement par le producteur du composant. Elles permettent de spécifier des contraintes sur le placement des composants ainsi que sur les connexions, obligatoires ou optionnelles.

La plateforme à service OSGi (acronyme pour « Open Services Gateway initiative ») implémente un modèle de composant (appelé « Bundle » (appelé « Bundle », terme anglo-saxon signifiant groupement). Ces derniers possèdent un cycle de vie leur permettant d'être arrêté, démarrés, mis à jour et désinstallés à chaud. Le service appelé « registry » (terme anglo-saxon signifiant « registre ») permet d'enregistrer des modèles de composant (bundle) en tant que services et d'en détecter l'apparition ou la suppression d'autres. OSGi est basé sur la découverte de services. Toutefois, la plateforme OSGi ne supporte pas la migration des composants entre périphériques et est basée sur la découverte de services. Les solutions existantes proposent ainsi différentes approches d'adaptation structurelle des applications : canevas logiciel, intergiciel, plateforme d'exécution. Toutefois, aucune des approches proposées ne permet une supervision décentralisée, entièrement dynamique et transparente des composants applicatifs sur un ensemble de dispositifs mobiles, pouvant être de nature différente et 068714 connectés par tous types de réseaux, en fonction du contexte. Par ailleurs, aucune des solutions existantes ne propose un tel système de supervision capable de contrôler la communication entre les composants applicatifs. Définition générale de l'invention A cet effet, l'invention propose un système de supervision d'applications s'exécutant sur un ensemble de dispositifs électroniques reliés entre eux par un ou plusieurs réseaux. Chaque dispositif comprend une entité de supervision locale, les entités de supervision coopérant entre elles pour contrôler les applications s'exécutant sur les dispositifs électroniques. Chaque application comprend un ensemble de composants applicatifs, chaque composant applicatif étant encapsulé dans un conteneur et les composants étant reliés entre eux par des connecteurs. Chaque conteneur de composant comprend au moins une unité d'entrée pour recevoir les flux d'entrée, au moins une unité de sortie pour recevoir les flux de sortie, et une unité de contrôle, l'entité de supervision du dispositif hébergeant un composant étant apte à contrôler le cycle de vie du composant entre les dispositifs en utilisant l'unité de contrôle, tandis que le composant est apte à accéder à ses données d'entrée et de sortie en utilisant les unités d'entrée et de sortie du conteneur. Selon une caractéristique de l'invention, le composant peut accéder à ses données d'entrée, par lecture directe sur un flux choisi, par une opération bloquante jusqu'à ce qu'une donnée soit disponible.

En variante, le composant peut accéder à ses données d'entrée, par lecture directe de la première donnée disponible sur l'un des flux d'entrée, par une opération bloquante. Selon une autre caractéristique de l'invention, le conteneur de composant comprend un ensemble d'écouteurs placés sur certains au moins de ces flux d'entrée, et chaque écouteur peut appeler une méthode de lecture de données, en réponse à la présence d'une donnée sur le flux d'entrée où est placé l'écouteur. Le conteneur peut comprendre en outre un gestionnaire d'écouteurs coopérant avec l'unité de contrôle du conteneur de composant pour activer des écouteurs sur des flux d'entrée du composant, en réponse à une information de disponibilité de données sur un connecteur d'entrée transmise à l'unité de contrôle par le connecteur d'entrée.

En réponse à une commande d'arrêt du composant transmise par l'entité de supervision du dispositif hébergeant le composant à l'unité de contrôle du conteneur du composant, l'unité de contrôle peut arrêter le gestionnaire d'écoute. 068714 Selon un autre aspect de l'invention, le composant peut écrire directement sur un flux de sortie, l'opération étant bloquante si aucun flux de sortie n'est connecté sur la sortie correspondante. En réponse à une commande de démarrage du composant transmise par l'entité de supervision du dispositif hébergeant le composant à l'unité de contrôle du conteneur du composant, si le composant n'est pas relié à un connecteur, l'unité de contrôle peut démarrer le composant et poursuivre son exécution tant que le composant ne tente pas d'accéder à un flux d'entrée ou de sortie. En réponse à une commande d'arrêt d'une unité d'entrée du composante, transmise par l'entité de supervision du dispositif hébergeant le composant à l'unité de contrôle du conteneur du composant, l'unité de contrôle peut arrêter le composant si le composant tente de lire une donnée sur l'unité d'entrée arrêtée. En réponse à une commande d'arrêt de composant ou de migration d'un composant vers un autre dispositif, transmise par l'entité de supervision du dispositif hébergeant le composant à l'unité de contrôle du conteneur du composant, l'unité de contrôle peut arrêter toutes les unités d'entrée du composant. Par ailleurs, chaque unité d'entrée du composant active peut, à chaque tentative de lecture du composant sur l'unité d'entrée, tenter de récupérer des données si elle est reliées à un connecteur ou à bloquer les lectures du composant sur l'unité d'entrée jusqu'à ce qu'elle soit reliée à un connecteur.

Selon une caractéristique de l'invention, chaque connecteur est encapsulé dans un conteneur de connecteur, une unité d'entrée, une unité de sortie et une unité de contrôle coopérant avec l'entité de supervision. L'entité de supervision d'un dispositif donné peut, en réponse à la réception d'une commande de création d'un connecteur entre le dispositif donné, dit dispositif source, et un dispositif cible, le dispositif source et le dispositif cible ayant des moyens de communication compatibles : - envoyer une commande de création de conteneur de connecteur sur le dispositif cible et créer localement un conteneur de connecteur sur le dispositif source, -synchroniser la création des connecteurs sur le dispositif source et le dispositif cible, selon un mécanisme d'échange de message d'acquittement entre les dispositifs.

En réponse à la réception d'une commande de création d'un connecteur entre le dispositif donné, dit dispositif source, et un dispositif cible, le dispositif source et le dispositif cible ayant des moyens de communication incompatibles, l'entité de supervision d'un dispositif donné peut: -calculer une route entre le dispositif source et le dispositif cible, 068714 -déterminer un dispositif relai entre le dispositif source et le dispositif cible ayant des moyens de communication compatibles avec le dispositif source et le dispositif cible, - envoyer une commande de création de conteneur de connecteur sur le dispositif relai, et créer localement un conteneur de connecteur sur le dispositif source, l'entité de supervision du dispositif relai étant configurée pour créer un conteneur de connecteur relai et envoyer une commande de création de conteneur de connecteur au dispositif cible ; et -synchroniser la création des connecteurs sur le dispositif source, le dispositif relai et le dispositif cible selon un mécanisme d'échange de message d'acquittement entre les dispositifs. Selon un aspect de l'invention, le mécanisme de synchronisation entre l'entité de supervision du dispositif cible et du dispositif source comprend: -l'envoi d'un message de synchronisation à l'entité de supervision du dispositif source -En réponse à la création de l'autre extrémité du connecteur sur le dispositif cible, l'envoi d'un message d'acquittement par l'entité de supervision du dispositif cible à l'entité de supervision du dispositif source.

En réponse à la création de l'autre extrémité du connecteur sur le dispositif cible, l'entité de supervision du dispositif cible peut créer en outre une interface logicielle de réception des données, et une interface logicielle pour les acquittements. En réponse à la réception du message d'acquittement par l'entité de supervision du dispositif source, l'entité de supervision du dispositif source peut créer une interface logicielle d'envoi de données et d'une interface logicielle de réception d'acquittement. L'entité de supervision du dispositif cible peut créer en outre une boîte à lettres pour stocker les messages de synchronisation arrivant d'autres entités de supervision. Selon une caractéristique de l'invention, les entités de supervision peuvent encapsuler les données échangées entre les composants dans une classe d'encapsulation.

Si un dispositif hébergeant un connecteur qui reçoit des données encapsulées, ne dispose pas localement de la classe des objets, le connecteur ne manipule alors que les données de la classe d'encapsulation. Si un dispositif hébergeant un connecteur qui reçoit des données encapsulées, dispose localement de la classe des objets, le conteneur de connecteur peut alors à extraire la classe d'encapsulation de l'objet contenu. Selon une autre caractéristique de l'invention, les objets échangés entre composants sont sérialisés. 068714 Le système de supervision selon l'invention permet ainsi d'établir des liens entre les composants et de supporter la communication entre les dispositifs qui peuvent dialoguer les uns avec les autres par ces liens. Par ailleurs, le système de supervision selon l'invention permet de déplacer ou de remplacer un composant, de manière transparente, sans que les composants qui communiquent avec ce composant n'aient besoin d'en être informés. Ainsi, les composants liés à un composant déplacé ou remplacé peuvent continuer à fonctionner, sans être impactés. Brève description des dessins D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit et des figures des dessins annexés dans lesquels: - la figure 1 est un schéma représentant l'architecture générale du système de supervision selon une forme de réalisation de l'invention ; - la figure 2 représente des exemples de dispositifs hébergeant des composants contrôlés par le système de supervision, selon des modes de réalisation de l'invention ; - La figure 3 montre la structure des applications ; - La figure 4 est un schéma montrant la structure d'un modèle de composant, selon certaines formes de réalisation de l'invention; -La figure 5 illustre le cycle de vie d'un composant, selon certaines formes de réalisation de l'invention; - La figure 6 est un schéma montrant la structure d'un conteneur de composant, selon une forme de réalisation de l'invention ; - La figure 7 représente un diagramme d'états détaillé d'une unité de sortie selon une forme de réalisation de l'invention; - La figure 8 est un schéma structurel d'un modèle de Connecteur supporté par le système de supervision selon une forme de réalisation de l'invention ; - La figure 9 représente un connecteur Interne, selon une forme de réalisation de l'invention ; - La figure 10 représente un connecteur distribué, selon une forme de réalisation de l'invention; - La figure 11 est un organigramme représentant la création d'un connecteur distribué selon une forme de réalisation de l'invention; 068714 - La figure 12 est un organigramme représentant la suppression d'un connecteur distribué selon une forme de réalisation de l'invention; - La figure 13 représente un connecteur relai du système de supervision selon une forme de réalisation de l'invention; - La figure 14 est un organigramme représentant la création d'un connecteur distribué selon une forme de réalisation de l'invention; - La figure 15 est une table illustrant la redirection de connecteurs en fonction des configurations des connecteurs, selon certaines formes de réalisation de l'invention; - La figure 16 illustre la communication entre les entités de supervision ; - La figure 17 est un schéma représentant le mécanisme de synchronisation des connecteurs selon les modes de réalisation de l'invention ; et - La figure 18 représente l'architecture du noyau du système de supervision. Description détaillée La figure 1 représente un système de supervision d'applications 10 mettant en oeuvre le procédé de chargement dynamique selon les formes de réalisation de l'invention. Le système de supervision 10 représenté est un système dynamique et décentralisé pour contrôler les applications d'un ensemble de dispositifs électroniques 5 connectés entre eux par des réseaux de communication, par exemple de type WIFI, ou satellite (GSM, 3G, 4G etc.). Les dispositifs électroniques (encore désignés par les expressions « dispositif hôtes » ou « hôtes » ou « machines » dans la suite de la description) peuvent comprendre tout type de dispositif électronique, notamment des dispositifs électroniques mobiles, comme des ordinateurs personnels tels que PC1 et P02), des téléphones mobiles intelligents (appelé « Smartphone » en langue anglo-saxonne) tels que Ti et T2, des tablettes informatiques telles que TI1, etc. Les réseaux de communication supportés par les dispositifs électroniques 5 peuvent comprendre plusieurs types de réseaux. Selon cette approche décentralisée, le système de supervision 10 comprend un ensemble d'entités de supervision 6 (encore appelée « entités de supervision locales »), chacune hébergée sur un dispositif électronique respectif 5. Les entités de supervision coopèrent entre elles pour superviser de manière dynamique les composants applicatifs qui s'exécutent sur l'ensemble des dispositifs 5 en fonction du contexte et des ressources. Ces entités de supervision contrôlent dynamiquement le cycle de vie des composants qui peut comprendre la création d'un composant sur un dispositif, la suppression d'un composant d'un dispositif 5 ou la migration d'un composant applicatif entre un dispositif source et un dispositif cible, notamment pour tenir compte du contexte d'exécution et des 068714 ressources matérielles. Les entités locales de supervision 6 peuvent en outre être configurées pour collecter des informations sur l'utilisation des ressources matérielles des dispositifs électroniques, telle que la batterie, la mémoire ou le CPU (acronyme pour l'expression anglo-saxonne « Central Processing Unit »), et/ou le contexte d'exécution, représenté par exemple par le réseau, les besoins des utilisateurs, ou les règles d'usage de l'application, etc. Les entités de supervision locales 6 peuvent alors déclencher dynamiquement des actions de reconfiguration des composants applicatifs qui s'exécutent sur les dispositifs électroniques 5 de manière transparente pour l'utilisateur selon une approche décentralisée (aucun serveur central n'est requis). Une telle reconfiguration permet le déploiement et le redéploiement dynamique d'applications et peut notamment impliquer la création, la suppression ou la migration de composants. Les composants (Cl ,C2, C3) peuvent ainsi être migrés de dispositif en dispositif, de manière indépendante, quel que soit le type du dispositif source et du dispositif d'accueil en fonction du contexte d'exécution et/ou des ressources matérielles, tout en poursuivant leur exécution sur chaque dispositif qui les accueille (redémarrage à chaud).

Le système de supervision 10 selon l'invention permet notamment d'assurer une continuité de service en cas d'indisponibilité d'un dispositif électronique 5. En particulier, en cas de dysfonctionnement d'un dispositif, les entités de supervision 6 peuvent fournir à l'application tout ce qu'elle attend tout en pérennisant au maximum son exécution et en anticipant des situations critiques qui peuvent être liées par exemple à la durée de vie d'une batterie ou le dépassement de la bande passante disponible. Le système de supervision 10 permet notamment de répartir la charge de l'application sur des dispositifs électroniques 5 voisins, et d'optimiser la répartition des composants de l'application sur les dispositifs électroniques voisins, lorsque le dispositif 5 sur lequel s'exécute l'application est confronté à des problèmes de ressources, comme des déconnexions dues au déchargement de la batterie.

La figure 2 montre des exemples de dispositifs 5, de types différents, exécutant des applications contrôlées par le système de supervision selon l'invention (non représenté sur la figure). Une application peut être composée d'un ou de plusieurs services et chaque service peut être réalisé par un ou plusieurs assemblages de composants (représentés par les carrés grisés) reliés par des connecteurs (représentés par les lignes fléchées). L'état d'une application est ainsi constitué par l'ensemble des états des composants, des dispositifs 5, des connecteurs entre les composants et de l'environnement. Les entités de supervision 6 sont configurées pour recueillir de telles données afin de les traiter et de déclencher des commandes de reconfiguration qui conviennent. En réponse à ces commandes de reconfigurations, les entités de supervision peuvent coopérer entre elles pour modifier l'architecture générale de l'application (pouvant impliquer une modification de la répartition des composants sur l'ensemble des dispositifs impliqués dans l'application), en migrant des composants (carrés grisés) d'un dispositif 5 à un autre selon un procédé de migration, et/ou en remplaçant un ou plusieurs composants par d'autres. 068714 Le système de supervision 10 selon l'invention permet ainsi le déploiement dynamique et la reconfiguration dynamique d'applications sur tout un ensemble de dispositifs pouvant inclure tout type de dispositif électronique 5 (ordinateur portable, tablette informatique, téléphones intelligents, etc.), quel que soit le réseau de communication qu'il supporte.

La figure 3 représente la structure générale des applications 3 contrôlées par le système de supervision 10. Des applications modulaires 3 à base de composants logiciels distribués peuvent être exécutées sur les dispositifs 5. La modularité qui en résulte permet de proposer des solutions ad hoc, reconfigurables à chaud, qui garantissent la continuité des applications et leur pérennité dans le temps.

Chaque application 3 selon l'invention comprend un ensemble de fonctionnalités 30 interconnectées. Chaque fonctionnalité est elle-même constituée d'un ensemble de composants logiciels 302 reliés par des connecteurs 303. Ces fonctionnalités 30 peuvent être réalisées de différentes manières à partir d'assemblages de composants 302 différents. Le système de supervision 10 dispose donc de plusieurs décompositions fonctionnelles correspondant aux diverses configurations de l'architecture. Pour pouvoir s'adapter dynamiquement, chaque application 3 a une capacité de réflexivité qui lui permet d'avoir une connaissance d'elle-même. Cette capacité de réflexivité lui permet de remplacer un service défectueux ou inadapté au contexte courant par un autre service. A cet effet, le système de supervision 10 est configuré pour acquérir la connaissance de l'application en cours ainsi que le contexte de l'application de manière dynamique et transparente. Le système de supervision peut être utilisé par exemple pour superviser une application de prise de notes à destination des jardiniers d'un parc botanique équipé chacun de dispositifs 5, afin de leur permettre de réaliser un suivi des plantes et de leurs évolutions (prises de photos, prises de notes, localisation, etc.). L'application peut être hébergée sur des téléphones intelligents 5 (smartphones) permettant aux jardiniers de prendre des notes géolocalisées, écrites ou orales. Chaque plante est accompagnée d'un panneau identificateur par code barre de type code OR (acronyme pour l'expression anglo-saxonne « Quick Response >>, signifiant littéralement « réponse rapide »), la lecture de ces codes OR facilitant la désignation des plantes dans les notes. Pour des raisons pratiques (position du preneur de notes par rapport au panneau), la lecture des codes OR peut être déléguée à un autre jardinier. Il est également possible de permettre à un autre jardinier de compléter une prise de notes. Lorsqu'un jardinier arrive dans le parc et dispose d'un téléphone intelligent hébergeant une entité de supervision locale 6 en cours d'exécution, un composant d'IHM (Interface Homme Machine) peut lui être déployé, offrant 3 boutons : Edition/Sélection d'une note, enregistrement d'une note vocale, activation de la géolocalisation. 068714 S'il sélectionne le premier bouton, un composant Cl de choix de note écrite ou orale est déployé lui permettant de sélectionner une note déjà présente tandis qu'un composant 02 d'accès à la base de données des notes est déployé sur le serveur central du parc. Ces deux composants Cl et 02 sont reliés entre eux par des connecteurs. Si le jardinier choisit une note écrite, un composant d'édition 03 est déployé. Lorsqu'il souhaite introduire une lecture (scan) de code OR dans sa note, la liste des dispositifs des autres jardiniers présents dans le parc lui est proposée. Il peut alors choisir de scanner lui-même la note ou de déléguer cette tâche à l'un de ses collègues. Dans ce dernier cas, un composant d'alerte (vibreuret message) 04 est déployé sur le terminal de ce collègue afin de l'avertir de la demande. Si le collègue accepte, ce composant d'alerte 04 est remplacé par un composant 05 de lecture de code OR qui est relié par connecteur au composant de prise de notes 06 du premier jardinier. Dès que la lecture du code a été faite et le résultat inséré dans la note, le composant de lecture (scan) et le connecteur sont automatiquement supprimés. Si le jardinier a mis en marche la géolocalisation, lorsqu'il sauvegarde sa note sur le serveur du parc, elle pourra être automatiquement géolocalisée. Lors d'une consultation ultérieure de cette note, cette géolocalisation ainsi que la date seront accessibles. Une application est ainsi constituée de composants logiciels 302 lies par des connecteurs 303. L'architecture d'une application est conçue pendant l'exécution et peut être modifiée pendant que l'application s'exécute sans qu'il soit nécessaire de l'arrêter (reconfiguration à chaud).

Les entités de supervision 6 coopèrent entre elles pour ajouter, supprimer, connecter, déconnecter, ou migrer les composants de chaque application. Pendant son exécution, chaque entité de supervision peut en outre collecter des informations sur l'état de l'application en cours d'exécution, en particulier des informations relatives aux composants, aux connecteurs liant les composants, aux dispositifs hôtes 5. En complément, une interface utilisateur peut être prévue pour permettre la gestion des entités de supervision sur chaque dispositif impliqué dans une application donnée. Les applications supervisées par le système de supervision 10 sont ainsi réparties sur l'ensemble des dispositifs 5. Toutefois, contrairement aux approches classiques, elles ne sont pas dépendantes de l'existence de serveurs centraux. Chaque dispositif 5 peut dialoguer directement avec les autres dispositifs par des liens entre les composants qui sont établis par le système de supervision 10. Le système de supervision 10 peut ainsi déplacer ou remplacer un composant, sans qu'il soit nécessaire d'en informer les composants qui communiquent avec lui. Les composants liés peuvent alors continuer à fonctionner de façon totalement identique. Cependant, le déplacement d'un composant d'un hôte vers un autre nécessite de faire suivre les liaisons réseaux (via les connecteurs) qui sont établies depuis le composant déplacé et vers ce composant. Or, un tel déplacement peut nécessiter de changer d'interface réseau (par exemple, 068714 pour passer du wifi vers de la 3G ou 4G). Par ailleurs, pour assurer un fonctionnement dynamique du système de supervision, les opérations liées à un tel déplacement de composant doivent se faire de manière totalement transparente pour les composants en relation avec le composant migré.

La figure 4 illustre les interactions entre les composants 302 et des connecteurs 303, selon certains aspects de l'invention. Le système de supervision 10 forme une plateforme de supervision qui est distribuée sur les dispositifs 5 de manière à avoir connaissance des composants 302 et connecteurs 303 déployés. Elle est en outre configurée pour récupérer les informations de contexte que ceux-ci lui transmettent. En fonction de ces informations, le système de supervision 10 peut déterminer si des reconfigurations doivent être mises en oeuvre, impliquant le déploiement et le redéploiement dynamique de composant. Le système de supervision 10 utilise des conteneurs 305 pour surveiller le fonctionnement des composants 302 et la circulation des flux de données entre les composants 302 connectés par les connecteurs 303. Les conteneurs 305 sont configurés pour recueillir les informations entre les entités 302 et 303. Ils permettent en outre de gérer l'hétérogénéité matérielle et logicielle des dispositifs 5 ainsi que la mobilité des dispositifs. La figure 4 montre plus précisément un modèle de conteneur 305 de composant 302 de type Composant Métier. Dans la suite de la description, les termes « composants métier », « composants applicatifs « composants logiciels », ou simplement « composants » pourront être utilisés de manière similaire pour désigner un composant. Selon ce modèle de conteneur 305, la logique métier contenue dans un composant est séparée de la supervision gérée par un conteneur. Le Composant 302 peut recevoir plusieurs flux de données en entrée et produire plusieurs flux de données en sortie. Par ailleurs, chaque flux de sortie peut être dupliqué. Le conteneur 305 représenté encapsule un seul composant 302 et peut implémenter un ensemble de propriétés non- fonctionnelles, telles que la gestion du cycle de vie, la récupération des informations de qualité de service et la gestion des communications. Le conteneur 305 associé à un composant sur un dispositif est créé par l'entité de supervision 6 qui accueille le composant, tandis que le code associé au composant peut être chargé dynamiquement. Le conteneur 305 possède trois types unités : - Une ou plusieurs unités d'entrée (UE) désignées par la référence 41 pour recevoir les flux de donnée en entrée, Une ou plusieurs unités de sortie (US) désignées par la référence 42 pour recevoir les flux de donnée en sortie, et Une Unité de contrôle (UC) désignées par la référence 40. 068714 Les unités UE d'entrée 41 et les unités US de sortie 42 peuvent être reliées à un ou à plusieurs connecteurs 303. Ces unités 41 et 42 permettent au Composant 302 de lire et d'écrire des données provenant d'autres composants ou à destination d'autres composants. Le composant 302 peut ainsi lire des données via les unités d'entrée 41, effectuer son traitement et écrire les résultats dans les unités de sortie 42 US. Le système de supervision 10 utilise l'unité de contrôle 40 (UC) pour superviser le conteneur 305 de composant. Chaque conteneur 305 de composant 302 peut en effet enregistrer son unité de contrôle 40 comme un service auprès de l'entité de supervision du dispositif hébergeant le composant, afin de permettre à l'entité de supervision 6 de contrôler les différentes phases du cycle de vie du composant.

L'unité de contrôle 40 contrôle les éléments du conteneur 305 de composant. Par exemple, le comportement du composant peut être contrôlé par l'unité de contrôle 40 au moyen d'une méthode d'initialisation de composant (appelée init()), d'une méthode de suppression de composant (appelée « destroy ») ou encore d'une méthode d'activation de composant (appelée « Run BC »). Les unités d'entrée et de sortie 40 et 41 contrôlent la circulation des données dans le conteneur 305 et donnent au composant des accès à ses flux d'entrée et de sortie. La figure 5 illustre le cycle de vie d'un composant 302. Les composants associés à une application donnée sont initialement écrits par le concepteur de l'application. Le système de supervision 10 encapsule ensuite le composant 302 dans un conteneur 305 qui en contrôlera le cycle de vie. Le cycle de vie d'un composant correspond à l'appel de méthodes surchargées. Ce cycle de vie est similaire à celui d'une « applet » (terme désignant un logiciel qui s'exécute dans la fenêtre d'un navigateur web), d'un MIDIet (acronyme pour « Mobile Information Device applet » et désignant un programme installé dans un dispositif d'information mobile) ou d'une activité du système d'exploitation Android. Le cycle de vie d'un composant 302 correspond aux trois types d'actions mises en oeuvre par les entités de supervision 6: la création d'un composant sur une machine hôte, la suppression d'un composant d'un composant sur une machine hôte et la migration d'un composant entre deux machines hôte reliées en réseau. La création d'un composant 302 comprend l'instanciation d'un objet de la classe associée au composant, l'encapsulation de cet objet dans un conteneur 305 puis la connexion de ses flux d'entrée et de sortie. La suppression d'un composant 302 comprend l'arrêt du composant encapsulé puis la suppression de son conteneur 305. Ses flux d'entrée/sortie peuvent rester en attente d'un nouveau composant ou d'être à leur tour supprimés. 068714 La migration d'un composant est mise en oeuvre lorsqu'un composant 302 s'exécutant sur un hôte A doit être migré vers un hôte B. L'entité de supervision 6 hébergée sur l'hôte A arrête alors le composant au niveau de l'hôte A comme lors d'une suppression, puis envoie le composant à l'entité de supervision sur l'hôte B en utilisant un mécanisme de sérialisation des propriétés du composant, si le dispositif B ne dispose pas du code associé au composant. L'entité de supervision 6 détourne ensuite l'ensemble des connecteurs 303 reliés à ce composant 302 vers leurs nouvelles destinations constituées par l'hôte B. Le composant 502 reçu en B est encapsulé dans un conteneur 305 puis l'entité de supervision 6 reconnecte les flux d'entrée et de sortie du composant.

Lorsqu'un composant 302 est créé, il passe de l'état « non-présent », désigné par la référence 60, à l'état « Initialisé », désigné par la référence 61, où il exécute une méthode d'initialisation appelée « mit ». Il passe ensuite dans l'état « Actif », désigné par la référence 62, où il exécute une méthode d'exécution appelée « run BC ». Un composant peut également passer directement de l'état « non-présent » (60) à l'état « actif » (61) lorsqu'il est reçu sur le dispositif électroniques suite à une migration. Dans ce cas le composant est démarré à chaud dans le même état que celui où il se trouvait précédemment sur le dispositif source depuis lequel il a été migré, de sorte qu'aucune phase d'initialisation n'est requise. Lors d'appels de fonctions de l'interface de programmation API (acronyme pour l'expression anglo-saxonne « Application Programming Interface »), comprenant par exemple des fonctions de type lecture, écriture, services du système de supervision, le composant peut être mis dans un état « Bloqué », désigné par la référence 63. Depuis l'état Actif 62 et l'état Bloqué 63, le composant 302 peut être arrêté et mis dans l'état « Détruit » (état 64) où il exécute une méthode appelée « Destroy ». Un composant 302 peut passer de l'état actif 62 à l'état détruit 64 s'il est en fin d'activité ou a été migré vers un autre dispositif. Un composant peut notamment passer de l'état « bloqué » 63 à l'état « détruit » 64 sur un dispositif donné 5, lors d'une migration vers un autre dispositif électronique 5. Les transitions entre les états 50 à 54 sont provoquées par des exceptions. Une exception désigne une interruption de l'exécution d'un programme en réponse à un évènement spécifique pouvant entraîner un changement d'état. Selon une caractéristique de l'invention, deux classes d'exception peuvent être utilisées : Une première classe appelée « StopBCException » qui représente une exception qui peut être utilisée lors de tentatives de lecture ou d'écriture ou lors d'accès aux services du système de supervision (passage de l'état actif 52 à l'état bloqué 53). Une deuxième classe appelée « InterruptedException » qui peut être utilisée pour provoquer des changements d'état lorsqu'un composant 302 est dans l'état bloqué 53 sur un sémaphore ou est suspendu.

Après l'exécution de la méthode « Destroy » (dans l'état « détruit » 54) ou après un laps de temps prédéfini, si l'exécution de la méthode « Destroy » ne se termine pas, le composant 302 peut être 068714 détruit ou migré. Lors d'une migration du composant 302, ses propriétés peuvent être sérialisées, puis sur le nouveau dispositif électronique d'accueil 5, il peut être mis directement dans l'état Actif 52. Dans une forme de réalisation préférée de l'invention, la partie applicative (comprenant notamment le code des classes des composants et des objets échangés) n'est pas résidente sur les dispositifs électroniques mobiles pour limiter la surcharge des dispositifs 5. Les classes d'un composant 302 sont alors chargées dynamiquement lors de la création de la première instance du composant sur un dispositif et supprimées lors de la suppression de sa dernière instance sur le composant. Pour cela, l'entité de supervision 6 qui accueille un nouveau composant (création ou migration) peut envoyer des messages de demande du fichier de code associé au composant vers les autres entités de supervision 6 et charger les classes du composant à partir du fichier de code, s'il a été renvoyé par l'une des entités de supervision 6 sur les autres dispositif, en utilisant un chargeur de classes créé pour le fichier associé au composant. Par ailleurs, pour ne pas occuper inutilement de la place en mémoire, le code associé à un composant (notamment classes du composant) peut être supprimé du dispositif si aucune autre instance du composant 302 ne l'utilise. Un composant 302 peut comprendre plusieurs classes et peut inclure des ressources (par exemple images, sons,..) et des bibliothèques. Le code exécutable associé au composant peut alors comprendre le code binaire (« byte code » en langue anglo-saxonne) de chaque classe nécessaire au fonctionnement du composant 302 (incluant des bibliothèques) et des classes des objets échangés entre composants. La figure 6 montre les interactions entre des connecteurs 303 et un composant 302 auquel ils sont reliés, selon un exemple de réalisation de l'invention. Un composant 302 peut accéder à ses flux d'entrée et de sortie par le biais de mécanismes fournis par son conteneur 305. Dans une forme de réalisation de l'invention, les données lues en entrées ou écrites en sorties d'un composant peuvent être des objets sérialisables qui peuvent être prédéfinis par le concepteur. Comme les flux peuvent transporter des données continues (suite continue de données dans le temps arrivant à intervalle de temps régulier) ou des données discontinues (informations n'arrivant pas à intervalle de temps régulier), le système de supervision 10 peut supporter deux types de moyens d'accès aux données, le premier moyen d'accès étant adapté aux flux continus et le second moyen d'accès étant adapté aux flux non continus. Le premier moyen d'accès permet un accès direct aux données. Le composant 302 peut lire dans le flux de son choix par une opération bloquante jusqu'à ce qu'une donnée soit disponible : l'exécution du composant est suspendue jusqu'à ce que la donnée soit disponible, tandis que les autres composants peuvent continuer à s'exécuter. En variante, le composant 302 peut récupérer la première donnée disponible dans l'un de ses flux d'entrée par une opération qui le bloque jusqu'à ce qu'une donnée soit disponible sur l'un des flux d'entrée. Le deuxième moyen d'accès 068714 permet un accès aux données en utilisant des écouteurs. Selon ce deuxième moyen d'accès, le composant 302 met en place sur un flux un écouteur 61 d'entrée dont une méthode sera automatiquement appelée dès qu'une donnée sera présente sur ce flux. Les écouteurs 61 peuvent être placés sur certaines entrées seulement, sur toutes les entrées ou encore sur aucune. Un écouteur d'entrée peut être supprimé à tout moment par le composant 302 qui retournera alors au premier moyen d'accès (mode d'accès direct). L'écriture dans un flux de sortie par un composant 302 se fait par une opération d'accès direct qui ne peut être bloquante que si aucun flux n'est connecté sur la sortie correspondante. Dans une forme de réalisation de l'invention, lorsqu'un connecteur d'entrée 303 dispose d'une nouvelle donnée, il en informer l'unité de contrôle (UC) 40 du conteneur (1) qui transmet cette information à un gestionnaire d'écouteurs 60 du composant 302. Le gestionnaire d'écouteurs 60 est adapté pour gérer une file d'attente des écouteurs du composant à activer (2) et exécuter les méthodes appropriées de ces écouteurs (3). Lorsque le composant 302 doit être arrêté, par exemple parce qu'il est migré sur un autre dispositif (étape 602 de la figure 6), l'entité de supervision 6 du dispositif sur lequel s'exécute le composant peut arrêter le gestionnaire d'écouteurs 60 en utilisant les mêmes mécanismes que le composant lui-même (exceptions) pour que les données des connecteurs 303 ne soient plus traitées. Par suite, le gestionnaire d'écouteurs peut être configuré pour ne plus lancer d'écouteurs pour traiter les données d'entrée. Ces données restent donc dans le connecteur 303 pour pouvoir être récupérées par le prochain composant qui sera relié à ce connecteur. En mode d'accès direct (absence d'écouteurs), l'entité de supervision 6 du dispositif hébergeant un composant arrête le composant à migrer en communiquant avec l'unité de contrôle du composant. L'unité de contrôle 40 du composant arrête alors les unités d'entrée 40 du composant. Les données d'entrée restent alors également dans les connecteurs 303 d'entrée pour pouvoir être réutilisées après la reconnexion des connecteurs.

Le démarrage d'un composant 302 par l'entité de supervision 6 du dispositif sur lequel s'exécute le composant n'est pas assujetti à l'existence des connecteurs 303 qui lui sont reliés. L'exécution d'un composant 302 peut se poursuivre tant qu'il ne tente pas d'accéder à un flux d'entrée ou de sortie. La figure 7 montre le diagramme d'états de l'unité d'entrée 41 d'un conteneur 305 de composant 302.

Le fonctionnement des flux d'entrée est géré par les unités d'entrée 41 du conteneur 305 du composant 302. Une unité d'entrée (UE) 41 peut être dans un état « non-créé » (état 700). Une unité d'entrée créée peut être « arrêtée » (état 701), « en marche et connectée » (état 702), ou encore « en marche et non connectée » (état 703). Lorsqu'une unité d'entrée 41 créée est arrêtée (état 701), une tentative de lecture par le composant 302 sur le flux d'entrée de cette unité d'entrée provoque une exception qui arrête le composant. Cette procédure d'exception fournie par le 068714 conteneur 305 de composants consiste à arrêter le composant 302 puis à lui faire exécuter sa méthode de destruction ("destroy") pour qu'il se termine comme prévu par le concepteur du composant. Ainsi, quand un composant 302 doit être migré (ou plus généralement arrêté), l'entité de supervision 10 du dispositif cible place toutes ses unités d'entrée et de sortie (41, 42) en mode « arrêté » (état 700). Lorsqu'une unité d'entrée 41 est en marche (i.e. l'unité d'entrée est en cours d'exécution), elle peut être reliée à un connecteur 303 (état 702) ou non-reliée à un connecteur 303 (état 703). Lorsqu'elle n'est pas reliée à un connecteur (état 703) elle peut soit être arrêtée (état 700), soit passer en attente de lecture en cas de tentative de lecture par le composant 302 sur le flux d'entrée de l'unité d'entrée (état 704), soit passer en attente de connexion (état 705).

A chaque tentative de lecture par le composant 302 depuis l'état 701, l'unité d'entrée 41 passe à l'état d'attente de lecture 704, puis vérifie si elle est reliée à un connecteur 303 (état 706 de recherche de connexion). Si elle est reliée à un connecteur 303, l'unité d'entrée 41 tente de récupérer une donnée (état de lecture 707). Sinon, si elle n'est reliée à aucun connecteur (état 708 d'attente de disponibilité de connecteur), l'unité d'entrée 41 bloque le composant 302 jusqu'à ce qu'elle soit à nouveau connectée à un connecteur (retour à l'état 706) ou jusqu'à ce que le système de supervision 10 arrête l'unité d'entrée 41 (état 701). Lors d'une tentative de lecture dans un connecteur 303 en entrée (état 707), après que l'unité d'entrée 41 a identifié une connexion avec ce connecteur 303 (état 706), le composant 302 est bloqué jusqu'à ce qu'une donnée soit présente sur l'entrée la reliant au connecteur 303. Pendant le blocage du composant 302, l'unité d'entrée 41 vérifie que le connecteur 303 reste présent. Si le connecteur 303 disparaît ou est déconnecté de cette entrée 41 alors que le composant 302 est bloqué, l'unité d'entrée 41 suspend la lecture en cours et attend qu'une nouvelle connexion soit réalisée (état 708 d'attente de disponibilité de connecteur). Dès qu'une telle connexion est établie, l'unité d'entrée reprend la lecture suspendue (retour à l'état 707).

Lorsqu'une donnée est présente sur l'entrée reliant l'unité d'entrée au connecteur 303, l'unité d'entrée 41 passe à l'état 709 pour tenter de récupérer des données. Si aucune donnée n'est disponible, l'unité d'entrée passe en état d'attente (état 710) jusqu'à ce qu'une donnée soit disponible (état 711). Lorsqu'une donnée est disponible, l'unité d'entrée peut soit être arrêtée (état 701) soit revenir à l'état 702 jusqu'à la prochaine tentative de lecture de donnée.

En complément, le système de supervision 10 peut à tout moment arrêter le composant 302. Des sémaphores peuvent être utilisés de manière à bloquer un composant 302 et permettre l'exécution des autres composants pendant que l'un d'entre eux est en attente soit d'un connecteur soit d'une donnée. Le diagramme d'état de la figure 10 s'applique de manière similaire aux unités de sortie 42. Les flux de sortie en provenance d'un composant 302 peuvent être dupliqués autant de fois que 068714 nécessaire pour être transmis à plusieurs composants qui lui sont reliés. Cette duplication est totalement transparente pour les composants 302 de sorte que l'ajout ou le retrait d'un connecteur 303 n'a pas d'incidence sur son fonctionnement. Lorsqu'il n'y a plus de flux en sortie d'une unité de sortie 42, le composant 302 est bloqué dès qu'il tente de produire une donnée sur cette sortie. Il est automatiquement relancé dès la connexion d'un nouveau connecteur puis la donnée en attente y est écrite. Comme les unités d'entrée 41, les unités de sortie 42 peuvent être arrêtées ou en marche, connectées ou non connectées. Lorsqu'une unité de sortie est arrêtée, une tentative d'écriture par le composant 302 provoque une exception qui l'arrête à son tour. Ce mode de fonctionnement permet de supprimer, déconnecter ou reconnecter des flux d'entrée/sortie, de manière dynamique, sans perturber le fonctionnement des composants 302, qui sont suspendus lorsqu'ils tentent d'accéder aux flux d'entrée/sortie, et relancés lorsque les flux d'entrée/sortie sont à nouveau disponibles. Cette capacité de connexion/déconnexion dynamique des flux d'entrée/sortie est particulièrement adaptée aux environnements mobiles où de telles situations peuvent se produire fréquemment.

L'unité de contrôle 40 du conteneur 305 de composant constitue le lien entre le conteneur de composant et l'entité de supervision 6. En particulier, chaque entité de supervision 6 peut communiquer avec l'unité de contrôle 40 du conteneur 305 d'un composant pour faire passer une unité d'entrée 40 ou une unité de sortie 41 du composant à l'état arrêté lorsqu'elle veut arrêter le composant. Chaque entité de supervision 6 peut en outre communiquer avec l'unité de contrôle 40 du conteneur 305 d'un composant pour recueillir des informations sur l'activité du composant. La figure 8 représente la structure générale d'un modèle de connecteur 303 qui permet de relier deux composants 302, selon une forme de réalisation de l'invention. Selon cette forme de réalisation, un connecteur 303 peut être encapsulé par des conteneurs 805. La fonctionnalité principale d'un connecteur 303 est de relier deux composants 302 entre eux et de faire circuler l'information entre eux. De la même manière qu'un composant 302, un connecteur 303 constitue un élément de première classe (élément pouvant être créé ou détruit dynamiquement). Les connecteurs 303 ne sont pas limités à la mise en oeuvre d'un ou de plusieurs modes de communication spécifiques (par exemple de type Client/Serveur, Pipe & Filter, etc.). Par ailleurs, un connecteur 303 peut agir sur l'information échangée entre deux composants de manière à adapter (techniquement ou sémantiquement) les données. Pour cela, chaque connecteur 303 peut comprendre lui-même un composant métier 802. Ainsi, le composant 802 contenu dans un connecteur peut non seulement faire circuler l'information mais peut également la modifier au passage, par exemple en cryptant ou en comprimant les données avant de les transmettre. 068714 Comme montré sur la figure 8, un connecteur 303 peut être encapsulé dans un conteneur 805 doté d'une unité d'entrée (UE) 81, d'une unité de sortie (US) 82 et d'une unité de contrôle (UC) 80 de manière analogue au conteneur 305 d'un composant métier 302. Cependant, contrairement au conteneur 305 de composant métier 302, le conteneur 805 de connecteur 303 n'accepte qu'une seule unité entrée 81 et qu'une seule unité de sortie 82. Par ailleurs, l'unité de contrôle 80 (UC) permet au système de supervision 10 de superviser le fonctionnement du connecteur 303. L'unité d'entrée (UE) 81 et l'une unité de sortie (US) 82 peuvent être reliées à des tampons respectivement 810 et 820 pour éviter les pertes de données lors des reconfigurations. Les données sont stockées dans les tampons 810 et 820 jusqu'à ce qu'elles puissent être transférées.

En outre, les tampons 810 et 820 permettent de détecter des situations pouvant nécessiter des reconfigurations des composants 302 sur l'ensemble des dispositifs mobiles 5, par exemple par migration de certains composants 302 entre les dispositifs mobiles. Ainsi, si un tampon de sortie 820 est saturé, l'unité de contrôle 80 détecte que le composant suivant ne traite pas les données assez rapidement ou que la liaison réseau est lente. Si un tampon d'entrée 810 est saturé, l'unité de contrôle 80 détecte un dysfonctionnement du composant 802 contenu dans le connecteur 303. Par ailleurs, si les tampons 810 et 820 sont vides, cela permet à l'unité de contrôle 80 de détecter la fluidité de la circulation des données et de déclencher dynamiquement une reconfiguration des composants 302 sur l'ensemble des dispositifs 5 pour augmenter la qualité du service. Ainsi, le composant 802 encapsulé dans le connecteur 303 assure le transfert de données entre l'unité d'entrée 81 et l'unité de sortie 82. Il peut appliquer tout type de communication orientée processus (compression, règles de priorité entre les données, agrégation des données, etc.). Le composant 802 est essentiellement prévu pour lire un échantillon de données dans l'unité d'entrée 81 et l'écrire dans l'unité de sortie 82. Le connecteur 303 est configuré pour informer l'entité de supervision 6 du dispositif sur lequel il s'exécute 5 (**vérifier) de l'état de la circulation des données dans l'application. Il est en outre adapté pour lever des alarmes quand des données s'accumulent dans ses tampons 810 et 820 mais également quand la circulation des données devient fluide après une accumulation dans les tampons 810 et 820. Le système de supervision 10 peut ainsi surveiller la circulation de données dans un hôte 5 ou entre deux hôtes 5 sur le réseau. Les niveaux des alarmes sont paramétrables dans le système de supervision 10. L'entité de supervision 6 peut communiquer avec l'unité de contrôle 80 des connecteurs hébergés sur le même dispositif pour recevoir des alertes. L'unité de contrôle 80 émet de telles alarmes en fonction de l'état des tampons 810 et 820. A partir des alertes reçues, l'entité de supervision 6 peut déclencher des reconfigurations qui modifient la cartographie des composants sur l'ensemble des dispositifs de manière transparente. 068714 Les connecteurs 303 correspondent ainsi à des flux de données qui peuvent être également encapsulés dans des conteneurs 805. Ces conteneurs 805 de connecteurs permettent au système de supervision d'effectuer des déploiements et des reconfigurations dynamiques pendant l'exécution de l'application. Les connecteurs forment eux-mêmes des composants capables de contrôler le transfert des données. Ils permettent notamment à l'entité de supervision locale de contrôler l'état de l'information qui circule entre les composants. Selon un aspect de la présente invention, les connecteurs 303 peuvent fonctionner en mode synchrone. Ainsi, pour chaque donnée envoyée un acquittement est renvoyé. Aucune nouvelle donnée ne peut être envoyée tant que l'acquittement n'a pas été reçu. Ce mécanisme de synchronisation permet au système de supervision 10 de contrôler et/ou de mesurer la circulation des données. Ainsi, aucune donnée ne peut être accumulée hors de son « middleware » (encore appelé « intergiciel »), par exemple dans les mémoires tampon (« buffers » en langue anglo-saxonne) des connecteurs réseau (« sockets » en langue anglo-saxonne). Un connecteur 303 peut être utilisé pour relier deux composants 302 sur le même dispositif électronique 5 (connecteur interne). En variante, un connecteur 303 peut être utilisé pour relier deux composants 302 placés sur des dispositifs électroniques 5 différents (connecteur distribué). En raison de l'hétérogénéité des réseaux (ethernet, wifi, bluetooth, 3G, etc.) qui peuvent être utilisés sur l'ensemble des dispositifs électroniques 5 couverts par le système de supervision 10, il peut arriver que deux dispositifs 5 devant être reliées par un connecteur 303 ne puissent pas communiquer directement. Le système de supervision 10 est alors configuré pour trouver un dispositif mobile intermédiaire 5 pouvant servir de passerelle entre les deux types de réseaux. Ainsi, le système de supervision 10 supporte trois types de connecteurs selon les définitions suivantes : des connecteurs internes, des connecteurs distribués et des connecteurs relais. La figure 9 représente un connecteur interne 303. Le connecteur 303 est interne à un hôte 5 qui relie deux composants 302 sur le même dispositif électronique 5. Lorsque le système de supervision 10 détermine que deux composants 302 doivent être reliés, l'entité de supervision 6 locale sur le dispositif 5 crée un conteneur 805 de connecteur 303 sur le dispositif 5 et le relie aux conteneurs respectifs 305 des deux composants 302, de sorte, que l'unité d'entrée 81 du connecteur résultant 303 est reliée à l'unité de sortie 42 de l'un des composants et l'unité de sortie 82 du connecteur 303 est reliée à l'unité d'entrée 41 de l'autre composant 302. La figure 10 représente un connecteur distribué 303 pour relier deux composants 302 localisés sur deux hôtes distincts A et B, comme par exemple deux téléphones intelligents (« smartphones ») distincts, deux ordinateurs portables (PC) distincts, ou encore un téléphone intelligent et un ordinateur portable, etc., lorsque les deux hôtes ont des moyens de communication compatibles 068714 (les deux hôtes peuvent communiquer directement par réseau). Le connecteur distribué 303 établit alors une communication par réseau 102 pour connecter les composants 302. La figure 11 est un organigramme illustrant le traitement d'une commande de création de connecteur distribué entre un hôte A et un hôte B par l'entité de supervision 6 sur l'hôte A, lorsque les hôtes A et B ont des moyens de communication compatibles. Quand l'entité de supervision 6 sur l'hôte A reçoit une commande de création d'un connecteur de l'hôte A vers l'hôte B (étape 90), elle détermine une route vers B. Si la route vers B ainsi déterminée est directe (étape 92), c'est-à-dire qu'elle ne passe pas par des hôtes intermédiaires, l'entité de supervision 6 sur l'hôte A envoie une commande à l'entité de supervision 6 sur l'hôte B pour que cette dernière crée un conteneur de connecteur 805B (étape 93). De son côté, l'entité de supervision 6 sur l'hôte A crée un conteneur de connecteur 805A (étape 94). L'homme du métier comprendra que les étapes 93 et 94 peuvent être réalisées sensiblement en même temps ou successivement. Le connecteur 303 qui en résulte est un élément en deux parties, 303A encapsulé par le conteneur 805A et 303B encapsulé par le conteneur 805B, avec un fil d'exécution client (« thread » en langue anglo- saxonne) d'un côté (sur l'hôte B) et un fil d'exécution serveur (« thread » en langue anglo-saxonne) de l'autre côté (sur l'hôte hôte A). Un mécanisme de synchronisation est démarré entre ces deux fils d'exécution afin de synchroniser les deux parties du connecteur 303. Si l'entité de supervision 6 sur l'hôte B reçoit une commande de création d'un connecteur de l'hôte A vers l'hôte B, un procédé similaire à celui de la figure 10A est mis en oeuvre, en permutant les rôles de l'hôte A et de l'hôte B. La figure 12 est un organigramme illustrant le traitement d'une commande de suppression d'un connecteur distribué sur un hôte A et un hôte B, par l'entité de supervision 6 sur un hôte A. En réponse à la réception d'une commande de suppression d'un connecteur distribué 303 (étape 95), l'entité de supervision sur l'hôte A envoie une commande à l'entité de supervision 6 sur l'hôte B pour qu'elle supprime le conteneur 303 et le fil (« thread ») de communication (étape 96). De son côté, l'entité de supervision sur l'hôte A supprime son propre conteneur 303 et son fil (« thread ») de communication (étape 97). L'homme du métier comprendra que les étapes 96 et 97 peuvent être réalisées sensiblement en même temps ou successivement. La figure 13 illustre la structure d'un connecteur relai 303 qui peut être utilisé pour connecter deux composants 302 placés respectivement sur deux hôtes distincts A et C qui ne peuvent pas communiquer entre eux. Une telle situation se produit lorsque le réseau de communication 120 de l'hôte A (par exemple réseau 3G) est incompatible avec le réseau de communication 121 de l'hôte C (par exemple réseau wifi), c'est-à-dire qu'il n'y a pas de liaison directe entre les hôtes. Dans ce cas, un connecteur 303B sur un hôte relai B peut être utilisé comme relai sur le réseau. Le relai hôte B est choisi de manière à pouvoir établir une liaison directe avec A et une autre liaison directe 068714 avec C. Un tel connecteur 303B permet de créer des ponts entre deux réseaux de types différents (distincts de routes complexes). Ainsi, pour relier deux composants 302 sur deux hôtes utilisant des réseaux différents, le système de supervision 10 crée un connecteur 303B sur un hôte relai B ayant simultanément accès aux deux réseaux 120 et 121.

L'unité d'entrée 81 du connecteur 303B sur l'hôte relai B est liée à l'unité de sortie 42 du composant 302 sur le premier hôte A et l'unité de sortie 82 du connecteur 303B sur l'hôte relai B est reliée à l'unité d'entrée 41 du composant 302 sur le second hôte C. Le connecteur relai 303 se présente ainsi en trois parties 303A, 303B et 3030, et utilise les mêmes mécanismes de connexion qu'un connecteur distribué.

La figure 14 est un organigramme des étapes mise en oeuvre par les entités de supervision pour relier deux composants 302 sur deux hôtes A et C ayant des moyens de communication incompatibles. Une commande de création d'un nouveau connecteur peut être reçue par une entité de supervision, par exemple pour relier deux composants nouvellement créés ou pas, dans le cadre d'une action de reconfiguration déclenchée dynamiquement. En réponse à une commande de création d'un connecteur 303 entre un hôte A et un hôte C (étape 130), l'entité de supervision 6 sur l'hôte A calcule une route de A vers C (étape 132), si la commande a été reçue par l'hôte A. Pour détecter l'incompatibilité des réseaux, l'hôte A exécutant la commande de création peut tenter d'atteindre l'autre hôte B, et s'il n'y parvient pas déterminer, qu'il n'y a pas de liaison directe possible entre les hôtes A et B. Si la route ainsi déterminée n'est pas directe (133) et passe par un hôte B pouvant servir de relai (134), l'entité de supervision locale 6 sur l'hôte A envoie une commande à l'entité de supervision locale 6 sur l'hôte relai B pour qu'elle crée un connecteur 303B de B vers C (étape 135). L'entité de supervision locale 6 sur l'hôte relai B crée un conteneur de connecteur 805B encapsulant un connecteur 303B (137). De son côté, l'entité de supervision locale 6 sur l'hôte A crée un conteneur de connecteur 805A sur l'hôte A encapsulant un connecteur 303A (134). L'entité de supervision locale 6 sur l'hôte B envoie à son tour une commande à l'entité de supervision locale 6 sur l'hôte C pour qu'elle crée un conteneur de connecteur 8050 encapsulant un connecteur 3030 (étape 139). L'entité de supervision locale 6 sur l'hôte relai C crée alors un conteneur de connecteur 8050 encapsulant un connecteur 3030 (137).Un connecteur relai 303 en trois parties 303A, 303B et 3030 est ainsi créé. Un mécanisme de synchronisation est ensuite mis en oeuvre entre les trois parties 303A, 303B et 3030 du connecteur 303 (étape 140) pour synchroniser ces trois parties. Dans une forme de réalisation particulière de l'invention, les dispositifs 5 supervisés par le système de supervision 10 repose sur un langage objet, de préférence JAVA. La suite de la description sera faite en référence à une telle forme de réalisation. 068714 Chaque entité de supervision 6 peut contrôler les communications entre les composants 302 par sérialisation des objets échangés. L'intergiciel (« middleware ») de l'entité de supervision comprend ainsi l'ensemble des connecteurs 303 et des parties de l'entité de supervision chargées de gérer ces connecteurs (par exemple pour les créer, les supprimer, etc.).

Le système de supervision 10 définit notamment une classe, appelée ci-après « Sample (signifiant littéralement « échantillon »), dont héritent les classes des objets échangés au travers des connecteurs 303. Des informations peuvent être ajoutées aux données telles que leur date de création et le flux sur lequel les données ont été transportées. Ces informations peuvent être ajoutées automatiquement par l'entité de supervision. Ces informations peuvent être utilisées de différentes manières, par exemple, pour éviter que des données considérées comme dépassées ne soient utilisées. Lorsque le code des classes des composants et des objets échangés n'est pas résident sur chacun des hôtes 5 et est téléchargé à la demande sur le dispositif qui accueille un nouveau composant par le système de supervision 10, la disponibilité des classes de composants et des objets échangés sur un dispositif donné dépend de la création du composant sur ce dispositif 5. Toutefois, pour pouvoir transporter des objets par sérialisation entre composants 302, les dispositifs 5 hébergeant les composants doivent disposer des classes de ces objets. La sérialisation permet de traduire les propriétés constituant l'état d'un objet dans un format en permettant ou le stockage ou le transport sur une liaison réseau. Puis de pouvoir, y compris sur une autre machine, reconstituer, à partir des informations mises dans ce format, les propriétés telles qu'elles étaient initialement. Lorsqu'un connecteur 303 sur un dispositif 5 est relié à un composant 302, les classes des objets en entrée et sortie du composant 302 ont été chargées au préalable avec le composant 302 dans le cadre de la création ou de la migration du composant sur l'hôte. Le connecteur 303 a ainsi accès aux classes des objets. Toutefois, comme le système de supervision 10 est réparti, il peut arriver qu'un connecteur 303 soit créé sur un dispositif donné avant le composant 302 auquel il est relié (cas i), de sorte que le dispositif 5 ne dispose pas du code des données associées au composant 302 lors de la création du connecteur 303. En effet, comme la création d'un connecteur 303 entre un hôte A et un hôte B peut être initiée par l'hôte A ou par l'hôte B, la création de la partie 303A du connecteur se trouvant sur A peut survenir par exemple suite à une commande provenant de l'hôte B tandis que la création du composant 302 associé à ce connecteur sur l'hôte A peut être provoquée par une commande provenant d'un autre hôte C distinct de l'hôte B, par exemple parce qu'il met en oeuvre une restructuration ou reconfiguration dynamique de l'application suite à un changement de contexte. Par suite, les deux commandes reçues par l'hôte A (commande de création d'un 068714 connecteur 303A provenant de l'hôte B et commande de création d'un composant 302 provenant de l'hôte C) étant issues de deux machines différentes, l'ordre dans lequel elles parviennent à l'hôte A est imprévisible : ainsi, l'hôte B pourrait envoyer une donnée sur le connecteur 303A le reliant à l'hôte A avant que l'hôte A ne dispose effectivement du code de la classe de cette donnée.

Par ailleurs, un connecteur 303 sur un hôte 5 donné peut n'être relié à aucun composant 302 (cas ii), comme dans le cas d'un connecteur relai incluant un connecteur 303B placé sur un hôte relai B dans le but de relier deux autres hôtes A et C ne partageant pas le même réseau (figure 12). Le code des objets transportés par le connecteur 303 n'a alors pas été préalablement chargé dynamiquement sur l'hôte où a été créé le connecteur, comme le chargement dynamique du code associé au composant est déclenché pour la création où la migration d'un composant sur l'hôte. En l'absence du code des données, l'hôte ne peut relayer les données. Pour remédier à la situation, les entités de supervision 6 peuvent encapsuler les classes des objets transmis par dans une classe d'encapsulation spécifique (désignée ci-après par « EncapsulatedSample », expression signifiant littéralement « Echantillon encapsulé ») de sorte que les connecteurs 303 qui n'ont pas accès aux classes des données ne manipulent que des objets de cette classe d'encapsulation « EncapsulatedSample L'encapsulation des données transmises dans un conteneur prévu à cet effet permet de les transporter et de les recevoir, même en l'absence du code des classes de ces données. Ces données ne peuvent être désencapsulées et utilisées sur un dispositif que lorsque leur code est disponible sur ce dispositif. Il est ainsi possible de transporter sur des connecteurs des informations dont le code n'est pas disponible localement. Par cette encapsulation, le composant émetteur et le composant destinataire final des données échangées sont capables de traiter les données puisque ces dispositifs disposent du code des classes de ces données qui a été dynamiquement chargé en même temps que le code du composant lui-même, au moment de la création de sa première instance.

Ainsi, lorsque le connecteur 303 est le connecteur 303B servant de relai entre les deux autres parties d'un connecteur relai (cas ii), le rôle de ce connecteur intermédiaire 303B se limite alors à transmettre les données encapsulées. Dans le cas d'un connecteur 303 lié à un composant 302 mais créé avant le composant 302 (cas i), le connecteur 303 transmet la donnée encapsulée dans la classe « EncapsulatedSample » à l'unité d'entrée 81 du conteneur de connecteur 805 qui peut extraire de la classe d'encapsulation l'objet contenu puisque le code de la classe de cet objet a été chargé avec le composant 302 qui la traite. La partie centrale d'un connecteur relai est en général créée lorsque deux dispositifs devant communiquer ne peuvent pas établir de liaison directe. Le rôle des parties centrales de connecteurs relais consiste essentiellement à faire circuler les données encapsulées sans les traiter. L'application peut ainsi fonctionner comme si cette partie centrale n'existait pas. 068714 Selon un autre aspect de l'invention, les entités de supervision 6 peuvent contrôler la redirection des connecteurs en fonction de la mobilité des composants entre les dispositifs 5. La création d'un connecteur 303 peut aboutir, selon la localisation des composants 302 que le connecteur relie, à la création d'un connecteur interne, d'un connecteur distribué ou d'un connecteur avec relai. Par exemple, lorsqu'un composant 302 est migré d'un hôte A vers un hôte B, le composant 302 est arrêté sur l'hôte A puis sérialisé vers l'hôte B et enfin ses connecteurs 303 d'entrée et de sortie sont redirigés de façon à ce qu'ils aboutissent désormais sur l'hôte B et non plus sur l'hôte A. La redirection d'un connecteur 303, dans le cadre d'une migration, peut être mise en oeuvre différemment selon le type de connecteur et la localisation des parties de connecteurs 303 avant la migration du composant. Le tableau de la figure 15 présente différents cas possibles. Dans le CAS 1 correspondant à la création sur un hôte A d'un connecteur 303 entre deux composants sur l'hôte A (connecteur interne), l'entité de supervision locale 6 crée un connecteur 303 interne sur l'hôte A.

Dans le CAS 2 correspondant à la création par un hôte A d'un connecteur 303 distribué un hôte E et l'hôte A, lorsque le lien est direct entre l'hôte E et l'hôte A, l'entité de supervision locale 6 sur l'hôte A crée une partie 303A d'un connecteur distribué connecté en entrée à l'hôte E et demande à E de créer l'autre partie de ce connecteur (303E). Dans le CAS 3 correspondant à la création par un hôte A d'un connecteur 303 entre un hôte E et l'hôte A, lorsque le lien indirect entre E et A passe par un hôte intermédiaire HE, l'entité de supervision locale 6 sur l'hôte A demande à l'hôte intermédiaire HE de créer un connecteur relai 303HE de E vers A et crée la partie locale 303A du connecteur. HE demande à E de créer l'autre partie 303E du connecteur. Dans le CAS 4 correspondant à la création par un hôte A d'un connecteur 303 entre l'hôte A et un hôte S distinct de A, lorsque le lien est direct entre A et S, l'hôte A crée un connecteur distribué 303A connecté en sortie à l'hôte S et demande à S de créer l'autre partie 303S du connecteur. Dans le CAS 5 correspondant à la création par un hôte A d'un connecteur 303 entre un hôte E et un hôte S, tous deux distincts de A, lorsque le lien est direct entre E et A d'une part et S et A d'autre part, l'entité de supervision sur l'hôte A crée localement un connecteur relai 303A de E vers S et demande à E et S de créer les autres parties, 303E et 303S, de ce connecteur. Dans le CAS 6 correspondant à la création par un hôte A d'un connecteur 303 entre un l'hôte A et un hôte S, distinct de A, lorsque le lien indirect entre A et S passe par un hôte intermédiaire HS, 068714 l'hôte A demande à HS de créer un connecteur relai 303HS de A vers S et crée la partie locale 303 A du connecteur. L'hôte HS demande à S de créer l'autre partie 303S du connecteur. Dans une forme de réalisation de l'invention, les communications assurées par les connecteurs 303 peuvent utiliser un modèle client/serveur. En particulier, lorsqu'un connecteur distribué sur deux hôtes distincts A et B est créé, il lance un procédé de synchronisation permettant de contrôler que les différentes parties qui le constituent (connecteurs 303A et 303B) sont prêtes. Au cours de ce procédé, des mécanismes sont mis en place pour permettre la communication ultérieure. Le mécanisme de synchronisation s'applique de manière analogue entre chaque extrémité d'un connecteur relai et la partie centrale d'un connecteur relai.

La figure 16 représente la structure générale de communication permettant aux entités de communiquer entre elles. Chaque entité de supervision 6 peut comprendre une ou plusieurs files d'attente 101 pour stocker les messages entrants ou sortants. Ces files d'attente permettent aux différents services de chaque entité de supervision locale 6 et aux connecteurs 303 des applications d'utiliser le réseau en concurrence. Lors de l'envoi d'un message par une entité de supervision locale 6, le message peut ainsi être mis en attente dans une file d'attente jusqu'à ce que le réseau soit disponible et/ou jusqu'à ce que le message puisse être réellement envoyé. Du point de vue du service ou du connecteur qui est à l'origine de l'envoi du message, l'envoi est considéré comme fait, mais en réalité l'envoi peut être différé.

Chaque entité de supervision 6 comprend en outre au moins un émetteur 102 pour transmettre les messages placés dans les files d'attente 101 à un client d'envoi 103 correspondant au réseau approprié en fonction de son destinataire. Si ce client 103 ne peut pas atteindre le destinataire identifié, l'émetteur 102 peut faire appel à l'unité de routage 15 pour qu'elle détermine si un autre dispositif 5 peut servir de relai. Le message est alors envoyé à ce dispositif relai qui le transmettra au destinataire. Chaque entité de supervision comprend en outre un serveur de réception 105 pour la réception des messages provenant d'autres entités de supervision 6. Le message reçu est placé dans une boîte à lettres 106 avant d'être délivré au service de l'entité de supervision auquel il est destiné. Un mutex 107 peut être utilisé pour éviter que deux requêtes reçues soient en concurrence. Si le dispositif 5 récepteur ne correspond pas au destinataire du message, le message est immédiatement renvoyé de façon à assurer la fonction de relai permettant les passerelles entre types de réseaux différents. 068714 Chaque entité de supervision 6 fonctionnant sur un dispositif électronique 5 qui dispose d'une adresse publique peut lancer un serveur supplémentaire de proxy. Sur un dispositif 5 configuré pour accéder à un réseau par satellite, l'adresse de l'un de ces proxys peut être spécifiée au préalable à l'entité de supervision du dispositif via une interface. Le dispositif 5 pourra alors établir une connexion avec ce proxy qu'il conservera ouverte afin de pouvoir recevoir des messages et des données. Le dispositif 5 peut lancer également un client lié à ce proxy qui sera alors choisi par son émetteur de messages 102 pour tous les messages envoyés par son entité de supervision locale 6. En complément, pour éviter les déconnexions qui peuvent être provoquées par les fournisseurs d'accès, lors de l'établissement d'une connexion avec le proxy, le client d'envoi 103 peut envoyer, à intervalles réguliers un message de test appelé « PING » (également désigné par l'acronyme « Packet InterNet Groper ») destiné à maintenir cette connexion ouverte. Cet échange de messages de test permet également au dispositif 5 et au proxy, de détecter les pertes de - les conteneurs 805 de connecteurs 303 ; - un gestionnaire de classes de composant 226 pour gérer dynamiquement les classes chargées ; il crée en outre des chargeurs de classes pour chaque fichier de code connexion (liée à la mobilité). En outre, des écouteurs peuvent être utilisés (tel que par exemple l'écouteur de diffusion appelé « BroadcastReceiver » pour les dispositifs de type Android) pour permettre aux dispositifs mobiles 5 de basculer automatiquement d'un mode de fonctionnement par proxy au mode de fonctionnement normal sans proxy, lors d'un changement de type de connexion. L'unité de routage 15 permet au système de supervision 10 de supporter tout type de réseau de communication entre les dispositifs mobiles 5. En particulier, elle permet de relayer les messages lorsque deux dispositifs 5 dépendant de réseaux de communication différents ne peuvent pas établir de communication directe entre eux (par exemple, lors de la création d'un connecteur distribué sur deux hôtes ayant des moyens de communication incompatibles). Cela permet notamment d'établir à tout moment une connexion entre deux entités de supervision locales 6. L'unité de routage 15 peut être interrogée par l'émetteur 102 de l'entité de supervision 6 pour déterminer un relai pour une communication avec l'entité de supervision hébergée sur un autre dispositif, lorsque cela est nécessaire. Elle peut être également interrogée par l'entité de supervision pour déterminer le dispositif qui doit accueillir un connecteur relai lorsque deux composants doivent être reliés alors qu'ils ne disposent pas de possibilité de lien direct. Ainsi quand l'entité de supervision sur l'hôte A reçoit une commande pour créer un connecteur avec l'hôte B, l'hôte A interroge l'unité de routage 15 pour trouver une route vers B. Cette route peut être directe ou indirecte, dans ce dernier cas un hôte pouvant servir de relai est identifié et un connecteur avec relai est créé. 068714 Dans une forme de réalisation de l'invention, la recherche de routes utilise un mécanisme de type « PING » et des messages de diffusion (« broadcast », « multicast »), ou en point à point vers les hôtes voisins. Ainsi si un dispositif A cherche une route pour atteindre un dispositif B, le mécanisme est le suivant : le dispositif A tente tout d'abord d'atteindre directement le dispositif B par envoi d'un message de type PING. Si le dispositif B répond au message PING, la liaison est directe et la recherche de route est terminée. Dans le cas contraire, le dispositif A envoie à tous ses voisins (le message est envoyé par diffusion, les dispositifs récepteurs constituant les dispositifs voisins) un message de recherche du dispositif B. Chacun de ses voisins tente alors de joindre le dispositif B par un message de PING. Les dispositifs qui parviennent à joindre le dispositif B indiquent au dispositif A qu'ils peuvent servir de relai pour le dispositif B. Ceux qui n'y parviennent pas diffusent à leur tour cette demande à leurs propres voisins. Le dispositif A peut recevoir plusieurs réponses. Dans ce cas, il peut choisir comme route celle qui correspond à la première réponse reçue et qui représente la route la plus rapide. La figure 17 illustre le procédé de synchronisation mis en oeuvre pour synchroniser les différentes parties 303A et 303B d'un connecteur distribué 303 sur un hôte A et un hôte B. Lorsqu'un connecteur 303A est créé sur L'hôte A, l'entité de supervision locale 6 sur l'hôte A envoie un message 151 de synchronisation « SYNC » qui est transmis sur le réseau vers l'entité de supervision 6 sur l'hôte B sur lequel se trouve l'autre extrémité du connecteur 303B. Un sémaphore d'exclusion mutuelle désigné par la référence 152 peut être utilisé pour gérer l'accès concurrent à la file d'attente des messages de synchronisation 101 utilisée par les clients d'envoi 103 de l'entité de supervision 6 au niveau de l'hôte A. En réponse à la création de l'autre extrémité du connecteur 303B sur l'hôte B, l'entité de supervision 6 sur l'hôte B répond au message de synchronisation par un message d'acquittement « SYNC ACK » désigné par la référence 154 qui est transmis à l'hôte A.

Par ailleurs, en réponse à la réception du message de synchronisation, l'entité de supervision locale 6 sur l'hôte B peut créer également une interface logicielle de réception (ou « socket » de réception) 162 pour recevoir les données, une boîte aux lettres 106, et une interface logicielle d'acquittement (ou « socket » d'acquittement) 163 pour les acquittements 164. Ainsi, lorsque le connecteur 303B est créé sur l'hôte B, il peut trouver dans la boîte aux lettres 106 le message de synchronisation envoyé par l'autre extrémité de ce connecteur 303B et y répondre par un message d'acquittement « SYNC ACK » 161. Dès lors, les données reçues sont placées dans la boîte à lettres 106 qui ne contient qu'un seul élément. Si le connecteur 303 récupère la donnée dans la boîte aux lettres 106, la boîte aux lettres 106 envoie un message d'acquittement. La réception du message d'acquittement « SYNC ACK » par l'entité de supervision sur l'hôte A peut provoquer en outre la création d'une interface logicielle (ou « socket » en langue anglo- 068714 saxonne) d'envoi de données 155 et d'une interface logicielle (ou « socket >>) de réception d'acquittement 156 sur l'hôte A. Un sémaphore 157 est mis en place pour éviter qu'une nouvelle donnée ne puisse être émise avant que l'acquittement pour la précédente donnée n'ait été reçu. Lorsqu'une donnée est envoyée par un connecteur 303, le sémaphore de synchronisation est fermé jusqu'à ce qu'un acquittement soit reçu. Ce mécanisme assure le fonctionnement synchrone des connecteurs 303 en mettant en oeuvre un contrôle permettant d'assurer que les connecteurs n'envoient pas plus de données que n'en récupère l'autre extrémité. Le mécanisme de synchronisation des parties de connecteurs s'applique de la même manière, d'une part entre une extrémité d'un connecteur relai placé sur un hôte A et la partie centrale du connecteur relai placé sur un hôte B, et d'autre part entre la partie centrale du connecteur relai placé sur l'hôte et l'autre extrémité du connecteur relai placé sur un hôte C. Le mécanisme de synchronisation selon les formes de réalisation de l'invention permet notamment une communication synchrone dans chaque connecteur 303. Ainsi, chaque donnée envoyée par l'entité de supervision hébergeant une partie d'un connecteur distribué ou relai provoque un acquittement de l'entité de supervision réceptrice hébergeant une autre partie du connecteur distribué ou relai. Une nouvelle donnée ne peut être envoyée via le connecteur que si l'acquittement pour la précédente donnée a été reçu de l'entité de supervision réceptrice hébergeant l'autre partie du connecteur distribué ou relai. Un connecteur correspond ainsi à deux liaisons physiques : une liaison pour les données qui circulent dans un sens et une autre liaison pour les acquittements qui circulent dans l'autre sens. Un tel procédé de synchronisation permet aux entités de supervision de vérifier que des données transmises sont effectivement reçues, et de détecter des disfonctionnements éventuels des connexions par réseau en particulier en situation de mobilité des dispositifs. Le système de supervision 10 selon les formes de réalisation de l'invention permet ainsi de contrôler la communication entre composant et notamment de créer, supprimer, connecter ou déconnecter des composants 302, de manière transparente, pendant que l'application est en cours de fonctionnement. La figure 18 montre un exemple d'architecture de noyau pour chaque entité locale de supervision 6 pour le contrôle de la communication entre composant. Chaque entité locale de supervision 6 peut comprendre : - Un enregistreur de services 2 qui permet à l'entité locale de supervision 6 d'accéder à un ensemble de services offerts par le système de supervision 10 ; 068714 - une couche de communication indépendante du réseau 24 et une couche de communication dépendante du réseau 25 : ces couches permettent aux entités locales de supervision 6 hébergées sur des dispositifs mobiles respectifs de communiquer entre elles et servent de support aux connecteurs entre composants ; la couche de communication indépendante du réseau 24 fournit des mécanismes (files d'attentes, sémaphores, etc) qui peuvent être utilisés par l'entité de supervision et les connecteurs pour envoyer et recevoir des objets et la couche de communication dépendante du réseau 25 fournit notamment des mécanismes pour implémenter les communications de réseau pour l'entité de supervision et pour les connecteurs. L'entité de supervision locale 6 peut comprendre en outre les éléments 22 suivant utilisés pour la supervision des applications : - Un module de supervision 223 (encore appelé « superviseur >>) pour exécuter les commande de déploiement ou de reconfiguration en créant, supprimant, migrant des composants et/ou en créant, supprimant, dupliquant, redirigeant des connecteurs exécuter les commandes de création/suppression/migration/connexion/déconnexion de composants ; - un gestionnaire de contexte 222 pour contrôler le contexte des applications, notamment à partir de capteurs du dispositif 23 ; il reçoit notamment des informations sur l'état de l'application en cours d'exécution, en particulier des informations relatives aux composants, aux connecteurs liant les composants et aux dispositifs hôtes 5 ; - les conteneurs 805 de connecteurs 303 ; - un gestionnaire de classes de composant 226 pour gérer dynamiquement les classes chargées ; il crée en outre des chargeurs de classes pour chaque fichier de code téléchargé pour un nouveau composant accueilli sur l'hôte. - les conteneurs 305 de composants 302 ; et - un gestionnaire de modules 227 qui peuvent être des modules d'extension (ou plugin) pour contrôler un ensemble modules 21. Le gestionnaire de modules 227 est adapté pour lancer ou arrêter des modules 21 de l'entité de supervision. Il peut utiliser un fichier de description qui indique les plugins qui sont automatiquement exécutés lorsque l'entité de supervision s'arrête. Des modules 21 peuvent être ajoutés ou supprimés en cours d'exécution. Les modules 21 peuvent comprendre une fonction de chargement de code 210 pour charger dynamiquement le code des classes correspondant aux composants 302 et aux objets échangés entre composants. Les modules 21 peuvent en outre comprendre : 068714 - un module pour applications (encore appelée « plugins pour application ») 21 qui permet aux composants d'accéder à des ressources gérées par l'entité de supervision 6. Ces ressources peuvent comprendre des ressources classiques (par exemple, textes, images, etc.) ou encore des ressources spécifiques au matériel (telles que des capteurs 211, un système GPS (acronyme pour « Global Positiong System », ou encore un système SMS (acronyme pour Short Messaging System », etc.)) ; cette unité permet notamment aux composants d'envoyer des commandes aux entités de supervision locales ou distantes et de recevoir des réponses. - L'unité de routage 15 pour le calcul de routes (encore appelée service de routage) ; et - Le DNS local 212 (DNS est l'acronyme pour « Domain Name System » signifiant System de Nom de Domaine). L'enregistreur de services 2 peut fonctionner de manière similaire à l'application JAVA appelée «RMI registry » mais en mode local, c'est-à-dire en faisant uniquement référence aux services hébergés sur l'entité de supervision locale 6 au dispositif électronique 5. Les services de l'entité de supervision locale 6 y sont enregistrés. Par exemple, lors de la création d'un connecteur distribué, des commandes sont envoyées vers les autres entités locales de supervision 6 en interrogeant l'enregistreur de services 2 pour obtenir le service chargé des couches de communications par réseau 24 et 25. De la même façon, chaque conteneur 805 de connecteur 303 peut être enregistré comme un service qui sera pourra être utilisé par l'entité locale de supervision 6 pour le contrôler et permettre sa découverte dynamique par les conteneurs 305 de composant 302 pour établir leur connexion aux flux d'entrée ou de sortie. Par ailleurs, chaque conteneur 305 de composant 302 peut enregistrer son unité de contrôle 40 comme un service permettant à l'entité locale de supervision de contrôler les différentes phases du cycle de vie d'un composant. Les composants 302 peuvent accéder aux services du système de supervision 302 par le biais de l'enregistreur de services 2, tels que les services 211. Les autres services sont accessibles par l'entité de supervision locale 6. Le module de supervision 223 reçoit et exécute des commandes provenant des autres entités locales de supervision 6 hébergées sur les autres dispositifs mobiles 5, des composants 302 ou d'un module de décision. Ces commandes peuvent inclure des commandes relatives aux composants 302 pouvant comprendre des commandes de création, suppression, migration, connexion, déconnexion et duplication des flux de sortie des composants. Ces commandes peuvent comprendre : -Une commande de création de composant prenant comme paramètres une liste d'entrée et de sorties pouvant être vides ou marquée pour être utilisée ultérieurement ; - Une commande de suppression d'un composant donné ; 068714 - Une commande d'envoi d'un composant vers une destination ; - Une commande de déconnexion d'une entrée d'un composant ; - Une commande de déconnexion d'une sortie d'un composant ; - Une commande de reconnexion d'une entrée d'un composant ; et -Une commande de duplication d'une sortie d'un composant. Les commandes peuvent en outre inclure des commandes relatives aux connecteurs 303, comme des commandes de création de connecteur, de suppression de connecteurs et de redirection de connecteurs. Les commandes peuvent également comprendre des commandes relatives au contexte permettant de récupérer les états de l'hôte 5, des conteneurs 224 de connecteurs 303, des conteneurs 305 de composants, et de la qualité de service indiquée par un composant. De telles commandes relatives au contexte incluent : - une commande qui retourne un objet contenant le contexte d'un hôte, c'est-à-dire l'occupation mémoire, l'état de la batterie, la charge CPU, le débit réseau moyen en entrée et en sortie sur la dernière seconde. - une commande qui retourne un objet contenant le contexte d'un conteneur. Si le nom désigne un conteneur 303 de composant, cette commande retourne les noms des connecteurs reliés en entrée et en sortie. Si le nom désigne un conteneur de connecteur 303, cette commande retourne les adresses des hôtes hébergeant l'entrée et la sortie de ce connecteur. - une commande qui retourne un objet contenant la Qualité de Service d'un conteneur. Si le nom désigne un conteneur de composant 302, cette commande retourne la valeur indiquée par le composant. Si le nom désigne un conteneur de connecteur 303, cette commande retourne le taux de remplissage des tampons d'entrées et de sortie du connecteur 303 ainsi que le débit moyen depuis la création. Les entités locales de supervision 6 peuvent exécuter un ensemble de méthodes qui doivent être surchargées, par exemple : - Une méthode qui renvoie la qualité de service (QdS) offerte par le composant 302, - La méthode appelée « run BC() » qui est exécutée pour faire passer un composant 302 à l'état actif 52 (figure 5). Dans certaines forme de réalisation de l'invention, la méthode « Run BC » ne se termine jamais (flux de données) et comporte pour cela une boucle du type « tant que » (while(isRunning() en langage de programmation). Si un composant 302 souhaite arrêter son 068714 exécution, de façon à ce que l'entité locale 6 puisse le migrer ou l'arrêter, une méthode appelée « idle()» peut être appelée. Les entités de supervision locales 6 peuvent en outre exécuter des méthodes pouvant être surchargées, notamment : - La méthode d'initialisation appelée « init() », pour initialiser un composant 302 Les initialisations des propriétés d'un composant 302 peuvent être faites dans la méthode « mit » ou au début de la méthode « run BC » (avant la boucle). La méthode d'initialisation « mit » est exécutée lors du premier lancement du composant métier 302. Toutefois, elle n'est pas redémarrée après une migration. Les initialisations faites dans la méthode « mit » concernent par conséquent les propriétés qui seront sérialisées lors d'une migration. Ainsi, la création d'une interface, l'accès à des dispositifs locaux ou la mise en place d'écouteurs d'événements sur certains flux d'entrée peuvent être faites au début de la méthode « run BC » pour être prises en compte lors d'une migration. - La méthode de destruction appelée « destroy()» qui est exécutée lors de l'arrêt définitif du composant et également avant une migration. Les méthodes suivantes sont héritées de la classe des modèles de composants, appelée «BCModel», et peuvent être utilisables par chaque composant 302. Elles comprennent des méthodes relatives à l'état du composant 302 incluant : - une méthode d'arrêt de composant appelée « idle() » qui arrête le composant mais ne le supprime pas ; - une méthode qui indique si le composant 302 peut continuer à s'exécuter, appelée « isRunning() » et de type booléen. Dans le cas où le composant doit être arrêté, cette méthode peut lever l'exception de classe appelée « StopBCException ». - une méthode indiquant l'état de migration du composant 302, de type booléen. Cette méthode peut par exemple renvoyer la valeur « VRAI » si le composant 302 a été migré. Les méthodes « idle()» et «isRunning()» sont de préférence bloquantes : si elles sont appelées par un autre fil d'exécution (thread en langue anglo saxonne), elles ne s'exécutent pas et affichent une erreur. Les méthodes héritées de la classe des modèles de composants « BCModel » et utilisables par chaque composant 302 peuvent comprendre également des méthodes relatives à l'environnement du composant telles que: - Une méthode qui renvoie le nom du composant ; 068714 - Une méthode qui renvoie le nombre d'entrées du composant 302; - Une méthode qui renvoie le nombre d'entrées actuellement connectées du Composant 302; - Une méthode d'indication de connexion d'entrée pour indiquer si l'entrée désignée par le paramètre est actuellement connectée à un connecteur ; - Une méthode qui renvoie le nombre de sorties du composant 302 ; - Une méthode qui renvoie le nombre de sorties actuellement connectées du composant 302 ; - Une méthode d'indication de connexion de sortie pour indiquer si la sortie désignée par le paramètre est actuellement connectée à au moins un connecteur. Les méthodes héritées de la classe des modèles de composants « BCModel » et utilisables par chaque composant 302 peuvent comprendre aussi des Méthodes relatives aux entrées telles que : - Une méthode pour créer un filtre de données d'une classe spécifiée, sur une entrée du composant 302; - Une méthode pour supprimer le filtre de données sur une entrée du composant 302 qui reçoit en paramètre un numéro d'entrée; - Une méthode de lecture des données sur une entrée du composant; - Une méthode de lecture des données d'une classe sur une entrée du composant; - Une méthode de lecture de la première donnée disponible sur l'une des entrées du composant 302; - Une méthode qui indique la disponibilité de données sur une entrée du composant 302; - Une méthode pour ajouter un écouteur en entrée d'un composant 302; - Une méthode de suppression d'écouteurs. D'autres méthodes utilisables par les composants peuvent être relatives aux sorties des composants 302 et comprendre une méthode pour écrire sur une sortie du composant 302. D'autres méthodes pouvant être appelées par les composants peuvent être relatives aux événements (interfaces ou écouteurs d'entrée), comme une méthode d'attente d'un événement de composant ou une méthode d'envoi d'un événement au composant. 068714 Les composants 302 peuvent également appeler des méthodes relatives aux ressources contenues dans le fichier de code associé au composant (fichier jar). Les ressources peuvent être placées dans un sous-répertoire du répertoire contenant le composant. Le composant 302 peut y accéder en utilisant des méthodes appelées « getResourceAsByteArray » (récupération de la ressource sous forme binaire) ou « getResourceAsStream » (récupération d'un flux de lecture de la ressource). Selon une autre caractéristique de l'invention, chaque entité locale de supervision 6 peut maintenir des informations relatives à toutes les entités locales de supervision 6 avec lesquelles elle est entrée en communication. En particulier, ces informations peuvent être enregistrées dans le DNS local 212. Pour chaque autre entité locale de supervision 6 identifiée par le DNS 212, le DNS 212 peut stocker les informations suivantes : - un identifiant unique associé à l'entité locale de supervision 6 ; - La liste des adresses connues de cette entité locale de supervision 6 sur chacun des réseaux auxquels elle accède ; - Le Décalage d'horloge avec cette entité locale de supervision 6 et l'erreur maximale de mesure de ce décalage. Lors de chaque réception de message (par exemple, message de recherche de classe) par l'entité locale de supervision locale 6 en provenance d'une entité locale de supervision 6 hébergée sur un autre dispositif, le DNS 212 enregistre l'entité de supervision 6 émettrice et son adresse. Lors d'échanges de messages de type PING ou de recherche de routes, à la réception de la réponse, le DNS 212 calcule le décalage d'horloges (ces messages contiennent l'heure d'émission extraite de l'horloge locale de l'entité de supervision 6 émettrice). Le temps d'échange de ces messages permet en outre de déterminer une borne maximale d'erreur de la mesure de ce décalage. Chaque route indirecte trouvée provoque l'ajout de l'entité de supervision 6 servant de relai et de celle à laquelle aboutit la route. Par ailleurs, à intervalles réguliers, les entités de supervision 6 peuvent échanger les contenus de leurs DNS 212. Les informations ainsi reçues peuvent être utilisées pour mettre à jour chaque DNS local, notamment pour ajouter des entités de supervision 6 qui n'y étaient pas enregistrées, ou pour compléter les listes d'adresses des entités de supervision 6.

Les décalages d'horloges reçus permettent de calculer de nouvelles valeurs, par exemple : - Décalage entre hôte A et hôte B = décalage entre A et C + décalage entre C et B, et 068714 - Erreur sur le décalage entre hôte A et hôte B = Erreur sur le décalage entre A et C + Erreur sur le décalage entre C et B. Ces valeurs peuvent ainsi compléter le DNS local 212 ou remplacer les valeurs locales lorsque l'erreur calculée est inférieure à celle couramment connue localement.

Les décalages d'horloges du DNS peuvent être utilisés pour la gestion des connexions, notamment pour dater les objets échangés en heure locale. En effet, les données envoyées sont automatiquement datées à leur création et cette date est ajustée par les connecteurs 303 à la réception. Lorsque le décalage d'horloge avec l'hôte émetteur n'est pas connu, le connecteur 303 date la donnée par l'heure locale de sa réception.

Pour tenir compte de la mobilité des dispositifs 5, les enregistrements du DNS 212 ont de préférence une durée de vie limitée et sont supprimés à leur terme. Une valeur maximale peut être affectée à cette durée de vie lors de chaque communication réussie, puis réajustée à partir des durées de vie des DNS reçus des autres entités de supervision 6 (la valeur maximale peut alors être conservée). Ainsi une entité de supervision 6 qui disparaît ou perd toute connexion pourra être supprimée de tous les DNS. De même, une entité de supervision 6 qui ne communique avec aucune autre entité de supervision (par exemple, aucun message n'a été échangé avec d'autres entités de supervision) pourra être supprimée de tous les DNS, et réapparaître dans les DNS dès que l'entité de supervision correspondante communiquera à nouveau avec d'autres entités de supervision.

En complément, les composants 805 encapsulés dans les conteneurs 303 peuvent offrir une méthode indiquant la qualité de service qu'ils offrent. Cette méthode peut être appelée à tout instant par la plateforme pour évaluer la Qualité de service de l'application. Les connecteurs peuvent contrôler l'état de leurs tampons internes (en nombre d'objets en attente) et mesurent leur débit instantané et moyen (en Ko/s). Ils peuvent conserver ces informations de façon à pouvoir les transmettre à la demande et lever des alarmes lorsque ces valeurs franchissent certains seuils (paramétrables). Afin de pouvoir détecter tant les baisses que les hausses de la qualité de service, ces alarmes peuvent correspondre soit à des seuils hauts soit à des seuils bas. Par ailleurs, chaque entité de supervision peut comprendre une unité de gestion des alarmes pour recevoir des alarmes provenant de la capture du contexte. Cette unité peut également recevoir des informations sur l'état actuel de l'application, des connexions et du dispositif. A partir de ces alarmes et des informations collectées, l'unité de gestion des alarmes peut déclencher des reconfigurations dans le but de maintenir la meilleure qualité de service possible en fonction du contexte courant. Ainsi, par exemple, lorsqu'un composant propose une Qualité de service faible, l'entité de supervision peut tenter de trouver une configuration dans laquelle elle sera remplacée par un composant pouvant proposer une meilleure qualité de service. L'entité de supervision peut également tenter de déplacer un ou plusieurs composants de cet hôte vers un autre. Une telle 068714 décision peut par exemple être déclenchée lorsque des connecteurs signalent une accumulation de données (causée par exemple par une saturation du réseau) ou quand l'hôte signale de faibles ressources (CPU/RAM/Energie). Les inventeurs ont effectué un certain nombre de mesures relatives au système de supervision 10, en particulier sur la complexité, le temps d'exécution des commandes, les temps de transfert d'informations dans les connecteurs et le temps de déploiement d'une application. La plupart des exécutions de commandes supportées par le système de supervision induisent des temps d'attente faibles (réponse par réseau d'une autre entité de supervision, recherche de route ...). Une reconfiguration est, généralement constituée de plusieurs commandes (ajout/suppression de composants et/ou de connecteurs par exemple). Ces temps d'attente sont optimisés par le système de supervision 10 en permettant l'exécution parallèle de ces commandes. Aussi, le temps d'exécution d'une reconfiguration est inférieur à la somme des temps d'exécution de chacune des commandes prises indépendamment. D'après les mesures effectuées, les temps de reconfiguration sont suffisamment faibles pour permettre au système de supervision d'adapter rapidement une application à un changement de contexte. Le passage à l'échelle (nombre plus important de dispositifs impliqués dans la reconfiguration) ne modifie pas la situation significativement puisque chaque entité de supervision sur un dispositif peut exécuter ses commandes en parallèle des autres. Le système de supervision 10 selon l'invention permet ainsi d'exécuter des applications (i.e. des composants formant tout ou partie d'une application) sur différents dispositifs 5 pouvant être mobiles et d'agir à chaud sur l'architecture de l'application lorsque nécessaire. Il permet en outre de contrôler la communication entre composants applicatifs, indépendamment des composants eux même qui fonctionnent de manière autonomes. L'invention n'est pas limitée aux modes de réalisation décrits ci-avant à titre d'exemple non limitatif.

Elle englobe toutes les variantes de réalisation qui pourront être envisagées par l'homme du métier. En particulier, l'invention n'est pas limitée à l'architecture des entités de supervision représentée sur la figure 18. Elle n'est pas non plus limitée à l'agencement particulier d'éléments de communication des figures 16 et 17. Par ailleurs, les entités de supervision peuvent être paramétrées de différentes manières, par l'utilisateur. Ainsi, les entités de supervision peuvent utiliser une liste de composants refusés, paramétrable par l'utilisateur à travers une interface de configuration de l'entité de supervision, pour désigner des composants qui ne doivent pas être installés sur le dispositif (par exemple un composant devant utiliser un système de localisation GPS ne sera pas installé par l'entité de supervision si l'utilisateur a spécifié qu'il refusait d'être localisé). Les entités de supervision peuvent en outre être configurées pour gérer l'achat de composants.

068714 L'homme du métier comprendra par ailleurs que les entités de supervision 6 selon les formes de réalisation de l'invention peuvent être mises en oeuvre de diverses façons par matériel (« hardware »), logiciel, ou une combinaison de matériel et de logiciels. En particulier, les éléments de chaque entité de supervision peuvent être combinés ou séparés en sous-éléments pour mettre en oeuvre l'invention. En outre, ils peuvent être mis en oeuvre sous la forme de programmes d'ordinateur exécutés par un processeur. Un programme d'ordinateur est un ensemble d'instructions qui peuvent être utilisées, directement ou indirectement, par un ordinateur. Un programme d'ordinateur peut être écrit dans n'importe quel langage de programmation, y compris les langages compilés ou interprétés, et il peut être déployé sous n'importe quelle forme dans l'environnement informatique choisi.

Claims (22)

1. REVENDICATIONS1. Système de supervision d'applications s'exécutant sur un ensemble de dispositifs électroniques (5) reliés entre eux par un ou plusieurs réseaux, caractérisé en ce que chaque dispositif (5) comprend une entité de supervision locale (6), les entités de supervision coopérant entre elles pour contrôler les applications s'exécutant sur les dispositifs électroniques (5), chaque application comprenant un ensemble de composants applicatifs, chaque composant applicatif (302) étant encapsulé dans un conteneur (305) et les composants étant reliés entre eux par des connecteurs (303), chaque conteneur de composant comprenant au moins une unité d'entrée pour recevoir les flux d'entrée, au moins une unité de sortie (42) pour recevoir les flux de sortie, et une unité de contrôle (40), l'entité de supervision du dispositif hébergeant un composant étant apte à contrôler le cycle de vie du composant entre les dispositifs (5) en utilisant ladite unité de contrôle (40), tandis que le composant est apte à accéder à ses données d'entrée et de sortie en utilisant les unités d'entrée et de sortie dudit conteneur (40).
2. 2. Système de supervision selon la revendication 1, caractérisé en ce que le composant est apte à accéder à ses données d'entrée, par lecture directe sur un flux choisi, par une opération bloquante jusqu'à ce qu'une donnée soit disponible.
3. 3. Système de supervision selon la revendication 1, caractérisé en ce que le composant est apte à accéder à ses données d'entrée, par lecture directe de la première donnée disponible sur l'un des flux d'entrée, par une opération bloquante.
4. 4. Système de supervision selon la revendication 1, caractérisé en ce que le conteneur de composant comprend un ensemble d'écouteurs (60) placés sur certains au moins de ces flux d'entrée, et en ce que chaque écouteur est apte à appeler une méthode de lecture de données, en réponse à la présence d'une donnée sur le flux d'entrée où est placé l'écouteur.
5. 5. Système de supervision selon la revendication 4, caractérisé en ce que le conteneur comprend en outre un gestionnaire d'écouteurs (60) coopérant avec l'unité de contrôle (40) du conteneur (305) de composant pour activer des écouteurs sur des flux d'entrée du composant, en réponse à une information de disponibilité de données sur un connecteur d'entrée transmise à l'unité de contrôle (40) par le connecteur d'entrée.
6. 6. Système de supervision selon la revendication 5, caractérisé en ce que, en réponse à une commande d'arrêt du composant transmise par l'entité de supervision (6) du dispositif hébergeant le composant à l'unité de contrôle (40) du conteneur du composant, l'unité de contrôle (40) arrête le gestionnaire d'écoute (60).068714
7. 7. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que le composant est apte à écrire directement sur un flux de sortie, l'opération étant bloquante si aucun flux de sortie n'est connecté sur la sortie correspondante.
8. 8.Système de supervision selon l'une des revendications précédentes, caractérisé en ce que, en réponse à une commande de démarrage du composant transmise par l'entité de supervision (6) du dispositif hébergeant le composant à l'unité de contrôle (40) du conteneur du composant, si le composant n'est pas relié à un connecteur, l'unité de contrôle (40) démarre le composant et poursuit son exécution tant que le composant ne tente pas d'accéder à un flux d'entrée ou de sortie.
9. 9. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que, en réponse à une commande d'arrêt d'une unité d'entrée du composante transmise par l'entité de supervision (6) du dispositif hébergeant le composant à l'unité de contrôle (40) du conteneur du composant, l'unité de contrôle (40) est apte à arrêter le composant si le composant tente de lire une donnée sur l'unité d'entrée arrêtée.
10. 10. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que, en réponse à une commande d'arrêt de composant ou de migration d'un composant vers un autre dispositif transmise par l'entité de supervision (6) du dispositif hébergeant le composant à l'unité de contrôle (40) du conteneur du composant, l'unité de contrôle (40) est apte à arrêter toutes les unités d'entrée du composant.
11. 11. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que chaque unité d'entrée du composant active est apte, à chaque tentative de lecture du composant sur l'unité d'entrée, à tenter de récupérer des données si elle est reliées à un connecteur (303) ou à bloquer les lectures du composant sur l'unité d'entrée jusqu'à ce qu'elle soit reliée à un connecteur (303).
12. 12. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que chaque connecteur est encapsulé dans un conteneur de connecteur (805), une unité d'entré (81), une unité de sortie (82) et une unité de contrôle (82) coopérant avec l'entité de supervision.
13. 13. Système de supervision selon l'une des revendications précédentes, caractérisé en que l'entité de supervision d'un dispositif donné est apte, en réponse à la réception d'une commande de création d'un connecteur entre le dispositif donné, dit dispositif source, et un dispositif cible, le dispositif source et le dispositif cible ayant des moyens de communication compatibles, à : - envoyer une commande de création de conteneur (805) de connecteur (303) sur le dispositif cible et créer localement un conteneur de connecteur (805A) sur le dispositif source,068714 -synchroniser la création des connecteurs sur le dispositif source et le dispositif cible, selon un mécanisme d'échange de message d'acquittement entre les dispositifs.
14. 14. Système de supervision selon l'une des revendications précédentes, caractérisé en que l'entité de supervision d'un dispositif donné est apte, en réponse à la réception d'une commande de création d'un connecteur entre le dispositif donné, dit dispositif source, et un dispositif cible, le dispositif source et le dispositif cible ayant des moyens de communication incompatibles, à : -calculer une route entre le dispositif source et le dispositif cible, -déterminer un dispositif relai entre le dispositif source et le dispositif cible ayant des moyens de communication compatibles avec le dispositif source et le dispositif cible, - envoyer une commande de création de conteneur (805) de connecteur (303) sur le dispositif relai, et créer localement un conteneur de connecteur (805A) sur le dispositif source, l'entité de supervision du dispositif relai étant configurée pour créer un conteneur (805A) de connecteur relai (303B) et envoyer une commande de création de conteneur (8050) de connecteur (3030) au dispositif cible ; et -synchroniser la création des connecteurs sur le dispositif source, le dispositif relai et le dispositif cible selon un mécanisme d'échange de message d'acquittement entre les dispositifs.
15. 15. Système de supervision selon l'une des revendications 12 et 13, caractérisé en ce que le mécanisme de synchronisation entre l'entité de supervision (6) du dispositif cible et du dispositif source comprend: -l'envoi d'un message de synchronisation à l'entité de supervision du dispositif source -En réponse à la création de l'autre extrémité du connecteur sur le dispositif cible, l'envoi d'un message d'acquittement par l'entité de supervision du dispositif cible à l'entité de supervision du dispositif source.
16. 16. Système de supervision selon la revendication 15, caractérisé en ce que en réponse à la création de l'autre extrémité du connecteur sur le dispositif cible, l'entité de supervision du dispositif cible crée en outre une interface logicielle de réception des données, et une interface logicielle pour les acquittements.
17. 17. Système de supervision selon la revendication 15, caractérisé en ce que, en réponse à la réception du message d'acquittement par l'entité de supervision du dispositif source, l'entité de supervision du dispositif source crée une interface logicielle d'envoi de données et d'une interface logicielle de réception d'acquittement.068714
18. 18. Système de supervision selon la revendication 17, caractérisé en ce que l'entité de supervision du dispositif cible crée en outre une boîte à lettres pour stocker les messages de synchronisation arrivant d'autres entités de supervision.
19. 19. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que les entités de supervision encapsulent les données échangées entre les composants dans une classe d'encapsulation.
20. 20. Système de supervision selon la revendication 19, caractérisé en ce que, si un dispositif hébergeant un connecteur (303) qui reçoit des données encapsulées, ne dispose pas localement de la classe des objets, le connecteur ne manipule que les données de la classe d'encapsulation.
21. 21. Système de supervision selon la revendication 19, caractérisé en ce que si un dispositif hébergeant un connecteur (303) qui reçoit des données encapsulées, dispose localement de la classe des objets, le conteneur (805) de connecteur est apte à extraire la classe d'encapsulation de l'objet contenu.
22. 22. Système de supervision selon l'une des revendications précédentes, caractérisé en ce que les objets échangés entre composants sont sérialisés.