JP2005174120A - Ｗｅｂサービス接続処理方法とシステム、およびプログラム - Google Patents

Abstract

【課題】 Ｗｅｂサービスのインタフェースが多少違っていてもクライアントプログラムを修正することなくＷｅｂサービスを呼び出すことができるようにする。
【解決手段】 想定接続先と新規接続先のＷｅｂサービス定義文書、および新規接続先に対する要求データを受け取った場合（Ｓ４１０のＹＥＳ）に、類似性判定処理（Ｓ４２０）として、２つのＷｅｂサービス定義文書から引数と戻り値のデータ型情報を読み込み（Ｓ４２１）、その差異を抽出し（Ｓ４２２）、抽出結果に基づいて構造的な類似性を判定する（Ｓ４２３）。構造的に類似している場合（Ｓ４２４のＹＥＳ）には、新規接続先に対する変換ルールを生成し（Ｓ４２５）、変換ルールに従って要求データをＸＭＬ形式の要求データに変換する（Ｓ４３０）。ＸＭＬ形式の応答データを受け取った場合（Ｓ４４０のＹＥＳ）には、変換ルールに従ってＸＭＬ形式の応答データをデータ変換する（Ｓ４５０）。
【選択図】 図４

Description

本発明は、クライアント端末上で入力された接続要求に応じてＷｅｂサービス端末にアクセスし、Ｗｅｂサービス端末から受け取った接続応答を当該接続要求の結果データとしてクライアント端末上で出力するためのＷｅｂサービス接続処理技術に関するものである。

近年の通信ネットワーク技術の発展に伴い、インターネットなどの通信ネットワークを通して相互に接続された情報システムの上で、企業間商取引や企業内業務などが実現されるようになってきている。ビジネスを取り巻く環境は劇的に変化してきており、従来の固定的な取引関係から、企業グループや業界の垣根を超えた、一層自由な競争へと移りつつある。企業の情報システムには、このようなビジネス環境の変化に柔軟に対応できることが強く求められている。

ＸＭＬ Ｗｅｂサービスは、ＨＴＴＰやＸＭＬなどの広く普及しているオープンな技術に基づいて、複数の情報システムを柔軟にかつ容易に接続するためのアーキテクチャとして注目されている。ＸＭＬ Ｗｅｂサービスを利用することによって、企業が構築してきたＡＳＰやＷｅｂアプリケーション、レガシーシステムといった情報システムの機能を、サービスとしてインターネット上に提供することが可能となる。現在、サービスの記述／公開／呼出を実現するための最も基本的な標準仕様であるところの、ＳＯＡＰ／ＷＳＤＬ／ＵＤＤＩの策定が整いつつあり、その上で、セキュリティやトランザクション、ビジネスプロセスといった、高信頼化、高機能化を実現するための標準仕様について議論が進められている。

ＸＭＬ Ｗｅｂサービスのアーキテクチャでは、Ｗｅｂサービスとクライアント間の１対１の固定的な呼び出しだけでなく、クライアントは、Ｗｅｂサービスの公開レジストリであるＵＤＤＩから検索して発見したＷｅｂサービスを動的に呼び出すことが可能である。しかし、システム同士を接続するためには、システム間で事前に接続インタフェースを取り決めておく必要がある。

ＸＭＬ Ｗｅｂサービスでは、Ｗｅｂサービスのインタフェースを記述するためにＷＳＤＬという記述言語の仕様が制定されている。ＷＳＤＬによって記述されたインタフェース情報（以下、Ｗｅｂサービス定義文書と記す）には、Ｗｅｂサービスとして公開されている操作名や、やり取りされるＸＭＬデータの構造、アクセスポイント情報等が記述される。ＷＳＤＬ定義文書にはインタフェース情報が過不足なく記述されているため，ＷＳＤＬ定義文書を元に実装の雛形を作成することも可能である。このため、サービス側への要求を出すＷｅｂサービスリクエスタ、あるいはサービスを提供するＷｅｂサービスプロバイダのプロキシコード（スタブとも呼ばれる）を作成できるような製品も出てきており、開発の効率化が図られるようになっている。

ＷＳＤＬ文書の記述形式を企業グループ内や業界内で統一すれば、クライアントに対して、一様なアクセス手段を提供することができる。しかし、Ｗｅｂサービスのインタフェースを統一することは、企業間の利害関係が絡み、必ずしも実現が容易なことではなく、現実にはインタフェースが少しずつ異なるＷｅｂサービスが多数混在している。また、Ｗｅｂサービスを一旦公開すると、Ｗｅｂシステムの特性上からシステムの運転を停止することは一般に難しく、その意味からも一度決定したインタフェースを変更することは容易ではない。

一方、クライアントプログラムの視点から考えると、クライアントプログラムの利用が想定されるＷｅｂサービスのインタフェース情報（ＵＲＬ、操作名、メッセージ名、データ型情報等）を事前に知っていなければならない。すなわち、クライアントプログラムにＷｅｂサービス毎の呼び出し方を実装しておかなければならない。仮に、Ｗｅｂサービスのインタフェースが変更された場合には、クライアントプログラムを一旦停止して再度構築しなければならない。一般的に、ＸＭＬ Ｗｅｂサービス・アーキテクチャの特徴として、システムの動作環境の変化に動的に対応できることが挙げられているが、上述のように、現実には多くの制約や課題が存在している。

