Digital Distributed Computing Environment (DCE) for Windows NT

Digital Equipment Corporation

October 1994

It's More Than a Network, It's Your Business

Emerging from the technological explosion of the 1980's and the fiscal implosion of the 1990's, today's information system (IS) professionals face increasingly conflicting demands. For companies to succeed, they must reduce the cost of doing business, while finding new ways to compete in the global marketplace. Changes in the business environment require quick response while protecting corporate investments in equipment, data, and personnel. Productivity must increase not just in the IS department, but across the corporation. A variety of types and sizes of computers scattered across the organization, including proprietary systems, applications, and protocols that don't talk to each other, must be made into a cohesive system.

The distributed computing environment (DCE) provides the key to solving today's complex IS problems within the client/server model—a model that encompasses the growing computing needs that now extend from corporate desktop PCs to corporate computing levels. Digital Equipment Corporation's DCE family of products provides customers with a complete, interoperable set of services that support a distributed computing environment as specified by the Open Software Foundation's Distributed Computing Environment (OSF DCE) standard.

Integrate Your Business with DCE

OSF DCE provides a set of integrated software services that simplify the development, maintenance, and use of distributed applications in a multivendor environment. Basic services include the following:

• Cell Directory Service (CDS). Provides the unique network addresses of named resources, such as users, servers, applications, and systems within a distributed computing environment. CDS ensures constant availability of directories and access to networked resources when they are needed. This is accomplished by way of replication of name services. Applications and users can use networked resources without concern for their physical location or whether their physical location has changed. CDS also includes an application programming interface (API) to the X/Open Directory Services (XDS). With XDS, application programmers can use a single API to gain access to both CDS and to the Global Directory Service (X.500), a powerful general-purpose distributed database service that can be used for intercell communications.
  
  
• Distributed Time Service (DTS). Keeps clocks closely synchronized in a distributed computing environment. DTS synchronizes time with Coordinated Universal Time (UTC), an international time standard that is interoperable with the Internet's Network Time Protocol (NTP). DTS enhances the dependability of a network because events occur in the correct sequence. DTS puts time stamps on applications and their procedures, which ensures operational integrity.
  
  
• DCE Security (DCES). Provides secure communications and controlled access to resources in a distributed system using authentication, authorization, and data integrity. Authentication verifies user and service identities. Authorization controls access to resources. Data integrity mechanisms protect data from tampering and nonprivileged access attempts. In this way, client support of security ensures that the integrity of application data is preserved. Security also protects applications that are interoperating across different platforms, such as a Microsoft® Windows NT™ client application using a DCE server on an OSF/1 or OpenVMS system.
  
  
• Remote Procedure Call (RPC). Lets individual procedures of an application run on systems anywhere on the network. RPC extends the typical local procedure call model by supporting direct calls in a C-like language, called the Interface Definition Language (IDL), to procedures on remote systems. Programmers can develop distributed applications as easily as they developed traditional, single-system applications.
  
  
• Threads. Provides a simple programming model for building concurrent applications that perform many operations simultaneously. A server process using threads can respond to many client requests at the same time, improving the performance of every application.

Digital Extends DCE to Windows NT

Today, Digital offers DCE on more platforms than any other vendor. Digital DCE is supported on four platforms:

• DEC® OSF/1 AXP™
  
  
• MS-DOS® Windows®
  
  
• OpenVMS VAX®
  
  
• OpenVMS AXP

With the addition of DCE for Windows NT AXP and Intel, Digital has assumed a leadership position in distributed computing by offering flexibility and choice for DCE development and use. With our proven expertise in enterprise computing and DCE, as well as early and vigorous support of Windows NT, as demonstrated by the Windows NT Alpha AXP product, Digital is ideally positioned to offer DCE on Windows NT.

Windows NT users can now take advantage of all DCE-based, enterprise-wide distributed applications in a multivendor, client/server environment. Application developers have an additional platform choice for designing and building clients and servers that can interoperate over a wide range of operating systems and networks, including the Windows NT operating system.

