JP2006252539A

JP2006252539A - システムデータインターフェース、関連アーキテクチャ、印刷システムデータインターフェース、および関連印刷システムアーキテクチャ

Info

Publication number: JP2006252539A
Application number: JP2006032952A
Authority: JP
Inventors: F Maxa Adrian; エフ．マクサエイドリアン; Mark A Lawrence; エー．ローレンスマーク
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-03-10
Filing date: 2006-02-09
Publication date: 2006-09-21
Also published as: EP1701245A2; KR20060097577A; CN1869923B; EP1701245A3; US7962917B2; CN1869923A; US20060206903A1

Abstract

【課題】システムのデータインターフェースおよび関係するアーキテクチャを提供すること。
【解決手段】さまざまな実施形態は、汎用データモデル、非同期クライアントおよびサーバディスパッチ、キャンセレーション、バッチ処理、トランザクション呼び出し、並列呼び出し、インターセプション、またはリフレクションの機能のうちの１つまたは複数を実現できる。一実施形態では、システムデータインターフェースは、印刷システムとの関連で使用される。
【選択図】図１

Description

本発明は、システムデータインターフェースおよび関係するアーキテクチャに関するものであり、特定の実施形態において、印刷システムデータインターフェースおよび関係するアーキテクチャに関するものである。

いくつかのシステムは、データを処理し、さまざまな種類のクライアントと通信するサーバを備えることができる。特定の種類のシステムとして、さまざまなクライアントからのジョブ、デバイス、論理サーバ、およびフォームデータにアクセスできるようにするプリントサーバを備えることができる印刷システムがある。印刷システムなどの多くの現行システムは、新しいクラスのデータをサポートする必要が生じると必ず修正されなければならない融通のきかない基幹ネットワークインターフェースを備えている。さらに、いくつかのインターフェースは、いたずらに多くの通信を必要とし、サーバ上にコンテキストを生成する場合があるが、この両方とも、印刷システムなど、サーバが使用されるどのようなコンテキストであってもサーバパフォーマンスを制限する可能性がある。

多くのシステムにとって厄介な他の問題では、融通がきかない、拡張が難しい、プロトコル特有である範囲の制限が生じうる。

したがって、本発明は、改善されたデータインターフェースおよび関係するアーキテクチャを含む、改善されたシステムを異次元することに関連する懸案事項から生じた。

システムのデータインターフェースおよび関係するアーキテクチャについて説明する。さまざまな実施形態は、汎用データモデル、非同期クライアントおよびサーバディスパッチ（ａｓｙｎｃｈｒｏｎｏｕｓｃｌｉｅｎｔａｎｄｓｅｒｖｅｒｄｉｓｐａｔｃｈ）、キャンセレーション、バッチ処理、トランザクション呼び出し、並列呼び出し、インターセプション、およびリフレクションの機能のうちの１つまたは複数を実現できる。

一実施形態では、システムデータインターフェースは、印刷システムとの関連で使用される。

概要
後述の説明において、現行システムの欠点の多くを解消する新規性のあるシステムが提示される。一実施形態では、システム、そのデータインターフェース、および関連するアーキテクチャは、印刷システムとの関連で使用される。しかし、本発明の後述の特徴を、請求された主題の精神および範囲から逸脱することなく、印刷システム以外のシステムで使用することができることは理解されるであろう。

説明される印刷システムは、多くのことを実行するが、基本的には説明されている印刷システムは２、３の主要タスクを実行する。第１に、印刷システムは、オブジェクトおよびその特性の集合を含むデータを管理する。第２に、印刷システムは、まずレンダリングのため印刷ジョブをスケジュールし、その後、印刷のため印刷ジョブを適切な印刷デバイスに送信する。ドキュメントをレンダリングするプロセスは、ジョブを処理するために呼び出すコンポーネントを指定するデータインターフェースから構成情報を取り出すことにより実行することができる。そのため、印刷システムがデータを表す方法は、そのオペレーションに対し基本的なものとすることができる。

これらの主要タスクを実行するために、本発明の印刷システムでは、特定のインターフェースおよび関係するコンポーネントを使用する。このインターフェースおよびこのインターフェースが含まれる印刷システムは、現行印刷システムに勝る多数の利点を備えることができる。以下の説明では、印刷システムおよびインターフェースの予備的評価を行うため、さまざまな利点について説明する。この説明の後の、「例示的な実施形態」という表題の節では、印刷システム、および特に、データインターフェースの具体的実装例を説明する。

後述のデータインターフェースは、汎用データモデル、非同期クライアントディスパッチ、非同期サーバディスパッチ、キャンセレーション、バッチ処理、トランザクション呼び出し、並列呼び出し、インターセプション、およびリフレクションの機能をサポートするが、それぞれ、見出しを立てて説明し、示す。

汎用データモデル
説明されるデータインターフェースを、汎用データモデルをサポートし、汎用データモデルとして考えられるものに関連して使用することができる。データモデルは、以下の機能を備えるオブジェクトのクラスをサポートすることができる。
● プロパティ−いかなるオブジェクトも、プロパティの任意の集合を持つことができる。クライアントは、オブジェクトから取り出すプロパティのどのような集合をも指定することができる。クライアント側で興味を持つプロパティのみが取り出される。
● コマンド−どのようなオブジェクトも、パラメータの任意の集合を伴うコマンドの集合をサポートすることができる。
● サーバからクライアントへ利用可能なクラス、コマンド、およびプロパティを任意に拡張するためにワイヤ形式を修正する必要はない。

非同期クライアントディスパッチ
非同期クライアントディスパッチは、当業者であれば理解するように、制御を即座にクライアントスレッドに返すデータ要求をクライアントまたはクライアントアプリケーションが開始できるようにするデータインターフェースアプリケーションプログラムインターフェース（ＡＰＩ）の機能を指す。オペレーションの結果が完全な場合、コールバックまたは通知されるシステムイベントを介してクライアントに情報が送られ、クライアントはそのデータの結果を取り出すことができる。例示され、説明されている実施形態では、この機能は、同期ブロックし、クライアントが先へ進めるようにするスレッドをスピンする自明なラッパーとして提供されない。むしろ、非同期ディスパッチは、デバイスレベルにへと下方に伝わる。低レベルでは、呼び出しの結果は、ネットワークカードにより駆動される割り込みである。このモデルを使用することで、サーバからデータを取り出しつつ応答できるクライアントユーザインターフェースを設計することが簡素化される。また、クライアント上で必要なスレッドの個数も減る。これは、クライアントシステムが、他の印刷システムへのブリッジとして動作する印刷システムの場合に特に有利である。

非同期サーバディスパッチ
非同期に要求をサーバにディスパッチするクライアントの機能と併せて、サーバはサービス要求をクライアントから非同期に要求できる。サーバが実行するクライアント要求がＩＯバインドされた場合（例えば、データをディスクに書き込むか、または他のサーバにデータを要求する必要がある）、プラグインコンポーネントは、他の非同期呼び出しを発行し、制御権をサーバサイドデータインターフェースに返し、その後、ＩＯが完了すると呼び出しを完了することができる。このメカニズムは、サーバ上で動作しているスレッドの数を劇的に減らし、すべてのスレッドがシステムＣＰＵを完全利用するようにできる。

システム上で実行するすべてのスレッドは、システムから大量の「非ページプール」を取り出す（非ページプールは、物理メモリが制限されている場合にはディスクに書き出すことができないメモリである）。システムロックを取得するシステム内で動作しているそれぞれのスレッドも、システム内に大量の「争奪」を発生させる（これは、実行のスレッドを切り替えるために必要な時間およびＣＰＵ資源の量である）。したがって、システム内で動作しているスレッド数を減らすことは、システムのパフォーマンスを改善する重要なメカニズムである。

キャンセレーション
後述の実施形態では、サーバ上で進行中の呼び出しを、いつでもクライアント側によりキャンセルすることができる。これにより、クライアントは、対話型ユーザインターフェースを呼び出し側に提供できる。

バッチ処理
バッチ処理は、データインターフェースを使用して、任意のアクションシーケンスを構築し、それらのアクションシーケンスを１単位としてサーバへ送信させるクライアントの機能を指す。その後、このシーケンスは、処理され、１回の転送応答でクライアントに返される。これらのアクションは、プロパティの参照および設定、プロパティの集合のクエリ、サーバオブジェクトに対するコマンドの発行、およびサーバオブジェクトのプロパティ変更に関する通知の登録など、任意の種類のアクションを含むことができる。

トランザクション呼び出し
トランザクション呼び出しは、完全に実行しなければならない、またはサーバの状態を変更しないという意味動作を割り当てられるバッチを指す。

並列呼び出し
並列呼び出しは、バッチ内のすべてのアイテムは並列に実行されなければならないという意味動作を割り当てられるバッチを指す。これにより、サーバは、長い実行アクションを並列に実行することができ、また他のどのようなアクションが失敗するとしてもバッチはすべてのアクションを実行するという意味動作も与える。

インターセプション
システム側でサポートできるオペレーションおよびプロパティは、純粋なデータ転送により表されるため、他のコンポーネントをシステム内に挿入し、システムのビヘイビアを監視し、同期的に応答し、修正することができ、これはインターセプションと呼ばれる。これにより、監視ソフトウェアをシステム内にプラグインすること、およびシステムから削除することを行える。また、独立系ハードウェアベンダ（ＩＨＶ）もシステムビヘイビアを拡張することができる。例えば、キューが停止された場合、関連するサービスも、停止する必要があるかもしれない。このキュー上の「ｓｔｏｐ」コマンドは、ＩＨＶにより横取りされ、その後、それらにより、停止オペレーションが完了できる前にサービスが必ず停止されるようにできる。インターセプションメカニズムは、さらに、トランザクション意味動作も備えることができる。

リフレクション
リフレクションは、所定のクラスのオブジェクトによりどのようなプロパティがサポートされるかの情報またはそのオブジェクトに関連付けられたその他の情報を取り出すメカニズムをシステムが備えることを指す。このメカニズムを使用して取り出すことができる情報は、限定はしないが、以下を含むことができる。
● それぞれのプロパティの型名、フィールド名、およびデータ型、
● プロパティ使用法の人間が読み取れる記述、
● オブジェクトによりサポートされるコマンド、およびそのコマンドによりサポートされる入力および出力パラメータ。それぞれのコマンドは、コマンドの使用法の人間が読み取れる記述を備える。パラメータ毎に、パラメータの名前と型、およびパラメータの人間が読み取れる記述を取り出すことができる。

例示され、説明されている実施形態では、システムのリフレクション機能は、プロトコルに関係しない。さらに、リフレクション機能は、サーバプラグインのネイティブコードおよびマネージドコードによる両方の実装との間で使用できる。さらに、リフレクション機能は、ネットワークインターフェース経由でリフレクションを実行することができ、サーバサイドオブジェクトの実装がクライアント上に存在している必要はない。

これらの機能および他の機能は、以下の説明から明らかになるであろう。

例示的な実施形態
以下の説明では、本発明のインターフェースの高水準の説明が図１に関連して与えられる。この説明に従って、実装の実施例が与えられ、これは実装特有の情報を含む。実装特有の実施例は、上述の機能を含む印刷システムをどのように実装できるかを示す一例としてのみ与えられていることは評価され、理解されるであろう。したがって、本明細書で請求されている主題の精神および範囲から逸脱することなく、他の実装を利用できる。他の実装は、上述のように、印刷システムとの関連で使用できる場合も使用できない場合もある。

図１は、共通データインターフェース１０２を含む一般に１００で示されるシステム、プラグインテーブル１０６およびインターセプションテーブル１０８を含むバッチ処理ルータ１０４を示す。システム１００は、さらに、メッセージプラグイン１１０、メッセージサービス１１２、コレクション１１４、さまざまなオブジェクト１１６、システム拡張機能１１８、およびいわゆる「その他のコラボレーション」１２０も含み、それぞれについて以下で説明する。

共通データインターフェース（ＣＤＩ）
共通データインターフェース（ＣＤＩ）は、バッチ処理ルータ１０４とのインターフェースであり、これにより、メッセージを構築し、バッチ処理ルータにディスパッチすることができる。ＣＤＩは、さらに、クライアントに応答を送信する役割も持つ。

バッチ処理ルータ
バッチ処理ルータ１０４は、ＣＤＩ１０２によりパッケージされシステム内に渡されるメッセージを受信する。それぞれのメッセージは、多数のプラグインを宛先とすることができる多数のオペレーションを含むことができる。これらのメッセージは、非同期にディスパッチされ、それらの結果は、順に、バッチ処理ルータ１０４により取り出される。メッセージは、メッセージの送り先となるコレクションを識別する曖昧でないパスに基づいてルーティングされる。クライアントの観点からの単一メッセージは、複数の宛先を持つ場合がありうる。

プラグインテーブル
プラグインテーブル１０６は、所定のオブジェクトのコレクションを受け持つメッセージ処理プラグインのすべてを追跡する。それぞれのコレクションは、グローバル一意識別子（ＧＵＩＤ）により識別される。そのオブジェクトへのパスが検査され、プラグインテーブル内で検索されてから、メッセージがそれに渡される。

メッセージプラグイン
適切なコレクションが識別された後、メッセージの集合がメッセージプラグイン１１０に受け渡される。メッセージプラグイン１１０は、リモートから有線で他のマシンへそれらのメッセージを単純に送出する可能性がありうる。しかし、通常、メッセージプラグイン１１０は、それらのメッセージを解釈して、適宜応答する。例示され説明されている実施形態では、サードパーティがメッセージプラグインを提供することができる。しかし、第三者がそうする場合、それらの第三者はメッセージサービスにより提供されるサービスを利用できない。このため、この層でのプラグインはかなり難しくなる。メッセージプラグインがあるという主な利点は、オリジナルのメッセージの形態が利用可能になるという点である。これを使用して、プラグインコレクションによりリモートマシンにメッセージ全体を中継するようにできる。さらに、これは、バッチ処理をサポートするリモートシステムも備え、また受信されたメッセージ形式と自メッセージ形式との間で翻訳できるようにしたい場合に、独立系ハードウェアベンダにとって利点となりうる。

メッセージサービス
メッセージベースのシステムの主要問題の１つは、複数のメッセージ呼び出しにわたって状態を保持することの難しさであるため、メッセージを分解し、それらをコレクションインターフェース上でより単純な呼び出しシーケンスに翻訳するコンポーネント−メッセージサービス１１２−が用意される。例えば、限定はしないが、例示され、説明される実施形態では、メッセージサービスは、以下のタスクを実行することができる。
● メッセージをスレッドに割り当てる、
● メッセージが複数の遅延呼び出しに応答できるようにする、
● コレクション内のオブジェクトから適切なデータを取り出して、メッセージに埋める、
● オペレーションキャンセレーションを正しく処理する、
● 長時間にわたるオブジェクトインスタンスのキャッシュ、
● オブジェクトの透過的ロック、
● コレクション内に保持されているオブジェクトのリフレクションサービス。

コレクション
コレクション１１４は、オブジェクトの同質な集合を保持する。システムは、オブジェクトを容易に持続させられるコレクションを備える。コレクションを使用する１つの利点は、これにより独立系ハードウェアベンダが任意のオブジェクトでシステムを容易に拡張できるという点である。例示され、説明されている実施形態では、コレクションは、ダイナミックリンクライブラリ（ＤＬＬ）から取り出されるＣＯＭインターフェースとして実装される。当業者であれば理解するように、ＤＬＬは、グローバルアセンブリキャッシュ内で検索され、ＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔへの直接呼び出しが実行され、ＣＯＭ登録を回避できる。

オブジェクト
上述および後述のシステムの１つの目標は、独立系ハードウェアベンダおよびその他の開発者が、大部分、その実装言語の直接的サポートにより、クラスのレベルでコーディングできるようにすることである。この目標は、できる限り多くのコードをコレクションに合併し、独立系ハードウェアベンダおよびその他の開発者が書かなければならないコードの総量を減らすことである。オブジェクト１１６は、コレクションにより保持される論理構文である。メッセージサービス１１２は、それらのオブジェクトがＣ＋＋クラスに直接対応する層を備える。

インターセプションテーブル
インターセプションテーブル１０８は、一般的な、普遍的な、拡張メカニズムを印刷システムに提供する。ここでの目標は、システム内のオブジェクト、特定のクラスのオブジェクト、または特定のオブジェクトインスタンスをターゲットとするメッセージを横取りし、修正することができる拡張を用意することである。

システム拡張
システム内のほとんどすべてのものは、中央メッセージシステムを発生元とし、メッセージにより表されるため、システム拡張１１８により、システムを拡張することができ、とりわけ、適していると思われる何らかの方法で、サードパーティにより監視されるようにできる。これらの拡張は、スプーラチーム自体による有用な監視拡張機能も備える。

他のコラボレーション
システムビヘイビアのすべてを、データ駆動型メッセージングシステムとして表せるわけではないことは理解されるであろうしたがって、マシン内の他のサブシステムを作成するオブジェクト間に他のコラボレーション１２０があり、またこれからもある。これらは、例えば、パイプラインおよびスケジューラを含むことができる。ここでの目標は、他のパーティがシステム内にプラグインできるようにすべてのコラボレーションを可能な限り柔軟にすることである。

これらの他のサブシステムがシステムのＣＤＩビューとの一貫性を維持する方法は、ＣＤＩを通じて、オブジェクトを直接作成する、または適切なデータを返してオブジェクトをインスタンス化できるようにするファクトリオブジェクトを呼び出すことである。このパターンを使用すると、システム拡張機能がファクトリオブジェクトへのこれらの呼び出しを横取りし、ファクトリを実装してオリジナルインターフェースをラップすることができるという結果が得られる。これは、システム拡張機能がシステムのどのような側面をも監視または修正できることを意味する。これは、プラガブルな監視コンポーネントをシステム内の任意の位置に挿入できるようにするために有用である。

ここまで本発明のインターフェースの高水準の説明を行ったが、以下の節では、実装特有の情報を含む実装の実施例を説明する。上述のように、実装特有の実施例は、本明細書で説明されている本発明の原理に従って印刷システムをどのように実装できるかを示す一例としてのみ与えられていることは評価され、理解されるであろう。したがって、本明細書で請求されている主題の精神および範囲から逸脱することなく、他の実装を利用できる。

実装の実施例
以下の説明全体にわたって次の用語および頭字語を使用することをあらかじめ述べておく。
● アクション−「バッチ」を参照。
● アクセスアダプタ−「データアクセスアダプタ」を参照。
● アクセッサ−オブジェクトからデータを取り出すために使用される方法。．Ｎｅｔプロパティは、アクセッサの一例である。
● バッチ−溜め込んだ後、ある時点において実行されるアクションのシーケンス。通常、バッチを実行すると、ネットワーク呼び出しが１回行われる。アクションは、取得、設定、クエリ、コマンド、および通知要求とすることができる。
● バッチ処理コレクション−バッチ処理ルータにプラグインされる最高レベルのインターフェース。適切にルーティングされた、実行すべきアクションのバッチを受け取る。
● バッチ処理ルータ−コレクションの集合のうちからバッチ内のアクションを受け渡す先を選択するＣＤＩ内の要素。
● 正規名−時間と空間においてオブジェクトインスタンスを一意に識別する名前。ＣＤＩでは、これは、コレクションＧＵＩＤおよびオブジェクトＧＵＩＤである。ＣＤＩは、正規名のみに基づいてルーティングする。アプリケーションでは、システムと通信するときに可能であれば正規名を使用すべきである。「フレンドリ名」を参照。
● ＣＤＩ−「共通データインターフェース」を参照。
● クラス−ＣＤＩにおいては、オブジェクトの一種。クラスは、プリンタ、ジョブまたはサーバ、またはその他の論理分割とすることができる。クラスは、型からなる。
● クライアントコレクション−クライアント上に保持されるオブジェクトのコレクション。ＣＤＩは、そのタイプマップに基づいてクライアントコレクション内のオブジェクトに書き込む。
● コレクション−１つの論理的コード断片により与えられるオブジェクトの異種の集合。ＣＤＩは、正規名に基づいて複数のコレクションに要求をルーティングする。
● コレクションアダプタサービス−バッチ処理ルータにバッチ処理コレクションインターフェースを公開し、少ない労力でオブジェクトの集合を公開できるようにするサービスを実装するサービス。
● コマンド−バッチが最終的にサーバに送信されたときにオブジェクトに対するメソッドを実行させる一種のバッチアクション。
● 共通データインターフェース−正規名を介してオブジェクトにアクセスできるようにするコンポーネント。呼び出しをまとめてバッチ処理すること、およびオブジェクトへの非同期または同期アクセスもサポートする。
● データアクセスアダプタ−データアクセスアダプタは、ＣＤＩにプラグインし、何らかの方法でその機能を翻訳する。これは、ＣＤＩにより公開されるインターフェースを他（プロセス内アダプタ）に変換することが可能であるか、またはＣＤＩのリモーティングを行うことが可能であり、その場合、それはリモートアクセスがアダプタである。
● 表示名−「フレンドリ名」を参照。
● 埋め込み型−他のコレクション内の他のオブジェクトによりサポートされるプロパティを動的に拡張するために使用されるコレクション内のオブジェクト。
● フィールド−データの名前付き断片。
● フレンドリ名−「表示名」とも呼ばれる。フレンドリ名は、オブジェクトインスタンスを識別するためにシステムにより使用される正規名とは反対に、ユーザがオブジェクト（Ｆｒｅｄのプリンタ）に関連付ける名前である。フレンドリ名を正規名に変換できるようにするため、ＣＤＩでは、名前解決パイプラインを備える。
● 階層−ＣＤＩでは、これは、親オブジェクトと親オブジェクトにリンクのクエリを実行することにより得ることができる子オブジェクトとの任意の関係である。
● プロセス内アダプタ−アプリケーション内で実行されているＣＤＩインスタンスとともにプロセス内で実行されるデータアクセスアダプタの一形態。これらは、通常、何らかの方法でデータを変換するだけである。例えば、データにアクセスするＡＰＩを用意する。
● リンク−オブジェクト間の階層関係のクエリを実行するために使用される特別な予約済みクラス。
● メタデータ−ＣＬＲ内のリフレクションと混同しないこと。サポートしている型、フィールド、およびコマンドを発見するために任意のオブジェクトからメタデータについてクエリを実行することができる。クライアント上で対応するアセンブリが利用可能かどうかについての情報を取り出すことができる。
● メソッド−そのオブジェクトを呼び出す場合に実行されるオブジェクト上の実際のコード断片。少し異なる概念については「コマンド」を参照。
● 名前解決パイプライン−フレンドリ名を正規名に変換するためにアプリケーション空間内で実行されるリゾルバと呼ばれる要素のシーケンス。
● 最適化タイプマップ−一方のオブジェクトから他方のオブジェクトへ、フィールドの集合を移動するために２つのオブジェクトを突き合わせて実行される取得および設定のシーケンス。これは、クライアントオブジェクトのタイプマップおよびサーバオブジェクトのタイプマップのフィールドを組み合わせることができる。
● 永続的オブジェクトコレクションサービス−オブジェクトをデータベースに対して永続的にできるコレクションをアダプタサービスにプラグインするサービス。
● クエリ−ＣＤＩと関連して、オプションのフィルタおよびオプションのクエリベースを持つ与えられたクラスのオブジェクトの集合に対する要求。
● クエリベース−クエリが開始する概念上の位置。例えば、ベースは、ローカルマシンまたは与えられたサーバとすることが可能である。
● リモートアクセスアダプタ−リモートアクセスアダプタを使用すると、ＣＤＩにより公開されるインターフェースをマシン間でリモーティングを行うことができる。これは、一方のＣＤＩにはオブジェクトのコレクションとして、リモーティングが行われるＣＤＩにはデータアダプタとして見せることにより行われる。
● リゾルバ−名前解決パイプライン内の一要素。それぞれのリゾルバは、コレクションに関連付けられ、その内部の要素を識別する方法を知っている。
● タイプマップ−オブジェクトからデータを取り出す、またはそれをオブジェクトに適用する方法を記述するフィールドのテーブルおよび相関するアクセッサ。タイプマップは、動的または静的とすることができる。フィールド同士を比較することにより２つのタイプマップを組み合わせて、最適化されたタイプマップを出力する。
● 型−インターフェースに類似する。型は、常に、完全に実装されなければならないフィールドおよびコマンドの論理グループである。

共通データインターフェース
共通データインターフェース（ＣＤＩ）は、名前（フレンドリ名または好ましくは正規名）でオブジェクトを特定すること、オブジェクトからデータを取得またはデータをオブジェクトに適用すること、オブジェクト変更に関する通知をサポートすること、およびコマンドをオブジェクトに発行することを含む機能を提供する。ＣＤＩは、限定はしないが、２、３例を挙げると、同期インターフェースの使用、拡張性の欠如、名前ベースのルーティング、およびバッチ処理の欠如を含む、現行のアーキテクチャの多くの制限に対処し、克服する。

ＣＤＩでは、任意の数の一意に識別可能なコレクションをシステム内にプラグインできるようにすることにより、これを実行する。これらのコレクションでは、望ましいどのような種類のオブジェクトをもサポートできる。インターフェース自体は、非同期オペレーションおよびバッチ処理をサポートするために妥当な複雑性を有するが、サービスが提供され、プラグインされるコレクションを比較的簡単に書くことができる。

ルータの再アーキテクチャ
現在のスプーラアーキテクチャにおける多数の基本的な問題は、ルータから生じるものである。これは、同期ＡＰＩセットの使用、起動時にすべてのプロバイダ（およびモニタ）をロードする必要があること、オブジェクトの名前を変更できないこと、スプーラコンポーネントのアンロードを行えないこと、およびシステムをシャットダウンできないことを含む。この節では、本発明の印刷システムにおけるルータの交換アーキテクチャについて説明する。

以下の説明は、図２に示されている概要図に基づく。この実施例では、ルータは、かなり柔軟なデータアクセスメカニズムである、共通データインターフェース（ＣＤＩ）で置き換えられる。ＣＤＩは、基本的に、アクセスアダプタとコレクションとの間のルーティングおよびサービス層である。これは、複数のプロトコルを介して任意のシステム上の印刷オブジェクトを特定する機能を備え、また、同じ意味動作をすべてのオブジェクトに持たせることができるサービスの集合も提供する。これらの意味動作は、オブジェクトデータの部分集合を取り出し、設定する機能、すべてのオブジェクトに対するそのステータスに関するクエリ機能、コマンドをオブジェクトに発行する機能、およびシステム内のすべてのオブジェクトから一貫して変更通知を送信する機能である。データアクセスアダプタは、複数のプロセス内アダプタとリモートアクセスアダプタに分けられる。

例示され説明されている実施形態では、すべての内部コンポーネントおよびアプリケーション（コレクションプロバイダおよびアクセスアダプタを除く）は、プロセス内アダプタとのみインターフェースする。プロセス境界をまたがる通信およびクライアントサーバ通信については、ＣＯＭ／ＤＣＯＭリモートアクセスアダプタが使用される。Ｗｅｂサービスベースのシナリオについては、ＳＯＡＰアダプタが使用される。アダプタは、次に、他のプロセス空間、または他のマシン内にコレクションとして出現する。これにより、共通データインターフェースをフルサポートすることができるアクセスアダプタは、プロセス内アダプタを通じて常にアクセス可能にできる。この接続性スキームの概要は、図３に示されている。

