WO2006040991A1

WO2006040991A1 - Terminal device, server device, and web service providing system

Info

Publication number: WO2006040991A1
Application number: PCT/JP2005/018512
Authority: WO
Inventors: Tetsuya Matsuyama; Soichi Nitta; Masafumi Hirata
Original assignee: Sharp Kabushiki Kaisha
Priority date: 2004-10-08
Filing date: 2005-10-06
Publication date: 2006-04-20
Also published as: JPWO2006040991A1

Abstract

Even in an environment such as the MIDP unable to add classes dynamically, dynamic connections to a plurality of Web services can be made on a terminal such as a mobile telephone having few resources. In case the Web services are called from a Web service server, a terminal device neither down-loads nor installs a stub class corresponding to the Web services, but down-loads an API calling procedure describing file enumerating a series of API calling procedures necessary for calling the Web services. The terminal device is enabled to use the Web service merely by calling the API sequentially on the basis of that API calling procedure describing file.

Description

Specification

Terminal device, server device, and Web service providing system

Technical field

TECHNICAL FIELD [0001] The present invention relates to a terminal device such as a mobile phone, and more particularly to a technique for using the terminal device as a Web service service client.

Background art

[0002] There has been a remarkable improvement in the functionality of mobile phones in recent years, beginning with Internet connection, such as camera 'GPS (Global Positioning System)' navigation, and other personalized service portals that are not just talking devices. Exhibit as a terminal. Since various personal information is stored in the mobile phone and even payment processing is possible if the mobile phone is at hand, it is no longer routine to carry the mobile phone with you at all times.

[0003] On the other hand, in collaboration between systems within and between companies, standardized XML (extended Markup Language) messages are exchanged instead of each vendor's original technology centered on the mainframe. Web services that call external services are spreading rapidly!

[0004] With Web services, computers can call each other's services without human intervention. Various services are now available as Web services regardless of their scale, with the aim of integrating systems that cross departments within the company and outsourcing operations for the purpose of centralizing the use of resources between companies. It is starting to be offered.

[0005] In recent years, attempts have been proposed to use Web services using mobile terminals such as mobile phones. For example, in JSR172 (J2ME Web Services Specification) formulated by JCPOAVA Community Process), standardization of JAVA implementation of Web service client as a terminal is being promoted. In order for a terminal to function as a Web service client, an appropriate SOAP (Simple Object Access Protocol) defined by a Web Service Description Language (WSDL) file that describes the Web service interface is used. It is necessary to implement a program that sends messages to the Web service server.

FIG. 19 shows a general Web service invocation method. The Web service server publishes an interface 1901 as shown in the example in the figure, and it is assumed that a Web service call 1902 as shown in the figure is made from such a Web service client to the Web service server. Figure 20 shows a description example of a WSDL file for calling a Web service. When API (Application Programming Interface) defined in JSR172 is used for calling a Web service, a series of API calls as shown in Fig. 21 is actually required.

[0007] However, in general, it is very difficult to call up an API as shown in Fig. 21 by praying a WSDL file as shown in Fig. 20 on a terminal such as a mobile phone. Have difficulty. Therefore, in the example described in Non-Patent Document 1, the stub class used on the terminal is generated in an environment without resource restrictions, and then the stub class is installed in the terminal.

FIG. 22 shows a case where a stub 'class is used for invoking a Web service. The Web service client 2200 has an application 2201, a stub class 2202, and a library 2203 that implements JSR172. The application 2201 calls the library 2203 through the stub 'class 2202 and sends a SOAP message 2204 to the Web service server 2205. Figure 23 shows an example of a 'stub' class. As shown in Fig. 23, the stub 'class hides the API calls necessary for calling the web service internally, so the developer of application 2201 handles the normal classes as shown in Fig. 24. If the stub 'class is handled as in the case, the Web service can be called without being aware of the detailed contents of the SOAP message 2204.

[0009] Patent Document 1 discloses a technique for providing a proxy server between a server and a terminal and using a Web service from a terminal having only a normal Web browser function without a necessary implementation as a Web service client. ing. When a predetermined keyword is input on the Web page from the terminal, a specific Web service that matches the user's wishes is extracted, and related information is sent to the proxy server device. The proxy server device creates a dedicated API based on the protocol described in the WSDL document, and then sends it to the server device that provides the Web service. A service request is sent on behalf of the terminal device. As a result of the service provision, the service is reported by e-mail to the proxy server device terminal. Patent Document 1: Japanese Patent Laid-Open No. 2004-30360

