WO2002075546A2 - Procede de sauvegarde et de restauration de l'ensemble des parametres de configuration d'une plateforme informatique par l'intermediaire d'un serveur - Google Patents

Procede de sauvegarde et de restauration de l'ensemble des parametres de configuration d'une plateforme informatique par l'intermediaire d'un serveur Download PDF

Info

Publication number
WO2002075546A2
WO2002075546A2 PCT/FR2002/000953 FR0200953W WO02075546A2 WO 2002075546 A2 WO2002075546 A2 WO 2002075546A2 FR 0200953 W FR0200953 W FR 0200953W WO 02075546 A2 WO02075546 A2 WO 02075546A2
Authority
WO
WIPO (PCT)
Prior art keywords
server
platform
configuration
data
analysis
Prior art date
Application number
PCT/FR2002/000953
Other languages
English (en)
Other versions
WO2002075546A3 (fr
Inventor
Sébastien ANGELE
Fabrice Bardon
Philippe Clavel
Olivier Dumont
Original Assignee
Angele Sebastien
Fabrice Bardon
Philippe Clavel
Olivier Dumont
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Angele Sebastien, Fabrice Bardon, Philippe Clavel, Olivier Dumont filed Critical Angele Sebastien
Priority to AU2002255064A priority Critical patent/AU2002255064A1/en
Publication of WO2002075546A2 publication Critical patent/WO2002075546A2/fr
Publication of WO2002075546A3 publication Critical patent/WO2002075546A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/875—Monitoring of systems including the internet

Definitions

  • the subject of the present invention is a method for saving and restoring all of the configuration parameters of a computer platform, for example a personal computer or a fleet of computers, by means of a server for example.
  • a server for example.
  • an Intranet or Internet server It concerns both the configuration of the platform's operating system and that of specialized software (word processors, spreadsheets, Internet browsers, email managers, etc.) installed on this platform.
  • the method which is the subject of the invention has the property of being independent of the operating system used by the platform whose configuration is saved, this configuration being able to be restored on machines equipped with a different operating system. Similarly, software configuration parameters can be restored to different software that may have similar functionality.
  • the method also offers the possibility of carrying out all the operations of modification, insertion or deletion of the saved configurations and of protecting their confidentiality.
  • the invention applies in particular, but not exclusively, to the recovery of its configuration by a user forced to change platform, to the standardization of the configurations on a fleet of computers or even to the reinstallation after replacement of equipment.
  • the network computer provides standardization by nature within the network, the system and software configuration being centralized in the main server. But we know the speed limits of networks, which can hardly be used for example for the animation of complex graphic objects.
  • a first family of software [ref: "Webshot”, “Stardock”] only facilitate the personalization of the computer, only at the level of the configuration of the screen.
  • ASP Application Service Provider
  • the present invention therefore aims to eliminate these drawbacks and limitations, and to offer a general means of backing up and restoring all of the configuration parameters of an IT platform and user preferences, as well as operating system level as specialized software, 'with the essential property of enabling the recovery of this configuration on a system or software different from those from which the backup was made.
  • This process could also include a phase of restoring the configuration data saved by the server site on the requesting platform, possibly separate from the aforementioned platform, this phase of restoration comprising the following steps:
  • the application for backing up and restoring configurations can be offered to users in the form of an ASP procedure on the Internet or on the Intranet (defined above).
  • Such a choice has the following advantages:
  • the method according to the invention comprises at least, in general, the following subsets, which are therefore all installed on the server site:
  • - a Database preferably on the relational model, the different parts of which are: - an Application Database, containing the data necessary for the proper functioning of the application, - a General Public database, relating to information on the users of the application,
  • Appliquette or applet small program integrated into an HTML page and which performs a function
  • AP preferably programmed in JAVA language
  • each tree is defined by a root and can contain a list of dependent trees.
  • the data is organized into a chain, a system of pointers allowing access to the element contained in a link in the chain, or else to move to the next link or the previous link.
  • Associated functions allow you to insert or destroy trees or elements.
  • the operation of the Application Server implements a listening "socket" (channel) which remains pending a connection request. It receives a request from the Server which previously identified the user (by verifying its password) and then associates with this user one of its "sockets”.
  • the "Login” process on the Web server has indeed initialized a User Object. This performs step by step the processing requested by the request. This Object is put into action thanks to a set of Execution Units ("threads") associated with the "socket”.
  • Execution Units are normally dormant and returned to the active state by the responses to the read or write operations requested by the User Object. They then send the latter the order to continue the treatment until the requested result is obtained. Verification devices for exceeding the limited durations make it possible to eliminate unsuccessful connections.
  • the data will be encrypted in RSA.
  • Module includes all the parameters of a given operating system or specialized software; during the preparatory phase of a backup or restore procedure, before receiving the values of the parameters concerned;
  • Pre-module is a set of niinimal data characterizing the Module
  • - a Package includes all the Modules of the same software family (Word Processing for example); - a Configuration is the set of Packages for a user.
  • the operating mechanism of the User Object comprises at least the following steps:
  • a similar mechanism, according to the invention, is implemented for the Restoration. It includes at least the following phases:
  • each transmitted object is represented by a series of formatted bytes, which successively includes:
  • the start and end bytes are redundancies intended to ensure data integrity.
  • the different object classes can be, in a non-exhaustive manner:
  • the length and format of the data string contained in the serialized object depend of course on the class to which the object belongs.
  • each object After transmission, each object is de-serialized before being used, the reading of the class identifier allowing the interpretation of the data area.
  • the data exchanges between the AP, which provides the interface function with the User, and the Application Server, which performs the requested processing will preferably be carried out by integrating the data flow in an HTTP protocol .
  • This choice has, among other things, the advantage of allowing the crossing of “firebreak” walls that may be installed on the Server site.
  • the exchanges between the AP and the Server will essentially take the form of sending requests by the AP, to which actions executed by the Server respond, which returns the resulting data.
  • the HTTP header which can have a form adapted to the format of the following blocks;
  • the request header which contains the indication of the type (normal or error request) and the nature of the request
  • the response of the Server to a request may include similarly:
  • the response header which contains the indication of the type (normal or error case) and the nature of the response;
  • This dialogue can advantageously be associated with the management of a maximum number of errors, beyond which the response from the Server signals a next disconnection.
  • the communication protocol between the Web Server and the Application Server will include at least connection requests sent by the Web Server, which do not require encryption, and their response by the Application Server.
  • the function of the Web Server itself is to receive the connection request from the user, with his password.
  • a Script procedure (text file containing a set of instructions intended to be executed by a script interpreter, this procedure using a DAL dynamic function library) is executed, which allows to: - authenticate the user thanks to the Application Server,
  • the function of the AP itself is to save or restore Modules on the user's workstation. To do this, its execution is controlled by two Execution Units (threads): the main ensures data processing, the other the connection with the Server.
  • the main execution process taking into account the functioning according to the invention of the User Object described above, will include at least in the case of the Backup the following steps:
  • the functionality offered to the user on the website may include, without limitation, from a home page:
  • FIG. 1 gives the general architecture of the method according to the invention
  • Figure 2 is the block diagram of a Backup procedure
  • Figure 3 is the block diagram of a Restoration procedure
  • Figure 4 gives the operating principle of the User Object
  • FIG. 5 represents the diagram of states of the User Object during a backup
  • FIG. 6 represents the same diagram in the case of restoration
  • Figure 7 illustrates the general format of a serialized object
  • FIG. 8 gives the format of the requests sent by the AP to the server;
  • Figure 9 shows the format of responses to requests returned by the server.
  • FIG. 1 are represented the main sub-assemblies forming the general architecture of the method according to the invention: the Database 1 communicates through the Interface 2 with the Web Server 3 and the Application Server 4. The Web Server 3 and the Application Server 4 exchanges information with the Appliquette (AP) 5 downloaded on the platform, here the user's computer.
  • AP Appliquette
  • the functional diagram in Figure 2 represents the circulation of the Pre-modules and Configuration Modules between the Database, the Server and the User during a Backup procedure: the Pre-modules are transmitted to the AP on the user's computer, where the choice of Modules to be saved is made; the selected Pre-modules are sent back to the Server which constitutes the data block of the Modules to be saved before returning them to the AP where the current configuration parameters are integrated into the Modules; the Modules are finally sent again to the Server, which performs the reconversion operations necessary for the reconstitution of the Packages concerned, before replacing them in the Database; at each movement of a Pre-module or a Module, the corresponding data are serialized at the start and de-serialized at the finish.
  • FIG. 3 shows the processing of Pre-modules and Modules during a Restoration procedure: the Pre-modules are extracted from the Database and transmitted to the AP where s 'operates the selection; the Pre-modules concerned are returned to the Server, which performs the conversions necessary to reform the Package to be restored with the parameters extracted from the Database, before returning this Package to the AP, which proceeds with the restoration.
  • the Pre-modules are extracted from the Database and transmitted to the AP where s 'operates the selection
  • the Pre-modules concerned are returned to the Server, which performs the conversions necessary to reform the Package to be restored with the parameters extracted from the Database, before returning this Package to the AP, which proceeds with the restoration.
  • the ESI state ends with the sending of the Choice of Modules and leaves room for an intermediate state
  • the successive states of the User Object appear in Figure 6: the ERO (Connection), ER1 (Analysis) and ER2 (Processing) states are similar to the ESO, ESI and ES2 states respectively in the Backup case; the following state ER3 (Sending of Modules) is maintained until the transmission of the last Module, before giving way to the state ER4 (End).
  • FIG. 7 represents the general format of the serialized objects transmitted between the Server and the AP. Each object is successively formed from:
  • Figure 8 shows the format of requests sent by the AP to the Server. This format successively includes: - the HTTP header;
  • the identifier of the user UI encrypted according to the RSA algorithm and which itself comprises four parts: the identifier of the key to be used for IDC decryption, the total size of the encrypted area, the identifier of the user himself IDU and the number of NBI iterations;
  • the ETR request header which has two parts: the TR type (normal or error) and the nature of the NR request;
  • Figure 9 gives the format of the Server response to a request, which includes:

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Automatic Analysis And Handling Materials Therefor (AREA)

Abstract

Le procédé selon l'invention comprend une phase de sauvegarde comportant une demande de sauvegarde de la plateforme sur un serveur Internet ou Intranet, l'acceptation de la demande par le serveur et la transmission par ce serveur à la plateforme de données pour analyser cette plateforme, l'analyse interne de la plateforme à partir desdites données et la transmission au serveur des résultats de l'analyse, la préparation par le serveur des données de sauvegarde et la transmission à la plateforme de ces données, la sauvegarde par la plateforme de ses données de configuration et leur transmission au serveur, et la conversion puis la sauvegarde par le serveur de ces données.

Description

PROCEDE DE SAUVEGARDE ET DE RESTAURATION DE L'ENSEMBLE DES PARAMETRES DE CONFIGURATION D'UNE PLATEFORME INFORMATIQUE PAR L'INTERMEDIAIRE D'UN SERVEUR.
La présente invention a pour objet un procédé de sauvegarde et de restauration de l'ensemble des paramètres de configuration d'une plateforme informatique par exemple un ordinateur individuel ou d'un parc d'ordinateurs, par l'intermédiaire d'un serveur par exemple un serveur Intranet ou Internet. Elle concerne aussi bien la configuration du système d'exploitation de la plateforme que celle des logiciels spécialisés (traitements de texte, tableurs, navigateurs Internet, gestionnaires de courrier électronique, etc ..) installés sur cette plateforme.
Le procédé objet de l'invention possède la propriété d'être indépendant du système d'exploitation utilisé par la plateforme dont on sauvegarde la configuration, cette configuration pouvant être restaurée sur des machines équipées d'un système d'exploitation différent. De façon analogue, les paramètres de configuration des logiciels peuvent être rétablis sur des logiciels différents pouvant présenter des fonctionnalités similaires. Le procédé offre en outre la possibilité d'effectuer toutes les opérations de modification, insertion ou suppression des configurations sauvegardées et de protéger leur confidentialité. L'invention s'applique notamment, mais non exclusivement, à la récupération de sa configuration par un utilisateur contraint de changer de plateforme, à la standardisation des configurations sur un parc d'ordinateurs ou encore à la réinstallation après un remplacement de matériel.
On connaît déjà certaines solutions partielles au problème de l'enregistrement et de la répétition des configurations d'ordinateurs, soit par le choix des matériels, soit par des outils logiciels.
Parmi les solutions matérielles, on peut citer l'ordinateur portable, qui répond au besoin de transport d'une configuration, mais non à celui de sa répétition. Il présente de plus les inconvénients connus d'un coût relativement élevé et d'une ergonomie limitée. L'ordinateur de réseau ("Network computer") apporte quant à lui une standardisation par nature à l'intérieur du réseau, la configuration du système et des logiciels étant centralisée dans le serveur principal. Mais on sait les limites de débit des réseaux, peu utilisables par exemple pour l'animation d'objets graphiques complexes.
De nombreux logiciels présents sur le marché apportent par ailleurs des facilités partielles pour la sauvegarde et la reproduction des configurations des utilisateurs.
Une première famille de logiciels [réf : "Webshot", "Stardock"] ne font que faciliter la personnalisation de l'ordinateur, seulement au niveau de la configuration du fond d'écran.
Dans une seconde catégorie, on trouve les logiciels qui permettent de créer et sauvegarder localement les seuls paramètres d'ergonomie du bureau [réf : "Desktop Architect"]. Un autre groupe de logiciels propose le déploiement vers l'ensemble des ordinateurs d'un même parc d'une seule configuration du système [réf : "RapidDeploy"].
On trouve encore des logiciels [réf : "User Roaming Profile"] dont la fonction est de reporter le profil de configuration des utilisateurs sur un serveur local. Une telle solution ne gère pas le cas d'un parc d'ordinateurs non homogène, ni celui d'un changement de système d'exploitation ou d'une réinstallation.
D'autres solutions proposent la sauvegarde des fichiers sur un site Internet [réf : "Visto.com"]. Dans cette approche, de même que pour les logiciels précédemment évoqués, il est clair que la configuration du système elle-même n'est pas sauvegardée et ne peut donc être restaurée.
Un autre type de services proposé sur Internet fait appel à la procédure dénommée "Application Service Provider" (ASP) dans laquelle les logiciels d'application sont déportés sur le site serveur [réf : "webos.com"]. Dans cette solution, la configuration des logiciels déportés est bien standardisée pour l'ensemble des utilisateurs, mais les possibilités de personnalisation sont très limitées.
On peut enfin citer les logiciels spécialisés dans la sauvegarde sur Internet de la configuration complète d'un seul outil ou ensemble d'outils logiciel, "Office 2000" par exemple [réf : "Save My Settings Wizard"]. Ce service ne concerne évidemment pas la configuration du système ni celle des autres logiciels.
La présente invention a donc pour but de supprimer ces inconvénients et limitations, et d'offrir un moyen général de sauvegarde et de restauration de l'ensemble des paramètres de configuration d'une plateforme informatique et des préférences de l'utilisateur, aussi bien au niveau du système d'exploitation que des logiciels spécialisés, 'avec la propriété essentielle de permettre la récupération de cette configuration sur un système ou des logiciels différents de ceux à partir desquels a été effectuée la sauvegarde.
Elle propose, à cet effet, un procédé de sauvegarde et de restauration de la configuration d'une plateforme informatique telle que, par exemple, un ordinateur, par connexion sur un serveur par exemple un serveur Internet/Intranet, ce procédé comportant une phase de sauvegarde comprenant :
- la demande de sauvegarde de la plateforme sur un serveur,
- l'acceptation de la demande par le serveur et la transmission par le serveur à la plateforme de données pour analyser la plateforme,
- l'analyse interne de la plateforme à partir des données transmises par le serveur et la transmission au serveur des résultats de l'analyse, - la préparation par le serveur des données pour sauvegarder la configuration de la plateforme et la transmission à la plateforme des données pour sauvegarder la configuration de la plateforme,
- la sauvegarde par la plateforme des données de configuration de la plateforme et la transmission de ces données au serveur, - la conversion des données de configuration de la plateforme puis la sauvegarde par le serveur de ces données.
Ce procédé pourra en outre comprendre une phase de restauration des données de configuration sauvegardées par le site serveur sur la plateforme demandeur éventuellement distinct de la susdite plateforme, cette phase de restauration comprenant les étapes suivantes :
- la demande de restauration émise par la plateforme demandeur à destination du serveur, T l'acceptation de la demande par le site serveur et la transmission par celui- ci à la plateforme demandeur, de données d'analyse, - l'analyse interne de la plateforme à l'aide des données d'analyse et la transmission par la plateforme au serveur des résultats de l'analyse,
- la conversion par le serveur, en fonction de ces résultats, des données pour la restauration de la configuration de la plateforme et la transmission par le serveur de ces données à la plateforme,
- la restauration de la configuration sur la plateforme.
Avantageusement, l'application de sauvegarde et de restauration des configurations pourra être proposée aux utilisateurs sous la forme d'une procédure ASP sur Internet ou sur Intranet (définie précédemment). Un tel choix présente les avantages suivants :
- suppression des opérations d'installation et de déploiement dans le cas de sites à plusieurs plateformes, puisqu'il n'y a pas de logiciel spécifique à mettre en place sur la machine de l'utilisateur ; - absence d'incompatibilité avec les logiciels déjà installés et absence de problèmes de puissance ou de capacité, l'application objet de l'invention étant exécutée sur le site serveur ;
- mises à jour centralisées de l'application, nécessaires lors de l'apparition de nouvelles versions de logiciels sur le marché, sans aucune intervention de l'utilisateur ;
- suppression des risques de copiage de l'application ;
- économie pour le fournisseur de l'ASP des coûts de distribution et de support à l'installation.
Dans cette solution, le procédé selon l'invention comprend au moins, de façon générale, les sous-ensembles suivants, qui sont donc tous installés sur le site du serveur :
- une Base de Données, préférentiellement sur le modèle relationnel, dont les différentes parties sont : - une Base Applicative, contenant les données nécessaires au bon fonctionnement de l'application, - une Base Grand Public, relative aux informations sur les utilisateurs de l'application,
- une Base Entreprise, fournissant les informations commerciales liées à son utilisation ; (Les deux bases de données Grand Public et Entreprise gèrent les configurations des utilisateurs, la Base Entreprise ayant un complément pour l'administration des configurations des employés des entreprises) ;
- un Interface (serveur Web utilisant le protocole HTTP), gérant les interactions entre les différents sous-ensembles de l'application ; - un Serveur Applicatif, assurant l'ensemble des fonctions de connexion des utilisateurs, de sauvegarde et de restauration des configurations ;
- une Appliquette ou applet (petit programme intégré dans une page HTML et qui accomplit une fonction), préférentiellement programmée en langage JAVA, téléchargée sur l' ordinateur de l'utilisateur lors de la connexion, qui sera dénommée AP par commodité dans la suite de la description.
Le Serveur Applicatif et l'Appliquette utilisent un modèle arborescent, dans lequel chaque arbre est défini par une racine et peut contenir une liste d'arbres dépendants. A l'intérieur de chaque arbre, les données sont organisées en chaîne, un système de pointeurs permettant d'accéder à l'élément contenu dans un maillon de la chaîne, ou bien de se déplacer vers le maillon suivant ou le maillon précédent. Des fonctions associées permettent d'insérer ou de détruire des arbres ou des éléments.
Le fonctionnement du Serveur Applicatif met en œuvre une "socket" (canal) d'écoute qui reste en attente d'une demande de connexion. Il reçoit une requête du Serveur qui a précédemment identifié l'utilisateur (en vérifiant son mot de passe) et associe alors à cet utilisateur une de ses "sockets". Le processus de "Login" sur le serveur Web a en effet initialisé un Objet Utilisateur. Celui-ci effectue étape par étape le traitement demandé par la requête. Cet Objet est mis en action grâce à un ensemble d'Unités d'exécution ("threads") associées à la "socket".
Ces Unités d'exécution sont normalement en sommeil et remis à l'état actif par les réponses aux opérations de lecture ou d'écriture demandés par l'Objet Utilisateur. Ils transmettent alors à celui-ci l'ordre de poursuivre le traitement jusqu'à obtention du résultat demandé. Des dispositifs de vérification des dépassements des durées limitées permettent d'éliminer les connexions qui n'ont pas abouti.
Préférentiellement, les données seront cryptées en RSA.
La partie non cryptée des requêtes (données) sera masquée.
Le fonctionnement détaillé de l'Objet Utilisateur fait appel aux concepts généraux suivants :
- un Module comprend l'ensemble des paramètres d'un système d'exploitation ou d'un logiciel spécialisé donné ; durant la phase préparatoire d'une procédure de sauvegarde ou de restauration, avant de recevoir les valeurs des paramètres concernés ;
- un Pré-module est un ensemble de données niinimales caractérisant le Module ;
- un Paquet regroupe l'ensemble des Modules d'une même famille de logiciels (Traitement de Texte par exemple) ; - une Configuration est l'ensemble des Paquets pour un utilisateur.
Dans le cas de la Sauvegarde, le mécanisme de fonctionnement de l'Objet Utilisateur selon l'invention comprend au moins les étapes suivantes :
- Connexion
* récupération de la requête en provenance de l'AP * récupération dans la Base des Paquets concernés et de l'Outil d'analyse
* génération de l'Outil d'analyse
* envoi de l'Outil d'analyse vers l'utilisateur par l'intermédiaire de l'AP
- Analyse
* récupération de l'Outil d'analyse renvoyé par l'AP
* si l'Outil d'analyse indique la présence de deux Modules au moins appartenant au même Paquet : - génération du Choix de Modules(dont le rôle est la récupération des noms de Modules) - envoi du Choix de Modules vers l'AP
* récupération dans la Base des Pré-modules correspondants avec les moyens de conversion associés * envoi de ces Pré-modules vers l'AP
- Traitement
* récupération d'un Pré-module à partir de l'AP
* envoi d'un acquittement de cette réception vers l'AP ** si tous les Modules ont été traités, passage à l'étape d'Envoi
* génération du Module traité
* reprise au début du Traitement
- Envoi * récupération d'une demande de Module venant de l'AP
* envoi vers l'AP de tous les Modules en attente
- Réception
* récupération d'un Module en provenance de l'AP * acquittement de cette réception
* utilisation des moyens de conversion pour reformer un Paquet * envoi du Paquet reconstitué à la Base
* reprise au début de la Réception jusqu'à ce que tous les Modules soient reçus
- Fin de la procédure
Un mécanisme similaire, selon l'invention, est mis en œuvre pour la Restauration. Il comporte au moins les phases suivantes :
- Connexion
* récupération de la requête en provenance de l'AP
* récupération dans la Base des Paquets concernés et de l'Outil d'analyse
* génération de l'Outil d'analyse * envoi de l'Outil d'analyse vers l'utilisateur par l'intermédiaire de l'AP
- Analyse
* récupération de l'Outil d'analyse renvoyé par l'AP
* récupération dans la Base des Pré-modules correspondants avec les moyens de conversion associés
* envoi de ces Pré-modules vers l'AP
- Traitement
* récupération d'un Pré-module à partir de l'AP * envoi d'un acquittement de cette réception vers l'AP
* si tous les Modules ont été traités, passage à l'étape d'Envoi
* génération du Module traité
* reprise au début du Traitement
- Envoi
* récupération d'une demande de Module venant de l'AP * envoi vers l'AP de tous les Modules en attente
- Fin de la procédure
Dans tous les transferts entre l'Utilisateur, le Serveur et la Base de données des informations nécessaires à la mise en œuvre de l'invention, il est avantageux d'utiliser une méthode de sérialisation des différents objets, de façon à obtenir un flux de données aisément transmissible.
Dans cette approche, chaque objet transmis est représenté par une suite d'octets formatée, qui comporte successivement :
- un octet de début,
- un identifiant de classe, qui définit la classe laquelle appartient l'objet,
- la zone des données proprement dite, - un octet de fin.
Les octets de début et de fin sont des redondances destinées à assurer l'intégrité des données.
Les différentes classes d'objets peuvent être, de façon non exhaustive :
- arbre,
- arbre principal,
- racine principale,
- racine principale avec identifiant, - racine de paramètre absolu,
- racine de paramètre de l'utilisateur,
- racine de commande (dont le contenu correspond à des ordres à exécuter),
- racine d'identifiant,
- racine d'identifiant avec valeur, - racine externe,
- racine d'action pour le Serveur, - racine d'action pour l'Utilisateur.
La longueur et le format de la chaîne de données contenue dans l'objet sérialisé dépendent bien entendu de la classe à laquelle appartient l'objet.
Après transmission, chaque objet est dé-sérialisé avant d'être utilisé, la lecture de l'identifiant de classe permettant l'interprétation de la zone des données.
Selon l'invention, les échanges de données entre l'AP, qui assure la fonction d'interface avec l'Utilisateur, et le Serveur Applicatif, qui effectue les traitements demandés, seront préférentiellement réalisés en intégrant le flux de données dans un protocole HTTP. Ce choix présente entre autres l'avantage de permettre le franchissement des murs « coupe-feu » éventuellement installés sur le site du Serveur.
Dans cette optique, les échanges entre l'AP et le Serveur prendront essentiellement la forme d'envois de requêtes par l'AP, auxquelles répondent des actions exécutées par le Serveur, qui en retourne les données résultantes.
Les requêtes émises par l'AP répondront avantageusement à un format composé de quatre blocs :
- l'en-tête HTTP, qui peut présenter une forme adaptée au format des blocs suivants ;
- l'identifiant de l'utilisateur, crypté selon l'algorithme évoqué plus haut et qui comprend lui-même quatre parties :
- l'identifiant de la clé à utiliser pour décrypter l'identité,
- l'indication de la dimension de la partie cryptée,
- l'identifiant proprement dit de l'utilisateur,
- le nombre d'itérations, qui détermine le numéro des connexions simultanées pour un même utilisateur ; - l'en-tête de requête, qui contient l'indication du type (normal ou requête d'erreur) et de la nature de la requête ;
- les données nécessaires pour effectuer la requête.
La réponse du Serveur à une requête pourra comprendre de façon similaire :
- l'en-tête HTTP ;
- l'en-tête de réponse, qui contient l'indication du type (normal ou cas d'erreur) et de la nature de la réponse ;
- les données de la réponse.
A ce dialogue pourra avantageusement être associée la gestion d'un nombre maximal d'erreurs, au-delà duquel la réponse du Serveur signale une prochaine déconnexion.
Le protocole de communication entre le Serveur Web et le Serveur Applicatif comprendra au moins des requêtes de connexion émises par le Serveur Web, qui ne nécessitent pas de cryptage, et leur réponse par le Serveur Applicatif.
Le Serveur Web lui-même a pour fonction de recevoir la demande de connexion de l'utilisateur, avec son mot de passe. Après validation, une procédure Script (fichier de texte contenant un ensemble d'instructions destinées à être exécutées par un interpréteur de script, cette procédure faisant appel à une bibliothèque de fonction dynamique DAL) est exécutée, qui permet de : - authentifier l'utilisateur grâce au Serveur Applicatif,
- lire dans la Base les données le concernant,
- afficher ces informations sous forme arborescente, proposer à l'utilisateur une sélection dans cette arborescence et le choix de la fonction à exécuter (Sauvegarde ou Restauration). L'AP effectue une demande, les paramètres correspondants sont alors transmis à l'AP, qui effectue son traitement et gère ses échanges de données avec le Serveur Applicatif de façon autonome, seul l'état d'avancement du traitement étant visible pour l'utilisateur.
L'AP elle-même a pour fonction de sauvegarder ou de restaurer des Modules sur le poste de l'utilisateur. Pour ce faire, son exécution est pilotée par deux Unités d'exécution (threads) : le principal assure le traitement des données, l'autre la connexion avec le Serveur.
Le processus d'exécution principal, compte-tenu du fonctionnement selon l'invention de l'Objet Utilisateur décrit précédemment, comportera au moins dans le cas de la Sauvegarde les étapes suivantes :
- génération et envoi au Serveur des options choisies par l'utilisateur ; - réception des Outils d'analyse ;
- analyse de la plateforme et renvoi des Outils d'analyse ;
- en cas de présence de plusieurs Modules dans un même Paquet, réception du Choix de Modules, acquisition des choix de l'utilisateur et renvoi au Serveur ; - réception des Pré-modules ;
- Module par Module, lecture des paramètres actuels et renvoi au Serveur du Module évalué ;
- lorsque tous les Modules sont renvoyés, requête auprès du Serveur pour s'assurer que la procédure s'est correctement terminée.
Lors d'une Restauration, le déroulement du processus sera le suivant :
- génération et envoi au Serveur des options choisies par l'utilisateur ;
- réception des Outils d'analyse ;
- lecture des paramètres actuels et renvoi des Outils d'analyse ; - réception des Pré-modules ; - Module par Module, lecture des paramètres actuels, renvoi au Serveur du Module valorisé, réception du Module à restaurer et restauration ;
- signalisation de fin de tâche au Serveur et acquittement.
Les fonctionnalités proposées à l'utilisateur sur le site Web pourront comprendre, de façon non limitative, à partir d'une page d'accueil :
- les fonctions d'identification et d'enregistrement de l'utilisateur, qui peut donc, après avoir indiqué ses coordonnées personnelles, ouvrir un compte sur le site ;
- l'accès aux Configurations déjà enregistrées dans le compte de l'utilisateur, sur lesquelles les manipulations possibles comprendront au moins :
- la sauvegarde de la Configuration actuelle, - la restauration d'une Configuration sélectionnée,
- la suppression d'une Configuration,
- le partage d'une Configuration avec un ou plusieurs autres internautes,
- le changement de nom d'une Configuration,
- l'envoi d'une Configuration vers une Communauté, dont les fonctionnalités sont décrites plus loin ;
- les mêmes possibilités de manipulation au niveau d'un seul Paquet, seule la possibilité de renommer un Paquet étant exclue ;
- la possibilité d'annuler la dernière restauration effectuée, et donc de rétablir la Configuration initiale ;
- la constitution d'une Communauté de Configurations, au sein de laquelle l'utilisateur peut au moins : - restaurer sur son poste une Configuration de la Communauté, - se constituer un « Panier » de Configurations préférentielles, qui peuvent être restaurées sur son poste,
- sauvegarder une Configuration de la Communauté vers son compte,
- ajouter ou supprimer un partage avec un ou plusieurs autres internautes de son choix ;
- toutes les aides et explications nécessaires à l'emploi du procédé objet de l'invention, ainsi qu'à la création et la mise à jour des Configurations.
Le procédé selon l'invention est illustré par les dessins annexés dans lesquels :
La figure 1 donne l'architecture générale du procédé suivant l'invention ;
La figure 2 est le schéma fonctionnel d'une procédure de Sauvegarde ;
La figure 3 est le schéma fonctionnel d'une procédure de Restauration ;
La figure 4 donne le principe de fonctionnement de l'Objet Utilisateur ;
La figure 5 représente le diagramme d'états de l'Objet Utilisateur au cours d'une sauvegarde ;
La figure 6 représente le même diagramme dans le cas de la restauration ;
La figure 7 illustre le format général d'un objet sérialisé ;
La figure 8 donne le format des requêtes adressées par l'AP au serveur ; La figure 9 indique le format des réponses aux requêtes retournées par le serveur.
Sur la figure 1 sont représentés les principaux sous-ensembles formant rarchitecture générale du procédé selon l'invention : la Base de Données 1 communique à travers l'Interface 2 avec le Serveur Web 3 et le Serveur Applicatif 4. Le Serveur Web 3 et le Serveur Applicatif 4 échange des informations avec l'Appliquette (AP) 5 téléchargée sur la plateforme, ici l'ordinateur de l'utilisateur.
Le schéma fonctionnel de la figure 2 représente la circulation des Pré-modules et des Modules de configuration entre la Base de Données, le Serveur et l'Utilisateur au cours d'une procédure de Sauvegarde : les Pré-modules sont transmis à l'AP sur le poste de l'utilisateur, où s'opère le choix des Modules à sauvegarder ; les Pré-modules sélectionnés sont renvoyés au Serveur qui constitue le bloc des données des Modules à sauvegarder avant de les retourner à l'AP où sont intégrés aux Modules les paramètres de configuration actuels ; les Modules sont enfin adressés à nouveau au Serveur, qui effectue les opérations de reconversion nécessaires à la reconstitution des Paquets concernés, avant de replacer ceux-ci dans la Base de Données ; à chaque mouvement d'un Pré-module ou d'un Module, les données correspondantes sont sérialisées au départ et dé-sérialisées à l'arrivée.
De façon similaire, est représenté sur le schéma fonctionnel de la figure 3 le traitement des Pré-modules et des Modules lors d'une procédure de Restauration : les Pré-modules sont extraits de la Base de Données et transmis à l'AP où s'opère la sélection ; les Pré-modules concernés sont retournés au Serveur, qui effectue les conversions nécessaires pour reformer le Paquet à restaurer avec les paramètres extraits de la Base de Données, avant de renvoyer ce Paquet à l'AP, qui procède à la restauration. La figure 4 illustre le fonctionnement de l'Objet Utilisateur sur le Serveur sous l'action des Unités d'exécution : à chaque fois que l'Objet Utilisateur 6 demande une opération d'entrée (lecture) ou de sortie (écriture) de données au port 7 correspondant à la socket d'entrée/sortie, le retour de l'acquittement de cette opération par le port est détecté par l'une des Unités d'exécution 8 en sommeil, qui entre alors en action pour donner à l'Objet Utilisateur l'ordre de poursuivre le traitement, et ainsi de suite jusqu'à l'achèvement de la procédure.
Sur la diagramme d'états de la figure 5 sont représentés les états successifs de l'Objet Utilisateur lors d'une procédure de Sauvegarde :
- l'état ESO (Connexion) dure jusqu'à l'envoi des Outils d'analyse ;
- l'état ESI (Analyse) qui suit se maintient jusqu'à l'envoi des Pré-modules ;
- dans le cas où un choix de Modules est nécessaire, l'état ESI prend fin avec l'envoi des Choix de Modules et laisse la place à un état intermédiaire
ES l' jusqu'à l'envoi des Pré-modules ;
- l'état suivant ES2 (Traitement) se termine lorsque le dernier Module a été traité et la procédure s'achève avec l'état ES3 (Fin).
Lors d'une procédure de Restauration, les états successifs de l'Objet Utilisateur apparaissent sur la figure 6 : les états ERO (Connexion), ER1 (Analyse) et ER2 (Traitement) sont similaires aux états ESO, ESI et ES2 respectivement dans le cas de la Sauvegarde ; l'état suivant ER3 (Envoi des Modules) se maintient jusqu'à la transmission du dernier Module, avant de laisser la place à l'état ER4 (Fin).
La figure 7 représente le format général des objets sérialisés transmis entre le Serveur et l'AP. Chaque objet est formé successivement de :
- un octet de début OD, - l'identifiant de la classe à laquelle appartient l'obj et IC,
- les données de l'objet, dont le format et la longueur dépendent de la classe, - un octet de fin OF.
La figure 8 montre le format des requêtes adressées par l'AP au Serveur. Ce format comprend successivement : - l'en-tête HTTP ;
- l'identifiant de l'utilisateur IU, crypté selon l'algorithme RSA et qui comporte lui-même quatre parties : l'identifiant de la clé à utiliser pour le décryptage IDC, la taille totale de la zone cryptée, l'identifiant de l'utilisateur lui-même IDU et le nombre d'itérations NBI ; - l'en-tête de requête ETR, qui comporte deux parties : le type TR (normal ou erreur) et la nature de la requête NR ;
- les données nécessaires au traitement de la requête.
Enfin la figure 9 donne le format de la réponse du Serveur à une requête, qui comprend :
- l'en-tête HTTP ;
- l'en-tête de réponse, dont le format est identique à celui de l'en-tête de requête ;
- les données de la réponse.

Claims

REVENDICATIONS
1. Procédé pour la sauvegarde et la restauration de la configuration d'une plateforme informatique par connexion sur un site Internet ou Intranet, ce procédé ne nécessitant aucune installation préalable sur la plateforme concernée d'un logiciel spécialisé dans ces tâches de sauvegarde ou de restauration, caractérisé en ce qu'il comprend une phase de sauvegarde comportant les phases opératoires suivantes :
- la demande de sauvegarde de la plateforme sur un site serveur Internet ou Intranet,
- l'acceptation de la demande par le serveur et la transmission par le serveur à la plateforme de données pour analyser la plateforme, - l'analyse interne de la plateforme à partir des données transmises par le serveur et la transmission au serveur des résultats de l'analyse,
- la préparation par le serveur des données pour sauvegarder la configuration du poste et la transmission à la plateforme des données pour sauvegarder la configuration de la plateforme, - la sauvegarde par la plateforme des données de configuration de la plateforme et la transmission de ces données au serveur,
- la conversion des données de configuration de la plateforme puis la sauvegarde par le serveur de ces données.
2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une phase de restauration des données de configuration sauvegardées par le site serveur sur la plateforme demandeur éventuellement distinct de la susdite plateforme, cette phase de restauration comprenant les étapes suivantes : - la demande de restauration émise par la plateforme demandeur à destination du serveur,
- l'acceptation de la demande par le site serveur et la transmission par celui- ci à la plateforme demandeur, de données d'analyse, - l'analyse interne de la plateforme à l'aide des données d'analyse et la transmission par la plateforme au serveur des résultats de l'analyse,
- la conversion par le serveur, en fonction de ces résultats, des données pour la restauration de la configuration de la plateforme et la transmission par le serveur de ces données à la plateforme, - la restauration de la configuration sur la plateforme.
3. Procédé selon la revendication 1, caractérisé en ce qu'il comporte au moins les sous-ensembles suivants installés sur le site du serveur : - une Base de données, renfermant les configurations sauvegardées et les autres données nécessaires au fonctionnement de l'application ;
- un Interface, assurant les liaisons entre les différents sous-ensembles ;
- un Serveur Applicatif, qui pilote l'ensemble des opérations de sauvegarde et de restauration des configurations ; - un Serveur Web, gérant la connexion des utilisateurs et l'interface Utilisateur ;
- un programme, téléchargé sur la plateforme de l'utilisateur et réalisant les traitements internes d'acquisition ou de mise en place des paramètres de configuration.
4. Procédé selon l'une des revendications précédentes, caractérisé en ce que la configuration sauvegardée ou restaurée comprend la configuration du système d'exploitation utilisé par la plateforme et/ou la configuration des logiciels spécialisés installés sur cette plateforme.
5. Procédé selon la revendication 4, caractérisé en ce que les susdits logiciels spécialisés consistent en des Traitements de texte, des Tableurs, des Navigateurs Internet ou des Gestionnaires de courrier électronique.
6. Procédé selon la revendication 4, caractérisé en ce que, si l'on désigne par Module l'ensemble des paramètres d'un logiciel donné, les Modules d'une même famille de logiciels spécialisés et les Modules concernant les systèmes d'exploitation sont regroupés dans un Paquet affecté à cette famille, ce qui permet, grâce à une analyse préalable, de restaurer la configuration d'un logiciel sauvegardée à partir d'un autre logiciel de la même famille.
7. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'une opération de sauvegarde préalable locale est effectuée préalablement à une opération de restauration, permettant ainsi d'annuler l'opération de restauration et de rétablir la configuration originale.
8. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que toutes les informations circulant entre la platefoπne utilisateur et le serveur sont codées dans un format sérialisé, de manière à pouvoir les transmettre à l'aide de protocoles standards.
9. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comprend des facilités d'ajout, de suppression, de modification, de partage, et/ou de mise en communauté des configurations sauvegardées.
PCT/FR2002/000953 2001-03-21 2002-03-19 Procede de sauvegarde et de restauration de l'ensemble des parametres de configuration d'une plateforme informatique par l'intermediaire d'un serveur WO2002075546A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002255064A AU2002255064A1 (en) 2001-03-21 2002-03-19 Method for saving and restoring all configuration parameters for a computer platform by means of a server

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0104047A FR2822563A1 (fr) 2001-03-21 2001-03-21 Procede de sauvegarde et de restauration de l'ensemble des parametres de configuration d'une plateforme informatique par l'intermediaire d'un serveur
FR01/04047 2001-03-21

Publications (2)

Publication Number Publication Date
WO2002075546A2 true WO2002075546A2 (fr) 2002-09-26
WO2002075546A3 WO2002075546A3 (fr) 2003-04-10

Family

ID=8861541

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/000953 WO2002075546A2 (fr) 2001-03-21 2002-03-19 Procede de sauvegarde et de restauration de l'ensemble des parametres de configuration d'une plateforme informatique par l'intermediaire d'un serveur

Country Status (3)

Country Link
AU (1) AU2002255064A1 (fr)
FR (1) FR2822563A1 (fr)
WO (1) WO2002075546A2 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995013580A1 (fr) * 1993-11-09 1995-05-18 Arcada Software Systeme de sauvegarde et de restauration de donnees pour reseau informatique
EP0910019A2 (fr) * 1997-10-14 1999-04-21 International Computers Limited Système de sauvegarde à distance
US6108712A (en) * 1998-05-05 2000-08-22 International Business Machines Corp. Client-server system with central application management and providing export agent capability for retrofitting existing hardware and applications into the system
WO2000070445A2 (fr) * 1999-05-14 2000-11-23 Eisenworld International Appareil et procede de transfert d'informations entre des plates-formes
WO2000077585A1 (fr) * 1999-06-11 2000-12-21 Invensys Systems, Inc. Hebergement d'egal a egal de dispositifs intelligents sur site

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995013580A1 (fr) * 1993-11-09 1995-05-18 Arcada Software Systeme de sauvegarde et de restauration de donnees pour reseau informatique
EP0910019A2 (fr) * 1997-10-14 1999-04-21 International Computers Limited Système de sauvegarde à distance
US6108712A (en) * 1998-05-05 2000-08-22 International Business Machines Corp. Client-server system with central application management and providing export agent capability for retrofitting existing hardware and applications into the system
WO2000070445A2 (fr) * 1999-05-14 2000-11-23 Eisenworld International Appareil et procede de transfert d'informations entre des plates-formes
WO2000077585A1 (fr) * 1999-06-11 2000-12-21 Invensys Systems, Inc. Hebergement d'egal a egal de dispositifs intelligents sur site

Also Published As

Publication number Publication date
FR2822563A1 (fr) 2002-09-27
AU2002255064A1 (en) 2002-10-03
WO2002075546A3 (fr) 2003-04-10

Similar Documents

Publication Publication Date Title
FR2791159A1 (fr) Procede d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede
FR2805108A1 (fr) Procede d'enregistrement d'un usager sur un serveur d'annuaire d'un reseau de type internet et/ou de localisation d'un usager sur ce reseau, et carte a puce pour la mise en oeuvre du procede
EP1208684A2 (fr) Procede de transmission de flux de donnees a haut debit sur un reseau de type internet entre un serveur et un terminal a carte a puce
FR2800540A1 (fr) Terminal securise muni d'un lecteur de carte a puce destine a communiquer avec un serveur via un reseau de type internet
FR2816421A1 (fr) Gestion coordonnee de contrats et services, notamment de telecommunication
FR2844370A1 (fr) Document electronique de description d'un service informatique
CA2564108A1 (fr) Systeme et procede de tracabilite de contenus sur internet
JP2005011098A (ja) 代理認証プログラム、代理認証方法、および代理認証装置
EP1303812A2 (fr) Procede de transmission d'un agent mobile dans un reseau; emetteur, recepteur, et agent mobile associes
FR2812422A1 (fr) Preparation et remise securisees de rapports de donnees
EP1357724B1 (fr) Dispositif de gestion de filtres de données
WO2002080024A1 (fr) Dispositif et procede d'echange de flux entre un dispositif client et un serveur
WO2002075546A2 (fr) Procede de sauvegarde et de restauration de l'ensemble des parametres de configuration d'une plateforme informatique par l'intermediaire d'un serveur
EP1610519A1 (fr) Procédé de médiation entre applications de services web, et plate-forme de médiation pour la mise en oeuvre du procédé
EP1309124A1 (fr) Passerelle CIM pour la supervision et le contrôle de réseaux de télécommunication
WO2004056071A1 (fr) Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre
EP1394983B1 (fr) Dispositif de gestion automatique d'équipements de réseau
WO2004104877A1 (fr) Systeme de reseau informatique securise pour la gestion de donnees personnelles
EP0969347B1 (fr) Procédé d'authentification pour accès protégés dans un système informatique en réseau
WO2002089446A2 (fr) Dispositif et procede de traitement de donnees, et serveur comportant ce dispositif
FR2852177A1 (fr) Procede de proposition d'un service fourni par un ordinateur serveur dans un reseau de communication
WO2004057825A2 (fr) Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre
WO2003069475A2 (fr) Programme complementaire api pour traitement de transaction dans un reseau modulaire
FR2844414A1 (fr) Procede de proposition d'un service et procede d'analyse d'un document de description d'un tel service.
WO2005031620A2 (fr) Procede d’enquete electronique

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP