JPWO2006040991A1 - 端末装置、サーバ装置、及びＷｅｂサービス提供システム - Google Patents

Abstract

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

Description

本発明は、携帯電話等の端末装置に関し、特に、端末装置をＷｅｂサービスのサービスクライアントとして利用する技術に関するものである。

昨今の携帯電話の高機能化にはめざましいものがあり、インターネット接続に始まりカメラ・GPS（Global Positioning System）・ナビゲーションなど、単なる通話機器に留まらずパーソナライズ化されたサービスポータル端末としての様態を呈している。携帯電話内に様々な個人情報が蓄積され、決済処理ですら、携帯電話が手元にあれば可能になるために、携帯電話を常に身近に持ち歩くことはもはや日常的となっている。

一方で、企業内部および企業間におけるシステム間の連携においては、これまでのメインフレームを中心とした各ベンダーの独自技術に代わって、標準化されたXML（eXtended Markup Language）メッセージのやり取りによって外部のサービスを呼び出すWebサービスが急速に普及している。

Webサービスでは、人間の作業が介在せずにコンピュータ同士が互いにサービスを呼び出すことが可能である。企業内部における各部署間を横断するようなシステムの統合化、企業間におけるリソースの集中活用を目的とした業務のアウトソーシング化をにらんで、現在様々なサービスがその規模を問わずWebサービスとして提供され始めている。

近年、携帯電話などの携帯端末を用いて、Webサービスを利用する試みが提案されている。例えば、JCP(JAVA Community Process)によって策定されたJSR172(J2ME Web Services Specification)では、端末であるWebサービスクライアントのJAVA実装の標準化が進められている。端末がWebサービスクライアントとしての機能を果たすためには、Webサービスのインターフェイスを記述したWSDL(Web Service Description Language)ファイルによって規定される適切なSOAP（Simple Object Access Protocol）メッセージをWebサービスサーバへ送信するプログラムを実装する必要がある。

図１９は、一般的なWebサービスの呼び出し方法を示す。Webサービスサーバは図示の例のようなインターフェイス1901を公開しており、このようなWebサービスサーバに対して、Webサービスクライアントより図示のようなWebサービスの呼び出し1902を行う場合を想定する。図２０は、Webサービスを呼び出すためのWSDLファイルの記述例を示す。Webサービスの呼び出しにJSR172で規定されているAPI(Application Programming Interface)を用いた場合、実際には図２１のような一連のAPIの呼び出しが必要となる。

しかしながら、一般的に携帯電話などの端末にて、図２０のようなWSDLファイルを解析し、図２１のようなAPIの呼び出しを行うことは、リソースの制限から非常に困難である。そのため、非特許文献１に記載されている例では、端末上で利用するスタブ・クラスをリソースの制限のない環境で生成した後、そのスタブ・クラスを端末にインストールする。

図２２はWebサービスの呼び出しにスタブ・クラスを用いた場合を示す。Webサービスクライアント2200は、アプリケーション2201、スタブ・クラス2202、及び、JSR172を実装したライブラリ2203を有する。アプリケーション2201は、そのスタブ・クラス2202を介してライブラリ2203を呼び出し、SOAPメッセージ2204をWebサービスサーバ2205に送信する。図２３は、スタブ・クラスの例を示す。スタブ・クラスは、図２３に示したように、Webサービスの呼び出しに必要なAPIの呼び出しを内部に隠蔽しているので、アプリケーション2201の開発者は図２４のように通常のクラスを扱う場合と同様にスタブ・クラスを扱えば、SOAPメッセージ2204の詳細な内容を意識せずにWebサービスを呼び出すことができる。

特許文献１には、サーバと端末間に代理サーバを設け、Webサービスクライアントとして必要な実装なしに、通常のWebブラウザ機能のみを有する端末からWebサービスを利用する技術が公開されている。端末からWebページ上にて所定のキーワードを入力すると、利用者の希望に合致した特定のWebサービスが抽出され、関連情報が代理サーバ装置へ送られる。代理サーバ装置はWSDL文書に記載されたプロトコルに基づいて専用APIを作成した上で、当該のWebサービスを提供するサーバ装置へ端末装置に代わってサービス要求を送る。その結果行われたサービスの提供について、代理サーバ装置から端末装置へ電子メールによるサービスの報告が行われる。
特開2004-30360号公報 JAVA WORLD 2004年3月号166ページ

