PROCEDE ET DISPOSITIF D'INTERACTION ENTRE DES APPLICATIONS INFORMATIQUES ET UN SITE DISTANT

La présente invention concerne un procédé et un dispositif d'interaction entre des applications informatiques et un site distant. La présente invention est du domaine de l'informatique lié aux réseaux informatiques, par exemple Internet et autres réseaux mettant en œuvre le protocole IP, acronyme d'Internet Protocol pour protocole Internet. La présente invention met en place un système de communication et de traduction, ou conversion, de données entre une application, ou programme informatique, quelconque, par exemple un traitement de texte ou un tableur et un serveur hébergeant des sites de la toile, en vue de l'affichage des données sur les pages de ces sites, l'affichage lui-même étant connu dans l'art antérieur.

La gestion de contenu des sites, connue sous le nom de CMS, acronyme de Content Management System ou système de gestion de contenu, utilise actuellement une interface utilisateur de type web entre l'utilisateur et le serveur pour que l'utilisateur puisse modifier ou faire évoluer ledit contenu. Le fait qu'il y ait uniquement une interface utilisateur, donc une intervention humaine, qui permette de créer et agencer les contenus des sites constitue une limitation de l'art antérieur que la présente invention vise à éliminer. Le gestionnaire de contenu CMS n'agit donc pas sur la structure soutenant le contenu du site mais seulement sur le contenu des pages du site.

Un des buts de la présente invention est de supprimer cet intermédiaire afin de pouvoir faire évoluer le contenu d'un site web non plus au travers d'interfaces affichées par des navigateurs mais depuis une application tierce, par exemple un logiciel de traitement de texte, un tableur, un logiciel d'édition de présentations, de comptabilité ou de dessin.

On connaît le document FR 2797336, du même inventeur que la présente invention, qui décrit un procédé de modélisation des sites Internet. Cependant, ce procédé se limite à définir une encapsulation de fonctionnalités sous la forme d'objet, les dits objets se limitant au contenu des pages du site et ne s'étendant pas à toutes les composantes du site. La présente invention vise à étendre ce modèle d'objet pour piloter, avec une application tierce, la gestion de sites de la toile. En particulier, dans le système décrit dans

ce document, aucun objet n'est accessible par programmation depuis un autre programme, mais seulement par une interface utilisateur.

A cet effet, la présente invention vise, selon un premier aspect, un procédé d'interaction entre des applications informatiques et un site distant, caractérisé en ce qu'il met en œuvre des éléments représentatifs des contenus des pages et de la structure des sites Web dans des bases de données situées sur un serveur central, lesdits éléments représentatifs étant constitués :

- d'objets contenus dans une base de données, un objet étant une entité autonome encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente, d'attributs desdits objets, lesdits attributs étant des paramètres modifiables pour constituer l'interface de l'objet vis à vis de l'utilisateur des applications clientes,

- de données de structure définissant la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles, le procédé comportant :

- une étape de traduction des éléments provenant d'une application tierce dits « clients » vers une représentation par objets des sites web et

- une étape de génération d'un macro objet consistant à lier des objets provenant de l'application tierce, dans un macro objet, chaque objet du macro objet étant indissociable des autres objets constituant le macro objet.

Grâce à ces dispositions, des éléments provenant d'une application tierce, par exemple un traitement de texte ou un tableur sont mis en œuvre par le serveur, en tant qu'objets, les liens entre eux étant mémorisés dans le macro objet. La présente invention étend le modèle objet décrit dans le document FR 2797336, précédemment limité aux composants des pages, à tous les éléments d'un site (rubriques, événements, éléments du gestionnaire de contenu CMS, etc..) ainsi qu'aux différentes personnes chargées de la gestion et du contrôle.

On rappelle ici que les rubriques sont la version abstraite des pages. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, en outre, lors de l'accès au site par une application cliente, une étape de traduction des objets des sites web vers les éléments clients.

Grâce à ces dispositions, les éléments de la première application tierce, traduits en objets et macro objets, sont récupérables dans une autre application cliente. Par exemple un tableau généré par un tableur est traduit en objet et inséré dans une page d'un site de la toile puis récupéré dans une application de traitement de texte, éventuellement automatiquement, sans intervention de l'utilisateur de la machine cliente.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, en outre, une étape de modélisation de l'ensemble des éléments d'un site Internet au travers d'objets distribuables et accessibles à distance en mettant en œuvre des protocoles standard. Ainsi, ce ne sont plus seulement les contenus des pages qui sont modélisés au travers d'objets, mais également tous les autres éléments constituant un site de la toile.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, en outre, une étape de définition d'un système générique d'exposition, à distance, d'objets de contrôles du site, par leurs méthodes et propriétés, en implémentant une couche web services utilisée comme protocole de communication et de contrôle.

On observe qu'il y a une différence entre les macro objets qui sont serialisables et transmissibles et les objets de contrôle que l'on utilise uniquement au travers de leurs propriétés et méthodes.

