FR2841998A1 - Procede d'execution sur une station d'un reseau de communication d'un programme informatique represente dans un langage de balisage - Google Patents
Procede d'execution sur une station d'un reseau de communication d'un programme informatique represente dans un langage de balisage Download PDFInfo
- Publication number
- FR2841998A1 FR2841998A1 FR0208374A FR0208374A FR2841998A1 FR 2841998 A1 FR2841998 A1 FR 2841998A1 FR 0208374 A FR0208374 A FR 0208374A FR 0208374 A FR0208374 A FR 0208374A FR 2841998 A1 FR2841998 A1 FR 2841998A1
- Authority
- FR
- France
- Prior art keywords
- execution
- function
- communication network
- station
- address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/31—Programming languages or programming paradigms
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Stored Programmes (AREA)
- Multi Processors (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Un procédé d'exécution sur une station d'un réseau de communication d'un programme informatique représenté dans un langage de balisage comprend une étapes de lecture d'une balise comprenant l'identification d'une instruction ; une étape d'identification (E40) d'une adresse électronique associée à la balise comprenant l'identification d'une instruction ; une étape de comparaison (E41) de l'adresse électronique avec l'adresse locale de la station ; et une étape d'envoi (E43, E45) si l'adresse électronique est différente de l'adresse locale, d'une requête à une station serveur du réseau correspondant à l'adresse électronique en vue d'obtenir l'exécution de l'instruction.Utilisation notamment pour exécuter un programme informatique réparti sur différents serveurs d'un réseau de communication.
Description
La présente invention concerne un procédé d'exécution sur une
station d'un réseau de communication d'un programme informatique.
Ce programme informatique est représenté dans un langage de balisage, en utilisant par exemple la syntaxe du langage de balisage XML (en
anglais, "eXtented Markup Language").
Les réseaux de communication prennent une place sans cesse croissante dans l'utilisation des ordinateurs de telle sorte que, de plus en plus, les programmes informatiques eux-mêmes ont besoin pour fonctionner d'être
reliés à d'autres ordinateurs via un réseau de communication.
Ainsi il n'est pas rare qu'un programme informatique soit réparti dans le réseau de communication, en utilisant au mieux les fonctionnalités et les
capacités de traitement de chaque serveur du réseau de communication.
Aussi, l'exécution d'un tel programme sur un ordinateur local, sans connexion au réseau de communication, ne peut plus être mise en oeuvre ou
sinon dans un mode dégradé.
Il devient donc de plus en plus important de pouvoir accéder aux fonctionnalités offertes par les différents programmes stockés sur les différents
serveurs d'un réseau de communication.
Il existe aujourd'hui plusieurs techniques d'accès et de mise en
oeuvre des programmes informatiques distants.
Une première technique dite de RPC (en anglais, "Remote Procedure Calf'), permet à un programme local d'envoyer une requête de demande d'exécution de fonction à un programme distant, ce dernier exécutant
la fonction et retournant le résultat demandé.
Toutefois, cette technique RPC présente un certain nombre d'inconvénients. Premièrement, elle nécessite de connaître précisément à l'avance la définition de la fonction à exécuter à distance. En outre, elle oblige le programmeur à modifier considérablement le code de son programme pour lui permettre d'accéder à des fonctions distantes. Enfin, le programmeur doit traiter différemment les appels de fonction locale et les appels de fonction distante. Il existe également une deuxième technique consistant à télécharger
à la demande une fonction.
Cette technique consiste à télécharger un premier élément d'un programme depuis un serveur distant, puis, au fur et à mesure que l'exécution de ce programme fait appel à des fonctions contenues dans d'autres éléments
du programme, on télécharge ces autres éléments depuis un serveur distant.
Cette technique est mise en ceuvre grâce au langage de programmation Java , utilisée par certains navigateurs (en anglais "Browser")
sur le Web.
Bien que simple à utiliser, cette technique nécessite que la totalité du programme à exécuter soit initialement stockée sur le serveur distant, ce qui empêche l'utilisation de modèles distribués dans lequel le programme est découpé en plusieurs sous-programmes répartis sur différents ordinateurs du
réseau de communication.
Par ailleurs, cette technique ne permet pas le téléchargement à partir de plusieurs ordinateurs du réseau des différents sous-programmes constituant
un programme.
Parallèlement à cette technique de traitement d'un programme réparti sur un réseau de communication, il existe la technique des "hypertiens" (en anglais, "hyperlinks"). Cette technique permet à un document dit "hypertexte" (en anglais, "hypertext') de référencer des documents stockés sur
des serveurs distants.
Dans son principe, ces liens hypertextes consistent à encadrer un mot ou une phrase d'un document électronique par une balise (en anglais, "tag") contenant l'adresse du document électronique correspondant au mot ou à
la phrase du document traité.
En pratique, les mots ou phrases ainsi encadrés par une balise sont affichés à l'écran dans une couleur particulière de telle sorte que l'utilisateur peut cliquer sur l'un d'entre eux. Le document courant est alors remplacé à l'écran par le document référencé grâce à un logiciel du type navigateur permettant de rechercher sur le réseau de communication le document associé
à cette balise.
Cette technique est d'une grande simplicité d'emploi pour le référencement de documents électroniques répartis sur plusieurs serveurs d'un
réseau de communication.
L'invention a pour but de proposer un nouveau procédé d'exécution sur un réseau de communication d'un programme informatique réparti sur plusieurs serveurs dans un réseau de communication, sans les inconvénients
de l'état de la technique.
A cet effet, un procédé d'exécution sur une station d'un réseau de communication d'un programme informatique représenté dans un langage de balisage comprend les étapes suivantes: - lecture d'une balise comprenant l'identification d'une instruction; - identification d'une adresse électronique associée à ladite balise comprenant l'identification d'une instruction; - comparaison de ladite adresse électronique avec l'adresse locale de ladite station; et - envoi si ladite adresse électronique est différente de ladite adresse locale, d'une requête à une station serveur du réseau correspondant à
ladite adresse électronique en vue d'obtenir l'exécution de ladite instruction.
Ainsi, grâce à l'introduction dans un programme informatique de balise incluant une adresse électronique référençant un sous-programme, du type d'un lien hypertexte, l'exécution d'un tel programme est grandement
facilitée à partir d'une station d'un réseau de communication.
En outre, que cette adresse électronique référence l'adresse locale de la station sur laquelle est exécuté le programme ou l'adresse d'une station distante du réseau de communication, le même modèle de référencement peut
être utilisé pour les deux types d'appel d'instruction.
Cela facilite considérablement la tâche du programmeur et permet sans inconvénient de passer, pour certaines parties du programme informatique de l'exécution d'instruction locale à l'exécution d'instruction distante et vice versa. Le même modèle de référencement peut être utilisé tant pour l'exécution de fonctions hébergées sur des stations distantes que pour la mise
à jour ou la lecture de variables mémorisées sur des stations distantes.
En outre, l'exécution d'un tel programme informatique peut être tout à fait réalisée lorsque les différents sous-programmes ou fonctions sont répartis
sur différents serveurs dans un réseau de communication.
En particulier, des fonctions peuvent être réalisées de manière optimale par les serveurs ayant des caractéristiques ou capacités de traitement
adaptées à ces fonctions.
L'invention permet ainsi de manière générale d'exécuter des programmes informatiques référençant d'autres programmes informatiques par
le biais de liens de type hypertexte.
Selon une caractéristique préférée de l'invention, à l'étape d'envoi, une requête de demande d'exécution de la fonction à distance est envoyée à la
station serveur du réseau de communication.
Ainsi, la fonction peut être exécutée à distance sur le serveur
hébergeant cette fonction, en utilisant les capacités de traitement de ce serveur.
De manière pratique, le procédé d'exécution comprend alors une
étape de réception du résultat d'exécution de cette fonction.
Selon une caractéristique alternative de l'invention, à l'étape d'envoi, une requête de demande d'obtention du code de la fonction à exécuter est
envoyée à la station serveur du réseau de communication.
Ainsi, l'exécution de la fonction est réalisée directement sur la station mettant en oeuvre le programme informatique, à partir du code d'exécution réceptionné. De préférence, ce procédé comprend en outre une étape de mémorisation dudit code de la fonction réceptionnée, afin de permettre l'utilisation ultérieure de ce code en cas d'appels successifs de la fonction dans
un même programme informatique.
Selon une autre caractéristique alternative de l'invention, à l'étape d'envoi, une requête d'obtention d'une valeur variable est envoyée à la station
serveur du réseau de communication.
Ainsi, une valeur variable peut être obtenue directement lors de l'exécution du programme à partir d'une station serveur du réseau conservant et
mettant à jour régulièrement cette valeur variable.
Selon une autre caractéristique alternative de l'invention, à l'étape d'envoi, une requête de mise à jour d'une variable est envoyée à la station
serveur du réseau de communication.
La mise à jour d'une valeur variable peut ainsi être exécutée à distance, puis une réponse envoyée à la station du serveur sur lequel est
exécuté le programme informatique principal.
De préférence, ce procédé comprend en outre une étape de
mémorisation de ladite valeur variable extraite ou mise à jour.
Ceci permet l'utilisation ultérieure de cette variable en cas d'utilisations successives de cette variable dans un même programme informatique. Cette mémorisation permet en outre de mettre à jour ultérieurement à distance la variable localisée sur une station serveur du réseau
de communication.
Corrélativement, la présente invention concerne un dispositif d'exécution sur une station d'un réseau de communication d'un programme informatique représenté dans un langage de balisage. Ce dispositif d'exécution comprend: - des moyens de lecture d'une balise comprenant l'identification d'une instruction; - des moyens d'identification d'une adresse électronique associée à la balise comprenant l'identification d'une instruction; - des moyens de comparaison de ladite adresse électronique avec l'adresse locale de la station; et - des moyens d'envoi adaptés à envoyer une requête à une station serveur du réseau correspondant à ladite adresse électronique en vue d'obtenir l'exécution de l'instruction, si ladite adresse électronique est différente de ladite
adresse locale.
Ce dispositif d'exécution présente des caractéristiques et avantages
analogues à ceux du procédé d'exécution conforme à l'invention.
La présente invention concerne également un programme d'ordinateur comprenant des portions de codes logiciels adaptées à mettre en oeuvre le procédé d'exécution conforme à l'invention lorsque ledit programme
est chargé sur un ordinateur.
Elle concerne enfin des moyens de stockage d'informations, fixes ou partiellement ou totalement amovibles, adaptés à mémoriser des séquences
d'instructions dudit programme d'exécution conforme à l'invention.
Dans son application pratique, la présente invention concerne enfin un ordinateur et un réseau de communication comprenant des moyens adaptés
à mettre en oeuvre le procédé d'exécution conforme à l'invention.
D'autres particularités et avantages de l'invention apparaîtront
encore dans la description ci-après.
Aux dessins annexés, donnés à titre d'exemples non limitatifs: - la figure la illustre un premier réseau de communication adapté à mettre en oeuvre le procédé d'exécution conforme à l'invention; - la figure lb illustre un second réseau de communication adapté à mettre en oeuvre le procédé d'exécution conforme à l'invention; - la figure 2 est un algorithme illustrant un procédé d'exécution d'un programme conforme à l'invention; la figure 3 est un algorithme illustrant l'évaluation des instructions dudit programme de la figure 2; - la figure 3a est un algorithme illustrant l'étape d'exécution d'une hyper-fonction de la figure 3; - la figure 3b est un algorithme illustrant l'étape de lecture d'une hyper-variable de la figure 3; - la figure 3c est un algorithme illustrant l'étape de mise à jour d'une hyper-variable de la figure 3; et - la figure 4 est un schéma-bloc d'un ordinateur adapté à incorporer
un dispositif d'exécution conforme à l'invention.
On va décrire tout d'abord le principe du procédé d'exécution conforme à l'invention en référence à la figure la illustrant un réseau de
communication adapté à mettre en oeuvre ce procédé.
Ici, ce réseau de communication comporte trois ordinateurs C, 1, R. Un ordinateur client C ne dispose ni d'une imprimante ni d'une
puissance de calcul intensive.
En revanche, un deuxième ordinateur I est spécialisé dans l'impression d'images haute résolution, alors qu'un troisième ordinateur R est
spécialisé dans les opérations de calculs intensifs.
Dans un tel réseau de communication, on a intérêt à déporter une ou plusieurs sous-parties d'un programme informatique afin d'utiliser au mieux les capacités de traitement de chacun des ordinateurs C, 1, R. On va donner ci-après un exemple non limitatif de programme d'ordinateur adapté à être réparti au mieux dans un tel réseau de communication. Dans la suite, on fera référence au langage de programmation XPL (en anglais "eXtended Program Language'). Ce langage de programmation est adapté à présenter des programmes informatiques en utilisant la syntaxe du
langage de balisage XML (en anglais "eXtended Markup Language').
Bien entendu, la présente invention n'est pas limitée à un tel langage de programmation XPL mais peut être adaptée à tout autre type de langage de
programmation utilisant un langage de balisage.
On considère à titre d'exemple un programme de rotation et
d'impression d'une image.
De manière classique, un tel programme pourrait se présenter de la façon suivante: <xp:function name="printlmage" args="pixels width height"> <xp:loop var="i" start="1" stop="height"> <xp:loop var="j" start="1" stop="width"> <xp:print><xv:pixels at="i" at="j"/></xp:print> </xp:loop> </xp:loop> </xp:function> <xp:function name= "rotatelmage" args="pixels width height"> <xp:loop var="i" start="1" stop="height"> <xp:loop var="j" start="1" stop="width"> <xv:pixels2 at="height-j+1" at="i"> <xv:pixels at="i" at="j"/> </xv:pixels2> </xp:loop> </xp:loop> <xp:return> <xv:pixels2/><xv:heighV><xp:width/> </xp:return> </xp:function> <xp:main args="pixels width height"> <xp:printImage> <xp:rotatelmage> <xv:pixels/> <xp:width/><xp:height/> </xp:rotatelmage> </xp:printImage > </xp:main> Le programme ci-dessus est ainsi composé de trois fonctions distinctes: - une fonction d'impression d'une image ("printlmage'), - une fonction de rotation d'image ("rotatelmage'}, et - une fonction principale ("main') qui enchaîne les deux opérations précédentes. En revenant à la figure la, il est intéressant de pouvoir découper le programme précédent en trois sous-programmes indépendants, stockés
respectivement dans des fichiers print.xpl, rotate.xpl et main.xpl.
Le fichier print.xpl, correspondant au programme d'impression d'une image, est stocké sur le deuxième ordinateur I spécialisé dans l'impression d'images haute résolution, alors que le fichier rotate.xpl, mémorisant le programme de rotation d'une image, est stocké sur le troisième ordinateur R
spécialisé dans les opérations de calculs intensifs.
Ainsi, les fonctions "printimage" et "rotatelmage" ne sont-elles plus
connues par le programme principal main.xpl.
On modifie alors le programme main.xpl de la manière suivante: <xp:main args="pixels width height"> <xp:printlmage href="http://l/print.xpl"> <xp:rotatelmage href="http://R/rotate.xpl"> <xv:pixels/><xp:width/><xp: height/> </xp:rotatelmage> </xp:printlmage > </xp:main> Ainsi, on indique pour chaque instruction référençant une fonction non disponible localement, l'adresse électronique à laquelle se trouve la
définition de cette fonction.
Ici, l'instruction <xp:printlmage> contient l'adresse électronique "http://l/print.xpl" de la fonction "printimage" hébergée sur le deuxième
ordinateur I spécialisé dans l'impression d'image.
De même, l'instruction <xp:rotatelmage> contient l'adresse électronique "http://R/rotate.xpl" correspondant à l'adresse du troisième
ordinateur R hébergeant la fonction "rotatelmage".
On peut, grâce à une modification minimale du programme, déporter facilement le traitement d'une fonction vers un ordinateur distant du réseau de communication. Une instruction annotée par l'attribut "href" sera appelée dans la suite
de la description une "hyper-instruction" (en anglais "hyper-statement').
Ainsi, l'adresse électronique du serveur hébergeant la fonction est
mémorisée grâce à un attribut de la balise définissant la fonction.
Comme cela sera décrit en détail ultérieurement en référence aux figures 2 et suivantes, l'exécution d'une telle instruction génère automatiquement une demande de requête d'exécution à distance de la
fonction associée à l'adresse électronique.
Ainsi, une demande de requête d'exécution à distance de la fonction "rotatelmage" est envoyée à destination du troisième ordinateur R.
En retour, l'ordinateur client C reçoit une image transformée.
De même, l'évaluation de l'instruction <xp:printimage>, permet de générer automatiquement une requête de demande d'exécution à distance pour la fonction "printimage", adressée au deuxième ordinateur I spécialisé dans les
techniques d'impression.
On montrera en particulier qu'il n'est pas nécessaire de répéter la notation "hre' tsur chaque hyper-instruction du même nom. Par exemple, si la fonction "rotatelmage" est appelée plusieurs fois à différents endroits du même programme informatique, il suffit de la noter une seule fois avec l'attribut "href' pour que le programme informatique sache traiter ces hyper-instructions, en
requérant l'exécution de la fonction sur l'ordinateur distant.
A titre de variante, les fonctions distantes pourraient être déclarées
en en-tête d'un programme.
Les programmes précédents pourraient ainsi être écrits de la manière suivante de telle sorte que les fonctions "rotatelmage" et "printimage" soient toutes deux considérées comme des hyper-instructions: il <function name="rotatelmage" href="http://R/rotate.xpl"/> <xp:main args="pixels width height"> <xp:printimage href="http://I/print.xpl"> <xp:rotatelmage> <xv: pixels/><xp:width/><xp:height/> </xp:rotatelmage> </xp:printlmage > </xp:main> On va décrire à présent un deuxième mode de réalisation en
référence à la figure 1 b.
A la différence du réseau de communication illustré à la figure la, les deuxième et troisième ordinateurs R et I sont des simples serveurs de programme, c'est-à-dire qu'ils mettent à la disposition des utilisateurs, le code
source ou l'exécutable de certains programmes particulièrement intéressants.
Ces deuxième et troisième ordinateurs R et I ne sont pas dotés de moyens de calcul et d'impression suffisants pour mettre en oeuvre les
programmes qu'ils hébergent.
Ainsi, à titre d'exemple, le deuxième ordinateur I propose le code de la fonction "printimage" alors que le troisième ordinateur R propose le code de
la fonction "rotatelmage".
Ainsi le fichier print.xpl et le fichier rotate.xpl sont hébergés respectivement sur le deuxième et le troisième ordinateur I et R. Ici, contrairement à l'exemple de réalisation précédent, l'ordinateur client C est doté de moyens suffisants pour permettre des calculs intensifs et
l'impression d'images.
Dans ce type de réseau, l'évaluation d'une hyper-instruction telle que décrite précédemment génère automatiquement une requête de demande
d'obtention du code de la fonction à exécuter.
Ainsi, lors de l'évaluation de l'hyper-instruction <xp:rotatelmage> dans le programme principal main.xpl, I'interpréteur génère et envoi automatiquement une demande d'obtention du fichier <rotate.xpl> au troisième ordinateur R. En retour, l'ordinateur client C reçoit le code de la fonction
"rotatelmage" de manière à pouvoir l'exécuter localement.
Comme cela sera décrit en référence aux figures suivantes, le code ainsi obtenu peut être mémorisé dans un cache pour une durée prédéterminée,
afin d'utiliser successivement cette fonction lors de l'exécution du programme.
La génération et l'envoi automatique d'une demande d'obtention du fichier "printxpl" est également adressée de manière analogue au deuxième
ordinateur 1.
On a décrit précédemment un procédé d'exécution de fonctions
hébergées sur des stations distantes.
Ce procédé d'exécution peut s'appliquer de manière analogue à des hypervariables. De manière similaire, une hyper-variable est une variable xpl à laquelle on a ajouté un attribut "href" dans lequel l'adresse du serveur sur lequel
réside le contenu de la variable peut être mémorisée.
Une hyper-variable permet notamment de partager facilement des variables entre plusieurs programmes informatiques. En outre, une hyper20 variable permet de préserver des informations en les déportant sur un serveur,
généralement mieux surveillé et entretenu qu'un ordinateur client.
On donne à titre d'exemple ci-dessous l'utilisation d'une hypervariable dans la fonction "printimage": <xp:function name="printlmage" args="pixels width height"> <xp:loop var="i" start="1" stop="height"> <xp:loop var="j" start="1" stop="width"> <xp:print><xv:pixels href="http://R/pixels.xv" at="i" at="j"/> </xp:print> </xp:loop> </xp:loop> </xp:function> Dans cet exemple, la fonction "printimage" s'exécute localement mais, à chaque itération, une requête est envoyée à un serveur du réseau de communication à l'adresse "http://R/pixels.xv", afin d'obtenir le contenu d'une
case (i, j) d'un tableau "pixels".
On va décrire à présent, en référence à la figure 2, le procédé d'exécution d'un programme conforme à l'invention, dans lequel le programme informatique comprend des hyper-instructions, c'est-à-dire soit des hyperfonctions, soit des hyper-variables, dont le contenu ou le code est hébergé à
distance sur un réseau de communication.
Le procédé d'exécution comporte d'abord une étape de test E20 dans laquelle on vérifie s'il existe ou non un cache, dans l'espace mémoire de
l'ordinateur client sur lequel est exécuté le programme.
Dans l'affirmative, on initialise ce cache dans une étape d'initialisation E21. A l'issue de cette initialisation ou lorsqu'il n'existe pas de cache, on procède à une étape d'analyse classique E22 du code du programme de manière à construire un arbre. Cette étape d'analyse E22 permet ainsi de parser et de construire un arbre syntaxique qui correspond à l'emboîtement des
fonctions et des instructions.
Une étape d'obtention E23 permet de constituer ensuite la liste des
fonctions qui sont dans cet arbre.
Ces fonctions sont ensuite ajoutées dans une étape d'ajout E24 dans une table de fonctions classique dans lequel toutes les fonctions peuvent être
mémorisées en association avec leur code d'exécution.
En pratique, on mémorise le nom de chaque fonction en association avec l'adresse du noeud dans l'arbre auquel est situé le code d'exécution de la fonction. On obtient ensuite dans une étape d'obtention E25 une fonction principale, c'est-à-dire la fonction "main" de plus haut niveau dans l'arbre afin
d'exécuter le programme.
L'ensemble de ces étapes E20 à E25 sont des étapes classiques mises en oeuvre lors de l'exécution d'un programme représenté dans un
langage xpl et n'ont pas besoin d'être décrites plus en détail ici.
Une étape d'exécution E26 proprement dite permet d'exécuter cette fonction principale. Cette étape d'exécution E26 va être décrite en référence à
la figure 3.
On obtient dans une étape d'obtention E30 la première instruction I à
exécuter dans cette fonction principale.
Une étape de test E31 permet de vérifier si cette instruction est une
hyper-fonction.
En pratique, on vérifie s'il s'agit d'une balise incorporant le nom d'une fonction, associée à une adresse électronique par exemple sous la forme d'un
attribut via la référence "href'.
Dans l'affirmative, on exécute cette hyper-fonction dans une étape
E32 qui sera décrite ultérieurement en référence à la figure 3a.
Sinon, une étape de test E33 permet de vérifier si cette instruction I
est une hyper-variable.
Là encore, on vérifie si il s'agit d'une variable dont la valeur est
associée à une adresse électronique via l'attribut "href".
Dans l'affirmative, une autre étape de test E34 permet de vérifier s'il
s'agit d'une mise à jour ou non de la valeur de la variable.
En pratique, les variables peuvent être utilisées soit par la lecture
d'une valeur, soit par une mise à jour de cette valeur.
La distinction peut être réalisée suivant la présence ou non d'une
valeur dans la balise.
Par exemple, lorsqu'il s'agit d'un compteur, une balise seule <counter!> signifiera qu'il s'agit de lire la valeur du compteur, alors que la balise <counter>10</counter> signifiera qu'il s'agit de mettre à jour la valeur 10 du compteur. A l'issue de cette étape de test E34, dans la négative, une étape de lecture E35 de la valeur d'une hyper-variable sera mise en oeuvre comme cela
sera décrit plus en détail en référence à la figure 3b.
Dans l'affirmative à l'issue de l'étape de test E34, lorsque la variable doit être mise à jour, une étape de mise à jour E36 sera mise en oeuvre telle
que cela sera décrit ultérieurement en référence à la figure 3c.
Si à l'issue de l'étape de test E33, la première instruction n'est pas une hyper-variable, une étape d'évaluation E37 est adaptée à évaluer
l'instruction de manière classique, en exécutant celle-ci localement.
A l'issue de cette étape d'évaluation E37 ou encore des étapes d'exécution E32, de lecture E35 ou de mise à jour E36, on vérifie si la fonction principale comporte une autre instruction dans une étape de test E38. Dans l'affirmative, on considère l'instruction suivante dans une étape d'obtention E39 et l'ensemble des étapes E31 à E38 sont réitérées pour cette instruction suivante. Lorsque toutes les instructions de la fonction principale ont été
traitées, le programme d'évaluation prend fin.
On va décrire à présent en référence à la figure 3a l'exécution d'une
hyper-fonction conformément au premier mode de réalisation de l'invention.
Dans une étape de lecture E40, la valeur de l'attribut "href' est lue.
En pratique, cet attribut comporte une adresse sous la forme d'une
adresse électronique d'un serveur sur le réseau de communication.
Dans une étape de comparaison E41, cette adresse électronique est
comparée à l'adresse locale du serveur exécutant le programme.
Si ces adresses sont différentes, le procédé d'exécution comprend une étape d'envoi pour permettre d'obtenir l'exécution de la fonction hébergée à
distance sur un autre serveur du réseau de communication.
En pratique, on vérifie dans une étape E42 si le mode d'exécution de
la fonction est un mode d'exécution à distance ou non.
Le mode d'exécution de chaque fonction peut être défini par un mode global associé au serveur local exécutant le programme, par exemple défini par l'utilisateur. L'utilisateur peut ainsi prévoir que toutes les fonctions
sont exécutées à distance, sur différents serveurs du réseau de communication.
Alternativement, ce mode d'exécution de chaque fonction peut être spécifique à chaque programme, un attribut associé au programme informatique devant être exécuté définissant un mode d'exécution àdistance ou
non de chaque fonction.
Enfin, un troisième mode de réalisation consisterait à définir pour chaque fonction son mode d'exécution propre. Ainsi, dans le programme informatique écrit en langage xpl, un attribut supplémentaire pourrait être associé à chaque fonction afin de définir un mode d'exécution à distance ou un
mode d'exécution locale pour chacune de ces fonctions.
Si le mode d'exécution est un mode d'exécution à distance, une étape d'envoi E43 est mise en èuvre afin d'envoyer automatiquement une requête d'exécution de la fonction à distance au serveur référencé par l'adresse électronique. Ce serveur à distance, après réception de cette requête, exécute
localement la fonction, puis envoie une réponse au serveur client.
Cette réponse, correspondant ainsi à l'exécution de la fonction, est
réceptionnée dans une étape de réception E44.
La requête et la réponse peuvent être au format xpl.
Si à l'issue du test E42, le mode d'exécution de la fonction n'est pas un mode d'exécution à distance, une étape d'envoi E45 est adaptée à envoyer
automatiquement une demande d'obtention du code de la fonction.
Le serveur à distance envoie alors le code de la fonction demandée de telle sorte que cette réponse est réceptionnée dans une étape de réception
E46 sur la station client.
Une fois le code ainsi réceptionné, cette fonction peut être exécutée de manière classique sur la station client, après une étape d'extraction E48 du
code de la fonction.
Cette exécution locale est identique à celle qui est mise en oeuvre par le serveur lorsqu'à l'issue de l'étape E41, l'adresse électronique mémorisée dans l'attribut "href" associé à la fonction n'est autre que l'adresse locale du
serveur exécutant le programme.
Dans l'affirmative, une étape de lecture F47 du fichier mémorisé
localement est suivie de l'étape d'extraction E48 du code de la fonction.
A l'issue de cette étape d'extraction E48, une étape d'analyse E49 permet comme précédemment de construire un arbre à partir du code de la fonction et une étape d'obtention E50 permet d'obtenir la liste des fonctions
contenues dans ce nouvel arbre.
Lors d'une étape d'ajout E51, ces fonctions sont mémorisées dans la
table des fonctions.
Ces étapes E49 à E51 correspondent ainsi à une étape de
mémorisation du code de la fonction.
Une étape d'évaluation E52 permet ensuite d'évaluer et d'exécuter la
fonction à partir des fonctions mémorisées dans la table.
On va décrire à présent en référence à la figure 3b l'étape de lecture
E35 de la valeur d'une hyper-variable.
On vérifie dans une étape de test E60 si l'adresse électronique mémorisée dans l'attribut "href" correspond à l'adresse locale du serveur
exécutant le programme ou non.
Dans l'affirmative, une étape de lecture E61 peut être mise en oeuvre
localement directement sur la station exécutant le programme.
Sinon, on vérifie dans une étape de test E62 si cette valeur est mémorisée ou non dans une mémoire cache de l'ordinateur exécutant le
programme.
Dans l'affirmative, l'étape de lecture E61 est mise en oeuvre afin de lire localement cette valeur, dans la mémoire cache du serveur exécutant le programme. Sinon, une étape d'envoi E63 est adaptée à envoyer une demande d'obtention de la valeur variable. Cette demande est envoyée à l'adresse
électronique de la station référencée par l'attribut "href".
Une étape de réception E64 permet de réceptionner en réponse la valeur de la variable adressée par le serveur distant. Une étape d'extraction E65 permet d'extraire cette valeur de la réponse. On vérifie dans une étape de test E66 s'il convient de cacher ou non cette valeur. En pratique il peut être intéressant de mémoriser dans un cache la valeur variable lorsque celle-ci est
utilisée successivement dans le même programme informatique.
* Dans l'affirmative, une étape de mémorisation E67 permet de mémoriser la valeur variable dans le cache. Cette étape de lecture E35 d'une
hyper-variable est ainsi achevée.
De manière alternative, l'étape de mise à jour E36 de la figure 2, permettant de mettre à jour une valeur variable, est illustrée à la figure 3c. Comme précédemment, on vérifie dans une étape de test E70 si l'adresse électronique mémorisée dans l'attribut "href' correspond à l'adresse
locale du serveur mettant en oeuvre le procédé d'exécution du programme.
Dans l'affirmative, une étape de mise à jour E71 est mise en oeuvre afin de mettre à jour la valeur de la variable à partir des éléments mémorisés
sur le serveur local.
Sinon, une étape de test E72 permet de vérifier si cette variable à mettre à jour est déjà mémorisée dans une mémoire cache. Dans l'affirmative, on met à jour comme précédemment, dans l'étape de mise à jour E71, la valeur
de la variable.
Sinon, une étape d'envoi E73 permet d'envoyer une demande de mise à jour de la valeur variable à un serveur distant situé sur le réseau de communication à l'adresse électronique mémorisée dans l'attribut "hret' associé
à cette hyper-variable.
Une étape de réception E74 permet de réceptionner une réponse intégrant la mise à jour de cette valeur variable. Cette valeur variable mise à
jour est extraite dans une étape d'extraction E75.
Dans une étape de test E76, on vérifie si la valeur variable mise à
jour doit être mémorisée ou non.
Dans l'affirmative, une étape de mémorisation E77 permet la mémorisation de la valeur variable dans la mémoire cache en vue de son
utilisation ultérieure dans l'exécution du programme informatique.
Ces procédés de traitement d'une hyper-fonction ou d'une hypervariable tels que décrits précédemment en référence aux figures 3a, 3b et 3c permettent ainsi, grâce à l'attribut "href", de traiter de manière analogue les fonctions ou variables accessibles sur des serveurs distants du réseau ou
accessibles localement.
En revenant à la figure 2, à l'issue de cette étape d'exécution d'une fonction principale E26, on vérifie dans une étape de test E27 s'il existe une
mémoire cache ou non sur le serveur local.
Dans l'affirmative, une étape de mise à jour E28 permet de mettre à jour à distance les hyper-variables. Ainsi, lors de la mise à jour successive d'une variable sur un serveur local exécutant un programme, lorsque cette variable est mémorisée dans le cache de l'ordinateur, cette étape de mise à jour E28 permet de retourner à un serveur du réseau de communication la valeur mise à jour de la variable, en vue d'une utilisation ultérieure par la même station locale ou une autre station
du réseau de communication.
Ce procédé d'exécution permet ainsi d'exécuter de manière relativement simple un programme informatique réparti sur un réseau de communication, en utilisant au mieux les capacités de traitement ou les
caractéristiques des différents serveurs du réseau.
Afin de mettre en oeuvre ce procédé d'exécution, un dispositif d'exécution comporte des moyens de lecture de chaque balise constituant le programme informatique afin d'identifier les instructions référencées dans cette balise. Il comporte également des moyens d'identification d'une adresse électronique associée à cette balise, de préférence sous la forme d'un attribut
(noté "hrefT.
Des moyens de comparaison sont adaptés à comparer cette adresse électronique avec l'adresse locale du serveur hébergeant le dispositif d'exécution. Conformément à l'invention, ce dispositif d'exécution comporte des moyens d'envoi adaptés à envoyer une requête à une station serveur du réseau correspondant à l'adresse électronique lue en vue d'obtenir l'exécution de l'instruction lorsque cette adresse électronique est différente de l'adresse locale
du serveur hébergeant le dispositif d'exécution.
Ce dispositif d'exécution comprend également des moyens de réception d'un résultat d'exécution d'une fonction ou d'un code d'une fonction à exécuter ainsi que des moyens de mémorisation du code d'une fonction à exécuter. Il comprend également des moyens de mémorisation d'une valeur
variable extraite ou mise à jour à distance.
L'ensemble de ces moyens sont incorporés de préférence dans un
ordinateur tel qu'illustré à la figure 4.
En particulier, les différents moyens peuvent être incorporés dans un microprocesseur 100, une mémoire morte 101 (en anglais "Read OnIy Memory" ou ROM) étant adaptée à mémoriser un programme d'exécution d'un
programme informatique.
Ainsi, le dispositif d'exécution peut être mis en oeuvre dans un
ordinateur relié à d'autres stations serveurs d'un réseau de communication 1.
Une mémoire vive 102 (en anglais "Random Access Memory" ou RAM) est adaptée à mémoriser dans des registres les variables modifiées lors
de l'exécution du programme d'exécution.
En particulier, la mémoire vive 102 est adaptée à mémoriser la table des fonctions et les différents arbres réalisés à partir de la structure du programme. Ce microprocesseur 100 est intégré à un ordinateur client C qui peut être connecté à différents périphériques, telle qu'une imprimante, ou à d'autres
ordinateurs du réseau de communication 1.
Cet ordinateur C comporte une interface de communication 110 reliée au réseau de communication pour recevoir ou transmettre des messages
ou des requêtes.
Ici, dans ce mode de réalisation, les requêtes peuvent être établies
selon le protocole de communication HTTP bien connu de l'homme du métier.
L'ordinateur C comporte en outre des moyens de stockage de documents, tel qu'un disque dur 106 ou est adapté à coopérer au moyen d'un lecteur de disque 107 (disquettes, disques compacts ou cartes informatiques) avec des moyens de stockage de documents amovibles, tels que des
disques 7.
Ces moyens de stockage fixes ou amovibles peuvent comporter en outre le code du procédé d'exécution conforme à l'invention, qui, une fois lu par
le microprocesseur 100 sera stocké dans le disque dur 106.
A titre de variante, le programme permettant au dispositif d'exécution de mettre en oeuvre l'invention pourrait être stocké dans la mémoire morte 1 01. En seconde variante, le programme pourrait reçu pour être stocké
comme décrit précédemment par l'intermédiaire du réseau de communication 1.
L'ordinateur C possède également un écran 103 permettant par exemple de servir d'interface avec un opérateur à l'aide du clavier 104 ou de la souris 105 ou de tout autre moyen et d'afficher des données, par exemple le
résultat du programme informatique après son exécution.
L'unité centrale 100 (CPU) va exécuter des instructions relatives à la
mise en oeuvre de l'invention.
Lors de la mise sous tension, les programmes et méthodes relatives à l'invention stockés dans une mémoire non volatile, par exemple la mémoire morte 101, sont transférés dans la mémoire vive 102 qui contiendra alors le code exécutable de l'invention ainsi que les variables nécessaires à la mise en
oeuvre de l'invention.
Un bus de communication 112 permet la communication entre les différents sous-éléments de l'ordinateur C ou liés à lui. La représentation du bus 112 n'est pas limitative et notamment le microprocesseur 100 est susceptible de communiquer des instructions à tous sous-éléments, directement ou par
l'intermédiaire d'un autre sous-élément.
Bien entendu, de nombreuses modifications peuvent être apportées aux exemples de réalisation décrits précédemment sans sortir du cadre de l'invention.
Claims (23)
1. Procédé d'exécution sur une station (C) d'un réseau de communication d'un programme informatique représenté dans un langage de balisage, caractérisé en ce qu'il comprend les étapes suivantes: - lecture (E30-E36) d'une balise comprenant l'identification d'une instruction; identification (E40) d'une adresse électronique associée à ladite balise comprenant l'identification d'une instruction; - comparaison (E41, E60, E70) de ladite adresse électronique avec l'adresse locale de la station; et - envoi (E43, E45, E63, E73) si ladite adresse électronique est différente de ladite adresse locale, d'une requête à une station serveur du réseau correspondant à ladite adresse électronique en vue d'obtenir l'exécution
de ladite instruction.
2. Procédé d'exécution conforme à la revendication 1, caractérisé en ce que l'adresse électronique est inscrite comme attribut de ladite balise
comprenant l'identification d'une instruction.
3. Procédé d'exécution conforme à l'une des revendications 1 ou 2,
caractérisé en ce qu'à l'étape d'envoi (E43), une requête de demande d'exécution d'une fonction à distance est envoyée à ladite station serveur du
réseau de communication.
4. Procédé d'exécution conforme à la revendication 3, caractérisé en ce qu'il comprend en outre une étape de réception (E44) d'un résultat
d'exécution de ladite fonction.
5. Procédé d'exécution conforme à l'une des revendications 1 ou 2,
caractérisé en ce qu'à l'étape d'envoi (E45), une requête de demande d'obtention du code d'une fonction à exécuter est envoyée à ladite station
serveur du réseau de communication.
6. Procédé d'exécution conforme à la revendication 5, caractérisé en ce qu'il comprend en outre une étape de réception (E46) dudit code de la fonction à exécuter et une étape d'exécution (E48-E52) de la fonction par ladite
station (C).
7. Procédé d'exécution conforme à la revendication 6, caractérisé en ce qu'il comprend en outre une étape de mémorisation dudit code de la fonction réceptionnée.
8. Procédé d'exécution conforme à l'une des revendications 1 ou 2,
caractérisé en ce qu'à l'étape d'envoi (E63), une requête d'obtention d'une valeur variable est envoyée à ladite station serveur du réseau de communication.
9. Procédé d'exécution conforme à la revendication 8, caractérisé en ce qu'il comprend en outre une étape de réception (E64) d'une réponse et
d'extraction (E65) de ladite valeur variable.
10. Procédé d'exécution conforme à l'une des revendications 1 ou 2,
caractérisé en ce qu'à l'étape d'envoi (E73), une requête de mise à jour d'une
variable est envoyée à ladite station serveur du réseau de communication.
11. Procédé d'exécution conforme à l'une des revendications 8 à 10,
caractérisé en ce qu'il comprend une étape de mémorisation (E67, E77) de
ladite valeur variable extraite ou mise à jour.
12. Procédé d'exécution conforme à la revendication 11, caractérisé en ce qu'il comprend une étape de mise à jour à distance (E28) d'une variable d'une station serveur du réseau de communication à partir de ladite valeur
variable mémorisée.
13. Procédé d'exécution conforme à l'une des revendications 1 à 12,
caractérisé en ce que ledit programme informatique est représenté dans un
langage utilisant la syntaxe du langage de balisage XML.
14. Procédé d'exécution conforme à l'une des revendications 1 à 13,
caractérisé en ce que le réseau de communication met en oeuvre un procédé
de communication de type HTTP entre les serveurs dudit réseau.
15. Dispositif d'exécution sur une station (C) d'un réseau de communication d'un programme informatique représenté dans un langage de balisage, caractérisé en ce qu'il comprend: - des moyens de lecture (100, 101, 102) d'une balise comprenant l'identification d'instructions; - des moyens d'identification (100, 101, 102) d'une adresse électronique associée à ladite balise comprenant l'identification d'une instruction; des moyens de comparaison (100, 101, 102) de ladite adresse électronique avec l'adresse locale de la station; et - des moyens d'envoi (100, 101, 102) adaptés à envoyer une requête à une station serveur du réseau correspondant à ladite adresse électronique en vue d'obtenir l'exécution de ladite instruction lorsque ladite
adresse électronique est différente de ladite adresse locale.
16. Dispositif d'exécution conforme à la revendication 15, caractérisé en ce qu'il comprend des moyens de réception (100, 101, 102) d'un résultat
d'exécution d'une fonction ou d'un code d'une fonction à exécuter.
17. Dispositif d'exécution conforme à la revendication 16, caractérisé en ce qu'il comprend des moyens de mémorisation (100, 101, 102) d'un code
de fonctions à exécuter.
18. Dispositif d'exécution conforme à l'une des revendications 15 à
17, caractérisé en ce qu'il comprend des moyens de mémorisation (100, 101,
102) d'une valeur variable extraite ou mise à jour.
19. Dispositif d'exécution conforme à l'une des revendications 15 à
18, caractérisé en ce qu'il est incorporé dans: - un microprocesseur (100) ; - une mémoire morte (101) adaptée à mémoriser le procédé d'exécution d'un programme informatique; et - une mémoire vive (102) comprenant des registres adaptés à
mémoriser des variables modifiées lors de l'exécution dudit programme.
20. Ordinateur, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé d'exécution conforme à l'une des
revendications 1 à 14.
21. Réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé d'exécution conforme à l'une
des revendications 1 à 14.
22. Programme d'ordinateur comprenant des portions de codes logiciels adaptés à mettre en oeuvre le procédé d'exécution conforme à l'une
des revendications 1 à 14, lorsque ledit programme est chargé sur un
ordinateur.
23. Moyens de stockage d'information, fixes ou partiellement ou totalement amovibles, adaptés à mémoriser des séquences d'instructions du
procédé d'exécution conforme à l'une des revendications 1 à 14.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0208374A FR2841998B1 (fr) | 2002-07-04 | 2002-07-04 | Procede d'execution sur une station d'un reseau de communication d'un programme informatique represente dans un langage de balisage |
| US10/610,523 US7594235B2 (en) | 2002-07-04 | 2003-07-02 | Method of executing on a station of a communication network a computer program represented in a markup language |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0208374A FR2841998B1 (fr) | 2002-07-04 | 2002-07-04 | Procede d'execution sur une station d'un reseau de communication d'un programme informatique represente dans un langage de balisage |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2841998A1 true FR2841998A1 (fr) | 2004-01-09 |
| FR2841998B1 FR2841998B1 (fr) | 2004-10-22 |
Family
ID=29725151
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0208374A Expired - Fee Related FR2841998B1 (fr) | 2002-07-04 | 2002-07-04 | Procede d'execution sur une station d'un reseau de communication d'un programme informatique represente dans un langage de balisage |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7594235B2 (fr) |
| FR (1) | FR2841998B1 (fr) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2745365C (fr) | 2008-12-23 | 2013-01-08 | J.J. Mackay Canada Limited | Parcmetre sans fil basse puissance et reseau de parcmetres |
| CA2756489C (fr) | 2011-03-03 | 2023-09-26 | J.J. Mackay Canada Limited | Parcometre avec methode de paiement sans contact |
| CA145137S (en) | 2012-04-02 | 2013-07-22 | Jj Mackay Canada Ltd | Single space parking meter |
| CN105849691B (zh) | 2013-06-18 | 2019-09-13 | 西安姆贝拉有限公司 | 用于代码虚拟化和远程进程调用生成的方法和装置 |
| US9619122B2 (en) | 2014-01-10 | 2017-04-11 | Ciambella Ltd. | Method and apparatus for automatic device program generation |
| US10067490B2 (en) | 2015-05-08 | 2018-09-04 | Ciambella Ltd. | Method and apparatus for modifying behavior of code for a controller-based device |
| CA2984106C (fr) | 2015-05-08 | 2021-12-21 | Ciambella Ltd. | Procede et appareil de developpement automatique de logiciels pour un groupe de dispositifs a base de controleur |
| CA2894350C (fr) | 2015-06-16 | 2023-03-28 | J.J. Mackay Canada Limited | Goulotte de monnaie dotee d'un mecanisme anti repechage |
| USRE48566E1 (en) | 2015-07-15 | 2021-05-25 | J.J. Mackay Canada Limited | Parking meter |
| CA3176773A1 (fr) | 2015-08-11 | 2017-02-11 | J.J. Mackay Canada Limited | Renovation d'un parcometre pour espace unique |
| USD813059S1 (en) | 2016-02-24 | 2018-03-20 | J.J. Mackay Canada Limited | Parking meter |
| WO2018170079A1 (fr) | 2017-03-14 | 2018-09-20 | Ciambella Ltd. | Procédé et appareil conçus pour générer et incorporer automatiquement un code dans des environnements de développement |
| US10380915B2 (en) * | 2017-06-29 | 2019-08-13 | Stephen Sophorn Lim | Braille dot delivery system |
| CA3031936A1 (en) | 2019-01-30 | 2020-07-30 | J.J. Mackay Canada Limited | Spi keyboard module for a parking meter and a parking meter having an spi keyboard module |
| US11922756B2 (en) | 2019-01-30 | 2024-03-05 | J.J. Mackay Canada Limited | Parking meter having touchscreen display |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2795535A1 (fr) * | 1999-06-25 | 2000-12-29 | Canon Res Ct France Sa | Procede d'execution a distance d'une fonction sur un objet informatique dans un reseau de communication |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4442486A (en) * | 1981-11-25 | 1984-04-10 | U.S. Philips Corporation | Protected programmable apparatus |
| US5956483A (en) * | 1996-06-28 | 1999-09-21 | Microsoft Corporation | System and method for making function calls from a web browser to a local application |
| DE60039554D1 (de) | 1999-06-25 | 2008-09-04 | Canon Res Ct France S A | Verteilte Verwaltung von Datenobjekten in einem Kommunikations-Netzwerk |
| US6490564B1 (en) * | 1999-09-03 | 2002-12-03 | Cisco Technology, Inc. | Arrangement for defining and processing voice enabled web applications using extensible markup language documents |
| EP1120959A1 (fr) | 2000-01-24 | 2001-08-01 | Canon Research Centre France S.A. | Procédé et dispositif de gestion des ressources d'un moyen de communication informatique pour traiter un document informatique |
| US20060168644A1 (en) * | 2000-02-29 | 2006-07-27 | Intermec Ip Corp. | RFID tag with embedded Internet address |
| EP1197859A1 (fr) | 2000-10-10 | 2002-04-17 | Canon Kabushiki Kaisha | Procédé et dispositif d'utilisation à distance d'un objet informatique dans un réseau de communication |
| US7240024B2 (en) | 2000-10-10 | 2007-07-03 | Canon Kabushiki Kaisha | Method for remote execution of a function in a communication network |
| US7111077B1 (en) * | 2000-12-22 | 2006-09-19 | Unisys Corporation | Method and apparatus for passing service requests and data from web based workstations directly to online transaction processing (OLTP) server systems |
| JP4099948B2 (ja) * | 2001-01-18 | 2008-06-11 | 株式会社日立製作所 | 構造化文書をプログラム言語の構造体データへマッピングするシステム及び方法及びプログラム |
| FR2819959A1 (fr) | 2001-01-22 | 2002-07-26 | Canon Kk | Procede d'annulation d'une operation executee a distance sur une station serveur |
| US7089567B2 (en) * | 2001-04-09 | 2006-08-08 | International Business Machines Corporation | Efficient RPC mechanism using XML |
| US6502777B2 (en) * | 2001-05-21 | 2003-01-07 | Sheng Hsin Liao | Wire-winding box capable of unidirectionally winding wire |
| US6799184B2 (en) * | 2001-06-21 | 2004-09-28 | Sybase, Inc. | Relational database system providing XML query support |
| FR2826761B1 (fr) | 2001-06-27 | 2003-10-17 | Canon Kk | Procede d'analyse d'un document represente dans un langage de balisage |
| FR2829330B1 (fr) | 2001-08-31 | 2003-11-28 | Canon Kk | Procede de demande de reception du resultat d'execution d'une fonction a distance a une date predeterminee |
-
2002
- 2002-07-04 FR FR0208374A patent/FR2841998B1/fr not_active Expired - Fee Related
-
2003
- 2003-07-02 US US10/610,523 patent/US7594235B2/en not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2795535A1 (fr) * | 1999-06-25 | 2000-12-29 | Canon Res Ct France Sa | Procede d'execution a distance d'une fonction sur un objet informatique dans un reseau de communication |
Non-Patent Citations (2)
| Title |
|---|
| BURNS J, LAUZON M, HEIN R A: "eXtensible Programming Language ( XPL ) Specification", XPL OPENSOURCE PROJECT, 22 July 2000 (2000-07-22), XP002241972, Retrieved from the Internet <URL:http://www.vbxml.com/XPL/spec_draft.asp> [retrieved on 20030521] * |
| CLINICK A: "Remote Scripting", MSDN LIBRARY, 21 April 1999 (1999-04-21), XP002200229, Retrieved from the Internet <URL:msdn.microsoft.com/library/en-us/dnclinic/html/scripting041299.asp> [retrieved on 20020527] * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040040028A1 (en) | 2004-02-26 |
| FR2841998B1 (fr) | 2004-10-22 |
| US7594235B2 (en) | 2009-09-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101454764B (zh) | 独立ActionScript分析工具和技术 | |
| FR2841998A1 (fr) | Procede d'execution sur une station d'un reseau de communication d'un programme informatique represente dans un langage de balisage | |
| FR2824160A1 (fr) | Conteneur generique configurable de facon dynamique | |
| WO2003057648A2 (fr) | Procedes et systemes de recherche et d'association de ressources d'information telles que des pages web | |
| EP1195699A1 (fr) | Procédé d'optimisation, par un terminal, de la consultation de données | |
| FR2909198A1 (fr) | Procede et disositif de filtrage d'elements d'un document structure a partir d'une expression. | |
| FR2906383A1 (fr) | Referentiel semantique de services web et procede utilisant ce referentiel | |
| WO2001044887A2 (fr) | Procede de commercialisation de biens ou de services par des moyens electroniques sur des reseaux du type internet | |
| WO2001093094A1 (fr) | Systeme de publication multi-terminal et procede de mise en oeuvre correspondant | |
| FR2869133A1 (fr) | Systeme et procede de tracabilite de contenus electroniques syndiques via un reseau de communication de type internet | |
| EP2674860B1 (fr) | Procédé de traitement de données par un module de navigation | |
| FR2952203A1 (fr) | Procede de generation d'un flux web et un systeme associe | |
| FR2906382A1 (fr) | Procedes et dispositifs pour optimiser le traitement xml | |
| FR2966948A1 (fr) | Indexation et execution d'applications logicielles dans un reseau | |
| EP1559003A2 (fr) | Carte a microcircuit comportant des moyens de publication de ses objets informatiques | |
| WO2006048378A1 (fr) | Procede de chargement d'un code logiciel en langage intermediaire oriente objet dans un appareil portatif | |
| FR2811101A1 (fr) | Procede de traitement de donnees structurees utilisant un langage informatique oriente objet | |
| FR2925721A1 (fr) | Procede et dispositif de compilation et d'evaluation d'une pluralite d'expressions a evaluer sur un document structure | |
| EP3262536B1 (fr) | Procédé de téléchargement accéléré d'une page web vers un terminal de communication | |
| FR2911200A1 (fr) | Procede et dispositif de traitement de documents a partir de schemas enrichis et procede et dispositif de decodage correspondants | |
| FR3029657A1 (fr) | Procede de fourniture d'un service informatique et systeme informatique pour la mise en œuvre du procede. | |
| BE1005836A6 (fr) | Ameliorations apportees a l'efficacite du traitement de donnees et s'y rapportant. | |
| FR3087916A1 (fr) | Procede de traitement d'un code source, dispositif, systeme et programme correspondant | |
| FR2795536A1 (fr) | Procede de traduction, de transfert et de mise a jour d'un objet informatique sur un reseau de communication informatique | |
| EP2056196A1 (fr) | Procédé de réalisation et de traitement d'appel de procédure, système et produit programme d'ordinateur correspondant |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20140331 |