WO2001038977A1 - Procede de creation de fichiers de configuration d'objets inclus dans un systeme informatique - Google Patents

Procede de creation de fichiers de configuration d'objets inclus dans un systeme informatique Download PDF

Info

Publication number
WO2001038977A1
WO2001038977A1 PCT/FR2000/003231 FR0003231W WO0138977A1 WO 2001038977 A1 WO2001038977 A1 WO 2001038977A1 FR 0003231 W FR0003231 W FR 0003231W WO 0138977 A1 WO0138977 A1 WO 0138977A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
parameters
file
configuration file
description
Prior art date
Application number
PCT/FR2000/003231
Other languages
English (en)
Inventor
Pierre Andrei
Hoan Bui-Xuan
Original Assignee
Evidian
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 Evidian filed Critical Evidian
Publication of WO2001038977A1 publication Critical patent/WO2001038977A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files

Definitions

  • the present invention relates to a method for creating configuration files of objects belonging to a computer system.
  • the computer system includes hardware objects (machines, ...), and / or software objects (applications, ). This system is indifferently a distributed system or not, heterogeneous or not.
  • Objects include parameters included in a configuration file.
  • the invention applies to any configuration file written in an extensible markup language, that is to say a language which presents information framed by tags.
  • the configuration file is written using a description metalanguage whose format is independent of the hardware and / or software to be configured.
  • a metalanguage is generally defined as being a language used to describe another language.
  • the XML markup language Extensible Markup Language
  • W3C consortium World Wide Web Consortium
  • This consortium is an organization promoting the "World Wide Web", which develops open and free standards and protocols, with a view to maximum interoperability.
  • the XML configuration file has a structure declared in a description file.
  • This description file includes the description of the configuration parameters of an object and is generally called Document Type Definition (DTD). This definition takes place according to a particular formalism also defined in the XML specification of the W3C consortium.
  • DTD Document Type Definition
  • XML must obey certain syntactic constraints. Indeed, an XML document has a logical structure. It consists of descriptions, elements, comments, character calls, and processing instructions, which are indicated in the document through explicit markup.
  • the elements are surrounded by opening tags, for example ⁇ preface>, and closing tags, for example ⁇ / preface>.
  • the parameters of the objects are defined in a configuration file written in an XML language as defined above.
  • the main problem is that there are thousands of objects to configure and that several of these objects can rely on the same DTD description file and have identical values for all or part of their parameters.
  • the administrator of the management system To build the configuration file, the administrator of the management system must then value the parameters described in the description file as many times as there are objects relying on this DTD file. More precisely, suppose that two objects B1 and B2 are based on the same description file (DTD). To configure the B1 object, the user must value all the parameters described in the DTD file. To configure the object
  • the configuration file has a large volume, the data flow between the management system and the client application can be very important and lead to saturate the communication system between the client applications and the management system.
  • a first aim of the solution is therefore to considerably simplify the writing of configuration files, thereby reducing both the cost in writing time thereof and the risk of writing errors.
  • the object of the solution is a method for creating at least one configuration file for hardware and / or software objects present in a computer system, said configuration file being written using a description metalanguage whose format is independent of the hardware and / or software to be configured, this configuration file including all or part of the parameters of said objects and based on a description file defining constraints to be observed on the structure and syntax when writing said configuration file, characterized in that it consists in extending the description file by at least one model comprising at least one parameter described in the description file, and in that it consists in valuing all or part of the parameters of this model.
  • configuration file of hardware and / or software objects present in a computer system
  • said configuration file being written using a description metalanguage whose format is independent of the hardware and / or software to be configured, this file configuration including all or part of the parameters of said objects and relying on a description file defining constraints to be respected on the structure and syntax when writing said configuration file, characterized in that the description file is extended, in that the extension comprises at least one model including at least one parameter included in the description file, and in that part of the parameters of this model are valued.
  • FIG. 1 is a synoptic view of the architecture of a computer system on which the solution can be applied
  • FIG. 1 is a view of a model according to the present solution.
  • this system SYS includes a management system SG and at least one machine M1.
  • the management system SG comprises at least one operating system, at least one information storage memory and at least one processor controlling the process of processing the information.
  • the term management is used to conform to the Afnor (French Association for NORmalisation) translation of "Management”.
  • a machine management system of the "Open Master” type (trademark registered by the company BULL SA), known to those skilled in the art, is particularly well suited for the implementation of the solution.
  • This management system can be assimilated to a set of services which interact with each other to give an object representation of the real world constituted in particular by the machines of the computer system. It is an object representation that an administrator manipulates (surveillance, action) to manage the real world.
  • the object representation relates to virtual objects from the real world and constitutes an object model.
  • an object managed by the management system is an abstract view, defined for management purposes, of a logical or physical resource of the computer system, (disk, processor, memory, etc.) and / or logic (files, processes, semaphores, etc.).
  • the management system and the machines it manages constitute a Client / Server architecture.
  • a client application interrogates the management system to find out the state of the objects managed by the management system.
  • Client / Server mode has the advantage of allowing a user called client (or client application) located on a machine, for example by means of a simple microcomputer or a workstation, to entrust a part of its task or its operations to be performed on the server, namely the management system. In this way, the customer has a much greater computing capacity than that of his microcomputer.
  • the computer system can be heterogeneous. In order to mask the heterogeneity of the computer system, the management system SG and the machines managed by the management system include at least one respective agent associated with a management protocol. An agent ensures, among other things, a protocol conversion.
  • the management system is linked to a machine managed via any network.
  • the network can be of the LAN (Local Area Network), WAN (Wide Area Network) type.
  • a set of software layers is interposed between the management system SG and the RES network and between the network and each machine. For reasons of simplification of the description, this set of software layers is not shown in FIG. 1.
  • Each managed object includes parameters defined in a configuration file preferably written in a markup description language comprising a structure and including all or part of the parameters (name, at least one attribute, at least one action, etc.) of the objects. .
  • the configuration file is based on a separate file called description file defining the constraints on the structure and the syntactic constraints of the parameters for writing said configuration file associated with an object of a machine.
  • the configuration file is written in an XML type language
  • the description file is a description file of DTD type, known to those skilled in the art.
  • this XML configuration file and the DTD description file are included in the SG management system.
  • the DTD description file is centralized on the management system so that it can be used by all the machines on the network.
  • the managed objects can be represented by a tree, each node of the tree representing a managed object.
  • An APV viewing application included on the machine M1 can interrogate the configuration file in order to receive the parameters of the configured objects and to view these objects on this machine.
  • the machine M1 is provided with a standard browser called "Internet Explorer", known to those skilled in the art, in which a program in JAVA language is executed to read the configuration file, thus accessing its content and structure, and for transmitting the information read to APV viewing applications.
  • An object includes as parameter at least one attribute and properties.
  • an ID attribute is the identifier of the object, another TYPE attribute designates its type, and another OWNER attribute.
  • an object also includes as parameters:
  • node an element "node” is associated with a node, and elements are subordinate to it and are associated respectively
  • Attributes can be associated with an element.
  • the "node” element comprises three attributes, namely: B an ID attribute designating its identifier, B a TYPE attribute designating its type, B and an attribute designating its owner.
  • a DTD description file defining a tree object can be written in the following way, respecting the specific formalism defined in the XML specification of the W3C consortium:
  • CDATA #REQUIRED means that the attribute in question must be a block of text containing characters.
  • writing "action *" means that the actions have no attributes and that the syntax of these actions to use when writing the configuration file is text.
  • This description file will correspond in the following description to the description file initially created.
  • a description file includes a much larger number of parameters.
  • three objects OBJ1, OBJ2 and OBJ3
  • the main problem is that, to build the configuration file, the administrator of the management system must value the parameters described in the description file as many times as there are objects relying on this DTD file. The administrator must therefore complete the configuration file three times. The time cost of such writing is therefore considerable.
  • the solution consists in extending the description file by at least one model comprising at least one parameter included in the description file, and in that it consists in valuing part of the parameters of this element model.
  • the solution consists in introducing an element model whose writing respect the properties defined in the following description.
  • the objects (OBJ1, OBJ2 and OBJ3) have a respective name (JAZZ, POP, SOL) and a respective identifier (123, 1 2, 162).
  • B the value of the element corresponding to the actions that can be executed is the same for each object (OBJ1, OBJ2 and OBJ3)
  • B the value of the element corresponding to the graphic properties is the same for each object (OBJ1, OBJ2 and OBJ3).
  • the value of the element corresponding to the actions that can be performed on each object is ACT1 for the "open” command, ACT2 for the "close” command, and ACT3 for the command "develop”.
  • the value of the element corresponding to the graphic properties of each object is PRO1 for the font, PRO2 for the icon, and PRO3 for the background color.
  • the two attributes TYPE and OWNER take for each object (OBJ1, OBJ2 and OBJ3) the values "snmp" and "operator", respectively.
  • step 2 the writing of the configuration file resulting from the valuation of the undefined parameters of the element model (step 2).
  • the first step must be carried out while respecting certain properties.
  • the parameters of these objects whose value is invariant being identified, the solution consists in introducing the model of element MODEL in the file of description DTD created.
  • the element model differs from the other elements in the description file in that it includes at least one parameter with a value.
  • the model includes, respecting the formalism of writing a DTD description file defined in the XML specification of the W3C consortium,
  • the MODEL model can be written as follows:
  • ⁇ IMODELE tnoeud ELEMENT node> meaning that the MODEL model has a specific name "tnoeud” and that it is based on the description of the element "node” defined beforehand in the description file (DTD).
  • the writing of undefined elements is particular.
  • the elements to be defined are identified in this model by means of a specific tag whose header is for example ⁇ ! DEFINE ... >.
  • the elements to be defined are identified by a name "tnodeName" and a reference to an element nodeName in the initial description file specifying on which element of the previously defined description file is based on the element model "tnodeName”.
  • an element to be defined can be written as follows:
  • This file constitutes a common FC factor for writing the configuration file and describes the parameters (element and / or attribute) to be defined.
  • Figure 2 is a view of the configuration file that results from the use of the element model.
  • Writing the configuration file corresponds to the second step.
  • This operation consists in using the MODEL element model defined in the DTD description file and in valuing the undefined elements and attributes.
  • the solution consists in using the part comprising the valued parameters as a common factor, and in that the writing is limited to the valuation of the parameters having no value.
  • OBJ1, OBJ2 and OBJ3 having their respective names (JAZZ, POP, SOL) and a respective identifier (123, 142, 162) are to be configured and the configuration file is written for these three objects is limited to writing the following three blocks (B1, B2 and B3):
  • the number of invocation of the element model corresponds to the number of objects based on this MODEL model. These three blocks have the same common factor as the one created in the description file.
  • an element model can contain other element models.
  • an element model reference for example "tnoeud”
  • another element model reference for example "tnoeud”
  • the object of the solution is a method of creating, in a computer system, at least one configuration file of at least one hardware and / or software object comprising parameters, said configuration file being written using a description metalanguage whose format is independent of the hardware and / or software to be configured, this configuration file including all or part of the parameters of said object and relying on a description file defining constraints to be respected on its structure and its syntax when it is written, characterized in that it consists, before writing the configuration file, of extending the description file by at least one model comprising at least one parameter described in the description file, and of valuing all or part of the parameters of this model.
  • the solution consists in using the part of the model comprising the valued parameters as a common factor, and in that the writing of the configuration file is limited to the valuation of the parameters not comprising valuable.
  • the solution can consist first of all in grouping the objects resting on the same description file, then in identifying the parameters whose value is identical between all these objects, and finally e to value these parameters to constitute a common factor in this model.
  • the solution consists, for example, when writing the configuration file, if at least two objects are based on the same model, to use the common factor and to value only the rest of the parameters of this model as many times as it There are objects based on this element model.
  • the solution consists in giving a name to identify the model in the description file, and in that it consists in including in the model a reference of the description file, this reference defining the constraints to be respected on the structure and syntax of this model.
  • the solution consists in introducing into a model two keywords DEFINIR and DEFINI indicating that a parameter is to be defined (DEFINER) or is defined (DEFINI) in this model.
  • the language of the configuration file is XML
  • the solution consisting in taking as parameter an element and / or an attribute of an object.
  • the solution consists in extending the description file by at least one element model comprising at least one parameter (element and / or attribute) described in the description file, and in valuing all or part of the parameters of this element model.
  • the solution consists in giving a name to identify the element model in the description file, and in that it consists in including in the model a reference to an element of the description file, this reference defining the constraints to respect the structure and syntax of this model.
  • the solution can consist in transmitting the common factor and the blocks resulting from the valuation of the undefined elements.
  • a configuration file of at least one hardware and / or software object comprising parameters
  • said configuration file being written using a description metalanguage whose format is independent of the hardware and / or software to be configured, this configuration file including all or part of the parameters of said object and based on a description file defining constraints to be respected on its structure and syntax when it is written, characterized in that the description file is extended, and in that that the extension includes at least one model.
  • a first advantage is the considerable simplification of writing a configuration file. Indeed, the defined parameters being valued in the element model, the writing of the configuration file is limited to the valuation of the undefined parameters. Consequently, the administrator thus avoids repetition identical parameters between objects. The cost of writing time and the risk of writing errors when writing the configuration file is greatly reduced.
  • the introduction of a common factor in the model considerably reduces the size of the configuration file.
  • the management system transmits the configuration file including the common factor of the element model and, for each of the objects, the parameters of this element model which have been valued during the writing the configuration file. The size of the configuration file being reduced, the transfer of this file is therefore faster.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention a pour objet la création d'au moins un fichier de configuration d'au moins un objet matériel et/ou logiciel comprenant des paramètres, ledit fichier de configuration étant écrit en utilisant un métalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ce fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture. L'invention consiste, avant l'écriture du fichier de configuration, à étendre le fichier de description par au moins un modèle comprenant au moins un paramètre décrit dans le fichier de description, et à valoriser tout ou partie des paramètres de ce modèle.