Ainsi, la présente invention étend le modèle objet de description non plus uniquement aux contenus des pages mais à la description de tout le site. Un site est défini comme un ensemble structuré de pages. Cependant sur un serveur http de l'art antérieur, le serveur n'a aucune connaissance de cette structure, il ne fait que transmettre les fichiers qu'on lui demande. Il n'a pas non plus de connaissance (sous la forme d'une structure de données) du contenu des pages et tout autre système. Grâce à la mise en œuvre de la présente invention, la structure des pages et leurs relations entre elles, ainsi que leur contenu forme un ensemble d'objets qui peut être modifié.

Il en résulte, sans que cette liste soit limitative, que la description par objet s'étend aux rubriques, sites, interactions entre objet au niveau script client, aux objets de données et à leurs contenus, aux utilisateurs contributeurs et vérificateurs, aux règles d'interactions entre les contributeurs et le site, aux règles d'interactions entre les contributeurs et les vérificateurs et aux modules de script.

La présente invention s'applique donc particulièrement au travail du concepteur de site et à tous les utilisateurs entrant en interaction avec le site au niveau conception et mise à jour. Cependant, elle améliore aussi la récupération de contenu par les utilisateurs du site pour les utiliser dans différentes applications informatique, comme exposé ci-après.

La modélisation du site Internet est ainsi :

- d'une part, représentée par la définition objet des pages, étendue à ses conteneurs (comme on l'a vu précédemment, des objets encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente, permettent de représenter l'ensemble des informations d'un site sous la forme d'une structure de données. On peut voir les structures principales sous la forme de « conteneur », c'est-à-dire qu'un site contient des pages, elles-mêmes contiennent

des objets contenant des propriétés - dans le cas présent, les conteneurs font référence à la structure de plus haut niveau, à savoir les sites et/ou un ensemble de sites sous la forme d'un compte client) et interactions (les événements et actions associés aux objets de la rubrique, tels que les clics de souris ou les saisies au clavier) sous une forme, elle aussi, objet et,

- d'autre part, la réunion d'un ensemble d'objets (par exemple, la traduction d'un tableau Excel - marque déposée - est constituée d'un objet de type tableau et d'objets de type Texte Simple constituant les cellules. Les objets de cet ensemble d'objets sont indissociables car chacun, pris individuellement, n'a pas de signification en dehors de ce contexte. On définit donc un macro objet nommé « W.H.O.L.E. », qui permet de conserver les relations entre les objets, ici les cellules et le tableau,

- ainsi qu'un système de traduction dynamique entre l'application cliente et le serveur. Ce modèle, une fois instancié, possède une représentation persistante au travers de la base de données. L'ensemble des classes et des mécanismes d'accès aux objets par des protocoles standards (par exemple SOAP, acronyme de Simple Object Access Protocol pour protocole simple d'accès aux objets ou web services) sont hébergés sur un serveur applicatif.

Le serveur est relié au réseau Internet qui permet son accessibilité par les applications clientes contenant le traducteur dynamique (éléments clients vers objets du site, et réciproquement). Le traducteur dynamique peut être implémenté dans toutes applications et constitue son 'Framework', c'est-à-dire l'ensemble des éléments composant la solution de traduction, ou conversion. Les mécanismes de commande du serveur en ce qui concerne tous les autres aspects, sont accessibles par des méthodes sur les différents objets correspondant aux organes de commandes. La présente invention permet donc, de par sa représentation objet totale et son accessibilité par le web, de contrôler entièrement non seulement le contenu d'un site mais aussi sa structure par la manipulation des objets et méthodes publiques qui constituent son interface de contrôle. On rappelle que, dans le domaine informatique, le terme « interface » possède au moins deux significations, dont l'une, qui concerne la présente invention peut- être un programme permettant l'interaction avec l'utilisateur, ou des fonctions permettant à des programmes d'interagir entre eux (exemple API Application Program Interface).

La présente invention permet, par exemple, grâce à l'inclusion du mécanisme de traduction dynamique (sous forme de script ou autre) dans une application comme Microsoft Word (marques déposées) de publier directement un contenu du document Word sur le site web sans que l'utilisateur final ne mette en œuvre d'autres outils que le logiciel (Word lui- même) implémentant la présente invention et l'application cliente, ici Word. En effet, Word implémenté un mécanisme de scripting qui permet d'ajouter des fonctions au programme

sans avoir à recompiler le programme. De ce fait, il est possible d'ajouter le traducteur et tous les autres programmes mis en œuvre pour implémenter la présente invention sans avoir à modifier le code source de Word et le recompiler. Excel ou Openoffice (marques déposées) présentent les mêmes mécanismes. En revanche, certains programmes de comptabilité, par exemple, ne permettent pas d'ajout et pour lui adjoindre les caractéristiques de la présente invention, il est nécessaire de modifier son code source et de le recompiler. Cet avantage s'étend à tout logiciel ou application cliente pouvant faire appel soit au protocole standard de communication, soit à des briques logicielles externes, directement, soit au travers d'un proxy (un proxy est un élément logiciel intermédiaire qui permet de faire le lien entre deux programmes applicatifs, comme une « dll » (acronyme de Dynamic Link Library pour bibliothèque de lien dynamique) dans l'environnement Windows (marque déposée).

La présente invention vise à définir, outre un modèle général des objets constituant un site Internet, un modèle ouvert d'objets pouvant être intégré au site web. Il s'agit ici de définir une interface générique pour les objets pouvant être conçu en dehors des serveurs et y être intégré. Ces objets qui sont matérialisés sous la forme de fichiers aux formats portables, par exemple l'XML (acronyme de extensible Markup Language pour langage de marquage étendu), permettront l'enrichissement de la plate-forme de part des contributions externes. La présente invention concerne aussi un procédé et un dispositif de traitement d'information. Elle s'applique, en particulier, au traitement d'événements entre un client Web, par exemple un navigateur, et un serveur en utilisant des technologies standard du web, le protocole http (acronyme de Hyper Text Transfer Protocol pour protocole de transfer hyper texte), le client supportant le DOM, niveau 2 (DOM étant l'acronyme de « Document Object Model » pour modèle d'objet de document). Le DOM est, pour les navigateurs, une représentation objet interne permettant à un script, comme Javascript (marque déposée), d'interagir avec la représentation mémoire du code HTML (acronyme de HyperText Markup Language pour langage avec liens hypertextes), et ainsi de modifier dynamiquement la page, le serveur Web permettant l'exécution de script, ainsi que la modélisation par objets d'un site Internet.

On désigne par « événement », l'intervention d'un utilisateur sur l'interface graphique d'un logiciel de navigation ou navigateur ou toute autre action asynchrone au programme comme l'arrivée de données ou la fin d'un chronomètre ou « timer ». Par exemple, cette action est crée par le mouvement de la souris, l'appui sur l'un des boutons de la souris ou l'action sur une touche du clavier.

L'application du réseau Internet appelée web fonctionne sur la base d'un client ou navigateur, d'un serveur hébergeant le contenu à fournir au client et d'un réseau permettant la communication entre le client et le serveur.

Les protocoles mis en jeu dans le cadre de l'échange d'informations entre le client et le serveur sont notamment le protocole http. Ce dernier ne permet pas de traiter un système événementiel complexe. La capacité de ce protocole au traitement des événements se résume en une requête GET ou POST qui appelle une nouvelle page à être charger sur le client en passant un ensemble de couple champ / valeur. Ce support très simple de traitement des événements clients ne satisfait pas la réalisation d'applications complexes et hautement Interactives. Deux obstacles majeurs nuisent au bon fonctionnement de telles applications, premièrement le rechargement complet d'une page à chaque événement provoque un désagrément graphique pour l'utilisateur et un comportement de l'application non-conforme aux standards des applications usuelles, d'autre part, il est impossible de traiter par ce système des événements très rapide comme le déplacement de la souris. En effet il n'est pas concevable d'émettre une requête vers le serveur pour chaque mouvement de la souris.

La présente invention vise à remédier à ces inconvénients.

A cet effet, la présente invention s'appui sur une représentation du contenu des pages de site par des objets, comme exposé dans le document FR 2797336, du même inventeur que la présente invention et incorporé ici par référence, quant à sa possibilité de modéliser un site Internet comme un ensemble d'objet. Ce document propose une extension sémantique de la structure DOM des navigateurs.

La présente invention vise à obvier à ces inconvénients ou impossibilités en proposant un nouveau système de gestion événementiel entre un client et un serveur en utilisant les technologies standard du web (Protocole http, Client supportant le DOM niveau 2 et le javascript, serveur Web permettant l'exécution de script), ainsi que la modélisation de site Internet exposée dans le document FR 2797336. Cette technologie met en oeuvre des éléments représentatifs des contenus des pages et de la structure des sites Web dans des bases de données situées sur un serveur central, lesdits éléments représentatifs étant constitués :

- d'objets contenus dans une base de données, un objet étant une entité autonome encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente,

- d'attributs desdits objets, lesdits attributs étant des paramètres modifiables pour constituer l'interface de l'objet vis à vis de l'utilisateur des applications clientes, de données de structure définissant la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles.

Chaque propriétaire de site peut modifier, via le réseau Internet, le comportement de ces objets en agissant sur leurs attributs au travers d'un gestionnaire d'objets. Il peut aussi agencer, via le réseau Internet, ces objets librement dans au moins une page et agencer les pages entre elles en agissant sur la structure au travers d'un éditeur. La consultation par un internaute du site déclenche l'activation, sur le serveur central, d'une procédure d'élaboration de pages dynamiques par un moteur d'application, à partir des informations contenues dans les bases de données de structure et d'objets, les pages dynamiques étant ensuite interprétées par un serveur HTTP et transmises sous forme de code HTML à l'application cliente. A cet effet, la présente invention vise, selon un deuxième aspect, un procédé de traitement d'information, caractérisé en ce qu'il comporte :

- une étape de détection d'un événement au niveau de l'interface d'un navigateur mis en œuvre sur un terminal client,

- pour au moins une partie des événements détectés, une étape de gestion de cet événement, symétriquement, d'une part, par un processus client et, d'autre part, par un processus serveur asynchrone au processus client.

La mise en œuvre de la présente invention autorise des temps de réponses de l'application instantané dans la mesure où le traitement du serveur n'entraîne pas de modifications dans le contenu de l'interface graphique. II résulte de la mise en œuvre de la présente invention, que la capture des événements se fait relativement aux objets, par exemple les objets définis dans le document FR 2797336, et que l'action qui peut résulter du traitement par le serveur de cet événement agit sur le rendu de ce même type d'objet ou autre actions de traitement.

Selon des caractéristiques particulières, le traitement de chaque événement par le serveur n'entraîne pas le rechargement d'une page en cours d'affichage par le navigateur, sauf si le rechargement est explicitement requis par le terminal client.

Grâce à ces dispositions, la gestion de l'événement par le serveur ne nuit pas à l'interactivité de l'application cliente.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte une étape de traitement, dans le terminal client, de tout événement détecté pour déclencher soit une action directe, action ne nécessitant pas traitement de la part du serveur, sur un objet de l'interface client, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements simples, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements complexes. Les événements complexes sont des événements qui comportent des informations complémentaires à l'événement lui-même. Par exemple, l'événement 'onmoumouve' lorsque

Ia souris bouge, est un événement simple, mais Onmousmouve(x,y)' avec x et y les coordonnées de la souris au moment de l'événement, est un événement complexe.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, pour les événements mémorisés dans la pile d'événements simples, une étape de transmission au serveur.

Selon des caractéristiques particulières, l'étape de transmission est effectuée par l'intermédiaire d'une requête http simple de type GET.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, pour les événements mémorisés dans la pile d'événements complexes, une étape de sérialisation des données représentatives de l'événement complexe et une étape de transmission au serveur des données sérialisées.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, pour les événements transmis au serveur, une étape de stockage, par le serveur, dans au moins une base de données associée aux piles. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, une étape de génération de requête de traitement des événements stockés dans chaque base de données, au travers d'un gestionnaire d'événements.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, au niveau du gestionnaire d'événements, une étape de génération dynamique d'un script client et une étape de transmission, par le serveur, dudit script client au terminal client.

Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte une étape d'action, dans le terminal client, du script client sur des objets clients pour en modifier le rendu. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte une étape de gestion des quatre types d'événements suivants : i. client - client, action directe d'un événement sur un objet client sur autre objet client ou lui-même, ii. client - serveur synchrone simple, événement standard du DOM n'impliquant pas d'autres informations que l'identifiant objet récepteur et le nom de l'événement, nécessitant un traitement serveur dont le résultat modifie le rendu graphique de l'interface cliente, iii. client - serveur synchrone complexe, événement non standard du DOM ou nécessitent plus d'informations que pour le point ii et iv. client - client synchrone / client - serveur asynchrone complexe, événement standard ou non du DOM ayant à la fois une action directe sur l'interface cliente

et un traitement serveur dont le résultat n'interfère pas avec l'action cliente - cliente.

D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés, dans lesquels :

- la figure 1 représente, schématiquement, l'architecture globale d'un dispositif implémentant la présente invention,

- la figure 2 représente, schématiquement, un détail de mise en œuvre de la présente invention, - la figure 3 représente, schématiquement, un exemple de mise en œuvre du procédé objet de la présente invention et la figure 4 représente le schéma fonctionnel du procédé de traitement d'information et d'événement objet du deuxième aspect de la présente l'invention.

Avant de décrire les figures, on donne, ci-dessous, des définitions qui seront utilisées dans la description.

« générique » : C'est à dire que l'on n'ait pas à modifier le programme dans le cas d'ajout de nouveaux objets au système ;

« exposition des objets » : Terme informatique désignant que les objets sont accessibles par des programmeurs tiers, en effet une application orientée objet est composée d'un certain nombre d'objets, certains servant au fonctionnement interne et sont donc non accessibles depuis l'extérieur, d'autre servant d'éléments d'interface du programme avec l'extérieur on dit qu'ils sont « exposés » ; « méthodes et propriétés » : Terminologie des langages orientés objet les méthodes sont les fonctions associées à un objet, les propriétés sont des variables associées à l'objet dont on peut connaître la valeur ;

- « couche » : Comme le modèle OSI définit la communication entre application par un certain nombre de couches communicant entre elles, nous mettons en place ici un protocole qui échange des informations entre couche communicant avec les couches adjacentes (au dessus et en dessous) ; - « web services » : le web services étant une technologie connue et publique, le terme de couche web service signifie que l'on peut utiliser les web services dans la couche de transport et de contrôle pour invoquer des méthodes sur des objets distants à travers le protocole http, par exemple ; « Macro objet » ou « objet W.H.O.LE. » : « Macro » signifiant « englobant », un macro objet est la représentation d'un objet contenant un ensemble d'objets ;

« traduction » ou « conversion » : Elles consistent à passer d'une représentation à une autre par des moyens déterministes. Par exemple, un compilateur est un

traducteur d'un langage X vers un langage Y. Dans notre cas, on traduit la structure de données de l'application vers une structure de données compatible avec les objets définis dans le brevet FR2797336. Par exemple, pour un tableau Excel (qui est un conteneur de cellules, objets faisant référence à des textes simples), on traduit les données de l'application pour convertir en objets + attributs + structure. Pour Excel, on crée un ensemble d'objets liés en un macro objet qui donne cohérence vis-à-vis du serveur et évite de perdre lien entre cellules et contenus ; « enfouissement » : fait référence à l'ensemble des objets non visibles depuis l'extérieur : on ne peut avoir accès aux objets élémentaires, Ie macro objet est exposé mais pas ses éléments unitaires ;

« encapsulation » : le fait de rendre inaccessible, à un utilisateur final, le code source de l'objet mais de permettre l'accès aux fonctions dudit objet et les « clients » sont, de façon générique, tout logiciel interagissant avec le serveur. Dans le cas strict de la présente invention, les clients sont les programmes tiers autre que les navigateurs web dialoguant avec le serveur ;

« éléments clients » : Dans une architecture client-serveur n tiers il y a un serveur et un client, le client étant le programme qui communique avec le client les éléments clients sont les données qui se trouvent dans ce programme. Par exemple, les éléments qui se trouvent traitées par un programme Excel ; - « contributeur » : toute personne physique susceptible de modifier le contenu d'un site dûment habilitée ;

« vérificateur » : toute personne physique pouvant autoriser ou non la publication du contenu d'un contributeur sur le site ; « base de données » : tout système pouvant contenir des données, d'un simple fichier au serveur de données ; objets « V.D.O.M. » : des entités autonomes encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente, chaque objet possédant des attributs, paramètres modifiables permettant de contrôler le rendu de l'interface de l'objet vis à vis de l'utilisateur des applications clientes. On observe que des données de structure extérieures aux objets V.D.O.M. définissent la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles. L'homme du métier pourra se référer au document FR 2797336 pour mieux connaître ces objets.

La mise en œuvre de la présente invention s'appuie sur celle décrite dans le brevet FR 2797336 et les technologies additionnelles ou concurrentes qui ont été décrites depuis le dépôt de ce brevet. Dans la présente invention, on utilise la partie du système décrit dans le brevet FR 2797336 qui permet de transformer une représentation objet d'un site vers des

pages exploitables par un serveur http standard. Un des objets de la présente invention est de remplacer l'interaction de l'homme avec le serveur, au travers d'un navigateur, pour construire ou modifier un site par l'intermédiaire d'un logiciel autre qui n'a pas pour vocation à l'origine de produire un quelconque contenu pour le web. On rappelle que le brevet FR 2797336 enseigne un procédé d'interaction entre des applications informatiques et un site distant, qui met en œuvre des éléments représentatifs des contenus des pages dans des bases de données situées sur un serveur central, lesdits éléments représentatifs étant constitués :

- d'objets contenus dans une base de données, un objet étant une entité autonome encapsulant des fonctions pour générer un code informatique, par exemple HTML, interprétable par une application de navigation cliente, d'attributs desdits objets, lesdits attributs étant des paramètres modifiables pour constituer l'interface de l'objet vis à vis de l'utilisateur des applications clientes et de données de structure définissant la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles.

Comme on l'observe en figure 1 , le dispositif objet de la présente invention met en œuvre le réseau Internet et utilise des protocoles standards : le protocole HTTP est L'Hyper Text Transfert Protocol ou protocole de transfert hyper texte. Le protocole SOAP est le Simple Object Access Protocol ou protocole simple d'accès à des objets. Le modèle objet complet d'un site respecte le paradigme objet et en supporte au moins les principales caractéristiques, il en résulte que son implémentation doit être mise en oeuvre à l'aide d'un langage objet ou, au moins, en supporter les principes dans le cas de la manipulation de ceux-ci au travers d'un réseau permettant la transmission de leurs composantes par un protocole standard, par exemple Internet. La présente invention propose aussi un système de traduction dynamique d'un ensemble d'éléments contenu dans l'application source vers une représentation objet par une traduction dynamique réversible et elle propose aussi de conserver cette représentation sous la forme d'un macro objet W.H.O.L.E dont chaque objet est indissociable des autres.

La figure 1 donne le schéma global d'un mode de réalisation particulier d'un dispositif objet de la présente invention, dans lequel un serveur applicatif 100 comporte :

- une représentation générale de chaque site 105 sous la forme d'objets V.D.O.M. 110 et de leurs extensions, mémorisées dans une base de données,

- un système 115 de persistance des objets pouvant garder des données, du simple fichier au serveur de base de données, de façon non volatile, - un système 130 de vérification de signature optionnel, désérialiseur (on rappelle que la sérialisation est le procédé qui transforme une représentation complexe en un ensemble de données séquentiel - en général un ensemble de caractères - que l'on peut

transmettre par une liaison série c'est-à-dire octet par octet, la désérialisation est l'opération inverse et un déserialiseur est la fonction qui effectue ce travail) et séquenceur permettant d'implémenter les macros objets W.H.O.L.E. sous la forme d'objets V.D.O.M. en gardant une liaison entre eux, - d'un système 120 permettant d'invoquer des méthodes depuis le réseau sur les objets de contrôle du serveur par des protocoles standards, par exemple SOAP (dans le prototype développé par l'inventeur, un mécanisme permettant de faire cette opération est les web services, mais il en existe d'autres comme le RPC-XML),

- d'un générateur de réponse 125 pouvant, suivant le cas, retourner un macro objet W.H.O.L.E. vers le client ou une réponse à une action de contrôle, réponse qui est sérialisée et transmise par l'intermédiaire d'un réseau 140, par exemple Internet.

Une partie cliente est constitué d'une part d'une application cliente 155 (un programme quelconque) ou d'un serveur applicatif 160 dans lequel on a ajouté, soit par script si l'application l'autorise, soit directement dans le programme principal de l'application, la logique, ou mécanisme, 165 de traduction, d'enfouissement, de sérialisation et la logique de traduction réciproque et de contrôle, le système optionnel de signature du flux sérialisé 170 et la couche de transport par protocole standard 175 (par exemple SOAP ou web services).

Lorsqu'un utilisateur de l'application 155 lance un processus de transfert vers le site Internet, le mécanisme de traduction 165 des éléments à transférer est invoqué et génère un macro objet W.H.O.L.E. contenant un ensemble d'objets V.D.O.M. élémentaires décrivant le ou les éléments à transférer. Ce macro objet est ensuite sérialisé et, optionnellement, signé par le système de signature 170.

Le mécanisme de contrôle 165 (le contrôle se faisant par l'invocation d'une ou plusieurs méthodes) initie une séquence de commande représentée par la flèche 180 qui forme une session ayant pour but l'insertion, représentée par la flèche 185, du macro objet W.H.O.L.E. dans le site web (ces commandes peuvent aller de la simple demande d'inclusion du macro objet dans une page à la création d'une nouvelle page avec inclusion de cette objet ou d'autres actions encore plus complexe). Suivant ce processus, les méthodes de contrôle 120 agissent sur le modèle objet

105, c'est-à-dire l'ensemble des objets constituant la représentation d'un site, le mécanisme d'inclusion du macro-objet dans la page cible opère et une réponse, représentée par la flèche 190, est générée par le générateur de réponses 125 et est transmise à l'application cliente par les protocoles standards. Dans le cas de la récupération d'un objet W.H.O.L.E. depuis le serveur applicatif vers une application, les actions sont les suivantes : le système de contrôle de la partie cliente (les commandes sont matérialisées par des appels de fonctions ou méthodes, lorsqu'elles

sont liées à un objet, c'est la fonction que l'on appelle sur le serveur) demande la récupération de l'objet W.H.O.L.E., celui-ci est généré par le générateur de réponse 125, sérialisée puis transmis à l'application cliente, le système de traduction dynamique 165 transforme chaque objet V. D. O. M. en des éléments compatible avec l'application cliente 155. Le résultat est alors disponible dans l'application cliente 155. On observe qu'il peut y avoir un traducteur pour chaque application cliente.

La figure 2 présente, en détail, le fonctionnement d'une séquence de transfert du dispositif illustré en figure 1. Partant, sur un poste de travail 200, d'une application cliente d'origine 205 qui contient un certain nombre d'éléments 210 à publier sur le web, le traducteur dynamique 165 analyse les éléments à transmettre et les transforme en un ensemble d'objets élémentaires V.D.O.M. 220, dans un macro objet W.H.O.L.E. 230 . Afin d'être transmissible sur le réseau, ce macro objet » est sérialisé par un sérialiseur 225 puis transmis à l'aide d'un protocole standard au serveur applicatif 100 standard et compatible. Le serveur applicatif 100 crée ensuite la série d'objets transmis, dans une rubrique, 240 définie par les mécanismes de contrôle vus précédemment.

En figure 2, trois objets se trouvent en dehors du macro objet 230, pour indiquer que la rubrique dans laquelle le macro objet 230 est inséré peut ne pas être vide avant l'insertion de ce macro objet 230.

Les éléments locaux à l'application 205 qui transmet du contenu vers le web n'étant pas, à l'origine, représentés d'une quelconque manière sous la forme d'objets V.D.O.M., le traducteur dynamique 165 convertit ou traduit les données locales en un ensemble de données qui décrivent le contenu de l'application comme un ensemble d'objets V.D.O.M. pour pouvoir les transmettre au serveur et que celui-ci reconstruise cette structure de données sur le serveur 100. Le traducteur 165 fabrique un macro objet 230 qui réunit l'ensemble des objets 220 en un ensemble cohérant qui préserve le fait que chaque objet élémentaire 220 dépende des autres objets du même macro objet 230. Cette représentation doit ensuite être envoyée par l'intermédiaire du réseau 140. C'est donc ici qu'intervient le mécanisme de sérialisation 225 qui transforme cette représentation en une séquence de caractères que l'on peut transmettre par le réseau 140. A son autre extrémité, c'est-à-dire sur le serveur 100, on reconstruit cette structure de données pour la conserver dans une base de données et l'utiliser ensuite pour générer des pages Web comme exposé dans le brevet FR 2797336.

L'ensemble des objets V.D.O.M. élémentaires 220 créés sont cependant maintenus par une liaison entre eux définissant précisément un objet W.H.O.L.E. 230. Aucun de ces objets ne peut être dissocié des autres et, par exemple, une tentative de suppression de l'un d'entre eux supprimera tous les autres. Il est par conséquent possible de récupérer, lors de la demande d'une autre application 255, sur un autre poste de travail 250, la structure exacte

du système d'objets transmis par l'application 205. C'est ce qui est fait par l'application tierce 255 qui est, dans le cas représenté en figure 2, différente de l'application 205 ayant transmis ces données initialement. Lorsque cette application tierce 255 demande à récupérer un objet W.H.O.L.E. 230, le serveur 100 procède à la sérialisation de l'objet puis le transfère par un protocole standard vers l'application cliente 255. L'application cliente 255 désérialise le flux puis décompose la série d'objets V.D.O.M. à traduire en éléments compatibles avec l'application cliente 255 (si possible). Le traducteur 165 effectue ensuite son travail et ajoute, dans l'application cliente 255, les éléments ainsi traduits.

Un exemple concret de ce processus est donné dans la figure 3. Dans cette figure 3, on observe une application 205 de type tableur qui contient un tableau de données 305. Cette application 205 transmet ce tableau 305 vers le serveur 100. A cet effet, le traducteur 165 transforme ce tableau 305 et les données qu'il contient, en une série d'objets élémentaires V.D.O.M. 310 qui sont, chacun, un objet de type tableau 310, puis un ensemble d'objets de type texte simple 315, ces derniers contenant les données de chaque cellule. Ces objets sont ensuite sérialisées et transmis au serveur 100 via le réseau 140. Le serveur 100 construit alors les objets localement dans une page 320 définie par le mécanisme de contrôle. Il est ensuite possible de publier cette page grâce aux mécanismes intégrés au serveur 100 pour en obtenir une page HTML.

On suppose ici qu'une l'application 225, de type traitement de texte, demande à récupérer le tableau 305 transmis au serveur 100 pour l'intégrer dans son document courant. Le serveur 100 sérialise alors les objets et les transmet via le réseau 140. Ces données sont ensuite traitées par le traducteur dynamique 165 en éléments compatibles avec l'application 255. Le tableau 325 est alors reconstruit dans cette application 255.

Avant de détailler la description de la figure 4, on rappelle que l'on désigne par « événement », l'intervention d'un utilisateur sur l'interface graphique d'un logiciel de navigation ou navigateur. Par exemple, cette action est crée par le mouvement de la souris, l'appui sur l'un des boutons de la souris ou l'action sur une touche du clavier ou toute autre action asynchrone au programme comme l'arrivée de données ou la fin d'un 'timer'.

Le procédé de traitement d'information objet de la présente invention comporte : - une étape de détection d'un événement au niveau de l'interface d'un navigateur mis en oeuvre sur un terminal client,

- pour au moins une partie des événements détectés, une étape de gestion de cet événement, symétriquement, d'une part, par un processus client et, d'autre part, par un processus serveur asynchrone au processus client. Ainsi, l'application peut répondre instantanément dans la mesure où le traitement du serveur n'entraîne pas de modifications dans le contenu de l'interface graphique. Il résulte de la mise en œuvre de la présente invention, que la capture des événements se fait

relativement aux objets, par exemple définis dans le document FR 2797336 incorporé ici par référence, et que l'action qui peut résulter du traitement par le serveur de cet événement agit sur le rendu de ce même type d'objet ou autre actions de traitement.

Préférentiellement, le traitement de chaque événement par le serveur n'entraîne pas le rechargement d'une page en cours d'affichage par le navigateur, sauf si le rechargement est explicitement requis par le terminal client. La gestion de l'événement par le serveur ne nuit donc pas à l'interactivité de l'application cliente.

On observe, en figure 4, que trois couches sont mises en œuvre. Ces couches sont le client C1 , le réseau Internet C2 et le serveur C3. L'événement 411 est capté sur une interface graphique du client et est géré par la logique interne de cette interface graphique pour être ensuite intercepté par un dispatcher 412 de modélisation objet client qui décide quelles sont les actions à mener pour cet événement.

Le dispatcher 412 effectue une étape de traitement, dans le terminal client, de tout événement détecté pour déclencher soit une action directe, action ne nécessitant pas de traitement de la part du serveur, sur un objet de l'interface client, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements simples, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements complexes.

Les événements complexes sont des événements qui comportent des informations complémentaires à l'événement lui-même. Par exemple, l'événement 'onmoumouve' lorsque la souris bouge, est un événement simple, mais Onmousmouve(x,y)' avec x et y les coordonnées de la souris au moment de l'événement, est un événement complexe.

Plusieurs cas de figure sont possibles et sont déterminés en amont par un compilateur qui analyse le code programme et génère les éléments de programmes nécessaires et, en particulier indique le cas dans lequel on se trouve.

Dans un premier cas de figure, l'action, ou l'événement, n'a pas à être traitée par le serveur et n'a d'action que sur le client, une action 415 client - client est alors émise et agit sur un autre objet de la page affichée comportant les objets 425.

Dans un deuxième cas de figure, l'action est purement synchrone au résultat du serveur et ne nécessite pas d'argument supplémentaire que l'événement lui-même et que l'objet sur lequel il a été intercepté. Cet événement est alors mis dans une pile FIFO (acronyme de First In First Out pour premier entré premier sorti) des événements simples 413. A intervalle de temps régulier, le navigateur scrute cette pile interne afin de transmettre les événements au serveur s'il y en a dans la pile. La transmission des événements au serveur ainsi que de l'identifiant objet réfèrent se fait grâce à la capacité des navigateurs à exécuter plusieurs requêtes http dans la même instance d'un navigateur. Le procédé utilisé pour générer cette requête alors que la page est

complètement chargé peut être multiple. Il peut être, par exemple, initié dans une Frame (ou trame) (nouvelle instance de chargement d'une page dans le navigateur) ou par des techniques autre comme par exemple celle connue sous le nom de « remote scripting ». On effectue donc une requête de type « GET » HTTP dans laquelle on transmet le contenu de la pile 413 qui contient les événements à transmettre.

On rappelle qu'une requête HTTP est une requête selon le protocole HTTP, le protocole de base des échanges de données entre un client web et un serveur web, par exemple la version de ce protocole HTTP v1.0 (RFC 1945) v.1.1 (RFC 2068). On l'observe, par exemple, dans les adresses électroniques, communément appelées « URL », acronyme de Uniform Resource Locator pour localiseur de ressources uniforme, par l'en-tête « http:// ». On précise qu'une requête simple est une requête de type « GET » suivie de l'uri (l'uri est une sous partie de l'uri, celle qui fait référence au document) c'est-à-dire 7<document> ?<données>' ce qui signifie que l'on passe les données directement dans les informations de requête du document ce qui limite la quantité de données transmissible (256 caractères selon les spécifications des uri ), contrairement à une requête de type « POST » qui permet de passe des données en quantité arbitraire.

Un script serveur transfert les données de la requête dans une base de données 417 du serveur associée à une pile d'événement simples 419, consécutivement, un générateur de requête 424 commande le traitement de l'événement par le gestionnaire du serveur 421. Le gestionnaire d'événements 421 du serveur dépile les événements. Le processeur de traitement exécute le script associé à l'événement. Le résultat est la génération dynamique d'un script client effectuant des actions sur les objets instanciés sur le client.

Ainsi, le procédé objet de la présente invention comporte, dans des modes de réalisation exemplaires, une étape de génération de requête de traitement des événements stockés dans chaque dite base de données, au travers d'un gestionnaire d'événements. Le gestionnaire d'événements effectue une étape de génération dynamique d'un script client, une étape de transmission de ce script client au terminal client, étant effectuée par le serveur. Il s'en suit une étape d'action, dans le terminal client, du script client sur des objets clients pour en modifier le rendu. Dans un troisième cas de figure, l'action est synchrone avec le traitement sur le serveur et nécessite des paramètres additionnels à l'identifiant objet et au nom de l'événement, ou n'est pas un événement standard supporté par le DOM, il s'agit alors d'un événement dit « complexe ». On rappelle que les événements complexes sont des événements qui comportent des informations complémentaires à l'événement lui-même. Par exemple, l'événement 'onmoumouve' lorsque la souris bouge, est un événement simple, mais Onmousmouve(x,y)' avec x et y les coordonnées de la souris au moment de l'événement, est un événement complexe. Cet événement est matérialisé, coté client, par un

objet Java Script contenant un nombre de bases d'informations qui sont l'Identifiant Objet, le type d'événement, les coordonnées (X ₁ Y) de l'objet et un champ data supplémentaire contenant une quantité arbitraire de couple (étiquette, valeur) représentant les paramètres spécifiques à cet événement. Dans ce cas, le dispatcher d'événement 412 stocke l'objet événement dans la pile

FIFO des événements complexes 414. A intervalle de temps régulier, le navigateur scrute cette pile interne 414 afin de transmettre les événements au serveur, s'il y en a dans la pile.

La transmission des événements au serveur ne peut pas, dans ce cas, être une simple requête http. En effet le protocole http ne peut transmettre des objets java script directement au serveur. Un serialisateur 416 transforme alors les objets de la pile 414 en un ensemble de données transmissibles par http.

La sérialisation effectuée et le stockage de l'événement dans une base de données 418 du serveur associée à une pile 420 d'événements complexes conservée dans le serveur, le générateur de requête 424 commande le traitement de l'événement par un gestionnaire d'événement 421 du serveur. Le gestionnaire d'événements 421 du serveur dépile les événements. Le processeur de traitement 422 exécute le script associé à l'événement. Le résultat est la génération dynamique d'un script 423 client effectuant des actions sur les objets instanciés sur le terminal client.

Dans un quatrième cas de figure, l'action est synchrone au client et asynchrone au traitement serveur. Dans ce cas, le dispatcher génère parallèlement un événement de type direct destiné à être traité par le serveur. La condition pour un bon fonctionnement du système est que le résultat du traitement du serveur n'agisse pas en contradiction avec l'événement Client-Client.

Ainsi, la mise en œuvre de la présente invention permet de gérer les quatre types d'événements suivants : i. client - client, action directe d'un événement sur un objet client sur autre objet client ou lui-même, ii. client - serveur synchrone simple, événement standard du DOM n'impliquant pas d'autres informations que l'identifiant objet récepteur et le nom de l'événement, nécessitant un traitement serveur dont le résultat modifie le rendu graphique de l'interface cliente, iii. client - serveur synchrone complexe, événement non standard du DOM ou nécessitant plus d'informations que pour le point ii et iv. client - client synchrone / client - serveur asynchrone complexe, événement standard ou non du DOM ayant à la fois une action directe sur l'interface cliente et un traitement serveur dont le résultat n'interfère pas avec l'action cliente - cliente.