Arquitectura de Windows Media Administrador de dispositivos

Windows Media Administrador de dispositivos permite que una aplicación o un complemento se comuniquen con un dispositivo. Las aplicaciones pueden solicitar metadatos de dispositivo, enumerar y explorar dispositivos conectados y enviar o recibir objetos (carpetas, archivos, listas de reproducción, etc.). Windows Media Administrador de dispositivos proporciona una única API a la aplicación que realiza la llamada, independientemente del tipo de dispositivo al que se llama (MTP o Clase de almacenamiento masivo, proveedores de servicios basados en la versión 10 o proveedores de servicios basados en versiones anteriores de Windows Media Administrador de dispositivos).

Windows Media Administrador de dispositivos actúa como un paso entre los tres componentes principales del sistema: la aplicación, que realiza solicitudes (para obtener información, leer o escribir datos, etc.); un proveedor de contenido seguro, que es un componente que controla la comunicación con archivos protegidos con DRM; y un proveedor de servicios, que recibe solicitudes de la aplicación y se comunica con el dispositivo para realizar estas solicitudes. Tanto la aplicación como el proveedor de servicios se basan en el SDK de Windows Media Administrador de dispositivos.

En el diagrama siguiente se muestra cómo se comunica una aplicación de escritorio con un dispositivo mediante Windows Media Administrador de dispositivos 11.

En el diagrama anterior se muestra una aplicación que se comunica con cuatro tipos diferentes de dispositivos, cada uno con su propio proveedor de servicios. Cada proveedor de servicios está diseñado para comunicarse con un tipo específico de dispositivo; En este diagrama se muestran los tres proveedores de servicios proporcionados por Microsoft (controladores de clase genéricos para dispositivos de clase de almacenamiento masivo, dispositivos RAPI y dispositivos MTP), así como un proveedor de servicios personalizado para un dispositivo propietario creado por un tercero. Cuando se conecta un dispositivo, Windows Media Administrador de dispositivos crea una instancia del proveedor de servicios registrado para ese dispositivo. Los proveedores de servicios obtienen solicitudes de la aplicación a través de interfaces de Windows Media Administrador de dispositivos que implementan, usan controladores adecuados para comunicarse con el dispositivo y devuelven los resultados adecuados. La comunicación entre el proveedor de servicios y el dispositivo está fuera del dominio de Windows Media Administrador de dispositivos.

Los proveedores de servicios son invisibles para la aplicación; una aplicación solo ve una lista de "dispositivos" porque Windows Media Administrador de dispositivos expone un conjunto estándar de métodos e interfaces para todos los dispositivos. Si un fabricante crea un proveedor de servicios personalizado, debe controlar todos los métodos estándar de Windows Media Administrador de dispositivos si las aplicaciones pueden usar el dispositivo.

En este diagrama también se muestra un módulo de proveedor de contenido seguro (SCP). Este módulo es responsable de controlar el contenido protegido por la administración de derechos digitales (DRM). Microsoft proporciona un módulo SCP que puede controlar archivos WMA y WMV protegidos con DRM. Si una aplicación o dispositivo pretende controlar otros formatos protegidos, debe proporcionar su propio módulo SCP. Ni la aplicación ni el proveedor de servicios tratan directamente con el SCP.

Tanto la aplicación como el proveedor de servicios se basan en Windows Media Administrador de dispositivos, que enruta las llamadas entre la aplicación y el proveedor de servicios adecuado para un dispositivo; el proveedor de servicios es responsable de comunicarse directamente con el dispositivo. Windows Media Administrador de dispositivos realiza algunas acciones (como enumerar dispositivos conectados, llamadas de enrutamiento y controlar la comprobación de componentes); sin embargo, la mayoría del trabajo lo realiza el proveedor de servicios, que recibe solicitudes de la aplicación y se comunica con el dispositivo.

Una aplicación basada en Windows Media Administrador de dispositivos puede comunicarse con dispositivos y proveedores de servicios basados en versiones anteriores de Windows Media Administrador de dispositivos; sin embargo, estos dispositivos anteriores se ejecutarán a través de componentes de la serie 9 (no se muestran) y no admitirán las características más recientes, especialmente la administración de derechos digitales más avanzada. Tecnología.

