FEATURES

DCE: Unifying Your Network Fabric

Running TCP/IP services on your systems gives you lots of things--such as Internet standards (and, more importantly, vendor-supported products) for functions such as e-mail, printing and file transfer--but among the pieces missing are some of the most important ones. For example, there are no standards for user and group management, advanced security or a directory service that ties these together. Without these components, you'll never be able to migrate your organization completely or your network computing environment to a truly open one.

You can use proprietary technologies to get these services, but you'll pay the price in terms of limited cross-platform availability and support. For example, you may be able to use Network Information Services (NIS) and/or NIS+ on some of your U nix systems, but you won't get it on your big iron. Likewise, you can use Novell Directory Services (NDS) to provide these services on your NetWare systems, but that won't help with your other platforms. The resulting scenario is one where you still have to manage individual accounts and security controls on each specific platform.

These high-level services are part of what the Distributed Computing Environment (DCE) was designed to provide. The base suite of DCE services consists of a directory and related security controls; combined, they offer a consistent interface to any system DCE runs on, and the list is long. In addition, a solid set of development application programming interfaces (APIs)--another standard part of the DCE distribution--provides a platform-independent network development interface that permits rapid development and deployment of network-centric applications, regardless of the underlying OS protocols or network APIs. Together, these services and APIs constitute a general-purpose net working platform that serves as a somewhat homogeneous interface to your heterogeneous network.

The key word in that sentence is "somewhat." Although a variety of DCE implementations exists, there are some significant gaps in the roster of supported platforms. For example, you can get DCE clients and servers for almost all large-scale systems on the market, as well as for the most popular client platforms. However, there are absolutely no DCE products that run on NetWare or on most second-tier Unix variants. Nor are there many off-the-shelf applications that take advantage of DCE, making it difficult to assemble a full top-to-bottom implementation.

Regardless of these limitations, for platform-independent network-centric services and applications, DCE outshines any other technology on the market. By deploying DCE services on your diff erent systems--and by using DCE for your cross-platform applications--you can dramatically increase the overall functionality and security of your network, while simultane ously reducing your system management costs.

In the Beginning, There Was the Standalone System As most of you will remember, the LAN wasn't always there. But that didn't stop users from trying to link disparate systems by building cross-platform bridges. Vendors saw this need for network services and responded by trying to lock in their accounts to proprietary networks (along with their proprietary host systems), making the situation worse. Now, each system not only used incompatible security, file system and other critical services, they also used incompatible network protocols.

If you had an order-entry system that ran on a Unix server, a manufacturing control system that ran on a Hewlett-Packard Co. HP-3000, an inventory system that ran on Digital Equipment Corp. VAX and a consolidated billing system that ran on an IBM Corp. mainframe, you had no hope of tying everything into a functional, cross-platform environment. Your best bet--and a solution still implemented at many companies--was to use batch transfers to move data files among systems in hope of automating the process enough to work at least marginally well.

Then, in an act of rare cooperation, a handful of larger system vendors got together to establish network services that would run on any platform or protocol, thereby providing an avenue for the development of cross-platform network-centric applications. Rather than force users to consolidate their heterogeneous systems or network services on a single vendor's proprietary technologies, they gave users vendor-independent tools for integrating their disparate systems.

In 1988, these same vendors launched the Open Software Foundation (OSF), whose task was to develop vendor-independent technologies to foster such objectives as DCE, OSF/1 (a standard Unix) and standard interface systems (Motif, for one). Though many eff orts did not succeed, DCE generally has been accepted by OSF's members and outside organizations alike.

OSF projects must go through a series of technology-feedba ck cycles. Member organizations (of which there are now more than 200) contribute technology to OSF, which then turns the work into distributable code. The members license the resulting source code from OSF, and then integrate it into their respective operating systems and networking products. The result is a highly uniform code base that accommodates high levels of interoperability. Since vendors use the same source code in their products, there is negligible incompatibility among the various implementations, and even less finger-pointing should something go awry.