BC/NW 2006, №2 (9): 11.2

 

 

АДАПТАЦИЯ ПРИНЦИПОВ АВТОМАТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ К ТЕХНОЛОГИИ CORBA

 

Р.А. Рыбаков

 

 (Москва, Московский энергетический институт (технический университет), Россия)

 

 

На сегодняшний день технология CORBA занимает лидирующие позиции в области разработки распределенного программного обеспечения и поддерживается большинством существующих аппаратных и программных платформ. Последние дополнения, касающиеся асинхронного вызова методов (AMI – Asynchronous Method Invocation), существенно расширили возможности данной технологии, позволив клиентам осуществлять неблокирующие двунаправленные вызовы с использованием SMI (Synchronous Method Invocation), тем самым, сняв ограничения предыдущих версий [1].

Однако, появление нового стандартизованного механизма, позволяющего обслуживать несколько двунаправленных запросов в пределах одного потока, привело к возникновению целого ряда трудностей, связанных с организацией процесса асинхронного взаимодействия. При этом предложенные стандартом схемы уведомления (модели callback и polling) рассчитаны на использование дополнительного механизма, ассоциирующего полученные результаты с запросами к удаленной стороне, реализация которого выходит за рамки стандарта CORBA.

Кроме того, нерешенными остались вопросы, связанные с асинхронной обработкой запросов на стороне сервера, что также снижает эффект от применения механизма AMI в многоуровневых серверах, где основные операции выполняются в отдельных потоках [2].

 

Для организации асинхронного взаимодействия в среде CORBA могут применяться различные методы. В качестве одного из вариантов может быть рассмотрен подход, основанный на использовании принципов автоматно-ориентированного программирования.

В отличие от традиционного программирования, оперирующего понятием «событие», данный стиль программирования базируется на понятии «состояние» [3]. В рамках автоматного подхода программирование выполняется не посредством переменных или флагов, как это делается в традиционном программировании, а посредством состояний, что позволяет лучше понять и специфицировать задачу и ее составные части.

Для реализации базовых принципов автоматно-ориентированного программирования была разработана модель UDE [4]. Основным элементом этой модели, отвечающим за формирование логики работы приложения и организацию процесса асинхронного взаимодействия удаленных объектов, являются распределенные процедуры, получившие название «DPC-процедур». Использование механизма DPC позволяет организовать внутреннюю логику приложения в виде наборов конечных недетерминированных автоматов, каждый из которых отвечает за реализацию отдельной функции UDE-объекта.

Основная идея разработанной модификации CORBA-UDE (рис. 1) состоит в том, чтобы дополнить текущую спецификацию CORBA 3.0 средствами двустороннего асинхронного взаимодействия, адаптировав к ней принципы автоматно-ориентированного программирования.

 

Рис. 1. Базовая архитектура CORBA-UDE.

        

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

Механизм работы CORBA-UDE приложений представлен на рис. 2.

 

Рис. 2. Механизм взаимодействия CORBA-UDE приложений.

 

При запуске сервера создается UDE-объект, отвечающий за выполнение требуемого набора функций. В процессе инициализации ему присваивается уникальный в пределах системы адрес (UNIADDR), используемый при последующих обращениях со стороны UDE-объектов, а также активируется объект-привратник (servant), обеспечивающий связь с элементами технологии CORBA. На финальной стадии происходит регистрация UDE-объекта в службах именования CORBA и UDE, после чего становится возможным обращение к объекту с удаленных узлов.

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

Механизм выполнения асинхронных запросов выглядит следующим образом: клиент формирует UDE-сообщение (пакет запроса), в котором содержатся адреса отправителя и получателя, код операции и параметры, необходимые для успешного выполнения запроса. Далее осуществляется вызов метода PostUDEMsg объекта UDEDispatcher, который осуществляет доставку сообщения объекту-получателю. После приема оно помещается в очередь сообщений соответствующего UDE-объекта, а клиент получает уведомление о доставке, и с этого момента может переходить к выполнению дальнейших действий.