ダウンレベルおよびアップレベルのプロトコルアクセス
アップレベルアダプタは、完全な共通データインターフェースを丸ごとカプセル化することができるアダプタであり、唯一の完全プロセス内アダプタは、属性ベースのマネージドコードアダプタである。システムへのマネージドＡＰＩは、システム機能の有用なアプリケーション部分集合を表すのみである。ローカルマシン上で、クライアントサーバベースのシナリオにおいて、通信に使用されるプロセス外ＣＯＭアダプタ、およびＷｅｂサービスを介してデータへのアクセスを提供するＳＯＡＰリモートアクセスアダプタを含む、２種類の完全リモートアクセスアダプタがある。

アダプタの他の候補は、共通データインターフェースのフルパワーを使用できるアダプタであり、それら自身は、限定されたデータ型を公開するだけであるが、その場合、完全にデータ駆動方式によりマッピングすることができる。例えば、ＭＯＦファイルのデータ型と共通データインターフェースのデータ型との間のマッピングは、完全データ駆動方式で実行可能である。ＭＯＦファイルは、Ｗｉｎｄｏｗｓ（登録商標）ＭａｎａｇｅｍｅｎｔＩｎｓｔｒｕｍｅｎｔａｔｉｏｎ（ＷＭＩ）システムにより、システムオブジェクト記述するために使用される。

他のあまり柔軟でないプロトコルだと、印刷システムコンポーネントと通信するためにプロセス内アダプタを使用する可能性が最も高く、例えば、ＲＰＣクライアントは、Ｃ＋＋テンプレートライブラリを介して新しい印刷システムと通信する。

ダウンレベルプロバイダのサポートは、メモリ内コレクションを提供し、ユーザがデータをシステムに供給するマネージドクラスおよびオブジェクトアダプタを書くことができるようにすることにより簡素化される。ダウンレベルプロバイダは、システムにより使用可能な限定された型のある部分集合をサポートしなければならない。

共通データインターフェースのオブジェクトモデル
例示され説明される実施形態では、共通データインターフェース（ＣＤＩ）は、以下のようなプロパティを持つ。ＣＤＩは、オブジェクト上の個々のプロパティを取得および設定することをサポートする。また、クエリフィルタおよびそれぞれのオブジェクトから取り出すプロパティの集合に基づいてオブジェクトのグループについてクエリを実行することもサポートする。ＣＤＩは、コマンドを実行するようにオブジェクトに依頼すること、パラメータの集合をそれに受け渡すこと、およびそれから戻りパラメータの集合を受け取ることをサポートする。さらに、ＣＤＩは、オブジェクト変更の通知を要求することもサポートする。通知は、呼び出し側が通知を望むフィルタおよびプロパティの集合を含む。さらに、ＣＤＩは、プロセス内のみであり、インターフェースをリモート操作する機能は、適切なプラグインアダプタにより実現される。ＣＤＩは、通知のコールバックを使用し、通知は、クライアントにより保持される接続はサーバ拡張性を劇的に低下させるためある種の難しいトレードオフの関係をもたらす。この問題を解決するために、通知の２つのクラスを使用することができ、第１には、管理通知で非同期インターフェースを使用してサーバへの接続を維持することができる。これらの通知は、管理目的を有する傾向のあるデータ、例えば、論理キュー内のジョブのビューを頻繁に変更することに使用することができ、第２に、ステータス変更通知は、ＴＴＬスキームおよびメッセージングシステム（例えば、ＭＳＭＱ）を使用して、あまり頻繁でない通知を配送保証とともに送信することができる。通知メカニズムではサーバサイドクエリをサポートするので、一般に必要とされるユーザ通知は、サーバサイドクエリを指定し、保証された配送メカニズムを使用することにより、実装される。

さらに、ＣＤＩは、アクセッサに基づく。これは、辞書インターフェースを公開しない。むしろ、データを取得するクエリメカニズムが用意され、また辞書インターフェースをエミュレートするためオブジェクトメタデータを取り出す機能が提供される。ＣＤＩは、さらに、多数のオブジェクトコレクションを集約してまとめる。アップレベルコレクションは、完全クエリサポートを行うために使用される。ダウンレベルコレクションは、列挙型サポートのために使用されるが、それは、すべての印刷コレクションは似ていなければならないからであり、クエリは、すべてのオブジェクトを列挙し、フィルタをそれらに適用することにより構築される。ＣＰＵに束縛されないメソッドは、非同期的と呼ぶことができる。

共通データインターフェースを使用すると、オブジェクトコレクションにアクセスすることができる。すべてのＣＤＩオブジェクトは、コレクションを通じてアクセスされる。すべてのコレクションにおいて、オブジェクトクラスの集合にアクセスすることができる。オブジェクトクラスは、オブジェクトのクラス、例えば、論理デバイス、プロトコルアダプタ、論理サーバを識別する。オブジェクトクラスは、プログラム名で識別される。プログラム名は、＜会社＞．＜クラス＞［．＜バージョン＞］の形式でなければならない。この名前を、オブジェクトを識別するためにロケール内で使用できる。この文字列は、ユニコード文字列として実装できるが、他の実装では、英語識別子を含むことができる。

例示され説明されている実施形態では、オブジェクトの特定のクラスは、常に、サーバの前のバージョン、またはダウンレベルサーバを表すコレクションを含めて、システムの存続期間全体にわたって同じプログラム名により識別される。

与えられたオブジェクトクラスは、多数の型からなる。型は、オブジェクトクラスと同じ方法でプログラム名により識別される。型は、多数のフィールドからなり、それぞれのフィールドは、プログラムフィールド名およびフィールド型により識別される。ある型のフィールドは、オペレーティングシステムのすべてのバージョンにまたがって、またどのようなプラットフォーム上でも不変でなければならない。型は、さらに、フィールドとともにコマンドもカプセル化する。コマンドは、文字列により識別され、多数の順序付けられた入力および出力引数を受け取る。

ＣＤＩを使用すると、サードパーティによりＣＤＩを通じて送信されるメッセージのインターセプションおよび拡張が可能になる。このため、これらのパーティはオブジェクト機能を監視し、拡張することができる。オブジェクトも、いくつかの呼び出しを、含まれているオブジェクトにリダイレクトするようにできる。

オブジェクト命名
例示され説明されている実施形態では、オブジェクトは、常に、オブジェクトのそのインスタンスを正確に識別する一意の正規名を有するが、このルールの唯一の例外は、ダウンレベルサーバ上のオブジェクトを表すコレクションである。

オブジェクトは、オブジェクトパスにより示される。オブジェクトパスは、常に、それが含まれるコレクションインスタンスのＧＵＩＤから始まり、したがって、｛ＸＸＸＸＸＸＸ｝＼｛ＹＹＹＹＹＹ｝は、コレクション｛ＸＸＸＸＸ｝内にＧＵＩＤ｛ＹＹＹＹＹ｝を持つオブジェクトを指す。アップレベルサーバ上のオブジェクトについては、パスは、｛ＷＷＷＷＷ｝＼＜ｓｅｒｖｅｒ＞＼｛ＸＸＸＸＸ｝＼｛ＹＹＹＹＹ｝となるが、ただし、｛ＷＷＷＷ｝はリモートコレクションＧＵＩＤであり、｛ＸＸＸＸＸ｝はオブジェクト｛ＹＹＹＹＹ｝が配置されているリモートコレクションである。

すべてのＣＤＩインスタンスは、ファイルシステム内の現在のパスに類似したデフォルトのコレクションの概念をサポートする。したがって、アプリケーション空間内でホスティングされているＣＤＩは、サテライトサンドボックスプロセスおよびアプリケーションドメインのすべてと同様に、ローカルマシン上のスプーラに設定されているデフォルトコレクションを持つことができる。完全修飾パスを持たない任意のオブジェクトの正規名は、デフォルトコレクション内で自動的に検索される。アプリケーション空間内で実装されたコレクション（例えば、ローカルサービスをバイパスするサーバへの直接ネットワークアクセス）がアクセスされる場合、完全修飾パス（つまり、「＼」で始まるパス）を使用しなければならない。

例示され、説明されている実施形態では、オブジェクトパス内の「＼」、「：」、「”」、「＾」および「．」は予約文字である。

キャレット文字（＾）は、後続文字をエスケープするために使用され、これにより、任意の文字を文字列内で表すことができる。有効なエスケープを以下の表にまとめた。

したがって、パスに「＼」を含まなければならないオブジェクト名を分離するために、「＼」を「＾＼」でエスケープすることが可能である。

フレンドリ名および名前解決パイプライン
オブジェクトは、さらに、状況に応じて、フレンドリ名（または表示名）を付けることもできる。オブジェクトは、以下のメカニズムを使用して必ず特定されなければならない。
● 表示目的のために、オブジェクトクラスのベースレスクエリをサービスと突き合わせて作らなければならない。このクラスと一致するすべてのローカルオブジェクトが返される。そのときからＵＩは、返されたオブジェクトの正規名を使用し、クラス表示名を示さなければならない。
● ユーザインターフェースに直接入力することが可能な名前（リモートサーバのＵＮＣ名を含む）の場合、ネームリゾルバと呼ばれるプラガブルなコンポーネントのシーケンスを与えることができる。アプリケーションでは、「フレンドリ名」を正規名に解決するためにこれらを呼び出す。既存のＡＰＩは、ネームリゾルバを使用して、ＯｐｅｎＰｒｉｎｔｅｒおよびＣｌｏｓｅＰｒｉｎｔｅｒなどのフレンドリ名ベースの呼び出しを正規名形式に変換する（名前解決は、時間がかかる可能性が高いため、キャッシング層を導入しなければならない）。
● ネームリゾルバのシーケンスは、与えられた名前マッピングの優先度を意味する。例えば、リモートＵＮＣ名が接続にアップグレードされる場合、それと同じ名前は、リモートキューを表すキューオブジェクトではなく、ローカルコレクション内の論理キューオブジェクトに解決する。
● アプリケーションは、最大のフル機能のネームバインディングが返されることのみ、またはフレンドリ名に対するすべての同じバインディングが返されることを選択することができる。可能なすべてのネームバインディングを返すのは、解決すべき多数のコレクションをロードする必要がある可能性があるため、非常に費用がかかる。
● 現在のルータアーキテクチャとは異なり、名前解決要素を用意することにより、コレクション全体が不必要にロードされるのを防ぐ。それらのオブジェクトについてフレンドリ名をサポートしたいすべてのコレクションは、名前解決要素も実装しなければならない。
● アプリケーションは、名前解決を実行するときに、目的を指定することが許される。例えば、管理アプリケーションでは、非キャッシュ情報のみを使用したいことを指定することが可能である。この場合、非キャッシュオブジェクトは、キャッシュバージョンよりも能力が低くても返される。

セキュリティ
例示され、説明されている実施形態では、セキュリティは、システムによって提供されるサービス層に緊密に結び付けられている。しかし、重要なトピックであり、実装について説明する前にモデルのグローバルな概要が望ましいので、セキュリティの仕組みの概要をここで説明する。

図４は、一実施形態による新しいスプーラセキュリティモデルの概念図を示す。新しいスプーラセキュリティモデルの１つの目標は、ＣＤＩをオブジェクトへの軽量内部インターフェースとして保持し、認証機能を実行しないようにすることである。さらに、ＣＤＩは、リモートコレクションを介してデータをサーバにルーティングすることができる。その後、サーバによって許可が実行される。したがって、この実施形態によれば、ＣＤＩルーティング層は、許可機能を備えない。最後に、ＣＤＩは、認証も許可も必要ない場合にアプリケーション空間内でも実行される。

そのため、認証は、アクセストランスポートおよびプロトコルと一致する方法でリモートアクセスアダプタにより実行され、許可は、適切なコレクションサービスによって実行される（またはリモートサーバに遅延される）。このアプローチの１つの帰結として、ＣＤＩおよびコレクションのすべては、無許可ユーザによるアクセス可能である。これを緩和しやすくするために、論理システムオブジェクトは、マシンの印刷システム全体へのアクセスを制御するアクセス制御リスト（ＡＣＬ）を備える。コマンドのバッチがリモートアクセスアダプタにより受信されると、論理システムオブジェクトに対しアクセスチェックが実行される。これらのコマンド（取得、設定、およびクエリ）は、アクセスチェックが成功した場合のみ実行を許可される。このオペレーションは、リモートアクセスアダプタにより受信されたパッチコマンドに対し１回だけ実行される。例示され、説明されている実施形態では、論理システムＡＣＬは、デフォルトでは、「Ｅｖｅｒｙｏｎｅ」（ただし「Ａｎｏｎｙｍｏｕｓ」ではない）となっている。管理者は、印刷サブシステムへのアクセスを制限する論理システム許可を変更することを許される。

例示され、説明されている実施形態では、論理マシンオブジェクトへの許可がないまま、リモートアクセスアダプタが通す必要のある論理システムオブジェクト上に特別な予約済みシステムリセットコマンドがある。論理マシンオブジェクトを使用することにより、管理者は、このコマンドを実行し、管理者を論理マシンＡＣＬに追加して戻す。このメカニズムは、管理者は、管理者がサブシステムに再びアクセスできなくなる論理機械オブジェクトへの許可拒否するのを防ぐ。

例示され、説明されている実施形態では、ローカルコレクションのすべてのオブジェクトは、関連付けられたＡＣＬを持つ。オブジェクト上のアクセスチェックでは、ちょうど、ＡＣＬに対するアクセスをチェックする。それぞれのオブジェクトインスタンスは、そのクラスの新しいオブジェクトについてデフォルトの継承可能なＡＣＬを備えるクラスオブジェクトを持ち、ＣＤＩは、クラスオブジェクトのコレクションを保持する。管理者は、与えられたクラスの新しいオブジェクトについてデフォルトのＡＣＬを用意するクラスＡＣＬを自由に修正できる。これにより、管理者は、オブジェクトへの作成権を他のユーザに移譲することができるが、それでも、作成時にデフォルトのＡＣＬをそのオブジェクトに適用することができる。

例示され、説明されている実施形態では、ＣＤＩは、オブジェクトのローカルコレクションをできる限り容易に書けるようにするサービス層を備える。このサービス層は、セキュリティインフラストラクチャをオブジェクト実装に提供し、そのオブジェクト実装は自由にそのインフラストラクチャを使用する。

図４には、パーミッションが変更された場合に新しいＡＣＬをすべての参加クラスに再帰的に適用するパーミッションエージェントは示されていない。このエージェントは、クラスオブジェクトへの変更をクラスのインスタンスに伝搬する役割を持ち、また、管理階層変更をオブジェクトインスタンスに伝搬する役割も持つ。

ＣＤＩアクセッサモデル
このインターフェースのより基本的な態様の１つはアクセッサモデルである。このメカニズムを使用することにより、共通データインターフェースおよびコレクションは、呼び出し側のデータ構造に初期値を設定できる。例示され、説明されている実施形態では、操作対象の印刷スプーラがアンマネージドコアサービスからなるため、ＣＤＩアクセッサモデルはアンマネージドである。印刷システムのいくつかのコンポーネントはマネージドであり、印刷システム内のデータにフルアクセスすることが望まれているため、マネージドコードアクセス層もある。

ＣＤＩアクセッサモデルの背後にある考え方は、ＣＤＩはクライアントオブジェクトの１つのコレクションとサーバオブジェクトの複数のコレクションとの間のブローカーであるということである。これは、クライアントおよびサーバが、それぞれのパーティにおいて転送を望むフィールドのみを使用してこの情報を交換するための効率的なメカニズムを実現する。

例えば、サーバコレクション、クライアントコレクション、およびＣＤＩと関連して、一実施形態により、この機能を実装する方法のいくつかの態様を示す図５を考察する。

この実施例では、サーバおよびクライアントは両方とも、同じメカニズム−タイプマップ−を介して公開または取り出したいデータを記述する。タイプマップには、それぞれのオブジェクトがサポートするさまざまな副型およびフィールドが記述される。フィールド毎に、記述するクラスのすべてのインスタンスについて与えられたプロパティを取得または設定する方法を認識するインターフェースが用意される。したがって、タイプマップが与えられると、クラスインスタンスのプロパティのすべてにアクセスできる。

クライアントおよびサーバクラスの記述が与えられると、ＣＤＩは的確な最適化を実行することができる。特に、ＣＤＩは、クライアントタイプマップおよびサーバタイプマップからそれぞれのフィールドおよび型を照合し、アクセスインターフェースのみからなる最適化されたタイプマップを作成することができる。２つのオブジェクトインスタンス上でこの最適化されたタイプマップが実行されると、要求されたデータはすべて、中間の記憶装置またはデータの検索を使用せずに、その２つのオブジェクト間で転送される。最適化されたタイプマップの目標は、ターゲットオブジェクトは正規構造を持つという事実を利用することである。与えられたコレクションについて、サーバサイドオブジェクトは正規構造を持つ。また、与えられたクエリに対し、システム内のすべてのオブジェクトから同じデータが一般的には望ましい。そのため、ソースオブジェクトの特定クラスとデスティネーションオブジェクトの特定のクラスとの間のバインディングは、常に同じである。さらに、ソースおよびデスティネーションオブジェクトは最終的にはシステムコンポーネントであり、それ自体正規構造であるため、それぞれのオブジェクトインスタンスは、軽量の方法で格納できる。

さらに、データを取り出せるサーバオブジェクトが１つしかないとすれば、これで十分であると考えられる。しかし、実際には、互換性のあるサーバオブジェクトの実装が多数ありえ、それぞれタイプマップを持つ。そのため、クライアントがタイプマップをＣＤＩに登録した場合、ＣＤＩは、ＧＵＩＤで検索できる最適化されたタイプマップ用に格納空間を作成する。その後、サーバサイドは、必要に応じて、それぞれの最適化されたマップを格納する。この目標は、クライアントがアプリケーション起動時にマップを登録することである。その後、システムは、クライアントがデータ取り出しを開始したときにその特定のクライアントタイプの周辺に最適化集合を構築する。

テンプレート派生タイプマップ
クラスインスタンスのアクセスオブジェクトを作成すると、それぞれのインターフェースの背後にあるそれぞれのインスタンスは１つのプロパティへのアクセス方法しか認識していないので、多数のコードが書かれる可能性がある。それぞれのインスタンスがデータを使用してサーバおよびクライアント内のプロパティにアクセスできるようにすることにより大量の作業を省くことができる（例えば、フィールドオフセットを使用することで、一般的に多くのオブジェクトにまたがるフィールドにアクセスできる）。これを実行すると、コーディングされなければならないアクセスオブジェクト実装の数を大幅に減らせる。

例示され、説明されている実施形態では、ＣＤＩは、さらに、ユーザがクラスを定義し、多数のメソッドまたはフィールドを作成し、その後、定義されることが望まれているフィールドまたはメソッドを公開するテーブルを書くために使用できるテンプレートライブラリも備える。テンプレートメカニズムは、クラスフィールド型またはメソッドシグネチャから直接、型情報を抽出し、アクセスオブジェクトインスタンスを自動的に作成する。これにより、クライアント（またはサーバ）は、ＩＤＬを書かずに、オブジェクトを公開することができる。オブジェクトは、その後、印刷システムによりサポートされるトランスポート手段でサポートされるようにでき、非同期呼び出しのメリットを自動的に受け取る。

以下に示した抜粋コードは、クライアントがサーバから取り出すことを望んでいる構造を定義する最も単純なメカニズムを示しているが、エラー処理は省略されている。

タイプマップメカニズムでは、さらに、呼び出し側がメソッドを指定することができる。以下の抜粋コードは、この場合にメソッドを定義する方法を例示し、エラー処理は省略されている。

例示され、説明されている実施形態では、テンプレートライブラリは、ＣＤＩの型からＣ＋＋の型へのマッピングのコアセットをサポートしている。このライブラリは、サードパーティにより拡張可能であり、したがって、テンプレートライブラリの一部を全く変更せずに、いつでも、新しい型を導入または精緻化することができる。

共通データインターフェースの使用
この節で取り上げられている資料は、上述の資料を基に拡張されるが、かなり低い水準で行われる。本明細書の残り部分は、一実施形態によるＣＤＩの使用および実装の低水準の説明をもっぱらとする。

ＣＤＩ型
ＣＤＩ型システムは、システムが保証する多数の標準型をサポートするように設計されている（例えば、これらは、システムによってサポートされている任意のプロトコル上で動作し、大半は、クエリに使用できる）。ＣＤＩ型システムは、さらに、設計時に新しい型を作成し、実行時にシステム内でそれらの型を使用するメカニズムも備える。

この目的のために、ＩｍｇＶａｒｉａｎｔ型が、以下の抜粋コードに示されているように定義される。システムのバリアント型のように、それは、型と無名共用体を持つ。しかし、これは、以下の表に示されているように、システムのバリアント型とは非常に異なる、基本型の集合をサポートする。

他の違いは、ＩｍｇＶａｒｉａｎｔ型は拡張可能であるという点である。これは、ＩｍｇＴｙｐｅを共用体でなく、ポインタとして定義することにより、実現される。この宣言は、以下の抜粋コードに示されている。

列挙型を新しい型として予約するために、ＩｍｇＴｙｐｅＲｅｓｅｒｖａｔｉｏｎグローバル変数を定義し、そのアドレスが、定義された型に対する保証された一意の識別子になる。同様に、システムは、システム自体の型をグローバル一意ポインタとして定義する。これにより、ローダを使用して、それらの型がアドレス空間において衝突しないことを保証する。

例示され、説明されている実施形態では、印刷システムは、バリアント型を操作するため以下のメソッドを用意している。

新しいＣＤＩプリミティブ型
ＣＤＩＩｍｇＶａｒｉａｎｔ型それ自体は、ＣＤＩにより定義された幾つかの新しい型を含むことができる。これらは、順に以下のとおりである。

ＩＩｍｇＩｍｕｔａｂｌｅＳｔｒｉｎｇ
これは参照カウント文字列である。この型は、ＣＤＩによりＢＳＴＲとの間で自由変換でき、文字列の効率的操作を行うことができる。そのインターフェースおよび作成関数は、以下の抜粋コードに示されている。

Ｖａｌｕｅメソッドは、不変文字列内に保持されている文字列を指すポインタを返す。呼び出し側は、この値を修正してはならないが、読み込むのは自由である。そのアドレスは、変化せず、文字列参照が保持されている間、解放も修正もされない。

ＮｅｗＩｎｔｅｒｆａｃｅメソッドを使用すると、呼び出し側は、同じ文字列への新しいインターフェースを要求することができる。これは、参照カウント問題を分離するのに役立つ。呼び出し側は、その文字列への単一スレッドインターフェースを要求することができる。この場合、新しいインターフェースでの参照カウントは連動しない。呼び出し側が、単一スレッドコンテキスト内で文字列の操作を何回も行うことを知っている場合、これにより、そのパフォーマンスを改善することが可能である。ＩｍｇＣｒｅａｔｅＳｔｒｉｎｇにより作成される初期文字列は、常に、フリースレッドである。

ＩＩｍｇＣａｎｏｎｉｃａｌＮａｍｅ
この型は、内部で、プラグインにより使用され。他の型への正規名参照を提供する。この型は、以下の抜粋コードに例示されている。

正規名は、オブジェクトパスの解析された要素からなる。それぞれの要素は、不変文字列として格納される。正規名は、パスから作成されるか、または不変文字列の集合から直接構成することができる。例えば、パス「＼｛ＧＵＩＤ｝＼ａｂｃ＾＼ｄｅｆ」については、正規名は、「｛ＧＵＩＤ｝」および「ａｂｃ＼ｄｅｆ」の２つの文字列からなる。このインターフェースでは、さらに、呼び出し側が正規名の部分文字列からパスを形成することができ、例えば、文字列「ａｂ＼＼ｃｄ」、「ｅｆｇ」を含む正規名を作成し、その後、パス「ａｂ＾＼＾＼ｃｄ＼ｅｆｇ」を取得することが可能である。

不変文字列のように、正規名も不変であり、スレッドまたは参照カウントを目的として、それから新しいエイリアスインターフェースを取得することができる。

ＩＩｍｇＭｕｌｔｉＶａｌｕｅｄＮａｍｅ
多値名は、正規名による参照を多数の異なるオブジェクトに返すために使用される。これは、２つのオブジェクトクラスの間の１−ＮまたはＮ−Ｎの関係を表すために使用される。そのインターフェースは、以下の抜粋コードに示されている。

多値名を正規名の集合から構成することができ、またそれぞれの正規名を取り出すことができる。不変文字列および正規名インターフェースのように、これは不変であり、参照カウントまたはスレッドを理由として、新しいインターフェースを取得することができる。

これらのインターフェースのナビゲートは、呼び出し側にとってはいくぶん複雑である可能性があるため、多値名は、ＧｅｔＮａｍｅｓＡｓＳｔｒｉｎｇｓインターフェースを通じてＢＳＴＲパスの配列として囲まれている正規名全体を取得するメカニズムを備える。返された多値文字列を解放するために、ＩｍｇＦｒｅｅＭｕｌｔｉＳｔｒｉｎｇ呼び出しが使用される。さらに、呼び出し側は、パスのマルチ文字列からマルチ名へまっすぐに進むことができる。これは、静的パスの集合から多値名を構成するうえで特に有用である可能性がある。

新しいバリアント型の登録
標準バリアント型は、常に、電線を経由して正しくマーシャリングを行い、すべて、システムに使用されるクエリ言語でサポートする。しかし、特にプロセス内の場合、バリアント型を拡張すると非常に有用と考えられる。これにより、点などの新しい値型、または文字列に変換する必要のない印刷可能領域を作成できる。代替えとして、コマンドの一部として取り出し、操作できるインターフェースを定義することができる。この目的のために、ＣＤＩは、ＶａｒｉａｎｔＣｏｐｙ、ＶａｒｉａｎｔＣｌｅａｒ、およびＶａｒｉａｎｔＣｏｎｖｅｒｔにより処理できるバリアント型を拡張するメカニズムを備える。

このインターフェースは、以下の抜粋コードに示されている。

ここで、登録されている型に対しすべてのオペレーションを実行する方法を認識するＩＩｍｇＶａｒｉａｎｔＥｘｔｅｎｄｅｒインターフェースで供給する必要がある。その後、さらに、このインターフェースによりサポートされる型の集合およびそのインターフェースで実行する変換の集合も供給する。その後、システムは、バリアント型の処理を拡張し、指定された型に対しそれらのインターフェースを呼び出すことを含むようにする。

標準バリアント型間の変換が用意された場合、リモーティング層も、有線でその適切なデータを正しくマーシャリングする。これにより、サーバオブジェクトと同じプロセス内で、または有線で、透過的に型を使用することができる。