Non-Patent Document 1: JAVA WORLD March 2004, page 166

Disclosure of the invention

[0010] Currently, MIDP (Mobile Information Device Profile) is mainly used as a specification for Java execution environment defined for mobile phones and other devices. The format of application created for MIDP is " It is called “MIDlet”. A terminal that supports MIDP can download and install the MIDlet via the network and run it on the terminal. However, on MIDP, it is necessary to support functions such as user-defined class loader reflection, so classes cannot be added dynamically. In order to add a class, a new MIDlet containing the added class must be installed. Therefore, even when creating an application that calls various Web services, it is not possible to dynamically add stub classes corresponding to each Web service. It is necessary to newly install the MIDlet including the stub class corresponding to the Web service.

An object of the present invention is to enable dynamic connection to a plurality of Web services on a terminal with few resources such as a mobile phone even in an environment where a class cannot be dynamically added like MIDP. And

[0012] According to the present invention, when a terminal device calls a web service from a web service server, the terminal device calls the web service rather than downloading and installing a stub 'class corresponding to the web service. Download the API call procedure description file that enumerates the series of API call procedures required for this. Based on the API call procedure description file, the terminal device can use the Web service by simply calling the API in order. Therefore, the terminal does not need to analyze the WSDL file in the same way as when using the stub 'class, and it is not necessary to add the class to the MIDlet. Therefore, the class can be added dynamically like MIDP. Even in the environment, it is possible to dynamically connect to multiple Web services with few resources. [0013] According to the present invention, even in an environment where a class cannot be added dynamically, such as MIDP, it is possible to dynamically connect to a plurality of Web services on a terminal with few resources such as a mobile phone.

Brief Description of Drawings

FIG. 1 is a schematic diagram of a Web service system according to the present invention.

FIG. 2 is a configuration diagram of a first example of a terminal device and a server device according to the present invention.

FIG. 3 is a diagram illustrating a terminal device according to the present invention in comparison with the prior art.

FIG. 4 is a diagram showing a flow of processing in the terminal device according to the present invention.

FIG. 5 is a diagram showing a flow of processing in the server device according to the present invention.

FIG. 6 shows an example of an API call procedure description file.

FIG. 7 is a diagram for explaining a qname element in an API call procedure description file.

FIG. 8 is a diagram for explaining an element element in an API call procedure description file.

FIG. 9 is a diagram for explaining a complextype element in an API call procedure description file.

FIG. 10 is a diagram for explaining an operation element in an API call procedure description file.

FIG. 11 is a diagram for explaining the setproperty element in the API call procedure description file.

FIG. 12 is a diagram showing an example of storing objects in a hash table.

FIG. 13 is a diagram showing an example of input parameters.

FIG. 14 is a diagram showing a second example of input parameters (parameters are two-dimensional).

FIG. 15 is a diagram showing an example of a service identifier correspondence table storage unit.

FIG. 16 is a diagram showing a second example of a service identifier correspondence table storage unit.

FIG. 17 is a configuration diagram of a second example of a terminal device and a server device according to the present invention.

FIG. 18 is a diagram showing an example of input parameters in the second example of the terminal device and the server device according to the present invention.

FIG. 19 is a diagram for explaining an example of calling a conventional general Web service.

FIG. 20 is a diagram showing an example of a WSDL file.

FIG. 21 is a diagram showing an example of a terminal-side API call in a conventional general Web service call.

FIG. 22 is a configuration diagram using a stub 'class for calling a Web service. FIG. 23 is a diagram showing an example implementation of a stub class.

FIG. 24 is a diagram showing an example of invoking a Web service using a stub 'class.

Explanation of symbols

[0015] 10 · 'Terminal device, 20 · · · Server device, 30 · ·' Web service server, 40 · "Communication network (Internet), 100 to Web service system, 101 ... I / O unit, 102 ... application , 103 • API call procedure description file storage unit, 104—API call procedure description file processing unit, 105… Receiving unit, 106… Transmitting unit, 107… Library, 121 Bespoke, 123 ... Request parameter, 124 ... Response parameter, 125 ... Service interface description file acquisition destination, 126 ... Method identification information, 201 ... Service identifier correspondence table storage unit, 202 ... Service interface description file acquisition unit, 203 · -API call procedure description file generation unit, 204 ··· Method identification unit, 205 ··· Reception unit, 206 ··· Send unit, 225 · "API call procedure description file