Description

Procédé de création de fichiers de configuration d'objets inclus dans un système informatique.
DESCRIPTION
Domaine technique
La présente invention se rapporte à un procédé de création de fichiers de configuration d'objets appartenant à un système informatique.
Le système informatique comprend des objets matériels (machines, ...), et/ou logiciels (applications, ...). Ce système est indifféremment un système distribué ou non, hétérogène ou non.
Les objets comprennent des paramètres inclus dans un fichier de configuration. L'invention s'applique à tout fichier de configuration écrit dans un langage de balisage extensible, c'est-à-dire un langage qui présente de l'information encadrée par des balises. Le fichier de configuration est écrit en utilisant un metalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer. Un metalangage se défini généralement comme étant un langage utilisé pour décrire un autre langage. Le langage de balisage XML (extensible Markup Langage), connu de l'homme du métier, est bien adapté à la mise en œuvre de la présente solution. Rappelons que la spécification du langage XML est définie par le consortium W3C (World Wide Web Consortium). Ce consortium est un Organisme de promotion du "World Wide Web", qui met au point des normes et des protocoles ouverts et libres, dans un souci d'Interopérabilité maximale. Le fichier de configuration XML a une structure déclarée dans un fichier de description. Ce fichier de description comprend la description des paramètres de configuration d'un objet et se nomme généralement Définition de Type de Document (DTD). Cette définition s'effectue selon un formalisme particulier également défini dans la spécification XML du consortium W3C.
L'art antérieur Par définition, l'écriture d'un fichier de configuration dans un langage
XML doit obéir à certaines contraintes syntaxiques. En effet, un document XML a une structure logique. Il se compose de descriptions, d'éléments, de commentaires, d'appels de caractère et d'instructions de traitement, qui sont indiqués dans le document par l'intermédiaire d'un balisage explicite. Les éléments sont encadrées par de balises ouvrantes, par exemple <préface>, et des balises fermantes, par exemple </préface>. Les éléments sont structurés et décrivent les paramètres des objets. Les paramètres, comme un attribut d'un objet, peuvent être inclus à l'intérieur même des balises. Par exemple, on peut écrire <LIVRE sujet = k> signifiant que l'attribut sujet de l'élément LIVRE a la valeur K.
Dans notre exemple de réalisation, Les paramètres des objets sont définis dans un fichier de configuration écrit dans un langage XML tel que défini précédemment.
Le problème principal est que les objets à configurer se comptent en milliers et que plusieurs de ces objets peuvent se reposer sur un même fichier de description DTD et avoir des valeurs identiques pour tout ou partie de leurs paramètres. Pour construire le fichier de configuration, l'administrateur du système de gestion doit alors valoriser les paramètres décrit dans le fichier de description autant de fois qu'il y a d'objets se reposant sur ce fichier DTD. Plus précisément, supposons que deux objets B1 et B2 se reposent sur un même fichier de description (DTD). Pour configurer l'objet B1 , l'utilisateur doit valoriser tous les paramètres décrit dans le fichier DTD. Pour configurer l'objet
B2, l'utilisateur doit à nouveau valoriser tous les paramètres décrit dans le fichier DTD. En conséquence, les paramètres de même valeur sont écrit autant de fois qu'il y a d'objets se reposant sur un même fichier de description. L'écriture d'un fichier de configuration présente donc des redondances. Le langage XML étant un langage de configuration da bas niveau, un utilisateur est donc contraint d'écrire dans le fichier de configuration des descriptions de paramètres répétitives dont la sémantique est, dans certains cas, sans rapport avec ses besoins, ce qui nécessite une culture importante de sa part de l'ensemble des syntaxes offertes par le langage XML. De ce fait, le fournisseur doit fournir avec le fichier de description une documentation précise. Il est clair qu'un fichier de configuration impose un coût en temps important en écriture.
Un autre problème, lié au nombre important d'objets à décrire, est que si un utilisateur situé sur une machine quelconque du réseau souhaite visualiser des ressources du système informatique configurées dans le fichier de configuration, le système de gestion doit alors transmettre le fichier de configuration à la machine distante par l'intermédiaire du réseau. Lorsque le fichier de configuration a un gros volume, le flux de données entre le système de gestion et l'application cliente peut s'avérer très important et conduire à saturer le système de communication entre les applications clientes et le système de gestion.
Enfin, un autre problème est que la syntaxe définie selon les recommandations du consortium W3C doit être respectée à la lettre tout au long de l'écriture du fichier de configuration. Le risque d'erreur lors de l'écriture d'un fichier de configuration est donc permanent pour un administrateur du système de gestion.
Sommaire de l'invention Un premier but de la solution est donc de simplifier considérablement l'écriture des fichiers de configuration réduisant en conséquence à la fois le coût en temps d'écriture de celui-ci et le risque d'erreurs d'écriture.
Un deuxième but visé est de réduire la taille du fichier de configuration. A cet effet, la solution a pour objet un procédé de création d'au moins un fichier de configuration d'objets matériels et/ou logiciels présents dans un système informatique, ledit fichier de configuration étant écrit en utilisant un metalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ce fichier de configuration incluant tout ou partie des paramètres desdits objets et se reposant sur un fichier de description définissant des contraintes à respecter sur la structure et la syntaxe lors de l'écriture dudit fichier de configuration, caractérisé en ce qu'il consiste à étendre le fichier de description par au moins un modèle comprenant au moins un paramètre décrit dans le fichier de description, et en ce qu'il consiste à valoriser tout ou partie des paramètres de ce modèle. II en résulte également un fichier de configuration d'objets matériels et/ou logiciels présents dans un système informatique, ledit fichier de configuration étant écrit en utilisant un metalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ce fichier de configuration incluant tout ou partie des paramètres desdits objets et se reposant sur un fichier de description définissant des contraintes à respecter sur la structure et la syntaxe lors de l'écriture dudit fichier de configuration, caractérisé en ce que le fichier de description est étendu, en ce que l'extension comprend au moins un modèle incluant au moins un paramètre inclus dans le fichier de description, et en ce que une partie des paramètres de ce modèle sont valorisés.
L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.
Description d'un exemple de réalisation
Dans les dessins:
- la figure 1 est une vue synoptique de l'architecture d'un système informatique sur lequel peut s'appliquer la solution,
- la figure 2, est une vue d'un modèle conforme à la présente solution. Sur la figure 1 , on a représenté un système informatique SYS distribué illustrant un exemple de réalisation préféré de la solution. Dans l'exemple illustré, ce système SYS inclut un système de gestion SG et au moins une machine M1. Le système de gestion SG comprend au moins un système d'exploitation, au moins une mémoire de stockage d'informations et au moins un processeur contrôlant le processus du traitement de l'information. Le terme gestion est utilisé pour être conforme à la traduction Afnor (Association Française de NORmalisation) de " Management ". Un système de gestion de machines de type " Open Master " (marque déposée par la société BULL S.A.), connu de l'homme du métier, est particulièrement bien adapté pour la mise en œuvre de la solution. Ce système de gestion peut être assimilé à un ensemble de services qui interagissent entre eux pour donner une représentation objet du monde réel constitué notamment par les machines du système informatique. C'est une représentation objet qu'un administrateur manipule (surveillance, action) pour gérer le monde réel. La représentation objet porte sur des objets virtuels du monde réel et constitue un modèle objet. En d'autres mots, un objet géré par le système de gestion est une vue abstraite, définie pour les besoins de gestion, d'une ressource logique ou physique du système informatique, (disque, processeur, mémoire, etc.) et/ou logiques (fichiers, processus, sémaphores, etc.).
Le système de gestion et les machines qu'il gère constitue une architecture Client/Serveur. Dans une telle architecture, un application cliente interroge le système de gestion pour connaître l'état des objets gérés par le système de gestion. Le mode client/Serveur a l'avantage de permettre à un utilisateur appelé client (ou application cliente) situé sur une machine, par exemple par l'intermédiaire d'un simple micro-ordinateur ou d'une station de travail, de confier une partie de sa tâche ou de ses opérations à effectuer au serveur à savoir le système de gestion. De cette manière, le client dispose d'une capacité de calcul beaucoup plus importante que celle de son micro- ordinateur. Le système informatique peut être hétérogène. Afin de masquer l'hétérogénéité du système informatique, le système de gestion SG et les machines gérées par le système de gestion comprennent au moins un agent respectif associé à un protocole de gestion. Un agent assure, entre autres, une conversion de protocole.
Le système de gestion est relié à une machine gérée par l'intermédiaire d'un réseau quelconque. Le réseau peut être de type LAN (Local Area Network), WAN (Wide Area Network). Un ensemble de couches logicielles s'interpose entre le système de gestion SG et le réseau RES et entre le réseau et chaque machine. Pour des raisons de simplification de la description, cet ensemble de couches logicielles n'est pas représenté sur la figure 1.
Chaque objet géré comprend des paramètres définis dans un fichier de configuration de préférence écrit dans un langage de description à balisage comportant une structure et incluant tout ou partie des paramètres (nom, au moins un attribut, au moins une action, etc.) des objets. Le fichier de configuration se base sur un fichier distinct appelé fichier de description définissant les contraintes sur la structure et les contraintes syntaxiques des paramètres pour l'écriture dudit fichier de configuration associé à un objet d'une machine. De préférence, le fichier de configuration est écrit dans un langage de type XML, et le fichier de description est un fichier de description de type DTD, connus de l'homme du métier. Dans notre exemple de réalisation, ce fichier de configuration XML et le fichier de description DTD sont inclus dans le système de gestion SG.
Dans notre exemple de réalisation, le fichier de description DTD est centralisé sur le système de gestion de façon à être utilisable par toutes les machines du réseau. De préférence, les objets gérés peuvent être représentés par un arbre, chaque noeud de l'arbre représentant un objet géré. Une application de visualisation APV incluse sur la machine M1 peut interroger le fichier de configuration dans le but de recevoir les paramètres des objets configurés et de visualiser ces objets sur cette machine. De préférence, pour la visualisation des paramètres de configuration des objets, la machine M1 est munie d'un navigateur standard dit " Internet Explorer ", connu de l'homme du métier, dans lequel un programme en langage JAVA est exécuté pour lire le fichier de configuration, accédant ainsi à son contenu et à sa structure, et pour transmettre les informations lues à (aux) applications de visualisation APV.
Description de paramètres de configuration d'un objet :
Un objet comprend comme paramètre au moins un attribut et des propriétés.. Par exemple, un attribut ID est l'identificateur de l'objet, un autre attribut TYPE désigne son type, et un autre attribut OWNER. Dans notre exemple, un objet comprend également comme paramètres:
B le nom de l'objet,
B les actions que l'on peut exécuter sur cet objet incluant l'action ouvrir pour l'ouverture du noeud, l'action fermer pour la fermeture du noeud, l'action développer pour visualiser les noeuds subordonnés à un noeud, B et des propriétés graphiques de ce noeud incluant le type de police de caractère, l'adresse de l'icône qui lui est associé, et la couleur de fond désirée
Ainsi, dans ce fichier de description DTD, un élément " noeud " est associé à un noeud, et des éléments lui sont subordonnés et sont associés respectivement
B au nom de l'objet
B aux actions (ouvrir, fermer, développer) que l'on peut exécuter sur cet objet,
B et aux propriétés graphiques (police de caractère, icône, couleur de fond) de cet objet.
Des attributs peuvent être associés à un élément. Dans notre exemple de réalisation, l'élément " noeud " comprend trois attributs à savoir : B un attribut ID désignant son identificateur, B un attribut TYPE désignant son type, B et un attribut désignant son propriétaire. Un fichier de description DTD définissant un objet de l'arbre peut être écrit de la façon suivante, en respectant le formalisme particulier défini dans la spécification XML du consortium W3C :
< IELEMENT noeud (noeudNom, noeudActions, noeudPropriétéGrαphique)>
< IELEMENT noeudActions (αction*)>
< ELEMENT noeudNom (groupeNom, αdresseNom, versionNom)>
< IATTLIST noeud Id CDATA #REQUIRED Type CDATA #REQUIRED
Owner CDATA #REQUIRED >
< IELEMENT noeudPropriétégrαphique (police, icône, couleur)>
Dans ce fichier, CDATA #REQUIRED siginifie que l'attribut en question doit être un bloc de texte contenant des caractères. De plus, l'écriture " action* " signifie que les actions n'ont pas d'attributs et que la syntaxe de ces actions à utiliser lors de l'écriture du fichier de configuration est du texte.
L'écriture < ! ELEMENT noeudNom (groupeNom, αdresseNom, versionNom)> indique que l'élément " noeudNom " comprend trois éléments
(groupeNom, αdresseNom, versionNom) qui lui sont subordonné. L'élément
" groupeNom " désigne le nom de l'objet, l'élément " αdresseNom " désigne l'adresse de l'objet, et l'élément " versionNom " désigne la version de l'objet.
Ce fichier de description correspondra dans la suite de la description au fichier de description initialement créé.
Notons que le nombre de paramètres dans notre exemple de réalisation est réduit pour des raisons de simplification de la description. En général un fichier de description comprend un nombre de paramètres beaucoup plus important. Dans l'exemple illustré, supposons par exemple que trois objets (OBJ1 , OBJ2 et OBJ3) se reposent sur le même fichier de description DTD défini plus haut. Le problème principal est que, pour construire le fichier de configuration, l'administrateur du système de gestion doit valoriser les paramètres décrit dans le fichier de description autant de fois qu'il y a d'objets se reposant sur ce fichier DTD. L'administrateur doit donc compléter le fichier de configuration trois fois. Le coût en temps d'une telle écriture est donc considérable.
A cet effet, la solution consiste à étendre le fichier de description par au moins un modèle comprenant au moins un paramètre inclus dans le fichier de description, et en ce qu'il consiste à valoriser une partie des paramètres de ce modèle d'élément. En l'espèce, la solution consiste à introduire un modèle d'élément dont l'écriture respectent des propriétés définies dans la suite de la description.
Dans notre exemple de réalisation, nous avons à définir un ensemble d'objets dont les seuls paramètres variant entre eux sont
- l'élément " Nom " correspondant au nom des objets (OBJ1 , OBJ2 et OBJ3), respectivement (JAZZ, POP, SOL),
- et l'attribut " ID " correspondant à l'identificateur des objets (OBJ1 , OBJ2 et OBJ3), respectivement (123, 142, 162).
Ces deux paramètres seront dits indéfinis dans le suite de la description. Dans l'exemple de réalisation, les objets (OBJ1 , OBJ2 et OBJ3) ont un nom respectif (JAZZ, POP, SOL) et un identificateur respectif (123, 1 2, 162).
Conformément à notre hypothèse de départ, les autres paramètres ont la même valeur pour chaque objet (OBJ1 , OBJ2 et OBJ3). Ils seront dits définis. Ainsi,
B la valeur de l'élément correspondant aux actions que l'on peut exécuter est la même pour chaque objet (OBJ1 , OBJ2 et OBJ3), B la valeur de l'élément correspondant aux propriétés graphiques est la même pour chaque objet (OBJ1 , OBJ2 et OBJ3).
De même,
B la valeur de l'attribut TYPE désignant le type du objet est le même pour chaque objet (OBJ1 , OBJ2 et OBJ3),
B et la valeur de l'attribut OWNER désignant son propriétaire est le même pour chaque objet (OBJ1 , OBJ2 et OBJ3).
Pour des raisons de simplification de la description, on donnera des valeurs arbitraires aux paramètres définis. Dans notre exemple, la valeur de l'élément correspondant aux actions que l'on peut exécuter sur chaque objet (OBJ1 , OBJ2 et OBJ3) est ACT1 pour la commande " ouvrir ", ACT2 pour la commande " fermer ", et ACT3 pour la commande " développer ". De même, la valeur de l'élément correspondant aux propriétés graphiques de chaque objet (OBJ1 , OBJ2 et OBJ3) est PRO1 pour la police de caractère, PRO2 pour l'icône, et PRO3 pour la couleur de fond. Enfin, les deux attributs TYPE et OWNER prennent pour chaque objet (OBJ1 , OBJ2 et OBJ3) les valeurs " snmp " et " opérateur ", respectivement.
Les deux étapes principales du procédé conforme à la solution sont respectivement
- l'écriture du fichier de description DTD et de l'extension associé à ce fichier constitué par au moins un modèle d'élément (étape 1 ),
- et l'écriture du fichier de configuration résultant de la valorisation des paramètres indéfinis du modèle d'élément (étape 2).
Ecriture du fichier de description et introduction de la notion de modèle d'élément dans un fichier de description :
La première étape doit être réalisée en respectant certaines propriétés. Les paramètres de ces objets dont la valeur est invariante étant identifiés, la solution consiste à introduire le modèle d'élément MODELE dans le fichier de description DTD créé. Le modèle d'élément se distingue des autres éléments du fichier de description en ce sens qu'il comporte au moins un paramètre avec une valeur.
Premièrement, le modèle comprend, en respectant le formalisme d'écriture d'un fichier de description DTD défini dans la spécification XML du consortium W3C,
- une entête MODELE avec un nom spécifique " tnoeud "
- et une référence à un élément " noeud " défini du fichier de description DTD créé initialement.
Le modèle MODELE peut être écrit de la façon suivante :
< IMODELE tnoeud ELEMENT =noeud > signifiant que le modèle MODELE à un nom spécifique " tnoeud " et qu'il se base sur la description de l'élément " noeud " défini au préalable dans le fichier de desciption (DTD).
Deuxièmement, dans ce modèle, l'écriture des éléments indéfinis est particulière. Dé façon à distinguer un élément défini d'un élément indéfini dans le modèle d'élément, les éléments à définir sont repérés dans ce modèle par l'intermédiaire d'une balise spécifique dont l'entête est par exemple < !DEFINIR...>. De plus, les éléments à définir sont identifiés par un nom " tnoeudNom " et une référence à un élément noeudNom du fichier de description initial précisant sur quel élément du fichier de description préalablement défini se base le modèle d'élément " tnoeudNom ". Dans notre exemple, un élément à définir peut s'écrire de la façon suivante :
< IDEFINIR tnoeudNom...ELEMENT noeudNom >. A la différence des éléments indéfinis, les éléments définis du modèle d'élément sont écrits de la même façon que pour l'écriture d'un fichier de configuration XML. Troisièmement, l'écriture des attributs indéfinis respecte des propriétés. Dans ce modèle, de façon à distinguer les attributs à définir et les attributs définis, la solution consiste à introduire deux mots clés DEFINIR et DEFINI indiquant qu'un paramètre attribut est à définir (DEFINIR) ou est défini (DEFINI). Dans notre exemple, l'attribut ID est à définir lors de l'écriture du fichier de configuration, tandis que les attributs TYPE et OWNER sont définis et prennent respectivement les valeurs " snmp " et " opérateur ". Dans notre exemple, la liste d'attributs est relative au modèle d'élément MODELE " tnoeud " et peut s'écrire de la façon suivante :
< ! ATTLIST tnoeud
ID DEFINIR
TYPE DEFINI " snmp "
OWNER DEFINI " opérateur " > En définitive, le fichier de description DTD qui découle d'une telle configuration peut s'écrire de la façon suivante :
< IMODELE tnoeud ELEMENT=noeud
< IDEFINIR tnoeudNom ELEMENT=noeudNom>
< noeudActions > <αction nom=ouvrir> ACTl </αction>
<αction nom=fermer>ACT2</αction> <αction nom=développer>ACT3</αction> </ noeudActions >
< noeudPropriétésgrαphiques > <police de caractères PROl ... />
<lcône>PR02</lcône> < couleur de fond PR03/>
< / Propriétésgraphiques > > < ! ATTLIST tnoeud ID DEFINIR
TYPE DEFINI " snmp " OWNER DEFINI " opérateur " >. Ce fichier constitue un facteur commun FC pour l'écriture du fichier de configuration et décrit les paramètres (élément et/ou attribut) à définir.
Ecriture du fichier de configuration
La figure 2 est une vue du fichier de configuration qui résulte de l'utilisation du modèle d'élément.
L'écriture du fichier de configuration correspond à la deuxième étape. Cette opération consiste à utiliser le modèle d'élément MODELE défini dans le fichier de description DTD et à valoriser les éléments et attributs indéfinis. Lors de écriture du fichier de configuration, la solution consiste à utiliser la partie comprenant les paramètres valorisés comme facteur commun, et en ce que l'écriture se limite à la valorisation des paramètres ne comportant pas de valeur.
En l'espèce, trois objets (OBJ1 , OBJ2 et OBJ3) ayant pour nom respectif (JAZZ, POP, SOL) et un identificateur respectif (123, 142, 162) sont à configurer et l'écriture du fichier de configuration pour ces trois objets se limite à écrire les trois blocs suivants (B1 , B2 et B3) :
(Bl )
< tnoeud ld= "123"> < tnoeudNom > <noeudNom>
<groupeNom> JAZZ </groupeNom> <αdresseNom> dbO </ αdresseNom > <versionNom> 8.0 <versionNom> </noeudNom> </ tnoeudNom > </tnoeud>
(B2)
< tnoeud ld= "142"> < tnoeudNom > <noeudNom> <groupeNom> POP </groupeNom>
<αdresseNom> dbl </ αdresseNom > <versionNom> 8.1 <versionNom> </noeudNom> </ tnoeudNom > </tnoeud>
(B3)
<tnoeudld= "162"> < tnoeudNom > <noeudNom>
<groupeNom> SOL </groupeNom> <αdresseNom> db2 </ αdresseNom > <versionNom> 8.2 <versionNom> </noeudNom> </ tnoeudNom > </tnoeud>
Le nombre d'invocation du modèle d'élément correspond au nombre d'objets se reposant sur ce modèle MODELE. Ces trois blocs ont pour même facteur commun celui créé dans le fichier de description. Selon une variante, un modèle d'élément peut contenir d'autres modèles d'éléments. Ainsi, dans un fichier de configuration, on peut utiliser à l'intérieur d'une référence de modèle d'élément (par exemple " tnoeud ") une autre référence de modèle d'éléments. En effet, supposons qu'il existe dans le fichier de description DTD un modèle d'élément " tOracleNoeudNom " dont les éléments définis sont
B l'élément nommé groupeNom
B et l'élément versionNom
et dont l'élément indéfini est adresseNom. L'écriture de ce modèle d'élément peut être le suivant :
< IMODELE tOrocleSNodeNome ELEMENT=noeudNom <groupeNom> Oracle </groupeNom>
< IDEFINIR tOracleDb ELEMENT=adresseNom> <versionNom> 8.0 <versionNom>
>
De cette façon, lors de l'écriture du fichier de configuration, on peut utiliser le modèle " tOracleNoeudNom " pour définir l'élément noeudNom. Le fichier de configuration s'écrit alors de la façon suivante :
<tnoeud ld= "123"> < tnoeudNom >
< tOrocle8NoeudNom>
< tOracleDb> <αdresseNom> dbO </αdresseNom>
</ tOracleDb> </ tOracle8NoeudNom> </ tnoeudNom > </tnoeυd> D'une manière générale, la solution a pour objet un procédé de création, dans un système informatique, d'au moins un fichier de configuration d'au moins un objet matériel et/ou logiciel comprenant des paramètres, ledit fichier de configuration étant écrit en utilisant un metalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ce fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture, caractérisé en ce qu'il consiste, avant l'écriture du fichier de configuration, à étendre le fichier de description par au moins un modèle comprenant au moins un paramètre décrit dans le fichier de description, et à valoriser tout ou partie des paramètres de ce modèle.
Ensuite, lors de l'écriture du fichier de configuration, la solution consiste à utiliser la partie du modèle comprenant les paramètres valorisés comme facteur commun, et en ce que l'écriture du fichier de configuration se limite à la valorisation des paramètres ne comportant pas de valeur.
Lors de la création du modèle, on a vu que la solution peut consister tout d'abord à regrouper les objets se reposant sur le même fichier de description, ensuite à identifier les paramètres dont la valeur est identique entre tous ces objets, et enfin e à valoriser ces paramètres pour constituer un facteur commun dans ce modèle.
La solution consiste par exemple, lors de l'écriture du fichier de configuration, si au moins deux objets se reposent sur le même modèle, à utiliser le facteur commun et à valoriser uniquement le restant des paramètres de ce modèle autant de fois qu'il y a d'objets se reposant sur ce modèle d'élément.
Le langage utilisé est extensible. Dans notre exemple, on a vu que la solution consiste à donner un nom pour identifier le modèle dans le fichier de description, et en ce qu'il consiste à inclure dans le modèle une référence du fichier de description, cette référence définissant les contraintes à respecter sur la structure et la syntaxe de ce modèle. On a vu également que dans notre exemple, la solution consiste à introduire dans un modèle deux mots clés DEFINIR et DEFINI indiquant qu'un paramètre est à définir (DEFINIR) ou est défini (DEFINI) dans ce modèle.
De préférence, le langage du fichier de configuration est le langage XML, la solution consistant à prendre comme paramètre un élément et/ou un attribut d'un objet. Selon cette variante, la solution consiste à étendre le fichier de description par au moins un modèle d'élément comprenant au moins un paramètre (élément et/ou attribut) décrit dans le fichier de description, et à valoriser tout ou partie des paramètres de ce modèle d'élément. De même, la solution consiste à donner un nom pour identifier le modèle d'élément dans le fichier de description, et en ce qu'il consiste à inclure dans le modèle une référence à un élément du fichier de description, cette référence définissant les contraintes à respecter sur la structure et la syntaxe de ce modèle.
Enfin, on a vu que, sur requête d'une application utilisant le fichier de configuration, la solution peut consister à transmettre le facteur commun et les blocs résultant de la valorisation des éléments indéfinis.
Enfin, il en résulte un fichier de configuration d'au moins un objet matériel et/ou logiciel comprenant des paramètres, ledit fichier de configuration étant écrit en utilisant un metalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ce fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture, caractérisé en ce que le fichier de description est étendu, et en ce que l'extension comprend au moins un modèle.
En conclusion, la solution offre de nombreux avantages. Un premier avantage est la simplification considérable de l'écriture d'un fichier de configuration. En effet, les paramètres définis étant valorisés dans le modèle d'élément, l'écriture du fichier de configuration se limite à la valorisation des paramètres indéfinis. En conséquence, l'administrateur évite ainsi la répétition de paramètres identiques entre objets. Le coût en temps d'écriture et le risque d'erreurs d'écriture lors de l'écriture du fichier de configuration est largement réduit. De plus, l'introduction d'un facteur commun dans le modèle réduit considérablement la taille du fichier de configuration. Avantageusement, sur requête d'une application cliente, le système de gestion transmet le fichier de configuration incluant le facteur commun du modèle d'élément et, pour chacun des objets, les paramètres de ce modèle d'élément qui ont été valorisés lors de l'écriture du fichier de configuration. La taille du fichier de configuration étant réduit, le transfert de ce fichier s'effectue donc plus rapidement.

