(57)【要約】【課題】電子商取引を迅速化する。【解決手段】電子商取引装置１００は、電子商取引の申込み情報を顧客端末３００から受信して、業務処理装置２００に複数の業務プロセスを実行させることにより電子商取引を実現する。業務プロセスがループ処理を含むとき、電子商取引装置１００は、そのループ処理を細分化した子ループ処理を生成することにより、複数の子業務プロセスを生成する。電子商取引装置１００は、計算リソースの使用可能量が比較的大きい業務処理装置２００に優先的に子業務プロセスを割り当てて実行させる。【選択図】図１
2009193162.tif 000002
【特許請求の範囲】
【請求項１】
複数の業務処理装置と接続され、業務処理装置に複数の業務プロセスを実行させることにより電子商取引サービスを提供するための装置であって、
前記電子商取引サービスへの申込み情報を顧客端末から受信する申込み情報受信部と、
前記申込み情報が受信されたとき、実行すべき業務プロセスを特定する業務プロセス特定部と、
前記特定された業務プロセスをいずれかの業務処理装置に実行させる通常実行部と、
前記特定された業務プロセスのプログラムコードにループ処理が含まれるとき、当該ループ処理を親ループ処理として特定し、親ループ処理を分割して複数の子ループ処理を生成することにより、前記業務プロセスから複数の子業務プロセスを生成する業務プロセス分割部と、
各業務処理装置が備える計算リソースの使用可能量をリソース使用可能量として検出する装置状況検出部と、
前記複数の子業務プロセスの実行主体を複数の業務処理装置に分散させる分散実行部と、
を備え、
前記分散実行部は、複数の業務処理装置のうち前記リソース使用可能量が比較的大きい業務処理装置に優先的に子業務プロセスを割り当てることを特徴とする電子商取引装置。
【請求項２】
前記業務プロセス分割部は、前記親ループ処理が所定の実行回数だけ繰り返される処理であるとき、前記装置状況検出部により各業務処理装置から検出されたリソース使用可能量の比率に応じて当該親ループ処理の実行回数を分割して複数の子ループ処理を生成し、前記複数の子業務プロセスを各業務処理装置に対応づけ、
前記分散実行部は、各業務処理装置に対応づけられた子業務プロセスをそれぞれの業務処理装置に割り当てることを特徴とする請求項１に記載の電子商取引装置。
【請求項３】
子業務プロセスの実行に要する実行負荷を予測する実行負荷予測部をさらに備え、
前記業務プロセス分割部は、前記親ループ処理が複数の命令を繰り返し要素とする処理であるとき、前記複数の命令の一部を繰り返す子ループ処理を１以上の命令に対応づけて複数生成し、
前記実行負荷予測部は、前記生成された子ループ処理を含む子業務プロセスそれぞれの実行負荷を予測し、
前記分散実行部は、実行負荷が所定の閾値よりも大きいと予測される子業務プロセスを前記リソース使用可能量が大きい業務処理装置に優先的に割り当てることを特徴とする請求項１に記載の電子商取引装置。
【請求項４】
複数の業務処理装置と接続され、業務処理装置に複数の業務プロセスを実行させることにより電子商取引サービスを提供するための装置であって、
前記電子商取引サービスへの申込み情報を顧客端末から受信する申込み情報受信部と、
前記申込み情報が受信されたとき、実行すべき業務プロセスを特定する業務プロセス特定部と、
前記特定された業務プロセスをいずれかの業務処理装置に実行させる通常実行部と、
各業務処理装置が備える計算リソースの使用可能量をリソース使用可能量として検出する装置状況検出部と、
前記特定された業務プロセスのプログラムコードにループ処理が含まれ、当該ループ処理が所定の実行回数だけ繰り返される処理であるとき、前記装置状況検出部により各業務処理装置から検出されたリソース使用可能量の比率に応じて当該ループ処理の実行回数を分割して、各業務処理装置に実行させるループ処理の実行回数を算出する実行回数算出部と、
前記ループ処理を含む業務プロセスを複数の業務処理装置に実行させる分散実行部と、
を備え、
前記分散実行部は、前記複数の業務処理装置における一の業務処理装置に前記業務プロセスを実行させるとき、当該業務処理装置について前記算出された実行回数だけループ処理を実行させることを特徴とする電子商取引装置。
【請求項５】
複数の業務処理装置と接続され、業務処理装置に複数の業務プロセスを実行させることにより電子商取引サービスを提供するための装置に、
前記電子商取引サービスへの申込み情報を顧客端末から受信する機能と、
前記申込み情報が受信されたとき、実行すべき業務プロセスを特定する機能と、
前記特定された業務プロセスをいずれかの業務処理装置に実行させる機能と、
前記特定された業務プロセスのプログラムコードにループ処理が含まれるとき、当該ループ処理を親ループ処理として特定し、親ループ処理を分割して複数の子ループ処理を生成することにより、前記業務プロセスから複数の子業務プロセスを生成する機能と、
各業務処理装置が備える計算リソースの使用可能量をリソース使用可能量として検出する機能と、
前記複数の子業務プロセスの実行主体を複数の業務処理装置に分散させる機能と、
を実現させ、
前記分散させる機能は、複数の業務処理装置のうち前記使用可能量が比較的大きい業務処理装置に優先的に子業務プロセスを割り当てることを特徴とするコンピュータプログラム。
【請求項６】
複数の業務処理装置と接続され、業務処理装置に複数の業務プロセスを実行させることにより電子商取引サービスを提供するための装置に、
前記電子商取引サービスへの申込み情報を顧客端末から受信する機能と、
前記申込み情報が受信されたとき、実行すべき業務プロセスを特定する機能と、
前記特定された業務プロセスをいずれかの業務処理装置に実行させる機能と、
各業務処理装置が備える計算リソースの使用可能量をリソース使用可能量として検出する機能と、
前記特定された業務プロセスのプログラムコードにループ処理が含まれ、当該ループ処理が所定の実行回数だけ繰り返される処理であるとき、前記各業務処理装置から検出されたリソース使用可能量の比率に応じて当該ループ処理の実行回数を分割して、各業務処理装置に実行させるループ処理の実行回数を算出する機能と、
前記ループ処理を含む業務プロセスを複数の業務処理装置に実行させる機能と、
を実現させ、
前記複数の業務処理装置に実行させる機能は、前記複数の業務処理装置における一の業務処理装置に前記業務プロセスを実行させるとき、当該業務処理装置について前記算出された実行回数だけループ処理を実行させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、電子商取引技術に関する。
【背景技術】
【０００２】
近年、コンピュータの普及とネットワーク技術の進展にともない、ネットワークを介した電子情報の交換が盛んになっている。商取引の多くも、ネットワークを介したいわゆる電子商取引に移行しつつあり、最近ではインターネット上にさまざまな電子商取引サイトが開設されている。
【特許文献１】特開平１１−２５０１５５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
電子商取引を申込む旨の申込み情報を顧客から受け付けた電子商取引装置は、通常、複数の業務プロセスを様々な業務処理装置に実行させることにより、電子商取引サービスを提供する。本明細書における「業務プロセス」は、「与信確認」や「経理処理」等、電子商取引を実現するための各業務を実行するソフトウェアモジュールを意味する。
【０００４】
業務プロセスの中には、その実行完了までに時間がかかるものがある。一方で、電子商取引装置は、通常、業務プロセスを単位として、いずれかの業務処理装置に実行を要求する。その結果、実行完了までに長時間を要する業務プロセスがネックとなり、電子商取引の処理完了までに長い時間がかかる場合があり、顧客の利便性を損なうことがあった。
【０００５】
電子商取引で実行される業務プロセスは、そのプログラムコードにおいてループ処理を含むことが多い。本発明者は、業務プロセスに含まれるループ処理を分割して複数の業務処理装置に分散実行させることで業務プロセスの実行時間を短縮でき、迅速な電子商取引を実現できると考えた。
【０００６】
本発明は、本発明者の上記着目に基づいて完成された発明であり、その主たる目的は、電子商取引を迅速化する技術を提供することである。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様の電子商取引装置は、複数の業務処理装置と接続され、業務処理装置に複数の業務プロセスを実行させることにより電子商取引サービスを提供するための装置であって、電子商取引サービスへの申込み情報を顧客端末から受信する申込み情報受信部と、申込み情報が受信されたとき、実行すべき業務プロセスを特定する業務プロセス特定部と、特定された業務プロセスをいずれかの業務処理装置に実行させる通常実行部と、特定された業務プロセスのプログラムコードにループ処理が含まれるとき、当該ループ処理を親ループ処理として特定し、親ループ処理を分割して複数の子ループ処理を生成することにより、業務プロセスから複数の子業務プロセスを生成する業務プロセス分割部と、各業務処理装置が備える計算リソースの使用可能量をリソース使用可能量として検出する装置状況検出部と、複数の子業務プロセスの実行主体を複数の業務処理装置に分散させる分散実行部と、を備える。分散実行部は、複数の業務処理装置のうちリソース使用可能量が比較的大きい業務処理装置に優先的に子業務プロセスを割り当てる。
【０００８】
本発明の別の態様もまた、電子商取引装置である。この装置は、複数の業務処理装置と接続され、業務処理装置に複数の業務プロセスを実行させることにより電子商取引サービスを提供するための装置であって、電子商取引サービスへの申込み情報を顧客端末から受信する申込み情報受信部と、申込み情報が受信されたとき、実行すべき業務プロセスを特定する業務プロセス特定部と、特定された業務プロセスをいずれかの業務処理装置に実行させる通常実行部と、各業務処理装置が備える計算リソースの使用可能量をリソース使用可能量として検出する装置状況検出部と、特定された業務プロセスのプログラムコードにループ処理が含まれ、当該ループ処理が所定の実行回数だけ繰り返される処理であるとき、装置状況検出部により各業務処理装置から検出されたリソース使用可能量の比率に応じて当該ループ処理の実行回数を分割して、各業務処理装置に実行させるループ処理の実行回数を算出する実行回数算出部と、ループ処理を含む業務プロセスを複数の業務処理装置に実行させる分散実行部と、を備える。分散実行部は、複数の業務処理装置における一の業務処理装置に業務プロセスを実行させるとき、当該業務処理装置について算出された実行回数だけループ処理を実行させる。
【０００９】
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１０】
本発明によれば、電子商取引を迅速化できる。
【発明を実施するための最良の形態】
【００１１】
本発明の典型的な実施形態は、電子商取引サービスを顧客に提供する電子商取引装置である。この電子商取引装置は、電子商取引において実行されるべき複数の業務プロセスを業務処理装置に実行させることで電子商取引を実現する。また、この電子商取引装置は、業務プロセスにおけるループ処理を分割して、複数の業務処理装置に分散実行させることで、業務プロセスの処理時間の短縮を実現する。
【００１２】
図１は、電子商取引システムのハードウェア構成図である。
以下の説明において、電子商取引システム１０００は、電子商取引「先物為替予約の中途解約（以下、単に「中途解約」と呼ぶ。）」の申込みを受け付けて、その処理結果を作成するまでの電子商取引を実現するシステムとして説明する。通信網４００は、ＬＡＮ（Local Area Network）・ＷＡＮ（Wide Area Network）・インターネット等を含むデータ通信ネットワークである。
【００１３】
電子商取引システム１０００において、電子商取引装置１００は、通信網４００を介して、複数の顧客端末３００ａ、３００ｂ、・・・３００ｃ（以下、単に「顧客端末３００」と呼ぶ。）と接続されている。また、通信網４００を介して、複数の業務処理装置２００ａ、２００ｂ、・・・２００ｃ（以下、単に「業務処理装置２００」と呼ぶ。）とも接続されている。
【００１４】
電子商取引装置１００は、ウェブサーバとしての機能を有し、顧客端末３００にウェブページを送信する。このウェブページにより、顧客が電子商取引装置１００にアクセスするためのユーザインタフェースが提供される。顧客端末３００は、ウェブブラウザを搭載した一般的なウェブ端末である。
【００１５】
また、電子商取引装置１００は、業務処理装置２００に複数の業務プロセスを実行させることにより電子商取引を実現する。業務プロセスがループ処理（以下、「親ループ処理」とも呼ぶ。）を含むとき、電子商取引装置１００は、そのループ処理を細分化したループ処理（以下、「子ループ処理」とも呼ぶ。）を生成することにより、複数の子業務プロセスを生成する。電子商取引装置１００は、業務処理装置２００それぞれにおける計算リソース、具体的にはＣＰＵ・メモリ・磁気記録媒体等の使用可能量に応じて、子業務プロセスを各業務処理装置２００に割り当てる。
【００１６】
以下、親ループ処理が有限の実行回数だけ繰り返される処理であることを前提として、親ループ処理の実行回数を分割して複数の子ループ処理を生成する電子商取引装置１００を第１の実施形態にて提案する。また、同様の前提条件において、親ループ処理の実行回数を分割して、分割された実行回数を業務処理装置２００の業務プロセス実行時にパラメータとして指定する電子商取引装置１００を第３の実施形態にて提案する。さらにまた、親ループ処理が複数の命令を繰り返しの要素とする処理であることを前提として、複数の命令のうち一部を繰り返す子ループ処理を各命令に対応づけて複数生成する電子商取引装置１００を第２の実施形態にて提案する。
【００１７】
（第１の実施形態）
図２は、第１の実施形態における電子商取引装置１００の機能構成を示すブロック図である。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。
【００１８】
電子商取引装置１００は、ユーザインタフェース処理部１０と、データ保持部２０と、データ処理部３０とを備える。
ユーザインタフェース処理部１０は、顧客端末３００とのユーザインタフェース処理を担当する。データ保持部２０は、各種データを保持するための記憶領域である。データ処理部３０は、ユーザインタフェース処理部１０やデータ保持部２０から取得されたデータをもとにして各種のデータ処理を実行し、また、業務処理装置２００とのインタフェース処理も担当する。さらに、データ処理部３０は、ユーザインタフェース処理部１０とデータ保持部２０との間のインタフェースの役割も果たす。
【００１９】
ユーザインタフェース処理部１０:
ユーザインタフェース処理部１０は、申込み情報受信部１２を有する。申込み情報受信部１２は、インターネットを介して、顧客端末３００から送信された電子商取引「中途解約」の申込み情報を受信する。
【００２０】
データ保持部２０：
データ保持部２０は、業務プロセス情報保持部２２と、進捗情報保持部２４とを有する。
業務プロセス情報保持部２２は、電子商取引において実行されるべき複数の業務プロセスそれぞれの属性を示す業務プロセス情報を保持する。
【００２１】
図３は、業務プロセス情報のデータ構造を示す。業務プロセス欄１０２には、電子商取引「中途解約」において実行されるべき業務プロセスの識別情報が記録される。同図では業務プロセス名が記録されている。実行順序欄１０４には、各業務プロセスの実行順序が記録される。ループ有無欄１０６には、業務処理のプログラムコードに「for」ブロックや「while」ブロック等のループ処理が存在するか否かが記録される。また、ループ処理を含む業務プロセスであって、処理時間が所定の閾値よりも短い業務プロセス、言い換えれば、ループ処理を分割する必要のない業務プロセスの場合、そのループ有無欄１０６には常に「無」が設定されてもよい。なお、この閾値は企業の経験や実験の結果に基づいて、適切な値が設定されればよい。
【００２２】
ソースプログラム欄１０８には、電子商取引装置１００のファイルシステム内の位置を示す情報であって、業務プロセスのソースプログラムが保持されているパス情報が記録される。例えば、業務プロセス「申込み内容チェック」のソースプログラムは、ディレクトリ「/opt/calc」に保持される「Check」ファイルであることを示している。なお、ソースプログラム欄１０８には、業務プロセスのソースプログラムを参照先とするファイルポインタが保持されてもよく、ソースプログラムそのものが保持されてもよい。図２に戻る。
【００２３】
進捗情報保持部２４は、顧客から申込まれた電子商取引「中途解約」の進捗情報であって、当該電子商取引に含まれる各業務プロセスが実行済か未実行かを示す実行状態情報を保持する。図４は、進捗情報のデータ構造を示す。申込みＩＤ欄１１２には、顧客から申込まれた電子商取引の識別情報が記録される。実行予定業務プロセス欄１１４には、電子商取引において実行されるべき複数の業務プロセスが実行順に記録される。実行フラグ欄１１６には、各業務プロセスの実行状態情報が記録される。図２に戻る。
【００２４】
データ処理部３０：
データ処理部３０は、進捗情報更新部３２と、業務プロセス特定部３４と、通常実行部３６と、装置状況検出部３８と、業務プロセス分割部４０と、分散実行部４２とを有する。
【００２５】
進捗情報更新部３２は、電子商取引「中途解約」に対する申込み情報が受信されたことを契機に、業務プロセス情報保持部２２から業務プロセス情報を取得して、進捗情報保持部２４に実行予定業務プロセスとして追加する。例えば、図４のように申込みＩＤ「００２」まで進捗情報に記録されている状態で、新規の申込み情報が申込みＩＤ「００３」として受信されるとする。このとき、進捗情報更新部３２は、図３で示す業務プロセス情報から業務プロセス名を取得し、申込みＩＤ「００３」および実行フラグ「未実行」に対応づけ、図３で示す実行順序にしたがって図４の進捗情報に追加する。また、進捗情報更新部３２は、後述する通常実行部３６または分散実行部４２から業務プロセスの実行完了が通知されたとき、進捗情報保持部２４にアクセスして、当該業務プロセスの実行フラグ欄１１６を「実行済」に更新する。
【００２６】
業務プロセス特定部３４は、電子商取引の進捗情報から実行すべき未実行の業務プロセス（以下、「実行対象業務プロセス」と呼ぶ。）を特定する。例えば、電子商取引の進捗情報が図４で示す状態であるとき、業務プロセス特定部３４は、実行フラグ欄１１６が「未実行」の業務プロセスのうち実行順序が早い業務プロセスを実行対象業務プロセスとして特定する。すなわち図４からは、申込みＩＤ「００１」の実行予定業務プロセス「中途解約利金計算」、または、申込みＩＤ「００２」の実行予定業務プロセス「申込み内容チェック」が実行対象業務プロセスとして特定される。
【００２７】
通常実行部３６は、業務プロセス特定部３４により特定された実行対象業務プロセスを業務処理装置２００のいずれかに実行させる。通常実行部３６が対象とする実行対象業務プロセスは、そのプログラムコードにループ処理を含まないもの、言い換えれば、図３で示す業務プロセス情報のループ有無欄１０６が「無」に設定された業務プロセスである。例えば、図４の実行予定業務プロセス「申込み内容チェック」が実行対象業務プロセスとして特定されたとする。このとき、通常実行部３６は、図３の業務プロセス情報を参照して、当該業務プロセスはループ処理を含まないと判定し、当該業務プロセスを業務処理装置２００のいずれかに実行させる。
【００２８】
なお、通常実行部３６が、業務処理装置２００の中から実行対象業務プロセスを実行させる主体を決定する方法には特に制限はない。業務処理装置２００の中からランダムに決定してもよく、後述する装置状況検出部３８により検出される計算リソースの使用可能量が比較的大きい業務処理装置２００に決定してもよい。
【００２９】
装置状況検出部３８は、各業務処理装置２００が備える計算リソースの使用可能量をリソース使用可能量として検出する。ここでのリソース使用可能量は、業務処理装置に搭載されたＣＰＵやメモリ等の計算リソース量の割合であって、業務プロセス処理のために使用可能な割合を示す。
【００３０】
装置状況検出部３８は、まず、業務処理装置２００のＯＳ（Operating System）が備えるＡＰＩ（Application Program Interface）を呼び出し、または業務処理装置２００に対しコマンドを発行して、各業務処理装置２００における計算リソースの使用量を取得する。例えば、各業務処理装置２００に「vmstat」コマンドを発行することにより、ＣＰＵ使用率やメモリ使用率等を取得してもよい。続いて装置状況検出部３８は、計算リソースの使用量からリソース使用可能量を算出する。例えば、ある業務処理装置のＣＰＵ利用率が「0.3」であるとき、そのＣＰＵリソースの使用可能量は「0.7」であると算出する。
【００３１】
また、装置状況検出部３８は、各業務処理装置２００においてＣＰＵやメモリの搭載量が異なるとき、所定のリソース量に正規化してリソース使用可能量を算出してもよい。例えば、ＣＰＵ１個の業務処理装置（以下、「業務処理装置Ａ」と呼ぶ。）におけるＣＰＵの使用可能量が「0.4」で、ＣＰＵ４個の業務処理装置（以下、「業務処理装置Ｂ」と呼ぶ。）におけるＣＰＵの使用可能量が「0.2」であるとする。ＣＰＵ１個で正規化する場合、装置状況検出部３８は、業務処理装置ＡにおけるＣＰＵの使用可能量はそのまま「0.4」とする一方で、業務処理装置ＢにおけるＣＰＵの使用可能量は４倍の「0.8」としてもよい。以降の説明では、いずれの業務処理装置２００においてもリソース搭載量は同一であり、正規化は不要であるとして説明する。
【００３２】
なお、装置状況検出部３８は、所定の時間経過ごとに各業務処理装置２００にアクセスして、リソース使用可能量を検出し、そのリソース使用可能量をデータ保持部２０に記録してもよい。また、後述する業務プロセス分割部４０の指示を受け付けたときにリソース使用可能量を検出してもよい。
【００３３】
業務プロセス分割部４０は、実行対象業務プロセスがループ処理を含むとき、親ループ処理の実行回数を分割して複数の子ループ処理を生成する。これにより、１つの業務プロセスから複数の子業務プロセスを生成して、それぞれの子業務プロセスを各業務処理装置２００に対応づける。
【００３４】
具体的に、業務プロセス分割部４０は、まず、装置状況検出部３８により各業務処理装置２００から検出されたリソース使用可能量を取得する。また、実行対象業務プロセスの業務プロセス情報におけるソースプログラム欄１０８に記録されたパス情報を参照して、当該業務プロセスのソースプログラムを取得する。続いて、各業務処理装置２００のリソース使用可能量の比率に応じて親ループ処理の実行回数を分割して、複数の子ループ処理の実行回数を設定し、複数の子業務プロセスのソースプログラムを生成する。必要な場合には、生成したソースプログラムをさらにコンパイルし、オブジェクトプログラムを生成してもよい。最後に、子ループ処理それぞれの実行回数に対応するリソース使用可能量を有する業務処理装置２００に対して当該子ループ処理を含む子業務プロセスを対応づける。
【００３５】
図５（ａ）は、分割前の業務プロセスを示す。同図では、１００回の繰り返しを行うループ処理の中で３つの命令が呼び出されている。ここでは、業務プロセス分割部４０は、図５（ａ）の業務プロセスから、図１の業務処理装置２００ａ、２００ｂおよび２００ｃにそれぞれ実行させる子業務プロセスを生成する。また、各業務処理装置２００のリソース使用可能量は、それぞれ「0.7」、「0.5」および「0.3」であるとする。
【００３６】
このとき、業務プロセス分割部４０は、以下で示すように、親ループの実行回数１００回を各業務処理装置２００におけるリソース使用可能量の比率で按分して、各業務処理装置２００に割り当てる子ループの実行回数を設定する。
業務処理装置２００ａでの実行回数：100*0.7/(0.7+0.5+0.3) = 47
業務処理装置２００ｂでの実行回数：100*0.5/(0.7+0.5+0.3) = 33
業務処理装置２００ｃでの実行回数：100*0.3/(0.7+0.5+0.3) = 20
図５（ｂ）は、分割後の業務プロセスを示す。同図では、実行回数が４７回、３３回および２０回の子ループを含む３つの子業務プロセスが生成された状態を示している。業務プロセス分割部４０は、「Module Penalty_1」を業務処理装置２００ａに、「Module Penalty_2」を業務処理装置２００ｂに、「Module Penalty_3」を業務処理装置２００ｃにそれぞれ対応づける。
【００３７】
分散実行部４２は、各業務処理装置２００に対応づけられた子業務プロセスをそれぞれの業務処理装置２００に実行させる。例えば、上述の例では、業務プロセス分割部４０により生成された子業務プロセス「Module Penalty_1」を業務処理装置２００ａに送信して実行させる。必要な場合には、子業務プロセスを実行した各業務処理装置２００からその実行結果を取得して、複数の実行結果を合算等してもよい。
【００３８】
また、各業務処理装置２００は、ループ処理を含む業務プロセスについては、当該ループ処理の実行回数を呼び出し側から指定できる形式で保持していてもよい。この場合、分散実行部４２は、業務プロセス分割部４０により各業務処理装置２００に対して設定された実行回数の情報を各業務処理装置２００に送信して、各業務処理装置２００において当該実行回数だけ業務プロセスを実行させる。言い換えれば、分散実行部４２は、子業務プロセスのモジュールそのものを送信するのではなく、子業務プロセスを実行するためのパラメータのみを送信して、各業務処理装置２００に子業務プロセスを実行させてもよい。
【００３９】
以下、電子商取引装置１００における処理の流れをフローチャートにて説明する。
図６（ａ）は、申込み情報の受け付けにおける一連の処理を示すフローチャートである。申込み情報受信部１２は、顧客端末３００から送信された申込み情報を受信する（Ｓ１０）。進捗情報更新部３２は、進捗情報保持部２４にアクセスして、電子商取引の進捗情報を更新する（Ｓ１２）。つまり、電子商取引において実行すべき業務プロセスを業務プロセス情報保持部２２から取得して進捗情報保持部２４の進捗情報に追加する。
【００４０】
図６（ｂ）は、業務プロセスの実行における一連の処理を示すフローチャートである。業務プロセス特定部３４は、進捗情報保持部２４を参照して、電子商取引の進捗情報から実行対象業務プロセスを特定する（Ｓ２０）。実行対象業務プロセスがループ処理を含まないとき（Ｓ２２のＮ）、通常実行部３６は、その実行対象業務プロセスを業務処理装置２００のいずれかに実行させる（Ｓ３０）。実行対象業務プロセスがループ処理を含むとき（Ｓ２２のＹ）、装置状況検出部３８は、業務プロセス分割部４０の要求に応じて、各業務処理装置２００のリソース使用可能量を検出する（Ｓ２４）。業務プロセス分割部４０は、各業務処理装置２００のリソース使用可能量の比率に応じてループ処理を分割し、複数の子業務プロセスを生成する（Ｓ２６）。分散実行部４２は、子業務プロセスの実行主体を複数の業務処理装置に分散して、複数の子業務プロセスを各業務処理装置２００に分散実行させる（Ｓ２８）。
【００４１】
第１の実施形態によれば、親ループ処理を複数の子ループ処理に分割することで子業務プロセスを生成し、複数の業務処理装置のうちリソース使用可能量が比較的大きい業務処理装置に優先的に子業務プロセスを割り当てる。具体的には、各業務処理装置のリソース使用可能量に応じて親ループ処理の実行回数を分割して子業務プロセスを生成する。実行に時間のかかるループ処理を分散実行させることで、業務プロセスの実行時間を短縮できる。また、リソース使用可能量が比較的大きい業務処理装置に割り当てる子業務プロセスにはその子ループ処理に多くの実行回数を設定することで、業務プロセスの実行時間をさらに短縮できる。
【００４２】
また、第１の実施形態によれば、それぞれの子ループ処理の実行回数を各業務処理装置のリソース使用可能量に応じて動的に決定できる。これにより、業務プロセス実行に伴い発生する負荷を各業務処理装置の負荷状況に応じて適切に配分できる。つまり、業務プロセスを業務処理装置に割り当てる時点において計算処理の負荷が高い業務処理装置には実行回数が少ない子ループ処理を、計算処理の負荷が低い業務処理装置には実行回数が多い子ループ処理を割り当てられる。この結果、各業務処理装置の負荷を平準化できるとともに、各業務処理装置が備える計算リソースを有効活用できる。
【００４３】
さらに、ループ処理の動的分割により各業務処理の負荷を平準化できることは、システム開発者の負担も軽減する。すなわち、従来は、開発時に決定されて実装された業務プロセスの粒度がそのまま実行単位となり、業務プロセスの実行性能にも影響していた。したがって、業務プロセスの実行時間を改善するためには、システム開発者は、業務処理分割やプログラムコードの書き換え等、手作業による性能チューニングを実施する必要があった。本実施の形態によれば、ループ処理の動的分割、言い換えれば動的な性能チューニングを実現することで、システム開発者および保守者の負担を軽減する。
【００４４】
（第２の実施形態）
図７は、第２の実施形態における電子商取引装置１００の機能構成を示すブロック図である。同図において、第１の実施形態における電子商取引装置１００の部材に対応する部材については、図２と同じ符号を付している。第２の実施形態のデータ処理部３０は、第１の実施形態の構成に加え、実行負荷予測部４４を有する。
以下、第１の実施形態と異なる特徴、主に、業務プロセス分割部４０、実行負荷予測部４４および分散実行部４２について説明する。
【００４５】
業務プロセス分割部４０は、親ループ処理に含まれる複数の命令のうち一部を繰り返す子ループ処理を１以上の命令に対応づけて複数生成する。例えば、図５（ａ）で示した業務プロセスでは、ループ処理の中で３つの命令が繰り返し要素として記述されている。業務プロセス分割部４０は、それら３つの命令のうち１つを繰り返す３つの子ループ処理を生成することにより、当該業務プロセスから３つの子業務プロセスを生成してもよい。
【００４６】
図８は、分割後の業務プロセスを示す。同図は、図５（ａ）の親ループ処理における繰り返し回数はそのままで、親ループ処理で実行される命令ごとに３つの子ループが生成され、それに伴い３つの子業務プロセスが生成された状態を示している。
【００４７】
また、業務プロセス分割部４０は、子業務プロセスの子ループ処理の中に複数の命令を設定してもよい。例えば親ループでは６つの命令が繰り返し要素となっているものの、業務処理装置が３つである場合には、子ループ処理それぞれにおける命令数を２つずつとして、３つの子業務プロセスを生成してもよい。図７に戻る。
【００４８】
さらにまた、業務プロセス分割部４０は、親ループから子ループを生成する前に、構文解析等の既知の技術により親ループ内の各命令の依存関係を取得して、その依存関係に基づいて親ループ内の命令の分割可否を判定してもよい。例えば、親ループに含まれる３つ命令のうち２つの命令の間に依存関係があるとき、業務プロセス分割部４０は、これら２つの命令については同一の子ループに割り当ててもよい。これにより、プログラムの整合性を維持しつつ、ループ処理を分割できる。
【００４９】
実行負荷予測部４４は、業務プロセス分割部４０により生成された子業務プロセスそれぞれの実行に要する実行負荷を予測する。実行負荷とは、子業務プロセスを実行するために必要となる計算リソース使用量であり、具体的にはＣＰＵ使用量やメモリ使用量である。具体的に、実行負荷予測部４４は、まず、子業務プロセスに含まれる子ループ処理の実行回数を１回に設定し、子業務プロセスそれぞれの実行時間を計測する。続いて、計測したそれぞれの実行時間を所定の閾値と比較することにより、実際には子ループ処理を複数回繰り返す子業務プロセスそれぞれの実行負荷の大小を決定する。なお、この閾値は、企業の経験や実験の結果に基づき、適切な値に決定されればよい。
【００５０】
図８で示した子業務プロセスの実行負荷を実行負荷予測部４４が予測する例を説明する。実行負荷予測部４４は、まず、「Module Penalty_1」、「Module Penalty_2」および「Module Penalty_3」におけるループ処理の実行回数を１に設定して実行し、実行結果のログファイル等を参照して、それぞれの実行時間を検出する。続いて、それぞれの実行時間と所定の閾値とを比較する。比較した結果、例えば、「Module Penalty_1」の実行時間が第１の閾値未満であり、「Module Penalty_2」の実行時間が第１の閾値以上かつ第２の閾値未満であり、「Module Penalty_3」の実行時間が第２の閾値以上であったとする。このとき、実行負荷予測部４４は、「Module Penalty_1」の実行負荷を「小」、「Module Penalty_2」の実行負荷を「中」、「Module Penalty_3」の実行負荷を「大」と決定する。
【００５１】
また、実行負荷予測部４４は、実行時間を計測する代わりに、実際のＣＰＵ使用時間をＯＳのコマンド、例えば「prstat」等により取得して実行負荷の大小を決定してもよい。
【００５２】
さらにまた、実行負荷予測部４４は、子業務プロセスの実行負荷の相対的な大小を単に予測してもよい。この場合、実行時間が「Module Penalty_1」＜「Module Penalty_2」＜「Module Penalty_3」であるとき、実行負荷予測部４４は、子業務プロセスの実行負荷の大小は、「Module Penalty_1」＜「Module Penalty_2」＜「Module Penalty_3」であると決定する。
【００５３】
さらにまた、実行負荷予測部４４は、過去の実績データに基づいて子業務プロセスの実行時間を取得して、実行負荷の大小を決定してもよい。例えば、実行負荷予測部４４は、過去の子業務プロセスの実行ログ等を参照することで、子業務プロセスそれぞれの実行時間の実績を取得し、各実行時間をそれぞれの大小を比較して、または、各実行時間を所定の閾値と大小を比較して、実行負荷の大小を決定してもよい。
【００５４】
分散実行部４２は、実行負荷が所定の閾値よりも大きいと予測された子業務プロセスをリソース使用可能量が大きい業務処理装置に優先的に実行させる。言い換えれば、リソース使用可能量に余裕がある業務処理装置に実行負荷が大きな子業務プロセスを優先的に割り当てる。例えば、上述の例で、実行負荷が「中」以上の「Module Penalty_2」および「Module Penalty_3」については、業務処理装置２００のうちリソース使用可能量が大きい業務処理装置に割り当てる。一方で、実行負荷が「小」の「Module Penalty_1」については、業務処理装置２００の中からランダムに割り当ててもよい。
【００５５】
なお、分散実行部４２は、業務処理装置２００のリソース使用可能量の大小および子業務プロセスの実行負荷の大小を対応させて、子業務プロセスをいずれかの業務処理装置２００に割り当ててもよい。例えば、リソース使用可能量が業務処理装置２００ａ＞２００ｂ＞２００ｃであり、子業務プロセスの実行負荷が「Module Penalty_1」＜「Module Penalty_2」＜「Module Penalty_3」であるとする。このとき、分散実行部４２は、業務処理装置２００ａ、２００ｂおよび２００ｃにそれぞれ「Module Penalty_3」、「Module Penalty_2」および「Module Penalty_1」を割り当ててもよい。
【００５６】
図９は、業務プロセスの実行における一連の処理を示すフローチャートである。同図のＳ４０、Ｓ４２およびＳ５２は、図６（ｂ）のＳ２０、Ｓ２２およびＳ３０と同様であるため説明を省略する。業務プロセス分割部４０は、親ループにて実行される複数の命令を分割することにより複数の子業務プロセスを生成する（Ｓ４４）。実行負荷予測部４４は、子業務プロセスそれぞれの実行負荷を予測する（Ｓ４６）。装置状況検出部３８は、各業務処理装置２００のリソース使用可能量を検出する（Ｓ４８）。分散実行部４２は、実行負荷が大きい子業務プロセスの実行主体をリソース使用可能量が大きい業務処理装置２００に優先的に割り当てることで、子業務プロセスを複数の業務処理装置２００に分散実行させる（Ｓ５０）。
【００５７】
なお、図９のフローチャートにおけるＳ４４およびＳ４６は、電子商取引装置１００の事前処理としてあらかじめ実行されてもよい。例えば、業務プロセスの開発時、言い換えれば、電子商取引サービスの提供前に実行されてもよい。このとき、業務プロセス分割部４０は、図８の子業務プロセスを事前に生成しておく。例えば、業務処理装置２００の数にあわせて子業務プロセスを生成しておいてもよい。実行負荷予測部４４は、子業務プロセスそれぞれの実行に要する実行負荷を事前に予測する。これにより、業務プロセス実行時における子業務プロセスの生成が不要となり、より迅速な業務プロセス処理が実現される。また、電子商取引装置１００に必要となるハードウェアリソース量も低減される。
【００５８】
第２の実施形態によれば、親ループ処理を複数の子ループ処理に分割することで子業務プロセスを生成し、複数の業務処理装置のうちリソース使用可能量が比較的大きい業務処理装置に優先的に子業務プロセスを割り当てる。具体的には、親ループ処理の繰り返し要素である複数の命令を分割して子業務プロセスを生成し、実行負荷が大きな子業務プロセスはリソース使用可能量に余裕のある業務処理装置に実行させる。実行に時間のかかるループ処理を分散実行させることで、業務プロセスの実行時間を短縮できる。また、子業務プロセスの実行負荷および業務処理装置のリソース使用可能量を加味して子業務プロセスの実行主体を決定することで、業務プロセスの実行時間をさらに短縮できる。
【００５９】
また、第２の実施形態においても、各業務処理装置に割り当てる子業務プロセスを各業務処理装置のリソース使用可能量に応じて動的に決定できる。これにより、第１の実施形態において既述したように、各業務処理装置の負荷を平準化できるとともに、各業務処理装置が備える計算リソースを有効活用できる。また、システム開発者の負担も軽減する。
【００６０】
（第３の実施形態）
第３の実施形態では、あらかじめループ処理を含む業務プロセスは、そのループ処理の実行回数を呼び出し時に指定できるように設定されている。つまり、ループ処理の実行回数が変数（以下、「ラベル」）で記述されており、呼び出し側からそのラベル値を指定できる。図１０は、ラベルにより繰り返し回数が指定される業務プロセスを示す。第３の実施形態の電子商取引装置１００は、各業務処理装置２００のリソース使用可能量に応じて、その実行回数を分割して、各業務処理装置２００に実行させるループ処理の実行回数を算出する。各業務処理装置に算出した実行回数を通知して、それぞれのリソース使用可能量に応じた回数だけループ処理を実行させる。
【００６１】
電子商取引装置１００の構成は、図２で示す第１の実施形態の構成と同様であるが、データ処理部３０は、業務プロセス分割部４０の代わりに、ループ処理分割部を有する。以下、第１の実施形態と異なる特徴、主に、ループ処理分割部および分散実行部４２について説明する。
【００６２】
ループ処理分割部は、装置状況検出部３８により各業務処理装置２００から検出されたリソース使用可能量の比率に応じて、ループ処理の実行回数を分割する。ループ処理分割部は、例えば、第１の実施形態の業務プロセス分割部４０のように、各業務処理装置２００におけるリソース使用可能量の比率で按分して、各業務処理装置２００に割り当てる子ループの実行回数を算出してもよい。ここでは、第１の実施形態の例と同様に、業務処理装置２００ａ、２００ｂ、２００ｃにおけるループ処理の実行回数として、それぞれ４７、３３、２０が算出されたこととする。
【００６３】
なお、実行回数の算出において使用する実行回数の総数については、その総数がいずれかの業務プロセスの実行結果により決定される場合には、ループ処理分割部は、当該業務プロセスの実行結果を参照すればよい。また、所定の回数が事前に決まっている場合には、データ保持部２０はその所定の回数を業務プロセスおよびループ処理の識別情報に対応づけて保持し、ループ処理分割部は、データ保持部２０にアクセスして、その所定の回数を参照すればよい。
【００６４】
分散実行部４２は、ループ処理を含む業務プロセスを複数の業務処理装置２００に分散して実行させる。例えば、図１０の業務プロセス「Module Penalty」を各業務処理装置２００に送信して実行させる。また、これに併せて、業務プロセス「Module Penalty」のループ処理におけるラベル値として、ループ処理分割部により算出された実行回数を指定する。ここでは、業務処理装置２００ａに対しては、「VALa」のラベル値として１、「VALb」のラベル値として４７を指定する。また、業務処理装置２００ｂに対しては、「VALa」のラベル値として４８、「VALb」のラベル値として８０を指定する。業務処理装置２００ｃに対しては、「VALa」のラベル値として８１、「VALb」のラベル値として１００を指定する。なお、必要な場合には、子業務プロセスを実行した各業務処理装置２００からその実行結果を取得して、複数の実行結果を合算等してもよい。
【００６５】
第３の実施形態によれば、第１の実施形態で既述した効果に加え、業務プロセスから子業務プロセスを生成する処理が不要となるため、迅速な業務プロセス処理が実現される。また、電子商取引装置１００に必要となるハードウェアリソース量も低減される。
【００６６】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００６７】
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【００６８】
上述した３つの実施形態が有効な電子商取引サービスの具体例として、複数の通貨により構成される外貨建て債券の償還前売却サービスや、複数の通貨により構成されるオプション付き外貨預金の中途解約サービス等がある。すなわち、従来技術では、１つの業務プロセスの中で通貨種別に応じてループ処理が実行される必要があり、その処理に長時間を要していた。この結果、顧客が緊急で全てのポジションを解消したい場合に、その要望に応じられず、顧客の利便性を損なうことがあった。上述した実施形態によれば、ループ処理の分割により処理時間が短縮され、顧客は短時間で全てのポジションを解消でき、顧客の利便性を向上できる。
【００６９】
変形例として、電子商取引装置１００は、業務プロセスにおけるループ処理の分割要否を決定する図示しない分割要否決定部をさらに備えてもよい。分割要否決定部は、過去の実績データに基づいてループ処理の実行時間を取得して、その分割要否を決定する。例えば、分割要否決定部は、過去の実行ログ等を参照することで、ループ処理部分の実行時間の実績を取得し、その実行時間が所定の閾値以上であるとき、ループ処理の分割が必要であると判定する。この場合、分割要否決定部は、業務プロセス情報のループ有無欄１０６を「有」に更新し、または、業務プロセス分割部４０に業務プロセスのループ処理を分割するように指示する。これにより、ループ処理の実行時間の実績に基づいて、ループ処理の分割実行を動的に決定できる。
【００７０】
別の変形例として、電子商取引装置１００は、上述した第１および第２の実施形態の特徴を備えてもよい。すなわち、親ループ処理が有限回数の繰り返し処理であり、さらに複数の命令を含むとき、業務プロセス分割部４０は、親ループ処理が含む複数の命令を分割して複数の子ループを生成する。さらに、業務プロセス分割部４０は、各業務処理装置２００のリソース使用可能量に応じて、子ループの実行回数を分割して複数の孫ループを生成してもよい。これにより、孫ループを含む業務プロセスが多数生成され、多数の業務処理装置に分散実行させることができる。１つの業務プロセスの処理に長時間を要し、多数の業務処理装置が存在する場合、各業務処理装置が備える計算リソースを有効活用して実行時間を短縮できる。
【００７１】
さらに別の変形例として、電子商取引装置１００は、上述した第２および第３の実施形態の特徴を備えてもよい。すなわち、同様の前提条件において、業務プロセス分割部４０は、親ループ処理が含む複数の命令を分割して複数の子ループを生成する。さらに、ループ処理分割部は、各業務処理装置２００のリソース使用可能量に応じて、子ループの実行回数を各業務処理装置に対応づけて生成する。これにより、業務プロセスの分散実行をさらに促進でき、１つの業務プロセスの処理に長時間を要し、多数の業務処理装置が存在する場合、各業務処理装置が備える計算リソースを有効活用して実行時間を短縮できる。
【図面の簡単な説明】
【００７２】
【図１】電子商取引システムのハードウェア構成図である。
【図２】第１の実施形態における電子商取引装置の機能構成を示すブロック図である。
【図３】業務プロセス情報のデータ構造を示す図である。
【図４】進捗情報のデータ構造を示す図である。
【図５（ａ）】分割前の業務プロセスを示す図である。
【図５（ｂ）】分割後の業務プロセスを示す図である。
【図６（ａ）】申込み情報の受け付けにおける一連の処理を示すフローチャートである。
【図６（ｂ）】業務プロセスの実行における一連の処理を示すフローチャートである。
【図７】第２の実施形態における電子商取引装置の機能構成を示すブロック図である。
【図８】分割後の業務プロセスを示す図である。
【図９】業務プロセスの実行における一連の処理を示すフローチャートである。
【図１０】ラベルにより繰り返し回数が指定される業務プロセスを示す図である。
【符号の説明】
【００７３】
１０  ユーザインタフェース処理部、１２  申込み情報受信部、２０  データ保持部、２２  業務プロセス情報保持部、２４  進捗情報保持部、３０  データ処理部、３２  進捗情報更新部、３４  業務プロセス特定部、３６  通常実行部、３８  装置状況検出部、４０  業務プロセス分割部、４２  分散実行部、４４  実行負荷予測部、１００  電子商取引装置、１０２  業務プロセス欄、１０４  実行順序欄、１０６  ループ有無欄、１０８  ソースプログラム欄、１１２  申込みＩＤ欄、１１４  実行予定業務プロセス欄、１１６  実行フラグ欄、２００  業務処理装置、３００  顧客端末、４００  通信網、１０００  電子商取引システム。
【図１】
2009193162.tif 000003
【図２】
2009193162.tif 000004
【図３】
2009193162.tif 000005
【図４】
2009193162.tif 000006
【図５（ａ）】
2009193162.tif 000007
【図５（ｂ）】
2009193162.tif 000008
【図６（ａ）】
2009193162.tif 000009
【図６（ｂ）】
2009193162.tif 000010
【図７】
2009193162.tif 000011
【図８】
2009193162.tif 000012
【図９】
2009193162.tif 000013
【図１０】
2009193162.tif 000014