JP2006244488A

JP2006244488A - 異なるアプリケーションフレームワーク間のデータサービスのためのプラットフォーム

Info

Publication number: JP2006244488A
Application number: JP2006047523A
Authority: JP
Inventors: Anil K Nori; ケー．ノリアニル; T Whitten Arthur; ティー．ホイッテンアーサー; Dale Woodford; ウッドフォードデイル; A Blakeley Jose; エー．ブレークレイジョゼ; Pedro Celis; チェリーズペドロ; Praveen Seshadri; セシャドリプラビーン; Sameet H Agarwal; エイチ．アガーワルサミート; Terek Soner; テレクソナー
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-02-28
Filing date: 2006-02-23
Publication date: 2006-09-14
Also published as: AU2006200230A1; TW200632699A; EP1696352A2; RU2425417C2; NO20060072L; SG125173A1; MY149824A; CN1828527A; MXPA06001208A; NZ544991A; TWI405091B; AU2006200230B2; ZA200600754B; US20060195476A1; KR101224670B1; EG25837A; BRPI0600191A; US7853961B2; KR20060095447A; CO5790183A1

Abstract

【課題】共通のデータストアと複数の異なるアプリケーションフレームワークの複数のアプリケーションとの間でデータ管理を行う。
【解決手段】データの保存を容易にするデータストレージコンポーネントが提供される。データは構造化、半構造化、および非構造化データを含む。共通データプラットフォームがデータストレージコンポーネントへのインタフェースとなることにより、複数の異なるアプリケーションフレームワークによりアクセス可能なデータサービスを提供する。このデータサービスにより、異なるフレームワークの対応するアプリケーションがデータにアクセスすることが可能となる。
【選択図】図１

Description

本発明は、異なるアプリケーションフレームワーク間のデータサービスのためのプラットフォームに関する。

データはほとんどあらゆるアプリケーションにおける重要な資産になっている。このことは、製品を閲覧して注文を生成するために利用される基幹業務（ＬＯＢ）アプリケーションであるか、人々の間のミーティング（会議・会談・打ち合わせ）をスケジューリングするために用いられる個人情報管理（ＰＩＭ）アプリケーションであるかを問わない。アプリケーションは、アプリケーションデータに対してデータアクセス／操作およびデータ管理の両方のオペレーションを実行する。典型的なアプリケーションのオペレーションでは、データ収集に対する問合せ（クエリ）を行い、結果セットを取ってきて、データの状態を変化させる何らかのアプリケーションロジックを実行し、そして最後に、記憶媒体にデータを持続する。

従来、クライアント／サーバー型アプリケーションは、クエリおよび持続アクションを、データ層に配備されたデータベース管理システム（ＤＢＭＳ）に委ねている。データ処理を中心とするロジックがある場合、それはデータベースシステム内のストアドプロシジャ（内蔵手続）としてコーディングされる。データベースシステムはテーブルおよび行という形でデータに機能し、アプリケーションは、アプリケーション層において、プログラミング言語オブジェクト（例えばクラスや構造体）という形でデータに機能する。アプリケーション層とデータ層におけるデータ操作サービス（およびメカニズム）のミスマッチ（不整合）は、クライアント／サーバー型システムでは許容されていた。しかし、ウェブ技術（およびサービス指向アーキテクチャ）の出現と、アプリケーションサーバーが広く受け入れられてきたことに伴い、アプリケーションは多層構造化しつつあり、さらに重要なことに、データが現在ではあらゆる層に存在することである。

このような階層化アプリケーションアーキテクチャでは、データが複数の層で操作される。また、アドレス指定能力および大容量メモリにおけるハードウェアの進歩に伴い、より多くのデータがメモリに常駐するようになっている。また、アプリケーションは、例えばオブジェクト、ファイル、およびＸＭＬ（eXtensible Markup Language：拡張マークアップ言語）データのようなさまざまな種類のデータを扱うようになっている。

ハードウェアおよびソフトウェアの環境において、プログラミング環境に適切に統合された、リッチ（豊か）なデータアクセスおよび操作のサービスに対する需要が高まっている。上記の課題を解決するために導入された従来の実装の１つとしてデータプラットフォームがある。データプラットフォームは、アプリケーションプログラミング環境に適切に統合されたデータに対するアクセス、操作、および管理を行うために、アプリケーションに対してサービス（メカニズム）のコレクション（集合）を提供する。しかし、このような従来のアーキテクチャは多くの点で不十分である。このようなデータプラットフォームに対する主な要求には、複雑なオブジェクトモデリング、リッチなリレーションシップ（関連付けの指定）、論理的データ抽象化と物理的データ抽象化の分離、リッチなクエリを備えたデータモデル概念、アクティブな通知、および中間層インフラ基盤（基幹施設）とのより良い統合が含まれる。

以下に、本アーキテクチャのいくつかの態様の基本的理解を可能にするために、本発明の簡単な概要を提示する。この概要は、本発明の広範な概観ではない。この概要は、本発明の主要な要素を特定することや、本発明の範囲を画定することを意図していない。その唯一の目的は、後述するさらに詳細な説明の前置きとして、簡単な形で本発明のいくつかの概念を提示することである。

本明細書に開示され特許請求の範囲に記載される発明は、その一態様において、共通のデータストアと、複数の異なるアプリケーションフレームワークの複数のアプリケーションとの間でのデータ管理を容易にするアーキテクチャを含む。本アーキテクチャは、テーブルをオブジェクトにマッピングするために、マッピングレイヤ（マッピング層）をアプリケーションとは別個に定式化する。本アーキテクチャは、デスクトップアプリケーションと基幹業務（ＬＯＢ）アプリケーションフレームワークの間のギャップ（すき間）を橋渡しすることにより、アプリケーションが、テーブルではなくアプリケーションオブジェクトのレベルでデータを扱うことができるようにする。さらに、本アーキテクチャは、エンドユーザアプリケーションによって定義されたデータエンティティがＬＯＢアプリケーションによって使用可能となり、その逆も可能となるように、すべてのフレームワークにわたるこのデータの共有を可能にする。

本アーキテクチャは、データの保存を容易にするデータストレージコンポーネントを含む。このデータは、構造化、半構造化、および非構造化データを含む。共通データプラットフォームがデータストレージコンポーネントへのインタフェースとなることにより、複数の異なるアプリケーションフレームワークからアクセス可能なデータサービスを提供する。このデータサービスは、異なるフレームワークの対応するアプリケーションがデータにアクセスすることを可能にする。また、データプラットフォームは、公開クラス、インタフェース、および静的ヘルパ関数（static helper function）の形でアプリケーションとの通信を容易にするＡＰＩ（アプリケーションプログラムインタフェース）と、ＡＰＩへのインタフェースとなりオブジェクトリレーショナルマッピング、クエリマッピングを提供し、制約（constraint）を執行するランタイムコンポーネントと、制約の宣言的作成を容易にしてデータプラットフォームのエンティティへのアクセスを制御する制約／セキュリティエンジンとをさらに含む。

本発明の別の態様において、共通データプラットフォーム（ＣＤＰ）が、さまざまなエンドユーザ（最終使用者）のアプリケーションフレームワーク間で（例えばＰＩＭ（個人情報マネージャ））フレームワークからＬＯＢ（基幹業務）アプリケーションフレームワークまで）共通するデータサービスを提供する。アプリケーションの範囲には、エクスプローラ（ファイル管理ソフト）、メール、およびメディアアプリケーションのようなエンドユーザアプリケーション、ドキュメント管理アプリケーションやコラボレーションアプリケーションのような知識労働者向けアプリケーション、企業資源計画（統合業務ソフト）（ＥＲＰ：Enterprise Resource Planning）および顧客関係管理（ＣＲＭ：Customer Relationship Management）のごときＬＯＢアプリケーション、ウェブアプリケーションならびにシステム管理アプリケーションが含まれる。

本発明のさらに別の態様において、ＣＤＰは、構造化、半構造化、および非構造化データをモデリングし保存する能力を提供するリッチなストア、フレキシブルな編成、リッチなクエリ／検索、リッチな挙動、フレキシブルな管理、データ同期、共有、スキーマ、および多層環境におけるフレキシブルなデプロイメント（クラスファイルをＷｅｂアップリケーションサーバーに配置すること）等の利益をアプリケーションに提供する。

上記の目的および関連する目的を達成するため、本明細書において、以下の説明および添付図面を用いて本アーキテクチャのいくつかの例示的態様を説明する。しかし、これらの態様は、本アーキテクチャの原理を用いることができる種々の方法のほんの一部を示すに過ぎず、本発明は、すべてのこのような態様およびその均等物を含むことを意図している。本アーキテクチャのその他の利点および新規な特徴は、以下の本発明の詳細な説明を図面とともに考慮することで明らかとなるであろう。

以下、図面を参照して本アーキテクチャを説明する。図中、同一参照番号は一貫して同一要素を指すために用いられる。以下の説明では、説明の目的上、本発明の十分な理解を可能にするために数多くの具体的詳細が記載される。しかし、これらの具体的詳細なしで本アーキテクチャを実施し得ることは明らかであろう。他の場合には、本アーキテクチャの説明を容易にするために、周知の構造および装置（デバイス）はブロック図形式で示される。

本明細書で使用される場合、「コンポーネント」および「システム」という用語はコンピュータ関連のエンティティを指すことを意図しており、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、あるいは実行中のソフトウェアのいずれかを問わない。例えば、コンポーネントは、プロセッサ上で動作するプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであり得るが、これらに限定されない。実例として、サーバー上で動作するアプリケーションおよびそのサーバーの両方がコンポーネントであり得る。１つまたは複数のコンポーネントがプロセスおよび／または実行スレッド内に存在してもよいし、コンポーネントが１つのコンピュータに局在すること、および／または２つ以上のコンピュータに分散されることが可能である。

データプラットフォームは、アプリケーションプログラミング環境に適切に統合されたデータに対するアクセス、操作、および管理を行うために、アプリケーションに対してサービス（メカニズム）のコレクションを提供するプラットフォームである。本発明は、従来のデータプラットフォームに対する改良である。本アーキテクチャは、さまざまなアプリケーションフレームワーク（例えばＰＩＭ（個人情報管理）フレームワークおよびＬＯＢ（基幹業務）フレームワーク）間で共通するデータサービスを提供する共通データプラットフォーム（ＣＤＰ）である。アプリケーションの範囲には、エクスプローラ、メール、およびメディアアプリケーションのようなエンドユーザアプリケーション、ドキュメント管理アプリケーションやコラボレーションアプリケーションのような知識労働者向けアプリケーション、ＥＲＰ（Enterprise Resource Planning）およびＣＲＭ（Customer Relationship Management）のようなＬＯＢアプリケーション、ウェブアプリケーションならびにシステム管理アプリケーションが含まれる。

ＣＤＰは、アプリケーションに少なくとも以下の利益を提供する：
１．リッチなストア：すべての種類のデータ（構造化、半構造化、および非構造化）をモデリングし保存する能力。
ａ．リレーショナルデータモデリングおよびアクセス。
ｂ．リッチなオブジェクト抽象化およびプログラミング環境。
ｃ．ＸＭＬストレージおよびクエリによる半構造化データモデリング。
ｄ．ファイルとしての非構造化データ。
２．フレキシブルな編成：オブジェクトの任意のコレクションを、静的にテーブルとしてではなく、編成する能力。
ａ．ファイルシステム名前空間および編成のサポート。
３．リッチなクエリ／検索：すべてのデータに対してクエリを行う能力。
ａ．リッチなクエリのサポート（例えばＳＱＬ、ＯＳＱＬ（オブジェクト指向ＳＱＬ）、ＸＭＬクエリ、Ｃ＃シーケンス）。ＯＳＱＬは、ＳＱＬのスーパーセットである関数型言語である。
４．リッチな挙動：リッチなデータ挙動のサポート。これは、アプリケーション／ビジネスのプロセスロジックの置換ではない。
５．フレキシブルな管理：さまざまな粒度（グラニュラリティ）での管理（例えば、コピー、移動、およびシリアライズのようなアイテムレベルのオペレーション）。
６．データ同期：データの任意のコレクションのピアツーピアおよびマスタ−スレーブ同期。
７．共有：複数のアプリケーションおよび複数のアプリケーションフレームワークの間でデータを共有する能力。例えば、Ｏｕｔｌｏｏｋ（アウトルック；本件特許出願人の個人情報管理ソフト）とＣＲＭアプリケーションの間での連絡先（Contacts）の共有。
８．スキーマ：ユーザアプリケーションとＩＳＶ（独立系サポートベンダ）アプリケーションの相互のコラボレーションを容易にするための、リッチですぐに使えるスキーマ。
９．フレキシブルなデプロイメント：２層および３層環境にデプロイ可能。

ＣＤＰおよび関連するアーキテクチャは上記のすべての利点を可能にする。主な技術革新として、階層化アーキテクチャ、複数のアプリケーションフレームワーク間で共通のモデリング概念を取り出した共通データモデル、およびＣＤＰコンポーネント（機能的）アーキテクチャがある。

まず図面を参照すると、図１は、ＣＤＰ１０２を使用するシステム１００を示している。ＣＤＰ１０２は、データアプリケーションおよびアプリケーションフレームワーク１０４と、データストア１０６上のデータとの間でのデータ管理を提供するために使用される。データストア１０６は、例えば構造化、半構造化および非構造化データ型を保存できる。前述のように、ＣＤＰ１０２は、アプリケーションフレームワークおよびそれに関連するエンドユーザアプリケーション間で共通するデータサービスを提供する。また、ＣＤＰ１０２は、アプリケーションおよびアプリケーションフレームワーク１０４、ランタイムコンポーネント１１０、および制約／セキュリティエンジンコンポーネント１１２とのインタフェースを容易にするＡＰＩ１０８を含む。ＡＰＩ１０８は、公開クラス、インタフェース、および静的ヘルパ関数の形でＣＤＰを用いてアプリケーションに対するプログラミングインタフェースを提供する。例として、StorageContext、StorageSearcher、Entity、TableSet、Table、EntityReference、およびTableReferenceがある。理解されるように、データベースプログラミング言語統合（例えばＣ＃シーケンスオペレータ）がＡＰＩ１０８の一部であり得る。

ＣＤＰランタイムコンポーネント１１０は、公開ＡＰＩレイヤ１０８に公開される種々の機能を実装するレイヤである。これは、オブジェクトリレーショナルマッピングおよびクエリマッピングの提供やデータモデル制約の強制等によって、共通データモデルを実装する。すなわち、ＣＤＰランタイム１１０は以下のものを含む：共通データモデルコンポーネントの実装；クエリプロセッサコンポーネント；セッション・トランザクションコンポーネント；オブジェクトキャッシュ、これはセッションキャッシュおよび明示的キャッシュを含み得る；変更追跡、コンフリクト検出、およびイベンティングを含むサービスコンポーネント；カーソル・ルールコンポーネント；ビジネスロジックホスティングコンポーネント；および永続化・クエリエンジン、これは、コア永続化およびクエリサービスを提供する。永続化・クエリサービス内には、クエリ／更新マッピングを含むオブジェクトリレーショナルマッピングがある。また、ＣＤＰ１０２は、制約／セキュリティエンジン１１２も含む。制約／セキュリティエンジン１１２は、データストア１０６に対する制約およびセキュリティポリシ（例えばロールに基づくセキュリティ）の適用を図る。

図２は、より詳細なＣＤＰシステム２００を示している。ＣＤＰシステム２００はＣＤＰ１０２を含み得る。ＣＤＰ１０２は、別個のデータストア（図示せず）のストア管理コンポーネント２０２とのインタフェースとなる。別法として、ストア管理コンポーネント２０２は、ＳＱＬサーバー実装に関連し得るもののようなデータストアを含むことができる。理解されるように、データストアは、構造化、半構造化および非構造化データ型を保存することができる。

ＣＤＰの１つの目標は、さまざまなアプリケーションフレームワーク２０４（ＡＦ₁，ＡＦ₂，...，ＡＦ_Zで表す）に対するサポートを可能にすることによって、迅速なアプリケーション開発をサポートすることである。フレームワーク２０４は、例えばＬＯＢ、エンドユーザ、およびシステム管理のアプリケーションフレームワークを含み得る。アプリケーションフレームワーク２０４（それぞれＡＦ₁，ＡＦ₂，...，ＡＦ_Z）に関連するアプリケーション２０６（ＡＰＰ₁，...，ＡＰＰ_S；ＡＰＰ₁，...，ＡＰＰ_Tで表す）は、それぞれのアプリケーションフレームワーク２０４、ＣＤＰ１０２、および基礎となるストア２０２を活用することで、リッチなアプリケーションを開発できる。階層化手法の利点は以下で説明する。

ストア管理レイヤ２０２はコアデータ管理能力（例えばスケーラビリティ、容量、アベイラビリティおよびセキュリティ）のサポートを提供する。ＣＤＰレイヤ１０２は、アプリケーションフレームワーク２０４に対し、リッチなデータモデル、マッピング、クエリ、およびデータアクセスメカニズムをサポートする。ＣＤＰメカニズムは、複数のアプリケーションフレームワーク２０４がデータプラットフォーム上に構築され得るように拡張可能である。アプリケーションフレームワーク２０４は、アプリケーションドメイン（例えばエンドユーザアプリケーションおよびＬＯＢアプリケーション）に固有の付加的なモデルおよびメカニズムである。階層化アーキテクチャ手法はいくつかの利点を有する。これによれば、各レイヤを独立に、そして迅速に改良しデプロイすることが可能となる。ＣＤＰレイヤ１０２は、より軽快になり、改良の自由度がより高くなり、ストアレイヤ２０２よりも頻繁に改良可能となる。階層化手法は、ＣＤＰレイヤ１０２を企業ストラテジ（戦略情報）に連携させる。そして最後に、ストアレイヤ２０２は、ストラテジと整合性をもちながら、コアデータ（柱となるデータ）の管理能力に集中することができる。

次に図３を参照して、共通データプラットフォームを実装する方法を示す。説明を簡単にする目的上、本明細書において、例えばフローチャート形式で示される１つまたは複数の方法は一連のアクト（行為）として図示され説明されているが、理解され認識されるように、本アーキテクチャはそれらのアクトの順序に限定されない。本発明によれば、一部のアクトは、図示され本明細書に記載されるものとは異なる順序で、および／または他のアクトと並行して生起し得る。例えば、当業者には理解され認識されるように、本方法は、別法として、状態図のように、相互に関係する一連の状態またはイベント（事象）として表現してもよい。さらに、本アーキテクチャによる方法を実装するために、例示されたすべてのアクトが必須とは限らない。

３００において、構造化、半構造化および非構造化データ型をモデリングしデータストアに保存するコアデータ管理レイヤが提供される。３０２で、ＣＤＰ１１０レイヤが、コアデータ管理レイヤ上に適用されることにより、アプリケーションフレームワークに対するリッチなデータモデル、マッピング、クエリ、およびデータアクセスメカニズムをサポートするデータサービスが提供される。３０４で、１つまたは複数のアプリケーションフレームワークがＣＤＰの上にオーバーレイされる。３０６で、ＣＤＰによって提供されるデータサービスを通じてデータストアのデータにアクセスできるようになった各アプリケーションフレームワーク内に、１つまたは複数のアプリケーションが提供される。

図４は、本アーキテクチャのＣＤＰコンポーネントの概略図である。理解されるように、この概略図におけるいずれのコンポーネントおよび／またはボックスの配置も、プロセス／マシンの境界を越えた特定のデプロイメントを意味する（あるいは必然的に回避する）ものではない。ＣＤＰは、楽観的並行処理モデル（optimistic concurrency model）を利用することにより、変更を保存すべきであって他の変更が既に基礎データに対してなされている場合には、コンフリクト（衝突）検出がアプリケーション固有の方法でこれを解決する。効果的なデータプラットフォームであるために、ＣＤＰは、プログラミング言語統合、リッチなデータモデリング、永続化フレームワーク、サービス等の機能を含む。ＡＰＩ１０８は、言語統合、およびアプリケーション４００によるＣＤＰランタイム１１０経由でのストア２０２へのデータアクセスを容易にする。ドメイン不可知（domain agnostic）であるということは、ＣＤＰがデータの性質および形式ならびにそれに対して要求される意味論的制約に関して必要最小限の仮定しか置かないことを意味する。この目的のため、ＣＤＰは以下の機能（詳細は後述）を提供する。

共通データモデル（ＣＤＭ）：ＣＤＰランタイム１１０の中心にはＣＤＭ４０２がある。ＣＤＭ４０２の目的は、主としてユーザデータ（ＰＩＭ、ドキュメント等）ないしＬＯＢおよび企業データを処理するアプリケーションから、複数のアプリケーションドメインにわたり共通するモデリングコンセプト（構想、概念）を取り出すことである。リッチなオブジェクトおよびリレーションシップの抽象化を提供することに加えて、ＣＤＭ４０２は、構造化、半構造化および非構造化データのサポートを提供する。

行／エンティティデータ − ＣＤＭ４０２は、リッチなエンティティ−リレーションシップモデルをサポートすることにより、構造化データ（例えばビジネスデータ）の構造および挙動を捕捉する。ＣＤＭ４０２は、コアリレーショナルモデルのスーパーセットであり、リッチなオブジェクト抽象化およびリレーションシップモデリング（例えば、ドキュメント（Documents）と連絡先（Contacts）の間の作成者（Author）リレーションシップ；購入注文書（Purchase Orders）と注文明細行（Order Lines）の間の明細行（Lines）リレーションシップ）について拡張されている。