Claims

REVENDICATIONS
1- Procédé de création, dans un système informatique, d'au moins un fichier de configuration d'au moins un objet matériel et/ou logiciel comprenant des paramètres, ledit fichier de configuration étant écrit en utilisant un metalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ce fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture, caractérisé en ce qu'il consiste, avant l'écriture du fichier de configuration,
- à étendre le fichier de description par au moins un modèle comprenant au moins un paramètre décrit dans le fichier de description,
- et à valoriser tout ou partie des paramètres de ce modèle.
2- Procédé selon la revendication 1 , caractérisé en ce qu'il consiste, lors de l'écriture du fichier de configuration, à utiliser la partie du modèle comprenant les paramètres valorisés comme facteur commun, et en ce que l'écriture du fichier de configuration se limite à la valorisation des paramètres ne comportant pas de valeur.
3- Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il consiste, lors de la création du modèle, à regrouper les objets se reposant sur le même fichier de description et ensuite à identifier les paramètres dont la valeur est identique entre tous ces objets, et en ce qu'il consiste à valoriser ces paramètres pour constituer un facteur commun dans ce modèle.
4- Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il consiste, lors de l'écriture du fichier de configuration, si au moins deux objets se reposent sur le même modèle, à utiliser le facteur commun et à valoriser uniquement le restant des paramètres de ce modèle autant de fois qu'il y a d'objets se reposant sur ce modèle d'élément. 5- Procédé selon l'une des revendications 1 à 4, caractérisé en ce que le langage est extensible et en ce qu'il consiste à donner un nom pour identifier le modèle dans le fichier de description, et en ce qu'il consiste à inclure dans le modèle une référence du fichier de description, cette référence définissant les contraintes à respecter sur la structure et la syntaxe de ce modèle.
6- Procédé selon l'une des revendications 1 à 5, caractérisé en ce que le langage est extensible et en ce qu'il consiste à introduire dans un modèle deux mots clés DEFINIR et DEFINI indiquant qu'un paramètre est à définir (DEFINIR) ou est défini (DEFINI) dans ce modèle. 7- Procédé selon l'une des revendications 1 à 6, caractérisé en ce que le langage est le langage XML, et en ce qu'il consiste à prendre comme paramètre un élément et/ou un attribut d'un objet.
8- Procédé selon la revendication 7, caractérisé en ce qu'il consiste à étendre le fichier de description par au moins un modèle d'élément comprenant au moins un paramètre (élément et/ou attribut) décrit dans le fichier de description, et à valoriser tout ou partie des paramètres de ce modèle
9- Procédé selon la revendication 7 ou 8, caractérisé en ce qu'il consiste à donner un nom pour identifier le modèle d'élément dans le fichier de description, et en ce qu'il consiste à inclure dans le modèle une référence à un élément du fichier de description, cette référence définissant les contraintes à respecter sur la structure et la syntaxe de ce modèle.
10- Procédé selon l'une des revendication 7 à 9, caractérisé en ce qu'il consiste à inclure dans un modèle d'élément au moins un modèle d'élément.
11- Procédé selon l'une des revendications 7 à 10, caractérisé en ce qu'il consiste, sur requête d'une application utilisant le fichier de configuration, à transmettre le facteur commun et les blocs résultant de la valorisation des éléments indéfinis.
12- Fichier de configuration d'au moins un objet matériel et/ou logiciel comprenant des paramètres, ledit fichier de configuration étant écrit en utilisant un metalangage de description dont le format est indépendant du matériel et/ou logiciel à configurer, ce fichier de configuration incluant tout ou partie des paramètres dudit objet et se reposant sur un fichier de description définissant des contraintes à respecter sur sa structure et sa syntaxe lors de son écriture, caractérisé en ce que le fichier de description est étendu, et en ce que l'extension comprend au moins un modèle tel que défini dans l'une des revendications 1 à 11.
PCT/FR2000/003231 1999-11-26 2000-11-21 Procede de creation de fichiers de configuration d'objets inclus dans un systeme informatique WO2001038977A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9914882A FR2801705B1 (fr) 1999-11-26 1999-11-26 Procede de creation de fichiers de configuration d'objets inclus dans un systeme informatique
FR99/14882 1999-11-26

