WinFS - nowa nadzieja Microsoftu

WinFS, nowy produkt Microsoftu, miał być częścią Visty, ale będzie debiutował samodzielnie. Jest równie nowatorski, co niekompletny.

WinFS, nowy produkt Microsoftu, miał być częścią Visty, ale będzie debiutował samodzielnie. Jest równie nowatorski, co niekompletny.

Win jest skrótem od Windows, ale FS bynajmniej nie oznacza File System, ale bardziej ambitne Future Storage. Ani historii, ani samej premiery WinFS nie można uważać za typową. Zamiast na najbliższej wielkiej konferencji dla profesjonalistów, kod pojawił się dobry tydzień wcześniej w Internecie, witrynie MSDN, na oficjalnej stronie dla programistów piszących do Windows. Mimo że Microsoft zapowiadał betę, czyli produkt w zasadzie gotowy, to, co się ukazało, zasługuje raczej na określenie "beta bardzo wczesna". Stało się jasne, że prawie gotowa Vista i system plików do niej przeznaczony nie są na tym samym etapie rozwoju. System operacyjny szykowany na przyszły rok nie będzie tak obfitował w nowości, jak obiecywano, prawdopodobnie WinFS zdąży dopiero na jego następną wersję.

Czym jest WinFS? Jaki właściwie produkt i do kogo kierowany ujrzał światło dzienne? Odpowiedź zależy od perspektywy czasu i punktualności producenta. Jedno nie ulega wątpliwości: przygotowywana jest zunifikowana cyfrowa zupa, do której wleje się wszelkie możliwe składniki. Pliki z systemu folderów, wszystkie informacje z rejestru, komplet tego, co robi się za pomocą Active Directory, a wszystko przyprawione danymi z Outlooka: kontaktami, listami i notatkami z kalendarza.

Mieszać w tym kotle będą relacyjne bazy danych, obiekty, XML i metadane. Brzmi to wystarczająco poważnie, ale w istocie mamy do czynienia z powłoką przykrywającą system plików i innych danych.

System totalny

Po instalacji WinFS w Eksploatorze pojawia się nowy folder, WinFS Stores. Jego adres udaje udział sieciowy \\Komputer\DefaultStore. Pliki wrzucone do magazynu są opatrywane identyfikatorem (Item ID) i atrybutem rodzaju (Type).Duża grupa plików (GenericFile) nie jest rozpoznawana przez system.

Po instalacji WinFS w Eksploatorze pojawia się nowy folder, WinFS Stores. Jego adres udaje udział sieciowy \\Komputer\DefaultStore. Pliki wrzucone do magazynu są opatrywane identyfikatorem (Item ID) i atrybutem rodzaju (Type).Duża grupa plików (GenericFile) nie jest rozpoznawana przez system.

Rzeczywiście, jeżeli plan się powiedzie, to poza systemem WinFS, w tradycyjnej postaci pozostaną tylko te dane, do których wymagamy bardzo szybkiego dostępu i które chcemy wydajnie przetwarzać. Można myśleć o bazach danych w rodzaju SAP R3 czy aplikacjach CAD, chociaż nawet tam może być celowe przechowywanie części danych pod kontrolą WinFS.

W ten sposób dochodzimy do prawdopodobnej przyczyny tak niezwykłej premiery - chodziło raczej o programistów niż przyszłych użytkowników. Totalny w założeniu system powinien obsługiwać wiele rodzajów danych do rozmaitych aplikacji. Bez pomocy z zewnątrz nawet gigant z Redmond nie daje rady.

Jak już pisaliśmy, Microsoft nazwał to wydanie nowego systemu "betą" zdecydowanie na wyrost. Z każdej strony widać prowizorkę i oznaki pośpiechu. Zamiast pracującej całości, jak na betę przystało, mamy łaty surowego kodu, które często wymagają ręcznego zszywania. Uruchamianie go w dobrze pracującym systemie nie zawsze się uda, a nawet może spowodować jego destrukcję. Można by rozpocząć na przykład od Wirtualnego PC, ale nakładka tego systemu np. na Maka nie ma ochoty obsługiwać WinFS, który - jak się okazało - został skompilowany na Pentium 4. Paradoksalnie nowy system nie działa także pod kontrolą Visty, do której był przeznaczony, bo brak do niego odpowiednich bibliotek. Bardziej zrozumiała jest odmowa współpracy z systemem plików FAT. Nie ma w nim, dostępnych w konkurencyjnym NTFS-ie, atrybutów, z których WinFS korzysta.