ファイルデータ − ＣＤＭ４０２は、非構造化（ファイル）データを保存し操作するための「ファイルストリーム」データ型をサポートする。ファイルストリームデータ型は、データをファイルとして保存でき、ファイルアクセスＡＰＩをサポートする。ファイルストリームデータ型は、ＳＱＬ（構造化照会言語）サーバーでネイティブに（そのままで）サポートされ、ＮＴＦＳファイルストリームにマッピングされ、ファイルハンドル／ストリームに基づくすべてのオペレーションをサポートする。非構造化コンテンツをＣＤＭ４０２におけるファイルストリームとしてモデリングすることに加えて、エンティティ型を用いて、有用なコンテンツを構造化プロパティ（属性）に進展させることができる。データベース型ファイルストレージシステムは、ファイルバックトアイテム（file backed item）というコンセプト（概念）を規定している。これは、非構造化コンテンツのファイルストリームとともに構造化プロパティをモデリングするエンティティである。ファイルバックトアイテムは、関連するファイルストリームに対するストリーム系オペレーションとともに、リッチなクエリを提供する。

ＸＭＬデータ − ＸＭＬ文書は、ＣＤＭ４０２において次の２つの主要な方法にモデリングできる：（１）それをＸＭＬデータ型として保存し、（２）ＸＭＬ文書を（例えばデータコントラクトと同様の）１つまたは複数のエンティティにマッピングする。ＣＤＭ４０２は、ＳＱＬサーバーでサポートされるようなＸＭＬデータ型をサポートする。ＸＭＬデータ型は、任意のエンティティプロパティの型であり得る。ＸＭＬデータ型は、型付けされていないＸＭＬ文書あるいは型付けされたＸＭＬ文書のいずれをも保存することを可能にする。ＸＭＬ文書プロパティに１つまたは複数のＸＭＬスキーマを関連づけることによって強い型付けが提供される。

ＡＰＩ１０８における、クエリを含むプログラミング言語統合：コアＣＤＰ機能コンポーネント、すなわちセッション／トランザクション４０４、クエリ４０６、永続化（persistence）４０８、カーソル４１０、サービス４１２、オブジェクトキャッシュ４１４およびビジネスロジックホスティング４１６が、ＣＤＰＡＰＩ１０８で利用可能ないくつかの「ランタイム」クラス内にカプセル化される（例えばStorageContext）。ＣＤＭ４０２で作成される型に基づいて、ＣＤＰ設計時ツールが、強く型付けされたＣＬＲ（共通言語ランタイム）クラスを生成する。ＣＤＰは、ＣＤＭ４０２によって定義される型システム上のクエリ言語を要求する。ＣＤＰは、そのクエリ言語としてＣ＃シーケンスオペレータおよびＯＰＡＴＨをサポートできる。本発明の目的上、ＣＤＰによってサポートされるクエリ言語は一般に共通クエリ言語（ＣＱＬ）と呼ばれる。ＣＱＬは、コアリレーショナル代数（例えば選択（select）、結合（join）、および射影（project）演算子）を包含するとみなされる。構文はＳＱＬと同一でなくてもよいが、ＣＱＬはＳＱＬに直接マッピングできる。ＣＱＬは、プログラマが扱うオブジェクト構造体に対するリッチなクエリを可能にする。目標は、Ｃ＃グループによって行われているシーケンスオペレータの仕事にＣＱＬを連携させることである。これらの機能は、リレーショナルデータベース管理システム（ＲＤＢＭＳ）に保存されたデータ（あるいは任意の他のＣＤＰ対応データ）に対して、強く型付けされた、オブジェクトに基づく抽象化を効果的に提供する。さらに、ＣＤＰの永続化フレームワークを用いることにより、ＰＯＣＯ（Plain Old CLR Object:平凡な旧型のＣＬＲオブジェクト）に対する持続的な永続化およびクエリができる。

永続化エンジン − 永続化エンジンは、リレーショナルストアに由来するコンポーネント断片からどのようにしてオブジェクトが組み立てられるかを厳密に記述する宣言的マッピング定義を提供する。このエンジンは、オブジェクトクエリ式を用いてクエリプロセッサによって定義される式を受け取り、それを宣言的マッピングと結合するクエリ生成コンポーネント（図示せず）を含む。これが、データベース内の基礎テーブルにアクセスする等価なクエリ式となる。更新生成コンポーネント（図示せず）が、変更追跡サービスを参照し、マッピングメタデータの助けを借りて、オブジェクトの世界での変更をどのようにしてテーブルの世界での変更に翻訳するかを記述する。

ファイルおよびＸＭＬデータのクエリ／検索 − 上記で説明したように、ＣＤＭ４０２は、それぞれファイルストリームデータ型およびＸＭＬデータ型を用いて非構造化データおよび半構造化データを保存する。ＣＱＬは、これらのデータ型に対するクエリが可能である。構造化エンティティに昇格したファイルコンテンツ（例えばＷｉｎＦＳファイルバックトアイテム）の場合、ＣＱＬのリレーショナル演算子がこれらのエンティティにクエリをすることができる。ファイルストリームとして保存された非構造化データは、全文検索を用いてクエリができる。ＸＭＬコンテンツはＸＰａｔｈまたはＸＱｕｅｒｙを用いてクエリができる。

オブジェクトリレーショナル（Ｏ−Ｒ）マッピング：ＣＤＰは、リレーショナル（表形式）ストレージの上にオブジェクトに基づく抽象化を提供するので、Ｏ−Ｒマッピングコンポーネントを提供することを必要とする。ＣＤＰは、規範的マッピング（マッピングがどのように起こるかをＣＤＰが決定する）および非規範的マッピング（型設計者がマッピングを指定する何らかの自由度を有する）の両方をサポートする。なお、データベース型ファイルストレージシステム実装は現在、規範的マッピングを使用しているが、より一般的なＯ−Ｒ永続化フレームワークは非規範的マッピングを必要とすることに留意されたい。

キャッシング：ＣＤＰランタイムは、クエリ結果（例えばカーソル）およびコミットしていない更新のキャッシュを保持する。これは「セッションキャッシュ」と呼ばれる。また、ＣＤＰは「明示的キャッシュ」も提供する。これは、アプリケーションが非連結モードで働くことを可能にする。ＣＤＰは、明示的キャッシュ内のデータに対する種々の整合性保証を提供する。このキャッシュは、ディスク上のデータ本体をメモリ内オブジェクトと関係づけることによって同一性管理（identity management）を実行する。

クエリプロセッサ（ＱＰ）：ストアに対するクエリの際に、ＣＱＬクエリはＳＱＬにマッピングされる。しかし、明示的キャッシュに対するクエリの際には、ＣＱＬクエリはＱＰコンポーネントによって処理される。データベースアクセスはクエリプロセッサを経由する。クエリプロセッサにより、フロントエンドが複数のクエリ言語を扱えることで、複数のクエリ言語が表現され、その後内部標準フォーマットにマッピングされることが可能となる。これは、ドメインモデルと、それが作用しているアプリケーションのオブジェクトとを用いて行われる。そして、クエリは、パイプラインであるプロセッサに渡された後、バックエンド固有のクエリに変換される。

カーソル：ＣＤＰは、前方専用カーソルおよびスクロール可能カーソルの両方を提供する。カーソルは、通知、展開／折り畳み状態を有するマルチレベルグルーピング、動的ソーティングおよびフィルタリングをサポートする。

ビジネスロジックホスト：ＣＤＰは、型／インスタンスに関して、およびオペレーションに関してデータ中心ロジックをホスティングするランタイム環境を提供する。このようなデータ中心ビジネスロジックは、アプリケーションサーバーにおいてホスティング可能なアプリケーション／ビジネスプロセスロジックとは異なる。オブジェクトはデータベース内の単なる行ではない。オブジェクトは、メモリ内に実体化されると、実際に、アプリケーションが呼び出せる挙動を有するオブジェクトとなる。システム内には、主としてイベントおよびコールバックである拡張ポイントがあり、これらはすべて、実行時にＣＤＰを拡張するように動作する。これらのオブジェクトは単なるオブジェクトではなく、ＣＬＲオブジェクト、．ＮＥＴオブジェクト等である。ＣＤＰは、それらのオブジェクトにおけるプロパティやメソッド呼び出しに割り込む能力を有する。アプリケーションは、これらのオブジェクトの挙動をカスタマイズすることができる。

サービス：ＣＤＰは、すべてのＣＤＰクライアントに利用可能なサービスの中心的なセットを提供する。これらのサービスはルール、変更追跡、コンフリクト検出、イベンティング、および通知を含む。イベンティングは、ＣＤＰランタイム１１０をフレームワークレベルのサービスやアプリケーションに対するサービスから拡張してさらに挙動を追加し、また、ユーザインタフェースにおけるデータバインディングのためにも使用される。

制約：ＣＤＰは、制約／セキュリティコンポーネント１１２を提供することにより、少なくとも、型設計者が制約を宣言的に作成できるようにする。こうした制約はストアで実行される。一般に、ＣＤＰ制約のスコープは、長さ、精度、スケール、デフォルト、チェック等のような概念を包含する。これらの制約は実行時にＣＤＰ制約エンジンによって強制される。

セキュリティ：ＣＤＰは、ロールに基づくセキュリティモデルを提供する。すなわち、ユーザのクレデンシャルが、そのユーザの「ロール」（例えばアドミニストレータ、パワーユーザ、承認者等）を決定する。各ロールには、アクセスパーミションのセットが割り当てられる。ＣＤＰのセキュリティエンジンは、これらのセキュリティポリシを強制する。さらに、ＣＤＰは、ＣＤＰ内のエンティティへのアクセスを制御するためのセキュリティモデルを提供する。セキュリティモデルは、オペレーティングシステムユーザの認証、エンティティの権限付与レベル（例えば読み出しおよび更新に対する別個のパーミション）等をサポートすることができる。

なお、制約／セキュリティコンポーネント１１２は、ＣＤＰランタイムコンポーネント１１０とは別個のエンティティとして動作できるので、ＣＤＰランタイムコンポーネント１１０とは別に図示していることに留意されたい。別法として、そしておそらくはより効率的には、制約／セキュリティコンポーネント１１２は、ストアコンポーネント２０２（これはデータベースシステムとすることができる）と統合される。

全体として、これらの機能は、複数の層にわたりフレキシブルにデプロイされることが可能なデータ中心アプリケーションおよびロジックを開発するための強力なプラットフォームを提供する。なお、この図におけるランタイムコンポーネント（あるいはボックス）の配置は、プロセス／マシンの境界を越えたいかなる特定のデプロイメントを意味する（あるいは必ず回避する）ものでもないことに留意されたい。これは、機能コンポーネントを示すために用いられる概略図である。

ＣＤＰアーキテクチャの主要な利点の１つとして、実装におけるフレキシビリティを提供することがある。これは次の２つのことを意味する：

１）図４に示したコンポーネントのいくつかは、複数のプロセス／層（Tier）に存在し得るという意味で「移動可能」である。具体的には、制約／セキュリティコンポーネント１１２は一般に、図２のストアプロセス２０２に存在する。
２）データプラットフォームが十分に機能するためには、図４に示したすべてのコンポーネントが実装される必要があるわけではない。具体的には、オブジェクトキャッシュ４１４はセッションキャッシュのみからなっていてもよい。別の実装では、キャッシュ４１４は、ストアと同期する明示的キャッシュを含み得る。クエリプロセッサ４０６は、オブジェクトキャッシュ４１４内のオブジェクトに対して作用する。

ＣＤＰのいくつかの機能および／またはコンポーネントを以下でさらに詳細に説明する。前述したように、ＣＤＰの中心には共通データモデル（ＣＤＭ）４０２があり、ＣＤＭ４０２の目的は、主としてユーザデータ（例えばＰＩＭ、ドキュメント等）ないしＬＯＢおよび企業データを処理するアプリケーションから、複数のアプリケーションドメインにわたり共通するモデリング概念を取り出すことである。一般に、このような機能を実装するために利用可能な技法として次の２つの可能性がある：１）想定される（あるいは重要と想定される）あらゆるドメインに固有の概念をモデリングする。例えば、「顧客・取引先（Customer）」が何を意味するかを（ＬＯＢドメインから）正確に定義し、「人・人物（Person）」が何を意味するかを（ユーザドメインから）正確に定義する等。２）アプリケーション設計者が自己のドメイン特定型式、制約、リレーションシップを作成することができるようなフレキシブルな基盤を提供する。ＣＤＭ４０２は、第２の手法を利用することにより、基本的な型（タイプ）の一組を提供し、新しい型を作成するためのフレキシブルなフレームワークを定義する。この意味で、ＣＤＭ４０２は、データモデルである（例えば、いくつかの特定の型およびそれらのセマンティクスを実際に定義する）と同時に、データメタモデルでもある（例えば、他のモデルを規定することができる）ことが可能である。

ＣＤＭ４０２のいくつかの特徴を以下で説明するが、これらは本発明に対する限定と解してはならない。データモデルは、リレーショナルデータモデルを包含し得る。すなわち、テーブル、行、クエリ、およびテーブルに対する更新の概念はＣＤＭ４０２によって公開される。ＣＤＭ４０２は、テーブルおよび行よりもリッチな、データに対するオブジェクト抽象化を定義できる。特に、ＣＤＭ４０２によれば、エンティティ、エンティティ間のリレーションシップ、継承(インヘリタンス)、束縛(コンテイメント)、およびそれらのコレクション（集合）のような概念を用いて、実社会の行為（real world artifact）をモデリングすることが可能となる。また、ＣＤＭ４０２は、プログラミング言語の型システムを、その中でモデリングされたアプリケーション抽象化に緊密に連携させることによって、アプリケーション構造とストレージ構造の間のインピーダンスミスマッチを最小限にすることができる。さらに、２層および多層アプリケーションを可能にするため、アプリケーション挙動に対するサポート（例えばメソッド、関数）と、挙動のフレキシブルなデプロイメントを提供できる。また、ＣＤＭ４０２は、基礎となる物理ストアとは独立に永続化セマンティクスを捕捉できるため、多様なストア上でＣＤＭ４０２の実装が可能となる。

ＣＤＭ４０２は複数の概念を引き起こし得る。以下の概念が、ドメイン固有のデータモデルを設計するために実装されるように、メタモデルによって利用されることが可能である。特に、以下の概念は、ＣＤＭ４０２の核心とみなすことができる：１）エンティティ型は、プロパティおよびメソッドのグルーピングのための、アプリケーション設計者の仕様であることが可能である。ここで、エンティティはエンティティ型のインスタンスである。理解されるように、エンティティ型は、継承階層（インヘリタンス・ヒエラルキー）を通じて組織化され得る。２）テーブルは、他のエンティティのプロパティであり得るエンティティのコレクションである。エンティティ、継承、およびテーブルを用いて、アプリケーションはデータ階層を再帰的に定義できる。テーブルは、所与のテーブルが所与の型またはその部分型のエンティティのみを含むことができるという意味で、強く型付けされることが可能である。３）テーブルセットは、そのプロパティがテーブルであるようなエンティティであることが可能である。これは、テーブルおよびエンティティを用いて定義された再帰的データ階層の基本的な場合である。これは、データベースの概念とほぼ同様であり得る。そして、４）リレーションシップは、エンティティ間の意味論的関連を表現できる。理解されるように、リレーションシップは、関連づけ（アソシエーション）、包含等を定義するように拡張可能である。

エンティティ、リレーションシップ、および／またはテーブルセットの定義は、例えばスキーマとの関連で生じ得る。本発明の目的上、スキーマの主要な目的は、スキーマで定義される要素の名前のスコーピングのための名前空間を定義することである。テーブルセットは、ＣＤＭ４０２の「トップレベル」（最高位）を形成し得る。ストレージは、テーブルセットを作成することによって直接的および／または間接的に割り当てられることが可能である。例えば、次の擬似コードは、テーブルセットの一例を示している：

エンティティ型は、それに関連づけられたプロパティおよびメソッドを有することができる。プロパティ、メソッドパラメータおよびメソッド返値の型を指定するため、ＣＤＭ４０２はいくつかの組込み型を提供する：１）単純型：Ｉｎｔ３２、ｓｔｒｉｎｇ、他のＣＬＲ値の型；２）列挙型：ＣＬＲｅｎｕｍと同等；３）参照型（後述）；および、４）配列型：インライン型（下記）の順序付きコレクション。これらの組込み型のプロパティをまとめることによりインライン型を作ることができる。インライン型は、他のインライン型のメンバを有することができる。以下は、上記の一例である：

エンティティは、組込み型および／またはインライン型を利用することにより構築できる。例えば、次の擬似コードはエンティティを示す：

エンティティ（テーブルセットを除く）は、あるテーブル内に含まれることが可能である。その少なくとも１つの理由は、テーブルセットはトップレベルの組織単位であり、テーブルセットはテーブルから構成されるからである。テーブルスコープ内では、各エンティティは一意のキー値を有することができる。ストア全体にわたるスコープでは、各エンティティは一意の識別（すなわち、そのキー値にそのテーブルの識別を再帰的に連結したもの）を有することができる。エンティティは、キーおよび／または識別によって参照可能なＣＤＭ４０２内の最小単位であり得る。ストレージ操作はエンティティを対象とすることができ、そのような操作としては、永続化、保存、移動、コピー、削除、名前変更、バックアップ、リストア等が挙げられるが、これらに限定されない。インライン型インスタンスは、包含する側のエンティティとの関連で使用可能である。ＣＤＭ４０２は、抽象エンティティ型の概念を定義することができ、これはＣＬＲにおける抽象クラスとほぼ同様である。すなわち、これは直接インスタンス化することはできず、他のインスタンス可能な型を作成するために派生可能なだけである。

エンティティ参照は、エンティティへの持続的・永続的な参照として定義できる。参照値はエンティティ識別全体に値をとる。エンティティを間接演算（indirecting）することでその参照が得られ、参照を逆参照（dereference:参照外し、参照剥がし、間接参照、参照値の読み出し、参照先データの取得等とも称されている）することでエンティティインスタンスが得られる。参照の主要な目的は、エンティティ共有を可能にすることである。例えば、同じ顧客のすべての注文が、Ref(Customer)プロパティについて実質的に類似の値を有する場合、注文エンティティは顧客エンティティを共有すると称する（例えば下記のコードサンプルの第６コード行が一例である）。

ＣＤＭ４０２に関連するデータは、その構成部分間にリレーションシップを有する。リレーショナルモデルは、リレーションシップを明示的にはサポートしない。ＰＫ／ＦＫ／参照完全性は、限定された形でリレーションシップを実装するためのツールを提供する。しかしながら、ＣＤＭ４０２は、アソシエーションおよびコンポジションを用いて、リレーションシップの明示的な概念的モデリングをサポートする。アソシエーションおよびコンポジションの能力を理解するため、次の例を挙げることができる：

1. <EntityType Name="Order" Key="OrderId">
2. <Property Name="OrderId" Type="String" Nullable="false">
3. <Length Minimum="10" Maximum="10"/>
4. </Property>
5. <Property Name="Date" Type="DateTime" Nullable="false"/>
6. <Property Name="Customer" Type="Ref(Customer)"
7. Association="OrderCustomer"/>
8. <Property Name="Lines" Type="Table(OrderLine)"
9. Composition="OrderOrderLine"/>
10. <Property Name="ShippingAddress" Type="Address"
Nullable="false"/>
11. </EntityType>
12. <Association Name="OrderCustomer">
13. <End Role="OrderRole" Type="Order" Multiplicity="*"
14. Table="SalesData.Customers"/>
15. <End Role="CustomerRole" Type="Customer" Multiplicity="1"/>
16. <Reference FromRole="OrderRole" ToRole="CustomerRole"
Property="Customer"/>
17. </Association>
18. <Composition Name="OrderOrderLine">
19. <ParentEnd Role="Order" Type="Order" Property="Lines"/>
20. <ChildEnd Role="OrderLine" Type="OrderLine"
Multiplicity="100"/>
21. </Composition>

アソシエーションは、エンティティ間のピアツーピア(peer to peer)リレーションシップを表現できる。上記の例では、注文がアソシエーション(Association)を通じて顧客に関係づけられている。上記のコードサンプルにおいて第６行は、注文が、関連する顧客（これは参照プロパティCustomerによって指定される）を有することを示している。このアソシエーションの性質は第１２〜１５行で定義されている。これは、OrderCustomerアソシエーションがOrderからCustomerへのアソシエーションであることを示している（第１５行）。また、各Customerについて（第１５行のMultiplicity="1"）複数のOrderが存在し得る（第１３行のMultiplicity="*"）。上記の種類のアソシエーションは、「参照アソシエーション」と呼ぶことができる。

