Content deleted Content added
m remove NPOV text |
various cleanup |
||
Line 3:
In the early 1990s the "next big thing" in computing was to use desktop [[microcomputer]]s to display and edit data being provided by [[mainframe]] 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 [[terminal emulator]]s did all of the work on the server and provided no [[GUI]].
It seemed that the proper split of duties would be to have a cooperative set of objects,
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 accute on [[minicomputer]]s and [[mainframe]]s 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.
Extending these systems to support [[remote procedure call]]s behind the scenes was seen as a natural extension, and solution to the client/server programming problem. At the time there were a number of major projects to delver 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.▼
Nevertheless this problem was being addressed in 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.
Sun's solution was based on work in their [[Spring operating system]], which used intercommunicating objects for almost all programming tasks. Modifying this to work under a "traditional" Unix like Solaris was not all that difficult, although Unix makes the assumption that all programs run locally, and an interface for remote access had to be added. For this, DOE added an [[object request broker]] (ORB) that ran on the backoffice servers, listening for DOE requests and handing them off to the proper program to be handled.▼
▲Extending these systems to support [[remote procedure call]]s behind the scenes was seen as a natural
▲Sun's solution was based on work in their [[Spring operating system]], which used intercommunicating objects for almost all programming tasks. Modifying this to work under a "traditional" Unix like Solaris was not all that difficult, although Unix makes the assumption that all programs run locally, and an interface for remote access had to be added. For this, DOE added an [[object request broker]] (ORB) that ran on the backoffice servers, listening for DOE requests and handing them off to the proper program to be handled. During development, CORBA became a key [[buzzword]] in the industry. This prompted a delay while the ORB was re-engineered for CORBA support. Under the CORBA model, different objects, like those from DOE or SOM, would be able to interact by sharing a common interface.
A bigger problem for Sun is that they had no integrated desktop object programming solution. Although [[C++]] was common, their own [[SunView]] and [[Solaris]] operating systems were all "plain C" based. In order to supply a comprehensive and flexible object programming solution, Sun had turned to OpenStep. The idea was to have OpenStep programs calling DOE objects on their servers, providing a backoffice-to-frontoffice solution on Sun machines. OpenStep was only released in 1993, further delaying the project.▼
▲A bigger problem for Sun is that they had no integrated desktop object programming solution. Although [[C++]]
By the time DOE, now known as NEO, was released in 1995, Sun had already moved onto [[Java programming language|Java]] as their next big thing. Java was now the GUI of choice for client-side applications, so NEO was re-positioned as a Java system with the introduction of '''Joe''', but it saw little use. OpenStep support was quietly dropped that year as Sun focussed entirely on Java.▼
▲By the time DOE, now known as NEO, was released in 1995, Sun had already moved onto [[Java programming language|Java]] as their next big thing. Java was now the GUI of choice for client-side applications,
In general, the market for distributed objects never really appeared. Although CORBA was the "next big thing" in the early 90's, by the second half of the decade it had essentially disappeared. Web-based applications running entirely on the server became the new "next big thing", and the need for a powerful display system on the client-side was simply dropped and replaced by lightweight GUI's based on [[HTML]].▼
▲
==References==
| |||