DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


Notice the existence of the communication software from the DBMS vendors themselves (or it could be a third-party communication middleware product). Oracle, Informix, and Sybase, for example, all provide their own communications middleware to enable processes to communicate with remote DBMSs. You will have heard of SQL*Net, I-Net, and OpenClient/Open Server. These products are all middleware products, but highly specialized ones providing connectivity to the DBMS vendor’s own DBMS.

Table 15.2 Level 2 functions
Level of function Type of function Function/command
Level 2 Connecting to a data source SQLBrowseConnect
Obtain info about a driver and data source SQLDataSources
Preparing SQL requests SQLParamOptions
SQLSetScrollOptions
Submitting requests SQLNativesql
SQLDescribeParam
SQLNumParams
Retrieving results and info about results SQLExtendedFetch
SQLSetPos
SQLMoreResults
Obtaining information from System Catalog tables SQLColumnPrivileges
SQLForeignKeys
SQLPrimaryKeys
SQLProcedure Columns
SQLProcedures
SQLTablePrivileges

If local DBMSs are used, the driver communicates with the local DBMS engine. If the driver needs to communicate with a remote DBMS, the communications software provided with the DBMS is used; for example, a developer using Oracle would use SQL*Net, a developer using Ingres would use Ingres*Net, and so on.


Figure 15.2  Architecture of ODBC software

If you want to access a remote DBMS you are still going to need the DBMS vendor’s connectivity product, and if you want to access a number of DBMSs you are going to have to have a copy of each of the connectivity middleware products of those DBMSs on the machine you are using as the “client”—a very compelling reason to use three-tier architectures instead of a two-tier architecture. In other words, all your drivers and connectivity software goes on the “business server,” not on the “presentation layer.”

OLE DB

OLE DB is a set of interfaces and methods conforming to the COM model that provide the developer with access to data stores (persistent data stores) of different types from components. OLE DB is thus not a replacement for ODBC but an alternative to it. Whereas ODBC can be used with normal procedural languages and function-based programs, OLE DB has been specifically designed for use in DCOM and for use with object-oriented languages.

OLE DB is intended to be more far reaching in its coverage of persistent data than ODBC. Through OLE DB many different sorts of data—text, graphics, relational data, geographic data, e-mail messages, and so on—is intended to be accessible. In effect, data from many sources and of many types will be accessible using component-oriented method invocations based on a set of defined interfaces. What sorts of methods can this interface(s) support? Let me provide an example.

Where data transfer is between a Data Object and a component, special facilities are provided to enable both Data Object and Component to find out or specify the format of the data and the medium of transfer. The client uses the IDataObject Interface, which has functions to get/set and query the data. As part of the functionality of this interface, the client can use two data structures—FORMATETC and STGMEDIUM. STGMEDIUM is used by clients or data sources to define the most efficient exchange medium for the data being passed—disk, global memory, and so on. The FORMATETC structure is used to indicate either the type of data the client wants from the data source or the format a data source can provide.

Thus the world of OLE DB is based entirely on the COM model and has methods specifically devised to handle the world of component-based access to data sources, which themselves look like object-based data stores.

How can the developer access different data types from a component interface?

As we have seen, the paradigm used by object-oriented applications is fundamentally different from that used in normal function-based applications. Most data sources are accessed by an API that is function based—SELECT, DELETE, INSERT, and so on.

Clearly, when an object-based application is being used to access object-oriented databases, the mapping between concepts used in languages such as C++ or Smalltalk is relatively simple as the concepts and paradigm being used are the same. As long as OLE DB is accessing a persistent store of some kind that was built to be accessed via interfaces and methods, then the mapping is quite straightforward, but in all other cases—relational DBMSs, hierarchical DBMSs, network DBMSs, spreadsheets, file systems—practically all our “legacy” or heritage file systems—something has to be done to “map” the interface/method invocations to API calls. The answer would seem to be translation of the commands at runtime, but in fact there are four possible solutions open to the developer:

  Database Object Using DML-If this approach is used, the developer creates a special “database object” in a language (such as C) that directly supports the DBMS API. In effect, the developer creates a component in a non-object-oriented language from which normal DML commands can be issued. The developer then does the mapping of data structures from within the object. The advantages of this approach are that the developer can use the DML directly and therefore can be sure of the overall effect of the command.

Furthermore, the commands can be compiled with the component, so the access is likely to be more efficient. The disadvantage is that the mapping of the data structures from the database component to the calling client can be tedious and may be difficult to achieve. Microsoft does not use this approach although there is nothing to stop the developer using it.

  Database Object Using ODBC-If this approach is used, a special “database object” is used that directly supports ODBC. In effect, the developer uses a special component that can support ODBC commands. The advantages of this approach are that the developer can use ODBC to access numerous DBMSs and file systems—hundreds of drivers exist for these systems and one dialect of SQL can be used. The disadvantages are the ones we have already seen in all translation products—performance may not be very good as translation is at runtime and the developer still has to understand the DBMSs and how they work to get the best from them. There is an additional problem as the mapping of the data structures from the database component to the calling client can be tedious and may be difficult to achieve. Microsoft can support this approach using the Active Data Object—we will see how shortly.
  Relational Mapping-If this approach is used, the software translates at runtime between the commands and concepts used in the component and the commands and concepts used in the DBMS. I will take two example companies that supply this sort of software to demonstrate how the products work—Persistence Software’s products and the ONTOS Integration Server. Both work in a similar way.

A table is set up that describes the mapping between concepts, for example, objects to tables, aggregations to foreign keys, etc., and then the programmer writes code to read, write, and update data using normal object-based invocations on methods. The software then translates at runtime between the commands and concepts used in the object and the commands and concepts used in the DBMS.

Now, we saw in an earlier section that this form of translation or database connectivity could be classified as “different DML translation.” Persistence Software and ONTOS thus provide products that compare in specialized functionality to those from Information Builders or Platinum Software because they provide specialized mapping from an object-based “DML” to a relational DML (or similar). They will also suffer from the same limitations. The administrator will need to ensure the tables are always up-to-date as the databases change, the developer may have to limit himself to only certain sorts of access (probably only queries—certainly not updates), and because translation is at runtime, performance may suffer. Microsoft does not use this approach.

  Interface Language Mapping-In this approach the entire database engine is mapped into components, which are then accessed through interfaces. Microsoft does support this approach, so it deserves more explanation. We will examine this solution in more depth below.


Previous Table of Contents Next