Jose Blakeley
Microsoft Corporation
December 1996
Businesses are increasingly discovering the need to build solutions that span desktop, mid-range, mainframe, and Internet technologies. The variety of data stores that are present in any business today, and the many ways in which they are accessed, create barriers to developing applications that can bridge both the new and the old technologies. As a result, new requirements emerge for middleware that enables a new class of applications to be easily built and managed.
OLE DB is a specification for a set of data access interfaces designed to enable a multitude of data stores, of all types and sizes, to work seamlessly together. These interfaces comprise an industry standard for data access and manipulation that can ensure consistency and interoperability in a heterogeneous world of data and data types.
OLE DB goes beyond simple data access by partitioning the functionality of a traditional relational database into logical components, and the events needed for those components to communicate. Developers can use these interfaces to define very simple data providers as well as fully relational databases. This is a strategic part of the Microsoft® enterprise infrastructure for component-based computing. Components can be thought of as the combination of both process and data into a secure, reusable object. As a result, it often makes sense to treat components as both consumers and providers of data at the same time. Since the OLE DB specification is a definition of how databases interoperate at various levels, components can be built using OLE DB to behave as a table, even though very complex computing processes can actually occur between the data sources and the consuming applications. This capability will have considerable impact on how multi-tier applications are assembled.
The OLE DB interfaces are useful to all software vendors whose products manage data in some way. Since OLE DB provides a way for any type of data store to expose its data in a standard, tabular form, new opportunities will arise that don't exist today. Some examples are discussed here:
There is clearly a need for a new approach to unified data access and manipulation. OLE DB is that new approach. Software vendors who take advantage of the OLE DB capabilities break down into four categories: data providers, data consumers, data service providers, and business component developers.
As can be seen in the earlier examples, there are many reasons to simplify data access in the corporate world. Enabling a variety of diverse data sources to share information is essential to corporate decision making.
With the initial release of the OLE DB SDK, OLE DB-compliant data consumers will be able to efficiently access all relational databases through existing ODBC drivers. Therefore, Microsoft's plan is to work primarily with non-SQL database vendors to support the OLE DB interfaces. These data sources range from very simple formats like log files and ISAMs through the most complex formats, such as IMS, ADABAS, or e-mail stores.
Additionally, the OLE DB SDK provides a component that implements common functionality associated with managing a rowset. This component makes it easier for data providers to expose the rowset interfaces on top of their data.
The advantages of OLE DB continue to grow as a broad base of support from a wide array of database vendors becomes available.
The OLE DB data consumer is any piece of system or application code that needs access to a broad range of data, including development tools, languages, and personal productivity tools. Microsoft is actively encouraging a broad set of tools vendors to write to the OLE DB specification. The goal is to get complete tool support for OLE DB.
As mentioned earlier, OLE DB goes beyond simple data access by partitioning the functionality of a traditional relational database into logical components, and the events needed for those components to communicate. The intent is to develop database components, such as query processors or cursor engines, as stand-alone products that can seamlessly integrate with existing OLE DB-compliant data providers.
As applications broaden their reach to end users through the corporate networks and to customers through the Internet, applications based on reusable components that can execute locally (for graphical work) or remotely (for computational work) become increasingly important. Microsoft is actively building a suite of tools and an infrastructure to make distributed applications based on these technologies both scaleable and manageable. OLE DB will play an important role in the future development of vertical applications based on business-centered components.
For example, when a developer decides whether to design a new application using a classic client/server approach, or using a three-tier approach, there are certain tradeoffs. For instance, it is much easier to attach a visual control directly to a table than it is to write code to query a component and load the control. On the other hand, it is better to avoid linking controls directly to data structures so the database can evolve without impacting all dependent clients. The solution is for business components to use OLE DB to both consume data from data providers and at the same time expose its result set after data access and processing as a simple OLE DB tabular rowset. This provides the best of both worlds—the capability to attach to a rowset, while maintaining the required abstraction from the true data tables.
In addition, if the returned rowset from the component is very large, it may need to be queried for subsets of information. In this case, the developer can treat the returned rowset like a table, and can use an OLE DB-compliant query processor to query and update subsets.
Finally, when data changes, events are required to allow notification between dependent components on a single desktop, and between the remote database and any dependent desktop components. OLE DB defines the events required to synchronize the entire application environment as data changes occur. This is a critical element when writing database-centered applications using components.
The ODBC technology and third-party market have matured to a point at which ODBC is an ideal technology for accessing SQL databases. As a result, an integral part of OLE DB is a new OLE DB driver manager that enables OLE DB consumers to talk to ODBC providers. The following information can guide your choice of which technology to use:
| ODBC | OLE DB |
| Data access API | Database Component APIs |
| C-Level API | COM API |
| SQL-based data | All tabular data |
| SQL-based standard | COM-based standard |
| Native providers | Component Architecture |
There are an increasing number of data stores and data types spread across computer systems. Increasingly, business applications need access to a multiplicity of internal and external data sources simultaneously. OLE DB is a forward-thinking technology targeted at these kinds of applications. This is a low-level technology directed toward software vendors whose products provide or consume data. The result of ISV support for OLE DB will be availability of high-level tools and languages from many vendors. These tools will be able to access a wide variety of data sources without the confusion of different proprietary APIs.
As application developers move to solutions designed as reusable components, OLE DB enables business-centered components to behave and communicate like mini-databases, both as data consumers and providers. This capability is the basis for new, simpler ways to build applications based on components.
OLE DB is an integral part of a comprehensive suite of products and technologies from Microsoft designed to take advantage of the trend towards network-based, distributed computing solutions.
This capability extends across corporate data as well as Internet data, and across all types of data providers beyond SQL databases.
When a developer uses a tool or language that supports OLE DB, different data sources can behave as a single, homogeneous source. For instance, Microsoft will provide a high level, object-oriented way to access all OLE DB data through a new version of ActiveX™ Data Objects (ADO). From ADO, developers can create business applications that link many data sources.
Business components can excrete data change events, consume OLE DB data, and provide OLE DB data. This way, business components can perform very complex processing, and synchronize with other components, yet expose simple, table-like interfaces.
Most graphical development tools automate loading result sets from queries directly into visual controls. Today, calling components requires more programming to access the result set and load the visual controls. When business components expose their results as OLE DB-based tabular data, development tools can treat them as a simple table, even though their application is using reusable, distributed components.
OLE DB is a useful technology in its own right, but becomes compelling as Microsoft's broad suite of enterprise tools and technologies integrate and extend each other's capabilities. For instance, the transaction processing component of OLE DB is being defined and implemented by Microsoft's OLE-based transaction product currently code-named Viper, and Viper will utilize OLE DB for data access.
OLE DB data consumer tools and languages have full access to all ODBC drivers and ODBC-based data.
Note: This white paper is being made available for your review only; Microsoft does not support it.