JP2001034476A - オブジェクトを管理する方法、システム及びプログラム記憶装置 - Google Patents

Abstract

(57)【要約】 【課題】 作業負荷を管理する分散オブジェクト指向コ
ンピューティング環境を実現する。 【解決手段】 通常はサーバ・インスタンスのコンテナ
によって実行される管理機能が、サーバ・インスタンス
に結合された資源マネージャに委譲される。たとえば、
ロッキング、セキュリティ制御、マルチシステム・キャ
ッシングおよびコミットメント制御などの管理機能の責
任が、コンテナから除去され、資源マネージャに委譲さ
れる。これによって、下層の資源マネージャでもたらさ
れる進行中の改良および機能拡張が、サーバ・インスタ
ンス内で即座に透過的に影響を及ぼすことができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般的にはオブジ
ェクト指向コンピューティング環境に関し、具体的に
は、信頼性があり、保護され、トランザクショナルであ
り、作業負荷を管理される分散オブジェクト指向コンピ
ューティング環境に関する。

【０００２】

【従来の技術】オブジェクト指向技術は、簡単に使用で
き再利用できる可搬性のあるアプリケーション・コード
を作成する際に使用されるますます重要になるツールに
なり続けている。オブジェクト指向技術の基本的な前提
は、オブジェクトの使用である。オブジェクトとは、イ
ンスタンス・メソッドとそれに関連する変数の特定の組
を有する実行時実体である。

【０００３】オブジェクトの使用性、可搬性、信頼性お
よび相互運用性を強化する努力において、いくつかの標
準規格が作成されてきた。そのような標準化の責任を負
うグループの１つを、Object Management Group（ＯＭ
Ｇ）と称するが、ＯＭＧは、オブジェクト指向技術の促
進に関心を抱く異なる会社、企業およびユーザの協会で
ある。

【０００４】Object Management Groupは、標準化の労
力において大きい行動を起こした。たとえば、ＯＭＧ
は、オブジェクト・リクエスト・ブローカ（ＯＲＢ）の
作成の責任を負うが、ＯＲＢは、コンピューティング環
境のクライアントとサーバの間の通信を実現するのに使
用される。ＯＲＢは、ＯＭＧが推奨する、コモン・オブ
ジェクト・リクエスト・ブローカ・アーキテクチャ（Ｃ
ＯＲＢＡ）と称するアーキテクチャに基づく。

【０００５】ＯＭＧの目標の１つが、変化し続けるコン
ピューティング産業の必要と要望に一致する、分散オブ
ジェクト指向アプリケーションおよびシステムを提供す
ることである。この目標には、複数のベンダによる世界
規模の異種ネットワークのサポートが含まれる。

【０００６】

【発明が解決しようとする課題】Object Management Gr
oupの目標およびオブジェクト指向産業全体としての目
標をかなえるために労力が払われてきたが、さらなる機
能強化が必要である。たとえば、信頼性があり、保護さ
れ、トランザクショナルであり、作業負荷を管理する分
散オブジェクト指向コンピューティング環境の必要が存
在する。

【０００７】

【課題を解決するための手段】コンピューティング環境
内でオブジェクトを管理する方法の提供を介して、従来
技術の短所が克服され、追加の長所がもたらされる。こ
の方法は、たとえば、サーバ・インスタンスによって、
サーバ・インスタンス内でディスパッチされるオブジェ
クトの１つまたは複数の属性を要求するステップと、１
つまたは複数の属性を取得するステップとを含み、１つ
または複数の属性の取得に使用されるロッキング、セキ
ュリティ制御、マルチシステム・キャッシングおよびコ
ミットメント制御のうちの少なくとも１つが、サーバ・
インスタンスに結合された少なくとも１つの資源マネー
ジャによって実行される。

【０００８】一例では、ロッキング、セキュリティ制
御、マルチシステム・キャッシングおよびコミットメン
ト制御のうちの少なくとも１つの責任が、サーバ・イン
スタンスのコンテナから除去され、少なくとも１つの資
源マネージャに委譲される。

【０００９】もう１つの例では、サーバ・インスタンス
が、サーバ・インスタンス内の１つまたは複数の接続オ
ブジェクトを使用して、１つまたは複数の資源マネージ
ャに結合される。

【００１０】本発明のもう１つの実施形態では、コンピ
ューティング環境内でオブジェクトを管理する方法が提
供される。この方法は、たとえば、少なくとも１つのオ
ブジェクト管理機能の責任を、コンピューティング環境
の少なくとも１つのコンテナから除去するステップと、
少なくとも１つのオブジェクト管理機能の責任を、少な
くとも１つのコンテナに結合された少なくとも１つの資
源マネージャに委譲するステップとを含み、少なくとも
１つのオブジェクト管理機能が、ロッキング、セキュリ
ティ制御、マルチシステム・キャッシングおよびコミッ
トメント制御を含む。

【００１１】本発明のもう１つの態様では、コンピュー
ティング環境内でオブジェクトを管理するシステムが提
供される。このシステムは、たとえば、サーバ・インス
タンスによって、サーバ・インスタンス内でディスパッ
チされるオブジェクトの１つまたは複数の属性を要求す
るための手段と、１つまたは複数の属性を取得するため
の手段とを含み、１つまたは複数の属性の取得に使用さ
れるロッキング、セキュリティ制御、マルチシステム・
キャッシングおよびコミットメント制御のうちの少なく
とも１つが、サーバ・インスタンスに結合された少なく
とも１つの資源マネージャによって実行される。

【００１２】本発明のもう１つの態様では、コンピュー
ティング環境内でオブジェクトを管理するシステムが提
供される。このシステムは、たとえば、コンピューティ
ング環境の少なくとも１つのコンテナから少なくとも１
つのオブジェクト管理機能の責任を除去するための手段
と、少なくとも１つのオブジェクト管理機能の責任を、
少なくとも１つのコンテナに結合された少なくとも１つ
の資源マネージャに委譲するための手段とを含む。

【００１３】本発明のもう１つの態様では、コンピュー
ティング環境内でオブジェクトを管理するシステムが提
供される。このシステムは、たとえば、サーバ・インス
タンス内でディスパッチされるオブジェクトの１つまた
は複数の属性を要求するように適合されたサーバ・イン
スタンスを含み、サーバ・インスタンスが、１つまたは
複数の属性を取得するようにさらに適合され、１つまた
は複数の属性の取得に使用されるロッキング、セキュリ
ティ制御、マルチシステム・キャッシングおよびコミッ
トメント制御のうちの少なくとも１つが、サーバ・イン
スタンスに結合された少なくとも１つの資源マネージャ
によって実行される。

【００１４】本発明のもう１つの態様では、コンピュー
ティング環境内でのオブジェクトの管理を引き起こすた
めのコンピュータ可読プログラム・コード手段をその中
に埋め込まれた少なくとも１つのコンピュータ使用可能
媒体を含む製造品が提供される。製造品のコンピュータ
可読プログラム・コード手段は、たとえば、サーバ・イ
ンスタンスによって、サーバ・インスタンス内でディス
パッチされるオブジェクトの１つまたは複数の属性をコ
ンピュータに要求させるためのコンピュータ可読プログ
ラム・コード手段と、１つまたは複数の属性をコンピュ
ータに取得させるためのコンピュータ可読プログラム・
コード手段とが含まれ、１つまたは複数の属性の取得に
使用されるロッキング、セキュリティ制御、マルチシス
テム・キャッシングおよびコミットメント制御のうちの
少なくとも１つが、サーバ・インスタンスに結合された
少なくとも１つの資源マネージャによって実行される。

【００１５】本発明は、下層のデータ・マネージャにい
くつかの管理機能の責任を有利に委譲し、これらの機能
をサーバ・インスタンス内で複製する必要をなくす。

【００１６】追加の特徴および長所は、本発明の教示を
介して理解される。本発明の他の実施形態および態様
は、本明細書で詳細に説明され、請求される発明の一部
とみなされる。

【００１７】

【発明の実施の形態】本発明の原理によれば、オブジェ
クト指向コンポーネントベース・プログラミング・モデ
ルをサポートし、分散式であり、信頼性があり、保護さ
れ、トランザクショナルであり、作業負荷が管理される
コンピューティング環境をもたらすインフラストラクチ
ャが提供される。

【００１８】本発明の機能を組み込み、使用するコンピ
ューティング環境の一実施形態を、図１に示す。コンピ
ューティング環境１００には、たとえば、１つまたは複
数のクライアント・システム１０４に結合された１つま
たは複数のサーバ・システム１０２が含まれる。本明細
書に記載の例では、サーバ・システム１０２およびクラ
イアント・システム１０４は、International Business
Machines Corporation（米国ニューヨーク州アーモン
ク）が提供し、参照によって全体を本明細書に組み込ま
れる「Enterprise Systems Architecture/390 Principl
es of Operation」、IBM Publication No. SA22-7201-0
5、Sixth Edition（1998年9月）に記載のEnterprise Sy
stems Architecture（ＥＳＡ）／３９０に基づく。しか
し、他の例では、１つまたは複数のサーバ・システムま
たはクライアント・システムを、ＵＮＩＸ（登録商標）
アーキテクチャを含むがこれに制限されない他のアーキ
テクチャに基づくものとすることができる。さらに、あ
るアーキテクチャのサーバ・システムを、別のアーキテ
クチャのサーバ・システムまたはクライアント・システ
ムに結合することができる。

【００１９】上記に加えて、一実施形態では、少なくと
も１つのサーバ・システム１０２ならびに１つまたは複
数のクライアント・システムが、オブジェクト指向プロ
グラミングとオブジェクト指向の概念をサポートする。
オブジェクト指向のプログラミングおよび概念は、たと
えば、Ben-Natan著、「CORBA A Guide To Common Objec
t Request Broker Architecture」、McGraw-Hill Publi
shers刊、1995年と、Christina Lau著、「Object- Orie
nted Programming Using SOM and DSOM」、VanNostrand
Reinhold Publishers刊、１９９４年に記載されてお
り、この両方が、参照によってその全体を本明細書に組
み込まれる。ＣＯＲＢＡは、さらに、WWW.OMG.ORG/libr
ary/C2INDX.HTMLで入手できる「CORBA 2.2/IIOP Specif
ication」に記載されており、これは、参照によってそ
の全体を本明細書に組み込まれる。

【００２０】サーバ・システム１０２には、たとえば、
本発明のさまざまな態様のインフラストラクチャおよび
機能を提供する、コンポーネント・ブローカ実行時サー
ビス１０６が含まれる。一例では、コンポーネント・ブ
ローカ実行時サービス１０６に、たとえば、システム管
理サービス、管理オブジェクト・フレームワーク・イン
ターフェース、ネーミング・サービス、Life Cycleサー
ビス、トランザクショナル・サービス、インターフェー
ス・リポジトリ・サービスおよびロケーション・サービ
ス・エージェント・サービスが含まれる。これらのサー
ビスならびに他のサービスは、下で説明するように、本
発明の諸態様の実施に使用される。コンポーネント・ブ
ローカ実行時サービスは、たとえば、コンポーネント・
ブローカ製品に含まれる可能性がある。コンポーネント
・ブローカ製品が、本発明のさまざまな態様を含むかイ
ンプリメントする可能性もある。コンポーネント・ブロ
ーカのさまざまな特徴の実施形態の１つが、それぞれ参
照によってその全体を本明細書に組み込まれる、「Comp
onent Broker Programming Reference Release 2.0」、
IBM Publication No. SC09-2810-04（1998年12月）、
「Component Broker Programming Guide Release 2.
0」、IBM Publication No. GO4L-2376-04（1998年12
月）および「Component Broker Advanced Programming
Guide Release 2.0」、IBM Publication No. SC09-2708
-03（1998年12月）に記載されている。コンポーネント
・ブローカまたはコンポーネント・ブローカ実行時サー
ビスは、オペレーティング・システムとは別にまたはオ
ペレーティング・システムと共にパッケージ化して販売
される可能性がある。

【００２１】サーバ・システム１０２には、コンピュー
ティング環境内の資源の組を所有し、制御する１つまた
は複数の資源マネージャ１０８と、サーバ・システムの
動作を制御する少なくとも１つのオペレーティング・シ
ステム１１０も含まれる。

【００２２】資源マネージャの一例が、International
Business Machines Corporation（米国ニューヨーク州
アーモンク）が提供するＤＢ２などのデータベース管理
機能である。ＤＢ２は、参照によってその全体を本明細
書に組み込まれる「OS/390 Version 5 Release Guid
e」、IBM Publication No. SC26-8965-01（1997年6月）
に記載されている。ＤＢ２によって管理されるデータ
は、サーバ・システム１０２に結合された外部記憶装置
１１２（たとえば、直接アクセス記憶装置（ＤＡＳ
Ｄ））に格納することができる。

【００２３】オペレーティング・システム１１０の一例
が、International Business Machines Corporation
（米国ニューヨーク州アーモンク）が提供するＯＳ／３
９０または多重仮想記憶域（ＭＶＳ）オペレーティング
・システムである。ＯＳ／３９０は、それぞれ参照によ
って全体を本明細書に組み込まれる、「MVS Programmin
g: Assembler Services Guide」、IBM Publication No.
GC28-1762-01、SecondEdition（1996年9月）および「M
VS Programming: Assembler Services Reference」、IB
M Publication No. GC28-1910-01、Second Edition（19
96年9月）に記載されている。

【００２４】本発明の一態様によれば、オペレーティン
グ・システム１１０には、少なくとも１つのサーバ・イ
ンスタンス１１４が含まれ、サーバ・インスタンス１１
４は、たとえば、サーバ・システム１０２内で定義され
たソフトウェア・プロセスである。各サーバ・インスタ
ンスは、１つまたは複数のアドレス空間内にあり、たと
えば、コンポーネント・ブローカ実行時サービス１０６
によって提供される１つまたは複数のグラフィカル・ユ
ーザ・インターフェース（ＧＵＩ）を使用して定義され
る。グラフィカル・ユーザ・インターフェースは、サー
バ・インスタンスに名前を付け、ある特性（たとえば、
サーバ・インスタンスが安全であるか、作業負荷を管理
されるかなど）と関連付けることができるようにするオ
プションを提供する。ＧＵＩに提示される情報は、ＤＢ
２データベースなどのデータベースに格納される。サー
バの定義の後に、サーバは、たとえば、ＤＢ２データベ
ースから必須情報を引き出すアドレス空間作成を使用す
ることによって作成される。

【００２５】サーバ・インスタンス１１４には、たとえ
ば、１つまたは複数のオブジェクト１１６、１つまたは
複数のコンテナ１１８および少なくとも１つのオブジェ
クト・リクエスト・ブローカ（ＯＲＢ）１２０などのさ
まざまなコンポーネントが含まれる。サーバ・インスタ
ンス１１４のコンポーネントのそれぞれを、下で詳細に
説明する。

【００２６】オブジェクト１１６は、インスタンス・メ
ソッド（すなわち、オブジェクトに対して実行される機
能）とそれに関連するインスタンス変数（オブジェクト
に固有のデータを格納するのに使用される）の特定の組
を有する実行時実体（たとえばアプリケーション・コー
ド）である。

【００２７】オブジェクトの一例が、ビジネス・オブジ
ェクト２０２、データ・オブジェクト２０４およびキー
・オブジェクト２０６などのさまざまなコンポーネント
を含む管理オブジェクト２００（図２）である。管理オ
ブジェクト２００は、管理オブジェクト・フレームワー
クを介して作成され、管理オブジェクト・フレームワー
クには、継承されるインターフェースの組が含まれる。
管理オブジェクト・フレームワークの諸部分が、作成時
にビジネス・オブジェクトによって継承され、これによ
って、ビジネス・オブジェクトが、サーバ・インスタン
ス１１４内に常駐できるようになる。一例として、ビジ
ネス・オブジェクト２０２は、管理オブジェクト・フレ
ームワークから、「managed object with data object
（データ・オブジェクトを有する管理オブジェクト）」
と称するインターフェースを継承する。これによって、
データ・オブジェクト２０４がもたらされる。

【００２８】データ・オブジェクト２０４は、ビジネス
・オブジェクトに対するヘルパ・オブジェクトである。
データ・オブジェクト２０４は、ビジネス・オブジェク
トのユーザには露出されない。このデータ・オブジェク
ト内に含まれるのが、データを参照するための手段（た
とえば、ＤＢ２データに対するＳＱＬ）である。すなわ
ち、データ・オブジェクトには、スキーマ・マップが含
まれる。これは、データベースに移動し、要求された情
報を検索し、その情報をビジネス・オブジェクトに渡す
責任を負うオブジェクトである。

【００２９】メソッドの組が、「managed object with
data object」インターフェースに導入される。これに
は、たとえば、initForReactivationメソッド、initFor
Creationメソッド、uninitForPassivationメソッドおよ
びuninitForDestructionメソッドが含まれる。これらの
メソッドは、コンテナが機能を実行する前またはその後
に、ビジネス・オブジェクトに対して駆動される。仮想
メモリ内でオブジェクトを管理するのは、コンテナであ
る。これらのメソッドは、コンテナが行ったことをビジ
ネス・オブジェクトに知らせ、コンテナが管理するイベ
ントの結果として処理を行う機会をビジネス・オブジェ
クトに与えるのに使用される。

【００３０】具体的に言うと、initForReactivationメ
ソッドとinitForCreationメソッドは、下でさらに説明
するように、管理オブジェクトの仮想メモリ・イメージ
をメモリに移動し、初期設定するのに使用される。unin
itForPassivationメソッドは、仮想メモリから管理オブ
ジェクトのイメージを除去するのに使用され、uninitFo
rDestructionメソッドは、やはり下でさらに説明するよ
うに、支援記憶装置（たとえばＤＢ２データベース）か
ら管理オブジェクトを削除するのに使用される。

【００３１】ビジネス・オブジェクトをインプリメント
する者は、上で述べたメソッドをインプリメントする責
任を負う。たとえば、アプリケーション開発者が、型Ａ
のビジネス・オブジェクトのインプリメンテーションの
作成を希望すると仮定する。アプリケーション開発者
は、「managed object with data object」インターフ
ェースを継承する、型Ａのインターフェースを使用す
る。そのインターフェースは、アプリケーション開発者
がインプリメンテーションを提供する、上の４つのメソ
ッドのための継承を提供する。

【００３２】アプリケーション開発者は、ビジネス・オ
ブジェクトに関連する、キー・オブジェクト２０６のイ
ンプリメンテーションも提供する。キー・オブジェクト
には、ホーム・コレクション内で管理オブジェクトを他
の管理オブジェクトから識別するのに使用されるキー値
が含まれる。

【００３３】一実施形態では、提供されるインプリメン
テーションのすべてが、コンパイルされ、リンクされ、
動的リンク・ライブラリ（ＤＬＬ）にパッケージ化され
る。ＤＬＬは、システム管理アプリケーションによって
作成されるホーム・コレクション・オブジェクトと称す
るオブジェクトによってサポートされる。

【００３４】具体的に言うと、各管理オブジェクトは、
ホームに存在するが、ホームは、名前によって識別さ
れ、それに関連するプロパティの定義済みの組を有す
る。ホームとＤＬＬ内の情報との間の関係は、データ定
義言語（ＤＤＬ）の形のシステム管理メタデータの組に
よって表される。ＤＤＬには、たとえば、ホームの名
前、ホームのプロパティ、ＤＬＬをサポートすることに
なるコンテナ（下で説明する）の名前が含まれる。さら
に、ＤＤＬには、ビジネス・オブジェクト・クラスの名
前、データ・オブジェクト・クラスの名前および主キー
・クラスの名前が含まれる。ＤＤＬパッケージは、シス
テム管理アプリケーションにインポートされる。システ
ム管理アプリケーションは、名前付きのコンテナが存在
する（すなわち、システム管理定義がある）ことを確認
し、その後、ＤＬＬをサポートするホーム・コレクショ
ン・オブジェクトを作成する。ホームは、それが付加さ
れるコンテナから継承するので、ホームとコンテナのマ
ージがある。したがって、メタデータのマージがある。

【００３５】図１に戻って、サーバ・インスタンス１１
４には、１つまたは複数のコンテナ１１８も含まれる。
サーバ・インスタンスに関連するコンテナのリストが、
サーバ・インスタンスの作成中に作成され、たとえばＤ
Ｂ２データベースに格納される。一例では、各サーバ・
インスタンスは、サーバ・インスタンスにブートストラ
ップされ、それに関連する他のすべてのコンテナを管理
するルート・コンテナを有する。サーバ・インスタンス
自体に類似して、各コンテナは、たとえば、コンポーネ
ント・ブローカ実行時サービス１０６によって供給され
る１つまたは複数のグラフィカル・ユーザ・インターフ
ェースを使用して定義される。ＧＵＩを使用して、コン
テナに名前が付けられ、それに関連する方針（下で説明
する）が定義される。やはり、この定義はＤＢ２に格納
される。さらに、サーバ・インスタンスとコンテナの間
の関係が、ＤＢ２に格納される。

【００３６】各コンテナは、そのコンテナに関連する１
つまたは複数の管理オブジェクトまたはビジネス・オブ
ジェクト（本明細書では単にオブジェクトと呼称する）
を突きとめるのに使用される。すなわち、コンテナは、
１つまたは複数のオブジェクトのホームとみなされる。
コンテナは、たとえばＯＲＢ１２０によってコンテナに
供給されるオブジェクト・キーを使用してオブジェクト
を突きとめることができる。オブジェクトが仮想メモリ
内にない場合には、コンテナは、記憶装置（たとえばデ
ータベース）から仮想メモリへオブジェクトを持ち込
み、オブジェクトを実体化する。その後、コンテナは、
そのオブジェクトの仮想アドレスをＯＲＢ１２０に渡
す。というのは、オブジェクト・キーをコンテナに渡し
たのがそのオブジェクト・リクエスト・ブローカだから
である。ＯＲＢは、アドレスを受け取った時に、そのオ
ブジェクトに対するメソッドをディスパッチすることが
できる。

【００３７】ＯＲＢ１２０は、サーバ・インスタンスと
リモート・クライアントの間の通信を管理する責任を負
う。具体的に言うと、ＯＲＢは、リモート・クライアン
トからリクエストを受け取り、要求されているオブジェ
クトを判定し、要求されたメソッドをその特定のオブジ
ェクトに対して駆動する。オブジェクトを突きとめるた
めに、オブジェクト・リクエスト・ブローカは、オブジ
ェクト・キーをコンテナに渡し、コンテナは、オブジェ
クト・リクエスト・ブローカのためにオブジェクトを突
きとめる。

【００３８】リモート・クライアントは、たとえば、ク
ライアント・システム１０４内で突きとめられ、このク
ライアント・システム１０４には、少なくとも１つのオ
ペレーティング・システム１３０によって管理される１
つまたは複数のクライアント・インスタンス１２８また
はクライアントが含まれる。オペレーティング・システ
ム１３０は、たとえば、International Business Machi
nes Corporationが提供するＯＳ／３９０オペレーティ
ング・システムである。他の例では、オペレーティング
・システム１３０は、Windows ＮＴ（登録商標）、ＡＩ
Ｘ（登録商標）または本発明と共に使用することのでき
る他のいずれかのオペレーティング・システムである。

【００３９】クライアントには、たとえば、１つまたは
複数のアプリケーション１３２、１つまたは複数のリモ
ート・アクセス・プロキシ・オブジェクト１３４および
クライアント・オブジェクト・リクエスト・ブローカ
（ＯＲＢ）１３６が含まれる。

【００４０】アプリケーション１３２は、サーバ・シス
テム１０２のサーバ・インスタンス１１４内で突きとめ
られたオブジェクトへのリクエストを初期設定する。各
リクエストには、インタオペラブル・オブジェクト・リ
ファレンス３００（図３）が含まれ、インタオペラブル
・オブジェクト・リファレンス３００は、オブジェクト
の識別と、オブジェクトが常駐するサーバ・インスタン
スの識別を供給する。具体的に言うと、インタオペラブ
ル・オブジェクト・リファレンス３００には、たとえ
ば、オブジェクトの型を含む、オブジェクトに関する情
報を供給するヘッダ３０２と、オブジェクトを収納する
サーバ・インスタンスの位置情報を提供するネットワー
ク・アドレッシング情報３０４と、オブジェクトの識別
（すなわちキー）を供給するオブジェクト・キーが含ま
れる。

【００４１】アプリケーションがリクエストを発行する
時には、そのリクエストは、アプリケーションとＯＲＢ
１３６に結合されたリモート・アクセス・プロキシ・オ
ブジェクト１３４によって代行受信される。リモート・
アクセス・プロキシ・オブジェクトは、クライアント・
アプリケーションに、クライアント・アプリケーション
がリモート・オブジェクトではなくローカル・オブジェ
クトに対してメソッドを駆動しているという錯覚を与え
る。リモート・アクセス・プロキシ・オブジェクトは、
リクエストをＯＲＢ１３６に渡し、ＯＲＢ１３６は、そ
のリクエストを、たとえばＴＣＰ／ＩＰ接続１３８を介
して、所与のサーバ・インスタンスのＯＲＢ１２０に転
送する。ＯＲＢ１３６は、リクエストを送信する先のサ
ーバ・インスタンスを知っている。というのは、そのサ
ーバ・インスタンスが、リクエストと共に渡されるイン
タオペラブル・オブジェクト・リファレンス内に配置さ
れたネットワーク・アドレッシング情報３０４で識別さ
れるからである。

