JP2005539295A - ウエブサービス装置及び方法 - Google Patents

Abstract

ウエブサービスシステムにおいて使用する方法が、データリポジトリへのアクセスを与え、且つ前記データリポジトリのサーチを行う場合に使用するシャドウ属性を与える、ことを包含している。

Description

本開示は、一般的に、ＵＤＤＩレジストリ及びウエブサービスに関するものであって、更に詳細には、このようなサービスに対して実際的な効果を与える場合に使用される方法、装置及びシステムに関するものである。

ＵＤＤＩ（Ｕｎｉｖｅｒｓａｌ Ｄｅｓｃｒｉｐｔｉｏｎ， Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｉｎｔｅｇｒａｔｉｏｎ）は、ウエブサービスを使用するアプリケーションが迅速に、容易に且つ動的に互いに相互作用することを可能とすべく定義されている一組のスタンダードである。ＵＤＤＩは、サービスを記述し、ビジネスを発見し且つオペレーショナルレジストリのみならずインターネットを使用してシステムサービスを統合するプラットフォーム独立性でオープンなフレームワークを形成することを意図している。更なる詳細についてはｗｗｗ．ｕｄｄｉ．ｏｒｇのウエブサイトを参照すると良い。

ＵＤＤＩレジストリは、ウエブサービスを使用して構成されるシステムに対して貴重なサポートを提供する。図１ａは基本的なウエブサービス及びＵＤＤＩ概念を概略的に例示している。図１ｂはウエブサービス環境に対する簡単化したプロトコルスタックを概略的に例示している。ＵＤＤＩはウエブサービス情報に対するリポジトリを与え且つそれ自身ウエブサービスにより与えられる。

ＵＤＤＩはアプリケーションがウエブ上でどのようにして相互作用することを希望するかをパブリッシュすることを可能とする。各「ウエブサービス」は、インターネット接続を介して他のアプリケーションに対し何等かのシステム機能性を提供するアプリケーション論理の自己記述型で自己完結型のモジュールユニットである。アプリケーションはユビキタスなウエブプロトコル及びデータフォーマットを介してウエブサービスへアクセスし、各ウエブサービスがどのようにして実現されるかについて心配する必要性はない。ウエブサービスは、より大きなワークフロー又はビジネストランズアクションを実行するために他のウエブサービスと混合及びマッチさせることが可能である。

ＵＤＤＩスタンダードは、ウエブサービスタイプ、ビジネス組織、及びどのようにしてウエブサービスを喚起させるかについての詳細の記述を管理することが意図されている特定目的リポジトリを記述する。該スタンダードは、それがどのようにして実現されるべきであるかについて、又はその実現がデータベース、ディレクトリ又は何らかのその他の媒体を使用する格納部を包含すべきであるかについて必ずしも特定するものではない。

ＵＤＤＩスタンダードに責任を有する組織により支えられているウエブサイトにおいて（ｈｔｔｐ：／／ｗｗｗ．ｕｄｄｉ．ｏｒｇ／ｆａｑｓ．ｈｔｍｌ）、多数の頻繁に訪ねられる質問（ＦＡＱ）が存在している。これらの質問のうちの１つは「ＵＤＤＩレジストリはＬＤＡＰ上に構築又はそれに基づくものとすることが可能ですか？」というものである。その回答は、このウエブサイトは、ＵＤＤＩとディレクトリとの間に何等フォーマルな関係は存在しないことを開示している。「ＵＤＤＩ仕様はレジストリ実現の詳細を支配するものではない。ＵＤＤＩ仕様はＸＭＬに基づくデータモデルを定義し且つそのデータモデルへアクセスし且つそれを取り扱うための一組のＳＯＡＰ ＡＰＩを定義する。該ＳＯＡＰ ＡＰＩはＵＤＤＩリポジトリが示す挙動を定義する。ＵＤＤＩ実現は、それが特定されている挙動に適合する限り、ＬＤＡＰディレクトリ上に構築することが可能である。これまでのところ、全てのＵＤＤＩ実現はリレーショナルデータベース上に構築されている。」
注意すべきことであるが、Ｘ．５００及びＬＤＡＰ等のディレクトリ技術は、ユーザ及びリソースを管理するために最も頻繁に使用される拡張可能で汎用のデータストア及びそれらの関連する言語である。それは非常に良く確立された技術であり、広く採用されており、且つ非常に安定で且つ信頼性があるものと考えられている。

然しながら、ディレクトリ上にＵＤＤＩスタンダード（ｗｗｗ．ｕｄｄｉ．ｏｒｇにおいて入手可能）を実現することは、多数の問題を解決することを必要とする。ＵＤＤＩスタンダードは多くの重要な問題を未対処のままとしており、例えば、
・ＵＤＤＩスタンダードは多数のオブジェクトを定義しており、そのうちの幾つかは階層により関連されているが、ＵＤＤＩは全てを取囲む階層を定義するものではない。例えば、ビジネスサービスオブジェクトはビジネスエンティティオブジェクトの下に来るものであり、且つバインディングテンプレートオブジェクトはビジネスサービスの下に来るものである。図２はこの階層の１例を例示している。ビジネスエンティティオブジェクトは２１で示してあり、ビジネスサービスオブジェクトは２２で示してあり、バインディングテンプレートオブジェクトは２３で示してある。更に注意すべきことであるが、例えば２４で示してあるＴＭｏｄｅｌオブジェクトはこれらのオブジェクトと階層的に関連しているものではない。更に、階層的に定義されているものでない例えばパブリッシャアサーション（Ｐｕｂｌｉｓｈｅｒ Ａｓｓｅｒｔｉｏｎ）等のその他の概念も存在している。

・ユーザが彼／彼女の制御下にあるオブジェクトのみを変更することが許可される条件の効率的な実現例の作成。

・ＵＤＤＩレジストリを配布させることを可能とする効率的な実現例を作成すること。

・サーチ及びアップデートの管理及び性能の側面を向上させる効率的な実現例を作成すること。

・複雑なＵＤＤＩオブジェクトを比較的に効率的な態様でどのようにして表現するか。例えば、ビジネスエンティティ、ビジネスサービス、バインディングテンプレート及び／又はＴＭｏｄｅｌは複合的反復要素を有している。更に、これらの反復要素は更なる反復要素を包含する場合がある。例えば、ビジネスエンティティはコンタクトを包含する場合があり且つ該コンタクトがアドレスを包含する場合がある。アドレスはアドレスラインと電話番号とを包含する場合がある。図１３はビジネスエンティティにおける比較的複雑なオブジェクトのＵＤＤＩ概念を概略的に例示している。ビジネスエンティティオブジェクト１３１は、例えば、ＡｕｔｈｏｒｉｚｅｄＮａｍｅ、ＢｕｓｉｎｅｓｓＫｅｙ、Ｎａｍｅ等の多数の属性１３２を包含している。Ｎａｍｅは１つ又はそれ以上の名前フィールド１３３を有しており、例えば「ｔｅｘｔ」であるか、又はこれは「ｎａｍｅ」自身の中に暗示的である場合がある。又「ｌａｎｇｕａｇｅ」も存在している。１つ又はそれ以上のこれらのフィールド１３３が存在している場合がある。

・反復要素の中に包含される特定の項目に対して比較的迅速なサーチをどのようにして与えるか。

・ディレクトリオブジェクトの階層においてＵＤＤＩ情報及び条件をどのようにして表現するか。

・ＵＤＤＩオブジェクト及び全てのそれらの関連する情報の削除を効率的な態様でどのようにして管理するか。及び、
・ディレクトリ格納媒体の制限を考慮しながらディレクトリアクセス及び反復的メモリ内動作の両方を最小とさせるようにサーチ動作期間中に中間サーチ結果収集物の構成をどのように最適化させるか。実際に、ディレクトリエントリは任意の順番で格納し且つリターンすることが可能であり、且つディレクトリ結果はソートするのに大き過ぎる場合がある。

・パブリッシャアサーションに関するデータを効率的な態様でどのようにして表現するか。

・特にｆｉｎｄｒｅｌａｔｅｄＢｕｓｉｎｅｓｓ方法の実現に関して、パブリッシャアサーションの効率的実現例をどのように作成するか。

・関係によりパブリッシャアサーションの効率的サーチをどのように実現するか。

・パブリッシャアサーションの有効性をどのように管理するか。

・ビジネスエンティティの所有者によりなされるビジネスエンティティに対して作成され且つ削除されるアサーションをどのように制限するか。

・ＵＤＤＩスタンダードにおいて定義されるように属性の関連する収集物をどのように効率的に管理するか。

・サーチの性能を向上させるために属性及びオブジェクトをどのように定義するか。

種々のＵＤＤＩスキーマが提案されている。然しながら、いずれもが少なくとも上述した問題に対処するものとは考えられない。例えば、１つのスキーマは、効率的な商業的実現例を発生するために必ずしも複雑性及び最適化を考慮することなしに、ディレクトリオブジェクトに対してＵＤＤＩオブジェクトの比較的簡単なマッピングを与えている。このようなスキーマにおいて、どのようにして多数のＵＤＤＩサービス（特に、ｆｉｎｄ ｓｅｒｉｅｓ）を効率的に実現することが可能であるかも不明である。

例えば、図１４はビジネスエンティティにおける比較的複雑なオブジェクトのノベル（Ｎｏｖｅｌｌ）表現を概略的に例示している。ビジネスエンティティオブジェクト１４１は、例えば、多数の属性１４２を包含しており、各々が「タイプ」及び「値」を有している。例示したように、値「Ｂｉｌｌ」を有するＡｕｔｈｏｒｉｚｅｄＮａｍｅ、値「８９０．ｏｂａｌｅ．８９０．．．」を有するＢｕｓｉｎｅｓｓＫｅｙ、及び複数の値１４３，１４４、即ち、
ｅｎ＃ｃａ
ＩＮ＃ＣＡＴＳ
を有するＮａｍｅが存在している。

ＵＤＤＩ（図１３）及びノベル（図１４）例の表現はウエブサービスに対しての効率的な表現であるとは考えられない。

従って、ディレクトリに基づいてＵＤＤＩの比較的拡張性があり効率的で且つ信頼性のある実現例を提供するために上述した一般的な問題及びその他の問題に対処することの必要性が存在している。

ウエブサービスシステムにおいて使用する方法が、データリポジトリへのアクセスを与え、且つ前記データリポジトリのサーチを行う場合に使用するシャドウ属性を与える、ことを包含している。

ウエブサービスシステムにおいて使用する方法を実施するためのコンピュータにより実行可能なコードを包含するコンピュータ記録媒体が、データリポジトリへのアクセスを与えるためのコード、及び前記データリポジトリのサーチを行う場合に使用するシャドウ属性を与えるためのコードを包含している。

図面に例示した本開示の好適実施例を説明する場合に、明確性のために特定の用語を使用する。然しながら、本開示はそのように選択された特定の用語に制限されることを意図したものではなく、各特定の用語は同様の態様で動作する全ての技術的な均等物を包含するものとして理解すべきである。

図１８は本開示の方法及びシステムを実現することが可能なコンピュータシステムの１例を示している。本開示のシステム及び方法は、例えば、メインフレーム、パソコン（ＰＣ）、ハンドヘルドコンピュータ、サーバー等のコンピュータシステム上で稼動するソフトウエアアプリケーションの形態で実現することが可能である。そのソフトウエアアプリケーションは、例えば、フロッピィディスク、コンパクトディスク、ハードディスク等のコンピュータシステムにより局所的にアクセス可能な記録媒体上に格納することが可能であり、又はコンピュータシステムから離れており且つ、例えば、ローカルエリアネットワーク又はインターネット等のネットワークへのハードワイヤード又は無線の接続を介してアクセス可能なものとすることが可能である。

本方法及びシステムを実現することが可能なコンピュータシステムの１例を図１８に示してある。大略システム１８０として言及するコンピュータシステムは、中央処理装置（ＣＰＵ）１８２、例えばランダムアクセスメモリ（ＲＡＭ）等のメモリ１８４、プリンタインターフェース１８６、ディスプレイユニット１８８、（ＬＡＮ）ローカルエリアネットワークデータ伝送制御器１９０、ＬＡＮインターフェース１９２、ネットワーク制御器１９４、内部バス１９６及び例えばキーボード、マウス等の１つ又はそれ以上の入力装置１９８を包含することが可能である。図示したように、システム１８０は、例えばハードディスク等のデータ格納装置２００へリンク２０２を介して接続することが可能である。

以下は本開示の実施例の顕著な特徴のうちの幾つか及びそれにより与えられる２，３の利点について要約するものである。

本開示の１実施例によれば、ユーザの上にリポジトリレイヤーが作成され、従って各リポジトリは異なるサーバー上に配置することが可能である。このリポジトリレイヤーは１つ又はそれ以上のディレクトリノードを包含しており、該ノードは集合的にディレクトリプレフィックスを形成する。これは、リポジトリの「ドメイン（Ｄｏｍａｉｎ）」又は「名前（Ｎａｍｅ）」としても知られている。このことの利点は、それがドメインに関しての情報を保持する単一の場所を与えることである。このノードの名前はディレクトリプレフィックスを表わす。

ＵＤＤＩアカウントを表わすデータを保持するためにユーザオブジェクトを作成することが可能である。このことの利点は、それがユーザ／アカウントに関する情報を保持するための単一の場所を与えることである。

ビジネスエンティティオブジェクトはユーザオブジェクトの下に配置させることが可能であり、ビジネスサービスオブジェクトはビジネスエンティティオブジェクトの下に、且つバインディングテンプレートオブジェクトはビジネスサービスオブジェクトの下に配置することが可能である。このことの利点は、ユーザオブジェクトレイヤーの上のリポジトリ即ち「ドメイン」レイヤーが多数のリポジトリを配置させるか又は論理的に一体的に接続させることを可能とすることである。該ドメインレイヤーは、例えば、大陸によりまとめられる異なる国ＡＵ，ＵＳ，ＥＰ等の多数のレベルに配置させることが可能である。

別の利点は、この特徴はＸ５００ディレクトリのディストリビューション特徴の使用により効果を与えることが可能であることである。例えば、これを実現するために、仮想ディレクトリツリーの頂部に「ワールド（Ｗｏｒｌｄ）」又は「コーポレイション（Ｃｏｒｐｏｒａｔｉｏｎ）」ノードを配置させ、且つ一意的に名前を付けたノードを各ＵＤＤＩサブツリー（ＵＤＤＩ名前空間）の頂部に配置させる。ユーザには見えないが、これらの「ノード」プレフィックスはＵＤＤＩリポジトリがディレクトリディストリビューションを利用することを可能とする。

本開示の１実施例によれば、ビジネスエンティティオブジェクトはユーザオブジェクトのチャイルド即ち子とすることが可能である。ビジネスエンティティに関してユーザ／アカウントを有する場合には、ビジネスサービス及びバインディングテンプレート階層が各ユーザがそれら自身のサブツリーを有することの効果を与える。このことは、管理性およびセキュリティを向上させる。ユーザはそれら自身のサブツリーを修正及び／又は制御することに容易に制限される。このことは、又、ディレクトリサブツリーサーチ動作を利用することにより性能を向上させる。

１実施例によれば、ユーザにより定義されるＴＭｏｄｅｌは、ユーザオブジェクトの子とすることが可能であり、従ってセキュリティを出現することを容易なものとさせる。このことは管理性及びセキュリティを向上させる。何故ならば、ユーザはそれら自身のサブツリーを修正及び／又は制御することが可能であるに過ぎないからである。それは、又、ディレクトリサブツリーサーチ動作を利用することにより性能を向上させる。

本開示の１実施例は、Ｘ．５００／ＬＤＡＰディレクトリ技術を使用してＵＤＤＩ環境の「マッピング」を表わす。特に、Ｘ．５００及びＬＤＡＰディレクトリ技術の階層構造はＵＤＤＩ環境にとって適切なものであることが判明している。付加的な要素（ユーザオブジェクト等）の注意深い設計が該階層をＵＤＤＩ環境の必要性にとって更に適切なものとさせている。

本開示を介して、ディレクトリという用語はＸ．５００、ＬＤＡＰ及び同様の技術を包含すべきであり、「ユーザ」という用語は「アカウント」も包含すべく理解すべきであり且つその逆も又真であり、且つ「リポジトリ」という用語は「ディレクトリプレフィックス」、「ドメイン」及び／又は「ノード」を包含するものと理解すべきであり且つその逆も又真である。

ウエブサービスは、最初は、例えばビジネス、パートナー、顧客、サプライヤ等の組織の間のサービスであることが目論まれていた。この文脈において、ＵＤＤＩはこれらの組織が提供するサービスに対する単一のリポジトリとして目論まれていた。

現在明らかなことであるが、ウエブサービス及びＵＤＤＩは組織内部のアプリケーションを統合するためにエンタプライズ即ち企業内において有用なものである。更に明らかなことであるが、ウエブサービス及びＵＤＤＩは、あるベンダーからの製品の組の中の製品を統合するために使用することが可能である。それは、又、政府の部門、大きな教育機関、及びその他の多数の非商業的エンティティのインスタンス等の分野において商業的環境以外に適用することも可能である。

以下の説明は、エンタプライスに関して説明するものであるが、任意のタイプの環境に対して等しく適用性を有しており且つ上述したタイプの環境に対して特に適用性を有している。