По мере готовности сервер приступает к обработке запроса, в процессе выполнения которого могут потребоваться дополнительные обращения к другим UDE-объектам. После завершения процесса обработки, сервер формирует ответное сообщение, в котором содержатся адреса отправителя и получателя и результат выполнения запроса. Поскольку у клиентского UDE-объекта может отсутствовать связь с элементами CORBA, доставка ответного сообщения осуществляется с использованием UDEDispatcher клиента, так как он гарантированно взаимодействует с подсистемой CORBA посредством объекта-привратника (servant).

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

В модели UDE для организации асинхронных запросов используется специальный вид процедур, так называемые DPC-процедуры (рис. 3).

 

Рис. 3. Пример реализации DPC-процедуры на языке C++.

 

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

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

Механизм выполнения DPC-процедуры представлен на рис. 4.

 

Рис. 4. Механизм выполнения DPC-процедуры.

 

Активация DPC-процедуры производится при наступлении одного из событий: явный запуск процедуры в ответ на поступившее сообщение, повторный запуск при получении результата выполнения запроса и повторный запуск по прошествии критического интервала времени, отведенного на выполнение запроса.

В момент активации DPC-процедуры происходит восстановление (инициализация) значений локальных DPC-переменных из внутреннего стека процедуры, что позволяет организовать работу с локальными переменными так же, как в и случае с обычными процедурами и функциями.

В зависимости от текущего состояния автомата, хранящегося в дескрипторе DPC-процедуры, активируется участок кода (обработчик), соответствующий данному состоянию. В обработчиках состояний размещается основной код, реализующий логику работы процедуры. За каждым обработчиком следует одна из управляющих инструкций, которая определяет дальнейшее поведение автомата. В текущей реализации предусмотрены следующие управляющие инструкции:

1.     Безусловный переход к новому состоянию (Continue), выполняемый без прерывания процедуры.

2.     Условный переход на основе результата запроса к удаленному объекту (Suspend) – приостанавливает выполнение процедуры до момента получения результата запроса.

3.     Условный переход с таймаутом (SuspendWithKick) – приостанавливает выполнение процедуры до момента получения результата запроса или момента завершения указанного интервала времени.

4.     Завершение процедуры (End) – освобождает все ресурсы, связанные с данной процедурой, и прекращает ее выполнение.

5.     Отмена процедуры (Cancel) – осуществляет безусловный переход к специальному состоянию без прерывания процедуры и инициирует обработчик, в ходе выполнения которого возможен переход к другому состоянию, инициирующему новую цепочку действий.

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

Сторона, инициирующая запрос, формирует UDE-сообщение, указывая в нем всю необходимую информацию, после чего осуществляет его отправку с помощью объекта UDEDispatcher. Как правило, после команды отправки сообщения следует управляющая инструкция, определяющая дальнейшее поведение автомата. В большинстве случаев используются команды Suspend и SuspendWithKick, в параметрах которых задаются номера состояний, к которым будет осуществлен переход в случае успешного и неуспешного завершения запроса, а также в случае истечения указанного промежутка времени.

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

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

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

 

Последние дополнения к стандарту CORBA, касающиеся асинхронного вызова методов (AMI), лишь частично решили проблемы, связанные с организацией двунаправленного асинхронного взаимодействия в среде CORBA. В частности нерешенными остались вопросы асинхронной обработки запросов на стороне сервера. Кроме того, предложенные стандартом схемы уведомления о выполнения операций требуют реализации дополнительного механизма, ассоциирующего полученные результаты с запросами к удаленной стороне.

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

ЛИТЕРАТУРА

1.     Henning M., Vinoski S. Advanced CORBA® Programming with C++ // Addison-Wesley professional computing series, 1999. – 1120 p.

2.     Brunsch D., O’Ryan C., Schmidt D.C. Designing an Efficient and Scalable Server-side Asynchrony Model for CORBA // Proc. of the IFIP/ACM International Conference on Distributed Systems Platforms, Springer, 2000. – 7 p.

3.     Шалыто А.А. Логическое управление. Методы аппаратной и программной реализации алгоритмов. СПб.: Наука, 2000. 780 с.

4.     Рыбаков Р.А. Разработка модели взаимодействия объектов в распределенной среде // Радиоэлектроника, электротехника и энергетика // Двенадцатая Междунар. науч.-течн. конф. студентов и аспирантов: Тез. докл. В 3-х т. – М.: МЭИ, 2006. Т. 1. – с. 427-428.