【００４２】インタオペラブル・オブジェクト・リファ
レンスは、クライアントによるリクエストに対する応答
の結果として、または、なんらかのインバウンド・パラ
メータとして、クライアントに供給される。たとえば、
インタオペラブル・オブジェクト・リファレンスは、下
でさらに説明するように、ネーミング・サービスによっ
てクライアントに供給することができる。インタオペラ
ブル・オブジェクト・リファレンスが、クライアント側
ＯＲＢにインポートされる時には、そのクライアント側
ＯＲＢは、それをオブジェクト・リファレンスとして認
識し、それに問い合わせて、そのリファレンスを用いて
行うべきことを判定する。それはオブジェクト・リファ
レンスであるから、ＯＲＢ１３６は、リモート・アクセ
ス・プロキシ・オブジェクトを作成し、アドレッシング
情報をプロキシに関連付け、リモート・アクセス・プロ
キシ・オブジェクトの仮想アドレスを、それの使用を望
むアプリケーションに渡す。したがって、アプリケーシ
ョンがオブジェクトを駆動する時には、アプリケーショ
ンは、プロキシと通信し、プロキシが、クライアント側
ＯＲＢに進む。クライアント側ＯＲＢは、プロキシ・オ
ブジェクトのＩＯＲに格納されたネットワーク・アドレ
ッシング情報を使用して、サーバ・インスタンスを突き
とめ、サーバ・インスタンスに、内部が見えないデータ
としてオブジェクト・キーを渡す。したがって、クライ
アント内に常駐するプロキシ・オブジェクトは、リモー
ト・サーバ・インスタンス内に常駐するターゲット・オ
ブジェクトへの、ネットワークにまたがるリファレンス
を表す。

【００４３】上で説明したように、リモート・アクセス
・プロキシ・オブジェクトは、物理的にネットワーク内
の別のアドレス空間に常駐するターゲット・オブジェク
トにメソッド・リクエストを配送するために、クライア
ント側オブジェクト・リクエスト・ブローカを駆動する
のに使用される。クライアント・アプリケーションは、
ターゲット・サーバ・オブジェクトの実際の仮想メモリ
・アドレスを使用しないので、サーバ・インスタンスに
常駐する物理オブジェクトのライフ・サイクルは、その
オブジェクトへの未解決のクライアント・リファレンス
の数から独立にすることができる。

【００４４】しかし、ターゲット・オブジェクトのクラ
イアント（すなわちリクエスタ）が、物理的にターゲッ
ト・オブジェクト自体と同一のアドレス空間内に常駐す
る場合には、オブジェクト・リクエスト・ブローカの相
互作用が必要ではないので、仮想メモリ・ポインタを用
いてターゲット・オブジェクトへのリファレンスを表す
ことが一般的に行われている。ＯＲＢは、通常は、同一
のアプリケーション・サーバ・プロセス（すなわち、同
一のアドレス空間）内の通信を容易にするためではな
く、異なるアプリケーション・プロセスにまたがる（す
なわち、異なるアドレス空間にまたがる）通信をもたら
すためだけに使用される。したがって、ローカル・アク
セスの場合には、ターゲット・オブジェクトのライフ・
サイクルは、そのオブジェクトへの未解決のローカル・
リファレンスの追跡に密接にバインドされる。

【００４５】ターゲット・オブジェクトのライフ・サイ
クルと未解決のローカル・リファレンスとのバインディ
ングに関連する、複数の問題が存在する。第１に、オブ
ジェクトへのローカル・リファレンスが、リモート・リ
ファレンスと異なる挙動を示すので、ローカル／リモー
ト透過性の原理が崩れる。第２に、この手法では、ター
ゲット・オブジェクトの仮想メモリ常駐コピーの管理が
制約され、メモリ常駐性が未解決のローカル・リファレ
ンスの数に依存するようになる。第３に、ターゲット・
オブジェクトの物理コピーが、クライアント・アプリケ
ーション内の仮想アドレス・ポインタと直接に結び付け
られるので、活性化などを決定するいくつかのインスタ
ンス管理方針と、さまざまな実行コンテキスト境界での
分離レベルが、インプリメント不能になる。というの
は、オブジェクトへのリファレンスが、異なる実行コン
テキストで走行中の複数の作業単位によって使用されな
いことを保証できないからである。言い換えると、ター
ゲット・オブジェクトの別々にキャッシュ記憶されたコ
ピーを、サーバ・インスタンス（上で説明した）のイン
スタンス管理コンポーネント（たとえばコンテナ）によ
って提供することができない。というのは、リファレン
スの共用使用が、オブジェクトの単独のキャッシュ記憶
されたコピーの共用使用をもたらすからである。

【００４６】前述に基づいて、ローカル・オブジェクト
・リファレンスを、インスタンス管理コンテナ内のター
ゲット・オブジェクトの仮想メモリ・コピーの管理から
分断する必要が存在する。さらに、オブジェクトを、ク
ライアント・アプリケーション（すなわちリクエスタ）
によって所有されるアドレス・ポインタから独立（たと
えばバインドされない）になることを可能にする必要が
存在する。したがって、本発明の一態様によれば、ロー
カル・プロキシがサーバ・インスタンスに追加され、そ
の結果、アドレス空間内でリモートであれローカルであ
れ、ターゲット・オブジェクトへのアクセスのすべて
が、プロキシを介して管理されるようにする。

【００４７】ローカル・アクセスのためのサーバ・イン
スタンス上のローカル・プロキシの追加を、図４に示
す。ローカル・アクセス・プロキシ４００は、サーバ・
インスタンス１１４内の１つのオブジェクト４０２（た
とえば、管理オブジェクトまたはビジネス・オブジェク
ト）またはＯＲＢが、サーバ・インスタンス１１４のオ
ブジェクトを駆動するクライアント１２８内のアプリケ
ーションに類似の形でサーバ・インスタンス内の別のオ
ブジェクト４０４（たとえば管理オブジェクトまたはビ
ジネス・オブジェクト）を駆動できるようにする。有利
なことに、これによって、アクセスがローカルとリモー
トのどちらであるかに無関係に同一の形でオブジェクト
を駆動できるという点で、ローカル／リモート透過性が
もたらされる。

【００４８】ローカル・プロキシ作成に関連する論理の
一例を、図５および６に関連して説明する。まず、オブ
ジェクト・リファレンスから管理オブジェクト（たとえ
ばオブジェクトＢ）へのポインタを取得することを望
む、ＯＲＢなどのリクエスタは、オブジェクト・リファ
レンスをルート・コンテナに渡し、管理オブジェクト・
ポインタを要求する（ステップ５００、図５）。具体的
に言うと、一実施形態では、オブジェクト・キー値全体
が、ルート・コンテナに渡される。オブジェクト・キー
値は、ターゲット管理オブジェクトの階層名キー経路で
ある。たとえば、オブジェクト・キー値は、「root/con
tainer1/123456」になる可能性があるが、この場合、
「root」は、ルート・コンテナのキーであり、「contai
ner1」は、管理オブジェクトを保持するコンテナのキー
であり、「１２３４５６」は、コンテナ内の管理オブジ
ェクトのキーである。

【００４９】ルート・コンテナは、キーのルート・コン
テナ部分をはぎ取り、キーの残りを次のコンテナ、たと
えばコンテナ１に渡す（ステップ５０２）。コンテナ１
は、キーのコンテナ１部分をはぎとる（ステップ５０
４）。

【００５０】ローカル・プロキシ・サポートの一部とし
て、コンテナ１は、ローカル・アクセス・プロキシを作
成し（ステップ５０６）ローカル・アクセス・プロキシ
のアドレスをリクエスタに返す（ステップ５０８）。

【００５１】一例では、ローカル・アクセス・プロキシ
を作成するために、コンテナ（たとえばコンテナ１）
が、まず、その構成されたメタデータを介して、管理さ
れるオブジェクトの型（たとえば型Ｂ）を判定する（ス
テップ６００、図６）。コンテナは、クラス・マネージ
ャ４０６（たとえば、インターフェース名のリストを表
すテーブル）から、必要な情報を検索する。たとえば、
コンテナは、ＤＬＬによってロードされるローカル・プ
ロキシ・ファクトリの項目を検索して、型Ｂのローカル
・プロキシを作る（ステップ６０２）。コンテナは、そ
のプロキシ・ファクトリに対してリクエストを駆動し、
ローカル・プロキシＢのインスタンスを得る（ステップ
６０４）。ローカル・プロキシＢが作成され、このプロ
キシのアドレスが、呼出し元オブジェクト（たとえばＯ
ＲＢ）に渡される（もう１つの例では、オブジェクトＡ
などのオブジェクトのプロキシが、実際の呼出しを行
い、したがって、プロキシＢのアドレスは、オブジェク
トＡのプロキシに渡され、このプロキシがオブジェクト
Ａにそのアドレスを渡す）。

【００５２】リクエスタは、ローカル・アクセス・プロ
キシのアドレスを受け取った時に、もう１つのリクエス
トを発行するが、このリクエストは、ローカル・アクセ
ス・プロキシに送られ、ローカル・アクセス・プロキシ
が、ターゲット・オブジェクトと通信する。具体的に言
うと、一実施形態では、ローカル・アクセス・プロキシ
・オブジェクトが、コンテナ（たとえばコンテナ１）に
問い合わせて、ターゲット管理オブジェクトの実際の仮
想メモリ・アドレスを得る。このアドレスを得るため
に、ローカル・アクセス・プロキシは、ターゲット・オ
ブジェクトの主キーをコンテナに渡す。

【００５３】上で詳細に説明したのは、オブジェクトの
リクエスタと同一のアドレス空間に常駐するオブジェク
トを含むオブジェクトにアクセスするためのローカル・
アクセス・プロキシの使用である。一態様では、ローカ
ル・アクセス・プロキシを使用する時に、オブジェクト
・リファレンスの使用が、「dupe」および「release」
ＣＯＲＢＡメソッドの適当な使用を含めることであるこ
とが一般的である。実際に、一実施形態では、ＣＯＲＢ
Ａオブジェクトへのリファレンスを保持する手段とし
て、「t-var」の使用が推奨される。この推奨は、管理
オブジェクトへのアクセスが、ローカルである場合で
も、ＯＲＢ境界にまたがる場合でも適用される。ＶＡＲ
は、Ｃ＋＋プログラム内のスコープから外れる時のプロ
キシの解放を引き起こす。

【００５４】本明細書に記載の手法を用いると、ローカ
ル・アクセス・プロキシが、適当なターゲット・オブジ
ェクトに動的に切り替えることができるようになり、そ
れと同時に、コンテナが、その活性化されたオブジェク
トを、指定された方針に従って管理できるようになる。
具体的に言うと、ローカル・アクセス・プロキシは、そ
のコンテナに進んで、オブジェクトが駆動されている下
層のコンテキストに基づいて（リアルタイムで）駆動す
べきオブジェクトを見つけることができる。これによっ
て、コンテナが、その方針に従ってオブジェクトを管理
できるようになる。一例では、コンテナは、管理オブジ
ェクトのメソッド・ディスパッチのそれぞれの前と後の
両方に問い合わされる。この問合せは、ローカル・プロ
キシから行われる。コンテナは、活性化された管理オブ
ジェクトの後処理に対する変更が、ローカル・プロキシ
からの呼出しの「前」と「後」の間に発生しないことを
保証する。

【００５５】これらの方針は、オブジェクトの記憶装置
内コピーのライフ・サイクルだけではなく、それぞれが
トランザクションまたはセッションなどの特定の実行コ
ンテキストと関連するターゲット・オブジェクトの複数
のコピーを管理することによってインプリメントされる
物理的な分離レベルも制御する。ターゲット・オブジェ
クトのメモリ常駐性を、オブジェクトへの未解決のロー
カル・リファレンスの数から独立にすることによって、
コンテナは、サーバ・インスタンスの仮想メモリをより
効率的に管理するためにオブジェクトをページアウトす
ることができ、それと同時に、オブジェクトがクライア
ント・アプリケーションによって参照される場合に、オ
ブジェクトのページインを引き起こすためのトリガ機構
を提供する。

【００５６】本発明の一態様によれば、オブジェクトの
インストール時（たとえばコンテナを定義する時）に顧
客が選択できる管理方針の組が提供される。これらの方
針は、サーバ・インスタンス１１４（図７）などの分散
オブジェクト・サーバの仮想メモリ内の一時的なオブジ
ェクトと永続的なオブジェクトの両方の、状態コヒーレ
ンシ、分離レベルおよび常駐ライフタイムの管理を制御
する。方針７００は、１つまたは複数のコンテナ１１８
によって管理され、方針７００には、たとえば、活性化
分離方針、パシベーション方針、フラッシュ方針および
リフレッシュ方針が含まれる。これらの方針のそれぞれ
を、下で説明する。

【００５７】活性化とは、管理オブジェクト（またはビ
ジネス・オブジェクト）の仮想メモリ・イメージが、メ
モリに持ち込まれ、たとえばinitForReactivationメソ
ッドまたはinitForCreationメソッドを介して初期設定
される処理である。活性化は、管理オブジェクト・ファ
クトリを用いて管理オブジェクトを作成する時に暗黙の
うちに行われる処置である。活性化の処理は、トランザ
クション管理、セッション管理、ロッキングなどとはア
ーキテクチャ的に独立である。活性化は、仮想メモリ内
のオブジェクト・イメージのインスタンス化と、ＯＲＢ
またはローカル・アクセス・プロキシのいずれかへのオ
ブジェクトの付加であり、その結果、オブジェクトは、
クライアントによって駆動されるメソッドに対して物理
的に準備が調う。

【００５８】たとえば、employee（従業員）オブジェク
トと称するオブジェクト、Employee1と、そのオブジェ
クトに対して駆動されるIncrease Salary（給料増加）
と称するメソッドがあると仮定する。また、このオブジ
ェクトの状態は永続的であり、サーバ環境に結合された
データベース内に存在すると仮定する。オブジェクト
は、従業員通し番号など、オブジェクトの主キーを表す
一意の識別を有する。具体的に言うと、主キーは、オブ
ジェクト・キーの一部であり、オブジェクト・キーに
は、所与のサーバ・インスタンスのルート・コンテナか
ら、たとえばemployeeオブジェクトなどの特定のオブジ
ェクトを管理するコンテナを介する階層経路を表す情報
の組が含まれる。一例として、employeeオブジェクトの
オブジェクト・キーは、記号的には、「ルート・コンテ
ナ／employeeホーム主キー値／employee管理オブジェク
ト主キー値」のような形になる。

【００５９】オブジェクト・キーは、図８および９に関
して下の例で説明するように、オブジェクトの活性化に
使用される。まず、クライアントは、リクエストをパッ
ケージ化する（ステップ８００）。リクエストには情
報、たとえば、Increase Salaryなどのメソッドの名前
と、メソッドのパラメータと、インタオペラブル・オブ
ジェクト・リファレンスから得られたオブジェクト・キ
ーとが含まれる。リクエストは、リモート・アクセス・
プロキシ・オブジェクトに転送され（クライアントが、
ターゲット・オブジェクトと異なるアドレス空間にある
と仮定する）、リモート・アクセス・プロキシ・オブジ
ェクトは、リクエストからオブジェクト・キーを除去
し、オブジェクト・キーおよびデータをＯＲＢを介して
サーバ・インスタンスに渡す（ステップ８０２）。サー
バ・インスタンスのＯＲＢは、オブジェクト・キーおよ
びデータを受け取る。

【００６０】サーバＯＲＢは、それに対してメソッドが
ディスパッチされる、サーバ・インスタンス内部のオブ
ジェクトを見つけるために、キーをマーシャル解除す
る。具体的に言うと、ＯＲＢは、オブジェクト・キーを
とり、ルート・コンテナに進み（ＯＲＢは、サーバ・イ
ンスタンスにハードワイヤされているので、ルート・コ
ンテナがどこにあるかを知っている）、コンテナに対し
てKeyToObjと称するメソッドを駆動する（ステップ８０
４）。ＯＲＢは、ディスパッチの対象になる実際のオブ
ジェクトを突きとめるためにこれを行う。具体的に言う
と、ＯＲＢは、オブジェクトの実際のインスタンスの仮
想メモリ・アドレスを探し、コンテナに頼って、そのア
ドレスをＯＲＢに返す。しかし、ＯＲＢに返されるアド
レスは、本発明の一態様によれば、実際のオブジェクト
ではなく、ローカル・アクセス・プロキシへのポインタ
である。

【００６１】図８の説明を続けると、ルート・コンテナ
は、オブジェクト・キーを受け取る時に、突きとめられ
るオブジェクトのオブジェクト・キーをはぎとる（ステ
ップ８０６）。この例では、employeeホーム・コンテナ
の主キー値がはぎとられ、ルート・コンテナは、そのem
ployeeホーム・コンテナがアクティブであるかどうかを
判定する（問合せ８０８）。一例では、ルート・コンテ
ナは、キー値をとり、その値についてハッシュ・テーブ
ルを探索することによって、コンテナがアクティブであ
るかどうかを判定する。値がハッシュ・テーブルに存在
する場合には、そのコンテナはアクティブである。

【００６２】コンテナが非アクティブである場合には、
そのコンテナが活性化される（ステップ８１０）。一例
では、コンテナの活性化は、管理オブジェクトの活性化
と同一の処理である。この処理は、再帰的であり、コン
テナ・ツリーのどのレベルでも行うことができる。

【００６３】ホーム・コンテナがアクティブである場合
またはそれが活性化された後に、コンテナが、それに関
連する方針のスコープ内にあるかどうかに関する次の判
定が行われる（問合せ８１２）。やはり、一例では、こ
れは、ハッシュ・テーブルに記憶された方針情報を使用
して達成される。コンテナが方針のスコープ内でない場
合には、例外が供給される（ステップ８１４）。

【００６４】しかし、コンテナがその方針のスコープ内
である場合には、別のコンテナを突きとめなければなら
ないかどうかに関する判定が行われる（問合せ８１
６）。具体的に言うと、特定のキー値に関するコンテナ
が現在処理されているコンテナであるかどうかに関する
判定が行われる。そうでない場合には、この手順は次の
層へ再帰する。具体的に言うと、オブジェクト・キーの
残りが、コンテナに転送され、KeyToObjメソッドがもう
一度駆動される（ステップ８０４）。

【００６５】問合せ８１６に戻って、この場合のemploy
eeオブジェクトを管理するのに適当なコンテナが得られ
た後に、コンテナは、このクラスのオブジェクトのため
のローカル・アクセス・プロキシを作成する（ステップ
８１８）。コンテナは、オブジェクトに関連するＤＢ２
テーブルに格納された情報によって、オブジェクトのク
ラスを知る。すなわち、コンテナは、管理オブジェクト
のクラス名、ビジネス・オブジェクトのクラス名、方針
およびローカル・アクセス・プロキシ・クラスを知って
いる。したがって、コンテナは、主キーによって識別さ
れる特定のemployeeのためのローカル・プロキシを稼動
させる。

【００６６】その後、コンテナは、ローカル・アクセス
・プロキシへのポインタを、呼出し元（この例ではルー
ト・コンテナ）に返す（ステップ８２０）。呼出し元
は、ローカル・プロキシへのポインタを受け取った後
に、図９に関連して説明するように、ローカル・プロキ
シを介して管理オブジェクトをディスパッチすることが
できる。

【００６７】まず、リクエスタは、ローカル・プロキシ
上で表されるメソッドを駆動する（ステップ８２２、図
９）。その後、ローカル・プロキシは、オブジェクトの
コンテナに問い合わせて、管理オブジェクトのアドレス
を得る（ステップ８２４）。

【００６８】その後、コンテナは、そのディスパッチン
グ方針を実施し、ディスパッチされるオブジェクトの仮
想メモリ・コピーを選択する（ステップ８２６）。この
選択は、活性化分離レベルなどに基づき、オブジェクト
の活性化をもたらす場合がある。一例では、方針は、コ
ンテナが活性化される時にコンテナ内にキャッシュ記憶
される。活性化分離方針には、たとえば、トランザクシ
ョン・レベル、セッション・レベルおよびコンテナ・レ
ベルの３つのレベルが含まれる。

【００６９】トランザクション・レベルでは、管理オブ
ジェクトの特定の仮想メモリ・イメージが、オブジェク
トにアクセスするトランザクションごとに活性化され
る。トランザクション内の、サーバ・インスタンス内で
走行する実行のスレッドのどれもが、同一の活性化され
た管理オブジェクトを共用することができる。これに
は、複数のスレッドならびに、所与のトランザクション
をスレッド上でアクティブにした、オブジェクト・リク
エスト・ブローカによって管理されるコンテキスト切替
えの結果または再開動作のいずれかとしてトランザクシ
ョン上で走行する異なるスレッドが含まれる。しかし、
トランザクションの外部で走行するスレッドは、管理オ
ブジェクトの同一の仮想メモリ・コピーを共用しない。

【００７０】セッション・レベルでは、管理オブジェク
トの特定の仮想メモリ・イメージが、オブジェクトにア
クセスするセッションごとに活性化される。セッション
内のサーバ・インスタンス内で走行する実行のスレッド
は、異なるセッション内で走行するものも含めて、オブ
ジェクトの同一の仮想メモリ・コピーを共用することが
できる。しかし、セッションの外部で走行するスレッド
は、管理オブジェクトの同一の仮想メモリ・コピーを共
用しない。

【００７１】コンテナ・レベルでは、どの時点でも、管
理オブジェクトの１つの仮想メモリ・コピーだけが、サ
ーバ・インスタンス内のコンテナ内で活性化される。そ
のコンテナ内で走行するセッションおよびトランザクシ
ョンは、管理オブジェクトの同一の仮想メモリ・コピー
を共用することができる。

【００７２】たとえば、方針によって、トランザクショ
ンごとに１つのオブジェクトが活性化されると仮定す
る。コンテナは、そのコンテナがトランザクションで分
離されることを認識し、したがって、コンテナは、それ
が走行しているトランザクションを判定する。これは、
リクエストに関連する実行スレッドについて、それを放
つトランザクショナル・コンテキストに問い合わせるこ
とによって達成される。たとえば、トランザクショナル
・コンテキストがトランザクション７であると判定され
る場合には、コンテナは、ハッシュ・テーブル（たとえ
ばＤＢ２テーブル）を参照し、オブジェクトの主キー値
をトランザクション７の情報と共に使用して、オブジェ
クトがメモリ内で活性化されているかどうかを判定す
る。トランザクション７に関するその主キー値を有する
オブジェクトがない場合には、オブジェクトが作成され
る。

【００７３】具体的に言うと、オブジェクトを一から作
成することができ、また、コンテナが、管理オブジェク
トのインスタンスを得るのに使用されるオブジェクトの
プール（たとえば、オブジェクトのホット・キャッシュ
・シェル）を有することができる。一例として、管理オ
ブジェクトのインスタンス、データ・オブジェクトおよ
び主キー・オブジェクトが取得される。

【００７４】インスタンスを得た後に、コンテナは、主
キー値をとり、その値を主キー・オブジェクトに渡す。
すなわち、主キー・オブジェクトは、それにその状態を
渡すことによって構築される。主キー・オブジェクト
は、FromStringメソッドを使用してそれ自体を初期設定
する。主キー・オブジェクトは、その後、呼出し「Inte
rnalizeFromPrimaryKey」を用いてデータ・オブジェク
トに渡される。データ・オブジェクトは、このオブジェ
クトを識別するのに必要な情報のすべてを取り出す。た
とえば、データ・オブジェクトは、主キー値を取り出
し、その結果、ＳＱＬのselectを用いてＤＢ２データベ
ースにアクセスできるようにする。

【００７５】その後、コンテナは、データ・オブジェク
トに対して、RetrieveFromDataStoreメソッドと称する
メソッドを駆動する。データ・オブジェクトは、主キー
値をとり、これが検索メソッドなのでselectステートメ
ント（たとえばＳＱＬ）に組み込み、データベースにア
クセスし、適当な行を取り出し、データを取り込み、デ
ータ・オブジェクトに配置する。これが達成された後
に、データ・オブジェクトは、そのオブジェクトが実際
に存在することを検証する。したがって、データ・オブ
ジェクトは、主キーをとり、データベースにアクセス
し、オブジェクトがそこにあることの何らかの表示をコ
ンテナに返す。

【００７６】次に、コンテナは、ビジネス・オブジェク
トに対してinitForReactivationメソッドを駆動して、
ビジネス・オブジェクトにデータ・オブジェクトを渡
す。ビジネス・オブジェクトは、最新のデータ・オブジ
ェクトを保存し、その時点で、それ自体を初期設定する
のに必要な関数を実行することができる。その後、ビジ
ネス・オブジェクトは、コンテナにリターンし、コンテ
ナは、この活性化されたオブジェクトの実際のアドレス
をローカル・アクセス・プロキシに返す。

