Distributed Objects Everywhere ( DOE ) был долгосрочным проектом Sun Microsystems по созданию распределенной вычислительной среды на основе системы CORBA в «бэк-энде» и OpenStep в качестве пользовательского интерфейса. Впервые запущенный в 1990 году и анонсированный вскоре после этого, он оставался пустым программным обеспечением в течение многих лет, прежде чем был окончательно выпущен как NEO в 1995 году. Он продавался только в течение короткого периода, прежде чем был снят с производства (вместе с OpenStep) в 1996 году. На его месте находится то, что сегодня известно как Enterprise JavaBeans .
В начале 1990-х годов «следующим большим событием» в вычислительной технике стало использование настольных микрокомпьютеров для отображения и редактирования данных, предоставляемых мэйнфреймами и миникомпьютерами . Хотя ряд методов такого доступа уже существовал, разделение труда было совсем неравномерным. Например, SQL требовал от рабочей станции загрузки огромных наборов данных и их локальной обработки, тогда как использование эмуляторов терминала оставляло всю работу на сервере и не предоставляло никакого графического интерфейса .
Казалось, что правильным разделением обязанностей будет иметь кооперативный набор объектов, при этом рабочая станция будет отвечать за отображение и взаимодействие с пользователем, а обработка будет на сервере. На пути такого решения стояли огромные различия в операционных системах и языках программирования между платформами. Хотя можно было бы построить такую систему, которая работала бы на любой комбинации рабочей станции и сервера, то же самое решение не будет работать на любой другой системе.
Как ни странно, различия между любыми двумя языками программирования на одной платформе были почти такими же большими. У каждого языка был свой собственный формат для передачи параметров в вызовы процедур , форматы файлов, которые они генерировали, часто были совершенно разными. В общих чертах, не всегда было возможно писать разные части программы на разных языках, хотя это часто имело реальную пользу. Проблема не была столь острой на мини-компьютерах и мэйнфреймах, где поставщик часто указывал стандарты для своих библиотек, но на микрокомпьютерах системы программирования обычно поставлялись различными сторонними компаниями, не заинтересованными в стандартизации.
Тем не менее, эта проблема решалась в начале 1990-х годов посредством внедрения различных систем общих библиотек . Они фактически были предназначены для облегчения использования ресурсов на меньших платформах, позволяя нескольким программам, использующим общий ресурс, такой как GUI, совместно использовать одну копию кода вместо того, чтобы загружать отдельную копию в память. В качестве побочного эффекта возможности вызова из многих программ эти системы также определили стандартный способ их вызова с использованием языка определения интерфейса , или IDL, чтобы позволить любому языку на платформе понимать код внутри библиотеки.
Расширение этих систем для поддержки удаленных вызовов процедур за кулисами рассматривалось как естественная эволюция, предоставляющая решение проблемы клиент-серверного программирования. В то время существовало несколько крупных проектов по поставке такой системы, включая System Object Model (SOM/DSOM) от IBM , Portable Distributed Objects от NeXT , Component Object Model (COM/DCOM) от Microsoft и множество разновидностей CORBA . Sun, пытаясь позиционировать себя как будущую IBM с точки зрения поддержки бэк-офиса, чувствовала, что должна атаковать и этот рынок.
Решение Sun было основано на работе в их операционной системе Spring , которая использовала взаимодействующие объекты почти для всех задач программирования. Модификация этого для работы в «традиционном» Unix, таком как Solaris, была не такой уж сложной, хотя Unix предполагает, что все программы выполняются локально, и необходимо было добавить интерфейс для удаленного доступа. Для этого DOE добавил брокера запросов объектов (ORB), который работал на серверах бэк-офиса, прослушивая запросы DOE и передавая их соответствующей программе для обработки. Во время разработки CORBA стал ключевым модным словом в отрасли. Это вызвало задержку, пока ORB был переработан для поддержки CORBA. В модели CORBA различные объекты, такие как объекты из DOE или SOM, могли взаимодействовать, разделяя общий интерфейс.
Более серьезной проблемой для Sun было то, что у них не было интегрированного решения для программирования объектов рабочего стола. Хотя библиотеки объектов C++ становились обычными на некоторых платформах, их собственная операционная система SunOS (позже известная как Solaris ) и связанные с ней системы SunView и X Window были основаны на «чистом C», в то время как их более новая среда окон NeWS была основана на расширяемом сетью объектно-ориентированном диалекте PostScript .
Для того чтобы предоставить комплексное и гибкое решение объектного программирования, Sun обратилась к NeXT, и они вдвоем разработали OpenStep . Идея состояла в том, чтобы программы OpenStep вызывали объекты DOE на серверах Sun, предоставляя решение backoffice-to-frontoffice на машинах Sun. OpenStep был выпущен только в 1993 году, что еще больше задержало проект.
К моменту выхода DOE, теперь известного как NEO, в 1995 году [1] Sun уже перешла на Java как на свой следующий большой шаг. Теперь Java была выбрана в качестве графического интерфейса для клиентских приложений, и планы Sun OpenStep были тихо свернуты (см. Lighthouse Design ). NEO была перепозиционирована как система Java с введением фреймворка "Joe" [2] , но она не нашла особого применения. Компоненты NEO и Joe в конечном итоге были включены в Enterprise JavaBeans . [3]
Хотя распределенные объекты, и CORBA в частности, были «следующим большим явлением» в начале 1990-х годов, ко второй половине десятилетия интерес к ним по сути исчез. [ editorializing ] Веб-приложения, работающие полностью на сервере, стали новым «следующим большим явлением», а потребность в мощной системе отображения на стороне клиента сошла на нет, и их в значительной степени заменили легкие графические интерфейсы на основе HTML и JavaScript (« Интерфейсы пользователя браузера »).