JP2009301480A - サービス接続システム及びサービス接続方法 - Google Patents

Abstract

【課題】Ｗｅｂサービスのインタフェースが全く異なる複数のＷｅｂサービスを、スタブを再生成することなく、１つのスタブで呼び分けることができるようなＷｅｂサービス接続方式を提供することを目的とする。
【解決手段】Ｗｅｂサービスリクエスタ２００はクライアントアプリケーション２１０からのデータオブジェクトを汎用型の要求データに変換して中継サーバ４００へ送信する。中継サーバ４００は当該汎用型の要求データを固有型の要求データに変換してＷｅｂサービスプロバイダ３００へ送信し、Ｗｅｂサービスプロバイダ３００から返信される固有型の応答データのデータ形式を汎用型の応答データに変換してＷｅｂサービスリクエスタ２００へ送信する。Ｗｅｂサービスリクエスタ２００は当該汎用型の応答データのデータ形式をデータオブジェクトに変換してクライアントアプリケーション２１０に返す。
【選択図】図１

Description

本発明は、サービス接続システム及びサービス接続方法に関するものである。本発明は、特に、Ｗｅｂサービス接続システムにおけるＷｅｂサービスメッセージ変換方式に関するものである。

ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ・Ｍａｒｋｕｐ・Ｌａｎｇｕａｇｅ）・Ｗｅｂサービス（以下、単にＷｅｂサービスと記す）は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ・Ｔｒａｎｓｆｅｒ・Ｐｒｏｔｏｃｏｌ）、ＸＭＬ、ＳＯＡＰ（Ｓｉｍｐｌｅ・Ｏｂｊｅｃｔ・Ａｃｃｅｓｓ・Ｐｒｏｔｏｃｏｌ）といったオープンなインターネット技術に基づいて、情報サービスをインターネット上に提供し、ネットワーク上の他のプログラムから呼び出して利用できるようにするものである。ここで、Ｗｅｂサービスを提供するプログラムをＷｅｂサービスプロバイダ、Ｗｅｂサービスを利用するプログラムをＷｅｂサービスリクエスタと呼ぶ。

Ｗｅｂサービスを呼び出すには、入出力パラメータとＳＯＡＰメッセージの間の変換とサーバとの通信を行うスタブと呼ばれるモジュールを、Ｗｅｂサービスのインタフェースを定義するＷｅｂサービス定義文書（ＷＳＤＬ（Ｗｅｂ・Ｓｅｒｖｉｃｅ・Ｄｅｆｉｎｉｔｉｏｎ・Ｌａｎｇｕａｇｅ、あるいは、Ｗｅｂ・Ｓｅｒｖｉｃｅｓ・Ｄｅｓｃｒｉｐｔｉｏｎ・Ｌａｎｇｕａｇｅ）文書）（以下、単にＷＳＤＬと記すことがある）に基づいて作成する必要がある。インタフェースが少しでも異なると、新たに別のスタブを作成しなければならない。

スタブの作成はＷＳＤＬからスタブを自動生成するツールの利用によって、開発の効率化が図られている（例えば、特許文献１〜４参照）。
特開２００５−１７４１２０号公報 特開２００６−７２９７８号公報 特開２００５−９２５３３号公報 特開２００４−２７２８７１号公報

Ｗｅｂサービスごとにスタブを作成する従来の方式では、サービスのインタフェースの変更、生成ツールの不具合があると、スタブを再生成又は修正し、クライアントを再構築する必要があるという課題があった。また、各ベンダのスタブ生成ツールが生成するスタブに互換性がなく、ツールが異なると、クライアントアプリケーションの作り方も変わってしまうという課題があった。

特許文献１に記載のシステムによれば、Ｗｅｂサービスのインタフェースが２つあるとき、両方のインタフェースに１つのスタブで対応できる場合があるが、２つのインタフェース間に類似性が必要という制約があった。

特許文献１に記載のシステムでは、あるＷｅｂサービスを呼び出していたＷｅｂサービスリクエスタに対して、Ｗｅｂサービス定義文書（ＷＳＤＬ）が少し変更された別のＷｅｂサービスを呼び出せるように変更を加える場合、スタブ（特許文献１の図２ではプロキシモジュールにあたる）の再生成を避けるために、データ変換モジュールで要求データ／応答データの形式を一方のものから他方のものに準じるように変換することによって、スタブの再生成なしに新規サービスを呼び出せるようにしている。しかしながら、２つのインタフェース間の類似性を判定して（特許文献１の図３の類似性判定モジュール）、構造的に類似と判定された場合しか、新規サービスが呼び出せないという制限があった。

本発明は、例えば、Ｗｅｂサービスの入出力データ（即ちインタフェース）が全く異なる複数のＷｅｂサービスを、スタブを再生成することなく、１つのスタブで呼び分けることができるようなＷｅｂサービス接続方式を提供することを目的とする。

本発明の一の態様に係るサービス接続システムは、
サービスの種類ごとに固有のデータ形式をもつ固有型の要求データに対し、固有のデータ形式をもつ固有型の応答データを返信することでサービスを提供するサービス提供装置が複数接続された通信ネットワークを利用するサービス接続システムにおいて、
サービスを利用するクライアントアプリケーションをＣＰＵ（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）で実行するアプリケーション実行部と、
アプリケーション実行部が実行するクライアントアプリケーションからサービスの種類を特定するサービスＩＤ（識別子）と任意のデータオブジェクトとの入力を受け付け、当該データオブジェクトのデータ形式を汎用のデータ形式に変換して汎用型の要求データを生成する要求側データ変換部と、
要求側データ変換部が入力を受け付けたサービスＩＤと要求側データ変換部が生成した汎用型の要求データとを送信する要求側データ通信部とを備えるサービス要求装置を有するとともに、
前記サービス要求装置から送信されたサービスＩＤと汎用型の要求データとを受信する第１の中継側データ通信部と、
第１の中継側データ通信部が受信した汎用型の要求データのデータ形式を、第１の中継側データ通信部が受信したサービスＩＤで特定される種類のサービス固有のデータ形式に変換して固有型の要求データを生成する中継側データ変換部と、
前記通信ネットワークを介して、中継側データ変換部が生成した固有型の要求データを、第１の中継側データ通信部が受信したサービスＩＤで特定される種類のサービスを提供するサービス提供装置へ送信し、当該サービス提供装置から返信される固有型の応答データを受信する第２の中継側データ通信部とを備える中継装置を有し、
中継側データ変換部は、第２の中継側データ通信部が受信した固有型の応答データのデータ形式を汎用のデータ形式に変換して汎用型の応答データを生成し、
第１の中継側データ通信部は、中継側データ変換部が生成した汎用型の応答データを前記サービス要求装置へ送信し、
要求側データ通信部は、前記中継装置から送信された汎用型の応答データを受信し、
要求側データ変換部は、要求側データ通信部が受信した汎用型の応答データのデータ形式を変換してデータオブジェクトを生成し、当該データオブジェクトをアプリケーション実行部が実行するクライアントアプリケーションに返すことを特徴とする。

