(57)【要約】【課題】  ＵＤＤＩレジストリを利用したＷｅｂサービスの動的接続を可能とするシステムにおいて、各Ｗｅｂサービスの提供するサービス内容についての高度な検索処理を可能とするシステムを提供する。【解決手段】  Ｗｅｂサービス検索システム１００は、各業務システム１１０Ａ〜１１０Ｄから受信したクエリ文字列１２０，１３０を解析し、情報検索処理又は情報更新処理を行う。情報検索処理の場合には、クエリ文字列１２０に示される要件に基づき検索処理を行い、要件データベース１０１から検索結果を取得するとともに、当該検索結果に対応するアクセスポイント等の情報をＵＤＤＩレジストリ１０２から取得し、接続先情報１４０を生成して業務システム１１０Ａに送信する。情報更新処理の場合には、クエリ文字列１３０に示される情報に基づき、要件データベース１０１内のレコードを更新する。【選択図】      図１
2005148823.tif 000002
【特許請求の範囲】
【請求項１】
ＵＤＤＩレジストリにアクセス可能な検索処理手段を備えるＷｅｂサービス検索システムであって、
各Ｗｅｂサービスの種別に対応する検索要件を格納した要件テーブルと、当該要件テーブルの各レコードと前記ＵＤＤＩレジストリ内の情報を識別する識別情報との対応関係を定義した対応テーブルとを含む要件情報格納手段と、
Ｗｅｂサービス呼出し側の第一の業務システムからの検索要求を受付け、前記要件テーブルから検索条件に応じたレコードを取得するとともに、当該レコードに対応する前記識別情報を取得し、当該識別情報に基づき、前記ＵＤＤＩレジストリからＷｅｂサービスの提供側の第二の業務システムについてのアクセスポイントを取得して、前記要件情報格納手段及び前記ＵＤＤＩレジストリから取得した各情報に基づき接続先情報を生成して、前記第一の業務システムに送信するＷｅｂサービス検索処理手段と
を備えることを特徴とするＷｅｂサービス検索システム。
【請求項２】
前記Ｗｅｂサービス検索処理手段は、
クエリ文字列を受付け、前記クエリ文字列に示される検索要求又は更新要求に応じて、前記要件情報格納手段に対し各処理を実行するクエリ実行手段を有することを特徴とする請求項１に記載のＷｅｂサービス検索システム。
【請求項３】
前記要件テーブルに対応した要件項目を格納したファイルとして予め作成された要件ファイルから、任意に選択された要件項目を取得するとともに、取得した各要件項目に対し任意に指定された値又は範囲に基づき、前記クエリ文字列を生成するクエリ文字列生成手段を備えることを特徴とする請求項２に記載のＷｅｂサービス検索システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスの動的接続サービスを提供するシステムに好適なＷｅｂサービス検索システムに関する。
【背景技術】
【０００２】
近年、Ｗｅｂサービスを効果的に利用するために、Ｗｅｂサービスの登録・公開・検索を行うための仕組みとして、ＵＤＤＩ（Universal  Description,  Discovery,  and  Integration）レジストリを利用したシステムによる検索サービスの提供が行われている。
ここで、Ｗｅｂサービスとは、一般に、インターネットの標準技術を使ってネットワーク上に分散したアプリケーションを連携させる技術、または、当該技術によって連携させられるアプリケーションを示し（以下、本明細書では、アプリケーションを示すものとする。）、例えば、ＸＭＬ Ｗｅｂサービスと呼ばれている。Ｗｅｂサービスでは、ＸＭＬ（eXtensible  Markup  Language）技術を外部とのインタフェースとして採用することにより、人間を介すること無く、Ｗｅｂサービス同士のやり取りを可能としている。Ｗｅｂサービスの中核をなす技術としては、一般に、メッセージの送受信技術としてのＳＯＡＰ（Simple  Object  Access  Protocol），インタフェース記述言語としてのＷＳＤＬ（Web  Service  Description  Language），Ｗｅｂサービスの公開・発見のための技術であるＵＤＤＩが利用されている。
すなわち、Ｗｅｂサービス呼出し側の業務システムでは、ＵＤＤＩレジストリにより公開されたＷｅｂサービスの中から、必要なＷｅｂサービスを検索し、各Ｗｅｂサービスのインタフェースを記述したＷＳＤＬ文書のＵＲＬを取得する。この場合、取得したＵＲＬにアクセスすることにより、ＷＳＤＬ文書を取得することができ、当該ＷＳＤＬ文書に基づきＷｅｂサービスを呼出すモジュールのコードを自動生成することで、Ｗｅｂサービスの動的な接続が可能となる。この際、メッセージの送受信にＳＯＡＰを使用することにより、種々のプラットフォーム上で稼動するオブジェクト間連携が可能となっている。
Ｗｅｂサービスの検索の際に利用されるＵＤＤＩレジストリには、サービスを提供する当事者の情報を有するｂｕｓｉｎｅｓｓＥｎｔｉｔｙと、特定のサービスに関する情報を有するｂｕｓｉｎｅｓｓｓｅｒｖｉｃｅと、Ｗｅｂサービスに接続するための技術的な情報を有するｂｕｉｎｄｉｎｇＴｅｍｐｌａｔｅとが含まれている。以上の構成により、ＵＤＤＩレジストリを利用したＷｅｂサービス検索システムでは、各情報に基づく検索を行うとともに、Ｗｅｂサービスの接続先情報としてＷＳＤＬ文書を提供している。
従って、例えば、ある製品の受注，製造，配送といった一連の流れを、複数のＷｅｂサービスを連携させて実現しようとする場合に、ＵＤＤＩレジストリを利用した検索システムにより必要なＷｅｂサービスの接続先情報等を取得することができ、Ｗｅｂサービスの動的接続が可能となっている。
【０００３】
前記ＵＤＤＩレジストリを利用したシステムについては、従来、ＵＤＤＩレジストリ（中央レジストリ）に対し、ネットワークを介して接続されたＷｅｂサービスにおいて、サービス説明を生成してＵＤＤＩレジストリに登録する手段と、ＵＤＤＩレジストリから取得したサービス説明によりＷｅｂサービスへの動的接続を行う手段とを備えることにより、ＵＤＤＩレジストリへのサービス説明の自動登録等を可能とした構成が公知となっている（例えば、特許文献１参照。）。
【特許文献１】特開２００３−１３３０５３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、ＵＤＤＩレジストリを利用した場合、一般にｂｕｓｉｎｅｓｓＳｅｒｖｉｃｅの情報に基づいてＷｅｂサービスの検索処理を行うこととなるが、具体的には産業コード，製品／サービス，国コード等の指定が可能なだけであり、他の具体的な情報に基づく検索処理を行うことができなかった。
また、前記特許文献１に記載のシステムは、ＷｅｂサービスについてＵＤＤＩレジストリに登録される各種の情報の登録処理等を自動的に行う手段を設けているが、検索処理については従来と同様にｂｕｓｉｎｅｓｓＳｅｒｖｉｃｅ等の情報により行うものとなっていた。
この場合、例えば、ある電子部品の発注を受付けるＷｅｂサービスを検索する場合において、具体的な商品の在庫数，単価，納品日等に基づく検索処理や、各検索項目についての範囲を指定した検索処理等を行うことができなかった。
従って、詳細な情報に基づくＷｅｂサービスの検索が必要な場合には、ＵＤＤＩレジストリの情報のみでは対応できず、必ずしも適切なＷｅｂサービスの検索を行うことができないため、ＵＤＤＩレジストリの有効活用を図ることが出来ないという問題があった。
【０００５】
本発明は、前記課題を解決するためのものであり、ＵＤＤＩレジストリを利用したＷｅｂサービスの検索システムにおいて、各Ｗｅｂサービスの提供するサービス内容についての高度な検索処理による適切なＷｅｂサービスの検索を可能とするシステムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
前記課題を解決するため、本発明は、ＵＤＤＩレジストリにアクセス可能な検索処理手段を備えるＷｅｂサービス検索システムであって、各Ｗｅｂサービスの種別に対応する検索要件を格納した要件テーブルと、当該要件テーブルの各レコードと前記ＵＤＤＩレジストリ内の情報を識別する識別情報との対応関係を定義した対応テーブルとを含む要件情報格納手段と、Ｗｅｂサービス呼出し側の第一の業務システムからの検索要求を受付け、前記要件テーブルから検索条件に応じたレコードを取得するとともに、当該レコードに対応する前記識別情報を取得し、当該識別情報に基づき、前記ＵＤＤＩレジストリからＷｅｂサービス提供側の第二の業務システムについてのアクセスポイントを取得して、前記要件情報格納手段及び前記ＵＤＤＩレジストリから取得した各情報に基づき接続先情報を生成して、前記第一の業務システムに送信するＷｅｂサービス検索処理手段とを備えることを特徴とする。
また、前記Ｗｅｂサービス検索処理手段は、クエリ文字列を受付け、前記クエリ文字列に示される検索要求又は更新要求に応じて、前記要件情報格納手段に対し各処理を実行するクエリ実行手段を有することを特徴とする。
また、前記要件テーブルに対応した要件項目を格納したファイルとして予め作成された要件ファイルから、任意に選択された要件項目を取得するとともに、取得した各要件項目に対し任意に指定された値又は範囲に基づき、前記クエリ文字列を生成するクエリ文字列生成手段を備えることを特徴とする。
【発明の効果】
【０００７】
以上の構成により、本発明では、ＵＤＤＩレジストリを利用したＷｅｂサービス検索システムにおいて、要件情報格納手段に格納された種々の要件項目に基づき、Ｗｅｂサービスについての詳細な検索処理を行うことが可能となり、高度な検索処理結果に基づくＷｅｂサービスの動的な接続が可能となる。
また、クエリ実行手段により、クエリ文字列に基づき要件検索，情報更新の各処理を行うこととしたので、各処理手段を別々に設ける必要が無く、システムの実装と要件情報のメンテナンスが容易となる。
また、要件ファイルに格納された要件項目から、利用者により任意に選択された項目及び各項目に対して指定された値，範囲に基づきクエリ文字列を生成することとしたので、利用者に対し要件検索処理及び情報更新処理の利用を容易なものとすることができる。
【発明を実施するための最良の形態】
【０００８】
以下、本発明の一実施の形態について、図面に基づき説明する。図１は本発明の一実施の形態に係るＷｅｂサービス検索システムの概略構成を示すブロック図である。
本実施の形態に係るＷｅｂサービス検索システム１００は、複数の業務システム１１０Ａ〜１１０Ｄに対してネットワークを介して接続されている。
本例では、業務システム１１０ＡがＷｅｂサービス呼び出し側の業務システムを示し、業務システム１１０Ｂ〜１１０ＤがＷｅｂサービス提供側の業務システムを示している。各業務システム１１０Ｂ〜１１０Ｄは、ネットワーク上で分散したシステムであり、それぞれ異なる企業等が保持し、独自のＷｅｂサービスを有している。
Ｗｅｂサービス検索システム１００は、情報格納手段としての要件データベース１０１とＵＤＤＩレジストリ１０２とを備えている。
Ｗｅｂサービス検索システム１００と、各業務システム１１０Ａ〜１１０Ｄとの間では、クエリ文字列１２０，１３０により検索条件，更新情報等の送受信が行われる。また、Ｗｅｂサービスの呼び出しは、各業務システム１１０Ａ〜１１０Ｄ間で行われる。
Ｗｅｂサービス検索システム１００は、各業務システム１１０Ａ〜１１０Ｄから受信したクエリ文字列１２０，１３０を解析し、検索処理又は情報更新処理を行う。
検索処理の場合には、クエリ文字列１２０に示される要件に基づき検索処理を行い、要件データベース１０１から検索結果を取得するとともに、当該検索結果に対応するアクセスポイント等の情報をＵＤＤＩレジストリ１０２から取得し、接続先情報１４０を生成して業務システム１１０Ａに送信する。
情報更新処理の場合には、クエリ文字列１３０に示される情報に基づき、要件データベース１０１内のレコードを更新する。
業務システム１１０Ａは、取得した接続先情報１４０に基づきＷｅｂサービス呼出しを行うことにより、要件に適したＷｅｂサービスの動的な選択，接続が可能となる。
本実施の形態に係るＷｅｂサービス検索システム１００では、種々の要件を検索用データとして要件データベース１０１に格納しており、各業務システム１１０Ａ〜１１０Ｄにおいて利用者により任意に選択された要件項目についてＳＱＬ（Structured  Query  Language）文によるクエリ文字列を生成し、要件データベース１０１の検索処理，更新処理を可能としている。
【０００９】
図２は、本実施の形態に係るＷｅｂサービス検索システム１００の行う検索処理の概要を示すブロック図であり、図３は、Ｗｅｂサービス検索システム１００における要件データベース１０１に対する情報更新処理の概要を示すブロック図である。なお、図３では、情報更新処理に不要な構成の図示を省略している。
本実施の形態では、各処理を行うための構成として、図２，図３に示すように、各業務システム１１０Ａ〜１１０Ｄに、それぞれクエリ文字列生成部１１１Ａ〜１１１Ｄと接続先情報解析部１１２Ａとを備えるとともに、Ｗｅｂサービス検索システム１００にクエリ実行部１０３とＵＤＤＩレジストリ検索部１０４と接続先情報生成部１０５とを備える。
Ｗｅｂサービス検索システム１００の行う検索処理では、まず、Ｗｅｂサービス呼び出し側の業務システム１１０Ａのクエリ文字列生成部１１１Ａが要件ファイル２００を読込み、利用者の検索処理要求に応じて、要件検索要求を示すクエリ文字列１２０を生成する。この場合のクエリ文字列１２０は、例えば、ＳＥＬＥＣＴ構文で生成する。
クエリ実行部１０３は、クエリ文字列生成部１１１Ａの生成したクエリ文字列１２０を要件データベース１０１への問い合わせに変換し、要件データベース１０１への問い合わせを実施することにより検索処理を行い、検索結果を取得する。
ＵＤＤＩレジストリ検索部１０４は、クエリ実行部１０３から検索結果に含まれるｂｉｎｄｉｎｇｋｅｙを取得し、ＵＤＤＩレジストリ１０２を検索する。
接続先情報生成部１０５は、ＵＤＤＩレジストリ検索部１０４がＵＤＤＩレジストリ１０２から取得した情報等に基づき、Ｗｅｂサービスの呼出しに必要な接続先情報１４０を生成する。
接続先情報解析部１１２Ａは、接続先情報生成部１０５の生成した接続先情報１４０を受信し、当該接続先情報１４０に含まれるＷｅｂサービスへのアクセスポイント(ＵＲＬ)に基づき、Ｗｅｂサービスの呼出しを行う。
なお、検索要件を満たすＷｅｂサービスが複数あった場合には、接続先情報の配列が接続先情報解析部に送信される。この場合、接続先情報解析部１１２Ａでは、接続先情報の要件の結果を使用してアクセスポイントを選択して、またはアクセスポイントをさらに絞り込むために再度要件検索を実施することにより、最終的に１つのアクセスポイントを得るように処理する。
また、要件情報の更新処理では、Ｗｅｂサービス提供側の業務システム１１０Ｂ〜１１０Ｄのクエリ文字列生成部１１１Ｂ〜１１１Ｄが要件ファイル３００を読込み、利用者の更新処理要求に応じて、要件更新要求を示すクエリ文字列１３０を生成する。この場合のクエリ文字列１３０は、例えば、ＵＰＤＡＴＥ構文で生成する。
クエリ実行部１０３は、クエリ文字列生成部１１１Ｂ〜１１１Ｄの生成したクエリ文字列１３０を要件データベース１０１への更新に変換し、要件データベース１０１内の情報更新処理を行う。
【００１０】
ここで、本実施の形態に係る各システムの基盤となるソフトウェアは、アプリケーションサーバである。アプリケーションサーバは、好ましくは、Ｊａｖａアプリケーションサーバ（「Ｊａｖａ」は、米国サンマイクロシステムズ社の登録商標）であるが、本システムを実装するソフトウェアコンポーネントの開発基盤（プログラム開発言語およびフレームワーク）のサポート、文字列を送信可能とするネットワークプロトコルのサポートなどのＷｅｂサーバとしての機能に加えて、データベースに接続可能なフレームワークを提供していること、また、ＳＯＡＰ，ＷＳＤＬ，ＵＤＤＩのＷｅｂサービス技術を実装しているものであれば、これを制限しない。
また、アプリケーションサーバが動作するオペレーティングシステム、ハードウェアは、アプリケーションサーバの動作可能性に関してのみ制限される。また、クエリ実行部１０３、ＵＤＤＩレジストリ検索部１０４、接続先情報生成部１０５、クエリ文字列生成部１１１Ａ〜１１１Ｄ、接続先情報解釈部１１２Ａの１つの実装は、アプリケーションサーバに配置するソフトウェアコンポーネントであり、ネットワークプログラミングが容易なプログラム言語、フレームワークで実装し、好ましくは、ＥＪＢ（Enterprise  JavaBeans）により実装する。また、クエリ文字列と接続先情報を送信するプロトコルは、文字列を送信可能であればよいが、好ましくは、ＨＴＴＰ（HyperText  Transfer  Protocol）である。この場合の１つの実装は、クエリ文字列は、メディアタイプｔｅｘｔ／ｐｌａｉｎとし、ＨＴＴＰのボディ部に格納し送信する。また、接続先情報は、各パートにメディアタイプｔｅｘｔ／ｐｌａｉｎを設定したマルチパートとし、各々の接続先情報を各パートのボディ部に格納し送信する。また別の実装では、メディアタイプにｔｅｘｔ／ｘｍｌを使用する。この場合、クエリ文字列、接続先情報共にマークアップで構造化し、ＨＴＴＰのボディ部に格納して送信する。但し、本発明において、プロトコルは別の選択が可能である。前述おいて、文字列を送信可能であればよいため、例えば、ＲＭＩ（Remote  Method  Invocation）、ＪＭＳ（Java  Message  Service）、ＳＯＡＰ等のプロトコルを用いてよい。
【００１１】
図４，図５は、要件データベース１０１を構成する要件テーブル２００と、対応テーブル３００とを示す。
要件テーブル４００は、各Ｗｅｂサービスの提供する具体的なサービス情報を識別する要件ＩＤ４０１と、具体的なサービス情報を示す各項目とから構成されている。本例では、ＤＲＡＭ半導体の受注サービスに関するサービス情報を示す項目として、メーカ名４０２，容量４０３，電荷保持時間４０４，使用基盤４０５，在庫数４０６，納品日４０７，単価４０８，・・・の各データ項目を有する。
また、対応テーブル５００は、要件テーブル４００の要件ＩＤ４０１と、ＵＤＤＩレジストリ１０２を構成するｂｕｉｎｄｉｎｇＴｅｍｐｌａｔｅに含まれるｂｕｉｎｄｉｎｇｋｅｙとの対応関係を定義したものである。
なお、要件テーブル４００における新規レコードの追加は、信頼のおけるＷｅｂサービスのみを登録する必要から、Ｗｅｂサービス検索システム１００の管理者だけが行うものとし、要件テーブル４００に新規レコードを追加した場合には、当該レコードに対して付与された要件ＩＤを、新規レコードの登録要求を行った企業に通知する。また、要件ＩＤとｂｉｎｄｉｎｇＫｅｙの対応関係を、対応テーブル５００に登録する。
【００１２】
図６は、ＵＤＤＩレジストリ１０２のデータ構造の概略を示すブロック図である。
ＵＤＤＩレジストリ１０２は、ｂｕｓｉｎｅｓｓＥｎｔｉｔｙ６０１をルートとした木構造を形成しており、ＵＤＤＩレジストリ１０２の具体的な構造は、ＸＭＬの要素によって表現される。
ｂｕｓｉｎｅｓｓＥｎｔｉｔｙ６０１は、サービスを提供する当事者の情報、例えば企業名（個人名）、連絡先、地理、企業（個人）を特定するＩＤなどの情報を有し、ある企業が複数の異なるサービスを提供する場合には、複数のｂｕｓｉｎｅｓｓＳｅｒｖｉｃｅ６０２，・・・を有する。
ｂｕｓｉｎｅｓｓＳｅｒｖｉｃｅ６０２は、特定のサービスに関する業務情報、例えばサービス名、業種や製品の分別コードなどの情報を有し、特定のサービスが複数の技術的な方法を通して提供される場合には、複数のｂｉｎｄｉｎｇＴｅｍｐｌａｔｅ６０３，・・・を有する。
ｂｉｎｄｉｎｇＴｅｍｐｌａｔｅ６０３は、Ｗｅｂサービスに実際に接続するための技術的な情報、例えば接続先、接続プロトコル、接続のためのデータ形式などの情報を有する。但し、具体的な情報は、ｔＭｏｄｅｌ６０４に記述され、ｂｉｎｄｉｎｇＴｅｍｐｌａｔｅ６０３は、ｔＭｏｄｅｌ６０４に記述された情報を参照するようになっている。
ｔＭｏｄｅｌ６０４は、Ｗｅｂサービスのインターフェース別の情報であり、インターフェース情報をｂｉｎｄｉｎｇＴｅｍｐｌａｔｅ６３０と切り離すことにより、新たなインターフェースが必要であるときだけ新たなｔＭｏｄｅｌ６０４を追加するような管理が可能となる。ｔＭｏｄｅｌ６０４はサービスの型とも言われるもので、ｔＭｏｄｅｌ６０４が分かれば呼び出し側の業務システム１１０Ａはその型を使ってＷｅｂサービスの呼び出しをすることが可能となる。具体的には、ＷＳＤＬ文書のＵＲＬ等が記述されている。
本実施の形態では、接続先情報生成部の生成する接続先情報にｔＭｏｄｅｌ６０４の情報が含まれることとなる。
【００１３】
図７は、業務システム１１０Ａ〜１１０Ｄの行うクエリ文字列生成処理手順を示すフローチャートである。
クエリ文字列生成処理では、クエリ文字列生成部１１１Ａ〜１１１Ｄが、利用者により選択された要件ファイル２００，３００を開く（ステップ７０１）。当該要件ファイル２００，３００から、利用者により任意に指定された項目を取得し（ステップ７０２）、要件ファイル２００，３００を閉じる（ステップ７０３）。
利用者の処理要求が要件検索の場合（ステップ７０４）、要件ファイル２００から取得した各項目について利用者により任意に入力された値，範囲等に基づき、ＳＥＬＥＣＴ構文でクエリ文字列を生成する（ステップ７０５）。
一方、利用者の処理要求が要件登録の場合（ステップ７０４）、要件ファイル３００から取得した各項目について利用者により任意に入力された値等に基づき、ＵＰＤＡＴＥ構文でクエリ文字列を生成する（ステップ７０６）。
ステップ７０５又はステップ７０６により生成したクエリ文字列を、Ｗｅｂサービス検索システム１００に送信して（ステップ７０７）、処理を終了する。
【００１４】
図８は、Ｗｅｂサービス検索システム１００の行う各処理を示すフローチャートである。
Ｗｅｂサービス検索システム１００のクエリ実行部１０３は、業務システム１１０Ａ〜１１０Ｄから受信したクエリ文字列を取得し（ステップ８０１）、要件データベース１０１に対応するクエリ文字列に変換する（ステップ８０２）。
変換したクエリ文字列がＳＥＬＥＣＴ構文の場合には（ステップ８０３）、検索処理としてクエリを実行し、要件データベース１０１の要件テーブル４００から検索要件に合致するレコードのＩＤと、各要件項目の値とを取得する（ステップ８０４）。
要件データベース１０１に検索要件を満たすレコードがある場合（ステップ８０５）、当該レコードの要件ＩＤに基づき、対応テーブル５００からｂｉｎｄｉｎｇＫｅｙを取得する（ステップ８０６）。
ＵＤＤＩレジストリ検索部１０４は、クエリ実行部１０３の取得したｂｉｎｄｉｎｇＫｅｙに基づき、ＵＤＤＩレジストリ１０２のｔＭｏｄｅｌ６０４を参照して、Ｗｅｂサービスのアクセスポイントを含む各情報を取得する（ステップ８０７）。
接続先情報生成部１０５は、検索要件，クエリ実行部１０３とＵＤＤＩレジストリ検索部１０４とが取得した各レコードの値及びアクセスポイント等の情報に基づき接続先情報を生成する（ステップ８０８）。
ステップ８０６〜８０８の処理を、検索結果として要件データベース１０１から取得した全てのレコードについて行う（ステップ８０９）。
一方、検索処理の結果、要件データベース１０１に検索要件を満たすレコードが無い場合には（ステップ８０５）、接続先情報を空で生成する（ステップ８１０）。
生成した接続先情報をＷｅｂサービス呼び出し側の業務システム１１０Ａに送信して（ステップ８１１）、処理を終了する。
また、ステップ８０３において、変換した文字列がＵＰＤＡＴＥ構文の場合には、登録処理としてクエリを実行し、要件データベース１０１を更新して（ステップ８１２）、処理を終了する。
【００１５】
図９は、本実施の形態で用いられる要件ファイルと、当該要件ファイルに基づき、クエリ文字列生成部１１１Ａ〜１１１Ｄの生成する各クエリ文字列との例を示す図である。
図９に示すように、要件ファイル９００は、要件データベース１０１を構成するサービス種別毎の要件テーブル４００に対応するものであり、各要件テーブル４００における必須の要件項目として要件ＩＤ９０１とアクセスポイント９０２を有し、その他、サービス種別毎に異なる要件項目９０３を有する。本例では、ＤＲＡＭ半導体発注サービスに対応する要件項目９０３として、メーカ名，容量，単価，在庫数，納品日等の複数のデータ項目を有する。従って、要件ファイル９００を取得した業務システム１１０Ａでは、ＤＲＡＭ半導体受注サービスについて、ＩＤ，メーカ名，容量，電荷保持時間，使用基盤，在庫数，納品日，単価，・・・の各項目について検索要求が可能となり、具体的には、「在庫数が１０００以上のＤＲＡＭ半導体受注サービス」、「納品日が本日のＤＲＡＭ半導体受注サービス」等の検索が可能となる。
Ｗｅｂサービス呼び出し側の業務システム１１０Ａにおけるクエリ文字列生成部１１１Ａは、利用者による「要件検索」の選択及び要件項目の選択を受付けるとともに、各要件項目に対応する値，範囲の指定（検索条件の指定）を受付け、クエリ文字列９１０を生成する。ここで、クエリ文字列９１０は、要件検索に使用されるものであり、ＳＥＬＥＣＴ構文を用いて、「単価」が「１００」より安いＤＲＡＭ半導体の発注が可能なＷｅｂサービスを検索する条件を記述したものである。
また、Ｗｅｂサービス提供側の業務システム１１０Ｂ〜１１０Ｄにおけるクエリ文字列生成部１１１Ｂ〜１１１Ｄは、利用者による「更新登録」の選択及び要件項目の選択を受付けるとともに、各要件項目に対応する値の指定（更新内容の指定）を受付け、クエリ文字列９２０を生成する。ここで、クエリ文字列９２０は、要件テーブル４００の該当レコードの更新に使用されるものであり、ＵＰＤＡＴＥ構文を用いて、「単価」と「在庫数」についての更新内容を記述したものである。
従って、本実施の形態によれば、業務システム１１０Ａの利用者に対し、要件ファイル９００から任意の要件項目を選択させるとともに、選択された各要件項目について、任意の値，範囲を入力させることのみにより、Ｗｅｂサービスの詳細な検索及び動的な接続等が可能となる。同様に、業務システム１１０Ｂ〜１１０Ｄについては、要件データベース１０１の更新要求が可能となる。
なお、要件ファイル９００の配布は、Ｗｅｂサービス検索システムのＷｅｂページからの事前のダウンロードにより行う。また、他の方法として、要件ファイルの配布自体をＷｅｂサービス検索システムのＷｅｂサービスとして提供する形態（この場合はアクセスポイントを公開する）、オブジェクト言語による実装において、要件ファイル９００を適切なオブジェクトにカプセル化し、オブジェクト配布（ＪａｖａであればＪＮＤＩ（Java  Naming  and  Directory  Interface））で実施する形態等としてもよい。このように、要件ファイル９００は要件項目のみが記述された単純な構造のため、柔軟な方法をとることができる。
【００１６】
以上のように、本実施の形態に係るＷｅｂサービス検索システムでは、ＵＤＤＩレジストリを利用したＷｅｂサービスへの動的接続を行う際においても、詳細な検索条件に基づくＷｅｂサービスの検索が可能となる。
特に、クエリ文字列に基づき要件検索，情報更新を行うこととしたので、双方の処理手段を別々に設ける必要が無く、システムの実装とメンテナンスを容易なものとすることが可能となる。
また、要件データベース（要件テーブル）に含まれる要件項目に対応した要件ファイルを生成して、各業務システムに提供することとしたので、要件ファイルの利用により要件検索，情報更新等を容易に行わせることが可能となる。また、各Ｗｅｂサービスの種別に応じた要件項目を有する要件ファイルと要件データベース（要件テーブル）とを作成しておくことにより、種々のＷｅｂサービスの検索に容易に対応することが可能となる。
また、クエリ文字列は、ＳＱＬ構文という短い文字列で構成しているため、ネットワークに対する負荷を小さなものとすることができ、高いパフォーマンスを実現することが可能となる。特に、ネットワークとしてインターネットのような低速度のネットワークを介したＷｅｂサービスの動的接続に有利となる。
さらに、要件データベース及び要件ファイルを単純な構成としたため、保守管理等が容易となる。
【００１７】
なお、前記実施の形態では、Ｗｅｂサービス検索システム内にＵＤＤＩレジストリを含んだ構成を示しているが、これに限られるものでは無く、ＵＤＤＩレジストリを別構成としてもよい。
また、Ｗｅｂサービス呼出し側の業務システムとＷｅｂサービス提供側の業務システムとは必ずしも区別されるものでは無く、双方の機能を備えた業務システムとしてもよい。
また、各業務システム側にクエリ文字列生成部を備えることとしているが、Ｗｅｂサービス検索システム側にクエリ文字列生成部を備えることとしてもよい。
また、Ｗｅｂサービス検索システムにおいて、要件データベースに対応する要件ファイルを生成する手段と、各要件ファイルを格納するデータベース等を備えることとしてもよい。
また、要件データベースを構成する対応テーブルにおいては、要件ＩＤとｂｉｎｄｉｎｇＫｅｙとの対応関係を定義することとしているが、これに限られるものでは無く、ＵＤＤＩレジストリ内の他の情報との対応関係を定義することとしてもよい。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施の形態に係るＷｅｂサービス検索システムを含むネットワーク構成を示すブロック図である。
【図２】本発明の一実施の形態に係るＷｅｂサービス接続システムの概略構成を示すブロック図である。
【図３】本発明の一実施の形態に係るＷｅｂサービス接続システムの概略構成を示すブロック図である。
【図４】Ｗｅｂサービス接続システムに備えられる要件データベースを構成する要件テーブルのデータ構造の一例を示す図である。
【図５】Ｗｅｂサービス接続システムに備えられる要件データベースを構成する対応テーブルのデータ構造の一例を示す図である。
【図６】Ｗｅｂサービス接続システムに備えられるＵＤＤＩレジストリのデータ構造の一例を示す図である。
【図７】クエリ文字列生成処理部の行う文字列生成処理手順を示すフローチャートである。
【図８】Ｗｅｂサービス検索システムの行う各処理手順を示すフローチャートである。
【図９】要件ファイルと要件ファイルに基づき生成されたクエリ文字列の一例をしめす図である。
【符号の説明】
【００１９】
１００  Ｗｅｂサービス検索システム、１０１  要件データベース、１０２  ＵＤＤＩレジストリ、１０３  クエリ実行部、１０４  ＵＤＤＩレジストリ検索部、１０５  接続先情報生成部、１１０Ａ〜１１０Ｄ  業務システム、１１１Ａ〜１１１Ｄ  クエリ文字列生成部、１１２Ａ  接続先情報解釈部、１２０，１３０  クエリ文字列、１４０  接続先情報。
【図１】
2005148823.tif 000003
【図２】
2005148823.tif 000004
【図３】
2005148823.tif 000005
【図４】
2005148823.tif 000006
【図５】
2005148823.tif 000007
【図６】
2005148823.tif 000008
【図７】
2005148823.tif 000009
【図８】
2005148823.tif 000010
【図９】
2005148823.tif 000011