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

Previous | Table of Contents | Next

What makes this solution different is that no translation takes place, but the vendors of the DBMSs, or file systems have all the work to do. They have to provide components that conform to the interfaces. Thus it is not up to third-party “driver” companies to provide simple translation engines; the DBMS vendors themselves have to actually provide components that implement the functions of the interface!

The functionality of the database is partitioned into components, each accessible via an interface. Thus there are components to manipulate this data, handle the caching, store the data, delete the data, and so on. Database or data source providers/vendors or third-party providers then implement one or more of the actual components that access the data source.

Perhaps the important point to make here is that the same interface is used to access multiple data sources, and behind the scenes different components from each data source vendor will actually be used to implement the functionality—real polymorphism in practice.

Figure 15.3 Interface language mapping

The developer thus gets a common interface to access all data sources; all the data will appear to the developer as though it was a simple table.

Microsoft has provided DBMS vendors and file system vendors with a sort of “kick start.” The OLE DB SDK provides one component that implements common functionality associated with managing a rowset. This component can be used by data providers to expose the rowset interfaces on top of their data; however, Microsoft is encouraging both the vendors and third-party service providers to develop their own components to implement the interfaces, with components for query processing, cursor engines, and so on. Each is intended to be a stand-alone component with a defined interface that can be integrated with other components where need be.

One advantage with this approach is that the components can use the same interfaces and functions themselves as ordinary components. One useful example of this is the use of the Outgoing Interface.

Outgoing Interfaces and Data Objects

In the description above, we saw how the OLE DB COM interface can be used to access data and how the components can be built to provide the functionality of OLE DB. But Microsoft has also provided an interface by which Data Objects can inform clients of events, and this is called the IAdviseSink.

This is a special implementation of the Outgoing Interface, as it allows a “server” component to inform a client of an event. If data in the Data Object/source changes, for example, the data source itself can asynchronously notify the clients connected to it of the data change event. DCOM refers to this as “notification” and achieves the notification via an object called an “Advise Sink,” which is placed in the client.

Figure 15.4 AdviseSinks and DataObjects

The client contacts the Data Object through the generic interface called IDataObject. The client then provides a pointer to the Advise Sink that can be used by COM to communicate with the AdviseSink. At the same time, the client also registers its interest in a specific data change. It is then the Data Object’s responsibility to detect that data change.

Data Objects can send notifications to multiple Advise Sinks, but the Data Object itself does not have to know which clients are interested in the data change. COM itself manages the pointers to each of the clients on the Data Object’s behalf, and it is COM that actually does the notification.

What does all this mean? Well, it means that a database or file of data managed by a DBMS or file system can act like a connectable object. If the value of a data item, for example, changes, one or more clients can be informed. So, for example, if the share price was held on a database and the share price rose to astronomic heights, the “Data Object” could be used to inform all the clients (shareholders, customers, stockbrokers, the share company) of the change.

How it all works in practice

We have seen that Microsoft effectively provide two solutions to the problem of data access of existing file systems and data sources—via vendor provided components or via ODBC. So how does all this work behind the scenes? The diagram below shows how.

From the developer’s point of view, he or she will access all OLE DB data through a new version of ActiveX Data Objects—ADO. OLE DB data consumers use the OLE DB SDK to access data. A new OLE DB Driver Manager directs calls either to the OLE DB components I have described or to ODBC Drivers.

Where the calls are directed to the ODBC Drivers, the consumer communicates with ODBC-compliant data providers through existing ODBC drivers. In this case, the data is usually relational and accessed using SQL commands.

If the data source provider has provided a component to implement the methods and interfaces in OLE DB, however, the calls will be directed to these components. In the diagram you will also see a box marked Thor. Thor provides OLE DB to DB2 data access. In the diagram I have also included the last piece in this puzzle—stream and storage objects.

Figure 15.5 OLEDB Architecture

Stream and storage objects

Up to now I have assumed that the developer is accessing existing data sources—data sources from third-party vendors or from Microsoft themselves. But what if the developer wants to use a purpose-built object-oriented storage mechanism to store data—one that is supplied with DCOM.

The Active Data Object provides direct access to a Persistent (object oriented) storage mechanism used by COM and DCOM itself. Two types of storage element are supported—stream objects and storage objects:

  • Stream objects are the conceptual equivalent of a single disk file—the basic file system in which data lives. Each stream can contain any sort of data, and data in stream objects can itself be manipulated using objects geared to the data type, for example, text objects, bit map objects, drawing objects. A stream is named using a text string, has access rights, and a single seek pointer. Through the IStream interface, the stream can be told to read, write, seek, and perform other operations on its underlying data. Functions in IStrearn map nearly one to one with file handling functions.
  • Storage Object is the conceptual equivalent of a file directory. Each storage, like a directory, can contain any number of substorages and any number of streams (files). Each storage has its own access rights. The IStorage Interface is used to move, copy, rename, create, destroy, etc., storage objects. Storage objects cannot store data.

Previous | Table of Contents | Next