JP3628577B2 - サーバ・データ処理装置、操作方法および記憶装置 - Google Patents
サーバ・データ処理装置、操作方法および記憶装置 Download PDFInfo
- Publication number
- JP3628577B2 JP3628577B2 JP2000039363A JP2000039363A JP3628577B2 JP 3628577 B2 JP3628577 B2 JP 3628577B2 JP 2000039363 A JP2000039363 A JP 2000039363A JP 2000039363 A JP2000039363 A JP 2000039363A JP 3628577 B2 JP3628577 B2 JP 3628577B2
- Authority
- JP
- Japan
- Prior art keywords
- data processing
- server data
- server
- machine
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
- G06F9/548—Object oriented; Remote method invocation [RMI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Description
【０００１】
【発明の属する技術分野】
本発明は、１つのコンピューティング装置（「クライアント」）が別のコンピューティング装置（「サーバ」）にクライアントの作業の一部を実行するように要求する、クライアント／サーバ（「分散」としても知られる）コンピューティングの分野に関する。クライアントおよびサーバは両方とも、同一の物理的コンピューティング装置に配置することもできる。
【０００２】
【従来の技術】
クライアント／サーバ・コンピューティングは、情報技術の世界において過去数年間でますます重要になってきた。この種の分散コンピューティングは、１つのマシンがその作業の一部を、例えばその作業を実行するのにより適している別のマシンに委ねることを可能にする。例えば、サーバは、大量のデータの記憶を管理するデータベース・プログラムを実行する高能力コンピュータとすることができる一方、クライアントは単に、そのローカル・プログラムの１つで使用するためにデータベースからの情報を要求するデスクトップ・パーソナル・コンピュータ（ＰＣ）である。
【０００３】
クライアント／サーバ・コンピューティングの利点は、クライアントおよびサーバを異なる（異種）「プラットフォーム」に配置することを可能にする、オブジェクト指向プログラミング（ＯＯＰ）と呼ばれる周知のコンピュータ・プログラミング技術の使用によってさらに増強されてきた。プラットフォームとは、マシンがその作業を行うために使用する特定のハードウェア／ソフトウェア／オペレーティング・システム／通信プロトコルの組合せである。ＯＯＰは、クライアント・アプリケーション・プログラムの作業要求がどのようにサーバ・アプリケーション・プログラムによって交信され受け入れられるかを気にすることなく、クライアント・アプリケーション・プログラムおよびサーバ・アプリケーション・プログラムがそれ自体のプラットフォームで動作することを可能にする。同様にサーバ・アプリケーションは、ＯＯＰシステムがどのようにサーバ・アプリケーションの処理結果を受け取り、変換し、要求側クライアント・アプリケーションに返送するかを気にする必要がない。
【０００４】
ＯＯＰ技術が異種クライアント／サーバ・システムとどのように統合されてきたかの詳細は、米国特許第５４４０７４４号および欧州特許公開出願ＥＰ ０ ６７７９４３ Ａ２号に説明されている。これら２件の刊行物を参照によって本明細書に組み込む。しかし、本発明の環境の背景理解のために、基本的アーキテクチャの１例を以下で取り上げる。
【０００５】
図１に示すように、クライアント・コンピュータ１０（例えばＩＢＭ ＯＳ／２オペレーティング・システムを搭載したパーソナル・コンピュータとすることができる）は、そのオペレーティング・システム上で実行するアプリケーション・プログラム４０を有する（「ＩＢＭ」および「ＯＳ／２」はＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ社の商標）。アプリケーション・プログラム４０は定期的に、サーバ・コンピュータ２０上で作業を実行するように、かつ／または後でアプリケーション・プログラム４０で使用するためにデータをサーバ２０から返送するように要求する。サーバ・コンピュータ２０は、例えばＩＢＭのＭＶＳオペレーティング・システム上で実行する高性能メインフレーム・コンピュータとすることができる（「ＭＶＳ」もＩＢＭ社の商標）。本発明の場合、サーバによって実行される通信サービスの要求が、第１アプリケーション・プログラム４０とのユーザの対話によって引き起こされるか、それともアプリケーション・プログラム４０がユーザの対話に関係なく動作して、プログラムの実行中に自動的に要求を行うかは関係ない。
【０００６】
クライアント・コンピュータ１０がサーバ・コンピュータ２０のサービスを要求したいときに、第１アプリケーション・プログラム４０は、必要とするサービスについて第１論理手段５０に通知する。これは、例えば、第１論理手段に遠隔手順の名前を入出力パラメータのリストと共に送ることによって、実行することができる。次いで第１論理手段５０は、記憶装置６０に格納された利用可能な通信サービスの定義を参照して、第２コンピュータ２０との必要な通信を確立するタスクを処理する。可能なサービスはすべて、オブジェクト・クラス７０のコヒーシブ・フレームワークとして定義されており、これらのクラスは単一オブジェクト・クラスから導出される。このようにしてサービスを定義すると、性能および再使用可能性の点で多数の利点が得られる。
【０００７】
サーバ２０との必要な通信を確立するために、第１論理手段５０はフレームワーク内のどのオブジェクト・クラスを使用する必要があるかを判定し、次いで、サーバにおいて、そのオブジェクトのインスタンス、つまりそのオブジェクトにそのメソッドの１つを呼び出させるためにそのオブジェクトに送信されるメッセージを形成する。これにより、接続手段８０を介してサーバ・コンピュータ２０との接続の確立が生じ、続いて要求が第２論理手段９０に送信される。
【０００８】
次いで第２論理手段９０が要求を、サーバ・コンピュータ２０で実行している第２アプリケーション・プログラム１００（以下、サービス・アプリケーションという）に渡すので、サービス・アプリケーション１００は、データ検索手順を実行するなど、その要求によって要求される特定のタスクを実行することができる。このタスクが完了すると、サービス・アプリケーションは、結果を第１コンピュータ１０に返送する必要があるかもしれない。要求されたタスクの実行中、および結果が第１コンピュータ１０に返送される際、サーバ・アプリケーション１００は第２論理手段９０と対話する。第２論理手段９０はオブジェクトのインスタンスを決定し、サーバ・アプリケーション１００によって要求されたときにこれらのオブジェクトの適切なメソッドを呼び出し、記憶装置１１０に格納されたオブジェクト・クラスのコヒーシブ・フレームワークからオブジェクト・インスタンスが形成される。
【０００９】
上記の技術を使用すると、クライアント・アプリケーション・プログラム４０は通信アーキテクチャにさらされない。さらに、サービス・アプリケーション１００が、その環境の標準機構を介して呼び出される。つまり、それは遠隔的に呼び出されていることを認識しない。
【００１０】
オブジェクト管理グループ（ＯＭＧ）は、図１に示すような分散オブジェクトを持つ異種プラットフォームでのクライアント／サーバ・コンピューティングの様々な側面に関与する組織の国際的コンソーシアムである。ＯＭＧは、クライアント・コンピュータ（例えば１０）がサーバ・マシン（例えば２０）と（ＯＯＰの形で）通信するための標準を規定し発行した。これらの標準の一環として、クライアント・マシンとサーバ・マシンの間にオブジェクト指向ブリッジを提供するオブジェクト要求ブローカ（ＣＯＲＢＡつまり共通オブジェクト要求ブローカ・アーキテクチャと呼ばれる）が定義された。ＯＲＢは、オブジェクト指向実装の詳細からクライアント・アプリケーションおよびサーバ・アプリケーションを切り離し、第１および第２論理手段５０、９０ならびに接続手段８０の作業の少なくとも一部分を実行する。
【００１１】
ＣＯＲＢＡソフトウェア構造の一部として、ＯＭＧは「トランザクション」に関連する標準を規定した。これらの標準は、ＯＴＳつまりオブジェクト・トランザクション・サービスとして知られる。例えば、ＯＭＧ文書９４．８．４、ＣＯＲＢＡオブジェクト・トランザクション・サービス仕様１．０を参照されたい。コンピュータによって実装されるトランザクション処理システムは、いくつかの産業において重要なビジネス・タスクに使用される。トランザクションは、完全に終了しなければならないか、または動作せずに完全にパージしなければならない単一作業単位を定義する。例えば、銀行の現金自動預け払い機で顧客が現金を引き出そうとする場合、現金を払い出し、機械内にある現金の残高を差し引き、顧客の銀行預金残高を差し引く動作が全部行われるか、またはそれらが全く行われないかのいずれかでなければならない。下位動作の１つが失敗すると、記録と実際のオカレンスの不一致が生じる。
【００１２】
分散トランザクション処理は、複数の物理位置または論理位置における資源に影響するトランザクションを伴う。上記の例では、トランザクションは、局所現金自動預け払い機で管理される資源に影響するだけでなく、銀行のメイン・コンピュータによって管理される銀行預金残高にも影響する。そのようなトランザクションは、サーバによって処理される一連のクライアント要求により１つの特定のサーバ・コンピュータ（例えば２０）と通信する１つの特定のクライアント・コンピュータ（例えば１０）を伴う。ＯＭＧのＯＴＳは、これらの分散トランザクションを調整する責任がある。
【００１３】
クライアント・プロセスで実行するアプリケーションは、複数の様々なサーバの呼出しを含むトランザクションを始動し、それぞれのサーバはサーバ・プロセスを起動して、トランザクションに含まれる命令に従ってそのローカル・データを変更する。トランザクションを実行する（したがってすべてのサーバがそれらのローカル・データの変更を終了する）か、またはトランザクションを打ち切る（したがってすべてのサーバがトランザクション中に行われたそれらのローカル・データの変更を「撤回」または無視する）かのいずれかによって、トランザクションは終了する。トランザクション中にサーバと通信する（例えばそれらにトランザクションにおけるそれらの役割を実行するかまたは打ち切るように命令する）ために、含まれるプロセスの１つはトランザクションのための状態データを維持しなければならない。ＯＴＳ標準によると、これは一連のオブジェクトをセットアップするプロセスを含み、そのうちの１つは、様々なサーバに関してトランザクションを調整するコーディネータ・オブジェクトである。
【００１４】
このコーディネータ・オブジェクトの主な目的は、どのサーバ・オブジェクトがトランザクションに関与しているかを追跡し続けて、トランザクションが終了したときに、トランザクションに関与する各サーバ・オブジェクトに、１回の統一された努力で、そのサーバ・オブジェクトに関連するローカル・データベースに局所的に行われた変更をコミットするように命令することができるようにすることである。これにより、どのサーバ・オブジェクトも、同一トランザクションに関与する他のサーバ・オブジェクトなしでは、データ変更を最終決定しないことが保証される。したがって、トランザクションに参加する各サーバ・オブジェクトは最初にコーディネータ・オブジェクトに登録して、コーディネータ・オブジェクトがサーバ・オブジェクトの存在、トランザクションへの参加の希望、およびトランザクションを終了する時が来たときにサーバ・オブジェクトがどこにあるか（例えばサーバ・オブジェクトがどのサーバ・マシンに常駐しているか）が分かるようにしておかなければならない（コーディネータ・オブジェクトはすべてのサーバ・オブジェクトにそれぞれのローカル・データの変更を最終決定するように命令する）。
【００１５】
データを更新する責任のあるサーバ・オブジェクト（以下、資源オブジェクトという）は、別のサーバ・オブジェクト（またはトランザクションを開始した元のクライアント・オブジェクト）が資源オブジェクトに何らかの作業をするように資源オブジェクトに要求を送ったときに、トランザクションに関与するようになる。この後者の要求は、要求がトランザクションの一部であることを資源オブジェクトに知らせる、トランザクション・コンテキストと呼ばれる何らかの情報を含む。資源オブジェクトはそれがトランザクションに関与するようになることを認識すると、コーディネータ・オブジェクトに登録要求を行う。
【００１６】
資源オブジェクトが、コーディネータ・オブジェクトとは異なるオペレーティング・システム・プロセスに配置されている場合、従来技術（例えば、１９９７年に発売されたＩＢＭのコンポーネント・ブローカ・ソフトウェア製品におけるＩＢＭによる実装をはじめとするＣＯＲＢＡのＯＴＳ標準）で、資源オブジェクト（２２３または２２４）と同じオペレーティング・システム・プロセスに配置された下位コーディネータ・オブジェクト（図２の２２２）を使用すると便利であることが明らかになった。その場合、主コーディネータ・オブジェクトを「上位コーディネータ・オブジェクト」２１１と呼ぶ。資源オブジェクト２２３のトランザクションへの登録中に、下位コーディネータ２２２は資源オブジェクト２２３を収容しているサーバ・マシン２２内で局所的にセットアップされ、資源オブジェクト２２３は登録要求を行うときに、この下位コーディネータ・オブジェクト２２２と直接やり取りする。（ここでは用語「サーバ・マシン」を使用しているが、分散サーバ・オブジェクトを実際には、同じサーバ・マシンであるがそのサーバ・マシン上で実行している別のオペレーティング・システム・プロセスに配置することもできることを示すために、用語「サーバ・プロセス」を使用することもできることに留意されたい。したがって、以下では、用語「サーバ」は、両方の用語を指すのに使用する。）次に下位コーディネータ２２２はそれ自体を、上位コーディネータ・オブジェクト２１１（あたかも資源オブジェクトであるかのように、おそらく別のサーバ・マシン上の別のプロセスに配置されている）に登録する。
【００１７】
下位コーディネータ・オブジェクト２２２はこのようにして、資源オブジェクトを収容しているサーバ内におけるトランザクションの存在を表現する。上位コーディネータ・オブジェクト２１１と直接やり取りする代わりに、資源オブジェクト２２３、２２４は最初にそれらのローカル下位コーディネータ・オブジェクト２２２とやり取りし、次にこれが上位コーディネータ・オブジェクトとやり取りする。これにより、オペレーティング・システム・プロセス間の相互呼出し回数が大幅に減少する。
【００１８】
【発明が解決しようとする課題】
この従来技術のアーキテクチャでは、結果的に生じる非効率性が依然として多く存在する。例えば、トランザクションに関与する２つのマシンがあり、１つのマシンはビジネス論理を含み、別のマシンはデータ論理を含むと仮定する。上位コーディネータは、ビジネス論理を含むマシン上で実行するプロセスにセットアップされ、資源オブジェクトはデータ論理を含むマシンに配置される。データ論理を含むマシンはその中で実行する２つのサーバ・プロセスを持ち、そのようなプロセスがそれぞれ、分散トランザクションに関与する資源オブジェクトを有する。したがって、各サーバ・プロセスに１つずつ、２つの分離した下位コーディネータがセットアップされる。データ論理を含むマシン内の各下位コーディネータは次に、トランザクションを処理するために、ビジネス論理を含むマシン内の上位コーディネータにマシン間メッセージ（例えばＴＣＰ／ＩＰを使用して）を送る。このように、従来技術のこのソフトウェア・アーキテクチャでは、発生するマシン間データ・フローが依然として多数存在する。
【００１９】
【課題を解決するための手段】
第１の態様によれば、本発明は、複数のサーバ・データ処理装置によって実行される分散トランザクションを調整する際に使用する第１サーバ・データ処理装置であって、第２サーバ・データ処理装置から登録要求を受け取る手段と、登録要求を送った第２サーバ・データ処理装置のマシン・アドレスを決定する手段と、第１装置に登録要求を送るサーバ・データ処理装置のマシン・アドレスのリストを維持する手段と、アウトバウンド・トランザクション要求の宛先マシン・アドレスを決定する手段と、アウトバウンド・トランザクション要求の宛先マシン・アドレスが前記維持手段によって維持されるマシン・アドレスのリストに含まれるかどうかを判定する手段と、アウトバウンド・トランザクション要求の宛先マシン・アドレスが前記維持手段によって維持されるマシン・アドレスのリスト内に含まれる場合には、第１サーバ装置上に位置するトランザクション・コーディネータを識別するアウトバウンド・トランザクション要求内の識別子を、アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ装置上に位置するトランザクション・コーディネータを識別する識別子で代用する手段とを備える第１サーバ・データ処理装置を提供する。
【００２０】
第２の態様によれば、本発明は、第１の態様に関して上述した機能を実行する方法を提供する。
【００２１】
第３の態様によれば、本発明は、コンピュータ可読記憶媒体に格納されたコンピュータ・プログラムであって、コンピュータ上で実行するときに、本発明の第２の態様に記載した方法を実行するためのプログラム要素を有するプログラムを提供する。
【００２２】
したがって、本発明は同一マシン上に配置された１群の下位コーディネータを統合するので、１つのそうした下位コーディネータだけが、マシン間データを介して上位コーディネータ（これは別のマシンで実行している）と直接やり取りする必要がある。このため、それがなければ必要になるマシン間データ転送の回数が大幅に減少する。
【００２３】
【発明の実施の形態】
本発明の好適な実施形態を例示するために、第１層がクライアント・マシンの対トランザクション・インタフェースであり（そのような層は一般的にパーソナル・コンピュータ・ワークステーション上で実行する）、第２層が一般的に部門サーバ・レベルに常駐するビジネス論理層であり、第３層が一般的にデータベース・サーバとして使用されるマシン（単数または複数）に常駐するデータ論理層である、３層分散トランザクション処理アーキテクチャの典型例を使用する。
【００２４】
図３で、サーバ・マシン３１は、上位コーディネータ・オブジェクト３１１を含むプロセスを実行している。例えば、このプロセスは、以前にトランザクション開始要求（またはコマンド）をサーバ・マシン３１に送った第１層のクライアント・マシン（図示せず）によって開始された分散トランザクションを実行するためのビジネス論理の第２層処理に含まれる。
【００２５】
第２サーバ・マシン３２は、分散トランザクションを実行するための第３層のデータ論理の処理にそれぞれ含まれる３つの異なるプロセス３２１、３２２、３２３を実行している。プロセス３２１では、下位コーディネータ・オブジェクト３２１１が、トランザクションにそれぞれ含まれる資源オブジェクト３２１２、３２１３と直接やり取りする。プロセス３２２では、下位コーディネータ３２２１が、トランザクションに含まれる資源オブジェクト３２２２と直接やり取りする。プロセス３２３では、下位コーディネータ・オブジェクト３２３１が、トランザクションにそれぞれ含まれる資源オブジェクト３２３２、３２３３、３２３４と直接やり取りする。
【００２６】
従来技術では、分散トランザクションの処理中に、各下位コーディネータ３２１１、３２２１、３２３１が、別個のマシン間データ・フローを上位コーディネータ・オブジェクト３１１に送る。本発明の好適な実施形態では、下位コーディネータ・オブジェクト３２２１、３２３１はそれらのトランザクション結果を下位コーディネータ３２１１に受け渡し、これは次にそうした結果をオブジェクト３２１１自体の結果と共に、マシン３１の上位コーディネータ・オブジェクト３１１に中継する。したがって、これはマシン間データ・フローの回数を著しく削減し、その代わりに同一マシン上でのプロセス間データ・フローだけが必要であるが、これは、例えばリモートＴＣＰ／ＩＰ接続を実行する必要がないので（プロセスが同一マシン上で実行しているので）、ずっと速く実行される。
【００２７】
同一マシン上に位置する下位コーディネータ・オブジェクトが、マシンの境界を超えて上位コーディネータ・オブジェクトに集合データ・フローを送る前に、それらのトランザクション・データ・フローをいかにして集めるかについて、今から説明する。
【００２８】
上位コーディネータ３１１を含むサーバ・マシン・プロセスは、
１）上位コーディネータ・オブジェクト３１１に登録されたリモート下位コーディネータ（つまり３２１１、３２２１、３２３１）のホスト・マシン位置を決定し、
２）次に、アウトバウンド・トランザクション要求（例えばビジネス論理層からデータ論理層へ送られる要求）の宛先ホスト・マシンを決定し、
３）アウトバウンド要求の宛先に局所的（ローカル）に（つまり同一マシン上に）すでに形成された下位コーディネータがある場合には、次に、アウトバウンド要求を伴う伝搬コンテキスト内のトランザクションの上位コーディネータのオブジェクト参照の代わりに、目標オブジェクトと「同一マシン上の（マシン・ローカルな，ｍａｃｈｉｎｅ−ｌｏｃａｌ）」リモート下位コーディネータのオブジェクト参照を代用する
ことによってこれを達成する。
【００２９】
好適な実施形態では、ストリング化オブジェクト参照に指定されたフォーマットの構造を使用する。ｏｂｊｅｃｔ＿ｔｏ＿ｓｔｒｉｎｇと呼ばれるすべてのＣｏｒｂａオブジェクトで動作する方法を提供する。この方法は、ｓｔｒｉｎｇ＿ｔｏ＿ｏｂｊｅｃｔを使用して保管し、他のシステム等に渡し、オブジェクト参照に送り返すことができるストリング・バージョンのオブジェクト参照を生成する。
【００３０】
実際には、ストリングは事実上、オブジェクトのためのストリング形式の相互運用可能なオブジェクト参照（ＩＯＲ）である。そのようなＣＯＲＢＡ：：ＩＯＰ：：ＩＯＲ構造は、ＣＯＲＢＡ ２．０仕様に完全に規定されている。これらのフォーマットは、ＯＲＢによって使用される特定のトランスポート・メカニズムのＣＯＲＢＡ ＩＯＰプロトコルによって完成されたときに、Ｃｏｒｂａ ２．０一般Ｉｎｔｅｒ−Ｏｒｂプロトコル（ＧＩＯＰ）によって記述される。
【００３１】
ＩＩＯＰ ＯＲＢのＩＯＲの一部分は、ホスト・マシンのＩＰアドレスである。したがって、オブジェクト参照からホスト・マシンを決定することは簡単である（これが、そのオブジェクト参照を使用してリモート・オブジェクトに方法を送ることを可能にするメカニズムであり、ＯＲＢは参照からホストおよびポートを抽出し、要求を処理のためにリモート・システムに送る）。
【００３２】
アプリケーション（またはトランザクション・サービス）から見て、これは、内部ＯＲＢ法を使用することなく行うことができる。つまり、単にｏｂｊ．ｏｂｊｅｃｔ＿ｔｏ＿ｓｔｒｉｎｇを呼び出し、Ｃｏｒｂａ ２．０仕様に埋め込まれたデータ・フォーマットを使用してストリングを調べて、ホスト・アドレスを得ることができる。別法として、希望するなら、同じことを行う提供された内部ＯＲＢ機能の知識を使用することもでき、すなわちＯＲＢの内部コードによって、おそらく、より効率的に行うことができるであろう。
【００３３】
本発明の好適な実施形態では、要求がプロセス間を流れるときに、トランザクション・サーバ間で受け渡される伝搬コンテキストを新規に利用する。詳しくは、我々は、登録された資源を有しかつそれがその上位コーディネータに資源を登録している、下位コーディネータからの要求に関心がある。我々がここで関心を持つのは応答で返されるコンテキストであるので、この流れの中で、伝搬コンテキストは通常「再開」を目的とするトランザクション情報を含まない。しかし、この伝搬コンテキストは、「実装特有の」目的のために使用できるデータ領域を含む。それはまたその中に、ＴｒａｎｓＩｄｅｎｔｉｔｙフィールド内にコーディネータ参照のためのスロット（応答フローでは使用されない）を含む。
【００３４】
下位コーディネータから上位コーディネータへのこの登録要求により、我々は、登録作業を実行するプロセスで形成される新しい下位コーディネータのオブジェクト参照を伝搬コンテキスト内に入れる。（伝搬コンテキスト内のどちらのデータ領域も使用することができる。大して重要ではないが、応答の「検査済みトランザクション」検査がｏｔｉｄトランザクションｉｄを使用して行われるとき、我々はそれを安全にＴｒａｎｓＩｄｅｎｔｉｔｙ構造のコーディネータ・スロットに入れることができる。）
【００３５】
ｒｅｇｉｓｔｅｒ＿ｒｅｓｏｕｒｃｅ要求の均等物が要求からの応答に便乗する「遅延登録」の場合に、同様のプロセスを使用することができる。
【００３６】
上位コーディネータ（例えば３１１）を含むプロセスで要求を受け取ると、「受け取られた要求」の標準ｏｒｂインタセプタがすでに目標オブジェクトの型および伝搬コンテキストを調べる。単純な拡張により、インタセプタは、送り出しプロセスからリモート・コーディネータのオブジェクト参照を抽出することができる。
【００３７】
Ｃｏｏｒｄｉｎａｔｏｒ：：ｒｅｇｉｓｔｅｒ＿ｒｅｓｏｕｒｃｅインタフェース・メソッドは、資源登録がそれに関連し対応するリモート下位コーディネータ参照を有するかどうか検査するように拡張される。そうである場合、登録を処理するコーディネータは、下位コーディネータのオブジェクト参照を抽出する。コーディネータはオブジェクト参照を調べて、それが形成されたホストのＩＰアドレスを決定する。（これは、所望する場合には、上記参照と一緒に簡単に受け渡すことができる。）
【００３８】
コーディネータは、トランザクションに含まれるそのようなリモート下位トランザクション・コーディネータの表を維持する。表は、ＩＰアドレスから、これらのリモート・マシン・ホストにすでに構築されておりトランザクションに関連するコーディネータ参照へのマッピングである。一般的にこの表は小さいので、性能オーバヘッドが大きくなる可能性は全くない。
【００３９】
最終ステップが必要である。現在、ｓｅｎｄｉｎｇ＿ｒｅｑｕｅｓｔ ＯＲＢインタセプタでは、トランザクション要求がリモート・サーバに流れるとき、ローカル（上位）コーディネータの参照が伝搬コンテキスト内に置かれる。したがって現在、トランザクションへの関与および資源の登録は、グローバル分散トランザクション・ツリーに接続するために、このサーバに戻ってくる。上述のステップを前提にして、今やｓｅｎｄｉｎｇ＿ｒｅｑｕｅｓｔ ＯＲＢインタセプタが上述のように目標オブジェクトのホスト・マシンＩＰアドレスを抽出し（目標オブジェクトがＣｏｓｔｒａｎｓａｃｔｉｏｎｓ：：ＴｒａｎｓａｃｔｉｏｎａｌＯｂｊｅｃｔであるかどうかを判定するためにすでにそれにアクセスしている）、すでに形成されているそのリモート下位コーディネータの表を参照することは、単純なプロセスである。したがって、要求が流れていく先の目標オブジェクトと同一マシン上にすでに存在するトランザクションに関係する下位コーディネータがあるかどうかを判定する。
【００４０】
目標オブジェクト・マシン上に登録されたコーディネータがすでにある場合には、伝搬コンテキストでそれ自体のオブジェクト参照を送り出す代わりに、上位コーディネータは、すでに目標オブジェクトと同一マシン上に「局所的に」存在する下位コーディネータのオブジェクト参照を代用する。そのトランザクション・フローの結果、何らかの資源登録の関与が生じた場合、それらが自動的に同一マシン上の下位コーディネータに流れる。
【００４１】
手短に述べると、登録要求を受け取ったときに、上位コーディネータ・オブジェクト３１１を含むサーバ・マシン３１が実行するステップは、図４の流れ図に示されている。
【００４２】
ステップ４１で、サーバ・マシン３１はサーバ・マシン３２から登録要求を受け取る。ステップ４２で、サーバ・マシン３１はサーバ・マシン３２のマシン・アドレス（例えばＩＰアドレス）を決定する。ステップ４３で、サーバ・マシン３１はサーバ・マシン３２のマシン・アドレスを、どのサーバ・マシンがサーバ・マシン３１に登録要求を送ったかを追跡するリストに付加する。
【００４３】
さらに、アウトバウンド・トランザクション要求（上位コーディネータ・オブジェクト３１１を含むサーバ・プロセスの外部のプロセス宛てに送られる要求）を受け取ったときに、上位コーディネータ・オブジェクト３１１を含むサーバ・マシン３１で実行しているサーバ・プロセスによって実行されるステップを、図５の流れ図に示す。コーディネータ・オブジェクト３１１を含むプロセスを以下ではアウトバウンド・トランザクション要求を「受け取る」ことと述べるが、本発明の実施形態によっては、このプロセスは、内部でプロセスへの要求を生成することもできる。しかし、プロセスが別のプロセスからアウトバウンド要求を受け取るのが、より普通のケースである。
【００４４】
ステップ５１で、サーバ・マシン３１は、異なるサーバ・マシン上の資源にアクセスし、したがってトランザクションに関係することを指定するアウトバウンド・トランザクション要求を（例えば、図示しないがクライアント・マシンから、またはサーバ・マシン３１上で実行しているクライアント・プロセスから、または別のサーバ・プロセスから）受け取る。ステップ５２で、サーバ・マシン３１はアウトバウンド・トランザクション要求の宛先マシン・アドレスを決定する。例えば、アウトバウンド要求が、トランザクションの一部としてサーバ・マシン３２に位置する資源オブジェクトにアクセスすることを要求している場合には、アウトバウンド・トランザクション要求の宛先マシン・アドレスは、サーバ・マシン３２のアドレスである。
【００４５】
ステップ５３で、サーバ・マシン３１は、アウトバウンド要求の宛先マシン・アドレスが、図４のステップ４３で付加されたリストに含まれるかどうかを判定する。つまり、サーバ・マシン３１が、アウトバウンド・トランザクション要求内で識別されている宛先サーバ・マシンから以前に登録要求を受け取ったことがあるかどうか（例えばステップ４１）、判定が行われる。我々の例では、宛先サーバ・マシン３２は実際にサーバ・マシン３１に登録要求を送ったことがある。アウトバウンド要求の宛先マシン・アドレスがリストに含まれる場合（我々の例の場合のように）、サーバ・マシン３１は、上位コーディネータの識別子の代りに、アウトバウンド要求の宛先マシンに局所的な下位コーディネータの識別子を代用する。あるいは、アウトバウンド要求の宛先マシン・アドレスがリストに含まれていない場合、上位コーディネータの識別子がアウトバウンド要求内に残される。
【００４６】
この代用を実行する（ステップ５３のＹＥＳ分岐に従う）ことにより、まだ上位コーディネータ３１１に登録要求を行っていないが、すでに上位コーディネータ３１１に登録要求を行った別の下位コーディネータ３２１１と同一サーバ・マシン３２上に位置する下位コーディネータ３２２１は、データ・フローを上位コーディネータ３１１に直接送る代わりに、そうしたデータ・フローを下位コーディネータ３２１１に送る。これにより、マシン相互のデータ・フローの数が著しく減少し、したがってネットワーク・トラヒックの量が大幅に低下する。
【００４７】
本発明の好適な実施形態は、上述のようないくつかの様々なステップを含むが、そのいずれも設計または実装の努力、実行システムのＣＰＵサイクル、またはネットワーク・トラヒックの点からみて高価ではない。
【００４８】
結果は、「三層（スリー・ティア）」アーキテクチャの分散の非常に一般的なシナリオになると考えられるＩＢＭのコンポーネント・ブローカ製品などの分散コストランザクション・システムにおける典型的なビジネス・トランザクションの実行において、マシン間メッセージの数を大幅に減少する。
【００４９】
その上、講じられるステップの結果、現在構築されているものよりコミット・ツリーの最適度が低下することは決してなく、また試みられた最適化により利益が得られるか否かに関係なく、含まれる処理が実行システムに及ぼす性能上の影響は最小限である。
【００５０】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００５１】
（１）複数のサーバ・データ処理装置によって実行される分散トランザクションの調整に使用される第１サーバ・データ処理装置であって、
第２サーバ・データ処理装置から登録要求を受け取る手段と、
登録要求を送った前記第２サーバ・データ処理装置のマシン・アドレスを決定する手段と、
前記第１装置に登録要求を送るサーバ・データ処理装置のマシン・アドレスのリストを維持する手段と、
アウトバウンド・トランザクション要求の宛先マシン・アドレスを決定する手段と、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが、前記維持手段によって維持されるマシン・アドレスのリストに含まれるかどうかを判定する手段と、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが前記維持手段によって維持されるマシン・アドレスのリストに含まれる場合、前記第１サーバ装置上に位置するトランザクション・コーディネータを識別するアウトバウンド・トランザクション要求内の識別子を、前記アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ装置上に位置するトランザクション・コーディネータを識別する識別子で代用する手段と
を含む第１サーバ・データ処理装置。
（２）前記第１サーバ装置上に位置するトランザクション・コーディネータが上位コーディネータであり、前記アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ装置上に位置するトランザクション・コーディネータが下位コーディネータである、上記（１）に記載の装置。
（３）分散トランザクションが前記サーバ装置により共通オブジェクト要求ブローカ・アーキテクチャのオブジェクト・トランザクション・サービスの実現を通じて実行される、上記（１）に記載の装置。
（４）前記複数のサーバ・データ処理装置がインターネットを介して相互接続される、上記（１）に記載の装置。
（５）前記マシン・アドレスがインターネット・プロトコル・アドレスによって指定される、上記（４）に記載の装置。
（６）複数のサーバ・データ処理装置によって実行される分散トランザクションの調整に使用される第１サーバ・データ処理装置を操作する方法であって、
第２サーバ・データ処理装置から登録要求を受け取るステップと、
登録要求を送る前記第２サーバ・データ処理装置のマシン・アドレスを決定するステップと、
前記第１装置に登録要求を送るサーバ・データ処理装置のマシン・アドレスのリストを維持するステップと、
アウトバウンド・トランザクション要求の宛先マシン・アドレスを決定するステップと、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが、前記維持ステップによって維持されるマシン・アドレスのリストに含まれるかどうかを判定するステップと、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが前記マシン・アドレスのリストに含まれる場合、前記第１サーバ装置上に位置するトランザクション・コーディネータを識別するアウトバウンド・トランザクション要求内の識別子を、前記アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ装置上に位置するトランザクション・コーディネータを識別する識別子で代用するステップと
を含む方法。
（７）前記第１サーバ装置上に位置するトランザクション・コーディネータが上位コーディネータであり、前記アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ装置上に位置するトランザクション・コーディネータが下位コーディネータである、上記（６）に記載の方法。
（８）分散トランザクションが前記サーバ装置により共通オブジェクト要求ブローカ・アーキテクチャのオブジェクト・トランザクション・サービスの実現を通じて実行される、上記（６）に記載の方法。
（９）前記複数のサーバ・データ処理装置がインターネットを介して相互接続される、上記（６）に記載の方法。
（１０）前記マシン・アドレスがインターネット・プロトコル・アドレスによって指定される、上記（９）に記載の方法。
（１１）上記（６）の方法ステップを実行するためのマシンによって実行可能な命令のプログラムを記憶したマシン可読プログラム記憶装置。
【図面の簡単な説明】
【図１】本発明の好適な実施形態を適用することができる文脈における、オブジェクト技術を使用した周知の異種クライアント／サーバ・アーキテクチャのブロック図である。
【図２】本発明の好適な実施形態を適用することができる文脈における、従来の設計に従って２つの共通トランザクション・サーバ内でインスタンス化される様々なオブジェクトを示すブロック図である。
【図３】本発明の好適な実施形態に従って２つの共通トランザクション・サーバ内でインスタンス化される様々なオブジェクトを示す別のブロック図である。
【図４】本発明の好適な実施形態に従って、サーバ内に含まれるステップを示す流れ図である。
【図５】本発明の好適な実施形態に従って、サーバ内に含まれるステップを示す流れ図である。
【符号の説明】
３１ サーバ・マシン
３２ 第２サーバ・マシン
３１１ 上位コーディネータ・オブジェクト
３２１ プロセス
３２２ プロセス
３２３ プロセス
３２１１ 下位コーディネータ・オブジェクト
３２２１ 下位コーディネータ・オブジェクト
３２２２ 資源オブジェクト
３２３１ 下位コーディネータ・オブジェクト
３２３２ 資源オブジェクト
３２３３ 資源オブジェクト
３２３４ 資源オブジェクト
【発明の属する技術分野】
本発明は、１つのコンピューティング装置（「クライアント」）が別のコンピューティング装置（「サーバ」）にクライアントの作業の一部を実行するように要求する、クライアント／サーバ（「分散」としても知られる）コンピューティングの分野に関する。クライアントおよびサーバは両方とも、同一の物理的コンピューティング装置に配置することもできる。
【０００２】
【従来の技術】
クライアント／サーバ・コンピューティングは、情報技術の世界において過去数年間でますます重要になってきた。この種の分散コンピューティングは、１つのマシンがその作業の一部を、例えばその作業を実行するのにより適している別のマシンに委ねることを可能にする。例えば、サーバは、大量のデータの記憶を管理するデータベース・プログラムを実行する高能力コンピュータとすることができる一方、クライアントは単に、そのローカル・プログラムの１つで使用するためにデータベースからの情報を要求するデスクトップ・パーソナル・コンピュータ（ＰＣ）である。
【０００３】
クライアント／サーバ・コンピューティングの利点は、クライアントおよびサーバを異なる（異種）「プラットフォーム」に配置することを可能にする、オブジェクト指向プログラミング（ＯＯＰ）と呼ばれる周知のコンピュータ・プログラミング技術の使用によってさらに増強されてきた。プラットフォームとは、マシンがその作業を行うために使用する特定のハードウェア／ソフトウェア／オペレーティング・システム／通信プロトコルの組合せである。ＯＯＰは、クライアント・アプリケーション・プログラムの作業要求がどのようにサーバ・アプリケーション・プログラムによって交信され受け入れられるかを気にすることなく、クライアント・アプリケーション・プログラムおよびサーバ・アプリケーション・プログラムがそれ自体のプラットフォームで動作することを可能にする。同様にサーバ・アプリケーションは、ＯＯＰシステムがどのようにサーバ・アプリケーションの処理結果を受け取り、変換し、要求側クライアント・アプリケーションに返送するかを気にする必要がない。
【０００４】
ＯＯＰ技術が異種クライアント／サーバ・システムとどのように統合されてきたかの詳細は、米国特許第５４４０７４４号および欧州特許公開出願ＥＰ ０ ６７７９４３ Ａ２号に説明されている。これら２件の刊行物を参照によって本明細書に組み込む。しかし、本発明の環境の背景理解のために、基本的アーキテクチャの１例を以下で取り上げる。
【０００５】
図１に示すように、クライアント・コンピュータ１０（例えばＩＢＭ ＯＳ／２オペレーティング・システムを搭載したパーソナル・コンピュータとすることができる）は、そのオペレーティング・システム上で実行するアプリケーション・プログラム４０を有する（「ＩＢＭ」および「ＯＳ／２」はＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ社の商標）。アプリケーション・プログラム４０は定期的に、サーバ・コンピュータ２０上で作業を実行するように、かつ／または後でアプリケーション・プログラム４０で使用するためにデータをサーバ２０から返送するように要求する。サーバ・コンピュータ２０は、例えばＩＢＭのＭＶＳオペレーティング・システム上で実行する高性能メインフレーム・コンピュータとすることができる（「ＭＶＳ」もＩＢＭ社の商標）。本発明の場合、サーバによって実行される通信サービスの要求が、第１アプリケーション・プログラム４０とのユーザの対話によって引き起こされるか、それともアプリケーション・プログラム４０がユーザの対話に関係なく動作して、プログラムの実行中に自動的に要求を行うかは関係ない。
【０００６】
クライアント・コンピュータ１０がサーバ・コンピュータ２０のサービスを要求したいときに、第１アプリケーション・プログラム４０は、必要とするサービスについて第１論理手段５０に通知する。これは、例えば、第１論理手段に遠隔手順の名前を入出力パラメータのリストと共に送ることによって、実行することができる。次いで第１論理手段５０は、記憶装置６０に格納された利用可能な通信サービスの定義を参照して、第２コンピュータ２０との必要な通信を確立するタスクを処理する。可能なサービスはすべて、オブジェクト・クラス７０のコヒーシブ・フレームワークとして定義されており、これらのクラスは単一オブジェクト・クラスから導出される。このようにしてサービスを定義すると、性能および再使用可能性の点で多数の利点が得られる。
【０００７】
サーバ２０との必要な通信を確立するために、第１論理手段５０はフレームワーク内のどのオブジェクト・クラスを使用する必要があるかを判定し、次いで、サーバにおいて、そのオブジェクトのインスタンス、つまりそのオブジェクトにそのメソッドの１つを呼び出させるためにそのオブジェクトに送信されるメッセージを形成する。これにより、接続手段８０を介してサーバ・コンピュータ２０との接続の確立が生じ、続いて要求が第２論理手段９０に送信される。
【０００８】
次いで第２論理手段９０が要求を、サーバ・コンピュータ２０で実行している第２アプリケーション・プログラム１００（以下、サービス・アプリケーションという）に渡すので、サービス・アプリケーション１００は、データ検索手順を実行するなど、その要求によって要求される特定のタスクを実行することができる。このタスクが完了すると、サービス・アプリケーションは、結果を第１コンピュータ１０に返送する必要があるかもしれない。要求されたタスクの実行中、および結果が第１コンピュータ１０に返送される際、サーバ・アプリケーション１００は第２論理手段９０と対話する。第２論理手段９０はオブジェクトのインスタンスを決定し、サーバ・アプリケーション１００によって要求されたときにこれらのオブジェクトの適切なメソッドを呼び出し、記憶装置１１０に格納されたオブジェクト・クラスのコヒーシブ・フレームワークからオブジェクト・インスタンスが形成される。
【０００９】
上記の技術を使用すると、クライアント・アプリケーション・プログラム４０は通信アーキテクチャにさらされない。さらに、サービス・アプリケーション１００が、その環境の標準機構を介して呼び出される。つまり、それは遠隔的に呼び出されていることを認識しない。
【００１０】
オブジェクト管理グループ（ＯＭＧ）は、図１に示すような分散オブジェクトを持つ異種プラットフォームでのクライアント／サーバ・コンピューティングの様々な側面に関与する組織の国際的コンソーシアムである。ＯＭＧは、クライアント・コンピュータ（例えば１０）がサーバ・マシン（例えば２０）と（ＯＯＰの形で）通信するための標準を規定し発行した。これらの標準の一環として、クライアント・マシンとサーバ・マシンの間にオブジェクト指向ブリッジを提供するオブジェクト要求ブローカ（ＣＯＲＢＡつまり共通オブジェクト要求ブローカ・アーキテクチャと呼ばれる）が定義された。ＯＲＢは、オブジェクト指向実装の詳細からクライアント・アプリケーションおよびサーバ・アプリケーションを切り離し、第１および第２論理手段５０、９０ならびに接続手段８０の作業の少なくとも一部分を実行する。
【００１１】
ＣＯＲＢＡソフトウェア構造の一部として、ＯＭＧは「トランザクション」に関連する標準を規定した。これらの標準は、ＯＴＳつまりオブジェクト・トランザクション・サービスとして知られる。例えば、ＯＭＧ文書９４．８．４、ＣＯＲＢＡオブジェクト・トランザクション・サービス仕様１．０を参照されたい。コンピュータによって実装されるトランザクション処理システムは、いくつかの産業において重要なビジネス・タスクに使用される。トランザクションは、完全に終了しなければならないか、または動作せずに完全にパージしなければならない単一作業単位を定義する。例えば、銀行の現金自動預け払い機で顧客が現金を引き出そうとする場合、現金を払い出し、機械内にある現金の残高を差し引き、顧客の銀行預金残高を差し引く動作が全部行われるか、またはそれらが全く行われないかのいずれかでなければならない。下位動作の１つが失敗すると、記録と実際のオカレンスの不一致が生じる。
【００１２】
分散トランザクション処理は、複数の物理位置または論理位置における資源に影響するトランザクションを伴う。上記の例では、トランザクションは、局所現金自動預け払い機で管理される資源に影響するだけでなく、銀行のメイン・コンピュータによって管理される銀行預金残高にも影響する。そのようなトランザクションは、サーバによって処理される一連のクライアント要求により１つの特定のサーバ・コンピュータ（例えば２０）と通信する１つの特定のクライアント・コンピュータ（例えば１０）を伴う。ＯＭＧのＯＴＳは、これらの分散トランザクションを調整する責任がある。
【００１３】
クライアント・プロセスで実行するアプリケーションは、複数の様々なサーバの呼出しを含むトランザクションを始動し、それぞれのサーバはサーバ・プロセスを起動して、トランザクションに含まれる命令に従ってそのローカル・データを変更する。トランザクションを実行する（したがってすべてのサーバがそれらのローカル・データの変更を終了する）か、またはトランザクションを打ち切る（したがってすべてのサーバがトランザクション中に行われたそれらのローカル・データの変更を「撤回」または無視する）かのいずれかによって、トランザクションは終了する。トランザクション中にサーバと通信する（例えばそれらにトランザクションにおけるそれらの役割を実行するかまたは打ち切るように命令する）ために、含まれるプロセスの１つはトランザクションのための状態データを維持しなければならない。ＯＴＳ標準によると、これは一連のオブジェクトをセットアップするプロセスを含み、そのうちの１つは、様々なサーバに関してトランザクションを調整するコーディネータ・オブジェクトである。
【００１４】
このコーディネータ・オブジェクトの主な目的は、どのサーバ・オブジェクトがトランザクションに関与しているかを追跡し続けて、トランザクションが終了したときに、トランザクションに関与する各サーバ・オブジェクトに、１回の統一された努力で、そのサーバ・オブジェクトに関連するローカル・データベースに局所的に行われた変更をコミットするように命令することができるようにすることである。これにより、どのサーバ・オブジェクトも、同一トランザクションに関与する他のサーバ・オブジェクトなしでは、データ変更を最終決定しないことが保証される。したがって、トランザクションに参加する各サーバ・オブジェクトは最初にコーディネータ・オブジェクトに登録して、コーディネータ・オブジェクトがサーバ・オブジェクトの存在、トランザクションへの参加の希望、およびトランザクションを終了する時が来たときにサーバ・オブジェクトがどこにあるか（例えばサーバ・オブジェクトがどのサーバ・マシンに常駐しているか）が分かるようにしておかなければならない（コーディネータ・オブジェクトはすべてのサーバ・オブジェクトにそれぞれのローカル・データの変更を最終決定するように命令する）。
【００１５】
データを更新する責任のあるサーバ・オブジェクト（以下、資源オブジェクトという）は、別のサーバ・オブジェクト（またはトランザクションを開始した元のクライアント・オブジェクト）が資源オブジェクトに何らかの作業をするように資源オブジェクトに要求を送ったときに、トランザクションに関与するようになる。この後者の要求は、要求がトランザクションの一部であることを資源オブジェクトに知らせる、トランザクション・コンテキストと呼ばれる何らかの情報を含む。資源オブジェクトはそれがトランザクションに関与するようになることを認識すると、コーディネータ・オブジェクトに登録要求を行う。
【００１６】
資源オブジェクトが、コーディネータ・オブジェクトとは異なるオペレーティング・システム・プロセスに配置されている場合、従来技術（例えば、１９９７年に発売されたＩＢＭのコンポーネント・ブローカ・ソフトウェア製品におけるＩＢＭによる実装をはじめとするＣＯＲＢＡのＯＴＳ標準）で、資源オブジェクト（２２３または２２４）と同じオペレーティング・システム・プロセスに配置された下位コーディネータ・オブジェクト（図２の２２２）を使用すると便利であることが明らかになった。その場合、主コーディネータ・オブジェクトを「上位コーディネータ・オブジェクト」２１１と呼ぶ。資源オブジェクト２２３のトランザクションへの登録中に、下位コーディネータ２２２は資源オブジェクト２２３を収容しているサーバ・マシン２２内で局所的にセットアップされ、資源オブジェクト２２３は登録要求を行うときに、この下位コーディネータ・オブジェクト２２２と直接やり取りする。（ここでは用語「サーバ・マシン」を使用しているが、分散サーバ・オブジェクトを実際には、同じサーバ・マシンであるがそのサーバ・マシン上で実行している別のオペレーティング・システム・プロセスに配置することもできることを示すために、用語「サーバ・プロセス」を使用することもできることに留意されたい。したがって、以下では、用語「サーバ」は、両方の用語を指すのに使用する。）次に下位コーディネータ２２２はそれ自体を、上位コーディネータ・オブジェクト２１１（あたかも資源オブジェクトであるかのように、おそらく別のサーバ・マシン上の別のプロセスに配置されている）に登録する。
【００１７】
下位コーディネータ・オブジェクト２２２はこのようにして、資源オブジェクトを収容しているサーバ内におけるトランザクションの存在を表現する。上位コーディネータ・オブジェクト２１１と直接やり取りする代わりに、資源オブジェクト２２３、２２４は最初にそれらのローカル下位コーディネータ・オブジェクト２２２とやり取りし、次にこれが上位コーディネータ・オブジェクトとやり取りする。これにより、オペレーティング・システム・プロセス間の相互呼出し回数が大幅に減少する。
【００１８】
【発明が解決しようとする課題】
この従来技術のアーキテクチャでは、結果的に生じる非効率性が依然として多く存在する。例えば、トランザクションに関与する２つのマシンがあり、１つのマシンはビジネス論理を含み、別のマシンはデータ論理を含むと仮定する。上位コーディネータは、ビジネス論理を含むマシン上で実行するプロセスにセットアップされ、資源オブジェクトはデータ論理を含むマシンに配置される。データ論理を含むマシンはその中で実行する２つのサーバ・プロセスを持ち、そのようなプロセスがそれぞれ、分散トランザクションに関与する資源オブジェクトを有する。したがって、各サーバ・プロセスに１つずつ、２つの分離した下位コーディネータがセットアップされる。データ論理を含むマシン内の各下位コーディネータは次に、トランザクションを処理するために、ビジネス論理を含むマシン内の上位コーディネータにマシン間メッセージ（例えばＴＣＰ／ＩＰを使用して）を送る。このように、従来技術のこのソフトウェア・アーキテクチャでは、発生するマシン間データ・フローが依然として多数存在する。
【００１９】
【課題を解決するための手段】
第１の態様によれば、本発明は、複数のサーバ・データ処理装置によって実行される分散トランザクションを調整する際に使用する第１サーバ・データ処理装置であって、第２サーバ・データ処理装置から登録要求を受け取る手段と、登録要求を送った第２サーバ・データ処理装置のマシン・アドレスを決定する手段と、第１装置に登録要求を送るサーバ・データ処理装置のマシン・アドレスのリストを維持する手段と、アウトバウンド・トランザクション要求の宛先マシン・アドレスを決定する手段と、アウトバウンド・トランザクション要求の宛先マシン・アドレスが前記維持手段によって維持されるマシン・アドレスのリストに含まれるかどうかを判定する手段と、アウトバウンド・トランザクション要求の宛先マシン・アドレスが前記維持手段によって維持されるマシン・アドレスのリスト内に含まれる場合には、第１サーバ装置上に位置するトランザクション・コーディネータを識別するアウトバウンド・トランザクション要求内の識別子を、アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ装置上に位置するトランザクション・コーディネータを識別する識別子で代用する手段とを備える第１サーバ・データ処理装置を提供する。
【００２０】
第２の態様によれば、本発明は、第１の態様に関して上述した機能を実行する方法を提供する。
【００２１】
第３の態様によれば、本発明は、コンピュータ可読記憶媒体に格納されたコンピュータ・プログラムであって、コンピュータ上で実行するときに、本発明の第２の態様に記載した方法を実行するためのプログラム要素を有するプログラムを提供する。
【００２２】
したがって、本発明は同一マシン上に配置された１群の下位コーディネータを統合するので、１つのそうした下位コーディネータだけが、マシン間データを介して上位コーディネータ（これは別のマシンで実行している）と直接やり取りする必要がある。このため、それがなければ必要になるマシン間データ転送の回数が大幅に減少する。
【００２３】
【発明の実施の形態】
本発明の好適な実施形態を例示するために、第１層がクライアント・マシンの対トランザクション・インタフェースであり（そのような層は一般的にパーソナル・コンピュータ・ワークステーション上で実行する）、第２層が一般的に部門サーバ・レベルに常駐するビジネス論理層であり、第３層が一般的にデータベース・サーバとして使用されるマシン（単数または複数）に常駐するデータ論理層である、３層分散トランザクション処理アーキテクチャの典型例を使用する。
【００２４】
図３で、サーバ・マシン３１は、上位コーディネータ・オブジェクト３１１を含むプロセスを実行している。例えば、このプロセスは、以前にトランザクション開始要求（またはコマンド）をサーバ・マシン３１に送った第１層のクライアント・マシン（図示せず）によって開始された分散トランザクションを実行するためのビジネス論理の第２層処理に含まれる。
【００２５】
第２サーバ・マシン３２は、分散トランザクションを実行するための第３層のデータ論理の処理にそれぞれ含まれる３つの異なるプロセス３２１、３２２、３２３を実行している。プロセス３２１では、下位コーディネータ・オブジェクト３２１１が、トランザクションにそれぞれ含まれる資源オブジェクト３２１２、３２１３と直接やり取りする。プロセス３２２では、下位コーディネータ３２２１が、トランザクションに含まれる資源オブジェクト３２２２と直接やり取りする。プロセス３２３では、下位コーディネータ・オブジェクト３２３１が、トランザクションにそれぞれ含まれる資源オブジェクト３２３２、３２３３、３２３４と直接やり取りする。
【００２６】
従来技術では、分散トランザクションの処理中に、各下位コーディネータ３２１１、３２２１、３２３１が、別個のマシン間データ・フローを上位コーディネータ・オブジェクト３１１に送る。本発明の好適な実施形態では、下位コーディネータ・オブジェクト３２２１、３２３１はそれらのトランザクション結果を下位コーディネータ３２１１に受け渡し、これは次にそうした結果をオブジェクト３２１１自体の結果と共に、マシン３１の上位コーディネータ・オブジェクト３１１に中継する。したがって、これはマシン間データ・フローの回数を著しく削減し、その代わりに同一マシン上でのプロセス間データ・フローだけが必要であるが、これは、例えばリモートＴＣＰ／ＩＰ接続を実行する必要がないので（プロセスが同一マシン上で実行しているので）、ずっと速く実行される。
【００２７】
同一マシン上に位置する下位コーディネータ・オブジェクトが、マシンの境界を超えて上位コーディネータ・オブジェクトに集合データ・フローを送る前に、それらのトランザクション・データ・フローをいかにして集めるかについて、今から説明する。
【００２８】
上位コーディネータ３１１を含むサーバ・マシン・プロセスは、
１）上位コーディネータ・オブジェクト３１１に登録されたリモート下位コーディネータ（つまり３２１１、３２２１、３２３１）のホスト・マシン位置を決定し、
２）次に、アウトバウンド・トランザクション要求（例えばビジネス論理層からデータ論理層へ送られる要求）の宛先ホスト・マシンを決定し、
３）アウトバウンド要求の宛先に局所的（ローカル）に（つまり同一マシン上に）すでに形成された下位コーディネータがある場合には、次に、アウトバウンド要求を伴う伝搬コンテキスト内のトランザクションの上位コーディネータのオブジェクト参照の代わりに、目標オブジェクトと「同一マシン上の（マシン・ローカルな，ｍａｃｈｉｎｅ−ｌｏｃａｌ）」リモート下位コーディネータのオブジェクト参照を代用する
ことによってこれを達成する。
【００２９】
好適な実施形態では、ストリング化オブジェクト参照に指定されたフォーマットの構造を使用する。ｏｂｊｅｃｔ＿ｔｏ＿ｓｔｒｉｎｇと呼ばれるすべてのＣｏｒｂａオブジェクトで動作する方法を提供する。この方法は、ｓｔｒｉｎｇ＿ｔｏ＿ｏｂｊｅｃｔを使用して保管し、他のシステム等に渡し、オブジェクト参照に送り返すことができるストリング・バージョンのオブジェクト参照を生成する。
【００３０】
実際には、ストリングは事実上、オブジェクトのためのストリング形式の相互運用可能なオブジェクト参照（ＩＯＲ）である。そのようなＣＯＲＢＡ：：ＩＯＰ：：ＩＯＲ構造は、ＣＯＲＢＡ ２．０仕様に完全に規定されている。これらのフォーマットは、ＯＲＢによって使用される特定のトランスポート・メカニズムのＣＯＲＢＡ ＩＯＰプロトコルによって完成されたときに、Ｃｏｒｂａ ２．０一般Ｉｎｔｅｒ−Ｏｒｂプロトコル（ＧＩＯＰ）によって記述される。
【００３１】
ＩＩＯＰ ＯＲＢのＩＯＲの一部分は、ホスト・マシンのＩＰアドレスである。したがって、オブジェクト参照からホスト・マシンを決定することは簡単である（これが、そのオブジェクト参照を使用してリモート・オブジェクトに方法を送ることを可能にするメカニズムであり、ＯＲＢは参照からホストおよびポートを抽出し、要求を処理のためにリモート・システムに送る）。
【００３２】
アプリケーション（またはトランザクション・サービス）から見て、これは、内部ＯＲＢ法を使用することなく行うことができる。つまり、単にｏｂｊ．ｏｂｊｅｃｔ＿ｔｏ＿ｓｔｒｉｎｇを呼び出し、Ｃｏｒｂａ ２．０仕様に埋め込まれたデータ・フォーマットを使用してストリングを調べて、ホスト・アドレスを得ることができる。別法として、希望するなら、同じことを行う提供された内部ＯＲＢ機能の知識を使用することもでき、すなわちＯＲＢの内部コードによって、おそらく、より効率的に行うことができるであろう。
【００３３】
本発明の好適な実施形態では、要求がプロセス間を流れるときに、トランザクション・サーバ間で受け渡される伝搬コンテキストを新規に利用する。詳しくは、我々は、登録された資源を有しかつそれがその上位コーディネータに資源を登録している、下位コーディネータからの要求に関心がある。我々がここで関心を持つのは応答で返されるコンテキストであるので、この流れの中で、伝搬コンテキストは通常「再開」を目的とするトランザクション情報を含まない。しかし、この伝搬コンテキストは、「実装特有の」目的のために使用できるデータ領域を含む。それはまたその中に、ＴｒａｎｓＩｄｅｎｔｉｔｙフィールド内にコーディネータ参照のためのスロット（応答フローでは使用されない）を含む。
【００３４】
下位コーディネータから上位コーディネータへのこの登録要求により、我々は、登録作業を実行するプロセスで形成される新しい下位コーディネータのオブジェクト参照を伝搬コンテキスト内に入れる。（伝搬コンテキスト内のどちらのデータ領域も使用することができる。大して重要ではないが、応答の「検査済みトランザクション」検査がｏｔｉｄトランザクションｉｄを使用して行われるとき、我々はそれを安全にＴｒａｎｓＩｄｅｎｔｉｔｙ構造のコーディネータ・スロットに入れることができる。）
【００３５】
ｒｅｇｉｓｔｅｒ＿ｒｅｓｏｕｒｃｅ要求の均等物が要求からの応答に便乗する「遅延登録」の場合に、同様のプロセスを使用することができる。
【００３６】
上位コーディネータ（例えば３１１）を含むプロセスで要求を受け取ると、「受け取られた要求」の標準ｏｒｂインタセプタがすでに目標オブジェクトの型および伝搬コンテキストを調べる。単純な拡張により、インタセプタは、送り出しプロセスからリモート・コーディネータのオブジェクト参照を抽出することができる。
【００３７】
Ｃｏｏｒｄｉｎａｔｏｒ：：ｒｅｇｉｓｔｅｒ＿ｒｅｓｏｕｒｃｅインタフェース・メソッドは、資源登録がそれに関連し対応するリモート下位コーディネータ参照を有するかどうか検査するように拡張される。そうである場合、登録を処理するコーディネータは、下位コーディネータのオブジェクト参照を抽出する。コーディネータはオブジェクト参照を調べて、それが形成されたホストのＩＰアドレスを決定する。（これは、所望する場合には、上記参照と一緒に簡単に受け渡すことができる。）
【００３８】
コーディネータは、トランザクションに含まれるそのようなリモート下位トランザクション・コーディネータの表を維持する。表は、ＩＰアドレスから、これらのリモート・マシン・ホストにすでに構築されておりトランザクションに関連するコーディネータ参照へのマッピングである。一般的にこの表は小さいので、性能オーバヘッドが大きくなる可能性は全くない。
【００３９】
最終ステップが必要である。現在、ｓｅｎｄｉｎｇ＿ｒｅｑｕｅｓｔ ＯＲＢインタセプタでは、トランザクション要求がリモート・サーバに流れるとき、ローカル（上位）コーディネータの参照が伝搬コンテキスト内に置かれる。したがって現在、トランザクションへの関与および資源の登録は、グローバル分散トランザクション・ツリーに接続するために、このサーバに戻ってくる。上述のステップを前提にして、今やｓｅｎｄｉｎｇ＿ｒｅｑｕｅｓｔ ＯＲＢインタセプタが上述のように目標オブジェクトのホスト・マシンＩＰアドレスを抽出し（目標オブジェクトがＣｏｓｔｒａｎｓａｃｔｉｏｎｓ：：ＴｒａｎｓａｃｔｉｏｎａｌＯｂｊｅｃｔであるかどうかを判定するためにすでにそれにアクセスしている）、すでに形成されているそのリモート下位コーディネータの表を参照することは、単純なプロセスである。したがって、要求が流れていく先の目標オブジェクトと同一マシン上にすでに存在するトランザクションに関係する下位コーディネータがあるかどうかを判定する。
【００４０】
目標オブジェクト・マシン上に登録されたコーディネータがすでにある場合には、伝搬コンテキストでそれ自体のオブジェクト参照を送り出す代わりに、上位コーディネータは、すでに目標オブジェクトと同一マシン上に「局所的に」存在する下位コーディネータのオブジェクト参照を代用する。そのトランザクション・フローの結果、何らかの資源登録の関与が生じた場合、それらが自動的に同一マシン上の下位コーディネータに流れる。
【００４１】
手短に述べると、登録要求を受け取ったときに、上位コーディネータ・オブジェクト３１１を含むサーバ・マシン３１が実行するステップは、図４の流れ図に示されている。
【００４２】
ステップ４１で、サーバ・マシン３１はサーバ・マシン３２から登録要求を受け取る。ステップ４２で、サーバ・マシン３１はサーバ・マシン３２のマシン・アドレス（例えばＩＰアドレス）を決定する。ステップ４３で、サーバ・マシン３１はサーバ・マシン３２のマシン・アドレスを、どのサーバ・マシンがサーバ・マシン３１に登録要求を送ったかを追跡するリストに付加する。
【００４３】
さらに、アウトバウンド・トランザクション要求（上位コーディネータ・オブジェクト３１１を含むサーバ・プロセスの外部のプロセス宛てに送られる要求）を受け取ったときに、上位コーディネータ・オブジェクト３１１を含むサーバ・マシン３１で実行しているサーバ・プロセスによって実行されるステップを、図５の流れ図に示す。コーディネータ・オブジェクト３１１を含むプロセスを以下ではアウトバウンド・トランザクション要求を「受け取る」ことと述べるが、本発明の実施形態によっては、このプロセスは、内部でプロセスへの要求を生成することもできる。しかし、プロセスが別のプロセスからアウトバウンド要求を受け取るのが、より普通のケースである。
【００４４】
ステップ５１で、サーバ・マシン３１は、異なるサーバ・マシン上の資源にアクセスし、したがってトランザクションに関係することを指定するアウトバウンド・トランザクション要求を（例えば、図示しないがクライアント・マシンから、またはサーバ・マシン３１上で実行しているクライアント・プロセスから、または別のサーバ・プロセスから）受け取る。ステップ５２で、サーバ・マシン３１はアウトバウンド・トランザクション要求の宛先マシン・アドレスを決定する。例えば、アウトバウンド要求が、トランザクションの一部としてサーバ・マシン３２に位置する資源オブジェクトにアクセスすることを要求している場合には、アウトバウンド・トランザクション要求の宛先マシン・アドレスは、サーバ・マシン３２のアドレスである。
【００４５】
ステップ５３で、サーバ・マシン３１は、アウトバウンド要求の宛先マシン・アドレスが、図４のステップ４３で付加されたリストに含まれるかどうかを判定する。つまり、サーバ・マシン３１が、アウトバウンド・トランザクション要求内で識別されている宛先サーバ・マシンから以前に登録要求を受け取ったことがあるかどうか（例えばステップ４１）、判定が行われる。我々の例では、宛先サーバ・マシン３２は実際にサーバ・マシン３１に登録要求を送ったことがある。アウトバウンド要求の宛先マシン・アドレスがリストに含まれる場合（我々の例の場合のように）、サーバ・マシン３１は、上位コーディネータの識別子の代りに、アウトバウンド要求の宛先マシンに局所的な下位コーディネータの識別子を代用する。あるいは、アウトバウンド要求の宛先マシン・アドレスがリストに含まれていない場合、上位コーディネータの識別子がアウトバウンド要求内に残される。
【００４６】
この代用を実行する（ステップ５３のＹＥＳ分岐に従う）ことにより、まだ上位コーディネータ３１１に登録要求を行っていないが、すでに上位コーディネータ３１１に登録要求を行った別の下位コーディネータ３２１１と同一サーバ・マシン３２上に位置する下位コーディネータ３２２１は、データ・フローを上位コーディネータ３１１に直接送る代わりに、そうしたデータ・フローを下位コーディネータ３２１１に送る。これにより、マシン相互のデータ・フローの数が著しく減少し、したがってネットワーク・トラヒックの量が大幅に低下する。
【００４７】
本発明の好適な実施形態は、上述のようないくつかの様々なステップを含むが、そのいずれも設計または実装の努力、実行システムのＣＰＵサイクル、またはネットワーク・トラヒックの点からみて高価ではない。
【００４８】
結果は、「三層（スリー・ティア）」アーキテクチャの分散の非常に一般的なシナリオになると考えられるＩＢＭのコンポーネント・ブローカ製品などの分散コストランザクション・システムにおける典型的なビジネス・トランザクションの実行において、マシン間メッセージの数を大幅に減少する。
【００４９】
その上、講じられるステップの結果、現在構築されているものよりコミット・ツリーの最適度が低下することは決してなく、また試みられた最適化により利益が得られるか否かに関係なく、含まれる処理が実行システムに及ぼす性能上の影響は最小限である。
【００５０】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００５１】
（１）複数のサーバ・データ処理装置によって実行される分散トランザクションの調整に使用される第１サーバ・データ処理装置であって、
第２サーバ・データ処理装置から登録要求を受け取る手段と、
登録要求を送った前記第２サーバ・データ処理装置のマシン・アドレスを決定する手段と、
前記第１装置に登録要求を送るサーバ・データ処理装置のマシン・アドレスのリストを維持する手段と、
アウトバウンド・トランザクション要求の宛先マシン・アドレスを決定する手段と、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが、前記維持手段によって維持されるマシン・アドレスのリストに含まれるかどうかを判定する手段と、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが前記維持手段によって維持されるマシン・アドレスのリストに含まれる場合、前記第１サーバ装置上に位置するトランザクション・コーディネータを識別するアウトバウンド・トランザクション要求内の識別子を、前記アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ装置上に位置するトランザクション・コーディネータを識別する識別子で代用する手段と
を含む第１サーバ・データ処理装置。
（２）前記第１サーバ装置上に位置するトランザクション・コーディネータが上位コーディネータであり、前記アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ装置上に位置するトランザクション・コーディネータが下位コーディネータである、上記（１）に記載の装置。
（３）分散トランザクションが前記サーバ装置により共通オブジェクト要求ブローカ・アーキテクチャのオブジェクト・トランザクション・サービスの実現を通じて実行される、上記（１）に記載の装置。
（４）前記複数のサーバ・データ処理装置がインターネットを介して相互接続される、上記（１）に記載の装置。
（５）前記マシン・アドレスがインターネット・プロトコル・アドレスによって指定される、上記（４）に記載の装置。
（６）複数のサーバ・データ処理装置によって実行される分散トランザクションの調整に使用される第１サーバ・データ処理装置を操作する方法であって、
第２サーバ・データ処理装置から登録要求を受け取るステップと、
登録要求を送る前記第２サーバ・データ処理装置のマシン・アドレスを決定するステップと、
前記第１装置に登録要求を送るサーバ・データ処理装置のマシン・アドレスのリストを維持するステップと、
アウトバウンド・トランザクション要求の宛先マシン・アドレスを決定するステップと、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが、前記維持ステップによって維持されるマシン・アドレスのリストに含まれるかどうかを判定するステップと、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが前記マシン・アドレスのリストに含まれる場合、前記第１サーバ装置上に位置するトランザクション・コーディネータを識別するアウトバウンド・トランザクション要求内の識別子を、前記アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ装置上に位置するトランザクション・コーディネータを識別する識別子で代用するステップと
を含む方法。
（７）前記第１サーバ装置上に位置するトランザクション・コーディネータが上位コーディネータであり、前記アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ装置上に位置するトランザクション・コーディネータが下位コーディネータである、上記（６）に記載の方法。
（８）分散トランザクションが前記サーバ装置により共通オブジェクト要求ブローカ・アーキテクチャのオブジェクト・トランザクション・サービスの実現を通じて実行される、上記（６）に記載の方法。
（９）前記複数のサーバ・データ処理装置がインターネットを介して相互接続される、上記（６）に記載の方法。
（１０）前記マシン・アドレスがインターネット・プロトコル・アドレスによって指定される、上記（９）に記載の方法。
（１１）上記（６）の方法ステップを実行するためのマシンによって実行可能な命令のプログラムを記憶したマシン可読プログラム記憶装置。
【図面の簡単な説明】
【図１】本発明の好適な実施形態を適用することができる文脈における、オブジェクト技術を使用した周知の異種クライアント／サーバ・アーキテクチャのブロック図である。
【図２】本発明の好適な実施形態を適用することができる文脈における、従来の設計に従って２つの共通トランザクション・サーバ内でインスタンス化される様々なオブジェクトを示すブロック図である。
【図３】本発明の好適な実施形態に従って２つの共通トランザクション・サーバ内でインスタンス化される様々なオブジェクトを示す別のブロック図である。
【図４】本発明の好適な実施形態に従って、サーバ内に含まれるステップを示す流れ図である。
【図５】本発明の好適な実施形態に従って、サーバ内に含まれるステップを示す流れ図である。
【符号の説明】
３１ サーバ・マシン
３２ 第２サーバ・マシン
３１１ 上位コーディネータ・オブジェクト
３２１ プロセス
３２２ プロセス
３２３ プロセス
３２１１ 下位コーディネータ・オブジェクト
３２２１ 下位コーディネータ・オブジェクト
３２２２ 資源オブジェクト
３２３１ 下位コーディネータ・オブジェクト
３２３２ 資源オブジェクト
３２３３ 資源オブジェクト
３２３４ 資源オブジェクト
Claims (9)
- 複数のサーバ・データ処理装置によって実行される分散トランザクションの調整に使用される第１サーバ・データ処理装置であって、
第２サーバ・データ処理装置から登録要求を受け取る手段と、
登録要求を送った前記第２サーバ・データ処理装置のマシン・アドレスを決定する手段と、
前記第１サーバ・データ処理装置に登録要求を送ったサーバ・データ処理装置のマシン・アドレスのリストを維持する手段と、
アウトバウンド・トランザクション要求の宛先マシン・アドレスを決定する手段と、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが、前記維持手段によって維持されるマシン・アドレスのリストに含まれるかどうかを判定する手段と、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが前記維持手段によって維持されるマシン・アドレスのリストに含まれる場合、前記第１サーバ・データ処理装置上に位置するトランザクション・コーディネータを識別するアウトバウンド・トランザクション要求内の識別子を、前記アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ・データ処理装置上に位置するトランザクション・コーディネータを識別する識別子で代用する手段と
を含む第１サーバ・データ処理装置。 - 分散トランザクションが前記サーバ・データ処理装置により共通オブジェクト要求ブローカ・アーキテクチャのオブジェクト・トランザクション・サービスの実現を通じて実行される、請求項１に記載の第１サーバ・データ処理装置。
- 前記複数のサーバ・データ処理装置がインターネットを介して相互接続される、請求項１に記載の第１サーバ・データ処理装置。
- 前記マシン・アドレスがインターネット・プロトコル・アドレスによって指定される、請求項３に記載の第１サーバ・データ処理装置。
- 複数のサーバ・データ処理装置によって実行される分散トランザクションの調整に使用される第１サーバ・データ処理装置が次の各ステップを実行する方法であって、
第２サーバ・データ処理装置から登録要求を受け取るステップと、
登録要求を送る前記第２サーバ・データ処理装置のマシン・アドレスを決定するステップと、
前記第１サーバ・データ処理装置に登録要求を送ったサーバ・データ処理装置のマシン・アドレスのリストを維持するステップと、
アウトバウンド・トランザクション要求の宛先マシン・アドレスを決定するステップと、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが、前記維持ステップによって維持されるマシン・アドレスのリストに含まれるかどうかを判定するステップと、
前記アウトバウンド・トランザクション要求の宛先マシン・アドレスが前記マシン・アドレスのリストに含まれる場合、前記第１サーバ・データ処理装置上に位置するトランザクション・コーディネータを識別するアウトバウンド・トランザクション要求内の識別子を、前記アウトバウンド・トランザクション要求の宛先マシン・アドレスを有するサーバ・データ処理装置上に位置するトランザクション・コーディネータを識別する識別子で代用するステップと
を含む方法。 - 分散トランザクションが前記サーバ・データ処理装置により共通オブジェクト要求ブローカ・アーキテクチャのオブジェクト・トランザクション・サービスの実現を通じて実行される、請求項５に記載の方法。
- 前記複数のサーバ・データ処理装置がインターネットを介して相互接続される、請求項５に記載の方法。
- 前記マシン・アドレスがインターネット・プロトコル・アドレスによって指定される、請求項７に記載の方法。
- 請求項５に記載の方法ステップを実行するためにコンピュータ装置によって実行可能な命令のプログラムを記憶した記憶装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9903629A GB2346983B (en) | 1999-02-18 | 1999-02-18 | Client/server computing for transaction processing with superior coordinator o ptimization |
| GB9903629.5 | 1999-02-18 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000242607A JP2000242607A (ja) | 2000-09-08 |
| JP3628577B2 true JP3628577B2 (ja) | 2005-03-16 |
Family
ID=10847961
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000039363A Expired - Fee Related JP3628577B2 (ja) | 1999-02-18 | 2000-02-17 | サーバ・データ処理装置、操作方法および記憶装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6499063B1 (ja) |
| JP (1) | JP3628577B2 (ja) |
| GB (1) | GB2346983B (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007310891A (ja) * | 2006-05-19 | 2007-11-29 | Sap Ag | コンピュータソフトウェア開発の方法およびシステム |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7437456B1 (en) * | 2000-03-17 | 2008-10-14 | Fujitsu Limited | Object reference generating device, object reference generating method and computer readable recording medium for recording an object reference generating program |
| US7386114B1 (en) * | 2004-01-08 | 2008-06-10 | Shortel, Inc. | Distributed session-based data |
| US20050262100A1 (en) * | 2004-05-19 | 2005-11-24 | Bea Systems, Inc. | System and method for context propagation in application servers and transaction-based systems |
| US8230426B2 (en) * | 2004-10-06 | 2012-07-24 | Digipede Technologies, Llc | Multicore distributed processing system using selection of available workunits based on the comparison of concurrency attributes with the parallel processing characteristics |
| US7533080B2 (en) * | 2006-04-10 | 2009-05-12 | Microsoft Corporation | Commit tree optimization based on recovery topology information |
| US9703285B2 (en) * | 2006-04-27 | 2017-07-11 | International Business Machines Corporation | Fair share scheduling for mixed clusters with multiple resources |
| US7698251B2 (en) * | 2006-04-27 | 2010-04-13 | International Business Machines Corporation | Fault tolerant facility for the aggregation of data from multiple processing units |
| US8087026B2 (en) | 2006-04-27 | 2011-12-27 | International Business Machines Corporation | Fair share scheduling based on an individual user's resource usage and the tracking of that usage |
| US8442958B2 (en) * | 2006-06-26 | 2013-05-14 | Cisco Technology, Inc. | Server change management |
| US7706303B2 (en) | 2006-06-26 | 2010-04-27 | Cisco Technology, Inc. | Port pooling |
| US8346851B2 (en) * | 2009-08-31 | 2013-01-01 | Red Hat, Inc. | System and method for determining when to generate subordinate coordinators on local machines |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6205464B1 (en) * | 1994-09-16 | 2001-03-20 | International Businesss Machines Corporation | System for building optimal commit trees in a distributed transaction processing system |
| US6317773B1 (en) * | 1994-10-11 | 2001-11-13 | International Business Machines Corporation | System and method for creating an object oriented transaction service that interoperates with procedural transaction coordinators |
| JPH08286962A (ja) * | 1994-12-16 | 1996-11-01 | Internatl Business Mach Corp <Ibm> | 処理システム及びオブジェクト活動化をスケジュールする方法 |
| DE69628965T2 (de) * | 1995-03-22 | 2004-02-26 | Sun Microsystems, Inc., Mountain View | Verfahren und Gerät zum Verwalten von Beziehungen zwischen Objekten in einer verteilten Objektumgebung |
| GB2303474A (en) * | 1995-07-19 | 1997-02-19 | Ibm | Optimized synchronisation procedure |
| ES2142564T3 (es) * | 1996-08-20 | 2000-04-16 | Cit Alcatel | Procedimiento para administrar la especificacion de objetos. |
| CA2213213A1 (en) * | 1996-08-26 | 1998-02-26 | Tandem Computers Incorporated | Method and apparatus for performing efficient corba transactions |
| SE521041C2 (sv) * | 1997-05-28 | 2003-09-23 | Ericsson Telefon Ab L M | Metod för optimering av transaktionsprotokoll inom en distribuerad databas |
| US6226788B1 (en) * | 1998-07-22 | 2001-05-01 | Cisco Technology, Inc. | Extensible network management system |
-
1999
- 1999-02-18 GB GB9903629A patent/GB2346983B/en not_active Expired - Lifetime
- 1999-06-25 US US09/344,799 patent/US6499063B1/en not_active Expired - Lifetime
-
2000
- 2000-02-17 JP JP2000039363A patent/JP3628577B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007310891A (ja) * | 2006-05-19 | 2007-11-29 | Sap Ag | コンピュータソフトウェア開発の方法およびシステム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000242607A (ja) | 2000-09-08 |
| GB9903629D0 (en) | 1999-04-07 |
| GB2346983A (en) | 2000-08-23 |
| GB2346983B (en) | 2003-04-16 |
| US6499063B1 (en) | 2002-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4464525B2 (ja) | 作業負荷によって管理されるクライアント／サーバ・データ処理システムにおける集中アフィニティ維持装置および方法 | |
| US6457041B1 (en) | Client-server transaction data processing system with optimum selection of last agent | |
| US6052731A (en) | Apparatus, method and computer program for providing arbitrary locking requesters for controlling concurrent access to server resources | |
| US6289343B1 (en) | Apparatus and method for performing semantic concurrency control in dispatching client requests within a server in a client/server computer system | |
| US6038589A (en) | Apparatus, method and computer program product for client/server computing with a transaction representation located on each transactionally involved server | |
| US20030115379A1 (en) | Method, system, and program for implementing a remote method call | |
| JP3628577B2 (ja) | サーバ・データ処理装置、操作方法および記憶装置 | |
| JP3579353B2 (ja) | クライアント／サーバ・コンピューティング・システム、およびクライアント／サーバ処理方法 | |
| JP3409308B2 (ja) | クライアント／サーバ・コンピューティング・システム及びサーバ処理方法 | |
| JP3548030B2 (ja) | サーバ処理装置及びサーバ処理方法 | |
| US6542922B1 (en) | Client/server transaction data processing system with automatic distributed coordinator set up into a linear chain for use of linear commit optimization | |
| US6324589B1 (en) | Apparatus, method and computer program product for client/server computing with reduced cross-process calls | |
| US6829632B1 (en) | Apparatus, method and computer program product for client/server computing with timing of creation of coordinator transaction state object being based on triggering events | |
| JP2001159978A (ja) | 分散オブジェクトプログラム実行支援システム | |
| CZ20002585A3 (cs) | Zařízení, způsob a produkt počítačového programu pro výpočetní operace klient/server s inteligentním hledáním transakčních objektů |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040727 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040818 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20041130 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041208 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3628577 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071217 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081217 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081217 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091217 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091217 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101217 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101217 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111217 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111217 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121217 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121217 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131217 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |