Распределенные объекты везде: история DOE и NEO

Введение

Distributed Objects Everywhere (DOE) был долгосрочным проектом Sun Microsystems по созданию распределенной вычислительной среды, использующей систему CORBA на серверной стороне и OpenStep в качестве пользовательского интерфейса. Проект был начат в 1990 году и вскоре объявлен, но оставался нереализованным в течение многих лет, пока наконец не был выпущен под названием NEO в 1995 году. Он продавался лишь короткое время, прежде чем был прекращен (вместе с OpenStep) в 1996 году. На смену ему пришли технологии, известные сегодня как Enterprise JavaBeans.

Предыстория

В начале 1990-х годов "следующей большой вещью" в вычислительной технике было использование настольных микрокомпьютеров для отображения и редактирования данных, предоставляемых мейнфреймами и миникомпьютерами. Хотя уже существовало несколько методов для подобного доступа, разделение труда было далеко не равномерным. Например, SQL требовал от рабочей станции загружать огромные наборы данных и затем обрабатывать их локально, в то время как использование терминальных эмуляторов оставляло всю работу на сервере и не предоставляло графического интерфейса. Казалось, что оптимальное разделение обязанностей заключалось бы в использовании кооперативного набора объектов, где рабочая станция отвечала бы за отображение и взаимодействие с пользователем, а обработка выполнялась бы на сервере. Препятствием на пути к такому решению были существенные различия в операционных системах и языках программирования между платформами. Хотя теоретически можно было создать систему, работающую на любой комбинации рабочей станции и сервера, то же самое решение не работало бы на другой системе. Удивительно, но различия между любыми двумя языками программирования на одной платформе были почти столь же велики. Каждый язык имел свой формат передачи параметров в процедурные вызовы, а форматы генерируемых ими файлов часто существенно отличались. В целом, не всегда было возможно писать различные части программы на разных языках, хотя это часто было полезно. Проблема была менее острой на миникомпьютерах и мейнфреймах, где поставщик часто определял стандарты для своих библиотек, но на микрокомпьютерах системы программирования обычно поставлялись различными сторонними компаниями, не заинтересованными в стандартизации. Тем не менее, эта проблема решалась в начале 1990-х годов благодаря внедрению различных систем общих библиотек. Изначально они предназначались для оптимизации использования ресурсов на небольших платформах, позволяя нескольким программам, использующим общий ресурс, например, графический интерфейс, совместно использовать одну копию кода вместо загрузки каждой программой собственной копии в память. Как побочный эффект возможности вызова из множества программ, эти системы также определяли стандартный способ вызова, используя язык описания интерфейсов (IDL), чтобы любой язык на платформе мог понимать код внутри библиотеки. Расширение этих систем для поддержки удаленных вызовов процедур "под капотом" рассматривалось как естественная эволюция, предоставляющая решение проблемы клиент-серверного программирования. В то время существовало несколько крупных проектов по созданию подобной системы, включая System Object Model (SOM/DSOM) от IBM, Portable Distributed Objects от NeXT, Component Object Model (COM/DCOM) от Microsoft и множество вариантов CORBA. Sun, стремясь позиционировать себя как будущего IBM в области поддержки серверной части, считала необходимым выйти и на этот рынок.

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.

Спринг, DOE, OpenStep, NEO

Решение Sun было основано на разработке в их операционной системе Spring, которая использовала взаимодействующие объекты для выполнения почти всех задач программирования. Адаптировать это для работы под «традиционным» Unix, таким как Solaris, оказалось не так сложно, хотя Unix исходит из предположения, что все программы выполняются локально, и потребовалось добавить интерфейс для удаленного доступа. Для этого DOE добавил брокер запросов объектов (ORB), который работал на серверных серверах, прослушивал запросы DOE и передавал их соответствующей программе для обработки. В процессе разработки CORBA стало ключевым словом в индустрии. Это привело к задержке, пока ORB был переработан для поддержки CORBA. В рамках модели CORBA различные объекты, такие как объекты DOE или SOM, могли бы взаимодействовать, используя общий интерфейс. Более серьезной проблемой для Sun стало отсутствие интегрированного решения для объектного программирования на рабочих станциях. Хотя объектные библиотеки C++ становились распространенными на некоторых платформах, их собственная операционная система SunOS (позже известная как Solaris) и связанные с ней системы SunView и X были основаны на «простом C», в то время как их новая оконная среда NeWS базировалась на сетевом расширяемом объектно-ориентированном диалекте PostScript. Чтобы предоставить комплексное и гибкое решение для объектного программирования, Sun обратилась к NeXT, и они совместно разработали OpenStep. Идея заключалась в том, чтобы программы OpenStep вызывали объекты DOE на серверах Sun, обеспечивая решение для серверной и клиентской части на машинах Sun. OpenStep был выпущен только в 1993 году, что еще больше задержало проект. К тому времени, когда DOE, теперь известный как NEO, был выпущен в 1995 году, Sun уже переключилась на Java как на следующую важную разработку. Java стал графическим интерфейсом пользователя по умолчанию для клиентских приложений, и планы Sun по OpenStep были тихо свернуты (см. Lighthouse Design). NEO был перепозиционирован как Java-система с внедрением фреймворка "Joe", но он не получил широкого распространения. Компоненты NEO и Joe в конечном итоге были включены в Enterprise JavaBeans. Хотя распределенные объекты, и особенно CORBA, были «следующей большой вещью» в начале 1990-х годов, ко второй половине десятилетия интерес к ним практически исчез. Веб-приложения, работающие полностью на сервере, стали новой «большой вещью», и потребность в мощной системе отображения на стороне клиента уменьшилась, в основном замененная легковесными графическими интерфейсами пользователя на основе HTML и JavaScript («пользовательские интерфейсы браузера»).

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++ object libraries were becoming common on some platforms, their own SunOS (later known as Solaris) operating system and associated SunView and X window systems were 'plain C' based, while their newer NeWS windowing environment was based on a network extensible object oriented dialect of PostScript. In order to supply a comprehensive and flexible object programming solution, Sun turned to NeXT and the two developed OpenStep. The idea was to have OpenStep programs calling DOE objects on Sun servers, providing a backoffice to frontoffice solution on Sun machines. OpenStep was not released until 1993, further delaying the project. By the time DOE, now known as NEO, was released in 1995, Sun had already moved on to Java as their next big thing. Java was now the GUI of choice for client side applications, and Sun's OpenStep plans were quietly dropped (see Lighthouse Design). NEO was re positioned as a Java system with the introduction of the "Joe" framework, but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans. Although distributed objects, and CORBA in particular, were the "next big thing" in the early 1990s, by the second half of the decade interest in them 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 faded, largely replaced by lightweight GUIs based on HTML and JavaScript ("Browser User Interfaces").