FR2888069A1 - METHOD OF EXCHANGING DATA BETWEEN A SERVER AND A CUSTOMER, SYSTEM SERVER COMPRISING THIS SERVER, CUSTOMER OF THIS SYSTEM, PROGRAMS FOR A COMPUTER FORMING A SERVER AND A COMPUTER FORMING A CLIENT - Google Patents

Abstract

This method of exchanging data between at least a first server (14) and a client (12) comprises a step (52) of formulating a request for a second server (14, 14 ') which , where appropriate, may be the first server, providing structured data, in particular of XML type, and a preliminary step (36) of supply by the first server (14) to the client (12) of information relating to the query structures ( 40) and response (42) in accordance with the data structure in effect on the second server (14, 14 '). Preferably, the information providing step (36) is completed by a presentation step (50). ) of this information by an interface program executed by the client. This program generates an interface for presenting information about query and response structures.

Description

The present invention relates to a method for exchanging structured data

  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.

  It applies in particular to the automatic exploitation by the client of information proposed by the server.

  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.

  It is known to exchange data between a client and a server interconnected by the Internet.

  Thus, in the particular case of a server offering the services of a search engine, 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).

  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.

  To facilitate the automatic obtaining of information by a client, it has been proposed in the state of the art to standardize the presentation of the information provided by a server, for example in accordance with the specifications of the TV-Anytime type or the syndication type. really simple RSS (according to the acronym Really Simple Syndication).

  These specifications make it possible to organize a structured data exchange between a server and a client in extensible XML markup language (in the acronym eXtensible Markup Language).

  However, the definition of the TV-Anytime or RSS type specifications requires a consultation work with interested service providers and relatively important standardization to describe the syntax and semantics of the requests and responses.

  In addition, although the access of a client user to the data is simplified, the user must become familiar with the aforementioned specifications of the data structure before he can use it.

  Finally, the 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.

  For this purpose, 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. 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.

  If necessary, 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.

  On the Internet, these structures are usually independent of the presentation of the HTML page, which usually allows access to the services offered by a server. A modification of the presentation of this page has no consequence on the operation of the data access program.

  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.

  Optionally, this information may also include: a group of at least two parameters, connected by logical operators; - for each parameter, a descriptive comment, a list of expected values, a minimum value, a maximum value and a default value; a list of elements to include in the answer.

  In addition, the response structure information provided to the client includes at least one of 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.

  Advantageously, 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.

  This makes it possible to be able to replace the content of each element at the appropriate place, for example, in a client database, with or without conversion of the coding of the server to the coding at the client, upon reception of the response.

  According to a particular embodiment of the invention, the first and second servers form a single server.

  Optionally, 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 content of this window is usually written in ordinary language, accessible by a user who is not familiar with computer languages.

  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.

  If necessary, 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.

  Thus, 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.

  Optionally, the information presentation step is initiated by the voluntary activation of a link in an Internet page presented by the first server.

  Thus, 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.

  Optionally, 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.

  Optionally, 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.

  Optionally, 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 described above, characterized in that it automatically provides the client with information relating to the query 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.

  Optionally, 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; - presents, 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.

  The invention will be better understood on reading the description which follows, given solely by way of example and with reference to the drawings in which: 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. 35

  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.

  The client 12 comprises a computer comprising a central unit 20 equipped with a processor 20P, a memory 20M, for example RAM (Random Access Memory), and input-output 20A, 20B. 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 comprises a computer comprising a central unit 26 and a data base 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.

  Alternatively, the client 12 and / or the server 14 may comprise several databases. Similarly, the system 10 may include a central server giving access to different servers providing data.

  Below will be described, with reference to FIG. 2, a data exchange method implemented by the system 10.

  In the following, we will call client user, a user of the client 12.

  Initially (preliminary step 30), 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.

  During step 36, conventional means (including in particular the central unit 26 of the server 14) provide the client 12 with information 38 comprising definitions relating to the query and response structures 40 corresponding to the data structure. in force on 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 shown schematically in FIG. 3. Thus, the definition of the request structure 40 comprises at least one definition of the mode of execution. 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). For each defined 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 steps. particular values.

  Thus, in the case of a database listing stock values of companies, company name and country of the stock market may be items. These elements can take different values NAME1, NOM2, etc. and COUNTRY1, COUNTRY2, etc. For each element, 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: <? Xml version = "1.0" encoding = "UTF- 8 "?> <Xs: schema xmins: xs =" http://www.w3.org/2001/XMLSchema "elementFormDefault =" qualified "attributeFormDefault =" unqualified "> <xs: import namespace =" http: // www .w3.org / XML / 1998 / namespace "schemaLocation =" ./xml 2001.xsci '/> <! - definition of the main element of the query and response structure -> <xs: element name = "QueryResponseDescription"

  type = "QueryResponseDescription Type" />

  <xs: complexType name = "QueryResponseDescription Type"> <xs: sequence> <xs: element name = "QueryStructure" type = "QueryStructureType" /> <xs: element name = "ResponseStructure" type = "ResponseStructureType" /> </ xs: sequence> <xs: attribute name = "version" type = "xs: integer" use = "required '/> <1-- This is a sequence of two elements: query structure and response structure -> </ xs: complexType> <! - Description of the request structure: optionally HTTP or SOAP request -> <xs: complexType name = "QueryStructureType"> <xs: sequence> <xs: choice> <xs: element name = "HTTPQuery" type = "HTTPQueryType" I> <xs: element name = "SOAPQuery" type = "SOAPQueryType" I> </ xs: choice> <xs: element narrate = "ParameterGroup" type = "ParameterGoupType" minOccurs = "O" /> </ xs: sequence> </ xs: complexType> <xs: complexType name = "HTTPQueryType"> <xs: sequence> <xs: element name = "EntryPoint" type = "xs: string" minOccurs = "O" /> <xs: element name = "Command" type = "xs: string" minOccurs = "O" /> </ xs: sequence> </ xs: complexType> <xs: co mplexType name = "SOAPQueryType"> <xs: sequence> <xs: element name = "service" type = "service Type" /> </ xs: sequence> </ xs: complexType> <xs: complexType name = "serviceType" <xs: sequence> <xs: element name = "port" type = "portType" /> </ xs: sequence> <xs: attribute name = "name" type = "xs: string" /> </ xs: complexType> <xs: complexType narrate = "portType"> <xs: sequence> <xs: element name = "SOAPaddress" type = "SOAPaddressType '/> </ xs: sequence> <xs: attribute name =" name "type = "xs: string '/> </ xs: complexType> <xs: complexType narrate =" SOAPaddressType "> <xs: attribute name =" location "type =" xs: anyURI "/> </ xs: complexType> <! - - Parameter list of the query structure with possible grouping with AND and OR operators -> <xs: complexType name = "ParameterGoupType"> <xs: sequence> <xs: choice maxOccurs = "unbounded"> <xs: element name = "Parameter" type = "ParameterType'V> <xs: element narrate =" ParameterGroup "type =" ParameterGoupType '/> </ xs: choice> </ xs: sequence> <xs: attribute name = "binaryBooleanOperator" def ault = "OR"> <xs: simpleType> <xs: base restriction = "xs: string"> <xs: enumeration value = "AND" /> <xs: enumeration value = "OR" /> </ xs: restriction> </ xs: simpleType> </ xs: attribute> </ xs: complexType> <! - Semantic description of the parameters of the query structure: text, list of values, minimum and / or maximum value -> < xs: complexType name = "ParameterType"> 25 <xs: sequence> <xs: element name = "Clarification" type = "TextualBaseType" maxOccurs = "unbounded" /> <xs: element name = "ValueList" type = "ValueList Type "minOccurs =" 0 '/> <xs: element name = "Min Value" type = "xs: string" minOccurs = "O" /> <xs: element name = "MaxValue" type = "xs: string" minOccurs = "0" /> <xs: element narrate = "AIIComparisonOperator" type = "xs: boolean" minOccurs = "0 '/> </ xs: sequence> <xs: attribute name =" narrate "type =" xs: string " use = "required '/> <xs: attribute name =" type "> <xs: simpleType> <xs: base restriction =" xs: string "> <xs: enumeration value =" xs: anyURI "/> <xs: enumeration value = "xs: boolean'V> <xs: enumeration value =" xs: dateTime 'V> <xs: enumeration value = "xs: float' /> <xs: enumeration value =" xs: integer '/> <xs: enumeration value = "xs: string'V> </ xs: restriction> </ xs: simpleType> </ xs: attribute> <xs: attribute name = "multiple Value" type = "xs: boolean" default = "false" /> <xs: attribute name = "unit" type = "xs: string" /> <xs: attribute name = "use"> <xs: simpleType> <xs: base restriction = "xs: string"> <xs: enumeration value = "optional" /> <xs: enumeration value = "required" / > </ xs: restriction> </ xs: simpleType> </ xs: attribute> <! - Parameter name -> <! - parameter format -:> <! - Possibility of multiple values or not for the parameter -> </ xs: complexType> <! - Ability to give the meaning of the parameter in multiple languages -> <xs: complexType name = "TextualBaseType"> <xs: simpleContent> <xs: extension base = "xs : string "> <xs: attribute ref =" xml: lang "use =" optional "/> </ xs: extension> </ xs: simpleContent> </ xs: complexType>

  <! - Description of the response structure ->

  <xs: complexType name = "ResponseStructureType"> <xs: choice> <xs: element name = "SchemaRef" type = "xs: anyURl" /> <xs: element name = "Element" type = "ElementType" /> < ! - Description of the response structure either from a known schema or by describing the structure -> </ xs: choice> </ xs: complexType> <! - Description of an element of the response with its attributes if it has -> <xs: complexType name = "ElementType"> <xs: sequence> <xs: element name = "Clarification" type = "TextualBaseType" minOccurs = "O" maxOccurs = "unbounded" / <xs: choice> <xs: element name = "ValueList" type = "ValueListType" minOccurs = "0" /> <xs: element name = "Element" type = "ElementType" minOccurs = "O" maxOccurs = "unbounded "/> </ xs: choice> <xs: element name =" Attribute "type =" Attri bute Type "minOccurs =" O "maxOccurs =" unbounded "/> </ xs: sequence> <xs: attribute name =" name "type =" xs: string "use =" required '/> <xs: attribute name = "type" type = "xs: string" /> <xs: attribute name = "type" type = "elementAttributeType" /> <xs: attribute name = "number"> <xs: simpleType> <xs: base restriction = "xs: string"> <xs: enumeration value = "0" /> <xs: enumeration value = "1" /> <xs: enumeration value = "unbounded" /> </ xs: restriction> </ xs: simpleType> </ xs: attribute> <! - Precision of the semantics of the response element: name of the tag, its unit, its type, its multiplicity -> <! - Possibility of indicating the multiple presence of the element or its possible absence -> </ xs: complexType> <xs: complexType name = "AttributeType"> <xs: sequence> <xs: element narre = "Clarification" type = "TextualBaseType" minOccurs = "O" maxOccurs = "unbounded" /> <xs: element name = "Va, readList" type = "ValueListType" 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> <! - Type Accuracy of an Element or Response Item Attribute -> <xs: simpleType narrate = "elementAttributeType"> <xs : restriction b ase = "xs: string"> <xs: enumeration value = "xs: anyURl" /> xs: enumeration value = "xs: boolean" /> <xs: enumeration value =: "xs: da teTime'Y> < xs: enumeration value = "xs: float" /> <xs: enumeration value == "xs: integer '/> <xs: will enumerate fion value =" xs: string' /> </ xs: restriction> </ xs: simpleType> <! - List of possible values of the element or attribute of an element in the response -> <xs: complexType name = "ValueListType"> <xs: sequence> <xs: element name = " Value "type =" Value Type "maxOccurs =" unbounded "/> </ xs: sequence> </ xs: complexType> <xs: complexType name =" Value Type "> <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> The general structure of the definition file containing the description of the query (40) and response (42) structures is therefore the next:

