JP2000517453A

JP2000517453A - 分散型オブジェクト指向計算用システム開発ツール

Info

Publication number: JP2000517453A
Application number: JP11503411A
Authority: JP
Inventors: アンドリューアルバートザンダー; イアンアレクサンダーローズ
Original assignee: シトルプロプライエタリーリミテッド
Priority date: 1997-06-18
Filing date: 1998-06-17
Publication date: 2000-12-26
Also published as: EP0923761A1; CA2263571A1; WO1998058313A1

Abstract

(57)【要約】一般的には複数のクライアント（２６）と、複数のサーバー（２９）と、クライアントのサービスに関する要求をサーバーへ通信するための分散型オブジェクトインフラストラクチャ（２５）とを含む大規模分散型オブジェクト指向（ＬＳＤＯＯ）コンピューターシステムを造るための開発ツールである。本開発ツールは、予め定められたオブジェクト設計パターンを提供する一連のテンプレート（１２）と、コード発生器（１５）と、好ましくは基本的な分散型サービス（２１）とを含む。コード発生器（１５）は、クライアントプロセス（３２）により要求されるような所望のサーバープロセス（３３）を定義するため、及び設計パターンの中から選択されたものを組み込むためにユーザーにより作り出されたオブジェクト指向システムモデル（１１）から、分散型オブジェクトインフラストラクチャ（２５）からクライアントアプリケーションコードを分離するための、各クライアントプロセス用クライアントアクセスレイヤー（２７）と、分散型オブジェクトインフラストラクチャ（２５）からサーバーアプリケーションコードを分離させるための、各サーバープロセス用サーバーアクセスレイヤー（２８）と、ユーザーがサーバーセマンティックスのインプリメンテョンを統合するための規則を含む、各サービスを実行するためのサーバーアプリケーションコードのスタブ部（２９）とを生成するために配置されている。基本分散型サービスのセットは、システム内でファイルを複製するためのファイル複製サービス（３０）及びシステム内で利用可能なサービスの検索のためのサービスファインダーサービス（３１）を含んでいてもよい。

Description

