Влияние исследований на технологию промежуточного программного обеспечения

Вольфганг Эммерих, Микио Аояма, Джо Свентек
Перевод: Сергей Кузнецов

Назад Содержание Вперёд

7. Распределенные объекты

В этом разделе мы рассмотрим методы, которые поддерживают вызовы операций между объектами, разделенными границами машин. Таким образом, в сферу интересов этого раздела входят объектные запросы, поддерживаемые архитектурой CORBA, примитивами RMI в среде Java и архитектурой Remoting в среде .NET. Для создания современных распределенных приложений разработчики программного обеспечения используют примитивы удаленного вызова, которые теперь тесно интегрированы с языками программирования. Мы уже обсуждали объем рынка серверов приложений, основанных на J2EE. В спецификации EJB [42], которой должен соответствовать любой сервер приложений, основанный на J2EE, предписывается использование RMI в среде Java [141]. В этой спецификации говорится, что «удаленный и удаленный собственный (remote home) интерфейсы являются интерфейсами Java RMI». Таким образом, EJB могут быть доступны за пределами границ машин. В .NET для этой цели используется примитив Remoting [137]. Тем самым, Java RMI и .NET Remoting обеспечивают основу для вызова операций между различными распределенными звеньями архитектуры программного обеспечения, без чего было бы невозможно создавать масштабируемые и надежные Web-приложения.

В [4] и [95] описываются эффективные методы построения распределенных систем на основе использования J2EE и .NET соответственно. Эти методы, происходящие от компаний Sun и Microsoft соответственно, широко используются в индустрии программного обеспечения, и значительное число Web-сайтов в областях электронной коммерции, онлайн-банкинга и т.д. разрабатывается с использованием этих методов. В [4] предлагается строгое разделение уровня представления и уровня бизнес-объектов. Уровень бизнес-объектов отвечает за поддержку логики приложения и поддержку интерфейсов с базовыми информационными системами и унаследованными приложениями. Одним из методов является размещение этих уровней на разных машинах для поддержки балансировки нагрузки и отказоустойчивости. В результате объектам уровня представления требуется вызывать операции объектов уровня бизнес-объектов сквозь границы машин. На практике это достигается путем использования Java RMI или .NET Remoting.

Поэтому мы утверждаем, что примитивы удаленного вызова обладают большой важностью для построения распределенных программных приложений, и теперь мы можем начать исследовать происхождение этих примитивов удаленного вызова.

7.1. Java Remote Method Invocation

Спецификация RMI в компании Sun Microsystems создавалась под руководством Джима Вальдо, и технические понятия RMI были впервые опубликованы в [151]. RMI позволяет Java-объекту-клиенту вызывать методы объекта-сервера, располагающегося в другой JVM (Java Virtual Machine), возможно, в другом хосте.

Рис. 13. Трассы воздействия для Java RMI

На рис. 13 показаны трассы воздействий, которые привели к RMI. В [146] обсуждаются основные проектные принципы и происхождение RMI. Вальдо признает, что RMI основывается на наследии систем удаленного вызова процедур и идентифицирует [21], как первую систему RPC. Он также указывает в качестве предшественников RMI архитектуру OMG CORBA [103] и Distributed Component Object Model (DCOM) компании Microsoft [61]. Затем Вальдо излагает проектные принципы RMI и описывает важные отличия RMI от предшествующих работ в областях RPC, CORBA и DCOM. В частности, в RMI произошел отказ от неоднородности языков программирования, разрешавшейся за счет поддержки независимого языка определения интерфейсов и его привязок к различным языкам программирования, на которой базировались все предшествующие работы по системам удаленных вызовов процедур. В [151] утверждается, что вместо этого в RMI продолжаются традиции Network Objects в среде Modula-3, где примитивы удаленного вызова встраивались в язык программирования. В [151] также говорится, что RMI основывается на механизме сборки мусора, впервые внедренном в Modula-3 Network Objects.

RMI также отличается от предыдущих работ в области систем удаленного вызова процедур тем, что стабы, требуемые для синхронизации и поддержки прямого и обратного маршалинга, загружаются при необходимости, а не при запуске распределенной программы. Этот механизм существенно упрощает развертывание распределенных программ. Для обеспечения возможности загрузки стабов в RMI используется механизм динамической загрузки классов Java, описанный в [85]. Для использования в распределенной среде необходимо обеспечить безопасность загрузки классов, и в [85] описывается, как можно добиться надежной и безопасной загрузки классов, следуя формально обоснованным методам обеспечения безопасности предыдущих механизмов загрузки классов Java [74].

