FR2830349A1 - Procede et dispositif d'execution d'une fonction dans un serveur informatique, ladite fonction retournant des resultats multiples selectionnables - Google Patents

Abstract

Un procédé d'exécution d'une fonction dans un système informatique serveur ( " serveur " ), dans un environnement client-serveur, ladite fonction pouvant retourner une pluralité de résultats différents, et étant applicable à un objet informatique. Le procédé comporte une étape préalable de réception (E501) d'un message d'appel de la fonction en provenance d'un système informatique client ( " client " ), et comporte ensuite les étapes suivantes : - extraction (E503) du message d'appel d'une liste de résultats désirés, chaque élément de la liste étant indicatif d'un type de résultat d'exécution désiré en retour par le client; - obtention (E507) d'un ensemble de sous-programmes associés à la fonction, chaque sous-programme étant responsable de la génération d'un résultat particulier parmi tous les résultats différents pouvant être retournés suite à l'exécution de la fonction; - parcours (E513, E527) de la liste de résultats désirés, et pour chaque résultat désiré, recherche et sélection (E515) du sous-programme permettant de générer le résultat désiré considéré; - exécution (E509) du sous-programme de traitement de la fonction et exécution (E521) des sous-programmes sélectionnés; - génération (E505, E525) d'une réponse d'exécution de fonction, la réponse contenant les résultats produits par l'exécution des sous-programmes sélectionnés; - envoi (E529) de la réponse d'exécution de fonction au client.

Description

<Desc/Clms Page number 1>

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 un procédé d'exécution d'une fonction, dans un système informatique serveur ; la fonction étant applicable à un objet informatique, et pouvant retourner une pluralité de résultats différents.

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 un système informatique apte à mettre en oeuvre le procédé précité.

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++.

<Desc/Clms Page number 2>

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

<Desc/Clms Page number 3>

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.

<Desc/Clms Page number 4>

Dans le document constitué par la demande de brevet français NO 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 NO 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 de données 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.

<Desc/Clms Page number 5>

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 en particulier 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é d'exécution d'une fonction dans un système informatique serveur ("serveur"), dans un environnement clientserveur ; cette fonction pouvant retourner une pluralité de résultats différents, et étant applicable à un objet informatique. Ce 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"), et est remarquable en ce qu'il comporte les étapes suivantes : - extraction du message d'appel d'une liste de résultats désirés, chaque élément de la liste étant indicatif d'un type de résultat d'exécution désiré en retour par le client ; - obtention d'un ensemble de sous-programmes associés à la fonction, chaque sous-programme étant responsable de la génération d'un résultat particulier parmi tous les résultats différents pouvant être retournés suite à l'exécution de la fonction ; - parcours de la liste de résultats désirés, et pour chaque résultat désiré, recherche et sélection du sous-programme permettant de générer le résultat désiré considéré ; - exécution du sous-programme de traitement de la fonction et exécution des sous-programmes sélectionnés ;

<Desc/Clms Page number 6>

- génération d'une réponse d'exécution de fonction, la réponse contenant les résultats produits par l'exécution des sous-programmes sélectionnés ; - envoi de la réponse d'exécution de fonction au client.

Ainsi, en n'exécutant que les sous-programmes associés à la fonction qui permettent d'obtenir les résultats demandés par le système client, on gagne en rapidité de traitement de la fonction dans le système serveur, et donc en temps de réponse vis-à-vis du client. D'autre part, en envoyant une réponse d'exécution ne contenant que les résultats demandés par le système client, on évite à ce dernier de trier les résultats reçus pour ne sélectionner que ceux désirés. Par ailleurs, dans le contexte d'un réseau de communication, on réduit aussi la charge de travail du réseau.

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'au moins un système informatique destinataire pour chaque type de résultat désiré.

Par ailleurs, les étapes de génération et d'envoi de la réponse d'exécution 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, 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 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.

<Desc/Clms Page number 7>

La présente invention concerne encore un réseau de communication comportant au moins un système informatique serveur, tel que brièvement exposé ci-dessus.

Selon un autre aspect, l'invention concerne aussi 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 un tel programme 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 ce système informatique, programme d'ordinateur, et de ce support d'informations, sont identiques à ceux du procédé 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 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 documents informatiques, 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 ;

<Desc/Clms Page number 8>

- la Figure 3 est un organigramme illustrant un procédé de demande d'exécution d'une fonction dans un système informatique client d'un environnement client-serveur ; - la Figure 4 représente la structure d'une table stockée dans la mémoire d'un système informatique serveur selon l'invention, dans laquelle sont mémorisées les informations relatives aux fonctions applicables à un objet informatique ; - la Figure 5, composée des figures 5A-5B, est un organigramme illustrant un procédé d'exécution d'une fonction dans un système informatique serveur d'un environnement client-serveur, selon un mode préféré de réalisation de l'invention.

