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