Distributed Objects Everywhere: Difference between revisions

Revision as of 03:33, 10 December 2006

Revision as of 18:04, 13 December 2006

Line 2:

== Background ==

In the early 1990s the 'next big thing' in computing was to use desktop [[microcomputer]]s to display and edit data being provided by [[mainframeMainframe computer|mainframes]]s and [[minicomputer]]s. 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 emulator]]s 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 system]]s and [[programming language]]s 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 language]]s on a single platform was almost as great. Each language had its own format for passing parameters into [[procedure call]]s, 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 [[minicomputer]]s and [[mainframe]]smainframes 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.