エンタプライズＵＤＤＩレジストリは、内部的消費のための情報及びサービスをパブリッシュするためにそのエンタプライズ内においてデプロイ即ち配備することが可能なサービスとすることが可能である。更に、エンタプライズＵＤＤＩサービスは、配布したアプリケーションに対するコンフィギュレーションディスカバリ等のその他の機能を提供するために利用することが可能である。

ウエブサービスは内部的に及びパートナーと共にビジネスプロセスを迅速且つ容易に統合するための願望により追いたてられている。ウエブサービスを効果的に使用する１つのコンポーネントはパブリックＵＤＤＩレジストリであり、それはソフトウエアコンポーネントがインターネットを横断しての適宜のサービスを動的に発見し且つ接続することを可能とさせる。ウエブサービスは、又、エンタプライズ内のビジネスプロセスを統合することを可能とする約束を提供する。この場合において、ＵＤＤＩレジストリは組織のインフラストラクチャの一部となり（例えば、重要なエンタプライズアプリケーション）、従って最高レベルのセキュリティ、性能、信頼性及び管理性を提供することが可能である。ディレクトリ技術はエンタプライズＵＤＤＩレジストリの厳格な条件をサポートするための理想的な基礎を提供する。

エンタプライズＵＤＤＩレジストリはＵＤＤＩに対するスタンダード準拠サポートを提供するものとして定義することが可能であるが、デプロイメントに対する４つの分野に対処するためにそれを超えるものである。これらの分野は、アクセスを承認されたユーザのみに制限するためのセキュリティ（ＳＥＣＵＲＩＴＹ）、大型のデプロイメントをサポートするためのディストリビューション（ＤＩＳＴＲＩＢＵＴＩＯＮ）、真の生産システムに対する管理性（ＭＡＮＡＧＥＡＢＩＬＩＴＹ）、及びサービスレベルアグリメント（ｓｅｒｖｉｃｅ ｌｅｖｅｌ ａｇｒｅｅｍｅｎｔ）を満足するためのアベーラビリティ（ＡＶＡＩＬＡＢＩＬＩＴＹ）即ち使用可能性を包含している。

強力なセキュリティは、あるエンタプライズデプロイメントに対して重要な条件である場合がある。パブリックＵＤＤＩレジストリは、誰かが使用可能なサービスを発見することを助ける唯一の目的のために存在している。ＵＤＤＩレジストリは、正しい人がこれらのサービスを発見させる唯一の目的のために存在している。これは重要な区別である。

インターネットＵＤＤＩレジストリは、エンタプライズにおいてウエブサービスをデプロイするのには不適切であると考えられている。例えば、給与体系又は従業員福祉管理アプリケーションとインターフェースするウエブサービスの定義はインターネットＵＤＤＩレジストリに対してポストされることはない。

セキュリティ条件は、又、内部的にデプロイされたＵＤＤＩレジストリであっても強力なアクセス制御を与えることを意味する場合がある。何故ならば、ＵＤＤＩレジストリは、基本的に、何を為すことができるか且つそれをどのようにして行うかに関してのチュートリアルを定義するからである。ＵＤＤＩレジストリは、いずれかの使用可能なウエブサービスのビジネスレベルの記述及びこれらのサービスに対してのプログラム的なインターフェースを完全に定義するＷＳＤＬへの指示を提供する。このことは、アプリケーション開発者に対して、及びハッカーに対して高生産性のツールを提供する。

従って、資金的に機密性がある即ち秘密性（例えば、医学的記録）のシステムに対するインターフェース定義に対してのアクセスを制限することが望ましい。デプロイメント組織内においても、特定のウエブサービスに関する情報へのアクセスを承認された者へ制限することが賢明な場合がある。

エンタプライズ内において、又はエクストラネットを介して選択したビジネスパートナーとの間で安全確保されていないＵＤＤＩレジストリを使用することは極めて危険な場合がある。自由にダウンロード可能なツールのおかげで、比較的低いレベルの熟練を有する人がウエブサービスへアクセスし且つそれを使用することが可能である。どのような真のエンタプライズソリューションも、ウエブサービスに関しての情報へのアクセスをトランスペアレントに制御する能力を持ってスタンダードのＵＤＤＩサービスを実現することが可能である。

ディストリビューションに関して、多くの場合において、ＵＤＤＩレジストリの初期的なデプロイメントは、小規模なものである。然しながら、ウエブサービス条件が成長するに従い、大きなデプロイメントがより一般的なものとなる。更に、レジストリの使用及びデプロイメントは、ＵＤＤＩレジストリに対する新たな機能の発見と共に加速する。

より大きな実現、及び地理的に分布した組織内での使用は、単一の組織内においての複数のＵＤＤＩレジストリの実現を駆立てる。分散型レジストリへ向かっての展開は、どの個別的なレジストリもそれらの要求をサービスするために他のレジストリと動的に相互作用することが可能であることを重要なものとさせる。確立されると、レジストリ間通信は、信用されているビジネスパートナーにおけるレジストリ、又はインターネットＵＤＤＩレジストリをも包含すべくファイヤウォールを超えて拡張される場合がある。

レジストリ間通信に対する必要性に対処するために２つの基本的なアプローチが存在すると考えられる。１つのアプローチは、レプリケーション（ＲＥＰＬＩＣＡＴＩＯＮ）であり、その場合には複数のサーバー上で同一のエントリ名前空間が存在している。別のアプローチはディストリビューション（ＤＩＳＴＲＩＢＵＴＩＯＮ）であり、その場合には、相互接続されているサーバーは異なるエントリ名前空間を有しているが、それらは１つの論理的サービスとして動作する。

これらの２つのアプローチは、しばしば、類似したものとして混乱を招く場合があるが、それらは全く異なるものである。

レプリケーションアプローチにおいては、情報は、それをルックアップすることが必要な場合のあるすべてのサーバー内において複製される。これは比較的簡単で過剰に簡単でもあるソリューションであるが、それはアップデートを同期するための条件を導入し、且つそれは、定義上、レジストリの数及びそれらの内容の量が増大すると共にネットワークの渋滞が増加する。レプリケーション技術は、サービスの数が低く、情報の量が低く且つ変化が頻繁でない場合の環境に最も良く適している。エンタプライズデプロイメントの場合には、レプリケーションは、フェイルオーバー環境におけるバックアップリポジトリを維持するのに最も有用である。地理的に又は機能的に分散しているサーバーを同期した状態に維持することはれプリケーション技術を使用する場合には非常に困難である。

ディストリビューションアプローチにおいては、情報は、各参加するサーバー上で論理的に表わされるが、単一のレジストリに格納されるに過ぎない。クエリーが、必要に応じてのみ他のレジストリへ配布される。従って、リターンされる情報は現在のものであることが保証される。このことは、単一のアップデート点を与え且つレプリケーション技術において内在する同期及び帯域幅消費の問題を取除いている。真のディストリビューションは、サーバー間のスケーラブルな接続性に対する１つの回答であると考えられる。

エンタプライズＵＤＤＩレジストリの場合には、通常ディストリビューションが使用される２つのシナリオが存在している。最初のシナリオは、各々が新たなＵＤＤＩエントリを発生し且つＵＤＤＩサービスをコンシューム（ｃｏｎｓｕｍｅ）即ち消費する地理的に離隔しているオフィスを有する組織に対するものである。単一の中央集権化したＵＤＤＩレジストリを稼動させることが可能であるが、帯域幅制限及び時間帯の違いが、しばしば、このことが動作可能なものとすることを困難なものとさせる。

分散型レジストリは、柔軟性がありスケーラブルなソリューションを与える。このシナリオにおいては、各参加オフィスが別個のレジストリを有しており、且つ各レジストは他のものをそれ自身の内容の論理的一部として見る。レジストリサービスは接続性詳細の全てを取り扱い、且つ顧客は地理的な点で懸念する必要はない。

エンタプライズが、その内部ＵＤＤＩシステムを信用されているパートナーのもの又はパブリックインターネットレジストリへ接続することを必要とする場合に２番目のシナリオが発生する。パブリックレジストリの場合には、特に、レプリケーションが問題である。インターネットレジストリのオペレーターは、そのレジストリの一部をエンタプライズの内部レジストリへ複製することを嫌がる場合がある。この場合も、分散型アプローチが１つの回答である。現在のところ、ディストリビューションに対するＵＤＤＩスタンダードは存在せず且つレプリケーションに対する提案は複雑なものであると考えられる。１つのソリューションは、スタンダードに対する修正を必要とすることなしにＵＤＤＩ分散型アプローチの利点を提供することである。

管理性に関しては、エンタプライズ内のミッションクリチカルな機能を実施するコンポーネントとして、ＵＤＤＩは性能及び信頼性の条件を満足すべきである。それは、単に、開発者にとって便利なユーティリティとして存在すべきではない。クライエントによる読取アクセスは、ＵＤＤＩレジストリの最も頻繁で且つ最も時間的に臨界性のある利用である。性能は最大の処理能力に対して最適化され、且つルックアップクエリーの応答時間はより複雑なサーチにより影響されるべきではない。レジストリが寸法及び複雑性の点で増加するに従い性能が影響を受けるべきではない。ＵＤＤＩレジストリを支えるデータストアは産業的強さとなるべきであり且つトランズアクション及び自動的リカバリを完全にサポートすべきである。更に、ＵＤＤＩサーバーは、高度のアベーラビリティ即ち使用可能性を有し且つネットワークフェイルオーバー及びホットスタンバイ等の特徴をサポートすべきである。システムアドミニストレーターは、ＵＤＤＩレジストリを容易に維持し、モニタし、制御することの能力を有するべきである。これらの能力は、サービスをオフラインとすること無しに制御、規則及び設定を変化させるためのダイナミックコンフィギュレーション（ＤＹＮＡＭＩＣ ＣＯＮＦＩＧＵＲＡＴＩＯＮ）、高いアベーラビリティのためのオンラインバックアップ及びチューニング（ＯＮＬＩＮＥ ＢＡＣＫＵＰＳ ＡＮＤ ＴＵＮＩＮＧ）、レジストリの「トローリング（ｔｒａｗｌｉｎｇ）」を停止し且つサービス妨害攻撃を防止するためのアドミニストラティブコントロール（ＡＤＭＩＮＩＳＴＲＡＴＩＶＥ ＣＯＮＴＲＯＬＳ）、ＳＮＭＰ又はその他のタイプの警告メカニズムを介してのモニタリング（ＭＯＮＩＴＯＲＩＮＧ）、セキュリティ、統計、クエリー、アップデート情報に対し別々のログファイルを具備するオーディティング及びダイアグノスティックス（ＡＵＤＩＴＩＮＧ ＡＮＤ ＤＩＡＧＮＯＳＴＩＣＳ）、及びレプリケーション、ディストリビューション、ルーチングをサポートするデプロイメント（ＤＥＰＬＯＹＭＥＮＴ）オプションを包含している。

多くの開発者中心ＵＤＤＩレジストリが導入されている。これらは、小さな開発チームに対して有用な能力を提供するが、真に生産品質のシステムではない。ウエブサービスディプロイメントは迅速に成長しており且つ現在進行中のウエブサービスデプロイメントをサポートするために迅速にスケールすることが可能なエンタプライズ品質のレジストリに対する対応する必要性が存在している。

ＵＤＤＩレジストリはサービスを提供する。このサービスは多くのアプリケーションにより信頼される。オンラインビジネスの場合には、このサービスが存在することが重要な場合がある。例えば、ＵＤＤＩレジストリは、９９．９９％のアベーラビリティのサービスレベルアグリメントを与えることが必要な場合がある。このレベルのアベーラビリティを容易なものとさせるために、ＵＤＤＩレジストリは、２つ又はそれ以上のマシン及びそれらのマシンが同期されていることを維持することを確かなものとするために設けられているメカニズムにわたって複製される場合があり、且つ該マシンのうちのいずれかが使用不可能なものとなる場合には、入って来るクエリーは自動的に使用可能なマシンへ経路付けされる。

指摘したように、ＵＤＤＩは実効的には電話帳サービスに類似したものと考えることが可能である。そうであるから、情報を格納のディレクトリモデルは、ＵＤＤＩレジストリサービスを構築するのに完全な土台である。ディレクトリモデルは、ディレクトリに基づくサービスの特定の必要性に対して展開され且つ開発され、セキュリティ、スケーラビリティ及び信頼性がエンタプライズレベルのディプロイメントに対して必要とされる。

上述した項目の殆どは、アプリケーションアーキテクチャにおいて、データ格納レベルにおいてではなくサービスレベルにおいて実現される。リレーショナルデータベース（ＲＤＢＭＳ）は、その上に多くの異なる種類のアプリケーションを構築することが可能な一般的なツールキットである。ＲＤＢＭＳ実現例は、終端アプリケーションにおいて必要とされるエキストラなサービス機能ではなく安定したデータアクセス機能性を与えることに集中している。

図３に示したディレクトリサービスアーキテクチャは、他のコンポーネントからのサービスレイヤー３１の分離を例示している。インターフェース機能をサービスレイヤー３１内にカプセル化することは、再使用可能なサービスインフラストラクチャコンポーネントを発生させる。このことの優れた例はウエブサーバーである。ウエブサーバーは、スタンドアローンコンポーネント内に構築するのに充分に有用なサービスを一体となって作り上げる一群の機能（ＨＴＴＢアクセス、ＣＧＩ処理等）を提供する。同じ様に、ディレクトリサービスモデルは、特定のタイプのアプリケーションにより必要とされる機能を供給するために開発されている。ディレクトリ技術は、オーセンティケーション（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）即ち認証及びオーソリゼーション（ａｕｔｈｏｒｉｚａｔｉｏｎ）即ち承認の分野における多くのミッションクリティカルなアプリケーションに対する基礎を与える。

ＵＤＤＩは、別の種類のディレクトリサービスと類似するものと考えることが可能である。従って、ＵＤＤＩにより定義される実現上の問題の多くはディレクトリ技術を使用することによって解消することが可能であることを理解することが可能である。例えば、ディレクトリは、ＵＤＤＩ電話ディレクトリ動作に対して非常に一般的な極めて効率的なファインド（ｆｉｎｄ）及びサーチ動作に対して最適化される。

既に述べたように、エンタプライズ内に成功裡にデプロイされるべきためには、ＵＤＤＩサービスは、強力なセキュリティ、ディストリビューション、管理性能力を提供すべきである。これらは、エンタプライズ強さディレクトリサービスソリューション内に既に組込まれているのと正に同じ属性である。

エンタプライズＵＤＤＩレジストリを構築する１つの方法は、高性能で実世界のアプリケーションにおいて試行され且つテストされた既存のディレクトリインフラストラクチャを拡張することである。

ディレクトリサービスアーキテクチャは、エンタプライズＵＤＤＩレジストリを実現するための最適な手段を提供している。この組合わせは、成功するために必要な能力をサポートする。図４に概略的に例示したように、ＵＤＤＩサービスは、このインフラストラクチャに対して実現することが可能なコンポーネントを識別する。ＵＤＤＩ意味論的ブリッジ４１は、ＵＤＤＩのＳＯＡＰ実現例４２とディレクトリ４４にサポートされているＬＡＤＰインターフェース４３との間を調停するサービスコンポーネントである。ディレクトリ４４はサポートするセキュリティ制御、ディストリビューションメカニズム、管理能力と共に情報アクセスを送給する。ＲＤＢＭＳ４５は基礎となる物理的データ管理、トランズアクションに関する完全性及びバックアップ及びリカバリメカニズムを提供する。

ＵＤＤＩレジストリ製品はＲＤＢＭＳ技術の上に直接的に構築することが可能である。リレーショナルデータベースは、多くの場合において非常に有用であり且つ強力なものであるが、それ自身ではディレクトリ処理にとって独特の条件を満足するものではない。

ＲＤＢＭＳ又はその他のデータ格納システムを表面下で使用して、ディレクトリ型アプリケーションをゼロから構築することが可能である。然しながら、これは最も効率的なアプローチではない場合がある。

別のアプローチは、ＵＤＤＩレジストリをデリバーするためにディレクトリサービスモデルを適用し且つこの特定のタイプのアプリケーションに対して必要とされる機能を供給することである。ＵＤＤＩレジストリに対して必要とされる更なる機能は、最近の産業的強さ（ｉｎｄｕｓｔｒｉａｌ−ｓｔｒｅｎｇｔｈ）ディレクトリサービスにより供給することが可能である。ＵＤＤＩレジストリは特別の通信及びＡＰＩを具備するディレクトリサービスとして見ることが可能である。ディレクトリ上にＵＤＤＩサービスをデリバーすることは、利益を得るためにＵＤＤＩスタンダードを修正することの必要性なしに所要のセキュリティ、ディストリビューション、管理能力を与えることが可能である。

データ表現の注意深い設計は、ＵＤＤＩリポジトリに必要な機能性及び性能を与える上で有益的である。

以下の説明は種々のＵＤＤＩ概念に関するものである。これらのＵＤＤＩ概念の更なる詳細な説明は、ＵＤＤＩ仕様を参照することにより得ることが可能である（ｈｔｔｐ：／／ｗｗｗ．ｕｄｄｉ．ｏｒｇ／ｓｐｅｃｉｆｉｃａｔｉｏｎ．ｈｔｍｌ）。

