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 functionalityreal 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 Objects 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 Objects 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 sourcesvia vendor provided components or via ODBC. So how does all this work behind the scenes? The diagram below shows how.
From the developers point of view, he or she will access all OLE DB data through a new version of ActiveX Data ObjectsADO. 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 puzzlestream 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 sourcesdata 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 dataone 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 supportedstream objects and storage objects:
Previous | Table of Contents | Next |