Interconnecting Personal Computers with the Distributed Computing Environment

Table of Contents

Acknowledgements....................................................................................................... ii

Abstract............................................................................................................................ iii

Table of Contents.......................................................................................................... iv

List of Figures................................................................................................................. vi

1. Introduction................................................................................................................. 1

1.2 The challenges...................................................................................................... 1

1.3 Why DCE?............................................................................................................. 5

1.4 Programming in the DCE world.......................................................................... 7

1.5 What about the future?....................................................................................... 10

2. Choosing Platforms................................................................................................ 11

2.1 Microsoft DOS and Windows 3.x...................................................................... 11

2.2 Microsoft Windows 95........................................................................................ 17

2.3 Microsoft Windows NT....................................................................................... 18

2.4 IBM OS/2 and Apple Macintosh........................................................................ 19

2.5 OS choices conclusion....................................................................................... 20

3. What You Need......................................................................................................... 22

3.1 Supported protocol stacks................................................................................. 23

3.2 Development kits................................................................................................ 24

3.3 Hardware............................................................................................................. 25

3.4 Summary of what you need................................................................................ 25

4. Third Party Tools...................................................................................................... 27

4.1 Digital DCE for Windows NT and Windows 95............................................... 27

4.2 Gradient’s PC/DCE............................................................................................ 29

4.3 Hewlett-Packard OODCE.................................................................................. 30

5. Porting An Existing OSF DCE Application to Microsoft Platforms (BINOP) 31

5.1 Straight Microsoft................................................................................................ 32

5.2 Full DCE.............................................................................................................. 36

6. The Future (Is Sooner Than You Think)............................................................. 41

6.1 DCOM.................................................................................................................. 41

6.2 CORBA................................................................................................................ 46

6.3 WWW and DCE.................................................................................................. 48

7. Conclusion................................................................................................................ 52

Glossary.......................................................................................................................... 55

References..................................................................................................................... 57

Appendix A: BINOP Source Code........................................................................... 59

1. Introduction

This thesis seeks to demonstrate that personal computers (PC’s) can be integrated into the Distributed Computing Environment (DCE) and to illustrate the compromises that exist among various methods of such integration. The thesis was initially conceived as a tutorial on porting DCE applications to PC’s. It was also to provide a guide to writing applications that are generally portable across all DCE and environments that support Remote Procedure Calls (RPC). As work on the thesis progressed, it became clear that it would be necessary to not only examine ways that PC’s can be integrated into DCE, but also to explore the role of personal computers in distributed computing in general.

1.2 The challenges

Most computing environments deployed within businesses, schools, universities, and other organizations today are heterogeneous in nature. That is, no one vendor’s products are used exclusively to meet all of the computing needs of all users within these organizations. Some sub-groups may use Unix workstations from a variety of vendors, including Sun Microsystems, Digital Equipment Corporation, Hewlett Packard, and many others. Some may use IBM standard personal computers, running such operating systems as Microsoft DOS, Microsoft Windows, Microsoft Windows 95, Microsoft Windows NT, IBM OS/2, or one of many versions of Unix. It is also the case that these personal computers may be obtained from a wide selection of vendors. Some users may use mainframes or minicomputers (such as IBM’s AS/400) from IBM and other sources. In addition, many users may use some or all of these platforms at various times for differing tasks, since some platforms tend to be used for specialized purposes.

Yet, with this dizzying array of heterogeneous hardware, peripherals, and software, there exists a need for interoperability. The information contained on one system may be needed to perform an analysis on another system. Although data may have many representations on the disparate platforms (e.g., EBCDIC or ASCII), the information stored on each of these systems must be made to cross the boundaries among machines. That is, the increasingly naïve users of computing systems should not have to be concerned with the technical details regarding the way data is stored or even where it is stored. They should simply be able to find and utilize the information that they seek.

