JPWO2004021234A1 - ネットワークシステム、プロバイダ、管理サイト、リクエスタ及びプログラム - Google Patents

Abstract

ＵＤＤＩに対するウェブサービスの検索に際して、適切な選択基準の提供を実現する。ウェブサービスを提供するプロバイダ１０において、提供するウェブサービスの良し悪しを判断するための実績情報を採取し、ＵＤＤＩサイト２０へ送信する。そして、ＵＤＤＩサイト２０において、この実績情報を管理し、リクエスタ３０からのウェブサービスの検索要求に対し、検索されたウェブサービスと共にこのウェブサービスの実績情報を返送する。

Description

本発明は、ネットワークを介してウェブサービスを使用するシステムに関し、特にウェブサービスの検索に特徴を有するシステム関する。

インターネットの普及に伴い、インターネットで利用されているウェブベースの情報交換技術の新しい利用形態として、ウェブサービス（Ｗｅｂ ｓｅｒｖｉｃｅ）が注目されている。ネットワークを介して提供されるソフトウェアサービスの一種であるウェブサービスは、インターネット上のソフトウェア・コンポーネントに対して、動的な疎結合接続を可能にするものである。サービスとしてソフトウェアの機能を提供するウェブサイト（ウェブサーバ）は、作成したサービスをカプセル（接続用のコードで包んだ形）化してインターネット上に公開することにより、サービスを要求するウェブサイトやウェブ端末からのサービス利用を可能にする。ウェブサービスは、情報の登録及び検索が可能な蓄積管理システムであるレジストリ機能としてＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｉｓｃｏｖｅｒｙ，ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ）、提供するサービスを説明する記述言語としてＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）、通信プロトコルとしてＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）、データ記述言語仕様としてＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、などの公開技術を用いている。
なお、ＵＤＤＩについては下記文献１、２に、ＷＳＤＬについては下記文献３、４に、ＳＯＡＰについては下記文献５に、ＸＭＬについては下記文献６に、ウェブサービスについては下記文献７に詳細に記載されている。
文献１：ＵＤＤＩ Ｖ２．０４ ＡＰＩ Ｓｐｅｃｉｆｉｃａｔｉｏｎ
ｈｔｔｐ：／／ｗｗｗ．ｕｄｄｉ．ｏｒｇ／ｐｕｂｓ／ＰｒｏｇｒａｍｍｅｒｓＡＰＩ−Ｖ２．０４−Ｐｕｂｌｉｓｈｅｄ−２００２０７１９．ｐｄｆ
文献２：ＵＤＤＩ Ｖ２．０３ Ｄａｔａ Ｓｔｒｕｃｔｕｒｅ Ｒｅｆｅｒｅｎｃｅ
ｈｔｔｐ：／／ｗｗｗ．ｕｄｄｉ．ｏｒｇ／ｐｕｂｓ／ＤａｔａＳｔｒｕｃｔｕｒｅ−Ｖ２．０３−Ｐｕｂｌｉｓｈｅｄ−２００２０７１９．ｐｄｆ
文献３：Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ（ＷＳＤＬ）Ｖｅｒｓｉｏｎ １．１
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００１／ＮＯＴＥ−ｗｓｄｌ−２００１０３１５
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｗｓｄｌ
文献４Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ（ＷＳＤＬ）Ｖｅｒｓｉｏｎ １．２
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００２／ＷＤ−ｗｓｄｌ１２−２００２０７０９
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｗｓｄｌ１２
文献５：ＳＯＡＰ Ｖｅｒｓｉｏｎ １．２
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００１／ＷＤ−ｓｏａｐ１２−２００１０７０９／
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｓｏａｐ１２／
文献６Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）１．０（Ｓｅｃｏｎｄ Ｅｄｉｔｉｏｎ）
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ＲＥＣ−ｘｍｌ
文献７：Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｒｅｑｕｉｒｅｍｅｎｔ
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／２００２／ＷＤ−ｗｓａ−ｒｅｑｓ−２００２０８１９
ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｗｓａ−ｒｅｑｓ
図１３は、ウェブサービスのアーキテクチャを示す図である。
図１３を参照すると、ウェブサービスを実現するためのアーキテクチャは、ネットワークを介して相互にデータ交換が可能な、プロバイダ（サービス提供者）１３１、ＵＤＤＩサイト１３２、リクエスタ（サービス利用者）１３３とを含む。ウェブサービスは、これら３者の間のデータ交換により実現される。すなわち、まずプロバイダ１３１が、提供するサービスを実装する〔１〕。そして、実装されたサービスに関する情報をＵＤＤＩサイト１３２へ登録、公開する〔２〕。次に、リクエスタ１３３が、ＵＤＤＩサイト１３２に対して所望のサービスの検索要求を行う〔３〕。所望のサービスが見つかったならば、リクエスタ１３３は、プロバイダ１３１に接続してサービスを要求し〔４〕、プロバイダ１３１はリクエスタ１３３に結果（応答）を返す〔５〕。
従来、ウェブサービスにおいて、ＵＤＤＩサイト１３２に登録される情報は、例えば、サービス提供者である企業体を特定する情報（企業体名等）、業務内容（サービス名等）、サービスをバインドするのに必要な情報（ＵＲＬ等）である。ここで、サービスをバインドするとは、サービス（サービス・コンポーネント）のＵＲＬアドレス、接続インターフェース（プロトコル、接続メソッド（接続コード））を得て、そのサービスに接続することである。また、サービス・コンポーネントとは、サービスを他者からのアクセスを可能にするためにカプセル化したものである。これらの情報は、図１３を参照して分かるように、実際にサービスの提供開始に先立って登録される静的な情報であった。
上記のように、従来のウェブサービスにおいてＵＤＤＩサイトに登録される情報は、サービス提供開始前に用意される静的な情報であった。このため、リクエスタが所望のサービスを検索した際、同じようなサービスが複数検索された場合に、いずれのサービスを選ぶかについての効果的な選択基準がなかった。
このような場合に、適切な選択基準を提供することができれば、ウェブサービスによるサービスの提供に競争原理を導入できる。すなわち、プロバイダは、自らが提供するサービスが選択されるように工夫を重ねることが容易に想像される。これにより、ウェブサービスによる活動（特に、インターネットを用いた商取引などのビジネス活動）の活性化が強力に推進されることが期待できる。
また、この選択基準として、提供されるサービスの質を客観的に表す情報を提供することができれば、プロバイダは、提供するサービスの質を向上しようとするようになり、リクエスタにとっても、より質の高いサービスを享受できることとなる。
そこで、本発明は、ウェブサービスの検索に際して、適切な選択基準の提供を実現することを目的とする。
また、本発明は、上記の選択基準として、サービスの質を判断するための客観的な情報を提供することを他の目的とする。

