+

WO2006040991A1 - 端末装置、サーバ装置、及びWebサービス提供システム - Google Patents

端末装置、サーバ装置、及びWebサービス提供システム Download PDF

Info

Publication number
WO2006040991A1
WO2006040991A1 PCT/JP2005/018512 JP2005018512W WO2006040991A1 WO 2006040991 A1 WO2006040991 A1 WO 2006040991A1 JP 2005018512 W JP2005018512 W JP 2005018512W WO 2006040991 A1 WO2006040991 A1 WO 2006040991A1
Authority
WO
WIPO (PCT)
Prior art keywords
description file
service
server device
api call
terminal device
Prior art date
Application number
PCT/JP2005/018512
Other languages
English (en)
French (fr)
Inventor
Tetsuya Matsuyama
Soichi Nitta
Masafumi Hirata
Original Assignee
Sharp Kabushiki Kaisha
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sharp Kabushiki Kaisha filed Critical Sharp Kabushiki Kaisha
Priority to JP2006540900A priority Critical patent/JPWO2006040991A1/ja
Publication of WO2006040991A1 publication Critical patent/WO2006040991A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Definitions

  • Terminal device server device, and Web service providing system
  • 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.
  • 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.
  • API Application Programming Interface
  • 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.
  • 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.
  • 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.
  • 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
  • MIDP Mobile Information Device Profile
  • MIDlet Mobile Information Device Profile
  • a terminal that supports MIDP can download and install the MIDlet via the network and run it on the terminal.
  • MIDP it is necessary to support functions such as user-defined class loader reflection, so classes cannot be added dynamically.
  • 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.
  • the terminal device 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the service interface description file is a service interface description file.
  • the file acquisition unit 202 itself may be stored in advance.
  • 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.
  • the difference between the present invention and the prior art of FIG. 22 will be described.
  • the stub 'class 2202 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.
  • 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.
  • step S401 the input / output unit 101 receives the input parameter 121 from the application 102 using the Web service.
  • 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.
  • step S404 the receiving unit 105 receives the API call procedure description file 225 from the server device 20.
  • 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.
  • 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.
  • 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.
  • step S 408 the converted parameter is output from the input / output unit 101 to the application 102.
  • step S501 the receiving unit 205 receives the service identifier 122 from the terminal device 10.
  • 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.
  • the service interface description file acquisition unit 202 itself may have a service interface description file.
  • 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.
  • 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.
  • step S505 the transmission unit 206 transmits the generated API call procedure description file 225 to the terminal device 10.
  • 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.
  • 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.
  • the defined type is a simple type
  • the qname attribute representing the Qname object to be referenced is the first argument of the constructor
  • 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
  • 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.
  • 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.
  • FIG. 11 shows a description method of the API call procedure description file 225 when a property is added to the Operation object.
  • 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.
  • 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.
  • 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.
  • FIG. 13 shows an example of the input parameter 121 input from the application 102.
  • 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.
  • 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.
  • the WSDL file it is usually possible to publish multiple methods. The method actually executed is specified by the parameters below the service name.
  • 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
  • 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
  • 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.
  • information is stored as to which line in the WSDL file each element exists.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

　MIDPのように動的にクラスを追加できない環境においても、携帯電話のようなリソースの少ない端末上で複数のＷｅｂサービスへの動的な接続を可能にする。端末装置は、WebサービスサーバからWebサービスの呼び出しを行う場合に、そのWebサービスに対応したスタブ・クラスをダウンロードしてインストールするのではなく、そのWebサービスの呼び出すのに必要な一連のAPI呼び出し手続きを列挙したAPI呼出手順記述ファイルを、ダウンロードする。端末装置は、そのAPI呼出手順記述ファイルに基づいて順にAPIを呼び出しを行うだけで、Webサービスを利用することができる。

Description