Digital DCE for Windows NT:

• Offers the only DCE product set today for Windows NT, including support on both Alpha AXP and Intel platforms.
  
  
• Provides base distributed computing technologies that enable the development of multivendor, client/server applications from your PC.
  
  
• Opens the Windows NT application world to the rest of the enterprise.

This new Digital DCE product extends the DCE environment to the leading-edge Windows NT platform with the full, interoperable set of distributed computing services. Version 1.0 is available today and offers the Digital DCE Run-time Services and the Digital DCE Application Developer's Kit. These components allow you to use your Windows NT system to develop distributed applications that can operate in a multivendor DCE cell. DCE on Windows NT Version 1.1 (available in late 1994) will offer DCE Security and Cell Directory Services.

In addition to the basic run-time capabilities specified by the OSF DCE standard, DCE for Windows NT includes the following enhancements:

• DCE RPC Mapped to Microsoft RPC. Transparent mapping of the OSF RPC API to the Microsoft RPC (MS-RPC) API, allowing DCE applications to be ported to the Windows NT platform by a simple recompilation.
  
  
• Support for Multiple Transports. Automatic support for all Windows NT network transports.
  
  
• CDS Tailored to Single-User System. Local name caching to speed up the time it takes to look up a resource name.
  
  
• Open, Interoperable Threads Support. Support for the POSIX 1003a.4a interface through NT threads, ensuring a standards-based thread capability as well as interoperability between NT kernel threads and DCE Threads.
  
  
• Enhanced Time Management Support. Use of the NT kernel's ability to gradually speed up or slow down the time-of-day clock without affecting applications.
  
  
• DCE Support for the NT Exception Handler. Support for DCE standard exception semantics through internal calls to the Microsoft C built-in exception handler. Programmers see DCE messages that describe what application error occurred and where.
  
  
• DCE Manager (version 1.1). A graphical tool that greatly simplifies the management and administration of a DCE environment.

For more information about these enhancements as well as other implementation details, see the "Internal Architecture" section of this document.

Digital DCE for Windows NT Packages

Digital offers the following four DCE product packages for Windows NT. The first two are included in version 1.0 of the product, and all four are included in version 1.1 of the product.

• Digital DCE Run-time Services. The Run-time Services kit allows Windows NT applications to use full, secure DCE client functions. The Run-time Services kit allows development of DCE client and server applications, through the Application Developer's kit. One Run-time Services kit is required for each system in the DCE environment. The Run-time Services kit includes the following:
  • Administrative tools
    
    
  • Time Service for both client and server
    
    
  • Remote Procedure Call Run-time (RPC) API and Library

Access to DCE Threads for developing multiprocess applications

Use of CDS for locating servers

Use of DCE Security for authentication, authorization, and data integrity

• Name service interface daemon (NSID) for communication with MS-RPC. The NSID allows MS-RPC client and server applications to perform name service operations on the full CDS namespace, in the same way that DCE RPC does.
  
  
• DCE Application Developers' Kit for Windows NT. Provides the tools required for developing DCE applications on the Windows NT operating system. These applications can then interoperate with other DCE vendors' platforms, calling on servers located on other DCE systems. The Developers' Kit includes the following:
  
  
• Digital's advanced RPC IDL compiler tool kit, offering:

All OSF DCE Version 1.0.3 features.

DEC Fortran language support on Alpha AXP platforms.

Application Template Generator—The IDL compiler uses interface definition files to generate C language templates that can be modified to create executable client and server application code.

Event Logger—A software utility that helps you debug RPC applications by logging detailed RPC data during application execution.