Dans le mode de réalisation décrit et illustré aux figures, l'environnement client-serveur est le Web sur l'Internet.

La Figure 1 représente un exemple de deux documents informatiques 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 :" < image... > "et" < /image > ". 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

<Desc/Clms Page number 9>

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) 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 : < rotate > et < /rotate > . La première balise < angle type="xs : float/ > 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. < width.../ > ) 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 returned lorsqu'il est égal à'true'signifie que le résultat correspondant est

<Desc/Clms Page number 10>

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 documents informatiques, décrivant respectivement un message (200) d'appel de la fonction"rotate" définie dans le document 110, et une réponse (210) obtenue après exécution de la fonction par le système serveur. Ces 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 : < message > et < /message > . 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 : < rotate > et < /rotate > .

L'élément < angle > 90 < /angle > 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 ( < answer > ) et une balise fermante

<Desc/Clms Page number 11>

( < /answer > ). Chaque paire de balises ouvrante et fermante ( < answer > , < /answer > ) 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 ( < answer > ).

Dans l'exemple choisi, cette information d'identification de destinataire : to='mailto : caf 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" seton te protocote 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 (2101,2102) comprend une paire de balises ouvrante et fermante rotate-result... > , < /rotateresult > ) 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.

<Desc/Clms Page number 12>

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 un procédé 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 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 de fonction 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 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

<Desc/Clms Page number 13>

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, à partir de 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 la fonction correspondante.

A l'étape E305, on attend que l'utilisateur sélectionne la fonction à 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).

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) destinataire (s), 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.

<Desc/Clms Page number 14>

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 alors 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.

La Figure 4 représente la structure d'une table stockée en mémoire du système informatique serveur, dans laquelle sont mémorisées les informations relatives aux fonctions applicables à un objet informatique considéré.

Ainsi, dans la table 400 donnée à titre d'exemple à la Fig. 4, dans la colonne"Fonction"sont inscrits les noms des fonctions applicables à une image numérique donnée. Ici, seulement deux fonctions, rotate et countpixels, sont données.

Dans la seconde colonne"Sous-programme principal"est inscrit le nom du sous-programme à appeler pour traiter la fonction correspondante. Ainsi pour la fonction rotate le sous-programme à appeler est"doRot/on", alors que pour la fonction"countpixels", le sous-programme à appeler est

"doCountPixels".

Dans la troisième colonne "Résultat pouvant être retourné"sont inscrits les différents types de résultats pouvant être retournés par une fonction

<Desc/Clms Page number 15>

considérée. Ainsi, pour la fonction rotate, quatre types de résultats peuvent être retournés : width (largeur de l'image), height (hauteur de l'image), preview (prévisualisation, c'est-à-dire affichage d'une imagette) et pixels (pixels de l'image, c'est-à-dire obtention de l'image dans son format normal). De même, pour la fonction countpixels trois types de résultats différents peuvent être retournés : pixelNumber (nombre de pixels), width et height.

Dans la quatrième colonne"Sous-programme secondaire"sont inscrits les noms des sous-programmes, responsable chacun de la génération du type de résultat correspondant dans la table 400 (c.-à-d., inscrit sur la même ligne) dans la colonne"Résultat pouvant être retourné".

Ainsi, pour la fonction rotate, le sous-programme principal doRotation permet de réaliser la rotation de l'image considérée, et selon les types de résultats demandés, tout ou partie des sous-programmes secondaires seront appelés : - GetWidth pour obtenir la largeur de l'image ; - GetHeight pour obtenir la hauteur de l'image ;

- GetPreview pour obtenir l'imagette (thumbnail) de prévisualisation ; - GetPixels pour obtenir tous les pixels de l'image, c.-à-d., obtenir l'image dans sa taille originale (format bitmap).

De même, pour la fonction countpixels, le sous-programme principal

doCountPixels permet de calculer le nombre de pixels de l'image, et les sous- programmes secondaires GetWidth et GetHeight, respectivement, la largeur et la hauteur de l'image.

On remarquera ici que la fonction countpixels retournant nécessairement

le résultat pixelNumber dont la valeur est le nombre de pixels de l'image, la présence de la chaîne de caractères :"'='"dans la colonne"Sous-programme secondaire", signifie que le résultat pixelNumber est directement produit par le sous-programme principal (doCountPixels) et non par un sous-programme secondaire.

Ainsi chaque sous-programme associé à la fonction est identifié dans un champ prédéfini de la table (400). La table 400, mémorisée dans le serveur, est

<Desc/Clms Page number 16>

utilisée par ce dernier pour exécuter une fonction sur un objet informatique, selon un procédé d'exécution de fonction conforme à l'invention.

On notera ici que chacun des sous-programmes (principal et secondaires) peut être écrit dans un langage de programmation différent de celui des autres sous-programmes, et différent de celui du programme, tournant dans le serveur, qui assure le traitement de la requête d'exécution de la fonction (c. -à-d. le traitement du message d'appel de la fonction), envoyée par le système client.