【発明の詳細な説明】分散型オブジェクト指向計算用システム開発ツール発明の属する技術分野本発明は分散型オブジェクト指向計算システム、特に、大規模分散型オブジェクト指向システム（ＬＳＤＯＯ）に関する。このようなシステムは多くの機器、特に、ある種のビジネス機能を自律的に遂行するために協働する、コンピューターネットワーク上にリンクされた機器に関係するオブジェクトを有している。予想されるシステムのサイズのガイドラインは、典型的には、数百万乃至数億オブジェクト、１００乃至１０００人のユーザー、約１００乃至１０００の機器で毎秒合計１０００乃至５００００回の演算をする。発明の背景分散型オブジェクト指向（ＯＯ）技術は、コンピューターネットワーク上に搭載するアプリケーションの開発者に、彼らのアプリケーションを展開する際に多くの利用できる可能性のある利点を提供する。オブジェクト指向技術は、その中で複雑さと変化とを管理する、制御された環境を提供する。分散型計算を使用すれば、アプリケーションは、一方で万一ネットワークの一部が損傷を受けた場合でも回復力に優れた環境を提供しながら、広範な地理的領域に亘って作動することができる。概括すれば、ＬＳＤＯＯシステムは、（世界企業システムに迫る上端を持つ）１０のファクターで評価できる、最小のコストで受容できる信頼性を提供し、他のビジネスクリティカルシステムとの標準化された対話を支援し、単にデータの記憶に役立つだけでなくオペレーションを効率的に支援する。オブジェクト管理グループ会社(ＯＭＧ)、ソフトウェアベンダーのコンソーシアム、エンドユーザーにより開発されたこのようなシステムを構築するための既知の標準の例は、コモン・オブジェクト・リクエスト・ブローカー・アーキテクチュア（ＣＯＲＢＡ）である。ＣＯＲＢＡオブジェクト・リクエスト・ブローカー（ＯＲＢ）は、異種の言語で実行でき且つ異なる機器により異質の環境で実行できる、オブジェクト間での相互作動性を提供するためのアプリケーション・フレームワークである。ＣＯＲＢＡは、オブジェクトがフレームワーク内では目に見えないで要求し、答えを受け取ることができるようにする、非常に柔軟なアーキテクチュアである。ＣＯＲＢＡ２．０／ＩＩＯＰ仕様、ＣＯＲＢＡサービス仕様、及び他の関連仕様などの参考文献がＯＭＧから発行されている。ＣＯＲＢＡ及び同様なＤＯＯのアーキテクチュアは広範なアプリケーションを持っており複雑なので、大きなシステムの開発には高いコストがかかる。このコストは、先ず非常に長い仕様をそのアーキテクチュアに適合させる問題から発生して、特定のタスクを処理する際に複数の可能な選択肢を複数提供し、又次は、その選択のどの組み合わせが広範な設計要件に対し最適解を提供するかを特定する問題から発生する。更に、分散型オブジェクト指向技術の利点を実現することは、多くの開発者と共に以下のような処理すべき関心事へ挑戦することである。・スケーラビリティ − 数十の機器及び一千万までのＣＯＲＢＡオブジェクトに至るシステムをいかに構築するか。・性能 − 満足できる性能のシステムをいかに構築するか。・故障許容限界 − 毎週７日２４時間の可用性をいかに達成するか。・持続性 − オブジェクトの状態を高性能分散型環境にいかに効率的且つ安全に維持するか。・管理 − 非集中型コンピューターシステムをいかに管理するか。・実行 − ソフトウェアの高度再使用を許容しながら、開発、試験、リスクをいかに包含するか。ＩＢＭ名義の欧州特許ＥＰ７２７７３９号は、オブジェクト指向言語で書かれたネットワーク管理アプリケーションプログラムをネットワーク通信プロトコルに変換するためのプログラミング・インタフェースを開示している。オブジェクト・ダイナミックス社名義の国際特許公告ＷＯ９７／２２９２５号は、ソフトウェアのコンポーネント及びシステムを、現存のオブジェクトモデルと互換性があり且つそれらを拡張する独立した構成部品から組み立てることにより設計及び構築するためのシステムを開示している。ガーロフ他名義の米国特許第５６９９３１０号は、オブジェクト指向管理技術が、ユーザーの入力した仕様からソースコードを生成するためのコード発生器と共に使用されているコンピューターシステムを開示している。しかし、これら初期の開示は、以下に述べるパワーと柔軟性を提供する設計パターンに特徴付けられるＬＳＤＯＯシステムを構築するための開発ツールならびに方法を述べてはいない。用語解説特に指定がないか又は使用されている文脈から明らかな場合を除き、以下の用語は添付説明の意味に用いる。「属性」ゲット及び（通常は）セット・オペレーションにより表に出されるＮステートデータ。「同報通信デレゲーション」全コンフェデレーツに対するデレゲーション。「大容量オペレーション」多数（又は全ての）オブジェクトのＮステートにアクセスするオペレーション。「クライアント」１つ又はそれ以上のサービスへのアクセスを要求するアプリケーション。「クラスタ」クラスタ状に構成された機器から成る、対等クラスタ分散モデル。クラスタは互いに対等者として協働し、クラスタ内の機器は特殊化される。「集合」あるコモナリティを有するメンバーのセット、好ましくは順序付けされていないオブジェクトのセット、を参照するオブジェクト。「コンフェデレーツ」フェデレーションを構成する集合。「ＣＯＲＢＡオブジェクト」それに対しクライアントがＣＯＲＢＡオブジェクト・リファランスを取得するオブジェクト。「ＣＯＳＳ」通常のオブジェクトサービス。「デレゲーション」オペレーションを実行するためのもうひとつのオブジェクトを含む１つのオブジェクト。「設計パターン」システム設計の中で生じるＬＳＤＯＯの問題点に取り組むための設計解。「指定デレゲーション」コンフェデレーツの識別されたサブセットに対するデレゲーション。「分散モデル」は、システムを実行するために機器及びデータリンクをどのように物理的に組織するかを述べる。「明示的グループ」グループオペレーションであり、そこではメンバーがアイデンティティによってリストされている。「ファクトリー」他のオブジェクトを造るオブジェクト。「フェデレーション」より早く、安く、信頼性の高いサービスを提供するために協働する集合のセット。「フレンド」オブジェクト同士がＩステートを共有しているが独立したＮステートを持っているように見える関係。「ゲートウェイ」非ＣＯＲＢＡ環境のＣＯＲＢＡ表現。「ジェネリック・インタフェース」特定インタフェース間に存在する、根本問題ドメインコモナリティを識別するインタフェース。「優雅故障」コンポーネントの故障に対して、故障の影響を直接には被らないオペレーションを実行し続けることによって対応するシステム。「グループオペレーション」１つの基本的オペレーションが多数のオブジェクトに適用されるオペレーション。「アイデンティティ」オブジェクトと不変の１対１の関係を有するＮステートデータ。「暗示的グループ」メンバーが探索述語によって定義されるグループオペレーション。「Ｉステート」オブジェクトの実行によって記憶される状態。「ライフサイクル」オブジェクトを作成、コピー、再配置、破壊するプロセス。「ＬＳＤＯＯ」大規模分散型オブジェクト指向であり、典型的には、あるビジネスファンクションを自律的に実行するために協働する多くの機器上にオブジェクトを有するシステム。「メンバー」集合により参照されるオブジェクト。「自然集合」システムの機能性を支援するのに必要な集合。「正規化オブジェクト」下記事項全てが真の場合オブジェクトは正規化される。ｉ）オブジェクトの状態が他のオブジェクトと重複しない。ｉｉ）オブジェクトのセマンティクスがそのオブジェクトのみによって定義され、実行される。ｉｉｉ）そのインタフェースが、全ての状態にアクセスし、それをオブジェクトのセマンティクスと矛盾しない何らかの方法で変更するのに丁度十分である。「正規化システム」システム内の全オブジェクトが正規化されると、システムは正規化される。「Ｎステート」正規化された状態であり、オブジェクトが正しい挙動を表示するのに必要なステートの量が最小である。「オブジェクト」オブジェクトのＯＯコンセプト、即ち、アイデンティティを有し、定義されたインタフェースを通してアクセスされる状態（Ｎステート）のアトム。オブジェクトはＬＳＤＯＯシステムの基本的なコンポーネントであり、（プリンターのような）ハードウェア装置であってもよいし、（プリントマネジャーのような）ソフトウェア・アプリケーションでもよい。「オブジェクト・リファランス」オブジェクトに対し不変の多数対１の関係を有する、オブジェクトに対するポインター。「ＯＯＰＬ」オブジェクト指向プログラミング言語。「パーティション」オブジェクトの物理的グループであり、そこでは各オブジェクトが正確に一つのパーティションと関係している。一般的に、パーティションと計算ハードウェアのセットとの間には１対１の対応関係がある。「性能集合」グループオペレーションの効率的実行を提供することによってシステム性能を改善する集合。「レプリカ」複製されたオブジェクトのＩステート複製の一つ。「複製」いくつかの物理的位置におけるオブジェクトのＩステートの複製。「ＲＤＢＭＳ」関係データベース管理システム。「セカンドクラス・オブジェクト」ＣＯＲＢＡオブジェクト・リファランスでは参照することのできないオブジェクト。「サービス」機能性の抽象的プロバイダーであり、ＣＯＲＢＡＩＤＬインタフェースによって定義される。（通常サービスは、互いに協働する論理的にグルーピングされたオブジェクトによって提供される。）「ツリー降順」再帰デレゲーションの一形態であり、そこでは代表者がツリーを形成する。「ウォーム」再帰デレゲーションの一形態であり、そこでは代表者が任意のグループを形成する。「ラッパー」システムのコンポーネントを、他のコンポーネント、共通サービス、インフラストラクチャにおける変化及び不良から守る内部インタフェース。発明の目的本発明の目的は、先行技術に関係する問題の少なくとも幾つかを改良又は克服する大規模分散型オブジェクト指向コンピューターシステムのための開発ツールを提供することである。本発明のもう一つの目的は、開発者がオブジェクトモデリングとビジネスロジック実行に焦点を絞れるようにしながら、少数のパワフルなＣＯＲＢＡ使用モデルを実行する、大規模分散型オブジェクト指向コンピューターシステムを開発するための方法を提供することである。本発明の更にもう一つの目的は、・ＣＯＲＢＡを使用するシステムモデリングのガイドラインと、・抽象的オブジェクトモデルを展開可能なＣＯＲＢＡインタフェース設計言語（ＩＤＬ）に翻訳するためのモデリングツールと、・ＣＯＲＢＡクライアント、サーバー、ファクトリー、集台を作るためにインフラストラクチャレベルコードを生成するための、コードライブラリーを含むコード生成器と、・分散された構成、デバッギング、管理、性能計測のためのシステム管理機能とを提供する大規模分散型オブジェクト指向計算のためのシステム開発ツール及び／又は方法を提供することである。発明の開示ある形態においては、唯一又は事実最も広範囲な形態である必要はないが、本発明は、複数のクライアントと、複数のサーバーと、クライアントのサービスに関する要求をサーバーへ通信するための分散型オブジェクトインフラストラクチャとを含む、大規模分散型オブジェクト指向コンピューターシステムを構築するための開発ツールに在り、前記開発ツールは、（ａ）（ｉ）各オブジェクトの固有のアイデンティフィケーションを容易にするオブジェクトアイデンティティパターンと、（ｉｉ）あるコモナリティを有するオブジェクトの論理的グルーピングを容易にする集合パターンと、（ｉｉｉ）オブジェクトのセットに目標を絞ったオペレーションを容易にするグループオペレーションパターンと、（ｉｖ）クライアントとは無関係に一つのオブジェクトともう一つのオブジェクトとの連携を容易にするフレンドパターンと、（ｖ）性能目的にオブジェクトの物理的グルーピングを容易にするパーティションパターンとを含む、予め定められたオブジェクト設計パターンを提供する一連のテンプレートと、（ｂ）クライアントプロセスが要求することになる所望のサーバープロセスを定義るために、そしてオブジェクト設計パターンの内の選択されたものを組み込むためにユーザーによって作り出されるオブジェクト指向システムモデルから、以下の（ｉ）分散型オブジェクトインフラストラクチャからクライアントアプリケーションコードを切り離すための、各クライアントプロセス用のクライアントアクセスレイヤーと、（ｉｉ）分散型オブジェクトインフラストラクチャからサーバーアプリケーションコードを切り離すための、各サーバープロセス用のサーバーアクセスレイヤーと、（ｉｉｉ）ユーザーがサーバーセマンティックスのインプリメンテーションを統合するための規定を含む、各サービスを実行するためのサーバーアプリケーションコードのスタブ部とを生成するために配置されているコード発生器とから成る。前記開発ツールは更に、システム内で利用可能なサービスの発見のためのサービスファインダーサービスを含む基本的分散型サービスのセットを含んでいるのが相応しい。必要であれば、前記一連のテンプレートは更に、以下のオブジェクト設計パタ一ン、即ち、（ｖｉ）改善されたサービスを提供するために協働する集合のセットであるフェデレーションパターン（ｖｉｉ）フェデレーション内のセットからの集合の最適選定を容易にする統一されたサービスパターン、及び／又は（ｖｉｉｉ）特別にアイデンティファイされたオブジェクト上での複数のオペレーションを容易にする大容量オペレーションパターンの内の一つ又はそれ以上を含んでいてもよい。オブジェクトアイデンティティはオブジェクトの属性であり、構造化名を用いて表され、オブジェクトの複製を考慮しているのが望ましい。なるべくなら、１つの集合にグルーピングされたオブジェクトはメンバーとして知られ、集合のメンバーの知識は明示的に維持され、リストの形式になっているか、或いは規則の適用によって明示的になっているのが好ましい。グループオペレーションが適用されるオブジェクトのセットは、明示的に又は暗示的に定義されたグループオペレーションの有効範囲として知られているのが望ましい。明示的に定義されたグループオペレーションは、サービスとオペレーションに対するパラメータ、好ましくはオブジェクト識別子のリスト、から成るオブジェクトにより支持された根本的オペレーションに基づいており、有効範囲を定義する。暗示的に定義されたグループオペレーションは根本的オペレーションに基づいてはおらず、クライアント指定フィルターがオブジェクトに適用されオペレーションの有効範囲を定義する。２つのオブジェクトは、もしそれらが分散型オブジェクトインフラストラクチャを通してクライアントと連携して現れるのではなく、互いに連携して現れるのであればフレンドであるのが相応しい。パーティションはオブジェクトの物理的なグルーピングであり、そこではシステム内の各オブジェクトは１つのパーティションとだけ関係し、そのパーティシヨンはコンピューターハードウェアの１つのセットと対応する。なるべくなら、フェデレーション内の集合は、より早くより広くより信頼性のあるサービスを提供するために、互いにオペレーションを委任できるのが望ましい。統一されたサービスは統合された集合であり、そこでは予め定められた集合のサブセットはクライアントには見えないのが相応しい。クライアントアクセスレイヤーは、サービスを実行するオブジェクトにアクセスするエージェントクラスと、エージェントクラスにより操作されるデータ構造を表すための別のクラスとを含んでいるのが望ましい。なるべくなら、エージェントクラスは分散型オブジェクトインフラストラクチャ用のインタフェースコードをクライアントアプリケーションコードから分離して、オブジェクトのアイデンティティ、インタフェース、その実現に取り組むための手段をカプセル化しておくのが望ましい。サーバーアクセスレイヤーは、あらゆるパーティションに関してオブジェクトを管理するためのサービスマネージャーを含んでいてもよく、オブジェクトの創造と削除とを考慮している。サーバーアクセスレイヤーは、サービスを実行するオブジェクトへのアクセスを提供するためのアダプタークラスを含んでいるのが望ましい。基本的分散型サービスのセットは更に、システム内のファイルを複製するためのファイル複製サービスを含んでいるのが相応しい。基本的分散型サービスのセットは、コードライブラリーによって供給されるのが望ましい。必要があれば、システムはＣＯＲＢＡ標準を利用し、そこでは、（ａ）分散型オブジェクトインフラストラクチャはオブジェクトリクエストブローカー（ＯＲＢ）を含み、（ｂ）オブジェクト指向システムモデルはＣＯＲＢＡコンセプトを使用してモデル化され、（ｃ）サーバーインタフェースはＣＯＲＢＡインタフェース設計言語（ＩＤＬ）に従って生成される。別の形態においては、本発明は、複数のクライアントと、複数のサーバーと、クライアントのサービスに関する要求をサーバーへ通信するための分散型オブジェクトインフラストラクチャとを含む、大規模分散型オブジエクト指向コンピューターシステムの開発ための方法に在り、前記開発方法は、（ａ）（ｉ）各オブジェクトの固有のアイデンティフィケーションを容易にするオブジェクトアイデンティティパターンと、（ｉｉ）あるコモナリティを有するオブジェクトの論理的グルーピングを容易にする集合パターンと、（ｉｉｉ）オブジェクトのセットに目標を絞ったオペレーションを容易にするグループオペレーションパターンと、（ｉｖ）クライアントとは無関係に一つのオブジェクトともう一つのオブジェクトとの連携を容易にするフレンドパターンと、（ｖ）性能目的にオブジェクトの物理的グルーピングを容易にするパーティションパターンとを含む、予め定められたオブジェクト設計パターンのための一連のテンプレートから一つ又はそれ以上のテンプレートを選択する段階と、（ｂ）クライアントプロセスによって要求されることになる所望のサーバープロセスを定義するための、そしてそのモデルが選択されたオブジェクト設計パターンを組み込むところの、オブジェクト指向システムモデルを作る段階と、（ｃ）前記オブジェクト指向システムモデルから、以下の（ｉ）分散型オブジェクトインフラストラクチャからクライアントアプリケーションコードを切り離すための、各クライアントプロセス用のクライアントアクセスレイヤーと、（ｉｉ）分散型オブジェクトインフラストラクチャからサーバーアプリケーションコードを切り離すための、各サーバープロセス用のサーバーアクセスレイヤーと、（ｉｉｉ）ユーザーがサーバーセマンティックスのインプリメンテーションを統合するための規定を含む、各サービスを実行するためのサーバーアプリケーションコードのスタブ部とのためのコードモジュールを生成する段階とから成る。前記方法は更に、システム内で利用可能なサービスの発見のためのサービスファインダーサービスを含む基本的分散型サービスのセットを提供する段階含んでいるのが望ましい。前記段階（ｃ）における選択に利用可能な前記一連のテンプレートは更に、以下のオブジェクト設計パターン、即ち、（ｖｉ）改善されたサービスを提供するために協働する集合のセットであるフェデレーションパターン、（ｖｉｉ）フェデレーション内のセットからの集合の最適選定を容易にする統一されたサービスパターン、及び／又は（ｖｉｉｉ）特別にアイデンティファイされたオブジェクト上での複数のオペレーションを容易にする大容量オペレーションパターンの内の一つ又はそれ以上を含んでいてもよい。オブジェクトアイデンティティパターンが選択されると、オブジェクトのアイデンティティ属性は構造化名を用いて表され、この属性はオブジェクトの複製を考慮している。集合パターンが選択されると、メンバーとして一つの集合にグルーピングされたオブジェクトを参照し、リスト形式のように明示的に、或いは規則の適用により暗示的にの何れかで集合のメンバーの知識を保持する。グループオペレーションパターンが選択されると、グループオペレーションがグループオペレーションの有効範囲として適用されるオブジェクトのセットを参照するが、この有効範囲は明示的に定義されていても暗示的に定義されていてもよい。フレンドパターンが選択されると、フレンドオブジェクトを、彼らが分散型オブジェクトインフラストラクチャを通してクライアントと連携して現れるのではなく、互いに連携して現れるように配置する。パーティションパターンが選択されると、オブジェクトの物理的グルーピングをパーティションに割り当て、そこではシステム内の各オブジェクトは、コンピューターハードウェアの１つのセットに対応する１つのパーティションにだけ関係する。フェデレーションパターンが選択されると、より早くより広くより信頼性の高いサービスを提供するために、集合が互いにオペレーションを委託できるようにする。統一されたサービスパターンが選択されると、統合された集合内の予め定められた集合のサブセットを、クライアントが要求する統一されたサービスが見えないように配置する。前記クライアントアクセスレイヤーを生成する段階は更に、エージェントクラスによって操作されるデータ構造を表現するためにサービス及び他のクラスを実行するオブジェクトにアクセスするため、エージェントクラスを生成する段階を含むのが望ましい。前記エージェントクラスを生成する段階は、分散型オブジェクトインフラストラクチャのためのインタフェースコードをクライアントアプリケーションコードから分離し、オブジェクトのアイデンティティ、インタフェース、その実現に取り組むための手段をカプセル化するのが望ましい。前記サーバーアクセスレイヤーを生成する段階は、あらゆるパーティションに関してオブジェクトを管理するためのサービスマネジャーの規定を含んでいてもよく、オブジェクトの創造と削除を容易にする。前記サーバーアクセスレイヤーを生成する段階は、アダプタークラスが、サービスを実行するオブジェクトへのアクセスを提供できるようにすることが望ましい。前記基本的分散型サービスのセットを提供する段階は、更に、システム内のファイルを複製するためのファイル複製サービスを提供する段階を含んでいてもよい。又別の形態においては、本発明は、上に説明した何れかの開発ツール又は開発方法を使って構築された大規模オブジェクト指向システムに在り、そこではオブジェクト指向システムは共通の管理インタフェースを含んでいる。上記共通の管理インタフェースは、テストの規定、使用可能、使用不可能、バックアップ、再スタート機能を含む、システム内の全ての統一されたサービスを遠隔管理し易くするのが望ましい。更に、この管理インタフェースは又、統一された各サービスを照会できる、バージョン番号、著作権情報、ステータス、ホスト機器、プロセスアイデンティティ、等の属性の１つ又はそれ以上を含む属性のセットをサポートする。図面の簡単な説明本発明の理解を助けるために、好適な実施例を以下の図面と共に説明する。図１は、コンピューターネットワークの線図であり、その上でオブジェクトが大規模ＯＯシステム内に分散されている。図２は、第１の実施例の開発ツールのための使用モデルの線図である。図３は、第１の実施例のアーキテクチュアの概観である。図４は、集合設計パターンの図を示す線図である。図５は、プルモデルを使用して実行された集合を示す線図である。図６は、プッシュモデルを使用して実行された集合を示す線図である。図７は、個々のオペレーションに委任するグループオペレーションを示す線図である。図８は、他のグループオペレーションに委任するグループオペレーションを示す線図である。図９は、フレンド設計パターンの例を示す。図１０は、対等クラスター分散モデルを示し、ここではクラスターはパーティション設計パターンに関係する。図１１は、統合された集合を示す。図１２は、不可視的に統合されたファクトリーの例を示す。図１３は、２つの統合されたオブジェクトの間に存在するフェデレーションインタフェースの配置を示す。図１４は、統一されたサービスパターンの例を示す。図１５は、統一された統合サーバーを含む典型的なクライアント／サーバーシナリオを示す。図１６は、オブジェクト識別子（ＯＩＤ）のオペレーションを示す。図１７は、本実施例のサーバープロセスにおけるアダプターとＩｍｐｌクラス間の関係を示す。図１８は、サービスロケーターサービスとサービスマネージャー間の対話を示す。図面の詳細な説明概要図１はコンピューターネットワークを示し、その上にＯＯシステムのオブジェクトが分散配置されている。ネットワークは、ネットワークバックボーン３に接続されたコンピューター端末即ちＰＣ１、ファイル即ちプリントサーバー２等のコンピューター機器、又は命令とデータを互いに共有するための他の通信インフラストラクチャを含んでいる。コンピューター機器は遠く離れた位置４、５、６に配置し、ネットワークバックボーンの分枝をルーター７のような切替え装置で接続しておけばよい。ここでは、オブジェクトは特定のプリンター８に例をとりサービスはファイル記憶機能に例を取る。図２では、システム開発ツール１０のインテジャが、本実施例で実行されるように、ＣＯＲＢＡ標準に従うシステムを作るために示されている。ＣＯＲＢＡの作業知識は以下の記述のように仮定されるか、そうでなければ上記のＣＯＲＢＡ仕様に対しリファランスが作られる。先ず開発者は設計ガイド１２の支援の下に共通オブジェクトモデリング技術を使って論理オブジェクトモデル１１を考え出す。本実施例では、開発ツールは更に、開発者が汎用モデリング言語（ＵＭＬ）で表現されたＣＯＲＢＡシステムモデル１４を規定するのを支援する、モデルウィザード１３を含んでいる。他の実施例では、システムモデルを、もう１つのオブジェクト指向コンピューター支援ソフトウェアエンジニアリング（ＣＡＳＥ）ツールのようなある他のツールで作ることもでき、又モデルウィザードを先に存在しているＵＭＬモデル又は他のＯＯモデルで初期化することもできる。開発者がＣＯＲＢＡシステムモデルが正しいと満足している場合、コードウィザード１５の形のコード発生器はシステムを取り上げ、ＣＯＲＢＡインタフェース設計言語（ＩＤＬ）モジュール１６と、開発者が規定したオブジェクトセマンティックス１８に対するフックを含むサーバー１７に対するインプリメンテーションと、サービスに対する単純化されたクライアントインタフェース１９とを作る。開発者１０はオブジェクトセマンティック１８を、好都合にも本実施例内で単純化クライアントインタフェース１９のためにコードウィザードによって使用されているＣ＋＋のような適当な言語でコード化するのが望ましい。他の実施例ではジャバ、スモールトーク、ＯＯソフトウェアに適した他の言語等を使うこともできる。基本的分散型サービスのセットは、開発ツールライブラリー２１によっても提供され、これは他の共通機能を含んでいる。ＣＯＲＢＡに従うオブジェクトリクエストブローカー（ＯＲＢ）２０、即ちその中でシステムが稼動する環境、も又支給される。ビジジェニックの「ビジブローカー」、イオナ技術の「オービック」等の商業的に入手可能な製品がこの目的に適している。適当な目標ＯＳは、サンマイクロシステムの「ソラリス」、ヒューレットパッカードの「ＨＰＵＸ」、マイクロソフトの「ＮＴ」或いは他の適当なマルチタスクＯＳであると思われる。次に、サーバー２２及びデフォルトクライアント２３に対し実行可能なものが生成されたモジュール１６，１７，１９及び開発者がコード化したモジュール１８を外部ソースのＯＲＢコンポーネント２０と共に連結することによって作られる。開発者は、何れのコードウィザード出力ファイルをも、その初期選択を修正し、又は開発ツールによってサポートされているものよりもっと複雑なＣＯＲＢＡコンセプトを使用するために、拡張又は修正することができる。便宜上、本実施例のシステム開発ツール１０を以後「ＯＲＢマスター」と呼ぶ。アーキテクチュア図３は本実施例によって生成された、生成されたサービスの典型的なクライアント／サーバーの図である。この線図に示されているＯＲＢマスターアーキテクチュアのキーとなる態様は、クライアントアプリケーションコード２６、クライアントアクセスレイヤー２７、サーバーアクセスレイヤー２８、サーバーアプリケーションコード２９、基本サービスであり、基本サービスはファイル複製サービス３０とサービスファインダーサービス３１を含んでいる。クライアントプロセス３２、サーバープロセス３３及び基本サービスはＯＲＢ２５の形態の分散型オブジェクトインフラストラクチャを通して通信すると理解されたい。ＯＲＢマスターアーキテクチュアはサービス開発者がアプリケーションコード（クライアントアプリケーションコード及びサーバーアプリケーションコード）領域内に開発努力を集中できるようにする。ＯＲＢマスターアーキテクチュアはこれを、いくつかの有用な分散型サービス(ファイル複製及びサービスファインディング)、いくつかの有用な設計パターンのコード（グループオペレーション、統一されたサービス、等以下で論議する）を提供することによって行う。このアーキテクチュアは又、クライアントと、ＯＲＢ依存コードをアプリケーション特定コードから分離し、そしてサービスの分散態様を実施するコードを他のサービスセマンティックスを実行するコードから分離するサーバーアクセスレイヤー（ＣＡＬ及びＢＡＬ）とを提供する。ＯＯアーキテクチュアにおける最も基本的なコンポーネントはオブジェクトである。クライアント／サーバーのパラダイム内では、オブジェクトのグループがサービスを提供するために協働し、サービスにはクライアントのアプリケーションがアクセスする。ＯＲＢマスターのアーキテクチュアは、ＣＯＲＢＡとは対照的に、アイデンティティ、サポートインタフェースを有し、インプレメンテーションを有するオブジェクトのコンセプトに依存する。アイデンティティはオブジェクトの属性である構造化名を用いて表され、インタフェースはＩＤＬを用いて定義され、インプレメンテーションはＣＯＲＢＡオブジェクトリフアランスを用いてアドレスされる。従って、ＯＲＢマスターオブジェクトは丁度第１クラスＣＯＲＢＡオブジェクトにアイデンティティを付加したものである。アイデンティティは以下に記述する設計パターンにおいては暗示的である。命名属性とオブジェクトとの間には多数対１の関係がある。命名属性はオブジェクトの読取専用属性である。オブジェクトの命名属性はそのオブジェクト識別子（ＯＩＤ）として指定される。ＯＩＤとオブジェクトの間には１対１の関係がある。ＯＩＤは、データベースキーとして、そしてオブジェクトに対するオブジェクトキー（ＣＯＲＢＡインターオペラブル・オブジェクト・リファランス(ＩＯＲ)）としての両方に使われる。オブジェクトリフアランスはオブジェクトの現在のインプリメンテーシヨンにアドレスするか、又は何にもアドレスしない。即ち、１つのオブジェクトに対するオブジェクトリフアランスは引き続いて異なるオブジェクトにアドレスするのに使うことはできない。オブジェクトリファランスはオブジェクトが動いたときには変化するかもしれず、それ故、オブジェクトアイデンティティを表すことはできない。当然、オブジェクトリファランスはクライアントによって持続的に保持されるべきではない(代わりにＯＩＤを使うべきである)。このアーキテクチュアはオブジェクトが１つ以上のインプリメンテーシヨンを持てるようにする、即ち、オブジェクトが複製できるようにする。サービスは、ある特定のビジネスニーズに合致するように、機能的に且つ論理的にグルーピングされる。サービスは関係するサービスプロバイダーオブジェクトのグループによって実行される。サービスはＯＩＤ（即ち名前）によって識別される。全てが同一の統一されたサービスをサポートするサービスマネージャーの１つのセットは、（それらのＯＩＤをサービス名とした）単一の複製されたオブジェクトであるのが効率的である。一般的には以下の２種類のサービスプロバイダーオブジェクトがある。即ち、サービスマネージャー：これは、分散管理、コンポーネントオブジェクトの集合上のグループオペレーション、コンポーネントオブジェクトのライフサイクル管理を取り扱うサービスのオペレーションを提供する、コンポーネントオブジェクト：これは、サービスにより管理された状態の最も小さく分割された識別可能なコンポーネントである、の２つである。サービスマネージャーとコンポーネントオブジェクトのインプリメンテーションは、図２に示すように、サーバーアクセスレイヤー（ＳＡＬ）とサーバーアプリケーションコードとに分けられる。ＳＡＬは、後出の「サーバーアクセスレイヤー」の項で詳しく説明する。システム開発ツールの１つの目的は、少なくともクライアントアプリケーションに関しては、ＣＯＲＢＡアーキテクチュアを理解する必要なしに、サービスへの完全なアクセスを提供することである。ＯＲＢマスタークライアントアクセスレイヤー（ＣＡＬ）はこの目的を達成するためにシークする。ＣＡＬはアプリケーションコードを、サービスを実行するオブジェクトにアクセスするのに必要なコードから分離する。ＣＡＬとアプリケーションコードとの間のインタフェースは、サービスのためにインタフェース定義言語（ＩＤＬ）から生成されたＣ＋＋クラスの何れをも表に出さない。ＣＡＬは、後出の「クライアントアクセスレイヤー」の項で詳しく説明する。インタフェースこの項では、ＬＳＤＯＯでのインタフェースの役割を、Ｃ＋＋ヘッダーファイルのようなＯＯＰＬインタフェースと対比する。インタフェースの役割はサービスの定義を提供することである。インプリメンテーションの役割は、定義されたオペレーションを遂行するためにオブジェクトの状態上で活動することによりサービスを実行することである。開発者は、サービスを利用するために、オブジェクト状態のコンセプトを必要とする。疑いの余地なく、これは実際のインプリメンテーションで用いられる実際の状態でなくともよく、むしろ、リファランスオブジェクトが有するであろう正規化状態「Ｎステート」のコンセプトである。Ｎステートのコンセプトがなければ、オブジェクトのオペレーションは結び付けられていないように見える。例えば、基本的なネームサーバーを考えよう。このＩＤＬはインタフェースのシンタックスを正確に規定する。トークン名はオペレーションセマンティックスを暗示する。例えば、add()オペレーションが'name'を'named'に対応付けるとしよう。結合が（ある規則のセットに照らして）真であれば、リターン結果も真であろう。find()からの単一のリターンは、名前が一意に違いないことを示している。コメントがこの理解を増すであろう。それは相互オペレーションセマンティックスを暗示する。find()オペレーションは、名前に合致し、delete()オペレーションよりもより好結果のadd()オペレーションを経たオブジェクトを返すと想定できる。この理解はＮステートを説明するコメントを通して深めることができる。それはサービスの質については何も言っていない。即ち、如何に早く、如何に多く、如何に信頼できるかである。オブジェクトのＮステートを表に出すことに失敗すると、オペレーション同士が相互連結を持っていないので、インタフェースが使用できなくなる。ＲＤＢＭＳに対する過剰反応として、ＯＯデザイナーは通常、これを単なるインプリメンテーションの課題だと考えて、議論しているオブジェクトの状態を避けるため非常に長く行ってしまう。この遠慮はインプリメンテーション状態（Ｉステート）に有効に適用されるが、Ｎステートを議論しなければならない。又、Ｎステートは無定形の形の無い物ではなく、構造を持っている。１つの有用なＮステートコンセプトは属性のそれである。属性は、その値を得て通常はセットするためのオペレーションを持つ１つのＮステートデータである。属性を得ることはＮステートを変えはしない。それをセットすると、その値を提案されたものに変えるか、或いは、もしそれがオブジェクトのセマンティックに違反するものであれば、フェイルする。１つの属性をセットしても、Ｎステートの他の部分は何も変わらない。属性の特別のタイプは「リレーション」であり、これはそのタイプがオブジェクトリファランスであるところの属性である。もう１つの属性の特別なタイプは「ネーム」であり、これはオブジェクトと多数対１の関係を有する属性である。ネームの特別なタイプが「キー」であり、これは不変のネームである。キーの特別なタイプが「アイデンティティ」であり、これはオブジェクトと１対１の関係を有するキーである。属性として表に出されていないＮステートはオペレーションを通して表に出され、「コンスタント」オペレーションはＮステートを変化させないでおくように設計されている。Ｎステート、属性、リレーション、キー、ネーム、コンスタンとオペレーション、及び品質のコンセプトは、アプリケーションの機能性にとって非常に重要であるのでインタフェースにおいて避けることはできない。しかし、これらのコンセプトのどれも、ＣＯＲＢＡのＩＤＬグラマーで本来的に表現可能ではない。ＩＤＬ属性は閉じているが、ユーザーの定義した例外をサポートできないので、半機能的である。それ故、規定を開発して発行し、これらのコンセプトをＩＤＬでエンコードするために一貫して適用しなければならない。ＣＯＲＢＡは、インタフェースレポジトリー（ＩＲ）サービスを規定する。しかし、このサービスは非常に小さな役割しか持っておらず、それは、それが単に「シンタックスレポジトリー」であるからであり、それは、インタフェースを含む他の複雑さの何れをも表現する方法を持っていないからである。ＩＲは恐らくは、ゲートウェイ及び基本のブラウザーに対して唯一有用であり、即ち、サービスのコンセプトをシンタックスのそれ以上には何ら有していないものなのである。設計パターン本実施例の開発ツールはＣＯＲＢＡに基づいて分散型アプリケーションを構築するためのアーキテクチュアを提供する。本節では、数多くのＯＲＢマスター設計パターンについて説明するが、これらは設計システムのためのテンプレートである。各パターンは１つ又はそれ以上のＬＳＤＯＯ問題点に取り組む。設計パターンのコンセプトについてもっと詳しいことは、ガンマ．Ｅ他の１９９５年ニューヨーク、アディソン・ウェズリー発行「設計パターン」及びモブレィ．Ｔ．Ｊ他の１９９７年ウィリィ発行「ＣＯＲＢＡ設計パターン」を参照されたい。以下に議論するパターンは、特に有用であり、システム設計ツールの支援の下で構築されるサーバーにおいて重要な役割を果たす。開発者は、システムの最もビジネス優先度の高いものに取り組むパターンに焦点を絞りながら、設計ガイド１２及び論理モデル１１の指示により、システム設計に対し設計パターンを選択的に適用することができる。・集合パターン集合は、性能及びシステムモデリングの問題点に取り組む幾つかのコモナリティを有するオブジェクトのセットを参照しやすく配列する１つのオブジェクトである。このパターンは、以下に述べるフレンド及びフェデレーションパターンと共に働く。集合はメンバーのセットに参照をつけるオブジェクトである。メンバーはある形式のコモナリティを有するオブジェクトであり、集合が管理するのは正しくこれである。以下の４つは集合の例である。即ち、 − ネームサーバーはオブジェクトのセットを表し、各オブジェクトは名前を持っており、それ故、集合は名前による検索をサポートする、 − トポロジーサーバーはオブジェクトのセットを表し、各オブジェクトはリレーションを持っており、それ故、集合はリレーションによる検索をサポートする、 − ＣＯＲＢＡ−ＩＰゲートウェイは、インタフェースプロトコル（ＩＰ）を表すオブジェクトと、ＩＰオブジェクトのセットを表す集合から成り、それ故、集合は、与えられたＩＰアドレスに対応するオブジェクトを見つけ出すなど、ＩＰタイプのオペレーションをサポートする、及び − エラーログはエラーオブジェクトの集合であり、それ故、集合は、エラーオブジェクトのライフサイクル、その検索、関係する統計をサポートする。集合は常にそのメンバーを知っている。集合はその知識を常に明示的に、例えば、メンバーオブジェクト参照のリストとして、或いは規則を通して暗示的に、例えば、１２３．２２．＊．＊に合致するＩＰアドレスを持った何らかのオブジェクトとして保持する。メンバーは複数の集合の一部であってもよく、例えば、プリンターオブジェクトはネームサーバー集合、インベントリー集合、ＩＰオブジェクトゲートウェイ集合の一部であってもよい。メンバーがその集合に関し持っている知識は変化することができる。あるメンバーはその集合と緊密な関係を有していて、そのアイデンティティを知っており、それと協働するように設計されており、例えばゲートウェイメンバーがそれに当たる。他のオブジェクトは、誰かいるとして、誰が彼らを集めているのかを認識していないかもしれない。そのようなオブジェクトは、ライフサイクルや状態変更通知のような、彼らを簡単に集めることができる機能をサポートしているかもしれない。集合は最も普及したＬＳＤＯＯパターンであり、設計プロセスで非常によく使われる。ＲＤＢＭＳシステムでは、全てのデータは、簡単な照会言語でアクセスするのにテーブルで利用できる。対照的に、典型的なＯＯシステムは最初のオブジェクトと共にスタートし、これが他のオブジェクトを明らかにし、そのオブジェクトが又他のを明らかにし、関心のあるオブジェクト全てが見つけ出されるまでこれが繰り返される。リレーション図に接続されていないオブジェクトは全て見つけ出せない。図４では、図の根元は最初のオブジェクトリファランス３５であり、これはC0RBA::resolve_initial_reference()のようなステートメントを用いてＯＲＢから手に入れることができる。集合は、図４に示す図では、無葉オブジェクト３５、３６、３７、３８である。従来型ＯＯモデリングの主要機能は集合を識別することである。そのような識別及びそれを行うための技法はＬＳＤＯＯと同じである。以下は、その中で集合をオブジェクトモデルの中に明らかにする共通の状況である。即ち、 − 属性検索、例えば、ペーパー外にあるプリンターを探す、 − グループオペレーション、例えば、オフラインのプリンターを探し、オンラインにセットする、 − ネーミング、例えば、ＩＰアドレス12.34.56.78のオブジェクトを探し出す、 − 束縛関係、例えば、装置内のプリント回路板のリストを返す、又は − 連結性、例えば、２つの終点オブジェクトを接続する最小コストパスを見つけ出す。集合は、ポインターを、代表的にはモデリング、検索、ネーミング、束縛などのメンバーの幾つかに返してもよく、テーブル探索に似たそのメンバーのＮステート幾つかを復帰させてもよく、そのメンバー（アクティブ集合）上でオペレーションを実行してもよく、カスケード削除のようにメンバーのライフサイクルを管理することもできる。集合パターンを他のＯＯコンセプトと組み合わせて適用することもできる。多くの集合は非集合態様を有しており、例えば、プリンターオブジェクトは、プリンター機能を実行すると同時に、そのコンポーネントオブジェクトの集合であってもよい。以下に集合を他のＯＯコンセプトと結合する例を示す。即ち、 − フェデレーションパターン、これは集合がより広範囲の照会に答えて協働できるようにする、 − フレンドパターン、以下に議論する通り、 − ファクトリー、ここでは非ＣＯＲＢＡ環境に対するゲートウェイが通常、全体としては異なる環境を表す集合と、オブジェクトの異なるコンセプトを表す個々のオブジェクトとを有している。集合に対するインタフェースは、例えば、ネームによってメンバーを見つけ出す等の集合の機能性を提供するオペレーションを有し、メンバー（ゲートウェイ／集合は例外であってもよい）を追加及び除去するためのいくつかのオペレーションを有し、通常フェデレーションをサポートし、そして、結果が大きかったり応答が遅い場合は、結果の取り消し又は逐次返却をサポートする。メンバーを追加及び除去するには多くのアプローチがある。集合がファクトリーであれば、有用なアプローチの幾つかはファクトリーであり、ファクトリーで作られるオブジェクトは全て自動的にメンバーであり、集合サポートにメンバーの追加と除去のオペレーションを提供し、集合が異なるドメインへのゲートウェイであればゲートウェイであり、集合のメンバーシップは通常そのドメインで表示される。例えば、ＩＰルーターをインストールすれば、対応するネットマスクを持ったＩＰゲートウェイ集合のメンバーシップを発生させることになる。効率的且つ柔軟性のある集合を構築するのは挑戦であり、スケールは集合の手に負えないものである。問題は、集合が如何にすれば、メンバーの状態を、そのオペレーションが効率よく実行できる十分な状態に維持できるかということである。例えば、不完全なプリンターのリストの返却をサポートするプリンター集合は、各プリンターをポーリングする（これはプリンターが沢山あれば遅い）か、又はプリンター状態のローカルキャッシュを探索するか（これは、プリンターとの同期性を維持するのにキャッシュが必要である）の何れかによってそのオペレーションを実行することができる。フレンドパターンは集合的Ｎステートへの１つの解を提供するが、それはメンバーのフレンドである集合がそれらのＩステートにすばやくアクセスできるものである。例えば、製造者がＨＰであるプリンターを見つけ出すのは、プリンターのＩステートがＲＤＢＭＳに記憶されていれば容易である。フレンド関係は、フレンドパターンで論議する幾つかの欠点を持っている。非フレンド集合はメンバーのリストを維持しなければならない。これは、図５及び６に示すように、プル及びプッシュ・データシェアリングモデルをサポートするには十分であり、即ち、 − プルモデル４０は、メンバー４２に、集合４１が必要に応じてそのＮステートにアクセスできるようにするステートインタフェース４３を持つことを要求し(プルモデルは、キャッシュを維持し、要求に応じて委任し、又は集合的オペレーションを実行するのに使うことができる)、 − プッシュモデル４５は、集合に、集合的Ｎステートを更新するのに使用できるオファインタフェース４７を持つことを要求する(プッシュはメンバー４８又は他のパーティから来ることもできる)。プッシュモデルは、クライアントの複雑さを犠牲にして、集合の大局から実行することは容易である。プルモデルは、集合を犠牲にして、よりメンバー寄りである。デレゲーションは通常遅く、キャッシュはプルモデルを使って維持するには複雑である。集合は設計、構築するのは難しくてもよく、設計を普及させる傾向にあり、それ故、標準集合の再使用を考慮すべきである。カスタムインタフェースは設計できるが、これらは標準コード化されたインプリメンテーションを使って実行されるべきである。候補標準集合は以下の通りであり、即ち、 − あらゆる集合に対するネームサーバーであり、これは１つまたはそれ以上の非常に独特なキーを有し、対応するオブジェクト、例えば、ＩＰアドレスをオブジェクトリファランスに変換するＩＰゲートウェイを返すものであり、 − あらゆる集合に対するＯＭＧ互換トレーダーであり、これは、例えば最良のプリンターを見つけ出すようなほとんど変化しない属性に基づいて、多くの中から１つのオブジェクトを選択するものであり、 − あらゆる集合に対するＯＶテレコムトポロジーであり、そこでは１つのオブジェクトがもう１つのオブジェクトと、例えば、所有者と所有されているオブジェクトの間に、何らかの形式の関係を確立する。このときには、標準サービスの良いインプリメンテーションは殆どなく、これがこのアプローチをいくらか制限する。又、標準解は常にカスタム構築のものよりも遅い。・大容量オペレーション（又は自然集合）パターン集合パターンの派生であり、自然集合とも称され、大容量オペレーションを実行する。特別に識別されたオブジェクト上での複数のオペレーションは、大容量オペレーションであると考えられる。自然集合は正規化システムモデルに必要な集合である。自然集合はシステムの機能性を実行するのに必要な集合であり、正規化システムの１部である。ＬＳＤＯＯシステムを設計する際には、全てのＯＯシステムと同じく、抽象的オブジェクトモデルからスタートする。これは、インプリメンテーションの問題点に関わることなくシステムのロジックを補足するモデルである。次に、抽象的オブジェクトモデルを、特定のインプリメンテーション技術、この場合はＣＯＲＢＡ、上にマッピングする。自然集合は集合の抽象的コンセプトのマッピングである。システムに対して自然集合を認識するのはやや困難であり、それはこれが従来のＯＯモデリングからの結果だからである。オブジェクト指向プログラミング言語（ＯＯＰＬ）の用語で考えると、ＬＳＤＯＯシステムでは理解できない幾つかの自然集合がありそれらは次の通りである。即ち、 − 多くのＯＯＰＬは、例えば、Ｃ＋＋又はジャバのスタティックメンバーファンクション及びデータのような、クラスデータのコンセプトを有している。ＤＯＯはこのコンセプトを持っていない。自然集合オブジェクトを使ってクラスデータを明示的にモデル化しなければならない。 − ＯＯＰＬの構造のコンセプト、例えば、Ｃ＋＋及びジャバnew()オペレーションは、何らかの特定のオブジェクト上で実行されるのではないグローバルなオペレーションである。ＤＯＯでは、新しいオペレーションは、ある特定のオブジェクト、典型的には連結されたファクトリー／集合オブジェクト上で実行されなければならない。オブジェクトモデルのテストのためにイベントトレース又はＣＲＣを実行する場合には、各オブジェクトをどのようにして見つけ出し、それを作るのに何を使ったかを非常に注意深く吟味しなければならない。 CORBA::resolve_initial_reference()ステートメントを使えば、各オブジェクトを、それをＯＲＢから手に入れた最初のオブジェクトリファランスまで遡って追跡できる。自然集合インタフェースは集合のために記述したインタフェース構造上で拡張する。自然集合の機能性では以下のテーマがしばしば浮上してくる。即ち、 − 名前を構成するものの詳細に関する名前による探索は、先のインタフェースの役割の項参照、 − オブジェクトの属性から形成される幾つかの述語に従う、オブジェクトの探索、 − オブジェクトライフサイクルオペレーション、特にカスケード除去、及び − そのプロジェクトに在りうる例に関する特定の集合的テーマは、パス選択、伝播、最善の選定である。共通のインタフェースの表現はこれらの共通のテーマに対して展開されなければならない。ここに幾つかの例と注意がある。即ち、あなたの集合のインタフェースを予測できるように命名せよ、例えば、Ｘの集合はＸ集合と呼ばれる、大容量オペレーション、通知、等に対して、一貫したサポートがなければならない、性能集合オペレーションをあなたの自然集合と接続することを探求せよ、 − 例外は注意深く使用せよ。例えば、「オブジェクトが見つからない」は滅多に例外状態であることはなく、検索とネーム探索の予想される結果である。自然集合インタフェースで繰り返すテーマは、探索オペレーションを典型とする、オブジェクトのリストを返すオペレーションである。返されたオブジェクトを表す幾つかのオプションがあり、即ち、 − オブジェクトリファランスを、あまり多くない場合には返却せよ、そうすればあなたの代表的クライアントは返されたリファランスの各々に「get attrib utes」呼び出しを即座に掛けることはないであろう、 − もしそれがあなたの代表的クライアントが必要としているもので、属性のサイズが大きすぎなければ、オブジェクトアイデンティティに属性を加えて返却せよ、 − 多くのオブジェクトがある場合はオブジェクトアイデンティティを返しなさい。もしアイデンティティを返せば、アイデンティティをオブジェクトリファランスに変換するグループオペレーションを提供しなければならない。もし返さなければ、非ＣＯＲＢＡ型又はセカンドクラスのオブジェクトを実行していることになる。実行に際しては、集合インタフェースが非常な類似性（リスト返却、逐次結果、フェデレーション等）を示す。これは全て、あなたがクライアント及びサーバーサイドに包んでおかねばならない「house-keeping」コードである。・グループオペレーション（又は性能集合）パターン集合パターンの更なる派生で、性能集合とも呼ばれ、グループオペレーションを実行する。１つではなく多くのオブジェクトを狙っているオペレーションはグループオペレーションと考えられる。グループオペレーションの効果は、単一のオペレーションを繰り返し実行するのと同じである。グループオペレーションには２つの形態、明示と暗示がある。即ち、 − 明示的グループではクライアントが目標オブジェクトをリスト表示し、例えば、このオブジェクトのリストで挙げられたオブジェクトの状態属性を返し、 − 暗示的グループではクライアントがメンバーシップ状態とその基準に合致する全てのオブジェクトから成るグループを指定し、例えば、状態故障を有する各オブジェクト上で自己試験を実行する。性能集合はオブジェクトモデリングプロセスからは起こってこない。これは、イベントのような技法を使った、システムのダイナミックな挙動の念入りな探索から出てくる。グループオペレーションに要求される２つの価値のある状態があり、それは、先ずクライアントが計画されたグルーピングに興味を抱かなければならず、次にグループオペレーションが対応する単一のオペレーションよりも相当に速くなければならない。価値のある明示的グループを作る因子には次のものが含まれる。即ち、 − クライアントは、それが如何に起こりうるかをあなたが考えるに必要なリファランスのリストを保持しなければならない(明らかな方法は、クライアントが探索オペレーションのような幾つかのオペレーションによってオブジェクトポインターのリストを与えられることである。もっと狡猾な方法はクライアントが徐々に個々のポインターを蓄積することである。)、 − クライアントはしばしばリストないの各オブジェクト上で全く同じオペレーションを実行する(例えば、クライアントはポインターを保有している多くのプリンターに対してテストオペレーションを実行しようとする。)、 − グループオペレーションは単一オペレーションよりも高速でなければならない(これはインタフェースで議論した問題点に依る。経験則では２ｋｂ以下のデータを戻すような単一オペレーションはグループオペレーションの候補である。)。興味ある暗示的グループを作る因子は以下の通りである。即ち、 − 幾つかの自然集合はメンバーシップ規準をとり、オブジェクトポインターのリスト、典型的には幾つかの形式の探索オペレーションを返すオペレーションを提供しなければならない、 − クライアントはしばしば返された各オブジェクト上で全く同じオペレーションを実行する、そして − グループオペレーションは連結された探索及び単一オペレーションよりも高速でなければならない。全ての暗示的グループオペレーションは、極端な場合を除きこの基準に合致しなければならない。明示的グループインタフェースでの重要な決定は、目標のオブジェクトをどのようにして指摘するかである。ＣＯＲＢＡオブジェクトリファランスは、整理が遅く、効率的に委任するのが下手（後のフェデレーションパターンの論議参照）なので、これを選定するのは良くない。幾つかのキー属性は、通常良い選択である。グループインタフェースはその基礎となる単一オペレーションインタフェースと対応しなければならない。システムの設計者及び保守する者を支援するためには、対応が予測できるのが望ましい。例えば、単一オペレーション、 Result X::M(in_args,out_args) は次の明示的グループオペレーション Sequence<Result>Xcollection::M(sequence<Xid>.in_args,sequence<out_args>) に対応する。単一及びグループオペレーションによって生ずる例外の間のマッピングを定義しなければならない。一般的には、グループオペレーションでは、例外が正確に何に対応するかが明確でないので、ユーザー例外は出てくるべきではない。暗示的グループは、集合がＮ個のリストの復帰オペレーションを持っており、そのメンバーがＭ個の単一オペレーションを持っていれば人口爆発が起き、集合上にＮ＊Ｍ個の暗示的グループオペレーションがあることになる。これは、復帰オブジェクトアイデンティティに対する全てのリスト復帰オペレーションを手に入れ、オブジェクトアイデンティティのシーケンス上のグループオペレーションを提供することにより、Ｎ＋Ｍにまで低減することができる。性能集合は、そのメンバーが集合のフレンドであれば遥かに効率的である。しかし、フレンドパターンには幾つかの注意事項がある。フレンドは以下の速度改善を可能とする。即ち、 − グループサイズをＮとすれば、Ｎ−１のＯＲＢ周回を約５（Ｎ−１）ｍｓ節約でき、 − グループオペレーションがオブジェクトリファランスではなくオブジェクトアイデンティティを使えば、整理リファランスにおいて相当な時間、約Ｎｍｓが節約でき、そして − ＩステートがＲＤＢＭＳ内に保持されていれば、大容量オペレーションを使う高速オペレーションを実質的に得ることになる。何であれ性能集合を統合するのは利益がありそうである。統合デレゲーションに対する一般的アプローチは後に、フェデレーションパターンに関係して論議する。しかし、グループオペレーションの委任には特別な問題がある。グループオペレーションは、図７に示すように、単一オペレーションのセットに非効率的に委任されるべきではない。むしろ、図８に示すように、グループオペレーションはグループオペレーションに委任すべきであり、そのほうが効率的である。最初の集合はグループを、各々が正確に一つの実行集合を目指す、グループのセットに分割する。こうすると、グループオペレーション性能が確実に維持できる。・フレンドパターンオブジェクトの１つの基本的な特性は「カプセル化」であり、オブジェクトの状態は公にされたインタフェースを通してのみ利用できる。不都合にも、現在のＣＯＲＢＡインプリメンテーションのためにＣＯＲＢＡインタフェースを通してカプセル化されたオブジェクトにアクセスするのは比較的遅いオペレーションとなり、通常毎秒２−３百オペレーションしかできない。図９に示すように、フレンドパターン５０は厳格なカプセル化モデルを緩和する。２つのオブジェクト５１と５２とは、５３にカプセル化されているようにクライアントに見えればフレンドであるが、５４との間ではカプセル化されているようには互いに見えない。フレンドは、それを通してフレンドが通信するインタフェースが、公にされたＣＯＲＢＡインタフェースよりも高速且つ充実するように設計されているので、有用なパターンである。フレンドオブジェクトは性能のためにＩステートを共有するが、Ｎステートは共有しない。彼らは性能問題に取り組み、集合及びファクトリーパターンと共に働く。フレンドの挙動の１例は、プリンターオブジェクトがそのＩステートを記憶しているデータベースにアクセスすることにより「オフラインにあるプリンターを復帰させる」を実行するプリンター集合である。フレンドの挙動は対称である必要はない。上の例を使えば、プリンターオブジェクトは決して集合Ｉステートにアクセスすることはない。オブジェクトは多くのタイプの多くのオブジェクトとフレンドになれる。もし複数のオブジェクトが同じプロセスで実行されれば、メモリーに記憶されているＩステートを共有することができる。複数のオブジェクトが同じディスクを共有すれば、データベース内に記憶されているＩステートを共有できる。正式には、ゲートウェイとそのメンバーは本来的にフレンドであるが、フレンドインタフェースは異なるドメインにある。この論議ではこのどちらかといえば明白なケースを避け、代わりにフレンドが性能上の理由で使われるところに焦点を当てる。フレンドは、ＬＳＤＯＯから妥当な性能を抽出することにおいて重要なパターンである。これは、フレンドインタフェースが、全体システムをその基本的ＯＯ特性に保ちながら、ＣＯＲＢＡインタフェースよりも数百倍高速で作動できるからである。フレンドは純粋なＯＯコンセプトとは相容れないので、その利用は相当な利益が付加される領域に限定すべきである。プル状態モデルを使用しての自然集合上での探索オペレーション及び性能集合上での全オペレーションは、集合とメンバーがフレンドであれば相当に早い。フレンドでなければ、これらのオペレーションは、単純な非効率的なインプリメンテーションか、複雑で効率的なインプリメンテーションかの何れかになる。フレンドであれば、単純で効率的なインプリメンテーションが可能となる。誰か一人が、与えられたシステム内で、オブジェクトのインプリメンテーションに対し唯一責任を持っている場合、フレンドのコンセプトは全く制限とはならず、システムはＯＯ及び純粋なＣＯＲＢＡを外から見る。他の開発者がシステム内の幾つかのオブジェクトを実行するように期待される場合、それらの統合のポイントも又純粋ＣＯＲＢＡでなければならず、即ち、フレンド関係には依存しない。しかし、システム内の全てのオブジェクトが互いに独立して再実行可能になる必要性は滅多にない。一緒にに実行されねばならないオブジェクトのグループは、拡張性境界のコンセプトである。境界の外ではオブジェクトは任意に取り替えることができ、境界の内側では拘束がある。プリンター−ＰＣシステムのハードウェアを同様に考える。プリンターはＰＣの拡張性境界の外側にあるので、公にされたインタフェースがあり、順応するプリンターであれば何ででもインプリメンテーションが受容できる。今、カプセルに入ったユニットであるプリンター内のトナーカートリッジを考えるが、これは公になったインタフェースを持っておらず、異なるインプリメンテーションと取り替えることはできない。トナーカートリッジはプリンターの拡張性境界の内側にある。プリンター製造業者は協議してトナーカートリッジ工業の標準に合わせることもできるはずだが、そのような細かなレベルでの拡張性価値はコストに値しないのであろう。ＬＳＤＯＯ用語では、プリンターとトナーカートリッジはフレンドで、プリンターとＰＣはそうではない。ＬＳＤＯＯシステム内の全てのオブジェクトが独立して再実行可能であるのは現実的ではなく、プリンター内の全てのコンポーネントがそうであると期待するのも同じである。フレンドは拡張境界内のオブジェクトに対する候補インプリメンテーションである。フレンドであるオブジェクトに対する外部インタフェースはその事実に影響されるべきではない。即ち、外からは、フレンドオブジェクトは純粋なＣＯＲＢＡオブジェクトと見えなければならない。フレンド間のインタフェースはインプリメンテーションと関係づけて後に議論する。オブジェクトがたとえ純粋なＣＯＲＢＡオブジェクトだと見えても、そこには更に以下の３つの独立性のレベルがありる。 − 依存、即ち、オブジェクトが、公にされたインタフェースを通しては全ての有効な値にセットできないＮステートを有している場合、依存である。依存という用語は、オブジェクトに対する幾つかの非ＣＯＲＢＡアクセスがあることを意味し、これはある異なるドメインからのもの、或いはフレンドインタフェースを通しての他のオブジェクトからのものかもしれない。 − 弱い独立、即ち、全てのオペレーションが、原則的には、公にされたインタフェースを通して行えるのであれば、２つのオブジェクトは弱い独立である。実際には、そのインプリメンテーションは実用に耐えぬほど遅い。 − 強い独立、即ち、１つのオブジェクトが、システムの機能又は性能を変えることなく新しいインプリメンテーションと置換できるのであれば、２つのオブジェクトは強い独立である。通常、拡張性境界内のオブジェクトは依存であり、拡張性境界外のオブジェクトは強い独立である。フレンドインタフェースを実行するには多くの技法がある。例を幾つか挙げるとそのアプローチは以下の通りである。 − １つのオブジェクトはその状態をＲＤＢＭＳ内に記憶することができ、他のオブジェクトはデータベースにアクセスできる。このアプローチは、自然集合又は性能集合内のグループオペレーションで探索オペレーションを実行するのには魅力的である。 − 複数のオブジェクトが、同じプロセス、又はプロセス間の共有メモリーの何れかの中で、メモリー内状態を共有できる。 − オブジェクトはＣＯＲＢＡインタフェースを使用でき、クライアントとサーバーを同じプロセスにリンクすることによって高速を実現できる。これはなおフレンドインタフェースであり、強い独立をサポートしていないことに注目されたい。弱い独立はインタフェース設計を通して達成される。強い独立は、インタフェース設計とインプリメンテーション設計を必要とする。強い独立には２つのアプローチがあり次の通りである。 − Ａｄｄ、即ち、集合は非フレンドの追加を許すadd()オペレーションをサポートする。それ故集合はフレンドと非フレンドが混じっている。平等なサービス品質を提供したいとすれば、効率的な非フレンドのインプリメンテーションを構築せねばならず、そうすると、フレンドパターンを全部落とすことになる。 − フェデレート、即ち、集合は、異なる集合があなたの集合のオペレーションの実行に参加することを許容するフェデレーションインタフェースをサポートする。これは強い独立を提供し、あなたの効率的且つ単純なフレンドインプリメンテーションを維持する。しかし、異なる開発者は今、メンバーと同じく集合の部分を実行する負荷を負う。纏めると、２つのアプローチがあるように見えるが「Add」アプローチは無意味なように思える。ＩＰルーターがＩＰポートを外部に見えるようにすれば同じ状況となるが、その中及びその間ではＩＰプロトコルを使う必要はない。先に論じたように、フレンドインタフェースは２つのオブジェクトに特権的な関係を与える。特権は他の開発者のオブジェクトには使えないので、システムの拡張性は低減される。・パーティションパターン（又は分散モデル）分散モデルは、性能、信頼性、システム内での操作性の問題点に取り組みながら、オブジェクトをどのように機器上にマッピングするかを記述する。ＣＯＲＢＡを使えば、クライアントはオブジェクトの位置を意識する必要はなく、ＯＲＢが、オブジェクトがどこにあっても、システムが働くことを保証する。分散モデルは以下のことを記述する。即ち、 − どのような機器がシステム内に存在するか、即ち、機器のタイプ、数、目的、 − どのオブジェクトがどの機器上に在るか、即ち、集合、メンバー、レプリカが機器上にどのように分散されているか、そして − どのようなデータフローが存在するか、即ち、機器の各ペア間でどれだけのデータが伝送されているか、である。分散モデルは、メタモデル又は展開モデルの何れかとして存在する。展開された分散モデルは特定のカスタマーによって実行される。メタ分散モデルは、システム設計者が配慮した展開モデルの完全なセットである。システム設計者とコンポーネント設計者は共にメタ分散モデルを必要とする。システム設計者は、ターゲットユーザーのニーズに応える詳細なモデルを必要とする。コンポーネント設計者は一般的モデルを必要とするだけであるが、コンポーネントが役に立つように展開できることを立証できるほどには詳細でなければならない。システム設計者はエンドユーザーに、実際には、大きなシステムバックグラウンドを持っていない展開分散モデルユーザーはこれを自分でやることを期待しないであろうという設計をしていることを保証する責任がある。分散モデルなしでの成功は、ＬＡＮを作り上げるのに、ケーブル、ハブ、ルーターをランダムに接続するのと同じように、殆どありえないことである。コンポーネント開発者は、ＣＯＲＢＡインタフェースを表に出して、メタモデルを展開モデルとして例示できるようにすべきである。システム開発者は、コマンドライン又は構成ファイルのように、ＣＯＲＢＡインタフェース、又は他のインタフェースの何れかを使用できる。分散モデルを設計する際には、以下のインプリメンテーションの問題点を考慮しなければならない。即ち、 − 展開後成長パスを含めた最小及び最大のシステムサイズ、 − クライアントとサーバーとの間の、特別な識別及び利用結合におけるデータフロー、 − バックアップ、ソフトウェアのアップグレード、機器の保守を含むシステム管理戦略、及び − 機器及びネットワーク損傷の影響、である。メタモデル、展開モデルは共に、これらの相違はー般原理の中にあると考える必要がある。メタモデル設計は集合、フェデレーション、複製、フレンドパターンを利用するために、システムオブジェクトモデル及びインタフェース設計と対話しなければならない。展開モデル設計は機器、ネットワーク帯域幅、機器配置、システム構成、最終用途を選定しなければならない。いろいろな根拠があってあまり詰めてやる必要はなく、最大に展開されたシステムでも最小のものの１０倍になることはあまりない。分散モデルの抽象的ゴールは、所有権のコストを低減することである。ハードウェア、ソフトウェアなどの所有権問題の明らかなコストを別にすれば、最大の要素は管理であろう。管理コストに関する経験則によれば、１次推定ではコストはデータベース機器の数に比例し、２次推定では構成しなければならないものの数に比例する。多くの現行システムに対する分散モデルは数個のＵＩ機器を持った１サーバー機器である。ＣＯＲＢＡシステムを１０から数百のサーバー機器上に展開すると期待するのは妥当である。この水準を超えると脅威的な困難に遭遇するであろう。図１０は１つの有用な分散モデルの例、対等クラスター分散モデル５５を示しており、これは以下の顕著な特徴を有している。即ち、 − 各クラスター内のマシンは特別な機能を有する、例えばデータベースマシン又はイベントハンドラーである。 − クラスター５６、５７、５８は同等に機能的なピアである。 − エントリーレベルは１台のマシンを含む１台のクラスターを持つことになり、クラスターにマシンを加えるか又はシステムにクラスターを加えるか何れかで展開のスケールを上げることができる。 − 多くのシステムの場合このモデルは、クラスターが１０台程度、各クラスターにマシンが１０台程度までの規模となる。 − 管理コストが下がる理由は、以下の通りである。（ｉ）データベースマシンの数が通常はクラスターの数と等しい。（ｉｉ）各クラスターは、自分自身に関する情報と対等者のアイデンティティのみで構成される。 − 各クラスターは、相互に働き合う外部システム５９、６０、６１の近くに置かれる。 − ユーザー６２、６３、６４は主に自分の近くのクラスター、５９、６０、６１と相互に働く。しかし、システム内の置かれたデータに対してアクセスを妨げるものは何もない。クラスターはパーティションのコンセプトを確立する。パーティションとは性能を目的に物理的グルーピングを具体化する設計パターンである。これは、ドメインの論理的コンセプト、即ち、種々の管理を目的にオブジェクトを論理的にグルーピングすることとは関係がない。現実世界の多くのシステムは対等クラスターモデルを提示しており、例えば電話システムのスイッチは、既存のスイッチを内部拡張するか又は新たなスイッチを加えるかの何れかにより、成長する内部構造を持ったピアである。このクラスターモデルでマシンが１００台以上になることは滅多にない。・フェデレーションパターンフェデレーションにより集合はより秀れたサービスを提供すべく協力できるようになり、それによりシステムの性能と信頼性の問題が提起される。多くのオブジェクトは、自分のオペレーションを実行する時幾つか他のオブジェクトを使って権限を委譲する。集合はフェデレーションと呼ばれる特定の形式のデレゲーションを頻繁に使う。図１１は統合集合６５を示す。フェデレーションが起こるのは、集合オブジェクトのグループ（コンフェデレート６６、６７として知られるいる）が、個々の集合オブジェクトが提供するサービスよりも秀れたサービス、即ち、速度、拡張性、信頼性の高いサービスを提供すべく協力するように設計された時である。ネームサーバーが統合集合のよい例である。各ネームサーバーはネームスペースの一部を保有し、他のネームサーバーに対するポインタを有している。あるサーバーが要求に答えられない場合、そのサーバーは答えられるサーバーに権限を委任する。特定の集合フェデレートがクライアントフェデレーションに対して利害があるという事実は、集合のＮステートモデルの一部である。例えばＩＰネームサーバーを使う場合クライアントには、全ＩＰスペースの内のどの部分を探索するか（Ｎステート範囲）が重要であり、どのように探索されるか（Ｉステートモデル）は重要でない。フェデレーションは又、 − トラスペアレント（透明）であり得る。この場合、クライアントはフェデレーション達成に関与しない。統一サービスパターンはトラスペアレントフェデレーションの特別なケースである。 − トランスルーセント（半透明）であり得る。この場合、クライアントはフェデレーション達成にある程度関与する。フェデレーションの別の特別な使用が集合／ファクトリーオブジェクトに当てはまる。ＣＯＳＳライフサイクルには、オブジェクトファクトリーに関するモデルが説明されており、共通のテーマは「オブジェクトを何処に置くか」である。あるアプローチでは、オブジェクトをファクトリーと同じ機器上に置くようクライアントに決めさせている。別のアプローチでは、統合ファクトリーに決めさせているので、ファクトリーはクライアントには知られていないアルゴリズムに基づいて位置を共同で決めている。図１２は例えば、各コンフェデレート（７２、７３）が特定のＩＰアドレスマスクを扱う見えない統合ファクトリー７０を示しており、この場合例えば、各コンフェデレート（７２、７３）は特定のＩＰアドレスマスクを扱う。創造要求７１はフェデレーション７０によって、正しいコンフェデレートへ委任される、本例では、コンフェデレート７２からコンフェデレート７３に委任され、コンフェデレート７３は新たなオブジェクト７５を返す。フェデレーションは、システムが管理するオブジェクト数を増大させるためのキーパターンである。システムが拡大されコンピュータがシステムに加えられると、集合オブジェクトを更に加える必要がある。これはシステムを物理的インプリメンテーションの必然的な結果である。しかし、クライアントは最大限まで物理的インプリメンテーションの問題とは無関係でなければならない。フェデレーションは１つの論理的集合のイルージョンを留めつつも複数の物理的オブジェクトを許容し矛盾を抑えることになる。以下の状況がフェデレーションの必要性を示しており、プリンタ集合を使って以下のように示されている。 − 集合は複数のマシン上にメンバーを有している。これは、集合フェデレーションを有する各マシン上のローカル集合を示している。ローカル集合は性能改善用のフレンドインプリメンテーションを利用できる。例えば、あるプリンタ集合がプリンタオブジェクトを有する各マシン上に存在すると、複数プリンタ集合は探索を互いに委任する。 − クライアントは通常、特定サブセットのメンバーにアクセスするが、時にはそれ以上のアクセスをする。これは、フェデレートはグローバルデータにアクセスするが、集合はローカル化されたデータアクセスパタンを利用することを示している。ドメインにしばしば関連しているローカル化されたアクセスは、管理システムにはよく見られる。例えば、プリンタ集合オブジェクトは部門線上に組織される。照会の多くは部門のプリンタ集合で回答できるが、必要なら回答は委任される。 − 優雅故障が必要である、即ち、コンポーネント故障に直接影響されずにシステムが作動し続けるということである。これは、オペレーションを作動中のコンフェデレートに委任するフェデレーテッド集合があることを示している。例えば、ある照会が作動していないプリンタ集合を要求すると、照会は回避されて部分的結果が返される。 − 他の開発者による拡張性が必要である、特に、他の集合が非常に異なるインプリメンテーションを有している場合がこれに当たる。これは、それぞれのインプリメンテーションを提供する異なる開発者を有する統合集合を示している。例えば、ＩＰの統合集合と共通管理インタフェースサービス（ＣＭＩＳ）で管理される（複数の）プリンタの場合、各集合は各々のプロトコルで要求を発し、応答をＣＯＲＢＡ返却値に翻訳するフェデレーションは集合インタフェースから自然に来ることが可能である。例えばＣＯＳＳネームサービスの場合、ネームコンテキストオブジェクトは集合であり、resolve()オペレーションは正規インタフェイスを使って他方のネームコンテキストオブジェクトへ委任する。自然インタフェイスは、通常、ワーム、ツリー降順、指名のデレゲーションインプリメンテーションに関連している。特別なフェデレーションインタフェイスを時に必要とするが、これは同報通信デレゲーションのインプリメンテーション通常関連している。インタフェイスは、フェデレーションの実行に影響する情報でクライアントが入手し得なくて、当該情報を集合に与えるのが難しくないのであれば、トランスペアレントフェデレーション（トランスルーセントフェでレーションよりも）を支援すべきである。フェデレーションはコンフェデレートが共同で実行するアルゴリズムであり、オブジェクト間のコミュニケーションを意味する。従って、フェデレーションとそれに付随するアルゴリズムは集合のＮステートモデルの一部であり、単なるＩステート問題ではない。明らかに、見えないように統合されたサービスはコンフェデレートとコンフェデレート以外という２つのタイプのクライアントを有しているが、コンフェデレートしかフェデレーションのアルゴリズムに興味を示さないであろう。従って、コンフェデレート上に一般的なインタフェイスとフェデレーションインタフェイスを持つと更にはっきりする。図１３に２つのコンフェデレート７１、７２の間に存在するコンフェデレーションインタフェイス７０を示すが、両インタフェイスは一般的インタフェイス７３、クライアントインタフェイス７４とは異なる。インプリメンテーションを考えると、複数機器の場合には、集合は全て統合されていなければならないのが恐らく本当であろう。フェデレーションにより、コスト殆どなしで多くの利益が得られる。しかしインプリメンテーションが所望の目的を達成するのを保証するため、フェデレーションの目的を注意深く（性能、信頼性、その他）考えるべきである。フェデレーションを実行する際の主な問題は「委任をどう達成するか」である。委任の手法例としては、ツリー降順、ワーム、指名、同報通信等のデレゲーションがある。 − ツリー降順デレゲーションの場合、メンバーは自然ツリー構造を持っている必要がある。集合は木を下ることで他のコンフェデレートに委任する。例えばＭ．３１００ネットワークレプリゼンテーション中に完全に識別された名前（ＦＤＮ）レゾルーション、ツリー降順は予見可能で受け入れ可能な性能を有している。 − ワームデレケーションの場合、メンバーが一般的なグラフとして相互接続される必要がある。集合は、グラフ中のノードをトラバースすること、例えばネットワークルーティング用の「最短パスアルゴリズム」によって委任する。ワームに影響する問題として、サイクル検出、ゴール探索、予測不能最悪ケースでの性能を挙げることができる。 − 指名デレゲーションは、委任するコンフェデレートが委任されるコンフェデレートを直接識別できる場合である。これは分割された問題で頻繁に起こる。例えば、電話番号は多くのディレクトリに分けることができ、調べれば任意の番号を正しいディレクトリにデレゲートさせることができる。指名デレゲーションでは、予測可能で満足な性能が発揮される。 − 同報通信デレゲーションは、委任するコンフェデレートが委任される特定のコンフェデレートを識別できない場合であり、従って唯一の解決策はコンフェデレート全てに委任し応答を集めることである。例えば統合警報ログでは、過去５分間に同報通信されるべく起きた警報を照会により探す必要がある。同報通信デレゲーションの性能は予測できるが貧弱である。こうしたデレゲーション手法は全て、優雅故障を提示できる。ツリー降順、指名の両デレゲーションはオペレーション全てを実行済みであると証明している点で権威がより高い。ワーム、同報通信の両デレゲーションは解の一部でないメンバーにより影響されるので、これらのアルゴリズムは時には部分的実行を不正確に報告する。シングルポイントの故障を避けるため、指名、同報通信の両フェデレーションは、オペレーションが実行されるべき集合オブジェクトの選択をクライアントに提供すべきである。詳細は下記の統一サービスパタンの説明を参照されたい。上記説明から得られる結論の一部を以下に示す。 − ツリー降順デレゲーションは終始良好な性能を示す。 − ワームデレゲーションは特に貧弱な性能を示す場合があるが、問題によっては良好な性能を示す。例えば電話通信ネットワークは任意の２つの終端点間で短路パス（５ホップス以下）を持つよう設計されているが、ワームはこうしたネットワークで最短パスを見つけるのに優れた性能を示す。 − 指名デレゲーションは良好な性能を示すが、各コンフェデレートを訪問する必要がないように問題を分けられるのが条件である。システムが大きくなるに連れ、この必要性が増し真実味も増すようである。例えば、プリンタ集合オブジェクトが３つあり、読者が持っている３００台の内の殆どに特定の照会をする場合、指名デレゲーションなら依然として３台にしか照会をしないであろう。 − 同報通信デレゲーションは一定の時間内に応答するが、非常に上手く判断する訳ではない。「どう委任するか」の質問後に「誰へか」と言う質問がくる。ワームとツリー降順の両デレゲーションの手法は通常、メンバーと集合インタフェイスに含まれているデレゲーションターゲットを有している。例えば、ＣＯＳＳネーミングは、Ｎステートコンセプトであるコンテキストネームに基づいて、委任する。同報通信デレゲーションは全コンフェデレートに対し単純なソルーションデレゲートを有する。唯一必要となるのは、コンフェデレートが互いに自分の存在を知らせ合う方法である。複製登録が良好な手法となる。指名デレゲーションではもっと複雑となり、３つに分けるのが可能である。 − 誰がコンフェデレートか？同報通信デレゲーションに関しては、登録ベースとするのが良好な手法である。 − スペースをどう分割するか？自然鍵（例えばＦＤＮ）、代用鍵（例えば分割されたシークケンス番号）の何れかに基づいた分割ルールが必要となる。良好な管理では、各コンフェデレートに固有のパーティションルールを記憶させる必要がある。他者は必要に応じて固有のルールを問い合わせるようにすれば、全体構成ベースに対する必要性が避けられる。 − スペースにキーをどう付けるか？オペレーションで鍵を明らかにする、例えばオブジェクトアイデンティ又は他の鍵を回覧する。同報通信デレゲーションに影響する微妙な問題は、再同報通信をすることなくその時に知る必要のある対等者に対し初期のコンフェデレート同報通信をループすることである。解決策は多いが一部の解決策はクライアントのインタフェイスを汚す。最善の手法は、インプリメンテーションが再同報通信しない特定インタフェイスを使うことである。効率的なデレゲーションは分散システムに対し一般に重要である。これは、オブジェクト鍵とアイデンティティに影響するため、一度決めると変更しにくい設計上の決定である。やり方が拙いとスケールとフェデレートの能力を制限することになる。上記議論は幾つかのインプリメンテーション手法では確認済みであるが、特定のシステムに対しては徹底的な分析が必要である。フェデレーションパタンへとの類似性は、ＤＮＳ又はＸ．５００のようなネームサービスで、単純な照会に答えられるヘルプデスクで引き出してもよく、何故なら、より複雑な照会はもっと経験を積んだスタッフに委任され、欠陥は開発技術者に送られるからである。私的なフェデレーションインタフェイスを持つことは魅力的であり、私的なフェデレーションインタフェイスはコンフェデレートを分散フレンドにすることになる。私的なフェデレーションインタフェイスはフレンドの強力な独立特性を壊すことになる。従って、私的なフェデレーションインタフェイスはある製品に対しては許容できることだが、再使用可能なプラットホームコンポーネントには滅多に許容できない。システムは同報通信の使用を最小限にしかつワームの性能を有するよう設計されるべきとするのが好ましい。地球規模の範囲の照会に答えられるフェデレーテッド集合を設計することが、魅力的である。これは必要とする機器又はクラスターが１０台までのシステムでは許容できる。１０台を超すシステムでは上手くゆかない。詳細は分散モデルパタンについて述べた節を参照されたい。非ＣＯＲＢＡフェデレーションスキームを設計することができる。データベーススキームを公にする手法である。この低コスト機構はフレンド関係であるので、それ故にオブジェクトカプセル封入違反に関係した生まれつきの制約条件を抱えている。・統一パターンサービス統一サービスパタンとは、使いやすく信頼性のある統合集合であり、従ってフレンドパターン、集合パターン、フェデレーションパターンと共に働く。統合集合の望ましい特性を挙げると以下の通りである。 − ユーザーに気付かれずに統合される。 − サービスネームのみに基づいてクライアントがコンフェデレートを得るための機構がある場合。 − 全コンフェデレーツが任意のオペレーションに対し、速度のみを例外として全く同じ応答をする場合。 − クライアントに返却されたコンフェデレートが、許容可能な（恐らく良好な）性能を持ってねばならない場合。 − クライアントは、あるコンフェデレートで失敗しても他のコンフェデレートを得られる場合。こうした特性により統一サービスには信頼性と便利性が備わる。同報通信又は指名のデレゲーション７６を使って実行されるどの統合サービスも統一サービスでなければならない。統一サービス７５は、サービスネームに基づいてコンフェデレート７６を選択しコンフェデレート７７を再選択するためのインタフェイス７８を有している。統一サービスは図１４に示されるように、統合サービスに対する前置き方式のものとして作られている。前置き方式では、利用可能な中から「最善」のコンフェデレート７９を選択する能力が必要である。これをトレーダーオペレーションとして実行することが魅力的である。しかし、ただ一つの故障点でもこの手法を制限する可能性がある。「最善」の実行には以下の点を考慮すべきである。 − 作動していないコンフェデレートは「最善」でない。 − コンフェデレートへの負荷量は少ない方がよい。 − ネットワーク遅延が短く、帯域幅連結性が高いコンフェデレートの方がよい。チケットエージェンシーは統一サービスに似ている。チケットエージェンシーは多くのコンフェデレーツ（予約クラーク）を有する、コンフェデレートセレクタ（電話ディレクトリと呼び出し分配器）がある、全コンフェデレートは同じサービスを提供できる(一部は速度が遅いが)、１つのコンフェデレートが故障してもサービスに何ら影響しない、等の点である。ツリー降順とワームの委任フェデレーションはあるメンバー上でオペレーションを実行するのであり一般には統一サービスのための候補でないことに留意するべきである。図１５は、クライアント／サーバー８０中での統一統合サーバーのオペレーションを示す。クライアント８２、第１サーバー８３、第２サーバー８４、サービスファインダ８５と通信するＯＲＢ８１が備えられている。サービスファインダのサービスのオペレーションを以下に詳述する。エンティティＡ、Ｂ、Ｃは第１サーバー８３から、エンティティＤ、Ｅは第２サーバー８４から利用できる。統一統合サーバーである第１、第２の両サーバーの作動例は以下の通りである。１．クライアント８２がサービスファインダ８５にサーバー（特定のサービスを支援する）を要求すると、サービスファインダは第１サーバー８３を戻す。２．クライアント８２は第１サーバー８３上にオペレーションを呼び出す。３．第１サーバー８３は第２サーバー８４上にオペレーションを呼び出すが、理由は第１サーバー８３が要求全体を果たせないからである。４．第１サーバー８３が結果（エンティティＥ）をクライアント８２に戻すと、次にクライアント８２はエンティティＥ上にオペレーションを呼び出す。機能的考察本節では、ＯＲＢマスターが生成するサービスの機能的考察について述べる。ＯＲＢマスター・アーキテクチュアは、全サービスによって行われる共通の機能があることを認識しており、それら共通の機能はアーキテクチュアによりアドレスされる。多くの場合に、それらは生成されたコードまたはライブラリコードにより完璧に実行される。共通機能は以下のカテゴリー、即ち − 分散管理 − グループオペレーション − クライアント／サーバ対話の管理 − コンポーネントオブジェクトのライフサイクルにグループ分けされる。上記サービスへの導入部で説明したように、これらの機能はサービスマネジャー・オブジェクトにより実行される。・分散管理ＯＲＢマスター・アーキテクチュアにおいて、全サービスマネジャーは一体化されたサービスプロバイダーである。これは、サービスにより採用される分散モデルの詳細が当該サービスのクライアントから隠されているということである。一体化されたサービス設計パターンのおかげで、クライアントは、全コンポーネントオブジェクトを、それらが分散していることとは無関係に、単一の集合に属するものとして扱うことができる。この単一集合的考察を提供できるようにするために、全サービスマネジャーは以下のインターフェースをサポートせねばならない。即ち、「導出する」ＯＩＤを与えられると、オブジェクトのリファランスを戻すか、ORBMasterIDL::NoSuchObjectという例外を戻す。更に、サービスマネジャーはクライアントがコンポーネントオブジェクトを創造できるようにしている。即ち、「創造する」 (少なくとも)読み出しのみという属性を与えられ(サービスがＯＩＤを生成できる場合にはこれを除く)、新しいオブジェクトを創造するか、ORBMasterIDL::ObjectAlreadyExistsという例外をリターンする。備考：これらのインターフェースはＯＲＢマスターが生成するアクセスレイヤー内にカプセル化されており、概要は図３を参照されたい。システム開発ツールは、分散モデルのためにコンポーネントオブジェクトの複製とコンポーネントオブジェクトの分割の両方をサポートする。コンポーネントオブジェクトが複製されると、それらの状態は提供されるサービスにつきサービスマネジャーの内の２つ以上により記憶される。ＯＲＢマスター・アーキテクチュアは、オブジェクト・アイデンティティーのコンセプトをオブジェクトインプリメンテーションから分離することにより、オブジェクトの複製を可能にしている。システム開発ツールの最新の実施例では、オブジェクトの状態を複製するための直接サポートは提供されていない。しかしながら、この目的のために、ＯＲＢマスターファイル複製サービスがサービス開発者により使用されることができる。システム開発ツールの他の実施例では、複製に関してより多くのサポートを提供している。コンポーネントオブジェクトが分割されると、それらの状態はたった１つのサービスマネジャーにより記憶される。これらのサービスに関して、２つの関連問題、即ちＯＩＤ導出及びコンポーネントオブジェクト配置管理を説明せねばならない。分割されたコンポーネントオブジェクトのための(ＯＩＤからオブジェクトリファランスまでをマッピングしている)ＯＩＤ導出は、論理的には２段階プロセスである。まず、権限のあるサービスマネジャーを見つけて、その権限のあるサービスマネジャーにＯＩＤを導出するように、或いはMasterIDL::NoSuchObject という例外を戻すように頼む。サービスマネジャーは、他のサービスマネジャーに照会せずに、ＯＩＤがサービスのコンポーネントオブジェクトを表しているかどうかを判定できるなら、ＯＩＤに関して権限を有することになる。権限を有するサービスマネジャーはまた、(当該サービスがオブジェクトの創造をサポートする場合)権限を持つ対象となるコンポーネントオブジェクトを創造する。オブジェクト分割が用いられるとき、オブジェクト導出はオブジェクト登録ツリーを基にする。オブジェクト登録ツリーは、それらノードが、自身が根となるサブツリーに対する権限を代表しているツリーである。それらノードには結びついた名前があり、ＯＩＤはコンポーネントがこれらの名前に対応する構造を持つ名前である。ＯＩＤは、図１６に示すように、オブジェクト登録ツリー９０のノードに対応するものより多くのコンポーネントを有してもよい。サービス名、チャンク名、及び身分証という３つのコンポーネントから成るＯＩＤを例にとると、ＯＩＤ＝「プリンター／チャンク２／１２３／２４」である。本実施例のオブジェクト登録ツリーは深さ２であるが、他の実施例では任意のＯＩＤ及びいかなる深さのオブジェクト登録ツリーをサポートしてもよい。ＯＩＤは、共通の根９１に対して限定された絶対的な名前である。間近のノード９２及び９３は、例えば「プリンター」ノード９２というサービス名により、サービスを効率良くグループに分ける。オブジェクト登録ツリーの葉ノード９４、９５、９６、９７は、導出オペレーション及び(当該サービスがサポートするなら)創造オペレーションをサポートするサービスマネジャーである。ＯＲＢマスターが生成するサービスは、それらのユーザー(一般的にはシステム管理者の役割を演じているユーザーのみ)に対して、コンポーネントオブジェクトがどこに置かれるかを２つの方法、即ち、 − どのサービスもクライアントがコンポーネントオブジェクトを創造できるようにしている訳ではないが、何れのサービスマネジャーが、所定のコンポーネントオブジェクト(これは分割ルールを用いて表される)を創造するのかを特定することにより、そして − コンポーネントオブジェクトが創造された後それらを移動させて、オブジェクト登録ツリーのノードが、CosLifeCycle::LifeCycleObject::moveというオペレーションをサポートするオブジェクトとなり、ひいてはコンポーネントオブジェクトのグループをそれらのＯＩＤに基づき移動させることができるようになることにより、規定するために、サポートを提供する。分割ルールは、オブジェクトがオブジェクト登録ツリーの葉ノードに結びついた名前に創造されるとき、オブジェクトに与えられる属性のサブセット用の値からマッピングを定義する。創造オペレーションに対する属性の１つがＯＩＤである場合、仮に分割ルールがマップするオブジェクト登録ツリーの同じノードに対して導出もしないＯＩＤでオペレーションが発動されたなら、それはエラーである。分割コンポーネントオブジェクトのオブジェクト創造(がサポートされる場合)は、論理的に２段階のプロセス、即ち、 − 分割ルールがマッピングする、権限を有するサービスマネジャーを見つけそして、 − そのサービスマネジャーに、新しいオブジェクトを創造して、そのオブジェクトリファランスを、或いは当該オブジェクトが既に存在している場合には、 ORBMasterIDL::ObjectAlreadyExistsという例外を戻すように頼むこと、である。・グループオペレーショングループオペレーションは、２つ以上のコンポーネントオブジェクトに用いるオペレーションである。グループオペレーションが特定して実施されるオブジェクトのセットは、オペレーションの範囲として知られている。グループオペレーションは、コンポーネントオブジェクトよりむしろサービスマネジャーによりサポートされる。グループオペレーションは、以下の基準、即ち、 − 範囲の定義 − 部分的完了へのサポート − 委任方法 − 処理行動に従い分類される。グループオペレーションの範囲は明示的または暗示的の何れかで定義される。明示的に定義されたグループオペレーションは、サービスのコンポーネントオブジェクトによりサポートされる下層のオペレーションに基づいており、その範囲のオブジェクト毎に下層のコンポーネントオブジェクトオペレーションを発動することに相当し、それらの範囲はオペレーションに対するパラメータ(ＯＩＤのリスト)により明示的に定義されており、インプリメンテーションの効率性という理由のためにだけ存在しており、それらのインターフェースは開発者が規定する下層のコンポーネントオブジェクトインターフェースに基づきシステム開発ツールにより生成されている。一方、暗示的に定義されるグループオペレーションは、個別のコンポーネントオブジェクトに関する下層のオペレーションに基づいておらず、それらの範囲は当該サービスがサービスのコンポーネントオブジェクト全てに対してクライアントの規定するフィルターを使用することにより求められるもので、(インプリメンテーションの効率性という理由ではなく)開発者により識別される問題定義域意味論を実行するという理由から存在し、それらのインターフェースは開発者規定のインターフェースに基づくシステム開発ツールにより部分的に生成されるというものである。暗示的に定義されたグループオペレーションは照合インターフェースであるのが一般的である。コードジェネレータは、開発者規定のコンポーネントオブジェクトインターフェースから暗示的定義範囲グループオペレーション用のインターフェースを生成する。グループオペレーション規模で使用されるコンポーネントオブジェクトインターフェースは、 − リターン無効で、 − どのようなタイプのパラメータにおいてもゼロ或いはそれ以上を有し、 − どのようなタイプをも戻すことのできるオプションのアウトパラメータを有し、 − それらのデータ内容として、ORBMasterIDL::ReturnCodeという構成を含んだユーザ一例外のみを起こす、ことが望ましい。コンポーネントオペレーションは従って、以下の形式になる。ここに、 <interface>は、開発者により定義されたコンポーネントオブジェクトインターフェースの名前、 <baseoperation>は、コンポーネントオブジェクトに関して開発者が定義した下層のオペレーション、 <in arg list>は、インパラメータのオペレーションリスト、 <result type>は、アウトパラメータのタイプ、 <out param>は、オプションのアウトパラメータ、 <exception list>はオペレーションにより起きるユーザー例外のオプションのリスト、である。システム開発ツールにより生成されるＩＤＬの一例は以下の通りである。１．ストラクチャ(<interface>を含むモジュールの範囲において)：ここに、 validは、当該構造の他のフィールド(常時有効であるrcを除く)が有効であるかどうかを示し、 <out param>は、oidにより識別されるオブジェクトに付随してリターンされる値、(<base operation>がアウトパラメータを有する場合のみ存在する)、 oidは、構造がその結果を保持するオブジェクトのＯＩＤ、そして、 rcは、コンポーネントオブジェクトによりリターンされるであろう例外を表している。２．<interface><base operation>Resultのシーケンスを定義するtypedef: ３．(サービスマネジャーインターフェースに関して定義された)オペレーション：ここに、 oidsは、オペレーションの範囲、 <in arg list>は、<base operation>によりサポートされるパラメータのオプションのリスト、 resultsは、オペレーション用に得た結果のリスト、である。グループオペレーションを生成するため、開発者がシステム開発ツールを必要とする対象である、コンポーネントオブジェクトオペレーションgetNameの例を以下に示す。この例については、システム開発ツールは以下に示す追加的ＩＤＬを生成する。上で定義されたＩＤＬインターフェースをカプセル化するＣ＋＋、ＣＡＬ、及びＳＡＬインターフェースクラスは、以後「アクセスレイヤー」の節で示す例の中で説明する。暗示的に定義された範囲を有するオペレーションは、開発者により定義され、システム開発ツールに対しては暗示的に範囲を定められたグループオペレーションとして識別される。グループオペレーションはまた部分的な完了をサポートする。これは、オペレーションを実行するサービスは、当該範囲の全オブジェクトに対してオペレーションが適用されるよう全力を尽くすであろうということである。そのサービスに利用されるものには、オペレーションが適用されるであろう。範囲内のオブジェクトに接触できないときには、クライアントは報告を受けることが望ましい。暗示的に範囲が定められたグループオペレーションの場合には、サービスがコンポーネントオブジェクトを分割し、どのオブジェクトが実際に範囲に入るのか判断できなくなるので(例えば、仮にオペレーション実行時、ある分割が利用できなくなる)、これは不可能である。明示的に範囲が定められたグループオペレーションについては、システム開発ツールは、サービスが利用できない各オブジェクトに関連づけてObjectUnavailableというリターンコードを戻すことを必要条件とする。暗示的に範囲が定められたグループオペレーションについては、システム開発ツールは、サービスがORBMasterIDL：：ResultAuthorityタイプのパラメータを結果に付随させて戻すことを必要条件とする。委任方法には以下に簡単に説明するもの、即ち、 − 複製されたコンポーネントオブジェクトに基づくサービスに関するオペレーションのみに適用される方法は無い、 − 分割されたコンポーネントオブジェクトに基づくサービスに関するオペレーション及び暗示的に範囲を定められたグループオペレーションのみに適用されるよう指向性を持たせる方法、 − 分割されたコンポーネントオブジェクトに基づくサービスに関するオペレーションのみと、明示的に範囲を定められたグループオペレーション及び暗示的に範囲を定められたグループオペレーションの両方に適用されるよう拡大した方法、が含まれる。処理的オペレーションはＯＲＢマスターの他の実施例によりサポートされることになっている。・クライアント／サーバ対話(結果イテレイター)の管理照会であるグループオペレーションは、個別「結果」のリストをそれらのクライアントに戻すのが普通である。これらの照会が、照会毎にＩＤＬオペレーションを使用して実行されるなら、次のような、 − 照会クライアントは、何らかの「結果」が入手可能となる前に全ての「結果」を受信するための必要条件であるメモリを配置せねばならない、 − 照会クライアントは、全体的なオペレーションが完了するまでは「結果」の内のいくつかについて処理を始めることはできない、ということになる。結果イテレイターは、これらの問題を解決するために使用される標準設計パターンである。この設計パターンはこれらのインターフェース、即ちテンプレート化されたクラスと、ＯＲＢマスターライブラリの部分を形成するORBMaster::ResultIterator<class T>と、ＯＲＢが生成し且つテンプレート化されたクラスを使用するエージェントクラスとを限定するＩＤＬ用の標準形式を採っている。システム開発ツール結果イテレイター設計パターンは、照会を実行するために３通りのＩＤＬオペレーション、即ち、１．結果の第１バッチを戻すオペレーション、２．結果のその次のバッチを戻すオペレーション、３．クライアントが照会に興味を無くしたことを通知するためのオペレーション取り消し、を使用する。結果のバッチは、クライアントが規定した数以下の個別結果を含んだセットである。サーバは、以下に述べるように、結果の実際の数をバッチで確定する。 − 以下の何れかのことが起きるまで、即ち、（i）少なくとも１つの結果が入手できる、或いは、（ii）入手できる全データがサーチされたとサーバが確定する、までは第１バッチブロックを戻し、次に入手できるそれら結果を戻す(が、クライアントが規定した数を超えない)というオペレーション。サーバは、クライアントが照会のための識別子として使用するresultIDを出力する。サーバはまた、入手できる全データがサーバにより探索されたとき、真に設定されるブールのisLastも出力する。次のバッチを戻すオペレーションは、resultIDを入力として採る以外は、同様に行われる。一旦、１つの結果がクライアントに戻されると、各結果がたった１回限り戻されるようにするため、それはサーバにより破棄される。オペレーション取り消しは、本質的には、クライアントが照会にもはや興味を持っていないことのサーバへの通知である。これ以外のセマンティックスは有していない。サーバはこの通知を使用して、照会実行のためにそれが配置されていたリソースをリリースする。以下の例は、非常に長い列のリストを戻す、getAllの照会を示している。結果イテレイターを利用するために、この照会は以下のオペレーションにより実行される。・ライフサイクル管理クライアントがコンポーネントオブジェクトを創造できるようにしているサービスもあれば、そうでないサービスもある。クライアントがコンポーネントオブジェクトを創造できるなら、オブジェクト創造時、すでにそれの読み出しのみという属性の全てが定義されていなければならない。これは、創造オペレーションが、入力値としてそれらの属性全ての値を採るか、そうでなければサーバがそれらを生成するかせねばならない、ということを意味している。一般的には、サーバにより生成される読み出しのみという属性だけがＯＩＤである。従って、ＯＩＤは創造オペレーションに対する入力パラメータとしてクライアントにより規定されるか、或いは創造オペレーションのインプリメンテーションの一部としてサーバにより生成されるかの何れかである。アクセスレイヤークライアントアクセスレイヤー(ＣＡＬ)は、サービスを実行するオブジェクトにアクセスするのに必要なコードからアプリケーションコードを分離させる。ＣＡＬとアプリケーションコードの間のインターフェースは、サービス用のＩＤＬから生成されるＣ＋＋クラスの何れも公開しない。同様に、ＯＲＢマスター・サーバ・アクセスレイヤー(ＳＡＬ)は、アクセスするために、ＩＤＬが生成するコードからアプリケーションコードを分離させる。好適実施例のＣＡＬ及びＳＡＬについて以下により詳細を述べる。クライアントアクセスレイヤー (ＣＡＬ) クライアントアプリケーションコードとＣＡＬ間のインターフェースを提供するクラスは、 − サービスを実行する分散型オブジェクトにアクセスするために使用されるエージェントクラス、及び − エージェントクラスにより扱われるデータ構造を表現するクラスと、から成る。エージェントクラスは、アプリケーションコードからＩＤＬが生成したコードを分離させるため、且つオブジェクトを完全にカプセル化する、即ちオブジェクトのアイデンティティーとそのインターフェースとそれのインプリメンテーション（複数インプリメンテーション）をアドレスするための方法をカプセル化するため、という２つの主目的を担う。実際は、エージェントクラス及びサポートするデータ構造は、ＩＤＬについての代替Ｃ＋＋マッピングである。次の副節では、非標準代替Ｃ＋＋ＩＤＬマッピングを導入するための位置調整について説明する。・ＩＤＬのための代替Ｃ＋＋結合を提供するための位置調整代替Ｃ＋＋ＩＤＬマッピングの提供のために２つの主要な位置調整がある。１．開発者には、彼らがＣＯＲＢＡサービスの熟達した開発者となる前に多大なトレーニングが必要で、彼らにアクセスするクライアントコードも必要である。 (ａ)ＣＡＬ及びＳＡＬに対してインターフェースを定義するクラスは(標準Ｃ＋＋ＩＤＬマッピングとは異なり)、ＡＮＳＩＣ＋＋という標準テンプレートライブラリを使用する。これは、Ｃ＋＋に熟達した開発者は既にインターフェースの主要部分であるデータ構造を理解しているということを意味する。 (ｂ)標準ＩＤＬマッピングは、オプションの数をより少なくしてより単純化することによって、タスクを行う２つ以上のやり方を提示して(例えば、メモリ管理用に２つ以上のモデルがある)おり、必然的に前記ＳＡＬとＣＡＬインターフェースクラスは使用がより簡単になる。 (ｃ)標準ＩＤＬマッピングはより複雑なコンセプト(例えば、標準オブジェクトリファランスは、システム開発ツールエージェントクラスよりもより複雑なコンセプトである)をユーザーに公開する。２．ＩＤＬのための標準Ｃ＋＋マッピングは、オブジェクトアイデンティティー及びオブジェクトの可動性をアドレスしない。 (ａ)ＣＯＲＢＡオブジェクトリファランスは、一様性のために比較を行わない。 (ｂ)ＣＯＲＢＡオブジェクトリファランスは、変更(例えば、あるサーバにより実行中のオブジェクトが他のサーバに移動する)してもよい。 (ｃ)ＣＯＲＢＡオブジェクトリファランスは、あまりに大きいのでオブジェクトを持続的に記憶するためのデータベースキーとして使用するには適していない。・代替ＩＤＬ結合ＩＤＬのための代わりのクライアント側マッピングは、マッピングルールのセットに従い開発される。これらのルールは、普通以下の通りである。１．各ＩＤＬインターフェースに、Ｃ＋＋エージェントクラスが与えられる。Ｃ＋＋エージェントクラスの名前は<IDL module>＿<IDL interface>Agentである。２．エージェントクラスの継承(公開仮想)はＩＤＬインターフェースの継承を映し出し、例えば、である。３．エージェントクラスは、対応するインターフェースについて各ＩＤＬが定義したオペレーションのための方法を含んでいる。これらのオペレーション全てはＯＶＥエラーを戻し、ＩＤＬコンパイラにより生成されるデータタイプではなくＳＴＬデータタイプを使用する。４．エージェントクラスは、割り当て演算子と、ORBMaster＿Agentに関してと同じセマンティックスを有するコピーコンストラクターを提供する。５．ＩＤＬが定義したstructsはＣ＋＋クラスとして表現される。これらのクラスのためのネーミング変換は、(ＩＤＬ structの範囲により異なるが)、 <IDL module>＿<IDL interface>＿<Structurename>;又は、 <IDL module>＿<Structure name> である。６．ＩＤＬ constructs管理を表現するクラスはそれら自身のメモリを管理し、それらのデータメンバー全てのための初期値を提供するコンストラクタを有している。構築に際して、それらは提供されたデータメンバーの全てをコピーする。それらは、割り当て演算子及びソースオブジェクトの深いコピーを生み出すコピーコンストラクタをサポートする。・エージェントクラスこれらのエージェントクラスの例は、オブジェクトのクライアントの立場から見た分散型オブジェクトを表している。エージェントオブジェクトは、常時それらが表現する分散されたオブジェクトのＯＩＤを含んでいる。コンポーネントオブジェクト用のエージェントの場合には、これはコンポーネントオブジェクトのＯＩＤであり、サービスマネジャーオブジェクト用のエージェントの場合には、これはサービス名である。オブジェクトにアクセスするためにエージェントが使用されるとき、当該オブジェクトのためのＣＯＲＢＡオブジェクトリファランスも提示されねばならない。エージェントクラスは、必要時これらのオブジェクトリファランスを入手する。エージェントクラスの事例は、以下の方法、即ち、 − ＯＩＤを表現する列にそれらを結びつける、 − 同じオブジェクトを同時に両方のエージェントが代表するという割り当てに従い、エージェントを次から次へと割り当てる、 − 同じオブジェクトを同時に両方のエージェントが代表するという構築に従い、別のエージェントをソースとして利用しながらある１つのエージェントを構築する、 − それらを（アプリケーションコードではなくＣＡＬ及びＳＡＬ内のコードに対してのみ使える)ＣＯＲＢＡオブジェクトリファランスに結びつける、により、分散型オブジェクトに結合される。必要時に、ＣＯＲＢＡオブジェクトリファランスが提示されないなら、エージェントが、適当なＣＯＲＢＡオブジェクトリファランスに対してＯＩＤを自動的に導出する。エージェントクラスはまたシステム例外の妨害も行い、それらが発生するとＣＯＲＢＡオブジェクトリファランスに対してＯＩＤを再導出する。これにより、オブジェクトのクライアントによる介入なしに、異なるオブジェクトのインプリメンテーションにアクセスするために同じエージェントを使用することができる。これは、以下のような事例、即ち、 − 負荷の均衡を図るためにオブジェクトが管理者により動かされる、 − オブジェクトのある１つの複製コピーが失敗し、自動的に別物に取り換えられる、という事例においては有効である。自動的導出が首尾良くいかない場合にのみエラー表示がクライアントに戻される。エージェントクラスの目的は、ＣＯＲＢＡに従属するコードとアプリケーションコードを明確に分離させることである。この分離の結果として、ＣＯＲＢＡヘッダーファイルも、又ＩＤＬコンパイラにより生成されるヘッダーファイルも、エージェントクラス用のヘッダーファイルに含まれない。(明らかにＯＲＢコードに依存している)エージェントクラスのインプリメンテーションは、各エージェントクラスが、隠されたアクセスレイヤー(アクセスレイヤークラスヘッダーファイルは一般使用に対しては提供されず、クライアントとサーバアクセスレイヤー内の内的使用にのみ利用できる)という事例に対するポインターである私的データメンバーを含むことにより、隠蔽される。以下のクラスは、ORBMaster＿A gentというエージェントパラダイムをサポートするため、実施例のＯＲＢマスター・サポート・ライブラリの一部として提供されており、２つの目的、即ち − 例えば全エージェントクラスの共通性をカプセル化するＯＲＢマスターサーバにより実行される特定オブジェクト用のエージェントクラスにより限定される基本クラス、及び − ＯＲＢマスターサーバにより実行されるどのようなオブジェクトをも表すために使用できる、という目的を担っている。このクラスは、開発者によりアクセスされるもので、以下のようなマンページがそのために含まれている。システム開発ツールはまた、ORBMaster＿Agentから継承する特定のエージェントクラスを(ＩＤＬから)生成する。システム開発ツールは、これらのエージェントクラスを、それらを完璧に実行して生成する。ORBMaster＿Agentクラスにのように、特定のエージェントクラスは隠されたアクセスレイヤーオブジェクトを含んでいる。これらは、同様にＣＯＲＢＡオブジェクトリファランスを含んでいる。また、ORBMaster＿Agentクラスのように、これらの特定エージェントクラスは、開発者が、コピーコンストラクター、割り当て演算子、及び結合方法を使用して、エージェントを特定ＣＯＲＢＡオブジェクトに結合できるようにしている。備考：ＣＯＢＲＡオブジェクトリファランスは、システム開発ツールサービスをサポートするオブジェクトを識別するには十分でないので、エージェントはＣＯＢＲＡオブジェクトリファランスにいつも結合されるわけではない。サーバアクセスレイヤー (ＳＡＬ) システム開発ツールの実行の裏には２つの基本的な仮定がある。１．コンポーネントオブジェクトは、あるオブジェクト記憶サービスにより、常時持続して記憶されている。当該オブジェクト記憶サービスは相関性があってもよく、またＯＯデータベースでもよく、或いは(レガシーシステムまたはネットワーク管理プロトコルを介してアクセスされるネットワーク機器へＣＯＲＢＡゲートウェイを利用する場合には)外部アプリケーションでも構わない、そして、２．サービスマネジャーは、コンポーネントオブジェクトの分割を知る、即ち、与えられたコンポーネントオブジェクトについて、それらはどのサービスマネジャーがそれに対する権限を持っているのかを知っているが、それらはオブジェクト記憶サービスに、与えられたオブジェクトが実際に存在するかどうかについての知識を委任する。オブジェクト記憶サービスは、ＯＩＤを与えられると、コンポーネントオブジェクトの状態をロケートするか、若しくはＯＩＤが有効なコンポーネントオブジェクトを表していないことを標示する、アプリケーションズ・プログラム・インターフェース(ＡＰＩ)を提供する。仮に実行中のサービスが創造中及び消去中のオブジェクトのコンセプトをサポートするなら、オブジェクト記憶サービスはこのライフサイクル管理を行うＡＰＩを提供する。備考：「オブジェクト記憶サービス」という用語を使用しているが、実際のサービスは、オブジェクトを持続して記憶する以外にも、例えば、アプリケーションを完了させることなどを行ってもよい。要点は、少なくとも、ライフサイクルを管理し、オブジェクトの存在についての照会に回答し、オブジェクトを持続的に記憶することが望ましいということである。以上の仮定により、以下の事柄、即ち、 − 非分散型オブジェクト記憶サービスを使用して分散されたサービスを構築し、当該サービスがオブジェクト記憶サービスのスケーラビリティ限度まで伸縮しＯＲＢに制限を受けなくなることができる、 − コンポーネントオブジェクトの内的状態がサービスマネジャーによってアクセスできるようにすることによって、それらが権限を持つサービスマネジャーとコンポーネントオブジェクトの間のフレンド関係が探究される、 − サービスマネジャーが別々にオブジェクトが存在するトラックを保持する必要を回避し、それによりそれらが、それらとオブジェクト記憶サービスの間にあるこの情報を同期化させる必要性を排除する、そして、 − オブジェクトの状態とオブジェクトの存在についての知識の両方が、オブジェクト記憶サービスにより持続的に記憶されるので、サービスマネジャーが、コンポーネントオブジェクトインプリメンテーションオブジェクトをメモリの内外に意識的にスワップする、ということが実現する。上に説明した仮定では、ＳＡＬをカプセル化するクラスとサービスインプリメンテーションをカプセル化するクラスの間での責任の非常に明確な分離が必要条件となる。実際この分離は非常に複雑なため、ＯＲＢマスターアプローチは、本質的にＣＯＲＢＡゲートウェイサーバ設計パターンのアプリケーションである。このパターンは、普通は、レガシーシステムのカプセル化に適用されるが、しかしながら、システム開発ツールは、アプリケーションコードからＯＲＢ依存コードを引き離す際にそれが提供する利益のために、それを全サーバに適用させる。図１７は、サーバアクセスレイヤー(ＳＡＬ)のサーバＣ＋＋オブジェクトとサーバアプリケーションコードの間の対話を示している。ＳＡＬは、アクセス及びサービスマネジャーインプリメンテーション１０１用のメモリを管理し、ORBMaster＿Server Cache１０２を有するサービスマネジャーアダプタ１０を含んでいる。サーバキャッシュは、ＬＲＵのリストにあるコンポーネントオブジェクトアダプタ１０３のスワッピングを制御するが、このオブジェクトアダプタは、オブジェクト記憶サービス１０５の内外にスワップされるそれぞれのコンポーネントオブジェクトインプリメンテーションのためのアクセスとメモリを制御する。オブジェクト記憶サービス１０５は、ＲＤＢＭＳ、ＯＯＤＢＭＳ、若しくはレガシーアプリケーションであってもよく、そのサービスは１．コンポーネントオブジェクトの創造と削除、２．コンポーネントオブジェクトの存在に関する照会への回答、３．コンポーネントオブジェクトの記憶、である。・ＳＡＬ／ＳＡＣインターフェースＩＤＬが定義されたインターフェース毎に対応するのは２つのクラス、即ち、 − システム開発ツールによりスタブ形式でのみ提供されるImplクラスであって、サーバアプリケーションコード内のこれらの存在は図３に示され、 − ＩＤＬが生成されるサーバスタブから引き出され、システム開発ツールにより実行されるAdaptorクラスであって、サーバアプリケーションコード内のこれらの存在は図３に示される、というクラスである。エージェントクラスのように、Implクラスは、ＩＤＬインターフェース内の定義された各オペレーション用の方法をサポートする。実際には、これらの方法の名前及び署名は、対応するエージェントクラスのそれらに等しい。Implクラスのための提案されるネーミング変換は、 <IDL module>＿<IDL interface>Impl である。開発者は、システム開発ツールにより生成されたインプリメンテーションをスタブ上に構築することにより、これらのクラスを実際に実行させる。開発者は、これらのクラスのインプリメンテーションをオブジェクト記憶サービスに対して状態の無いゲートウェイとして選んでもよいし、また開発者はコンポーネントの状態をそれらの中にキャッシュすることもできる。インフラストラクチャクラスは、ＩＤＬコンパイラが生成されるサーバスタブから引き出される。これらのクラスは、ＯＲＢと開発者が提供するインプリメンテーションとの間にアクセス経路を提供する。インフラストラクチャクラス用に提案されるネーミング変換は、 <IDL module>＿<IDL interface>Adaptor である。サーバアプリケーションコードはImplクラス方式に直接アクセスすることは決してない。Implオブジェクトへの全アクセスは、対応するアダプターオブジェクト経由となる。これは、オブジェクトインプリメンテーションが(同じクラス内であっても)別のオブジェクトへアクセスする必要が生じたとき、エージェントオブジェクトを使用するということを意味する。開発者が、彼らが与えるコードでエージェントクラスを使用することに失敗すると、スレッドの安全性及びメモリアドレシングに関する問題を引き起こすことにもなりかねない。・ライフサイクル及びメモリ管理各Implオブジェクトのメモリ管理は、インフラストラクチャにより操作される。即ち、開発者は <IDL module>＿<IDL interface>Impl を決して直接構築したり破壊したりはせず、これは対応する <IDL module>＿<IDLinterface>Ada ptorによりなされるということである。同様に、コンポーネントオブジェクトの場合には、インフラストラクチャ(即ち、アダプタークラス)はコンポーネントオブジェクトの内外のスワッピングの初期化に責任を持つ。開発者には、あらゆるサービス特定スワップイン及びスワップアウトインプリメンテーションを提供することだけが求められる。クライアントは、サービスマネジャー上のオペレーションを介してコンポーネントオブジェクトを創造或いは消去する。コンポーネントオブジェクトのライフサイクル管理のための創造及び消去オペレーションは、システム開発ツールにとって特別なものではない。これらのオペレーションのインプリメンテーションは、他の全てのオペレーション同様に、アダプターオブジェクトに対応するサービスマネジャーImplオブジェクトまで呼び出しをするアダプターオブジェクト(この場合はサービスマネジャー用のアダプターオブジェクト)を含んでいる。サービスマネジャーオブジェクトはそれらを例示するサーバプロセスが「インストール」コマンド・ライン・オプション・セットで起動するとき、生成される。同様に、それらは、それらを例示するサーバプロセスが「ディインストール」コマンド・ライン・オプション・セットで起動するとき消去される。換言すると、インスタレーション管理者は、サービスマネジャーオブジェクトのライフサイクルを明示的に管理する。・分散問題図１７は、サーバのＣ＋＋クラスの事例が単一のプロセス内でどのように相互作用するかを示している。サービスマネジャー用のアダプタークラスは、分散コンセプトをカプセル化することに責任を持つ。これは、サービスマネジャー用の Implクラスは分散の問題には関わっておらず、それらは単一ホスト上でサービスを単に実行するだけであることを意味している。換言すると、Implクラス上の全オペレーションは、ローカルオブジェクト記憶サービスに照会することのみにより実行される。アダプターは、(適当とされる対等なサービスマネジャーへの同報通信或いは指名委任を用いることにより)適当な対等のサービスマネジャーに委任することによって分散的考察を提供する。・Ｃ＋＋クラス以下のクラスは、ＯＲＢマスターサーバのインプリメンテーションを手伝うサポートライブラリの部分として提供される。コンポーネント実行のための抽象ベースクラス；サポートライブラリの部分であっても、開発者はこれらのオブジェクトに直接アクセスしない。システム開発ツールはまた、それぞれのＩＤＬインターフェースにつき(ＩＤＬから)アダプター及びImplクラスを生成する。コンポーネントオブジェクトの場合には、ImplクラスはORBMaster＿Componentから継承される。各サービスにつき、システム開発ツールは又、main()機能を定義付けるファイルを生成する。この機能は、当該サービスのためのサービスマネジャーを実行するアダプターオブジェクトを例示する。共通のＩＤＬ以下のＩＤＬは全サービスに使用される共通データタイプを定義する。ファイル複製サービスファイル複製サービスは、ＣＯＲＢＡインスタレーション内でファイルの複製をサポートする。実施例のファイル複製サービスは以下の項目により異なる。 − 特定のＣＯＲＢＡＯＲＢ − ＯＤＢＣアクセスレイヤー − ＰＯＳＩＸ追従システムインターフェースこの制限された依存性により、相互依存性という複雑さ無しに、ファイル複製サービスのトップに他のサービスを構築することができる。ファイル複製サービスは、標準ＩＤＬインターフェース複製マネジャー及び複製クライアントをサポートするオブジェクトを使用して実行される。インスタレーション中の各ホストにつき、多くても１つの複製マネジャーオブジェクトが存在する。複製マネジャーのセットは、ピアグループに形成することができる。ピアグループ内で、全複製マネジャーはオブジェクトリファランスを、ピアグループの他の全ての複製マネジャーに対して保持する。各複製マネジャーの目的は、ファイルのセットのローカルコピーを、これらローカルコピーの内容がピアグループを通して「ほぼ」同期的に作用するように保守する。複製サービスのクライアントは、どのファイルが複製されるのかを限定する。複製クライアントオブジェクトは、それらを複製マネジャーオブジェクトと共に登録する。登録に際し、複製クライアントは、興味のあるファイルを特定する。ファイルは、ファイルのローカルバージョンが異なるホスト上で異なる名前を持てるようにしているファイル名ではなく識別子を用いて特定される。サービスは、ファイルのグループを、仮にグループの何れかのファイルが変更されたならそのグループは変更されたと見なされ、そのグループの全ファイルはグループが変更されるときに複製されるというように、単一のエンティティとして取り扱う。・仮定ファイル複製サービスは、以下の制限事項(これらは、一般的に厳密な制限というよりもむしろ大きさの度合いを表している)を条件としてファイルの複製をサポートする。 − ピアグループ毎に１０ホスト − ホスト毎に１０ファイル − ファイル毎に５００文字 − ファイル更新はほとんど起こらない(１日につき数回の変更のみ) − ピアグループの全ホスト上のクロックは約１０秒以内までで同期的に作動する。 − １つのファイルへの変更は、分散されたオペレーションを使用してファイルの別のコピーへと伝播される。コピーは、従って、変化がそれらに伝播するまでは、データ外にあり、変更は全ホストに伝播され、変化発生の１分以内に変更を作り出したホストに到達できる。 − 仮にホストが変更のソースとの接続性を失っても、接続性を再度得ると５分以内にホストはソースと整列する。・インターフェース定義モジュール以下はインターフェース定義モジュールの例である。・ピアグループを定義するピアグループの全複製マネジャーは、そのピアグループの他の全複製マネジャーの自身のローカル知識を保守する。それらは、ＣＯＲＢＡオブジェクトリファランスを用いてこれを行う。複製マネジャーを初期化するサーバプロセスが、インストールモードで起動するなら、それは持続的な複製マネジャーを創造し、そのＣＯＲＢＡオブジェクトリファランスを、そのサーバが実行中のホストと同じ名前で(よく知られたディレクトリの)ファイルに記憶する。ロードピアオペレーションが発動されるとき、ピアグループの複製マネジャー用のＣＯＲＢＡオブジェクトリファランスの完全なセットが、よく知られたディレクトリにファイルとして記憶されているはずである。ＣＯＲＢＡオブジェクトリファランスを含んでいるディレクトリの内容が、ピアグループのホスト毎に確実に同じになるようにすることは、管理タスクである。ロードピアオペレーションは、関連データベースのピアのためのオブジェクトリファランスを記憶する。複製マネジャーが、インストールモード以外のモードで起動するとき、そのデータベースを用いてピアを入手する。これは、複製マネジャーが起動する能力が、ローカルデータベースの有効性に唯一依存しているということを意味している。ピアグループを初期化するための管理手順は次のようになる。 − ピアグループの複製マネジャーをサポートしている全サーバをインストールモードで起動する − それぞれは、それらのＣＯＲＢＡオブジェクトリファランスを、ローカルホスト名をファイル名として用いて、ファイルに書き込む。 − 各ホストが確実にＣＯＲＢＡオブジェクトリファランス・ファイルのセットを持つようにする(ここで、ＣＯＲＢＡオブジェクトリファランスを含んでいるディレクトリがＮＦＳを使用してマウントされるなら必要条件は無し)。 − ピアグループの各複製マネジャー上でロードピアオペレーションを発動する。ファイル複製サービスに依存するサービスは、ピアグループが初期化された後に初めて起動することができる。・クライアント登録を管理する複製マネジャーインターフェース上のレジスタークライアントオペレーションは、特定のクライアントオブジェクトがどのファイルグループに興味があるのかを限定する。アンレジスタークライアントは登録を行わない。ファイルグループは(ファイル名ではなくて)ストリングスによって識別される。クライアント登録は複製マネジャーにより持続される。クライアントは彼らが登録されるファイルグループに変更が生じた場合には通知されるが、しかしながら、ファイルグループ変更時にクライアントが複製マネジャーにより連絡不可能な場合には、その後可能になっても、クライアントへの通知は試みられない。ダウンしている間に生じた何らかの変更に確実に変更に気づくために、起動時にそのファイルの最新のコピーを入手することはクライアントの責任である。・ファイル変更のためのソースプッシュ・アルゴリズムファイル複製サービスは、それが複製するファイルがファイルシステム経由で直接変更できることを仮定している。各複製マネジャーは、クライアント登録を有する対象であるファイルグループが変更されているかどうかを判断するため、一定(設定可能)間隔でファイルシステムをポーリングする。一旦、複製マネジャーが、ファイルグループは変更されていると判断すると、それらに関してアップロードオペレーションを発動することにより、そのピア全部に対して変更されたファイルグループをプッシュする。それはまた、関心のある全クライアントに、彼らに関して更新オペレーションを発動することにより通知する。アップロードオペレーションを発動するとき、それは、グループのファイルにつきファイルグループバージョン番号(アップロードオペレーションに対するバージョンパラメータ)として最新のファイル変更タイム(１９７０年１月１日００：００：００時以来数秒内)を使用する。新しいバージョン番号がそれの全てのピアに対して確実にプッシュされるようにすることは、変更(ソース)を検知した複製マネジャーの責任である。これは、(たとえ停止してその後再起動しても)成功するまで、それがアップロードオペレーションを繰り返し試みることを意味している。再試行間隔は設定可能である。アップロードオペレーションが発動されるとき、対象となる複製マネジャーは入力ファイルグループがそのローカルコピーよりも新しいかどうかをチェックする。それは、入力バージョンパラメータとそれの記憶値を比較することによりこれを行う。これらにシステムクロック(設定可能)の最大エラーの範囲を超えて違いがあるなら、最も間近の値がより大きなバージョン番号として採られる。そうでないなら、バージォン番号は無視され、入力ホスト名とローカルホスト名が比較される。最も間近ものが、より大きいと判断するものとして採られる。ホスト名に関してこの任意の配列を使用するということは、ほとんど同時に２つ以上の異なる変更が生じた場合に、成功するのはたった１つであるということを意味する。入力値がより間近なものなら、複製マネジャーはそのローカルコピーを更新し、そのクライアントに通知し、そして入力バージョン番号をグループのためのバージョン番号として記憶する。仮に入力値がより間近なものでなければ、複製マネジャーは戻すだけである。バージョン番号の他にも、複製マネジャーは、各ローカルファイルに付随してタイムスタンプを持続的に記憶する。それらは、ファイル変更時に検知できるようにするためこれを行う。起動時、それらは、終止中にファイルグループが変更されているかどうかを、持続的に記憶されているタイムスタンプとファイルシステムから得る値を比較することにより判断する。これらのタイムスタンプを持続的に記憶することにより、「終止中のファイル変更」という事態を、上に述べたように正常なファイルグループ変更として取り扱うことができる。・ピアグループ起動複製マネジャーが創造されるとき、その記憶されたバージョン番号とファイルのタイムスタンプはゼロに設定される。クライアント登録が発生すると、複製マネジャーは、記憶されたタイムスタンプが実際の値より少ないことを検知するので、ファイルのローカルコピーを全ピアに対してプッシュする。ピアグループを起動させる最も効率的な方法は、各ファイルグループのピアグループ内でコピーをたった１つだけ持つということである。サービスファインダーサービスサービスファインダーサービスは、インターフェースのサービスロケーターとサービスマネージャーをサポートするオブジェクトを使って実行される。インストレーション中の全ホストは多くて一つのサービスロケーターを有している。サービスロケーターはサービスマネージャーの格納位置を管理し、クライアントが、サービスネームに基づいてサービスマネージャーを探し、サービスロケーターに接近して位置を見つけ出せるようにしている。サービスファインダーサービスは次の事項に依存している。 − 指定された特定のＣＯＲＢＡＯＲＢ、 − ＯＤＢＣアクセスレイヤー、 − ＰＯＳＩＸ式システムインターフェース、 − ＣＯＲＢＡ通知サービス・前提条件次の条件を実施例に適用する。 − インストレーションは、約１０のホストから構成されている。 − インストレーション内のホストは、インストレーションタイムで規定されており、変更されない。 − サービスマネージャーは、インストレーションに流動的に加えられても、除かれてもよい。・インターフェース定義・サービスロケーター一つのピアーグループ内の全サービスロケーターが、そのピアーグループ内の他の全てのサービスロケーターが有しているローカルな知識を保持する。本実施例では、ＣＯＲＢＡオブジェクトリファランスを用いてこれを行う。サービスロケーターを例示するサーバープロセスがインストールモードで開始されると、サーバープロセスは、持続性のあるサービスロケーターを作りだし、サーバーが実行しているホストと同じネームを持った、ファイル（よく知られているディレクトリ内に）内にそのＣＯＲＢＡオブジェクトリファランスを記憶する。ロードピアーオペレーションが呼び出されると、そのピアーグループ内のサービスロケーター用のＣＯＲＢＡオブジェクトリファランスの全セットが、よく知られているディレクトリにファイルとして記憶されなければならない。ＣＯＲＢＡオブジェクトリファランスを含むディレクトリの内容がピアーグループ内の全ホストに共通するものであることを確認するのは、管理的タスクである。ロードピアーオペレーションは、そのピアーグループ内の全サービスロケーターを検索するため、ＣＯＲＢＡオブジェクトリファランスを含んでいるファイルを読む。ロードピアーオペレーションは、ピアー用のオブジェクトリファランスを関連するデータベースに記憶する。サービスロケーターがインストールモードとは別のモードで始動すると、データベースはピアーを獲得するために使われる。このことは、サービスロケーターが始動する能力は、単にローカルデータベースの可用性によることを示している。ピアーグループを初期化するための一般的な管理手続きは次のようなものである。 − ピアーグループ内のサービスロケーターをサポートしている全サーバーをインストールモードで始動させると、各々がファイル名としてローカルホスト名を使っているファイルに、各々のＣＯＲＢＡオブジェクトリファランスを書き出す。 − 各ホストはＣＯＲＢＡオブジェクトリファランスの全セット（ＣＯＲＢＡオブジェクトリファランスを含んでいるディレクトリがＮＦＳを用いて装備されるなら、ここでは必要ない）を有することを確認する。 − ピアーグループ内の各サービスロケーター上にロードピアーオペレーションを呼び出す。各サービスロケーターは、それぞれが登録しているサービスマネージャーの継続リストを保持している。各サービスロケーターはＯＤＢＣアクセスレイヤーを使って、このリストを関連あるデータベースに記憶する。サービスロケーターはそのピアーサービスロケーターによって管理されている登録は記憶しない。クライアントは、何れかのサービスロケーターでゲットベストマネージャーを呼び出すことによって、特定のサービス用のサービスマネージャーを要求する。クライアントがサービスマネージャーを要求する環境は一般的に二通りある。１．クライアントが、まずサービスマネージャーと交信しようとして、エージェントを拘束しているか、又は２．クライアントが、サービスマネージャーと交信しようとして、システムの例外を行っている。本サービスは、求められたときは（すなわち通常は前記１のケース）大方のサービスマネージャーが入手可能であるという前提で設計されている。このことはクライアントがそうするという明確な要求がなければ、サービスがサービスマネージャーの可用性をチェックしないことを意味する。クライアントは単に、サービスマネージャーが利用できなくなっている（すなわち前記２のケース）と考える理由があるとき、ただチェックを要求する。可用性について全サービスマネージャーが確認されるとすれば、サービスマネージャーを求める声に応じる際にキャッシュメモリーを使ってもほとんど問題はない。しかしながら、通常、可用性の確認はなされないので、サービスロケーターが要求に応じるときにはキャッシュメモリーを使うと効果がある。従って、各サービスロケーターは、サービスマネージャーの位置を確認するための先の試みの結果から得られるタプル（サービス、ネーム、サービスマネージャー）を記憶するローカルなインメモリーキャッシュを保持している。キャッシュに記憶されているタプルは、サービスのマネージャーを求める広範な要求に対する第一の応答に対応する。クライアントは、通信が不履行になれば、testRequiredのパラメータを真にセットし、さもなければ偽にセットする。従って、getBestManagerの要求の処理は、次に述べるように、 testRequiredパラメータの値にかかっている。 getBestManagerオペレーションが呼び出されると、返すべきサービスマネージャーを決めるために、次のような段階が用いられる。 − 特定のサービスに関してサービスロケーターに登録されているサービスマネージャーがあれば、それを返すか、又は − もし特定のサービスに関するキャッシュにエントリーがあれば、それを戻すか、又は、 − getLocalManagerの要求を全ピアーサービスロケーターに同報通信する。T estRequiredパラメータは、遠隔同報通信がなされていれば、サービスマネージャーと接触する余分な時間はそれほど重要ではないので、これらのオペレーションに対し真にセットされる。獲得された第一の応答はキャッシュ内に置かれ、クライアントに戻される。 getBestManagerオペレーションが呼び出されると、返すべきサービスマネージャーを決めるために、次のような段階が用いられる。 − 特定のサービスに関してサービスロケーターに登録されているサービスマネージャーがいれば、それと交信してみる(そのロケーション属性を得る)。 − 接触できれば、それを戻す、又は、 − 特定のサービスに関してキャッシュにエントリーがあれば交信してみる。接触できればそれを戻すか、さもなければキャッシュエントリーを無効にすし、そして、 − getLocalManagerリクエストを全ピアーサービスロケーターに同報通信する。TestRequiredパラメータは、これらのオペレーヨンに対し真にセットする。最初に得られた応答がキャッシュ内に置かれ、クライアントに返される。・サービスマネージャーピアーグループを定義すると次のように考えられる。何れかのサービスロケーターにおいてgetAllRegisterdManagerオペレーションを呼び出し、適当なサーバーネームを指定すれば、サービスマネージャーのピアーグループのメンバーを獲得できる。このオペレーションはサービスマネージャーの位置を確認するために同報通信を用いるので、コストの高いオペレーションになるかもしれない。一般的には、グループ内の他のピアーを決める必要があるのは、ある特定のピアーグループそのもののメンバーである。従ってサービスロケーターは、コストの高いgetAllRegisterdManagerオペレーションに替えて、自分たちのピアーグループをサービスマネージャーに記憶させることができる。そのピアーグループにメンバーの出入りがあったときはいつでも通知を送ることにより、これを行う。サービスマネージャーが自分たちのピアーグループメンバーシップリストを保持したいと望めば、通知受取人として、通知制作者であるローカルサービスロケーターに登録しなければならない。図１８に図式化してあるように、サービスロケーターは、何時メンバーがグループに出入りしたかの情報を、notifyAddManag er及びnotifyRemoveManagerオペレーションを使って配布する。配布の段階は次の通りである。１．ロケーションＸ１１０に対するサービスマネージャーは、ローカルサービスロケーター１１１にロケーションを登録する。２．ローカルサービスロケーター１１１は、notifyAddManagerプロセスをそのピアーサービスロケーター１１２、１１３、及び１１４の各々に呼び出す。３．サービスロケーターは、サービスマネージャーのオブジェクトリファランスを含んでいる通知を通知サービス１１５に送り、その通知はピアーサービスマネージャー１１６及び１１７で受信される。そうすると、サービスマネージャーは、イニシャルコンテンツを得るためにgetA llRegisterdManagerを用い、それを保持するために通知を用いて、自分たちのピアーのキャッシュを作り出すことができる。概要上記説明により、本発明の開発ツールは大規模オブジェクト指向システムの開発者に次の有用性を提供するということが理解頂けるであろう。（ａ）開発チームメンバーに関するトレーニングコストが削減される。ＣＯＲＢＡの読み書きができる必要はなく、それ以上にＣＯＲＢＡ専門家である必要はない。（ｂ）本開発ツールは、特定の需要に適合するようにパック化された使用モデルを含んでいるので、設計時間が短縮される。（ｃ）コード発生器及びライブラリーは、信頼性が証明済みのモジュールを提供するのでコーディング時間が短縮され、又、本ツールはクライアントとサーバーのアプリケーションコードに単純化されたインターフェースを提示する。更に、（ｄ）開発者が書き込むコードは少なく、複雑でなく、誤った使用をしないよう指導してもらえるので、テスト時間が短縮される。本発明のシステム開発方法とツールを使えば、開発者は、アプリケーションサービスを供給するために必要とされる分散型オブジェクト指向のインフラストラクチャではなく、アプリケーションの機能性を提供することに焦点を絞ることができるようになる。本発明のシステム開発方法とツールが、ＯＭＧのＣＯＲＢＡ以外の分散型オブジェクト指向システムアーキテクチュアに対して、実質的に同様の有用性をもって適用できると理解することも重要である。本システム開発ツールは、性能と規模を拡張するために現在のコンピューターアプリケーションに分散を加えたり、あるいは統一されたアクセス方法を提供するためにシステムを見えないように統合するのに適している。特に本システム開発ツールは、分散型遠隔通信又は金融サービス用の新しいシステムを開発するのに適している。明細書全体を通しての目的は、本発明の好適実施例を説明することであり、本発明を一つの特定の実施例、又は特別な特徴の集合に限定するわけではない。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＡＵ，ＣＡ，ＪＰ，ＵＳ【要約の続き】の、各サーバープロセス用サーバーアクセスレイヤー（２８）と、ユーザーがサーバーセマンティックスのインプリメンテョンを統合するための規則を含む、各サービスを実行するためのサーバーアプリケーションコードのスタブ部（２９）とを生成するために配置されている。基本分散型サービスのセットは、システム内でファイルを複製するためのファイル複製サービス（３０）及びシステム内で利用可能なサービスの検索のためのサービスファインダーサービス（３１）を含んでいてもよい。

