Architettura di Windows Media Gestione dispositivi

Windows Media Gestione dispositivi consente a un'applicazione o a un plug-in di comunicare con un dispositivo. Le applicazioni possono richiedere metadati del dispositivo, enumerare ed esplorare i dispositivi collegati e inviare o ricevere oggetti (cartelle, file, playlist e così via). Windows Media Gestione dispositivi fornisce una singola API all'applicazione chiamante, indipendentemente dal tipo di dispositivo chiamato (MTP o Classe di archiviazione di massa, provider di servizi basati sulla versione 10 o sui provider di servizi basati sulle versioni precedenti di Windows Media Gestione dispositivi).

Windows Media Gestione dispositivi funge da go-between per i tre componenti principali del sistema: l'applicazione, che effettua richieste (per informazioni, per leggere o scrivere dati e così via); un provider di contenuto sicuro, che gestisce la comunicazione con file protetti da DRM e un provider di servizi, che riceve le richieste dall'applicazione e comunica con il dispositivo per eseguire queste richieste. Sia l'applicazione che il provider di servizi sono basati su Windows Media Gestione dispositivi SDK.

Il diagramma seguente illustra come un'applicazione desktop comunica con un dispositivo usando Windows Media Gestione dispositivi 11.

Il diagramma precedente mostra un'applicazione che comunica con quattro diversi tipi di dispositivi, ognuno con il proprio provider di servizi. Ogni provider di servizi è progettato per comunicare con un tipo specifico di dispositivo; questo diagramma illustra i tre provider di servizi forniti da Microsoft (driver di classe generici per dispositivi di classe di archiviazione di massa, dispositivi RAPI e dispositivi MTP), nonché un provider di servizi personalizzato per un dispositivo proprietario compilato da terze parti. Quando un dispositivo si connette, Windows Media Gestione dispositivi crea un'istanza del provider di servizi registrata per tale dispositivo. I provider di servizi ricevono richieste dall'applicazione tramite le interfacce di Windows Media Gestione dispositivi implementate, usano driver appropriati per comunicare con il dispositivo e restituire risultati appropriati. La comunicazione tra il provider di servizi e il dispositivo non rientra nel dominio di Windows Media Gestione dispositivi.

I provider di servizi sono invisibili all'applicazione; un'applicazione visualizza solo un elenco di "dispositivi" perché Windows Media Gestione dispositivi espone un set standard di metodi e interfacce per tutti i dispositivi. Se un produttore crea un provider di servizi personalizzato, deve gestire tutti i metodi standard di Windows Media Gestione dispositivi se le applicazioni devono essere in grado di usare il dispositivo.

Questo diagramma mostra anche un modulo SCP (Secure Content Provider). Questo modulo è responsabile della gestione dei diritti digitali (DRM) protetta. Microsoft fornisce un modulo SCP che può gestire i file WMA e WMV protetti da DRM. Se un'applicazione o un dispositivo intende gestire altri formati protetti, deve fornire il proprio modulo SCP. Né l'applicazione né il provider di servizi si occupa direttamente del servizio SCP.

Sia l'applicazione che il provider di servizi sono basati su Windows Media Gestione dispositivi, che instrada le chiamate tra l'applicazione e il provider di servizi appropriato per un dispositivo. Il provider di servizi è responsabile della comunicazione diretta con il dispositivo. Windows Media Gestione dispositivi esegue alcune azioni , ad esempio l'enumerazione dei dispositivi connessi, le chiamate di routing e la gestione della verifica dei componenti. Tuttavia, la maggior parte del lavoro viene eseguita dal provider di servizi, che riceve le richieste dall'applicazione e comunica con il dispositivo.

Un'applicazione basata su Windows Media Gestione dispositivi può comunicare con dispositivi e provider di servizi basati sulle versioni precedenti di Windows Media Gestione dispositivi. Tuttavia, questi dispositivi meno recenti verranno eseguiti tramite componenti di serie 9 (non visualizzati) e non supporteranno le funzionalità più recenti, in particolare la tecnologia di gestione dei diritti digitali più avanzata.

Architettura di un dispositivo

