Brevet FR2822984A1 — publié le 20021004

code de coach Sac salon lice de 1'6c de consignee. Procédé et système pour une communication d'évènements sur une plateforme à scanners/postes de travail répartis Le domaine de l'invention est celui des procédés et systèmes d'imagerie médicale. En particulier, l'invention porte sur un procédé et système qui permet une remise fiable et transparente d'événements dans une plate-forme d'imagerie médicale à scanners et postes de travail répartis comprenant de multiples hôtes utilisant un ou plusieurs langages. Durant le fonctionnement typique d'un système d'imagerie médicale comportant une plate-forme à scanners/postes de travail, de nombreux événements sont générés et reçus, les événements étant des paquets de données auto-descripteurs remis entre différentes applications (programmes évolués). De manière traditionnelle, une plate-forme à scanners/postes de travail était réalisée sur un seul ordinateur hôte. En outre, les applications exploitées sur l'hôte étaient typiquement programmées dans le langage C++ ou un autre langage de type C. En raison de la simplicité structurelle de ces systèmes et du degré auquel les divers éléments de ces systèmes partageaient les mémes protocoles de communication, une remise d'événements entre des applications dans ces systèmes pouvait être réalisée facilement et rapidement, sans utiliser aucune technique de communication spécialisée. Toutefoi s, l es pl ate s-formes à scanners/postes de travail de nouvelle génération sont devenues de plus en plus complexes dans leur structure et leur fonctionnement. Un grand nombre de ces plates-formes à scanners/postes de travail emploient de multiples hôtes, utilisent de multiples architectures (par exemple petit-boutiste/gros-boutiste) et utilisent de multiples langages tels que C++ ou JAVA (pour mettre en _uvre des interfaces utilisateur). En outre, comme les plates-formes à scanners/postes de travail ont été reliées à l'Internet, les platesformes à scanners/postes de travail ont aussi commencé à employer et/ou à interagir avec des applets et d'autres protocoles Internet. En résultat de cet accroissement de complexité des plates-formes à scanners/postes de travail, la communication d'événements entre applications exploitées sur les plates-formes à scanners/postes de travail est aussi devenue de plus en plus compliquée. En particulier, il est souhaitable que la programmation des applications tienne compte de toutes les complications influant sur le transfert de données entre applications, qui résultent de l'utilisation de multiples hôtes, de multiples architectures et de multiples langages, incluant des protocoles de communication Internet. Bien qu'une telle programmation des applications tenant compte de toutes ces complications soit réalisable, elle est complexe et coûteuse, et le fonctionnement résultant des plates- formes à scanners/postes de travail est souvent lent et parfois peu fiable. Par conséquent, une programmation permettant une communication d'événements au moyen de procédés traditionnels requiert une grande connaissance des logiciels de la part du programmateur des logiciels, et est difficile pour quelqu'un qui n'est pas réellement programmateur (par exemple un chercheur utilisant les systèmes d'imagerie médicale). Il serait donc avantageux de mettre au point un système qui permette aux applications exploitées sur la ou les plates-formes à scanners/postes de travail d'un système d'imagerie médicale de communiquer des événements entre elles de manière facile et fiable, méme lorsque la ou les platesformes à scanners/postes de travail comprennent de multiples hôtes ou emploient de multiples architectures. Il serait également avantageux qu'un tel système permette aussi une communication facile et fi able d' événements entre applications méme lorsque les applications sont programmées dans différents langages d'ordinateur. Il serait en outre avantageux qu'un tel système permette une communication facile et fiable d'événements même entre des applications et des applets, ou entre les applications des plates-formes à scanners/postes de travail et l'Internet. La présente invention porte sur un système d'imagerie médicale comprenant au moins un hôte, et comprenant en outre une première application, une seconde application, et un service de nom d'événement. La première application est au niveau de l'au moins un hôte, et est une première source d'événements. La seconde application est au niveau de l'au moins un hôte, et est une première auditrice d'événements capable de recevoir un premier événement provenant de la première application. Le service de nom d'événement est en communication avec les première et seconde applications. Au moins une des première et seconde applications est capable de s'inscrire auprès du service de nom d'événement. La présente invention porte en outre, dans un système d'imagerie médicale, sur un système de communication d'informations qui comprend une pluralité d'applications sources d'événements, une pluralité d'applications auditrices d'événements, un moyen d'hébergement, et un service de nom d'événement auquel les applications auditrices d'événements peuvent s'inscrire. Les applications sources d'événements sont capables de remettre des événements, en tant qu'éditeurs, à des applications auditrices d'événements. Les applications auditrices d'événements sont capables de recevoir, en tant qu'abonnés, au moins certains des événements provenant des applications sources d'événements, en utilisant un mécanisme de filtrage d'événement. Le moyen d'hébergement sert à héberger au moins une de la pluralité d'applications sources d'événements et auditrices d'événements. Les applications sources d'événements ne remettent des événements aux applications auditrices d'événements que si les applications auditrices d'événements sont inscrites pour ces événements auprès du service de nom d'événement. La présente invention porte en outre, dans un système d'imagerie médicale, sur un procédé de communication d'informations. Le procédé inclut le fait de prévoir une première application qui est une auditrice d'événements, une seconde application qui est une source d'événements, et un service de nom d'événement, et d'inscrire au moins une de l'auditrice d'événements et la source d'événements auprès du service de nom d'événement. Le procédé inclut en outre le fait d'envoyer un événement de la source d'événements à l'auditrice d'événements lorsque l'au moins une de l'auditrice d'événements et la source d'événements est inscrite auprès du service de nom d'événement. La présente invention porte en outre sur un procédé de communication d'informations sur une plate-forme d'imagerie médicale à scanners/postes de travail répartis. Le procédé inclut le fait de prévoir une première source d'événements sur un premier hôte de la plate-forme, de prévoir une première auditrice d'événements sur un second hôte de la plate-forme, et d'inscrire la première source d'événements à un service de nom d'événement. Le procédé inclut en outre le fait de remettre une liste comprenant la première source d'événements et une seconde source d'événements en réponse à une demande, de déterminer si une source d'événement désiré capable de remettre un événement désiré comme demandé par la première auditrice d'événements est inscrite et, lorsque la source d'événement désiré est inscrite, remettre l'événement désiré de la source d'événement désiré à la première auditrice d'événements. L'invention sera mieux comprise à l'étude de la description détaillée de quelques exemples de réalisation, illustrée par les dessins annexés sur lesquels: 1a figure 1 est un schéma synoptique représentant 1'interaction d'applications sur un exemple de système à scanners/postes de travail répartis qui fonctionnent pour communiquer des événements; la figure 2 est un schéma synoptique représentant des bibliothèques utilisées par le système de la figure 1; la figure 3 est un schéma synoptique représentant des interfaces et objets dans une bibliothèque C++ DEMIDL de la figure 2; les figures 4-6 sont des schémas synoptiques représentant des classes enveloppes dans une bibliothèque C++ DEM de la figure 2; et les figures 710 sont des schémas d'interaction représentant le fonctionnement d'API qui permettent une communication d'événements entre les applications de la figure 1. A propos de la figure 1, un schéma synoptique représente comment des applications d'une plate-forme d'imagerie médicale 2 à scanners/postes de travail répartis communiquent des événements entre elles. Comme représenté, une application qui est une source d'événements, à savoir une source d'événements 10, est exploitée sur un premier hôte 22. La source d'événements peut remettre un ou plusieurs événements à une application qui écoute des événements, à savoir une auditrice d'événements 20, représentée comme étant exploitée sur un second hôte 24. De plus, la source d'événements 10 et l'auditrice d'événements 20 sont chacune en communication avec un emplacement centralisé servant à fournir des services d'événements, à savoir un service de nom d'événement 30. Le service de nom d'événement 30 peut exister sur le premier hôte 22, le second hôte 24, ou ailleurs. s La figure 1 est globalement représentative de n'importe quelle paire d'applications exploitées sur un système d'imagerie médicale donné. Comme représenté, les deux applications peuvent être des applications qui sont hébergées par deux hôtes différents, qui peuvent exister dans un même appareil d'imagerie médicale, ou dans deux appareils d'imagerie médicale séparés. Dan s d'autres vari antes, la première appli c ation (c'est-àdire la source d'événements 10) est hébergée par un appareil médical qui est en communication avec la seconde application d'un second appareil par l'Internet. Pour plus de généralité, la plate-forme 2 à scanners/postes de travail de la figure 1 est représentée comme comprenant des hôtes supplémentaires 26, 28 sur lesquels d'autres applications peuvent exister et communiquer entre elles. Les deux programmes d'application qui communiquent peuvent aussi être exploités sur des hôtes qui utilisent des architectures différentes ou multiples (par exemple, petit-boutiste/gros-boutiste), ou peuvent être hébergés 1S par des hôtes utilisant une même architecture. La source d'événements 10 et l'auditrice d'événements 20 peuvent chacune fonctionner au moyen de n'importe lequel d'un certain nombre de langages, tels que C++ ou Java. Si la source d'événements 10 est hébergée sur un appareil d'imagerie médicale différent de l'auditrice d'événements 20, ces deux appareils peuvent être connectés par n'importe laquelle d'un certain nombre de liaisons de communication, incluant l'Internet. La plate-forme 2 à scanners/postes de travail peut inclure des appareils d'imagerie médicale de divers types, par exemple des systèmes d'imagerie par résonance magnétique (IRM), des systèmes de tomodensitométrie, des systèmes à scanners de tomographie par émission de positons (TEP), des scanners à rayons X et des scanners d'imagerie nucléaire. Le ou les événements qui sont communiqués entre la source d'événements 10 et l'auditrice d'événements 20 peuvent être n'importe quels ensembles de données qui contiennent à la fois des données réelles et des données autodescriptives. A savoir, les informations remises en tant qu'événement doivent inclure une information indiquant comment ces informations doivent 8tre exploitées. Les événements peuvent aller de simples chaînes (par exemple "bonjour") à des matrices complexes de valeurs ainsi qu'à des données ayant divers autres formats. Un exemple du premier hôte 22 destiné à la source d'événements 10 est un scanner d'imagerie médicale ayant obtenu une image balayée et l'ayant mémorisée dans sa base de données après balayage d'un patient. Dans ce cas, une application de ce scanner d'imagerie médicale peut recevoir une demande provenant d'une application exploitée sur un autre appareil, tel qu'une imprimante, de remise des informations balayées. Dans ce cas, si les informations sont transmises du scanner d'imagerie médicale à l'imprimante, la source d'événements 10 serait une application sur le scanner d'imagerie médicale et l'auditrice d'événements 20 serait un programme d'application sur l'imprimante. Comme représenté par la figure 1, le service de nom d'événement 30 est en communication avec à la fois la source d'événements 10 et l'auditrice d'événements 20. L'auditrice d'événements 20 est capable d'accéder aux informations provenant du service de nom d'événement 30 sous la forme d'une liste de toutes les sources d'événements de la plate-forme 2 à scanners/postes de travail, qui comporte souvent de multiples sources d'événements fonctionnant simultanément. Le service de nom d'événement 30 est en outre capable d'identifier la ou les sources d'événements qui peuvent avoir généré n'importe quel événement particulier donné. Le service de nom d'événement 30 joue donc le rôle d'un suppléant pour des sources d'événements qui ne sont pas encore en ligne. Dans le cas o une source d'événements vient juste de passer en ligne après avoir été hors ligne, le service de nom d'événement 30 cesse de jouer le rôle d'un suppléant. Le service de nom d'événement 30 fonctionne comme une seule application qui connecte tous les hôtes hébergeant les différentes applications qui sont potentiellement des sources d'événements ou des auditrices d'événements. La relation entre la source d'événements 10 et l'auditrice d'événements se déroule conformément à un modèle abonné-éditeur au moyen d'une technique de rappel réparti. A n'importe quel instant donné, n'importe quelle application donnée peut jouer le rôle d'un éditeur (c'est-à-dire une source d'événements) ou d'un abonné (c'est-à-dire une auditrice d'événements). Les applications qui sont les éditeurs (sources d'événements) mettent en ceuvre des interfaces de programme d'application (API) qui sont bien connues des personnes compétentes dans l'art, et qui permettent à des abonnés (auditrices d'événements) de s'inscrire aux ou de se faire radier des éditeurs. En outre, les éditeurs emploient des API bien connues pour transmettre des événements dans un mode de multidiffusion ou à un groupe d'abonnés qui vérifient un critère de filtrage déterminé par le service de nom d'événement 30. Les auditrices 20 abonnées pour un événement mettent en _uvre des API bien connues qui sont invoquées lorsque des événements sont transmis. Les abonnés peuvent en outre régler, au niveau du service de nom d'abonné 30, les filtres qui indiquent les types d'événements qu'ils souhaitent écouter ou recevoir. Les filtres peuvent être de simples filtres restrictifs qui autorisent seulement la remise d'un seul événement particulier à un abonné donné, ou être plus compliqués et permettre la remise de certaines combinaisons d'événements à un abonné. Les abonnés et éditeurs inclus dans l'ensemble du - réseau peuvent être localisés par utilisation de programmes de localisation de . servces ben connus. La figure 2 est un schéma de paquetage d'un support logiciel utilisé par les applications pour une communication d'événements sur la plate-forme 2 à scanners/postes de travail répartis. Le langage utilisé par et entre les diverses applications est typiquement le langage CORBA, qui est une norme de communication répartie bien connue dans l'art. Toutefois, dans des variantes, d'autres langages peuvent être utilisés. Comme représenté sur la figure 2, le schéma de paquetage comprend une bibliothèque C++ DEM 40, qui exécute des procédés d'enveloppement et des API commodes qui sont en C++, qui mettent en _uvre des interfaces de niveau application. La bibliothèque C++ DEM 40 inclut une bibliothèque C++ DEMJNI 50 et une bibliothèque Java DEMjar 60, qui sont les paquetages générés. La bibliothèque C++ DEMJNI 50 contient des interfaces C++ générées par cxxwrap qui sont utilisées par des applications Java. La bibliothèque DEMjar 60 contient des API Java. Dans la forme de réalisation représentée, la bibliothèque C++ DEMJNI et la bibliothèque Java DEMjar 60 sont sous le format interface native Java (JNI), qui permet une traduction entre le langage Java et le langage C++. La bibliothèque C++ DEM 40 contient en outre une bibliothèque C++ DEMIDL , qui met en ceuvre les interfaces de niveau application fournissant les mécanismes de communication pour une communication entre différentes applications. La bibliothèque C++ DEMIDL 70 définit 1'ensemble basique d'interfaces IDL, qui sont conformes à la norme de communication répartie CORBA. Bien que le schéma de paquetage de la figure 2 comprenne des bibliothèques C++ et des bibliothèques Java et soit configuré pour un fonctionnement conformément à la norme CORBA, dans des variantes les langages et normes de communication particuliers peuvent varier. La figure 3 représente un exemple de paquetage DEMIDL 170 pouvant se trouver dans la bibliothèque C++ DEMIDL 70. Le paquetage DEMIDL 170 représenté comprend trois interfaces, une interface ISource 110, une interface IListener 120 et une interface INameService 130. L'interface ISource 110 est l'interface que toutes les sources d'événements doivent mettre en _uvre, soit directement soit au moyen d'un objet qui est inclus dans la source d'événements. L'interface IListener 120 est l'interface que toutes les auditrices d'événements doivent mettre en ceuvre. L'interface INameService 130 est l'interface qui réalise une recherche de nom pour les sources d'événements et auditrices d'événements. Une classe FilterRep 140, une classe ListenerRep 150 et une classe EventRep 160 sont aussi incluses dans le paquetage DEMIDL. La classe FilterRep 140 et la classe ListenerRep 150 sont toutes les deux utilisces par l'interface ISource 110. La classe FilterRep 140 permet à l'auditrice d'événements 20 de n'être appelée que lorsqu'il se produit un événement de type désiré. La classe FilterRep 140 peut être utilisée comme une seule classe ou être subdivisée. La classe ListenerRep 150 est un objet de rappel automatique qui permet à la source d'événements 10 de transmettre un événement à l'auditrice d'événements 20. La classe EventRep 160 est l'événement de base qui est remis à l'auditrice d'événements 20 depuis la source d'événements 10, et est utilisée par l'interface IListener 120. La classe ListenerRep 150 est aussi en communication avec l'interface IListener 120, de sorte que l'interface ISource 110 peut déterminer quand transmettre un événement à l'auditrice d'événements 20 depuis la source d'événements 10. L'interface INameService 130 est en communication avec l'interface ISource , et l'interface INameService supporte le nombre d'API représenté. Les figures 4-6 représentent trois sections 240a, 240b et 240c d'un exemple de paquetage DEM 240. Le paquetage DEM 240 correspond à, et peut se trouver ou être contenu dans la bibliothèque C++ DEM 40. Comme représenté, le paquetage DEM 240 comprend trois classes: une classe TerraSourceUtil 210 représentée dans la section 240a sur la figure 4; une classe TerraListenerUtil 230 représentée dans la section 240b sur la figure 5; et une classe TerraNameServiceUtil 260 représentée dans la section 240c sur la figure 6. La classe TerraSourceUtil 210 est une classe enveloppe qui définit les API qui doivent être mises en _uvre pour n'importe quelle application qui est une source d'événements, telle que la source d'événements 10. La classe TerraSourceUtil 210 fournit une mise en ceuvre par défaut de ces API, qui peut varier selon la forme de réalisation. De plus, la classe TerraSourceUtil 210 cache tous les détails CORBA et fournit une interface simple et facile à utiliser. La classe TerraListenerUtil 230 est une classe enveloppe qui fournit un mécanisme permettant à une auditrice d'un événement particulier (telle que l'auditrice d'événements 20) d'obtenir ou de recevoir l'événement. La classe TerraListenerUtil 230 emploie un pointeur (appelé dans ce cas "EventDispatcher") pour permettre à l'auditrice d'événements 20 d'obtenir le contenu de l'événement. En ce qui concerne la classe TerraNameServiceUtil 260, il s'agit d'une classe singleton qui fournit les références de sources possibles aux auditrices d'événements, et est le serveur de nom centralisé. Il est prévu que les diverses sources d'événements telles que la source d'événements 10 s'inscrivent à la classe TerraNameServiceUtil 260. La classe TerraNameServiceUtil 260 peut aussi enregistrer des auditrices d'événements, tell es que l 'auditrice d'événements 20, qui sont en attente de sources d'événements particuliers, avant apparition des sources d'événements. Comme représenté sur les figures 4-5, la classe TerraSourceUtil 210 inclut une sous-classe ISourceImpl 220, et la classe TerraListenerUtil 230 inclut une sous-classe TerraEventUtil 250 et une sous-classe IListenerImpl 280. Comme représenté sur la figure 6, la classe TerraNameServiceUtil 260 inclut une sous-classe NameServiceUtil 270. Chaque auditrice d'événements 20 inclut la classe TerraListenerUtil 230 et les sous-classes 250 et 280; chaque source d'événements 210 inclut la classe TerraSourceUtil 210 et la sous-classe ISourceImpl 220, et chaque service de nom d'événement 30 inclut la classe TerraNameServiceUtil 260 et la sous-classe NameServiceUtil 270. La bibliothèque C++ DEMJNI 50 et la bibliothèque Java DEMJar 60 comprennent des classes et sous-classes similaires qui diffèrent de cell es des figures 4-6 principalement par le seul fait que les informations des classes et sous-classes dans le paquetage DEM 240 des figures 4-6 ont été enveloppées par le programme cxxwrap. A propos de la figure 7, un schéma d'interaction représente un exemple d'interaction entre la classe TerraSourceUtil 210 de la source d'événements 10 et la classe TerraListenerUtil 230 de l'auditrice d'événements 20 durant la transmission d'un événement de la source d'événements à l'auditrice d'événements. Comme représenté, l'interaction inclut une première étape 310, à laquelle la classe TerraSourceUtil 210 détermine quelles auditrices d'événements sont en attente d'un événement, et une seconde étape 320 à laquelle la classe TerraSourceUtil 210 transmet l'événement particulier à la classe TerraListenerUtil 230 des auditrices appropriées, qui dans ce cas incluent l'auditrice d'événements 20. A propos de la figure 8, un schéma d'interaction représente un exemple d'interaction entre la classe TerraNameServiceUtil 260 et la classe TerraSourceUtil 210 du service de nom d'événement 30 et de la source d'événements 10, respectivement, durant l'inscription et la radiation de la source d'événements du service de nom d'événement. Comme représenté, la classe TerraSourceUtil 210 peut envoyer soit une commande de service d'inscription à la classe TerraNameServiceUtil 260 à une étape 330 soit une commande de service de radiation à la classe TerraNameServiceUtil à une étape 340, qui provoquent respectivement soit l'inscription de la source d'événements 10 auprès du service de nom d'événement 30 soit sa radiation. A propos de la figure 9, un schéma d'interaction représente comment la classe TerraListenerUtil 230 de 1'auditrice d'événements 20 peut contacter la classe TerraNameServiceUtil 210 du service de nom d'événement 30, afin d'envoyer des informations indiquant que l'auditrice d'événements souhaite recevoir un type particulier d'événement. Pour cela, une commande de service de liste est transmis de la classe TerraListenerUtil 230 à la classe TerraNameServiceUtil 210 à une étape 350. A propos de la figure 10, un schéma d'interaction représente comment l'auditrice d'événements 20 est capable de s'inscrire pour recevoir un événement même lorsque aucune source d'événements capable de ï communiquer l'événement n'est encore présente. Dans ce cas, le service de nom d'événement 30 joue le rôle d'un serveur mandataire de la source d'événement désiré, et transfère l'inscription une fois que la source d'événement est en ligne. Comme représenté, à une étape 360 la classe TerraListenerUtil 230 transmet une commande ajouter auditrice à la classe TerraNameServiceUtil 260 du service de nom d'événement 30. A une étape 370, le service de nom d'événement détermine si une source d'événement désiré pouvant communiquer l'événement désiré existe actuellement ou est en ligne. Une fois que la source d'événement désiré est en ligne, à une étape 380 la classe TerraNameServiceUtil 260 envoie un ordre ajouter auditrice à la classe TerraSourceUtil 210 de la source d'événements (par exemple, la source d'événements 10). Les formes de réalisation représentées sur les figures 1-10 sont destinées à illustrer plusieurs formes de réalisation différentes dans lesquelles une ou plusieurs auditrices d'événements sont en communication avec une ou plusieurs sources d'événements, au moyen d'un ou plusieurs services de nom d'événement. Les formes de réalisation représentées permettent à des applications correspondant aux sources d'événements et auditrices d'événements, qui sont écrites soit en C++ soit en Java, de fonctionner au moyen de la méme interface de programmation. En outre, les formes de réalisation représentées peuvent facilement s'étendre à des applications qui sont hébergées sur de multiples hôtes et sont écrites dans de multiples langages ou utilisent des communications par applets. Dans un mode de réalisation de l' invention, au moins une des première et seconde applications comprend les applets. Dans un mode de réalisation de l' invention, chacune des applications est soit une source d' évènements soit une auditrice d' évènements. Dans un mode de réalisation de l' invention, au moins certaines des applications supplémentaires sont des auditrices d'évènements supplémentaires et la première source d'évènements 10 décide de remettre ou non le premier événement à la première auditrice d'événements 20 et aux auditrices d'événements supplémentaires en se basant sur un filtre déterminé par le service de nom d'événement 30 en réponse à l'inscription d'au moins certaines de la première auditrice d'événements 20 et des auditrices d'événements supplémentaires auprès du service de nom d'événement 30. Dans un mode de réalisation de l' invention, au moins certaines des applications supplémentaires sont des auditrices d'événements supplémentaires, et en ce que la première source d'événements 10 remet le premier événement à la première auditrice d'événements 20 et à chacune des auditrices d'événements supplémentaires dans un mode de fonctionnement multidiffusion. Dans un mode de réalisation de l' invention, au moins certaines des applications supplémentaires sont des sources d'événements supplémentaires, et la première auditrice d'événements 20 est capable d'envoyer une commande au service de nom d'événement 30 de remise d'une liste 350 de la première source d'événements 10 et des sources d'événements supplémentaires qui sont actuellement actives. Dans un mode de réalisation de l' invention, la classe IListener est mise en _uvre dans la première auditrice d'évènements 20. REVENDICATIONS 1. Système d'imagerie médicale (2) comprenant au moins un hôte (22, 24), et comprenant en outre: une première application (10) au niveau dudit au moins un hôte (22, 24), la première application étant une première source d'éYénements (10); une seconde application (2û) au niveau dudit au moins un hôte (22, 24), la seconde application étant une première auditrice d'événements (203 capable de recevoir un premier événement fourni par la première application (10); et un service de nom d'événement (30) en communication avec les première et seconde applications (10, 20), caractérisé en ce que au moins une des première et seconde applications est capable de s'inscrire auprès du service de nom d'événement. 2. Système selon la revendication 1, caractérisé en ce que ledit au moins un hôte comprend un premier hôte (22) et un second hôte (24), en ce que la première application (10) est au niveau du premier hôte (2) et la seconde application (20) est au niveau du second hôte (24), et en ce que les premier et second hôtes diffèrent par au moins un paramètre parmi leurs langages respectifs, leurs architectures respectives, ou les appareils respectifs sur lesquels les hôtes respectifs résident. 3. Système selon la revendication 1, caractérisé en ce que la communication du premier événement entre les première et seconde applications (10, 20) se déroule par la vole de l'Internet, et au moins une des première et seconde applications comprend des applets. 4. Système selon la revendication 1, caractérisé en ce que l'application qui est capable de s'inscrire auprès du service de nom d'événement (30) est aussi capable de se radier du service de nom d'événement (30). 5. Système selon la revendication 1, comprenant en outre une pluralité d'hôtes supplémentaires (26, 28) qui hébergent une pluralité d'applications supplémentaires, caractérisé en ce que chacune des applications est soit une source d'événements soit une auditrice d'événements. 6. Système selon la revendication 5, caractérisé en ce que au moins certaines des applications supplémentaires sont des auditrices d'événements supplémentaires, et en ce que la première source d'événements (10) décide de remettre ou non le premier événement à la première auditrice d'événements (20) et aux auditrices d'événements supplémentaires en se basant sur un filtre déterminé par le service de nom dévénement (30) en réponse à l'inscription d'au moins certaines de la première auditrice d'événements (20) et des auditrices d'événements supplémentaires auprès du service de nom d'événement (30). 7. Système selon la revendication 5, caractérisé en ce que au moins certaines des applications supplémentaires sont des auditrices d'événements supplémentaires, et en ce que la première source dévénements (10) remet le premier événement à la première auditrice d'événements (20) et à chacune des auditrices d'événements supplémentaires dans un mode de fonctionnement multidiffusi on. 8. Système selon la revendication 5, caractérisé en ce que au moins certaines des applications supplémentaires sont des sources d'événements supplémentaires, et en ce que la première auditrice d'événements (20) est capable d'envoyer une commande au service de nom d'événement (30) de remise d'une liste (350) de la première source d'événements (10) et des sources d'événements supplémentaires qui sont actuellement actives. 9. Système selon la revendication 1, caractérisé en ce que, lorsque la première auditrice d'éYénements (20) s'inscrit auprès du service de nom d'événement (30) pour recevoir le premier événement mais la première source d'événements (10) n'est pas encore en ligne, le service de nom d'événement (30) joue le rôle d'un serveur mandataire de la première source d'événements (10) jusqu'à ce que la première source d'événements soit en ligne. 10. Système selon la revendication 1, caractérisé en ce que les première et seconde applications (10, 20) emploient chacune un paquetage incluant une bibliothèque C++ DEM (40), une bibliothèque C++ DEh1IDL (70), une bibliothèque C++ DEMJNI (50), et une bibliothèque Java DEMjar (60). 11. Système selon la revendication 10, caractérisé en ce que chaque bibliothèque C++ DEM (40) comprend un paquetage DEM (240a, 240b, 240c) comprenant une classe TerraSourceUtil (210), une classe TerraListenerUtil (230) et une classe TerraNameServiceUtil (260), en ce que chaque classe TerraSourceUtil comprend une sous-classe ISourceImpl (220), en ce que chaque classe TerraListenerUtil comprend une sous-classe TerraEventUtil 1; (250) et une sous-classe IListenerImpl (280); et en ce que chaque classe TerraNameServiceUtil comprend une sous-classe NameServiceUtil (270. 12. Système selon la revendication 1O, caractérisé en ce que chaque bibliothèque C++ DEMIDL (70) comprend un paquetage DEMIDL (170) qui comprend une classe INameService (130), une classe ISource (110) et une classe IIistener (12), en ce que la classe INameService est mise en _uvre dans le service de nom d'événement (30), la classe ISource est mise en _uvre dans la première source d'événements (10) et possède une classe FilterRep (140) et une classe ListenerRep (150), en ce que la classe ListenerRep (150) est aussi en association avec la classe IListener (120), et en ce que la classe IListener est mise en _uvre dans la première auditrice d'événements (20) et possède une classe EventRep (1601. 13. Système selon la revendication 1, dans lequel le système d'imagerie médicale (2) est un système parmi un système d'imagerie médicale IRM, un système de tomodensitométrie, un système d'imagerie médicale TEP, un scanner à rayons X et un scanner d'magerie nucléaire. 14. Dans un système d'imagerie médicale (2), système de communication d'informations comprenant: une pluralité d'applications sources d'événements (10), les applications sources d'événements étant capable de remettre des événements, en tant qu'éditeurs, à des applications auditrices d'événements (20); une pluralité d'applications auditrices d'événements (20), les applications auditrices d'événements étant capables de recevoir, en tant qu'abonnés, au moins certains des événements provenant des applications sources d'événements (10) en utilisant un mécanisme de filtrage d'événement; un moyen d'hébergement (22 et/ou 24) pour héberger au moins une de la pluralité d'applications sources d'événements et auditrices d'événements (10, ); et un service de nom d'événement (30) auprès duquel les applications auditrices d'événements peuvent s'inscrire, caractérisé en ce que les applications sources d'événements (10) ne remettent les événements aux applications auditrices d'événements (20) que si les applications auditrices d'événements sont inscrites pour les événements auprès du service de nom d'événement (30). 15. Système selon la revendication 13, caractérisé en ce que au moins une des applications sources d'événements (10) et une des applications auditrices d'événements (20) sont hébergées sur un seul dispositif hôte, le seul dispositif hôte étant inclus dans un moyen d'hébergement (22 et/ou 24), et en ce que le langage employé dans la communication de 1'événement est CORBA. 16. Système selon la revendication 13, caractérisé en ce que 1'une des applications sources d'événements (10) est hébergée sur un dispositif hôte (22) différent de 1'une des applications auditrices d'événements (20), et 1'une des applications sources d'événements ( 10) emploie une architecture différente et un langage différent de l'une des applications auditrices d'événements (20). 17. Dans un système d'imagerie médicale (2), procédé de communication d'informations, le procédé étant caractérisé par le fait de: prévoir une première application (20) qui est une auditrice d'événements, une seconde application (10) qui est une source d'événements, et un service de nom d'événement (30); inscrire (330, 360) au moins une de l'auditrice d'événements (20) et la source d'événements (10) auprès du service de nom d'événement (30); et envoyer (320) un événement de la source d'événements (10) à 1'auditrice d'événements (20) lorsque l'au moins une de l'auditrice d'événements et la source d'événements est inscrite auprès du service de nom d'événement (30) . 18. Procédé selon la revendication 17, caractérisé en ce que l'inscription de l'au moins une de l'auditrice d'événements et la source d'événements auprès du service de norn d'événement (30} est l'inscription (330) de l'auditrice d'événements (20) auprès du service de nom d'événements (30), et comprenant en outre le fait de: déterminer si une source d'événement particulier pouvant remettre un événement désiré existe actuellement (370); fournir un serveur mandataire de la source d'événement particulier si la source d'événement particulier n'est pas actuellement en ligne, le serveur mandataire étant fourni par le service de nom d'événement; et transférer une inscription du serveur mandataire à la source d'événement particulier lorsque la source d'événement particulier arrive en }igne (380). . 19. Procédé selon la revendication 17, caractérisé en outre par le fait de: fournir une liste des sources d'événements inscrites (350); et radier l'au moins une de l'auditrice d'événements et la source d'événements du service de nom d'événement (340). 20. Procédé de communication d'informations sur une plate-forme d'imagerie médicale (2) à scanners/postes de travail répartis, le procédé étant caractérisé par le fait de: prévoir une première source d'événements (10) sur un premier hôte (22) de la plate-forme; prévoir une première auditrice d'événements (20) sur un second hôte (24) de la plate- forme; inscrire (330) la première source d'événements (10) auprès d'un service de nom d'événement (30); fournir une liste comprenant la première source d'événements (10) et une seconde source d'événements en réponse à une demande (350); déterminer si une source d'événement désiré capable de remettre un événement désiré comme demandé par la première auditrice d'événements (20) est inscrite (310); et lorsque la source d'événement désiré est inscrite, transmettre (320) l'éYénement désiré de la source d'événement désiré à la première auditrice