(57)【要約】【課題】  ソフトウェア環境においてデータの保全性を維持するための装置及び方法を提供する。【解決手段】  本装置及び方法によれば、トランザクションに関連した個々のソフトウェア・リソースが識別され、これらのリソースの処理が開始される。これらのリソースの処理が終了すると、それらの関連ＡＰＩは、そのソフトウェア・リソースがコミットしたこと又はコミットし得なかったことを表すメッセージ及びソフトウェア・リソースがコミットし得なかった理由を返送する。この理由に基づいて、適正なエラー解決及び回復オペレーションが遂行され、コミットし得なかったソフトウェア・リソースに対してのみトランザクションが再処理依頼される。既にコミットしたソフトウェア・リソースはそれらの状態を維持される。この方法で、コミットしたソフトウェア・リソースのロールバックが回避される。【選択図】  図４
2005004754.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェア環境においてトランザクションを処理する方法であって、
前記トランザクションに参加する個々のリソースに対して前記トランザクションを処理依頼するステップと、
前記リソースがコミットし得たか又はコミットし得なかったかを表す応答を前記個々のリソースから受け取るステップと、
前記リソースがコミットし得なかったことを表す応答が前記リソースから受け取られた場合、前記コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼するステップと
を含む、方法。
【請求項２】
前記個々のリソースからの応答は、前記個々のリソースと関連したアプリケーション・プログラム・インターフェースから受け取られた１つ又はそれ以上の応答メッセージである、請求項１に記載の方法。
【請求項３】
前記リソースがコミットし得なかったことを個々のリソースからの前記応答が表す場合、前記応答は、更に、前記リソースがコミットし得なかった理由に関する識別子を含む、請求項１に記載の方法。
【請求項４】
前記リソースにおいて遂行すべき適正なエラー解決及び回復オペレーションを決定するために前記リソースからの応答に対して１つ又はそれ以上のルールを適用するステップと、
前記リソースに対して前記トランザクションを再処理依頼する前に前記リソースにおいて前記エラー解決及び回復オペレーションを遂行するステップと
を更に含む、請求項３に記載の方法。
【請求項５】
前記トランザクションに対するトランザクション状態データ構造を生成するステップと、
前記トランザクションに参加する各リソースに関する情報でもって前記トランザクション状態データ構造を占めさせるステップと
を更に含む、請求項１に記載の方法。
【請求項６】
前記個々のリソースから応答を受け取ったことに応答して前記トランザクション状態データ構造を更新するステップを更に含む、請求項５に記載の方法。
【請求項７】
トランザクション・マネージャが存在しないソフトウェア環境において前記方法が実施される、請求項１に記載の方法。
【請求項８】
前記リソースがコミットし得なかったことを前記リソースからの応答が表す場合、前記リソースに対する前記トランザクションの一部に関する再処理依頼の数が所定の閾値を越えるかどうかを決定するステップと、
前記再処理依頼の数が前記所定の閾値よりも小さいか又は前記所定の閾値に等しい場合にのみ、前記リソースに対して前記トランザクションの一部を再処理依頼するステップと
を更に含む、請求項１に記載の方法。
【請求項９】
前記再処理依頼の数が前記所定の閾値よりも大きい場合、エラー・ハンドラに制御を移すステップを更に含む、請求項８に記載の方法。
【請求項１０】
前記エラー・ハンドラは、前記トランザクションの一部としてコミットしたリソースによって行われた変更をロールバックする、請求項９に記載の方法。
【請求項１１】
ソフトウェア環境においてトランザクション処理をコンピュータに行わせるためのコンピュータ・プログラムであって、
前記トランザクションに参加する個々のリソースに対して前記トランザクションを再処理依頼するための第１命令と、
前記リソースがコミットし得たか又はコミットし得なかったかを表す応答を前記個々のリソースから受け取るための第２命令と、
前記リソースがコミットし得なかったことを表す応答が前記リソースから受け取られた場合、コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼するための第３命令と
を含む、コンピュータ・プログラム。
【請求項１２】
前記個々のリソースからの応答は、前記個々のリソースと関連したアプリケーション・プログラム・インターフェースから受け取られた１つ又はそれ以上の応答メッセージである、請求項１１に記載のコンピュータ・プログラム。
【請求項１３】
前記リソースがコミットし得なかったことを個々のリソースからの前記応答が表す場合、前記応答は、更に、前記リソースがコミットし得なかった理由に関する識別子を含む、請求項１１に記載のコンピュータ・プログラム。
【請求項１４】
前記リソースにおいて遂行すべき適正なエラー解決及び回復オペレーションを決定するために前記リソースからの応答に対して１つ又はそれ以上のルールを適用するための第４命令と、
前記リソースに対して前記トランザクションを再処理依頼する前に前記リソースにおいて前記エラー解決及び回復オペレーションを遂行するための第５命令と
を更に含む、請求項１３に記載のコンピュータ・プログラム。
【請求項１５】
前記トランザクションに対するトランザクション状態データ構造を生成するための第６命令と、
前記トランザクションに参加する各リソースに関する情報でもって前記トランザクション状態データ構造を占めさせるための第７命令と
を更に含む、請求項１１に記載のコンピュータ・プログラム。
【請求項１６】
前記個々のリソースから応答を受け取ったことに応答して前記トランザクション状態データ構造を更新するための第８命令を更に含む、請求項１５に記載のコンピュータ・プログラム。
【請求項１７】
トランザクション・マネージャが存在しないソフトウェア環境において前記コンピュータ・プログラム製品が実行される、請求項１１に記載のコンピュータ・プログラム。
【請求項１８】
前記リソースがコミットし得なかったことを前記リソースからの応答が表す場合、前記リソースに対する前記トランザクションの一部に関する再処理依頼の数が所定の閾値を越えるかどうかを決定するための第９命令を更に含み、
前記再処理依頼の数が前記所定の閾値よりも小さいか又は前記所定の閾値に等しい場合にのみ、前記トランザクションの一部が前記リソースに対して再処理依頼される、請求項１１に記載のコンピュータ・プログラム。
【請求項１９】
前記再処理依頼の数が前記所定の閾値よりも大きい場合、エラー・ハンドラに制御を移すための第１０命令を更に含む、請求項１８に記載のコンピュータ・プログラム。
【請求項２０】
前記エラー・ハンドラは、前記トランザクションの一部としてコミットしたリソースによって行われた変更をロールバックする、請求項１９に記載のコンピュータ・プログラム。
【請求項２１】
ソフトウェア環境においてトランザクションを処理するための装置であって、
前記トランザクションに参加する個々のリソースに対して前記トランザクションを再処理依頼するための手段と、
前記リソースがコミットし得たか又はコミットし得なかったかを表す応答を前記個々のリソースから受け取るための手段と、
前記リソースがコミットし得なかったことを表す応答が前記リソースから受け取られた場合、コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼するための手段と
を含む、装置。
【請求項２２】
前記個々のリソースからの応答は、前記個々のリソースと関連したアプリケーション・プログラム・インターフェースから受け取られた１つ又はそれ以上の応答メッセージである、請求項２１に記載の装置。
【請求項２３】
前記リソースがコミットし得なかったことを個々のリソースからの前記応答が表す場合、前記応答は、更に、前記リソースがコミットし得なかった理由に関する識別子を含む、請求項２１に記載の装置。
【請求項２４】
前記リソースにおいて遂行すべき適正なエラー解決及び回復オペレーションを決定するために前記リソースからの応答に対して１つ又はそれ以上のルールを適用するための手段と、
前記リソースに対して前記トランザクションを再処理依頼する前に前記リソースにおいて前記エラー解決及び回復オペレーションを遂行するための手段と
を更に含む、請求項２３に記載の装置。
【請求項２５】
前記トランザクションに対するトランザクション状態データ構造を生成するための手段と、
前記トランザクションに参加する各リソースに関する情報でもって前記トランザクション状態データ構造を占めさせるための手段と
を更に含む、請求項２１に記載の装置。
【請求項２６】
前記個々のリソースから応答を受け取ったことに応答して前記トランザクション状態データ構造を更新するための手段を更に含む、請求項２５に記載の装置。
【請求項２７】
トランザクション・マネージャが存在しないソフトウェア環境において前記装置が動作する、請求項２１に記載の装置。
【請求項２８】
前記リソースがコミットし得なかったことを前記リソースからの応答が表す場合、前記リソースに対する前記トランザクションの一部に関する再処理依頼の数が所定の閾値を越えるかどうかを決定するための手段と、
前記再処理依頼の数が前記所定の閾値よりも小さいか又は前記所定の閾値に等しい場合にのみ、前記リソースに対して前記トランザクションの一部を再処理依頼するための手段と
を更に含む、請求項２１に記載の装置。
【請求項２９】
前記再処理依頼の数が前記所定の閾値よりも大きい場合、エラー・ハンドラに制御を移すための手段を更に含む、請求項２８に記載の装置。
【請求項３０】
前記エラー・ハンドラは、前記トランザクションの一部としてコミットしたリソースによって行われた変更をロールバックする、請求項２９に記載の装置。
【請求項３１】
ソフトウェア環境においてトランザクションを処理するための装置であって、
前記トランザクションに参加する複数のリソースとコミュニケーションを行うための１つ又はそれ以上のインターフェースと、
前記複数のインターフェースに結合された認識エンジンと
を含み、
前記トランザクションは、前記複数のリソースに対して処理依頼され、前記複数のリソースから前記１つ又はそれ以上のインターフェースを介して応答が受け取られ、
前記応答は、対応するリソースがコミットし得たか又はコミットし得なかったかを表示し、
前記認識エンジンは、前記リソースがコミットし得なかったことを応答したリソースに対して前記トランザクションの一部を再処理依頼すべきかどうかを、前記受け取られた応答に基づいて決定する
装置。
【請求項３２】
前記コミットし得なかったリソースに対して前記トランザクションの一部を再処理依頼するための方法を決定するための１つ又はそれ以上のルールを有する再処理依頼ルール・データベースを更に含む、請求項３１に記載の装置。
【請求項３３】
前記トランザクションに参加する前記複数のリソースの各々の状態を識別するトランザクション状態データ構造をストアするためのトランザクション状態データ構造ストレージを更に含む、請求項３１に記載の装置。
【請求項３４】
前記複数のリソースから受け取られた前記リソースに基づいて、前記トランザクション状態データ構造が更新される、請求項３３に記載の装置。
【請求項３５】
前記認識エンジンは、前記トランザクション状態データ構造にストアされた状態情報に基づいて、コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼すべきかどうかを決定する、請求項３３に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して云えば、コンピュータ・システムの改良に関する。詳しく云えば、本発明は、多数のソフトウェア・リソースに関連したトランザクションを処理するとき、コンピュータ・システムにおけるデータの保全を維持するリソース保全エンジンに関するものである。
【背景技術】
【０００２】
ごく一般的なアプリケーションを除けば、こんにちのソフトウェア環境において実行されるアプリケーション・プログラムが特定のタスクを成し遂げるために多数のソフトウェア・リソースと対話することは普通のことである。これらのソフトウェア・リソースは、基本的には相互に独立していることが多いが、アプリケーション・プログラムの実行中、アトミック・ユニット、即ち、それ以上細分化し得ない統一体として作用する必要がある。アトミック・ユニットとして提携して作用する多数のリソースを持ったこの実行の単位がトランザクションと呼ばれる。
【０００３】
例えば、データベースにおけるレコードの更新を行うために単一のタスクがデータベース・ソフトウェア・リソースを必要とすることがあり、更新の完了を表すメッセージをもう１つのソフトウェア・リソースに送るためにメッセージング・ソフトウェア・リソースを必要とすることがある。トランザクションは、データベース・レコードを更新すること及びメッセージを送信することを含むであろう。トランザクションが成功裏に完了するためには、これらのオペレーションの両方とも遂行されなければならない。
【０００４】
或るソフトウェア・オペレーティング・システムは、個々のリソース間でコラボレーション（collaboration）を行うための機構を提供する。この機構は、トランザクション・マネージャと呼ばれることが多い。そのような機構は、個々のリソース間に分布している各トランザクションのオペレーションに対して単一のアトミック・ユニットとして作用する単一のコンテキストを形成する。このタイプのトランザクション・マネージャにおいてトランザクションを管理するための１つのよく知られた技法は、２フェーズ・コミット（commit）・プロセスを使用することである。
【０００５】
２フェーズ・コミット・プロセスは、「準備（prepare）フェーズ」及び「コミット・フェーズ」を含む。「準備フェーズ」の間、トランザクション・マネージャは、意図されたトランザクションをすべての参加者に知らせ、それらの参加者が保留のトランザクションをコミット又はロールバックするための準備ができていることをそれらが認めることを要求する。「コミット・フェーズ」の間、トランザクションにおけるすべての参加者がトランザクションをコミットするように、即ち、トランザクションのそれらの部分を完了するように要請される。参加者がトランザクションをコミットし得ない場合、即ち、「準備フェーズ」中に応答しない場合、トランザクションは失敗し、何らかの変更がロールバックされる。すべての参加者によって完了されていないトランザクションにより行われる変更のロールバックは、システムにおいてデータの保全を維持することを意図されている。即ち、トランザクションに関与したソフトウェア・リソースの状態の同期が維持されなければならない。
【０００６】
トランザクション・マネージャは、アプリケーション・プログラムにとって透明なこの機能を提供する。管理されたソフトウェア・リソースがコンピューティング・システム・ソフトウェアによって支援されるとき、これは完全に受容可能な方法であるけれども、必ずしも種々のソフトウェア・リソース・タイプがすべてのトランザクション・マネージャによって支援されるわけではない。更に、すべてのソフトウェア環境が、例えば、２フェーズ・コミット・プロセスを通してトランザクションを管理するために使用可能なトランザクション・マネージャを含むわけではない。
【０００７】
従って、トランザクション・マネージャが存在しないコンピューティング・システムにおいて、又は、トランザクション・マネージャによって支援されないソフトウェア・リソースを有するコンピューティング・システムにおいて、データの保全を維持するための装置及び方法を有することは有益であろう。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の目的は、トランザクション・マネージャのないソフトウェア環境においてリソースの保全を維持するための装置及び方法を提供することにある。
【課題を解決するための手段】
【０００９】
本発明の装置及び方法によれば、アプリケーション・プログラム及び複数のソフトウェア・リソース・アプリケーション・プログラム・インターフェース（ＡＰＩ）とインターフェースするためのリソース保全エンジンが設けられる。リソース保全エンジンは、アプリケーション・プログラムから１つのトランザクションを受ける。そのトランザクションは、そのトランザクションに関与する複数のソフトウェア・リソースを識別する。リソース保全エンジンは、オペレーティング・システムによって登録されたＡＰＩであってそのトランザクションにおいて識別されたソフトウェア・リソースに対して適正なＡＰＩを識別し、そのソフトウェア・リソースがトランザクションを受ける準備ができていることを表す肯定応答でもってそのソフトウェアが応答することを要請するリクエストを、ＡＰＩを介してそのソフトウェア・リソースに送る。
【００１０】
ソフトウェア・リソースから肯定応答を受けると、リソース保全エンジンはトランザクションをソフトウェア・リソースに、例えば、データベース、通信チャネル、キュー、メッセージング・ソフトウェア等に送り、そのトランザクションにおいて表された必要な機能をそれらに遂行させる、即ち、コミットさせるか又はコミットしないようにさせる。ソフトウェア・リソースは、例えば、通信接続障害、データベース接続の不整合、リソース・マネージャの障害、キューの満杯、タイムアウト状態の適合、可能な接続における最大数の到達、ディスク・ドライブのようなハードウェアの障害、システム・メモリの枯渇等を含む多くの種々の理由でコミットできないことがある。
【００１１】
本発明によれば、リソース保全エンジンにおける認識エンジンが、それぞれのソフトウェア・リソースが成功裏にコミットされたか、或いはそのコミットが失敗したかを表すメッセージをそのソフトウェア・リソースと関連したＡＰＩから受ける。認識エンジンは、すべてのソフトウェア・リソースが成功裏にコミットされたかどうか、成功裏にコミットされたソフトウェア・リソースがまったくなかったかどうか、或いはトランザクションの部分的なコミットがあったかどうかを決定するためにロジックを使用する。
【００１２】
トランザクションの一部であるとして識別されたソフトウェア・リソースがすべて成功裏にコミットされた場合、即ち、それらのソフトウェア・リソースと関連したトランザクション機能が成功裏に遂行された場合、トランザクションはエラーなしに完了する。しかし、トランザクションと関連した１つ又はそれ以上のソフトウェア・リソースがコミットすることに失敗した場合、認識エンジンは、コミットすることに失敗したソフトウェア・リソースと関連したトランザクションの残りを再処理依頼すべきかどうか及びどのように再処理依頼すべきかを決定する。これは、１つのリソースでもコミットすることに失敗したときに変更をロールバックする既知の２フェーズ・コミット・オペレーションに反するものである。
【００１３】
成功裏にコミットされたトランザクションと関連したソフトウェア・リソースがまったくなかった場合、トランザクションは一括してソフトウェア・リソースに再処理依頼されてもよい。それは、前の処理依頼の結果、いずれのソフトウェア・リソースに対しても状態の変化が生じなかったためである。しかし、エラーの回復なしに、トランザクションにおける失敗した部分に関する再処理依頼の結果として、ソフトウェア・リソースのコミットの成功は生じ得ない。従って、認識エンジンは、ＡＰＩから受け取った応答メッセージを分析し、ソフトウェア・リソースがトランザクションに関する以前の処理依頼においてコミットすることができなかった理由を決定する。その決定された理由に基づいて、認識エンジンは、トランザクションの再処理依頼がすべてのソフトウェア・リソースに関するコミットの成功を生じる可能性を高めるために、適切なエラー回復ロジック又は他の適切な継続ロジックを呼び出す。
【００１４】
トランザクションと関連したソフトウェア・リソースの部分的コミットの場合、認識エンジンは、コミットしなかったソフトウェア・リソースに、トランザクションにおける失敗した部分を再処理依頼するけれども、既にコミットしたソフトウェア・リソースのデータ保全を維持するためにロジックを使用する。この場合、認識エンジンは、どのソフトウェア・リソースがコミットしたか及びどのソフトウェア・リソースがコミットしなかったかを識別する。トランザクション内でエラー条件を生じさせ得るデータの重複（duplication）を避けるために、成功裏にコミットされなかったソフトウェア・リソースのみがトランザクション・プロセスの部分として再処理依頼される。
【００１５】
再処理依頼のためのロジックは、ソフトウェア・リソースのうちのどれもコミットしなかった場合に関して上述したロジックと同じである。即ち、ソフトウェア・リソースのＡＰＩによって返送されたメッセージがリソース・エンジンによって分析され、そのソフトウェア・リソースが成功裏にコミットしたかどうか、或いは、１つ又はそれ以上のソフトウェア・リソースが遭遇したエラーが存在したかどうかを決定する。１つの実施例では、リソースがコミットされたかどうかを決定するために、トランザクションに固有の情報が使用される。例えば、トランザクションは、独特の識別番号を持つことができるであろう。この識別番号がリソース内で見つかった場合、認識エンジンは、リソースがコミットされたことを結論付けることができる。この方法では、ソフトウェア・プログラムが、データの保全を明示的にトラッキングすることなく各ソフトウェア・リソースの状態を保持することができる。認識エンジンがリソースを照会するためには、リソース・エンティティがそのリソースのＡＰＩ又は他のレジスタ機構を介して検索可能でなければならない。
【００１６】
リソース保全エンジンにおける認識エンジンは、１つ又はそれ以上の回復及び再処理依頼ルールをデータ構造における非コミット・エントリに適用し得る。これらのルールは、トランザクションを関連のソフトウェア・リソースに再処理依頼するための適正なプロシージャにエラー・コードを相関させることを含み得る。それらのルールは、返送されたエラー・コードを見てもよいし、エラー・コードが返送されたコンテキストを見てもよい。例えば、アウトバウンド・キューとの通信接続が障害を生じたことをエラー・コードが表す場合、それらのルールを介して識別された再処理依頼プロシージャは、所定の期間待機し、しかる後、トランザクションをアウトバウンド・キューに対して再処理依頼することが可能である。
【００１７】
成功裏にコミットしたソフトウェア・リソースは、それらの変更をロールバックされない。本発明の特徴は、本発明が「コミット済み」リソースをロールバックしないということである。それは、その状況を「検出」し、検出時に直ちに未コミットのリソースを再処理依頼する。結局、再処理依頼が究極的に失敗した場合、トランザクション全体が「問題決定及び訂正のためのエラー・ハンドラ（Error Handler for Problem Determination and Correction）」に送られる。従って、本発明はロールバックを演じないけれども、トランザクションが完了していないことを表すための明示的な表示が行われる。原理な説明（rationale）は、ほとんどの場合、再処理依頼が成功するであろうということである。再処理依頼が成功しないという稀な場合、リスクを負ったリソースが識別され、エラー処理機構（ErrorHandling Mechanism）に送られる。その機構は、実際に、ロールバックを含む任意の数の仕事を行うことが可能である。
【００１８】
従って、本発明によって、トランザクション・マネージャを持たないソフトウェア環境においてトランザクションを処理するための機構が提供する。更に、本発明は、トランザクションを完了するために及びコミットされたソフトウェア・リソースに対して行われた変更のロールバックを回避するために、コミットすることができなかったソフトウェア・リソースに関して、そのトランザクションの一部をオペレーティング・システムに再処理依頼し得る機構を提供する。本発明に関するこれらの及び他の特徴及び利点は、望ましい実施例に関する以下のような詳細な説明において記述され、そのような説明から鑑み、当業者にとって明らかになるであろう。
【発明を実施するための最良の形態】
【００１９】
本発明は、トランザクション・マネージャを含まないソフトウェア環境においてトランザクションを管理するための機構を提供する。更に、本発明は、前の処理依頼においてコミットすることができなかったトランザクションを、そのトランザクションと関連したソフトウェア環境に再処理依頼するための機構を提供する。本発明の機構は、本発明の精神及び範囲から逸脱することなく、独立型のコンピューティング・デバイス又は分散型のデータ処理環境において実施可能である。望ましい実施例では、本発明は、分散型データ処理システムのサーバ・コンピューティング・デバイスにおいて実施される。従って、図１乃至図３は、本発明の特徴及び利点を説明するためのコンテキストを与えるために提供される。
【００２０】
次に、図面を参照すると、図１は、本発明を実装し得るデータ処理システムのネットワークの描画的表示を示す。ネットワーク・データ処理システム１００は、本発明を実装し得るコンピュータのネットワークである。ネットワーク・データ処理システム１００はネットワーク１０２を含む。ネットワーク１０２は、ネットワーク・データ処理システム１００において相互に接続された種々のデバイス及びコンピュータの間の通信リンクを提供するために使用される媒体である。ネットワーク１０２は、有線通信リンク、無線通信リンク、又は光ファイバ・ケーブルを含み得る。
【００２１】
図示の例では、サーバ１０４がストレージ・ユニット１０６と共にネットワーク１０２に接続される。更に、クライアント１０８、１１０、及び１１２がネットワーク１０２に接続される。これらのクライアント１０８，１１０、及び１１２は、例えば、パーソナル・コンピュータ又はネットワーク・コンピュータであってもよい。図示の例では、サーバ１０４は、ブート・ファイルのようなデータ、オペレーティング・システム・イメージ、及びアプリケーションをクライアント１０８−１１２に提供する。クライアント１０８、１１０、及び１１２は、サーバ１０４に対するクライアントである。ネットワーク・データ処理システム１００は、更なるサーバ、クライアント、及び図示されてない他のデバイスを含んでもよい。図示の例では、ネットワーク・データ処理システム１００は、ネットワーク１０２を有するインターネットであり、相互に通信するためにプロトコルである伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）スイートを使用するネットワーク及びゲートウェイのワールドワイド集合体を表す。インターネットの中心には、主要なノード間又はホスト・コンピュータ間の高速データ通信線のバックボーンがあり、それは、データ及びメッセージを経路指定する数千もの商業的コンピュータ・システム、政府機関のコンピュータ・システム、教育機関のコンピュータ・システム、及び他のコンピュータ・システムから成る。もちろん、ネットワーク・データ処理システム１００は、例えば、イントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、又は広域ネットワーク（ＷＡＮ）のような多数の種々のタイプのネットワークとしても実装可能である。図１は、１つの例として意図され、本発明に対する体系上の制限として意図されるものではない。
【００２２】
図２を参照すると、図１におけるサーバ１０４のようなサーバとして実装可能なデータ処理システムのブロック図が本発明の望ましい実施例に従って示される。データ処理システム２００は、システム・バス２０６に接続された複数のプロセッサ２０２及び２０４を含む対称マルチプロセッサ（Symmetric Multiprocessor : ＳＭＰ）システムであってもよい。代替えとして、単一プロセッサ・システムが使用可能である。更に、システム・バス２０６には、メモリ・コントローラ／キャッシュ２０８が接続され、そのメモリ・コントローラ／キャッシュはローカル・メモリ２０９に対するインターフェースを提供する。システム・バス２０６にはＩ／Ｏバス・ブリッジ２１０が接続され、Ｉ／Ｏバス２１２に対するインターフェースを提供する。メモリ・コントローラ／キャッシュ２０８及びＩ／Ｏバス・ブリッジ２１０は、図示のように統合されてもよい。
【００２３】
Ｉ／Ｏバス２１２に接続された周辺コンポーネント相互接続（PeripheralComponent Interconnect : ＰＣＩ）バス・ブリッジ２１４がＰＣＩローカル・バス２１６に対するインターフェースを提供する。ＰＣＩローカル・バス２１６には、多くのモデムが接続可能である。代表的なＰＣＩバスのインプリメンテーションは、４個のＰＣＩ拡張スロット又はアドイン・コネクタをサポートするであろう。図１におけるクライアント１０８−１１２に対する通信リンクが、アドイン・ボードを介してＰＣＩローカル・バス２１６に接続されたモデム２１８及びネットワーク・アダプタ２２０を介して提供可能である。
【００２４】
更なるＰＣＩバス・ブリッジ２２２及び２２６が更なるＰＣＩローカル・バス２２６及び２２８に対するインターフェースを提供する。これらのＰＣＩローカル・バスから、更なるモデム又はネットワーク・アダプタがサポート可能である。このように、データ処理システム２００は、多数のネットワーク・コンピュータへの接続を可能にする。図示のように、メモリマップ・グラフィックス・アダプタ２３０及びハード・ディスク２３２もＩ／Ｏバス２１２には、直接的に又は間接的に接続可能である。
【００２５】
図２に図示されたハードウェアが変更可能であることは当業者には明らかであろう。例えば、光ディスク・ドライブ等のような他の周辺装置が図示のハードウェアに加えて、又は図示のハードウェアの代わりに使用可能である。図示の例は、本発明に関する体系上の制限を暗示することを意味するものではない。
【００２６】
図２に示されたデータ処理システムは、例えば、米国ニューヨーク州アーモンクにおけるインターナショナル・ビジネス・マシーンズ・コーポレーションの製品である「IBM eServer pSeries」システムであってもよく、それは、拡張対話式エグゼクティブ（AdvancedInteractive Executive : ＡＩＸ）オペレーティング・システム又はＬＩＮＵＸオペレーティング・システムを稼動させる。
【００２７】
次に図３を参照すると、本発明を実装し得るデータ処理システムを表したブロック図が示される。データ処理システム３００は、クライアント・コンピュータ又は独立型コンピューティング・デバイスの一例である。データ処理システム３００は、周辺コンポーネント相互接続（ＰＣＩ）ローカル・バス・アーキテクチャを使用する。図示の例はＰＣＩバスを使用するけれども、加速式グラフィックス・ポート（Accelerated Graphics Port : ＡＧＰ）及び工業標準アーキテクチャ（Industry StandardArchitecture : ＩＳＡ）のような他のバス・アーキテクチャが使用可能である。プロセッサ３０２及びメイン・メモリ３０４がポスト／ＰＣＩキャッシュ／ブリッジ３０８を介してＰＣＩローカル・バス３０６に接続される。ＰＣＩブリッジ３０８は、プロセッサ３０２のための統合メモリ・コントローラ及びキャッシュ・メモリも含み得る。ＰＣＩローカル・バス３０６に対する更なる接続が、ダイレクト・コンポーネント相互接続を介して、又はアドイン・ボードを介して行われてもよい。図示の例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ３１０、小型コンピュータ・システム・インターフェース（SmallComputer System Interface : ＳＣＳＩ）・ホスト・バス・アダプタ３１２、及び拡張バス・インターフェース３１４がダイレクト・コンポーネント接続によってＰＣＩローカル・バス３０６に接続される。対照的に、オーディオ・アダプタ３１６、グラフィックス・アダプタ３１８、及びオーディオ／ビデオ・アダプタ３１９が、拡張スロットに挿入されたアドイン・ボードによってＰＣＩローカル・バス３０６に接続される。拡張バス・インターフェース３１４は、キーボード及びマウス・アダプタ３２０、モデム３２２、及び追加のメモリ３２４のための接続線を提供する。ＳＣＳＩホスト・バス・アダプタ３１２がハード・ディスク・ドライブ３２６、テープ・ドライブ３２８、及びＣＤ−ＲＯＭドライブ３３０のための接続線を提供する。代表的なＰＣＩローカル・バス・インプリメンテーションは、３個又は４個のＰＣＩ拡張スロット又はアドイン・コネクタをサポートするであろう。
【００２８】
オペレーティング・システムはプロセッサ３０２において稼動し、図３におけるデータ処理システム３００における種々のコンポーネントの制御を調整及び提供するために使用される。オペレーティング・システムは、マイクロソフト・コーポレーション（Microsoft Corporation）から入手可能なウィンドウＸＰのような商業的に入手可能なオペレーティング・システムであってもよい。Ｊａｖａのようなオブジェクト指向プログラミング・システムがオペレーティング・システムと関連して稼動可能であり、データ処理システム３００上で実行されるＪａｖａプログラム又はアプリケーションからオペレーティング・システムへのコールを行う。なお、「Ｊａｖａ」は、サン・マイクロシステムズ社（SunMicrosystems, Inc.）の商標である。オペレーティング・システム、オブジェクト指向オペレーティング・システム、及びアプリケーション又はプログラムのための命令は、ハード・ディスク・ドライブ３２６のようなストレージ・デバイス上に置かれ、プロセッサ３０２による実行のためにメイン・メモリ３０４にロード可能である。
【００２９】
図３におけるハードウェアがインプリメンテーションに従って変更可能であることは当業者には明らかであろう。フラッシュ・リード・オンリ・メモリ（ＲＯＭ）、同等の不揮発性メモリ、又は光ディスク・ドライブ等のような他の内部ハードウェア或いは周辺装置が、図３に示されたハードウェアに加えて又はそのハードウェアの代わりに使用可能である。更に、本発明のプロセスは、マルチプロセッサ・データ処理システムにも適用可能である。
【００３０】
もう１つの例として、データ処理システム３００は、ネットワーク通信インターフェースのタイプに依存することなくブート可能であるように構成された独立型システムであってもよい。更にもう１つの例として、データ処理システム３００は、パーソナル・ディジタル・アシスタント（Personal Digital Assistant : ＰＤＡ）デバイスであってもよい。そのＰＤＡデバイスは、オペレーティング・システム・ファイル及び（又は）ユーザ生成のデータを記憶するための不揮発性メモリを提供するために、ＲＯＭ及び（又は）フラッシュＲＯＭによって構成される。
【００３１】
図３における図示された例及び上記の例は体系上の制限を暗示することを意味するものではない。例えば、データ処理システム３００は、ＰＤＡの形式を取ることに加えて、ノートブック・コンピュータ又はハンド・ヘルド・コンピュータであってもよい。データ処理システム３００は、キオスク（kiosk）又はウェブ・アプライアンス（Web appliance）であってもよい。
【００３２】
前述のように、本発明は、トランザクション・マネージャのないソフトウェア環境においてリソース保全性を維持するための装置及び方法を提供する。本発明は、部分的にコミットされたトランザクションにおいてソフトウェア・リソースに対してトランザクションの再処理依頼を行うと共に、コンピューティング・システムのデータの保全性を保証するリソース保全エンジンを提供する。
【００３３】
次に、図４を参照すると、アプリケーション・インターフェース４１０と、複数のソフトウェア・リソース４６０−４８０に関連した複数のソフトウェア・リソース・アプリケーション・プログラム・インターフェース（ＡＰＩ）４３０−４８０とをインターフェースするためのリソース保全エンジン４２０が提供される。アプリケーション・プログラム４１０、リソース保全エンジン４２０、ＡＰＩ４３０−４５０、及びソフトウェア・リソース４６０−４８０は、同じ又は異なるコンピューティング・デバイスに常駐し得る。例えば、リソース保全エンジン４２０、ＡＰＩ４３０−４５０、ソフトウェア・リソース４６０−４８０はサーバ・コンピューティング・デバイスに常駐するけれども、アプリケーション・プログラム４１０は、クライアント・コンピューティング・デバイスに常駐してもよい。
【００３４】
アプリケーション・プログラム４１０は、処理するためのトランザクションをリソース保全エンジン４２０に処理依頼する。トランザクションは、そのトランザクションに関連した複数のソフトウェア・リソース４６０−４８０を識別する。リソース保全エンジン４２０は、トランザクションの一部分であるソフトウェア・リソース４６０−４８０及びそれらのそれぞれのＡＰＩ４３０−４５０を識別する。そこで、リソース保全エンジン４２０は、それらのＡＰＩ４３０−４５０を介してその識別されたソフトウェア・リソース４６０−４８０にトランザクションを処理依頼する。これらのＡＰＩ４３０−４５０は、それらの対応したソフトウェア・リソース４６０−４８０がトランザクションにおけるそれらの部分を成功裏に遂行したか又は非成功裏に遂行したかに関する表示を提供する。
【００３５】
例えば、トランザクションは、データベース更新メッセージをインバウンド・キュー上に配置し、ビジネス・ルールを更新メッセージに適用し、それによってデータベースを更新し、しかる後、アウトバウンド・キュー上に更新完了メッセージを設定するという形を取り得る。このトランザクションから、２つのリソース、即ち、メッセージング・ミドルウェア・リソース及びデータベース・ソフトウェア・リソースが使用されていることは明らかである。これらの２つのリソースに対するＡＰＩは、オペレーティング・システムによって登録されていると思われ、ＡＰＩによって返送された成功／エラー・コードがリソース保全エンジン４２０によってチェックされるように、既知の方法でオペレーティング・システムを介してリソース保全エンジン４２０により呼び出し可能である。
【００３６】
リソース保全エンジン４２０の主要な機能は、ソフトウェア・リソース４６０−４８０によって管理されたデータの保全性を維持することである。保全性を維持するために、リソース保全エンジン４２０は、ソフトウェア・リソース４６０−４８０が相互に同期化された状態に保つことを要求される。これは、個々のソフトウェア・リソース４６０−４８０が、実行されつつあるトランザクションに関して最新の状態に保たれることを意味する。ソフトウェア・リソース４６０−４８０のうちの少なくとも１つがコミットされない場合、ソフトウェア・リソース４６０−４８０がそのトランザクションに参加している他のいずれのソフトウェア・リソース４６０−４８０とも同期化されないという状態が存在する。
【００３７】
トランザクションがソフトウェア・リソースに関してアトミック・ユニットとして動作するようなトランザクションを処理するために、及びソフトウェア・リソースが同期化されるようなソフトウェア・リソースによって管理されたデータの保全性を維持するために、本発明は以下のような５つの機能を遂行する：
（１）トランザクションと関連する独立したソフトウェア・リソースの識別；
（２）ソフトウェア・リソースにおける成功したコミットの検証；
（３）トランザクションのすべてのソフトウェア・リソースが成功裏にコミットされたかどうかの決定；
（４）コミットしなかったソフトウェア・リソースの認識及びそれらがコミットしなかった理由；
（５）ソフトウェア・リソースがコミットしなかったための認識された理由に基づいて、コミットしなかったソフトウェア・リソースに対するトランザクションのエラー回復及び再処理依頼。
【００３８】
前述のように、リソース保全エンジン４２０は１つのトランザクションを受け取る。そのトランザクションは、そのトランザクションに関連したソフトウェア・リソースを識別する。トランザクションにおけるこの情報から、リソース保全エンジン４２０は、本発明が操作するコンピューティング・デバイスのオペレーティング・システムによるそれらの登録を通して関連のＡＰＩ４３０−４５０を識別することが可能である。更に、ＡＰＩ４３０−４５０は、関連のソフトウェア・リソース４６０−４８０によってトランザクションに関するそれの実行スレッドの成功裏の完了又は非成功裏の完了を、即ち、ソフトウェア・リソース４６０−４８０がトランザクションをコミットしたか否かを、リソース保全エンジン４２０に知らせるインターフェースを提供する。従って、ソフトウェア・リソース４６０−４８０とＡＰＩ４３０−４５０との対話は、リソース保全エンジンが上記機能（１）及び（２）、即ち、独立したソフトウェア・リソースの識別及びソフトウェア・リソースの成功したコミットを検証する機能を遂行するための能力を提供する
【００３９】
リソース保全エンジン４２０は、アプリケーション・プログラム４１０からトランザクションを受けたとき、そのトランザクションの一部であるソフトウェア・リソース４６０−４８０の適切なＡＰＩ４３０−４５０を識別する。リソース保全エンジン４２０は、更に、トランザクションに関するコンテキスト状態情報を維持するためのデータ構造を初期設定する。そこで、リソース保全エンジン４２０は、それぞれのＡＰＩ４３０−４５０を介してその識別されたソフトウェア・リソース４６０−４８０にトランザクションを送る。しかる後、リソース保全エンジン４２０は、ソフトウェア・リソースの成功したコミット又はソフトウェア・リソースに関するエラー状態を表すＡＰＩ４３０−４５０からの応答を待つ。そこで、その成功したコミット又はエラー状態がそのトランザクションに関連したデータ構造に記録される。
【００４０】
トランザクションは、コンピューティング・システムの特定のインプリメンテーションに依存した多くの種々の方法で遂行可能である。例えば、１つの特定のインプリメンテーションでは、処理は、個々のソフトウェア・リソースが成功裏にコミットされたとき、そのトランザクションに参加すべき次の独立したソフトウェア・リソースに処理が流れるよう、実行の逐次的フローを必要とするソフトウェア命令のセットに基づくことがあり得る。もう１つの例示的インプリメンテーションでは、イベント通知ロジックが利用可能である。例えば、個々のソフトウェア・リソースがコミットするとき、リソースをコミットするプログラムは、アクションが成功裏に完了したことをリソース保全エンジンに通知するであろう。供給される情報に一部は、そのリソースの成功又は失敗のステータ表示である。
【００４１】
上記のイベント通知インプリメンテーションに関連して本発明の望ましい実施例を説明する。しかし、逐次的処理フローが同様に使用可能であることは明らかである。そのような場合、リソース保全エンジン４２０によって維持されたコンテキスト状態データ構造がソフトウェア・リソースの逐次化に関する情報及びそれらがコミットの成功を返送したか否かの情報を含み得る。ソフトウェア・リソースがエラー状態を返送する場合、エラーを返送したソフトウェア・リソースの後に逐次現れる如何なるソフトウェア・リソースもそれらの現在の状態に対するエントリを持たないであろう。それは、それらがエラーを返送したソフトウェア・リソースにおけるコミットの成功を必要とするためである。
【００４２】
いずれの場合も、リソース保全エンジン４２０は、トランザクションのソフトウェア・リソースすべてがそのトランザクションをコミットしたかどうかを決定する（上記の機能（３））ために、そのトランザクションに対するコンテキスト状態データ構造における状態情報を見ることが可能である。リソース保全エンジン４２０は、ソフトウェア・リソース４６０−４８０に処理依頼されるトランザクションに起因して起こり得るケースを判別する（上記の機能（４））ために認識エンジンを使用する。コンテキスト状態データ構造においてリストされたソフトウェア・リソースのうちのいずれかがエラー状態を返送した場合、トランザクションは成功裏に完了しなかったし、そのトランザクションの回復及び再処理依頼はが望ましい。コンテキスト状態データ構造においてリストされたソフトウェア・リソースのすべてが成功したコミットを返送した場合、トランザクションは成功裏に完了し、成功トランザクションの正規の処理が行われる。「正規の処理」が意味することは、トランザクションが、データベースにおいて患者情報を成功裏に記録し且つその情報を他のシステムに伝送すること、銀行預金が適正に記録されたこと、航空機の予約が成功裏に記帳されたこと等のような所望のアクションを生じさせたことであり、次に、そのインプリメンテーションに特有の処理が実行される。
【００４３】
例えば、データベース・レコードに書き込まれた情報を含む患者メッセージが受信されたものと仮定する。この情報は、メッセージに含まれた独特のＩＤを含む。更に、一旦データベースが更新されると、メッセージ内容が他のメッセージング・システムにも配布される。データベースの更新と次のシステム上へのメッセージの送付との間で問題が生じた場合、データは同期を外れることがある。メッセージが第１システムにおいて患者を追加し、第１システムがその患者に対する更新を行う場合、それはそのレコードを適正に更新することができる。しかし、その更新が次のメッセージング・システムに送られる場合、当初のレコードが受け取られることはないので、それは失敗するであろう。
【００４４】
本発明なしの場合、第１システムにおいて処理するための当初のメッセージがリキューされたとき、（それはメッセージング・システムによってコミットされず、データベース・システムにおいてのみコミットされたので）、データベースにおけるレコードの重複を表すエラーが返送された。それは、既知のシステムにおけるそのトランザクションの処理を終了させるであろう。
【００４５】
本発明によれば、認識エンジンは、データベースにおける識別子がメッセージにおける識別子と一致し、その後の処理を生じさせ得ること、即ち、メッセージを次のシステムに送り得ることを決定する。
【００４６】
いずれのソフトウェア・リソースも成功裏にコミットされなかった場合、トランザクションにおける協働オペレーションのセット全体が本質的に反復可能である。実用的な意味では、これは、当初のソフトウェア・リソースが障害を生じたことを意味し、その後のソフトウェア・リソースの処理は放棄されなければならない。しかし、エラーの解決及び回復オペレーションが適用されない場合、オペレーションを反復した結果、ソフトウェア・リソースのコミットが成功する保証はない。遂行された特定のエラー解決及び回復オペレーションは、トランザクションをコミットしようとするとき、ソフトウェア・リソースが遭遇したエラーのタイプに基づく。
【００４７】
例えば、リソース保全エンジン４２０の認識エンジンは、ソフトウェア・リソース４６０−４８０と関連したＡＰＩ４３０−４５０によって返送されそしてコンテキスト状態データ構造にストアされたエラー・インディケータに対して認識ルールを適用し、トランザクションの再処理依頼の前に遂行されるべきエラー解決及び回復オペレーションのタイプを決定することが可能である。そのようなエラー解決及び回復オペレーションは、エラーを能動的に解決し且つソフトウェア・リソースを回復するようにもう１つのソフトウェア・オペレーションの開始に関連し、所定の期間を待ってからソフトウェア・リソースにトランザクションを再処理依頼するというような受動的な解決及び回復であってもよい。一旦、適正なエラー解決及び回復オペレーションが遂行されると、リソース保全エンジン４２０は、ＡＰＩ４３０−４５０を介してソフトウェア・リソース４６０−４８０にトランザクションを再処理依頼する（上記の機能（５））ことが可能である。
【００４８】
或るソフトウェア・リソースはコミットしたが他のソフトウェア・リソースはコミットしなかった場合、ソフトウェア保全エンジン４２０は、コミットしなかったソフトウェア・リソースのみにトランザクションを再処理依頼することができるけれども、全体のデータ保全を保証する。この方法では、トランザクションがまったく完了され得ないようにしてトランザクションにおける実エラー状態を導き得るデータの重複が回避される。
【００４９】
部分的なコミットのケースでは、リソース保全エンジン４２０の認識エンジンは、ソフトウェア・リソースが上述の関連エラー状態を有する場合、又はソフトウェア・リソースが初めて本質的に処理されようとしている場合、トランザクションのコンテキスト状態データ構造における各ソフトウェア・リソースに対して、そのソフトウェア・リソースが既にコミットされているかどうかを決定する。ソフトウェア・リソースが既にコミットされている場合、そのソフトウェア・リソースによりデータに対して行われた変更はロールバックされない。その代わり、ソフトウェア・リソースによって行われたデータ変更に関する現在の状態が維持される。
【００５０】
ソフトウェア・リソースが関連のエラー状態を有する場合、適正なエラー解決及び回復オペレーションがエラーの識別に基づいて遂行され、トランザクションはエラー状態を有するソフトウェア・リソースに対してのみ再処理依頼される。一旦、すべてのソフトウェア・リソースがトランザクションをコミットしたことをそれらのソフトウェア・リソースが示すと、正規の処理が遂行されてそのシステムにおけるトランザクションを完了する。ソフトウェア・リソースの或るものがエラー状態を返送し続ける場合、本発明のエラー解決及び再処理依頼ロジックは、すべてのソフトウェア・リソースがコミットするまで、又は所定数の再処理依頼が行われるまで、継続可能である。所定数の再処理依頼が行われた後、コミットしていない１つ又はそれ以上のソフトウェア・リソースが依然として存在する場合、トランザクションは成功裏に完了し得ないことが決定され、他のソフトウェア・リソースによって行われた変更がロールバックされ得る。
【００５１】
従って、本発明は、トランザクション・マネージャが存在しないソフトウェア環境においてトランザクションを管理するための機構を提供する。更に、本発明は、適正なエラー解決及び回復オペレーションが遂行された後、コミットしていないソフトウェア・リソースがトランザクションを再処理依頼し得るように、トランザクションと関連したソフトウェア・リソースをモニタするための機構を提供する。本発明によれば、コミットしなかったソフトウェア・リソースのみがトランザクションを再処理依頼されるであろうし、コミットしたソフトウェア・リソースはそれらの状態を変更されないであろう。
【００５２】
図５は、本発明によるリソース保全エンジンの例示的ブロック図である。図５における素子は、ソフトウェア、ハードウェア、又はソフトウェア及びハードウェアの何らかの結合において実装可能である。望ましい実施例では、図５の素子が、１つ又はそれ以上の処理デバイスによって実行されるソフトウェア命令として実装される。
【００５３】
図５に示されるように、リソース保全エンジンは、コントローラ５１０、インターフェース５２０、１つ又はそれ以上のＡＰＩインターフェース５３０、認識エンジン５４０、トランザクション状態データ構造ストレージ５５０、及びエラー解決及び回復／再処理依頼ルール・データベース（以下、「ルール・データベース」と呼ばれる）５６０を含む。素子５１０−５６０は、制御／データ信号バス５７０を介して相互にコミュニケーションを行う。バス・アーキテクチャが図５に示されているけれども、本発明は、そのようなアーキテクチャに限定されないし、素子５１０−５６０の間で制御情報及びデータのコミュニケーションを容易にする任意のアーキテクチャが本発明の精神及び範囲から逸脱することなく使用可能である。
【００５４】
コントローラ５１０は、リソース保全エンジンの全体的なオペレーションを制御し、他の素子５２０−５６０のオペレーションを調整する。インターフェース５２０は、１つ又はそれ以上のアプリケーション・プログラムに対するコミュニケーション・パスを提供する。ＡＰＩインターフェース５３０は、リソース保全エンジンが協働するソフトウェア・リソースのＡＩＰとのコミュニケーション・パスを提供する。コントローラ５１０は、インターフェース５２０を介してトランザクションを受け、ＡＰＩインターフェース５３０を介してソフトウェア・リソースにトランザクション・メッセージを送る。一方、ＡＰＩは、ソフトウェア・リソースの成功コミット又はエラー状態を表すメッセージを返送する。ＡＰＩに返送されたこれらのソフトウェア・リソースの状態が、コントローラ５１０によって、トランザクション状態データ構造ストレージ５５０におけるトランザクション状態データ構造にストアされる。
【００５５】
認識エンジン５４０は、すべてのソフトウェア・リソースがコミットした場合、コミットしたソフトウェア・リソースがまったくない場合、及びソフトウェア・リソースの部分的コミットがトランザクションに関連した場合を区別することに関して上記の機能を遂行する。認識エンジン５４０は、更に、トランザクション状態データ構造ストレージ５５０にストアされたトランザクション状態データに基づいて、どのソフトウェア・リソースがコミットしたか及びどれがコミットしなかったかを識別する。そこで、認識エンジン５４０は、ソフトウェア・リソースにおいて遂行されるべき適正なエラー解決及び回復オペレーション、並びに、いつ及び如何にトランザクションをソフトウェア・リソースに再処理依頼すべきであるかを決定するためにルール・データベース５６０からのルールを適用することが可能である。
【００５６】
図５に示された機構によって、トランザクション・マネージャが存在しないソフトウェア環境では、トランザクションがソフトウェア・リソースに対して処理依頼されることが可能である。更に、図５の機構によって、コミットしたソフトウェア・リソースの状態を維持するけれども、トランザクションは、コミットしなかったソフトウェア・リソースに再処理依頼されることが可能である。従って、本発明は、トランザクション全体が再送されるように、コミットしたソフトウェア・リソースによって行われた変更をロールバックする必要をなくする。
【００５７】
図６は、部分的コミットの場合における本発明の例示的オペレーションを示す。図６に示されるように、問題のトランザクションは、メッセージ・リソースがインバウンド・キュー６１０上に更新メッセージを配置すること、更新メッセージの内容がデータベース・リソース６２０にストアされるようにその更新メッセージの内容にビジネス・ルールが適用されること、しかる後、更新完了メッセージがメッセージ・リソースによってアウトバウンド・キュー６３０上に配置されることを含む。この例では、メッセージ・リソースがインバウンド・キュー６１０上にメッセージを配置し、データベース・リソース６２０が更新されるようにトランザクションが処理されるが、更新完了メッセージがアウトバウンド・キュー上に配置される前に失敗が存在するものと仮定する。
【００５８】
上記の失敗の結果、データベース・リソースに対するＡＰＩは、そのデータベース・リソースに対するＡＰＩがコミットされるというメッセージを返送するが、メッセージ・リソースに対するＡＰＩは、そのメッセージ・リソースがコミットされないことを表し、エラー状態は、そのメッセージ・リソースがコミットしなかった理由を表す。このエラー状態に基づいて、本発明の認識エンジンは、トランザクションをメッセージ・リソースに再処理依頼する前に適正なエラー解決及び回復オペレーションを適用するであろう。トランザクションは、データベース・リソースに再処理依頼されないであろう。
【００５９】
トランザクションをメッセージ・リソースに再処理依頼する場合、メッセージ・リソースは、インバウンド・キュー６１０上にもう１つの同じ更新メッセージを配置しようとすることがある。同じメッセージがインバウンド・キュー６１０上に配置されるので、その結果としてエラーが生じ得る。既知のシステムでは、この結果、エラー状態が生じるであろうし、そのエラー状態は、そのトランザクションに基づきソフトウェア・リソースによって行われた変更のロールバックを生じされるであろう。
【００６０】
しかし、ルール・データベースからのルールを適用する本発明は、データベース６２０がコミットされたこと、従って、インバウンド・キュー６１０における重複メッセージが回復不可能なエラーではなく、インバウンド・キュー６１０における重複メッセージの配置及びデータベース６２０の更新をスキップし得ることを決定し、アウトバウンド・キュー６３０における更新完了メッセージの配置を進めることが可能である。更新完了メッセージがアウトバウンド・キュー６３０上に配置された後、メッセージ・リソースＡＰＩは、そのメッセージ・リソースがコミットしたこと、従って、すべてのソフトウェア・リソースがコミットしたことを表すメッセージをリソース保全エンジンに返送する。
【００６１】
図７は、本発明の例示的オペレーションを概説したフローチャートである。図７に示されるように、オペレーションは、トランザクションを受け取ることによって開始する(ステップ７１０)。トランザクションの一部である個々のリソースが、そのトランザクションに含まれた情報に基づいて識別され、ＡＰＩがオペレーティング・システムによって登録される（ステップ７２０）。トランザクションに参加すべき各個々のリソースの処理が開始される(ステップ７３０)。各個々のリソースの処理が終了するとき、それらの関連のＡＰＩからメッセージが受け取られる(ステップ７４０)。すべてのリソースが成功したかどうか、即ち、コミットしてしまったかどうかに関する決定が行われる(ステップ７５０)。これが肯定される場合、正規の処理が遂行され、トランザクションを終了する(ステップ７６０)。それが否定される場合、認識エンジンが、コミットできなかった各リソースに対する失敗の原因を決定する(ステップ７７０)。識別された失敗の原因に基づいて、適切なエラー解決及び回復オペレーションが遂行される(ステップ７８０)。コミットしなかったリソースのみの処理が再開され(ステップ７９０)、オペレーションはステップ７４０に戻る。
【００６２】
図７には明確に示されてないけれども、リソースに関する所定数の再処理依頼又は再開が行われたかどうかを決定する追加ステップが含まれてもよい。そのようなケースでは、所定数の再処理依頼が行われた場合、クリティカルなエラーが識別可能であり、コミットしたリソースがロールバックされ得る。そうでない場合、所定数の再処理依頼が行われてしまうまで、又はすべてのリソースがコミットされるまで、再処理依頼は継続するであろう。
【００６３】
従って、本発明によって、トランザクション・マネージャを持たないソフトウェア環境においてトランザクションを処理するための機構が提供される。更に、本発明は、トランザクションを完了するために及びコミットしたソフトウェア・リソースに対して行われた変更のロールバックを回避するために、コミットし得なかったソフトウェア・リソースに対して、トランザクションの一部が再処理依頼されることを可能にする機構を提供する。
【００６４】
十分に機能するデータ処理システムに関連して本発明を説明したけれども、本発明のプロセスが命令及び種々の形式のコンピュータ可読媒体という形で配布可能であること、及び本発明がその配布を実行するために実際に使用される特定タイプの信号保持媒体に関係なく等しく適用することは、当業者には明らかであろう。コンピュータ可読媒体の例は、フロッピ・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭのような記録可能型媒体、並びに、ディジタル及びアナログ通信リンク、例えば、無線周波数及び光波伝送のような伝送形式を使用する有線又は無線通信リンクのような伝送型媒体を含む。コンピュータ可読媒体は、特定のデータ処理システムにおける実際の使用のためにデコードされるコード化フォーマットの形を取り得る。
【００６５】
本発明に関する説明は、図解及び説明を目的として示されており、網羅的であること又は開示された形式の発明に限定されることを意図するものではない。当業者にとって、多くの修正及び変更が明らかであろう。実施例は、本発明の原理及び実用的な応用を最もよく説明するために、及び意図された特定の用途に適する種々の修正を伴う種々の実施例に関して他の当業者が発明を理解することを可能にするように、選択及び記述された。
【００６６】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００６７】
（１）ソフトウェア環境においてトランザクションを処理する方法であって、
前記トランザクションに参加する個々のリソースに対して前記トランザクションを処理依頼するステップと、
前記リソースがコミットし得たか又はコミットし得なかったかを表す応答を前記個々のリソースから受け取るステップと、
前記リソースがコミットし得なかったことを表す応答が前記リソースから受け取られた場合、前記コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼するステップと
を含む、方法。
（２）前記個々のリソースからの応答は、前記個々のリソースと関連したアプリケーション・プログラム・インターフェースから受け取られた１つ又はそれ以上の応答メッセージである、上記（１)に記載の方法。
（３）前記リソースがコミットし得なかったことを個々のリソースからの前記応答が表す場合、前記応答は、更に、前記リソースがコミットし得なかった理由に関する識別子を含む、上記（１)に記載の方法。
（４）前記リソースにおいて遂行すべき適正なエラー解決及び回復オペレーションを決定するために前記リソースからの応答に対して１つ又はそれ以上のルールを適用するステップと、
前記リソースに対して前記トランザクションを再処理依頼する前に前記リソースにおいて前記エラー解決及び回復オペレーションを遂行するステップと
を更に含む、上記（３)に記載の方法。
（５）前記トランザクションに対するトランザクション状態データ構造を生成するステップと、
前記トランザクションに参加する各リソースに関する情報でもって前記トランザクション状態データ構造を占めさせるステップと
を更に含む、上記（１)に記載の方法。
（６）前記個々のリソースから応答を受け取ったことに応答して前記トランザクション状態データ構造を更新するステップを更に含む、上記（５)に記載の方法。
（７）トランザクション・マネージャが存在しないソフトウェア環境において前記方法が実施される、上記（１)に記載の方法。
（８）前記リソースがコミットし得なかったことを前記リソースからの応答が表す場合、前記リソースに対する前記トランザクションの一部に関する再処理依頼の数が所定の閾値を越えるかどうかを決定するステップと、
前記再処理依頼の数が前記所定の閾値よりも小さいか又は前記所定の閾値に等しい場合にのみ、前記リソースに対して前記トランザクションの一部を再処理依頼するステップと
を更に含む、上記（１)に記載の方法。
（９）前記再処理依頼の数が前記所定の閾値よりも大きい場合、エラー・ハンドラに制御を移すステップを更に含む、上記（８)に記載の方法。
（１０）前記エラー・ハンドラは、前記トランザクションの一部としてコミットしたリソースによって行われた変更をロールバックする、上記（９）に記載の方法。
（１１）ソフトウェア環境においてトランザクション処理をコンピュータに行わせるためのコンピュータ・プログラムであって、
前記トランザクションに参加する個々のリソースに対して前記トランザクションを再処理依頼するための第１命令と、
前記リソースがコミットし得たか又はコミットし得なかったかを表す応答を前記個々のリソースから受け取るための第２命令と、
前記リソースがコミットし得なかったことを表す応答が前記リソースから受け取られた場合、コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼するための第３命令と
を含む、コンピュータ・プログラム。
（１２）前記個々のリソースからの応答は、前記個々のリソースと関連したアプリケーション・プログラム・インターフェースから受け取られた１つ又はそれ以上の応答メッセージである、上記（１１)に記載のコンピュータ・プログラム。
（１３）前記リソースがコミットし得なかったことを個々のリソースからの前記応答が表す場合、前記応答は、更に、前記リソースがコミットし得なかった理由に関する識別子を含む、上記（１１)に記載のコンピュータ・プログラム。
（１４）前記リソースにおいて遂行すべき適正なエラー解決及び回復オペレーションを決定するために前記リソースからの応答に対して１つ又はそれ以上のルールを適用するための第４命令と、
前記リソースに対して前記トランザクションを再処理依頼する前に前記リソースにおいて前記エラー解決及び回復オペレーションを遂行するための第５命令と
を更に含む、上記（１３)に記載のコンピュータ・プログラム。
（１５）前記トランザクションに対するトランザクション状態データ構造を生成するための第６命令と、
前記トランザクションに参加する各リソースに関する情報でもって前記トランザクション状態データ構造を占めさせるための第７命令と
を更に含む、上記（１１)に記載のコンピュータ・プログラム。
（１６）前記個々のリソースから応答を受け取ったことに応答して前記トランザクション状態データ構造を更新するための第８命令を更に含む、上記（１５)に記載のコンピュータ・プログラム。
（１７）トランザクション・マネージャが存在しないソフトウェア環境において前記コンピュータ・プログラム製品が実行される、上記（１１)に記載のコンピュータ・プログラム。
（１８）前記リソースがコミットし得なかったことを前記リソースからの応答が表す場合、前記リソースに対する前記トランザクションの一部に関する再処理依頼の数が所定の閾値を越えるかどうかを決定するための第９命令を更に含み、
前記再処理依頼の数が前記所定の閾値よりも小さいか又は前記所定の閾値に等しい場合にのみ、前記トランザクションの一部が前記リソースに対して再処理依頼される、上記（１１)に記載のコンピュータ・プログラム。
（１９）前記再処理依頼の数が前記所定の閾値よりも大きい場合、エラー・ハンドラに制御を移すための第１０命令を更に含む、上記（１８)に記載のコンピュータ・プログラム。
（２０）前記エラー・ハンドラは、前記トランザクションの一部としてコミットしたリソースによって行われた変更をロールバックする、上記（１９)に記載のコンピュータ・プログラム。
（２１）ソフトウェア環境においてトランザクションを処理するための装置であって、
前記トランザクションに参加する個々のリソースに対して前記トランザクションを再処理依頼するための手段と、
前記リソースがコミットし得たか又はコミットし得なかったかを表す応答を前記個々のリソースから受け取るための手段と、
前記リソースがコミットし得なかったことを表す応答が前記リソースから受け取られた場合、コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼するための手段と
を含む、装置。
（２２）前記個々のリソースからの応答は、前記個々のリソースと関連したアプリケーション・プログラム・インターフェースから受け取られた１つ又はそれ以上の応答メッセージである、上記（２１)に記載の装置。
（２３）前記リソースがコミットし得なかったことを個々のリソースからの前記応答が表す場合、前記応答は、更に、前記リソースがコミットし得なかった理由に関する識別子を含む、上記（２１)に記載の装置。
（２４）前記リソースにおいて遂行すべき適正なエラー解決及び回復オペレーションを決定するために前記リソースからの応答に対して１つ又はそれ以上のルールを適用するための手段と、
前記リソースに対して前記トランザクションを再処理依頼する前に前記リソースにおいて前記エラー解決及び回復オペレーションを遂行するための手段と
を更に含む、上記（２３)に記載の装置。
（２５）前記トランザクションに対するトランザクション状態データ構造を生成するための手段と、
前記トランザクションに参加する各リソースに関する情報でもって前記トランザクション状態データ構造を占めさせるための手段と
を更に含む、上記（２１)に記載の装置。
（２６）前記個々のリソースから応答を受け取ったことに応答して前記トランザクション状態データ構造を更新するための手段を更に含む、上記（２５)に記載の装置。
（２７）トランザクション・マネージャが存在しないソフトウェア環境において前記装置が動作する、上記（２１)に記載の装置。
（２８）前記リソースがコミットし得なかったことを前記リソースからの応答が表す場合、前記リソースに対する前記トランザクションの一部に関する再処理依頼の数が所定の閾値を越えるかどうかを決定するための手段と、
前記再処理依頼の数が前記所定の閾値よりも小さいか又は前記所定の閾値に等しい場合にのみ、前記リソースに対して前記トランザクションの一部を再処理依頼するための手段と
を更に含む、上記（２１)に記載の装置。
（２９）前記再処理依頼の数が前記所定の閾値よりも大きい場合、エラー・ハンドラに制御を移すための手段を更に含む、上記（２８)に記載の装置。
（３０）前記エラー・ハンドラは、前記トランザクションの一部としてコミットしたリソースによって行われた変更をロールバックする、上記（２９)に記載の装置。
（３１）ソフトウェア環境においてトランザクションを処理するための装置であって、
前記トランザクションに参加する複数のリソースとコミュニケーションを行うための１つ又はそれ以上のインターフェースと、
前記複数のインターフェースに結合された認識エンジンと
を含み、
前記トランザクションは、前記複数のリソースに対して処理依頼され、前記複数のリソースから前記１つ又はそれ以上のインターフェースを介して応答が受け取られ、
前記応答は、対応するリソースがコミットし得たか又はコミットし得なかったかを表示し、
前記認識エンジンは、前記リソースがコミットし得なかったことを応答したリソースに対して前記トランザクションの一部を再処理依頼すべきかどうかを、前記受け取られた応答に基づいて決定する
装置。
（３２）前記コミットし得なかったリソースに対して前記トランザクションの一部を再処理依頼するための方法を決定するための１つ又はそれ以上のルールを有する再処理依頼ルール・データベースを更に含む、上記（３１)に記載の装置。
（３３）前記トランザクションに参加する前記複数のリソースの各々の状態を識別するトランザクション状態データ構造をストアするためのトランザクション状態データ構造ストレージを更に含む、上記（３１)に記載の装置。
（３４）前記複数のリソースから受け取られた前記リソースに基づいて、前記トランザクション状態データ構造が更新される、上記（３３)に記載の装置。
（３５）前記認識エンジンは、前記トランザクション状態データ構造にストアされた状態情報に基づいて、コミットし得なかった前記リソースに対して前記トランザクションの一部を再処理依頼すべきかどうかを決定する、上記（３３)に記載の装置。
【図面の簡単な説明】
【００６８】
【図１】本発明が実装可能である分散型データ処理システムを示す例示的な図である。
【図２】本発明が実装可能であるサーバ・コンピューティング・デバイスを示す例示的な図である。
【図３】本発明が実装可能であるクライアント又は独立型コンピューティング・デバイスを示す例示的な図である。
【図４】本発明の主要な操作可能コンポーネントの関係を示す例示的なブロック図である。
【図５】本発明の１つの実施例によるリソース保全エンジンの例示的なブロック図である。
【図６】本発明の実施例のオペレーションを示す例示的な図である。
【図７】本発明の典型的なオペレーションを概説するフローチャートである。
【図１】
2005004754.tif 000003
【図２】
2005004754.tif 000004
【図３】
2005004754.tif 000005
【図４】
2005004754.tif 000006
【図５】
2005004754.tif 000007
【図６】
2005004754.tif 000008
【図７】
2005004754.tif 000009