【００７７】コンテナが、オブジェクトの仮想メモリ・
コピーを選択した後に、ローカル・プロキシは、コンテ
ナからアドレスを得た実際の管理オブジェクトにメソッ
ド・リクエストを委譲する（ステップ８２８）。管理オ
ブジェクトは、そのビジネス関数を実行し、ローカル・
プロキシにリターンする（ステップ８３０）。

【００７８】その後、ローカル・プロキシは、もう一度
コンテナに問い合わせて、コンテナがメソッド実行後の
クリーンアップを行えるようにする（ステップ８３
２）。さらに、ローカル・プロキシは、リクエスタにリ
ターンする（ステップ８３４）。

【００７９】上記に加えて、オブジェクト活性化中に、
コンテナは、オブジェクト・トランザクション・サービ
ス（ＯＴＳ）９００（図１０）に、ＯＴＳ同期化オブジ
ェクトとしてそれ自体を登録する（ＯＭＧ ＯＴＳは、
ＯＭＧのウェブ・ページ（ＷＷＷ．ＯＭＧ．ＯＲＧ）の
technical libraryから入手可能なＣＯＲＢＡサービス
仕様に記載されており、参照によってその全体を本明細
書に組み込まれる）。すなわち、コンテナは、さまざま
な情報をＯＴＳに関連するテーブルに格納する。図１０
からわかるように、ＯＴＳは、オペレーティング・シス
テム内に配置される資源回復サービス（ＲＲＳ）９０２
に結合される。コンテナは同期化オブジェクトなので、
コンテナは、「完了前」メソッドと「完了後」メソッド
をインプリメントする。したがって、一例として、トラ
ンザクションのコミットの準備ができている時に、ＯＴ
Ｓは、syncオブジェクトを使用して、コミットが発生し
ようとしている（「完了前」）ことと、それが発生した
（「完了後」）ことをオブジェクトに知らせる。

【００８０】さらに、ＯＴＳは、コミットをＲＲＳ９０
２に渡し、ＲＲＳ９０２は、サーバ・インスタンスに結
合された資源マネージャにそのコミットを駆動する責任
を負う。コミットを実行する責任を最終的に負うのは、
資源マネージャである。コミットが終了した時に、ＲＲ
Ｓは、ＯＴＳにリターンし、完了を示す。

【００８１】一実施形態では、トランザクショナル・コ
ミットの一部として、オブジェクトがパシベートされ
る。パシベーションは、活性化の反対である。パシベー
ションは、データをデータベースにプッシュし、データ
の仮想メモリ・コピーを除去する能力である。具体的に
言うと、同期化オブジェクトの完了前メソッドは、デー
タベースへのデータのプッシュを引き起こす。これによ
って、ＲＲＳが資源マネージャに２相コミット処理を開
始するように知らせる前に、更新を行うことが可能にな
る。

【００８２】パシベーションは、サーバ・インスタンス
内の仮想メモリから管理オブジェクトのイメージを除去
して、そのイメージをオブジェクト・リクエスト・ブロ
ーカまたはローカル・アクセス・プロキシから切り離す
動作である。ローカル・アクセス・プロキシを使用する
ことによって、コンテナに、オブジェクトへのさまざま
なポインタを追跡しなけれならないのではなく、適当な
方針に基づいてオブジェクトをパシベートする能力が与
えられる。コンテナは、オブジェクトをパシベートする
と決定した時に、そのオブジェクトのデータを、ＤＢ２
などの資源マネージャにプッシュする。管理オブジェク
トは、uninitForPassivationメソッドまたはuninitForD
eletionメソッドを介してパシベーションについて通知
される。管理オブジェクトの削除は、オブジェクトが形
式的に削除される前のパシベーションの動作を暗示す
る。パシベーションは、パシベーション自体の動作に関
連しない異なる理由のために、異なる時にトリガするこ
とができる。コンテナ自体以外のバッキング資源マネー
ジャを有しない一時的なオブジェクトの場合には、パシ
ベーションは、管理オブジェクトの削除を暗示する。

【００８３】パシベーションに関連する管理方針は、パ
シベーション方針と呼ばれ、これには、たとえば、ピン
止め（pinned）、セッションの寿命にわたるピン止め、
トランザクションの寿命にわたるピン止め、非ピン止め
の４つのオプションが含まれる。

【００８４】ピン止めは、管理オブジェクトが絶対にパ
シベートされないことを示す。管理オブジェクトが、ク
ライアントによって駆動されるメソッド・ディスパッチ
から使用不能になるようにするためには、管理オブジェ
クトを削除する（すなわち除去する）。一時的なオブジ
ェクトは、通常はピン止めされるが、この方針は、永続
的なオブジェクト（たとえば、そのデータが支援記憶装
置に格納されるオブジェクト）にも適用することができ
る。コンテナは、オブジェクトが削除されたので管理オ
ブジェクトのリフレッシュが失敗した場合に、活性化さ
れたオブジェクトを仮想メモリから除去することができ
る。これは、租にコヒーレントなシステムで、クライア
ント・アプリケーションが、現行以外の複製されたサー
バ領域内の管理オブジェクトを削除した時に発生する可
能性がある。

【００８５】セッションの寿命にわたるピン止めは、管
理オブジェクトが、それに関連付けられたセッションが
ない時に、サーバ・インスタンス内でパシベートされる
ことを示す。実行のスレッドからのセッション中断は、
セッションと管理オブジェクトの関連付けの解除をもた
らさないことに留意されたい。セッションの関連付け
は、管理オブジェクトを変更する所与のセッション内で
走行する実行のスレッドからもたらされる動作である。
この関連付けは、セッションの寿命にわたって存続す
る。

【００８６】トランザクションの寿命にわたるピン止め
は、管理オブジェクトが、それに関連付けられたトラン
ザクションがない時に、サーバ・インスタンス内でパシ
ベートされることを示す。実行のスレッドからのトラン
ザクション中断は、トランザクションとアクティブな管
理オブジェクトの関連付けの解除をもたらさないことに
留意されたい。トランザクションの関連付けは、管理オ
ブジェクトを変更する所与のトランザクション内で走行
する実行のスレッドからもたらされる動作である。この
関連付けは、トランザクションの寿命にわたって存続す
る。

【００８７】非ピン止めは、管理オブジェクトが、コン
テナの自由裁量で、トランザクションの終りの前にいつ
でもパシベートされる可能性があることを示す。さら
に、管理オブジェクトは、その管理オブジェクトにトラ
ンザクションが関連付けられていない時にパシベートさ
れる。

【００８８】一例では、管理オブジェクトをパシベート
する前に、管理オブジェクトの変更された本質的な状態
をバッキング資源マネージャにプッシュするために、オ
ブジェクトがフラッシュされる。一例では、ビジネス・
オブジェクトの本質的な状態が、データ・オブジェクト
内で保たれ、本質的な状態へのアクセスは、データ・オ
ブジェクトに委譲される。これを、委譲パターンと称す
る。このパターンは、managedObjectWithDataObjectイ
ンターフェースの継承を介して指定される。このパター
ンを用いて、本質的な状態が、データ・オブジェクトに
対する更新動作の実行を介してプッシュされる。

【００８９】しかし、もう１つの例では、ビジネス・オ
ブジェクトの本質的な状態は、データ・オブジェクトで
はなくビジネス・オブジェクト内に常駐する。これを、
キャッシング・パターンと称する。このパターンは、ビ
ジネス・オブジェクトがmanagedObjectWithCachedDataO
bjectインターフェースを継承する場合に指定される。
この場合、データ・オブジェクト更新動作を駆動する直
前に、syncToDataobjectメソッドが管理オブジェクトに
対して駆動される。具体的に言うと、syncToDataobject
メソッドは、資源マネージャにさらにデータをプッシュ
するためにデータ・オブジェクトに対するメソッドが駆
動される前に、ビジネス・オブジェクトにそのキャッシ
ュ記憶された状態をデータ・オブジェクトへプッシュさ
せるために、コンテナによって駆動される。

【００９０】上記に加えて、管理オブジェクトは、パシ
ベーションと独立に、パシベーションの前に、複数回フ
ラッシュされる可能性がある。もう１つの例として、管
理オブジェクトは、管理オブジェクトが、チェックポイ
ント化されるセッションと関連する場合に、セッション
・チェックポイント動作の結果としてフラッシュされ
る。

【００９１】他の明示的なフラッシュ方針オプションを
設けることもできる。たとえば、ある方針オプションに
よって、トランザクションの終りにフラッシュを実行し
なければならないことが示される。この方針を用いる
と、データ・オブジェクト更新動作と、それに対応する
syncToDatastore動作が、管理オブジェクトに関連して
いた登録されたトランザクションの終りをコンテナが認
識するたびに駆動される。トランザクション方針の終り
は、管理オブジェクトの同一の共用される仮想メモリ・
コピーに対して複数のトランザクションが並列に走行す
ることを許可する活性化分離方針の下でインスタンスが
活性化された場合であっても、インスタンスにアクセス
するトランザクションのそれぞれに適用される。したが
って、単一の活性化された管理オブジェクトが、めいめ
いの方針オプションの下で複数の並列トランザクション
内で複数回フラッシュされる可能性がある。

【００９２】もう１つの例として、明示的なフラッシュ
方針が定義されない。そうである場合には、フラッシュ
動作は、パシベーションの時に、セッション・チェック
ポイント動作の結果として実行される。

【００９３】管理オブジェクトは、リフレッシュするこ
ともできる。管理オブジェクトのリフレッシュは、管理
オブジェクトに関連するデータ・オブジェクトに対する
検索動作の実行から生じる論理動作である。検索動作
は、管理オブジェクトの識別に基づき、管理オブジェク
トの主キー値によって表される、バッキング資源マネー
ジャでの管理オブジェクトの本質的な状態の存在を最小
限保証する責任を有する。さらに、検索メソッドは、関
連するバッキング資源マネージャから、管理オブジェク
トの本質的な状態の一部またはすべてを得ることができ
る。キャッシュ記憶される管理オブジェクト（すなわ
ち、キャッシュ記憶されるデータ・オブジェクトを有す
る管理オブジェクト）の場合、syncfromDataobject動作
も、検索動作がデータ・オブジェクトに対して駆動され
た後に、リフレッシュ中に管理オブジェクトに対して駆
動される。syncfromDataobjectメソッドは、syncToData
objectメソッドの反対である。syncfromDataobjectメソ
ッドは、データ・オブジェクトからキャッシュ記憶され
た本質的な状態を取り出すようにビジネス・オブジェク
トに要求するためにコンテナによって駆動される。

【００９４】管理オブジェクトは、活性化される処理の
一部としてリフレッシュされる。さらに、管理オブジェ
クトを、活性化された状態である間にリフレッシュする
ことができ、パシベートの前に複数回リフレッシュする
ことができる。一例として、管理オブジェクトは、リセ
ットされるセッションに関連する場合に、セッション・
リセット動作の一部としてリフレッシュされる。

【００９５】上記に加えて、明示的なリフレッシュ方針
オプションを設けることができる。このオプションに
は、たとえば、トランザクション認識時のリフレッシ
ュ、セッション認識時のリフレッシュおよび方針なしが
含まれる。トランザクション認識時には、データ・オブ
ジェクト検索動作およびそれに対応するsyncFromDatast
ore動作が、オブジェクトを変更する実行のスレッドで
コンテナが新しいトランザクションを認識するたびに駆
動される。

【００９６】セッション認識時には、データ・オブジェ
クト検索動作およびそれに対応するsyncFromDatastore
動作が、オブジェクトを変更する実行のスレッドでコン
テナが新しいセッションを認識するたびに駆動される。
リフレッシュ方針は、管理オブジェクトの同一の共用仮
想メモリ・コピーに対して複数のトランザクションまた
はセッションが並列に走行することを許容する活性化分
離方針の下でオブジェクト・インスタンスが活性化され
た場合であっても適用される。したがって、単一の活性
化された管理オブジェクトが、それぞれの方針オプショ
ンの下で複数の並列のトランザクションおよびセッショ
ン内で複数回リフレッシュされる可能性がある。

【００９７】リフレッシュに関して明示的な方針が定義
されていない時には、リフレッシュは、活性化の時に行
われる。

【００９８】一実施形態では、方針を定義するか方針と
コンテナを関連付けるために、コンポーネント・ブロー
カ実行時サービスによって供給されるシステム管理アプ
リケーションが使用される。このアプリケーションは、
たとえば、コンテナのために選択できる方針のリストを
提供し、適当な方針を選択できるようにする。指定され
たコンテナについて選択された方針は、その後、システ
ム管理リポジトリ（たとえばＤＢ２データベース）に格
納される。

【００９９】サーバ・インスタンス内のオブジェクトの
アクティブなメモリ内インスタンスは、コンテナ１００
０（図１１）によって管理される。コンテナの責任の１
つが、永続性機構を提供し、その結果、記憶装置内オブ
ジェクト１００２に、データベースなどの外部データ・
ソース１００４から本質的な状態に移行し、その後、デ
ータベースに格納し、オブジェクトに対するすべての変
更が永続的になるようにすることである。しかし、しば
しば、オブジェクトを永続的にするために設けられる機
構は、オブジェクトの本質的な状態のロックまたは直列
化のための機構である並列性制御などの、関連する他の
機能要件が伴い、その結果、オブジェクトの内容が、ト
ランザクション、セキュリティを提供するアクセス制
御、変更をコミットまたはロール・バックする時を制御
するトランザクショナル作業単位の下でのコミット制御
などの所与の活動単位のコンテキスト内で安定し、観察
可能になる。さらに、エンタープライズ・クラス・デー
タ・システムの場合、データベース内のデータの使用
が、それを使用するオブジェクトだけの排他的なもので
ないことがしばしばである。多くの場合に、同一のデー
タが、さまざまな種類のアプリケーションによって並列
に使用され、これらのアプリケーションのうちの一部
は、ＣＩＣＳまたはＩＭＳ（International Business M
achines Corporationが提供する）など、オブジェクト
・サーバ・インスタンスまたはシステムのスコープおよ
び管理の範囲の外にある、より伝統的な種類の環境で実
行される。このデータは、通常は、さまざまな種類の方
針を介して制御され、これらの方針は、データへのアク
セス（すなわちセキュリティ）の制御、複数のユーザお
よびシステムにまたがるデータの共用、データの並列性
制御およびデータのトランザクショナル回復を制御す
る。

【０１００】従来、コンテナは、永続的なオブジェクト
がオブジェクト・サーバ・インスタンス内に存在し、単
にデータ・ベース内に存在するデータから構成されると
いう前提に基づいて、オブジェクト・サーバ・インスタ
ンス内で作成される。この見方を採用する時には、オブ
ジェクト・サーバ・インスタンスは、上で説明した種類
の方針をホストし、実行する責任を引き受ける。たとえ
ば、通常のオブジェクト・サーバ・インプリメンテーシ
ョンは、オブジェクト・サーバ・インスタンス内でのオ
ブジェクトの並列性制御を実行するためにロッキング・
サービスを提供する。オブジェクト・サーバ・インスタ
ンスは、オブジェクトのアクセス制御に関する同様の責
任を引き受ける。しかし、この手法に関連する複数の問
題が存在する。その問題の一部を、下に列挙する。 １）スケーラブルなロック・マネージャの作成が、複雑
でエラーが生じやすい。 ２）スケーラブルなマルチシステム・ロック・マネージ
ャの作成が、さらに複雑でエラーが生じやすい。 ３）オブジェクトの移行に使用されるデータが、システ
ム内で他の目的にも使用されるので、オブジェクト・サ
ーバ・ドメイン内で行われるロッキング機能を、データ
ベース管理ドメイン内で行われれるロッキングと調和さ
せなければならない。 ４）多くの場合に、オブジェクト・サーバ・ドメイン内
に常駐するアクセス制御方針が、データ管理ドメイン内
のアクセス制御方針の複製であり、実行時の性能低下
と、顧客のシステム管理コストが増える。 ５）回復可能な資源マネージャの作成が、複雑でエラー
が生じやすい。これをサポートするのに必要なトランザ
クショナル・ログ記録を含む、この機能をオブジェクト
・サーバ内で提供することは、いずれにせよデータ管理
ドメインで必要な機能の重複になることがしばしばであ
る。 ６）オブジェクト・サーバ・ドメインでのトランザクシ
ョン境界にまたがるオブジェクト状態の効率的なキャッ
シュ記憶を提供するために、データ管理ドメインで提供
されるキャッシュ記憶方針との調和が必要である。さら
に、クラスタ化システム構成の場合には、キャッシュ記
憶を、複数のシステムにまたがって調和させなければな
らない。

【０１０１】上の問題を排除するために、インスタンス
管理のさまざまな態様が、コンテナ１０００から、Inte
rnational Business Machines Corporation（米国ニュ
ーヨーク州アーモンク）が提供するＤＢ２などの１つま
たは複数の下層の資源マネージャ１００６に委譲され
る。具体的に言うと、ロッキング（たとえば並列性制
御）、アクセス制御、複数のシステムにまたがるキャッ
シング（たとえばマルチシステム・キャッシング）およ
びコミット制御の責任が、下層のデータ・マネージャに
委譲される。したがって、オブジェクト・サーバ・イン
スタンスは、もはや、オブジェクトのホームとはみなさ
れず、永続的なオブジェクトのための一時的なディスパ
ッチ空間とみなされ、この永続的なオブジェクトは、デ
ータベース内の永続的なホームからオブジェクト・サー
バ・インスタンスにステージングまたはキャッシュ記憶
される。

【０１０２】したがって、オブジェクトの１つまたは複
数の属性（たとえば、employeeオブジェクトの場合、属
性には氏名、給与、部署などが含まれる）を取得し、そ
の結果、オブジェクト・サーバ・インスタンス仮想メモ
リ内でディスパッチのために合成／ステージングできる
ようにするために、オブジェクト・サーバ・インスタン
スによってリクエストが作られる時には、コンテナでは
なく資源マネージャが、属性を得るのに必要なロッキン
グ、マルチシステム・キャッシング、アクセス制御およ
びコミット制御を実行または管理する。これが、たとえ
ばトランザクションごとに仮想メモリ内のステージング
されたオブジェクトの別々のコピーを提供するインスタ
ンス管理方針と組み合わされて、オブジェクト・サーバ
・インスタンス内で並列性制御を提供する必要がなくな
る。というのは、ロッキングが、通常は資源（またはデ
ータ・）マネージャ内のトランザクション境界で管理さ
れるからである。

【０１０３】オブジェクトは、オブジェクトの属性のそ
れぞれについて下層の資源マネージャ内で保持されるす
べてのロックを介して効率的に直列化される。さらに、
資源マネージャ・ドメイン内で保持されるロックは、ク
ラスタ化構成の複数のシステムにまたがる並列性制御を
提供している。このロックを用いて、資源マネージャ
は、他のリクエスト（他のオブジェクトサーバか、ＣＩ
ＣＳまたはＩＭＳなどの従来のトランザクション環境の
いずれかからの）がデータについて行われる際に、リア
ル・タイムでロックの互換性状態をネゴシエートするこ
ともできるようになる。

【０１０４】責任の同一の配置が、セキュリティに関し
て存在する。所与のユーザによる使用のために仮想メモ
リ内でオブジェクトを作成するためにオブジェクト・サ
ーバ・インスタンスからリクエストが行われるので、ア
クセス制御は、下層の資源マネージャによって提供され
る。責任の同一の配置が、データ・キャッシングおよび
回復可能なコミットメント制御に関して存在する。オブ
ジェクト・サーバ・インスタンスが、資源の回復および
ログ記録を提供する必要はない。というのは、その機能
が、下層の資源マネージャにプッシュ・ダウンされてい
るからである。キャッシングに関して、オブジェクト・
サーバ・インスタンスは、状態が下層の資源マネージャ
内で無効になる可能性がある点を超えて仮想メモリ内で
状態を保持する責任を負わない。この扱いは、オブジェ
クト・サーバ・インスタンスの特定の方針の指定を介し
てのみオーバーライドされる。この手法のもう１つの長
所は、下層の資源マネージャで提供される進行中の改良
および機能拡張のすべてが、オブジェクト・サーバ・イ
ンスタンス内で即座に透過的に影響を及ぼすことであ
る。

【０１０５】インスタンス管理のさまざまな態様を、コ
ンテナから資源マネージャに委譲するために、特定のコ
ンテキストをオブジェクト空間内に設け、その結果、そ
れらのコンテキストを、資源マネージャへのアクセスに
使用されるインターフェース上で提供できるようにす
る。一例として、実行のスレッド上で特定のコンテキス
トをセット・アップし、これによって、コンテナ自体に
責任をインプリメントさせるのではなく、資源マネージ
ャに管理責任をプッシュするのは、オブジェクト・リク
エスト・ブローカである。これを、図１２に関して下で
さらに詳細に説明する。

【０１０６】一例として、ＯＲＢ１１００が、所与の実
行のスレッド１１０２でメソッドをディスパッチする責
任を負う。拡張によって、ＯＲＢは、その実行のスレッ
ドの拡張コンテキスト１１０４のセットアップの責任を
（少なくとも最初は）負う。この拡張コンテキストに
は、たとえば、以下が含まれる。 １）実行されるトランザクションを識別し、その中で１
つの作業が完了する、トランザクショナル・コンテキス
ト。このコンテキストは、トランザクショナル作業単位
によって表され、識別と状態を関連付けられている。ト
ランザクショナル・コンテキストに実行のスレッドを関
連付けることによって、その実行のスレッド上で走行す
るすべてのものが、それがそのトランザクションのコン
テキストの内部にいることを知る。 ２）ある原理またはあるユーザを表し、実行のスレッド
に関連する証明書の組を提供するセキュリティ・コンテ
キスト。これによって、この作業を要求している原理ま
たはユーザの表示がもたらされる。 ３）その実行のスレッドの作業負荷管理に関連する、性
能管理コンテキスト。これによって、最高の性能を達成
するために資源を割り振るのに使用される方針が記述さ
れる。

【０１０７】一実施形態では、ＯＲＢが、コンテキスト
・サービスと称する、ＯＳ／３９０またはＭＶＳのサー
ビスの組を使用することによって、異なるコンテキスト
を付加する（たとえば、トランザクション、作業負荷管
理およびセキュリティ）。具体的に言うと、作業コンテ
キストと称する制御ブロックが、コンテキスト・サービ
スによって提供される。たとえば、ＯＲＢがコンテキス
トに現行の実行のスレッドを関連付けられるようにする
アプリケーション・プログラミング・インターフェース
の組が使用される。この関連付けを、コンテキスト切替
えと称し、これによって、コンテキストをスレッドに切
り替えるか、スレッドからコンテキストを切り替えるこ
とができる。コンテキストの内部に正しい識別、タグ、
名前または、そのコンテキストを表すのに必要なものを
セットするのは、個々の作業マネージャ（この例ではＯ
ＲＢ）の義務である。その後、作業単位（実行のスレッ
ド）が異なる環境にまたがって流れる際に、資源マネー
ジャが、作業コンテキストにアクセスしてデータを見つ
け、そのデータが、コンテキスト内の設計された位置に
配置される。コンテキスト・サービスは、それぞれ参照
によってその全体を本明細書に組み込まれる、「OS/390
MVS Planning: Workload Management」、IBM Pub. No.
GC28-1761-07（1999年3月）、「OS/390 MVS Programmi
ng: WorkloadManagement Services」、IBM Pub. No. GC
28-1773-06（1999年3月）、および「OS/390 V2R5.0 MVS
Programming: Resource Recovery」、IBM Publication
No.GC28-1739-02（1998年1月）でさらに説明されてい
る。

【０１０８】当初はＯＲＢがコンテキストをセット・ア
ップするが、コンテナは、すべてのメソッドのディスパ
ッチ経路上にあるので、コンテナが、コンテナの追加方
針に基づいてこれらのコンテキストを変更または操作で
きるようにすることが可能である。一例として、コンテ
ナは、あるトランザクション（たとえばトランザクショ
ン１）から新しいトランザクション（たとえばトランザ
クション２）に切り替えることができる。

【０１０９】一例では、コンテナが、ある機能（たとえ
ばコミットの準備、コミット、ロッキング、ログ記録な
ど）を実行する責任を１つまたは複数の資源マネージャ
に委譲するために、資源マネージャも、トランザクショ
ナル・コンテキストを知っていなければならない。これ
を達成する形を、下で説明する。

【０１１０】一例では、コンテナが初期設定される時
（initForReactivation）に、コンテナが、コンテナ１
１０６を資源マネージャ１１１０と結合するのに使用さ
れる接続オブジェクト１１０８を初期設定する。具体的
に言うと、接続オブジェクトは、特定の版の資源マネー
ジャ・アタッチメント１１１２、たとえばＲＲＳＡＦと
称するＤＢ２アタッチメントを有するＤＬＬとリンクさ
れている。したがって、コンテナが初期設定されつつあ
る時に、コンテナは、接続オブジェクトを初期設定し、
この接続オブジェクトに対して初期設定メソッドを駆動
する。接続オブジェクトは、システムの管理リポジトリ
に付加され、この管理リポジトリは、どの資源がこのコ
ンテナに付加されるかを示す。この例では、コンテナ１
１０６は、ＸＹＺと称する特定のＤＢ２サブシステムに
付加される。