タイプマップの登録
クライアントタイプマップは、構成された後、ＣＤＩに登録され、インターフェースは、そのタイプマップ登録を表すクライアントに返される。このオブジェクトは、さまざまなコレクションクラスにバインドするために使用される最適化されたタイプマップを蓄積する。その目的は、プロセスがあらかじめ使用するつもりの型すべてを登録してから、それ以降与えられたタイプマップを使用できるようにすることである。最適化されたタイプマップが構築されるときに、オブジェクトに対しデータのクエリを実行するのに要する時間は、フィールドを比較しなくてよいので、非常に短くなる。タイプマップを登録するための完全なインターフェースは、以下の抜粋コードに示される。

このインターフェースに使用される型は多数あるため、それぞれについて以下で検討する。

ＥＩｍｇＣｏｐｙＦｌａｇｓ
これらのフラグは、コピーオペレーションに関連付けられ、これにより、クライアントは、データをコピーする場合に遭遇した問題について知ることができる。これらのフラグのほとんどは説明を要しない。興味深いフラグとしては以下のものがある。
● Ｐｒｉｖａｔｅ−システムの外部でデータをコピーしてはならない。システムの一部と考えられる他のプロセスは、データを受け取ることが可能である。データは、決して有線で送信されることはない。
● ＮｏｔＭｏｄｉｆｉｅｄ−データがサーバ上でそれ以降修正されていないことを示す。これは、設定オペレーションを最適化する場合に使用できる。
● ＣｏｌｌｅｃｔＨｉｓｔｏｒｙ−これは、このフィールドへの変更の履歴を収集すべきであることをＣＤＩに指示する。デフォルトの動作は、フィールドの履歴を圧縮する。

ＩｍｇＥｘｔｒａＣｏｐｙＤａｔａ
これは、アクセッサに渡され、アクセッサはフラグを修正または挿入できる。また、設定が実行される場合に変更ハンドラをアクセッサに渡すためにも使用され、これにより、変更ハンドラは、プロパティ値が変更された場合に変更を送信することができる。

ＩｍｇＦｉｅｌｄＡｃｃｅｓｓ
これは、フィールドを指定する。構造体フィールドのほとんどは説明を要しない。クライアント上で記述を指定する必要はない。サーバ上では、このフィールドはリフレクションに使用できる。タグは、サーバ上で使用され、これにより、特定のフィールドを簡単に参照できる。タグを一意に保つのは、構造体を伝搬する側の役目である。

ＩｍｇＦｉｅｌｄＡｃｃｅｓｓｏｒｓ
これは、フィールドアクセッサの集合を指定する。

ＩｍｇＣｌａｓｓＤｅｓｃｒｉｐｔｉｏｎ
これは、クラスを記述し、取得アクセッサおよび設定アクセッサを指定する。

ＩＩｍｇＡｃｃｅｓｓｏｒ
このインターフェースでは、特定のフィールドにアクセスできる。ＩｍｇＶａｒｉａｎｔは、データを一時的に格納し、多数の異なる型のデータを受け渡すことができる。

ＩＩｍｇＴｙｐｅＭａｐｓ
このインターフェースを、クライアント側で解放することができる。次に、登録時に渡されたアクセッサインターフェースすべてが解放される。

ＩＩｍｇＣｏｍｍｏｎＤａｔａ
これは、タイプマップを登録するために使用できる中央インターフェースである。このインターフェースを、解放することができ、タイプマップ登録は有効なままである。

バッチ処理インターフェース
残りの各節（つまり、オブジェクトクエリ、オブジェクトコマンド、および通知）では、データアクセスインターフェースを詳細に取り扱う。この節では、オブジェクトとはどのようなものであり、クライアントはオブジェクトをどのように、取得し、設定し、クエリを実行するのかについて取りあげる。

クライアントがこれらのオブジェクトにアクセスするために使用するインターフェースは、以下の抜粋コードに示されている。

このアクセスインターフェースは、例えば、限定はしないが、以下を含む新しい概念を公開する。
● バッチ処理インターフェース（ＩＩｍｇＢａｔｃｈ）
● 非同期プログラミングメカニズム（ＩＩｍｇＡｓｙｎｃＲｅｓｕｌｔ）
● クライアントコレクションインターフェース（ＩＩｍｇＣｌｉｅｎｔＣｏｌｌｅｃｔｉｏｎ）
これらのインターフェースのそれぞれについて、まず要約で説明し、その後、潜在的呼び出しシーケンスの実施例を示し、これらの概念を具体的に説明する。

データアクセスインターフェースに発行されるすべてのアクションは、バッチ処理される。バッチ処理インターフェースは、ＩＩｍｇＣｏｍｍｏｎＤａｔａ：：ＧｅｔＤａｔａＢａｔｃｈ（）の呼び出しから戻り、その後、一連のアクションがバッチ処理インターフェースに発行され、最後にバッチが実行される。呼び出し側が単一アクションを発行することを望んでいる場合は、ただ１つのアクションのバッチ要求を作成するだけである。

Ｅｘｅｃｕｔｅメソッドが呼ばれるまでアクションはどれも実行されない。Ｅｘｅｃｕｔｅは、同期的に、または非同期的に呼び出すことができる（Ｅｘｅｃｕｔｅが呼び出されるか、またはＢｅｇｉｎＥｘｅｃｕｔｅが呼び出されるかに応じて）。呼び出し側は、完了インターフェース内を通ることができるか、またはＩＩｍｇＡｓｙｎｃＲｅｓｕｌｔインターフェースから返されたウェイトハンドルを使用することができる。このルールは、呼び出し側が完了インターフェースを通る場合、ウェイトハンドルを取り出せないというものである。呼び出し側は、クッキーインターフェースを通じて付加データを呼び出しに関連付けることができる。ＣＤＩは、Ｄｏｎｅメソッドが呼完了インターフェースで呼び出され、必要に応じてクッキーを解放できることを保証する。呼び出し側は、ＥｎｄＥｘｅｃｕｔｅ呼び出しを呼び出して、バッチ処理呼び出しの結果を取り出さなければならない。

呼び出し側は、バッチをシリアル、パラレル、またはトランザクションバッチとして開くことができる。非トランザクションバッチは部分的成功戻り値を持つことができるが、トランザクションバッチはそうではない。残念なことに、すべてのコレクションがトランザクションをサポートするわけではなく（トランザクションをサポートしていないダウンレベルのシステムと通信する可能性がある）、バッチのアクションのどれかが非トランザクションコレクションにクロスした場合、バッチ全体が失敗する。したがって、一実施形態により、トランザクションバッチ処理は、主に、システム内部で実行することができるか、または一度だけ、サーババージョンがポジティブに識別されている。

「Ｐａｕｓｅａｌｌｐｒｉｎｔｅｒｓ」のようなバッチ処理可能ないくつかのアクションについては、トランザクションであることは意味をなさないが、それは、１つのキューが一時停止できなかったため、どのキューも一時停止しないのではなく、キューの半分を一時停止しているからである。バッチの意味動作がシリアルである場合、バッチ内のアクションは、順次実行されることが保証される。バッチの意味動作が並列である場合、システムは、十分な資源があるか、または他の何らかの形でそうするのが最適である場合に、アクションを並列実行する可能性がある。これは、並列バッチ意味動作では、アクションはどれも任意の順序で失敗する可能性があることを意味する。トランザクションバッチは、さらに、順次意味動作を暗示する。

バッチ内のそれぞれのアクションは、増大するインデックスを返す。呼び出し側は、バッチ呼び出しの結果を取り出す必要がない場合に、インデックスを無視することができる。（それがトランザクションバッチである可能性があり、またバッチのステータスは、アクションのステータスである）。それぞれの呼び出しの結果は、バッチインターフェースの対応する「Ｒｅｓｕｌｔ」メソッドを呼び出すことにより取り出すことができる。この呼び出しでエラーが報告された場合、拡張エラー情報をバッチから返すことができる。

ｅｘｅｃｕｔｅの同期および非同期形式は、非同期の場合に、ＥｎｄＥｘｅｃｕｔｅ呼び出しから戻りステータスが返されることを除き同じである。バッチコマンドは並列実行することが可能であるため、バッチは、部分的な失敗結果を伴う可能性がある。それぞれのインデックスに対しクエリを実行し、どの呼び出しが失敗したか、呼び出し側で望む場合に、その失敗理由を正確に決定することができる。

実施形態による、バッチ処理インターフェースのメソッドを以下に要約する。
● ＧｅｔＯｂｊｅｃｔＤａｔａ−与えられたタイプマップおよび呼び出し側指定オブジェクトを使用して与えられたオブジェクト名からデータを取り出す。
● ＳｅｔＯｂｊｅｃｔＤａｔａ−書き込みを行うため与えられたタイプマップを使用して与えられたオブジェクトにデータを書き込み（クライアントコレクションとサーバコレクションとの間のアクセッサは逆転される）、そのオブジェクトからデータが取り出される。データがリモートデスティネーションに送信される場合には、内容は早い段階でオブジェクトからすっかりコピーされることに注意されたい。ローカルオブジェクトに対してデータが設定されている場合、それらの内容は、後から実際の設定が行われるときにコピーされる。
● ＱｕｅｒｙＯｂｊｅｃｔＤａｔａ−特定のオブジェクトクラスに対してクエリを発行する。クエリについて、以下で詳述する。クエリは、ただ単一オブジェクトではなくクエリの条件を満たすために多くのオブジェクトがコレクションから割り当てられることを除きＧｅｔコマンドと概念上ほぼ同様である。
● ＩｓｓｕｅＣｏｍｍａｎｄＴｏＯｂｊｅｃｔ−オブジェクトに対してコマンドを発行する。コマンドについて、以下で詳述する。コマンドは、与えられたオブジェクト上の特定の型に発行される。コマンド自体は、ユニコード文字列であり、入力引数の順序付きリストを受け取る。出力パラメータは、ＲｅｓｕｌｔＩｓｓｕｅＣｏｍｍａｎｄ呼び出しを通じて呼び出し側で取り出すことができる。
● Ｅｘｅｃｕｔｅ−これにより、ここまでバッチ処理されるすべてのコマンドが実行される。
● Ｃａｎｃｅｌ−ｅｘｅｃｕｔｅ呼び出し実行後、現在進行中のアクションをキャンセルする。これは、さらに、呼び出しが実行される前にバッチ処理インターフェースからコマンドを一気に消去する。

バッチ処理インターフェースは、Ｃａｎｃｅｌ呼び出しが戻った後、または同期Ｅｘｅｃｕｔｅ呼び出しが完了するか、非同期ＥｎｄＥｘｅｃｕｔｅが戻った後にしか、再利用できない。

図６は、バッチ呼び出しコマンドの図を示している。ここでは、ＩＩｍｇＤａｔａＢａｔｃｈインターフェースは実行すべきコマンドのリストを作成すると仮定する。

クエリ、コマンド、および通知は、後の節で詳しく取りあげる。したがって、オブジェクトの状態を取得し、その後、オブジェクトの名前およびコメントを変更し、それらの変更を再び適用するコードスニペットのサンプルを以下に示す。コードは、非同期コールバック形式で書かれており、非同期バッチ処理インターフェースを例示しているが、実際にはこのような複雑なことを必要としない。

オブジェクトのクエリ
この節では、オブジェクトのクエリについて説明する。ＩＤａｔａＡｃｃｅｓｓＢａｔｃｈにより公開されるインターフェースを以下に示す。

ｔｙｐｅＭａｐおよびｃｌｉｅｎｔＣｏｌｌｅｃｔｉｏｎパラメータについては、すでに説明されている。ｑｕｅｒｙＳｔｒｉｎｇパラメータは、クエリを制御する。ヌルであれば、クエリは、クエリベースにより指定されるように与えられた型のすべてのオブジェクトを要求する。ヌルでなければ、クエリのフィルタを指定する。クエリは、クエリベース、クエリクラス、およびクエリ文字列からなる。クエリ文字列については、少し後で取りあげる。クエリベースは、クエリのルートオブジェクトである、つまり、他のオブジェクトが存在すると考えられるオブジェクトである（ジョブ列挙のクエリベースは、プリンタまたはサーバオブジェクトとすることができる）。クエリベース関係は、通常、階層的でなく、関係的である（つまり、クエリベースから２レベル下でオブジェクトを列挙できない）。しかし、厳格な階層とは異なり、オブジェクトは、多くの異なるクエリベースの下に置くことができる。これは、基幹ストアが関係的であるという事実を反映している。クエリベースをサポートする主な理由は、クエリのダウンレベル列挙型ベースの実装で列挙型に対するルートオブジェクトを容易に見つけられることにある。しかし、クエリベースは、アップレベルの場合には、クエリの解析を複雑にする。

クエリおよび型のサンプルリストを以下の表にまとめた。コレクション内のオブジェクトは、コレクションのプログラム名を使用できないことに注意されたい。これらは、フレンドリ名に対し名前解決メカニズムを使用し、その後、内部で、数値オブジェクト名を使用してオブジェクトを参照するようにしなければならない。文字列は人間が編集する可能性が高いため、コレクションを、クエリに対するプログラム名を使用して指定することができる。

リモートコレクションは、ローカルマシンに対するクエリについてオブジェクト返す必要はないことに注意されたい。効率が悪すぎるため、すべてのサーバにクエリを実行することはできない。クエリ文字列は、与えられたオブジェクトが持たなければならない属性を指定するフィルタである。フィールドは以下の形式をとる。

Ｐｒｏｇｒａｍｍａｔｉｃ．Ｔｙｐｅ．Ｎａｍｅ．Ｖｅｒｓｉｏｎ：ＦｉｅｌｄＮａｍｅ
将来のクエリでは、データに埋め込まれたＸＭＬドキュメント内のデータにアクセスすることを許されることであろう。これらのクエリは以下の形式を持つ。

Ｐｒｏｇｒａｍａｔｉｃ．Ｔｙｐｅ．Ｎａｍｅ．Ｖｅｒｓｉｏｎ：ＦｉｅｌｄＮａｍｅ＼Ｎｏｄｅ＼Ｎｏｄｅ＼Ｐｒｏｐｅｒｔｙ
有効な演算子およびその優先度を以下の表にまとめた。

フィールドは、複数の定数とのみ比較することができる。以下に有効な定数を示す。
● 任意の整数値。整数を、１０進数または１６進数形式で表すことができる。
● 任意の浮動小数点数。
● 引用符で囲まれた任意のリテラル文字列。引用符を文字列の一部とする必要がある場合は、ＢＡＳＩＣスタイルの””を使用する。

有効なクエリを以下の表にまとめた。いくつかの共通アクセスオブジェクトの意味動作を簡素化するために、ダウンレベルサーバとの相互運用性を容易に確立できるクエリベースを正しく定義することができる。これらに含まれるのは、以下のとおりである。
● 印刷キュークエリ−クエリベースは、印刷キューを含むサーバオブジェクトでなければならない。
● ジョブオブジェクトクエリ−クエリベースは、ジョブを含むキューまたはサーバオブジェクトでなければならない。

一実施形態により以下の制約条件がクエリに適用される。
● クエリが数値型（整数または浮動小数点数）についてフィールドを比較する場合、実際のフィールドは数値（３２ビット整数、６４ビット整数、または倍精度数）でなければならない。
● クエリが文字列型についてフィールドを比較し、比較演算子がＣＯＮＴＡＩＮＳでない場合、唯一の有効なフィールド型は、ＢＳＴＲまたはＩＩｍｇＩｍｕｔａｂｌｅＳｔｒｉｎｇである。
● ＣＯＮＴＡＩＮＳ演算子は、文字列型にのみ作用する。単一値文字列については、等しいかどうかの検査となる。正規名については、パスが同じかどうかの検査となる。マルチ文字列については、マルチ文字列内の文字列が等しいかどうかの検査を評価する。多値名については、多値名の中の正規名のどれかにより表されるパスが包含演算子が参照する文字列に等しいかどうかの検査と同等である。
● ビット単位のＡＮＤ演算は、整数型にしか適用されない。

この説明を具体的にするために、以下の抜粋コードでサンプルを示す。これは一組の印刷オブジェクトのクエリを実行し、その後それらを列挙する。このサンプルでは、ＩＡｓｙｎｃＲｅｓｕｌｔインターフェースの待機可能な形式を使用する。ここでもまた、この場合には、これは必要ではないが、インターフェースの他の使用法を示している。呼び出し側に対してＩＩｍｇＣｌｉｅｎｔＣｏｌｌｅｃｔｉｏｎおよび列挙子を自動的に構築するテンプレートライブラリの機能を使用することに注意されたい。簡単のためエラー処理は省略される。

オブジェクトコマンド
オブジェクトのコレクションのクエリを実行するとともに、与えられたオブジェクトにコマンドを発行することができる。

オブジェクト上のコマンドは、オブジェクトが持つ可能性のある他のコレクションからの組み込み型を含む、型に結び付けられる。これにより、オブジェクトのコマンド集合を拡張できるか、または永続性ベースとすることができる。

一実施形態によれば、コマンドは以下のプロパティを持つ。
● コマンドは決してキャッシュされないが、データはキャッシュできる。
● コマンドは、失敗例外を超えて呼び出し側にパラメータを返すことができる。
● コマンドは、順序付けされた入力および出力パラメータの固定された集合を持つ。コマンドは、オーバーロードまたは拡張することはできない。コマンドの意味動作は、システムのバージョンが新しくなっても決して変わることはありえない。（コマンドは、陳腐化する可能性があり、最終的にサポートは打ち切られる場合がある。）
コマンドは、オブジェクト構成およびオブジェクト削除に使用される。オブジェクト削除の場合、定義済みの型およびメソッドが定義される−「Ｍｉｃｒｏｓｏｆｔ．ＧｅｎｅｒｉｃＯｂｊｅｃｔ．１」、コマンド「Ｄｅｌｅｔｅ」。削除コマンドは、パラメータを取らず、パラメータを返さない。すべての削除可能なオブジェクトは、このコマンドを公開する必要がある。すべての埋め込み可能なオブジェクトも、このコマンドを公開する必要がある。埋め込まれたオブジェクトの含んでいる側のオブジェクトが削除された場合、埋め込まれたオブジェクトのすべてに自分自身を削除するよう要求する。

セキュリティ保護可能なすべてのオブジェクトが公開する必要があるもう１つのコマンドは、「Ｍｉｃｒｏｓｏｆｔ．ＧｅｎｅｒｉｃＯｂｊｅｃｔ．１」コマンド「ＡｃｃｅｓｓＣｈｅｃｋ」であり、これは、単一のパラメータ−パーミッションオブジェクト−を取り、真または偽を返す。このコマンドは、自コレクションを通じてアクセスされる場合に埋め込みオブジェクトと同じセキュリティ意味動作を必ず強制するように組み込み型により使用される。

コマンド呼び出し結果から返されたパラメータの存続期間は、バッチの存続時間と同じである。バッチが、解放、キャンセルされるか、または他のアクションがバッチに対し実行された場合、コマンドパラメータは消去される。

最後に、コマンドインターフェースの使用例を以下に示す。これは、すでに発見されている印刷キューにストリームオブジェクトを要求する。

通知
通知を、さらに、オブジェクト、オブジェクトクラス、サーバ、またはコレクションから受け取ることもできる。このインターフェースは、さらに、クライアントからバッチ処理される。このインターフェースは以下に示されている。

このインターフェースは、多数の新しい概念を公開しており、とりわけ、例えば、限定はしないが、通知コレクション、通知オブジェクト、通知フィルタ、および通知チャネルが含まれる。このインターフェースは、他の２つのアクションＲｅｇｉｓｔｅｒＮｏｔｉｆｉｃａｔｉｏｎＣｏｌｌｅｃｔｉｏｎおよびＲｅｓｕｌｔＮｏｔｉｆｉｃａｔｉｏｎＣｏｌｌｅｃｔｉｏｎとともにバッチインターフェースを拡張する。

通知コレクションは、わずかに豊富な意味を持つクライアントコレクションである。これは、同質なクライアントオブジェクトのコレクションである。それぞれのオブジェクトは、タイプマップにより記述することができる。特定のオブジェクトに対する通知が発生した場合、またはオブジェクトが追加された場合、オブジェクトが取り出され、その後、値を入力される。オブジェクトに対する新しいデータがその中に入れられると、そのオブジェクト上のＥｎｄＮｏｔｉｆｙＣｈａｎｇｅｓメソッドが呼び出され、オブジェクトが更新されると、インプリメンタが必要な処理を実行することができる。

呼び出し側により指定された通知コレクションは、常に、逐次的に更新される（つまり、複数のスレッドにより呼び出される可能性があるが、一度に１つのスレッドしかそれを呼び出さない）。通知コレクションは、ＰｏｐｕｌａｔｅまたはＵｐｄａｔｅ呼び出しが、そのチャネル上で実行された場合のみ更新される。したがって、呼び出し側は、マルチスレッドアクセスをオブジェクトに対し実行している場合に、ＰｏｐｕｌａｔｅまたはＵｐｄａｔｅ呼び出しに適切なロックを掛けることによりオブジェクトを保護することができる。呼び出し側が通知に対しコールバックを指定した場合、一度に１つのスレッドのみがコールバックで実行することを保証される。

通知は、以下のように働く。Ｐｏｐｕｌａｔｅ呼び出しがチャネルに対し実行されると、Ａｄｄメソッドを通じて指定されたコレクションからオブジェクトが割り当てられる。その後、ＢｅｇｉｎＮｏｔｉｆｙＣｈａｎｇｅｓ呼び出しでオブジェクトが呼び出され、これが更新サイクルか、値設定サイクルであるかが、このときに、オブジェクトに渡される。

その後、通知チャネルを通じて通知が受信される。呼び出し側がコールバックを指定した場合、新しい更新が受信されると（またはチャネルがエラーを発生した場合に）コールバックが呼び出される。呼び出し側がコールバックを指定しなかった場合、ウェイトハンドルが利用可能になるか、またはＩｓＣｏｍｐｌｅｔｅｄメソッドについてチャネルがポーリングされることができる。通知は、サブシステムにより受信されるが、チャネル上でＵｐｄａｔｅメソッドが呼び出されるまでクライアントオブジェクトに適用されない。何らかの理由によりチャネルが途絶した場合、更新の際に適切なエラーが返される。

Ｕｐｄａｔｅの呼び出し時に、クライアントオブジェクトは、サーバ上で変更されたプロパティで更新される。新しいオブジェクトがサーバ上で作成されるか、または通知フィルタと一致する場合、コレクションは、Ａｄｄメソッドの呼び出しを受け取り、通知の理由がオブジェクトがこれでフィルタと一致したことであるのか、またはオブジェクトが新しいのかを知らされる。

同様に、オブジェクトがフィルタに一致しない場合、または削除されてしまっている場合、コレクション上でＲｅｍｏｖｅメソッドが呼び出される。

オブジェクトは、プロパティの直接呼び出しにより更新される。更新は、ＢｅｇｉｎＮｏｔｉｆｙＣｈａｎｇｅｓメソッドの呼び出しとＥｎｄＮｏｔｉｆｙＣｈａｎｇｅｓメソッドの呼び出しで囲まれる。

呼び出し側が通知の受信を停止することを望んでいる場合、受け取ったＩＮｏｔｉｆｉｃａｔｉｏｎＣｈａｎｎｅｌインターフェースを解放する。

コレクション内のすべてのローカルオブジェクトから２つのフィールドについて通知を受信するサンプルコードが以下に示されている。このサンプルコードは、ローカルコレクション内のすべてのプリンタに対するＳｔａｔｕｓおよびＮａｍｅフィールドの変更を受け取る。プリンタは、クエリの結果として画面上で更新されると仮定される。読みやすくするため、エラー処理は省略されている。

クライアントコレクション
ＣＤＩインターフェースの一態様、つまり、データをある種の中間データオブジェクトに書き込みデータセットを伝搬するのではなくクライアントコレクションおよびクライアントオブジェクトの値設定を行う選択には、いくつかの利点がある。

例えば、そうすることにより、通知およびデータ設定を、非常によく似た方法で取り扱うことができる。クライアントの観点からこれが意味することは、クライアントオブジェクトは、これら２つの場合において非常に容易に再利用できるということである。さらに、そうすることにより、クライアントコードは極めて効率的なものとすることができる。特に、データがクライアントオブジェクトの中に集められた後、固有の方法で構造体内のオフセットとして参照される。データが中間コレクション内に格納される場合、クライアントは、順にデータをいくつかのクライアントオブジェクト内にコピーして操作しなければならないか、またはデータをコレクションから毎回取り出さなければならない。

さらに、クライアントコレクションおよびクライアントオブジェクトの値設定により、クライアントコード内の失敗条件は、コレクションからコピーされるときではなく、データが設定されるときに制限される。これは、クライアントコードの複雑さを実質的に低減する可能性を有する。中間コレクションが使用される場合、コレクション内のデータがアクセスされるときには必ず、失敗の可能性がある。

さらに、クライアントコレクションおよびクライアントオブジェクトの値設定により、複数の種類の中間コレクションを使用することができる。本質的に、このメカニズムは、完全に柔軟なビルダパターンをカプセル化する。これは、汎用「クライアント」がタイプマップを動的に構築し、それを、お気に入りの任意の種類の中間コレクションにマップすることができることを意味する。これは、マネージドデータプロバイダ用のデータセットオブジェクトを構築するために使用することが可能であろう。それとは別に、データのＸＭＬビューを構築するために使用することも可能であろう。これは、中間データセットが間に挿入されることにより生じる忠実度またはパフォーマンスの喪失なしで実行することが可能である。さらに、関連するプロパティは、クライアントコレクションおよびクライアントオブジェクトの値設定により、クライアントコレクションは、実際に、容易にリモーティングを行える形式でデータを準備するアクセスアダプタとすることができるというものである。しかし、ネガティブな面では、クライアントオブジェクトは、取り出したいそれぞれのプロパティに対するアクセッサを公開することを強制される可能性がある。

動的タイプマップ
例示され説明されている実施形態を使用することにより、ユーザが１つのオブジェクトインスタンスを所有することを望んでいるが、呼び出し条件に応じてサーバオブジェクトから異なるフィールドを動的に取り出すことができることを望んでいる状況に対処することができる。このようなことが生じる可能性のあるケースは２つあり、１つは、多数のプロパティを備える具体的オブジェクトがあるが、呼び出し側が与えられた呼び出しで伝搬されることを望んでいる実際のプロパティが動的である場合、もう１つは、呼び出し側が実際にデータを完全に動的に取り扱いたい場合である。それぞれ、例示され、説明されているアーキテクチャ内に解決策がある。

第１の問題を解決するために、例示され説明されている実施形態において、それぞれのプロパティに関連付けられているタグを使用して、クラスから部分集合動的タイプマップを構築する。これらのタグは、テンプレートライブラリの一部として指定することもできる。テンプレートライブラリは、指定されたタグのみと一致する部分的タイプマップを取り出す。この解決策は、以下の抜粋コードに示されている。