特開２００３−３１６８１２公報 特開２００３−２７１４４１公報

本発明は、上記のような従来のＷｅｂサービス技術の問題点を解決するために提案されたものであり、その目的は、Ｗｅｂサービスのインタフェースが多少違っていてもクライアントプログラムを修正することなくＷｅｂサービスを呼び出すことができ、Ｗｅｂサービス呼び出しの柔軟化を実現可能なＷｅｂサービス接続処理方法とシステム、およびプログラムを提供することである。

本発明は、上記の目的を達成するために、Ｗｅｂサービスのインタフェースの構造的類似性に応じたデータ間の構造変換ルールを生成することにより、Ｗｅｂサービスのインタフェースが多少違っていてもクライアントプログラムを修正することなくＷｅｂサービスを呼び出すことができるようにしたものである。

請求項１の発明は、クライアント端末上で入力された接続要求に応じてＷｅｂサービス端末にアクセスし、Ｗｅｂサービス端末から受け取った接続応答を当該接続要求の結果データとしてクライアント端末上で出力するためのＷｅｂサービス接続処理方法において、次のような技術的特徴を有するものである。すなわち、各Ｗｅｂサービス端末のインタフェースで取り扱い可能なデータ型を含むインタフェース情報をそれぞれ定義した個々のＷｅｂサービス定義文書が存在する状況の下で、クライアント端末または当該クライアント端末とＷｅｂサービス端末とを接続するデータ処理装置により、類似性判定ステップ、接続要求変換ステップ、接続応答変換ステップ、を行うことを特徴としている。

ここで、類似性判定ステップは、クライアント端末の接続先として予め想定されたＷｅｂサービス端末のＷｅｂサービス定義文書が想定接続先Ｗｅｂサービス定義文書として与えられると共に、新たな接続先のＷｅｂサービス端末のＷｅｂサービス定義文書が新規接続先Ｗｅｂサービス定義文書として与えられた場合に、想定接続先Ｗｅｂサービス定義文書と新規接続先Ｗｅｂサービス定義文書の構造的類似性を判定し、この判定結果に基づいて、想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のデータと新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のデータとの間の構造変換ルールを生成するステップである。

また、接続要求変換ステップは、構造変換ルールに基づいて、想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続要求データを、新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続要求データに変換するステップである。また、接続応答変換ステップは、構造変換ルールに基づいて、新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続応答データを、想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続応答データに変換するステップである。

この発明によれば、接続先として予め想定されたＷｅｂサービス端末のＷｅｂサービス定義文書と新たな接続先のＷｅｂサービス端末のＷｅｂサービス定義文書との間の構造的類似性を判定し、判定結果に応じた構造変換ルールを生成することにより、この構造変換ルールに基づいて、一方のＷｅｂサービス定義文書に準ずる接続要求データや接続応答データを他方のＷｅｂサービス定義文書に準ずるデータに変換することができる。したがって、接続先として予め想定されたＷｅｂサービス端末と新たな接続先のＷｅｂサービス端末のインタフェースが多少違っていても、クライアントプログラムを修正することなく新規接続先のＷｅｂサービスを呼び出すことができる。

なお、本発明において、重要な用語の定義は次の通りである。
「端末」は、典型的にはコンピュータまたは複数のコンピュータからなるコンピュータシステムであるが、それに限らず、携帯電話等のモバイル機器を含め、通信ネットワークを通じてサービス要求またはサービス提供を行うことが可能な端末機能を有する機器またはシステムを含む広い概念である。

「クライアント端末」は、Ｗｅｂサービス端末に対してサービス要求を行う端末一般を示す用語である。
「Ｗｅｂサービス端末」は、Ｗｅｂサービスを提供する端末一般を示す用語である。なお、あるＷｅｂサービスを提供するＷｅｂサービス端末が、他のＷｅｂサービス端末に対してサービス要求を行うクライアント端末として使用される場合もある。

「Ｗｅｂサービス定義文書に準ずるデータ形式」は、当該Ｗｅｂサービス定義文書により定義されたデータ形式を含むが、それに加えて、当該Ｗｅｂサービス端末において当該Ｗｅｂサービス定義文書により定義されたデータ形式と同様に取り扱い可能な範囲のデータ形式を含む広い概念である。

以上のように、本発明によれば、Ｗｅｂサービスのインタフェースの構造的類似性に応じた構造変換ルールを生成することにより、Ｗｅｂサービスのインタフェースが多少違っていてもクライアントプログラムを修正することなくＷｅｂサービスを呼び出すことができ、Ｗｅｂサービス呼び出しの柔軟化を実現可能なＷｅｂサービス接続処理方法とシステム、およびプログラムを提供することができる。

以下に、本発明の実施形態を図面に沿って具体的に説明する。ただし、ここで記載する実施形態は、本発明を何ら限定するものではなく、本発明の一態様を例示するものにすぎない。

本発明は、典型的には、コンピュータをソフトウェアで制御することにより実現される。この場合のソフトウェアは、コンピュータのハードウェアを物理的に活用することで本発明の作用効果を実現するものであり、また、従来技術を適用可能な部分には好適な従来技術が適用される。さらに、本発明を実現するハードウェアやソフトウェアの具体的な種類や構成、ソフトウェアで処理する範囲などは自由に変更可能であり、例えば、本発明を実現するプログラムは本発明の一態様である。