【０１１１】一実施形態では、ＤＢ２へのコンテナの付
加が、「Identify」と称するＡＰＩを使用して実行され
る。したがって、接続オブジェクトは、ＤＢ２が供給す
るコード片「Identify」を呼び出す。ＤＢ２は、この呼
出しを受け取り、それがＲＲＳＡＦパッケージ上の識別
子であると判定する。したがって、ＤＢ２は、ＲＲＳＡ
Ｆ制御構造１１１４を、この例では実行のスレッド１１
０２上でセット・アップする。

【０１１２】Identifyプロトコルを用いて、ＤＢ２は、
どの特定のスレッドがＤＢ２と通信しようとしているか
を知る。したがって、実行のスレッドに出会った時に、
ＤＢ２は、そのスレッドをテーブル索引し、そのスレッ
ドのためにそのコンテキストに移動し、それがどのトラ
ンザクションの中にあるかを見つける。その点で、ＤＢ
２は、コンテナに類似の形で動作する。

【０１１３】ＤＢ２は、ＲＲＳＡＦを介する付加によっ
て、ＤＢ２が特殊な出口を有することも知っている。Ｄ
Ｂ２は、トランザクションを追跡している資源回復サー
ビス１１１６（ＲＲＳＡＦはこのサービスの一部であ
る）を使用して、このトランザクションへの関係を登録
する。

【０１１４】上記に加えて、ＲＲＳに結合されたオブジ
ェクト・トランザクション・サービス（ＯＴＳ）１１１
８も、その責任をＲＲＳに委譲する。ＯＴＳは、ＲＲＳ
インターフェースの組（たとえば、準備、コミット、ロ
グ・データ書込などのインターフェース）を介してＲＲ
Ｓに責任を委譲する。したがって、本発明の一態様によ
れば、資源マネージャを介するある方向（軸）と、下層
のオペレーティング・システムへのもう１つの方向
（軸）への責任の委譲がある。

【０１１５】分散オブジェクト・サーバ・インスタンス
１２００（図１３）内では、管理オブジェクトまたはビ
ジネス・オブジェクト１２０２が、永続的であることが
しばしばである。すなわち、これらのオブジェクトは、
１つまたは複数のデータベース１２０４に常駐するデー
タから構成される。ＤＢ２、ＩＭＳおよびＣＩＣＳ（す
べて米国ニューヨーク州アーモンクのInternational Bu
siness Machines Corporationが提供する）などのさま
ざまなデータ・ソースならびにさまざまな他のデータ・
ソースが存在するレガシー環境では、これらの資源マネ
ージャからデータを抽出し、そのデータを使用して永続
的なオブジェクトにその本質的な状態を供給する必要が
ある。

【０１１６】この構成を達成するため、また、オブジェ
クトの移行に使用されるデータの特定の位置およびスキ
ーマを隠蔽するために、少なくとも１つのコンテナ１２
０６と少なくとも１つのデータ・オブジェクト１２０８
が使用される。コンテナは、オブジェクト・サーバ・イ
ンスタンスから資源マネージャ１２１０への付加を容易
にし、その結果、資源マネージャ１２１０によって管理
されるデータベース１２０４からの資源を、オブジェク
トの移行に使用できるようにする。オブジェクト内の特
定の状態のデータベース内の特定の行またはレコードへ
のマッピングは、データ・オブジェクト１２０８内で実
行される。データ・オブジェクトは、オブジェクト・サ
ーバ・インスタンス実行時内のヘルパ・オブジェクトで
あって、ビジネス・オブジェクトの永続的な状態の管理
を支援し、コンテナによって管理される付加を介するビ
ジネス・オブジェクトとデータベースとの間のデータの
移動を容易にする。

【０１１７】通常、コンテナとデータ・オブジェクト
は、付加および相互作用を正確に１つの種類の資源マネ
ージャに制限する制約を用いて作成される。この手法に
伴う問題は、多くの場合に、複数の異なる種類のバック
エンド資源のためにビジネス・オブジェクトを合成する
必要があることである。たとえば、型「employee」の特
定のビジネス・オブジェクトが、従業員通し番号および
氏名をＤＢ２から取得するが、給与属性をＶＳＡＭレコ
ードまたは既存のＩＭＳトランザクション・プログラム
から取得する場合がある。この場合には、通常の解決策
には、それぞれが別々のコンテナによって管理される複
数のビジネス・オブジェクトを介してアプリケーション
内で合成を実行するか、それぞれが別々のコンテナによ
って管理され、それぞれがその独自の従属データ・オブ
ジェクトに関連する複数の他のビジネス・オブジェクト
に機能を委譲することによって合成データ・オブジェク
トを作成することによるのいずれかが含まれる。

【０１１８】この手法は、複数のコンテナを介して複数
のオブジェクトをディスパッチする追加の経路のゆえの
みならず、追加のオブジェクトを保持するのに使用され
る追加のメモリに関しても、性能低下につながる。アプ
リケーションに合成を処理させる場合の最悪の場合に
は、アプリケーション開発者が、特定のデータ型、位
置、スキーマおよび合成を意識するようになり、これに
よって、ビジネス・オブジェクト自体の移植性および再
利用が危険にさらされる形でアプリケーションの設計が
制約される。さらに、複数のコンテナを使用する必要が
生じるので、そうでなければ回避できるはずのシステム
管理の重荷が生じる。また、複数のデータ・オブジェク
トの作成に使用される開発プロセスおよびこれらのオブ
ジェクトを互いにパッケージ化して単一のビジネス・オ
ブジェクトのためのサポートを形成するプロセスが、無
用に複雑で高コストになる。

【０１１９】したがって、本発明の一態様によれば、合
成されたコンテナおよび合成されたデータ・オブジェク
トが導入される。合成されたコンテナ１２２０（図１
４）は、その中で複数の異なる資源マネージャ１２２２
を構成し、駆動することができる合成されたコンテナで
ある。合成されたコンテナは、単一のビジネス・オブジ
ェクト１２２４の合成をサポートするのに必要であるか
所望される資源マネージャのすべてへの複数の付加およ
び接続を管理する。対応するデータ・オブジェクト１２
２６も合成され、ビジネス・オブジェクトにその本質的
な状態を供給するのに必要であるか所望されるさまざま
なバックエンド資源へのさまざまなリクエスト・レベル
の相互作用をサポートする。この手法では、コンテナの
インストールおよび構成が簡略化され、単一のデータ・
オブジェクト内でリクエスト・レベルの相互作用が簡略
化され、合併され、複数のコンテナにまたがる複数の別
々のディスパッチが排除されるので経路長が改善され、
インプリメントされるアプリケーション・モデルでの実
行時オブジェクトのより明瞭かつ直接のマッピングがア
プリケーション開発者に与えられる。

【０１２０】一実施形態では、合成されたコンテナ１２
２０は、複数の接続オブジェクト１２２８を使用してイ
ンプリメントされる。接続オブジェクト１２２８のそれ
ぞれは、資源マネージャ１２２２に関連し、結合され
る。たとえば、ある接続オブジェクトは、資源マネージ
ャ１（たとえばＤＢ２）に関連し、もう１つの接続オブ
ジェクトは、資源マネージャＮ（たとえばＩＭＳ）に関
連する。

【０１２１】一実施形態では、接続オブジェクト１２２
８は、たとえばコンポーネント・ブローカ実行時サービ
スによって提供されるユーザ・インターフェースを使用
して作成される接続仕様を使用して定義される。システ
ム管理者は、一例として、コンテナに接続される資源マ
ネージャごとに接続仕様を定義する。接続仕様では、資
源マネージャへの接続に必要な情報の組が識別される。
たとえば、ＤＢ２の場合には、ＤＢ２サブシステム名が
含まれる。

【０１２２】接続仕様が定義される時には、接続仕様
は、種類（たとえばＤＢ２接続）を有し、使用される接
続オブジェクト・クラスを有する。さらに、特定の型の
接続のために、接続仕様には、コンテナがバックエンド
資源に付加または接続するために必要なすべての情報が
含まれる。接続仕様および関連情報は、サーバ・インス
タンスに結合されたシステム管理リポジトリなどのデー
タベースに格納される。システム管理リポジトリには、
コンテナに関連する情報も含まれる。

【０１２３】コンテナが初期設定される（たとえばinit
ForReactivation）時には、コンテナに、１つまたは複
数の接続仕様のリストが供給される。コンテナは、この
リストから、そのコンテナに接続される資源マネージャ
を表す接続仕様を選択する。その後、選択された接続オ
ブジェクトごとに、コンテナは、その接続仕様に関する
情報をシステム管理リポジトリから取り出す。この情報
には、各接続仕様の接続オブジェクト・クラス名が含ま
れる。一例として、クラス名と、接続に必要な特定の情
報とが、ストリーム・フォーマットでコンテナに渡され
る。コンテナは、接続オブジェクト・クラス名を使用し
て接続オブジェクトを作成し、コンテナが資源マネージ
ャ（たとえばＤＢ２）に付加できるように、データを用
いて接続オブジェクトを初期設定する。

【０１２４】初期設定中に、コンテナは、接続オブジェ
クトに対して「init」メソッドを駆動する。「init」中
に、接続オブジェクトは、ＤＢ２ ＲＲＳＡＦアタッチ
メント（すなわち、この接続オブジェクトにリンクされ
たライブラリ・コード片）を使用して、資源マネージャ
に接続する。たとえば、接続オブジェクトは、ＤＢ２サ
ブシステム名を使用して、ＤＢ２資源マネージャに接続
する。接続オブジェクトの特定のインプリメンテーショ
ンは、各資源マネージャによって供給される。

【０１２５】一実施形態では、各接続オブジェクト・ク
ラスが、特定の種類の資源マネージャのためにハードワ
イヤされる。各接続オブジェクトは、インプリメントさ
れなければならない複数のインターフェースを有し、こ
れには、付加された資源マネージャが、サーバ・アドレ
ス空間を資源マネージャ・アドレス空間に付加するのに
必要なすべての処理を実行する初期設定と、接続オブジ
ェクトが、特定の所与のトランザクションの下で作業を
実行するためのコンテキストをセット・アップするのに
必要なすべての処理を実行する責任を負う（たとえば、
ＤＢ２では、現行のトランザクショナル作業単位に直接
に束縛される論理ＤＢ２実行のスレッドを作成する必要
がある場合がある）トランザクション識別、めいめいの
イベントのクリーンアップ処理を実行するのに使用され
る初期設定解除およびトランザクション識別解除が含ま
れる。

【０１２６】一実施形態では、コンテナが、初めてトラ
ンザクションを見た時に、同期オブジェクトをＯＴＳに
登録し、各接続オブジェクトに、トランザクションが識
別されることを知らせる。付加の種類に応じて、その接
続オブジェクトは、処置を実行する場合としない場合が
ある。たとえば、ＤＢ２の場合、接続オブジェクトは、
スレッドのＤＢ２表現を作成し、ユーザをサイン・オン
させ、その結果、ＤＢ２がユーザについて知るようにす
る。具体的に言うと、接続オブジェクト内では、トラン
ザクションが識別され、ＤＢ２が、スレッドを作成し、
その構造のうちの１つをＲＲＳコンテキストにアンカす
る。したがって、データ・オブジェクトがＤＢ２にアク
セスする時には、そのデータ・オブジェクトは、コンテ
キストからそれ自体のデータをプルする。

【０１２７】上記に加えて、１つまたは複数の合成され
たデータ・オブジェクト１２２６も提供される。具体的
に言うと、合成されたデータ・オブジェクトのそれぞれ
は、複数の異なる資源を理解するように作られる。すな
わち、データ・オブジェクトには、たとえば、ＳＱＬス
テートメントならびにＣＩＣＳおよびＩＭＳの呼出しを
含めることができ、また、データ・オブジェクトは、た
とえば特定のＤＢ２サブ・データ・オブジェクトに委譲
することができる。

【０１２８】一実施形態では、合成されたデータ・オブ
ジェクトを作成するために、コンテナによって初期設定
メソッドが駆動される。この初期設定中に、コンテナ・
オブジェクトによって作成される１つまたは複数のリク
エスト・ヘルパ・オブジェクトが、データ・オブジェク
トに渡される。各リクエスト・ヘルパ・オブジェクトに
は、特定の資源マネージャに対するリクエストを支援す
るためにデータ・オブジェクトが必要とする可能性があ
る情報が格納される。したがって、コンテナは、ヘルパ
・オブジェクトのリストをデータ・オブジェクトに渡
し、データ・オブジェクトは、必要なヘルパ・オブジェ
クト（たとえばＤＢ２用、ＣＩＣＳ用、ＩＭＳ用など）
を選択する。ヘルパ・オブジェクト内には、適当な接続
仕様の名前がある。

【０１２９】上で詳細に説明したものは、サーバ・イン
スタンス内に配置されるオブジェクトの管理に使用され
るサーバ・インスタンスである。本発明の一態様では、
サーバ・インスタンスは、同一のシステム・イメージ上
または複数のシステム・イメージにまたがってのいずれ
かで複製することができる。複数のシステム・イメージ
にまたがって複製されるサーバ・インスタンスの一例
を、図１５に関して説明する。

【０１３０】図１５に示されているのは、結合機構１３
０２を介して互いに結合されて、クラスタ化シスプレッ
クス構成を形成する２つのサーバ・システム、システム
１（１３００ａ）およびシステム２（１３００ｂ）であ
る。結合機構１３０２（別名、構造化外部記憶（ＳＥ
Ｓ）プロセッサ）は、システムによってアクセス可能な
記憶装置を含み、システム内のプログラムによって要求
される動作を実行する。結合機構の動作の諸態様は、米
国特許第５３１７７３９号明細書、米国特許第５５６１
８０９号明細書、米国特許第５７０６４３２号明細書お
よび本明細書に記載の発明および応用例などの文献に詳
細に記載されており、これらのすべてが、参照によって
その全体を本明細書に組み込まれる。

【０１３１】各システムは、それぞれ、International
Business Machines Corporation（米国ニューヨーク州
アーモンク）が提供するＯＳ／３９０またはＭＶＳオペ
レーティング・システムなどのオペレーティング・シス
テム１３０４ａおよび１３０４ｂを実行している。一例
として、オペレーティング・システム１３０４ａは、１
つまたは複数のサーバ・インスタンス１３０６ａの実行
を制御し、これらのサーバ・インスタンス１３０６ａ
は、システムにまたがってサーバ１３０６ｂとして複製
される。たとえば、システム１のサーバ１は、システム
２にサーバ１として複製される。

【０１３２】さらに、各オペレーティング・システム
は、それぞれ、作業負荷マネージャ１３０８ａまたは１
３０８ｂを含むかこれに結合される。各作業負荷マネー
ジャは、最適の負荷平衡化およびシステム性能を達成す
るために、シスプレックスのシステムの間で作業負荷を
平衡化する。作業負荷マネージャの一例が、それぞれ参
照によってその全体を本明細書に組み込まれる、「OS/3
90 MVS Planning: Workload Management」、IBM Pub. N
o. GC28-1761-07（1999年3月）および「OS/390 MVS Pro
gramming: Workload Management Services」、IBM Pub.
No. GC28-1773-06（1999年3月）に記載されている。

【０１３３】さらに、各オペレーティング・システム・
イメージには、それぞれ、１つまたは複数の資源マネー
ジャ１３１０ａおよび１３１０ｂが結合される。各資源
マネージャは、上で説明したように、そのマネージャに
関連するデータを所有し、制御する。

【０１３４】１つまたは複数のクライアント１３１２
が、たとえばＴＣＰ／ＩＰ接続を介して、サーバ・イン
スタンスにリクエストを送る。

【０１３５】タスクを実行するために適当なサーバ・イ
ンスタンスを選択するために、そのサーバ・インスタン
スが所与のシステム内またはシスプレックス内のシステ
ム間で複製される時に、１つまたは複数のデーモンが、
本発明の一態様に従って使用される。一実施形態では、
デーモン１３１４ａおよび１３１４ｂ（図１６）が、そ
れぞれ各システムに追加される。これらのデーモンは、
下で説明するように、作業負荷の平衡化に使用される、
ロケーション・サービス・エージェントである。具体的
に言うと、ロケーション・サービス・デーモンは、通信
プロトコル（たとえばＩＩＯＰ）においても、作業負荷
マネージャ・サーバ・インスタンスとの通信のクライア
ント側実行時確立においても、独自拡張を必要とせず
に、業界標準のＣＯＲＢＡ ＩＩＯＰ（ＴＣＰ／ＩＰ）
プロトコルに基づいて、複製されたオブジェクト・サー
バ・インスタンスへのクライアント通信セッションの作
業負荷平衡化を容易にする。

【０１３６】ＩＩＯＰプロトコル内には、クライアント
が、分散ネットワーク内で対象のオブジェクトを突きと
めようとする時に発生する設計された制御の流れが存在
する。この制御の流れは、ＣＯＲＢＡによって定義さ
れ、「ロケート・フロー（locate flow）」と称する。
このフローに対して、３つの可能な応答が存在する。こ
のフローは、オブジェクトの識別に使用されるオブジェ
クト・リファレンスによって識別されるサーバ・インス
タンスに対して発生し、サーバ・インスタンスは、１）
オブジェクトがそのターゲット・サーバ・インスタンス
上にある、２）オブジェクトが存在しない、または３）
オブジェクトがこのサーバ・インスタンス上にないが、
この応答で返される新しいオブジェクト・リファレンス
によって識別される別のサーバ上にある可能性がある、
を応答する。第３の種類の応答を、「ロケーション・フ
ォワード（location forward）」応答と称する。クライ
アントＯＲＢは、ロケーション・フォワード型の応答を
受け取る時に、返されたオブジェクト・リファレンスに
よって識別されるサーバ・インスタンスにもう１つのロ
ケート・リクエストを発行する。

【０１３７】本発明の一態様によれば、複製されたサー
バ・インスタンスの組にまたがるクライアント通信エン
ドポイントの平衡化を引き起こすために、ロケーション
・フォワード機構が、独自の形で使用される。この機構
では、たとえば、直接および間接のオブジェクト・リフ
ァレンスが使用される。直接オブジェクト・リファレン
スとは、対象のサーバ・プロセス（アドレス空間）の実
際のネットワーク・アドレスがバインドされるリファレ
ンスである。間接オブジェクト・リファレンスとは、ロ
ケーション・サービス・エージェントまたはデーモンの
ネットワーク・アドレスがバインドされるリファレンス
である。本発明のこの態様に関して、分散オブジェクト
へのファースト・クラス・リファレンスが間接であるこ
とが前提である。したがって、分散クライアント・アプ
リケーションによって取得されるリファレンスは、間接
であり、それが使用される時には、ロケーション・サー
ビス・デーモンへのロケート・リクエストがもたらされ
る。

【０１３８】タスクを実行するために適当なサーバ・イ
ンスタンスを選択するのに使用される論理の一実施形態
を、図１７に関して説明する。まず、クライアントは、
たとえばネーム・サービスを介してまたは、出力パラメ
ータとしてリファレンスを返す関連しないオブジェクト
・メソッド・リクエストの結果として、間接オブジェク
ト・リファレンスを得る（ステップ１４００）。その
後、クライアントは、間接オブジェクト・リファレンス
を使用して、デーモンにロケート・リクエストを発行す
る（ステップ１４０２）。

【０１３９】その後、実際のオブジェクト・サーバ・イ
ンスタンスとして仮装しているデーモンは、そのシステ
ム上の作業負荷マネージャに問い合わせ、作業負荷マネ
ージャに、シスプレックス内のどこかで走行している使
用可能なサーバ・インスタンスを選択するように求め、
その結果、このクライアント通信を確立できるようにす
る（ステップ１４０４）。作業負荷マネージャは、構成
にまたがって使用可能な資源および容量の評価に基づい
てサーバ・インスタンスを選択し、選択されたサーバ・
インスタンス（たとえばシステム１のサーバ１またはシ
ステム２のサーバ１）のリファレンス情報をデーモンに
返す。デーモンは、ロケート・リクエストに対して、ロ
ケーション・フォワード応答を用いて応答し、選択され
た実際のサーバ・インスタンスの新しいリファレンスを
渡す（ステップ１４０６）。この返されるリファレンス
は、直接リファレンスであり、その結果、クライアント
による次のロケート・リクエストは、デーモンではなく
実際の選択されたサーバ・インスタンスに配送される
（ステップ１４０８）。この場合、選択されたサーバ・
インスタンスは、ロケート・リクエストに対して「オブ
ジェクトがここにある」応答を用いて応答する。

【０１４０】ロケーション・サービス・エージェント
が、作業負荷マネージャにタスクの実行に適当なサーバ
・インスタンスを選択させることができるようにするた
めに、エージェントは、まず、それ自体をデーモンとし
て作業負荷マネージャに登録する。これは、作業負荷マ
ネージャに固有の意味を有する。具体的に言うと、作業
負荷マネージャは、そのデーモンが作業負荷マネージャ
に戻ってきて、作業負荷マネージャに特定の環境名を突
きとめるように要求すると期待する。

【０１４１】作業負荷マネージャに登録するために、デ
ーモンは、さまざまな作業負荷管理インターフェースを
使用して、作業マネージャに登録されているサーバ・イ
ンスタンスの最適位置を得る。「作業マネージャ」とし
てＷＬＭ（WorkLoad Manager）に登録するのは、サーバ
・インスタンス（たとえば、下で説明する制御領域）で
ある。デーモンは、所与のクラス名の下で適当な「作業
マネージャ」を見つけるようにＷＬＭに求め、ＷＬＭ
は、その位置を返す。

【０１４２】複製されたサーバ・インスタンスの使用
は、すべてのサーバ・インスタンスが、アプリケーショ
ン・サーバ・インスタンスが必要とする資源に対する同
等の共用アクセス権を有する時に最適になる。この複製
が使用可能にされる時に実現される２つの特定の長所
が、１）単独の障害点の削減と、２）平衡化された性能
およびスケーラビリティである。さらに、３９０システ
ム設計では、複製されたサーバ・インスタンスの組に対
するインバウンド作業の配置に関する作業負荷管理決定
を行うのに最適の場所が、作業負荷の配置の知的決定を
行うのに必要な関係情報のすべてが存在し、作業が構成
に到着する際に実時間で評価できる、シスプレックス機
構であると主張されている。さらに、分散システムで
は、通信プロトコルおよびこれらのプロトコルをインプ
リメントする実行時が標準化されて、異なるベンダによ
って供給されるクライアントおよびサーバの組にまたが
って通信が発生することができる場合に、通信のサーバ
側で実行時に作業負荷管理決定を行い、その結果、独自
の作業負荷管理ベースの拡張が、さまざまなベンダのす
べてによって供給されるさまざまなクライアント側実行
時で不要になることが有利である。

【０１４３】本発明のもう１つの態様によれば、複製さ
れたサーバの組にまたがる作業負荷平衡化は、アプリケ
ーションの実行内の周知の境界で発生するように実行さ
れる。これは、走行中のアプリケーションに関連する一
時的な状態を保護するためである。具体的に言うと、ほ
とんどのアプリケーション・サーバ・インスタンス内に
は、物理アドレス空間またはアプリケーションをサービ
スするサーバ構造に束縛され、これから管理される、走
行中のアプリケーションに関連する一時的な状態が存在
する。そのようなシステムの、この一時的なアプリケー
ション状態は、トランザクショナル作業単位内など、ア
プリケーション活動の所定の周知の単位内で有効であ
り、コヒーレントであるとみなされる。そのような状態
の例には、アドレス空間の仮想メモリ・キャッシュ内に
常駐するオブジェクトまたはデータに対して行われ、デ
ィスクなどの物理的媒体上のデータの永続的なホームに
関して保留中である更新が含まれるが、これに制限はさ
れない。通常、そのような保留中の更新は、アプリケー
ション活動の所定の単位の終り、たとえば現行トランザ
クショナル作業単位の終りに、ディスク上の最終的なホ
ームにプッシュされる。一時的な状態の他の例には、状
態／遷移方針などのアプリケーションの実行を制御する
のに使用される制御情報またはメタ・データと、オープ
ン・ファイルまたは通信装置など、アプリケーションに
よって使用される資源の現在の状態を反映する状態デー
タが含まれる。