携帯電話などの端末向けに定義されたJava実行環境の仕様としては現在MIDP(Mobile Information Device Profile)が主に利用されており、そのMIDP用に作られたアプリケーションの形式は「MIDlet」と呼ばれる。MIDPをサポートしている端末では、ネットワーク経由でMIDletをダウンロード及びインストールし、それを端末上で動作させることができる。しかしながら、MIDP上では、ユーザ定義のクラスローダ・リフレクションなどの機能をサポートしていないためクラスを動的に追加することができない。クラスを追加するためには追加したクラスを含むMIDletを新たにインストールしなければならない。そのため、様々なWebサービスを呼び出すようなアプリケーションを作成する際にも、それぞれのWebサービスに対応したスタブ・クラスを動的に追加することはできず、新規のWebサービスの呼び出しを行う度にそのWebサービスに対応したスタブ・クラスを含むMIDletを新たにインストールし直す必要がある。

本発明は、MIDPのように動的にクラスを追加できない環境においても、携帯電話のようなリソースの少ない端末上で複数のＷｅｂサービスへの動的な接続を可能にすることを目的とする。

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

本発明によれば、MIDPのように動的にクラスを追加できない環境においても、携帯電話のようなリソースの少ない端末上で複数のＷｅｂサービスへの動的な接続を可能にする。

本発明によるＷｅｂサービスシステムの概略図である。 本発明による端末装置とサーバ装置の第１の例の構成図である。 本発明による端末装置を従来技術と比較して説明する図である。 本発明による端末装置における処理の流れを示す図である。 本発明によるサーバ装置における処理の流れを示す図である。 ＡＰＩ呼出手順記述ファイルの例を示す図である。 ＡＰＩ呼出手順記述ファイル中のqname要素の説明する図である。 ＡＰＩ呼出手順記述ファイル中のelement要素の説明する図である。 ＡＰＩ呼出手順記述ファイル中のcomplextype要素の説明する図である。 ＡＰＩ呼出手順記述ファイル中のoperation要素の説明する図である。 ＡＰＩ呼出手順記述ファイル中のsetproperty要素の説明する図である。 ハッシュテーブルへオブジェクト格納した例を示す図である。 入力パラメータの例を示す図である。 入力パラメータの第二の例（パラメータが二次元）を示す図である。 サービス識別子対応表記憶部の例を示す図である。 サービス識別子対応表記憶部の第二の例を示す図である。 本発明による端末装置とサーバ装置の第２の例の構成図である。 本発明による端末装置とサーバ装置の第２の例における入力パラメータの例を示す図である。 従来の一般的なWebサービスの呼び出し例を説明する図である。 WSDLファイルの例を示す図である。 従来の一般的なWebサービスの呼び出しにおける、端末側のAPI呼び出しの例を示す図である。 Webサービスの呼び出しにスタブ・クラスを用いた構成図である。 スタブ・クラスの実装例を示す図である。 スタブ・クラスを用いたWebサービスの呼び出し例を示す図である。

符号の説明

10…端末装置、20…サーバ装置、30…Webサービスサーバ、40…通信網（インターネット）、100…Ｗｅｂサービスシステム、101…入出力部、102…アプリケーション、103…API呼出手順記述ファイル記憶部、104…API呼出手順記述ファイル処理部、105…受信部、106…送信部、107…ライブラリ、121…入力パラメータ、122…サービス識別子、123…リクエストパラメータ、124…レスポンスパラメータ、125…サービスインターフェイス記述ファイル取得先、126…メソッド特定情報、201…サービス識別子対応表記憶部、202…サービスインターフェイス記述ファイル取得部、203…API呼出手順記述ファイル生成部、204…メソッド特定部、205…受信部、206…送信部、225…API呼出手順記述ファイル