BEST MODE FOR CARRYING OUT THE INVENTION

FIG. 1 shows an overall view of a Web service system according to the present invention. The web service system 100 of this example generates and provides a terminal device 10 such as a mobile phone serving as a web service client and an API call procedure description file describing an application programming interface (API) call procedure. A server device 20 and a Web service server 30 that stores and provides Web services are connected to each other via a communication network 40 such as the Internet.

The terminal device 10 transmits a service identifier that identifies a Web service to be used to the server device 20. The server device 20 generates an API call procedure description file based on the service identifier and transmits it to the terminal device 10. The terminal device 10 calls the API based on the API call procedure description file and calls the Web service on the Web service server 30. The Web service server 30 provides the called Web service to the terminal device 10.

[0018] The configuration of the terminal device 10 will be described with reference to FIG. The terminal device 10 includes an input / output unit 101, an application 102, an API call procedure description file storage unit 103, an API call procedure description file processing unit 104, a reception unit 105, and a transmission unit 106. The input / output unit 101 performs parameter input / output processing with the application 102 using the Web service. The input parameter 121 input from the application 102 by the input / output unit 101 includes a service identifier 122 that identifies a Web service to be used, a request parameter 123 that is a parameter for sending a request to the Web service, and a record from the Web service. It includes three parameters, response parameter 124, which is a parameter when receiving a response. An example of the input parameter 121 will be described later with reference to FIGS.

The API call procedure description file storage unit 103 stores the API call procedure description file 225 received from the server device 20 in association with the service identifier 122. This serves as a cache that prevents the same API call procedure description file 225 from being repeatedly received from the server device 20.

The API call procedure description file processing unit 104 uses the request parameter 123 and the response parameter 124 from the API call procedure description file 225 and the application 102 to actually call the Web service on the Web service server 30. . Details of this process will be described later. The reception unit 105 is responsible for receiving the API call procedure description file 225 from the server device 20, and the transmission unit 106 is responsible for transmission of the service identifier 122 to the server device 20.

Next, the configuration of the server device 20 will be described. The server device 20 includes a service identifier correspondence table storage unit 201, a service interface description file acquisition unit 202, an API call procedure description file generation unit 203, a method identification unit 204, a reception unit 205, and a transmission unit 206.

[0023] The service identifier correspondence table storage unit 201 stores a service identifier that identifies a Web service and information associated therewith. Such information includes the service name, bind name, port name, operation name, argument name, and return value name necessary to specify the WSDL file acquisition source and the method to be called. An example of the service identifier correspondence table storage unit 201 will be described later with reference to FIG. 15 and FIG.

[0024] The service interface description file acquisition unit 202 sends an appropriate WSDL file, that is, the service interface description file via the communication network 40 according to the WSDL file acquisition destination stored in the service identifier correspondence table storage unit 201. get. However, the service interface description file is a service interface description file. In some cases, the file acquisition unit 202 itself may be stored in advance.

[0025] The method identification unit 204 corresponds to a plurality of methods described in the WSDL file based on the service name, node name, port name, operation name, argument name, and return value name associated with the service identifier. Identify the method to perform. The API call procedure description file generation unit 203 generates an API call procedure description file 225 that describes an API procedure necessary to call the specified method. Details of this processing will be described later.

The receiving unit 205 is responsible for receiving the terminal device 10 service identifier 122, and the transmitting unit 206 is responsible for transmitting the API call procedure description file 225 to the terminal device 10.

With reference to FIG. 3, the difference between the present invention and the prior art of FIG. 22 will be described. In the prior art, since the stub 'class 2202 is used to connect to the web service, it was necessary to replace the stub' class 2202 to newly connect to another web service. In this example, a function equivalent to the stub class 2202 is realized by the API call procedure description file 225 describing the API call procedure and the API call procedure description file processing unit 104 interpreting it. Therefore, even when newly connecting to another Web service, it is not necessary to replace the class file constituting the API call procedure description file processing unit 104. The API call procedure description file 225 is downloaded from the server device 20 and replaced. It's okay.