［１．全体構成］
図１は、本発明を適用した１つの実施形態に係るＷｅｂサービス接続処理システム全体の構成を示すブロック図である。この図１に示すように、サービス要求を行うクライアント端末であるＷｅｂサービスリクエスタ１００と、サービスを提供するＷｅｂサービス端末であるＷｅｂサービスプロバイダ２００とが、通信ネットワーク３００を介して接続されるようになっている。一般に、１つのＷｅｂサービスリクエスタ１００から複数のＷｅｂサービスプロバイダ２００を利用することができるようになっている。

図２は、Ｗｅｂサービスリクエスタ１００からＷｅｂサービスプロバイダ２００を利用するための、リクエスタとプロバイダのモジュール構成を示すブロック図である。

まず、Ｗｅｂサービスリクエスタ１００のモジュール構成について説明する。図２に示すように、Ｗｅｂサービスリクエスタ１００は、クライアントアプリケーション１１０、プロキシモジュール１２０、データ変換モジュール１３０、ＳＯＡＰ処理モジュール１４０、等のモジュールを備えている。

ここで、クライアントアプリケーション１１０とプロキシモジュール１２０はアプリケーション毎に作成される。また、データ変換モジュール１３０とＳＯＡＰ処理モジュール１４０は、汎用的なプログラムモジュールであり、データ変換モジュール１３０は、本発明に従う特徴的な処理を行うモジュールである。なお、ＳＯＡＰ処理モジュール１４０としては、標準仕様ＳＯＡＰとＷＳＤＬに準拠した、商用あるいはオープンソースの実装が多数存在する。例えば、商用では、ＩＢＭ社製の「ＷｅｂＳｐｈｅｒｅ（登録商標）」、ＢＥＡ社製の「ＷｅｂＬｏｇｉｃ」、Ｏｒａｃｌｅ社製の「Ｏｒａｃｌｅ ９ｉＡＳ」、Ｍｉｃｒｏｓｏｆｔ社製の「．ＮＥＴ」がリリースされており、オープンソースではＡｐａｃｈｅプロジェクト製の「Ａｘｉｓ」などがある。

以下には、Ｗｅｂサービスリクエスタ１００を構成するこれらのモジュール１１０，１２０，１３０，１４０の機能について順次説明する。

クライアントアプリケーション１１０は、必要に応じてＷｅｂサービスプロバイダ２００を利用しながら一定の処理を実行するアプリケーションプログラムである。このクライアントアプリケーション１１０は、プロキシモジュール１２０を介して、Ｗｅｂサービスプロバイダ２００へ要求データを送信し、Ｗｅｂサービスプロバイダ２００から応答データを受信する。

プロキシモジュール１２０は、クライアントアプリケーション１１０がＷｅｂサービスプロバイダ２００を利用するための接続手段を提供するモジュールである。プロキシモジュール１２０のインタフェースは、Ｗｅｂサービスリクエスタ１００の接続先として予め想定された想定接続先のＷｅｂサービスプロバイダ２００が提供するＷｅｂサービスのＷｅｂサービス定義文書に記述されたインタフェース定義に従って実装され、Ｗｅｂサービスプロバイダ２００への接続方法もこのモジュール内に組み込まれる。

そのため、クライアントアプリケーション１１０は、Ｗｅｂサービスプロバイダ２００がネットワーク接続された遠隔の端末上で稼動していること、およびそこへの接続方法を意識することなく、あたかもローカル端末上のモジュールであるかのように、想定接続先のＷｅｂサービスプロバイダ２００を利用することができる。

データ変換モジュール１３０は、プロキシモジュール１２０から受け取った要求データを、ＸＭＬ形式の要求データに変換してＳＯＡＰ処理モジュール１４０へ渡す処理と、ＳＯＡＰ処理モジュール１４０から受け取ったＸＭＬ形式の応答データを、プロキシモジュール１２０で取り扱い可能なデータ形式の応答データとして返す処理を行う。

このデータ変換モジュール１３０は、要求データのデータ変換を行う際に、プロキシモジュール１２０が実装されたときに参照した想定接続先のＷｅｂサービス定義文書と、実際の新規接続先のＷｅｂサービス定義文書とを比較参照し、定義文書中で定義されたデータ形式の差異を抽出し、この抽出結果に基づいて変換ルールを生成する。なお、データ変換モジュール１３０の詳細な構成については後述する。

ＳＯＡＰ処理モジュール１４０は、接続先のＷｅｂサービスプロバイダ２００のＳＯＡＰ処理モジュール２２０との間で、ＳＯＡＰプロトコルを利用してＸＭＬ形式のメッセージを交換するモジュールである。このＳＯＡＰ処理モジュール１４０は、データ変換モジュール１３０から受け取ったＸＭＬ形式の要求データを、接続先のＷｅｂサービスプロバイダ２００のＷｅｂサービス定義文書に従ってＸＭＬメッセージを組み立てる処理と、Ｗｅｂサービスプロバイダ２００から受け取ったＸＭＬメッセージを解析して応答データを抽出し、データ変換モジュール１３０へ渡す処理を行う。

次に、Ｗｅｂサービスプロバイダ２００のモジュール構成について説明する。図２に示すように、Ｗｅｂサービスプロバイダ２００は、Ｗｅｂサービス実装２１０、ＳＯＡＰ処理モジュール２２０、Ｗｅｂサービス定義文書格納庫２３０、等のモジュールを備えている。

