FR2796511A1 - Telecommande d'execution d'une fonction dans un serveur - Google Patents

Abstract

Une adresse d'une librairie dynamique (DLL) contenue dans un serveur et contenant ladite fonction, et des champs de données non cachés et cachés sont inclus (E3) dans une requête (R1) transmise par un terminal client (CL) à travers un réseau de transmission (WWW). Le nombre (NC) de champs dans la requête reçue est compté (S2) dans le serveur. La fonction dans une table mémorisée dans le serveur est sélectionnée (S3) en dépendance du nombre de champs de données comptés afin d'exécuter (S4, S5, S6) la fonction dans le serveur. Afin d'éviter le téléchargement de la librairie dans le terminal client, un programme exécutable n'effectuant aucune action (EX) est chargé (I01, I02) initialement dans le terminal client et exécuté en réponse à l'adresse de la librairie dynamique dans la requête.

Description

Télécommande <B>d'exécution d'une fonction dans un</B> <B>serveur</B> La présente invention concerne de manière générale des échanges demande/réponse entre un terminal client, appelé ci-après client, et un serveur à travers un réseau de transmission à débit élevé. Plus particulièrement, elle a trait à l'exécution d'une fonction dans le serveur sous la commande du client à travers le réseau Internet.

Le réseau Internet est basé sur une structure client-serveur qui utilise je protocole de communication HTTP (Hypertext Trans-fer Protocol). Si un client demande un document au serveur, le client se connecte au réseau Internet, le document est transféré du serveur au client et le client se déconnecte du réseau. La plupart des documents Web d'un serveur HTTP sont exprimés dans le langage HTML (Hypertext Markup Language). Des balises de ce langage définissent la structure logique d'un document Web. Un navigateur Web - une interface graphique dans le terminal pour visualiser un document Web - interprète les balises HTML et effectue la présentation graphique. Les documents HTML peuvent contenir des images et d'autres éléments non-textuels. Si le navigateur trouve un tel élément dans un document HTML, il charge automatiquement les données correspondantes en faisant appel au protocole HTTP.

Les documents Web sont identifiés par un système d'adressage. Chaque document Web, ainsi que les éléments intégrés au document, sont identifiés par une adresse respective URL (Uniform Ressource Locator). Le document Web peut exister statiquement sur 1e serveur ou peut être créé dyna:niquament au momen" de La demande du document car 'Le cLïent. Cette technique est transparente pour -gin client Web. Les types de document qu'un client charge et la façon dont le client interagit avec un document dépendent de la fonctionnalité des programmes utilisés dans le navigateur.

Les applications Web sont partagées en de,,-;x catégories selon leur lieu d'exécution les applications du côté serveur et les applications du côté client. Les applications dans le serveur sont responsables de la création et la mise à disposition des données. Les applications dans le client ont pour tâches la visualisation des données et la gestion des interactions avec l'utilisateur.

La mise à disposition des données est habituellement sous la forme de fichiers statiques, installés dans les répertoires du serveur HTTP. Les applications Web donnent accès à des données qui n'existent pas encore ou qui existent dans un format autre qu'en langage HTML.

Les données peuvent être également créées dynamiquement à partir de sources d'informations très complexes telle qu'une base de données. Selon leurs fonctionnalités, plusieurs types d'applications Web dans un serveur HTTP sont différenciées les applications intégrées dans le serveur HTTP et les applications externes qui sont lancées par le serveur HTTP, mais aussi les applications qui créent un document complet et les applications qui ajoutent des morceaux à un document existant ou qui modifient un document existant. L'invention s'inscrit dans le cadre des ces dernières applications. En utilisant des applications du serveur, le navigateur dans le client ne sert que pour l'entrée et la sortie de données en mode graphique.

Pour réduire la charge du réseau et pour améliorer les délais de réponse, une partie de la gestion de données, par exemple la validation de données entrantes, est déportée dans le client. Le langage interprété HTML ne fournit pas cette fonctionnalité. Pour résoudre ce problème, des applications Web du côté client ont été développées, par exemple au moyen d'applets en langage JAVA (marque déposée), ou de contrôles en langage ActiveX (marque déposée). La dépendance de ces applications au système d'exploitation et au navigateur est importante.

La présente invention vise à améliorer l'interface entre un client et un serveur en rendant interactif des documents exprimés en langage hypermédia dans le client directement avec des fonctions appelées dans le serveur par le client pour créer, modifier ou compléter un document.