図１に本発明によるＷｅｂサービスシステムの全体図を示す。本例のＷｅｂサービスシステム100は、Ｗｅｂサービスクライアントの役割を果たす携帯電話等の端末装置10と、アプリケーションプログラミングインターフェイス（ＡＰＩ）の呼び出し手順を記述したＡＰＩ呼出手順記述ファイルを生成し、それを提供するサーバ装置20と、Ｗｅｂサービスを蓄積し、それを提供するＷｅｂサービスサーバ30と、を有し、これらはインターネット等の通信網40により相互に接続されている。

端末装置10は、サーバ装置20に対して利用するＷｅｂサービスを特定するサービス識別子を送信する。サーバ装置20は、サービス識別子に基づいてＡＰＩ呼出手順記述ファイルを生成し、それを端末装置10に送信する。端末装置10は、ＡＰＩ呼出手順記述ファイルに基づいてＡＰＩを呼び出し、Ｗｅｂサービスサーバ30上のＷｅｂサービスの呼び出しを行う。Ｗｅｂサービスサーバ30は呼び出されたＷｅｂサービスを端末装置10に提供する。

図２を参照して端末装置10の構成について説明する。端末装置10は、入出力部101、アプリケーション102、API呼出手順記述ファイル記憶部103、API呼出手順記述ファイル処理部104、受信部105、及び、送信部106、を有する。

入出力部101は、Webサービスを利用するアプリケーション102との間で、パラメータの入出力処理を行う。入出力部101がアプリケーション102から入力する入力パラメータ121は、利用するWebサービスを特定するサービス識別子122、Webサービスへリクエストを送信する際のパラメータとなるリクエストパラメータ123、Webサービスからのレスポンスを受信する際のパラメータとなるレスポンスパラメータ124の3つのパラメータを含む。入力パラメータ121の例は、後に、図１３及び図１４を参照して説明する。

API呼出手順記述ファイル記憶部103は、サーバ装置20から受信したAPI呼出手順記述ファイル225をサービス識別子122と関連付けて記憶する。これは、同一のAPI呼出手順記述ファイル225をサーバ装置20から何度も受信することを防ぐキャッシュの役割を果たす。

API呼出手順記述ファイル処理部104は、API呼出手順記述ファイル225およびアプリケーション102からのリクエストパラメータ123及びレスポンスパラメータ124を利用して、実際にWebサービスサーバ30上のWebサービスを呼び出す。この処理の詳細については後述する。受信部105はサーバ装置20からのAPI呼出手順記述ファイル225の受信、送信部106はサーバ装置20へのサービス識別子122の送信をそれぞれ担う。

次に、サーバ装置20の構成について説明する。サーバ装置20は、サービス識別子対応表記憶部201、サービスインターフェイス記述ファイル取得部202、API呼出手順記述ファイル生成部203、メソッド特定部204、受信部205、及び、送信部206を有する。

サービス識別子対応表記憶部201は、Webサービスを特定するサービス識別子とそれに関連付けられた情報を記憶する。このような情報には、WSDLファイル取得先、および呼び出すメソッドを特定するために必要なサービス名、バインド名、ポート名、オペレーション名、引数名、返り値名とを含む。サービス識別子対応表記憶部201の例は、後に、図１５及び図１６を参照して説明する。

サービスインターフェイス記述ファイル取得部202は、サービス識別子対応表記憶部201に記憶されているＷＳＤＬファイル取得先に従って、該当するＷＳＤＬファイル、即ち、サービスインターフェイス記述ファイルを通信網40を介して外部から取得する。ただし、サービスインターフェイス記述ファイルは、サービスインターフェイス記述ファイル取得部202自身にあらかじめ記憶されている場合もある。

メソッド特定部204は、サービス識別子に関連付けられたサービス名、バインド名、ポート名、オペレーション名、引数名、返り値名より、WSDLファイル中に記載された複数のメソッドから該当するメソッドを特定する。API呼出手順記述ファイル生成部203は、特定されたメソッドを呼び出すのに必要なAPI手順を記述したAPI呼出手順記述ファイル225を生成する。この処理の詳細については後述する。