ここで、Ｗｅｂサービス実装２１０と、Ｗｅｂサービス定義文書格納庫２３０に格納されるＷｅｂサービス定義文書は、アプリケーション毎に作成される。このうち、Ｗｅｂサービス定義文書格納庫２３０は、メモリやデータベース、ファイルシステム、等の記憶手段上に構築される。また、ＳＯＡＰ処理モジュール２２０は、汎用的なプログラムモジュールであり、Ｗｅｂサービスリクエスタ１００のＳＯＡＰ処理モジュール１４０と同一のモジュールが使用可能である。なお、このＳＯＡＰ処理モジュール２２０としては、ＳＯＡＰ処理モジュール１４０について前述したように、標準仕様ＳＯＡＰとＷＳＤＬに準拠した、商用あるいはオープンソースの実装が多数存在するが、Ｗｅｂサービスリクエスタ１００とＷｅｂサービスプロバイダ２００とで、利用するＳＯＡＰ処理モジュールの実装が異なってもよい。

以下には、Ｗｅｂサービスプロバイダ２００を構成するＷｅｂサービス実装２１０とＳＯＡＰ処理モジュール２２０の機能について順次説明する。

Ｗｅｂサービス実装２１０は、計算やデータ処理などの機能や情報を提供するプログラムの実態である。このＷｅｂサービス実装２１０に対するインタフェース情報（ＵＲＬ、操作名、メッセージ名、引数と戻り値のデータ型情報等）が、Ｗｅｂサービス記述言語ＷＳＤＬを利用してＷｅｂサービス定義文書として記述され、Ｗｅｂサービス定義文書格納庫２３０に格納されている。

ＳＯＡＰ処理モジュール２２０は、Ｗｅｂサービスリクエスタ１００から受信したＸＭＬメッセージを解析して要求データを抽出し、Ｗｅｂサービス実装２１０で取り扱い可能なデータ形式に変換してＷｅｂサービス実装２１０に渡す処理と、Ｗｅｂサービス実装２１０から受け取った応答データからＸＭＬメッセージを組み立ててＷｅｂサービスリクエスタ１００へ返信する処理を行う。

［２．データ変換モジュールの構成］
図３は、Ｗｅｂサービスリクエスタ１００において、本発明に従う特徴的な処理を行うデータ変換モジュール１３０の詳細な構成を示すブロック図である。この図３に示すように、データ変換モジュール１３０は、類似性判定モジュール１３１、要求データ変換モジュール１３２、応用データ変換モジュール１３３、変換ルール格納庫１３４、等のモジュールを備えている。以下には、これらのモジュール１３１〜１３４について順次説明する。

類似性判定モジュール１３１は、プロキシモジュール１２０から２つのＷｅｂサービス定義文書と、接続先のＷｅｂサービスプロバイダ２００に対する要求データを受け取る。この場合に与えられる２つのＷｅｂサービス定義文書は、クライアントアプリケーション１１０の設計時に接続先として予め想定されていた想定接続先のＷｅｂサービスプロバイダ２００の定義文書と、実際に接続しようとしている新規接続先のＷｅｂサービスプロバイダ２００の定義文書である。

類似性判定モジュール１３１は、２つのＷｅｂサービス定義文書それぞれから引数と戻り値のデータ型情報を読み込み、その差異を抽出し、この抽出結果に基づいて構造的な類似性を判定する。そして、構造的に類似していると判定した場合には、当該新規接続先のＷｅｂサービスプロバイダ２００に対する変換ルールを生成して変換ルール格納庫１３４に格納し、プロキシモジュール１２０から受け取った要求データを要求データ変換モジュール１３２へ渡すようになっている。一方、構造的に類似していないと判定した場合には、プロキシモジュール１２０へエラーを返す。

要求データ変換モジュール１３２は、変換ルール格納庫１３４から当該新規接続先のＷｅｂサービスプロバイダ２００に対する変換ルールを読み込み、類似性判定モジュール１３１から受け取った要求データを変換ルールに従ってＸＭＬ形式の要求データに変換して、ＳＯＡＰ処理モジュール１４０へ渡す。

応答データ変換モジュール１３３は、変換ルール格納庫１３４から当該新規接続先のＷｅｂサービスプロバイダ２００に対する変換ルールを読み込み、ＳＯＡＰ処理モジュールから受け取ったＸＭＬ形式の応答データを変換ルールに従ってデータ変換して、プロキシモジュール１２０へ渡す。

変換ルール格納庫１３４は、類似性判定モジュール１３１により当該新規接続先のＷｅｂサービスプロバイダ２００に対する変換ルールが生成された場合に、その変換ルールを保存するようになっている。なお、変換ルール格納庫１３４は、メモリやデータベース、ファイルシステム上に構築される。

［３．データ変換モジュールの動作］
図４は、本発明に従う特徴的な処理として、Ｗｅｂサービスリクエスタ１００のデータ変換モジュール１３０による動作を示すフローチャートである。

この図４に示すように、データ変換モジュール１３０は、プロキシモジュール１２０から、想定接続先のＷｅｂサービスプロバイダ２００の定義文書、新規接続先のＷｅｂサービスプロバイダ２００の定義文書、および当該新規接続先のＷｅｂサービスプロバイダ２００に対する要求データ、を受け取った場合（Ｓ４１０のＹＥＳ）に、類似性判定モジュール１３１により類似性判定処理を行う（Ｓ４２０）。