【０１４４】分散システム内およびアプリケーション活
動の所定の単位内には、所与のクライアントから、その
ようなアプリケーション状態が保持されているターゲッ
ト・サーバ・インスタンスへの直接の、または、複数の
他の中間ミドル層サーバ・インスタンスを介してターゲ
ット・サーバへのいずれかの、複数の相互作用が存在す
る可能性がある。アプリケーションの所与の活動単位の
下でのターゲット・サーバのアプリケーション状態への
すべてのリクエストが、分散アプリケーションの正しい
実行を保証するために、サーバのアドレス空間の同一の
物理インスタンスに向けられる。しかし、ターゲット・
サーバ・インスタンスが、クラスタ化構成の物理システ
ムにまたがって複製され、複製されたサーバ・インスタ
ンスへのアクセスが、作業負荷管理方針によって制御さ
れる場合には、アプリケーション活動の共通の単位の下
でターゲット・サーバ・インスタンスに対して確立され
る、分散ネットワーク内の中間ノードからのセッション
は、異なる物理サーバ・インスタンスに平衡化または分
散され、これによってアプリケーションでの誤った挙動
が導入される可能性がある。言い換えると、複製された
サーバの組にまたがる作業負荷平衡化は、アプリケーシ
ョンの実行内の周知の境界で発生しなければならない。
これらの境界の中では、ある機構を使用して、クラスタ
化システム構成内の特定のサーバ・インスタンスへの一
時的な類縁性が定義され、認識され、実施されることを
保証し、その結果、分散ネットワーク内のすべてのノー
ドからのアプリケーション活動の同一の単位の下のリク
エストが、構成内の同一の物理サーバ・インスタンスに
到着するようにする。

【０１４５】所与のトランザクショナル作業単位が、ク
ラスタ化システム構成内の適当なサーバ・インスタンス
に到着することを保証するために、トランザクション関
係の高性能マルチシステム登録と、ＣＯＲＢＡ準拠ＩＩ
ＯＰ関連ロケーション・フォワード機構が使用される。

【０１４６】所与の作業単位が適当なサーバ・インスタ
ンスに到着することを保証する実施形態の１つを、図１
８に関して説明する。メソッド・リクエストがサーバ・
インスタンスに到着し、そのリクエストに、分散トラン
ザクショナル・コンテキストなどの特定の作業単位が付
随する時には（ステップ１５００）、リクエストを受け
取るサーバ・インスタンスが、そのトランザクションの
所有者であるかどうかに関する判定が、ＯＲＢによって
行われる（問合せ１５０２）。言い換えると、サーバ・
インスタンスは、それがすでにインバウンド・トランザ
クションに関する責任を所有しているかどうかに関する
ローカル判断を行う。一例では、この判定は、サーバ・
インスタンスに結合された結合機構内またはサーバ・イ
ンスタンスのメモリ内に配置される登録テーブルを検査
することによって行われる。

【０１４７】サーバ・インスタンスが、インバウンド・
トランザクションの責任を所有する場合には、そのサー
バ・インスタンスがリクエストを処理する。

【０１４８】サーバ・インスタンスは、それがトランザ
クションの登録された所有者ではないと判定する場合
に、インバウンド・トランザクションへのサーバの関係
を登録しようと試みる（ステップ１５０４）。この登録
は、たとえば、結合機構で行われ、たとえばGlobal Res
ource Serialization（ＧＲＳ）大域待機（ＥＮＱ）を
使用することによって、原子的な形で実行される。ＧＲ
Ｓは、「OS/390 MVS Planning: Global Resource Seria
lization」、IBM Pub. No. GC28-1759-04（1998年3
月）、「OS/390 MVS Programming: Authorized Assembl
er Services Guide」、IBM Pub. No. GC28-1763-06（19
99年3月）、「OS/390 MVS Programming: Authorized As
sembler Services Reference」、IBM Pub. No. GC28-17
64-05（1998年9月、GC28-1765-07（1999年3月）、GC28-
1766-05（1999年3月）およびGC28-1767-06（1998年12
月）、「OS/390 MVS Programming: Assembler Services
Guide」、IBM Pub. No. GC28-1762-01（1996年9月）お
よび「OS/390 MVS Programming:Assembler Services Re
ference」、IBM Pub. No. GC28-1910-1（1996年9月）に
記載されており、これらのそれぞれが、参照によってそ
の全体を本明細書に組み込まれる。登録情報には、たと
えば、指定されたトランザクションに関連する構成内の
特定のサーバ・インスタンスを識別する、リクエストで
指定されたユーザ・データ（たとえばＵＵＩＤ）が含ま
れる。

【０１４９】その後、登録が成功であったかどうかに関
する判定を行う（問合せ１５０６）。すなわち、他のサ
ーバ・インスタンス複製が、同一のトランザクションへ
の関係を登録していない場合には、登録が成功し、その
サーバは、作業単位の適当なサーバ・インスタンスであ
るとみなされる（ステップ１５０８）。他のサーバ・イ
ンスタンス複製が、トランザクションへのその関係を登
録している場合には、登録の試みは失敗する。この場合
には、ＧＲＳ動作（たとえばＧＱＳＣＡＮ）を開始し
て、トランザクションに関して登録されているサーバ・
インスタンスの識別とトランザクションＩＤを含む登録
情報を得る（ステップ１５１０）。その情報が返された
時に、登録されているサーバ・インスタンスの位置と、
ディスパッチされるオブジェクトの現在のオブジェクト
・キーを使用して、新しいオブジェクト・リファレンス
を作成する（ステップ１５１２）。

【０１５０】その後、サーバ・インスタンスは、ロケー
ション・フォワード応答をクライアントに返す（ステッ
プ１５１４）。ＣＯＲＢＡプロトコルでは、所与のサー
バに送られる分散メソッド・リクエストに対して、ロケ
ーション・フォワード応答を返すことが許容される。ク
ライアントＯＲＢは、新しいオブジェクト・リファレン
スを使用して、シスプレックス内の適当なサーバ・イン
スタンスへのＩＩＯＰ接続を確立する（ステップ１５１
６）。

【０１５１】上のプロトコルを使用することによって、
有利なことに、トランザクションの処理中に接続の障害
が発生した場合に、トランザクションを打ち切らずに接
続を再確立することができる。

【０１５２】上で説明したように、ＯＲＢは、オブジェ
クトが互いに関連することを可能にする低水準接続性機
能を提供する。しかし、アプリケーションおよび他のコ
ンポーネントをＯＲＢベース環境で記述できるようにす
るために、他の機能性が提供される。Object Managemen
t Group（ＯＭＧ）によれば、これらの機能性は、ＯＲ
Ｂレベルの上の別々のモジュラー・コンポーネントとし
て定義されなければならない。これらの機能性の１つ
に、オブジェクトが名前によって他のオブジェクトを参
照できるようにするネーミング・サービスが含まれる。
具体的に言うと、OMG Naming Serviceを用いると、人間
可読の名前をオブジェクトに割り当てることができ、そ
の結果、その名前を後で使用して、オブジェクトを見つ
けることができるようになる。

【０１５３】名前は、ネーミング・コンテキスト内に存
在し、ネーミング・コンテキスト内で一意である。具体
的に言うと、名前は、ネーミング・コンテキスト内でオ
ブジェクトにバインドされる（すなわちバインディン
グ）。ネーミング・コンテキスト自体は、オブジェクト
であり、したがって、名前を用いて１つまたは複数の他
のネーミング・コンテキストにバインドすることができ
る。

【０１５４】OMG Naming Service仕様（ＣＯＲＢＡに基
づく）では、システム名前空間と、その名前空間の内容
を操作できる演算子の組が定義されている。名前空間の
一例を、図１９に示し、本明細書で説明する。名前空間
１６００には、ネーミング・コンテキスト・オブジェク
トまたはネーミング・コンテキストと称する複数のオブ
ジェクト１６０２が含まれる。各ネーミング・コンテキ
スト・オブジェクトには、少なくとも１つの、別のオブ
ジェクトへのバインディングが含まれる。このバインデ
ィングによって、人間可読の名前が、名前付きオブジェ
クトを識別するオブジェクト・リファレンスにマッピン
グされる。

【０１５５】OMG Naming Serviceの基本的な概念は、名
前空間が、ツリー１６０４を形成するために互いにバイ
ンドされたネーミング・コンテキストからなるというこ
とである。各ネーミング・コンテキストは、それ自体が
オブジェクトであり、したがって、分散できるので、名
前空間は、分散ネットワークにまたがる複数のネーム・
サーバにまたがって分散することができる（もう１つの
例として、名前空間が分散されない（図２０参照））。

【０１５６】２つのネーミング・コンテキストの間の関
連の作成は、単に、名前を有するコンテキストを、他の
オブジェクトと同様に他のコンテキストにバインドまた
は関連付けるという問題である。具体的に言うと、ネー
ム・サービスは、名前とオブジェクトを関連付けるため
の２つの別個のインターフェースを提供する。一方は、
ネーミング・コンテキストを親ネーミング・コンテキス
トにバインドするのに使用され、他方は、非ネーミング
・コンテキスト・オブジェクトを親ネーミング・コンテ
キストにバインドするのに使用される。

【０１５７】名前空間の構造と、その構造内でのネーミ
ング・コンテキストの配置をさらに示すために、図２１
を参照されたい。図２１は、ネーム・ツリー１７０２内
でのネーミング・コンテキスト１７００の階層の一例を
示す図である。オブジェクト自体は、名前を有しないこ
とに留意されたい。その代わりに、オブジェクトのバイ
ンディング１７０４が名前（たとえばＡ、Ｂ、…）を有
する。したがって、オブジェクト名は、本来コンテキス
ト的であり、ツリー内の配置に基づく相対的なものであ
る。オブジェクトにバインドされた名前は、所与のネー
ミング・コンテキスト内に存在する。

【０１５８】従来のネーミング・サービスに関連する問
題の１つが、バインディングおよびネーミング・コンテ
キストを、軽量ディレクトリ・アクセス・プロトコル
（ＬＤＡＰ）／Ｘ．５００によって提供されるデータ・
モデルなどの特定のデータ・モデルにマッピングする方
法である（ＬＤＡＰプロトコルおよびＸ．５００データ
・モデルは、ＸＯＰＥＮ Ｇｒｏｕｐによって提供され
る業界標準である。Ｘ．５００の標準規格には、ＩＴＵ
勧告Ｘ．５００−Ｘ．５２０に記載のＣＣＩＴＴＸ．５
００規格が含まれ、ＬＤＡＰは、ＩＥＴＦ ＲＦＣ ２
２５１−２２５６に記載されており、この両方が、参照
によってその全体を本明細書に組み込まれる）。具体的
に言うと、下層のディレクトリ技術と緊密にリンクされ
たインプリメンテーションをもたらさずに、下層のディ
レクトリのセマンティックスおよび構造を完全に利用す
る形で実行される、そのようなマッピングの必要が存在
する。

【０１５９】本発明の一態様によれば、コンポーネント
・ブローカ実行時サービスによって提供される抽象と共
にオブジェクト技術を介して使用可能にされる抽象に影
響を及ぼす、上記の問題に対する解決策が提供される。
この解決策を用いると、名前が合成名である時であって
も、ネーミング・コンテキストおよび名前付きバインデ
ィング（下で説明する）を「単一ホップ」を介して取り
出すことができる。単一ホップ取出とは、CosNaming::N
amingContext::resolveメソッドなどの解決メソッド
が、複数のテーブル索引または複数のresolveへの内部
呼出しではなく、下層のディレクトリ（たとえばＬＤＡ
Ｐディレクトリ）への単一のテーブル索引を用いて所望
のオブジェクトを突きとめることができることを意味す
る。

【０１６０】上記に加えて、本発明のこの態様は、さら
に、ネーミング・コンテキストおよび名前付きバインデ
ィングを一貫性のある形で処理できるようにし、これに
よって、必要なローカル探索照会の数を減らすことによ
って、性能を改善する。最後に、このインプリメンテー
ションは、アルゴリズムを下層のディレクトリ技術の詳
細から物理的に分離する構造を提供する。

【０１６１】具体的に言うと、一実施形態では、オブジ
ェクト特化を使用し、これによって、名前空間内のオブ
ジェクトをバインディングとして扱えるようにする。す
なわち、バインディングは、アプリケーション・オブジ
ェクトに対するバインディングを表すのに使用される名
前付きバインディングと、下でさらに説明する、名前空
間内の不連続性の点を表す乖離と、ネーミング・コンテ
キスト特化を表すネーミング・コンテキストとの３つの
範疇に分類される。

【０１６２】ネーミング・コンテキストとバインディン
グ・クラスの両方が、管理オブジェクトである。管理オ
ブジェクトとして、ネーミング・コンテキストとバイン
ディング・クラスは、ビジネス・オブジェクトおよびデ
ータ・オブジェクトに分割される。ネーミング・コンテ
キストのビジネス・オブジェクトには、ディレクトリ
（たとえばＬＤＡＰ）の抽象を操作するアルゴリズムが
含まれ、データ・オブジェクトは、下層のディレクトリ
との関係を管理する責任を負う。管理オブジェクトのコ
ンポーネントに関連する継承関係および委譲関係の一例
を、図２２に示す。たとえば、NamingService::NamingC
ontextは、IextendedNaming::NamingContextとNamingSe
rvice::Bindingの両方から継承することが示されてい
る。

【０１６３】データ・オブジェクトは、下層のディレク
トリのサービスを使用して、バインディングおよびネー
ミング・コンテキストに対応する項目の作成、削除、検
索および更新を行う。本発明の一態様によれば、バイン
ディング・クラスとネーミング・コンテキスト・クラス
は、同一の属性をサポートする。したがって、バインデ
ィング・クラスとネーミング・コンテキスト・クラス
は、同一の下層ディレクトリ・データに関して二重のパ
ーソナリティとして働く。パーソナリティは、データの
オブジェクト表現として定義される。ネーミング・コン
テキストは、バインディングとの間の継承関係からのバ
インディングであるので、そのバインディングの存在
は、名前空間内でバインドされたネーミング・コンテキ
ストの存在を暗示する。

【０１６４】この形でネーミング・コンテキストを定義
すると、特定のネーム・サーバ内に常駐するオブジェク
トの効率的な１ホップ・テーブル索引が可能になる。名
前空間に含まれる各オブジェクトは、バインディング・
オブジェクトによって表されるので、所与の名前の名前
付きバインディングの検索は、単一のホーム・コレクシ
ョン（バインディング・ホーム・コレクション）に対す
る探索を必要とする。

【０１６５】各バインディングには、それに関連するパ
ーソナリティのハンドルを表す属性が格納される。ネー
ミング・コンテキストを表すバインディングの場合、パ
ーソナリティは、そのクラスがネーミング・コンテキス
トであるが、その主キーがバインディングと同一であ
る、すなわち、フル・バインディング名であるオブジェ
クトへのポインタである。したがって、所望のバインデ
ィングを突きとめた後に、そのバインディングをバッキ
ングするデータのビューは、パーソナリティ属性を返す
ことによってネーミング・コンテキスト・クラスに変換
される。したがって、同一ディレクトリ・データの二重
のパーソナリティが見られる。

【０１６６】さらに、バインディングが、アプリケーシ
ョン・オブジェクトへのバインディングを表す場合に
は、パーソナリティ属性が、バインドされたオブジェク
トへのリファレンスを格納するのに使用される。したが
って、名前バインディングの解決は、バインディング・
ホーム・コレクションに対する探索を介して実行するこ
とができる。その名前付きバインディングにバインドさ
れるオブジェクトは、パーソナリティ・フィールドに格
納される。ネーミング・コンテキストを表すバインディ
ングの場合には、パーソナリティ・フィールドに、同一
のデータによってバッキングされるネーミング・コンテ
キスト型のオブジェクトへのリファレンスが格納され
る。この二重マッピングが可能にされるのは、これらの
オブジェクトのそれぞれへのリファレンスのそれぞれ
に、ディレクトリへの同一のキーが格納されるからであ
る。これを、下でさらに説明する（本明細書に記載の擬
似コードの少なくとも一部では、前後の議論に関連する
コードの抜粋だけを示す）。

【０１６７】新しいネーミング・コンテキストを作成
し、それを名前空間内にバインドするのに使用されるbi
nd_new_contextのインプリメンテーションに関連する擬
似コードの一例を、下に示す（本明細書に記載の擬似コ
ードの少なくとも一部では、前後の議論に関連するコー
ドの抜粋だけを示す）。 ・If nameが合成名である then ・新しいコンテキストがバインドされるネーミング・コ
ンテキストを見つけるために、ctx = 実行中のネーミン
グ・コンテキスト -> resolve(<c1;c2;...cn-1>) ・単純名に対してbind_new_contextを呼び出すために、
ctx->bind_new_context(<cn>)を呼び出す ・リターン ・Else nameが単純名である ・新規作成されるNamingContextオブジェクトの主キー
文字列を作成する ・このキーを使用して、Naming Contextホーム・コレク
ションに対してコンストラクタ（createFromPrimaryKey
String）を駆動する。 ・バインディング・タイプ属性にNaming Contextをセッ
トする ・この新しいNamingContextのIORをパーソナリティ属性
に保存する ・NamingContextオブジェクトを返す

【０１６８】bind_new_contextの上の手順では、単一の
ホーム・コレクション（たとえばNaming Contextホーム
・コレクション）に新しいオブジェクトを作成する。継
承関係のゆえに、定義により、バインディング・オブジ
ェクトは、これと同時に作成される。したがって、ネー
ミング・コンテキストの作成と名前空間へのコンテキス
トのバインディングは、同義である。また、この手順で
は、まずresolveを呼び出し、その結果、単純名を操作
できるようにしていることに留意されたい。上の擬似コ
ードでは、ctx->bind_new_contextの呼出しが、再帰呼
出しである。ある点で、単純名が供給され、この論理
は、主キー文字列の作成に継続する。合成名に関連する
すべてのネーミング・コンテキストならびに、それに対
してbind_new_contextが呼び出されるオブジェクトが、
同一のネーム・サーバ内に存在する時に、新しいネーミ
ング・コンテキスト・オブジェクトを、resolveメソッ
ドへの単一のホップだけを用いて作成することができ
る。

【０１６９】アプリケーション・オブジェクトは、bind
メソッドを使用して名前空間にバインドされる。以下の
手順で、bindメソッドの一実施形態を説明する。このbi
ndメソッドは、単一の作成動作だけを必要としながら、
単一のホップで新しい名前付きバインディングを作成で
きることに留意されたい。 ・If nameが合成名である then ・オブジェクトがバインドされるターゲット・ネーミン
グ・オブジェクトを見つけるために、ctx = 実行中のネ
ーミング・コンテキスト -> resolve(<c1;c2;...cn-1>) ・resolve動作は、指定された名前を見つけられない場
合に例外を送出することに留意されたい ・単純名に対してbindを呼び出すために、ctx->bind(<c
n>, obj)を呼び出す ・リターン ・Else nameが単純名である ・新しいBindingオブジェクトの主キー文字列を作成す
る ・createFromPrimaryKeyStringを呼び出し、PrimaryKey
を渡すことによって、Bindingホーム・ファクトリを駆
動する ・if nameがすでにBindingホーム・コレクションに存在
する ・AlreadyBound例外を送出する ・else 新しいBindingオブジェクトが作成された ・新しいBindingオブジェクトのパーソナリティ属性にo
bjをセットする ・バインドされたオブジェクトをバインディング・タイ
プ属性にセットする ・リターン

【０１７０】上の論理では、createFromPrimaryKeyStri
ngメソッドが呼び出される。この動作は、たとえば、ホ
ーム・コレクションに常駐する種類の新しい永続的なオ
ブジェクトを作成するのに使用される、ホーム・コレク
ションに対するファクトリ・メソッドである。これは、
システム内で永続的な管理オブジェクトを作成するのに
使用される機構である。

【０１７１】この時点で、新しい名前付きバインディン
グが、名前空間に追加されている。これらの名前付きバ
インディングの下層ディレクトリへのマッピングによっ
て、resolveメソッドを用いる効率的な検索が可能にな
る。バインディングのホーム・コレクションだけが、探
索される必要があり、検索されたバインディングのパー
ソナリティ属性の内容が返される。これは、バインディ
ングがネーミング・コンテキストを表す場合でも、バイ
ンドされたアプリケーション・オブジェクトを表す場合
でも機能する。

【０１７２】resolveの手順の例を下に示す。 ・If 入力nameが'/'または'\'から始まる then ・Naming Serviceルートを得るためにresolve_initial_
referencesを呼び出す ・名前の残りを渡して、ルート・ネーミング・コンテキ
ストに対してresolveを再駆動する ・リターン ・名前空間内の探さなければならないオブジェクトを表
す主キー文字列を作成する ・主キー文字列を渡して、Bindingホーム・コレクショ
ンに対してfindByPrimaryKeyStringを駆動する ・If Bindingオブジェクトが見つかった then ・Bindingオブジェクトのbound_object属性を返す。こ
れは、リーフ・ノード・オブジェクトまたはNamingCont
extオブジェクトのいずれかになる可能性がある。

【０１７３】上で詳細に説明したのは、新しい名前付き
バインディングを単一ホップで作成できるようにし、複
数レベルの名前をルート・ネーミング・コンテキストか
ら単一ホップで解決できるようにする機能である。これ
は、ルートから始める時に、createとresolveをそれぞ
れ１回だけ呼び出す必要があることを意味する。さら
に、単一のリポジトリ（ＬＤＡＰ）が、ネーミング・コ
ンテキストとバインディングの両方のための永続的な記
憶域として使用される。さらに、バインディングの状態
は、バインディングの型を示すために型を付けられる。

【０１７４】上で説明したように、名前空間を構築する
際には、名前空間の諸部分が、異なる物理システムに存
在することが可能である。すなわち、あるサーバがある
システム上にあり、別のサーバが別のシステム上にある
可能性がある。たとえば、図２１を参照すると、ネーミ
ング・コンテキスト「／Ｂ」が、システムＡ上に存在す
ることができ、ネーミング・コンテキスト「／Ｂ／Ｄ」
が、システムＢ上に存在することができる。これらのネ
ーミング・コンテキストの下層の資源マネージャは、同
一でない可能性がある（たとえば、これらの資源マネー
ジャは、データベース内の異なるデータ・スキーマおよ
びフォーマット、ディレクトリ・スキーマのナビゲート
に使用される異なるプロトコル、ディレクトリ・システ
ム内の項目を表すのに使用される名前の異なるフォーマ
ットなどを有する可能性がある）。たとえば、ネーミン
グ・コンテキスト「／Ｂ」が、ＬＤＡＰに格納され、ネ
ーミング・コンテキスト「／Ｂ／Ｄ」が、ＤＣＥ ＣＤ
Ｓ（Distributed ComputerEnvironment Cell Directory
Services）に格納される可能性がある。このシナリオ
の概略図を、図２３に示す。図２３では、ネーミング・
コンテキスト「／Ｂ」１９００が、システムＡのネーム
・サーバ１（１９０２）内に配置され、ＬＤＡＰ資源マ
ネージャ１９０４によってバッキングされ、ネーミング
・コンテキスト「／Ｂ／Ｄ」１９０６が、システムＢの
ネーム・サーバ１（１９０８）内に配置され、そのデー
タが、ＤＣＥ ＣＤＳ資源マネージャ１９１０によって
バッキングされる。

【０１７５】ネーミング・コンテキストが異なるシステ
ムに常駐するので、名前空間内に「外部接合」があると
言われる。すなわち、特定のネーミング・コンテキスト
（たとえば「／Ｂ／Ｄ」）を１つのシステム上で解決で
きず、したがって、外部接合が存在する。本発明の一態
様によれば、このような外部接合は、性能を損なわず、
使用される下層のディレクトリ技術の知識に依存しない
形でトラバースされる。

【０１７６】下でさらに説明するように、本発明のこの
態様によって使用される技法は、下層のネーミング・コ
ンテキスト格納機構のオブジェクト表現によって提供さ
れる抽象に影響し、乖離バインディングという概念が導
入される。乖離バインディングは、ネーミング・コンテ
キストのＣＯＲＢＡ名の、下層のディレクトリ技法の自
然な名前解決能力からの逸脱が発生する位置を表す。た
とえば、ＯＭＧネーム・サービスのバインディング名
が、ａ／ｂになる場合がある。この名前の「ａ」部は、
ディレクトリ・システムＸにマッピングされ、下層ディ
レクトリでの実際の名前が、「name = a」というフォー
マットである。名前の「ｂ」部は、異なる下層ディレク
トリ、ディレクトリＹに常駐し、この要素の下層ディレ
クトリ名が、「partname <b>」である可能性がある。ａ
とｂの間の接合は、オブジェクト空間内で「ａ／ｂ」名
前付きバインディングを形成するために連合化する必要
がある２つの異なるネーミング・スキーマを有する２つ
の異なるディレクトリ・システムに対する大きい接合で
ある。これらの乖離点の識別によって、外部接合を効率
的に簡単に識別できるようになる。

【０１７７】上記に加えて、本発明のこの態様では、同
種の形でエイリアス名をインプリメントするために、乖
離バインディングを利用する。ネーミング・コンテキス
トのエイリアス名とは、そのネーミング・コンテキスト
の代替の名前である。ネーミング・コンテキストは、当
初は、プライマリ名の下でバインドされ、これがそのハ
ード・リンクになる。さらに、そのネーミング・コンテ
キストへの代替経路で、エイリアス名が利用される。エ
イリアス名と外部接合は、同一の形で処理される。

