What Is the Web Storage System?

[Previous] [Next]

You might have heard the term Web Storage System. What does the Web Storage System technology mean for you as a developer? For the past few years, Microsoft's Exchange Server group has been developing a great data storage technology. The one problem with this database technology is that it shipped only with Microsoft Exchange Server, so it was limited to products bearing the Exchange Server name. However, Microsoft has since renamed this database technology Web Storage System and ripped it out of Exchange Server. Not only is the Web Storage System technology now identifiable by name, it can be embedded into other Microsoft products. This means you can use the Web Storage System in situations that require a rich, semi-structured, Web-aware database you can access from a number of different client access methods. Furthermore, the Web Storage System technology provides a rich set of development services, which we'll look at in this chapter.

Exchange Server 2000 will be the first Microsoft product to ship with the Web Storage System technology. Following Exchange Server 2000, you'll see a number of other products shipping with this technology. If you learn the basics of Web Storage System development now, you'll have a great foundation for building applications on both Exchange Server 2000 and other products that ship with the Web Storage System.

Enough background. Let's talk about the core features of the Web Storage System technology. The core features 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 that it provides a native OLE DB 2.5 provider. This allows developers to write directly to OLE DB interfaces to get or set information contained in the Web Storage System. Furthermore, it allows developers 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. Since the Web Storage System is tightly integrated with Microsoft Internet Information Services (IIS), the Web Storage System can provide rich access to data over Web protocols such as Hypertext Transfer Protocol (http). However, standard http commands, such as GET and POST, cannot provide you with 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 could create a new folder in the Web Storage System, create a new item in that folder, and then query for the new item using WebDAV and requests formatted in a specific XML format that WebDAV understands. You'll see some examples of using WebDAV in the next chapter when we examine the Training application.

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 via Microsoft Windows Explorer. Furthermore, 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 later in the chapter will show you some ways you can use the IFS provider in your applications.

Programmability Features

The Web Storage System allows both 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. This section will give you an overview of each of these areas; you'll see more in-depth coverage when we look at the Training application.

Schema Support

Built directly into the Web Storage System is an extensive array of schema support. By having the ability 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 that of objects that support certain properties. The Web Storage System defines some built-in schemas you can take advantage of, such as a schema for an object or an item. Exchange Server 2000 specifically defines a schema for messages, appointments, and contacts.

One of the neat things about the Web Storage System schema support is that schemas are inheritable. This means that 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 the correct properties will be returned when you submit searches using the SQL SELECT * syntax. This allows other application developers to simply traverse the ADO fields collection rather than know the actual names of your properties. For performance reasons, however, you might not want applications that use SELECT *, because the Web Storage System will have to 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.

Even though using schemas isn't required to build applications on the Web Storage System, I highly recommend that you use schemas in your applications, as appropriate. Most of the time, using schema 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 are lost if the item is deleted. Furthermore, you might find creating a schema more tedious than simply appending new fields onto the item using ADO. The code for the workflow process in the Training application will show you an example of this. In that sample, it was easier to just 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 chapter 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 is divided into 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 need to add some special markup to your HTML-based forms, indicating to the Web Storage System that the fields you're requesting in your form should be pulled from your Web Storage System application. We'll drill into what this markup actually consists of when we look at the Web Storage System form used in the Training application.

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. Since Web Storage System forms support both standard HTML 3.2 browsers and XML-aware browsers, data binding can occur in one of two places: on the server or on the client. For HTML 3.2 clients, you'll want to do your data binding on the server. This forces the Web Storage System to pull the values for the fields in the form, perform the data binding on the server side, and return only the form's HTML 3.2 representation.

For XML-aware browsers, such as Microsoft Internet Explorer 5, 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 side rather than on the server side. This allows you to provide easier manipulation of the data without having to make an extra round-trip to the server each time. For example, you could 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. Since 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. This flexibility allows you to build different forms for different clients. For example, you could create a microbrowser form for cell phone clients browsing your application using the Microsoft microbrowser technology. We'll look at the forms registry in more detail when we examine the Training application.

Web Storage System Events

Exchange Server 5.5 introduced an event mechanism that allowed application developers to write code to handle events occurring in the Exchange Server database. The Web Storage System further improves on this concept. In Exchange Server 5.5, events are asynchronous, meaning that the event fires after the item is committed to the database. The Web Storage System also supports asynchronous events; however, it supports synchronous and system events too. 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 could 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, and you can use it to retrieve and set data. We'll look at the XML support of the Web Storage System more closely in the Training application.

Security Features

Since information security is always a major concern for developers and users, 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 2000 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 (TLH), and a set of management objects that allow you to programmatically manage information in Active Directory and the Exchange Server 2000 Web Storage System. Let's take a look at each of these features.

MAPI Support