Publications (1)

Publication Number Publication Date
WO2001038977A1 true WO2001038977A1 (fr) 2001-05-31

Family

ID=9552564

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2000/003231 WO2001038977A1 (fr) 1999-11-26 2000-11-21 Procede de creation de fichiers de configuration d'objets inclus dans un systeme informatique

Country Status (2)

Country Link
FR (1) FR2801705B1 (fr)
WO (1) WO2001038977A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100429888C (zh) * 2005-01-12 2008-10-29 乐金电子(中国)研究开发中心有限公司 手机及手机配置方法及为手机提供xml配置文件的网站

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030072451A1 (en) * 2001-10-16 2003-04-17 Pimentel Roberto J. Method and apparatus for securely transferring wireless data
US7418484B2 (en) * 2001-11-30 2008-08-26 Oracle International Corporation System and method for actively managing an enterprise of configurable components
JP2005523513A (ja) 2002-04-19 2005-08-04 コンピューター アソシエイツ シンク，インク． オペレーティングシステムオプション価値を管理するためのシステムおよび方法
US7434041B2 (en) 2005-08-22 2008-10-07 Oracle International Corporation Infrastructure for verifying configuration and health of a multi-node computer system
US8615578B2 (en) 2005-10-07 2013-12-24 Oracle International Corporation Using a standby data storage system to detect the health of a cluster of data storage servers

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
BERT BOS: "XML in 10 points", INTERNET DOCUMENT, 27 March 1999 (1999-03-27), XP002151130, Retrieved from the Internet <URL:http://www.w3.org/XML/1999/XML-in-10-points> [retrieved on 20001024] *
CLEMENS KERER: "A flexible and extensible security framework for Java code", INTERNET DOCUMENT: DIPLOMARBEIT, 22 October 1999 (1999-10-22), Vienne, Autriche., XP002151129, Retrieved from the Internet <URL:http://www.infosys.tuwien.ac.at/Teaching/Finished/MastersTheses/JSEF/thesis.ps.zip> [retrieved on 20001025] *
ÉRIC JACOBONI (JACO@MAIL.DOTCOM.FR): "Lire et envoyer du courrier off-line sur sa machine", INTERNET DOCUMENT, 1 July 1998 (1998-07-01), XP002151131, Retrieved from the Internet <URL:ftp://anonymous:anonymous@ftp.linux-france.org/pub/article/mail/sendmail/sendmail.ps.gz> [retrieved on 20001024] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100429888C (zh) * 2005-01-12 2008-10-29 乐金电子(中国)研究开发中心有限公司 手机及手机配置方法及为手机提供xml配置文件的网站

