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

Previous | Table of Contents | Next

Every “data item” in effect becomes a stream. Although the objects themselves manipulate the streams, COM handles storage (physically) on disk and manages unused space, overflow, etc. As long as the data type of the stream is known, any application can look at data in storage—not just the application that created it.

Every storage and stream object has a character-based name that is not dependent on the underlying file system, but the name of the root storage object is the name of the underlying file system. In effect, the persistent data storage mechanism supported by COM is a little like a hierarchical file system, except that the “data items” aren’t stored as a group in records, but stored singly within a storage object representing that record.

Clients can browse directory and data using the IStorage Interface and DCOM. Clients can also update data. As objects have direct incremented access to their bit of data, objects can also make incremental changes to data or do incremental reads.

Two modes of update are allowed—direct and transacted. Direct mode provides immediate and permanent update of data. Transacted updates are buffered so that they can be saved/committed. The client, however, has to keep the update changes separate from the old version of data itself; DCOM does not do this for it. It then issues a commit/save or close/revert. Only when the client commits is the storage updated and two-phase commit is built in to ensure the update is successful.

Figure 15.6 Storage and stream objects

Clients, as is the case with all of DCOM, use interfaces and calls on methods in those interfaces to tell DCOM what it wishes to do with storage:

  • IPersistStorage-This interface enables the component to read and write its persistent state to a storage object.
  • IPersistStream-This interface enables the component to read and write its persistent state to a stream object.
  • IPersistFile-This interface enables a component to read and write its persistent state to a file on the underlying system directly.

### In Summary

Developers need to be able to store and access data in permanent data stores—stores which in object-oriented terminology are called “persistent data stores.” Two main types of store are supported in DCOM:

  • existing DBMSs and file systems, any file in fact which is accessed currently via a non-DCOM interface
  • a purpose-built data store supporting stream and storage objects

Access to both is via OLE DB and the Active Data Object, with added support for ODBC for existing, primarily relational, DBMSs. OLE DB is an interface/method-based means of accessing data in data stores, based on the COM model. Where access is to existing DBMSs or files via OLE DB, the vendors of these products will be expected to build components that implement the method in the OLE DB DCOM interfaces.

There are clearly advantages to using a COM-based interface to access data. Commonality of interface from the developer’s point of view does help to simplify things, and we saw that many interfaces used in COM to achieve development actions—for example, the Outgoing Interface—could be used to good effect by the Data Objects.

It does remain to be seen, however, whether this will really work in practice—first, whether DBMS vendors will bother to produce components (it does seem a lot of work for them with only Microsoft to gain from it) and second, whether a standard interface to the sort of complex often duplicated data companies actually have in practice will work. As I explained, it may not be a good idea to hide the complexity anyway, given that it can affect the accuracy of the results and can also affect performance. This is the one area of DCOM, in fact, where I have misgivings about the whole approach being taken.

I’m not sure it isn’t just better to get dedicated developers to write components destined to be resident on each DBMS host, which use a language like C and native DML to access the data. By using this approach the components with their DML can also be compiled.

The developer will have the job of mapping the data structures in the database with those destined to be passed across the interface, but in doing so may also be able to do some basic format translation, coding system conversions, or data cleaning. Where the data is collected from many different data sources to be merged, it could then be merged on a middle tier using the stream and storage objects as a working store.

The result is likely to give far better performance and more reliable results than the somewhat complex translation solution offered by OLE DB or ODBC. It may be better to limit the use of OLE DB to low- to medium-volume ad hoc queries, for example, on straightforward, well-documented data structures.

Previous | Table of Contents | Next