• Sample programs and example source code
  
  
• All DCE application programming interfaces
  
  
• DCE Cell Directory Server (CDS). Provides a consistent mechanism for naming and locating users, applications, files, and systems within a DCE cell. The CDS Server also includes the Global Directory Agent (GDA). The Global Directory Agent provides a means of linking multiple CDS namespaces via either X.500 or the Internet Domain® Name Server (BIND). Users must install the DCE Run-time Services kit on each system in the cell before installing the Digital DCE CDS Server. The DCE CDS Server also requires the installation of the DCE Security Server on a system in the same DCE cell.
  
  
• DCE Security Server. Allows users controlled access to information in a distributed computing environment safely and confidentially. The DCE Security Server accomplishes this through three services:
  
  
• DCE Authentication Service allows users and resources to prove their identity to each other. The DCE authentication service is based on Kerberos, which requires that all users and resources posses a secret key.
  
  
• DCE Authorization Service verifies operations that users may perform on resources. A DCE Registry Service contains a list of valid users. An Access Control List (ACL) associated with each resource determines valid users through the Registry Service, and the types of operations a user may perform.
  
  
• DCE Data Integrity Service protects network data from tampering. Cryptographic checksums automatically generated by RPC enable DCE to determine whether data has been corrupted in transmission.

  Users must install the DCE Run-time Services kit on each system in the cell before installing the Digital DCE Security Server. The DCE Security Server also requires the installation of the DCE CDS Server on a system in the same DCE cell.

Digital DCE on Windows NT Internal Architecture

Digital DCE on Windows NT is implemented as an integrated layer between the operating system and network, and the distributed application. As on all other Digital platforms, Digital DCE on Windows NT provides the services that allow a distributed application to interact with a collection of possibly heterogeneous computers, operating systems, and networks as if they were a single system.

Figure 1 shows DCE in relation to the Windows NT operating system, network communications software, and application software. Figure 1 also shows the DCE technology components that work together to implement the DCE layer. In Figure 1, the names of DCE services that are implemented in a different way from other Digital DCE implementations appear in italic typeface. The following sections describe these differences.

Figure 1. Digital DCE for Windows NT architecture

Secure DCE RPC Calls MS-RPC

Digital's DCE for Windows NT provides a full-function, OSF DCE–conformant RPC application programming interface (API) through MS-RPC. Digital DCE RPC ensures transparent interoperability between applications using MS-RPC and those using DCE RPC.

Digital's DCE RPC is implemented as a layer above MS-RPC. Each DCE RPC API call corresponds to an MS-RPC call. The syntactic mapping between calls is transparent to the application developer. Digital DCE RPC also returns standard DCE RPC status codes through a similar transparent mapping from the MS-RPC error status codes. Digital's layered implementation, with transparent mapping to the underlying MS-RPC API and status codes, allows porting of DCE applications easily to Windows NT while retaining source-code compatibility across open DCE environments.

Authenticated RPC, which is integrated with the Digital DCE RPC API and MS-RPC API, is implemented as a separate dynamic link library (DLL). The DCE Security implementation on Windows NT allows access to the full set of DCE Security APIs from DCE RPC. The Digital Security DLL is called by MS-RPC whenever it sends or receives an authenticated DCE RPC call.

Figure 2 shows the roles of application code, RPC stubs, and RPC run-time libraries during a remote procedure call. As in Figure 1, operational differences between the Windows NT implementation and those on other Digital platforms appear in italic typeface.

Figure 2. Execution of a remote procedure call

Figure 2 shows the client's application code making a remote procedure call and passing the input arguments to the stub for the called DCE RPC interface. The client's stub translates the input arguments from the local data representation into the network representation and dispatches the call to the client's RPC run time. On the Windows NT platform, the DCE RPC call is converted into an MS-RPC call that is dispatched by the MS-RPC run time over the network to the server's RPC run time. If the DCE RPC call includes authentication information, DCE RPC invokes the MS-RPC run time, which then invokes the Digital Security DLL. The Digital Security DLL verifies the identity of the requesting user or service and returns the information to the MS-RPC run time, after which the call is dispatched to the server.

