FR2973534A1 - Method for optimizing searches on data accessible via simple object access protocol-web service definition language web service, involves translating Meta-SQL query to build SQL query on tables in relational database and execute SQL query - Google Patents

Abstract

The method involves obtaining a web service definition language document of a web service (100), and creating tables (200) in a relational database. A Meta-SQL query is constructed (250). Input parameters and operations to be performed are defined and validated (275). The Meta-SQL query is translated (300) to construct and execute a Simple Object Access Protocolrequest to the web service. Response from the web service is collected (400) and stored in the tables. The SQL query is translated (500) to construct an SQL query on the tables, and to execute the SQL query. The request is expressed by pre-defined writing rules using SQL or JavaScript Object Notationlanguage.

Description

The present invention belongs to the field of computing and in particular to research on data accessible via a web service SOAP-WSDL (acronym for "Simple Object Access Protocol - Web Service Definition Language").

Preamble Web services represent a communication mechanism between remote applications, through a network independent of any programming language and any execution platform. Web services are used to transmit computer data through a computer network from one computer to another using, in particular, HTTP and / or HTTPS as a means of transport. These web services use an XML Markup Language (eXtensible Markup Language) syntax to describe remote function names, input and output parameters for these remote functions. These web services organize the call and answer mechanisms of these remote functions. The basic standards used by web services are the SOAP protocol and WSDL formalism standardized by the W3C (World Wide Web Consortium).

SOAP is an Internet protocol that allows communication between applications for access to web services. The WSDL formalism is a standard notation for the description of a web service. An advantage of a web service is on the one hand its independence with regard to the programming languages and of any platform of execution and on the other hand its ease of operation due to the use of the protocol HTTP (and / or HTTPS ) to pass through many firewalls without requiring changes to the filtering rules. We understand that a lot of data in the computer world are available through this. A disadvantage of a web service is that it presents formatted responses according to what was planned during its implementation (coding). A filtering of these responses, an order, a grouping, and / or an operation can only be performed if one or more input parameters allow it. Due to this disadvantage, the user of a web service can not, in general, directly obtain the optimal response that is filtered, ordered and / or grouped to his needs, being limited by the weakness of the interrogations that can be transmitted to the web service. For example, consider a web service that provides a list of employees in a company (Last Name, Last Name, Company Entry Date) with the only non-mandatory entry parameter, the name of an employee and a user who is looking for only employees, sorted alphabetically First name, whose entry date is between a specific date and another date. We understand that the call to the web service will not directly provide the exact answer to his need. It will be necessary for the user to recover all the data, delete the lines that do not correspond to the chosen selection and then sort the remaining lines by ordering them according to the alphabetical order of the first name and the name.

OBJECTS OF THE INVENTION The problem that arises is therefore to propose a method of querying data accessible only via a web service which automatically provides a user with a response that meets his or her needs which may be complex, this method operating for any service. web.

DISCLOSURE OF THE INVENTION The present invention aims at a search optimization method accessible to a user of at least one SOAP-WSDL web service of any kind, said access being realized through a computer system, said computer system being able to access at least a relational database and said concerned SOAP-WSDL web service, this user having defined a request on data accessible by this SOAP-WSDL web service. The method uses previously defined writing rules, making it possible to express the request to be made, and comprises the following steps: - validation of the input parameters of the process consisting on the one hand of or Internet addresses (s) allowing to access the WSDL document (s) of the web service (s), - to create tables in a relational database, - to construct a SQL meta-query involving both the call to the method (s) of the web service (s) (SOAP), as well as the tables previously constructed (SQL), - presentation to the user of the request so that he / she defines his / her input parameters as well as the operations it wishes to perform on the returned data; then validation of this request, - execution of one or more request (s) SOAP to be made on the service (s) web, - recovery of the response (s) of the service (s) (s) ) web and storage of this or these response (s) in the previously built tables, - execution of an SQL query to be performed on previously built tables, - creation of the process response, - destruction of tables previously built .