A cette fin, un procédé pour télécommander l'exécution d'une fonction dans un serveur en réponse à une requête transmise par un terminal client à travers un réseau de transmission, est caractérisé par les étapes suivantes - inclure dans la requête établie par le terminal client une adresse d'une librairie dynamique qui est contenue dans le serveur et qui contient, en outre, ladite fonction, et des champs de données dont le nombre identifie la fonction ; - compter les champs de données dans la requête reçue dans le serveur SER ; et - sélectionner 1a fonction Jans une table de foncrions mémorisée dans 'Le servelr en dépendance du nombre de champs de données comptés afin d'exécuter la fonction dans le serveur.

Le terminal client selon l'invention n'utilise aucun applet en langage JAVA ou aucun contrôle en langage ActiveX, mais seulement des documents exprimés typiquement en langage H7ML, ce qui soulage le terminal client.

De manière à ajuster le nombre de champs de données au nombre identifiant la fonction, au moins l'un des champs de données inclus dans la requête est de type caché et a des données n'apparaissant pas sur un écran du terminal client. Les données du ou des champs cachés supplémentaires sont bien souvent sans signification.

L'invention remédie également au téléchargement d'un programme prédéterminé, telle que la librairie dynamique, que le navigateur demande à la suite de l'établissement d'une adresse de type URL à envoyer au serveur. A cet effet, un programme exécutable n'effectuant aucune action est chargé initialement dans le terminal client afin de le répertorier dans un tableau de types de média, et un fichier correspondant au programme exécutable dans le tableau de types de média est recherché en réponse à l'adresse de la librairie dynamique contenue dans la requête, puis le programme n'effectuant aucune action est exécuté. L'exécution d'un programme sans action inhibe ainsi la demande de téléchargement du navigateur.

En pratique, l'étape de charger peut comprendre un téléchargement du programme n'effectuant aucune action avec une page d'accueil depuis le serveur dans le terminal client. D'autres caractéristiques et avantages de la présente invention apparaitront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention en référence à la figure unique annexée correspondante 1 qui est un algorithme d'une demande/réponse entre un terminal client et un serveur pour exécuter une fonction dans le serveur selon l'invention.

Une interface graphique interactive, appelée Webtop, est implantée dans un terminal d'un utilisateur et dans l'un des modules logiciels contenus en permanence en mémoire dans un serveur<B>SEP,</B> et appelées librairies (ou bibliothèques) dynamiques DLL (Dynamic Link Library). Le terminal d'utilisateur est appelé dans la suite "client" CL pour désigner les ressources logicielles et matérielles dans le terminal.

Comme montré schématiquement à la figure 1, le client CL et le serveur SER sont reliés notamment à travers un réseau de transmission de données à débit élevé, le réseau Internet WWW auquel on se référera, ou bien un réseau Intranet. Les messages échangés entre le client et le serveur sont des requêtes selon le protocole HTTP (Hypertext Transfer Protocol). Une requête est une adresse URL (Universal Ressource Locator) spécifiant notamment, à la suite du nom de protocole HTTP, le nom du serveur et le nom d'un document (répertoire et page) à afficher dans le client CL ou le nom d'une librairie de fonctions à traiter dans le serveur SER.

Afin de fixer le cadre de l'invention, il est rappelé ci-après quelques caractéristiques du serveur et du client, servant à la description d'une communication entre client et serveur lors du remplissage d'un formulaire par le client.

Le serveur SER a la possibilité de modifier un document existant avant de l'envoyer au client qui. l'a demandé. Le serveur consulte le document, cherche les instructions intégrées au document et les remplace par des objets demandés dans des instructions par le client CL. Les objets sont par exemple des lignes de texte, des images ou d'autres objets dynamiques interactifs qui sont créés au moment de la consultation du document. Cette technique est transparente pour l'utilisateur du terminal client CL qui ne visualise que le résultat d'une telle modification.

Cette technique est basée sur une plate-forme de logiciel, côté serveur, l'ASP (Active Server Pages), qui utilise des instructions intégrées dans les documents et également des petits programmes, des scripts exprimés par exemple dans le langage de programmation Javascript (marque déposée). Les scripts sont interprétés par un interpréteur qui est intégré dans le serveur SER. Ce type d'application Web dépend du système d'exploitation du serveur et est développé pour des accès à au moins une base de données BD.