完全に実行時に決定されるプロパティの完全にランダムな集合をリモートサーバから取り出せるようにすることも、タイプマップインターフェースを通じて実現できる。しかし、この場合、単にプロパティの集合を１つのクラスに束縛することはできない。この場合、低レベルのタイプマップインターフェースのパワーと柔軟性が実際に効くのである。この場合、呼び出し側は、すべてのインターフェースはオブジェクトインスタンスでもあるという事実を利用し、バリアント型を直接使用することができる。この概念は、図７に示されている。

そこでは、それぞれのインターフェースは、実際に、静的なメソッドまたはフィールドではなく、オブジェクトを指す。それぞれのオブジェクトは、最終デスティネーションオブジェクトを操作する方法に関するある種の状態を保持する。この場合、これは、デスティネーションオブジェクトが保持するオブジェクト配列へのインデックスを保持する。デスティネーションオブジェクトの配列のサイズは可変であり、デリゲートオブジェクトおよびタイプマップは両方とも、動的に構築できる。したがって、このメカニズムを使用することにより、呼び出し側は、ソースオブジェクトにバインドすることができ、任意のソースオブジェクトをオンザフライで構築できる。

例示され説明されている実施形態では、このメカニズムは、実際には完全に汎用的である。これらのインターフェースがＸＭＬドキュメントの構築、データセットの作成、または画面へのデータの書き込みに参加できない特定の理由はない。また、これを使用することで、オブジェクトのコレクションを任意の形式で構築することもできる。これは、ｌｏｎｇｈｏｒｎＡＰＩまたはその他のデータアクセスＡＰＩにブリッジする際に極めて有用である。

このスキームを実装するコードは以下に示されており、バッチインターフェースを通じて１つのオブジェクトにアクセスすることを含む（エラー処理は省かれている）。

属性テンプレートライブラリおよび継承
テンプレートライブラリの興味深い態様の１つは、オブジェクト間の継承（複数の継承を含む）をサポートすることである。これは、サーバ上に比べて、クライアント上ではあまり使い道がない。サーバ上では、これにより、共通機能および対応するフィールドおよびメソッドを基本クラスに格納し、必要に応じて派生クラスに引き込むことができる。

継承をサポートすることに加えて、このライブラリは、仮想メソッドを正しく処理する。つまり、基本クラス内の仮想メソッドを、基本クラスタイプマップ内で参照することができ、したがって、基本クラス内の仮想メソッドは、派生タイプマップ内の派生クラスを正しく呼び出す。型の正常に機能している集合の実施例は、以下の抜粋コードに示される。このコードは、単に、クラスの構造を示しているだけである−簡単のため実装は省略されている。

この実施例では、派生クラスは、１つの仮想メソッドをオーバーライドし、２つの純粋メソッドを実装する。他のフィールドおよびメソッドはすべて、基本クラスから引き込まれる。派生クラスのメソッドは、テーブルの定義が基本クラスで定義されているテーブルから実際に引き込まれるとしても、そのまま呼び出される。

派生テーブルは、そのテーブル内の「Ｉｎｈｅｒｉｔｓ」フィールドとともに基本クラステーブルの定義を引き込む。基本クラスおよび基本クラステーブルの拡張は、派生クラスのテーブル内に即座に反映される。したがって、これらのテーブルは、真の多重継承を実装するものとして示すことができる。

カーソル
カーソルは、呼び出し側が単一要求としてではなく、サーバから一度に１チャンクずつデータを取り出すためのインターフェースである。これは、列挙する必要のあるオブジェクトが多数、サーバ上にある場合に特に有用である。これは、１回の呼び出しによりネットワーク上で返さなければならないデータの量を減らし、サーバサイドでのワーキングセットを減らす。オブジェクトのコレクションが非常に大きい場合、さらに、これにより、クライアントはオブジェクトすべてをメモリに格納する必要がなくなる。その代わりに、クライアントは、テーブルの中へのカーソルを保持し、必要に応じてさらに多くの行を取り出すことができる。この特定の実装の実施例では、カーソルは、以下のさまざまな理由からＣＤＩでは現在実装されていない。
● サーバ上に保持されているオブジェクトの数は、典型的なデータベースに格納されるのとほぼ同じ桁数とはいえない。クライアントがデータのコピーを格納するのに十分なメモリを持たないことは極めてありそうにない。
● サーバ上の多くのオブジェクトは、ほとんどのキューがジョブを受け取るので、必ずアクティブである。したがって、ワーキングセットは、データベースの場合ほど考慮しなくてよい。
● ネットワークトラフィックは、２つのパスでクエリを実行することにより任意に低減でき、その初期クエリは、それぞれのオブジェクトの正規名を取り出し、その後、ＧｅｔＯｂｊｅｃｔＤａｔａ呼び出しの第２の集合で、それぞれのオブジェクトに対するデータを取り出すことができる。複数のＧｅｔＯｂｊｅｃｔＤａｔａ呼び出しを適宜１つのまとまりにできるので、それぞれのオブジェクトからデータを取り出すためにネットワーク内を行き来する必要がない。
● 呼び出し側は、正確なクエリフィルタを指定できるので、データセットのサイズをかなり小さくできる。例えば、クライアントスプーラは、すべてのジョブを列挙することなく、指定されたユーザに属すジョブを列挙することができ、それにより指定されたユーザに属さないものを除去することができる。
● 呼び出し側は取り出したいフィールドを正確に指定できるため、データの量は、不自由な情報レベルシステムを持つ現行システムに比べてかなり低減できる。例えば、現在、キュー内のジョブの数を取り出すためには、呼び出し側で、デフォルトのＤＥＶＭＯＤＥおよびセキュリティ記述子も含む、ＰＲＩＮＴＥＲ＿ＩＮＦＯ＿２を指定しなければならない。
● インターフェースは、現在、通知を除き、ワイヤレベルでステートレスである。カーソルは、サーバ状態を増やす傾向がある。カーソルに必要な状態を保持するためのオーバーヘッドは、特に緩和の数が指定された場合に、それから得られるメリットを超えることが考えられる。

しかしながら、特に印刷システムがドキュメントアーカイブを実行するようにスケーリングされる場合、または非常に大きな印刷サーバを少数がアクティブである非常に多くのキューを処理するようにできる場合に、システム内のある点においてカーソルを実装することが望ましいことがある（オブジェクトをいたずらにメモリ内に引き込むことを回避することは、このシナリオでは非常に重要になる）。この節では、クエリに対しかなり安価な前進のみカーソルが得られるメカニズムを説明する。

通知に関しては、通知はクライアントインターフェースに対する変更を必要としないと考える。ワイヤインターフェース（ｗｉｒｅｉｎｔｅｒｆａｃｅ）は、値設定されたデータをチャンク単位でクライアントに送信し、その後、クライアントオブジェクトの更新を開始する。最適なパフォーマンスが得られるように、更新は元の初期値設定と交互に並べられる場合がある。

クライアントカーソルに関して、以下の事項を考察する。例示され、説明されているシステムの１つの目標は、可能な限りステートレスワイヤプロトコルを保持することである。したがって、カーソルによりオブジェクトのどのような集合が取り出されるかを定義し、その後、それらの目標を達成する実装を提供する。カーソルの妥当な意味動作は以下のとおりである。
● カーソルは、前進のみである。
● カーソルにより取り出されるオブジェクトの集合は、カーソルが作成されたときのクエリと一致するオブジェクトの数からその後削除されたオブジェクトの数を差し引いた数である。これは、カーソルが最初に作成された後作成されたオブジェクトを含まない。これは、遅いクライアントが、オブジェクトの集合が急激に変化する場合にサーバに対して決して終了しないという状況を防止する。

説明されている解決策は、増加一途のシーケンスカウントをそれぞれのオブジェクトとともに保持することである。カーソルが確立されると、現在の最大シーケンスカウント数は、クライアントにより記録される。オブジェクトの集合が返され、最後のオブジェクトの最大シーケンスカウントが記憶される。オブジェクトの次の集合が取り出される場合、このクエリでは、まず、Ｔｉｍｅｓｔａｍｐ＞ｌａｓｔ＿ｍａｘおよびＴｉｍｅｓｔａｍｐ＜ｉｎｉｔｉａｌ＿ｍａｘである、次のＣＨＵＮＫＳＩＺＥオブジェクトを取り出す。

結局、サーバ上の要求毎にこのクエリを実行するオーバーヘッドが、サーバ上のカーソルコンテキストを保持するために必要な接続を維持する平均オーバーヘッドを超えることになる可能性がある。解決策の妥協案は、ＧＵＩＤにより識別されたサーバ上でカーソルのキャッシュを保持することである。クライアントは、タイムスタンプおよびＧＵＩＤをサーバにサブミットする。サーバサイドカーソルがまだキャッシュ内に存在している場合、当然その状態が使用される。そうでない場合、それは、タイムスタンプクエリを実行して復元され、キャッシュ内に再度挿入される。これにより、サーバは、低速なクライアントに対して手軽に状態を破棄することができる。

主要な目標が個々のネットワーク要求のサイズを低減し、クエリに対しサーバ上で必要なワーキングセットを縮小することであると仮定した場合、ＣＤＩインターフェースは、必ずしも変更を必要とせず、リモートアクセスアダプタおよびローカルアクセスアダプタは、クライアントがクエリを発行したときに透過的にサーバサイドへのカーソルを使用するだけである。

非常に大きなデータセットの場合、クライアント側で、一度にその状態全体をメモリに保持することのないようにカーソル自体を操作したい場合がある。この場合、カーソルを表すインターフェースは、ＣＤＩインターフェースから取り出される。暗黙のうちに単一カーソルは大量のデータを取り出すので、この呼び出しをバッチ処理させることは必要ない。

フレンドリ名解決
さまざまな点で、フレンドリ名を正規名に変換するという概念について説明してきた。フレンドリ名は、オブジェクトインスタンスの人間が読み取り可能なものであり、例えば、ｓｅｒｖｅｒ．ｍｙｄｏｍａｉｎ．ｏｒｇというサーバあるという概念はフレンドリ名である。正規名は、サーバと通信するために使用するプロトコル、論理サーバがホスティングされる物理サーバ、および論理サーバオブジェクトインスタンスへの完全に一義的な参照を識別する完全に一義的な名前である。例えば、上記のフレンドリ名は、「｛６３３１５ｃａ９−ｂｅｆ６−４ｃｃ５−９１５２−０５ｅ３６９ｄ３ｄ６９１｝＼ｗｗｗ．ｒｅａｌｈｏｓｔ．ｎｅｔ＼｛ａ４ｂ６ｅ９５６−ｄｅｅ０−４６ｄ０−ｂ８２ｃ−７ｆｆｃ８ｆ８１４ｅ９５｝＼｛ｆ０９１ｂ５ａ１−ａｄ２ａ−４ｄｆｅ−９ｄ３７−９５９２ｂ１ａｅ２５１２｝」という正規名に対応している可能性がある。正規名は、完全に一義的であるという利点を持ち、コンピュータにとっては優れたものである。しかし、人間にとっては容易に入力できるものではない。

正規名が与えられた場合、これが関連している場合にオブジェクトのフレンドリ名を決定することは容易である。オブジェクトは、単純に、オブジェクトから取り出すことができる「Ｏｂｊｅｃｔ：Ｎａｍｅ」などのプロパティを持つ。しかし、システムがフレンドリ名しか持たない場合、正規名を決定できなければならない。この節では、このインターフェースのアプリケーション呼び出し可能側について説明する。ネームリゾルバを実装することについては、以下の「フレンドリ名解決プラグイン」という表題の節で説明する。クライアントのフレンドリ名解決インターフェースは、以下に、一実施形態に従って示されている。

呼び出し側が、フレンドリネームリゾルバを取得することを望んでいる場合、ＩＩｍｇＣｏｍｍｏｎＤａｔａインターフェース上でＧｅｔＦｒｉｅｎｄｌｙＮａｍｅＲｅｓｏｌｖｅｒメソッドを呼び出す。フレンドリ名は、２つの論理メソッドのみ（およびそれらの１つに対する非同期呼び出しパターン）を公開する。

ＲｅｓｏｌｖｅＮａｍｅ
解決すべき名前、例えば「ｓｅｒｖｅｒ．ｍｙｄｏｍａｉｎ．ｏｒｇ」および名前のクラス、例えば「Ｓｅｒｖｅｒ」が与えられた場合、名前解決インターフェースは、フレンドリネームリゾルバプラグインを呼び出して、ＩＩｍｇＣａｎｏｎｉｃａｌＮａｍｅＩｔｅｒａｔｏｒインターフェースとしてプラグインにより返される有効なすべての結果を返す。ネームイテレータ（ｎａｍｅｉｔｅｒａｔｏｒ）を使用することにより、呼び出し側は、フレンドリ名に対応するすべての正規名を取り出すことができる。正規名を何回も返せるようにする理由は、同じオブジェクトが異なるパスを介して見える場合があるからである。例えば、同じサーバに対し、ＳＯＡＰとＲＰＣの両方を介してアクセスできる。

ＲｅｓｏｌｖｅＮａｍｅメソッドは、特定のオブジェクトにアクセスする方法を調べるために複数のプロトコルに対しクエリを実行しなければならない場合があるため、長い時間を要することがある。そのため、このインターフェースは、さらに、ＢｅｇｉｎＲｅｓｏｌｖｅＮａｍｅおよびＥｎｄＲｅｓｏｌｖｅＮａｍｅメソッドの形で非同期呼び出しパターンも用意する。これらは、バッチＢｅｇｉｎＥｘｅｃｕｔｅおよびＥｎｄＥｘｅｃｕｔｅメソッドにより使用されるのと同じ非同期呼び出しパターンを使用する。呼び出し側は、コールバックインターフェースを指定するか、またはＩＩｍｇＡｓｙｎｃＲｅｓｕｌｔの戻りを介して返されるシステム待機可能ハンドルを取得することができる。これらは、対応する正規名すべてが解決されたときに通知を受ける。

ＲｅｍｏｖｅＮａｍｅ
ネームリゾルバは、名前解決は潜在的に非常に遅く、コストがかかるため、フレンドリ名に解決された名前のキャッシュを保持する。キャッシュは、時間がたてば自動的にフラッシュされる。名前解決がその後キャッシュ内にあるのと同じ名前を解決できなくなった場合、それらの名前関連付けは駆除される。この動作は、一定時間の経過後、名前は陳腐化したとみなされることである。呼び出し側が再び名前を要求した場合、陳腐化した名前はネームリゾルバにより返されるが、名前解決の他のラウンドのものをネームリゾルバプラグインに発行し、そのどれもが名前を返さない場合には、その名前がキャッシュから削除される。これは、名前に対する非常に高速な解決を実現するが、陳腐化した名前バインディングが一定期間返される可能性がある。

呼び出し側は、フレンドリ名を解決するが、その後、ＣＤＩを介してアクセスされたときに正規名が失敗するため名前が陳腐化していると独立に決定する可能性がある。同じフレンドリ名を再び要求すれば、同じ陳腐化した名前を取得する可能性がある。これを防ぐために、ＲｅｍｏｖｅＮａｍｅメソッドを通じて、陳腐化した名前をキャッシュから明示的に削除することができる。呼び出し側がこれを実行しない場合、名前は、最終的に、クリアされるが、これがオプションの最適化である。

拡張オブジェクトの動作
前の節の目標は、ＣＤＩのインターフェースおよび基本概念を提示することである。この提示の目標は、主に使用法の観点から明らかにすることであった。前の節で提示されているようなインターフェースは、アプリケーション作成者が、印刷システム内のオブジェクトに対する通知の取得、設定、クエリ、および受信を行うのに十分強力なものである。この節が目指すのは、新しいセキュリティおよび発見機能を使用可能にするためオブジェクトにより公開できる付加的動作を提示することである。

オブジェクトファクトリ、オブジェクトクローニング
この節では、システム内に新しいオブジェクトを作成し、それらのオブジェクト（適用可能であれば）を他のシステムに転送し、新しいオブジェクト作成ユーザインターフェース（ＵＩ）を挿入できるようにするために使用できるメカニズムを取りあげる。ファクトリオブジェクトを除くシステム内のすべてのオブジェクトは、このメカニズムをサポートしなければならない。このメカニズムは、図８に示されており、以下の説明の基盤として使用される。

オブジェクト作成およびクローニングメカニズムでは、以下を行えるドライバストアがあると仮定する。
１．ＵＩアセンブリ厳密名に基づきＵＩアセンブリをクライアントまたはサーバに供給する。
２．コレクションアセンブリ厳密名に基づきコレクションアセンブリをサーバ済度に供給する。

厳密名およびそれをバージョニングに関係付ける方法の正確な定義は、別に説明する。ただし、文脈上、以下で考察する。

厳密名は、使用されているアセンブリの実際のインスタンスおよび１つのモニカ内のアセンブリのパブリッシャを両者とも一意に識別する名前である。この一実装は、公開鍵暗号法を使用してアセンブリの内容に署名し、その後その署名の暗号ハッシュ（通常は、ＭＤ５ハッシュ）を実行し、そのハッシュ（またはハッシュの一部）を名前に埋め込む。この名前はアセンブリの内容に実際に結び付けられているだけでなく、アセンブリのパブリッシャにも結び付けられている。誰かが異なる機能で他のアセンブリを作成し、非常に大きな数（１２８ビットハッシュでは１０³⁸）のアセンブリを作成してそれぞれについてプロセス全体を試みることなく自分のアセンブリの厳密名を使用可能な知られている手法はない。

本質的な考え方は、それぞれのコレクションは、オブジェクトインスタンスの集合に対するファクトリオブジェクトとして機能するよく知られているオブジェクトインスタンスを提供するというものである。新しいオブジェクトに対する構成パラメータはあらかじめ知ることができないため、オブジェクトは、新しいオブジェクトインスタンスを作成するＣｒｅａｔｅ（）と呼ばれるコマンドを使用してカスタム型（この実施例では、Ｃｏｍｐａｎｙ．Ｔｙｐｅ．１）を実装する。呼び出し側がファクトリオブジェクトおよびファクトリ型を知っている場合、新しいスプーラにおいてそのクラスのオブジェクトを作成することができる。

クローニングは、Ｍｉｃｒｏｓｏｆｔ．Ｏｂｊｅｃｔ．１型をサポートするオブジェクトによりサポートされる。このオブジェクトによりサポートされるフィールドは、ＣｏｌｌｅｃｔｉｏｎＳＮ、その作成に使用されファクトリオブジェクトインスタンスおよび３つのコマンド、ＧｅｔＳｔｒｅａｍ、Ｄｅｌｅｔｅ、およびＵｐｄａｔｅＦｒｏｍＳｔｒｅａｍを含む。ＧｅｔＳｔｒｅａｍは、オブジェクトの内容をストリームの中に取り出し、Ｄｅｌｅｔｅは、オブジェクトを削除し、ＵｐｄａｔｅＦｒｏｍＳｔｒｅａｍは、それに渡されるストリームに基づきオブジェクトの状態を更新する。オブジェクトは、任意の種類のストリームをサポートできるが、相互運用性の理由から、ストリームはＸＭＬであるのが理想的である。

オブジェクトのクローニングが行われる場合、オブジェクトインスタンスに対し、そのコレクションＳＮおよびファクトリオブジェクトインスタンスのクエリが実行される。これらは、ストリーム内に格納され、その後、ストリームにより表されるようなオブジェクトの状態が格納される。

オブジェクトを復元するには、ドライバストアからコレクションを取り出し、ファクトリオブジェクトを特定する。ファクトリオブジェクトは、ＣｒｅａｔｅＣｌｏｎｅコマンドを通じてストリームの残り部分に渡される。これにより、ファクトリは同一のオブジェクトインスタンスを作成する。

システム内のすべてのオブジェクトは、切り離されたＵＩ作成およびクローニング機能をサポートしなければならないことに注意されたい。しかし、簡単のため、ファクトリオブジェクトおよびクローニングインターフェースは、説明および図を簡略化するため残りの節には示されていない。

階層
階層は、通常、２つの目標を達成する。１つは、探索空間を細分し、オブジェクトの効率的な特定を行えるようにすることである。ＣＤＩを複数のコレクションに分割する機能、与えられたクラスをサポートしている場合にコレクションのみをロードできる機能、および一連のアクションを与えられたサーバに送ることができる機能は、この目標をすでに達成している。もう１つは、システムまたは管理者が複数のオブジェクトを論理階層にグループ化できるようにすることにより異種オブジェクトを管理し、発見できるようにすることである。すべてのオブジェクトが階層内のどこかに配置されているため、階層を利用することにより発見することが可能である。そのため、システム内のすべてのオブジェクトが発見されるまでユーザがそれぞれのオブジェクト内へ順繰りにドリルダウンすることができるブラウザを構築することができる。階層は、さらに、管理アクションによりオブジェクトの部分木にセキュリティ変更を適用できるようにすることによりシステムのセキュリティのビューも実現できる。このメカニズムは、ファイルシステムでセキュリティを実装する方法に類似している。

階層は、通常、オブジェクト間の関係を示すためには有用でない。純粋な階層では、１つのオブジェクトは他のちょうど１つのオブジェクトの下にしか配置できない。そのため、ジョブは、プリンタおよびサーバの両方に属すことはできない。また、階層は、オブジェクト間の多対一の関係を効率よく示すこともできない。関係モデルは、オブジェクトの関係を示すうえでかなり強力である。ＣＤＩを使用すると、バッチ処理インターフェース（他のオブジェクトにより包含されると論理的に考えられるオブジェクトを返す）上のＱｕｅｒｙアクションのＱｕｅｒｙＢａｓｅメカニズムを通じてこれを効果的に行うことができる。

階層の第１の目標は、すでにＣＤＩおよびリモートアクセスアダプタルーティングメカニズムにより達成されており、またＣＤＩの関係メカニズムは、オブジェクト関係を表すためにとにかくより強力であるため、システム内の異種オブジェクトの管理および発見をサポートするメソッドだけがあればよい。既存のモデルはかなりの割合のケースについて十分に強力であるため、すべてのオブジェクトが必ず階層をサポートするとは限らないことに注意されたい。サービス層により提供されるデフォルトの永続可能なストアは、階層を自動的にサポートする。したがって、ローカルオブジェクトに対する最も単純な実装は、自動的に階層をサポートする。発見可能な階層をサポートするが、修正可能な階層をサポートしない場合もある。例えば、現在のスプーラＲＰＣインターフェースをサポートするリモートアダプタを使用すると、クライアントはサーバの下でプリンタ、プリンタの下でジョブを発見できる可能性があるが、編成を変更することは許されない。

階層は、１つの型を持つＬｉｎｋクラスと呼ばれる新しいＣｌａｓｓを導入することにより表すことができ、リンク型は、何らかの方法で現在のオブジェクトの「下に」あると考えることができるオブジェクトの正規名である１つのプロパティＯｂｊｅｃｔを持つ。現在のクラスから階層的にトラバースされうるオブジェクトインスタンスを発見したい場合、クエリベースとしてトラバースされるオブジェクトインスタンスを持つＬｉｎｋｓクラスについてクエリを実行する。階層内に設定される多数のオブジェクトの実施例が図９に示されている。これは、ありとあらゆるマシン上のルートオブジェクトとなる、論理システムオブジェクトを除外する。

リンククラスクエリの実装は、永続的オブジェクトコレクションサービスにより自動的に実現される。しかし、発見可能な階層を公開することを望んでいるコレクションでは、リンククエリに値を設定できる。例えば、ＤＳオブジェクトを公開するコレクションは、それぞれのＤＳオブジェクトの子を列挙し、その後、親オブジェクトが列挙された場合にそれぞれのオブジェクトの区別名をリンクタブの中に投入できる。

セキュリティおよび階層
階層は、発見可能性とセキュリティを規定する。ＣＤＩは、オブジェクトのセキュリティ記述子が変更された場合に、子オブジェクトを通じて実行され、セキュリティ継承ルールを強制することになるセキュリティエージェントを備える。セキュリティは、永続的オブジェクトコレクションサービスにより自動的に処理され、セキュリティエージェントは、このコレクション内のオブジェクトに対し自動的に実行される。

論理グループと呼ばれる特別なオブジェクトが用意され、管理者はオブジェクトの任意の集合をその下に置くことができる。これにより、管理者は、論理グループ上のＡＣＬを変更し、その論理グループの下にあるすべてのオブジェクトにそれらのＡＣＬを自動的に適用させることができる。これにより、管理者は、有用とわかっている管理階層をサーバ上で適用し、その後、セキュリティルールをその階層に適用することができる。

セキュリティおよびクラスミックスイン
階層によりセキュリティを制御するとともに、システムでは、さらに、クラスによりセキュリティを制御することもできる。このため、作成者／所有者管理アクセス権をシステム上で作成されたすべてのジョブに付与するなどの機能を使用できる。現行システムでは、クラスルールは、システムにハードコードされているが、将来、どのクラスでもミックスインが使用可能になる。

図１０に示されているように、クラス継承は、セキュリティ階層内で編集可能なクラスオブジェクトを公開することにより実現される。これらは、それぞれ、作成時にそれぞれのクラスに適用されるデフォルトのセキュリティ記述子を最初に含むことになる。他のすべてのオブジェクトと同様に、これらは、システム全体の基本オブジェクトとして使用される論理システムオブジェクトからその記述子を継承する。適切なクラスのオブジェクトが作成されると、親オブジェクトとクラスオブジェクトの両方が、セキュリティ記述子を派生させるために使用される。図１０は、さらに、階層上の論理グループの効果も示している。ここで、管理者は、２つの論理グループを作成しており、１つはクラスタサーバへのアクセスを制御することができ、もう１つはローカルサーバオブジェクト上のプリンタへのアクセスを制御することができる。ここでそれぞれの場合にオブジェクトが１つしか示されていないが、それぞれの論理グループの下に、オブジェクトをいくつでも配置することが可能である。

メタデータ
例示され、説明されている実施形態では、ＣＤＩは、オブジェクトをリモートオブジェクトにバインドする機能を備えるが、呼び出し側は、バインドする前にそのオブジェクトがサポートするフィールドおよびコマンドを知っていなければならない。ほとんど常に、クライアントは、サーバオブジェクトおよびそれらがサポートするインターフェースを知っている。クライアントが知らなかった場合、機能するサーバオブジェクトについて先験的に知っている必要があるため、クライアントは正常に機能できないであろう。インターフェースは、この動作を最適化するように適合され、呼び出される際のコンテキストを正確に知っているクラスはメタデータメカニズムを実装する必要はない。

しかし、クライアントが操作対象のクラスについて先験的知識を持たない場合もある。例えば、クライアントは、マネージドデータプロバイダインターフェースへのＣＤＩ呼び出しを翻訳するアクセスアダプタである場合もある。この場合、そのクライアントにより要求されるデータは、先験的に知ることはできず、通信相手のサーバオブジェクトも、先験的に知られることはできない。または、そのクライアントは、クライアントまたはサーバ上のオブジェクトのすべてをオブジェクトの型に関係なくブラウズし操作できるようにする汎用管理ＵＩである場合もある。