Although typical computing environments are composed of a mix of platforms, these platforms are typically interconnected through some form of network. A larger heterogeneous network may be composed of locally homogeneous subnetworks, each operating over a possibly unique topology (e.g., ATM, ethernet, or token ring) and a possibly unique protocol (e.g., TCP/IP, IPX, Netbios, Netbeui [Netbios Extended User Interface], DECnet, etc.). However, the subnetworks that comprise this larger network are all typically interconnected via bridges and gateways to form an intranet (which may, in fact, be connected to the global Internet). This configuration allows an organization to exchange information among its component platforms, as long as the data can be coaxed into a format appropriate for its destination platform. Of course, moving data from platform to platform can be a significant problem in and of itself. It may require translation from one encoding scheme to another (such as big-endian notation to little-endian notation) and perhaps from one application’s proprietary format to another (such as Wordperfect to Word).

Moreover, performance problems can arise if large quantities of data are to be transported across the network to be operated upon by a remote computer. This can be a very time-consuming process and can quickly use up all available bandwidth (the capacity of a network to transport data) if it is a common occurrence. This may result in performance issues for all users of the network, not merely for the user or set of users who require the transport of the data in question.

The task for programmers to make all disparate platforms and networks work seamlessly together is immense. What is really needed is a way for programmers to write programs in the way they are accustomed (i.e., with the assumption that data and code dwell on the same physical machine), while remapping the programmer’s code to work across the network.

Users also benefit from the concept of transparency. A typical user of a computer system simply wishes to get work done. That is, the user wants to know about some information and perhaps put it together with other information that exists elsewhere on the network. It should not be up to the user to discover which physical machine or computing platform happens to house this information. Rather, the user should employ the same means when working with data that is stored on the network or on the local workstation.

The problems presented by heterogeneity of hardware platforms and operating systems, limited communications bandwidth, and the need to transparently code distributed systems are far from trivial. In the past (and even today), distributed applications have been built without regard to previously developed applications. These applications are usually written utilizing the TCP/IP protocol (e.g., web browsers), the IPX protocol (e.g., Novell Netware file servers), or some other custom protocol. This has resulted in systems that are limited with regard to platform and/or operating system, and which required highly specific expertise on the part of applications developers. For example, many Novell Netware applications have not survived the recent and swift conversion to TCP/IP. These problems beg for an abstraction layer which hides the specifics of individual protocols from the application developer and which allows the developer to write code with little regard for whether code executes on the local machine or on another machine located across the network.

The client/server style of coding helps the developer to make this abstraction. The developer creates a client application that provides, minimally, a user interface. The client application relies upon a server that may be located remotely to do some or all of the actual computing work. This distribution of computing effort allows the server to run in closer proximity to the data on which it operates, perhaps on the same physical machine. This can reduce the bandwidth problems discussed earlier. However, without some additional layer of abstraction, the distribution still does not free the developer from many of the details of wire protocols and platform dependencies.

1.3 Why DCE?

The Open Software Foundation (OSF; now called the Open Group [22]) has developed a standard for distributed computing called the Distributed Computing Environment (DCE). DCE is rapidly becoming the standard for the interoperation of heterogeneous computers that run some implementation of the Unix operating system. In fact, DCE run-time services are being incorporated into the base operating systems support provided by many manufacturers. DCE allows clients on one platform to access servers on another, without regard to the hardware, operating system, or available network transports between and among the cooperating machines. In theory, this frees the application developer from mundane tasks and provides a layer of abstraction on which to rest the development process: The application developer creates a client and a server, each of which should be able to run on any platform, operating system, or transport.

In practice, this works quite well for many of the operating systems that support DCE. These include Digital Equipment Corporation’s line of Alpha workstations running Digital Unix, HP systems running HP/UX, IBM’s RS/6000 line running AIX, Silicon Graphics machines running IRIX, Cray Supercomputers, and even Sun workstations with the addition of some third party software. In many environments, these platforms can co-exist using DCE very effectively. However, many real environments today, both academic and commercial, contain large numbers of personal computers based on the IBM standard using Intel processor chips. The vast majority of these machines run Microsoft Corporation operating systems; primarily Microsoft DOS, Microsoft Windows 3.0 and successors (a.k.a. Windows 3.x), Microsoft Windows 95 and its successors (a.k.a. Windows 9x), and Microsoft Windows NT. In order to make a DCE application available to the greatest number of users, the client portion (at least) must be made to run on the various Microsoft-based operating systems.

