FR 3067838 A1 20181221 FR 1755401 A 20170615 SYSTÈME ET PROCÉDÉ DE TRAITEMENT DE MESSAGERIE DES BAGAGES DOMAINE TECHNIQUE Les modes de réalisation concernent des systèmes et des procédés de traitement de messagerie concernant des bagages, en particulier de systèmes et des procédés servant d'interface avec des systèmes externes sans qu'il soit nécessaire de modifier ces systèmes externes. CONTEXTE L'industrie aéronautique a connu une croissance considérable au cours des dernières décennies. Avec la croissance du nombre de passagers, le nombre des bagages qui doivent être transportés a aussi considérablement augmenté. La perte d'un bagage est coûteuse, aussi bien en efforts déployés pour retrouver le bagage perdu, mais aussi en matière de dommages à la réputation. Il existe donc un besoin de système fiable pour tracer un bagage. RÉSUMÉ Les modes de réalisation concernent un point d'accès pour un système de traitement de message d'un bagage. Le système comprend une interface entrée/sortie adaptée pour être connectée à un système externe, un convertisseur configuré pour convertir un message reçu via l'interface entrée/sortie et/ou un message devant être transmis via l'interface entrée/sortie dans un format prédéterminé, un extracteur configuré pour extraire des métadonnées à partir d'un message converti et une unité de transmission et/ou de réception configurée pour transmettre et/ou recevoir un autre message comprenant les métadonnées extraites et l'information associée relative à l'adresse. L'adaptateur peut être configuré pour accéder à une base de données stockant un ou plusieurs protocoles de communication et pour convertir le format d'un message sur la base desdits protocoles stockés. L'adaptateur est configuré pour lier une métadonnée reçue via l'unité de transmission/réception à un message qui doit être envoyé via l'interface entrée/sortie conformément à un protocole de communication stocké. L'extracteur peut-être un analyseur qui émet et absorbe des événements au fur et à mesure qu'une arborescence d'analyse est traversée. 2 Le point d'accès peut être par ailleurs configuré pour créer un message devant être envoyé via l'unité de transmission/réception en combinant la métadonnée extraite avec un ID de transaction unique. Les modes de réalisation de l'invention concernent aussi un système de 5 traitement de message d'un bagage comprenant une pluralité de points d'accès et un ou plusieurs routeurs configurés pour router un message reçu via une unité de transmission/réception d'un point d'accès sur la base au moins en partie du contenu de la métadonnée qui forme une partie du message. Le routeur peut accéder à des règles de routage et router le message sur la 10 base des règles de routage. Les règles de routage peuvent lier des éléments d'information inclus dans la métadonnée pour obtenir un niveau plus fin de granularité de routage qu'il ne serait autrement possible sur la base des seuls éléments de métadonnée. Les règles peuvent, en particulier, lier des éléments de métadonnée d'une manière qui est spécifique à la destination, telle qu'un aéroport de destination, 15 pour permettre le routage du message vers un sous-système ou lieu de la destination. Chaque routeur peut être configuré pour router des messages conformément à des règles de routage, le routeur étant configuré pour compiler de façon dynamique lesdites règles de routage au moment de leur utilisation ou immédiatement avant. Des modes de réalisation de l'invention concernent également le système de 20 traitement de message d'un bagage qui comprend une pluralité de points d'accès décrits ci-dessus et un stockage distribué pour stocker les messages reçus par l'interface entrée/sortie d'un point d'accès ainsi que l'information indiquant l'état de routage des messages associés transmis par l'unité de transmission/réception du point d'accès. 25 L'information peut comprendre un recoupement complet historique de routage du message associé. Chaque routeur est configuré, au redémarrage, pour accéder au stockage distribué et router des messages pour lesquels les états associés de routage indiquent que le routage est incomplet. 30 Le stockage distribué peut être accessible à une pluralité de routeurs. Un système de traitement de message d'un bagage peut être configuré pour associer un point d'accès avec chaque client logique avec qui la communication doit être établie. 3 Le système de traitement de message d'un bagage peut être configuré pour localiser des articles individuels de bagage en traçant les messages qui comprennent une métadonnée identifiant l'article et provenant des points d'accès dont la localisation est connue. 5 Des modes de réalisation de l'invention concernent aussi un procédé de communication d'un message entre un système de traitement de message d'un bagage et un système extérieur au système de traitement de bagage d'un message. Le procédé comprend la réception d'un message provenant du système externe via une interface entrée/sortie, la conversion du message reçu dans un format 10 prédéterminé, l'extraction d'une métadonnée du message converti et la transmission au système de traitement de message de bagage d'un message comprenant la métadonnée extraite et l'information associée relative à l'adresse. Des modes de réalisation de l'invention concernent aussi des instructions exécutables d'un produit-programme d'ordinateur qui, lorsqu'elles sont exécutées par 15 un processeur, conduisent un point d'accès pour un système de traitement de message de bagage à accepter, via une interface entrée/sortie, un message provenant d'un système externe, à convertir le message reçu dans un format prédéterminé et à extraire la métadonnée du message converti et à transmettre un message comprenant la métadonnée extraite et l'information associée relative à l'adresse au système de 20 message de traitement de bagage. BRÈVE DESCRIPTION DES DESSINS Les modes de réalisation de l'invention présente seront mieux compris et seront appréciés plus pleinement grâce à la lecture de la description détaillée ci-après qui complète les dessins. 25 Figure 1 montre un système de distribution de messages relatifs à des bagages selon un mode de réalisation ; Figure 2 montre une vue de haut niveau de l'architecture d'un mode de réalisation du système de distribution de messages de bagage ; Figure 3 apporte une vue d'ensemble de l'architecture de noeuds individuels 30 selon un mode de réalisation ; Figure 4 fournit une vue plus détaillée de l'architecture d'un noeud individuel selon un mode de réalisation ; 4 Figure 5 montre l'architecture d'un service de passerelles selon un mode de réalisation ; Figure 6 montre le flux de données dans un routeur ; Figure 7 illustre un exemple de flux de messages dans le système BMD ; et 5 Figure 8 montre les détails relatifs aux façons de stocker les données dans le journal de transactions. DESCRIPTION DÉTAILLÉE Figure 1 montre un système de distribution de messages de bagage (BMD) 100 conforme à un mode de réalisation. Le système de distribution de messages de 10 bagage 100 facilite une communication efficace entre une variété de systèmes impliqués avec les messages relatifs à un bagage. Ces systèmes incluent, sans restriction, les systèmes de contrôle de départ 110 à 130, les systèmes de tri de bagages 140 à 160 et les systèmes de rapprochement des bagages 170 à 190. Les systèmes de contrôle de départ 110 à 130 peuvent être gérés par diverses 15 compagnies aériennes dans un aéroport particulier ou dans plusieurs aéroports ou par une compagnie aérienne particulière dans un certain nombre d'aéroports. Les divers systèmes de tri de bagages 140 à 160 et les systèmes de rapprochement relatifs aux bagages 170 à 190 peuvent fonctionner dans des aéroports différents. On remarquera que les aéroports mentionnés ci-dessus ne sont pas nécessairement tous situés dans 20 un pays, et encore moins dans un pays en particulier. On remarquera qu'en raison de la popularité croissante du trafic aérien le nombre d'articles de bagages qui sont transportés chaque jour est très important et augmente de façon constante. La quantité de données relatives au transport des bagages qui est générée de façon constante est donc très importante. Ce seul fait rend 25 la gestion et la distribution des messages complexes relatifs aux bagages. En outre, les systèmes de gestion de données des compagnies aériennes et des aéroports utilisent invariablement des procédés et des conventions de traitement différentes. Par conséquent, l'échange des messages entre ces systèmes a tendance à être impossible, sans même parler dans un mode très fiable, face à des volumes 30 élevés de messages. Figure 2 illustre à haut niveau l'architecture d'un mode de réalisation du système de distribution de messages de bagages 100. Le système 100 comprend une pluralité de noeuds 210 qui forment un groupement 250 englobant la région 5 géographique couverte par le système BMD 100. Dans un mode de réalisation, chaque noeud héberge un ensemble de services dans le système. Chaque composant dans le système est considéré comme un service, et le terme « service » se rapporte simplement à une unité (regroupée) de temps d'exécution qui peut être installée et 5 fonctionner sur n'importe quel noeud dans le groupement 250. Les noeuds 210 sont connectés par un système de messagerie 260 pour permettre aux services de communiquer les uns avec les autres entre les noeuds. Dans un mode de réalisation, le système de messagerie utilisé est Active MQ. Dans un mode de réalisation, les noeuds 210 forment un réseau d'intermédiaires, permettant à 10 chaque noeud 210 dans le réseau d'être implicitement visible de tout autre noeud 210 dans le réseau. Un journal de transactions 270 comprend un ensemble de tableaux qui sont utilisés pour tracer et enregistrer le flux de messages et l'état des transactions dans l'ensemble du système. Chaque message d'un noeud 210 est mis à disponibilité à au moins un autre noeud 210 de sorte que l'échec d'un noeud ne conduise pas à la 15 perte d'un quelconque message. Puisque le système BMD 100 est un système distribué couvrant un nombre quelconque de noeuds, un service de coordination partagé 280 est fourni pour coordonner les noeuds 210. Ce service 280 apportera un contexte, englobant le groupement, pour chaque noeud 210 pour permettre de faire connaître les services 20 hébergés par un noeud 210 ainsi que pour annoncer la capacité ou l'incapacité d'un noeud 210 à participer au traitement des activités. Le service de coordination 280 est configuré pour faciliter l'élection d'un chef de file parmi les noeuds 210 dans le groupement 250, pour fournir un registre de tous les services offerts par les noeuds 210 dans le groupement 250, pour surveiller l'état des noeuds 210 et les 25 services qu'ils fournissent et pour équilibrer les charges de travail au sein du groupement 250. Dans un mode de réalisation, le service de coordination 280 est fourni par des machines différentes de celles qui fournissent les noeuds BMD 210. Les services de coordination en eux-mêmes peuvent être groupés pour assurer une haute disponibilité et tolérance face à un échec du service de coordination 280. 30 Chaque composant individuel dans les noeuds 210 est déployé un nombre fois qui est configurable sur un nombre configurable de noeuds dans l'ensemble du groupement 250 sans entraîner une quelconque dépendance forte envers son site d'hébergement. Cela permet à de nouveaux noeuds d'être ajoutés pendant le temps d'exécution et d'être approvisionnés de façon dynamique. Le déploiement dynamique de ces composants individuels permet le rééquilibrage des ressources informatiques 6 dans l'ensemble du groupement lors d'une défaillance sur la base de l'addition ou de la soustraction des noeuds actifs. Figure 3 apporte une vue d'ensemble de l'architecture de noeuds individuels 210, selon un mode de réalisation, ainsi que la manière par laquelle les 5 noeuds 210 communiquent via une connexion aux éléments environnants. Un noeud 210 comprend un serveur d'application dans lequel un ensemble de services BMD essentiels 300 sont déployés. Toutes les communications avec des systèmes externes 310 sont traitées par des passerelles de service 320 responsables de l'adaptation des protocoles, des sessions de maintenance et tout autre comportement 10 spécifique à un domaine. Les systèmes externes incluent, sans restriction, les systèmes de contrôle de départ 110 à 130, les systèmes de tri de bagages 140 à 160 et les systèmes de rapprochement des bagages 170 à 190 qui sont illustrés dans la Figure 1. Une fois que le message a été reçu et traité de façon appropriée par une 15 passerelle de service 320, il est remis aux services essentiels BMD 300 pour un routage et une livraison adéquate. Les services essentiels 300 calculent la voie de livraison du message sur la base d'un ensemble de règles de routage enfichables stockées dans la base de connaissances 330. Dans le mode de réalisation, ces règles sont des scripts compilés de façon dynamique et peuvent par conséquent être 20 modifiées durant l'exécution du système pour ajuster les modes de routage sans subir d'interruption. Une fois que les voies de routage adéquates sont déterminées, le service de coordination 280 détermine les adresses de service dans le groupement pour les services de passerelle prévus des systèmes destinataires 320. Alors que, dans un mode de réalisation, une copie de la base de 25 connaissances 330 est présente dans chaque noeud, dans un autre mode de réalisation, la base de connaissances peut être stockée sous une forme qui peut être accessible par chaque service dans le groupement selon le besoin. De ce fait, uniquement une seule copie de la base de connaissances a besoin d'être stockée, permettant ainsi de réaliser des économies d'espace de stockage. À des fins de 30 répétition, un nombre de copies est avantageusement conservé. Dans un mode de réalisation, la copie ou les copies de la base de données de connaissances sont distribuées dans l'ensemble du groupement. Les règles stockées dans la base de connaissances peuvent être actualisées pendant l'exécution. La base de connaissances est configurée pour transmettre des notifications pour toutes les mises 35 à jour de règles aux routeurs dans le groupement de sorte que les routeurs opèrent en utilisant les règles les plus actualisées dans l'ensemble de règles disponible. 7 Tous les services, y compris le service de coordination 280 sont configurés pour s'inscrire eux-mêmes avec un service de registre afin d'annoncer leur présence et disponibilité dans le système 100. Les services peuvent par conséquent être adressés individuellement à un quelconque noeud dans l'ensemble du groupement. Dans un 5 mode de réalisation, le routeur 300 est responsable de la résolution des adresses internes de service utilisées au cours de la livraison des messages. Les services sont aussi configurés pour se reconfigurer eux-mêmes à la demande lors de l'exécution à la requête du service de coordination afin de permettre l'équilibrage des charges, etc. le registre de service est conservé dans le cadre du 10 service de coordination 280. Comme mentionné ci-dessus, dans un mode de réalisation, le service de coordination 280 forme un second groupement hautement disponible avec un trois noeuds au minimum, distinct de l'ensemble de noeuds BMD. Une entrée dans le registre ne demeure que pendant que le service est actif et opérationnel et expire à tout moment dès lors que le service est à l'arrêt ou qu'il y a 15 une défaillance. Vu que le service de coordination 280 est exploité dans un groupement séparé, la possibilité d'une défaillance simultanée avec un noeud 210 exécutant un service qui échoue est très faible. Chaque noeud 210 conserve une connexion active avec le service de coordination 280, ce qui pour les modes de réalisation fonctionne sur une machine séparée. Ces connexions créent une session 20 en même temps que des objets de donnée qui sont liés à cette session. Le service de coordination 280 veille sur la session. Dans l'hypothèse où le noeud 210 se déconnecterait et que la session soit perdue, le service de coordination 280 peut redistribuer des actions associées aux sessions qui ont échoué vers d'autres noeuds. Les services hors ligne peuvent être rapidement détectés de cette manière permettant 25 un contrôle facile de l'état du groupement et une réaction aux événements liés au cycle de vie du service et aux échecs en mode événement. Figure 4 apporte une vue plus détaillée de l'architecture d'un noeud individuel 210. Chacun des services essentiels BMD 300 et chacune des passerelles 320 incluent leur propre file d'attente, 340 et 350 respectivement, qui sera 30 globalement disponible dans l'ensemble du groupement via le système de messagerie. Dans l'hypothèse d'un échec, des messages d'un service qui ont commencé à être routés à travers le groupement, mais n'ont pas encore été délivrés peuvent être récupérés à partir de la file d'attente qui les héberge lorsque le service a échoué et que le routage peut être relancé. Selon un mode de réalisation, le système est configuré 35 similairement pour utiliser des files d'attente d'autres services pour servir de tampons 8 lors de pointes des charges. De cette manière, le trafic de pointe peut être géré et traité sans difficulté pendant une période de temps opérationnel. Les passerelles 320 reçoivent des messages provenant de systèmes externes connectés 310 et convertissent ces messages du format reçu à un format d'échange 5 dans le BMD 100. Tous les messages ainsi reformatés sont stockés dans un journal de transactions 270. Le stockage dans le journal de transactions 270 permet de purger les files d'attente 340 et 350. Les files d'attente purgées sont préférables pour des raisons de performance. Dans l'éventualité où des messages non purgés de file d'attente seraient perdus, les files d'attente 340 et 350 sont alors remplies à nouveau sur la 10 base du journal de transactions 270. Dans un mode de réalisation, chaque noeud 210 contient un noeud-agent. Le noeud-agent est chargé de veiller au bon fonctionnement de la machine sur laquelle le noeud 210 est exécuté ainsi que sur le JVM dans lequel ce noeud 210 fonctionne. Le noeud-agent veille en particulier au niveau d'usage de l'unité centrale de traitement 15 (CPU) par le système d'exploitation du noeud et à la capacité de mémoire du JVM. L'usage du CPU et des capacités de la mémoire JVM des noeuds exécutant les mêmes services sont comparés afin d'identifier les noeuds fortement chargés et ceux qui sont moins chargés. Une vaste connaissance des noeuds moins chargés est obtenue sur la base de ce groupement. Le noeud-agent est configuré de sorte que, 20 durant les fortes pointes de trafic, les messages sont automatiquement routés vers le noeud le plus approprié dans le groupement, à n'importe quel moment donné, afin d'assurer une distribution de charge optimale. Figure 5 montre l'architecture d'un service de passerelles 320 selon un mode de réalisation. Une passerelle 320 enrobe tous les transports, protocoles et 25 sémantiques de session requis pour la communication avec un système externe. Les services de passerelle 320 facilitent la prise en charge des systèmes externes de sorte que les systèmes externes qui doivent être connectés au système BMD 100 n'ont pas besoin d'être modifiés. L'extrémité 400 prend en charge toutes les interactions avec le système externe 310, notamment des responsabilités telles que le décodage/encodage 30 de trames TCP/IP, la génération de battements de coeur et les mécanismes d'authentification. La passerelle 320 est un point frontière efficace pour l'entrée et la sortie du BMD 100. Dans un mode de réalisation, une seule passerelle 320 par système logique externe 310 est déployée, créant un mappage biunivoque pour la passerelle 320 au client. 9 L'extrémité 400 est fournie pour permettre la communication avec le système externe 310 en utilisant des méthodes de communication telles que, mais sans limitation, les méthodes suivantes : TCP/IP, UDP, S/FTP/S, JMS, Services Web (SOAP/REST), etc. L'extrémité 400 repose sur des protocoles préexistants pour cette 5 nature, mais s'ils sont configurés pour être capables de stocker des nouveaux et/ou des protocoles actualisés adapter des protocoles de communication personnalisés qui peuvent être utilisés par certains systèmes externes 310. Dans un mode de réalisation, l'extrémité 400 est configurée pour utiliser un identifiant de ressource uniforme (URI) basé sur une chaîne pour permettre le remplacement d'une propriété dans l'ensemble 10 d'un noeud. Le fait de définir une adresse IP locale, à laquelle un service doit être lié comme propriété du service, permet au service d'être reprogrammé pour fonctionner sur un noeud de remplacement 210 en cas d'échec du noeud 210 sur lequel il fonctionnait à l'origine. La passerelle 320 inclut en outre un adaptateur de protocole 410. L'adaptateur 15 de protocole 410 est responsable de la conversion de/vers un format de donnée domaine-spécifique. L'extrémité 400 découple cette conversion du mécanisme de transport actuel utilisé. L'adaptateur de protocole 410 est configuré pour ajouter et retirer des enveloppes de protocole et de la transformation de/vers un format connu de donnée utilisé par un système externe. Si le message est reçu à la passerelle 320, cela 20 inclut de relier au message la métadonnée appropriée produite durant la propagation du message dans le BMD 100. Cette métadonnée peut par exemple être des identifiants de séquence de messages. L'opération de l'adaptateur de protocole 410 sera décrite de façon plus détaillée ci-dessous en référence à la Figure 6. La passerelle 320 inclut par ailleurs un analyseur 420 qui est configuré pour 25 analyser et valider les messages entrants. Ces messages peuvent être des messages de Bagage IATA 1745, des messages IATA de Bagage IATA XML ou tout autre type de messages échangés dans le BMD 100. L'analyse des messages de Type-B est accomplie par l'implémentation des grammaires étendues Extended Backus-Naur Form (EBNF) qui sont utilisées pour générer des analyseurs avec une structure 30 ANTLR. Les analyseurs générés 420 fournissent un mécanisme de rappel commandé par les événements qui se comporte de façon similaire à un analyseur SAX, avec émission et absorption d'événements au fur et à mesure que l'arbre d'analyse est traversé. On remarquera que d'autres technologies d'analyseur peuvent être utilisées dans des modes de réalisation différents. 35 Durant le processus d'analyse et de validation, une métadonnée est extraite de la charge de message pour une utilisation dans le routage en aval. La métadonnée 10 extraite peut inclure une ou plusieurs des informations concernant les aéroports impliqués, LPC, adresses TTY, etc. Si des irrégularités relatives au format du message sont détectées empêchant un routage correct, ces erreurs seront identifiées et signalées par l'analyseur pour un usage ultérieur d'inspection et de rapport de 5 message. L'analyseur 420 peut extraire une métadonnée, quel que soit le format d'origine du message. Optionnellement, la passerelle 320 inclut un moyen de transformation canonique 430 pour transformer la métadonnée extraite par l'analyseur 420 en un espace de nom unique et un schéma pour chaque type de donnée pouvant être routée 10 par le système. Dans un mode de réalisation, par exemple, chaque sous-type IATA 1745 (p. ex. BSM, BPM, ou BTM) a son propre espace de nom, p. ex. com.amadeus.apt.bmd.bdm. Le schéma de métadonnée est interne au système décrit dans les présentes dans un mode de réalisation et est configuré pour identifier tous les attributs et structures imbriqués représentant un type de donnée. L'espace de nom 15 com.amadeus.apt.bmd.iata peut, par exemple, inclure un schéma individuel pour BSM, BTM, BPM, etc. Celui-ci peut être basé sur la norme IATA 1745. Un identifiant complet est donc, dans un mode de réalisation, com.amadeus.apt.bmd.iata.bsm. On remarquera que le moyen de transformation canonique 430 n'a pas besoin d'opérer sur des messages reçus à la passerelle 320 pour une sortie vers le système 20 externe 310, car le message devant sortir vers le système externe 310 est réassemblé par l'adaptateur de protocole 410. Il est important de noter que bien que la passerelle 320 sera utilisée à la fois pour des flux entrant et sortant, chacun aura des problèmes de traitement distincts. Un flux sortant par exemple n'aura jamais besoin d'appliquer une logique de 25 transformation canonique ou analytique. Il est aussi possible pour une seule passerelle d'être comprise de plusieurs routes et extrémités différentes selon la demande du système client. Figure 6 montre le flux de données à l'intérieur d'un routeur 300. Le routeur peut recevoir la métadonnée extraite d'un message. Alors que la destination de 30 routage peut partiellement identifier la destination du message, les messages de gestion de bagages ont actuellement tendance à ne pas permettre d'identification sans ambiguïté concernant les lieux de destination individuels. La destination fournie peut, par exemple, être seulement l'aérodrome vers lequel le bagage sera dirigé. Cependant, il peut n'y avoir pas plus de données précises disponibles concernant la 35 destination. Le routage basé sur cette donnée de destination peut au mieux être capable de délivrer le message au lieu géographique correct. Cependant, une livraison 11 plus précise n'est plus possible. Pour permettre un routage plus précis, les routeurs sont configurés pour inspecter la métadonnée et prendre des décisions de routage sur cette base. Pour faciliter ces décisions chaque routeur stocke, ou est connecté en mode de communication avec une mémoire qui stocke dans un espace physique 5 séparé, des règles de routage basées sur le contenu et est configuré pour décider, sur la base du contenu du message tel qu'il est encodé sous forme de métadonnée et sur la base des informations reçues provenant du service de coordination, la voie de routage du message afin d'atteindre un service de destination particulier. Ce service de destination peut-être une passerelle de destination connectée un système externe 10 particulier vers lequel le message interne doit être délivré sous la forme d'un message de sac. Par exemple, les règles de routage basées sur le contenu peuvent lier divers éléments d'information inclus dans la métadonnée d'une manière qui reflète spécifiquement les exigences de traitement dans un aéroport particulier. Un message 15 peut par exemple être destiné à un aéroport particulier, dans lequel la métadonnée ne spécifie pas cependant un endroit particulier de l'aéroport, par exemple un terminal spécifique. Au moins si des terminaux différents de l'aéroport incluent une infrastructure physique ou des données distinctes, la livraison du message vers un terminal incorrect n'est pas souhaitable. Les règles de routage basées sur le contenu 20 lient les entrées de métadonnée pour parfaire le routage à un niveau plus précis de granularité qu'il ne serait possible uniquement sur la base d'un seul élément de métadonnée. Une règle de routage basée sur du contenu peut par exemple définir vers quel terminal d'un aéroport de destination un message doit être routé sur la base d'informations du transporteur concerné par le message, sur la base d'un aéroport de 25 destination finale si le message concerne l'escale d'un vol, etc. Le routage basé sur le contenu peut donc être défini comme un routage qui combine un nombre d'éléments d'information dans la métadonnée sur la base de certaines informations dans la métadonnée pour atteindre une granularité de routage plus affinée qu'il ne serait possible sur la base d'un élément d'information de la 30 métadonnée ou sur le seul élément d'information de la métadonnée sur laquelle était basée la combinaison utilisée pour le routage. Le routage basé sur le contenu peut, par exemple, être basé sur un aérodrome : par exemple la définition de routages peut être basée sur un aéroport de départ, plusieurs escales/points de transfert et sur la destination finale ; il peut être 35 basé sur une compagnie aérienne, par exemple une définition de routages peut être basée sur les contraintes spécifiques d'une compagnie aérienne, d'un transporteur vs 12 un opérateur dans les terminaux préférés, sur les vols intérieurs vs les vols internationaux basés sur une série de numéros de vols, par exemple les numéros de vols de 0001-3000 opèrent dans un terminal pour les vols intérieurs, mais les numéros 4000+ opèrent dans un terminal international ; il peut être basé sur le LPC 5 (plaque d'immatriculation de l'étiquette de bagage), par exemple sur la base du préfixe LPC d'un BSM ou sur le LPC lui-même si un routage inverse d'un BPM est effectué en retour vers le système émetteur ; il peut être basé sur le type de message, par exemple la définition de routages est basée sur un type de donnée interne d'espace de nom (représentant un BSM, enregistrement de vols, etc.) pour cibler des systèmes 10 spécifiques sur la base des types de données ou sur une quelconque combinaison de ceux-ci. On remarquera que les exemples de routage cités dans les présentes illustrent simplement certaines des nombreuses façons de combiner des éléments d'information de la métadonnée afin d'améliorer la granularité du routage. L'information reçue du service de coordination peut inclure un ou plusieurs des 15 éléments suivants : - L'information concernant les types et lieux de services à la destination (dans l'exemple de la Figure 6 l'aérodrome de destination). - L'information identifiant les systèmes dans l'aérodrome appartenant aux transporteurs concernés 20 - L'information relative au lieu de l'équipement affecté à un vol particulier à l'aérodrome de destination. Dans un mode de réalisation un ou plusieurs de chaque noeud 210 dans le système 100 maintient une réserve configurable de routeurs permettant le routage parallèle des messages provenant de chaque système connecté. 25 Dans un mode de réalisation, les routeurs 300 sont configurés pour les actualisations de règles de routage et d'adresses de service en temps réel. Le service de coordination est configuré pour diffuser l'information nécessaire pour ces mises à jour lorsqu'elles sont nécessaires et/ou disponibles. Le besoin pour les mises à jour peut survenir à la suite d'un événement, tel que l'échec d'un service ou d'un noeud 30 entier dans le système 100. De cette manière, l'ensemble du mécanisme de publication de mises à jour peut être basé sur des événements. Les règles de routage se conforment à un format qui peut être compilé de façon dynamique à l'intérieur du routeur. Que cette manière, les règles peuvent être modifiées de façon dynamique lors de l'exécution sans besoin de relancer ou de 35 remplacer des composants. 13 Figure 7 illustre un flux de messages dans le système BMD 100. Après qu'un message d'origine a été reçu, à une passerelle entrante/source 320 à l'étape 500, il est traité par l'analyseur 420 faisant partie de la passerelle 320, à l'étape 510. La charge brute du message est stockée dans le journal de transactions 270 à l'étape 520 5 et le message interne analysé est envoyé au routeur pour transmission vers sa destination à l'étape 530. Chaque message contient un identifiant de transaction unique ainsi que la métadonnée concernant la charge message. Puisque l'identifiant de transaction peut être utilisé ultérieurement pour récupérer la charge entière de message dans un stockage permanent, un message passant par la portion de routage 10 et de livraison du système est une représentation extrêmement allégée des données complètes du message. Optionnellement, en cas de besoin, la charge complète d'origine peut aussi être attachée au message. Pour faciliter la récupération de données clés par les utilisateurs clients ainsi que le personnel opérationnel, les données du message stockées incluent, dans un mode de réalisation, un Identifiant de 15 Système Externe, un Identifiant de Message (LPC, etc.), la compagnie aérienne (provenance DCS) concernée, l'aéroport concerné, la voix de livraison, les horaires de livraison, les indications d'erreur et les relances de comptage. On remarquera que cette liste n'est pas restrictive et qu'en plus d'autres données peuvent être stockées. La voix de livraison est déterminée par le routeur d'origine et tous les autres routeurs y 20 adhèrent. Seulement après que le message a été stocké dans le journal de transactions et transmis au routeur, l'analyseur 420 est alerté du message, tel qu'il est accepté par la passerelle entrante/source 320, à l'étape 540. À son tour, la passerelle entrante/source 320 ne fait qu'accuser réception du message à la source à l'étape 550, 25 suite à la réception d'une indication d'acceptation provenant de l'analyseur 420. Comme indiqué, chaque routeur 300 comprend une file d'attente de services 340. Les messages internes reçus au routeur 300 en provenance de l'analyseur 420 sont stockés dans la file d'attente du routeur 340 pour traitement, récupérés à l'étape 560 et acheminés par le routeur 300 à l'étape 570 vers la file 30 d'attente de la passerelle de destination 350. En remarquera que ce routage peut impliquer un routage via un nombre de noeuds 210. Alors que les services de passerelle sont fournis dans un mode de réalisation, ils ne sont utilisés que pour la communication avec des systèmes externes. Tous les services internes d'un groupement peuvent communiquer les uns avec les autres directement sans devoir 35 passer par la passerelle de services. Dans un mode de réalisation, les routeurs 300 de ces noeuds communiquent via une passerelle de service 320 intervenante. Dans un 14 autre mode de réalisation, les noeuds 210 et les routeurs 300 dans ces noeuds 210 sont configurés pour permettre une communication directe entre les routeurs 300. Une fois que le message interne a progressé dans la file d'attente de la passerelle de destination 320 il est récupéré par la passerelle de destination et converti 5 dans un format de messages de sac qui, on le sait, est attendu par la destination (un système de traitement de bagage BHS dans le cas de la Figure 6) à l'étape 580, avant la livraison à destination et l'accusé réception par la destination à l'état 590. Figure 8 montre en détail de quelle manière les données sont stockées dans le journal de transactions 270 au fur et à mesure que les messages sont routés de la 10 passerelle entrante 320 à la passerelle sortante 320. Après que le message d'origine a été reçu à la passerelle 320, sa charge est stockée dans sa forme brute sur la base de la couche de transport de réception (c.-à-d. avant de commencer l'analyse) dans le journal de transactions 270 avec un ID de transmission unique pour le message. Au fur et à mesure que le message interne (maintenant modifié) progresse sous sa route de 15 livraison vers la (les) passerelle(s) sortante(s) 320, chaque noeud de routeur 300 stocke un horodatage indiquant que le processus a bien été effectué par le noeud/composant auquel la tâche de mise en oeuvre était confiée. La passerelle entrante stocke aussi la ou les adresse(s) de destination associée(s) avec l'ID de transmission dans le journal de transactions 270. L'horodatage est seulement stocké 20 après l'achèvement du processus auquel il est lié. Par conséquent il est possible de déterminer si oui ou non un message a été traité par la passerelle en 320 et si oui ou non le routage a été complété. Dans l'éventualité où il serait déterminé qu'un message en question n'est pas arrivé à destination, le message interne peut-être généré à nouveau sur la base des données brutes du message d'origine qui ont été stockées 25 dans le journal transactions 270 par la passerelle entrante 320. Au cas où un routeur aurait besoin de se relancer après une défaillance, lorsque le routeur est à nouveau opérationnel en ligne tous les messages valides et non délivrés dans le journal de transactions seront rechargés pour traitement avec une priorité accordée aux messages actuels. Dans un mode de réalisation, une transaction est une étape de 30 transmission d'un message d'un routeur à un autre. Dans un mode de réalisation, chaque transaction est affectée à un routeur spécifique. C'est ce routeur qui complétera les transactions qui lui ont été affectées suite à sa relance. Le système est configuré pour réaffecter des transactions à d'autres routeurs dans l'éventualité où un routeur compromis, auquel des transactions particulières ont été affectées, ne parvient 35 pas à se relancer après un laps de temps prédéterminé. 15 Le journal de transactions, de façon plus générale, contient des entrées qui détaillent les mouvements et les points de vérification actuels du flux de messages circulant dans le BMD. Cela inclut, sans restrictions, des états acceptés acheminés, délivrés, avec accusé réception, expirée, etc. ainsi que les charges brutes complètes 5 entrantes et sortantes. De cette manière, le système 100 est configuré pour reconstruire entièrement le cycle de vie et le chemin traversé d'un message à un quelconque moment donné même après une récupération suite à une défaillance. Comme mentionné ci-dessus, le journal de transactions n'est mis à jour que seulement après avoir atteint avec succès un point de vérification pendant la propagation du 10 message. Dans l'éventualité d'un scénario de récupération, le système 100 a une garantie que l'état du message est au moins actuel ou antérieur à la dernière tentative réussie au point de vérification dans le système. Cela empêche la perte de messages supposément délivrés. La pénalité encourue est au pire la duplication d'un seul message en aval d'un système après récupération. 15 Dans un mode de réalisation, le journal de transactions 270 prend la forme d'un prend la forme d'un registre répliqué d'engagement disponible pour tous les noeuds dans le groupement dans l'ensemble du stockage attaché à un réseau. Dans un mode de réalisation, les enregistrements entrés dans le journal ont un niveau bas et un format simple. Cela permet l'utilisation d'une connectivité brute de base de données 20 Java (JDBC), réduisant les fonctions techniques. Concernant ce qui précède, on remarquera qu'aucun accès de données partagées n'est nécessaire pour un quelconque enregistrement. Le système 100 évite par conséquent les dépendances intertransactions et atteint une production élevée de données parallèles. Bien que l'invention soit illustrée par une description de divers modes de 25 réalisation et bien que ces modes de réalisation soient décrits de façon très détaillée, il n'est pas de l'intention du demandeur de restreindre ou de limiter, de quelque façon que ce soit, l'étendue des revendications des présentes à ces détails. Des avantages supplémentaires et des modifications possibles apparaîtront aisément aux hommes de métier. L'invention sous un angle plus large n'est donc pas limitée aux détails 30 spécifiques, aux procédés et aux appareils représentatifs, et aux illustrations montrées et décrites à titre d'exemple. REVENDICATIONS1. Un point d'accès pour un système de traitement de message d'un bagage comprenant : une interface entrée/sortie adaptée pour se connecter à un système externe ; un convertisseur configuré pour convertir un message reçu via l'interface entrée/sortie et/ou un message devant être transmis via l'interface entrée/sortie dans un format prédéterminé ; un extracteur configuré pour extraire une métadonnée à partir d'un message converti ; et une unité de transmission et/ou de réception configurée pour transmettre et/ou recevoir un autre message comprenant la métadonnée extraite et l'information associée relative à l'adresse. 2. Un point d'accès selon la revendication 1, comprenant en outre un adaptateur configuré pour accéder à une base de données stockant un ou plusieurs protocoles de communication et pour convertir le format des messages sur la base desdits protocoles stockés. 3. Un point d'accès selon la revendication 2, dans lequel ledit adaptateur est configuré pour lier une métadonnée reçue via l'unité de transmission/réception à un message qui doit être envoyé via l'interface entrée/sortie conformément à un protocole de communication stocké. 4. Un point d'accès selon l'une quelconque des revendications précédentes dans lequel l'extracteur est un analyseur qui émet et absorbe des événements au fur et à mesure qu'un arbre d'analyse est traversé. 5. Un point d'accès selon l'une quelconque des revendications précédentes dans lequel il est par ailleurs configuré pour créer un message devant être envoyé via l'unité de transmission/réception en combinant une métadonnée extraite avec un ID de transaction unique. 6. Un système de traitement de message d'un bagage comprenant une pluralité de points d'accès selon l'une quelconque des revendications précédentes et un ou plusieurs routeurs configurés pour router un message reçu par une unité de 17 transmission/réception d'un point d'accès sur la base au moins en partie du contenu de la métadonnée qui forme une partie du message. 7. Un système de traitement de message d'un bagage selon la revendication 6, 5 dans lequel chaque routeur est configuré pour router des messages conformément à des règles de routage, le routeur étant configuré pour compiler de façon dynamique lesdites règles de routage immédiatement avant ou au moment de leur utilisation. 8. Un système de traitement de message d'un bagage selon la revendication 6 ou 10 7, dans lequel est compris un stockage distribué pour stocker les messages reçus de l'interface entrée/sortie d'un point d'accès ainsi que l'information indiquant un état de routage des messages associés transmis par l'unité de transmission/réception du point d'accès. 9. Un système de traitement de message d'un bagage selon la revendication 8 15 dans lequel ladite information comprend un suivi historique complet du routage du message associé. 10. Un système de traitement de message d'un bagage selon la revendication 8 ou 9, dans lequel chaque routeur est configuré, au redémarrage, pour accéder au stockage distribué et router des messages pour lesquels les états associés de routage 20 indiquent que le routage est incomplet. 11. Un système de traitement de message d'un bagage selon l'une quelconque des revendications 8 à 10, dans lequel le stockage distribué est accessible par une pluralité de routeurs. 12. Un système de traitement de message d'un bagage selon l'une quelconque des 25 revendications 6 à 11, dans lequel il est configuré pour associer un point d'accès avec chaque client logique avec lequel la communication doit être établie. 13. Un système de traitement de message d'un bagage selon l'une quelconque des revendications 6 à 12, dans lequel une configuration permet de tracer l'emplacement des éléments individuels d'un bagage en traçant les messages qui comprennent une 30 métadonnée identifiant l'élément et reçu des points d'accès dont la localisation est connue. 18 14. Un procédé de communication d'un message entre un système de traitement de message d'un bagage et un système extérieur au système de traitement de bagage d'un message, le procédé comprenant : la réception d'un message en provenance du système externe via une interface 5 entrée/sortie ; la conversion du message reçu dans un format prédéterminé ; l'extraction d'une métadonnée du message converti ; et la transmission au système de traitement de message de bagage, d'un message comprenant la métadonnée extraite et l'information d'adresse associée. 10 15. Un produit-programme d'ordinateur comprenant des instructions d'ordinateur exécutables qui, lorsqu'elles sont exécutées par un processeur, amène un point d'accès pour un système de traitement de message d'un bagage à: accepter via une interface entrée/sortie un message provenant d'un système externe ; 15 convertir le message reçu dans un format prédéterminé ; extraire la métadonnée du message converti ; et transmettre au système de traitement de message de bagage, un message comprenant la métadonnée extraite et l'information d'adresse associée.