明 細 書
端末装置、サーバ装置、及び Webサービス提供システム
技術分野
[0001] 本発明は、携帯電話等の端末装置に関し、特に、端末装置を Webサービスのサー ビスクライアントとして利用する技術に関するものである。
背景技術
[0002] 昨今の携帯電話の高機能化にはめざましいものがあり、インターネット接続に始まり カメラ ' GPS (Global Positioning System) 'ナビゲーシヨンなど、単なる通話機器に留ま らずパーソナライズィ匕されたサービスポータル端末としての様態を呈して ヽる。携帯 電話内に様々な個人情報が蓄積され、決済処理ですら、携帯電話が手元にあれば 可能になるために、携帯電話を常に身近に持ち歩くことはもはや日常的となっている
[0003] 一方で、企業内部および企業間におけるシステム間の連携においては、これまで のメインフレームを中心とした各ベンダーの独自技術に代わって、標準化された XML (extended Markup Language)メッセージのやり取りによって外部のサービスを呼び出 す Webサービスが急速に普及して!/、る。
[0004] Webサービスでは、人間の作業が介在せずにコンピュータ同士が互いにサービスを 呼び出すことが可能である。企業内部における各部署間を横断するようなシステムの 統合化、企業間におけるリソースの集中活用を目的とした業務のアウトソーシングイ匕 をにらんで、現在様々なサービスがその規模を問わず Webサービスとして提供され始 めている。
[0005] 近年、携帯電話などの携帯端末を用いて、 Webサービスを利用する試みが提案さ れている。例えば、 JCPOAVA Community Process)によって策定された JSR172(J2ME Web Services Specification)では、端末である Webサービスクライアントの JAVA実装 の標準化が進められて 、る。端末が Webサービスクライアントとしての機能を果たすた めには、 Webサービスのインターフェイスを記述した WSDL(Web Service Description Language)ファイルによって規定される適切な SOAP (Simple Object Access Protocol) メッセージを Webサービスサーバへ送信するプログラムを実装する必要がある。
[0006] 図 19は、一般的な Webサービスの呼び出し方法を示す。 Webサービスサーバは図 示の例のようなインターフェイス 1901を公開しており、このような Webサービスサーバ に対して、 Webサービスクライアントより図示のような Webサービスの呼び出し 1902を 行う場合を想定する。図 20は、 Webサービスを呼び出すための WSDLファイルの記述 例を示す。 Webサービスの呼び出しに JSR172で規定されている API(Application Prog ramming Interface)を用いた場合、実際には図 21のような一連の APIの呼び出しが必 要となる。
[0007] し力しながら、一般的に携帯電話などの端末にて、図 20のような WSDLファイルを解 祈し、図 21のような APIの呼び出しを行うことは、リソースの制限から非常に困難であ る。そのため、非特許文献 1に記載されている例では、端末上で利用するスタブ'クラ スをリソースの制限のない環境で生成した後、そのスタブ'クラスを端末にインスト一 ルする。
[0008] 図 22は Webサービスの呼び出しにスタブ'クラスを用いた場合を示す。 Webサービ スクライアント 2200は、アプリケーション 2201、スタブ'クラス 2202、及び、 JSR172を実 装したライブラリ 2203を有する。アプリケーション 2201は、そのスタブ'クラス 2202を介 してライブラリ 2203を呼び出し、 SOAPメッセージ 2204を Webサービスサーバ 2205に送 信する。図 23は、スタブ'クラスの例を示す。スタブ'クラスは、図 23に示したように、 W ebサービスの呼び出しに必要な APIの呼び出しを内部に隠蔽しているので、アプリケ ーシヨン 2201の開発者は図 24のように通常のクラスを扱う場合と同様にスタブ'クラス を扱えば、 SOAPメッセージ 2204の詳細な内容を意識せずに Webサービスを呼び出 すことができる。
[0009] 特許文献 1には、サーバと端末間に代理サーバを設け、 Webサービスクライアントと して必要な実装なしに、通常の Webブラウザ機能のみを有する端末から Webサービス を利用する技術が公開されている。端末から Webページ上にて所定のキーワードを 入力すると、利用者の希望に合致した特定の Webサービスが抽出され、関連情報が 代理サーバ装置へ送られる。代理サーバ装置は WSDL文書に記載されたプロトコル に基づ!/、て専用 APIを作成した上で、当該の Webサービスを提供するサーバ装置へ 端末装置に代わってサービス要求を送る。その結果行われたサービスの提供につい て、代理サーバ装置力 端末装置へ電子メールによるサービスの報告が行われる。 特許文献 1：特開 2004-30360号公報
非特許文献 1： JAVA WORLD 2004年 3月号 166ページ
発明の開示
[0010] 携帯電話などの端末向けに定義された Java実行環境の仕様としては現在 MIDP(Mo bile Information Device Profile)が主に利用されており、その MIDP用に作られたアプリ ケーシヨンの形式は「MIDlet」と呼ばれる。 MIDPをサポートしている端末では、ネットヮ ーク経由で MIDletをダウンロード及びインストールし、それを端末上で動作させること ができる。しかしながら、 MIDP上では、ユーザ定義のクラスローダ'リフレクションなど の機能をサポートして ヽな 、ためクラスを動的に追加することができな 、。クラスを追 加するためには追カ卩したクラスを含む MIDletを新たにインストールしなければならな い。そのため、様々な Webサービスを呼び出すようなアプリケーションを作成する際に も、それぞれの Webサービスに対応したスタブ ·クラスを動的に追加することはできず 、新規の Webサービスの呼び出しを行う度にその Webサービスに対応したスタブ'クラ スを含む MIDletを新たにインストールし直す必要がある。
[0011] 本発明は、 MIDPのように動的にクラスを追加できない環境においても、携帯電話の ようなリソースの少ない端末上で複数の Webサービスへの動的な接続を可能にする ことを目的とする。
[0012] 本発明によると、端末装置は、 Webサービスサーバから Webサービスの呼び出しを 行う場合に、その Webサービスに対応したスタブ'クラスをダウンロードしてインスト一 ルするのではなぐその Webサービスの呼び出すのに必要な一連の API呼び出し手 続きを列挙した API呼出手順記述ファイルを、ダウンロードする。端末装置は、その A PI呼出手順記述ファイルに基づ 、て順に APIを呼び出しを行うだけで、 Webサービス を利用することができる。そのため、端末はスタブ'クラスの利用時と同様に WSDLファ ィルの解析を行う必要がない上に MIDletに対してクラスを追加する必要がないため、 MIDPのような動的にクラスを追加できな 、環境にぉ 、ても、少な 、リソースで複数の Webサービスへの動的な接続が可能になる。 [0013] 本発明によれば、 MIDPのように動的にクラスを追加できない環境においても、携帯 電話のようなリソースの少ない端末上で複数の Webサービスへの動的な接続を可能 にする。
図面の簡単な説明
[0014] [図 1]本発明による Webサービスシステムの概略図である。
[図 2]本発明による端末装置とサーバ装置の第 1の例の構成図である。
[図 3]本発明による端末装置を従来技術と比較して説明する図である。
[図 4]本発明による端末装置における処理の流れを示す図である。
[図 5]本発明によるサーバ装置における処理の流れを示す図である。
[図 6]API呼出手順記述ファイルの例を示す図である。
[図 7]API呼出手順記述ファイル中の qname要素の説明する図である。
[図 8]API呼出手順記述ファイル中の element要素の説明する図である。
[図 9]API呼出手順記述ファイル中の complextype要素の説明する図である。
[図 10]API呼出手順記述ファイル中の operation要素の説明する図である。
[図 11]API呼出手順記述ファイル中の setproperty要素の説明する図である。
[図 12]ハッシュテーブルへオブジェクト格納した例を示す図である。
[図 13]入力パラメータの例を示す図である。
[図 14]入力パラメータの第二の例 (パラメータが二次元)を示す図である。
[図 15]サービス識別子対応表記憶部の例を示す図である。
[図 16]サービス識別子対応表記憶部の第二の例を示す図である。
[図 17]本発明による端末装置とサーバ装置の第 2の例の構成図である。
[図 18]本発明による端末装置とサーバ装置の第 2の例における入力パラメータの例 を示す図である。
[図 19]従来の一般的な Webサービスの呼び出し例を説明する図である。
[図 20]WSDLファイルの例を示す図である。
[図 21]従来の一般的な Webサービスの呼び出しにおける、端末側の API呼び出しの 例を示す図である。
[図 22]Webサービスの呼び出しにスタブ'クラスを用いた構成図である。 [図 23]スタブ ·クラスの実装例を示す図である。
[図 24]スタブ'クラスを用いた Webサービスの呼び出し例を示す図である。
符号の説明
[0015] 10· · '端末装置、 20· · ·サーバ装置、 30· · 'Webサービスサーバ、 40· "通信網（インター ネット）、 100〜Webサービスシステム、 101…入出力部、 102…アプリケーション、 103 •••API呼出手順記述ファイル記憶部、 104— API呼出手順記述ファイル処理部、 105 …受信部、 106…送信部、 107…ライブラリ、 121· ··入力パラメータ、 122· ··サービス識 別子、 123· ··リクエストパラメータ、 124· ··レスポンスパラメータ、 125· ··サービスインター フェイス記述ファイル取得先、 126· ··メソッド特定情報、 201· ··サービス識別子対応表 記憶部、 202…サービスインターフェイス記述ファイル取得部、 203· -API呼出手順記 述ファイル生成部、 204· ··メソッド特定部、 205…受信部、 206· ··送信部、 225· "API呼 出手順記述ファイル
発明を実施するための最良の形態
[0016] 図 1に本発明による Webサービスシステムの全体図を示す。本例の Webサービス システム 100は、 Webサービスクライアントの役割を果たす携帯電話等の端末装置 10 と、アプリケーションプログラミングインターフェイス (API)の呼び出し手順を記述した API呼出手順記述ファイルを生成し、それを提供するサーバ装置 20と、 Webサービ スを蓄積し、それを提供する Webサービスサーバ 30と、を有し、これらはインターネッ ト等の通信網 40により相互に接続されて 、る。
[0017] 端末装置 10は、サーバ装置 20に対して利用する Webサービスを特定するサービス 識別子を送信する。サーバ装置 20は、サービス識別子に基づいて API呼出手順記 述ファイルを生成し、それを端末装置 10に送信する。端末装置 10は、 API呼出手順 記述ファイルに基づ 、て APIを呼び出し、 Webサービスサーバ 30上の Webサービス の呼び出しを行う。 Webサービスサーバ 30は呼び出された Webサービスを端末装置 10に提供する。
[0018] 図 2を参照して端末装置 10の構成について説明する。端末装置 10は、入出力部 10 1、アプリケーション 102、 API呼出手順記述ファイル記憶部 103、 API呼出手順記述フ アイル処理部 104、受信部 105、及び、送信部 106、を有する。 [0019] 入出力部 101は、 Webサービスを利用するアプリケーション 102との間で、パラメータ の入出力処理を行う。入出力部 101がアプリケーション 102から入力する入力パラメ一 タ 121は、利用する Webサービスを特定するサービス識別子 122、 Webサービスへリク エストを送信する際のパラメータとなるリクエストパラメータ 123、 Webサービスからのレ スポンスを受信する際のパラメータとなるレスポンスパラメータ 124の 3つのパラメータ を含む。入力パラメータ 121の例は、後に、図 13及び図 14を参照して説明する。
[0020] API呼出手順記述ファイル記憶部 103は、サーバ装置 20から受信した API呼出手順 記述ファイル 225をサービス識別子 122と関連付けて記憶する。これは、同一の API呼 出手順記述ファイル 225をサーバ装置 20から何度も受信することを防ぐキャッシュの 役割を果たす。
[0021] API呼出手順記述ファイル処理部 104は、 API呼出手順記述ファイル 225およびァプ リケーシヨン 102からのリクエストパラメータ 123及びレスポンスパラメータ 124を利用して 、実際に Webサービスサーバ 30上の Webサービスを呼び出す。この処理の詳細につ Vヽては後述する。受信部 105はサーバ装置 20からの API呼出手順記述ファイル 225の 受信、送信部 106はサーバ装置 20へのサービス識別子 122の送信をそれぞれ担う。
[0022] 次に、サーバ装置 20の構成にっ 、て説明する。サーバ装置 20は、サービス識別子 対応表記憶部 201、サービスインターフェイス記述ファイル取得部 202、 API呼出手順 記述ファイル生成部 203、メソッド特定部 204、受信部 205、及び、送信部 206を有する
[0023] サービス識別子対応表記憶部 201は、 Webサービスを特定するサービス識別子とそ れに関連付けられた情報を記憶する。このような情報には、 WSDLファイル取得先、 および呼び出すメソッドを特定するために必要なサービス名、バインド名、ポート名、 オペレーション名、引数名、返り値名とを含む。サービス識別子対応表記憶部 201の 例は、後に、図 15及び図 16を参照して説明する。
[0024] サービスインターフェイス記述ファイル取得部 202は、サービス識別子対応表記憶 部 201に記憶されている WSDLファイル取得先に従って、該当する WSDLファイル、 即ち、サービスインターフェイス記述ファイルを通信網 40を介して外部力も取得する。 ただし、サービスインターフェイス記述ファイルは、サービスインターフェイス記述ファ ィル取得部 202自身にあらカゝじめ記憶されて ヽる場合もある。
[0025] メソッド特定部 204は、サービス識別子に関連付けられたサービス名、ノ《インド名、 ポート名、オペレーション名、引数名、返り値名より、 WSDLファイル中に記載された複 数のメソッドから該当するメソッドを特定する。 API呼出手順記述ファイル生成部 203は 、特定されたメソッドを呼び出すのに必要な API手順を記述した API呼出手順記述フ アイル 225を生成する。この処理の詳細については後述する。
[0026] 受信部 205は端末装置 10力 サービス識別子 122の受信、送信部 206は端末装置 1 0への API呼出手順記述ファイル 225の送信をそれぞれ担う。
[0027] 図 3を参照して、本発明と図 22の従来技術との差異について説明する。従来技術 では、スタブ'クラス 2202を利用して Webサービスに接続しているため、新たに別の W ebサービスに接続するにはスタブ'クラス 2202を入れ替える必要があった。本例では 、スタブ'クラス 2202と同等の機能を、 APIの呼び出し手順を記述した API呼出手順記 述ファイル 225とそれを解釈する API呼出手順記述ファイル処理部 104によって実現し ている。従って、新たに別の Webサービスに接続する場合でも、 API呼出手順記述フ アイル処理部 104を構成するクラスファイルを入れ替える必要は無ぐ API呼出手順 記述ファイル 225をサーバ装置 20よりダウンロードして入れ替えるだけでよい。
[0028] 図 4のフローチャートに基づいて端末装置 10の処理の流れについて説明する。ステ ップ S401において、入出力部 101は、 Webサービスを利用するアプリケーション 102か ら入力パラメータ 121を受け付ける。ステップ S402において、入力パラメータ 121に含ま れるサービス識別子 122に関連付けられた API呼出手順記述ファイル 225が、 API呼出 手順記述ファイル記憶部 103に記憶されて 、る力否かを判断する。記憶されて 、る場 合には、その API呼出手順記述ファイル 225に基づいて、ステップ S405以降の処理を 行う。記憶されていない場合には、ステップ S403において、サーバ装置 20に対して A PI呼出手順記述ファイル 225のリクエストを行う。即ち、送信部 106は、入力パラメータ 1 21に含まれるサービス識別子 122をサーバ装置 20に送信する。
[0029] ステップ S404において、受信部 105は、サーバ装置 20より API呼出手順記述ファイル 225を受信する。ステップ S405において、アプリケーション 102から入力された入力パ ラメータ 121中に含まれるリクエストパラメータ 123の変換を行う。この処理の詳細につ いては後述する。
[0030] ステップ S406にお 、て、 API呼出手順記述ファイル処理部 104は、 API呼出手順記 述ファイル 225に基づいて APIを呼び出し、変換されたパラメータを用いて Webサービ スサーバ 30に対して Webサービスの呼び出しを行う。ステップ S407において、レスポ ンスパラメータ 124の変換を行う。即ち、 Webサービスの呼び出しによって得られた返 り値を、レスポンスパラメータ 124に基づいて変換する。ステップ S405及びステップ S40 7の詳細は、後に、図 13及び図 14を参照して説明する。
[0031] ステップ S408において、変換されたパラメータを入出力部 101よりアプリケーション 10 2に出力する。
[0032] 次に図 5のフローチャートに基づ!/、てサーバ装置 20の処理の流れにつ!、て説明す る。ステップ S501において、受信部 205は、サービス識別子 122を端末装置 10より受信 する。ステップ S502において、サービスインターフェイス記述ファイル取得部 202は、 サービス識別子対応表記憶部 20はり、受信したサービス識別子 122に関連付けられ た WSDLファイル取得先を検索し、検索した WSDLファイル取得先に従って、 WSDLフ アイル、即ち、サービスインターフェイス記述ファイルを外部力も取得する。上述のよう に、サービスインターフェイス記述ファイルをサービスインターフェイス記述ファイル取 得部 202自身が有する場合もある。
[0033] ステップ S503において、メソッド特定部 204は、そのサービス識別子 122に関連付け られたサービス名、バインド名、ポート名、オペレーション名、引数名、返り値名より、 WSDLファイル中に記載された複数のメソッドから該当するメソッドを特定する。
[0034] ステップ S504にお 、て、 API呼出手順記述ファイル生成部 203は、特定されたメソッ ドの呼び出しに必要な API呼出手順を記述した API呼出手順記述ファイル 225を生成 する。ステップ S505において、送信部 206は、生成された API呼出手順記述ファイル 2 25を端末装置 10に送信する。
[0035] ステップ S406における Webサービスの呼び出しについて詳細に説明する。 API呼出 手順記述ファイル処理部 104は、図 6に示す API呼出手順記述ファイル 225を読み込 み、 service要素の子要素の一つ一つに基づいて実際に APIの呼び出しを行う。以下 、図 7〜図 11に APIの呼び出し規則の例を挙げる。 [0036] 図 7では、名前空間名とローカル名より構成される修飾された名前 (qualified name) を表現する QNameオブジェクトを生成する APIを呼び出す場合の、 API呼出手順記述 ファイル 225の記述方法を示す。それぞれ、 qname要素 701の name属性が生成する Q Nameオブジェクトの名前、名前空間名を表す namespaceURI属性がコンストラクタの第 一引数、ローカル名を表す localPart属性がコンストラクタの第二引数となる。この qna me要素 701を読み込んだ API呼出手順記述ファイル処理部 104は、 702記載の APIを 呼び出すことになる。図 6の（1) (3) (8) (10)は図 21の（1) (3) (8) (10)に対応する。
[0037] 図 8では、 WSDL中の type要素にて定義されている要素を表現する Elementオブジェ タトを生成する APIを呼び出す場合の、 API呼出手順記述ファイル 225の記述方法を 示す。定義される型が単純型である場合には、 element要素 801の name属性が生成 する Elementオブジェクトの名前、参照する Qnameオブジェクトを表す qname属性がコ ンストラクタの第一引数、型を表す type属性がコンストラクタの第二引数、最小出現数 を表す minOccurs属性がコンストラクタの第三引数、最大出現数を表す maxOccurs属 性がコンストラクタの第四引数、要素を省略の可否を表す nillable属性がコンストラクタ の第五引数となる。この element要素 801を読み込んだ API呼出手順記述ファイル処 理部 104は、 802記載の APIを呼び出すことになる。定義される型が後述する複雑型で ある場合には、 type属性の代わりに参照する ComplexTypeオブジェクトを表す comple xType属性が付加され、 element要素 803を読み込んだ API呼出手順記述ファイル処 理部 104が、 804記載の APIを呼び出すことになる。図 6の（2) (4) (9)が図 21の（2) (4 ) (9)に対応する。
[0038] 図 9では、 WSDL中の type要素にて定義されている複雑型を表現する ComplexType オブジェクトを生成する APIを呼び出す場合の、 API呼出手順記述ファイル 225の記述 方法を示す。 complexType要素 901の name属性が生成する ComplexTypeオブジェクト の名前、 size属性がこの ComplexTypeオブジェクトを構成する Elementオブジェクトの 個数を表し、 complexType要素 901の子要素である part要素中の name属性力 この C omplexTypeオブジェクトを構成する Elementオブジェクトのそれぞれの名前を表す。 従って、この complexType要素 901を読み込んだ API呼出手順記述ファイル処理部 10 4は、 902記載の APIを呼び出すことになる。図 6の（5) (6) (7)が図 21の（5) (6) (7)に 対応する。
[0039] 図 10では、 WSDL中の portType要素の子要素である operation要素を表す Operatio nオブジェクトを生成する APIを呼び出す場合の、 API呼出手順記述ファイル 225の記 述方法を示す。 operation要素 1001の参照する Qnameオブジェクトを表す qname属性 を第一引数、引数の型を表す input属性を第二引数、返り値の型を表す output属性を 第三引数として、 Operationクラスの newlnstanceメソッドを呼び出す。従って、この oper ation要素 1001を読み込んだ API呼出手順記述ファイル処理部 104は、 1002記載の A PIを呼び出すことになる。図 6の（13)が図 21の（13)に対応する。
[0040] 図 11では、 Operationオブジェクトに対してプロパティを付加する場合の、 API呼出 手順記述ファイル 225の記述方法を示す。 SOAPのトランスポートプロトコルとして HTT Pを利用する際に SOAPActionヘッダを指定する場合、 setProperty要素 1101を読み 込んだ API呼出手順記述ファイル処理部 104は、 1102記載の APIを呼び出す。図 6の（ 12)が図 21の（12)に対応する。また、呼び出すサービスのエンドポイントを指定する 場合、 setProperty要素 1103を読み込んだ API呼出手順記述ファイル処理部 104は、 1 104記載の APIを呼び出す。図 6の（12)が図 21の（12)に対応する。
[0041] ただし、実際のプログラムでは図 7〜図 11のように動的に変数名を変えることはでき ない。そのため、 qname要素 701を読み込んだ API呼出手順記述ファイル処理部 104 は、実際に「qnameName」という名前のオブジェクトを生成するのではなぐ図 12の 120 1のようにハッシュテーブルなどへ生成したオブジェクトとその名前を関連付けて格納 する。また、参照時には 1202のようにそのノ、ッシュテーブル力も名前をキーにして該 当するオブジェクトを取得するようにする。
[0042] 次に、ステップ S405におけるリクエストパラメータの変換、およびステップ S407におけ るレスポンスパラメータの変換の詳細について説明する。通常 JSR172を用いた Webサ 一ビスの呼び出しでは、図 21 (a)(b)(c)のように Object型の配列にパラメータを格納し て APIを呼び出す。
[0043] 図 13は、アプリケーション 102から入力される入力パラメータ 121の例を示す。本例の 入力パラメータ 1301では、リクエストパラメータとしてオブジェクト配列の添え字、ォブ ジェタトの型、オブジェクトの値が関連付けられたものを含む。 API呼出手順記述ファ ィル処理部 104は、リクエストパラメータに従って図 13の 1302のように順にオブジェクト を配列に格納する。同様に、 Webサービスの呼び出しで得られる返り値も Object型の 配列に格納されて 、るため、レスポンスパラメータとしてオブジェクト配列の添え字、 オブジェクトの型を関連付け、そのオブジェクト配列の添え字力 得られるオブジェク トを指定されたオブジェクトの型に変換してアプリケーション 102へ出力する。図 14は、 入力パラメータ 121のオブジェクト配列が二次元の場合の例を示す。ただし、実際の プログラムでは「Objectl」や「input〇bject」のように動的に変数名を変えることはでき ないため、図 12の QNameオブジェクトの扱いと同様に、実際に「Objectl」や「inputObj ect」という名前のオブジェクトを生成するのではなぐハッシュテーブルなどへ生成し たオブジェクトとその名前を関連付けて格納、参照する。
[0044] サービス識別子対応表記憶部 201、メソッド特定部 204、およびステップ S503におけ るメソッド特定の処理の詳細にっ 、て説明する。
[0045] 図 15に示すように、サービス識別子対応表記憶部 201には、サービス識別子 1501、 WSDLファイル取得先 1502、サービス名 1503、バインド名 1504、ポート名 1505、ォペレ ーシヨン名 1506、引数名 1507、及び、返り値名 1508が記憶されている。 WSDLフアイ ル中には通常複数のメソッドを公開することが可能である力 サービス名以下のパラ メータによって実際に実行されるメソッドが特定される。これらのパラメータにおいて、 サービス名 1503が WSDL中の service要素の name属性に対応し、バインド名 1504が bi nding要素の name属性に対応し、ポート名 1505が portType要素の name属性に対応し 、オペレーション名 1506が portType要素の子要素である operation要素の name属性 に対応し、引数名 1507が operation要素の子要素である input要素の name属性に対 応し、返り値名 1508が operation要素の子要素である output要素の name属性に対応 しており、それら全てに合致するメソッドが特定される。サービス名以下のパラメータ はメソッドを特定するためだけに用いられるものであり、同等の目的を達成するもので あれば本質的に他の情報でも問題はな ヽ。
[0046] 図 16はサービス識別子対応表記憶部 201の他の例を示す。この例では、それぞれ の要素が WSDLファイル中の何行目に存在するかという情報が記憶されている。
[0047] ステップ S504における API呼出記述ファイルの生成処理および API呼出手順記述フ アイル生成部 203の詳細について説明する。まず、通常のスタブの生成と同様にステ ップ S503において特定されたメソッドの呼び出しに必要な一連の API呼び出し（図 21 の（1)〜（13) )を生成する。次に、得られた一連の API呼び出しから図 7〜図 11の変 換規則を逆方向に適用して API呼出手順記述ファイル（図 6)を生成する。
[0048] 図 17を参照して本発明による端末装置とサーバ装置の第 2の例を説明する。ここで は、図 2の第 1の例と異なる部分のみを説明する。第 1の例では、サーバ装置 20は、 端末装置 10からのサービス識別子 122を受信し、サービス識別子対応表記憶部 201 にてサービス識別子 122に関連付けられた情報を取得した。本例では、これら必要な 情報を全て端末装置 10から受信するため、サービス識別子対応表記憶部 201が省略 されている。入出力部 101がアプリケーション 102から入力する入力パラメータ 121は、 サービス識別子 122の代わりに、サービスインターフェイス記述ファイル取得先 125お よびメソッド特定情報 126を含む。従って、入力パラメータ 121は、サービスインターフ ェイス記述ファイル取得先 125、メソッド特定情報 126、リクエストパラメータ 123、及び、 レスポンスパラメータ 124の 5つのパラメータを含む。
[0049] 図 18は、本例のアプリケーション 102より入力される入力パラメータ 121を示す。端末 装置 10は、サービスインターフェイス記述ファイル取得先 125およびメソッド特定情報 1 26を含む入力パラメータ 121をサーバ装置 20に送信するため、サーバ装置 20では第 1の例のサービス識別子対応表記憶部 201を省略することができる。
[0050] 本例では、第 1の例と比較するため必要な全ての情報がアプリケーション力 入力 される例を示したが、その必要な情報の一部がアプリケーション力も入力され、残りを サーバ装置 20のサービス識別子対応表記憶部 201が補間するような構成でもよい。
[0051] 以上、本発明の例を説明したが、本発明は上述の例に限定されるものではなぐ特 許請求の範囲に記載された発明の範囲にて様々な変更が可能であることは当業者 に理解されよう。