ＣＤＭ４０２は、他に２種類のアソシエーション、すなわち「値アソシエーション」および「アソシエーションエンティティによるアソシエーション」を定義する。値アソシエーションは、識別参照によってだけでなく、任意のプロパティによるリレーションシップの表現を可能にする（例えば、Document.Authorプロパティは等式条件によってContact.Nameと関係する）。アソシエーションエンティティは、リレーションシップのモデリングを可能にする。この場合、リレーションシップ自体が何らかのデータを持つ（例えば、会社と人の間の雇用リレーションシップは、その会社内の人の雇用期間や職位および肩書きのようなプロパティを持ち得る）。

コンポジション(Composition)は、親子リレーションシップおよび／または束縛リレーションシップを表現できる。Order（注文）とOrderLine（注文明細行）を考える（例えば、Orderは、あなたがあるウェブサイトでショッピングカートに入れたものの全体であり、OrderLineは、カート内の書籍、ＤＶＤ等の個々の商品である）。各OrderLineは、Orderのコンテクスト内でのみ意味がある。OrderLineは、それを包含しているOrderの外部に独立して存在することができない。すなわち、OrderLineはOrder内に包含され、その有効期間はOrderの有効期間で決まる。

上記のリレーションシップは、コンポジションを用いてモデリングすることができる。第８行がコンポジションの一例を示している。LinesプロパティおよびOrderOrderLineコンポジション（第１８〜２１行）は、注文がその明細行を管理し、明細行はそれを含む注文に依存することを表現している。理解されるように、注文は親であり、明細行は子である。コンポジションとインライン型（inline type）の主要な相違点は、コンポジションがエンティティを含むという点である。すなわち、OrderLineは参照のターゲットであることが可能であるのに対して、インライン型は上記の例において参照のターゲットであるとすることはできない。

ＣＤＭ４０２およびそれによるリレーションシップの明示的モデリングの１つの利点は、クエリに対するメタデータ（データに関する属性情報を記述するデータのこと）のサポートを提供することである。アップストリームのクエリもまた利用可能である。例えば、ＣＤＭ４０２内にNavigationPropertyを実装することによって、顧客は、（明示的なバックポインタを保存することを必要とせずに）全注文検索を呼び出すことができる。これは、下記のコードフラグメントの第２８行に示されている。

28. <EntityType Name=" Customer" Key="CustomerId">
29. <NavigationProperty Name="Orders" Association="OrderCustomer"
FromRole="Customer" ToRole="Orders"/>
30. </EntityType>

永続化エンジン４０８は、オブジェクトリレーショナルマッピングを含むことができる。すなわち、ＣＤＰによって提供されるモデリング、アクセス、およびクエリの抽象化はオブジェクトベースである。ＣＤＰによって利用される主なストレージ技術はリレーショナルベースである（例えばＳＱＬ２０００）。永続化エンジン４０８は、オブジェクトリレーショナルマッピング（「Ｏ−Ｒマッピング」とも呼ぶ）を利用する。ここで、永続化エンジン４０８は、言語クラスを、基礎となるテーブル表現にマッピングすることができる。

永続化エンジン４０８は、Ｏ−Ｒマッピングを考慮する際に２つのケース、すなわち、１）規範的Ｏ−Ｒマッピング、および、２）非規範的Ｏ−Ｒマッピング、を提供できる。規範的Ｏ−Ｒマッピングは、ＣＤＰ型の間のマッピングであって、それらのリレーショナル表現をＣＤＰへとハードコードすることができる。型設計者には、基礎となるテーブルのレイアウトを選択する自由度がほとんどあるいは全くない。この一例として、データベース型ファイルストレージシステムが挙げられる。非規範的Ｏ−Ｒマッピングでは、開発者は、基礎となるストレージ構造にＣＬＲクラスがどのようにマッピングされるかを選択するさまざまな自由度を有する。考えられる２つのサブケースがある。１）既存のリレーショナルスキーマをオブジェクトとして公開するサブケース。型設計者は、ＣＤＭ型を設計するための高水準仕様言語、それらのＣＤＭ型に基づいてクラスを生成するためのツール、および型がテーブルにどのようにマッピングされるかを指定するフレキシビリティを利用する。この状況は、ＣＤＰアプリケーションが既存のリレーショナルアプリケーションと（実質的に類似のデータを使用するという意味で）並存してデプロイされる場合に生じる。例えば、自動車会社のＩＴ部門がＬＯＢアプリケーションを有しているが、（おそらくは段階的な移行戦略の一部として）同じデータに対するＣＤＰアプリケーションを書きたい場合がある。ここで要求されるのは、ＬＯＢアプリケーションおよび新規なＣＤＰアプリケーションの両方が同一データに対してともに動作することである。２）クラスのコレクションをリレーショナルスキーマに永続化するサブケース。開発者は、生成されているクラスを使用しない。むしろ、独自設計のクラスを利用する。開発者は、これらのクラスをリレーショナルスキーマにマッピングすることを望む。理解されるように、この要求を生じる多様な状況がある。

さらに、ＣＤＰは、設計時に利用可能なプログラミングサーフェス（図示せず）を含むことができる。プログラミングサーフェスは、ＣＤＰアプリケーション設計者および／またはプログラマにとって利用可能とすることができる。プログラミングサーフェスは次の３つの一般的領域に分類できる：１）設計時プログラミングツール（例えば、型設計者がＣＤＭ型およびその制約を作成し、これらの型からＣＬＲクラスを生成し、型に挙動を追加するためのツール）、２）ＡＰＩ（例えばＣＤＰアプリケーションを書くためのクラスおよびメソッド）、ならびに、３）クエリ（例えばエンティティインスタンスのようなＣＤＭオブジェクトにクエリを行うための言語）。プログラミングサーフェスのこれらのコンポーネントが相乗作用することで、基礎となるストアデータに対して、強く型付けされたオブジェクトベースの抽象化を提供する。

ＣＤＰは、エンティティ型、エンティティテーブル、エンティティ型間のリレーションシップ、および制約を定義するため、ＳＱＬのデータ定義言語やＣ＃のクラス定義に類似した、宣言的な共通スキーマ定義言語（ＣＳＤＬ）を提供する。以下の３つの主要な設計時のコンポーネントがある。

１．ＡＰＩジェネレータ。アプリケーション設計者は、ＣＳＤＬを用いてＣＤＭ型およびリレーションシップを設計し、これらの型およびリレーションシップに対応する部分ＣＬＲクラスを生成するＡＰＩＧ（「エイピグ」と読む）と呼ばれる設計時ＣＤＰツールを使用する。ＡＰＩＧにより生成されるクラスは、アプリケーションプログラマがアセンブリとして利用可能であり、Ｃ＃のｕｓｉｎｇ文を用いてアプリケーションプログラムから参照できる。ＡＰＩＧによって生成されるクラスは、ある意味で、標準的クラスである。すなわち、それらのクラスは、アプリケーションプログラム内のＣＤＭ型の直接的表現であり得る。一例として、アプリケーションが例えば以前に書かれたクラスライブラリ（グラフィクスパッケージ、数学パッケージ等）からのクラスを使用している場合のように、アプリケーションクラスがその定義に制約されることがある。アプリケーションは、ＣＤＰのオブジェクト永続化フレームワークを使用することにより、ストア内のこれらのクラスのインスタンスに対して持続的に永続化およびクエリを行うことができる。このようなオブジェクトはＰＯＣＯ（Plain Old CLR Object）と呼ばれることがある。ＣＤＰはＰＯＣＯ利用のケースもサポートする。
２．オブジェクトリレーショナルマッピング。ＣＳＤＬのこのコンポーネントは、アプリケーション設計者が、テーブルやビューのようなストア概念と、ＣＬＲクラスとの間の具体的で非規範的なマッピングを宣言するのに役立つ。また、このコンポーネントは、ＣＤＭ４０２に関して定義される制約がＳＱＬの宣言的制約、トリガあるいはストアドプロシジャにどのようにマッピングされ得るかも指定することができる。
３．挙動。ＣＳＤＬによれば、アプリケーション設計者は、ビジネスロジックのどの部分がインスタンスメソッドとして、静的関数として、あるいはストアドプロシジャとして実装されるかを決定できる。また、ＣＳＤＬは、ロジックが動作し得る層（例えばＣＤＰランタイムかストアか）も決定することができる。

さらに、プログラミングサーフェスはＣＤＰＡＰＩを含むことができ、これに対してプログラミングサーフェスアプリケーションを書くことができる。ＣＤＰＡＰＩは次の３つのサブパートを有し得る：

１．汎用ＣＤＰデータアクセス。これは、ストア、セッション、トランザクション（例えばStorageContext）、クエリサービス（例えばStorageSearcher）、およびＣＲＵＤサービス（例えばSaveChanges）を公開するＡＰＩの部分である。
２．ＣＤＭデータクラス。これは、エンティティ、リレーションシップ、エクステンション等のようなＣＤＭ概念を公開する標準的な、アプリケーションから独立したクラスのセットである。
３．ドメインデータクラス。これは、ＣＤＭ４０２に準拠するがドメイン固有のプロパティおよび挙動を公開するContact、Message、PurchaseOrdersのようなアプリケーション／フレームワーク固有のクラスである。

また、ＣＤＭ４０２は、クエリ言語ＣＱＬも定義することができる。ＣＱＬは、プログラマが扱うオブジェクト構造に対するリッチなクエリを可能にするように設計される。以下は、ＣＱＬ方式の基礎のために利用される３種類の技法である：

１．ＯＰａｔｈ：ＯＰａｔｈ言語は、ＳＱＬおよびＸＰａｔｈを起源としており、ＸＰａｔｈのＣＬＲオブジェクトバージョンとなるように設計された。設計は、ＸＰａｔｈのパス式の概念を基礎に、オブジェクトのプロパティを順に逆参照（dereference）するメソッドを公開する。設計は、１つの単純な原則、すなわち、開発者はオブジェクトのコレクションをオブジェクト指向ＡＰＩにおける主要な「構造的」コンストラクトとみなそうとする、という原則に基づいている。ＯＰａｔｈは、データベース型ファイルストレージシステムに対するＰＯＲクエリ方式となり得る。
２．オブジェクトＳＱＬ：この手法は、ＣＤＭオブジェクトのグラフおよびコレクションを操作するようにＳＱＬクエリ言語を拡張する。Ｗｉｎｄｏｗｓ（登録商標）クエリ言語（ＷｉｎＱＬ）は、ＣＬＲオブジェクトのグラフに対するクエリおよび操作を行うように設計されたＳＱＬの変種であり、ＳＱＬに必要とされる拡張のための設計候補である。
３．Ｃ＃シーケンスオペレータ：これは、強く型付けされた、コンパイル時チェックされるクエリおよび集合演算のためのＣ＃拡張のセットであって、（例えばオブジェクトリレーショナルマッピングを通じて）ＣＬＲオブジェクトの一時的あるいは永続的コレクションの広範なクラスに適用可能である。

戦略上、Ｃ＃シーケンスオペレータの手法が、ＣＱＬのフレームワークとなるために最も有用である。ＣＱＬはクエリ言語である。作成、更新、削除はオブジェクトオペレーション（新規（ｎｅｗ）、プロパティセッタ等）として実行される。永続化エンジン４０８内のＯ−Ｒマッピングコンポーネントは、これらのオペレーションを、ＳＱＬ内の基礎となるＤＭＬオペレーションにマッピングすることができる。

ＣＤＭ型とプログラミングサーフェスの間の関係を以下で説明する。ＣＤＭ４０２における「型」の概念は、次の３つの異なるレベルで見ることができる：

１．スキーマ空間：ＣＤＭスキーマにおける型の記述。これは、ランタイムスタックの（例えばアプリケーションからストアに至るまでの）いかなるコンポーネント内でも明示的に実体化できないという意味で抽象型である。
２．アプリケーション空間：ＣＤＰＡＰＩ内のＣＬＲクラスとしての型の表現。スキーマ空間内のエンティティ／インライン型と、アプリケーション空間内のデータクラスとの間には一対一対応が存在し得る。すなわち、ＣＤＭスキーマ内のそれぞれのエンティティおよびインライン型はＣＬＲクラスを生じ得る。多くの場合、このようなクラスはＡＰＩＧによって自動生成される。しかし、ＰＯＣＯの場合には、開発者がＣＬＲクラスとスキーマ空間内の型との間のマッピングを明示的に指定できる。また、アプリケーション空間は、エンティティおよびインライン型に対するクラスに加えて、リレーションシップクラスも含むことができる。
３．ストレージ空間：基礎となるストア内の型の永続化フォーマット。ストアがリレーショナルストアである場合、これらの型はテーブル／ＵＤＴ／コアＳＱＬ型である。ＣＤＰのＯ−Ｒマッピングコンポーネントは、スキーマ空間内の型がストレージ空間内の型にマッピングされることを可能にするマッピングスキーマをサポートする（例えば、Purchase Orderエンティティ型は、ＳＱＬサーバー内のPurchaseOrderテーブルにマッピングされることが可能である）。

ＣＤＰクエリ言語はアプリケーション空間を対象とする。これが意味をなす理由は、開発者は、他のオペレーションに対して使用する実質的に類似の抽象化（例えばオブジェクトやコレクション）を用いてクエリをしたいからである。ただし、ＣＱＬのセマンティクスはＣＤＭ抽象化（スキーマ空間）を用いて記述される。

また、ＣＤＰは、制約／セキュリティ１１２も含むことができる。ほとんどすべてのデータは、より広い意味論的コンテクスト内で調べると、何らかの形でその型のドメインについて制約される。したがって、型およびアプリケーションの設計者がこのような制約を表現する手段をＣＤＰが提供することは非常に重要である。ＣＳＤＬは、型設計時に宣言的に制約を作成するために使用可能である。制約の例としては、以下のものに限定されないが、１）長さ、精度、スケール、デフォルトおよびチェックのような単純型制約、２）要素制約、生起（occurs）、一意、およびチェックのような配列型制約、ならびに、３）プロパティ制約、等がある。

これらの制約は、実行時にＣＤＰ制約エンジンによって強制することができる。なお、ＣＤＭ４０２に準拠するということ自体、基礎となるリレーショナルストアのレベルから見ると、制約のセットを意味することに留意されたい。例えば、ＣＤＭ４０２は、「あらゆるエンティティはそれを包含しているテーブルのスコープ内で一意のキーを有する」ことを要求する。これは、ストアレベルでの一意キー制約と解釈される。このような制約には他にいくつかの例がある。ここで重要なことは、ＣＤＰ制約エンジンが、ＣＤＭ４０２によって含意される（そしてＣＤＭ４０２への準拠のために要求される）制約と、型設計者によって作成される制約という２種類の制約を強制することである。ＣＳＤＬで作成される宣言的制約に加えて、制約は、ＳＱＬサーバーストアドプロシジャを用いて書かれることも可能である。この方法によれば、宣言的言語で可能であるよりも複雑な制約の表現が可能となる。

さらに、制約／セキュリティ１１２は、ＣＤＰ内のエンティティへのアクセスを制御するためのセキュリティモデルを提供できる。ＣＤＰに対するセキュリティモデルは、少なくとも以下のことを満たさなければならない：

認証：セキュリティモデルは、オペレーティングシステムユーザの認証をサポートできる。これはドメイン、ワークグループあるいは非連結クライアントマシンのユーザを含む。また、セキュリティモデルは、ＮＴＬＭ（Windows NT LAN Manager）方式およびＫｅｒｂｅｒｏｓ（ケルベロス：暗号化を用いたユーザ認証のためのプロトコル）方式の両方の認証に対するサポートも含むことができる。

権限付与：ＣＤＰセキュリティモデルは、少なくともエンティティレベルでのセキュリティの権限付与をサポートすることができる。ＣＤＰセキュリティモデルは、エンティティの読み出しおよび更新に対して別個のパーミションを管理することもできなければならない。少なくとも、制約／セキュリティ１１２は、エンティティのセキュリティ識別子とみなされるべきエンティティの「プロパティ」および／またはプロパティのセットを提供する。エンティティのアクセス権は、セキュリティ識別子をパラメータとしてとるテーブルに関連づけられた関数によって決まる。また、ＣＤＰは、セキュリティ識別子を変更できるユーザに対するプロビジョニングと、エンティティの残りの部分を変更できるユーザに対するプロビジョニングとを別個に可能にすべきである。理解されるように、ＣＤＰは、単なる読み出しおよび書き込みにも異なるパーミションが可能な、より一般的なロールに基づくモデルをサポートすることができる。

ＣＤＰランタイム１１０は、クエリ結果（例えば以下で詳述するカーソル）およびコミットしていない更新のキャッシュ４１４（例えばオブジェクトキャッシュ４１４）を保持する。このようなキャッシュは、セッション・トランザクション４０４と結びついているので、セッションキャッシュと呼ばれることがある。また、このようなキャッシュは、セッションが作成される時に発生し、そのセッションが終了すると消滅する。ＣＤＰセッションは、StorageContextオブジェクト内にカプセル化される。アプリケーションは、StorageContextの複数のインスタンスをインスタンス化することができ、それにより複数のセッション、したがって複数のセッションキャッシュを生成する。また、ＣＤＰ(共通データプラットフォーム)は、明示的キャッシュと呼ばれる別種のキャッシュも公開することができる。明示的キャッシュは、１つまたは複数のクエリからのデータのキャッシュを提供する。データが明示的キャッシュ内に実体化されると、以下のデータ整合性保証を提供できる：１）リードオンリ、権威なし；２）ライトスルー、権威あり；および、３）外来通知による自動リフレッシュ。明示的キャッシュに対するプログラミングおよびクエリモデルは、ストアデータに対するものとほぼ同様とすることができる。

カーソル・ルール４１０は、ＣＱＬ（共通クエリ言語）から返されるデータエンティティのセットが一度に１つずつ処理されることを可能にするメカニズムである。アプリケーションは、結果セット全体をメモリ内に単にコピーし、メモリ構造内でこの上にスクロールパターンをオーバレイすることによって、結果セットに対するカーソルを作成できる。しかし、このことに対する要求が広く存在すること、および、カーソルの実装は（特に更新、ページング等を考慮に入れる場合には）複雑さを伴うことがあることから、データプラットフォームはカーソルモデルを提供すべきである。

ＣＤＰは、前方専用カーソルおよびスクロール可能カーソルの両方を提供する。ブラウズおよびスクロールの基本機能に加えて、ＣＤＰカーソルは以下の機能を提供する：１）外来通知および保守；２）展開／折り畳み状態を有するマルチレベルグルーピング；ならびに、３）動的ソーティングおよびフィルタリング（例えば「ポストプロセシング」）。認識され理解されるように、カーソルは、結果セットを指定するための別のメカニズムではなくてもよい。その場合、結果セットはクエリによって指定され、カーソルはそれらのクエリに対するものである。

また、ＣＤＰはビジネスロジックホスティング４１６も含むことができる。複数のアプリケーションが実質的に類似のデータを操作している場合、主要な要件は、データが信頼できる状態を保証することである。すなわち、データが種々の妥当性検査（バリデーション）ルール、ビジネスルール、ならびに、型設計者および／またはデータ所有者によって設定されたその他の抑制均衡システムに従っていることを保証することである。アプリケーションは一般的に信頼できないというのが妥当な仮定である。無思慮、悪意、および／または単なる切迫した予想外の使用パターンから、アプリケーションは無効なものを保存してしまうか、あるいは保存しようとする。例えば、ユーザがエリアコードとして２９２を入力すると、２９２が無効なエリアコードであるため電話番号フィールド内の値がもはや電話番号を表していなくても、アプリケーションはこの番号を保存する。すなわち、この番号が電話番号であることは「信頼」できない。これを防ぐための通常の方法は、信頼境界（trust boundary）を作成することである。信頼境界は、何らかの宣言的ルール／妥当性検査コード等（例えば、一般にビジネスロジックと呼ばれる）であって、別個のプロセスで動作し、アプリケーションによってなされるデータ変更を検査してその変更を「承認」する。その後、アプリケーションはこうした変更をストアに保存できる。多くの場合、ビジネスロジックは検査・承認よりも多くのことを行う。すなわち、ビジネスロジックは、ビジネスルールを強制し、ワークフロー(仕事の流れ)を発生させる（例えば、新規の顧客を挿入する時には、信用価値を確認するため信用調査部門に電子メールを送るべきである）等も行う。

ＣＤＰは、ビジネスロジック（ＢＬ）を作成するためのいくつかのメカニズムを提供する。これらのメカニズムは、次の５種類に分けることができる：制約、イベントハンドラ（イベント処理部）、静的／インスタンスメソッド、バインド可能な挙動、および静的サービスメソッド。これらについてはそれぞれ以下でさらに詳細に説明する。制約／セキュリティ１１２は、前述のように、宣言的、および、手続き的であり得る。このような制約は、データの近くで、ストア上で実行可能である。したがって、制約１１２は信頼境界内にあるとみなされる。さらに、制約は型設計者が作成可能である。

ビジネスロジックホスティング４１６はイベントハンドラを使用することができる。ＣＤＰＡＰＩは、データ変更操作時にいくつかのイベントを発生する。ＢＬ作成者は、ハンドラコードによりこれらのイベント内にフックすることができる。例えば、注文管理アプリケーションを考える。新規注文が入った時、アプリケーションは、注文額がその顧客に対して認められる信用限度より小さいことを確認する必要がある。このロジックは、注文がストアに挿入される前に実行されるイベントハンドラコードの一部となり得る。