この目的のために、例示され、説明されている実施形態は、呼び出し側がオブジェクトインスタンスに対しそのメタデータについてクエリを実行できるようにする標準システム型を備える。これらの型は、Ｔｙｐｅ、Ｐｒｏｐｅｒｔｙ、Ｃｏｍｍａｎｄ、およびＰａｒａｍｅｔｅｒ型である。コレクションアダプタサービスを使用して実装されるクラスは、自動的に完全なメタデータサポートをフリーで取得するこれは、クラスのそれぞれについて供給されるサーバオブジェクトのタイプマップから取り出される。

メタデータを取り出すためのベースとしてオブジェクトによりクエリが実行可能な型を図１１に示す。

メタデータは、クエリのベースとしてオブジェクトによりＴｙｐｅｓ型について最初にクエリを実行することにより取り出される。Ｔｙｐｅｓ型は、論理オブジェクトインスタンスによりサポートされるすべての型のリストを備える。将来、システムにおいてオブジェクトを他のオブジェクトの中に埋め込む、または他のオブジェクトを拡張することが可能になるため、これらの型は、基幹の基本オブジェクトだけでなく、そのオブジェクトインスタンスに対するすべての集成型を含むことになる。次に、それぞれのＴｙｐｅｓ型は、サポートされるコマンドまたはプロパティについてクエリが実行されるようにできる。さらにそれぞれのコマンドは、サポートされるパラメータについてクエリが実行されるようにできる。

クエリベース
クエリベースは、他の何らかの形で非階層型であるシステムでは風変わりな設計の態様である。この節では、そもそもなぜそれらが実装されたのか、またどのようにして関係クエリにマップされるのかについて説明する。

クエリベースでは、ソースオブジェクトを指定し、クエリが実行されるクラスのインスタンスを何らかの尺度により「下」にあると考えることができる。これは、さまざまな理由から与えられる。まず、これを使用すると、他の方法ではクエリの一部として関係を表す方法を知ることがない誰かが下位要素の列挙を構成できる。第２に、列挙に基づくダウンレベルのシステムに非常にうまくマッピングされるということである。クエリのベースは、非常に自然に、列挙における親オブジェクトとなる。したがって、ダウンレベルオブジェクトでは、クエリベースおよびオブジェクト状態に対するフィルタは、クエリを実装する自然な方法である。第３に、可変性の高い構成を持つオブジェクトの場合（例えば、オブジェクトにより格納されるメタデータ）、親オブジェクトからの列挙のシーケンスとしてクエリを取り扱うことがより論理的である。

しかし、クエリベースは、関係クエリにマッピングするための何らかの操作を必要とする。幸いなことに、これは、実現が比較的容易である。

例示目的のために、上記のテーブルは、印刷キュー内の多数のジョブを例示している。ジョブが関連付けられているオブジェクトの正規名を格納する２つのフィールド（基幹データベース内の外部キーとして実装される）がある。リモートオブジェクトを参照するそれぞれの列は、リモートオブジェクトクラスを認識する。

クエリが特定の基本オブジェクトを受ける場合、オブジェクトのクラスはオブジェクト内の論理フィールドに相関され、その後、クエリは、正しい値を持つこのフィールドを含むように拡張される。

例えば、クエリがＢａｓｅ＝”｛ＳＳＳＳ｝”、ＢａｓｅＣｌａｓｓ＝”Ｓｅｒｖｅｒ”を受け、クエリ文字列が「Ｊｏｂｓ：Ｓｉｚｅ＜１５０ＫＢ」である場合、これは、以下のクエリに翻訳される。

Ｊｏｂｓ：Ｓｅｒｖｅｒ＝”｛ＳＳＳＳ｝” ＡＮＤ（Ｊｏｂｓ：Ｓｉｚｅ＜１５０ＫＢ）

これは、正しい結果、Ｆｒｅｄ’ｓＪｏｂを返す。この翻訳は、コレクションアダプタサービス内で自動的に実行される。どのようなフィールドをクエリベースとして使用することができ、どのようなクラスに対応するのかを知る必要があるため、サーバオブジェクトのタイプマップ内に少し多くのメタデータを必要とする。

ＣＤＩ実装
前節では、オブジェクトから予想される動作を説明し、クライアントに公開されるインターフェースについて説明した。この節では、ＣＤＩのサーバサイドの実装を説明する。ＣＤＩにより提供されるサービスおよびプラグインモデルについて説明する。

図１２は、ＣＤＩの主要コンポーネントとともに、システム内に挿入されるさまざまなプラグインを示す。あらかじめ、主要コンポーネントのそれぞれの説明を行い、その後、ＣＤＩボックス自体の中のコンポーネントの詳細な説明を行う。コレクションアダプタサービスは、システムによって提供されるが、これは、プラグインによりホスティングされる別のサービスと考えられ、ＣＤＩそれ自体の一部でない。コレクションアダプタサービスについては、次の節で説明する。

アプリケーション
アプリケーションへのインターフェースは、前節の主要焦点となっていた。アプリケーションでは、ＣＤＩにバッチインターフェースを要求し、多数のアクションを記録し、その後、それらを実行する。実行が完了すると、アプリケーションは結果を取得できる。

ルータ
アクションを実行すると、ルータによりそのバッチがルーティングされ、プラグインに渡される。ルータは、同じプラグインを宛先とするバッチの連続する範囲を見つけて、それらの範囲を１回の呼び出しでプラグインに渡す。したがって、プラグインは、そのまま、バッチ処理動作自体を保存することができる。アプリケーションにより呼び出され意味動作に応じて、これらの節は、プラグインに並列に、順次に、受け渡すことができるか、またはトランザクションオブジェクトをバッチに関連付けて、プラグインがトランザクションを調整するようにできる。

プラグイン
プラグインは、ＤＬＬマニフェストおよび構成情報と関連してＤＬＬにより公開されるインターフェースである。単一のＤＬＬで、１つまたは複数のプラグインインターフェースを公開することができる。例示され、説明されている実施形態では、プラグインインターフェースは、１つのメソッドを持つ１つのファクトリインターフェース、および２つのメソッドＡｓｙｎｃＰｒｏｃｅｓｓＲｅｑｕｅｓｔおよびＳｈｕｔｄｏｗｎを持つプラグインインターフェース（ＩＩｍｇＢａｔｃｈＣｏｌｌｅｃｔｉｏｎ）からなる。プラグインインターフェースは、そのまま、そのオペレーションをバッチとして受け取る。したがって、これは、バッチもサポートする他のシステムへのリモーティングに使用する論理インターフェースである。この目的のために、例示され、説明されている実施形態では、プラグインであるローカルアクセスアダプタ、リモートアクセスアダプタ、サンドボックスアダプタ、および適応型プラグインが用意されるが、それぞれについて以下の段落で別々に説明する。

ローカルアクセスアダプタは、ローカルサービスまたはユーザ別サービスへのアクセスを行えるようにする。現在、これは、非同期ＣＯＭを使用するが、他のリモーティングメカニズムを使用できない理由は特にない。

リモートアクセスアダプタは、リモートマシンにアクセスするためのものであり、大部分、ローカルアクセスアダプタと同じメカニズムを使用し、サーバ上でクライアント別状態を低減するいくつかの違いがある。

サンドボックスアダプタは、これまでのアプリケーションの作業を、要求をバッチにグループ化することとして保存するために使用される。これは、同じ万能プラグインモデルをプロセス内またはプロセス外コンポーネントで使用することができ、さらには、望めばサンドボックスシステムコンポーネントも可能であることも意味する。ＣＤＩのほかにシステムのすべての部分は、プラグインとして公開される。

適応型プラグインは、極めて単純な形態であるが、プラグインは、非同期呼び出しで、キューに入れられているバッチオペレーションを解釈する必要があり、これは複雑な作業になりうる。このような理由から、コレクションアダプタサービス（ＣＡＳ）が用意されている。コレクションアダプタサービスを使用すると、オブジェクト（ＩＩｍｇＯｂｊｅｃｔ）の複数のオブジェクトコレクション（ＩＩｍｇＯｂｊｅｃｔＣｏｌｌｅｃｔｉｏｎ）をプラグインし、次に、バッチ処理された呼び出しを解釈し、それらを供給されるコレクションおよびオブジェクト上の複数の呼び出しに翻訳することができる。コレクションアダプタサービスは、これらのインターフェースの同期および非同期の両方の実装を効率よく扱うことができる。コレクションインターフェースは、十分に広く、ダウンレベルプロトコルにアクセスするために使用できる。通常、バッチ処理をサポートしないため、これらの場合において、パフォーマンスの損失はない。

サービス
例示され、説明されている実施形態では、ＣＤＩは、一連のサービスを提供する。これらのほとんどは、プラグインからしかアクセスできない。これらのサービスは、パブリックであり、ＣＡＳおよび他のプラグインに等しく公開される。これにより、ＣＡＳだと制限が強すぎると考える独立系ソフトウェアベンダまたは独立系ハードウェアベンダは同じ機能自体を得ることができる。明示的な目標は、ＣＡＳがほとんどのシナリオを解決できるようにすることであり、システム供給オブジェクトはすべてそれを使用する。ＣＤＩにより提供されるサービスは、クエリコンパイラ、ワークフロー、トランザクション、変更スコープ、バリアント、およびタイプマップを含み、以下では、それぞれについて別々に説明する。

クエリコンパイラは、アプリケーションにより供給されるクエリを２つの形式、解析木とフィルタにコンパイルすることができる。解析木は、プラグイン側でクエリを他の形式のクエリに翻訳することを望んでいる場合に有用である−これは、かっこおよび演算子優先度が解決され、いくつかの基本的な適格性検査がパーザーによりすでに実行されているため、自分でクエリの再解析を試みるよりも容易である。フィルタは、オブジェクトにバインドすることができ、メソッド−与えられたオブジェクトの状態が渡されたクエリと一致する場合に呼び出し側が検査できる「ＤｏｅｓＭａｔｃｈ」を備える。

ワークフローは、アプリケーションがＣＤＩへの呼び出しを実行する場合には必ず、インスタンス化されるインターフェースである。これは、ユーザアクションの論理的実行に対応する。ワークフローは、作業をスケジュールすることができ、ワークフローがキャンセルされるとそれに関連付けられた作業項目を通知する（通常、ユーザからの元の呼び出しがキャンセルされるため）。ワークフローは、再帰を検出し、防ぐためにトークンの集合を追跡することができる。プラグイン側でＣＤＩからの呼び出しの結果としてシステムへの呼び出しを実行したい場合、元の呼び出しのと同じワークフローを使用しなければならない。特別なサーバサイド専用呼び出し（ＩＩｍｇＣｏｍｍｏｎＤａｔａＳｅｒｖｅｒ：：ＲｅｃｕｒｓｅＤａｔａＢａｔｃｈ）を通じてこれを実行する。

再帰を実行する場合、同じオペレーションが同じ流れで再発し、したがって再帰から戻るか検査するために後で使用できるトークンを流れの中に挿入しなければならない。ワークフローは、さらに、元の呼び出しのトークンも追跡する。プラグインが非同期に、独立してＣＤＩを呼び出す場合、クライアントインターフェースを通じてそうすることができるか、またはそれ自身のワークフローを作成し、ＲｅｃｕｒｓｅＤａｔａＢａｔｃｈを呼び出すことができる。

呼び出し側がトランザクションを要求した場合、このオブジェクトが作成され、バッチに関連付けられる。トランザクションは、１つのトランザクションコレクションおよび従属アイテムの集合をトランザクションに関連付けるメカニズムを備える。これは、トランザクションとの同期と非同期の両方のインターフェースを備える。バッチが実行を終了すると、トランザクションはコミットされる。結果は、ストアに送られ、ストアが正しく更新すると、従属アイテムが実行される。従属アイテムとしての資格を得るためには、アイテムは、コミット要求を失敗できてはならない。これは、ストアに伝搬される状態変化に応じてオブジェクトをメモリ内で活動状態にするために使用される。プラグインが他のオブジェクトを含むようにトランザクションを拡張することを望んでいる場合（例えば、順に他のオブジェクトを削除する「Ｄｅｌｅｔｅ」コマンドを実装するために）、ＲｅｃｕｒｓｅＤａｔａＢａｔｃｈを介してＣＤＩにコールバックするときに同じトランザクションを指定することができる。毎回の再帰を介したすべての変更は、一番外側のバッチが正常に完了するまで保留状態を保つ。

変更スコープは、それぞれのチャネルを表すサーバサイド変更ハンドラに関係する。変更スコープを、トランザクション上に挿入できる。

バリアント型については、前の節で取りあげた。バリアント型は、クライアントまたはサーバサイドのいずれかにより使用することができる。

タイプマップについても、前の節で取りあげた。最適化されたマップは、サーバサイドからしか見えない。

プラグインインターフェース
例示され、説明されている実施形態では、プラグインインターフェースは、ＣＯＭに似たオブジェクトインスタンス化モデルを使用してインスタンス化される。これは、プラグインがレジストリにクラスｉｄを登録することを必要としない。プラグインをインスタンス化するプロセスは、図１３に示されている。

例示され、説明されている実施形態では、プラグインはすべて、ＷＭＩ．Ｃｏｎｆｉｇ内に、ＣＤＩ構成の一部として格納される。プラグインデータの一部は、ＷＭＩ．ＣｏｎｆｉｇによりプラグインＤＬＬのＸＭＬ構成ファイルから合成される（これは、ＸＣＯＰＹベースのソリューションに役立つ）。ＣＤＩ構成は、プラグインＤＬＬのリストからなる。それぞれのＤＬＬについて、それぞれサポートするコレクションＧＵＩＤとともに、それぞれの論理コレクション内でサポートされるクラスの一覧を示す。それぞれ、関連付けられたいくつかの初期化データも持つ。これは、通常、ＤＬＬによりサポートされるオブジェクトが永続し、取り出される場所を表す。ルータ側でプラグインインターフェースをインスタンス化することを望んでいる場合、これはコレクションＧＵＩＤを取り出し、対応するＤＬＬを見つけて、ＤｌｌＧｅｔＣｌａｓｓＯｂｊｅｃｔを呼び出す。

その後、ＣＬＳＩＤ＿ＩＩｍｇＢａｔｃｈＣｏｌｌｅｃｔｉｏｎおよびＩＩＤ＿ＩＩｍｇＢａｔｃｈＣｏｌｌｅｃｔｉｏｎＦａｃｔｏｒｙを要求する。その後、ＤＬＬは、プラグインによりサポートされるＩＩｍｇＢａｔｃｈＣｏｌｌｅｃｔｉｏｎのさまざまなインスタンスを返すことができるクラスファクトリを返す。ＩＩｍｇＢａｔｃｈＣｏｌｌｅｃｔｉｏｎＦａｃｔｏｒｙは、以下のインターフェースをサポートする。

ファクトリは、ＣｒｅａｔｅＩｎｓｔａｎｃｅで以下の情報を渡される。
● ＩＩｍｇＣｏｍｍｏｎＤａｔａＳｅｒｖｅｒインターフェース。このインターフェースは、ＩＩｍｇＣｏｍｍｏｎＤａｔａから継承し、さらに、サーバサイドサービスにアクセスするいくつかのプラグイン特有のメソッドも含む。注意：プラグインは、ＣｏＣｒｅａｔｅＩｎｓｔａｎｃｅ（ＣＬＳＩＤ＿ＩＩｍｇＣｏｍｍｏｎＤａｔａ）を呼び出すべきではない、というのも、これはクライアントインターフェースを作成するからである。システムは、最後のクライアントインターフェースが解放されたときにシャットダウンし、サーバサイドプラグインがクライアントインターフェースを保持しているとシャットダウンしない。
● ｃｏｌｌｅｃｔｉｏｎＧＵＩＤ。これは、ＣＤＩ構成内に存在するのと同じＧＵＩＤである。ファクトリは、このＧＵＩＤに応じて、異なるＩＩｍｇＢａｔｃｈＣｏｌｌｅｃｔｉｏｎインターフェースをインスタンス化することを選択することが可能である。
● 初期化データ−このデータは、ＷＭＩ．Ｃｏｎｆｉｇから取り出される。現在のところ、これは、文字列により表されている。プラグインは、この初期化データを使用して、オブジェクトの取得元を選択する。
● Ｒｉｉｄ−これは、ＣＤＩにより要求されるインターフェースである。現在、ＩＩＤ＿ＩＩｍｇＢａｔｃｈＣｏｌｌｅｃｔｉｏｎのみが要求されるが、将来のインターフェースは、ここで要求されることが可能である。

プラグインにより返されるインターフェースは以下のとおりである。

ＡｓｙｎｃＰｒｏｃｅｓｓＲｅｑｕｅｓｔインターフェースは、データの宛先がバッチからプラグインになっている場合に呼ばれる。コレクションは以下に渡される。
● ＩＩｍｇＳｅｒｖｅｒＩｔｅｍＣｏｍｐｌｅｔｉｏｎインターフェース。このインターフェースは、要求が完全に処理されたときに呼び出される単一メソッド−「Ｄｏｎｅ」をサポートする。呼び出し側は、ＡｓｙｎｃＰｒｏｃｅｓｓＲｅｑｕｅｓｔから即座に戻ることができる。呼び出し側は、ＡｓｙｎｃＰｒｏｃｅｓｓＲｅｑｕｅｓｔ呼び出しを失敗しない限り、「Ｄｏｎｅ」を呼び出さなければならない。「Ｄｏｎｅ」の呼び出しに失敗すると、クライアントのＥｘｅｃｕｔｅ呼び出しは完了しない。
● ＢａｔｃｈＡｒｒａｙ。このインターフェースは、クライアントにより要求されるアクションにアクセスできるようにする。
● バッチ配列の開始および終了インデックス。これを使用すると、ルータは、その後さまざまなプラグインにより共有される１つのバッチを作成することができる。これらのプラグインは、クライアントが並列実行の意味動作を要求した場合に、並列実行している可能性がある。

バッチ配列は、以下のインターフェースを持つ。

バッチの意味動作、関連するトランザクション、およびワークフローは、バッチ配列から取り出すことができる。これらのインターフェースは、バッチアレイにエイリアスされているため、増えた参照カウントとともに返されない。ＩｔｅｍＡｔメソッドは、与えられたインデックスでバッチアクションを返す。これは、アイテムの型を示す列挙を含む。また、アイテムが完了したかどうか、およびエラー情報を示すようにプラグイン側で設定できるフィールドも含む。これは、対応するアクションについて呼び出し側により渡されるパラメータを含む共用体を含む。

インターセプション
プラグインインターフェースおよびルータが定義されているため、インターセプションの説明は以下のとおりである。インターセプションは、バッチ処理ルータがデータを送信できる他のプラグインインターフェースとして、例示され、説明されている実施形態において実装される。しかし、ルーティングに対するコレクションｉｄ（またはクエリのクラス）しか必要としない、通常のプラグインについて格納される構成情報と異なり、インターセプトするプラグインは、以下の情報断片を指定する。
● インターセプトアクション。インターセプタは、取得、設定、クエリ、コマンド、または通知をトラップしたいかどうかを指定することができる。
● インターセプトクラス。インターセプタは、どのようなクラスのオブジェクトについて呼び出されたいかを指定する。このクラスは、「＊」として指定できるが、この場合、すべてのクラスについて登録される。
● インターセプトコレクション。インターセプタは、オブジェクトをインターセプトすることが望まれているコレクションの一意的ＧＵＩＤを指定する。このコレクションは、「＊」として指定できるが、この場合、すべてのコレクションについて登録される。
● インターセプトオブジェクト。インターセプタは、監視したいオブジェクトの一意的なオブジェクトｉｄを指定できる（これを行う場合、オブジェクトのＤｅｌｅｔｅコマンドをインターセプトしてインターセプションを削除しなければならない）。「＊」が指定された場合、すべてのクラスに対し、インターセプタが呼び出される。

インターセプションテーブル内のそれぞれの登録は、ＧＵＩＤを割り当てられる。インターセプションメカニズムは、「Ｃｈａｉｎｏｆｃｏｍｍａｎｄ」パターンを利用する。バッチ処理ルータにより実行されるアクションは以下のとおりである。
１．バッチ内の与えられたアイテムをコレクションにルーティングする前に、ルータはまず、上述のフィールドを使用して呼び出しについて登録されているインターセプタがあるかどうかを確認する。
２．もしあれば、同じルールに基づいて同じインターセプタを宛先とするアクションの連続する集合が見つかる。
３．インターセプション登録に関連付けられているＧＵＩＤがワークフロー上に挿入され、インターセプタが呼び出される。

インターセプタはこの時点で、他のプラグインの場合のように、バッチアクションを渡される。これは、以下の２つの方法のうちの１つでアクションの実行を変更する。
１．ルータに対してＲｅｃｕｒｓｅＢａｔｃｈＡｃｔｉｏｎｓ（）を呼び出し、再びワークフロー、それに加えて元のバッチアクションを渡す。これにより、アクションが修正されることはないが、インターセプタはそれらを読み込んで、追加アクション自体を実行することができる（例えば、シンクロナイザの場合、キャッシュされているデータが古ければ、これを使用して同期処理アクションを起動する）。
２．これはそれぞれのバッチアクションを解釈し、その後、ＲｅｃｕｒｓｅＤａｔａＢａｔｃｈを呼び出してワークフローを再び渡すことによりそれらを修正する。このオプションを使用することにより、インターセプタは、アクションの結果を変更できるが、実装することは（意図的に）かなり困難である。例えば、「Ｇｅｔ」の結果を変更するには、一時プロキシオブジェクトをインスタンス化し、実際のオブジェクト取得の結果を保持しなければならず、新しいタイプマップを登録して、この一時オブジェクトに書き込む必要がある。

これらの呼び出しのいずれでも、バッチ処理ルータへのコールバックが生じる。バッチ処理ルータは、ワークフロー内にリストされているＧＵＩＤトークンを持つインターセプタを呼び出さないことを除き、前と全く同じ検索を実行する。したがって、アクションがデスティネーションオブジェクトにルーティングされるまで、それぞれのインターセプションが順に使い尽くされる。ルータは、呼び出しが再帰的になっている場合にすでに呼び出されているインターセプタを自動的に無視するため、この同じメカニズムにより、適切な動作をするインターセプタおよびオブジェクトの集合が再帰を示さないように防止する。

インターセプタは、呼び出しの連鎖を形成する役割を持つため、連鎖形成の前または後にアクションを実行することを選択することができる。これは、バッチの意味動作を変更できる。通常、バッチがトランザクションでない場合、インターセプションはトランザクションであることを確実にしたいことがある。これは、非同期に呼び出されるため、インターセプトされたアクションと並行してインターセプションを実行することすら可能である。

インターセプションの使用
インターセプションは、２つの目的−システム拡張または態様拡張−に使用することができる。インターセプションを、バッチアクションの動作を拡張するためＩＨＶにより使用することができる。例えば、キューが解析されるときに、ドライバによって他のアクションが実行される必要がある場合がある。これらの拡張は、元のアクションの結果を変更しようとするのでない限り、十分に安全である。このような理由から、ＲｅｃｕｒｓｅＢａｔｃｈＡｃｔｉｏｎｓメソッドは、実装をかなり単純にされる。バッチアクションの結果を変更することはかなり難しいが、それは、タイプマップ、クライアントオブジェクト、およびクライアントオブジェクトコレクションなどの何らかの厄介なものを含む、インターセプション、およびすべてのパラメータを修正することを必要とするからである。インターセプションは、互換性を維持し、システムにパッチをあてるメカニズムとして使用されると考えることもできる。例えば、システムの改訂により、プラグインの誤動作が生じた場合、それが認識するものへの呼び出しを変更するインターセプタを作成することが可能である。その後、例えば、目標オブジェクトに到達する前に大きすぎる文字列とともに呼び出しをインターセプトすることによりセキュリティホールにパッチをあてるインターセプタを供給することによりシステムにサービスの提供することが可能である。これは、極めて汎用的に行うことさえ可能であり、例えば、ＭＡＸ＿ＰＡＴＨよりも大きいすべての文字列を拒絶するインターセプタを作成することが可能であり、または、１フィールド毎に適切な文字列長さを持つテーブルを用意することが可能である。

インターセプションが最も有用である場合、多数のオブジェクトをクロス／カットするシステムの態様を実装する例えば、特定のパターンに従うシステム内のすべてのアクションのログを取るインターセプタを作成することが可能である（例えば、「ＡｃｃｅｓｓＤｅｎｉｅｄ」で失敗する）。

オブジェクトコマンド
オブジェクトコマンドは、サーバサイドでしか呼び出されないという点でオブジェクトプロパティと異なる。これは、コマンド呼び出しがバリアント型の配列をクライアントからサーバに渡し、また戻すことにより実行されるためである。クライアントサイドプロキシオブジェクトが呼び出されるという概念はない。データ表現を以下に示した。

上からわかるように、サーバクラス記述は、クライアントクラス記述と同じであるが、一連のコマンドの記述も含む。コマンドは、型、コマンド、および記述を持つ。これは、コマンドインターフェースへのポインタを含む。コマンドインターフェースは、プロパティにアクセスする際に使用されるアクセッサインターフェースに類似した動作をする。コマンドインターフェースは、コマンドおよびコマンドの入力パラメータを含むｌｍｇＶａｒｉａｎｔの配列が適用されなければならないオブジェクトに渡される。すべてのコマンドは、非同期に実行することができるが、これは、インターフェースがＢｅｇｉｎＣｏｍｍａｎｄおよびＥｎｄＣｏｍｍａｎｄの両方のメソッドを持つからである。

それぞれのコマンドは、さらに、そのパラメータのすべての型も定義し、さらに、それぞれのコマンドに対するすべての記述のリストも持つ。

プロパティアクセッサのように、コマンドは、動的な型の一番上に構築することができる。しかし、基本レベルでは、アクションを実行することに対応しており（データを取り出すこととは反対に）、また動的プロキシオブジェクトは、コマンドを呼び出すときにワイヤマーシャリングを行うように構築される必要はないため、これは、プロパティの場合ほど有用である可能性はない。インターセプションを介してコマンドが拡張された場合には、有用である可能性もある。

ＩＡＴＬコマンド
ＩＡＴＬは、ＣＤＩタイプマッププロパティをＣ＋＋フィールドおよびメソッドに直接マッピングするメカニズムを備えるのと同様に、ＣＤＩコマンドをＣ＋＋クラスメソッド呼び出しに直接マッピングするメカニズムを備える。

ＩＡＴＬを使用することにより、呼び出し側はコマンドを、非同期ＢｅｇｉｎＣｏｍｍａｎｄ、ＥｎｄＣｏｍｍａｎｄペアがインプリメンタ向けに自動的に構築される単一メソッドとして実装することができる。これは、インプリメンタが、ＩＯを実行しないコマンドを実装したい場合に有用である。それとは別に、ＩＡＴＬにより、クラスは２つのメソッドを備え、コマンドを非同期に実装することができる。ＩＡＴＬコマンドを構築するために使用されるメカニズムは、以下の抜粋コードとしてまとめられている。

