【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上に複数のサービスプログラムが提供される分散コンピューティング環境を利用してクライアントが要求する処理を実行する分散情報処理システムに関する。
【０００２】
【従来の技術】
分散情報処理システムは、クライアントから要求された処理を複数の処理要素に分割し、分割した各処理要素をネットワークを介して適切なサービスプログラムに送信し、サービスプログラムから返信された結果を統合してクライアントに要求された処理の結果を回答する。例えば、気象情報の処理に関する分散型処理システムとして特許文献１がある。
【０００３】
【特許文献１】特開２００１−２０８８６２号公報 図３
【０００４】
【発明が解決しようとする課題】
しかしながら、上述した従来の分散処理システムでは、分割された各処理要素の処理をネットワーク上のどのサービスプログラムに依頼するか、および、各処理要素をどのような順番で実行するかは全体を制御する分散管理システムにより予め決定されており、実行途中で依頼先、処理順序を変更することは困難である。したがって、依頼先のサービスプログラムを格納するコンピュータやネットワークに障害が発生したり、処理の実行中に分散環境が変化した場合（例えば依頼するはずのサービスプロバイダのＵＲＬが変更される等）に、依頼先を動的に変更することも困難である。
【０００５】
本発明は、上記の従来技術の課題に鑑み、分散コンピューティング環境において、依頼先、処理順序を予め決定しなくともユーザの要求する処理を確実に実行して回答することができる分散型情報処理システムを提供することを目的とする。
【０００６】
【課題を解決するための手段】
本発明にかかる分散型情報処理システムは、上記の目的を達成させるため、サービスプログラムを提供するサービスプロバイダと、複数のサービスプログラムの仕様が登録されて依頼される処理内容に対応するサービスプログラムを抽出するレジストリと、サービスプログラムを利用して分散処理サービスを提供する分散システム制御手段と、分散処理サービスを利用するクライアントとがネットワークを介して接続される分散コンピューティング環境を前提として、分散システム制御手段は、クライアントからの処理依頼を受けると、当該処理依頼を解決するために必要な処理要素を取り出して各処理要素について処理内容をキーにしてレジストリを検索し、適切なサービスプログラムをレジストリから抽出し、抽出されたサービスプログラムから適当なプログラムを選択して処理要素の処理を依頼し、依頼した処理要素の処理結果を評価し、評価結果が依頼の要件を満足する場合には当該処理要素に関する処理を終了し、一部満足しない場合には実行されたサービスプログラムの処理結果を入力とする新たな処理要素を追加して新たに抽出された他のサービスプログラムに追加された処理要素の処理を依頼し、全部満足しない場合には先の処理要素の処理を他のサービスプログラムに代替して処理させ、全ての処理要素の評価結果が依頼の要件を満足した場合に、これらの処理結果を統合して処理依頼に対する回答をクライアントに示すことを特徴とする。
【０００７】
上記のシステムによれば、依頼先のサービスプログラムがレジストリを用いて動的に決定されるため、プロバイダやネットワークに障害が発生した場合にも、それを避けて分散処理を実行することができ、安全、確実にクライアントに依頼された課題を解決することができる。
【０００８】
なお、上記のように依頼先を検索結果に基づいて動的に決定する場合、選択されたサービスプログラムが要求を完全に満たす回答を返さない場合が想定される。例えば、１つのサービスプログラムの処理結果を次のサービスプログラムの入力とする場合に、先のサービスプログラムの出力が次のサービスプログラムの入力の形式を満たさない場合である。このような場合に、先のサービスプログラムによる処理をエラーとして処理全体を中止すると、クライアントは求める回答を得ることができず、新たに処理要求を出し直さなければならない。
【０００９】
本発明のシステムでは、選択されたサービスプログラムが要求を完全に満たす回答を返さない場合にも、回答が一部利用できる場合には、新たな処理要素を追加して他のサービスプログラムを追加的に挿入して回答を要求に合致した形式に加工することにより、処理全体を中止することなく、クライアントに回答することができる。
【００１０】
上記の分散システム制御手段に、クライアントからの処理依頼を解決するためのあらゆるオブジェクトを保持するコンテナを備えさせることができる。この場合には、当該コンテナ内で処理要素の処理、評価を実行することができる。
【００１１】
ネットワークがインターネットでありる場合、レジストリとしては、インターネット上に散在するサービスプログラムに関する情報を格納するＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ， Ｄｉｓｃｏｖｅｒ ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ）を利用することができる。ＵＤＤＩを利用する場合には、分散システム制御手段がレジストリからサービスプログラムを抽出する際には、ＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）ファイルのファイル名を受け取り、分散システム制御手段は、ファイル名に基づいてＷＳＤＬファイルを取得して適切なサービスプログラムを選択することとなる。また、分散システム制御手段は、処理要素を実行したサービスプログラムから処理結果と共にＷＳＤＬファイルが返送された場合に、評価結果が依頼の要件を一部満足しないと判断し、新たな処理要素を追加するようにしてもよい。
【００１２】
【発明の実施の形態】
以下、この発明にかかる分散型情報処理システムの実施形態を説明する。最初に、図１により実施形態の分散型情報処理システムのシステム構成について説明する。なお、実施形態のシステムは、グリッド・コンピューティングの技術を使って複数のデータベースを検索するものである。グリッド・コンピューティングは、ネットワーク上のサーバやストレージ、データベース、アプリケーションなどのさまざまな資源をグリッドの一点（コンピュータ・グリッド）とし、これらを相互に結んだひとつの巨大なコンピュータとして捉えたものである。
【００１３】
実施形態のシステムは、分散システム制御手段として分散コンピューティング環境を利用してクライアントからの処理依頼を解決するサーバ１と、各種のサービスプログラムを提供する複数のサービスプロバイダ２と、これらのサーバ１とサービスプロバイダ２とが接続される広域ネットワークとしてのインターネット３とを含む。クライアント４は、この例ではサーバ１に対してローカルエリアネットワーク（ＬＡＮ）５を介して接続されている。ただし、クライアント４もインターネット３を介して接続されてもよい。
【００１４】
サーバ１は、クライアントからの処理依頼を受け付けてクライアントに回答するまでの全体の処理の流れを制御する処理依頼コントローラ１ａと、処理依頼を解決するために必要な処理要素の実行を制御する処理要素コントローラ１ｂとを含む。処理依頼は、クライアントが解決を求める課題であり、通常複数の処理要素に分けて考えることができる。処理要素は、一連の処理の中で、分散された環境で実際にサービスプログラムによって処理される単位である。
【００１５】
また、サーバ１のメモリ空間には、クライアント４からの処理依頼を受けると図中破線で示すコンテナ１ｃが生成される。コンテナ１ｃは、処理依頼に含まれる処理要素オブジェクトをもとに実行に関連する全てオブジェクトを集約する。
【００１６】
一方、インターネット３には、複数のサービスプログラムＳＰの仕様が登録されて依頼される処理内容に対応するサービスプログラムを抽出するサービスリゾルバ６が接続されている。サービスリゾルバ６は、ＵＤＤＩを利用したレジストリであり、インターネット上に散在するサービスプログラムに関する情報を格納している。
【００１７】
図２は、上記の分散型情報処理システムの作動を示す概念図である。図２では、サービスプロバイダ２をまとめてＧｒｉｄ Ｐｒｏｘｙとして記載している。クライアントから処理依頼がコンテナに入力されると、サーバ１の処理依頼コントローラ１ａが処理依頼から処理要素を取得してコンテナ内に設定する。処理要素コントローラ１ｂは、処理要素から検索条件を受けると、サービスリゾルバ６に対して処理要素を処理するために適したサービスプログラムを抽出するよう「サービス検索」の指示を出す。
【００１８】
サービスリゾルバ６は、その処理要素を解決するために適したサービスプログラムに関する検索結果をＷＳＤＬファイル名のリストとして返してくる。ＷＳＤＬとは、Ｗｅｂサービスを用いるときに必要なＷｅｂサービスの仕様を記述するためのＸＭＬ形式で記述された仕様である。１つの処理に対して複数のサービスプログラムが抽出される場合もあり、その場合にはサービスプログラム毎に１つのＷＳＤＬファイル名（ＵＲＬ）が提供される。
【００１９】
処理要素コントローラ１ｂは、当該処理要素に適したサービスプログラムを選択するため、ＷＳＤＬファイル名に基づいてＷＳＤＬファイルを取得し、解析する。ＷＳＤＬファイルには、サービスプログラムを提供しているホスト名（ＵＲＬ）、具体的なプログラム名、入力ファイル名、出力ファイル名等の情報が記述されている。１つずつＷＳＤＬファイルを開き、サービスプログラムの入出力形式をチェックして、処理要素に対して必要な結果が得られるか否かを判断し、どのサービスプログラムが最適かを判断する。なお、サービスプログラムの選択に当たっては、処理内容のみでなく、ネットワークの混雑等の要因も考慮に入れることが好ましい。
【００２０】
最適なサービスプログラムが選択されると、処理要素コントローラ１ｂが処理要素の処理をサービスプログラムに依頼する。すなわち、処理要素の入力データをＧｒｉｄ Ｐｒｏｘｙに転送すると共に、サービスプログラムの実行を依頼する。サービスプログラムから処理結果が返ると、この処理結果は処理要素に設定されると共に、処理要素コントローラ１ｂにより評価される。
【００２１】
評価の結果、処理要素の出力形式を満たす処理結果をサービスプログラムが出力した場合には、当該処理要素については処理済みとして未処理の処理要素を同様にして抽出、選択したサービスプログラムに渡して処理を実行する。
【００２２】
一方、サービスプログラムの処理結果が当該処理要素の出力形式を満たさない場合には、サービスプログラム側から出力形式がどのように満たされていないかを記述したＷＳＤＬファイルが発行される。処理要素コントローラ１ｂは、このファイルが返ってきたときには、サービスプログラムの処理結果を、このサービスプログラムにより処理された先の処理要素の出力形式に一致させるための処理要素を追加する。追加される処理要素は、単一の場合も複数の場合もあり得る。
【００２３】
なお、サービスプログラムが処理結果を返さない場合、例えば各サービス側でプログラムが停止したり、ネットワークが切断された場合には、このサービスプログラムへの依頼を撤回して他の候補に代替させる。処理依頼コントローラー側でタイマー監視をしている場合には、例えば通常３分で応答があるものが１時間経っても応答がない場合には、依頼を撤回してもよい。
【００２４】
また、実施形態では、グリッド・コンピューティングの技術を使い分散システムを実装しているため、ＵＤＤＩやＷＳＤＬを用いているが、ＣＯＲＢＡ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）技術を用いる場合には、ネーミングサービスへ問い合わせ結果をオブジェクトリファレンスで受けることになる。
【００２５】
次に、上記のシステムを利用した処理の詳細を図３〜図７のフローチャートに基づいて説明する。図３は処理全体の概略を示すフローチャートであり、図４〜図７は、図３のフローチャートに含まれる１つのステップをより詳細に説明したものである。
【００２６】
クライアントから処理依頼を受け取ると、サーバ１内の処理依頼コントローラ１ａは、サーバ１のメモリ空間に当該処理依頼に対応したコンテナを生成する（ステップＳ１）。ステップＳ２では、処理依頼コントローラ１ａは、処理依頼を分散処理に適した処理要素に分解して設定する。
【００２７】
処理依頼コントローラ１ａは、これらの処理要素を処理する順番でソーティングしてソートテーブルを作成する。処理要素をソーティングするキーとなるのが、処理順番オブジェクトである。以下、処理要素はこのソートテーブルにより管理される。
【００２８】
処理順番は、正の整数のｎ次元配列で管理される。次元数の低いところから番号の空きを探し、見つかれば、同じ次元で番号を増やしたものを採用し、増やそうとした番号が重複する場合には次元を増やし重複を回避する。新規に処理依頼が入力された場合、処理要素には０から始まる整数の処理順番「０，１，２，３，…，ｎ」が付される。処理要素の処理結果を評価して新たな処理要素が追加される場合には、順番の途中に割り込んで処理順番が追加される。例えば「２」と「３」の間に新たに処理要素を追加する場合、追加される番号は「２．０」となる。さらに、「２．０」と「３」との間に新たな処理要素を追加する場合、追加される番号は「２．１」となり、「２．０」と「２．１」の間に加える場合には「２．０．１」となる。ただし、過去の順序は変更できず、例えば「２」と「２．０」との間には追加することはできない。さらに、各処理要素は、以下の表１に示す情報を備えている。
【００２９】
【表１】
【００３０】
入力情報は、当該処理要素が最初に処理されるものであれば、クライアントから与えられており、当該処理要素より前段階で実行される処理要素の出力を入力として用いる場合には、先の処理要素が正常に終了した段階で書き込まれる。また、出力情報は、当該処理要素が実行された後に処理結果として記録される。さらに、サービスプロパティは、サービス検索条件をキーにしてサービスリゾルバ６によりサービスプログラムを抽出することにより記録されるものであり、抽出されたサービスプログラムのリストを含み、このリストには、各サービスプログラムを既に実行したか否かの履歴も含まれる。サービスプロパティ内のサービスプログラムのリストは、サービス評価関数に従いソートされて管理されている。なお、処理要素は、当該処理要素が処理中なのか、処理済なのか、未処理なのかの情報も有している。
【００３１】
未実行の処理依頼内の処理要素は、全て未処理状態となっている。また、処理済みの処理要素については、処理結果の保存場所が出力情報に記録されている。処理要素は処理順にソートされているため、ソートテーブルを処理順に検索して最初に出現した未処理の処理要素から順番に実行していけばよい。
【００３２】
ステップＳ３では、処理要素の処理順番を規定するソートテーブルの参照位置が初期化される。ステップＳ４以下の処理は、処理依頼に含まれる全ての処理要素について処理を実行するためのものである。まず、ステップＳ４では、ソートテーブルを参照してコンテナに格納された処理要素から実行可能な処理要素を取得する。ステップＳ４の処理の詳細については後述する。
【００３３】
ステップＳ５では、処理要素コントローラ１ｂが、ステップＳ４の処理で処理要素を取得したか否かを判断する。処理要素が取得された場合には、取得された処理要素をそれぞれネットワーク上のサービスプログラムに割り当て、分散処理を実行し（ステップＳ６）、処理要素コントローラが処理要素についての処理結果を評価する（ステップＳ７）。評価の結果、サービスプログラムが正常に終了したと判断される場合（ステップＳ８，Ｙｅｓ）には、ステップＳ４に戻って次の処理要素を取得する。何らかの異常があって正常終了しなかったと判断された場合（ステップＳ８，Ｎｏ）には、ステップＳ９において処理のリトライを試みて、可能であればステップＳ６に戻って処理を繰り返す。
【００３４】
ステップＳ５で処理要素が取得されなかったと判断された場合には、ステップＳ１０で全ての処理要素が処理済みか否かを判断する。全て処理済みであれば、各処理要素について得られた処理結果を統合して回答をクライアントに送る（ステップＳ１１）。続いて、ステップＳ１２では、回答がクライアントの要求を満たして承認が得られるか否かを判断し、承認が得られれば、当該処理依頼についての処理を正常に終了し、コンテナに含まれる情報を全てクリアする。承認が得られなければ、ステップＳ２からの処理を繰り返す。
【００３５】
ステップＳ９で処理済みではない処理要素が含まれると判断された場合には、ステップＳ１３で実行中の処理要素があるか否かを判断する。実行中の処理要素が存在する場合（ステップＳ１３，Ｙｅｓ）には、ステップＳ４に戻って処理を繰り返す。一方、処理済みではない処理要素が含まれるにもかかわらず、実行中の処理要素が存在しない場合（ステップＳ１３，Ｎｏ）には、回避が不能な障害が発生したと判断し、ステップＳ１４でクライアントに「実行不能」であることを通知して異常終了する。
【００３６】
以上の処理により、障害が発生しなければ、全ての処理要素についてネットワークに接続されたサービスプログラムを用いて分散処理を行い、クライアントが要求する処理依頼に対して回答を与えることができる。
【００３７】
次に、上記のステップＳ４の「処理要素取得」処理の詳細を図４のフローチャートに基づいて説明する。ここでは、処理要素の処理順序を規定するソートテーブル（Ｓ２で作成）を利用し、ソートテーブル内の未処理の処理要素の位置から順番に処理要素の状態を確認し、実行可能な処理要素を取り出す。実行可能な条件は、（１）処理要素の状態が未処理であること、そして（２）処理要素の入力データが存在することである。（２）の条件は、表１の入力情報をチェックすることにより満たすか否かを判断できる。（２）の条件を満たすのは、その処理要素の入力データが、（２−１）他の処理済の処理要素の処理結果として存在するか、あるいは、（２−２）最初に実行されれる処理要素の入力データとして存在する場合である。（２−１）のチェックは、処理済みの処理要素の出力データを実行された順とは逆順で、すなわち、直前に処理された要素から順に検索して実行される。
【００３８】
ステップＳ１０１では、処理要素コントローラ１ｂがソートテーブルの参照位置の処理順番に該当する処理要素の状態をチェックする。ステップＳ１０２では、処理要素コントローラ１ｂによりチェックされた処理要素が未処理であるか否か、すなわち上記の条件（１）を満たすか否かが判定される。未処理であればステップＳ１０３に進み、未処理でなければステップＳ１０６に進む。
【００３９】
未処理の処理要素が発見されると、ステップＳ１０３においてその処理要素の入力データが存在するか否か、すなわち上記の条件（２）を満たすか否かが判定される（ステップＳ１０４）。入力データが存在すればステップＳ１０５に進み、存在しなければステップＳ１０５をスキップしてステップＳ１０６に進む。
【００４０】
ステップＳ１０５では、当該処理要素を実行可能な要素として取得し、処理要素コントローラ１ｂに渡す。ステップＳ１０６では、ソートテーブルの参照位置を進め、ステップＳ１０７では参照位置がテーブルの最後に達したか、すなわち、ソートテーブル内の処理要素のチェックが全て終了したか否かを判断する。ソートテーブルの最後に達していなかったら、ステップＳ１０１に戻って処理を繰り返し、ソートテーブルの最後に達していたら、図３のフローチャートにリターンする。
【００４１】
図４の処理要素取得処理により、処理依頼コントローラは、ソートテーブル内の未処理の処理要素の先頭位置を探し、その処理要素から後の処理要素のうち、実行可能な処理要素を全て取り出して処理要素コントローラに渡すことができる。
【００４２】
次に、図３のステップＳ６の「処理要素の実行」の処理の詳細を図５のフローチャートに基づいて説明する。
ステップＳ４の「処理要素取得」処理で実行可能な処理要素が取得されると、処理要素コントローラ１ｂは、取得された処理要素を全て並列に実行する。すなわち、処理要素ごとにスレッドをあてがいマルチスレッドで並行処理する。
【００４３】
ステップＳ２０１では、処理要素コントローラは実行される処理要素にサービスプロパティが存在するか否かを確認し、ステップＳ２０２で判断する。サービスプロパティが存在しない場合、すなわち、当該処理要素について未だサービスリゾルバ６によりサービスプログラムを検索してない場合には、ステップＳ２０３においてサービスプロパティを検索する。
【００４４】
ステップＳ２０３の検索処理は、以下の（１）〜（８）段階を含む。
（１）処理要素からサービス検索条件を取得する。
（２）取得したサービス検索条件のサイト名、サービス名をキーにサービスリゾルバ６（ＵＤＤＩレジストリ）を検索する。検索結果は検索条件にあったサービスの詳細が記述されたＷＳＤＬファイルの存在場所（ＵＲＬ形式）として得られる。
（３）検索結果一件毎にサービスプロパティオブジェクトを１つ生成する。
（４）作成したサービスプロパティオブジェクトをサービス情報に加える。
（５）サービス情報は加えられたサービスプロパティオブジェクトをサービス評価関数に従い優先度を付けて管理する。
（６）処理要素コントローラはサービスプロパティを取り出し、取り出したサービスプロパティからサービスの詳細が記述されているＷＳＤＬファイルを実在するコンピュータから転送し、ファイルの内容読み込み解釈する。
（７）解釈した結果として以下の項目を取得し、取得した情報をサービスプロパティに設定する。
・実行先のホスト名
・実行するコマンド名、コマンド引数
・コマンドの入力するファイルの種類、数、並び順
・コマンドの出力する結果
・出力する手段（例えば、エラー出力、標準出力、ファイル出力等）ごとのデータの種類、数
（８）設定されたサービスプロパティの情報分の評価値を算出して加点し、サービスの優先度順を更新する。
【００４５】
ステップＳ２０３で取得されたサービス情報を使い、若しくは、ステップＳ２０２でサービスプロパティが存在すると判断された場合にはすでに登録されているサービス情報を使い、以降の処理を実行する。ステップＳ２０４では、処理要素コントローラ１ｂがサービス情報から実行すべきサービスプログラムに関するサービスプロパティを取得する。取得されるサービスプロパティは、過去に実行された履歴が存在するものを除いて、優先順位が一番高いサービスプログラムに関するものである。
【００４６】
ステップＳ２０５では、ステップＳ２０４でサービスプロパティが取得できたか否かを判断し、取得できなかった場合にはエラーとしてステップＳ２０６でクライアントに「実行不能」を通知して異常終了する。サービスプロパティを取得できた場合には、ステップＳ２０４で取得したサービスプロパティに実行の履歴を追加する（ステップＳ２０７）。
【００４７】
続いて、処理要素コントローラ１ｂは、ステップＳ２０８において、サービスプロパティに設定されている入力ファイルを、選択されたサービスプログラムが実行されるコンピュータへ転送する。ステップＳ２０９では、サービスプロパティから実行先と実行するコマンドを取得し、実行先のコンピュータへ処理を依頼する。そして、ステップＳ２１０では当該処理要素の状態を「実行中」にする。ステップＳ２０７〜２１０の処理に異常がないか否かをステップＳ２１１でチェックし、異常が生じた場合にはステップＳ２１２のエラー処理を経て図３のフローチャートにリターンする。ステップＳ２１２のエラー処理は、サービスプロパティに失敗の履歴を追加し、不要なデータを削除する処理である。
【００４８】
ステップＳ２１３では、処理要素コントローラ１ｂがサービス評価関数によりサービスプログラムの実行状態を評価し、ステップＳ２１４で評価関数に応じて実行したサービスプログラムの続行／中止の制御を行う。中止の場合には、ステップＳ２１２のエラー処理を実行する。例えば、処理時間が評価関数として指定されていれば、処理時間を評価し、所定の時間をオーバーした場合にはサービスプログラムを中止してエラー処理を実行する。
【００４９】
処理要素コントローラがステップＳ２１５においてサービスプログラムの終了を検出すると、そのサービスプログラムの終了コードを取得し、終了コードが正常終了を示しているか否かをステップＳ２１６で判断する。終了コードが正常終了を示している場合にはそのまま、示していない場合にはステップＳ２１２のエラー処理を実行してから図３のフローチャートにリターンする。
【００５０】
次に、図３のステップＳ７の「処理結果の評価」の処理の詳細を図６のフローチャートに基づいて説明する。ステップＳ３０１において処理要素コントローラ１ｂは、サービスプログラムから出力される処理結果とサービスプロパティが持つ出力情報とを照合する。次に、ステップＳ３０２において、両者の情報に矛盾がないか否かを判断する。具体的には、サービスプロパティの出力情報に記述されたデータ型とデータ数とが実際の処理結果と一致しているか否かにより矛盾の有無を判定する。矛盾がない場合には、正常に処理が実行されたと判断する。
【００５１】
ステップＳ３０２で矛盾があると判断された場合には、出力されたデータに処理要素を記述したＷＤＳＬファイルが含まれるか否かが判断される（ステップＳ３０３）。出力データ内のＷＤＳＬファイルの存在は、処理要素の追加が必要であることを意味する。そこで、この場合には、処理依頼コントローラ１ｂがコンテナ１ｃ内に新たな処理要素を追加し（ステップＳ３０４）、本処理要素は正常終了したと判断する。
【００５２】
ステップＳ３０３でＷＳＤＬファイルが存在しない場合には、当該処理要素が正常に終了しなかったと判断し、ステップＳ２１２と同様のエラー処理を実行し（ステップＳ３０５）、図３のフローチャートにリターンする。この場合には、当該処理要素を実行するために選択されたサービスプログラムではなく、他のサービスプログラムが必要と判断され、続くステップＳ９で別のサービスプログラムを選択して当該処理要素の処理は継続する。
【００５３】
実行していた処理要素が正常に終了したと判断された場合には、該当のサービスプログラムから出力された結果をデータ型ごとに当該処理要素の出力情報へ登録し（ステップＳ３０６）、処理要素コントローラは１ｂは当該処理要素の処理状態を「実行済」にし（ステップＳ３０７）、図３のフローチャートにリターンする。
【００５４】
次に、図３のステップＳ９の「処理のリトライ」の処理の詳細を図７のフローチャートに基づいて説明する。この処理は、ステップＳ６、Ｓ７の処理が正常に終了しなかった場合、すなわち、ステップＳ２１２あるいはステップＳ３０５のエラー処理を経てきた場合に、代替のサービスプログラムを提供して処理要素を実行するための処理である。
【００５５】
まず、ステップＳ４０１では、処理しようとしていた処理要素の状態を「処理中」から「未処理」に戻す。続いて、ステップＳ４０２においてソートテーブルを参照して実行済みの処理要素を実行順に１つ遡り（参照位置を１つ戻し）、参照位置がソートテーブルの最初に達しておらず、遡る処理要素が存在する場合には（ステップＳ４０３，Ｎｏ）、遡った処理要素の状態を未実行に変更する（ステップＳ４０４）。これらのステップＳ４０２〜４０４の３つのステップを、リトライ（再実行）できる分岐となる処理要素を発見するまで繰り返す。
【００５６】
リトライできるかどうかは、処理要素のサービスプロパティの中に、実行履歴が無い（未実行の）サービスプログラムに関するプロパティが存在するか否かにより決まる。実行履歴のないサービスプログラムのサービスプロパティが存在すれば、リトライが可能と判断する。リトライできる処理要素が発見された場合には、図３のフローチャートにリターンし、ステップＳ６で未実行のサービスプロパティで定義されるサービスプログラムを使い、その処理要素から処理を再実行する。
【００５７】
リトライできる処理要素を発見する前にソートテーブルの最初に達して遡る処理要素が存在しなくなった場合（ステップＳ４０４，Ｙｅｓ）には、処理依頼は実行不能と判断し、ステップＳ４０６でクライアントに「実行不能」であることを通知して異常終了する。
【００５８】
次に、サービスプログラムを抽出、選択する際に処理要素のサービス情報とＵＤＤＩ上の情報、あるいはＷＳＤＬファイルに記述された情報とがどの程度合致していれば一致と判断するか、具体例を挙げて説明する。
【００５９】
最初に、Ｓ２０３のサービスプロパティの検索において、処理要素のサービス条件に定められたサービス名が「ＡＢ」であるとき、ＵＤＤＩに登録されたどのようなサービス名が一致と判断されるかを表２に示す。表中の記号「×」は抽出されないサービスであること、「○」は抽出されるサービスであることを示している。
【００６０】
【表２】
【００６１】
次に、ＷＳＤＬファイルを読み込んだ際にサービスプログラムの入力／出力条件が「ＡＢ」であるとき、処理要素のサービス検索条件がどのような条件であるときに条件が一致と判断されるかを表３に示す。表中の記号「◎」は最優先でデータが一致していると判断すること、「○」は「◎」がないときに一致すると判断されること、「△」は「◎」と「○」とがないときに一致すると判断されること、「×」は不一致であることを示している。
【００６２】
【表３】
【００６３】
続いて、図７の処理で処理要素を１つずつ遡って検索する際に、入力の予定が「ＡＢ」であるとき、サービスプロパティでどのような実績のある処理要素をＳ４０５でリトライ可能（データ一致）と判断するか否かを表４に示す。記号の意味は表３と同様である。
【００６４】
【表４】
【００６５】
【発明の効果】
以上説明したように、本発明によれば、依頼先のサービスプログラムがレジストリを用いて動的に決定されるため、プロバイダやネットワークに障害が発生した場合にも、それを避けて分散処理を実行することができ、安全、確実にクライアントに依頼された課題を解決することができる。
【００６６】
また、選択されたサービスプログラムが要求を完全に満たす回答を返さない場合にも、回答が一部利用できる場合には、新たな処理要素を追加して他のサービスプログラムを追加的に挿入して回答を要求に合致した形式に加工することにより、処理全体を中止することなく、クライアントに回答することができる。
【図面の簡単な説明】
【図１】本発明の実施形態にかかる分散型情報処理システムのシステム構成を示すブロック図である。
【図２】図１の分散型情報処理システムの作動を示す概念図である。
【図３】実施形態にかかる分散型情報処理システムを利用した処理の概略を示すフローチャートである。
【図４】図３の処理要素取得を詳細に示すフローチャートである。
【図５】図３の処理要素の実行を詳細に示すフローチャートである。
【図６】図３の処理要素の評価を詳細に示すフローチャートである。
【図７】図３の処理のリトライを詳細に示すフローチャートである。
【符号の説明】
１ サーバ
１ａ 処理依頼コントローラ
１ｂ 処理要素コントローラ
１ｃ コンテナ
２ サービスプロバイダ
３ インターネット
４ クライアント
５ ＬＡＮ
６ サービスリゾルバ[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a distributed information processing system that executes a process requested by a client using a distributed computing environment in which a plurality of service programs are provided on a network.
[0002]
[Prior art]
The distributed information processing system divides a process requested by a client into a plurality of processing elements, transmits each of the divided processing elements to an appropriate service program via a network, and integrates results returned from the service program. Returns the result of the requested processing to the client. For example, Patent Document 1 discloses a distributed processing system related to processing of weather information.
[0003]
[Patent Document 1] Japanese Patent Application Laid-Open No. 2001-208862 FIG.
[0004]
[Problems to be solved by the invention]
However, in the above-described conventional distributed processing system, the entire control is performed as to which service program on the network requests processing of each divided processing element, and in what order each processing element is executed. It is determined in advance by the distributed management system, and it is difficult to change the request destination and the processing order during execution. Therefore, when a failure occurs in the computer or network storing the service program of the request destination or when the distributed environment changes during execution of the processing (for example, the URL of the service provider to be requested is changed), It is also difficult to change the destination dynamically.
[0005]
SUMMARY OF THE INVENTION The present invention has been made in view of the above-described problems of the related art, and in a distributed computing environment, a distributed information processing system capable of reliably executing and responding to a process requested by a user without previously determining a request destination and a processing order. The purpose is to provide a system.
[0006]
[Means for Solving the Problems]
In order to achieve the above object, the distributed information processing system according to the present invention extracts a service provider that provides a service program, and a service program corresponding to a processing content requested by registering specifications of a plurality of service programs. Distributed system control means for providing a distributed processing service using a service program, and a distributed computing environment in which a client using the distributed processing service is connected via a network. Receives a processing request from the client, retrieves the processing elements necessary to resolve the processing request, searches the registry using the processing content for each processing element as a key, and extracts an appropriate service program from the registry. , Extracted service program Requesting the processing of the processing element by selecting an appropriate program from the system, evaluating the processing result of the requested processing element, and ending the processing for the processing element when the evaluation result satisfies the requirement of the request; If the part is not satisfied, a new processing element that receives the processing result of the executed service program as an input is added, and processing of the processing element added to another newly extracted service program is requested. In this case, the processing of the previous processing element is replaced with another service program, and when the evaluation results of all processing elements satisfy the requirements of the request, these processing results are integrated and the response to the processing request is made. Is shown to the client.
[0007]
According to the above system, the service program of the request destination is dynamically determined using the registry. Therefore, even if a failure occurs in the provider or the network, it is possible to execute the distributed processing while avoiding the failure, It is possible to safely and securely solve the issues requested by clients.
[0008]
When the request destination is dynamically determined based on the search result as described above, it is assumed that the selected service program does not return a response that completely satisfies the request. For example, when the processing result of one service program is input to the next service program, the output of the previous service program does not satisfy the input format of the next service program. In such a case, if the processing by the previous service program is regarded as an error and the whole processing is stopped, the client cannot obtain a desired answer and must reissue a processing request.
[0009]
In the system of the present invention, even when the selected service program does not return a response that completely satisfies the request, if the response is partially available, a new processing element is added to add another service program. And processing the response into a format that matches the request, it is possible to reply to the client without stopping the entire process.
[0010]
The above-mentioned distributed system control means may be provided with a container for holding all objects for solving a processing request from a client. In this case, processing and evaluation of the processing element can be executed in the container.
[0011]
When the network is the Internet, a UDDI (Universal Description, Discover and Integration) that stores information on service programs scattered on the Internet can be used as the registry. When UDDI is used, when the distributed system control unit extracts a service program from the registry, it receives the file name of a WSDL (Web Service Description Language) file, and the distributed system control unit uses the WSDL based on the file name. The user obtains the file and selects an appropriate service program. Further, when the WSDL file is returned together with the processing result from the service program that has executed the processing element, the distributed system control means determines that the evaluation result does not partially satisfy the requirements of the request, and adds a new processing element. You may do so.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, an embodiment of a distributed information processing system according to the present invention will be described. First, the system configuration of the distributed information processing system according to the embodiment will be described with reference to FIG. The system according to the embodiment searches a plurality of databases using the technology of grid computing. In grid computing, various resources such as servers, storages, databases, and applications on a network are regarded as one point of a grid (computer grid), and are regarded as one huge computer interconnecting these resources.
[0013]
The system according to the embodiment includes a server 1 that resolves a processing request from a client using a distributed computing environment as a distributed system control unit, a plurality of service providers 2 that provide various service programs, The Internet 3 as a wide area network to which the service provider 2 is connected. The client 4 is connected to the server 1 via a local area network (LAN) 5 in this example. However, the client 4 may also be connected via the Internet 3.
[0014]
The server 1 includes a processing request controller 1a that controls the entire processing flow from receiving a processing request from a client to responding to the client, and a processing element that controls execution of processing elements required to resolve the processing request. Controller 1b. The processing request is an issue that the client seeks to solve, and can usually be considered in a plurality of processing elements. A processing element is a unit that is actually processed by a service program in a distributed environment in a series of processing.
[0015]
When a processing request is received from the client 4, a container 1c indicated by a broken line in the figure is generated in the memory space of the server 1. The container 1c aggregates all objects related to execution based on the processing element objects included in the processing request.
[0016]
On the other hand, the Internet 3 is connected to a service resolver 6 for registering specifications of a plurality of service programs SP and extracting a service program corresponding to the requested processing content. The service resolver 6 is a registry using UDDI, and stores information on service programs scattered on the Internet.
[0017]
FIG. 2 is a conceptual diagram showing the operation of the above-mentioned distributed information processing system. In FIG. 2, the service providers 2 are collectively described as Grid Proxy. When a processing request is input to a container from a client, the processing request controller 1a of the server 1 acquires a processing element from the processing request and sets the processing element in the container. When receiving the search condition from the processing element, the processing element controller 1b issues an instruction of “service search” to the service resolver 6 to extract a service program suitable for processing the processing element.
[0018]
The service resolver 6 returns a search result regarding a service program suitable for solving the processing element as a list of WSDL file names. WSDL is a specification described in an XML format for describing a specification of a Web service required when using the Web service. In some cases, a plurality of service programs are extracted for one process. In that case, one WSDL file name (URL) is provided for each service program.
[0019]
The processing element controller 1b acquires and analyzes a WSDL file based on the WSDL file name in order to select a service program suitable for the processing element. The WSDL file describes information such as a host name (URL) providing the service program, a specific program name, an input file name, and an output file name. The WSDL file is opened one by one, the input / output format of the service program is checked, it is determined whether or not a required result is obtained for the processing element, and which service program is optimal. In selecting a service program, it is preferable to take into account not only the processing content but also factors such as network congestion.
[0020]
When the optimal service program is selected, the processing element controller 1b requests the processing of the processing element from the service program. That is, the input data of the processing element is transferred to the Grid Proxy and the execution of the service program is requested. When the processing result is returned from the service program, the processing result is set in the processing element and is evaluated by the processing element controller 1b.
[0021]
As a result of the evaluation, if the service program outputs a processing result that satisfies the output format of the processing element, the processing element is processed and the unprocessed processing element is similarly extracted and passed to the selected service program for processing. Execute
[0022]
On the other hand, when the processing result of the service program does not satisfy the output format of the processing element, the service program issues a WSDL file describing how the output format is not satisfied. When this file is returned, the processing element controller 1b adds a processing element for making the processing result of the service program match the output format of the processing element processed by this service program. The processing element to be added may be single or plural.
[0023]
If the service program does not return a processing result, for example, if the program is stopped on each service side or the network is disconnected, the request to the service program is withdrawn and replaced with another candidate. If the processing request controller is monitoring the timer, for example, if there is no response after 3 hours, but there is no response after 1 hour, the request may be withdrawn.
[0024]
In the embodiment, since the distributed system is implemented by using the grid computing technology, UDDI and WSDL are used. However, when the CORBA (Common Object Request Broker Architecture) technology is used, the naming service is used. The query result will be received by object reference.
[0025]
Next, details of the processing using the above-described system will be described based on the flowcharts of FIGS. FIG. 3 is a flowchart showing an outline of the entire processing, and FIGS. 4 to 7 describe one step included in the flowchart of FIG. 3 in more detail.
[0026]
Upon receiving a processing request from a client, the processing request controller 1a in the server 1 generates a container corresponding to the processing request in the memory space of the server 1 (step S1). In step S2, the processing request controller 1a decomposes the processing request into processing elements suitable for distributed processing and sets them.
[0027]
The processing request controller 1a sorts these processing elements in the processing order and creates a sort table. The key to sorting the processing elements is the processing order object. Hereinafter, the processing elements are managed by this sort table.
[0028]
The processing order is managed by an n-dimensional array of positive integers. An empty number is searched for from the low number of dimensions, and if found, the number increased in the same dimension is adopted. If the number to be increased is duplicated, the dimension is increased to avoid duplication. When a new processing request is input, the processing elements are given an integer processing order “0, 1, 2, 3,..., N” starting from 0. When a new processing element is added by evaluating the processing result of the processing element, the processing order is added by interrupting the processing in the middle. For example, when a new processing element is added between “2” and “3”, the added number is “2.0”. Further, when a new processing element is added between “2.0” and “3”, the number to be added is “2.1”, and between “2.0” and “2.1”. If it is added, it will be "2.0.1." However, the past order cannot be changed, and for example, it cannot be added between “2” and “2.0”. Further, each processing element has information shown in Table 1 below.
[0029]
[Table 1]
[0030]
The input information is provided by the client if the processing element is processed first, and when the output of the processing element executed at a stage earlier than the processing element is used as input, the previous processing is performed. Written when the element is successfully completed. The output information is recorded as a processing result after the processing element is executed. Further, the service property is recorded by extracting a service program by the service resolver 6 using the service search condition as a key, and includes a list of the extracted service programs. The list includes each service program. A history of whether or not execution has already been performed is also included. The list of service programs in the service property is sorted and managed according to the service evaluation function. The processing element also has information on whether the processing element is being processed, has been processed, or has not been processed.
[0031]
All processing elements in the unexecuted processing request are in an unprocessed state. For the processed elements that have been processed, the storage location of the processing result is recorded in the output information. Since the processing elements are sorted in the processing order, the sort table may be searched in the processing order, and the unprocessed processing elements that appear first may be executed in order.
[0032]
In step S3, the reference position of the sort table that defines the processing order of the processing elements is initialized. The processing of step S4 and subsequent steps is for executing processing for all processing elements included in the processing request. First, in step S4, an executable processing element is acquired from the processing elements stored in the container with reference to the sort table. Details of the processing in step S4 will be described later.
[0033]
In step S5, the processing element controller 1b determines whether the processing element has been acquired in the processing in step S4. When the processing element is obtained, the obtained processing element is allocated to each service program on the network, and the distributed processing is executed (step S6), and the processing element controller evaluates the processing result of the processing element (step S6). S7). As a result of the evaluation, when it is determined that the service program has ended normally (step S8, Yes), the process returns to step S4 to acquire the next processing element. If it is determined that the process has not been completed normally due to some abnormality (step S8, No), a retry of the process is attempted in step S9, and if possible, the process returns to step S6 to repeat the process.
[0034]
If it is determined in step S5 that no processing element has been acquired, it is determined in step S10 whether all processing elements have been processed. If all processing has been completed, processing results obtained for each processing element are integrated, and a response is sent to the client (step S11). Subsequently, in step S12, it is determined whether or not the response satisfies the client's request and approval is obtained. If the approval is obtained, the process for the processing request is normally completed, and the information included in the container is deleted. Clear all. If the approval is not obtained, the processing from step S2 is repeated.
[0035]
If it is determined in step S9 that a processing element that has not been processed is included, it is determined in step S13 whether there is a processing element being executed. If there is a processing element being executed (step S13, Yes), the process returns to step S4 to repeat the processing. On the other hand, if there is no processing element that is being executed even though a processing element that has not been processed is included (step S13, No), it is determined that a failure that cannot be avoided has occurred, and the client determines in step S14. Is notified that execution is not possible, and terminates abnormally.
[0036]
With the above processing, if no failure occurs, distributed processing can be performed for all processing elements using the service program connected to the network, and a response can be given to the processing request requested by the client.
[0037]
Next, details of the “processing element acquisition” processing in step S4 will be described based on the flowchart of FIG. Here, a sort table (prepared in S2) that defines the processing order of the processing elements is used, the states of the processing elements are sequentially checked from the positions of the unprocessed processing elements in the sort table, and the executable processing elements are determined. Take out. The executable conditions are (1) the state of the processing element is unprocessed, and (2) the input data of the processing element exists. It is possible to determine whether or not the condition (2) is satisfied by checking the input information in Table 1. The reason for satisfying the condition (2) is that the input data of the processing element exists as a processing result of (2-1) another processed processing element, or (2-2) is executed first. This is a case where the data exists as input data of the processing element. The check in (2-1) is executed by searching output data of processed processing elements in the reverse order of execution, that is, in order from the element processed immediately before.
[0038]
In step S101, the processing element controller 1b checks the state of the processing element corresponding to the processing order of the reference position in the sort table. In step S102, it is determined whether or not the processing element checked by the processing element controller 1b has not been processed, that is, whether or not the above condition (1) is satisfied. If not, the process proceeds to step S103. If not, the process proceeds to step S106.
[0039]
When an unprocessed processing element is found, it is determined in step S103 whether input data of the processing element exists, that is, whether the above condition (2) is satisfied (step S104). If input data exists, the process proceeds to step S105. If not, step S105 is skipped and the process proceeds to step S106.
[0040]
In step S105, the processing element is acquired as an executable element and passed to the processing element controller 1b. In step S106, the reference position of the sort table is advanced, and in step S107, it is determined whether the reference position has reached the end of the table, that is, whether or not all the processing elements in the sort table have been checked. If the end of the sort table has not been reached, the process returns to step S101 to repeat the processing. If the end of the sort table has been reached, the process returns to the flowchart of FIG.
[0041]
By the processing element acquisition processing of FIG. 4, the processing request controller searches for the leading position of the unprocessed processing element in the sort table, extracts all executable processing elements from the processing elements after the processing element, and performs processing. Can be passed to the element controller.
[0042]
Next, the details of the process of “executing the processing element” in step S6 of FIG. 3 will be described based on the flowchart of FIG.
When processing elements that can be executed are acquired in the “processing element acquisition” processing in step S4, the processing element controller 1b executes all the acquired processing elements in parallel. That is, a thread is assigned to each processing element, and parallel processing is performed by multi-thread.
[0043]
In step S201, the processing element controller checks whether a service property exists in the processing element to be executed, and determines in step S202. If there is no service property, that is, if a service program has not been searched for by the service resolver 6 for the processing element, a service property is searched for in step S203.
[0044]
The search processing in step S203 includes the following steps (1) to (8).
(1) Obtain a service search condition from a processing element.
(2) Search the service resolver 6 (UDDI registry) using the acquired site name and service name of the service search condition as keys. The search result is obtained as the location (URL format) of the WSDL file in which the details of the service meeting the search conditions are described.
(3) One service property object is generated for each search result.
(4) Add the created service property object to the service information.
(5) The service information manages the added service property object with a priority according to the service evaluation function.
(6) The processing element controller fetches the service property, transfers a WSDL file in which the details of the service are described from the fetched service property from the actual computer, and reads and interprets the contents of the file.
(7) The following items are acquired as a result of the interpretation, and the acquired information is set in the service property.
-Execution destination host name
・ Command name to be executed, command arguments
-Type, number, and order of files to be input by the command
-Command output results
-Type and number of data for each output means (for example, error output, standard output, file output, etc.)
(8) The evaluation value for the information of the set service property is calculated and added, and the priority order of the service is updated.
[0045]
Using the service information acquired in step S203, or when it is determined in step S202 that the service property exists, the subsequent processing is executed using the already registered service information. In step S204, the processing element controller 1b acquires a service property related to a service program to be executed from the service information. The acquired service properties are related to the service program with the highest priority, except for those having a history of past execution.
[0046]
In step S205, it is determined whether or not the service property has been acquired in step S204. If the service property has not been acquired, an error is notified to the client in step S206 as "executable", and the process ends abnormally. If the service property has been acquired, an execution history is added to the service property acquired in step S204 (step S207).
[0047]
Subsequently, in step S208, the processing element controller 1b transfers the input file set in the service property to the computer on which the selected service program is executed. In step S209, an execution destination and a command to be executed are acquired from the service property, and a process is requested to the execution destination computer. Then, in step S210, the state of the processing element is set to "executing". It is checked in step S211 whether there is any abnormality in the processing in steps S207 to S210. If an abnormality occurs, the process returns to the flowchart in FIG. 3 via the error processing in step S212. The error process in step S212 is a process of adding a failure history to the service property and deleting unnecessary data.
[0048]
In step S213, the processing element controller 1b evaluates the execution state of the service program using the service evaluation function, and controls the continuation / stop of the service program executed in accordance with the evaluation function in step S214. In the case of cancellation, the error processing of step S212 is executed. For example, if the processing time is specified as an evaluation function, the processing time is evaluated. If the processing time exceeds a predetermined time, the service program is stopped and error processing is executed.
[0049]
When the processing element controller detects the end of the service program in step S215, the processing element controller acquires the end code of the service program, and determines in step S216 whether the end code indicates a normal end. If the end code indicates a normal end, the process returns to the flowchart of FIG. 3 after executing the error processing of step S212 if it does not indicate the normal end.
[0050]
Next, details of the processing of “evaluation of processing result” in step S7 of FIG. 3 will be described based on the flowchart of FIG. In step S301, the processing element controller 1b checks a processing result output from the service program with output information of the service property. Next, in step S302, it is determined whether or not there is any contradiction between the two information. Specifically, it is determined whether or not there is any inconsistency based on whether or not the data type and the number of data described in the output information of the service property match the actual processing result. If there is no inconsistency, it is determined that the processing has been executed normally.
[0051]
If it is determined in step S302 that there is a contradiction, it is determined whether the output data includes a WDSL file describing a processing element (step S303). The presence of a WDSL file in the output data means that a processing element needs to be added. Therefore, in this case, the processing request controller 1b adds a new processing element in the container 1c (step S304), and determines that the processing element has been completed normally.
[0052]
If the WSDL file does not exist in step S303, it is determined that the processing element did not end normally, and the same error processing as in step S212 is executed (step S305), and the process returns to the flowchart in FIG. In this case, it is determined that another service program is required instead of the service program selected to execute the processing element, and another service program is selected in step S9 to continue the processing of the processing element. I do.
[0053]
If it is determined that the processing element that has been executed has ended normally, the result output from the corresponding service program is registered in the output information of the processing element for each data type (step S306), and the processing element controller 1b sets the processing state of the processing element to "executed" (step S307), and returns to the flowchart of FIG.
[0054]
Next, the details of the “retry process” in step S9 in FIG. 3 will be described with reference to the flowchart in FIG. This processing is for providing an alternative service program and executing a processing element when the processing of steps S6 and S7 is not completed normally, that is, when the error processing of step S212 or step S305 is passed. Processing.
[0055]
First, in step S401, the state of the processing element to be processed is returned from "processing" to "unprocessed". Subsequently, in step S402, the processing elements that have been executed are referred to by one in the execution order with reference to the sort table (the reference position is returned by one), and the reference position does not reach the beginning of the sort table, and there is a processing element that goes back. If so (step S403, No), the state of the processing element traced back is changed to unexecuted (step S404). These three steps S402 to S404 are repeated until a branch processing element that can be retried (re-executed) is found.
[0056]
Whether or not retry can be performed is determined by whether or not there is a property related to a service program having no execution history (unexecuted) in the service properties of the processing element. If there is a service property of a service program having no execution history, it is determined that retry is possible. If a processing element that can be retried is found, the process returns to the flowchart of FIG. 3, and in step S6, the processing is re-executed from the processing element using a service program defined by the service property that has not been executed.
[0057]
If there is no processing element that reaches the beginning of the sort table and traces back before finding a processing element that can be retried (step S404, Yes), it is determined that the processing request cannot be executed, and the client executes “execute” in step S406. "Not possible" and terminate abnormally.
[0058]
Next, when extracting and selecting a service program, a specific example is given as to how much the service information of the processing element and the information on the UDDI or the information described in the WSDL file match if it is determined that they match. Will be explained.
[0059]
First, in the service property search in S203, when the service name defined in the service condition of the processing element is “AB”, what kind of service name registered in the UDDI is determined to match is shown in Table 2. Shown in The symbol “x” in the table indicates that the service is not extracted, and “○” indicates that the service is extracted.
[0060]
[Table 2]
[0061]
Next, when the input / output condition of the service program is “AB” when the WSDL file is read, and what kind of condition is the service search condition of the processing element, the table shows whether the condition is determined to match. 3 is shown. In the table, the symbol “◎” indicates that the data has the highest priority and is determined to match, “○” indicates that the data matches when there is no “◎”, and “△” indicates “◎” and “○” "" Indicates that they do not match, and "x" indicates that they do not match.
[0062]
[Table 3]
[0063]
Subsequently, when searching for processing elements one by one in the processing of FIG. 7, when the input schedule is “AB”, what processing element with a track record in the service property can be retried in S405 (data Table 4 shows whether or not to judge (match). The meanings of the symbols are the same as in Table 3.
[0064]
[Table 4]
[0065]
【The invention's effect】
As described above, according to the present invention, the service program of the request destination is dynamically determined using the registry. Therefore, even when a failure occurs in the provider or the network, the distributed processing is executed while avoiding the failure. It is possible to solve the problem requested by the client safely and reliably.
[0066]
Also, if the selected service program does not return a response that fully satisfies the request, and if some of the responses are available, add new processing elements and insert additional service programs. By processing the answer into a format that matches the request, the answer can be sent to the client without stopping the entire process.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a system configuration of a distributed information processing system according to an embodiment of the present invention.
FIG. 2 is a conceptual diagram showing the operation of the distributed information processing system of FIG.
FIG. 3 is a flowchart illustrating an outline of a process using the distributed information processing system according to the embodiment;
FIG. 4 is a flowchart showing details of processing element acquisition in FIG. 3;
FIG. 5 is a flowchart detailing the execution of the processing elements of FIG. 3;
FIG. 6 is a flowchart showing in detail the evaluation of the processing elements of FIG. 3;
FIG. 7 is a flowchart showing details of a retry of the processing in FIG. 3;
[Explanation of symbols]
1 server
1a Processing request controller
1b Processing element controller
1c container
2 Service Provider
3 Internet
4 clients
5 LAN
6 Service resolver
