Industrial-Strength Object Database

At its core, Exchange Server is an object database. This object database is highly scalable, replicated, built for 24-hour availability 7 days a week, and can hold many different types of objects, including messages, Microsoft Office documents, video files, voice mail, faxes, hyperlinks, text documents, custom forms, and applications such as executable files. You can store all of your application's data in the database while replicating the information to other locations, so the application and its relevant information are available anytime, anywhere. Core features of the Exchange Server database are discussed in the following sections.

Huge Storage Capacity

Many collaborative applications require large amounts of data to be available anytime. Exchange Server makes an excellent repository for this data because it can handle large amounts of information and ensure the reliability and availability of that information. Exchange Server supports very large databases—up to 16 terabytes (16,000 gigabytes) of information. That's pretty big considering that if you compiled every Wall Street transaction in history, you'd have only a little more than 1 terabyte. Really, the only factor limiting the size of your database is the hardware you run Exchange Server on. The database can run continuously because it has online defragmentation and allows backup programs to work with the database, even when users are logged on.

Exchange Server can store many different types of objects and their associated data in the same database. These objects can even be in the same table, or folder (as tables are called in Exchange Server). Users simply drag and drop different types of objects into these folders, and Exchange Server adds them to the database. This flexibility gives you a distinct advantage when developing applications. Figure 3-4 shows a folder in Outlook with many different types of objects.

Figure 3-4 The Exchange Server database is an object database and can hold many types of objects in a single folder.

Multiple Views

The Exchange Server database not only supports multiple objects in a single folder but multiple views of those objects. You can customize views of the objects stored in the folder by sorting, grouping, and filtering the objects using any combination of their properties. For example, you can customize the view of an Exchange Server folder containing Office documents by specifying Office properties, as shown in Figure 3-5. Even custom properties can be columns in a view, and you can use them to sort and group items in the view.

Figure 3-5 Views support using properties from Office documents. Your applications can use these properties for sorting, grouping, and filtering.

Exchange Server also supports "per-user" views that allow individual users to create custom views. Exchange Server actually maintains for each user the initial view of the folder, the status of read and unread items, and whether a particular grouping is expanded in the view. Figure 3-6 shows a single view of an Exchange Server folder but for different users. Notice how different the views look. Views can also be replicated offline by using Exchange Server's built-in replication features.

Figure 3-6 The initial view of the same discussion folder for two different users. Notice that certain groups are expanded and certain items are marked as read.

Built-In Replication

The Exchange Server database is a replicated database, enabling replication from Exchange Server to Exchange Server and from Exchange Server to Outlook on the client machine. Exchange Server even supports filtered replication between the server and the client.

Replication in Exchange is not the same as simple duplication. Exchange Server replication is more similar to the concept of synchronization in that only the changes are sent to replicas in the system. Sending only the changes, as opposed to copying the entire folder for each replication cycle, saves time and network bandwidth.

Setting up server-to-server replication with Exchange Server is easy. All the administrator has to do is select the folder to be replicated and then select the server to replicate the folder to. The settings that enable server-to-server replication in the Microsoft Exchange Administrator program are shown in Figure 3-7. Once these settings are in place, the actual replication messages are sent over the Exchange Server messaging infrastructure. This allows the replication messages to leverage Exchange Server's load balancing, least-cost routing, and failover capabilities. Exchange Server also supports setting the time and size limits of the replication messages.

Figure 3-7 Setting up server-to-server replication for your applications in Exchange Server is as easy as pointing and clicking in the Exchange Administrator program.

The Exchange Server replication feature has built-in conflict management capabilities that enable users to edit the same information at the same time in the same folder or even in replicas of a folder in different locations. To determine which item to accept as the newest, Exchange Server implements "last saved wins," the process of querying the time an item was saved and retaining the most recently saved item. You can also set an option that alerts users via e-mail when items are in conflict. Both versions of the item are sent to these users, and they can decide which item is the most up-to-date. Exchange Server will keep the item they select.

For server-to-client replication, Exchange Server and Outlook support bidirectional synchronization of changes to information in Exchange Server folders. This synchronization occurs in Outlook as a background process, so users can continue working in Outlook. The synchronization can be scheduled so that it happens at certain intervals. For example, a user can configure Outlook replication so that every 30 minutes the Outlook client synchronizes its local database with new information from the Exchange Server.

Outlook also supports filtered replication, in which only a subset of information is synchronized to the local database. Filtered replication is most useful to users when large amounts of data are available in the Exchange Server database but users want to take only a subset of that data offline. For example, imagine an Exchange Server folder with 50,000 sales contacts. A typical user wouldn't be able to accommodate the entire folder on her local hard disk, so she could set the replication criterion to only those contacts for whom she is the sales representative. Instead of 50,000 contacts, the filtered subset is 1,000 contacts. Figure 3-8 shows the interface in Outlook where users can set the criteria for filtered replication.

Figure 3-8 Setting up filtered replication in Outlook is easy for users of your application.

Schema Flexibility

Typically, when you begin work on an application that deals with a database, you are forced to plan your schema for the database before you start writing your application. If the application requirements change and a new field has to be added to the database, the schema might not be flexible enough to support the addition, and you might have to drop the present database and create a new one.

With the Exchange Server database, however, you can add new fields at any point in development, which allows you to accommodate the changing requirements of an application. New fields are automatically available to users, so users can create custom views using them.

Transaction Logging

A transaction is a unit of work, such as adding an item to an Exchange Server database. Before any item is committed to the Exchange Server database, the transaction is written to a transaction log file and then to the database. This process is called write-ahead transaction logging, and it guarantees that no item will be lost.

Transaction logs allow the Exchange Server to recover the database after some form of failure, such as a power loss. In this type of scenario, after power is restored and the server is rebooted, the Exchange Server automatically recovers the database. Using checkpoints in the transaction logs, the Exchange Server replays any transactions that were not committed to the database before the power failure.

The transaction log is an inherent feature of the Exchange Server database, so any application you develop on Exchange Server can take advantage of it. Any items your application sends or stores in the Exchange Server system will be delivered or committed, even in the event of certain failures in the computer system or network.