Arquitectura de un dispositivo

En el diagrama siguiente se muestra una jerarquía simplificada de dispositivos y almacenamientos, como se ve en una aplicación con Windows Media Administrador de dispositivos.

En el diagrama anterior se muestra una versión simplificada de una unidad flash conectada, como se ve en una aplicación de windows Media Administrador de dispositivos. La unidad flash tiene atributos y propiedades, como un número de serie y configuraciones de formato admitidas. Un elemento secundario inmediato del dispositivo flash es el objeto de almacenamiento raíz, que contiene una carpeta, que contiene una imagen y una canción.

Una aplicación enumera la lista de dispositivos adjuntos llamando a un método de enumeración expuesto por la interfaz IWMDeviceManager raíz. Los dispositivos se representan mediante una interfaz IWMDMDevice (o derivada). Esta interfaz expone métodos para recuperar el nombre del dispositivo, las funcionalidades de formato, el número de serie, etc., así como un método que enumera los almacenamientos del dispositivo. En Windows Media Administrador de dispositivos, un almacenamiento es cualquier tipo de objeto en el dispositivo, independientemente de si es o no un blob real de datos. Por ejemplo: archivos de audio, archivos de texto, carpetas, listas de reproducción almacenadas como archivos y listas de reproducción almacenadas como metadatos se consideran almacenamientos, aunque las carpetas y los elementos de metadatos probablemente no representen un archivo físico. El tipo (o formato) de un almacenamiento se puede recuperar llamando a GetAttributes (o GetMetadata, solicitando el formato del almacenamiento).

Los almacenamientos de un dispositivo se almacenan jerárquicamente y todos los dispositivos tienen un almacenamiento raíz. Cada almacenamiento puede contener cero o más objetos secundarios, enumerados mediante una llamada al método IWMDMStorage::EnumStorage del almacenamiento.

Tenga en cuenta que cada almacenamiento del diagrama tiene atributos y metadatos asociados (no se muestran todos los valores). Los atributos son información sencilla y booleana que suele describir información de administración o navegación (como "tiene carpetas" o "puede eliminar"), mientras que los metadatos pueden ser valores de cadena, números o información compleja (como funcionalidades de representación). Los atributos se describen mediante un conjunto bastante limitado de marcas definidas por el SDK y recuperadas mediante una llamada a IWMDMStorage::GetAttributes o IWMDMStorage2::GetAttributes2. Los valores de metadatos se recuperan mediante un nombre único; El SDK define una serie de valores de metadatos que los dispositivos deben admitir, pero los dispositivos pueden definir sus propias constantes de metadatos. Sin embargo, si un proveedor de dispositivos o servicios define una nueva constante de metadatos, las aplicaciones no podrán solicitar o establecer este valor a menos que los desarrolladores de aplicaciones conozcan esta nueva constante. Un proveedor de servicios debe admitir IWMDMStorage3 o posterior para admitir la recuperación o configuración de metadatos. Para obtener más información, vea Obtener y establecer metadatos y atributos.

Proveedores de servicios

El proveedor de servicios actúa como intermediario entre la aplicación y el dispositivo. El proveedor de servicios es invisible para el desarrollador de aplicaciones, por lo que un desarrollador de aplicaciones no necesita saber nada sobre el desarrollo de un proveedor de servicios. Sin embargo, es el proveedor de servicios que realiza el trabajo de comunicación con un dispositivo.

Un proveedor de servicios es un archivo DLL COM basado en Windows Media Administrador de dispositivos que recibe solicitudes de una aplicación y se comunica con el dispositivo para realizarlas. La comunicación con la aplicación de escritorio está mediada por Windows Media Administrador de dispositivos; la comunicación con el dispositivo está bajo el control del proveedor de servicios.

Un proveedor de servicios recibe solicitudes de la aplicación para enumerar el contenido del dispositivo, las solicitudes de funcionalidades del dispositivo, las solicitudes para leer o escribir datos, etc. Debe conocer el diseño de un dispositivo lo suficientemente bien como para que pueda enviar comandos en el formato y el protocolo adecuados. También debe ser capaz de ocultar requisitos específicos del dispositivo, como una extensión de archivo necesaria para listas de reproducción, de modo que las aplicaciones no necesiten conocer estos requisitos para poder usar el dispositivo.