本発明の一の態様によれば、サービス接続システムにおいて、
サービス要求装置が、クライアントアプリケーションから任意のデータオブジェクトの入力を受け付け、当該データオブジェクトのデータ形式を汎用のデータ形式に変換して汎用型の要求データを生成し、当該汎用型の要求データを中継装置へ送信し、
中継装置が、サービス要求装置から送信された汎用型の要求データのデータ形式をサービス固有のデータ形式に変換して固有型の要求データを生成し、当該固有型の要求データをサービス提供装置へ送信し、当該サービス提供装置から返信される固有型の応答データのデータ形式を汎用のデータ形式に変換して汎用型の応答データを生成し、当該汎用型の応答データをサービス要求装置へ送信し、
サービス要求装置が、中継装置から送信された汎用型の応答データのデータ形式を変換してデータオブジェクトを生成し、当該データオブジェクトをクライアントアプリケーションに返すことにより、
例えば、Ｗｅｂサービスの入出力データ（即ちインタフェース）が全く異なる複数のＷｅｂサービスを、スタブを再生成することなく、１つのスタブで呼び分けることができるようなＷｅｂサービス接続方式を提供することが可能となる。

以下、本発明の実施の形態について、図を用いて説明する。

実施の形態１．
図１は、本実施の形態に係るＷｅｂサービス接続システム１００（サービス接続システムの一例）の構成を示すブロック図である。

図１において、Ｗｅｂサービス接続システム１００は、Ｗｅｂサービスリクエスタ２００、Ｗｅｂサービスプロバイダ３００、中継サーバ４００を備える。Ｗｅｂサービスリクエスタ２００、Ｗｅｂサービスプロバイダ３００、中継サーバ４００は、通信ネットワーク５００に接続されている。図中、Ｗｅｂサービスリクエスタ２００、中継サーバ４００は１つずつしか示していないが、それぞれが複数存在してもよい。また、Ｗｅｂサービスプロバイダ３００も１つしか示していないが、実際には複数存在するものとする。それぞれのＷｅｂサービスプロバイダ３００は、Ｗｅｂサービス（サービスの一例）の種類ごとに固有のデータ形式をもつ固有型の要求データに対し、固有のデータ形式をもつ固有型の応答データを返信することでＷｅｂサービスを提供する。Ｗｅｂサービスプロバイダ３００は、Ｗｅｂサービスを１種類しか提供していなくてもよいし、２種類以上提供していてもよい。また、２つ以上のＷｅｂサービスプロバイダ３００が同じ種類のＷｅｂサービスを提供していてもよい。それぞれのＷｅｂサービスプロバイダ３００には、識別子として、少なくとも１つのＵＲＩ（Ｕｎｉｆｏｒｍ・Ｒｅｓｏｕｒｃｅ・Ｉｄｅｎｔｉｆｅｒ）が割り当てられているものとする。

Ｗｅｂサービスリクエスタ２００は、クライアントアプリケーション２１０、オブジェクト変換モジュール２２０、ＳＯＡＰ処理モジュール２３０を含むプログラムである。このプログラムは、コンピュータであるサービス要求装置によって実行される。サービス要求装置は、アプリケーション実行部、要求側データ変換部、要求側データ通信部を備える。また、図示していないが、サービス要求装置は、ＣＰＵ（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）、メモリ（ハードディスクドライブなども含む）、入力装置、出力装置などのハードウェアを備えるものとする。サービス要求装置の各部は、メモリに予め記憶されたプログラム（モジュール）をＣＰＵで読み取って実行することにより以下のように動作する。

まず、アプリケーション実行部は、Ｗｅｂサービスの種類を特定するサービスＩＤ（識別子）と、そのＷｅｂサービスを利用するための入力パラメータである任意のデータオブジェクトＸｑとを入力するクライアントアプリケーション２１０をＣＰＵで実行する。次に、要求側データ変換部は、オブジェクト変換モジュール２２０をＣＰＵで実行することにより、アプリケーション実行部が実行するクライアントアプリケーション２１０からサービスＩＤとデータオブジェクトＸｑとの入力を受け付ける。そして、要求側データ変換部は、データオブジェクトＸｑのデータ形式を汎用のデータ形式に変換して汎用型の要求データＹｑを生成する。次に、要求側データ通信部は、ＳＯＡＰ処理モジュール２３０を実行することにより、要求側データ変換部が入力を受け付けたサービスＩＤと要求側データ変換部が生成した汎用型の要求データＹｑとを、通信ネットワーク５００を介して中継装置へ送信する。

また、要求側データ通信部は、ＳＯＡＰ処理モジュール２３０を実行することにより、通信ネットワーク５００を介して中継装置から送信される汎用型の応答データＹｓを受信する。次に、要求側データ変換部は、オブジェクト変換モジュール２２０をＣＰＵで実行することにより、要求側データ通信部が受信した汎用型の応答データＹｓのデータ形式を変換してデータオブジェクトＸｓを生成する。そして、要求側データ変換部は、データオブジェクトＸｓをアプリケーション実行部が実行するクライアントアプリケーション２１０に返す。最後に、アプリケーション実行部は、クライアントアプリケーション２１０をＣＰＵで実行することにより、要求側データ変換部が返したデータオブジェクトＸｓを用いて、例えばＷｅｂサービスを利用した結果を画面などに表示する。

