Rozproszone obiekty wszędzie

Distributed Objects Everywhere ( DOE ) był wieloletnim projektem firmy Sun Microsystems mającym na celu zbudowanie rozproszonego środowiska obliczeniowego opartego na systemie CORBA w „zapleczu” i OpenStep jako interfejsie użytkownika. Rozpoczęty w 1990 roku i wkrótce potem ogłoszony, pozostawał waporyzatorem przez wiele lat, zanim ostatecznie został wypuszczony jako NEO w 1995 roku. Był sprzedawany tylko przez krótki okres, zanim został usunięty (wraz z OpenStep) w 1996 roku. Na jego miejscu jest to, co jest dziś znany jako Enterprise JavaBeans .

Tło

Na początku lat 90. „kolejną wielką rzeczą” w informatyce było wykorzystanie mikrokomputerów stacjonarnych do wyświetlania i edytowania danych dostarczanych przez komputery typu mainframe i minikomputery . Chociaż istniało już wiele metod tego rodzaju dostępu, podział pracy wcale nie był równomierny. Na przykład SQL wymagał, aby stacja robocza pobierała ogromne zbiory danych, a następnie przetwarzała je lokalnie, podczas gdy użycie emulatorów terminali pozostawiało całą pracę serwerowi i nie zapewniało GUI .

Wydawało się, że właściwym podziałem obowiązków będzie posiadanie współpracującego zestawu obiektów, gdzie stacja robocza będzie odpowiedzialna za wyświetlanie i interakcję użytkownika, z przetwarzaniem na serwerze. Na drodze do tego rodzaju rozwiązania stały ogromne różnice w systemach operacyjnych i językach programowania między platformami. Chociaż możliwe byłoby zbudowanie takiego systemu, który działałby na dowolnej kombinacji stacji roboczej i serwera, to samo rozwiązanie nie działałoby na żadnym innym systemie.

Co dziwne, różnice między dowolnymi dwoma językami programowania na jednej platformie były prawie tak duże. Każdy język miał swój własny format przekazywania parametrów do wywołań procedur , a generowane przez nie formaty plików były często zupełnie inne. Ogólnie rzecz biorąc, nie zawsze było możliwe napisanie różnych części programu w różnych językach, chociaż robienie tego często ma rzeczywistą użyteczność. Problem nie był tak dotkliwy w przypadku minikomputerów i komputerów typu mainframe, gdzie sprzedawca często określał standardy dla swoich bibliotek, ale w przypadku mikrokomputerów systemy programistyczne były na ogół dostarczane przez różne firmy zewnętrzne, które nie były zainteresowane standaryzacją.

Niemniej jednak problem ten został rozwiązany na początku lat 90. poprzez wprowadzenie różnych systemów bibliotek współdzielonych . W rzeczywistości miały one na celu ułatwienie korzystania z zasobów na mniejszych platformach, umożliwiając wielu programom korzystającym ze wspólnego zasobu, takiego jak GUI, współdzielenie pojedynczej kopii kodu zamiast ładowania każdej oddzielnej kopii do pamięci. Jako efekt uboczny możliwości wywoływania z wielu programów, systemy te zdefiniowały również standardowy sposób ich wywoływania, używając języka definicji interfejsu lub IDL, aby umożliwić dowolnemu językowi na platformie zrozumienie kodu wewnątrz biblioteki.

Rozszerzenie tych systemów w celu obsługi zdalnych wywołań procedur za kulisami było postrzegane jako naturalna ewolucja, zapewniająca rozwiązanie problemu programowania klient/serwer. W tamtym czasie istniało wiele dużych projektów mających na celu dostarczenie takiego systemu, w tym IBM System Object Model (SOM/DSOM), Portable Distributed Objects NeXT , Component Object Model ( COM/DCOM) Microsoftu i wiele CORBA smaki. Sun, próbując pozycjonować się jako przyszły IBM w zakresie wsparcia backoffice, poczuł, że musi zaatakować również ten rynek.

Wiosna, DOE, OpenStep, NEO

Rozwiązanie firmy Sun opierało się na pracy w ich systemie operacyjnym Spring , który wykorzystywał komunikujące się obiekty do prawie wszystkich zadań programistycznych. Zmodyfikowanie tego, aby działało pod „tradycyjnym” Uniksem, takim jak Solaris, nie było wcale takie trudne, chociaż Unix zakłada, że ​​wszystkie programy działają lokalnie i trzeba było dodać interfejs do zdalnego dostępu. W tym celu firma DOE dodała brokera żądań obiektów (ORB), który działał na serwerach zaplecza, nasłuchując żądań DOE i przekazując je odpowiedniemu programowi do obsługi. Podczas opracowywania CORBA stała się kluczowym hasłem w branży. Spowodowało to opóźnienie, podczas gdy ORB został ponownie zaprojektowany do obsługi CORBA. W modelu CORBA różne obiekty, takie jak te z DOE lub SOM, mogłyby wchodzić w interakcje, dzieląc wspólny interfejs.

Większym problemem firmy Sun jest brak zintegrowanego rozwiązania do programowania obiektowego dla komputerów stacjonarnych. Chociaż C++ stawały się powszechne na niektórych platformach, ich własny system operacyjny SunOS (później znany jako Solaris ) i powiązane systemy okien SunView i X były oparte na „zwykłym C”, podczas gdy ich nowsze środowisko okienkowe NeWS było oparte na obiekcie rozszerzalnym przez sieć zorientowany dialekt języka PostScript .

W celu dostarczenia kompleksowego i elastycznego rozwiązania do programowania obiektowego firma Sun zwróciła się do NeXT i dwóch opracowanych OpenStep . Pomysł polegał na tym, aby programy OpenStep wywoływały obiekty DOE na serwerach Sun, zapewniając rozwiązanie backoffice-to-frontoffice na maszynach Sun. OpenStep został wydany dopiero w 1993 roku, co dodatkowo opóźniło projekt.

Do czasu wydania DOE, obecnie znanego jako NEO, w 1995 roku, Sun już przeszedł na Javę jako kolejną wielką rzecz. Java była teraz preferowanym graficznym interfejsem użytkownika dla aplikacji po stronie klienta, a plany OpenStep firmy Sun zostały po cichu odrzucone (patrz Lighthouse Design ). NEO został ponownie ustawiony jako system Java wraz z wprowadzeniem frameworka „Joe”, ale nie był używany. Komponenty NEO i Joe zostały ostatecznie włączone do Enterprise JavaBeans .

Chociaż obiekty rozproszone, aw szczególności CORBA, były „kolejną wielką rzeczą” na początku lat 90., w drugiej połowie dekady zainteresowanie nimi zasadniczo zniknęło. Aplikacje internetowe działające w całości na serwerze stały się nową „kolejną wielką rzeczą”, a potrzeba wydajnego systemu wyświetlania po stronie klienta zniknęła, w dużej mierze zastąpiona przez lekkie GUI oparte na HTML i JavaScript ( „ Interfejsy użytkownika przeglądarki ").

Linki zewnętrzne

• Shah, Rawn (1 czerwca 1996). „Rozproszone przetwarzanie obiektowe z Joe i NEO” . JavaŚwiat . Źródło 2020-07-15 .