DCOM - The Distributed Component Object Model
The information contained the in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only.

MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft Windows NT Server

This paper provides a business overview of DCOM—the Distributed Component Object Model—a technology that enables software components to communicate directly with each other across networks, including the Internet and intranets.

Introduction

With the advent of the Java programming language and the growth of the Internet, IT (Information Technology) managers are once again excited at the prospect of using component software technology—the idea of breaking large, complex software applications into a series of pre-built and easily developed, understood, and changed software modules called components—as a means to deliver software solutions much more quickly and at a lower cost.

The goal is to achieve economies of scale for software deployment across the industry. A component architecture for building software applications will enable this by:

A distributed component architecture applies these benefits across a broader scale of multiuser applications. The Distributed Component Object Model (DCOM) has three unique strengths that make it a key technology for achieving this: The combination of these three factors—the largest installed base, native support for Internet protocols, and open support for multiple platforms—means that businesses can realize the benefits of a modern component application architecture without having to replace investments in existing systems, staff, and infrastructure.

Components and Desktop Development

Component-based development is established today as a mainstream business technology on the desktop.

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:

Components and the Network

The logical boundary for component applications is no longer on a single machine. Businesses want to leverage the benefits of component development across a broader set of multiuser applications.

Companies want to apply the benefits of component software, rapid reuse, broad industry support, and availability of thousands of components, across shared applications that operate on multiple machines. These types of applications are referred to as “three-tier” or “n-tier” applications, where “tiers” of application logic, presentation services, business services, and information retrieval and management services, are broken into different components that can communicate directly with each other across a network. To the end user, these applications appear as a seamless extension of their existing desktop environment. For the IT manager, they represent the opportunity to apply the economics and flexibility of desktop development across a broader set of application problems.

For example, a business may deploy a new sales management system based on a multitier application design using components. The application includes different order entry components, each one designed for a separate sales channel. These components all use a common, single tax calculation component that runs on a server. As tax laws change, the company only has to change the tax component located on the server, without having to retrofit the order entry components for each of the different sales channels.

DCOM is an ideal technology for multitier applications because it enables ActiveX components to work across networks, enabling developers to easily build systems that span machine boundaries. In the scenario described above, developers integrate components together without having to worry about network programming, system compatibility, and integration of components built from different languages.

This can lower the cost and complexity of building distributed applications from components. DCOM leverages the investments companies have already made in ActiveX by providing the following benefits:

Components and the Internet

Businesses want to use Internet protocols to link component-based applications across public and private networks, projecting a presence of their business systems out onto the Web.

The simplicity, ubiquity, and industry momentum of standard Internet protocols like HTTP make it an ideal technology for linking components together for applications that span machine boundaries. HTTP is easy to program, is inherently cross-platform, and supports an accessible, universal naming service. Much of the excitement around the Java language derives from its potential as a mechanism to build distributed component applications on the Internet.

For example, many companies have built investment portfolio management systems that rely upon an Internet-based data streams, such as Pointcast for stock information. This enables a low cost way to leverage and integrate existing services and applications into an in-house solution based on browser and Web technology. Developers can simply “plug-in” the services of a remote component communicating over the Internet as a low-cost means to enhance the functionality of an in-house solution.

DCOM enables component applications to operate across the Internet. Microsoft is working with Internet standards bodies, including the IETF and the W3C, to offer DCOM to the Internet community as an open technology.

DCOM is ideally positioned to become a mainstream, Internet technology for business applications because it is:

Components and the Enterprise

As distributed applications built from simple components and Internet protocols emerge, a new set of "Enterprise" platform services for component applications will be required.

A key goal of any component software architecture is to separate business logic, for example, how a tax component calculates tax rates, from execution logic, for example, whether the tax component runs in a browser or on a multiprocessor server. DCOM extends this separation even further, because the same components can communicate with each other across processes in a single machine or across the Internet via HTTP.

However, components by themselves do not solve all of the issues of enterprise application complexity.

For example, a business wants to rapidly build and deploy a customer order entry application that involves five different areas of functionality—tax calculation, customer credit verification, inventory management, warranty update, and order entry. The application is built from five separate components and operates on a Web server with access via a browser. How does the developer handle exceptions? System failures? Network outages? Peaks in performance load?

It defeats the two main goals of component-based development, fast time-to-market and lower development costs, if companies are forced to “hand-code” into their component applications the mission critical services that are required for online production systems.

To address the enterprise requirements for a distributed component architecture, without sacrificing rapid development and cost effectiveness, Microsoft is integrating DCOM into the ActiveX Server, a series of technology services that speed deployment of component-based applications across the Internet and corporate intranets. Some of the ActiveX Server Framework services include:

The ActiveX Server technologies will be built using publicly available Internet protocols and will begin to appear in 1996.

DCOM Availability

Additional implementations of DCOM on other Internet and Enterprise platforms will be available in Q1 1997.

For more information

For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/backoffice or the Windows NT Server Forum at the Microsoft Network (GO WORD: MSNTS).

The information contained the in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be intrepreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

© 1996 Microsoft Corporation. All rights reserved.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

ActiveX, Microsoft, Visual Basic, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Other product and company names may be trademarks of their respctive owners.

Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA

0996 Part No. 098-66121