ディレクトリ専門用語において、スキーマはディレクトリ内に格納することが可能なデータ要素及びどのようにしてこれらの要素を共に接続することが可能であるかの記述である。これは、可能な属性（属性は一片のデータを保持する）の各々の記述、種々のオブジェクト（オブジェクトは属性の集まりである）の記述、及び可能なオブジェクト階層の使用を包含している。本明細書において使用する特定のスキーマ表記法はコンピュータアソシエイツインターナショナルインコーポレイテッドの製品であるｅＴｒｕｓｔディレクトリにより使用されるものである。「ｅＴｒｕｓｔ」はコンピュータアソシエイツインターナショナルインコーポレイテッドの製品名及び商標である。勿論、その他のスキーマ表記法を使用することが可能である。

本開示はデータストアとしてディレクトリを使用するＵＤＤＩリポジトリを実現するために使用されるスキーマを説明する。このスキーマに関与する多数の概念が存在している。又、ＵＤＤＩインプリメンテーション即ち実現例の動作を向上させるために使用される多数の技術が存在している。以下のものはこれらの概念のうちの幾つかの簡単な説明である。これらの概念及び技術のより詳細な説明は、本開示の実施例を説明する場合に後に説明する。

本スキーマは最適化された動作を与えるべくデザインされている。属性、オブジェクトクラス、エントリ、階層の定義を包含する本スキーマデザインは、動作を向上させる態様で具体化されている。本スキーマデザインは、少なくとも、セキュリティ、性能、管理性、ディストリビューションにおいて顕著な利点を与える。

本システムの階層について説明する。Ｘ．５００ディレクトリは内部的にディストリビューションをサポートし、ＵＤＤＩレベルでのコーディング無しで分散型ＵＤＤＩリポジトリを与える。レベルが該リポジトリの概念を分割する。このスキーマの（オプションの）ドメインレベルが、レベル、各ドメインエントリ、その下側のエントリの全てを、ＵＤＤＩレベルのプログラミングに対してトランスペアレントに別個のディレクトリサーバー上に配置させることが可能であることを与える。図１１は本開示のこの側面の１実施例を例示している。これについて以下更に詳細に説明する。

本開示の１実施例によれば、ユーザオブジェクトがビジネス及びＴＭｏｄｅｌオブジェクトの上に配置される。ユーザオブジェクトはユーザに関する情報を格納するための場所を提供する。それは、又、ユーザによりパブリッシュされるデータの全てに対するアンカーポイントを与える。図１０は本開示のこの側面の１実施例を例示している。これについて以下に更に詳細に説明する。

セキュリティはこのドメイン／ユーザ階層システムにおいて簡単化されている。ＵＤＤＩ実現例は、ユーザがデータオブジェクトのそれらのサブツリーにわたって制御を有することを強制することが可能である。

ユーザ制御型エントリに対するサーチが与えられる。このユーザにより制御されるデータに対するサーチは、ユーザオブジェクトの下のサブツリーサーチを使用することにより向上させることが可能である。

例えば、バインディングテンプレートにおいて発生するＴＭｏｄｅｌを特定することによりビジネスを見つけることが可能である。このことは、「子の１つ（又はそれ以上）を見つけることによりｘを見つけ出すこと」と等しい。換言すると、クエリーは「このＴＭｏｄｅｌを参照するバインディングテンプレートを有するサービスを有する全てのビジネスを探し出す」とすることが可能である。このようなクエリーは、ビジネスエンティティのＤＮを発生させるために、子孫オブジェクトのＤＮ（識別名）を見つけ出し且つ不所望のレベルを廃棄することにより行われる。又、この態様において二重削除を行うことが可能である。この見つけ出し特徴は、本開示の構造の階層的性質に起因して発生する。

サーチはオブジェクトクラスにとって一意的な属性を使用して実施することが可能である。これは２つの利点を有する最適化である。このことはサーチの書込を簡単化し且つ「弱い」節を除去することを介して優れた性能を発生する。「弱い」節はフィルタの一部であって、それは多数のエントリをリターンするか、又は多くのエントリの一部である属性を参照する。全てのＮａｍｅ即ち名前に対し同一の属性名を使用したデザインは、名前によってビジネスエンティティに対しサーチを行う場合に２つの選択を有しており、それはサーチ又はサーチ結果のフィルタにおいてオブジェクトクラスを包含している。前者は、ビジネス名が一意的なオブジェクトクラスを有する場合に可能であるに過ぎず、且つその場合であっても、オブジェクトクラスは弱い節であり、更なるオーバーヘッドを発生する。後者は、エキストラなコードを意味しており、且つ結果リストをリターンする潜在性は所望の結果よりも一層大きい。

例えば、広範囲のウエブサービスを提供する「ＭｃＫｅｎｎａ’ｓテスティングサービス」と呼ばれる会社について検討すると、そのサービスの全てはその名前において「ＭｃＫｅｎｎａ’ｓ」を包含しており、それらの名前において「ＭｃＫｅｎｎａ’ｓ」を有するビジネスエンティティに対するサーチはサービスの全てに対して中間結果をリターンする。これらの中間結果は、除去することが可能であるが、それらを取り扱うことは性能を減少させる。

サーチにおける属性名を特定し且つその属性名をして求めるオブジェクトクラスを一意的に識別させることが可能であることが望ましい。上の例を継続すると、そのサーチは、（ｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅ＝ＭｃＫｅｎｎａ’ｓ＊）を特定することが可能である場合に著しく簡単となる。

このようなデザインは強力なサーチを発生し、それらは所望の分野のみのサーチを行うので効率的である。強力なサーチは小数のエントリをリターンするサーチを包含している。ディレクトリはｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅ属性をインデックスし、且つそのインデックスからの結果をリターンすることが可能であり、このことは良好な性能を発生し且つ不必要な中間結果を取り扱うことを回避する。

簡単なクエリーの場合、このようなデザインは、ビジネスエンティティ名に対するサーチが、別のデザインにおいて必要となる場合のある複合的なものではなく単一の節であることを意味している。その名前属性がｅｕＮａｍｅと呼ばれ、且つビジネスエンティティ名オブジェクトがｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅと呼ばれるものと想定する。それは、
（＆（ｅｕＮａｍｅ＝ＭｃＫｅｎｎａ’ｓ＊）（ｏｃ＝ｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅ））
のようなサーチを発生する。

更により簡単なデザインがあり、その場合は、全ての名前が同一のオブジェクトクラス内に格納される。このことは、サーチが（ｅｕＮａｍｅ＝ＭｃＫｅｎｎａ’ｓ＊）に再度還元されることを意味するが、今回は、ビジネスエンティティである親オブジェクトを有するものを探し出すことを試みながら全ての名前に対する結果を介して進むこととなり、この最後のデザインは潜在的に拙い性能でむしろより複雑なプログラミングを発生する。

シャドウ特性は大文字小文字区別性に対して使用することが可能である。単一のインデックスを使用して大文字小文字区別性と大文字小文字非区別性の両方のサーチを与えることは些細なことというにはほど遠い。１つのオプションは、大文字小文字非区別的にインデックスし、次いでその結果を大文字小文字区別的にスキャンすることである。ここでの別のソリューションは、オリジナルのデータを大文字小文字区別的にインデックスし、且つ大文字小文字非区別的にインデックスされた第二の属性（その場合に同一のデータを格納する）を付加することである。次いで、必要なことは、ファインドクワリファイヤ（ｆｉｎｅ ｑｕａｌｉｆｉｅｒ）即ち発見修飾子に依存してサーチすべく適宜の属性を選択することだけである。

このデザインにおける全ての属性は単一値型とすることが可能である。このことは効率的なインデックス処理、より高い性能、より強いサーチとすることを可能とする。

多値型属性を使用することは不明瞭なサーチを可能とさせる。即ち、直感に反し且つ意図していないサーチ結果を得る可能性がある。「ｎ」と呼ばれる多値型数値属性及び値２及び５と共にこの属性を包含するエントリを想定すると、このエントリはサーチ（＆（ｎ＜３）（ｎ＞４））に応答してリターンされ、それは容易に予測されるようなものではない。

単一値型属性は強いサーチに対して使用される技術のうちの１つである。強いサーチは、インデックスを介して大多数の候補結果を除去することが可能なものである。強いサーチは改良された性能に対して重要である。

サービスプロジェクション（ｓｅｒｖｉｃｅ ｐｒｏｊｅｃｔｉｏｎ）のためにエイリアスを使用することが可能である。これは、データストアとしてＸ．５００ディレクトリを使用することの顕著な利点である。サービスプロジェクションは、Ｘ．５００エイリアスを使用して巧妙に表わすことが可能である。これは、データのインテグリティ即ち完全性を保証することの主要な利点を有している。該エイリアスがオリジナルのデータへアクセスし、従ってそのオリジナルに対する何等かの変化は瞬時に該エイリアスにより反映される。ディレクトリのインプリメンテーション即ち実現がエイリアスのインテグリティをサポートする場合には、オリジナルのエントリが削除されると、エイリアスは付加的な作業なしに消滅する。

パブリッシャアサーション（Ｐｕｂｌｉｓｈｅｒ Ａｓｓｅｒｔｉｏｎ）は、ＵＤＤＩスタンダードにおいて最も不明確に定義されている要素のうちの１つであり、且つそれは注意深いデザインを必要とする。不適切なインプリメンテーション即ち実現は容易に拙い性能を発生する場合がある。

パブリッシャアサーションの最も一般的な使用はｆｉｎｄ ｒｅｌａｔｅｄＢｕｓｉｎｅｓｓ ＡＰＩであり、それは特定したビジネスエンティティに関連するパブリッシャアサーションの全てをサーチするものであるから、各アサーションをそれが参照するビジネスエンティティの下に配置することが良好なデザインである。

アサーションのステータスを計算し、且つそれをアサーションオブジェクト内に格納することにより、サーチを完了したパブリッシャアサーションへ制限することが可能である。このことは、リターンされる結果が除去されるべき偶発的な参照を包含することがないことを意味する。

補助的なクラスとしてリレーションシップオブジェクトをストア即ち格納することは、サーチが不所望のリレーションシップを有するアサーションを除去することを可能とさせる。リレーションシップが子オブジェクトとして格納されると、リレーションシップとアサーション完了ステータスの両方に対処する単一のサーチを書くことは不可能である。

ＵＤＤＩキーは存在する場合にネーミング即ち名前付けのために使用することが可能である。ＵＤＤＩは重要なオブジェクトクラスの多くに対してのキーを定義し、且つこれらのキーは一意的なものであることが保証されているものとして特定される。このことは、該キーはオブジェクトに対するネーミング属性として使用することが可能である。ネーミング属性としてＵＤＤＩキーを使用することは、ネーミングクラッシュの解決を試みることの必要性がないことを意味し、例えば、ビジネスエンティティに対するネーミング属性としてデフォルト名を使用した場合にはそのことが必要とされる。

キーは、存在しない場合にネーミングのために提供することが可能である。即ち、全てのＵＤＤＩオブジェクトが定義されたキーを有しているものではない。１つの例はパブリッシャアサーションである。これらの場合には、本システムは、ＵＤＤＩ定義キーに対して使用されるのと同一のアルゴリズムを使用してキーを提供する。このアイディアの再使用は、他のオブジェクトに対して書かれたコード及び構造を再使用することが可能であることを意味している。

一連のＵＤＤＩオブジェクトが別のオブジェクトの子であり、且つそれらの子の順番が重要（例えば、アドレスライン）である場合には、子オブジェクトに対して割当てられるキーは値が単調的に増加すべく配列され、従ってそれらのキーに関してのソーティングは所望の順番を発生する。このことは所望の順番を確保することのプロセスを簡単化させる。

実際的である場合には、キーがリトルエンディアン（ｌｉｔｔｌｅ−ｅｎｄｉａｎ）の態様で変化することが望ましい。即ち、そのキーの最も左側のバイトが最も迅速に変化する。何故ならば、それはデータストアとしてＸ．５００ディレクトリを使用する場合にインデックス処理の最も良い性能を発生するからである。

ＵＤＤＩスタンダードは主要なオブジェクトタイプの幾つかの中において多数のサブストラクチャ（ｓｕｂ−ｓｔｒｕｃｔｕｒｅ）を定義する。多くの場合において、これらのサブストラクチャはオプションであり、且つ反復させることが可能である（それらは０、１、又は同一のオブジェクトにおいて一回を超えて発生することが可能である）。簡単な例は、ストリング（名前）及び言語識別子を包含する名前サブストラクチャである。Ｘ．５００スキーマ定義は構造型属性の使用をサポートするものではなく、従ってすぐに明らかなサブストラクチャのマッピングは存在しない。これらのサブストラクチャをＸ．５００スキーマにおいてインプリント即ち実現することが可能な２，３の方法が存在している。

１つの方法は、サブストラクチャのコンポーネントを、種々の要素を分割するための何らかの種類のセパレーターを使用して、単一の属性へ連結させることである。このことは、最適のデザイン選択でない場合がある。何故ならば、それはコンポーネントを別個にインデックス又はサーチするための能力を失い、且つそれはデータを取り扱うことに対して処理上の複雑性を付加するからである。

本システムにおいては、サブストラクチャを表わすために使用されるデザインが、性能及び管理性を最大化させるために選択される。ここに開示するデザインは、ディレクトリにおけるサブストラクチャを表わすために多様の技術のうちの１つ又はそれ以上を使用する場合がある。これらの技術は３つのカテゴリに要約することが可能である。

１つの技術は、サブストラクチャの多くを子オブジェクトとして取り扱うことが可能であるということである。名前が良好な例であり、ビジネスエンティティの名前をビジネスエンティティの子として格納する。別の例は記述であり、その場合には、別個のビジネス記述オブジェクトがビジネスエンティティオブジェクトの子である。図１５は本開示のこの側面の実施例の例示を与えており以下に更に詳細に説明する。

別の技術はフラットニング（ｆｌａｔｔｅｎｉｎｇ）／マージング（ｍｅｒｇｉｎｇ）である。別のオブジェクトに対して高々１つのリレーションシップが存在する場合には、属性を単一のオブジェクトに結合することが可能である。この場合には、階層がフラットニングされるという。何故ならば２つのオブジェクトが１つのオブジェクトに結合されるからである。新たなオブジェクトはマージされているという。何故ならば、その新たなオブジェクトはオブジェクトを結合することから属性の結合を包含しているからである。好適には、リレーションシップオブジェクトの内容は親オブジェクトへ進展される。

例えば、図１６はＵＤＤＩリレーションシップ線図の表現を概略的に例示している。図１７はディレクトリ階層線図を概略的に例示しており、その場合に、ディレクトリ階層はＵＤＤＩオブジェクトのフラットニングにより形成されている。

説明として、図１６は、オブジェクト１６３に対してリレーションシップオブジェクト１６２を有するオブジェクト１６１を例示している。

本開示の１実施例によれば、１対１のリレーションシップが存在する場合には、「子」を進展させることが可能である。換言すると、その階層の部分を崩壊又はフラットニングさせ且つオブジェクトをマージさせることが可能である。その結果は図１７に概略的に例示してある。親オブジェクト１７１はコンテント即ち内容Ａ１，Ａ２，Ａｎを有しており、且つコンテントＢ１，Ｂ２，Ｂｎ，Ｃ１，Ｃ２，Ｃｎを有する１つ又はそれ以上の子である子オブジェクト９ｎを有している。

別の技術はスプリッティング（ｓｐｌｉｔｔｉｎｇ）である。例えば、１つの特定の場合（ＯｖｅｒｖｉｅｗＤｏｃサブストラクチャ）において、サブストラクチャが非反復型要素と反復型要素とを包含している。非反復型要素（ＯｖｅｒｖｉｅｗＵＲＬ）は親の中に移動させることが可能であり、一方反復要素は子オブジェクトとすることが可能である。

本開示の別の側面はマネージメント即ち管理である。ＴＭｏｄｅｌを削除することは、それをｆｉｎｄ ＴＭｏｄｅｌから隠すが、それをリポジトリから除去することはない。従って、ＴＭｏｄｅｌの正しい取り扱いを実現するために、隠しフラッグ（ｈｉｄｄｅｎ ｆｌａｇ）を実現することが可能である。このフラッグの存在は、ＴＭｏｄｅｌ（ユーザオブジェクト）が隠されていることを表わす。このフラッグの非存在は、そうでないことを表わす。このことが、大多数のＴＭｏｄｅｌにとって成立し、従ってこのアプローチは効率的である。隠されていないオブジェクトにおいて何等空間が占有されることはなく、且つ何等インデックス処理が使用されるものでもない。ディレクトリは隠されている属性を有するエントリのみをインデックスする。このことは、又、隠されていないＴＭｏｄｅｌに対するサーチが高速であり且つ効率的であることを意味する。

データストアとして使用されるＸ．５００ディレクトリは、空の値を格納することのないデザインを奨励する。例えば、オブジェクトに不在の（オプションの）値は該ディレクトリ内に格納されることはない。このことは、格納空間を効率的に使用し且つより強いサーチを行う。属性に関してのサーチは、その属性に対するデータを有するオブジェクトを考慮することが必要であるに過ぎない。

本システムのデータ階層は、ＵＤＤＩスタンダードの意図と良くマッチしている。ＵＤＤＩオブジェクトを削除するためのリクエストが到達すると、それは該ディレクトリにおけるサブツリーの削除に対して直接的にマップする。例えば、サービスを削除することは、その名前及び記述、及びそのバインディングテンプレートの全てを削除することを包含している。これらの全ては該ディレクトリにおけるサービスエントリの子である。従って、本システムは、そのサービス以下全てのサブツリーを削除する。これは容易に実現され且つ効率的である。

