• Illustration: WinFS and NTFS Compatibility
• Sidebar: Evaluating Prerelease Code

The first WinFS beta, released Sept. 2005, gives developers an opportunity to evaluate the planned data and file management service for Windows. WinFS offers a single database for organizing conventional files as well as data records, such as contacts and tasks. Such a database could help users rapidly locate data and share information across multiple applications. However, this early beta lacks the user interface and management components that IT departments would need to evaluate WinFS and compare it with existing file system and database technologies.

Unifying Data and Files

WinFS is a data management system for the Windows OS that can store both individual database records (such as a contact or task record) and complete files in a single store. WinFS operates on top of the NT File System (NTFS), the primary Windows file system, and provides additional organization, search, and management features.

WinFS databases (called stores) combine features of file systems, relational databases, and directory services such as Active Directory (AD). A WinFS store contains items, or data objects with properties. An item can be any of the following:

• A single data record (such as a contact or task)
• A complete file and its properties (such as a digital photo with "date taken" and "dimensions in pixels" properties), called a file-backed item
• A container that holds other items, similar to a Windows folder or AD container object.

WinFS can also store associations or relationships between items; for example, an association between a container and an item it contains, or between a contact item and a photo item that depicts the contact. WinFS provides a query engine and a query language (called OPath) for locating items by their properties and associations.

The WinFS data model offers users more options for organization and search than the fixed folder hierarchy of a Windows file volume. For example, a user could search a WinFS store for all documents related to a particular project, or all documents authored by a particular contact, regardless of where the documents were located in a container hierarchy.

However, the Sept. 2005 first beta does not include an out-of-the-box user interface for organizing or querying WinFS stores. Consequently, it is difficult to say how much WinFS will simplify finding data compared to a conventional file system with full-text search utilities, such as MSN Desktop Search. (For more information on technology previews and betas, see "Evaluating Prerelease Code".)

Extensible for Applications

WinFS item classes and properties are defined by schemas, similar to but distinct from the schemas used for relational databases and XML documents. Microsoft has defined standard schemas for commonly used item classes, including documents, e-mail messages, calendar items, contacts, and tasks. However, application developers can extend these schemas or create their own, enabling WinFS to store an application's specific data types and files.

Standard schemas from Microsoft could simplify sharing of data across applications. For example, an e-mail client, instant messaging client, and customer relationship management system might all work from a single store of WinFS contacts, reducing the need for users to move or synchronize data among these applications. In addition, by supporting new schemas, WinFS can accommodate any application data, so in principle it could give users a single place to store and manage all their application data, compared with the multiple application files, databases, and registry keys that users must manage today. Of course, data sharing and unified storage depend on adoption of WinFS by application developers.

Query, Synchronization Services

In addition to providing data organization and query, WinFS delivers services that can automatically organize data and maintain data integrity across multiple devices or applications. The goal of these services is to handle common data management tasks, reducing the number of data-management interfaces that users must use and developers must write.

The two most important services in the beta are as follows:

Stored queries and rules. WinFS can include stored queries, components which monitor the WinFS store and notify applications when WinFS items are added or deleted that meet specific criteria. Similar in concept to Outlook search folders, stored queries could be used to notify users of important changes, such as the addition of a document intended for review by the user. WinFS also supports rules, stored queries for automating calculations (such as automatically calculating a contact's full name from first name and last name). Note that unlike Outlook rules or database triggers, WinFS rules only calculate; they do not make changes to the store.

Synchronization. Another WinFS service synchronizes items between WinFS stores, moving only changed data for efficiency and notifying applications of data conflicts between the stores. Developers can extend the synchronization service with application-specific rules for resolving data conflicts, or with adapters for synchronization between WinFS and other data sources. For example, an adapter might synchronize WinFS contacts with those on a user's phone, or with a contact list in an existing desktop contact management application.

Note that the WinFS Beta 1 does not provide a Windows user interface for stored queries, rules, or synchronization, although it ships with sample applications and tools (such as a command-line synchronization utility). Beta 1 also lacks utilities for storage management tasks such as backup, restore, defragmentation, or space reporting. Consequently, it will be difficult for anyone but application developers to evaluate WinFS shared services or evaluate how useful WinFS is for specific purposes. Developers will also have to compare the WinFS shared services against those provided by existing embedded database engines. For example, both the Microsoft Jet engine (used in Access) and the SQL Server engine provide types of synchronization, and SQL Server also provides triggers that can do some of the tasks of WinFS rules.

Compatible with Windows Files, APIs

Behind the scenes, WinFS stores are kept in NTFS. The properties of a WinFS file are stored in WinFS, but a WinFS file's data can be stored in either a WinFS store or in an NTFS file. In the latter (file-backed) case, an NTFS extension installed with WinFS maintains consistency between every file-backed item in WinFS and its corresponding NTFS data file so that (for example) moving the data file in NTFS does not break the link to the file-backed item.

Applications can access WinFS by one of two API sets. First, WinFS is accessible through ADO.NET, the standard data-access API of the .NET Framework development platform. In addition, WinFS implements the conventional Win32 file APIs for access to file-backed items. That means that existing Win32 applications and utilities can work on file-backed items in a WinFS store. For example, Windows Explorer can be used to copy NTFS files to and from WinFS file-backed items. However, the Win32 API does not provide full access to WinFS: it can only be used to access file-backed items and containers, it does not support any item properties other than the standard NTFS ones, it does not support querying, and it does not provide services such as synchronization. The ADO.NET API, in contrast, provides full access.

(For a graphical view of these relationships, see the illustration "WinFS and NTFS Compatibility".)

Developers First, Organizations After

Overall, WinFS is at such an early stage of development that it will interest application developers more than IT administrators or end users.

Developers can use the beta release to determine how WinFS might be used in their own applications. This gives them ample time to provide feedback to Microsoft about the additional features they need from WinFS while there is still time for Microsoft to act on their requests. Developers can also compare the WinFS data model and services with existing data engines, such as Jet and SQL Server.

IT administrators can't really evaluate WinFS based on the current beta. Without utilities for management tasks such as backup and restore, and without information on how WinFS will work with file server technologies, such as the Encrypted File System (EFS) and the Distributed File System (DFS), and replication engines, it's difficult to tell whether WinFS will be simpler to manage than today's file systems and databases.

End users will have to wait for a more complete beta release to tell whether WinFS really solves its target problems better than today's technologies. Without a user interface for querying and organizing WinFS stores, it is hard to tell whether WinFS search and organization will be markedly better than conventional file systems combined with full-text indexing and search. The question is particularly important, because the Windows Desktop Search indexing and search component is already available and will be integrated in Windows Vista when the OS ships in 2006.

At the earliest, a WinFS user interface and management utility set could appear in Windows versions in the Windows Longhorn Server timeframe (2007). However, the first beta of Longhorn Server does not include WinFS support. A more realistic WinFS release vehicle might be Windows Vista R2, the client OS version tentatively planned for 2008.

In the end, WinFS will be useful only when applications use it. Microsoft could start this process by adopting WinFS in its own applications, particularly the widely used Office suite. However, Office 12, due in 2006, does not employ WinFS; a version of Office that supports WinFS is unlikely to appear before 2008, with 2009 more likely.

Resources

Further developer information and the beta download (MSDN subscribers only) are at msdn.microsoft.com/data/winfs.

The WinFS team blog is blogs.gotdotnet.com/winfs.