Abstract
In the recent version of Microsoft Windows, code-named "Longhorn", Microsoft presents a new storage platform named WinFS. It represents the new file system as part of the new Windows. In its conception WinFS is much more than a file system. Featuring various new concepts WinFS new data model is capable of storing non-file-data information, which is one of its most remarkable premises. In this article we explain the architecture of the WinFS data model and we demonstrate how to add its potentialities to our applications.
WinFS
With the evolution of Internet and the information technologies, working with big volumes of information has increasingly become more common. Hard disks represent the first half of the storage for personal information. They are commonly used to store personal contacts, work documents, etc. These information items usually keep certain relationship levels among them. So, when you work with a large number of these items, it is very important to organize them and provide a flexible search mechanism based on their properties and content. To address these problems, the recent Microsoft Windows code named "Longhorn" features a new storage platform: WINFS.
More than a File system
WinFS is a storage platform to organize, search and share a wide diversity of information. The following figure shows the WinFS model:
Figure 1: The WinFS model.
WinFS not only provides all the file system functionality requirements but it also adds indexing and streaming potentialities to file-based data. To access the stored files, WinFS provides a rich set of APIs including the existing Win32 API. With these facilities Win32 developers may continue using Win32 API in Longhorn and also add some query and searching potentialities to applications. WinFS extends APIs potentialities to work with non-file data including personal contacts, email messages and even other qualifying file data. The WinFS data can be structured with an XML schema to explain meaning and purpose. Data can also be semi-structured or unstructured. The entire storage platform must provide the infrastructure to organize, search and share information. When it comes to these aspects, WinFS goes beyond a traditional file system and a relational database system to support these potentialities for all types of data.
Instead of a traditional tree in NTFS to organize information, WinFS uses a direct acyclic graph of items (DAG). It is a set of stored items and their relationships whose physical storage is a relational database providing support to store any item hierarchy. With these novel storage method WinFS offers search capacities never dreamed of before in file systems. Now it is possible to find items according to the value of their properties and even to the value of the properties of items related to them.
The data-sharing capacities of WinFS come with a set of services such us synchronization, notification, a unified store and a common security model. The integration of these services to other technologies like Active Directory makes it possible for applications to share data in a flexible way.
Gathering these WinFS potentialities, we are able to obtain the necessary infrastructure to organize, search and share personal information. We may also get a framework to build applications using this information. The bottom line of WinFS is the way it stores, represents and organizes information through the WinFS data model.
Data Model
Every data models must provide concepts to describe data structures and organizations. Examples of traditional data models are the Entity Relationship Model and the File System. Similarly, the WinFS data model provides the following concepts to describe data structures and organizations:
- Types and subtypes.
- Properties and fields.
- Relationships.
- Constraints.
- Extensibility.
Types and Subtypes
Any programming environment manages concepts that represent abstraction entities of a model. A WinFS type is a template for an instance and it is composed of properties/fields. For instance, a Person type may have a name field and Peter is an instance of Person type. On the other hand, a WinFS type may have subtypes and super types which express the inheritance relationship. For example, a Document type has an Item as its super type and a Media as one of its subtypes. Every instance of a WinFS type is serialized into a WinFS store and has an associated namespace defining how it can be named to be queried. All the WinFS types derive from Base.Item type. Only single inheritance is permitted between types. When a type inherits from another type all the properties and fields of the parent types are also inherited.
Nested Elements
The closest elements to Nested Element types in programming environments are structures or records. All the Nested Element types must inherit from Base.NestedElement and can only be used as properties/fields of a WinFS Item.
Properties/fields
All WinFS types are composed of properties and fields. A field or a property may be a scalar type or a WinFS Nested Element type. The starting points of the WinFS data model are the scalar types. The following figure shows the WinFS scalar types and their SQL and .NET equivalents:
Figure 2: The list of WinFS scalar types.
As part of a type definition a field may have multiple values (known as a collection). For instance, a Person type must have multiple addresses.
All the WinFS properties and fields must express some restrictions about their content. In WinFS these restrictions are referred to as constraints. For example, a constraint may express that the name field can be null. In the current version of WinFS the constraint support is limited.
WinFS Schema Definition Language
WinFS introduces the concept of a schema definition language to describe all WinFS types. As part of the WinFS implementation, the code named "LongHorn" operating system provides a series of predefined schemas defining a set of Item and NestedElement types. WinFS Schema Definition Language is different from XSD and from other data definition languages. The following sample shows the definition of an Address Item type:
<Type Name="Address" MajorVersion="1" MinorVersion="0" ExtendsType="Core.CategorizedNestedElement" ExtendsVersion="1">
<Field Name="AddressLine" Type="WinFSTypes.nvarchar(1024)" Nullable="true" MultiValued="false" TypeMajorVersion="1"></Field>
<Field Name="PrimaryCity" Type="WinFSTypes.nvarchar(49)" Nullable="true" MultiValued="false" TypeMajorVersion="1">
</Field>
<Field Name="SecondaryCity" Type="WinFSTypes.nvarchar(49)" Nullable="true" MultiValued="false" TypeMajorVersion="1"><Notes></Notes>
</Field>
<Field Name="CountryRegion" Type="WinFSTypes.nvarchar(1024)" Nullable="true" MultiValued="false" TypeMajorVersion="1"></Field>
<Field Name="PostalCode" Type="WinFSTypes.nvarchar(16)" Nullable="true" MultiValued="false" TypeMajorVersion="1"></Field>
........
</Type>
WinFS includes a set of schemas that define an Item Type called Windows type. We can define new schemas or extend the existing ones. These two features are one of the basic extensibility mechanisms in the WinFS data model.
Relationships
WinFS manages the concept of relationship to express Items related to each other. As part of its definition, all relationships identify a source and a target type. These types are translated into type instances as part of a relationship instance. All relationships are tied to a source type. A relationship instance requires a source instance to exist. If a source instance is deleted, the relationship will also be deleted. A relationship, however, may exist without a target instance. These relationships are known as "dangling" relationships.
In WinFS there are two types of relationships: Holding and Reference. Holding relationships cannot be dangling. They control the lifetime of their target instance. That is, the target instance involved in a relationship exists as long as it has one relationship referencing it as its target. The most notable holding relationship in WinFS is the FolderMember between a file (target) and a folder (source) type. In WinFS a file can exist in multiple folders. That is, several holding relationships can exist referencing the same file as its target. If you delete one of these holding relationships, the file instance will not exist anymore in the folder representing the source of this relationship. The file, however, remains in the WinFS data storage as long as it keeps being a target in a holding relationship with another folder instance. If no folder refers to the file it will be deleted.
Reference relationships do not control the lifetime of the target instance. They may be established between instances that reside in different data storages. As Item Types relationships may have properties and fields that can be Scalar or NestedElement types. For instance, a relationship between a Person and his/her office may have properties as Startdate, Enddate and so on.
Relationships are one of the most remarkable concepts in the WinFS data model. All the programming languages use the same structure to define the fields and the relationships among classes but relationships and fields are two different concepts in the Object-Oriented theory. Now in the WinFS data model different structures define them.
Using the WinFS Data Model
The basic architecture of the WinFS data model has been illustrated above. Now in this section we look at the general use of some WinFS potentialities in applications. The WinFS data model exposes some of its functionalities to programmers as part of the WinFS CLR/COM API. This API allows for the use of objects in a CLR managed language or in a COM native language. Developers can add WinFS potentialities like queries, navigation and events to their applications.
All the Windows types defined as WinFS schemas have an equivalent class in the WinFS API. These classes are known as data classes, for example, Service, FullName, etc. In Longhorn there are 28 schemas with their corresponding data classes in the WinFS API. The existence of data classes reflects the object-oriented approach in the WinFS philosophy. We can define new schemas to extend the existing ones in WinFS and generate the equivalent .NET and COM classes for further use in future applications.
Searching
One of the pillars of all storage platforms are the searching capabilities. To complement its robust storage mechanisms, WinFS provides a broad spectrum of searching functionalities. We can develop searching operations over WinFS storages in a variety of ways. This is a code example on how to list all the Contacts in WinFS store.
In the above example we have followed a simple search pattern in WinFS by using the Open method of the ItemContext class where ItemContext represents an aspect of the WinFS model to identify a WinFS item domain. This context represents the current WinFS store in which one can find contacts, print names and finally get it closed. Obviously, this is a very simple search sample that would require for more powerful search possibilities in a complex model.
WinFS increase its search potentialities using the OPATH language, an object query language used to perform complex queries against a WinFS storage. As part of its implementation, OPATH addresses such search aspects as filtering objects by using their primitive field values or pattern matching. The following sample shows how to find all Folders whose names contain the word "Windows".
ItemContext context= ItemContext.Open();
FindResult result= context.FindAll(typeof(Folder), "DisplayName like '%Windows%'");
foreach(Folder f in result)
Console.WriteLine(f.DisplayName);
context.Close();
By using the OPATH language we can perform complex search operations reflected as queries among Items in a WinFS store.
Navigating relationships
Over relationships we can perform search operations the same as over Items. This simply constitutes one of the most powerful benefits of the WinFS data model. In a traditional object-oriented programming language we express the relationship among objects in the same way we define fields in a class. Now in WinFS we can find authors of documents or documents written by specific authors among other queries involving item relationships.
Notifications
WinFS often stores a great variety of items related to each other. In some cases it is very important to act against a modification on an item. WinFS addresses this issue and presents a mechanism capable of notifying the changes or delete actions when they take place on items. Notifications on WinFS follow the same CLR event patterns. The main class for the use of WinFS notifications is the ItemWatcher class. The following sample shows a program that subscribes to notifications on one Contact Item and prints a message when the contact has changed.
public class DataModelTester
{
private static ItemContext context= ItemContext.Open();
public static void NotificationTest()
{
Contact ActualContact= Contact.FindOne(context, "");
Console.WriteLine(ActualContact.DisplayName);
ItemWatcher watcher= new ItemWatcher(ActualContact);
watcher.ItemChanged += new ItemChangedEventHandler(ChangeContactHandler); ChangeItem(ActualContact);
context.Close();
}
private static void ChangeItem(Item target)
{
Console.WriteLine("Change the name of the item...");
target.DisplayName= "New Name" + Guid.NewGuid().ToString();
Console.WriteLine("The new name is:");
Console.WriteLine(target.DisplayName);
}
//this is the handler of the contact
public static void ChangeContactHandler(object source, ItemChangedEventArgs e)
{
Console.WriteLine("The Contact changed...");
}
static void Main(string[] args)
{
DataModelTester.NotificationTest();
}
ADO.NET and WinFS
Although OPATH language represents a powerful mechanism to perform search operations, WinFS provides an OLEDB and ADO.NET data access API to query a WinFS store. The main component of this relational data access API is the T-SQL language holding possibilities to make queries in a SQL based manner over the WinFS store. Using this feature we can consume WinFS data in a tabular manner. We can use this functionality in applications that need to consume the WinFS data with a high control level and adapt the results to the most heterogeneous environments.
Conclusions
WinFS data model expresses a set of modern storage concepts featuring a combination of the file system services and the relational system to provide a new powerful and enhancing storage platform. This actually elevates the file system conception to a higher level. The WinFS Item may be expressed in XML, object-oriented or tabular manner which allows the WinFS functionalities to be used in a variety of heterogeneous environments. In addition to this, WinFS features a powerful API to develop applications that use its potentialities. Due to its conception WinFS data model represents a step forward in the evolution of file systems and even of storage platforms.