The use of a database in the process makes it possible to use the power of the SQL language to obtain a result that meets the needs of the user of the process. It is recalled that in the field of computer science, the manipulation of computer data, that is to say a specific extraction, a sorting a grouping, is generally performed optimally by querying a relational database with a powerful language called SQL (Structured Query Language) language.

According to a preferred embodiment, the writing rules making it possible to express the request to be made use the SQL language.

According to another preferred embodiment, the writing rules making it possible to express the request to be made use the JSON (JavaScript Oriented Notation) language.

According to another embodiment, the writing rules are coded with a language making it possible to express any request.

According to a preferred embodiment, the step of creating tables in the relational database follows a logic for the creation data model of these tables to automatically make the relationship between an output entity in the WSDL document and a column in a table. We understand the interest of the construction logic of the data model which is to make the process automatic and independent of the web service.

According to a preferred embodiment, the response of the method is provided in the form of a csv file. We understand that it is sufficient to read this file csv with a conventional spreadsheet to view the answer. According to a preferred embodiment, the response of the method is provided in the form of an XML file. The XML standard is widely used in the computer world, it is understood that a response formatted by this standard may be relevant. DESCRIPTION OF THE FIGURES The characteristics and advantages of the invention will be better appreciated thanks to the description which follows, a description which sets out the characteristics of the invention through a nonlimiting example of application. The description is based on the appended figures in which: FIG. 1 schematically represents an exemplary computer environment implemented in a particular mode of the method which is the subject of the present invention; FIG. 2 represents in the form of FIG. a logic diagram, steps implemented in a particular embodiment of the method object of the present invention.

DETAILED DESCRIPTION OF ONE EMBODIMENT OF THE INVENTION As seen in FIG. 1, a search optimization method according to the invention can be implemented in an application 1 hosted in an accessible application server 2. by a user-client 3 directly or via the Internet or intranet, via a user interface 4. This application server 2 must be able to: - first, access, for example via HTTP or HTTPS, to a web service 5 that user-client 3 wishes to interrogate, and, secondly, to access a database 6 located in a local or remote DBMS with appropriate access rights for creating, deleting, updating tables. There may be several user-clients 3, as well as there may be several application servers 2 hosting application 1, which access the same database 6.

As seen in Figure 1, the application 1 uses as input parameters, provided by the interface 4: - an Internet address 7 to obtain the WSDL document 8 of the web service 5 that the user-client 3 wants to interrogate. - And a request 9 of the client-user 3 written according to writing rules 21 explained later. The application 1 has as output an answer considered optimal 10 to the request 9.