<QueryResponseDescription>

  <QueryStructure> </ QueryStructure> <ResponseStructure>

  </ ResponseStructure> </ QueryResponseDescription>

  The process according to the invention can be carried out for example according to the two following modes.

  In the first embodiment, the server is queried using the HTTP transfer protocol.

  In the example of the interrogation of a server containing stock data, according to this first embodiment, the request structure 40 presented in the definition file, in the form of a program in XML language, may be the same. type below: <QueryStructure> <! - HTTP request with server address and command -> <HTTPQuery> <EntryPoint> server Internet address </ EntryPoint> <Command> XML table </ Command> </ HTTPQuery> <! - Description of the parameters of the request: name, meaning and expected content for each one -> <ParameterGroup binaryBooleanOperator = "AND"> <Parameter name = "symbol" multipleValue = "true"> <Clarification xml: lang = "en"> Choose the value code from the list of values shown here. Example: "CODE" for "COMPANY" </ Clarification> <ValueList> <Value content = "CODE2"> <Clarification> COMPANY2 </ Clarification> </ Value> <Value content = "CODE1"> <Clarification> COMPANY1 </ Clarification> </ Value> </ ValueList> </ Parameter> <Parameter name = "lanquage" use = "optional"> <Clarification xml: lang = "en"> Language of the elements in response when several languages are available </ Clarification > <ValueList> <Value content = "en" defaultValue = "true"> <Clarification> English </ Clarification> </ Value> <Value content = "in"> <Clarification> English </ Clarification> < / Value> <NalueList> </ Parameter> </ ParameterGroup> </ QueryStructure> In the second embodiment, 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: <? Xml version = "1.0"?> <definitions targetNamespace = "urn: anyRR: transport: wsdl: 2005" xmins: this = "urn: anyRR: transport: wsdl: 2005" xmlns: soap = "http://schemas.xmlsoap.org/wsdl/soap/" xmlns = "http: // schemas.xmlsoap.org/wsdl/"> <documentation> WSDL Service Interface for any Data Provider API.

  This WSDL document defines API calls for access port </ documentation> <! - Basic input and output messages. -> <message name = "get Data"> <part name = "body" element = "this: get Data" /> </ message> <message name = "get Data_Result"> <part name = "body" element = "this: geLData_Result" /> </ message> <message name = "ErrorReportMessage"> <part name = "body" element = "this: ErrorReport '/> </ message> <! - The different types of services ( ports) with their input and output messages -> <port Type name = "get Data_Port"> <operation name = "get Data <input message =" this: get Data "/> <output message =" this : get Data Result "/> <fault name =" error "message =" this: ErroReportMessage '/> </ operation> </ portType> <I-The "binding" defines how SOAP / HTTP is used to transport the service. -> <binding name = "get Data_SOAP" type = "this: get Data_Port"> <documentation> any data provider get Data binding </ documentation> <soap: binding style = "document" transport = "http: // schemas .xmlsoap.org / soap / http'V> <operation name = "get Data"> <soap: operation soapAction = "get Data" /> <input> <soap: body use = "literal" parts = "body" /> </ input> <output> <soap: body use = "Iiteral" parts = "body" /> </ output> <fault name = "error"> <soap: fault use = "literal" /> </ fault> </ operation> </ binding> </ definitions> The query structure presented in the definition file is then in the following form: <QueryStructure> <! - SOAP type request with server address and command - > <SOAPQuery> <service name = "server"> <port name = "get Server_data"> <SOAPaddress location = "http: // server_address / accessSOAP" /> </ port> </ service> </ SOAPQuery> <I - Description of the parameters of the request: name, meaning and expected content for each of them -> <ParameterGroup> definition of parameters of the same type as for the first embodiment </ ParameterGroup> 15 </ QueryStructure> The structure The response 42 presented in the definition file, in the form of a program in XML language, does not depend on the protocol used and can be of the type below: <ResponseStructure> <I - Description of the structure of the response to the query above -> <Element name = "response"> <Clarification xml: lang = "en"> Envelope of the answer </ Clarification> <1-- Description (syntax and semantics ) first-level elements of the structure of the query response above -> <Element name = "Name Value" type = "xs: string"> <Clarification xml: lang = "en"> Current name of the value </ Clarification> </ Element> <Element name = "Code Value" type = "xs: string"> <Clarification xml: lang = "en"> Code of the value according to the coding "xxxx". Example: "CODE" for "COMPANY" </ Clarification> </ Element> <Element name = "Course" type = "xs: float" unit = "EUR"> <Clarification xml: lang = "en"> Course of the value in Euros </ Clarification> </ Element> <I-Description of a top-level element with several possible values -> <Element name = "Tip" type = "xs: integer"> <Clarification xml: lang = "en"> Analyst Advice </ Clarification> <ValueList> <Value content = "l"> <Clarification xml: lang = "en"> Sell </ Clarification> </ Value> <Value content = "2"> < Clarification xml: lang = "en"> Underweight </ Clarification> </ Value> <Value content = "3"> <Clarification xml: lang = "en"> Retain </ Clarification> </ Value> <Value content = " 4 "> <Clarification xml: lang =" en "> Overweight </ Clarification> 45 50 </ Value> <Value content =" 5 "> <Clarification xml: lang =" en "> Buy </ Clarification> </ Value > <NalueList> </ Element> </ Element> <! - Attribute of the first element (response) of the first level -> <Attribute name = "DateTime" type = "xs: dateTime"> <Clarifica xml: lang = "en"> Date and time of the value course </ Clarification> </ Attribute> </ ResponseStructure> The response structure 42 can 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, within the framework of the example, it is possible to return information on several companies in the same answer: <ResponseStructure > <! - Response description. "response" is the first-level element -> <Element name = "response"> <Clarification xml: lang = "en"> Response Envelope </ Clarification> <! - Only one type of element at second level but there may be several elements of this type in the response -> <Element name = "Value" number = "unbounded"> <I-- This element at the second level may appear multiple times in the response as indicated by number = "unbounded" above -> <! - First element inside the element "Value", therefore at the third level -> <Element name = "Code Value" type = "xs: string" > <Clarification xmislang = "en"> Code of the value according to the coding "xxxx". Example: "CODE1" for "COMPANY" </ Clarification> </ Element> <Element name = "Quote" type = "xs: float" unit = "EUR"> <Clarification xmislang = "en"> Closing price of the value in Euros </ Clarification> </ Element> <Element name = "Variation" type = "xs: float"> <Clarification xml: lang = "fr"> Price variation compared to the previous closing price in percent </ Clarification> </ Element> <Element name = "Link" type = "xs: anyURI"> <Clarification xml: lang = "en"> URL to access the complete Echos page on the current value </ Clarification> </ Element> </ Element> <! - Attribute of the first element (response) of the first level -> <Attribute name = "DateTime" type = "xs: dateTime"> <Clarification xml: lang = "en"> Date and time of the course or values that follow </ Clarification> </ Attribute> </ Element> </ ResponseStructure> Using the file provided by the server 14, for example the type of at least one of the programs ci above, the client 12 can formulate a request adapted to the information that he wants to get from the server 14.

  The query whose elements have been clarified by a definition file according to the example can be formulated using the http transfer protocol, as follows: http: // address lnternet seiner / tableXML? Symbol = CODE + CODE2 & language = en.

  The user can also make a request by choosing the elements he wants to appear in the response: http: // address lnternetserveur / tableXML? Symbol = CODE1 & fields = / response / Code Value / Course / text () + / response / Code Value / Varia tion / text (According to the second embodiment, the request for the example can be formulated as follows: <get Data xmins = urn: anyRR: transport: 2005 ...> <Query> < 1-- list of parameters in the query -> <ParameterGroup BinaryBooleanOperator = "AND"> <Parameter name = "symbol" operator = "EQ" value = "CODE1 + CODE2 '%> <Parameter name =" language "operator = "EQ" value = "en" /> </ ParameterGroup> </ Query> <Fields> <1-- list of requested fields in the response -> <Field name = '/ response / Name Value / text ()' 7> <Field name = '/ response / Code Value / text (' /> <Field name = '/ response / Course / text () "/> <Field name =' / response / Link / text ()" /> </ Fields> </ get Data> However, for the information 38 defining the query structures e 40 and response 42 are accessible by a user who is not familiar with computer languages, preferably the method comprises a presentation step 50 during which the client generates, using 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 having the definitions of the structures 40, 42.

  These 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 receiving the definition file sent by the server 14 which includes a MIME type (for example: application / x-QRDprogram) associated with this program. For example, if the computer program is intended to run the .QRD format files, the extension of the definition file is .QRD and the corresponding MIME type sent is then application / x-QRD-program. This program retrieves the information. 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 of the structures 40, 42 appearing on the Internet page are, for example, lists of values or a text presenting the various parameters in this embodiment.

  Preferably, the interface program also creates, in the presentation HTML page displayed on the client screen 12, assistance elements for the formulation of requests.

  Thus, 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, during a step 58. This transmission can be done as a result of a voluntary action by the user on the client 12 (substep 60 of step 58) or automatically (substep 62 of step 58).

  Thus, during the substep 60, the client user can manually trigger the transmission of the request for example by clicking a button of the presentation window. During the substep 60, 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.

  During the substep 62, the request is automatically sent by the client 12 to the server 14, for example according to a sequence programmed by the user in the client 12.

  For example, in the substep 62, 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.

  During the sub-step 62, 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.

  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. In the case of the response structure 42 given as an example, the response according to the first embodiment can be as follows: <response DateTime = "200502-01 T16: 41: 00"> <Name Value> SOCI SUM 1 </ Name Value> <ValueCode> CODE1 </ ValueCode> <Course> 23.25 </ Course> <Tip> 3 </ Tip> </ response> According to the second embodiment, the response to the example query is: <? xml version. "1.0" encoding = "LITF-8"?> <geLData_Result ...> <response> <Name Value> COMPANY1 </ Name Value> <Code Value> CODE1 </ ValueCode> <Course> 23.25 </ Course > <Link> http: // server address / accesSOAP / symbol = CODE1 </ Link> </ response> </ get Data_Result ...> The response can also be constituted by a tree of elements allowing to provide several distinct data so that a single sending by the server 14 can contain all the data required by the client 12. If necessary, some data in the server response 14 and from the base 28 of this s 14 are assigned, with possible conversion to the encoding used in the client, during a step 66, to the database 24 of the client 12. This assignment can be performed by a utility software stored on the CPU 20 of the customer 12.

  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.

  In particular, as illustrated in dashed lines in FIG. 1, 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. In this configuration, 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 '.

