(57)【要約】【課題】選択されたサービスプログラムが要求を完全に満たす回答を返さない場合にも、処理全体を中止することなくクライアントに回答することができる分散処理システムを提供すること。【解決手段】クライアントから処理依頼がコンテナに入力されると、処理依頼コントローラ１ａが処理依頼から処理要素を取得し、処理要素コントローラが処理要素から検索条件を受けてサービスリゾルバ６に対して処理要素を処理するために適したサービスプログラムを抽出させる。抽出されたサービスプログラムから最適なものを選択し、処理要素の処理をサービスプログラムに依頼し、処理結果を評価する。処理結果が処理要素の出力形式を満たさない場合、処理要素コントローラはサービスプログラムの処理結果を、このサービスプログラムにより処理された先の処理要素の出力形式に一致させるための新たな処理要素を追加する。【選択図】  図２
2004287803.tif 000002
【特許請求の範囲】
【請求項１】
サービスプログラムを提供するサービスプロバイダと、複数のサービスプログラムの仕様が登録されて依頼される処理内容に対応するサービスプログラムを抽出するレジストリと、前記サービスプログラムを利用して分散処理サービスを提供する分散システム制御手段と、前記分散処理サービスを利用するクライアントとがネットワークを介して接続される分散コンピューティング環境における分散型情報処理システムにおいて、
前記分散システム制御手段は、前記クライアントからの処理依頼を受けると、当該処理依頼を解決するために必要な処理要素を取り出して各処理要素について処理内容をキーにして前記レジストリを検索し、適切なサービスプログラムを前記レジストリから抽出し、抽出されたサービスプログラムから適当なプログラムを選択して処理要素の処理を依頼し、依頼した処理要素の処理結果を評価し、評価結果が依頼の要件を満足する場合には当該処理要素に関する処理を終了し、一部満足しない場合には実行されたサービスプログラムの処理結果を入力とする新たな処理要素を追加して新たに抽出された他のサービスプログラムに追加された処理要素の処理を依頼し、全部満足しない場合には先の処理要素の処理を他のサービスプログラムに代替して処理させ、全ての処理要素の評価結果が依頼の要件を満足した場合に、これらの処理結果を統合して前記処理依頼に対する回答を前記クライアントに示すことを特徴とする分散型情報処理システム。
【請求項２】
前記分散システム制御手段は、前記クライアントからの処理依頼を解決するためのあらゆるオブジェクトを保持するコンテナを備え、当該コンテナ内で前記処理要素の処理、評価が実行されることを特徴とする請求項１に記載の分散型情報処理システム。
【請求項３】
前記ネットワークはインターネットであり、前記レジストリは、インターネット上に散在するサービスプログラムに関する情報を格納するＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）であることを特徴とする請求項１または２に記載の分散型情報処理システム。
【請求項４】
前記分散システム制御手段が前記レジストリからサービスプログラムを抽出する際には、ＷＳＤＬ（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）ファイルのファイル名を受け取り、前記分散システム制御手段は、前記ファイル名に基づいてＷＳＤＬファイルを取得して適切なサービスプログラムを選択することを特徴とする請求項３に記載の分散型情報処理システム。
【請求項５】
前記分散システム制御手段は、前記処理要素を実行したサービスプログラムから処理結果と共にＷＳＤＬファイルが返送された場合に、評価結果が依頼の要件を一部満足しないと判断し、新たな処理要素を追加することを特徴とする請求項４に記載の分散型情報処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上に複数のサービスプログラムが提供される分散コンピューティング環境を利用してクライアントが要求する処理を実行する分散情報処理システムに関する。
【０００２】
【従来の技術】
分散情報処理システムは、クライアントから要求された処理を複数の処理要素に分割し、分割した各処理要素をネットワークを介して適切なサービスプログラムに送信し、サービスプログラムから返信された結果を統合してクライアントに要求された処理の結果を回答する。例えば、気象情報の処理に関する分散型処理システムとして特許文献１がある。
【０００３】
【特許文献１】特開２００１−２０８８６２号公報  図３
【０００４】
【発明が解決しようとする課題】
しかしながら、上述した従来の分散処理システムでは、分割された各処理要素の処理をネットワーク上のどのサービスプログラムに依頼するか、および、各処理要素をどのような順番で実行するかは全体を制御する分散管理システムにより予め決定されており、実行途中で依頼先、処理順序を変更することは困難である。したがって、依頼先のサービスプログラムを格納するコンピュータやネットワークに障害が発生したり、処理の実行中に分散環境が変化した場合（例えば依頼するはずのサービスプロバイダのＵＲＬが変更される等）に、依頼先を動的に変更することも困難である。
【０００５】
本発明は、上記の従来技術の課題に鑑み、分散コンピューティング環境において、依頼先、処理順序を予め決定しなくともユーザの要求する処理を確実に実行して回答することができる分散型情報処理システムを提供することを目的とする。
【０００６】
【課題を解決するための手段】
本発明にかかる分散型情報処理システムは、上記の目的を達成させるため、サービスプログラムを提供するサービスプロバイダと、複数のサービスプログラムの仕様が登録されて依頼される処理内容に対応するサービスプログラムを抽出するレジストリと、サービスプログラムを利用して分散処理サービスを提供する分散システム制御手段と、分散処理サービスを利用するクライアントとがネットワークを介して接続される分散コンピューティング環境を前提として、分散システム制御手段は、クライアントからの処理依頼を受けると、当該処理依頼を解決するために必要な処理要素を取り出して各処理要素について処理内容をキーにしてレジストリを検索し、適切なサービスプログラムをレジストリから抽出し、抽出されたサービスプログラムから適当なプログラムを選択して処理要素の処理を依頼し、依頼した処理要素の処理結果を評価し、評価結果が依頼の要件を満足する場合には当該処理要素に関する処理を終了し、一部満足しない場合には実行されたサービスプログラムの処理結果を入力とする新たな処理要素を追加して新たに抽出された他のサービスプログラムに追加された処理要素の処理を依頼し、全部満足しない場合には先の処理要素の処理を他のサービスプログラムに代替して処理させ、全ての処理要素の評価結果が依頼の要件を満足した場合に、これらの処理結果を統合して処理依頼に対する回答をクライアントに示すことを特徴とする。
【０００７】
上記のシステムによれば、依頼先のサービスプログラムがレジストリを用いて動的に決定されるため、プロバイダやネットワークに障害が発生した場合にも、それを避けて分散処理を実行することができ、安全、確実にクライアントに依頼された課題を解決することができる。
【０００８】
なお、上記のように依頼先を検索結果に基づいて動的に決定する場合、選択されたサービスプログラムが要求を完全に満たす回答を返さない場合が想定される。例えば、１つのサービスプログラムの処理結果を次のサービスプログラムの入力とする場合に、先のサービスプログラムの出力が次のサービスプログラムの入力の形式を満たさない場合である。このような場合に、先のサービスプログラムによる処理をエラーとして処理全体を中止すると、クライアントは求める回答を得ることができず、新たに処理要求を出し直さなければならない。
【０００９】
本発明のシステムでは、選択されたサービスプログラムが要求を完全に満たす回答を返さない場合にも、回答が一部利用できる場合には、新たな処理要素を追加して他のサービスプログラムを追加的に挿入して回答を要求に合致した形式に加工することにより、処理全体を中止することなく、クライアントに回答することができる。
【００１０】
上記の分散システム制御手段に、クライアントからの処理依頼を解決するためのあらゆるオブジェクトを保持するコンテナを備えさせることができる。この場合には、当該コンテナ内で処理要素の処理、評価を実行することができる。
【００１１】
ネットワークがインターネットでありる場合、レジストリとしては、インターネット上に散在するサービスプログラムに関する情報を格納するＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ）を利用することができる。ＵＤＤＩを利用する場合には、分散システム制御手段がレジストリからサービスプログラムを抽出する際には、ＷＳＤＬ（Ｗｅｂ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ）ファイルのファイル名を受け取り、分散システム制御手段は、ファイル名に基づいてＷＳＤＬファイルを取得して適切なサービスプログラムを選択することとなる。また、分散システム制御手段は、処理要素を実行したサービスプログラムから処理結果と共にＷＳＤＬファイルが返送された場合に、評価結果が依頼の要件を一部満足しないと判断し、新たな処理要素を追加するようにしてもよい。
【００１２】
【発明の実施の形態】
以下、この発明にかかる分散型情報処理システムの実施形態を説明する。最初に、図１により実施形態の分散型情報処理システムのシステム構成について説明する。なお、実施形態のシステムは、グリッド・コンピューティングの技術を使って複数のデータベースを検索するものである。グリッド・コンピューティングは、ネットワーク上のサーバやストレージ、データベース、アプリケーションなどのさまざまな資源をグリッドの一点（コンピュータ・グリッド）とし、これらを相互に結んだひとつの巨大なコンピュータとして捉えたものである。
【００１３】
実施形態のシステムは、分散システム制御手段として分散コンピューティング環境を利用してクライアントからの処理依頼を解決するサーバ１と、各種のサービスプログラムを提供する複数のサービスプロバイダ２と、これらのサーバ１とサービスプロバイダ２とが接続される広域ネットワークとしてのインターネット３とを含む。クライアント４は、この例ではサーバ１に対してローカルエリアネットワーク（ＬＡＮ）５を介して接続されている。ただし、クライアント４もインターネット３を介して接続されてもよい。
【００１４】
サーバ１は、クライアントからの処理依頼を受け付けてクライアントに回答するまでの全体の処理の流れを制御する処理依頼コントローラ１ａと、処理依頼を解決するために必要な処理要素の実行を制御する処理要素コントローラ１ｂとを含む。処理依頼は、クライアントが解決を求める課題であり、通常複数の処理要素に分けて考えることができる。処理要素は、一連の処理の中で、分散された環境で実際にサービスプログラムによって処理される単位である。
【００１５】
また、サーバ１のメモリ空間には、クライアント４からの処理依頼を受けると図中破線で示すコンテナ１ｃが生成される。コンテナ１ｃは、処理依頼に含まれる処理要素オブジェクトをもとに実行に関連する全てオブジェクトを集約する。
【００１６】
一方、インターネット３には、複数のサービスプログラムＳＰの仕様が登録されて依頼される処理内容に対応するサービスプログラムを抽出するサービスリゾルバ６が接続されている。サービスリゾルバ６は、ＵＤＤＩを利用したレジストリであり、インターネット上に散在するサービスプログラムに関する情報を格納している。
【００１７】
図２は、上記の分散型情報処理システムの作動を示す概念図である。図２では、サービスプロバイダ２をまとめてＧｒｉｄ  Ｐｒｏｘｙとして記載している。クライアントから処理依頼がコンテナに入力されると、サーバ１の処理依頼コントローラ１ａが処理依頼から処理要素を取得してコンテナ内に設定する。処理要素コントローラ１ｂは、処理要素から検索条件を受けると、サービスリゾルバ６に対して処理要素を処理するために適したサービスプログラムを抽出するよう「サービス検索」の指示を出す。
【００１８】
サービスリゾルバ６は、その処理要素を解決するために適したサービスプログラムに関する検索結果をＷＳＤＬファイル名のリストとして返してくる。ＷＳＤＬとは、Ｗｅｂサービスを用いるときに必要なＷｅｂサービスの仕様を記述するためのＸＭＬ形式で記述された仕様である。１つの処理に対して複数のサービスプログラムが抽出される場合もあり、その場合にはサービスプログラム毎に１つのＷＳＤＬファイル名（ＵＲＬ）が提供される。
【００１９】
処理要素コントローラ１ｂは、当該処理要素に適したサービスプログラムを選択するため、ＷＳＤＬファイル名に基づいてＷＳＤＬファイルを取得し、解析する。ＷＳＤＬファイルには、サービスプログラムを提供しているホスト名（ＵＲＬ）、具体的なプログラム名、入力ファイル名、出力ファイル名等の情報が記述されている。１つずつＷＳＤＬファイルを開き、サービスプログラムの入出力形式をチェックして、処理要素に対して必要な結果が得られるか否かを判断し、どのサービスプログラムが最適かを判断する。なお、サービスプログラムの選択に当たっては、処理内容のみでなく、ネットワークの混雑等の要因も考慮に入れることが好ましい。
【００２０】
最適なサービスプログラムが選択されると、処理要素コントローラ１ｂが処理要素の処理をサービスプログラムに依頼する。すなわち、処理要素の入力データをＧｒｉｄ  Ｐｒｏｘｙに転送すると共に、サービスプログラムの実行を依頼する。サービスプログラムから処理結果が返ると、この処理結果は処理要素に設定されると共に、処理要素コントローラ１ｂにより評価される。
【００２１】
評価の結果、処理要素の出力形式を満たす処理結果をサービスプログラムが出力した場合には、当該処理要素については処理済みとして未処理の処理要素を同様にして抽出、選択したサービスプログラムに渡して処理を実行する。
【００２２】
一方、サービスプログラムの処理結果が当該処理要素の出力形式を満たさない場合には、サービスプログラム側から出力形式がどのように満たされていないかを記述したＷＳＤＬファイルが発行される。処理要素コントローラ１ｂは、このファイルが返ってきたときには、サービスプログラムの処理結果を、このサービスプログラムにより処理された先の処理要素の出力形式に一致させるための処理要素を追加する。追加される処理要素は、単一の場合も複数の場合もあり得る。
【００２３】
なお、サービスプログラムが処理結果を返さない場合、例えば各サービス側でプログラムが停止したり、ネットワークが切断された場合には、このサービスプログラムへの依頼を撤回して他の候補に代替させる。処理依頼コントローラー側でタイマー監視をしている場合には、例えば通常３分で応答があるものが１時間経っても応答がない場合には、依頼を撤回してもよい。
【００２４】
また、実施形態では、グリッド・コンピューティングの技術を使い分散システムを実装しているため、ＵＤＤＩやＷＳＤＬを用いているが、ＣＯＲＢＡ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒｅ）技術を用いる場合には、ネーミングサービスへ問い合わせ結果をオブジェクトリファレンスで受けることになる。
【００２５】
次に、上記のシステムを利用した処理の詳細を図３〜図７のフローチャートに基づいて説明する。図３は処理全体の概略を示すフローチャートであり、図４〜図７は、図３のフローチャートに含まれる１つのステップをより詳細に説明したものである。
【００２６】
クライアントから処理依頼を受け取ると、サーバ１内の処理依頼コントローラ１ａは、サーバ１のメモリ空間に当該処理依頼に対応したコンテナを生成する（ステップＳ１）。ステップＳ２では、処理依頼コントローラ１ａは、処理依頼を分散処理に適した処理要素に分解して設定する。
【００２７】
処理依頼コントローラ１ａは、これらの処理要素を処理する順番でソーティングしてソートテーブルを作成する。処理要素をソーティングするキーとなるのが、処理順番オブジェクトである。以下、処理要素はこのソートテーブルにより管理される。
【００２８】
処理順番は、正の整数のｎ次元配列で管理される。次元数の低いところから番号の空きを探し、見つかれば、同じ次元で番号を増やしたものを採用し、増やそうとした番号が重複する場合には次元を増やし重複を回避する。新規に処理依頼が入力された場合、処理要素には０から始まる整数の処理順番「０，１，２，３，…，ｎ」が付される。処理要素の処理結果を評価して新たな処理要素が追加される場合には、順番の途中に割り込んで処理順番が追加される。例えば「２」と「３」の間に新たに処理要素を追加する場合、追加される番号は「２．０」となる。さらに、「２．０」と「３」との間に新たな処理要素を追加する場合、追加される番号は「２．１」となり、「２．０」と「２．１」の間に加える場合には「２．０．１」となる。ただし、過去の順序は変更できず、例えば「２」と「２．０」との間には追加することはできない。さらに、各処理要素は、以下の表１に示す情報を備えている。
【００２９】
【表１】
2004287803.tif 000003
【００３０】
入力情報は、当該処理要素が最初に処理されるものであれば、クライアントから与えられており、当該処理要素より前段階で実行される処理要素の出力を入力として用いる場合には、先の処理要素が正常に終了した段階で書き込まれる。また、出力情報は、当該処理要素が実行された後に処理結果として記録される。さらに、サービスプロパティは、サービス検索条件をキーにしてサービスリゾルバ６によりサービスプログラムを抽出することにより記録されるものであり、抽出されたサービスプログラムのリストを含み、このリストには、各サービスプログラムを既に実行したか否かの履歴も含まれる。サービスプロパティ内のサービスプログラムのリストは、サービス評価関数に従いソートされて管理されている。なお、処理要素は、当該処理要素が処理中なのか、処理済なのか、未処理なのかの情報も有している。
【００３１】
未実行の処理依頼内の処理要素は、全て未処理状態となっている。また、処理済みの処理要素については、処理結果の保存場所が出力情報に記録されている。処理要素は処理順にソートされているため、ソートテーブルを処理順に検索して最初に出現した未処理の処理要素から順番に実行していけばよい。
【００３２】
ステップＳ３では、処理要素の処理順番を規定するソートテーブルの参照位置が初期化される。ステップＳ４以下の処理は、処理依頼に含まれる全ての処理要素について処理を実行するためのものである。まず、ステップＳ４では、ソートテーブルを参照してコンテナに格納された処理要素から実行可能な処理要素を取得する。ステップＳ４の処理の詳細については後述する。
【００３３】
ステップＳ５では、処理要素コントローラ１ｂが、ステップＳ４の処理で処理要素を取得したか否かを判断する。処理要素が取得された場合には、取得された処理要素をそれぞれネットワーク上のサービスプログラムに割り当て、分散処理を実行し（ステップＳ６）、処理要素コントローラが処理要素についての処理結果を評価する（ステップＳ７）。評価の結果、サービスプログラムが正常に終了したと判断される場合（ステップＳ８，Ｙｅｓ）には、ステップＳ４に戻って次の処理要素を取得する。何らかの異常があって正常終了しなかったと判断された場合（ステップＳ８，Ｎｏ）には、ステップＳ９において処理のリトライを試みて、可能であればステップＳ６に戻って処理を繰り返す。
【００３４】
ステップＳ５で処理要素が取得されなかったと判断された場合には、ステップＳ１０で全ての処理要素が処理済みか否かを判断する。全て処理済みであれば、各処理要素について得られた処理結果を統合して回答をクライアントに送る（ステップＳ１１）。続いて、ステップＳ１２では、回答がクライアントの要求を満たして承認が得られるか否かを判断し、承認が得られれば、当該処理依頼についての処理を正常に終了し、コンテナに含まれる情報を全てクリアする。承認が得られなければ、ステップＳ２からの処理を繰り返す。
【００３５】
ステップＳ９で処理済みではない処理要素が含まれると判断された場合には、ステップＳ１３で実行中の処理要素があるか否かを判断する。実行中の処理要素が存在する場合（ステップＳ１３，Ｙｅｓ）には、ステップＳ４に戻って処理を繰り返す。一方、処理済みではない処理要素が含まれるにもかかわらず、実行中の処理要素が存在しない場合（ステップＳ１３，Ｎｏ）には、回避が不能な障害が発生したと判断し、ステップＳ１４でクライアントに「実行不能」であることを通知して異常終了する。
【００３６】
以上の処理により、障害が発生しなければ、全ての処理要素についてネットワークに接続されたサービスプログラムを用いて分散処理を行い、クライアントが要求する処理依頼に対して回答を与えることができる。
【００３７】
次に、上記のステップＳ４の「処理要素取得」処理の詳細を図４のフローチャートに基づいて説明する。ここでは、処理要素の処理順序を規定するソートテーブル（Ｓ２で作成）を利用し、ソートテーブル内の未処理の処理要素の位置から順番に処理要素の状態を確認し、実行可能な処理要素を取り出す。実行可能な条件は、（１）処理要素の状態が未処理であること、そして（２）処理要素の入力データが存在することである。（２）の条件は、表１の入力情報をチェックすることにより満たすか否かを判断できる。（２）の条件を満たすのは、その処理要素の入力データが、（２−１）他の処理済の処理要素の処理結果として存在するか、あるいは、（２−２）最初に実行されれる処理要素の入力データとして存在する場合である。（２−１）のチェックは、処理済みの処理要素の出力データを実行された順とは逆順で、すなわち、直前に処理された要素から順に検索して実行される。
【００３８】
ステップＳ１０１では、処理要素コントローラ１ｂがソートテーブルの参照位置の処理順番に該当する処理要素の状態をチェックする。ステップＳ１０２では、処理要素コントローラ１ｂによりチェックされた処理要素が未処理であるか否か、すなわち上記の条件（１）を満たすか否かが判定される。未処理であればステップＳ１０３に進み、未処理でなければステップＳ１０６に進む。
【００３９】
未処理の処理要素が発見されると、ステップＳ１０３においてその処理要素の入力データが存在するか否か、すなわち上記の条件（２）を満たすか否かが判定される（ステップＳ１０４）。入力データが存在すればステップＳ１０５に進み、存在しなければステップＳ１０５をスキップしてステップＳ１０６に進む。
【００４０】
ステップＳ１０５では、当該処理要素を実行可能な要素として取得し、処理要素コントローラ１ｂに渡す。ステップＳ１０６では、ソートテーブルの参照位置を進め、ステップＳ１０７では参照位置がテーブルの最後に達したか、すなわち、ソートテーブル内の処理要素のチェックが全て終了したか否かを判断する。ソートテーブルの最後に達していなかったら、ステップＳ１０１に戻って処理を繰り返し、ソートテーブルの最後に達していたら、図３のフローチャートにリターンする。
【００４１】
図４の処理要素取得処理により、処理依頼コントローラは、ソートテーブル内の未処理の処理要素の先頭位置を探し、その処理要素から後の処理要素のうち、実行可能な処理要素を全て取り出して処理要素コントローラに渡すことができる。
【００４２】
次に、図３のステップＳ６の「処理要素の実行」の処理の詳細を図５のフローチャートに基づいて説明する。
ステップＳ４の「処理要素取得」処理で実行可能な処理要素が取得されると、処理要素コントローラ１ｂは、取得された処理要素を全て並列に実行する。すなわち、処理要素ごとにスレッドをあてがいマルチスレッドで並行処理する。
【００４３】
ステップＳ２０１では、処理要素コントローラは実行される処理要素にサービスプロパティが存在するか否かを確認し、ステップＳ２０２で判断する。サービスプロパティが存在しない場合、すなわち、当該処理要素について未だサービスリゾルバ６によりサービスプログラムを検索してない場合には、ステップＳ２０３においてサービスプロパティを検索する。
【００４４】
ステップＳ２０３の検索処理は、以下の（１）〜（８）段階を含む。
（１）処理要素からサービス検索条件を取得する。
（２）取得したサービス検索条件のサイト名、サービス名をキーにサービスリゾルバ６（ＵＤＤＩレジストリ）を検索する。検索結果は検索条件にあったサービスの詳細が記述されたＷＳＤＬファイルの存在場所（ＵＲＬ形式）として得られる。
（３）検索結果一件毎にサービスプロパティオブジェクトを１つ生成する。
（４）作成したサービスプロパティオブジェクトをサービス情報に加える。
（５）サービス情報は加えられたサービスプロパティオブジェクトをサービス評価関数に従い優先度を付けて管理する。
（６）処理要素コントローラはサービスプロパティを取り出し、取り出したサービスプロパティからサービスの詳細が記述されているＷＳＤＬファイルを実在するコンピュータから転送し、ファイルの内容読み込み解釈する。
（７）解釈した結果として以下の項目を取得し、取得した情報をサービスプロパティに設定する。
・実行先のホスト名
・実行するコマンド名、コマンド引数
・コマンドの入力するファイルの種類、数、並び順
・コマンドの出力する結果
・出力する手段（例えば、エラー出力、標準出力、ファイル出力等）ごとのデータの種類、数
（８）設定されたサービスプロパティの情報分の評価値を算出して加点し、サービスの優先度順を更新する。
【００４５】
ステップＳ２０３で取得されたサービス情報を使い、若しくは、ステップＳ２０２でサービスプロパティが存在すると判断された場合にはすでに登録されているサービス情報を使い、以降の処理を実行する。ステップＳ２０４では、処理要素コントローラ１ｂがサービス情報から実行すべきサービスプログラムに関するサービスプロパティを取得する。取得されるサービスプロパティは、過去に実行された履歴が存在するものを除いて、優先順位が一番高いサービスプログラムに関するものである。
【００４６】
ステップＳ２０５では、ステップＳ２０４でサービスプロパティが取得できたか否かを判断し、取得できなかった場合にはエラーとしてステップＳ２０６でクライアントに「実行不能」を通知して異常終了する。サービスプロパティを取得できた場合には、ステップＳ２０４で取得したサービスプロパティに実行の履歴を追加する（ステップＳ２０７）。
【００４７】
続いて、処理要素コントローラ１ｂは、ステップＳ２０８において、サービスプロパティに設定されている入力ファイルを、選択されたサービスプログラムが実行されるコンピュータへ転送する。ステップＳ２０９では、サービスプロパティから実行先と実行するコマンドを取得し、実行先のコンピュータへ処理を依頼する。そして、ステップＳ２１０では当該処理要素の状態を「実行中」にする。ステップＳ２０７〜２１０の処理に異常がないか否かをステップＳ２１１でチェックし、異常が生じた場合にはステップＳ２１２のエラー処理を経て図３のフローチャートにリターンする。ステップＳ２１２のエラー処理は、サービスプロパティに失敗の履歴を追加し、不要なデータを削除する処理である。
【００４８】
ステップＳ２１３では、処理要素コントローラ１ｂがサービス評価関数によりサービスプログラムの実行状態を評価し、ステップＳ２１４で評価関数に応じて実行したサービスプログラムの続行／中止の制御を行う。中止の場合には、ステップＳ２１２のエラー処理を実行する。例えば、処理時間が評価関数として指定されていれば、処理時間を評価し、所定の時間をオーバーした場合にはサービスプログラムを中止してエラー処理を実行する。
【００４９】
処理要素コントローラがステップＳ２１５においてサービスプログラムの終了を検出すると、そのサービスプログラムの終了コードを取得し、終了コードが正常終了を示しているか否かをステップＳ２１６で判断する。終了コードが正常終了を示している場合にはそのまま、示していない場合にはステップＳ２１２のエラー処理を実行してから図３のフローチャートにリターンする。
【００５０】
次に、図３のステップＳ７の「処理結果の評価」の処理の詳細を図６のフローチャートに基づいて説明する。ステップＳ３０１において処理要素コントローラ１ｂは、サービスプログラムから出力される処理結果とサービスプロパティが持つ出力情報とを照合する。次に、ステップＳ３０２において、両者の情報に矛盾がないか否かを判断する。具体的には、サービスプロパティの出力情報に記述されたデータ型とデータ数とが実際の処理結果と一致しているか否かにより矛盾の有無を判定する。矛盾がない場合には、正常に処理が実行されたと判断する。
【００５１】
ステップＳ３０２で矛盾があると判断された場合には、出力されたデータに処理要素を記述したＷＤＳＬファイルが含まれるか否かが判断される（ステップＳ３０３）。出力データ内のＷＤＳＬファイルの存在は、処理要素の追加が必要であることを意味する。そこで、この場合には、処理依頼コントローラ１ｂがコンテナ１ｃ内に新たな処理要素を追加し（ステップＳ３０４）、本処理要素は正常終了したと判断する。
【００５２】
ステップＳ３０３でＷＳＤＬファイルが存在しない場合には、当該処理要素が正常に終了しなかったと判断し、ステップＳ２１２と同様のエラー処理を実行し（ステップＳ３０５）、図３のフローチャートにリターンする。この場合には、当該処理要素を実行するために選択されたサービスプログラムではなく、他のサービスプログラムが必要と判断され、続くステップＳ９で別のサービスプログラムを選択して当該処理要素の処理は継続する。
【００５３】
実行していた処理要素が正常に終了したと判断された場合には、該当のサービスプログラムから出力された結果をデータ型ごとに当該処理要素の出力情報へ登録し（ステップＳ３０６）、処理要素コントローラは１ｂは当該処理要素の処理状態を「実行済」にし（ステップＳ３０７）、図３のフローチャートにリターンする。
【００５４】
次に、図３のステップＳ９の「処理のリトライ」の処理の詳細を図７のフローチャートに基づいて説明する。この処理は、ステップＳ６、Ｓ７の処理が正常に終了しなかった場合、すなわち、ステップＳ２１２あるいはステップＳ３０５のエラー処理を経てきた場合に、代替のサービスプログラムを提供して処理要素を実行するための処理である。
【００５５】
まず、ステップＳ４０１では、処理しようとしていた処理要素の状態を「処理中」から「未処理」に戻す。続いて、ステップＳ４０２においてソートテーブルを参照して実行済みの処理要素を実行順に１つ遡り（参照位置を１つ戻し）、参照位置がソートテーブルの最初に達しておらず、遡る処理要素が存在する場合には（ステップＳ４０３，Ｎｏ）、遡った処理要素の状態を未実行に変更する（ステップＳ４０４）。これらのステップＳ４０２〜４０４の３つのステップを、リトライ（再実行）できる分岐となる処理要素を発見するまで繰り返す。
【００５６】
リトライできるかどうかは、処理要素のサービスプロパティの中に、実行履歴が無い（未実行の）サービスプログラムに関するプロパティが存在するか否かにより決まる。実行履歴のないサービスプログラムのサービスプロパティが存在すれば、リトライが可能と判断する。リトライできる処理要素が発見された場合には、図３のフローチャートにリターンし、ステップＳ６で未実行のサービスプロパティで定義されるサービスプログラムを使い、その処理要素から処理を再実行する。
【００５７】
リトライできる処理要素を発見する前にソートテーブルの最初に達して遡る処理要素が存在しなくなった場合（ステップＳ４０４，Ｙｅｓ）には、処理依頼は実行不能と判断し、ステップＳ４０６でクライアントに「実行不能」であることを通知して異常終了する。
【００５８】
次に、サービスプログラムを抽出、選択する際に処理要素のサービス情報とＵＤＤＩ上の情報、あるいはＷＳＤＬファイルに記述された情報とがどの程度合致していれば一致と判断するか、具体例を挙げて説明する。
【００５９】
最初に、Ｓ２０３のサービスプロパティの検索において、処理要素のサービス条件に定められたサービス名が「ＡＢ」であるとき、ＵＤＤＩに登録されたどのようなサービス名が一致と判断されるかを表２に示す。表中の記号「×」は抽出されないサービスであること、「○」は抽出されるサービスであることを示している。
【００６０】
【表２】
2004287803.tif 000004
【００６１】
次に、ＷＳＤＬファイルを読み込んだ際にサービスプログラムの入力／出力条件が「ＡＢ」であるとき、処理要素のサービス検索条件がどのような条件であるときに条件が一致と判断されるかを表３に示す。表中の記号「◎」は最優先でデータが一致していると判断すること、「○」は「◎」がないときに一致すると判断されること、「△」は「◎」と「○」とがないときに一致すると判断されること、「×」は不一致であることを示している。
【００６２】
【表３】
2004287803.tif 000005
【００６３】
続いて、図７の処理で処理要素を１つずつ遡って検索する際に、入力の予定が「ＡＢ」であるとき、サービスプロパティでどのような実績のある処理要素をＳ４０５でリトライ可能（データ一致）と判断するか否かを表４に示す。記号の意味は表３と同様である。
【００６４】
【表４】
2004287803.tif 000006
【００６５】
【発明の効果】
以上説明したように、本発明によれば、依頼先のサービスプログラムがレジストリを用いて動的に決定されるため、プロバイダやネットワークに障害が発生した場合にも、それを避けて分散処理を実行することができ、安全、確実にクライアントに依頼された課題を解決することができる。
【００６６】
また、選択されたサービスプログラムが要求を完全に満たす回答を返さない場合にも、回答が一部利用できる場合には、新たな処理要素を追加して他のサービスプログラムを追加的に挿入して回答を要求に合致した形式に加工することにより、処理全体を中止することなく、クライアントに回答することができる。
【図面の簡単な説明】
【図１】本発明の実施形態にかかる分散型情報処理システムのシステム構成を示すブロック図である。
【図２】図１の分散型情報処理システムの作動を示す概念図である。
【図３】実施形態にかかる分散型情報処理システムを利用した処理の概略を示すフローチャートである。
【図４】図３の処理要素取得を詳細に示すフローチャートである。
【図５】図３の処理要素の実行を詳細に示すフローチャートである。
【図６】図３の処理要素の評価を詳細に示すフローチャートである。
【図７】図３の処理のリトライを詳細に示すフローチャートである。
【符号の説明】
１  サーバ
１ａ  処理依頼コントローラ
１ｂ  処理要素コントローラ
１ｃ  コンテナ
２  サービスプロバイダ
３  インターネット
４  クライアント
５  ＬＡＮ
６  サービスリゾルバ
【図１】
2004287803.tif 000007
【図２】
2004287803.tif 000008
【図３】
2004287803.tif 000009
【図４】
2004287803.tif 000010
【図５】
2004287803.tif 000011
【図６】
2004287803.tif 000012
【図７】
2004287803.tif 000013