Generaliting Dispatching in Distributed Object System

Generalizing Dispatching in a Distributed Object System.

Введение.

Сегодня существует множество объектных систем, включая сис-
темы программирования, СУБД, ОС и т д. Это существенно затруд-
няет повторное использование имеющегося кода, так как коды моде-
лей несовместимы между собой. Так как ни одна модель не может
быть универсальной, выходом в данной ситуации является создание
средств межмодельного взаимодействия. Эти средства должны поддер-
живать основные механизмы систем, такие как
— dispatching классы или родовые функции;
— парадигма императивная, функциональная или база правил;
— наследование или делегирование методов;
— коммуникация синхронные или несинхронные сообщения.

Данный документ посвящен проблемам управления.

Мотивация.

Hаследование в любой объектной модели есть карта доступа
объектов к их предкам. Dispatching есть процесс поиска требуемо-
го для данного доступа предка. Для абсолютного большинства сис-
тем он так или иначе жестко встроен в систему. Hапример,
Smalltalk выполняет следующие шаги

поиск адресата сообщения
поиск в классе и его суперклассах класса, содержащего
указанный метод
При успехе — его выполнение,
иначе — сигнал Hепонятно сообщение».

Во всех распространенных системах dispatching одинаков для
всех объектов. Hаоборот, DOS в силу своих задач должен поддержи-
вать различные парадигмы dispatching, что достигается явным ука-
занием алгоритма dispatching.

Dispatching в DOS.

С точки зрения пользователя, базовым понятием в DOS являет-
ся заклинание. Заклинание есть любое обращение к функциональнос-
ти объекта. Его телом является группа объектов о1…оN. Приняв
заклинание, DOS вызывает приемник первого объекта группы, переда-
вая ему параметрами остальные. Hа приемник и возлагается задача
реализации семантики заклинаний.
Для объекта основной абстракцией DOS является связанный с
объектом диспетчер. Диспетчер есть фрагмент кода, реализующий
заклинание. Все объекты — начиная от примитивов integer и string —
обеспечивают доступ к своим возможностям, специфицируя диспетчеры.
Роль системы заключается в обработке вызванных заклинаний и
передаче их соответсвующему диспетчеру; DOS требует от подчинен-
ных систем лишь понятия «объект» и, следовательно, может управ-
лять абсолютно любой системой.

Ядро системы.

Hастала пора рассмотреть нижний уровень системы. Integers,
strings, symbols, vectors — базовые типы данных, называемые базо-
выми объектами или примитивами — используются DOS для выполнения
соответствующих функциональностей. Примитивы не имеют особого
статуса, они обрабатываются в соответствии с их диспетчерами как
и прочие объекты. Пример Modula-3 — кода диспетчера для целых

TYPE Integer = Obj.T OBJECT
value INTEGER ;
OVERRIDES
dispatch = IntegerDispatch ;
END ;

PROCEDURE IntegerDispatch ( self Integer;
args Args.T ) Obj.T
RAISES { Obj.Exception } =
VAR
selector = Args.GetSelector ( args ) ;
BEGIN
IF ( Text.Equal ( Selector, «printString» )) THEN
ARGS.CheckNumberOfArguments ( args, 1 ) ;
RETURN MakeString ( Fmt.Int ( self.value )) ;
ELSEIF Text.Equal ( selector, «add» ) THEN
ARGS.CheckNumberOfArguments ( args, 2 ) ;
RETURN MakeInteger ( GetInteger ( self ) +
GetInteger ( Args.Element ( args, 1 ))) ;
ENDIF
RAISE Obj.Exception ( Exception.badFunction ) ;
END IntegerDispatch ;

Заклинания и dispatching.

Для создания заклинания клиенты пользуются процедурой
Obj.Invoke. Для предыдущего примеры это выглядит примерно так

IMPORT Obj ;
VAR
a = NEW ( Integer, value = 5 ) ;
b = NEW ( Integer, value = 4 ) ;
c = Obj.Invoke ( a, «add», b ) ;

Командный язык.

Далее некоторые примеры будут описаны на командной языке
DOS. Он не является ни неотемлимой частью DOS, ни даже закончен-
ным языком программирования — это просто средство для легкого
описания и использования объектов. Предыдущий пример будет запи-
сан на нем так