Cette approche"modulaire"du programme d'exécution de fonction selon l'invention, permet notamment la réutilisation de modules logiciels existants, et de s'affranchir de la dépendance vis-à-vis d'une plate-forme logicielle particulière, liée à l'architecture client-serveur (par ex. le réseau de communication), ou bien liée au système informatique serveur.

En liaison avec la Figure 5, composée des figures 5A-5B, 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éponses tels 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 d'ordinateur, 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 Figure 5A, le procédé d'exécution d'une fonction débute par l'étape E501 au cours de laquelle le serveur reçoit un message

<Desc/Clms Page number 17>

(200) d'appel de fonction. Ensuite, à l'étape E503, on extrait du message (200) reçu, les informations d'appel de la fonction.

Plus précisément, il s'agit d'extraire les arguments de la fonction appelée. 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 d'un ou plusieurs systèmes informatiques destinataires 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. La liste de résultats désirés par le client est donc constituée, dans cet exemple, par les types de résultats suivants : width, height, pixels.

A l'étape E505, on génère des messages de réponse vides (MSG). 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é.

On génère autant de messages de réponses vides distincts, qu'il y a de destinataires identifiés différents dans le message d'appel de fonction.

Ainsi, dans l'exemple du message 200, les deux messages vides suivants seront créés :

<tb>
<tb> MSG1 <SEP> : <SEP> MSG2 <SEP> :
<tb> < rotateresutt > <SEP> < rotateresu <SEP> ! <SEP> t >
<tb> < width > VIDE < /width > <SEP> < pixels > VIDE < /pixels >
<tb> < height > VIDE < /height > <SEP> < /rotate~result >
<tb> < /rotate~result >
<tb>

<Desc/Clms Page number 18>

A l'étape E507 qui suit, on recherche en mémoire l'ensemble des sousprogrammes associés à la fonction rotate identifiée dans le message d'appel de fonction (200). En pratique, on va lire en mémoire la table 400 associée à l'objet informatique auquel doit s'appliquer la fonction.

Après avoir identifié le nom de la fonction (rotate) dans la table 400, on identifie le sous-programme principal de traitement de la fonction, soit, dans l'exemple présent, le sous-programme dorotation (voir Fig. 4).

A l'étape E509, ce sous-programme "principal" de traitement de la fonction est alors exécuté, et le résultat d'exécution correspondant est

sauvegardé dans un registre mémoire Rf (étape E511).

Ici, le sous-programme exécuté est dorotation, et le résultat obtenu est l'image issue de la rotation à 90 degrés de l'image d'origine.

Le processus d'exécution continue à la Figure 5B, par l'étape E513. Au cours de cette étape, on sélectionne un résultat demandé par l'utilisateur dans la liste (2001) de résultats, extraite du message (200) d'appel de fonction.

Ensuite, à l'étape E515, on recherche dans la table 400, le sousprogramme (secondaire) responsable de la génération du résultat sélectionné à l'étape précédente.

Ainsi, dans l'exemple choisi et illustré dans lequel la liste 2001 comprend les trois résultats : width, height, et pixels, les trois sous-programmes dits "secondaires"correspondant, identifiés dans la table 400, seront respectivement : GetWidth, GetHeight, GetPixels.

A l'étape de test E517, on détermine si le sous-programme secondaire obtenu à l'étape précédente (E515) est le sous-programme principal de la fonction.

En pratique, on détermine si le champ correspondant de la colonne "Sous-programme secondaire", dans la table 400, contient ou non la chaîne de caractères"'='". C'est le cas par exemple pour le résultat pixelNumber.

Si c'est le cas (E517, OUI), on copie le contenu du registre Rf dans un second registre R. En effet, le registre Rf contient déjà le résultat d'exécution du sous-programme principal de la fonction, exécuté lors de l'étape E509.

<Desc/Clms Page number 19>

Dans le cas contraire (E517, NON), à l'étape E521, le sous-programme secondaire obtenu (E515) est exécuté. Puis le résultat obtenu est mémorisé dans le registre R (étape E523).

A l'étape E525, on insère le contenu du registre R dans le (ou les) message (s) de réponse correspondant (s) (MSG1 ou MSG2).

