Brevet FR2934099A1 — publié le 20100122

Procédé d'accès des ressources du Web serveur mettant en oeuvre un tel procédé La présente invention se rapporte à procédé d'accès à des ressources du Web ainsi qu'a un serveur mettant en oeuvre ce procédé. Une application majeure du réseau [Men& est le Web, également dé nommé � World Vide Web �, wvvtAt � OU la � Talle �. Plus précisément, le Web est un ensemble de ressources accessibles, via le réseau Intemet, à un terminal éqUipé d'Un navigateur pouvant afficher des données transmises par ces ressources du Web. Pour cela, ces ressources sont stockées dans des serveurs connectes au réseau lnternet et utilisant un même protocole de transport de données que les navigateurs accédant à ces ressources. A titre d'exemple; le protocole HTTP û pour � HyperText Transfer Prote-COL � en anglais û a ainsi etc développé dans le réseau Interne Ce protocole permet notamment la transmission de requêtes ou de commandes Val- 15 tees par les serveurs du Wei). Typiquement. le protocole HTTP permet d'émettre une commende telle que la commande s GET �, qui entraîne une description des ressources du Web identifiées dans la commande, ou telle que la commande POST �, qui permet d'obtenir le traitement de données d'entrée, transmises dans la 20 commande, par des ressources du Web également identifiées dans la commande. Par ailleurs, des adresses sont attribuées à ces ressources du Web afin de permettre la transmission de requêtes à travers le réseau Intemet. Plus précisément, cette adresse est dénommée URL pour � Uniform Ressource 25 Locator � en anglais. Elle indique un nom de domaine, une localisation dans le réseau Intemet ou un réseau à partir duquel il est possible d'accéder aux ressources associées à cet URI. Ueccès aux ressources dU Web étant ainsi assuré, il est égelement nécessaire de munir un terminal Web de moyens permettant d'afficher données issues de ces ressources afin que les utilisateurs puissent suivre leurs accès au Web. De fait, des formats ont été développés pour harmoniser la présentation de données issues d'applications du Web. A titre d'exemple, le format XML, pour � extensible Markup Language � en anglais, est largement utilisé sur le Web, Ce format établit des règles d'affichage de données au moyen de balises structurant la présentation de données d'entrée ù fournies aux ressources ù ou de sorties ù fournies par ces ressources. Le format XML est compatible avec les langages applicatifs codant, de 10 façon pratique, le traitement des données. A titre d'exemple, on peut citer: le langage HTML, pour � HyperText Markep Language � en anglais, dédié notamment à la représentation de pages Web. le langage SOAP, pour � Simple Object Access Protocol � en anglais, dédié notamment à l'échange de données entre serveurs ou systèmes du 15 Web. le langage RSS, pour � Really Simple Syndication � en anglais, dédié notamment a la diffusion d'alertes, de nouvelles ou de lire sur le Web. Pour illustrer les différents éléments introduits ci-dessus, la figure 1 représente des ressources 2 du réseau internet 3 auxquelles accèdent des 20 terminaux 4. A cet effet ces terminaux 4 sont munis de navigateurs utilisant le protocole HTTP pour émettre des requêtes comprenant au moins une donnée d'entrée 6 telle qu'une adresse URL. Une requête comprenant cette donnée d'entrée 6 est transmise par le 25 réseau 1nternet 3 jusqu'aux ressources 2 qui traitent alors cette donnée d'entrée 6 pour générer une donnée de sortie 8 codée dans le langage ap- plicatif de la ressource utilisée. AInsi, en considérant que la donnée d'entrée 6 est un URL correspondant une page Web, la don nec de sortie 8 peut être cette page Web codée 30 dans le langage HTML Cette dernière peut alors être affichée sur les terminaux 4 lorsque le navigateur associé â ces terminaux 4 prend en compte le langage applicatif HTML. La présente invention résulte de la constatation qu'il existe de nombreuses ressources sur le Web mettant en oeuvre différents langages applicatIfs. Dés lors, les utilisateurs du Web sont confrontés a te nécessité d'équiper leurs terminaux d'outils logiciels spécifiques à chaque langage applicatif pour accéder à ces différentes ressources, ce qui rend l'utilisation du Web complexe. II convient de noter que ce problème d'accès hétérogène se présente indépendamment de la nature des applications considérées du Web comme la consultation d'un site ou la réalisation d'un service à travers le Web. En effet, la réalisation d'un service Web requiert d'un URL --comme pour l'accès à un site Web û et l'indication d'autres données d'entrée - comme un identifiant ou un numéro de carte de paiement û qui doivent correspondre au langage applicatif du site hébergeant le service considéré. La présents invention vise à remédier à ce problème en fournissant un procédé qui permet eeccéder à des ressources du Web de façon simple et indépendante du langage applicatif mis en oeuvre par les ressources requises. 'est pourquoi, la présente invention concerne un procédé d'accès à des ressources du Web destinées a recevoir une donnée d'entrée émise par un terminal, selon un protocole de communication standard, pour déterminer une valeur de sortie codée selon un langage applicatif conforme à un format déterminant des règles de présentation de données, caractérisé en ce qu'il comprend les étapes suivantes: - l'étape pour le terminal de transmettre à un serveur d'accès des données d'entrée comprenant notamment une adresse de ces ressources du Web� - retape pour le serveur de générer une séquence d'accès successifs aux ressources du Web à partir de ces données d'entrée, - l'étape de mettre en oeuvre automatiquement cette séquence d'accès en-30 tre le serveur et les ressources du Web en effectuant : i) l'émission par le serveur, selon le protocole de communication standard, d'une donnée d'entrée utilisée par les ressources pour générer une donnée de sortie, transmise au serveur, codée selon le langage applicatif conforme au format d'affichage, il) l'extraction par le serveur de la donnée de sortie transmise par les ressources en utilisant le format d'affichage de données pour identifier cette donnée de sortie dans la transmission émise par les ressources, - l'étape pour le serveur de transmettre les données de sortie ainsi extraites vers le terminal selon le protocole de communication standard. Grâce à l'Invention, il est possible d'accéder à des ressources mettant en oeuvre différents langages applicatifs à partir d'un seul type de procédé 10 d'accès à ces ressources Web. En effet, l'invention permet à un terminal de s'affranchir du langage applicatif propre à des ressources pour accéder à ces dernières puisqu'un serveur conforme à l'invention effectue une fonction de passerelle entre ce terminal et les ressources. 15 De fait, le serveur communique avec le terminal selon un protocole de communication standard tant pour recevoir de ce dernier les données d'entrée nécessaires pour accéder aux ressources que pour transmettre à ce dernier les données de sortie issues de ces accès. Parallèlement le serveur utilise également ce protocole de communica- 20 tien pour transmettre aux ressources ces données d'entrée et le format structurant la présentation de données pour extraire, des transmissions reçues des ressources, les données de sorties requises par le terminal. Dans une réalisation, le procédé comprend l'étape de transmettre au serveur une définition des ressources indiquant une adresse de ces res- 25 sources et des Moyens de mise en oeuvre de différentes opérations devant être suivies par le serveur pour accéder à un service via ces ressources. Selon une réalisation, les moyens de mise en oeuvre comprennent la description d'une séquence d accès successifs qui doivent être effectués par le serveur auprès des ressources considérées pour obtenir le service. 30 Dans une réalisation, les moyens de mise en oeuvre comprennent une liste de paramètres devant être fournis par un utilisateur du service pour être utilisés comme données d'entrée par le serveur lors de ses accès aux ressourcee. Selon une réalisatioh, les moyens de mise en oeuvre comprennent un formulaire d'URL permettant de générer un URL de la ressource à requérir pour chaque accès en complétant ce formulaire URI.. à l'aide d'une donnée d'entrée. Dans une réalisation, les moyens de mise en oeuvre comprennent un formulaire HTTP permettant de déterminer une requête HTTP à transmettre aux ressources pour chaque accès en complétant ce formulaire HTTP à laide d'une donnée d'entrée. Selon une réalisation, le format déterminant des règles de présentation IO de données est le protocole HTTP û pour � HyperText Transfer Protocol � en anglais. Dans une réalisation, l'accès aux ressources est effectué à l'aide de commande du type � GET �, entraînant une description des ressources du Web identifiées dans la commande, ou de commande du type � POST �, 15 entraînant le traitement de données d'entrée, transmises dans la commande, par des ressources du Web également identifiées dans la commande. Selon une réalisation, le langage applicatif codant les données de sortie est un des langages suivants 20 - le langage HTML, pour � HyperText Markup Language � en anglais, dédié notamment à la représentation de pages Web. - le langage SOAP, pour � Simple Object Aoeess Protocol � en anglais, dédié notamment à l'échange de données entre serveurs ou systèmes du Web. 2.5 - le langage RSS, pour � Really Simple Syndication � en anglais, dédié notamment à la diffusion d'alertes, de nouvelles ou de liste sur le Web. Dans une réesation, le format de présentation des données est un for- mat à balises tel que le format XML. L'invention concerne également un serveur d'accès à des ressources du 30 Web destinées à recevoir une donnée d'entrée ém{se par un terminal, selon un protocole de communication standard, pour déterm,nei une donnée de sortie codée selon un langage applicatif conforme à un format déterminant des règles de présentation de données, caractérisé en ce qu'il comprend des moyens pour : recevoir d'un terminal des données d'entrée comprenant notamment une adresse de ressources du et), - générer une séquence d'accès successifs aux ressources du Web à partir de ces données d'entrée. - mettre en oeuvre automatiquement cette séquence d'accès entre le serveur et les ressources du Web en effectuant : i) rémission par le serveur, selon le protocole de communication IO standard, d'une donnée &entrée utilisée par les ressources pour générer une donnée de sortie, transmise au serveur, co 'e selon le langage applicatif_ conforme au format d'affichage, ii) l'extraction par le serveur de la donnée de sortie transmise par les ressources en utilisant le format d'affichage de données pour identifier cette 15 donnée de sortie dans la transmission émise par les ressources, - transmettre les données de sortie ainsi extraites vers le terminal selon le protocole de communication standard, La présente invention sera mieux comprise à la lumière de la description effeduée ci-dessous, à titre illustratif et non limitatif, d'une réalisation de 20 l'invention faite en référence aux figures ci-jointes sur lesquels - la figure 1, déjà décrite, illustre laccès à des ressources du Web se-Ion un procédé conforme à l'art antérieur, - la figure 2 illustre l'aCCèS s des ressources du Web selon un procédé conforme à l'invention, 25 - la figure 3 représente schématiquement la structure d'un serveur comprenant des moyens pour mettre en oeuvre l'invention, et la figure 4 est un diagramme représentant les étapes mises en oeuvre par un procédé conforme à l'invention. En référence à la figure 2, un terminal 20 peut accéder s des ressources .30 22 pour obtenir des données de sorties 26 à partir de données d'entrée 24 indépendamment du langage applicatif utilisé par ces ressources 22. De i conformément à l'invention, les valeurs d'entrées 24 sont transi, mises à un serveur 28 selon un protocoie de communication standard tel ÿuÿ protocole HTTParl suite, %{rve 28 génère une séquence 25 d accès successifs 3 aux ressources, chaque accès utilisant différentes valeurs Centrée egénérant une valeur de sortie transmise selon le langage applicatif conforme à l'application mise en oeuvre pari les resce Par exemple, ce langage ap�)Ç $ peut Cep langage HTML pour l'accès à des pages Web OU le langage SOAP pour l'accès à' es comman 10 des de serveur. Un traitement interne 27 au serveur 28 permet d'identifier les données de sortie transmises par eees ressources suite à ces accès 25. Pou' ce faire, le serveur 28 utilise des règles de codages prédéterminées propres à un format déterminant des règles de présentation de données. 15 Dans cet exemple, ces règles de codage respectent un forma à balises tel qrmaXML la localisation des données de sortie est facilitée par Une déclaration préalable du prestataire de spi \e comme décrit ultérieurement A partir d'une donnée de sortie, le serveur 28 peut déterminer une d0 20 née eeeée pour un accès ultérieur aux ressources 22, Ainsi, l'invention permet d'accéder à des ressources requérant la transmission de plusieurs données d'entrées. En référence \ figure 3 e décrite la structure d'un serveur 30 conforme à l'invention. Un tel serveur 30 comprend un registre 32 de décla- 25 rations de services qui comprend des moyens pour r ois et mémoriser des reques 34 déclarant des services dont les ressources sont t destinées a être accessibles via le serveur 30. A cet effet, les requêtes 34 doivent ) ' ue ne a esse des ressoc - par exemple sous la forme d'un nom du sce associé à ces ressources - 30 et des m oyeés de mise en eu e des différentes op é tiens devant effectuées parle serveur 30 pour accéder à ce s�rv % Notamment> ces moyens comprennent la description d'une séquence d'accès successifs qui doivent être effectués par le serveur 30 auprès des ressources considérées. Par exemple, en considérant un service de prévision météorologique payant, les accès successifs peuvent comprendre la séquence suivante : - l'accès aux ressources du service pour indiquer un lieu pour la prévision, l'accès aux ressources du service pour indiquer une date de prévision, l'accès aux ressources pour indiquer un numéro d'abonné au service. Eh outre, ces moyens doivent comprendre la liste des paramètres de- tif vant être fournis par un utilisateur du service pour permettre la réalisation de commandes � GET � ou � PST � à partir de formulaire URL ou HTTP éga- lement fournis per le fournisseur de service. Plus précisément, le formulaire d'URI, doit permettre de déterminer un URI_ des ressources à requérir pour chaque accès de la séquence en utilisant des données d'entrée pour remplir ce formulaire LI RL. De même, un formulaire HTTP doit permettre de déterminer une requête HTTP visant les ressources à requérir lors de chaque accès de la séquence en utilisant des données d'entrée pour remplir ce formulaire HTTP. Finalement, ces moyens indiquent une ou plusieurs donnée(s) de sortie 20 devant être émise par les ressources. En autre, les mayens comprennent une indication de la structure attendue de cette émission qui doit être conforme au format d'affichage .ML. Selon l'exemple relatif à un service de prévisions météorologiques, ce dernier peut être déclaré au registre 32 en indiquant la définition suivante: 25 un nom de service tel qu'un URL � prévision rnétéorologique.fr � - des paramètres à fournir par l'utilisateur du service tels que pays pour la prévision �, � ville de la prévision �, � date de la prévision � et �. nu-mère d'abonné au service W. - une séquence d'opérations à suivre pour effectuer des accès sucres- 30 site tels que, : une saisie du pays de la prévision, une saisie de la ville de la prévision, une saisie de la date de la prévision et une sais Sun numéro d'abonné au service de prévision - des données de sortie à obtenir tels qu'une température, un degré d'humidité, un degré d'ensoleillement et une facture. Lorsque le registre 32 a ainsi stocké la définition d'un service, il peut émettre une information 36 relative au statut de ce service, par exemple ac-5 cessible ou refusé. Le serveur 30 comprend également une unité 38 de traitement des requêtes 40 d'accès à un service. Plus précisément, cette unité 38 reçoit une telle requête 40 afin d'en extraire des données d'entrée nécessaires à la mise en oeuvre du service requis, 10 Suivant l'exemple précédemment mentionné d'un service de prévision météorologique, une requête 40 d'accès pourrait comprendre les données d'entrée suivantes:. - le nom du service requis : � prévision météorologique.fr � - les paramètres suivant : � France � et �Rennes � pour respective-15 ment le pays et la ville de la prévision, 14 Juillet 2008 � pour la date de la prévision et � 75A � pour le numéro d'abonné au service. Par la suite, l'unité 38 effectue la transmission 42 du nom du service cliqué dans la requête 40 vers le registre 32. Ainsi, ce dernier transmet la définition 44 û nom, données d'entrées et moyens de anise en oeuvre û de 20 ce service à l'unité 38 A partir de cette définition, l'unité 38 met en oeuvre les différents accès requis en utilisant des données d'entrée indiquées par l'utilisateur dans sa requête 40. Pour cela, l'unité 38 fait appel e une interface 46 et e un extracteur 48 25 XML de la façon suivante : - l'interface 46 reçoit le formulaire URL et les données d'entrée afin de compléter le formulaire URL a partir de ces dernières. Lorsqu'une commande � POST � doit être émise, l'unité 38 transmet également le formulaire HTTP afin que l'interface 46 complète ce dernier 30 avec des paramètres comme donnée d'entrée. Ainsi, l'interface 46 génère un URL transmie à partir d'un message � GET �, t éventuellement un corps de requête HTTP dans le cas d'un meesege s POST vers ies reesoweee We 52 A la suite de cette requête 50, les ressources 52 envoient une réponse 54 conforme au format XML, par exempte en langage applicatif SOAP; XHTML ou HTML. La passerelle 46 effectue la transmission 56 de cette réponse 54 vers 5 l'unité 38 qui la renvoie û étape 58 vers l'extracteur 48. - L'extracteur 48 reçoit ainsi les éléments XML reçus par la passerelle 46 ainsi �une liste de résultats devant être obtenus dans à partir de la réponse 54. A partir de cette transmission 58, l'extracteur 48 peut identifier une don 10 née de sortie attendue codée selon un format de présentation XML. Cette donnée de sortie, par exemple un nom ou une valeur, fait ensuite l'objet d'une transmission 60 vers l'unité 38. Cette dernière mémorise les données dé sortie ainsi obtenues afin de les transmettre lors d'une dernière opération 62, Toutefois, une première 15 donnée de sortie obtenue lors d'un premier accès peut être égalemOnt re- quise comme donnée d'entrée pour un second accès. Dans ce cas, l'unité 38 ajoute cette première donnée de sorte dans les paramètres pris en compte pour transmettre des données d'entrées lors d'accès ultérieurs, 20 En référence à la figure 4, les éléments et les opérations décrites dessous sont illustrés sous la forme d'un diagramme. Plus précisément, ce diagramme représente notamment. - les communications 34 et 36 entre le fournisseur de service 37 et le re gistre 32 lors de la déclaration d'un service, 25 - les communications 40 et 62, selon le protoeoie de communication standard, entre le terminal 41 et l'unité 38, - !es communications 50, selon le protocole de communication standard, et 5, selon le langage applicatif des ressources 52, entre l'interface 46 et ces ressources 52, et 30 - la séquence 64 d'accès aux ressources aboutissant aux données de sortie fournies au terminal. Revendications1. Piecedé d'accès à des ressources (52) du Web destinées à recevoir une donnée d'entrée émise par un terminal (41), selon un protocole de communication standard (HTTP), pour déterminer une donnée de sortie cedée selon un langage applicatif (HTML, SOAP) conforme a un format (XML) déterminant des règles de présentation de données, caractérisé en ce qu'il comprend les étapes suivantes: - l'étape pour le terminal (41) de transmettre à un serveur (30) d'accès des 10 données d'entrée (40) comprenant notamment une adresse de ces ressources (52) du WeID, - l'étape pour le serveur (30) de générer une séquence d'accu (50) successifs aux ressources (52) du Web à partir de ces données d'entrée, - l'étape de mettre en oeuvre automatiquement cette séquence d'accès (50) 15 entre le serveur (30) et les ressources (52) du Web en effectuant pour chaque accès: i) l'émission (50) par le serveur, selon le protocole de communication standard (HTTP), d'une donnée d'entrée utilisée par les ressources (52) pour générer une donnée de sortie transmise (54) au serveur (30) et codée 20 selon le langage applicatif (HTML, SOAP conforme au ton-net (XML) de présentation de données> ii) l'extraction par le serveur (30) de le donnée de sortie transmise par les ressources (52) en utilisant le format (XML) de présentation de données pour, identifier cette donnée de sortie dans la transmission (54) émise par les 25. ressources (52), - l'étape pour le serveur (30) de transmettre (62) les données de sortie ainsi extraites vers le terminal (41) selon le protocole de communication standard (HTTP), 2> Procédé selon la revendication 1 caractérisé en ce qu'il comprend 30 l'étape de transmettre au serveur (30) une définition des ressources indiquant une adresse (URI_ ',i de ces ressources (52) et des moyens de mise en ce. Jvre de différentes tn.,ération devant être suivies par le serveur (30) pour ;sereine vn es tte ntniieee.3, Procédé selon le revendication 2 caractérisé en ce que les moyens de mise en oeuvre comprennent la description d'une séquence d'accès successifs qui doivent être effectués par le serveur (30) auprès des ressources (52) pour obtenir le service. 4. Procédé selon la revendication 2 ou 3 caractérisé en ce que les mayens de mise en oeuvre comprennent une liste de paramètres devant être feurnis par un utilisateur du service pour être utilisés comme données d'entrée par le serveur (30) lors des accès aux ressources (52). 5. Procédé selon l'une des revendications 2, 3 ou 4 caractérisé en 10 que les moyens de mise en oeuvre comprennent un formulaire d'URL per-mettant de générer un URL de la ressource (52) à requérir pour chaque ad-ces en complétant ce formulaire URL à raide d'une donnée d'entrée. 6, Procédé selon l'une des revendications 2 à 5 caractérisé en ce que les moyens de mise en oeuvre comprennent un formulaire HTTP permettant 15 de déterminer une requête HTTP à transmettre aux ressources pour chaque accès en complétant ce formulaire HTTP à raide d'une donnée d'entrée. 7. Procédé selon rune des revendications précédentes caractérisé en ce que le protocole de communication standard est le protocole HTTP ù pour � Hyper-rext Transfer Protocol � en anglais. 20 8. Procédé selon la revendication 7 caractérisé en ce qUe l'accès aux ressources est effectué à l'aide. d'une commande du type � GET �, entrainant une description des ressources du Web identifiées dans le commande, ou d'une commande du type � POST �, entraînant le traitement de données d'entrée, transmises dans la commande, par des ressources du Web égal- 25 Iement identifiées dans la commande. 9. Procédé selon l'une des revendications précédentes caractérisé en ce que le langage applicatif codant les données de sortie est un des langages suivants : le langage HTML, pour � HyperText Markup Language � en anglais,. 30 dédié notamment à la représentation de pages Wei]. - le langage SOAP, pour � Simple Objeet Access Protocol � en anglais, dédié notamment à l'échange de données entre serveurs eu systèmes du VVeb.- le langage RSS, pour � Really Simple Syndication � en anglais, dédié notamment à la diffusion d'alertes, de nouvelles ou de liste sur le Web. 10. Procédé selon l'une des revendications précédentes caractérisé en ce que le format de présentation des données est un format à balises tel que le format MIL Il. Serveur (30) d'accès à des ressources (52) du Web destinées à recevoir une donnée d'entrée émise par un terminal (41)> selon un protocole de communication standard (HTTP), pour déterminer une donnée de sortie codée selon un langage applicatif (HTML, SOAP) conforme à un format IO (XML) déterminant des règles de présentation de données, caractérisé en ce qu'il comprend des moyens peur : - recevoir d'un terminal (41) des données d'entrée (40) comprenant notam ment une adresse de ressources (52) Web, générer une séquence d'accès (50) successifs aux ressources (52) du 15 Web à partir de ces données d'entrée (40), - mettre en oeuvre automatiquement cette séquence d'accès (50) entre le serveur (30) et tes ressources (52) du Web en effectuant pour chaque accès : i) l'émission par le serveur, selon le protocole de communication 20 standard, d'une donnée d'entrée utilisée par les ressources pour générer une donnée de sortie, transmise au serveur, codée selon le langage applica- tif conforme au format d'affichage, il) l'extraction par le serveur de la donnee de sortie transmise par les ressources en utilisant le format d'affichage de données pour identifier cette 25 donnée de sortie dans la transmission émise par les ressources, - transmettre les données de sortie ainsi extraites vers le terminal selon le protoeoie de communication standard.