Claims

【特許請求の範囲】１．大規模分散型オブジェクト指向のコンピューターシステムを構築するための開発ツールであって、前記システムは複数のクライアントと、複数のサーバーと、サービスに関するクライアントの要求をサーバーへ通信するための分散型オブジェクトのインフラストラクチャとを含み、前記開発ツールは、（ａ）（ｉ）各オブジェクト固有のアイデンティフィケーションを容易にするオブジェクトアイデンティティパターンと、（ｉｉ）あるコモナリティを有するオブジェクトの論理的グルーピングを容易にする集合パターンと、（ｉｉｉ）オブジェクトのセットに目標を絞ったオペレーションを容易にするグループオペレーションパターンと、（ｉｖ）クライアントとは無関係に一つのオブジェクトともう１つのオブジェクトとの連携を容易にするフレンドパターンと、（ｖ）システムの性能を目的にオブジェクトの物理的グルーピングを容易にするパーティションパターンとを含む予め定められたオブジェクト設計パターンを提供する一連のテンプレートと、（ｂ）クライアントプロセスによって要求されることになる所望のサーバープロセスを定義するために、そして設計パターンの内の選択されたものを組み込むためにユーザーによって作り出されるオブジェクト指向システムモデルから以下の、（ｉ）分散されたオブジェクトインフラストラクチャからクライアントアプリケーションコードを切り離すための、各クライアントプロセス用のクライアントアクセスレイヤーと、（ｉｉ）分散されたオブジェクトインフラストラクチャからサーバーアプリケーションコードを切り離すための、各サーバープロセス用のサーバーアクセスレイヤーと、（ｉｉｉ）ユーザーがサーバーセマンティックスのインプリメンテーションを統合するための規定を含む、各サービスを実行するためのサーバーアプリケーションコードのスタブ部とを生成するために配置されているコード発生器と、から成ることを特徴とする開発ツール。２．前記システム内で利用可能なサービスの検索のためのサービスファインダーサービスを含む基本的分散型サービスのセットを更に含むことを特徴とする、上記請求項１に記載の開発ツール。３．前記一連のテンプレートが以下のオブジェクトデザインパターン、即ち（ｖｉ）改善されたサービスを提供するために協働する集合のセットであるフェデレーションパターン、（ｖｉｉ）フェデレーション内のセットからの集合の最適選定を容易にする統一されたサービスパターン、及び/又は（ｖｉｉｉ）特別にアイデンティファイされたオブジェクト上での複数のオペレーションを容易にする大容量オペレーションパターン、の中から一つ又はそれ以上を更に含んでいてもよいことを特徴とする、上記請求項１又は２の何れかにに記載の開発ツール。４．オブジェクトアイデンティティがオブジェクトの属性であり、構造化名を使って表されることを特徴とする、上記請求項１から３の何れかに記載の開発ツール。５．前記オブジェクトアイデンティティの属性がオブジェクトの複製を考慮していることを特徴とする、上記請求項４に記載の開発ツール。６．集合にグルーピングされたオブジェクトがメンバーとして知られ、集合のメンバーの知識が明示的に又は暗示的にの何れかで保存されていることを特徴とする、上記請求項１から５の何れかに記載の開発ツール。７．グループオペレーションが適用されるオブジェクトのセットがグループオペレーションの範囲として知られており、その範囲が明示的に又は暗示的に定義されてもよいことを特徴とする、上記請求項１から６の何れかに記載の開発ツール。８．明示的に定義されるグループオペレーションがサービスから成るオブジェクトによりサポートされている基本的なオペレーションに基づいており、オブジェクト識別子のリストがグループオペレーションの範囲を定義することを特徴とする、上記請求項７に記載の開発ツール。９．暗示的に定義されるグループオペレーションが基本的なオペレーションに基づくのではなく、クライアント指定のフィルター又は規則がグループオペレーションの範囲を定めるためにオブジェクトに適用されることを特徴とする、上記請求項７に記載の開発ツール。１０．二つのオブジェクトが分散型オブジェクトインフラストラクチャを通してクライアントと関連しては現れず、相互に関連して現れるのであれば、二つのオブジェクトはフレンドであることを特徴とする、上記請求項１から９の何れかに記載の開発ツール。１１．パーティションがオブジェクトの物理的グルーピングであり、システム内の各オブジェクトが一つのパーティションにだけ関係しており、そのパーティションはコンピューターのハードウェアの１つのセットに対応していることを特徴とする、上記請求項１から１０の何れかに記載の開発ツール。１２．フェデレーション内の集合が、より速く、より広く又はより信頼性のあるサービスを提供するために、互いにオペレーションを委任できることを特徴とする、上記請求項３から１１の何れかに記載の開発ツール。１３．統一されたサービスが、予め定められた集合のサブセットが統一たサービスを要求するクライアントには見えないようになっている、統合された集合であることを特徴とする、上記請求項３から１２の何れかに記載の開発ツール。１４．前記クライアントアクセスレイヤーが、サービスを実行するオブジェクトにアクセスするためのエージェントクラスと、そのエージェントクラスにより操作されるデータ構造を表すための別のクラスとを含むことを特徴とする、上記請求項１から１３の何れかに記載の開発ツール。１５．前記エージェントクラスが、分散型オブジェクトインフラストラクチャ用のインターフェースコードを、クライアントアプリケーションコードから効果的に分離し、そのインプリメンテーションに取り組むために、オブジェクトのアイデンティティと、インターフェイスと、方法とをカプセル化することを特徴とする、上記請求項１４に記載の開発ツール。１６．前記サーバーアクセスレイヤーが、何れかのパーティションに関してオブジェクトを管理するためのサービスマネージャーを含み、オブジェクトの創造と削除を考慮することを特徴とする、上記請求項１から１５の何れかに記載の開発ツール。１７．前記サーバーアクセスレイヤーが、サービスを実行するオブジェクトへのアクセスを提供するためのアダプタークラスを含むことを特徴とする、上記請求項１６に記載の開発ツール。１８．前記基本的分散型サービスのセットが、システム内のファイルを複製するためのファイル複製サービスを更に含むことを特徴とする、上記請求項２から１７の何れかに記載の開発ツール。１９．前記システムが、（ａ）分散型オブジェクトインフラストラクチャがオブジェクトリクエストブローカーから成る、（ｂ）オブジェクト指向システムモデルがＣＯＲＢＡコンセプトを用いてモデル化される、（ｃ）サーバーインターフェースがＣＯＲＢＡインターフェース設計言語（ＩＤＬ）に従って生成される、というようなＣＯＲＢＡ標準を利用することを特徴とする、上記請求項１から１８の何れかに記載の開発ツール。２０．大規模分散型オブジェクト指向のコンピューターシステム開発のための方法であって、前記システムは複数のクライアントと、複数のサーバーと、クライアントのサービスに関する要求をサーバーへ通信するための分散型オブジェクトインフラストラクチャとを含み、前記開発方法は（ａ）（ｉ）各オブジェクトの固有のアイデンティフィケーションを容易にするオブジェクトアイデンティティパターンと、（ｉｉ）あるコモナリティを有するオブジェクトの論理的グルーピングを容易にする集合パターンと、（ｉｉｉ）オブジェクトのセットに目標を絞ったオペレーションを容易にするグループオペレーションパターンと、（ｉｖ）クライアントとは無関係に一つのオブジェクトともう一つののオブジェクトとの連携を容易にするフレンドパターンと、（ｖ）性能目的にオブジェクトの物理的グルーピングを容易にするパーティションパターンとを含む、予め定められたオブジェクト設計パターンのための一連のテンプレートから一つまたはそれ以上のテンプレートを選択する段階と、（ｂ）クライアントプロセスによって要求されることになる所望のサーバープロセスを定義するための、そしてそのモデルが選択されたオブジェクト設計パターンを組み込むところの、オブジェクト指向システムモデルを作る段階と、（ｃ）前記オブジェクト指向システムモデルから、以下の（ｉ）分散型オブジェクトインフラストラクチャからクライアントアプリケーションコードを切り離すための、各クライアントプロセス用のクライアントアクセスレイヤーと、（ｉｉ）分散型オブジェクトインフラストラクチャからサーバーアプリケーションコードを切り離すための、各サーバープロセス用のサーバーアクセスレイヤーと、（ｉｉｉ）ユーザーがサーバーセマンティックスのインプリメンテーションを統合するための規定を含む、各サービスを実行するためのサーバーアプリケーションコードのスタブ部のためのコードモジュールを生成する段階とから成ることを特徴とするシステム開発のための方法。２１．前記システム内で利用可能なサービスの検索のためのサービスファインダーサービスを含む基本的分散型サービスのセットを提供する段階を更に含むことを特徴とする、上記請求項２０に記載のシステム開発のための方法。２２．前記段階（ｃ）における選択に利用可能な前記一連のテンプレートが、更に以下のオブジェクト設計パターン、即ち（ｖｉ）改善されたサービスを提供するために協働する集合のセットであるフェデレーションパターン、（ｖｉｉ）フェデレーション内のセットからの集合の最適選定を容易にする統一されたサービスパターン、及び/又は（ｖｉｉｉ）特別にアイデンティファイされたオブジェクト上での複数のオペレーションを容易にする大容量オペレーションパターンの内の一つ又はそれ以上を含んでいてもよいことを特徴とする、上記請求項２０又は２１の何れかに記載のシステム開発のための方法。２３．オブジェクトのアイデンティティ属性を構造化名を使って表す段階を含むことを特徴とする、上記請求項２０から２２の何れかに記載のシステム開発のための方法。２４．前記オブジェクトのアイデンティティ属性が、オブジェクトの複製を考慮していることを特徴とする、上記請求項２３に記載のシステム開発のための方法。２５．メンバーとして集合にグルーピングされたオブジェクトを参照し、集合のメンバーの知識を明示的に又は暗示的にの何れかで保持する段階を含むことを特徴とする、上記請求項２０から２４の何れかに記載のシステム開発のための方法。２６．グループオペレーションの範囲としてグループオペレーションが適用されるオブジェクトのセットを参照する段階であって、前記範囲が明示的に又は暗示的に定義されていてもよい、そのような段階を含むことを特徴とする、上記請求項２０から２５の何れかに記載のシステム開発のための方法。２７．フレンドオブジェクトが、分散型オブジェクトインフラストラクチャを通してクライアントと関連しては現れないが、相互に関連して現れるようにフレンドオブジェクトを配置する段階を含むことを特徴とする、上記請求項２０から２６の何れかに記載のシステム開発のための方法。２８．オブジェクトの物理的グルーピングをパーティションに割り当てる段階であって、システム内の各オブジェクトがそのようなパーティションの一つとだけ関係しており、前記パーティションがコンピューターのハードウェアの１つのセットに対応している、そのような段階を含むことを特徴とする、上記請求項２０から２７の何れかに記載のシステム開発のための方法。２９．フェデレーション内の集合が、より速く、より広く、又はより信頼性の高いサービスを提供するために、別の集合にオペレーションを委任することを許容する段階を含むことを特徴とする、上記請求項２２から２８の何れかに記載のシステム開発のための方法。３０．統一されたサービスを要求するクライアントには見えなくなるように、統合された集合内に予め定められた集合のサブセットを配置する段階を含むことを特徴とする、上記請求項２２から２９の何れかに記載のシステム開発のための方法。３１．前記クライアントアクセスレイヤーを生成する段階が、サービスを実行するオブジェクトにアクセスするためのエージェントクラスと、前記エージェントクラスによって操作されるデータ構造を表す別のクラスとを生成する段階を含むことを特徴とする、上記請求項２０から３０の何れかに記載のシステム開発のための方法。３２．前記エージェントクラスを生成する段階が、分散型オブジェクトインフラストラクチャ用のインターフェースコードをクライアントアプリケーションコードから分離し、オブジェクトのアイデンティティと、インターフェースと、そのインプリメンテーションに取り組むための方法とをカプセル化する段階を含むことを特徴とする、上記請求項３１に記載のシステム開発のための方法。３３．前記サーバーアクセスレイヤーを生成する段階が、全てのパーティションに関してオブジェクトを管理するためのサービスマネージャーの規則を含み、前記サービスマネージャーはオブジェクトの創造と削除を容易にすることを特徴とする、上記請求項２０から３２の何れかに記載のシステム開発のための方法。３４．前記サーバーアクセスレイヤーを生成する段階が、サービスを実行するオブジェクトへのアクセスを提供するために、アダプタークラスの規則を含むことを特徴とする、上記請求項３３に記載のシステム開発のための方法。３５．前記基本的な分散型サービスのセットを提供する段階が、システム内のファイルを複製するためのファイル複製サービスを提供することを更に含むことを特徴とする、上記請求項２１から３４の何れかに記載のシステム開発のための方法。３６．請求項１から１９の何れかに記載の開発ツールを用いて、又は請求項２０から３５の何れかに記載の方法に従って作られる大規模オブジェクト指向システムにおいて、前記オブジェクト指向システムが、共通の管理インターフェースを含むことを特徴とする大規模オブジェクト指向システム。３７．前記共通の管理インターフェースが、テスト、使用可能、使用不可能、バックアップ及び再スタートの機能の規則を含む、システム内の統一された全サービスの遠隔管理を容易にすることを特徴をする、上記請求項３６に記載の大規模オブジェクト指向システム。３８．前記管理インターフェースは、統一された各サービスを照会できる、バージョン番号、著作権情報、ステータス、ホスト機器、プロセスアイデンティティ、又は同等の属性の中の一つ又はそれ以上を含めた属性のセットをサポートすることを特徴をする、上記請求項３７に記載の大規模オブジェクト指向システム。