Na komputerze z Windows XP z wymienionym systemem plików instalacja nie jest trudna, wystarczy pilnie przestrzegać instrukcji. Należy rozpocząć od wersji beta 2 .NET Framework 2.0. Wbrew zwyczajom, ta jest nowsza od wersji końcowej. Ważne, aby obsługiwała procedury Common Language Routine v.2.050215.

Po restarcie maszyny należy otworzyć Eksplorator Windows. Między twardymi dyskami, napędami optycznymi i pulpitem zauważymy tam nowy obiekt, z etykietą WinFS Stores, a po jego otwarciu drugi magazyn, podpisany DefaultStore. Te obiekty są widoczne tylko w Eksploratorze, a na przykład popularny Total Commander okazuje się bezradny. Napełnianie domyślnego magazynu może się zacząć automatycznie, ale my nie mieliśmy tyle szczęścia. Pracowicie zaznaczyliśmy garść plików i upuściliśmy do środka. Od tego momentu zaczął się dużo wolniejszy niż zwykłe kopiowanie proces napełniania magazynu. Przebiega on rozmaicie w wypadku różnych rodzajów danych. Te, które można nazwać kontaktami, są opisywane i trafiają w całości do magazynu. Dokumenty Worda albo innych programów z pakietu Office są także kopiowane do magazynu i otrzymują długi, 32-znakowy, unikatowy numer identyfikacyjny, tzw. GUID (globally unique ID). Plik otrzymuje atrybut "ukryty", aby żaden z użytkowników nie uzyskał do niego dostępu poza kontrolą WinFS.

Tworzenie zapytań za pomocą StoreSpy. Wybieramy z rozwijanego menu.

Tworzenie zapytań za pomocą StoreSpy. Wybieramy z rozwijanego menu.

Razem z numerem identyfikacyjnym tworzony jest skojarzony z plikiem rekord relacyjnej bazy danych, która ma ułatwiać późniejsze wyszukiwanie według wybranych kryteriów. Synchronizacja danych o pliku z nim samym jest podstawą sukcesu, a przechowywanie danych w dalszym ciągu w systemie NTFS pozwala zachować szybki i bezpośredni dostęp do nich za pomocą standardowych funkcji Win32 API.

W szczególności dokumenty pakietu Office są dalej przechowywane pod opieką NTFS, a wszystkie metadane skojarzone z nim są umieszczane w bazie WinFS. Jeśli obiekt składa się wyłącznie z metadanych, na przykład kontakt lub kalendarz, jest wtedy przechowywany w całości w magazynie WinFS. Żadna z jego części nie trafia do sfery zarządzanej przez NTFS.

Takie ujęcie miało większy sens, kiedy Microsoft wypracowywał precyzyjny schemat w języku XML, który miał być stosowany podczas pierwszego wprowadzania obiektu do magazynu, ale klarowność tego podziału została zakłócona. Magazyn WinFS, zbudowany na podstawie kodu SQL 2005, zwanego Yukon, rozrósł się i obejmuje nie tylko samą bazę, ale też niektóre rodzaje obiektów, mając dzięki temu tendencję do stania się systemem z wielkim pojedynczym plikiem.

Na czym polega problem? Przypuśćmy, że w obecnej sytuacji WinFS to zainstalowany magazyn w postaci jednego dużego pliku, umieszczonego w systemie NTFS komputera. Pamiętamy, że jedne obiekty są w pliku, a inne poza nim. To rodzi pytanie, w jaki sposób przekłamania i błędy będą obsługiwane w różnych sytuacjach, po obu stronach drzwi magazynu. Przechowywanie wszystkiego w jednym miejscu zmniejszyłoby prawdopodobieństwo, że jakieś elementy zostaną osierocone na skutek błędu. Zastosowanie funkcji chkdsk daje szanse na zlepienie pękniętego magazynu, zachowanie stabilności i utrzymanie synchronizacji.

