(57)【要約】【課題】複数のデータ処理部の連携時の処理結果の受け渡しを効率化する。【解決手段】処理制御部１０は、クライアント２から指示されたスクリプトを実行する際、各データ処理部３０を起動して部分処理を実行させる。データ処理部３０は、部分処理の処理結果を処理結果記憶部５０に登録する。処理結果記憶部５０は、登録された処理結果に対して一意な処理結果ＩＤを割り当て、これをデータ処理部３０に返す。データ処理部３０は、その処理結果ＩＤを自らの処理結果として処理制御部１０に返す。処理制御部１０は、データ処理部３０を起動する際、引数として処理結果ＩＤを指定する。データ処理部３０は、引数の処理結果ＩＤに対応する処理結果を処理結果記憶部５０から取得して自らの処理を行う。【選択図】図１
2006134005.tif 000002
【特許請求の範囲】
【請求項１】
各々が所定の単位処理を実行する複数のデータ処理部を連携動作させることで、要求された処理を実行する連携処理装置であって、
前記複数のデータ処理部の処理結果データを記憶するための共有記憶部と、
前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録手段と、
前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供手段と、
を備え、
前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を前記処理結果提供手段に送ってその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために前記処理結果登録手段に対して登録要求を行うことを特徴とする連携処理装置。
【請求項２】
複数の単位処理を含んだ処理手順の実行要求をクライアント装置から受け取り、その処理手順に記述された各単位処理に対応するデータ処理部を順に起動して各々の単位処理を実行させる処理制御部、を更に備え、
前記各データ処理部は、前記登録要求に対して前記処理結果登録手段から受け取った処理結果識別情報を前記処理制御部に返し、
前記処理制御部は、前記データ処理部から返された処理結果識別情報を、そのデータ処理部の処理結果データを利用して単位処理を行う他のデータ処理部に対して処理パラメータとして渡す、
ことを特徴とする請求項１記載の連携処理装置。
【請求項３】
クライアント装置からの処理手順の実行要求に対して一意な利用可能範囲識別情報を付与し、付与した利用可能範囲識別情報を前記処理制御部に渡す利用可能範囲識別情報付与手段と、
各利用可能範囲識別情報に対応する１以上の処理結果識別情報を保持する利用可能範囲情報管理手段と、
を更に備え、
前記処理制御部は、前記利用可能範囲識別情報付与手段から付与された利用可能範囲識別情報を、前記処理手順の中で起動する前記データ処理部に対して渡し、
前記データ処理部は、前記処理制御部から渡された利用可能範囲識別情報を前記処理結果登録手段に対する登録要求の際に前記処理結果登録手段に渡し、
前記処理結果登録手段は、前記データ処理部から登録要求の際に渡された利用可能範囲識別情報を、その登録要求の対象である処理結果データに対応する処理結果識別情報と対応づけて前記利用可能範囲情報管理手段に登録し、
前記データ処理部は、前記処理制御部から渡された利用可能範囲識別情報を前記処理結果提供手段に対する取得要求の際に前記処理結果提供手段に渡し、
前記処理結果提供手段は、前記データ処理部から取得要求に係る処理結果識別情報が、その取得要求の際に渡された利用可能範囲識別情報に対応づけて前記利用可能範囲情報管理手段に保持されているか否かを調べ、保持されている場合にのみその処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す、
ことを特徴とする請求項２記載の連携処理装置。
【請求項４】
利用可能範囲識別情報を伴うデバッグモードが指示された場合に、その利用可能範囲識別情報がデバッグ対象である旨を記憶するデバッグモード管理手段、を更に備え、
前記処理制御部は、前記処理手順中のデバッグモード指示を実行する場合、その処理手順の利用可能範囲識別情報を伴うデバッグモード指示を前記デバッグモード管理手段に送り、
前記処理結果提供手段は、その取得要求の際に渡された利用可能範囲識別情報がデバッグ対象であるか否かを前記デバッグモード管理手段を参照して求め、デバッグ対象である場合には、取得要求の対象である処理結果識別情報がその利用可能範囲識別情報に対応づけて前記利用可能範囲情報管理手段に保持されているか否かによらず、前記処理結果提供手段がその処理結果識別情報に対応する処理結果データをそのデータ処理部に提供する、
ことを特徴とする請求項３記載の連携処理装置。
【請求項５】
有効期間開始要求に応じて、一意な有効期間識別情報を付与し、付与した有効期間識別情報を前記処理制御部に返す有効期間開始手段と、
各有効期間識別情報に対応する１以上の処理結果識別情報を保持する有効期間情報管理手段と、
有効期間識別情報を指定した有効期間終了要求に応じて、前記有効期間情報管理手段に保持されたその有効期間識別情報に対応する各処理結果識別情報に対応する処理結果データを、前記共有記憶部から削除する有効期間終了手段と、
を更に備え、
前記処理制御部は、前記処理手順中の有効期間の開始指示を実行する場合は、前記有効期間開始手段に有効期間開始要求を行い、この要求に応じて前記有効期間開始手段から付与された有効期間識別情報を受け取り、この有効期間識別情報を、前記処理手順の中で前記有効期間の開始指示に対応する終了指示までの間に起動する前記データ処理部に対して渡し、
前記データ処理部は、前記処理制御部から渡された有効期間識別情報を前記処理結果登録手段に対する登録要求の際に前記処理結果登録手段に渡し、
前記処理結果登録手段は、前記データ処理部から登録要求の際に渡された有効期間識別情報を、その登録要求の対象である処理結果データに対応する処理結果識別情報と対応づけて前記有効期間情報管理手段に登録し、
前記処理制御部は、前記処理手順中の有効期間の終了指示を実行する場合は、前記有効期間終了手段に対して、その有効期間の有効期間識別情報を伴う有効期間終了要求を行う、
ことを特徴とする請求項２記載の連携処理装置。
【請求項６】
処理結果識別情報を伴う削除対象除外要求に応じて、処理結果識別情報に対応する処理結果データを、前記有効期間終了手段による前記共有記憶部からの削除対象から外す削除対象除外手段、を更に備え、
前記処理制御部は、前記処理手順中に処理結果識別情報を指定した削除対象除外指示が記述されている場合は、その処理結果識別情報を伴う削除対象除外要求を前記削除対象除外手段に実行させる、
ことを特徴とする請求項５記載の連携処理装置。
【請求項７】
有効期間識別情報を伴うデバッグモードが指示された場合に、その有効期間識別情報がデバッグ対象である旨を記憶するデバッグモード管理手段、を更に備え、
前記処理制御部は、前記処理手順中のデバッグモード指示を実行する場合、有効期間識別情報を伴うデバッグモード指示を前記デバッグモード管理手段に送り、
前記有効期間終了手段は、前記有効期間終了要求に指定された有効期間識別情報がデバッグ対象であるか否かを前記デバッグモード管理手段を参照して求め、デバッグ対象である場合には、前記有効期間情報管理手段に保持されたその有効期間識別情報に対応する各処理結果識別情報に対応する処理結果データの前記共有記憶部からの削除を行わない、
ことを特徴とする請求項５記載の連携処理装置。
【請求項８】
ネットワークを介して接続された複数のホスト装置を連携動作させることで、要求された処理を実行する連携処理システムであって、
各ホスト装置は、
各々が単位処理を実行する１以上のデータ処理部と、
前記データ処理部の処理結果データを記憶するための共有記憶部と、
前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録手段と、
前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供手段と、
を備え、
前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を前記処理結果提供手段に送ってその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために前記処理結果登録手段に対して登録要求を行い、当該データ処理部が他のホスト装置から呼び出されたものである場合はその登録要求に対する返り値として受け取った処理結果識別情報を呼出元である該他のホスト装置に返し、
前記処理結果提供手段は、前記データ処理部からの取得要求に指定された処理結果識別情報に対応する処理結果データが自ホスト装置の前記共有記憶部にない場合に、その処理結果識別情報が示すホスト装置の共有記憶部に対してその処理結果識別情報を伴う取得要求を行い、この取得要求に対してその共有記憶部から返されてきた処理結果データをそのデータ処理部に渡すと共に、その処理結果データをその処理結果識別情報と対応づけて自ホスト装置の前記共有記憶部に登録する、
ことを特徴とする連携処理システム。
【請求項９】
ネットワークを介して接続された複数のホスト装置を連携動作させることで、要求された処理を実行する連携処理システムであって、
各ホスト装置は、
各々が単位処理を実行する１以上のデータ処理部と、
前記データ処理部の処理結果データを記憶するための共有記憶部と、
前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録手段と、
前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供手段と、
を備え、
前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を前記処理結果提供手段に送ってその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために前記処理結果登録手段に対して登録要求を行い、当該データ処理部が他のホスト装置から呼び出されたものである場合はその登録要求に対する返り値として受け取った処理結果識別情報とそれに対応して前記共有記憶部に登録された処理結果データを呼出元である該他のホスト装置に返し、
前記各データ処理部は、自らの単位処理の実行の中の部分処理のために他のホスト装置のデータ処理部を呼び出した場合、その呼出に対して該他のホスト装置のデータ処理部から返される処理結果識別情報と処理結果データとを前記共有記憶部に登録する、
ことを特徴とする連携処理システム。
【請求項１０】
前記複数のホスト装置は、前記データ処理部の一つとして、複数の単位処理を含んだ処理手順の実行を制御する処理制御部を備え、ホスト装置内の複数のデータ処理部のうちこの処理制御部のみが、他のホスト装置内のデータ処理部に対する起動要求を発する、ことを特徴とする請求項８又は９に記載の連携処理システム。
【請求項１１】
前記ホスト装置の処理制御部は、他のホスト装置の複数のデータ処理部のうちの前記処理制御部にのみ起動要求を発することができる、ことを特徴とする請求項１０記載の連携処理システム。
【請求項１２】
前記複数のホスト装置は、クライアント装置からの処理手順の実行要求を受け付けるポータルホスト装置と、それ以外のリモートホスト装置とに分類され、
前記ポータルホスト装置は、
クライアント装置からの処理手順の実行要求に対して一意な利用可能範囲識別情報を付与し、付与した利用可能範囲識別情報を該ポータルホスト装置の処理制御部に渡す利用可能範囲識別情報付与手段と、
各利用可能範囲識別情報に対応する１以上の処理結果識別情報を保持する利用可能範囲情報管理手段と、
を備え、
該ポータルホスト装置の前記処理制御部は、前記利用可能範囲識別情報付与手段から付与された利用可能範囲識別情報を、前記処理手順の中で起動する自ホスト装置内の前記データ処理部に対して渡すと共に、その処理手順の中で他のホスト装置に対する第２の処理手順の実行指示が含まれる場合は、該他のホスト装置の処理制御部に対し、該第２の処理手順の実行要求をその利用可能範囲識別情報と共に渡し、
前記リモートホスト装置は、
各利用可能範囲識別情報に対応する１以上の処理結果識別情報を保持する利用可能範囲情報管理手段と、
他のホスト装置から処理手順の実行要求を受けた場合に、その実行要求と共に受け取った利用可能範囲識別情報を当該ホスト装置内の前記利用可能範囲情報管理手段に登録する手段と、
を備え、
該リモートホスト装置の前記処理制御部は、前記他のホスト装置からの処理手順の実行要求と共に受け取った利用可能範囲識別情報を、その処理手順の中で起動する自ホスト装置内の前記データ処理部に対して渡すと共に、その処理手順の中で他のホスト装置に対する第２の処理手順の実行指示が含まれる場合は、該他のホスト装置の処理制御部に対し、該第２の処理手順の実行要求をその利用可能範囲識別情報と共に渡し、
前記各ホスト装置の前記データ処理部は、自ホスト装置の前記処理制御部から渡された利用可能範囲識別情報を自ホスト装置の前記処理結果登録手段に対する登録要求の際に前記処理結果登録手段に渡し、
該各ホスト装置の前記処理結果登録手段は、自ホスト装置の前記データ処理部から登録要求の際に渡された利用可能範囲識別情報を、その登録要求の対象である処理結果データに対応する処理結果識別情報と対応づけて自ホスト装置の前記利用可能範囲情報管理手段に登録し、
前記各ホスト装置の前記データ処理部は、自ホスト装置の前記処理制御部から渡された利用可能範囲識別情報を自ホスト装置の前記処理結果提供手段に対する取得要求の際に前記処理結果提供手段に渡し、
前記各ホスト装置の前記処理結果提供手段は、自ホスト装置の前記データ処理部から取得要求に係る処理結果識別情報が自ホスト装置の前記共有記憶部にある場合には、その処理結果識別情報が取得要求と共に渡された利用可能範囲識別情報に対応づけて自ホスト装置の前記利用可能範囲情報管理手段に保持されているか否かを調べ、保持されている場合にのみその処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返し、自ホスト装置の前記データ処理部から取得要求に係る処理結果識別情報が自ホスト装置の前記共有記憶部にない場合には、その処理結果識別情報が示すホスト装置の共有記憶部に対してその処理結果識別情報とその利用可能範囲識別情報とを伴う取得要求を行い、
前記各ホスト装置の前記処理結果提供手段は、他のホスト装置の前記処理結果提供手段から処理結果識別情報と利用可能範囲識別情報とを伴う取得要求を受けた場合、その処理結果識別情報が自ホスト装置内の前記利用可能範囲管理手段にその利用可能範囲識別情報と対応づけて保持されているか否かを調べ、保持されている場合にのみその処理結果識別情報に対応する処理結果データを自ホスト装置の前記共有記憶部から取得して前記他の装置の前記処理結果提供手段に返す、
ことを特徴とする請求項１１記載の連携処理システム。
【請求項１３】
前記各ホスト装置は、
有効期間開始要求に応じて、一意な有効期間識別情報を付与し、付与した有効期間識別情報を前記処理制御部に返す有効期間開始手段と、
各有効期間識別情報に対応する１以上の処理結果識別情報を保持する有効期間情報管理手段と、
有効期間識別情報を指定した有効期間終了要求に応じて、前記有効期間情報管理手段に保持されたその有効期間識別情報に対応する各処理結果識別情報に対応する処理結果データを、前記共有記憶部から削除する有効期間終了手段と、
を更に備え、
前記処理制御部は、前記処理手順中の有効期間の開始指示を実行する場合は、前記有効期間開始手段に有効期間開始要求を行い、この要求に応じて前記有効期間開始手段から付与された有効期間識別情報を受け取り、この有効期間識別情報を、前記処理手順の中で前記有効期間の開始指示に対応する終了指示までの間に起動する前記データ処理部及び他のホスト装置の処理制御部に対して渡し、
前記データ処理部は、前記処理制御部から渡された有効期間識別情報を前記処理結果登録手段に対する登録要求の際に前記処理結果登録手段に渡し、
前記処理結果登録手段は、前記データ処理部から登録要求の際に渡された有効期間識別情報を、その登録要求の対象である処理結果データに対応する処理結果識別情報と対応づけて前記有効期間情報管理手段に登録し、
前記処理制御部は、前記処理手順中の有効期間の終了指示を実行する場合は、前記有効期間終了手段に対して、その有効期間の有効期間識別情報を伴う有効期間終了要求を行う、
ことを特徴とする請求項１１記載の連携処理システム。
【請求項１４】
コンピュータシステムを、各々が所定の単位処理を実行する複数のデータ処理部を連携動作させることで、要求された処理を実行する連携処理装置として機能させるためのプログラムであって、前記コンピュータシステムを、
前記複数のデータ処理部の処理結果データを記憶するための共有記憶部、
前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録手段、
前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供手段、
として機能させると共に、
前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を前記処理結果提供手段に送ってその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために前記処理結果登録手段に対して登録要求を行うことを特徴とするプログラム。
【請求項１５】
ネットワークを介して接続された複数のホスト装置を連携動作させることで、要求された処理を実行する連携処理システムにおけるホスト装置として、コンピュータシステムを機能させるためのプログラムであって、該コンピュータシステムを、
各々が単位処理を実行させる１以上のデータ処理部、
前記データ処理部の処理結果データを記憶するための共有記憶部、
前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録手段、
前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供手段、
として機能させると共に、
前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を前記処理結果提供手段に送ってその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために前記処理結果登録手段に対して登録要求を行い、当該データ処理部が他のホスト装置から呼び出されたものである場合はその登録要求に対する返り値として受け取った処理結果識別情報を呼出元である該他のホスト装置に返し、
前記処理結果提供手段は、前記データ処理部からの取得要求に指定された処理結果識別情報に対応する処理結果データが自ホスト装置の前記共有記憶部にない場合に、その処理結果識別情報が示すホスト装置の共有記憶部に対してその処理結果識別情報を伴う取得要求を行い、この取得要求に対してその共有記憶部から返されてきた処理結果データをそのデータ処理部に渡すと共に、その処理結果データをその処理結果識別情報と対応づけて自ホスト装置の前記共有記憶部に登録する、
ことを特徴とするプログラム。
【請求項１６】
ネットワークを介して接続された複数のホスト装置を連携動作させることで、要求された処理を実行する連携処理システムホスト装置として、コンピュータシステムを機能させるためのプログラムであって、該コンピュータシステムを、
各々が単位処理を実行する１以上のデータ処理部、
前記データ処理部の処理結果データを記憶するための共有記憶部、
前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録手段、
前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供手段、
として機能させると共に、
前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を前記処理結果提供手段に送ってその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために前記処理結果登録手段に対して登録要求を行い、当該データ処理部が他のホスト装置から呼び出されたものである場合はその登録要求に対する返り値として受け取った処理結果識別情報とそれに対応して前記共有記憶部に登録された処理結果データを呼出元である該他のホスト装置に返し、
前記各データ処理部は、自らの単位処理の実行の中の部分処理のために他のホスト装置のデータ処理部を呼び出した場合、その呼出に対して該他のホスト装置のデータ処理部から返される処理結果識別情報と処理結果データとを前記共有記憶部に登録する、
ことを特徴とするプログラム。
【請求項１７】
各々が所定の単位処理を実行する複数のデータ処理部を連携動作させることで、要求された処理を実行する連携処理制御方法であって、
前記データ処理部から所定の共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録ステップと、
前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供ステップと、
を有し、
前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を行って前記処理結果提供ステップを実行することによりその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために登録要求を行うことで前記処理結果登録ステップを実行する、連携処理制御方法。
【請求項１８】
ネットワークを介して接続され、各々が単位処理を実行する１以上のデータ処理部と、前記データ処理部の処理結果データを記憶するための共有記憶部と、を備える複数のホスト装置を連携動作させることで、要求された処理を実行する連携処理制御方法であって、
前記各ホスト装置は、
前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録ステップと、
前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供ステップと、
を有し、
前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を行って前記処理結果提供ステップを実行することによりその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために登録要求を行うことで前記処理結果登録ステップを実行し、当該データ処理部が他のホスト装置から呼び出されたものである場合はその登録要求に対して前記処理結果登録ステップから受け取った処理結果識別情報を呼出元である該他のホスト装置に返し、
前記処理結果提供ステップでは、前記データ処理部からの取得要求に指定された処理結果識別情報に対応する処理結果データが自ホスト装置の前記共有記憶部にない場合に、その処理結果識別情報が示すホスト装置の共有記憶部に対してその処理結果識別情報を伴う取得要求を行い、この取得要求に対してその共有記憶部から返されてきた処理結果データをそのデータ処理部に渡すと共に、その処理結果データをその処理結果識別情報と対応づけて自ホスト装置の前記共有記憶部に登録する、
ことを特徴とする連携処理制御方法。
【請求項１９】
ネットワークを介して接続され、各々が単位処理を実行する１以上のデータ処理部と、前記データ処理部の処理結果データを記憶するための共有記憶部と、を備える複数のホスト装置を連携動作させることで、要求された処理を実行する連携処理制御方法であって、
前記各ホスト装置は、
前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録ステップと、
前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供ステップと、
を有し、
前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を行って前記処理結果提供ステップを実行することによりその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために登録要求を行って前記処理結果登録ステップを実行し、当該データ処理部が他のホスト装置から呼び出されたものである場合はその登録要求に対する返り値として受け取った処理結果識別情報とそれに対応して前記共有記憶部に登録された処理結果データを呼出元である該他のホスト装置に返し、
前記各データ処理部は、自らの単位処理の実行の中の部分処理のために他のホスト装置のデータ処理部を呼び出した場合、その呼出に対して該他のホスト装置のデータ処理部から返される処理結果識別情報と処理結果データとを前記共有記憶部に登録する、
ことを特徴とする連携処理制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は複数のデータ処理コンポーネントを連携させて一連の処理を行わせる分散データ処理技術に関する。
【背景技術】
【０００２】
複数のデータ処理コンポーネントを連携させて一連の処理を実行させる分散データ処理方法として、例えば特許文献１に示される方法がある。この方法では、結合処理の手続き情報および中間結果情報を転送情報単位としてネットワーク内を巡回させ、一方各部分処理を実行して結果を保持する各ノードはネットワークから転送情報単位を取得し、この転送情報単位の手続き情報に基づき、当該ノードの保持する部分処理結果と該取得した中間結果情報とを用いて、結合処理の一部を行い、この結果により中間結果情報を更新し、手続き情報とともにネットワークに送出する。
【０００３】
また、特許文献２には、ウェブサーバ上の原料ファイルを処理サーバに処理させ、複数の処理サーバの処理を連携させることで、複雑な加工を施した処理結果を求めるシステムが開示されている。このシステムでは、ウェブブラウザは、原料ファイルを手続名、パラメータ、コンピュータ名等で修飾した仮想ＵＲＬ(Uniform Resource Locator)によりリクエストを送出する。複数の部分処理を組み合わせた複合的な処理は、部分処理の仮想ＵＲＬに対し引数とする他の部分処理の仮想ＵＲＬを組み込む形で表現しており、各処理サーバは、自分宛の仮想ＵＲＬを解釈してその中に含まれる自分が処理できない引数（仮想ＵＲＬ）が示すリクエストをそれを処理できる処理サーバにＨＴＴＰ(Hypertext Transfer Protocol)で転送してその処理結果を取得し、それを自分の処理に利用する。各処理サーバは、自分が実行した部分処理の処理結果（スナップショット）を、その処理の元になった仮想ＵＲＬに対応づけてテーブルに保持する。そして、処理サーバは、送られてきた自分宛の仮想ＵＲＬに対応するスナップショットが自装置内のテーブルにあるかどうかを調べ、あれば更にその有効性を調べ、有効であればその仮想ＵＲＬの示す処理を実行せずにそのスナップショットを処理結果として返す。ここで有効性の検査では、スナップショットの作成時刻が、そのスナップショット作成の原料ファイルの更新日時より新しい場合に、有効と判断する。スナップショットの作成には、他の処理サーバの部分処理の処理結果が引数として用いられている場合には、他の処理サーバに対して引数の部分処理のスナップショットの有効性を問い合わせる。ある部分処理の引数のスナップショットのなかに１つでも無効なものがあれば、その部分処理のスナップショットが無効となる。スナップショットが無効であれば、その部分処理は再実行する。ただし、この場合、その部分処理の引数のスナップショットの中に有効なものがあれば、その引数については処理の再実行は行わず、そのスナップショットを利用する。
【０００４】
【特許文献１】特開平１０−０２７１６４号公報
【特許文献２】特開２０００−０７６１１８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１の方法では、ネットワーク内に巡回させる転送処理単位に中間処理結果のデータ実体が含まれており、ネットワーク負荷が大きいという問題がある。またこの方法では、ノードに転送処理単位が回ってくるごとに、そのノードに対し転送処理単位のデータのコピーが発生する。また、過去に行った処理とまったく同じ処理でも、そのような処理がプログラムに記述されていればそれを繰り返し実行するので、効率が悪い。
【０００６】
特許文献２の方式では、各処理サーバが、自分の行った部分処理のスナップショットを保持し、再利用しているので、過去に行った処理とまったく同じ処理を繰り返すという無駄は生じにくい。しかし、この方法では、処理サーバは、処理が終わった場合、その処理の結果を利用する処理サーバに対し、その処理結果の実体データを送信している。このため、スナップショット利用により各処理サーバの処理負担を低減することはできても、ネットワークの負荷の低減効果は少ない。
【０００７】
また、特許文献２の方式では、ある処理を示す仮想ＵＲＬ内に、その処理の引数となる別の処理の仮想ＵＲＬを入れ子で記述することで、複数の処理サーバでの処理を連携しているが、このような入れ子方式の記述形態では、処理の繰り返しを表現することが困難である。
【０００８】
また、複数の処理サーバを連携させた、例えばパイプライン処理の連携処理を実行する場合、処理サーバの処理結果の実体データを次の処理サーバに渡した時点から該次の処理サーバの処理を開始したのでは、全体の処理に時間を要するという問題がある。この問題は、１つのコンピュータ装置上の複数のデータ処理コンポーネントを連携させる場合にも生じることである。なお、ＵＮＩＸ（登録商標）等のＯＳ（オペレーティングシステム）が提供するパイプライン処理機能は、パイプラインを構成する各プログラムをＯＳが最初に起動し、それらプログラムの標準出力ストリームをその次のプログラムの標準入力ストリームに割り当てることで、連携処理を実現しているので、上述のような問題がない。しかし、そのように各プログラムの処理結果を入出力のストリームを介して受け渡したのでは、各プログラムごとの処理結果がコンピュータ装置上に残らないため、デバッグなどの様に、途中の処理結果を調べたい場合には不十分であった。
【０００９】
本発明は、上記従来技術の問題の少なくとも１つを解決するものである。
【課題を解決するための手段】
【００１０】
本発明の１つの側面では、各々が所定の単位処理を実行する複数のデータ処理部を連携動作させることで、要求された処理を実行する連携処理装置を提供する。この連携処理装置は、前記複数のデータ処理部の処理結果データを記憶するための共有記憶部と、前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録手段と、前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供手段と、を備え、前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を前記処理結果提供手段に送ってその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために前記処理結果登録手段に対して登録要求を行う。
【００１１】
本発明の別の側面では、ネットワークを介して接続された複数のホスト装置を連携動作させることで、要求された処理を実行する連携処理システムを提供する。このシステムでは、各ホスト装置は、各々が単位処理を実行する１以上のデータ処理部と、前記データ処理部の処理結果データを記憶するための共有記憶部と、前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録手段と、前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供手段と、を備え、前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を前記処理結果提供手段に送ってその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために前記処理結果登録手段に対して登録要求を行い、当該データ処理部が他のホスト装置から呼び出されたものである場合はその登録要求に対する返り値として受け取った処理結果識別情報を呼出元である該他のホスト装置に返し、前記処理結果提供手段は、前記データ処理部からの取得要求に指定された処理結果識別情報に対応する処理結果データが自ホスト装置の前記共有記憶部にない場合に、その処理結果識別情報が示すホスト装置の共有記憶部に対してその処理結果識別情報を伴う取得要求を行い、この取得要求に対してその共有記憶部から返されてきた処理結果データをそのデータ処理部に渡すと共に、その処理結果データをその処理結果識別情報と対応づけて自ホスト装置の前記共有記憶部に登録する。
【００１２】
更に別の側面では、連携処理システムを構成する各ホスト装置は、各々が単位処理を実行する１以上のデータ処理部と、前記データ処理部の処理結果データを記憶するための共有記憶部と、前記データ処理部から前記共有記憶部への処理結果データの登録要求を受けた場合に、その処理結果データに対して一意な処理結果識別情報を付与し、付与した処理結果識別情報をその処理結果データと対応づけて前記共有記憶部に登録し、その処理結果識別情報を前記登録要求に対する返り値として前記データ処理部に返す処理結果登録手段と、前記データ処理部から処理結果識別情報を指定した取得要求を受けた場合に、その処理結果識別情報に対応する処理結果データを前記共有記憶部から取得してそのデータ処理部に返す処理結果提供手段と、を備え、前記各データ処理部は、処理結果識別情報を処理パラメータとして含む起動要求により起動された場合、その処理結果識別情報を含む取得要求を前記処理結果提供手段に送ってその処理結果識別情報に対応する処理結果データを受け取り、その処理結果データを用いて自らの単位処理を実行すると共に、その単位処理により得られる処理結果データを記憶するために前記処理結果登録手段に対して登録要求を行い、当該データ処理部が他のホスト装置から呼び出されたものである場合はその登録要求に対する返り値として受け取った処理結果識別情報とそれに対応して前記共有記憶部に登録された処理結果データを呼出元である該他のホスト装置に返し、前記各データ処理部は、自らの単位処理の実行の中の部分処理のために他のホスト装置のデータ処理部を呼び出した場合、その呼出に対して該他のホスト装置のデータ処理部から返される処理結果識別情報と処理結果データとを前記共有記憶部に登録する。
【発明を実施するための最良の形態】
【００１３】
以下、図面を参照して、本発明を実施するための最良の形態（以下「実施形態」と呼ぶ）について説明する。
【００１４】
［第１実施形態］
図１は、本発明の第１実施形態のシステム構成を示す図である。このシステムでは、１つのホスト（コンピュータ装置）１が、クライアント２（コンピュータ装置）に対するサービスを実行する。ホスト１は、例えばGroovy等のスクリプト言語で記述されたスクリプトを実行することにより、サービスのための処理を行う。サービスを要求するためにクライアント２がホスト１に対して送るリクエストは、例えば、スクリプトの名前（スクリプト名）と、そのスクリプトの引数とするパラメータとを含んだものとなる。
【００１５】
ホスト１内の処理機構には、処理制御部１０、処理制御手順解釈部２０、データ処理部３０−１，３０−２、原料データ記憶部４０、処理結果記憶部５０が含まれる。
【００１６】
データ処理部３０−１，３０−２は、クライアント２に対するサービスを実現するための、個々の単位的なデータ処理を実行するユニットである。単位的なデータ処理（以下「単位処理」という）の内容には特に限定はない。例えば、文書の要約、複数文書のマージ（併合）など、さまざまなものが考えられる。
【００１７】
図示例では、データ処理部３０−１，３０−２は、Ｊａｖａ（登録商標）等のクラスとして実装している。そのクラス名は、データ処理部３０−１がComponent1、データ処理部３０−２がComponent2である。データ処理部３０−１はComponent1クラスのメソッドであるexecuteメソッド３２−１を、データ処理部３０−２はComponent2クラスのメソッドであるexecuteメソッド３２−２をそれぞれ備えている。executeメソッド３２−１，３２−２は、それぞれ対応するデータ処理部３０−１，３０−２が提供する単位処理を実行するためのメソッドである。
【００１８】
図１には、データ処理部３０−１，３０−２の２つのデータ処理部を示したが、もっと多くのデータ処理部をホスト１に持たせることももちろん可能である。ホスト１の処理は、これらデータ処理部３０−１，３０−２，・・・の単位処理を連携させることにより実現される。以下、データ処理部３０−１，３０−２に固有のものでない、データ処理部一般に妥当する事柄については、データ処理部３０−１，３０−２，・・・をデータ処理部３０と総称する。
【００１９】
処理制御部１０は、それら複数のデータ処理部３０の単位処理の連携を制御するユニットである。処理制御部１０は、クライアント２からのリクエストに指定されたスクリプトを起動し、そのスクリプトに記述された各単位処理を実行するデータ処理部３０を起動して処理を実行させる。このスクリプト実行の際、処理制御部１０は、各データ処理部３０の処理結果の受け渡しの制御を行う。
【００２０】
処理制御部１０は、サーブレットプログラムとして実装することができる。図示例では、処理制御部１０はＪａｖａ（登録商標）等のクラスとして実装しており、そのクラス名はEvaluatorである。処理制御部１０が実行する処理は、evalメソッド１２として実装されている。クライアント２は、スクリプトとその実行に必要なパラメータを指定し、ホスト１のEvaluatorクラスのevalメソッド１２を呼び出すことで、ホスト１に対して処理を要求することができる。
【００２１】
例えば、ホスト１をウェブアプリケーションサーバとして構成する場合、クライアント２からホスト１へのリクエストは、以下に例示するようなＨＴＴＰのＵＲＬの形とすることができる。
http://host.domain/Evaluator?method=eval&script=script1.groovy&arg1=aaa&arg2=bbb
… (1)
【００２２】
このＵＲＬ(1)において、hostはホスト１のホスト名であり、domainはホスト１が位置するドメインのドメイン名である。Evaluatorは、呼び出すべきEvaluatorクラスである。また、ＵＲＬのクエリ部（"?"以下の記述）には、呼び出すメソッド名eval、実行したいスクリプト名script1.groovy、及びそのスクリプトの２つの引数（パラメータ）aaa、bbbが記述されている。スクリプトが要する引数の数（或いは引数が要らないか）は、スクリプトごとに異なる。リクエストには実行対象のスクリプトに合った引数がセットされる。
【００２３】
ホスト１が実行するスクリプトには、個々のデータ処理部３０の処理（すなわち単位処理）を起動するための式と、別のスクリプトを実行させるための式とを含み得る。また、スクリプト内にはforループなど、従来から知られている各種の制御構造を記述することができ、単位処理又はスクリプトを示す式の並び順や制御構造の記述により、一連の処理を表すことができる。
【００２４】
クライアント２から上記(1)のＵＲＬに基づくＨＴＴＰリクエストがホスト１に送られた場合、ホスト１では、ウェブサーバがそのリクエストを受け取り、Evaluatorという名前で示されるサーブレットを起動する。これのサーブレットが処理制御部１０である。
【００２５】
処理制御手順解釈部２０は、スクリプトの記述を解釈するユニットであり、処理制御部１０から通知されたスクリプトを解釈し、処理制御部１０に対してそのスクリプトが示す処理を順次指示していく。
【００２６】
原料データ記憶部４０は、データ処理部３０での単位処理の原料となる原料データを記憶している。原料データは単位処理の内容による。例えば、文書要約処理の原料データは文書データとなる。図では原料データ記憶部４０をホスト１内のユニットとして示したが、この代わりに、ＬＡＮやインターネット上にある別のサーバ装置を原料データ記憶部４０として用いるシステム構成も可能である。
【００２７】
処理結果記憶部５０は、各データ処理部３０が実行した単位処理の処理結果を記憶し、管理するユニットである。本実施形態では、各データ処理部３０が実行した単位処理の処理結果を処理結果記憶部５０に登録するわけであるが、処理結果記憶部５０は、登録する処理結果に対して「処理結果ＩＤ」と呼ぶ一意な識別情報を付与して管理する。そして、データ処理部３０間でのデータの受け渡しを、データ実体を直接受け渡すのではなく、処理結果ＩＤを受け渡すことにより実現する。処理結果ＩＤを受け取ったデータ処理部３０は、その処理結果ＩＤに対応するデータ実体を処理結果記憶部５０から取得し、自らの処理に用いる。
【００２８】
処理結果記憶部５０は、図示例では、処理結果記憶部５０はＪａｖａ（登録商標）等のクラスとして実装しており、そのクラス名はPoolである。処理結果記憶部５０に対する処理結果データの登録処理はregisterメソッド５１として、処理結果記憶部５０からの処理結果データの取得処理はaccessメソッド５２として、それぞれ実装される。処理結果の実体データは、処理結果管理テーブル５３に登録され、管理される。処理結果管理テーブル５３は、図２に示すように、処理結果の実体データ（「処理結果実体」）を、それに対して付与された処理結果ＩＤと対応づけて登録したテーブルである。
【００２９】
以下に、ホスト１内の各処理部で実行されるメソッドの処理内容をまとめる。
【００３０】
＜データ処理部３０(Evaluator)＞
・executeメソッド３２：このメソッドは、呼び出されると、所定のデータ処理を行い、処理結果記憶部５０(Pool)のregiterメソッド５１を呼んでその処理結果を処理結果記憶部５０に登録し、regiterメソッド５１の返り値である処理結果ＩＤを、executeメソッド３２の呼出元に返す。呼び出されるexecuteメソッド３２の引数に処理結果ＩＤが与えられている場合は、処理結果記憶部５０のaccessメソッド５２を呼んでその処理結果ＩＤに対応する処理結果実体を取得し、データ処理に用いる。
【００３１】
＜処理結果記憶部５０(Pool)＞
・registerメソッド５１：このメソッドは、引数として渡された処理結果実体に対し、処理結果ＩＤを付与して処理結果管理テーブル５３に登録し、呼出元にその処理結果ＩＤを返す。なお、一意の処理結果ＩＤは、例えば通し番号を採番することで生成する。
【００３２】
・accessメソッド５２：このメソッドは、引数として渡された処理結果ＩＤに対応する処理結果実体を処理結果管理テーブル５３から読み出し、呼出元に返す。
【００３３】
＜処理制御部１０(Evaluator)＞
・evalメソッド１２：このメソッドは、引数に指定されたスクリプトを起動し、その処理結果を呼出元に返す。呼出元がクライアント２であれば処理結果は実体データで返す。一方、スクリプトから呼び出された場合は、処理結果ＩＤを返す。evalメソッド１２の処理の詳細は、後でフローチャートを示して詳細に説明する。
【００３４】
次に、本実施形態で用いるスクリプトについて説明する。スクリプトを構成する式のうち、データ処理部３０を起動する式は、次のようなものとなる。
id1 = Component1.execute(url1);               …(2)
【００３５】
この例は、url1というＵＲＬが示す原料データをComponent1クラスのexecuteメソッドで処理させることを示す式であり、id1はそのメソッドの返り値である処理結果ＩＤを示す。
【００３６】
また、スクリプトを構成する式のうち、別のスクリプトの実行を示す式は、次のようなものとなる。
id2 = Evaluator.eval(scriptname, parameter);  …(3)
【００３７】
この例が示すように、スクリプトの実行は、Evaluatorクラスのevalメソッドを呼び出すことにより実現する。evalメソッドの最初の引数scriptnameは、実行対象のスクリプトのスクリプト名であり、第２の引数parameterは、そのスクリプトが取るパラメータの配列である。この場合、evalメソッドはスクリプト内から呼ばれているので、その返り値id2はスクリプトの最終処理結果の処理結果ＩＤとなっている。
【００３８】
スクリプトは、このようにデータ処理部３０を起動する式と別のスクリプトの実行を指示する式とを、反復や選択などの各種制御構造を示す文と共に記述したものとなる。
【００３９】
本実施形態では、スクリプトはホスト１内の記憶装置に記憶されている。そして、処理制御手順解釈部２０が、処理制御部１０から指定されたスクリプト名に該当するスクリプトをその記憶装置から読み出し、解釈する。
【００４０】
次に、図３に示す処理制御部１０の処理（evalメソッド）の手順と図１とを参照して、ホスト１によるリクエスト処理について説明する。
【００４１】
処理制御部１０であるサーブレットは、クライアント２からＵＲＬ形式のリクエストに応じて起動され、まずそのリクエストのクエリ部からスクリプト名とパラメータ（引数）を抽出する（Ｓ１０）。例えばリクエストが上述のＵＲＬ(1)であった場合、スクリプト名として"script1.groovy"が、第１のパラメータとしてaaaが、第２のパラメータとしてbbbが抽出される。
【００４２】
次に処理制御部１０は、そのスクリプト名が示すスクリプトを呼び出す（Ｓ１２）。すなわち、抽出したスクリプト名及びパラメータを渡して処理制御手順解釈部２０を起動する。起動された処理制御手順解釈部２０は、そのスクリプト名に対応するスクリプトを記憶装置から取得し、これを解釈して実行すべき処理を順に処理制御部１０に指示する。
【００４３】
例えば、呼び出されたスクリプト"script1.groovy"が以下のようなものだったとする。
id_const = Component1.execute(url1);               … (11)
id_result;
for (i=0; i<10; i++) [
id_current = Component2.execute(id_const, id_result);  … (12)
id_result = id_current;
]
return id_result;
【００４４】
このスクリプトにおいて、(11)式は、url1というＵＲＬが示す原料データをデータ処理部３０−１に処理させる旨の指示を示している。id_constは、この処理の処理結果のＩＤを保持する変数である。また(12)式は、id_constという処理結果ＩＤが示す処理結果データと、id_resultという処理結果ＩＤが示す処理結果データとを、データ処理部３０−２に処理を実行させる旨の指示を示している。id_currentは、この処理の処理結果のＩＤを保持する変数である。(12)式の処理は、forループにより１０回反復されるが、その中で用いられる引数id_constはその反復においても変化しない。すなわち、(11)式の処理の処理結果は変化しない定数としてforループの中で繰り返し使用される。それに対し、もう一つの引数id_resultは、反復の都度、最新のid_currentの値に更新される。
【００４５】
このようなスクリプトが与えられた場合、処理制御手順解釈部２０は、図１に示すように、まず最初に(11)式が示す処理を実行すべきと判断する。
【００４６】
処理制御部１０は、処理制御手順解釈部２０に処理指示を受け取りに行き（Ｓ１４）、これに応じて処理指示を受け取ることができたかどうかを判定する（Ｓ１６）。上記スクリプト例の場合、最初には(11)式が表す処理指示が取得できるので、この判定結果はＹｅｓとなりＳ１８に進む。Ｓ１８では、その処理指示が、スクリプト実行の指示か否かを判定する。処理指示には、上述の(2)式に示したデータ処理部３０を起動する指示と、(3)式に示したスクリプト実行の指示とがあるので、Ｓ１８ではそのうちのどちらであるかを判定するわけである。
【００４７】
(11)式が表す処理指示の場合、データ処理部３０を起動する指示なので、Ｓ１８の判定結果はＮｏとなり、Ｓ２０に進むことになる。Ｓ２０では、その指示が示すデータ処理部３０を起動する。例えば(11)式の処理指示の場合、処理制御部１０は、データ処理部３０−１のexecuteメソッド３２−１を、引数"url1"を指定して起動する。データ処理部３０−１は、"url1"が示す原料データを原料データ記憶部４０から取得し、executeメソッド３２−１によりその原料データに対して所定の処理を施す。executeメソッド３２−１は、処理結果記憶部５０のregisterメソッド５１を呼んで、その処理の処理結果"Ａ１"を処理結果管理テーブル５３に登録する。registerメソッド５１は、処理結果"Ａ１"に対して処理結果ＩＤ"id1"を付与して処理結果管理テーブル５３に登録し、その処理結果ＩＤ"id1"をデータ処理部３０−１に返す。
【００４８】
なお、ここで、処理結果管理テーブル５３に対する処理結果の登録は、executeメソッド３２−１の処理結果のデータが全て揃う前に行うこともできる。
【００４９】
データ処理部３０−１は、処理結果記憶部５０のregisterメソッド５１からの返り値として処理結果ＩＤ"id1"を受け取り、その"id1"を自らの処理の返り値として処理制御部１０に返す。処理制御部１０は、そのデータ処理部３０−１からのその処理結果ＩＤ"id1"を取得すると（Ｓ２２）、Ｓ１４に戻り、処理制御手順解釈部２０から次の処理指示の取得を試みる。
【００５０】
上述のスクリプト例"script1.groovy"の場合、(11)式の処理の次には、forループの１回目の(12)式の処理となる。したがって、Ｓ１６の判定結果はＹｅｓ、Ｓ１８の判定結果はＮｏとなり、Ｓ２０でデータ処理部３０−２のexecuteメソッド３２−２を呼び出すことになる。この呼出の際の第１の引数id_constは、先ほどのデータ処理部３０−１の処理結果の処理結果ＩＤ"id1"である。第２の引数id_resultは最初のループなので、デフォルト値である。呼び出されたexecuteメソッド３２−２は、処理結果記憶部５０のaccessメソッド５２を呼び出して、第１及び第２の引数（処理結果ＩＤ）が示す処理結果実体のデータを処理結果管理テーブル５３から取得する。図１では、繁雑さを避けるため、処理結果ＩＤ"id1"に対応する処理結果実体"Ａ１"を取得する流れのみ示した。そしてexecuteメソッド３２−２は、取得した２つの実体データに対して所定のデータ処理を施し、その処理結果"Ａ２"をregisterメソッド５１により処理結果管理テーブル５３に登録し、その処理結果のＩＤ"id2"を取得して処理制御部１０に返す。処理制御部１０はその処理結果ＩＤ"id2"を取得してＳ１４に戻る。上記スクリプト例における次の処理は、受け取った処理結果ＩＤ"id2"を変数id_resultにセットするものなので、処理制御部１０はそれを実行し、再びＳ１４に進む。
【００５１】
今回のステップＳ１４では、処理制御部１０は、上述のスクリプト例におけるforループの２回目の(12)式の処理指示を受け取るので、Ｓ２０で第１の引数id_constを"id1"、第２の引数id_resultを"id2"として、データ処理部３０−２のexecuteメソッド３２−２を呼び出し、その処理結果のＩＤを取得してＳ１４に戻る。以上のような処理がforループの最後のループまで繰り返される。図１では、最後のループでのデータ処理部３０−２の処理結果の処理結果ＩＤは"idN"であり、この時点で変数id_resultの値は"idN"となる。最後のループが終わった後に戻ってきたＳ１４では、次の処理指示はないので、処理制御部１０の処理はＳ２４に進む。
【００５２】
Ｓ２４では、今実行しているスクリプトが、別のスクリプトから呼び出されたものかそうでないかで、以降の処理がＳ２６とＳ２８の２つに分岐する。
【００５３】
すなわち、スクリプトの中には、クライアント２からのリクエストにより起動されたサーブレット（処理制御部１０）から呼び出されるスクリプトと、スクリプト中から上記(3)式のような式で呼ばれるスクリプトとがある。後者は上述のスクリプト例には含まれないが、仮に上記(3)式のような処理指示がスクリプト中に含まれていたとすれば、その処理指示の番ではＳ１８の判定結果がＹｅｓとなる。この場合、処理制御部１０は、Ｓ１２に戻り、Evaluatorクラスのevalメソッド１２を起動し、処理指示の式に示されているスクリプトの呼び出しを行わせることになる。このようにスクリプト中のある式により呼び出されたスクリプトの最終的な処理結果は、その式の返り値として呼出元のスクリプトに渡されることになる。それに対し、クライアント２のリクエストから呼び出されたスクリプトの処理結果は、クライアント２に返される。
【００５４】
ここで、スクリプトに返される処理結果は、ホスト１内で利用されるのだから処理結果ＩＤでよい。これを受け取った処理制御部１０は、必要に応じてその処理結果ＩＤに対応する処理結果実体を処理結果記憶部５０から取得できる。これに対し、クライアント２にはリクエストに対する結果として処理結果の実体データを返す必要がある。このような区別に従い、Ｓ２４の分岐では、現在実行中のスクリプトａが別のスクリプトｂから呼び出されたものであるならば、処理制御部１０は、スクリプトａの最終的な処理結果の処理結果ＩＤをスクリプトｂに返す（Ｓ２６）。この処理結果ＩＤを受け取ったスクリプトｂでは、そのＩＤを用いて残りの処理を続行することになる。一方、現在実行中のスクリプトａがクライアント２からのリクエストにより呼び出されたものであれば、処理制御部１０は、そのスクリプトａの終了時点で変数id_resultにセットされている処理結果ＩＤに対応する処理結果実体を、accessメソッド５２により処理結果記憶部５０から取り出し、これをＨＴＴＰレスポンスにセットして、呼出元のクライアント２に返す。
【００５５】
このように、本実施形態では、各データ処理部３０の処理結果（これはリクエスト全体の処理から見れば中間処理結果である）をシステム共有の記憶領域である処理結果記憶部５０にて、一意的な処理結果ＩＤを付与して管理している。そして、処理を記述するスクリプトではその処理結果ＩＤを用いて処理の引数や返り値のデータを示している。このようなことにより、同じ処理を繰り返し実行する無駄を省くことができる。例えば、上述のスクリプト例では、forループ内の(12)式には、そのループの前にある(11)式の処理結果が引数に指定されているが、その引数の値はループの繰り返し回数によらず変わらない。したがって、一度処理した(11)式の処理結果の処理結果ＩＤをその引数に指定しておけば、処理結果記憶部５０に保持された(11)式の処理結果を繰り返し利用できるため、forループの繰り返しの都度(11)式を再計算するというような無駄はない。
【００５６】
また、本実施形態では、各データ処理部３０が求めた処理結果が処理結果記憶部５０に保存されているので、クライアント２からのリクエストに対する全体的な処理の途中の各段階での処理結果を必要に応じて観察することができるので、不具合が発生した場合の調査が容易になる。例えば、エラーコードに処理の引数である処理結果ＩＤなどを含めるようにすれば、エラー発生時のエラーコードに示される処理結果ＩＤを用いて処理結果実体を処理結果記憶部５０から読み出すことができ、調査ができる。
【００５７】
本実施形態において、処理結果記憶部５０のPoolオブジェクトを、オブジェクトへのデータの書き込みとオブジェクトからのデータの読み出しを並行して行える同期型オブジェクトとすることが好適である。このようにすることにより、データ処理部３０は、自分の処理結果が出そろう前に処理結果記憶部５０のregisterメソッド５１を呼んで処理結果の記憶領域の確保と処理結果ＩＤの取得を行い、その処理結果ＩＤを処理制御部１０に返すことができる。これを受けて、処理制御部１０は、そのデータ処理部３０の処理結果を用いる後段のデータ処理部３０をその処理結果ＩＤを用いて起動することができる。すなわち、前のデータ処理部３０の処理が全て終わる前に後のデータ処理部３０を起動できる。別の観点から言えば、前のデータ処理部３０の処理の終了は、その処理の結果を利用する他のデータ処理部３０がその処理結果を必要とする時点まで遅らせることができる。このようなことから、効率的な連携処理が可能となる。
【００５８】
［第２実施形態］
次に本発明の第２実施形態を説明する。図４は、第２実施形態のホスト１の機能構成を示す図である。この図では、クライアント２の図示は省略している。また、図１の構成要素と同様のものには、同一符号を付して詳しい説明は書略する。
【００５９】
第２実施形態のホスト１は、図１の第１実施形態のホスト１に対して利用可能範囲制御部６０と有効期間管理部７０を追加し、更に処理結果記憶部５０にremoveメソッド５４を追加したものである。またこの他、処理制御部１０や各データ処理部３０、処理結果記憶部５０の処理内容にも若干の追加がある。以下、これら追加点につき説明する。
【００６０】
まず、利用可能範囲制御部６０は、リクエストが、処理結果記憶部５０にある別のリクエストの処理結果にアクセスできないようにする管理のためのユニットである。
【００６１】
すなわち、第１実施形態では、リクエストの処理のために起動された各データ処理部３０の処理結果を処理結果記憶部５０に登録し、処理制御部１０や別のデータ処理部３０から利用できるようにしたが、ホスト１には様々なリクエストが到来し、異なるユーザからのリクエストも到来するため、異なるリクエストに関連する処理結果が利用できると、情報セキュリティその他の観点から好ましくない。
【００６２】
そこで、１つのリクエストに関連して起動されるスレッドに対しては利用可能範囲制御部６０が生成する同じ識別情報を付与し、処理結果記憶部５０に登録する処理結果についても、その識別情報と関連づけて管理することで、処理結果が他のリクエストから利用できないように制御する。逆に１つのリクエストの実行過程で起動される一連のスレッド群では、処理の連携のためにスレッド同士で処理結果を共有する必要があり、また同じリクエスト内ではそのようにスレッド間で処理結果を共有できてもセキュリティ上の問題はない。そこで、本実施形態では、リクエストに対して一意的な識別情報を付与し、そのリクエストの実行過程で起動されるスレッドは、常に起動元のスレッドに設定された識別情報を引き継ぎ、また、その処理結果にも識別情報を持たせて管理することで、同じリクエスト内のスレッド同士は処理結果を互いに参照でき、異なるリクエストに属するスレッド同士では処理結果の参照ができないように制御する。このように、リクエストを識別する識別情報を、以下では「利用可能範囲ＩＤ」と呼ぶ。
【００６３】
この管理のため、利用可能範囲制御部６０は、利用可能範囲ＩＤ管理テーブル６６を備える。利用可能範囲ＩＤ管理テーブル６６には、図５に示すように、利用可能範囲ＩＤごとに、その利用可能範囲ＩＤが割り当てられたリクエストの処理過程での各データ処理部３０の処理結果の処理結果ＩＤの配列が登録される。
【００６４】
利用可能範囲制御部６０は、例えばＪａｖａ（登録商標）等のクラスとして実装することができる。そのクラス名を、ここではVirtualThreadManagerとする。VirtualThreadManagerは、以下のようなメソッドを備える。
【００６５】
・openメソッド６１：このメソッドは、呼び出されると、一意的な利用可能範囲ＩＤを生成し、利用可能範囲ＩＤ管理テーブル６６にその利用可能範囲ＩＤに対応するエントリを作成する。利用可能範囲ＩＤは、例えば、通し番号を採番するなどの形で生成すればよい。このメソッドは、処理制御部１０から呼ばれ、生成した利用可能範囲ＩＤをこのメソッドを実行しているスレッドに設定する。
【００６６】
・closeメソッド６２：このメソッドは、呼び出されると、このメソッドを実行しているスレッドに設定されている利用可能範囲ＩＤを取得し、その利用可能範囲ＩＤに該当するエントリを利用可能範囲ＩＤ管理テーブル６６から削除する。またこのとき、削除するエントリの処理結果ＩＤ配列を引数として処理結果記憶部５０のremoveメソッドを呼び、その利用可能範囲に属する各処理結果を削除させる。このメソッドは、リクエストの処理が完了するときに、処理制御部１０から呼ばれる。クライアント２からのリクエストに対する中間処理結果は、そのリクエスト以外のリクエストからは基本的に必要ない（但し後述のスクリプトのデバッグのためのリクエストはこの限りでない）ので、リクエスト処理の終了時にこのように削除することで、利用可能なメモリ領域を増やすことができる。
【００６７】
・addメソッド６３：このメソッドは、新たに処理結果記憶部５０に登録された処理結果のＩＤを利用可能範囲ＩＤ管理テーブル６６に追加する際に呼ばれる。このメソッドには、呼出元から、引数として、その処理結果ＩＤが渡される。このメソッドは、呼ばれると、このメソッドを実行しているスレッドに設定されている利用可能範囲ＩＤを取得し、利用可能範囲ＩＤ管理テーブル６６におけるその利用可能範囲ＩＤに該当するエントリの処理結果ＩＤ配列に対し、引数として受け取った処理結果ＩＤを追加する。
【００６８】
・validateメソッド６４：このメソッドは、スレッドが処理結果記憶部５０に登録されている処理結果にアクセスしようとする際に、そのスレッドがその処理結果を利用（アクセス）できるかどうかを判定するためのものである。このメソッドには、呼出元から、引数として、その処理結果の処理結果ＩＤが渡される。このスレッドは、呼び出されると、このメソッドを実行しているスレッドに設定されている利用可能範囲ＩＤを取得し、利用可能範囲ＩＤ管理テーブル６６におけるその利用可能範囲ＩＤに該当するエントリの処理結果ＩＤ配列の中に、引数として渡された処理結果ＩＤが含まれているかをチェックする。そして、含まれている場合はそのスレッドがその処理結果を利用可能と判定し、そうでない場合は利用不可と判定する。呼出元には、その判定結果を返す。
【００６９】
・removeメソッド６５：このメソッドは、処理結果記憶部５０からの処理結果の削除に伴って、その処理結果の処理結果ＩＤを利用可能範囲ＩＤ管理テーブル６６の処理結果ＩＤ配列から削除するために用いられる。このメソッドには、呼出元から、引数として処理結果ＩＤが渡される。このメソッドは、このメソッドを実行しているスレッドに設定されている利用可能範囲ＩＤを取得し、利用可能範囲ＩＤ管理テーブル６６におけるその利用可能範囲ＩＤに該当するエントリの処理結果ＩＤ配列から、引数の処理結果ＩＤを削除する。
【００７０】
次に、有効期間管理部７０について説明する。有効期間管理部７０は、処理結果記憶部５０の記憶領域の費消を抑制するための管理を行うユニットである。すなわち本実施形態では、スクリプト中に有効期間の始点と終点を明示的記述し、スクリプト中でその始点から終点までの間に記述された各処理の処理結果は、その始点から終点までの間のみ有効とする。別言すれば、スクリプトの処理の進行がその終点を超えると（すなわち有効期間が終了すると）、対応する始点からその終点までに記述された処理の処理結果を処理結果記憶部５０から削除する。スクリプト作成者が後で使うことがない処理結果の削除を明示的にスクリプトに記述することで、使用されない処理結果のデータにより処理結果記憶部５０の記憶領域が無駄に費消されるのを抑制できる。
【００７１】
このように有効期間の終了後に関連する処理結果を削除するために、本実施形態では、処理結果記憶部５０に登録する処理結果に対し、有効期間ＩＤを関連づける。有効期間ＩＤは、個々の有効期間に対して一意的に付与される識別情報である。スクリプトを実行して有効期間の始点に至ったときに、一意的な有効期間ＩＤを生成（例えば通し番号の採番）する。そして、その始点に対応する終点に至るまでに起動するスレッドに、その有効期間ＩＤを設定し、処理結果記憶部５０に対して処理結果を登録する場合には、登録処理を実行しているスレッドから有効期間ＩＤを取得し、その有効期間ＩＤを関連づけて登録する。これにより、スクリプトの処理が進んで有効期間の終点を超えると、その有効期間ＩＤと関連づけられた処理結果を検索することで、その有効期間内の処理結果を処理結果記憶部５０から一括削除できる。
【００７２】
この管理のため、有効期間管理部７０は、有効期間ＩＤ管理テーブル７５を備える。有効期間ＩＤ管理テーブル７５には、図６に示すように、有効期間ＩＤごとにエントリが作成され、エントリにはその有効期間ＩＤが割り当てられた範囲の中の処理記述により起動された各データ処理部３０の処理結果のＩＤの配列が登録される。
【００７３】
有効期間管理部７０は、例えばＪａｖａ（登録商標）等のクラスとして実装することができる。そのクラス名を、ここではScopeManagerとする。ScopeManagerは、以下のようなメソッドを備える。
【００７４】
・openメソッド７１：このメソッドは有効期間の始点で呼び出される。言い換えれば、スクリプト中に有効期間を設定する場合、その期間の始点に当たる位置に、このメソッドを呼び出す式を記述するのである。このメソッドは、処理制御部１０から呼び出される。呼び出された場合、このメソッドは、一意的な有効期間ＩＤを生成し、これを有効期間ＩＤ管理テーブル７５に登録するとともに、生成した有効期間ＩＤをこのメソッドを実行しているスレッドに設定する。
【００７５】
・closeメソッド７２：このメソッドは、有効期間の終了時に、その有効期間に属するスレッドの処理結果を一括削除するために、処理制御部１０から呼ばれる。このメソッドは、呼び出されると、メソッドを実行しているスレッドに設定されている有効期間ＩＤ（これはopenメソッドが呼出元から呼び出された際に設定される）を取得し、有効期間ＩＤ管理テーブル７５からそのＩＤに該当するエントリを削除する。またこのとき、削除するエントリの処理結果ＩＤ配列を引数として処理結果記憶部５０のremoveメソッド５４を呼び、その利用可能範囲に属する各処理結果を削除させる。なお、このとき呼び出されたremoveメソッド５４は、引数として受け取った処理結果ＩＤのエントリを処理結果管理テーブル５３から削除すると共に、利用可能範囲制御部６０のremoveメソッド６５を呼び出し、その処理結果ＩＤを利用可能範囲ＩＤ管理テーブル６６から削除するよう依頼する。
【００７６】
・addメソッド７３: このメソッドは、新たに処理結果記憶部５０に登録された処理結果のＩＤを有効期間ＩＤ管理テーブル７５に追加する際に呼ばれる。このメソッドには、呼出元から、引数として、その処理結果ＩＤが渡される。このメソッドは、呼ばれると、このメソッドを実行しているスレッドに設定されている有効期間ＩＤを取得し、有効期間ＩＤ管理テーブル７５におけるその有効期間ＩＤに該当するエントリの処理結果ＩＤ配列に対し、引数として受け取った処理結果ＩＤを追加する。
【００７７】
・exportメソッド７４：スクリプト中に設定した有効期間の範囲内の処理の処理結果のうち、有効期間外の処理で利用したいものがある場合、このメソッドが用いられる。すなわち、スクリプト中にこのメソッドを呼び出す式を記述することで、その式が含まれる有効期間が終了した後も、そのメソッドの引数に指定した処理結果ＩＤに対応する処理結果が削除されず残されるようにすることができる。このメソッドは、対象となる処理結果ＩＤと、別の有効期間ＩＤを引数として呼び出され、このメソッドを実行しているスレッドに設定されている有効期間ＩＤを取得し、引数として受け取った処理結果ＩＤを有効期間ＩＤ管理テーブル７５におけるその有効期間ＩＤに該当するエントリの処理結果ＩＤ配列から、引数として受け取った別の有効期間ＩＤに該当するエントリの処理結果ＩＤ配列に移動させる。これにより、有効期間ＩＤを削除するために、有効期間管理部７０のcloseメソッドが呼び出された場合でも、別の有効期間ＩＤのエントリに移動させた処理結果ＩＤに対応する処理結果は、処理結果記憶部５０から削除されない。
【００７８】
次に、第１実施形態からみた本実施形態の処理結果記憶部５０の変更点について説明する。
【００７９】
まず本実施形態では、removeメソッド５４が追加されている。このremoveメソッド５４は、処理結果管理テーブル５３から処理結果のエントリを削除するためのものである。このメソッドは、例えばクライアント２からのリクエストに対する処理の終了時に利用可能範囲制御部６０から呼ばれたり、有効期間の終点で有効期間管理部７０から呼ばれたりする。このメソッドは、引数として処理結果ＩＤの配列をとる。
【００８０】
また、registerメソッド５１及びaccessメソッド５２は、第１実施形態で説明した処理に加え、以下のような処理を行う。
【００８１】
まずregisterメソッド５１は、呼び出された場合、そのメソッド５１を実行しているスレッドに設定されている利用可能範囲ＩＤ，有効期間ＩＤを取得する。そして、利用可能範囲制御部６０のaddメソッド６３及び有効期間管理部７０のaddメソッド７３をそれぞれ呼び出して、そのregisterメソッド５１が処理結果管理テーブル５３に登録した処理結果の処理結果ＩＤを引数として渡す。これを受けたaddメソッド６３は、利用可能範囲ＩＤ管理テーブル６６において、このメソッドを実行するスレッドに設定された利用可能範囲ＩＤに対応するエントリの処理結果ＩＤ配列に対し、引数の処理結果ＩＤを追加する。addメソッド７３の場合は、有効期間ＩＤ管理テーブル７５に追加する。
【００８２】
またaccessメソッド５２は、呼出元から引数として渡された処理結果ＩＤに対応する処理結果実体を返す前に、その呼出元がその処理結果実態を利用できるかどうかを調査する。この調査は、利用可能範囲制御部６０のvalidateメソッド６４を呼び出すことで行う。すなわち、accessメソッド５２は、呼出元から受け取った処理結果ＩＤを引数としてvalidateメソッド６４を呼び出す。validateメソッド６４は、前述の通り、メソッドを実行するスレッドに設定された利用可能範囲ＩＤを取得し、引数として渡された処理結果ＩＤがアクセスできるかを判定し、その結果をaccessメソッド５２に返す。accessメソッド５２は、アクセス可能との判定結果を受け取った場合は、その処理結果ＩＤに対応する実体データを処理結果管理テーブル５３から読み出し、呼出元に返す。アクセス不可との判定結果を受け取った場合は、アクセス不可の旨を示す値を呼出元に返す。
【００８３】
以上のように、有効期間管理部７０は、利用可能範囲制御部６０と似た部分があるが、根本的な相違は、有効期間管理部７０は、スクリプト中に記述された処理指示に応じて呼び出されるのに対し、利用可能範囲制御部６０は、スクリプトに記述するものではなく、リクエストの処理開始時と終了時に処理制御部１０から必ず呼び出されるという点である。
【００８４】
次に、図７を参照して、この実施形態でのリクエスト処理の流れを説明する。なお、図７において、図３に示した第１実施形態の手順の中のステップと同様の処理を行うステップについては、同一符号を付して詳細な説明を省略する。
【００８５】
図７の手順は、図３の手順のステップＳ１０の前にステップＳ５を、ステップＳ２８の後にステップＳ３０を追加したものである。
【００８６】
この手順では、ホスト１の処理制御部１０は、クライアント２からリクエストを受け取ると、まず利用可能範囲制御部６０のopenメソッド６１(VirtualThreadManager.open)を呼び、利用可能範囲ＩＤの付与を受ける（Ｓ５）。これに続くステップＳ１０以降の処理は、最後のステップＳ３０の処理を除き、図３の手順と基本的に同じ処理を行う。但し、細かくみれば、処理制御部１０は、自らが呼び出す処理スレッドに対して、付与を受けた利用可能範囲ＩＤを設定する処理を行う点は、第１実施形態にはない点である。
【００８７】
すなわち、ステップＳ５で、利用可能範囲ＩＤを受け取った処理制御部１０は、自らのスレッドの変数に対してその利用可能範囲ＩＤを設定すると共に、以降、自らが呼び出すスレッドに対しても、その利用可能範囲ＩＤを設定する。例えば、そのリクエストのスクリプトの実行過程においてステップＳ２０で呼び出すデータ処理部３０や、ステップＳ１８の判定がＹｅｓとなった後ステップＳ１２でそのスクリプトから呼び出すスクリプト（更に呼び出したスクリプトから呼び出すスクリプトなどの派生スクリプトも含む）の実行のために新たなスレッドを起動する場合には、そのスレッドに対して利用可能範囲ＩＤをセットするわけである。
【００８８】
なお、ステップＳ２０で呼び出されたデータ処理部３０の処理においても新たなスレッドを起動することがあれば、自スレッドの変数に設定されている利用可能範囲ＩＤを、新たに起動するスレッドの変数に設定する。
【００８９】
このようにスレッドの変数に利用可能範囲ＩＤを連鎖的に設定していくことで、１つのリクエストから派生する全ての処理ユニットのスレッドには同一の利用可能範囲ＩＤが関連づけられることになる。これにより、各処理ユニットの処理(スレッド)がどの利用可能範囲に属している（すなわちどのリクエストから派生したものか）かは、スレッドの変数をみれば分かることになる。
【００９０】
その一方、本実施形態では、データ処理部３０の処理結果を処理結果記憶部５０に登録する際に、その処理結果に付与された処理結果ＩＤを、そのデータ処理部３０に設定された利用可能範囲ＩＤと関連づけてaddメソッド６３により利用可能範囲ＩＤ管理テーブル６６に登録するので、このテーブル６６を利用すれば処理結果がどの利用可能範囲に属するものかが分かる。
【００９１】
そこで、処理結果記憶部５０は、データ処理部３０や処理制御部１０などからaccessメソッド５２により処理結果へのアクセスを要求された場合、validateメソッド６４を用いて利用可能範囲制御部６０へ問い合わせを行うことで、それらデータ処理部３０や処理制御部１０のスレッドがその処理結果にアクセス可能であるか否かを知ることができる。そして、アクセス可能であれば処理結果記憶部５０は呼出元に対し処理結果の実体を返し、そうでなければアクセス不可の旨を知らせる情報を返す。
【００９２】
そして、クライアント２からのリクエストに指定されたスクリプトの処理が終わりクライアント２に処理結果を返す（Ｓ２８）と、Ｓ３０にて処理制御部１０は利用可能範囲制御部６０のcloseメソッド６２を呼び、そのリクエストの利用可能範囲ＩＤと、これに関連づけられた処理結果の情報を、利用可能範囲制御部６０及び処理結果記憶部５０から削除する。リクエストの実行過程で登録された処理結果は、そのリクエストの処理が終了した後に他のリクエストから利用されることは基本的にはないので、Ｓ３０でデータを削除しても問題はない。
【００９３】
なお、この手順において、有効期間管理部７０を利用して不要になった処理結果を速やかに削除するのは、スクリプトに記述されたopenメソッド７１やcloseメソッド７２を、処理制御部１０がステップＳ２０で呼び出すことで実行される。
【００９４】
例えば次のようなスクリプトが与えられたとする。
id4 = Component4.execute(param4);       …(21)
ida = function_a(urla, urlb);             …(22)
return Component5.merge(id4, ida);    …(23)
function_a(URL url1, URL url2)[
sid = (VirtualThread.currentThread()).getScopeID();    … (24)
ScopeManager.open();       … (25)
id1 = Component1.execute(url1);
id2 = Component2.execute(url2);
id3 = Component3.merge(id1, id2);
ScopeManager.export(id3, sid);        … (26)
ScopeManager.close();         … (27)
return id3;
]
【００９５】
このスクリプトにおいて、ScopeManagerは有効期間管理部７０を示し、ComponentN（Ｎは１〜５の整数）はそれぞれ異なる５つのデータ処理部３０を示す。
【００９６】
また、(21)式から(23)式が実行するスクリプトで、"function_a()"以降は関数定義を表している。
【００９７】
まず、(21)式で示されたComponent4の処理が実行され、この処理結果id4と、function_aに引数"urla"と"urlb"を指定したときの処理結果idaとが、(23)式でComponent5により併合され、その併合結果がスクリプトの呼び出し側に返される。
【００９８】
function_aにおいては、関数内で生成された処理結果のうち、id3に対応する処理結果のみを残して、それ以外は削除するための手順を示している。
【００９９】
function_aにおいて、まず(24)式の実行により、現在のスレッドに設定されている有効期間ＩＤを取得し、変数sidに格納する。sidに格納した有効期間ＩＤは、function_aの呼び出し側の有効期間ＩＤと同一である。次に、(25)式(openメソッド)の実行より有効期間ＩＤの付与を受ける。その次の２つの式では、Component1,Component2がurl1,url2の示す原料データを元に所定の処理をそれぞれ行う。これら２つの処理の結果は、次の式により、Component3により併合される。この併合（マージ）処理の結果の処理結果ＩＤは変数id3 にセットされる。この処理結果(id3)は、関数定義の外、例えば(23)式でも利用するので、(27)式により有効期間を閉じる前に、(26)式でのexportメソッド７４を呼び出すことで、id3を有効期間終了時のデータ削除対象から外す。そして、(27)式(closeメソッド)の実行により、(25)式から始まる有効期間が閉じられて、その期間内で求められた処理結果が処理結果記憶部５０から削除される。このスクリプト例では、id3は削除対象から外されているので、処理結果ＩＤid1及びid2に対応する各処理結果実体が処理結果記憶部５０から削除されることになる。
【０１００】
以上、第２の実施形態について説明した。この実施形態によれば、利用可能範囲制御部６０の働きより、リクエストの途中段階での処理結果が、別のリクエストから参照されることがないので、処理結果の不正利用を防止できる。また、有効期間管理部７０により、スクリプト中に指定された有効期間が過ぎると、その期間内で生成された処理結果を削除することができるので、ホスト１の記憶領域の無駄遣いを減らすことができる。これにより、処理の途中でメモリ領域が不足し、その結果計算コストが増えたり、処理不能な状態に陥ったりすることを避けることができる。
【０１０１】
なお、以上の説明から明らかなように、利用可能範囲制御部６０と有効期間管理部７０の機能は独立している。したがって、上述の例では利用可能範囲制御部６０と有効期間管理部７０の両方を備えたホスト１を示したが、そのうち利用可能範囲制御部６０のみを備える構成、有効期間管理部７０のみを備える構成でも、それぞれのユニットによる個別の効果を得ることはできる。
【０１０２】
また、以上の例では、データ処理部３０の処理結果は、同じ利用可能範囲ＩＤを持つスレッドからしかアクセスできず、また有効期間から外れると削除していたが、スクリプトのデバッグを行う場合、このように処理結果が削除されたり、他のリクエストから処理結果にアクセスできないと、デバッグが困難になってしまう。そこで、スクリプトのデバッグを容易にする第２実施形態の変形例を以下に説明する。
【０１０３】
この変形例では、利用可能範囲制御部６０と有効期限管理部７０に、デバッグモードを指示するためのメソッド(setDebug)を用意する。
【０１０４】
利用可能範囲制御部６０をVirtualThreadManagerクラス、有効期間管理部７０をScopeManagerクラスとして実装した場合、デバッグ対象のスクリプト中に以下のように記述することでデバッグモードが指示できる。
VirtualThreadManager.setDebug(true);  … (31)
ScopeManager.setDebug(true);          … (32)
【０１０５】
このような記述より後に示された記述の処理については、利用可能範囲制御部６０と有効期限管理部７０のそれぞれについてデバッグモードの取扱がなされる。
【０１０６】
例えば、利用可能範囲ＩＤ管理テーブル６６には、各利用可能範囲ＩＤがデバッグ対象であるか否かを示すフラグが設けられる。このフラグは、デフォルトでは「デバッグ対象でない」ことを示す値にセットされている。利用可能範囲制御部６０のsetDebugメソッドは、呼び出されると、その利用可能範囲ＩＤ管理テーブル６６において、メソッドを実行しているスレッドに設定された利用可能範囲ＩＤがデバッグ対象か否かを示すためのフラグを「デバッグ対象」を示す値にセットする。そして、利用可能範囲制御部６０のcloseメソッド６２は、呼び出されると、メソッドを実行しているスレッドに設定された利用可能範囲ＩＤがデバッグ対象か否かをそのフラグを参照して判定し、デバッグ対象であれば、利用可能範囲ＩＤ管理テーブル６６の登録情報の削除や、その利用可能範囲ＩＤのエントリに登録された処理結果ＩＤの情報の処理結果記憶部５０からの削除の処理を実行しない。デバッグ対象でなければ、上述の通り、それらの情報の削除を行う。また、利用可能範囲制御部６０のvalidateメソッド６４は、呼び出されると、メソッドを実行しているスレッドに設定された利用可能範囲ＩＤがデバッグ対象か否かをそのフラグを参照して判定し、デバッグ対象であれば、そのvalidateメソッド６４呼出の引数である処理結果ＩＤが利用可能範囲ＩＤ管理テーブル６６中のその利用可能範囲ＩＤのエントリに登録されているかどうか調べずに、利用可能の旨を示す返り値を処理結果記憶部５０に返す。
【０１０７】
同様に、有効期間管理テーブル７５には、各有効期間ＩＤがデバッグ対象であるか否かを示すフラグが設けられ、これは有効期間管理部７０のsetDebugメソッドによりセットされる。そして、有効期間制御部７０のcloseメソッド７２は、呼び出されると、呼出元から渡された利用可能範囲ＩＤがデバッグ対象か否かをそのフラグを参照して判定し、デバッグ対象であれば、有効期間ＩＤ管理テーブル７５の登録情報の削除や、その有効期間ＩＤのエントリに登録された処理結果ＩＤの情報の処理結果記憶部５０からの削除などの処理を実行しない。
【０１０８】
また、デバッグモードの範囲の末尾を、引数をfalseに設定したsetDebugメソッドの記述により示すこともできる。
【０１０９】
このようにして、デバッグモードが指定されている間、利用可能範囲制御部６０と有効期限管理部７０のcloseメソッドの処理では、処理結果記憶部５０に対するremove指示を行わないようにする。また、利用可能範囲制御部６０のvalidateメソッドの処理では、利用可能判定を行わないようにすることができる。
【０１１０】
以上のことにより、一連の処理が終了しクライアント２に処理結果を返した後も、処理結果記憶部５０には、デバッグモードの範囲内の処理結果が残り、しかもそれら残った処理結果に対するアクセスが利用可能範囲制御部６０により制限されることもない。したがって、処理結果記憶部５０に残った処理結果を調べることで、効率のよいデバッグを行うことが可能になる。
【０１１１】
また、本実施形態では、処理結果は、それぞれ利用可能範囲制御部６０にて利用可能範囲ＩＤと関連づけて管理されているので、スクリプトのデバッグの際、利用可能範囲ＩＤを指定すれば、その利用可能範囲ＩＤに対応する処理結果群を取り出し、解析することができる。
【０１１２】
［第３実施形態］
第１及び第２実施形態は、１つのホスト１で複数のデータ処理部３０が単位処理を連携実行する構成であった。これに対し、この第３実施形態は、図８に示すように、複数のホスト１Ｐ，１Ｒが、インターネット等のネットワーク３を介して処理の連携を行うシステム構成である。
【０１１３】
ホスト１Ｐ及び１Ｒの内部構成は、図４に示した第２実施形態のものと同様である。ただし、ホスト１Ｐ及び１Ｒ内の各ユニットには、ネットワーク３を介した処理連携のための機能が加わっている。
【０１１４】
処理連携を行うホスト１Ｐ及び１Ｒは、クライアント２からのリクエストを受け付けるポータル（玄関）のホスト１Ｐと、他のホスト（１Ｐ又は１Ｒ）からのリクエストを受けて動作するリモートホスト１Ｒとに分類できる。このシステムでは、ユーザがクライアント２からホスト１Ｐへリクエストを送ると、ホスト１Ｐがそのリクエストに指定されたスクリプトを実行するのであるが、そのスクリプトの中にリモートのホスト１Ｒが持つスクリプトの実行が記述されていれば、ホスト１Ｐはそのリモートホスト１Ｒにスクリプト実行のリクエストを送り、その処理結果を受けて自分の処理を続行する。リモートホスト１Ｒが実行するスクリプトの中にも、他のホスト１Ｐ又は１Ｒが実行するスクリプトの実行指示を記述することができる。ホスト１Ｐ又は１Ｒへのリクエストは、上記第１実施形態に例示したＵＲＬ(1)と同様、ＵＲＬの形で記述される。
【０１１５】
ネットワーク３を介した処理連携のため、各ホスト１Ｐ及び１Ｒの処理制御部１０は、別のホスト１Ｐ又は１Ｒの処理制御部１０にスクリプト実行を指示するリクエストを作成する機能を備える。この機能は、例えばevalメソッド１２に組み込めばよい。例えば、スクリプト中に記述された次の(41)式は、host1（これはこのスクリプトを実行中のホストhost0とは別のホストであるとする）という名のホスト１Ｐ又は１Ｒに対し、 "script1.groovy"という名のスクリプトを、id1という処理結果ＩＤが示すデータを引数として実行させる旨を示している。
id2 = Evaluator.eval(host1, "script1.groovy", id1)        … (41)
スクリプト実行中のhost0の処理制御部１０は、(41)式の指示を受けると、host1に対するリクエストとして、次のようなＨＴＴＰリクエストを作成し、host1宛に送信する。
http://host1.domain/Evaluator?method=eval&script=script1.groovy&arg0=id1…(42)
【０１１６】
host1の処理制御部１０は、そのＵＲＬに示されるスクリプトを実行し、その処理結果の処理結果ＩＤを含んだＨＴＴＰレスポンスを作成し、これを呼出元のホストhost0に返す。レスポンスを受け取ったhost0の処理制御部１０は、そのレスポンスに含まれる処理結果ＩＤの値を(41)式の変数id2に代入し、その後に続く式の処理に進む。そして、後続の処理でその処理結果が利用されることになった時点で、その処理結果ＩＤ"id2"に該当する処理結果実体を、host1からコピーする。
【０１１７】
すなわち、host0におけるスクリプト実行の際、データ処理部３０又は処理制御部１０が処理結果ＩＤ"id2"に該当する処理結果実体を用いて処理を行うことになった場合、データ処理部３０又は処理制御部１０は、自ホストhost0の処理結果記憶部５０に対し、accessメソッド５２を用いてそのid2の実体を要求する。ここで、id2に対応する実体データがhost0の処理結果記憶部５０に保持されている場合は、その実体データが呼出元に返される。これに対し、id2に対応する実体データがhost0の処理結果記憶部５０にない場合は、accessメソッド５２がそのid2に対応する処理結果実体を要求するＨＴＴＰリクエストを作成し、それをその処理結果実体を持つホストhost1に送る。このとき作成されるＨＴＴＰリクエストは、例えば次のようなものとなる。
http://host1.domain/Pool?method=access&eid=12345678    … (43)
【０１１８】
ここで、eidは処理結果ＩＤを示し、12345678は要求する処理結果ＩＤの値であり、言い換えれば(41)式のリクエストに対してhost1から返された処理結果ＩＤの値である。このリクエストは、host1のPoolクラス（すなわち処理結果記憶部５０）のaccessメソッド５２を呼び出し、その処理結果ＩＤに対応する処理結果実体を渡す旨を指示するものである。これにより取り出された処理結果実体は、ＨＴＴＰレスポンスに組み込まれて、呼出元であるhost0の処理結果記憶部５０に返される。host0の処理結果記憶部５０は、受け取った処理結果実体を、accessメソッド呼出元のデータ処理部３０又は処理制御部１０に渡すと共に、その処理結果実体を処理結果ＩＤに対応づけて処理結果管理テーブル５３に登録する。リモートホストの処理結果も、このようにして一度取得して自ホストの処理結果管理テーブル５３に登録すれば、今後のその処理結果が必要とされる場合は、処理結果管理テーブル５３から読み出すことができ、リモートホストから取得する必要がない。
【０１１９】
なお、処理結果記憶部５０のaccessメソッド５２が他のホストに処理結果実体を要求する(43)式のようなリクエストを作成するには、その処理結果実体を保持しているホストが分からなければならない。このため、本実施形態では、処理結果ＩＤとして、ホストの識別情報を含んだ形のものを用いる。例えばホストの識別情報とそのホスト内で一意な識別番号とを併合したものを処理結果ＩＤとするなどである。registerメソッド５１は、処理結果を登録する際、このような処理結果ＩＤを生成し、これをその処理結果に対して割り当てる。処理結果ＩＤ内に組み込むホストの識別情報として例えばホストのＩＰアドレスを用いれば、処理結果実体を要求するＨＴＴＰリクエストを作成する際、処理結果ＩＤからＩＰアドレスを抽出し、これを宛先のホストの指定に用いることができる。また、このようにＩＰアドレスそのものを用いなくても、処理結果ＩＤ内のホストの識別情報からそれに対応するＵＲＬやＩＰアドレスを求めて回答する手段を各ホスト内、又は各ホストからアクセス可能なネットワーク３上のサーバに設けておけば、同様のことが可能である。
【０１２０】
次に、スクリプトの例を挙げて、複数のホスト１Ｐ及び１Ｒの連携動作を説明する。ここでは、ポータルホスト１Ｐ(host0)が、クライアント２から、次のようなスクリプトの実行を要求するリクエストを受け取ったとする（但し、ここに例示するのはスクリプトの一部分だけであり、実際にはこの前後にいくつかの処理指示が記述されているものとする）。
id1 = Evaluator.eval(host1, "scriptA.groovy", parameter1) … (51)
id2 = Evaluator.eval(host2, "scriptB.groovy", id1)        … (52)
id3 = Evaluator.eval(host2, "scriptC.groovy", id1)        … (53)
【０１２１】
このスクリプトにおいて、(51), (52), (53)は、ポータルホスト１Ｐの処理制御部１０のevalメソッド１２の実行を指示する式である。evalメソッド１２の引数は、ネットワーク上での分散処理を考慮していない第１実施形態ではスクリプト名とパラメータだけであったが、本実施形態ではそれにホスト名が加わる。３つの引数のうちの先頭のhost1などが、ホスト名である。例えば(51)式は、リモートのhost1に対し、スクリプト"scriptA.groovy"を、引数parameter1を用いて実行させ、その実行の結果の処理結果ＩＤを変数id1にセットする旨の指示を示している。
【０１２２】
ポータルホスト１Ｐの処理制御部１０は、まずこの(51)式の処理指示を処理制御手順解釈部２０から受けると、リモートホストのhost1に対してスクリプト"scriptA.groovy"の実行を指示する(42)と同様のＨＴＴＰリクエストを作成して送信する。そして、そのリクエストの処理結果の処理結果ＩＤがhost1から返ってくると、それを変数id1にセットし、次の処理指示(52)の処理に移る。
【０１２３】
(52)の処理では、host0の処理制御部１０は、別のリモートホストhost2に対し、その変数id1にセットされた処理結果ＩＤを引数として"scriptB.groovy"を実行する旨のＨＴＴＰリクエストを送信する。このリクエストを受けたhost2の処理制御部１０は、その処理結果ＩＤ(id1)に対応する処理結果実体を自らの処理結果記憶部５０に要求する。ところが、この時点ではその処理結果実体はhost1にしかないので、host2の処理結果記憶部５０は、その処理結果ＩＤ(id1)に対応する処理結果実体を求める(43)と同様のＨＴＴＰリクエストを作成してhost1へと送り、これに応じてhost1から返されてきた処理結果実体をその処理結果ＩＤと対応づけて自らの処理結果管理テーブル５３に登録する。このように処理結果ＩＤ(id1)に対応する処理結果実体が得られたら、host2の処理制御部１０はスクリプトの実行を進めることができる。
【０１２４】
また、ポータルのhost0は、(53)の指示により、更にhost2に"scriptC.groovy"を実行させる。"scriptC.groovy"はid1を引数にとっているので、これに対応する処理結果実体が必要であるが、host2は既に(52)の処理でその処理結果実体を取得し、処理結果管理テーブル５３に登録済みであるので、このときは処理結果管理テーブル５３から取得できるので、リモートのhost1に要求する必要はない。
【０１２５】
このようにして、本実施形態では、複数のホスト１Ｐ及び１Ｒが連携して、クライアント２からのリクエストを実行する。
【０１２６】
以上、本実施形態におけるリクエストの分散処理の仕組みを説明したが、本実施形態でも、上述の第２実施形態と同様、リクエスト間での処理結果への不正アクセスを防止する仕組みが利用できる。
【０１２７】
すなわち、この場合、ポータルホスト１Ｐ及びリモートホスト１Ｒに第２実施形態と同様の利用可能範囲制御部６０を設ける。ただし、利用可能範囲制御部６０の機能は、ポータルホスト１Ｐとリモートホスト１Ｒとで少し異なる。すなわち、ポータルホスト１Ｐの利用可能範囲制御部６０は第２実施形態のものと同じであり、openメソッド６１が呼ばれると一意な利用可能範囲ＩＤを採番するのに対し、リモートホスト１Ｒにはopenメソッドが不要である。これは、利用可能範囲ＩＤは、クライアント２からのリクエストごとに割り当てるものであるからである。リモートホスト１Ｒは、ポータルホスト１Ｐが付与した利用可能範囲ＩＤを受け取って継承する。
【０１２８】
より具体的には、ポータルホスト１Ｐは、あるリクエストに対する処理の中でリモートホスト１Ｒにスクリプト実行を依頼する場合、これは現在実行中のスレッドの変数にセットされているそのリクエストの利用可能範囲ＩＤを取得し、これをそのリモートホスト１Ｒに対して送るＨＴＴＰリクエストに組み込む。例えば次のようにリクエストヘッダに組み込めばよい。
X-VirtualThreadID : 11111    … (61)
【０１２９】
ここでX-VirtualThreadIDは利用可能範囲ＩＤを示し、11111は利用可能範囲ＩＤの値である。
【０１３０】
このようなリクエストを受け取ったリモートホスト１Ｒは、処理制御部１０を起動してこの利用可能範囲ＩＤをスレッドの変数にセットする。そして、リモートホスト１Ｒ内では、上記第２実施形態と同様の方式で、新しく起動するスレッドがあれば、その変数に利用可能範囲ＩＤを継承させる。
【０１３１】
この場合、継承した利用可能範囲ＩＤを、リモートホスト１Ｒの利用可能範囲制御部６０に登録するのは、addメソッド６３の機能拡張により実現する。すなわち、リモートホスト１Ｒ内のデータ処理部３０の処理結果を同ホスト１Ｒ内の処理結果記憶部５０にregisterメソッド５１により登録すると、その処理結果のＩＤを利用可能範囲ＩＤ管理テーブル６６に登録するため、そのregisterメソッド５１から同ホスト１Ｒ内の利用可能範囲制御部６０のaddメソッド６３が呼び出されるわけであるが、このとき第２実施形態のaddメソッド６３であれば、利用可能範囲ＩＤ管理テーブル６６の、その時にスレッド変数として受け渡された利用可能範囲ＩＤに対応する処理結果ＩＤ配列に対し、引数である処理結果ＩＤを登録するだけである。これに対し、この実施形態のaddメソッド６３は、スレッド変数として受け取った利用可能範囲ＩＤが利用可能範囲ＩＤ管理テーブル６６に登録済みかどうかを調べ、未登録であれば、そのテーブル６６にその利用可能範囲ＩＤ用の新たなエントリを作成した上で、そのエントリの処理結果ＩＤ配列に、引数の処理結果ＩＤを登録する。
【０１３２】
なお、リモートホスト１Ｒでのスクリプトの処理結果は、呼出元のホスト１Ｐ又は１Ｒに処理結果ＩＤの形で返されるので、呼出元はその処理結果ＩＤを、そのスクリプトの呼び出しを行ったスレッドの利用可能範囲ＩＤに対応づけて、利用可能範囲ＩＤ管理テーブル６６に登録することができる。
【０１３３】
また、利用可能範囲ＩＤに基づくアクセス制御では、処理結果記憶部５０が他のホスト上の処理結果実体を要求する上記(43)のようなＨＴＴＰリクエストを作成・送信する際、そのリクエストのヘッダに、上記(61)の様に利用可能範囲ＩＤを組み込んで送るようにする。このリクエストを受け取ったホストの処理結果記憶部５０は、自ホスト内の利用可能範囲制御部６０に対するvalidateメソッド６４を呼び出し、そのリクエストヘッダに組み込まれた利用可能範囲ＩＤが、そのリクエストが要求する処理結果ＩＤの処理結果にアクセス可能かどうかを判定させる。そして、判定の結果、アクセス可能ならばその処理結果を含むＨＴＴＰレスポンスを呼出元ホストの処理結果記憶部５０に返す。逆に、アクセス不可と判定された場合は、その旨を示すデータを含んだＨＴＴＰレスポンスを呼出元ホストの判定結果記憶部５０に返す。
【０１３４】
また、クライアント２からのリクエストで要求されたスクリプトの処理が終了すると、ポータルホスト１Ｐの処理制御部１０が同ホスト１Ｐ内の利用可能範囲制御部６０のcloseメソッド６２を呼び出して、そのリクエストに係る処理結果の削除を行うが、このときその利用可能範囲制御部６０は、そのリクエストの処理の際に呼び出したリモートホスト１Ｒの利用可能範囲制御部６０のcloseメソッド６２を呼び出す。この呼び出しは、ホスト間の他の要求送信の場合と同様、ＨＴＴＰリクエストで行えばよい。このＨＴＴＰリクエストのヘッダには対象となる利用可能範囲ＩＤを組み込む。
【０１３５】
このＨＴＴＰリクエストは、システム中に存在するすべてのリモートホスト１Ｒに送信するようにしてもよいが、クライアント２からのリクエストの処理の際に実施に利用したリモートホスト１Ｒだけに絞り込んでその削除のためのＨＴＴＰリクエストを送ることもできる。すなわち、ポータルホスト１Ｐの利用可能範囲ＩＤ管理テーブル６６の、close処理対象の利用可能範囲ＩＤのエントリに登録された各処理結果ＩＤを調べれば、各処理結果がどのホスト１Ｐ又は１Ｒにあるか分かる（処理結果ＩＤには、それを生成したホストの識別情報が含まれているから）ので、該当するリモートホスト１Ｒを特定できるからである。なお、リモートホスト１Ｒでのスクリプト処理の中で、別のリモートホスト１Ｒのスクリプト処理を呼び出すこともあり、この場合、ポータルホスト１Ｐには後者のリモートホスト１Ｒの処理結果のＩＤは戻らないことがある。しかし、closeメソッド６２を呼び出されたリモートホスト１Ｒが、自らが呼び出した他のホストに対してcloseメソッド６２を呼び出すようにしておけば、そのような場合でも、クライアント２からのリクエストの処理の際に生成された、各ホスト上の中間処理結果を全て削除することができる。
【０１３６】
以上、ネットワークを介した分散処理における利用可能範囲ＩＤベースのアクセス管理について説明したが、有効期間管理部７０による記憶領域確保のための処理も、それと同様の仕組みで、分散処理対応できる。
【０１３７】
すなわち、スクリプト中の有効期間の始点から終点までの間に、複数のホスト１Ｐ及び１Ｒでの処理が記述されている場合は、そのスクリプトを実行しているホストがその始点で有効期間ＩＤを生成し、他のホストでのスクリプト処理を呼び出す場合は、その有効期間ＩＤをＨＴＴＰリクエストのヘッダなどに組み込んで呼び出し先のホストに伝達すればよい。呼び出し先のホストは、その有効期間ＩＤを自ホストの有効期間ＩＤ管理テーブル７５に登録する。これは、addメソッド６３の機能追加によりリモートホスト１Ｒが継承した利用可能範囲ＩＤを管理テーブル６６に登録したのと同様、addメソッド７３の機能拡張により対応できる。呼出元から実行を指示されたスクリプトの中で他のホストの別のスクリプトを呼び出す場合には、そのためのＨＴＴＰリクエストにその有効期間ＩＤを含めて送ることで、有効期間ＩＤを連鎖的に継承させる。ホストＡの処理制御部１０からスクリプトの実行要求を受けたホストＢの処理制御部１０は、少なくともそのスクリプトの処理結果の処理結果ＩＤをホストＡの処理制御部１０に返すので、ホストＡの処理制御部１０は、その処理結果ＩＤをスレッドの有効期間ＩＤに対応づけて、ホストＡの有効期間ＩＤ管理テーブル７５に登録することができる。
【０１３８】
また、スクリプトの実行において、有効期間の終点に達すれば、そのスクリプトを実行しているホストは、有効期間中に呼び出した各ホストに対しcloseメソッド７２を要求するＨＴＴＰリクエストを送る。このリクエストには、対象とする有効期間ＩＤをヘッダとして組み込む。このclose処理のためのリクエストの送り先は、有効期間ＩＤ管理テーブル７５の当該有効期間ＩＤのエントリに登録された各処理結果ＩＤから判別できる。
【０１３９】
以上のような仕組みにより、分散環境においても、有効期間内の処理により生成された中間処理結果を、有効期間終了後に削除することができる。
【０１４０】
なお、あるスクリプトに設定された有効期間内から呼び出したスクリプトの中に、別の有効期間の始点及び終点が記述される場合もある。両方のスクリプトが同じホストで実行される場合は、有効期間管理部７０がそれらに別々の有効期間ＩＤを付与するので、管理上の問題はないが、それらスクリプトが別のホストで分散処理される場合、異なるホストが同じ値の有効期間ＩＤを付与すると適切な管理ができない。そこで、例えば有効期間ＩＤには、それを付与したホストの識別情報を組み込むようにすれば、このような問題は解消できる。
【０１４１】
次に、図９及び図１０のフローチャートを参照して、本実施形態におけるポータルホスト１Ｐ及びリモートホスト１Ｒの処理制御部１０の処理の流れを説明する。この処理手順は、利用可能範囲制御部６０を含むシステム構成に対応するものである。なお、図９及び図１０において、図３及び図７のフローチャートにおけるステップと同様の処理を行うステップには、同一符号を付して詳しい説明は省略する。
【０１４２】
図９は、ポータルホスト１Ｐの処理制御部１０の処理手順を示す。この手順は、図７に示した第２実施形態の処理制御部１０の手順に、Ｓ４０〜Ｓ４４の各ステップを加えたものである。すなわち、本実施形態では、処理制御部１０は、次の処理指示がＳ１８でスクリプト実行指示と判定であると判定した場合、更にそのスクリプトを実行すべきホストが自ホストか否かを判定する（Ｓ４０）。この判定は、(41)等に示したスクリプト実行を指示する記述の中で、実行指定ホストを示す最初の引数の値を調べることにより行える。この判定で、実行指定ホストが自ホストであればＳ１２に戻ってそのスクリプトを呼び出し、実行指定ホストが他のホスト（リモートホスト１Ｒ）であれば、そのスクリプト実行指示記述中のホスト情報、引数を用いて、該他のホストの処理結果制御部１０（サーブレット）を起動するＵＲＬを作成し、これに対応したＨＴＴＰリクエストを送出する（Ｓ４２）。そして、そのリクエストに対するＨＴＴＰレスポンスを受け取ると、その中に示される処理結果ＩＤを取得し（Ｓ４４）、Ｓ１４に戻る。
【０１４３】
図１０は、リモートホスト１Ｒの処理制御部１０の処理手順を示す。この手順は、図９のポータルホスト１Ｐの処理手順と比較した場合、利用可能範囲制御部６０から利用可能範囲ＩＤ付与を受けるステップＳ５を含まない。利用可能範囲ＩＤは、クライアント２のリクエストに対してポータルホスト１Ｐで付与され、そのリクエストのために呼ばれる他のホストでは、その利用可能範囲ＩＤを継承すればよいからである。また、ポータルホスト１Ｐの手順では、依頼されたスクリプトの処理が終わった（Ｓ１６の判定結果がＮｏ）後、そのスクリプトが別のスクリプトから呼び出されたスクリプトかどうかを判定していたが（Ｓ２４）、リモートホスト１Ｒでは、実行するスクリプトは必ず他のスクリプトの中から呼ばれたものなので、Ｓ２４の判定処理は不要であり、単にそのスクリプトの最終処理結果のＩＤを呼出元に返す処理を行えばよい（Ｓ２６）。なお、リモートホスト１Ｒの処理制御部１０は、依頼されたスクリプトの処理を開始する際に、上述のように利用可能範囲ＩＤの生成(openメソッド６１）を行わないので、このスクリプトが終了した時点では、関連情報の削除(closeメソッド６２）を行わない。この関連情報の削除は、クライアント２からのリクエストで指定されたスクリプトの処理が終了した時に、ポータルホスト１Ｒからの指示に基づき行われる。
【０１４４】
以上に説明した第３実施形態によれば、複数のホスト１Ｐ及び１Ｒが連携して処理を行うシステム構成おいても、上記第１及び第２実施形態と同様の効果を得ることができる。
【０１４５】
また、本実施形態では、各ホスト１Ｐ又は１Ｒ内の各ユニット（例えばデータ処理部３０）が処理のために必要なデータ（中間処理結果）を自ホスト内の処理結果記憶部５０に要求し、その処理結果記憶部５０が要求されたデータを持たない場合にのみ、そのデータを持つホストからデータを取得し、それをその処理結果記憶部５０に登録するようにした。これにより、呼び出されたホストから呼出元のホストに処理結果の実体データを１回転送してコピーすれば、その後呼出元のホストでその処理結果のデータが必要とされた時には、コピーした処理結果実体を再利用できる。これに対し、上記特許文献２の方式では、各処理サーバは自分の処理結果（スナップショット）を保存しているが、自分が呼び出した他の処理サーバの処理結果をコピーして再利用することまではしていない。このため、特許文献２では、ネットワークの負荷が大きいが、本実施形態ではそのような問題は解消乃至軽減できる。
【０１４６】
また、本実施形態では、各ホスト１Ｐ及び１Ｒに保持される処理結果は、それぞれ利用可能範囲制御部６０にて利用可能範囲ＩＤと関連づけて管理されている。このため、スクリプトのデバッグの際、利用可能範囲ＩＤを指定すれば、その利用可能範囲ＩＤに対応する処理結果を各ホスト１Ｐ及び１Ｒから取得し、解析することができる。
【０１４７】
なお、以上の説明では、別のホスト（呼出元）からスクリプトの実行を指示されたホスト（呼出先）は、スクリプトの処理が終わった時点では呼出元に対して処理結果ＩＤのみを返し、その処理結果が必要となったときに呼出元がその処理結果ＩＤを用いて処理結果実体を呼出先から取得して自分の処理結果記憶部５０にコピーした。しかし、これは処理手順の一例に過ぎない。この代わりに、呼出先がスクリプトの処理が終わった時点で呼出元に対して処理結果ＩＤと処理結果実体の両方を送り、呼出元がこれを自ホストの処理結果記憶部５０に登録するような手順を採用することもできる。また、この場合、呼出先から呼出元へ処理結果実体のみを送り、これを受け取った呼出元がその処理結果実体に新たな処理結果ＩＤを付与して、処理結果記憶部５０に登録するという処理手順を用いることも可能である。
【０１４８】
［第４実施形態］
上記第３実施形態では、リモートホスト１Ｒが、他のホストから実行依頼されたスクリプトをどのように入手するかについては特に限定しなかった。しかし、仮に、リモートホスト１Ｒに対するリクエストの中で、インターネット等のネットワーク上の任意の場所にあるスクリプトのスクリプト名を実行対象に指定できるようにしたり、或いはリクエスト中にスクリプトそのものを組み込めるようにしたりしたのでは、未知のホストから任意のスクリプトを実行させられる可能性があり、セキュリティ上問題となる場合がある。この第４実施形態はそのような問題に対処するものである。
【０１４９】
図１１に、本実施形態のシステム構成を示す。本システムは、各ホスト１Ｐ及び１Ｒにスクリプト管理部８０Ｐ及び８０Ｒを加えたものであり、それ以外は第３実施形態のシステムと同じである。
【０１５０】
本実施形態では、リモートホスト１Ｒは、ポータルホスト１Ｐからスクリプトを取得して実行するようにする。そして、ポータルホスト１Ｐ以外からのスクリプトは受け入れないようにする。
【０１５１】
本実施形態の分散処理システムで実行可能なスクリプトは、すべてポータルホスト１Ｐのスクリプト管理部８０Ｐに登録される。各スクリプトにはシステム内で一意な識別情報（スクリプトＩＤと呼ぶ）が割り当てられている。リモートホスト１Ｒに対するスクリプトの実行指示には、実行対象のスクリプトＩＤを記述するようにする。そして、この実行指示を受け取ったリモートホスト１Ｒの処理制御部１０は、自ホスト内のスクリプト管理部８０Ｒに対してそのスクリプトＩＤの示すスクリプト実体を要求する。この要求を受けたスクリプト管理部８０Ｒは、要求されたスクリプトＩＤに対応するスクリプト実体を持っていれば、それを処理制御部１０に返す。持っていなければ、ポータルホスト１Ｐのスクリプト管理部８０Ｐに対しそのスクリプトＩＤの情報を含んだリクエストを例えばＨＴＴＰを利用して送信し、スクリプト実体を取得して、処理制御部１０に渡す。ここで、取得したスクリプト実体を、スクリプト管理部８０ＲにスクリプトＩＤと対応づけて登録するようにすれば、今後そのスクリプトＩＤに対する要求を受けたときに、ポータルホスト１Ｐからスクリプトを取得する必要がなくなる。
【０１５２】
このような仕組みによれば、リモートホスト１Ｒは、自分自身が最初から持っているか、ポータルホスト１Ｐから取得するかしたスクリプトしか実行できないので、未知のホストから任意のスクリプトを実行させられるというようなことは起こらない。
【０１５３】
なお、以上の例では、リモートホスト１Ｒはポータルホスト１Ｐのみからスクリプトを取得したが、リモートホスト１Ｒからスクリプトを取得できるようにすることもできる。この場合、スクリプトＩＤとして、そのスクリプトの実体を持つホスト１Ｐ又は１Ｒの識別情報を組み込んだものを用いる。そして各ホストのスクリプト管理部８０Ｐ又は８０Ｒは、要求されたスクリプトを持っていない場合、そのスクリプトＩＤに示されたホストに対してスクリプト実体を要求するリクエストを送って、そのスクリプトを取得する。このような仕組みでも、未知のホスト上にあるスクリプトを実行させられることはない。
【０１５４】
［第５実施形態］
第３実施形態では、リモートホスト１Ｒに対する処理の分散は、スクリプト単位であった。これに対し、この第５実施形態では、データ処理部３０の処理の単位で分散を行う場合のシステム構成について説明する。
【０１５５】
第５実施形態のシステムの構成を図１２に示す。図１２において、図１に示した構成要素に想到する構成要素には同一符号を付した。
【０１５６】
この実施形態では、スクリプトを実行するのはポータルホスト１Ｐのみであり、リモートホスト１Ｒには処理制御部１０が設けられない。スクリプト中の個々の処理指示には、つぎのように、それを実行するホストの情報が記述される。
id1 = Host1.Component1.execute(url1)
【０１５７】
この指示では、Host1が、その処理を実行するホストを示している。ポータルホスト１Ｐの処理制御部１０は、このような処理指示を受けた場合、その処理指示中のホスト情報が自ホストのものか否かを判定し、自ホストでなければ、そのホスト情報が示す他ホストに対してその処理を実行する旨のＵＲＬを作成し、それに基づきその他ホストに対してＨＴＴＰリクエストを送信する。作成するＵＲＬは例えば次のようになる。
http://host1.domain/Component1?method=execute&arg1=url1
【０１５８】
このリクエストは、リモートホスト１Ｒのウェブサーバで受け付けられる。そして、そのウェブサーバが、Component1という名前で示されるサーブレット（データ処理部３０−１）を起動し、引数url1が示す原料データに基づく処理を実行させる。この処理の結果は、リモートホスト１Ｒの処理結果記憶部５０に登録され、そのとき処理結果記憶部５０が付与した処理結果ＩＤがそのデータ処理部３０−１に返される。データ処理部３０−１はその処理結果ＩＤをウェブサーバに返し、ウェブサーバがその処理結果ＩＤを含んだＨＴＴＰレスポンスをポータルホスト１Ｐの処理制御部１０に返す。ポータルホスト１Ｐのデータ処理部３０がその処理結果を必要とするときは、上記第３実施形態と同様、ポータルホスト１Ｐの処理結果記憶部５０がそれを持っていればデータ処理部３０に提供し、持っていなければリモートホスト１Ｒの処理結果記憶部５０からそれを取得してデータ処理部３０に提供する。リモートホスト１Ｒが別のリモートホスト１Ｒの処理結果を必要とする場合も同様である。
【０１５９】
以上の各実施形態では、クライアントとホストの間、及びホスト同士の間のリクエストとレスポンスをＨＴＴＰで受け渡すようにしたが、これはあくまで一例に過ぎない。また、以上の例では、ホスト１がスクリプトを実行する様にし、リクエストは実行すべきスクリプトを指定することにより行ったが、これも一例に過ぎない。
【図面の簡単な説明】
【０１６０】
【図１】本発明の第１実施形態のシステム構成を示す図である。
【図２】処理結果管理テーブルのデータ構造を示す図である。
【図３】処理制御部の処理内容を示すフローチャートである。
【図４】本発明の第２実施形態のホストの構成を示す図である。
【図５】利用可能範囲ＩＤ管理テーブルのデータ構造を示す図である。
【図６】有効期間ＩＤ管理テーブルのデータ構造を示す図である。
【図７】第２実施形態での処理制御部の処理を示すフローチャートである。
【図８】第３実施形態のシステム構成を示す図である。
【図９】第３実施形態のポータルホストの処理制御部の処理を示すフローチャートである。
【図１０】第３実施形態のリモートホストの処理制御部の処理を示すフローチャートである。
【図１１】第４実施形態のシステム構成を示す図である。
【図１２】第５実施形態のシステム構成を示す図である。
【符号の説明】
【０１６１】
１  ホスト、２  クライアント、１０  処理制御部、１２  evalメソッド、２０  処理制御手順解釈部、３０  データ処理部、３２  executeメソッド、４０  原料データ記憶部、５０  処理結果記憶部、５１  registerメソッド、５２  accessメソッド、５３  処理結果管理テーブル。
【図１】
2006134005.tif 000003
【図２】
2006134005.tif 000004
【図３】
2006134005.tif 000005
【図４】
2006134005.tif 000006
【図５】
2006134005.tif 000007
【図６】
2006134005.tif 000008
【図７】
2006134005.tif 000009
【図８】
2006134005.tif 000010
【図９】
2006134005.tif 000011
【図１０】
2006134005.tif 000012
【図１１】
2006134005.tif 000013
【図１２】
2006134005.tif 000014