Windows Media デバイス マネージャー アーキテクチャ

Windows Media デバイス マネージャーを使用すると、アプリケーションまたはプラグインがデバイスと通信できるようになります。 アプリケーションでは、デバイス メタデータの要求、接続されているデバイスの列挙と探索、オブジェクト (フォルダー、ファイル、プレイリストなど) の送受信を行うことができます。 Windows Media デバイス マネージャーは、呼び出されるデバイスの種類 (MTP または大容量ストレージ クラス、バージョン 10 上に構築されたサービス プロバイダー、または以前のバージョンの Windows Media デバイス マネージャー上に構築されたサービス プロバイダー) に関係なく、呼び出し元アプリケーションに 1 つの API を提供します。

Windows Media デバイス マネージャーは、システムの 3 つの主要コンポーネント (情報、データの読み取りまたは書き込みなど) を行うアプリケーション、DRM で保護されたファイルとの通信を処理するコンポーネントであるセキュリティで保護されたコンテンツ プロバイダー、およびアプリケーションから要求を受信し、これらの要求を実行するためにデバイスと通信するサービス プロバイダーの間で機能します。 アプリケーションとサービス プロバイダーの両方が Windows Media デバイス マネージャー SDK 上に構築されています。

次の図は、Windows Media デバイス マネージャー 11 を使用してデスクトップ アプリケーションがデバイスと通信する方法を示しています。

上の図は、それぞれ独自のサービス プロバイダーを持つ 4 種類のデバイスと通信するアプリケーションを示しています。 すべてのサービス プロバイダーは、特定の種類のデバイスと通信するように設計されています。この図は、Microsoft が提供する 3 つのサービス プロバイダー (Mass Storage Class デバイス、RAPI デバイス、MTP デバイス用の汎用クラス ドライバー) と、サード パーティによって構築された独自のデバイス用のカスタム サービス プロバイダーを示しています。 デバイスが接続すると、Windows Media デバイス マネージャーは、そのデバイスに登録されているサービス プロバイダーのインスタンスをインスタンス化します。 サービス プロバイダーは、実装する Windows Media デバイス マネージャー インターフェイスを介してアプリケーションから要求を取得し、適切なドライバーを使用してデバイスと通信し、適切な結果を返します。 サービス プロバイダーとデバイス間の通信は、Windows Media デバイス マネージャーのドメイン外です。

サービス プロバイダーはアプリケーションに対して見えません。Windows Media デバイス マネージャーではすべてのデバイスの標準的なメソッドとインターフェイスのセットが公開されるため、アプリケーションでは "デバイス" の一覧のみが表示されます。 製造元がカスタム サービス プロバイダーを作成する場合、アプリケーションでデバイスを使用できる場合は、すべての標準的な Windows Media デバイス マネージャー メソッドを処理する必要があります。

この図では、セキュリティで保護されたコンテンツ プロバイダー (SCP) モジュールも示しています。 このモジュールは、デジタル著作権管理 (DRM) で保護されたコンテンツを処理する役割を担います。 Microsoft は、DRM で保護された WMA ファイルと WMV ファイルを処理できる SCP モジュールを提供しています。 アプリケーションまたはデバイスが他の保護された形式を処理する場合は、独自の SCP モジュールを提供する必要があります。 アプリケーションもサービス プロバイダーも SCP を直接処理しません。

アプリケーションとサービス プロバイダーの両方が Windows Media デバイス マネージャー上に構築されており、アプリケーションとデバイスの適切なサービス プロバイダーの間で呼び出しをルーティングします。サービス プロバイダーは、デバイスと直接通信する役割を担います。 Windows Media デバイス マネージャーでは、接続されているデバイスの列挙、呼び出しのルーティング、コンポーネントの検証の処理など、一部のアクション自体が実行されますが、ほとんどの作業はサービス プロバイダーによって実行され、アプリケーションから要求を受信してデバイスと通信します。

Windows Media デバイス マネージャー 上に構築されたアプリケーションは、以前のバージョンの Windows Media デバイス マネージャー上に構築されたデバイスやサービス プロバイダーと通信できます。ただし、これらの古いデバイスは 9 シリーズ コンポーネント (図示せず) を介して実行され、最新の機能 、特に高度なデジタル著作権管理テクノロジはサポートされません。