以下では、サービス要求装置の動作をＷｅｂサービスリクエスタ２００の動作として説明する場合がある。また、アプリケーション実行部、要求側データ変換部、要求側データ通信部の動作を、それぞれクライアントアプリケーション２１０、オブジェクト変換モジュール２２０、ＳＯＡＰ処理モジュール２３０の動作として説明する場合がある。

Ｗｅｂサービスプロバイダ３００は、Ｗｅｂサービス実装３１０、ＳＯＡＰ処理モジュール３３０を含むプログラムである。このプログラムは、コンピュータであるサービス提供装置によって実行される。サービス提供装置は、サービス処理実行部、提供側データ通信部を備える。また、図示していないが、サービス提供装置は、ＣＰＵ、メモリ、入力装置、出力装置などのハードウェアを備えるものとする。サービス提供装置の各部は、メモリに予め記憶されたプログラム（モジュール）をＣＰＵで読み取って実行することにより以下のように動作する。

まず、提供側データ通信部は、ＳＯＡＰ処理モジュール３３０を実行することにより、通信ネットワーク５００を介して中継装置から送信される固有型の要求データＺｑを受信する。次に、サービス処理実行部は、Ｗｅｂサービス実装３１０をＣＰＵで実行することにより、提供側データ通信部が受信した固有型の要求データＺｑに基づいて、Ｗｅｂサービスに係る処理を実行する。そして、サービス処理実行部は、当該実行結果として、固有型の応答データＺｓを返す。次に、提供側データ通信部は、サービス処理実行部が実行したＷｅｂサービス実装３１０から返された固有型の応答データＺｓを受け取る。そして、提供側データ通信部は、固有型の応答データＺｓを、通信ネットワーク５００を介して中継装置へ送信する。

サービス提供装置は、さらに、ＷＳＤＬ格納部３４０を備える。ＷＳＤＬ格納部３４０は、サービス処理実行部が実行するＷｅｂサービス実装３１０が提供するＷｅｂサービスの種類ごとに、固有のデータ形式を定義するＷＳＤＬ（サービス定義ファイルの一例）をメモリに保持している。提供側データ通信部は、中継装置からＷｅｂサービスの種類を指定してＷＳＤＬを要求された場合、通信ネットワーク５００を介して、該当するＷＳＤＬを中継装置へ送信する。

以下では、サービス提供装置の動作をＷｅｂサービスプロバイダ３００の動作として説明する場合がある。また、サービス処理実行部、提供側データ通信部の動作を、それぞれＷｅｂサービス実装３１０、ＳＯＡＰ処理モジュール３３０の動作として説明する場合がある。

中継サーバ４００は、ＳＯＡＰ処理モジュール４１０、中継サービス４２０、メッセージ変換モジュール４３０、ＷＳＤＬ取得モジュール４４０を含むプログラムである。このプログラムは、コンピュータである中継装置によって実行される。中継装置は、第１の中継側データ通信部及び第２の中継側データ通信部、中継側データ変換部、ファイル取得部を備える。また、図示していないが、中継装置は、ＣＰＵ、メモリ、入力装置、出力装置などのハードウェアを備えるものとする。サービス要求装置の各部は、メモリに予め記憶されたプログラム（モジュール）をＣＰＵで読み取って実行することにより以下のように動作する。

まず、第１の中継側データ通信部は、ＳＯＡＰ処理モジュール４１０をＣＰＵで実行することにより、通信ネットワーク５００を介してサービス要求装置から送信されたサービスＩＤと汎用型の要求データＹｑとを受信する。そして、第１の中継側データ通信部は、中継サービス４２０をＣＰＵで実行することにより、サービスＩＤで特定される種類のサービスを提供するサービス提供装置を１つ選択する。次に、ファイル取得部は、第１の中継側データ通信部が選択したサービス提供装置からＷＳＤＬを取得する。このとき、ファイル取得部は、第１の中継側データ通信部が受信したサービスＩＤをサービス提供装置へ送信することにより、特定のＷｅｂサービスの種類を指定してＷＳＤＬを要求してもよい。次に、中継側データ変換部は、メッセージ変換モジュール４３０をＣＰＵで実行することにより、ファイル取得部が取得したＷＳＤＬで定義されるデータ形式を参照して、第１の中継側データ通信部が受信した汎用型の要求データＹｑのデータ形式を、第１の中継側データ通信部が受信したサービスＩＤで特定される種類のサービス固有のデータ形式に変換して固有型の要求データＺｑを生成する。次に、第２の中継側データ通信部は、ＳＯＡＰ処理モジュール４１０をＣＰＵで実行することにより、通信ネットワーク５００を介して、中継側データ変換部が生成した固有型の要求データＺｑを、第１の中継側データ通信部が選択したサービス提供装置へ送信する。

また、第２の中継側データ通信部は、ＳＯＡＰ処理モジュール４１０を実行することにより、固有型の要求データＺｑを送信したサービス提供装置から返信される固有型の応答データＺｓを受信する。次に、中継側データ変換部は、メッセージ変換モジュール４３０をＣＰＵで実行することにより、ファイル取得部が取得したＷＳＤＬで定義されるデータ形式を参照して、第２の中継側データ通信部が受信した固有型の応答データＺｓのデータ形式を汎用のデータ形式に変換して汎用型の応答データＹｓを生成する。次に、第１の中継側データ通信部は、ＳＯＡＰ処理モジュール４１０をＣＰＵで実行することにより、通信ネットワーク５００を介して、中継側データ変換部が生成した汎用型の応答データＹｓをサービス要求装置へ送信する。

中継装置は、さらに、サービスＩＤ／ＵＲＩマッピングデータベース４５０を備える。サービスＩＤ／ＵＲＩマッピングデータベース４５０は、サービスＩＤとＷｅｂサービスプロバイダ３００のＵＲＩとの対応関係をメモリに記憶するデータベースである。第１の中継側データ通信部は、サービスＩＤで特定される種類のサービスを提供するサービス提供装置を選択する際に、ファイル取得部に対し、当該サービスＩＤに対応するＵＲＩをサービスＩＤ／ＵＲＩマッピングデータベース４５０から抽出させ、当該ＵＲＩで特定されるサービス提供装置（複数ある場合には、その中の１つ）を選択してもよい。