【０１７８】有利なことに、エイリアス名と外部接合
は、名前解決動作中の下層ディレクトリ技術への効率的
なマッピングの長所を最大にする形で処理される。これ
は、ローカル・システムと外部システムの両方の名前空
間セグメントの下層ディレクトリ技術からの独立性を維
持する形で行われる。

【０１７９】一例では、名前解決動作に、所与の名前に
関連するオブジェクトを見つけるのに使用されるresolv
eメソッドが含まれる。resolveメソッドの処理の一部と
して、乖離バインディングに遭遇する可能性がある。こ
れが処理される形を、図２４に関して下で説明する。

【０１８０】一実施形態では、主キーは、入力の名前に
基づいて構築される（ステップ２０００）。主キーは、
名前空間内で数層下のオブジェクトを表すことができ
る。キー構築の一例を、図２６に関して下で説明する。
主キーの構築の後に、findByPrimaryKeyメソッドを呼び
出して、その主キーによって知られる名前空間オブジェ
クトを探す（ステップ２００２）。一例として、findBy
PrimaryKey動作は、ホーム・コレクションに対して導入
され、入力の主キー値によって指定される管理オブジェ
クトのホーム・コレクションを照会するのに使用するこ
とができる。

【０１８１】検索が成功である場合には（問合せ２００
４）、所望のバインディングが見つかる。したがって、
そのバインディングに関連するオブジェクトを、呼出し
元に返す（ステップ２００６）。このオブジェクトは、
アプリケーション・オブジェクトまたはネーミング・コ
ンテキストのいずれかになる可能性がある。したがっ
て、本明細書に記載のように、複数レベルの解決を、単
一のステップで実行できる。

【０１８２】findByPrimaryKeyでターゲット・オブジェ
クトを発見できない場合には、潜在的に解決できている
名前の最大の部分に対して、findByPrimaryKeyを駆動す
る（ステップ２００８）。これは、findByPrimaryKeyが
成功するか、名前全体を使い果たすまで、右端の名前成
分を増分的に後戻りすることによって達成できる。その
代わりに、下層ディレクトリ技術が、最初のfindByPrim
aryKeyが不成功であった後に解決できた名前の部分を供
給することができる。この情報は、例外を介するなどの
一般的な形でビジネス・オブジェクトに供給することが
できる。

【０１８３】名前のどの部分もfindByPrimaryKeyを介し
て突きとめることができない場合（問合せ２０１０）に
は、NotFound例外を供給する（ステップ２０１２）。そ
の一方で、名前の一部がfindByPrimaryKeyStringを介し
て突きとめられる場合には、乖離が名前空間内で突きと
められている（ステップ２０１４）。この乖離は、外部
バインディングまたはエイリアス名のいずれかを表す可
能性がある。そのバインディングに関連するオブジェク
トを取り出し、オブジェクト名の残りを使用して、その
オブジェクトに対してresolveメソッドを再駆動する
（ステップ２０１６）（乖離が外部バインディングを表
す場合には、resolveメソッドは、異なるシステムに対
して再駆動される。このシステムは、乖離が突きとめら
れたシステムと異なるＣＯＲＢＡアーキテクチャのイン
プリメンテーションを有する可能性がある）。したがっ
て、性能は、通常のテーブル索引の場合には維持され、
簡単で同質の形で処理される乖離は、下層ディレクトリ
の機構から分離されている。

【０１８４】resolveメソッドに関連する詳細を、さら
に下で説明する。具体的に言うと、resolveに関連する
論理の一実施形態は次の通りである。 ・If 入力nameが'/'または'\'から始まる then ・Naming Serviceルートを得るためにresolve_initial_
referencesを呼び出す ・nameの残りを渡して、ルート・ネーミング・コンテキ
ストに対してresolveを再駆動する ・リターン ・名前空間内の見つけなければならないオブジェクトを
表す主キー文字列を作成する ・主キー文字列を渡してBindingホーム・コレクション
に対してfindByPrimaryKeyStringを駆動する ・If Bindingオブジェクトが見つかった then ・Bindingオブジェクトのbound_object属性を返す。こ
れは、リーフ・ノード・オブジェクトまたはNamingCont
extオブジェクトのいずれかになる可能性がある。 ・Else findByPrimaryKeyメソッドでBindingオブジェク
トが見つからなかった ・name =<c1;c2;...,cn>の主キーを使用してBindingホ
ーム・コレクションに対するfindByPrimaryKeyが成功す
る最大のnを見つける ・If そのようなnのBindingが見つかった then ・Bindingオブジェクトからbound-object属性を得る。
これは、NamingContextオブジェクトを表す ・name =<cn+1;cn+2,...,cz>を使用してこのNamingCont
extに対してresolveを駆動する。ここで、czは、元の名
前の最後の成分である ・resolve呼び出しから返されたオブジェクト・リファ
レンスを返す ・Else Bindingが見つからない ・NotFound例外を送出する

【０１８５】上からわかるように、本明細書に記載の手
法は、ローカル・システムまたは外部システムのいずれ
のバッキング・ディレクトリとも直接の相互作用を有し
ない。この手法では、コンポーネント・ブローカ・プロ
グラミング・モデルのオブジェクト空間に対して定義さ
れたクライアント側インターフェースだけを利用する。
具体的には、インスタンス管理インターフェースならび
に、Naming Serviceによって供給されるインターフェー
スおよびおそらくは、１ホップで解決できる名前の最大
のサブ部分の「ヒント」（すなわち、名前の一致する部
分）が利用される。

【０１８６】乖離バインディングは、元々は、bind_con
text呼び出しの結果として確立された。bind_contextに
関連する論理の一例を下に示す。 void bind_context (in Name name, in NamingContext nc) raises (NotFound, CannotProceed, InvalidName AlreadyBound); ・If nameが合成名 then ・入力コンテキストがバインドされるターゲット・ネー
ミング・コンテキストを見つけるために、ctx = 実行中
のネーミング・コンテキスト->resolve(<c1;c2;...cn-1
>) ・単純名に対してbind_contextを呼び出すためにctx->b
ind_context(<cn>,nc)を呼び出す ・リターン ・Else nameが単純名である ・新しいBindingの主キー文字列を作成する ・createFromPrimaryKeySringを呼び出し、PrimaryKey
を渡すことによって、Bindingホーム・ファクトリを駆
動する ・If NamingContextがすでに存在する ・AlreadyBound例外を返す ・新しいBindingのバインディング・タイプ（bt）属性
にndcontextをセットして、このBindingオブジェクトが
乖離バインディングを表すことを示す ・bound_object属性に入力ネーミング・コンテキストnc
をセットする ・リターン

【０１８７】上で説明したのは、外部ネーミング・コン
テキストを処理する技法である。有利なことに、外部ネ
ーミング・コンテキストへの接合またはエイリアスを含
む複数レベルの名前を、最小の数のホップで解決するこ
とができる。

【０１８８】本発明の一態様では、効率的な１ホップ名
前解決を容易にするために、オブジェクトのコンテキス
トに敏感なＣＯＲＢＡ名（すなわちCosNaming::Name）
が、そのオブジェクトの識別（たとえばその主キー）に
マッピングされ、その後、効率的であるが、ＣＯＲＢＡ
オブジェクト・ドメインとディレクトリ・ドメインの間
の分離も維持される形でＬＤＡＰ Ｘ．５００（一例と
して）の識別名にマッピングされる。

【０１８９】具体的に言うと、一例では、オブジェクト
が常駐するサーバのルートに対する相対的なＣＯＲＢＡ
名が、名前空間オブジェクト（たとえばバインディング
またはネーミング・コンテキスト）のオブジェクト主キ
ーとして使用される。オブジェクト主キーは、その後、
そのオブジェクトを表すディレクトリ項目の識別名の判
定に使用される。したがって、名前空間オブジェクトの
識別は、そのオブジェクトが常駐するサーバの名前空間
のルートに対する相対的な名前と密接に結び付けられ
る。この手法の長所は、効率的な１ホップ名前解決が容
易になり、インダイレクションの必要が減り、バインデ
ィング属性としてＣＯＲＢＡ名を格納する必要が除去さ
れることである。

【０１９０】名前付きオブジェクトに対してメソッドを
ディスパッチするためのＣＯＲＢＡ名の識別名へのマッ
ピングに関連する論理の一実施形態を、図２５に関して
説明する。一例として、名前空間オブジェクトに対して
メソッドが呼び出される時に、メソッド・リクエスト
は、クライアント（すなわち呼出し元）からネーム・サ
ーバに流れる（ステップ２１００）。この流れに含まれ
るのが、メソッドが呼び出される対象のオブジェクトの
リファレンス（ＩＯＲ）である（このオブジェクトを、
実行オブジェクトと称する）。このリファレンスには、
そのターゲット・オブジェクトのオブジェクト・キーが
含まれる。ＯＲＢは、ＩＯＲからオブジェクト・キーを
抽出し、コンテナに供給する（ステップ２１０２）。オ
ブジェクト・インスタンス化処理の一部として、コンテ
ナは、ネーミング・コンテキスト・データ・オブジェク
トを作成し、それにこのキーを供給する（ステップ２１
０４）（上で説明したように、データ・オブジェクト
は、ディレクトリとの相互作用の責任を負う）。

【０１９１】その後、データ・オブジェクトは、キーか
らＣＯＲＢＡ名を抽出する（ステップ２１０６）。たと
えば、オブジェクト・キーは、「ルート・コンテナ／バ
インディング・ホーム主キー／オブジェクト主キー」と
いうフォーマットを有する可能性があり、ここで、オブ
ジェクト主キー部分の可能な値は、「Y12A.Dept/Jeffre
y Frey.Programmer」である。データ・オブジェクト
は、主キーのオブジェクト主キー部分を抽出して、サー
バのルートに対する相対的なそのオブジェクトのＣＯＲ
ＢＡ名の文字列形を得る。上の例では、この文字列は
「/Y12A.Dept/Jeffrey Frey.Programmer」である。

【０１９２】その後、オブジェクト主キーは、逆転さ
れ、さらに操作されて、ＬＤＡＰ識別名が作成される
（ステップ２１０８）。このＬＤＡＰ識別名は、対応す
るディレクトリ・エントリを突きとめるためにＬＤＡＰ
によって使用することができる。

【０１９３】以下は、前のステップからのＣＯＲＢＡ名
を使用する、結果の識別名の一例である。ＬＤＡＰルー
トは、下層ディレクトリの名前空間ルートの位置であ
る。 TypelessRDN=Jeffrey Frey.Programmer、 TypelessRDN=Y12A.Dept、TypelessRDN=/、＜ＬＤＡＰル
ート＞

【０１９４】その後、データ・オブジェクトは、この識
別名を使用して、単一の動作でデータを検索する（ステ
ップ２１１０）。その後、残りのオブジェクト・インス
タンス化処理が実行され、メソッドがディスパッチされ
る（ステップ２１１２）。

【０１９５】オブジェクト・キーの一部としてＣＯＲＢ
Ａ名を使用することによって、オブジェクト・リファレ
ンス（すなわちインタオペラブル・オブジェクト・リフ
ァレンス）に、下層ディレクトリ（たとえばＬＤＡＰ
Ｘ．５００）からオブジェクトを取り出すのに必要な情
報が格納される。オブジェクト・キーを識別名にマッピ
ングするために、メタ状態テーブルは不要である。さら
に、ディレクトリの下層構造は、名前空間の構造を表
す。すなわち、名前空間オブジェクトは、ある生成され
た名前を使用して単一のディレクトリ項目の下にバイン
ドされるすべての名前空間オブジェクトに関してフラッ
トな形でディレクトリを使用する必要がない。

【０１９６】上で説明したのは、前に存在する名前空間
オブジェクトのインスタンス化である。次に説明するの
は、新しい名前空間オブジェクトの作成のための主キー
の構築である。一例として、bind_new_context（name）
メソッドは、実行中のネーミング・コンテキストに対す
る相対的な名前「name」を使用して、名前空間内でバイ
ンドされる新しいネーミング・コンテキスト・オブジェ
クトの作成をもたらす。新しいオブジェクトのための新
しい主キーの作成に関連する論理の一実施形態を、図２
６に関して説明する。

【０１９７】まず、現在実行中のネーミング・コンテキ
ストの主キーを得る（ステップ２２００）（オブジェク
トが存在し、識別を有するので、このキーは簡単に入手
できる）。その後、主キーをＣＯＲＢＡ名に変換する
（ステップ２２０２）。

【０１９８】ＣＯＲＢＡ名を得た後に、入力名「name」
をＣＯＲＢＡ名に付加する（ステップ２２０４）。その
後、結果のＣＯＲＢＡ名を、オブジェクト・キーに変換
する（ステップ２２０６）。

【０１９９】たとえば、名前「/Y12A.Dept/Jeffrey Fre
y.Programmer/Component Broker.Project」の下の新し
いネーミング・コンテキストを作成すると仮定する。新
しいネーミング・コンテキストを作成するために、この
例では名前が「/Y12A.Dept/Jeffrey Frey.Programmer」
である現在実行中のネーミング・コンテキストに対し
て、bind_new_contextメソッドを呼び出す。bind_new_c
ontextの呼び出しに渡される名前は、「Component Brok
er.Project」である。このメソッド内で、主キーが作成
される。

【０２００】新しいネーミング・コンテキストの主キー
を作成するために、現在実行中のネーミング・コンテキ
ストのＣＯＲＢＡ名の文字列形が抽出される。処理の、
新しいキーが作成される時点では、現在実行中のネーミ
ング・コンテキストの主キーは、「ルート・コンテナ／
Bindingホーム主キー／オブジェクト主キー」であり、
この例のオブジェクト主キー部分の値は、「/Y12A.Dept
/Jeffrey Frey.Programmer」である。

【０２０１】その後、オブジェクト主キーが抽出され、
サーバのルートに対する相対的なオブジェクトのＣＯＲ
ＢＡ名の文字列形がもたらされる。前と同様に、その文
字列は、この例では「/Y12A.Dept/Jeffrey Frey.Progra
mmer」である。その後、現在実行中のネーミング・コン
テキストに対する相対的な新しいバインディングの名前
が、ＣＯＲＢＡ名に連結されて、ＣＯＲＢＡ名文字列
「/Y12A.Dept/Jeffrey Frey.Programmer/Component Bro
ker.Project」がもたらされる。この文字列は、その
後、作成中の新しいネーミング・コンテキストの主キー
のオブジェクト・キーとして使用され、その形は、「ル
ート・コンテナ／Bindingホーム主キー／オブジェクト
主キー」である。この手法の結果として、オブジェクト
・キー内のオブジェクト主キーの構造に、ＬＤＡＰ識別
名または、サーバのルートに対する相対的なオブジェク
トのＣＯＲＢＡ名の文字列形のいずれかの構築に必要な
すべての情報が格納される。

【０２０２】上記のもう１つの例は、次の通りである。
ａ／ｂ／ｃ／ｄ／ｅ／ｆを有するツリーを仮定する。さ
らに、resolveメソッドが、単純名ｃによって指定され
るネーミング・コンテキストに対して駆動され、名前ｄ
／ｅ／ｆでバインドされるネーミング・コンテキストに
対して相対的にバインドされるオブジェクトが、突きと
められるか作成されると仮定する。したがって、ｃ位置
のネーミング・コンテキストの完全識別は、ａ／ｂ／ｃ
である。ＬＤＡＰでのその実際の名前は、たとえば、ty
pelessRDN=c、typelessRDN=b、typeRDN=aである。この
ＬＤＡＰ名は、ＬＤＡＰディレクトリからその名前に関
連するオブジェクトを取り出すのに使用される。そのデ
ータ・オブジェクトは、ＬＤＡＰ名をそのＣＯＲＢＡ名
ａ／ｂ／ｃに変換する。その後、／ｄ／ｅ／ｆがＣＯＲ
ＢＡ名に付加され、ａ／ｂ／ｃ／ｄ／ｅ／ｆがもたらさ
れる。このＣＯＲＢＡ名全体が、上で説明したように新
しいオブジェクト・キーに変換される。後続の点で、新
しい主キーが、データ・オブジェクトに供給され、この
データ・オブジェクトは、その主キーを使用して、識別
名を作成する。その後、この識別名を使用して、項目を
見つけるか作成することができる。

【０２０３】この新しいキーは、たとえばcreateFromPr
imaryKeyStringメソッドへの入力として使用して、新し
いネーミング・コンテキスト・オブジェクトを作成し、
それに名前空間を関連付ける（またはバインドする）こ
とができる。これを達成するための処理の一部として、
新しいキーが、データ・オブジェクトに供給され、この
データ・オブジェクトは、識別名を作成し、ldap_addを
呼び出す。

【０２０４】次の例では、新しいキーを使用して、既存
の項目を見つける。たとえば、この同一の主キー構築手
法を、resolveメソッドの一部として使用して、名前空
間内でバインドされたオブジェクトを単一ホップで突き
とめることができる。resolveメソッドは、たとえばネ
ーミング・コンテキスト・ビジネス・オブジェクト内で
インプリメントされる（上で説明したように、ビジネス
・オブジェクトには、主アプリケーション・インターフ
ェースとアルゴリズムが含まれる）。resolve中に、新
しいキーが、findByPrimaryKeyStringに渡され、findBy
PrimaryKeyStringは、そのキーをデータ・オブジェクト
に渡す。このデータ・オブジェクトは、キーを使用し
て、識別名を作成し、ldap_searchを呼び出す。主キー
作成処理を使用するresolveメソッドの一実施形態を、
下に示す。 ・If 入力nameが'/'または'\'から始まる then ・Naming Serviceルートを得るためにresolve_initial_
referencesを呼び出す ・nameの残りを渡して、ルート・ネーミング・コンテキ
ストに対してresolveを再駆動する ・リターン ・実行中のNaming Contextの主キーで表されるCorba Na
meに入力Nameを連結することによって見つかるName Spa
ce内のオブジェクトを表す主キー文字列を作成する ・主キー文字列を渡して、Bindingホーム・コレクショ
ンに対してfindByPrimaryKeyStringを駆動する ・If Bindingオブジェクトが見つかった then ・Bindingオブジェクトのbound_object属性を返す。こ
れは、リーフ・ノード・オブジェクトまたはNamingCont
extオブジェクトのいずれかになる可能性がある。

【０２０５】上の形での名前空間オブジェクト主キーの
定義によって、名前解決をバッチ式に実行することが可
能になる。探索のターゲットである名前は、その名前が
ディレクトリ階層内で数層下のオブジェクトを表す場合
であっても、単一ホップで解決できる。この手法によっ
て、下層のセマンティックスおよび下層ディレクトリ技
術の性能特性を利用できるようになる。

【０２０６】本発明の一態様によれば、名前空間に対す
る複数の更新は、互いにならびにアプリケーション・オ
ブジェクトの作成および更新に対して、原子的にされ
る。たとえば、保険方針オブジェクトなどのアプリケー
ション・オブジェクトは、原子的に作成され、名前空間
にバインドされる。これによって、名前空間の全体的な
保全性が維持される。一実施形態では、原子的更新は、
ネーム・サーバでのトランザクショナル・セマンティッ
クスの追加によって提供される。名前空間オブジェクト
のトランザクショナル・セマンティックスは、名前空間
オブジェクトを管理オブジェクトにすることによって達
成される。管理オブジェクトとして、名前空間オブジェ
クトは、トランザクショナル特性を含むサービスの品質
の組を継承する。これと共に、トランザクショナル・コ
ンテキストをネーム・サーバから、たとえばＬＤＡＰデ
ィレクトリを介して、最終的に資源マネージャに伝播す
る、ディレクトリ・サービスへのローカル・インターフ
ェースが供給される。

【０２０７】名前空間オブジェクトでトランザクショナ
ル・セマンティックスを達成するために、コンピューテ
ィング環境の複数のコンポーネントが使用される。これ
らのコンポーネントには、たとえば、一般化された２相
コミット・マネージャとして働く下層の資源回復サービ
ス（ＲＲＳ）２３００（図２７）、ＲＲＳに結合され、
ＲＲＳと共に働くオブジェクト・トランザクション・サ
ービス２３０１、ＲＲＳプロトコルを利用する資源マネ
ージャ２３０２（たとえばデータベース・サブシステ
ム）、資源マネージャ２３０２に結合されるローカル・
バックエンド２３０５を、ＲＲＳプロトコルを利用して
作成するＬＤＡＰサービス２３０４、および、オブジェ
クト・リクエスト・ブローカ２３０８およびコンテナ２
３１２を含むサーバ・インフラストラクチャ２３０６が
含まれる。

【０２０８】これらのコンポーネントは、プログラミン
グ・モデルとしてコンポーネント・ブローカ管理オブジ
ェクト・フレームワークを使用し、ネーミング・オブジ
ェクトの支援記憶装置として使用されるディレクトリ・
サービスとしてＬＤＡＰローカル・バックエンドを使用
することを介して、ネーム・サーバによってまとめられ
る。

【０２０９】管理オブジェクト・フレームワークを使用
することによって、ネーム・サーバは、コンテナがトラ
ンザクションを管理できるようにする、設計されたイン
ターフェースの組をサポートする。これらのインターフ
ェースには、クライアント・レベル・インターフェース
をインプリメントするためのアプリケーション論理を含
むビジネス・オブジェクトに使用されるものと、支援記
憶装置（この場合はＬＤＡＰローカル・バックエンド）
との相互作用の責任を負うデータ・オブジェクトに使用
されるものが含まれる。

【０２１０】ＬＤＡＰローカル・バックエンドは、ＬＤ
ＡＰサーバ関数が、関連するＬＤＡＰクライアント関数
を呼び出したものと同一の作業単位の下で実行できるよ
うにする。そうすることによって、ＲＲＳコンテキスト
情報を、ネーム・サーバからＬＤＡＰを介して、たとえ
ばＤＢ２データベースに移行することができる。ローカ
ル・バックエンド２３０５の詳細を、下でさらに説明す
る。

【０２１１】具体的に言うと、本発明の一態様によれ
ば、ＬＤＡＰサーバ・コードは、ＬＤＡＰクライアント
・コードに対してローカルに走行することを許可され
る。したがって、クライアント・コードとサーバ・コー
ドは、ネットワーク・フローを迂回できるようにする変
更と共に一緒にパッケージ化される。

【０２１２】たとえば、ＯＲＢが、トランザクショナル
・コンテキストを確立する。その後、ネーミング・デー
タ・オブジェクトが、制御を受け取り、ＬＤＡＰクライ
アント・インターフェース・コードおよびＬＤＡＰサー
バ・コード（同一のサーバに常駐する）などのＬＤＡＰ
インターフェースを呼び出す。その後、ＤＢ２が、たと
えばトランザクショナル・コンテキストを取り出す。

【０２１３】この配置では、ネーミング・データ・オブ
ジェクトなどの呼出し元が、ＬＤＡＰクライアント・イ
ンターフェース・コードを呼び出す。クライアント・イ
ンターフェース・コードは、アウトバウンドのネットワ
ークに行かずに、ＬＤＡＰサーバ・コードを直接呼び出
す。したがって、ネーミング・データ・オブジェクト、
ＬＤＡＰクライアント・コード、ＬＤＡＰサーバ・コー
ドおよびＤＢ２への呼出しが、同一の作業単位の下で走
行することになる。したがって、ＤＢ２は、ＬＤＡＰク
ライアント・コードが呼び出される前にＯＲＢによって
確立されたトランザクショナル・コンテキストにアクセ
スすることができる（ＬＤＡＰは、「LDAP Server Admi
nistration and Usage Guide」、IBM Publication No.
SC24-5861-00（1998年1月）およびＤＳ．ＩＮＴＥＲＮ
ＩＣ．ＮＥＴ ＲＦＣ １７７７でさらに説明されてお
り、これらは、参照によってその全体を本明細書に組み
込まれる）。

【０２１４】トランザクショナル・ネーム・サーバが定
義される方法と操作される方法の詳細の一部を、さまざ
まな論理の流れに関して下で説明する。一例として、ト
ランザクショナル環境でのオブジェクト作成に関連する
制御の流れを、図２８に関して説明する。この例は、ネ
ーミング・オブジェクト（たとえば、ネーミング・コン
テキストまたはバインディング）の観点からのものであ
る。さらに、この例では、新しいネーミング・コンテキ
スト・オブジェクトが、本明細書に記載のbind_new_con
textメソッドを介して作成される。