If the server was compiled on a Windows NT platform, the server stub uses its copy of the MS-RPC run time to translate the input arguments from network to local data representation before passing them on to the called remote procedure. DCE RPC converts the call into DCE RPC syntax before passing the input arguments on to the called remote procedure. For a server compiled on a non Windows NT platform, the server stub uses its copy of the DCE RPC run time to translate the input arguments from network to local data representation and pass them directly on to the called remote procedure.

If the DCE RPC call includes authentication information, DCE RPC invokes the MS-RPC run time, which in turn invokes the Digital Security DLL. The Digital Security DLL verifies the identity of the requesting user or service and returns the information to the MS-RPC run time. The MS-RPC run time returns the authentication information to the DCE RPC call.

The procedure then executes and returns any results to the server's stub. The server's stub translates the results and passes them to the server's RPC run time. DCE RPC converts the results, which are output arguments or a return value or both, into MS-RPC syntax and passes them on to the MS-RPC run time. The run time dispatches them back over the communications network to the client's MS-RPC run time. DCE RPC converts the results into DCE RPC syntax and dispatches them to the client's stub.

The client's stub uses its copy of the DCE RPC interface to translate output arguments from network to local data representation and pass them to the calling code.

Enhanced IDL Compiler Tool Kit

Digital's DCE IDL compiler is the preferred RPC stub generator over Microsoft's MIDL because it gives applications access to all DCE services and conforms to DCE data structure standards. DCE IDL also provides all of the Digital enhancements to IDL, such as the event logger, offered in other Digital DCE products. Although MIDL compiles the majority of DCE IDL API calls, MIDL is not wholly conformant to DCE open standards. Using DCE IDL ensures application portability to any vendor's DCE environment, in any DCE cell, as well as interoperability with every other DCE-conformant application.

Compiling, Linking, and Generating UUIDs

In addition to using the DCE Application Developer's Kit tools to compile and link the DCE RPC application, some components in the Windows NT SDK must also be used. Applications must be compiled using some of the MS-RPC header files, and the MS-RPC libraries must be linked.

Unlike other Digital DCE products, Digital DCE for Windows NT does not provide the Universal Unique ID Generator (UUIDGEN). UUIDGEN is a tool that is used to generate an IDL file template that contains a new UUID. This tool is included with Windows NT as part of MS-RPC, and is therefore not provided with Digital DCE for Windows NT.

CDS Tailored to Single-User Design on Windows NT

Digital's DCE on Windows NT provides the full range of CDS services available in other Digital DCE products. As an example, the command-line control program that manages the CDS directory (CDSCP) works the same way as CDSCP on the DCE on DEC OSF/1 and OpenVMS implementations. Similarly, applications can access CDS services through two standard DCE open interfaces: the DCE name service (rpc_ns) routines and the X/Open XDS interface.

The CDS client implementation is different internally from other Digital DCE products because it uses a per-username cache to reduce calls to the server, eliminating the need for a CDS clerk process. In this way, Digital enhanced the original DCE CDS internal design, which is based on a time-sharing paradigm, to take advantage of the single-user design of the Windows NT operating system. This implementation features greater security and response time for each CDS call due to a restructuring of the original CDS clerk process, which essentially tailors CDS naming lookups according to each individual user's most commonly used names. Digital's internal restructuring of CDS affords better response time and security while preserving both the standard semantics of CDS API calls used in all other DCE environments as well as external control program commands.

Figure 3 illustrates the use of per-user name caches on an RPC client call to look up a name in CDS. The first name lookup on behalf of user 1 searches the CDS namespace server for the name. Once that name has been looked up, subsequent lookup requests from user 1 for the same name are made to the CDS user 1 name cache.

Figure 3. CDS name lookups

Open, Interoperable Threads Support on Windows NT

The Digital DCE on Windows NT Run-time Services implementation of DCE Threads, or pthreads, ensures a standards-based thread capability and interoperability between Microsoft's Windows NT threads and DCE Threads:

• Standards-Based. DCE Threads are conformant with POSIX P1003.4a Draft 4.
  
  
• Interoperable with Microsoft Windows NT Kernel Mode threads. DCE Threads provides a one-to-one mapping of a DCE thread to a Windows NT kernel mode thread.