以下では、中継装置の動作を中継サーバ４００の動作として説明する場合がある。また、第１の中継側データ通信部及び第２の中継側データ通信部、中継側データ変換部、ファイル取得部の動作を、それぞれＳＯＡＰ処理モジュール４１０、中継サービス４２０、メッセージ変換モジュール４３０、ＷＳＤＬ取得モジュール４４０の動作として説明する場合がある。

上記のように、本実施の形態では、特許文献１に記載のシステムと異なり、Ｗｅｂサービスリクエスタ２００にオブジェクト変換モジュール２２０を置いている。オブジェクト変換モジュール２２０はクライアントアプリケーション２１０からＷｅｂサービスに渡すデータオブジェクトを、ＷＳＤＬが定義するメッセージ形式に依存しない汎用的な形式の要求メッセージ（汎用型の要求データＹｑ）に変換するものである。オブジェクト変換モジュール２２０はＷｅｂサービスが返した汎用的な形式の応答メッセージ（汎用型の応答データＹｓ）を、データオブジェクトに変換することも行う。ここで、要求メッセージ及び応答メッセージは、文字列で表されるものとする。以下では、汎用的な形式の要求メッセージ及び応答メッセージを汎用メッセージという場合がある。

Ｗｅｂサービスリクエスタ２００からＷｅｂサービスプロバイダ３００のサービスを呼ぶとき、Ｗｅｂサービスリクエスタ２００は汎用メッセージ（汎用型の要求データＹｑ）を中継サーバ４００に送る。中継サーバ４００のメッセージ変換モジュール４３０は、ＷＳＤＬ取得モジュール４４０を介してＷｅｂサービスプロバイダ３００から取得したＷＳＤＬのメッセージ定義を参照しながら、汎用メッセージ（汎用型の要求データＹｑ）をサービス固有のメッセージ（固有型の要求データＺｑ）に変換し、Ｗｅｂサービスを呼び出す。Ｗｅｂサービスが返した応答メッセージ（固有型の応答データＺｓ）は、上記の経路を逆にたどって、中継サーバ４００で汎用メッセージ（汎用型の応答データＹｓ）に変換され、Ｗｅｂサービスリクエスタ２００のオブジェクト変換モジュール２２０で応答データ（データオブジェクトＸｓ）に変換され、クライアントアプリケーションに戻される。

図２は、Ｗｅｂサービスリクエスタ２００のプログラムを実行するサービス要求装置、Ｗｅｂサービスプロバイダ３００のプログラムを実行するサービス提供装置、中継サーバ４００のプログラムを実行する中継装置のハードウェア構成の一例を示す図である。

図２において、サービス要求装置、サービス提供装置、中継装置は、コンピュータであり、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）やＬＣＤ（液晶ディスプレイ）の表示画面を有する表示装置９０１、キーボード９０２（Ｋ／Ｂ）、マウス９０３、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ・Ｄｉｓｋ・Ｄｒｉｖｅ）、ＣＤＤ９０５（Ｃｏｍｐａｃｔ・Ｄｉｓｃ・Ｄｒｉｖｅ）、プリンタ装置９０６などのハードウェアを備え、これらはケーブルや信号線で接続されている。

サービス要求装置、サービス提供装置、中継装置は、プログラムを実行するＣＰＵ９１１を備えている。ＣＰＵ９１１は、バス９１２を介してＲＯＭ９１３（Ｒｅａｄ・Ｏｎｌｙ・Ｍｅｍｏｒｙ）、ＲＡＭ９１４（Ｒａｎｄｏｍ・Ａｃｃｅｓｓ・Ｍｅｍｏｒｙ）、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、ＦＤＤ９０４、ＣＤＤ９０５、プリンタ装置９０６、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカードリーダライタなどの記憶媒体が用いられてもよい。

ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、メモリの一例である。通信ボード９１５、キーボード９０２、マウス９０３、ＦＤＤ９０４、ＣＤＤ９０５などは、入力装置の一例である。また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。

通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）などに接続されている。通信ボード９１５は、ＬＡＮに限らず、インターネット、あるいは、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ・Ｐｒｏｔｏｃｏｌ・Ｖｉｒｔｕａｌ・Ｐｒｉｖａｔｅ・Ｎｅｔｗｏｒｋ）、広域ＬＡＮ、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ・Ｔｒａｎｓｆｅｒ・Ｍｏｄｅ）ネットワークなどのＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。ＬＡＮ、インターネット、ＷＡＮは、ネットワークの一例である。

磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。プログラム群９２３には、本実施の形態の説明において「〜部」として説明する機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。また、ファイル群９２４には、本実施の形態の説明において、「〜データ」、「〜情報」、「〜ＩＤ（識別子）」、「〜フラグ」、「〜結果」として説明するデータや情報や信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」や「〜テーブル」の各項目として記憶されている。「〜ファイル」や「〜データベース」や「〜テーブル」は、ディスクやメモリなどの記憶媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶されたデータや情報や信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・制御・出力・印刷・表示などのＣＰＵ９１１の処理（動作）に用いられる。抽出・検索・参照・比較・演算・計算・制御・出力・印刷・表示などのＣＰＵ９１１の処理中、データや情報や信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。

また、本実施の形態の説明において用いるブロック図やフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号は、ＲＡＭ９１４などのメモリ、ＦＤＤ９０４のフレキシブルディスク（ＦＤ）、ＣＤＤ９０５のコンパクトディスク（ＣＤ）、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク（ＭＤ）、ＤＶＤ（Ｄｉｇｉｔａｌ・Ｖｅｒｓａｔｉｌｅ・Ｄｉｓｃ）などの記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体により伝送される。

また、本実施の形態の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜工程」、「〜手順」、「〜処理」であってもよい。即ち、「〜部」として説明するものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。あるいは、ソフトウェアのみ、あるいは、素子・デバイス・基板・配線などのハードウェアのみ、あるいは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実現されていても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤなどの記録媒体に記憶される。このプログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。即ち、プログラムは、本実施の形態の説明で述べる「〜部」としてコンピュータを機能させるものである。あるいは、本実施の形態の説明で述べる「〜部」の手順や方法をコンピュータに実行させるものである。

