Welcome Guest. | Log In| Register | Membership Benefits

Columnist
June 29, 1998

Developments:
DCOM: No Objects In Sight

Microsoft's distributed object initiative illustrates how the company's technology is unable to escape its desktop roots

By John Tibbetts and Barbara Bernstein

O ur recent column, "Distributed Object Dreams" (InformationWeek, May 18), gave some readers nightmares. We had agonized over whether the best bet for a distributed object architecture is the more open Corba or the more holistic Java Remote Method Interface. Not even in the running, we asserted, was Microsoft's distributed object initiative, known as DCOM, which we described as "totally proprietary, essentially platform-specific, and technologically mediocre." In flew the E-mails demanding our reasons.

Fair enough. Dispatching this popular technology requires more than a few salvos. Furthermore, it provides a good example of how Microsoft lays claim to the most advanced concepts in enterprise computing while its underlying technology lags behind, unable to escape its desktop roots.

DCOM is built directly upon desktop integration infrastructure that Microsoft introduced around 1990, though Redmond has changed emphasis and nomenclature so many times that it's hard to see the connection. DCOM is the distributed (i.e., network-enabled) version of Microsoft's Component Object Model. COM is essentially a renaming (circa 1993) of a bunch of lower-level services that Microsoft separated out of OLE object technology. OLE is the plumbing built to integrate, for example, an Excel spreadsheet into a PowerPoint presentation. An Internet-enabled version of OLE controls later appeared under the name ActiveX. (A few months ago, Microsoft introduced the term Distributed interNet Applications Architecture [DNA] to describe this entire edifice of components, plumbing, and services.)

DCOM, then, rests on a lightweight interaction paradigm now several generations old. Technology developed to open a spreadsheet in a word processing document is being shot full of steroids and put out there as a remote transaction contender. Many new features have been added, but there's been no fundamental rethinking of the creaky underpinnings. DCOM exists today as an inelegant, sprawling, fundamentally unarchitected piece of technology. It is stunningly complex. For example, it has a huge API (we stopped counting at 300 entries) that's structured in such a way that a high-level programmer needs to keep track of many low-level details.

What Microsoft has failed to provide over the course of the decade has been any notion of objects. That's right--despite that "O" in its name, DCOM is based on a strictly pre-object model of how to structure and manipulate software.

Object technology's sine qua non is that software gets decomposed into small atoms of data-plus-function that can be individually known, named, contacted, and coerced to perform work. It is these objects/atoms that let us think about systems in terms of Parts, Employees, Accounts, etc., and let us design swift, flexible, reusable programs. DCOM doesn't natively provide any way to interact with objects. Instead, it lets us interact only with a list of functions, the same way that Cobol or Basic always has.

DCOM closely resembles the function-oriented Remote Procedure Call technology that was popular at the beginning of the decade. Its primary distribution machinery comes, in fact, directly from the Open Software Foundation's venerable Distributed Computing Environment. Microsoft can add powerful transaction and directory services, and it can appropriate distributed object terminology, but the fact remains: This is not an object environment.

It may be that DCOM can handle most jobs currently on a developer's agenda. But as real distributed object systems raise the bar on what is possible, DCOM's weak-ness will become apparent. Those who buy into a distribution scheme that lacks discrete, individually addressable objects will find that reuse is hard, complexity atrocious, and that newer options such as collaborative transactions and mobile agent technology are virtually impossible.

When we wrote "technologically mediocre," we were being kind.

John Tibbetts and Barbara Bernstein are partners in Kinexis, a San Francisco consulting firm. You can visit them at their Web site at www.kinexis.com.


Back to Columnists

Send Us Your Feedback

Top of the Page