Distributed object application development: The DCOM solution

Part 1: " Link ."
Part 2: " Link ."
Part 2: " Link ."

DCOM overview

Microsoft's answer to distributed computing is the Distributed Component Object Model (DCOM) -- the "other" major standard to consider in the world of distributed objects. DCOM is simply an extension of Microsoft's Component Object Model (COM), formerly called Network OLE, which forms the basic architecture of the Windows operating system. The underlying objective of COM is to permit the independent development of software components that can intercommunicate, regardless of language or function. DCOM extends the functionality of COM by allowing components to communicate remotely via LAN, WAN, or the Internet.

And how does ActiveX fit in to this picture? ActiveX is no more than another representation of a DCOM object. ActiveX controls are designed to facilitate distribution of components over the Internet and provide integration of DCOM components into Web browsers (specifically Internet Explorer).

The pros and cons of DCOM

The biggest gain that DCOM provides in developing a distributed application is, not surprisingly, its tight integration with Microsoft operating systems and applications. For example, distributed systems using DCOM as its middle-ware will be able to leverage the powerful resources of components like Microsoft's Transaction Server and Internet Information Server 4.0. Both of these technologies rely on DCOM for remote communications. Furthermore, there are tons of Microsoft shops currently building COTS products and tools that are DCOM compatible, thus reducing the system development time by reusing these plug-and-play components.

DCOM-based applications can also take full advantage of Microsoft NT security mechanisms. Since the first release of DCOM, the application programming interface (API), including the security model, has been made readily available to developers. Through this model, developers can provide secure and authorized communications via Windows Domain, Novell Authenticators or DCE Kerberos. Security implementations in DCOM are also highly configurable. Developers and administrators have the ability to configure the security settings for each component using the DCOMCNFG utility. DCOMCNFG allows developers/administrators to define access control lists (ACLs) for each component. This is an important feature which provides the means to create complex, multi-user, multi-role, applications with n-levels of secure access.

There are three principal drawbacks to a DCOM implementation: non-intuitive and complex development process, platform dependencies, and ActiveX security issues.

One of the chief complaints of a DCOM solution, regardless of the programming language, is that the development effort is too awkward and complex. Fortunately, Microsoft's Visual J++ removes some of this complexity by making DCOM objects resemble Java classes. Interestingly enough, Java is better suited for DCOM development than other languages (Microsoft. Visual C++., Microsoft Visual Basic., Delphi, PowerBuilder) due to the Java Bindings provided by the Visual J++ tools.

As a product of the Micosoft world, DCOM architectures are tied heavily to Windows95 and WinNT platforms. This is a major stumbling block for any architectures that are not 100% Microsoft, so strides are being taken to port DCOM to other operating systems. A Microsoft solutions provider, Software AG, has developed a port to Sun Microsystems' Solaris UNIX platform and has plans to develop DCOM ports for other UNIX operating systems as well. Even more DCOM-porting initiatives are reportedly underway at Digital Equipment Corporation, Hewlett Packard, and Siemens-Nixdorf. The bottom line is that DCOM will eventually have multi-platform support, giving the DCOM architecture even more credibility as a tool for building heterogeneous distributed systems.

There also has been criticism about the lack of security of ActiveX components -- that "signed" code does not equate to "secure" code. Critics of ActiveX believe that the technology needs to incorporate a more Java applet type of security model, where the download-able Java code cannot play outside of its well-defined "sandbox." This is a valid request, since a hostile ActiveX component could instill extensive damage upon a client machine. As outlined in an article on ZDNet titled "Norton Utilities, Internet Explorer Combo Puts Systems in Harm's Way," it was discovered that there was a core component of the Norton Utilities software that could be invoked by an ActiveX component downloaded through an Internet Explorer browser. The authors describe some of the havoc that could be reaked upon unsuspecting clients.

"A Web page hacker could build a page that, when viewed by Internet Explorer, runs a few lines of VBScript code that wipes out a hard drive, installs a Trojan horse, or invokes file transfer and directory utilities to retrieve confidential information. Worse yet, all these tasks could be performed in the background without the user ever knowing what's happening to their system."¹

