Brevet FR3100908A1 — publié le 20210319

Procédé de communication via une API, comportant les étapes de : - produire une description structurelle (14) de chaque version de la transaction ; - produire une signature (13) qui est représentative de la description structurelle de la version ; - définir et sauvegarder un objet (11) comportant la signature (13) et la description structurelle (14) de la version ; - faire émettre, par une entité logicielle émettrice (E), un message courant d’une version courante de la transaction, ainsi qu’une signature courante de la version courante ; - faire recevoir, par une entité logicielle réceptrice (R), le message courant et la signature courante ; - faire identifier, par l’entité logicielle réceptrice, un objet ayant une signature identique à la signature courante, et décoder le message courant en utilisant la description structurelle dudit objet. FIGURE DE L’ABREGE : Fig.4 Procédé de communication entre des entités logicielles via une API L’invention concerne le domaine des interfaces de programmation applicatives (API). ARRIERE PLAN DE L’INVENTION Deux entités logicielles, localisées ou non dans un même équipement « physique », peuvent échanger des informations à travers un médium commun via une interface de programmation applicative (API). L’API comprend un ensemble de transactions qui chacune met en œuvre des échanges de messages. Chaque message échangé est structuré de manière adaptée au transport de l’information associée au message (description des champs, type des champs, etc.). Au gré du développement de nouvelles versions des transactions dans les différentes entités logicielles, il est possible que la structure de ces messages évolue en fonction de nouveaux besoins. Ces évolutions sont rarement synchronisées de part et d’autre de la liaison. Une entité logicielle qui reçoit un message décode ledit message au travers de la description de structure qui a été définie dans sa propre version de la transaction de l’API. Le type de structure de données considéré ici est un ensemble de champs qui peuvent posséder chacun une valeur. C’est la valeur contenue dans un champ donné qui permet un traitement spécifique suite à l’utilisation de l’API. Chaque champ est primitivement typé. Cela signifie que chaque champ admet un type de valeur, par exemple un entier, une chaîne de caractères ou une autre structure. On peut considérer qu’un tableau typé est une suite de champs du type donné. De plus, comme un type peut être utilisé plusieurs fois, la structure est un ensemble ordonné de champs. On considère aussi que le codage et le décodage des structures de données sont basés uniquement sur leur type qui est décrit entre parenthèses. Cette considération limite le nombre de types possibles et retire la sémantique de chaque champ. Cette considération est à prendre en compte dans la mesure où le nombre de champs différents possibles n’est pas limité. Ainsi, lorsqu’un message reçu par une entité logicielle a été encodé dans une version de la transaction qui n’est pas implémentée dans l’entité, il en résulte une erreur de communication pouvant aboutir à un message indécodable, ou à une interprétation erronée du message. Bien sûr, cette problématique se présente principalement lorsque les deux entités logicielles appartiennent à deux équipements distincts susceptibles de connaître des évolutions distinctes. Par exemple, lorsqu’un premier équipement demande à un deuxième équipement ses caractéristiques, le message mis en œuvre peut être : ID_request , et la réponse : ID_answer . On considère dans cet exemple que le message ID_request requiert seulement en retour une valeur correspondant à ID . Dans cet exemple, on prend l’hypothèse que le deuxième équipement, dans sa version logicielle, encode sa réponse dans une structure constituée de champs typés comme suit : (entier) ID (chaine de caractères) Name (entier) Maxbandwidth (entier) Latency Le premier équipement, dans sa version logicielle, attend une structure de type : (entier) ID (chaine de caractères) Name (entier) Latency Ainsi, le premier équipement envoie au deuxième équipement la donnée contenant la valeur correspondant à ID . Le deuxième équipement, afin de répondre, construit sa réponse avec sa structure, qui comprend donc ID , Name , Maxbandwidth et Latency . Le deuxième équipement envoie alors sa réponse. À la réception de la réponse, le premier équipement décode la donnée. Les valeurs associées aux champs ID et Name correspondent et sont cohérentes. Par contre, le décodage du champ Latency est en réalité la valeur du champ Maxbandwidth de la structure connue du deuxième équipement. La compréhension du message est par conséquent erronée et peut donc conduire à un mauvais traitement de l’information. Un certain nombre d’approches ont été envisagées pour garantir la compatibilité des versions de transaction utilisées par les deux entités logicielles. Il est possible de caractériser chaque version de la transaction par un numéro de version qui est contrôlé au moment de la réception du message par l’autre entité logicielle. Cette solution peut toutefois conduire à des incompatibilités liées à des développements faits de manière non homogène. Il est aussi possible de signer et de certifier les versions utilisées. Toutefois, deux versions jugées incompatibles ne peuvent pas communiquer, alors même que certains de leurs messages sont compatibles. On a par ailleurs envisagé de transmettre la description de la structure de chaque message préalablement à la transmission du message lui-même, pour s’assurer de la compatibilité des versions. Cette approche est très lourde du fait du grand nombre de messages au vu de leur usage réel. Le document US 9,516,130 B1 décrit un procédé de communication entre deux versions d’une transaction d’une API au travers d’un module logiciel supplémentaire de cache qui permet de réordonner les paramètres pour les rendre compatibles entre les entités logicielles. Ce procédé nécessite le développement et l’utilisation du module logiciel supplémentaire de cache et est donc complexe et coûteux à mettre en œuvre. Il existe sous Linux un bus de communication nommé uBus qui permet à des services de proposer des objets structurés et strictement définis. Les données peuvent être demandées ou modifiées au travers d’une requête qui est un message structuré à envoyer. Afin de savoir comment structurer le message pour effectuer la requête, la structure peut être demandée au bus de communication. Selon le retour de cette demande, il est possible d’adapter le traitement par rapport à la description. Ce mécanisme permet une compatibilité entre les acteurs, mais nécessite d’embarquer un « traducteur » adaptatif de structures de données. De plus, il est nécessaire de charger et d’analyser la description avant de commencer à échanger des données utiles. OBJET DE L’INVENTION L’invention a pour objet d’assurer de manière simple, peu coûteuse et efficace la compatibilité des échanges de messages entre deux entités logicielles communiquant via une API. Il sera fait référence au dessin annexé suivant : la figure 1 représente un tableau qui associe des types de base et des caractères ; la figure 2 représente un message initiateur d’une transaction ; la figure 3 représente un message de réponse de la transaction ; la figure 4 représente une table de versions d’une entité logicielle ; la figure 5 représente une table de versions d’une entité logicielle émettrice qui communique avec une entité logicielle réceptrice ; la figure 6 représente une table de versions de l’entité logicielle réceptrice ; la figure 7 représente le dialogue entre l’entité logicielle émettrice et l’entité logicielle réceptrice ; la figure 8 représente la table de versions mise à jour de l’entité logicielle réceptrice ; la figure 9 représente un dialogue entre deux entités logicielles émettrices et une entité logicielle réceptrice ; la figure 10 représente la table de versions mise à jour de l’une des deux entités logicielles émettrices. Procédé de communication entre des entités logicielles via une interface de programmation applicative (API) qui comporte au moins une transaction (12), le procédé de communication comprenant une phase de configuration comportant les étapes, mises en œuvre dans chaque entité logicielle et pour chaque version de la transaction implémentée par ladite entité logicielle, de : - produire une description structurelle (14) de la version, qui comporte une structure globale de chaque message pouvant être échangé dans la version de la transaction ; - produire une signature (13) qui est représentative de la description structurelle de la version ; - définir et sauvegarder un objet (11) comportant la signature (13) et la description structurelle (14) de la version ; le procédé de communication comprenant en outre une phase d’émission comportant l’étape de : - faire émettre, par une entité logicielle émettrice (E), un message courant d’une version courante de la transaction, ainsi qu’une signature courante de la version courante ; et une phase de réception comprenant les étapes de : - faire recevoir, par une entité logicielle réceptrice (R), le message courant et la signature courante ; - faire identifier, par l’entité logicielle réceptrice, un objet ayant une signature identique à la signature courante, et décoder le message courant en utilisant la description structurelle dudit objet. Procédé de communications selon la revendication 1, dans lequel, au cours de la phase de configuration, la signature est obtenue en mettant en œuvre sur la description structurelle de la version une fonction de hachage qui est identique pour toutes les versions de la transaction. Procédé de communication selon la revendication 1, dans lequel la signature courante est transmise à l’entité logicielle réceptrice en étant incluse dans le message courant. Procédé de communication selon la revendication 1, dans lequel, au cours de la phase de configuration, chaque entité logicielle stocke les objets dans une table de versions (10). Procédé de communication selon la revendication 4, dans lequel, au cours de la phase de configuration, l’entité logicielle émettrice (E) et l’entité logicielle réceptrice (R) échangent leur table de versions (10), de sorte que l’entité logicielle émettrice connaît et utilise les versions de la transaction implémentées par l’entité logicielle réceptrice. Procédé de communication selon la revendication 4, dans lequel la table de versions (10) de l’entité logicielle émettrice comporte au moins un identifiant de privilège qui identifie une version privilégiée (17) de la transaction, associée à une première entité logicielle réceptrice (18), que l’entité logicielle émettrice utilise en priorité lorsque l’entité logicielle émettrice communique avec la première entité logicielle réceptrice. Procédé de communication selon la revendication 6, dans lequel la table de versions de l’entité logicielle émettrice comporte au moins un identifiant par défaut qui identifie une version par défaut (19) de la transaction, que l’entité logicielle émettrice utilise en priorité lorsque l’entité logicielle émettrice communique avec une deuxième entité logicielle réceptrice qui n’est pas associée à une version privilégiée dans la table de versions de l’entité logicielle émettrice. Procédé de communication selon l’une des revendications précédentes, dans lequel chaque objet (11) comprend, outre la signature et la description structurelle de la version associée audit objet, un indicateur de préférence (15) permettant d’évaluer et de comparer entre elles plusieurs versions pour sélectionner une version optimisée permettant d’optimiser des performances de la communication. Procédé de communication selon la revendication 2, dans lequel la phase de configuration comprend une étape au cours de laquelle la fonction de hachage est négociée entre les entités logicielles. Procédé de communication selon l’une des revendications précédentes, dans lequel la phase de configuration comprend l’étape de définir un ensemble fini de types de base destinés à définir les structures globales des messages, et à associer un identifiant de type à chaque type de base, de sorte que la représentation structurelle de chaque version comporte une chaîne desdits identifiants de type. Procédé de communication selon la revendication 10, dans lequel chaque identifiant de type est un caractère distinct. Procédé de communication selon la revendication 11, dans lequel la structure globale d’au moins un message comprend au moins une structure de données imbriquées. Procédé de communication selon la revendication 12, dans lequel l’ensemble fini de types de base comprend au moins un type de base destiné à délimiter la structure de données imbriquées. Equipement comportant une entité logicielle agencée pour communiquer via une interface de programmation applicative (API) qui comporte au moins une transaction, l’entité logicielle comprenant une table de versions produite par la mise en œuvre des étapes de la phase de configuration du procédé de communication selon l’une des revendications précédentes, l’entité logicielle étant en outre agencée pour mettre en œuvre la phase d’émission et/ou la phase de réception du procédé de communication selon l’une des revendications précédentes. Programme d’ordinateur comprenant des instructions qui conduisent l’équipement selon la revendication 14 à exécuter la phase de configuration, ainsi que la phase d’émission et/ou la phase de réception du procédé de communication selon l’une des revendications 1 à 13. Support d'enregistrement lisible par ordinateur, sur lequel est enregistré le programme d’ordinateur selon la revendication 15.