Le serveur décide selon le préfixe du fichier contenant le document s'il doit lancer une analyse. La gestion et le traitement facile des scripts et des instructions sont avantageusement intégrés directement dans des documents HTML (Hypertext Markup Document). Le client ne réceptionne qu'un document HTML standard. Pour réduire la charge du serveur SER, des outils de programmation API !'Application Programming Interfaces) facilitent !'accès interactif d'applications au système d'exploitation dans le serveur. Ces outils de programmation sont des librairies DLL (Dynamic Link Library) chargées dynamiquement en langage orienté objet, par exemple en langage C++. Ces librairies encapsulent un certain nombre de fonctions internes ou d'appels de système d'exploitation sont appelées selon des paramètres d'entrée. Les librairies DLL sont chargées une fois lors d'une première demande du client et restent accessibles dans 1a mémoire du serveur pour d'autres demandes. L'exécution d'une telle librairie crée un processus dans le serveur qui répond à plusieurs requêtes. La librairie utilise le même espace de mémoire que le serveur et elle peut donc utiliser toutes les ressources du serveur SER. Un outil API est dépendant du système d'exploitation du serveur et n'est pas portable. L'outil API peut intégrer une application quelconque qui est développée dans le même langage de programmation que l'outil lui-même ; en conséquence, une modification d'une librairie DLL demande une recompilation de cette librairie.

L'interface utilisateur Webtop comprend un navigateur (browser) afin de consulter des librairies dans le serveur. Le navigateur sait interpréter le langage de description de document (page) d'écran HTML afin d'afficher du texte dans les fenêtres du navigateur qui sont éventuellement enrichies d'éléments multimédias et qui sont généralement interactives au moyen de liens hypertextes insérés. L'interface Webtop chez le client contient également un langage de scripts, tel que le langage JavaScript (marque déposée), qui complète 1e langage HTML afin notamment d'animer des pages HTML, d'ouvrir des fenêtres, de modifier des documents affichés, etJ.

Du côté du<B>client</B> CL, la présentation des différents types de médias tels que textes, images, vidéo, sons, etc., demande des logiciels spécifiques. Le type de média est identifié par le format standard MIME (Multipurpose Internet Mail Extensions) contenant le type de média et l'extension du fichier type/extension. Le serveur SER ajoute, dans l'en tête d'une réponse à une demande HTTP, la spécification du type du document envoyé. Le navigateur Web reconnaît le type de document et sélectionne dans un tableau la bonne présentation du document. Les types de médias de base sont par exemple des commandes text/html, ou bien des images graphiques image/gif affichables directement par le navigateur. Pour d'autres types, le navigateur utilise des programmes auxiliaires en correspondance avec le type de document.

Selon la réalisation préférée, le langage de script est JavaScript (marque déposée), supporté par le navigateur Web.

Les scripts d'une application Web exécutables dans le client sont soit intégrés directement dans la page HTML, soit transmis séparément dans un autre document Web lié à plusieurs pages HTML. Le navigateur Web lance un script soit lors du chargement du document Web, soit après un événement ou une interaction définie dans le document Web. Les événements, tels que des interactions de souris, sont directement appliqués à des balises HTML. Les scripts servent souvent à valider des données saisies dans un formulaire HTML.

Les fonctions des langages de script sont susceptibles également de modifier le contenu, 1a structure et la présentation d'un document Web de façon dynamique. Cette technique est basée s,.:r le modèle d'objet de document DOM (Document Object Model). Chaque élément d'une page HTML, ainsi que le navigateur lui-même, est traité comme un objet avec un certain nombre de propriétés. Avec les méthodes qui sont appliquées par le script et des fonctions supplémentaires fournies par le script, les propriétés des objets sont modifiables.

La fusion entre les langages de script et le modèle DOM est appelé le langage dynamique DHTML (Dynamic HTML) qui permet, gràce au traitement dynamique d'objets, la réalisation d'animations simples directement dans une page HTML.