Also Published As

Publication number Publication date
FR2801705A1 (fr) 2001-06-01
FR2801705B1 (fr) 2002-01-25

Similar Documents

Publication Publication Date Title
US11714665B2 (en) Method and apparatus for composite user interface creation
US8650320B1 (en) Integration server supporting multiple receiving channels
JP4993876B2 (ja) Ｗｅｂサービス・アプリケーション・プロトコルおよびＳＯＡＰ処理モデル
JP4015375B2 (ja) クライアント側ユーザインタフェース要素を処理するサーバ側制御オブジェクト
US6792607B1 (en) Databinding using server-side control objects
US20030140097A1 (en) Method and device for presenting data to a user
US11507351B2 (en) Intent compiler
US20030037181A1 (en) Method and apparatus for providing process-container platforms
US20040167896A1 (en) Content management portal and method for communicating information
EP1126681A2 (fr) Portique de réseau et procédé associé
US8966509B2 (en) Client-side web service provider
US20040187111A1 (en) Content management portal and method for communicating media content
US6728750B1 (en) Distributed application assembly
US20030105858A1 (en) Method and apparatus for remote database maintenance and access
CN102792268A (zh) 虚拟软件应用部署配置
JP2004506968A (ja) データ処理装置、方法、及びシステム
US20080091743A1 (en) Methods and Systems For Simultaneously Accessing Multiple Databases
JP5886901B2 (ja) 装置へのコンテンツの分配を管理するシステムと方法とプログラムを提供する記憶媒体
WO2001038977A1 (fr) Procede de creation de fichiers de configuration d&#39;objets inclus dans un systeme informatique
EP1126674B1 (fr) Procédé et appareil de présentation de données pour un utilisateur
US20070283034A1 (en) Method to support data streaming in service data objects graphs
US20090228900A1 (en) Systems and methods for application programming using persistent objects
US20050198057A1 (en) Mechanism for efficiently implementing object model attributes
EP1009128A1 (fr) Procédé de visualisation, dans un système informatique, d&#39;associations entre objects inclus dans un arbre de contenance d&#39;un système de gestion de machines
GB2370658A (en) A modular software framework

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 09890211

Country of ref document: US

122 Ep: pct application non-entry in european phase