この場合、類似性判定モジュール１３１は、類似性判定処理として、２つのＷｅｂサービス定義文書それぞれから引数と戻り値のデータ型情報を読み込み（Ｓ４２１）、その差異を抽出し（Ｓ４２２）、この抽出結果に基づいて構造的な類似性を判定する（Ｓ４２３）。すなわち、２つのＷｅｂサービス定義文書ＸＭＬのデータ型情報において、そのデータ構造の一部に差異がある場合に、その差異が、ＸＭＬ技術の分野で「弱包摂関係」と呼ばれる構造的な類似性を持つか否かを判定する。

類似性判定モジュール１３１は、判定結果が「真」、すなわち構造的に類似していると判定した場合（Ｓ４２４のＹＥＳ）には、当該新規接続先のＷｅｂサービスプロバイダ２００に対する変換ルールを生成して変換ルール格納庫１３４に格納し（Ｓ４２５）、プロキシモジュール１２０から受け取った要求データを要求データ変換モジュール１３２へ渡す。

ここで、当該Ｗｅｂサービスプロバイダ２００に対する変換ルールとして生成される変換ルールは、想定接続先Ｗｅｂサービスプロバイダ２００の想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のデータと、新規接続先Ｗｅｂサービスプロバイダ２００の新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のデータとを、相互に変換するための構造変換ルールである。この変換ルールは、プロキシモジュール１２０から与えられる要求データを当該Ｗｅｂサービスプロバイダ２００に送信するＸＭＬ形式の要求データへ変換するための変換ルールと、当該Ｗｅｂサービスプロバイダ２００から受け取ったＸＭＬ形式の応答データを、プロキシモジュール１２０で取り扱い可能な形式の応答データへ変換するための変換ルールとを含む。

また、類似性判定モジュール１３１は、判定結果が「偽」、すなわち構造的に類似していないと判定した場合（Ｓ４２４のＮＯ）には、プロキシモジュール１２０へエラーを返す（Ｓ４２６）。

要求データ変換モジュール１３２は、変換ルール格納庫１３４から当該新規接続先のＷｅｂサービスプロバイダ２００に対する変換ルールを読み込み、類似性判定モジュール１３１から受け取った要求データを変換ルールに従ってＸＭＬ形式の要求データに変換する（Ｓ４３０）。すなわち、要求データ変換モジュール１３２は、変換ルールに基づいて、想定接続先Ｗｅｂサービス定義文書で定義されたデータ形式に準ずるデータ形式の要求データを、新規接続先Ｗｅｂサービス定義文書で定義されたデータ形式に準ずるデータ形式の要求データに変換する。要求データ変換モジュール１３２は、変換した要求データをＳＯＡＰ処理モジュール１４０へ渡す。

データ変換モジュール１３０は、ＳＯＡＰ処理モジュール１４０から、当該新規接続先Ｗｅｂサービスプロバイダ２００からのＸＭＬ形式の応答データを受け取った場合（Ｓ４４０のＹＥＳ）に、応答データ変換モジュール１３３により、変換ルール格納庫１３４から当該新規接続先Ｗｅｂサービスプロバイダ２００に対する変換ルールを読み込み、ＸＭＬ形式の応答データを変換ルールに従ってデータ変換する（Ｓ４５０）。すなわち、応答データ変換モジュール１３３は、変換ルールに基づいて、新規接続先Ｗｅｂサービス定義文書で定義されたデータ形式に準ずるデータ形式の応答データを、前記想定接続先Ｗｅｂサービス定義文書で定義されたデータ形式に準ずるデータ形式の応答データに変換する。応答データ変換モジュール１３３は、変換した応答データを、プロキシモジュール１２０へ渡す。

［４．類似性判定処理の具体例］
図５〜図８は、図４に示す類似性判定処理の対象となるＷｅｂサービス定義文書の具体例として、４つのＷｅｂサービス定義文書ＷＤ１〜ＷＤ４をそれぞれ示す図である。また、図９は、これら４つのＷｅｂサービス定義文書ＷＤ１〜ＷＤ４の各々について、戻り値のデータ型「GetQuotesResponse」のツリー表記を示す図である。

以下には、これらの図５〜図９を用いて、第１のＷｅｂサービス定義文書ＷＤ１を想定接続先Ｗｅｂサービス定義文書として実装されたクライアントアプリケーション１１０を持つＷｅｂサービスリクエスタ１００から、第２〜第４のＷｅｂサービス定義文書ＷＤ２〜ＷＤ４の１つを持つ各Ｗｅｂサービスプロバイダ２００に接続する場合の具体的な類似性判定処理について説明する。

［第１、第２のＷｅｂサービス定義文書ＷＤ１，ＷＤ２の類似性判定処理］
第１のＷｅｂサービス定義文書ＷＤ１を想定接続先Ｗｅｂサービス定義文書、第２のＷｅｂサービス定義文書ＷＤ２を新規接続先Ｗｅｂサービス定義文書として類似性判定処理を行った場合、図５と図６から、戻り値のデータ型定義の差異として、要素「lastPrice」，「quote」の組み合わせが抽出される。

すなわち、第１のＷｅｂサービス定義文書ＷＤ１中の要素「lastPrice」（図５の第１７行目に存在）が、第２のＷｅｂサービス定義文書ＷＤ２中に存在しない要素として抽出されると共に、第２のＷｅｂサービス定義文書ＷＤ２中の要素「quote」（図６の第１７行目に存在）が、第１のＷｅｂサービス定義文書ＷＤ１中に存在しない要素として抽出される。