En référence à la figure 1, il est supposé que le client CL a demandé un formulaire par exemple sur la page d'accueil du serveur SER et reçu celui-ci à des étapes initiales E01 et E02. L'utilisateur remplit, au moyen du navigateur (browser) dans le terminal client CL, le formulaire affiché sur le terminal en saisissant des données par exemple au clavier du terminal, à une étape E1. Des données peuvent être effacées au cours de la saisie sur le formulaire au moyen d'un bouton "RESET", comme indiqué à des étapes E11 et E12. Après que le formulaire soit rempli à l'étape E1, le client CL a constitué une chaîne de caractères composée de couples de champ/valeur ayant chacun le nom d'un champ de données rempli du formulaire suivi d'une valeur saisie dans ce champ. A ce stade, selon l'invention, le nombre de champs ou de couples NC inclus dans la chaîne de caractères indique le numéro de la fonction à cibler dans la librairie DLL qui sera exécutée dans le serveur. Lorsque les champs remplis par des valeurs saisies sont en nombre insuffisant, le client complète éventuellement la chaîne par des champs supplémentaires afin d'atteindre le numéro de la fonction ciblée. Les champs supplémentaires sont des champs de type caché "HIDDEN" de la classe d'entrées dont les données n'apparaissent pas graphiquement à l'écran du terminal client CL, c'est-à-dire dans le formulaire initialement affiché à l'étape EO ou dans des formulaires affichés et complétés ultérieurement par le serveur. Certains de ces champs supplémentaires non visualisés à l'écran peuvent être, du moins pour partie, remplis de données qui sont traitées ultérieurement par la librairie dynamique DLL et qui peuvent être retournées au client CL en les ajoutant dans la nouvelle page Web écrite par le serveur. Ces données sont ainsi conservées pour le client, et sont utilisables aussi bien par le serveur que par le client. Toutefois, certains champs cachés peuvent être vides de données afin que le nombre total NC de champs corresponde au numéro de la fonction ciblée dans la librairie DLL.

La chaîne de données est ainsi constituée pour être envoyée au serveur SER selon la méthode indiquée par un attribut METHOD inclus dans une balise < FORM> au début du formulaire en langage HTML. Les données saisies dans le formulaire devant être traitées par le serveur SER, la balise < FORM> comprend la méthode POST. En réponse à la sollicitation d'un bouton de soumission "SUBMIT" à l'étape E2, le client établit une requête HTTP R1 et envoie celle-ci au serveur à l'étape E3. La requête HTTP contient un attribut ACTION définissant une adresse URL contenant, outre le nom du serveur, l'adresse de la librairie ciblée DLL et la chaîne de couples de champ/valeur.

En réponse à la première requête HTTP R-.1, le serveur SER effectue des premières étapes S1 à S3 pour identifier la fonction dans la librairie DLL, puis des étapes pour exécuter la fonction et créer une nouvelle page Web.

A la première étape S1, le serveur SER récupère les données constituées par les couples de champ/valeur, y compris avec les champs cachés, et les stocke dans un tableau. Puis, l'étape S2 compte les champs remplissant le tableau afin d'en déduire le nombre de champs de données NC qui sont inclus dans la requête reçue R1 et ainsi identifier la fonction ciblée dans la librairie DLL à l'étape S3. Le nombre NC sélectionne la fonction identifiée dans une table de fonctions qui est mémorisée dans le serveur. Si le nombre NC ne correspond à aucune fonction dans la table, le serveur émet un message d'erreur.

Puis la fonction identifiée est appelée à l'étape S4, conformément au caractère dynamique de la librairie DLL. Chaque fonction dans la librairie DLL peut être lancée plusieurs fois de façon dynamique et reste disponible en permanence en mémoire du serveur. La librairie DLL encapsule par exemple une dizaine de fonctions telles que - ouverture, création, lecture et écriture d'un fichier texte ou binaire sur l'ordinateur qui héberge le serveur SER ; - création ou conversion d'un fichier image, par exemple une création de fichier a@,, format Bitmap ou une conversion de fichier au format JPEG ; - une exécution de programmes spécifiques de façon dynamique, c'est-à-dire exécutables à la demande du client.

La fonction ayant été appelée, des variables locales nécessaires à l'exécution de la fonction sent initialisées à l'étape S5, en vue d'exécuter des actions caractérisant la fonction, à l'étape Sô. A cette étape, des données reçues peuvent être lues dans le tableau rempli à l'étape S1, mais également des données peuvent être écrites dans une base de données BD et/ou des données peuvent être lues dans la base BD. La base de données BD échange classiquement des couples de demande/réponse avec le serveur.

Après l'exécution de la fonction, les résultas des actions exécutées de la fonction identifiée sont mis en forme en langage HTML suivant un script en langage JavaScript de manière à créer une nouvelie page Web et à la transmettre avec le type de page selon le format MIME au client CL dans une deuxième requête HTTP R2. Le cas échéant, la nouvelle page Web contient certains champs de données cachés transm_s dans la première requête Rl.

