Brevet FR2963971A1 — publié le 20120224

Entité générique de communication à haute vitesse entre composants CCM L'invention a pour domaine celui de la communication entre deux composants logiciels respectant le standard CCM. Le standard CCM (CORBA Component Model), maintenu par l'OMG (Object Management Group), est une approche de développement d'applications logicielles par assemblage d'entités élémentaires. Ce standard regroupe ainsi la notion de composants logiciels et celle de communication selon le standard CORBA entre deux tels composants. Un composant est une entité de conception, d'implémentation, de déploiement et d'exécution, comportant une partie d'enveloppe, permettant d'interfacer, selon des modes d'interaction prédéfinis, cette entité avec d'autres entités au sein de l'application, et une partie de code métier, encapsulée à l'intérieur de l'enveloppe et permettant de spécifier le traitement particulier qu'effectue cette entité logicielle. CORBA (Common Object Request Broker Architecture) est un middleware de communication entre composants, qui permet une gestion transparente de la communication entre deux composants de l'application, et ceci quel que soit le plan déploiement de l'application, c'est-à-dire la manière d'implanter les différentes entités composant l'application sur plusieurs plateformes reliées entre elles par un réseau de manière à constituer une installation informatique. Ainsi, lorsque le plan de déploiement conduit à ce que deux composants devant échanger des données soient exécutés sur deux plateformes différentes, le middleware CORBA gère tous les aspects de la communication sur le réseau reliant ces plateformes. Dans le cas des interactions de type asynchrone (« events »), cette gestion s'effectue par l'appel au service de notification CosNotification de CORBA. Celui-ci impose l'implémentation du protocole GIOP (pour General Inter-ORB Protocol). Un ORB (pour Object Request Broker) est une entité logicielle du middleware CORBA apte à transformer (« sérialiser ») la structure d'une donnée en cours de traitement sur une première plateforme, en une séquence d'octets propre à être transmise sur le réseau vers une seconde plateforme, sur laquelle la donnée, après avoir subi la transformation inverse par un autre ORB, finira d'être traitée. Le standard CCM définit des modes synchrones et asynchrones de communications entre deux composants. En mode synchrone, un premier composant émetteur d'une donnée initiale à destination d'un second composant récepteur, suspend l'exécution de son code métier tant que le second composant ne lui a pas renvoyé un message de réponse adapté. Ce message de réponse peut par exemple comporter une donnée d'accuser-réception de la donnée initiale ou encore une donnée résultant d'un traitement de la donnée initiale effectué par le second composant. En mode asynchrone, un premier composant émetteur d'une donnée initiale à destination d'un second composant récepteur, reprend l'exécution de son code métier dès l'émission de la donnée initiale, sans attendre de message de réponse de la part du second composant récepteur. Le standard LwCCM (Light weight CORBA Component Model) est un sous-ensemble du standard CCM qui a été défini pour répondre aux besoins particuliers des applications logicielles destinées à être exécutées sur des systèmes embarqués. Une telle application logicielle doit respecter des contraintes fortes en termes de taille dans l'espace mémoire et de consommation des capacités de calcul (CPU) du système embarqué. Elle doit également conduire à une faible consommation énergétique. En outre, les applications logicielles destinées aux systèmes embarqués ont souvent pour fonction d'effectuer des prétraitements sur des données acquises, ces prétraitements devant être réalisés en temps réel. Par temps réel, on entend dans ce qui suit un fonctionnement de l'application dans un temps caractéristique inférieur à un temps propre du système. Par exemple, dans le cas du prétraitement d'une image vidéo haute définition obtenue en sortie d'une caméra fonctionnant à 24 images par seconde, il faut que le prétraitement effectué sur chaque image par l'application logicielle s'effectue en moins de 20 ms. En conséquence, au sein de l'application logicielle, chaque traitement effectué par un composant de l'application, ainsi que la communication entre deux composants de cette application doivent également s'effectuer en moins de 20 ms. Or, il a été constaté que le Middleware CORBA ne permet pas de réaliser des applications fonctionnant en temps réel, car l'échange de données entre deux composants, fondé sur le service de notification de CORBA, est peu performant et consomme une partie relativement importante du CPU. De ce fait, le temps nécessaire pour effectuer un échange de données entre composants n'est pas négligeable par rapport à un temps propre du système. Cette lenteur relative des communications entre deux composants est accentuée lorsque la quantité ou la nature des données à échanger entre composants génère un flux important. Par exemple, pour le prétraitement d'une image vidéo haute définition, un flux de données d'environ 50 Mégaoctets doit pouvoir être échangé entre deux composants. Ainsi, alors que les applications embarquées temps réel ont un besoin de communications asynchrones haute vitesse, le standard LwCCM ne fournit par les moyens de communication nécessaires. De plus, il ne permet pas l'échange de données de nature variée : flux audio, flux vidéo, flux radio, etc. L'invention a donc pour but de palier au problème précité en permettant, tout en restant dans le standard LwCCM, d'offrir la possibilité aux développeurs des applications embarquées temps réel d'une communication haute vitesse entre composants. A cet effet, l'invention a pour objet une entité générique de communication à haute vitesse entre un Composant émetteur et au moins un composant récepteur, ces composants respectant le standard CORBA Component Model, version 1.0. Cette entité comporte : - un Fragment émetteur comportant une partie d'enveloppe comportant un Port d'entrée destiné à être connecté à un Port de sortie du composant émetteur ; - au moins un Fragment récepteur comportant une partie d'enveloppe comportant un Port de sortie destiné à être connecté à un Port d'entrée d'un Composant récepteur parmi lesdits au moins un Composants récepteurs ; - le Fragment émetteur comportant une partie de code métier comportant des moyens d'émission d'une donnée publiée sur le Port d'entrée de la partie d'enveloppe du Fragment émetteur, à destination du ou de chaque Fragment récepteur ; et, - le ou chaque Fragment récepteur comportant une partie de code métier comportant des moyens de réception de la donnée émise par les moyens d'émission du Fragment émetteur, pour la publication de la donnée sur le Port de sortie de la partie d'enveloppe du Fragment récepteur. Suivant des modes particuliers de réalisation, l'entité comporte une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - le Port d'entrée du Fragment émetteur et le Port de sortie du ou de chaque Fragment récepteur sont du type synchrone (interaction facette/réceptacle) ; les moyens d'émission du Fragment émetteur comportent un moyen de communication en mode local, et les moyens de réception du ou de chaque Fragment récepteur comportent un moyen conjugué de communication en mode local ; - les moyens d'émission du Fragment émetteur comportent au moins un moyen de communication en mode distant, et les moyens de réception du ou de chaque Fragment récepteur comportent au moins un moyen conjugué de communication en mode distant ; les moyens d'émission comportent un moyen d'acquisition propre à acquérir une donnée publiée sur le Port d'entré du Fragment émetteur et à la transmettre soit au moyen de communication en mode local soit au moyen de communication en mode distant ; - les moyens d'émission comportent un moyen de communication TCP et un moyen de communication UDP, et les moyens de réception comportent un moyen conjugué de communication TCP et un moyen conjugué de communication UDP, l'entité comportant, en outre, un fichier de configuration comportant un paramètre de sélection du protocole de communication à utiliser en mode distant ; le ou chaque moyen de communication en mode distant est propre à effectuer une transformation de sérialisation de la donnée à transmettre, et le ou chaque moyen conjugué de communication en mode distant est propre à effectuer une transformation inverse sur la donnée reçue ; - les moyens d'émission comportent un moyen d'écriture dans un buffer d'émission, propre à réserver un espace mémoire du buffer d'écriture et à écrire une donnée appliquée en entrée du moyen d'écriture par le moyen de communication en mode local, et les moyens de réception comportent un moyen de lecture dans un buffer de réception propre à lire une donnée dans le buffer de réception et à l'appliquer en entrée du moyen conjugué de communication en mode local ; les moyens d'écriture et de lecture sont propres à utiliser un buffer commun situé en mémoire partagée. L'invention a également pour objet un support d'enregistrement d'informations comportant les instructions pour l'instanciation sur une installation informatique d'une entité du type de celle présentée précédemment, lorsque ces instructions sont exécutées par l'unité de calcul d'un ordinateur. L'invention a également pour objet une installation informatique comportant au moins une plateforme et au moins une instanciation d'une entité du type de celle présentée précédemment pour la communication à haute vitesse entre une instanciation, sur une première plateforme, d'un Composant émetteur et au moins une instanciation, sur une seconde plateforme, d'un Composant récepteur (14), ces composants respectant le standard CORBA Component Model, version 1.0 et les première et seconde plateformes pouvant être soit confondues, soit distantes et connectées l'une à l'autre par un réseau. L'invention a également pour objet un procédé de communication à haute vitesse entre un Composant émetteur et au moins un Composant récepteur, ces composants respectant le standard CORBA Component Model, version 1.0, comportant les étapes consistant en : - l'instanciation d'une entité du type de celle présentée précédemment ; - l'acquisition par l'entité d'une donné publiée par le Composant émetteur sur le port d'entrée du Fragment émetteur de l'entité ; - la communication de la donnée acquise entre les Fragments émetteur et récepteur de l'entité ; et, - la publication de la donnée sur le Port d'entrée du Composant récepteur via le Port de sortie du Fragment récepteur. L'invention et ses avantages seront mieux compris à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple, et faite en se référant aux dessins annexés sur lesquels : - la figure 1 est une représentation au sens du standard CCM du connecteur selon l'invention pour la communication directe entre deux composants ; et, - la figure 2 est une représentation schématique sous forme de blocs du code métier du connecteur de la figure 1. La présente description se fonde sur les versions des standards les plus à jour à la date de dépôt de la présente demande de brevet, à savoir CORBA Component Model V4.0, plus particulièrement le document « Formal/06-04-01 », ainsi que les deux standards suivants permettant d'étendre le standard CCM : DDS4LwCCM, V1.0 betal, plus particulièrement le document « PTC/2009-02-02 ». Ces documents sont en libre accès sur le site de l'OMG à l'adresse www.omq.orq. L'invention consiste en un Connecteur, au sens du standard DDS4LwCCM, servant d'interface entre un Port de sortie d'un Composant émetteur et un Port d'entrée d'un Composant récepteur. La partie d'enveloppe du Connecteur est représentée schématiquement à la figure 1, tandis que la partie de code métier du Connecteur est représentée à la figure 2. En se référant à la figure 1, le Connecteur 10 assure la communication de données émises par un Composant émetteur 12, vers un Composant récepteur 14. Le Composant émetteur comporte un Port de sortie 13. De manière similaire le Composant récepteur comporte un Port d'entrée 15. Le Connecteur est fragmenté. Il comporte un premier Fragment émetteur et un second fragment récepteur. Le Fragment émetteur comporte un Port d'entrée 23 destiné à être connecté au Port de sortie 13 du Composant émetteur. De manière similaire, le Fragment récepteur comporte un Port de sortie 25 destiné à être connecté au Port d'entrée 15 du Composant récepteur. Le Fragment émetteur 22 constitue un service, au sens du standard DDS4LwCCM, du Port de sortie 13 Composant émetteur. Lors du déploiement de l'application, le Fragment émetteur et le Composant émetteur sont instanciés, ensemble, sur une même plateforme. C'est ce qui est représenté schématiquement sur la figure 1 par le rectangle 32 englobant dans une même entité logicielle le Composant émetteur et le Fragment émetteur. De manière similaire, le Fragment récepteur constitue un service, au sens du standard DDS4LwCCM, associé au Port d'entrée du Composant récepteur. Il est à noter qu'entre le Port d'un Composant et le Port correspondant d'un Fragment, l'échange de données s'effectue directement par un appel de méthode synchrone, le connecteur gérant le mécanisme apte à rendre la connexion asynchrone. Le middleware CORBA n'est pas utilisé. Les Fragments émetteur et récepteur communiquent directement entre eux (flèche F sur la figure 1). Cette communication est totalement transparente du point de vue des Composants émetteur et récepteur. En se référant maintenant à la figure 2, la partie de code métier du connecteur permettant de réaliser la communication directe F va être décrite. Le fragment émetteur 22 comporte des moyens d'émission comportant : - un moyen d'acquisition 52, propre à collecter une donnée publiée sur le port d'entrée 23 du fragment émetteur, et à la transmettre à l'un des moyens de communication ; - un moyen de communication UDP 54, apte à recevoir une donnée du moyen d'acquisition 52 et à l'émettre sur un réseau NETWORK1, conformément au protocole UDP; - un moyen de communication TCP 56, apte à recevoir une donnée du moyen d'acquisition 52 et à l'émettre sur un réseau NETWORK2, conformément au protocole TCP ; - un moyen de communication en mode local 58, apte à recevoir une donnée du moyen d'acquisition 52 et à la publier par appel à un moyen d'écriture 59 ; - un moyen d'écriture 59, propre à réserver, sur requête du moyen d'acquisition 52, un espace mémoire partagé dans le buffer 60 d'une mémoire de la plateforme sur laquelle est déployé le fragment émetteur, et à y écrire une donnée qui lui est transmise par le moyen de communication en mode local 58. Quant à lui, le fragment récepteur comporte : - un moyen conjugué de communication UDP 74, apte à recevoir une donnée UDP reçue sur un canal prédéterminé, et à la publier sur le port de sortie 25 du fragment récepteur ; - un moyen conjugué de communication TCP 76, apte à recevoir une donnée TCP reçue sur un canal prédéterminé, et à la publier sur le port de sortie 25 du fragment récepteur ; - un moyen conjugué de communication en mode local 78, apte à publier sur le port de sortie 25 du fragment récepteur, une données qui lui est transmise par un moyen de lecture 79 ; - un moyen de lecture 79, propre à lire une donnée placée dans un espace mémoire partagée du buffer 60, et à transmettre cette donnée vers le moyen de communication en mode local 78. Le connecteur 10 selon l'invention étend le standard CCM en offrant une sémantique générique pour l'échange de donnée à haute vitesse entre les composants émetteur et récepteur. Le connecteur est configuré lors du déploiement de l'application. Il est configuré en fonction du plan de déploiement, mais également au moyen d'un fichier de configuration tel que le fichier 80 au format « .xml ». Lors du démarrage de l'application, les fragments émetteur et récepteur vont automatiquement détecter s'ils sont instanciés sur une même plateforme de l'installation informatique ou sur deux plateformes différentes. Dans l'affirmative, le mode de communication en mode local est sélectionné. A défaut, le mode de communication à distance est sélectionné. Cette détection automatique s'effectue de la manière suivante dans une implémentation de l'entité 1 vers 1. Chaque Fragment récupère les informations d'adresse IP, de nom de machine, et/ou l'équivalent, de la plateforme sur laquelle il est implémenté. Puis, les deux fragments échangent leurs informations respectives pour déterminer si ces informations sont identiques ou différentes, c'est-à-dire si les deux fragments sont implantés sur la même plateforme ou sur deux plateformes différentes. Le fichier de configuration 80 comporte par exemple un paramètre de qualité de service pour la sélection du protocole de communication en mode distant : soit le mode TCP si le développeur souhaite une communication fiable, soit le mode UDP s'il privilégie la vitesse de communication. En effet, le protocole TCP met en oeuvre des méthodes de vérification de l'intégrité de la transmission de donnée qui augmentent la qualité de la communication, mais ralentissent la vitesse de celle-ci. Le buffer 60 est du type FIFO (pour « First ln First Out »). Dans le présent mode de réalisation, le buffer 60 est commun au fragment émetteur et au fragment récepteur. Le buffer 60 doit pour cela être situé dans une mémoire partagée de la plateforme sur laquelle sont déployés les fragments récepteur et émetteur. Ceci permet d'éviter une copie du contenu d'un buffer d'écriture associé au fragment émetteur, dans un buffer de lecture associé au fragment récepteur. De ce fait, les erreurs de copie sont évitées et, dans le cas d'un connecteur 1 vers N, comportant 1 fragment émetteur et N fragments récepteurs, cela évite N copies du buffer d'écriture. La communication en mode local s'effectue de la manière suivante. Le fragment émetteur 22 et le fragment récepteur 24 sont instanciés, en utilisant les informations contenues dans le plan de déploiement et le fichier de configuration 80, et, en particulier, la sélection du protocole de communication (mode et qualité de service). Le moyen d'acquisition 52 acquiert une nouvelle donnée publiée sur le Port d'entrée 23 du fragment émetteur. II appelle le moyen d'écriture 59 afin que celui-ci réserve un espace mémoire dans le buffer 60 d'échange de données. Dès qu'un espace mémoire est réservé, le moyen d'écriture 59 renvoie un message d'acquittement au moyen d'acquisition 52. Sur ce, le moyen d'acquisition 52 transmet la donnée au moyen de communication en mode local 58. Dès réception de la donnée, le moyen de communication en mode local 58 la transmet au moyen d'écriture 58. Lors de la réception de cette donnée, le moyen d'écriture lance l'exécution d'une méthode d'écriture de la donnée dans l'espace mémoire précédemment réservé. Du côté du fragment récepteur 24, le moyen de lecture 79 parcourt successivement les différents espaces mémoire du buffer 60. Il accède à un espace mémoire et lit la donnée qui y est contenue. Le moyen de lecture 79 transmet à la donnée lue au moyen conjugué de communication en mode local 78 du fragment récepteur. Dès réception de la donnée, le moyen de communication conjugué en mode local 78 la publie sur le Port de sortie 25 du fragment récepteur. Alors que fragment récepteur et fragment(s) récepteur sont instanciés sur des plateformes différentes, reliées entre elles par un réseau, la communication en mode distant s'effectue de la manière suivante : Le fragment émetteur 22 et le fragment récepteur 24 sont instanciés, en utilisant les informations contenues dans le fichier de configuration 80, et, en particulier la sélection du protocole, par exemple TCP, pour l'échange de données sur le réseau NETWORK 2. Le moyen d'acquisition 52 acquiert une nouvelle donnée publiée sur le Port d'entrée 23 du fragment émetteur. Le moyen d'acquisition 52 transmet la donnée au moyen de communication TCP 56. Dès réception de la donnée, le moyen de communication TCP 56 sérialise la données et la transmet sur le réseau. Du côté du fragment récepteur 24, le moyen conjugué de communication TCP 76 scrute un canal prédéterminé et dès réception d'une donnée, il réalise la transformation inverse de la sérialisation. Le moyen conjugué de communication TCP 76 publie la donnée ainsi obtenue sur le Port de sortie 25 du fragment récepteur. Alors que le mode de réalisation qui vient d'être décrit permet une communication 1 vers 1 entre un fragment émetteur et un fragment récepteur, en variante, le connecteur comporte 1 fragment émetteur et N fragments récepteurs pour une communication 1 vers N. En mettant en oeuvre une implémentation du présent connecteur générique, la demanderesse est parvenue, dans une application de traitement d'image vidéo, à réaliser des échanges de données vidéo entre connecteurs à un débit de 160 mégaoctets par seconde en mode local, à 50 mégaoctets par seconde en mode UDP, et à 30 mégaoctets par seconde en mode TCP, et ceci en consommant environ 10% du CPU. La présente solution permet d'optimiser l'usage des ressources matérielles en gérant le flux de données directement à l'intérieur du code métier du connecteur. Ceci permet d'éviter d'avoir recours au service de notification de CORBA qui impose l'implémentation du protocole GIOP. Au contraire, selon l'invention, les données sont sérialisées uniquement lorsque cela s'avère être nécessaire, c'est-à-dire dans le mode distant. De plus, le service de notification de CORBA interdit le partage de données entre composant émetteur et composant récepteur via une mémoire partagée. Il n'offre pas la possibilité du choix de la qualité de service. Par ailleurs, le fait de coder des moyens de communication haute vitesse dans un connecteur plutôt que dans un composant permet d'introduire dans le standard LwCCM une entité générique configurable présentant une interface respectant le standard IDL3 (pour « Interface Description Language », Version 3) Dans l'annexe, est reproduit le code de spécification de l'interface du Connecteur logiciel de l'invention. Ainsi, le code applicatif reste lisible et sa complexité n'augment pas. Il est facile à tester et à maintenir. ANNEXE Implémentation d'un connecteur de communication dénommé "Fast Events" : Interface du connecteur « Fast Events » : // FastEventsSource local interface FastEventsSourcelntf { FastEvents$T$Writer reserve(); void push(in FastEvents$T$Writer writer); void delete(in FastEvents$T$Writer writer); }; 15 port_type FastEventsSourcePort { uses FastEventsSourcelntf none; }; 20 // FastEventsSink local interface FastEventsSinklntf { void push(in FastEvents$T$Reader reader); }; 25 port_type FastEventsSinkPort { provides FastEventsSinklntf none; 30 Exemple d'utilisation : //Définition du type échangé eventtype Ev_Track { 35 public long id; public long date; }; Composant émetteur : 40 component subject { port FastEventsSourcePort tracks_out; 45 Composant récepteur : component sink { port FastEventsSinkPort tracks_in; Connecteur FastEvent : connector FastEventCnx { 10 }; 50 mirrorport FastEventsSourcePort data_in; mirrorport FastEventsSinkPort data_out; }; Code généré pour le marshaller « Fast Events » : module FastEvents { local interface Ev_TrackWriter { void id (in long value); void date (in long value); }; Code généré pour le de-marshaller « Fast Events » : module FastEvents { local interface Ev_TrackReader { long id (); long date Q; }; }; Code généré pour le composant émetteur : local interface Ev Track FastEventsSourcelntf { ::FastEvents::Ev_TrackWriter reserve (); void push (in ::FastEvents::Ev_TrackWriter writer); void delete (in ::FastEvents::Ev_TrackWriter writer); }; component subject { }; Code généré pour le composant récepteur : local interface Ev Track FastEventsSinklntf uses ::Ev_Track_FastEventsSourcelntf tracks_out_src; { void push (in ::FastEvents::Ev_TrackReader reader); }; component sink { provides :: Ev_Track_FastEventsSinklntf tracks_in_snk; }; Code du composant émetteur : //appel sur le contexte du composant pour avoir le réceptacle CC M_subject_Context_ptr source = context->get_connection_tracks_out_src(); //récupération d'une instance de marshaller FastEvents::ISP::Ev_TrackWriter ptr track_ref = source->reserve(); // Remplissage des valeurs 50 track_ref->id(track_infos_. id ); track_ref->date(track_infos_.date); //Envoi de l'événement source->push(track_ref); //Libération du marshaller context->delete_Ev_TrackW riter(track_ref); Code du composant récepteur : //Implementation de la reception void CCM_sink_impl::push(FastEvents::Ev TrackReader ptr trackReader) { long id = trackReader->id(); long date = trackReader->date(); } REVENDICATIONS1.- Entité générique de communication à haute vitesse entre un Composant émetteur (12) et au moins un composant récepteur (14), lesdits composants respectant le standard CORSA Component Model, version 1.0, caractérisée en ce qu'il comporte un connecteur au sens du standard DDS4LwCCM, version 1.0 Betal, comprenant : - un Fragment émetteur (22) comportant une partie d'enveloppe comportant un Port d'entrée (23) destiné à être connecté à un Port de sortie (13) du composant émetteur ; - au moins un Fragment récepteur (24) comportant une partie d'enveloppe comportant un Port de sortie (25) destiné à être connecté à un Port d'entrée (15) dudit au moins un composant récepteur ; - ledit Fragment émetteur comportant une partie de code métier comportant des moyens d'émission (52, 54, 56, 58, 59) d'une donnée publiée sur le Port d'entrée de la partie d'enveloppe dudit Fragment émetteur, à destination dudit au moins un Fragment récepteur ; et, - ledit Fragment récepteur comportant une partie de code métier comportant des moyens de réception (74, 76, 78, 79) de la donnée émise par les moyens d'émission du Fragment émetteur, pour la publication de ladite donnée sur le Port de sortie de la partie d'enveloppe dudit Fragment récepteur. 2.- Entité selon la revendication 1, caractérisée en ce que le Port d'entrée (23) dudit Fragment émetteur et le Port de sortie (25) dudit au moins un Fragment récepteur sont du type synchrone. 3.- Entité selon la revendication 1 ou la revendication 2, caractérisée en ce que les moyens d'émission du Fragment émetteur comportent un moyen de communication en mode local (58), et en ce que les moyens de réception du Fragment récepteur comportent un moyen conjugué de communication en mode local (78). 30 4.- Entité selon la revendication 1 ou la revendication 2, caractérisée en ce que les moyens d'émission du Fragment émetteur comportent au moins un moyen de communication en mode distant (54, 56), et en ce que les moyens de réception du Fragment récepteur comportent au moins un moyen conjugué de communication en 35 mode distant (74, 76).25 5.- Entité selon la revendication 3 et la revendication 4 en combinaison, caractérisée en ce que les moyens d'émission comportent un moyen d'acquisition (52) propre à acquérir une donnée publiée sur le Port d'entré (23) du Fragment émetteur et à la transmettre soit au moyen de communication en mode local (58) soit au moyen de communication en mode distant (54, 56). 6.- Entité selon la revendication 4 ou la revendication 5, caractérisée en ce que les moyens d'émission comportent un moyen de communication TCP (56) et un moyen de communication UDP (54), et en ce que les moyens de réception comportent un moyen conjugué de communication TCP (76) et un moyen conjugué de communication UDP (78), l'entité comportant, en outre, un fichier de configuration (80) comportant un paramètre de sélection du protocole de communication à utiliser en mode distant. 7.- Entité selon l'une quelconque des revendications 4 à 6, caractérisée en ce que le ou chaque moyen de communication en mode distant (54, 56) est propre à effectuer une transformation de sérialisation de la donnée à transmettre, et en ce que le ou chaque moyen conjugué de communication en mode distant (74, 76) est propre à effectuer une transformation inverse sur la donnée reçue. 8.- Entité selon l'une quelconque des revendications 3 à 7, caractérisée en ce que les moyens d'émission comportent un moyen d'écriture (59) dans un buffer d'émission, propre à réserver un espace mémoire du buffer d'écriture et à écrire une donnée appliquée en entrée du moyen d'écriture par le moyen de communication en mode local (58), et les moyens de réception comportent un moyen de lecture (79) dans un buffer de réception propre à lire une donnée dans le buffer de réception et à l'appliquer en entrée du moyen conjugué de communication en mode local (78). 9.- Entité selon la revendication 8, caractérisée en ce que les moyens d'écriture et de lecture (59, 79) sont propres à utiliser un buffer (60) commun situé en mémoire partagée. 10.- Support d'enregistrement d'informations, caractérisé en ce qu'il comporte les instructions pour l'instanciation sur une installation informatique d'une entité conforme à l'une quelconque des revendications 1 à 9, lorsque ces instructions sont exécutées par l'unité de calcul d'un ordinateur. 11.- Installation informatique comportant au moins une plateforme, caractérisée en ce qu'elle comporte au moins une instanciation d'une entité conforme à l'une quelconque des revendications 1 à 9 pour la communication à haute vitesse entre une instanciation sur une première plateforme d'un Composant émetteur (12) et au moins une instanciation sur une seconde plateforme d'un Composant récepteur (14), lesdits composants respectant le standard CORBA Component Model, version 1.0 et lesdites première et seconde plateformes pouvant être soit confondues, soit distantes et connectées l'une à l'autre par un réseau. 12.- Procédé de communication à haute vitesse entre un Composant émetteur (12) et au moins un Composant récepteur (14), lesdits composants respectant le standard CORBA Component Model, version 1.0, caractérisé en ce qu'il comporte les étapes consistant en : - l'instanciation d'une entité selon l'une quelconque des revendications 1 à 9 ; - l'acquisition par ladite entité d'une donné publiée par le Composant émetteur sur le port d'entrée du Fragment émetteur de ladite entité ; - la communication de la donnée acquise entre les Fragments émetteur et récepteur de ladite entité ; et - la publication de la donnée sur le Port d'entrée du Composant récepteur via le Port de sortie du Fragment récepteur.