Sposób przechowywania dokumentów jest nieco mylący. Mimo że są aktualnie zapisane poza magazynem systemu WinFS, wszystkie manipulacje, w tym najpopularniejsze przeciąganie myszą, odbywają się tak, jakby były umieszczone wewnątrz niego. Użytkownik ma do takich dokumentów dostęp jedynie przez magazyn. To wrażenie jest dodatkowo wzmocnione zastosowaniem konwencji sugerującej przechowywanie dokumentów w tym miejscu. Zapis: \\Nazwa_komputera\DefaultStore\nazwa dokumentu jest przecież identyczny z konwencjonalnym \\Nazwa_komputera\Udostępniany udział\nazwa dokumentu, który precyzyjnie wskazuje lokalizację obiektu.

W danych o zdjęciu w formacie JPG nie ma ani słowa o jego temacie. Są tam tylko informacje techniczne reprodukowane z Exifa.

W danych o zdjęciu w formacie JPG nie ma ani słowa o jego temacie. Są tam tylko informacje techniczne reprodukowane z Exifa.

Na ilustracji pokazaliśmy wynik przenoszenia do magazynu różnych rodzajów plików. Najpopularniejszy przyrostek GenericFile oznacza te rodzaje plików, których aktualna implementacja systemu WinFS nie rozpoznała. Taki plik pozostaje dla systemu "czarną skrzynką", a jedyne dane wpisywane do bazy były i tak znane z systemu operacyjnego. Lakoniczność wpisu powoduje, że wyszukiwanie WinFS niezbyt wzbogaca wiedzę, którą można uzyskać bez jego pomocy, na podstawie danych w rodzaju daty utworzenia pliku i kilku atrybutów.

Jeśli można, choć z trudem, zrozumieć nierozpoznawanie klipów multimedialnych, to ślepotę systemu na tak proste elementy, jak bitmapa czy plik RTF tłumaczy jedynie brak czasu i układ priorytetów programistów z Redmond.

Pomoc firm trzecich wydaje się bardzo potrzebna, a połączenie systemu metadanych z obiektami powinno ułatwiać tworzenie brakujących części oprogramowania.

Dodatkowe narzędzia

To, co napisano powyżej, ilustruje prawie wszystkie możliwości mocno tymczasowego rdzenia systemu WinFS, ale w pakiecie instalacyjnym jest jeszcze kilka programów użytkowych dostarczanych wraz z wersją podstawową. Przegląd najlepiej zacząć od StoreSpy, który pozwala na spacerowanie po magazynie. Jest to pouczająca wycieczka, zdradzająca, jak obiekty zostają opisane i potem rozpoznawane. Weźmy na przykład pliki Excela. Przeciągnięcie jednego z nich, powiedzmy Excel.xls, do domyślnego magazynu Default Store ulokowanego pod adresem \\nazwa komputera\DefaultStore powoduje zmiany w jego atrybutach. Już w Eksploratorze Windows zauważymy GUID, jeden z atrybutów dodanych do każdego pliku z magazynu. Zostawmy ten program i spróbujmy znaleźć nasz arkusz za pomocą magazynowego szpiega. Zastosujemy w tym celu dość proste zapytanie, którym odcedzimy szukany plik od pozostałych danych zapisanych w magazynie. W części nawigacyjnej dodamy włączenie podfolderów, a na pasku wybierzemy przycisk Documents. Szpieg zrewanżuje się listą wszystkich dokumentów. Jest na niej poszukiwany arkusz. Część danych, tytuł, nazwa i relatywna ścieżka dostępu znajdą się w grupie danych głównych. Obok nich jest także bardzo łatwy do zapamiętania, 32-znakowy identyfikator. Na razie nic ciekawego.

Bardziej szczegółowe informacje znajdują się w prawym panelu zatytułowanym w wypadku takiego pliku System.Storage.Documents.Document. Część z nich dotyczy ogólnych atrybutów pliku (ukryty, archiwalny itd.), inne - synchronizacji arkusza z magazynem.

Z grafiki trudniej wypreparować informacje tekstowe, zresztą magazyn dotąd pozytywnie weryfikuje tylko format JPG. Pliki graficzne z innymi rozszerzeniami są opisane przy użyciu absolutnego minimum danych, podobnie jak reszta nierozpoznanych plików. Z obrazu w formacie JPG ekstrahowałyby się także tylko podstawowe informacje, gdyby nie ratujący sytuację exif, system stowarzyszony z aparatami cyfrowymi, który razem ze zdjęciem zapisuje model aparatu, wielkość przesłony, migawkę i wiele, wiele innych danych o wykonanym zdjęciu. Dane te są wczytywane z pliku i zapisane w magazynie.


Zobacz również