この抜粋コードは、あるクラスからのメソッドはＣＤＩコマンドとして公開できるさまざまな方法を示している。

Ｐｒｉｎｔコマンドは、ＳｅｒｖｅｒＰｒｉｎｔｅｒＣｏｍｍａｎｄＢａｓｅ内に実装され、単一同期メソッドとして実装される。すべての非同期メソッドは、第１引数としてＩｍｇ：：ｉａｔｌ：：ＣｏｍｍａｎｄＰａｒａｍｓパラメータを受け取る。この構造体は、コマンドに関連付けられているワークフローおよび共通データインターフェースを保持する。第２のパラメータは、第１のコマンド引数にマッピングされ、というように続く。どのパラメータが入力であり、どれが出力パラメータであるかについて曖昧さをなくすために、呼び出し側は、メソッドが多数の入力および出力機能をどのように持つかを示すためＣｏｍｍａｎｄ関数にパラメータを供給しなければならない。例えば、入力コマンドが参照される場合：

ｇ１Ｉｎパラメータは、これが１つの入力パラメータを持つコマンドであることを示す。コマンドとして呼び出せるメソッドでは、入力パラメータは出力パラメータの前になければならない。

プロパティタイプマップと同様に、コマンドタイプマップは、基本型から派生型に継承することができる。これは、Ｉｎｈｅｒｉｔｓ関数で実行される。

コマンドパラメータの型は、メソッド引数から自動的に推論される。しかし、オプションの記述フィールドは、テーブル内で与えられなければならない。これは、ＩｎＤｅｓｃｒｉｐおよびＯｕｔＤｅｓｃｒｉｐ関数を介して実行される。例えば、次のようである。

ここで、ＣｏｍｍａｎｄＦｕｎｃｔｉｏｎは、コマンドの基本定義を与え、ＩｎＤｅｓｃｒｉｐおよびＯｕｔＤｅｓｃｒｉｐ関数は、それぞれ、第１の入力およびパラメータを記述する。複数のパラメータが記述されている場合、ＩｎＤｅｓｃｒｉｐおよびＯｕｔＤｅｓｃｒｉｐの複数の呼び出しを行うことが生きる。

ＩＡＴＬコマンドマップにより示されている他の注目すべき特徴は、非同期コマンドを実装できることである。これは、ＳｅｒｖｅｒＰｒｉｎｔｅｒクラス上のＢｅｇｉｎＮｏｔｈｉｎｇおよびＥｎｄＮｏｔｈｉｎｇメソッドにより例示される。

これは、コマンドを記述で次のように参照される。

この場合のＣｏｍｍａｎｄ関数では、入力パラメータは定義によりＢｅｇｉｎメソッドが受け取り、出力パラメータは定義によりＥｎｄメソッドが返すので、どれが入力および出力パラメータであるかを指示する必要はない。この場合、ＢｅｇｉｎメソッドおよびＥｎｄメソッドは、さらに、同期（単一メソッド）コマンドへの異なる構造体、つまり、Ｉｍｇ：：ｉａｔｌ：：ＩｎＣｏｍｍａｎｄＰａｒａｍｓおよびＩｍｇ：：ｉａｔｌ：：ＯｕｔＣｏｍｍａｎｄＰａｒａｍｓを取る。ＩｎＣｏｍｍａｎｄＰａｒａｍｓは、保存され、オペレーションが完了したことを示すコールバックインターフェースおよびオペレーションに関連付けられるコンテキスト情報を含む。Ｅｎｄメソッドは、コンテキスト情報を戻され、コマンドの結果をエラーコードまたは戻りパラメータの集合として返すことができる。

クエリコンパイラ
クエリコンパイラは、ＣＤＩクエリをクラス記述または解析木を持つオブジェクトに対して適用可能なフィルタにコンパイルするメカニズムを備える。クエリコンパイラにより公開されるインターフェースは、以下の抜粋コードに示されている。

サーバサイドＣＤＩインスタンスは、クエリをコンパイルするメカニズムを備える。クエリフィルタが望ましい場合、ＩＩｍｇＣｏｍｍｏｎＤａｔａサーバインターフェースのＣｏｍｐｉｌｅＱｕｅｒｙメソッドが使用される。解析木が必要な場合、ＣｏｍｐｉｌｅＱｕｅｒｙＴｒｅｅメソッドが呼び出される。

クエリフィルタは、ファクトリとして返される。特定のクラス記述がクエリフィルタファクトリに渡されると、クエリフィルタが返される。カバーの下のクエリフィルタは、クエリにより動的に生成されるクラスに対してタイプマップを構築する。サーバオブジェクトにバインドされる場合、サーバオブジェクトに対して最適化されたマップを構築する。この最適化されたマップは、その後クエリが適用されるクエリオブジェクトに値を設定するために使用される。

クエリフィルタファクトリから返されるクエリフィルタは、定義により、特定のサーバクラスにバインドされる。これは、複数のサーバクラスオブジェクトインスタンスに対し適用することができる。これはスレッドセーフではない。呼び出し側が異なるスレッドから同じクエリを使用したい場合、同じクエリフィルタファクトリから異なるクエリフィルタインスタンスを取得し、異なるスレッド中でそれを使用することができる。

クエリフィルタは、クラス記述をサポートするクラスに対して適用可能であるという利点を有する。しかし、クラスに対して適用すべきフィルタについては、クラスをインスタンス化し、そのフィルタと潜在的に一致する可能性のあるすべてのインスタンスを評価しなければならない。これは、十分に小さなオブジェクトの集合については適切であるが（場合によっては、現在のコンピュータでは１０，０００のオーダー）、オブジェクトの集合が大きくなるとパフォーマンスが非常に低下する。オブジェクトの大きな集合の場合、ＳＱＬによって使用されるようなクエリメカニズムを使用しなければならない。しかし、ＣＤＩクエリ構文は、ＳＱＬ構文と同一ではない。この問題を解決するために、代わりにクエリ木をコンパイルし、その後、ＳＱＬクエリに翻訳することができる。ＣＤＩクエリコンパイラを実行できることにより、クエリフィルタに対し同じクエリを処理する方法と矛盾がないように演算子優先順位およびかっこなどの問題をＣＤＩコンパイラにより評価することができる。

ＣｏｍｐｉｌｅＱｕｅｒｙＴｒｅｅメソッドから返されるインターフェースは、Ｒｏｏｔメソッドを通じてコンパイル済みクエリ木へのエイリアスを返す。返される解析木により占有されるメモリは、ＩＩｍｇＱｕｅｒｙＴｒｅｅインターフェースが解放されるとシステムに戻される。

一実施形態では、解析木は、クエリノードから始まり、クエリノードは比較とすることができるか、またはブールノードとすることが可能である。ブールノードの場合、ノードは演算子を持ち、次に、２つのクエリノードからなる。これは、解析木を構築するための構文である。比較ノードの場合、比較は、解析識別子と定数とからなる。クエリ「Ｐｒｉｎｔｅｒ．ｃＪｏｂｓ＞１０ＡＮＤＰｒｉｎｔｅｒ．ｃＪｏｂｓ＜１００」のように、識別子が同じ式の中に２回出現した場合、同じＩｍｇＰａｒｓｅｌｄｅｎｔｉｆｉｅｒインスタンスが解析木内に２回出現する。ｐＣｏｏｋｉｅフィールドは、呼び出し側がクッキー内の識別子の概念を格納するための木内のプレースホルダである。例えば、Ｐｒｉｎｔｅｒ．ｃＪｏｂｓがデータベース内のＮｕｍｂｅｒＯｆＪｏｂｓ列に翻訳された場合、これを、クッキー内に格納することが可能である。拡張ポイントを用意することのほかは、クッキーは無視される。

トランザクション
トランザクションは、オペレーションが完全に成功すること、および失敗した場合は、マシンに中間状態が格納されないことを保証するためにＣＤＩが使用するメカニズムである。トランザクションを処理する実際のメカニズムは、ＣＤＩとＣＡＳとに分散される。ＣＤＩは、トランザクションおよびワークフローを処理するためのインターフェースを備える。ＣＡＳは、トランザクションの正しさを保証し、デッドロックのないロック戦略を規定するために必要なメカニズムを用意する。

それぞれのトランザクションは、正確に１つのトランザクションオブジェクトにより制御される。それぞれのトランザクションオブジェクトは１つの論理ストアオブジェクトを有する。システム内のそれぞれの論理ストアは、ＧＵＩＤにより参照される。ストアオブジェクトは、トランザクションが調整を必要とする永続的状態の処理を調整する。ストアはただ１つという制限は、ストアが分散リソースマネージャ（ＤＲＭ）でない場合に２つのトランザクションストアに対する２回のコミットが成功することを保証できるということをシステム側で保証できないと考えられる場合に妥当なものである。それらがＤＲＭである場合、トランザクションは、調整される形で１つの論理ストア全域にある、つまり、ＣＯＭ＋の場合のように、分散トランザクションコーディネータ（ＤＴＣ）により提供されるものである。

それぞれのトランザクションは、さらに、多数の従属がアクションを保持する。従属アクションは、そのオペレーションのＣｏｍｍｉｔまたはＲｅｖｅｒｔに失敗できないというのがルールである。従属アクションは、一般に、キャッシュされた状態（またはロック）を永続的ストアの状態に結合するために使用される。例えば、ＣＡＳは、トランザクションをストアに適用する前にそれぞれのオブジェクトのクローニングを行い、ストアが変更を正常にコミットした場合に、クローニングされたオブジェクトはキャッシュ内にスワップされる。トランザクションインターフェースは以下に示されている。

呼び出し側またはインプリメンタが非同期呼び出しメカニズムを使用することを望んでいる場合には、インターフェースのすべてがＣＯＭ非同期呼び出しパターンを使用することに注意されたい。そうでない場合、そのまま、インターフェースへの同期呼び出しを実行するか、または同期トランザクション従属アクションを実装することができる。

ストアまたはトランザクション従属アイテムを実装することを望んでいる場合には、ＩＩｍｇＴｒａｎｓａｃｔｉｏｎＤｅｐｅｎｄｅｎｔＩｔｅｍインターフェースを実装しなければならない。このインターフェースは、ＣｏｍｍｉｔまたはＲｅｖｅｒｔの２つのメソッドを持つ。ストアがコミット（復帰ではなく）に失敗する場合があり、他の従属アイテムは常にそのＣｏｍｍｉｔおよびＲｅｖｅｒｔメソッドを成功させなければならない。

それぞれのトランザクションは、ちょうど１つのストアを持つことができる。現在のストアおよびそのストアＧＵＩＤを、ＧｅｔＴｒａｎｓａｃｔｉｏｎａｌＣｏｌｌｅｃｔｉｏｎメソッドにより取り出すことができる。

呼び出し側がトランザクションストアを設定することを望んでいる場合、ＳｅｔＴｒａｎｓａｃｔｉｏｎａＩＣｏｌｌｅｃｔｉｏｎ呼び出しが使用される。トランザクションはマルチスレッドインターフェースであるため、ＳｅｔＴｒａｎｓａｃｔｉｏｎａｌＣｏｌｌｅｃｔｉｏｎはＧＵＩＤ、設定すべきコレクションの両方を取り、もしそこにあれば既存のコレクションを返す。以下の３つの場合がある（ＥＴｒａｎｓａｃｔｉｏｎＳｅｔＲｅｓｕｌｔ戻りパラメータにより示される）。
● トランザクションは、現在、関連付けられたストアオブジェクトを持たない。この場合、戻りは、ＴｒａｎｓａｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎＳｅｔであり、コレクションで渡されるものが、トランザクションに関連付けられたストアになる。
● トランザクションは現在、ストアオブジェクトを持つが、指定されているものと同じＧＵＩＤを持つ。この場合、トランザクションオブジェクトは、既存のコレクションを呼び出し側に返す。呼び出し側は、前のコレクションを解放し、現在トランザクションにある永続的ストアで呼び出しを継続しなければならない。
● トランザクションは現在、ストアオブジェクトを持ち、それは異なるストアである（異なるストアＧＵＩＤを持つ）。この場合、トランザクションオブジェクトは、ＴｒａｎｓａｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎＩｎｃｏｍｐａｔｉｂｌｅを返す。呼び出し側は、通常、この時点でオペレーションを失敗する。（これにより、トランザクションが復帰する）。

トランザクションコーディネータはストアオブジェクトへのインターフェースを知ることができないため（それはトランザクションファイルシステムからＳＱＬデータベースへの何かでありうる）、これが、ｌＵｎｋｎｏｗｎとして呼び出し側に返され、そこから、Ｑｕｅｒｙｌｎｔｅｒｆａｃｅを介して実際のストアインターフェースを取り出すことができる。ストアは、トランザクションオブジェクトが正しくストアへの変更のＣｏｍｍｉｔまたはＲｅｖｅｒｔを実行できるようにＩＩｍｇＴｒａｎｓａｃｔｉｏｎＤｅｐｅｎｄｅｎｔＩｔｅｍを実装しなければならない。

トランザクション従属アイテムは、２つのフェーズでコミットまたは復帰される。これは、ＩｎｓｅｒｔＤｅｐｅｎｄｅｎｔＡｃｔｉｏｎへのＴｒａｎｓａｃｔｉｏｎＯｒｄｅｒＦｉｒｓｔおよびＴｒａｎｓａｃｔｉｏｎＯｒｄｅｒＬａｓｔパラメータを介して指定される。ロックのためＣＡＳに依存するトランザクションは、ＴｒａｎｓａｃｔｉｏｎＯｒｄｅｒＦｉｒｓｔのみを使用すべきであるが、それは、ＣＡＳがＴｒａｎｓａｃｔｉｏｎＯｒｄｅｒＬａｓｔの従属アイテムを使用して、必ず調整トランザクションがコミットまたは復帰された後にオブジェクトロックが解除されるようにするからである。

ワークフロー
ＣＤＩインターフェースは、たいてい非同期である。そのため、単一オペレーションは、１つのスレッド上で完了することができるか、または複数のスレッド上で完了する可能性がある。非同期性の小さいプログラミングを使用するシステムでは、状態をスレッドに関連付けることができる場合が多く、例えば、スレッドは、トランザクションが起動した後に、スレッドからのメソッド発行で常に暗示される関連付けられたトランザクションを持つ可能性がある。ワークフローの概念は、ＣＤＩのスレッドの一般概念を置き換える。ワークフローは、常に、ユーザによってサブミットされるバッチに正確に対応する。ユーザは、ワークフローを作成しない。これは、新しいバッチが発行されるときにＣＤＩにより自動的に作成される。サーバプラグインは、それ自身の目的のために望んでいる場合に最初からワークフローを作成できる。

ワークフローは、さらに、新しい非同期ワークアイテムを作成し、それをワークフローに、したがって開始バッチに関連付けることもサポートする。バッチがキャンセルされた場合、ワークフローもキャンセルされ、したがって、ワークフロー上のすべてのアイテムがキャンセルを要求される。このメカニズムを使用すると、ＣＤＩはすべてのインターフェース上で明示的なキャンセレーションメソッドをサポートする必要はなく、メソッドは代わりにワークフローを受け取るだけである。

ワークフローインターフェースは以下に示されている。

次に、ワークフローによって与えられるサービスである、ワークアイテム、トークン、スコープ、およびトランザクションを取りあげる。トランザクションは、上では独立して取りあげられているが、ワークフローは、それらに対する何らかの特別な処理を有する。

ワークアイテム
ワークアイテムを実装するために、呼び出し側は、ＩＩｍｇＷｏｒｋＩｔｅｍインターフェースを実装しなければならない。ワークアイテムが実行され、ワークフローがキャンセルされた場合にＣａｎｃｅｌメソッドが呼び出されると、Ｒｕｎメソッドがそのインターフェース上で呼び出される。

ワークアイテムは以下の３つの基本型がある。
● 「ＡｄｄＷｏｒｋＩｔｅｍ」で作成される、通常のワークアイテム。この種のワークアイテムは、十分なリソースが利用可能であれば直ちに実行される。すべてのワークアイテム同様、呼び出し側は、どのような種類のワークアイテムがワークアイテムフラグを通じて実行されるかを指定できる。
● 「ＡｄｄＷａｉｔａｂｌｅＩｔｅｍ」で作成される、待機可能なワークアイテム。待機可能なワークアイテムは、関連付けられたイベントの発生が知らされたときに実行される。
● 「ＡｄｄＤｅｐｅｎｄｅｎｔＩｔｅｍ」で作成される、従属ワークアイテム。従属ワークアイテムは実行されないが、ワークフローがキャンセルされる場合は「Ｃａｎｃｅｌ」メソッドが呼び出される。これにより、呼び出し側は、異なる非同期メソッドを使用できるが（例えば、オーバーラップする構造体を使用してＲｅａｄＦｉｌｅを呼び出すことが可能である）、そのまま、元のワークフローからキャンセレーション通知を受け取る。

ＩＩｍｇＷｏｒｋＩｔｅｍＣｏｎｔｒｏｌインターフェースは２つの目的を成就する−これにより、待機可能なワークアイテムは、そのワークアイテムをトリガするように設定できるイベントハンドラを返すことができる。また、これにより、呼び出し側は、インターフェースを解放することにより特定のワークアイテムをキャンセルすることができる。この場合のキャンセル呼び出しは、常に、非同期である、つまり、ワークアイテムはキャンセレーションを通知されるが、このインターフェース上のＲｅｌｅａｓｅ呼び出しは、キャンセレーションが完了するのを待たないということである。

これは、ワークフローに対するＳｈｕｔｄｏｗｎメソッドの動作とは異なる。シャットダウンメソッドは、ワークフロー内のワークアイテムすべてがキャンセルされるのを同期して待つ。

トークン
トークンは、ワークフロー上の特定の状態をマークするために使用される。これらは、インターセプションを実装するときに再帰が無限に実行されるのを防ぐために使用されることを意図されている。つまり、特定の種類のインターセプションが、トークンをワークフローに追加して、その後、その種類のインターセプションが再び発生することを防ぐことができる。

トークンはＧＵＩＤである−トークンを、ワークフローに追加すること、ワークフロー内で見つけること、およびワークフローから削除することができる。

トランザクション
ワークフローは、正確に１つのトランザクションを持ちうる。ワークフローは、トランザクションを作成できる唯一のインターフェースである。ワークフローは、現在のトランザクションを処理するためのヘルパメソッドを多数備える。
● ＣｒｅａｔｅＴｒａｎｓａｃｔｉｏｎは、トランザクションを作成し、それを現在のワークフローに関連付ける。トランザクションがすでに存在している場合、これは、良いものであると考えられ、現在のトランザクションが返される。（呼び出し側は、これは、ＥＩｍｇＢａｔｃｈＴｒａｎｓａｃｔｉｏｎＣｒｅａｔｉｏｎ戻りを通じて発生したと推論できる）。
● ＧｅｔＢａｔｃｈＴｒａｎｓａｃｔｉｏｎは、もし存在すればワークフローに現在関連付けられているバッチトランザクションを返す。存在しなければＮＵＬＬを返す。
● ＩｎｓｅｒｔＴｒａｎｓａｃｔｉｏｎａｌＣｏｌｌｅｃｔｉｏｎは、コレクションをワークフローに関連付けられたトランザクションに挿入する。挿入されたコレクションまたは既存のコレクションは、返されるｐｐＩＳｅｔＴｒａｎｓＣｏｌｌｅｃｔｉｏｎを介して返される。コレクションが非互換である（異なるＧＵＩＤを使用する）場合、呼び出しは失敗する。
● ＧｅｔＴｒａｎｓａｃｔｉｏｎａｌＣｏｌｌｅｃｔｉｏｎは、ワークフローに関連付けられたトランザクションに関連付けられているトランザクションコレクションを取り出す。

スコープ設定ワークフロー
ワークフローは、他のワークフローを含むことができる。ワークフローのスコープが他のワークフロー内に設定された場合、すべてのワークアイテムおよびトークンをその親から自動的に継承する。また、その親ワークフローから進行中のトランザクションも継承する。ワークフローのスコープを設定することにより、２つの主要な種類の機能を使用できる。
● 親ワークフロー内のトークンを、削除できない。このため、ワークフロー内のトークンの集合は、ワークフロー呼び出しが呼び出し側に再帰的に戻るまで「ロック」状態にできる。これは、インターセプタがうっかり、削除すべきでないトークンを削除してしまうことを防止できるという点で有用である。
● ユーザからの非トランザクション要求は、実装の詳細として実行するために、トランザクションも必要とする可能性がある。例えば、削除要求で、多数の下位オブジェクトも削除する必要が生じる可能性がある。元のバッチは、トランザクションにすべきでないか、またはトランザクションにできない他のアイテムを含むことがあるため、呼び出し側によって作成されたワークフローにトランザクションを追加することはしたくないであろう。解決策として、第１のワークフローの内側のスコープに入るワークフローを生成し、その後、トランザクションを内側のワークフローに関連付ける。これにより、ワークアイテム上のキャンセレーション要求を維持することができ、さらに、元のワークフローをトランザクションにすることなく、元のワークフロー上のトークンを保存することもできる。

サーバサイド通知
ＣＤＩは、通知をサポートすることを望んでいるプラグインコレクションをサポートする。これにより、通知チャネルで、リモートコレクションおよびローカル（プロセス内またはサンドボックス）コレクションから同時にデータを取り出し、クライアントに代わって通知チャネルを矛盾なく処理することができる。ＣＡＳは、特定のオブジェクトに関する通知をさらにサポートする（ロック機能インフラストラクチャを通じて通知が正しくシリアライズされることを保証するなど）。

それぞれのバッチコレクションは、それぞれの通知チャネルについてデータをクライアントコレクションにプッシュするために使用されるＩＩｍｇＮｏｔｉｆｉｃａｔｉｏｎＤａｔａＳｅｒｖｅｒインターフェースを与えられる。ＣＤＩ自体は、クライアントコレクションおよび他のインフラストラクチャを通知のため保持する。

通知データサーバインターフェースは、以下の３つのメソッドを公開する。
● ＲｅｇｉｓｔｅｒＳｈｕｔｄｏｗｎ−これにより、呼び出し側は、シャットダウンされるチャネルに関心のあることを示すことができる。例えば、リモートアクセスアダプタは、クライアント通知チャネルがプルダウンされたときにそれ自身の通知チャネルをプルダウンすることを知っている必要があると考えられる。
● ＣｒｅａｔｅＮｏｔｉｆｉｃａｔｉｏｎＯｂｊｅｃｔ−これは、通知チャネルを通じてデータをブッシュするために使用されなければならない新しい通知インターフェースを作成する。それぞれのＩＩｍｇＰｕｓｈＮｏｔｉｆｙＤａｔａＴｈｒｏｕｇｈＣｈａｎｎｅｌインスタンスは、スレッドセーフでない。このシステムは、ＩＩｍｇＰｕｓｈＮｏｔｉｆｙＤａｔａＴｈｒｏｕｇｈＣｈａｎｎｅｌインスタンスを通じて送信される変更が一グループとして送信されるか、全く送信されないかの保証を与える。
● ＳｅｎｄＦａｉｌｕｒｅ−通知がそのチャネルを通じて送信されるのを妨げる致命的エラーが発生する可能性がある。この場合、ＳｅｎｄＦａｉｌｕｒｅメソッドを呼び出すことができる。これは、チャネルを破壊することが保証される。さらに、エラー情報を最善努力方式で呼び出し側に送信する。

チャネルインターフェースを介したプッシュ通知データは、以下のメソッドを持つ。
● ＳｅｎｄＡｄｄＯｂｊｅｃｔＮｏｔｉｆｙ−新しい通知オブジェクトが追加されたことをチャネルに知らせる。オブジェクトは、実際に作成されたため追加された可能性があるか、または代わりにクエリフィルタに一致する状態に変化した可能性がある。
● ＳｅｎｄＲｅｍｏｖｅＯｂｊｅｃｔＮｏｔｉｆｙ−オブジェクトが実際に削除されたか、またはクエリフィルタに一致しなくなり、したがってクライアントコレクションから論理的に削除されてしまっていることをチャネルに知らせる。
● ＳｅｎｄＣｈａｎｇｅＤａｔａＮｏｔｉｆｙ−これは、個別のフィールド情報をチャネルからクライアントに送信する。マップインデックスは、クライアントの登録されているクラス記述内のフィールドのインデックスである。送られるそれぞれの変更は、２つの動作のうちの１つをとることができる。変更がシステム内のどこかにバッファリングされ、同じフィールドへの他の変更が発生した場合、新しいフィールド値に置き換わる。これは、バッファリングされている通知データに必要な記憶域を最小にする利点を有する。それとは別に、すべての変更が有意である可能性もあり、その場合、呼び出し側は、すべての変更の履歴を保持するように要求することができる。
● ＳｅｎｄＤｏｎｅ−これは、ＩＩｍｇＰｕｓｈＮｏｔｉｆｙＤａｔａインターフェースに送信された変更を終了する。通知の初期データが送信され、その場合、ＮｏｔｉｆｙＵｐｄａｔｅＰｏｐｕｌａｔｅ変更形態を使用できるか、またはこれが、オブジェクト状態の後続の変化に関する通知であり、その場合、ＮｏｔｉｆｙＵｐｄａｔｅを指定できる。

フレンドリ名解決プラグイン
プラグインバッチコレクションが正規名空間に差し込むために使用するメカニズムについては、上の「プラグインインターフェース」という表題の節で説明されている。基本的に、それぞれのコレクションはＧＵＩＤにより識別される。バッチコレクションがさらにフレンドリ名もサポートしたい場合、フレンドリ名解決ハンドラを登録しなければならない。これは、要求されたクラスのフレンドリ名を可能ならば正規名に翻訳する。フレンドリネームリゾルバは、通常のプラグインが登録されるのと同じ方法でＣＤＩに登録されるが、ただし、フレンドリ名クラスは、コレクションＧＵＩＤの代わりに使用され、異なるクラスファクトリおよびインターフェースが代わりに使用される点が異なる。クラスファクトリおよびプラグインインターフェースが以下に示されている。

クライアントが名前解決を要求した場合、フレンドリネームリゾルバがキャッシュ内にその名前を見つけられなければ、そのクラスについてそれぞれ登録されているプラグインに対する名前解決ハンドラが呼び出される（並列呼び出しで）。それぞれのネームリゾルバは、名前を解決しようとし、名前解決が終了すると、リゾルバは、ＩＩｍｇＳｅｒｖｅｒＩｔｅｍＣｏｍｐｌｅｔｉｏｎインターフェース上でＤｏｎｅを呼び出す。ネームリゾルバは、その後、ＢｅｇｉｎＲｅｓｏｌｖｅＮａｍｅにより返される同じコンテキストとともにＥｎｄＲｅｓｏｌｖｅＮａｍｅを呼び出す。次に、ネームリゾルバは、ネームリゾルバがフレンドリ名に対応していると判定した正規名を含むＩＩｍｇＣａｎｏｎｉｃａｌＮａｍｅイテレータを返す。

