Distributed Objects Everywhere - Background

Background

In the early 1990s the 'next big thing' in computing was to use desktop microcomputers to display and edit data being provided by mainframes and minicomputers. Although a number of methods for this sort of access already existed, the division of labor was not at all even. For instance, SQL required the workstation to download huge data sets and then process them locally, whereas use of terminal emulators left all of the work to the server and provided no GUI.

It seemed that the proper split of duties would be to have a cooperative set of objects, the workstation being responsible for display and user interaction, with processing on the server. Standing in the way of this sort of solution was the massive differences in operating systems and programming languages between platforms. While it might be possible to build such a system that would work on any one combination of workstation and server, the same solution would not work on any other system.

Oddly, the differences between any two programming languages on a single platform was almost as great. Each language had its own format for passing parameters into procedure calls, the file formats that they generated were often quite different. In general terms, it was not always possible to write different portions of a program in different languages, although doing so often has real utility. The problem was not so acute on minicomputers and mainframes where the vendor often specified standards for their libraries, but on microcomputers the programming systems were generally delivered by a variety of 3rd party companies with no interest in standardization.

Nevertheless this problem was being addressed in the early 1990s through the introduction of various shared library systems. These were actually intended to ease resource use on smaller platforms, by allowing a number of programs using a common resource, like the GUI, to share a single copy of code instead of each loading a separate copy into memory. As a side effect of being able to be called from many programs, these systems also defined a standard way to call them, using an interface definition language, or IDL, to allow any language on the platform to understand the code inside the library.

Extending these systems to support remote procedure calls behind the scenes was seen as a natural evolution, providing a solution to the client/server programming problem. At the time there were a number of major projects to deliver such a system, including IBM's System Object Model (SOM/DSOM), NeXT's Portable Distributed Objects, Microsoft's Component Object Model (COM/DCOM) and many CORBA flavors. Sun, attempting to position itself as the future IBM in terms of backoffice support, felt they had to attack this market as well.