概して、次のような型のイベントがあり得る：１）妥当性検査（例えば、このイベントは、提示された値を当事者が検査してその妥当性を確認する機会を提供する）；２）事前保存（例えば、このイベントは、変更をストアに保存する直前に発生され、目的および挙動においてＳＱＬサーバーの「ＢＥＦＯＲＥ」トリガと実質上同様とすることができる）；および、３）事後保存（例えば、このイベントは、変更をストアに保存した後に発生され、目的および挙動においてＳＱＬサーバーのＡＦＴＥＲトリガと実質上同様とすることができる）。この型のＢＬはＣＤＰで動作し、したがって、ＣＤＰがデプロイされる任意の層で動作し得る。このため、それがクライアント層で動作する場合、他のアプリケーションによってバイパスされる（例えば信頼境界内で実行されない）ことが可能である。

さらに、ビジネスロジックホスティング４１６は、静的／インスタンスメソッドを呼び出すことができる。ＣＤＭ型に対して自動生成されるクラスは部分クラスである。型設計者は、通常は特定の型または型のセットに対して意味のあるロジックを実装するために、これらの部分クラスにさらにメソッドを追加することによって、これらの部分クラスを完成させることができる。次の例を考える：person.GetOnlineStatus()、ここでpersonはPerson型のインスタンスである；emailAddr.IsValidAddress()、ここでemailAddrはSMTPEmailAddress型のインスタンスである、等とする。その性質上、この種のＢＬは強制可能でない。例えば、IsValidAddress()を呼び出すことにより妥当性を保証するのはアプリケーションの責任である。これは、ＣＤＰがデプロイされる任意の層で実行される。したがってこれは、ＣＤＰがクライアント層にある場合に信頼境界内で実行されない。

バインド可能挙動は、型設計者がサードパーティ拡張のためのプラグインポイントを作成することを可能にするコーディングパターンである。典型例は電子メールメッセージのための型である。与えられたマシン上で、相異なる電子メールプログラムが動作している可能性がある。各プログラムは、共通のMessage型を使用したいが、各プログラムはSendMessageメソッドの挙動をカスタマイズする必要もある。型設計者はこれを実現するために、SendMessageメソッドに対する基本挙動を定義し、サードパーティが実装へのポインタを提供することを可能にする。また、バインド可能挙動は、ＣＤＰがデプロイされる任意の層で動作する。したがってこれは、ＣＤＰがクライアント層にある場合に信頼境界内では実行されない。

静的サービスメソッドは、中間層に対して書かれてデプロイされ、クライアント層に対してリモーティング（遠隔操作）を行うＢＬである。すなわち、ＢＬは中間層でウェブサービスとして動作する。例えば、CreateAppointment()、GetFreeBusy()、等のようなサービスを提供するカレンダ管理サービスを考える。これらのサービス（「静的サービスメソッド」）はＣＤＰを用いて実装され、ウェブサービスは中間層にデプロイされる。クライアント層はウェブサービスプロキシを有し、ウェブサービスプロキシは、アプリケーションによって、チャネル（後述）を用いてこれらのサービスを呼び出すために使用される。この種のＢＬは中間層で動作することができ、信頼境界内にあることが可能である。

理解されるように、コンポーネント化されたアーキテクチャにより、ＣＤＰは、ある一定の範囲でストア不可知（store agnostic）のままであることが可能である。オブジェクトキャッシュ、カーソル、セッション、トランザクション等のようなＣＤＰ機能はＣＤＰレベルの抽象化を利用する。基礎となるストレージ抽象化へのマッピングはＯ−Ｒマッピングおよび永続化レイヤで行われる。マッピングロジックを書き換えることにより、ＣＤＰは、相異なるストア上に実装可能である。

図５は、ＣＤＰの種々のコンポーネント内のデータフロー（データ流れ）を示している。次の例を用いて、アプリケーション５００（アプリケーション２０６およびアプリケーション４００と同様）によるメソッド呼び出しに対する種々のコンポーネントのインタラクションを調べるのが有益である。

1. void AddToCart (String customerId, String productId)
2. {
3. using (OrderData od = new OrderData())
4. {
5. ShoppingCart cart = od.ShoppingCarts.Searcher.Filter(
6. "CustomerId={0}", customerId).GetFirst();
7. if(cart == null)
8. throw new Exception("No shopping cart");
9. Product product = od.Products.Searcher.Filter(
10. "Productld={0}", productId).GetFirst();
11. if(product = null) throw new Exception("Missing product");
12. cart.Products.Add(product);
13. od.SaveChanges();
14. }
15. }

この例は、永続的なShoppingCartに商品（item：品目ともいう）を追加する。このメソッドが例えばＡＳＰ．ＮＥＴウェブページを処理する一部として呼び出されることを考える。

第３行：ストレージコンテクストの作成。StorageContextは、アプリケーション５００によって作成されるOrderDataオブジェクトによってカプセル化される。OrderDataクラスは、ＣＤＭスキーマで記述されるテーブルセット型を表すことができる。OrderDataオブジェクトは、ストア２０２と対話するために必要に応じて構成されるStorageContextオブジェクトを作成する。StorageContextの初期化コードは、ランタイムセッション・トランザクションコンポーネント４０４の一部であることが可能であり、セッション・トランザクションコンポーネント４０４は、ストア２０２へのコネクションをオープンし、セッションの開始およびトランザクションコンテクストの作成に必要な作業を行う。セキュリティコンテクストが制約／セキュリティコンポーネント１１２に確立される。最後に、StorageContextのインスタンスがＡＰＩ１０８によってアプリケーション５００に返される。２層の場合、StorageContextを獲得することによりストア２０２へのコネクションが得られる。理解されるように、３層デプロイメントにおけるコネクションはやや異なり得る。

第５行：クエリ。第５行の式の右辺はＯＰａｔｈクエリである。永続化・クエリエンジン４０８が、ＣＤＭクエリに基づいてオブジェクトを取得するためのメソッドとの基本的インタフェースを公開する。ＣＤＭ４０２におけるＣＤＭ実装が、指定されたＯＰａｔｈを用いてメソッドを呼び出す。永続化・クエリエンジン４０８は、クエリをＳＱＬにマッピングし、ＴＤＳペイロードとして送信する。制約／セキュリティコンポーネント１１２は、セキュリティが正しく適用されること、および、アプリケーション／ユーザが見ることを許可されたデータのみを見ることを保証する。ストアは、クエリを実行し、その結果をＣＤＰランタイム１１０に返す。ＣＤＭ４０２および永続化／クエリエンジン４０８が協力してＴＤＳ結果からオブジェクトをハイドレート（hydrate）し、これらのオブジェクトをオブジェクトキャッシュ４１４（例えばセッションキャッシュ）に入れる。その結果、ＡＰＩ１０８はShoppingCartオブジェクトをアプリケーション５００に返す。

第９行：クエリ。このクエリおよび前のクエリのいずれにおいても、その結果としてカーソルは作成されない（GetFirst()メソッドは基本的にクエリへの「top 1」文に適用される）。しかし、クエリがカーソルの作成を要求した場合、カーソル／ルールコンポーネント４１０がこのオペレーションを実行する。

第１２行：更新。オブジェクトキャッシュ４１４内のShoppingCartオブジェクトが、指定されたProductを用いて更新される。

第１３行：変更のフラッシュ。OrderDataオブジェクト上のSaveChanges()の実装が、カプセル化されたStorageContextオブジェクト上のSaveChanges()を呼び出す。StorageContext.SaveChanges()は、ビジネスロジックホスティングコンポーネント４１６の一部である。これは以下のステップを伴う。まず、事前保存ロジックが実行される。次に、妥当性検査コードが実行された後、事後保存プロセスが実行される。妥当性検査コードは、ＣＤＰＡＰＩ１８０によって定義されるイベントにフックされる。なお、別の実装として、妥当性検査コードはオブジェクトのセッタにフックされることも可能である。次に、事前保存コードが実行される。このコードは、ＣＤＰＡＰＩ１８０によって定義されるイベントにフックされる。ストアへの変更の書き込み。まず、ホスティングコンポーネント４１６がオブジェクトキャッシュ４１４を処理することにより、このストレージコンテクスト内でなされたすべての変更を含む変更ベクタを取得する。永続化エンジン４０８はIPersistというインタフェースを公開する。これは、Write(<changeVector>)等のようなメソッドとの基本的インタフェースである。ホスティングコンポーネント４１６は、永続化エンジン４０８からIPersistを取得し、変更ベクタを用いてIPersist.Write()を呼び出す。永続化エンジン４０８は、書き込み要求を適当なＳＱＬ更新（実際のＵＰＤＡＴＥ文か、またはストアドプロシジャコールのいずれか）にマッピングし、これを用いて変更をストア２０２に書き込む。このプロセス中に、制約／セキュリティコンポーネント１１２は、適当なセキュリティ強制がなされることを保証する。また、制約／セキュリティコンポーネント１１２は、任意の制約ロジックも実行する。最後に、事後保存コードが実行される。このコードは、ＣＤＰＡＰＩ１８０によって定義されるイベントにフックされる。

なお、ビジネスロジックの実行の結果、キャッシュ４１４内のオブジェクトに変更が生じ得る。こうした変更は、myStorageContext.SaveChanges()への呼び出しによってストア２０２に永続化される。これは、ビジネスロジック４１６がバイパスされないことを保証する。複数のＩＳＶ（独立系サポートベンダ）が、データ変更に関するロジックを実行したい場合がある。この場合、それらのＩＳＶは、自己のハンドラをイベントにフックし、ハンドラはＣＬＲによってＦＩＦＯ（先入れ先出し）順に呼び出される。この例では、ビジネスロジック４１６はＩＳＶの妥当性検査、事前保存、および事後保存ロジックをホスティングする。

図６は、ＣＤＰを用いて実装可能な種々のフレームワークを示している。ＣＤＰは、種々の特殊な垂直的ドメイン（例えばユーザデータ、ＬＯＢデータ等）にわたって使用可能であるように設計されたデータプラットフォームである。ＣＤＭがドメイン不問のデータモデルを提供する。これは、ドメイン固有の構造およびセマンティクスを表現できる程度にリッチではあるが、それと同時に、相異なるドメインにわたって使用可能であるくらいに一般的である。ＣＤＰの諸機能はＣＤＭに基づいているため、すべてのドメインのアプリケーションにわたって利用可能である。

ＣＤＰに対して書かれるアプリケーション全体は次の３つのクラスに分けられる：

１．フレームワーク：フレームワークは、特定のドメインに対してＣＤＰをカスタマイズするために、ＣＤＰによって提供される拡張性メカニズムを使用する。フレームワークは、型の特殊化および追加サービスにより、ＣＤＰに価値（value）を付加する。しかし、アプリケーションに公開されるプログラミングモデルはＣＤＰプログラミングモデルである。特に、アプリケーションはデータクラス、StorageContext、StorageSearcher、およびＣＱＬを依然として使用する。データベース型ファイルストレージシステムは、ユーザデータドメインに対してカスタマイズされた、ＣＤＰの上のフレームワークの一例となり得る。
２．垂直的プラットフォーム：固有のＡＰＩ、抽象化、およびデータモデルを有する、ＣＤＰの上の別個の層。これは、ＣＤＰを隠蔽し、全く異なるプログラミングモデルをアプリケーションに公開する。例えば、電子メールとともに利用されるアプリケーションはＣＤＰを使用可能であるが、そのユーザに対しては電子メールオブジェクトモデルを公開する。
３．「通常の」アプリケーション：特定のタスクのセットを遂行することを意図した単なるＣＤＰアプリケーション。これは、ＣＤＰ型を特殊化すること、プログラミングモデルを公開すること、あるいは、フレームワークや垂直的プラットフォームを使用することはない。

垂直的プラットフォームおよび「通常の」アプリケーションは単なるコードである。すなわちこれらは、好悪にかかわらず望み通りにＣＤＰを使用することができる。フレームワークはやや異なる。フレームワークはＣＤＰをアプリケーションから隠蔽せずにＣＤＰに価値を付加するので、以下のルールに従うことが可能である：

１．フレームワークデータモデルはＣＤＭと同一であるか、または、ＣＤＭの簡単な、十分にドキュメンテーションの付された特殊化である。フレームワークデータモデルは新規な型を定義できるが、これらの型はエンティティによって最大スーパープロパティの型化（ultimate-supertype）される。
２．フレームワークは、既存のＣＤＭ型に対する付加的制約を定義することや、ＣＳＤＬを用いて新規な制約を作成することが可能である。すなわち、制約は、制約定義のためのＣＤＭ方法を用いることにより表現しなければならない。
３．フレームワークは通常、独自のクエリ言語を公開しない。公開するとしても、ＣＱＬに代えてではなく、ＣＱＬに追加する形となる。
４．フレームワークは通常、独自のプログラミングモデルを公開しない。公開するとしても、ＣＤＰＡＰＩに代えてではなく、ＣＱＬに追加する形となる。
５．フレームワークは、ＣＤＰの上に付加的な特殊なサービスを提供する。これらのサービスは、ＣＤＰビジネスロジックとして、または付加的なヘルパークラスおよびメソッドとして実装され得る。

認識され理解されるように、上記のルールはすべて、所与のフレームワークによってＣＤＰに保存されるデータが、アプリケーションがこのフレームワークを使用しているかどうかにかかわらず、すべてのアプリケーションからアクセス可能となるように保証することを意図している。

図６は、ＣＤＰレイヤ６０２の上の３つのフレームワーク、すなわち、ユーザアプリケーションフレームワーク（ＵＡＦ）６０４（例えば、データベース型ファイルストレージシステム、ＷｉｎＦＳ等）、コラボレーションフレームワーク６０８（例えばＷＳＳ）、およびビジネスフレームワーク６１０（ＢＦ）（例えばＬＯＢフレームワーク）を示している。各フレームワークに属するデータが、フレームワークのボックスと同じパターンで示されている。例えば、ＵＡＦ６０４は、連絡先６１８およびアイテム６２０というデータを有し、コラボレーションフレームワーク６０８はドキュメントライブラリ（ＤＯＣＬＩＢ）６２２というデータを有し、ＢＦ６１０は注文６２４というデータを有する。これらすべての型はエンティティ６２６に最大スーパープロパティの型化されていることに留意されたい。

また、図６は、アプリケーションレイヤの３つのアプリケーション、すなわち、連絡先管理アプリケーション６１２、コラボレーションアプリケーション６１４（例えば電子メールアプリケーション）、および顧客関係管理（ＣＲＭ）アプリケーション６１６も示している。連絡先管理アプリケーション６１２は、ＵＡＦ６０４からのデータ全般を扱う。ＣＲＭアプリケーション６１６はＵＡＦ６０４およびＢＦ６１０の両方からのデータを扱う。そして、コラボレーションアプリケーション６１４は、３つのフレームワークすべて（すなわちＵＡＦ６０４、コラボレーションフレームワーク６０８、およびＢＦ６１０）からのデータを扱う。

図７は、複数のアプリケーションがデータを共有することを可能にする共通のデータベース型ファイルストレージシステムの事例を示している。すなわち、図７は、単一のフレームワークを利用する複数のアプリケーションを示している。ＣＤＰコンポーネントおよびストアコンポーネント７０２（図７ではＣＤＰ＋ストアとして示す）は、あらゆるアプリケーションによって活用される、オペレーティングシステムに対する単一のデータプラットフォームとして利用可能である。その利点（前述）は、リッチなモデリング（モデル化）、データ透過性、およびデータ共有である。これらの利点について、以下のようにさらに詳細に説明することができる。

ＣＤＭは、多様なアプリケーションおよび事例のセットによって要求される型を記述するために使用可能なフレキシブルなモデリング環境を提供する。例えば、ユーザデータ（例えばドキュメント、ファイル、写真、音楽、...）、ＬＯＢデータ（例えば顧客、注文、注文明細、...）、ＰＩＭデータ（例えば連絡先、電子メール、カレンダ、タスク、...）はすべて、ＣＤＭを利用してモデリング可能である。構造化、半構造化、および非構造化データにわたるとともに垂直的ドメインにも広がるこの種のリッチなモデリングは、単一のアプリケーションが、共通の抽象化およびクエリ言語を用いてさまざまな種類のデータを扱うことを可能にする。すなわち、ＣＤＰは１つのストアとして使用可能である。

ＣＤＰは、すべてのアプリケーションによって活用される単一のデータプラットフォームとして利用可能である。さらに、ＣＤＰを用いて保存されたデータは、すべてのアプリケーションが（例えばセキュリティポリシの下で）作用するために利用可能である。次の場合を考える。各アプリケーションがあるフォーマットでデータを保存し、そのフォーマットが、当該アプリケーション（すなわちそのデータを保存したアプリケーション）自身以外の他のアプリケーションにとって不透明であるとする。２つほど例を挙げる：電子メールのメールボックスの内容が、電子メールアプリケーション以外の他のすべてのアプリケーションとって不透明である場合；ＣＲＭアプリケーションが、複雑なスキーマのセットをテーブルの上にオーバーレイすることで、Ｃｕｓｔｏｍｅｒ（顧客）、Ｃａｓｅ（ケース）等のような抽象化を作成しているため、「Ｃｕｓｔｏｍｅｒ」という概念が他のすべてのアプリケーションにとって（例えばそのアプリケーションがＣＲＭアプリケーションによって使用されるスキーマを知らなければ）不透明となる場合。

明らかに、電子メールアプリケーションのデータには、ＣＲＭアプリケーションによって保存されるデータと概念的に類似しているものが存在する。一例として連絡先（Ｃｏｎｔａｃｔ）情報がある。ユーザに関する限り、連絡先は連絡先にすぎない。この観点からは、どうして同一の連絡先情報が２回、すなわち１回はＣＲＭに、そして１回は電子メールのメールボックスに、保存されるのかを理解することは困難である。ここでの問題は、単に保存が冗長であるということだけでなく、これが含意するすべての変則的なこと、例えば、両方の場所での更新の発生、削除の調停、および両方の場所での挿入の保証等である。電子メールアプリケーションおよびＣＲＭアプリケーションが両方ともＣＤＰストア７０２上に構築される場合に何が起こるかを考える。ＣＤＭを用いると、Ｃｏｎｔａｃｔ型をエンティティ型から派生させることができ、その構造は電子メールアプリケーションおよびＣＲＭアプリケーションの両方にとって透過的となる。したがって、これら２つのアプリケーションが型のスキーマに関して合意する限り、異なるアプリケーションが互いの存在を知らずに互いのデータを使用できる。ＣＤＰは共通クエリモデルを提供するので、（例えば）ＣＲＭアプリケーションは、Ｃｏｎｔａｃｔの特定のインスタンスがそれに「属する」かどうかにかかわらず、Ｃｏｎｔａｃｔデータに対するクエリを行うことができる。

リッチなモデリング、データ透過性およびプラットフォーム・フレームワーク型アーキテクチャの組合せにより、複数のアプリケーションおよびフレームワークの組合せに関わる多くの共有／相互運用事例が可能となる。理解されるように、共有という用語は、どのアプリケーションがデータを保存したか、あるいはどのフレームワークがそのデータを保存するために利用されたかにかかわらず、そのデータがＣＤＰに保存されている限り、そのデータを利用できるアプリケーションについて用いることができる。

特に、図７は、複数のアプリケーションがデータを共有する共通ＵＡＦ（ユーザアプリケーションフレームワーク）の事例を示している。この場合、データはアイテム７０６から派生したＵＡＦ型のセットである。ＣＤＰ・ストア７０２は、ＵＡＦフレームワーク７０４に関係するＵＡＦ型のセットを含み得る。ＵＡＦ型のセットはアイテム７０６から派生でき、このセットは電子メール７０８、ドキュメント７１０、および連絡先７１２を含み得る。また、理解されるように、アイテム７０６はエンティティ７１４から派生できる。ＣＤＰおよびＵＡＦフレームワーク７０４と組み合わせて複数のアプリケーションが利用可能であり、例えば、以下のものに限定されないが、電子メールアプリケーション７１６、リッチｅｖｉｔｅ（イーバイト）クライアント７１８、およびＰｒｏｊｅｃｔＭ（プロジェクトＭ）７２０が利用可能である。認識され理解されるように、アプリケーション、ＣＤＰ、ＵＡＦが存在する層に関して何ら制限は課されない。例えば、図７のアプリケーションのいずれか（例えばコラボレーションアプリケーション）が中間層で実行・動作することも可能である。

図８は、ＣＤＰおよび関連するアーキテクチャによる複数のフレームワークを利用した単一のアプリケーションを示している。ＣＤＰ・ストア７０２は、アプリケーションによって活用されるオペレーティングシステムに対する単一のデータプラットフォームを提供する。主としてＬＯＢフレームワーク８０４に対して書かれ得るＣＲＭアプリケーション８０２は、ＵＡＦフレームワーク８０８に関連する連絡先データ８０６を利用できる。理解されるように、ＣＲＭアプリケーション８０２は通常、以下のものに限定されないが、注文明細８１４、および購入注文書（purchase order）８１６のような、関連するデータを利用する。ＣＲＭアプリケーション８０２は、ＵＡＦデータ（例えば連絡先データ８０６、アイテム８１０、エンティティ８１２等）を利用する際に、ＣＤＰレベルの抽象化を利用できる。すなわち、ＣＲＭアプリケーション８０２は、ＵＡＦフレームワーク８０８のメソッドを利用する必要はない。さらに、認識され理解されるように、ＣＲＭアプリケーション８０２は任意の層に存在することができる。