クライアントアプリケーション２１０及びＷｅｂサービス実装３１０を記述するプログラム言語は、オブジェクトからそのクラスで定義されている変数の名前やデータ型の情報を取得するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ・Ｐｒｏｇｒａｍ・Ｉｎｔｅｒｆａｃｅ）、いわゆるリフレクション機能を実現しているものとする。ここではＪａｖａ（登録商標）言語の例を記述する。なお、データ型が１対１に対応可能な範囲で使用するのであれば、クライアントアプリケーション２１０とＷｅｂサービス実装３１０の記述言語が異なっていてもよい。

リフレクション機能をもつプログラム言語のデータオブジェクトと、汎用的な形式のメッセージを相互に変換する方法としては、例えば、Ｊａｖａ（登録商標）言語では、ｊａｖａ．ｂｅａｎｓ．ＸＭＬＥｎｃｏｄｅ及びＸＭＬＤｅｃｏｄｅという標準ＡＰＩがある。

図３に、データオブジェクトと、ＸＭＬで表された汎用的な形式のメッセージとの変換例を示す。メッセージの具体的な形式と変換手順はこれに限るものではないが、メッセージ形式は以下の特徴を備えているものとする。
（ａ）オブジェクトのデータ型と値が表せる。
（ｂ）構造型のフィールドの名前と、オブジェクトのデータ型と値が表せる。
（ｃ）オブジェクトの配列を表せる。
（ｄ）構造型のフィールドの１つが別の、あるいは、それ自身の型の構造型である、または配列であるなど、入れ子の構造を表せる。

Ｗｅｂサービスリクエスタ２００の動作を図４に示す。クライアントアプリケーション２１０は、例えばｍｙＢｅａｎというデータオブジェクト６０１（データオブジェクトＸｑ）を保持している。ｍｙＢｅａｎは、呼び出すサービスのＷＳＤＬ（図５のＷＳＤＬ７０１に相当）で定義されたメッセージ要素（ｅｌｅｍｅｎｔ）に合わせたプロパティ構成とする。クライアントアプリケーション２１０は、呼び出すＷｅｂサービスを識別するサービスＩＤと、ｍｙＢｅａｎを引数として、オブジェクト変換モジュール２２０のＡＰＩ（ここでは例としてｃａｌｌメソッドとする）を呼び出す。ｃａｌｌメソッドではｍｙＢｅａｎオブジェクトを汎用的な形式の要求メッセージである汎用メッセージ６０２（汎用型の要求データＹｑ）に変換する。汎用メッセージ６０２のメッセージ形式は、上記のＷＳＤＬに依存しないため、ＷＳＤＬに変更や追加などがあっても、オブジェクト変換モジュール２２０（スタブに相当）を変更又は再作成する必要はない。オブジェクト変換モジュール２２０は、ＳＯＡＰ処理モジュール２３０を通して、ＳＯＡＰメッセージ６０３を作成し、中継サーバ４００に送る。

中継サーバ４００でのメッセージ変換手順を図５に示す。中継サービス４２０はＳＯＡＰ処理モジュール４１０を通して、サービスＩＤと要求メッセージ（汎用型の要求データＹｑ）をＷｅｂサービスリクエスタ２００から受け取り、メッセージ変換モジュール４３０に渡す。メッセージ変換モジュール４３０では、サービスＩＤをＷＳＤＬ取得モジュール４４０に渡す。ＷＳＤＬ取得モジュールは、サービスＩＤ／ＵＲＩマッピングデータベース４５０から、サービスＩＤに対応するＷｅｂサービスプロバイダ３００のＵＲＩを得て、Ｗｅｂサービスプロバイダ３００からＷＳＤＬ７０１を取得し、メッセージ変換モジュール４３０に渡す。メッセージ変換モジュール４３０はＷＳＤＬ７０１のメッセージ定義を参照しながら、汎用メッセージ６０２をサービス固有のメッセージ６０４（固有型の要求データＺｑ）に逐次変換し、それをＷｅｂサービスプロバイダ３００に送信する。

インタフェースが異なり、別のＷＳＤＬをもつＷｅｂサービスプロバイダ３００のＷｅｂサービスを呼ぶ必要が生じたときは、中継サーバ４００のサービスＩＤ／ＵＲＩマッピングデータベース４５０にデータを追加し、Ｗｅｂサービスリクエスタ２００のクライアントアプリケーション２１０では、新たなＷＳＤＬに合わせたデータ型のオブジェクトを作成し、オブジェクト変換モジュール２２０を呼ぶときの引数であるサービスＩＤと、データオブジェクトを変更する。

Ｗｅｂサービスリクエスタ２００では、サービスＩＤによって異なるサービスを呼び分けることができるため、新たなＷｅｂサービス呼び出しを行うことになっても、スタブの再生成は不要であり、また特許文献１に記載のシステムのような、インタフェース類似性の制限も生じない。なお、特許文献１では、インタフェースが変更されてもクライアントプログラムの修正が不要であるという効果について記載されているが、それはクライアントプログラムの機能の変更が全くない場合に限定される。例えば、これまで使用していたプロバイダのＷｅｂサービスに加えて、別のプロバイダのサービスを使用する場合などは、クライアントプログラムの修正は必要となる。本実施の形態では、そのような場合におけるクライアントアプリケーション２１０の修正は必要最小限のものである。

以上説明した本実施の形態に係るＷｅｂサービス接続方法は、
（ａ）クライアント端末において、プログラム言語のデータオブジェクトの値を接続先のＷｅｂサービスのＷｅｂサービス定義文書に依存しない汎用的なデータ形式の要求メッセージに変換する工程、
（ｂ）クライアント端末において、汎用的なデータ形式の応答メッセージを、プログラム言語のデータオブジェクトの値に変換する工程、
（ｃ）ネットワークで、クライアント端末とＷｅｂサービス提供サーバの中間に置かれた中継サーバにおいて、Ｗｅｂサービス提供サーバよりＷｅｂサービス定義文書を取得する工程、
（ｄ）中継サーバにおいて、接続先のＷｅｂサービスのＷｅｂサービス定義文書に依存しない汎用的な要求メッセージを、接続先のＷｅｂサービス固有の形式の要求メッセージに変換する工程、
（ｅ）中継サーバにおいて、接続先のＷｅｂサービス固有の形式の応答メッセージを、汎用的な応答メッセージに変換する工程、
を備えることを特徴とする。