Exchange Server 2000 continues to fully support the MAPI interfaces. This means clients that use MAPI, such as Microsoft Outlook 2000, will run against the Web Storage System without modification. As an application developer, you should realize that the applications you have written to MAPI will continue to work. As always, you should nevertheless test your applications to ensure that all functionality continues to behave as expected.

Multiple Top-Level Hierarchies

You might be wondering what a top-level hierarchy, or TLH, is. A top-level hierarchy is simply a tree of folders that has a top-level root folder. So 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, Microsoft has enabled you to have TLHs besides the Public Folder one in your Exchange Server environment. This support allows you to break your applications into multiple hierarchies so that users can avoid crawling through the Public Folder tree to find the desired application. 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 will need to keep your application in the Public Folder hierarchy. Outlook cannot view hierarchies other than the Public Folder hierarchy.

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

Figure 18-1. The Exchange System Manager with multiple TLH support. Multiple TLHs greatly benefit application developers.

CDO for Exchange Management

To provide a programmatic way for developers to manage recipients and servers, the new version of CDO in Exchange Server 2000 has been extended with a set of management objects called CDO for Exchange Management Objects (EMO). With EMO, you can create, modify, or delete recipients or groups of recipients. Furthermore, with EMO you can manage the structure of the information stored in Exchange Server 2000. Notice 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. Instead, you should 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.

You'll want to use EMO where appropriate in your applications. Furthermore, if you plan to write any administration components for Exchange Server 2000, such as Microsoft Management Console (MMC) snap-ins, you'll need to learn about and use the EMO object model. We won't discuss EMO any further in this chapter because its interfaces are so straightforward. However, I will point you to the Exchange Server Software Development Kit (SDK), included on the companion CD, so you can learn more about it.

Outlook Web Access

The Web Storage System in Exchange Server 2000 directly supports a new version of OWA. OWA is no longer based on Active Server Pages (ASP) as in previous versions. Instead, the OWA code is directly compiled into the Exchange Server, and the HTML files are generated by the server instead of by interpreted script running on IIS.

There are also a number of enhancements to OWA that you should be aware of. The most significant one is that different versions of OWA exist for different browsers. For non-Internet Explorer 5 browsers, OWA uses standard HTML 3.2 to render information from Exchange Server, as shown in Figure 18-2. In this case, all HTML rendering and data binding take place on the server side.

If you are using Internet Explorer 5, OWA and the Exchange Server are smart. Instead of forcing all the rendering and data binding to occur on the server, OWA takes advantage of the XML and WebDAV support in Internet Explorer 5 to offload processing and rendering to the browser. OWA will push down Exchange Server data as XML and will utilize Internet Explorer to format the XML data by using extensible style sheets (XSL). If the user needs a different set of data, OWA will request only the data from the server and won't have to reload the entire page in the browser. By doing this, the Internet Explorer 5 version of OWA saves you round-trips to the server to re-sort or group the existing XML data on the client. Furthermore, if data is needed from the server, OWA is efficient at retrieving just that data rather than the entire page. Figure 18-3 shows the new version of OWA. Later in this chapter, you'll see how to extend OWA by using URL parameters and Web Storage System forms.

Figure 18-2. The Netscape Navigator version of Outlook Web Access.

Figure 18-3. The Internet Explorer 5.0 version of OWA. This version supports XML and WebDAV.

What About Exchange Server 5.5 Applications?

You might be wondering what will happen to the existing Exchange Server 5.5 applications you've written using MAPI, CDO, ADSI, or even the Event Scripting Agent. Have no fear—those applications should continue to run without modification, except for some cases that I'll describe here.

First, MAPI, CDO 1.21, and the Event Scripting Agent are all supported by Exchange Server 2000. Microsoft even supports running the Exchange Server 5.5 version of OWA against Exchange Server 2000. This demonstrates that CDO 1.21 works fine with Exchange Server 2000. In terms of MAPI support, Outlook 2000 uses MAPI and since Outlook continues to work with Exchange Server 2000, it shows how MAPI still works as well.

If you've written applications that use the Directory API (DAPI), you'll need to rewrite your code to use ADSI since Active Directory replaces the Exchange Server directory in Exchange Server 2000. Furthermore, if you've written administration extensions to the Exchange Server administration program, you'll need to rewrite these extensions to the MMC since this is the way you administer Exchange servers.

The major hurdle of moving your Exchange Server 5.5 applications to Exchange Server 2000 is the conceptual differences between the two versions of Exchange Server. While you can continue to run your Exchange Server 5.5 applications as is on Exchange Server 2000, you'll at least have to look at the features of Exchange Server 2000 to see where you can enhance your existing applications. For example, if you have an Outlook forms-based application, you might want to extend it using the new server events in Exchange Server 2000 to add workflow or other functionality. Throughout the rest of this chapter, we'll look at the new features Exchange Server 2000 offers developers. If you have Exchange Server 5.5 applications, as you read this information, look for ways to enhance or migrate existing parts of your applications to Exchange Server 2000.