図９は、複数の異なるフレームワークに関連する複数のアプリケーションとデータを共有するＣＤＰを示している。図９は、ＣＤＰ９０２の上の３つのフレームワーク、すなわち、ＵＡＦフレームワーク９０４、コラボレーションフレームワーク９０８、およびＢＦフレームワーク９１０を示している。複数のアプリケーションが、フレームワークレベルおよびＣＤＰレベルのプログラミングの組合せを利用できる。特に、連絡先管理アプリケーション９１２、コラボレーションアプリケーション９１４、およびＣＲＭアプリケーション９１６が、フレームワークレベルおよびＣＤＰレベルのプログラミングの組合せを利用できる。ＣＤＰ９０２は、ストア９２８内のデータを共有するために、複数の異なるフレームワークに関連するそれら複数のアプリケーションを提供する。

具体的には、複数のアプリケーションがデータと相互作用するには種々の方法がある。連絡先管理アプリケーション９１２は、ＣＱＬを利用して、連絡先９１８に対するクエリを行うことができる。すなわち、連絡先管理アプリケーション９１２は、アイテム単位のmove（移動）、copy（コピー）、contact.GetBestEAddress()等のようなＵＡＦ９０４のメソッドを利用できる。また、連絡先管理アプリケーション９１２は、以下のものに限定されないが、StorageContext、StorageSearcherのようなコアＣＤＰランタイムクラス、およびＣＤＰデータクラス（例えば連絡先クラスならびに関連するゲッタおよびセッタ）を利用することができる。

コラボレーションアプリケーション９１４は、ＣＱＬを利用して、連絡先９１８およびドキュメントライブラリ（ｄｏｃｌｉｂ）９２２内の任意のドキュメントに対するクエリを行い、さらにおそらくは注文９２４に対するクエリも行うことができる。コラボレーションアプリケーション９１４はこのようなクエリを行うために、ＵＡＦ９０４および／またはＢＦ９１０の存在を知る必要はない。クエリは、他のフレームワークによって書かれた特別なコードを利用せずに、純粋にＣＤＰレベルで行うことが可能である。コラボレーションアプリケーション９１４は、AddDocumentToDocLib(<document>, <docLib>)等のように、コラボレーションフレームワーク９０８に固有のオペレーションを利用して、ドキュメントライブラリ９２２を操作する。また、コラボレーションアプリケーション９１４は、StorageContext、StorageSearcher、Contact、Order、DocLibrary、ならびに関連するセッタおよびゲッタのようなＣＤＰレベルのクラスを利用することができる。

ＣＲＭアプリケーション９１６は、ＣＱＬを利用して、与えられた連絡先によるすべての注文に対するクエリを行う。理解されるように、ＣＲＭアプリケーション９１６は、その連絡先が実際にはＵＡＦ９０４を利用して作成されたことを知らずにこのクエリを行うことができる。ＣＲＭアプリケーション９１６は、ＢＦ９１０によって提供されるメソッドおよびサービス（例えばFindShipStatus(<order>)）を利用してOrderを操作する。また、ＣＲＭアプリケーション９１６は、StorageContext、StorageSearcher、Contact、Order、ならびに関連するセッタおよびゲッタのようなＣＤＰレベルのクラスを利用することができる。

非ＣＤＰストア（non-CDP store）との共有を行う場合、任意のデータソースがＣＤＰストアとして見えるプロバイダモデルを、ＣＤＰが使用しない点に留意することが重要である。ＣＤＰ／フレームワークアプリケーションが非ＣＤＰストア内のデータを扱いたい場合、次の２つの選択肢が使用可能である：１）同期アダプタアーキテクチャ（これはＵＡＦの一部である）を用いてこのデータをＣＤＰストアに同期させる；および、２）非ＣＤＰストアに組み込むためのカスタムロジックを構築する。

図１０は、ＣＤＰの２層デプロイメントを示している。ＣＤＰを構成する種々のコンポーネントは、ある意味で移動可能である。ある一定の限定の下で、それらのコンポーネントは、相異なるプロセスおよびマシンの境界を越えてデプロイ可能であるため、２層、３層、およびＮ層（ここでＮは１以上の整数である）構成が得られる。認識され理解されるように、２層デプロイメントが例示されているが、本発明はそのように限定されず、任意層数の構成が使用可能である。

特に、ＣＤＰＡＰＩ１００２およびＣＤＰランタイム１００４が両方とも、アプリケーション１００６と関連するアプリケーションプロセスに存在できる。したがって、ＣＤＰコンポーネント（例えばＣＤＰラインタイム１００４、ＡＰＩ１００２、および制約／セキュリティ１００８）はさまざまな層に存在できる。例えば、ＡＰＩ１００２、ＣＤＰランタイム１００４、およびアプリケーション１００６はクライアント層１０１０に存在できる。ここで、クライアント層１０１０のコンポーネントはそれぞれのプロセス／マシン境界内に存在できる。また、ストア１０１２および制約／セキュリティ１００８はサーバー層１０１４に存在できる。ここで、サーバー層１０１４のコンポーネントはそれぞれのプロセス／マシン境界内に存在できる。理解されるように、制約／セキュリティ１００８はストアプロセスにホスティングされ得るが、残りのＣＤＰコンポーネントはクライアントプロセス内に存在し得る。これは、どのようにしてＣＤＰコンポーネントを移動可能とみなし得るかの重要な一例である。

図１１は、本発明の一態様による、共有データを用いた２層デプロイメントを示している。第１の構成（下記）は、複数のアプリケーションが同一のデータを共有する場合である。これは、アプリケーションはデータを共有しなければならないということではない。むしろ、どのアプリケーションのデータも他のアプリケーションから利用可能であるということである。また、データの利用可能性は、ユーザとの関連ではなくアプリケーションとの関連でのことである。したがってこれは、ユーザ認証（user credential）の概念とは異なる。ＣＤＰランタイムの制約／セキュリティモジュールは、アプリケーションとは無関係にこれを扱うことができる。

アプリケーションは、ＡＰＩおよびＣＤＰランタイムと対話することができる。ここで、種々のアプリケーションがそれぞれのコンポーネントとともに存在し得ることにより、それぞれのアプリケーション、ＡＰＩ、およびＣＤＰランタイムは、境界１１０２、境界１１０４、および境界１１０６として示されている固有のマシン／プロセス境界を有し得る。簡単のため、３つのアプリケーション（すなわちアプリケーション１、アプリケーション２、およびアプリケーション３）が示されているが、任意個数のアプリケーションが使用可能であることは言うまでもない。アプリケーションは、自己のプロセス／マシン境界１１１２内のストア１１１０内の共有データ１１０８にアクセスできる。理解されるように、異なるアプリケーション間でのこのようなデータの共有中には制約／セキュリティ１１１４が強制される。

この構成は多くのユーザ事例で非常に重要である。例えば、この構成は、スキーマ化されたユーザデータに対するデータベース型ファイルストレージのビジョン（構想）における基礎となり、ＩＳＶ（独立系サポートベンダ）がインテリジェントでデータアウェアなアプリケーションを構築するために活用できる。プロジェクトＭは、これに基づいて、すべてのユーザデータに対するユニバーサルキャンバスであるというそのビジョンを実現できる。これは、ＣＤＰによってサポートされる重要な構成である。

図１２は、アプリケーションが他のアプリケーションによる閲覧および／または利用を望まないプライベートデータを有するような第２の構成を示している。すなわち、プライベートデータに関わる２層デプロイメントがある。アプリケーションプライベートデータの概念を必要とする多くのユーザ事例およびＩＳＶ事例が存在する。例えば、アプリケーションがそのコンフィグレーションデータ（例えばｉｎｉファイルと同等のもの）をデータベース型ファイルストレージシステムに保存することに決めた場合、これはアプリケーションにとってプライベートであるのが望ましい。多くの場合、部分的プライバシー、すなわち、読み出しは許可するが書き込みは許可しない、ということに対する要求がある。例えば、電子メールアプリケーションでは、メールボックスを表示することは望ましいが、メールボックスを変更する権利は自分自身に留保するであろう。

２層デプロイメントにおいて、ＣＤＰは、この構成に対するサポートが限定されている。ＳＱＬサーバーのストアにおけるアプリケーションレベルのセキュリティに対する適度なサポートはない。その結果、一部のデータが、データアクセスを阻止するという厳格な意味で、所与のアプリケーションにとってプライベートとマークされないことがある。しかし、この状況は以下のようにして部分的にサポートされることが可能である：
・アプリケーションが固有の型を使用し、その型を別個の名前空間に置き、それらの型から生じるデータクラスに対するプライベートアセンブリを作成する。このスキーマに属するインスタンスデータへのすべてのＣＤＰレベルのアクセスはこれらのアセンブリを通して行われるので、他のアプリケーションは、対応するクラスへのアクセスができない。
・アプリケーションが固有のプライベートＣＤＰストア（例えば、StorageContextがその上に作成され得るＣＤＰ内のエンティティのセット）を作成し、その名前を他のアプリケーションに公開しない。
・ドキュメンテーションを活用する。

理解されるように、アプリケーションは、プライベートデータを持つために、上記の方法の一部または全部を選択することができる。

なお、ＣＤＰアーキテクチャ自体が、プライベートデータの真の概念の実装に向けて障害を生じるわけではないと気付くことができる。したがって、基礎となるプラットフォームでアプリケーションレベルのセキュリティが利用可能となった場合、ＣＤＰはそれを容易に公開することができると考えられる。またここで留意すべきは、多くの場合、「プライベートデータ要求」は、可視性を制限することが真に必要であるという理由からではなく、データに対してアプリケーション固有のビジネスロジックを強制する必要から生じる。例えば、電子メールアプリケーションによって作成されるローカルメールボックスはカレンダフォルダを有する。ルールとして、カレンダアイテムのみをこのフォルダに入れることができる。このルールが強制される限り、電子メールアプリケーションにとって、別のアプリケーション（例えば他社製の電子メールアプリケーション）が自己のメールボックスを閲覧／変更することができるかどうかは無関係であろう。ＣＤＰアーキテクチャは、すべてのアプリケーションがＣＤＰレイヤを通ってくる限り、すべてのビジネスロジックの強制を行う。理解されるように、中間層でこれを強制できるので、プライベートアプリケーションデータは３層デプロイメントでサポートされる。

図１２の説明を続けると、アプリケーションがＡＰＩおよびＣＤＰランタイムと対話するマシン／プロセス境界１２０２と、アプリケーションがＡＰＩおよびＣＤＰランタイムと対話するマシン／プロセス境界１２０４が示されている。簡単のため、アプリケーションは２つだけ示されているが、理解されるように、任意個数のアプリケーションが、自己のプロセス／マシン境界１２０８内のストア１２０６内で、共有データ１２１１にアクセスでき、また、それぞれのプライベートデータ（例えば、アプリケーション１はプライベートデータ１２１０、そして、アプリケーション２はプライベートデータ１２１２）にアクセスできる。

図１３は、別のアプリケーションがストアに直接アクセスするような、関連する第３の構成を示している。すなわち、直接ストアアクセスを備えた２層デプロイメントがある。マシン／プロセス境界１３０２内のアプリケーション２は、おそらくは例えばＡＤＯ．ＮＥＴを通じて、あるいは他のデータアクセスＡＰＩを通じて、直接にＳＱＬストア１３０６にアクセスできる。例えば、既存のＳＱＬアプリケーションを有する大規模なＩＴ（情報技術）専門店（アイ・ティ・ショップ）は、それをなくして丸ごとＣＤＰベースのアプリケーションに移す可能性は低い。むしろ、少しずつＣＤＰへの移行を実施する可能性がある。実働環境では停止時間ゼロおよび安定性が重要課題なので、ある一定期間、ＣＤＰアプリケーションはＳＱＬアプリケーションと並行して動作し続け得る可能性が高い。ＣＤＰはフレキシブルで非規範的なＯ−Ｒ（オブジェクト−リレーショナル）マッピングを提供するので、ＣＤＰアプリケーションは既存のスキーマの上にデプロイ可能である。ＣＤＰアーキテクチャによれば、当然、直接のＳＱＬアクセスが可能である。その理由は、「アプリケーション１データ」は単にテーブルのセットであり、アプリケーション２が適当なパーミション（permission:同意、許可）を有する限り、アプリケーション２がそのデータに直接にアクセスすることを妨げるものは何もないからである。

アプリケーション２について、以下の結果に留意されたい：
１）アプリケーション２はＣＤＰサービス（あるいはＣＤＰの上のフレームワークによって構築された任意のサービス）へのアクセス権を持たない可能性がある。
２）具体的には、アプリケーション２はＣＤＭの利益を受けない。したがって、テーブル表現を判断し、このレベルで直接にクエリ／更新を発行しなければならない。

アプリケーション１について、以下の結果に留意されたい：
１）ＢＬサービス内のビジネスロジックはアプリケーション２によって実質的にバイパスされる。
２）一部の制約（例えばトリガ／ＤＲＩ（宣言型参照完全性（declarative referential integrity））として実装されないもの）もアプリケーション２によってバイパスされる。

この特定のデプロイメントでは、アプリケーション２が自己のロジックで制約等を実行することにより物事が適正に行われるようにすることは、アプリケーション設計者および／またはデプロイメント管理者の責任である。

図１４および図１５は、ＣＤＰコンポーネントの３層デプロイメント構成を示している。種々のＣＤＰコンポーネントが３層構成でデプロイ可能である。この構成では、ＣＤＰランタイム１４０２がクライアント層および中間層（図１５に示す）の両方に存在する。アプリケーションはクライアント層にあり、ストア１４０４はサーバー層（図１５に示す）にある。アプリケーションロジックは、図１４および図１５における２つの要求者に関係し得る。第１の要求者はクライアント１４０６である。第２の要求者は、ウェブサービスプロキシ１４０８、ウェブサービス１４１０（図１５に示す）、およびビジネスロジックホスティング１４１２（図１５に示す）（例えば、妥当性検査、事前保存ロジック、および事後保存ロジック）である。クライアント１４０６はアプリケーションであるため、それに含まれるロジックを「アプリケーションロジック」と呼ぶことは正当かもしれないが、このロジックはそう呼ばれるものではない。そう呼ばれるのは、ウェブサービスプロキシ１４０８、ウェブサービス１４１０、およびビジネスロジックホスティング１４１２内に含まれるロジックである。これは、ＩＳＶによって書かれ、中間層にデプロイされることが意図されたコードである。したがって本当の意味では、これは中間層「アプリケーション」である。アプリケーションロジックはクライアント層および中間層の両方の存在し得る。アプリケーションロジックがどこで動作するかに応じていくつかの可能な事例があり、それらを以下で考察する。

事例ごとの考察に進む前に理解しておくべきことであるが、多層デプロイメントのテーマは、アプリケーションアクションが層間でリモーティングされる方法に密接に関係している。リモーティングという用語は、層間でアプリケーションレベルまたはＣＤＰサービスレベルのオペレーションをリモーティングするための次の３つの一般的手法を包含し得る：

１．ウェブサービス経由でのアプリケーションレベルのリモーティング：この事例では、アプリケーションロジックが中間層に存在し、リモーティングされる静的メソッドとしてクライアントに公開される。これについて詳細は後述する。
２．暗黙的ＣＤＰサービス呼び出しリモーティング：FindAll()、FindOne()、SaveChanges()のようなＣＤＰＡＰＩ呼び出しはリモーティングエージェントおよびリモーティングサービスコンポーネント経由で暗黙的に中間層に送られる。このアーキテクチャについては後述する。また、後のセクションには、これがどのように動作するかを説明する例がある。
３．明示的な非連結リモーティング：ＣＤＰＡＰＩは、層間オペレーションがいつ起こるべきかをアプリケーションが明示的に定義するためのプログラミングパターンを定義する。このオペレーションの結果としてデータ取得がなされる場合、取得されたデータはクライアント層にキャッシュされる。このパターンは通常、「非連結モード（disconnected mode）」（後述）と呼ばれる。

特に、図１４および図１５は、中間層で動作するアプリケーションロジック（例えばウェブサービス）を示している。中間層デプロイメントの主要な事例は、アプリケーションロジックが中間層で明示的に動作する場合である。その場合、クライアント１４０６は、ウェブサービスメカニズム（例えばウェブサービスプロキシ１４０８およびウェブサービス１４１０）を通じてこのロジックを呼び出す。理解されるように、サーバー層のセキュリティエンジンは中間層ＣＤＰプロセスにホスティングされることが可能である。２層デプロイメントでは、ＣＤＰ呼び出しはクライアントプロセス内のＣＤＰランタイム１４０２によって処理され、ランタイムは必要な時にサーバーと連絡をとる。３層デプロイメントでは、一部のＣＤＰ呼び出しは（クライアント層経由で）ローカルに処理され、一部は（中間層経由で）リモートに処理される。また、それ以外は両方の場所で処理されることが可能である。３層デプロイメントは、適当な呼び出しをリモーティングするための方法を定義する。

クライアント層のリモーティングエージェント１４１４は、チャネル（例えばＩｎｄｉｇｏ）を用いて要求をパッケージングし中間層のＣＤＰへ送ることができるコンポーネントである（これはリモートプロシジャコールの実際の作用である）。中間層にはリモーティングサービス１４１６（図１５に示す）がある。リモーティングサービス１４１６は適宜、これらの要求に対するサービスを提供する。このパターンは、一般にサービス指向アーキテクチャ（ＳＯＡ）として知られているものの一部である。ＳＯＡの特徴は、異なる層がメッセージを交換することにより相互に通信することである。ＣＤＰはこの目的のためにＩｎｄｉｇｏインフラストラクチャを利用することができる。

リモーティングサービスは、「クエリの実行（execute a query）」、「挿入（insert）」、「削除（delete）」、「更新（update）」、「新規作成（create）」、「保存（save）」、「与えられたキーに対するオブジェクトを取得（get an Object given the key）」、「ルートキーを取得（get the root key）」のような、データ指向サービスのセットを提供する。ＳＯＡパラダイムに従い、これらのオペレーションはＳＯＡＰメッセージ内の動詞となり得る。クライアント層が中間層で実行させたい任意のアクションはこれらの簡単な動詞を用いて表現される。これらの基本的なメッセージング動詞は、Ｉｎｄｉｇｏによって提供されるファシリティを用いた２つのインタフェースに対するメソッドに抽象化される。つまりそれは上記のIPersistおよびIQueryインタフェースである。こうして、リモーティングエージェント１４１４およびリモーティングサービス１４１６はともに、IPersistおよびIQueryインタフェースのメソッドをリモーティングするためのＩｎｄｉｇｏチャネル上のエンドポイントとして作用する。認識され理解されるように、IPersistおよびIQueryインタフェース内のメソッドは次の意味で「きめが粗い（coarse-grained）」のである：すなわち、これらのメソッドは、大規模なオブジェクトのセットに対してクエリあるいは操作を行うために使用可能である。例えば、SaveChanges()メソッドに応じて、リモーティングエージェント１４１４は、変更されたオブジェクトのセット全体について、リモーティングサービス１４１６へIPersist.Write()を１回発行する。したがって、クライアントと中間層の間のインタフェースはバルク指向（bulk-oriented）であり、チャット的ではない。

メソッド呼び出しに応じて、図１４および図１５に示した種々のモジュール間で行われるデータ／制御フローを調べるために、次の擬似コード例を用いることができる。認識され理解されるように、以下は一例であり、本アーキテクチャはこれに限定されない。

1. WinFSData wd =
new WinFSData(@"＼＼CorpSvr01\SharedSchedule＼AnilNori"))
2. ScheduleEntry s = wd.Items.FilterByType<ScheduleEntry>().Filter(
"StartTime > @0", new DateTime(xxxx, 10, 29, 9, 0, 0)).GetFirst();
3. s.DisplayName = s.DisplayName + "[important, please come!]";
4. ScheduleService ss = new Scheduleservice(wd);

/* public bool CreateAppointment(ScheduleEntry appointment,
* string path)*/
5. if (ss.CreateAppointment(s, @"＼＼CorpSvr01＼SharedSchedule＼PCelis"))
6. {
7. Console.WriteLine("Appointment created!")；
8. }

この例において、アプリケーションは、企業イントラネット上のＡｎｉｌＮｏｒｉ(アニール・ノリ)にクエリを行うことにより、ｘｘｘｘ年１０月２９日午前９時に対する彼のカレンダエントリを取得する。これは、ScheduleEntryオブジェクトによって表されており、ScheduleEntryオブジェクトはEntityから派生した型(type)である（例えば、ScheduleEntryはＰＩＭスキーマの一部であり、ユーザのスケジュール内のアイテムを表す）。アプリケーションはScheduleEntryを変更する。すなわち、アポイントメントのタイトルにテキスト「[important, please come!]」を付加する。次に、（ScheduleServiceという）ウェブサービスのCreateAppointmentメソッドを呼び出して、この変更したScheduleEntryをＰｅｄｒｏＣｅｌｉｓ(ペドロ・チェリズ)の共有カレンダに入れる。このコードフラグメントは、３層デプロイメントにおける次のようないくつかのキーポイントを例示している：

