WinFS Contents

1. WinFS Contents 1. Overview 2. Why WinFS? 3. WinFS Architecture 3.1 WinFS Technology 3.2 WinFS Types and Extensibility 3.3 WinFS Synchronization 4. WinFS for Developers 5. WinFS Availability 6. WinFS Resources

2. WinFS Overview WinFS is the code name of a Windows storage subsystem, being developed by Microsoft for use on its future Windows (c) Operating System. WinFS is a relational database located on NTFS and representing itself to the operating system as a file storage subsystem. The codename WinFS stands for Windows Future Storage. WinFS intends to link the worlds of traditional relational databases, objects, XML, and file systems of unstructured documents with the concept of metadata over files. Instead of representing a file solely by directory path and filename, WinFS represents individual domain objects - e.g. images, e-mails, address book entries, and any kind of regular file - with indexed and searchable context and keyword information. The underlying system is based on Microsoft SQL Server (c) database engine. WinFS provides access to data through both traditional file-based APIs, and new object-based approaches that take advantage of the new features. Applications that are not written to take advantage of WinFS can access the contents of a WinFS Store through a regular UNC path.

3. Why WinFS ? A traditional file system, such as FAT or NTFS, has its contents organized in a hierarchal directory structure and is relatively slow in searching the content by particular attributes. If you organize your pictures in folders “by Dates” – there would be no way to access them “by Persons”, “by Events” etc… You are to use third party custom software like Adobe PhotoAlbum (c) to perform this task. WinFS overcomes the hierarchy and "flattens" the storage of individual files (i.e. there is no "hierarchy" based on directory and file names), and it enables searching for items by their attributes (like date the photograph was taken, who or what is in the picture, what camera was used to take the picture, etc). WinFS also extends this idea beyond the kinds of information that have been traditionally stored as files on a file system. WinFS can understand any arbitrary set of data, such as a "Photo" or an "Email" or a "Calendar". Applications today must store these kinds of information in their own custom database; if other applications want to gain access to this information, it's quite a lot of work because there is no application-neutral storage mechanism for this kind of information.

4. WinFS Architecture WinFS is not a physical file system; it is built on top of NTFS, and NTFS will remain as the default file system. WinFS is based on SQL Server and its core feature is to provide a data relations mechanism. This means that your pictures are related to dates, events, and persons and so on. This allows you to perform a search such as "All pictures of Joe taken the last month". This query is not possible for a traditional file system such as NTFS, but will be a trivial part of WinFS. In reality, WinFS stores are simply SQL Server database files (.mdf files) with the FILESTREAM feature enabled. These files are stored in secured folder named "System Volume Information" placed into the volume root, in folders under the folder "WinFS" with names of GUIDs of these stores.

5. WinFS Technology From a technology standpoint, WinFS is made up of five components: Core WinFS Core WinFS is made up of the core services that you would expect from a file system. Think of Core WinFS as the fundamentals, which includes operations and file system services. Some examples here are security, manageability, Win32 file access support, import/export, quotas, and so on. Data Model Moving beyond the core services, the Data Model provides some of the technical innovations including the basic item structure, relationships, and the ability to extend both items and relationships. Schemas Without built-in schemas, WinFS would be no better than the existing file system, since WinFS would not understand your data in richer ways or provide a more structured way to handle your data's metadata. WinFS schemas include schemas for your everyday information such as documents, e-mail, appointments, tasks, media, audio video, and more. WinFS also includes system schemas that include configuration, programs, and other system-related data. Services Synchronization and rules fall into the services area of WinFS. These technologies "sit on top" of WinFS to provide you with capabilities that extend beyond the fundamentals of the system. Synchronization will enable you to synchronize WinFS systems across a network, as well as build synchronization adapters to synchronize WinFS to other systems. For example, you may want to synchronize contact information from your CRM system to WinFS so that you can relate that data to other data in WinFS or work with that data offline through WinFS. Synchronization adapters can be bi-directional, so any changes made to the data in WinFS can be synchronized back to the other partner system. APIs As a developer, you write to APIs. WinFS includes a rich API that is part of the overall WinFX programming model in Longhorn. Through the WinFS API, you can program the different building blocks of the WinFS system including data operations, rules, synchronization, and the data model. The API that will provide programmatic access is being coded in C# or Managed C++, so .NET applications can access it, but the actual base code that will execute the functions of WinFS is coded written in C++. This is to provide WinFS with access to the Kernel of the operating system which in turn provides root access to disk management API’s which are part of NTFS.

