The Web Storage System

You might have heard of the Web Storage System, but you might not know what this technology means for the developer. For the past few years , Microsoft's Exchange Server group has been developing a great data storage technology, but until now it has shipped only with Exchange Server. Microsoft has renamed this database technology Web Storage System and ripped it out of Exchange Server. Not only is this technology now identifiable by name , but it can also be embedded into other Microsoft products. This means that you can use the Web Storage System in situations that require a rich, semistructured, Web-aware database that you can access from a number of client access methods . Furthermore, the Web Storage System technology provides a rich set of development services.

Exchange Server 2000 was the first Microsoft product to ship with the Web Storage System technology. Then SPS 2001 shipped with the Web Storage System. You might see the Web Storage System referred to as the Exchange store in Exchange Server and as the document store in SharePoint. It's pretty much the same technology despite the different names .

Enough background. Let's talk about the core features of the Web Storage System technology. They fall into three main areas: data access, programmability, and security.

Data Access Features

One of the major new data access features of the Web Storage System is a native OLE DB 2.5 provider. This provider allows developers to write directly to OLE DB interfaces to get or set information contained in the Web Storage System. It also allows developers who are familiar with ADO to write ADO applications using the Web Storage System as the data store. We'll look closely at the ADO 2.5 support provided by the Web Storage System later in this chapter.

Another data access feature is Web Distributed Authoring and Versioning (WebDAV) support. The Web Storage System is tightly integrated with IIS, so it can provide rich access to data over Web protocols such as HTTP. However, standard HTTP commands, such as GET and POST, do not provide a rich enough set of features to build collaborative applications. For this reason, the Internet Engineering Task Force (IETF) came up with WebDAV ”extensions to HTTP 1.1 that allow you to move, copy, query, and delete resources. For example, with WebDAV, you can create a new folder in the Web Storage System, create a new item in that folder, and then query for the new item using requests formatted in a specific XML format that WebDAV understands. You'll see some examples of using WebDAV in Chapter 16.

The final way ”and in my opinion, one of the most interesting ways ”to get data from the Web Storage System is by using its Installable File System (IFS) provider. The IFS provider allows you to provide access to your data in the Web Storage System using standard file system programs or interfaces. For example, you can make the documents you create in the Web Storage System available to your application users through Windows Explorer. And without having to write a single line of code, you can turn any file system “aware application into an interface for your application's data. The Training application we'll look at in Chapter 15 will show some ways you can use the IFS provider in your applications.

Programmability Features

The Web Storage System gives Web and Windows developers a great amount of flexibility in their programming. Programmability features fall into five key areas: schema, form, event, workflow, and XML support. The upcoming sections will give you an overview of each of these areas; you'll see more in-depth coverage when we look at the Training application in Chapter 15.

Schema Support

Built directly into the Web Storage System is an extensive array of schema support. By being able to create a schema, developers can define sets of properties that are common to a certain type of item in the Web Storage System. Such support is similar to object support for certain properties. The Web Storage System defines some built-in schemas, such as a schema for an object or an item. Exchange Server 2003 specifically defines a schema for messages, appointments, and contacts.

One great thing about the Web Storage System schema support is that schemas are inheritable. This means you can inherit schema properties from another schema collection and extend the inherited properties with your own properties. For example, suppose I want to create a customer schema definition that includes properties similar to those of the built-in contact schema as well as some custom properties for my application. I simply tell the Web Storage System that I want to inherit the properties from the built-in contact schema and extend it with my own properties.

By creating a custom schema, you are guaranteed that all of the properties will be returned when you submit searches using the SQL SELECT * syntax. This allows other application developers to traverse the ADO fields collection instead of having to know the actual names of your properties. (For performance reasons, however, you might not want applications that use SELECT * because the Web Storage System must return all the properties on the items contained in your search. For most Web Storage System items, this can be in excess of 100 properties for each item!)

Even though you're not required to use schemas to build applications on the Web Storage System, I highly recommend that you do, when appropriate ”and most of the time, using schemas will be appropriate. However, using a schema might not make sense if you're only creating a one-off, single-use item for which you don't care whether the properties are reused on other items or for which the property definitions will be lost if the item is deleted. Furthermore, you might find that creating a schema is more tedious than simply appending new fields onto the item using ADO. This is the case in the code for the workflow process in the Training application in Chapter 15; it is easier to append items onto the process instance in the workflow than to create a full-fledged schema definition for the process instance itself. However, you'll see other code samples in this book in which schema and their definitions play an important role.

Web Storage System Forms

The Web Storage System supports an HTML-based forms technology. This technology has three key components : HTML markup for the forms, a server-side Internet Server API (ISAPI) filter, and a forms registry.

To create Web Storage System forms, you must add some special markup to your HTML-based forms that indicate to the Web Storage System that the fields you're requesting in your form should be pulled from your Web Storage System application. You'll see what this markup actually consists of when we look at the Web Storage System form used in the Training application in Chapter 15.

Beyond client-side markup, the Web Storage System forms technology also includes a server-side ISAPI extension. This extension captures requests sent to your Web server and checks to see whether the Web browser is requesting an item that has an associated Web Storage System form. If the item does have an associated Web Storage System form, the ISAPI extension finds that form and returns the form to the Web browser. Web Storage System forms support both standard HTML 3.2 browsers and XML-aware browsers, so data binding can occur in one of two places: on the server or on the client. For HTML 3.2 clients , you should perform data binding on the server, which forces the Web Storage System to pull the values for the fields in the form, and return only the form's HTML 3.2 representation to the client.