上記の目的を達成する本発明は、ネットワークを用いてサービスを利用する、次のようなネットワークシステムとして実現される。すなわち、このネットワークシステムは、サービスを提供し、提供されるサービスの質を判断するための情報を採取するプロバイダと、このプロバイダにより提供されるサービス及びプロバイダにて採取された前記サービスの質を判断するための情報を登録し管理する管理サイトとを備えることを特徴とする。
ここで、サービスとしてウェブ関連の技術を用いたウェブサービスを実現する場合、管理サイトは、ウェブサービスの検索・照会システムであるＵＤＤＩを備えたＵＤＤＩサイトとすることができる。
このサービスの質を判断するための情報としては、サービスの実際の運用における実績情報、具体的には、サービスの利用回数、利用頻度、サービスを実行する際の所要時間、サービスの休止時間等を用いることができる。これらの情報はサービスのためのデータ処理の実行に伴って数値的に採取することが容易であるので、サービスの質を客観的に判断するための情報として用いることができる。
また、このネットワークシステムは、管理サイトに対してサービスの検索を行い、サービスの質を判断するための実績情報を伴う検索結果を取得し、この検索結果に基づいて利用するサービスを決定して、決定されたウェブサービスを提供するプロバイダにサービスを要求するリクエスタを備える構成とすることができる。
より詳細には、上述したプロバイダは、サービスのための処理を実行するサービス実行部と、サービス実行部による処理の実行に基づき、サービスの質を判断するための情報を採取するサービス質情報採取部とを備えることを特徴とする。
また、管理サイトは、サービスに関する情報を登録して管理する第１の管理手段と、この第１の管理手段に登録されているサービスの質を判断するための実績情報を管理する第２の管理手段とを備えることを特徴とする。
ここで、この管理サイトは、第２の管理手段にて管理されているサービスの質を判断するための実績情報の検索をサービスとして第１の管理手段に登録し、リクエスタに提供することができる。
管理サイトの第２の管理手段は、このサービスの質を判断するための実績情報を、かかるサービスを提供するプロバイダから取得する。プロバイダにて提供されるサービスがウェブサービスである場合、一般に、この情報はＷＳＤＬを用いて既述されたＸＭＬ文書として送られるが、第２の管理手段は、リクエスタからの検索要求に応じて検索を行う場合のパフォーマンス向上を図るため、この情報をリレーショナルデータベース構造に変換する。また、ＸＭＬ文書に記載されているデータを検索に応じた内容の情報（１日の利用頻度、サービスを実行する際の所要時間等）に変換して格納しておくことができる。
また、上述したリクエスタは、ネットワークを介して上述した管理サイトに対し所望のサービスの検索要求を行い、サービスの質を判断するための実績情報を含む検索結果を取得するサービス検索部と、このサービス検索部にて取得された検索結果に基づいて所定のサービスを選択し、このサービスを提供するプロバイダに対し、ネットワークを介して、このサービスの実行要求を行うサービス要求部とを備えることを特徴とする。
サービスの質を判断するための実績情報を含む検索結果に基づいてプロバイダに要求するサービスを選択する手法としては、検索された各サービスにおける実績情報を比較し、利用件数（サービスの人気の度合）のポイントの高いものや、サービスを実行する際の所要時間の短いものをパラメータとして、優先順位を決める手法を取ることができる。
さらに、このリクエスタは、サービス検索部にて取得された検索結果を、サービスの質を判断するための実績情報を反映させて所定の表示装置に表示する表示制御部を備える構成とすることもできる。
さらにまた、本発明は、コンピュータを制御して、上述したプロバイダ、管理サイトまたはリクエスタを実現するプログラムとして実現することができる。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供することができる。
特に、プロバイダにおけるサービスの質を判断するための情報を採取するための機能や、リクエスタにおけるサービスの質を判断するための実績情報を含む検索結果に基づいてプロバイダに要求するサービスを選択する機能は、かかる機能を実現するプログラムファイルをオブジェクト指向プログラミングにおけるクラス・ライブラリとして提供することができる。このようにすれば、これらの機能を、サービスの提供や検索といったプロバイダやリクエスタの本来の機能から隠蔽することができる。

