Windows Media Geräte-Manager-Architektur
Windows Media Geräte-Manager ermöglicht es einer Anwendung oder einem Plug-In, mit einem Gerät zu kommunizieren. Anwendungen können Gerätemetadaten anfordern, angefügte Geräte auflisten und untersuchen und Objekte (Ordner, Dateien, Wiedergabelisten usw.) senden oder empfangen. Windows Media Geräte-Manager stellt eine einzelne API für die aufrufende Anwendung bereit, unabhängig davon, welcher Gerätetyp aufgerufen wird (MTP oder Massenspeicherklasse, Dienstanbieter, die auf Version 10 basieren, oder Dienstanbieter, die auf früheren Versionen von Windows Media Geräte-Manager basieren).
Windows Media Geräte-Manager fungiert als Vermittler für die drei Hauptkomponenten des Systems: die Anwendung, die Anforderungen stellt (Informationen, Lesen oder Schreiben von Daten usw.), ein sicherer Inhaltsanbieter, der die Kommunikation mit DRM-geschützten Dateien verarbeitet, und ein Dienstanbieter, der Anforderungen von der Anwendung empfängt und mit dem Gerät kommuniziert, um diese Anforderungen auszuführen. Sowohl die Anwendung als auch der Dienstanbieter basieren auf dem Windows Media Geräte-Manager SDK.
Das folgende Diagramm zeigt, wie eine Desktopanwendung mit einem Gerät über Windows Media Geräte-Manager 11 kommuniziert.
Das obige Diagramm zeigt eine Anwendung, die mit vier verschiedenen Gerätetypen kommuniziert, die jeweils mit einem eigenen Dienstanbieter kommunizieren. Jeder Dienstanbieter ist für die Kommunikation mit einem bestimmten Gerätetyp konzipiert. Dieses Diagramm zeigt die drei von Microsoft bereitgestellten Dienstanbieter (generische Klassentreiber für Massenspeicherklassengeräte, RAPI-Geräte und MTP-Geräte) sowie einen benutzerdefinierten Dienstanbieter für ein proprietäres Gerät, das von einem Drittanbieter erstellt wurde. Wenn ein Gerät eine Verbindung herstellt, instanziiert Windows Media Geräte-Manager eine instance des für dieses Gerät registrierten Dienstanbieters. Die Dienstanbieter erhalten Anforderungen von der Anwendung über Windows Media Geräte-Manager Schnittstellen, die sie implementieren, verwenden geeignete Treiber für die Kommunikation mit dem Gerät und geben entsprechende Ergebnisse zurück. Die Kommunikation zwischen dem Dienstanbieter und dem Gerät erfolgt außerhalb der Domäne von Windows Media Geräte-Manager.
Dienstanbieter sind für die Anwendung unsichtbar; einer Anwendung wird nur eine Liste von "Geräten" angezeigt, da Windows Media Geräte-Manager einen Standardsatz von Methoden und Schnittstellen für alle Geräte verfügbar macht. Wenn ein Hersteller einen benutzerdefinierten Dienstanbieter erstellt, muss er alle Standardmethoden von Windows Media Geräte-Manager verarbeiten, damit Anwendungen das Gerät verwenden können.
Dieses Diagramm zeigt auch ein SCP-Modul (Secure Content Provider). Dieses Modul ist für den Umgang mit drM-geschützten Inhalten (Digital Rights Management) zuständig. Microsoft bietet ein SCP-Modul, das DRM-geschützte WMA- und WMV-Dateien verarbeiten kann. Wenn eine Anwendung oder ein Gerät andere geschützte Formate verarbeiten möchte, muss es ein eigenes SCP-Modul bereitstellen. Weder die Anwendung noch der Dienstanbieter befasst sich direkt mit dem SCP.
Sowohl die Anwendung als auch der Dienstanbieter basieren auf Windows Media Geräte-Manager, die Anrufe zwischen der Anwendung und dem entsprechenden Dienstanbieter für ein Gerät weiterleiten. Der Dienstanbieter ist für die direkte Kommunikation mit dem Gerät verantwortlich. Windows Media Geräte-Manager führt einige Aktionen selbst aus (z. B. das Auflisten verbundener Geräte, das Routing von Anrufen und die Verarbeitung der Komponentenüberprüfung). Die meiste Arbeit wird jedoch vom Dienstanbieter ausgeführt, der Anforderungen von der Anwendung empfängt und mit dem Gerät kommuniziert.
Eine Anwendung, die auf Windows Media Geräte-Manager basiert, kann mit Geräten und Dienstanbietern kommunizieren, die auf früheren Versionen von Windows Media Geräte-Manager basieren. Diese älteren Geräte werden jedoch über Komponenten der 9-Serie ausgeführt (nicht angezeigt) und unterstützen nicht die neuesten Features, insbesondere die fortschrittlichere Technologie für die Verwaltung digitaler Rechte.
Architektur eines Geräts
Das folgende Diagramm zeigt eine vereinfachte Hierarchie von Geräten und Speichern, die von einer Anwendung mit Windows Media Geräte-Manager dargestellt wird.
Das obige Diagramm zeigt eine vereinfachte Version eines verbundenen Flashlaufwerks, wie sie von einer Windows Media-Geräte-Manager-Anwendung dargestellt wird. Das Flash-Laufwerk verfügt über Attribute und Eigenschaften, z. B. eine Seriennummer und unterstützte Formatkonfigurationen. Ein unmittelbares untergeordnetes Element des Flashgeräts ist das Stammspeicherobjekt, das einen Ordner enthält, der selbst ein Image und einen Song enthält.
Eine Anwendung listet die Liste der angefügten Geräte auf, indem eine Enumerationsmethode aufgerufen wird, die von der IWMDeviceManager-Stammschnittstelle verfügbar gemacht wird. Geräte werden durch eine IWMDMDevice-Schnittstelle (oder eine abgeleitete) Schnittstelle dargestellt. Diese Schnittstelle macht Methoden zum Abrufen des Gerätenamens, der Formatfunktionen, der Seriennummer usw. sowie einer Methode verfügbar, die Speicher auf dem Gerät aufzählt . In Windows Media Geräte-Manager ist ein Speicher ein beliebiges Objekt auf dem Gerät, unabhängig davon, ob es sich um ein tatsächliches Datenblob handelt oder nicht. Beispiel: Audiodateien, Textdateien, Ordner, als Dateien gespeicherte Wiedergabelisten und als Metadaten gespeicherte Wiedergabelisten gelten als Speicher, auch wenn Ordner und Metadatenelemente wahrscheinlich keine physische Datei darstellen. Der Typ (oder das Format) eines Speichers kann abgerufen werden, indem GetAttributes (oder GetMetadata) aufgerufen wird, um das Format des Speichers anzufordern.
Speicher auf einem Gerät werden hierarchisch gespeichert, und alle Geräte verfügen über einen Stammspeicher. Jeder Speicher kann null oder mehr untergeordnete Objekte enthalten, die durch Aufrufen der IWMDMMStorage::EnumStorage-Methode dieses Speichers aufgelistet werden.
Beachten Sie, dass jedem Speicher im Diagramm Attribute und Metadaten zugeordnet sind (nicht alle Werte werden angezeigt). Attribute sind einfache, boolesche Informationen, die häufig Verwaltungs- oder Navigationsinformationen beschreiben (z. B. "verfügt über Ordner" oder "kann gelöscht werden"), während Metadaten Zeichenfolgenwerte, Zahlen oder komplexe Informationen (z. B. Renderingfunktionen) sein können. Attribute werden durch einen relativ begrenzten Satz von Flags beschrieben, die vom SDK definiert und durch Aufrufen von IWMDMStorage::GetAttributes oder IWMDMStorage2::GetAttributes2 abgerufen werden. Metadatenwerte werden durch einen eindeutigen Namen abgerufen. das SDK definiert eine Reihe von Metadatenwerten, die Geräte unterstützen sollen, aber Geräte können ihre eigenen Metadatenkonstanten definieren. Wenn ein Gerät oder Dienstanbieter jedoch eine neue Metadatenkonstante definiert, können Anwendungen diesen Wert nur anfordern oder festlegen, wenn die Anwendungsentwickler diese neue Konstante kennen. Ein Dienstanbieter muss IWMDMStorage3 oder höher unterstützen, um das Abrufen oder Festlegen von Metadaten zu unterstützen. Weitere Informationen finden Sie unter Abrufen und Festlegen von Metadaten und Attributen.
Dienstanbieter
Der Dienstanbieter fungiert als Vermittler zwischen der Anwendung und dem Gerät. Der Dienstanbieter ist für den Anwendungsentwickler unsichtbar, sodass ein Anwendungsentwickler nichts über die Entwicklung eines Dienstanbieters wissen muss. Es ist jedoch der Dienstanbieter, der die Kommunikation mit einem Gerät übernimmt.
Ein Dienstanbieter ist eine COM-DLL, die auf Windows Media Geräte-Manager basiert und Anforderungen von einer Anwendung empfängt und mit dem Gerät kommuniziert, um diese auszuführen. Die Kommunikation mit der Desktopanwendung wird von Windows Media Geräte-Manager vermittelt. Die Kommunikation mit dem Gerät wird vom Dienstanbieter gesteuert.
Ein Dienstanbieter empfängt Anforderungen von der Anwendung zum Auflisten von Geräteinhalten, Anforderungen für Gerätefunktionen, Anforderungen zum Lesen oder Schreiben von Daten usw. Es muss den Entwurf eines Geräts so gut kennen, dass es Befehle im richtigen Format und Protokoll senden kann. Es sollte auch in der Lage sein, gerätespezifische Anforderungen wie eine erforderliche Dateierweiterung für Wiedergabelisten auszublenden, sodass Anwendungen diese Anforderungen nicht kennen müssen, um das Gerät verwenden zu können.
Microsoft bietet eine Reihe von Dienstanbietern für Standardgerätetypen, einschließlich generischer MTP-Geräte, Massenspeicherklassengeräte und RAPI-Geräte. Der einzige Grund, warum ein Gerätedesigner einen benutzerdefinierten Dienstanbieter erstellen muss, ist, wenn ein Gerät bestimmte oder ungewöhnliche Datenspeicheranforderungen aufweist, die von den Standarddienstanbietern nicht verarbeitet werden– für instance, wenn Dateien an bestimmten Speicherorten gespeichert werden müssen und das Gerätebetriebssystem dies nicht automatisch verarbeitet.
Wenn ein Gerät mit dem Computer verbunden ist, erstellt das Betriebssystem eine instance des entsprechenden Dienstanbieters für jede Windows Media-Geräte-Manager-Anwendung. Wenn eine zweite Windows Media Geräte-Manager-Anwendung gestartet wird, wird eine zweite instance des Dienstanbieters geladen. Jeder Dienstanbieter kann jedoch mehrere Geräte verarbeiten. Dies wird im folgenden Diagramm veranschaulicht.
Das obige Diagramm zeigt zwei verschiedene Anwendungen, die mit zwei MTP-Geräten kommunizieren. Die Geräte verwenden dieselbe Dienstanbieterklasse, aber jede Anwendung verfügt über eine eigene instance desselben Dienstanbieters. Jeder Dienstanbieter instance kommuniziert mit Geräten. Die verschiedenen Instanzen des Dienstanbieters kennen einander nicht.
Viele Anwendungsmethoden verfügen über eine entsprechend benannte Dienstanbietermethode. Wenn die Anwendung eine Methode aufruft, leitet Windows Media Geräte-Manager den Aufruf an die entsprechende Methode des Dienstanbieters weiter (es kann jedoch zuerst einige zusätzliche interne Aktionen ausführen). Wenn die Anwendung beispielsweise IWMDMDevice3::GetProperty aufruft, leitet Windows Media Geräte-Manager diesen Aufruf an die Implementierung von IMDSPDevice3::GetProperty durch den Dienstanbieter weiter. (Die meisten Anwendungsschnittstellen beginnen mit IWMDM, und die entsprechende Dienstanbieterschnittstelle beginnt mit IMDSP). Es wird erwartet, dass der Dienstanbieter diesen Methodenaufruf verarbeitet und ein entsprechendes Ergebnis zurückgibt.
Eine Anwendung untersucht oder kommuniziert nie direkt mit einem Gerät (es sei denn, sie ruft IWMDMDevice3::D eviceIoControl oder IWMDMStorage::SendOpaqueCommand auf). Die Anwendung kommuniziert mit dem Dienstanbieter, der ein Gerät möglichst logisch und einfach darstellen muss. Wenn die Anwendung Informationen zum Gerät anfordert oder Objekte auf dem Gerät aufzählt, fragt der Dienstanbieter das Gerät in geeigneter Weise ab und ruft die entsprechenden Informationen ab und gibt diese zurück. Es kann die Datei organization auf dem Gerät anders verfügbar machen, als sie physisch auf dem Gerät gespeichert wird, sofern dies angemessen ist. Das Gerät sollte jedoch konsistent und logisch verfügbar gemacht werden, damit die Anwendung die benötigten Befehle finden und die gesendeten Befehle verarbeiten kann. Ein guter Dienstanbieter blendet gerätespezifische Besonderheiten aus. Wenn das Gerät beispielsweise eine Wiedergabeliste physisch als Datei mit einer benutzerdefinierten Dateierweiterung speichert, sollte der Dienstanbieter diese Erweiterung automatisch hinzufügen, wenn die Anwendung eine Wiedergabeliste auf dem Gerät erstellt; Es sollte nicht davon ausgegangen werden, dass die Anwendung beim Erstellen eines Wiedergabelistenobjekts die richtige Erweiterung kennt.
Dienstanbieter werden innerhalb des Prozesses der aufrufenden Anwendung ausgeführt. Die einzige Ausnahme ist der MTP-Dienstanbieter, der in seinem eigenen Prozess ausgeführt wird. Aus diesem Grund besteht ein gewisses Risiko, dass ein blockierter Dienstanbieter dazu führt, dass die aufrufende Anwendung blockiert wird. Daher sollten Dienstanbieter so konzipiert sein, dass sie robust sind und Blockieren verhindern, und Anwendungen sollten so konzipiert werden, dass sie nicht zum Stillstand kommen, wenn ein bestimmter Methodenaufruf nicht schnell zurückgegeben wird.
Zugehörige Themen