受信部205は端末装置10からサービス識別子122の受信、送信部206は端末装置10へのAPI呼出手順記述ファイル225の送信をそれぞれ担う。

図３を参照して、本発明と図２２の従来技術との差異について説明する。従来技術では、スタブ・クラス2202を利用してWebサービスに接続しているため、新たに別のWebサービスに接続するにはスタブ・クラス2202を入れ替える必要があった。本例では、スタブ・クラス2202と同等の機能を、APIの呼び出し手順を記述したＡＰＩ呼出手順記述ファイル225とそれを解釈するAPI呼出手順記述ファイル処理部104によって実現している。従って、新たに別のWebサービスに接続する場合でも、API呼出手順記述ファイル処理部104を構成するクラスファイルを入れ替える必要は無く、ＡＰＩ呼出手順記述ファイル225をサーバ装置20よりダウンロードして入れ替えるだけでよい。

図４のフローチャートに基づいて端末装置10の処理の流れについて説明する。ステップS401において、入出力部101は、Webサービスを利用するアプリケーション102から入力パラメータ121を受け付ける。ステップS402において、入力パラメータ121に含まれるサービス識別子122に関連付けられたAPI呼出手順記述ファイル225が、API呼出手順記述ファイル記憶部103に記憶されているか否かを判断する。記憶されている場合には、そのAPI呼出手順記述ファイル225に基づいて、ステップS405以降の処理を行う。記憶されていない場合には、ステップS403において、サーバ装置20に対してAPI呼出手順記述ファイル225のリクエストを行う。即ち、送信部106は、入力パラメータ121に含まれるサービス識別子122をサーバ装置20に送信する。

ステップS404において、受信部105は、サーバ装置20よりAPI呼出手順記述ファイル225を受信する。ステップS405において、アプリケーション102から入力された入力パラメータ121中に含まれるリクエストパラメータ123の変換を行う。この処理の詳細については後述する。

ステップS406において、API呼出手順記述ファイル処理部104は、API呼出手順記述ファイル225に基づいてAPIを呼び出し、変換されたパラメータを用いてWebサービスサーバ30に対してWebサービスの呼び出しを行う。ステップS407において、レスポンスパラメータ124の変換を行う。即ち、Webサービスの呼び出しによって得られた返り値を、レスポンスパラメータ124に基づいて変換する。ステップS405及びステップS407の詳細は、後に、図１３及び図１４を参照して説明する。

ステップS408において、変換されたパラメータを入出力部101よりアプリケーション102に出力する。

次に図５のフローチャートに基づいてサーバ装置20の処理の流れについて説明する。ステップS501において、受信部205は、サービス識別子122を端末装置10より受信する。ステップS502において、サービスインターフェイス記述ファイル取得部202は、サービス識別子対応表記憶部201より、受信したサービス識別子122に関連付けられたWSDLファイル取得先を検索し、検索したWSDLファイル取得先に従って、WSDLファイル、即ち、サービスインターフェイス記述ファイルを外部から取得する。上述のように、サービスインターフェイス記述ファイルをサービスインターフェイス記述ファイル取得部202自身が有する場合もある。

ステップS503において、メソッド特定部204は、そのサービス識別子122に関連付けられたサービス名、バインド名、ポート名、オペレーション名、引数名、返り値名より、WSDLファイル中に記載された複数のメソッドから該当するメソッドを特定する。

ステップS504において、API呼出手順記述ファイル生成部203は、特定されたメソッドの呼び出しに必要なAPI呼出手順を記述したAPI呼出手順記述ファイル225を生成する。ステップS505において、送信部206は、生成されたAPI呼出手順記述ファイル225を端末装置10に送信する。

ステップS406におけるWebサービスの呼び出しについて詳細に説明する。API呼出手順記述ファイル処理部104は、図６に示すAPI呼出手順記述ファイル225を読み込み、service要素の子要素の一つ一つに基づいて実際にAPIの呼び出しを行う。以下、図7〜図11にAPIの呼び出し規則の例を挙げる。