図１は、本実施の形態におけるウェブサービスのアーキテクチャを示す図である。
図２は、本実施の形態によるウェブサービスを実現するための機能層（レイヤ）を示す図である。
図３は、本実施の形態におけるプロバイダ、ＵＤＤＩサイト及びリクエスタを実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図４は、本実施の形態で用いられるサービス質情報を記載したｓｑＭＬの例を示す図である。
図５は、図４のｓｑＭＬにおける各タグの意味を説明する図表である。
図６は、本実施の形態におけるプロバイダの機能を説明する図である。
図７は、本実施の形態におけるプロバイダの機能を、オブジェクト指向プログラミングにて実現する場合の構成例を示すクラス図である。
図８は、図７に対応するシーケンス図である。
図９は、本実施の形態におけるＵＤＤＩサイトの機能を説明する図である。
図１０は、本実施の形態におけるリクエスタの機能を説明する図である。
図１１は、本実施の形態において、サービス質情報を含む検索結果に基づき、利用するサービスを決定するためのロジックの例を示す図である。
図１２は、本実施の形態におけるサービスの検出結果の表示画面の構成例を示す図である。
図１３は、従来のウェブサービスのアーキテクチャを示す図である。
発明を実施するための最良の態様
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
まず、本発明の概要を説明する。本発明では、サービス利用者がＵＤＤＩサイトに対してウェブサービスの検索を行った場合に、サービスの良し悪しを判断するための情報、すなわちサービスの質を表す情報を提供できるシステムを構築する。この情報（以下、サービス質情報）は、実際のサービスの提供に伴って得られる動的な情報である。サービスの質に対する評価カテゴリとしては、第三者による評価やサービスの利用者自身による評価など、種々の者が考えられるが、本発明では、数値的に検出可能な評価基準として、サービスの実際の運用における実績情報（利用件数、利用頻度、サービスを実行する際の所要時間、サービスの休止時間等）を用いる。すなわち、サービス提供者の運用に伴って、かかる運用実績に関する情報を収集し、ＵＤＤＩサイトにおいて、各サービス提供者におけるサービスの質を表す情報として提供する。
図１は、本実施の形態におけるウェブサービスのアーキテクチャを示す図である。
図１を参照すると、本実施の形態におけるウェブサービスを実現するためのアーキテクチャは、ネットワークを介して相互にデータ交換が可能な、プロバイダ（サービス提供者）１０、ＵＤＤＩサイト２０、リクエスタ（サービス利用者）３０とを含む。これらの構成要素は、例えばワークステーションやパーソナルコンピュータ等のネットワーク機能を備えたコンピュータ装置にて実現される。ウェブサービスは、これら３者の間のデータ交換により実現される。
具体的には、まずプロバイダ１０が、提供するサービスを実装する〔１〕。このとき、本実施の形態にて提供されるクラス・ライブラリから、サービス質情報採取機能とサービス質情報送信機能とを実現するプログラム（クラス）を取得し、プロバイダ１０を実現するコンピュータ装置の制御プログラムに組み込む。ここでは、プロバイダ１０がサービスを提供するための制御プログラムは、Ｊａｖａ（米国サンマイクロシステムズ株式会社の商標）等のオブジェクト指向プログラミング言語にて記述されており（すなわち、サービスのための具体的なデータ処理は所定のメソッドにて実行される）、クラス・ライブラリにて特定の機能を有するプログラムファイルを提供できることを前提としている。これにより、プロバイダ１０は、このサービス質情報採取機能及びサービス質情報送信機能を容易に実現できる。なお、サービス質情報採取機能及びサービス質情報送信機能の詳細については後述する。
次に、プロバイダ１０は、実装されたサービスに関する情報を、ＷＳＤＬを用いてＵＤＤＩサイト２０へ登録し、公開する〔２〕。
次に、リクエスタ３０が、ＵＤＤＩサイト２０に対して所望のサービスの検索要求を行う〔３〕。このとき、当該サービスの質に関する情報が収集されていれば、この情報も一緒に得られることとなる。
所望のサービスが検索されたならば、リクエスタ３０は、得られたサービスの質に関する情報を踏まえて、利用するサービスを提供するプロバイダ１０を選択し、プロバイダ１０に接続してサービスを要求する〔４〕。
サービスの要求を受けたプロバイダ１０は、当該サービスのためのデータ処理を実行し、結果をリクエスタ３０に返す〔５−１〕。このデータ処理の前後に、上述したサービス質情報採取機能により、運用実績に関する情報がサービス質情報として採取される〔５−２〕。また、データ処理の完了後に、上述したサービス質情報送信機能により、採取されたサービス質情報をＳＯＡＰにてＵＤＤＩサイト２０へ送信する〔５−３〕。
ＵＤＤＩサイト２０は、プロバイダ１０から送られたサービス質情報を受信し、データベースに蓄積する〔６〕。
図２は、本実施の形態によるウェブサービスを実現するための機能層（レイヤ）を示す図である。
ウェブサービスの実現に必要とされる一般的な機能層は、物理レベルに近い方から、ＴＣＰ／ＩＰ、ＳＯＡＰ、ＷＳＤＬ、ＵＤＤＩを備える。本実施の形態において実現されるプロバイダ１０のサービス質情報採取機能や、ＵＤＤＩサイト２０のサービス質情報管理機能、リクエスタ３０のサービス質情報の検索機能などは、図２に示すように、ＵＤＤＩ層の上に実装された機能層にて実装される。この機能層をブースターコンテナ（Ｂｏｏｓｔｅｒ Ｃｏｎｔａｉｎｅｒ）層と呼ぶ。サービスのためのデータ処理を実行するアプリケーションは、このブースターコンテナ層の上に構築される。このように構成することで、ブースターコンテナ層は、アプリケーション開発から隠蔽される。すなわち、サービス質情報採取機能などを実現するソラトウェアを、アプリケーション開発者が具体的な取り決めの下に自分で作成する必要はなく、ブースターコンテナ層で機能するツールとして提供されているクラス・ライブラリを利用すれば良い。
図３は、図１に示したプロバイダ１０、ＵＤＤＩサイト２０及びリクエスタ３０を実現するのに好適なコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図３に示すコンピュータ装置は、演算手段であるＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２及びＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２及びＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスを介してＭ／Ｂチップセット１０２に接続されたハードディスク１０５、ネットワークインターフェイス１０６及びＵＳＢポート１０７と、さらにこのＰＣＩバスからブリッジ回路１０８及びＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１０９及びキーボード／マウス１１０とを備える。
なお、図３は本実施の形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、ＡＴＡ（ＡＴ Ａｔｔａｃｈｍｅｎｔ）などのインターフェイスを介してＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やＤＶＤ−ＲＯＭ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）のドライブを設けても良い。
次に、本実施の形態において、プロバイダ１０におけるサービス（メソッド）の実行に伴って採取されるサービス質情報について説明する。
本実施の形態では、プロバイダ１０において採取されたサービス質情報をＸＭＬ文書に記述する。このＸＭＬ文書をｓｑＭＬ（Ｓｅｒｖｉｃｅ Ｑｕａｌｉｔｙ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）と名付ける。ｓｑＭＬには必須項目と選択項目が設けられる。図４は、ｓｑＭＬの例を示す図、図５は、図４のｓｑＭＬにおける各タグの意味を説明する図表である。図４、５に示すように、ｓｑＭＬには、デコレータの実行時刻、属性、デコレータを呼び出したサービスの名前及びアドレス、デコレータの処理名、処理属性、選択項目の内容などが記述される。ここで、デコレータとは、サービス（メソッド）の実行に伴って、サービス質情報を採取する付加機能としての隠蔽されたコード（メソッド）である。
次に、本実施の形態のウェブサービスを実現するための個々の構成要素について、詳細に説明する。
図６は、プロバイダ１０の機能を説明する図である。
図６を参照すると、プロバイダ１０は、提供するサービスを実行するサービス実行部１１と、サービス質情報を採取するサービス質情報採取部（デコレータ）１２と、採取されたサービス質情報をＵＤＤＩサイト２０へ送信する非同期送信制御部１３とを備える。また、特に図示しないが、サービスの提供開始に先立って、実装されたサービスに関する情報を、ＷＳＤＬを用いてＵＤＤＩサイト２０に登録する機能を備える。
これらの構成要素は、プログラム（メソッド）の制御により、例えば図３のＣＰＵ１０１にて実現される仮想的なソフトウェアブロックである。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録装置に格納して配布したり、ネットワークを介して配信したりすることにより提供される。そして、図３に示したメインメモリ１０３に格納されてＣＰＵ１０１を制御することにより、これらの機能を実現する。
サービス実行部１１は、リクエスタ３０からのサービス要求を受け付け、プロバイダ１０が提供する当該サービスのためのデータ処理を実行する。そして、データ処理の結果をリクエスタ３０に返送する。
サービス質情報採取部１２は、サービス実行部１１によるサービス（メソッド）の実行の前後に、ｓｑＭＬを生成し、シリアライズ（例えば図３のメインメモリ１０３の作業エリアや作業ファイルへ一時的に格納）する。
非同期送信制御部１３は、サービス質情報採取部１２にて生成され、シリアライズされたｓｑＭＬをデシリアライズした（作業ファイル等に格納されたｓｑＭＬを読み出した）後、例えば図３に示したネットワークインターフェイス１０６を制御し、デシリアライズされたｓｑＭＬを、ＳＯＡＰを用いてＵＤＤＩサイト２０に非同期送信する。
図７は、上記のサービス実行部１１及びサービス質情報採取部１２による機能を、オブジェクト指向プログラミングにて実現する場合の構成例を示すクラス図、図８は、この場合のシーケンス図である。
図７、８に示すように、これらの機能は、いわゆるＧｏＦのデザインパターン（Ｄｅｓｉｇｎ Ｐａｔｔｅｒｎｓ ｂｙ Ｅｒｉｃｈ Ｇａｍｍａ，Ｒｉｃｈａｒｄ Ｈｅｌｍ，Ｒａｌｐｈ Ｊｏｈｎｓｏｎ，Ｊｏｈｎ Ｖｌｉｓｓｉｄｅｓ）のデコレータ・パターン（Ｄｅｃｏｒａｔｏｒ Ｐａｔｔｅｒｎ）を用いて実装することができる。デコレータ・パターンは、所定のメソッドに、他のメソッドを次々に付加していく際に、元のメソッドから付加するメソッドを隠蔽することができる。
なお、本実施の形態では、オブジェクト指向プログラミングにおける、機能の再利用テクニック（継承、隠蔽等のノウハウ）として２３個のパターンをまとめ、教則本として周知であるＧｏＦのデザインパターンから、デコレータ・パターンを使用した。ＧｏＦのデザインパターンについては、例えば、下記文献８、９に詳細に記載されている（文献９は文献８の訳書）。
文献８：Ｄｅｓｉｇｎ Ｐａｔｔｅｒｎｓ Ｅｌｅｍｅｎｔｓ ｏｆ Ｒｅｕｓａｂｌｅ Ｏｂｅｊｅｃｔ−Ｏｒｉｅｎｔｅｄ Ｓｏｆｔｗａｒｅ ｂｙ Ｅｒｉｃｈ Ｇａｍｍａ，Ｒｉｃｈａｒｄ Ｈｅｌｍ，Ｒａｌｐｈ Ｊｏｈｎｓｏｎ，Ｊｏｈｎ Ｖｌｉｓｓｉｄｅｓ／Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏｍｐａｎｙ
文献９：オブジェクト指向における再利用のためのデザインパターン本位田真一／吉田和樹 監訳，ＳＯＦＴＢＡＮＫ
サービス質情報採取部１２による、プロバイダ１０が提供するサービス（メソッド）の前後に、ｓｑＭＬを生成し、シリアライズする処理（メソッド）をデコレータ処理と呼ぶ。デコレータ処理は、図７のＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＢｅｆｏｒｅ及びＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＡｆｔｅｒのＯｐｅｒａｔｉｏｎ（）で提供される。デコレータ処理において生成されるｓｑＭＬの必須項目は以下の通りである。
・各デコレータ（ＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＢｅｆｏｒｅ、ＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＡｆｔｅｒ）の名前と属性
・ＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＢｅｆｏｒｅにおけるＯｐｅｒａｔｉｏｎ（）メソッド実行時の時間
・ＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＡｆｔｅｒにおけるＯｐｅｒａｔｉｏｎ（）メソッド実行時の時間
・ＣｏｎｃｒｅｔｅＣｏｍｐｏｎｅｎｔにおけるＯｐｅｒａｔｉｏｎ（）メソッド名、ＵＲＬ
また、デコレータ処理をオーバーライド（Ｏｖｅｒｒｉｄｅ）することにより、さらに個々のプロバイダ１０のサービスに固有の情報を採取することができる。
サービス実行部１１による、プロバイダ１０が提供するサービス（メソッド）自体は、図７のＣｏｎｃｒｅｔｅＣｏｍｐｏｎｅｎｔにおけるＯｐｅｒａｔｉｏｎ（）に実装される。
図８を参照して、これらのクラスの実行シーケンスを見ると、まずＳｅｒｖｉｃｅＭｅｔｈｏｄＯｐｅｒａｔｉｏｎが実行され、その中でＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＢｅｆｏｒｅが呼ばれて、Ｏｐｅｒａｔｉｏｎ（）メソッド実行時（サービス開始時に相当）の時間が採取される。次に、ＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＢｅｆｏｒｅの中でＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＡｆｔｅｒが呼ばれ、さらにその中でＣｏｎｃｒｅｔｅＣｏｍｐｏｎｅｎｔが呼ばれて、サービス（メソッド）が実行される。サービス（メソッド）が終了すると、ＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＡｆｔｅｒに戻り、Ｏｐｅｒａｔｉｏｎ（）メソッド実行時（サービス終了時に相当）の時間が採取される。そして、ＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＢｅｆｏｒｅに戻り、さらにＳｅｒｖｉｃｅＭｅｔｈｏｄＯｐｅｒａｔｉｏｎに戻って処理を終了する。
以上のようにして、サービス質情報を採取する処理（デコレータ処理）は、サービス（メソッド）から隠蔽される。
図９は、ＵＤＤＩサイト２０の機能を説明する図である。
図９を参照すると、ＵＤＤＩサイト２０は、プロバイダ１０が提供するウェブサービスの検索・照会システムであるＵＤＤＩ２１と、プロバイダ１０から送信されたｓｑＭＬを受信する非同期受信制御部２２と、サービス質情報を管理する管理システムとして、サービス質情報蓄積照会部２３及びデータベースであるＳＱＭ（Ｓｅｒｖｉｃｅ Ｑｕａｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ）２４とを備える。
これらの構成要素は、プログラム（メソッド）の制御により、例えば図３のＣＰＵ１０１にて実現される仮想的なソフトウェアブロックである。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録装置に格納して配布したり、ネットワークを介して配信したりすることにより提供される。そして、図３に示したメインメモリ１０３に格納されてＣＰＵ１０１を制御することにより、これらの機能を実現する。また、ＵＤＤＩ２１やＳＱＭ２２にて管理されるデータは、例えば図３のメインメモリ１０３やハードディスク１０５に格納される。
ＵＤＤＩ２１は、プロバイダ１０にて提供されるウェブサービスに関する情報を登録し集積して管理する。また、リクエスタ３０からの検索要求に応じて当該検索要求に適合する登録情報（ウェブサービスに関する情報）を検索する。そして、検索結果をリクエスタ３０に返送する。
非同期受信制御部２２は、プロバイダ１０から送信されたｓｑＭＬを受信し、サービス質情報蓄積照会部２３に渡す。
サービス質情報蓄積照会部２３は、ｓｑＭＬをＳＱＭ２４へ格納すると共に、リクエスタ３０からの検索要求に応じてサービス質情報の検索を行う。また、ＳＱＭ２４に対する検索処理のパフォーマンスを向上させるため、所定の前処理を行う。具体的には、ＸＭＬパーサーを用いて、ＸＭＬ文書であるｓｑＭＬをリレーショナルデータベース構造に変換する。そして、情報をリクエスタ３０において利用しやすい形式に変換する。例えば、サービス（メソッド）の実行に要した実時間の計算（ＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＡｆｔｅｒにおけるＯｐｅｒａｔｉｏｎ（）メソッド実行時の時間から、ＣｏｎｃｒｅｔｅＤｅｃｏｒａｔｏｒＢｅｆｏｒｅにおけるＯｐｅｒａｔｉｏｎ（）メソッド実行時の時間を引く）や、サービス（メソッド）の実行回数の計算などを行う。したがって、リクエスタ３０からの検索要求に対しては、これらの情報がサービス質情報として返送されることとなる。
通常、サービス質情報蓄積照会部２３に対する検索は、ＵＤＤＩ２１に対する検索と一緒に行われ、サービス質情報蓄積照会部２３により検索されるサービス質情報は、ＵＤＤＩ２１により検索されたサービスに関する情報に対応している（すなわち当該サービスに関するサービス質情報である）。したがって、サービス質情報蓄積照会部２３の検索結果は、通常、ＵＤＤＩ２１の検索結果と一緒にリクエスタ３０に返送される。そこで、以下の説明では、ＵＤＤＩ２１による検索結果とサービス質情報蓄積照会部２３により検索されたサービス質情報とをリクエスタ３０に返送する場合、検索結果にサービス質情報を付加して返送、検索結果をサービス質情報と共に返送などと表現する。実際には、ＵＤＤＩ２１による検索結果とサービス質情報とが関係付けられていれば良く、送信態様（別ファイルとして送信したり、１つのファイルにパッケージ化して送信したりする等）によらない。また、ＵＤＤＩ２１による検索結果とサービス質情報蓄積照会部２３による検索結果とを合わせてサービス質情報を含む検索結果等とも表現する。
ＳＱＭ２４は、プロバイダ１０から送信されたｓｑＭＬを格納し蓄積する。ＳＱＭ２４に蓄積されたｓｑＭＬのサービス質情報は、リクエスタ３０からの検索要求によりＵＤＤＩ２１が検索された際に、検索結果であるウェブサービスに対応するものが検索され、付加情報として検索結果と共にリクエスタ３０に送られることとなる。
なお、サービス質情報蓄積照会部２３及びＳＱＭ２４を実現するデータベースとして、例えば米国ＩＢＭ社のＤＢ２／ＵＤＢ（ユニバーサルデータベース）を用いる場合、ＷＯＲＦ（ＷｅｂＳｅｒｖｉｃｅｓ Ｏｂｊｅｃｔ Ｒｕｎｔｉｍｅ Ｆｒａｍｅｗｏｒｋ）及びＸＭＬエクステンダを用いることにより、ｓｑＭＬをＸＭＬ文書からリレーショナルデータベース構造に変換する処理を容易に行うことができ、プロバイダ１０から受信したｓｑＭＬをＳＱＭ２４に格納する時点で変換を行っておくことができる。
図１０は、リクエスタ３０の機能を説明する図である。
図１０を参照すると、リクエスタ３０は、ＵＤＤＩサイト２０に対して所望のサービスの検索要求を行うサービス検索部３１と、プロバイダ１０に対してサービスの実行要求を行うサービス要求部３２とを備える。
これらの構成要素は、プログラム（メソッド）の制御により、例えば図３のＣＰＵ１０１にて実現される仮想的なソフトウェアブロックである。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録装置に格納して配布したり、ネットワークを介して配信したりすることにより提供される。そして、図３に示したメインメモリ１０３に格納されてＣＰＵ１０１を制御することにより、これらの機能を実現する。
サービス検索部３１は、ＵＤＤＩサイト２０に接続し、ＵＤＤＩ２１に対して所望のサービスの検索要求を行う。また、サービス質情報蓄積照会部２３に対して対応するサービス質情報の検索要求を行う。そして、検索結果を受信する。サービス質情報蓄積照会部２３への検索要求を行う機能は、当該機能を実現するプログラムファイルをクラス・ライブラリとして提供することにより、容易にサービス検索部３１に組み込むことができる。
サービス要求部３２は、サービス検索部３１にて取得されたサービスの検索結果から、所定のサービスを選択し、当該サービスを提供するプロバイダ１０に接続してサービス要求を送信する。そして、サービスの実行結果を受信する。ここで、サービス要求部３２は、検索結果の中から所定のサービスを選択する場合に、当該検索結果と共に取得したサービス質情報を参酌することができる。サービス質情報には、上述したように、サービスの実行に要した実時間やサービスの実行回数などが含まれるため、例えば、サービスの実行に要した実時間の短い（すなわち応答の早い）プロバイダ１０、サービスの実行回数の多い（すなわち人気のある）プロバイダ１０といような、適当な判断基準を設けてサービスを選択することができる。
図１１は、サービス検索部３１にて取得された、サービス質情報を含む検索結果に基づき、利用するサービスを決定するためのロジックの例を示す図である。
図１１に示す３つのロジックの例では、取得された検索結果の各サービスに関して、平均サービス時間（サービス実行に要する実時間の平均）とアクセス頻度（一定時間（例えば１日）のアクセス件数）を比較する。ロジック１は、平均サービス時間が第１位（最も短い）であり、アクセス頻度が第１位（最も多い）であるものを選択し、そのサービスを使うことを決定する。ロジック２は、平均サービス時間が第１位でなくても、アクセス頻度が第１位（最も多い）であるものを選択し、そのサービスを使うことを決定する。たとえサービスの処理の実行に時間がかかっても、人気の高いサービスは信用に足ることを考慮したロジックである。ロジック３は、平均サービス時間が第３位（３番目に短い）よりも上位であり、アクセス頻度が第１位（最も多い）であるものを選択し、そのサービスを使うことを決定する。人気の高いサービスであることを重視するが、サービスの実行における所用時間もある程度考慮したロジックである。
以上のようにして、利用するサービスが決定され、サービス要求部３２により、当該サービスに対応するＵＲＬ（当該サービスを提供するプロバイダ１０のＵＲＬ）を宛先としてサービス要求の送信が行われる。
また、サービス要求部３２にてプログラム制御により機械的に要求するサービスを選択するだけでなく、リクエスタ３０のユーザに検索結果を提示して、ユーザによる選択を促すこともできる。例えば、リクエスタ３０の機能として図１０に記載しない表示制御部を備える構成とし、当該表示制御部の制御により、所定の表示装置に、サービス検索部３１の検索結果にサービス質情報を反映させて表示し、ユーザが任意のサービスを選択することを促す。そして、サービス要求部３２が、ユーザにより選択されたサービスを提供するプロバイダ１０にサービス要求を行う。このようなリクエスタ３０の態様は、例えば、リクエスタ３０が企業等で用いられるサーバではなく、個人が用いる端末装置であって、サービス検索部３１、サービス要求部３２及び図示しない表示制御部として機能するウェブブラウザによりＵＤＤＩサイト２０やプロバイダ１０にアクセスする場合に適用される。
図１２は、表示装置に表示されるサービスの検出結果の表示画面の構成例を示す図である。
図１２に示す例では、４つの仮想企業（ＡＡＡ、ＢＢＢ、ＣＣＣ、ＤＤＤ）が要介護判定のサービスを行っており、かつＵＤＤＩサイト２０に登録されていることを仮定し、「要介護判定」を検索パラメータとして検索を行った場合の検索結果が示されている。図示のように、この表示画面には、各企業のサービスに関して、サービス名、ＵＲＬ、企業名、平均サービス時間、一日の実行件数（Ｔｒｘ．／日）、サービスの利用が集中する時間帯（Ｔｒｘ．集中分布）、備考の各項目が一覧表示される。また、図示の例では、平均サービス時間の短いものから順に並べている。このように、サービス質情報における所定の項目の情報を基準として、昇順あるいは降順に検索結果の情報を並べることにより、ユーザがサービスを選択する際の便に供することができる。さらに、各サービスにおける備考欄には、プロバイダ１０自身が提供する情報（サービス利用に応じた特典や割引等）やサービスの質に関する評価（５段階評価等）を記載することができ、ユーザの判断材料とすることができる。
ユーザは、ウェブブラウザにより端末装置の表示装置に表示された図１２のような表示画面を参照して利用するサービスを決定し、マウス等の入力デバイスを操作して所望のサービスを選択する。ウェブブラウザは、この選択操作によるイベントを検出すると、選択されたサービスに対応するＵＲＬ（当該サービスを提供するプロバイダ１０のＵＲＬ）を宛先としてサービス要求を送信する。
なお、上述した実施の形態では、リクエスタ３０がＵＤＤＩサイト２０に対してサービス検索を行った際に、検索された登録情報に対応するサービス質情報を当該検索結果と共に返送することとしたが、サービス質情報の検索サービス自体を、ＵＤＤＩサイト２０が提供するウェブサービスとすることもできる。
すなわち、サービス質情報蓄積照会部２３及びＳＱＭ２４によるサービス質情報の検索サービスに関する情報を、ＷＳＤＬを用いてＵＤＤＩ２１に登録し、公開しておく。これにより、リクエスタ３０のサービス検索部３１からＵＤＤＩ２１が検索され、当該サービス質情報の検索サービスに関する情報が読み出されると、ＷＳＤＬの記述から検索サービスへの接続用のプロキシ（接続プログラム）が動的に生成され、サービス質情報の検索が可能となる。したがって、このような構成とした場合、リクエスタ３０のサービス検索部３１にＵＤＤＩサイト２０のサービス情報蓄積照会部２３へアクセスする機能を付与するクラス・ライブラリを提供する必要はない。
以上説明したように、本発明によれば、ウェブサービスの検索に際して、適切な選択基準を提供し、より優れたウェブサービスの利用の便に供することができる。
また、本発明によれば、上記の選択基準として、サービスの質に関する情報を提供することができる。
１０…プロバイダ（サービス提供者）、１１…サービス実行部、１２…サービス質情報採取部、１３…非同期送信制御部、２０…ＵＤＤＩサイト、２１…ＵＤＤＩ、２２…非同期受信制御部、２３…サービス質情報蓄積照会部、２４…ＳＱＭ（Ｓｅｒｖｉｃｅ Ｑｕａｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ）、３０…リクエスタ（サービス利用者）、３１…サービス検索部、３２…サービス要求部、１０１…ＣＰＵ、１０２…Ｍ／Ｂチップセット、１０３…メインメモリ、１０５…ハードディスク、１０６…ネットワークインターフェイス、１１０…キーボード／マウス

