JP4464525B2 - 作業負荷によって管理されるクライアント／サーバ・データ処理システムにおける集中アフィニティ維持装置および方法 - Google Patents
作業負荷によって管理されるクライアント／サーバ・データ処理システムにおける集中アフィニティ維持装置および方法 Download PDFInfo
- Publication number
- JP4464525B2 JP4464525B2 JP2000105458A JP2000105458A JP4464525B2 JP 4464525 B2 JP4464525 B2 JP 4464525B2 JP 2000105458 A JP2000105458 A JP 2000105458A JP 2000105458 A JP2000105458 A JP 2000105458A JP 4464525 B2 JP4464525 B2 JP 4464525B2
- Authority
- JP
- Japan
- Prior art keywords
- data processing
- server
- server data
- transaction
- client
- 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
-
- 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5033—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering data affinity
-
- 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/466—Transaction processing
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Multi Processors (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データ処理の分野に関する。さらに詳細には、クライアント・データ処理システムから出される作業要求に関して、サーバ・データ処理システム・グループが作業負荷によって管理されている場合に関する。
【０００２】
【従来の技術】
クライアント／サーバ・コンピューティングは、情報技術の世界でここ数年ますます重要なものになってきている。この種の分散コンピューティングは、あるマシンの作業の一部を、たとえばその作業を実行するのにより好適であると思われる他のマシンに任せることができるようにするものである。たとえばサーバは、莫大な量のデータの格納を管理するデータベース・プログラムを実行する高性能コンピュータであり、クライアントは単に、そのローカル・プログラムの１つで使用するためにデータベースから情報を要求するデスクトップ型パーソナル・コンピュータ（ＰＣ）である。
【０００３】
クライアント／サーバのデータ処理において、クライアントは一単位の作業要求を、クライアントに代わってその作業単位を実行する能力があるとわかっている特定サーバに向けて送る。もちろんサーバはクライアントとしても機能することができるので、サーバ間要求も普通のことである。特定サーバに向けて大量の要求が送られることが予想される場合や、サーバが常時動作状態でなければならない場合には、それぞれ一定単位の作業を実行できるサーバのグループを提供することはごく普通のことである。このサーバ・グループに向けて特定の一単位の作業が送られると、作業負荷管理ユニットは、この特定単位の作業要求をこのサーバ・グループのどの特定のメンバに割り当てるべきかを決定する。たとえば、グループ内で最もビジーでないサーバが選択されあるいは、グループ内の１つのサーバが誤動作を起こしている場合には、グループ内の他のサーバが要求を処理するために選択される。
【０００４】
以下の説明では、サーバ・グループへのアクセスを試みている作業要求単位の発信元を「エンティティ」と呼ぶ。エンティティはクライアントである場合がある。また他の場合（こちらの方が一般的である）に、エンティティはトランザクションであり、そのため実行中のデータ処理のタイプはトランザクション処理と呼ばれる。
【０００５】
あるサーバ・グループにアクセス中のエンティティが、後で同じサーバ・グループに再度アクセスする場合、この後のアクセスは前のアクセス中に使用されたグループ内にある同じサーバに戻るのが、非常に有利である。これによってデータの保全性が維持され、パフォーマンスも向上する。これは従来技術では「アフィニティ（affinity）」（すなわち特定のエンティティのためのすべての作業が、特定のサーバ・グループの同じサーバ上で処理されること）と呼ばれる。
【０００６】
こうしたアフィニティを確立するための従来技術の一方法（エンティティがトランザクションである一般的な例を挙げる）は、各サーバ・グループ内のサーバにトランザクションのマッピング・リストを配置するものである。ある要求がそのサーバ・グループに到達すると、その要求がトランザクションの一部であるか否かがチェックされ、そうである場合は、そのサーバ・グループの作業負荷マネージャによって、そのトランザクションがマッピング・リストにあるか否かがチェックされ、リスト上にある場合、マッピング・リストがそのトランザクションをグループ内のどのサーバにマップするかが決定される。次いで作業負荷マネージャは要求をその特定サーバに送信するので、特定トランザクションの一部であるサーバ・グループに要求が入ってくるごとに、グループ内の同じサーバが選択されるため、トランザクションのアフィニティが維持される。この従来技術は、ＩＢＭのソフトウェア製品Component Broker 390（ＣＢ／３９０）（「Component Broker 390」および「ＣＢ／３９０」は、ＩＢＭ社の登録商標である）で実施されてきた。さらに、ＩＢＭのソフトウェア製品ＣＩＣＳＰｌｅｘＳＭ（「ＣＩＣＳＰｌｅｘＳＭ」はＩＢＭ社の登録商標である）でも実施されてきた。
【０００７】
【発明が解決しようとする課題】
この従来技術には、不利な点がある。具体的に言えば、トランザクションが完了すると、こうした完了済みトランザクションのマッピングをマッピング・テーブル内で維持する必要がなくなり、そうでなければテーブルは役に立たなくなった情報で膨れ上がってしまう。したがって従来技術では、マッピング・テーブルを常時維持する（すなわち「クリーン・アップする」）必要があるので、各サーバ・グループ内に特別な維持コードが必要となる。
【０００８】
【課題を解決するための手段】
本発明は、その一態様によれば、作業負荷によって管理されるサーバ・データ処理プロセスのグループを含み、そのそれぞれのプロセスが作業要求を実行する機能を有するサーバに対してクライアントが作業要求を送信する、クライアント／サーバ・データ処理システムにおいて、サーバ・データ処理プロセスを実行するサーバ・データ処理装置であって、作業負荷によって管理されるサーバ・データ処理プロセスの複数のグループのそれぞれに特定のサーバ・データ処理プロセスをマッピングする、マッピング・データを格納するデータ記憶ユニットと、作業負荷によって管理されるサーバ・データ処理プロセスの特定のグループに対応する、マップされたサーバ・データ処理プロセスの識別を求める要求をクライアントから受け取る手段であって、この特定グループがその要求中で指定されている手段と、受け取った要求中で指定される特定グループについて、マップされたサーバ・データ処理プロセスの識別を決定するために、データ記憶ユニットにアクセスする手段と、マップされたサーバ・データ処理プロセスの識別をクライアントに返す手段とを含み、クライアントから受け取った要求が、サーバ・データ処理プロセスの継続時間と結合された継続時間を有するエンティティに関連付けられている装置を提供する。
【０００９】
本発明は、第２の態様によれば、第１の態様に関して前述した機能を実行するための方法を提供する。
【００１０】
本発明は、第３の態様によれば、コンピュータ上で実行する際に、第１の態様に関して前述した機能を実行するための、コンピュータ読取り可能記憶媒体上に記憶されたコンピュータ・プログラム製品を提供する。
【００１１】
したがって本発明は、特定の要求元エンティティに関するサーバに対するサーバ・グループのマッピング・リストを、各サーバ・グループではなく中央位置で維持する。要求元エンティティがサーバ・グループにアクセスしたい場合、この要求元エンティティはまずこの中央位置にアクセスし、特定のサーバ・グループについて、そのサーバ・グループ内のどのサーバを使用するべきかを決定する。これによって、エンティティが必要なくなったとき（たとえばトランザクションの完了時）に実行しなければならない維持量が大幅に削減される。
【００１２】
従来技術では、シングル・ポイント障害（single point of failure）になる（すなわち、集中型マッピングがダウンすると、これに依存するシステム全体が動作不能になる）ことがあるという理由から、この集中型マッピングの使用を避けてきた。ただし、その継続時間（すなわちライフサイクル）が要求元エンティティのライフサイクルに結合されている単一プロセス内で集中型マッピングが維持されるため、本発明の状況ではシングル・ポイント障害は問題とみなされない。
【００１３】
たとえば、要求元エンティティがトランザクションの場合、マッピング・データを維持するための中央位置はトランザクションのルート（すなわちトランザクション・ツリーの最上位）に格納されるため、トランザクションが完了すると、このトランザクション・ツリーは自動的に削除される。マッピング・リストをトランザクションのルートに配置すると、要求プロセスはルートに到達するまでトランザクション・ツリーを逆方向に追跡するだけでよいので、トランザクション内の要求プロセスにとって、この中央位置を見つけるのが非常に容易になるという利点がある。すなわち、既存のトランザクション・ツリー構造を、要求プロセスからマッピング・リストの中央位置までの経路として使用することができる。
【００１４】
【発明の実施の形態】
本発明の好ましい実施形態は、ＣＯＲＢＡ（共通オブジェクト要件ブローカ、Common Object Request Broker）のＯＴＳ（オブジェクト・トランザクション・サービス、Object Transaction Service）標準により実施される。次に、この特定環境に関するいくつかの背景を示す。
【００１５】
クライアント／サーバ・コンピューティングの利点は、クライアントとサーバを異なる（異種の（heterogeneous））「プラットフォーム」上に配置することができる、オブジェクト指向プログラミング（object-oriented programming、ＯＯＰ）と呼ばれるよく知られたコンピュータ・プログラミング技術を使用することによって、さらに拡大されてきた。プラットフォームとは、マシンが作業を実行する際に使用する、特有のハードウェア／ソフトウェア／オペレーティング・システム／通信プロトコルの組み合わせである。ＯＯＰは、クライアント・アプリケーションの作業要求がサーバ・アプリケーションによってどのように通信され受け入れられるかを気にすることなく、クライアント・アプリケーション・プログラムとサーバ・アプリケーション・プログラムがそれ自体のプラットフォーム上で動作できるようにする。同様に、サーバ・アプリケーションは、ＯＯＰシステムがサーバ・アプリケーションの処理結果をどのように受け取り、変換して、要求元クライアント・アプリケーションに送り返すかを気にする必要はない。
【００１６】
ＯＯＰ技法が異種のクライアント／サーバ・システムとどのように統合されてきたかについての詳細は、米国特許第５４４０７４４号および欧州特許出願公開明細書ＥＰ０６７７９４３ Ａ２号に記載されている。ただし、本発明の環境の前後関係を理解するために、基本アーキテクチャの例を下記に記載する。
【００１７】
図１に示すように、クライアント・コンピュータ１０（たとえばＩＢＭのオペレーティング・システムであるＯＳ／２がインストールされているパーソナル・コンピュータなど）は、そのオペレーティング・システム上で動作するアプリケーション・プログラム４０を有する（「ＩＢＭ」および「ＯＳ／２」は、インターナショナル・ビジネス・マシーンズ・コーポレイションの登録商標である）。このアプリケーション・プログラム４０は、サーバ・コンピュータ２０上で実行される作業、またはアプリケーション・プログラム４０が後で使用するためにサーバ２０から戻されるデータ、あるいはその両方を定期的に必要とする。サーバ・コンピュータ２０は、たとえばＩＢＭのオペレーティング・システムであるＭＶＳ（「ＭＶＳ」もＩＢＭ社の登録商標である）上で動作する高性能メインフレーム・コンピュータであってもよい。サーバによる通信サービスの実行を求める要求が、第１のアプリケーション・プログラム４０とユーザとの対話によって起こされるか、それともアプリケーション・プログラム４０がユーザとの対話とは独立に動作してプログラム実行中に自動的に要求を行うかは、本発明の目的には無関係である。
【００１８】
クライアント・コンピュータ１０がサーバ・コンピュータ２０のサービスを要求したい場合、第１のアプリケーション・プログラム４０は、第１の論理手段５０に必要なサービスを伝える。これはたとえば、第１の論理手段に、リモート・プロシージャ名ならびに入力パラメータと出力パラメータのリストを送信することで実行される。次いで第１の論理手段５０は、記憶デバイス６０に格納された使用可能な通信サービスの定義を参照しながら、必要な第２のコンピュータ２０との通信を確立するタスクを処理する。可能なすべてのサービスは、オブジェクト・クラスのコヒーシブ・フレームワーク（cohesive framework）７０として定義され、これらのクラスは単一のオブジェクト・クラスから引き出される。このようにしてサービスを定義すると、パフォーマンスおよび再使用可能性に関して数多くの利点が得られる。
【００１９】
必要なサーバ２０との通信を確立するために、第１の論理手段５０は、フレームワーク内のどのオブジェクト・クラスを使用する必要があるかを決定し、次いでそのオブジェクトのインスタンスをサーバ側で作成し、そのオブジェクトにそのメソッドの１つを呼び出させるように、そのオブジェクトにメッセージを送信する。これにより、接続手段８０を介してサーバ・コンピュータ２０との接続が確立され、第２の論理手段９０に後続の要求が送信される。
【００２０】
次いで第２の論理手段９０は、その要求をサーバ・コンピュータ２０上で動作する第２のアプリケーション・プログラム１００（以下、サービス・アプリケーションと呼ぶ）に渡して、その要求によって必要とされるデータ検索手順の実行など特有のタスクをサービス・アプリケーション１００が実行できるようにする。このタスクが完了すると、サービス・アプリケーションは、結果を第１のコンピュータ１０に返信する必要が生じる場合がある。サービス・アプリケーション１００は、要求されたタスクの実行中、および第１のコンピュータ１０に結果が返信されるときに、第２の論理手段９０と対話する。第２の論理手段９０はオブジェクトのインスタンスを確立し、サービス・アプリケーション１００によって必要とされるとおりに、かつ必要とされるときに、それらオブジェクトの適切なメソッドを呼び出し、このオブジェクト・インスタンスは、記憶デバイス１１０に格納されたオブジェクト・クラスのコヒーシブ・フレームワークから作成される。
【００２１】
上記技法を使用すると、クライアント・アプリケーション・プログラム４０は、通信アーキテクチャと直に接して（exposed to）いない。さらにサービス・アプリケーション１００は、その環境の標準機構を介して呼び出され、リモートに呼び出されていることに気付かない。
【００２２】
オブジェクト・マネージメント・グループ（Object Management Group、ＯＭＧ）は、図１に示すような分散オブジェクトを備えた異種プラットフォーム上での、クライアント／サーバ・コンピューティングの様々な態様に関係する、国際的な業界団体である。ＯＭＧは、クライアント・コンピュータ（たとえば１０）がサーバ・マシン（たとえば２０）と（ＯＯＰ形式で）交信する際に使用する公式の標準を発表した。これら標準の一部として、ＯＲＢ（オブジェクト要求ブローカ、Object Request Broker）標準（ＣＯＲＢＡ、共通オブジェクト要求ブローカアーキテクチャ、Common Object Request Broker Architectureと呼ばれる）が定義されたが、これは、クライアント・マシンとサーバ・マシンとの間にオブジェクト指向のブリッジを提供するものである。ＯＲＢは、第１論理手段５０と第２論理手段９０ならびに接続手段８０の作業の少なくとも一部を実行して、クライアント・アプリケーションおよびサーバ・アプリケーションを、オブジェクト指向の実施の詳細から切り離す。
【００２３】
ＯＭＧは、ＣＯＲＢＡソフトウェア構造の一部として「トランザクション」に関係する標準を発表したが、これらの標準は、ＯＴＳ、すなわちオブジェクト・トランザクション・サービス（Object Transaction Service）として知られている。たとえば、１９９４年８月４日付のCORBA Object Transaction Service Specification 1.0、OMG Documentを参照されたい。コンピュータで実施されるトランザクション処理システムは、いくつかの業界で、重大な業務上のタスクに使用されている。トランザクションは、アクションなしですべて完了されなければならない、またはすべてパージされなければならない単一の作業単位を定義する。たとえば、顧客が現金を引き出す銀行の現金自動預け払い機の場合、現金を出すアクションと、機械の中に入っている現金の残高を減らすアクションと、顧客の預金残高を減らすアクションは、すべてが発生するか、あるいはどれも発生しないかのいずれかでなければならない。従属アクション（subordinate action）のいずれか１つでも失敗すると、記録と実際の発生との間に矛盾が生じてしまう。
【００２４】
分散トランザクション処理は、複数の物理的または論理的位置にあるリソースに影響を与えるトランザクションに関係する。前述の例では、トランザクションは、ローカルの現金自動預け払い機で管理されるリソース、ならびに銀行のメイン・コンピュータによって管理される預金残高に影響を与える。このようなトランザクションは、サーバによって処理される一連のクライアント要求を介してある特定のサーバ・コンピュータ（たとえば２０）と通信する、ある特定のクライアント・コンピュータ（たとえば１０）に関係する。ＯＭＧのＯＴＳの実施は、これらの分散トランザクションを調整する役割を果たす。
【００２５】
クライアント・プロセス上で動作するアプリケーションは、複数の異なるサーバの呼出しに関係するトランザクションを開始し、それぞれのサーバが、トランザクションに含まれる命令に従ってローカル・データを変更するためのサーバ・プロセスを開始する。このトランザクションは、トランザクションをコミットする（したがって、すべてのサーバがそのローカル・データへの変更を最終的なものにする）か、またはトランザクションを打ち切る（したがって、すべてのサーバが「ロールバック」する、すなわちトランザクション中にそのローカル・データに加えられた変更を無視する）ことによって終了する。トランザクション中にサーバと通信する（たとえば、トランザクション中のサーバ部分をコミットするまたは打ち切るようサーバに指示する）には、関係するプロセスの１つがそのトランザクションの状態データを維持しなければならない。ＯＴＳ標準によれば、これは、プロセスが、そのうちの１つが様々なサーバに関してトランザクションを調整するコーディネータ・オブジェクト（coordinator object）である、一連のオブジェクトをセットアップすることを必要とする。
【００２６】
このコーディネータ・オブジェクトの主な目的は、どのサーバ・オブジェクトがトランザクションに関係しているかを追跡することであるため、トランザクションが完了すると、１回の統一された努力で、そのトランザクションに関係するそれぞれのサーバ・オブジェクトに対して、そのサーバ・オブジェクトに関連付けられたローカル・データベースにローカルに加えられた変更をコミットするよう通知することができる。これにより、サーバ・オブジェクトがデータの変更を最終的なものにするには、同じトランザクションに関係している他のサーバ・オブジェクトもそうしなければならないことが保証される。したがって、１つのトランザクションに参加する各サーバ・オブジェクトは、まずコーディネータ・オブジェクトに登録して、トランザクションを完了することになったとき（コーディネータ・オブジェクトがすべてのサーバ・オブジェクトにそれぞれのローカル・データの変更を最終的なものにするよう指示したとき）に、そのサーバ・オブジェクトの存在、トランザクションへの参加の意思、およびサーバ・オブジェクトの場所（たとえば、そのサーバ・オブジェクトがどのサーバ・マシンに常駐しているか）がコーディネータ・オブジェクトにわかるようにしなければならない。
【００２７】
データの更新を担当するサーバ・オブジェクト（以下、リソース・オブジェクトと呼ぶ）は、別のサーバ・オブジェクト（またはトランザクションを開始した元のクライアント・オブジェクト）が何らかの作業を実行することを求める要求をリソース・オブジェクトに送ったとき、そのトランザクションに関わり合う。この後者の要求は、その要求がトランザクションの一部であることをリソース・オブジェクトに知らせる、トランザクション・コンテキストと呼ばれる何らかの情報を搬送する。ＣＯＲＢＡバージョン２では、このトランザクション・コンテキストは、ローカルのCosTransactions::Coordinator object get_txcontextメソッドによって構築される。リソース・オブジェクトがトランザクションに関わり合うべきことがわかると、コーディネータ・オブジェクトへの登録要求を行う。
【００２８】
リソース・オブジェクトが、コーディネータ・オブジェクトとは別のオペレーティング・システム・プロセスに配置されている場合、リソース・オブジェクト（図２の２２３または２２４）と同じオペレーティング・システム・プロセスに配置された従属コーディネータ・オブジェクト（２２２）を使用すると便利であることがわかっている。そこでこのメイン・コーディネータ・オブジェクトは「優位コーディネータ・オブジェクト（superior coordinator object）」２１１と呼ばれる。リソース・オブジェクト２２３をトランザクションに登録する際、従属コーディネータ２２２はそのリソース・オブジェクト２２３を収容するサーバ・マシン２２内部でローカルにセットアップされ、リソース・オブジェクト２２３は登録要求を行うときにこの従属コーディネータ・オブジェクト２２２と直接通信する。（本明細書では「サーバ・マシン」という用語を使用するが、実際には分散サーバ・オブジェクトが、同じサーバ・マシン上にあって、そのサーバ・マシン上で動作する別のオペレーティング・システム・プロセス上に配置できるということを示すために、「サーバ・プロセス」という用語も使用できるため、以下、どちらの用語を表すのにも「サーバ」という用語を使用することに留意されたい。）次に従属コーディネータ２２２は、それ自体を（リソース・オブジェクトの場合と同様に、別のサーバ・マシン上にあってもよい別のプロセスに配置されている）優位コーディネータ・オブジェクト２１１に登録する。
【００２９】
この従属コーディネータ・オブジェクト２２２は、リソース・オブジェクトを収容しているサーバ内にトランザクションが存在するか否かを示す。リソース・オブジェクト２２３および２２４は、優位コーディネータ・オブジェクト２１１と直接通信するのではなく、まずそれらのローカル従属コーディネータ・オブジェクト２２２と通信し、次いでこれが優位コーディネータ・オブジェクトと通信する。この方法により、オペレーティング・システム・プロセス相互間の呼出しの数が大幅に削減される。
【００３０】
図３で、サーバ・プロセス３１は、ルート・コーディネータ３１１（優位コーディネータとも呼ばれる）ならびに、システム・メモリ内に格納されたマッピング・テーブル３１２を含んでいる。次に、識別子（名前）「サーバ・グループ１」を有するサーバ（サーバＡ、Ｂ、Ｃ）の第１グループ３２が提供され、各サーバはそれ自体のプロセスで実行中である。同様にして次に、識別子「サーバ・グループ２」を有するサーバ（サーバＤ、Ｅ、Ｆ）の第２グループ３３が提供される。
【００３１】
実行中の各トランザクションごとに、マッピング・テーブル３１２がルート・コーディネータ３１１と同じサーバ・プロセス内に維持される。マッピング・テーブル３１２（図４に詳細に図示）は、特定のトランザクションについて、第１列３１２１にサーバ・グループ（たとえばサーバ・グループ１）の識別子をリスト表示し、その横の第２列３１２２に対応するマップされたサーバ（たとえばサーバＣ）の識別をリスト表示する。したがってこのマッピング・テーブルは、テーブルがそれに対してセットアップされたトランザクションの一部である要求が、サーバ・グループ１のサーバの１つにアクセスすることを希望したときには必ず、アクセスされるべきサーバがサーバＣであるという事実を追跡する。同様に、テーブルがそれに対してセットアップされたトランザクションの一部である要求が、サーバ・グループ２のサーバの１つにアクセスすることを希望したときには必ず、アクセスされるべきサーバはサーバＥである。サーバ３１は、マッピング・テーブル３１２を、そのCosTransactions::Coordinator情報の一部として、たとえば、「AffinityMappingｓ」と呼ばれるクラスのインスタンスとして維持する。ルート・コーディネータのマッピング・テーブル３１２が、要求されたサーバ・グループのエントリを含まない場合、このルート・コーディネータはそのサーバ・グループ内にあるサーバの１つを（たとえば任意に、または何らかの基準に基づいて）選択し、対応する新しいマッピング・エントリがルートのマッピング・テーブル３１２に追加される。
【００３２】
サーバ３１によって実行される動作ステップを図５の流れ図に示し、以下に説明する。
【００３３】
実行中のトランザクションの一部として、サーバ・グループ２のサーバＥが、サーバ・グループ１のサーバの１つに１単位の作業要求を送信する必要があると想定する。サーバＥは、サーバＥに対してローカルな実行中のトランザクションに、どのリソースが関係するかを追跡する、従属コーディネータ３３１を含む。本発明の好ましい実施形態によれば、サーバＥは、サーバＥが実行中のトランザクションの一部として作業要求単位を送信するのに、サーバ・グループ１のどのサーバ（Ａ、Ｂ、またはＣ）を使用すべきかをサーバ３１がサーバＥに伝えるよう要求する相互プロセス要求を、サーバ３１のルート・コーディネータ３１１に送信する（図３円で囲んだ１の付いた矢印）。すなわちサーバＥは、サーバ・グループ１にあるサーバの１つに作業要求を送信しなければならないことはわかるが、３つのサーバ（Ａ、Ｂ、またはＣ）のどれにその要求を送信するべきかはわからない。したがって、選択すべきサーバ（Ａ、Ｂ、またはＣ）の識別を知るために、サーバＥは要求（円で囲んだ１）をサーバ３１に送信する。
【００３４】
ルート・コーディネータ３１１が、トランザクション・ツリーの最上位にあり、ルート・コーディネータ３１１に比べて下位の（従属）位置にある従属コーディネータ３３１を含むことに留意されたい。したがって、従属コーディネータ３３１は、サーバ３１内に配置されたトランザクション・ツリーをツリー最上位のコーディネータ（ルート・コーディネータ３１１）までたどればよいだけなので、従属コーディネータ３３１は、要求（円で囲んだ１）のターゲットとすべきサーバ・プロセス３１を簡単に見つけることができる。
【００３５】
サーバＥからの要求（円で囲んだ１）を受け取ると（図５のステップ５１）、サーバ３１は、図４に示すシステム・メモリからマッピング・テーブル３１２にアクセスする。サーバＥから受け取った要求には、サーバＥが注目する特定のサーバ・グループ（この場合はサーバ・グループ１）の識別表示が含まれる。サーバ３１はこのサーバ・グループ識別を使用してマッピング・テーブル３１２にアクセスし（ステップ５２）、列３１２１のサーバ・グループ１について、サーバＣが隣の列３１２２に配置されていることを、このテーブルから読み取る。すなわちサーバ・グループ１は、マッピング・テーブル３１２に基づいてサーバＣにマッピングされる。
【００３６】
その後サーバ３１は、サーバＣの識別をサーバＥに（円で囲んだ２の付いた矢印）返信する（ステップ５３）。これにより、サーバＣにサーバＥが接触すべきことがサーバＥに伝えられる。次いでサーバＥは、サーバＣにトランザクション要求（円で囲んだ３の付いた矢印）を送信する。
【００３７】
これにより、この特定のトランザクションに関して、サーバ・グループ１のいずれかのサーバにアクセスするときは必ずサーバＣが選択されるので、トランザクションのアフィニティが維持される。
【００３８】
パフォーマンスを向上させるために、サーバ・グループ１のサーバＣへのマッピングを、サーバＥにある従属コーディネータ３３１でキャッシュすることができる。従属コーディネータは、そのようなマッピング情報がローカルにキャッシュされない場合、その優位コーディネータにマッピング情報を要求する。したがってこのマッピング情報を求める要求は、情報が得られるまで、トランザクション・ツリーを上方に向かって繰返し伝達される（すなわち従属コーディネータは、ローカルにまたはトランザクション・ツリーの中間ノードに格納することができるので、アフィニティ・マッピング情報を得るために必ずしもルートを照会する必要がない）。
【００３９】
図３では、本発明の好ましい実施形態を簡単に図示するために、非常に単純なトランザクションが使用されていることに留意されたい。実際には、これよりもかなり複雑なトランザクションが使用され、たとえば従属コーディネータ３３１は、その下にいくつかの他の従属コーディネータ層を有する。このように複雑なトランザクションの場合、従属コーディネータは、トランザクション・ツリー内で、トランザクションの一部としてサーバ・グループと接触する必要のあるルート・コーディネータ３１１からかなり遠く離れるが、マッピング・テーブルを含むサーバ・プロセスの位置を求めるためには、（従属コーディネータ３３１を介して）最上位のルート・コーディネータ３１１までトランザクション・ツリーをすべて逆方向に追跡するだけでよい。
【００４０】
マッピング・テーブルが単一の（中央）位置に配置されていることは、シングル・ポイント障害であるが、マッピング・テーブル３１２は、そのためにセットアップされた特定トランザクションだけに関連しており、マッピング・テーブル３１２へのアクセスを調整するルート・コーディネータ３１１は、トランザクション自体と同じライフサイクルである（トランザクションが完了するとルート・コーディネータは削除される）ことも留意されたい。したがって本発明では、シングル・ポイント障害があるという事実によって、それほど重大な問題が発生することはない。
【００４１】
以上、トランザクションがマッピング・テーブルの作成されるエンティティであるという状況における好ましい実施形態について述べてきたが、本発明はこれに限定されるものではない。たとえば、クライアントがこのエンティティであってもよい。すなわち、特定クライアントの代わりにマッピング・テーブルをセットアップすることができ、このテーブルには、クライアントがサーバ・グループへのアクセスを希望するたびに必ず使用するサーバ・グループ／サーバ・マッピングが含まれる。このマッピング・テーブルを含むサーバ・プロセスのライフサイクルは、シングル・ポイント障害の問題を避けるための何らかの所定の方法で、クライアントのライフサイクルと結合される。
【図面の簡単な説明】
【図１】本発明の好ましい実施形態によるオブジェクト指向のクライアント／サーバ環境を示すのに役立つ構成図である。
【図２】本発明の好ましい実施形態の環境である、ＣＯＲＢＡ ＯＴＳの様々な構成要素を示すのに役立つ構成図である。
【図３】本発明の好ましい実施形態を例示するのに使用される様々なデータ処理プロセスの一例を示す構成図である。
【図４】本発明の好ましい実施形態により、図３のマッピング・テーブルを詳細に示した図である。
【図５】本発明の好ましい実施形態により、ルート・コーディネータを有するサーバによって実行される動作ステップを示す流れ図である。
【符号の説明】
３１ サーバ
３２ サーバ・グループ１
３３ サーバ・グループ２
３１１ ルート・コーディネータ
３１２ マッピング・テーブル
３３１ 従属コーディネータ
Ａ サーバＡ
Ｂ サーバＢ
Ｃ サーバＣ
Ｄ サーバＤ
Ｅ サーバＥ
Ｆ サーバＦ
【発明の属する技術分野】
本発明は、データ処理の分野に関する。さらに詳細には、クライアント・データ処理システムから出される作業要求に関して、サーバ・データ処理システム・グループが作業負荷によって管理されている場合に関する。
【０００２】
【従来の技術】
クライアント／サーバ・コンピューティングは、情報技術の世界でここ数年ますます重要なものになってきている。この種の分散コンピューティングは、あるマシンの作業の一部を、たとえばその作業を実行するのにより好適であると思われる他のマシンに任せることができるようにするものである。たとえばサーバは、莫大な量のデータの格納を管理するデータベース・プログラムを実行する高性能コンピュータであり、クライアントは単に、そのローカル・プログラムの１つで使用するためにデータベースから情報を要求するデスクトップ型パーソナル・コンピュータ（ＰＣ）である。
【０００３】
クライアント／サーバのデータ処理において、クライアントは一単位の作業要求を、クライアントに代わってその作業単位を実行する能力があるとわかっている特定サーバに向けて送る。もちろんサーバはクライアントとしても機能することができるので、サーバ間要求も普通のことである。特定サーバに向けて大量の要求が送られることが予想される場合や、サーバが常時動作状態でなければならない場合には、それぞれ一定単位の作業を実行できるサーバのグループを提供することはごく普通のことである。このサーバ・グループに向けて特定の一単位の作業が送られると、作業負荷管理ユニットは、この特定単位の作業要求をこのサーバ・グループのどの特定のメンバに割り当てるべきかを決定する。たとえば、グループ内で最もビジーでないサーバが選択されあるいは、グループ内の１つのサーバが誤動作を起こしている場合には、グループ内の他のサーバが要求を処理するために選択される。
【０００４】
以下の説明では、サーバ・グループへのアクセスを試みている作業要求単位の発信元を「エンティティ」と呼ぶ。エンティティはクライアントである場合がある。また他の場合（こちらの方が一般的である）に、エンティティはトランザクションであり、そのため実行中のデータ処理のタイプはトランザクション処理と呼ばれる。
【０００５】
あるサーバ・グループにアクセス中のエンティティが、後で同じサーバ・グループに再度アクセスする場合、この後のアクセスは前のアクセス中に使用されたグループ内にある同じサーバに戻るのが、非常に有利である。これによってデータの保全性が維持され、パフォーマンスも向上する。これは従来技術では「アフィニティ（affinity）」（すなわち特定のエンティティのためのすべての作業が、特定のサーバ・グループの同じサーバ上で処理されること）と呼ばれる。
【０００６】
こうしたアフィニティを確立するための従来技術の一方法（エンティティがトランザクションである一般的な例を挙げる）は、各サーバ・グループ内のサーバにトランザクションのマッピング・リストを配置するものである。ある要求がそのサーバ・グループに到達すると、その要求がトランザクションの一部であるか否かがチェックされ、そうである場合は、そのサーバ・グループの作業負荷マネージャによって、そのトランザクションがマッピング・リストにあるか否かがチェックされ、リスト上にある場合、マッピング・リストがそのトランザクションをグループ内のどのサーバにマップするかが決定される。次いで作業負荷マネージャは要求をその特定サーバに送信するので、特定トランザクションの一部であるサーバ・グループに要求が入ってくるごとに、グループ内の同じサーバが選択されるため、トランザクションのアフィニティが維持される。この従来技術は、ＩＢＭのソフトウェア製品Component Broker 390（ＣＢ／３９０）（「Component Broker 390」および「ＣＢ／３９０」は、ＩＢＭ社の登録商標である）で実施されてきた。さらに、ＩＢＭのソフトウェア製品ＣＩＣＳＰｌｅｘＳＭ（「ＣＩＣＳＰｌｅｘＳＭ」はＩＢＭ社の登録商標である）でも実施されてきた。
【０００７】
【発明が解決しようとする課題】
この従来技術には、不利な点がある。具体的に言えば、トランザクションが完了すると、こうした完了済みトランザクションのマッピングをマッピング・テーブル内で維持する必要がなくなり、そうでなければテーブルは役に立たなくなった情報で膨れ上がってしまう。したがって従来技術では、マッピング・テーブルを常時維持する（すなわち「クリーン・アップする」）必要があるので、各サーバ・グループ内に特別な維持コードが必要となる。
【０００８】
【課題を解決するための手段】
本発明は、その一態様によれば、作業負荷によって管理されるサーバ・データ処理プロセスのグループを含み、そのそれぞれのプロセスが作業要求を実行する機能を有するサーバに対してクライアントが作業要求を送信する、クライアント／サーバ・データ処理システムにおいて、サーバ・データ処理プロセスを実行するサーバ・データ処理装置であって、作業負荷によって管理されるサーバ・データ処理プロセスの複数のグループのそれぞれに特定のサーバ・データ処理プロセスをマッピングする、マッピング・データを格納するデータ記憶ユニットと、作業負荷によって管理されるサーバ・データ処理プロセスの特定のグループに対応する、マップされたサーバ・データ処理プロセスの識別を求める要求をクライアントから受け取る手段であって、この特定グループがその要求中で指定されている手段と、受け取った要求中で指定される特定グループについて、マップされたサーバ・データ処理プロセスの識別を決定するために、データ記憶ユニットにアクセスする手段と、マップされたサーバ・データ処理プロセスの識別をクライアントに返す手段とを含み、クライアントから受け取った要求が、サーバ・データ処理プロセスの継続時間と結合された継続時間を有するエンティティに関連付けられている装置を提供する。
【０００９】
本発明は、第２の態様によれば、第１の態様に関して前述した機能を実行するための方法を提供する。
【００１０】
本発明は、第３の態様によれば、コンピュータ上で実行する際に、第１の態様に関して前述した機能を実行するための、コンピュータ読取り可能記憶媒体上に記憶されたコンピュータ・プログラム製品を提供する。
【００１１】
したがって本発明は、特定の要求元エンティティに関するサーバに対するサーバ・グループのマッピング・リストを、各サーバ・グループではなく中央位置で維持する。要求元エンティティがサーバ・グループにアクセスしたい場合、この要求元エンティティはまずこの中央位置にアクセスし、特定のサーバ・グループについて、そのサーバ・グループ内のどのサーバを使用するべきかを決定する。これによって、エンティティが必要なくなったとき（たとえばトランザクションの完了時）に実行しなければならない維持量が大幅に削減される。
【００１２】
従来技術では、シングル・ポイント障害（single point of failure）になる（すなわち、集中型マッピングがダウンすると、これに依存するシステム全体が動作不能になる）ことがあるという理由から、この集中型マッピングの使用を避けてきた。ただし、その継続時間（すなわちライフサイクル）が要求元エンティティのライフサイクルに結合されている単一プロセス内で集中型マッピングが維持されるため、本発明の状況ではシングル・ポイント障害は問題とみなされない。
【００１３】
たとえば、要求元エンティティがトランザクションの場合、マッピング・データを維持するための中央位置はトランザクションのルート（すなわちトランザクション・ツリーの最上位）に格納されるため、トランザクションが完了すると、このトランザクション・ツリーは自動的に削除される。マッピング・リストをトランザクションのルートに配置すると、要求プロセスはルートに到達するまでトランザクション・ツリーを逆方向に追跡するだけでよいので、トランザクション内の要求プロセスにとって、この中央位置を見つけるのが非常に容易になるという利点がある。すなわち、既存のトランザクション・ツリー構造を、要求プロセスからマッピング・リストの中央位置までの経路として使用することができる。
【００１４】
【発明の実施の形態】
本発明の好ましい実施形態は、ＣＯＲＢＡ（共通オブジェクト要件ブローカ、Common Object Request Broker）のＯＴＳ（オブジェクト・トランザクション・サービス、Object Transaction Service）標準により実施される。次に、この特定環境に関するいくつかの背景を示す。
【００１５】
クライアント／サーバ・コンピューティングの利点は、クライアントとサーバを異なる（異種の（heterogeneous））「プラットフォーム」上に配置することができる、オブジェクト指向プログラミング（object-oriented programming、ＯＯＰ）と呼ばれるよく知られたコンピュータ・プログラミング技術を使用することによって、さらに拡大されてきた。プラットフォームとは、マシンが作業を実行する際に使用する、特有のハードウェア／ソフトウェア／オペレーティング・システム／通信プロトコルの組み合わせである。ＯＯＰは、クライアント・アプリケーションの作業要求がサーバ・アプリケーションによってどのように通信され受け入れられるかを気にすることなく、クライアント・アプリケーション・プログラムとサーバ・アプリケーション・プログラムがそれ自体のプラットフォーム上で動作できるようにする。同様に、サーバ・アプリケーションは、ＯＯＰシステムがサーバ・アプリケーションの処理結果をどのように受け取り、変換して、要求元クライアント・アプリケーションに送り返すかを気にする必要はない。
【００１６】
ＯＯＰ技法が異種のクライアント／サーバ・システムとどのように統合されてきたかについての詳細は、米国特許第５４４０７４４号および欧州特許出願公開明細書ＥＰ０６７７９４３ Ａ２号に記載されている。ただし、本発明の環境の前後関係を理解するために、基本アーキテクチャの例を下記に記載する。
【００１７】
図１に示すように、クライアント・コンピュータ１０（たとえばＩＢＭのオペレーティング・システムであるＯＳ／２がインストールされているパーソナル・コンピュータなど）は、そのオペレーティング・システム上で動作するアプリケーション・プログラム４０を有する（「ＩＢＭ」および「ＯＳ／２」は、インターナショナル・ビジネス・マシーンズ・コーポレイションの登録商標である）。このアプリケーション・プログラム４０は、サーバ・コンピュータ２０上で実行される作業、またはアプリケーション・プログラム４０が後で使用するためにサーバ２０から戻されるデータ、あるいはその両方を定期的に必要とする。サーバ・コンピュータ２０は、たとえばＩＢＭのオペレーティング・システムであるＭＶＳ（「ＭＶＳ」もＩＢＭ社の登録商標である）上で動作する高性能メインフレーム・コンピュータであってもよい。サーバによる通信サービスの実行を求める要求が、第１のアプリケーション・プログラム４０とユーザとの対話によって起こされるか、それともアプリケーション・プログラム４０がユーザとの対話とは独立に動作してプログラム実行中に自動的に要求を行うかは、本発明の目的には無関係である。
【００１８】
クライアント・コンピュータ１０がサーバ・コンピュータ２０のサービスを要求したい場合、第１のアプリケーション・プログラム４０は、第１の論理手段５０に必要なサービスを伝える。これはたとえば、第１の論理手段に、リモート・プロシージャ名ならびに入力パラメータと出力パラメータのリストを送信することで実行される。次いで第１の論理手段５０は、記憶デバイス６０に格納された使用可能な通信サービスの定義を参照しながら、必要な第２のコンピュータ２０との通信を確立するタスクを処理する。可能なすべてのサービスは、オブジェクト・クラスのコヒーシブ・フレームワーク（cohesive framework）７０として定義され、これらのクラスは単一のオブジェクト・クラスから引き出される。このようにしてサービスを定義すると、パフォーマンスおよび再使用可能性に関して数多くの利点が得られる。
【００１９】
必要なサーバ２０との通信を確立するために、第１の論理手段５０は、フレームワーク内のどのオブジェクト・クラスを使用する必要があるかを決定し、次いでそのオブジェクトのインスタンスをサーバ側で作成し、そのオブジェクトにそのメソッドの１つを呼び出させるように、そのオブジェクトにメッセージを送信する。これにより、接続手段８０を介してサーバ・コンピュータ２０との接続が確立され、第２の論理手段９０に後続の要求が送信される。
【００２０】
次いで第２の論理手段９０は、その要求をサーバ・コンピュータ２０上で動作する第２のアプリケーション・プログラム１００（以下、サービス・アプリケーションと呼ぶ）に渡して、その要求によって必要とされるデータ検索手順の実行など特有のタスクをサービス・アプリケーション１００が実行できるようにする。このタスクが完了すると、サービス・アプリケーションは、結果を第１のコンピュータ１０に返信する必要が生じる場合がある。サービス・アプリケーション１００は、要求されたタスクの実行中、および第１のコンピュータ１０に結果が返信されるときに、第２の論理手段９０と対話する。第２の論理手段９０はオブジェクトのインスタンスを確立し、サービス・アプリケーション１００によって必要とされるとおりに、かつ必要とされるときに、それらオブジェクトの適切なメソッドを呼び出し、このオブジェクト・インスタンスは、記憶デバイス１１０に格納されたオブジェクト・クラスのコヒーシブ・フレームワークから作成される。
【００２１】
上記技法を使用すると、クライアント・アプリケーション・プログラム４０は、通信アーキテクチャと直に接して（exposed to）いない。さらにサービス・アプリケーション１００は、その環境の標準機構を介して呼び出され、リモートに呼び出されていることに気付かない。
【００２２】
オブジェクト・マネージメント・グループ（Object Management Group、ＯＭＧ）は、図１に示すような分散オブジェクトを備えた異種プラットフォーム上での、クライアント／サーバ・コンピューティングの様々な態様に関係する、国際的な業界団体である。ＯＭＧは、クライアント・コンピュータ（たとえば１０）がサーバ・マシン（たとえば２０）と（ＯＯＰ形式で）交信する際に使用する公式の標準を発表した。これら標準の一部として、ＯＲＢ（オブジェクト要求ブローカ、Object Request Broker）標準（ＣＯＲＢＡ、共通オブジェクト要求ブローカアーキテクチャ、Common Object Request Broker Architectureと呼ばれる）が定義されたが、これは、クライアント・マシンとサーバ・マシンとの間にオブジェクト指向のブリッジを提供するものである。ＯＲＢは、第１論理手段５０と第２論理手段９０ならびに接続手段８０の作業の少なくとも一部を実行して、クライアント・アプリケーションおよびサーバ・アプリケーションを、オブジェクト指向の実施の詳細から切り離す。
【００２３】
ＯＭＧは、ＣＯＲＢＡソフトウェア構造の一部として「トランザクション」に関係する標準を発表したが、これらの標準は、ＯＴＳ、すなわちオブジェクト・トランザクション・サービス（Object Transaction Service）として知られている。たとえば、１９９４年８月４日付のCORBA Object Transaction Service Specification 1.0、OMG Documentを参照されたい。コンピュータで実施されるトランザクション処理システムは、いくつかの業界で、重大な業務上のタスクに使用されている。トランザクションは、アクションなしですべて完了されなければならない、またはすべてパージされなければならない単一の作業単位を定義する。たとえば、顧客が現金を引き出す銀行の現金自動預け払い機の場合、現金を出すアクションと、機械の中に入っている現金の残高を減らすアクションと、顧客の預金残高を減らすアクションは、すべてが発生するか、あるいはどれも発生しないかのいずれかでなければならない。従属アクション（subordinate action）のいずれか１つでも失敗すると、記録と実際の発生との間に矛盾が生じてしまう。
【００２４】
分散トランザクション処理は、複数の物理的または論理的位置にあるリソースに影響を与えるトランザクションに関係する。前述の例では、トランザクションは、ローカルの現金自動預け払い機で管理されるリソース、ならびに銀行のメイン・コンピュータによって管理される預金残高に影響を与える。このようなトランザクションは、サーバによって処理される一連のクライアント要求を介してある特定のサーバ・コンピュータ（たとえば２０）と通信する、ある特定のクライアント・コンピュータ（たとえば１０）に関係する。ＯＭＧのＯＴＳの実施は、これらの分散トランザクションを調整する役割を果たす。
【００２５】
クライアント・プロセス上で動作するアプリケーションは、複数の異なるサーバの呼出しに関係するトランザクションを開始し、それぞれのサーバが、トランザクションに含まれる命令に従ってローカル・データを変更するためのサーバ・プロセスを開始する。このトランザクションは、トランザクションをコミットする（したがって、すべてのサーバがそのローカル・データへの変更を最終的なものにする）か、またはトランザクションを打ち切る（したがって、すべてのサーバが「ロールバック」する、すなわちトランザクション中にそのローカル・データに加えられた変更を無視する）ことによって終了する。トランザクション中にサーバと通信する（たとえば、トランザクション中のサーバ部分をコミットするまたは打ち切るようサーバに指示する）には、関係するプロセスの１つがそのトランザクションの状態データを維持しなければならない。ＯＴＳ標準によれば、これは、プロセスが、そのうちの１つが様々なサーバに関してトランザクションを調整するコーディネータ・オブジェクト（coordinator object）である、一連のオブジェクトをセットアップすることを必要とする。
【００２６】
このコーディネータ・オブジェクトの主な目的は、どのサーバ・オブジェクトがトランザクションに関係しているかを追跡することであるため、トランザクションが完了すると、１回の統一された努力で、そのトランザクションに関係するそれぞれのサーバ・オブジェクトに対して、そのサーバ・オブジェクトに関連付けられたローカル・データベースにローカルに加えられた変更をコミットするよう通知することができる。これにより、サーバ・オブジェクトがデータの変更を最終的なものにするには、同じトランザクションに関係している他のサーバ・オブジェクトもそうしなければならないことが保証される。したがって、１つのトランザクションに参加する各サーバ・オブジェクトは、まずコーディネータ・オブジェクトに登録して、トランザクションを完了することになったとき（コーディネータ・オブジェクトがすべてのサーバ・オブジェクトにそれぞれのローカル・データの変更を最終的なものにするよう指示したとき）に、そのサーバ・オブジェクトの存在、トランザクションへの参加の意思、およびサーバ・オブジェクトの場所（たとえば、そのサーバ・オブジェクトがどのサーバ・マシンに常駐しているか）がコーディネータ・オブジェクトにわかるようにしなければならない。
【００２７】
データの更新を担当するサーバ・オブジェクト（以下、リソース・オブジェクトと呼ぶ）は、別のサーバ・オブジェクト（またはトランザクションを開始した元のクライアント・オブジェクト）が何らかの作業を実行することを求める要求をリソース・オブジェクトに送ったとき、そのトランザクションに関わり合う。この後者の要求は、その要求がトランザクションの一部であることをリソース・オブジェクトに知らせる、トランザクション・コンテキストと呼ばれる何らかの情報を搬送する。ＣＯＲＢＡバージョン２では、このトランザクション・コンテキストは、ローカルのCosTransactions::Coordinator object get_txcontextメソッドによって構築される。リソース・オブジェクトがトランザクションに関わり合うべきことがわかると、コーディネータ・オブジェクトへの登録要求を行う。
【００２８】
リソース・オブジェクトが、コーディネータ・オブジェクトとは別のオペレーティング・システム・プロセスに配置されている場合、リソース・オブジェクト（図２の２２３または２２４）と同じオペレーティング・システム・プロセスに配置された従属コーディネータ・オブジェクト（２２２）を使用すると便利であることがわかっている。そこでこのメイン・コーディネータ・オブジェクトは「優位コーディネータ・オブジェクト（superior coordinator object）」２１１と呼ばれる。リソース・オブジェクト２２３をトランザクションに登録する際、従属コーディネータ２２２はそのリソース・オブジェクト２２３を収容するサーバ・マシン２２内部でローカルにセットアップされ、リソース・オブジェクト２２３は登録要求を行うときにこの従属コーディネータ・オブジェクト２２２と直接通信する。（本明細書では「サーバ・マシン」という用語を使用するが、実際には分散サーバ・オブジェクトが、同じサーバ・マシン上にあって、そのサーバ・マシン上で動作する別のオペレーティング・システム・プロセス上に配置できるということを示すために、「サーバ・プロセス」という用語も使用できるため、以下、どちらの用語を表すのにも「サーバ」という用語を使用することに留意されたい。）次に従属コーディネータ２２２は、それ自体を（リソース・オブジェクトの場合と同様に、別のサーバ・マシン上にあってもよい別のプロセスに配置されている）優位コーディネータ・オブジェクト２１１に登録する。
【００２９】
この従属コーディネータ・オブジェクト２２２は、リソース・オブジェクトを収容しているサーバ内にトランザクションが存在するか否かを示す。リソース・オブジェクト２２３および２２４は、優位コーディネータ・オブジェクト２１１と直接通信するのではなく、まずそれらのローカル従属コーディネータ・オブジェクト２２２と通信し、次いでこれが優位コーディネータ・オブジェクトと通信する。この方法により、オペレーティング・システム・プロセス相互間の呼出しの数が大幅に削減される。
【００３０】
図３で、サーバ・プロセス３１は、ルート・コーディネータ３１１（優位コーディネータとも呼ばれる）ならびに、システム・メモリ内に格納されたマッピング・テーブル３１２を含んでいる。次に、識別子（名前）「サーバ・グループ１」を有するサーバ（サーバＡ、Ｂ、Ｃ）の第１グループ３２が提供され、各サーバはそれ自体のプロセスで実行中である。同様にして次に、識別子「サーバ・グループ２」を有するサーバ（サーバＤ、Ｅ、Ｆ）の第２グループ３３が提供される。
【００３１】
実行中の各トランザクションごとに、マッピング・テーブル３１２がルート・コーディネータ３１１と同じサーバ・プロセス内に維持される。マッピング・テーブル３１２（図４に詳細に図示）は、特定のトランザクションについて、第１列３１２１にサーバ・グループ（たとえばサーバ・グループ１）の識別子をリスト表示し、その横の第２列３１２２に対応するマップされたサーバ（たとえばサーバＣ）の識別をリスト表示する。したがってこのマッピング・テーブルは、テーブルがそれに対してセットアップされたトランザクションの一部である要求が、サーバ・グループ１のサーバの１つにアクセスすることを希望したときには必ず、アクセスされるべきサーバがサーバＣであるという事実を追跡する。同様に、テーブルがそれに対してセットアップされたトランザクションの一部である要求が、サーバ・グループ２のサーバの１つにアクセスすることを希望したときには必ず、アクセスされるべきサーバはサーバＥである。サーバ３１は、マッピング・テーブル３１２を、そのCosTransactions::Coordinator情報の一部として、たとえば、「AffinityMappingｓ」と呼ばれるクラスのインスタンスとして維持する。ルート・コーディネータのマッピング・テーブル３１２が、要求されたサーバ・グループのエントリを含まない場合、このルート・コーディネータはそのサーバ・グループ内にあるサーバの１つを（たとえば任意に、または何らかの基準に基づいて）選択し、対応する新しいマッピング・エントリがルートのマッピング・テーブル３１２に追加される。
【００３２】
サーバ３１によって実行される動作ステップを図５の流れ図に示し、以下に説明する。
【００３３】
実行中のトランザクションの一部として、サーバ・グループ２のサーバＥが、サーバ・グループ１のサーバの１つに１単位の作業要求を送信する必要があると想定する。サーバＥは、サーバＥに対してローカルな実行中のトランザクションに、どのリソースが関係するかを追跡する、従属コーディネータ３３１を含む。本発明の好ましい実施形態によれば、サーバＥは、サーバＥが実行中のトランザクションの一部として作業要求単位を送信するのに、サーバ・グループ１のどのサーバ（Ａ、Ｂ、またはＣ）を使用すべきかをサーバ３１がサーバＥに伝えるよう要求する相互プロセス要求を、サーバ３１のルート・コーディネータ３１１に送信する（図３円で囲んだ１の付いた矢印）。すなわちサーバＥは、サーバ・グループ１にあるサーバの１つに作業要求を送信しなければならないことはわかるが、３つのサーバ（Ａ、Ｂ、またはＣ）のどれにその要求を送信するべきかはわからない。したがって、選択すべきサーバ（Ａ、Ｂ、またはＣ）の識別を知るために、サーバＥは要求（円で囲んだ１）をサーバ３１に送信する。
【００３４】
ルート・コーディネータ３１１が、トランザクション・ツリーの最上位にあり、ルート・コーディネータ３１１に比べて下位の（従属）位置にある従属コーディネータ３３１を含むことに留意されたい。したがって、従属コーディネータ３３１は、サーバ３１内に配置されたトランザクション・ツリーをツリー最上位のコーディネータ（ルート・コーディネータ３１１）までたどればよいだけなので、従属コーディネータ３３１は、要求（円で囲んだ１）のターゲットとすべきサーバ・プロセス３１を簡単に見つけることができる。
【００３５】
サーバＥからの要求（円で囲んだ１）を受け取ると（図５のステップ５１）、サーバ３１は、図４に示すシステム・メモリからマッピング・テーブル３１２にアクセスする。サーバＥから受け取った要求には、サーバＥが注目する特定のサーバ・グループ（この場合はサーバ・グループ１）の識別表示が含まれる。サーバ３１はこのサーバ・グループ識別を使用してマッピング・テーブル３１２にアクセスし（ステップ５２）、列３１２１のサーバ・グループ１について、サーバＣが隣の列３１２２に配置されていることを、このテーブルから読み取る。すなわちサーバ・グループ１は、マッピング・テーブル３１２に基づいてサーバＣにマッピングされる。
【００３６】
その後サーバ３１は、サーバＣの識別をサーバＥに（円で囲んだ２の付いた矢印）返信する（ステップ５３）。これにより、サーバＣにサーバＥが接触すべきことがサーバＥに伝えられる。次いでサーバＥは、サーバＣにトランザクション要求（円で囲んだ３の付いた矢印）を送信する。
【００３７】
これにより、この特定のトランザクションに関して、サーバ・グループ１のいずれかのサーバにアクセスするときは必ずサーバＣが選択されるので、トランザクションのアフィニティが維持される。
【００３８】
パフォーマンスを向上させるために、サーバ・グループ１のサーバＣへのマッピングを、サーバＥにある従属コーディネータ３３１でキャッシュすることができる。従属コーディネータは、そのようなマッピング情報がローカルにキャッシュされない場合、その優位コーディネータにマッピング情報を要求する。したがってこのマッピング情報を求める要求は、情報が得られるまで、トランザクション・ツリーを上方に向かって繰返し伝達される（すなわち従属コーディネータは、ローカルにまたはトランザクション・ツリーの中間ノードに格納することができるので、アフィニティ・マッピング情報を得るために必ずしもルートを照会する必要がない）。
【００３９】
図３では、本発明の好ましい実施形態を簡単に図示するために、非常に単純なトランザクションが使用されていることに留意されたい。実際には、これよりもかなり複雑なトランザクションが使用され、たとえば従属コーディネータ３３１は、その下にいくつかの他の従属コーディネータ層を有する。このように複雑なトランザクションの場合、従属コーディネータは、トランザクション・ツリー内で、トランザクションの一部としてサーバ・グループと接触する必要のあるルート・コーディネータ３１１からかなり遠く離れるが、マッピング・テーブルを含むサーバ・プロセスの位置を求めるためには、（従属コーディネータ３３１を介して）最上位のルート・コーディネータ３１１までトランザクション・ツリーをすべて逆方向に追跡するだけでよい。
【００４０】
マッピング・テーブルが単一の（中央）位置に配置されていることは、シングル・ポイント障害であるが、マッピング・テーブル３１２は、そのためにセットアップされた特定トランザクションだけに関連しており、マッピング・テーブル３１２へのアクセスを調整するルート・コーディネータ３１１は、トランザクション自体と同じライフサイクルである（トランザクションが完了するとルート・コーディネータは削除される）ことも留意されたい。したがって本発明では、シングル・ポイント障害があるという事実によって、それほど重大な問題が発生することはない。
【００４１】
以上、トランザクションがマッピング・テーブルの作成されるエンティティであるという状況における好ましい実施形態について述べてきたが、本発明はこれに限定されるものではない。たとえば、クライアントがこのエンティティであってもよい。すなわち、特定クライアントの代わりにマッピング・テーブルをセットアップすることができ、このテーブルには、クライアントがサーバ・グループへのアクセスを希望するたびに必ず使用するサーバ・グループ／サーバ・マッピングが含まれる。このマッピング・テーブルを含むサーバ・プロセスのライフサイクルは、シングル・ポイント障害の問題を避けるための何らかの所定の方法で、クライアントのライフサイクルと結合される。
【図面の簡単な説明】
【図１】本発明の好ましい実施形態によるオブジェクト指向のクライアント／サーバ環境を示すのに役立つ構成図である。
【図２】本発明の好ましい実施形態の環境である、ＣＯＲＢＡ ＯＴＳの様々な構成要素を示すのに役立つ構成図である。
【図３】本発明の好ましい実施形態を例示するのに使用される様々なデータ処理プロセスの一例を示す構成図である。
【図４】本発明の好ましい実施形態により、図３のマッピング・テーブルを詳細に示した図である。
【図５】本発明の好ましい実施形態により、ルート・コーディネータを有するサーバによって実行される動作ステップを示す流れ図である。
【符号の説明】
３１ サーバ
３２ サーバ・グループ１
３３ サーバ・グループ２
３１１ ルート・コーディネータ
３１２ マッピング・テーブル
３３１ 従属コーディネータ
Ａ サーバＡ
Ｂ サーバＢ
Ｃ サーバＣ
Ｄ サーバＤ
Ｅ サーバＥ
Ｆ サーバＦ
Claims (7)
- 作業負荷によって管理されるサーバ・データ処理プロセスのグループを含み、前記各プロセスが作業要求を実行する機能を有するサーバに対して、クライアントが作業要求を送信する、クライアント／サーバ・データ処理システムにおいて、サーバ・データ処理プロセスを実行するサーバ・データ処理装置であって、
作業負荷によって管理されるサーバ・データ処理プロセスの複数のグループのそれぞれに、特定のサーバ・データ処理プロセスをマッピングする、マッピング・データを格納するデータ記憶ユニットと、
作業負荷によって管理されるサーバ・データ処理プロセスの特定のグループに対応する、マップされたサーバ・データ処理プロセスの識別を求める要求をクライアントから受け取る手段であって、前記特定グループが前記要求中で指定されている手段と、
前記受け取った要求中で指定される前記特定グループについて、前記マップされたサーバ・データ処理プロセスの識別を決定するために、前記データ記憶ユニットにアクセスする手段と、
前記マップされたサーバ・データ処理プロセスの識別をクライアントに返す手段とを含み、
前記クライアントから受け取った前記要求が、前記サーバ・データ処理プロセスの継続時間と結合された継続時間を有するエンティティに関連付けられており、
前記エンティティがトランザクションであって、前記クライアントから受け取った前記要求がトランザクションの一部であり、
前記装置のサーバ・データ処理プロセスが、前記トランザクションを表すトランザクション・ツリーのルートに配置されているサーバ・データ処理装置。 - 前記マッピング・データがトランザクションごとに格納され、前記クライアントから受け取った前記要求が、前記トランザクションを表すトランザクション・ツリーをたどることにより、前記サーバ・データ処理プロセスに到達する、請求項１に記載の装置。
- 前記サーバ・データ処理プロセスによって受け取られる要求を出したクライアントが、前記複数のグループの１つに含まれ、前記要求中で指定された特定のグループが、前記複数のグループのうちの他の１つである、請求項１に記載の装置。
- 作業負荷によって管理されるサーバ・データ処理プロセスのグループを含み、前記各プロセスが作業要求を実行する機能を有するサーバに対して、クライアントが作業要求を送信する、クライアント／サーバ・データ処理システムにおいて、サーバ・データ処理装置を介して実行されるサーバ・データ処理方法であって、
前記装置がサーバ・データ処理プロセスを実行し、前記装置が作業負荷によって管理されるサーバ・データ処理プロセスの複数のグループのそれぞれに、特定のサーバ・データ処理プロセスをマッピングする、マッピング・データを格納するデータ記憶ユニットを含み、
前記装置が、作業負荷によって管理されるサーバ・データ処理プロセスの特定のグループに対応する、マップされたサーバ・データ処理プロセスの識別を求める要求をクライアントから受け取るステップであって、前記特定グループが前記要求中で指定されているステップと、
前記装置が、前記受け取った要求中で指定される前記特定グループについて、前記マップされたサーバ・データ処理プロセスの識別を決定するために、前記データ記憶ユニットにアクセスするステップと、
前記装置が、前記マップされたサーバ・データ処理プロセスの識別をクライアントに返すステップとを含み、
前記クライアントから受け取った前記要求が、前記サーバ・データ処理プロセスの継続時間と結合された継続時間を有するエンティティに関連付けられており、
前記エンティティがトランザクションであって、前記クライアントから受け取った前記要求がトランザクションの一部であり、
前記装置のサーバ・データ処理プロセスが、トランザクションを表すトランザクション・ツリーのルートに配置されている、サーバ・データ処理方法。 - 前記マッピング・データがトランザクションごとに格納され、前記クライアントから受け取った前記要求が、前記トランザクションを表すトランザクション・ツリーをたどることにより、前記サーバ・データ処理プロセスに到達する、請求項４に記載の方法。
- 前記サーバ・データ処理プロセスによって受け取られる要求を出したクライアントが、前記複数のグループの１つに含まれ、前記要求中で指定された特定のグループが、前記複数のグループのうちの他の１つである、請求項４に記載の方法。
- 請求項４に記載の方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9908477A GB2348985A (en) | 1999-04-15 | 1999-04-15 | Centralized affinity maintenance in a workload managed client/server system |
| GB9908477.4 | 1999-04-15 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000339287A JP2000339287A (ja) | 2000-12-08 |
| JP4464525B2 true JP4464525B2 (ja) | 2010-05-19 |
Family
ID=10851477
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000105458A Expired - Fee Related JP4464525B2 (ja) | 1999-04-15 | 2000-04-06 | 作業負荷によって管理されるクライアント／サーバ・データ処理システムにおける集中アフィニティ維持装置および方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US6466965B1 (ja) |
| JP (1) | JP4464525B2 (ja) |
| GB (1) | GB2348985A (ja) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6970932B1 (en) | 1999-12-14 | 2005-11-29 | Microsoft Corporation | Non-delegable client requests to servers storing local information only |
| US7151729B1 (en) * | 2000-06-29 | 2006-12-19 | Samsung Electronics Co., Ltd. | Optical recording medium having read-only storage area and writeable storage area and recording/reproducing apparatus and method therefor |
| US6782410B1 (en) * | 2000-08-28 | 2004-08-24 | Ncr Corporation | Method for managing user and server applications in a multiprocessor computer system |
| US20100042565A1 (en) * | 2000-09-25 | 2010-02-18 | Crossbeam Systems, Inc. | Mezzazine in-depth data analysis facility |
| US20070192863A1 (en) * | 2005-07-01 | 2007-08-16 | Harsh Kapoor | Systems and methods for processing data flows |
| US20110213869A1 (en) * | 2000-09-25 | 2011-09-01 | Yevgeny Korsunsky | Processing data flows with a data flow processor |
| US9800608B2 (en) | 2000-09-25 | 2017-10-24 | Symantec Corporation | Processing data flows with a data flow processor |
| US8010469B2 (en) | 2000-09-25 | 2011-08-30 | Crossbeam Systems, Inc. | Systems and methods for processing data flows |
| US20020165947A1 (en) | 2000-09-25 | 2002-11-07 | Crossbeam Systems, Inc. | Network application apparatus |
| US20110214157A1 (en) * | 2000-09-25 | 2011-09-01 | Yevgeny Korsunsky | Securing a network with data flow processing |
| US20110219035A1 (en) * | 2000-09-25 | 2011-09-08 | Yevgeny Korsunsky | Database security via data flow processing |
| US9525696B2 (en) | 2000-09-25 | 2016-12-20 | Blue Coat Systems, Inc. | Systems and methods for processing data flows |
| US7383355B1 (en) * | 2000-11-01 | 2008-06-03 | Sun Microsystems, Inc. | Systems and methods for providing centralized management of heterogeneous distributed enterprise application integration objects |
| US8782654B2 (en) | 2004-03-13 | 2014-07-15 | Adaptive Computing Enterprises, Inc. | Co-allocating a reservation spanning different compute resources types |
| CA2558892A1 (en) | 2004-03-13 | 2005-09-29 | Cluster Resources, Inc. | System and method for a self-optimizing reservation in time of compute resources |
| US20070266388A1 (en) | 2004-06-18 | 2007-11-15 | Cluster Resources, Inc. | System and method for providing advanced reservations in a compute environment |
| KR20070058445A (ko) * | 2004-07-02 | 2007-06-08 | 스트라스바흐, 인코포레이티드 | 웨이퍼 처리 방법 및 시스템 |
| US8176490B1 (en) | 2004-08-20 | 2012-05-08 | Adaptive Computing Enterprises, Inc. | System and method of interfacing a workload manager and scheduler with an identity manager |
| CA2827035A1 (en) | 2004-11-08 | 2006-05-18 | Adaptive Computing Enterprises, Inc. | System and method of providing system jobs within a compute environment |
| US9075657B2 (en) | 2005-04-07 | 2015-07-07 | Adaptive Computing Enterprises, Inc. | On-demand access to compute resources |
| US8863143B2 (en) | 2006-03-16 | 2014-10-14 | Adaptive Computing Enterprises, Inc. | System and method for managing a hybrid compute environment |
| US9231886B2 (en) | 2005-03-16 | 2016-01-05 | Adaptive Computing Enterprises, Inc. | Simple integration of an on-demand compute environment |
| EP3242208A1 (en) * | 2005-05-31 | 2017-11-08 | Imbert Management Consulting Solutions | Computational expansion system object of the invention |
| US8041773B2 (en) | 2007-09-24 | 2011-10-18 | The Research Foundation Of State University Of New York | Automatic clustering for self-organizing grids |
| US8642722B2 (en) * | 2009-05-15 | 2014-02-04 | Iucf-Hyu (Industry-University Cooperation Foundation Hanyang University) | Preparation method of polybenzimidazole |
| US11720290B2 (en) | 2009-10-30 | 2023-08-08 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
| US10877695B2 (en) | 2009-10-30 | 2020-12-29 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
| US8745629B2 (en) * | 2010-01-11 | 2014-06-03 | Qualcomm Incorporated | System and method of controlling power in an electronic device |
| US9185054B2 (en) | 2010-09-15 | 2015-11-10 | Oracle International Corporation | System and method for providing zero buffer copying in a middleware machine environment |
| US8756329B2 (en) | 2010-09-15 | 2014-06-17 | Oracle International Corporation | System and method for parallel multiplexing between servers in a cluster |
| EP2500856A1 (en) * | 2011-03-15 | 2012-09-19 | Amadeus S.A.S. | Method and system for providing a session involving a plurality of software applications |
| US10613948B2 (en) | 2017-08-31 | 2020-04-07 | International Business Machines Corporation | Repairing partially completed transactions in fast consensus protocol |
| US11392924B2 (en) * | 2019-09-11 | 2022-07-19 | Ebay Inc. | In-person transaction processing system |
| CN113794697B (zh) * | 2021-08-27 | 2023-04-18 | 北京深盾科技股份有限公司 | 基于代理服务的信息处理方法、系统以及存储介质 |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2643356B2 (ja) * | 1988-09-14 | 1997-08-20 | 株式会社日立製作所 | 分散システムにおけるトランザクション整合性保証制御方法 |
| AU628753B2 (en) * | 1990-08-14 | 1992-09-17 | Digital Equipment Corporation | Method and apparatus for implementing server functions in a distributed heterogeneous environment |
| CA2048306A1 (en) * | 1990-10-02 | 1992-04-03 | Steven P. Miller | Distributed configuration profile for computing system |
| US5506987A (en) * | 1991-02-01 | 1996-04-09 | Digital Equipment Corporation | Affinity scheduling of processes on symmetric multiprocessing systems |
| GB2288477A (en) * | 1994-04-05 | 1995-10-18 | Ibm | Communications system for exchanging data between computers in a network. |
| JPH09269903A (ja) * | 1996-04-02 | 1997-10-14 | Hitachi Ltd | プロセス管理方式 |
| US5872972A (en) * | 1996-07-05 | 1999-02-16 | Ncr Corporation | Method for load balancing a per processor affinity scheduler wherein processes are strictly affinitized to processors and the migration of a process from an affinitized processor to another available processor is limited |
| JPH10149306A (ja) * | 1996-11-18 | 1998-06-02 | Nippon Telegr & Teleph Corp <Ntt> | サービス連携装置およびその生成装置 |
| GB2320594A (en) * | 1996-12-20 | 1998-06-24 | Ibm | Dispatching client method calls to parallel execution threads within a server |
| US6078943A (en) * | 1997-02-07 | 2000-06-20 | International Business Machines Corporation | Method and apparatus for dynamic interval-based load balancing |
| US5995997A (en) * | 1997-05-02 | 1999-11-30 | Microsoft Corporation | Apparatus and methods for optimally allocating currently available computer resources to future task instances versus continued execution of current task instances |
| GB2336449A (en) * | 1998-04-14 | 1999-10-20 | Ibm | A server selection method in an asynchronous client-server computer system |
-
1999
- 1999-04-15 GB GB9908477A patent/GB2348985A/en not_active Withdrawn
- 1999-07-29 US US09/363,436 patent/US6466965B1/en not_active Expired - Fee Related
-
2000
- 2000-04-06 JP JP2000105458A patent/JP4464525B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000339287A (ja) | 2000-12-08 |
| GB9908477D0 (en) | 1999-06-09 |
| US6466965B1 (en) | 2002-10-15 |
| GB2348985A (en) | 2000-10-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4464525B2 (ja) | 作業負荷によって管理されるクライアント／サーバ・データ処理システムにおける集中アフィニティ維持装置および方法 | |
| US7213049B2 (en) | System and method for transaction processing with transaction property feature | |
| JP4550411B2 (ja) | 同期されたコールバック処理特徴をもったトランザクション処理システム及び方法 | |
| US6832238B1 (en) | Local transaction management | |
| US6976262B1 (en) | Web-based enterprise management with multiple repository capability | |
| US7441025B2 (en) | System and method for transaction processing with delegated commit feature | |
| US7673029B2 (en) | Grid automation bus to integrate management frameworks for dynamic grid management | |
| US6349342B1 (en) | Methods and apparatus for managing computer processes | |
| US8056091B2 (en) | Systems and methods for using application services | |
| AU2002318249A1 (en) | System and method for transaction processing with transaction property feature | |
| JP2005505055A (ja) | モバイルウェブクライアントに対する方法、装置及びシステム | |
| JP2000242615A (ja) | サーバ・コンピューティング装置、操作方法および記憶装置 | |
| JPH09223116A (ja) | 複数ミドルウェアに渡る分散オブジェクトの位置透過性 | |
| JPH08286918A (ja) | 手順トランザクション・コーディネータと相互動作するオブジェクト指向トランザクション・サービスを作成するためのシステムおよび方法 | |
| US20080288622A1 (en) | Managing Server Farms | |
| US6769125B2 (en) | Methods and apparatus for managing computer processes | |
| JP2002510084A (ja) | クライアント／サーバ・コンピューティング・システム | |
| JP3628577B2 (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 | |
| Saleh et al. | The distributed object computing paradigm: concepts and applications | |
| KR100403659B1 (ko) | 서버 프로세스 장치 및 서버 프로세스 방법 및 컴퓨터 판독가능한 기록 매체 | |
| US5668994A (en) | Conversation management routine for co-operative processing applications | |
| Street et al. | Software architectural reuse issues in service-oriented architectures | |
| US20230164243A1 (en) | Systems and methods for context-aware event ordering protocol for distributed service systems | |
| Zhou et al. | Fault-tolerant servers for the RHODOS system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20020624 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070329 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20090127 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20090212 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090908 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090929 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091224 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20091224 |
|
| 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: 20100216 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100219 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130226 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130226 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140226 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |