Arquitetura de Gerenciador de Dispositivos do Windows Media
O Windows Media Gerenciador de Dispositivos permite que um aplicativo ou plug-in se comunique com um dispositivo. Os aplicativos podem solicitar metadados do dispositivo, enumerar e explorar dispositivos anexados e enviar ou receber objetos (pastas, arquivos, playlists e assim por diante). O Windows Media Gerenciador de Dispositivos fornece uma única API para o aplicativo de chamada, independentemente do tipo de dispositivo que está sendo chamado (classe mtp ou de armazenamento em massa, provedores de serviços criados na versão 10 ou provedores de serviços criados em versões anteriores do Windows Media Gerenciador de Dispositivos).
O Windows Media Gerenciador de Dispositivos atua como um intermediário para os três principais componentes do sistema: o aplicativo, que faz solicitações (para informações, para ler ou gravar dados e assim por diante); um provedor de conteúdo seguro, que é um componente que lida com a comunicação com arquivos protegidos por DRM; e um provedor de serviços, que recebe solicitações do aplicativo e se comunica com o dispositivo para executar essas solicitações. O aplicativo e o provedor de serviços são criados no SDK do Windows Media Gerenciador de Dispositivos.
O diagrama a seguir mostra como um aplicativo da área de trabalho se comunica com um dispositivo usando o Windows Media Gerenciador de Dispositivos 11.
O diagrama anterior mostra um aplicativo se comunicando com quatro tipos diferentes de dispositivos, cada um com seu próprio provedor de serviços. Cada provedor de serviços foi projetado para se comunicar com um tipo específico de dispositivo; este diagrama mostra os três provedores de serviços fornecidos pela Microsoft (drivers de classe genérica para dispositivos de Classe de Armazenamento em Massa, dispositivos RAPI e dispositivos MTP), bem como um provedor de serviços personalizado para um dispositivo proprietário criado por terceiros. Quando um dispositivo se conecta, o Windows Media Gerenciador de Dispositivos instancia uma instância do provedor de serviços registrada para esse dispositivo. Os provedores de serviços recebem solicitações do aplicativo por meio de interfaces de Gerenciador de Dispositivos do Windows Media implementadas, usam drivers apropriados para se comunicar com o dispositivo e retornam os resultados apropriados. A comunicação entre o provedor de serviços e o dispositivo está fora do domínio do Windows Media Gerenciador de Dispositivos.
Os provedores de serviços são invisíveis para o aplicativo; um aplicativo vê apenas uma lista de "dispositivos" porque o Windows Media Gerenciador de Dispositivos expõe um conjunto padrão de métodos e interfaces para todos os dispositivos. Se um fabricante criar um provedor de serviços personalizado, ele deverá lidar com todos os métodos padrão do Windows Media Gerenciador de Dispositivos se os aplicativos puderem usar o dispositivo.
Este diagrama também mostra um módulo scp (provedor de conteúdo seguro). Este módulo é responsável por lidar com conteúdo protegido por DRM (gerenciamento de direitos digitais). A Microsoft fornece um módulo SCP que pode lidar com arquivos WMA e WMV protegidos por DRM. Se um aplicativo ou dispositivo pretende lidar com outros formatos protegidos, ele deve fornecer seu próprio módulo SCP. Nem o aplicativo nem o provedor de serviços lidam diretamente com o SCP.
O aplicativo e o provedor de serviços são criados no Windows Media Gerenciador de Dispositivos, que roteia chamadas entre o aplicativo e o provedor de serviços apropriado para um dispositivo; o provedor de serviços é responsável por se comunicar diretamente com o dispositivo. O Windows Media Gerenciador de Dispositivos executa algumas ações em si (como enumerar dispositivos conectados, rotear chamadas e lidar com a verificação de componentes); no entanto, a maior parte do trabalho é feita pelo provedor de serviços, que recebe solicitações do aplicativo e se comunica com o dispositivo.
Um aplicativo criado no Windows Media Gerenciador de Dispositivos pode se comunicar com dispositivos e provedores de serviços criados em versões anteriores do Windows Media Gerenciador de Dispositivos; no entanto, esses dispositivos mais antigos serão executados por meio de componentes da Série 9 (não mostrados) e não darão suporte aos recursos mais recentes, especialmente a tecnologia mais avançada de gerenciamento de direitos digitais.
Arquitetura de um dispositivo
O diagrama a seguir mostra uma hierarquia simplificada de dispositivos e armazenamentos, conforme visto por um aplicativo usando o Windows Media Gerenciador de Dispositivos.
O diagrama anterior mostra uma versão simplificada de uma unidade flash conectada, conforme visto por um aplicativo do Windows Media Gerenciador de Dispositivos. A unidade flash tem atributos e propriedades, como um número de série e configurações de formato com suporte. Um filho imediato do dispositivo flash é o objeto de armazenamento raiz, que contém uma pasta, que contém uma imagem e uma música.
Um aplicativo enumera a lista de dispositivos anexados chamando um método de enumeração exposto pela interface IWMDeviceManager raiz. Os dispositivos são representados por uma interface IWMDMDevice (ou derivada). Essa interface expõe métodos para recuperar o nome do dispositivo, os recursos de formato, o número de série e assim por diante, bem como um método que enumera armazenamentos no dispositivo. No Windows Media Gerenciador de Dispositivos, um armazenamento é qualquer tipo de objeto no dispositivo, seja ou não um blob real de dados. Por exemplo: arquivos de áudio, arquivos de texto, pastas, playlists armazenadas como arquivos e playlists armazenadas como metadados são considerados armazenamentos, embora pastas e itens de metadados provavelmente não representem um arquivo físico. O tipo (ou formato) de um armazenamento pode ser recuperado chamando GetAttributes (ou GetMetadata, solicitando o formato do armazenamento).
Os armazenamentos em um dispositivo são armazenados hierarquicamente e todos os dispositivos têm um armazenamento raiz. Cada armazenamento pode conter zero ou mais objetos filho, enumerados chamando o método IWMDMStorage::EnumStorage desse armazenamento.
Observe que cada armazenamento no diagrama tem atributos e metadados associados a ele (nem todos os valores são mostrados). Atributos são informações simples e boolianas geralmente descrevendo informações de gerenciamento ou de navegação (como "tem pastas" ou "pode excluir"), enquanto os metadados podem ser valores de cadeia de caracteres, números ou informações complexas (como recursos de renderização). Os atributos são descritos por um conjunto bastante limitado de sinalizadores definidos pelo SDK e recuperados chamando IWMDMStorage::GetAttributes ou IWMDMStorage2::GetAttributes2. Os valores de metadados são recuperados por um nome exclusivo; O SDK define vários valores de metadados aos quais os dispositivos devem dar suporte, mas os dispositivos podem definir suas próprias constantes de metadados. No entanto, se um dispositivo ou provedor de serviços definir uma nova constante de metadados, os aplicativos não poderão solicitar ou definir esse valor, a menos que os desenvolvedores de aplicativos estejam cientes dessa nova constante. Um provedor de serviços deve dar suporte a IWMDMStorage3 ou posterior para dar suporte à recuperação ou à configuração de metadados. Para obter mais informações, consulte Obtendo e definindo metadados e atributos.
Provedores de serviço
O provedor de serviços atua como um intermediário entre o aplicativo e o dispositivo. O provedor de serviços é invisível para o desenvolvedor de aplicativos, portanto, um desenvolvedor de aplicativos não precisa saber nada sobre o desenvolvimento de um provedor de serviços. No entanto, é o provedor de serviços que faz o trabalho de comunicação com um dispositivo.
Um provedor de serviços é uma DLL COM criada no Windows Media Gerenciador de Dispositivos que recebe solicitações de um aplicativo e se comunica com o dispositivo para executá-las. A comunicação com o aplicativo da área de trabalho é mediada pelo Windows Media Gerenciador de Dispositivos; a comunicação com o dispositivo está sob o controle do provedor de serviços.
Um provedor de serviços recebe solicitações do aplicativo para enumerar o conteúdo do dispositivo, solicitações de recursos do dispositivo, solicitações para ler ou gravar dados e assim por diante. Ele deve saber o design de um dispositivo bem o suficiente para que ele possa enviar comandos no formato e no protocolo adequados. Ele também deve ser capaz de ocultar requisitos específicos do dispositivo, como uma extensão de arquivo necessária para playlists, para que os aplicativos não precisem conhecer esses requisitos para usar o dispositivo.
A Microsoft fornece vários provedores de serviços para tipos de dispositivo padrão, incluindo dispositivos MTP genéricos, dispositivos de Classe de Armazenamento em Massa e dispositivos RAPI. O único motivo pelo qual um designer de dispositivo deve precisar criar um provedor de serviços personalizado é se um dispositivo tiver alguns requisitos específicos ou incomuns de armazenamento de dados que os provedores de serviços padrão não manipulam, por exemplo, se os arquivos precisarem ser armazenados em locais específicos e o sistema operacional do dispositivo não lidar com isso automaticamente.
Quando um dispositivo está conectado ao computador, o sistema operacional cria uma instância do provedor de serviços apropriado para cada aplicativo do Windows Media Gerenciador de Dispositivos. Se um segundo aplicativo Gerenciador de Dispositivos do Windows Media for iniciado, uma segunda instância do provedor de serviços será carregada. No entanto, cada provedor de serviços pode lidar com vários dispositivos. O diagrama a seguir ilustra isso.
O diagrama anterior mostra dois aplicativos diferentes se comunicando com dois dispositivos MTP. Os dispositivos usam a mesma classe de provedor de serviços, mas cada aplicativo tem sua própria instância do mesmo provedor de serviços. Cada instância do provedor de serviços está se comunicando com dispositivos. As diferentes instâncias do provedor de serviços não estão cientes umas das outras.
Muitos métodos de aplicativo têm um método de provedor de serviços nomeado correspondentemente. Quando o aplicativo chama um método, o Windows Media Gerenciador de Dispositivos roteia a chamada para o método correspondente no provedor de serviços (embora ele possa executar algumas ações internas adicionais primeiro). Por exemplo, quando o aplicativo chama IWMDMDevice3::GetProperty, o Windows Media Gerenciador de Dispositivos roteia essa chamada para a implementação do provedor de serviços de IMDSPDevice3::GetProperty. (A maioria das interfaces de aplicativo começa com IWMDM e a interface do provedor de serviços correspondente começa com IMDSP). Espera-se que o provedor de serviços lide com essa chamada de método e retorne um resultado apropriado.
Um aplicativo nunca explora ou se comunica diretamente com um dispositivo (a menos que chame IWMDMDevice3::D eviceIoControl ou IWMDMStorage::SendOpaqueCommand); o aplicativo se comunica com o provedor de serviços, que deve representar um dispositivo da maneira mais lógica e simples possível. Quando o aplicativo solicita informações sobre o dispositivo ou enumera objetos no dispositivo, o provedor de serviços consulta o dispositivo de maneira apropriada e adquire e retorna as informações apropriadas. Ele pode expor a organização de arquivos no dispositivo de forma diferente de como ela é armazenada fisicamente no dispositivo, se for apropriado. No entanto, ele expõe o dispositivo, ele deve ser de maneira consistente e lógica, para permitir que o aplicativo encontre o que ele precisa e manipule os comandos que ele envia. Um bom provedor de serviço ocultará peculiaridades específicas do dispositivo, por exemplo, se o dispositivo armazenar fisicamente uma playlist como um arquivo com uma extensão de arquivo personalizada, o provedor de serviços deverá adicionar essa extensão automaticamente quando o aplicativo criar uma playlist no dispositivo; ele não deve esperar que o aplicativo saiba a extensão adequada ao criar um objeto de playlist.
Os provedores de serviço são executados dentro do processo do aplicativo de chamada. A única exceção a isso é o provedor de serviços MTP, que é executado em seu próprio processo. Por isso, há algum risco de que um provedor de serviços bloqueado faça com que o aplicativo de chamada seja bloqueado. Portanto, os provedores de serviços devem ser projetados para serem robustos e impedir o bloqueio, e os aplicativos devem ser projetados para evitar paralisação se uma chamada de método específica não retornar rapidamente.
Tópicos relacionados