Claims (20)

1. ネットワークを介したソフトウェアサービスを提供するネットワークシステムであって、
   ソフトウェアサービスを提供する少なくとも１つのプロバイダであって、前記サービスの質を判断するための実績情報を採取するプロバイダと、
   前記プロバイダによって採取された実績情報を管理する管理サイトと、
   を備えるネットワークシステム。
2. 前記プロバイダは、前記サービスの質を判断するための実績情報として、サービスの利用回数、サービスの利用頻度、サービスの実行時間、サービスの休止時間、のうち少なくともいずれか１つを採取する請求項１に記載のネットワークシステム。
3. ネットワークを介したソフトウェアサービスを実現するネットワークシステムであって、
   少なくとも１つのプロバイダが提供するソフトウェアサービスの質を判断するための実績情報を管理する管理サイトと、
   前記プロバイダのうちの少なくとも１つにサービスを要求するリクエスタを備え、
   前記リクエスタは、前記管理サイトに対してソフトウェアサービスの検索を要求し、検索されたサービスの質を判断するための実績情報を含むサービスの検素結果に基いて供給されるサービスを決定する、
   ネットワークシステム。
4. ネットワークを介してソフトウェアサービスを提供するプロバイダにであって、
   少なくとも１つのソフトウェアサービスの処理を実行する手段と、
   前記実行する手段による処理の実行に基いて、前記ソフトウェアサービスの質を判断するための情報を採取する手段と、
   を備えるプロバイダ。