Microsoft itself has recognized the need for its operating systems to function in the DCE world. To facilitate this, Microsoft provides support for the core component of DCE; the remote procedure call (RPC; see [19]). The RPC is a standard way to create a procedure which runs on a server that can be called from a client just as though this procedure were a normal procedure, local to the client. In the case of DOS and Windows 3.x, this support is in the form of a toolkit of redistributable dynamic link libraries (DLL’s) that can be freely added to machines running one of these operating systems. In the case of Windows 9x and Windows NT, support is built into the system itself.

However, Microsoft’s implementations of RPC’s are not based on the Open Group’s source code for DCE, as are most other manufacturers’ implementations. Worse, Microsoft does not provide interoperability with other DCE functions that are standard in true DCE environments. Such important functions as Cell Directory Service (CDS), security service, Distributed Time System (DTS), and DCE threads are unavailable in current Microsoft operating systems. CDS provides a mechanism for discovering services which are available within a DCE cell. DTS is a service which keeps time accurate and consistent among the cell members. The security service provides authentication and encryption capability, and DCE threads are the standard POSIX threads which allow multiple threads of execution within a single program.

Due to the limited compatibility, many programs originally written for the DCE environment cannot be run, or even compiled, on Microsoft platforms. The goal of this paper is to explore ways that the popular PC environments can function as a part of the Distributed Computing Environment. In some cases this entails adding additional software to these platforms, writing work-around code to deal with incompatibilities, and sometimes even submitting to a loss of functionality. Each of the popular PC environments has its own challenges and limitations.

1.4 Programming in the DCE world

The Distributed Computing Environment runs best and is fully functional on a variety of Unix based platforms and the IBM mainframe systems (e.g., AS/400, VM, and OS/390). By fully functional, it is meant that all of the standard DCE services are available on these platforms. The basic services (see [14]) include the Cell Directory Service (CDS), the Distributed Time Service (DTS), security services, Remote Procedure Calls (RPC), and the Distributed File System (DFS). A fully featured DCE client machine has a CDS clerk (a clerk is a process running on a client machine which provides access to a given service), a DTS clerk, a Security clerk, DFS client software, and a DCE runtime library. Each DCE server system may have some or all of the client software, plus it may include a CDS server, a DTS server, a DFS server, and a Security server.

A typical developer of a DCE application can assume that most or all of these services are available to his or her program. Furthermore, since DCE has grown out of Unix and Unix-like environments, the developer typically assumes that standard Unix operating systems calls and standard ANSI C library support is available. In general, it is assumed that the target system is POSIX compliant.

POSIX is an attempt to standardize the disparate flavors of Unix. It is a set of IEEE standards (IEEE 10003.0 to 10003.22 a.k.a. POSIX level 0 to POSIX level 22) which define minimal requirements for an operating system to be considered compliant. There are several levels of POSIX compatibility. One of the serious problems for writing applications which function across Unix and PC platforms is that most PC platforms are not strictly POSIX compliant. Even Microsoft Windows NT (NT) is merely POSIX level 1 compliant. Since threading, for example, is not a requirement until POSIX level 4a, applications running on NT cannot presume thread support.

An even more difficult problem is NT’s support for POSIX. POSIX on NT is implemented as a compatibility “subsystem”. Windows NT was designed with a protected kernel that provides basic operating system services. On top of this kernel, a layer of subsystems is provided which run as standard user mode applications (see Figure 1). These subsystems add richer functionality that is not available directly from the kernel. Supplied with the OS, are OS/2 and POSIX subsystems. These subsystems are on an equal footing with standard Win32 applications in terms of services available to them. However, these subsystems have their own executable formats. They cannot be linked with standard libraries available to typical Win32 applications.

Figure 1: Microsoft Windows NT Architecture

From “The Foundations of Microsoft Windows NT System Architecture” whitepaper by Microsoft Corporation, September 1997.

Since POSIX applications cannot link to standard Win32 libraries, they cannot take advantage of the rich functionality available to typical Win32 applications. Since there are few libraries available for the POSIX subsystem, POSIX applications are reduced to the role of poor step-relatives when compared to their Win32 counterparts. Further confounding the situation, is the fact that DOS, Windows 3.x, and Windows 95 do not even purport to be POSIX compliant, as does NT.

1.5 What about the future?