For XML-aware browsers, such as Internet Explorer 5.0 and 6.0, you can perform server-side or client-side data binding. If you perform client-side data binding, the forms engine will return the form and you can perform the data binding on the client. This allows you to provide easier manipulation of the data without having to make an extra round-trip to the server each time the form needs to be updated. For example, you can re- sort or change the format of the data representation to suit your application's needs without incurring the cost of returning to the server to do this.

The final component of the Web Storage System forms technology is the Web Storage System forms registry. By allowing you to specify which forms should appear for specific items, the Web Storage System enables you to customize the default renderings of items. Each built-in item has some default forms that will be rendered for it. Because the forms registry is flexible, you can register forms based on the browser type requesting the item, the language of the browser client, or the type of item that the user requests from the Web Storage System. You can thus build different forms for different clients. For example, you can create a microbrowser form for cell phone clients that browse your application using the Microsoft microbrowser technology. We'll look at the forms registry in more detail when we examine the Training application in Chapter 15.

Web Storage System Events

Exchange Server 5.5 introduced an event mechanism that allows application developers to write code to handle events occurring in the Exchange Server database. The Web Storage System improves on this concept. In Exchange Server 5.5, events are asynchronous, which means that the event fires after the item is committed to the database. The Web Storage System supports asynchronous events, but it also supports synchronous and system events. Synchronous events fire before the item is committed to the database, enabling your application to decide whether the item should be committed or aborted (in which case the item won't be saved). Synchronous events guarantee that the application is the only process making this decision for the item. Users or other processes are blocked until the application finishes processing. The system events notify the applications about key occurrences in the Web Storage System ”for example, a system event might fire after the Web Storage System starts up. Developers can write code to either begin replication or start processing their custom application when this event occurs. These two new classes of events allow you to build even richer applications on the Web Storage System.

Workflow Support

A workflow application is an excellent example of an application you can build with Web Storage System events. The Web Storage System ships with a built-in workflow engine that uses synchronous and system events to perform its functionality. This built-in workflow support enables developers to start writing workflow applications as soon as they obtain a product containing the Web Storage System.

XML Support

The Web Storage System is very Web-centric, which explains how it got its name. The Web Storage System natively supports XML which you can use to retrieve and set data. We'll look at the XML support of the Web Storage System more closely in Chapter 20.

Security Features

Information security is always a major concern for developers and users, so the Web Storage System supports securing data at both the item level and the property level. This allows you to select which users or groups of users can access data contained in the Web Storage System. Furthermore, you can query or modify this access programmatically.

Additional Features

Besides the standard Web Storage System features, Exchange Server 2003 provides some additional features in its implementation of the Web Storage System technology. These features include Messaging Application Programming Interface (MAPI) support, multiple top-level hierarchies (TLHs), and a set of management objects that allow you to programmatically manage information in Active Directory and the Exchange Server 2003 Web Storage System. Let's take a look at each of these features.

MAPI Support

Exchange Server 2003 continues to fully support the MAPI interfaces. This means clients that use MAPI (such as Outlook) run against the Web Storage System without modification. The applications you have written to MAPI will continue to work, but you should test your applications to ensure that all functionality continues to behave as expected.

Multiple Top-Level Hierarchies

A TLH is simply a tree of folders with a top-level root folder. For example, the Public Folder hierarchy that starts with Public Folders and continues to All Public Folders is a top-level hierarchy. To make application development easier, Exchange Server 2003 lets you have TLHs other than the Public Folder hierarchy. You can thus break your applications into multiple hierarchies so users can avoid crawling through the Public Folder tree to find the application they need. This change also makes it easier for administrators to manage your applications because they can separate the applications into independent TLHs. You should, when possible, place your applications in a top-level hierarchy other than the Public Folders hierarchy because other top-level hierarchies provide more functionality. However, if you require Outlook access to your application, you must keep your application in the Public Folder hierarchy. Outlook cannot view hierarchies other than the Public Folder hierarchy.

Figure 2-27 shows the Exchange System Manager (which replaces the Exchange 5.5 Administration program) displaying multiple TLHs on a single Exchange server. Notice that the multiple TLHs also allow developers to place applications into different naming contexts.

Figure 2-27: The Exchange System Manager with multiple-TLH support

CDO for Exchange Management

To provide a programmatic way for developers to manage recipients and servers, CDO in Exchange Server 2000 and later contains an extended set of management objects called CDO for Exchange Management Objects (EMO, or CDOEXM). With EMO, you can create, modify, or delete recipients or groups of recipients, and you can manage the structure of the information stored in Exchange. Notice that I said structure and not content . EMO doesn't give you the ability to create items, change properties, or perform other such content- related tasks . You must use CDO and ADO to attain such functionality. EMO is there to help you create storage groups and folder hierarchies, as well as change storage quotas and deleted-item recovery periods.

If you plan to write any administration components for Exchange Server, such as Microsoft Management Console (MMC) snap-ins, you'll need to learn about and use the EMO object model. The Training application makes heavy use of EMO when working with Exchange Server to allow you to create new storage groups, folder databases, hierarchies, and virtual roots. We'll look at CDO for Exchange Management in Chapter 18.

Exchange Server Web Services Support

Exchange Server Objects (XSO) is the next generation of programming interfaces for Exchange built using XML Web services technology. The technology under XSO is actually a higher-level object model on WebDAV. In Chapter 14, we will look at wrapping Exchange Server object models with your own Web services interfaces so you do not have to wait for XSO and can start writing applications that leverage Web services against Exchange today.