Brevet FR2830398A1 — publié le 20030404

La présente invention a trait de manière générale à l'exécution de fonctions appliquées à des objets informatiques dans un environnement clientserveur. Plus particulièrement, l'invention concerne, d'une part, un procédé de demande d'exécution d'une fonction dans un système informatique client dans un environnement client-serveur, la fonction étant applicable à un objet informatique traité par un système informatique serveur ; le procédé comportant les étapes préalables d'obtention d'une interface de l'objet et de sélection d'une fonction à partir de l'interface. D'autre part, l'invention concerne un procédé d'exécution d'une fonction dans un système informatique serveur, dans un environnement client-serveur ; Ce procédé comportant une étape préalable de réception d'un message d'appel de la fonction, en provenance d'un système informatique client. L'invention concerne aussi des systèmes informatiques aptes à mettre en oeuvre les procédés précités. De manière générale, dans un système orienté objet (en anglais"object oriented system"), un objet informatique est un élément comprenant des données, également appelé attributs, et des fonctions (en anglais"functions" ou"methods") utilisant éventuellement des paramètres d'entrée (en anglais "input arguments"). Classiquement, ces fonctions peuvent être appelées ou invoquées (en anglais "invoked") pour manipuler les données de l'objet. L'ensemble des fonctions applicables à un objet et ses attributs constitue l'interface de l'objet. Chaque objet informatique est créé dans un langage de programmation utilisé par une application informatique qui est mise en oeuvre sur le site du réseau sur lequel est créé l'objet. De tels langages de programmation sont connus, par exemple, sous le nom de JAVA ou C++. Pour qu'un objet informatique puisse être partagé sur un réseau de communication, il est nécessaire de le coder d'une manière telle qu'il ne soit ni dépendant de l'architecture du réseau de communication, ni dépendant du langage de programmation dans lequel l'application informatique a créé l'objet. Cela est nécessaire dès lors qu'un autre ordinateur peut ne pas avoir la même architecture de réseau ou peut implémenter une application informatique différente. Lorsque l'objet informatique est reçu par un autre site, une opération inverse de traduction doit être appliquée à l'objet pour obtenir une représentation de l'objet dans l'application informatique mise en oeuvre sur ce second site. Le réseau Internet avec ses langages et ses protocoles de communication se prête particulièrement à l'élaboration d'un système orienté objet d'étendue planétaire. Plus particulièrement, le World Wide Web (Web ou WWW) constitue l'interface de prédilection pour accéder à la plupart des ressources disponibles sur Internet. Le Web (aussi appelé"Toile"en français) est un ensemble de protocoles Internet et de logiciels qui présentent l'information dans un format hypertexte. Le concept d'hypertexte s'emploie pour construire des documents informatiques qui référencent d'autres documents à l'aide de liens, aisément sélectionnables par des utilisateurs novices. Le langage HTML (HyperText Markup Language) est un langage de balisage conçu pour décrire la manière dont des documents doivent être affichés par les navigateurs Web. Ce langage du fait de sa simplicité et de sa facilité d'utilisation, a été rapidement adopté comme un standard dans le monde Internet. Cependant, il est impossible d'étendre ce langage au-delà de ce pourquoi il a été conçu, c. -à-d., la présentation de documents. Les auteurs de documents ne sont en effet pas autorisés à créer de nouvelles balises pour leurs besoins spécifiques. Le langage XML (eXtensible Markup Language) a été créé notamment pour pallier la faiblesse du langage HTML. Le langage XML est défini selon une norme de l'organisation internationale connue sous le nom de"W3 Consortium" (W3C). XML est un langage de balisage à balises de structuration : chaque balise correspond à un élément, qui peut être présent une ou plusieurs fois dans le document. Une balise peut contenir du texte ou d'autres balises. Dans le cas où elle contient d'autres balises, une balise est assimilée à un noeud d'un arbre. Contrairement à HTML, le nom des balises n'est pas soumis à une norme, il est défini par le programmeur. En outre, chaque balise ouvrante doit être accompagnée d'une balise fermante, ou être une balise vide. Cette contrainte permet de créer des documents ayant une structure hiérarchique qui peut être représentée sous la forme d'un arbre. De par sa structure hiérarchique (arborescente), le langage XML permet de représenter des données structurées. D'autre part, un document XML est parfaitement lisible par un humain"averti". Enfin les documents XML étant au format texte, ils peuvent être facilement échangés via le Web en utilisant les protocoles existants comme HTTP (Hypertext Transfer Protocol). En complément du langage XML, on trouve des langages"de schéma", ainsi désignés parce qu'ils permettent de définir une classe de document XML, le terme "document instance" étant souvent utilisé pour définir un document qui est valide par rapport à un certain schéma. Ainsi une DTD (Document Type Definition) est un langage de schéma qui permet de spécifier quels éléments sont susceptibles d'apparaître dans les documents instances, quels éléments peuvent être contenus dans d'autres éléments, et dans quel ordre ils doivent apparaître. Le plus souvent une DTD est un fichier à part, externe au document XML. Récemment, un autre langage de schéma est apparu : XML Schema, également défini par une norme W3C. XML Schema présente l'avantage par rapport aux DTD d'utiliser la syntaxe XML. Autrement dit, un document exprimé en XML Schema (appelé schéma XML) est un document XML. Ainsi n'importe quel schéma XML peut être manipulé par tout éditeur XML. Le langage XML Schema présente, entre autres, l'avantage par rapport au langage XML, de permettre la création de types complexes. Dans le document constitué par la demande de brevet français n 9908155 déposée au nom de la société CANON, on décrit un procédé et un dispositif d'exécution à distance d'une fonction sur un objet informatique dans un réseau de communication. Plus particulièrement, ce document propose une méthode de description de l'interface d'un objet, basée sur l'utilisation du langage XML. Dans le document constitué par la demande de brevet français n 0108772 déposée également au nom de la société CANON, on décrit un procédé et un dispositif de description de l'interface d'un objet informatique. Selon ce document, une fonction applicable à un objet informatique donné (par ex., une image numérique) est définie par une première balise utilisant la syntaxe du langage XML. Par ailleurs, des secondes balises, contenues dans la première, utilisant la syntaxe du langage XML Schema permettent de décrire les arguments de la fonction et les types de ces arguments. En outre, si la fonction produit un résultat, il est défini une troisième balise, également contenue dans la première, décrivant le résultat de la fonction, le type du résultat étant exprimé selon la syntaxe XML Schema. Ainsi, dans ce contexte, pour effectuer un appel de fonction à distance sur un objet informatique, un ordinateur client transmet à un ordinateur serveur hébergeant l'objet, un fichier XML qui respecte une syntaxe prédéfinie par le serveur. Cependant, dans l'art antérieur connu à ce jour, et en particulier dans les documents précités, une fonction donnée applicable à un objet informatique, lorsqu'elle retourne un résultat, retourne le plus souvent un résultat unique, et l'utilisateur n'a aucune possibilité de choix concernant ce résultat. Par ailleurs, lorsqu'un utilisateur demande à obtenir plusieurs résultats, il y a généralement deux solutions possibles. Soit, plusieurs fonctions distinctes sont appelées, chacune d'entres elles retournant un des résultats demandés, soit une seule fonction est appelée, la fonction retournant une pluralité de résultats. Dans le premier cas, chaque appel de fonction est consommateur de temps de réponse et de bande passante sur le réseau. Dans le second cas, la fonction retournant tous les résultats qu'elle peut générer, il peut y avoir parmi ceux-ci des résultats non désirés par l'utilisateur. Les résultats inutiles retournés consomment également de la bande passante sur le réseau, d'autre part il incombe à l'utilisateur de faire le tri parmi les résultats retournés. Or, avec notamment le développement du commerce électronique sur Internet, il y a un réel besoin de pouvoir offrir à l'utilisateur, des services qui offrent une grande souplesse d'utilisation, et notamment par l'utilisation de fonctions appliquées à des objets informatiques, qui puissent renvoyer des résultats multiples et sélectionnables par l'utilisateur. La présente invention vise à répondre à ce besoin. A cet effet, l'invention concerne selon un premier aspect, un procédé de demande d'exécution d'une fonction dans un système informatique client ("client") dans un environnement client-serveur, la fonction étant applicable à un objet informatique traité par un système informatique serveur ("serveur"). Ce procédé comporte les étapes préalables d'obtention d'une interface de l'objet et de sélection d'une fonction à partir de l'interface, et est caractérisé en ce qu'il comporte les étapes suivantes : - détermination des résultats différents retournés suite à l'exécution de la fonction, à partir d'informations d'identification de résultat, codées dans l'interface ; - sélection d'au moins un résultat désiré à partir desdites informations d'identification de résultat ; - génération d'un message d'appel de la fonction, le message d'appel incluant une liste de résultats désirés, chaque élément de la liste étant indicatif d'un résultat sélectionné ; - envoi du message d'appel de la fonction, audit serveur. Grâce à ce procédé, on offre à un utilisateur (humain) du système informatique client la possibilité de choisir les résultats qu'il désirent obtenir à partir de l'exécution de la fonction choisie et appliquée à l'objet informatique considéré, et d'obtenir en retour du système serveur seulement les résultats choisis. Selon une caractéristique particulièrement avantageuse de l'invention, l'étape de sélection d'au moins un résultat désiré inclut, pour chaque résultat désiré, la détermination d'un ou plusieurs systèmes informatiques destinataires ("destinataires") du résultat correspondant ; le message d'appel incluant alors des informations d'identification du (ou des) destinataire (s) pour chaque résultat désiré. De cette façon, outre la possibilité de choisir les résultats renvoyés par le serveur, l'utilisateur a la possibilité de spécifier pour chaque résultat ou pour chaque groupe de résultats défini par lui, un destinataire informatique (dans l'environnement client-serveur) de ce résultat ou de ce groupe de résultats. En outre, un résultat donné peut être envoyé à plusieurs destinataires sans que le serveur ait à calculer plusieurs fois ce résultat. Le procédé de demande d'exécution comporte alors une étape finale de réception, en provenance du serveur, d'un message de réponse d'exécution contenant les valeurs des résultats, parmi ceux sélectionnés, dont le destinataire correspond au système informatique client. Selon un mode de réalisation préféré, le procédé comporte en outre une étape d'affichage des résultats reçus. Corrélativement, selon un second aspect, la présente invention concerne un procédé d'exécution d'une fonction dans un système informatique serveur ("serveur"), dans un environnement client-serveur. Le procédé comporte une étape préalable de réception d'un message d'appel de la fonction, en provenance d'un système informatique client ("client"). Le procédé d'exécution est caractérisé en ce qu'il comporte les étapes suivantes : - extraction des arguments de la fonction appelée du message d'appel ; - extraction d'une liste de résultats désirés du message d'appel, chaque élément de la liste étant indicatif d'un type de résultat d'exécution désiré en retour par le client ; - exécution de la fonction en lui appliquant les arguments extraits ; - sélection, parmi les résultats obtenus au cours de l'exécution de la fonction, des résultats désirés par le client selon la liste de résultats désirés extraite du message d'appel ; - génération d'un message de réponse d'exécution de fonction, ledit message de réponse contenant les résultats d'exécution désirés par ledit client ; - envoi du message de réponse d'exécution de fonction au client. Selon une caractéristique avantageuse de l'invention, l'étape d'extraction d'une liste de résultats désirés, inclut une étape d'extraction, du message d'appel, d'informations d'identification d'un ou plusieurs systèmes informatiques destinataires pour chaque type de résultat désiré. Par ailleurs, les étapes de génération et d'envoi du message de réponse au client, incluent les étapes suivantes : - génération d'un message de réponse distinct par destinataire identifié, chaque message de réponse contenant le (ou les) résultat (s) correspondant (s) ; - envoi des messages de réponses aux différents destinataires. Selon un mode préféré de réalisation, l'environnement client-serveur est un réseau de communication de type Internet sur lequel communiquent à distance les systèmes informatiques client et serveur. Dans ce mode de réalisation, le protocole de communication utilisé est le protocole HTTP. D'autre part, l'interface de l'objet informatique, le message d'appel de fonction, et les messages de réponse d'exécution de fonction, sont des documents informatiques dont le contenu est représenté dans un langage de balisage de type XML. Selon un autre aspect, l'invention concerne un système informatique client comportant des moyens adaptés à la mise en oeuvre d'un procédé de demande d'exécution d'une fonction tel que succinctement exposé supra. De manière similaire, l'invention concerne aussi un système informatique serveur, comportant des moyens adaptés à la mise en oeuvre d'un procédé d'exécution d'une fonction tel que succinctement exposé supra. La présente invention concerne encore un réseau de communication comportant au moins un système informatique client et au moins un système informatique serveur, tels que brièvement exposés ci-dessus. Selon un autre aspect, l'invention concerne aussi, d'une part, un programme d'ordinateur sur un support d'informations, remarquable en ce qu'il comprend des instructions permettant de mettre en oeuvre un procédé de demande d'exécution d'une fonction tel que brièvement exposé plus haut, lorsque ce programme est chargé et exécuté dans un système informatique client ; et d'autre part, un programme d'ordinateur sur un support d'informations, remarquable en ce qu'il comprend des instructions permettant de mettre en oeuvre un procédé d'exécution d'une fonction tel que brièvement exposé plus haut, lorsque ce programme est chargé et exécuté dans un système informatique serveur. L'invention vise aussi un support d'informations contenant de tels programmes d'ordinateur. Un tel support d'informations peut comporter un moyen de mémorisation, tel qu'une ROM, par exemple un CD ROM ou une ROM semi-conducteur, ou un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, ou encore par radio ou par d'autres moyens. Les avantages de ces systèmes informatiques, programmes d'ordinateur, et de ce support d'informations, sont identiques à ceux des procédés de demande d'exécution et d'exécution de fonction, tels que brièvement exposés supra. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après d'un mode préféré de réalisation décrit à l'appui des dessins annexés sur lesquels : - la Figure 1 représente un exemple de deux documents selon l'invention exprimés dans un langage de balisage et décrivant respectivement un objet informatique et son interface ; - la Figure 2 représente un exemple de deux documents informatiques selon l'invention, exprimés dans le même langage de balisage, et décrivant respectivement un message d'appel d'une fonction applicable sur l'objet informatique et des messages de réponse obtenus après exécution de la fonction ; - la Figure 3 est un organigramme illustrant un procédé selon l'invention de demande d'exécution d'une fonction dans un système informatique client d'un environnement client-serveur ; - la Figure 4 est un organigramme illustrant un procédé d'exécution d'une fonction dans un système informatique serveur d'un environnement clientserveur, selon un mode de réalisation préféré de l'invention ; - la Figure 5 est un organigramme détaillant certaines étapes du processus de traitement des messages de réponse qui compose le procédé d'exécution d'une fonction, illustré à la Fig. 4 ; - la Figure 6 illustre l'interaction entre le processus d'exécution de la fonction et le processus de génération des messages de réponse, selon le mode de réalisation de l'invention illustré aux Figures 4 et 5, appliqué à l'appel de fonction représenté à la Fig. 2. Dans le mode de réalisation décrit et illustré au figures, l'environnement client-serveur est le Web sur l'Internet. La Figure 1 représente un exemple de deux documents informatiques selon l'invention exprimés dans un langage de balisage et décrivant respectivement un objet informatique et son interface. Dans le mode de réalisation préféré, le langage de balisage est le langage XML. Le document 100 est ainsi un document XML décrivant un objet informatique, ici une image numérique stockée dans un ordinateur serveur sur le réseau (par ex. un serveur d'images). Le document 100 peut être obtenu par un utilisateur utilisant un ordinateur "client" sur le réseau, par exemple après avoir consulté un site informatique (site web) et cliqué sur un lien hypertexte ou sur un objet informatique affiché à l'écran. Selon le document 100, un objet informatique"image"est décrit entre les balises XML ouvrante et fermante :" "et" ". L'interface de cet objet peut être obtenue à l'adresse électronique HTTP "http : //www. crf. canon. fr/", dans le fichier"imagelnterface. xsd". Dans ce fichier, l'objet"image"est identifié par le nom (name)"Flower" ("fleur"en français). Le document 100 est par exemple affiché sur un écran associé à l'ordinateur client, au travers d'une interface graphique (GUI, graphical user interface). Pour obtenir l'interface de l'image "Flower" à partir du document 100, l'utilisateur peut par exemple entrer une commande au clavier ou cliquer sur un élément graphique affiché à cet effet à l'écran. L'interface de l'objet, c. -à-d., le document 110, est alors téléchargée dans l'ordinateur client depuis l'adresse électronique"http : //www. crf. canon. fr/". Dans cet exemple, l'interface de l'objet décrit deux fonctions qui lui sont applicables : - la fonction "rotate" (en français "rotation") ; -la fonction"resize" (en français"redimensionner"). A chacune de ces fonctions correspond des définitions de paramètres d'entrée (arguments) de la fonction et des informations d'identification de type de résultats pouvant être retournés suite à l'exécution de la fonction. Ces informations sont codées à l'aide de balises utilisant la syntaxe du langage XML Schema. Ainsi, dans l'interface 110, la fonction "rotate" est définie par des informations codées entre les balises ouvrante et fermante : et . La première balise définit un paramètre d'entrée (argument) de cette fonction :"angle" de type flottant (float). Les autres balises, regroupées sous la référence 1101, définissent chacune un type de résultat pouvant être retourné par la fonction "rotate". Ainsi, quatre types de résultats sont définis : -"width" : largeur de l'image ; -"height" : hauteur de l'image ; -"preview" : affichage d'une imagette (thumbnail image en anglais) ; -"pixels" : affichage de l'image à sa taille normale. Chacune des balises (par ex. ) définissant un type de résultat particulier retourné par la fonction comporte en outre deux attributs :"out"et "returned". L'attribut out lorsqu'il est égal à'true' (vrai) definit l'élément correspondant (par ex. width) comme étant un résultat d'exécution. L'attribut retumed lorsqu'il est égal à'true'signifie que le résultat correspondant est retourné par défaut au système informatique client, émetteur du message d'appel de la fonction. De cette façon, si l'utilisateur ne précise pas quels résultats il souhaite obtenir, on lui retourne par défaut une réponse contenant l'ensemble des résultats pour lesquels l'attribut retumed a la valeur'true'. La seconde fonction"resize"définie dans l'interface (110) de l'objet considéré (image) ne retourne quant à elle aucun résultat. En effet, seul son argument (factor) est défini, et elle ne comprend aucun élément comportant un attribut out='true'. La Figure 2 représente un exemple de deux documents informatiques, décrivant respectivement un message (200) d'appel de la fonction "rotate" définie dans le document 110, et un message (210) de réponse obtenu après exécution de la fonction par le système serveur. Ces deux documents (200, 210) sont également des documents XML. On suppose que l'utilisateur du système informatique client a sélectionné au préalable, à partir de l'interface 110 de l'objet, plusieurs types de résultats à partir de la liste 1101. Un message 200 d'appel de fonction est alors généré, dans le système client. Comme représenté sur la Fig. 2, le message 200 d'appel de fonction (s) est défini entre les balises ouvrante et fermante, respectivement : et . Dans cet exemple, une seule fonction est appelée, la fonction rotate. L'appel de la fonction rotate choisie est défini par les informations codées entre les balises ouvrante et fermante : et . L'élément 90 définit la valeur (90) du seul argument (paramètre d'entrée) "angle" de la fonction rotate. Dans cet exemple il s'agit donc d'appliquer une rotation de 90 degrés à l'objet image"Flower". Le message (200) d'appel de la fonction (rotate) inclut une liste de résultats d'exécution désirés. Cette liste est identifiée à la Fig. 2 par la référence 2001. Chacun des résultats de la liste 2001 est représenté par une balise XML, elle-même insérée entre une balise ouvrante ( ) et une balise fermante ( ). Chaque paire de balises ouvrante et fermante ( , ) définit une sous-liste de résultats désirés qui sont destinés à un destinataire particulier sur le réseau. Ainsi dans l'exemple donné (message 200), deux sous-listes sont présentes. La première comprend deux types de résultat désirés : width et height. Selon l'implémentation choisie et illustrée, comme aucune information concernant le destinataire de ces résultats n'est présente dans la première sous-liste, les résultats d'exécution correspondants seront envoyés par le serveur au système client émetteur du message d'appel de fonction. Dans la seconde sous-liste, un seul type de résultat est demandé : pixels. Une information d'identification de destinataire du résultat est ici présente sous la forme d'un attribut XML particulier (to='...') inséré dans la balise ouvrante correspondante ( ). Dans l'exemple choisi, cette information d'identification de destinataire : to='mailto : cra) canon. net' (2002), signifie que le résultat de type pixels sera renvoyé après exécution de la fonction (rotate) par le serveur, à l'adresse de courrier électronique"crf@canon. net" se ! on te protoco) e SMTP (Simple Mail Transfer Protocol). Ensuite, après traitement du message d'appel 200, c.-à-d. de la demande d'exécution de la fonction rotate appliquée à l'objet image Flower, le \ serveur exécute la fonction et génère deux messages de réponse (210), l'un (2101) destiné au système client émetteur de la demande d'exécution, et l'autre (2102) destiné au système informatique correspondant à l'adresse courrier "crf@canon. net". Chacun des messages de réponse contient les résultat désirés qui correspondent à chaque destinataire défini dans le message d'appel 200. Chaque message de réponse comprend une paire de balises ouvrante et fermante ( , ) indiquant qu'il s'agit d'un résultat d'exécution d'une fonction (rotate~result). A l'intérieur de cette paire de balises ouvrante et fermante, chaque résultat retourné est défini par un autre couple de balises filles ouvrante et fermante définissant le type du résultat et sa valeur, obtenue par l'exécution de la fonction. Ainsi dans le message de réponse 2101, le résultat de type width retourné au système client a pour valeur 36. Celui de type height a pour valeur 50. De même dans le message de réponse 2102, dont le destinataire est le serveur de courrier correspondant à l'adresse"crf@canon. net", le résultat retourné est de type pixels et a pour valeur la suite d'éléments hexadécimaux : 'A4515BC...'définissant une image dans le format bitmap. En liaison maintenant avec la Figure 3, on va décrire le procédé selon l'invention de demande d'exécution d'une fonction dans un système informatique client compris dans un environnement client-serveur. Plus particulièrement, on va décrire le processus mis en oeuvre dans un système informatique client pour obtenir, à partir de la sélection d'un objet informatique sur le réseau, une interface de cet objet tel que le document 110 (Fig. 1), puis générer un message d'appel de fonction tel que le document 200 (Fig. 2), afin d'obtenir un ou plusieurs messages de réponse tels qu'illustré à la référence 210 (Fig. 2). Le procédé de demande d'exécution d'une fonction selon l'invention est mis en oeuvre dans un système informatique client (aussi désigné par "client" ou "ordinateur client"). Dans un mode de réalisation préféré les moyens informatiques permettant de mettre en oeuvre sont essentiellement des moyens logiciels ou programmes, chargés ou stockés de façon résidente dans l'ordinateur client. Le procédé de demande d'exécution selon l'invention est alors mis en oeuvre lorsque ce ou ces programmes sont exécutés dans l'ordinateur client. Comme représenté à la Fig. 3, le procédé de demande d'exécution d'une fonction selon l'invention débute par une étape E301 au cours de laquelle l'utilisateur du système client obtient l'interface d'un objet informatique (par ex. une image) sélectionné par exemple par navigation Internet sur un site Web. L'objet informatique est hébergé par un système informatique serveur (aussi désigné par"serveur"ou"ordinateur serveur"). Cette interface, dans sa forme brute, est un document XML tel que celui (110) représenté à la Fig. 1. Ce document interface peut être utilisé tel quel et être affiché sur un écran d'ordinateur, ou bien être traité d'abord par un logiciel d'interface graphique de manière à être plus facilement exploitable par un utilisateur novice en informatique. A l'étape E303 suivante, une liste des fonctions applicables à l'objet est affichée à l'écran sous une forme quelconque. Par exemple, selon l'interface 110, on pourra afficher les mots clés suivants :"Rotation de l'image", "Redimensionner l'image", sur lesquels l'utilisateur pourra cliquer pour sélectionner une fonction. A l'étape E305, on attend que l'utilisateur sélectionne une fonction qu'il désire voir exécuter sur l'objet informatique considéré. En réalité, l'utilisateur peut sélectionner le cas échéant plusieurs fonctions, mais le processus étant le même pour chaque fonction sélectionnée, on ne considèrera ici qu'une seule fonction sélectionnée, afin de simplifier l'exposé. Lorsqu'une fonction a été sélectionnée par l'utilisateur, on détermine (E307) les types de résultats différents qui peuvent être retournés suite à l'exécution de la fonction. Les types de résultats retournés sont déterminés à partir des informations (1101) d'identification de type de résultat, codées dans l'interface (110). Ensuite, à titre d'exemple, une fenêtre de dialogue pourra être affichée à l'écran. Dans cette fenêtre les différents types de résultat (1101) seront présentés à l'utilisateur. On attend alors que l'utilisateur fasse son choix (étape E309). Selon l'invention, l'étape E309 de sélection d'un ou plusieurs types de résultat désiré inclut, pour chacun des types de résultat sélectionnés, la détermination du (ou des) système (s) informatique (s) destinataire (s) ("destinataire (s)") du résultat correspondant, le message d'appel (200) incluant alors des informations (2002) d'identification du ou des destinataires, par ex. telles que celles exposées supra en liaison avec la Fig. 2. Lorsque l'utilisateur a sélectionné un ou plusieurs types de résultats, par ex. en cliquant à l'écran sur des mots clés représentant ces types de résultats, on génère (E311) un message d'appel de la fonction choisie précédemment. Dans le mode de réalisation préféré de l'invention, il s'agit d'un message XML tel que décrit plus haut (200) en liaison avec la Fig. 2. Comme exposé plus haut, le message d'appel (200) inclut une liste (2001) de résultats désirés, chaque élément de la liste étant indicatif d'un type de résultat sélectionné. Le message (200) d'appel de fonction, encore désigné par"demande d'exécution de fonction", est alors envoyé (étape E313) à l'ordinateur serveur au travers du réseau. Le serveur traite le message d'appel de fonction (cf. infra, description en liaison avec les figures 4 et 5) puis envoie un message de réponse d'exécution de la fonction aux différents destinataires spécifiés dans le message d'appel (200). Le système client reçoit la réponse d'exécution qui lui est destinée, à l'étape E315. Cette réponse contient les résultats d'exécution correspondant aux types de résultat, parmi ceux sélectionnés par l'utilisateur (E309), dont le destinataire correspond au système client. Enfin (E317), les résultats d'exécution sont affichés à l'écran dans le système client. En liaison maintenant avec la Figure 4, on va décrire un procédé d'exécution d'une fonction dans un système informatique serveur d'un environnement client-serveur, selon un mode de réalisation préféré de l'invention. Plus particulièrement, on va décrire le processus mis en oeuvre dans un système informatique serveur pour traiter un message d'appel de fonction tel que le document 200 (Fig. 2), afin d'obtenir un ou plusieurs messages de réponse tel qu'illustré à la référence 210 (Fig. 2). Le procédé d'exécution d'une fonction selon l'invention est mis en oeuvre dans un système informatique serveur (aussi désigné par"serveur"ou "ordinateur serveur"). Dans un mode de réalisation préféré les moyens informatiques permettant de mettre en oeuvre ce procédé sont essentiellement des moyens logiciels ou programmes chargés ou stockés de façon résidente dans l'ordinateur serveur. Le procédé d'exécution selon l'invention est alors mis en oeuvre lorsque ce ou ces programmes sont exécutés dans l'ordinateur serveur. Comme représenté à la Fig. 4, le procédé d'exécution d'une fonction selon l'invention débute par une étape E400 au cours de laquelle le serveur reçoit un message (200) d'appel de fonction. Ensuite, selon le mode de réalisation préféré de l'invention, deux processus (E41, E42) sont exécutés en parallèle. Ces deux processus, assurent respectivement : - le traitement de l'appel de fonction (E41) ; - le traitement des réponses (E42). Les processus E41 et E42 interagissent au moyen d'une pile (stack en anglais). Cette pile peut être par exemple constituée d'un fichier XML ou d'un emplacement mémoire particulier. Dans le processus E41, on commence (E410) par extraire les informations d'appel de fonction du message (200) reçu. Plus précisément, il s'agit, d'une part, d'identifier la fonction appelée et d'en extraire les arguments. Dans l'exemple choisi (message 200), l'argument de la fonction rotate est l'angle de rotation de l'image dont la valeur choisie par l'utilisateur est'90' (degrés). D'autre part, il s'agit d'extraire la liste de résultats sélectionnés par l'utilisateur associée aux informations (2002) d'identification du (ou des) système (s) informatique (s) destinataire (s) pour chaque type de résultat désiré. Dans l'exemple du message 200 les résultats sélectionnés sont les informations regroupées sous la référence 2001, les informations d'identification de destinataire étant indiquées par la référence 2002. A l'étape E412, la fonction (rotate) est exécutée en lui appliquant les arguments extraits (angle). Au cours de l'exécution de la fonction, au fur et à mesure de l'obtention des résultats, ceux-ci sont insérés (E414) dans la pile (mémoire temporaire). Le processus E42 de traitement des messages de réponse commence quant à lui par l'étape E420 au cours de laquelle on génère des messages de réponse vides. Comme cela sera exposé plus bas, en liaison avec les figures 5 et 6, ces messages vides sont constitués de"squelettes"XML contenant la paire de balises XML ouvrante et fermante de plus haut niveau, ainsi que pour chaque résultat désiré, une paire de balise ouvrante et fermante ne contenant pas encore la valeur du résultat considéré. D'autre part, on génère autant de messages de réponse vides distincts, qu'il y a de destinataires identifiés différents dans le message d'appel de la fonction. A l'étape suivante, E422, on attend l'apparition d'un nouveau résultat d'exécution dans la pile, et on l'ajoute dans le (ou les) message (s) de réponse correspondant (s) (c. -à-d. destinées) au (x) destinataire (s) spécifié (s) dans le message d'appel de la fonction) si ce résultat est désiré par l'utilisateur. En d'autres termes, on sélectionne parmi les résultats d'exécution obtenus lors de l'exécution de la fonction, ceux correspondant à la liste (2001) de résultats désirés extraite du message d'appel (200). Les messages de réponse sont ainsi complétés au fur et à mesure de l'apparition des résultats dans la pile. Cela apporte notamment un gain de temps dans l'exécution du processus global de traitement de la requête d'exécution (message d'appel) de la fonction par le système serveur. On génère donc un message réponse différent par destinataire identifié dans le message d'appel (2001), chaque message de réponse contenant le ou les résultats correspondants. Enfin, à l'étape E424, les messages (2101,2102) de réponse d'exécution de la fonction sont envoyés à leur destinataire respectif. La Figure 5 est un organigramme détaillant certaines opérations accomplies au cours du processus (E42, Fig. 4) de traitement des réponses, au cours duquel les différents messages de réponse sont créés et complétés au fur et à mesure de l'apparition des résultats d'exécution dans la pile. A la Fig. 5, on commence par l'étape E420 (celle de la Fig. 4) au cours de laquelle des messages de réponse vides sont générés. Il y a autant de messages de réponse vides que de destinataires différents spécifiés dans le message d'appel de la fonction. On passe ensuite à l'étape E4220 au cours de laquelle on attend qu'un résultat d'exécution (RES) soit inséré dans la pile. Lorsqu'un résultat a été obtenu, on sélectionne (E4221) un message de réponse incomplet MSG (à ce moment là il s'agit d'un message vide). A l'étape suivante, E4222, on détermine si le résultat considéré (RES) doit être ou non inclus dans le message incomplet sélectionné. Cette détermination est effectuée par exemple par l'analyse des balises de résultat présentes dans le message incomplet considéré. Si c'est le cas (E4222, Oui), au cours de l'étape E4223, on encode le résultat RES et on l'ajoute dans le message incomplet courant (MSG). Dans le cas contraire (E4222, Non), on passe directement à l'étape E4242 décrite plus bas. A l'étape E4240, on détermine si le message MSG courant est complet, c. -à-d. s'il contient tous les résultats spécifiés dans le message (200) d'appel de fonction. Si c'est le cas (E4240, Oui), on envoie en E4241 le message de réponse complet à son destinataire sur le réseau, puis on passe au test E4242. Si le message n'est pas complet (E4240, Non), on passe directement au test E4242 au cours duquel on détermine s'il existe un autre message de réponse incomplet à traiter. Si c'est le cas (E4242, Oui), on retourne à l'étape E4221 pour sélectionner un autre message de réponse incomplet, et le processus continue comme décrit plus haut. Dans le cas contraire (E4242, Non), il n'y a plus de message de réponse incomplet à traiter. Dans ce cas, on passe au test E4243, dans lequel on détermine si tous les résultats demandés dans le message d'appel de la fonction ont été obtenus. Si c'est le cas (E4243, Oui), le processus est terminé. Dans le cas contraire (E4243, Non), on retourne à l'étape E4220 pour attendre l'arrivée, dans la pile, d'un nouveau résultat d'exécution de la fonction, et le processus continue comme exposé plus haut. La Figure 6 illustre l'interaction entre le processus (E41) d'exécution de la fonction et le processus (E42) de génération des messages de réponse, selon le mode de réalisation de l'invention illustré au dessus en référence aux Figures 4 et 5, et appliqué à titre d'exemple au message d'appel (200) de fonction représenté à la Fig. 2. Comme illustré à la Fig. 6, le message d'appel 200 reçu dans le serveur donne lieu, après avoir été analysé, au déclenchement (601) de l'exécution de la fonction rotate et à l'initialisation (607) de la pile. En parallèle, deux messages de réponse vides sont créés (références 603,607) : MSG1~0 et MSG2~0. Ces messages sont au nombre de deux, puisqu'il y a deux destinataires spécifiés dans le message 200. Les messages MSG1~0 et MSG2~0 correspondent à l'initialisation des messages MSG1 et MSG2 qui seront finalement envoyés à leur destinataire, une fois complétés. Le message MSG1~0 contient les balises correspondantes aux résultats "width" et "height" de la fonction rotate destinés au système client. Le message MSG2~0 contient les balises correspondantes au résultat "pixels" de la fonction rotate, destiné au serveur de courrier d'adresse"crf@canon. net". La valeur de ces résultats n'est pas encore connue (VIDE). En 609, le premier résultat obtenu lors de l'exécution de la fonction rotate est"width", ce résultat est contenu dans une variable du même nom et est stocké dans la pile. En 611, le résultat "width" est alors extrait de la pile, puis encodé dans le message MSG1 pour produire le message de réponse incomplet MSG1~1. De même, lorsque le résultat "height" est produit et inséré dans la pile (en 613), il est récupéré puis encodé également dans MSG1 c.-à-d. dans MSG1~1, le message MSG1~2 est alors produit. La valeur de chacun des résultats width et height est contenue dans MSG1~2 (respectivement'36'et '50'). Le message MSG1, dans l'état MSG1~2, est complet ; il peut être alors envoyé (en 617) à son destinataire, ici, le système informatique client, émetteur de la requête XML (200) d'exécution de fonction. Il est à noter que si un autre résultat, qui est non demandé dans le message d'appel de la fonction, est produit durant l'exécution de la fonction, par exemple le résultat "preview" pour la fonction rotate (voir interface 110), ce résultat sera stocké dans la pile, mais il ne sera pas incorporé ensuite dans un message de réponse (Fig. 5, test E4222, Non). Dans l'exemple représenté à la Fig. 6, le résultat"pixels"est produit à la fin d'exécution (619) de la fonction rotate. Il s'agit alors, dans cet exemple, de la variable de retour de la fonction rotate. La variable de retour Pixels est alors insérée dans la pile (en 621). En 623, la variable Pixels est extraite de la pile et sa valeur encodée dans le message MSG2 précédemment dans l'état MSG2~0. La valeur du résultat "pixels" : la suite hexadécimale'A4515BC...' (format bitmap) est inscrite dans le message de réponse MSG2~0. Le message MSG2 maintenant dans l'état MSG2~1 est complet, et peut donc être envoyé en 625 à son destinataire. Ainsi, à la fin du processus d'exécution de la fonction rotate (effectué en réponse à la réception du message 200 d'appel de fonction dans le serveur), le serveur produit une réponse d'exécution (210, Fig. 2) constituée de deux messages de réponse distincts MSG1 et MSG2 de contenu respectif 2101 et 2102. Il est à noter que si l'utilisateur ne spécifie, dans le message d'appel de la fonction, aucun résultat devant lui être retourné directement (dans le système client qu'il utilise), on peut prévoir que le serveur envoie quand même un message de réponse au système client, ce message de réponse contenant par exemple un message textuel indiquant que l'exécution de la fonction s'est bien déroulée. Bien entendu, la présente invention n'est nullement limitée aux modes de réalisation décrits et représentés, mais englobe, bien au contraire, toute variante à la portée de l'homme du métier. En particulier, l'invention s'applique également à un environnement client-serveur non inscrit dans le contexte d'un réseau de communication. Par exemple, le client et le serveur peuvent être constitués par des applications logicielles distinctes mises en oeuvre au sein d'un même ordinateur. REVENDICATIONS 1. Procédé de demande d'exécution d'une fonction dans un système informatique client ("client") dans un environnement client-serveur, la fonction étant applicable à un objet informatique traité par un système informatique serveur ("serveur"), le procédé comportant les étapes préalables d'obtention (E301) d'une interface (110) de l'objet et de sélection (E303, E305) d'une fonction à partir de l'interface, le procédé étant caractérisé en ce qu'il comporte les étapes suivantes : - détermination (E307) des types de résultats différents retournés suite à l'exécution de la fonction, à partir d'informations (1101) d'identification de type de résultat, codées dans ladite interface (110) ; - sélection (E309) d'au moins un type de résultat désiré à partir desdites informations (1101) d'identification de type de résultat ; - génération (E311) d'un message (200) d'appel de la fonction, le message d'appel incluant une liste (2001) de résultats désirés, chaque élément de la liste étant indicatif d'un type de résultat sélectionné ; - envoi (E313) du message (200) d'appel de la fonction, audit serveur. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape de sélection (E309) d'au moins un type de résultat désiré inclut, pour chaque type de résultat désiré, la détermination d'au moins un système informatique destinataire ("destinataire") du résultat correspondant, le message d'appel (200) incluant des informations (2002) d'identification dudit au moins un destinataire pour chaque type de résultat désiré. 3. Procédé selon la revendication 2, caractérisé en ce qu'il comporte en outre une étape (E315) de réception, en provenance dudit serveur, d'un message (211,212) de réponse d'exécution contenant les résultats correspondant aux types de résultats, parmi ceux sélectionnés, dont le destinataire correspond audit client. 4. Procédé selon la revendication 3, caractérisé en ce qu'il comporte en outre une étape (E317) d'affichage des résultats reçus. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit environnement client-serveur est un réseau de communication, lesdits client et serveur communiquant à distance sur le réseau. 6. Procédé selon la revendication 5, caractérisé en ce que ledit réseau de communication est un réseau de type Internet, ledit client et ledit serveur communiquant en utilisant un protocole de communication de type HTTP. 7. Procédé selon la revendication 6, caractérisé en ce que ladite interface de l'objet informatique, ledit message d'appel de fonction, et lesdits messages de réponse d'exécution de fonction, sont des documents informatiques dont le contenu est représenté dans un langage de balisage de type XML. 8. Procédé selon la revendication 7, caractérisé en ce que lesdites informations (1101) d'identification de type de résultat codées dans ladite interface (110) de la fonction sont codées dans des balises utilisant la syntaxe d'un langage de balisage de type XML Schema. 9. Procédé selon la revendication 7 ou 8, caractérisé en ce que chacun desdits résultats désirés de ladite liste (2001) de résultats désirés contenue dans ledit message (200) d'appel, est représenté par une balise XML, elle-même insérée entre une balise ouvrante ( ) et une balise fermante ( ) prédéterminées, chaque paire de balises ouvrante et fermante prédéterminée définissant une sous-liste de résultats désirés, destinés à un destinataire particulier sur le réseau de communication. 10. Procédé selon la revendication 9, caractérisé en ce que lesdites informations (2002) d'identification de destinataire sont définies par un attribut particulier (to=") du langage XML, inséré dans ladite balise ouvrante ( ) correspondante, dans ledit message (200) d'appel de fonction. 11. Procédé d'exécution d'une fonction dans un système informatique serveur ("serveur"), dans un environnement client-serveur, le procédé comportant une étape préalable (E400) de réception d'un message (200) d'appel de la fonction, en provenance d'un système informatique client ("client"), le procédé étant caractérisé en ce qu'il comporte les étapes suivantes : - extraction (E410) des arguments de la fonction appelée dudit message (200) d'appel ; - extraction (E410) d'une liste (2001) de résultats désirés dudit message (200) d'appel, chaque élément de la liste étant indicatif d'un type de résultat d'exécution désiré en retour par ledit client ; - exécution (E412) de la fonction en lui appliquant les arguments extraits ; - sélection (E422), parmi les résultats obtenus au cours de l'exécution de la fonction, des résultats désirés par ledit client selon la liste (2001) de résultats désirés extraite dudit message (200) d'appel ; - génération (E422) d'un message (210) de réponse d'exécution de fonction, ledit message (210) de réponse contenant les résultats d'exécution désirés par ledit client ; - envoi (E424) dudit message (210) de réponse d'exécution de fonction audit client. 12. Procédé selon la revendication 11, caractérisé en ce que l'étape (E410) d'extraction d'une liste de résultats désirés, inclut l'étape suivante : - extraction, dudit message (200) d'appel, d'informations (2002) d'identification d'au moins un système informatique destinataire ("destinataire") pour chaque type de résultat désiré. 13. Procédé selon la revendication 12, caractérisé en ce que les étapes de génération (E422) et d'envoi (E424) dudit message (211) de réponse audit client, incluent les étapes suivantes : - génération d'un message (2101,2102) de réponse distinct par destinataire identifié, chaque message de réponse contenant le (ou les) résultat (s) correspondant (s) ; - envoi des messages (2101,2102) de réponses aux différents destinataires. 14. Procédé selon l'une quelconque des revendications 11 à 13, caractérisé en ce que ledit environnement client-serveur est un réseau de communication, lesdits client et serveur communiquant à distance sur le réseau. 15. Procédé selon la revendication 14, caractérisé en ce que ledit réseau de communication est un réseau de type Internet, ledit client et ledit serveur communiquant en utilisant un protocole de communication de type HTTP. 16. Procédé selon la revendication 15, caractérisé en ce que ledit message d'appel de fonction, et lesdits messages de réponse d'exécution de fonction, sont des documents informatiques dont le contenu est représenté dans un langage de balisage de type XML. 17. Procédé selon la revendication 16, caractérisé en ce que chacun desdits résultats désirés de ladite liste (2001) de résultats désirés contenue dans ledit message (200) d'appel, est représenté par une balise XML, ellemême insérée entre une balise ouvrante ( ) et une balise fermante ( ), chaque paire de balises ouvrante et fermante définissant une sous-liste de résultats désirés, destinés à un destinataire particulier sur le réseau de communication. 18. Procédé selon la revendication 17, caractérisé en ce que lesdites informations (2002) d'identification de destinataire sont définies par un attribut particulier (to=") du langage XML, inséré dans ladite balise ouvrante ( ) correspondante, dans ledit message (200) d'appel de fonction. 19. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit message (200) d'appel de la fonction est généré dans ledit système informatique client à la suite de la mise en oeuvre d'un procédé de demande d'exécution d'une fonction selon l'une quelconque des revendications 1 à 10. 20. Système informatique client, caractérisé en ce qu'il comporte des moyens adaptés à la mise en oeuvre d'un procédé de demande d'exécution d'une fonction selon l'une quelconque des revendications 1 à 10. 21. Système informatique serveur, caractérisé en ce qu'il comporte des moyens adaptés à la mise en oeuvre d'un procédé d'exécution d'une fonction selon l'une quelconque des revendications 11 à 19. 22. Réseau de communication comportant au moins un système informatique client selon la revendication 20 et au moins un système informatique serveur selon la revendication 21. 23. Programme d'ordinateur sur un support d'informations, caractérisé en ce qu'il comprend des instructions permettant de mettre en oeuvre un procédé de demande d'exécution d'une fonction selon l'une quelconque des revendications 1 à 10, lorsque ledit programme est chargé et exécuté dans un système informatique client. 24. Programme d'ordinateur sur un support d'informations, caractérisé en ce qu'il comprend des instructions permettant de mettre en oeuvre un procédé d'exécution d'une fonction selon l'une quelconque des revendications 11 à 19, lorsque ledit programme est chargé et exécuté dans un système informatique serveur.