JP3574030B2 - コンピューティング装置、操作方法およびプログラム記憶装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、１つのコンピューティング装置（「クライアント」）が別のコンピューティング装置（「サーバ」）にクライアントの作業の一部を実行するように要求する、クライアント／サーバ（「分散」としても知られる）コンピューティングの分野に関する。クライアントおよびサーバは両方とも、同一の物理的コンピューティング装置に配置することもできる。
【０００２】
【従来の技術】
クライアント／サーバ・コンピューティングは、情報技術の世界において過去数年間でますます重要になってきた。この種の分散コンピューティングは、１つのマシンがその作業の一部を、例えばその作業を実行するのにより適している別のマシンに委ねることを可能にする。例えば、サーバは、大量のデータの記憶を管理するデータベース・プログラムを実行する高能力コンピュータとすることができる一方、クライアントは単に、そのローカル・プログラムの１つで使用するためにデータベースからの情報を要求するデスクトップ・パーソナル・コンピュータ（ＰＣ）である。
【０００３】
クライアント／サーバ・コンピューティングの利点は、クライアントおよびサーバを異なる（異種）「プラットフォーム」に配置することを可能にする、オブジェクト指向プログラミング（ＯＯＰ）と呼ばれる周知のコンピュータ・プログラミング技術の使用によってさらに増強されてきた。プラットフォームとは、マシンがその作業を行うために使用する特定のハードウェア／ソフトウェア／オペレーティング・システム／通信プロトコルの組合せである。ＯＯＰは、クライアント・アプリケーション・プログラムの作業要求がどのようにサーバ・アプリケーション・プログラムによって交信され受け入れられるかを気にすることなく、クライアント・アプリケーション・プログラムおよびサーバ・アプリケーション・プログラムがそれ自体のプラットフォームで動作することを可能にする。同様にサーバ・アプリケーションは、ＯＯＰシステムがどのようにサーバ・アプリケーションの処理結果を受け取り、変換し、要求側クライアント・アプリケーションに返送するかを気にする必要がない。
【０００４】
ＯＯＰ技術が異種クライアント／サーバ・システムとどのように統合されてきたかの詳細は、米国特許第５４４０７４４号および欧州特許公開出願ＥＰ ０ ６７７９４３ Ａ２号に説明されている。これら２件の刊行物を参照によって本明細書に組み込む。しかし、本発明の環境の背景理解のために、基本的アーキテクチャの１例を以下で取り上げる。
【０００５】
図１に示すように、クライアント・コンピュータ１０（例えばＩＢＭ ＯＳ／２オペレーティング・システムを搭載したパーソナル・コンピュータとすることができる）は、そのオペレーティング・システム上で実行するアプリケーション・プログラム４０を有する（「ＩＢＭ」および「ＯＳ／２」はＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ社の商標）。アプリケーション・プログラム４０は定期的に、サーバ・コンピュータ２０上で作業を実行するように、かつ／または後でアプリケーション・プログラム４０で使用するためにデータをサーバ２０から返送するように要求する。サーバ・コンピュータ２０は、例えばＩＢＭのＭＶＳオペレーティング・システム上で実行する高性能メインフレーム・コンピュータとすることができる（「ＭＶＳ」もＩＢＭ社の商標）。本発明の場合、サーバによって実行される通信サービスの要求が、第１アプリケーション・プログラム４０とのユーザの対話によって引き起こされるか、それともアプリケーション・プログラム４０がユーザの対話に関係なく動作して、プログラムの実行中に自動的に要求を行うかは関係ない。
【０００６】
クライアント・コンピュータ１０がサーバ・コンピュータ２０のサービスを要求したいときに、第１アプリケーション・プログラム４０は、必要とするサービスについて第１論理手段５０に通知する。これは、例えば、第１論理手段に遠隔手順の名前を入出力パラメータのリストと共に送ることによって、実行することができる。次いで第１論理手段５０は、記憶装置６０に格納された利用可能な通信サービスの定義を参照して、第２コンピュータ２０との必要な通信を確立するタスクを処理する。可能なサービスはすべて、オブジェクト・クラス７０のコヒーシブ・フレームワークとして定義されており、これらのクラスは単一オブジェクト・クラスから導出される。このようにしてサービスを定義すると、性能および再使用可能性の点で多数の利点が得られる。
【０００７】
サーバ２０との必要な通信を確立するために、第１論理手段５０はフレームワーク内のどのオブジェクト・クラスを使用する必要があるかを判定し、次いで、サーバにおいて、そのオブジェクトのインスタンス、つまりそのオブジェクトにそのメソッドの１つを呼び出させるためにそのオブジェクトに送信されるメッセージを形成する。これにより、接続手段８０を介してサーバ・コンピュータ２０との接続の確立が生じ、続いて要求が第２論理手段９０に送信される。
【０００８】
次いで第２論理手段９０が要求を、サーバ・コンピュータ２０で実行している第２アプリケーション・プログラム１００（以下、サービス・アプリケーションという）に渡すので、サービス・アプリケーション１００は、データ検索手順を実行するなど、その要求によって要求される特定のタスクを実行することができる。このタスクが完了すると、サービス・アプリケーションは、結果を第１コンピュータ１０に返送する必要があるかもしれない。要求されたタスクの実行中、および結果が第１コンピュータ１０に返送される際、サーバ・アプリケーション１００は第２論理手段９０と対話する。第２論理手段９０はオブジェクトのインスタンスを決定し、サーバ・アプリケーション１００によって要求されたときにこれらのオブジェクトの適切なメソッドを呼び出し、記憶装置１１０に格納されたオブジェクト・クラスのコヒーシブ・フレームワークからオブジェクト・インスタンスが形成される。
【０００９】
上記の技術を使用すると、クライアント・アプリケーション・プログラム４０は通信アーキテクチャにさらされない。さらに、サービス・アプリケーション１００が、その環境の標準機構を介して呼び出される。つまり、それは遠隔的に呼び出されていることを認識しない。
【００１０】
オブジェクト管理グループ（ＯＭＧ）は、図１に示すような分散オブジェクトを持つ異種プラットフォームでのクライアント／サーバ・コンピューティングの様々な側面に関与する組織の国際的コンソーシアムである。ＯＭＧは、クライアント・コンピュータ（例えば１０）がサーバ・マシン（例えば２０）と（ＯＯＰの形で）通信するための標準を規定し発行した。これらの標準の一環として、クライアント・マシンとサーバ・マシンの間にオブジェクト指向ブリッジを提供するオブジェクト要求ブローカ（ＣＯＲＢＡつまり共通オブジェクト要求ブローカ・アーキテクチャと呼ばれる）が定義された。ＯＲＢは、オブジェクト指向実装の詳細からクライアント・アプリケーションおよびサーバ・アプリケーションを切り離し、第１および第２論理手段５０、９０ならびに接続手段８０の作業の少なくとも一部分を実行する。
【００１１】
ＣＯＲＢＡソフトウェア構造の一部として、ＯＭＧは「トランザクション」に関連する標準を規定した。これらの標準は、ＯＴＳつまりオブジェクト・トランザクション・サービスとして知られる。例えば、ＯＭＧ文書９４．８．４、ＣＯＲＢＡオブジェクト・トランザクション・サービス仕様１．０を参照されたい。コンピュータによって実装されるトランザクション処理システムは、いくつかの産業において重要なビジネス・タスクに使用される。トランザクションは、完全に終了しなければならないか、または動作せずに完全にパージしなければならない単一作業単位を定義する。例えば、銀行の現金自動預け払い機で顧客が現金を引き出そうとする場合、現金を払い出し、機械内にある現金の残高を差し引き、顧客の銀行預金残高を差し引く動作が全部行われるか、またはそれらが全く行われないかのいずれかでなければならない。下位動作の１つが失敗すると、記録と実際のオカレンスの不一致が生じる。
【００１２】
分散トランザクション処理は、複数の物理位置または論理位置における資源に影響するトランザクションを伴う。上記の例では、トランザクションは、局所現金自動預け払い機で管理される資源に影響するだけでなく、銀行のメイン・コンピュータによって管理される銀行預金残高にも影響する。そのようなトランザクションは、サーバによって処理される一連のクライアント要求により１つの特定のサーバ・コンピュータ（例えば２０）と通信する１つの特定のクライアント・コンピュータ（例えば１０）を伴う。ＯＭＧのＯＴＳは、これらの分散トランザクションを調整する責任がある。
【００１３】
クライアント・プロセスで実行するアプリケーションは、複数の様々なサーバの呼出しを含むトランザクションを始動し、それぞれのサーバはサーバ・プロセスを起動して、トランザクションに含まれる命令に従ってそのローカル・データを変更する。トランザクションを実行する（したがってすべてのサーバがそれらのローカル・データの変更を終了する）か、またはトランザクションを打ち切る（したがってすべてのサーバがトランザクション中に行われたそれらのローカル・データの変更を「撤回」または無視する）かのいずれかによって、トランザクションは終了する。トランザクション中にサーバと通信する（例えばそれらにトランザクションにおけるそれらの役割を実行するかまたは打ち切るように命令する）ために、含まれるプロセスの１つはトランザクションのための状態データを維持しなければならない。ＯＴＳ標準によると、これは一連のオブジェクトをセットアップするプロセスを含み、そのうちの１つは、様々なサーバに関してトランザクションを調整するコーディネータ・オブジェクトである。
【００１４】
このコーディネータ・オブジェクトの主な目的は、どのサーバ・オブジェクトがトランザクションに関与しているかを追跡し続けて、トランザクションが終了したときに、トランザクションに関与する各サーバ・オブジェクトに、１回の統一された努力で、そのサーバ・オブジェクトに関連するローカル・データベースに局所的に行われた変更をコミットするように命令することができるようにすることである。これにより、どのサーバ・オブジェクトも、同一トランザクションに関与する他のサーバ・オブジェクトなしでは、データ変更を最終決定しないことが保証される。したがって、トランザクションに参加する各サーバ・オブジェクトは最初にコーディネータ・オブジェクトに登録して、コーディネータ・オブジェクトがサーバ・オブジェクトの存在、トランザクションへの参加の希望、およびトランザクションを終了する時が来たときにサーバ・オブジェクトがどこにあるか（例えばサーバ・オブジェクトがどのサーバ・マシンに常駐しているか）が分かるようにしておかなければならない（コーディネータ・オブジェクトはすべてのサーバ・オブジェクトにそれぞれのローカル・データの変更を最終決定するように命令する）。
【００１５】
データを更新する責任のあるサーバ・オブジェクト（以下、資源オブジェクトという）は、別のサーバ・オブジェクト（またはトランザクションを開始した元のクライアント・オブジェクト）が資源オブジェクトに何らかの作業をするように資源オブジェクトに要求を送ったときに、トランザクションに関与するようになる。この後者の要求は、要求が特定のトランザクションの一部であることを資源オブジェクトに知らせる、トランザクション・コンテキストと呼ばれる何らかの情報を含む。ＣＯＲＢＡバージョン２では、トランザクション・コンテキストは、ローカルＣｏｓＴｒａｎｓａｃｔｉｏｎｓ：：Ｃｏｏｒｄｉｎａｔｏｒオブジェクトｇｅｔ＿ｔｘｃｏｎｔｅｘｔメソッドによって構築される。資源オブジェクトはそれが特定のトランザクションに関与するようになることを認識すると、コーディネータ・オブジェクトに登録要求を行う。
【００１６】
資源オブジェクトが、コーディネータ・オブジェクトとは異なるオペレーティング・システム・プロセスに配置されている場合、資源オブジェクト（２２３または２２４）と同じオペレーティング・システム・プロセスに配置された下位コーディネータ・オブジェクト（図２の２２２）を使用すると便利であることが明らかになった。その場合、主コーディネータ・オブジェクトを「上位コーディネータ・オブジェクト」２１１と呼ぶ。資源オブジェクト２２３のトランザクションへの登録中に、下位コーディネータ２２２は資源オブジェクト２２３を収容しているサーバ・マシン２２内で局所的にセットアップされ、資源オブジェクト２２３は登録要求を行うときに、この下位コーディネータ・オブジェクト２２２と直接やり取りする。（ここでは用語「サーバ・マシン」を使用しているが、分散サーバ・オブジェクトを実際には、同じサーバ・マシンであるがそのサーバ・マシン上で実行している別のオペレーティング・システム・プロセスに配置することもできることを示すために、用語「サーバ・プロセス」を使用することもできることに留意されたい。したがって、以下では、用語「サーバ」は、両方の用語を指すのに使用する。）次に下位コーディネータ２２２はそれ自体を、上位コーディネータ・オブジェクト２１１（あたかも資源オブジェクトであるかのように、おそらく別のサーバ・マシン上の別のプロセスに配置されている）に登録する。
【００１７】
下位コーディネータ・オブジェクト２２２はこのようにして、資源オブジェクトを収容しているサーバ内におけるトランザクションの存在を表現する。上位コーディネータ・オブジェクト２１１と直接やり取りする代わりに、資源オブジェクト２２３、２２４は最初にそれらのローカル下位コーディネータ・オブジェクト２２２とやり取りし、次にこれが上位コーディネータ・オブジェクトとやり取りする。これにより、オペレーティング・システム・プロセス間の相互呼出し回数が大幅に減少する。
【００１８】
トランザクションはしばしば、潜在的に異なるサーバ・マシン上でそれぞれ実行するいくつかの異なるプロセスを含む。例えば、サーバ・プロセス２１（これは上位コーディネータ２１１を含む）は、分散トランザクションに参加する３つの異なるプロセスを呼び出すことがあり、したがってそのような各プロセスは結果的に、そのプロセスのトランザクションを局所的に調整するために下位コーディネータを形成する。トランザクションの最後に、上位コーディネータは従来の２段階コミット・プロトコルを使用して、３つのプロセスのそれぞれがその変更を、一括した「オール・オア・ナッシング」方式で（つまり、それらが全部それぞれの変更を確定するか、それともそれらが全部それぞれの変更を取り消す）、最終決定することを確実にする。２段階コミット・プロトコルは従来、３つの下位コーディネータのそれぞれにプリペア・コール（ｐｒｅｐａｒｅ ｃａｌｌ）を送り、次いで、それらがプリペア・コールに応答してすべてコミットすることをボーティングしたと仮定して、３つの下位コーディネータのそれぞれにコミット・コールを送ることを含む。したがって、これは上位コーディネータ２１１による６つのプロセス間コールの送り出しを含む。
【００１９】
２段階コミットにおけるプロセス間コールの総数を減少するためにしばしば使用される２段階コミット・プロトコルの周知の最適化は、「最終エージェントの最適化」として知られる（例えば、ＧｒａｙとＲｅｕｔｅｒ共著「Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ：Ｐｒｏｃｅｓｓｅｓ ａｎｄ Ｔｅｃｈｎｉｑｕｅｓ」（Ｍｏｒｇａｎ Ｋａｕｆｍａｎ Ｐｕｂｌｉｓｈｅｒｓ社刊）１９９２年９月、１２．５．３節を参照のこと）。この最適化を要約すると、トランザクション・ルート・コーディネータ（例えば上位コーディネータ２１１）がトランザクションに含まれるＮ個の資源（例えば３つの下位コーディネータを表す）を有する場合、それらのうちＮ−１個を準備する（つまり、Ｎ−１個にプリペア・フローを送る）ということである。この時点ですべての資源がコミットすることをボーティングすると（通常のケース）、トランザクションの結果は最終資源のプリペア・ボーティングによって決まる。したがって、最終資源のプリペア・フローおよびコミット・フローを結合することができ、この最適化された最終フローは、ｒｅｓｏｕｒｃｅ：：ｃｏｍｍｉｔ＿ｏｎｅ＿ｐｈａｓｅ法によってＣＯＲＢＡ ＣｏｓＴｒａｎｓａｃｔｉｏｎｓ仕様で提供される。この議論では、下位コーディネータ、それらの資源、およびその他の資源を同様に取り扱うことができ、これらは総称して関連「エージェント」と呼ばれる。最終エージェントの最適化により、２段階コミットの単純なケースでは、コーディネータと最終エージェントとの間のメッセージ・フローは半減する。
【００２０】
２段階コミット・プロトコルのさらによく知られている最適化は、「線形コミット」最適化と呼ばれる（これも上記のＧｒａｙらの章節に記載されている）。線形コミット最適化は、分散トランザクションに関係するシステムを線形連鎖状に配列することができれば、この連鎖に最終エージェント最適化を繰返し使用することができるという概念に基づいている。これは、分散トランザクションの完了に参加している分散システム間で受け渡さなければならないメッセージの総数をほぼ半減する。
【００２１】
【発明が解決しようとする課題】
しかし、これらの最適化はトランザクション処理分野ではよく知られているが、クライアント／サーバ分散トランザクション処理において、どのようにしてコーディネータを自動的に確実にそのような線形連鎖状に配列するかがこれまで不明であり、従来技術におけるこの欠如が、本発明者が以下で記述する本発明を考案するに至る刺激となった。
【００２２】
【課題を解決するための手段】
第１の態様によると、本発明は、クライアント／サーバ・トランザクション処理システム用のコンピューティング装置であって、サーバ・データ処理装置がサーバ・データ処理装置にとって局所的な資源をトランザクションに登録するように要求するために登録要求を送るべきコンピューティング装置の標識を含むトランザクション要求をサーバ・データ処理装置に送ってサーバ・データ処理装置が分散トランザクションの処理に関与するようになることを要求するための送信手段と、トランザクション要求の受信に応答して登録要求を送出した装置の線形連鎖における現在の最後の装置の標識を含むトランザクション要求への応答をサーバ・データ処理装置から受け取るための受信手段と、受信手段が受け取る応答に基づいて線形連鎖の最後の現在の装置を追跡するための維持手段とを含み、送信手段によってトランザクション要求と一緒にサーバ・データ処理装置に送られる標識が、前記維持手段に基づいて線形連鎖の最後の現在の装置の標識である、コンピューティング装置を提供する。
【００２３】
第２の態様によれば、本発明は、第１の態様の装置を操作する方法を提供する。
【００２４】
第３の態様によれば、本発明は、第２の態様の方法のステップを実行するためにマシンによって実行可能な命令のプログラムを有形に実施するマシン可読プログラム記憶装置を提供する。
【００２５】
したがって、本発明は、分散トランザクションのコーディネータを自動的かつ確実に線形連鎖状に並べることができ、したがって線形コミット最適化の使用を可能にする。そうすると線形コミット最適化を使用することができるので、２段階コミット・プロセス中のコーディネータ間メッセージの流れの数を半減することができる。現在および将来のオブジェクト指向電子取引分野は分散トランザクションを実質的に利用するので（トランザクションに必要なデータベースが様々なサーバに保持されるため）、本発明は、システム間トラヒックをかなり削減するという意味で、そのようなシステムにとって事実上の確実な利益になるであろう。
【００２６】
【発明の実施の形態】
本発明の好適な実施形態がいかに作用するかを例示するために、今、図３に関して、シナリオの例を提示する。このシナリオ例は、分散トランザクションがどのように実行されるかを示すかなり典型的な例として選択した。
【００２７】
この例では、４つのシステムで動作する分散トランザクションを取り上げる。（ここで、システムはおそらくそれ自体の専用マシン上で動作する離散オペレーティング・システム・プロセスと認識することができ（各マシンはインターネットなどのネットワークを介して他のマシンと接続している）、あるいはこの例と矛盾することなくすべてのプロセスが同一物理マシン上で実行していることもあり得る。）
【００２８】
クライアント・アプリケーション３１はシステムＡ上にあり、ユーザのトランザクション作業単位を実行している間、クライアント・アプリケーション３１は、３つのサーバ・システムすなわちサーバＢ、サーバＣ、およびサーバＤをホストとするサーバ・アプリケーションを利用する。
【００２９】
ユーザのトランザクションが関係する各サーバ・システムについて、分散トランザクションの一部として回復可能資源にアクセスが行われるが、このためにはサーバ・システムがトランザクションおよびトランザクションの分散２段階コミット・プロセスに関与するようになることが必要である。トランザクションが展開するシナリオについて、以下で説明する。
【００３０】
トランザクションの展開中、本発明の好適な実施形態では、分散トランザクション・ツリーの「新しい」部分の展開は常に、構築中の現在のトランザクション「連鎖」の「最後」に配置されるようになることが必要である。この結果、トランザクション・ツリーが線形になり（関係するコーディネータの点から見て）、したがって「線形コミット」最適化の潜在的可能性が改善される。
【００３１】
ユーザは、クライアント・アプリケーション３１「ＣＬＩＥＮＴ ＡＰＰ」をシステム「Ａ」で実行し、このアプリケーションがユーザのためにトランザクション作業単位を実行している間に、アプリケーション・コードは、システム「Ｂ」に位置するサーバ・アプリケーション「ＡＰＰ ＳＥＲＶＥＲ Ｂ」に呼出しを行う（図３の流れ「１」）。
【００３２】
この呼出しが行われると、システムＢのトランザクション・サービスは、アプリケーションの代わりにシステムＢ（宛先システム）でトランザクションを確立する。これは、アプリケーションの要求と一緒に送られる「トランザクション・コンテキスト」を用いて行われる。トランザクション・コンテキストのこの確立は、トランザクション・オブジェクトを目標とするすべてのアプリケーションの流れ（例えば我々のシナリオでは流れ「１」、「５」、および「８」）を受信すると、宛先システムで同様に行われる。
【００３３】
サーバ・アプリケーション・プログラムＢ３２を実行している間、資源「ＲｅｓＢ１」３３はアプリケーション３２によってローカル・コーディネータ「ＣｏｏｒｄＢ」３４に登録される。「ＣｏｏｒｄＢ」３４は、分散トランザクションの完了に関与することがまだ登録されていないので、現在確立されているトランザクション・コンテキストに存在したコーディネータ参照（「ＣｏｏｒｄＡ」３５）にそれ自身のｒｅｇｉｓｔｅｒ＿ｒｅｓｏｕｒｃｅ呼出しを行う（流れ「２」）。したがって、「ＣｏｏｒｄＢ」３４は今、「ＣｏｏｒｄＡ」３５によって調整される分散トランザクションにリンクされる。したがって、ｒｅｇｉｓｔｅｒ＿ｒｅｓｏｕｒｃｅの流れの処理を終了した「ＣｏｏｒｄＡ」３５は戻り、制御は発呼側システム（「Ｂ」）に返される（流れ「３」）。
【００３４】
処理はシステムＢで続き、サーバ・アプリケーションＢ３２の一部によって別の資源３６（「ＲｅｓＢ２」）がトランザクションに登録される。「ＣｏｏｒｄＢ」３４はすでにトランザクションに関与しているので、新しいｒｅｇｉｓｔｅｒ＿ｒｅｓｏｕｒｃｅの流れ（「２」、「３」などの）は不要である。
【００３５】
ユーザのサーバ作業の処理がシステム「Ｂ」で終了し、「Ｂ」は制御をシステムＡに返す（流れ「４」）。この流れに便乗して、返却側システム（システムＢ）がこのとき関与するコーディネータの分散トランザクション連鎖の「最後」にあると考えるコーディネータへの参照−この例の場合には「ＣｏｏｒｄＢ」の参照−が送られ、この参照は返却側「トランザクション・コンテキスト」に格納される。
【００３６】
トランザクションの次のステップとして、クライアント・アプリケーション・プログラム３１はシステムＣの「ＡＰＰ ＳＥＲＶＥＲ Ｃ３７」を呼び出す（流れ「５」）。従来技術では、システムＡはシステムＡのコーディネータ３５に参照を渡す（この参照は、流れ「５」に便乗するトランザクション・コンテキストに入れて送られる）ので、システムＣは（システムＣにとって局所的な）ローカル資源をトランザクションに登録するときに、システムＣがシステムＡの主コーディネータ３５に登録要求を行わなければならないことを知る。しかし、本発明の好適な実施形態では、このシナリオ（実施形態）の流れ「５」で、システムＡは「ＣｏｏｒｄＡ」３５が現在「連鎖」の最後にあると考えるコーディネータ（つまり「ＣｏｏｒｄＢ」３４）に参照を渡す。
【００３７】
したがって、サーバ「Ｃ」のトランザクション・サービスがトランザクションに関与するようになるとき、（従来技術の場合のように）「ＣｏｏｒｄＡ」に接触して分散トランザクションに参加するようになる（したがって、Ｖ字型のトランザクション・ツリーを形成する）のではなく、「ＣｏｏｒｄＢ」３４に接触して線形連鎖を形成し、これは線形コミット最適化技術により２段階コミットを使用してより効率的にコミットすることができる。
【００３８】
したがって、ＣｏｏｒｄＢ３４がシステムＡからのトランザクション・コンテキストでシステムＣに渡されるコーディネータ参照であったので、「ＣｏｏｒｄＣ」３８は（システムＣのローカル資源ＲｅｓＣ１ ３９をトランザクションに登録するために）ｒｅｇｉｓｔｅｒ＿ｒｅｓｏｕｒｃｅの流れを「ＣｏｏｒｄＢ」３４に流す（流れ「６」）。この流れは、流れ「２」と同様であり、同じ装置を使用する。「ＣｏｏｒｄＢ」３４は戻り（返流「７」）、処理はシステムＣで続行する。
【００３９】
このとき、関与システムの連鎖「Ａ」→「Ｂ」→「Ｃ」ができており、制御（つまり、移動中のアプリケーションのスレッド）は現在ノード「Ｃ」にある。トランザクションの現在実行中／稼働中の部分のトランザクション・サービスが連鎖における現在の「最後」のコーディネータを知り、この「最後」のコーディネータの参照をアウトバウンド・トランザクションの流れと共に流し、この（または更新された）参照をどの応答でも返す限り、トランザクションは常に連鎖内の「最後」のシステム（システム間ｒｅｇｉｓｔｅｒ＿ｒｅｓｏｕｒｃｅを介して関与した）を追跡し、その後の新しいシステム間トランザクションの流れでこの参照を送る（かつそれを上述の通り更新する）ことにより、分散トランザクション・ツリーは、望む通りのコーディネータの線形連鎖を形成する。
【００４０】
このシナリオでは「ＣｏｏｒｄＣ」３８は現在の連鎖の最後にあるので、トランザクション作業がシステム「Ｄ」のサーバ・アプリケーションＤ４１に送られる（流れ「８」）と、ＣｏｏｒｄＣの参照がこの流れのトランザクション・コンテキストに入れて渡される。「ＣｏｏｒｄＤ」４０は、流れ「９」および返流「１０」により現在の「最後」のコーディネータ（ＣｏｏｒｄＣ３８）へのｒｅｇｉｓｔｅｒ＿ｒｅｓｏｕｒｃｅの流れ（そのローカル資源ＲｅｓＤ１ ４２を登録するため）を介してトランザクションに関与するようになる。我々のシナリオでは、作業はシステムＣからＤに流れ（流れ「８」）、システム「Ｃ」に戻り（返流「１１」）、次いで最終的にシステムＡに戻る（流れ「１２」）。したがって、コーディネータは、望む通りに線形連鎖状にＡ→Ｂ→Ｃ→Ｄと並ぶ。
【００４１】
別のシナリオでは、システム「Ｄ」は、システム「Ａ」、「Ｂ」、および「Ｃ」のいずれかから流れる作業のため、トランザクションに関与するようになることがあり、これらの３つのシステムのいずれかが線形連鎖「Ａ」→「Ｂ」→「Ｃ」の分散トランザクション・ツリーに関与するようになると、「Ａ」、「Ｂ」、または「Ｃ」のいずれかからＤへのトランザクションの流れは、トランザクション・コンテキストに便乗して「ＣｏｏｒｄＣ」３８への参照を渡す。
【００４２】
次に、本発明の好適な実施形態によるプロセスに従って実行されるステップを、図４の流れ図を参照しながら説明する。例示のために、図３のプロセスＣを、図４の流れ図に関して説明する代表的プロセスとする。
【００４３】
ステップ４０１で、プロセスＣのサーバ・アプリケーションＣ３７はクライアント・アプリケーション３１から、プロセスＣが分散トランザクションに関与するようになることを要求するトランザクション要求（図３の流れ５）を受け取る。受け取ったトランザクション要求の伝搬コンテキストには、プロセスＣがそのローカル資源ＲｅｓＣ１ ３９をトランザクションに登録するために登録要求を送出するときに、プロセスＣがこの登録要求をプロセスＢのＣｏｏｒｄＢ３４に送らなければならないという指示が含まれる（プロセスＢが線形連鎖の最後のコーディネータであったことを、プロセスＢが前にプロセスＡに知らせたため）。
【００４４】
ステップ４０２で、プロセスＣは受け取ったトランザクション要求の伝搬コンテキストを調べ、プロセスＣが登録要求を送る宛先とすべきプロセスの識別子を決定する。前段で説明した通り、図３のこのシナリオでは、登録要求を送るべき宛先プロセスはプロセスＢである。したがって、ステップ４０３で、プロセスＣは登録要求をプロセスＢのＣｏｏｒｄＢ３４に送る（流れ６）。このとき、プロセスＣのＣｏｏｒｄＣ３８は登録要求をプロセスＢに送ったので、プロセスＣのＣｏｏｒｄＣが今や、プロセスＢのＣｏｏｒｄＢに代わってトランザクションの登録コーディネータの線形連鎖における最後のコーディネータとなる。したがって、ステップ４０４で、プロセスＣは、例えばプロセスＢのＣｏｏｒｄＢが線形連鎖の最後のコーディネータであったという標識を前に格納していた記憶場所を削除し、かつその記憶場所にプロセスＣのＣｏｏｒｄＣが今や登録コーディネータの線形連鎖の最後のコーディネータであるという標識を挿入することによって、線形連鎖における最後の登録コーディネータを追跡する。
【００４５】
ステップ４０５で、プロセスＣは、プロセスＤが分散トランザクションに関与するようになることを要求するために、プロセスＤにトランザクション要求を送る（流れ８）（プロセスＣはプロセスＤを、クライアント・アプリケーション３１がサーバ・アプリケーションＣに送った（流れ５で）トランザクション要求の実行の一部として呼び出すことに注意されたい）。トランザクション要求の伝搬コンテキストには、プロセスＤがそのローカル資源ＲｅｓＤ１ ４２をトランザクションに登録するために登録要求を送出するときに、プロセスＤはこの登録要求をプロセスＣのＣｏｏｒｄＣ３８に送らなければならないという指示が含まれる（前段落で述べた通り、プロセスＣがプロセスＢに代わってそれ自身を線形連鎖の最後のコーディネータとしたため）。
【００４６】
ステップ４０６で、プロセスＣはプロセスＤから、プロセスＤのローカル資源ＲｅｓＤ１ ４２をトランザクションに登録することを要求する登録要求を受け取る（流れ９）。次いでプロセスＣは、登録要求への応答（流れ１０）をプロセスＤに送り返す（ステップ４０７）。
【００４７】
ステップ４０７で、プロセスＤがトランザクション作業のその役割を実行し終わると、プロセスＣは、ステップ４０５でプロセスＣがプロセスＤに送ったトランザクション要求（流れ８）へのプロセスＤからの応答を受け取る（流れ１１）。この後者の応答（流れ１１）は、プロセスＤが今線形連鎖における最後の登録コーディネータであるという標識を含む（プロセスＤがプロセスＣに登録要求を送ったため（流れ９））。ステップ４０８で、プロセスＣは次に、例えばプロセスＣのＣｏｏｒｄＣが線形連鎖の最後のコーディネータであったという標識を前に格納していた記憶場所を削除し、かつその記憶場所にプロセスＤのＣｏｏｒｄＤが今や登録コーディネータの線形連鎖の最後のコーディネータであるという標識を挿入することによって、線形連鎖における最後の登録コーディネータを追跡する。
【００４８】
ステップ４０９で、プロセスＣがステップ４０１で受け取ったトランザクション要求のその処理を終了すると、プロセスＣはトランザクション要求への応答（流れ１２）をプロセスＡのクライアント・アプリケーション３１に送り返す。この応答の伝搬トランザクション・コンテキストには、プロセスＤが今や登録されたコーディネータの線形連鎖の最後のコーディネータであるという標識が含まれる。この応答を受け取ると、プロセスＡは次いで線形連鎖における最後のコーディネータについてのそれ自体の記録を更新する（プロセスＡは現在、プロセスＢを最後のコーディネータとして格納しているので）。このようにして、クライアント・アプリケーション３１がさらなるサーバＥ（図３には図示せず）にトランザクション要求を送る場合、クライアント・アプリケーション３１はサーバＥに、サーバＥがトランザクションに登録するときにはサーバＥはその登録要求をプロセスＤに送らなければならないことを知らせる（これによりサーバＥは次に登録プロセスの線形連鎖の最後に置かれる）。
【００４９】
本発明の好適な実施形態を、オブジェクト指向プログラミング環境で説明したが、本発明は非オブジェクト指向プログラミング環境にも適用することができる。
【００５０】
添付の請求の範囲において、用語「装置」は、マシンまたはマシン上で実行するプロセスのどちらともすることができる。
【００５１】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００５２】
（１）クライアント／サーバ・トランザクション処理システムに使用するコンピューティング装置であって、
サーバ・データ処理装置がサーバ・データ処理装置にとって局所的な資源をトランザクションに登録するように要求するために登録要求を送るべきコンピューティング装置の標識を含むトランザクション要求をサーバ・データ処理装置に送ってサーバ・データ処理装置が分散トランザクションの処理に関与するようになることを要求するための送信手段と、
トランザクション要求の受信に応答して登録要求を送出した装置の線形連鎖における現在の最後の装置の標識を含むトランザクション要求への応答をサーバ・データ処理装置から受け取るための受信手段と、
受信手段が受け取る応答に基づいて線形連鎖の最後の現在の装置を追跡するための維持手段と
を含み、
送信手段によってトランザクション要求と一緒にサーバ・データ処理装置に送られる標識が、前記維持手段に基づく線形連鎖の最後の現在の装置の標識であるコンピューティング装置。
（２）前記標識がトランザクション伝搬コンテキストの一部として応答に提供される、上記（１）に記載の装置。
（３）前記装置が共通オブジェクト要求ブローカ・オブジェクト・トランザクション・サービス仕様に従って実現される、上記（１）に記載の装置。
（４）前記クライアント／サーバ・システムが通信媒体としてインターネットを使用する、上記（１）に記載の装置。
（５）クライアント／サーバ・トランザクション処理システムに使用するコンピューティング装置を操作する方法であって、
サーバ・データ処理装置がサーバ・データ処理装置にとって局所的な資源をトランザクションに登録するように要求するために登録要求を送るべきコンピューティング装置の標識を含むトランザクション要求をサーバ・データ処理装置に送ってサーバ・データ処理装置が分散トランザクションの処理に関与するようになることを要求するステップと、
トランザクション要求の受信に応答して登録要求を送出した装置の線形連鎖における現在の最後の装置の標識を含むトランザクション要求への応答をサーバ・データ処理装置から受け取るステップと、
受信ステップによって受け取った応答に基づいて線形連鎖の最後の現在の装置を追跡するステップとを含み、
送信ステップによりトランザクション要求と一緒にサーバ・データ処理装置に送られる標識が、前記維持ステップに基づく線形連鎖の最後の現在の装置の標識である
方法。
（６）前記標識がトランザクション伝搬コンテキストの一部として応答に提供される、上記（５）に記載の方法。
（７）前記装置が共通オブジェクト要求ブローカ・オブジェクト・トランザクション・サービス仕様に従って実現される、上記（５）に記載の方法。
（８）前記クライアント／サーバ・システムが通信媒体としてインターネットを使用する、上記（５）に記載の方法。
（９）上記（５）の方法のステップを実行するためにマシンによって実行可能な命令のプログラムを有形に実施する、マシン可読プログラム記憶装置。
（１０）前記標識がトランザクション伝搬コンテキストの一部として応答に提供される、上記（９）に記載のプログラム記憶装置。
（１１）前記装置が共通オブジェクト要求ブローカ・オブジェクト・トランザクション・サービス仕様書に従って実現される、上記（９）に記載のプログラム記憶装置。
（１２）前記クライアント／サーバ・システムが通信媒体としてインターネットを使用する、上記（９）に記載のプログラム記憶装置。
【図面の簡単な説明】
【図１】本発明の好適な実施形態を適用することができる、オブジェクト技術を使用した周知の異種クライアント／サーバ・アーキテクチャのブロック図である。
【図２】従来のシステムに従って２つの共通トランザクション・サーバ内でインスタンス化される様々なオブジェクトを示すブロック図である。
【図３】本発明の好適な実施形態によるソフトウェア構成要素を示すブロック図である。
【図４】本発明の好適な実施形態に従ってプロセスによって実行されるステップを示す流れ図である。
【符号の説明】
３１ クライアント・アプリケーション
３２ サーバ・アプリケーションＢ
３３ 資源Ｂ１
３４ コーディネータＢ
３５ コーディネータＡ
３６ 資源Ｂ２
３７ サーバ・アプリケーションＣ
３８ コーディネータＣ
３９ 資源Ｃ１
４０ コーディネータＤ
４１ サーバ・アプリケーションＤ
４２ 資源Ｄ１