Статья [20] про Network Objects начинается с утверждения, что «в чистом объектно-ориентированном программировании у клиентов не должен иметься прямой доступ к реальному состоянию объектов, он должен обеспечиваться только через методы объектов. Эта методология замечательно применяется к распределенному компьютингу, поскольку вызовы методов представляют собой удобное место для внедрения коммуникаций, требуемых распределенной системой». Таким образом в Network Objects продолжаются традиции Вирта (Niklaus Wirth) и Парнаса (David Parnas) инкапсуляции, модульности и сокрытия информации, и эта система основывается на многочисленных работах, посвященных объектно-ориентированным языкам. Более глубокое обсуждение происхождения этой работы см. в [122]. В [20] явно утверждается, что система Modula-3 Network Objects основана на идеях предыдущих исследований, и приводятся ссылки на системы Emerald [76], Argus [87], Eden [2], Arjuna [47], Orca [11] и SOS [124]. Многие их этих источников являются журнальными публикациями технических отчетов или диссертациями, в которых системы описываются более подробно. Объектная модель Emerald определяется в [71], соответствующая система типов описывается в [23]. Подход персистентных объектов в Arjuna создан при выполнении диссертационной работы Диксона [46]. Объектная модель Orca была определена в [10].

В [20] Биррелл и др. отмечают три свои результата. Первый состоит в том, что подход Network Objects существенно проще и легче других подходов; им удалось достичь этого путем отбора из предыдущих систем только тех понятий, которые полагаются необходимыми для распределенного программирования. Вторым результатом является интеграция в согласованную языковую инфраструктуру. И третьим основным результатом они считают реализацию этого языка, которую они затем подвергли качественной и количественной оценке, чтобы показать целесообразность сравнительно мелкоструктурной распределенной обработки. Таким образом, исследования Modula-3 Network Objects в лаборатории компании DEC можно считать необходимым и, с учетом оказанного воздействия на RMI, существенным шагом на пути консолидации предыдущих исследовательских работ.

Несомненно, на Network Objects повлияли и предыдущие работы Эндрю Биррелла в области удаленных вызовов процедур [21], но прежде, чем обсудить это, мы бы хотели проследить воздействие другого непосредственного предшественника RMI, которым, как это признается в [146], является CORBA. На самом деле, Джим Вальдо, когда он работал в HP/Apollo, являлся членом группы, создавшей первую спецификацию CORBA. В RMI более или менее непосредственно повторно используется ряд ключевых понятий CORBA, включая использование механизма исключительных ситуаций для обработки сбоев коммуникаций, прозрачности местоположения объектов за счет использования ссылок на удаленные объекты, наследование интерфейсов с использованием правильно определенного корневого объектного типа, использование стабов для прямого и обратного маршалинга, принимаемое по умолчанию поведение синхронизации, возможность выполнения активизации по требованию и использование в качестве транспортного механизма Internet Inter ORB Protocol (IIOP)

7.2. Common Object Request Broker Architecture

В период 1991-2003 гг. стандарт CORBA подвергся значительному числу переработок. Однако, за исключением протокола IIOP, который появился только в спецификации CORBA 2.0 [106], все упомянутые выше понятия, которые нашли свое отражение в RMI, возникли уже в первой версии CORBA, и поэтому нам надлежит исследовать происхождение именно этой спецификации.

Рис. 14. Трассы воздействий, приведших к OMG/CORBA

Трассы воздействий для CORBA показаны на рис. 14. Архитектура CORBA была специфицирована OMG в рамках открытого процесса. Первая спецификация CORBA является результатом деятельности двух рабочих групп, первая из которых определила объектную модель, а вторая – архитектуру брокера объектных запросов (Object Request Broker, ORB Architecture).

Можно установить две основные области воздействий на первую спецификацию CORBA со стороны различных исследовательских дисциплин. Исследования в областях инженерии программного обеспечения и языков программирования воздействовали на объектную модель CORBA, а исследования в области распределенных систем – на архитектуру ORB. Ниже мы обсудим обе эти области.

Очевидно, что группа, определявшая объектную модель, была осведомлена о предыдущих исследованиях и разработках в областях объектно-ориентированных языков программирования, объектно-ориентированного проектирования и объектных баз данных. На собраниях технического комитета OMG в то время происходили регулярные выступления ведущих исследователей на темы, имевшие отношение к CORBA. На собрании технического комитета в феврале 1990 г. по поводу С++ выступал Брайан Строуструп (Bjarne Stroustrop), который говорил о необходимости сосуществования и интеграции С++ с другими языками (в частности, он упоминал Smalltalk). В апреле 1990 г. выступал Клаус Дитрих (Klaus Dittrich) с рассказом об объектных моделях баз данных, в июне 1990 г. Айвар Якобсон (Ivar Jacobson) говорил про Objectory, и в октябре 1990 г. Эндрю Ватсон (Andrew Watson) рассказывал про ANSAware. Кроме того, в документе [135], определяющем объектную модель, содержится большое число ссылок на статьи, включая манифест объектных баз данных [8], на книги по объектно-ориентированному программированию, такие как [94], [77] и [40], и книги по объектно-ориентированному проектированию, включая [24] и [150].