図7では、名前空間名とローカル名より構成される修飾された名前(qualified name)を表現するQNameオブジェクトを生成するAPIを呼び出す場合の、API呼出手順記述ファイル225の記述方法を示す。それぞれ、qname要素701のname属性が生成するQNameオブジェクトの名前、名前空間名を表すnamespaceURI属性がコンストラクタの第一引数、ローカル名を表すlocalPart属性がコンストラクタの第二引数となる。このqname要素701を読み込んだAPI呼出手順記述ファイル処理部104は、702記載のAPIを呼び出すことになる。図6の（１）（３）（８）（１０）は図２1の（１）（３）（８）（１０）に対応する。

図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オブジェクトを表すcomplexType属性が付加され、element要素803を読み込んだAPI呼出手順記述ファイル処理部104が、804記載のAPIを呼び出すことになる。図6の（２）（４）（９）が図２1の（２）（４）（９）に対応する。

図9では、WSDL中のtype要素にて定義されている複雑型を表現するComplexTypeオブジェクトを生成するAPIを呼び出す場合の、API呼出手順記述ファイル225の記述方法を示す。complexType要素901のname属性が生成するComplexTypeオブジェクトの名前、size属性がこのComplexTypeオブジェクトを構成するElementオブジェクトの個数を表し、complexType要素901の子要素であるpart要素中のname属性が、このComplexTypeオブジェクトを構成するElementオブジェクトのそれぞれの名前を表す。従って、このcomplexType要素901を読み込んだAPI呼出手順記述ファイル処理部104は、902記載のAPIを呼び出すことになる。図6の（５）（６）（７）が図２1の（５）（６）（７）に対応する。

図10では、WSDL中のportType要素の子要素であるoperation要素を表すOperationオブジェクトを生成するAPIを呼び出す場合の、API呼出手順記述ファイル225の記述方法を示す。operation要素1001の参照するQnameオブジェクトを表すqname属性を第一引数、引数の型を表すinput属性を第二引数、返り値の型を表すoutput属性を第三引数として、OperationクラスのnewInstanceメソッドを呼び出す。従って、このoperation要素1001を読み込んだAPI呼出手順記述ファイル処理部104は、1002記載のAPIを呼び出すことになる。図6の（１３）が図２1の（１３）に対応する。

図１1では、Operationオブジェクトに対してプロパティを付加する場合の、API呼出手順記述ファイル225の記述方法を示す。SOAPのトランスポートプロトコルとしてHTTPを利用する際にSOAPActionヘッダを指定する場合、setProperty要素1101を読み込んだAPI呼出手順記述ファイル処理部104は、1102記載のAPIを呼び出す。図6の（１２）が図２1の（１２）に対応する。また、呼び出すサービスのエンドポイントを指定する場合、setProperty要素1103を読み込んだAPI呼出手順記述ファイル処理部104は、1104記載のAPIを呼び出す。図6の（１２）が図２1の（１２）に対応する。

ただし、実際のプログラムでは図7〜図11のように動的に変数名を変えることはできない。そのため、qname要素701を読み込んだAPI呼出手順記述ファイル処理部104は、実際に「qnameName」という名前のオブジェクトを生成するのではなく、図12の1201のようにハッシュテーブルなどへ生成したオブジェクトとその名前を関連付けて格納する。また、参照時には1202のようにそのハッシュテーブルから名前をキーにして該当するオブジェクトを取得するようにする。

次に、ステップS405におけるリクエストパラメータの変換、およびステップS407におけるレスポンスパラメータの変換の詳細について説明する。通常JSR172を用いたWebサービスの呼び出しでは、図２1 (a)(b)(c)のようにObject型の配列にパラメータを格納してAPIを呼び出す。

