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: и  гибко,  и

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

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

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

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

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

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

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

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