ドメインは階層的サブツリーのベースを表わす名前である。Ｘ．５００用語においては、ドメインはコンテクストプレフィックス（ｃｏｎｔｅｘｔ ｐｒｅｆｉｘ）として知られている。ＬＤＡＰ用語においては、それはサフィックスとして知られている。ＵＤＤＩリポジトリにドメイン名を与えることは、該リポジトリにおけるデータの真のディストリビューション（Ｘ．５００の意味において）の使用を可能とする。ＵＤＤＩスタンダードはレプリケーションをサポートするに過ぎない。ドメインノードを有することにより、本システムはアプリケーションに対してトランスペアレントにディレクトリディストリビューションファシリティを使用することが可能である。

例えば、エンタプライズが内部的にＵＤＤＩをデプロイするが、２つの開発サイトを有しているものと仮定する。このファシリティの場合には、彼らは各サイトにＵＤＤＩサーバーをデプロイすることが可能であり、ディストリビューションは各サイトが両方のレジストリ上でパブリッシュされる項目をトランスペアレントに観察することを可能とする。

このことの１つの利点は、それが「無料で」ディストリビューションを可能とするということである。例えば、ＵＤＤＩサーバーは何等エキストラな作業を行うことは必要ではなく且つディレクトリシステムは実効的に情報のアイランドを一緒にリンクさせる。

ＵＤＤＩスタンダードにおける何かが、どのようにしてユーザ情報が格納されるかを支配するものではない。ユーザオブジェクトを作成することにより、ユーザに関連する情報の全ては単一のオブジェクト内に格納することが可能であり、そのオブジェクトはそのユーザがパブリッシュするオブジェクトの全てを保持するサブツリーのルートとして使用することが可能である。このことは、セキュリティの定義を一層簡単なものとさせる。例えば、考慮中のオブジェクト（それがビジネスであろうと、サービスであろうと、又はＴＭｏｄｅｌであろうと）がユーザのユーザオブジェクトの下にある場合には、ユーザはそれを制御する。

ＵＤＤＩは反復する要素を包含するオブジェクトを定義する。性能、サーチ性、管理性等の利点のために、これらの反復する要素を子オブジェクトとして表わすことが可能である。

反復する構造型データを子オブジェクトとして格納することは、そのデータをディレクトリにおいて効率的に表現することを可能とし、各フィールドがサーチのために個別的に使用可能（且つインデックス）である。

例えば、ビジネスエンティティ名はビジネスエンティティオブジェクトの子として格納することが可能である。別の例は、ビジネスエンティティオブジェクトの下に子として格納することが可能なビジネス記述である。

このタイプのシステムの利点は、それが名前についてサーチすること（それは通常のＵＤＤＩサーチである）を可能とするということであり、且つエントリのＤＮがその名前が属するオブジェクトのＤＮを与える。

ＵＤＤＩは冗長の「コンテナ」ノード（属性ではなく子サブストラクチャのみを包含するＵＤＤＩ構造）を定義する。これらは、クエリーの結果から比較的低コストで構成することが可能であるので、除去することが可能である。幾つかの場合においては、属性を子ノードからその親へ進展させることが可能であり、今や冗長な子ノードをディレクトリ表現から除去する。

例えば、ｔＭｏｄｅｌＩｎｓｔａｎｃｅＤｅｔａｉｌｓは、それが属性を包含するものではないので、ディレクトリスキーマにおいて表現されることはない。ｉｎｓｔａｎｃｅＤｅｔａｉｌｓは、その属性が、その子ｏｖｅｒｖｉｅｗＤｏｃの属性がそうであったようにｔＭｏｄｅｌＩｎｓｔａｎｃｅＩｎｆｏ親内へ進展されているので、ディレクトリスキーマにおいて表現されることはない。カテゴリ及び識別子バッグはディレクトリにおいて表現されることはなく、それらのコンテントは該バッグの所有者の子とされる。

このことの利点は、それがディレクトリ内のエントリの数を減少させるということである。特に、それはＤＩＴの深さを最小とさせ、そのことは性能を改善することが可能である。

図１２は本開示の１実施例に基づく階層構造を概略的に例示している。一つ又はそれ以上のドメイン又はプレフィックス１２１が設けられている。各ドメイン１２１の下に、１つ又はそれ以上のユーザ１２２が存在する場合がある。各ユーザ１２２の下に、１つ又はそれ以上のＴＭｏｄｅｌ１２３及び１つ又はそれ以上のビジネスエンティティ（ＢＥ）１２４が設けられている場合がある。各ビジネスエンティティ１２４の下に、１つ又はそれ以上のパブリッシャアサーション（ＰＡ）１２５、１つ又はそれ以上のビジネスサービス（ＢＳ）１２６及び１つ又はそれ以上のサービスプロジェクション（ＳＰ）１２７が設けられている場合がある。各ビジネスサービス（ＢＳ）１２６の下に、１つ又はそれ以上のバインディングテンプレート（ＢＴ）１２８が設けられている場合がある。エイリアスは特定のインプリメーションにより必要とされる場合に配置させることが可能である。例えば、サービスプロジェクションオブジェクト（図１２においては三角形として示してある）はエイリアスとしてビジネスエンティティオブジェクトから派生する場合がある。

図１２に示したようなこのスキーマデザインの利点は、本開示全体を読むことから明らかなものとなる。

パブリッシャアサーションはそれらが参照するビジネスエンティティの下に配置されている。何故ならば、それらはｆｉｎｄ ＲｅｌａｔｅｄＢｕｓｉｎｅｓｓｅｓコールの文脈において最も頻繁に使用されるからであり、該コールは、ビジネスキーを特定し且つパブリッシャアサーションを介してそれと関連するビジネスの全てを探し出す。本システムは特定したビジネスを探し出し、次いでその下側の（完全な）全てのパブリッシャアサーションを読取る。これは関連性のあるアサーションを探し出すのに迅速で且つ効率的な方法である。

このことの利点は、それが高速で且つ効率的なサーチを可能とすることである。それは、又、データインテグリティを容易に維持することを可能とする。例えば、ビジネスが削除されると、全てのパブリッシャアサーションも自動的に削除される。

ＴＭｏｄｅｌは、それらをパブリッシュしたユーザにより変化させる（即ち、リタイア／隠す）ことが可能である。それらをそのユーザを表わすエントリの下に配置させることは、セキュリティを簡単なものとさせる。例えば、ＴＭｏｄｅｌがユーザエントリの下側のサブツリー内に存在する場合には、それを修正することが可能である。そうでない場合には、そうすることは不可能である。

より詳細には、変化させようとするユーザのＤＮ（識別名）がＴＭｏｄｅｌのＤＮのプレフィックスと一致する場合には、そのエントリはそのユーザにより修正することが可能であり、そうでない場合には、不可能である。ディレクトリはこの決定を行うために使用することが可能であり（ＤＮが存在しない場合にはネーミングの例外）、又はＵＤＤＩサーバーがそれを行うことが可能である。

オブジェクトがリポジトリから削除されると、そのオブジェクトに関連する情報も削除することが可能である。このことは、本スキーマの実施例に基づいて使用される階層的デザインにより著しく簡単化されている。オブジェクトが削除されると、それがルートであるサブツリー全体を削除することが可能であり、且つこのプロセスは全ての（且つ通常それのみの）関連する情報を削除することが可能である。サブツリーを削除することはボトムアップに実施することが可能である。各エントリは、その子の全てが削除される場合に削除することが可能であるに過ぎない。このことは、全ての子を逆のＤＮ順にリストすることにより管理される。このことは、それらの親の前に子を削除することを保証する。

このことの利点は、ソートリスト（ｓｏｒｔｅｄ ｌｉｓｔ）方法が、より複雑なリカーション即ち回帰を使用することの代替であるということである。更に、それは比較的簡単であり且つメモリ効率的である。サブツリー内の全てのエントリがＤＮによりソートされ、且つ逆順に削除が実行されると、このことは、全ての子がそれらの親の前に削除されることを保証する。

例えば、ビジネスサービスが削除されると、本システムはそれと関連する全てのバインディングテンプレートを、それらのＴＭｏｄｅｌインスタンス情報、及び種々の関連するカテゴリ情報を削除する。このことの全ては、そのビジネスサービスがルートであるサブツリーを削除することにより削除することが可能である。

このスキーマのデザインにおいて使用される階層に起因して、オブジェクトのＤＮは所有の遅延及びオブジェクトに対する制御を露呈させる。注意すべきことであるが、推論は、又、ネーミング属性の注意深い選択に依存する。

このことの利点は、それが情報を収集するために使用されるサーチ又は読取の数を減少させることが可能であるということである。例えば、子オブジェクト（例えば名前）であるサーチ結果の場合、各エントリのＤＮは親（例えば、ビジネスエンティティ）及びそれを所有するアカウントを露呈させる。

例えば、ビジネスサービスのＤＮは、それが属するビジネス、及びそれを制御するユーザを露呈させる。

ディレクトリは結果のどのような順番付けも保証するものではない。複雑な結果（それらの適宜の名前及び記述と共に、ビジネスエンティティ及びそのビジネスサービス等）を取り扱う場合には、出力の構成はサーチの結果を取り且つそれらをＤＮによりソーティングすることにより簡単化することが可能である。このことは、結果の構成が比較的簡単なものとなるようにそれらを編成する。各オブジェクトはその子の前に構成され、従って子をその親の下に配置することが簡単であり、従ってビジネスに対する結果はそのサービスの前に編成される。オブジェクトの全ての子は同一のタイプの次のオブジェクトの前に表われ、１つのビジネスに対するサービスの全ては次のビジネスの前に表われる。このことは、又、簡単な再帰的構造を可能とする。何故ならば、同じことが各レベルにおいて適用されるからである。

このことの利点は、ＵＤＤＩ構造を構成するために必要とされる生のエントリのリストを介してのパスの数を最小とさせることである。

例えば、ソーティングの後に、ビジネスＡに対する結果はその最初のサービスＡＡ、そのサービスの名前、に対する結果により追従され、次いでＡの２番目のサービスＡＢ及びその名前、次いで２番目のビジネスＢにより追従される。

サーチは子に関して実施することも可能である。例えば、頻繁なサーチリクエストは「その子の１つ（又はそれ以上）を見つけ出すことによりｘを見つけ出すこと」という場合がある。ビジネスをサーチにより見つけ出すことが可能な方法のうちの１つは、例えば、バインディングテンプレートにおいて発生するＴＭｏｄｅｌを特定することによるものである。換言すると、そのクエリーは「このＴＭｏｄｅｌを参照するバインディングテンプレートを有するサービスを有する全てのビジネスを探し出せ」である。これらのクエリーは、子孫のオブジェクトのＤＮを見つけ出し、且つビジネスエンティティのＤＮを発生するために不所望のレベルを切り捨てることにより行うことが可能である。好適には、之は、又、重複を取除く。このサーチ方法は、部分的には、本開示の実施例の階層構造に起因して起こるものである。

保証された一意的なキーの使用は物事を簡単化させる。リポジトリ全体を単一のキーについてサーチすることが可能であり、且つ一意性は、結果が存在しないか（そのキーが存在しない場合）、又は１つの結果が存在する（それが存在する場合）のいずれかであることを確保する。サーチを親の範囲内に制限することに関して注意することは必要ではない。このことは、ディレクトリから向上された性能を発生する。何故ならば、それはデータベースインデックスを最適状態に使用することが可能だからである。

このことの利点は、それが最も速いタイプのディレクトリクエリーを利用するということである。別の利点は、与えられたオブジェクトが別のものから参照される場合に保証された一意的な名前が重要な場合があるということである。

殆どのインデキシング方式のプロパティ即ち性質は、それらがデータ従属性であることである。データが「リトルエンディアン」（最も左側の部分が最も迅速に変化する）である場合には、そのデータは広がる傾向にあり、従ってインデックスは最大の性能を与えることが可能である。逆に、そのデータが反復的である場合には、インデックスは非常に効果的なものでない場合がある。ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）アルゴリズムを使用することが可能であり、それは「リトルエンディアン」の性質を示す。このことの利点は、それがディレクトリ性能を最大化させるということである。

キーは派生されたオブジェクトへ付加させることが可能である。反復するデータ要素が子オブジェクト内に入れられる場合には、ネーミング属性を付加することが必要であり、それはそのＤＮの最後のアーク（ａｒｃ）を形成する。ディレクトリにおいて、ネーミング属性はその兄弟姉妹とは異なっている。何故ならば、同一の親の二人の子が同一の名前を有することは不可能だからである。

２つの種類のキーを使用する場合がある。順番を必要としない子オブジェクトの場合、ＵＵＩＤが使用される。何故ならば、これらは一意的なものであることが保証されているからである。順番が重要である場合には、単調的に増加する特性を有するキーを使用して順番を保証する。

ＵＤＤＩスタンダードにおいては、ビジネスエンティティは、それらが別のビジネスエンティティにより提供されるという事実にも拘わらず、２つの種類のサービス、即ちそれが制御するもの（子オブジェクトによりリポジトリ内において表わされる）、及びそれがそれに対してインターフェースを提供するもの、を提供することが可能である。後者はエイリアスにより開示されたＵＤＤＩリポジトリにおいて表わされる。エイリアスは正に正しい特徴を与える。例えば、オリジナルのオブジェクト（サービス）がその所有者により何等かの態様で変更される場合に（多分、別のバインディングテンプレートが付加される）、そのエイリアスを介して参照されるオブジェクトも「変化する」。更に、サービスに対するビジネスエンティティの下でのサーチは実際の及びエイリアス型の両方のサービスを発生する。

例えば、エイリアスは、サービスプロジェクションに対して使用することが可能であり、その場合には、ビジネスは別のビジネスの下で定義されているサービスに対してポイント即ち指し示すことが可能である。

このことの利点は、てこ入れ用のエイリアスは、基本的に、「代替的な名前」を自動的に供給させることが関与する機能性を可能とさせるということである。更に、ディレクトリがエイリアスのインテグリティをサポートする場合には、そのオリジナルのサービスが削除されると、全てのプロジェクションが自動的に取除かれる。

ＵＤＤＩスタンダードにおいては、別のオブジェクトへの直接的な参照を有することを望むものではなく、むしろ、ＴＭｏｄｅｌインスタンス情報の場合には、中間的なステップ、又はパブリッシャアサーションにおいてはビジネスエンティティへの参照を有することを望む多数の場所が存在している。これらの場合には、エイリアスはコードを複雑化させることとなる。従って、その代わりに、本システムはオブジェクトに対する参照を使用する場合がある。本システムは、１実施例によれば、全てのオブジェクトが一意的なキーを有することを保証するので、そのキーは正確に参照として動作し、時折、「フォーリン」キーとして知られている。

属性のグルーピングを補助的なオブジェクトクラスを使用して実施することが可能である。パブリッシャアサーションを取り扱う場合に、パブリッシャアサーションを一意的に識別するこれら３つの属性、即ち２つのビジネスエンティティキー、及びそれらの間のリレーションシップ即ち関係を使用してパブリッシャアサーションを探し出す能力に対する必要性が存在している。然しながら、そのリレーションシップはキー型参照として特定され、それ自身は３つの異なる属性、即ちＴＭｏｄｅｌキー、キー名、キー値である。１つの方法は、このリレーションシップをパブリッシャアサーションの子オブジェクトとして格納することである。然しながら、このことは特定のパブリッシャアサーションに対して最も効率的なサーチを可能とするものでない場合がある。キー型参照のリレーションシップをパブリッシャアサーションエントリに対する補助的なクラスとすることにより、単一のサーチにおいて５つの属性全てに対してサーチを行うことが可能であり、従って、必要とされるパブリッシャアサーションオブジェクトを正確に分離させることが可能である。

このスキーマの１つのデザインは、通常のオブジェクト指向型デザイン技術を使用する場合があり、且つ、例えば、同一の属性名を有する全てのキー型参照を発生する。然しながら、このデザインは、例えば、ビジネスエンティティカテゴリキー型参照を分離させ、且つそれをＴＭｏｄｅｌカテゴリＴ型参照と混乱させることを回避することをより困難且つ高価なものとさせる場合がある。それは、又、フィルタ内にオブジェクトクラス項目を包含させることを必要とする場合があり且つこのような項目は弱いものである（リポジトリ内において高度に反復的である）。

例えば、全ての異なる種類のキー型参照に異なるオブジェクトクラス及び異なる属性名を与えることは、特定の属性名に対するサーチが必然的にそのオブジェクトクラスを暗示することを意味している。それは、又、ディレクトリサーバーが所望とされる特定の種類のエントリに対してその中にエントリを有するに過ぎないインデックスを構成することを可能とすることを意味している。このようなインデックスはより小さく、従ってより高速である。

例えば、「ｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅ＝Ｓｍｉｔｈ＊」のようなサーチはｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅに対するインデックスを検査し、従ってｅｕＴＭｏｄｅｌＮａｍｅと呼ばれる属性においてＳｍｉｔｈを包含するエントリと混乱させることは不可能である。

ＵＤＤＩスタンダードの範囲外のツールに対する要請が存在する場合がある。このようなツールはＵＤＤＩスタンダードにおいて特定されているものを超えるアクセス手段を提供することを必要とする場合がある。このようなツールを可能とするために、本開示は単一のＵＤＤＩ概念を表わすオブジェクトクラスの全てをバインドする抽象的なクラスを定義している。このことは、例えば、全ての名前又は全てのキー型参照を見ることが可能なサーチを定義することを可能とする。