A processing flow of the terminal device 10 will be described based on the flowchart of FIG. In step S401, the input / output unit 101 receives the input parameter 121 from the application 102 using the Web service. In step S402, it is determined whether or not the API call procedure description file 225 associated with the service identifier 122 included in the input parameter 121 is stored in the API call procedure description file storage unit 103. If it is stored, the processing after step S405 is performed based on the API call procedure description file 225. If not stored, a request for the API call procedure description file 225 is made to the server device 20 in step S403. That is, the transmission unit 106 transmits the service identifier 122 included in the input parameter 121 to the server device 20.

In step S404, the receiving unit 105 receives the API call procedure description file 225 from the server device 20. In step S405, the request parameter 123 included in the input parameter 121 input from the application 102 is converted. Details of this process This will be described later.

[0030] In step S406, the API call procedure description file processing unit 104 calls the API based on the API call procedure description file 225, and uses the converted parameters to the Web service server 30 as a Web service. Make a call. In step S407, the response parameter 124 is converted. That is, the return value obtained by calling the Web service is converted based on the response parameter 124. Details of step S405 and step S407 will be described later with reference to FIG. 13 and FIG.

In step S 408, the converted parameter is output from the input / output unit 101 to the application 102.

Next, the processing flow of the server apparatus 20 will be described based on the flowchart of FIG. In step S501, the receiving unit 205 receives the service identifier 122 from the terminal device 10. In step S502, the service interface description file acquisition unit 202 searches the WSDL file acquisition destination associated with the received service identifier 122 using the service identifier correspondence table storage unit 20, and in accordance with the searched WSDL file acquisition destination, That is, the service interface description file is also acquired by the external force. As described above, the service interface description file acquisition unit 202 itself may have a service interface description file.

[0033] In step S503, the method specifying unit 204 uses a service name, a bind name, a port name, an operation name, an argument name, and a return value name associated with the service identifier 122 to generate a plurality of items described in the WSDL file. Identify the corresponding method from the methods.

In step S504, the API call procedure description file generation unit 203 generates an API call procedure description file 225 that describes the API call procedure necessary for calling the specified method. In step S505, the transmission unit 206 transmits the generated API call procedure description file 225 to the terminal device 10.

The invocation of the web service in step S406 will be described in detail. The API call procedure description file processing unit 104 reads the API call procedure description file 225 shown in FIG. 6, and actually calls the API based on each child element of the service element. Examples of API calling rules are shown below in Figs. [0036] Figure 7 shows how to write the API call procedure description file 225 when calling an API that generates a QName object that represents a qualified name consisting of a namespace name and a local name. . The name attribute of the qname element generated by the name attribute of the qname element 701, the namespaceURI attribute representing the namespace name are the first argument of the constructor, and the localPart attribute representing the local name is the second argument of the constructor. The API call procedure description file processing unit 104 that has read this qname element 701 calls the API described in 702. (1) (3) (8) (10) in Fig. 6 corresponds to (1) (3) (8) (10) in Fig. 21.

[0037] FIG. 8 shows a description method of the API call procedure description file 225 when calling an API that generates an Element object that represents an element defined by the type element in WSDL. If the defined type is a simple type, the name attribute of the Element object generated by the name attribute of the element element 801, the qname attribute representing the Qname object to be referenced is the first argument of the constructor, and the type attribute representing the type is the constructor The minOccurs attribute that represents the minimum number of occurrences is the third argument of the constructor, the maxOccurs attribute that represents the maximum number of occurrences is the fourth argument of the constructor, and the nillable attribute that indicates whether elements can be omitted is the fifth argument of the constructor Become. The API call procedure description file processing unit 104 that has read the element element 801 calls the API described in 802. If the type to be defined is a complex type, which will be described later, a complex xType attribute representing a ComplexType object to be referenced is added instead of the type attribute, and the API call procedure description file processing unit 104 that reads the element element 803 reads The API described in 804 will be called. (2) (4) (9) in Fig. 6 corresponds to (2) (4) (9) in Fig. 21.

FIG. 9 shows a description method of the API call procedure description file 225 when calling an API that generates a ComplexType object representing a complex type defined by a type element in WSDL. The name of the ComplexType object generated by the name attribute of the complexType element 901, the size attribute indicates the number of Element objects that make up this ComplexType object, and the name attribute power in the part element that is a child element of the complexType element 901. Represents the name of each Element object that composes. Therefore, the API call procedure description file processing unit 104 that has read the complexType element 901 calls the API described in 902. (5) (6) (7) in Fig. 6 is replaced with (5) (6) (7) in Fig. 21 Correspond.

