(57)【要約】【課題】非同期処理を採用した場合、発生したエラーに自動的に対応できる保証がなく、動作保証が不十分であるという課題があった。【解決手段】非同期処理起動サービス２や非同期処理管理テーブル６がリレーショナルデータベースと連動し、進捗や障害を管理し、投入された非同期処理が少なくとも１回は呼び出される、非同期処理起動サービス２によって実現される第１の機能と、投入された非同期処理が二重実行されないように後続の処理を中止する第２の機能と、前記非同期処理管理テーブル６が持つ情報をもとに、障害が発生した場合の統一的管理を実現する第３の機能と、非同期処理が入れ子で呼び出された場合、障害を辿って分析できる第４の機能と、検索されたエラーとなった非同期処理に対してリトライを要求できる第５の機能を実現する。【選択図】      図１
2004157776.tif 000002
【特許請求の範囲】
【請求項１】
クライアントサービスからの処理依頼に対し、非同期処理サーバサービスにおいて非同期で実行されるアプリケーションの動作を保証するアプリケーションの処理方法であって、
同期処理のみで動作し、前記クライアントサービスから同期処理サーバサービスへ非同期処理の処理依頼を出すための投入フェーズ、非同期処理起動サービスから非同期処理依頼された非同期処理が、前記非同期処理サーバサービスにより実行される処理フェーズ、前記クライアントサービスにより前記同期処理サーバサービスを介して非同期処理の進捗や成功、失敗を含む前記非同期処理の実行について確認する確認フェーズ、前記確認フェーズで処理の終了を確認した後、情報を取り込むための取得フェーズ、前記非同期処理や異常終了後の再実行のための再実行フェーズの内から必要なフェーズを連携させ、非同期で実行されるアプリケーションの動作を保証するアプリケーションの処理方法。
【請求項２】
前記投入フェーズは、同期処理として前記クライアントサービスから前記同期処理サーバサービスへ非同期処理への依頼をかける投入ステップと、前記同期処理サーバサービスがパラメータやファイルなどの非同期処理への入力情報を登録する入力情報登録ステップと、前記同期処理サーバサービスが前記非同期処理への依頼を非同期処理管理テーブルに登録する非同期処理登録ステップと、登録処理が終了した旨のリターンを前記クライアントサービスが前記同期処理サーバサービスから受け取る登録完了通知ステップとを有し、前記処理フェーズは、前記非同期処理起動サービスから処理依頼された非同期処理が前記非同期処理起動サービスによって実行される非同期処理依頼ステップと、前記非同期処理サーバサービスが前記非同期処理管理テーブルに対して依頼内容を確認しにいく依頼検索ステップと、前記非同期処理サーバサービスが前記非同期処理管理テーブルに対し前記非同期処理を実行する場合に必要な入力情報を確認しにいく入力内容参照ステップと、業務データベースを使って参照、更新が行われる検索更新ステップと、前記非同期処理の結果を出力情報として保存する保存ステップと、前記非同期処理の進捗状況を前記非同期処理管理テーブルに保存する進捗状況更新ステップと、前記非同期処理を終了し、非同期処理終了を前記非同期処理起動サービスへ返す非同期処理終了ステップとを備えていることを特徴とする請求項１記載のアプリケーションの処理方法。
【請求項３】
非同期で実行されるアプリケーションの動作を保証する構成を提供するアプリケーションの処理システムであって、
同期、非同期のサービスを受けるクライアントサービスと、
前記クライアントサービスに対するサーバ処理を受け持つ同期処理サーバサービスと、
非同期処理を実行する非同期処理サーバサービスと、
前記非同期処理サーバサービスの非同期処理実行について、リレーショナルデータベースと連動し、進捗や障害を管理し、非同期で実行されるアプリケーションの動作を保証する保証手段と、
を備えたことを特徴とするアプリケーションの処理システム。
【請求項４】
前記保証手段は、リレーショナルデータベースと連動し、非同期処理の場合のユーザからの要求に実行をかけるための非同期処理起動サービスと非同期処理管理テーブルとを備えていることを特徴とする請求項３記載のアプリケーションの処理システム。
【請求項５】
前記保証手段は、非同期処理関係の情報と連携する、同一のデータベース管理システム下に置かれた業務データベースを備えていることを特徴とする請求項４記載のアプリケーションの処理システム。
【請求項６】
前記保証手段は、投入された非同期処理が少なくとも１回は呼び出される、非同期処理起動サービスによって実現される第１の機能と、投入された非同期処理が二重実行されないように後続の処理を中止する、非同期処理管理テーブルをもとに実現される第２の機能と、前記非同期処理管理テーブルが持つ情報をもとに、障害が発生した場合の統一的管理を実現する第３の機能と、非同期処理が入れ子で呼び出された場合、障害を辿って分析できる第４の機能と、検索されたエラーとなった非同期処理に対してリトライを要求できる第５の機能を実現することを特徴とする請求項４または５記載のアプリケーションの処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、非同期で実行されるアプリケーションの動作を保証する構成を提供するアプリケーションの処理方法およびシステムに関する。
【０００２】
【従来の技術】
非常に単純なシステムを開発する場合、そのシステムの利用者が自分の実行した処理の正常終了を常に確認することにすれば、同期処理のみでシステムを構築することができる。このような単純なシステムでは人間系によってエラーを回避して、システムの信頼性を保証することになる。
なお、このようなシステムの信頼性を向上させるためのトランザクションの二重実行を回避するものとして、トランザクションの完了通知が紛失している場合でも、他ホストにてリカバリされた記録の有無をチェックし、トランザクションの二重実行を防止し中断トランザクションの起動の契機を得てシステムの信頼性を向上させるものが提案されている（例えば、特許文献１参照）。
【０００３】
【特許文献１】
特開平１１−２１２９１７号公報
【０００４】
【発明が解決しようとする課題】
ところが、オペレータが伝票入力を行い、システムが構成チェックを行った後、伝票をプリンタで打ち出すような場合、オペレータに連続して入力作業をしてもらった方が効率が良く、そのためには構成チェックやプリンタでの印刷はオペレータの入力処理とは非同期に並列で行う必要があるなど、複雑な処理を単位時間になるべく多く実行させようとするシステムを構築する場合、処理を並列で実行させる必要があるが、非同期処理を採用した場合、非同期に行われた処理は知らない間にエラーすることがある。このため、非同期処理には知らない間に発生した様々なエラーにも自動的に対応できるような高い保証レベルが要求されるが、Ｊａｖａ（登録商標、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ社が開発した言語）には非同期処理を行うためにはＭＤＢ（Ｍｅｓｓａｇｅ−ｄｒｉｖｅｎ  Ｂｅａｎ）を使うことができるがそのままでは動作保証が不十分であるという課題があった。
【０００５】
具体的には従来の技術には、次のような問題点がある。
第１の問題点は、非同期処理をデータベースの更新と連携させたいと思っても、データベース更新に関するコミット、ロールバックと非同期処理の要求、実行に関するコミット、ロールバックを同一管理できなかったということである。その理由は、非同期処理起動サービス（待ち行列）がデータベース管理システムと連動していなかったり、非同期処理管理テーブルを持っていなかったためである。また、もしそれらのサービスを持っていたとしても非同期処理起動サービス（待ち行列）と非同期処理管理テーブルを一般のテーブルと同じデータベース管理システムの配下で管理していなかったためである。
【０００６】
第２の問題点は、非同期処理が要求された後で、非同期に実行されている部分が異常終了しても自動的には処理を再実行させることが出来ないということである。その理由は、非同期処理起動サービス（待ち行列）がデータベースと連携していないので障害があった非同期処理を再実行して良いのか悪いのかシステムとして判断出来ないためである。
第３の問題点は、再実行を要求したが、実は先行処理が正常に終了していた場合、同様の非同期処理を２回実行してしまうことになるということである。
その理由は、非同期処理管理テーブルを用意していないので実行の進捗を管理出来ないためである。
【０００７】
第４の問題点は、主に障害時における以下のような情報を統一的に管理できないことにある。
（１）障害が発生した場合、どの処理がいつどんな状態でエラーになったか統一的に管理できておらず、エラーとなった非同期処理を検索することが困難である。
（２）親→子→孫のように非同期処理が入れ子で呼び出された場合、障害を追いかけて分析することができない。
（３）エラーとなった非同期処理を発見できてもその非同期処理に対して容易にリトライを要求できない。その理由は、本発明で提示しているような非同期処理管理テーブルがそもそも用意されていなかったり、あったとしても上記リトライを要求するのに充分な情報を管理するようになっていないためである。
【０００８】
そこで本発明は、データベース更新に関するコミット、ロールバックと、非同期処理の要求、実行に関するコミット、ロールバックを同一管理できるアプリケーションの処理方法およびシステムを提供することを目的とする。
【０００９】
また、本発明は、非同期にアプリケーションを実行できるアプリケーションの処理方法およびシステムを提供することを目的とする。
【００１０】
また、本発明は、誤って複数回非同期処理を実行してしまった場合には後続の処理が複数実行であることを検出でき、二重実行となってしまう場合には処理を取りやめることができるアプリケーションの処理方法およびシステムを提供することを目的とする。
【００１１】
また、本発明は、実行情報、障害情報や、非同期処理の親子の関係を一元管理し、それらの情報から障害が起こった場合でもリトライが容易に行えるアプリケーションの処理方法およびシステムを提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明に係るアプリケーションの処理方法は、クライアントサービスからの処理依頼に対し、非同期処理サーバサービスにおいて非同期で実行されるアプリケーションの動作を保証するアプリケーションの処理方法であって、同期処理のみで動作し、前記クライアントサービスから同期処理サーバサービスへ非同期処理の処理依頼を出すための投入フェーズ、非同期処理起動サービスから非同期処理依頼された非同期処理が、前記非同期処理サーバサービスにより実行される処理フェーズ、前記クライアントサービスにより前記同期処理サーバサービスを介して非同期処理の進捗や成功、失敗を含む前記非同期処理の実行について確認する確認フェーズ、前記確認フェーズで処理の終了を確認した後、情報を取り込むための取得フェーズ、前記非同期処理や異常終了後の再実行のための再実行フェーズの内から必要なフェーズを連携させ、非同期で実行されるアプリケーションの動作を保証することを特徴とする。
【００１３】
本発明のアプリケーションの処理方法は、投入フェーズ、処理フェーズ、確認フェーズ、取得フェーズ、再実行フェーズの内から必要なフェーズを連携させ、データベース更新に関するコミット、ロールバックと、非同期処理の要求、実行に関するコミット、ロールバックを同一管理可能にすることで、非同期処理の二重実行の防止、障害が起こった場合の再実行を可能にし、非同期にアプリケーションを実行し、前記非同期で実行されるアプリケーションの動作を保証する。
【００１４】
本発明に係るアプリケーションの処理システムは、同期、非同期のサービスを受けるクライアントサービスと、前記クライアントサービスに対するサーバ処理を受け持つ同期処理サーバサービスと、非同期処理を実行する非同期処理サーバサービスと、前記非同期処理サーバサービスの非同期処理実行について、リレーショナルデータベースと連動し、進捗や障害を管理し、非同期で実行されるアプリケーションの動作を保証する保証手段とを備えたことを特徴とする。
【００１５】
本発明のアプリケーションの処理システムは、非同期処理サーバサービスの非同期処理実行について、リレーショナルデータベースと連動し、進捗や障害を管理し、データベース更新に関するコミット、ロールバックと、非同期処理の要求、実行に関するコミット、ロールバックを同一管理し、非同期処理の二重実行の防止、障害が起こった場合の再実行を可能にし、非同期にアプリケーションを実行し、前記非同期で実行されるアプリケーションの動作を保証する。
【００１６】
【発明の実施の形態】
以下、本発明の実施の一形態について説明する。
図１は、この実施の形態のアプリケーションの処理システムを示すブロック図である。図２は、この実施の形態のアプリケーションの処理システムにおける非同期処理動作を示すシーケンス図である。この実施の形態のアプリケーションの処理方法が適用されるシステムは、図１に示す各サービスから構成され、図２のシーケンスに従って実行される。
このアプリケーションの処理システムでは、図１および図２に符号２で示す非同期処理起動サービス（待ち行列）や符号６で示す非同期処理管理テーブルがリレーショナルデータベースと連動し、進捗や障害を管理することに特徴がある。
そして、非同期処理を正確に１回だけ実行させるために以下の２つの機能を提供する。第１の機能は、投入された非同期処理はたとえ障害が発生したとしても少なくとも１回は呼び出される。この第１の機能は主に図１および図２の符号２で示す非同期処理起動サービス（待ち行列）によって実現される。また、第２の機能は、投入された非同期処理が、万一複数回実行された場合は既に実行済みであることを検知して二重実行されないように後続の処理を中止する。この第２の機能は主に図１および図２の符号６で示す非同期処理管理テーブルによって実現される。これら第１の機能と第２の機能を合わせることでハードウエア障害など一般には復旧が出来ないと思われるような状況においても投入された非同期処理を確実に１回実行することを可能とする。
また、図１および図２の符号６で示す非同期処理管理テーブルに持つ情報により、障害が発生した場合、どの処理がいつどんな状態でエラーになったか統一的に管理できる第３の機能を実現し、また、親→子→孫のように非同期処理が入れ子で呼び出された場合でも障害を追いかけて分析できる第４の機能を実現し、また、エラーとなった非同期処理を検索することが可能である。さらに検索されたエラーとなった非同期処理に対してリトライを要求できる第５の機能を実現する。
このようにして、非同期で実行されるアプリケーションの動作を高度に保証することを可能にする。
【００１７】
なお、この実施の形態において同期処理とは図１４の左のシーケンスで示されるように呼び出しを行なった側が呼び出された側の処理のリターンを待って処理を継続していく処理方式を指すものとする。そして、この同期処理では、ユーザへのレスポンスが悪いため業務に支障をきたすというデメリットがある反面、トランザクションなどの終了結果を利用者が確認できるというメリットを有している。
また、非同期処理とは図１４の右のシーケンスで示されるように呼び出しを行った側が呼び出された側の処理を待つことなく、呼び出しを行なった側と呼び出された側が同時に並行して動作する処理方式を指すものとする。そして、この非同期処理では、プリンタの印刷状況を後で確認したり、後続の処理で今までの作業の一覧を確認する画面を呼び出す（部品では進捗管理テーブルを用意しているため容易に確認できる）など、非同期で処理される部分の実行結果を後で確認する必要があるなどのデメリットがある反面、処理が素早く返ってくるため単位時間あたり多くの入力を行うことができるメリットがある。
【００１８】
先ず、この実施の形態のアプリケーションの処理システムを構成する図１に示す各サービスについて説明する。
クライアントサービス（例：ブラウザ）１は、同期、非同期のサービスを受けるクライアントを指す。例としてはエンドユーザが操作するブラウザやクライアントアプリケーションが挙げられる。主にオンライン系として利用されることを想定しているが、場合によってはバッチ系の処理がクライアントサービスとなって同期処理や非同期処理を利用する場合もある。
【００１９】
非同期処理起動サービス（例：ＪａｖａのＪＭＳキュー、Ｊｏｂ管理サービス、ＵＮＩＸ（登録商標、ＡＴ＆Ｔ社が開発したタイム・シュアリング・システム用ＯＳ）のクーロン、Ｗｉｎｄｏｗｓ（登録商標、Ｍｉｃｒｏｓｏｆｔ社が開発したＯＳ）のａｔコマンド）２は、同期処理はユーザからの要求で実際に処理が実行されるが、非同期処理の場合はユーザからは要求のみが登録され、その要求に実行をかけるために別のサービスが必要となる。この別のサービスに対応するのが非同期処理起動サービスである。非同期処理起動サービスはこの機能を実現する。例えばＪａｖａのＪＭＳ  （Ｊａｖａ  Ｍｅｓｓａｇｉｎｇ  Ｓｅｒｖｉｃｅ）や市販のＪｏｂ管理ツール、ＵＮＩＸのクーロン、Ｗｉｎｄｏｗｓのａｔコマンドなどがこの非同期処理起動サービスとなり得る。
【００２０】
同期処理サーバサービス（例：Ｗｅｂアプリケーションサーバ）３は、クライアントサービスに対するサーバ処理を受け持つサービスである。これらの間の処理は同期処理となる。クライアントサービスから非同期処理を投入する場合は先ずこの同期処理サーバサービスにアクセスして、同期処理サーバサービス経由で非同期処理を要求することになる。例えばＷｅｂアプリケーションサーバやＴＰモニタ（トランザクションモニタ）やＭｉｃｒｏｓｏｆｔのＣＯＭ＋、ＣＯＲＢＡ  （Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉ  ｔｅｃｔｕｒｅ）やＲＭＩ（Ｒｅｍｏｔｅ  Ｍｅｔｈｏｄ  Ｉｎｖｏｃａｔｉｏｎ）に代表されるＯＲＢ（Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ）などがこれにあたる。
【００２１】
非同期処理サーバサービス（例：ＪａｖａのＭｅｓｓａｇｅ−ｄｒｉｖｅｎ  Ｂｅａｎ、シェルやコマンドなどのバッチ処理）４は、実際に非同期処理を実行するサービスを指す。例えばＪａｖａのＭＤＢ（Ｍｅｓｓａｇｅ−ｄｒｉｖｅｎＢｅａｎ）  やシェルやコマンドなどのバッチ処理を行うサービスがこれにあたる
。
【００２２】
入力情報（ＩＮ）５は、テーブル（データ）、実ファイル（テキスト、ＣＳＶ、バイナリファイルなど）非同期処理への入力情報である。簡単なパラメータは非同期処理管理テーブルで管理できるがデータベースのテーブルに格納する巨大なデータを利用する場合やテキストファイル、ＣＳＶ（Ｃｏｍｍａ  Ｓｅｐａｒａｔｅｄ  Ｖａｌｕｅｓ）ファイル、バイナリファイルを扱う場合は非同期処理管理テーブルの外で管理することになる。ただし、この実施の形態では全ての情報はデータベースで管理することとするので各種のファイルとして持っている情報もデータベースに格納して管理することになる。
【００２３】
非同期処理管理テーブルの拡張としてこれら入力情報５のデータをデータベースで管理する場合の例を図１２に示す。
非同期処理管理テーブル６は、この実施の形態の中核をなす情報を管理するテーブルである。ＭＤＢ（Ｍｅｓｓａｇｅ−ｄｒｉｖｅｎ  Ｂｅａｎ）で部品化した場合のサンプルを図３、図４、図５、図６、図７、図８、図９、図１０、図１１に示す。このサンプルでは複数のテーブルで詳細な情報を管理するように作られているので図３から図１１までで規定している。
【００２４】
出力情報（ＯＵＴ）７はプル型とプッシュ型とに分かれ、プル型としてテーブル（データ）、実ファイル（テキスト、ＣＳＶ、バイナリファイルなど）を想定し、プッシュ型としては、プリンタ、メール、ログ、障害通知、他システム連携などを想定している。そして、この出力情報（ＯＵＴ）７は、非同期処理からの出力情報である。簡単なパラメータやエラーコード、エラーメッセージは非同期処理管理テーブルで管理されているがそれでは不足する場合に必要となる。上述したように大きくプル型とプッシュ型に分かれる。
プル型はテーブルに格納されている情報やテキスト、ＣＳＶ、バイナリなどのファイルがデータベースに格納されているものをユーザからのアクションで取ってもらう場合を想定している。
これに対してプッシュ型はシステム側から自動的にユーザまで届けられる場合で、プリンタへの出力やメールへの転送、ログや障害通知、それに他システムへの連携などが挙げられる。非同期処理管理テーブルの拡張としてこれらのデータをデータベースで管理する場合の例を図１２に示す。
【００２５】
業務データベース８については、この実施の形態では業務データベースと非同期処理関係の情報が連携する必要があるので、同一のデータベース管理システム下に置くものとする。
【００２６】
次に非同期処理フェーズについて説明する。
図２は各フェーズの処理内容を示すシーケンス図であり、図２に示すように、投入フェーズ、処理フェーズ、確認フェーズ、取得フェーズ（プル型）、再実行フェーズ（プッシュ型）に分類でき、これらフェーズが連携して、非同期で実行されるアプリケーションの動作を高度に保証する。
投入フェーズは、ユーザが非同期処理の処理依頼を出すためのフェーズを指す。図２のシーケンスを見るとこの投入フェーズは同期処理のみで動作することが分かる。一般に非同期処理への投入は非常に軽い処理であり、ユーザは投入が終わると次の処理フェーズの実行の如何に関わらず別の非同期処理の投入を行うことが出来る。
【００２７】
処理フェーズは、非同期処理サーバサービス４により実際に非同期処理の内容が実行される部分である。この処理フェーズのみが非同期処理起動サービス４から実行される。主に処理時間の長いチェック系の業務や印刷業務で使用される。
【００２８】
確認フェーズは、ユーザが非同期処理の進捗や成功、失敗の別を確認するフェーズである。処理が実行中の場合（未完了の場合）はこの確認フェーズを繰り返し実行する必要がある。
【００２９】
取得フェーズ（プル型）は、プル型の情報を持つ非同期処理の場合、ユーザは確認フェーズで処理の終了を確認した後、取得フェーズによって情報を取り込む必要がある。
【００３０】
再実行フェーズ（プッシュ型）は、プッシュ型の情報を持つ非同期処理や、プル型でも異常終了して再実行を要求したい場合、この再実行フェーズを行うことになる。
【００３１】
次に、図２に示すシーケンス図を参照し、この実施の形態の全体の動作について詳細に説明する。
先ず、「各非同期処理フェーズに関する説明」で個々のフェーズでの詳細を説明し、その後に「非同期処理フェーズの連携に関する説明」で前に説明した個々のフェーズがどのように連携するかを説明する。
「各非同期処理フェーズに関する説明」
以下、前記分類した処理フェーズごとに区切って説明する。
「投入フェーズ」
ステップＳ１１（投入）では、一般の同期処理としてクライアントサービス１から同期処理サーバサービス３へ「非同期処理への依頼」をかける。ステップＳ１２（パラメータ、ファイル）では、同期処理サーバサービス３がパラメータやファイルなどの非同期処理への入力情報を登録する。ステップＳ１３（非同期処理の依頼を登録）では、同期処理サーバサービス３が前記「非同期処理への依頼」を非同期処理管理テーブル６に登録する。ステップＳ１４（登録完了を通知）では、ユーザ（クライアントサービス１）は登録処理が終了した旨のリターンを同期処理サーバサービス３から受け取る。注意が必要なのはこの時点では非同期処理の登録のみが正常に終了したことしか分からないことである。非同期処理自体が正常に終了したかどうかは後述する「確認フェーズ」でチェックする必要がある。
【００３２】
「処理フェーズ」
ステップＳ２１（非同期処理依頼）では、「非同期処理起動サービス２」によって非同期処理が実行される。ステップＳ２２（依頼を検索）では、非同期処理サーバサービス４が「非同期処理管理テーブル６」に対して依頼内容を確認しにいく。またステップＳ２３（入力内容を参照）では、非同期処理を実行する場合に必要な入力情報を非同期処理サーバサービス４が非同期処理管理テーブル６に対し確認しにいく。ステップＳ２４（検索処理、更新処理）では、「業務データベース８」を使って当該処理参照、更新が行われる。ステップＳ２５（出力結果を保存）では、非同期処理の結果を出力情報７として保存する。ステップＳ２６（依頼の進捗状況を更新）では、非同期処理が完了したので進捗状況を「非同期処理管理テーブル６」に保存する。ステップＳ２７（非同期処理終了をリターン）では、非同期処理を終了し、非同期処理終了を非同期処理起動サービス２へ返す。
【００３３】
「確認フェーズ」
ステップＳ３１（確認画面を要求）では、ユーザが非同期処理の確認を要求する。ステップＳ３２（進捗状況を確認）では、「非同期処理管理テーブル６」に進捗状況を確認する。ステップＳ３３（進捗、結果を一覧表示）では、進捗状況をリターンする。実行中、正常終了、エラーなどがリターンされる。
【００３４】
「取得フェーズ（プル型）」
ステップＳ４１（一覧表示画面から１件選択）では、「確認フェーズ」で取得した情報から必要な情報の取得を要求する。ステップＳ４２（当該処理の結果取得）では、「出力情報７」から非同期処理の結果を取得する。ステップＳ４３（当該処理の結果で使用するデータを取得）では、「出力情報７」以外に必要とする情報があれば「業務データベース８」から取得する。ステップＳ４４（結果の返却）では、結果をユーザ（クライアントサービス１）に返却する。
【００３５】
「再実行フェーズ（プッシュ型）」
ステップＳ５１（一覧表示画面から１件選択）では、「確認フェーズ」で取得した情報から再実行の必要な情報を選択する。ステップＳ５２（非同期処理管理テーブルのステータスを再実行に変更）では、「非同期処理管理テーブル６」のステータスを再実行に変更する。ステップＳ５３（再実行を通知）では、再実行を要求した旨をユーザ（クライアントサービス１）に返却する。
これらの非同期処理フェーズごとの処理が以下の「非同期処理フェーズの連携に関する説明」のように連携して非同期処理が実行される。
【００３６】
「非同期処理フェーズの連携に関する説明」
以下、前記実施の形態の構成において説明した各機能と前記「各非同期処理フェーズに関する説明」で説明したそれぞれの非同期処理フェーズがどのように連携して非同期処理全体を構成するかをパターンに分けて説明する。
【００３７】
図２の出力情報（ＯＵＴ）７で説明したプル型の場合、各フェーズは例えば以下のように連携する。
例えば長時間を要する処理を非同期で投入した場合には、「投入フェーズ」→「処理フェーズ」→「確認フェーズ」→「取得フェーズ」。
【００３８】
図２の「出力情報（ＯＵＴ）７」で説明したプッシュ型の場合、各フェーズは例えば以下のように連携する。
例えば印刷や自分宛てのメールなど別途確認が可能な処理を要求した場合には、「投入フェーズ」→「処理フェーズ」。
または、他人宛てのメールや他システムへの連携処理など確認が必要な場合には、「投入フェーズ」→「処理フェーズ」→「確認フェーズ」。
または、例えば非同期処理の失敗を確認し、リトライをかけた場合や、印刷などで紙詰まりが発生し、再印刷をかけた場合には、「投入フェーズ」→「処理フェーズ」→「確認フェーズ」→「再実行フェーズ」。
【００３９】
次に、オンライン処理から非同期処理を呼び出す場合とバッチ処理から非同期処理を呼び出す場合について説明する。
以上、説明してきた非同期処理の動作はオンライン系の処理とバッチ系の処理のどちらからでも呼び出すことができる。図１３は、非同期処理の動作について実際にオンラインからの呼び出しとバッチからの呼び出しを想定した場合の構成例を示す説明図である。図１３の例ではＭＤＢ（Ｍｅｓｓａｇｅ−ｄｒｉｖｅｎＢｅａｎ）で非同期処理を実装しているが以下の３種類の呼び出しを例として備えている。
【００４０】
「（Ａ）ローカルの非同期処理を呼び出す」
図１のクライアントサービス１と同期処理サーバサービス３がオンライン系の処理を構成している場合でかつ、図１の同期処理サーバサービス３と非同期処理サーバサービス４が同一の環境に実装されている場合。
【００４１】
「（Ｂ）リモートの非同期処理を呼び出す」
図１のクライアントサービス１と同期処理サーバサービス３がオンライン系の処理を構成している場合でかつ、図１の同期処理サーバサービス３と非同期処理サーバサービス４が異なる環境に実装されている場合。
【００４２】
「（Ｃ）バッチ処理から非同期処理を呼び出す」
図１のクライアントサービス１と同期処理サーバサービス３がオンライン系の処理を構成している場合。図１３ではバッチ処理から非同期処理を呼び出す場合はリモート呼出のみ記述されているが環境の作り方如何によってはローカル呼び出しも可能である。
【００４３】
以上のように、この実施の形態によれば、第１の効果は、一般のテーブルと非同期処理起動サービス（待ち行列）２や非同期処理管理テーブル６などを共通のデータベース管理システムの配下に設置したため、本発明を利用した部品を利用する業務アプリケーションのトランザクションと本発明を利用した非同期処理のトランザクションを同一のトランザクションとしてコミット、ロールバックのタイミングを共通管理できることである。
【００４４】
また、第２の効果は、非同期処理起動サービス（待ち行列）２をデータベースに書き込むことによってハードウエア障害を含むシステム上の障害が発生した後でも障害復旧後に自動的に未処理状態にある非同期処理を再実行でき、再実行する回数は非同期処理管理テーブル６のリトライ回数として指定することができ、少なくとも１回は非同期にアプリケーションを実行できる。
【００４５】
また、第３の効果は、非同期処理管理テーブル６で進捗管理をしており、非同期処理管理テーブル６のステータスをチェックすることで当該処理が正当な実行状態にあるのか異常な事項状態にあるのか確認できるため、間違って複数回非同期処理を実行してしまった場合には後続の処理が複数実行であることを検出でき、二重実行となってしまう場合には処理を取りやめることができる。
（※第２の効果と第３の効果を合わせてハードウエア障害など一般には復旧不能と思われるような状況に陥っても「少なくとも１回（第２の効果）」かつ「ただ１回だけ（第３の効果）」非同期処理を実行することを可能とする）
【００４６】
また、第４の効果は、非同期処理管理テーブルで実行ユーザＩＤ、開始時刻、終了時刻、ステータス、エラーコード、エラーメッセージなどの情報を管理できており、図１５で示すように前の非同期処理を特定するＩＤを保持しているのでそれを辿って非同期処理全体のツリーを復元でき、さらに非同期処理管理テーブル６とそれに付随するテーブルを使えばリトライに必要な全ての情報を取り出すことができるように設計されているため、実行情報、障害情報や、非同期処理の親子の関係を一元管理し、図１６に示すように非同期処理に障害が発生した場合でもリトライが容易に行える。
【００４７】
次に、本発明の他の実施の形態について説明する。
以上の説明では、Ｊａｖａでの実装を想定し、Ｊａｖａのイメージで記述を行なっているが、Ｊａｖａに限定せず一般のサービスとしても利用可能である。
【００４８】
図１の非同期処理起動サービス２と非同期処理サーバサービス４を複数のサーバに分散させて負荷分散または障害時の振分け構成（フェイルオーバー）をとることも可能である。例えば、図３から図１１に示す非同期処理管理テーブル（Ｍｅｓｓａｇｅ−ｄｒｉｖｅｎ  Ｂｅａｎの場合）はこの複数サーバ構成に対応するように作られている。
【００４９】
図１のクライアントサービス１としてブラウザや一般のアプリケーションを想定してシステムを組むことが可能である。
【００５０】
図１の非同期処理起動サービス２としてＪａｖａのＪＭＳキュー（Ｊａｖａ  Ｍｅｓｓａｇｉｎｇ  Ｓｅｒｖｉｃｅ  Ｑｕｅｕｅ）、一般製品として発売されているＪｏｂ管理サービス、ＵＮＩＸのクーロン、ＷｉｎｄｏｗｓＮＴやＷｉｎｄｏｗｓ２０００のａｔコマンドなどを採用することが可能である。ただし、これらの待ち行列をデータベースと連携させるように構築することが必要となる。（ほかにやり方がない場合は一定間隔でデータベースを見に行くように作る必要がある）
【００５１】
図１の同期処理サーバサービス３としてＷｅｂアプリケーションサーバやＴＰモニター（トランザクションモニター）などを採用することが可能である。また分散オブジェクトを使う場合はＥＪＢコンテナ（Ｅｎｔｅｒｐｒｉｓｅ  Ｊａｖａ  Ｂｅａｎｓ  コンテナ）やＣＯＲＢＡオブジェクトやＭＩＣＲＯＳＯＦＴのＣＯＭ＋などを使うことも可能である。
【００５２】
図１の非同期処理サーバサービス４としてＪａｖａのＭｅｓｓａｇｅ−ｄｒｉｖｅｎ  Ｂｅａｎ、ＵＮＩＸのシェルやコマンド、Ｗｉｎｄｏｗｓのバッチファイルなどを用いることができる。
【００５３】
図１の入力情報（ＩＮ）５としては図５の業務パラメータのように図１の非同期処理管理テーブル６で直接管理するほか業務データベース８のテーブル（データ）として管理したり、実ファイル（テキスト、ＣＳＶ、バイナリファイルなど）として管理する方法もある。図１の非同期処理管理テーブル６に図５の業務パラメータのような構造をもたせておくと、図１２の非同期処理管理テーブルの拡張で示すようにテーブルの拡張が可能となる。（拡張するテーブルの一意キーを図６の業務パラメータに設定することでテーブル拡張する）また、テーブルを拡張する場合、もとの図１の非同期処理管理テーブル６に対応するクラスを作って運用している場合、当該クラスを継承して拡張クラスを拡張テーブルに割り付けるように設計することも可能となる。
【００５４】
図１の非同期処理管理テーブル６は一般に業務データベース８のテーブルとして定義される。ただし、２フェーズコミットの機能など拡張トランザクションを考えられる場合はこの限りではない。図３から図１１にＭｅｓｓａｇｅ−ｄｒｉｖｅｎ  Ｂｅａｎを使った場合の非同期処理管理テーブルの例を示す。また非同期処理管理テーブルを拡張する場合は図１２のイメージで拡張する。
【００５５】
図１の出力情報（ＯＵＴ）７としてはクライアント側から情報を取りに行く必要のあるプル型とサーバから情報が送りつけられるプッシュ型がある。以下ではそれぞれに分けて説明する。
【００５６】
プル型としては図１の  入力情報（ＩＮ）５で説明したのと同様にテーブル（データ）、実ファイル（テキスト、ＣＳＶ、バイナリファイルなど）が考えられる。プッシュ型としてはプリンタ、メール、ログ、障害通知、他システム連携などが考えられる。
その他テーブルの拡張などは図１の入力情報（ＩＮ）５で説明したのと同様の方法で行うことができる。
【００５７】
図１の業務データベース８は一般にトランザクション管理可能なリレーショナルデータベースで管理するが、データベースはリレーショナルデータベースに限定するわけではなく、コダシル型やオブジェクト指向データベースなどを使うことも可能である。また、トランザクションの概念を追加できるならば一般のファイルなどで管理することも可能である。ただし、トランザクションの概念が本発明では必要となるのでトランザクションの概念を利用できないものは採用できない。
【００５８】
【発明の効果】
本発明によれば、投入フェーズ、処理フェーズ、確認フェーズ、取得フェーズ、再実行フェーズの内から必要なフェーズを連携させ、データベース更新に関するコミット、ロールバックと、非同期処理の要求、実行に関するコミット、ロールバックを同一管理し、非同期処理の二重実行の防止、障害が起こった場合の再実行を可能にして、非同期にアプリケーションを実行でき、前記非同期で実行されるアプリケーションの動作を保証できる効果がある。
【００５９】
本発明によれば、同期、非同期のサービスを受けるクライアントサービスと、前記クライアントサービスに対するサーバ処理を受け持つ同期処理サーバサービスと、非同期処理を実行する非同期処理サーバサービスと、前記非同期処理サーバサービスの非同期処理実行について、リレーショナルデータベースと連動し、進捗や障害を管理し、非同期で実行されるアプリケーションの動作を保証する保証手段とを備えたので、非同期処理サーバサービスの非同期処理実行について、リレーショナルデータベースと連動し、進捗や障害を管理し、データベース更新に関するコミット、ロールバックと、非同期処理の要求、実行に関するコミット、ロールバックが同一管理でき、非同期処理の二重実行の防止、障害が起こった場合の再実行が可能になり、非同期にアプリケーションを実行し、前記非同期で実行されるアプリケーションの動作を保証できる効果がある。
【図面の簡単な説明】
【図１】本発明の実施の一形態のアプリケーションの処理システムを示すブロック図である。
【図２】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理動作を示すシーケンス図である。
【図３】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理管理テーブルの一例を示す説明図である。
【図４】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理管理テーブルの一例を示す説明図である。
【図５】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理管理テーブルの一例を示す説明図である。
【図６】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理管理テーブルの一例を示す説明図である。
【図７】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理管理テーブルの一例を示す説明図である。
【図８】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理管理テーブルの一例を示す説明図である。
【図９】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理管理テーブルの一例を示す説明図である。
【図１０】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理管理テーブルの一例を示す説明図である。
【図１１】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理管理テーブルの一例を示す説明図である。
【図１２】本発明の実施の一形態のアプリケーションの処理システムにおいて非同期処理管理テーブルの拡張として入力情報のデータをデータベースで管理する場合の一例を示す説明図である。
【図１３】本発明の実施の一形態のアプリケーションの処理システムの非同期処理の動作についてオンラインからの呼び出しとバッチからの呼び出しを想定した場合の構成例を示す説明図である。
【図１４】本発明の実施の一形態のアプリケーションの処理システムにおける非同期処理と同期処理の比較を示すシーケンス図である。
【図１５】本発明の実施の一形態のアプリケーションの処理システムにおける実行ユーザＩＤ、ステータス、エラーコード、前の非同期処理を特定するＩＤなどの情報を管理可能な非同期処理管理テーブルを示す説明図である。
【図１６】本発明の実施の一形態のアプリケーションの処理システムにおいて、復元した非同期処理全体のツリーをもとに非同期処理に障害が発生した場合でもリトライが容易に行えることを示す説明図である。
【符号の説明】
１……クライアントサービス、２……非同期処理起動サービス（保証手段）、３……同期処理サーバサービス、４……非同期処理サーバサービス、６……非同期処理管理テーブル（保証手段）、８……業務データベース（保証手段）。
【図１】
2004157776.tif 000003
【図２】
2004157776.tif 000004
【図３】
2004157776.tif 000005
【図４】
2004157776.tif 000006
【図５】
2004157776.tif 000007
【図６】
2004157776.tif 000008
【図７】
2004157776.tif 000009
【図８】
2004157776.tif 000010
【図９】
2004157776.tif 000011
【図１０】
2004157776.tif 000012
【図１１】
2004157776.tif 000013
【図１２】
2004157776.tif 000014
【図１３】
2004157776.tif 000015
【図１４】
2004157776.tif 000016
【図１５】
2004157776.tif 000017
【図１６】
2004157776.tif 000018