FR 2865557 A1 20050729 FR 0450140 A 20040127 SYSTEME OUVERT D'INTEGRATION ET DE GESTION DE COMPOSANTS INFORMATIQUES REPRESENTANT UNE FONCTIONNALITE SPECIFIQUE D'UNE APPLICATION DETERMINEE Introduction Afin de faciliter la lecture de la description qui va suivre, les termes suivants sont ci-après explicités: Framework = Cadre, Porteur Cluster/Clustering = Groupe, Groupement Bootstrap = initialisation, démarrage IDs = Identificateur Wizards = Assistant automatisé Threadés = Tâches actives parallelisées utilisant le 10 processeur Snowflack = A liaisons multiples On appelle OpenComponents un environnement ouvert d'intégration et de gestion de composants distribués au sein d'une même machine ou entre plusieurs machines connectées à un réseau Ethernet TCP/IP. C'est également une démarche méthodologique qui accompagne l'outil et permet aux développeurs et aux utilisateurs de comprendre les principes de la programmation par composants et qui les guide dans les différentes étapes d'un projet de réalisation. Le paradigme componentiel utilisé dans OpenComponents reprend les grands principes de cette approche qui permet un contrôle accru sur le processus de développement et une importante réutilisation. Il suppose donc une approche méthodologique à la fois nouvelle et complémentaire aux méthodes d'analyse et de conception classiques. Nouvelle parce qu'un composant est un élément d'un tout et que l'objectif est d'atteindre un tout par composition comme cela peut être le cas dans une approche systémique. Mais également complémentaire car le composant est élémentaire et s'appuie à ce titre sur des approches plus classiques qui ont pour objet de synthétiser une entité logicielle à partir d'un code, donc d'un langage de programmation (il peut par exemple s'agir d'un langage objet, lui même distribué ou non). D'un point de vue méthodologique, OpenComponents s'appuie sur l'identification des rôles et des interactions entre des entités métiers. En premier lieu, les rôles définissent différents genres d'entités et conduisent à la création, l'adaptation ou à la réutilisation de composants. En second lieu, l'instanciation des composants permet de produire en nombre suffisant les acteurs nécessaires à la réalisation de l'objectif fonctionnel dans le respect des contraintes spatiales et temporelles. Finalement, la connaissance des différents scénarios d'interactions entre les instances permet de définir les liaisons entre les acteurs et de contrôler les flux de messages. D'un point de vue technique, OpenComponents repose sur un noyau qui offre l'ensemble des services de base nécessaires à la gestion des composants, leur enregistrement, leur instanciation et leur représentation. Le noyau procure également le support de communication entre les composants et gère leurs connexions. Cet effort de réduction des services du noyau à une base minimale facilite grandement la prise en main du framework et reporte naturellement la responsabilité de l'intégration de nouveaux services sur les composants en tant que métiers qu'ils soient génériques ou spécialisés. L'invention concerne un système ouvert d'intégration et de gestion de composants informatiques représentant une fonctionnalité spécifique d'une application déterminée. L'application déterminée est notamment destinée à assurer le fonctionnement, la supervision et le contrôle de machines connectées à un réseau informatique de type Ethernet TCP/IP au sein d'installations industrielles distribuées et hétérogènes. Le système comprend un noyau informatique comportant: - un contexte d'intégration standard des composants informatiques dans l'application déterminée, - un protocole d'intégration, commun aux composants, comportant des moyens d'instanciation et de chargement destinés à répertorier, sélectionner et affecter les composants informatiques à la réalisation d'objectifs fonctionnels de l'application déterminée, - des moyens de connexion destinés à établir des connexions et à contrôler des flux de messages entre les 20 composants informatiques. Le système comprend en outre: - au moins une interface homme-machine, générant une représentation graphique des composants informatiques, destinée à permettre à un utilisateur de contrôler les connexions et les flux de messages entre les composants informatiques, - des composants informatiques spécifiques, dédiés à la réalisation d'applications spécifiques, notamment des composants informatiques de routage permettant de traduire et d'acheminer des messages entre deux composants informatiques, des composants informatiques simulateurs de composants destinés à permettre une validation partielle de l'application déterminée. Le système permet donc de construire facilement des applications déterminées en incorporant et en connectant entre 35 elles des technologies de composants informatiques hétérogènes. Ainsi, en plus du framework OpenComponents, un certain nombre de composants sont offerts pour la conception de clusters, pour l'aide à l'intégration et au débogage, des composants d'adaptation, des composants de communication, des composants de représentation (ex: représentation de courbes, affichage de plans interactifs), etc. Présentation Le noyau et ses services Une application informatique est toujours constituée de modules fonctionnels qui coopèrent entre eux pour réaliser une ou plusieurs fonctionnalités plus complexes et plus sophistiquées que celles réalisées par chacun des modules participants. D'autre part, des configurations différentes de ces mêmes modules peuvent donner naissance à des variantes d'une même application. La technologie OpenComponents consiste à intégrer des composants logiciel représentant chacun une fonctionnalité spécifique dans un environnement fédérateur (le containeur de composants) et à établir la communication entre ces composants afin d'obtenir un comportement global qui répond à la spécification de l'application. Pour cela, le noyau fournit les services suivants: - un contexte permettant d'intégrer des composants et d'assurer leur bon fonctionnement; - un protocole qui permet l'intégration des composants; - un moyen de communication entre ces composants. La figure 1 représente de manière schématique la création d'une application par assemblage de composants. Cette création est créée à partir de l'utilisation d'un container 1 permettant d'intégrer des composants 2 selon un protocole déterminé grâce auquel les composants 2 vont communiquer entre eux selon les spécifications d'une application déterminée 3. En outre, le noyau fournit deux services supplémentaires de sécurité et de gestion des IHMs. Le service sécurité permet de définir différents niveaux d'accès à l'application qui correspondent à des droits d'utilisateurs sur le système. Le service de gestion des IHMs prend en charge la distribution des éléments d'IBM exportés par les composants au sein de l'application container. L'ensemble des services offerts par le noyau est résumé dans la liste suivante: - sécurité, - gestion des IHMs, - configuration des applications, - intégration de composants, - communications externes, Les composants Un composant est un code autonome qui interagit avec un environnement donné constitué du container dans lequel il est instancié et de l'ensemble des autres composants (locaux et distants). Un composant est constitué de quatre parties: - Une partie intégration; Une partie IHM (fenêtre(s), menu(s), barre d'outils et barre d'état); Une partie process qui assure la fonctionnalité du 25 composant; - Une partie communication. La partie intégration permet au composant de s'intégrer dans une application containeur. Elle permet aussi au composant d'insérer son IHM dans l'interface principale de l'application containeur. C'est un mécanisme standard que chaque composant doit obligatoirement inclure. Un composant dispose de sa propre IHM pour sa présentation et son interaction avec l'utilisateur (un menu, une barre d'outils, une ou plusieurs fenêtres, une barre d'état). Une partie de son IHM peut être exportée vers le containeur. La partie process est un niveau comportemental, interne, qui caractérise les processus métier du composant. La partie communication définit une interface entre le niveau comportemental et son environnement (en particulier les autres composants) . Le niveau communicationnel est lui même divisé en deux couches: une couche langage et une couche média. La figure 2 représente l'architecture générale d'un composant comprenant un niveau communicationnel 7 comportant lui-même une couche langage 4 et une couche média 5, ainsi qu'un niveau comportemental 6. La couche langage 4 définit l'interface logique de communication, elle dépend rigoureusement du métier. A ce titre elle introduit un ensemble de mots spécifiques, voire même également une syntaxe particulière. D'un point de vue général le langage définit le cadre sémantique des différentes sollicitations qui sont acceptées par le composant et qui déclenchent ses comportements. De ce fait OpenComponent ne préconise aucun langage particulier mais insiste sur le positionnement de cette couche qui, du point de vue méthodologique, doit être conçue prioritairement dans le respect de son rapport au métier afin de garantir que les développements des composants soient les plus indépendants possibles. L'intégration et la mise en relation des composants est alors une démarche de composition de plus haut niveau dont l'objectif est la mise en oeuvre de plusieurs entités métier pour la réalisation d'un objectif commun (le chapitre sur le clustering développe ce point de vue et apporte une réponse technique adaptée). Au dessus de la couche langage qui interprète les sollicitations extérieures, la couche média 5 assure la connectivité du composant avec un ou plusieurs autres composants et l'acheminement des données sur ces connexions. Pour cela un composant peut disposer d'une ou plusieurs bornes de connexion appelées plugs reliables les unes aux autres par des liaisons bidirectionnelles. Un plug est une borne de connexion par laquelle un composant peut transmettre des paquets d'octets de longueur variable. Ces paquets sont généralement la forme sérialisée d'une donnée structurée (un type simple, une structure ou une classe), d'un fichier, etc. L'application containeur OpenComponents offre un container standard et unique directement utilisable pour instancier des composants qui sont alors immédiatement actifs. Il joue un rôle fédérateur pour assurer la coopération entre les composants et propose les services suivants: intégration des composants dans l'application; - hébergement des IHMs fenêtres, menus, barres d'outils et barres d'état; - connexion des composants; - persistance de la configuration applicative. Le service d'intégration est central puisqu'il assure le chargement et l'initialisation des composants, leur connexion et est à l'origine de l'activation des autres services, en particulier le service d'hébergement des IHMs. Son rôle est donc équivalent à celui d'un bootstrap applicatif qui garantit la recherche et la mise en place des composants au sein du containeur. Le rôle du service d'hébergement des IHMs est de garantir l'interactivité entre l'utilisateur et les différents composants de l'environnement graphique. Les éléments d'interaction (ex: les boutons de la barre d'outils, les menus, etc.) sont initialisés au moment de l'intégration des composants dans l'environnement. Pour cela, ce service définit une interface qui permet: - le positionnement des composants graphiques, l'importation des boutons de barre d'outils, - l'importation des menus, un affichage minimum, - la ré-attribution contextuelle des événements clavier. La définition d'un écran, lié à un profil donné d'application, peut se réaliser pendant l'exécution de l'application (à l'aide de la souris) et peut être liée à la persistance applicative globale. L'accès à cette fonctionnalité qui permet le positionnement des composants graphiques dépend des droits accordés à l'utilisateur. L'importation des boutons de barre d'outils et des menus des différents composants est réalisée automatiquement et conduit à leur disposition dans la fenêtre principale du containeur. Cette fenêtre permet également d'accéder à un affichage minimum qui donne accès à un certain nombre de fonctionnalités de base tel que la sélection d'une configuration. Sur la figure 3, qui illustre le principe d'intégration d'un composant, on a représenté les éléments suivants: composant 2, interface 2a, process 2b, données d'IHM 9, événements d'IHM 8, container 10. Un browser permet de visualiser les différentes bornes de connexion, les plugs, exportées par chaque composant et de connecter ces plugs entre eux. Le browser de plugs permet d'obtenir une cartographie complète du projet qui donne au concepteur une vision synthétique de l'application et des différents liens de communications. La configuration applicative consiste en la définition du profil de l'application. Ce profil, persistant, est caractérisé par le paramétrage des composants graphiques (positionnement et dimensionnement) et le paramétrage des connexions entre les composants. Architecture Le noyau L'ensemble de l'application est composé d'une interface graphique principale, d'un containeur (le noyau) et de composants chargés par le noyau. L'interface graphique principale constitue la fenêtre d'accueil de l'ensemble de l'application en exécution. S'appuyant sur le noyau, elle héberge les fenêtres, les menus, les barres d'outils et les barres d'état qui appartiennent au noyau et aux composants intégrés. Le noyau fournit les services suivants: - Service d'intégration de composants - Service d'IHM - Service de sécurité - Service de communication Sur la figure 4, qui représente l'architecture globale du noyau, on a représenté les éléments suivants: des composants 2, les droits d'accès 11, le service de sécurité 12, la persistance du noyau 13, le service d'intégration de composants 14, le service d'IHM 15, l'IHM de l'application 16, les données IHM du noyau 17, les données d'IHM des composants 18, les commandes du noyau 19, les commandes des composants 20. Au sein du noyau, le service d'intégration se charge de la gestion des composants leur chargement, leur instanciation, leur interconnexion et la persistance de leur configuration. Le service d'IHM prend en charge l'exportation et la maintenance de l'interface graphique de chaque composant dans l'interface graphique principale de l'application. Il garantit l'acheminement des évènements en provenance de l'interface graphique de chaque composant vers le composant lui-même. Ce service gère aussi les objets graphiques et interactifs du noyau. Les évènements associés sont redistribués aux services concernés. Le service de sécurité définit le niveau de droits d'accès de la session en cours. Cette information est prise en compte par le service d'IHM pour déterminer le type de l'interface correspondante à utiliser. Le noyau gère une base de données pour sa propre persistance. En effet, chaque service utilise la même base pour assurer sa persistance, et le noyau joue le rôle de chef d'orchestre pour la persistance de l'ensemble. Les paragraphes suivants décrivent de manière plus détaillée l'architecture de chaque service. Le service d'intégration Le service d'intégration s'occupe de toutes les 5 opérations concernant: - le chargement et l'instanciation des composants, - l'interconnexion des composants, - la sélection des composants, - la persistance de la configuration des composants. Les opérations de chargement, d'instanciation et de sélection des composants sont assurées par le gestionnaire de composants. D'autre part, les opérations concernant l'interconnexion des composants sont gérées par le gestionnaire de communication décri dans les paragraphes suivants. Chaque gestionnaire prend en charge sa propre persistance, et le service lui-même garantit la cohérence de la persistance dans sa globalité. Sur la figure 5, qui représente le service d'intégration de composants, on a représenté les éléments suivants: la gestion de composants 21, la gestion de connexions 22, la liste de classes 23, la liste d'instances 24, les composants 2, le chargement et l'instanciation 25, la sélection d'instances 26, les plugs 27, la persistance 28, la liste de connexions 29. Le gestionnaire de composants maintient une liste de classes de composants et une liste d'instances de composants. La liste des classes contient les informations descriptives et la localité des composants enregistrés. La liste des instances contient les instances de composants en cours d'exécution. On appelle registre de composants la forme persistante de la liste des classes, tout composant devant être enregistré par le gestionnaire dans le registre avant de pouvoir être instancié. Pour chaque classe, le registre mémorise les informations suivantes: - le nom de la classe - la version de la classe - la localité du logiciel d'autres informations descriptives de la classe (auteur, copyright, description, etc.) Une classe est identifiée par son nom et sa version. Par conséquent, les composants de même type mais de versions différentes sont traités comme des classes différentes. Le gestionnaire crée des instances de composants à partir des informations obtenues du registre de composants. Les instances sont nommées et leur nom est unique dans la liste des instances. De cette manière, une instance peut être identifiée par son nom dans une application. Pour chaque instance stockée dans la liste d'instances est maintenu une structure de données qui mémorise son contexte (informations associées à l'instance et exploitées par d'autres services). Le gestionnaire de connexions met en oeuvre différents services qui permettent la gestion des plugs définis par chaque composant au niveau applicatif local jusqu'au niveau réseau global. Ces services sont notamment utilisés par le browser pour localiser l'ensemble des machines disposant d'un containeur OpenComponents actif. Pour chaque containeur, le gestionnaire de connexions est alors en mesure de connaître l'ensemble des instances de composants et leurs plugs. Les connexions entre plugs peuvent être réalisées depuis n'importe qu'elle machine. Le service d'hébergement des IHMs Le service d'hébergement des IHMs prend en charge tout d'abord la gestion et l'affichage des objets graphiques et interactifs du noyau dans l'interface principale de l'application suivant le droit d'accès fourni par le service de sécurité. Les évènements d'interactions destinés aux_différents services du noyau sont redistribués à leur destinataire. Le service d'hébergement des IHMs crée les menus selon les droits d'accès accordés à la session en cours. Ces menus sont insérés dans l'interface principale de l'application. Le service se charge de la redistribution des commandes de ces menus aux différents services du noyau. Puisque les composants sont des unités logicielles indépendantes (ex: DLL dans l'environnement Windows), les identificateurs de commandes utilisés par un composant peuvent être redondants lorsque plusieurs composants se situent dans un même espace d'exécution. Une substitution des identificateurs de commandes et des identificateurs de fenêtres est nécessaire pour bien distinguer les objets graphiques et les identificateurs de commandes dans l'interface principale de l'application. Une table de correspondance pour les fenêtres prend en charge la substitution de l'identificateur de fenêtre pour chaque fenêtre qu'un composant veut insérer en tant que fenêtre fille dans l'interface principale. De la même manière, une table de correspondance pour les identificateurs de commandes s'occupe de la substitution des identificateurs de commandes dans les menus et les barres d'outils d'un composant insérés dans l'interface principale. La correspondance entre les IDs de l'application et les IDs d'origine est gardée et vérifiée avant la redistribution des commandes vers le composant destinataire afin que ce dernier utilise toujours les IDs d'origine à l'intérieur de son code. Création de composants Création Le SDK OpenComponents permet de créer ses propres composants. Il comprend l'ensemble des librairies standard d'OpenComponents donnant notamment l'accès aux différents services du noyau. Des wizards correspondants à différents patterns de composants (composants munis d'une IHM, composants threadés, composants persistants, etc.) facilitent la conception et guident le programmeur dans sa prise en main du noyau. Différents exemples de composants illustrent les principes fondamentaux de OpenComponents. D'autres exemples montrent le degré de complexité que l'on peut atteindre avec un processus de développement fortement simplifié par le paradigme componentiel qui est naturellement incrémental et donc plus facilement maîtrisable qu'un développement monolithique classique. Tests unitaires et validation Avant d'intégrer un nouveau composant il est important de le tester. A ce moment le composant est vu comme une boite noire et peut subir des tests visant à valider ses différents comportements. Un test consiste en un scénario particulier de stimulations dont on a anticipé les réponses possibles. L'analyse comparative des réponses réelles du composant permet de vérifier son comportement vis à vis de sollicitations externes. Le composant Messenger Messenger est un composant qui permet la mise au point de composants. Il s'agit d'un stimulateur dans lequel il est possible d'écrire des scripts qui définissent différentes séquences de messages destinés à stimuler un composant particulier. Chaque script correspond à un scénario de test, l'exécution du scénario permettant de valider ou non les comportements du composant. Construction d'applications La composition La construction d'une application est un acte de composition qui consiste à interconnecter des composants existants suivant un schéma de collage particulier. Ce schéma constitue un regroupement de savoirs faire différents qui peuvent interagir pour produire une organisation particulière que l'on peut apparenter à une application virtuelle distribuée. Il existe deux techniques de collage: le collage direct et le collage indirect. Le collage direct consiste à connecter directement deux composants. Cette technique présente l'avantage de ne nécessiter aucun traitement intermédiaire mais pose le problème de l'indépendance des composants. Elle suppose en effet que les deux composants utilisent le même langage. Cependant il n'existe pas d'autres connexions que les connexions entre composants. Pour gérer ce problème OpenComponents introduit les notions de composants réactifs et de composants cognitifs. Un composant réactif est un composant capable de peut d'initiative et doté d'une connaissance très limitée. Ce type de composant est généralement contrôlé par des composants de plus haut niveau que sont les composants cognitifs. Un composant cognitif est un composant capable d'initiatives et doté d'une connaissance qui peut être évolutive. Ces composants sont généralement des entités de contrôle qui centralisent un certain nombre de services rendus par des composants réactifs. Les médiateurs utilisés dans le collage indirect sont des composants de type cognitif. Le collage indirect consiste à connecter un ensemble de composants à un même composant central qui leur sert alors de médiateur. Cette technique présente beaucoup d'avantages dont un avantage méthodologique par rapport aux processus de développement classiques. Le clustering fonctionnel D'un point du vue général une application est un graphe quelconque dont les noeuds sont des instances de composants et les liens les connexions entre ces instances. Ce graphe est construit directement dans la fenêtre principale qui offre par défaut les fonctionnalités de création et de connexion des composants. Il peut être sauvegardé sous la forme d'un fichier de configuration dont le nom est généralement celui de l'application. Un cluster fonctionnel, ou cluster (assimilable à une application), est un groupe particulier de composants, ou entités fonctionnelles, reliés ensemble par l'intermédiaire d'un composant de routage nommé Cluster Manager . Ce composant, qui connaît l'ensemble des services offerts par chaque entité fonctionnelle, réalise l'interface entre les besoins exprimés (explicitement par des requêtes ou implicitement au travers de notifications d'informations) par ces entités et les services offerts par les autres. Chaque entité reliée au routeur est une accointance du routeur. Le graphe de l'application est en étoile. Cependant ce graphe peut être augmenté par l'interconnexion de clusters et constituer alors une architecture de type snowflack . L'interconnexion de clusters permet une gestion accrue de la complexité applicative en terme de répartition fonctionnelle et géographique dans une hiérarchie dont la base est constituée de composants élémentaires (fortement réactifs) et dont le sommet nécessite la mise en oeuvre de composants de haut niveau généralement impliqué dans un processus de décision basé sur la manipulation de données de synthèse. Un autre intérêt de cette architecture est qu'elle permet d'isoler chacune des entités fonctionnelles et de limiter les phénomènes d'intrusion du métier de l'une dans le métier de l'autre (phénomènes qui entraînent généralement des interdépendances fortes et se traduisent par du code partagé). Création et mise au point de clusters Parmi les différents composants génériques que l'on peut adjoindre au framework OpenComponents, Maestro est un composant qui permet la construction et la mise au point de clusters. On appelle cluster manager (ou routeur) le gestionnaire d'un cluster. Maestro permet de définir l'interface entre des besoins exprimés explicitement au travers de requêtes ou implicitement par la notification d'informations et les différents services offerts par l'ensemble des composants du cluster (ses accointances). Cette interface est un routeur de messages pour lesquels l'utilisateur peut définir différents traducteurs. Maestro permet de définir, pour chaque accointance, ses liens avec les autres accointances et, pour chaque lien, les traducteurs qui interprètent et traduisent les messages. Sur la figure 6, qui représente le fonctionnement du composant générique Maestro, on a représenté les éléments suivants: composant A 30, composant B 31, accointance A4 32, accointance Al 34, accointance A3 33, accointance A2 35, Ael 36, Art 37, traducteur T2 38. Les différentes flèches représentent les événements suivants: Flèche 39: Envoi d'un message du composant A vers 5 l'accointance A4 du routeur. Flèche 40: Notification de la réception d'un message provenant d'une accointance. Flèche 41: Routage du message vers la ou les accointances liées. Flèche 42: Envoi du message au traducteur. Flèche 43: Traduction du message. Flèche 44: Récupération du port de communication. Flèche 45: Emission du message traduit vers le composant. Ce rapport entre les besoins (ou informations) et les services exprime une dynamique entièrement définit au niveau du routeur et qui caractérise une application d'une manière unique. En dehors des bugs spécifiques d'un composant, un cluster peut avoir un comportement imprévu généralement lié à un routage mal définit. Il peut être alors nécessaire de suivre les flux de messages gérés par le cluster manager en définissant des points d'arrêts. Pour cela Maestro permet desuivre en temps réel l'exécution d'un cluster et le suivi en pas à pas des différents flux de messages. Validation partielle d'un cluster La programmation par composants est un processus itératif qui pour être le plus efficace possible doit aussi intégrer la notion de validation partielle. Ainsi, même si les composants ne sont pas tous encore réalisés, les composants qui ont été validés lors des tests unitaires pourront être partiellement testés dans un contexte d'interaction proche du contexte final. La validation partielle d'un cluster consiste donc à étudier le comportement général d'une partie d'une application, soit d'un sous-ensemble de ses composants. Cependant il peut être nécessaire de simuler certains messages afin de permettre le déclenchement d'un processus que l'on désire valider. Pour cela un composant simulateur de composants Virtual Components est proposé pour se substituer à un composant en attente d'intégration. Cette substitution reste partielle dans la mesure où le simulateur ne peut implémenter les comportements réels du composant simulé mais permet de répondre à certains messages d'une manière mécanique au travers d'un script. Intéropérabilité Un environnement ouvert OpenComponents est un environnement ouvert à la plupart des technologies de composants actuelles. Cette ouverture est obtenue à partir d'un mécanisme d'adaptation d'interfaces qui permet d'incorporer différents types de technologies de composants et de rendre ces technologies interopérables avec l'ensemble des autres composants gérer par OpenComponents. Les skins Un skin est une interface d'adaptation qui traduit les messages entrant et sortant d'un composant exprimés dans le langage natif de son interface. Les skins permettent donc d'assurer l'intéropérabilité des composants OpenComponents avec d'autres composants issus de technologies différentes. Global Plug&Net Des composants hardware et software Aujourd'hui OpenComponents s'insère dans une gamme de produits complète visant le contrôle - commande des installations distribuées et hétérogènes: Global Plug&Net. Combiné à la technologie hardware Plug&Net Agent il permet la mise en oeuvre simple et rapide de modules de supervision et de contrôle répartis entre des agents hardware et des composants software sur des réseaux de différents types depuis les réseaux de terrain en liaison avec les équipements terminaux (automates ou entrées / sorties) jusqu'aux réseaux WAN. REVENDICATIONS 1. Système ouvert d'intégration et de gestion de composants informatiques représentant une fonctionnalité spécifique d'une application déterminée; ladite application déterminée étant notamment destinée à assurer le fonctionnement, la supervision et le contrôle de machines connectées à un réseau informatique de type Ethernet TCP/IP au sein d'installations industrielles distribuées et hétérogènes; ledit système comprenant un noyau informatique comportant: - un contexte d'intégration standard desdits composants informatiques dans ladite application déterminée, - un protocole d'intégration, commun auxdits composants, comportant des moyens d'instanciation et de chargement destinés à répertorier, sélectionner et affecter lesdits composants informatiques à la réalisation d'objectifs fonctionnels de ladite application déterminée, - des moyens de connexion destinés à établir des connexions et à contrôler des flux de messages entre lesdits composants informatiques; ledit système comprenant en outre: - au moins une interface homme-machine, générant une représentation graphique desdits composants informatiques, destinée à permettre à un utilisateur de contrôler lesdites connexions et lesdits flux de messages entre lesdits composants informatiques, - des composants informatiques spécifiques, dédiés à la réalisation d'applications spécifiques, notamment des composants informatiques de routage permettant de traduire et d'acheminer des messages entre deux composants informatiques, des composants informatiques simulateurs de composants destinés à permettre une validation partielle de ladite application déterminée; de sorte que le système permet de construire facilement des applications déterminées en incorporant et en connectant entre elles des technologies de composants informatiques hétérogènes.