FR 2762951 A1 19981106 FR 9705452 A 19970502 La présente invention concerne un procédé de transmission d'une notification dans un réseau de traitement d'informations à applications distribuées. Elle concerne en outre un réseau mettant en oeuvre ce pro- cédé. L'invention s'applique en particulier à l'architecture d'objets distri- bués de réseaux respectant la spécification "Common Object Request Broker Architecture" (CORBA) de "The Object Management Group" (OMG). Dans cette architecture, les objets sont distribués sur les différen- tes unités de traitement d'informations présentes dans le réseau. Ils communiquent par l'intermédiaire d'un bus logiciel désigné par "Object Request Broker' (ORB) dans la spécification CORBA Le terme "bus logiciel" désigne l'entité qui permet à des objets d'envoyer et de recevoir des requêtes dans un environnement distribué. Les applications distribuées sont implantées sur des unités de traitement d'informations communiquant entre elles par d'une part le support physi- que sur lequel sont connectées les unités de traitement d'informations formant le réseau, et d'autre part par les couches inférieures du protocole de communication, c'est-à-dire par exemple les couches IP (Intemrnet Pro- tocol) et TCP (Transmission Control Protocol). Les unités de traitement d'informations sont par exemple des auto- commutateurs d'un réseau de télécommunication ou encore un ensemble de stations de travail reliées à une ou plusieurs imprimantes. Dans un tel réseau, les objets o qu'ils soient sur le réseau four- nissent des services à des objets clients émettant sur le réseau des re- quêtes pour ces services. Le rôle du bus logiciel (ORB) est de délivrer les requêtes aux objets serveurs concernés et de retourner les valeurs de sortie aux objets clients. Cette opération s'effectue de manière transpa- rente pour l'objet client. Celui-ci ne sait pas o les objets résident sur le réseau, comment ils sont réalisés, comment ils sont mémorisés, ni com- ment ils sont exécutés. L'objet client n'a besoin pour adresser une requête que de la référence de l'objet. Conformément à la spécification CORBA, chaque objet distribué comporte une interface de communication rédigée en IDL (Interface Defi- nition Language). Cette interface IDL permet de définir de manière stati- que les interfaces des objets permettant le portage d'objets entre diffé- rents modèles d'objets. Après compilation de l'interface IDL, le talon ou souche obtenu est lié à la réalisation de l'objet. Ainsi, l'objet client peut interagir avec un objet serveur éloigné sim- plement en invoquant les fonctions IDL comme un objet local sans se préoccuper de la situation de l'objet serveur sur le réseau. A cet effet, l'objet client peut utiliser pour adresser sa requête le format de l'interface de communication de l'objet serveur. Dans de tels réseaux, un grand nombre de données sont transmi- ses directement de manière synchrone d'un objet émetteur vers un objet récepteur, tous deux reliés au même bus logiciel. Toutefois, de nombreuses données transitent par des serveurs de notifications. Ces serveurs de notifications reçoivent des notifications d'objets émetteurs enregistrés comme tels auprès du service de notifica- tions. Des objets récepteurs, inscrits en tant qu'objets récepteurs et ayant indiqué un ou plusieurs critères de tests prédéterminés afin d'effectuer un filtrage des notifications qui leur sont adressées à partir des données qu'elles contiennent, reçoivent du service de notifications les notifications qui satisfont aux critères de tests prédéterminés. Les méthodes de filtrage sont particulièrement utiles afin de réduire la quantité de données transmises sur le réseau et afin d'adapter le ser- vice de notifications aux besoins de chaque objet récepteur. Ces filtres peuvent être déclarés de manière dynamique et modi- fiés. Les données transmises par les objets émetteurs sous forme de notifications sont structurées suivant des champs ou attributs contenant des valeurs spécifiques à chaque objet émetteur et concernant celui-ci. Le filtrage consiste à l'identification de certains champs dans la structure de données et à la mise en oeuvre d'une comparaison sur les valeurs de ces champs selon la description du filtre. Seules les notifications dont les valeurs extraites satisfont aux cri- tères de tests prédéterminés sont transmises à l'objet récepteur. Dans de tels types de réseau, les méthodes de filtrage mises en oeuvre utilisent des tests de structure simple ne permettant pas un filtrage efficace. En particulier, ces filtres n'assurent pas un filtrage efficient et ne mettent pas en oeuvre des critères de test suffisamment élaborés. Aussi, ils ne sont pas aptes à limiter réellement le trafic vers les objets récep- teurs afin que ceux-ci recçoivent uniquement les données leur étant né- cessaires. Dans ces conditions, le réseau véhicule un nombre important de données présentant peu d'intérêt, augmentant inutilement le trafic du ré- seau. L'invention a pour but d'apporter une solution à ce problème et en particulier de proposer un procédé de transmission et un réseau mettant en oeuvre un tel procédé dans lequel un filtrage efficace réduit effective- ment le nombre de communications tout en permettant de satisfaire les impératifs de fonctionnement du réseau. A cet effet, l'invention a pour objet un procédé de transmission d'une notification dans un réseau de traitement d'informations à applica- tions distribuées depuis un émetteur vers au moins un récepteur par l'in- termédiaire d'un service de notifications auprès duquel est inscrit le ou chaque récepteur afin de recevoir des notifications satisfaisant à un cri- tère de test prédéterminé, dans lequel: - l'émetteur adresse au service de notifications une notification comportant un ensemble d'au moins deux valeurs concernant ledit émet- teur; - le service de notifications vérifie, pour chaque récepteur inscrit, si ledit ensemble de valeurs satisfait audit critère de test prédéterminé as- socié audit récepteur; et - le service de notifications adresse ladite notification concernant ledit émetteur audit récepteur si le critère de test prédéterminé est satis- fait; caractérisé en ce que ledit critère de test prédéterminé comporte une comparaison entre elles des au moins deux valeurs concernant ledit objet émetteur. Suivant des modes particuliers de mise en oeuvre, le procédé peut comporter l'une ou plusieurs des caractéristiques suivantes: - le réseau comporte plusieurs émetteurs, chaque émetteur adresse aux autres émetteurs au moins une valeur particulière représen- tative d'une information le concernant, ledit ensemble de valeurs de la notification adressée par ledit émetteur au service de notifications com- porte une valeur qui est fonction d'au moins une desdites valeurs particu- lières reçues par ledit émetteur, et ladite comparaison est effectuée entre ladite valeur qui est fonction d'au moins une desdites valeurs particulières et une valeur concernant ledit émetteur; - le ou chaque émetteur est destiné au suivi du fonctionnement d'une ressource, et les valeurs sur lesquelles porte la comparaison sont des informations représentatives de l'état de fonctionnement de ladite ressource associée; et - ledit critère de test prédéterminé est défini par ledit récepteur lors de son inscription auprès du service de notifications. L'invention a en outre pour objet un réseau de traitement d'infor- mations à applications distribuées comportant au moins un émetteur, au moins un récepteur, et un service de notifications auprès duquel est inscrit le ou chaque récepteur afin de recevoir des notifications satisfaisant à un critère de test prédéterminé, dans lequel: - le ou chaque émetteur comporte des moyens pour adresser au service de notifications une notification comportant un ensemble d'au moins deux valeurs concernant ledit émetteur; - le service de notifications comporte des moyens pour vérifier, pour chaque récepteur inscrit, si ledit ensemble de valeurs satisfait audit critère de test prédéterminé associé audit récepteur; et - le service de notifications comporte des moyens pour adresser ladite notification concernant ledit émetteur audit récepteur si le critère de test prédéterminé est satisfait; caractérisé en ce que ledit critère de test prédéterminé comporte une comparaison entre elles des au moins deux valeurs concernant ledit émetteur. Suivant des modes particuliers de réalisation, le réseau peut com- porter l'une ou plusieurs des caractéristiques suivantes: - il comporte plusieurs émetteurs, chaque émetteur comporte des moyens pour adresser aux autres émetteurs au moins une valeur particu- lière représentative d'une information le concernant, ledit ensemble de valeurs de la notification adressée par ledit émetteur au service de notifi- cations comporte une valeur qui est fonction d'au moins une desdites va- leurs particulières reçues par ledit émetteur, et ledit critère de test prédé- terminé comporte la comparaison entre ladite valeur qui est fonction d'au moins une desdites valeurs particulières et une valeur concernant ledit émetteur; - le ou chaque émetteur est adapté pour le suivi du fonctionnement d'une ressource, et les valeurs sur lesquelles porte la comparaison sont des informations représentatives de l'état de fonctionnement de ladite ressource associée; - ledit récepteur comporte des moyens de définition dudit critère de test prédéterminé lors de son inscription auprès du service de notifica- tions; et - au moins l'un des émetteurs et récepteurs est un objet. L'invention a également pour objet une unité de communication d'un réseau de traitement d'informations à applications distribuées, lequel réseau comporte au moins un émetteur et au moins un récepteur, I'unité de communication comportant un service de notifications auprès duquel est inscrit le ou chaque récepteur afin de recevoir des notifications satis- faisant à un critère de test prédéterminé, le ou chaque émetteur compor- tant des moyens pour adresser au service de notifications une notifica- tion comportant un ensemble d'au moins deux valeurs concernant ledit émetteur, le service de notifications comportant des moyens pour vérifier, pour chaque récepteur inscrit, si ledit ensemble de valeurs satisfait audit critère de test prédéterminé associé audit récepteur, et le service de no- tifications comportant des moyens pour adresser ladite notification con- cernant ledit émetteur audit récepteur si le critère de test prédéterminé est satisfait, caractérisée en ce que ledit critère de test prédéterminé com- porte une comparaison entre elles des au moins deux valeurs concernant ledit émetteur. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant à l'unique figure qui est une vue schématique d'un réseau d'objets distri- bués selon l'invention mettant en oeuvre un service de notifications. Dans la description qui suit, on suppose que chaque objet est conforme à la spécification CORBA et qu'en conséquence, les objets peuvent communiquer entre eux simplement en s'adressant des requêtes indépendamment de leur situation sur le réseau. Sur l'unique figure sont représentés cinq objets émetteurs désignés par les références 10A, 10B, 10C, 10D et 10E. Chacun de ces objets est affecté à la surveillance du fonctionnement d'une unité de traitement d'informations distincte, par exemple un autocommutateur d'un réseau de télécommunication. Les objets sont adaptés pour évaluer l'état de fonc- tionnement de tout type de composant du réseau qu'il s'agisse d'une res- source logiciel ou matériel. Ces objets sont répartis sur le réseau et sont reliés par un bus logiciel 11. Un service de notifications, portant la référence 12, est relié au bus logiciel et assure la communication asynchrone des informations entre les objets du réseau. Des objets récepteurs, désignés par les références 14A, 14B, sont reliés au bus logiciel 11. Ces objets sont par exemple affectés à des ser- vices de suivi du fonctionnement du réseau de télécommunication et sont notamment destinés à la détection de pannes sur le réseau et à l'informa- tion d'un opérateur en vue d'une intervention. Le service de notifications 12 est formé d'un ensemble d'objets re- liés sur le bus logiciel 11. En particulier, il comporte un administrateur de serveur de notifications 16 et un canal de notifications 18 destiné à l'envoi de notifications reçues depuis l'un des objets émetteurs vers l'un ou plu- sieurs des objets récepteurs, lorsque les données de la notification reçue satisfont à un critère de test prédéterminé formulé par l'objet récepteur lors de son inscription au service de notifications. Chacun des objets émetteurs 10 A à 10E est enregistré auprès de l'administrateur de serveur de notifications 16 par l'intermédiaire d'une interface IDL d'enregistrement 20. Cet enregistrement s'effectue par l'en- voi d'une requête depuis l'objet émetteur vers l'interface 20. Une telle re- quête est schématisée pour l'objet 10A par la flèche 21. Chaque objet émetteur 10A à 10E reçoit, lors de son enregistrement, la référence et éventuellement le format de l'interface de communication IDL 22 du canal de notifications 18. Cette référence lui permet alors de transmettre vers le service de notifications 12 des notifications comportant des valeurs le concernant. Ces notifications forment des alarmes et sont représentatives de l'état de fonctionnement de l'unité de traitement d'informations à laquelle est associé l'objet émetteur. La structure d'une alarme, écrite en IDL, est par exemple de la forme: struc{ string name; short severity; short highestseverity; string alarm_reason; }; o: "name" est le nom de l'objet émetteur, "severity" est le niveau, évalué sur une échelle de I à 5, de la gravité de la panne rencontrée sur l'unité de traitement d'informations associée à I'objet émetteur correspondant, "highestseverity" est le niveau de gravité le plus élevé rencontré parmi l'ensemble des objets émetteurs 1 OA à 10E, et "alarm reason" est un identificateur de la panne. L'objet émetteur affecte une valeur à chacun des champs en fonc- tion de l'état de fonctionnement de l'unité associée. Afin d'affecter une valeur au champ "highestseverity", les objets A à 10E sont adaptés pour communiquer entre eux afin que, lorsque l'un des objets envoie une alarme traduisant une panne d'un niveau dé- terminé sur l'unité de traitement d'informations associée, l'ensemble des autres objets est destinataire de cette alarme par l'intermédiaire de leur interface IDL. Par ailleurs, les objets récepteurs 14A, 14B sont inscrits auprès du service de notifications 12 afin de recevoir les notifications les intéres- sant. A cet effet, chaque objet récepteur 14A, 14B est inscrit auprès d'une interface IDL d'inscription 24 de l'administrateur de serveur de notifica- tions 16. Cette interface est adaptée pour l'inscription des objets reliés au bus logiciel afin que ceux-ci reçoivent les notifications issues du service de notifications pour lesquelles ils sont inscrits. L'inscription se fait notamment en fournissant à l'administrateur de serveur de notifications 16 la référence de l'objet récepteur inscrit. Le canal de notifications 18, formant un objet CORBA, est com- mandé par l'administrateur de serveur de notifications 16. En particulier, l'administrateur de serveur de notifications 16 assure l'inscription des ob- jets récepteurs auprès du canal de notifications 18 en fournissant à celui- ci leur référence. Lors de son inscription auprès du service de notifications, chaque récepteur définit également un filtre assurant la sélection des notifications devant lui être envoyées en fonction de la validation d'un critère de test prédéterminé contenu dans le filtre. En fonction du filtre défini par chaque objet récepteur, l'admnistra- teur de serveur de notifications 16 commande la configuration du canal de notifications 18 pour la mise en ceuvre de filtres 28A, 28B propres, res- pectivement, aux objets récepteurs 14A et 14B. Le canal de notifications 18 connaît ainsi, pour chaque objet récepteur 14A, 14B, la référence de l'objet et le critère de test propre à cet objet. Selon l'invention, le critère de test prédéterminé consiste en la comparaison de deux valeurs issues d'un même objet émetteur et repré- sentative d'informations le concernant. Par exemple, le filtrage s'effectue par la comparaison des niveaux des champs "severity" et "highestseverity" afin que seules les alarmes ayant le niveau le plus élevé de l'ensemble des alarmes présentes sur le réseau soient transmises aux objets récepteurs ayant imposé un tel fil- trage. A cet effet, la structure du filtre rédigée en IDL suivant la spécifica- tion CORBA est de la forme suivante: typedef string Attributeld; struct AttributeValueType { Attributeld attributeld any attributeValue }; struct TwoAttributesType { Attributeld attributeldl Attributeld attributeld2 enum TestType {AttributeWithValue, AttributeWithOtherAttribute} union AttributeType switch (TestType) { case AttributeWithValue: AttributeValueType single case AttributeWithOtherAttribute: TwoAttributesType multi }; enum FilterltemType { equalityChoice, greaterOrEqualChoice, lessOrEqualChoice, union Filterltem switch (FilterltemType) { case equalityChoice AttributeType equality case greaterOrEqualChoice: AttributeType greaterOrEqual; case lessOrEqualChoice Attribute Type lessOrEqual }; dans lequel: - "Attributeld" est l'indentificateur d'un attribut, - "Filterltem" est un test de base qui, par association avec d'autres tests de base, grâce à des opérateurs logiques tels que ET, OU, NON, permet l'écriture de tests complexes. "Filterltem" est déterminé par "FilterltemType" qui donne le type de test, dans le cas présent, parmi les tests suivants: égalité (equality), supérieur ou égal (greater-OrEqual), inférieur ou égal (lessOrEqual). Les arguments pour le test sont stockés dans "AttributeType". Selon l'invention, deux structures différentes sont envisagées pour les arguments du test. Il s'agit d'une part, de "AttributeValueType" qui cor- respond au test effectué par comparaison entre une valeur d'un champ de la structure de données et une valeur de référence prédéterminée, et d'autre part de 'TwoAttributesType" qui correspond au test effectué par comparaison entre deux valeurs de champs de la même structure de don- nées et relative à un même objet émetteur. Pour la rédaction du filtre, ces deux structures différentes sont dé- signées plus explicitement, respectivement par: "AttributeWithValue" et "AttributeWithOtherAttribute". Avec une telle structure de filtre, le filtrage des notifications suivant le critère de test selon lequel le niveau de gravité de la panne de l'unité de traitement d'informations ("severity") est supérieur ou égal au niveau le plus élevé rencontré sur le réseau ("highestseverity") s'écrit sous la forme: greaterOrEqual(AttributeType(AttributeWithOhterAttribute){severi- ty, highestseverity}) On comprend qu'avec un tel système de filtrage, la possibilité de sélection des notifications devant être envoyées aux objets récepteurs est accrue. En particulier, les critères de filtrage peuvent évoluer en fonction du temps et de l'état du réseau. Au contraire, avec les filtres actuels mettant en oeuvre uniquement une comparaison d'une valeur d'attribut à une valeur de référence, de telles évolutions des critères de filtrage sont impossibles. Bien que la description qui est faite ici mette en oeuvre des objets émetteurs et récepteurs, ceux-ci peuvent être des composants logiciels conventionnels et notamment des programmes procéduraux classiques. REVENDICATIONS 1.- Procédé de transmission d'une notification dans un réseau de traitement d'informations à applications distribuées depuis un émetteur (10A, 10B, 10C, 10D, 10E) vers au moins un récepteur (14A, 14B) par I'intermédiaire d'un service de notifications (12) auprès duquel est inscrit le ou chaque récepteur (14A, 14B) afin de recevoir des notifications sa- tisfaisant à un critère de test prédéterminé, dans lequel: - l'émetteur (10A,10B, 10C,10D, 10 E) adresse au service de noti- fications (12) une notification comportant un ensemble d'au moins deux valeurs concernant ledit émetteur; - le service de notifications (12) vérifie, pour chaque récepteur (14A, 14B) inscrit, si ledit ensemble de valeurs satisfait audit critère de test prédéterminé associé audit récepteur (14A, 14B); et - le service de notifications (12) adresse ladite notification concer- nant ledit émetteur (10A, 10B, 10C, 10D, 10E) audit récepteur (14A, 14B) si le critère de test prédéterminé est satisfait; caractérisé en ce que ledit critère de test prédéterminé comporte une comparaison entre elles des au moins deux valeurs concernant ledit objet émetteur (1 OA,1 OB,10 C,10 OD,10 E). 2.- Procédé selon la revendication 1, caractérisé en ce que le ré- seau comporte plusieurs émetteurs (10A, 10B, 10C, 10D, 10E), en ce que chaque émetteur (10OA, 10B, 10C, 10OD, 10E) adresse aux autres émetteurs (10A, 10B, 10C, 10D, 10E) au moins une valeur particulière représentative d'une information le concernant, en ce que ledit ensemble de valeurs de la notification adressée par ledit émetteur (10A, 10B, 10C, D, 10E) au service de notifications (12) comporte une valeur qui est fonction d'au moins une desdites valeurs particulières reçues par ledit émetteur (10OA, 10B,1, 10C, 10D, 10E), et en ce que ladite comparaison est effectuée entre ladite valeur qui est fonction d'au moins une desdites va- leurs particulières et une valeur concernant ledit émetteur (10A, 10B, C, 10D, 10E). 3.- Procédé selon la revendication I ou 2, caractérisé en ce que le ou chaque émetteur (10A, 10B, 10C, 10D, 10E) est destiné au suivi du fonctionnement d'une ressource, et en ce que les valeurs sur lesquelles porte la comparaison sont des informations représentatives de l'état de fonctionnement de ladite ressource associée. 4.- Procédé selon l'une quelconque des revendications précéden- tes, caractérisé en ce que ledit critère de test prédéterminé est défini par ledit récepteur (14A, 14B) lors de son inscription auprès du service de notifications (12). 5.- Réseau de traitement d'informations à applications distribuées comportant au moins un émetteur (10A, 10B, 10C, 10D, 10E), au moins un récepteur (14A, 14B), et un service de notifications (12) auprès duquel est inscrit le ou chaque récepteur (14A, 14B) afin de recevoir des notifica- tions satisfaisant à un critère de test prédéterminé, dans lequel: - le ou chaque émetteur (10A, 10B, 10C, 10D, 10E) comporte des moyens pour adresser au service de notifications (12) une notification comportant un ensemble d'au moins deux valeurs concernant ledit émet- teur; - le service de notifications (12) comporte des moyens pour vérifier, pour chaque récepteur (14A, 14B) inscrit, si ledit ensemble de valeurs satisfait audit critère de test prédéterminé associé audit récepteur (14A, 14B); et - le service de notifications (12) comporte des moyens pour adres- ser ladite notification concernant ledit émetteur (10A, O10B, 10C, 10D, E) audit récepteur (14A, 14B) si le critère de test prédéterminé est sa- tisfait; caractérisé en ce que ledit critère de test prédéterminé comporte une comparaison entre elles des au moins deux valeurs concemrnant ledit émetteur (10OA, 10OB, 10OC, 10D, 10E). 6.- Réseau selon la revendication 5, caractérisé en ce qu'il com- porte plusieurs émetteurs (10A, 10B, 10C, 10D, 10E), en ce que chaque émetteur (10A, 10OB, 10OC, 10OD, 10E) comporte des moyens pour adresser aux autres émetteurs (10A, 10B, 10C, 10D, 10E) au moins une valeur particulière représentative d'une information le concemrnant, en ce que le- dit ensemble de valeurs de la notification adressée par ledit émetteur (10A, 10B, 10OC, 10D, 10E) au service de notifications (12) comporte une valeur qui est fonction d'au moins une desdites valeurs particulières re- çues par ledit émetteur (10A, 10OB, 10OC, 10D, 10E), et en ce que ledit cri- tère de test prédéterminé comporte la comparaison entre ladite valeur qui est fonction d'au moins une desdites valeurs particulières et une valeur concernant ledit émetteur (1 OA, 1 OB, 1 OC, 1 OD, 10 OE). 7.- Réseau selon la revendication 5 ou 6, caractérisé en ce que le ou chaque émetteur (10A, 10OB, 10OC, 10D, 10E) est adapté pour le suivi du fonctionnement d'une ressource, et en ce que les valeurs sur lesquel- les porte la comparaison sont des informations représentatives de l'état de fonctionnement de ladite ressource associée. 8.- Réseau selon l'une quelconque des revendications 5 à 7, ca- ractérisé en ce que ledit récepteur (14A, 14B) comporte des moyens de définition dudit critère de test prédéterminé lors de son inscription auprès du service de notifications (12). 9.- Réseau selon l'une quelconque des revendications 5 à 8, ca- ractérisé en ce qu'au moins l'un des émetteurs (10OA, 10B, 10OC, 10D, 10E) et récepteurs (14A, 14B) est un objet. 10.- Unité de communication d'un réseau de traitement d'informa- tions à applications distribuées, lequel réseau comporte au moins un émetteur (10OA, 10OB, 10OC, 10OD, 10E) et au moins un récepteur (14A, 14B), l'unité de communication comportant un service de notifications (12) au- près duquel est inscrit le ou chaque récepteur (14A, 14B) afin de recevoir des notifications satisfaisant à un critère de test prédéterminé, le ou cha- que émetteur (1 OA, 1 OB, 1 OC, 1 OD, 10 OE) comportant des moyens pour adresser au service de notifications (12) une notification comportant un ensemble d'au moins deux valeurs concernant ledit émetteur, le service de notifications (12) comportant des moyens pour vérifier, pour chaque récepteur (14A, 14B) inscrit, si ledit ensemble de valeurs satisfait audit critère de test prédéterminé associé audit récepteur (14A, 14B), et le ser- vice de notifications (12) comportant des moyens pour adresser ladite notification concernant ledit émetteur (10A, 10B, 10C, 10D, 10E) audit récepteur (14A, 14B) si le critère de test prédéterminé est satisfait; caractérisée en ce que ledit critère de test prédéterminé comporte une comparaison entre elles des au moins deux valeurs concernant ledit émetteur (1 OA, 1 OB, 1 OC, 1 OD, 10 OE).