【０２１５】まず、トランザクションは、たとえばクラ
イアントがbind_new_context呼出しを実行する時に開始
される（ステップ２４００）。コンテナが活性化され、
トランザクション・コンテキストが、実行のスレッドに
付加される。コンテナ活性化の一部として、２つの接続
オブジェクトが初期設定される。一方は、たとえば、ld
ap_openおよびldap_bindを呼び出すことによって、ＬＤ
ＡＰ資源マネージャとの接続をセット・アップする。こ
れらの呼出しの結果として、データ・オブジェクトがそ
の将来のＬＤＡＰとの相互作用に使用するハンドルが供
給される。初期設定される第２の接続オブジェクトは、
本明細書で前に説明したように進行する、ＲＲＳＡＦの
ための接続オブジェクトである。これを介して、ネーム
・サーバとの相互作用をトランザクショナル・スコープ
の下で実行できるようにする環境がセット・アップされ
る。ＤＢ２は、ＯＲＢが実行のスレッドに付加したトラ
ンザクショナル・コンテキストを収集することができ
る。ＬＤＡＰは、ネーミング・コンテキスト・データ・
オブジェクトが行うリクエストによってＤＢ２データを
管理する。このすべてがセット・アップされた後に、現
在実行中のネーミング・コンテキストに対して、bind_n
ew_contextメソッドがディスパッチされる。これによっ
て、本明細書で前に説明したように、新しいネーミング
・コンテキストのオブジェクト・キーが作成される。こ
のメソッドは、その後、Naming Contextホームに対して
createByPrimaryKeyStringを呼び出して、新しいオブジ
ェクトを作成させる。この処理の一部として、新しいデ
ータ・オブジェクトが作成される（ステップ２４０
２）。

【０２１６】さらに、ビジネス・オブジェクトが、作成
され、データ・オブジェクトに関連付けられる（ステッ
プ２４０４）。一例として、関連付けは、initForCreat
ionを呼び出すことによって実行される。省略時属性
が、データ・オブジェクトからビジネス・オブジェクト
にコピーされる。

【０２１７】データ・オブジェクトおよびビジネス・オ
ブジェクトの作成の後に、トランザクションがコミット
される（ステップ２４０６）。コミット中に、データ・
オブジェクトに対してinsertToDataStoreメソッドが呼
び出され、これによって、内部化されたキーに関連する
新しいディレクトリ項目（たとえばＬＤＡＰディレクト
リ・レコード）が作成される（ステップ２４０８）。具
体的に言うと、トランザクションがコミットされる時
に、insertToDataStoreが、ＬＤＡＰディレクトリ・サ
ービスのサービスを呼び出して、新しいディレクトリ項
目を作成する。このサービスは、この例ではldap_addで
ある。ＬＤＡＰは、項目を作成するために、下層のＤＢ
２データベースの適当な操作を実行する。データ・オブ
ジェクト、ＬＤＡＰおよび最終的なＤＢ２呼出しは、す
べてが同一の実行のスレッドの下で走行しており、した
がって、同一のトランザクショナル・コンテキストの下
で走行しているので、この名前空間の変更は、特定のト
ランザクションに関連する。

【０２１８】オブジェクトを作成した後には、そのオブ
ジェクトを取り出すことができる。既存オブジェクトの
取出に関連する制御の流れの一部は、オブジェクト作成
の流れに類似しており、したがって、上の説明ならびに
同一の図面である図２８に対する参照を行う。一例で
は、取出の流れは、既存ネーミング・コンテキストの活
性化の一部として発生する。

【０２１９】まず、トランザクションが開始される（ス
テップ２４００）。上で説明したように、データ・オブ
ジェクトならびにビジネス・オブジェクトが作成される
（ステップ２４０２）。ビジネス・オブジェクトは、デ
ータ・オブジェクトに関連付けられる（ステップ２４０
４）。この場合、ビジネス・オブジェクトは、initForR
eactivationを呼び出すことによって、データ・オブジ
ェクトに関連付けられる。

【０２２０】その後、データが取り出される。この場
合、データ・オブジェクトに対してretrieveFromDataSt
oreが呼び出され、これによって、データ・オブジェク
トが、ldap_searchを駆動し、ＬＤＡＰが、ＤＢ２と相
互作用してデータを取得する。

【０２２１】オブジェクトを取り出した後に、そのオブ
ジェクトを更新することができる。たとえば、更新は、
bindによって、バインディングが異なるアプリケーショ
ン・オブジェクトを指すように変更することとすること
ができる。挿入または取出の後のオブジェクト更新に関
連する制御の流れの一実施形態を、図２９に関して説明
する。更新のシナリオは、上で説明したシナリオに類似
する。

【０２２２】まず、クライアント（すなわち呼出し元）
が、ビジネス・オブジェクトの１つまたは複数の属性を
更新する（ステップ２５００）。その後、トランザクシ
ョンがコミットされる（ステップ２５０２）。コミット
処理の一部として、前準備でビジネス・オブジェクトに
対してinitForPassivationが呼び出され、これによっ
て、ビジネス・オブジェクトの属性がデータ・オブジェ
クトに流される（ステップ２５０４）。

【０２２３】さらに、コミット処理中に、属性が、upda
teToDataStoreを使用してＬＤＡＰディレクトリに渡さ
れる（ステップ２５０６）。updateToDataStoreは、Ｌ
ＤＡＰを呼び出し、ＬＤＡＰは、ＤＢ２と相互作用す
る。たとえば、ＬＤＡＰは、ＤＢ２などの資源マネージ
ャのデータ記憶域に属性を格納する（ステップ２５０
８）。

【０２２４】属性が格納された後に、ビジネス・オブジ
ェクトおよびデータ・オブジェクトが、メモリから削除
され（ステップ２５１０）、ＤＢ２が、準備およびコミ
ットの流れを受け取る（ステップ２５１２）。これによ
って、トランザクショナル・ネーム・サーバでのオブジ
ェクト更新が終了する。

【０２２５】オブジェクトの挿入または取出の後のオブ
ジェクトの削除に関連する制御の流れの一実施形態を、
図３０に関して説明する。まず、クライアントが、オブ
ジェクトに対してremoveメソッドを駆動し（ステップ２
６００）、トランザクションがコミットされる（ステッ
プ２６０２）。コミットの一部として、オブジェクトを
削除するために、ビジネス・オブジェクトに対してunin
itForDestructionが呼び出される（ステップ２６０
４）。さらに、ＬＤＡＰディレクトリ項目および関連す
るＤＢ２データが、データ・オブジェクトに対して呼び
出されるdeleteFromDataStoreを介して削除される（ス
テップ２６０６）。一例では、データオブジェクトは、
ldap_delete()を使用して削除を実行する。さらに、ビ
ジネス・オブジェクトおよびデータ・オブジェクトが、
メモリから削除され（ステップ２６０８）、ＤＢ２が、
準備およびコミットの流れを受け取る（ステップ２６１
０）。

【０２２６】上の制御の流れのそれぞれに、流れている
トランザクショナル・コンテキストがある。上で説明し
た制御の流れの中でトランザクショナル・コンテキスト
を流す方法の一実施形態を、図３１に関して説明する。

【０２２７】まず、クライアント（すなわち呼出し元）
が、トランザクションを作成し、トランザクション・コ
ンテキストが、ネーム・サーバとの対話を用いて流れる
（ステップ２７００）。すなわち、クライアントは、be
gin_tranを実行し、トランザクショナル・コンテキスト
は、本明細書で説明するように、メソッド呼び出しの一
部として流れる。トランザクション・コンテキストは、
ネーム・サーバ内で確立され、ビジネス・オブジェクト
／データ・オブジェクト対と関連付けられる（ステップ
２７０２）。

【０２２８】その後、トランザクショナル・コンテキス
トは、ＤＢ２テーブルに対する更新のためにＤＢ２によ
って取り出される（ステップ２７０４）。ＤＢ２は、ビ
ジネス・オブジェクト／データ・オブジェクト対を所有
するものと同一の作業単位の下で走行しているので、ト
ランザクショナル・コンテキストを取り出すことができ
る。

【０２２９】上で説明した機能を用いると、複数のネー
ミング・コンテキストおよびアプリケーション・オブジ
ェクトを、１つまたは複数のサーバ・インスタンス内で
原子的に操作することができる。次の例を考慮された
い。 １）トランザクションを開始する ２）ネーミング・コンテキストＡを作成する ３）アプリケーション・オブジェクトＢを作成する ４）アプリケーション・オブジェクトＣを作成する ５）ネーミング・コンテキストＡの下でアプリケーショ
ン・オブジェクトＢをバインドする ６）ネーミング・コンテキストＡの下でアプリケーショ
ン・オブジェクトＣをバインドする ７）トランザクションをコミットまたはロール・バック
する

【０２３０】メモリ内のオブジェクトの寿命のスコープ
は、トランザクションのスコープに関連するので、サー
バ複製が可能になる。所与のサーバ内でアクティブであ
るオブジェクトは、ロックされる。したがって、複製さ
れたサーバは、これらのロックが解放されるまでそのオ
ブジェクトにアクセスできない。

【０２３１】上で詳細に説明したのは、名前空間に対す
る複数の原子的更新を提供するトランザクショナル・ネ
ーム・サーバである。トランザクショナル・ネーム・サ
ーバは、有利なことに、サーバの可用性および性能特性
を改善するサーバ複製を可能にする。本発明のこの態様
によれば、コンポーネント・ブローカ機構が、ＬＤＡＰ
の特定のインプリメンテーションと共に使用されて、デ
ータ・オブジェクト、ＬＤＡＰおよびＤＢ２呼び出しが
同一の作業単位の下で走行できるようになる。これによ
って、名前空間に対する変更がトランザクショナルにな
る。上で説明したように、これには、バインディングま
たはネーミング・コンテキストの取出、新規作成また
は、既存バインディングまたはネーミング・コンテキス
トの変更が含まれる可能性がある。これは、さまざまな
機能強化につながった。たとえば、名前空間を初期設定
する時には、名前空間のセグメント全体を、単一のトラ
ンザクションのスコープの下で作成することができる。
この結果として、コミットが実行される時に、変更のす
べてが行われるか、全く行われないかのどちらかにな
る。これによって、処理が早すぎる段階で打ち切られた
場合であっても、矛盾した状態を有する部分的な名前空
間が作成される可能性が排除される。さらに、トランザ
クショナル名前空間を用いると、単一のトランザクショ
ンのスコープの下で、アプリケーション・オブジェクト
を作成し、そのリファレンスを名前空間に登録すること
ができるようになる。これによって、オブジェクト作成
と名前空間登録の間で処理が割り込まれ、孤立オブジェ
クトがもたらされるシナリオが、回避される。

【０２３２】上で詳細に説明したように、名前空間が提
供され、これがネーミング・コンテキスト・オブジェク
トを管理する。本発明の一態様では、名前空間２８００
（図３２）に、Life Cycle Repository（ＬＣＲ）２８
０２などのリポジトリも含まれる。Life Cycle Reposit
oryは、たとえば、名前空間のプライベート部分に配置
され、１組のファクトリを含む。

【０２３３】ファクトリは、クライアント（すなわち呼
出し元、ユーザ）に、新しいオブジェクト・インスタン
スを作成し、初期設定するための特化された動作を提供
する。GenericFactoryインターフェースが、Life Cycle
Serviceによって定義される。Life Cycle Serviceは、
オブジェクトの作成、削除、コピーおよび移動の規約を
定義する、ＯＭＧが設計したサービスの組である。これ
らのサービスを用いると、リモート・クライアントが、
異なる位置のオブジェクトに対してライフ・サイクル動
作を実行できるようになる。GenericFactoryは、作成サ
ービスとして働き、オブジェクト作成のための汎用動作
を提供する。そのような形でオブジェクトを作成するた
めに、クライアントは、ファクトリへのオブジェクト・
リファレンスを使用する。クライアントは、Naming Ser
vicesの使用を介するか、下で説明するLife Cycle Fact
oryFinderサービスの使用を介して、ファクトリ・オブ
ジェクト・リファレンスを得ることができる。さらに、
クライアントに、パラメータとしてファクトリ・オブジ
ェクトを渡すことができる。

【０２３４】オブジェクトの削除を望むクライアント
は、remove動作を発行する。そのような形でオブジェク
トを削除するためには、そのオブジェクトが、LifeCycl
eObjectインターフェースをサポートしなければならな
い。LifeCycleObjectインターフェースは、move動作とc
opy動作もサポートする。move動作とcopy動作は、Facto
ryFinderへのオブジェクト・リファレンスを渡される。
クライアントは、これによって、FactoryFinderのスコ
ープ内のファクトリを使用するオブジェクトの移動また
はコピーを指定する。

【０２３５】FactoryFinderは、find_factories動作を
サポートし、この動作は、指定された特性に合致するフ
ァクトリのシーケンスを返す。FactoryFinderが探索を
実行する対象のファクトリの組は、Life Cycle Reposit
oryに格納される。

【０２３６】オブジェクトは、その継承階層に従って複
数のインターフェースをサポートすることができる。図
３３では、継承関係２９００が、さまざまなインターフ
ェースＡないしＥの間に示されている。オブジェクト・
インプリメンテーション２９０２は、インターフェース
Ｅ（網掛け部分）のために供給される。そのインプリメ
ンテーションのインスタンスは、インターフェースＡな
いしＥのすべてをサポートする。解決しなければならな
い問題は、クライアントが、インプリメンテーションＥ
のインスタンスを作るファクトリを見つける判断基準と
してインターフェースＡないしＥのいずれかを使用して
いる可能性がある時に、クライアントがそのファクトリ
を突きとめられるようにする方法である。たとえば、ク
ライアントは、インターフェースＡの名前をFactoryFin
derに渡し、そのインターフェースをサポートする１つ
または複数のファクトリを受け取ることを期待する可能
性がある。インプリメンテーションＥのためのファクト
リは、返されるファクトリの中に含まれなければならな
い。さらに、インプリメンテーションＥのためのファク
トリは、クライアントがFactoryFinderにインターフェ
ースＡないしＥのいずれかの名前を渡した時に、返され
なければならない。

【０２３７】本発明の一態様によれば、特定のオブジェ
クト（たとえばオブジェクトＥ）のインプリメンテーシ
ョンのインスタンスを作るファクトリを突きとめるため
に、インターフェース名が、インプリメンテーションＥ
のファクトリに関してLife Cycle Repository内に登録
される。

【０２３８】インプリメンテーションＥのファクトリに
関する複数のインターフェースの登録に関連する論理の
一実施形態を、図３４に示す。まず、登録を実行するた
めにトランザクションが開始される（ステップ３００
０）。トランザクショナル作業単位内で、この例ではイ
ンプリメンテーションＥのファクトリが、インターフェ
ース名Ａの下で登録される（ステップ３００２）。具体
的に言うと、ファクトリ・オブジェクトが、名前Ａの下
で名前空間にバインドされる。

【０２３９】さらに、インプリメンテーションＥのファ
クトリが、インターフェース名Ｂ、Ｃ、ＤおよびＥの下
で登録される（ステップ３００４ないし３０１０）。そ
の後、トランザクションがコミットされる（ステップ３
０１２）（他の例では、インターフェースの数が異なる
場合がある。上記は、１つの例にすぎない）。

【０２４０】上の手順を使用することによって、特定の
インプリメンテーション（たとえばインプリメンテーシ
ョンＥ）のファクトリに関連するすべてのインターフェ
ース名が、Life Cycle Repositoryに登録される。これ
によって、ファクトリの検索の判断基準として使用され
るインターフェースがどれであっても、特定のインプリ
メンテーションのインスタンスを作るファクトリを突き
とめることができるようになる。

【０２４１】たとえば、従業員オブジェクトを作成する
ファクトリと、個人オブジェクトを作成する別のファク
トリがあると仮定する。さらに、人間を作成するすべて
のファクトリのリストが所望されると仮定する。本発明
のこの態様によれば、このリストには、従業員が人間な
ので従業員ファクトリが含まれ、個人ファクトリも含ま
れる。

【０２４２】上で説明したように、サーバ・システムに
は、さまざまなオブジェクトの管理に使用される１つま
たは複数のサーバ・インスタンスが含まれる。サーバ・
インスタンスに関する詳細を、本明細書でさらに説明す
る。具体的に言うと、本発明の一態様によれば、保全性
（すなわち信頼性）、特権アプリケーションと非特権ア
プリケーションの間のアプリケーション分離、機能強化
されたトランザクション回復時間（すなわち、再始動／
回復スケーラビリティ）および効果的な作業負荷管理を
提供するサーバ・インスタンスが、設けられる。そのよ
うなサーバ・インスタンスの一実施形態を、図３５に関
して説明する。

【０２４３】本発明の一態様では、サーバ・インスタン
ス３１００に、たとえば、１つまたは複数の制御領域３
１０２と１つまたは複数のサーバ領域３１０４が含まれ
る。制御領域３１０２は、特権モードで実行されるアド
レス空間（１つまたは複数のサーバ領域アドレス空間か
ら分離された、別の空間）である。この領域には、ユー
ザ作成アプリケーション・コードの常駐は全く提供しな
いが、１つまたは複数のサーバ領域で走行するアプリケ
ーションから保護されたさまざまな制御機能を提供す
る。制御領域で提供される制御機能の１つに、たとえ
ば、セキュリティ証明書の処理が含まれる。インバウン
ド・リクエストのセキュリティ・コンテキストおよびト
ランザクショナル・コンテキストをマッピングするのに
必要な状態情報のほとんどが、制御領域内で管理され
る。

【０２４４】一例として、制御領域３１０２には、クラ
イアント３１０８などのクライアントと通信し、ＯＴＳ
３１１０、ＲＲＳ３１１２および作業負荷マネージャ３
１１４に結合されるＯＲＢ３１０６が含まれる。

【０２４５】サーバ領域３１０４は、非特権アプリケー
ション・コードの実行に使用されるアドレス空間であ
る。この領域は、１つまたは複数のコンテナ３１１６、
１つまたは複数のビジネス・オブジェクト３１１８およ
び１つまたは複数のデータ・オブジェクト３１２０のホ
ームであり、データ・オブジェクト３１２０は、少なく
とも１つの資源マネージャ３１２１と通信する。さら
に、サーバ領域３１０４には、制御領域のＯＲＢ３１０
６と通信し、ＯＴＳ３１２４、ＲＲＳ３１２６および作
業負荷マネージャ３１２８に結合されたＯＲＢ３１２２
が含まれる。これは、アプリケーション処理が行われる
場所である。サーバ領域は、作業負荷平衡化をもたらす
ために複製することができる。

【０２４６】ＯＲＢ３１０６および３１２２は、別々に
図示されているが、同一のサーバ・インスタンス内に配
置されるので、論理的には１つのＯＲＢである。同様
に、ＯＴＳ３１１０および３１２４は、論理的に同一で
あり、ＲＲＳ３１１２および３１２６と、作業負荷マネ
ージャ３１１４および３１２８も論理的に同一である。

【０２４７】特権機能と非特権機能をサーバ・インスタ
ンス内の別々のアドレス空間に分離することによって、
通常の単一アドレス空間サーバ・インスタンスが提供し
ない、保全性と分離がもたらされる。具体的に言うと、
ビジネス・アプリケーションの実行時コンポーネントと
実行空間の両方を含む単一アドレス空間構造では、エン
タープライズ・クラス・アプリケーションに必要なレベ
ルの保全性と分離が提供されない。そのような実行空間
では、エラーがあるか挙動の誤っているアプリケーショ
ン・コードが、保全性露出またはサーバの障害のいずれ
かを引き起こす形で実行時の状態を変更することが希で
はない。クリティカルな実行時状態の例には、共用ディ
スパッチ待ち行列、セキュリティ・コンテキスト、トラ
ンザクショナル・コンテキスト、作業負荷管理コンテキ
スト、および、アプリケーション・サーバの管理および
実行に必要な他の実行時状態が含まれる。セキュリティ
・コンテキストを処理する場合、状態データの変更の可
能性が存在する場合の、アプリケーションが走行してい
るものと同一のドメインでのセキュリティ関連データの
露出の問題は、システムの重大なセキュリティ露出を表
す。

【０２４８】さらに、通常の単一プロセス・サーバ構造
では、複数のトランザクションの下で実行中の複数のユ
ーザのスケジューリングを、複数の実行のスレッド上で
同一の仮想メモリ空間にディスパッチすることが可能に
なる。この手法は、あるトランザクションの下で走行す
るアプリケーションが、異なるトランザクションの下で
走行するアプリケーションの状態に影響することがで
き、これによって、分離というトランザクションの原理
が侵害される環境がもたらされる。

【０２４９】しかし、本発明の一態様によれば、サーバ
・インスタンスを、２つのディスパッチ方針のうちの１
つを用いて構成することができる。第１のディスパッチ
方針では、所与のバックエンド・サーバ領域が、マルチ
スレッド・サーバ領域内の実行のスレッドごとに１つの
複数のトランザクショナル作業単位で走行する複数のク
ライアント・リクエストを受け入れることを可能にす
る。この方針は、ＣＩＣＳシステム内で実行される種類
のディスパッチを非常によく表すので、「ＣＩＣＳ様」
と称する。この種のディスパッチ方針を用いると、複数
のトランザクションが、同時にサーバ領域アドレス空間
内で走行している可能性があるので、トランザクション
・アプリケーション間の分離がもたらされない。

【０２５０】ディスパッチ方針の第２の選択肢では、所
与のサーバ領域への作業のスケジューリングを制限し、
その結果、所与の時点で、サーバ領域内で１つのトラン
ザクショナル作業単位内で走行するユーザが多くとも１
つになるようにする。この方針選択肢を、「ＩＭＳ様」
スケジューリングと称する。この第２の選択肢は、より
多くの物理アドレス空間を消費するが、所望のトランザ
クションの分離および整合性を提供する。

【０２５１】単一アドレス空間サーバ・インスタンスの
もう１つの短所は、劣悪なトランザクション回復時間で
ある。分散アプリケーション・サーバが、トランザクシ
ョナル回復単位の下で作業を管理する能力を提供する場
合、そのサーバは、障害の場合に周知の回復処置を提供
することもしなければならない。サーバ障害の後の回復
の一部が、障害の時点で動作中であった分散通信チャネ
ルの再確立である。この回復処置は、それ以上の回復処
置が必要または所望されるか否かを判定するのに使用さ
れる。さらに、障害の時点でのサーバ内のトランザクシ
ョンの状態に関する情報を提供するトランザクション・
ログが、読み取られる。このログは、通常は、障害が発
生したサーバ・アドレス空間に結び付けられている。こ
れは、すべてのアドレス空間を再始動し、そのトランザ
クション・ログを再生し、それ以上の処置が必要である
かどうかを判定しなければならないことを意味する。シ
ステム内のサーバ・アドレス空間の数が増えるにつれ
て、再始動時間が、システムの効率的で応答性のよい回
復の阻害要因になる。

【０２５２】しかし、本発明のこの態様のサーバ構造に
よれば、回復可能な資源は、ＤＢ２などのバックエンド
資源マネージャまたは制御領域のいずれかに常駐する。
トランザクショナル回復に参加する必要がある資源は、
サーバ領域内には存在しない。これは、システム障害の
後に、サーバ領域を再始動し、回復に参加させる必要が
ないことを意味する。回復可能なオブジェクト指向資源
は、制御領域に関連するので、障害の後で再始動する必
要があるのは制御領域だけであり、再始動時間とスケー
ラビリティが大幅に改善される。

【０２５３】International Business Machines Corpor
ation（米国ニューヨーク州アーモンク）が提供するＭ
ＶＳシステムなどの多くのシステムでは、ディスパッチ
優先順位、メモリ管理、入出力優先順位待ち行列管理な
どに関する作業負荷管理決定が、アドレス空間レベルで
行われる。アドレス空間は、これらの資源を適当な粒度
で管理できる、都合のよいホームである。複数の異なる
性能クラスの組の下で作業をサービスするのに単一アド
レス空間が使用される場合、作業負荷管理方針の望まし
くない平均化が生じる可能性がある。というのは、作業
負荷管理が、アドレス空間で走行中のすべての作業につ
いてそのアドレス空間レベルで調整を行うからである。
したがって、本発明の一態様によれば、複数の作業負荷
管理待ち行列３１３０が、サーバ領域の作業負荷を平衡
化するために作業負荷マネージャ３１１４によって使用
される。たとえば、作業負荷マネージャは、類似する性
能目標を有する作業を、待ち行列のそれぞれでグループ
化し、所与のサーバ領域へのその作業のディスパッチを
引き起こすことができる。具体的に言うと、サーバ領域
が作業を受け入れることができる時に、その領域のＯＲ
Ｂが、そのめいめいの待ち行列からの作業を、処理され
る領域にプルする。

【０２５４】上の手法を用いると、作業負荷マネージャ
は、異なるクラスの作業を、異なる物理アドレス空間に
またがって効率的に区分し、その結果、単一アドレス空
間システムのように望ましくない性能目標管理の平均化
が発生することがなくなる。さらに、上の手法を用いる
と、作業負荷マネージャは、上にリストしたものなどの
作業負荷管理判断基準に基づいて、サーバ領域の数を動
的に拡大または縮小することができる。

【０２５５】上で説明したサーバ・インスタンスのイン
プリメンテーションでは、領域のうちの１つのビジネス
・オブジェクトが、別のサーバ・インスタンスのビジネ
ス・オブジェクトとの通信を望む場合に、そのビジネス
・オブジェクトは、アウトバウンド・オブジェクト・リ
クエストを流し、このリクエストは、ＯＲＢ３１２２か
らＯＲＢ３１０６へリンクを介して進む。一例では、こ
のリンクは、参照によってその全体を本明細書に組み込
まれる「Enterprise Systems Architecture/390 Princi
ples of Operation」、IBM Publication No. SA22-7201
-05（1998年9月）に詳細に記載されたＯＳ／３９０仮想
記憶間機構に基づく。その後、ＯＲＢ３１０６が、ター
ゲット・サーバと通信する。