例えば、ｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅ及びｅｕＴＭｏｄｅｌＮａｍｅを包含する名前型オブジェクトクラスの全てのスーパークラスである抽象的なクラスｅｕＮａｍｅが存在している。

ＵＤＤＩスタンダードは、例えば、大文字小文字を区別する態様及び大文字小文字を区別しない態様の両方で名前をサーチすることが可能であることを特定する。このことは、大文字小文字を区別せずにインデックス処理し、次いでエントリを検索し且つそれらを大文字小文字を区別してチェックすることによって取り扱うことが可能であるが、このようなアプローチは性能を犠牲にする。これらの場合においては、同一のデータを包含しているが別異にインデックスされているシャドウフィールドを定義することが望ましい。同様に、シャドウ属性を言語におけるバリエーション、例えば発音区別符に対して使用することが可能である。

例えば、ｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅオブジェクトクラスは各名前の２つのコピーを包含している。最初のバージョンは大文字小文字を区別せずにインデックスされ、一方第二のものは大文字小文字を区別してインデックスされる。このことは、サーチフィルタを構成することを可能とし、それは、どのような動作が要求されようとも最適に動作を行う。

このリポジトリにおける全ての属性（オブジェクトクラスを除く）は単一値型とすることが可能である。このことは、ディレクトリがより効率的なインデックスを構成し且つサーチにおいてより良い性能を提供することを可能とする。

このことは、又、サーチにおいて偽陽性の結果の可能性を取除く。例えば、「Ｆｒ」で始まり且つ「ｎｋ」で終了する名前を探すサーチについて検討する。このことは、「Ｆｒａｎｋ」のような名前を有する（有効な）エントリを発生するものと考えるかもしれない。然しながら、名前が多値型属性とされている場合には、「Ｆｒｅｄ」及び「Ｔｉｎｋ」のような２つの名前を有する無効なエントリを得る場合がある。何故ならば、この１つのエントリが特定された両方の基準にマッチするからである。その各々がエントリの子オブジェクトである単一値型の名前を使用することにより、「Ｆｒｅｄ」及び「Ｔｉｎｋ」のような偶発的なマッチングが除去される。

オペレーショナル属性は、ＵＤＤＩアプリケーションにより管理されるがユーザには見えない特別の属性である。

ＵＤＤＩデータの格納において、使用中であるＴＭｏｄｅｌを「リタイア（ｒｅｔｉｒｅ）」されたものから区別する方法を有することを可能なものとすべきである。ＴＭｏｄｅｌが削除されると、それが多くのエントリにより未だに使用される場合があり、従ってそれは真に削除することは不可能である。その代わりに、それは隠され、そのことは、ｆｉｎｄ ＴＭｏｄｅｌコールの結果の一部としてリターンされることはないが、それは、尚且つ、ｇｅｔ ＴＭｏｄｅｌＤｅｔａｉｌコールを介してクエリーさせることが可能であることを意味している。このことはｅｕＨｉｄｄｅｎと呼ばれる属性の使用により実現され、それは隠されるＴＭｏｄｅｌへ付加される。ｅｕＨｉｄｄｅｎ属性を包含するエントリを除去するサーチステップをＴＭｏｄｅｌをサーチするフィルタへ付加することが有益的であり且つ効率的である場合がある。

ディレクトリのインプリメンテーション即ち実現において、支配的に１つの値である属性を有することは一般的には非常に非効率的であると考えられている。例えば、エントリの９９％に対しＦＡＬＳＥに設定されている隠れ属性を有することは、拙い性能を発生し、そのインデックスは殆ど使用不可能である。

より効果的なものであると考えられるものは、隠れ属性無しに大多数のエントリを格納し、且つ隠されるべきエントリに対してのみ属性を付加させることである。このことは、これら全ての「ＦＡＬＳＥ」値を保持するための格納空間を必要とすることがないという付加的な利点を有している。隠されないＴＭｏｄｅｌの全てを見つけるためのフィルタは「（！（ｅｕＴＭｏｄｅｌ＝＊））」となり、それは存在テストの否定であり、特にエントリの小さい割合に関してのみ属性が存在する場合には存在テストは迅速である。

ディレクトリの文脈におけるインプリメンテーション及びＵＤＤＩスタンダードの問題を解決するための本開示の１実施例について説明する。Ｘ．５００スキーマに対し多数の要素が存在している。これらの要素は属性定義、オブジェクトクラス定義、名前バインディング定義を包含している。属性定義は単一データ要素を特定し、それに一意的な識別子（ＯＩＤ）、名前、データタイプを与える。オブジェクトクラス定義は全体として取り扱われる一群の属性を特定する。それは一意的な識別子（ＯＩＤ）、名前、属性のリストを与え、該属性は必要とされるもの又はオプションとすることが可能である。名前バインディングは可能な階層の一部を特定する。名前バインディングは別のものの下に格納することが可能な１つのオブジェクトクラスを特定し、且つこの文脈において子オブジェクトに名前を付ける子の属性（又は複数の属性）を特定する。

付加的なデザイン条件を課す多数の発見識別子が存在している。１つの発見識別子は、大文字小文字を区別する態様及び大文字小文字を区別しない態様の両方において効率的にテキストデータをサーチする能力を与えるために大文字小文字区別性である。本開示の１実施例によれば、大文字小文字区別性は別異にインデックスされてオブジェクト内に付加的なフィールドを与えることにより解決することが可能である。

この実施例によれば、テキストデータはタイプｃａｓｅＥｘａｃｔＳｔｒｉｎｇの属性において及びタイプｃａｓｅＩｇｎｏｒｅＳｔｒｉｎｇの属性において二度格納される。従って、該発見識別子は該フィールドのうちのいずれがサーチされるかを決定し、最大の性能を発生する。

例えば、ビジネスエンティティが「ＭｃＫｅｎｎａ’ｓ Ｉｒｏｎ Ｆｏｕｎｄｒｙ Ｓｅｒｖｉｃｅｓ」のような名前を有している場合には、そのストリングは二度格納され、即ち大文字小文字を区別してインデックスされるフィールドにおいて一度と大文字小文字を区別せずにインデックスされるフィールドにおいて一度であり、格納されるデータは同じであるが、基礎となるディレクトリにより発生されるインデックスは異なる。別の問題は、サービスプロジェクションを効率的にインプリメント即ち実現することに関与する。本開示の１実施例によれば、このことは、Ｘ．５００エイリアスファシリティを使用して解決することが可能である。サービスプロジェクションを取り扱うことが可能な多数の方法が存在している。本開示のこの実施例は、ディレクトリエイリアスによりそれらを取り扱う。このことは、それらをインプリメントするための特に効率的な方法である。それはベースサービスとのプロジェクションの一貫性を保証する。何故ならば、ベースサービスはエイリアスを介して直接的にアクセスされるからである。それは、又、ベースサービスが削除されるや否やそのプロジェクションが消滅することを保証し、従って一貫性を確保する。

例えば、Ｗｉｌｌｉａｍｓ Ａｃｃｏｕｎｔｉｎｇ Ｓｅｒｖｉｃｅｓと呼ばれるビジネスエンティティがＧｅｎｅｒａｌ Ｌｅｄｇｅｒ Ｃｒｏｓｓ−Ｃｈｅｃｋと呼ばれるウエブサービスをパブリッシュし、且つ同じサービスをＷｉｌｌｉａｍｓ Ａｕｄｉｔｉｎｇ Ｓｅｒｖｉｃｅｓと呼ばれる第二のビジネスエンティティの下で提供することが所望される場合に、このことは、２番目のビジネスエンティティの下にエイリアスエントリを配置させることにより達成することが可能である。Ｗｉｌｌｉａｍｓ Ａｕｄｉｔｉｎｇ Ｓｅｒｖｉｃｅｓにより提供されているサービスを列挙する照会者は、Ｗｉｌｌｉａｍｓ Ａｕｄｉｔｉｎｇ Ｓｅｒｖｉｃｅｓにより直接的に提供されているサービスを見つけ出す場合と同じくＧｅｎｅｒａｌ Ｌｅｄｇｅｒ Ｃｒｏｓｓ−Ｃｈｅｃｋサービスを見つけ出す。

別の問題は効率的にキーを実現することに関与する。本開示の１実施例によれば、このことは、外部キー及び順番が重要でないキーに対してＵＵＩＤを使用して解決される。順番が重要である場合にはシーケンシャルな数を使用することが可能である。キーがストリングとして表わされるが、それらは真にテキストデータではない。それらは、大文字小文字の区別無しに又は識別記号無しで比較される。

外部的に見えるキーは１組の規則に従う。ＵＤＤＩ仕様のバージョンに準拠するリポジトリを実現する場合に、それらはＩＳＯ−１１５７８に準拠するＵＵＩＤを保持する。ＵＤＤＩ仕様のバージョン３に対するリポジトリを実現する場合には、それらはその仕様のそのバージョンに規定されている規則に従うキーストリングを保持する。

注意すべきことであるが、要素を一体的にリンクするために内部的に使用されるキーは別の組の規則に従う。順番が重要でないものはＵＵＩＤを使用する。順番が重要である場合には、シーケンシャルな番号を使用する。

例えば、Ｗｉｌｌｉａｍｓ Ａｕｄｉｔｉｎｇ Ｓｅｒｖｉｃｅｓと呼ばれるビジネスエンティティに対するカテゴリバッグの要素を表わすキー型参照は、１２３４５６７８−１２３４−１２３４−１２３４−１２３４５６７８９０ａｂ（ＵＤＤＩ Ｖ２）のキーを有するＴＭｏｄｅｌを参照する場合がある。カテゴリバッグ内のキー型参照の順番は重要ではないが、キー型参照はオブジェクトのネーミング属性として機能するキーを必要とする。従って、８７６５４３２１−４３２１−４３２１−４３２１−ｂａ０１２３４５６７８９のようなこのオブジェクトに対するＵＵＩＤキーを発生する場合があり、且つそれをこのオブジェクトに対するディレクトリにおけるネーミング属性として使用する場合がある。

別の問題は、Ｘ．５００ディストリビューションが所望される場合に、データをドメイン内に編成する場合である。このことは、各リポジトリを異なるサーバーの上に配置することが可能であるように、ユーザの上にリポジトリレイヤーを作成することにより本開示の１実施例に従って解決される。

ＵＤＤＩスタンダードは、名前空間をディストリビュート即ち配布させることを許容するものではない。このことは、複数のＵＤＤＩレジスターが、レプリケーションによって、又はディストリビュートされた名前空間を管理するバックエンドデータストアをトランスペアレントに有することによって、互いに共同することが可能であることを意味している。

ディストリビュートされた名前空間は、ネーミングプレフィックスを有する各リポジトリにより容易化させることが可能である。このプレフィックスはドメインを定義する１組のノードである。これらのノードは、各ＵＤＤＩレジストリの上のリポジトリレイヤーと考えることが可能である。これらのノードはユーザレベルの上に配置される。

図１１は「ドメイン（Ｄｏｍａｉｎ）」１１０と呼ばれるノードの例を例示している。ドメイン１１０はディレクトリプレフィックスであり且つルートに至るまで１個又はそれ以上のノードを包含する場合がある。ドメイン１１０の下に、この例は、例えば、多数のユーザ１１２，１１３，１１４の配置を例示している。ドメイン１１０の下に配置させたユーザの数は、本システムの特定のコンフィギュレーション即ち形態及び／又は使用に従って変化する場合がある。本システムの特定のコンフィギュレーション及び／又は使用に依存して配置される多数のドメインが存在する場合もある。以下の例においては、それらはリポジトリオブジェクトと呼称され、それらが別個の物理的リポジトリを表わすものであることを暗示している。勿論、このことは、本システムのコンフィギュレーション及び／又は使用に依存して、必ずしもそうでない場合がある。

このリポジトリオブジェクトはネーミング属性を必要とするが、それが全てである。

ディストリビューションは、大型のディレクトリデプロイメントにおいて重要な概念である。というのは、それは大きな帯域幅オーバーヘッド及びレプリケーションの同期問題無しで多数のノードによりデータを共有することを可能とするからである。

１つの実施例において、「ｅＴｒｕｓｔ」ＵＤＤＩは、その基礎となるｅＴｔｒｕｓｔディレクトリサーバーの能力を使用してディストリビューションをサポートし、且つこのことが働くためには、スキーマがそれに従って構成され、ツリー階層の上部に仮想「ドメイン」ノード用の余裕を設け且つ各ノードサブツリーの上部に一意的なノード識別子又は名前を設ける（以下のＵＤＤＩスキーマ記述を参照）。

更に、ｅＴｒｕｓｔＵＤＤＩサーバーは、コンフィギュレーションを介して「ディストリビューションアウェア（ｄｉｓｔｒｉｂｕｔｉｏｎ−ａｗａｒｅ）」とすることが可能である。２つの別個のディレクトリプレフィックスを特定することが可能であり、サーチ及び読取のために１つとエントリを付加するために別の１つである。分散型サーバーをデプロイするために、その基礎となるｅＴｒｕｓｔディレクトリサーバーエージェントがｅＴｒｕｓｔディレクトリ管理ガイドのようにディストリビューションのためにコンフィギュア即ち形態が決められる。各別個のｅＴｒｕｓｔＵＤＤＩノードは一意的なノード名でコンフィギュアされる。各ノードに対するサーチ／読取プレフィックスは「Ｗｏｒｌｄ」又は「Ｃｏｒｐｏｒａｔｉｏｎ」ノード名に設定される。各ノードに対する付加プレフィックスはそのノードの一意的な名前に設定される。

このように、各ノードはそれ自身のディレクトリリポジトリに対してエントリを付加するが、Ｘ．５００ディレクトリのディストリビューション特徴を介して全てのノードにわたりエントリをサーチする。

リポジトリオブジェクトの１つの例は、
ｅｕＲｅｐｏｓｉｔｏｒｙＮａｍｅ＝Ｍｅｌｂｏｕｒｎｅ
である場合がある。

別の問題は、ユーザに関して保持されるデータを編成することに関与する。このことは、データを保持するためのユーザオブジェクトを作成することにより解決することが可能である。

ＵＤＤＩ仕様において特定されているユーザオブジェクトは存在しないが、このようなオブジェクトは、本開示の１実施例に従って利用することが可能である。例えば、ユーザオブジェクトは、とりわけ、ユーザクリデンシャルに対する格納点及びパブリッシング用のアンカー点とすることが可能である。

図１０は「ユーザ（Ｕｓｅｒ）」１０１と呼ばれるこのような配置の１つの例を例示している。ユーザ１０１の下に、この例は、ビジネスエンティティオブジェクト１０２、ビジネスサービスオブジェクト１０３、バインディングテンプレートオブジェクト１０４のようなその他のオブジェクトの配置を例示している。ユーザ１０１の下に配置されるビジネスエンティティオブジェクトの数は、本システムの特定のコンフィギュレーション及び／又は使用に従って異なる場合がある。本システムの特定のコンフィギュレーション及び／又は使用に依存して配置される多数のユーザが存在する場合もある。

ユーザオブジェクトにおいて保持されるデータ要素は、ユーザキー（このユーザアカウントに対して一意的な名前を与えるために使用される）、ユーザ名、及びクリデンシャル（パスワードのように簡単な場合もあり、又はＰＫＩ証明書のように複雑な場合もある）を包含している。それは、又、承認された名前（ユーザアカウントを動作すべく承認された人又は役割を識別する）を包含する場合がある。それは、又、ユーザにより定義されたＴＭｏｄｅｌを失うことなしに、ユーザアカウントの削除を取り扱う場合に使用される隠れフラッグを包含する場合がある。

ユーザカウントオブジェクトの１つの例は、

である場合がある（この例においては、簡単なユーザＩＤ及びパスワードシステムが実現されているものと仮定している）。

別の問題は、ビジネスエンティティ（ＵＤＤＩスタンダードにおいて記述されるオブジェクトクラス）に関するデータを効率的な態様で表現することに関与する。このことは、一意的なフィールドをそのオブジェクトの属性として表わし、且つ子として要素を繰り返すことにより本開示の１実施例に従って解決される。

このビジネスエンティティオブジェクトは、ＵＤＤＩスタンダードの基本的なコンポーネントである。そのコンテント即ち内容は、該スタンダードにより定義されるが、その要素の多くは反復する複合オブジェクトであり、それらはＸ．５００スキーマによりサポートされるものではない。このような要素は階層的配置により表わされる。

ビジネスエンティティにおける唯一の必要とされる要素はビジネスキーである。オプションの要素は、承認された名前、オペレーター、ユーザキーを包含する（この最後のものは通常のユーザによりパブリッシュされるビジネスエンティティ内に存在する）。

ビジネスエンティティの可能な子オブジェクトは、名前（名前ストリング及び言語コードを包含するオブジェクトで順番に対してキーが付けられている）、記述（記述ストリング及び言語コードを包含するオブジェクトで、順番に対してキーが付けられている）、コンタクト（複雑なオブジェクト、後に説明する）、ディスカバリーＵＲＬ（ＵＲＬストリングとユーザタイプとを包含するオブジェクトでキーが付けられている）、オブジェクトクラスの選択を介してカテゴリ又は識別子情報としてマークが付けられているキー型参照、及びビジネスサービス（以下に説明する）である。