ネームリゾルバプラグインは、通常、ＣＤＩインターフェースに対して、取得、クエリ、またはコマンドを使用することにより名前解決を実行することに注意されたい。したがって、非同期インターフェースを実装しても、次に、他の非同期インターフェースを呼び出すので、通常、あまり問題にならない。

呼び出し側がすべてのクエリコレクションについてＩＩｍｇＣａｎｏｎｉｃａｌＮａｍｅイテレータを実装しなくても済むように、正規名を蓄積し、そこからイテレータインスタンスを返すことができるコレクションインターフェースが用意される。このインターフェースは以下に示されている。

コレクションアダプタサービス
例示され、説明されている実施形態では、ＩＩｍｇＢａｔｃｈＣｏｌｌｅｃｔｉｏｎインターフェースは、実装が一見複雑そうである。呼び出し側は、それぞれのバッチアイテムを一通り実行し、デコードし、それへの応答方法を決定しなければならない。一般に、コレクションがバッチにアクセスしたい理由は、マシンまたはプロセス境界を越えて伝送するためバッチを保存するということだけである。バッチが実際に永続的ストアにロードされ、永続的ストアからロードされるオブジェクトのグループと相互作用する場合、これは、処理するプラグインにとって非常に複雑なことになる。このような理由から、コレクションアダプタサービスが用意されている。コレクションアダプタサービスは、以下の機能を備えている。
● プラグインコレクションの集合からオブジェクトを取り出す。
● インスタンス化されたオブジェクトをキャッシュし、使用されない場合にはフラッシュする。
● タイプマップを通じてクライアントオブジェクトをサーバオブジェクトにバインディングする作業を管理する。
● 互換性のあるコレクション間のトランザクションを調整する。
● トランザクションに関連してオブジェクトロックを管理する。
● 同期および非同期の両方のオブジェクトを管理する。
● オブジェクトフィルタを実装するためクエリコンパイラと相互作用する。
● 呼び出しを逐次実行するか、または並列実行するかを動的に選択することによりリソースを最適利用する。
● 楽観的ロックスキームを通じてオブジェクト同時実行性を維持する。
● オブジェクト変更通知を処理する。

基本ＣＤＩがさまざまなプラグインを１つにまとめる接着剤の働きをする場合、コレクションアダプタサービスは、高機能、非同期の高性能プラグインの実装ができる限り簡単になるようにする役割を持つ。コレクションアダプタサービスモデルは、一実施形態により図１４に示されている。

与えられたＣＡＳインスタンスは、中に複数のオブジェクトコレクションを差し込むことができる。それぞれのオブジェクトコレクションは、単一のクラス名、例えば「Ｐｒｉｎｔｅｒｓ」をサポートし、与えられたオブジェクトコレクション内のすべてのオブジェクトは、同質である。したがって、与えられたサーバオブジェクトが実装するすべてのプロパティおよびコマンドを表す単一クラス記述により記述することができる。コレクションアダプタサービスは、サーバクラス記述を使用して、クライアントオブジェクトとサーバオブジェクトとの間でデータを転送し、オブジェクトコマンドを実行する。サーバ内のそれぞれのオブジェクトは、ＩＩｍｇＯｂｊｅｃｔインターフェースを介して何らかの基本機能を実装する。ＩＩｍｇＣｏｌｌｅｃｔｉｏｎＡｄａｐｔｅｒは、以下のインターフェースを持つ。

クライアントは、ＩＩｍｇＢａｔｃｈＣｏｌｌｅｃｔｉｏｎＦａｃｔｏｒｙ：：ＣｒｅａｔｅＩｎｓｔａｎｃｅメソッドの「ＣｏＣｒｅａｔｅｉｎｓｔａｎｃｅ」を呼び出すことによりコレクションアダプタをインスタンス化する。これは、ＩＩｍｇＣｏｌｌｅｃｔｉｏｎＡｄａｐｔｅｒ：：Ｉｎｉｔｉａｌｉｚｅを呼び出して、それを、渡されたＩＩｍｇＣｏｍｍｏｎＤａｔａＳｅｒｖｅｒインターフェースに渡す。その後、ＲｅｇｉｓｔｅｒＯｂｊｅｃｔＣｏｌｌｅｃｔｉｏｎ呼び出しを通じて、オブジェクトコレクションのそれぞれをインスタンス化し、登録する。

ＩＩｍｇＯｂｊｅｃｔＣｏｌｌｅｃｔｉｏｎは、以下のメソッドを持つ。

ＧｅｔＴｒａｎｓａｃｔｉｏｎＣｏｌｌｅｃｔｉｏｎＤａｔａ呼び出しは、コレクションがトランザクションをサポートする方法、コレクションがトランザクションをサポートできないこと、従属アイテムとしてのトランザクション（これは、一時的コレクションによりサポートできる）、または基幹ストレージシステムに依存するカスタムトランザクションインターフェースおよびトランザクションが成功できるスコープを一意に識別するＩＤを返すことによりトランザクションをサポートできることの情報を返す。

ＧｅｔＣｏｌｌｅｃｔｉｏｎＤａｔａ呼び出しは、オブジェクトクラス名、最適化されたタイプマップバインディングで使用されるＯｂｊｅｃｔＩｄ、およびそれぞれのオブジェクト記述するサーバクラス記述を返す。残りの呼び出しＢｅｇｉｎＧｅｔおよびＥｎｄＧｅｔおよびＢｅｇｉｎＥｎｕｍ／ＥｎｄＥｎｕｍでは、コレクションからオブジェクトを取り出すことができる。シャットダウンメソッドは、ＩＩｍｇＢａｔｃｈＣｏｌｌｅｃｔｉｏｎ：：Ｓｈｕｔｄｏｗｎメソッドが呼び出された場合にＣＡＳにより呼び出される。

時間がかかりそうなＣＡＳが実行する呼び出しは、Ｂｅｇｉｎ／Ｅｎｄペアの形をとる。それぞれのＢｅｇｉｎ呼び出しは、ＩＩｍｇＳｅｒｖｅｒＩｔｅｍＣｏｍｐｌｅｔｉｏｎインターフェースを取り、ｐｐＣｏｎｔｅｘｔパラメータを通じてコンテキストを返せる。ＣＡＳは、インターフェースのインプリメンタへの以下の保証を行う。
● Ｂｅｇｉｎ呼び出しが失敗した場合、Ｅｎｄ呼び出しは呼び出されない。
● Ｂｅｇｉｎ呼び出しが成功した場合、Ｅｎｄ呼び出しは呼び出されることが保証される。
● Ｅｎｄ呼び出しは、ＩＩｍｇＳｅｒｖｅｒＩｔｅｍＣｏｍｐｌｅｔｉｏｎ：：Ｄｏｎｅメソッドが呼び出されるまで呼び出されない。
● Ｅｎｄ呼び出しは、Ｂｅｇｉｎメソッドが戻るまで実行されない。
● Ｅｎｄ呼び出しは、Ｂｅｇｉｎ呼び出しで返されるコンテキストを渡される。

これらの保証により、Ｂｅｇｉｎメソッドは、Ｂｅｇｉｎメソッド内でＤｏｎｅを呼び出すことにより同期呼び出しを実装することができる。それが実行するＩＯバインドオペレーションを、他のスレッドで実行するか（好ましくは他のオペレーション併せて）、または非同期呼び出しとして順に実装すべきである。非同期アイテムが完了すると、ＩＩｍｇＳｅｒｖｅｒＩｔｅｍＣｏｍｐｌｅｔｉｏｎ：：Ｄｏｎｅメソッドが呼び出されなければならない。開始メソッドが呼び出しに特有の状態を追跡する必要がある場合、これは、ｐｐＣｏｎｔｅｘｔパラメータで返すことができる。ＣＡＳではＥｎｄ呼び出しが実行されることを保証しているので、コンテキストを、常に解放できる。ＣＡＳでは、以下のメカニズムを使用して呼び出しのスケジューリングを行う。
● 呼び出しが同期であり（Ｂｅｇｉｎメソッドの内側でＤｏｎｅが呼び出される）、呼び出し側が並列実行を要求した場合、メソッドの実行は、ＣＰＵバインドであると仮定される。したがって、次の呼び出しは最初にシリアライズされる。呼び出しが失敗すると、結果は記録されるが、後続のすべての呼び出しはそのまま実行される。
● 呼び出しが非同期で、クライアントが並列実行を要求する場合、次の「Ｂｅｇｉｎ」メソッドは開始スレッドで即座に呼び出される。
● 呼び出しが非同期で、クライアントが順次またはトランザクション意味動作を要求した場合、作業の残りは、ＩＩｍｇＳｅｒｖｅｒＩｔｅｍＣｏｍｐｌｅｔｉｏｎ：：Ｄｏｎｅメソッドが呼び出されたのと同じスレッドで実行される。

これらルールは、ＣＡＳのクライアントをコレクションまたはオブジェクト側で、ＩＯバインドオペレーションが非同期パターンで実行されることを保証しなければならないか、さもなければ他のワークアイテムの並列実行を防ぐことができることを意味する。

オブジェクトは、以下のインターフェースを持つ。

実装すべきメソッドは以下のとおりである。
● Ｉｎｉｔｉａｌｉｚｅ呼び出しは、オブジェクトが最初にコレクションから返されたときにＣＡＳにより呼び出される。これは、オブジェクトにそれ自身を削除させる、ロックさせる、トランザクションと相互作用させる、システムの残り部分に変更通知を送らせるハンドラインターフェースをオブジェクトに渡す。また、呼び出しフィルタも返すことができる。呼び出しフィルタは、オブジェクトが部分的インスタンス化をサポートするかどうかを示す（その場合、ＢｅｇｉｎＧｅｔ／ＥｎｄＧｅｔメソッドは、データをそこから読み込む前に呼び出される）。また、いくつかのフィールドを書き出すことのみによりオブジェクトの永続化をサポートするかどうかも示す。この場合、ＢｅｇｉｎＧｅｔ／ＥｎｄＧｅｔメソッドは、呼び出し側が集合内でどのプロパティを指定したかを正確に指定することで呼び出される。
● ＧｅｔＲｅａｌＯｂｊｅｃｔＡｄｄｒｅｓｓはＩｍｇＳｅｒｖｅｒＣｌａｓｓＤｅｓｃｒｉｐｔｉｏｎアクセサリが関係するオブジェクトアドレスを返す。これは、オブジェクトが多重継承を使用して実装されている場合に、ＩＩｍｇＯｂｊｅｃｔインターフェースアドレスは必ずしも実際のオブジェクトアドレスと同じではないため、必要である。
● ＢｅｇｉｎＧｅｔ／ＥｎｄＧｅｔ−これらのメソッドは、その呼び出しフィルタ内で部分的オブジェクトをサポートしていることをオブジェクトが示す場合にのみ呼び出される。オブジェクトは、最適化されたマップがどのフィールドを読み込もうとしているのかを示すタグを渡される。オブジェクトは、永続的ストアからの最初のインスタンス化の後にこれを使用して重いフィールドをフェッチすることができる。オブジェクトがこれを実行し、呼び出しがＩＯバインドである場合（ほとんどいつでもそうなる）、非同期呼び出しパターンを使用しなければならない。
● ＣｌｏｎｅＯｂｊｅｃｔ−ＣＡＳは、オブジェクトが不変な方法で実装されると仮定する。これにより、オブジェクトは、データがそこから読み込まれている間、ロック解除状態のままにできる。これにより、トランザクションがコミットするまでオブジェクトを重複状態に保持できるため、トランザクションが簡素化される。したがって、オブジェクトは、集合が生じる前にそれ自身をクローニングするよう求められる。オブジェクトは、ＣＡＳと互換性のある不変な方法でコーディングされなければならない。
● ＢｅｇｉｎＳｅｔ／ＥｎｄＳｅｔ−メソッドのこのペアは、オブジェクトのクローニングが実行され、そのアクセサリを使用して状態が変更された後に集合内で呼び出される。オブジェクトは、その新しい状態がこの呼び出しで有効であることを確認できる。呼び出しフィルタでそれを要求する場合、その集合が生じたときにクライアントによりどのフィールドが指定されたかが知らされる。

オブジェクトハンドラ
オブジェクトハンドラは、ＣＡＳによりそれぞれのオブジェクトに渡されるインターフェースであり、これにより、オブジェクトは、さまざまな方法でＣＡＳと相互作用できる。ＣＡＳ内でキャッシュ状態を保持されているオブジェクト毎にオブジェクトハンドラのちょうど１つのインスタンスがある。ＩＩｍｇＯｂｊｅｃｔＨａｎｄｌｅｒは、さらに、それぞれのオブジェクトについて非同期ロックも公開する。このロックは、ＣＡＳにより、トランザクションと変更通知の両方を含む状態変更に対するオブジェクトへのアクセスを論理的にシリアライザするために使用される。オブジェクト上のいくつかのアクションでは、オブジェクトをロックする必要がある。オブジェクトハンドラインターフェースによりこの意味動作を強制する。オブジェクトハンドラインターフェースは以下に示されている。

オブジェクト非同期ロック
重要なメソッドは、ＧｅｔＯｂｊｅｃｔＬｏｃｋであり、これにより、呼び出し側は、オブジェクトに関連付けられたロックを取り出すことができる。返されるロックは、トランザクションロックをサポートする非同期ロックである。ロックおよび関連付けられた意味動作は、ＣＡＳにより使用され、その同じ意味動作は、他の呼び出し側により使用されなければならない。インターフェースは以下に示されている。

ロックは、非同期である、つまり、ロックを取得できるときにコールバックする。これは、以下の機能を実現する意図的な設計上の選択である。
● ロックを取得しようとするワークフローをキャンセルできる。ロックインターフェースは非同期なので、呼び出し側に対し、ロック取得の試みがキャンセルされたことを通知できる。
● ロックはトランザクションをまたがってオブジェクトアクセスをシリアライズするために使用されるので、またトランザクションは、多くのオブジェクトを取得しなければならない場合があり、状態をストアに書き込む必要が通常はあるので、オブジェクトロックは、長期間にわたって潜在的に保持される可能性がある。したがって、ロックアクセスは、ＩＯバインドであるオペレーションについて潜在的に待機している可能性がある。非同期ロックを使用すると、スレッドを他のＣＰＵバインドオペレーションに再利用できるため、ＩＯが完了するのを待たなくて済む。

ＣＡＳは、取得／クエリおよびコマンドに対しオブジェクトロックを使用しないことに注意されたい。つまり、トランザクションがオペレーションを論理的に保持している可能性はあるけれども、設定および通知をシリアライザするだけである。呼び出し側でコマンドをトランザクションにしたい場合、トランザクションを自分で作成し、オブジェクトロックを取得しなければならない。

ロックを取得することを望んでいる呼び出し側は、ＩＩｍｇＬｏｃｋＥｎｔｒｙインターフェースを実装しなければならない。このインターフェースは、ＥｎｔｅｒＬｏｃｋとＮｏｔｉｆｙＣａｎｃｅｌの２つのメソッドを持つ。

ＥｎｔｅｒＬｏｃｋは、呼び出し側がロックを取得した場合に呼び出される。ＩｍｇＬｏｃｋＣｏｎｔｅｘｔは、ＥｎｔｅｒＬｏｃｋ関数に渡される。このロックコンテキストは、ロックのその特定の取得に正確に関連付けられており、ロックが解除されたときにロックインターフェースに受け渡さなければならない。これは次の２つの目的を遂行する。
● 他の呼び出し側が誤って、ロックを取得していないのにロックを解除しようとした場合、解除は無効である。
● ロックが保持されなければならないという事実は、ロックコンテキストを提示することが必要だとすることで他のインターフェースにより意味論的に表現することができる。これは、さらに、関連付けられたアクションを実行する前にロックが実際に保持されていることもチェックすることができる。

さらに、呼び出し側がロックを取得したワークフローがキャンセルされる場合、そのインターフェース上のＮｏｔｉｆｙＣａｎｃｅｌメソッドが呼び出される。その後、それでもまだロックを取得しなければならないかどうか、またはロックへのアクセスをアボートすべきかどうかを決定することができる。ＡｃｑｕｉｒｅＬｏｃｋが呼び出された必要なロックシーケンスインターフェースを解放することによりロックの取得をキャンセルすることができる。

呼び出し側が、ロックを取得することが可能であると保証できない場合には望ましくない。例えば、ロックを取得し、参照カウントをインクリメントし、その後ロックを解除したい場合がある。その後、オブジェクトに対しいくつかのアクションを実行し、再びロックを取得し、参照カウントをデクリメントすることが可能である。第２のオペレーションに対してロックを取得することができなかった場合、参照カウントは正しくデクリメントされることは決してない。

呼び出し側がロックへのアクセスを保証できるようにするには、ＩＩｍｇＬｏｃｋＳｅｑｕｅｎｃｅインターフェースを使用する。ロックシーケンスがロックから戻ると、ロックの順次取得および解除は成功することが保証される。これは、実装の詳細として、ＩＩｍｇＬｏｃｋＳｅｑｕｅｎｃｅインターフェースは、十分な記憶域を確保し常にロックを取得できるオブジェクトにより実装される。

ロックとトランザクション
トランザクションは、多数のオブジェクトを順次ロックすることを必要とする場合がある。これは、複数のトランザクション間にロックの循環取得がある場合にシステムがデッドロックに陥る機会となる。２つのトランザクションが同じロックを保持していることは意味論的には非論理的であり、したがって、ロックはトランザクションに対する特別なサポートを行う。これは、プロパティを設定する前にオブジェクトをロックするときにＣＡＳにより自動的に使用され、トランザクションの意味動作を実装したいオブジェクトにより使用されなければならない。

ロックは、一度にちょうど１つのトランザクションにより保持することができる。ロックを取得することを望んでいるトランザクションは、ＡｄｄＴｒａｎｓａｃｔｉｏｎＴｏＬｏｃｋ呼び出しを使用する。ロックを保持しているトランザクションがすでにある場合には、この呼び出しは、ｐｂＴｒａｎｓａｃｔｉｏｎＡｄｄｅｄパラメータでＦＡＬＳＥを返す。その後、トランザクションは復帰され（トランザクションにより現在保持されているロックまたはリソースを解放する）、呼び出し側に失敗を返す前に既存のトランザクションが完了するのを待たなければならない。呼び出し側は、ＷａｉｔＦｏｒＴｒａｎｓａｃｔｉｏｎＴｏＦｉｎｉｓｈを呼び出して、ロックを保持しているトランザクションが完了するのを待つ（これらは非同期的に通知される）。ロックを保持しているトランザクションがない場合、即座にコールバックされる。ロックは、トランザクションがコミットされるかまたは復帰されると、トランザクションから自動的に切り離される。

呼び出し側が既存のトランザクションの終了を待たなければならない理由は、呼び出し側がオペレーションを再試行した場合に、簡単に再び古い（変更されていない）オブジェクト状態を取り出し、ロックを保持しているトランザクションに対し「スピン」する、ということがないことを保証することである。

ＣＤＩ／ＣＡＳ楽観的ロックモデル
ＣＤＩは、クライアントに対し、ロック構文を意図的に公開していない。この理由は多数ある。
● それぞれのロックは、さらにコンテキストオーバーヘッドをクライアントにより維持される可能性のあるサーバに加えなければならない。
● クライアントがエラー状態に入り、ロックを続けた場合、サーバのオペレーションを無効にする可能性がある。
● ロックを解除していないクライアントを取り扱うために、手動ロック破壊メカニズムをサーバに追加しなければならない。これは、他の方法では単に回避される追加ＵＩおよびメンテナンスである。

しかし、サーバ状態を正しく保持し、「戦う管理者」問題を回避することは望ましい。２人の管理者が同時にプリンタの名前を変更しようとした場合のために、一方の名前変更は成功するが、他方は失敗するようにしたい。

システムは、オブジェクトロックを取得するためにトランザクションが使用するメカニズムにより部分的にそれらの意味動作を保持する。また、すべてのオブジェクトに「Ｏｂｊｅｃｔ：ＬｏｃｋＩｄ」プロパティを与えることにより保持される。簡単に言うと、オブジェクト状態を変更するには、さらに、現在のオブジェクトロックｉｄと一致するロックｉｄを用意しなければならないということである。これは、オブジェクトを変更しようとする前にユーザが最後のオブジェクト状態に気づいていたことを示す。一致しないオブジェクトｉｄを与えた場合、状態を変更しようとする試みは失敗する。それに対する応答として、呼び出し側は、変更したいプロパティを再度取得しなければならず、したがってロックｉｄを再度取得しなければならない。その後、適切に書かれているクライアントであれば、プロパティをチェックして、有効にしたい変更がまだ意味を持つことを確認してから、再びオペレーションを試みる。

オブジェクト変更ハンドラ
オブジェクトに対する変更ハンドラを取り出すために、オブジェクトロックを取得し、その後、オブジェクトハンドラでＧｅｔＣｈａｎｇｅＨａｎｄｌｅｒメソッドを呼び出さなければならない。ＧｅｔＣｈａｎｇｅＨａｎｄｌｅｒメソッドは、ロックコンテキストを必要とする。変更ハンドラを取得するためにオブジェクトが使用できる他のメカニズムは、設定時にパラメータとしてプロパティアクセッサに渡すというものである。（この場合のＣＡＳは、オブジェクトプロパティを設定してくれる前にオブジェクトロックを取得する）。オブジェクト変更ハンドラインターフェースは以下に示されている。

ＣＤＩ変更ハンドラインターフェースについては上の節で説明されている。そのインターフェースは、特定のチャネル通して変更を送る機能を備える。ＣＡＳは、クエリのスコープを正しく設定し、特定のオブジェクトに注目している可能性のあるチャネルすべてを処理する機能を追加する。オブジェクトが実行しなければならないのは、どのプロパティが変更したかを示すことだけである。最も単純なメカニズムは、ＮｏｔｉｆｙＣｈａｎｇｅを呼び出して、変更されたフィールドのタグを渡すことである。ＣＡＳは、その後、プロパティアクセッサを介してそのフィールドに対するデータを取り出し、プロパティ変更通知を、その変更に注目するすべてのチャネルに送信する。

ＣＡＳがプロパティを取り出す手間を省くために、呼び出し側は、さらに、ＮｏｔｉｆｙＣｈａｎｇｅＤａｔａ呼び出しを介してデータを直接指定することもできる。

最後に、すべての変更が変更ハンドラに蓄積されると、ＳｅｎｄＣｈａｎｇｅｓメソッドを介して送ることができる。変更をどれも送れない場合、ＣＡＳは、そのオブジェクトをターゲットとする可能性のあるすべての通知チャネルを破棄する。

変更通知のＩＡＴＬサポート
変更通知は、オブジェクト側で実装するのは困難でない。さらに簡単に行えるようにするため、オブジェクトのプロパティがＣＤＩプロパティの取得または設定を通じてしか修正されず、そのプロパティがデータメンバとして実装される場合に、ＩＡＴＬは、変更通知コードを自動的に生成する。フィールドを指定するときに、ｇＮｏｔｉｆｙ修飾子をタイプマップ内のＦｉｅｌｄ関数に渡すだけでよい。これは以下に示されている。

これは、そのプロパティの取得および設定アクセッサを自動的に構築する。プロパティが変化すると、変更は、ＣＡＳによりプロパティアクセッサに供給される変更ハンドラに送られる。

残りのオブジェクトハンドラ関数
ＤｅｌｅｔｅＯｂｊｅｃｔ
この関数は、ＣＡＳのキャッシュからオブジェクトを削除する。これは、さらに、変更通知をクライアントにも送る。オブジェクトを削除するには、オブジェクトがロックされ、ロックコンテキストが提示されていなければならない。

ＣｕｒｒｅｎｔＯｂｊｅｃｔ
ＣＡＳは不変なオブジェクトモデルを使用する。オブジェクトが修正されると、クローンが作成され、その後、状態が変更された場合にキャッシュ内に挿入される。エラーが発生した場合、新しいオブジェクトは破棄される。この設計の意味するものとして興味深いのは、オブジェクトが非同期イベントの結果として変更通知を送りたい場合、または他の何らかの形でプロパティ取得時またはコマンド実行時にオブジェクトの最新バージョンを必要とする場合に、現在保持しているオブジェクトのインスタンスが正しいインスタンスであるかどうかを知ることができないという点である。この場合に対処するために、オブジェクトハンドラは、現在のオブジェクトインスタンスを取り出すことができる。オブジェクト状態変更はオブジェクトロックにより保護されているため、ロックは、現在のオブジェクトが意味のある形で取り出される前に取得されなければならない。

ＨｏｌｄＯｂｊｅｃｔＩｎＣａｃｈｅとＲｅｌｅａｓｅＯｂｊｅｃｔＦｒｏｍＣａｃｈｅ
ＣＡＳは、通常、オブジェクトを約１０秒間メモリ内にキャッシュしてから破棄する。オブジェクトは、代わりに、キャッシュ内に永久的に残るか、または他のオブジェクトがキャッシュされている間にキャッシュされたままとすることを決定することができる。この要求条件に対応するため、ＨｏｌｄＯｂｊｅｃｔＩｎＣａｃｈｅメソッドをオブジェクトハンドラ上で呼び出すことができる。呼び出されると、オブジェクトは、対応するＲｅｌｅａｓｅＯｂｊｅｃｔＦｒｏｍＣａｃｈｅ呼び出しが実行されるまでキャッシュ内に保持される。ＨｏｌｄＯｂｊｅｃｔＩｎＣａｃｈｅは、何回も呼び出すことができ、オブジェクトは、ＲｅｌｅａｓｅＯｂｊｅｃｔＦｒｏｍＣａｃｈｅへの同じ回数の呼び出しが実行されたときのみ解放される。

他のいくつかのオペレーションのためオブジェクトがすでにキャッシュ内にアクティブ状態で保持されている場合にＨｏｌｄＯｂｊｅｃｔＩｎＣａｃｈｅを安全に呼び出すことができる。そうでない場合、ＨｏｌｄＯｂｊｅｃｔＩｎＣａｃｈｅへの呼び出しが実行されている間に、キャッシュからオブジェクトが解放される潜在的競合状態がある。これで、クラッシュは生じないが、明らかに、ＨｏｌｄＯｂｊｅｃｔＩｎＣａｃｈｅ呼び出しはこの場合には受け付けられない。ＨｏｌｄＯｂｊｅｃｔＩｎＣａｃｈｅが変更することを保証される時点は以下のとおりである。
● オブジェクトによりサポートされているＩＩｍｇＯｂｊｅｃｔインターフェースへのＩｎｉｔｉａｌｉｚｅ呼び出しのとき。
● プロパティの取得または設定またはコマンド呼び出しのとき。
● 呼び出し側が、他の何らかの方法で、以前にＨｏｌｄＯｂｊｅｃｔＩｎＣａｃｈｅ呼び出しを発行したことを知っているとき。