【０２５６】上で詳細に説明したのは、信頼性があり、
保護され、トランザクショナルであり、作業負荷が管理
されるオブジェクト指向コンピューティング環境をもた
らす、本発明の諸態様である。

【０２５７】本発明は、たとえばコンピュータ使用可能
媒体を有する製造品（たとえば１つまたは複数のコンピ
ュータ・プログラム製品）に含めることができる。この
媒体は、その中に、たとえば、本発明の機能を提供し、
容易にするためのコンピュータ可読プログラム・コード
手段を実施される。この製造品は、コンピュータ・シス
テムの一部として含めるか、別々に販売することができ
る。

【０２５８】さらに、本発明の機能を実行するために機
械によって実行可能な少なくとも１つの命令のプログラ
ムを具体的に実施する、機械によって読み取ることので
きる少なくとも１つのプログラム記憶装置を提供するこ
とができる。

【０２５９】本明細書で示した流れ図は、例示にすぎな
い。本発明の主旨から逸脱しない、これらの図またはそ
れらに記載のステップ（または動作）に対する多数のさ
まざまな変形形態がありえる。たとえば、ステップを異
なる順序で実行することができ、ステップの追加、削除
または変更が可能である。これらの変形形態のすべて
が、請求される発明の一部とみなされる。

【０２６０】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０２６１】（１）サーバ・インスタンスによって、前
記サーバ・インスタンス内でディスパッチされるオブジ
ェクトの１つまたは複数の属性を要求するステップと、
前記１つまたは複数の属性の取得に使用されるロッキン
グ、セキュリティ制御、マルチシステム・キャッシング
およびコミットメント制御のうちの少なくとも１つが、
前記サーバ・インスタンスに結合された少なくとも１つ
の資源マネージャによって実行される、前記１つまたは
複数の属性を取得するステップとを含む、コンピューテ
ィング環境内でオブジェクトを管理する方法。 （２）ロッキング、セキュリティ制御、マルチシステム
・キャッシングおよびコミットメント制御のうちの少な
くとも１つに関する責任が、前記サーバ・インスタンス
のコンテナから除去され、前記少なくとも１つの資源マ
ネージャに委譲される、上記（１）に記載の方法。 （３）前記少なくとも１つの資源マネージャのうちの１
つの資源マネージャが、ＤＢ２である、上記（１）に記
載の方法。 （４）前記サーバ・インスタンス内に配置される１つま
たは複数の接続オブジェクトを使用して、前記サーバ・
インスタンスを、前記少なくとも１つの資源マネージャ
のうちの１つまたは複数の資源マネージャに結合するス
テップをさらに含む、上記（１）に記載の方法。 （５）少なくとも１つのオブジェクト管理機能の責任
を、前記コンピューティング環境の少なくとも１つのコ
ンテナから除去するステップと、ロッキング、セキュリ
ティ制御、マルチシステム・キャッシングおよびコミッ
トメント制御を含む前記少なくとも１つのオブジェクト
管理機能の前記責任を、前記少なくとも１つのコンテナ
に結合された少なくとも１つの資源マネージャに委譲す
るステップとを含む、コンピューティング環境内でオブ
ジェクトを管理する方法。 （６）前記委譲するステップが、実行のスレッド上で１
つまたは複数のコンテキストをセット・アップするステ
ップと、前記少なくとも１つの資源マネージャによる前
記責任の実行に使用するために、前記少なくとも１つの
資源マネージャによって前記１つまたは複数のコンテキ
ストを取得するステップとを含む、上記（５）に記載の
方法。 （７）前記コンピューティング環境内に配置される１つ
または複数の接続オブジェクトを介して、前記少なくと
も１つの資源マネージャのうちの１つまたは複数の資源
マネージャを、前記少なくとも１つのコンテナのうちの
１つまたは複数のコンテナに結合するステップをさらに
含む、上記（６）に記載の方法。 （８）サーバ・インスタンスによって、前記サーバ・イ
ンスタンス内でディスパッチされるオブジェクトの１つ
または複数の属性を要求するための手段と、前記１つま
たは複数の属性の取得に使用されるロッキング、セキュ
リティ制御、マルチシステム・キャッシングおよびコミ
ットメント制御のうちの少なくとも１つが、前記サーバ
・インスタンスに結合された少なくとも１つの資源マネ
ージャによって実行される、前記１つまたは複数の属性
を取得するための手段とを含む、コンピューティング環
境内でオブジェクトを管理するシステム。 （９）ロッキング、セキュリティ制御、マルチシステム
・キャッシングおよびコミットメント制御のうちの少な
くとも１つに関する責任が、前記サーバ・インスタンス
のコンテナから除去され、前記少なくとも１つの資源マ
ネージャに委譲される、上記（８）に記載のシステム。 （１０）前記サーバ・インスタンス内に配置される１つ
または複数の接続オブジェクトを使用して、前記サーバ
・インスタンスを、前記少なくとも１つの資源マネージ
ャのうちの１つまたは複数の資源マネージャに結合する
ための手段をさらに含む、上記（８）に記載のシステ
ム。 （１１）少なくとも１つのオブジェクト管理機能の責任
を、コンピューティング環境の少なくとも１つのコンテ
ナから除去するための手段と、ロッキング、セキュリテ
ィ制御、マルチシステム・キャッシングおよびコミット
メント制御を含む前記少なくとも１つのオブジェクト管
理機能の前記責任を、前記少なくとも１つのコンテナに
結合された少なくとも１つの資源マネージャに委譲する
ための手段とを含む、コンピューティング環境内でオブ
ジェクトを管理するシステム。 （１２）前記委譲するための手段が、実行のスレッド上
で１つまたは複数のコンテキストをセット・アップする
ための手段と、前記少なくとも１つの資源マネージャに
よる前記責任の実行に使用するために、前記少なくとも
１つの資源マネージャによって前記１つまたは複数のコ
ンテキストを取得するための手段とを含む、上記（１
１）に記載のシステム。 （１３）前記コンピューティング環境内に配置される１
つまたは複数の接続オブジェクトを介して、前記少なく
とも１つの資源マネージャのうちの１つまたは複数の資
源マネージャを、前記少なくとも１つのコンテナのうち
の１つまたは複数のコンテナに結合するための手段をさ
らに含む、上記（１２）に記載のシステム。 （１４）サーバ・インスタンス内でディスパッチされる
オブジェクトの１つまたは複数の属性を要求するように
適合された前記サーバ・インスタンスを含み、前記サー
バ・インスタンスが、前記１つまたは複数の属性を取得
するように適合され、前記１つまたは複数の属性の取得
に使用されるロッキング、セキュリティ制御、マルチシ
ステム・キャッシングおよびコミットメント制御のうち
の少なくとも１つが、前記サーバ・インスタンスに結合
された少なくとも１つの資源マネージャによって実行さ
れるコンピューティング環境内でオブジェクトを管理す
るシステム。 （１５）コンピューティング環境内でオブジェクトの管
理を引き起こすためのコンピュータ可読プログラム・コ
ード手段をその中で実施された少なくとも１つのコンピ
ュータ使用可能媒体を含み、前記コンピュータ可読プロ
グラム・コード手段が、コンピュータに、サーバ・イン
スタンスによって、前記サーバ・インスタンス内でディ
スパッチされるオブジェクトの１つまたは複数の属性を
要求させるためのコンピュータ可読プログラム・コード
手段と、コンピュータに、前記１つまたは複数の属性を
取得させるためのコンピュータ可読プログラム・コード
手段であって、前記１つまたは複数の属性の取得に使用
されるロッキング、セキュリティ制御、マルチシステム
・キャッシングおよびコミットメント制御のうちの少な
くとも１つが、前記サーバ・インスタンスに結合された
少なくとも１つの資源マネージャによって実行される、
前記コンピュータ可読プログラム・コード手段とを含
む、製造品。 （１６）ロッキング、セキュリティ制御、マルチシステ
ム・キャッシングおよびコミットメント制御のうちの少
なくとも１つに関する責任が、前記サーバ・インスタン
スのコンテナから除去され、前記少なくとも１つの資源
マネージャに委譲される、上記（１５）に記載の製造
品。 （１７）コンピュータに、前記サーバ・インスタンス内
に配置される１つまたは複数の接続オブジェクトを使用
して、前記サーバ・インスタンスを、前記少なくとも１
つの資源マネージャのうちの１つまたは複数の資源マネ
ージャに結合させるためのコンピュータ可読プログラム
・コード手段をさらに含む、上記（１５）に記載の製造
品。 （１８）コンピューティング環境内でオブジェクトを管
理するための方法を実行するために機械によって実行可
能な命令の少なくとも１つのプログラムを具体的に実施
する、機械によって読取可能な少なくとも１つのプログ
ラム記憶装置であって、前記方法が、少なくとも１つの
オブジェクト管理機能の責任を、前記コンピューティン
グ環境の少なくとも１つのコンテナから除去するステッ
プと、ロッキング、セキュリティ制御、マルチシステム
・キャッシングおよびコミットメント制御を含む前記少
なくとも１つのオブジェクト管理機能の前記責任を、前
記少なくとも１つのコンテナに結合された少なくとも１
つの資源マネージャに委譲するステップとを含む、少な
くとも１つのプログラム記憶装置。 （１９）前記委譲するステップが、実行のスレッド上で
１つまたは複数のコンテキストをセット・アップするス
テップと、前記少なくとも１つの資源マネージャによる
前記責任の実行に使用するために、前記少なくとも１つ
の資源マネージャによって前記１つまたは複数のコンテ
キストを取得するステップとを含む、上記（１８）に記
載の少なくとも１つのプログラム記憶装置。 （２０）前記方法がさらに、前記コンピューティング環
境内に配置される１つまたは複数の接続オブジェクトを
介して、前記少なくとも１つの資源マネージャのうちの
１つまたは複数の資源マネージャを、前記少なくとも１
つのコンテナのうちの１つまたは複数のコンテナに結合
するステップを含む、上記（１９）に記載の少なくとも
１つのプログラム記憶装置。

【図面の簡単な説明】

【図１】本発明の機能を組み込み、使用する、コンピュ
ーティング環境の一例を示す図である。

【図２】本発明の原理による、管理オブジェクトの一例
を示す図である。

【図３】本発明の原理に従って使用される、インタオペ
ラブル・オブジェクト・リファレンスの一例を示す図で
ある。

【図４】本発明の原理による、サーバ・インスタンス内
に配置されるローカル・アクセス・プロキシの一例を示
す図である。

【図５】本発明の原理による、ターゲット・オブジェク
ト用ローカル・アクセス・プロキシの作成に関連する論
理の一実施形態を示す図である。

【図６】本発明の原理による、ターゲット・オブジェク
ト用ローカル・アクセス・プロキシの作成に関連する論
理の一実施形態を示す図である。

【図７】本発明の原理による、特定のサーバ・インスタ
ンスのコンテナに関連する方針セットの一例を示す図で
ある。

【図８】本発明の原理による、管理オブジェクトの活性
化に関連する論理の一実施形態を示す図である。

【図９】本発明の原理による、管理オブジェクトの活性
化に関連する論理の一実施形態を示す図である。

【図１０】本発明の原理による、サーバ・インスタンス
に結合されたオブジェクト・トランザクション・サービ
スおよび資源回復サービスの一例を示す図である。

【図１１】本発明の原理による、オブジェクトを管理す
るコンテナの一例を示す図である。

【図１２】コンテナに関連し、本発明の原理に従って使
用される、接続オブジェクトの一例を示す図である。

【図１３】本発明の原理による、サーバ・インスタンス
のコンポーネントのもう１つの例を示す図である。

【図１４】本発明の原理に従って使用される、合成され
たコンテナおよび合成されたデータ・オブジェクトの一
例を示す図である。

【図１５】本発明の機能を使用する、マルチシステム環
境の一例を示す図である。

【図１６】本発明の原理に従って使用される、ロケーシ
ョン・サービス・エージェントの追加を伴う図１５のマ
ルチシステム環境を示す図である。

【図１７】本発明の原理による、特定のタスクを実行す
るための適当なサーバ・インスタンスの選択に関連する
論理の一例を示す図である。

【図１８】本発明の原理による、所与の作業単位が適当
なサーバ・インスタンスに到達することの保証に関連す
る論理の一実施形態を示す図である。

【図１９】本発明の原理による、分散名前空間の一例を
示す図である。

【図２０】本発明の原理による、非分散名前空間の一例
を示す図である。

【図２１】本発明の原理による、名前空間内のネーミン
グ・コンテキストの階層の一例を示す図である。

【図２２】本発明の原理による、管理オブジェクトのコ
ンポーネントに関連する継承関係および委譲関係の一例
を示す図である。

【図２３】本発明の原理による、異なる資源マネージャ
によってバッキングされる異なるネーミング・コンテキ
ストの概略図の一例を示す図である。

【図２４】本発明の原理による、乖離バインディングの
処理に関連する論理の一実施形態を示す図である。

【図２５】本発明の原理による、オブジェクトの識別へ
のＣＯＲＢＡ名のマッピングに関連する論理の一実施形
態を示す図である。

【図２６】本発明の原理による、新規オブジェクトの主
キーの作成に関連する論理の一実施形態を示す図であ
る。

【図２７】本発明の原理による、トランザクショナル・
ネーム・サーバの一実施形態を示す図である。

【図２８】本発明の原理による、トランザクショナル・
ネーム・サーバのオブジェクトの作成に関連する論理の
一実施形態を示す図である。

【図２９】本発明の原理による、トランザクショナル・
ネーム・サーバのオブジェクトの更新に関連する論理の
一実施形態を示す図である。

【図３０】本発明の原理による、トランザクショナル・
ネーム・サーバのオブジェクトの削除に関連する論理の
一実施形態を示す図である。

【図３１】本発明の原理による、トランザクショナル・
コンテキストの流れの一実施形態を示す図である。

【図３２】本発明の原理に従って使用される、ライフ・
サイクル・リポジトリを含む名前空間の一実施形態を示
す図である。

【図３３】本発明の原理による、さまざまなインターフ
ェースの間の継承関係の一例を示す図である。

【図３４】本発明の原理による、特定のインプリメンテ
ーションのための複数のインターフェースの登録に関連
する論理の一実施形態を示す図である。

【図３５】本発明の原理による、サーバ制御領域および
１つまたは複数のサーバ領域を含む、サーバ・インスタ
ンスの一実施形態を示す図である。

【符号の説明】

１００ コンピューティング環境 １０２ サーバ・システム １０４ クライアント・システム １０６ コンポーネント・ブローカ実行時サービス １０８ 資源マネージャ １１０ オペレーティング・システム １１２ 外部記憶装置 １１４ サーバ・インスタンス １１６ オブジェクト １１８ コンテナ １２０ オブジェクト・リクエスト・ブローカ（ＯＲ
Ｂ） １２８ クライアント １３０ オペレーティング・システム １３２ アプリケーション １３４ リモート・アクセス・プロキシ・オブジェクト １３６ クライアント・オブジェクト・リクエスト・ブ
ローカ（ＯＲＢ） １３８ ＴＣＰ／ＩＰ接続

───────────────────────────────────────────────────── フロントページの続き (72)発明者 キャロル・イー・ファルカーソン・ジュニ ア アメリカ合衆国27603 ノースカロライナ 州ラーレー ウォルヴァーハンプトン・ド ライブ 6129 (72)発明者 ロドニー・エイ・リトル アメリカ合衆国12603 ニューヨーク州ポ キプシー ジェイ・ロード １ (72)発明者 ゲアリー・エス・プチコフ アメリカ合衆国12603 ニューヨーク州ポ キプシー ハート・ドライブ 36

Claims (20)

【特許請求の範囲】
1. 【請求項１】サーバ・インスタンスによって、前記サー
   バ・インスタンス内でディスパッチされるオブジェクト
   の１つまたは複数の属性を要求するステップと、 前記１つまたは複数の属性の取得に使用されるロッキン
   グ、セキュリティ制御、マルチシステム・キャッシング
   およびコミットメント制御のうちの少なくとも１つが、
   前記サーバ・インスタンスに結合された少なくとも１つ
   の資源マネージャによって実行される、前記１つまたは
   複数の属性を取得するステップとを含む、コンピューテ
   ィング環境内でオブジェクトを管理する方法。
2. 【請求項２】ロッキング、セキュリティ制御、マルチシ
   ステム・キャッシングおよびコミットメント制御のうち
   の少なくとも１つに関する責任が、前記サーバ・インス
   タンスのコンテナから除去され、前記少なくとも１つの
   資源マネージャに委譲される、請求項１に記載の方法。
3. 【請求項３】前記少なくとも１つの資源マネージャのう
   ちの１つの資源マネージャが、ＤＢ２である、請求項１
   に記載の方法。
4. 【請求項４】前記サーバ・インスタンス内に配置される
   １つまたは複数の接続オブジェクトを使用して、前記サ
   ーバ・インスタンスを、前記少なくとも１つの資源マネ
   ージャのうちの１つまたは複数の資源マネージャに結合
   するステップをさらに含む、請求項１に記載の方法。
5. 【請求項５】少なくとも１つのオブジェクト管理機能の
   責任を、前記コンピューティング環境の少なくとも１つ
   のコンテナから除去するステップと、 ロッキング、セキュリティ制御、マルチシステム・キャ
   ッシングおよびコミットメント制御を含む前記少なくと
   も１つのオブジェクト管理機能の前記責任を、前記少な
   くとも１つのコンテナに結合された少なくとも１つの資
   源マネージャに委譲するステップとを含む、コンピュー
   ティング環境内でオブジェクトを管理する方法。
6. 【請求項６】前記委譲するステップが、 実行のスレッド上で１つまたは複数のコンテキストをセ
   ット・アップするステップと、 前記少なくとも１つの資源マネージャによる前記責任の
   実行に使用するために、前記少なくとも１つの資源マネ
   ージャによって前記１つまたは複数のコンテキストを取
   得するステップとを含む、請求項５に記載の方法。
7. 【請求項７】前記コンピューティング環境内に配置され
   る１つまたは複数の接続オブジェクトを介して、前記少
   なくとも１つの資源マネージャのうちの１つまたは複数
   の資源マネージャを、前記少なくとも１つのコンテナの
   うちの１つまたは複数のコンテナに結合するステップを
   さらに含む、請求項６に記載の方法。
8. 【請求項８】サーバ・インスタンスによって、前記サー
   バ・インスタンス内でディスパッチされるオブジェクト
   の１つまたは複数の属性を要求するための手段と、 前記１つまたは複数の属性の取得に使用されるロッキン
   グ、セキュリティ制御、マルチシステム・キャッシング
   およびコミットメント制御のうちの少なくとも１つが、
   前記サーバ・インスタンスに結合された少なくとも１つ
   の資源マネージャによって実行される、前記１つまたは
   複数の属性を取得するための手段とを含む、コンピュー
   ティング環境内でオブジェクトを管理するシステム。
9. 【請求項９】ロッキング、セキュリティ制御、マルチシ
   ステム・キャッシングおよびコミットメント制御のうち
   の少なくとも１つに関する責任が、前記サーバ・インス
   タンスのコンテナから除去され、前記少なくとも１つの
   資源マネージャに委譲される、請求項８に記載のシステ
   ム。
10. 【請求項１０】前記サーバ・インスタンス内に配置され
    る１つまたは複数の接続オブジェクトを使用して、前記
    サーバ・インスタンスを、前記少なくとも１つの資源マ
    ネージャのうちの１つまたは複数の資源マネージャに結
    合するための手段をさらに含む、請求項８に記載のシス
    テム。
11. 【請求項１１】少なくとも１つのオブジェクト管理機能
    の責任を、コンピューティング環境の少なくとも１つの
    コンテナから除去するための手段と、 ロッキング、セキュリティ制御、マルチシステム・キャ
    ッシングおよびコミットメント制御を含む前記少なくと
    も１つのオブジェクト管理機能の前記責任を、前記少な
    くとも１つのコンテナに結合された少なくとも１つの資
    源マネージャに委譲するための手段とを含む、コンピュ
    ーティング環境内でオブジェクトを管理するシステム。
12. 【請求項１２】前記委譲するための手段が、 実行のスレッド上で１つまたは複数のコンテキストをセ
    ット・アップするための手段と、 前記少なくとも１つの資源マネージャによる前記責任の
    実行に使用するために、前記少なくとも１つの資源マネ
    ージャによって前記１つまたは複数のコンテキストを取
    得するための手段とを含む、請求項１１に記載のシステ
    ム。
13. 【請求項１３】前記コンピューティング環境内に配置さ
    れる１つまたは複数の接続オブジェクトを介して、前記
    少なくとも１つの資源マネージャのうちの１つまたは複
    数の資源マネージャを、前記少なくとも１つのコンテナ
    のうちの１つまたは複数のコンテナに結合するための手
    段をさらに含む、請求項１２に記載のシステム。
14. 【請求項１４】サーバ・インスタンス内でディスパッチ
    されるオブジェクトの１つまたは複数の属性を要求する
    ように適合された前記サーバ・インスタンスを含み、 前記サーバ・インスタンスが、前記１つまたは複数の属
    性を取得するように適合され、前記１つまたは複数の属
    性の取得に使用されるロッキング、セキュリティ制御、
    マルチシステム・キャッシングおよびコミットメント制
    御のうちの少なくとも１つが、前記サーバ・インスタン
    スに結合された少なくとも１つの資源マネージャによっ
    て実行されるコンピューティング環境内でオブジェクト
    を管理するシステム。
15. 【請求項１５】コンピューティング環境内でオブジェク
    トの管理を引き起こすためのコンピュータ可読プログラ
    ム・コード手段をその中で実施された少なくとも１つの
    コンピュータ使用可能媒体を含み、前記コンピュータ可
    読プログラム・コード手段が、 コンピュータに、サーバ・インスタンスによって、前記
    サーバ・インスタンス内でディスパッチされるオブジェ
    クトの１つまたは複数の属性を要求させるためのコンピ
    ュータ可読プログラム・コード手段と、 コンピュータに、前記１つまたは複数の属性を取得させ
    るためのコンピュータ可読プログラム・コード手段であ
    って、前記１つまたは複数の属性の取得に使用されるロ
    ッキング、セキュリティ制御、マルチシステム・キャッ
    シングおよびコミットメント制御のうちの少なくとも１
    つが、前記サーバ・インスタンスに結合された少なくと
    も１つの資源マネージャによって実行される、前記コン
    ピュータ可読プログラム・コード手段とを含む、製造
    品。
16. 【請求項１６】ロッキング、セキュリティ制御、マルチ
    システム・キャッシングおよびコミットメント制御のう
    ちの少なくとも１つに関する責任が、前記サーバ・イン
    スタンスのコンテナから除去され、前記少なくとも１つ
    の資源マネージャに委譲される、請求項１５に記載の製
    造品。
17. 【請求項１７】コンピュータに、前記サーバ・インスタ
    ンス内に配置される１つまたは複数の接続オブジェクト
    を使用して、前記サーバ・インスタンスを、前記少なく
    とも１つの資源マネージャのうちの１つまたは複数の資
    源マネージャに結合させるためのコンピュータ可読プロ
    グラム・コード手段をさらに含む、請求項１５に記載の
    製造品。
18. 【請求項１８】コンピューティング環境内でオブジェク
    トを管理するための方法を実行するために機械によって
    実行可能な命令の少なくとも１つのプログラムを具体的
    に実施する、機械によって読取可能な少なくとも１つの
    プログラム記憶装置であって、前記方法が、 少なくとも１つのオブジェクト管理機能の責任を、前記
    コンピューティング環境の少なくとも１つのコンテナか
    ら除去するステップと、 ロッキング、セキュリティ制御、マルチシステム・キャ
    ッシングおよびコミットメント制御を含む前記少なくと
    も１つのオブジェクト管理機能の前記責任を、前記少な
    くとも１つのコンテナに結合された少なくとも１つの資
    源マネージャに委譲するステップとを含む、少なくとも
    １つのプログラム記憶装置。
19. 【請求項１９】前記委譲するステップが、 実行のスレッド上で１つまたは複数のコンテキストをセ
    ット・アップするステップと、 前記少なくとも１つの資源マネージャによる前記責任の
    実行に使用するために、前記少なくとも１つの資源マネ
    ージャによって前記１つまたは複数のコンテキストを取
    得するステップとを含む、請求項１８に記載の少なくと
    も１つのプログラム記憶装置。
20. 【請求項２０】前記方法がさらに、前記コンピューティ
    ング環境内に配置される１つまたは複数の接続オブジェ
    クトを介して、前記少なくとも１つの資源マネージャの
    うちの１つまたは複数の資源マネージャを、前記少なく
    とも１つのコンテナのうちの１つまたは複数のコンテナ
    に結合するステップを含む、請求項１９に記載の少なく
    とも１つのプログラム記憶装置。