Архитектура диспетчер устройств Windows Media
Windows Media диспетчер устройств позволяет приложению или подключаемого модуля взаимодействовать с устройством. Приложения могут запрашивать метаданные устройства, перечислять и изучать подключенные устройства, а также отправлять или получать объекты (папки, файлы, списки воспроизведения и т. д.). Windows Media диспетчер устройств предоставляет единый API для вызывающего приложения независимо от того, какой тип устройства вызывается (MTP или класс запоминающих устройств, поставщики услуг, созданные на основе версии 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, созданная на основе диспетчер устройств 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, который выполняется в собственном процессе. Из-за этого существует определенный риск того, что поставщик заблокированных служб приведет к блокировке вызывающего приложения. Таким образом, поставщики услуг должны быть надежными и предотвращать блокировку, а приложения должны быть разработаны таким образом, чтобы избежать остановки, если вызов определенного метода не возвращается быстро.
Связанные темы