ビジネスエンティティオブジェクトの１つの例は、

である場合がある。

注意すべきであるが、ビジネスエンティティオブジェクトの見かけのコンテントの殆どは、実際には、そのビジネスエンティティオブジェクトの直接的な子であるオブジェクト内に格納されている。

図１５はビジネスエンティティにおける比較的複雑なオブジェクトの表現に対する本開示の１実施例に基づくサブストラクチャ内への階層の導入の１例を例示している。図１５において、多値型要素、
子１５２の場合
言語 ｅｎ
名前 ＣＡ
子１５３の場合
言語 ＩＮ
名前 ＣＡＴＳ
は、ビジネスエンティティ１５１の子１５２，１５３として表現されている。子は全くないか又はより多くある場合がある。

解決すべき別の問題は、ビジネスサービス（ＵＤＤＩスタンダードにおいて記述されるオブジェクトクラス）に関するデータを効率的な態様で表わすことである。

このことは、そのオブジェクトの属性として一意的なフィールドを表わし且つ子として要素を繰り返すことにより本開示の１実施例に基づいて解決することが可能である。

ビジネスサービスは少なくとも２つの態様で実現することが可能である。最初のものは、ビジネスサービスが、その各々がバインディングテンプレートにより表わされる１つ又はそれ以上のアクセスルートを介して使用可能なビジネスエンティティにより提供される単一の概念的サービスを表わすものである。第二のものは、ビジネスサービスが、サービスに対するグルーピングメカニズムにあり、ここのサービスへの分解がバインディングテンプレートレベルにおいて行われるようなものである。いずれの場合においても、データフィールドはＵＤＤＩ仕様において定義される。

ビジネスサービスの要素は、ビジネス及びサービスキーである。ビジネスキーはそのサービスを所有するビジネスエンティティを特定する。これは、必ずしも、その下側に発見されるビジネスエンティティではない。単一のサービスは、サービスプロジェクションにより、幾つかのビジネスエンティティの下側に見つけることが可能である。サービスキーは、ＵＤＤＩリポジトリを介してのサービスの一意的な識別子である。両方のキーはストリングとして表わされる。

ビジネスサービスオブジェクトのオプションのコンテントは存在しない。その他の全てのコンテントは、潜在的に反復的な要素から構成され、従って子オブジェクトとして表わされる。ビジネスサービスの潜在的な子オブジェクトは、バインデンィングテンプレート（Ｂｉｎｄｉｎｇ Ｔｅｍｐｌａｔｅ）（以下参照）、名前（Ｎａｍｅ）（名前ストリング及び順番付けのためにキーが付けられている言語コードを包含しているオブジェクト）、記述（Ｄｅｓｃｒｉｐｔｉｏｎ）（記述ストリング及び順番付けのためにキーが付けられている言語コードを包含しているオブジェクト）、及びカテゴリ情報としてマーク付けされているキー型参照である。

例えば、ビジネスサービスオブジェクトは以下のものである場合がある。

注意すべきことであるが、ビジネスサービスオブジェクトの見かけの内容の殆どは、実際には、ビジネスサービスオブジェクトの直接的な子であるオブジェクト内に格納されている。

図１５はビジネスエンティティにおける比較的複雑なオブジェクトの表現に対しての本開示の１実施例に基づいて階層をサブストラクチャ内に導入する１例を例示しているが、ビジネスサービスにおける比較的複雑なオブジェクトの表現に対しての本開示の１実施例に基づいて階層をサブストラクチャ内に導入する一例も同じように例示するものである。図１５のビジネスエンティティ１５１はビジネスサービスに対しても等しく適用可能であり、ビジネスサービスの多値型要素はビジネスサービス１５１の子１５２，１５３として表わされている。全く子が存在しないか又はより大きくの子が存在する場合がある。

更に別の問題は、バインディングテンプレート（ＵＤＤＩスタンダードで記述されたオブジェクトクラス）に関するデータを効率的な態様で表わすことに関与する。このことは、一意的なフィールドをそのオブジェクトの属性として表わし、且つ要素を子として反復することにより本開示の１実施例に基づいて解決されている。

バインディングテンプレートは、特定のサービスへアクセスすることが可能な態様を表わしている。バインディングテンプレートの唯一の必要とされる要素は、そのキー及びそれが適用されるサービスのキーである。オプションとしての要素は、アクセスポイント又はホスト用リダイレクター（オブジェクトは正にこれらのうちの一つを有するべきである）を包含する場合がある。アクセスポイントが存在する場合には、アクセスポイントタイプも存在すべきである。

バインディングテンプレートの可能な子オブジェクトは、ＴＭｏｄｅｌインスタンス情報（ＴＭｏｄｅｌ Ｉｎｓｔａｎｃｅ Ｉｎｆｏ）（以下参照）、及び記述（Ｄｅｓｃｒｉｐｔｉｏｎ）（記述ストリング及び順番付けのためにキーが付けられている言語コードを包含しているオブジェクト）である。

バインディングテンプレートの一つの例は以下のものである場合がある。

再度、図１５は、ビジネスエンティティにおける比較的複雑なオブジェクトの表現に対して本開示の１実施例に基づいて階層のサブストラクチャ内への導入の１例を例示するものであるが、それは、バインディングテンプレートにおける比較的複雑なオブジェクトの表現に対して本開示の１実施例に基づいて階層をサブストラクチャ内へ導入する１例についても等しく例示するものである。図１５のビジネスエンティティ１５１は、等しく、バインディングテンプレートに適用可能であり、バインディングテンプレートの多値型要素はバインディングテンプレート１５１の子１５２，１５３として表わされる。子は全く存在しないか又はそれ以上存在する場合がある。

別の問題は、ＴＭｏｄｅｌ（ＵＤＤＩスタンダードで記述されたオブジェクトクラス）に関するデータを効率的な態様で表わすことに関与している。本開示の１実施例によれば、このことは、一意的なフィールドをそのオブジェクトの属性として表現し、且つ要素を子として表わすことにより解決することが可能である。

ＴＭｏｄｅｌは一つのアイディアを表わしている。そのアイディアは、例えば、妥当性検査される場合がある値の仕様を必要とするカテゴリ化システムである場合がある。又は、
それは、データ通信プロトコルの仕様である場合がある。ＴＭｏｄｅｌは、柔軟性があり且つ強力な概念であり、且つ実際にクエリーすることが可能な態様で複雑なデータを表わすためのＵＤＤＩの能力の中心的なものである。

ＴＭｏｄｅｌオブジェクトの唯一の必要とされる要素はＴＭｏｄｅｌキー及び名前である。これらはストリングとして表現される。

ＴＭｏｄｅｌオブジェクトの最適な要素は承認された名前、オーバービューＵＲＬ（オーバービューＤｏｃオブジェクトの一部）、ユーザキー、及び隠れフラッグである。

隠れフラッグは、ＴＭｏｄｅｌの取り扱いの要素である。隠れフラッグは、どのようにしてｄｅｌｅｔｅＴＭｏｄｅｌコールを取り扱うかということである。ＴＭｏｄｅｌが「削除」されると、隠れフラッグがそのオブジェクトへ付加される。このことは、オブジェクトはｆｉｎｄＴＭｏｄｅｌコールへリターンされないが、ｇｅｔＴＭｏｄｅｌコールへアクセス可能であることを意味している。

可能な子オブジェクトは、記述（Ｄｅｓｃｒｉｐｔｉｏｎ）（記述ストリング及び順番付けに対してキーが付けられている言語コードを包含するオブジェクト）、カテゴリ又は識別子情報としてマーク付けされているキー型参照、及びオーバービューＤｏｃ記述（記述ストリング及び順番付けのためにキーが付けられている言語コードを包含するオブジェクト）である。

ＴＭｏｄｅｌの一つの例は以下のようなものである。

再度、図１５は、ビジネスエンティティにおける比較的複雑なオブジェクトの表現に対して本開示の１実施例に基づく階層のサブストラクチャへの導入の１例を例示しているが、それは、等しく、ＴＭｏｄｅｌにおける比較的複雑なオブジェクトの表現に対して本願の１実施例に基づく階層のサブストラクチャ内への導入の１例を例示するものである。図１５のビジネスエンティティ１５１は、等しく、ＴＭｏｄｅｌに対して適用可能であり、ＴＭｏｄｅｌの多値型要素はＴＭｏｄｅｌ１５１の子１５２，１５３として表現されている。子は全く存在しないか又はより多くのものが存在する場合がある。

別の問題は、パブリッシャアサーション（ＵＤＤＩスタンダードにおいて記述されたオブジェクトクラス）に関するデータを効率的な態様で表わすことに関与している。

本開示の１実施例によれば、このことは、一意的なフィールドをオブジェクトの属性として表現し、且つ所要の関係のキー型参照に対して補助的クラスを使用することにより解決することが可能である。

パブリッシャアサーションは、２つのビジネスエンティティの間の関係を表わすオブジェクトである。

パブリッシャアサーションの所要の要素は、そのキー、ビジネスへ及びビジネスから及びユーザキー、ステータス、リレーションシップ即ち関係である。このリレーションシップは、キー型参照として特定され、且つパブリッシャアサーションエントリに対する補助的クラスとして格納される。そのステータスはストリングとして格納されるが、その可能な値はコンプレションステータス（Ｃｏｍｐｌｅｔｉｏｎ Ｓｔａｔｕｓ）オブジェクトから引き出される。全てのキーはストリングとして表わされる。

パブリッシャアサーションにはオプションのコンテント即ち内容は存在しておらず、且つ子オブジェクトは存在していない。

パブリッシャアサーションの一つの例は以下のような場合がある。

注意すべきことであるが、このエントリと関連する補助的クラスが存在しており、それはオブジェクトクラスｅｕＰｕｂｌｉｓｈｅｒＡｓｓｅｒｔｉｏｎＲｅｌａｔｉｏｎｓｈｉｐＫｅｙｅｄＲｅｆｅｒｅｎｃｅであり、且つ名前が付けられた２つのビジネスエンティティの間でアサートされている関係を特定する。一つの例は以下のような場合がある。

別の問題は、キー型参照（ＵＤＤＩスタンダードにおいて記述されるオブジェクトクラス）に関するデータを効率的な態様で表わすことに関与する。このことは、キー型参照の特定の集まり、例えば、ビジネスエンティティに関するカテゴリバッグ、を効率的にサーチすることが可能であることの必要性によりより複雑なものとされる。

このことは、キー型参照を表わすために抽象的ベースクラスを作成し、且つ所望の集まりの各々に対してそれをサブクラス化することにより本開示の１実施例に基づいて解決される。該集まりは、ディレクトリにおける表現を有するものではない。例えば、それらは、同一のサブクラスのキー型参照の１つのグループとして存在するものに他ならず、同一のオブジェクトの子として存在している。例えば、ビジネスエンティティのカテゴリバッグは、特定されたビジネスエンティティの子であるクラスｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＣａｔｅｇｏｒｙＫｅｙｅｄＲｅｆｅｒｅｎｃｅのオブジェクトである。注意すべきことであるが、ビジネスエンティティオブジェクトは、子として幾つかのキー型参照オブジェクトを有することが可能であり、それらのオブジェクトクラスのみが、どれがカテゴリバッグの一部であり且つどれが識別子バッグの一部であるかを明らかなものとさせる。

キー型参照は、ＵＤＤＩデータモデル内において幾つかの場所において使用される。それらは、ＴＭｏｄｅｌキー、キー名、キー値を包含している。キー型参照の２つの使用はカテゴリバッグ及び識別子バッグである。これらのバッグは、キー型参照の集まりであり、サーチのために重要である。これらのバッグは差別されていないキー型参照を包含するオブジェクトにより表わされる場合には、効率的なサーチを実現することは潜在的に著しく困難である。このことは、キー型参照の幾つかのサブクラスが実現されているかの理由である。ビジネスエンティティに関するカテゴリバッグは、クラスｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＣａｔｅｇｏｒｙＫｅｙｅｄＲｅｆｅｒｅｎｃｅの１つ又はそれ以上の子オブジェクトにより表わされる。このことは、それらのカテゴリバッグ内の特定したキー型参照でビジネスエンティティに対する効率的なサーチを実現することを容易なものとさせる。

以下の例は、アブストラクト（ａｂｓｔｒａｃｔ）即ち抽象的クラス、及び上述したような、派生したクラスのうちの１つｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＣａｔｅｇｏｒｙＫｅｙｅｄＲｅｆｅｒｅｎｃｅを示している。注意すべきことであるが、キー型参照に対するキーはアブストラクトクラスから継承されており、一方ＴＭｏｄｅｌキー、キー名、キー値は全て派生されたクラスにおいて特定され、従ってそれらはサーチのために独特の名前を有する場合がある。

コンタクトは多様な情報を表わす複雑なオブジェクトである。ビジネスエンティティと殆ど同じように、コンタクトは多様な複合反復要素を保持し、子オブジェクトクラスの使用を必要とする。

コンタクトオブジェクトの直接的な一部である唯一のデータ要素はキー、そのコンタクトが表わす人又は役割の名前である。オプションの使用タイプが存在している。

その他の可能な要素の全てはコンタクトオブジェクトの子である。これらは、アドレス（Ａｄｄｒｅｓｓ）（各々が、キー、使用タイプ、ソートコード、ＴＭｏｄｅｌキーを有する、アドレスラインオブジェクトの順番付けリストの親）、電話（Ｐｈｏｎｅ）（電話番号＋使用タイプ）、電子メールｅ−ｍａｉｌ（電子メールアドレス＋使用タイプ）、記述（Ｄｅｓｃｒｉｐｔｉｏｎ）（記述ストリング＋言語コード）である。

再度、図１５はビジネスエンティティにおける比較的複雑なオブジェクトの表現に対し本開示の一実施例に基づく階層のサブストラクチャ内への導入の１例を例示しているが、それは、同様に、コンタクトオブジェクトにおける比較的複雑なオブジェクトの表現に対し本開示の１実施例に基づいて階層をサブストラクチャ内へ導入する１つの例を例示するものである。図１５のビジネスエンティティ１５１はコンタクトオブジェクトに対して適用可能であり、コンタクトオブジェクトの多値型要素はコンタクトオブジェクト１５１の子１５２，１５３として表わされる。子は全く存在しないか又はそれ以上存在する場合がある。

別の問題は、名前及び記述（ＵＤＤＩスタンダードにおいて特定されている）を効率的な態様で表わすこと、及び特定のタイプの名前又は記述に対し迅速なサーチを可能とすることに関与する。

本開示の１実施例によれば、本システムは名前を表わすためにアブストラクトベースクラスを作成し、且つ記述を表わすために別のものを作成し、且つそれらを所望のタイプの各々に対してサブクラス化する。特定のタイプの名前（例えば、ビジネスエンティティ名）に対して探す場合にサブクラスの属性に対してサーチし、且ついずれかの名前を探す場合にアブストラクトクラスに対してサーチする。主要なオブジェクト（ビジネスエンティティ、ビジネスサービス等）の幾つかは、複数個の名前及び記述のオプションを有している。その理由は多種多様である。一つのビジネスが複数の名前で知られていることは珍しいことではなく、多分、１つが正式なもので且つ１つ又はそれ以上が日常会話的なものである。更に、１つのビジネスが異なる言語で異なる名前を使用する場合がある。例えば、一つの名前がまずく翻訳されることは珍しいことではない。例えば、コンピュータ会社Ｆｕｊｉｔｓｕは何年もの間英語を話す国において名前Ｆａｃｏｍを使用した。この問題は、複数個のキャラクタセットを有する言語において悪化される場合がある。日本の会社は、その名前の１つのバージョンをカタカナで有しており、且つ別のバージョンをひらがなで有している場合がある。

これらの理由及びそれ以上の理由のために、名前及び記述オブジェクトの両方は、単一オブジェクトに対して複数回発生する場合がある。各インスタンスは言語コードでタグが付けられる。ＵＤＤＩバージョン３において、同一の言語コードで複数のインスタンスが存在する場合がある（このことはバージョン２においては許可されていない）。

発見修飾詞は更なる混乱を付加する。前述したように、ＵＤＤＩサーチは、大文字小文字を区別するサーチと大文字小文字を区別しないサーチの両方をサポートすることが必要とされ、且つこのことは、Ｘ．５００ディレクトリ内にデータを二度格納することにより最も良く取り扱われる。

以下の例は、ビジネスエンティティの名前の集まりに対して使用されるアブストラクトクラス及び派生されるクラスのうちの１つｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅを示している。

注意すべきことであるが、ｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅＶａｌｕｅは、名前の大文字小文字区別性バージョンを包含する属性であり、一方ｅｕＢｕｓｉｎｅｓｓＥｎｔｉｔｙＮａｍｅＶａｌｕｅＩＣは、「大文字小文字無視（ｉｇｎｏｒｅ ｃａｒｅ）」としてマーク付けされたバージョンであり、従って、大文字小文字非区別性である。アブストラクトクラスから継承されたｅｕＮａｍｅＫｅｙフィールドは、名前の順番付けを制御するために使用され、且つ一意的なネーミング属性を与える。

名前オブジェクトの１例は以下のような場合がある。