5. ネットワークを介したソフトウェアサービスの検索を行う管理サイトに前記ソフトウェアサービスの質を判断するための情報を伝送する手段をさらに含む請求項４に記載のプロバイダ。
6. 前記採取する手段は、前記サービスの質を判断するための情報として、当該サービスのための処理を実行することで得られる実績情報を採取する請求項４に記載のプロバイダ。
7. ネットワークを通じて提供されるソフトウェアサービスを検索する管理サイトであって、
   前記ソフトウェアサービスに関する情報を管理する第１の手段と、
   前記第１の手段によって情報を管理されるサービスの質を判断するための実績情報を管理する第２の手段と、
   を備える管理サイト。
8. 前記第１の手段は、リクエスタからネットワークを介して伝送されたサービスの検索要求に応じて、該当するサービスを検索し、
   前記第２の手段は、前記第１の手段にて検索されたサービスの質を判断するための情報を検索し、
   前記第１の手段により検索されたサービスおよび前記第２の手段により検索されたサービスの質を判断するための情報が、前記リクエスタに伝送される、
   請求項７に記載の管理サイト。
9. ソフトウェアサービスを提供するプロバイダから当該サービスの質を判断するための情報を取得する、請求項７に記載の管理サイト。
10. 前記第１の手段が、サービスの質を判断するための情報の検索のための前記第２の手段の機能を、ソフトウェアサービスの１つとして管理する請求項７に記載の管理サイト。
11. ネットワークを介して提供されるソフトウェアサービスの検索を行う管理サイトにサービスの検索要求を送信する手段と、
    サービスの質を判断するための情報を含むサービスの検索結果を、前記管理サイトから取得する手段と、
    取得された前記検索結果に基いて、少なくとも１つのソフトウェアサービスを選択する手段と、
    プロバイダに、選択されたサービスの実行要求を送信する手段と、
    を備えるリクエスタ。
