Generalizing dispatching in a 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: IInteger; 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) ) ) ; END IF RAISE Obj. Exception (Exception. badFunction) ; END IntegerDispatch ; Заклинания и dispatching. Для создания заклинания клиенты пользуются процедурой Obj. Invoke. Для предыдущего примеры это выглядит примерно так: IInteger, 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: и гибко, и опасно. Постепенно выделятся общие пути диспетчеризации, которые станут высокоуровневыми абстракциями; - отделение

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