フレームワーク提供コレクション
ＩＩｍｇＯｂｊｅｃｔＣｏｌｌｅｃｔｉｏｎおよびＩＩｍｇＯｂｊｅｃｔインターフェースは、実装することについては特に困難ではなく、ＣＡＳを使用するプラグインが両方とも実装したいか、または実装する必要がある場合がある。例えば、新しいデータモデルを介してダウンレベルサーバ上のオブジェクトを表すアダプタを書く場合、自分用のＩＩｍｇＯｂｊｅｃｔＣｏｌｌｅｃｔｉｏｎを用意したい。しかし、標準フレームワーク提供のオブジェクトコレクションを使用できる場合が多数ある。これらは図１５に示されている。

フレームワーク提供コレクションおよびその関数は以下のとおりである。

メモリ内コレクションは、永続しないオブジェクトの動的コレクションを提供する。このコレクションは、公開すべき少数の実際の不変なオブジェクトとともにプラグインにより与えられたときに有用な場合がある（フィルタファクトリなど）。また、これは、ＴＳ印刷などのシナリオで軽量の永続不可能なオブジェクト用のストアを用意する際にも有用な場合がありうる。

永続的オブジェクトコレクションサービスは、永続的ストア内にオブジェクトを持続させることができる機能を備えるコレクションである。レジストリ、ＳＱＬデータベース、またはＷｉｎＦＳを含む、オブジェクトを持続させることができるストアが多数ありうる。それぞれのストアは、それ専用の永続的オブジェクトコレクションサービスのインスタンスを持つ。永続的オブジェクトコレクションサービスは、適切なストアにオブジェクト状態を入れて持続させる機能をサポートする。これは、サーバタイプマップ（ＩｍｇＳｅｒｖｅｒＣｌａｓｓＤｅｓｃｒｉｐｔｉｏｎ）を使用して、格納に必要なオブジェクト状態を取り出す。さらに、可能な場合には基幹ストアにより実現されるクエリサポートにクエリを直接マッピングする。

通知シムコレクションは以下のように機能する。多くの場合において、システムは、通知に対する限られたサポートを行う、または全くサポートしないダウンレベルシステムにブリッジする。この場合、呼び出し側は、すべてのオブジェクトを列挙し、新しいオブジェクトが到着するか、または出て行くかを確認し、フィールドに変化があった場合に適切な通知を発生させる必要がある。ＩＩｍｇＯｂｊｅｃｔＣｏｌｌｅｃｔｉｏｎインターフェースはパブリックであり、ＩｍｇＳｅｒｖｅｒＣｌａｓｓＤｅｓｃｒｉｐｔｉｏｎにより、呼び出し側は、オブジェクト上のフィールドすべてにアクセスすることができるため、この動作を自動化する汎用シムオブジェクトコレクションが用意される。これは、さらに、通知をサポートするだけのために余分な数行のコードを追加したくない呼び出し側に対し使用することも可能である。しかし、変更があった場合に自動的に通知を生成するデフォルトの実装をフィールドに対し用意することができる。

要するに、フレームワークは、ほとんどのユーザが自分専用のコレクションインターフェースを実装しなくて済む缶詰オブジェクトコレクションを多数用意するということである。アダプタコレクションインターフェースは、可能な例外である。シムコレクションは、ダウンレベルアダプタからのイベントの生成を自動化するために用意される。

ＩＩｍｇＯｂｊｅｃｔのＩＡＴＬ実装
ＩＩｍｇＯｂｊｅｃｔも、特に実装が困難なインターフェースではない。標準オブジェクトをできるだけ簡単に書けるようにするために、ＩＡＴＬは、非部分的オブジェクト実装をサポートするＩＩｍｇＯｂｊｅｃｔの標準実装を備える。実装されるクラスは以下のとおりである。
● ＴＳｅｒｖｅｒＯｂｊｅｃｔＢａｓｅ−ＩＵｎｋｎｏｗｎ、Ｉｎｉｔｉａｌｉｚｅ、ＢｅｇｉｎＧｅｔ／ＥｎｄＧｅｔ、およびＢｅｇｉｎＳｅｔ／ＥｎｄＳｅｔのデフォルト実装を提供する。取得および設定関数は何もしない。
● ＴＳｅｒｖｅｒＯｂｊｅｃｔ−このテンプレートは、基本クラステンプレート作成機能を通じてＧｅｔＲｅａｌＯｂｊｅｃｔＡｄｄｒｅｓｓ実装を追加する。
● ＴＳｅｒｖｅｒＤｅｆａｕｌｔＣｌｏｎｅａｂｌｅＯｂｊｅｃｔ−このテンプレートは、ＣｌｏｎｅＯｂｊｅｃｔメソッドを追加する。呼び出し側は、派生クラスにコピーコンストラクタを用意しなければならず、またオブジェクトがコピーされた後、例外をスローしないか、エラーがあった場合には例外をスローするか、またはＩｓＶａｌｉｄ（）メソッドからエラーを返すようにしなければならない。
● ＴＩＭＣＳｅｒｖｅｒＯｂｊｅｃｔ−このオブジェクトは、メモリ内コレクション用にＢｅｇｉｎＳｅｔ／ＥｎｄＳｅｔメソッドペアを実装する。

マネージドオブジェクト
ＩＡＴＬは、メソッドおよびフィールドをプロパティとして表すことができ、メソッドをＣＤＩを通じてコマンドとして表すことができるテンプレートライブラリを用意することにより、アンマネージドＣ＋＋クラスを自動的にサポートするように設計されている。アンマネージド空間内に残すことには多くの利点があるが、システムでは、特にパフォーマンス、ロバスト性、および設計安定性の面でマネージドコードが改善されるので、マネージドオブジェクトのデータ駆動型のサポートを行うようにもしたい。

ＣＡＳは多くの重要な機能をカプセル化するので、同じことを行う並列のマネージド実装を用意することは賢明でない。解決策として、マネージドメタデータを使用して、アンマネージド空間内にＩｍｇＳｅｒｖｅｒＣｌａｓｓＤｅｓｃｒｉｐｔｉｏｎを作成し、それを使用して、シャドウアンマネージドオブジェクトに値を設定し、シャドウアンマネージドオブジェクトを保持する。

一実施形態による解決策が図１６に示されている。ここで、マネージドオブジェクトからのクラスメタデータは、アンマネージド空間内のＩｍｇＳｅｒｖｅｒＣｌａｓｓＤｅｓｃｒｉｐｔｉｏｎにマッピングされる。このクラス記述では、シャドウアンマネージドオブジェクトを操作できるアクセッサを使用する。アンマネージドオブジェクト内のそれぞれのプロパティにインデックスを設定することができ、それぞれのプロパティは、マネージドオブジェクト内のプロパティに対応する。マネージドオブジェクトは、変更通知メカニズムを使用して、非同期変更をシャドウアンマネージドオブジェクトに伝搬する。アンマネージドオブジェクト上で設定が行われると必ず、最初にそれらのプロパティがマネージドオブジェクトに適用され、次に、マネージドオブジェクトの状態が複製されてアンマネージドオブジェクトに戻される。コマンドは、マネージドオブジェクト上のメソッド呼び出しに直接マッピングされる。

このメカニズムの利点は、オブジェクト上の最も一般的なオペレーションである取得およびクエリが、アンマネージドシャドウオブジェクト上で完全に実行されるという点である。さらに、アンマネージドシャドウオブジェクトは、アンマネージド永続的オブジェクトコレクションサービスにより格納することができ、またメモリ内コレクションの中に配置することができる。これは、さらに、他の方法ではプロパティ取得を実行するために必要になるであろう遅いリフレクションメカニズムをバイパスする。マネージドオブジェクトに対する変更は、１バッチアクション当たり１つの相互運用サンクに制約することができる。ＣＡＳの後にこれが発生するため、解釈の前にバッチ全体をマーシャリングすることはできない。この制限は、クエリおよび取得の場合にマネージドパスを全く回避することにより弱めなければならない。

例示的なクライアントデバイス／プリントサーバコンポーネント
図１７は、上述の実施形態を実装するためにクライアントデバイスと印刷システムの両方において使用できるコンポーネントを備える例示的なコンピューティングデバイスを示している。

コンピューティングデバイス１７４２は、１つまたは複数のプロセッサまたは処理ユニット１７４４、システムメモリ１７４６、およびシステムメモリ１７４６を含むさまざまなシステムコンポーネントをプロセッサ１７４４に結合するバス１７４８を備える。バス１７４８は、メモリバスまたはメモリコントローラ、周辺機器バス、アクセラレイティッドグラフィックスポート、およびさまざまなバスアーキテクチャのどれかを使用するプロセッサまたはローカルバスを含む数種類のバス構造のうちの１つまたは複数を表している。システムメモリ１７４６は、読み取り専用メモリ（ＲＯＭ）１７５０およびランダムアクセスメモリ（ＲＡＭ）１７５２を含む。起動時などにコンピューティングデバイス１７４２内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１７５４は、ＲＯＭ１７５０に格納される。

コンピューティングデバイス１７４２は、さらに、図に示されていないハードディスクへの読み書きを行うためのハードディスクドライブ１７５６、取り外し可能磁気ディスク１７６０への読み書きを行うための磁気ディスクドライブ１７５８、およびＣＤ−ＲＯＭまたはその他の光媒体などの取り外し可能光ディスク１７６４への読み書きを行うための光ディスクドライブ１７６２を備える。ハードディスクドライブ１７５６、磁気ディスクドライブ１７５８、および光ディスクドライブ１７６２は、ＳＣＳＩインターフェース１７６６または他の何らかの適切なインターフェースによりバス１７４８に接続される。ドライブおよび関連コンピュータ可読媒体は、コンピュータ１７４２用のコンピュータ可読命令、データ構造体、プログラムモジュール、およびその他のデータを格納する不揮発性記憶装置を実現する。本発明で説明されている例示的な環境ではハードディスク、取り外し可能磁気ディスク１７６０、および取り外し可能光ディスク１７６４を採用しているが、当業者であれば、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、複数のランダムアクセスメモリ（ＲＡＭ）、複数の読み取り専用メモリ（ＲＯＭ）などのコンピュータからアクセス可能なデータを格納できる他のタイプのコンピュータ可読媒体もこの例示的な動作環境で使用できることを理解するであろう。

オペレーティングシステム１７７０、１つまたは複数のアプリケーションプログラム１７７２（ユーザエージェントまたはブラウザなど）、その他のプログラムモジュール１７７４、およびプログラムデータ１７７６を含む、多くのプログラムモジュールは、ハードディスク１７５６、磁気ディスク１７６０、光ディスク１７６４、ＲＯＭ１７５０、またはＲＡＭ１７５２に格納されることができる。ユーザはキーボード１７７８およびポインティングデバイス１７８０などの入力デバイスを通じてコンピュータ１７４２にコマンドおよび情報を入力することができる。他の入力装置（図に示されていない）としては、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらの入力デバイスおよびその他の入力デバイスは、バス１７４８に結合されたインターフェース１７８２を通じて処理ユニット１７４４に接続される。モニタ１７８４またはその他の種類の表示デバイスも、ビデオアダプタ１７８６などのインターフェースを介してバス１７４８に接続される。パーソナルコンピュータは、通常、モニタのほかに、スピーカおよびプリンタなど、他の周辺出力デバイス（図に示されていない）を備える。

コンピュータ１７４２は、通常、さらに１つまたは複数のプリンタに接続されるプリントサーバ１７８８などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク接続環境で動作する。プリントサーバ１７８８は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の共通ネットワークノードとすることができ、通常は、コンピュータ１７４２に関して上で説明されている要素の多くまたはすべてを含む。図１７で説明されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７９０とワイドエリアネットワーク（ＷＡＮ）１７９２を含む。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットでは一般的である。

ＬＡＮネットワーキング環境で使用する場合、コンピュータ１７４２はネットワークインターフェースまたはアダプタ１７９４を介してローカルネットワークに接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ１７４２は、通常、モデム１７９６またはインターネットなどのワイドエリアネットワーク１７９２上で通信を確立するためのその他の手段を備える。モデム１７９６は、内蔵でも外付けでもよいが、シリアルポートインターフェース１７６８を介してバス１７４８に接続される。ネットワーク接続環境では、パーソナルコンピュータ１７４２またはその一部に関して示されているプログラムモジュールは、リモートメモリ記憶デバイスに格納されうる。図に示されているネットワーク接続は例示的であり、コンピュータ間の通信リンクを確立するのに他の手段が使用可能であることは理解されるであろう。

一般に、コンピュータ１７４２のデータプロセッサは、コンピュータのさまざまなコンピュータ可読記憶媒体にさまざまな時点において格納された命令を使ってプログラムされる。プログラムおよびオペレーティングシステムは、通常、例えば、フロッピー（登録商標）ディスクまたはＣＤ−ＲＯＭで配布される。そこから、コンピュータの補助記憶装置にインストールまたはロードされる。実行時に、それらは少なくとも一部はコンピュータの主記憶装置にロードされる。本明細書で説明されているシステムは、これらおよび他のさまざまな種類のコンピュータ可読記憶媒体を含むが、ただしそのような媒体にマイクロプロセッサまたはその他のデータプロセッサに関して説明されるブロックを実装する命令またはプログラムが格納されている場合である。説明されているシステムは、さらに、本明細書で説明されている方法および手法に従ってプログラムされた場合にコンピュータ自体も含む。

説明のため、プログラムおよびオペレーティングシステムなどの他の実行可能なプログラムコンポーネントは、本明細書では、離散ブロックとして例示されているが、そのようなプログラムおよびコンポーネントは、さまざまな時点において、コンピュータの異なる記憶コンポーネント内にあり、コンピュータの（複数の）データプロセッサにより実行されることは理解される。

結論
上述のさまざまな実施形態は、サードパーティのコンポーネント作成者が新しいクラスをシステム内に容易に挿入することを可能にできるプラガブルアーキテクチャを備える。複数のデータプロバイダからデータを取り出せるルーティングシステムが実現される。さらに、名前解決パイプラインが、人間によって指定された名前を内部の正規名に解決する。さらに、さまざまな実施形態では、オブジェクトから取り出したいデータをクライアントが正確に指定することができる機能を備える。オブジェクトからデータを取り出すための極めて効率的なメカニズムは、最適化されたタイプマップを使用する。タイプマップが構築されると、それ以上、文字列比較または検索を実行する必要はない。任意のデータをサポートできる単一のプラガブルインターフェースも備える。これは、セットアップに関する限り、インストール可能オブジェクトは１種類のみ必要であるということを意味する。他のオブジェクト型は、コレクションを通じてファクトリオブジェクトから取得できる。これは、例えば、パイプライン要素を構築するために使用できる。

さらに、システム内の任意のオブジェクトでクエリをサポートし、フィルタ処理された通知を含む通知をサポートし、キャッシングおよび作業スケジューリングをサポートすることを簡単に行えるようにする一群のサービスが提供される。

説明されている実施形態は、さらに、アクセスアダプタを通じて一連の基本型を処理できるプロトコルまたはトランスポート上でのトンネリングを可能にする機能も備えることができる。さまざまな実施形態ではさらに、ダウンレベルプロトコルでトランスポートされるオブジェクトのコレクションを提供し、ダウンレベル（およびアップレベル）プロトコルをシステムに動的に追加できる機能もサポートする。

さらに、非同期データインターフェースが備えられる。これは、多数の最終的にはＩＯバインドデータ書き込みが発生する場合に同期インターフェースだとサーバの機能が絞られるため重要である。また、単一ＵＩスレッドが実行され、実行中のオペレーションに対してストールしないため、ＵＩプログラミングが簡素化される。

さらに、バッチ処理インターフェースを使用することにより、オブジェクトコマンド、取得、設定、クエリ、および通知要求の任意のグループ化が可能である。これは、クライアントがプリンタのコレクションを削除するなどのオペレーションをサポートすることが可能になるため重要である。また、ネットワーク待ち時間の影響を低減できるという点でも有利である。例えば、ＵＩで、特定のキューに関する多数のプロパティを取り出したい場合、その要求すべてを１つのメッセージでバッチ化することにより、ネットワーク上で１回のやり取りで済ませることができるが、もしデータが順次的に取り出されるとすれば、ネットワーク上で何回もやり取りする必要がある。

さらに、さまざまな実施形態では、通知を除いて、ほとんど完全にステートレスなインターフェースを実現することができる。

さらに、プログラミングモデルは、クライアントオブジェクトのコレクションを使用することにより簡素化される。バッチ実行が成功してオブジェクトに値が設定された後、取り出されたデータに対する後続のすべてのオペレーションは、そのオブジェクト状態で格納されているため成功することが保証される。このプログラミングモデルは、さらに、通知およびクエリクライアントの意味動作をきちんと、ほとんど同じにする。

さらに、ＣＤＩでは、後続の反復で、またはいくつかのコレクションにおいて、以下を可能にできる。まず、ＣＤＩでは、標準型メタデータシステムを通じて新しいデータ型を動的に発見する機能を利用できる。汎用デバッグインターフェースおよびデータクエリインターフェースなどのいくつかの機能が使用可能になる。第２に、すべてのコレクションは同じインターフェースを持つため、他のプロセスまたはアプリケーションドメインにおいて容易にサンドボックス化できる。第３に、すべてのコレクションは同じインターフェースを持つため、呼び出しカウントシム（ｃａｌｌｃｏｕｎｔｉｎｇｓｈｉｍ）を実装することにより、システムは任意のコレクションをメンテナンスモードにし、それをアンロードすることができる。これは、既存のコンポーネントをアップグレードするときに、セットアップ作業におおいに役立つ。第４に、バッチもトランザクションにすることにより、トランザクションサポートを極めて容易に追加できる。最後に、すべてのオブジェクトは同じインターフェースを使用するため、デコレータなどのパターンをシステムに容易に追加できる。これにより、サードパーティが自由自在にシステムを拡張できる可能性が広がる。

本発明は構造的機能および／または方法論的ステップに固有の言語で説明されているが、付属の請求項で定められている発明は、説明した特定の機能またはステップに必ずしも限られないことは理解されるであろう。むしろ、特定の機能およびステップは請求されている発明を実施する好ましい形態として開示されている。

一実施形態によるデータインターフェースのさまざまなコンポーネントを例示する高水準ブロック図である。一実施形態による印刷データアクセスインターフェースの高水準ブロック図である。一実施形態によるプロセス外通信のいくつかの態様を例示するブロック図である。一実施形態によるセキュリティモデルの概要を例示する高水準ブロック図である。一実施形態によるタイプマッピングメカニズムを例示するブロック図である。一実施形態による共通データインターフェースオブジェクトアクセスインターフェースのブロック図である。一実施形態による動的タイプマップのブロック図である。一実施形態によるオブジェクト作成およびクローニングを例示するブロック図である。一実施形態による抽象階層を例示するブロック図である。一実施形態によるクラス階層およびセキュリティを例示するブロック図である。一実施形態によりオブジェクトから取り出されるメタデータを例示するブロック図である。一実施形態による共通データインターフェースの例示的なコンポーネントのブロック図である。一実施形態によるプラグインモデルのブロック図である。一実施形態によるコレクションアダプタサービスにより使用されるオブジェクトモデルのブロック図である。一実施形態によるフレームワーク提供コレクションを例示するブロック図である。一実施形態によるマネージドオブジェクトおよびアンマネージドオブジェクトの相互運用性を例示するブロック図である。１つまたは複数の実施形態を実装するために使用することができるコンピューティングデバイスの例示的なコンポーネントを示すブロック図である。

符号の説明

１００システム
１０２共通データインターフェース（ＣＤＩ）
１０４バッチ処理ルータ
１０６プラグインテーブル
１０８インターセプションテーブル
１１０メッセージプラグイン
１１２メッセージサービス
１１４コレクション
１１６オブジェクト
１１８システム拡張
１２０他のコラボレーション
１７４２コンピュータ
１７４４処理ユニット
１７４６システムメモリ
１７４８バス
１７５０ＲＯＭ
１７５６ハードディスクドライブ
１７５８磁気ディスクドライブ
１７６０磁気ディスク
１７６２光ディスクドライブ
１７６４光ディスク
１７６６ＳＣＳＩインターフェース
１７６８シリアルポート
１７７０オペレーティングシステム
１７７２アプリケーションプログラム
１７７４他のモジュール
１７７６プログラムデータ
１７７８キーボード
１７８０ポインティングデバイス
１７８２キーボード／マウスインターフェース
１７８４モニタ
１７８６ビデオアダプタ
１７８８プリントサーバ
１７９０ローカルエリアネットワーク
１７９２ワイドエリアネットワーク
１７９４ネットワークインターフェース
１７９６モデム

Claims

コンピュータ可読命令を含む１つまたは複数のコンピュータ可読媒体であって、前記命令は、実行されると、
汎用データモデルを実現するように構成されたインターフェースを備え、
クライアントまたはクライアントアプリケーションが、クライアントスレッドに制御を即座に返すデータ要求を開始できるようにする非同期クライアントディスパッチを実現し、
サーバが前記クライアントから非同期に要求を処理することができる非同期サーバディスパッチを実現するように構成されたソフトウェアアーキテクチャを実現することを特徴とする１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、前記サーバ上で進行中の呼び出しをいつでも前記クライアントによりキャンセルできるキャンセレーションを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、クライアントがアクションの任意のシーケンスを構築し、前記アクションを前記サーバに１つの単位として送信できるバッチ処理を実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、アクションのバッチに、全体として実行しなければならない、または前記サーバの状態を変更してはならないという意味動作を割り当てることができるトランザクション呼び出しを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、アクションのバッチに、すべてのアイテムは並列実行できるという意味動作を割り当てることができるトランザクション呼び出しを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、関連付けられたシステムを監視すること、前記システムに同期して応答すること、または前記システムの動作を修正することのうちの１つまたは複数を実行できるコンポーネントを前記アーキテクチャ内に挿入できるインターセプションを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、オブジェクトの与えられたクラスによりサポートされるプロパティを取り出すために使用できるリフレクションを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、
クライアントがアクションの任意のシーケンスを構築し、前記アクションを前記サーバに１つの単位として送信できるバッチ処理と、
アクションのバッチに、全体として実行しなければならない、または前記サーバの状態を変更してはならないという意味動作を割り当てることができるトランザクション呼び出しとを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、
クライアントがアクションの任意のシーケンスを構築し、前記アクションを前記サーバに１つの単位として送信できるバッチ処理と、
アクションのバッチに、すべてのアイテムは並列実行しなければならないという意味動作を割り当てることができる並列呼び出しとを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、
クライアントがアクションの任意のシーケンスを構築し、前記アクションを前記サーバに１つの単位として送信できるバッチ処理と、
アクションのバッチに、全体として実行しなければならない、または前記サーバの状態を変更してはならないという意味動作を割り当てることができるトランザクション呼び出しと、
アクションのバッチに、すべてのアイテムは並列実行しなければならないという意味動作を割り当てることができる並列呼び出しとを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、
クライアントがアクションの任意のシーケンスを構築し、前記アクションを前記サーバに１つの単位として送信できるバッチ処理と、
関連付けられたシステムを監視すること、前記システムに同期して応答すること、または前記システムの動作を修正することのうちの１つまたは複数を実行できるコンポーネントを前記アーキテクチャ内に挿入できるインターセプションとを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、
クライアントがアクションの任意のシーケンスを構築し、前記アクションを前記サーバに１つの単位として送信できるバッチ処理と、
オブジェクトの与えられたクラスによりサポートされるプロパティを取り出すために使用できるリフレクションとを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
前記ソフトウェアアーキテクチャは、
クライアントがアクションの任意のシーケンスを構築し、前記アクションを前記サーバに１つの単位として送信できるバッチ処理と、
オブジェクトの与えられたクラスによりサポートされるプロパティを取り出すために使用できるリフレクションと、
関連付けられたシステムを監視すること、前記システムに同期して応答すること、または前記システムの動作を修正することのうちの１つまたは複数を実行できるコンポーネントを前記アーキテクチャ内に挿入できるインターセプションとを実現するように構成されることを特徴とする請求項１に記載の１つまたは複数のコンピュータ可読媒体。
コンピュータ可読命令を含む１つまたは複数のコンピュータ可読媒体であって、前記命令は、
印刷システムであって、
バッチ処理ルータへのインターフェースとして使用さる、クライアントからのメッセージを構築して前記バッチ処理ルータにディスパッチし、応答を前記クライアントに送信できるように構成されている、共通データインターフェースと、
前記共通データインターフェースと通信できるようにリンクされ、前記共通データインターフェースにより渡されるメッセージを受信し、１つまたは複数のコレクションに前記メッセージを非同期にディスパッチするように構成された、バッチ処理ルータと、
１つまたは複数のコレクションを対象とするメッセージを受信して、処理するように構成されたメッセージ処理プラグインを追跡するように構成されているプラグインテーブルと、
１つまたは複数のオブジェクトをターゲットとするメッセージをインターセプトして修正する場合に使用するように構成されたインターセプションテーブルとを含む印刷システムを備えるソフトウェアアーキテクチャを実現することを特徴とする１つまたは複数のコンピュータ可読媒体。
前記メッセージは、１つまたは複数のプラグインを宛先とする１つまたは複数のオペレーションを含むことができることを特徴とする請求項１４に記載の１つまたは複数のコンピュータ可読媒体。
さらに、前記バッチ処理ルータに通信できるように関連付けられ、前記バッチ処理ルータからメッセージの集合を受信し、適切な場合に、前記メッセージを他のデバイスに送信するように構成されたメッセージプラグインを備えることを特徴とする請求項１４に記載の１つまたは複数のコンピュータ可読媒体。
さらに、前記バッチ処理ルータに通信できるように関連付けられ、コレクションインターフェース上でメッセージを受信し、前記メッセージを呼び出しのシーケンスに分割するように構成されたメッセージサービスを含むことを特徴とする請求項１４に記載の１つまたは複数のコンピュータ可読媒体。
さらに、前記バッチ処理ルータに通信できるように関連付けられ、コレクションインターフェース上でメッセージを受信し、前記メッセージを呼び出しのシーケンスに分割するように構成されたメッセージサービスを含み、前記メッセージサービスは、
メッセージをスレッドに割り当てるタスク、または
メッセージが複数の遅延呼び出しに応答できるようにするタスク、または
コレクション内のオブジェクトから適切なデータを取り出して、メッセージに設定するタスク、または
キャンセレーションオペレーションを処理するタスク、または
オブジェクトインスタンスをキャッシングするタスク、または
オブジェクトを透過的にロックするタスク、または
コレクション内に保持されているオブジェクトのリフレクションサービスを実行するタスクのうちの１つまたは複数を実行するように構成されていることを特徴とする請求項１４に記載の１つまたは複数のコンピュータ可読媒体。
さらに、オブジェクトの１つまたは複数のコレクションを含み、個々のコレクションはオブジェクトの同質な集合を保持することを特徴とする請求項１４に記載の１つまたは複数のコンピュータ可読媒体。
さらに、オブジェクトの１つまたは複数のコレクションを含み、個々のコレクションはオブジェクトの同質な集合を保持し、個々のコレクションは、ＤＬＬから取り出されたＣＯＭインターフェースとして実装されることを特徴とする請求項１４に記載の１つまたは複数のコンピュータ可読媒体。