En revenant à la partie de gauche de la figure 1, le client CL exécute un script en langage JavaScript à une étape E4 à la suite de l'étape E3 établissant la requête HTTP R1. Ce script consiste essentiellement à mettre le client CL en attente de la nouvelle page Web dans la requête HTTP R2, pendant une durée prédéterminée à l'étape suivante E5. A l'expiration de la durée prédéterminée, le script modifie l'attribut de la méthode en l'action GET à l'étape E6 de manière à lier la page Web transmise par le serveur SER avec une page HTML correspondante à créer dans le client CL à l'étape E7 selon la présentation correspondant au type de la page Web reçue, décrite dans le tableau MIME du client. Puis, la nouvelle page HTML, un formulaire, est affichée sur l'écran du terminal client à l'étape E8 qui est suivie d'une autre étape de remplissage de formulaire E0.

En revenant à l'étape E3 précédant l'attente de requête R2 aux étapes E4 à E7, l'attribut ACTION dans la première requête R1 définit une adresse URL qui contient le nom d'un fichier cible dans le serveur, en l'occurrence le nom de la librairie visée DLL. La librairie DLL porte l'extension ".d11" qui n'est pas normalement répertoriée dans le tableau de types de média MIME inclus dans le client.

Selon l'invention, afin que le navigateur ne demande pas dans une fenêtre affichée à l'écran de télécharger la librairie à la suite de la requête R1, le client CL reçoit préalablement un programme exécutable EX qui ne fait rien, par téléchargement et sauvegarde lors de la réception de la page d'accueil transmise par le serveur SER, à une étape initiale <B>101.</B> Le type de fichier correspondant à la librairie DLL est ajouté dans le tableau de types MIME du navigateur à une deuxième étape initiale 102.

Selon l'invention, lors de l'établissement de la requête HTTP R1, contenant le nom de la librairie DLL à l'étape E3, le client CL recherche la présentation correspondant au fichier ".d11" dans le tableau MIME à une étape I1 et exécute le programme EX, en fait un script en langage JavaScript, à une étape 12. Comme le programme EX est un exécutable vide, aucune action n'est entreprise dans le client et aucune nouvelle fenêtre n'est affichée par le navigateur pendant les étapes d'attente E4 à E7 au cours de laquelle les actions de la fonction visée dans la librairie DLL sont exécutées dans le serveur, selon les étapes S1 à S6.

L'invention convient particulièrement pour des applications installées dans le serveur relatives à la sélection de sites d'émetteurs de radiocommunication ou radio/télédiffusion et la prédiction de couvertures radioélectriques autour de ces sites sur un fond de carte prédéterminé.

Claims (1)

1. REVENDICATIONS 1 - Procédé pour télécommander l'exécution d'une fonction dans un serveur (SER) en réponse à une requête (R1) transmise par un terminal client<B>(CL)</B> à travers un réseau de transmission (WWW), caractérisé par les étapes suivantes - inclure (E3) dans la requête (R1) établie par le terminal client (CL) une adresse d'une librairie dynamique (DLL) qui est contenue dans le serveur et qui contient, en outre, ladite fonction, et des champs de données dont le nombre (NC) identifie la fonction ; - compter (S2) les champs de données dans la requête reçue dans le serveur (SER) ; et - sélectionner (S3) la fonction dans une table de fonctions mémorisée dans le serveur en dépendance du nombre de champs de données comptés afin d'exécuter (S4, S5, S6) la fonction dans le serveur. 2 - Procédé conforme à la revendication 1, selon lequel au moins l'un des champs de données inclus dans la requête (R1) a des données n'apparaissant pas sur un écran du terminal client (CL). 3 - Procédé conforme à la revendication 1 ou 2, comprenant les étapes de - charger (I01, 102) initialement un programme exécutable n'effectuant aucune action (EX) dans le terminal client (CL) afin de le répertorier dans un tableau de types de média (MIME) ; - rechercher (I1) un fichier correspondant au programme exécutable dans le tableau de types de média en réponse à l'adresse de la librairie dynamique (DLL) contenue dans la requête (R1) ; et - exécuter (I2) le programme n'effectuant aucune action (EX). 4 - Procédé conforme à la revendication 3, selon lequel l'étape de charger (I01, 102) comprend un téléchargement du programme n'effectuant aucune action (EX) avec une page d'accueil depuis le serveur (SER) dans le terminal client (CL).