これらの要素「lastPrice」，「quote」の組み合わせは、図９に示すツリー表記において、破線９２１，９２２で示すように、第１のＷｅｂサービス定義文書ＷＤ１中のノードτ13「lastPrice」と第２のＷｅｂサービス定義文書ＷＤ２中のノードτ23「quote」の組み合わせに対応している。これらのノードτ13，τ23間において、ノードτ23のラベルを「quote」から「lastPrice」に変更するラベルの付け替えを行うことにより、第２のＷｅｂサービス定義文書ＷＤ２における戻り値のデータ型定義を第１のＷｅｂサービス定義文書ＷＤ１における戻り値のデータ定義と同等とすることができる。一方、引数のデータ型定義については、図５と図６から明らかなように、第１、第２のＷｅｂサービス定義文書ＷＤ１，ＷＤ２間で同一である。

そのため、第１、第２のＷｅｂサービス定義文書ＷＤ１，ＷＤ２の間には構造的な類似性があると判定でき、要求データ（引数）については変換ルールを生成せず、応答データ（戻り値）についてのみ、上記の「ラベルの付け替え」を含む変換ルールが生成される。図１０は、このようにして生成された第１のＷｅｂサービス定義文書ＷＤ１に準ずるデータ形式のデータと、第２のＷｅｂサービス定義文書ＷＤ２に準ずるデータ形式のデータとの間のデータ変換ルールＲ１２を示す図である。

［第１、第３のＷｅｂサービス定義文書ＷＤ１，ＷＤ３の類似性判定処理］
第１のＷｅｂサービス定義文書ＷＤ１を想定接続先Ｗｅｂサービス定義文書、第３のＷｅｂサービス定義文書ＷＤ３を新規接続先Ｗｅｂサービス定義文書として類似性判定処理を行った場合、図５と図７から、戻り値のデータ型の差異として、第３のＷｅｂサービス定義文書ＷＤ３中の要素「volume」（図７の第１９行目に存在）が、第１のＷｅｂサービス定義文書ＷＤ１中に存在しない要素として抽出される。

すなわち、戻り値のデータ型定義の差異としては、図９に示すツリー表記において、破線９３０で示すように、第３のＷｅｂサービス定義文書ＷＤ３中のノードτ3「stockQuote」からこの下位ノードτ36「volume」に伸びる枝およびノードτ36「volume」からこの下位のノードτ361「String」に伸びる枝の２つの枝が、第１のＷｅｂサービス定義文書ＷＤ１中に存在しない枝として抽出される。この枝の枝刈りを行うことにより、第３のＷｅｂサービス定義文書ＷＤ３における戻り値のデータ型定義を第１のＷｅｂサービス定義文書ＷＤ１における戻り値のデータ型定義と同等とすることができる。

一方、引数のデータ型定義については、図５と図７から明らかなように、第１のＷｅｂサービス定義文書ＷＤ１中の要素「companyName」（図５の第８行目に存在）が、第３のＷｅｂサービス定義文書ＷＤ３中に存在しない要素として抽出される。引数のデータ型についてはツリー表記を示していないが、第１のＷｅｂサービス定義文書ＷＤ１中の要素「companyName」について枝刈りを行うことにより、第１のＷｅｂサービス定義文書ＷＤ１における引数のデータ定義を第３のＷｅｂサービス定義文書ＷＤ３における引数のデータ定義と同等とすることができる。

そのため、第１、第３のＷｅｂサービス定義文書ＷＤ１，ＷＤ３の間には構造的な類似性があると判定でき、要求データ（引数）については第１のＷｅｂサービス定義文書ＷＤ１中の要素「companyName」を「null」に変更する「枝刈り」を含む変換ルールが生成され、応答データ（戻り値）については、第３のＷｅｂサービス定義文書ＷＤ３中の要素「volume」を「null」に変更する「枝刈り」を含む変換ルールが生成される。図１１は、このようにして生成された第１のＷｅｂサービス定義文書ＷＤ１に準ずるデータ形式のデータと、３２のＷｅｂサービス定義文書ＷＤ３に準ずるデータ形式のデータとの間のデータ変換ルールＲ１３を示す図である。

［第１、第４のＷｅｂサービス定義文書ＷＤ１，ＷＤ４の類似性判定処理］
第１のＷｅｂサービス定義文書ＷＤ１を想定接続先Ｗｅｂサービス定義文書、第４のＷｅｂサービス定義文書ＷＤ４を新規接続先Ｗｅｂサービス定義文書として類似性判定処理を行った場合、図５と図８から、戻り値のデータ型の差異として、第４のＷｅｂサービス定義文書ＷＤ４中の要素「dayRange」（図８の第１８行目に存在）が、第１のＷｅｂサービス定義文書ＷＤ１中に存在しない要素として抽出される。その一方で、第４のＷｅｂサービス定義文書ＷＤ４中のその要素「dayRange」を構成する２つの要素「dayHighPrice」，「dayLowPrice」（図５の第１８，１９行目に存在）は、第１のＷｅｂサービス定義文書ＷＤ１中に存在する要素である。

