FR 3105476 A1 20210625 FR 1915435 A 20191223 Un procédé pour un accès basé sur un environnement d’exploitation hérité à des données non héritées inclut : la réception, à un serveur d’intermédiation, d’un objet de données non hérité contenant un contenu non hérité ; la génération d’un objet de données hérité contenant le contenu non hérité, pour stockage dans un répertoire ; le stockage, en association à l’objet de données hérité, d’un indicateur de chaîne de distribution non héritée ; l’ajustement d’un mécanisme de traitement hérité au répertoire conformément à l’indicateur de chaîne de distribution non héritée ; la réception d’un sous-système client, via une interface héritée, d’une demande pour du contenu non hérité ; et en réponse à la demande, la récupération et l’envoi de l’objet de données hérité contenant le contenu non hérité, via l’interface héritée. Système et procédé pour un accès basé sur un environnement d’exploitation hérité à des données non héritées La spécification concerne de façon générale des systèmes informatiques et spécifiquement un système et un procédé permettant un accès basé sur un environnement d’exploitation hérité à des données non héritées dans ces systèmes. Contexte Les systèmes informatiques peuvent stocker et traiter des données générées via une pluralité de chaînes, p. ex. en utilisant des protocoles de communication, des séquences de messagerie distincts (et pas nécessairement compatibles) et similaires. Ces systèmes peuvent inclure de nombreux sous-systèmes distincts dont certains peuvent être capables de manipuler des données (p. ex. pour initier des opérations de traitement, récupérer des données pour affichage et similaires) uniquement selon un sous-ensemble des chaînes susmentionnées. Les données générées via d’autres chaînes peuvent rester inaccessibles à ces sous-systèmes Résumé Un aspect de la spécification fournit un procédé pour un accès basé sur un environnement d’exploitation hérité à des données non héritées, le procédé comprenant : la réception, à un serveur d’intermédiation, d’un objet de données non hérité contenant un contenu non hérité ; la génération d’un objet de données hérité contenant le contenu non hérité, pour stockage dans un répertoire ; le stockage, en association à l’objet de données hérité, d’un indicateur de chaîne de distribution non héritée ; l’ajustement d’un mécanisme de traitement hérité au répertoire conformément à l’indicateur de chaîne de distribution non héritée ; la réception d’un sous-système client, via une interface héritée, d’une demande pour du contenu non hérité ; et en réponse à la demande, la récupération et l’envoi de l’objet de données hérité contenant le contenu non hérité, via l’interface héritée. Le stockage de l’indicateur de chaîne de distribution non héritée peut inclure le stockage de l’indicateur de chaîne de distribution non héritée dans un champ de l’objet de données hérité. L’ajustement du mécanisme de traitement hérité peut inclure : de déterminer si l’objet de données hérité est associé à l’indicateur de chaîne de distribution non héritée ; lorsque la détermination est affirmative, de sélectionner un autre mécanisme de traitement distinct du mécanisme de traitement hérité. L’ajustement du mécanisme de traitement hérité peut inclure : de déterminer si l’objet de données hérité est associé à l’indicateur de chaîne de distribution non héritée ; lorsque la détermination est affirmative, de supprimer le mécanisme de traitement hérité. Le procédé peut comprendre par ailleurs : lorsque la détermination est négative, d’initier le mécanisme de traitement hérité. Le mécanisme de traitement hérité est un mécanisme de publication configuré pour transmettre au moins une portion d’un objet de données hérité à un autre sous-système. L’envoi de l’objet de données hérité peut inclure d’envoyer l’indicateur de chaîne de distribution non héritée. L’envoi de l’objet de données hérité peut inclure d’omettre l’indicateur de chaîne de distribution non héritée. L’ajustement du mécanisme de traitement hérité conformément à l’indicateur de chaîne de distribution non héritée peut inclure d’appliquer une restriction d’accès non héritée à une base de données héritée. Un autre aspect de la spécification fournit un serveur d’intermédiation pour un accès basé sur un environnement d’exploitation hérité à des données non héritées, le serveur d’intermédiation comprenant : une mémoire stockant un répertoire ; une interface de communication ; et un processeur connecté à l’interface de communication, et la mémoire, le processeur étant configuré pour : recevoir, via l’interface de communications, un objet de données hérité contenant du contenu non hérité ; générer un objet de données hérité contenant le contenu non hérité ; stocker, en association à l’objet de données hérité, un indicateur de chaîne de distribution non héritée ; ajuster un mécanisme de traitement hérité au répertoire conformément à l’indicateur de chaîne de distribution non héritée ; recevoir d’un sous-système client, via une interface héritée, une demande pour du contenu non hérité ; et en réponse à la demande, récupérer et envoyer l’objet de données hérité contenant le contenu non hérité, via l’interface héritée. Le processeur peut être configuré, afin de stocker l’indicateur de chaîne de distribution non héritée, pour stocker l’indicateur de chaîne de distribution non héritée dans un champ de l’objet de données hérité dans le répertoire. Le processeur peut être configuré, afin d’ajuster le mécanisme de traitement hérité, pour : déterminer si l’objet de données hérité est associé à l’indicateur de chaîne de distribution non héritée ; lorsque la détermination est affirmative, sélectionner un autre mécanisme de traitement distinct du mécanisme de traitement hérité. Le processeur peut être configuré, afin d’ajuster le mécanisme de traitement hérité, pour : déterminer si l’objet de données hérité est associé à l’indicateur de chaîne de distribution non héritée ; lorsque la détermination est affirmative, supprimer le mécanisme de traitement hérité. Le processeur peut par ailleurs être configuré pour : lorsque la détermination est négative, initier le mécanisme de traitement hérité. Le mécanisme de traitement hérité peut être un mécanisme de publication configuré pour transmettre au moins une portion d’un objet de données hérité à un autre sous-système. Le processeur peut être configuré pour envoyer l’indicateur de chaîne de distribution non héritée avec l’objet de données hérité. Le processeur peut être configuré pour omettre l’indicateur de chaîne de distribution non héritée lors de l’envoi de l’objet de données hérité. Le processeur peut être configuré, dans le but d’ajuster le mécanisme de traitement hérité conformément à l’indicateur de chaîne de distribution non héritée, pour appliquer une restriction d’accès non hérité à une base de données héritée. Un autre aspect de la spécification fournit un produit-programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur comprenant : des moyens de programme lisibles par ordinateur pour recevoir, via une interface de communications, un objet de données non hérité contenant du contenu non hérité ; des moyens de programme lisibles par ordinateur pour générer un objet de données hérité contenant le contenu non hérité ; des moyens de programme lisibles par ordinateur pour stocker, en association à l’objet de données hérité, un indicateur de chaîne de distribution non héritée ; des moyens de programme lisibles par ordinateur pour ajuster un mécanisme de traitement hérité au répertoire conformément à l’indicateur de chaine de distribution non héritée ; des moyens de programme lisibles par ordinateur pour recevoir, d’un sous-système client, via une interface héritée, une demande pour du contenu non hérité ; et des moyens de programme lisibles par ordinateur pour, en réponse à la demande, récupérer et envoyer l’objet de données hérité contenant le contenu non hérité, via l’interface héritée lorsque ledit programme fonctionne sur un serveur d’intermédiation. Les modes de réalisation sont décrits en faisant référence aux figures suivantes, dans lesquelles : est un diagramme illustrant un système pour permettre un accès basé sur un environnement d’exploitation hérité à des données non héritées ; est un diagramme illustrant certains composants internes du serveur d’intermédiation de la FIG. 1 ; est un organigramme d’un procédé pour permettre un accès basé sur un environnement d’exploitation hérité à des données non héritées ; est un diagramme illustrant une exécution des blocs 305, 310 et 315 du procédé de la FIG. 3 ; est un diagramme illustrant une exécution des blocs 305, 310, 320 et 315 du procédé de la FIG. 3 ; et illustre une exécution exemplaire des blocs 345, 325, 330, 335 et 350 du procédé de la FIG. 3. Description détaillée La FIG. 1 décrit un système 100 pour intégrer la capacité d’accès basé sur un environnement d’exploitation hérité à des données non héritées. À l’intérieur du système 100 divers sous-systèmes informatiques interagissent pour générer et traiter des données relatives à une quelconque d’une grande variété d’activités. Dans les exemples décrits ci-dessous, les sous-systèmes du système 100 interagissent pour générer et traiter des données relatives à la livraison d’articles à des clients. Les articles dans les exemples sont des produits et des services liés au voyage, tels que des billets d’avion, des réservations d’hôtel, des réservations de location de véhicule, et similaires. Une grande variété d’autres activités peuvent être permises par l’échange de données entre les sous-systèmes montrés du système 100 et la nature spécifique des données traitées à l’intérieur du système 100 n’est pas particulièrement limitée. Dans l’exemple illustré, le système 100 inclut au moins un sous-système client 104, dont deux exemples 104-1 et 104-2 sont montrés dans la FIG. 1 (collectivement désignés comme étant les sous-systèmes clients 104 et de façon générique comme étant un sous-système client 104). Chaque sous-système client 104 est géré par une entité cliente qui peut aussi être désignée comme étant un vendeur. Le vendeur peut par exemple être une agence de voyages. Le sous-système client 104 génère des requêtes, p. ex. pour le compte de clients, pour des articles de voyage. Les requêtes spécifient divers attributs des articles de voyage, tels qu’un lieu d’origine et de destination, des horaires et des dates de voyages, et similaires. Les réponses aux requêtes des sous-systèmes client 104 sont générées par, ou pour le compte d’entités qui fournissent les articles, désignées dans la présente comme étant des fournisseurs. Par conséquent, dans le présent exemple les fournisseurs sont des entités telles que des lignes aériennes, des gestionnaires hôteliers ou similaires qui délivrent les articles au client, ou à d’autres de ces entités pour une livraison éventuelle au client, suite à l’achat des articles (cet achat étant effectué par exemple via un sous-système client 104). Chaque entité fournisseuse gère un sous-système 108 ; deux sous-systèmes fournisseurs exemplaires 108-1 et 108-2 sont montrés dans la FIG. 1. Chacun des sous-systèmes clients 104 et des sous-systèmes fournisseurs 108 sont implémentés sous forme d’au moins un dispositif informatique avec des assemblages d’entrée et de sortie et des dispositifs de communication pour échanger des données via un réseau 112. Le réseau 112 peut inclure une quelconque combinaison appropriée de réseaux de zone locale et de zone étendue, incluant l’Internet. Bien que deux sous-systèmes clients 104 et deux sous-systèmes fournisseurs 108 soient montrés dans la FIG. 1, le système 100 peut inclure un nombre plus grand nombre ou plus petit de sous-systèmes clients 104 et de sous-systèmes fournisseurs 108 dans d’autres exemples. La génération de réponses aux requêtes des sous-systèmes clients 104 peut prendre des formes variées. Dans l’exemple illustré, le sous-système client 108-1 est supposé générer des réponses à ces requêtes localement, bien que, comme on le verra ci-dessous, les requêtes ne sont pas transmises directement du sous-système client 104 au sous-système fournisseur 108-1. C’est-à-dire que le sous-système fournisseur 108-1 inclut un module de génération d’offres (p. ex. des instructions lisibles par ordinateur et du matériel d’exécution correspondant ainsi que diverses données stockées pour usage dans la génération des réponses) qui permet au sous-système 108-1 de générer des données de réponse basées sur les attributs spécifiés dans la requête émise à l’origine par un sous-système client 104. Les données de réponse peuvent aussi être désignées comme étant « des données d’offre » et définissent un ou plusieurs articles qui correspondent, ou correspondent partiellement, aux attributs demandés. D’autres sous-systèmes fournisseurs 108, tels que le sous-système fournisseur 108-2 dans le présent exemple peuvent ne pas générer de réponses à des requêtes du sous-système client 104. Au lieu de cela, ces réponses peuvent être générées par un sous-système de distribution 116. Le sous-système fournisseur 108-2 peut, par exemple, publier des données définissant les articles offerts par l’entité fournisseuse qui gère le sous-système fournisseur 108-2 à un sous-système de publication 120. Le sous-système de publication 120 peut être généré par une partie tierce (c.-à-d. distincte des entités fournisseuses susmentionnées) et peut recevoir des données d’articles publiées telles que des programmations de vol, des tarifs et similaires d’un ou de plusieurs sous-systèmes fournisseurs 108. Le sous-système de distribution 116, en retour, peut récupérer des données du système de publication 120 pour usage dans la génération de réponses à des requêtes provenant de sous-systèmes clients 104 pour le compte du sous-système fournisseur 108-2. Les mécanismes de génération de réponse distincts mentionnés ci-dessus peuvent être implémentés en utilisant différents ensembles de protocoles de communication, de normes d’échange de données et similaire. La collection de protocoles de communication, de formats de données normalisés et similaires qui définit comment les données de réponse sont générées pour une requête d’un client peut être désignée comme étant la chaîne de distribution selon laquelle cette requête est traitée. Comme il en ressortira pour les hommes de métier, dans le contexte des articles de voyage, une chaîne de distribution exemplaire est la norme de nouvelle capacité de distribution (NDC). La norme NDC définit un langage de balisage extensible (XML) basé sur un format de données ainsi qu’une syntaxe de message, des sollicitations API et similaire pour des messages échangés entre des sous-systèmes clients 104 et des sous-systèmes fournisseurs 108. Dans le présent exemple, le sous-système fournisseur 108-1 qui génère des données de réponse localement, est supposé utiliser la chaîne NDC. La chaîne NDC est aussi désignée dans la présente comme étant une chaîne de distribution non héritée, et le contenu (c.-à-d. les données définissant des articles) obtenu via la chaîne NDC est désigné comme étant un contenu non hérité. C’est-à-dire que le contenu non hérité est obtenu via la messagerie NDC. Une autre chaîne de distribution exemplaire dans le contexte des articles de voyage est une chaîne de système de distribution mondiale (GDS). Les composants du système 100 qui implémentent la chaîne GDS, tels que le sous-système de distribution 116 et le sous-système fournisseur 108-2 dans l’exemple illustré, utilisent une syntaxe de message, un séquencement, et similaires, qui sont différents de ceux qui sont utilisés sous la norme NDC. Par exemple, la chaîne GDS peut utiliser une syntaxe de message, une séquence, et similaire, ainsi que spécifié par la norme d’échanges de données électroniques pour l’administration, le commerce et les transports (EDIFACT). La chaîne GDS est aussi désignée dans la présente comme étant une chaîne de distribution héritée, et le contenu (c.-à-d. les données définissant les articles) obtenu via la chaîne GDS est désigné comme étant un contenu hérité. C’est-à-dire que le contenu hérité est obtenu via la messagerie GDS. En d’autres termes, les données de réponse (c.-à-d. le contenu susmentionné) peuvent être générées dans le système 100 en utilisant deux ou plusieurs mécanismes de génération distincts, ou chaînes de distribution. Certains sous-systèmes clients 104 peuvent être configurés pour obtenir des données de réponse uniquement via une chaîne (et non l’autre). Par ailleurs, les sous-systèmes clients 104 peuvent inclure des composants internes qui sont uniquement compatibles avec une chaîne de distribution. Par exemple, le sous-système client 104-1 peut être configuré pour obtenir des données de réponse via une chaîne ou l’autre, mais inclut un moteur de comptabilité 122 qui est uniquement compatible avec des données obtenues via la chaîne GDS (c.-à-d. du contenu hérité). Une grande variété de ces composants internes peut être incluse dans chaque sous-système client 104 et au moins certains de ces composants internes peuvent avoir été déployés uniquement avec une compatibilité de contenu hérité. Les sous-systèmes 104 peuvent être configurés pour obtenir à la fois du contenu hérité et non hérité, tel qu’un premier vol pour un client donné obtenu via la chaîne GDS et un deuxième vol pour ce client obtenu via la chaîne NDC. Pour permettre aux sous-systèmes client 104 de voir et de manipuler à la fois le contenu hérité et non hérité en même temps, certains systèmes implémentent un stockage de données partagé et un mécanisme de gestion avec un ensemble partagé de normes de formatage, de sollicitations API, et similaire. Cependant, ces systèmes ne solutionnent pas la compatibilité limitée des composants tels que le moteur 122 : le stockage partagé et les mécanismes de gestion diffèrent des mécanismes hérités et le moteur 122 est donc incapable d’utiliser ces mécanismes partagés sans des modifications potentiellement coûteuses. Le système 100 est donc configuré pour permettre aux composants tels que le moteur 122 d’accéder à des données non héritées (ainsi que des données héritées) en utilisant des mécanismes d’accès hérités. La fonctionnalité exposée dans la présente permet au moteur 122 et aux autres composants compatibles avec l’héritage de continuer à fonctionner avec peu ou aucune modification technique pour implémenter la compatibilité non héritée. Dans ce but, le système 100 inclut un serveur d’intermédiation 124 (également simplement désigné dans la présente comme étant le serveur 124) connecté au réseau 112. Les requêtes générées par les sous-systèmes clients 104 sont transmises via le réseau 112 au serveur d’intermédiation 124. Le serveur d’intermédiation 124 reçoit des requêtes des sous-systèmes client 104 et transmet ces requêtes aux sous-systèmes fournisseurs 108 et/ou au sous-système de distribution 116. Le serveur d’intermédiation 124 reçoit aussi des réponses provenant des sous-systèmes fournisseurs 108 et/ou des sous-systèmes de distribution 116 pour renvoyer ces réponses au sous-système client 104. Les réponses mentionnées ci-dessus (c.-à-d. le contenu) sont stockées dans un répertoire 128 au serveur 124. En particulier, comme cela sera décrit de façon plus détaillée ci-dessous, le contenu obtenu via une quelconque chaîne de distribution est stocké dans le répertoire 128 dans des objets de données hérités. Le stockage de contenu obtenu via à la fois les chaînes de distribution héritées et non héritées permet aux composants tels que le moteur 122 de récupérer et de traiter des données non héritées avec peu ou aucune modification. De plus, le serveur 124 est configuré pour appliquer diverses formes de mécanismes de traitement hérités aux données dans le répertoire 128. Cependant, ainsi que noté ci-dessus, le répertoire 128 peut aussi contenir du contenu non hérité pour lequel les mécanismes de traitement hérités peuvent être inappropriés. Bien que le contenu non hérité soit stocké dans le répertoire 128 dans des objets de données hérités, des interactions avec des entités externes telles que le sous-système 108-1 pour actualiser le contenu non hérité sont toujours effectuées selon la chaîne de distribution non héritée (p. ex. NDC). Le serveur 124 est donc aussi configuré pour suivre quel contenu dans le répertoire 128 est du contenu non hérité (c.-à-d. provenant de la chaîne de distribution non héritée). Le serveur 124 peut aussi, selon le suivi, ajuster les mécanismes de traitement hérités à du contenu non hérité. Avant d’aller plus loin dans la description de la fonctionnalité des divers composants du système 100, certains composants internes du serveur d’intermédiation 124 seront décrits en faisant référence à la FIG. 2. Prêtant attention à la FIG. 2, le serveur d’intermédiation 124 inclut au moins un processeur 200, tel qu’une unité de traitement centrale (CPU) ou similaire. Le processeur 200 est interconnecté à une mémoire 204 implémentée comme un support non transitoire, lisible par ordinateur (p. ex. une combinaison appropriée de sous-systèmes de mémoires volatiles et non volatiles incluant une quelconque ou plusieurs mémoires à accès aléatoire (RAM), mémoires à lecture seule (ROM), mémoires programmables à lecture seule effaçables électriquement (EEPROM), mémoires flash, stockage informatique magnétique, et similaire. Le processeur 200 et la mémoire 204 sont généralement compris d’un ou de plusieurs circuits intégrés (ICs). Le processeur 200 est aussi interconnecté à une interface de communication 208 qui permet au serveur 124 de communiquer avec les autres dispositifs informatiques du système 100 via le réseau 112. L’interface de communication 208 inclut donc tous les composants nécessaires (p. ex. des contrôleurs d’interface de réseau [NICs] des unités de radio, et similaires) pour communiquer via le réseau 112. Les composants spécifiques de l’interface de communication 208 sont sélectionnés en fonction de la nature du réseau 112. Le serveur 124 peut aussi inclure des dispositifs d’entrée et de sortie connectés au processeur 200, tels que des claviers, des souris, des écrans, et similaires (non illustrés). Les composants du serveur 124 mentionnés ci-dessus peuvent être déployés dans une seule enceinte ou sous un format distribué. Par conséquent dans certains exemples, le serveur 124 inclut une pluralité de processeurs qui peuvent soit partager la mémoire 204 et l’interface de communications 208 ou qui ont chacun des interfaces de communications et des mémoires associées distinctes. La mémoire 204 stocke le répertoire 128 ainsi que des instructions lisibles par ordinateur exécutables par le processeur 200 pour implémenter diverses fonctionnalités. Les instructions lisibles par ordinateur peuvent aussi être désignées comme étant des applications et dans l’exemple illustré, la mémoire 204 stocke une application de gestion de commande 212 (également dénommée simplement dans la présente comme étant l’application 212). Dans la description ci-dessous, le processeur 200 et de façon plus générale le serveur 124 sont censés effectuer ou être configurés pour effectuer ces actions. On comprendra qu’ils sont configurés ainsi via l’exécution (par le processeur 200) des instructions des applications stockées dans la mémoire 204, incluant l’application 212. L’exécution de l’application 212 par le processeur 200 configure le serveur 124 pour obtenir des données via une quelconque des chaînes de distribution mentionnées ci-dessus et pour stocker des données dans le répertoire 128. L’exécution de l’application 212 configure également le serveur 124 pour ajuster les mécanismes de traitement hérités exécutés sur des enregistrements dans le répertoire 128, sur la base de la chaîne de distribution par laquelle les enregistrements ont été obtenus. Un exemple d’un mécanisme de traitement est la gestion d’un enregistrement dans le répertoire 128 en réponse à une requête pour l’enregistrement provenant d’un sous-système client 104. Certains autres mécanismes de traitement exemplaires seront aussi détaillés ci-dessous. Faisant maintenant référence à la FIG. 3, certains aspects d’exploitation du système 100 seront décrits de façon plus détaillée. Spécifiquement, la FIG. 3 illustre un procédé 300 pour fournir un accès à des données non héritées en utilisant des mécanismes d’accès basé sur un environnement d’exploitation hérité. La mise en œuvre du procédé 300 sera exposée conjointement avec sa mise en œuvre dans le système 100 et spécifiquement par le serveur d’intermédiation 124 via l’exécution de l’application 212. Au bloc 305, le serveur 124 reçoit du contenu pour stockage dans le répertoire 128. La réception du contenu peut être précédée par une variété d’autres actions qui sont en dehors du champ d’application de la présente discussion. En bref, le serveur 124 peut recevoir une requête pour du contenu (p. ex. une requête pour des données définissant des articles de voyage pouvant être achetés) provenant d’un sous-système client 104. Le serveur 124 peut ensuite relayer la requête à l’entité pertinente dans le système 100, telle que le sous-système fournisseur 108-1 et le sous-système de distribution 116. Le serveur 124 peut ensuite recevoir au moins une réponse de l’entité ou des entités auxquelles la requête a été relayée pour traitement au bloc 305. Au bloc 310, le serveur 124 détermine si le contenu reçu au bloc 305 est un contenu non hérité. C’est-à-dire que le serveur 124 détermine si le contenu du bloc 305 a été obtenu selon la chaîne de distribution héritée (p. ex. en interagissant avec le sous-système de distribution 116) ou selon la chaîne de distribution non héritée (p. ex. en interagissant avec le sous-système fournisseur 108-1). La détermination au bloc 310 peut être basée sur l’entité ou les entités à partir desquelles le serveur 124 a reçu le contenu, la syntaxe de message, les sollicitations API, ou similaires, utilisées pour recevoir le contenu, et similaire. Par exemple, le serveur 124 peut stocker les paramètres de configuration indiquant le type de contenu pour chaque sous-système fournisseur 108. Lorsque la détermination au bloc 310 est négative, indiquant que le contenu reçu au bloc 305 est un contenu hérité (p. ex. obtenu via la chaîne de distribution GDS dans le présent exemple), le serveur 124 poursuit au bloc 315. Au bloc 315, le contenu reçu au bloc 305 est stocké dans le répertoire 128. Dans le cas d’un contenu hérité, le stockage au bloc 315 n’a pas besoin d’impliquer une quelconque modification du contenu parce que les enregistrements du répertoire 128 sont formatés selon la chaîne de distribution héritée. Faisant référence à la FIG. 4, une exécution exemplaire des blocs 305, 310 et 315 est montrée. En particulier, le sous-système de distribution 116 est montré transmettant un contenu sous la forme d’un objet de données hérité 400 au serveur 124 via le réseau 112. L’objet de données hérité 400 peut être, par exemple, un enregistrement contenant des données acquises à travers le processus EDIFACT, ainsi que noté précédemment. Au bloc 310, la détermination est négative et donc au bloc 315 le serveur 124 stocke l’objet de données hérité 400 dans le répertoire 128. Les contenus de l’objet de données 400 sont montrés dans la boîte en pointillés indiquant un traitement via l’exécution de l’application 212. Dans l’exemple illustré, l’objet de données 400 inclut un champ d’identifiant d’enregistrement 404, un champ de nom 408 et un champ de définition d’article 412. Une grande variété de champs supplémentaires peuvent être inclus dans l’objet de données 400. Comme il en ressortira pour les hommes de métier, l’objet de données 400 est un exemple simplifié d’un enregistrement de nom de passager (PNR) tel qu’utilisé dans les chaînes de distribution basées sur le GDS. De plus, l’objet de données 400 peut être stocké dans le répertoire 128 sous la forme selon laquelle l’objet de données 400 a été reçu du sous-système de distribution 116. Faisant référence à nouveau à la FIG. 3, suite à la mise en œuvre du bloc 315, le serveur 124 peut retourner au bloc 305 pour recevoir du contenu supplémentaire, ainsi qu’indiqué par la ligne pointillée du bloc 315 au bloc 305. De façon plus générale, la mise en œuvre des blocs 305-315 (et du bloc 320 exposé ci-dessous) peut être répétée non seulement avant que le restant du procédé 300 soit exécuté, mais aussi durant l’exécution du restant du procédé 300. C’est-à-dire que les blocs 305-320 indiquent comment le serveur 124 reçoit et traite le contenu pour stockage dans le répertoire 128 pendant que les blocs restants du procédé 300 indiquent comment le contenu déjà stocké dans le répertoire 128 peut être traité. La réception du contenu de stockage et le traitement du contenu stocké peuvent être dissociés l’un de l’autre. Lorsque la détermination au bloc 310 est affirmative, indiquant que le contenu reçu au bloc 305 est un contenu non hérité (p. ex. obtenu via la chaîne de distribution NDC dans le présent exemple), le serveur 124 avance au bloc 320 avant le bloc 315. Au bloc 320, le serveur 124 génère un objet de données hérité qui contient le contenu reçu au bloc 305. En d’autres termes, le bloc 320 implique une conversion du contenu non hérité dans un format hérité pour stockage dans le répertoire 128. Le serveur 124 génère aussi, au bloc 320, un indicateur de chaîne de distribution associé à l’objet de données hérité contenant le contenu non hérité. Faisant référence à la FIG. 5, une exécution exemplaire des blocs 305, 310, 320 et 315 est illustrée. Les actions exemplaires montrées dans la FIG. 5 sont supposées avoir lieu après l’exécution des blocs 305-315 détaillée ci-dessus en lien avec la FIG. 4 et l’objet de données 400 est donc montré dans le répertoire 128. Dans l’exemple illustré dans la FIG. 5, au bloc 305 le serveur 124 reçoit un objet de données non hérité 500 du sous-système fournisseur 116-1. L’objet de données 500 peut inclure des données acquises via un message formaté selon la norme NDC, tel qu’un message d’ordre NDC contenant des données définissant un ou plusieurs éléments réservés pour le compte d’un client. Comme le montre la FIG. 5, l’objet de données 500 inclut un champ d’identifiant d’enregistrement 504, un champ de nom de passager 508 et au moins un champ d’article. Dans le présent exemple, deux champs d’article 512 et 516 sont montrés, chacun contenant des données définissant un vol. L’objet de données non hérité 500 peut aussi inclure divers autres champs définissant divers autres produits ou services et des informations associées. Par exemple, l’objet de données 500 peut être un objet d’article de commande NDC incluant des données telles qu’un identifiant d’article de commande et similaire, qui peut ne pas avoir d’analogue direct dans les objets de données hérités. Suite à une détermination affirmative au bloc 310, le serveur 124 poursuit au bloc 320 pour générer un objet de données hérité 518 à partir du contenu non hérité dans l’enregistrement de données 500. En particulier, l’application 212 peut inclure des règles de mappage, ou similaires, qui spécifient les champs d’un objet de données hérité qui correspondent à des champs d’un objet de données non hérité. Un exemple de mappage est illustré dans la FIG. 5 par des lignes pointillées entre les champs 504-516 de l’objet de données 500 et les champs correspondants de l’objet de données hérité 518. En particulier, le champ d’identifiant d’enregistrement 504 correspond à un champ d’identifiant d’enregistrement 520. De façon similaire, le champ de nom de passager correspond à un champ de nom 524. Les champs d’article 512 et 516 sont combinés en un seul champ de segment 528 (qui peut aussi être désigné comme étant un segment de vol pour du contenu GDS). C’est-à-dire, que le serveur 124 peut être configuré pour récupérer des données d’un quelconque champ d’article 512, 516, etc. dans l’objet de données non hérité 500 et insérer ces données dans des sous-champs ou une quelconque autre structure de donnée appropriée dans un seul champ de segment 528. Dans d’autres exemples, la conversion d’un objet de données non hérité en un objet de données hérité n’a pas besoin d’inclure la fusion de champs ainsi qu’illustré dans la FIG. 5. Au lieu de cela, dans d’autres exemples un plusieurs champs d’un enregistrement de données non hérité 500 peuvent être divisés en de multiples champs correspondants dans l’enregistrement de données hérité 518. Comme il en ressortira maintenant, les champs 520-528 sont structurellement alignés sur les champs 404-412 montrés dans la FIG. 4. C’est-à-dire, avec une exception notée ci-dessous, que le contenu de l’objet de données non hérité 500 est converti, via le bloc 320, en un format approprié pour stockage comme objet de données hérité. L’exception mentionnée ci-dessus inclut la génération et le stockage d’un indicateur de chaîne de distribution correspondant à l’objet de données hérité 518. Dans certaines des implémentations, des exceptions supplémentaires incluent le stockage de liens entre les champs des objets de données 500 et 518 qui sont générés durant le processus de conversion. Ces liens peuvent être stockés dans l’objet de données hérité 518 lui-même, ou dans un répertoire séparé. L’indicateur de chaîne de distribution qui dans l’exemple illustré est la chaîne « NDC », indique que le contenu dans l’objet de données hérité 518 a été obtenu via un mécanisme non hérité tel qu’une chaîne de distribution NDC. L’indicateur peut être stocké dans un champ d’indicateur de chaîne de distribution 532 de l’objet de données 518. À noter que l’objet de données hérité 400 n’inclut pas un tel indicateur. De façon plus générale, les objets de données contenant du contenu hérité n’ont pas besoin d’être associés avec un tel indicateur bien que dans d’autres modes de réalisation, tous les objets de données dans le répertoire 128 peuvent inclure des indicateurs de chaîne de distribution (p. ex. « NDC » pour du contenu non hérité et « GDS » pour du contenu hérité). Dans d’autres exemples, l’indicateur de chaîne de distribution peut être stocké indépendamment de l’objet de données 518 par exemple dans un index distinct identifiant quels enregistrements dans le répertoire 128 sont associés à une chaîne de distribution non héritée. Suite à la génération de l’objet de donnée hérité 518 et de l’indicateur de chaîne de distribution, l’objet de données hérité 518 est stocké dans le répertoire 128 au bloc 315. De retour à la FIG. 3, le serveur est ensuite configuré, au bloc 325, pour déterminer s’il doit initier un quelconque d’une variété de mécanismes de traitement par rapport à un ou plusieurs des objets de données stockés dans le répertoire 128. La détermination au bloc 325 peut être basée sur divers facteurs et de nombreux exemples de mécanismes de traitement peuvent être initiés en réponse à ces déterminations. Des exemples de mécanismes de traitement incluent un flux de données qui peut aussi être désigné comme étant un mécanisme de publication. Par exemple, suite à la création d’un objet de données dans le répertoire 128 ou de l’application d’une mise à jour à un objet de données dans le répertoire 128, le serveur 124 peut être configuré pour initier un mécanisme de publication afin d’informer d’autres entités dans le système 100 (p. ex. un ou plusieurs des sous-systèmes fournisseurs 108) des changements effectués dans l’enregistrement de données. Un tel mécanisme de publication peut aussi être initié périodiquement et la détermination au bloc 325 peut donc inclure de déterminer si un laps de temps prédéterminé depuis une publication précédente s’est écoulé. Un autre exemple d’un mécanisme de traitement est la récupération d’un objet de données du répertoire 128 et la fourniture de l’objet de données à un autre composant du système 100 (p. ex. un sous-système client 104) en réponse à une requête de ce composant. Cet exemple en particulier sera exposé de façon plus détaillée ci-dessous. D’autres exemples de mécanismes de traitement qui peuvent être initiés au bloc 325 incluent des demandes de traitement pour modifier ou supprimer des objets de données dans le répertoire 128, l’indexation de processus effectués sur le répertoire 128 et similaires. Par conséquent au bloc 325, le serveur 124 peut évaluer une quelconque d’une variété de conditions pour déterminer s’il faut initier au moins un mécanisme de traitement. Si la détermination au bloc 325 est négative le serveur 124 revient au bloc 305 pour attendre d’autre contenu. Le serveur 124 peut aussi répéter l’exécution du bloc 325. Ainsi que noté ci-dessus, l’exécution des blocs 305-320 et celle du bloc 325 et des blocs suivants n’a pas besoin d’être couplée. C’est-à-dire que les conditions qui conduisent à une détermination affirmative au bloc 325 n’ont pas besoin d’être associées directement à l’objet de données le plus récemment reçu. Lorsque la détermination au bloc 325 est affirmative pour un objet de données donné, le serveur 124 poursuit au bloc 330. Au bloc 330, le serveur 124 détermine si l’objet de données est associé à l’indicateur de chaîne de distribution non héritée. Dans le présent exemple, le serveur 124 détermine au bloc 330 si l’objet de données inclut un champ d’indicateur de chaîne de distribution 532, ainsi qu’illustré dans la FIG. 5. En d’autres termes, au bloc 330 le serveur 124 détermine si l’objet de données pour lequel un mécanisme de traitement a été initié au bloc 325 contient du contenu hérité ou du contenu non hérité. Lorsque la détermination au bloc 330 est affirmative, indiquant que l’objet de données (bien que ce soit structurellement un objet de données hérité ainsi expliqué en lien avec le bloc 320) contient des données non héritées, le serveur poursuit au bloc 332. Au bloc 332, le serveur 124 détermine si un ajustement est nécessaire pour au moins un mécanisme de traitement hérité déclenché au bloc 325. Le serveur 124 peut stocker des indicateurs de mécanismes de traitement hérités qui peuvent être appliqués sans ajustements aux objets de données, quel que soit le type de contenu stocké dans ces derniers. Si le mécanisme de traitement déclenché au bloc 325 n’apparaît pas dans les indicateurs ci-dessus, la détermination au bloc 332 est affirmative et le serveur 124 poursuit au bloc 335. Au bloc 335, le serveur 124 ajuste le mécanisme de traitement initié au bloc 325 selon l’indicateur de chaîne de distribution. C’est-à-dire, que le serveur 124 sélectionne un mécanisme de traitement ajusté qui peut différer (mais ne doit pas obligatoirement différer) du mécanisme de traitement initié au bloc 325. Lorsque la détermination au bloc 332 est négative, indiquant qu’aucun ajustement n’est nécessaire, le serveur 124 poursuit alors au bloc 340, expliqué ci-dessous. Certains mécanismes de traitement, tels que le mécanisme de flux ou le mécanisme de publication mentionnés ci-dessus, peuvent ne pas être appropriés pour du contenu non hérité, mais sont néanmoins déclenchés au bloc 325 en réponse à une mise à jour du répertoire 128 parce que ces processus peuvent être déclenchés automatiquement en réponse à une quelconque mise à jour des objets de données hérités. L’ajustement peut donc inclure la suppression du mécanisme de traitement initié au bloc 325 de sorte que le mécanisme ajusté sélectionné au bloc 335 est simplement un processus invalidé (c.-à-d. une absence de traitement supplémentaire). Dans d’autres cas, le mécanisme de traitement ajusté sélectionné peut être analogue au mécanisme de traitement initié au bloc 325, mais peut différer dans au moins une particularité. Les ajustements aux mécanismes de traitement peuvent être reflétés dans les données de configuration des ajustements stockés au serveur 124, p. ex. dans les instructions de l’application 212. Par exemple, les données de configuration des ajustements peuvent mapper les mécanismes de traitement hérités sur des mécanismes de traitement ajustés. Le tableau 1 illustre des données de configuration d’ajustement exemplaires. Configuration d’ajustement de mécanisme de traitement Fonction héritée Fonction non héritée Flux fournisseur N/A Examen de la sécurité Examen de la sécurité GDS modifier la sécurité NDC modifier la sécurité Comme on le voit dans le tableau 1, une fonction de traitement de flux de fournisseurs (c.-à-d. la fonction de publication susmentionnée) n’est mappée sur aucune fonction non héritée. Par conséquent, lorsque le mécanisme de traitement hérité de flux de fournisseur est initié au bloc 325, au bloc 335 l’ajustement sélectionné pour ce mécanisme de traitement est de supprimer le mécanisme de traitement hérité et l’exécution du procédé 300 prend simplement fin. Le tableau 1 illustre aussi une fonction de traitement d’examen de la sécurité, utilisée pour déterminer s’il faut accorder une requête (p. ex. par un sous-système client 104 ou un de ses composants) afin de récupérer un objet de données du répertoire 128 pour affichage. Les données de configuration d’ajustement exemplaires du tableau 1 indiquent au bloc 335 que la même fonction de traitement est utilisée (c.-à-d. qu’aucun ajustement n’est fait et la détermination au bloc 332 pour le mécanisme « examen de la sécurité » serait négative). Dans d’autres exemples cependant, comme dans le troisième rang du tableau 1, différentes politiques de sécurité peuvent être appliquées, p. ex. dans le cas d’une requête pour modifier un enregistrement de données. Par exemple, la modification du prix d’un article dans le contenu hérité peut être autorisée, mais cette modification peut ne pas être autorisée pour du contenu non hérité. Lorsque la détermination au bloc 330 est négative, indiquant que l’objet de données pour lequel le mécanisme de traitement a été initié au bloc 325 contient du contenu hérité, le serveur 124 poursuit au bloc 340 et continue avec l’application du mécanisme de traitement hérité. Par exemple, dans le cas de la fonction de publication mentionnée ci-dessus, au bloc 340 le serveur 124 poursuit simplement avec la fonction de publication pour le contenu hérité (alors que la fonction de publication de contenu non hérité est supprimée au bloc 335). Ainsi que noté antérieurement, la gestion de requêtes est un cas spécifique d’un mécanisme de traitement initié au bloc 325. Par exemple, la détermination affirmative au bloc 325 peut résulter de la réception d’une requête pour du contenu au bloc 345. La requête reçue au bloc 345 peut inclure un identifiant d’enregistrement et initie l’exécution d’au moins un mécanisme de traitement, tel qu’un mécanisme d’examen de la sécurité pour déterminer s’il faut accorder un accès à l’objet de données. Au bloc 330, le serveur 124 détermine si l’objet de données demandé contient des données héritées ou non héritées et poursuit au bloc 335 ou 340 en fonction de l’indicateur de chaîne de distribution. Une réponse est générée et transmise à la requête au bloc 350 sur la base du mécanisme de traitement sélectionné (qu’il soit ajusté au bloc 335 ou non ajusté au bloc 340). Faisant référence à la FIG. 6, une exécution exemplaire des blocs 345, 325, 330, 335 et 350 est illustrée. En particulier, le moteur 122 du sous-système client 104 envoie une requête 600 au serveur 124 pour l’objet de données « ABCDEF » c.-à-d. l’objet de données 518 montré dans la FIG. 5). À noter en particulier que la requête est reçue au serveur 124 via une interface héritée. Ainsi que mentionné antérieurement, le moteur 122 peut être configuré uniquement pour implémenter la norme GDS plutôt que la norme NDC. Par conséquent, la requête 600 (et effectivement toute requête pour des objets de données générés par le moteur 122) utilise une syntaxe de message, un séquencement et similaire qui sont définis par la chaîne de distribution GPS. Ayant reçu la requête 600 au bloc 345, le serveur 124 initie un processus d’examen de la sécurité (c.-à-d. une détermination affirmative au bloc 325) et poursuit au bloc 330. Au bloc 330, la détermination est affirmative parce que l’objet de données 518 inclut le champ d’indicateur de chaîne de distribution 532 indiquant que l’objet de données 518 contient du contenu non hérité avec lequel le moteur 122 n’est pas compatible (en l’absence de la fonctionnalité exposée dans la présente). Le serveur 124 poursuit donc au bloc 335 et sélectionne un mécanisme de traitement ajusté selon les données de configuration d’ajustement. Dans le présent exemple, le tableau 1 indique qu’aucun ajustement n’est requis pour la récupération et l’affichage d’un objet de données. Dans d’autres modes de réalisation cependant, le tableau 1 peut indiquer qu’un ensemble de politiques de sécurité différentes doit être appliqué pour visionner le contenu non hérité. Au bloc 350, l’objet de données 518 est renvoyé, via l’interface héritée (c.-à-d. en utilisant une syntaxe et un séquencement de message GDS dans cet exemple) au moteur 122. Dans certains exemples, le champ d’indicateur de chaîne de distribution 532 peut être omis et la réponse contient donc une version modifiée 518' de l’objet de données 518. Dans d’autres exemples cependant l’objet de données entier 518 est transmis au bloc 350. Les données de configuration d’ajustement elles-mêmes peuvent inclure des paramètres de configuration indiquant, par exemple, si le champ 532 doit être inclus lors du renvoi de l’objet de données 518 au moteur 122. Les hommes de métier apprécieront que dans certains modes de réalisation, la fonctionnalité d’une quelconque des applications 212, peut être implémentée en utilisant du matériel préprogrammé ou des éléments micrologiciels (p. ex. des circuits intégrés spécifiques aux applications [ASICs], des mémoires à lecture seule programmables et effaçables électriquement [EEPROMs, etc.] ou d’autres composants associés. Un procédé pour un accès basé sur un environnement d’exploitation hérité à des données non héritées, le procédé comprenant : la réception, à un serveur d’intermédiation, d’un objet de données non hérité contenant un contenu non hérité ; la génération d’un objet de données hérité contenant le contenu non hérité, pour stockage dans un répertoire ; le stockage, en association à l’objet de données hérité, d’un indicateur de chaîne de distribution non héritée ; l’ajustement d’un mécanisme de traitement hérité au répertoire conformément à l’indicateur de chaîne de distribution non héritée ; la réception provenant d’un sous-système client, via une interface héritée, d’une demande pour du contenu non hérité ; et en réponse à la demande, la récupération et l’envoi de l’objet de données hérité contenant le contenu non hérité, via l’interface héritée. Le procédé de la revendication 1, dans lequel le stockage d’un indicateur de chaîne de distribution non héritée inclut le stockage de l’indicateur de chaîne de distribution non héritée dans un champ de l’objet de données hérité. Le procédé de la revendication 1 ou de la revendication 2, dans lequel l’ajustement du mécanisme de traitement hérité inclut : le fait de déterminer si l’objet de données hérité est associé à l’indicateur de chaîne de distribution non héritée ; lorsque la détermination est affirmative, la sélection d’un autre mécanisme de traitement distinct du mécanisme de traitement hérité. Le procédé de la revendication 1 ou de la revendication 2, dans lequel l’ajustement du mécanisme de traitement hérité inclut : le fait de déterminer si l’objet de données hérité est associé à l’indicateur de chaîne de distribution non héritée ; lorsque la détermination est affirmative, la suppression du mécanisme de traitement hérité. Le procédé de la revendication 3, comprenant par ailleurs : lorsque la détermination est négative, l’initiation du mécanisme de traitement hérité. Le procédé de la revendication 5, dans lequel le mécanisme de traitement hérité est un mécanisme de publication configuré pour transmettre au moins une portion d’un objet de données hérité à un autre sous-système. Le procédé de l’une quelconque des revendications 1 à 6, dans lequel l’envoi de l’objet de données hérité inclut l’envoi de l’indicateur de chaîne de distribution non héritée. Le procédé de l’une quelconque des revendications 1 à 7, dans lequel l’envoi de l’objet de données hérité inclut l’omission de l’indicateur de chaîne de distribution non héritée. Le procédé de l’une quelconque des revendications 1 à 8, dans lequel l’ajustement du mécanisme de traitement hérité conformément à l’indicateur de chaîne de distribution non héritée inclut l’application d’une restriction d’accès non hérité à la base de données héritée. Un serveur d’intermédiation pour un accès basé sur un environnement d’exploitation hérité à des données non héritées, le serveur d’intermédiation comprenant : une mémoire stockant un répertoire ; une interface de communications ; et un processeur connecté à l’interface de communications et à la mémoire, le processeur étant configuré pour : recevoir, via l’interface de communications, un objet de données non hérité contenant du contenu non hérité ; générer un objet de données hérité contenant le contenu non hérité ; stocker, en association à l’objet de données hérité, un indicateur de chaîne de distribution non héritée ; ajuster un mécanisme de traitement hérité au répertoire conformément à l’indicateur de chaîne de distribution non héritée ; recevoir d’un sous-système client, via une interface héritée, une demande pour du contenu non hérité ; et en réponse à la demande, récupérer et envoyer l’objet de données hérité contenant le contenu non hérité, via l’interface héritée. Le serveur d’intermédiation de la revendication 10, dans lequel le processeur est configuré, afin de stocker l’indicateur de chaîne de distribution non héritée, pour stocker l’indicateur de chaîne de distribution non héritée dans un champ de l’objet de données hérité dans le répertoire. Le serveur d’intermédiation de la revendication 10 ou de la revendication 11, dans lequel le processeur est configuré, dans le but d’ajuster le mécanisme de traitement hérité, pour : déterminer si l’objet de données hérité est associé à l’indicateur de chaîne de distribution non héritée ; lorsque la détermination est affirmative, sélectionner un autre mécanisme de traitement distinct du mécanisme de traitement hérité. Le serveur d’intermédiation de la revendication 10 ou de la revendication 11, dans lequel le processeur est configuré, dans le but d’ajuster le mécanisme de traitement hérité, pour : déterminer si l’objet de données hérité est associé à l’indicateur de chaîne de distribution non héritée ; lorsque la détermination est affirmative, supprimer le mécanisme de traitement hérité. Le serveur d’intermédiation de la revendication 12, dans lequel le processeur est par ailleurs configuré pour : lorsque la détermination est négative, initier le mécanisme de traitement hérité. Le serveur d’intermédiation de la revendication 14, dans lequel le mécanisme de traitement hérité est un mécanisme de publication configuré pour transmettre au moins une portion d’un objet de données hérité à un autre sous-système. Le serveur d’intermédiation de l’une quelconque des revendications 10 à 15, dans lequel le processeur est configuré pour envoyer l’indicateur de chaîne de distribution non héritée avec l’objet de données hérité. Le serveur d’intermédiation de l’une quelconque des revendications 10 à 16, dans lequel le processeur est configuré pour omettre l’indicateur de chaîne de distribution non héritée lors de l’envoi de l’objet de données hérité. Le serveur d’intermédiation de l’une quelconque des revendications 10 à 17, dans lequel le processeur est configuré, dans le but d’ajuster le mécanisme de traitement hérité selon l’indicateur de chaîne de distribution non héritée, pour appliquer une restriction d’accès non héritée à une base de données héritée. Un produit-programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur comprenant : des moyens de programme lisibles par ordinateur pour recevoir, via une interface de communications, un objet de données non hérité contenant du contenu non hérité ; des moyens de programme lisibles par ordinateur pour générer un objet de données hérité contenant le contenu non hérité ; des moyens de programme lisibles par ordinateur pour stocker, en association à l’objet de données hérité, un indicateur de chaîne de distribution non héritée ; des moyens de programme lisibles par ordinateur pour ajuster un mécanisme de traitement hérité au répertoire conformément à l’indicateur de chaîne de distribution non héritée ; des moyens de programme lisibles par ordinateur pour recevoir d’un sous-système client, via une interface héritée, une demande pour du contenu non hérité ; et des moyens de programme lisibles par ordinateur pour, en réponse à la demande, récupérer et envoyer l’objet de données hérité contenant le contenu non hérité, via l’interface héritée, lorsque ledit programme fonctionne sur un serveur d’intermédiation.