So it makes sense to enhance the security model of ActiveX. But how much? As a technology becomes more secure, it often loses desirable functionality. Today's Java applets are a good example of this security/functionality trade off. Though Java applets provide greater code security on the client side than ActiveX components, there are limitations associated with that security that sometimes make Java applets an inadequate solution. The answer for ActiveX is probably somewhere in the middle -- an expanded version of Java's sandbox mechanism combined with the current signature attachments (which is the exact approach Java applets are taking from the opposite end).

The future of DCOM

The future of DCOM appears secure. Microsoft's substantial COM user base from which to build gives it tremendous momentum. And they certainly boast some impressive figures to back up this statement. First, Microsoft states that over 150 million systems are using some form of COM. Second, the Giga Information Group estimates that the market for third-party components based on COM was at $410 million dollars in 1997. The same group projects an amazing growth rate that reaches about $3 billion dollars by 2001 for COM products.²

Another important factor in assuring the future success of DCOM was the move from proprietary Microsoft ownership to the welcoming arms of a standards body -- The Open Group (TOG). The main charter of The Open Group is to:

• promote the availability and compatibility of ActiveX technologies across systems and architectures.
• enhance ActiveX interoperability with the Distributed Computing Environment (DCE).
• accelerate the evolution of ActiveX technologies through the collaborative development process.

The current list of OTG members includes:

• Adobe Systems Inc.
• Computer Associates International Inc.
• Digital Equipment Corp.
• Hewlett-Packard Corp.
• Lotus Development Corp.
• Microsoft Corp.
• NCR Corp.
• The Powersoft Division of Sybase Inc.
• SAP AG
• Siemens Nixdorf Informationssysteme AG
• Software AG

A TOG-managed DCOM will impact the ongoing evolution of the distributed object technology in a number of ways. For one, it is likely to slow down the evolutionary process since there are more players involved with the different goals and objectives that need to be mediated, look at CORBA and the Object Management Group (OMG). However, more players in the mix will also mean a more robust, more versatile technology that meets the needs and visions of a broader community. Reiterating this point, Bob Zurek, from the Powersoft Division of Sybase, states, "We are excited about the outcome of the first meeting for determining the direction of ActiveX into the world of open standards. We believe this will bring significant benefits to the customers and ISVs that have a strong investment in COM and DCOM technologies."³ Now that DCOM is now part of an open standard, albeit one hand-picked by Microsoft, developers will be more apt to seriously consider DCOM as an alternative to CORBA.

Finally, it is important for DCOM's growth to acknowledge that CORBA is not going to disappear any time soon -- there are too many industry leaders supporting the technology. So it will be necessary to close the gap between DCOM and CORBA, providing builders of distributed applications with greater flexibility. But it's not likely that DCOM and CORBA will merge into a unified architecture, at least for the near term, so DCOM-CORBA Bridges will have to suffice. Software companies like IONA and ObjectSpace already understand the marketability of such tools, as they race to be the first on the technology block to support an integrated DCOM/CORBA development environment.

Sample DCOM-based projects & applications

X mktyplib /nocpp timestamp.idl

X javatlb  /U:T TimeStamp.tlb

import java.util.*;
import com.ms.com.*;
// the timestamp package is created 
in Step 4 by the JavaTLB compiler
import timestamp.*;

class TimeStampImpl implements TimeStampIF
{


  public String getTimeStamp() throws ComException {
    Date exactTime = new Date();
      String exactTimeStr = (String)(exactTime).toString();
        return exactTimeStr;
    }

}

X jvc -d C:\windows\java\trustlib TimeStampImpl.java

// DCOM -- TimeStampClient.java

import timestamp.*;

public class TimeStampClient {

  static public void main(String args[]){

  // bind to the TimeStamp object
  System.out.println("Binding to TimeStamp object");
  TimeStampIF obj =  (TimeStampIF) new timestamp.TimeStampImpl();

  // call the getTimeStamp() method on the remote object
  String whatTimeIsIt = obj.getTimeStamp();

  // print out the time given by the server
  System.out.println("TimeStamp = "+whatTimeIsIt);

  }

}

jvc -d C:\windows\java\trustlib TimeStampClient.java

 
X javareg /register /class:TimeStampImpl /clsid:{
F4339BE2-B109-11d1-ACAF-0080C7D43C92} /surrogate 

X jview TimeStampClient