Architektura programu Windows Media Device Manager
Menedżer urządzeń z systemem Windows Media umożliwia aplikacjom lub wtyczkom komunikowanie się z urządzeniem. Aplikacje mogą żądać metadanych urządzenia, wyliczać i eksplorować dołączone urządzenia oraz wysyłać lub odbierać obiekty (foldery, pliki, listy odtwarzania itd.). Menedżer urządzeń z systemem Windows Media udostępnia jeden interfejs API do aplikacji wywołującej, niezależnie od typu urządzenia wywoływanego (MTP lub klasy pamięci masowej, dostawców usług opartych na wersji 10 lub dostawców usług opartych na wcześniejszych wersjach programu Windows Media Device Manager).
Menedżer urządzeń z systemem Windows Media działa jako przejście między trzema głównymi składnikami systemu: aplikacją, która wysyła żądania (w celu uzyskania informacji, odczytu lub zapisu danych itd.); bezpieczny dostawca zawartości, który jest składnikiem obsługującym komunikację z plikami chronionymi przez drM; oraz dostawca usług, który odbiera żądania z aplikacji i komunikuje się z urządzeniem w celu wykonania tych żądań. Zarówno aplikacja, jak i dostawca usług są oparte na zestawie SDK programu Windows Media Device Manager.
Na poniższym diagramie pokazano, jak aplikacja klasyczna komunikuje się z urządzeniem przy użyciu programu Windows Media Device Manager 11.
Na powyższym diagramie przedstawiono aplikację komunikującą się z czterema różnymi typami urządzeń, z których każdy ma własnego dostawcę usług. Każdy dostawca usług jest przeznaczony do komunikowania się z określonym typem urządzenia; Na tym diagramie przedstawiono trzech dostawców usług dostarczanych przez firmę Microsoft (ogólnych sterowników klas dla urządzeń klasy masowej, urządzeń RAPI i urządzeń MTP), a także niestandardowego dostawcy usług dla zastrzeżonego urządzenia utworzonego przez inną firmę. Gdy urządzenie nawiąże połączenie, Menedżer urządzeń z systemem Windows Media tworzy wystąpienie dostawcy usług zarejestrowanego dla tego urządzenia. Dostawcy usług pobierają żądania z aplikacji za pośrednictwem interfejsów menedżera urządzeń systemu Windows Media, które implementują, używają odpowiednich sterowników do komunikowania się z urządzeniem i zwracają odpowiednie wyniki. Komunikacja między dostawcą usług a urządzeniem znajduje się poza domeną Menedżera urządzeń z systemem Windows Media.
Dostawcy usług są niewidoczni dla aplikacji; aplikacja widzi tylko listę "urządzeń", ponieważ Menedżer urządzeń z systemem Windows Media udostępnia standardowy zestaw metod i interfejsów dla wszystkich urządzeń. Jeśli producent tworzy niestandardowego dostawcę usług, musi obsługiwać wszystkie standardowe metody menedżera urządzeń Windows Media, jeśli aplikacje mają mieć możliwość korzystania z urządzenia.
Ten diagram przedstawia również moduł bezpiecznego dostawcy zawartości (SCP). Ten moduł jest odpowiedzialny za obsługę zawartości chronionej za pomocą funkcji zarządzania prawami cyfrowymi (DRM). Firma Microsoft udostępnia moduł SCP, który może obsługiwać pliki WMA i CACHE chronione przez drM. Jeśli aplikacja lub urządzenie zamierza obsługiwać inne chronione formaty, musi udostępnić własny moduł SCP. Ani aplikacja, ani dostawca usług nie zajmują się bezpośrednio usługą SCP.
Zarówno aplikacja, jak i dostawca usług są oparte na Menedżerze urządzeń z systemem Windows Media, który kieruje wywołania między aplikacją a odpowiednim dostawcą usług dla urządzenia; dostawca usług jest odpowiedzialny za bezpośrednią komunikację z urządzeniem. Menedżer urządzeń z systemem Windows Media wykonuje pewne akcje (takie jak wyliczanie połączonych urządzeń, wywołania routingu i obsługa weryfikacji składnika); jednak większość pracy jest wykonywana przez dostawcę usług, który odbiera żądania z aplikacji i komunikuje się z urządzeniem.
Aplikacja oparta na Menedżerze urządzeń z systemem Windows Media może komunikować się z urządzeniami i dostawcami usług opartymi na wcześniejszych wersjach menedżera urządzeń Windows Media; jednak te starsze urządzenia będą działać za pośrednictwem składników serii 9 (nie pokazano) i nie będą obsługiwać najnowszych funkcji, zwłaszcza bardziej zaawansowanych technologii zarządzania prawami cyfrowymi.
Architektura urządzenia
Na poniższym diagramie przedstawiono uproszczoną hierarchię urządzeń i magazynów, jak widać w aplikacji przy użyciu Menedżera urządzeń z systemem Windows Media.
Na powyższym diagramie przedstawiono uproszczoną wersję podłączonego dysku flash, jak widać w aplikacji Menedżera urządzeń z systemem Windows Media. Dysk flash ma atrybuty i właściwości, takie jak numer seryjny i obsługiwane konfiguracje formatu. Bezpośrednim elementem podrzędnym urządzenia flash jest główny obiekt magazynu, który zawiera folder, który zawiera obraz i piosenkę.
Aplikacja wylicza listę dołączonych urządzeń przez wywołanie metody wyliczenia uwidocznionej przez główny interfejs IWMDeviceManager. Urządzenia są reprezentowane przez interfejs IWMDMDevice (lub pochodne). Ten interfejs uwidacznia metody pobierania nazwy urządzenia, możliwości formatowania, numeru seryjnego itd., a także metody wyliczanej magazynów na urządzeniu. W Menedżerze urządzeń z systemem Windows Media magazyn jest dowolnym obiektem na urządzeniu, niezależnie od tego, czy jest to rzeczywisty obiekt blob danych. Na przykład: pliki audio, pliki tekstowe, foldery, listy odtwarzania przechowywane jako pliki i listy odtwarzania przechowywane jako metadane są traktowane jako magazyny, mimo że foldery i elementy metadanych prawdopodobnie nie reprezentują pliku fizycznego. Typ (lub format) magazynu można pobrać, wywołując GetAttributes (lub GetMetadata, żądając formatu magazynu).
Magazyny na urządzeniu są przechowywane hierarchicznie, a wszystkie urządzenia mają magazyn główny. Każdy magazyn może przechowywać zero lub więcej obiektów podrzędnych, wyliczone przez wywołanie metody IWMDMStorage::EnumStorage.
Należy pamiętać, że każdy magazyn na diagramie ma skojarzone atrybuty i metadane (nie wszystkie wartości są wyświetlane). Atrybuty są proste, informacje logiczne często opisują informacje dotyczące zarządzania lub nawigacji (takie jak "ma foldery" lub "mogą usuwać"), natomiast metadane mogą być wartościami ciągów, liczbami lub złożonymi informacjami (takimi jak możliwości renderowania). Atrybuty są opisane przez dość ograniczony zestaw flag zdefiniowanych przez zestaw SDK i pobierane przez wywołanie IWMDMStorage::GetAttributes lub IWMDMStorage2::GetAttributes2. Wartości metadanych są pobierane przez unikatową nazwę; Zestaw SDK definiuje wiele wartości metadanych, które powinny obsługiwać urządzenia, ale urządzenia mogą definiować własne stałe metadanych . Jeśli jednak urządzenie lub dostawca usług definiuje nową stałą metadanych, aplikacje nie będą mogły żądać ani ustawiać tej wartości, chyba że deweloperzy aplikacji wiedzieli o tej nowej stałej. Dostawca usług musi obsługiwać IWMDMStorage3 lub nowszym w celu obsługi pobierania lub ustawiania metadanych. Aby uzyskać więcej informacji, zobacz Pobieranie i ustawianie metadanych i atrybutów.
Usługodawców
Dostawca usług działa jako środek pośredniczący między aplikacją a urządzeniem. Dostawca usług jest niewidoczny dla dewelopera aplikacji, więc deweloper aplikacji nie musi wiedzieć nic o tworzeniu dostawcy usług. Jednak jest to dostawca usług, który wykonuje pracę komunikacji z urządzeniem.
Dostawca usług to biblioteka DLL COM oparta na Menedżerze urządzeń z systemem Windows Media, która odbiera żądania z aplikacji i komunikuje się z urządzeniem w celu ich wykonania. Komunikacja z aplikacją klasyczną jest mediaowana przez Menedżera urządzeń z systemem Windows Media; komunikacja z urządzeniem jest pod kontrolą dostawcy usług.
Dostawca usług odbiera żądania od aplikacji w celu wyliczania zawartości urządzenia, żądań dotyczących możliwości urządzenia, żądań odczytu lub zapisu danych itd. Musi znać projekt urządzenia na tyle dobrze, że może wysyłać polecenia w odpowiednim formacie i protokole. Powinno również być możliwe ukrycie wymagań specyficznych dla urządzenia, takich jak wymagane rozszerzenie pliku dla list odtwarzania, dzięki czemu aplikacje nie muszą znać tych wymagań w celu korzystania z urządzenia.
Firma Microsoft udostępnia wielu dostawców usług dla standardowych typów urządzeń, w tym ogólnych urządzeń MTP, urządzeń klasy pamięci masowej i urządzeń RAPI. Jedynym powodem, dla którego projektant urządzeń powinien utworzyć niestandardowego dostawcę usług, jest to, że urządzenie ma określone lub nietypowe wymagania dotyczące przechowywania danych, które nie są obsługiwane przez standardowych dostawców usług — na przykład jeśli pliki muszą być przechowywane w określonych lokalizacjach, a system operacyjny urządzenia nie obsługuje tego automatycznie.
Gdy urządzenie jest połączone z komputerem, system operacyjny tworzy jedno wystąpienie odpowiedniego dostawcy usług dla każdej aplikacji Menedżera urządzeń z systemem Windows Media. Jeśli zostanie uruchomiona druga aplikacja Menedżera urządzeń z systemem Windows Media, zostanie załadowane drugie wystąpienie dostawcy usług. Jednak każdy dostawca usług może obsługiwać wiele urządzeń. Na poniższym diagramie przedstawiono to.
Na powyższym diagramie przedstawiono dwie różne aplikacje komunikujące się z dwoma urządzeniami MTP. Urządzenia korzystają z tej samej klasy dostawcy usług, ale każda aplikacja ma własne wystąpienie tego samego dostawcy usług. Każde wystąpienie dostawcy usług komunikuje się z urządzeniami. Różne wystąpienia dostawcy usług nie są ze sobą świadome.
Wiele metod aplikacji ma odpowiednio nazwaną metodę dostawcy usług. Gdy aplikacja wywołuje metodę, Menedżer urządzeń z systemem Windows Media kieruje wywołanie do odpowiedniej metody u dostawcy usług (choć może najpierw wykonać dodatkowe akcje wewnętrzne). Na przykład gdy aplikacja wywołuje IWMDMDevice3::GetProperty, menedżer urządzeń Windows Media kieruje to wywołanie do implementacji IMDSPDevice3::GetProperty. (Większość interfejsów aplikacji zaczyna się od IWMDM, a odpowiedni interfejs dostawcy usług zaczyna się od IMDSP). Oczekuje się, że dostawca usług obsłuży to wywołanie metody i zwróci odpowiedni wynik.
Aplikacja nigdy nie eksploruje urządzenia ani nie komunikuje się z nim bezpośrednio (chyba że wywołuje IWMDMDevice3::D eviceIoControl lub IWMDMStorage::SendOpaqueCommand); aplikacja komunikuje się z dostawcą usług, który musi reprezentować urządzenie w najbardziej logiczny i prosty sposób. Gdy aplikacja żąda informacji o urządzeniu lub wylicza obiekty na urządzeniu, dostawca usług wysyła zapytanie do urządzenia w odpowiedni sposób i uzyskuje i zwraca odpowiednie informacje. Może to spowodować, że organizacja plików na urządzeniu różni się od tego, jak jest fizycznie przechowywana na urządzeniu, jeśli jest to odpowiednie. Jednak uwidacznia urządzenie, powinno być w spójny, logiczny sposób, aby umożliwić aplikacji znalezienie potrzebnych mu poleceń i obsługę wysyłanych poleceń. Dobry dostawca usług ukryje specyfiki specyficzne dla urządzenia — na przykład jeśli urządzenie fizycznie przechowuje listę odtwarzania jako plik z niestandardowym rozszerzeniem pliku, dostawca usług powinien dodać to rozszerzenie automatycznie, gdy aplikacja tworzy listę odtwarzania na urządzeniu; aplikacja nie powinna oczekiwać, że aplikacja zna odpowiednie rozszerzenie podczas tworzenia obiektu listy odtwarzania.
Dostawcy usług działają wewnątrz procesu wywołującej aplikacji. Jedynym wyjątkiem jest dostawca usług MTP, który działa we własnym procesie. W związku z tym istnieje pewne ryzyko, że zablokowany dostawca usług spowoduje zablokowanie aplikacji wywołującej. W związku z tym dostawcy usług powinni być zaprojektowani tak, aby był niezawodny i zapobiegać blokowaniu, a aplikacje powinny być zaprojektowane tak, aby uniknąć wstrzymania, jeśli określone wywołanie metody nie zwróci się szybko.
Tematy pokrewne