Claims

請求の範囲
[1] Webサービスを提供する Webサービスサーバ装置及びアプリケーションプログラミン グィンターフェイス (API)の呼び出し手順を記述した API呼出手順記述ファイルを提 供する API呼出手順記述ファイルサーバ装置との間で通信可能な通信部と、 上記 Webサービスを利用したアプリケーションを実行し、上記 Webサービスを利用 するために必要なパラメータを出力するアプリケーション部と、
上記 API呼出手順記述ファイルサーバ装置から送信された API呼出手順記述ファ ィルに基づ 、て、上記 Webサービスサーバ装置の Webサービスを呼び出す API呼 出手順記述ファイル処理部と、を有することを特徴とする端末装置。
[2] 請求項 1記載の端末装置にお 、て、上記パラメータは、 Webサービスを識別するた めのサービス識別子を含み、上記通信部は、 API呼出手順記述ファイルサーバ装置 に対して、利用する Webサービスを識別するための上記サービス識別子を送信する ことを特徴とする端末装置。
[3] 請求項 1記載の端末装置にお ヽて、上記パラメータは、サービスインターフェイス記 述ファイルの取得先を含み、上記通信部は、 API呼出手順記述ファイルサーバ装置 に対して、上記サービスインターフェイス記述ファイル取得先を送信することを特徴と する端末装置。
[4] 請求項 1記載の端末装置にお!、て、上記パラメータは、 API呼出手順記述ファイル 中に記載された複数のメソッドから所定のメソッドを特定するメソッド特定情報を含み 、上記通信部は、 API呼出手順記述ファイルサーバ装置に対して、上記メソッド特定 情報を送信することを特徴とする端末装置。
[5] 請求項 1記載の端末装置において、上記パラメータは、 Webサービスへリクエストを送 信する際のパラメータとなるリクエストパラメータ、及び、 Webサービスからのレスポンス を受信する際のパラメータとなるレスポンスパラメータを含むことを特徴とする端末装 置。
[6] 端末装置からのリクエストに基づいて、サービスインターフェイス記述ファイルを取得 するサービスインターフェイス記述ファイル取得部と、
上記サービスインターフェイス記述ファイルに記載された複数のメソッド力 所定の メソッドを特定するメソッド特定咅と、
上記特定されたメソッドに基づいて API呼出手順記述ファイルを生成する API呼出 手順記述ファイル生成部と、
を有し、
上記 API呼出手順記述ファイルを上記端末装置に送信することを特徴とするサー バ装置。
[7] 請求項 6に記載のサーバ装置において、上記サービスインターフェイス記述ファイル 取得部は、外部力 又は自身の中から、上記サービスインターフェイス記述ファイル を取得することを特徴とするサーバ装置。
[8] 請求項 6に記載のサーバ装置において、 Webサービスを特定するサービス識別子と それに関連付けられた情報を記憶するサービス識別子対応表記憶部を有することを 特徴とするサーバ装置。
[9] 請求項 8に記載のサーバ装置において、上記サービスインターフェイス記述ファイル 取得部は、上記サービス識別子対応表記憶部に記憶されたサービス識別子に関連 付けられた情報に基づ 、て、上記サービスインターフェイス記述ファイルを取得する ことを特徴とするサーバ装置。
[10] 請求項 8に記載のサーバ装置において、上記メソッド特定部は、上記サービス識別 子対応表記憶部に記憶されたサービス識別子に関連付けられた情報に基づいて、 上記メソッドを特定することを特徴とするサーバ装置。
[11] 請求項 6に記載のサーバ装置において、上記サービスインターフェイス記述ファイル 取得部は、上記端末装置力 送信されたサービスインターフェイス記述ファイル取得 先に基づ 、て、上記サービスインターフェイス記述ファイルを取得することを特徴とす るサーバ装置。
[12] 請求項 6に記載のサーバ装置において、上記メソッド特定部は、上記端末装置から 送信されたメソッド特定情報に基づ!/、て、上記メソッドを特定することを特徴とするサ ーバ装置。
[13] Webサービスを提供する Webサービスサーバ装置と、アプリケーションプログラミング インターフェイス (API)の呼び出し手順を記述した API呼出手順記述ファイルを提供 する API呼出手順記述ファイルサーバ装置と、を有する Webサービス提供システムに おいて、端末装置が、上記 API呼出手順記述ファイルサーバ装置に対してサービス 識別子を送信すると、上記 API呼出手順記述ファイルサーバ装置は、上記サービス 識別子に基づ 、て API呼出手順記述ファイルを上記端末装置に送信し、上記端末 装置が上記 API呼出手順記述ファイルに基づ ヽて APIを呼び出し、上記 Webサー ビスサーバ装置の Webサービスの呼び出しを行 、、上記 Webサービスサーバ装置 は、呼び出された Webサービスを上記端末装置に提供することを特徴とする Webサ 一ビス提供システム。
PCT/JP2005/018512 2004-10-08 2005-10-06 端末装置、サーバ装置、及びWebサービス提供システム WO2006040991A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006540900A JPWO2006040991A1 (ja) 2004-10-08 2005-10-06 端末装置、サーバ装置、及びＷｅｂサービス提供システム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004-296065 2004-10-08
JP2004296065 2004-10-08

