(57)【特許請求の範囲】
【請求項１】
複数の管理サーバを用いてデータを並列的に処理させるシステムであって、
外部サーバから各管理サーバに対して複数のユーザに関するデータの操作をリクエストされた場合、前記データの種別または前記ユーザの属性に基づいて前記データを前記複数の管理サーバごとのリクエストデータに分割し、前記分割された各管理サーバに対応するリクエストデータを異なる複数のスレッドとしてマルチスレッド処理を実行する制御手段を備え、
前記制御手段は、前記複数のスレッドの各々に対して少なくとも操作対象となる前記管理サーバを示す識別子を含むスレッド番号を付与し、何れかのスレッドでエラーが発生した場合、前記エラーが発生したスレッドに対応するスレッド番号を少なくとも前記外部サーバに返却またはログに出力する、並列処理システム。
【請求項２】
前記ユーザを認証する認証手段をさらに備え、
前記認証手段は、リクエスト元の認証トークンが必要な場合、前記認証トークンを発行し、
前記制御手段は、前記マルチスレッド処理を実行するために、前記認証トークンを複製し、前記複製された認証トークンを各スレッドに対して使用する、請求項１記載のシステム。
【請求項３】
複数の管理サーバを用いてデータを並列的に処理させるシステムが実行する、並列処理方法であって、
前記システムが備える制御手段が、外部サーバから前記各管理サーバに対して複数のユーザに関するデータの操作をリクエストされた場合、前記データの種別または前記ユーザの属性に基づいて前記データを前記複数の管理サーバごとのリクエストデータに分割し、前記分割された各管理サーバに対応するリクエストデータを、異なる複数のスレッドとしてマルチスレッド処理を実行し、
前記システムが備える制御手段が、前記マルチスレッド処理を実行する際に、前記複数のスレッドの各々に対して少なくとも操作対象となる前記管理サーバを示す識別子を含むスレッド番号を付与し、何れかのスレッドでエラーが発生した場合、前記エラーが発生したスレッドに対応するスレッド番号を少なくとも前記外部サーバに返却またはログに出力する、並列処理方法。
【請求項４】
前記システムが備える認証手段が、前記ユーザを認証し、
前記システムが備える認証手段が、リクエスト元の認証トークンが必要な場合、前記認証トークンを発行し、
前記システムが備える制御手段が、前記マルチスレッド処理を実行するために、前記認証トークンを複製し、前記複製された認証トークンを各スレッドに対して使用する、請求項３記載の並列処理方法。
【請求項５】
複数の管理サーバを用いてデータを並列的に処理させるためのプログラムであって、
外部サーバから各管理サーバに対して複数のユーザに関するデータの操作をリクエストされた場合、前記データの種別または前記ユーザの属性に基づいて前記データを前記複数の管理サーバごとのリクエストデータに分割し、前記分割された各管理サーバに対応するリクエストデータを、異なる複数のスレッドとしてマルチスレッド処理を実行する手順をコンピュータに実行させ、
かつ前記マルチスレッド処理を実行する手順は、前記複数のスレッドの各々に対して少なくとも操作対象となる前記管理サーバを示す識別子を含むスレッド番号を付与し、何れかのスレッドでエラーが発生した場合、前記エラーが発生したスレッドに対応するスレッド番号を少なくとも前記外部サーバに返却またはログに出力する、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、例えば、複数のデータ管理サーバが連動して動作するシステムにおいて、複数のユーザに関するデータまたは複数の種別のデータの操作を並列処理により高速に実行させるシステム、方法、およびプログラムに関する。
【背景技術】
【０００２】
近年、普及が進むクラウド環境において、リソースや運用コストを低減するために、アプリケーションやデータサーバを複数の利用事業者で共用するしくみが広く用いられている（マルチテナント方式）。例えば、自治体の業務に関するデータが、低コスト化や災害時のＢＣＰ（業務継続計画）の一環として、自治体外のクラウド環境にマルチテナント方式で保存される傾向がある（例えば、非特許文献１参照）。
【０００３】
自治体では、数十万・数百万人オーダの住民に関する多種多様な情報を複数年分にわたり管理しており、そのデータは定期的または不定期に追加更新される。例えば、国民健康保険における診療や調剤のレセプト情報、および健康診断情報などは受診の都度、データが追加される。従って、このような自治体に関する自治体業務データをクラウドへのアップロードする場合において、複数人分の多種多様な大容量データを、適切な宛先に振り分けながら、効率的よく高速に登録・更新できることが求められている。また、運用者の手間を極力最小化することが望ましい。
【０００４】
そこで、クラウド上などに構築された複数のサービスサーバでデータを管理する情報システムにおいて、自治体などが保有するサーバ（外部サーバ）から情報システム内の各サービスサーバに対して、運用者の手を介さずにデータ登録の操作を行うための方法が提案されている（例えば、特許文献１参照）。特許文献１の方法を用いることによって、外部サーバの正当性の確認後にユーザを擬似した認証処理を自動的に実行することにより、情報システム内の各サービスサーバにおいて、外部サーバからのアクセスを正当に認証されたものと認識できる。
【０００５】
また、特許文献１には、複数のサービスサーバが連動して動作する情報システムにおいて、各サービスサーバに対するデータ操作を運用者の手を介さずに外部サーバから実行する場合に、アクセス元の正当性を確認する方法についても記載されている。
【０００６】
また、特許文献１には、高速化の側面についても、外部サーバからのアクセスが多重に実行され複数スレッドを起動して処理をする場合に、認証状態を管理しておくことで証明書を適切に複数スレッドで利用できるようにするしくみが提案されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特許第０５４７８５９１号明細書
【非特許文献】
【０００８】
【非特許文献１】ADWORLD2/SaaS 自治体クラウド、http://www.hitachi-systems.com/ind/adworld/products/cloud/
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、大量データを高速に処理するためには、外部サーバからのアクセスの多重化への対応だけでなく、情報システム内の複数のサービスサーバに対するデータ操作処理要求を適切な単位に切り分けて並列処理する必要がある。なお、並列処理は、例えば、マルチスレッドを用いた処理である。そのため、自治体業務データのように、複数ユーザ分かつ多種多様なデータへの操作要求が含まれるリクエストをマルチスレッドで処理する場合には、次のような課題を解決する必要がある。
【００１０】
外部サーバからのリクエストには複数ユーザのデータ且つ複数種類のデータが含まれており、情報システム内ではデータ種別ごとや利用事業者（自治体）ごとに、サービスサーバ内のデータベース（ＤＢ）やテーブルが管理されている。そのため、リクエストに含まれるデータ種別またはユーザの属性などに応じてリクエストデータを切り分け、通信処理時間が最小になるように処理スレッドを分割しなければ、効率よく処理を実行することができないという問題がある。
【００１１】
また、情報システム内の複数のサービスサーバは、常時全てが正常に動作しているとは限らない。一部のサーバがダウンしていたり、何らかの処理プログラムに不具合が発生している可能性もある。そのため、リクエスト処理中にエラーが発生した場合には、運用者がもしくは自動で再試行することによって、少なくともリクエスト実行前の状態に戻す必要がある。しかしながら、高速化のためにマルチスレッド処理を実行する場合、何れのサービスサーバにおいて何れのデータの処理が失敗したかを知ること、および、エラーによる影響の範囲を知ることが難しくなるという問題がある。
【００１２】
この発明は上記事情に着目してなされたもので、その目的とするところは、複数のユーザまたは多種多様なデータへの操作要求が含まれるリクエストを、システム内の複数のサーバに対して行う場合における並列処理の高速化を図るためのシステム、方法、及びプログラムを提供することにある。
【課題を解決するための手段】
【００１３】
上記目的を達成するためにこの発明の第１の観点は、以下のような構成要素を備えている。すなわち、複数の管理サーバを用いてデータを並列的に処理させるシステムであって、外部サーバから各管理サーバに対して複数のユーザに関するデータの操作をリクエストされた場合、データの種別またはユーザの属性に基づいてデータを複数の管理サーバごとのリクエストデータに分割し、分割された各管理サーバに対応するリクエストデータを異なる複数のスレッドとしてマルチスレッド処理を実行する制御手段を備え、前記制御手段は、複数のスレッドの各々に対して少なくとも操作対象となる管理サーバを示す識別子を含むスレッド番号を付与し、何れかのスレッドでエラーが発生した場合、エラーが発生したスレッドに対応するスレッド番号を少なくとも外部サーバに返却またはログに出力するようにしたものである。
【００１５】
また、ユーザを認証する認証手段をさらに備える。さらに、認証手段は、リクエスト元の認証トークンが必要な場合、認証トークンを発行する。さらに、制御手段は、マルチスレッド処理を実行するために、認証トークンを複製し、複製された認証トークンを各スレッドに対して使用する。
【００１６】
また、この発明の第１の観点には、同様な構成要素および態様を備える方法およびプログラムも含まれる。
【発明の効果】
【００１７】
すなわちこの発明によれば、複数のユーザまたは多種多様なデータへの操作要求が含まれるリクエストを、システム内の複数のサーバに対して行う場合における並列処理の高速化を図るシステム、方法、及びプログラムを提供することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の第１の実施形態の並列処理システムの構成例を示す図。
【図２】同実施形態の並列処理システムにおけるゲートウェイサーバによってなされる処理を説明するための図。
【図３】同実施形態の並列処理システムにおける要求処理統括管理部によってなされる処理シーケンスの例。
【図４】同実施形態の並列処理システムにおける通信制御部によってなされる処理シーケンスの例。
【図５】同実施形態の並列処理システムにおける通信処理部によってなされる処理シーケンスの例。
【図６】同実施形態の並列処理システムにおける要求処理統括管理部によって保持される情報を示すデータベース構造の例。
【図７】同実施形態の並列処理システムの通信制御部によって保持される情報を示すデータベース構造の例。
【図８】同実施形態に係る並列処理システムの通信処理部によって保持される情報を示すデータベース構造の例。
【図９】同実施形態に係る並列処理システムのゲートウェイサーバによって、外部サーバから各サービスサーバにデータ登録をする場合になされる処理における引渡しデータの例。
【図１０】本発明の第２の実施形態の並列処理システムの構成例を示す図。
【図１１】同実施形態の並列処理システムによってなされる処理シーケンスの例。
【図１２】本発明の第３の実施形態の並列処理システムの構成例を示す図。
【図１３】同実施形態の並列処理システムによってなされる処理シーケンスの例。
【発明を実施するための形態】
【００１９】
（第１の実施形態）
以下、図面を参照してこの発明に係る第１の実施形態を説明する。  
図１は、本発明の第１の実施形態の並列処理システム１０の構成例を示す図である。本実施形態の並列処理システム１０は、ネットワークを介してクライアント端末５０、複数の外部サーバ４０―１，４０―２，・・・，４０―Ｍ、および複数のサービスサーバ３０―１，３０―２，・・・，３０―Ｎに接続されたゲートウェイサーバ２０によって実現する。
【００２０】
ゲートウェイサーバ２０は、要求処理統括管理部２１、通信管理部２２、および通信処理部２３を備える。ゲートウェイサーバ２０は、複数のサービスサーバ３０へのデータ操作リクエストを通信相手となるサービスサーバ３０ごとに分割し、分割したデータ操作リクエストを異なるスレッドとして並列実行することによって複数のサービスサーバ３０へのデータ操作リクエストを高速に処理するために、要求処理統括管理部２１、通信管理部２２、および通信処理部２３による各処理を実行するスレッドを順次起動し、起動したスレッドを並列的に実行する。具体的には、ゲートウェイサーバ２０は、要求処理統括管理部２１、通信管理部２２、および通信処理部２３による各処理に対応する３つのスレッドを順次起動する。なお、以下、データの登録、更新、または削除などのデータの操作をデータ操作と称する。また、データ操作リクエストとは、データ操作に関するリクエストである。
【００２１】
要求処理統括管理部２１は、各外部サーバ４０またはクライアント端末５０から各サービスサーバ３０に対するデータ操作リクエストを受信し、受信したデータ操作リクエストに応じて、メインスレッドを起動する。なお、受信するデータ操作リクエストには、複数の利用事業者からのリクエストが含まれる。また、要求処理統括管理部２１は、データ操作リクエストに対する応答処理の全体を管理する。なお、メインスレッドは、データ操作リクエストを受け付け、受け付けたデータ操作リクエストに対応する処理の全体を管理するためのスレッドである。
【００２２】
また、要求処理統括管理部２１は、各外部サーバ４０およびクライアント端末５０から各サービスサーバ３０へのデータ操作リクエストを受け付け、受け付けたリクエストを各サービスサーバ３０へのリクエストに分割する。より詳細には、要求処理統括管理部２１は、データ所在情報を保持する。要求処理統括管理部２１は、データ所在情報を参照し、データ操作の対象となるサービスサーバ３０を１つの単位として、データ操作リクエストに関するデータ（以下、リクエストデータと称す。）を分割する。なお、データ所在情報については図６を参照して詳述するが、データ所在情報は、リクエストデータをサービスサーバ３０ごとに分割するために必要な情報を含む。
【００２３】
また、要求処理統括管理部２１は、分割されたリクエストデータを引数として、通信する対象となるサービスサーバ３０の数に対応する数の通信管理部２２を呼び出し、各通信管理部２２から返却された結果を、リクエスト元である外部サーバ４０またはクライアント端末５０に返却する。
【００２４】
通信管理部２２は、要求処理統括管理部２１からの呼び出しに応じて通信管理スレッドを起動する。通信管理スレッドは、通信相手となるサービスサーバ３０ごとの設定（例えば、データサイズ、接続上限数）に基づき、複数に分割して呼び出した通信処理部からの応答を管理するためのスレッドである。通信管理部２２は、呼び出される際に指定されたサービスサーバ３０に対するデータ操作リクエストの応答処理を管理する。
【００２５】
また、通信管理部２２は、サービスサーバ経路特性情報を保持する。なお、サービスサーバ経路特性情報については図７を参照して詳述するが、サービスサーバ経路特性情報は、１回の通信で適切なサイズを特定するための情報を含む。通信管理部２２は、サービスサーバ経路特性情報を参照し、要求処理統括管理部２１から渡されたリクエストデータを指定されたサービスサーバ３０に適切なサイズに分割する。なお、適切なサイズとは、例えば、データの容量等に基づくデータサイズ、または、リクエストの件数等に基づくサイズである。通信管理部２２は、分割されたリクエストデータを引数として、分割された数だけ通信処理部２３を呼び出し、各通信処理部２３から返却された結果を、要求処理統括管理部２１に返却する。
【００２６】
通信処理部２３は、通信管理部２２からの呼び出しに応じて、通信処理スレッドを起動する。通信処理スレッドは、サービスサーバ３０に接続し、データ操作をリクエストするためのスレッドである。通信処理部２３は、通信処理部２３が呼び出される際に指定されたサービスサーバ３０に対して少なくとも１回の通信処理を行う。
【００２７】
また、通信処理部２３は、通信管理部２２によって分割されたリクエストを各サービスサーバ３０へ送信し、指定されたリクエストデータに関するデータ操作を、指定されたリクエストデータに対応するサービスサーバ３０に依頼する。なお、リクエストデータは、例えば、通信処理部２３が呼び出される際に指定される。そして、通信処理部２３は、処理結果を通信管理部２２に返却する。
【００２８】
また、通信処理部２３は、サービスサーバ通信情報を保持する。なお、サービスサーバ通信情報については図８を参照して詳述するが、サービスサーバ通信情報は、ＩＰアドレス、Ｅｎｄ  Ｐｏｉｎｔ  Ｒｅｆｅｒｅｎｃｅ、ポートなどの各サービスサーバ３０と通信するための情報を含む。通信処理部２３は、サービスサーバ通信情報を参照し、該当するサービスサーバ３０との通信を行う。
【００２９】
各サービスサーバ３０は、ゲートウェイサーバ２０の指示に応じて、それぞれデータ種別の異なるデータを格納することによってデータを管理し、クライアント端末５０からのリクエストに応じて、データ操作を実行することによってデータを処理し、クライアント端末５０等にサービスを提供する。また、各サービスサーバ３０にはそれぞれ異なるデータ種別のデータが保存されており、1つのサービスサーバ３０には複数の利用事業者のデータが保存されている。
【００３０】
各外部サーバ４０およびクライアント端末５０は、ゲートウェイサーバ２０に対して、データ操作リクエストを送信する。
【００３１】
次に、図２を参照して、ゲートウェイサーバ２０によってなされる処理の一例について説明する。  
図２は、要求処理統括管理部２１、通信管理部２２、および通信処理部２３の呼び出しにおける関係を示している。なお、図２乃至図９では、データ操作の一例として各外部サーバ４０から各サービスサーバ３０にデータを登録する場合について説明するが、データ操作は、上述したようなデータの更新、データの削除などでもよい。
【００３２】
外部サーバ４０は、登録操作に関するリクエストデータとして、複数のデータ種別を有する登録データａを、要求処理統括管理部２１に送る。要求処理統括管理部２１は、外部サーバ４０から受信したデータ登録リクエストに応じて、メインスレッドを起動する。また、要求処理統括管理部２１は、データ所在情報２４を参照し、登録データａを、サービスサーバ３０−１によって管理されるデータ種別を有する登録データｂ−１、及び、サービスサーバ３０−２によって管理されるデータ種別を有する登録データｂ−２、に分割する。
【００３３】
そして、要求処理統括管理部２１は、登録データｂ−１及び登録データｂ−２を引数として、通信先のサービスサーバ３０ごとに通信管理スレッドを通信管理部２２に起動させるために、通信管理部２２−１及び通信管理部２２−２を呼び出す。このように、通信管理部２２は、サービスサーバ３０毎に個別に存在する。また、要求処理統括管理部２１は、登録データｂ−１を通信管理部２２−１に送り、登録データｂ−２を通信管理部２２−２に送る。
【００３４】
なお、図２では要求処理統括管理部２１が２つの通信管理部２２を呼び出した場合を示しているが、要求処理統括管理部２１は、登録データａを分割しない場合は、１つの通信管理部２２を呼び出す。
【００３５】
次に、通信管理部２２−１は、要求処理統括管理部２１からの呼び出しに応じて、通信管理スレッドを起動する。また、通信管理部２２−１は、サービスサーバ経路特性情報２５を参照し、登録データｂ−１を、サービスサーバ３０−１の経路特性に適したサイズを有する登録データｃ−１−１及び登録データｃ−１−２に分割する。
【００３６】
そして、通信管理部２２−１は、登録データｃ−１−１及び登録データｃ−１−２を引数として、ゲートウェイサーバ２０とサービスサーバ３０−１との間の１回の通信分ごとに通信処理スレッドを起動させるために、通信処理部２３−１−１及び通信処理部２３−１−２を呼び出す。また、通信管理部２２−１は、登録データｃ−１−１を通信処理部２３−１−１に送り、登録データｃ−１−２を通信処理部２３−１−２に送る。
【００３７】
同様に、通信管理部２２−２は、要求処理統括管理部２１からの呼び出しに応じて、通信管理スレッドを起動する。また、通信管理部２２−２は、サービスサーバ経路特性情報２５を参照し、登録データｂ−２を、サービスサーバ３０−２の経路特性に適したサイズを有する登録データｃ−２−１及び登録データｃ−２−２に分割する。
【００３８】
そして、通信管理部２２−２は、登録データｃ−２−１及び登録データｃ−２−２を引数として、ゲートウェイサーバ２０とサービスサーバ３０−２との間の１回の通信分ごとに通信処理スレッドを起動させるために、通信処理部２３−２−１及び通信処理部２３−２−２を呼び出す。また、通信管理部２２−２は、登録データｃ−２−１を通信処理部２３−２−１に送り、登録データｃ−２−２を通信処理部２３−２−２に送る。
【００３９】
なお、図２では、通信処理部２３は、１つの通信管理部２２に対して２つ存在する例を示しているが、これは一例に過ぎず、例えば、通信処理部２３−１−１と通信処理部２３−１−２とを、１つの通信処理部２３−１（図示せず）で共有し、通信処理部２３−２−１と通信処理部２３−２−２とを、１つの通信処理部２３−２（図示せず）で共有してもよい。
【００４０】
通信処理部２３−１−１は、通信管理部２２−１からの呼び出しに応じて、通信処理スレッドを起動する。そして、登録データｃ−１−１に関する登録操作を、サービスサーバ３０−１に依頼する。なお、通信処理部２３−１は、サービスサーバ通信情報２６を参照し、サービスサーバ３０−１と通信する。
【００４１】
また、通信処理部２３−１−２は、通信管理部２２−１からの呼び出しに応じて、通信処理スレッドを起動する。そして、登録データｃ−１−２に関する登録操作を、サービスサーバ３０−１に依頼する。なお、通信処理部２３−１−２は、サービスサーバ通信情報２６を参照し、サービスサーバ３０−１と通信する。
【００４２】
同様に、通信処理部２３−２−１は、通信管理部２２−２からの呼び出しに応じて、通信処理スレッドを起動する。そして、登録データｃ−２−１に関する登録操作を、サービスサーバ３０−２に依頼する。なお、通信処理部２３−２−１は、サービスサーバ通信情報２６を参照し、サービスサーバ３０−２と通信する。
【００４３】
また、通信処理部２３−２−２は、通信管理部２２−２からの呼び出しに応じて、通信処理スレッドを起動する。そして、登録データｃ−２−２に関する登録操作を、サービスサーバ３０−２に依頼する。なお、通信処理部２３−２−２は、サービスサーバ通信情報２６を参照し、サービスサーバ３０−２と通信する。
【００４４】
次に、図３を参照して、要求処理統括管理部２１によって実行される処理の一例について説明する。  
なお、図３乃至図９では、一例として、３つのサービスサーバ３０−１、サービスサーバ３０−２、およびサービスサーバ３０−３を用いる場合について説明するが、用いるサービスサーバ３０の数は３つに限定する必要はなく、例えば、２つ、４つ、あるいはそれ以上のサービスサーバ３０を用いてもよい。
【００４５】
要求処理統括管理部２１は、データ登録操作リクエストを受信すると（ステップＳ２０）、メインスレッドを起動する（ステップＳ２１）。次に、メインスレッドにおいて、登録データａを読み込む（ステップＳ２２）。そして、読み込まれた登録データａを格納先となるサービスサーバ３０ごとの登録データｂ−１，ｂ−２，ｂ−３に分割するために、登録データａの全単位、たとえばレコードについて、当該単位中のデータ種別に基づいて格納先となるサービスサーバ３０を判別する処理を繰り返し行う（ステップＳ２３）。
【００４６】
登録データａに含まれる全単位について繰り返し実施する内容は以下の通りである。まず、登録データａの各単位について、データ種別に該当するデータの格納先となるサービスサーバ３０を判定する（ステップＳ２４）。
【００４７】
そして、サービスサーバ３０−１に登録データａの当該単位のデータを格納すると判定した場合、登録データａの当該単位のデータを登録データｂ−１に追加する（ステップＳ２５−１）。一方、サービスサーバ３０−２に登録データａの当該単位のデータを格納すると判定した場合、登録データａの当該単位のデータを登録データｂ−２に追加する（ステップＳ２５−２）。あるいは、サービスサーバ３０−３に登録データａの当該単位のデータを格納すると判定した場合、登録データａの当該単位のデータを登録データｂ−３に追加する（ステップＳ２５−３）。
【００４８】
次に、登録データｂ−１，ｂ−２，ｂ−３の作成が完了したか否かを判定する（ステップＳ２６）。なお、ステップＳ２６における処理は、例えば、ステップＳ２３乃至ステップＳ２６の処理が実行された回数が、予め設定された回数に達しているか否かを判定する処理でもよい。登録データｂ−１，ｂ−２，ｂ−３の作成が完了した場合（ステップＳ２６のＹＥＳ）、後述するステップＳ２６の処理を行う。登録データｂ−１，ｂ−２，ｂ−３の作成が完了していない場合（ステップＳ２６のＮＯ）、ステップＳ２３に戻り、登録データａの次の単位に対する追加処理を行う。ステップＳ２３において、追加処理を行う登録データａの次の単位がない場合、ステップＳ２３乃至ステップＳ２６の繰り返し行われる追加処理を行うことなく、ステップＳ２７に進む。
【００４９】
要求処理統括管理部２１は、ステップＳ２３またはステップＳ２６の後、すなわち、登録データｂ−１，ｂ−２，ｂ−３の作成が完了した後、登録データｂ−１を引数として通信管理部２２−１を呼び出す（ステップＳ２７）。次に、登録データｂ−２を引数として通信管理部２２−２を呼び出す（ステップＳ２８）。次に、登録データｂ−３を引数として通信管理部２２−３を呼び出す（ステップＳ２９）。なお、ステップＳ２７、ステップＳ２８、ステップＳ２９の処理の順序は、図３に示す順番でなくてもよい。例えば、ステップＳ２８またはステップＳ２９の処理の後、ステップＳ２７の処理を行ってもよい。
【００５０】
要求処理統括管理部２１は、ステップＳ２９の後、呼び出した全ての通信管理部２２−１，２２−２，２２−３からの応答が揃うまで待機する（ステップＳ３０）。呼び出した全ての通信管理部２２−１，２２−２，２２−３からの応答があった際、換言すると並列起動させた通信管理スレッドが終了した場合、各通信管理部２２−１，２２−２，２２−３から返却されたリクエスト結果を、リクエスト元である外部サーバ４０またはクライアント端末５０に返却する（ステップＳ３１）。
【００５１】
次に、図４を参照して、通信管理部２２によって実行される処理の一例について説明する。  
通信管理部２２―ｎ（ｎは、例えば１〜３）は、要求処理統括管理部２１からの呼び出しに応じて（ステップＳ４０）、登録データｂ―ｎを引数として通信管理スレッドを起動する（ステップＳ４１）。次に、通信管理部２２―ｎは、登録データｂ―ｎをサービスサーバ３０に適したリクエスト件数に分割し、登録データｃ―ｎ―１，ｃ―ｎ―２を生成する（ステップＳ４２）。
【００５２】
次に、登録データｃ−ｎ−１を引数として、登録データｃ−ｎ−１に対応する通信処理部２３−ｎ−１を呼び出す（ステップＳ４３）。また、通信管理部２２―ｎは、登録データｃ−ｎ−２を引数として、登録データｃ−ｎ−２に対応する通信処理部２３−ｎ−２を呼び出す（ステップＳ４４）。
【００５３】
通信管理部２２―ｎは、ステップＳ４３−１またはステップＳ４３−２の後、呼び出した全ての通信処理部２３−ｎ−１，２３−ｎ−２からの応答が揃うまで待機する（ステップＳ４５）。通信管理部２２−ｎは、呼び出した全ての通信処理部２３−ｎ−１，２３−ｎ−２からの応答があった際、換言すると並列起動させた通信処理スレッドが終了した場合、処理結果を要求処理統括管理部２１に、すなわちメインスレッドに、返却する（ステップＳ４６）。
【００５４】
次に、図５を参照して、通信処理部２３によって実行される処理の一例について説明する。  
通信処理部２３―ｎ−１（ｎは、例えば１〜３）及び通信処理部２３―ｎ−２の各々は、通信管理部２２−ｎからの呼び出しに応じて（ステップＳ５０）、登録データｃ―ｎ−１及び登録データｃ―ｎ−２の各々を引数として通信処理スレッドを起動する（ステップＳ５１）。通信処理部２３―ｎ−１及び通信処理部２３―ｎ−２の各々は、対応するサービスサーバ３０−ｎにデータ登録を依頼し、処理結果をサービスサーバ３０―ｎの各々から取得する（ステップＳ５２）。通信処理部２３―ｎ−１及び通信処理部２３―ｎ−２の各々は、取得した処理結果を対応する通信管理部２２―ｎに返却する（ステップＳ５３）。
【００５５】
次に、図６乃至図８を参照して、ゲートウェイサーバ２０の各部によって保持される情報の一例について説明する。各部は、各々の役割に応じて、各部の処理において必要な設定データを保持する。
【００５６】
まず、図６を参照して、要求処理統括管理部２１によって保持される情報を示すデータベース構造の一例について説明する。  
要求処理統括管理部２１は、データ所在情報２４を保持する。上述したように、データ所在情報２４は、リクエストデータをサービスサーバ３０ごとに分割するために必要な情報を含む。また、データ所在情報２４は、リクエストデータ内に含まれる各データ種別が格納されているサービスサーバ３０を特定するための情報でもある。
【００５７】
データ所在情報２４は、図６に示すように、例えば、データ種別情報２４−ａ及び格納先サービスサーバ情報２４―ｂを有する。
【００５８】
データ種別情報２４−ａは、データの種別を示す情報である。データ種別情報２４−ａは、図６に示すように、例えば、診療に関する診療レセプト情報、介護に関する介護レセプト情報、および健康診断に関する健康診断情報の要素を有する。
【００５９】
格納先サービスサーバ情報２４―ｂは、データの格納先であるサービスサーバ３０に関する情報である。格納先サービスサーバ情報２４―ｂは、図６に示すように、例えば、サービスサーバ１、サービスサーバ２、およびサービスサーバ３の要素を有する。
【００６０】
データ種別情報２４−ａの各要素は、サービスサーバ情報２４―ｂの各要素に一対一に関連付けられており、各サービスサーバ３０によって格納されるデータ種別を示している。
【００６１】
次に、図７を参照して、通信管理部２２によって保持される情報を示すデータベース構造の一例について説明する。  
通信管理部２２は、サービスサーバ経路特性情報２５を保持する。上述したように、サービスサーバ経路特性情報２５は、１回の通信で適切なサイズを特定するための情報を含む。また、サービスサーバ経路特性情報２５は、サービスサーバ識別情報２５−ａ毎に、サービスサーバ３０の性能による最適値に関する情報（サーバ性能要素情報２５―ｂ）、及び、サービスサーバ３０への経路の性能による最適値に関する情報（経路特性要素情報２５―ｃ）も含む。
【００６２】
最適値としては、通信管理部２２によって保持されているサービスサーバ３０に対するリクエスト件数に基づき、各サービスサーバ３０におけるリクエスト件数のうちリクエスト件数の少ない値を、最適値としてもよい。または、通信管理部２２によって保持されている上述したような適切なデータサイズに基づき、例えば、適切なデータサイズをリクエストデータの１単位の記録サイズで除算した値を最適値として、通信管理部２２等によって算出してもよい。
【００６３】
具体的には、図７に示すように、サービスサーバ経路特性情報２５は、サービスサーバ識別情報２５−ａ、サーバ性能要素情報２５−ｂ、及び経路特性要素情報２５−ｃを有する。
【００６４】
サービスサーバ識別情報２５−ａは、各サービスサーバを識別するための情報であり、図７に示すように、例えば、サービスサーバ１、サービスサーバ２、およびサービスサーバ３の要素を有する。
【００６５】
また、サーバ性能要素情報２５−ｂ及び経路特性要素情報２５−ｃは、各サービスサーバ３０に一対一に関連付けられている。例えば、図７に示すように、サービスサーバ１は、１００件を最適値とするサーバ性能要素情報２５―ｂの要素、及び、２００件を最適値とする経路特性要素２５―ｃの要素、に関連付けられている。同様に、サービスサーバ２は、２００件を最適値とするサーバ性能要素情報２５―ｂの要素、及び、２００件を最適値とする経路特性要素２５―ｃの要素、に関連付けられている。また、サービスサーバ３は、３００件を最適値とするサーバ性能要素情報２５―ｂの要素、及び、２００件を最適値とする経路特性要素２５―ｃの要素、に関連付けられている。
【００６６】
次に、図８を参照して、通信処理部２３によって保持される情報を示すデータベース構造の一例について説明する。  
通信処理部２３は、サービスサーバ通信情報２６を保持する。上述したように、サービスサーバ通信情報２６は、サービスサーバ識別情報２６−ａ毎に、Ｅｎｄ  Ｐｏｉｎｔ  Ｒｅｆｅｒｅｎｃｅ情報２６―ｂ、ＩＰアドレス情報２６−ｃ、及びポートなどの各サービスサーバ３０と通信するための情報を含む。
【００６７】
サービスサーバ識別情報２６―ａの各要素は、図８に示すように、Ｅｎｄ  Ｐｏｉｎｔ  Ｒｅｆｅｒｅｎｃｅ情報２６―ｂの各要素、及び、ＩＰアドレス情報２６−ｃの各要素と一対一に関連付けられている。例えば、サービスサーバ１は、「ｘｘｘｘｘ」で示されるＥｎｄ  Ｐｏｉｎｔ  Ｒｅｆｅｒｅｎｃｅ情報２６―ｂの要素、及び、「ｘｘ．ｘｘ．ｘｘ．ｘｘ」で示されるＩＰアドレス情報２６−ｃの要素、に関連付けられている。
【００６８】
次に、図９を参照して、ゲートウェイサーバ２０の各部によって引き渡されるデータの一例について説明する。  
外部サーバ４０から要求処理統括管理部２１に引き渡されるデータである「登録データａ」は、様々なユーザ属性を有する複数のユーザに関するデータ、及び、複数のデータ種別に関するデータを含んでいる。
【００６９】
「登録データａ」は、例えば、図９に示すような引き渡しデータベース９０として表される。具体的には、引き渡しデータベース９０は、ユーザ識別情報９０−ａ、データ種別情報９０―ｂ、及びユーザ属性情報９０−ｃを含む。また、データ種別情報９０−ｂは、診療レセプト情報９０−ｄ、介護レセプト情報９０−ｅ、及び健康診断情報９０―ｆを含む。また、ユーザ属性情報９０−ｃは、所属保険者情報９０―ｇ及び居住地情報９０−ｈを含む。
【００７０】
より詳細には、ユーザ識別情報９０−ａ毎に、診療レセプト情報９０−ｄ、介護レセプト情報９０−ｅ、健康診断情報９０―ｆ、所属保険者情報９０―ｇ、及び居住地情報９０−ｈが関連付けられている。例えば、ＵｓｅｒＡで示されるユーザ識別情報９０−ａには、「ｘｘＡＡ」で示される診療レセプト情報９０−ｄの要素、「ｙｙＡＡ」で示される介護レセプト情報９０−ｅの要素、「ｚｚＡＡ」で示される健康診断情報９０−ｆの要素、「国民健康保険」で示される所属保険者情報９０−ｇの要素、及び、「自治体Ｘ」で示される居住地情報９０−ｄｈの要素が関連付けられている。
【００７１】
要求処理統括管理部２１から通信管理部２１−１，２１−２，２１−３の各々に引き渡されるデータである登録データ９２（ｂ−１），９２（ｂ−２），９２（ｂ−３）は、それぞれ、サービスサーバ３０−１，３０−２，３０−３の各々に格納されるデータ種別に関するリクエストデータのみが抜粋されたデータである。
【００７２】
具体的には、登録データ９２（ｂ−１）は、登録データａ  ９０から、ユーザ識別情報９０−ａ毎に診療レセプト情報９０−ｄが抜粋されたデータである。同様に、登録データ９２（ｂ−２）は、登録データａ  ９０から、ユーザ識別情報９０−ａ毎に介護レセプト情報９０−ｅが抜粋されたデータである。また、登録データ９２（ｂ−３）は、登録データａ  ９０から、ユーザ識別情報９０−ａ毎に健康診断レセプト情報９０−ｆが抜粋されたデータである。
【００７３】
また、登録データ９４（ｃ−１−１），９４（ｃ−１−２）は、通信管理部２２−１から通信処理部２３−１−１及び通信処理部２３−１−２に引き渡されるリクエストデータであり、サービスサーバ３０−１の性能及びサービスサーバ３０−１までの経路の特性に適したサイズに切り分けられている。
【００７４】
具体的には、登録データ９４（ｃ−１−１）は、ＵｓｅｒＡに関する診療レセプト情報９０−ｄ及びＵｓｅｒＢに関する診療レセプト情報９０−ｄを含む１００件の診療レセプト情報９０−ｄを有している。一方、登録データ９４（ｃ−１−２）は、ＵｓｅｒＣに関する診療レセプト情報９０−ｄ及びＵｓｅｒＤに関する診療レセプト情報９０−ｄを含む１００件の診療レセプト情報９０−ｄを有している。
【００７５】
同様に、図示していないが、通信管理部２２−２から通信処理部２３−２−１及び通信処理部２３−２−２に引き渡されるデータである登録データ９４（ｃ−２−１）及び登録データ９４（ｃ−２−２）も存在する。これら登録データ９４（ｃ−２−１）および登録データ９４（ｃ−２−２）の各々も同様に、サービスサーバ３０−２の性能及びサービスサーバ３０−２までの経路の特性に適したサイズに切り分けられている。
【００７６】
また、同様に、図示していないが、通信管理部２２−３から通信処理部２３−３−１及び通信処理部２３−３−２に引き渡されるデータである登録データ９４（ｃ−３−１）及び登録データ９４（ｃ−３−２）も存在する。これら登録データ９４（ｃ−３−１）および登録データ９４（ｃ−３−２）の各々も同様に、サービスサーバ３０−３の性能及びサービスサーバ３０−３までの経路の特性に適したサイズに切り分けられている。
【００７７】
以上のような第１の実施形態によって、次のような効果を得ることができる。  
リクエストに含まれるデータ種別やデータオーナの所属等に応じて、各スレッドで処理する単位を適切に切り分けてマルチスレッド処理を実行し、通信処理の回数を最小化することが可能となる。また、各スレッドにおいてデータ操作対象となるサービスサーバ３０と通信する際に、相手サーバの能力やネットワーク環境に応じて更にスレッド分割を行い、通信処理を最適化することが可能となる。したがって、階層的なマルチスレッド処理による高速化が可能となる。
【００７８】
また、より詳細には、リクエストの中身に応じてデータを切り分け、階層的にマルチスレッド化することにより、通信処理の回数を最小化すると共に、各スレッドの対象となる通信相手の能力に応じて、通信処理をそれぞれ最適化することが可能となる。これにより、並列処理システム１０内の複数のサービスサーバ３０へのデータ操作要求を高速に処理することが可能となる。また、配信先のサービスサーバ３０の性能に応じてリクエストデータのサイズを切り分けて、階層的にマルチスレッド化し、並列処理を実行することによって、高速化が可能となる。
（第２の実施形態）
以下、図１０及び図１１を参照して本発明に係る第２の実施形態を説明する。  
なお、以下では、第１の実施形態において示した構成と異なる部分を中心に説明する。そのため、第１の実施形態と共通する要素には同一の符号を付し、重複する説明を省略する。
【００７９】
図１０は、本発明の第２の実施形態の並列処理システム１００の構成例を示す図である。  
第２の実施形態の並列処理システム１００は、第１の実施形態の並列処理システム１０に対して認証サーバ１１０をさらに加えた構成である。また、第２の実施形態の並列処理システム１００は、並列処理システム１００を利用するために認証が必要な場合を想定しており、認証サーバ１１０によって発行される認証トークンを利用する。
【００８０】
認証サーバ１１０は、ゲートウェイサーバ２０及び各サービスサーバ３０−１，３０−２，・・・，３０−Ｎと接続されており、認証が必要な場合、認証トークンを発行する。
【００８１】
次に、図１１を参照して、第２の実施形態の並列処理システム１００によってなされる処理シーケンスの一例について説明する。  
並列処理システム１００は、マルチスレッド処理を実行する際、次のような処理をさらに実行する。  
ゲートウェイサーバ２０は、クライアント端末５０または外部サーバ４０からのデータ操作リクエストに応じて、リクエスト元のクライアント端末５０または外部サーバ４０の認証トークンが必要な場合、擬似的な認証を行う（ステップＳ１１１）。認証トークンは、例えば、ゲートウェイサーバ２０上で動作する各スレッドの起動時に、クライアント端末５０に対応するユーザに対して認証済みであることを示すトークンである。また、擬似的な認証とは、ゲートウェイサーバ２０において保持されているハッシュ化されたＩＤ／パスワードを用いて、各外部サーバ４０と接続する際に行われる認証である。
【００８２】
次に、ゲートウェイサーバ２０は、擬似的な認証に成功した場合、認証サーバ１１０に対して認証トークンの発行を要求する（ステップＳ１１３）。認証サーバ１１０は、この要求に応じて認証トークンを発行し（ステップＳ１１５）、発行した認証トークンをゲートウェイサーバ２０に送信する。
【００８３】
次に、ゲートウェイサーバ２０は、並列動作するスレッド間において使用される認証トークンが競合しないように、受信した認証トークンを各スレッドに対して複製する（ステップＳ１１７）。換言すると、ゲートウェイサーバ２０は、各スレッドに対して認証トークンのインスタンスを生成する。ゲートウェイサーバ２０は、複製した認証トークンを各スレッドに対して使用して、各サービスサーバ３０に対して並列処理を実行させる（ステップＳ１１９）。
【００８４】
以上のような第２の実施形態の並列処理システム１００によって、次のような効果を得ることができる。  
すなわち、第２の実施形態では、認証が必要な場合であっても、認証サーバ１１０を用いることによって、複数のサービスサーバ３０−１，３０−２，・・・，３０−Ｎに対するデータ操作処理を並列的に高速に実行することが可能となる。また、各スレッドが並列的に動作する場合であっても、認証トークンが競合することなく認証トークンを利用することが可能となる。また、各サービスサーバ３０−１，３０−２，・・・，３０−Ｎにおいてリクエスト元である各外部サーバ４０を判別することが可能となる。
（第３の実施形態）
以下、図１２及び図１３を参照して本発明に係る第３の実施形態を説明する。  
なお、以下では、第１の実施形態及び第２の実施形態において示した構成と異なる部分を中心に説明する。そのため、第１の実施形態及び第２の実施形態と共通する要素には同一の符号を付し、重複する説明を省略する。
【００８５】
第３の実施形態の並列処理システム１２０は、第２の実施形態の並列処理システム１００における認証サーバ１１０の代わりに認証サーバ１３０を備えた構成である。この構成は、並列処理システム１２０が、認証サーバ１３０を使用して、ユーザＩＤを分散管理する場合を想定している。より詳細には、並列処理システム１２０は、サービスサーバ３０−１，３０−２，・・・，３０−Ｎ間の通信において、ユーザＩＤを分散管理するために、ユーザ識別子として実ユーザＩＤを使用せず、各ユーザに対して付与する仲介用の仲介ＩＤを使用する。仲介ＩＤは、認証サーバ１３０と各サービスサーバ３０−１，３０−２，・・・，３０−Ｎとの間で連携処理を実行するために使用される。
【００８６】
まず、図１２を参照して、並列処理システム１２０の構成例について説明する。  
認証サーバ１３０は、通信処理部１３１及びデータ操作部１３２を備える。また、認証サーバ１３０は、ユーザ情報１３３及びＩＤ連携情報１３４を保持する。
【００８７】
通信処理部１３１は、通信処理部２３、及び、通信処理部３１−１，３１−２，・・・，３１−Ｎの何れかとの間で通信を行う。また、通信処理部１３１は、データ操作部１３２と接続されており、データ操作部１３２と連携してデータ操作に関する処理を行ってもよい。また、通信処理部１３１は、各サービスサーバ−１，３０−２，・・・，３０−Ｎと接続されており、各サービスサーバ−１，３０−２，・・・，３０−Ｎと連携してデータ操作に関する処理を行ってもよい。
【００８８】
データ操作部１３２は、ユーザ情報１３３及び通信処理部１３１と連携して、例えば、後述するような、ユーザ登録処理、仲介用ＩＤの登録処理、及びデータ登録処理を行う。
【００８９】
ユーザ情報１３３は、サービスサーバ３０−１，３０−２，・・・，３０−Ｎの何れかを利用するユーザの認証サーバ１３０におけるユーザＩＤに関する情報を含む。
【００９０】
ＩＤ連携情報１３４は、認証サーバ１３０と各サービスサーバ３０−１，３０−２，・・・，３０−Ｎと間で用いる仲介ＩＤと認証サーバ１３０のユーザＩＤとのマッピングに関するマッピング情報を含む。
【００９１】
また、サービスサーバ３０−１，３０−２，・・・，３０−Ｎの各々も、認証サーバ１３０と同様の構成をしている。すなわち、サービスサーバ３０−１，３０−２，・・・，３０−Ｎはそれぞれ、通信処理部３１−１，３１−２，・・・，３１−Ｎ、及び、データ操作部３２−１，３２−２，・・・，３２−Ｎを備え、ユーザ情報３３−１，３３−２，・・・，３３−Ｎ、及び、ＩＤ連携情報３４−１，３４−２，・・・，３４−Ｎを保持する。
【００９２】
サービスサーバ３０−１によって保持される各ユーザ情報３３−１は、サービスサーバ３０−１を利用するユーザのサービスサーバ３０−１におけるユーザＩＤに関する情報を含む。ユーザ情報３３−２，・・・，３３−Ｎについても同様である。
【００９３】
ＩＤ連携情報３４−１は、認証サーバ１３０のＩＤ連携情報１３４と同一の仲介ＩＤと、サービスサーバ３０−１におけるユーザＩＤとのマッピングに関するマッピング情報を含む。ＩＤ連携情報３４−２，・・・，３４−Ｎについても同様である。
【００９４】
次に、並列処理システム１２０によってなされる処理シーケンスの一例について説明する。  
まず、並列処理システム１２０によってなされる処理シーケンスの概要について説明する。並列処理システム１２０によって実行される動作は、各外部サーバ４０−１，４０−２，・・・，４０−Ｍからのデータ操作リクエストが、更新または削除に関するリクエストである場合、第１の実施形態の並列処理システム１０によって実行される動作と同様の動作である。しかしながら、例えばデータ操作リクエストが、登録に関するリクエストである場合、認証サーバ１３０及び各サービスサーバ３０−１，３０−２，・・・，３０−Ｎへのユーザ登録処理、並びに、認証サーバ１３０及び各サービスサーバ３０−１，３０−２，・・・，３０−Ｎへの仲介用ＩＤの登録処理を、データ登録処理を行う前に実行する必要がある。
【００９５】
次に、具体的に、図１３を参照して、データ登録に関する並列処理について説明する。  
まず、ゲートウェイサーバ２０は、各外部サーバ４０−１，４０−２，・・・，４０−Ｍからデータ登録操作リクエストを受信する（ステップＳ１３１）。そして、ゲートウェイサーバ２０は、データ登録操作リクエストを受信した場合、データ登録処理を並列的に処理する前に、次のような処理を実行する。
【００９６】
要求処理統括管理部２１が、データ登録操作リクエストデータに基づき、各サービスサーバ３０−１，３０−２，・・・，３０−Ｎ及び認証サーバ１３０へのユーザ登録要求データを生成する（ステップＳ１３３）。なお、生成されるユーザ登録要求データは、データ登録操作リクエストデータに含まれているユーザ情報に対応するユーザに関するデータである。
【００９７】
次に、要求処理統括管理部２１が、第１の実施形態において説明したデータ登録処理と同様のデータ登録処理を用いて、サービスサーバ３０−１，３０−２，・・・，３０−Ｎ毎に生成したユーザ登録要求データを分割する（ステップＳ１３５）。そして、要求処理統括管理部２１は、分割したユーザ登録要求データを引数として通信管理部２２を呼び出す。そして、通信管理部２２は、通信先であるサービスサーバ３０（サービスサーバ３０−１，３０−２，・・・，３０−Ｎのうちの何れか）の性能などに適したサイズにユーザ登録要求データを分割し、そして、通信処理部２３を呼び出し、ユーザ登録要求データに関する並列処理を実行する。
【００９８】
次に、要求処理統括管理部２１が、ユーザＩＤ連携要求データ（仲介ＩＤ登録要求データ）を生成する（ステップＳ１３７）。ユーザＩＤ連携要求データは、各サービスサーバ３０−１，３０−２，・・・，３０−Ｎ及び認証サーバ１３０に対するデータ登録操作リクエストデータに含まれるユーザ情報に対応するユーザに関するデータである。また、ユーザＩＤ連携要求データは、認証サーバ１３０および各サービスサーバ３０−１，３０−２，・・・，３０−Ｎに仲介ＩＤを登録することを要求するデータでもある。
【００９９】
なお、ユーザＩＤ連携要求データに含める仲介ＩＤは、データ登録操作リクエストデータに含まれていてもよいし、ゲートウェイサーバ２０によって生成されてもよい。あるいは、ゲートウェイサーバ２０が、データ登録操作リクエストデータに含まれるユーザＩＤに対応する仲介ＩＤを、認証サーバ１３０に発行及び登録するための依頼をし、認証サーバ１３０によって発行された仲介ＩＤを使用してもよい。
【０１００】
次に、要求処理統括管理部２１が、第１の実施形態において説明したデータ登録処理と同様のデータ登録処理を用いて、サービスサーバ３０−１，３０−２，・・・，３０−Ｎ毎にユーザＩＤ連携要求データを分割し（ステップＳ１３９）、分割したユーザＩＤ連携要求データを引数として通信管理部２２を呼び出す。そして、通信管理部２２は、通信先であるサービスサーバ３０（サービスサーバ３０−１，３０−２，・・・，３０−Ｎのうちの何れか）の性能などに適したサイズにユーザＩＤ連携要求データを分割する。そして、通信管理部２２が、通信処理部２３を呼び出し、ユーザＩＤ連携要求データに関する並列処理を実行する（ステップＳ１４１）。
【０１０１】
ステップＳ１４１の後、第１の実施形態において説明したデータ登録に関する並列処理を実行する。例えば、ステップＳ１４１の後、図３に示すようなステップＳ３１の処理を開始する。
【０１０２】
以上のような第３の実施形態によって、次のような効果を得ることができる。  
すなわち、本実施形態によれば、ユーザＩＤを分散させて管理し、認証サーバ１３０およびサービスサーバ３０−１，３０−２，・・・，３０−Ｎ間において実ユーザＩＤでなく仲介ＩＤを用いる場合においても、第１の実施形態の並列処理システム１０または第２の実施形態の並列処理システム１００における並列処理方法を用いて、複数のサービスサーバ３０−１，３０−２，・・・，３０−Ｎに対して、データ操作処理を高速に実行させることが可能となる。また、ユーザＩＤを分散管理することによって、登録に関するリクエストを受けた場合に必要となるような、各サービスサーバ３０−１，３０−２，・・・，３０−Ｎ及び認証サーバ１３０へのユーザ登録処理及びＩＤ連携処理も、１回のリクエストにおいて、高速に実行することが可能となる。
（その他の変形例）
次に、第１の実施形態乃至第３の実施形態において適用可能な変形例について説明する。  
（変形例１）
変形例１では、マルチスレッド処理を実行中にエラーが発生した場合を想定しており、エラー発生時に返却値とエラーに関するログを発行することによって、例えばマルチスレッド処理中のエラー発生時にも、エラー発生箇所を特定する（エラーハンドリング・ログ出力方法）。
【０１０３】
変形例１の並列処理システムにおけるゲートウェイサーバ２０は、エラーが発生した場合、エラーが発生したスレッドに対応するスレッド番号を発行する機能、及び、エラーが発生した箇所を特定するためのログを出力する機能を有する。
【０１０４】
具体的には、ゲートウェイサーバ２０は、エラー発生箇所を特定するために、複数のスレッドの各々に対してスレッド番号を付与し、何れかのスレッドでエラーが発生した場合、エラーが発生したスレッドに対応するスレッド番号（以下、エラースレッド番号と称す。）を発行する。なお、スレッド番号は、例えば、スレッドを分割する際に、予め設定された体系的なスレッド番号である。
【０１０５】
次に、ゲートウェイサーバ２０は、例えば各スレッドに対して処理を実行している際、エラースレッド番号に対応するスレッドに含まれるデータ操作の対象となるデータを、ログとして出力する。また、ゲートウェイサーバ２０は、エラースレッド番号を、例えばリクエスト元である外部サーバ４０またはクライアント端末５０に返却する。
【０１０６】
次に、出力されるログについて説明する。  
まず、要求処理統括管理部２１は、第１の実施形態乃至第３の実施形態において用いた階層的なスレッドにおける各スレッドに対して、スレッドを分割する際、次のような体系的なスレッド番号を付与する。スレッド番号は、例えば「Ｘ．Ｙ．Ｚ」で表わされる。
【０１０７】
ここで、Ｘは、各サービスサーバ３０を示す文字列または数値を表している。文字列で示されるＸは、例えば、「medical」、「care」、「inquiry」、または「checkup」である。また、Ｘの値は、メインスレッドで管理される。
【０１０８】
Ｙは、各サービスサーバ３０に対して、何個目の通信管理スレッドであるかを示す値である。また、Ｙは、同一のサービスサーバ３０に対するデータを引数として通信管理部２１を呼び出すごとに、換言すると通信管理スレッドを作成するごとに、インクリメントされる。また、Ｙの値は、メインスレッドで管理される。
【０１０９】
Ｚは、各通信管理スレッドで生成した何個目の通信処理スレッドであるかを示す値である。Ｚは、通信管理スレッドにおいて通信処理部２３を呼び出すごとに、換言すると通信処理スレッドを起動するごとに、インクリメントされる。また、Ｚの値は、通信管理スレッドで管理される。
【０１１０】
以上のような変形例１によって、次のような効果を得ることができる。  
自治体業務データのように、複数のユーザに関するデータかつ多種多様なデータへの操作要求が含まれるリクエストを、並列処理システム内の複数のサービスサーバ３０に対して行う場合において、処理の高速化及びエラー発生時の発生箇所の特定が可能となる。
【０１１１】
また、利用者であるユーザに対応するクライアント端末５０は、エラー発生時にエラースレッド番号を含む返却値およびログを用いることによって、エラー発生箇所及びエラーにより影響を受ける範囲を特定することが可能となる。また、クライアント端末５０は、必要に応じて、返却値及びログに基づき、例えばエラー発生箇所に対するデータ操作リクエストの再試行を実行することが可能となる。また、クライアント端末５０は、ログに基づき、同一の要求に対する処理であることを判別することによって、要求ごとに正確にデータ操作に関するログを追跡することが可能となる。
【０１１２】
また、各スレッドの処理中に上述したようなエラースレッド番号をログとして出力することにより、例えば、複数のデータ操作リクエストを処理している場合であっても、同一のデータ操作リクエストを処理している親スレッド及び子スレッドが出力するログをそれぞれ対応づけることが可能となり、同一のデータ操作リクエストの処理のログを追跡することが可能となる。
【０１１３】
また、何れかのスレッドでエラーが発生した場合、エラースレッド番号を、例えばリクエスト元である外部サーバ４０またはクライアント端末５０に返却すると共に、エラーが発生したスレッドに含まれるリクエストデータ及びエラースレッド番号をログに出力することによって、エラーの影響が出る可能性がある同一スレッドで処理されたデータを明確化することが可能となる。そのため、エラー発生時の再試行を効率的に行うことが可能となる。
【０１１４】
また、不正利用などが発覚した際、ログを用いて利用者ごとにアクセス履歴を追跡できること必要とされるような場合がある。このような場合において、処理を逐次実行する場合は、例えば、実行中のスレッド名をログに出力することによって、複数のデータ操作リクエストが混在している場合であっても、複数のデータ操作リクエストから同一のデータ操作御リクエストに対応するログを抽出すればよい。しかし、マルチスレッド処理を実行する場合において、同一のデータ操作リクエストの処理を複数のスレッドに分割して実行し、各スレッドが同一のデータ操作リクエストであることを示さない単なる連番などのスレッド名でログを出力するような場合は、実行したデータ操作リクエスト処理の実行状況に関する時系列を用いた追跡や、エラー発生箇所の解析などが困難になる。しかしながら、本発明の変形例１において上述したような処理を実行することによって、このようなことを防ぐことが可能となる。
（変形例２）
変形例２は、要求処理統括管理部２１によるスレッド分割単位に関する変形例である。  
並列処理システムにおいて、リソースをシェアすることによってコストを削減することを目的として、データ種別ごとにサービスサーバ３０を設置したとしても、サービスサーバ３０内において自治体ごとに独立してデータを管理するような場合がある。また、自治体内において管理組織や区分が異なるデータを独立して管理するために、自治体ごとにサービスサーバ３０を設置したとしても、サービスサーバ３０内ではデータごとに独立して管理する場合もある。
【０１１５】
このような場合、要求処理統括管理部２１によって保持されるデータ所在情報２４と、サービスサーバ３０内のデータベースまたはテーブル等に記録されているより詳細なデータに関する宛先及びユーザ属性情報９０−ｃと、をマッピングする。これにより、要求処理統括管理部２１は、リクエストデータに含まれるデータオーナに関するユーザ属性情報９０―ｃをさらに用いてリクエストデータを分割し、通信管理スレッドの単位をサービスサーバ３０内で独立して管理される単位に合わせることが可能となる。また、通信管理部２２が、データ所在情報２４を参照できるようにすることによって、通信管理部２２において通信処理部２３を呼び出す際、ユーザ属性情報９０−ｃをさらに用いてリクエストデータを分割し、通信管理スレッドの単位をサービスサーバ３０内で独立して管理される単位に合わせることが可能となる。
【０１１６】
なお、通信管理部２２におけるスレッド分割単位について、エラー発生時の再試行を行うことを考慮した場合、マルチスレッド処理が成功したか否かの結果は、ユーザ単位で把握できることが望ましい。そのため、リクエストデータに含まれる同一のユーザ情報が多い場合などにおいて、サービスサーバ３０ごとに分割されたリクエストデータを、通信管理部２２においてユーザごとに分割し、通信処理スレッドを起動させるようにしてもよい。
【０１１７】
また、上記第１の実施形態乃至第３の実施形態において、データ操作の一例としてデータ登録について述べたが、リクエストデータをリクエスト検索式に置き換えることによって、データ操作としてデータの検索及びデータの取得について、上記第１の実施形態乃至第３の実施形態を適用可能である。そのため、例えば、ユーザＩＤが分散管理されたデータをＩＤ−ＷＳＦなどのプロトコルを用いてデータを収集することによって、並列処理の高速化が可能となる。
【０１１８】
また、並列処理システム１０，１００，１２０は、外部サーバ４０と接続することなく、ゲートウェイサーバ２０にクライアント端末５０を接続して、例えばＧＵＩを用いて、ローカルにあるリクエストデータを読み込むようにしてもよい。
【０１１９】
なお、この発明は、上記第１の実施形態乃至第３の実施形態に限定されるものではない。例えば、図１，１０，１２に示すような、ゲートウェイサーバ３０とは別に認証サーバ１１０を備えている場合の構成について説明したが、ゲートウェイサーバ３０の中に認証サーバ１１０を備えていてもよい。または、さらに多くのエンティティで構成してもよい。例えば、要求処理統括管理部２１、通信管理部２２、通信処理部２３、認証サーバ１３０、及びサービスサーバ３０の各々が有するデータベースを適宜統合したり、あるいは、さらに分散することによって、並列処理システム１０，１００，１２０を実現してもよい。
【０１２０】
その他、図６乃至図９は、各データベースの一例であり、適宜、フィールドを追加することができるため、図６乃至図９等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
【０１２１】
また、その他の変形例でも示したように、この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【０１２２】
１０，１００，１２０…並列処理システム、２０…ゲートウェイサーバ、２１…要求処理統括管理部、２２…通信管理部、２３…通信処理部、２４…データ所在情報、２５…サービスサーバ経路特性情報、２６…サービスサーバ通信情報、３０…サービスサーバ、４０…外部サーバ、５０…クライアント端末、９０…引き渡しデータベース、９２，９４…登録データ、１１０，１３０…認証サーバ、３１，１３１…通信処理部、３２，１３２…データ操作部、３３，１３３…ユーザ情報、３４，１３４…ＩＤ連携情報。
【図１】
0006340308.tif 000002
【図２】
0006340308.tif 000003
【図３】
0006340308.tif 000004
【図４】
0006340308.tif 000005
【図５】
0006340308.tif 000006
【図６】
0006340308.tif 000007
【図７】
0006340308.tif 000008
【図８】
0006340308.tif 000009
【図９】
0006340308.tif 000010
【図１０】
0006340308.tif 000011
【図１１】
0006340308.tif 000012
【図１２】
0006340308.tif 000013
【図１３】
0006340308.tif 000014