デバイスのアーキテクチャ

次の図は、Windows Media デバイス マネージャーを使用するアプリケーションで見られるように、デバイスとストレージの簡略化された階層を示しています。

上の図は、Windows Media デバイス マネージャー アプリケーションで見られるように、接続されているフラッシュ ドライブの簡略化されたバージョンを示しています。 フラッシュ ドライブには、シリアル番号やサポートされている形式構成などの属性とプロパティがあります。 フラッシュ デバイスの直接の子は、ルート ストレージ オブジェクトです。このオブジェクトには、それ自体に画像と曲が含まれるフォルダーが含まれています。

アプリケーションは、ルート IWMDeviceManager インターフェイスによって公開される列挙メソッドを呼び出すことによって、接続されているデバイスの一覧を列挙します。 デバイスは、 IWMDMDevice (または派生) インターフェイスによって表されます。 このインターフェイスは、デバイス名、書式設定機能、シリアル番号などを取得するメソッドと、デバイス上の ストレージ を列挙するメソッドを公開します。 Windows Media デバイス マネージャーでは、ストレージは、データの実際の BLOB であるかどうかに関係なく、デバイス上の任意の種類のオブジェクトです。 たとえば、オーディオ ファイル、テキスト ファイル、フォルダー、ファイルとして格納されているプレイリスト、およびメタデータとして格納されているプレイリストはすべて、フォルダーとメタデータ項目が物理ファイルを表していない可能性がありますが、すべてストレージと見なされます。 ストレージの型 (または形式) は、 GetAttributes (または GetMetadata、ストレージの形式を要求) を呼び出すことによって取得できます。

デバイス上のストレージは階層的に格納され、すべてのデバイスにはルート ストレージがあります。 各ストレージは、そのストレージの IWMDMStorage::EnumStorage メソッドを呼び出すことによって列挙された 0 個以上の子オブジェクトを保持できます。

ダイアグラム内の各ストレージには、属性とメタデータが関連付けられていることに注意してください (すべての値が表示されるわけではありません)。 属性は、多くの場合、管理情報やナビゲーション情報 ("has folders" や "can delete" など) を記述する単純なブール値です。一方、メタデータには文字列値、数値、または複雑な情報 (レンダリング機能など) を指定できます。 属性は、SDK によって定義され、 IWMDMStorage::GetAttributes または IWMDMStorage2::GetAttributes2 を呼び出すことによって取得される、かなり制限されたフラグセットによって記述されます。 メタデータ値は一意の名前で取得されます。SDK では、デバイスでサポートする必要がある多数のメタデータ値が定義されていますが、デバイスは独自の メタデータ定数を定義できます。 ただし、デバイスまたはサービス プロバイダーが新しいメタデータ定数を定義している場合、アプリケーション開発者がこの新しい定数を認識していない限り、アプリケーションはこの値を要求または設定できません。 サービス プロバイダーは、メタデータの取得または設定をサポートするために 、IWMDMStorage3 以降をサポートする必要があります。 詳細については、「 メタデータと属性の取得と設定」を参照してください。

サービス プロバイダー

サービス プロバイダーは、アプリケーションとデバイスの間の仲介者として機能します。 サービス プロバイダーはアプリケーション開発者には見えないので、アプリケーション開発者はサービス プロバイダーの開発について何も知る必要はありません。 ただし、デバイスと通信する作業を行うのはサービス プロバイダーです。

サービス プロバイダーは、アプリケーションから要求を受信し、それらを実行するためにデバイスと通信する Windows Media デバイス マネージャー上に構築された COM DLL です。 デスクトップ アプリケーションとの通信は、Windows Media デバイス マネージャーによって仲介されます。デバイスとの通信は、サービス プロバイダーの制御下にあります。

サービス プロバイダーは、アプリケーションからデバイスコンテンツを列挙するための要求、デバイス機能の要求、データの読み取りまたは書き込みの要求などを受け取ります。 適切な形式とプロトコルでコマンドを送信できる十分なデバイスの設計を知っている必要があります。 また、デバイスを使用するためにアプリケーションがこれらの要件を知る必要がないように、プレイリストに必要なファイル拡張子など、デバイス固有の要件を非表示にすることもできます。