Microsoft applications that use Windows NT threads can continue to use them while calling DCE services, and new application modules can be written using DCE pthreads.

Figure 4. One-to-one mapping of DCE threads to Windows NT kernel mode threads

Enhanced Time Support on Windows NT

The implementation of DCE DTS for Windows NT takes advantage of the enhanced Windows NT kernel's ability to speed up or slow down the time-of-day clock that synchronizes one system with the rest of the cell. In previous versions of Windows NT, the clock could be moved forward or back but the tick rate could not be changed. The newest NT kernel enhancement allows DTS to make time changes gradually without affecting applications. This important enhancement means that time stamps are always advancing and the correct ordering of distributed events can be determined.

Integration with Windows NT Exception Handler

In Digital DCE on Windows NT, DCE status codes and exceptions are closely integrated into the Windows NT environment so that application programmers see standard DCE text messages that describe what error occurred and where. DCE status codes are implemented as native Windows NT message codes by the mapping of IDL error status data types to native NT messages, providing transparent translation of messages. This implementation allows DCE applications full use of the superior Windows NT structured exception handler while preserving the appearance of standard DCE messages. The DCE exception semantics are primarily supported through calls to the Microsoft C built-in exception support.

Simplified DCE Management

As part of DCE V1.1 on Windows NT, Digital provides the DCE Manager—an intuitive, easy-to-learn graphical user interface (GUI) for managing a DCE environment. DCE Manager lets you perform the following functions:

• Manage user accounts and security groups.
  
  
• Create and delete CDS directories, and easily specify where failover replicas of a CDS directory are to be stored.
  
  
• Edit access control lists (ACLs) of CDS objects and application objects.
  
  
• Register computers as members of a DCE cell from your desk, without giving out an administrative password.

DCE Manager offers a highly task-oriented, streamlined management model. For example, a user can be added to a cell by choosing one command and answering three or four questions. DCE Manager also comes with extensive, cross referenced online help.

DCE Manager runs under the Daytona release (version 3.5) of Windows NT. However, it can manage all kinds of DCE hosts because it uses standard DCE protocols.

Support for Multiple Transports

By basing the DCE RPC run time on MS-RPC, Digital's fully integrated software automatically supports all of the current and future MS-RPC transports. Network transparency is ensured for both the user and the application developer because client/server applications can interoperate over the following network protocols:

• TCP/IP
  
  
• UDP/IP
  
  
• Windows NT local RPC
  
  
• Named Pipes
  
  
• NetBEUI/NetBIOS
  
  
• IPX/SPX
  
  
• DECnet™ Phase IV

Digital DCE RPC supports DECnet when Digital Pathworks for Windows NT is installed. Due to limitations in MS-RPC, authenticated RPC over datagram transports (such as UDP and IPX) is not supported in the current release.

Hardware and Software Requirements

• Digital DCE for Windows NT is supported on any system that supports Windows NT Version 3.5 (Daytona).
  
  
• Requires Windows NT SDK.
  
  
• MS-RPC and Windows NT Threads are provided by Microsoft with the Windows NT operating system.
  
  
• Pathworks for Windows NT Version 5.0 is optional.

___________________________________
Copyright 1994 Digital Equipment Corporation. All rights reserved.

The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document.

Alpha AXP, DEC, DEC Fortran, DEC OSF/1, DECnet, Digital, OpenVMS, and VAX are trademarks of Digital Equipment Corporation.
OSF and OSF DCE are trademarks of the Open Software Foundation.
Microsoft, MS-DOS, and Windows are registered trademarks and Windows NT is a trademark of Microsoft Corporation.
UNIX is a registered trademark of UNIX Systems Laboratories.
X/Open is a trademark of X/Open Ltd.
Kerberos is a trademark of Massachusetts Institute of Technology.
Intel is a registered trademark of Intel Corporation.