１．クライアントはローカルＣＤＰランタイムを用いてストアエンティティに対するクエリを行う。クエリは中間層で実行される。

２．クエリ結果はクライアント層のＣＤＰのセッションキャッシュに入る。

「アプリケーションロジック」全体（ビジネスロジック、妥当性検査等を含む）は、ウェブサービスによって、およびＣＤＰのＢＬホスティングエンジンによって、中間層で実行される。この処理は、CreateAppointment()メソッドへの呼び出しによってトリガされる。以下、種々のモジュール間でのデータフローを詳細に検討する。

第１行：ストレージコンテクストの作成。StorageContextオブジェクト（例えばクライアント層のＡＰＩ１４１８）はDataオブジェクトによってカプセル化され、Dataオブジェクトはアプリケーションおよび／またはクライアント１４０６によって作成される。Dataクラスは、ＣＤＭスキーマに記述されたテーブルセット型を表す。Dataオブジェクトは、ストア１４０４と対話するように必要に応じて構成されるStorageContextオブジェクトを作成する。StorageContextの初期化コードは、クライアント層のＣＤＰランタイム１４０２の一部である。

第２行：クエリ。第２行の式の右辺はＯＰａｔｈクエリである。このクエリは、高々１つのScheduleEntryオブジェクト、すなわち、１０／２９／０４、９ＡＭの最初のエントリ（例えば、「最初のエントリ」の厳密な定義が存在すると仮定する）を返す。クライアント層のＣＤＰランタイム１４０２は、リモーティングエージェント１４１４に対するIQueryインタフェースを取得し、それに対してExecuteQuery(<Opath>)を呼び出す。リモーティングエージェント１４１４は、Ｉｎｄｉｇｏチャネルを利用することができ、このクエリを中間層のリモーティングサービス１４１６に送る。クエリは、２層の場合と全く同様にマッピングされて実行され、結果がクライアント層に返される。ここで２つの可能性がある：

１．生のＴＤＳ結果が、オブジェクトをハイドレートせずに中間層からクライアント層に返される。その場合、クライアント層のＣＤＰランタイム１４０２がオブジェクトをハイドレートする。
２．これらのオブジェクトがオブジェクトキャッシュ４１４に既に存在する場合、ハイドレートされたオブジェクトがクライアント層に返される。
理解されるように、ＯＰａｔｈクエリ全体がＩｎｄｉｇｏチャネル越しに送信される。例えば、クエリが「型ScheduleEntryの全オブジェクトを検索」（すなわち、FindAll()メソッド呼び出し）である場合、このクエリ全体が１つのＳＯＡＰメッセージで（中間層のリモーティングサービス１４１６へ）送信されるのであって、オブジェクトごとに１つのメッセージが送信されるのではない。

第３行：クライアント層オブジェクトキャッシュの操作。ScheduleEntryオブジェクトがクライアント層に返されると、クライアント層のＣＤＰランタイム１４０２のセッションキャッシュ内でさらなる操作が可能である。クライアント１４１６がScheduleEntryオブジェクトのDisplayNameプロパティを変更する場合、これはクライアント層のＣＤＰランタイム１４０２によって全面的に処理される。

第４行：クライアント層のウェブサービスプロキシの新規作成（ｎｅｗ）。おそらく、クライアント１４０６は設計時に既に適当なａｓｍｘ（またはＩｎｄｉｇｏでの等価物）への参照を追加していると考えられる。第４行は、クライアント上にウェブサービスプロキシオブジェクトのインスタンスを作成できる。この呼び出しは、ウェブサービスプロキシ１４０８によって全面的にサービスされる。

第５行：ウェブサービスメソッドの呼び出し。CreateAppointment()は、中間層のウェブサービス１４１０によってリモーティングされるメソッドの１つである。このメソッドは、ScheduleEntryオブジェクトおよびＣＤＰコネクション文字列を受け取る。このメソッドは、この情報を用いて、コネクション文字列によって定義されるStorageContext内にScheduleEntryオブジェクトを作成する。この書き込み操作において本質的なことは、適当なビジネスロジックおよび妥当性検査ロジックの実行である。このメソッドは、ウェブサービスプロキシ１４０８によってパッケージングされ、ＳＯＡＰメッセージを用いてＩｎｄｉｇｏチャネル経由で中間層のウェブサービス１４１０に送られる。ウェブサービス１４１０は、このメソッドを、それがあたかも他のアプリケーションであるかのように、中間層のＣＤＰＡＰＩ１４２０への呼び出しを通じて実施する。ここで注意すべき重要なことは、CreateAppointment()のロジック全体が中間層で実行されることである。

図１６および図１７は、クライアント層および中間層の両方で動作するアプリケーションロジックの図である。メソッド呼び出しに応じてさまざまなコンポーネントおよび層を通るデータ／制御フローについて、一例を用いてさらに詳細に説明することができる。以下の例は、上記の例と類似している。

1. void AddToCart(String customerId, String productId)
2. {
3. using (OrderData od = new OrderData())
4. {
5. ShoppingCart cart = od.ShoppingCarts.Searcher.Filter(
6. "CustomerId={0}", customerId).GetFirst();
7. if(cart = null)
8. throw new Exception("No shopping cart");
9. Product product = od.Products.Searcher.Filter(
10. "ProductId={0}", productId).GetFirst();
11. if(product == null) throw new Exception("Missing product");
12. cart.Products.Add(product);
13. od.SaveChanges();
14. }
15. }
16.

前の例で理解されるように、第３行はストレージコンテクストを作成し、第５行および第９行はクエリに関係し、第１２行は更新に関係する。

第１３行：変更のフラッシュ（一気書出し）。以下の２つの可能性を考える：

１．ＢＬがクライアント層および中間層の両方で実行される場合：この場合、クライアント層のビジネスロジックホスト４１６が、妥当性検査および事前保存ロジックを実行し、IPersist.Write(<change vector>)を用いてクライアント層のリモーティングエージェント１４１４を呼び出す。リモーティングエージェント１４１４は、この呼び出しを中間層のリモーティングサービス１４１６（図１７に示す）に送る。リモーティングサービス１４１６は、中間層のオブジェクトキャッシュ４１４を変更し、SaveChanges()を呼び出す。これは前述のＢＬおよび永続化ステップを実行し、リモーティングサービス１４１６に復帰する。この場合、リモーティングサービス１４１６はクライアント層のリモーティングエージェント１４１４に復帰し、続いてリモーティングエージェント１４１４はビジネスロジックホスティング４１６に復帰する。クライアント側の事後保存ロジックは、ビジネスロジックホスティング４１６によって実行されない可能性がある。

２．ＢＬが中間層のみで実行される場合。この場合、ビジネスロジックホスティング４１６は呼び出しを直接リモーティングエージェント１４１４に渡し、リモーティングエージェント１４１４はさらにそれをリモートサービス１４１６に送る。処理は上記のように中間層で行われる。

両方の層でＢＬを実行することの１つの利点として、事前保存ロジックの妥当性検査においてエラーがあった場合、そうしたエラーは、中間層に接続するという代償を払うことを必要とせずに、クライアント層でトラップ（閉じ込め）することができる。

シームレスなオフラインのエクスペリエンスは、データベース型ファイルストレージの目標の１つである。これは、リモートストアとデータを同期させるローカルストア１６０２を必要とすることがある。また、ローカルストア１６０２は、制約／セキュリティ１６０４を含み得る。この場合、ローカルストア１６０２は、実質上同様のマシン上にあるが、異なるプロセス内にある（これは、本明細書の定義では、やはり２層デプロイメントである）。３層および２層デプロイメントに対するプログラミングモデルは対称的なので、同期のようなサービスがローカルストア１６０２と中間層の間で動作してデータを同期した状態に保つことは容易である。

上に示したコード例の第２行を考える。クエリの結果、層間オペレーションが生じる。この具体例では、１つのオブジェクト（ScheduleEntryオブジェクト）が返される。しかし、一般には、これは非常に大きい結果セットを返す可能性がある。同様の注釈が、前に提示したコード例の第５行にも当てはまる。考え得る２つの問題点があり、それらは３層デプロイメントに関連する：

・層間オペレーションは高価になり得るので、暗黙的には起こらないこと：これが層間オペレーションを引き起こすという明示的な指示が第２行にはない。すなわち、「マジック」が含まれている。ここで「マジック」という用語は、何かが起こる際にアプリケーションがそれについて知らないか、またはその発生を制御する能力がないという意味で用いられる。多くの場合、マジックは有益である。実際、多くのソフトウェアの目標は、基礎にある複雑さを隠蔽し、「マジック（魔法）であるかのように」物事を引き起こすことである。しかし、本具体例の場合、これまでの長い経験から、アプリケーション作成者は長大なクエリを行き当たりばったりに送信することが分かっている。そのようにしても、基礎となるコードは、ネットワークの流れを詰まらせたりサーバーにストレスを加えたりすることなく、大量のデータをどうにか返してくれると決め込んでいるのである。層間オペレーションのマジックをアプリケーションにとって明示的にすることにより、適切なコーディングの実践を奨励することが、確実な設計パラダイム（模範）である（〈百万行のテーブル〉からの「ｓｅｌｅｃｔ＊」が必要か。必要でないならおそらくＷＨＥＲＥ節が使える）。

・クライアント側キャッシングおよびステートレスな（処理状態を把握しない）オペレーション：適切なコーディングの試みにもかかわらず、アプリケーションが（大きい可能性のある）データセットを扱うことを必要とすることがある。そして、アプリケーションはこのデータセットが何であるかを知っていることが多い。このような場合のデータアクセスを最適化するため、アプリケーションは、クエリを実行し、（大きい可能性のある）データセットをフェッチ（所得）し、それをローカルにキャッシュに入れる能力を有するべきである。さらなるクエリ／ソーティング／フィルタリング／変更は、データのローカルコピーに対してなされる。最後に、フラッシュ操作により変更をストアに書き戻す。ローカルキャッシュに対する動作は、中間層が最小限の状態しか保持しないこと（または状態を全く保持しないこと）ことで、よりスケーラブル（拡張可能）になることを意味する。

解決手段は、明示的な非連結モデルを提供することである。これは以下のパターンによって特徴づけられる：

１．アプリケーションは、次のようにしてローカルキャッシュをインスタンス化する：

LocalContext lc = new LocalContext();

２．ローカルキャッシュは、次のように指定される１つまたは複数のクエリの結果を含むことになる：
lc.QueryCollection.Add("<query1>");
lc.QueryCollection.Add("<query2>");
// etc.

３．アプリケーションがローカルコンテクストを「フィル（fill）」する：
lc.Fill();

４．アプリケーションは、ストレージコンテクストに対してと全く同様に、ローカルコンテクストに対して作用する。例：
ScheduleEntry s =
lc.Entities.FilterByType<ScheduleEntry>().Filter(
"StartTime > @0", new DateTime(
2004, 10, 29, 9, 0, 0)).GetFirst();
s.DisplayName = s.DisplayName + "[important, please come!]";

５．最後に、アプリケーションは、下記に指定するように、変更を一括してストアに送る：
// sc は StorageContext
lc.SaveChanges(sc);

アプリケーションが層間オペレーションを行いたい時にどのように明示的になり得るか（ステップ３のlc.Fill()）に留意されたい。これにより、責任のないコードによってトリガされるマジックはなくなる。また、すべての後続のオペレーションをローカルキャッシュに対して行うことができるため、層間オペレーションが最小限となる（それに伴い中間層の状態も維持される）ことにも留意されたい。理解されるように、上記のコードフラグメントによって含意されるモデルは、ＡＤＯ．ＮＥＴにおけるデータセットモデルに極めて類似している。ＣＤＰもまた非連結モデルを提供することができる。

２層アプリケーションは、次のいずれかが真でなければ、３層環境にデプロイすべきではない：（ａ）アプリケーションが非連結型のプログラミングモデルのみを使用する、または（ｂ）非連結型のプログラミングモデルを使用するようにアプリケーションを書き換える。

ＣＤＰは、３層デプロイメントにおいて、接続型および非連結型の両方のプログラミングモデルを可能にする手法をとる。アプリケーションには、「３層環境にデプロイされると予想するなら、非連結キャッシュを使うべきである」というガイドラインが与えられる。

ＣＤＰストアを説明する次のセクションの背景を明らかにするため、ＳＱＬサーバーデータの全体がインスタンス、データベース、スキーマ、およびテーブルという４レベルの階層に分かれることに注意する。接続可能なユニットはインスタンスである。データベースは、それに対してバックアップ（予備）、リストア（復元）、およびレプリケーション（複製）が定義されるコンテナである。データベースとスキーマの組合せがクエリに対するコンテクストを提供する。ＣＤＰは、ストア、スキーマ、および型という３レベルの階層を使用する。ＣＤＰストアは接続可能ユニットであり、スキーマはクエリに対するコンテクストを提供する。与えられたスキーマが、複数のＣＤＰストアによってホスティング（提供）される可能性がある（例えば、型のセット（ＣＲＭスキーマ）がＣＤＰの２つの異なるインスタンス上にデプロイされることが可能である）。「同一性」が必要な場合、ＣＤＰの外部のメカニズム（レプリケーション、バルクコピー）を用いるべきである。与えられたＣＤＰストアが、その上にデプロイされた複数のスキーマ（例えばＨＲスキーマ、経理スキーマ等）を有する可能性がある。

以下、名前付けおよび発見（ディスカバリ）について説明する。上記で説明した、次のコードの第３行を考える。

Using (StorageContext sc =
new StorageContext(@＼＼corp001＼defaultstore))

ＣＤＰストアの名前付けおよび利用可能なストアの発見は次のように解決される。ＣＤＰストアをより明確に定義すると、次の２つの可能性がある：

１．ＣＤＰストアは現実の物理ストア、すなわち、現実のサーバー上のデータベースである。
２．ＣＤＰストアは論理ストアである。ctorへの引数がエンティティインスタンスの論理コンテナを識別する。実際にはこれは、複製された物理ストアのファームとしてデプロイされる可能性があり、フロントエンドサーバーがロードバランサ(負荷平衡部)と協働して、この特定のセッションに対するコンテクストを形成する実際の物理ストアを選ぶ。

ＣＤＰモデルでは、ストレージコンテクストは、物理ストアではなく論理ストアを識別する。ＣＤＰは、レプリケーション、バックアップ／リストアのメカニズムが物理ストアのレベルでどのように働くかを指定しない。

ctor引数のフォーマットに関して、コネクション文字列はＵＲＩ（Uniform Resource Identifier）である。個別のフレームワークがそれぞれのアプリケーション用の代替的名前付けフォーマットを定義できる。例えば、ＵＡＦは、ＵＮＣ名（例えば\\server\share）を指定することにより、自己のアプリケーションにストレージコンテクストを設定させることを選択するかもしれない。しかし、ＵＲＩによってＣＤＰストアに接続することは常に可能とすべきである。すなわち、フレームワークによって用いられるいかなる代替名も、対応するＣＤＰレベルのＵＲＩへの明確なマッピングを有していなければならない。

ＣＤＰは、ストアをどのようにして発見できるかを指定しない。この目的のためにアプリケーションは既存のメカニズムおよびリポジトリ（例えばＵＤＤＩ（Universal Description, Discovery and Integration））を用いることができると期待されている。また、フレームワークが発見のための固有のメソッドを指定してもよい。

このセクションでは、アプリケーションが活用できるその他のＣＤＰサービスを説明する。このようなサービスには次のものがある：

・ウォッチャ(Watcher)／通知サービス
・同期サービス
・明示的キャッシュサービス
・ユーティリティオペレーション
このセクションは、説明的とみなすべきであり、体系的とみなすべきでない。

ウォッチャ／通知サービス。通知（ウォッチャともいう）は、基礎となるストアに永続化されたエンティティ（データ）への変更の非同期通知を発生する能力を提供する。アプリケーション（または他の任意のコンポーネント）がこのサービスを用いて、永続化されたエンティティにおける変更をウォッチすることができる。アプリケーションは、何をウォッチするか、およびどのくらいの頻度で通知してほしいかを完全に制御できる。例えば、リッチアプリケーションビュー（ＲＡＶ）通知がウォッチャを用いて構築される。クライアント側ブラウジングアプリケーションは、ＲＡＶを用いることにより、これらの通知を用いてデータ変更にアクティブに反応することができる。

ＣＤＰプログラミングモデルは、エンティティにおける変更をウォッチすることが可能なWatcherクラスをサポートする。エンティティウォッチャメカニズムは、フレームワークおよびアプリケーションがより高いレベルのウォッチャ抽象化を構築するのに十分である。例えば、データベース型ファイルストレージシステムは、エンティティウォッチャ抽象化の上にアイテム、アイテムエクステンション、およびリンクのウォッチャ抽象化を構築できる（例えば、エンティティは、ウォッチされることが可能な最も粒度の細かいデータ単位であることに留意されたい）。

同期サービス。ＣＤＰおよびその上のフレームワークに対して書かれたアプリケーションは、以下の同期関連サービスから恩恵を受ける：

１）変更追跡のためのスキーマアノテーション。スキーマ設計者は、エンティティ型に対する変更ユニット境界を指定することができる。変更ユニットの指定は、変更追跡サービスの機能を制御する。
２）変更追跡。これは、アプリケーションから概ね不可視の状態で、すべてのＣＤＰオペレーションの間の変更ユニットのバージョンと、エンティティ削除のようなクリティカル(重大)なオペレーションのログとを維持管理する。変更追跡は、レガシーアプリケーションが引き続きＣＤＰランタイムをバイパスして変更を行う場合であっても正しく機能する。
３）変更列挙。これにより、ＣＤＰアプリケーションは、ある特定のウォーターマーク以降に変更されたエンティティおよびその変更ユニットのセットを取得することが可能となる。変更は、ＣＤＰエンティティおよび行セット（RowSet）として返される。障害、バックアップおよびリストア、ならびに複雑な同期トポロジーに際してウォーターマークを維持管理するためのサービスのセットが提供される。
４）コンフリクト検出。これにより、ＣＤＰアプリケーションは、ＣＤＰオペレーション（例えば更新）が、既に実行されたオペレーションと衝突するかどうかを判断することが可能となる（これもウォーターマークに基づく）。
この中心的機能を用いて、フレームワークは付加的な、より高レベルの同期サービスを構築することが可能である。

明示的キャッシュサービス。ＣＤＰにおける明示的キャッシュサービスは、アプリケーションのパフォーマンス／スケーラビリティの改善、非連結型プログラミングモデルのサポート（例えば、非連結型プログラミングモデルはフル機能の明示的キャッシュの利益なしで実装可能であることに留意されたい）、および一時データのサポートを提供する。明示的キャッシュの特徴として以下のことが挙げられる：

・多様な種類のデータ（例えばエンティティ、非構造化データ、およびＸＭＬデータ）のキャッシュ
・多様なキャッシュアクセスモード（例えば読み出し専用、読み書き、共有等）
・保存されているデータとの（例えばＳＱＬサーバーに保存されたデータに対する）キャッシュコヒーレンシ
・アプリケーションフェイルオーバーのための複数のＣＤＰキャッシュ間のキャッシュ（ある種のデータ、例えばセッションコンテクストデータ）のコヒーレンシ

明示的キャッシュに対するプログラミングサーフェスは次のものを公開することができる：
・キャッシュの作成
・キャッシュのポピュレート（データ投入）
・基礎となるストアへの（データの一部の）キャッシュの永続化
・キャッシュされたデータに対するクエリおよび更新

ユーティリティオペレーション。ＣＤＰは、エンティティおよびエンティティのコレクションに対するさまざまな管理オペレーションおよびユーティリティオペレーションのサポートを提供する。このようなオペレーションの例としては、コピー、移動、シリアライズ／デシリアライズ、およびバックアップ／リストアがある。

次に図１８を参照して、エンティティを利用するアイテムのモデリングについて説明する。データベース型ファイルストレージシステム（例えばＷＩＮＦＳ）の実装は、ＣＤＰおよびユーザアプリケーションフレームワーク（ＵＡＦ）の両方の側面を包含する。なお、ＣＤＰアーキテクチャは、データベース型ファイルストレージシステムの書き換えを意味しているのではなく、単にその内部のコンポーネントの区分のし直しを意味している。

このセクションでは、ＵＡＦを定義した後、データベース型ファイルストレージシステムの種々のコンポーネントをＵＡＦとＣＤＰにどのように区分できるかについて検討する。

ＵＡＦは、「ユーザ」データのモデリングに関係するＣＤＰフレームワークである。ユーザデータとは、ドキュメント、写真、音楽、連絡先等のような、通常のエンドユーザに関係する普通の日常的データを意味する。

基本的なＣＤＰインフラストラクチャに対して、ＵＡＦは以下のものを追加する：

・基本アイテム型（および関連する型）
・ユーザデータをモデリングするための実際の型
・有効期間管理、包含等のような制約
・ユーザがアイテムを用いて実行可能なこと：移動、コピー、名前変更、シリアライズ、...
・アイテムに対する組織的コンストラクト：コンテナ、リスト、オートリスト（autolist:自動的に補完リストを表示する）、アノテーション(注釈)、カテゴリ
・（ルール作成等の）アイテムに対するエンドユーザプログラミング抽象化
認識され理解されるように、アプリケーション開発者にとって、ＣＤＰはＵＡＦプログラミングモデルである。