Microsoft proporciona una serie de proveedores de servicios para los tipos de dispositivo estándar, incluidos los dispositivos MTP genéricos, los dispositivos de clase de almacenamiento masivo y los dispositivos RAPI. La única razón por la que un diseñador de dispositivos debe tener que crear un proveedor de servicios personalizado es si un dispositivo tiene algunos requisitos de almacenamiento de datos específicos o inusuales que los proveedores de servicios estándar no controlan, por ejemplo, si los archivos deben almacenarse en ubicaciones específicas y el sistema operativo del dispositivo no lo controla automáticamente.

Cuando un dispositivo está conectado al equipo, el sistema operativo crea una instancia del proveedor de servicios adecuado para cada aplicación de Windows Media Administrador de dispositivos. Si se inicia una segunda aplicación de Windows Media Administrador de dispositivos, se cargará una segunda instancia del proveedor de servicios. Sin embargo, cada proveedor de servicios puede controlar varios dispositivos. En el diagrama siguiente se ilustra esto.

En el diagrama anterior se muestran dos aplicaciones diferentes que se comunican con dos dispositivos MTP. Los dispositivos usan la misma clase de proveedor de servicios, pero cada aplicación tiene su propia instancia del mismo proveedor de servicios. Cada instancia del proveedor de servicios se comunica con dispositivos. Las distintas instancias del proveedor de servicios no son conscientes entre sí.

Muchos métodos de aplicación tienen un método de proveedor de servicios con nombre correspondiente. Cuando la aplicación llama a un método, Windows Media Administrador de dispositivos enruta la llamada al método correspondiente en el proveedor de servicios (aunque puede realizar algunas acciones internas adicionales primero). Por ejemplo, cuando la aplicación llama a IWMDMDevice3::GetProperty, Windows Media Administrador de dispositivos enruta esta llamada a la implementación del proveedor de servicios de IMDSPDevice3::GetProperty. (La mayoría de las interfaces de aplicación comienzan con IWMDM y la interfaz del proveedor de servicios correspondiente comienza con IMDSP). Se espera que el proveedor de servicios controle esta llamada al método y devuelva un resultado adecuado.

Una aplicación nunca explora o comunica directamente con un dispositivo (a menos que llame a IWMDMDevice3::D eviceIoControl o IWMDMStorage::SendOpaqueCommand); la aplicación se comunica con el proveedor de servicios, que debe representar un dispositivo de la manera más lógica y sencilla posible. Cuando la aplicación solicita información sobre el dispositivo o enumera los objetos del dispositivo, el proveedor de servicios consulta el dispositivo de forma adecuada y adquiere y devuelve la información adecuada. Puede exponer la organización de archivos en el dispositivo de forma diferente a la forma en que se almacena físicamente en el dispositivo, si es adecuado. Sin embargo, expone el dispositivo, debe ser coherente y lógico para permitir que la aplicación encuentre lo que necesita y controle los comandos que envía. Un buen proveedor de servicios ocultará las peculiaridades específicas del dispositivo; por ejemplo, si el dispositivo almacena físicamente una lista de reproducción como un archivo con una extensión de archivo personalizada, el proveedor de servicios debe agregar esa extensión automáticamente cuando la aplicación crea una lista de reproducción en el dispositivo; no debe esperar que la aplicación conozca la extensión adecuada al crear un objeto de lista de reproducción.

Los proveedores de servicios se ejecutan dentro del proceso de la aplicación que realiza la llamada. La única excepción a esto es el proveedor de servicios MTP, que se ejecuta en su propio proceso. Por este motivo, existe algún riesgo de que un proveedor de servicios bloqueado provoque que la aplicación que realiza la llamada se bloquee. Por lo tanto, los proveedores de servicios deben diseñarse para ser sólidos y evitar el bloqueo, y las aplicaciones deben diseñarse para evitar la detención si una llamada de método determinada no se devuelve rápidamente.

Temas relacionados

Introducción