Таратылған Объектілер Әлемі: Sun Microsystems жобасының тарихы
Distributed Objects Everywhere
DOE (Distributed Objects Everywhere) – Sun Microsystems жобасы, CORBA және OpenStep негізінде құрылған, бірақ сәтсіз аяқталды. Enterprise JavaBeans-ке жол берді.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Distributed Objects Everywhere (DOE) – Sun Microsystems компаниясының CORBA жүйесіне негізделген, пайдаланушы интерфейсі ретінде OpenStep қолданылған, таратылған есептеу ортасын құруға бағытталған, ұзақ мерзімді жобасы. 1990 жылы басталып, жақын арада жарияланғанмен, 1995 жылы NEO ретінде шығарылғанға дейін көп жылдар бойы іске аспады. 1996 жылы (OpenStep-пен бірге) қолданудан алынып, қысқа ғана уақыт сатылды. Оның орнына қазіргі Enterprise JavaBeans пайда болды.
Distributed Objects Everywhere (DOE) was a long running Sun Microsystems project to build a distributed computing environment based on the CORBA system in the 'back end' and OpenStep as the user interface. First started in 1990 and announced soon thereafter, it remained vaporware for many years before it was finally released as NEO in 1995. It was sold for only a short period before being dropped (along with OpenStep) in 1996. In its place is what is today known as Enterprise JavaBeans.
Өмірбаян
1990 жылдардың басында есептеу техникасындағы «келесі үлкен жетістік» – үстел микрокомпьютерлерін мейнфреймдер мен миникомпьютерлер ұсынатын деректерді көрсету және өңдеу үшін пайдалану болды. Мұндай қолжетімділік үшін бірнеше әдіс болғанымен, еңбек бөлінісі мүлдем тең емес еді. Мысалы, SQL жұмыс станциясына үлкен деректер жиынтығын жүктеуді және оларды жергілікті түрде өңдеуді қажет етті, ал терминал эмуляторларын пайдалану барлық жұмысты серверге жүктеді және графикалық интерфейс (GUI) ұсынбады. Міндеттерді дұрыс бөлу үшін, серверде өңдеуді жүзеге асырып, жұмыс станциясы деректерді көрсету және пайдаланушымен өзара әрекеттесу үшін жауапты болатын, ынтымақтастықпен жұмыс істейтін объектілер жиынтығы болуы керек деп есептелді. Алайда, мұндай шешімді жүзеге асыруға платформалар арасындағы операциялық жүйелер мен бағдарламалау тілдерінің айқын айырмашылықтары кедергі келтірді. Жұмыс станциясы мен сервердің кез келген комбинациясы үшін мұндай жүйені құру мүмкін болғанымен, дәл сол шешім басқа жүйеде жұмыс істемейтін еді. Қызығы, бір платформадағы екі бағдарламалау тілінің өзара айырмашылығы да шамамен бірдей болды. Әрбір тіл процедураға шақыру үшін параметрлерді жіберудің өзіндік форматына ие болды, ал олар жасаған файл форматтары көбінесе мүлдем басқаша болды. Жалпы алғанда, бағдарламаның әртүрлі бөліктерін әртүрлі тілдерде жазу әрқашан мүмкін болмады, бірақ мұндай тәсіл көбінесе өте пайдалы болар еді. Бұл мәселе миникомпьютерлер мен мейнфреймдерде соншалықты күрделі емес еді, себебі жеткізушілер өз кітапханалары үшін стандарттарды белгілеп берді, бірақ микрокомпьютерлерде бағдарламалау жүйелерін әдетте стандарттауға мүдделі емес әртүрлі үшінші тарап компаниялары жеткізді. Дегенмен, 1990 жылдардың басында ортақ кітапхана жүйелерін енгізу арқылы бұл мәселені шешуге тырысылды. Бұл жүйелердің мақсаты кіші платформаларда ресурстарды тиімді пайдалануды қамтамасыз ету болды, себебі GUI сияқты ортақ ресурсты пайдаланатын бірнеше бағдарламалар әрқайсысы жеке көшірмені жадына жүктеудің орнына, кодтың бір көшірмесімен бөлісе алатын еді. Көптеген бағдарламалардан шақыруға болатындықтан, бұл жүйелер оларды шақырудың стандартты әдісін анықтады, интерфейсті анықтау тілін (IDL) пайдаланып, платформадағы кез келген тілге кітапхана ішіндегі кодты түсінуге мүмкіндік берді. Бұл жүйелерді қашықтан процедураларды шақыруды қолдау үшін кеңейту табиғи эволюция ретінде қарастырылды, бұл клиент/сервер бағдарламалау мәселесіне шешім ұсынды. Сол кезде мұндай жүйені жүзеге асыру үшін бірқатар ірі жобалар іске асырылды, олардың ішінде IBM-нің System Object Model (SOM/DSOM), NeXT-тің Portable Distributed Objects, Microsoft-тың Component Object Model (COM/DCOM) және көптеген 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 серверлерінде жұмыс істейтін және DOE сұраныстарын тыңдап, оларды өңдеуге тиіс бағдарламаға жіберетін объект сұранысы брокері (ORB) қосылды. Әзірлеу кезеңінде CORBA индустрияда кең таралған ұғымға айналды. Бұл ORB-ді CORBA қолдауын қамтамасыз ету үшін қайта жасауға түрткіс берді, нәтижесінде жұмыс уақытша тоқтап қалды. CORBA моделінде DOE немесе SOM сияқты әртүрлі объектілер ортақ интерфейсті бөлісе отырып, өзара әрекеттесе алатын болды. Sun үшін үлкен мәселе – олардың біріктірілген жұмыс үстелінде объектілік бағдарламалауға арналған шешімі болмады. C++ объектілік кітапханалары кейбір платформаларда кеңінен таралғанымен, олардың өзіндік SunOS (кейін Solaris деп аталған) операциялық жүйесі және SunView және X терезелік жүйелері «жай ғана C» тілінде жасалған, ал олардың жаңа NeWS терезелік ортасы PostScript желілік кеңейтілген объектіге бағытталған диалектісіне негізделген. Кешенді және икемді объектілік бағдарламалау шешімін ұсыну үшін Sun NeXT компаниясына жүгінді және екеуі OpenStep-ті жасады. Мақсаты – OpenStep бағдарламалары Sun серверлеріндегі DOE объектілерін шақырып, Sun машиналарында артқы кеңселерден алдыңғы кеңселерге дейін шешім ұсыну болды. OpenStep 1993 жылға дейін жарық көрмеді, бұл жобаны одан әрі кешіктірді. 1995 жылы DOE, енді NEO деп аталған, жарық көрген кезде Sun Java-ны келесі үлкен жетістік деп қарады. Java енді клиенттік қолданбалар үшін таңдалыныс GUI болды, ал Sun-нің OpenStep жоспарлары үнсіз қалды (Лighthouse Design-ға қараңыз). NEO «Joe» фреймворкі енгізілген кезде Java жүйесі ретінде қайта позицияланды, бірақ ол аз қолданылды. NEO және Joe компоненттері ақырында Enterprise JavaBeans құрамына енді. 1990 жылдардың басында таратылған объектілер, әсіресе CORBA «келесі үлкен жетістік» болғанымен, он жылдықтың екінші жартысында оларға қызығушылық мүлдем жоғалды. Серверде толығымен жұмыс істейтін веб-қосымшалары жаңа «келесі үлкен жетістікке» айналды, ал клиенттік жағындағы қуатты дисплей жүйесіне деген қажеттілік азайды, көбінесе HTML және JavaScript негізіндегі жеңіл GUI-лермен («Браузерлік пайдаланушы интерфейстері») алмастырылды.
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").