Ainsi, à l'étape E525, si le résultat désiré dont la valeur vient d'être obtenue est width, la valeur de ce résultat (36 pixels) est insérée dans le message de réponse MSG1, qui est alors dans l'état suivant :
MSG1 : < rotateresult > < width > 36 < /width > < height > VIDE < /height > < /rotateresult >
A l'étape E527 qui suit, on détermine, à partir de la liste (2001) de résultats, si un autre résultat demandé reste à obtenir. Si c'est le cas (E527, OUI) on retourne à l'étape E513, et le processus recommence comme exposé plus haut.

A l'inverse, si tous les résultats demandés ont été obtenus (E527, NON), on envoie (étape E529) les différents messages de réponse à leur destinataire respectif, identifié (Fig. 2,2002) dans le message (200) d'appel de la fonction.

Le processus d'exécution de la fonction dans le serveur est alors terminé.

Ainsi, dans l'exemple choisi et illustré, à la fin du processus d'exécution de la fonction rotate (effectué en réponse à la réception dans le serveur du message 200 d'appel de fonction), 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.

Le message MSG1 est envoyé au système informatique client, émetteur de la requête XML (200) d'exécution de la fonction rotate. Le message MSG2

<Desc/Clms Page number 20>

est, quant à lui, envoyé au serveur de courrier d'adresse"crf@canon. net" (selon l'information 2002 spécifiée dans le message 200).

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.

Claims (14)

1. REVENDICATIONS 1. Procédé d'exécution d'une fonction dans un système informatique serveur ("serveur"), dans un environnement client-serveur, ladite fonction pouvant retourner une pluralité de résultats différents, et étant applicable à un objet informatique, le procédé comportant une étape préalable de réception (E501) d'un message d'appel (200) 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 (E503) du message d'appel d'une liste (2001) de résultats désirés, chaque élément de la liste étant indicatif d'un type de résultat d'exécution désiré en retour par le client ; - obtention (E507) d'un ensemble de sous-programmes associés à la fonction, chaque sous-programme étant responsable de la génération d'un résultat particulier parmi tous les résultats différents pouvant être retournés suite à l'exécution de la fonction ; - parcours (E513, E527) de la liste de résultats désirés, et pour chaque résultat désiré, recherche et sélection (E515) du sous-programme permettant de générer le résultat désiré considéré ; - exécution (E509) du sous-programme de traitement de la fonction et exécution (E521) des sous-programmes sélectionnés ; - génération (E505, E525) d'une réponse (210) d'exécution de fonction, ladite réponse contenant les résultats produits par l'exécution des sousprogrammes sélectionnés ; - envoi (E529) de la réponse (210) d'exécution de fonction audit client.
2. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape (E503) d'extraction d'une liste de résultats désirés, inclut l'étape suivante :

   <Desc/Clms Page number 22>

   - 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é.
3. 3. Procédé selon la revendication 2, caractérisé en ce que les étapes de génération (E505, E525) et d'envoi (E529) de ladite réponse (210) d'exécution audit client, incluent les étapes suivantes : - génération d'un message (2101,2102) de réponse différent par destinataire identifié, chaque message de réponse contenant le ou les résultats correspondants ; - envoi desdits messages (2101,2102) de réponses aux différents destinataires.
4. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le sous-programme de traitement de la fonction, dit "sous-programme principal", et les sous-programmes associées à la fonction, dits"sous-programmes secondaires", sont identifiés dans des champs prédéfinis contenus dans une table (400) mémorisée dans ledit serveur.
5. 5. Procédé selon la revendication 4, caractérisé en ce que ladite table (400) comporte un nombre prédéfini de premiers champs contenant chacun un identifiant du type de résultat pouvant être retourné par la fonction, et un même nombre de seconds champs contenant chacun un identifiant du sous-programme secondaire permettant l'obtention du type de résultat correspondant.
6. 6. Procédé selon la revendication 5, caractérisé en ce que lorsqu'un type de résultat est directement produit par le sous-programme principal de traitement de la fonction, cela est indiqué dans ladite table (400) par la

   <Desc/Clms Page number 23>

   présence d'un identifiant prédéfini particulier dans le champ correspondant parmi ceux contenant les identifiants desdits sous-programmes secondaires.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, 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.
8. 8. Procédé selon la revendication 7, 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.
9. 9. Procédé selon la revendication 8, 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.
10. 10. Procédé selon la revendication 8 ou 9, 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 ( < answer > ) et une balise fermante ( < /answer > ), 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.
11. 11. Procédé selon la revendication 10, 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 ( < answer > ) correspondante, dans ledit message (200) d'appel de fonction.

    <Desc/Clms Page number 24>
12. 12. 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 1 à 11.
13. 13. Réseau de communication comportant au moins un système informatique serveur selon la revendication 12.
14. 14. 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 1 à 11, lorsque ledit programme est chargé et exécuté dans un système informatique serveur.