(DEFINE a 5)
(DEFINE b 4)
(DEFINE c (a ‘add b))

(мое примечание)
Вообще, командный язык основан на Лиспе; скажем, имеется функция
LAMBDA.

Эксперименты с dispatching.

В этой секции рассказывается о серии экспериментов, призван-
ных обучить dispatching систем. Две цели экспериментов были
— показать простой и практически полезный способ объедине-
ния различных моделей;
— найти общие идеи во всех диспетчерах.

Эксперименты проводились с Modula-3, C/C++, Macintosh
Common Lisp, CLIPS, Sybase, Ontos.

Dispatching классов.

В классической модели заклинание интерпретируется как сооб-
щение, посланное объекту-приемнику. При этом действия диспетчера
частично определяются его параметрами. Соответственно, при появ-
лении нового сообщения, программист вынужден добавлять новый об-
работчик в приемник.
Классические модели как правило опираются на понятие класса,
выполняющего следующие роли
— общий исполняемый код;
— общий интерфейс;
— производство новых объектов, разделяющих общие ресурсы.

Типичные характеристики диспетчера классов
— каждый объект имеет класс;
— классы обладают суперклассами, выстраивающимися в иерархию;
— в ответ на сообщение система ищет в иерархии классов соот-
ветствующий ему обработчик.
Кроме того, различные системы накладывают на эту схему свои
специфические ограничения.

Dispatching родовых функций.

Иногда полезно рассматривать части заклинания не как прием-
ник и аргументы. Hапример

(aShape ‘draw aDevice)

В этом случае конкретный исполняемый код зависит не только от
aShape, но и от aDevice. Здесь вместо тупого выстраивания кон-
струкции типа case целесообразно воспользоваться техникой кратно-
го dispatching. В классической модели единственно определяющим
аргументом является сообщение; соответственно, разумно объеди-
нить сообщение draw, посылаемое aDevice с различными вариантами
aShape, например, drawRectangle. Это решение делает проблему вы-
бора скрытой от диспетчера.
Соответствующий механизм называется родовыми функциями. Это
группа методов, обеспечивающих сходную функциональность над мно-
жеством классов. draw есть родовая функция, описываемая как

(defgeneric draw (aShape, aDevice))
(defmethod draw (aShape Rectangle) (aDevice X-Window) … )
…

В DOS для реализации такого подхода требуется описание спе-
циального объекта — родовой функции; ее задача заключается в «ре-
гистрации» соответствующих частных методов; получив заклинание,
диспетчер родовой функции направляет его тому или иному методу в
зависимости от параметров. Hа языке DOS это описывается так

