Dispelling the Myths About DCE

By Ram Sudama,
Vice President of Technology and Chief Architect
Open Environment Corp.

Is DCE dead, or is it just a well-kept secret? Many companies that have chosen not to implement the DCE standard have hesitated in the face of numerous myths surrounding the technology. Perhaps the three most common myths are: it's complicated, it's too hard to use and manage, and it lacks market acceptance. Actually, many DCE applications are being developed and deployed in large organizations. What seems to mystify the masses is simply that the basic features and functions of DCE just aren't well known.

A Catch-22

DCE became widely available across most platforms in 1994, but still suffers from the lack of end-user applications to drive its visibility and deployment. Independent software vendors, or ISVs, have historically played a vital role in the success of new technologies. However, they aren't likely to add support to their products for any new technology until they see a significant installed base. A clucking chicken-and-egg dilemma. Despite this, a number of large and small vendors have already moved to support DCE in their products. The principal movers in the area of distributed computing, with products existing or planned for DCE, include such heavy hitters as IBM, Hewlett-Packard, Digital Equipment Corp., Siemens-Nixdorf, Microsoft, AT&T, Tandem and Transarc. All of which makes DCE perhaps one of the most widely implemented standards in the world, after TCP/IP. There are also a growing number of smaller vendors providing DCE product support: Open Environment, Open Horizon, Gradient Technologies and Dazel Corp., to name just a few. Although OSF had to cancel the Distributed Management Environment (DME) project, DCE management products still provide needed management support. Available are Hewlett-Packard's DCE Manager for OpenView, IBM's DCE Manager for NetView, HaL Computer Systems' DCE Cell Manager, Digital's DCE Cell Manager, SCO's Distributed Administration Service and Open Environment's Entera.

The real market for DCE today, however, lies in custom business applications. These are the applications that used to be run on the corporate mainframe, and are increasingly being implemented using distributed computing technology. DCE is the ideal solution for such applications because it has the state-of-the-art network security, reliability and scalability that's essential for successfully implementing enterprise-wide information systems.

A DCE Complex

DCE encompasses a large, complex set of distributed computing services. It's not uncommon for any complex system to expose interfaces that provide numerous functions and options. DCE is therefore not for the faint of heart. DCE was originally designed to be programmed by sophisticated C programmers. Fortunately, tools like Open Environment's Entera now make it possible to access DCE using such languages as COBOL, Visual Basic, PowerBuilder, C++, Smalltalk, or from applications such as Excel and Microsoft Word and so on. Such tools extend DCE's reach to the widest audience of commercial application developers.

These tools also automate the use of all the DCE services, so developers can focus on their applications, not on mastering the subtleties of using DCE. Some companies, like the Federal Home Loan Mortgage Corp. (better known, perhaps, as Freddie Mac), have been developing sophisticated, three-tiered client/server applications for several years. Freddie Mac used Open Environment's Entera to integrate many different platforms, tools and data sources into useful business solutions and soon expects to migrate existing applications to DCE. According to Jim Thompson, chief technical architect at Freddie Mac, "Three-tiered distributed computing enhances our ability to implement creative business solutions and hence gain a competitive advantage. Entera will make it easy for us to move to DCE, which we consider to be the most reliable and secure way for us to do business as we move forward."

Myth of Missing Platforms

Only a few major platforms do not support DCE, and the lack of DCE support on platforms such as the Macintosh has been a barrier to DCE deployment. Open Environment's DCE Adapter product allows the Macintosh to run DCE client applications without actually installing DCE on the desktop. Boston College is one institution that has been held back from deploying DCE by the lack of support for their many Macintoshes. Jaqui Lynch, manager of systems services at Boston College, said, "We're very excited now that a major barrier to using DCE has been removed. We can now start planning the deployment of a DCE infrastructure, and connect all our desktops to this environment through the DCE Adapter."

Messaging Misunderstood

Yet another myth concerns messaging. Many people don't understand the relationship among messaging, queuing and RPC communications. In terms of services, both RPC and messaging perform essentially the same function. They transfer data from one application to another. The important difference between RPCs and messaging is that RPCs provide a high-level language interface, while messaging and message queuing provide a low-level API. With the addition of threads in DCE, the DCE RPC can implement asynchronous communications such as messaging services.

Some message-queueing products do provide communications semantics, such as store-and-forward messaging or delayed execution. Although these are not provided directly in DCE today, they could, in fact, easily be layered over DCE RPC. By doing this, developers would still get the benefit of having a common set of directory and security services as well as the additional communication functionality.

Transactional Support

Not only is there a specification for transactional extensions to DCE RPC available from X/Open, but almost all the transaction monitors gaining in popularity today now support the use of DCE RPC. As an example, Citicorp has been working on building large-scale transaction processing systems using DCE with Transarc's Encina Monitor and Open Environment's Entera development tools.

A Standards Question

To comply with DCE, a vendor doesn't have to base its product on source code obtained from the Open Software Foundation. Like other open standards, specifications exist for both the DCE APIs and DCE network protocols.

Products conforming to these specifications are DCE-compliant. As an example, Microsoft has been shipping an RPC bundled with Windows NT for several years that is fully DCE-compliant. Digital has ported all the DCE services to Windows NT using Microsoft's RPC. Microsoft already provides RPC support for Windows NT, Windows 3.1, DOS and Macintosh and plans to provide its DCE-based RPC in Windows 95. In addition, the DCE RPC specification is the basis for the COM protocol used in Microsoft's future Distributed OLE. With its huge customer base carrying considerable clout, Microsoft's efforts should significantly accelerate the deployment of DCE. And rightly so.

Clearly, DCE is the most advanced way of building IT solutions available in the industry today. At last we have a truly open standard that supports all the major requirements of large-scale distributed computing. Hopefully, the ranks of the misinformed will shrink rapidly and not delay this new era of open information access.

Ram Sudama was featured at the OSF DCE Users & Developers Conference.