WO2007003774A1 - Procede d ' echange de donnees entre un serveur et un client , serveur correspondant a ce procede , systeme comprenant ce serveur, client de ce systeme , programmes correspondant a ce procede pour un ordinateur formant serveur et un ordinateur formant client - Google Patents

Procede d ' echange de donnees entre un serveur et un client , serveur correspondant a ce procede , systeme comprenant ce serveur, client de ce systeme , programmes correspondant a ce procede pour un ordinateur formant serveur et un ordinateur formant client Download PDF

Info

Publication number
WO2007003774A1
WO2007003774A1 PCT/FR2006/001530 FR2006001530W WO2007003774A1 WO 2007003774 A1 WO2007003774 A1 WO 2007003774A1 FR 2006001530 W FR2006001530 W FR 2006001530W WO 2007003774 A1 WO2007003774 A1 WO 2007003774A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
client
request
response
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2006/001530
Other languages
English (en)
Inventor
Christian Bertin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Publication of WO2007003774A1 publication Critical patent/WO2007003774A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream

Definitions

  • the present invention relates to a structured data exchange method between at least one server and a client, a server, a system comprising this server, a client of this system, a program for a computer forming a server and a program for a computer forming the client of this system.
  • the information is in the form of data whose structure is generally specific to the server providing the data. Thus a client user wishing to access this data must know the data structure of the server.
  • the client accesses a home web page and makes a request by entering for example keywords in an input field of this page d 'Home.
  • the home page is usually created in HTML markup language (HyperText Markup Language).
  • the search engine In response to the request, the search engine generally offers an HTML page containing citations each containing the references of a website (whose pages contain the key words entered) and a link to access this site.
  • the automatic exploitation of the information contained in the response provided by the search engine can be performed by the client by executing an analysis program of this response page.
  • the analysis program identifies particular marks in the page. However, if the presentation of the response page changes, the marks and the analysis program become obsolete and must be updated.
  • TV-Anytime or RSS type specifications are each specific to a particular domain, namely the audiovisual domain for the TV-Anytime specification and the journalistic domain for the RSS specification. Therefore, these specifications are not intended to be transposed to other areas.
  • the purpose of the invention is notably to facilitate the exchange of structured data, in particular of the XML type, between a client and a server without resorting to major standardization work.
  • the subject of the invention is a method for exchanging data between at least a first server and a client, the method being of the type comprising a step of formulating a request for the attention of a second server.
  • a second server which, if necessary, can be the first server, providing structured data, in particular of XML type, characterized in that it comprises a preliminary step of providing the first server to the client with information relating to the request and request structures. response consistent with the data structure in effect on the second server.
  • This preliminary step makes it possible to make the data proposed by a server easily accessible to the customer, without it being necessary to resort to standards systems specific to particular and difficult to establish domains.
  • access to the server can be done automatically by means of an access program established from the request and response structures communicated by the server.
  • the client user can therefore, from an Internet site hosted by a first server, generate a request to a second server, whose content is mentioned by this site, for example in the form of advertising, and its database, depending on the information that this database is likely to provide. Thanks to the invention, the client is informed of the query and response structures applicable to the data of the database of the data provider server, even if these structures are specific and not standardized. This allows the client to collect, possibly automatically, data from the server base by dispensing with the format of the Internet presentation page of a service offered by the server.
  • the query structure information includes at least one of a definition of a request transfer protocol, a definition of a server address, a definition of a command, and a definition of at least one of a parameter identified by a name, a type and a unit, if it is of numeric type.
  • this information may also include:
  • the response structure information provided to the client includes at least one definition selected from a definition of a data structure name expected in response and a definition of at least one element of the response, identified by a name, a type and a unit, if it is of numeric type.
  • they can also include, for each element, a name, a type, a list of possible values, a descriptive comment and, if the element is of numeric type, a unit and a cardinality.
  • the first and second servers form a single server.
  • the step of providing information is completed by a step of presenting said information using an interface program executed by the client.
  • the interface program generates, according to a particular embodiment, at least one window presenting this information, for example in the form of an HTML page.
  • the interface program may further comprise, on the one hand, descriptive elements describing the information relating to the request and response structures and, on the other hand, assistance elements for the formulation of a request.
  • At least one of the descriptive elements comprises a list of information that may be part of a response, the assistance elements for the formulation of a request making it possible to make a choice among the information items of this list.
  • This list can be in particular a list of values assigned to a parameter. For example, different values "NAME1", “NOM2”, etc. can be assigned to a "company name” parameter.
  • the invention thus avoids the user having to formulate his query directly in XML, this request being created by choosing values in the proposed list using a support element associated with the corresponding parameter.
  • the request formulation step may further include incorporating client-specific data into the request.
  • the method may include a step of transmitting the request to the second server as a result of a voluntary action of a user on the client.
  • the method may also include a step of automatic transmission of the request by the client to the second server, for example according to a sequence programmed by a user in the client.
  • a request that can be used periodically for example a stock quote request, can be stored by the client (which avoids the need to reformulate each time) and automatically transmitted to the corresponding server.
  • the information presentation step is initiated by the voluntary activation of a link in an Internet page presented by the first server.
  • the client user receives information about the data structure of the server only if he plans to make a request to the attention of this server, which avoids using the resources of the client unnecessarily.
  • the method also includes a response transmission step by the second server, the response being in accordance with the response structure previously transmitted to the client.
  • the invention also relates to a server characterized in that it comprises means for supplying a client with information relating to the request and response structures in accordance with the data structure in effect on a server providing structured data, in particular XML type.
  • a server providing structured data, in particular XML type.
  • the two servers described above form a single server.
  • the invention also relates to a system comprising a server and a client interconnected by means of a network, the client having means for formulating a request for a second server which, if necessary, can be the first server, providing data, including XML type, characterized in that the first server is as defined above.
  • the invention also relates to a client of a system as defined above, characterized in that it comprises means for presenting the information provided by the first server.
  • the client includes data embedding means specific to it in the request to the attention of the second server.
  • the client may also include means for sending the request to the second server, automatically or as a result of a voluntary action of a user.
  • the client according to the invention also comprises means for activating a link in an Internet page proposed by the first server, triggering the provision of information by this server.
  • the subject of the invention is also a program for a computer forming a server as defined above, characterized in that it automatically provides the client with information relating to the request and response structures conforming to the data structure of the server. a second server.
  • the invention also relates to a program for a computer forming a client of a system as defined above, characterized in that it generates an interface for presenting information provided to the client by the server.
  • the interface generated by this computer program includes a window, for example to display an HTML page, giving access or presenting the information provided to the client by the server;
  • FIG. 1 is a diagram of a data exchange system according to a particular embodiment of the invention
  • FIG. 2 represents the successive steps of a data exchange method according to the invention, implemented in the system of FIG. 1
  • Figure 3 is a diagram of a request and response structure that can be presented in XML.
  • FIG. 1 shows a system 10 according to the invention for exchanging data between a client 12 and a server 14 via a conventional network 16 connecting the client 12 and the server 14, for example the Internet network.
  • Client 12 includes a computer.
  • This computer comprises a processing device comprising a central unit 20 provided with a 2OP processor, a 2OM memory, for example of RAM (acronym for Random Access Memory), and input-output 2OA, 2OB.
  • the computer also includes interface elements 22 for a user, for example a keyboard, a screen and a mouse, and a database 24.
  • the server 14 includes a computer.
  • This computer comprises a supply device, comprising a central unit 26, and a database 28.
  • the central unit 26 is generally equipped with a processor 26P, a memory 26M and an input-output 26A , 26B.
  • the base 24 of the client 12 may, if necessary, be filled with data from the base 28 of the server 14, as specified below.
  • the client 12 and / or the server 14 may comprise several databases.
  • the system 10 may include a central server giving access to different servers providing data.
  • a data exchange method implemented by the system 10 will be described below with reference to FIG. 2.
  • a client user a user of the client 12, will be called.
  • the client user accesses, via the network 16, to an Internet page proposed by the server 14.
  • This Internet page presents elements forming computer links giving access to data likely to be provided by the server 14.
  • the client user interested in data proposed by the server 14, voluntarily activates a link (step 32) giving access to this data using a user interface element 22.
  • This step 32 triggers a step 36 of providing, by the server 14, information to the client 12.
  • conventional means including in particular the central unit 26 of the server 14
  • These conventional means include the central unit 26 of the server 14, on which runs a computer program.
  • the information 38 may be transmitted to the client 12 in an XML definition file programmed by an operator of a service proposed by the server 14.
  • the information 38 relating to the query and response structures 40 defining these structures can be organized in a tree-like manner as schematized in FIG. 3.
  • the definition of the request structure 40 comprises at least one definition of the mode of the request, ie the transfer protocol of the request.
  • the latter may for example be of type 44a, conforming to the hypertext transfer protocol HTTP (acronym for HyperText Transfer Protocol), or type 44b, compliant with the SOAP protocol (acronym for Simple Object Access Protocol).
  • the definition of the request structure 40 also includes a server address and a command.
  • the definition of the request structure 40 can also include a definition 46 of at least one interrogation parameter of the database 28 of the server 14, the latter being identified by a name, a type (boolean, integer, string characters, etc.) and a unit, if it is numeric.
  • the definition of the request structure 40 may also include a definition of a group of at least two parameters, related by logical operators, such as OR or AND. Each of the parameters of the request structure 40 may be specified by a descriptive comment, a list of expected values, a minimum value, a maximum value and a default value.
  • the definition of the request structure 40 may also include a list of elements to be included in the response, these elements being to be chosen from all the elements that the server 14 can provide in the response.
  • the definition of the response structure 42 may comprise a definition 48 of a name of a data structure expected in response, and a definition of at least one element of this structure, possibly associated with one or more attributes that may take particular values.
  • the definition of response structure 42 may include a definition of an element name, a type (boolean, integer, character string, etc.), a list of possible values, the meaning of these values and a unit and a cardinality, that is, the number of occurrences of an identity, only if the values associated with the element are numeric.
  • the above definitions can be apprehended by the client 12 directly from a program capable of understanding a data structure in XML syntax according to the diagram presented below:
  • ⁇ xs: enumeration value "OR" /> ⁇ / xs: restriction> ⁇ / xs: simpleType> ⁇ / xs: attribute> ⁇ / xs: complexType>
  • attribute name "number”> ⁇ xs: simpleType>
  • the server is queried using the HTTP transfer protocol.
  • the request structure 40 presented in the definition file, in the form of a program in XML language may be the same. type below:
  • the server is queried using the SOAP transfer protocol.
  • the client user can therefore query the server using this protocol according to the following specifications, defining the inputs and outputs, the encodings and the links to be used by the data services:
  • binding defines how SOAP / HTTP is used to transport the service.
  • response structure 42 presented in the definition file does not depend on the protocol used and can be of the type below:
  • the response structure 42 may also be of the type shown below. It differs from the type presented previously in that it allows to return a tree of elements, and thus, as part of the example, it is possible to send stock information on several companies in the same answer:
  • provisioning step consists of a supply by the first server 14 to the client 12 of request and response structures 40 in accordance with the data structure in force on the second server 14 or 14 ', these structures being defined in a program in data description language.
  • the client 12 can formulate a request adapted to the information that it wants to obtain from the server 14.
  • the query relating to the example can be formulated as follows:
  • the method includes a step 50 of presenting to the user.
  • presentation means 20 a window containing for example an HTML page, forming an interface giving access to or presenting information supplied to the client 12 by the server 14, more particularly presenting the definitions of the structures 40, 42.
  • presentation means 20 comprise a non-specific interface program to the server 14, downloaded and installed in advance on the client. The sending to the client 12 of the interface program can be triggered following a voluntary download command from the client 12.
  • the sending to the client 12 of the definition file with its MIME type can be triggered by the activation of the link provided in step 32.
  • the execution of the interface program by the client 12 is triggered automatically by the reception of the definition file sent by the server 14 which includes a MIME type (for example: "application / x-QRD-program") associated with this program.
  • MIME type for example: "application / x-QRD-program”
  • the extension of the definition file is ".QRD”
  • the corresponding MIME type sent is then "application / x-QRD-program”.
  • This program extracts the information 38 contained in the definition file to create, in the presentation HTML page displayed on the client screen 12, clear elements describing the information relating to the query 40 and response 42 structures.
  • the descriptive elements structures 40, 42 appearing on the Internet page are for example lists of values or text presenting the various parameters in this embodiment.
  • the interface program also creates, in the presentation HTML page displayed on the client screen 12, assistance elements for the formulation of requests.
  • At least one of the descriptive elements of the presentation HTML page may comprise a list of information that may be part of a response, the assistance elements for the formulation of a request making it possible to make a choice among the information from this list, for example using buttons or an input field.
  • the interface program is also used to decide the destination of the elements contained in the response with possible conversion to the coding used at the client.
  • the step 50 of presenting information is followed by a step 52 during which the client user makes a request to the attention of the server 14.
  • This step 52 may comprise a substep 54 of formulating the request using the assistance elements for the formulation of requests proposed by the interface program and conventional means such as an interface element 22 of the interface.
  • client 12 keyboard, mouse, etc.
  • Step 52 may also include a substep 56 of incorporation in the client-specific data request 12, more particularly data contained in the client's database 24.
  • the substep 56 may be executed in particular using means comprising non-server specific utility software 14 stored on the central unit 20 of the client 12. After having formulated the request, the client 12 sends this request to the server 14, in a step 58. This transmission can be done as a result of voluntary action by the user on the client 12 (substep 60 of step 58) or automatically (substep
  • the client user can manually trigger the transmission of the request for example by clicking a button of the presentation window.
  • the transmission of the request is controlled by conventional means of the client comprising a user interface element 22 (keyboard, mouse, etc.) and the central unit 20 of the client 12.
  • the request is transmitted to the server 14 via the network 16.
  • the request is automatically sent by the client 12 to the server 14, for example in accordance with a sequence programmed by the user in the client 12.
  • a form is presented to the client user.
  • the latter indicates, by filling fields of entries or by clicking on numerical buttons, to which deadlines the request must be transmitted automatically to the server 14.
  • This form can be generated by means including a utility software, for example the program of interface described above, stored in the central unit 20 of the client 12.
  • the transmission of the request is controlled by conventional means comprising the central unit 20 of the client 12.
  • the request is transmitted to the server 14 via the network 16.
  • the server 14 After reception of the request by the server 14, the latter processes it and sends a response to the client 12 during a step 64.
  • the response is in accordance with the response structure 42 included in the definition file presented in advance. to the customer user.
  • the response according to the first embodiment can be as follows: W
  • the response to the request given as an example is:
  • the response can also consist of a tree of elements to provide several separate data, so that only one sending by the server
  • server response 14 may contain all the data required by the client 12. If appropriate, some data in the server response 14 and from the base 28 of this server
  • the system and method described above thus allow a client user to generate a request to a server 14 and make the best use of its response regardless of the data structure in force on this server 14.
  • the data exchange system according to the invention is not limited to the embodiment described above.
  • the system may comprise two servers, namely the server 14 in full line (first server) and the server 14 'in dashed lines (second server) rather than one and the same server as previously described.
  • the first server 14 provides the client with information on the request and response structures in accordance with the data structure in effect on the second server 14 '.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Ce procédé d'échange de données entre au moins un premier serveur (14) et un client (12) comprend une étape (52) de formulation d'une requête à l'attention d'un second serveur (14, 14') qui, le cas échéant, peut être le premier serveur, fournissant des données structurées, notamment de type XML et une étape préalable (36) de fourniture par le premier serveur (14) au client (12) d'informations relatives aux structures de requête (40) et de réponse (42) conformes à la structure de données en vigueur sur le second serveur (14, 14'). De préférence, l'étape (36) de fourniture d'informations est complétée par une étape de présentation (50) de ces informations par un programme d'interface exécuté par le client. Ce programme génère une interface de présentation des informations relatives aux structures de requête et de réponse.

