(57)【要約】本発明は、軽量クライアントが委任コミット（１４０）をサーバ（１０６ないし１１２）で実行することを可能にするトランザクション・サービスを提供する。この方法は、軽量クライアント（１０２）がトランザクションを始めて終了させる一方で、トランザクションのコミット処理についての実際の役割は、コミット・サーバ及び該サーバをホストしているマシン上で作動しているトランザクション・マネージャに委任することを可能にするものである。クライアント・アプリケーション（１０２）は、ローカルのトランザクションサーバを必要としない。コミット・サーバはクライアントにアクセス可能な複数のサーバから選択することができ、トランザクションを、該トランザクションに参加している他の（参加）サーバに対してコミットする役割のものである。
2005523486.tif 000002
【特許請求の範囲】
【請求項１】
クライアントとサーバとの間でトランザクションのコミットプロセスについての役割を委任するトランザクション処理システムであって、
サーバにおいてコミットされるべきトランザクションをクライアントから受け取るトランザクション・インターフェースと、
前記トランザクションに参加する少なくとも１つの参加サーバを含む前記トランザクションを受け取る複数のサーバと、
コミット・サーバになるべき前記複数のサーバから選択され、前記少なくとも１つの参加サーバにおける前記トランザクションをコミットし、前記トランザクションのコミットプロセスの結果を前記クライアントプロセスに通信するサーバと、
を備えることを特徴とするシステム。
【請求項２】
前記クライアントがアクティブ段階を含み、このアクティブ段階の間に前記システムがトランザクションに参加しているサーバのサブセットを監視して記録するようにされた請求項１に記載のシステム。
【請求項３】
前記複数のサーバに最初に接触されたサーバが前記コミット・サーバとして選択される請求項２に記載のシステム。
【請求項４】
前記コミット・サーバが前記トランザクションを、前記参加サーバにおける前準備、ロギング、及びコミット段階を通して移動させるようになった請求項１に記載のシステム。
【請求項５】
前記コミット・サーバが前記コミットを前記クライアントプロセスに返すようになった請求項１に記載のシステム。
【請求項６】
前記コミット・サーバがコミット前の前記トランザクションを格納するトランザクション記憶装置を含むようになった請求項１に記載のシステム。
【請求項７】
前記参加サーバにおける前記トランザクションがコミットを失敗した場合に、前記トランザクションをロールバックするロールバックプロセッサをさらに備えた請求項６に記載のシステム。
【請求項８】
前記複数のサーバのいずれもがトランザクション・コーディネータを含むことができる請求項１に記載のシステム。
【請求項９】
前記トランザクションのインターフェースがＪａｖａトランザクション・インターフェースを拡張するようになった請求項１に記載のシステム。
【請求項１０】
前記クライアントがアクティブ段階を含み、このアクティブ段階の間に、前記システムが前記トランザクションの前記アクティブ段階を制限するタイマーを維持し、前記トランザクションが指定されたタイムアウト間隔の中で終了しなかった場合には該トランザクションをロールバックするようにされた請求項１に記載のシステム。
【請求項１１】
前記クライアントがアクティブ段階を含み、このアクティブ段階の間に、前記システムがサーバとのすべての通信を追跡して、前記トランザクションがコミットされたときに如何なる未解決の通信要求もないことを確実にするようにされた請求項１に記載のシステム。
【請求項１２】
クライアントとサーバとの間のトランザクションがコミット・サーバに委任されるようにする役割を可能にする該クライアントと該サーバとの間のトランザクション処理についての方法であって、
サーバにおいてコミットされるべきトランザクションをクライアントから受け取る段階、
複数のサーバから前記トランザクションをコミットする役割をもったコミット・サーバを定める段階、及び
前記トランザクションを参加サーバでコミットして、前記コミッティングの結果を前記クライアントに通信する段階、
からなる方法。
【請求項１３】
前記クライアントがアクティブ段階を含み、このアクティブ段階の間に、前記トランザクション・マネージャ・ロケータが前記複数のサーバのサブセットに接触する請求項１２に記載の方法。
【請求項１４】
前記複数のサーバに最初に接触されたサーバが前記コミット・サーバとして指定される請求項１３に記載の方法。
【請求項１５】
前記コミット・サーバが、前記トランザクションを、前記参加サーバにおける前準備、ロギング、及びコミット段階を通して移動させる請求項１２に記載の方法。
【請求項１６】
前記コミット・サーバが前記コミットを前記クライアントに返す請求項１２に記載の方法。
【請求項１７】
前記コミット・サーバがコミット前の前記トランザクションを格納するトランザクション記憶装置を含む請求項１２に記載の方法。
【請求項１８】
前記参加サーバにおける前記トランザクションがコミットを失敗した場合に、前記トランザクションをロールバックするロールバックプロセッサを含む請求項１７に記載のシステム。
【請求項１９】
前記複数のサーバの各々がトランザクション・コーディネータとして作用することができる請求項１２に記載の方法。
【請求項２０】
前記トランザクションのインターフェースがＪａｖａトランザクション・インターフェースを拡張する請求項１２に記載の方法。
【請求項２１】
前記クライアントがアクティブ段階を含み、このアクティブ段階の間に、前記システムが前記トランザクションの前記アクティブ段階を制限するタイマーを維持し、前記トランザクションが指定されたタイムアウト間隔の中で終了しなかった場合には該トランザクションをロールバックする請求項１２に記載の方法。
【請求項２２】
前記クライアントがアクティブ段階を含み、このアクティブ段階の間に、前記システムがサーバとのすべての通信を追跡して、前記トランザクションがコミットされたときに如何なる未解決の通信要求もないことを確実にする請求項１２に記載の方法。
【請求項２３】
前記参加サーバもまたコミット・サーバである請求項１に記載のシステム。
【請求項２４】
前記参加サーバはコミット・サーバではない請求項１に記載のシステム。
【請求項２５】
前記参加サーバもまたコミット・サーバである請求項１２に記載の方法。
【請求項２６】
前記参加サーバはコミット・サーバではない請求項１２に記載の方法
【請求項２７】
前記参加サーバは前記複数のサーバのうちの別のものである請求項２６に記載の方法。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
著作権表示
本特許文書の開示の一部は、著作権保護を受けた材料を含む。著作権者は、特許・商標事務所の特許ファイル又は記録に示されるように、特許文書又は特許開示の如何なる人による複製にも異議はないが、そうでない場合は、すべての著作権を保有する。
【０００２】
（技術分野）
本発明は、一般に、アプリケーション及びトランザクションサーバに関し、具体的には、トランザクション又はメッセージの委任コミットを可能にするシステムに関する。
優先権主張
本出願は、２００２年７月１５日に出願された米国特許出願番号第＿号の「委任コミット特徴をもったトランザクション処理システム及び方法」、２００１年７月１７日に出願された米国特許仮出願番号第６０／３０６，１００号の「委任コミット特徴をもったトランザクション処理システム」、及び２００１年７月３０日に出願された米国特許出願番号第６０／３０８，７５３号の「委任コミット特徴をもったトランザクション処理システム」に基づく優先権を主張するものであり、これらの出願は引用によりここに組み入れられる。
相互参照
本出願は、発明者Ｅｄｗａｒｄ  Ｐ．Ｆｅｌｔ、Ｐｒｉｓｃｉｌｌａ  Ｆｕｎｇ、Ａｌｅｘ  Ｓｏｍｏｇｙｉ、及びＳｒｉｒａｍ  Ｓｒｉｎｉｖａｓａｎにより２００２年７月１５日に出願された係属中の米国特許出願番号第＿号の「トランザクション特性特徴をもったトランザクション処理システム」、発明者Ｅｄｗａｒｄ  Ｐ．Ｆｅｌｔ、Ｐｒｉｓｃｉｌｌａ  Ｆｕｎｇ、Ａｌｅｘ  Ｓｏｍｏｇｙｉ、及びＳｒｉｒａｍ  Ｓｒｉｎｉｖａｓａｎにより２００２年７月１５日に出願された米国出願番号第＿号の「同期されたコールバック処理特徴をもったトランザクション処理システム」に関するものであり、これら出願のすべては本明細書において全体を引用によりここに組み入れられる。
【０００３】
（背景技術）
Ｊａｖａ２プラットフォーム、エンタープライズ・エディション（Ｊ２ＥＥ）仕様は、多層構成エンタープライズ・アプリケーションを開発する現在の基準の１つを定義するものである。Ｊ２ＥＥは、エンタープライズ・アプリケーションの設計、開発、組み立て、及び配置に対してコンポーネントベースの手法を提供し、これは、費用を下げ、より速い設計及び実施を可能にする。Ｊ２ＥＥプラットフォームは、多層構造の分散アプリケーションモデル、コンポーネントを再使用する能力、統一された機密保護モデル、及び融通性のあるトランザクション制御を開発者に与える。これらは、市場に対してかつてないほどに速い革新的なカスタマ・ソリューションを供給できるだけでなく、結果としてもたらされるプラットフォームに異存しないＪ２ＥＥコンポーネントベースのソリューションは、どのベンダの製品及びアプリケーション・プログラム・インターフェース（ＡＰＩ）にも拘束されない。
Ｊ２ＥＥ仕様は、以下の種類のコンポーネント、すなわちアプリケーション・クライアント・コンポーネント、エンタープライズＪａｖａＢｅａｎｓ（ＥＪＢ）、サーブレット及びＪａｖａサーバページ（ＪＳＰ）（ウェブコンポーネントとも呼ばれる）、及びアプレットを定義する。多層構造の分散アプリケーションモデルは、アプリケーション論理が機能によりコンポーネントに分割されて、異なるアプリケーション・コンポーネントが同じであるか又は異なるサーバ上でＪ２ＥＥアプリケーションを構成することができるということを含意する。アプリケーション・コンポーネントが実際にはどこにインストールされるかは、該アプリケーション・コンポーネントが、多層構造Ｊ２ＥＥ環境のどの層に属するかによって決まる。これらの層は図１に示される。図示されるように、ここでは、アプリケーション・サーバの層４は、ＥＪＢコンテナ及び／又はサーブレット、ＪＳＰ、及びｈｔｍｌページのような表示コンテナを開発するように用いられる。これらは、次に、クライアント８及びクライアント・アプリケーションが配置されるクライアント層２と、エンタープライズ又はエンタープライズ・リソース・プラニング（ＥＲＰ）システムのようなレガシー・アプリケーションをホストするために用いられる後端層６との間のインターフェースとして用いられる。
【０００４】
クライアント層。これらは、ブラウザ、Ｊａｖａベースのプログラム、又は企業のファイヤウォールの内側及び外側両方のクライアント層内で作動している他のウェブ使用可能プログラミング環境とすることができる。
アプリケーション・サーバ層。通常、この層は、表示論理及びビジネス論理の組み合わせをホストして、クライアントの要求を支持するようにする。表示論理は、ＨＴＭＬページを表示するＪＳＴページ及びサーブレットを介して支持され、ビジネス論理はリモート・メソッド呼び出し（ＲＭＩ）オブジェクト及びＥＪＢを介して支持される。ＥＪＢは、互いにビーンズが実行される作動時間環境を構成するトランザクション、ライフサイクル及び状態管理、リソースプーリング、機密保護についてのコンテナ環境に依存する。
後端層。これは、一般には、既存のアプリケーション及びデータ記憶装置の組み合わせである。これは、エンタープライズ・リソース・プラニング（ＥＲＰ）、メインフレーム・トランザクション処理、データベースシステムその他のレガシー情報システムのようなシステムを含むことができるため、エンタープライズ情報システム（ＥＩＳ）層とも呼ばれる。
Ｊ２ＥＥアプリケーションのコンポーネントは別々に作動し、多くの場合は異なる装置上で作動するため、クライアント及びアプリケーション・サーバ層のコードが他のコード及びリソースを調べて参照する方法が必要である。クライアント及びアプリケーション・コードは、例えば、Ｊａｖａネーミング・アンド・ディレクトリ・インターフェース（ＪＮＤＩ）１６を用いて、エンタープライズ・ビーンズのようなユーザにより定義されたオブジェクト、及びＪａｖａデータベース・コネクタ（ＪＤＢＣ）データソース・オブジェクトの位置のような環境エントリを調べるようにすることができ、これらは次いで、後端層におけるリソース及びメッセージ連結を調べるのに用いることができる。
【０００５】
機密保護及びトランザクション管理のようなアプリケーション作動は、ウェブ及びエンタープライズ・ビーン・コンポーネント上の配置時間で構成することができる。この配置時間特徴は、アプリケーション論理を、組立体により異なることがある構成の設定から分離するものである。Ｊ２ＥＥ機密保護モデルは、システムリソースが許可ユーザによってのみアクセスできるように、開発者にウェブ又はエンタープライズ・ビーン・コンポーネントを構成させるものである。例えば、ウェブコンポーネントは、ユーザ名及びパスワードの入力を要求するように構成することができる。エンタープライズ・ビーン・コンポーネントは、特定の群の中の人だけがそのメソッドの或る種類を起動できるように構成することができる。或いは、サーブレット・コンポーネントは、幾つかのメソッドは誰からでもアクセス可能であり、幾つかのメソッドは、組織内の特別許可された人だけがアクセス可能であるように構成することができる。同じサーブレット・コンポーネントは、別の環境において、すべてのメソッドが誰からでも利用可能であるようにするか、又は、すべてのメソッドが選択された数人の人にだけ利用可能にするように構成することができる。
カリフォルニア州サンノゼ所在のＢＥＡシステムズ社からのウェブロジック・サーバのような幾つかアプリケーション・サーバは、サーバ上で作動しているコンポーネントの用途についてきめの細かい制御を可能にするアクセス制御リスト（ＡＣＬ）機構を用いる。ＡＣＬを用いて、開発者はＪａｖａメソッドレベルで、ユーザ又はユーザ群により何が実行できるか又は実行できないかを定義することができる。このＡＣＬ機構は、ＥＪＢ仕様で定義される独自のアクセス制御機構を有するＥＪＢ以外のアプリケーション・サーバ上の作動する如何なるものもカバーする。機密保護領域は、管理者が情報を既存の権限又は認証システムからＡＣＬの中にインポートすることを可能にする。
【０００６】
Ｊａｖａサーブレット
サーブレットは、ウェブサーバの機能性を拡張するプログラムである。サーブレットは、クライアントから要求を受け取り、動的に応答を生成し（多分、該要求を満たすためにデータベースを照会して）、次にＨＴＭＬ又はＸＭＬ文書を含む応答をクライアントに送る。サーブレットはＣＧＩと同様であるが、典型的には、該サーブレットはＪａｖａクラス及びストリームを用いるために、書くのが容易である。サーブレットはＪａｖａバイトコード準拠で、実行時間においてはサーブレット・インスタンスはメモリに保持されており、各クライアント要求が新しいスレッドを生成しているために実行がより速い。サーブレットは、動的な様式により、ＨＴＴＰ応答ストリームに対してデータを生成するのを容易にする。各クライアント要求は、新しい接続として行われることになるため、フロー制御は本来要求の間に来ない。このセッションを可能にするために、管理は要求間で特定のクライアントの状態を維持する。幾つかアプリケーション・サーバにおいては、サーブレットはＨＴＴＰセッションオブジェクトを利用して、メソッド要求間の状態を保存するようにする。このオブジェクトは、フェールオーバー目的のためにクラスタ環境において複製することができる。
【０００７】
Ｊａｖａサーバページ
ＪＳＰページは、サーブレットを開発するテキストベースの表示中心方法である。ＪＳＰページは、サーブレットのすべての利点を提供し、ＪａｖａＢｅａｎｓクラスと組み合わされると、コンテンツと表示論理とを別々に維持する容易な方法をもたらす。ＪＳＰページ及びサーブレットの両方は、プラットフォームに依存せず、より少ないオーバーヘッドを用いるために、共通ゲートウェイ・インタフェース（ＣＧＩ）よりも望ましい。ＪＳＰページは、ＪａｖａＢｅａｎｓクラスと併せて用いて、同様の外観をもったページで構成されたウェブサイトを作るためのウェブレンプレートを定義するようにすることができる。ＪａｖａＢｅａｎｓクラスは、テンプレートが如何なるＪａｖａコードももたないようにデータレンダリングを行う。このことは、これらがＨＴＭＬエディタにより維持できることを意味する。ＪＳＰページを用いる単純なウェブベースのアプリケーションを用いて、コンテンツをＪａｖａＢｅａｍｓクラスの代わりにカスタムタグ又はスクリプトレットを用いるアプリケーション論理にバインドするようにすることができる。カスタムタグは、ＪＳＰページにインポートされるタグライブラリの中にバンドルされる。スクリプトレットは、ＪＳＰページに直接組み込まれた小さなＪａｖａコードセグメントである。
【０００８】
データベースアクセスサービス（ＪＤＢＣ）
ＪＤＢＣは、リレーショナル・データベースへのブリッジとして作用し、ＯＤＢＣ（オープン・データベース・コネクティビティ）仕様上でモデル化される。これは、ドライバを用いることにより、データベースをプログラムコードから分離するものである。幾つかのＪＤＢＣの実施は、進歩したデータ形式についての支持をもたらし、さらにスクロール可能な結果の組及びバッチの更新についての機能性を支持する。
Ｊａｖａメッセージ・サービス（ＪＭＳ）
ＪＭＳは、Ｊａｖａプログラム間でメッセージのやりとりを支持するように用いられるものである。送り側及び受け取り側が互いを認識している必要がなく、これにより独立して作動できるという方法で、Ｊａｖａは非同期式通信を支持する。ＪＭＳは、２つのメッセージング・モデルを支持する。
２地点間。これは、メッセージ・キューに基づくものである。このモデルにおいては、メッセージの作成者は、メッセージをキューに送る。メッセージのコンシューマは、それ自体をキューに添付して、メッセージを聴取るようにすることができる。メッセージがキューに到達すると、コンシューマはこれをキューから離し、これに応答する。メッセージは、１つのキューにだけ送ることができ、１人のコンシューマによってのみ用いられる。コンシューマは、メッセージをフィルタして、まさに欲しい種類のメッセージを指定するようにすることができる。
パブリッシュ及びサブスクライブ。これは、作成者がメッセージをトピックに対して及びそのトピックについて登録しているすべてのコンシューマに送って、これらのメッセージを取り寄せるようにすることを可能にするものである。この場合においては、多くのコンシューマが同じメッセージを受け取ることができる。
【０００９】
Ｊａｖａインターフェース定義言語（ＩＤＬ）
ＣＯＲＢＡオブジェクトはＩＤＬを用いて、コントラクトを指定するが、これはすなわち、これらがどのように他のオブジェクトと対話するのかを指定するものである。ＪａｖａＩＤＬにより、コントラクトをＪａｖａの世界とＣＯＲＢＡの世界との間に定義することができる。ＳｕｎのＪＤＫ１．２においては、Ｊａｖａアプリケーションが、インターネットＩｎｔｅｒＯＲＢ（ＩＩＯＰ）プロトコルを介して、遠隔ＣＯＲＢＡオブジェクトを起動することを可能にするＯＲＢが含まれている。
【００１０】
エンタープライズＪａｖａＢｅａｎｓ（ＥＪＢ）
ＥＪＢコンポーネントは、ビジネス論理をカプセル化して、開発者が、データベースのアクセス、トランザクションの支持、機密保護、キャッシング、及び並行性のような典型的なタスクについてのプログラミングコードを懸念することが必要ないようにする。ＥＪＢ仕様においては、これらのタスクはＥＪＢコンテナの役割である。エンタープライズ・ビーンは、インターフェースとクラスとからなる。クライアントは、エンタープライズ・ビーンのホーム及び遠隔インターフェースを介してエンタープライズ・ビーン・メソッドにアクセスする。ホーム・インターフェースは、エンタープライズ・ビーンを生成し、除去し、配置するメソッドをもたらし、遠隔インターフェースは、ビジネス・メソッドをもたらす。配置時間において、コンテナはこれらのインターフェースからクラスを生成し、これは次に、エンタープライズ・ビーン上でビジネス・メソッドを生成し、除去し、配置し、及びコールしようとしているクライアントにアクセスをもたらすように用いられる。エンタープライズ・ビーンのクラスは、ビジネス・メソッド、生成メソッド、及びファインダ・メソッドについての実施をもたらし、ビーンがそれ自体の永続性を管理する場合には、それ自体のライフサイクル・メソッドについての実施をもたらすようになる。
エンタープライズ・ビーンズには２つの種類、すなわちエンティティ・ビーンズ及びセッション・ビーンズがある。セッション・ビーンは、クライアントとの一時的な会話を表し、データベースの読み込み及び書き込みを実行することがある。セッション・ビーンは、ＪＤＢＣコールをそれ自体で起動することができるか、又はエンティティ・ビーンを用いてコールをするようにすることもでき、この場合においては、該セッション・ビーンは該エンティティ・ビーンにとってクライアントである。セッション・ビーンのフィールドは、会話状態を含み、これは一時的なものである。サーバ又はクライアントがクラッシュした場合には、セッション・ビーンはなくなる。
【００１１】
エンティティ・ビーンは、データベースにおけるデータ及びそのデータ上で作用するメソッドを表す。エンプロイー情報の表についてのリレーショナル・データベースのコンテクストにおいては、該表の各行について１つのビーンがあることになる。エンティティ・ビーンはトランザクション可能で長命である。データがデータベースに残っている限り、エンティティ・ビーンは存在する。このモデルは、リレーショナル・データベースについて容易に用いることができ、オブジェクト・データベースに制限されるものではない。
セッション・ビーンは、ステートフル又はステートレスであってよい。ステートフルのセッション・ビーンは、クライアントの代わりに、会話状態を含む。会話状態は、セッション・ビーンのインスタンス・フィールド値にセッション・ビーンのフィールドから到達可能なすべてのオブジェクトを足したものである。ステートフルのセッション・ビーンは、データを永続性のあるデータ記憶装置において表さないが、これらはクライアントの代わりにデータにアクセスして更新することができる。ステートレスのセッション・ビーンは、特定のクライアントについて、如何なる状態情報ももたない。これらは、典型的には、如何なる特定の状態も維持しないサーバ側の反応をもたらす。ステートレスのセッション・ビーンズは、より少ないシステムのリソースを必要とする。一般的なサービスを提供するか又は格納されたデータの共用ビューを表すビジネス・オブジェクトは、ステートレスなセッション・ビーンのための良好な候補である。
コンテナ管理された永続性を用いて、リレーショナル・データベースにアクセスするようにするエンタープライズ・ビーンは、コンテナがこれを管理するために、データベースにアクセスするのに、如何なるＪＤＢＣ２．０ＡＰＩも用いることを開発者に要求しない。しかしながら、ビーン管理された永続性が用いられる場合、又はリレーショナル・データベース以外のエンタープライズ情報システムにアクセスする必要がある場合には、これを行う適切なコードが与えられなければならない。
データベースにアクセスするのにビーン管理された永続性を用いるエンタープライズ・ビーンの場合においては、ＪＤＢＣ２．０ＡＰＩをもったビーンのライフサイクル・メソッドを実施して、データのロード及び格納を取り扱い、実行時間と永続データベース記憶装置との間の一貫性を維持するようにしなければならない。Ｗｅｂ層はデータを層間で転送するのにＨＴＴＰ又はＨＴＴＰＳを用いるが、ＥＪＢ層はＲＭＩ−ＩＩＯＰを用いる。ＲＭＩ−ＩＩＯＰは、如何なるクライアント又はエンタープライズ・ビーンにアクセスするウェブ層プログラムにもＥＪＢ層におけるサービスに対して直接アクセスを与えるフルスケールの分散計算プロトコルである。これらのサーバは、エンタープライズ・ビーンを参照するＪＮＤＩ、非同期メッセージを送りかつ受け取るＪａｖａメッセージング・サービス（ＪＭＳ）、及びリレーショナル・データベースのアクセスのためのＪＤＢＣを含む。
【００１２】
トランザクション管理
ＷｅｂＬｏｇｉｃサーバシステムのようなあらゆるアプリケーション・サーバの最も基本的な特徴の１つは、トランザクション管理である。トランザクションは、データベースのトランザクションが正確に完了し、しかもこれらが以下のものを含む高性能トランザクションの「ＡＣＩＳ］特性のすべてを負うことを保証する手段である。
原子性。トランザクションがデータベースに対して行うすべての変更は恒久的なものにされ、そうでない場合はすべての変更はロールバックされる。
一貫性。首尾のよいトランザクションは、データベースを前の有効状態から新しい有効状態に変換する。
独立性。トランザクションがデータベースに対して行うすべての変更は、トランザクションがその作業を完了するまで他の作動からは見えないようにされる。
耐久性。トランザクションがデータベースに対して行うすべての変更は、将来のシステム又は媒体の障害に耐えるものにされる。
Ｊ２ＥＥトランザクションモデルは、アプリケーションの開発者に、配置時間において、単純なトランザクションを含むメソッド間の関係を指定させるようにして、１つのトランザクションにおけるすべてのメソッドが単一のユニットとして扱われるようにする。トランザクションはすべてが完了しなければならない一連の段階であるため、又はそれらのすべてが完了されない場合にはすべてが逆にされるために、このことは望ましい。例えば、開発者は、第１の口座からデビットし、第２の口座にクレジットすることにより、お金を１つの銀行口座から別の銀行口座に移動するエンタープライズ・ビーンの一連のメソッドを有することがある。この例においては、振込み業務全体が１つのユニットとして取り扱われることが望まれるため、デビット後及びクレジット前に障害があった場合には、デビットがロールバックされることになる。
【００１３】
トランザクション属性は、組み立て中にアプリケーション・コンポーネント上で指定されて、開発者が、メソッドを該アプリケーション・コンポーネントにおけるトランザクションの中に群分けすることを可能にするようにする。このようにして、アプリケーション・コンポーネントをＪ２ＥＥアプリケーション内で変更することができ、トランザクション属性は、コードを変更することなく再割り当てされる。Ｊａｖａトランザクション・サービス（ＪＴＳ）及びＪａｖａトランザクションＡＰＩ（ＪＴＡ）は、Ｊ２ＥＥにおける、より具体的にはＥＪＢ及びＪＤＢＣにおけるトランザクション支持の基礎を形成する。ＪＴＳ仕様は、Ｊａｖａをオブジェクト管理グループ（ＯＭＧ）オブジェクト・トランザクション・サービスに対してマップするトランザクション管理についての低レベルのアプリケーション・プログラム・インターフェース（ＡＰＩ）である。ＪＴＡ仕様は、サンマイクロシステムズがトランザクション処理及びデータベースシステム領域における有力な産業パートナーと協力して開発されたものであり、標準のＪａｖａインターフェースをトランザクション・マネージャ、リソース・マネージャ、アプリケーション・サーバ、及びトランザクション可能アプリケーションの間で指定する。具体的には、ＪＴＡは以下の２つの部分からなる高レベルのＡＰＩである。
トランザクション・インターフェース。これは、分散コンポーネントにより行われた作業がグローバルなトランザクションによりバインドされることを可能にし、トランザクションを構成する作動の群をマークするか又は識別する方法である。
ＸＡリソース・インターフェース。これは、分散されたトランザクションの取り扱いを可能にするＸ／オープン又はＸＡインターフェースに基づくインターフェースである。これらは、データベース又はキューの中の又はこれらの間のような１つより多いリソースにおけるトランザクションの調整を含む。
【００１４】
ほとんどの時間において、ＪＴＡとの明示的なトランザクションのプログラミングは、コンテナにより取り扱われるＪＤＢＣ及びＥＪＢのＡＰＩにより行われ、アプリケーションの配置記述子により構成されるため、開発者はこの作業について懸念する必要はない。開発者はその代わりに、トランザクションの実施ではなく、該トランザクションの設計に集中することができる。
ＷｅｂＬｏｇｉｃサーバは、分散されたトランザクション及びエンタープライズ・アプリケーションについての２段階のコミット・プロトコルの両方を支持する。分散されたトランザクションは、調整された方法により多数のリソース・マネージャ（データベースのような）を更新するトランザクションである。対照的に、ローカル・トランザクションは、単一のリソース・マネージャを更新するものである。２段階のコミット・プロトコルは、２つ又はそれ以上のリソース・マネージャにわたり単一のトランザクションを調整する方法である。これは、トランザクション可能な更新が参加しているデータベースすべてにおいてコミットされたか、又はすべてのデータベースから完全にロールバックされたかを確認することによりデータの完全性を保証して、トランザクションの開始前の状態に戻るようにする。換言すると、すべての参加しているデータベースが更新されるか、又はいずれも更新されないかのどちらかである。分散されたトランザクションは、以下の参加者を含む。
【００１５】
トランザクション・オリジネータ。これはトランザクションを開始するものである。トランザクション・オリジネータは、ユーザ・アプリケーション、エンタープライズＪａｖａＢｅａｎ、又はＪＭＳクライアントとすることができる。
トランザクション・マネージャ。これは、アプリケーション・プログラムの代わりにトランザクションを管理するものである。トランザクション・マネージャは、アプリケーション・プログラムからのコマンドを調整して、これらのトランザクションに参加しているすべてのリソース・マネージャと通信することにより、トランザクションを始めて完了するようにする。リソース・マネージャがトランザクション中に故障すると、トランザクション・マネージャは、リソース・マネージャが、待ち状態のトランザクションをコミットするか又はロールバックするかを判断することを助ける。
リカバリ可能リソース。これは、データのための永続的な記憶装置を与えるものである。リソースは、ほとんどの場合、データベースである。
リソース・マネージャ。これは、情報及びプロセスの収集に対するアクセスを与えるものである。
【００１６】
トランザクション認識ＪＤＢＣドライバは、一般的なリソース・マネージャである。リソース・マネージャは、トランザクション能力及び作動の性能を与えるものであり、これは、分散されたトランザクション内でアクセスされて制御されるエンティティである。リソース・マネージャと特定のリソースとの間の通信は、トランザクション・ブランチと呼ばれる。
２段階のコミット・プロトコルの第１の段階は、準備段階と呼ばれる。要求される更新はトランザクションのログファイルに記録され、リソースはリソース・マネージャを介して、変更する準備ができていることを示さなければならない。リソースは、更新をコミットするか又は前の状態のロールバックするかのいずれかを示すことができる。第２段階で何が起こるかは、リソースが何を示すかによって決まる。すべてのリソースがコミットすることを示した場合には、トランザクションに参加しているすべてのリソースが更新される。１つ又はそれ以上のリソースがロールバックすることを示した場合には、トランザクションに参加しているすべてのリソースが、前の状態にロールバックされる。
ビジネス・トランザクションについての支持
トランザクションは、以下に説明される例示的な状況において適切である（しかしこれらの状況は例示的なものに過ぎず、網羅的なものではない。）
第１の例として、クライアント・アプリケーションは、１つ又はそれ以上のデータベースに書き込むことを含むことがある幾つかのオブジェクトの起動をしなければならない。不成功な起動が１つでもあった場合には、いずれかの書き込まれる状態（メモリ内にであるか又はより典型的にはデータベースに、のいずれか）はロールバックされなければならない。例えば、旅行業者のアプリケーションを考慮する。クライアント・アプリケーションは、遠い場所、例えば、フランスのストラスブールからオーストラリアのアリススプリングスまでのような旅行を容易する必要がある。このような旅行は、必然的に多数の個々の飛行機の予約を必要とする。クライアント・アプリケーションは、両方の個々の各々のセグメントを連続した順序で、例えばストラスブールからパリまで、パリからニューヨークまで、ニューヨークからロサンゼルスまで、のように予約することにより作動する。しかしながら、個々に予約できない飛行機があった場合には、クライアント・アプリケーションは、そこまで作られていたすべての飛行機の予約をキャンセルする方法が必要になる。クライアント・アプリケーションは、サーバ・アプリケーションにより管理されたオブジェクトとの会話が必要であり、該クライアント・アプリケーションは、特定のオブジェクトのインスタンス上で多数の起動をする必要がある。会話は、以下の１つ又はそれ以上のものにより特徴づけることができる。
【００１７】
データは、各々の連続する起動中に又はその後に、メモリにキャッシュされるか又はデータベースに書き込まれる。データは会話の最後にデータベースに書き込まれる。クライアント・アプリケーションは、オブジェクトが各々の起動間でメモリ内のコンテクストを維持するようにすることを必要とし、すなわち、各々の連続する起動は、会話にわたりメモリに維持されているデータを用いる。会話の最後において、クライアント・アプリケーションは、会話中に又は会話の最後において生じることがあるすべてのデータベース書き込み作動をキャンセルする能力が必要である。
代替的な例として、インターネットベースのオンライン・ショッピングカートのアプリケーションを考える。クライアント・アプリケーションのユーザは、オンラインのカタログに目を通し、多数の注文の選択をする。ユーザが、買いたい物品のすべてを選択し終わると、彼らはそれをチェックし、購入のためにクレジット・カードの情報を入力するように進む。クレジット・カードのチェックが不成功だった場合には、ショッピング・アプリケーションは、ショッピング・カート内の保留中の注文の選択すべてをキャンセルするか、又は会話中に行われたあらゆる購入についてのトランザクションをロールバックする必要がある。或るオブジェクトについて、単一のクライアント起動の範囲内では、該オブジェクトは、データベースにおけるデータに対して多数の編集を行う。編集の１つが不成功であった場合には、オブジェクトはすべての編集をロールバックする機構が必要である。（この状況においては、個々のデータベース編集は必ずしもＥＪＢ又はＲＭＩ起動でなくてもよい。アプレットのようなクライアントは、ＪＮＤＩを用いてＴｒａｎｓａｃｔｉｏｎオブジェクト及びＴｒａｎｓａｃｔｉｏｎＭａｎａｇｅｒオブジェクトに対する参照を取得して、トランザクションを始めることができる。）
別の例として、銀行業務のアプリケーションを考える。クライアントは、テラー・オブジェクト上の振込み作動を起動する。振込み作動は、テラー・オブジェクトが銀行データベース上で以下の起動、すなわちデビットメソッドを１つの口座で起動すること、及びクレジットメソッドを別の口座で起動すること、を行うようにすることを要求する。銀行データベース上でのクレジット起動が不成功だった場合には、銀行アプリケーションは、前のデビット起動をロールバックするようにする機構が必要になる。
上述のトランザクション管理についての従来の方法における問題は、軽量クライアントが信頼性をもってトランザクションプロセスに参加することを可能にしないことである。ここで言及されるように、軽量クライアントは、典型的には、単一ユーザの、管理されていないデスクトップ上で作動する、言い換えると不規則な利用可能性を有するクライアントである。例えば、ＰＣ（パーソナルコンピュータ）又はデスクトップの所有者は、彼らがそれを使用していないときにはデスクトップシステムをオフにすることがある。これらの単一ユーザの管理されていないデスクトップシステムは、理想的には、トランザクションのコーディネーションのような複雑で不可欠のネットワーク機能を実行するように要求されるべきではない。特に、管理されていないシステムは、サーバのリソースを含むトランザクションに望まれる原子性、一貫性、独立性、及び耐久性（ＡＣＩＤ）特性を確実にする役割を負うべきではない。このような役割の負担をクライアントから取り除き、トランザクションのコミットプロセスを助けながら、トランザクション全体の統一性を確実にする機構が必要とされる。
【００１８】
（発明の開示）
本発明は、トランザクション処理システムにおけるクライアントが、委任されたコミットを実行する、すなわちトランザクションのコミット段階を別のエンティティ、典型的にはサーバに委任することを可能にするものである。委任されたコミットは、軽量クライアントがトランザクションを始め、アクティブな部分を管理し、次いで該トランザクションを終了させることを可能にする一方で、該トランザクションのコミット処理についての実際の役割は、サーバマシン上で作動しているトランザクション・マネージャ・プロセスに委任される。この方法により、クライアント・アプリケーションは、ローカルのトランザクションサーバを必要としない。その代わり、クライアントが用いるＵｓｅｒＴｒａｎｓａｃｔｉｏｎの遠隔実施は、トランザクション・コーディネーションの実際の役割を、サーバ上のトランザクション・マネージャに委任する。
このような機構の利点は、クライアントがトランザクションのアクティブ段階中に多数のサーバを直接含むことを可能にする一方で、該トランザクションを原子的にコミットするという重要なタスクは、典型的にはクライアント自体より信頼性のある管理されたサーバに委任されることである。
トランザクションのライフサイクルにおいて、アクティブ、引き渡し、前準備、準備、ロギング、及びコミット状態の間にあるものを含む幾つかの状態の遷移がある。本発明においては、アクティブ状態の間、クライアント上で作動しているアプリケーション・コードは、トランザクションの実行中に幾つかのサーバに接触する。クライアントは、どのサーバが接触されたかについて覚える役割のものである。一実施形態においては、最初に接触されたサーバが「コミット」サーバとして指定される。クライアントが「コミット」を要求すると、トランザクションをコミットする役割が、コミット・サーバに委任される（すなわち引き渡される）。コミット・サーバは、トランザクションを、前準備、準備、ロギング、及びコミット段階を通して移動させる。コミット処理が完了すると、コミット・サーバはクライアントに戻る。コミット・サーバはコミットを処理する役割のものであるという事実を除いては、このサーバは普通のサーバとすることができ、多くの場合において、いずれのサーバもコミット・サーバの役割を負うことができる。どれが実際にその役割をもつことになるか（及びしたがってコミット・サーバになるか）は、実際の実施によって決まる。
【００１９】
クライアントは、ＪＮＤＩを用いて、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ及びＴｒａｎｓａｃｔｉｏｎＭａｎａｇｅｒオブジェクトに対する参照を取得して、いずれかのオブジェクト参照を用いてトランザクションを始めることができる。現在のスレッドについてのトランザクション・オブジェクトを得るために、クライアント・プログラムは、ｇｅｔＴｒａｎｓａｃｔｉｏｎ（）メソッドを起動する。ＪＮＤＩから返されたトランザクション・オブジェクトは、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎインターフェース及びＴｒａｎｓａｃｔｉｏｎＭａｎａｇｅｒインターフェースの両方を支持する。
本発明は、トランザクションに含まれるすべてのトランザクション可能なオブジェクトがそれぞれのトランザクション可能な要求の処理を完了しない限り、コミットは成功しないことを保証することにより、トランザクションの完全性を確実にする。トランザクショ・サービスは、オープン・グループ（ＯＭＧ）仕様により定められた標準的な要求／応答のプロセス間通信モデルにより与えられるものと等しいチェックされたトランザクション作動をもたらす。
本発明の一実施形態は、サーバにおいてコミットされるべきトランザクションをクライアントから受け取るインターフェースと、該トランザクションに参加する少なくとも１つの参加サーバを含む該トランザクションを受け取る複数のサーバと、前述のトランザクションを前述の少なくとも１つの参加サーバにおいてコミットし、前述のトランザクションのコミット段階の結果を前述のクライアントプロセスに通信する、コミット・サーバになるべき前述の複数のサーバから選択されたサーバとからなる、クライアントとサーバとの間のトランザクションのコミットプロセスについての役割を委任するトランザクション処理システムを備える。本発明の別の実施形態は、サーバでコミットされるべきトランザクションをクライアントから受け取る段階、複数のサーバから前述のトランザクションをコミットする役割をもったコミット・サーバを判断する段階、及び前述のトランザクションを参加サーバにおいてコミットして、前述のコミッティングの結果を前述のクライアントに通信する段階を含む、クライアントとサーバとの間のトランザクションがコミット・サーバに委任されるようにする役割を可能にする該クライアントと該サーバとの間のトランザクション処理についての方法を含む。
【００２０】
（発明を実施するための最良の形態）
本発明は、クライアント又はクライアント・アプリケーションが、トランザクション又はトランザクション処理システムにおいて委任コミットを実行することを可能にするシステム及び方法を提供する。このプロセスは、クライアントがトランザクションを始めること及び終了することを可能にするものであるが、トランザクションのコミット処理についての実際の役割は、サーバ上で作動しているトランザクション・マネージャに委任されている。このことのために、クライアント・アプリケーションは、ローカルのトランザクションサーバを必要とせず、これはクライアントが軽量クライアントである場合に重要な特徴となる。クライアントにより用いられるユーザ・トランザクションの遠隔実施は、トランザクションのコーディネーションについての役割を、選択されたサーバ上のトランザクション・マネージャに委任するものである。
このような機構の利点は、クライアントが、トランザクションのアクティブ段階において、多数のサーバを直接含むことを可能にする一方で、自動的にトランザクションをコミットすることについての重要な作業は、典型的には該クライアントより信頼できる管理されたサーバに委任されることである。このことは、クライアントが、ユーザ、企業レベルのサーバよりも障害又はエラーを生じやすいデスクトップマシンのような軽量クライアントである場合に特に当てはまる。
【００２１】
図２は、クライアント・アプリケーションが、トランザクションをコーディネートする役割を多数のサーバの１つに委任する本発明の実施形態の概略図を示す。図２に示されるように、クライアント・アプリケーション１０４を含むクライアント１０２は、サーバＡ１０６、サーバＢ１０８、サーバＣ１１０、及びサーバＤ１１２を含む少なくとも１つの又は多数のサーバを含むトランザクションを開始するか又は始める。アクティブ段階１２０において、クライアントは、トランザクションのコミット段階前に、トランザクションプロセスからサーバを加えることができる。そのため、例えば、トランザクションは、最初にサーバＡ１２２又はそのサーバのリソースを含むが、その後のアクティブ段階の時点においては、クライアント・アプリケーションは、該トランザクションがサーバＡ及びサーバＢ１２４も含むべきであることを指定することができる。個々のトランザクションの各々は、潜在的なサーバ／コーディネータのプールからトランザクションのコーディネータ又は「コミット・サーバ」を割り当てられている。図２に示される例においては、サーバＡ１０６がトランザクションのコーディネータ／コミット・サーバとして選択されているが、いずれのサーバＡ、Ｂ、Ｃ又はＤも等しくトランザクションのコーディネータとして選択できることが明らかであろう。トランザクションが最終的にコミットされると、トランザクションのコーディネータは、実際のトランザクションをコーディネートする役割を負い、この負担をクライアントから取り除くようにする。図２に示されるように、次いで、トランザクションのコーディネータとして選択されたサーバは、トランザクションがコミットされたときに、及び該トランザクションがコミットされた場合に、該トランザクションをコミットすることを可能にする準備段階情報１２６を維持する。開始コミット段階１３０において、クライアント・アプリケーション１３０は、コミット要求１３２をトランザクションのコーディネータに、又はトランザクションのコーディネータとして作用しているサーバに送る。委任コミット段階１４０においては、トランザクションのコーディネータとして作用しているサーバ（この場合はサーバＡ１０６）が、トランザクション１４２を、トランザクションのコンテクストの一部として指定されているサーバ（この場合はサーバＡ１０６及びサーバＢ１０８）に対してコミットする役割を負う。クライアントもクライアント・アプリケーションも、コミットプロセスにおいてこれ以上の役割をもつようには要求されない。このように、クライアントはいずれのコミット処理にも参加する必要はないため、該クライアントは軽量クライアントとなることができる。トランザクションのコーディネータは、トランザクションをコミットするのに必要なすべての情報を有している。
【００２２】
図２においては、サーバＡがトランザクションのコーディネータとして選択されているが、実際には、サーバをトランザクションのコーディネータとして作用させるように選択するか又は指定するのに利用可能な多数の技術がある。幾つかの実施例においては、クライアントは、最初に接触されたサーバをトランザクションのコーディネータとして選択することができる。他の実施及び実施形態においては、トランザクションのコーディネータは特定の法則又はアルゴリズムにより複数のサーバの１つから選択することができる。アクティブ段階において、クライアントは、どのサーバがトランザクションのコーディネータに対するトランザクションに参加するべきかという情報を通過させて、該情報を、次に、コミット段階において用いることができるようにする。一実施においては、サーバの各々は実質的に同じであり、いずれのサーバもトランザクションのコーディネータとして作用することができる。他の実施においては、幾つかのサーバをトランザクションのコーディネータとして指定することができる。Ｊａｖａトランザクション・アプリケーション（ＪＴＡ）においては、ＪＴＡは、トランザクション・コンテクストとして知られるデータ構造におけるトランザクション・データを常時監視することができる。このトランザクション・コンテクストは、選択されたトランザクションのコーディネータに伝播される。データ構造／トランザクション・コンテクストは、コミット段階で後続して用いられるトランザクションのコーディネータｉｄを含むすべての必要な情報を含む。
【００２３】
図３は、本発明と併せて用いる典型的なクライアント−サーバシステムの図を示す。一般に、クライアント・アプリケーションと呼ばれる遠隔装置又はアプリケーション２０２は、アプリケーション・サーバ２０４と通信するか、又は、より典型的には、該アプリケーション・サーバでホストされるアプリケーションと通信する。クライアントエンドにおいては、トランザクション・マネージャ２０６がクライアント・アプリケーションにより用いられて、トランザクション２０８をサーバ（又は多数のサーバ）に送りかつ該サーバから受け取るようにする。同様に、サーバエンドにおいては、トランザクション・マネージャ２１０が用いられて、クライアントとのトランザクションを管理するようにする。一実施形態においては、サーバはさらに論理的には、トランザクションを開始するトランザクション・コーディネータプロセス２１４、トランザクションのステータスを監視するサブコーディネータプロセス２１６、及びトランザクションをロギングするトランザクションロガープロセス２１８を含むことができる。トランザクションが生じると、これらは後の監査、参照、又はロールバック目的のために、データベース上のトランザクションログ２２０に記録されることになる。「トランザクションログ」は、トランザクションが、システム障害にわたって原子的にコミットされることを確実にするトランザクションのリカバリのために必要とされる。トランザクション・コーディネータ、サブコーディネータ、及びロガー・プロセッサの各々はすべて、同じサーバ上で作動することができ、又は異なるサーバ上で作動することができることは明らかであろう。一実施形態においては、クライアントにより最初に到達されるサーバは、自動的にコーディネータの役割を負う。他の実施その他の実施形態は、コーディネータの選択について異なる方法を用いることができる。
【００２４】
図４は、アクティブ３０２、引き渡し３０４、前準備３０６、準備３０８、ロギング３１０、及びコミッティング３１２状態を含むトランザクションのライフサイクルにおける種々の状態又は段階を示す。いずれのトランザクションのライフサイクルにおいても、アクティブ、引き渡し、前準備、準備、ロギング、及びコミット状態を含むこのような幾つかの状態の遷移がある。アクティブな状態においては、クライアント上で作動しているアプリケーション又はアプリケーション・コードは、トランザクションの実際の実行中に幾つかのサーバに接触するように設計されている。このクライアントは、どのサーバが接触されたかについて、及び時にはトランザクションに関する他の詳細を覚える役割のものである。本発明の一実施形態においては、接触された最初のサーバは、「コミット・サーバ」又はトランザクション・コーディネータとして指定される。クライアントが「コミット」を要求すると、トランザクションをコミットする実際の役割が、コミット・サーバに委任されるか又は引き渡される。コミット・サーバはコミットを処理する役割のものであるという事実を除いては、このサーバは普通のサーバとすることができ、多くの場合において、いずれのサーバもコミット・サーバの役割を負うことができる。どれが実際にその役割をもつことになるか（及びしたがってコミット・サーバになるか）は、実際の実施によって決まる。
【００２５】
図５は、本発明の実施形態におけるトランザクション委任コミットシステムの第１の図を示す。クライアント４０２がプロセスのトランザクションを通信しようとすると、複数のサーバ（４０４、４０６）に接触して４０８、４１０、どちらが実際にトランザクションを処理するかを判断するようにする。幾つかの実施形態においては、複数のサーバ内の各々のサーバ（４０４、４０６）は、コミット・サーバ又は参加サーバのいずれかとして作用することができる。本発明により提供されるシステムは、用いられるサーバの数及び種類について融通性がある。一実施形態においては、最初に接触されたサーバ（図５の例においてはサーバＡ４０４）がコミット・サーバ及びコーディネータになる。他のサーバ（すなわち図５におけるサーバＢ４０６）は、この場合、単に参加サーバとして考えられる。他の実施においては、コミット・サーバを選択するのに代替的な機構を用いることができる。
図６は、本発明の実施形態における同じトランザクション委任コミットシステムの第２の図を示す。前の段階で選択されたコミット・サーバは、ここでコミットプロセスを取り扱う役割を負うようになる。トランザクションプロセスは、クライアントと参加サーバ４０６との間のさらに別の通信なしで、クライアント４０２とコミット・サーバ４０４との間の通信だけにより取り扱われる。コミット・サーバは、参加サーバ４０６（又はトランザクションが多数の参加サーバを含む場合には複数のサーバ）とのトランザクション処理４１４のすべてを取り扱う。コミット・サーバは、トランザクションを、参加サーバ上の前準備、準備、ロギング、及びコミット段階を通して移動させる。コミット処理が完了すると、コミット・サーバはコミットをクライアントに返す。
【００２６】
図７は、本発明の実施形態におけるトランザクション委任コミットプロセスのフローチャートを示す。図７に示されるように、クライアント又はクライアント・アプリケーションは、複数のトランザクション又はアプリケーション・サーバに接触する（段階５０２）。コミット・サーバは、特定のトランザクションを実行するように指定されており、これは、一実施形態おいては、クライアントが最初の起動をするサーバであるのが普通である。ある時点において（段階５０６）、クライアント・アプリケーションはコミットプロセスを呼び出す。コミット・サーバは、参加サーバ又は複数のサーバにおいてトランザクションを処理する（段階５０８）。コミットプロセスが完了すると、コミット・サーバはクライアントに戻る。
クライアントプロセス（例えば、アプレット）は、標準ＪＮＤＩインターフェースを用いて、ＵｓｅｒＴｒａｎｓａｃｔｉｏｎ及びＴｒａｎｓａｃｔｉｏｎＭａｎａｇｅｒオブジェクトに対する参照を取得することができる。クライアントは、いずれかのオブジェクト参照を用いて、トランザクションを始めることができる。
チェックされたトランザクションの作動は、トランザクションに含まれるすべてのトランザクション可能なオブジェクトが、それらのトランザクション可能な要求の処理を完了しない限り、コミットは成功しないことを保証することにより、トランザクションの完全性をもたらす。トランザクション・サービスは、オープン・グループにより定められた要求／応答のプロセス間通信モデルにより与えられるものと等しいチェックされたトランザクション作動をもたらす。
【００２７】
図８は、本発明の実施形態による２段階のコミットプロセスを利用することができるシステムの概略図を示す。クライアント又はクライアント・アプリケーション６０２は、例えばコミット機能を用いて、トランザクションのコミットを呼び出す６０４。トランザクション要求は、複数のサーバ６０６に通信される。これらのサーバの１つ６１０が、この特定のトランザクションについてのコミット・サーバとして作用するように選択される。トランザクションのコミットについての役割は、そのコミット・サーバ６１０に引き渡される。一実施形態においては、コミット・サーバは、このトランザクションをディスク６１４に書き込み、他（参加サーバ）はこれを選出するか又はこれの上で作動できるようにする。トランザクションのロギングは、２段階のコミット・プロトコルの一部であり、この目的はシステム障害の場合におけるトランザクションの原子性を確実にするようにするものである。例えば、コーディネーティング・サーバが第２のコミット段階においてクラッシュした場合には、該サーバが再スタートした後に、ログされたトランザクションを利用して、第２のコミット段階を完了するようにすることができる。必要であれば、コミット・サーバはさらに、トランザクションが失敗した場合に、任意のロールバック機能６１６を取り扱う。トランザクションが完全にコミットされると、コミット・サーバはコミットをクライアント又は呼び出しアプリケーション６０２に返す６１８。
【００２８】
図９から図１１は、本発明の一実施形態の状態マシンの遷移を示す。これらの状態遷移は、トランザクションのコミット・ライフサイクル中のトランザクションにおいて生じることがある種々の作動を表す。図９から図１１全体を通して、実線は成功した作動を示し、点線は失敗した（及び最終的にはロールバックされた）作動を示す。
図９ａ及び図９ｂは、本発明の実施形態におけるクライアントのトランザクション状態マシンの概略図を示す。図９ａにおいて、クライアント又はクライアント・アプリケーションから見ると、トランザクションはアクティブ段階７０２を通過し、コミットされるか７０８、又はロールバックされる７１０かのいずれかである。前準備段階７０４及び準備段階７０６は、クライアントからはほとんど見えない。図９ｂはグローバルな観点から同様のプロセスを示すものであり、幾つかのトランザクションのブランチを包含している。この例においては、前準備段階７１６は、トランザクションのすべてのブランチが準備されているかどうかをチェックする。すべてが準備されている場合には、トランザクションはログされるか又はディスクに書き込まれる（７１８）。そうでない場合には、トランザクションは全体としてロールバックされる７１０。
【００２９】
図１０は、本発明の実施形態におけるトランザクション・コーディネータの状態マシンの概略図を示す。トランザクション・コーディネータから見ると、トランザクションは、２段階の又は委任コミットプロセスに引き渡されなければならず、そうでない場合にはロールバックされなければならない。アクティブ段階８０２において、ロールバックされることになるトランザクションは、ロールバック８０６のためにマークされ８０４、最終的にはロールバックされる８０８。コミットされることになるトランザクションは、２段階のコミットプロセス８１０に送られ、最終的にはコミットされる８１２。２段階のコミットプロセスにおいて、失敗したいずれのトランザクションもロールバックのリストに加えられて、最終的にはロールバックされる。
図１１ａ及び図１１ｂは、本発明の実施形態におけるサブコーディネータの状態マシンの概略図を示す。サブコーディネータは前準備９０２、準備中９０６、準備済み９１０、及びコミット段階を通してトランザクションを視認する役割のものである。幾つかの実施形態においては、付加的な段階を用いて、トランザクションが準備される９０４ことを確認して、この準備された状態をトランザクションログにログするようにすることができる９０８。
【００３０】
図１２から図１４までは、本発明の実施形態におけるトランザクションに関連したライフサイクルを示す。図１２は、本発明の実施形態における開始トランザクションのライフサイクルの図を示す。トランザクション・マネージャ１００２はコーディネータ・ロケーション１００４を用いて、この特定のトランザクションのためのトランザクション・コーディネータ１００６を見出し、トランザクションＩＤを得るようにする。このトランザクションｉｄは、次に、トランザクション１００８を生成する単純な機能により用いられる。本発明の他の実施形態においては、ｇｅｔＣｏｒｄｉｎａｔｏｒ１００４及びｇｅｔ  ｔｒａｎｓａｃｔｉｏｎ（予約ＸＩＤ）１００６の段階が排除されており、トランザクション・マネージャ１００２は、擬似乱数を用いて、それ自体で構成するトランザクションの識別子を指定する。
図１３は、本発明の実施形態におけるトランザクション伝播ライフサイクルの図を示す。クライアント・アプリケーション１１０２は、トランザクション・マネージャ１１０４を利用して、トランザクションをクライアントＪａｖａ仮想マシン１１０６に送る。クライアントＪａｖａ仮想マシン１１０６は、このトランザクションの通信を、遠隔サーバにおける対応する又は同様のサーバＪａｖａ仮想マシン１１０８に対して取り扱う。遠隔サーバは、サーバ・アプリケーション１１１２と通信状態にあるトランザクション・マネージャ１１１０を含む。サーバ・トランザクション・マネージャ１１１０は、トランザクションのコミット要求をディスパッチして、応答をクライアントに送る役割のものである。
【００３１】
図１４は、本発明の実施形態におけるコミット・ライフサイクルの図を示す。トランザクション・コミット要求を受け取ると、サーバ・トランザクション・マネージャ１２０２は、該コミット要求をトランザクション・コーディネータ１２０４に通過させる。コミットが処理されると、トランザクション・マネージャ１２０２は、該コミットをクライアント又はクライアント・アプリケーションに返す。
本発明の上記の説明は、図示及び説明目的のために提供された。これは、網羅的であるか又は本発明を開示された精密な形態に制限することを意図するものではない。明らかに、多くの修正及び変形が当業者には明らかであろう。実施形態は、本発明の原理及びその実用的な用途を最もよく説明するために選択されて述べられたものであり、したがって、当業者が種々の実施形態について及び考慮される特定の用途に適当な種々の修正をもって本発明を理解するようにするものである。本発明の範囲は特許請求の範囲及びその均等技術により定義されることが意図される。
【図面の簡単な説明】
【００３２】
【図１】従来技術において周知のＪ２ＥＥアーキテクチャの図を示す。
【図２】本発明の実施形態における委任コミット特徴の図を示す。
【図３】本発明と併せて用いる典型的なクライアント−サーバシステムの図を示す。
【図４】本発明の実施形態における種々のトランザクション状態の図を示す。
【図５】コミット・サーバを含む、本発明の実施形態におけるトランザクション委任コミットシステムの第１の図を示す。
【図６】コミット・サーバを含む、本発明の実施形態におけるトランザクション委任コミットシステムの第２の図を示す。
【図７】本発明の実施形態におけるトランザクション委任コミットプロセスのフローチャートを示す。
【図８】本発明の実施形態における２段階のコミットプロセスの概略図を示す。
【図９ａ】本発明の実施形態におけるクライアントのトランザクション状態マシンの概略図を示す。
【図９ｂ】本発明の実施形態におけるクライアントのトランザクション状態マシンの概略図を示す。
【図１０】本発明の実施形態におけるコーディネータの状態マシンの概略図を示す。
【図１１ａ】本発明の実施形態におけるサブコーディネータの状態マシンの概略図を示す。
【図１１ｂ】本発明の実施形態におけるサブコーディネータの状態マシンの概略図を示す。
【図１２】本発明の実施形態における開始トランザクション・ライフサイクルの図を示す。
【図１３】本発明の実施形態におけるトランザクション伝播ライフサイクルの図を示す。
【図１４】本発明の実施形態におけるコミット・ライフサイクルの図を示す。
【図１】
2005523486.tif 000003
【図２】
2005523486.tif 000004
【図３】
2005523486.tif 000005
【図４】
2005523486.tif 000006
【図５】
2005523486.tif 000007
【図６】
2005523486.tif 000008
【図７】
2005523486.tif 000009
【図８】
2005523486.tif 000010
【図９ａ】
2005523486.tif 000011
【図９ｂ】
2005523486.tif 000012
【図１０】
2005523486.tif 000013
【図１１ａ】
2005523486.tif 000014
【図１１ｂ】
2005523486.tif 000015
【図１２】
2005523486.tif 000016
【図１３】
2005523486.tif 000017
【図１４】
2005523486.tif 000018
【国際調査報告】
2005523486.tif 000019
2005523486.tif 000020