←предыдущая следующая→
1 2
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: и гибко, и опасно. Постепенно выделятся общие пути диспетчеризации, которые станут высокоуровневыми абстракциями;
- отделение мета- и базового уровня. Смесь в одном диспетче-
ре доступа к обоим уровням трудна для восприятия;
- оптимизация. Преимуществом предложенной схемы является то, что она не рассчитана на конкретный метод диспетчеризации и, следовательно, возможно оптимизировать какие-либо части работающей системы не нарушая работы остальных.
←предыдущая следующая→
1 2