図13は、アプリケーション102から入力される入力パラメータ121の例を示す。本例の入力パラメータ1301では、リクエストパラメータとしてオブジェクト配列の添え字、オブジェクトの型、オブジェクトの値が関連付けられたものを含む。API呼出手順記述ファイル処理部104は、リクエストパラメータに従って図13の1302のように順にオブジェクトを配列に格納する。同様に、Webサービスの呼び出しで得られる返り値もObject型の配列に格納されているため、レスポンスパラメータとしてオブジェクト配列の添え字、オブジェクトの型を関連付け、そのオブジェクト配列の添え字から得られるオブジェクトを指定されたオブジェクトの型に変換してアプリケーション102へ出力する。図14は、入力パラメータ121のオブジェクト配列が二次元の場合の例を示す。ただし、実際のプログラムでは「Object1」や「inputObject」のように動的に変数名を変えることはできないため、図12のQNameオブジェクトの扱いと同様に、実際に「Object1」や「inputObject」という名前のオブジェクトを生成するのではなく、ハッシュテーブルなどへ生成したオブジェクトとその名前を関連付けて格納、参照する。

サービス識別子対応表記憶部201、メソッド特定部204、およびステップS503におけるメソッド特定の処理の詳細について説明する。

図１５に示すように、サービス識別子対応表記憶部201には、サービス識別子1501、WSDLファイル取得先1502、サービス名1503、バインド名1504、ポート名1505、オペレーション名1506、引数名1507、及び、返り値名1508が記憶されている。WSDLファイル中には通常複数のメソッドを公開することが可能であるが、サービス名以下のパラメータによって実際に実行されるメソッドが特定される。これらのパラメータにおいて、サービス名1503がWSDL中のservice要素のname属性に対応し、バインド名1504がbinding要素のname属性に対応し、ポート名1505がportType要素のname属性に対応し、オペレーション名1506がportType 要素の子要素であるoperation要素のname属性に対応し、引数名1507がoperation 要素の子要素であるinput要素のname属性に対応し、返り値名1508がoperation 要素の子要素であるoutput要素のname属性に対応しており、それら全てに合致するメソッドが特定される。サービス名以下のパラメータはメソッドを特定するためだけに用いられるものであり、同等の目的を達成するものであれば本質的に他の情報でも問題はない。

図16はサービス識別子対応表記憶部201の他の例を示す。この例では、それぞれの要素がWSDLファイル中の何行目に存在するかという情報が記憶されている。

ステップS504におけるAPI呼出記述ファイルの生成処理およびAPI呼出手順記述ファイル生成部203の詳細について説明する。まず、通常のスタブの生成と同様にステップS503において特定されたメソッドの呼び出しに必要な一連のAPI呼び出し（図２1の（１）〜（１３））を生成する。次に、得られた一連のAPI呼び出しから図7〜図11の変換規則を逆方向に適用してAPI呼出手順記述ファイル（図6）を生成する。

図１７を参照して本発明による端末装置とサーバ装置の第２の例を説明する。ここでは、図２の第１の例と異なる部分のみを説明する。第１の例では、サーバ装置20は、端末装置10からのサービス識別子122を受信し、サービス識別子対応表記憶部201にてサービス識別子122に関連付けられた情報を取得した。本例では、これら必要な情報を全て端末装置10から受信するため、サービス識別子対応表記憶部201が省略されている。入出力部101がアプリケーション102から入力する入力パラメータ121は、サービス識別子122の代わりに、サービスインターフェイス記述ファイル取得先125およびメソッド特定情報126を含む。従って、入力パラメータ121は、サービスインターフェイス記述ファイル取得先125、メソッド特定情報126、リクエストパラメータ123、及び、レスポンスパラメータ124の５つのパラメータを含む。

図１８は、本例のアプリケーション102より入力される入力パラメータ121を示す。端末装置10は、サービスインターフェイス記述ファイル取得先125およびメソッド特定情報126を含む入力パラメータ121をサーバ装置20に送信するため、サーバ装置20では第１の例のサービス識別子対応表記憶部201を省略することができる。

本例では、第１の例と比較するため必要な全ての情報がアプリケーションから入力される例を示したが、その必要な情報の一部がアプリケーションから入力され、残りをサーバ装置20のサービス識別子対応表記憶部201が補間するような構成でもよい。

以上、本発明の例を説明したが、本発明は上述の例に限定されるものではなく、特許請求の範囲に記載された発明の範囲にて様々な変更が可能であることは当業者に理解されよう。

Claims (13)

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

Images