Publications (1)

Publication Number Publication Date
WO2006040991A1 true WO2006040991A1 (ja) 2006-04-20

Family

ID=36148286

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/018512 WO2006040991A1 (ja) 2004-10-08 2005-10-06 端末装置、サーバ装置、及びWebサービス提供システム

Country Status (2)

Country Link
JP (1) JPWO2006040991A1 (ja)
WO (1) WO2006040991A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015045332A1 (ja) * 2013-09-24 2015-04-02 Ｎｅｃプラットフォームズ株式会社 連携装置、連携システム、サービス連携方法およびプログラム記憶媒体
US11343320B2 (en) 2019-08-05 2022-05-24 Fujitsu Limited Information processing apparatus, access control system, and non-transitory computer-readable storage medium for storing access control program

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1083308A (ja) * 1996-04-23 1998-03-31 Sun Microsyst Inc スタブ検索及びローディング・サブシステム、スタブ検索及びローディング方法並びにスタブ検索及びローディング用記録媒体
JP2002505463A (ja) * 1998-02-26 2002-02-19 サン・マイクロシステムズ・インコーポレーテッド 分散システム内の遠隔処理呼出に関連する処理をおこなうためのダウンロード可能なスマートプロキシ
JP2002132739A (ja) * 2000-10-23 2002-05-10 Nec Corp スタブ検索ローディングシステム及び方法、サーバ装置、クライアント装置並びにコンピュータ可読記録媒体

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2807254B1 (fr) * 2000-03-31 2004-08-27 Schneider Automation Systeme d'acces a un ensemble d'automatisme programmable sur une architecture wap
JP2004030360A (ja) * 2002-06-27 2004-01-29 Japan Telecom Co Ltd Ｗｅｂサービスの提供システムおよび提供支援システム
JP2004280398A (ja) * 2003-03-14 2004-10-07 Toshiba Corp サービス提供側プログラム、利用側プログラム及び方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1083308A (ja) * 1996-04-23 1998-03-31 Sun Microsyst Inc スタブ検索及びローディング・サブシステム、スタブ検索及びローディング方法並びにスタブ検索及びローディング用記録媒体
JP2002505463A (ja) * 1998-02-26 2002-02-19 サン・マイクロシステムズ・インコーポレーテッド 分散システム内の遠隔処理呼出に関連する処理をおこなうためのダウンロード可能なスマートプロキシ
JP2002132739A (ja) * 2000-10-23 2002-05-10 Nec Corp スタブ検索ローディングシステム及び方法、サーバ装置、クライアント装置並びにコンピュータ可読記録媒体

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MATSUURA ET AL.: "Web Service Application ni Chosen", JAVA DEVELOPER, 1 August 2003 (2003-08-01), SOFTBANK PUBLISHING INC, pages 106 - 111, XP002998985 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015045332A1 (ja) * 2013-09-24 2015-04-02 Ｎｅｃプラットフォームズ株式会社 連携装置、連携システム、サービス連携方法およびプログラム記憶媒体
JP2015064682A (ja) * 2013-09-24 2015-04-09 Ｎｅｃプラットフォームズ株式会社 外部サービス連携システム、外部サービス連携装置、外部サービス連携方法、および、コンピュータ・プログラム
US11343320B2 (en) 2019-08-05 2022-05-24 Fujitsu Limited Information processing apparatus, access control system, and non-transitory computer-readable storage medium for storing access control program