Claims (8)

1. クライアント／サーバ・トランザクション処理システムに使用するクライアント装置であって、
   前記クライアント装置からサーバ装置へ前記サーバ装置が分散トランザクションの処理に関与することを要求するトランザクション要求を送信する送信手段であって、前記トランザクション要求は、前記サーバ装置にとってローカルな資源を前記トランザクションに登録することを要求する登録要求を指示すべき前記クライアント装置の第１の標識を含んでいる、前記送信手段と、
   前記サーバ装置から前記トランザクション要求に対する応答を受信する受信手段であって、前記応答は、前記トランザクション要求の受信に応答して登録要求を既に送信したサーバ装置のうちの線形トランザクション・ツリーの現在最後のサーバ装置の第２の標識を含む、前記受信手段と、
   前記受信手段によって受信された応答に基づいて、前記線形トランザクション・ツリーの前記現在最後のサーバ装置を追跡する追跡手段を含み、
   前記第２の標識が、前記追跡手段に基づいた、前記線形トランザクション・ツリーの前記現在最後のサーバ装置の標識である、
   クライアント装置。
2. 前記第２の標識が、トランザクション伝搬コンテキストの一部として応答に提供される、請求項１に記載のクライアント装置。
3. 前記クライアント装置が、共通オブジェクト要求ブローカ・オブジェクト・トランザクション・サービス仕様に従って実現される、請求項１に記載のクライアント装置。
4. 前記クライアント／サーバ・トランザクション処理システムが、通信媒体としてインターネットを使用する、請求項１に記載のクライアント装置。
5. クライアント／サーバ・トランザクション処理システムに使用するクライアント装置を操作する方法であって、
   前記クライアント装置からサーバ装置へ前記サーバ装置が分散トランザクションの処理に関与することを要求するトランザクション要求を送信するステップであって、前記トランザクション要求は、前記サーバ装置にとってローカルな資源を前記トランザクションに登録することを要求する登録要求を指示するべき前記クライアント装置の第１の標識を含んでいる、前記送信するステップと、
   前記サーバ装置から前記トランザクション要求に対する応答を受信するステップであって、前記応答は、前記トランザクション要求の受信に応答して登録要求を既に送信したサーバ装置のうちの線形トランザクション・ツリーの現在最後のサーバ装置の第２の標識を含む、前記受信するステップと、
   前記受信するステップによって受信された応答に基づいて、前記線形トランザクション・ツリーの前記現在最後のサーバ装置を追跡するステップとを含み、
   前記第２の標識が、前記追跡するステップに基づいた、前記線形トランザクション・ツリーの前記現在最後のサーバ装置の標識である、
   方法。
6. 前記第２の標識が、トランザクション伝搬コンテキストの一部として応答に提供される、請求項５に記載の方法。
7. 前記クライアント装置が、共通オブジェクト要求ブローカ・オブジェクト・トランザクション・サービス仕様に従って実現される、請求項５に記載の方法。
8. 前記クライアント／サーバ・トランザクション処理システムが、通信媒体としてインターネットを使用する、請求項５に記載の方法。

Images