Архитектура диспетчера устройств Windows Media

Диспетчер устройств Windows Media позволяет приложению или подключаемым модулям взаимодействовать с устройством. Приложения могут запрашивать метаданные устройства, перечислять и изучать подключенные устройства, а также отправлять или получать объекты (папки, файлы, списки воспроизведения и т. д.). Диспетчер устройств Windows Media предоставляет единый API для вызывающего приложения, независимо от типа вызываемого устройства (MTP или Mass Storage Class, поставщики услуг, созданные на основе версии 10 или поставщиков услуг, созданных на основе более ранних версий диспетчера устройств Windows Media).

Диспетчер устройств Windows Media выступает в качестве перехода между тремя основными компонентами системы: приложение, которое выполняет запросы (сведения, чтение или запись данных и т. д.); поставщик защищенного содержимого, который является компонентом, который обрабатывает обмен данными с файлами, защищенными DRM; и поставщик услуг, который получает запросы от приложения и взаимодействует с устройством для выполнения этих запросов. Приложение и поставщик услуг основаны на пакете SDK диспетчера устройств Windows Media.

На следующей схеме показано, как классическое приложение взаимодействует с устройством с помощью Диспетчера устройств Windows Media 11.

На предыдущей схеме показано приложение, взаимодействующее с четырьмя различными типами устройств, каждый из которых имеет собственный поставщик услуг. Каждый поставщик услуг предназначен для взаимодействия с определенным типом устройства; На этой схеме показаны три поставщика услуг, предоставляемые Корпорацией Майкрософт (универсальные драйверы классов для устройств класса хранилища масс, устройств RAPI и MTP), а также настраиваемый поставщик услуг для частного устройства, созданного сторонним поставщиком. При подключении устройства диспетчер устройств Windows Media создает экземпляр поставщика услуг, зарегистрированного для этого устройства. Поставщики услуг получают запросы от приложения через интерфейсы Диспетчера устройств Windows Media, которые они реализуют, используют соответствующие драйверы для взаимодействия с устройством и возвращают соответствующие результаты. Обмен данными между поставщиком услуг и устройством находится за пределами домена диспетчера устройств Windows Media.

Поставщики услуг невидимы для приложения; приложение видит только список "устройств", так как диспетчер устройств Windows Media предоставляет стандартный набор методов и интерфейсов для всех устройств. Если производитель создает пользовательского поставщика услуг, он должен обрабатывать все стандартные методы Диспетчера устройств Windows Media, если приложения смогут использовать устройство.

На этой схеме также показан модуль безопасного поставщика содержимого (SCP). Этот модуль отвечает за обработку защищенного содержимого управления цифровыми правами (DRM). Корпорация Майкрософт предоставляет модуль SCP, который может обрабатывать файлы WMA и WMV, защищенные DRM. Если приложение или устройство намерено обрабатывать другие защищенные форматы, он должен предоставить свой собственный модуль 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 или более поздней версии для получения или настройки метаданных. Дополнительные сведения см. в разделе Получение и настройка метаданных и атрибутов.

Поставщики услуг

Поставщик услуг выступает в качестве посредника между приложением и устройством. Поставщик услуг невидим для разработчика приложений, поэтому разработчику приложений не нужно ничего знать о разработке поставщика услуг. Однако это поставщик услуг, который работает над взаимодействием с устройством.

Поставщик услуг — это COM-библиотека DLL, созданная на основе диспетчера устройств Windows Media, который получает запросы от приложения и взаимодействует с устройством для их выполнения. Обмен данными с классическим приложением осуществляется с помощью диспетчера устройств Windows Media; Связь с устройством находится под контролем поставщика услуг.

Поставщик услуг получает запросы от приложения для перечисления содержимого устройства, запросов на возможности устройства, запросов на чтение или запись данных и т. д. Он должен знать дизайн устройства достаточно хорошо, чтобы он может отправлять команды в правильном формате и протоколе. Кроме того, он должен иметь возможность скрыть требования, относящиеся к устройству, такие как обязательное расширение файла для списков воспроизведения, чтобы приложения не должны знать эти требования для использования устройства.

Корпорация Майкрософт предоставляет ряд поставщиков услуг для стандартных типов устройств, включая универсальные устройства MTP, устройства класса хранилища масс и устройства RAPI. Единственная причина, по которой конструктор устройств должен создавать настраиваемый поставщик услуг, заключается в том, что устройство имеет определенные или необычные требования к хранилищу данных, которые стандартные поставщики услуг не обрабатывают, например, если файлы должны храниться в определенных расположениях, а операционная система устройства не обрабатывает это автоматически.

При подключении устройства к компьютеру операционная система создает один экземпляр соответствующего поставщика услуг для каждого приложения Диспетчера устройств Windows Media. Если запускается второе приложение Диспетчера устройств Windows Media, будет загружен второй экземпляр поставщика услуг. Однако каждый поставщик услуг может обрабатывать несколько устройств. На следующей схеме показана эта схема.

На предыдущей схеме показаны два разных приложения, взаимодействующих с двумя устройствами MTP. Устройства используют один и тот же класс поставщика услуг, но каждое приложение имеет собственный экземпляр одного поставщика услуг. Каждый экземпляр поставщика услуг взаимодействует с устройствами. Разные экземпляры поставщика услуг не знают друг друга.

Многие методы приложений имеют соответствующий метод поставщика услуг. Когда приложение вызывает метод, диспетчер устройств Windows Media направляет вызов соответствующему методу поставщика услуг (хотя он может выполнять некоторые дополнительные внутренние действия сначала). Например, когда приложение вызывает IWMDMDevice3::GetProperty, диспетчер устройств Windows Media направляет этот вызов к реализации поставщика услуг IMDSPDevice3::GetProperty. (Большинство интерфейсов приложений начинаются с IWMDM, а соответствующий интерфейс поставщика услуг начинается с IMDSP. Ожидается, что поставщик услуг обрабатывает этот вызов метода и возвращает соответствующий результат.

Приложение никогда не просматривает или не взаимодействует с устройством напрямую (если не вызывается IWMDMDevice3::D eviceIoControl или IWMDMStorage::SendOpaqueCommand); приложение взаимодействует с поставщиком услуг, который должен представлять устройство наиболее логическим и простым способом. Когда приложение запрашивает сведения об устройстве или перечисляет объекты на устройстве, поставщик услуг запрашивает устройство соответствующим образом и получает и возвращает соответствующую информацию. Он может предоставлять файловую организацию на устройстве по-разному от того, как он физически хранится на устройстве, если это уместно. Однако он предоставляет устройство, оно должно быть согласованным, логическим способом, чтобы приложение мог найти необходимые им команды и обрабатывать команды, которые он отправляет. Хороший поставщик услуг скрывает особенности конкретного устройства, например, если устройство физически хранит список воспроизведения в виде файла с пользовательским расширением, поставщик услуг должен автоматически добавить это расширение, когда приложение создает список воспроизведения на устройстве; Оно не должно ожидать, что приложение должно знать правильное расширение при создании объекта плейлиста.

Поставщики услуг выполняются внутри процесса вызывающего приложения. Единственным исключением является поставщик услуг MTP, который выполняется в собственном процессе. Из-за этого существует некоторый риск, что заблокированный поставщик услуг приведет к блокировке вызывающего приложения. Таким образом, поставщики услуг должны быть надежными и предотвращать блокировку, и приложения должны быть разработаны, чтобы избежать остановки, если конкретный вызов метода не возвращается быстро.

Связанные разделы

начало работы