すなわち、戻り値のデータ型定義については、図９に示すツリー表記において、破線９４０で示すように、２つのノードτ441，τ442の上位のノードτ44「dayRange」が、第１のＷｅｂサービス定義文書ＷＤ１中に存在しない中間ノードとして抽出される。その一方、破線９４１，９４２で示すように、ノードτ44の下位に位置する２つのノードτ441「dayHighPrice」，τ442「dayLowPrice」は、第１のＷｅｂサービス定義文書ＷＤ１中における２つのノードτ14，τ15と対応付けられる。

この場合、中間ノードτ44を除去し、τ44の上位ノードτ4と、τ44の下位ノードτ441，τ442をそれぞれ直結することにより、第４のＷｅｂサービス定義文書ＷＤ４における戻り値のデータ定義を第１のＷｅｂサービス定義文書ＷＤ１における戻り値のデータ定義と同等とすることができる。一方、引数のデータ型定義については、図５と図８から明らかなように、第１、第４のＷｅｂサービス定義文書ＷＤ１，ＷＤ４間で同一である。

そのため、第１、第４のＷｅｂサービス定義文書ＷＤ１，ＷＤ４の間には構造的な類似性があると判定でき、要求データ（引数）については変換ルールを生成せず、応答データ（戻り値）についてのみ、上記の「中間ノードの除去」を含む変換ルールが生成される。図１２は、このようにして生成された第１のＷｅｂサービス定義文書ＷＤ１に準ずるデータ形式のデータと、第４のＷｅｂサービス定義文書ＷＤ４に準ずるデータ形式のデータとの間のデータ変換ルールＲ１４を示す図である。

［５．実施形態の作用効果］
以上のような本実施形態によれば、次のような作用効果が得られる。すなわち、接続先として予め想定されたＷｅｂサービスプロバイダのＷｅｂサービス定義文書と新たな接続先のＷｅｂサービスプロバイダのＷｅｂサービス定義文書との間の構造的類似性を判定し、判定結果に応じた構造変換ルールを生成することにより、この構造変換ルールに基づいて、一方のＷｅｂサービス定義文書に準ずる接続要求データや接続応答データを他方のＷｅｂサービス定義文書に準ずるデータに変換することができる。

したがって、接続先として予め想定されたＷｅｂサービスプロバイダと新規接続先のＷｅｂサービスプロバイダのインタフェースが多少違っていても、クライアントプログラムを修正することなく新規接続先のＷｅｂサービスプロバイダを呼び出すことができ、Ｗｅｂサービス呼び出しの柔軟化を実現可能なＷｅｂサービス接続処理方法とシステム、およびプログラムを提供することができる。

［６．他の実施形態］
なお、本発明は、前述した実施形態に限定されるものではなく、本発明の範囲内で他にも多種多様な変形例が実施可能である。すなわち、前記実施形態で示したＷｅｂサービス接続処理システムの構成や処理手順、データ構造等は、一例にすぎず、具体的な構成や処理手順、データ構造等は自由に変更可能である。例えば、前記実施形態においては、データ変換手段であるデータ変換モジュールを、Ｗｅｂサービスリクエスタに設けたが、これに限らず、ＷｅｂサービスリクエスタとＷｅｂサービスプロバイダの間に、両者を接続する中継器等の独立のデータ処理装置を設け、このデータ処理装置により類似性判定、データ変換を行うこと等も可能である。

本発明を適用した１つの実施形態に係るＷｅｂサービス接続処理システム全体の構成を示すブロック図。 図１に示すＷｅｂサービスリクエスタからＷｅｂサービスプロバイダを利用するための、リクエスタとプロバイダのモジュール構成を示すブロック図。 図２に示すデータ変換モジュールの詳細な構成を示すブロック図 図３に示すデータ変換モジュールによる動作を示すフローチャート。 図４に示す類似性判定処理の対象となるＷｅｂサービス定義文書の具体例として、第１のＷｅｂサービス定義文書を示す図。 図４に示す類似性判定処理の対象となるＷｅｂサービス定義文書の具体例として、第２のＷｅｂサービス定義文書を示す図。 図４に示す類似性判定処理の対象となるＷｅｂサービス定義文書の具体例として、第３のＷｅｂサービス定義文書を示す図。 図４に示す類似性判定処理の対象となるＷｅｂサービス定義文書の具体例として、第４のＷｅｂサービス定義文書を示す図。 図５〜図８に示すＷｅｂサービス定義文書の各々について、戻り値のデータ型のツリー表記を示す図。 図５、図６に示すＷｅｂサービス定義文書について生成されたデータ変換ルールの一例を示す図。 図５、図７に示すＷｅｂサービス定義文書について生成されたデータ変換ルールの一例を示す図。 図５、図８に示すＷｅｂサービス定義文書について生成されたデータ変換ルールの一例を示す図。

符号の説明

１００…Ｗｅｂサービスリクエスタ
１１０…クライアントアプリケーション
１２０…プロキシモジュール
１３０…データ変換モジュール
１３１…類似性判定モジュール
１３２…要求データ変換モジュール
１３３…応答データ変換モジュール
１３４…変換ルール格納庫
１４０…ＳＯＡＰ処理モジュール
２００…Ｗｅｂサービスプロバイダ
２１０…Ｗｅｂサービス実装
２２０…ＳＯＡＰ処理モジュール
２３０…Ｗｅｂサービス定義文書格納庫
３００…通信ネットワーク

Claims (5)

