Generaliting Dispatching in Distributed Object System русский

между компонентами распределенной по сети

системы благодаря гибкому 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: и гибко, и

опасно. Постепенно выделятся общие пути диспетчеризации, которые

станут высокоуровневыми абстракциями;

- отделение мета- и базового уровня. Смесь в одном диспетче-

ре доступа к обоим уровням трудна для восприятия;

- оптимизация. Преимуществом предложенной схемы является то,

что она не рассчитана на конкретный метод диспетчеризации и, сле-

довательно, возможно оптимизировать какие-либо части работающей

системы не нарушая работы остальных.