Also Published As

Publication number Publication date
JPWO2006040991A1 (ja) 2008-05-15

Similar Documents

Publication Publication Date Title
US8656417B2 (en) Interface for telecommunication services using uniform resource identifiers
JP5241440B2 (ja) コンポーネントベースの無線アプリケーションを作成して同アプリケーションと通信するためのシステム及び方法
US7552265B2 (en) System and method for providing context information
US8521754B2 (en) System and methods for web data transformation sourcing
US7526482B2 (en) System and method for enabling components on arbitrary networks to communicate
US20040255005A1 (en) Web server resident on a mobile computing device
US20100050167A1 (en) System and method for facilitating development of an application and supporting access to a plurality of heterogeneous backend servers
JP2006512694A (ja) プラットホーム中立ジェネリックサービスのクライアントアプリケーションの構築及び実行のためのシステム及び方法
EP1719288A4 (en) SYSTEM AND METHOD FOR ASYNCHRONOUS COMMUNICATION WITH WEB SERVICES USING MESSAGE DEFINITIONS
AU2002351015A1 (en) Method and device for defining objects allowing to establish a device management tree for mobile communication devices
WO2008134895A1 (en) Xml push and remote execution of a wireless application
JP2004519757A (ja) 媒介物に記憶されるデータへのサービスからのアクセス
CN111901157B (zh) 一种基于k8s的服务部署方法、装置、设备、介质
CN100566311C (zh) 供应组件应用程序的系统和方法
KR100901281B1 (ko) 유비쿼터스 웹서비스 방법
CN100505711C (zh) 管理组件应用程序的通信的系统和方法
CN101167327A (zh) 通过移动应用程序访问多个数据源的系统和方法
US7665096B2 (en) DDS-assisted CORBA discovery
CA2604900C (en) System and method for discovering wireless mobile applications
EP1872207A1 (en) System and method of presenting entities of standard device applications in wireless devices
WO2006040991A1 (ja) 端末装置、サーバ装置、及びWebサービス提供システム
CA2544116C (en) System and method for facilitating development of an application and supporting access to a plurality of heterogeneous backend servers
Sward Using ada in a service-Ooriented architecture
EP1715646B1 (en) System and method for connecting applications to heterogeneous backend servers via a gateway server
JP2007066295A (ja) Ｗｅｂサービス接続用開発フレームワーク

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

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

Ref document number: 2006540900

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载