It seems clear that DCE will continue to be important for the foreseeable future. While arguments about what to distribute (e.g., the current concern with distributed object technology) may continue, there seems to be little question on the choice of whether or not to distribute. The major camps regarding distributed objects both support DCE after a fashion. The Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA) (see http://www.omg.org/corba/corbiiop.htm) standard contains provisions for interoperation with DCE. Microsoft’s Distributed Component Object Model (DCOM) sits securely atop DCE’s RPC. The Open Group has recently published standards for interoperation of the World Wide Web (WWW) with DCE (see http://www.camb.opengroup.org/RI/www/dceweb/). Each of these is further examined in Section 6.

DCE has been making great strides into corporate America and the world as well. As downsizing and right-sizing continue to drive companies away from completely centralized databases and applications, client-server and peer computing have made DCE an attractive standard. As DCE continues to penetrate corporate America, it will become increasingly important for personal computers (deployed on great numbers of corporate desktops) to be able to participate as standard DCE platforms. This project demonstrates that it is possible for personal computers to fulfill this role, with varying success, depending on the operating system and third party tools available.

2. Choosing Platforms

Software developers who wish to deploy distributed applications must make allowances for the operating systems and platforms that are deployed within their target organizations. Although the developer may wish to leverage DCE, the target platforms may not support DCE, or may support it only partially. Nonetheless, few organizations can afford to replace large numbers of systems, and this may require that developers find ways to integrate existing platforms into their solutions.

2.1 Microsoft DOS and Windows 3.x

The Microsoft Disk Operating System (DOS) and the windowing system that runs on top of it, Microsoft Windows 3.x, are very nearly ubiquitous in the PC environment. Almost every PC ever made has been bundled with some flavor of DOS (including some compatible non-Microsoft versions such as products from IBM and Digital Research). Since the introduction of Microsoft Windows 3.0, almost all PC’s are also bundled with Windows. Windows 9x and Windows NT have replaced DOS and Windows 3.x (see Figure 3) in recent years in bundles with new machines. However, the two-headed operating system of DOS/Windows 3.x remains deployed on vast numbers of corporate, academic, and home personal computers (see Figure 2).

Figure 2: Share of US PC’s Using Top Four Operating Systems

From Computer Intelligence InfoBeads study. Used in accordance with “InfoBead End-User License Agreement” (see http://www.ci.infobeads.com/InfoBeads/Pages/Viewer/VIEWER_REGISTRATION.ASP?INFOBEAD_ID=C0000938AA )

Figure 3: 1997 OS Shipments With PC Systems Worldwide – Market Share

From Computer Intelligence InfoBeads study. Used in accordance with “InfoBead End-User License Agreement” (see

http://www.ci.infobeads.com/InfoBeads/Pages/Viewer/VIEWER_REGISTRATION.ASP?INFOBEAD_ID=M0000913AB )

These facts might lead one to the conclusion that any project seeking to integrate personal computers into the world of the DCE would need to include support for DOS and Windows 3.x. Unfortunately, these operating systems were not designed with remote computing in mind, and therefore do not support many of the features that make it possible to fully integrate them with DCE.

There are, however, “work arounds” that allow some degree of interoperability for these operating systems. Microsoft provides a freely distributable product called Microsoft Remote Procedure Call Run-time that adds basic RPC functionality to DOS and Windows 3.x, but lacks all of the other standard DCE services. By installing the Microsoft Remote Procedure Call Run-time on a DOS or Windows 3.x workstation, some very simple DCE applications can be made to run in this environment. However, as shall be discussed later, such an application not only suffers from the lack of the aforementioned DCE services, but may also require a significant porting effort to compensate for differences in system calls, and general lack of POSIX compliance displayed by this environment.

2.1.2 Third party solutions

Another possible way to bring DOS/Windows 3.x into the DCE fold is through a set of commercial products from Gradient Technologies, Inc. (see http://www.gradient.com/Products/Pc-dce/dce_frt.htm) collectively called PC-DCE. PC-DCE consists of the PC-DCE Runtime Kit which must be installed on each workstation that runs a DCE application that has been ported using PC-DCE plus an Application Developer’s Kit which provides all of the tools (e.g., IDL compiler, UUID Generator, l