12. ネットワークを介して提供されるソフトウェアサービスの検索を行う管理サイトにサービスの検索要求を送信する手段と、
    サービスの質を判断するための情報を含むサービスの検索結果を、前記管理サイトから取得する手段と、
    前記サービスの検索結果を、前記サービスの質を判断するための情報を反映させて表示装置に表示する手段と、
    を備えるリクエスタ。
13. ネットワークを介してソフトウェアサービスを提供するためのコンピュータ・プログラムであって、
    少なくとも１つのソフトウェアサービスの処理を実行する手段、
    前記実行する手段による処理の実行に基いて、前記ソフトウェアサービスの質を判断するための情報を採取する手段、
    としてコンピュータを機能させるコンピュータ・プログラム。
14. さらにコンピュータを、ネットワークを介したソフトウェアサービスの検索を行う管理サイトに前記ソフトウェアサービスの質を判断するための情報を伝送する手段として機能させる請求項１３に記載のコンピュータ・プログラム。
15. 前記採取する手段は、前記サービスの質を判断するための情報として、当該サービスのための処理を実行することで得られる実績情報を採取する請求項１３に記載のコンピュータ・プログラム。
16. ネットワークを通じて提供されるソフトウェアサービスを検索を行うためのコンピュータ・プログラムであって、
    前記ソフトウェアサービスに関する情報を管理する第１の手段と、
    前記第１の手段によって情報を管理されるサービスの質を判断するための実績情報を管理する第２の手段と、
    としてコンピュータを機能させるコンピュータ・プログラム。
