Windows Media 设备管理器 体系结构
Windows Media 设备管理器使应用程序或插件能够与设备通信。 应用程序可以请求设备元数据、枚举和浏览附加设备，以及发送或接收) (文件夹、文件、播放列表等的对象。 Windows Media 设备管理器为调用应用程序提供单个 API，无论在 MTP 或大容量存储类 (调用哪种类型的设备、基于版本 10 构建的服务提供商或基于早期版本的 Windows Media 设备管理器) 构建的服务提供商。
Windows Media 设备管理器充当系统的三个主要组件的中间方：应用程序（ (信息请求、读取或写入数据等）) ;安全内容提供程序（处理与 DRM 保护的文件的通信的组件）;服务提供商（接收来自应用程序的请求并与设备通信以执行这些请求）。 应用程序和服务提供程序都是基于 Windows Media 设备管理器 SDK 构建的。
下图显示了桌面应用程序如何使用 Windows Media 设备管理器 11 与设备通信。
上图显示了一个应用程序与四种不同类型的设备通信，每个设备都有自己的服务提供商。 每个服务提供商都设计为与特定类型的设备通信;此图显示了 Microsoft 提供的三个服务提供商 (适用于大容量存储类设备、RAPI 设备和) MTP 设备的通用类驱动程序，以及第三方构建的专有设备的自定义服务提供商。 当设备连接时，Windows Media 设备管理器实例化为该设备注册的服务提供商的实例。 服务提供商通过它们实现的 Windows Media 设备管理器接口从应用程序获取请求，使用适当的驱动程序与设备通信，并返回适当的结果。 服务提供商和设备之间的通信位于 Windows Media 设备管理器 域之外。
服务提供商对应用程序不可见;应用程序只能看到“设备”列表，因为 Windows Media 设备管理器为所有设备公开一组标准的方法和接口。 如果制造商创建自定义服务提供商，则必须处理所有标准 Windows Media 设备管理器方法，应用程序才能使用该设备。
此图还显示了 SCP) 模块 (安全内容提供程序。 本模块负责处理数字版权管理 (DRM) 受保护的内容。 Microsoft 提供了一个 SCP 模块，该模块可以处理受 DRM 保护的 WMA 和 WMV 文件。 如果应用程序或设备打算处理其他受保护的格式，则必须提供自己的 SCP 模块。 应用程序和服务提供商都不直接处理 SCP。
应用程序和服务提供商都基于 Windows Media 设备管理器构建，后者在应用程序和设备的相应服务提供商之间路由调用;服务提供商负责直接与设备通信。 Windows Media 设备管理器本身确实 (执行某些操作，例如枚举连接的设备、路由呼叫和处理组件验证) ;但是，大部分工作由服务提供商完成，服务提供商接收来自应用程序的请求并与设备通信。
基于 Windows Media 设备管理器 构建的应用程序可以与基于早期版本的 Windows Media 设备管理器 构建的设备和服务提供商通信;但是，这些较旧的设备将通过 9 系列组件运行， (不会) 显示，并且不支持最新功能，尤其是更高级的数字版权管理技术。
设备的体系结构
下图显示了使用 Windows Media 设备管理器的应用程序看到的简化的设备和存储层次结构。
上图显示了连接的闪存驱动器的简化版本，如 Windows Media 设备管理器 应用程序所示。 闪存驱动器具有属性和属性，例如序列号和支持的格式配置。 闪存设备的直接子级是根存储对象，该对象包含一个文件夹，该文件夹本身包含一个图像和一首歌曲。
应用程序通过调用根 IWMDeviceManager 接口公开的枚举方法来枚举附加设备的列表。 设备由 IWMDMDevice (或派生的) 接口表示。 此接口公开用于检索设备名称、格式功能、序列号等的方法，以及枚举设备上的 存储 的方法。 在 Windows Media 设备管理器中，存储是设备上的任何类型的对象，无论它是否是实际的数据 Blob。 例如：音频文件、文本文件、文件夹、存储为文件的播放列表以及存储为元数据的播放列表都被视为存储，即使文件夹和元数据项可能不表示物理文件。 可以通过调用 GetAttributes (或 GetMetadata 来检索存储的类型 (或格式) ，并请求存储) 的格式。
设备上的存储是分层存储的，所有设备都有根存储。 每个存储可以保存零个或多个子对象，这些对象通过调用该存储的 IWMDMStorage：：EnumStorage 方法进行枚举。
请注意，关系图中的每个存储都具有与之关联的属性和元数据， (并非所有值都显示在) 。 属性是简单的布尔信息，通常描述管理或导航信息 (（如“具有文件夹”或“可以删除”) ），而元数据可以是字符串值、数字或复杂信息， (如呈现功能) 。 特性由 SDK 定义的一组相当有限的标志描述，并通过调用 IWMDMStorage：：GetAttributes 或 IWMDMStorage2：：GetAttributes2 检索。 元数据值由唯一名称检索;SDK 定义了设备应支持的多个元数据值，但设备可以定义自己的 元数据常量。 但是，如果设备或服务提供程序定义了新的元数据常量，应用程序将无法请求或设置此值，除非应用程序开发人员知道此新常量。 服务提供商必须支持 IWMDMStorage3 或更高版本才能支持检索或设置元数据。 有关详细信息，请参阅 获取和设置元数据和属性。
服务提供商
服务提供商充当应用程序和设备之间的中间人。 服务提供程序对应用程序开发人员不可见，因此应用程序开发人员无需了解有关开发服务提供商的任何信息。 但是，由服务提供商执行与设备通信的工作。
服务提供商是基于 Windows Media 设备管理器构建的 COM DLL，它接收来自应用程序的请求并与设备通信以执行请求。 与桌面应用程序的通信由 Windows Media 设备管理器 进行调解;与设备的通信由服务提供商控制。
服务提供商接收来自应用程序的请求以枚举设备内容、设备功能请求、读取或写入数据的请求等。 它必须充分了解设备的设计，才能以正确的格式和协议发送命令。 它还应该能够隐藏特定于设备的要求，例如播放列表所需的文件扩展名，以便应用程序无需知道这些要求即可使用设备。
Microsoft 为标准设备类型提供了许多服务提供商，包括通用 MTP 设备、大容量存储类设备和 RAPI 设备。 设备设计人员需要创建自定义服务提供程序的唯一原因是设备具有标准服务提供商无法处理的一些特定或异常数据存储要求，例如，如果文件必须存储在特定位置，而设备操作系统不自动处理此要求。
当设备连接到计算机时，操作系统会为每个 Windows Media 设备管理器应用程序创建相应服务提供程序的一个实例。 如果第二个 Windows Media 设备管理器 应用程序启动，则将加载服务提供程序的第二个实例。 但是，每个服务提供商可以处理多个设备。 下图说明了这一点。
上图显示了与两个 MTP 设备通信的两个不同的应用程序。 设备使用相同的服务提供程序类，但每个应用程序都有自己的同一服务提供程序实例。 每个服务提供程序实例都与设备通信。 服务提供程序的不同实例无法相互识别。
许多应用程序方法都有相应的命名服务提供程序方法。 当应用程序调用方法时，Windows Media 设备管理器将调用路由到服务提供程序 (上的相应方法，尽管它可能会首先) 执行一些其他内部操作。 例如，当应用程序调用 IWMDMDevice3：：GetProperty 时，Windows Media 设备管理器将此调用路由到服务提供商的 IMDSPDevice3：：GetProperty 实现。 (大多数应用程序接口以 IWMDM 开头，相应的服务提供程序接口以 IMDSP) 开头。 服务提供程序应处理此方法调用并返回适当的结果。
除非应用程序调用 IWMDMDevice3：:D eviceIoControl 或 IWMDMStorage：：SendOpaqueCommand) ，否则应用程序绝不会直接 (浏览设备或与设备通信;应用程序与服务提供商通信，服务提供商必须尽可能以最逻辑和最简单的方式表示设备。 当应用程序请求有关设备的信息或枚举设备上的对象时，服务提供商会以适当的方式查询设备，并获取并返回相应的信息。 如果合适，它可能会以不同于在设备上物理存储的方式公开设备上的文件组织。 但是，它公开了设备，它应该以一致、逻辑的方式使应用程序能够找到它所需的内容并处理它发送的命令。 良好的服务提供商会隐藏特定于设备的特性，例如，如果设备以物理方式将播放列表存储为具有自定义文件扩展名的文件，则当应用程序在设备上创建播放列表时，服务提供商应自动添加该扩展;创建播放列表对象时，应用程序不应知道正确的扩展。
服务提供程序在调用应用程序的进程中运行。 唯一的例外是 MTP 服务提供程序，它在其自己的进程中运行。 因此，存在一些风险，即被阻止的服务提供商会导致调用应用程序被阻止。 因此，服务提供程序应设计为可靠且防止阻塞，并且应用程序应设计为在特定的方法调用不快速返回时避免停止。
相关主题