Il diagramma seguente illustra una gerarchia semplificata di dispositivi e archiviazioni, come illustrato da un'applicazione che usa Windows Media Gestione dispositivi.

Il diagramma precedente mostra una versione semplificata di un'unità flash connessa, come illustrato da un'applicazione windows Media Gestione dispositivi. L'unità flash include attributi e proprietà, ad esempio un numero di serie e configurazioni di formato supportate. Un figlio immediato del dispositivo flash è l'oggetto di archiviazione radice, che contiene una cartella, che contiene un'immagine e una canzone.

Un'applicazione enumera l'elenco di dispositivi collegati chiamando un metodo di enumerazione esposto dall'interfaccia IWMDeviceManager radice. I dispositivi sono rappresentati da un'interfaccia IWMDMDevice (o derivata). Questa interfaccia espone i metodi per recuperare il nome del dispositivo, le funzionalità di formato, il numero di serie e così via, nonché un metodo che enumera le risorse di archiviazione nel dispositivo. In Windows Media Gestione dispositivi, un archivio è qualsiasi tipo di oggetto nel dispositivo, indipendentemente dal fatto che sia un BLOB effettivo di dati. Ad esempio: file audio, file di testo, cartelle, playlist archiviate come file e playlist archiviate come metadati sono tutti considerati archivi, anche se le cartelle e gli elementi di metadati probabilmente non rappresentano un file fisico. Il tipo (o il formato) di un archivio può essere recuperato chiamando GetAttributes (o GetMetadata, richiedendo il formato dell'archiviazione).

Le archiviazioni in un dispositivo vengono archiviate gerarchicamente e tutti i dispositivi dispongono di una risorsa di archiviazione radice. Ogni archiviazione può contenere zero o più oggetti figlio, enumerati chiamando il metodo IWMDMStorage::EnumStorage .

Si noti che ogni archiviazione nel diagramma contiene attributi e metadati associati a esso (non tutti i valori vengono visualizzati). Gli attributi sono informazioni semplici, booleane spesso che descrivono le informazioni di gestione o navigazione (ad esempio "ha cartelle" o "può eliminare"), mentre i metadati possono essere valori stringa, numeri o informazioni complesse (ad esempio funzionalità di rendering). Gli attributi sono descritti da un set abbastanza limitato di flag definiti dall'SDK e recuperati chiamando IWMDMStorage::GetAttributes o IWMDMStorage2::GetAttributes2. I valori dei metadati vengono recuperati da un nome univoco; l'SDK definisce un numero di valori di metadati che i dispositivi devono supportare, ma i dispositivi possono definire costanti di metadati personalizzate. Tuttavia, se un dispositivo o un provider di servizi definisce una nuova costante dei metadati, le applicazioni non potranno richiedere o impostare questo valore a meno che gli sviluppatori dell'applicazione non siano consapevoli di questa nuova costante. Un provider di servizi deve supportare IWMDMStorage3 o versioni successive per supportare il recupero o l'impostazione dei metadati. Per altre informazioni, vedere Recupero e impostazione di metadati e attributi.

Provider di servizi

Il provider di servizi funge da middleman tra l'applicazione e il dispositivo. Il provider di servizi è invisibile allo sviluppatore di applicazioni, quindi uno sviluppatore di applicazioni non deve conoscere nulla sullo sviluppo di un provider di servizi. Tuttavia, è il provider di servizi che esegue il lavoro di comunicazione con un dispositivo.

Un provider di servizi è una DLL COM basata su Windows Media Gestione dispositivi che riceve le richieste da un'applicazione e comunica con il dispositivo per eseguirle. La comunicazione con l'applicazione desktop è mediata da Windows Media Gestione dispositivi; la comunicazione con il dispositivo è sotto il controllo del provider di servizi.

Un provider di servizi riceve le richieste dall'applicazione per enumerare il contenuto del dispositivo, le richieste per le funzionalità del dispositivo, le richieste di lettura o scrittura di dati e così via. Deve conoscere la progettazione di un dispositivo abbastanza bene che possa inviare comandi nel formato e nel protocollo appropriati. Deve anche essere in grado di nascondere i requisiti specifici del dispositivo, ad esempio un'estensione di file necessaria per le playlist, in modo che le applicazioni non debbano conoscere questi requisiti per usare il dispositivo.

Microsoft offre numerosi provider di servizi per i tipi di dispositivi standard, tra cui dispositivi MTP generici, dispositivi di classe di archiviazione di massa e dispositivi RAPI. L'unico motivo per cui una finestra di progettazione dispositivi deve creare un provider di servizi personalizzato è se un dispositivo ha alcuni requisiti di archiviazione dati specifici o insoliti che i provider di servizi standard non gestiscono, ad esempio, se i file devono essere archiviati in posizioni specifiche e il sistema operativo del dispositivo non gestisce automaticamente questa operazione.

Quando un dispositivo è connesso al computer, il sistema operativo crea un'istanza del provider di servizi appropriato per ogni applicazione di Windows Media Gestione dispositivi. Se viene avviata una seconda applicazione di Windows Media Gestione dispositivi, verrà caricata una seconda istanza del provider di servizi. Tuttavia, ogni provider di servizi può gestire più dispositivi. come illustrato nel diagramma seguente.

Il diagramma precedente mostra due applicazioni diverse che comunicano con due dispositivi MTP. I dispositivi usano la stessa classe del provider di servizi, ma ogni applicazione ha una propria istanza dello stesso provider di servizi. Ogni istanza del provider di servizi comunica con i dispositivi. Le diverse istanze del provider di servizi non sono consapevoli tra loro.

Molti metodi dell'applicazione hanno un metodo provider di servizi denominato corrispondente. Quando l'applicazione chiama un metodo, Windows Media Gestione dispositivi instrada la chiamata al metodo corrispondente nel provider di servizi (anche se potrebbe eseguire alcune azioni interne aggiuntive). Ad esempio, quando l'applicazione chiama IWMDMDevice3::GetProperty, Windows Media Gestione dispositivi instrada questa chiamata all'implementazione del provider di servizi IMDSPDevice3::GetProperty. La maggior parte delle interfacce dell'applicazione inizia con IWMDM e l'interfaccia del provider di servizi corrispondente inizia con IMDSP. Il provider di servizi deve gestire questa chiamata al metodo e restituire un risultato appropriato.

Un'applicazione non esplora mai o comunica direttamente con un dispositivo (a meno che non chiami IWMDMDevice3::D eviceIoControl o IWMDMStorage::SendOpaqueCommand); l'applicazione comunica con il provider di servizi, che deve rappresentare un dispositivo nel modo più logico e semplice possibile. Quando l'applicazione richiede informazioni sul dispositivo o enumera oggetti nel dispositivo, il provider di servizi esegue una query sul dispositivo in modo appropriato e acquisisce e restituisce le informazioni appropriate. Può esporre l'organizzazione file nel dispositivo in modo diverso dal modo in cui viene archiviata fisicamente nel dispositivo, se appropriato. Tuttavia espone il dispositivo, deve essere in modo coerente, logico, per consentire all'applicazione di trovare le esigenze e gestire i comandi inviati. Un buon provider di servizi nasconderà le peculiarità specifiche del dispositivo, ad esempio se il dispositivo archivia fisicamente una playlist come file con un'estensione di file personalizzata, il provider di servizi deve aggiungere tale estensione automaticamente quando l'applicazione crea una playlist nel dispositivo; non dovrebbe aspettarsi che l'applicazione sappia l'estensione appropriata durante la creazione di un oggetto playlist.

I provider di servizi vengono eseguiti all'interno del processo dell'applicazione chiamante. L'unica eccezione a questa è il provider di servizi MTP, che viene eseguito nel proprio processo. A causa di questo, esiste un rischio che un provider di servizi bloccato causerà il blocco dell'applicazione chiamante. Pertanto, i provider di servizi devono essere progettati per essere affidabili e prevenire il blocco e le applicazioni devono essere progettate per evitare lo stallo se una determinata chiamata al metodo non restituisce rapidamente.

Argomenti correlati

Introduzione