The WSDL document 8 obtained by calling the Internet address 7 via HTTP or HTTPS is an XML type file encoded according to the WSDL formalism. The syntax, the manipulation, the decoding of an XML file is known to those skilled in the art. The reading (decoding) of this document WSDL 8 makes it possible in particular to know: the name of each of the methods (that is to say functions) managed by the web service 5 the name or the names of the input parameters, their type for each method, their mandatory nature or not the name and the type of result for each method. the location of the web service 5, ie the Internet address allowing access to the web service. The type of input parameter, or result of the method, can be either a simple type (integer, real, string of characters ...), or a complex type (simple type of composite data structure, table composed of simple type, table composed of complex data structure .. etc.) Examples, in no way limiting, given below, make it possible, on the one hand, to better understand simple types and complex types, and on the other hand will be used later to better understand the search optimization process. Example El: name of the method: name = "Method1" result of the method described in the WSDL 8 document: name = "Method 1 Result" type = "s: string" simple type input parameter in the WSDL document 8 not required: <s: element minOccurs = "0" maxOccurs = "1" name = "param1" type = "s: string" /> The equivalent in an object-oriented language of this example El is: Public String Methodl (String param1); Example E2: name of the method: name = "Method2" result of the method in the WSDL 8 document: name = "Method2Result" type = "tns: Address" The Address structure is defined in the WSDL 8 document by <s: complexType name = "Address" <s: sequence> <name = "Street" type = "s: string" ..> <name = "City" type = "s: string" ..> 35 <name = "ZipCode" type = "S: int" ..> </ s: sequence> </ s: complexType non-mandatory complex type input parameter: <s: element minOccurs = "0" maxOccurs = "1" name = "param1" type = "Tns: Person" /> the Person structure being defined in the document WSDL 8 by <s: complexType name = "Person" <s: sequence> <s: element minOccurs = "O" maxOccurs = "1" name = " LastName »type =" s: string "..> /> <s: element minOccurs =" O "maxOccurs =" 1 "name =" FirstName "type =" s: string "..> /> <s: element minOccurs = "1" maxOccurs = "1" name = "BithDate" 15 type = "s: dateTime" ..> /> </ s: sequence> </ s: complexType> The object-oriented equivalent of this example e E2 is: Public Address Method2 (Person param1); With: Public class Person {public String LastName; public String FirstName; public String BirthName; Public class Address {public String Street; Public String City; public String ZipCode; } 35 Example E3: name of the method: name = "Method3" result of the method in the WSDL 8 document: name = "Method3Result" type = "tns: ArrayOfString" 10 25 30 input parameter: narrate = "param1" type = "tns: ArrayOfString" The equivalent in an object-oriented language of this example E3 is: Public String [] Method3 (String [] param1); Example E4: Name of the method: name = "Method4" result of the method in the WSDL 8 document: name = "Method4Result" type = "tns: ArrayOfAddress" of the method in the WSDL 8 document: name = "Method4Result" type = "tns: ArrayOfAddress" The ArrayOfAddress type is defined in the WSDL 8 document by <s: complexType name = "ArrayOfAddress" name = "Address" type = "tns: Address" </ s: sequence> </ s: complexType > input parameter: narre = "param1" type = "tns: ArrayOfPerson" The object-oriented equivalent of this example E4 is: Public Address [] Method4 (Person [] param1); Example E5: 25 method name: name = "GetSport" result of the method in the WSDL 8 document can be name = "GetSport Result" type = "tns: ArrayOfSport" the ArrayOfSport type being defined in the WSDL document 8 by 30 <s: complexType name = "ArrayOfSport" name = "Name" type = "s: string" name = "PracticeAddress" type = "tns: Address" </ s: sequence> </ s: complexType> 35 input parameter mandatory: narre = "param1" type = "tns: Persian" 15 20 The equivalent in an object-oriented language of this example E5 is: Public Sport [] Method5 (Person param1); With Public class Sport {public String Name; public Address PracticeAddress; } The request 9 is written either directly by the client-user 3 is built by the user interface 4 following the need of the client-user 3. The request 9 must follow writing rules 21 in order to be decoded by the 1. These writing rules 21 must be able to express complex queries if necessary. A method according to the invention proposes a SQL standard language for the writing rules 21 making it possible to formulate the request 9. In the case of the example E1, the request 9 could be SELECT Method1. "Value" FROM Method 1. " parameters »parameters, Method1 Method1 The query 9 could also be, if we want to filter at param1: SELECT Method1." value "FROM Method 1." parameters "parameters, Method1 Method1 WHERE parameters." paraml "= 'string1' In the case of example E2, query 9 could be SELECT Method 2. "Street", Method 2. "City", Method 2. "ZipCode" FROM Method 2. "parameters" parameters, Method2 Method2 WHERE parameters. "paraml .LastName" = 'Dupont' AND parameters' param1.FirstName '=' Alain 'AND parameters.' Paraml.BithDate '= {ts 2010-11-03: 20: 17'} In the case of example E3, query 9 could SELECT Method3. "value" FROM Method3. "parameters" parameters, Method3 Method3 WHERE parameters. "paraml.String [0]" = 'string1' AND by ameters. "paraml.String [1]" = 'string2' The needs expressed in the previously mentioned sample requests 9 lead to answers that could be obtained directly by calling the web service 5. Let's modify this need with example E2 . SELECT Method 2. "Street", Method 2. "City", Method 2. "ZipCode" FROM Method 2. "parameters" parameters, Method2 Method2 WHERE parameters. "Paraml.BithDate" = {ts'2010-11-03: 20: 17 ' } AND Method2. "City", = 'Paris' ORDER BY Method2. "Street" We see that this need: filtering according to the city and sorting according to the street, could not be expressed in a direct call to the web service. As can be seen in FIG. 2, a search optimization method according to the invention can be broken down into steps as follows: Step 100: obtaining the WSDL document (s) from the service (s) that the user wishes call. Step 200: Building Tables in the Relational Database, Step 250: Constructing a SQL 9 Meta-query involving the SELECT statement and including: - in its FROM clause the reference to one or more methods of one or more web services - in its WHERE clause the input parameters of the methods of the web services involved in the FROM clause Step 275: presentation of the request to the user so that he defines his input parameters as well as the operations he wish to achieve on the returned data; then validation of the request 9. Step 300: Translation of the SQL meta-query for construction and execution of the SOAP call to the method, Step 400: Data retrieval in the tables built in step 200, Step 500: Translation the SQL meta-query for constructing an SQL query on the tables built in step 200 and executing said SQL query, Step 600: constructing the result 10, Step 700: Destroying the tables built in step 200,

A search optimization method according to the invention, when it is implemented by a user-client 3 via an interface 4, begins with a step 100 which consists initially in obtaining the document (s) WSDL 8 containing the description WSDL of the service (s) web 5 which interests (s) the user-client 3, by calling via the HTTP or HTTPS the Internet address (es) 7 provided by the user-client 3 via the interface 4.

If the Internet address (es) 7 are not accessible or if the page (s) returned (s) do not correspond to a WSDL document, step 100 returns an error code and the process is stopped.

At the end of step 100, for each web service, the list of available methods is presented to the user so that he selects those that interest him.

Next, a step 200 consists of the construction of the temporary tables in the database 6. The step 200 comprises a use of the information contained in the WSDL document (s) 8 involving the method (s) selected by the 'user. The WSDL 8 document makes it possible to identify the result as well as its type: simple or complex. It should be noted for clarification that the method of step 200 will allow, from the WSDL document, to construct the SOAP part of the SQL meta-query (query 9). The step starts from the WSDL document, which allows, for a method, to identify the parameters as well as the returned data. The presentation of the SQL meta-query to the user enables him to apply operators, and / or functions, and / or criteria in the SQL sense, on the returned data. The request 9 is therefore constructed from the selection of one or more method (s) of the service (s) web (all methods are described in the WSDL or).

The temporary tables consist, on the one hand, of a temporary reference table TTR, on the other hand, of one or more temporary tables of TTD data. In the implementation example described here, step 200 begins with the construction of the temporary reference table TTR, performed by a standard call in SQL "CREATE TABLE ...". The temporary reference table TTR comprises, for example, at least two columns: a column TTRa, for example named "table_id", which makes it possible to store the physical name of each of the temporary tables of data TTD, and a second column TTRb, by example named "table_name," which keeps the name of the associated method or if the result of the method is complex, the name of the method followed by a separator (the point for example) and an identifier of the complex form of the result of the method. The name of this temporary reference table TTR is constructed for example by using the date and time of the creation of this table, followed by a random number to guarantee its uniqueness. The name of this temporary reference table TTR is kept in memory until the end of the process steps. Step 200 consists of an analysis of the WSDL document 8 and the creation of one or more temporary tables of TTD data according to the complexity of the result of the requested method. More precisely, for a method, one can be led to build a single temporary table if no complex type is involved. As soon as a complex type is involved, several tables are built. The id table is broken down as follows: - Id YYYY_MM_DD_hh_mm_ss: this time marker allows the purge - XXX YYYY: random identifier allowing, for this time marker, to ensure a unique reference to the web service method involved - Ti for the name of the web service method involved, - TN with N varying from 2 to N if complex types are involved.

Any other method to cover purge requirements and identification of methods, parameters, data returned in the temporary physical data model, is acceptable.

In the example El already quoted, we have the following situation: Example El simple type: [WebMethod] public string Methodl (string paraml)

Contents of the TTR table table id table_name id 2010 11 03 09 19 11 487 5120 T1 Method 1 Contents of the TTD table <id> <null.id> value 1 NULL Response from Method1 Only one temporary TTD data table is created. The name of this temporary table TTD data is built using, in this example non-limiting, the date and time of the creation of this table followed by a random number and the term Ti to ensure its uniqueness. Let "id_2010_11_03_09_19_11_487_5120_T1", the name of this temporary TTD data table for this example E1. This TTD data table is created by a CREATE TABLE classic SQL query, it contains three columns named respectively <id> of type integer, <null.id> of type integer, value of type string. The <id> column serves as a unique identifier for the rows of the temporary TTD data table id_2010_11_03_09_19_11_487_5120_T1, the <null.id> column is for this non-significant El example, the value column is used to store the "Method1 Result" responses. The temporary data table TTD id_2010_11_03_09_19_11_487_5120_T1 being created, a line is added to the temporary reference table TTR with in the first column "table_id" the character string id 2010 11 03 09 19 11 487 5120 T1 and in the second column "table_name ", The name of the method of the example El, ie the string" Method1 ".

In the second example E2, the situation is as follows: ExampleE2 complex type composed of simple types: public class Person {public String LastName; public String FirstName; public DateTime BirthDate; public class Address {public String Street; Public String City; public int ZipCode; } [WebMethod] public Address Method2 (Person paraml)

Contents of the TTR table table id table_name id 2010 11 03 09 33 46 565 5120 T1 Method2 Contents of the TTD table <id> <null.id> Street City ZipCode 1 NULL 130 Baptistou Street, Saint Gely 34980 ZAE Nord Fesc La Temporary reference table TTR is created as in Example El and only one temporary table of TTD data is created. Let "id_2010_11_03_09_33_46_565_5120_T1", the name of this temporary TTD data table created by a classic SQL query CREATE TABLE; in example E2, the temporary TTD data table has five columns named respectively <id> of type integer, <null.id> of type integer, "Street" of type string, "City" of type string , "ZipCode" of string type. The <id> column serves as a unique identifier for the rows of the temporary data table TTD id_2010_11_03_09_33_46_565_5120_T1, the column <null.id> is, for this example E2, insignificant, the columns "Street", "City", " ZipCode "are used to store the" Method2Result "responses. The temporary data table TTD id_2010_11_03_09_33_46_565_5120_T1 being created, a line is added to the reference table TTR with in the first column "table_id" the character string id 2010 11 03 09 33 46 565 5120 T1 and in the second column "table_name" , the name of the method of the example E2, ie the string "Method2". In Example E5, the situation is as follows: Example E5 complex type composed of complex types: public class Person {public String LastName; public String FirstName; public DateTime BirthDate; public Address HomeAddress; } public class Sport {public String Name; public Address PracticeAddress; public class Address {public String Street; Public String City; public int ZipCode;

[WebMethod] public Sport [] GetSports (Person paraml) Contents of the TTR table table id table name id_2010_11_03_09_43_55_361_5120_T1 GetSports id_2010_11_03_09_43_55_361_5120_T2 GetSports.PracticeAddress Table Contents TTD1 <id> <null.id> Name 1 NULL Roller 30 Contents of the TTD2 table <id> <GetSports.id> Street City ZipCode 1 1 98 Queen's Road Boulogne-Billancourt 92100 The temporary TTR reference table is created as in example El and two temporary tables of TTD data are created. Let's say "id_2010_11_03_09_43_55_361_5120_T1", the name of the first temporary TTD data table created by a CREATE TABLE classic SQL query with E5 for example, three columns named <id> of integer type, <null.id> of integer type, " Name "of type string. The column <id> 15 20} 25 serves as a unique identifier for the rows of the TTD data temporary table id_2010_11_03_09_43_55_361_5120_T1, the "Name" column is used to store the Name response of the ArrayOfSport structure of Example E5. The temporary TTD data table id_2010_11_03_09_43_55_361_5120_T1 being created, a line is added to the temporary reference table TTR with in the first column "table_id" the character string id 2010 11 03 09 43 55 361 5120 T1 and in the second column "table_name ", The name of the method of the example E5, ie the string" GetSports ".

Either id_2010_11_03_09_43_55_361_5120_T2, the name of the second temporary TTD data table created by a CREATE TABLE known per se query with, for this example E5, five columns named <id> of integer type, <GetSports.id> of integer type , "Street" type string, "City" type string, "ZipCode" type string. The <id> column serves as a unique identifier for the rows of the temporary TTD data table id_2010_11_03_09_43_55_361_5120_T2, the "Street", "City", "ZipCode" columns are used to store the responses of the Address sub-structure of the ArrayOfSport structure. The column <GetSports.id> is used for insertions in this table id link with the corresponding line of the table id_2010_11_03_09_43_55_361_5120_T1. In SQL, we use a syntax of type "from id 2010 11 03 09 43 55 361 5120 T1 INNER JOIN id-2010-11-03-09-43-55-361-5120-T2 ONid-2010-11-03 -09-43-55-361-5120-T1. <Id> = id_2010_11_03_09_43_55_361_5120_T2. <GetSports.id> ".

In this E5 example, the name of the <GetSports.id> column is used to indicate that the id_2010_11_03_09_43_55_361_5120_T2 table contains the PracticeAddress sub-structure of the result. In order to keep the TTD data tables similar in construction, the temporary TTD tables contain a column named "null.id" when they do not correspond to a substructure in a response structure. The temporary TTD data table named id_2010_11_03_09_43_55_361_5120_T2 being created, a line is added to the temporary reference TTR with in the first column "table_id" the character string id 2010 11 03 09 43 55 361 5120 T2 and in the second column "table_name "The string" GetSports.PracticeAddress ". In example E5, the reference table TTR thus contains two lines.

In a next step 250, we construct a SQL meta-query involving the SELECT statement and including: - in its FROM clause the reference to one or more web services, - in its WHERE clause, the input parameters of the web services involved in the FROM clause. The SQL meta-query has 2 parts: - A first part, related to the call to a method of a web service with parameters passing, - A second part, related to the result data. For this second part, because a physical model of data has been constructed, all the power of the SQL language can be used on the results of the call to the web service method, and in particular the clauses of the instruction SELECT.

A step 275 presents the request to the user to define his input parameters as well as the operations he wishes to perform on the returned data: this key step allows the user to have all the power of the language SQL to transform the raw data returned by the web services.

In a second step, step 275 includes an analysis of the syntax of the request 9 to verify that it complies with the rules 21 and that it is based on the appropriate elements cited in the document WSDL 8 received following the request. 7. If this test fails, step 100 returns an error code and the process stops.

A next step 300 includes translating the SQL meta-query for constructing a SOAP request-compliant query 9 and executing it. The call to a WEB service 5 being known to those skilled in the art, it is not detailed here. The request 9 is decoded in order to extract the name of the method and the possible values of the input parameters to be transmitted to the SOAP request 20. The SOAP request 20 returns an XML return file 22 respecting the WSDL formalism.

A next step 400 includes decoding the XML return file 22, retrieving the data and inserting that data into the temporary data table (s) TTD created in step 200.

The data is inserted into the temporary TTD data table (s) by an INSERT INTO SQL query or by any other means known to those skilled in the art. The correspondence between the physical name of the temporary data table (s) TTD, and a simple element or structure of the SOAP response contained in the XML file 22, is found using the contents of the temporary reference table TTR. Choosing the correct column names in the temporary TTD data table (s) in step 200 makes it easy to map the name of a simple type element in the WSDL-compliant XML return file 22 8 and the name of the corresponding column in the associated temporary TTD data table.

In a next step 500, the SQL meta-query is translated to create an SQL query 23 and it is executed on the database 6. The SQL query 23 is constructed by decoding the request 9 and in particular by searching for each name from the query table 9 (FROM identifier) the name of the associated temporary TTD data table with the aid of the temporary reference table TTR. Matching for an item is conducted similarly to step 400.

In a next step 600, a result 10 is generated according to the results of the SQL query 23. The result 10 will preferably be presented in XML or CSV formats in order to be easily interpretable by a spreadsheet.

The search optimization method advantageously comprises a step 700 intended to delete the temporary tables in the database 6.

The operation of the method is as follows: 1 / Either the user-client 3 uses a reduced interface 4, allowing him to type the Internet address 7 and the request 9 according to the writing rules 21. He then clicks on a button to launch the preceded according to the invention and obtain the result 10, this interface 4 can even be integrated in the application 1. 2 / Either the user-client 3 uses a more developed interface 4, allowing him to type the Internet address 7 and create its application by tools that can be graphical. In this case, the interface 4 is responsible for constructing the request 9 in accordance with the writing rules 21. Similarly, the interface 4 can retrieve the result 10 and format it according to different rules.

Advantages of the invention The SQL / SOAP-WSDL translator makes it possible to ensure the following correspondences: Web Service SOAP-WSDL SQL Obtaining the description WSDL Equivalent of reading of the catalog in structure of the returned by the web a database SQL data service Obtaining the Result returned Result returned by the request given by the Passing Parameters method Application of a clause of type WHERE Parameters of the <parameter = value> method for each parameter Moreover, it allows the complete application of the SQL language, in particular: - Operators - Functions - Clauses: WHERE, HAVING, ORDER BY, BY GROUP, JOIN, UNION ...

Embodiments The scope of the present invention is not limited to the details of the above embodiments considered by way of example, but instead extends to modifications within the scope of those skilled in the art. An alternative is to provide write rules 21 with JSON (JavaScript Object Notation) formalism. Another variation is to use a SELECT IN 10 style SQL syntax. Yet another variant is to present the result 10 in any form exploitable by the user-client 3 or by the user interface 4. It should be noted that in the foregoing description, the protocols 15 of HTTP and HTTPS transport as means of access to a web service. However, the SOAP-WSDL protocol is not closed to these HTTP and HTTPS transport protocols alone, and the invention also applies to other transport protocols.

Claims (7)

REVENDICATIONS1. Search optimization method, accessible to a user of at least one SOAP-WSDL web service of any kind, said access being realized through a computer system, said computer system being able to access at least one relational database and said web service SOAP-WSDL concerned, said user having defined a request on data accessible by this SOAP-WSDL web service, characterized in that the method uses previously defined writing rules, making it possible to express the request to be made, and includes following steps: 100 - validation of the input parameters of the process consisting on the one hand of the Internet address for accessing the WSDL document of the web service and on the other hand the request to be made, 200 - creation of tables in a relational database, 250 - constructing a SQL meta-query involving the SELECT statement and including: - in its FROM clause a reference to one where several web services - in its WHERE clause of the input parameters of the web services involved in the FROM 275 clause - to present the request to the user so that he defines his input parameters as well as the operations that he wishes to achieve on the returned data; then validation of the request. 300 - translation of the SQL meta-query for construction and execution of the SOAP call to be made on the web service, 400 - recovery of the response of the web service and storage of this response in the tables built in step 200, 500 - translation of the SQL meta-query for building a query on the tables built in step 200 and executing said query. 2. Method according to claim 1 characterized in that the writing rules for expressing the request to perform, use the language SQL (Structured Query Language). 3. Method according to claim 1 characterized in that the writing rules for expressing the request to perform, use the language JSON (JavaScript Oriented Notation). 4. Method according to claim 1 characterized in that the writing rules are encoded with a language for expressing any request. 5. Method according to claim 1, characterized in that the step 200 of creation of tables in the relational database uses, for the data model of creation of these tables, a logic making it possible to automatically make the relation between an entity of output, described in the WSDL document of the concerned web service, and a column in a table constructed by said method. 6. Method according to claim 1 characterized in that it comprises a step 600 of providing a response in the form of a csv file. 7. Method according to claim 1 characterized in that it comprises a step 600 of providing a response in the form of an XML file.