1. クライアント端末上で入力された接続要求に応じてＷｅｂサービス端末にアクセスし、Ｗｅｂサービス端末から受け取った接続応答を当該接続要求の結果データとしてクライアント端末上で出力するためのＷｅｂサービス接続処理方法において、
   各前記Ｗｅｂサービス端末のインタフェースで取り扱い可能なデータ形式に関する情報を含むインタフェース情報をそれぞれ定義した個々のＷｅｂサービス定義文書が存在する状況の下で、
   前記クライアント端末または当該クライアント端末と前記Ｗｅｂサービス端末とを接続するデータ処理装置により、
   前記クライアント端末の接続先として予め想定された前記Ｗｅｂサービス端末の前記Ｗｅｂサービス定義文書が想定接続先Ｗｅｂサービス定義文書として与えられると共に、新たな接続先のＷｅｂサービス端末の前記Ｗｅｂサービス定義文書が新規接続先Ｗｅｂサービス定義文書として与えられた場合に、想定接続先Ｗｅｂサービス定義文書と新規接続先Ｗｅｂサービス定義文書の構造的類似性を判定し、この判定結果に基づいて、想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のデータと新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のデータとの間の構造変換ルールを生成する類似性判定ステップと、
   前記構造変換ルールに基づいて、前記想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続要求データを、前記新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続要求データに変換する接続要求変換ステップと、
   前記構造変換ルールに基づいて、前記新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続応答データを、前記想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続応答データに変換する接続応答変換ステップ、
   を行うことを特徴とするＷｅｂサービス接続処理方法。
2. 前記類似性判定ステップにおいて、
   前記想定接続先Ｗｅｂサービス定義文書と前記新規接続先Ｗｅｂサービス定義文書中で定義されたデータ形式の差異を抽出し、抽出結果に基づいて前記構造的類似性を判定し、前記構造変換ルールを生成する、
   ことを特徴とする請求項１に記載のＷｅｂサービス接続処理方法。
3. 前記類似性判定ステップにおいて、
   枝刈り、中間ノードの除去、ラベルの付け替え、の中から選択された一つ以上の手法を用いて前記構造的類似性を判定し、前記構造変換ルールを生成する、
   ことを特徴とする請求項２に記載のＷｅｂサービス接続処理方法。
4. クライアント端末上で入力された接続要求に応じてＷｅｂサービス端末にアクセスし、Ｗｅｂサービス端末から受け取った接続応答を当該接続要求の結果データとしてクライアント端末上で出力するためのＷｅｂサービス接続処理システムにおいて、
   各前記Ｗｅｂサービス端末のインタフェースで取り扱い可能なデータ形式に関する情報を含むインタフェース情報をそれぞれ定義した個々のＷｅｂサービス定義文書が存在する状況の下で、
   前記クライアント端末と前記Ｗｅｂサービス端末との間またはクライアント端末側にデータ変換手段が設けられ、このデータ変換手段は、
   前記クライアント端末の接続先として予め想定された前記Ｗｅｂサービス端末の前記Ｗｅｂサービス定義文書が想定接続先Ｗｅｂサービス定義文書として与えられると共に、新たな接続先のＷｅｂサービス端末の前記Ｗｅｂサービス定義文書が新規接続先Ｗｅｂサービス定義文書として与えられた場合に、想定接続先Ｗｅｂサービス定義文書と新規接続先Ｗｅｂサービス定義文書の構造的類似性を判定し、この判定結果に基づいて、想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のデータと新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のデータとの間の構造変換ルールを生成する類似性判定処理と、
   前記構造変換ルールに基づいて、前記想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続要求データを、前記新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続要求データに変換する接続要求変換処理と、
   前記構造変換ルールに基づいて、前記新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続応答データを、前記想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続応答データに変換する接続応答変換処理を行うように構成されている、
   ことを特徴とするＷｅｂサービス接続処理システム。
5. クライアント端末上で入力された接続要求に応じてＷｅｂサービス端末にアクセスし、Ｗｅｂサービス端末から受け取った接続応答を当該接続要求の結果データとしてクライアント端末上で出力するためのＷｅｂサービス接続処理プログラムにおいて、
   各前記Ｗｅｂサービス端末のインタフェースで取り扱い可能なデータ形式に関する情報を含むインタフェース情報をそれぞれ定義した個々のＷｅｂサービス定義文書が存在する状況の下で、
   前記クライアント端末の接続先として予め想定された前記Ｗｅｂサービス端末の前記Ｗｅｂサービス定義文書が想定接続先Ｗｅｂサービス定義文書として与えられると共に、新たな接続先のＷｅｂサービス端末の前記Ｗｅｂサービス定義文書が新規接続先Ｗｅｂサービス定義文書として与えられた場合に、想定接続先Ｗｅｂサービス定義文書と新規接続先Ｗｅｂサービス定義文書の構造的類似性を判定し、この判定結果に基づいて、想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のデータと新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のデータとの間の構造変換ルールを生成する類似性判定機能と、
   前記構造変換ルールに基づいて、前記想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続要求データを、前記新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続要求データに変換する接続要求変換機能と、
   前記構造変換ルールに基づいて、前記新規接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続応答データを、前記想定接続先Ｗｅｂサービス定義文書に準ずるデータ形式のＷｅｂサービス接続応答データに変換する接続応答変換機能、
   をコンピュータに実現させることを特徴とするＷｅｂサービス接続処理プログラム。