再度、図１５は、ビジネスエンティティにおける比較的複雑なオブジェクトの表現に対する本開示の１実施例に基づく階層のサブストラクチャ内への導入の１例を例示するものであるが、それは、同様に、アブストラクトクラスにおける比較的複雑なオブジェクトの表現に対する本開示の１実施例に基づく階層のサブストラクチャ内への導入の１例の例示である。図１５のビジネスエンティティ１５１は、同様に、アブストラクトに適用可能であり、バインディングテンプレートの多値型要素はアブストラクトクラス１５１の子１５２，１５３として表わされる。子は全く存在しないか又はそれ以上存在する場合がある。

別の問題は、ユーザが、彼／彼女の制御下にあるビジネスエンティティのみを変更することが許可されるという条件の効率的な実現例を作成することに関するものである。本開示の１実施例によれば、このことは、ビジネスエンティティをユーザオブジェクトのユーザの子により制御されるようにすることにより達成することが可能である。このことは、セキュリティをより容易に実現させる。

パブリッシングユーザのみが彼／彼女自身が所有する情報を変更することが許容されることを確保することが重要な場合がある。種々のデザインでこのことを行うことが可能である。然しながら、最適なデザインは、ユーザが項目をパブリッシュすることが承認されているか否かをすぐ様明らかにし、与えられたユーザにより制御されるデータの全てがそのユーザのサブツリー内に位置される。

このデザイン決定は、全体としてビジネスエンティティへのアクセスの容易性に影響を与えるものではない。何故ならば、ビジネスエンティティ内への全ての問い合わせは、一般性又は性能を失うことなしに、階層内のユーザレベルの上から行うことが可能だからである。

別の問題は、パブリッシャアサーションの効率的な実現例を作成することに関するものであり、特にｆｉｎｄＲｅｌａｔｅｄＢｕｓｉｎｅｓｓ方法のインプリメンテーションに関するものである。本開示の１実施例によれば、このことは、パブリッシャアサーションをビジネスオブジェクトのビジネス子に関連させることにより達成することが可能である。このことはその基準をサーチする必要性を取除く。

パブリッシャアサーションの１つの主要な使用は、ｆｉｎｄ ＲｅｌａｔｅｄＢｕｓｉｎｉｓｓｅｓ問い合わせ内に存在している。この問い合わせは、特定のビジネスエンティティを特定し、且つ完成したパブリッシャアサーションによりそのエンティティに関連する全てのビジネスエンティティに関する情報を要求する。この問い合わせは、そのパブリッシャアサーションをそれが関連するビジネスエンティティの下に配置させる階層により簡単化され且つ加速される。これは一貫性を増加させるという付加した利点を有している。ビジネスエンティティが削除されると、全ての関連するパブリッシャアサーション（今や無関係）がそれと共に削除される。

別の問題は、ユーザが彼／彼女の制御下にあるＴＭｏｄｅｌのみを変更することが許容されるという条件の効率的なインプリメンテーション即ち実現例を作成することに関するものである。本開示の１実施例によれば、本システムは、ユーザにより定義されるＴＭｏｄｅｌをユーザオブジェクトの子とさせる。このことは、セキュリティを実現することを容易とさせる。

ビジネスエンティティをユーザエントリの下側に配置させる場合に支配したものと同様の理由により、ユーザが定義したＴＭｏｄｅｌをそれらを定義するユーザのユーザエントリの下側に配置させることが賢明である。ＴＭｏｄｅｌを探し出すことに関する悪影響は存在しない。何故ならば、それらは単一のインデックスされたアクセスを介して探し出すことが可能であり、全てのＴＭｏｄｅｌが一意的に名前が付けられているからである。

別の問題は、リレーションシップ即ち関係によりパブリッシャアサーションの効率的なサーチを実現することに関するものである。本開示の１実施例によれば、このことは、該リレーションシップをパブリッシャアサーションエントリの補助的クラスにキー型参照とさせることにより達成することが可能である。キー型参照が子（一つのインプリメンテーション）である場合には、それは等しい効率でサーチすることは不可能であり、該リレーションシップに対するサーチはステータスに関する（重要な）フィルタ（完成したアサーションのみを考慮）等のパブリッシャアサーションのコンテントに関するサーチと結合することは不可能である。

Ｘ．５００スキーマシステムは、データ要素として他のオブジェクトクラスを包含するオブジェクトクラスの構成をサポートするものではない。例えば、キー型参照はパブリッシャアサーションのデータ要素とすることは不可能である。キー型参照をパブリッシャアサーションの子とすることは可能であるが、このことはキー型参照のコンテントを参照する効率的なサーチの構成を容易とするものではない。

キー型参照をパブリッシャアサーションエントリに対する補助的クラスとすることはこの問題に対する効率的な解決である。従って、あたかもそれがアサーションの一部であるからのようにキー型参照のコンテントに関してサーチを行うことが可能である。

上述したようにパブリッシャアサーションの１例は以下のような場合がある。

補助的オブジェクトクラスはｅｕＰｕｂｌｉｓｈｅｒＡｓｓｅｒｔｉｏｎＫｅｙＲｅｆｅｒｅｎｃｅであり、且つ上にリストした最後の３つの属性はそのクラスのデータ要素である。

本開示の１実施例によれば、コンピュータアソシエイツによるｅＴｒｕｓｔ（商標）ディレクトリのようなディレクトリは、理想的なエンタプライズＵＤＤＩレジストリプラットフォームを実現するために使用することが可能である。ｅＴｒｕｓｔディレクトリはＬＤＡＰｖ３に完全に準拠したＸ．５００電子的ディレクトリであり、それはＵＤＤＩウエブサービスインプリメンテーションを支持するために使用することが可能である。この「ｅＴｒｕｓｔ」ディレクトリは、大型のビジネスで重要なディレクトリサービスアプリケーションにおいて良く立証されている高度に成熟したディレクトリソリューションを利用することを可能とする。

その上にＵＤＤＩレジストリを構築するプラットフォームとして極めて魅力的なものとさせる「ｅＴｒｕｓｔ」ディレクトリの多数の独特の特徴が存在している。これらのうちの幾つかは、アクセス制御ポリシー、ロール（ｒｏｌｅｓ）、セキュアプロキシー（ｓｅｃｕｒｅ ｐｒｏｘｙ）、相互認証、分散型認証、分散型ＳＳＬ証明サブジェクト検証（ｓｕｂｊｅｃｔ ｖｅｒｉｆｉｃａｔｉｏｎ）及びネットワークアドレス妥当性検査を包含するセキュリティ特徴；並列分散型サーチ、負荷シェアリング、クエリーストリーミング及び最短経路ルーチングを包含するディストリビューション及びルーチング能力；リプレイを基礎にしたメカニズム（マルチ書込として知られている）の速度及び効率を状態を基礎としたリカバリー及び調停技術と結合するマルチマスターレプリケーションスキーム；データベースのホットスワップ、ネットワークフェイルオーバー及びディレクトリシステムエージョント（ＤＳＡ）フェイルオーバーを包含するアベイラビリティ特徴；高速であると考えられるキャッシングデザイン；及び動的コンフィギュレーション（データタイプ、スキーマルール、セキュリティ、知識等の）、非制限型データ寸法、一般情報完全性規則、広範な管理制御及び対話型コマンドコンソールを包含するデプロイメント特徴、を包含している。

ｅＴｒｕｓｔディレクトリは証明されたＸ．５００ディレクトリソリューションを提供する。この証明された基礎の上に、完全にスタンダード準拠のＵＤＤＩレジストリを可能とさせるためにＵＤＤＩ意味論的ブリッジを実現することが可能である。基礎となるディレクトリソリューションの能力のために、本明細書に開示した実施例は、既存のＵＤＤＩスタンダードに対する変化又は拡張を必要とすることなしに、柔軟性のあるセキュリティ、ディストリビューション、管理性を供給することが可能である。

本実施例の一つの問題は、ディレクトリの本質的に異なるセクション内に格納されているエンティティ間のリレーションシップ即ち関係をどのようにしてマップするかを取り扱うことである。

ＵＤＤＩデータ構造は主に階層的であるが、異なるオブジェクト間の相互関係とに問題がある場合がある。

基本的に２つのカテゴリの関係、即ち代替名及び相互関係が存在している。本開示の１実施例によれば、この問題は、代替名に対処するためにエイリアスの概念を使用することによって解決される。基本的には、このことは、異質の（ｆｏｒｅｉｇｎ）エンティティを主要のエンティティの仮想的な子として「取り付ける」効果を有している。

本実施例は、相互関係の問題に対処するために一意的なキーを使用する。基本的に、このことは、階層的ディレクトリシステム内のディスジョイント（ｄｉｓｊｏｉｎｔ）サブツリー間に存在するデータエンティティ間の関係をモデルするためにＲＤＤＭＳ技術におけるプライマリー／フォーリン（Ｐｒｉｍａｒｙ／Ｆｏｒｅｉｇｎ）キーシステムのような「リレーションシップポインター（ｒｅｌａｔｉｏｎｓｈｉｐ ｐｏｉｎｔｅｒ）」を形成する効果を有している。

本開示の１実施例に基づくエイリアスの使用について説明する。第一のシナリオは、ＵＤＤＩビジネスサービスプロジェクションのインプリメンテーションにより最も明確に示される。ビジネスサービスプロジェクションは、実効的に、ビジネスサービスに対する代替名である。ビジネスサービスプロジェクションはビジネスＡに属するように見えるビジネスサービスであるが、それは、実際には、ビジネスＢにより所有され且つ定義されるものである。

図５を参照すると、ビジネスサービス５１、即ちビジネスＡにより所有されているサービスもビジネスＢに属するように見える。ビジネスＡによってビジネスサービス５１に対して為される変化はビジネスＢの下に表われる投影されたサービスにおいて反映される。同様に、ビジネスサービス５１がレジストリから削除されると、それは、最早、ビジネスＡ又はビジネスＢのいずれの下にも表われることはない。更に、ビジネスエンティティＢはビジネスサービス５１を編集又は変化させるものではない。編集及びその他の全てのパブリッシング目的のために、ビジネスＡのみがビジネスサービス５１へのアクセスを有している。

ディレクトリエイリアスシステムはこの効果を達成するために使用することが可能である。ビジネスサービス５１のエイリアスがビジネスエンティティＢへ付加される。このエイリアスはディレクトリサーバー用の特別のマーカーであり、それは、実効的に、誰かがこのエイリアスを見る場合に、彼らにこの他のエントリをここに示す、ということを言うものである。

それは、オリジナルのサービスが編集する場合に、その変化がプロジェクションにおいても見えるものであることを意味する。ディレクトリシステムがエイリアスのインテグリティをサポートする場合であって、それはｅＴｒｕｓｔディレクトリの場合に言えることであるが、そのサービスが削除されると、そのプロジェクションも自動的に除去される。

更に、ディレクトリサーバーは、サーチされる場合にその投影されたビジネスサービスを二度、即ち各親の下で一度づつ、示すための構成とすることが可能である。このことは、ビジネスサービス親を解決することが必要なサーチを行う場合に有用である場合がある。

幾つかの状態は、ディレクトリ階層のディスジョイント部分におけるオブジェクトがリレーションシップを維持することを必要とする。

このことの１つの例はバインディングテンプレートとＴＭｏｄｅｌとの間である。ＴＭｏｄｅｌは種々の目的のためにＵＤＤＩを介して使用される。それらはカテゴリ化キー、サーチ識別子、（ＵＤＤＩ）リレーションシップ記述、及び、このインスタンスにおいては、技術的仕様「フィンガープリント」である。バインディングテンプレートに「取り付け」られているＴＭｏｄｅｌは、それに対してバインディングテンプレート（図８参照）が適合する技術的仕様を記述する。例えば、パブリッシャは、彼等のバインディングテンプレートがＳＯＡＰ１．１スタンダードに準拠することを主張するＴＭｏｄｅｌを取り付ける場合がある。

レジストリは、典型的に、有限組のＴＭｏｄｅｌを包含しており、その多くは数百又は数千のバインディングテンプレートエントリにより参照される。幾つかの場合において、そのレジストリはバインディングテンプレートの詳細と共に「取付け」られているＴＭｏｄｅｌの詳細にリターンする。

本開示の１実施例によれば、リレーショナルデータベースシステムにおいて使用されているようなプライマリー／フォーリンキーシステムを適宜修正し且つ適用することが可能である。レジストリ内に格納されている全てのＴＭｏｄｅｌはそれ自身の一意的な（プライマリー）キーを有している。バインディングテンプレートは、所要のＴＭｏｄｅｌの一意的なキーとマッチするローカルのフォーリン）を付加することによりＴＭｏｄｅｌを参照する。図７はこのことの１つの例を例示している。次いで、サーバーは、ＴＭｏｄｅｌデータがバインディングテンプレートと共にリターンさせることが必要であるかの質問においてＴＭｏｄｅｌをルックアップすることが可能である。

図６はバインディングテンプレートとＴＭｏｄｅｌとの間のリレーションシップ即ち関係を示している。

図７はどのようにしてＴＭｏｄｅｌキーが２つのエンティティの間のリレーションシップを作成するかを示している。

パブリッシャアサーションはＵＤＤＩリポジトリの重要な要素である。上述したように、それはユーザに、どのビジネスエンティティが興味のあるビジネスエンティティへ関連しているか、且つそれらがどのようにして関連しているかを発見するための能力を提供する。

パブリッシャアサーションは、関与する両方のビジネスエンティティの所有者がそのリレーションシップをアサートした場合にアサートされた関係のみが見えるようになることにより乱用に対して保護すべく設計されていた。この保護はコストを伴うものであり、即ちそれはインプリメンテーションを複雑化し、且つ拙い性能を回避するために注意深い設計を必要とする。

１つの問題はインテグリティである。パブリッシャアサーションは、その他のどのＵＤＤＩ構造物（ｃｏｎｓｔｒｕｃｔ）よりも一層複雑なライフサイクルを有している。それは、ビジネスエンティティの所有者がそのビジネス及び別のビジネスエンティティとのその関係に関してアサーションを行う場合に発生する。他のビジネスエンティティの所有者はステータスレポートを要求し且つ彼等のビジネスについてどのようなアサーションが為されたかを発見することが可能であり、又はかれらは帯域外で通知される場合がある。いずれの場合にも、他方のビジネスエンティティの所有者は、２つのビジネスエンティティの間のリレーションシップに関しマッチするアサーションを行うべく選択することが可能である。その時に、アサーションは完了し且つｆｉｎｄＲｅｌａｔｅｄＢｕｓｉｎｅｓｓｅｓをコールするユーザに対してビジブルである。１つ又は両方のアサーションを修正するか又は削除することが可能であり、且つアサーションは再度不完全となり、且つ最早ビジブルではない。更に、いずれかのビジネスエンティティの削除はアサーションをすぐさま除去すべきである。

パブリッシャアサーションオブジェクトは、アサーションのインテグリティを維持するような態様で管理することが可能である。

ビジネスエンティティの所有者がその所有者により制御されるビジネスエンティティに関してアサーションを行う（及び除去する）ことが可能であることが望ましい。

本開示のこの実施例は、Ｘ．５００ディレクトリに対して意図されていることであるが、ＵＤＤＩリポジトリが「リードモストリィ（ｒｅａｄ−ｍｏｓｔｌｙ）」ストアであるという仮定に基礎を置いている。この目的のために、デザインは、書込に関してより重い負担を課すことの犠牲においても、より良い読取性能に対して最適化されている。

パブリッシャアサーションと呼ばれるオブジェクトクラスは、サーチ性能を最適化することが望ましいために、ＵＤＤＩスタンダードにより必要とされるものを超えてデータを保持するべくデザインされている。そのデザインは、パブリッシャアサーションステータスを定義するオペレーショナル属性を導入する。アサーションのステータスは、ディレクトリへの書込時に決定され、且つそのようにして、サーチが実施される度に決定されることは必要ではない。

本実施例は、又、ユーザキーの形態におけるポインターを使用する。パブリッシャアサーションがディレクトリへ書き込まれると、ビジネス「へ」及び「から」に対するユーザキーが決定され且つオブジェクト内に書き込まれる。このことはｇｅｔＡｓｓｅｒｔｉｏｎＳｔａｔｕｓＲｅｐｏｒｔクエリーを簡単化させる。何故ならば、このようなレポートを発生するのに必要なことは、そのレポートを発生する人のユーザキーを包含するパブリッシャアサーションに対してサーチすることに過ぎないからである。

対照的に、そのユーザの下にある全てのビジネスキーをクエリーし、次いでこれらのビジネスキーを包含するパブリッシャアサーションを探すことが必要であった場合には、レポートを発生するのにかなりの努力が必要となる。

パブリッシャアサーションの１つの一般的な使用は、与えられたビジネスに「関連する」ビジネスの発見である。そのクエリーに対して良好な性能を与えるために、ビジネスに関連するパブリッシャアサーションはそのビジネスの子ノードとして配置される。

更に、各アサーションのステータスはオペレーショナル属性としてそのアサーション内に記録される。このことは、興味のある下側に配置させた完了のステータスを有するパブリッシャアサーションをクエリーすることを可能とする。このことは、ｆｉｎｄＲｅｌａｔｅｄＢｕｓｉｎｅｓｓｅｓをサーチすることを簡単化する。何故ならば、そのサーチは完全であるアサーションのみをリコールするからである。