FIG. 10 shows a description method of the API call procedure description file 225 when calling an API that generates an Operaton object representing an operation element that is a child element of the portType element in WSDL. Call the newlnstance method of the Operation class with the qname attribute representing the Qname object referenced by the operation element 1001 as the first argument, the input attribute representing the argument type as the second argument, and the output attribute representing the return type as the third argument . Therefore, the API call procedure description file processing unit 104 that has read the operation element 1001 calls the API described in 1002. (13) in Fig. 6 corresponds to (13) in Fig. 21.

FIG. 11 shows a description method of the API call procedure description file 225 when a property is added to the Operation object. When the SOAPAction header is specified when using HTTP as the SOAP transport protocol, the API call procedure description file processing unit 104 that has read the setProperty element 1101 calls the API described in 1102. (12) in Fig. 6 corresponds to (12) in Fig. 21. When specifying the endpoint of the service to be called, the API call procedure description file processing unit 104 that has read the setProperty element 1103 calls the API described in 1104. (12) in Fig. 6 corresponds to (12) in Fig. 21.

However, in an actual program, variable names cannot be dynamically changed as shown in FIGS. Therefore, the API call procedure description file processing unit 104 that has read the qname element 701 does not actually generate the object named “qnameName”, and the object generated in the hash table or the like as shown in 120 1 of FIG. Store the name in association. At the time of reference, the corresponding object is acquired using the name and the name of the table as shown in 1202 as a key.

[0042] Next, details of the request parameter conversion in step S405 and the response parameter conversion in step S407 will be described. Normally, when calling a Web service using JSR172, parameters are stored in an array of Object type as shown in Fig. 21 (a), (b), and (c), and the API is called.

FIG. 13 shows an example of the input parameter 121 input from the application 102. In this example, the input parameter 1301 includes a request parameter associated with an object array subscript, object type, and object value. API call procedure description file The file processing unit 104 stores the objects in the array in order as indicated by 1302 in FIG. 13 according to the request parameters. Similarly, the return value obtained by invoking the Web service is also stored in the Object type array. Therefore, the object array subscript and the object type are associated as response parameters, and the object array subscript power can be obtained. Is converted to the specified object type and output to the application 102. FIG. 14 shows an example when the object array of the input parameter 121 is two-dimensional. However, since the variable name cannot be changed dynamically like “Objectl” or “input〇bject” in the actual program, “Objectl” or “inputObj” Instead of creating an object named “ect”, the created object is stored and referenced in association with its name in a hash table or the like.

Details of the method specifying process in the service identifier correspondence table storage unit 201, the method specifying unit 204, and step S503 will be described.

[0045] As shown in FIG. 15, the service identifier correspondence table storage unit 201 includes a service identifier 1501, a WSDL file acquisition destination 1502, a service name 1503, a bind name 1504, a port name 1505, an operation name 1506, and an argument name 1507. Return value name 1508 is stored. In the WSDL file, it is usually possible to publish multiple methods. The method actually executed is specified by the parameters below the service name. In these parameters, the service name 1503 corresponds to the name attribute of the service element in the WSDL, the bind name 1504 corresponds to the name attribute of the binding element, the port name 1505 corresponds to the name attribute of the portType element, and the operation name 1506 corresponds to the name attribute of the operation element that is a child element of the portType element, argument name 1507 corresponds to the name attribute of the input element that is a child element of the operation element, and the return value name 1508 is a child element of the operation element. It corresponds to the name attribute of a certain output element, and methods that match all of them are specified. The parameters below the service name are used only to specify the method. If the same purpose is achieved, there is essentially no problem with other information.

FIG. 16 shows another example of the service identifier correspondence table storage unit 201. In this example, information is stored as to which line in the WSDL file each element exists.

[0047] API call description file generation processing and API call procedure description file in step S504 Details of the aisle generator 203 will be described. First, a series of API calls ((1) to (13) in FIG. 21) necessary for calling the method specified in step S503 are generated in the same way as normal stub generation. Next, an API call procedure description file (Fig. 6) is generated from the series of API calls obtained by applying the conversion rules shown in Figs. 7 to 11 in the reverse direction.

