DCOM has its roots in Microsoft's object technology, which has evolved over the last decade from DDE (Dynamic Data Exchange, a form of messaging between Windows programs), OLE (Object Linking and Embedding, embedding visual links between programs within an application), COM (the Component Object Model, used as the basis for all object binding), and ActiveX (COM enabled for the Internet).
The evolution of this technology shares a common theme: each iteration reduces the complexity of building large applications while enabling the delivery of successively richer functionality to the end user. This can lower application development costs, because developers can leverage pre-built components and their interfaces without having to spend as much time testing and integrating the work of multiple people.
Applications built from components are simply easier to debug and evolve than large, monolithic applications.
For example, the “Year 2,000 Problem“—where many large organizations are scrambling to fix their production systems to avoid failure when the date changes to the new millennium—is an application design problem, not a date problem. If legacy applications were written with a common date component, the fix would be easy to isolate and inexpensive to repair.
Most developers for the Microsoft Windows® operating system understand these benefits and use the ActiveX component architecture. There are over three million professional programmers trained on ActiveX and its technologies—OLE, COM, and DCOM—and hundreds of independent software companies ship thousands of prebuilt software components. These commercial software components can be used by developers working with Microsoft Visual Basic®, PowerBuilder, Micro Focus Visual Object COBOL and other popular tools.
The key business benefits of ActiveX on the desktop automatically extend to DCOM across the network: