Are you using Exchange 2000 Server as an application-development platform? If so, how do your applications access data in the Exchange Store? Exchange 2000 includes features such as ExOLEDB (an OLE DB provider for the Exchange Store), ActiveX Data Objects (ADO), and Collaboration Data Objects (CDO) for Exchange that make data access easier for developers. But how does the Microsoft .NET initiative affect this new approach to data access?

For me, the challenge in using Exchange 2000 as a development platform is understanding all the services for programmatic access (e.g., OLE DB, ADO, CDO). Technically, application developers can access the Exchange 2000 Store in only two ways—through HTTP-DAV or OLE DB. OLE DB-based access, which works in conjunction with ADO (using the Record and Stream objects that OLE DB exposes) is more complicated than HTTP-DAV-based access. The Exchange 2000 Store provides OLE DB access through an OLE DB provider (exoledb.dll). On the client side, Microsoft offers another OLE DB provider (commonly called "Rosebud" or OLE DB for Internet Publishing) that lets Microsoft Office applications use WWW Distributed Authoring and Versioning (WebDAV) to access Web servers. OLE DB is an open interface for uniform access to various information sources ranging from semistructured data, such as Exchange Server data, to structured data, such as Microsoft SQL Server. OLE DB leverages Microsoft's ODBC (designed for relational data) to permit access to any kind of data. Exchange 2000 OLE DB 2.5 adds important new features such as scoped operations (the ability to manipulate hierarchies) and direct URL binding to data objects (using http:// or file://) and permits direct SQL queries against Microsoft Web Storage System (WSS) data. These new features offer a rich provider mechanism on which to build powerful solutions.

ADO is layered on top of OLE DB and is both a consumer and a partner of OLE DB. Together, ADO and OLE DB provide complete navigation of the Exchange Store data. Microsoft designed ADO for Web-based client/server applications, and ADO provides a high-performance, easy-to-use object model. The current version, ADO 2.5, supports features such as URL addressing and hierarchical navigation to all Exchange Store data.

CDO is a set of objects (e.g., messaging, calendaring, contacts) layered on top of ADO. The most confusing aspect of CDO is the number of CDO generations and versions available—and they aren't all interoperable or compatible. CDO 1.2, the original version made available with Exchange Server 5.5 and Outlook 98, was Messaging API (MAPI)-based. A different, Internet protocol-based CDO 1.2 for Windows NT also exists. Finally, CDO 3.0, delivered with Exchange 2000 and Windows 2000, provides a single, unified object model that works on both the client side and server side, although the client side isn't available yet. CDO 3.0 for Win2K delivers some core messaging functionality (e.g., SMTP transport, Network News Transfer Protocol—NNTP) that is further enhanced when you install Exchange 2000. (CDO 3.0 for Exchange 2000 is a superset of CDO 3.0 for Win2K and exposes mailboxes and public folders.) CDO 3.0 isn't an upgrade to CDO 1.2, but MAPI applications will continue to run under the new version because the new version provides the CDO 1.2 library for backward-compatibility.

OLE DB and ADO provide the means to access data in the Exchange Store, and CDO builds on this access layer by providing objects that present the logic and behavior of the data. This approach is great for today's applications, but what happens when the .NET strategy comes to full fruition? Will developers need to start from scratch? The future of the Exchange Store leads to SQL Server and the creation of a unified storage engine for all Windows platform data. Microsoft won't leave Exchange developers behind, so I doubt that the company will eliminate the OLE DB, ADO, and CDO interfaces anytime soon. However, developers might have trouble using all the bells and whistles of the new storage paradigm unless they migrate their applications to the .NET platform, and migrating to .NET means that all roads lead to ADO.

In the .NET world, ADO is kept alive in ADO.NET. No vision of an Internet Web services environment is complete without a database-access component, and ADO.NET is that component for .NET. Developers wondering what to invest in for application-database access need to focus on ADO.NET. In the future, when Exchange Server, SQL Server, and even Active Directory (AD) use one unified storage platform, ADO.NET will provide access to that storage. If you're trying to future-proof the data-access model of your Exchange Server applications, make sure you're building on top of ADO today.