17. 前記第１の手段は、リクエスタからネットワークを介して伝送されたサービスの検索要求に応じて、該当するサービスを検索し、
    前記第２の手段は、前記第１の手段にて検索されたサービスの質を判断するための情報を検索し、
    前記第１の手段により検索されたサービスおよび前記第２の手段により検索されたサービスの質を判断するための情報が、前記リクエスタに伝送される、
    請求項１６に記載のコンピュータ・プログラム。
18. ソフトウェアサービスを提供するプロバイダから当該サービスの質を判断するための情報を取得する、請求項１６に記載のコンピュータ・プログラム。
19. 前記第１の手段が、サービスの質を判断するための情報の検索のための前記第２の手段の機能を、ソフトウェアサービスの１つとして管理する請求項１６に記載のコンピュータ・プログラム。
20. ネットワークを介したソフトウェアサービスを実現するためのコンピュータ・プログラムであって、
    ネットワークを介して提供されるソフトウェアサービスの検索を行う管理サイトにサービスの検索要求を送信する手段と、
    サービスの質を判断するための情報を含むサービスの検索結果を、前記管理サイトから取得する手段と、
    取得された前記検索結果に基いて、少なくとも１つのソフトウェアサービスを選択する手段と、
    プロバイダに、選択されたサービスの実行要求を送信する手段と、
    としてコンピュータを機能させるコンピュータ・プログラム。

Images