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 vendors own DBMS.
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 vendors 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 clienta 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 datatext, graphics, relational data, geographic data, e-mail messages, and so onis 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 structuresFORMATETC and STGMEDIUM. STGMEDIUM is used by clients or data sources to define the most efficient exchange medium for the data being passeddisk, 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 basedSELECT, 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 casesrelational DBMSs, hierarchical DBMSs, network DBMSs, spreadsheets, file systemspractically all our legacy or heritage file systemssomething 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:
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.
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 queriescertainly not updates), and because translation is at runtime, performance may suffer. Microsoft does not use this approach.
Previous | Table of Contents | Next |