For years, a vibrant debate has gone on between Microsoft engineering groups as to the merit of different database engines. This debate has been especially fierce concerning Microsoft Exchange Server. Exchange 2000 Server uses the Extensible Storage Engine 98 (ESE98) database engine, and Exchange Server 5.5 uses the ESE97 engine.
Extensible Storage Engine (ESE) is a variant of the Jet database engine that appears in products such as Microsoft Access. (Microsoft also uses a variant of ESE in Windows 2000's Active Directory—AD.) Microsoft designed this database engine to handle the demands of a messaging system. Typical database environments tend to work through highly structured transactions, but such isn't the case with a messaging server. One message can have a 2KB body and be sent to one addressee, and the next message can be addressed to a huge distribution list (DL) and include four attachments. Consequently, a messaging server's database engine must be able to handle semi-structured information in a highly scalable fashion. This requirement was behind the decision to give Exchange its own database engine. Over time, ESE has evolved to meet new needs, such as the introduction of the unlimited store in Exchange Server 5.5, Enterprise Edition (Exchange 5.5/E) and database partitioning in Exchange 2000 Enterprise Server.
ESE doesn't provide any user-level functionality out of the box. Exchange 2000 implements features on top of ESE through Magma, which is the code name for the Web Storage System (WSS). The WSS layer enables client access through different protocols such as Messaging API (MAPI), HTTP, and IMAP; implements the support for APIs such as ADO and OLE DB; and provides the point of integration for other Microsoft technology, such as the Babylon search engine.
Microsoft also uses WSS in SharePoint Portal Server 2001 (formerly code-named Tahoe). However, the implementation of WSS in SharePoint Portal Server is different from the implementation in Exchange because SharePoint Portal Server is a portal and search engine, not a messaging server. Think of the SharePoint Portal Server database as one public store per server. Although a casual examination of filenames and other clues might lead you to conclude that many similarities exist between Exchange and SharePoint Portal Server, they're quite different and no dependency exists between them.
In addition to WSS, Microsoft continues to develop SQL Server, another high-quality database engine. Because Microsoft incurs substantial engineering and support expenses by developing and maintaining two major databases, speculation that Microsoft might want to combine these separate databases into one database engine for use in all Microsoft products is only natural. The idea of Microsoft combining data storage into one database model isn't new—since Microsoft shipped Exchange Server 4.0 in 1996, people have asked whether Exchange will use SQL Server.
Recently, Microsoft sources began claiming that a future release of Exchange will use Yukon. Yukon is the code name for the next generation of SQL Server. This notion gained credibility when Gordon Mangione, the Microsoft vice president who was in charge of the Exchange development group when Exchange 2000 shipped, recently moved to take charge of SQL Server. What implications does this new data storage model have for Exchange users?
First, the change won't happen overnight. Yukon is still under development and isn't expected to ship in the near future—not until mid-2002 at the earliest. Exchange 2000 Service Pack 1 (SP1) doesn't depend on Yukon and neither does Mercury, the code name for the next functional release of Exchange that's expected in beta form in mid-2001.
Second, Microsoft is aware that the Exchange installed base is massive. Counting seats is always a difficult exercise, but a likely—and growing—estimate is that more than 50 million people use Exchange as their email server. Microsoft will have to find a way to seamlessly introduce Yukon to Exchange. But Microsoft has successfully performed massive upgrades to the Exchange store in the past. For example, most end users aren't aware that Exchange 2000 implemented WSS and includes database partitioning.
Third, application developers, particularly those who write applications that exploit the Exchange store or build products that interact with the Exchange store, should be isolated from the effects of change by Exchange 2000's comprehensive set of APIs. The theory is that if developers' applications write to the standards implemented in ADO, OLE DB, and Collaboration Data Objects (CDO), then a change to the underlying database engine won't affect the applications. However, as the developing story around ADO.NET (Microsoft's version of ADO for the company's .NET strategy) proves, the .NET standards are still evolving. After Microsoft finalizes the .NET standards, the amount of work that will be necessary to protect older code and ensure that it can move into the future will become apparent. Nevertheless, any application that exploits an unsupported API will probably require a substantial rework to upgrade to Yukon.
Technology's only guarantee is that it will change over time. Even if Microsoft achieves the goal of unified storage in Yukon, the company will have to meet many more challenges before Yukon ships. But Microsoft is smart enough to take the necessary steps to ensure that the transition is invisible to users and developers. After all, you didn't know about Magma, so why worry about Yukon?