Microsoft's Universal Data Access (UDA) strategy is finally starting to come to fruition with the advent of the Exchange 2000 Web Storage System. A developer can use the familiar ADO object model to deal with Exchange data and even write SQL queries against it. In this selection we'll see exactly how this can be done and look at the underlying technologies that make this type of data access possible.

The ADO/OLE DB Conspiracy

By now, most programmers working with the Microsoft development tool set have heard of Microsoft's Universal Data Access (UDA) strategy. The basic tenet is that regardless of the type of repository that houses your data, you should be able to get to it using just one application programming interface (API)--namely, ActiveX Data Objects (ADO). Sure, some component is going to have to know the low-level details of where the data lives, but that component (known as an OLE DB provider) hides all of these details from the ADO programmer. He or she just uses the ADO object model to programmatically manipulate data from a disparate bunch of data stores. Microsoft Data Access Components (MDAC) ties it all together by packaging ADO with the necessary OLE DB providers.

Figure 7.1 shows the big picture that we
have described here. Consider the real-world scenario in which your company
has corporate data stored in several heterogeneous data sources. You need to
write an application that has access to all of the data. The same application
needs to be available from any Web browser. With ADO, your application can have
one consistent programming interface to access all of the data. As long as the
data store supplies an OLE DB provider that conforms to Microsoft's standard,
a developer can use ADO to access the underlying data.

As the diagram in Figure 7.1 clearly suggests,
you can bypass ADO and directly code against the interfaces provided natively
by the OLE DB providers. Well, you could. However, the code is not trivial,
and you are limited to C++ as a language choice.