具体的には、図１８は、ＵＡＦ内のアイテムの概念およびそれがいくつかのエンティティから実際にどのように派生されるかを示している。ドキュメントアイテム１８０２は、いくつかのエンティティ、例えば、以下のものに限定されないが、ドキュメント１８０４、複数のリンク１８０６およびドキュメントエクステンション１８０８、から派生可能である。作成者（author）アイテム１８１０は、いくつかのエンティティ、例えば、以下のものに限定されないが、作成者１８１２、および作成者エクステンション(拡張子)１８１４、から派生可能である。

次に図１９を参照して、ＣＤＰの上にＵＡＦを実装することにより種々の機能を実装するための拡張可能なメカニズムについて説明する。ＵＡＦは、ＣＤＰの上に構築されるので、ＣＤＰの拡張可能性メカニズムを利用して追加機能を実装することができる。ＣＤＰ上のＵＡＦの構築は、種々のレイヤおよび／またはコンポーネントを含み得る。ストア１９０２は、ＣＤＰ制約エンジン１９０４を含み得る。ここで、ＣＤＰ制約エンジン１９０４は少なくとも１つのＵＡＦ制約１９０６を含む。ＣＤＰランタイム１９０８はＢＬホスト１９１２を含むことができ、ＢＬホスト１９１２はＵＡＦアイテム挙動１９１０を含むことができる。さらに、ＵＡＦアイテム挙動１９１０はＵＡＦバインド可能挙動１９１４を含み得る。ＣＤＰランタイム１９０８の上には、任意の他のＵＡＦサービス１９１６が存在し得る。

ＵＡＦは、ＣＤＰの制約エンジンを用いて、アイテムセマンティクス（および他の型セマンティクス）を強制する。これらはＣＳＤＬを用いて作成され、スキーマジェネレータがそれらに対するストアレベルの制約を作成する。移動、シリアライズ等のようなアイテム挙動がＣＤＰのＢＬメカニズムを用いて実装される。ＵＡＦ型は、それらに関連するバインド可能挙動を有し得る。これらの挙動は、型が設計されデプロイされた後、ＵＡＦアプリケーション開発者によって作成される。同期、メタデータ処理等のような他のＵＡＦサービスは、通常のＣＤＰコードとして実装される。全体として、これらの個別のロジックがＣＤＰの種々のレイヤで動作してＵＡＦを形成する。

以下の説明は、ＣＤＰとＵＡＦの間でのデータベース型ファイルストレージシステムの分割に当てはまる。データベース型ファイルストレージシステムにおける以下の機能はＣＤＰレイヤに属する：

１．Ｏ−Ｒマッピング、すなわち、エンティティからテーブルへのマッピング。ＣＤＰは、ＰＯＣＯ事例およびデータベース型ファイルストレージシステムサーバー事例を扱うための非規範的（non-prescriptive）マッピングをサポートする。また、これは更新マッピングも含み、エンティティ（および派生）型に対する基本的なＣＵＤオペレーションを提供する。
２．ＯＰａｔｈクエリマッピング
３．エンティティおよび他のＣＤＭコア型の実装
４．StorageContextおよびStorageSearcher（セッションおよびトランザクションの管理とともに）
５．セッションキャッシュ、キャッシュフラッシュロジック（SaveChanges）
６．変更追跡
７．エンティティ型に対するウォッチャ
８．カーソルサービス（ＲＡＶを含む）
９．アイテムレベルのセキュリティ強制メカニズム（行レベルセキュリティ、型ビューに含まれるセキュリティプレディケート）

データベース型ファイルストレージシステムにおける以下の機能はＵＡＦレイヤに属する：
１．バインド可能な、インスタンス単位の挙動
２．データベース型ファイルストレージシステムＡＰＩメタデータ（ＣＬＲメタデータとして表現されるクライアントクラスおよび挙動）
３．アイテムレベルのメソッド（コピー、移動、シリアライズ、名前変更）
４．同期、同期スコープ、変更列挙
５．コンテナに対するウォッチャ
６．効率的なパス名計算およびアイテムドメインのためのパステーブル
７．メタデータハンドラ
８．データベース型ファイルストレージシステム名前空間
９．アイテム完全性を強制するためのコード（コンテナ、アイテムパート、リンク、ファイルストリーム、有効期間管理等）

図２０は、ＣＤＰ上に実装されるＬＯＢアプリケーションの一例を示している。以下で、ＬＯＢフレームワークの要件と、そうした要件をどのようにＣＤＰによってサポートできるかについて説明する。ビジネスフレームワークアプリケーションはＬＯＢアプリケーションとみなすことができる。ビジネスアプリケーションの中心的な機能のセットは、共有ビジネスコンポーネントとしてのパッケージである。これらのコンポーネントのグループが、財務における総勘定元帳からＣＲＭにおける営業支援システム（sales force automation）サービスに至るさまざまなビジネス機能を管理する。重要な特徴は、これらのコンポーネントがフェイスレス(特定化されない)で、拡張可能であり、どのレベルの機能および複雑さで利用されるかに応じて複数の市場の要求に応えるように利用可能なことである。

ビジネスフレームワーク（Business Framework: ＢＦ）は、ビジネスソリューションフレームワーク（Business Solutions Framework）およびビジネスアプリケーションフレームワーク（Business Application Framework）からなることが可能である。ビジネスソリューションフレームワークは、ほとんどのビジネスアプリケーションを構築するために有用な機能を提供する。これは、Money(金額)およびQuantity（数量）のような基本的なビジネスデータ型；顧客、事業部、為替情報および支払条件のようなアプリケーションファミリ規模のビジネスエンティティ；商取引および口座のような一般的なビジネスパターンを実装するための構築ブロック；ならびに商取引を記帳するため等の一般的なビジネスプロセスパターンを含む。

ソリューションフレームワーク（Solution Framework）は、ビジネスアプリケーションフレームワークを用いて書かれる。ビジネスアプリケーションフレームワークは、データアクセス、セキュリティ、ユーザインタフェース、ワークフロー、コンポーネントプログラミングモデルその他多くのことに対するリッチなサービスを提供することによって、コンポーネントを書くことをサポートする。ソリューションフレームワークによって定義されるビジネスモデルおよびルールがアプリケーションにとって適切でない場合には、それをバイパスすることができ、そのアプリケーションの開発者がアプリケーションフレームワークを直接使用することができる。

ビジネスアプリケーションフレームワークは、．ＮＥＴフレームワークに基づき、その機能をビジネスアプリケーションに集中させる規範的プログラミングモデルを提供する。ビジネスアプリケーションフレームワークは、極めて高い拡張可能性の一方で、システム内でそれを使用するすべてのアプリケーションに対し、より一般的なソリューションが実装および構造の生産性および一貫性を向上させることがないかどうかについて、アプリケーション開発者のためにいくつかの判断を行う。ビジネスアプリケーションフレームワークは、ウェブに基づく分散ＯＬＴＰ(オンライントランザクション処理)アプリケーションを書くためのプログラミングモデルおよびサービスを提供する。ビジネスアプリケーションフレームワークは、製品固有のビジネスロジックを含まなくてよいので、ビジネスアプリケーションだけでなく、その基本的なプロファイルに適合する任意の他のアプリケーションを作成するためも好適である。ビジネスアプリケーションフレームワークは、データアクセス、メッセージング（例えばＳＯＡＰ（Simple Object Access Protocol）およびその他のプロトコルの使用）、ワークフロー、イベント仲介、インスタンスアクティブ化、診断、コンフィグレーション(設定)、メタデータ管理（反映）、アプリケーションコンポーネントセキュリティ、グローバル化、ビジネスデスクシェル等のサポートを提供するサービスのセットを提供する。ＣＤＰに対する要求は主としてＢＦのビジネスアプリケーションフレームワーク部分、特にデータアクセスの領域およびデータロジックのリモーティングの領域に由来する。

エンティティ永続化（ＥＰ）は、ビジネスフレームワーク内のデータアクセスサブシステムであり、実用的なオブジェクトリレーショナルマッピングフレームワークに基づくリッチなデータモデルをサポートする。これは、開発者が、関係行にマッピングされる（Ｃ＃の）オブジェクトを扱うという意味でオブジェクトリレーショナルである。中心的なデータモデリング概念は、エンティティおよびエンティティ間のリレーションシップ(関係)である。共通データモデル（ＣＤＭ）が、ＢＦデータアクセスのデータモデリング要求を本質的にサポートする。ＭＢＦＥＰは、以下のデータアクセスアクションに対するサポートを要求する：

・エンティティの作成、読み出し、更新および削除
・データセットを返すアドホッククエリ(任意問合せ)
・データベースで実行される集合系演算（set-based operation）

ＢＦは、分散的なサービス指向構成をサポートするためのエージェント／サービスフレームワークを規定する。いくつかのビジネス機能が与えられると、エージェントはその機能のユーザのできるだけ近くで動作し、サービスはデータのできるだけ近くで動作する。「できるだけ近く」は、各デプロイメント事例およびユーザの種類によって異なる。エージェント／サービスパターンは、２層（クライアント・サーバー）デプロイメントから多層デプロイメントに至るデプロイメントフレキシビリティを提供する。このようなデプロイメントにおいて、サービスは、サービス境界を越えて呼び出し可能なインタフェースを提供する。エージェントは通常、クライアント（ユーザ）に近いデータをフェッチし、それに対して作用し、変更をサービスに伝える。

特に、図２０は、ＬＯＢフレームワークおよび／またはアプリケーションがどのようにＣＤＰを利用することができるかを例示している。フレームワーク、およびフレームワークを利用して構築されたアプリケーションは、中間層のウルトラアプリケーションサーバー２００２にホスティング可能である。ウルトラアプリケーションサーバー２００２は、標準的なＬＯＢサービス、例えば、以下のものに限定されないが、ワークフロー、メッセージング、ビジネスプロセス等を、クライアントアプリケーション２００４へのウェブサービスインタフェースの形で提供できる。ウルトラアプリケーションサーバー２００２は、ＣＤＰを利用することにより、ストア制約２００６（ＣＤＰ制約エンジン２０１４経由で）およびデータ中心ビジネスロジック２００８を作成することができる。クライアントアプリケーション２００４は、Ｉｎｄｉｇｏチャネルを通じて（例えばウェブサービスプロキシ２０１０およびウェブサービスインタフェース２０１２を利用して）ウェブサービスメソッドを呼び出すことができる。さらに、クライアントアプリケーション２００４は、そのオブジェクト永続化／データアクセスの必要に応じて、クライアント層のＣＤＰを利用することができる。

ＣＤＰによって以下のことが満たされる：１）セッション管理；２）ＣＲＵＤ；３）共通データモデル（ＣＤＭ）サポート（例えばエンティティ抽象化、エンティティ拡張）；４）クエリ（例えばアドホック、エンティティ）；５）ランニングオブジェクトキャッシュ（暗黙的）；６）並行処理管理（例えば楽観的、孤立レベル、コンフリクト(衝突)検出等）；７）ビジネスロジック（例えばメソッド内、妥当性検査／デフォルト処理、プロパティパターン、イベント）；８）セキュリティ拡張；９）プロバイダとのマッピング（クエリ、スキーマ）（例えばリレーショナル、データベース型ファイルストレージシステム）；１０）メタデータ拡張機能（エンティティの他のユーザをサポート）；１１）集合演算；１２）ストアドプロシジャ呼び出し機能；そして、１３）Ｎ層デプロイメント。

ＢＦエンティティ永続化はＣＤＰに自然に適合する。ＢＦの永続化要求のほとんどはＣＤＰによって完全にサポートされる。一部のＳＯＡ要求もまたＣＤＰにより解決される。しかし、エージェント／サービスモデル、ＢＦビジネスオペレーションおよびプロセスに対する完全なサポートは、ＬＯＢフレームワークとしてＣＤＰの上に構築することができる。ＭＢＦのビジネスソリューションフレームワークもまたＣＤＰの上に階層化される。

図２１および図２２は、本発明による方法論（methodology）を示している。説明を簡単にするため、本方法論は一連のアクト(行為)として図示され説明される。理解され認識されるように、本発明は、例示されているアクトおよび／またはアクトの順序によって限定されない。例えば、アクトは、本明細書に記載されていない他のアクトとともに、さまざまな順序で、および／または並行して生起し得る。さらに、本発明による方法を実施するために、例示されたすべてのアクトが必須とは限らない。また、当業者には理解され認識されるように、本方法は、別法として、状態図やイベントにより、相互に関係する一連の状態として表現することも可能である。

図２１は、ＣＤＰの種々のコンポーネント内のデータフローの管理を容易にする方法２１００を示している。参照符号２１０２で、アプリケーションが注文データオブジェクトを作成する。注文データクラスは、ＣＤＭスキーマに記述されたテーブルセット型を表すことができる。注文データオブジェクトは、ストアと対話するために必要に応じて構成可能なストレージコンテクストオブジェクトを作成する。参照符号２１０４で、セッションを開始しトランザクションコンテクストを作成することにより、ストアへのコネクションをオープンし、セキュリティコンテクストが確立される。参照符号２１０６で、ストレージコンテクストのインスタンスがアプリケーションに返される。

参照符号２１０８で、ＣＤＭクエリに基づいてオブジェクトを取得するためのインタフェースが公開される。参照符号２１１０で、セキュリティを正しく適用しつつクエリがＳＱＬにマッピングされる。また、アプリケーション／ユーザは、見ることを許可されているデータのみを見ることができる。参照符号２１１２で、クエリからの結果がＣＤＰランタイムに返され、アプリケーションに返される。参照符号２１１４で、変更をフラッシュするために、カプセル化されたストレージコンテクストオブジェクトに対して変更保存（save changes）ファンクションを呼び出すことができる。

図２２は、異なるアプリケーションが各フレームワークに関係し得るような複数の異なるフレームワークにわたるＣＤＰのデプロイを容易にする方法を示している。参照符号２２０２で、構造化、半構造化、および非構造化データを保存できるデータストアを作成する。参照符号２２０４で、ＣＤＰを作成しデータストアの上にオーバーレイする。続いて参照符号２２０６で、関連する相異なるアプリケーションを有する複数のフレームワークがデータストアにアクセスできる。参照符号２２０８で、相異なるフレームワーク上の相異なるアプリケーションに対して共有データが提供される。すなわち、データストア内のデータを、それぞれのフレームワークとは無関係に複数の異なるアプリケーション間で共有することができる。参照符号２２１０で、プライベートデータが、特定のフレームワーク上の特定のアプリケーション専用となるように、利用可能となる。

次に図２３を参照すると、本発明によるＣＤＰならびに関連するコンポーネントおよび／またはプロセスのアーキテクチャを実行するように動作可能なコンピュータのブロック図が示されている。本アーキテクチャの諸態様についてさらに前後関係を説明するため、図２３および以下の説明は、本発明の諸態様が実施され得る好適なコンピューティング環境２３００の簡単な概説を行うことを意図している。本アーキテクチャは、１つまたは複数のコンピュータ上で動作し得るコンピュータ実行可能命令との一般的関連で説明されるが、当業者には認識されるように、本アーキテクチャは、他のプログラムモジュールと組み合わせて、および／またはハードウェアとソフトウェアの組合せとしても実施可能である。

一般的に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造等を含む。さらに、当業者には理解されるように、本発明の方法は、シングルプロセッサ方式またはマルチプロセッサ方式のコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティング装置、マイクロプロセッサ方式またはプログラム可能型の消費者電子機器(家電機器)等の他のコンピュータシステム構成でも実施可能であり、これらはそれぞれ１つまたは複数の関連するデバイスに結合して動作可能である。

また、例示した諸態様は、通信ネットワークを通じてリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境でも実施され得る。分散コンピューティング環境では、プログラムモジュールはローカル(近隣)およびリモート(遠隔地)の両方のメモリ記憶装置に配置され得る。