Description

PROCEDE D'ECHANGE DE DONNEES ENTRE UN SERVEUR ET DN CLIENT, SERVEUR CORRESPONDANT A CE PROCEDE, SYSTEME COMPRENANT CE SERVEUR, CLIENT DE CE SYSTEME, PROGRAMMES CORRESPONDANT A CE PROCEDE POUR UN ORDINATEUR FORMANT SERVEUR ET UN ORDINATEUR FORMANT CLIENT
La présente invention concerne un procédé d'échange de données structurées entre au moins un serveur et un client, un serveur, un système comprenant ce serveur, un client de ce système, un programme pour un ordinateur formant un serveur et un programme pour un ordinateur formant le client de ce système.
Elle s'applique en particulier à l'exploitation automatique par le client d'informations proposées par le serveur.
Les informations se présentent sous forme de données dont la structure est généralement spécifique au serveur fournissant ces données. Ainsi un utilisateur client souhaitant accéder à ces données doit connaître la structure de données du serveur.
Il est connu d'échanger des données entre un client et un serveur reliés entre eux par le réseau Internet.
Ainsi, dans le cas particulier d'un serveur proposant les services d'un moteur de recherche, le client accède à une page Internet d'accueil et formule une requête en saisissant par exemple des mots clefs dans un champ de saisie de cette page d'accueil. La page d'accueil est généralement créée en langage de balisage de texte HTML (acronyme anglais de HyperText Markup Language).
En réponse à la requête, le moteur de recherche propose généralement une page en HTML contenant des citations comportant chacune les références d'un site Internet (dont les pages contiennent les mots clefs saisis) et un lien permettant d'accéder à ce site. L'exploitation automatique des informations contenues dans la réponse fournie par le moteur de recherche peut être réalisée par le client en exécutant un programme d'analyse de cette page de réponse. Le programme d'analyse identifie des repères particuliers dans la page. Toutefois, si la présentation de la page de réponse évolue, les repères et le programme d'analyse deviennent caduques et doivent être remis à jour. Pour faciliter l'obtention automatique d'informations par un client, il a été proposé dans l'état de la technique de normaliser la présentation des informations fournies par un serveur, par exemple conformément aux spécifications du type TV-Anytime ou du type à syndication vraiment simple RSS (conformément à l'acronyme anglais Really Simple Syndication). Ces spécifications permettent d'organiser un échange de données structurées entre un serveur et un client en langage de balisage extensible XML (conformément à l'acronyme anglais extensible Markup Language). Toutefois, la définition des spécifications de type TV-Anytime ou RSS requiert un travail de consultation des fournisseurs de services intéressés et de standardisation relativement important pour décrire la syntaxe et la sémantique des requêtes et réponses.
De plus, bien que l'accès d'un utilisateur client aux données soit simplifié, celui-ci doit se familiariser avec les spécifications précitées de la structure de données avant de pouvoir l'utiliser.
Enfin, les spécifications de type TV-Anytime ou RSS sont chacune propre à un domaine particulier, à savoir le domaine audiovisuel pour la spécification de TV-Anytime et le domaine journalistique pour la spécification RSS. Par conséquent, ces spécifications ne sont pas prévues pour être transposées à d'autres domaines.
L'invention a notamment pour but de faciliter l'échange de données structurées, notamment de type XML, entre un client et un serveur sans recourir à des travaux importants de normalisation.
A cet effet, l'invention a pour objet un procédé d'échange de données entre au moins un premier serveur et un client, le procédé étant du type comprenant une étape de formulation d'une requête à l'attention d'un second serveur qui, le cas échéant, peut être le premier serveur, fournissant des données structurées, notamment de type XML, caractérisé en ce qu'il comprend une étape préalable de fourniture par le premier serveur au client d'informations relatives aux structures de requête et de réponse conformes à la structure de données en vigueur sur le second serveur.
Cette étape préalable permet de rendre facilement accessible au client des données proposées par un serveur, ceci sans qu'il soit nécessaire de recourir à des systèmes de normes spécifiques à des domaines particuliers et difficiles à établir.
Le cas échéant, l'accès au serveur peut se faire automatiquement au moyen d'un programme d'accès établi à partir des structures de requête et de réponse communiquées par le serveur.
Sur Internet, ces structures sont généralement indépendantes de la présentation de la page HTML qui, habituellement, permet l'accès aux services proposés par un serveur. Une modification de la présentation de cette page est donc sans conséquence sur le fonctionnement du programme d'accès aux données.
L'utilisateur client peut donc, à partir d'un site Internet hébergé par un premier serveur, générer une requête vers un second serveur, dont le contenu est mentionné par ce site, par exemple sous forme de publicité, et sa base de données, en fonction des informations que cette base est susceptible de lui fournir. Grâce à l'invention, le client est informé des structures de requête et de réponse applicables aux données de la base du serveur fournisseur de données, même si ces structures sont spécifiques et non normées. Ceci permet au client de recueillir, éventuellement de façon automatique, des données de la base du serveur en s'affranchissant du format de la page Internet de présentation d'un service proposé par le serveur. Les informations relatives à la structure de requête comprennent au moins une définition choisie parmi une définition d'un protocole de transfert de la requête, une définition d'une adresse de serveur, une définition d'une commande, et une définition d'au moins un paramètre identifié par un nom, un type et une unité, s'il est de type numérique. De manière optionnelle, ces informations peuvent également comprendre :
- un groupe d'au moins deux paramètres, mis en relation à l'aide d'opérateurs logiques ;
- pour chaque paramètre, un commentaire descriptif, une liste de valeurs attendus, une valeur minimale, une valeur maximale et une valeur par défaut ; une liste d'éléments à inclure dans la réponse.
Par ailleurs, les informations relatives à la structure de réponse et fournies au client comprennent au moins une définition choisie parmi une définition d'un nom de structure de données attendue en réponse et une définition d'au moins un élément de la réponse, identifié par un nom, un type et une unité, s'il est de type numérique.
Avantageusement, elles peuvent également comprendre, pour chaque élément, un nom, un type, une liste de valeurs possibles, un commentaire descriptif et, si l'élément est de type numérique, une unité et une cardinalité.
Cela permet en effet de pouvoir replacer à la réception de la réponse, le contenu de chaque élément à l'endroit approprié, par exemple, dans une base de données client, avec ou sans conversion du codage du serveur au codage chez le client.
Selon un mode de réalisation particulier de l'invention, le premier et le second serveurs forment un seul et même serveur.
De manière optionnelle, l'étape de fourniture d'informations est complétée par une étape de présentation desdites informations à l'aide d'un programme d'interface exécuté par le client .
Le programme d'interface génère, selon un mode de réalisation particulier, au moins une fenêtre présentant ces informations, par exemple sous forme de page HTML.
Le contenu de cette fenêtre est généralement rédigée dans un langage ordinaire, accessible par un utilisateur qui n'est pas familier des langages informatiques. -A-
Le programme d'interface peut en outre présenter, d'une part, des éléments descriptifs décrivant les informations relatives aux structures de requête et de réponse et, d'autre part, des éléments d'assistance à la formulation d'une requête.
Le cas échéant, au moins un des éléments descriptifs comprend une liste d'informations susceptibles de faire partie d'une réponse, les éléments d'assistance à la formulation d'une requête permettant de réaliser un choix parmi les informations de cette liste.
Cette liste peut être notamment une liste de valeurs affectées à un paramètre. Par exemple, différentes valeurs « NOM1 », « NOM2 », etc. peuvent être affectées à un paramètre « nom de société ».
L'invention évite ainsi à l'utilisateur d'avoir à formuler sa requête directement en langage XML, cette requête étant créée par choix de valeurs dans la liste proposée à l'aide d'un élément d'assistance associé au paramètre correspondant.
L'étape de formulation de requête peut en outre comprendre l'incorporation dans la requête de données propres au client.
Le procédé peut comprendre une étape d'émission de la requête vers le second serveur à la suite d'une action volontaire d'un utilisateur sur le client.
Le procédé peut également comprendre une étape d'émission automatique de la requête par le client vers le second serveur, par exemple conformément à une séquence programmée par un utilisateur dans le client.
Ainsi, une requête susceptible d'être utilisée périodiquement, par exemple une requête de cours de valeurs boursières, peut être mémorisée par le client (ce qui évite de la reformuler chaque fois) et transmise automatiquement au serveur correspondant.
De manière optionnelle, l'étape de présentation d'informations est initialisée par l'activation volontaire d'un lien dans une page Internet présentée par le premier serveur.
Ainsi, l'utilisateur client reçoit les informations relatives à la structure de données du serveur uniquement s'il envisage de formuler une requête à l'attention de ce serveur, ce qui évite d'utiliser les ressources du client inutilement.
Le procédé comprend également une étape de transmission de réponse par le second serveur, la réponse étant conforme à la structure de réponse transmise préalablement au client.
L'invention a également pour objet un serveur caractérisé en ce qu'il comprend des moyens de fourniture à un client d'informations relatives aux structures de requête et de réponse conformes à la structure de données en vigueur sur un serveur fournissant des données structurées, notamment de type XML. Optionnellement, les deux serveurs décrits ci-dessus forment un seul et même serveur.
L'invention a également pour objet un système comprenant un serveur et un client reliés entre eux au moyen d'un réseau, le client comportant des moyens de formulation de requête à l'attention d'un second serveur qui, le cas échéant, peut être le premier serveur, fournissant des données, notamment de type XML, caractérisé en ce que le premier serveur est tel que défini ci-dessus.
L'invention a également pour objet un client d'un système tel que défini ci-dessus, caractérisé en ce qu'il comprend des moyens de présentation des informations fournies par le premier serveur.
Optionnellement, le client comprend des moyens d'incorporation de données qui lui sont propres dans la requête à l'attention du second serveur.
Le client peut également comprendre des moyens d'émission de la requête vers le second serveur, automatiquement ou à la suite d'une action volontaire d'un utilisateur. De façon optionnelle, le client selon l'invention comprend également des moyens d'activatîon d'un lien dans une page Internet proposée par le premier serveur, déclenchant la fourniture d'informations par ce serveur.
L'invention a également pour objet un programme pour un ordinateur formant un serveur tel que défini ci-dessus, caractérisé en ce qu'il fournit automatiquement au client des informations relatives aux structures de requête et de réponse conformes à la structure de données d'un second serveur.
L'invention a également pour objet un programme pour un ordinateur formant un client d'un système tel que défini ci-dessus, caractérisé en ce qu'il génère une interface de présentation d'informations fournies au client par le serveur. De manière optionnelle, l'interface générée par ce programme d'ordinateur: comprend une fenêtre, permettant d'afficher par exemple une page HTML, donnant accès ou présentant les informations fournies au client par le serveur ;
- présente, d'une part, des éléments descriptifs décrivant les informations relatives aux structures de requête et de réponse et, d'autre part, des éléments d'assistance à la formulation d'une requête.
L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins dans lesquels :
- la figure 1 est un schéma d'un système d'échange de données selon un mode de réalisation particulier de l'invention ; - la figure 2 représente les étapes successives d'un procédé d'échange de données selon l'invention, mis en œuvre dans le système de la figure 1 ; la figure 3 est un schéma d'une structure de requête et de réponse susceptible d'être présentée en langage XML. On a représenté sur la figure 1 un système 10 selon l'invention pour l'échange de données entre un client 12 et un serveur 14 par l'intermédiaire d'un réseau classique 16 reliant le client 12 et le serveur 14, par exemple le réseau Internet.
Le client 12 comprend un ordinateur. Cet ordinateur comporte un dispositif de traitement comprenant une unité centrale 20 munie d'un processeur 2OP, d'une mémoire 2OM, par exemple de type RAM (acronyme anglais de Random Access Memory), et d"entrées-sorties 2OA, 2OB. L'ordinateur comporte également des éléments 22 d'interface pour un utilisateur, par exemple un clavier, un écran et une souris, et une base de données 24.
Le serveur 14 comprend un ordinateur. Cet ordinateur comporte un dispositif de fourniture, comprenant une unité centrale 26, et une base de données 28. L'unité centrale 26 est munie, en général, d'un processeur 26P, d'une mémoire 26M et d'entrées-sorties 26A, 26B.
La base 24 du client 12 peut, le cas échéant, être renseignée par des données de la base 28 du serveur 14, comme précisé par la suite. En variante, le client 12 et/ou le serveur 14 peuvent comprendre plusieurs bases de données. De même, le système 10 peut comprendre un serveur central donnant accès à différents serveurs fournissant des données.
On décrira ci-dessous, en référence à la figure 2, un procédé d'échange de données mis en oeuvre par le système 10. Dans ce qui suit, on appellera utilisateur client, un utilisateur du client 12.
Initialement (étape préliminaire 30), l'utilisateur client accède, par l'intermédiaire du réseau 16, à une page Internet proposée par le serveur 14. Cette page Internet présente des éléments formant des liens informatiques donnant accès à des données susceptibles d'être fournies par le serveur 14. L'utilisateur client, intéressé par des données proposées par le serveur 14, active volontairement un lien (étape 32) donnant accès à ces données à l'aide d'un élément 22 d'interface utilisateur.
Cette étape 32 déclenche une étape 36 de fourniture, par le serveur 14, d'informations au client 12. Au cours de l'étape 36, des moyens classiques (comprenant notamment l'unité centrale 26 du serveur 14) fournissent au client 12 des informations 38 comprenant des définitions relatives à des structures de requête 40 et de réponse 42 conformes à la structure de données en vigueur sur le serveur 14. Ces moyens classiques comprennent notamment l'unité centrale 26 du serveur 14, sur lequel s'exécute un programme informatique.
Les informations 38 peuvent être transmises au client 12 dans un fichier de définition en langage XML programmé par un exploitant d'un service proposé par le serveur 14.
Les informations 38 relatives aux structures de requête 40 et de réponse 42 définissant ces structures peuvent être organisées de façon arborescente comme cela est schématisé sur la figure 3. Ainsi, la définition de la structure de requête 40 comprend au moins une définition du mode de la requête, c'est à dire du protocole de transfert de la requête. Cette dernière peut être par exemple de type 44a, conforme au protocole de transfert hypertexte HTTP (acronyme anglais de HyperText Transfer Protocol), ou de type 44b, conforme au protocole SOAP (acronyme anglais de Simple Object Access Protocol). Pour chaque protocole défini, la définition de la structure de requête 40 comprend également une adresse de serveur et une commande.
La définition de la structure de requête 40 peut également comprendre une définition 46 d'au moins un paramètre d'interrogation de la base de données 28 du serveur 14, celui-ci étant identifié par un nom, un type (booléen, entier, chaîne de caractères, etc.) et une unité, s'il est de type numérique. La définition de la structure de requête 40 peut également comporter une définition d'un groupe d'au moins deux paramètres, mis en relation à l'aide d'opérateurs logiques, tels que OU ou ET. Chacun des paramètres de la structure de requête 40 peut être précisé par un commentaire descriptif, une liste de valeurs attendues, une valeur minimale, une valeur maximale et une valeur par défaut. La définition de la structure de requête 40 peut également comprendre une liste d'éléments à inclure dans la réponse, ces éléments étant à choisir parmi tous les éléments que peut fournir le serveur 14 dans la réponse.
La définition de la structure de réponse 42 peut comprendre une définition 48 d'un nom d'une structure de données attendue en réponse, et une définition d'au moins un élément de cette structure, associé éventuellement à un ou plusieurs attributs pouvant prendre des valeurs particulières.
Ainsi, dans le cas d'une base de données répertoriant des valeurs boursières de sociétés, « nom de société » et « pays du marché boursier» peuvent être des éléments. Ces éléments peuvent prendre différentes valeurs « NOM1 », « NOM2 », etc. et « PAYS1 », « PAYS2 », etc. Pour chaque élément, la définition de la structure de réponse 42 peut comprendre une définition d'un nom d'élément, d'un type (booléen, entier, chaîne de caractères, etc.), d'une liste de valeurs possibles, la signification de ces valeurs et d'une unité et d'une cardinalité, c'est-à-dire le nombre d'occurrences d'une identité, uniquement si les valeurs associées à l'élément sont numériques. Les définitions ci-dessus peuvent être appréhendées par le client 12 directement à partir d'un programme capable de comprendre une structure de données en syntaxe XML selon le schéma présenté ci- dessous :
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www. w3. org/2001/XMLSchema " elementFormDefault="qualified"attribυteFormDefault="unqualified">
<xs:import namespace="http://www. w3.org/XML/1998/namespace" schemaLocation="./xml_2001.xsd"/>
<!-- définition de l'élément principal de la structure de requête et de réponse --> <xs:element name="QueryResponseDescription " type="QueryResponseDescriptionType"/>
<xs:complexType name="QueryResponseDescriptionType"> <xs:sequence>
<xs:element name="QueryStructure" type="QueryStructureType"/> <xs:element name="ResponseStructure " type="ResponseStructure Type "/>
</xs:sequence>
<xs:attήbute name="version" type="xs:integer" use="required"/> </-- C'est une séquence de deux éléments: structure de requête puis structure de réponse --> </xs:complexType>
<!-- Description de la structure de requête : au choix requête HTTP ou SOAP --> <xs:complexType name= "QueryStructure Type "> <xs:sequence> <xs:choice> <xs:element name="HTTPQuery" type="HTTPQueryType"/>
<xs:element name="SOAPQuery" type="SOAPQueryType"/> </xs:choice>
<xs:element name="ParameterGroup" type="ParameterGoupType" minOccurs="0"/> </xs:sequence>
</xs:complexType>
<xs:complexType name="HTTPQueryType "> <xs:sequence>
<xs:element name="EntryPoint" type="xs:string" minOccurs="0"/> <xs:element name="Command" type="xs:string" minOccurs="0"/>
</xs:sequence> </xs:complexType> <xs:complexType name="SOAPQueryType ">
<xs:sequence> <xs:element name= "service" type="serviceType"/>
</xs:sequence> </xs:complexType> <xs:complexType name="serviceType">
<xs:sequence> <xs:element name="port" type="portType "/> </xs:sequence>
<xs:attributθ name="name" type="xs:string"/> </xs:complexTypθ> <xs:complθxType name="portTypθ"> <xs:sequence>
<xs:elθment name="SOAPaddress" type="SOAPaddressType"/> </xs:sequence>
<xs:attribute name="name" type="xs:string"/> </xs:complexTypθ> <xs:complθxType name="SOAPaddressType">
<xs:attribute name="location" type="xs:anyURI"/> </xs:complθxTypθ>
<!-- Liste des paramètres de la structure de requête avec groupement possible avec opérateurs AND et OR~> <xs:complexType name="ParameterGoupType"> <xs:sequence>
<xs:choice maxθccurs≈"unbounded">
<xs:element name="Parameter" type="ParameterType"/> <xs:element name="ParameterGroup" type="ParameterGoupType"/> </xs:choice>
</xs:sequence>
<xs:attribute name="binaryBooleanOperator" default="OR"> <xs:simple Type>
<xs:restriction base="xs:string"> <xs:enumeration value="AND"/>
<xs:enumeration value="OR"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType>
<!-- Description sémantique des paramètres de la structure de requête: texte, liste de valeurs, valeur minimale et/ou maximale --> <xs:complexType name="ParameterType ">
<xs:sequence> <xs:element name="Clahfication" type="TextualBaseType" maxθccurs= "unbounded"/>
<xs:element name="Valueϋst" type="ValueListType" minOccurs="0"/> <xs:element name="MinValue" type="xs:string" minOccurs="0"/> <xs:element name="MaxValue" type="xs:string" minOccurs="0"/> <xs:element name="AIIComparisonOperator" type="xs:boolean" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="type"> <xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="xs:anyURI7> <xs:enumeration value="xs:boolean "/> <xs:enumeration value="xs:dateTime"/> <xs:enumeration value="xs:float"/>
<xs:enumeration value="xs:integer"/> <xs:enumeration value="xs:string"/> </xs:restriction> </xs:simple Type> </xs:attributθ>
<xs:attribute name="multipleValue" typθ="xs:boolean" default="false"/> <xs:attribute name="unit" type="xs:string"/> <xs:attribute name="use"> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:enumeration value="optional"/> <xs:enumeration value="required"/> </xs:restriction> </xs:simpleType>
</xs:attribute> <!-- Nom du paramètre --> </-- format du paramètre -->
</-- Possibilité de multiples valeurs ou pas pour le paramètre --> </xs:complexType>
<!-- Possibilité de donner la signification du paramètre en plusieurs langues--> <xs:complexType name="TextualBase Type "> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:attribute ref="xml:lang" use="optional"/>
</xs:extension> </xs:simpleContent> </xs:complexType>
<!-- Description de la structure de réponse --> <xs:complexType name="ResponseStructureType">
<xs:choice>
<xs:element name="SchemaRef" type="xs:anyURI"/> <xs:element name="Element" type="Eementfype"/> <!-- Description de la structure de réponse soit à partir d'un schéma connu soit en décrivant la structure -->
</xs:choice> </xs:complexType>
<!-- Description d'un élément de la réponse avec ses attributs s'il en a --> <xs:complexType name="BementTypθ"> <xs:sequence>
<xs:element name="Clarification" type="TextualBaseType" minOccurs="0" maxOccurs="unbounded"/> <xs:choice>
<xs:element name≈'ValueList" type="ValueListType" minOccurs="0"/> <xs:element name="Bement" type="ElementType" minOccurs="0" maxOccurs="unbounded"/> </xs:choice>
<xs:element name="Attribute" type="AttributeType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="unit" type="xs:string"/> <xs:attribute name="type" type="elementAttributeType"/> <xs:attribute name="number"> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> <xs:enumeration value="unbounded"/> </xs:restriction> </xs:simple Type> </xs:attribute>
<!-- Précision de la sémantique de l'élément de réponse : nom de la balise, son unité, son type, sa multiplicité-^
<!-- Possibilité d'indiquer la présence multiple de l'élément ou son absence possible -->
</xs:complexType>
<xs:complexType name="AttributeType "> <xs:sequence>
<xs:element name="Clarification" type="TextualBaseType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="ValueList" type="ValueϋstType" minOccurs="0"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="unit" type="xs:string"/> <xs:attribute name="type" type="elementAttributeType"/> </xs:complexType>
<!-- Précision du type d'un élément ou d'un attribut d'élément de réponse --> <xs:simpleType name="elementAttributeType">
<xs:restriction base="xs:string">
<xs:enumeration value="xs:anyURI"/> <xs:enumeration value="xs:boolean"/> <xs:enumeration value="xs:dateTime"/> <xs:enumeration value="xs:float"/>
<xs:enumeration value="xs:integer"/> <xs:enumeration value="xs:string"/> </xs:restriction> </xs:s impie Type> </-- Liste de valeurs possibles de l'élément ou d'un attribut d'un élément dans la réponse -->
<xs:complexType name="ValueListType "> <xs:sequence>
<xs:element name="Value" type="ValueType" maxOccurs="unbounded"/> </xs:sequence>
</xs:complexType> <xs:complexType name="ValueType"> <xs:sequence>
<xs:element name="Clarification" type="TextualBaseType" maxOccurs="unbounded"/> </xs:sequence>
<xs:attribute name="content" type="xs:string" use="required"/> <xs:attribute name="defaultValue" type="xs:boolean"/> </xs:complexType> </xs:schema>
La structure générale du fichier de définition contenant la description des structures de requêtes (40) et de réponse (42) est donc la suivante : <QueryResponseDescription> <QueryStructure>
</QueryStructure> <ResponseStructure> </ResponseStructure> </ QueryResponseDescription> Le procédé selon l'invention peut être réalisée par exemple selon les deux modes suivants.
Dans le premier mode de réalisation, le serveur est interrogé à l'aide du protocole de transfert HTTP.
Dans l'exemple de l'interrogation d'un serveur contenant des données boursières, selon ce premier mode de réalisation, la structure de requête 40 présentée dans le fichier de définition, sous la forme d'un programme en langage XML, peut être du type ci- dessous :
<QueryStructure> <!-- requête de type HTTP avec adresse serveur et commande -->
<HTTPQuery>
<EntryPoint>adresseJnternet_serveur</EntryPoint> <Command> table XML</Command> </HTTPQuery> <!-- Description des paramètres de la requête : nom, signification et contenu attendu pour chacun d'eux -->
<ParameterGroup binaryBooleanOperator="AND"> <Parameter name="symbole" multipleValue="true">
<Clarification xml:lang="fr">Choisir le code de la valeur parmi la liste des valeurs indiquées ici. Exemple: "CODE1 " pour "SOCIETE1 "</Clarification> <ValueList>
<Value content="CODE2">
<Clarification>SOCIETE2</Clarification> <A/alue> < Value content≈" CODE1 ">
<Clarification> SOCIETE1</Clarification> <A/alue> </ValueList> </Parameter> <Parameter name="language" use="optional">
<Clarification xml:lang="fr">Langage des éléments en réponse quand plusieurs langues sont disponibles</Clarification> <ValueList>
<Value content="fr" defaultValue="true"> <Clarification>Français</Clarification>
</Value> <Value content="en">
<Clarification>English</Clarification> </Value> </ValueList>
</Parameter> </ParameterGroup> </QueryStructure> Dans le second mode de réalisation, le serveur est interrogé à l'aide du protocole de transfert SOAP.
L'utilisateur client peut donc interroger le serveur à l'aide de ce protocole selon les spécifications suivantes, définissant les entrées et sorties, les codages et les liens à utiliser par les services de données:
<?xml version="1.0"?> «définitions targetNamespace="urn:anyRR:transport:wsdl:2005" xmlns:this="urn:anyRR:transport:wsdl:2005" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">
<documentation> Interface de Service WSDL pour toute API de fournisseur de données. Ce document WSDL définit les appels de I 'API pour le port d'accès </documentation> <!-- Messages d'entrée et de sortie de base. --> «message name="get_Data"> <part name="body" element="this:get_Data"/> </message>
<message name="get_Data_Result"> <part name="body" element="this:get_Data_Result"/> </message>
<message name="ErrorReportMessage "> <part name="body" element="this:ErrorReport"/> </message> <!-- Les différents types de services (ports) avec leurs messages d'entrée et de sortie. --> <portType name="get_Data_Port"> <operation name="getJData"> «nput message="this:get_Data "/> <outputmessage="this:get_Data_Result"/> <fault name="error" message="this:ErroReportMessage"/>
</operation> </portType>
<!-Le "binding" définit comment SOAP/HTTP sont utilises pour transporter le service. --> <binding name="get_Data_SOAP" type="this:get_Data_Port"> <documentation>any data provider getJData binding</documentation> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="get_Data"> <soap:operation soapAction="get_Data"/> <input>
<soap:body use="literal" parts="body"/> </input> <output>
<soap:body use="literal" parts="body"/> </output>
<fault name="error"> <soap:fault use="literal"/> </fault> </operation> </binding> </definitions> W
-14-
La structure de requête présentée dans le fichier de définition se présente alors sous la forme suivante:
<QueryStructure>
</-- requête de type SOAP avec adresse serveur et commande --> <SOAPQuery>
<service name="serveur">
<port name="get_Data_serveur"> <SOAPaddress location="http://adresse_serveur/accesSOAP"/>
</port> </service> </SOAPQuery>
<!-- Description des paramètres de la requête : nom, signification et contenu attendu pour chacun d'eux --> <ParameterGroup> définition des paramètres de même type que pour le premier mode de réalisation </ParameterGroup>
</QueryStructure>
La structure de réponse 42 présentée dans le fichier de définition, sous la forme d'un programme en langage XML, ne dépend pas du protocole utilisé et peut être du type ci-dessous :
<ResponseStructure>
<!-Description de la structure de la réponse à la requête ci-dessus --> <Element name="response"> <Clarification xml:lang="fr">Enveloppe de la réponse</Clarification>
<!-- Description (syntaxe et sémantique) des éléments de premier niveau de la structure de la réponse à la requête ci-dessus -->
<Element name="NomValeur" type="xs:stήng">
<Clarification xml:lang="fr">Nom courant de la valeur</Clarification> </Element>
<Element name="CodeValeur" type="xs:string">
<Clarification xml:lang="fr">Code de la valeur selon la codification "xxxx". Exemple: "CODEV pour "SOCIETE1"</Clarification>
</Element> <Element name="Cours " type="xs:float" unit="EUR">
<Clarification xml:lang="fr">Cours de la valeur en Euros</Clarification> </Element>
<!-- Description d'un élément de premier niveau avec plusieurs valeurs possibles --> <Element name="Conseil" type="xs:integer">
<Clarification xml:lang="fr">Conseil des analystes</Clarification> <ValueList>
<Value content="1">
<Clarification xml:lang="fr"> Vendre</Clarification> </Value>
<Value content="2"> <Clarificationxml:lang="fr">Souspondérer</Clarification> </Value> <Value content="3">
<Clarificationxml:lang="fr">Consθrver</Clarification> </Value>
<Value content="4">
<Clarification xml:lang="fr">Suφondérer</Clarification> </Valuθ>
<Value content="5"> <Clarification xml:lang="fr">Acheter</Clarification>
</Valuθ> <A/alueList> </Element> </Element> </-- Attribut du premier élément (response) du premier niveau -->
<Attribute name≈'VateHeure" type="xs:dateTime">
<Clarification xml:lang="fr">Date et heure du cours de la valeur</Clarification> </Attήbute> </ResponseStructure>
La structure de réponse 42 peut également être du type présenté ci-dessous. Elle diffère du type présenté précédemment en ce qu'elle permet de renvoyer une arborescence d'éléments, et, ainsi, dans le cadre de l'exemple, il est possible de renvoyer des informations boursières sur plusieurs sociétés dans la même réponse :
<ResponseStructure>
<!-- Description de réponse, "response" est l'élément de premier niveau --> <Element name="response">
<Clarification xml:lang="fr">Enveloppe de la réponse</Clarification> <!-- Un seul type d'élément au deuxième niveau mais il peut y avoir plusieurs éléments de ce type dans la réponse -->
<Element name="Valeur" number="unbounded">
<!- Cet élément au deuxième niveau peut apparaître plusieurs fois dans la réponse comme indiqué par number="unbounded" ci dessus --> <!-- Premier élément à l'intérieur de l'élément "Valeur", donc au troisième niveau -->
<Element name="CodeValeur" type="xs:string" >
<Clarification xml:lang="fr">Code de la valeur selon la codification "xxxx". Exemple: "CODEV pour "SOCIETE1"</Clarification> </Element>
<Element name="Cours" type="xs:float" unit="EUR">
<Clarification xml:lang="fr">Cours de clôture de la valeur en Euros</Clarification>
</Element> <Element name="Variation " type="xs:float">
<Clarification xml:lang="fr">variation du cours par rapport au cours de clôture précédent en pourcent</Clarification> </Element>
<Element name="Lien" type="xs:anyURI"> <Clarification xml:lang="fr">URL pour accéder à la page complète des
Echos sur la valeur courante</Clarification> </E\ement> </Element>
<!-- Attribut du premier élément (response) du premier niveau -->
<Attribute name="DateHeure" type="xs:dateTime">
<Clarification xml:lang="fr">Date et heure du cours de la ou des valeurs qui suivent</Clarification> </Attribute> </Element> </ResponseStructure>
On comprend donc que l'étape de fourniture consiste en une fourniture par le premier serveur 14 au client 12 de structures de requête 40 et de réponse 42 conformes à la structure de données en vigueur sur le second serveur 14 ou 14', ces structures étant définies dans un programme en langage de description de données.
A l'aide du fichier fourni par le serveur 14, par exemple du type d'au moins un des programme ci-dessus, le client 12 peut formuler une requête adaptée aux informations qu'il veut obtenir de la part du serveur 14.
La requête dont les éléments ont été explicités par un fichier de définition selon l'exemple peut être formulée à l'aide du protocole de transfert http, de la façon suivante: http://adresseJnternet_serveur/tableXML?symbole=CODE1+CODE2&language=fr. L'utilisateur peut également formuler une requête en choisissant les éléments qu'il veut voir apparaître dans la réponse : http://adresse_lnternet__serveur/tableXML?symbole=CODE1&fields= /response/CodeValeur/Cours/text()+/response/CodeValeur/Variation/text()
Selon le second mode de réalisation, la requête relative à l'exemple peut être formulée de la façon suivante :
<get_Data xmlns=urn:anyRR:transport:2005...> <Query> </-- liste des paramètres dans la requête --> <ParameterGroup BinaryBooleanOperator="AND ">
<Parameter name="symbole" operator≈ΕQ" value="CODE1+CODE2"/> <Parameter name="langue" operator≈ΕQ" value="fr"/>
</ParameterGroup> </Query>
<Fields> </-- liste des champs demandés dans la réponse --> <Field name="/response/Nom Valeur/textQ "/> <Field name="/response/Code Valeur/textQ "/> <Field name="/response/Cours/text() "/> <Field name="/response/Lien/text() "/> </Fields> </get_Data>
Toutefois, pour que les informations 38 définissant les structures de requête 40 et de réponse 42 soient accessibles par un utilisateur qui n'est pas familier des langages informatiques, de préférence, le procédé comprend une étape 50 de présentation au 2
-17-
cours de laquelle le client génère, à l'aide de moyens de présentation 20, une fenêtre contenant par exemple une page HTML, formant une interface donnant accès ou présentant des informations fournies au client 12 par le serveur 14, plus particulièrement présentant les définitions des structures 40, 42. Ces moyens de présentation 20 comprennent un programme d'interface non spécifique au serveur 14, téléchargé et installé au préalable sur le client. L'envoi au client 12 du programme d'interface peut être déclenché à la suite d'une commande de téléchargement volontaire du client 12.
L'envoi au client 12 du fichier de définition avec son type MIME peut être déclenché par l'activation du lien prévue à l'étape 32.
L'exécution du programme d'interface par le client 12 est déclenchée automatiquement par la réception du fichier de définition envoyé par le serveur 14 qui comporte un type MIME ( par exemple :« application/x-QRD-program >>) associé à ce programme. Par exemple, si le programme informatique est destiné à exécuter les fichiers de format « .QRD », l'extension du fichier de définition est « .QRD » et le type MIME correspondant envoyé est alors « application/x-QRD-program ».Ce programme extrait les informations 38 contenues dans le fichier de définition pour créer, dans la page HTML de présentation affichée à l'écran du client 12, des éléments clairs décrivant les informations relatives aux structures de requête 40 et de réponse 42. Les éléments descriptifs des structures 40, 42 apparaissant sur la page Internet sont par exemple des listes de valeurs ou un texte présentant les différents paramètres dans ce mode de réalisation.
De préférence, le programme d'interface crée également, dans la page HTML de présentation affichée à l'écran du client 12, des éléments d'assistance à la formulation de requêtes.
Ainsi, au moins un des éléments descriptifs de la page HTML de présentation peut comprendre une liste d'informations susceptibles de faire partie d'une réponse, les éléments d'assistance à la formulation d'une requête permettant de réaliser un choix parmi les informations de cette liste, par exemple à l'aide de boutons ou d'un champ de saisie.
Le programme d'interface est également utilisé pour décider de la destination des éléments contenus dans la réponse avec conversion éventuelle au codage utilisé chez le client.
L'étape 50 de présentation d'informations est suivie d'une étape 52 au cours de laquelle l'utilisateur client formule une requête à l'attention du serveur 14. Cette étape 52 peut comprendre une sous-étape 54 de formulation de la requête à l'aide des éléments d'assistance à la formulation de requête proposés par le programme d'interface et de moyens classiques tels qu'un élément d'interface 22 du client 12 (clavier, souris, etc.). L'étape 52 peut également comprendre une sous-étape 56 d'incorporation dans la requête de données propres au client 12, plus particulièrement de données contenues dans la base 24 du client 12.
La sous-étape 56 peut être exécutée notamment à l'aide de moyens comportant un logiciel utilitaire non spécifique au serveur 14 stocké sur l'unité centrale 20 du client 12. Après avoir formulé la requête, le client 12 émet cette requête vers le serveur 14, au cours d'une étape 58. Cette transmission peut se faire à la suite d'une action volontaire de l'utilisateur sur le client 12 (sous-étape 60 de l'étape 58) ou automatiquement (sous-étape
62 de l'étape 58).
Ainsi, au cours de la sous-étape 60, l'utilisateur client peut déclencher manuellement la transmission de la requête par exemple en cliquant sur un bouton de la fenêtre de présentation. Au cours de la sous-étape 60, la transmission de la requête est pilotée par des moyens classiques du client comprenant un élément 22 d'interface utilisateur (clavier, souris, etc.) et l'unité centrale 20 du client 12. La requête est transmise au serveur 14 par l'intermédiaire du réseau 16. Au cours de la sous-étape 62, la requête est émise automatiquement par le client 12 vers le serveur 14, par exemple conformément à une séquence programmée par l'utilisateur dans le client 12.
Par exemple, au cours de la sous-étape 62, un formulaire est présenté à l'utilisateur client. Celui-ci indique, en remplissant des champs de saisies ou en cliquant sur des boutons numériques, à quelles échéances la requête doit être transmise automatiquement au serveur 14. Ce formulaire peut être généré par des moyens comprenant un logiciel utilitaire, par exemple le programme d'interface décrit ci-dessus, stocké dans l'unité centrale 20 du client 12.
Au cours de la sous-étape 62, la transmission de la requête est pilotée par des moyens classiques comprenant l'unité centrale 20 du client 12. La requête est transmise au serveur 14 par l'intermédiaire du réseau 16.
Après réception de la requête par le serveur 14, celui-ci la traite et transmet une réponse au client 12 au cours d'une étape 64. La réponse est conforme à la structure de réponse 42, incluse dans le fichier de définition présenté au préalable à l'utilisateur client. Dans le cas de la structure de réponse 42 donnée en exemple, la réponse selon le premier mode de réalisation peut être la suivante : W
-19-
<responsθ DateHθure="2005-02-01T16:41 :00">
<Nom Valeur>SOClETE1</Nom Valeur>
<Code Valeur>CODE1</Code Valeur>
<Cours>23.25</Cours> <Conseil>3</Conseil>
</response>
Selon le second mode de réalisation, la réponse à la requête donnée en exemple est :
<?xml version="1.0" encoding="UTF-8"?> <get_Data_Result ...> <response>
<Nom Valθur>SOCIETE1</Nom Valeur> <Code Valeυr>CODE1</Code Valeur> <Cours>23.25</Cours> <Lien>http://adresse_sθrveur/accesSOAP/symbole=CODE1</Lien>
</response> </get_Data_Result ...>
La réponse peut également être constituée par une arborescence d'éléments permettant de fournir plusieurs données distinctes, si bien qu'un seul envoi par le serveur
14 peut contenir toutes les données requises par le client 12. Le cas échéant, certaines données figurant dans la réponse du serveur 14 et provenant de la base 28 de ce serveur
14 sont affectées, avec conversion éventuelle au codage utilisé chez le client, au cours d'une étape 66, à la base de données 24 du client 12. Cette affectation peut être réalisée par un logiciel utilitaire stocké sur l'unité centrale 20 du client 12.
Le système et le procédé décrits ci-dessus permettent donc à un utilisateur client de générer une requête vers un serveur 14 et d'exploiter au mieux sa réponse quelle que soit la structure de données en vigueur sur ce serveur 14.
Le système d'échange de données selon l'invention ne se limite pas au mode de réalisation décrit ci-dessus.
En particulier, comme illustré en pointillés sur la figure 1 , le système peut comprendre deux serveurs, à savoir le serveur 14 en trait plein (premier serveur) et le serveur 14' en pointillés (second serveur) plutôt qu'un seul et même serveur comme décrit précédemment. Dans cette configuration, le premier serveur 14 fournit au client des informations relatives aux structures de requête et de réponse conformes à la structure de données en vigueur sur le second serveur 14'.

Claims

REVENDICATIONS
1. Procédé d'échange de données entre au moins un premier serveur (14) et un client (12), le procédé étant du type comprenant une étape (52) de formulation d'une requête à l'attention d'un second serveur (14, 14') qui, le cas échéant, peut être le premier serveur, fournissant des données structurées, notamment de type XML, caractérisé en ce qu'il comprend une étape préalable (36) de fourniture par le premier serveur (14) au client (12) d'informations relatives aux structures de requête (40) et de réponse (42) conformes à la structure de données en vigueur sur le second serveur (14, 14').
2. Procédé d'échange de données structurées selon la revendication 1 , caractérisé en ce que les informations (38) relatives à la structure de requête (40), fournies au client (12), comprennent au moins une définition choisie parmi une définition (44a, 44b) d'un protocole de transfert de la requête, une définition d'une adresse de serveur, une définition d'une commande, et une définition (46) d'au moins un paramètre identifié par un nom et un type.
3. Procédé d'échange de données structurées selon la revendication 2, caractérisé en ce que les informations (38) relatives à la structure de requête (40), fournies au client (12), peuvent comprendre : - un groupe d'au moins deux paramètres, mis en relation à l'aide d'opérateurs logiques ;
- pour chaque paramètre, un commentaire descriptif, une liste de valeurs attendues, une valeur par défaut et, si ce paramètre est de type numérique, une unité, une valeur minimale et une valeur maximale; - une liste d'éléments et d'attributs à inclure dans la réponse.
4. Procédé d'échange de données structurées selon les revendications 1 à 3, caractérisé en ce que les informations (38) relatives à la structure de réponse (42), fournies au client (12), comprennent au moins une définition choisie parmi une définition d'un nom (48) de structure de données attendue en réponse et une définition d'au moins un élément de la réponse.
5. Procédé d'échange de données structurées selon la revendication 4, caractérisé en ce que les informations (38) relatives à la structure de réponse (42), fournies au client (12), peuvent comprendre, pour chaque élément, un nom, un type, une liste de valeurs possibles, un commentaire descriptif et, si l'élément est de type numérique, une unité et une cardinalité, associé éventuellement à un ou plusieurs attributs, avec, pour chaque attribut, un nom, un type, une liste de valeurs possibles, un commentaire descriptif et, si l'attribut est de type numérique, une unité et une cardinalité.
6. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 5, caractérisé en ce que l'étape (36) de fourniture d'informations est complétée par une étape de présentation (50) de ces informations à l'aide d'un programme d'interface exécuté par le client (12).
7. Procédé d'échange de données structurées selon la revendication 6, caractérisé en ce que le programme d'interface génère une fenêtre, contenant par exemple une page HTML, présentant ces informations.
8. Procédé d'échange de données structurées selon la revendication 6 ou 7, caractérisé en ce que le programme d'interface présente, d'une part, des éléments descriptifs décrivant les informations (38) relatives aux structures de requête (40) et de réponse (42) et, d'autre part, des éléments d'assistance à la formulation d'une requête.
9. Procédé d'échange de données structurées selon la revendication 8, caractérisé en ce qu'au moins un des éléments descriptifs comprend une liste d'informations susceptibles de faire partie d'une réponse, les éléments d'assistance à la formulation d'une requête permettant de réaliser un choix parmi les informations de cette liste.
10. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 9, caractérisé en ce que l'étape (52) de formulation de requête comprend l'incorporation (56) dans la requête de données propres au client.
11. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend une étape (60) d'émission de la requête vers le second serveur (14, 14') à la suite d'une action volontaire d'un utilisateur sur le client (12).
12. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend une étape (62) d'émission automatique de la requête par le client (12) vers le second serveur (14, 14'), par exemple conformément à une séquence programmée par un utilisateur dans le client (12).
13. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 12, caractérisé en ce que l'étape (36) de fourniture d'informations est déclenchée par une étape (32) d'activation volontaire d'un lien dans une page Internet proposée par le premier serveur (14).
14. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 13, caractérisé en ce qu'il comprend une étape (64) de transmission au client (12) par le second serveur (14, 14') d'une réponse à la requête émise par ledit client (12), la réponse étant conforme à la structure de réponse (42).
15. Procédé de fourniture de données par un serveur (14), caractérisé en ce qu'il comprend une étape de fourniture à un client (12) d'informations (38) relatives aux structures de requête (40) et de réponse (42) conformes à la structure de données en vigueur sur un serveur (14, 14') fournisseur de données structurées.
16. Serveur caractérisé en ce qu'il comprend des moyens (26) de fourniture à un client (12) d'informations (38) relatives aux structures de requête (40) et de réponse (42) conformes à la structure de données en vigueur sur un serveur (14, 14') fournisseur de données structurées.
17. Serveur selon la revendication 16, caractérisé en ce qu'il forme le serveur (14) fournisseur de données structurées.
18. Système comprenant au moins un premier serveur (14) et un client (12) reliés entre eux au moyen d'un réseau (16), le client (12) comportant des moyens (22) de formulation de requête à l'attention d'un second serveur (14, 14'), qui, le cas échéant, peut être le premier serveurA caractérisé en ce que le premier serveur (14) est selon la revendication 15.
19. Client d'un système selon la revendication 18, caractérisé en ce qu'il comprend des moyens de présentation (20) des informations (38) fournies par le premier serveur (14).
20. Client selon la revendication 19, caractérisé en ce qu'il comprend des moyens d'incorporation (20) de données qui lui sont propres dans la requête à l'attention du second serveur (14, 14').
21. Client selon la revendication 19 ou 20, caractérisé en ce qu'il comprend des moyens d'émission (20, 22) de la requête vers le second serveur (14,14'), automatiquement ou à la suite d'une action volontaire d'un utilisateur.
22. Client selon l'une quelconque des revendications 19 à 21 , caractérisé en ce qu'il comprend des moyens d'activation (20, 22) d'un lien dans une page Internet proposée par le premier serveur (14), déclenchant la fournitures des informations (38) par ledit serveur (14) au client (12).
23. Dispositif de fourniture de données, caractérisé en ce qu'il comprend des moyens (26) de fourniture à un client (12) d'informations (38) relatives aux structures de requête (40) et de réponse (42) conformes à la structure de données en vigueur sur un serveur (14, 14') fournisseur de données structurées.
24. Programme pour un ordinateur formant serveur (14) selon la revendication 16, caractérisé en ce qu'il fournit automatiquement au client (12), suite à l'activation d'un lien par ledit client (12), des informations (38) relatives aux structures de requête (40) et de réponse (42) conformes à la structure de données d'un second serveur (14, 14').
25. Programme pour un ordinateur formant un client (12) d'un système selon la revendication 18, caractérisé en ce qu'il génère une interface de présentation d'informations fournies au client (12) par le premier serveur (14).
26. Programme d'ordinateur selon la revendication 25, caractérisé en ce que l'interface générée comprend au moins une fenêtre , contenant par exemple une page HTML, donnant accès ou présentant les informations fournies au client (12) par le premier serveur (14).
27. Programme d'ordinateur selon la revendication 25 ou 26, caractérisé en ce que l'interface générée présente, d'une part, des éléments descriptifs décrivant les informations relatives aux structures de requête (40) et de réponse (42) et, d'autre part, des éléments d'assistance à la formulation d'une requête.
PCT/FR2006/001530 2005-06-29 2006-06-29 Procede d ' echange de donnees entre un serveur et un client , serveur correspondant a ce procede , systeme comprenant ce serveur, client de ce systeme , programmes correspondant a ce procede pour un ordinateur formant serveur et un ordinateur formant client Ceased WO2007003774A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0506670A FR2888069A1 (fr) 2005-06-29 2005-06-29 Procede d'echange de donnees entre un serveur et un client, serveur systeme comprenant ce serveur, client de ce systeme, programmes pour un ordinateur formant serveur et un ordinateur formant client
FR0506670 2005-06-29

Publications (1)

Publication Number Publication Date
WO2007003774A1 true WO2007003774A1 (fr) 2007-01-11

Family

ID=35825342

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/001530 Ceased WO2007003774A1 (fr) 2005-06-29 2006-06-29 Procede d ' echange de donnees entre un serveur et un client , serveur correspondant a ce procede , systeme comprenant ce serveur, client de ce systeme , programmes correspondant a ce procede pour un ordinateur formant serveur et un ordinateur formant client

Country Status (2)

Country Link
FR (1) FR2888069A1 (fr)
WO (1) WO2007003774A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3072811B1 (fr) * 2017-10-19 2022-04-01 Amadeus Sas Partage de criteres de recherche entre de multiples espaces de recherche
EP3698309A1 (fr) * 2017-10-19 2020-08-26 Amadeus S.A.S. Partage de critères de recherche entre des espaces de recherche multiples

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005052811A1 (fr) * 2003-11-27 2005-06-09 International Business Machines Corporation Recherche dans un reseau informatique

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005052811A1 (fr) * 2003-11-27 2005-06-09 International Business Machines Corporation Recherche dans un reseau informatique

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
AGARWAL S ET AL: "Surfing the Service Web", SECOND INTERNATIONAL SEMANTIC WEB CONFERENCE, vol. 2870, October 2003 (2003-10-01), pages 211 - 226, XP002370002, Retrieved from the Internet <URL:http://citeseer.ist.psu.edu/agarwal03surfing.html> [retrieved on 20060227] *
JANECEK J: "Efficient SOAP processing in embedded systems", ENGINEERING OF COMPUTER-BASED SYSTEMS, 2004. PROCEEDINGS. 11TH IEEE INTERNATIONAL CONFERENCE AND WORKSHOP ON THE BRNO, CZECH REPUBLIC 24-27 MAY 2004, PISCATAWAY, NJ, USA,IEEE, 24 May 2004 (2004-05-24), pages 128 - 134, XP010711447, ISBN: 0-7695-2125-8 *
MRISSA M ET AL: "A Mediation Framework for Web Services in a Distributed Healthcare Information System", MEDICAL INFORMATION SYSTEMS: THE DIGITAL HOSPITAL, 2004. IDEAS '04-DH. PROCEEDINGS. IDEAS WORKSHOP ON BEIJING, CHINA 01-03 SEPT. 2004, PISCATAWAY, NJ, USA,IEEE, 1 September 2004 (2004-09-01), pages 15 - 22, XP010779126, ISBN: 0-7695-2289-0 *

Also Published As

Publication number Publication date
FR2888069A1 (fr) 2007-01-05

Similar Documents

Publication Publication Date Title
US7962470B2 (en) System and method for searching web services
World Wide Web Consortium The platform for privacy preferences 1.0 (P3P1. 0) specification
US8676886B2 (en) System and method for dynamically changing the content of an information display
US7890957B2 (en) Remote management of an electronic presence
US8621002B2 (en) System and method for dynamically changing the content of an information display
US9398069B2 (en) Stateless microkernel web server architecture
US20050204047A1 (en) Method and apparatus for partial updating of client interfaces
US20020116494A1 (en) Web page link-tracking system
US20080065974A1 (en) Template-based electronic presence management
EP1193950A2 (fr) Procédé d&#39;optimisation, par un élément d&#39;architecture de réseau, de la consulation de données.
FR2891077A1 (fr) Systeme de mise en oeuvre d&#39;une application metier.
CA2564108A1 (fr) Systeme et procede de tracabilite de contenus sur internet
Al-Masri et al. MobiEureka: an approach for enhancing the discovery of mobile web services
WO2007003774A1 (fr) Procede d &#39; echange de donnees entre un serveur et un client , serveur correspondant a ce procede , systeme comprenant ce serveur, client de ce systeme , programmes correspondant a ce procede pour un ordinateur formant serveur et un ordinateur formant client
RU2676880C2 (ru) Система и способ для обработки информации web-обзора
EP1515522A1 (fr) Procédé d&#39;insertion d&#39;informations de filtrage thématique de pages HTML et système correspondant
US8583697B2 (en) System and method of processing content
CA2368081A1 (fr) Systeme et procede pour fournir un service a un noeud client
EP1494147A1 (fr) Procédé de visualisation d&#39;informations accessibles par l&#39;intermédiaire d&#39;un réseau de télécommunications, serveur et programme pour sa mise en oeuvre
WO2023118770A1 (fr) Système de distribution de contenu internet personnalisé
Falchuk et al. An open service platform for deploying and managing services at network edges
EP1494419A1 (fr) Système de transmission de paramètres caractéristiques d&#39;une session de communication d&#39;un terminal vers un serveur distant
FR2883685A1 (fr) Procede et systeme de partage d&#39;attributs personnels, module de partage/d&#39;insertion/de terminal, fournisseur d&#39;acces internet, serveur proxy, fournisseur de services et programme d&#39;ordinateur pour ce procede
US20060149697A1 (en) Context data transmission
FR3105477A3 (fr) Système de distribution de contenu avec gestion de profil utilisateur

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06778722

Country of ref document: EP

Kind code of ref document: A1