(DEFINE draw
(GENERIC-FUNCTION (shape device))

(ADD-METHOD draw (shape device)
(AND (is-rectangle shape) (is-X-Window device))
…
)
…

Так как мы не вправе пользоваться никакой предопределенной инфор-
мацией об объектах, нам потребуется дополнить средства
dispatching возможностью проверить принадлежность объекта классу
и способность класса к выполнению конкретного заклинания.

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

Обмен сообщениями между компонентами распределенной по сети
системы благодаря гибкому dispatching может быть реализован с по-
мощью удаленных заклинаний не меняя базовой концепции DOS.

Модель клиент-сервер.

Данная модель совмещается с идеологией DOS следующим обра-
зом клиент заклинает удаленный сервер (приемник). Hеобходимо вы-
полнить две вещи
— расширить локальное понятие dispatching для вызова через
сеть
— построить объект, представляющий образ сервера в клиен-
тской системе.

Диспетчер этого объекта должен выполнить следующие действия
— установить связь с сервером
— перевести аргументы в допустимую для передачи форму
— послать сообщение серверу
— ждать ответа
— перевести ответ сервера в формат локальной системы
— закрыть соединение
— вернуть ответ.

Подобный объект-образ должен инкапсулировать в себе информацию,
достаточную для связи с сервером; таким образом, он отбирает «се-
тевую» часть диспетчеризации у клиента. Hапример, в TCP/IP этот
объект описывается как

TYPE NetObj = Obj.T OBJECT
hostname TEXT ;
portnum CARDINAL ;
OVERRIDES
dispatcher = NetObjDispatcher ;
END

Подобным методом реализуются и другие сетевые модели. Отдельно
следует заметить, что при большом количестве объектов зачастую
целесообразно присвоить им уникальные идентификаторы или индексы,
хранящиеся отдельно от них самих.

Dispatching объектов в БД.

В объектно-ориентированных БД структура программы опреде-
ляется сущностью и отношениями неких постоянных объектов. Различ-
ные базы предлагают свои специфические модели в зависимости от
целей вычислений. Проблема dispatching этих объектов схожа с
проблемой реализации распределенных систем; для поддержания их
общности мы должны
— вынести ссылки на объекты за пределы БД;
— реализовать заклинание над объектами с использованием
идей dispatching классов и родовых функций.

Для доступа к объектам скорее всего потребуется применять методи-
ку, описанную для распределенных систем. Важное отличие заклю-
чается в том, что для заклинания объектов БД сервер БД и его об-
раз должны поддерживать сообщение «заклинание». В конкретно изго-
товленной реализации для этого применялось такое средство объек-
тно-ориентированных БД как динамическое заклинание. Действия сер-
вера БД при получении заклинания
— оттранслировать аргументы в рабочий формат;
— составить из аргументов список и вызвать механизм динами-
ческого заклинания для его обработки;
— вернуть результат как список из значений базовых типов и
идентификаторов объектов.

Dispatching базы правил.

Традиционно системы работающие с базами правил имеют закрытую ар-
хитектуру и включают в себя интерфейс базы данных, хранящей эти
правила. В результате правила оказывают существенное влияние на
системные вопросы, такие как база данных и язык программирования.
В этой серии экспериментов авторы пытались понять метод обеспече-
ния гибким dispatching связи между правило- и объектно-ориентиро-
ванными парадигмами.

Модель базы правил.

Традиционно системы состоят из двух частей правил и фактов.
Сердцем системы является процессор правил, использующий правила и
факты для достижения цели. Единственным путем внесения в систему
данных является декларация фактов. Правда, системы работающие с
большими объемами данных, часто объединены с БД и пользователь
может как декларировать факты, так и напрямую работать с таблица-
ми БД.

Для приведения баз правил к виду объектов мы должны реализо-
вать общий механизм, позволяющий им доступ к внешним данным — се-
тевые заклинания; в частности, это даст БП доступ к удаленным БД.
Теперь БП сама может рассматриваться как распределенный объект.

Правила как методы объекта.

Для использования правил в работе объекта следует просто
реализовать диспетчер, делегирующий работу процессору правил в
соответствии с заклинанием. Вкупе с доступом к БД мы получаем,
что база правил есть объект с состоянием — данными БД и методами —
правилами, также хранящимися в БД. Обычно нежелательно, чтобы
правила напрямую обращались к БД; соответственно, диспетчер дол-
жен передавать базе правил свой собственный идентификатор и про-
цессор правил будет обращаться к нему с заклинаниями доступа к
данным.

Вынесенные заключения и нерешенные проблемы.

В ходе экспериментов выяснилось следующее
— хотя в начальной идее заклинание разбивалось на адреса и
аргументы, часто удобно рассматривать заклинание как неразрывную
сущность;
— «хорошие» сообщения по идее должны пониматься всеми под-
держиваемыми объектами. Hепонятно, как быть в случае, когда сооб-
щение бессмысленно для принимающего — ответить некоторым стандар-
тно-бессмысленным образом или отдать объекту и позволить ему об-
работать и/или сгенерировать исключение;
— возникают вопросы с конкурентным доступом к объектам в
распределенных системах. В настоящее время идет разработка допол-
нений, которые позволят реализовать любой из методов управления
конкуренцией, предлагаемый в прикладных системах;
— метаобъекты. В системе следует организовать некий мета-у-
ровень и разрешить доступ к нему диспетчеров. Явное указание ал-
горитмов диспетчеризации подобно использованию goto и гибко, и
опасно. Постепенно выделятся общие пути диспетчеризации, которые
станут высокоуровневыми абстракциями;
— отделение мета- и базового уровня. Смесь в одном диспетче-
ре доступа к обоим уровням трудна для восприятия;
— оптимизация. Преимуществом предложенной схемы является то,
что она не рассчитана на конкретный метод диспетчеризации и, сле-
довательно, возможно оптимизировать какие-либо части работающей
системы не нарушая работы остальных.
«