コンピュータは通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータによりアクセスできる任意の利用可能な媒体であってよく、揮発性および不揮発性媒体、リムーバブル(取り外し可能）および非リムーバブル(取り外し不能)媒体の両方を含む。例として、限定ではないが、コンピュータ可読媒体はコンピュータ記憶媒体および通信媒体を含み得る。コンピュータ記憶媒体としては、揮発性および不揮発性、リムーバブルおよび非リムーバブルの媒体があり、コンピュータ可読命令、データ構造体、プログラムモジュール、または他のデータのような情報の記憶のための任意の方法あるいは技術で実現される。コンピュータ記憶媒体としては、以下のものに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ等のメモリ技術、ＣＤ−ＲＯＭ、ディジタルビデオディスク（ＤＶＤ）等の光ディスクストレージ(記憶装置)、磁気カセット、磁気テープ、磁気ディスクストレージ等の磁気記憶装置、または、所望の情報を格納するために使用可能でありコンピュータからアクセス可能な任意の他の媒体がある。

通信媒体は通常、キャリア波等の変調データ信号または他のトランスポート(転送)メカニズムでコンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを具現化し、いかなる情報配信媒体も含む。「変調データ信号」という用語は、信号中に情報を符号化するように１つまたは複数の信号の特性が設定または変更された信号を意味する。例として、限定ではないが、通信媒体としては、有線ネットワークまたは直接有線コネクションのような有線媒体、および音響、ＲＦ、赤外線等の無線媒体がある。上記のいずれかの組合せもまた、コンピュータ可読媒体の範囲内に含まれるべきである。

再び図２３を参照すると、諸態様を実施するための例示的環境２３００はコンピュータ２３０２を含む。コンピュータ２３０２は、処理ユニット２３０４、システムメモリ２３０６およびシステムバス２３０８を含む。システムバス２３０８は、システムメモリ２３０６を含む（ただしこれに限定されない）システムコンポーネントを処理ユニット２３０４に結合する。処理ユニット２３０４は種々の市販のプロセッサのいずれでもよい。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャもまた、処理ユニット２３０４として使用可能である。

システムバス２３０８は、さまざまな商用バスアーキテクチャのいずれかを用いたメモリバス（メモリコントローラの有無を問わない）、ペリフェラルバス、およびローカルバスとさらに相互接続され得る数種のバス構成のいずれでもよい。システムメモリ２３０６は、読み出し専用メモリ（ＲＯＭ）２３１０およびランダムアクセスメモリ（ＲＡＭ）２３１２を含む。基本入出力システム（ＢＩＯＳ）がＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ等の不揮発性メモリ２３１０に記憶され、このＢＩＯＳは、起動中等にコンピュータ２３０２内の要素間で情報を転送するために役立つ基本ルーチンを含む。ＲＡＭ２３１２は、データをキャッシュするためのスタティックＲＡＭのような高速ＲＡＭを含んでもよい。

コンピュータ２３０２はさらに、内蔵ハードディスクドライブ（ＨＤＤ）２３１４（例えばＥＩＤＥ、ＳＡＴＡ）（この内蔵ハードディスクドライブ２３１４は、外付け用に適当な筐体（図示せず）内に構成されてもよい）、磁気フロッピー（登録商標）ディスクドライブ（ＦＤＤ）２３１６（例えばリムーバブルディスケット２３１８の読み書きを行う）、および光ディスクドライブ２３２０（例えばＣＤ−ＲＯＭディスク２３２２の読み出し、またはＤＶＤ等の他の大容量光媒体の読み書きを行う）を含む。ハードディスクドライブ２３１４、磁気ディスクドライブ２３１６および光ディスクドライブ２３２０はそれぞれハードディスクドライブインタフェース２３２４、磁気ディスクドライブインタフェース２３２６および光ドライブインタフェース２３２８によってシステムバス２３０８に接続され得る。外付けドライブ実装のためのインタフェース２３２４は、ユニバーサルシリアルバス（ＵＳＢ）およびＩＥＥＥ１３９４インタフェース技術の少なくとも一方または両方を含む。他の外付けドライブ接続技術も考慮の範囲内である。

ドライブ(駆動装置)およびそれらに関連するコンピュータ可読媒体は、データ、データ構造、コンピュータ実行可能命令等の不揮発性ストレージを備える。コンピュータ２３０２のために、ドライブおよび媒体は、適当なディジタルフォーマットで任意のデータのストレージを備える。上記のコンピュータ可読媒体の説明はＨＤＤ、リムーバブル磁気ディスケット、およびＣＤやＤＶＤのようなリムーバブル光媒体について述べているが、当業者には理解されるように、ｚｉｐドライブ、磁気カセット、フラッシュメモリカード、カートリッジ等のような、コンピュータが読むことができる他の種類の媒体もまた、例示的オペレーティング環境において使用可能であり、さらに、任意のこのような媒体が、本アーキテクチャの方法を実行するためのコンピュータ実行可能命令を含んでもよい。

オペレーティングシステム２３３０、１つまたは複数のアプリケーションプログラム２３３２、他のプログラムモジュール２３３４およびプログラムデータ２３３６を含めて、複数のプログラムモジュールが、ドライブおよびＲＡＭ２３１２に記憶され得る。オペレーティングシステム、アプリケーション、モジュール、および／またはデータの全部または一部が、ＲＡＭ２３１２にキャッシュされてもよい。理解されるように、種々の商用オペレーティングシステムまたはオペレーティングシステムの組合せが本アーキテクチャとともに実施され得る。

ユーザは、キーボード２３３８およびポインティングデバイス（例えばマウス２３４０）等の１つまたは複数の有線／無線入力デバイスを通じてコンピュータ２３０２にコマンドおよび情報を入力できる。他の入力デバイス（図示せず）としては、マイクロフォン、ＩＲリモートコントロール、ジョイスティック、ゲームパッド、スタイラスペン、タッチスクリーン等が挙げられる。これらおよびその他の入力デバイスは、システムバス２３０８に結合した入力デバイスインタフェース２３４２を通じて処理ユニット２３０４に接続されることが多いが、パラレルポート、ＩＥＥＥ１３９４シリアルポート、ゲームポート、ＵＳＢポート、ＩＲインタフェース等のような他のインタフェースで接続されてもよい。

モニタ２３４４または他の種類の表示デバイスもまた、ビデオアダプタ２３４６のようなインタフェース経由でシステムバス２３０８に接続される。モニタ２３４４に加えて、コンピュータは通常、スピーカ、プリンタ等のような他の周辺出力デバイス（図示せず）を含む。

コンピュータ２３０２は、リモートコンピュータ（複数可）２３４８のような１つまたは複数のリモートコンピュータへの、有線および／または無線通信による論理コネクションを用いたネットワーク環境で動作してもよい。リモートコンピュータ（複数可）２３４８は、ワークステーション、サーバーコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサ方式の娯楽機器、ピアデバイスまたは他の一般的なネットワークノードであってよく、一般に、コンピュータ２３０２に関連して説明した要素の多くまたはすべてを含む。ただし、簡単のため、メモリ／ストレージデバイス２３５０のみが例示されている。図示されている論理コネクションは、ローカルエリアネットワーク（ＬＡＮ）２３５２、および／または広域ネットワーク（ＷＡＮ）２３５４等のさらに大規模なネットワークへの有線／無線接続を含む。このようなＬＡＮおよびＷＡＮネットワーキング環境は、事務所や会社で一般的であり、イントラネットのような企業規模のコンピュータネットワークを実現し、それらはすべて、インターネットのようなグローバル通信ネットワークに接続され得る。

ＬＡＮネットワーキング環境で使用される場合、コンピュータ２３０２は、有線および／または無線通信ネットワークインタフェース（アダプタ）２３５６を通じてローカルネットワーク２３５２に接続される。アダプタ２３５６は、ＬＡＮ２３５２との有線または無線通信を実現でき、無線アダプタ２３５６と通信するためにＬＡＮ２３５２上に配置された無線アクセスポイントを含んでもよい。

ＷＡＮネットワーキング環境で使用される場合、コンピュータ２３０２はモデム２３５８を含んでもよく、あるいは、ＷＡＮ２３５４上の通信サーバーに接続されるか、または、インターネットのようなＷＡＮ２３５４を通じて通信を確立するための他の手段を有する。モデム２３５８は、内蔵でも外付けでもよく、有線デバイスでも無線デバイスでもよいが、シリアルポートインタフェース２３４２経由でシステムバス２３０８に接続される。ネットワーク環境では、コンピュータ２３０２に関して図示されているプログラムモジュールまたはその一部が、リモートメモリ／ストレージデバイス２３５０に記憶され得る。理解されるように、図示されているネットワーク接続は例示であり、コンピュータ間で通信リンクを確立する他の手段を使用してもよい。

コンピュータ２３０２は、任意の無線デバイス、あるいは無線通信において動作可能に配置されたエンティティ（例えば、プリンタ、スキャナ、デスクトップおよび／またはポータブルコンピュータ、携帯情報端末、通信衛星、無線検知可能タグが設けられた任意の機器または場所（例えば、キオスク、新聞売店、化粧室）、および電話機）と通信するように動作可能である。これには、少なくともＷｉ−ＦｉおよびＢｌｕｅｔｏｏｔｈ（商標）無線技術が含まれる。したがって、通信は、従来型のネットワークと同様のあらかじめ定められた構成であってもよく、あるいは単に、少なくとも２つのデバイス間のアドホック通信であってもよい。

Ｗｉ−Ｆｉ（Wireless Fidelity）は、家庭の寝椅子、ホテルの部屋のベッド、あるいは勤務時の会議室から、配線なしでインターネットへの接続を可能にする。Ｗｉ−Ｆｉは、携帯電話で用いられるものと同様の無線技術であって、例えばコンピュータのようなデバイスが、基地局の電波到達範囲内のどこでも、屋内・屋外を問わずデータを送受信することを可能にする。Ｗｉ−Ｆｉネットワークは、ＩＥＥＥ８０２．１１（ａ、ｂ、ｇ等）と呼ばれる無線技術を用いて、安全で、信頼性のある、高速な無線接続を提供する。Ｗｉ−Ｆｉネットワークは、コンピュータを相互に、インターネットに、および有線ネットワークに（これはＩＥＥＥ８０２．３すなわちＥｔｈｅｒｎｅｔ（登録商標）を使用する）接続するために使用可能である。Ｗｉ−Ｆｉネットワークは、例えば、無認可の２．４ＧＨｚおよび５ＧＨｚ電波帯において、１１Ｍｂｐｓ（８０２．１１ａ）または５４Ｍｂｐｓ（８０２．１１ｂ）のデータレートで、あるいは両方の帯域を含む製品（デュアルバンド）で動作するので、このネットワークは、多くのオフィスで用いられる基本的な１０ＢａｓｅＴ有線Ｅｔｈｅｒｎｅｔ（登録商標）ネットワークと同様の実際的パフォーマンスを提供することができる。

次に図２４を参照すると、データ管理を行うためにＣＤＰならびにそれぞれのコンポーネントおよび／またはプロセスにより利用可能な例示的コンピューティング環境２４００の概略ブロック図が示されている。システム２４００は、１つまたは複数のクライアント２４０２を含む。クライアント（複数可）２４０２は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）のいずれでもよい。クライアント（複数可）２４０２は、例えば、本アーキテクチャを使用することによるクッキー（複数可）および／または関連するコンテクスト情報を収容できる。

また、システム２４００は、１つまたは複数のサーバー２４０４も含む。サーバー（複数可）２４０４もまた、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）のいずれでもよい。サーバー２４０４は、例えば本アーキテクチャを使用することによって変換を実行するためのスレッドを収容できる。クライアント２４０２とサーバー２４０４の間の１つの可能な通信としては、２つ以上のコンピュータプロセスの間での伝送に適合したデータパケットの形態の通信があり得る。データパケットは、例えば、クッキーおよび／または関連するコンテクスト情報を含み得る。システム２４００は、クライアント（複数可）２４０２とサーバー（複数可）２４０４の間の通信を容易にするために使用可能な通信フレームワーク２４０６（例えばインターネットのようなグローバル通信ネットワーク）を含む。

通信は、有線（光ファイバを含む）および／または無線技術によって実現可能である。クライアント（複数可）２４０２は、クライアント（複数可）２４０２にとってローカルな情報（例えば、クッキー（複数可）および／または関連するコンテクスト情報）を記憶するために使用可能な１つまたは複数のクライアントデータストア２４０８に動作可能に接続される。同様に、サーバー（複数可）２４０４は、サーバー２４０４にとってローカルな情報を記憶するために使用可能な１つまたは複数のサーバーデータストア２４１０に動作可能に接続される。

以上、実施例について説明した。もちろん、本アーキテクチャを説明する目的で、コンポーネントまたは方法の想定し得るあらゆる組合せを記載することはできないが、当業者には認識されるように、本アーキテクチャのさらに多くの組合せおよび置換が可能である。したがって、本アーキテクチャは、添付の特許請求項の趣旨および範囲内に入るすべてのそのような変更、修正および変形を包含することを意図している。さらに、「includes」（含む）という用語が詳細な説明または特許請求の範囲で用いられる限り、この用語は、「comprising」（「含む」あるいは「備えた」）という用語が請求項における移行語として用いられる場合に解釈されるのと同様に包括的であることを意図している。

本アーキテクチャによる共通データプラットフォーム（ＣＤＰ）を使用するシステムを示す図である。本アーキテクチャによるＣＤＰシステムをより詳細に示す図である。データ管理を容易にする共通データプラットフォームを実装する方法を示す図である。本発明のアーキテクチャに関連するＣＤＰコンポーネントの概略図である。ＣＤＰの種々のコンポーネント内のデータフローを示す図である。ＣＤＰを用いて実装可能な種々のフレームワークを示す図である。複数のアプリケーションがデータを共有することを可能にする共通のデータベース型ファイルストレージシステムの事例を示す図である。ＣＤＰおよび関連するアーキテクチャによる複数のフレームワークを利用した単一のアプリケーションを示す図である。複数の異なるフレームワークに関連する複数のアプリケーションとデータを共有するＣＤＰを示す図である。データ管理を容易にするためのＣＤＰの２層デプロイメントを示す図である。データ管理を容易にするための、共有データを用いた２層デプロイメントを示す図である。アプリケーションが他のアプリケーションによる閲覧および／または利用を望まないプライベートデータを有するような第２の構成を示す図である。別のアプリケーションがストアに直接アクセスするような、関連する第３の構成を示す図である。ＣＤＰコンポーネントの３層デプロイメント構成を示す図である。ＣＤＰコンポーネントの３層デプロイメント構成を示す図である。クライアント層および中間層の両方で動作するアプリケーションロジックの図である。クライアント層および中間層の両方で動作するアプリケーションロジックの図である。少なくとも１つのエンティティを利用するアイテムのモデリングを示す図である。ＣＤＰの上にＵＡＦを組み込むことにより種々の機能を実装するための拡張可能なメカニズムを示す図である。ＣＤＰ上に実装されるＬＯＢアプリケーションの一例を示す図である。ＣＤＰの種々のコンポーネント内のデータフローの管理を容易にする方法を示す流れ図である。異なるアプリケーションが各フレームワークに関係し得るような複数の異なるフレームワークにわたるＣＤＰのデプロイを容易にする方法を示す流れ図である。本アーキテクチャを実行するように動作可能なコンピュータのブロック図である。本発明による例示的コンピューティング環境の概略ブロック図である。

符号の説明

１０２共通データプラットフォーム（ＣＤＰ）
１０４アプリケーションおよびアプリケーションフレームワーク
１０６データストア
１０８ＡＰＩ（言語統合およびデータアクセス）
１１０ＣＤＰランタイム
１１２制約／セキュリティ
２０２データストア／およびストア管理（例：ＳＱＬサーバー）
２０４アプリケーションフレームワーク
４００アプリケーション
４０２共通データモデル（テーブル、エンティティ、リレーションシップ）
４０４セッション、トランザクション
４０６クエリプロセッサ
４０８永続化エンジン（Ｏ−Ｒマッピング、クエリ・更新マッピングを含む）
４１０カーソル、ルール
４１２サービス（変更追跡、コンフリクト検出、イベンティング）
４１４オブジェクトキャッシュ
４１６ビジネスロジックホスティング
５００アプリケーション
６０２ＣＤＰ
６０４ＵＡＦ（別名ＷｉｎＦＳ）
６０６ストアレイヤ
６０８コラボレーション
６１０ＢＦ
６１２連絡先管理アプリケーション
６１４コラボレーションアプリケーション
６１６ＣＲＭアプリケーション
６１８連絡先
６２０アイテム
６２２ドキュメントライブラリー
６２４注文
６２６エンティティ
７０２ＣＤＰ＋ストア
７０６アイテム
７０８電子メール
７１０ドキュメント
７１２連絡先
７１４エンティティ
７１６電子メールアプリケーション
７１８リッチＥＶＩＴＥクライアント
７２０プロジェクト
８０２ＣＲＭアプリケーション
８０６連絡先
８１０アイテム
８１２エンティティ
８１４注文明細
８１６購入注文書
９０４ＵＡＦ（別名ＷｉｎＦＳ）
９０８コラボレーション
９１２連絡先管理アプリケーション
９１４コラボレーションアプリケーション
９１６ＣＲＭアプリケーション
９１８連絡先
９２０アイテム
９２２ドキュメントライブラリー
９２４注文
９２６エンティティ
９２８ストア
１００２ＡＰＩ（言語統合およびデータアクセス）
１００４ＣＤＰランタイム
１００６アプリケーション
１００８制約／セキュリティ
１０１０クライアント層
１０１２ストア
１０１４サーバー層
１１０８共有データ
１１１０ストア
１１１４制約／セキュリティ
１２１１共有データ
１１１４制約／セキュリティ
１２０６ストア
１２１０アプリケーション１プライベートデータ
１２１１共有データ
１２１２アプリケーション２プライベートデータ
１４０２ＣＤＰランタイム
１４０４ストア
１４０６クライアント
１４０８ウェブサービスプロキシ
１４１４リモーティングエージェント
１４１０ウェブサービス
１４１２ビジネスロジックホスティング
１４１６リモーティングサービス
１４２０ＡＰＩ（言語統合およびデータアクセス）
１４１４リモーティングエージェント
１６０２ストア
１６０４制約／セキュリティ
１８０２ドキュメントアイテム
１８０４ドキュメント
１８０６リンク
１８０８ドキュメントエクステンション
１８１０作成者アイテム
１８１２作成者
１８１４作成者エクステンション
１９０２ストア
１９０４ＣＤＰ制約エンジン
１９０６ＵＡＦ制約
１９０８ＣＤＰランタイム
１９１０ＵＡＦアイテム挙動
１９１２ＢＬホスト
１９１４ＵＡＦバインド可能な挙動
１９１６他のＵＡＦサービス
２００２ウルトラアプリケーションサーバー
２００４ＬＯＢクライアント
２００６ＬＯＢ制約
２００８データ中心ＢＬ
２０１０ウェブサービスプロキシ
２０１２ウェブサービスインタフェース
２０１４ＣＤＰ制約エンジン
２３０４処理ユニット
２３０６システムメモリ
２３０８バス
２３１４内蔵ＨＤＤ
２３１４外付けＨＤＤ
２３１８ディスク
２３２０光ドライブ
２３２２ディスク
２３２４，２３２６，２３２８インタフェース
２３３０オペレーティングシステム
２３３２アプリケーション
２３３４モジュール
２３３６データ
２３３８キーボード
２３４０マウス
２３４２入力デバイスインタフェース
２３４４モニタ
２３４６ビデオアダプタ
２３４８リモートコンピュータ
２３５０メモリ／ストレージ
２３５６ネットワークアダプタ
２３５８モデム
２４０２クライアント
２４０４サーバー
２４０６通信フレームワーク
２４０８クライアントデータストア
２４１０サーバーデータストア

Claims

データへの統一的なアクセスを可能にする複数の異なるアプリケーションフレームワークによりアクセス可能なデータサービスを提供することによってデータ管理を容易にするデータプラットフォームにおいて、
公開クラス、インタフェース、および静的ヘルパ関数の少なくとも１つの形でアプリケーションへの通信を容易にするアプリケーションプログラムインタフェース（ＡＰＩ）と、
前記ＡＰＩへのインタフェースとなり、オブジェクトリレーショナルマッピング、クエリマッピング、および制約の強制の少なくとも１つを提供するランタイムコンポーネントと、
前記複数の異なるアプリケーションフレームワークに共通するデータインタフェースを抽出する共通データモデルと
を備えたことを特徴とするデータプラットフォーム。
前記共通データモデルが、ドメイン固有の型、制約、およびリレーションシップの少なくとも１つの作成を容易にすることを特徴とする請求項１に記載のプラットフォーム。
前記ドメイン固有の型が、プロパティおよびメソッドの少なくとも１つのグルーピング（グループ化）に対する指定であるエンティティ型であり、該ドメイン固有の型がエンティティ、テーブル、テーブルセット、およびリレーションシップの少なくとも１つを使用することを特徴とする請求項２に記載のプラットフォーム。
スキーマが前記エンティティ、前記リレーションシップ、および前記テーブルセットの少なくとも１つを定義することにより、名前空間がそれに関連づけられるようにしたことを特徴とする請求項３に記載のプラットフォーム。
前記共通データモデルが、前記固有のドメイン型システムに対するクエリ言語を定義し、該クエリ言語は、保存されたデータに対する強く型付けされた、オブジェクトに基づく抽象化を提供するオブジェクト構造に対するリッチなクエリを可能にすることを特徴とする請求項２に記載のプラットフォーム。
前記クエリ言語が、ＯｐａｔｈおよびＯＳＱＬ（オブジェクト指向構造化クエリ言語）の少なくとも１つであることを特徴とする請求項５に記載のプラットフォーム。
制約の宣言的作成を容易にし、前記データプラットフォームの少なくとも１つのエンティティへのアクセスを制御する制約／セキュリティエンジンをさらに備えたことを特徴とする請求項１に記載のプラットフォーム。
規範的オブジェクトリレーショナルマッピングおよび非規範的オブジェクトリレーショナルマッピングの少なくとも１つを呼び出すことによって、言語クラスを基礎となるテーブル表現にマッピングするオブジェクトリレーショナルマッピングを呼び出す永続化エンジンをさらに備えたことを特徴とする請求項１に記載のプラットフォーム。
前記マッピングが、アプリケーション空間から前記共通データモデルへのマッピングであり、前記共通データモデルからストアへのマッピングとは独立であることを特徴とする請求項８に記載のプラットフォーム。
前記複数の異なるアプリケーションフレームワークが、業務フレームワーク、エンドユーザフレームワーク、システム管理フレームワーク、ユーザアプリケーションフレームワーク、コラボレーションフレームワーク、ビジネスフレームワーク、および個人情報フレームワークの少なくとも１つを含むことを特徴とする請求項１に記載のプラットフォーム。
前記アプリケーションが、エンドユーザアプリケーション、知識労働者向けアプリケーション、業務アプリケーション、ウェブアプリケーション、連絡先管理アプリケーション、ドキュメント管理アプリケーション、コラボレーションアプリケーション、電子メールアプリケーション、顧客関係管理アプリケーション、企業資源計画アプリケーション、およびシステム管理アプリケーションの少なくとも１つであることを特徴とする請求項１に記載のプラットフォーム。
前記ランタイムコンポーネントが、識別マッピング、オブジェクト変更追跡、および元の値の少なくとも１つを含むエンティティ状態の管理を提供することを特徴とする請求項１に記載のプラットフォーム。
前記データプラットフォームおよびそれぞれのコンポーネントが層不問（tier-agnostic）であり、クライアント層、中間層、サーバー層、およびウェブサービス層の少なくとも１つに存在し得ることを特徴とする請求項１に記載のプラットフォーム。
前記共通データモデルがデータストレージコンポーネント内の共有データを提供することにより、対応するフレームワークに関連する相異なるアプリケーションが前記共有データにアクセスできるようにしたことを特徴とする請求項１に記載のプラットフォーム。
前記共通データモデルがデータストレージコンポーネント内のプライベートデータを提供することにより、該プライベートデータが特定のフレームワークに関連する特定のアプリケーションのみによってアクセスされるようにしたことを特徴とする請求項１に記載のプラットフォーム。
ルールサービス、変更追跡サービス、コンフリクト検出サービス、イベンティングサービスおよび通知サービスの少なくとも１つをさらに備えたことを特徴とする請求項１に記載のプラットフォーム。
コンピュータにより実現されるデータ管理方法において、
構造化、半構造化、および非構造化データ型をモデリングし保存するストア上にデータプラットフォームをオーバーレイすることにより、相異なるアプリケーションフレームワークに対してリッチなデータモデル、マッピング、クエリ、およびデータアクセスメカニズムの少なくとも１つをサポートするデータサービスを提供し、
前記データプラットフォームの上に１つまたは複数のアプリケーションフレームワークをオーバーレイすることにより、各フレームワーク内の少なくとも１つのアプリケーションがデータストアにアクセスすることを可能にし、
公開クラス、インタフェース、および静的ヘルパ関数の少なくとも１つの形でアプリケーションと通信し、
オブジェクトリレーショナルマッピング、クエリマッピング、および制約の強制の少なくとも１つを提供し、
複数の異なるアプリケーションフレームワークに共通するモデリング概念を取り出す
ことを特徴とするデータ管理方法。
オブジェクトを作成し、
セッションを用いて前記ストアへのコネクションをオープンしてセキュリティコンテクストを確立し、
アプリケーションにストレージコンテクストのインスタンスを返し、
オブジェクトを取得するためのインタフェースを公開し、
セキュリティを適用しつつクエリをＳＱＬにマッピングし、
データプラットフォームランタイムおよび前記アプリケーションに結果を返し、
カプセル化されたストレージコンテクストオブジェクトに対する変更を保存する
ことをさらに含むことを特徴とする請求項１７に記載の方法。
前記相異なるアプリケーションフレームワーク上の相異なるアプリケーションに共有データを提供し、
特定の異なるアプリケーションフレームワーク上のアプリケーションに固有のプライベートデータを利用する
ことをさらに含むことを特徴とする請求項１７に記載の方法。
コンピュータにより実現される、データの管理を容易にするシステムにおいて、
公開クラス、インタフェース、および静的ヘルパ関数の少なくとも１つの形でアプリケーションと通信する手段と、
オブジェクトリレーショナルマッピング、クエリマッピング、および制約の強制の少なくとも１つを提供する手段と、
複数の異なるアプリケーションフレームワークに共通するモデリング概念を取り出す手段と
を備えたことを特徴とするデータの管理を容易にするシステム。