実施の形態２．
本実施の形態について、主に実施の形態１との差異を説明する。

実施の形態１では、一般的な構成のＷｅｂサービスプロバイダ３００を利用していたが、本実施の形態では、Ｗｅｂサービスリクエスタ２００がオブジェクト変換モジュール２２０を有するだけでなく、Ｗｅｂサービスプロバイダ３００も同様のモジュールを有する構成をとっている。この場合もスタブの再生成を不要にすることができる。

図６は、本実施の形態に係るＷｅｂサービス接続システム１００（サービス接続システムの一例）の構成を示すブロック図である。

図６において、Ｗｅｂサービス接続システム１００は、Ｗｅｂサービスリクエスタ２００、Ｗｅｂサービスプロバイダ３００を備えるが、中継サーバ４００は不要である。

Ｗｅｂサービスリクエスタ２００は、実施の形態１と同様のプログラムである。実施の形態１と同様に、このプログラムは、コンピュータであるサービス要求装置によって実行される。サービス要求装置の各部は、実施の形態１と同様に、メモリに予め記憶されたプログラム（モジュール）をＣＰＵで読み取って実行することにより以下のように動作する。

まず、アプリケーション実行部は、Ｗｅｂサービスの種類を特定するサービスＩＤと、そのＷｅｂサービスを利用するための入力パラメータである任意のデータオブジェクトＸｑとを入力するクライアントアプリケーション２１０をＣＰＵで実行する。次に、要求側データ変換部は、オブジェクト変換モジュール２２０をＣＰＵで実行することにより、アプリケーション実行部が実行するクライアントアプリケーション２１０からサービスＩＤとデータオブジェクトＸｑとの入力を受け付ける。そして、要求側データ変換部は、データオブジェクトＸｑのデータ形式を汎用のデータ形式に変換して汎用型の要求データＹｑを生成する。次に、要求側データ通信部は、ＳＯＡＰ処理モジュール２３０を実行することにより、要求側データ変換部が入力を受け付けたサービスＩＤと要求側データ変換部が生成した汎用型の要求データＹｑとを、通信ネットワーク５００を介してサービス提供装置へ直接送信する。

また、要求側データ通信部は、ＳＯＡＰ処理モジュール２３０を実行することにより、通信ネットワーク５００を介してサービス提供装置から送信される汎用型の応答データＹｓを受信する。次に、要求側データ変換部は、オブジェクト変換モジュール２２０をＣＰＵで実行することにより、要求側データ通信部が受信した汎用型の応答データＹｓのデータ形式を変換してデータオブジェクトＸｓを生成する。そして、要求側データ変換部は、データオブジェクトＸｓをアプリケーション実行部が実行するクライアントアプリケーション２１０に返す。最後に、アプリケーション実行部は、クライアントアプリケーション２１０をＣＰＵで実行することにより、要求側データ変換部が返したデータオブジェクトＸｓを用いて、例えばＷｅｂサービスを利用した結果を画面などに表示する。

Ｗｅｂサービスプロバイダ３００は、Ｗｅｂサービス実装３１０、オブジェクト変換モジュール３２０、ＳＯＡＰ処理モジュール３３０を含むプログラムである。このプログラムは、コンピュータであるサービス提供装置によって実行される。サービス提供装置は、サービス処理実行部、提供側データ変換部、提供側データ通信部を備える。また、図示していないが、サービス提供装置は、ＣＰＵ、メモリ、入力装置、出力装置などのハードウェアを備えるものとする。サービス提供装置の各部は、メモリに予め記憶されたプログラム（モジュール）をＣＰＵで読み取って実行することにより以下のように動作する。

まず、提供側データ通信部は、ＳＯＡＰ処理モジュール３３０を実行することにより、通信ネットワーク５００を介してサービス要求装置から送信されたサービスＩＤと汎用型の要求データＹｑとを受信する。次に、提供側データ変換部は、オブジェクト変換モジュール３２０をＣＰＵで実行することにより、提供側データ通信部が受信した汎用型の要求データＹｑのデータ形式を変換してデータオブジェクトＸｑを生成する。次に、サービス処理実行部は、Ｗｅｂサービス実装３１０をＣＰＵで実行することにより、提供側データ変換部が生成したデータオブジェクトＸｑを用いて、提供側データ通信部が受信したサービスＩＤで特定される種類のサービスに係る処理をＣＰＵで実行し、当該実行結果として新たなデータオブジェクトＸｓを返す。次に、提供側データ変換部は、オブジェクト変換モジュール３２０をＣＰＵで実行することにより、サービス処理実行部が返したデータオブジェクトＸｓのデータ形式を汎用のデータ形式に変換して汎用型の応答データＹｓを生成する。最後に、提供側データ通信部は、ＳＯＡＰ処理モジュール３３０を実行することにより、提供側データ変換部が生成した汎用型の応答データＹｓを、通信ネットワーク５００を介してサービス要求装置へ送信する。

上記のように、本実施の形態では、Ｗｅｂサービスプロバイダ３００側のオブジェクト変換モジュール３２０は、汎用的な形式の要求メッセージ（汎用型の要求データＹｑ）をＷｅｂサービス実装３１０のプログラム言語のデータオブジェクト（データオブジェクトＸｑ）に変換する。また、Ｗｅｂサービス実装３１０が返したデータオブジェクト（データオブジェクトＸｓ）を、汎用的な形式の応答メッセージ（汎用型の応答データＹｓ）に変換する。

Ｗｅｂサービスリクエスタ２００からＷｅｂサービスプロバイダ３００のサービスを呼ぶとき、Ｗｅｂサービスリクエスタ２００は汎用メッセージをＷｅｂサービスプロバイダ３００に直接送る。具体的には、まず、クライアントアプリケーション２１０が、オブジェクト変換モジュール２２０に、Ｗｅｂサービスに渡すデータオブジェクト（データオブジェクトＸｑ）を、オブジェクト変換モジュール２２０が提供するＷｅｂサービス呼び出しＡＰＩの引数として与える。オブジェクト変換モジュール２２０は、データオブジェクトを汎用的な形式の要求メッセージ（汎用型の要求データＹｑ）に変換し、ＳＯＡＰ処理モジュール２３０に渡す。ここで、ＳＯＡＰ処理モジュール２３０には、予め接続先のＷｅｂサービスプロバイダ３００を表す識別子として、ＵＲＩが与えられている（メモリに記憶されている）ものとする。ＳＯＡＰ処理モジュール２３０は、ＵＲＩで示される接続先のＷｅｂサービスプロバイダ３００のＳＯＡＰ処理モジュール３３０との間で、通信プロトコルにＳＯＡＰを利用して、要求メッセージを送信する。