セキュリティを簡単化するために、ユーザ及びそれらのパブリッシャアサーションにより制御される全てのビジネスはそのユーザのアカウントエントリの下の子ノードとする場合がある。このインプリメンテーション即ち実現は、そのユーザのアカウントエントリの下にあるサブツリーに対してユーザアクセスを可能とするのみによりアクセス制御を実施する。

注意すべきことであるが、そのステータスを表現するオペレーショナル属性は、ＵＤＤＩインプリメンテーションにより管理される。ユーザが別のアサートされたビジネスにより既にアサートされているアサーションをパブリッシュする場合には、ＵＤＤＩインプリメンテーションは他のビジネスのユーザにより制御される別のサブツリー内にある他のアサーションのステータスをアップデートする。アクセス制御がこのことを可能とする。

関与する２つのビジネスエンティティの各々の下に１つづつ２つのパブリッシャアサーションオブジェクトを格納することの代替的１実施例として、単一のパブリッシャアサーションオブジェクトがそれ自身のサブツリー内に設けられる。例えば、パブリッシャアサーションサブツリーはリポジトリオブジェクトの下に設けることが可能である。アサーションが初期的にこの場合に格納される場合には、それは不完全なステータスが与えられる（例えば、どちら側がアサートするかに依存して、ｔｏｋｅｙｉｎｃｏｍｐｌｅｔｅ又はｆｒｏｍｋｅｙｉｎｃｏｍｐｌｅｔｅ）。パブリッシャアサーションが相補的なアサーションによりアサートされると、そのステータスは完全へ変化される。パブリッシャアサーションが二者のうちの一方に削除されると、そのステータスは不完全へ戻される。パブリッシャアサーションが両者により削除されると、パブリッシャアサーションオブジェクトが削除される。効果的に、このことはアサーションの単に１つのコピーとなり、メインテナンス作業の殆どはそのアサーションのステータスを保持する単一の属性の修正を行うことのみからなる。

図１２は本開示の１実施例に基づく階層を概略的に例示している。この概略図は、パブリッシャアサーションオブジェクトがビジネスエンティティ及び／又はリポジトリオブジェクトの下に配置される場合の両方の代替例を例示している。

図８はパブリッシャアサーションを付加することを要求する方法を例示している。ステップＳ８０において、その要求が有効であるか否かを判別する。有効でない場合には（Ｎｏ、ステップＳ８０）、その要求は失敗する（ステップＳ９２）。その要求が有効である場合には（Ｙｅｓ、ステップＳ８０）、その要求がビジネスアワーズ（ｂｕｓｉｎｅｓｓ ｏｕｒｓ）からのものであるか否かを判別する（ステップＳ８２）。それがビジネスアワーズからのものでない場合には（Ｎｏ、ステップＳ８２）、それがビジネスアワーズへのものであるか否かを判別する（ステップＳ８４）。ビジネスアワーズへのものでない場合には（Ｎｏ、ステップＳ８４）、その要求は失敗する（ステップＳ９２）。それがビジネスアワーズへのものである場合には（Ｙｅｓ、ステップＳ８４）、そのアサーションが所有者からによって為されたか否かを判別する（ステップＳ８６）。そのアサーションが所有者からによって為されたものでない場合には（Ｎｏ、ステップＳ８６）、不完全なアサーションが書き込まれる（ステップＳ９４）。そのアサーションが所有者からによって為された場合には（Ｙｅｓ、ステップＳ８６）、完全なアサーションが書き込まれる（ステップＳ９６）。ステップＳ８２へ戻り、その要求がビジネスアワーズからのものであると判別される場合には（Ｙｅｓ、ステップＳ８２）、それがビジネスアワーズへのものであるか否かが判別される（ステップＳ８８）。ビジネスアワーズへのものでない場合には（Ｎｏ、ステップＳ８８）、そのアサーションが所有者に対してによって為されたものであるかの判別が行われる（ステップＳ９０）。そのアサーションが所有者に対してによって為されたものでない場合には（Ｎｏ、ステップＳ９０）、不完全なアサーションが書き込まれる（ステップＳ９４）。ステップＳ８８の結果がＹｅｓである場合には（ビジネスアワーズに対して）、又はステップＳ９０の結果がＹｅｓである場合には（所有者に対してによって為されたアサーション）、完全なアサーションが書き込まれる（ステップＳ９６）。

次の問題は、ディレクトリ格納媒体の制限を考慮に入れながらディレクトリアクセス及び反復的インメモリ動作の両方を最適化するようにサーチ動作期間中に中間的サーチ結果収集物の構成をどのようにして最適化するかを取り扱うことである。実際上、ディレクトリエントリは任意の順番でストアし且つリターンすることが可能であり、且つディレクトリ結果はソートするのに大き過ぎる場合がある。

本開示の１実施例によれば、識別名（Ｄｉｓｔｉｎｇｕｉｓｈｅｄ Ｎａｍｅ）により中間結果をソートする独特の結果ソーティングスキームと結合されたオブジェクト指向型インメモリデータ格納システムが提供される。これは、１つのサーチが多数の異なるタイプのオブジェクト、ＢｕｓｉｎｅｓｓＥｎｔｉｔｉｅｓ、ＢｕｓｉｎｅｓｓＳｅｒｖｉｃｅｓ等をリターンすることを可能とし、尚且つデータをユーザへリターンするための正しいＸＭＬ構造を容易にシステムが構成することを可能とする。注意すべきことであるが、ウエブサービスインタラクション即ち相互作用はＸＭＬにおけるものである。

このようなシステムの記述について説明する。ＵＤＤＩのＢｕｓｉｎｅｓｓＥｎｔｉｔｙ及び本開示における全ての子データ要素は以下の階層に基づくディレクトリにおいて（部分的に）表現される。

注意すべきことであるが、ＳｅｒｖｉｃｅＮａｍｅ、ＢｕｓｉｎｅｓｓＮａｍｅ、ＢｕｓｉｎｅｓｓＤｅｓｃｒｉｐｔｉｏｎは、サブストラクチャ（Ｓｕｂｓｔｒｕｃｔｕｒｅ）及びオブジェクトスプリッティング（Ｏｂｊｅｃｔ Ｓｐｌｉｔｔｉｎｇ）を取り扱う本開示の側面に関連して説明した。

ＢｕｓｉｎｅｓｓＥｎｔｉｔｙ検索コードは、所要のＢｕｓｉｎｅｓｓ Ｅｎｔｉｔｙ又はビジネスエンティティの一意的なキーに基づいてディレクトリサブツリーサーチを実施する。このサーチは見つかったエントリ及び全てのサブエントリをリターンする。ディレクトリスタンダードはリターンされたエントリに対して何等特定の順番を保証するものではなく、又サブエントリがそれらの親エントリのすぐ後に続くことでさえもそうである。

従って、検索コードは識別名によってリターンされたエントリをソートする。このことは、サブエントリがそれらの親の後の順番とされること、及び親‐子の関係を容易に区別することが可能であることを保証する。多様なソーティングアルゴリズムを使用することが可能である。使用されるソーティングアルゴリズムは、エントリが部分的にソートされる場合においては高性能の特性を示すべきである。

結果構造に対するアルゴリズムは、基本的に、「最初に深さ左から右のツリーウォーク（ｄｅｐｔｈ−ｆｉｒｓｔ，ｌｅｆｔ−ｔｏ−ｒｉｇｈｔ ｔｒｅｅ−ｗａｌｋ）」で動作する。それは、グラフ理論において「帰りがけ順（ｐｏｓｔｏｒｄｅｒ ｔｒａｖｅｒｓａｌ）」として知られている。

ソートしたリストが新たなＢｕｓｉｎｅｓｓＥｎｔｉｔｙオブジェクトのコンストラクター（ｃｏｎｓｔｒｕｃｔｏｒ）方法へパスされる。このオブジェクトは、例えば、ＵＤＤＩビジネスエンティティを表現すべくデザインされたオブジェクト指向型プログラミングコンストラクト（ｃｏｎｓｔｒｕｃｔ）である場合がある。ＢｕｓｉｎｅｓｓＥｎｔｉｔｙオブジェクトは最後にエントリ内に与えられたデータから「それ自身構築する」ためのコードを包含している。このコードは、リストを介して反復的に移動し、各エントリに関しての決定を行う。そのリストにおける最初のエントリはビジネスエンティティ自身に対する主要なエントリであることが理解され、且つそれが別のＢｕｓｉｎｅｓｓＥｎｔｉｔｙを見つけ出すや否や、構築が終了したことを理解し、そのリストの順番がこのことを保証する。それがＢｕｓｉｎｅｓｓＳｅｒｖｉｃｅ又はその他の子エントリを見つけるや否や、適宜のタイプのオブジェクトがインスタンス化され且つ該リストは、そのリストのどこから開始するかを告げるポインターと共に、新たなオブジェクトのコンストラクターへパスされる。

各オブジェクトは、基本的に、それ自身の構築を取り扱い且つ全ての子エントリの構築を適宜の子オブジェクトへ委任するための同様の処理コードを包含している。

このようにして、単一のディレクトリサーチを実施することが必要であるに過ぎず、結果的に得られるリストは効率的な態様で処理され、全てのエントリは一度処理される。そのリストが任意の順番とされるか、又は何等かのその他の態様でソートされた場合には、そのリストは結果的に得られるエントリからＵＤＤＩ階層を正しく構築するために複数回のパスで処理されねばならない。

構築及びリスト処理の階層内の異なるプログラミングオブジェクトへの委任は、処理コードを比較的小さな寸法とさせ、より効率的で且つ究極的により速いものとさせる。

図９はソートしたエントリリストの表現を包含するプログラミングコンストラクト（オブジェクト）を例示している。項目のリスト内に更なる項目が存在するか否かが判別される。付加的な項目が存在しない場合には（Ｎｏ、ステップＳ１００）、その処理は終了する（ステップＳ１１８）。付加的な項目が存在する場合には（Ｙｅｓ、ステップＳ１００）、そのリストにおける次の項目が検索される（ステップＳ１０２）。次いで、その項目がこのオブジェクトタイプのものであるか否かの判別が為される。その項目がこのオブジェクトタイプのものである場合には（Ｙｅｓ、ステップＳ１０４）、その項目に基づいてオブジェクト属性が設定され（ステップＳ１０６）且つ本プロセスはステップＳ１００へリターンする。このオブジェクトタイプのものでない場合には（Ｎｏ、ステップＳ１０４）、このオブジェクトタイプの項目が未だに処理されていないかどうかの判別が為される（ステップＳ１０８）。このオブジェクトタイプの項目が未だに処理されていない場合には（Ｎｏ、ステップＳ１０８）、本プロセスはステップＳ１００へリターンする。このオブジェクトタイプの項目が処理されている場合には（Ｙｅｓ、ステップＳ１０８）、その項目がこのオブジェクトの内在的なコンポーネントであるか否かの判別が為される（例えば、Ｎａｍｅ、Ｄｅｓｃｒｉｐｔｉｏｎ等）。内在的コンポーネントである場合には（Ｙｅｓ、ステップＳ１１０）、その項目はオブジェクト属性へ付加され且つエキストラな処理が実施される場合があり（ステップＳ１１２）、且つ本プロセスはステップＳ１００へリターンする。内在的コンポーネントでない場合には（Ｎｏ、ステップＳ１１０）、その項目がこのオブジェクトの子オブジェクトであるか否かの判別が為される（例えば、これがＢｕｓｉｎｅｓｓＥｎｔｉｔｙである場合にはＢｕｓｉｎｅｓｓＳｅｒｖｉｃｅ）。それが子オブジェクトである場合には（Ｙｅｓ、ステップＳ１１４）、本システムは正しいタイプのオブジェクトをインスタンス化し、且つ項目のリストをコンストラクターへパスし（ステップＳ１１６）且つ本プロセスはステップＳ１００へリターンする。子オブジェクトでない場合には（Ｎｏ、ステップＳ１１４）、本プロセスはステップＳ１１０へリターンする。

次の「実世界」例は、ＬＤＡＰディレクトリがリターンすることが予測されることのある任意の順番の種類を示している。

リスト１−太字でハイライトさせたＮａｍｅエントリはそのリストの上部にあるＢｕｓｉｎｅｓｓＥｎｔｉｔｙエントリのリーフ即ち葉であり、且つそれがＢｕｓｉｎｅｓｓＳｅｒｖｉｃｅエントリ及び該ＢｕｓｉｎｅｓｓＥｎｔｉｔｙのその他の分岐子の前に表われることが有用である。然しながら、それはリストの終わりに表われており、そのことはＢｕｓｉｎｅｓｓＥｎｔｉｔｙの全ての直接的な子が処理されていることを確保するためにリスト全体を処理コードがサーチすることを強制する。このことは最も効率的なものでない場合がある。

従って、本開示の１実施例に基づいて形成された規則に従ってソートされた同一のデータのバージョンは以下のものである。

リスト２−太字でハイライトしたエントリはリスト内のより論理的な位置に表われ、且つ処理コードはこのことを利用するために書くことが可能である。エントリの数が現実的なサーバーの負荷に増加されると、処理時間に関する節約はかなりのものとなる場合がある。

次のものは本開示の別の実施例である。

本開示は、この開示の基本的な特性の精神から逸脱することなしに幾つかの形態で実現することが可能であるので、上述した実施例はそうでないことが特記されていない限り本開示を制限するものではなく、特許請求の範囲に定義されるように本開示の精神及び範囲内で広義に構成することが可能であることを理解すべきである。種々の修正例及び均等な構成は本開示及び特許請求の範囲内に包含されることが意図されている。

幾つかのウエブサービス及びＵＤＤＩ概念を概略的に例示した概略図。 ウエブサービス環境に対する簡単化したプロトコルスタックを概略的に例示した概略図。 関連技術に基づく階層を概略的に例示した概略図。 関連技術に基づくディレクトリサービスモデルを概略的に例示した概略図。 本開示の１実施例に基づいてＸ．５００ディレクトリ技術を使用して実現したＵＤＤＩサービスモデルに対するインフラストラクチャコンポーネントを概略的に例示した概略図。 本開示の１実施例に基づくサービスプロジェクションを概略的に例示した概略図。 本開示の１実施例に基づくバインディングテンプレートとＴＭｏｄｅｌとの間のリレーションシップを概略的に例示した概略図。 本開示の１実施例に基づいてどのようにしてＴＭｏｄｅｌが２つのエンティティの間のリレーションシップを作成するかを概略的に例示した概略図。 本開示の１実施例に基づいてパブリッシャアサーションを付加する要求の論理的表現を例示した概略図。 本開示の１実施例に基づいてＵＤＤＩデータオブジェクトに対するコンストラクターの論理的表現を例示した概略図。 ユーザオブジェクトの下にビジネスエンティティオブジェクトを配置させることを概略的に例示した概略図。 ユーザオブジェクトの上にドメインオブジェクトを配置させることを概略的に例示した概略図。 本開示の１実施例に基づくスキーマのアウトラインを概略的に例示した概略図。 関連技術に基づくビジネスエンティティにおいて比較的複雑なオブジェクトのＵＤＤＩ概念を概略的に例示した概略図。 ビジネスエンティティにおける比較的複雑なオブジェクトのノベル表現を概略的に例示した概略図。 ビジネスエンティティにおける比較的複雑なオブジェクトの表現に対する本開示の１実施例に基づく階層の導入を概略的に例示した概略図。 本開示の１実施例に基づくバインディングテンプレート階層サブストラクチャを概略的に例示した概略図。 バイディングテンプレートサブストラクチャをフラットニング及び／又はマージした状態を概略的に例示した概略図。 本開示の種々の側面を実現することが可能なコンピュータシステムのブロック図。

Claims (12)

1. ウエブサービスシステムにおいて使用する方法において、
   データリポジトリへのアクセスを与え、
   前記データリポジトリのサーチを行う場合に使用するシャドウ属性を与える、
   ことを包含している方法。
2. 請求項１において、前記シャドウ属性が大文字小文字区別性無しに値を格納する方法。
3. 請求項１において、更に、マッチング規則に従って前記シャドウ属性をサーチすることを包含している方法。
4. 請求項１において、前記リポジトリのオペレーターを表わす属性が属性として格納されることがない方法。
5. 請求項１において、更に、予め計算したオペレーションに基づいてオペレーショナル属性を格納することを包含している方法。
6. 請求項５において、前記オペレーショナル属性が削除したユーザ及びサービスプロジェクションステータスのうちの少なくとも１つと関連している方法。
7. ウエブサービスシステムにおいて使用する方法を実施するためのコンピュータにより実行可能なコードを包含しているコンピュータ記録媒体において、
   データリポジトリへのアクセスを与えるためのコード、
   前記データリポジトリのサーチを行う場合に使用するシャドウ属性を与えるためのコード、
   を有しているコンピュータ記録媒体。
8. 請求項７において、前記シャドウ属性が大文字小文字区別性無しに値を格納するコンピュータ記録媒体。
9. 請求項７において、更に、マッチング規則に従って前記シャドウ属性をサーチするためのコードを包含しているコンピュータ記録媒体。
10. 請求項７において、前記リポジトリのオペレーターを表わす属性が属性として格納されることがないコンピュータ記録媒体。
11. 請求項７において、更に、予め計算したオペレーションに基づいてオペレーショナル属性を格納するためのコードを有しているコンピュータ記録媒体。
12. 請求項１１において、前記オペレーショナル属性が削除したユーザ及びサービスプロジェクションステータスのうちの少なくとも１つと関連しているコンピュータ記録媒体。

Images