A second example of the terminal device and the server device according to the present invention will be described with reference to FIG. Here, only the differences from the first example of FIG. 2 will be described. In the first example, the server device 20 receives the service identifier 122 from the terminal device 10, and acquires information associated with the service identifier 122 in the service identifier correspondence table storage unit 201. In this example, since all the necessary information is received from the terminal device 10, the service identifier correspondence table storage unit 201 is omitted. The input parameter 121 input by the input / output unit 101 from the application 102 includes a service interface description file acquisition destination 125 and method specifying information 126 instead of the service identifier 122. Therefore, the input parameter 121 includes five parameters: a service interface description file acquisition destination 125, method identification information 126, a request parameter 123, and a response parameter 124.

FIG. 18 shows input parameters 121 input from the application 102 of this example. Since the terminal device 10 transmits the input parameter 121 including the service interface description file acquisition destination 125 and the method specifying information 126 to the server device 20, the server device 20 omits the service identifier correspondence table storage unit 201 in the first example. can do.

[0050] In this example, an example is shown in which all the information necessary for comparison with the first example is input to the application force. However, a part of the necessary information is also input to the application device, and the rest is used as the server device 20 The service identifier correspondence table storage unit 201 may interpolate.

[0051] The example of the present invention has been described above, but the present invention is not limited to the above-described example, and various modifications can be made within the scope of the invention described in the claims. It will be understood by those skilled in the art.

Claims

The scope of the claims

[1] Communication that enables communication between the Web service server device that provides Web services and the API call procedure description file server that provides the API call procedure description file that describes the application program interface (API) call procedure An application unit that executes an application using the Web service and outputs parameters necessary for using the Web service;

An API call procedure description file processing unit for calling a Web service of the Web service server device based on the API call procedure description file transmitted from the API call procedure description file server device. A terminal device.

[2] In the terminal device according to claim 1, the parameter includes a service identifier for identifying a Web service, and the communication unit uses the API call procedure description file server device. A terminal device that transmits the service identifier for identifying a Web service.

[3] In the terminal device according to claim 1, the parameter includes an acquisition destination of the service interface description file, and the communication unit transmits the service interface description to the API call procedure description file server device. A terminal device characterized by transmitting a file acquisition destination.

[4] In the terminal device according to claim 1, the parameter includes method specifying information for specifying a predetermined method from a plurality of methods described in the API call procedure description file, and the communication unit includes: A terminal device that transmits the method specifying information to an API call procedure description file server device.

[5] In the terminal device according to claim 1, the parameters include a request parameter that is a parameter for transmitting a request to the Web service and a response parameter that is a parameter for receiving a response from the Web service. A terminal device characterized by including.

[6] A service interface description file acquisition unit that acquires a service interface description file based on a request from a terminal device;

Multiple method capabilities described in the service interface description file Method identification to identify the method,

An API call procedure description file generator that generates an API call procedure description file based on the identified method;

Have

A server device, wherein the API call procedure description file is transmitted to the terminal device.

7. The server device according to claim 6, wherein the service interface description file acquisition unit acquires the service interface description file from an external force or from itself.

8. The server device according to claim 6, further comprising a service identifier correspondence table storage unit that stores a service identifier that specifies a Web service and information associated therewith.

[9] The server device according to claim 8, wherein the service interface description file acquisition unit is configured to use the service interface based on information associated with a service identifier stored in the service identifier correspondence table storage unit. A server device characterized by acquiring a description file.

10. The server device according to claim 8, wherein the method specifying unit specifies the method based on information associated with a service identifier stored in the service identifier correspondence table storage unit. Server device.

[11] The server device according to claim 6, wherein the service interface description file acquisition unit acquires the service interface description file based on the service interface description file acquisition destination transmitted by the terminal device. A server device characterized by

[12] The server device according to claim 6, wherein the method specifying unit specifies the method based on the method specifying information transmitted from the terminal device! apparatus.

[13] Web service server device that provides Web services and API call procedure description files that describe application program interface (API) call procedures When the terminal device transmits a service identifier to the API call procedure description file server device, the API call procedure description file server device The API call procedure description file is transmitted to the terminal device based on the service identifier, the terminal device calls the API based on the API call procedure description file, and the Web service server device Web service The Web service providing system, wherein the Web service server device makes a call and provides the called Web service to the terminal device.