6. WinFS Types and Extensibility WinFS's type system is tied to the .NET Framework's concept of classes and inheritance. WinFS Type Extensibility allows developers to extend WinFS by providing a schema that defines new data types and associations. These schemas are XML files, though they are not W3C XML Schema Definition, presumably because there are incompatibilities between base types (e.g. WinFS's "integer" data type is nullable, whereas XSD's integer type is not). Custom schemas can be installed on a per-application basis (in situations where an application wants to store its data in WinFS, but not share the structure of that data with other applications), or they can be made available across the system.

7. WinFS Synchronization WinFS includes support for synchronization with external data. WinFS Sync provides developers with a set of API's that allow for synchronizing with other WinFS stores (i.e. on other computers), as well as with connected devices like a mobile phone, or with Web services such as a web-mail server. WinFS Sync handles all the detail-work related to conflict detection, resolution, and error-reporting. This should allow Sync adapter developers to focus on mapping their data to WinFS as accurately as possible.

8. WinFS for Developers

9. WinFS for Developers (cont.) The WinFS store can be accessed through several APIs, and in this release an app can use ADO.NET with the SQL Server™ Provider, OLE DB with native code, a COM-based API, and a managed API. In general, developers will use the APIs rather than T-SQL, but will still have access through T-SQL because there are a number of things that you can do in T-SQL that you cannot do with the other APIs. Developers who are concentrating on .NET will use the WinFS API found in the System.Storage assembly, which contains the general WinFS API. Developers will also use the System.Storage.Schema assembly, which holds the API for the standard Longhorn types (Track, Image, Folder, Message, and so on). In addition to the common language runtime (CLR) types defined for the WinFS Items, the System.Storage.Schema assembly contains the data model mapping for the items. This mapping indicates to WinFS the data source used to access the item and the mapping from the properties of the managed type to the fields in the data store table. Deep in the bowels of the WinFS API, this mapping information is used to construct the T-SQL queries to access the item in the store. All WinFS API code has to run under an ItemContext. An ItemContext means many things. First, the WinFS API must create a connection to the store; this connection remains active while the ItemContext is active. Second, since the ItemContext represents a data connection, it provides transactional facilities. If you like, you can make several changes to the store as an atomic unit. Finally, an ItemContext describes the scope of the work that you will do by defining which items your searches will act upon. The first action that you need to take is to open an ItemContext with the static Open method. The parameterless version of Open will open the context for all items, but you can limit the scope of the context with the other overloads. WinFS uses a naming scheme that allows you to identify both the volume and a backslash-delimited path to a folder. The ItemContext provides access to the data connection through BeginTransaction and EndTransaction. BeginTransaction creates a new transaction and returns a Transaction object. Once you have done this, all the changes you make to the store will be performed under the influence of the transaction until you call EndTransaction and treat all of your changes to the store as an atomic action. It is also worth pointing out that when you have finished accessing the store you should call Close on the ItemContext to release the data connection. If you have made changes to the store, you should also call Update to ensure that the changes have been persisted to the store. For this prerelease version of WinFS, once you have created a Folder object, you should save it before attempting to insert any items into the folder. To do this you can call Folder.Save, which is merely a wrapper around ItemContext.Save.

10. WinFS Availability Early Longhorn Builds WinFS made its first appearance as an optional component in the Windows "Longhorn" builds that Microsoft was producing internally through most of 2003. At the Microsoft Professional Developers Conference that year, the first build of "Longhorn" was given to developers. This became known as the "PDC Build", or Build 4051. The general consensus from developers and reviewers was that WinFS was unusable due to excessive memory requirements, unfriendly and under-documented developer API's, and no clear indication on how it was actually going to improve the day-to-day Windows user experience. In August 2004, Microsoft announced that WinFS would not ship with "Longhorn". Latest Release and Future Development After a full year of silence from Microsoft, WinFS Beta 1 was made available to MSDN Subscribers on August 29, 2005. (Beta 1 was refreshed with no new features on December 1, 2005 to be compatible with the final release of the .NET Framework v.2.0). Microsoft has a commitment to back-port WinFS to Windows XP and 2003, and to make it available as an installable component in the same way that the .NET Framework itself is. Beta 1 only supports Windows XP with Service Pack 2. Beta 2 is planned for May 1, 2006. It will include integration with Windows Desktop Search, so that search results will include results from both regular NTFS files and WinFS-backed files. A third Beta is planned for November, 2006. The final release will most likely not be available until late 2007. The final release of WinFS will not be included with Vista and whether it will be included in Longhorn Server or not is not clear at this time.

11. WinFS Resources WinFS 101 - an official introductory article on the concept. WinFS Team Blog Channel 9 Videos - Interviews with WinFS developers at Microsoft Windows Storage Foundation (WinFS) Preview A Developer's Perspective on WinFS: Part 1 A Developer's Perspective on WinFS: Part 2 microsoft.public.windows.developer.winfx.winfs - WinFS Newsgroup