ＳＯＡＰ処理モジュール３３０は、受信した要求メッセージをオブジェクト変換モジュール３２０に渡す。オブジェクト変換モジュール３２０は、要求メッセージを、Ｗｅｂサービス実装３１０を記述するプログラム言語のデータオブジェクト（データオブジェクトＸｑ）に変換し、Ｗｅｂサービス実装３１０に渡す。Ｗｅｂサービス実装３１０は、サービスが提供する情報処理を行い、結果のデータオブジェクト（データオブジェクトＸｓ）をオブジェクト変換モジュール３２０に返す。結果のデータオブジェクトは、要求メッセージから変換されたものと同じものであってもよいし、Ｗｅｂサービス実装３１０の処理が別に生成したものであってもよい。データ型が要求メッセージから変換されたものと異なっていてもよい。オブジェクト変換モジュール３２０は、データオブジェクトを汎用的な形式の応答メッセージ（汎用型の応答データＹｓ）に変換し、ＳＯＡＰ処理モジュール３３０に渡す。ＳＯＡＰ処理モジュール３３０は、通信プロトコルにＳＯＡＰを利用して、応答メッセージを要求元のＷｅｂサービスリクエスタ２００のＳＯＡＰ処理モジュール２３０に返す。

ＳＯＡＰ処理モジュール２３０は、応答メッセージをオブジェクト変換モジュール２２０に渡す。オブジェクト変換モジュール２２０は、応答メッセージをデータオブジェクト（データオブジェクトＸｓ）に変換する。

本実施の形態によれば、Ｗｅｂサービスプロバイダ３００が用意するサービスのインタフェースは、汎用的な形式の要求メッセージを文字列として受け取り、汎用的な形式の応答メッセージを文字列として返すものとなる。別のＷｅｂサービスを利用するＷｅｂサービスリクエスタ２００を作成する場合、本実施の形態のＷｅｂサービスプロバイダ３００を利用すれば、新たにスタブを生成することなく、オブジェクト変換モジュール２２０に渡すデータオブジェクトを、当該Ｗｅｂサービス実装３１０が期待するデータ型とし、ＳＯＡＰ処理モジュール２３０に設定する接続先のＵＲＩを変更するだけで別のＷｅｂサービスに接続できるという効果を奏する。

以上説明した本実施の形態に係るＷｅｂサービス接続方法は、
（ａ）クライアント端末において、プログラム言語のデータオブジェクトの値を接続先のＷｅｂサービスのＷｅｂサービス定義文書に依存しない汎用的なデータ形式の要求メッセージに変換する工程、
（ｂ）クライアント端末において、汎用的なデータ形式の応答メッセージを、プログラム言語のデータオブジェクトの値に変換する工程、
（ｃ）Ｗｅｂサービスの提供サーバにおいて、汎用的なデータ形式の要求メッセージを、プログラム言語のデータオブジェクトの値に変換する工程、
（ｄ）Ｗｅｂサービスの提供サーバにおいて、プログラム言語のデータオブジェクトを、汎用的なデータ形式の応答メッセージに変換する工程、
を備えることを特徴とする。

以上、本発明の実施の形態について説明したが、これらのうち、２つ以上の実施の形態を組み合わせて実施しても構わない。あるいは、これらのうち、１つの実施の形態を部分的に実施しても構わない。あるいは、これらのうち、２つ以上の実施の形態を部分的に組み合わせて実施しても構わない。

実施の形態１におけるＷｅｂサービス接続システムの構成を示すブロック図である。 実施の形態１におけるＷｅｂサービス接続システムを構成する各装置のハードウェア構成の一例を示す図である。 実施の形態１におけるデータオブジェクトと汎用メッセージとの間の変換例を示す表である。 実施の形態１におけるＷｅｂサービスリクエスタの動作を示す図である。 実施の形態１における中継サーバの動作を示す図である。 実施の形態２におけるＷｅｂサービス接続システムの構成を示すブロック図である。

符号の説明

１００ Ｗｅｂサービス接続システム、２００ Ｗｅｂサービスリクエスタ、２１０ クライアントアプリケーション、２２０ オブジェクト変換モジュール、２３０ ＳＯＡＰ処理モジュール、３００ Ｗｅｂサービスプロバイダ、３１０ Ｗｅｂサービス実装、３２０ オブジェクト変換モジュール、３３０ ＳＯＡＰ処理モジュール、３４０ ＷＳＤＬ格納部、４００ 中継サーバ、４１０ ＳＯＡＰ処理モジュール、４２０ 中継サービス、４３０ メッセージ変換モジュール、４４０ ＷＳＤＬ取得モジュール、４５０ サービスＩＤ／ＵＲＩマッピングデータベース、５００ 通信ネットワーク、６０１ データオブジェクト、６０２ 汎用メッセージ、６０３ ＳＯＡＰメッセージ、６０４ サービス固有のメッセージ、７０１ ＷＳＤＬ、９０１ 表示装置、９０２ キーボード、９０３ マウス、９０４ ＦＤＤ、９０５ ＣＤＤ、９０６ プリンタ装置、９１１ ＣＰＵ、９１２ バス、９１３ ＲＯＭ、９１４ ＲＡＭ、９１５ 通信ボード、９２０ 磁気ディスク装置、９２１ オペレーティングシステム、９２２ ウィンドウシステム、９２３ プログラム群、９２４ ファイル群。

Claims (5)

