Microsoft keeps refining app distribution

 OLE first became a distributed possibility with Microsoft Visual Basic
4.0, a language that lets developers create OLE automation servers that can be shared
among many clients. Known as remote OLE automation, this highly proprietary approach to
distributed computing was Microsoft's first try at DCOM.

 Remote OLE automation makes it possible to create nonvisual OLE servers for
application development. OLE controls-once called OCXs and now known as ActiveX-are visual
components that can plug into applications as well as World Wide Web browsers.

 Under Microsoft's somewhat confusing naming convention, OLE automation servers that
run on a server with no visual interface are called Active Server components. Desktop
components are called ActiveX if they were built under COM.

 Both ActiveX and Active Server, when connected by DCOM, get the moniker Active
Platform.

 On the Active Platform, DCOM is the plumbing and wiring that connects COM objects
into distributed applications. DCOM acts as part of the operating system's infrastructure,
allowing ActiveX and Active Server objects to find each other over a network.


 DCOM is part of Windows NT 4.0 and probably will be part of the next
release of Windows 95. It supports distributed application development and provides
directory, security, transaction and processing support.

 With its mechanisms for placement of parameters, client proxies and server stubs,
DCOM distributes COM's object infrastructure to support client requests made to objects on
remote computers. DCOM also has an Automation Manager for automatic distributed computing.


 The promise of DCOM is a single network log-in and a single point of administration
and replication. Early DCOM developers, however, have found that it does not scale well
and is best suited for distributing workgroup applications.

 Its synchronous communications mechanism is based on the Open Group's Distributed
Computing Environment (DCE) remote procedure call. Interestingly, DCOM does not take
advantage of DCE security and directory services. Instead, it uses the Windows Registry's
directory and security. 

The Windows Registry is organized by user accounts, each with a user ID, password and
access control information. It sets privileges for accessing files, printers, applications
and external resources. It may include ActiveX components and interfaces for those
components.

 DCOM itself isn't a development environment; it's simply a means of distributing
application services. Developers can build servers for distribution using any COM-enabled
development tool for ActiveX or Active Servers. Visual Basic, Powersoft Corp.'s
PowerBuilder and Borland International Inc.'s Delphi all have the facilities to make
components for distribution via DCOM.

 Once the Active Servers (or ActiveX components) exist, DCOM takes over. A DCOM
server can reside anywhere. Developers need only reference the server in the client
applications, and DCOM can find the correct resource, if available, for the client.

 The server makes itself known to the Windows Registry on the local computer, and
then DCOM uses the Windows Registry to ensure that other remote network computers know
about the server, too. Applications running on a remote computer can access the server as
if it resided on the local computer.

 DCOM also handles all distribution mechanisms. This is an example of multitiered
application development using the distributed object development model. 

Other examples include Common Object Request Broker Architecture (CORBA) distributed
objects and proprietary distributed object tools from Forte Software Inc. of Oakland,
Calif., and Dynasty Technologies Inc. of Naperville, Ill.

 So how does DCOM lead into the Active Platform? First, Microsoft plans to fix DCOM
scaling limitations via the Active Directory. Previewed in November, the directory is
supposed to support more than 10 million objects per store for enterprise-level
scalability.

 Second, Active Directory will be a single point of administration for all
DCOM-accessible resources, overlaying the Windows Registry with a COM-enabled mechanism.
Administrators and developers can group COM objects such as databases, files and
peripherals according to organizational units.


 For example, all accounting-related objects could reside in one logical
group accessible by networked applications.

 Active Directory also will support Internet directory standards such as the Domain
Name System, Lightweight Directory Access Protocol and X.500 and naming standards such as
Request for Comments 822 names, World Wide Web uniform resource locators, X.500 names and
Universal Naming Convention names.

 Overall, DCOM looks promising as part of the leading operating systems. Those who
upgrade to Windows NT 4.0 and the next Windows version will get DCOM with them. And, as
OLE automation and ActiveX development continue, most client-server development tools will
support the building of COM servers for use with DCOM.

 Competing CORBA application development hasn't gained as much tool support, so DCOM
looks to be the stronger candidate. As part of an operating system, DCOM could be the
easiest and least expensive way to build distributed computing solutions.

 There's little need for concern about third-party object integration, connection
mechanisms and protocols. However, Microsoft has a lot of work to do on DCOM's
scalability.

 The only reason organizations get involved in distributed computing is to scale up
their distributed applications and spread out the processing load. 

DCOM won't succeed until Microsoft sizes it for the enterprise. 


David S. Linthicum is a client-server expert with more than 15 years' experience. 


inside gcn

  • Congressman sees broader role for DHS in state and local cyber efforts

    Automating the ATO

Reader Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above