Brevet FR2889392A1 — publié le 20070202

L'invention concerne les réseaux de communication Internet, et plus particulièrement l'échange de données entre des terminaux de communication et des modules de services Internet (ou web ) via un réseau de communication Internet. On entend ici par module de services Internet (ou web) ce que l'homme de l'art appelle en anglais web services . Ce type de module se présente généralement sous la forme d'un composant logiciel, implanté dans un serveur d'applications du réseau Internet et chargé d'assurer l'interopérabilité entre des applications de types différents, implantées dans des terminaux de communication ou des serveurs. Il est enveloppé dans une couche de standards dérivés du langage XML ( eXtended Markup Language ) et peut être découvert et invoqué dynamiquement. Par ailleurs, on entend ici par terminal de communication tout équipement de communication, radio ou filaire, fixe ou mobile (ou portable), capable de se connecter à un réseau Internet afin d'échanger des données sous la forme de signaux, soit avec un autre terminal ou équipement de réseau, via leur(s) réseau(x) de rattachement, soit avec son propre réseau de rattachement. Il pourra donc s'agir, par exemple, de téléphones fixes ou mobiles, de serveurs de communication, d'ordinateurs fixes ou portables, ou d'assistants personnels numériques (ou PDA), équipés éventuellement d'un module de communication radio (par exemple cellulaire, WiFi (WLAN pour Wireless Local Area Network ), Bluetooth ou WiMAX). Comme le sait l'homme de l'art, l'accession à un module de services web ne peut se faire qu'au moyen de requêtes de type SOAP (pour Simple Object Access Protocol - protocole simple d'accès à des objets). Ce protocole SOAP est un protocole d'échange inter-applications reposant sur le langage XML et pouvant être transporté au moyen d'un protocole de transport tel que HTTP(S) (pour HyperText Transport Protocol (Secured) - protocole de transport d'hypertexte (sécurisé)). Un appel de service SOAP se présente sous la forme d'un document XML contenant les données échangées entre le client et le serveur. Afin de permettre à des applications embarquées dans des terminaux de communication d'échanger directement des données avec des modules de services web, il a été proposé d'équiper lesdits terminaux de modules assurant une fonction de type proxy SOAP. Cette solution n'est réellement efficace qu'à condition que le terminal de communication dispose d'une capacité de traitement (ou calcul) importante. En effet, le protocole SOAP utilisant le langage XML qui est relativement lourd (ou volumineux), le codage/décodage des données XML qu'il transporte dans des messagesrequêtes nécessite beaucoup de traitements que les ressources (mémoire et/ou capacité de calcul) des petits terminaux de communication, tels que les téléphones mobiles, ne peuvent pas supporter. Afin de permettre aux terminaux de communication d'accéder aux modules de services web, sans avoir à générer et traiter des messages-requêtes de type SOAP, plusieurs solutions ont été proposées. Une première solution, notamment décrite dans le document XP 4387761 de V. Kapsalis et al, OPC-SMS: a wireless gateway to OPC-based data sources , Computer Standards & Interfaces, 24 (2002), p. 437-451, consiste à faire transmettre des messages-requêtes SMS (pour Short Message System ) par des terminaux demandeurs à des adaptateurs chargés de convertir ces requêtes SMS en requêtes SOAP, et réciproquement. Cette solution présente au moins deux inconvénients: d'une part elle ne permet que l'accès à des bases de données de type OPC (pour Object linking and embedding for Process Control ) via des modules de services web, et d'autre part, les messages SMS ne peuvent comporter que du texte, ce qui interdit l'échange de tout autre type de données, et notamment d'images. Une seconde solution consiste à équiper les terminaux de communication d'un navigateur (ou browser ) de type HTML (pour HyperText Markup Language ) ou WAP (pour Wireless Application Protocol ), afin de transmettre des messages- requêtes à un serveur web (ou serveur HTML) chargé d'invoquer les (ou d'accéder aux) modules de services web pour récupérer des données, puis de construire des pages HTML avec ces données récupérées afin de les transmettre aux terminaux requérant. Cette solution présente également au moins deux inconvénients: d'une part elle impose que le terminal de communication soit équipé d'un navigateur HTML ou WAP, ce qui n'est pas toujours le cas (il est fréquent que des petits terminaux comportent une application Java de type midlet qui peut invoquer un serveur web assurant la fonction de navigateur web, mais qui est incapable d'afficher directement des pages HTML), et d'autre part elle équivaut à utiliser des modules de services web qui spécifient comment doivent être présentés les résultats qu'ils fournissent, ce qui n'est évidemment pas leur rôle. Aucune solution connue n'apportant une entière satisfaction, l'invention a donc pour but d'améliorer la situation. Elle propose à cet effet un dispositif de conversion de messages pour un serveur Internet (ou web) d'un réseau de communication Internet comprenant des modules de services Internet (ou web) propres à assurer une interopérabilité entre applications. Ce dispositif de conversion de messages se caractérise par le fait qu'il comprend des moyens de traitement chargés: - lorsqu'ils reçoivent un message-requête de type HTTP(S) provenant d'une application embarquée dans un terminal de communication connecté au réseau Internet et comportant des données représentant au moins une opération devant être effectuée par l'un des modules de services Internet, de convertir ce message-requête en un message-requête de type SOAP, compréhensible par ce module de services Internet, afin qu'il soit transmis à ce dernier, et - lorsqu'ils reçoivent un message de réponse de type SOAP contenant le résultat d'une opération requise (effectuée par le module de services Internet), de constituer un message de réponse de type HTTP(S) à partir du message de réponse de type SOAP reçu, afin qu'il soit transmis au terminal qui a émis le message-requête de type HTTP(S). Le dispositif de conversion de messages selon l'invention peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment: - les messages-requêtes peuvent être par exemple de type HTTP(S) POST ou HTTP(S) GET; - ses moyens de traitement peuvent être chargés d'assurer une fonction d'analyseur syntaxique (ou parser ) de langage XML; - ses moyens de traitement peuvent comprendre, d'une part, des moyens de conversion chargés d'effectuer les conversions de messages-requêtes de type HTTP(S) en messages-requêtes de type SOAP, de constituer les messages de réponse de type HTTP(S) afin qu'ils soient transmis aux terminaux requérant, et d'autre part, des moyens d'interface chargés de transmettre les messages-requêtes de type SOAP aux modules de services Internet qu'ils désignent; - il peut par exemple être agencé sous la forme d'une application Java de type servlet, d'un script de type ASP (pour Active Server Page ) ou d'un script de type CGI (pour Common Gateway Interface Script ). L'invention propose également un serveur Internet équipé d'un dispositif de conversion de messages du type de celui présenté ci-avant. L'invention propose également un terminal de communication comprenant: un module de communication, capable d'établir des connexions avec un réseau Internet comprenant des modules de services Internet assurant une interopérabilité entre applications, - au moins une application embarquée, et - un module de traitement chargé, d'une part, lorsqu'il est sollicité par l'application embarquée, de générer un message-requête de type HTTP(S) comportant i) un entête comprenant une adresse de dispositif de conversion de messages, et un corps comprenant des données représentant au moins une opération devant être effectuée par l'un desdits modules de services Internet, et d'autre part, lorsqu'il reçoit un message de réponse de type HTTP(S) provenant du dispositif de conversion de messages et comportant des données représentatives du résultat de chaque opération requise, effectuée par le module de services Internet, d'extraire ces données afin qu'elles soient utilisées par l'application embarquée. Le terminal de communication selon l'invention peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment: - son module de traitement peut par exemple être chargé de générer des messages-requêtes de type HTTP(S) POST ou HTTP(S) GET; - son module de traitement peut être chargé de générer des corps de messagerequête de type HTTP(S) comportant des premières données représentant au moins une opération devant être effectuée par un module de services Internet et des secondes données représentant au moins un argument associé à une opération représentée par des premières données; -les premières données peuvent par exemple définir au moins une première paire dite nom-valeur comportant la désignation d'une opération (c'est-à- dire le nom du module de services Internet devant effectuer l'opération désignée), et les secondes données peuvent par exemple définir au moins une seconde paire nom-valeur comportant soit la désignation d'un argument de l'opération désignée et la valeur de cet argument désigné lorsque ce dernier est de type simple, soit la désignation d'un argument de l'opération désignée, une suite de désignation d'un élément de type simple et éventuellement d'au moins un élément de type complexe auquel appartient l'élément de type simple désigné, et la valeur de cet élément de type simple désigné lorsque l'argument est de type complexe; - son module de traitement peut par exemple être intégré dans l'application embarquée. D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et du dessin annexé, sur lequel l'unique figure illustre de façon très schématique un réseau Internet auquel sont connectés, d'une première part, un serveur équipé d'un exemple de réalisation de dispositif de conversion de messages selon l'invention, d'une deuxième part, un serveur comportant un module de services web, et d'une troisième part, un terminal de communication selon l'invention. Le dessin annexé pourra non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant. L'invention a pour objet de permettre l'échange de données, par le biais de messages-requêtes et via un réseau de communication Internet, entre des terminaux de communication et des modules de services Internet (appelés web services en anglais, et présentés dans la partie introductive). Dans ce qui suit, on considère à titre d'exemple non limitatif que les terminaux de communication (T) sont des téléphones mobiles. Mais, l'invention n'est pas limitée à ce type de terminal de communication. Elle concerne en effet tout équipement de communication, radio ou filaire, fixe ou mobile (ou portable), capable de se connecter à un réseau Internet afin d'échanger des données sous la forme de signaux avec un autre terminal de communication ou un équipement de réseau. Il pourra donc également s'agir, par exemple, de téléphones fixes, de serveurs de communication, d'ordinateurs fixes ou portables, ou d'assistants personnels numériques (ou PDA), équipés éventuellement d'un module de communication radio (par exemple cellulaire, WiFi (WLAN pour Wireless Local Area Network ), Bluetooth ou WiMAX). Comme cela est illustré sur l'unique figure, la mise en oeuvre de l'invention requiert qu'au moins un terminal de communication (ici un téléphone mobile) T, adapté, au moins un serveur Internet S1, équipé d'un dispositif de conversion de messages D, et au moins un module de services web WS, par exemple implanté dans un autre serveur Internet S2, soient connectés à (ou accessibles par) un réseau Internet RI. On entend ici par réseau Internet ce que l'homme de l'art appelle généralement l'Internet, dont le web (ou toile d'araignée mondiale) constitue un sous-ensemble utilisant le protocole http, et qui est constitué d'une fédération de réseaux ou sous-réseaux à protocole Internet (ou IP). En présence de terminaux de communication T de type téléphone mobile, l'accès au réseau Internet (ou web) RI se fait par l'intermédiaire d'un réseau d'accès radio d'un réseau mobile (ou cellulaire) RM, par exemple de type GSM, ou GPRS/EDGE, ou encore UMTS, lui-même raccordé audit réseau Internet RI. Le téléphone mobile T comporte au moins un module de communication MCX, capable d'établir des connexions avec le réseau Internet RI, au moins une application embarquée A, et au moins un module de traitement MT2. L'application embarquée A est par exemple chargée de rechercher des numéros de téléphone en fonction de noms qui lui sont communiqués par l'utilisateur du téléphone mobile T au moyen d'une interface homme/machine (non représentée). Pour ce faire, elle doit échanger des données avec au moins un module de services web WS dédié, par exemple, à l'obtention de données d'information dans un annuaire téléphonique (tel que l'annuaire français les pages jaunes et/ou blanches ). Ce module de services web WS est donc chargé d'assurer l'interopérabilité entre les applications embarquées A, qui sont du type de celle implantée dans le téléphone mobile T, et une ou plusieurs applications d'annuaire(s) téléphonique(s) implantées dans des serveurs (non représentés), auxquels il est couplé via le réseau Internet RI. Il est ici rappelé que pour dialoguer avec un module de services web WS, il faut utiliser un protocole de type SOAP (pour Simple Object Access Protocol - protocole simple d'accès à des objets). Ce protocole SOAP est un protocole d'échange inter-applications reposant sur le langage XML. En raison de la lourdeur du protocole SOAP (liée à l'utilisation du langage XML), l'invention propose que les terminaux de communication T utilisent des messages-requêtes de type HTTP(S) (pour HyperText Transport Protocol (Secured) - protocole de transport d'hypertexte (sécurisé)) pour transmettre des requêtes, désignant des opérations devant être effectuées par des modules de services web choisis, et pour recevoir des messages de réponse de ces modules de services web. Les modules de services web dialoguant au moyen du protocole SOAP, l'invention prévoit d'utiliser au moins un dispositif de conversion de messages D, d'une part, pour convertir les messages-requêtes de type HTTP(S), qui proviennent des terminaux de communication T, en messagesrequêtes de type SOAP, compréhensibles par lesdits modules de services Internet WS qui en sont les destinataires, et d'autre part, pour constituer des messages de réponse de type HTTP(S) à partir des messages de réponse de type SOAP qu'ils reçoivent des modules de services Internet WS et qui sont destinés aux terminaux de communication T ayant émis lesdits messages- requêtes de type HTTP(S). Afin qu'un téléphone mobile T puisse échanger des messages-requêtes de type HTTP(S) avec un dispositif de conversion de messages D, il comprend un module de traitement MT2. Ce dernier est couplé à une application embarquée A, et peut même, comme cela est illustré sur l'unique figure, faire partie d'une application embarquée A. Ce module de traitement MT2 peut être réalisé sous la forme de circuits électroniques, de modules logiciels (ou informatiques), ou d'une combinaison de circuits et de logiciels. Lorsqu'il est exclusivement réalisé sous la forme de modules logiciels, il peut être éventuellement téléchargé. Lorsque le module de traitement MT2 fait partie d'une application embarquée A, cette dernière peut être également téléchargée dans un terminal de communication T, via un réseau de communication auquel ce dernier est rattaché. Par ailleurs, le module de traitement MT2 peut se présenter sous la forme d'une fonction de type proxy. Chaque fois que l'application embarquée A a besoin d'obtenir des données d'un module de services web WS, le module de traitement MT2 auquel elle est couplée (ou qu'elle comprend), génère un message-requête de type HTTP(S). Ces messages-requêtes se présentent par exemple sous la forme de requêtes HTTP(S) POST ou HTTP(S) GET, bien connues de l'homme de l'art. Un message-requête de type HTTP(S) comprend un entête et un corps. L'entête comprend l'adresse du dispositif de conversion de messages D qui est chargé de transmettre le message-requête après l'avoir converti. Cette adresse est par exemple l'adresse URL (pour Uniform Resource Locator ) du dispositif D. Le corps comprend des données qui représentent au moins une opération qui doit être effectuée par un module de services Internet WS. Par exemple, le corps d'un message-requête de type HTTP(S) comprend des premières données représentatives d'une opération devant être effectuée par un module de services Internet WS et des secondes données qui représentent au moins un argument associé à cette opération. A titre d'exemple non limitatif, les premières données peuvent constituer une première paire dite nom-valeur comportant la désignation de l'opération, c'est-à-dire le nom du module de services Internet WS devant effectuer l'opération désignée. Une telle paire nom-valeur s'écrit par exemple: opération= . Les secondes données peuvent également constituer une ou plusieurs secondes paires nom-valeur dont le contenu varie selon que l'argument, associé à l'opération définie par les premières données, est de type simple ou complexe. Lorsque l'argument est de type simple, les secondes données constituent une seconde paire nom-valeur qui s'écrit par exemple: = . Lorsque l'argument est de type complexe, il est constitué d'un jeu d'au moins deux éléments possédant chacun un nom et un type qui peut être à son tour simple ou complexe. Par conséquent, les secondes données constituent une ou plusieurs secondes paires nom-valeur qui s'écrivent chacune, par exemple: . = ou . . = ou . . . = . Bien entendu, il existe de nombreuses autres possibilités d'écriture. Ainsi, le signe . qui sépare les noms pourrait être un autre signe ou caractère. Une fois que le module de traitement MT2 a généré un message-requête de type HTTP(S), il le fait transmettre par le module de communication MCX du téléphone mobile T au dispositif D dont l'adresse URL est indiquée dans l'entête, via le réseau Internet RI (flèche F1). Lorsque le serveur Internet S1, dans lequel est implanté le dispositif de conversion de messages D, reçoit un message-requête de type HTTP(S) en provenance d'un module de traitement MT2, implanté dans un téléphone mobile T, il le transmet audit dispositif D afin qu'il procède à sa conversion. Ce dispositif de conversion de messages D comprend un module de traitement MT1 chargé de convertir chaque message-requête de type HTTP(S) reçu (et généré par un module de traitement MT2) en un message-requête de type SOAP, compréhensible par le module de services Internet WS qui est désigné dans le corps de ce message-requête de type HTTP(S). Pour ce faire, il extrait les données qui constituent le corps du messagerequête de type HTTP(S), puis détermine parmi ces données le nom du module de services web WS qui en est le destinataire, puis intègre les données extraites dans un message-requête de type SOAP, après les avoir codées en données XML, afin qu'il soit transmis à destination du module de services web WS désigné, via le réseau Internet RI. La partie du traitement relative à la conversion HTTP(S)/SOAP, et réciproquement, peut par exemple être assurée par un module de conversion MCV. Afin de procéder à l'encodage (et au décodage) XML des données extraites d'un message-requête de type HTTP(S) (ou SOAP), le module de conversion MCV assure préférentiellement la fonction d'analyseur syntaxique XML (ou XML parser ). Le module de conversion MCV extrait de la requête HTTP chaque argument qu'elle contient. Tout d'abord elle extrait l'argument nommé opération afin de savoir quelle opération du service web est invoquée, puis elle extrait les arguments nécessaires à l'invocation de cette opération. La transmission du message-requête de type SOAP peut se faire au moyen d'un module d'interface MI, couplé au module de conversion MCV, et qui se présente par exemple sous la forme d'un équipement de type proxy de module de services web (ou web service proxy ). Le proxy d'un service web est un module qui est chargé de la communication avec le service web. Il encode les données qui sont envoyées aux services web et décode les données des réponses fournies par ces services. Ce type d'équipement, bien connu de l'homme de l'art, peut être indépendant du module de traitement MT1, et donc externe à celui-ci, contrairement à ce qui est illustré sur l'unique figure. Par conséquent, on peut envisager de coupler, au sein du serveur Internet S1, un dispositif D à un module d'interface MI. Lorsqu'un serveur Internet S2 reçoit un message-requête de type SOAP provenant d'un dispositif D, via le réseau Internet RI (flèche F2), il détermine le module de services web WS qui en est le destinataire afin de le lui transmettre. Le module de services web WS effectue alors l'opération qui est définie (ou désignée) par les données contenues dans le message-requête de type SOAP reçu. Puis, il génère un message de réponse de type SOAP contenant des données XML représentatives du résultat de l'opération désignée, à destination du module de traitement MT2 demandeur, via le dispositif de conversion de messages D. Ce message de réponse de type SOAP est transmis au dispositif D destinataire par le serveur Internet S2, via le réseau Internet RI (flèche F2). Lorsque le serveur Internet S1 reçoit le message de réponse de type SOAP, il le transmet au dispositif D destinataire, et plus précisément à son module d'interface MI, qui le transmet ensuite au module de traitement MT1 afin qu'il constitue un message de réponse de type HTTP(S) à partir du message de réponse de type SOAP reçu. Plus précisément, le module de conversion MCV du module de traitement MT1 extrait les données XML contenues dans le message de réponse de type SOAP reçu afin de les décoder grâce à sa fonction d'analyseur syntaxique XML. Puis, il intègre les données décodées dans le corps d'un message de réponse de type HTTP(S) . HTTP étant synchrone, la connexion entre le terminal et le serveur est présente (ou active) tant que la requête n'est pas terminée; c'est-à-dire tant que la réponse n'a pas été envoyée ou que la connexion n'a pas été terminée par des mécanismes de temporisation (ou timeout ). Le dispositif de conversion de messages D selon l'invention, et notamment son module de traitement MT1 (qui comprend éventuellement le module d'interface MI), peut être réalisé sous la forme de circuits électroniques, de modules logiciels (ou informatiques), ou d'une combinaison de circuits et de logiciels. Le dispositif de conversion de messages D peut par exemple se présenter sous la forme d'une application Java de type servlet, ou d'un script de type ASP (pour Active Server Page ) ou encore d'un script de type CGI (pour Common Gateway Interface Script ). Le message de réponse de type HTTP(S), qui est généré par le dispositif D, est transmis au module de traitement MT2 destinataire par le serveur Internet S1, via le réseau Internet RI et, ici, le réseau mobile RM auquel est rattaché le téléphone mobile T qui le contient (flèche F3). Lorsque le module de traitement MT2 reçoit le message de réponse de type HTTP(S), il en extrait les données qui représentent le résultat de chaque opération définie dans un message-requête de type HTTP(S) précédemment transmis et effectuée par un module de services Internet WS, afin de les communiquer à l'application embarquée A à laquelle il est couplé (ou qui le contient). Cette application embarquée A peut alors utiliser ces données de résultat, par exemple en les affichant sur l'écran du téléphone mobile T après les avoir éventuellement intégrées dans un masque de présentation spécifique. L'invention offre un certain nombre d'avantages, parmi lesquels: -un codage/décodage XML transféré dans un serveur qui dispose de capacités de calcul importantes, contrairement aux petits terminaux de communication, - un accès quasi-immédiat aux modules de services web pour des terminaux de communication ne disposant pas de pile de protocole SOAP, - une présentation des résultats des recherches (objets des messagesrequêtes de type HTTP(S)) définie et effectuée par l'application embarquée, contrairement aux solutions de l'art antérieur utilisant des navigateurs HTML ou WAP. L'invention ne se limite pas aux modes de réalisation de dispositif de conversion de messages et de terminal de communication décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ciaprès. REVENDICATIONS 1. Dispositif de conversion de messages (D) pour un serveur Internet (Si) d'un réseau de communication Internet (RI) comprenant des modules de services Internet (WS) propres à assurer une interopérabilité entre applications, caractérisé en ce qu'il comprend des moyens de traitement (MT1) agencés, en cas de réception d'un message-requête de type HTTP(S) provenant d'une application (A) embarquée dans un terminal de communication (T) connecté audit réseau Internet (RI) et comportant des données représentant au moins une opération devant être effectuée par l'un desdits modules de services Internet (WS), pour convertir ce messagerequête en un message-requête de type SOAP, compréhensible par ledit module de services Internet (WS), afin qu'il soit transmis à ce dernier, et à réception d'un message de réponse de type SOAP contenant le résultat de chaque opération requise, effectuée par ledit module de services Internet (WS), pour constituer un message de réponse de type HTTP(S) à partir dudit message de réponse de type SOAP reçu afin qu'il soit transmis au terminal (T) ayant émis ledit message-requête de type HTTP(S). 2. Dispositif selon la revendication 1, caractérisé en ce que lesdits messages-requêtes sont de type HTTP(S) POST ou HTTP(S) GET. 3. Dispositif selon l'une des revendications 1 et 2, caractérisé en ce que lesdits moyens de traitement (MT1) sont agencés de manière à assurer une fonction d'analyseur syntaxique de langage XML. 4. Dispositif selon l'une des revendications 1 à 3, caractérisé en ce que lesdits moyens de traitement (MT1) comprennent i) des moyens de conversion (MCV) propres à effectuer lesdites conversions de messages- requêtes de type HTTP(S) en messages-requêtes de type SOAP, et à constituer lesdits messages de réponse de type HTTP(S) afin qu'ils soient transmis aux terminaux (T) requérant, et ii) des moyens d'interface (MI) propres à transmettre lesdits messages-requêtes de type SOAP aux modules de services Internet (WS) qu'ils désignent. 5. Dispositif selon l'une des revendications 1 à 4, caractérisé en ce qu'il est agencé sous la forme d'un équipement choisi dans un groupe comprenant une application Java de type Servlet, un script de type ASP et un script de type CGI. 6. Serveur (Si) pour un réseau de communication Internet, caractérisé en ce qu'il comprend un dispositif de conversion de messages (D) selon l'une des revendications précédentes. 7. Terminal de communication (T) comprenant un module de communication (MCX), propre à établir des connexions avec un réseau de communication Internet (RI) comprenant des modules de services Internet (WS) propre à assurer une interopérabilité entre applications, et au moins une application embarquée (A), caractérisé en ce qu'il comprend en outre un module de traitement (MT2) agencé, d'une part, lorsqu'il est sollicité par ladite application embarquée (A), pour générer un message-requête de type HTTP(S) comportant i) un entête comprenant une adresse de dispositif de conversion de messages (D) selon l'une des revendications 1 à 5, et ii) un corps comprenant des données représentant au moins une opération devant être effectuée par l'un desdits modules de services Internet (WS), et d'autre part, lorsqu'il reçoit un message de réponse de type HTTP(S) provenant dudit dispositif de conversion de messages (D) et comportant des données représentatives du résultat de chaque opération requise, effectuée par ledit module de services Internet (WS), pour extraire ces données afin qu'elles soient utilisées par ladite application embarquée (A). 8. Terminal de communication selon la revendication 7, caractérisé en ce que ledit module de traitement (MT2) est agencé pour générer des messagesrequêtes de type HTTP(S) POST ou HTTP(S) GET. 9. Terminal de communication selon l'une des revendications 7 et 8, caractérisé en ce que ledit module de traitement (MT2) est agencé pour générer des corps de message-requête de type HTTP(S) comportant des premières données représentant au moins une opération devant être effectuée par l'un desdits modules de services Internet (WS) et des secondes données représentant au moins un argument associé à une opération représentée par des premières données. 10. Terminal de communication selon la revendication 9, caractérisé en ce que lesdites premières données définissent au moins une première paire dite nom-valeur comportant une désignation d'opération à effectuer, et lesdites secondes données définissent au moins une seconde paire nomvaleur comportant soit une désignation d'argument de l'opération désignée et une valeur pour cet argument désigné lorsque ledit argument est de type simple, soit une désignation d'argument de l'opération désignée, une suite de désignation d'un élément de type simple et éventuellement d'au moins un élément de type complexe auquel appartient ledit élément de type simple désigné, et une valeur pour cet élément de type simple désigné lorsque ledit argument est de type complexe. 11. Terminal de communication selon l'une des revendications 7 à 10, caractérisé en ce que ledit module de traitement (MT2) est intégré dans ladite application embarquée (A).