(57)【特許請求の範囲】
【請求項１】
一のクライアント処理装置および複数のサーバ処理装置を用いて分散トランザクションを実行するクライアント／サーバ・コンピューティング・システムであって、
前記クライアント処理装置が、
前記複数のサーバ処理装置のうち１つのサーバ処理装置を、前記分散トランザクションを表すトランザクション・オブジェクトを生成および保持すべきサーバ処理装置として選択する手段と、
前記分散トランザクションに含まれる複数の呼び出しに加えて、前記選択されたサーバ処理装置に対する追加の呼び出しを生成する手段とを備え、
前記追加の呼び出しは、前記選択されたサーバ処理装置に対し、一の分散トランザクションが開始されたが、当該分散トランザクションを表すトランザクション・オブジェクトがまだ生成されていないことを指示するための固有値を有するトランザクション・コンテキストを含んでおり、
前記複数の呼び出しのうち任意の呼び出しを送る前に、前記追加の呼び出しを、前記選択されたサーバ処理装置に配置されている一のダミー・ビジネス・オブジェクトに送るか、または前記選択されたサーバ処理装置に配置されている一のオブジェクトのダミー・メソッドに送る手段と、
前記選択されたサーバ処理装置が前記トランザクション・オブジェクトを生成した後に、前記選択されたサーバ処理装置から変更されたトランザクション・コンテキストを受け取る手段と、
前記複数の呼び出しを前記複数のサーバ処理装置のうち少なくとも１つのサーバ処理装置に送るとともに、前記変更されたトランザクション・コンテキストを前記複数の呼び出しに渡す手段とをさらに備える、クライアント／サーバ・コンピューティング・システム。
【請求項２】
前記固有値がＮＵＬＬ値である、請求項１記載のクライアント／サーバ・コンピューティング・システム。
【請求項３】
前記選択する手段が、
前記複数のサーバ処理装置のうち前記分散トランザクション中に更新される資源を有する１つのサーバ処理装置を、前記選択されたサーバ処理装置として選択する、請求項１記載のクライアント／サーバ・コンピューティング・システム。
【請求項４】
前記選択されたサーバ処理装置が、
前記追加の呼び出しを受け取る手段と、
前記追加の呼び出しに含まれている前記トランザクション・コンテキスト中の前記固有値を認識し、前記固有値に応答して前記トランザクション・オブジェクトを生成する手段と、
前記変更されたトランザクション・コンテキストを生成する手段と、
前記変更されたトランザクション・コンテキストを前記クライアント処理装置に戻す手段とを備える、請求項１記載のクライアント／サーバ・コンピューティング・システム。
【請求項５】
一のクライアント処理装置および複数のサーバ処理装置を用いて分散トランザクションを実行するクライアント／サーバ・コンピューティング・システムにおけるクライアント／サーバ処理方法であって、
前記クライアント処理装置によって実施されるクライアント処理方法が、
前記複数のサーバ処理装置のうち１つのサーバ処理装置を、前記分散トランザクションを表すトランザクション・オブジェクトを生成および保持すべきサーバ処理装置として選択するステップと、
前記分散トランザクションに含まれる複数の呼び出しに加えて、前記選択されたサーバ処理装置に対する追加の呼び出しを生成するステップとを含み、
前記追加の呼び出しは、前記選択されたサーバ処理装置に対し、一の分散トランザクションが開始されたが、当該分散トランザクションを表すトランザクション・オブジェクトがまだ生成されていないことを指示するための固有値を有するトランザクション・コンテキストを含んでおり、
前記複数の呼び出しのうち任意の呼び出しを送る前に、前記追加の呼び出しを、前記選択されたサーバ処理装置に配置されている一のダミー・ビジネス・オブジェクトに送るか、または前記選択されたサーバ処理装置に配置されている一のオブジェクトのダミー・メソッドに送るステップと、
前記選択されたサーバ処理装置が前記トランザクション・オブジェクトを生成した後に、前記選択されたサーバ処理装置から変更されたトランザクション・コンテキストを受け取るステップと、
前記複数の呼び出しを前記複数のサーバ処理装置のうち少なくとも１つのサーバ処理装置に送るとともに、前記変更されたトランザクション・コンテキストを前記複数の呼び出しに渡すステップとをさらに含む、クライアント／サーバ処理方法。
【請求項６】
前記固有値がＮＵＬＬ値である、請求項５記載のクライアント／サーバ処理方法。
【請求項７】
前記選択するステップが、
前記複数のサーバ処理装置のうち前記トランザクション中に更新される資源を有する１つのサーバ処理装置を、前記選択されたサーバ処理装置として選択する、請求項５記載のクライアント／サーバ処理方法。
【請求項８】
前記選択されたサーバ処理装置によって実施されるサーバ処理方法が、
前記追加の呼び出しを受け取るステップと、
前記追加の呼び出しに含まれている前記トランザクション・コンテキスト中の前記固有値を認識し、前記固有値に応答して前記トランザクション・オブジェクトを生成するステップと、
前記変更されたトランザクション・コンテキストを生成するステップと、
前記変更されたトランザクション・コンテキストを前記クライアント処理装置に戻すステップとを実施する、請求項５記載のクライアント／サーバ処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、クライアント・コンピュータ（以下「クライアント」と表記）がサーバ・コンピュータ（以下「サーバ」と表記）に要求してクライアントの作業の一部を実行させるクライアント／サーバ（分散とも呼ばれる）コンピューティングの分野に関する。クライアントおよびサーバは、同じ物理的なコンピューティング装置に位置することもできる。
【０００２】
【従来の技術】
過去数年の間に、クライアント／サーバ・コンピューティングは、情報技術の世界でますます重要になってきた。この型の分散コンピューティングによって、１つのマシンが、それ自身の作業の一部を、当該作業を実行するのにより適している別のマシンに委任することか可能になる。例えば、サーバにはデータ容量の大きな記憶装置を管理するデータベース・プログラムを走らせている能力の高いコンピュータを用いる一方で、クライアントには自分のローカル・プログラムで使う情報をサーバのデータベースに要請するだけのデスクトップ型のパーソナル・コンピュータ（ＰＣ）を用いることができる。
【０００３】
クライアント／サーバ・コンピューティングの利点は、オブジェクト指向プログラミング（object-oriented programming：ＯＯＰ）と呼ばれている周知のコンピュータ・プログラミング技術を使うことによってなお一層増進してきた。ＯＯＰによると、クライアントおよびサーバは異なった（異種の）「プラットフォーム」上に位置することが可能になる。プラットフォームとは、マシンがその作業を実行するのに使う特定のハードウェア／ソフトウェア／オペレーティング・システム／通信プロトコルの組み合わせである。ＯＯＰによれば、クライアントのアプリケーション・プログラム（以下「クライアント・アプリケーション」と表記）およびサーバのアプリケーション・プログラム（以下「サーバ・アプリケーション」と表記）は、クライアント・アプリケーションの作業上の要求がどのようにして通信され、どのようにしてサーバ・アプリケーションによって受け入れられるかということを心配することなく、それ自身のプラットフォーム上で動作することができる。同様に、サーバ・アプリケーションは、クライアント・アプリケーションからどのようにして要求を受け取り、それをどのようにして翻訳し、そして、サーバ・アプリケーションの処理結果をどのようにして要求したクライアント・アプリケーションへ戻すかということを心配する必要はない。
【０００４】
ＯＯＰ技法が異種のクライアント／サーバ・システムとどのようにして統合してきたかということの詳細は、米国特許第５４４０７４４号および公開された欧州特許出願第ＥＰ  ０  ６７７９４３  Ａ２号に説明されている。しかしながら、本発明の環境を理解するために、以下でその基本アーキテクチャの一例を説明する。
【０００５】
図１に示すように、クライアント１０（例えば、ＩＢＭ  ＯＳ／２オペレーティング・システムを搭載したパーソナル・コンピュータを用いることができる）は、そのオペレーティング・システム上で走っているクライアント・アプリケーション４０を有している（「ＩＢＭ」および「ＯＳ／２」は、本出願人の商標である）。クライアント・アプリケーション４０は、サーバ２０上で作業が実行されること、およびクライアント・アプリケーション４０が引き続いて使うためにサーバ２０からデータが戻されることを定期的に必要とする。サーバ２０には、例えば、ＭＶＳオペレーティング・システムを走らせている能力の高いメインフレーム・コンピュータを用いることができる（「ＭＶＳ」は、本出願人の商標である）。本発明の目的のためには、サーバが実行すべき通信サービスに対する要求がクライアント・アプリケーション４０との間のユーザの対話によって開始されるか否か、あるいは、クライアント・アプリケーション４０がユーザの対話とは独立に動作し、クライアント・アプリケーション４０が走っている間に、サーバ２０が実行すべき通信サービスに対する要求を自動的に生成するか否かは関係がない。
【０００６】
クライアント１０がサーバ２０のサービスに対する要求を行うことを望んでいる場合、クライアント・アプリケーション４０は第１の論理手段５０に必要なサービスを通知する。例えば、クライアント・アプリケーション４０は、第１の論理手段５０に対し、遠隔手順の名前を入力パラメータおよび出力パラメータのリストと共に送ることによってこれを行う。次いで、第１の論理手段５０は、記憶装置６０に格納されている使用可能な通信サービスの定義を参照して、サーバ２０との必要な通信を確立するタスクを処理する。全ての可能なサービスは、オブジェクト・クラスの統合・一貫フレームワーク７０として定義されている。サービスをこのように定義することにより、性能および再使用性の点で多大な利点がもたらされる。
【０００７】
サーバ２０との必要な通信を確立するために、第１の論理手段５０は、フレームワーク中のどのオブジェクト・クラスを使う必要があるかを判定し、次いで、当該オブジェクトのインスタンスをサーバ２０に生成する。これは、当該オブジェクトがそのメソッドのうちの１つを呼び出すように、当該オブジェクトへメッセージを送ることにより行う。これにより、コネクション手段８０を介してサーバ２０とのコネクションが確立する。引き続いて、第２の論理手段９０へ要求を送る。
【０００８】
次いで、第２の論理手段９０がサーバ２０上で走っているサーバ・アプリケーション１００へ要求を渡す。その結果、サーバ・アプリケーション１００は、前記要求が必要とする特定のタスク（例えば、データ検索手順）を実行することができる。このタスクが完了すると、サーバ・アプリケーション１００は、結果をクライアント１０へ送り返す必要があるかも知れない。要求されたタスクを実行している間、サーバ・アプリケーション１００は、第２の論理手段９０と対話している。そして、結果をクライアント１０へ送り返すべき場合、第２の論理手段９０はオブジェクトをインスタンス化し、これらのオブジェクトの適切なメソッドを呼び出す。なお、これらのオブジェクト・インスタンスは、サーバ・アプリケーション１００が必要とするときに、記憶装置１１０に格納されているオブジェクト・クラスの統合・一貫フレームワーク１２０から生成されるものである。
【０００９】
前述の技法を使うと、クライアント・アプリケーション４０は、通信アーキテクチャに対し露出されない。さらに、サーバ・アプリケーション１００は、その環境用の標準の機構を通して呼び出される。したがって、サーバ・アプリケーション１００は、それ自身が遠隔的に呼び出されていることを認識しない。
【００１０】
ＯＭＧ（Object Management Group）は、図１に示すような分散オブジェクトを持つ異種のプラットフォーム上で行われるクライアント／サーバ・コンピューティングの様々な側面に関係する組織の国際コンソーシアムである。ＯＭＧは、クライアント（例えば、１０）がサーバ（例えば、２０）と（ＯＯＰ形態で）通信するための標準を公表している。これらの標準の一部として、オブジェクト・リクエスト・ブローカ（Object Request Broker：ＯＲＢ）が定義されている。ＯＲＢは、ＯＭＧが策定するアプリケーション・レベルの通信インフラストラクチャを定義する仕様であるＣＯＲＢＡ（Common Object Request Broker Architecture）の中心をなすものである。ＯＲＢは、クライアントとサーバとの間にオブジェクト指向のブリッジを提供する。ＯＲＢは、クライアント・アプリケーションおよびサーバ・アプリケーションを、オブジェクト指向の実現細目から分離し、コネクション手段８０に加えて第１の論理手段５０および第２の論理手段９０の作業のうち少なくとも一部を実行する。
【００１１】
ＣＯＲＢＡソフトウェア構成の一部として、ＯＭＧは、「トランザクション」に関係する標準を公表している。これらの標準は、ＯＴＳ（Object Transaction Service）と呼ばれている。その詳細については、例えば、ＣＯＲＢＡオブジェクト・トランザクション・サービス仕様１．０，ＯＭＧ文書９４．８．４．（CORBA Object Transaction Service Specification 1.0, OMG Document 94.8.4.）を参照されたい。コンピュータを使用して実現されたトランザクション処理システムは、多くの産業において、重要なビジネス・タスク用に使われている。トランザクションは、完全に完了されるか、あるいはアクションを伴うことなく完全に除去されねばならないような、単作業単位を定義する。例えば、顧客が現金を引き出すための銀行用のＡＴＭ（automated teller machine：現金自動預け払い機）の場合、現金を発行し、当該ＡＴＭ内に置かれている現金の残高を減少させるとともに、顧客の預金口座の残高を減少させるという全てのアクションを完全に行わなければならないか、またはその何れも全く行ってはならないのである。これらの従属アクションの１つでも失敗すると、記録内容と実際の事象との間に不一致が生ずることになる。
【００１２】
分散トランザクション処理は、複数の物理的または論理的な場所に存在する資源に影響するようなトランザクションに関わる。前述の例では、トランザクションは、ローカルのＡＴＭが管理している資源に影響するし、銀行のメイン・コンピュータが管理している銀行預金残高にも影響する。このようなトランザクションは、特定のサーバ（例えば、２０）が処理する一連のクライアントの要求に関して、当該サーバと通信する特定のクライアント（例えば、１０）に関わる。ＯＭＧのＯＴＳは、これらの分散トランザクションを調整する責任を負っている。
【００１３】
通常、クライアント・プロセス上で走っているアプリケーションが開始するトランザクションは、複数の異なったサーバを呼び出すことがある。この場合、各サーバは、当該トランザクションに含まれる命令に従って、それ自身のローカル・データベースを変更するためのサーバ・プロセスを開始する。当該トランザクションが終了するのは、当該トランザクションをコミットする（この結果、全てのサーバがそれぞれのローカル・データベースに対する変更を終了する）か、あるいは、当該トランザクションを打ち切る（この結果、全てのサーバがそれぞれのローカル・データベースに対する変更を「ロールバック」すなわち無視する）場合だけである。当該トランザクションの間にこれらのサーバと通信するためには（例えば、これらのサーバに対し、当該トランザクションにおけるそれぞれの部分をコミットするかまたは打ち切るように命令するためには）、関係するプロセスのうち１つが、当該トランザクション用の状態データを保持している必要がある。こうするために一般に採用されている方法は、特定のプロセスを使用して一連のトランザクション・オブジェクトをセットアップするとともに、そのうちの１つを様々なサーバに関するトランザクションを調整するためのコーディネータ・オブジェクトとするというものである。
【００１４】
図２は、ＩＢＭ社が開発し且つ１９９７年５月に発表した製品であるコンポーネント・ブローカ・シリーズ（Component Broker Series：本出願人の商標）の一部として含まれている、ＯＴＳの従来のインプリメンテーションを示している。トランザクション（例えば、銀行口座からの現金の引き出し）を開始することを望んでいるクライアント・プロセス２１は、このトランザクションの状態を保持するためのトランザクション・オブジェクトを生成および保持可能なプロセスを探し出す必要がある。シン・クライアント（最小限の機能だけを有するクライアント）を生成するのが最近の傾向なので、クライアント・プロセス２１は、通常、トランザクション・オブジェクトをローカルには保持することができない。したがって、この目的に適うサーバ・プロセスを探し出す必要がある。
【００１５】
この従来技術のアプローチによると、ＯＴＳ（あるいは、ＣＯＲＢＡライフサイクル・サービスのような別のサービス）は、サーバＡプロセス２２を探し出し、このサーバＡプロセス２２上にトランザクション・オブジェクト２２１（これにはコーディネータ・オブジェクト、コントロール・オブジェクトおよびターミネータ・オブジェクトが含まれる）を生成する。この従来技術によると、同じサーバ・プロセス（図２のサーバＡプロセス２２）が常に選ばれる。サーバＡプロセス２２を探し出すと、クライアント・プロセス２１は、サーバＡプロセス２２へメッセージを送り（丸数字１を参照）、トランザクション・オブジェクト２２１を生成するようにサーバＡプロセス２２に命じる。次いで、サーバＡプロセス２２は、トランザクション・オブジェクト２２１を生成し、トランザクション・コンテキストを含んでいる応答をクライアント・プロセス２１へ送る（丸数字２を参照）。次いで、クライアント・プロセス２１は、銀行口座の借方記入（debit bank account）コマンドをサーバＢプロセス２３（このプロセスは、クライアント・プロセス２１がそこから現金を引き出すことを望んでいる銀行口座オブジェクト２３１を有している）へ送る（丸数字３を参照）。この借方記入コマンドは、サーバＡプロセス２２がクライアント・プロセス２１へ供給したトランザクション・コンテキストを伴っている。このようにして、サーバＢプロセス２３中の銀行口座オブジェクト２３１は、それ自身をサーバＡプロセス２２中のトランザクション・オブジェクト２２１に登録することができる（丸数字４を参照）。この結果、トランザクションの終わりで、トランザクション・オブジェクト２２１は、銀行口座オブジェクト２３１に対し、コミットまたはロールバックするように命じることができる（丸数字５を参照）。
【００１６】
このインプリメンテーションは、少なくとも２つの点で非効率である。第１に、クライアント・プロセスが遠隔のサーバ・プロセスを探し出してトランザクション・オブジェクトを生成し保持するときは、常に、同じサーバ・プロセスが使われるので、このサーバ・プロセスは、すぐに過負荷になってしまう結果、それ自身のタスク（例えば、ローカル資源の内容の更新）を効率的に実行できなくなる。第２に、トランザクションに関わっている様々なプロセスの間に多くのプロセス間フローが存在する。トランザクション・オブジェクトの生成・保持がたとえ無作為に選ばれたサーバ・プロセス上で行われるとしても、プロセス間呼び出しの数が多いという問題は依然として存在する。
【００１７】
さらに、このインプリメンテーションでは、クライアント・プロセスには、トランザクション・オブジェクトを配置するのにどのサーバ・プロセスを使うかということに関する選択権がない。クライアント・プロセスは、自分がトランザクション・オブジェクトをセットアップすることを望んでいるサーバ・プロセス上でトランザクション・ファクトリ（CosTransaction::TransactionFactory）を探し出し、そのファクトリ上の生成メソッドを呼び出し、最終的にCosTransaction::TransactionFactory::resume()メソッドを呼び出してトランザクションを「カレント（current)」にすることができるであろう。しかし、これには、クライアント・プロセスの側で多くのステップが関与する。もしクライアント・プロセスがより単純なCosTransaction::Current インタフェースを使うことができ、さらに、その上にトランザクション・オブジェクトを配置すべきサーバ・プロセスを選択することができたら、事態はより容易になるであろう。しかし、現在の技術状態では、これはできない。
【００１８】
【課題を解決するための手段】
第１の側面によると、本発明は、分散トランザクションを実行するクライアント／サーバ・コンピューティング・システム、特にそのクライアント処理装置を提供する。
【００２１】
第２の側面によると、本発明は、分散トランザクションを実行するクライアント／サーバ・コンピューティング・システムにおいて使用するためのサーバ処理装置を提供する。
【００２２】
第３の側面によると、本発明は、第１の側面として前述したクライアント処理装置の機能を実行する方法を提供する。
【００２３】
第４の側面によると、本発明は、第２の側面として前述したサーバ処理装置の機能を実行する方法を提供する。
【００２６】
トランザクションを実行する際には、サーバ・プロセス（例えば、当該トランザクションに関わる資源を有しているサーバ・プロセス）中に、当該トランザクションの実行に実質的に関わることのできるトランザクション・オブジェクトを生成する。本発明によれば、クライアント・プロセスは、前記トランザクション・オブジェクトを生成すべきサーバ・プロセスを容易に選択することができるので、プロセス間フローの数を顕著に減少させることができる。
【００２７】
【発明の実施の形態】
ＣＯＲＢＡのＯＴＳは、「カレント（Current）」と呼ばれるインタフェース・オブジェクトを提供する。このカレント・インタフェース・オブジェクトは、その下部にあるソフトウェア層へトランザクションの開始を通知するためにクライアント・アプリケーション（ソース・コード）が使う「開始」メソッドを有している。本発明の参考例の実施形態によると、クライアント・アプリケーションが特定のクライアント・アーキテクチャ上で構築または実行されており且つ「開始」メソッドを含んでいる場合、その下部にあるソフトウェアは、当該トランザクションに実質的に関わるサーバ（例えば、当該トランザクションに関わるサーバ資源を有するサーバ）中に、トランザクション状態オブジェクトをセットアップすることにより、当該トランザクションを生成するように適切な動作を行う。
【００２８】
本発明の参考例の実施形態では、クライアント・プロセス３１（図３を参照）中で走っているアプリケーションは、通常のように、カレント・インタフェース・オブジェクト上の「開始」メソッドを呼び出すことにより、トランザクションを開始する。次いで、クライアント・プロセス３１は、例えば最小限のオブジェクトの集合をローカルに生成することにより、それ自身がこのコマンドを発行したという事実を記録する。前述のアクションは、図４のステップ４１に示してある。この例では、実行中のトランザクションが、顧客としてＡＴＭを使う、銀行口座からの現金の引き出しであると仮定している。かかるトランザクションは、世界中のどこでも、日常的に行われている。
【００２９】
次の点に留意すべきである。すなわち、従来技術では、この段階で、サーバＡプロセス２２が探し出された後、トランザクション・オブジェクト（図２の２２１）がこのサーバＡプロセス２２中に生成されていた。本発明の参考例は、以下で説明するように、これらのトランザクション・オブジェクトの生成を後の時点まで遅延させている。
【００３０】
クライアント・プロセス３１中で走っているアプリケーションは、現金引き出しトランザクションの最初の実質的部分として、サーバＢプロセス３３中の銀行口座オブジェクト３３１に対し、借方記入コマンドを発行する。この例では、借方記入コマンドは、「開始」コマンドを発行した後にクライアント・プロセス３１が当該トランザクションにおいて形成する、最初の遠隔フローである。このコマンドを形成する際に、クライアント・プロセス３１は、当該コマンド中にトランザクション・コンテキストを含めることにより、銀行口座オブジェクト３３１が、当該コマンドがトランザクションの一部であることを認識し且つこの特定のトランザクションを識別できるようにしなければならない。
【００３１】
従来技術（図２）では、クライアント・プロセス２１は、サーバＡプロセス２２中にセットアップされたトランザクション・オブジェクト２２１からトランザクション・コンテキストを受け取っていた。しかし、本発明の参考例の実施形態では、トランザクション・オブジェクトはまだ生成されていないので、この段階において、クライアント・プロセス３１に対し、トランザクション・コンテキストを供給することができない。それ故、参考例の実施形態では、クライアント・プロセス３１がサーバＢプロセス３３中の銀行口座オブジェクト３３１へ借方記入コマンドを送るときに、当該コマンド中に特定のトランザクション・コンテキスト（例えば、ＮＵＬＬトランザクション・コンテキスト）が含められる（図３の丸数字１を参照）。ＮＵＬＬトランザクション・コンテキストは、当該トランザクション・コンテキストの全てのフィールドが零に設定されていることを意味している。この特定のトランザクション・コンテキストは、トランザクションは開始されたが、そのトランザクション・オブジェクトはまだ生成されていない、ということを通知する。この最後の動作は、図４のステップ４２に示してある。
【００３２】
サーバＢプロセス３３は、この特定のトランザクション・コンテキスト（例えば、ＮＵＬＬトランザクション・コンテキスト）を認識すると、トランザクションは開始されたが、トランザクション・オブジェクトはまだ生成されていないことを通知される。次いで、サーバＢプロセス３３は、トランザクション・オブジェクト３３２をローカルに生成する（図４のステップ４３）。この時点でトランザクション・オブジェクト３３２が生成されたので、当該トランザクションには、今や、有効なトランザクション・コンテキストを有する。このような有効なトランザクション・コンテキストは、当該トランザクションに割り当てられる。次いで、サーバＢプロセス３３は、クライアント・プロセス３１へ応答を送り（丸数字２を参照）、クライアント・プロセス３１に有効なトランザクション・コンテキストを通知する（図４のステップ４４）。この時点で、クライアント・プロセス３１は、生成されたトランザクションの完全な知識を有することになる。
【００３３】
この段階で、銀行口座オブジェクト３３１は、トランザクション・オブジェクト３３２と通常の方法で通信する（図４のステップ４５）。ただし、全ての通信は同じサーバＢプロセス３３内で行われるために、このような通信については如何なるプロセス間フローも全く必要ない。この例では、かかる通信は、銀行口座オブジェクト３３１をトランザクション・オブジェクト３３２に登録することを含み、そして当該トランザクションが終了するとき、トランザクション・オブジェクト３３２は、銀行口座オブジェクト３３１に対しコミット・コマンドまたはロールバック・コマンドを送る。
【００３４】
クライアント・プロセス３１は、他のサーバ・プロセスを呼び出して、トランザクションに参加させることができる。これらのサーバ・プロセスは、サーバＢプロセス中に生成されたトランザクション・オブジェクト３３２に登録する必要がある。この結果、これらのサーバ・プロセス間に幾つかのプロセス間フローが形成される。しかし、クライアント・プロセス３１が本発明の参考例を使うと、プロセス間フローの合計数は最小になる。なぜなら、少なくともサーバＢプロセス３３中のローカル資源とトランザクション・オブジェクト３３２との間の相互作用によっては、プロセス間フローが全く生じないからである。また、唯一のサーバ・プロセスだけに関わるトランザクションの場合、プロセス間フローは、クライアント・プロセス３１と単一のサーバＢプロセス３３との間だけに存在するに過ぎない。
【００３５】
参考例の別の実施形態では、サーバＢプロセス３３は、ＮＵＬＬトランザクション・コンテキストがサーバＢプロセス３３に入ったら直ちにトランザクション・オブジェクト３３２を生成するのではなく、その後の時点で、例えば、資源の登録中にトランザクション・オブジェクト３３２を生成することができる。
【００３６】
参考例の実施形態では、（全てのフィールドを零に設定した）ＮＵＬＬトランザクション・コンテキストを用いたが、他の特定の値のトランザクション・コンテキストを用いることもできる。例えば、トランザクション・コンテキストの専用データ・フィールドを特定の値に設定することができる。
【００３７】
以上では、ＩＢＭ社が図２に示すコンポーネント・ブローカ・シリーズ製品のために行った改良を、本発明の参考例として説明した。この改良によって、トランザクション中で呼び出された最初のサーバ・プロセス上にトランザクション・オブジェクトを配置するという方法が実現した。この改良は、本出願人の所有に係る英国特許出願第９８００８３０．３号（１９９８年１月１６日出願）に記載されている。しかしながら、最初に呼び出されるサーバ・プロセスに、トランザクション・オブジェクトを生成させるのが最も有益であるとは言えないトランザクションが数多く存在する。
【００３８】
例えば、トランザクションにおける最初の呼び出しが、クライアント・プロセスを認証する（例えば、クライアント・プロセスがこの型のトランザクションを実行することを許可されているか否かを確認する）ための認証ビジネス・オブジェクトに対する認証呼び出しであると仮定する。この場合、この認証ビジネス・オブジェクトを有するサーバ・プロセス中にトランザクション・オブジェクトを配置しても、プロセス間フローの数は減少しない。なぜなら、このサーバ・プロセスは、当該トランザクション中に更新される資源を表すビジネス・オブジェクトを有していないからである。すなわち、認証ビジネス・オブジェクトを有するこのサーバ・プロセス中にトランザクション・オブジェクトを生成した場合、当該トランザクションの終わりには、多くのプロセス間フローが必要になる。なぜなら、当該トランザクション中に更新される資源を表す全てのビジネス・オブジェクトは、別の複数のサーバ・プロセス中に存在しているからである。
【００３９】
別の例は、当該トランザクションにおけるビジネス・オブジェクトに対する最初の呼び出しが、一の資源を表す一のビジネス・オブジェクトに対する読み出し専用呼び出しの場合である。これに相当する１例は、トランザクションにおける最初の呼び出しが、銀行口座残高の値を読み出すことだけを要求しており、銀行口座資源を表すビジネス・オブジェクト中の如何なる値も更新することを要求していない場合である。この場合にも、このビジネス・オブジェクトを有するサーバ・プロセス中にトランザクション・オブジェクトを生成することは、都合が良くない。
【００４０】
本発明は、トランザクション・オブジェクトを生成すべきサーバ・プロセスを選択する際の一層多くの制御をクライアントに付与することを意図している。したがって、以下では、この追加された機能を中心に、好ましい実施形態を説明する。
【００４１】
図５において、クライアント・プロセス５１は、トランザクションの処理を命じている。当該トランザクションにおける遠隔のサーバ・プロセスに対する第１の呼び出しは、サーバＢプロセス５３中の認証ビジネス・オブジェクト５３１に対する呼び出しである。これは、クライアント・プロセス５１を認証するためのものである。当該トランザクションにおけるサーバ・プロセスに対する第２の呼び出しは、サーバＡプロセス５２中の銀行口座オブジェクト５２１に対する呼び出しである。これは、銀行口座の残高の値を単に読み出すためのものである。当該トランザクションにおけるサーバ・プロセスに対する第３の呼び出しは、サーバＣプロセス５４中の銀行口座オブジェクト５４１に対する呼び出しである。これは、この銀行口座の残高の値を減らして資金の引き出しを実現するためのものである。
【００４２】
前述のトランザクションにおいて、サーバＡプロセス５２またはサーバＢプロセス５３の中にトランザクション・オブジェクトを生成するのは、都合が良くない。なぜなら、これらのプロセスの中には、当該トランザクション中に更新される資源を表すビジネス・オブジェクトが配置されていないからである。そうではなくて、サーバＣプロセス５４中にトランザクション・オブジェクトを生成するのが都合が良い。なぜなら、サーバＣプロセス５４は、当該トランザクション中に更新される銀行口座オブジェクト５４１を有しているからである。
【００４３】
本発明の好ましい実施形態では、サーバ・プロセス５２、５３、５４中にダミー・ビジネス・オブジェクト５２２、５３２、５４２をそれぞれ配置する。前記ダミー・ビジネス・オブジェクトの各々には、周知のキー（例えば、サーバ名から生成されたキー）が付与されている。この結果、クライアント・プロセス５１は、ダミー・ビジネス・オブジェクトのうち任意のものを容易に探し出すことができる。各ダミー・ビジネス・オブジェクトには、CosTransactions::Transactionalオブジェクトから継承したものである限り、任意の型の機能を付与することができる。各ダミー・ビジネス・オブジェクトの目的は、複数のサーバ・プロセスの各々に配置されたオブジェクトを容易にアクセス可能にすることである。この結果、クライアント・プロセス５１は、複数のサーバ・プロセスの中から任意の１つのサーバ・プロセスを、トランザクション・オブジェクトが配置されている場所として選択することができる。クライアント・プロセス５１は、次の点を保証する。すなわち、当該トランザクションにおけるサーバ・プロセスに対する最初の呼び出しは、クライアント・プロセス５１がトランザクション・オブジェクトを生成することを望んでいる、特定のサーバ・プロセス中のダミー・ビジネス・オブジェクトに対する呼び出しである。もし、一のサーバ・プロセス中にダミー・ビジネス・オブジェクトが配置されていれば、そのサーバ・プロセスは、クライアント・プロセス５１がトランザクション・オブジェクトを配置するために選択する候補である。
【００４４】
例えば、図５において、前述の例を使うと、当該トランザクションにおけるクライアント・プロセス５１の最初の２つの呼び出しは、サーバＢプロセス５３中の認証ビジネス・オブジェクト５３１およびサーバＡプロセス５２中の銀行口座オブジェクト５２１に対する呼び出しである。しかし、クライアント・プロセス５１は、真に最初の遠隔呼び出し（すなわち、前記２つの呼び出しより前に行う呼び出し）がサーバＣプロセス５４中のダミー・オブジェクト５４２に対する呼び出しになるように、当該トランザクションを変更する。なぜなら、サーバＣプロセス５４は、当該トランザクション中に更新される銀行口座オブジェクト５４１が配置されている場所であるので、トランザクション・オブジェクトを配置するのに最も適したサーバ・プロセスであるからである。
【００４５】
それ故、図５に示すように、クライアント・プロセス５１は、サーバＣプロセス５４中のダミー・ビジネス・オブジェクト５４２に対して第１の呼び出しを行う（丸数字１を参照）。これは図４のステップ４２に対応する。しかし、クライアント・プロセス５１は、銀行口座オブジェクト５４１ではなく、ダミー・ビジネス・オブジェクト５４２に対し、ＮＵＬＬトランザクション・コンテキストを含んでいる呼び出しを送る。この呼び出しの唯一の目的は、サーバＣプロセス５４中にトランザクション・オブジェクト５４３をセットアップすることである（図６を参照）。ダミー・ビジネス・オブジェクト５４２は、クライアント・プロセス５１からのこの第１の呼び出しに含まれているＮＵＬＬトランザクション・コンテキストを認識し、この認識に応答してトランザクション・オブジェクト５４３を生成する。これは図４のステップ４３に対応する。第２に、クライアント・プロセス５１は、サーバＢプロセス５３中の認証ビジネス・オブジェクト５３１に対して第２の呼び出しを行って、クライアント・プロセス５１の認証をする（丸数字２を参照）。第３に、クライアント・プロセス５１は、サーバＡプロセス５２中の銀行口座オブジェクト５２１に対して第３の呼び出しを行って、この銀行口座の残高を読み出す（丸数字３を参照）。第４に、クライアント・プロセス５１は、サーバＣプロセス５４中の銀行口座オブジェクト５４１に対して第４の呼び出しを行って、この口座の残高を減らす（なぜなら、この口座から現金が引き出されているからである）（丸数字４を参照）。
【００４６】
一旦、サーバＣプロセス５４がトランザクション・オブジェクト５４３をローカルに生成すると、サーバＣプロセス５４は、クライアント・プロセス５１に対し、有効なトランザクション・コンテキストで応答する。これは、図４のステップ４４に対応する。
【００４７】
以上のように、本発明の好ましい実施形態は、次のように振る舞うクライアント・プロセスに関わる。すなわち、走らせようとするトランザクションに注視し、トランザクション・オブジェクトを配置するのに最も適しているのはどのサーバ・プロセスであるかを決定し、当該トランザクションの始めにおいて、決定したサーバ・プロセス中に配置されているダミー・ビジネス・オブジェクトに対して呼び出しを行う、ということである。このように、トランザクション・オブジェクトは、前記のようにして決定したサーバ・プロセス上に生成される。
【００４８】
第２の実施形態では、ダミー・ビジネス・オブジェクトを使わない。その代わりに、現存するオブジェクト（例えば、銀行口座オブジェクト５４１）上のダミー・メソッドを呼び出す。それ故、この第２の実施形態では、前述の図５の例における真に最初の呼び出しは、クライアント・プロセス５１から銀行口座オブジェクト５４１への呼び出しであり、銀行口座オブジェクト５４１のダミー・メソッド（例えば、bankaccount.hello()）を呼び出すものである。この結果、トランザクション・オブジェクト５４３は、銀行口座オブジェクト５４１が配置されているサーバＣプロセス５４に生成されることになる。
【図面の簡単な説明】
【図１】オブジェクト指向技術を用いた周知の異種クライアント／サーバ・アーキテクチャを示すブロック図である。
【図２】従来のＯＴＳのインプリメンテーションを示すブロック図である。
【図３】本発明の参考例に従ったＯＴＳのインプリメンテーションを示すブロック図である。
【図４】図３のＯＴＳのインプリメンテーションに従って、クライアント・プロセスが開始コマンドを発行するときに実行されるステップを示すフローチャートである。
【図５】本発明の好ましい実施形態に従ったＯＴＳのインプリメンテーションを示すブロック図である。
【図６】本発明の好ましい実施形態に従ったサーバ・プロセスを示すブロック図である。
【符号の説明】
５１…クライアント・プロセス、５２…サーバＡプロセス、５２１…銀行口座オブジェクト、５２２…ダミー・ビジネス・オブジェクト、５３…サーバＢプロセス、５３１…認証ビジネス・オブジェクト、５３２…ダミー・ビジネス・オブジェクト、５４…サーバＣプロセス、５４１…銀行口座オブジェクト、５４２…ダミー・ビジネス・オブジェクト、５４３…トランザクション・オブジェクト。
【図１】
0003579353.tif 000002
【図２】
0003579353.tif 000003
【図３】
0003579353.tif 000004
【図４】
0003579353.tif 000005
【図５】
0003579353.tif 000006
【図６】
0003579353.tif 000007