ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД И СЕТЕВОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

Реклама
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ
ОБЕСПЕЧЕНИЕ
ПОДХОД
И
СЕТЕВОЕ
ПРОГРАММНОЕ
А.И.Илюшин, Н.Б.Дерябин, Журнал «ПРОГРАММИРОВАНИЕ» №6,1990
1.ВВЕДЕНИЕ
Использование объектно-ориентированнного подхода, как нам кажется, дает
существенные результаты практически во всех областях программирования. Не является
исключением и сетевое программное обеспечение. В ИПМ АН СССР накоплен довольно
большой опыт создания и использования сетей ЭВМ с объектно-ориентированной
архитектурой. В период с 1976 г. по 1981 г. были сделаны пробные реализации и построена
объектно -ориентированная сетевая архитектура, которая и используется по настоящее
время[1,2]. В 1983 г. была введена в эксплуатацию сеть СЕКОП из ЭВМ БЭСМ-6,
реализованная в соответствии с этой архитектурой. В 1988 г. была готова первая
реализация сети с объектно-ориентированной архитектурой для IBM PC, ДВК и ЕС ЭВМ.
Эта сеть получила название РУСЛАН и в настоящее время продолжает развиваться. Исходя
из нашего опыта, по-видимому, можно сделать два основных вывода:
- производительность программиста при создании распределенных программных
систем в сети с объектно-ориентированной архитектурой принципиально выше по
сравнению с работой в сети с традиционной архитектурой. Здесь под традиционной сетевой
архитектурой понимается представление распределенной программной системы в виде
совокупности распределенных по различным ЭВМ процессов. Причем эти процессы
взаимодействуют друг с другом, обмениваясь сообщениями с помощью примитивов
"послать - принять". Создавая распределенную систему, программист вынужден строить
частные протоколы связи между своими процессами, что является нетривиальной задачей
по крайней мере для программиста, привыкшего к традиционному локальному
программированию. В сети с объектно-ориентированной архитектурой распределенная
программная система строится в виде совокупности объектов-исполнителей операций,
распределенных по различным ЭВМ. Эти объекты взаимодействуют путем вызова операций друг в друге. В этом случае локальный и удаленный вызовы операций синтаксически
неразличимы в тексте программы. Сеть, как средство, связи превращается просто в один
частный случай механизма связи между вызывающей и вызываемой программами. Как
следствие сложность локального и распределенного программирования при прочих равных
условиях становится практически одинаковой;
- производительность во время счета и требования к ресурсам в сети с объектноориентированной архитектурой как минимум не хуже по сравнению с сетью, основанной на
"послать-принять".
Принципы построения сети с объектно-ориентированной архитектурой, разработанной
в ИПМ АН СССР, интерфейсы для пользователей, сетевой протокол удаленного вызова
операций описаны достаточно подробно в ранее опубликованных работах [1,2,3,4,5]. В
данной статье нам хотелось бы остановиться в основном на другой стороне проблемы обратном влиянии сетевой архитектуры на объектно-ориентированные средства. Дело в
том, что распространение некоторого метода за пределы области, в которой он
первоначально возник, часто приводит к полезному обобщению этого метода, очищению
его от частных решений, которые естественным, однако логически не обязательным,
образом были привнесены в него из исходной области применения. Как нам кажется, в
объектно-ориентированном подходе именно так обстоит дело с динамическим связыванием, ссылками на объекты, а также со способом создания, хранения и адресации объектов.
В сетевой обстановке перечисленные проблемы по необходимости должны решаться
способом, отличным от тех, которые используются в известных нам локальных реализациях
(см., например, [6]).
До рассмотрения именно различий локального и распределенного случаев нам
необходимо хотя бы кратко описать распределенный случай объектно-ориентированного
подхода. Некоторое количество локальных реализаций объектно-ориентированного
подхода считается известными.
2.ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ СЕТЕВАЯ АРХИТЕКТУРА
Начнем с перечисления проблем, которые должны быть решены в рамках любой
архитектуры для распределенной обработки:
- адресация в пределах сети компонент распределенной
системы (программ и данных);
- связывание удаленных компонент в единую систему. В локальном случае в качестве
аналога такого механизма можно, например, указать загрузку подпрограммы из библиотеки
по имени в вызывающей программе;
- преобразование представления данных для разных ЭВМ,
ОС и языков;
- нейтрализация сбоев и отказов. С одной стороны, сбои и отказы гораздо более
вероятны в распределенном случае по сравнению с локальным, а с другой стороны,
благодаря доступности многих ЭВМ, возможно продолжение счета даже в случае отказа
отдельных узлов сети;
- параллелизм выполнения, который является реальным в отличие от имитируемого в
случае одной ЭВМ.
Рассмотрим объектно-ориентированную сетевую архитектуру, использованную при
разработке сети РУСЛАН. Прикладной уровень строится в виде множества объектовисполнителей операций, которые взаимодействуют путем вызова операций друг в друге.
Удаленный вызов операций поддерживается с помощью единственного протокола УДВ.
Этот протокол в данной архитектуре заменяет собой протоколы общего назначения на
прикладном уровне модели ISO/OSI [7], а также протоколы 6, 5 и 4 уровней этой модели.
Протоколы нижележащих уровней можно считать неспецифичными для моделей.
Потенциально бесконечное множество прикладных протоколов для частных применений
модели ISO/OSI заменяются просто конкретными прикладными подсистемами (объектамиисполнителями), взаимодействие которых, вообще говоря, не несет никакой сетевой
специфики. Для программирования распределенных сетевых систем естественно использовать широко распространенные языки, например такие, как Си и Фортран, расширив
их соответствующими средствами. При объектно-ориентированном расширении языков для
распределенной обработки были использованы следующие понятия:
- переменная типа объект-исполнитель операций. Под типом здесь понимается
набор имен операций, которые может выполнять объект, указываемый данной переменной.
Значением такой переменной является ссылка на объект-исполнитель, который расположен
возможно в удаленной ЭВМ. В данном изложении нам удобно называть переменными
также и формальные параметры процедур (подпрограмм);
- кластер, являющийся реализацией типа объекта-исполнителя. Кластер
представляет собой набор подпрограмм, реализующий операции данного типа. Для этого
набора подпрограмм в заголовке кластера определяются общие переменные, называемые
представлением объекта;
- экземпляр объекта-исполнителя или просто объект-исполнитель. Создается из
кластера и индивидуального набора значений переменных представления;
- файл объектов - это специальный объект, умеющий выполнять операцию "создать
объект" с указанным кластером, а также операции "уничтожить", "найти". Значением
переменной, заданной в качестве параметра-результата операции создания исполнителя,
становится ссылка на созданный объект. Естественно, что с одним кластером может быть
создано много объектов. Существенно, что одной переменной могут быть в разные
моменты присвоены ссылки на исполнители с разными кластерами, но, естественно, с
соответствующими наборами операций (в объектно-ориентированных языках такое
свойство называется полиморфизмом). Единственное условие - набор имен операций,
определяющий тип переменной, должен быть подмножеством набора имен операций,
реализуемых кластером созданного объекта. Файлы объектов могут располагаться как в
оперативной памяти, так и на дисках. Введение файлов объектов - это принципиальный
шаг, позволяющий в единой системе программирования естественным образом объединить
как традиционные языковые средства, так и некоторые возможности баз данных;
- вызов операции в объекте-исполнителе. Вызываемый объект задается переменной
типа исполнитель. В качестве параметров вызова могут передаваться как переменные
традиционных типов, так и переменные типа "объект-исполнитель операций"
(динамическое связывание в терминологии объектно-ориентированных языков).
В целом предлагаемая схема функционирования прикладного уровня такова:
- имеется множество объектов-исполнителей операций, которые хранятся в файлах
объектов. Файлы объектов возможно рассредоточены по различным ЭВМ сети;
- имеется множество процессов, выполняющих подпрограммы в кластерах объектов.
В момент вызова операции в другом объекте, возможно удаленном, процесс "перетекает" в
этот другой объект;
- сама совокупность взаимодействующих объектов определяется ссылками, которые
хранятся в этих объектах в переменных типа "объект-исполнитель". Получаются эти
ссылки как аргументы или результаты вызовов операций.
В данной модели объекты и процессы находятся в соотношении "много - много". А
именно, один процесс может проходить через много объектов, расположенных в разных
ЭВМ. Конкретно это означает наличие распределенного по этим ЭВМ стека для вложенных
вызовов подпрограмм из кластеров объектов. С другой стороны, несколько процессов
могут одновременно войти в один объект. При необходимости они могут синхронизоваться
на общих переменных представления этого объекта. Для этого достаточен любой известный
в локальном случае набор средств.
Отметим, что в модели ISO/OSI принято соотношение "один
- один". А именно, процесс фактически отождествляется с подсистемой (объектом).
Перечислим, как решаются приведенные выше сетевые проблемы, когда
распределенная система представляет собой множество исполнителей, взаимодействующих
путем вызова операций:
- адресация. Значением переменной типа исполнитель является ссылка, указывающая
на объект-исполнитель, расположенный в любой ЭВМ сети. В ссылке хранится уникальный
в пределах всей сети идентификатор объекта (УИД), перечень указателей на операции,
которые может выполнять данный объект, и указатель на сетевую процедуру связи. УИД
может быть дополнен различного рода физическими адресами, оптимизирующими доступ.
Тогда вызов удаленной операции через рассматриваемую ссылку и процедуру связи
попадает в сетевое обеспечение, которое транспортирует его до вызываемого объектаисполнителя и возвращает назад результаты выполнения операции;
- связывание объектов-исполнителей в единую систему осуществляется путем
передачи ссылок на них как параметров операций. В частности, ссылки могут запоминаться
в объектах каталогах и получаться как результаты операций поиска по имени в этих
каталогах. Для переменной типа исполнитель всегда хранится перечень имен операций,
определяющий, так сказать, формальный тип данной переменной. При занесении в
переменную ссылки происходит связывание этой переменной с в общем случае удаленным
конкретным объектом-исполнителем. Связывание переменной типа объект-исполнитель
при присваивании ей значения с конкретным объектом и следовательно с набором
подпрограмм, реализующих операции, перечисленные в типе, можно рассматривать как
естественное распространение на объектно-ориентированный и распределенный случаи
механизма "знакомств", хорошо известного по системам типа MULTICS;
- преобразование представления. В механизм расширения языка программирования
объектно-ориентированными средствами входит генерирование по описаниям переменных
дескрипторов, описывающих их тип (целый, вещественный, массив, запись, исполнитель и
т.д.). Тогда сетевое обеспечение, имея в момент траспортировки вызова тип данных, тип
языка и тип ЭВМ, легко преобразует представление;
- нейтрализация сбоев. Хранение объектов в файлах объектов (стабильная память),
уникальные идентификаторы объектов позволяют естественным образом использовать
известную в базах данных технику неделимых цепочек операций, контрольных точек и
рестартов. Оказалось очень полезной в распределенном случае обработка исключительных
ситуаций, аналогичная локальной обработке. Исключительная ситуация распространяется
по цепочке вложенных вызовов "вверх" до обработчика через все ЭВМ, по которым прошел
процесс выполнения этих вложенных вызовов;
- параллелизм. В приводимой схеме среда связи между ЭВМ оказывается прозрачной
для вызовов операций. Сетевое обеспечение с логической точки зрения является лишь
некоторой частной реализацией общего механизма вызова операций. Все содержательные
действия выполняются внутри исполнителей. Поэтому проблемы создания процессов и их
синхронизации сводятся к локальному случаю и могут быть решены с помощью хорошо известных локальных средств, например, семафоров, мониторов и т.д.
Сделаем выводы из выше сказанного:
- в локальном случае хорошо известные средства создания программных систем как
совокупности подпрограмм, вызывающих друг друга, достаточны и удобны. Введение
объектов-исполнителей является естественным обобщением (добавляется новый тип исполнитель для переменных и параметров операций) этих хорошо известных средств.
Хорошо известные средства управления процессами в локальном случае также достаточны;
- распределенный случай сводится к локальному с помощью удаленного вызова
операций. Сеть становится одним из частных механизмов связи между подпрограммами.
Для программиста, с точки зрения техники программирования, исчезает разница между
локальным и распределенным случаями. Он может пользоваться в обоих случаях едиными
средствами, исторически доказавшими свою достаточность и удобство.
3. ВЛИЯНИЕ СЕТЕВОЙ ОБСТАНОВКИ НА ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ
ПОДХОД
Рассмотрим основные особенности сетевого случая по сравнению с локальным, а
также влияние этих особенностей на объектно-ориентированную архитектуру. Как нам
кажется, одно из существенных отличий распределенных систем от локальных в настоящее
время в том, что при раскрутке распределенных систем часто главная программа
запускается позже ряда подсистем, с которыми эта главная программа должна динамически
связаться и использовать их. Конечно, и в локальном случае можно найти примеры такой
ситуации. Например, операционная система запускается до любой прикладной системы,
которая использует ее операции. Однако, операционная система является
предопределенным объектом с предопределенным набором операций, и увязка с ними
выполняется чаще всего статически. Напротив, в распределенном случае естественно, что в
машинах-серверах заранее запускаются разнообразные подсистемы, к которым
впоследствии динамически подключаются программы-заказчики. Причем на разных ЭВМ,
возможно, имеются функциональные дубли подсистем, поставляемых различными
поставщиками, и программа-заказчик может динамически выбрать ту или иную реализацию
нужной ей функции. Реализация указанной возможности требует от языка
программирования и его поддержки времени счета ряда средств, которые, как нам кажется,
отсутствуют в известных нам объектно-ориентированных локальных реализациях.
Рассмотрим требуемые средства в порядке, соответствующем естественной
последовательности работы в сети ЭВМ. Требуется:
- возможность создать подсистему-исполнитель в виде объекта, который может
существовать нужный период времени и который может быть найден и использован
независимыми программами-заказчиками. Отсюда, естественным образом, по аналогии с
файловыми системами и базами данных возникает понятие файла объектов, уникальный
идентификатор объекта, ссылка на объект, в которой хранится этот идентификатор,
уникальный в пределах сети, каталоги, в которых ссылки на объекты регистрируются под
различными именами. В известных нам локальных реализациях объекты создаются
традиционными способами: в статической памяти программы, в "автоматической" памяти
(стек) и в heap памяти. Стабильная файловая память для объектов отсутствует;
- возможность динамически связать программу-заказчик с найденным объектомисполнителем. Отсюда вытекает потребность иметь в качестве значения переменной типа
исполнитель достаточно сложную ссылку на объект. В этой ссылке должен храниться набор
имен операций, необходимых программе-заказчику, а после связывания с конкретным
объектом УИД этого объекта, указатели на процедуры, реализующие операции, и т.д. Здесь
важно подчеркнуть, что тип переменной-исполнителя при написании программы-заказчика
услуг определяется в виде набора требуемых ей операций возможно путем рассмотрения
уже имеющихся подсистем и их наборов операций. При этом выбирается некоторое
удобное для данной программы подмножество операций. Именно поэтому в
использованной нами архитектуре под типом объекта-исполнителя понимается просто
набор имен операций. Это позволяет динамически связать программу-заказчик с любой
подсистемой, которая в частности реализует и подмножество операций с этими именами. В
таких сравнительно старых языках как Ада и Модула-2 динамическое связывание просто
отсутствует. В новых объектно-ориентированных системах на основе языка С++ и в
TURBO PASCAL 5.5 фирмы BORLAND динамическое связывание, следуя языку
СИМУЛА-67, ограничено соотношением базовый тип в программе-заказчике и
производный тип в подсистеме-исполнителе. При этом базовый тип должен быть явно
указан в описании производного типа и тем самым должен быть определен до него. Выше
было показано, что тип в программе-заказчике часто определяется позже реализации используемого объекта. Главное в данной ситуации то, что механизм динамического
связывания программы-заказчика с объектом -исполнителем, как нам кажется, никакого
отношения к содержательному понятию "наследования" и "родительского" типа не имеет.
Подведем некоторые итоги. Введение понятия файла объектов, трактовка типа
переменной-исполнителя, особенности реализации ссылок на объекты явились следствием
сетевой специфики и отсутствия соответствующих средств в известных нам локальных
реализациях объектно-ориентированных систем. Как нам кажется, указанные средства не
являются специфичными именно для распределенного случая и являются естественным
обобщением, уместным и для локального случая. В качестве примера возможного
применения этих средств в локальном случае укажем на использование стабильной
файловой памяти объектов для организации контрольных точек и рестартов, а также для
хранения общедоступных подсистем в крупных ЭВМ.
4. ПРИМЕР РАСПРЕДЕЛЕННОГО ПРОГРАММИРОВАНИЯ
Приведем пример, который написан на языке СИР2, являющимся объектноориентированным расширением языка СИ. Рассматриваются две программы, возможно
расположенные на разных ЭВМ. Программа-исполнитель на той ЭВМ, на которой она
выполняется, создает объект-исполнитель с кластером ANYCLUST и затем регистрирует
этот объект под именем ANYOBJ в некотором сетевом каталоге, известным в сети под
именем PUBLICDIR. Этот каталог возможно расположен на другой ЭВМ. Программазаказчик, выполняющаяся возможно на третьей ЭВМ, находит в сети этот объект и
вызывает в нем операцию ANYOPER1. Приводимые ниже программы могут быть
выполнены с использованием либо трех, либо двух, либо одной ЭВМ. При этом как
исходные тексты программ, так и машинный код (только в случае однотипных ЭВМ) будут
идентичными для всех трех случаев.
/* ------------
программа-исполнитель
/* определение кластера ANYCLUST */
clust ANYOPER1, ANYOPER2 ANYCLUST
/* переменные представления объекта */
int ... ; char ... ; serv ... ; и т.п.
;
clbody ANYCLUST
oper ANYOPER1( ... )
---------------*/
/* тело функции, реализующей операцию ANYOPER1 */
oper ANYOPER2( ... )
/* тело функции, реализующей операцию ANYOPER2 */
/* Головная функция */
main()
/* описание четырех переменных типа объект-исполнитель, указывающих на:
- файл объектов текущей задачи - переменная TFO
- предопределенный каталог текущей ЭВМ - переменная DIROWN
- общесетевой каталог, зарегистрированный в текущей ЭВМ под именем PUBLICDIR,
- переменная DIR
- вновь создаваемый объект - переменная OBJ
*/
serv CREATE TFO;
serv FIND, ENTER DIR, DIROWN;
serv ANYOPER1, ANYOPER2 OBJ;
/* Сетевое инициирование */
ninit();
/* Получение ссылок на файл объектов задачи и каталог своей ЭВМ */
get_tfo(res TFO);
get_dir(res DIROWN);
/* Создание объекта */
TFO.CREATE(res OBJ, ANYCLUST);
/* Подключение к сетевому каталогу */
DIROWN.FIND(res DIR, "PUBLICDIR");
/* Регистрация объекта в каталоге */
DIR.ENTER(OBJ, "ANYOBJ");
/* Остаемся резидентом в ожидании вызовов операций */
nkeep();
/* ------------
программа-заказчик
---------------*/
main()
serv FIND DIR, DIROWN;
serv ANYOPER1 OBJ;
/* Сетевое инициирование */
ninit();
/* Получение ссылки на каталог своей ЭВМ */
get_dir(res DIROWN);
/* Подключение к сетевому каталогу */
DIROWN.FIND(res DIR, "PUBLICDIR");
/* Поиск объекта в каталоге */
DIR.FIND(res OBJ, "ANYOBJ");
/* Вызов целевой операции */
OBJ.ANYOPER1( ... );
ЛИТЕРАТУРА
1. А.И. Илюшин, и др. Вызов процедур в распределенных системах. Методические
материалы и документация по пакетам прикладных программ, вып. 24, ч. 1, Москва,
МЦНТИ, 1983, стр. 104-130.
2. A.I.Ilushin, A.N.Myamlin, V.S.Shtarkman, Computer Network Software Design Based
on Abstract Objects, Information Processing 83, Paris, 1983, pp. 23-28.
3. С.А.Васильев, и др. Объектно-ориентированные средства для программирования
распределенных систем. Методические материалы и документация по пакетам прикладных
программ, вып. 31, ч. 1, Москва, МЦНТИ, 1986, стр. 30-57.
4. Дерябин Н.Б., Илюшин А.И. Распределенное программирование на базе языка Си.
XIV Всесоюзная школа-семинар по вычислительным сетям. Тезисы докладов. МоскваМинск, 1989, ч.1, стр. 53-58.
5. Савицкая О.А., Илюшин А.И., Дерябин Н.Б. Распределенные вычисления в
Фортране. XIV Всесоюзная школа-семинар по выч. сетям. Тезисы докладов. МоскваМинск, 1989, ч.3, стр. 286-290.
6. Bjarne Stroustrup, The C++ Programming Language, Addison-Wesley, 1986, 328 pp.
7. ISO 7498 Information processing systems - Open Systems Interconnection - Basic
Reference Model.
Телефон для справок: 333-80-55 (Москва)
Скачать