FEATURES

DCE: Unifying Your Network Fabric

Product Availability Ultimately, DCE's success will hinge on OS vendors' willingness to integrate DCE services into their operating systems to provide a mapping among the Remote Procedure Call (RPC) interfaces and the underlying protocols, as well as allowing the higher-level services to run on their specific hardware. Some may choose to tie the underlying user account database directly to the DCE security services, while others may maintain separate databases.

Gradient Technologies' Unix versions of DCE, for example, integrate seamlessly into the system login mechanisms, but its PC-DCE/32 for Windows NT does not--an obvious problem for NT security vendors that cannot get the necessary APIs from Microsoft Corp. If you're forced to maintain separate account systems, there's little value in using the DCE model, as it only increases your workload.

However, if you have DCE services implemented on more than two o r three platforms, the payback curve begins to bend in your favor, since you only have to add the user to the DCE system once. As you move toward more DCE-enabled services, you depend less on the native underlying services and more on those provided by DCE, meaning minimal direct account management on the actual end systems.

Almost every major multiplatform vendor offers DCE across its entire OS line--a good thing, since most of the platforms are incompatible. For example, IBM offers DCE products for MVS, OS/400, AIX, OS/2 and even Windows. Since it supports such a variety of platforms, IBM is a natural beneficiary of DCE's functionality. Without it, IBM wouldn't be able to interconnect its range of systems, or at least not to the extent possible with DCE. Others, such as HP and Digital, also offer DCE services across their product lines, thus helping customers integrate a variety of systems, while also enabling the vendors to integrate their own products. Digital, having pinned a portion of its product st rategy on NT, supports DCE on NT in order to integrate it with its VMS and Unix platforms.

The vendors that provide the weakest support for DCE are those that do not have incompatible platform lines. For example, Microsoft's Windows clients and servers all incorporate the same basic LAN Manager technology. Without a pressing need for a cross-platform set of self-integrating services, Microsoft has not been a notable producer of DCE technology. Similarly, vendors such as Novell and Sun Microsystems that offer a single OS don't support DCE directly at all. Sun relies on third parties, such as Transarc Corp., to provide DCE services to its customers. There are no NetWare server-based DCE solutions whatsoever, neither from Novell nor third parties. This is perhaps the single greatest limitation with DCE. If the most popular network operating system on the planet doesn't have any DCE security or directory services, it becomes very difficult to create a single, homogeneous interface to the entire network.

Ne tWare issues aside, many non-OS vendors make their living selling DCE on a variety of systems. Gradient sells DCE for an assortment of platforms, including Apple Computer Macintosh and Windows clients, as well as NT, Sequent Computer Systems, NCR Corp., Unisys Corp. and UnixWare servers. Other companies, such as Open Horizons, offer middleware products that bring DCE functionality to non-DCE applications, implementing aspects such as single sign-on and directory integration components.

How DCE Works DCE consists of two key pieces: the network services that provide for tasks such as unified account and security controls, and the APIs that enable external applications to communicate with these services (see "A DCE Communications Path," above). In addition, DCE provides a directory capable of acting as a global naming service for the networks in your LAN. It also offers cross-platform account management services, which brings the Holy Grail of single-sign-on services for any and all DCE-enabled syste ms to your network.

There are five core components of DCE--security, directory, time synchronization, RPCs and POSIX threads (see "Core Components of DCE," below). Each contains several subcomponents and technologies supplied either by OSF's member organizations or based on standards already defined and managed by other "standards" organizations.

The five key components are tightly integrated and rely heavily on each other to provide consistency and base functionality. The directory service, for instance, depends on the time service to guarantee consistency within the various directory database elements, while the security mechanisms rely on the time services to guarantee accuracy within the various events. In fact, these three services represent the core functionality of the DCE services environment that end users interact with most.

The RPCs and POSIX threads are there principally for application developers. Developers may use RPCs as network APIs to avoid inconsistent implementations of network p rotocol APIs. This way, a developer can write networking services directly to the RPC interface, without worrying whether the underlying protocol is IP, IPX or SNA. Also, by providing a standard thread model within the specification, developers can incorporate consistent thread and process management routines within the network portion of their applications, regardless of the thread model on the underlying OS.