JP2005148823A - Webサービス検索システム - Google Patents
Webサービス検索システム Download PDFInfo
- Publication number
- JP2005148823A JP2005148823A JP2003381286A JP2003381286A JP2005148823A JP 2005148823 A JP2005148823 A JP 2005148823A JP 2003381286 A JP2003381286 A JP 2003381286A JP 2003381286 A JP2003381286 A JP 2003381286A JP 2005148823 A JP2005148823 A JP 2005148823A
- Authority
- JP
- Japan
- Prior art keywords
- requirement
- web service
- search
- information
- character string
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】 UDDIレジストリを利用したWebサービスの動的接続を可能とするシステムにおいて、各Webサービスの提供するサービス内容についての高度な検索処理を可能とするシステムを提供する。
【解決手段】 Webサービス検索システム100は、各業務システム110A〜110Dから受信したクエリ文字列120,130を解析し、情報検索処理又は情報更新処理を行う。情報検索処理の場合には、クエリ文字列120に示される要件に基づき検索処理を行い、要件データベース101から検索結果を取得するとともに、当該検索結果に対応するアクセスポイント等の情報をUDDIレジストリ102から取得し、接続先情報140を生成して業務システム110Aに送信する。情報更新処理の場合には、クエリ文字列130に示される情報に基づき、要件データベース101内のレコードを更新する。
【選択図】 図1
【解決手段】 Webサービス検索システム100は、各業務システム110A〜110Dから受信したクエリ文字列120,130を解析し、情報検索処理又は情報更新処理を行う。情報検索処理の場合には、クエリ文字列120に示される要件に基づき検索処理を行い、要件データベース101から検索結果を取得するとともに、当該検索結果に対応するアクセスポイント等の情報をUDDIレジストリ102から取得し、接続先情報140を生成して業務システム110Aに送信する。情報更新処理の場合には、クエリ文字列130に示される情報に基づき、要件データベース101内のレコードを更新する。
【選択図】 図1
Description
本発明は、Webサービスの動的接続サービスを提供するシステムに好適なWebサービス検索システムに関する。
近年、Webサービスを効果的に利用するために、Webサービスの登録・公開・検索を行うための仕組みとして、UDDI(Universal Description, Discovery, and Integration)レジストリを利用したシステムによる検索サービスの提供が行われている。
ここで、Webサービスとは、一般に、インターネットの標準技術を使ってネットワーク上に分散したアプリケーションを連携させる技術、または、当該技術によって連携させられるアプリケーションを示し(以下、本明細書では、アプリケーションを示すものとする。)、例えば、XML Webサービスと呼ばれている。Webサービスでは、XML(eXtensible Markup Language)技術を外部とのインタフェースとして採用することにより、人間を介すること無く、Webサービス同士のやり取りを可能としている。Webサービスの中核をなす技術としては、一般に、メッセージの送受信技術としてのSOAP(Simple Object Access Protocol),インタフェース記述言語としてのWSDL(Web Service Description Language),Webサービスの公開・発見のための技術であるUDDIが利用されている。
すなわち、Webサービス呼出し側の業務システムでは、UDDIレジストリにより公開されたWebサービスの中から、必要なWebサービスを検索し、各Webサービスのインタフェースを記述したWSDL文書のURLを取得する。この場合、取得したURLにアクセスすることにより、WSDL文書を取得することができ、当該WSDL文書に基づきWebサービスを呼出すモジュールのコードを自動生成することで、Webサービスの動的な接続が可能となる。この際、メッセージの送受信にSOAPを使用することにより、種々のプラットフォーム上で稼動するオブジェクト間連携が可能となっている。
Webサービスの検索の際に利用されるUDDIレジストリには、サービスを提供する当事者の情報を有するbusinessEntityと、特定のサービスに関する情報を有するbusinessserviceと、Webサービスに接続するための技術的な情報を有するbuindingTemplateとが含まれている。以上の構成により、UDDIレジストリを利用したWebサービス検索システムでは、各情報に基づく検索を行うとともに、Webサービスの接続先情報としてWSDL文書を提供している。
従って、例えば、ある製品の受注,製造,配送といった一連の流れを、複数のWebサービスを連携させて実現しようとする場合に、UDDIレジストリを利用した検索システムにより必要なWebサービスの接続先情報等を取得することができ、Webサービスの動的接続が可能となっている。
ここで、Webサービスとは、一般に、インターネットの標準技術を使ってネットワーク上に分散したアプリケーションを連携させる技術、または、当該技術によって連携させられるアプリケーションを示し(以下、本明細書では、アプリケーションを示すものとする。)、例えば、XML Webサービスと呼ばれている。Webサービスでは、XML(eXtensible Markup Language)技術を外部とのインタフェースとして採用することにより、人間を介すること無く、Webサービス同士のやり取りを可能としている。Webサービスの中核をなす技術としては、一般に、メッセージの送受信技術としてのSOAP(Simple Object Access Protocol),インタフェース記述言語としてのWSDL(Web Service Description Language),Webサービスの公開・発見のための技術であるUDDIが利用されている。
すなわち、Webサービス呼出し側の業務システムでは、UDDIレジストリにより公開されたWebサービスの中から、必要なWebサービスを検索し、各Webサービスのインタフェースを記述したWSDL文書のURLを取得する。この場合、取得したURLにアクセスすることにより、WSDL文書を取得することができ、当該WSDL文書に基づきWebサービスを呼出すモジュールのコードを自動生成することで、Webサービスの動的な接続が可能となる。この際、メッセージの送受信にSOAPを使用することにより、種々のプラットフォーム上で稼動するオブジェクト間連携が可能となっている。
Webサービスの検索の際に利用されるUDDIレジストリには、サービスを提供する当事者の情報を有するbusinessEntityと、特定のサービスに関する情報を有するbusinessserviceと、Webサービスに接続するための技術的な情報を有するbuindingTemplateとが含まれている。以上の構成により、UDDIレジストリを利用したWebサービス検索システムでは、各情報に基づく検索を行うとともに、Webサービスの接続先情報としてWSDL文書を提供している。
従って、例えば、ある製品の受注,製造,配送といった一連の流れを、複数のWebサービスを連携させて実現しようとする場合に、UDDIレジストリを利用した検索システムにより必要なWebサービスの接続先情報等を取得することができ、Webサービスの動的接続が可能となっている。
前記UDDIレジストリを利用したシステムについては、従来、UDDIレジストリ(中央レジストリ)に対し、ネットワークを介して接続されたWebサービスにおいて、サービス説明を生成してUDDIレジストリに登録する手段と、UDDIレジストリから取得したサービス説明によりWebサービスへの動的接続を行う手段とを備えることにより、UDDIレジストリへのサービス説明の自動登録等を可能とした構成が公知となっている(例えば、特許文献1参照。)。
特開2003−133053号公報
しかし、UDDIレジストリを利用した場合、一般にbusinessServiceの情報に基づいてWebサービスの検索処理を行うこととなるが、具体的には産業コード,製品/サービス,国コード等の指定が可能なだけであり、他の具体的な情報に基づく検索処理を行うことができなかった。
また、前記特許文献1に記載のシステムは、WebサービスについてUDDIレジストリに登録される各種の情報の登録処理等を自動的に行う手段を設けているが、検索処理については従来と同様にbusinessService等の情報により行うものとなっていた。
この場合、例えば、ある電子部品の発注を受付けるWebサービスを検索する場合において、具体的な商品の在庫数,単価,納品日等に基づく検索処理や、各検索項目についての範囲を指定した検索処理等を行うことができなかった。
従って、詳細な情報に基づくWebサービスの検索が必要な場合には、UDDIレジストリの情報のみでは対応できず、必ずしも適切なWebサービスの検索を行うことができないため、UDDIレジストリの有効活用を図ることが出来ないという問題があった。
また、前記特許文献1に記載のシステムは、WebサービスについてUDDIレジストリに登録される各種の情報の登録処理等を自動的に行う手段を設けているが、検索処理については従来と同様にbusinessService等の情報により行うものとなっていた。
この場合、例えば、ある電子部品の発注を受付けるWebサービスを検索する場合において、具体的な商品の在庫数,単価,納品日等に基づく検索処理や、各検索項目についての範囲を指定した検索処理等を行うことができなかった。
従って、詳細な情報に基づくWebサービスの検索が必要な場合には、UDDIレジストリの情報のみでは対応できず、必ずしも適切なWebサービスの検索を行うことができないため、UDDIレジストリの有効活用を図ることが出来ないという問題があった。
本発明は、前記課題を解決するためのものであり、UDDIレジストリを利用したWebサービスの検索システムにおいて、各Webサービスの提供するサービス内容についての高度な検索処理による適切なWebサービスの検索を可能とするシステムを提供することを目的とする。
前記課題を解決するため、本発明は、UDDIレジストリにアクセス可能な検索処理手段を備えるWebサービス検索システムであって、各Webサービスの種別に対応する検索要件を格納した要件テーブルと、当該要件テーブルの各レコードと前記UDDIレジストリ内の情報を識別する識別情報との対応関係を定義した対応テーブルとを含む要件情報格納手段と、Webサービス呼出し側の第一の業務システムからの検索要求を受付け、前記要件テーブルから検索条件に応じたレコードを取得するとともに、当該レコードに対応する前記識別情報を取得し、当該識別情報に基づき、前記UDDIレジストリからWebサービス提供側の第二の業務システムについてのアクセスポイントを取得して、前記要件情報格納手段及び前記UDDIレジストリから取得した各情報に基づき接続先情報を生成して、前記第一の業務システムに送信するWebサービス検索処理手段とを備えることを特徴とする。
また、前記Webサービス検索処理手段は、クエリ文字列を受付け、前記クエリ文字列に示される検索要求又は更新要求に応じて、前記要件情報格納手段に対し各処理を実行するクエリ実行手段を有することを特徴とする。
また、前記要件テーブルに対応した要件項目を格納したファイルとして予め作成された要件ファイルから、任意に選択された要件項目を取得するとともに、取得した各要件項目に対し任意に指定された値又は範囲に基づき、前記クエリ文字列を生成するクエリ文字列生成手段を備えることを特徴とする。
また、前記Webサービス検索処理手段は、クエリ文字列を受付け、前記クエリ文字列に示される検索要求又は更新要求に応じて、前記要件情報格納手段に対し各処理を実行するクエリ実行手段を有することを特徴とする。
また、前記要件テーブルに対応した要件項目を格納したファイルとして予め作成された要件ファイルから、任意に選択された要件項目を取得するとともに、取得した各要件項目に対し任意に指定された値又は範囲に基づき、前記クエリ文字列を生成するクエリ文字列生成手段を備えることを特徴とする。
以上の構成により、本発明では、UDDIレジストリを利用したWebサービス検索システムにおいて、要件情報格納手段に格納された種々の要件項目に基づき、Webサービスについての詳細な検索処理を行うことが可能となり、高度な検索処理結果に基づくWebサービスの動的な接続が可能となる。
また、クエリ実行手段により、クエリ文字列に基づき要件検索,情報更新の各処理を行うこととしたので、各処理手段を別々に設ける必要が無く、システムの実装と要件情報のメンテナンスが容易となる。
また、要件ファイルに格納された要件項目から、利用者により任意に選択された項目及び各項目に対して指定された値,範囲に基づきクエリ文字列を生成することとしたので、利用者に対し要件検索処理及び情報更新処理の利用を容易なものとすることができる。
また、クエリ実行手段により、クエリ文字列に基づき要件検索,情報更新の各処理を行うこととしたので、各処理手段を別々に設ける必要が無く、システムの実装と要件情報のメンテナンスが容易となる。
また、要件ファイルに格納された要件項目から、利用者により任意に選択された項目及び各項目に対して指定された値,範囲に基づきクエリ文字列を生成することとしたので、利用者に対し要件検索処理及び情報更新処理の利用を容易なものとすることができる。
以下、本発明の一実施の形態について、図面に基づき説明する。図1は本発明の一実施の形態に係るWebサービス検索システムの概略構成を示すブロック図である。
本実施の形態に係るWebサービス検索システム100は、複数の業務システム110A〜110Dに対してネットワークを介して接続されている。
本例では、業務システム110AがWebサービス呼び出し側の業務システムを示し、業務システム110B〜110DがWebサービス提供側の業務システムを示している。各業務システム110B〜110Dは、ネットワーク上で分散したシステムであり、それぞれ異なる企業等が保持し、独自のWebサービスを有している。
Webサービス検索システム100は、情報格納手段としての要件データベース101とUDDIレジストリ102とを備えている。
Webサービス検索システム100と、各業務システム110A〜110Dとの間では、クエリ文字列120,130により検索条件,更新情報等の送受信が行われる。また、Webサービスの呼び出しは、各業務システム110A〜110D間で行われる。
Webサービス検索システム100は、各業務システム110A〜110Dから受信したクエリ文字列120,130を解析し、検索処理又は情報更新処理を行う。
検索処理の場合には、クエリ文字列120に示される要件に基づき検索処理を行い、要件データベース101から検索結果を取得するとともに、当該検索結果に対応するアクセスポイント等の情報をUDDIレジストリ102から取得し、接続先情報140を生成して業務システム110Aに送信する。
情報更新処理の場合には、クエリ文字列130に示される情報に基づき、要件データベース101内のレコードを更新する。
業務システム110Aは、取得した接続先情報140に基づきWebサービス呼出しを行うことにより、要件に適したWebサービスの動的な選択,接続が可能となる。
本実施の形態に係るWebサービス検索システム100では、種々の要件を検索用データとして要件データベース101に格納しており、各業務システム110A〜110Dにおいて利用者により任意に選択された要件項目についてSQL(Structured Query Language)文によるクエリ文字列を生成し、要件データベース101の検索処理,更新処理を可能としている。
本実施の形態に係るWebサービス検索システム100は、複数の業務システム110A〜110Dに対してネットワークを介して接続されている。
本例では、業務システム110AがWebサービス呼び出し側の業務システムを示し、業務システム110B〜110DがWebサービス提供側の業務システムを示している。各業務システム110B〜110Dは、ネットワーク上で分散したシステムであり、それぞれ異なる企業等が保持し、独自のWebサービスを有している。
Webサービス検索システム100は、情報格納手段としての要件データベース101とUDDIレジストリ102とを備えている。
Webサービス検索システム100と、各業務システム110A〜110Dとの間では、クエリ文字列120,130により検索条件,更新情報等の送受信が行われる。また、Webサービスの呼び出しは、各業務システム110A〜110D間で行われる。
Webサービス検索システム100は、各業務システム110A〜110Dから受信したクエリ文字列120,130を解析し、検索処理又は情報更新処理を行う。
検索処理の場合には、クエリ文字列120に示される要件に基づき検索処理を行い、要件データベース101から検索結果を取得するとともに、当該検索結果に対応するアクセスポイント等の情報をUDDIレジストリ102から取得し、接続先情報140を生成して業務システム110Aに送信する。
情報更新処理の場合には、クエリ文字列130に示される情報に基づき、要件データベース101内のレコードを更新する。
業務システム110Aは、取得した接続先情報140に基づきWebサービス呼出しを行うことにより、要件に適したWebサービスの動的な選択,接続が可能となる。
本実施の形態に係るWebサービス検索システム100では、種々の要件を検索用データとして要件データベース101に格納しており、各業務システム110A〜110Dにおいて利用者により任意に選択された要件項目についてSQL(Structured Query Language)文によるクエリ文字列を生成し、要件データベース101の検索処理,更新処理を可能としている。
図2は、本実施の形態に係るWebサービス検索システム100の行う検索処理の概要を示すブロック図であり、図3は、Webサービス検索システム100における要件データベース101に対する情報更新処理の概要を示すブロック図である。なお、図3では、情報更新処理に不要な構成の図示を省略している。
本実施の形態では、各処理を行うための構成として、図2,図3に示すように、各業務システム110A〜110Dに、それぞれクエリ文字列生成部111A〜111Dと接続先情報解析部112Aとを備えるとともに、Webサービス検索システム100にクエリ実行部103とUDDIレジストリ検索部104と接続先情報生成部105とを備える。
Webサービス検索システム100の行う検索処理では、まず、Webサービス呼び出し側の業務システム110Aのクエリ文字列生成部111Aが要件ファイル200を読込み、利用者の検索処理要求に応じて、要件検索要求を示すクエリ文字列120を生成する。この場合のクエリ文字列120は、例えば、SELECT構文で生成する。
クエリ実行部103は、クエリ文字列生成部111Aの生成したクエリ文字列120を要件データベース101への問い合わせに変換し、要件データベース101への問い合わせを実施することにより検索処理を行い、検索結果を取得する。
UDDIレジストリ検索部104は、クエリ実行部103から検索結果に含まれるbindingkeyを取得し、UDDIレジストリ102を検索する。
接続先情報生成部105は、UDDIレジストリ検索部104がUDDIレジストリ102から取得した情報等に基づき、Webサービスの呼出しに必要な接続先情報140を生成する。
接続先情報解析部112Aは、接続先情報生成部105の生成した接続先情報140を受信し、当該接続先情報140に含まれるWebサービスへのアクセスポイント(URL)に基づき、Webサービスの呼出しを行う。
なお、検索要件を満たすWebサービスが複数あった場合には、接続先情報の配列が接続先情報解析部に送信される。この場合、接続先情報解析部112Aでは、接続先情報の要件の結果を使用してアクセスポイントを選択して、またはアクセスポイントをさらに絞り込むために再度要件検索を実施することにより、最終的に1つのアクセスポイントを得るように処理する。
また、要件情報の更新処理では、Webサービス提供側の業務システム110B〜110Dのクエリ文字列生成部111B〜111Dが要件ファイル300を読込み、利用者の更新処理要求に応じて、要件更新要求を示すクエリ文字列130を生成する。この場合のクエリ文字列130は、例えば、UPDATE構文で生成する。
クエリ実行部103は、クエリ文字列生成部111B〜111Dの生成したクエリ文字列130を要件データベース101への更新に変換し、要件データベース101内の情報更新処理を行う。
本実施の形態では、各処理を行うための構成として、図2,図3に示すように、各業務システム110A〜110Dに、それぞれクエリ文字列生成部111A〜111Dと接続先情報解析部112Aとを備えるとともに、Webサービス検索システム100にクエリ実行部103とUDDIレジストリ検索部104と接続先情報生成部105とを備える。
Webサービス検索システム100の行う検索処理では、まず、Webサービス呼び出し側の業務システム110Aのクエリ文字列生成部111Aが要件ファイル200を読込み、利用者の検索処理要求に応じて、要件検索要求を示すクエリ文字列120を生成する。この場合のクエリ文字列120は、例えば、SELECT構文で生成する。
クエリ実行部103は、クエリ文字列生成部111Aの生成したクエリ文字列120を要件データベース101への問い合わせに変換し、要件データベース101への問い合わせを実施することにより検索処理を行い、検索結果を取得する。
UDDIレジストリ検索部104は、クエリ実行部103から検索結果に含まれるbindingkeyを取得し、UDDIレジストリ102を検索する。
接続先情報生成部105は、UDDIレジストリ検索部104がUDDIレジストリ102から取得した情報等に基づき、Webサービスの呼出しに必要な接続先情報140を生成する。
接続先情報解析部112Aは、接続先情報生成部105の生成した接続先情報140を受信し、当該接続先情報140に含まれるWebサービスへのアクセスポイント(URL)に基づき、Webサービスの呼出しを行う。
なお、検索要件を満たすWebサービスが複数あった場合には、接続先情報の配列が接続先情報解析部に送信される。この場合、接続先情報解析部112Aでは、接続先情報の要件の結果を使用してアクセスポイントを選択して、またはアクセスポイントをさらに絞り込むために再度要件検索を実施することにより、最終的に1つのアクセスポイントを得るように処理する。
また、要件情報の更新処理では、Webサービス提供側の業務システム110B〜110Dのクエリ文字列生成部111B〜111Dが要件ファイル300を読込み、利用者の更新処理要求に応じて、要件更新要求を示すクエリ文字列130を生成する。この場合のクエリ文字列130は、例えば、UPDATE構文で生成する。
クエリ実行部103は、クエリ文字列生成部111B〜111Dの生成したクエリ文字列130を要件データベース101への更新に変換し、要件データベース101内の情報更新処理を行う。
ここで、本実施の形態に係る各システムの基盤となるソフトウェアは、アプリケーションサーバである。アプリケーションサーバは、好ましくは、Javaアプリケーションサーバ(「Java」は、米国サンマイクロシステムズ社の登録商標)であるが、本システムを実装するソフトウェアコンポーネントの開発基盤(プログラム開発言語およびフレームワーク)のサポート、文字列を送信可能とするネットワークプロトコルのサポートなどのWebサーバとしての機能に加えて、データベースに接続可能なフレームワークを提供していること、また、SOAP,WSDL,UDDIのWebサービス技術を実装しているものであれば、これを制限しない。
また、アプリケーションサーバが動作するオペレーティングシステム、ハードウェアは、アプリケーションサーバの動作可能性に関してのみ制限される。また、クエリ実行部103、UDDIレジストリ検索部104、接続先情報生成部105、クエリ文字列生成部111A〜111D、接続先情報解釈部112Aの1つの実装は、アプリケーションサーバに配置するソフトウェアコンポーネントであり、ネットワークプログラミングが容易なプログラム言語、フレームワークで実装し、好ましくは、EJB(Enterprise JavaBeans)により実装する。また、クエリ文字列と接続先情報を送信するプロトコルは、文字列を送信可能であればよいが、好ましくは、HTTP(HyperText Transfer Protocol)である。この場合の1つの実装は、クエリ文字列は、メディアタイプtext/plainとし、HTTPのボディ部に格納し送信する。また、接続先情報は、各パートにメディアタイプtext/plainを設定したマルチパートとし、各々の接続先情報を各パートのボディ部に格納し送信する。また別の実装では、メディアタイプにtext/xmlを使用する。この場合、クエリ文字列、接続先情報共にマークアップで構造化し、HTTPのボディ部に格納して送信する。但し、本発明において、プロトコルは別の選択が可能である。前述おいて、文字列を送信可能であればよいため、例えば、RMI(Remote Method Invocation)、JMS(Java Message Service)、SOAP等のプロトコルを用いてよい。
また、アプリケーションサーバが動作するオペレーティングシステム、ハードウェアは、アプリケーションサーバの動作可能性に関してのみ制限される。また、クエリ実行部103、UDDIレジストリ検索部104、接続先情報生成部105、クエリ文字列生成部111A〜111D、接続先情報解釈部112Aの1つの実装は、アプリケーションサーバに配置するソフトウェアコンポーネントであり、ネットワークプログラミングが容易なプログラム言語、フレームワークで実装し、好ましくは、EJB(Enterprise JavaBeans)により実装する。また、クエリ文字列と接続先情報を送信するプロトコルは、文字列を送信可能であればよいが、好ましくは、HTTP(HyperText Transfer Protocol)である。この場合の1つの実装は、クエリ文字列は、メディアタイプtext/plainとし、HTTPのボディ部に格納し送信する。また、接続先情報は、各パートにメディアタイプtext/plainを設定したマルチパートとし、各々の接続先情報を各パートのボディ部に格納し送信する。また別の実装では、メディアタイプにtext/xmlを使用する。この場合、クエリ文字列、接続先情報共にマークアップで構造化し、HTTPのボディ部に格納して送信する。但し、本発明において、プロトコルは別の選択が可能である。前述おいて、文字列を送信可能であればよいため、例えば、RMI(Remote Method Invocation)、JMS(Java Message Service)、SOAP等のプロトコルを用いてよい。
図4,図5は、要件データベース101を構成する要件テーブル200と、対応テーブル300とを示す。
要件テーブル400は、各Webサービスの提供する具体的なサービス情報を識別する要件ID401と、具体的なサービス情報を示す各項目とから構成されている。本例では、DRAM半導体の受注サービスに関するサービス情報を示す項目として、メーカ名402,容量403,電荷保持時間404,使用基盤405,在庫数406,納品日407,単価408,・・・の各データ項目を有する。
また、対応テーブル500は、要件テーブル400の要件ID401と、UDDIレジストリ102を構成するbuindingTemplateに含まれるbuindingkeyとの対応関係を定義したものである。
なお、要件テーブル400における新規レコードの追加は、信頼のおけるWebサービスのみを登録する必要から、Webサービス検索システム100の管理者だけが行うものとし、要件テーブル400に新規レコードを追加した場合には、当該レコードに対して付与された要件IDを、新規レコードの登録要求を行った企業に通知する。また、要件IDとbindingKeyの対応関係を、対応テーブル500に登録する。
要件テーブル400は、各Webサービスの提供する具体的なサービス情報を識別する要件ID401と、具体的なサービス情報を示す各項目とから構成されている。本例では、DRAM半導体の受注サービスに関するサービス情報を示す項目として、メーカ名402,容量403,電荷保持時間404,使用基盤405,在庫数406,納品日407,単価408,・・・の各データ項目を有する。
また、対応テーブル500は、要件テーブル400の要件ID401と、UDDIレジストリ102を構成するbuindingTemplateに含まれるbuindingkeyとの対応関係を定義したものである。
なお、要件テーブル400における新規レコードの追加は、信頼のおけるWebサービスのみを登録する必要から、Webサービス検索システム100の管理者だけが行うものとし、要件テーブル400に新規レコードを追加した場合には、当該レコードに対して付与された要件IDを、新規レコードの登録要求を行った企業に通知する。また、要件IDとbindingKeyの対応関係を、対応テーブル500に登録する。
図6は、UDDIレジストリ102のデータ構造の概略を示すブロック図である。
UDDIレジストリ102は、businessEntity601をルートとした木構造を形成しており、UDDIレジストリ102の具体的な構造は、XMLの要素によって表現される。
businessEntity601は、サービスを提供する当事者の情報、例えば企業名(個人名)、連絡先、地理、企業(個人)を特定するIDなどの情報を有し、ある企業が複数の異なるサービスを提供する場合には、複数のbusinessService602,・・・を有する。
businessService602は、特定のサービスに関する業務情報、例えばサービス名、業種や製品の分別コードなどの情報を有し、特定のサービスが複数の技術的な方法を通して提供される場合には、複数のbindingTemplate603,・・・を有する。
bindingTemplate603は、Webサービスに実際に接続するための技術的な情報、例えば接続先、接続プロトコル、接続のためのデータ形式などの情報を有する。但し、具体的な情報は、tModel604に記述され、bindingTemplate603は、tModel604に記述された情報を参照するようになっている。
tModel604は、Webサービスのインターフェース別の情報であり、インターフェース情報をbindingTemplate630と切り離すことにより、新たなインターフェースが必要であるときだけ新たなtModel604を追加するような管理が可能となる。tModel604はサービスの型とも言われるもので、tModel604が分かれば呼び出し側の業務システム110Aはその型を使ってWebサービスの呼び出しをすることが可能となる。具体的には、WSDL文書のURL等が記述されている。
本実施の形態では、接続先情報生成部の生成する接続先情報にtModel604の情報が含まれることとなる。
UDDIレジストリ102は、businessEntity601をルートとした木構造を形成しており、UDDIレジストリ102の具体的な構造は、XMLの要素によって表現される。
businessEntity601は、サービスを提供する当事者の情報、例えば企業名(個人名)、連絡先、地理、企業(個人)を特定するIDなどの情報を有し、ある企業が複数の異なるサービスを提供する場合には、複数のbusinessService602,・・・を有する。
businessService602は、特定のサービスに関する業務情報、例えばサービス名、業種や製品の分別コードなどの情報を有し、特定のサービスが複数の技術的な方法を通して提供される場合には、複数のbindingTemplate603,・・・を有する。
bindingTemplate603は、Webサービスに実際に接続するための技術的な情報、例えば接続先、接続プロトコル、接続のためのデータ形式などの情報を有する。但し、具体的な情報は、tModel604に記述され、bindingTemplate603は、tModel604に記述された情報を参照するようになっている。
tModel604は、Webサービスのインターフェース別の情報であり、インターフェース情報をbindingTemplate630と切り離すことにより、新たなインターフェースが必要であるときだけ新たなtModel604を追加するような管理が可能となる。tModel604はサービスの型とも言われるもので、tModel604が分かれば呼び出し側の業務システム110Aはその型を使ってWebサービスの呼び出しをすることが可能となる。具体的には、WSDL文書のURL等が記述されている。
本実施の形態では、接続先情報生成部の生成する接続先情報にtModel604の情報が含まれることとなる。
図7は、業務システム110A〜110Dの行うクエリ文字列生成処理手順を示すフローチャートである。
クエリ文字列生成処理では、クエリ文字列生成部111A〜111Dが、利用者により選択された要件ファイル200,300を開く(ステップ701)。当該要件ファイル200,300から、利用者により任意に指定された項目を取得し(ステップ702)、要件ファイル200,300を閉じる(ステップ703)。
利用者の処理要求が要件検索の場合(ステップ704)、要件ファイル200から取得した各項目について利用者により任意に入力された値,範囲等に基づき、SELECT構文でクエリ文字列を生成する(ステップ705)。
一方、利用者の処理要求が要件登録の場合(ステップ704)、要件ファイル300から取得した各項目について利用者により任意に入力された値等に基づき、UPDATE構文でクエリ文字列を生成する(ステップ706)。
ステップ705又はステップ706により生成したクエリ文字列を、Webサービス検索システム100に送信して(ステップ707)、処理を終了する。
クエリ文字列生成処理では、クエリ文字列生成部111A〜111Dが、利用者により選択された要件ファイル200,300を開く(ステップ701)。当該要件ファイル200,300から、利用者により任意に指定された項目を取得し(ステップ702)、要件ファイル200,300を閉じる(ステップ703)。
利用者の処理要求が要件検索の場合(ステップ704)、要件ファイル200から取得した各項目について利用者により任意に入力された値,範囲等に基づき、SELECT構文でクエリ文字列を生成する(ステップ705)。
一方、利用者の処理要求が要件登録の場合(ステップ704)、要件ファイル300から取得した各項目について利用者により任意に入力された値等に基づき、UPDATE構文でクエリ文字列を生成する(ステップ706)。
ステップ705又はステップ706により生成したクエリ文字列を、Webサービス検索システム100に送信して(ステップ707)、処理を終了する。
図8は、Webサービス検索システム100の行う各処理を示すフローチャートである。
Webサービス検索システム100のクエリ実行部103は、業務システム110A〜110Dから受信したクエリ文字列を取得し(ステップ801)、要件データベース101に対応するクエリ文字列に変換する(ステップ802)。
変換したクエリ文字列がSELECT構文の場合には(ステップ803)、検索処理としてクエリを実行し、要件データベース101の要件テーブル400から検索要件に合致するレコードのIDと、各要件項目の値とを取得する(ステップ804)。
要件データベース101に検索要件を満たすレコードがある場合(ステップ805)、当該レコードの要件IDに基づき、対応テーブル500からbindingKeyを取得する(ステップ806)。
UDDIレジストリ検索部104は、クエリ実行部103の取得したbindingKeyに基づき、UDDIレジストリ102のtModel604を参照して、Webサービスのアクセスポイントを含む各情報を取得する(ステップ807)。
接続先情報生成部105は、検索要件,クエリ実行部103とUDDIレジストリ検索部104とが取得した各レコードの値及びアクセスポイント等の情報に基づき接続先情報を生成する(ステップ808)。
ステップ806〜808の処理を、検索結果として要件データベース101から取得した全てのレコードについて行う(ステップ809)。
一方、検索処理の結果、要件データベース101に検索要件を満たすレコードが無い場合には(ステップ805)、接続先情報を空で生成する(ステップ810)。
生成した接続先情報をWebサービス呼び出し側の業務システム110Aに送信して(ステップ811)、処理を終了する。
また、ステップ803において、変換した文字列がUPDATE構文の場合には、登録処理としてクエリを実行し、要件データベース101を更新して(ステップ812)、処理を終了する。
Webサービス検索システム100のクエリ実行部103は、業務システム110A〜110Dから受信したクエリ文字列を取得し(ステップ801)、要件データベース101に対応するクエリ文字列に変換する(ステップ802)。
変換したクエリ文字列がSELECT構文の場合には(ステップ803)、検索処理としてクエリを実行し、要件データベース101の要件テーブル400から検索要件に合致するレコードのIDと、各要件項目の値とを取得する(ステップ804)。
要件データベース101に検索要件を満たすレコードがある場合(ステップ805)、当該レコードの要件IDに基づき、対応テーブル500からbindingKeyを取得する(ステップ806)。
UDDIレジストリ検索部104は、クエリ実行部103の取得したbindingKeyに基づき、UDDIレジストリ102のtModel604を参照して、Webサービスのアクセスポイントを含む各情報を取得する(ステップ807)。
接続先情報生成部105は、検索要件,クエリ実行部103とUDDIレジストリ検索部104とが取得した各レコードの値及びアクセスポイント等の情報に基づき接続先情報を生成する(ステップ808)。
ステップ806〜808の処理を、検索結果として要件データベース101から取得した全てのレコードについて行う(ステップ809)。
一方、検索処理の結果、要件データベース101に検索要件を満たすレコードが無い場合には(ステップ805)、接続先情報を空で生成する(ステップ810)。
生成した接続先情報をWebサービス呼び出し側の業務システム110Aに送信して(ステップ811)、処理を終了する。
また、ステップ803において、変換した文字列がUPDATE構文の場合には、登録処理としてクエリを実行し、要件データベース101を更新して(ステップ812)、処理を終了する。
図9は、本実施の形態で用いられる要件ファイルと、当該要件ファイルに基づき、クエリ文字列生成部111A〜111Dの生成する各クエリ文字列との例を示す図である。
図9に示すように、要件ファイル900は、要件データベース101を構成するサービス種別毎の要件テーブル400に対応するものであり、各要件テーブル400における必須の要件項目として要件ID901とアクセスポイント902を有し、その他、サービス種別毎に異なる要件項目903を有する。本例では、DRAM半導体発注サービスに対応する要件項目903として、メーカ名,容量,単価,在庫数,納品日等の複数のデータ項目を有する。従って、要件ファイル900を取得した業務システム110Aでは、DRAM半導体受注サービスについて、ID,メーカ名,容量,電荷保持時間,使用基盤,在庫数,納品日,単価,・・・の各項目について検索要求が可能となり、具体的には、「在庫数が1000以上のDRAM半導体受注サービス」、「納品日が本日のDRAM半導体受注サービス」等の検索が可能となる。
Webサービス呼び出し側の業務システム110Aにおけるクエリ文字列生成部111Aは、利用者による「要件検索」の選択及び要件項目の選択を受付けるとともに、各要件項目に対応する値,範囲の指定(検索条件の指定)を受付け、クエリ文字列910を生成する。ここで、クエリ文字列910は、要件検索に使用されるものであり、SELECT構文を用いて、「単価」が「100」より安いDRAM半導体の発注が可能なWebサービスを検索する条件を記述したものである。
また、Webサービス提供側の業務システム110B〜110Dにおけるクエリ文字列生成部111B〜111Dは、利用者による「更新登録」の選択及び要件項目の選択を受付けるとともに、各要件項目に対応する値の指定(更新内容の指定)を受付け、クエリ文字列920を生成する。ここで、クエリ文字列920は、要件テーブル400の該当レコードの更新に使用されるものであり、UPDATE構文を用いて、「単価」と「在庫数」についての更新内容を記述したものである。
従って、本実施の形態によれば、業務システム110Aの利用者に対し、要件ファイル900から任意の要件項目を選択させるとともに、選択された各要件項目について、任意の値,範囲を入力させることのみにより、Webサービスの詳細な検索及び動的な接続等が可能となる。同様に、業務システム110B〜110Dについては、要件データベース101の更新要求が可能となる。
なお、要件ファイル900の配布は、Webサービス検索システムのWebページからの事前のダウンロードにより行う。また、他の方法として、要件ファイルの配布自体をWebサービス検索システムのWebサービスとして提供する形態(この場合はアクセスポイントを公開する)、オブジェクト言語による実装において、要件ファイル900を適切なオブジェクトにカプセル化し、オブジェクト配布(JavaであればJNDI(Java Naming and Directory Interface))で実施する形態等としてもよい。このように、要件ファイル900は要件項目のみが記述された単純な構造のため、柔軟な方法をとることができる。
図9に示すように、要件ファイル900は、要件データベース101を構成するサービス種別毎の要件テーブル400に対応するものであり、各要件テーブル400における必須の要件項目として要件ID901とアクセスポイント902を有し、その他、サービス種別毎に異なる要件項目903を有する。本例では、DRAM半導体発注サービスに対応する要件項目903として、メーカ名,容量,単価,在庫数,納品日等の複数のデータ項目を有する。従って、要件ファイル900を取得した業務システム110Aでは、DRAM半導体受注サービスについて、ID,メーカ名,容量,電荷保持時間,使用基盤,在庫数,納品日,単価,・・・の各項目について検索要求が可能となり、具体的には、「在庫数が1000以上のDRAM半導体受注サービス」、「納品日が本日のDRAM半導体受注サービス」等の検索が可能となる。
Webサービス呼び出し側の業務システム110Aにおけるクエリ文字列生成部111Aは、利用者による「要件検索」の選択及び要件項目の選択を受付けるとともに、各要件項目に対応する値,範囲の指定(検索条件の指定)を受付け、クエリ文字列910を生成する。ここで、クエリ文字列910は、要件検索に使用されるものであり、SELECT構文を用いて、「単価」が「100」より安いDRAM半導体の発注が可能なWebサービスを検索する条件を記述したものである。
また、Webサービス提供側の業務システム110B〜110Dにおけるクエリ文字列生成部111B〜111Dは、利用者による「更新登録」の選択及び要件項目の選択を受付けるとともに、各要件項目に対応する値の指定(更新内容の指定)を受付け、クエリ文字列920を生成する。ここで、クエリ文字列920は、要件テーブル400の該当レコードの更新に使用されるものであり、UPDATE構文を用いて、「単価」と「在庫数」についての更新内容を記述したものである。
従って、本実施の形態によれば、業務システム110Aの利用者に対し、要件ファイル900から任意の要件項目を選択させるとともに、選択された各要件項目について、任意の値,範囲を入力させることのみにより、Webサービスの詳細な検索及び動的な接続等が可能となる。同様に、業務システム110B〜110Dについては、要件データベース101の更新要求が可能となる。
なお、要件ファイル900の配布は、Webサービス検索システムのWebページからの事前のダウンロードにより行う。また、他の方法として、要件ファイルの配布自体をWebサービス検索システムのWebサービスとして提供する形態(この場合はアクセスポイントを公開する)、オブジェクト言語による実装において、要件ファイル900を適切なオブジェクトにカプセル化し、オブジェクト配布(JavaであればJNDI(Java Naming and Directory Interface))で実施する形態等としてもよい。このように、要件ファイル900は要件項目のみが記述された単純な構造のため、柔軟な方法をとることができる。
以上のように、本実施の形態に係るWebサービス検索システムでは、UDDIレジストリを利用したWebサービスへの動的接続を行う際においても、詳細な検索条件に基づくWebサービスの検索が可能となる。
特に、クエリ文字列に基づき要件検索,情報更新を行うこととしたので、双方の処理手段を別々に設ける必要が無く、システムの実装とメンテナンスを容易なものとすることが可能となる。
また、要件データベース(要件テーブル)に含まれる要件項目に対応した要件ファイルを生成して、各業務システムに提供することとしたので、要件ファイルの利用により要件検索,情報更新等を容易に行わせることが可能となる。また、各Webサービスの種別に応じた要件項目を有する要件ファイルと要件データベース(要件テーブル)とを作成しておくことにより、種々のWebサービスの検索に容易に対応することが可能となる。
また、クエリ文字列は、SQL構文という短い文字列で構成しているため、ネットワークに対する負荷を小さなものとすることができ、高いパフォーマンスを実現することが可能となる。特に、ネットワークとしてインターネットのような低速度のネットワークを介したWebサービスの動的接続に有利となる。
さらに、要件データベース及び要件ファイルを単純な構成としたため、保守管理等が容易となる。
特に、クエリ文字列に基づき要件検索,情報更新を行うこととしたので、双方の処理手段を別々に設ける必要が無く、システムの実装とメンテナンスを容易なものとすることが可能となる。
また、要件データベース(要件テーブル)に含まれる要件項目に対応した要件ファイルを生成して、各業務システムに提供することとしたので、要件ファイルの利用により要件検索,情報更新等を容易に行わせることが可能となる。また、各Webサービスの種別に応じた要件項目を有する要件ファイルと要件データベース(要件テーブル)とを作成しておくことにより、種々のWebサービスの検索に容易に対応することが可能となる。
また、クエリ文字列は、SQL構文という短い文字列で構成しているため、ネットワークに対する負荷を小さなものとすることができ、高いパフォーマンスを実現することが可能となる。特に、ネットワークとしてインターネットのような低速度のネットワークを介したWebサービスの動的接続に有利となる。
さらに、要件データベース及び要件ファイルを単純な構成としたため、保守管理等が容易となる。
なお、前記実施の形態では、Webサービス検索システム内にUDDIレジストリを含んだ構成を示しているが、これに限られるものでは無く、UDDIレジストリを別構成としてもよい。
また、Webサービス呼出し側の業務システムとWebサービス提供側の業務システムとは必ずしも区別されるものでは無く、双方の機能を備えた業務システムとしてもよい。
また、各業務システム側にクエリ文字列生成部を備えることとしているが、Webサービス検索システム側にクエリ文字列生成部を備えることとしてもよい。
また、Webサービス検索システムにおいて、要件データベースに対応する要件ファイルを生成する手段と、各要件ファイルを格納するデータベース等を備えることとしてもよい。
また、要件データベースを構成する対応テーブルにおいては、要件IDとbindingKeyとの対応関係を定義することとしているが、これに限られるものでは無く、UDDIレジストリ内の他の情報との対応関係を定義することとしてもよい。
また、Webサービス呼出し側の業務システムとWebサービス提供側の業務システムとは必ずしも区別されるものでは無く、双方の機能を備えた業務システムとしてもよい。
また、各業務システム側にクエリ文字列生成部を備えることとしているが、Webサービス検索システム側にクエリ文字列生成部を備えることとしてもよい。
また、Webサービス検索システムにおいて、要件データベースに対応する要件ファイルを生成する手段と、各要件ファイルを格納するデータベース等を備えることとしてもよい。
また、要件データベースを構成する対応テーブルにおいては、要件IDとbindingKeyとの対応関係を定義することとしているが、これに限られるものでは無く、UDDIレジストリ内の他の情報との対応関係を定義することとしてもよい。
100 Webサービス検索システム、101 要件データベース、102 UDDIレジストリ、103 クエリ実行部、104 UDDIレジストリ検索部、105 接続先情報生成部、110A〜110D 業務システム、111A〜111D クエリ文字列生成部、112A 接続先情報解釈部、120,130 クエリ文字列、140 接続先情報。
Claims (3)
- UDDIレジストリにアクセス可能な検索処理手段を備えるWebサービス検索システムであって、
各Webサービスの種別に対応する検索要件を格納した要件テーブルと、当該要件テーブルの各レコードと前記UDDIレジストリ内の情報を識別する識別情報との対応関係を定義した対応テーブルとを含む要件情報格納手段と、
Webサービス呼出し側の第一の業務システムからの検索要求を受付け、前記要件テーブルから検索条件に応じたレコードを取得するとともに、当該レコードに対応する前記識別情報を取得し、当該識別情報に基づき、前記UDDIレジストリからWebサービスの提供側の第二の業務システムについてのアクセスポイントを取得して、前記要件情報格納手段及び前記UDDIレジストリから取得した各情報に基づき接続先情報を生成して、前記第一の業務システムに送信するWebサービス検索処理手段と
を備えることを特徴とするWebサービス検索システム。 - 前記Webサービス検索処理手段は、
クエリ文字列を受付け、前記クエリ文字列に示される検索要求又は更新要求に応じて、前記要件情報格納手段に対し各処理を実行するクエリ実行手段を有することを特徴とする請求項1に記載のWebサービス検索システム。 - 前記要件テーブルに対応した要件項目を格納したファイルとして予め作成された要件ファイルから、任意に選択された要件項目を取得するとともに、取得した各要件項目に対し任意に指定された値又は範囲に基づき、前記クエリ文字列を生成するクエリ文字列生成手段を備えることを特徴とする請求項2に記載のWebサービス検索システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003381286A JP2005148823A (ja) | 2003-11-11 | 2003-11-11 | Webサービス検索システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003381286A JP2005148823A (ja) | 2003-11-11 | 2003-11-11 | Webサービス検索システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2005148823A true JP2005148823A (ja) | 2005-06-09 |
Family
ID=34690700
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003381286A Pending JP2005148823A (ja) | 2003-11-11 | 2003-11-11 | Webサービス検索システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2005148823A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010055141A (ja) * | 2008-08-26 | 2010-03-11 | Nec Corp | ウェブサービスシステム及びウェブサービス提供方法 |
JP2010527472A (ja) * | 2007-04-27 | 2010-08-12 | マイクロソフト コーポレーション | フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出す方法 |
-
2003
- 2003-11-11 JP JP2003381286A patent/JP2005148823A/ja active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010527472A (ja) * | 2007-04-27 | 2010-08-12 | マイクロソフト コーポレーション | フォームメタデータおよびテーブルメタデータからウェブサービスインターフェースを導き出す方法 |
US8484663B2 (en) | 2007-04-27 | 2013-07-09 | Microsoft Corporation | Method of deriving web service interfaces from form and table metadata |
US9158557B2 (en) | 2007-04-27 | 2015-10-13 | Microsoft Technology Licensing, Llc | Method of deriving web service interfaces from form and table metadata |
JP2010055141A (ja) * | 2008-08-26 | 2010-03-11 | Nec Corp | ウェブサービスシステム及びウェブサービス提供方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7343428B2 (en) | Dynamic, real-time integration of software resources through services of a content framework | |
US8335862B2 (en) | Programmatic management of software resources in a content framework environment | |
CN101065947B (zh) | Web服务注册和操作方法和系统 | |
US6985939B2 (en) | Building distributed software services as aggregations of other services | |
US7836439B2 (en) | System and method for extending a component-based application platform with custom services | |
CN1832476B (zh) | 动态服务代理方法与系统 | |
EP1901181B1 (en) | Discovery Web Service | |
KR101004576B1 (ko) | 연쇄 발견 웹 서비스 | |
CN100388265C (zh) | 管理数据处理系统中的应用文件的方法和装置 | |
US20070201655A1 (en) | System and method for installing custom services on a component-based application platform | |
US20050160088A1 (en) | System and method for metadata-based distribution of content | |
CA2409882A1 (en) | Persistent data storage for metadata related to web service entities | |
EP1444609A1 (en) | Application view component for system integration | |
US20050192929A1 (en) | Generation and conversion of object that provide for efficient object modification | |
US20050198336A1 (en) | Methods and apparatuses for automatic adaptation of different protocols | |
JP2005148823A (ja) | Webサービス検索システム | |
KR100479333B1 (ko) | ebXML 레지스트리에 기반을 둔 UDDI 웹서비스레지스트리 시스템과 그 관리 방법 | |
US7293021B1 (en) | Method and system for providing dynamic capability discovery and use | |
US20060026125A1 (en) | Accessing entity data from a UDDI registry | |
WO2008111031A2 (en) | An improved grid computing architecture and method for invoking network services for subscription | |
MXPA06006342A (es) | Soporte proxy agnostico tipo puerto para intermediarios de servicios de red. | |
JP2006526189A (ja) | ウエブサービスブローカー | |
JP2004356735A (ja) | ネットワークアクセスのための方法,プログラム,サーバ,システム | |
WO2007077412A1 (en) | Generating data messages | |
AU2002347920A1 (en) | Application view component for system integration |