Claims (25)

  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 a second server (14, 14 ') which, if necessary, can be the first server, providing structured data, in particular of the XML type, characterized in that it comprises a preliminary step (36) of provisioning by the first server (14) to the client (12) information relating to the request (40) and response (42) structures conforming to the data structure in effect on the second server (14, 14 ').   A method for exchanging structured data according to claim 1, characterized in that the information (38) relating to the request structure (40) supplied to the client (12) comprises at least one definition selected from a definition ( 44a, 44b) of a request transfer protocol, a definition of a server address, a definition of a command, and a definition (46) of at least one parameter identified by a name and a type.   A method for exchanging structured data according to claim 2, characterized in that the information (38) relating to the request structure (40) provided to the client (12) may comprise: - a group of at least two parameters, connected using logical operators; for each parameter, a descriptive comment, a list of expected values, a default value and, if this parameter is of numeric type, a unit, a minimum value and a maximum value; - a list of elements and attributes to include in the response.   A method for exchanging structured data according to claims 1 to 3, characterized in that the information (38) relating to the response structure (42) provided to the client (12) comprises at least one definition selected from a defining a data structure name (48) expected in response and a definition of at least one element of the response.   A structured data exchange method according to claim 4, characterized in that the information (38) relating to the response structure (42) provided to the client (12) may 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, possibly associated with one or more attributes, with, for each attribute, a name, a type, a list of possible values, a descriptive comment and, if the attribute is of numeric type, a unit and a cardinality.   6. Method for exchanging structured data according to any one of claims 1 to 5, characterized in that the step (36) of providing information is completed by a step of presenting (50) this information to the user. using an interface program executed by the client (12).   7. structured data exchange method according to claim 6, characterized in that the interface program generates a window, for example containing an HTML page, presenting this information.   Method for the exchange of structured data according to claim 6 or 7, characterized in that the interface program has, on the one hand, descriptive elements describing the information (38) relating to the request structures (40) and response (42) and, on the other hand, assistance elements in formulating a request.   9. Method for exchanging structured data according to claim 8, characterized in that at least one of the descriptive elements comprises a list of information likely to be part of a response, the elements of assistance to the formulation of a request to make a choice among the information in this list.   A structured data exchange method according to any one of claims 1 to 9, characterized in that the query formulation step (52) comprises embedding (56) in the request data specific to the client.   11. structured data exchange method according to any one of claims 1 to 10, characterized in that it comprises a step (60) for transmitting the request to the second server (14, 14 ') to the following a voluntary action by a user on the client (12).   12. Method for exchanging structured data according to any one of claims 1 to 10, characterized in that it comprises a step (62) of automatic transmission of the request by the client (12) to the second server ( 14, 14 '), for example according to a sequence programmed by a user in the client (12).   13. Method for exchanging structured data according to any one of claims 1 to 12, characterized in that the step (36) of providing information is triggered by a step (32) of voluntary activation of a link in an Internet page proposed by the first server (14).   14. structured data exchange method according to any one of claims 1 to 13, characterized in that it comprises a step (64) of transmission to the client (12) by the second server (14, 14 ') d a response to the request issued by said client (12), the response being in accordance with the response structure (42).   A server characterized in that it comprises means (26) for providing a client (12) with information (38) relating to the request (40) and response (42) structures conforming to the data structure. force on a server (14, 14 ') structured data provider.   16. Server according to claim 15, characterized in that it forms the server (14) providing structured data.   17. System comprising at least a first server (14) and a client (12) interconnected by means of a network (16), the client (12) having means (22) for formulating a request for attention a second server (14, 14 '), which, where appropriate, may be the first server, characterized in that the first server (14) is according to claim 15.   18. Customer of a system according to claim 17, characterized in that it comprises presentation means (20) of information (38) provided by the first server (14).   19. Client according to claim 18, characterized in that it comprises means of incorporation (20) of data specific to it in the request to the attention of the second server (14, 14 ').   20. Customer according to claim 18 or 19, characterized in that it comprises means for transmitting (20, 22) the request to the second server (14, 14 '), automatically or as a result of an action volunteer of a user.   21. Customer according to any one of claims 18 to 20, characterized in that it comprises means for activating (20, 22) a link in an Internet page proposed by the first server (14), triggering the providing information (38) by said server (14) to the client (12).   22. Program for a server computer (14) according to claim 15, characterized in that it automatically provides the customer (12), following the activation of a link by said customer (12), information (38). ) relating to the request (40) and response (42) structures conforming to the data structure of a second server (14, 14 ').   23. Program for a computer forming a client (12) of a system according to claim 17, characterized in that it generates an information presentation interface provided to the client (12) by the first server (14).   24. Computer program according to claim 23, characterized in that the generated interface comprises at least one window, for example containing an HTML page, giving access to or presenting the information provided to the client (12) by the first server (14). ).   25. Computer program according to claim 23 or 24, characterized in that the generated interface has, on the one hand, descriptive elements describing the information relating to the request (40) and response (42) structures and, on the other hand, elements of assistance with the formulation of a request.