Объектная модель была определена совместными усилиями членов одной из первых рабочих групп OMG в ходе работы по написанию «руководства по стандарту» Это руководство было отредактировано Ричардом Соли (Richard Soley), его первая версия была принята в сентябре 1990 г. и, в конце концов, оно было опубликовано в виде книги издательством John Wiley [135]. Базовая объектная модель (core object model) и глоссарий были привнесены Эланом Снайдером (Alan Snyder) [133, 132], который работал в то время в Hewlett Packard Labs. На оба эти материала, очевидно, воздействовали предыдущие исследования Снайдера. Понятие инкапсуляции и подход к поддержке множественного наследования в базовой объектной модели очень напоминают понятия, описанные в [131]. Объектная модель навязывает абстракцию данных в том смысле, что в базовой объектной модели не допускается какой-либо прямой доступ к данным; атрибуты трактуются, как пары операций доступа (одна для чтения, другая для записи), что очень близко к традициям абстракции данных в CLU [89]. Обработка исключительных ситуаций, которая добавляется к базовой модели данных в профиле объектной модели CORBA, явно внесена под воздействием более ранней работы Снайдера по управлению исключительными ситуациями в CLU [88].

После принятия объектной модели был объявлен прием предложений [147] по спецификации архитектуры брокера объектных запросов. В ответ на этот запрос консорциум OMG получил в январе 1991 г. одиннадцать конкурирующих предложений от компаний APM (Architecture Projects Management Ltd.) [68], Constellation [125], DESET [126], Hewlett Packard [91], Bull [12], HyperDesk [5], Digital Equipment Corporation [54], Teknekron [129], NCR [66], Software AG [50] и Sun Microsystems. В феврале 1991 г. Software AG, Teknekron и Constellation сняли свои предложения. Компания Sun аннулировала свое предложение и присоединилась к предложению HP [134]. Предложение ANSA (Advanced Network Systems Architecture) редактировалось Джоном Булем (John Bull), Эндрю Хербертом (Andrew Herbert) и Эндрю Ватсоном при поддержке других членов группы ANSA. Справочное руководство по ANSA [7] было создано в промежутке между 1984 и 1989 гг. группой, руководимой Эндрю Хербертом и включавшей Джо Свентека, Дейва Отвэя (Dave Otway), Овена Риса (Owen Rees) и других. В 1990 г. Свентек перешел на работу в HP, где стал соавтором предложения ORB от этой компании. Влияние ANSA на работу OMG продолжалось до середины 1990-х, в частности, потому что Эндрю Ватсон из ANSA возглавлял OMG ORB Task Force. Повторное предложение HP/Sun было написано и представлено в технический комитет OMG в марте 1991 г. Джо Свентеком, который руководил реализацией ANSA до перехода в HP, Джимом Вадьдо из Hewlett Packard, а также Ричардом Пробстом (Richard Probst) и Дуайтом Хэ (Dwight Hare) из Sun. На собрании технического комитета OMG в мае 1991 г. компания APM сняла свое предложение, заявив, что «APM не может справиться с трудностями, которые нужно преодолеть для достижения успеха своего предложения, что APM – это исследовательский консорциумом, предпочитающий работать над «будущими» ORB, и что процесс стандартизации ORB хорошо поддерживается Hewlett Packard и Digital Equipment Corporation.» После независимой экспертизы всех оставшихся предложений, выполненной INRIA [123], на том же майском собрании было решено отвергнуть все предложения и пригласить всех оставшихся подателей предложений подготовить совместное предложение. Это совместное предложение редактировалось Джо Свентеком и Биллом Андреасом (Bill Andreas) и было подано в августе 1991 г. от имени HP, DEC, HyperDesk, NCR и Sun [142]. Свентек и Андреас представили предложение на собрании технического комитета OMG в сентябре 1991 г., и впоследствии оно было принято в качестве стандарта. Андрю Ватсон возглавлял ORB Task Force с 1992 г. во время своей работы в APM. В 1995 г. он стал директором OMG по архитектуре, а позже – техническим директором.

Таким образом, мы представили доказательство того, что исследования ANSAware, проводившиеся в APM, в которых Херберт, Ватсон и Свентек играли основные роли, и которые частично финансировались европейской программой ESPRIT, оказали очень существенное воздействие на архитектуру CORBA. В следующем разделе мы покажем взаимосвязь между ANSAWare и системами RPC.

Назад Содержание Вперёд