Microsoft では、汎用 MTP デバイス、大容量記憶装置クラス デバイス、RAPI デバイスなど、標準デバイスの種類に対して多数のサービス プロバイダーを提供しています。 デバイス デザイナーがカスタム サービス プロバイダーを作成する必要がある唯一の理由は、デバイスに標準サービス プロバイダーが処理しない特定のデータ ストレージ要件や通常とは異なるデータ ストレージ要件がある場合です。たとえば、ファイルを特定の場所に格納する必要があり、デバイス オペレーティング システムで自動的に処理されない場合です。

デバイスがコンピューターに接続されると、オペレーティング システムによって、Windows Media デバイス マネージャー アプリケーションごとに適切なサービス プロバイダーのインスタンスが 1 つ作成されます。 2 つ目の Windows Media デバイス マネージャー アプリケーションが起動すると、サービス プロバイダーの 2 番目のインスタンスが読み込まれます。 ただし、各サービス プロバイダーは複数のデバイスを処理できます。 これを次の図に示します。

上の図は、2 つの MTP デバイスと通信する 2 つの異なるアプリケーションを示しています。 デバイスは同じサービス プロバイダー クラスを使用しますが、各アプリケーションには同じサービス プロバイダーの独自のインスタンスがあります。 各サービス プロバイダー インスタンスがデバイスと通信しています。 サービス プロバイダーの異なるインスタンスは、相互に認識されません。

多くのアプリケーション メソッドには、対応する名前付きサービス プロバイダー メソッドがあります。 アプリケーションがメソッドを呼び出すと、Windows Media デバイス マネージャーはサービス プロバイダーの対応するメソッドに呼び出しをルーティングします (ただし、最初に追加の内部アクションを実行する可能性があります)。 たとえば、アプリケーションが IWMDMDevice3::GetProperty を呼び出すと、Windows Media デバイス マネージャーはこの呼び出しをサービス プロバイダーの IMDSPDevice3::GetProperty の実装にルーティングします。 (ほとんどのアプリケーション インターフェイスは IWMDM で始まり、対応するサービス プロバイダー インターフェイスは IMDSP で始まります)。 サービス プロバイダーは、このメソッド呼び出しを処理し、適切な結果を返す必要があります。

アプリケーションがデバイスを直接探索または通信することはありません ( IWMDMDevice3::D eviceIoControl または IWMDMStorage::SendOpaqueCommand を呼び出す場合を除く)。アプリケーションはサービス プロバイダーと通信します。これは、可能な限り論理的でシンプルな方法でデバイスを表す必要があります。 アプリケーションがデバイスに関する情報を要求するか、デバイス上のオブジェクトを列挙すると、サービス プロバイダーは適切な方法でデバイスに対してクエリを実行し、適切な情報を取得して返します。 デバイス上のファイル organizationを、デバイスに物理的に格納する方法とは異なる方法で公開する場合があります (適切な場合)。 ただし、デバイスを公開する場合は、アプリケーションが必要なものを見つけて送信するコマンドを処理できるように、一貫性のある論理的な方法にする必要があります。 優れたサービス プロバイダーは、デバイス固有の特性を非表示にします。たとえば、デバイスがカスタム ファイル拡張子を持つファイルとしてプレイリストを物理的に格納する場合、アプリケーションがデバイスにプレイリストを作成するときに、サービス プロバイダーはその拡張機能を自動的に追加する必要があります。プレイリストオブジェクトを作成するときに、アプリケーションが適切な拡張機能を知っている必要はありません。

サービス プロバイダーは、呼び出し元アプリケーションのプロセス内で実行されます。 これに対する唯一の例外は、独自のプロセスで実行される MTP サービス プロバイダーです。 このため、ブロックされたサービス プロバイダーによって呼び出し元アプリケーションがブロックされるリスクがあります。 そのため、サービス プロバイダーは堅牢でブロックを防止するように設計する必要があります。また、特定のメソッド呼び出しがすぐに戻らない場合は、アプリケーションが停止しないように設計する必要があります。

関連トピック

はじめに