1. サービスの種類ごとに固有のデータ形式をもつ固有型の要求データに対し、固有のデータ形式をもつ固有型の応答データを返信することでサービスを提供するサービス提供装置が複数接続された通信ネットワークを利用するサービス接続システムにおいて、
   サービスを利用するクライアントアプリケーションをＣＰＵ（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）で実行するアプリケーション実行部と、
   アプリケーション実行部が実行するクライアントアプリケーションからサービスの種類を特定するサービスＩＤ（識別子）と任意のデータオブジェクトとの入力を受け付け、当該データオブジェクトのデータ形式を汎用のデータ形式に変換して汎用型の要求データを生成する要求側データ変換部と、
   要求側データ変換部が入力を受け付けたサービスＩＤと要求側データ変換部が生成した汎用型の要求データとを送信する要求側データ通信部とを備えるサービス要求装置を有するとともに、
   前記サービス要求装置から送信されたサービスＩＤと汎用型の要求データとを受信する第１の中継側データ通信部と、
   第１の中継側データ通信部が受信した汎用型の要求データのデータ形式を、第１の中継側データ通信部が受信したサービスＩＤで特定される種類のサービス固有のデータ形式に変換して固有型の要求データを生成する中継側データ変換部と、
   前記通信ネットワークを介して、中継側データ変換部が生成した固有型の要求データを、第１の中継側データ通信部が受信したサービスＩＤで特定される種類のサービスを提供するサービス提供装置へ送信し、当該サービス提供装置から返信される固有型の応答データを受信する第２の中継側データ通信部とを備える中継装置を有し、
   中継側データ変換部は、第２の中継側データ通信部が受信した固有型の応答データのデータ形式を汎用のデータ形式に変換して汎用型の応答データを生成し、
   第１の中継側データ通信部は、中継側データ変換部が生成した汎用型の応答データを前記サービス要求装置へ送信し、
   要求側データ通信部は、前記中継装置から送信された汎用型の応答データを受信し、
   要求側データ変換部は、要求側データ通信部が受信した汎用型の応答データのデータ形式を変換してデータオブジェクトを生成し、当該データオブジェクトをアプリケーション実行部が実行するクライアントアプリケーションに返すことを特徴とするサービス接続システム。
2. それぞれのサービス提供装置は、提供するサービスの種類ごとに、固有のデータ形式を定義するサービス定義ファイルを保持しており、
   前記中継装置は、さらに、
   第１の中継側データ通信部が受信したサービスＩＤで特定される種類のサービスを提供するサービス提供装置からサービス定義ファイルを取得するファイル取得部を備え、
   中継側データ変換部は、ファイル取得部が取得したサービス定義ファイルで定義されるデータ形式を参照して、汎用型の要求データと固有型の要求データとの間のデータ形式の変換、及び、固有型の応答データと汎用型の応答データとの間のデータ形式の変換をすることを特徴とする請求項１に記載のサービス接続システム。
3. 前記サービス接続システムは、前記中継装置に代えて、
   前記サービス要求装置から送信されたサービスＩＤと汎用型の要求データとを受信する提供側データ通信部と、
   提供側データ通信部が受信した汎用型の要求データのデータ形式を変換してデータオブジェクトを生成する提供側データ変換部と、
   提供側データ変換部が生成したデータオブジェクトを用いて、提供側データ通信部が受信したサービスＩＤで特定される種類のサービスに係る処理をＣＰＵで実行し、当該実行結果として新たなデータオブジェクトを返すサービス処理実行部とを備えるサービス提供装置を有し、
   提供側データ変換部は、サービス処理実行部が返したデータオブジェクトのデータ形式を汎用のデータ形式に変換して汎用型の応答データを生成し、
   提供側データ通信部は、提供側データ変換部が生成した汎用型の応答データを前記サービス要求装置へ送信し、
   要求側データ通信部は、サービス提供装置から送信された汎用型の応答データを受信することを特徴とする請求項１に記載のサービス接続システム。
4. それぞれのサービス提供装置は、Ｗｅｂサービスを提供するＷｅｂサービスプロバイダのプログラムを実行するコンピュータであり、
   前記サービス要求装置は、Ｗｅｂサービスを要求するＷｅｂサービスリクエスタのプログラムを実行するコンピュータであることを特徴とする請求項１から３までのいずれかに記載のサービス接続システム。
5. サービスの種類ごとに固有のデータ形式をもつ固有型の要求データに対し、当該データ形式をもつ固有型の応答データを返信することでサービスを提供するサービス提供装置が複数接続された通信ネットワークを利用するサービス接続方法において、
   サービス要求装置が、サービスを利用するクライアントアプリケーションをＣＰＵ（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ）で実行する第１ステップと、
   前記サービス要求装置が、第１ステップで実行するクライアントアプリケーションからサービスの種類を特定するサービスＩＤ（識別子）と任意のデータオブジェクトとの入力を受け付け、当該データオブジェクトのデータ形式を汎用のデータ形式に変換して汎用型の要求データを生成する第２ステップと、
   前記サービス要求装置が、第２ステップで入力されたサービスＩＤと第２ステップで生成した汎用型の要求データとを送信する第３ステップと、
   中継装置が、前記サービス要求装置から送信されたサービスＩＤと汎用型の要求データとを受信する第４ステップと、
   前記中継装置が、第４ステップで受信した汎用型の要求データのデータ形式を、第４ステップで受信したサービスＩＤで特定される種類のサービス固有のデータ形式に変換して固有型の要求データを生成する第５ステップと、
   前記中継装置が、前記通信ネットワークを介して、第５ステップで生成した固有型の要求データを、第４ステップで受信したサービスＩＤで特定される種類のサービスを提供するサービス提供装置へ送信し、当該サービス提供装置から返信される固有型の応答データを受信する第６ステップと、
   前記中継装置が、第６ステップで受信した固有型の応答データのデータ形式を汎用のデータ形式に変換して汎用型の応答データを生成する第７ステップと、
   前記中継装置が、第７ステップで生成した汎用型の応答データを前記サービス要求装置へ送信する第８ステップと、
   前記サービス要求装置が、前記中継装置から送信された汎用型の応答データを受信する第９ステップと、
   前記サービス要求装置が、第９ステップで受信した汎用型の応答データのデータ形式を変換してデータオブジェクトを生成し、当該データオブジェクトを第１ステップで実行するクライアントアプリケーションに返す第１０ステップとを備えることを特徴とするサービス接続方法。

Images