Generalizing dispatching in a distributed object system

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

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

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

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

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

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

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

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

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

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

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

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