next_inactive up previous


PIMR: Руководство программиста
Версия 1.0.0
www.gradsoft.kiev.ua


Contents

Введение

PIMR" ("репозитарий) предоставляет собой способ повысить доступность и облегчить конфигурирование взаимосвязанных CORBA-сервисов. Репозитарий также можно использовать вместо nameservice для получения инициальных объектных ссылок на необходимые сервисы. Репозитарий регистрирует в своей базе данных сервисы и при получении запроса (далее "заявки") - перенаправляет его подходящему сервису. Кроме того репозитарий отслеживает доступность известных ему сервисов и при необходимости делает попытку перезапустить сбойный сервис.

В данной реализации (версия 1.0.0) отслеживание доступности сервисов производится периодически через определённый промежуток времени. Частота проверки настраивается в конфигурационном файле, с помощью команды checkfreq {число}. При обнаружении недоступности сервиса производится попытка возобновления его работы. Если сервис не подал сигнал о успешной перезагрузке и остаётся недступным по истечении таймаута, он помечается как сбойный и более не перезапускается.

Прикладным программистам репозитарий предоставляет API, описываемое с помощью idl-интерфейсов.

Свойства сервиса и операции над ним

Со статической точки зрения сервис характеризуется набором взаимосвязанных свойств и операций. Некоторые свойства могут быть не установлены, поэтому они представлены множеством {флаг,свойство[, свойство...]}, в котором флаг определяет определённость свойств. Если флаг установлен - группа свойств определена и ими можно пользоваться. Если соответствующий флаг не установлен - значения свойств этой группы не имеют определённого смысла (хотя их и можно прочитать).

Свойства сервиса:

Динамическая часть

Рисунок: Диаграмма основных состояний
\begin{figure}\begin{verbatim}.------------------. \vert С... ...ОМ \vert \vert \____________________________________/\end{verbatim}\end{figure}

Рисунок: Переход через промежуточное состояние
\begin{figure}\begin{verbatim}ОСТАНОВЛЕН \vert \vert /инициирование запус... ...аймаут \vert \vert /запуск подтверждён v РАБОТАЕТ\end{verbatim}\end{figure}

Диаграмма основных состояний сервиса изображена на рисунке 1. На ней изображены основные состояния и возможные переходы между ними:

1
Запуск сервиса (переход через промежуточное состояние)
2
Остановка сервиса (переход через промежуточное состояние)
3
Работающий сервис стал недоступен
4
Недоступный сервис должен быть доступен в этот момент
5
Перезапуск сервиса (переход через промежуточное состояние)
6
Остановка сбойного сервиса (переход через промежуточное состояние)
7
Сервис запустили
8
Сервис остановили

При этом переход 8 запрещен для сервисов с флагом "всегда доступен". Сервисы со сброшеным флагом "всегда доступен" при обнаружении их недоступности считаются остановленными.

Диаграмма содержит два разных перехода из состояния ОСТАНОВЛЕН в РАБОТАЕТ и это не ошибка так как переходы 1,2,5,6 производятся через дополнительно введённые состояния (2).

API репозитария

API репозитария представлено в файле pimr.idl: 

#pragma prefix "gradsoft.kiev.ua"

module PIMR
{

 interface CheckCallback;

 interface Repository
 {

   exception UnknownServiceName {};

   /**
    * must be call by client, which know about PIMR after
    * startup.
    **/
   void activated(in string service, in Object instance)
           raises(UnknownServiceName);

   /**
    * we can call checker for service
    **/
   void setCheck(in string service, in CheckCallback callback)
           raises(UnknownServiceName);
    
 };

 enum ServiceStatus { Unknown, NotRunning, Correct };

 //   
 interface CheckCallback
 {
   ServiceStatus     checkStatus(in string service);
 };


};

#endif
Интерфейс Repository (а также RepositoryAdmin, определённый в файле PIMRAdmin.idl) реализуется CORBA-объектом репозитария, доступным по ссылке:

corbaloc::хост_репозитария:порт_репозитария/Repository

А CheckCallback предназначен для реализации в сервисе, поддерживающем репозитарий. Задача этого интерфейса - реализовать своеобразный CORBA-ping - проверку доступности сервиса. При этом операции activated() и(или) setCheck() могут быть вызваны объектом-сервисом при старте. Эти операции сообщают репозитарию о активизации данного объекта-сервиса. Отличие между ними состоит в том, что первая операция сообщает репозитарию информацию о (возможно, изменившемся) расположееии объекта-сервиса, а вторая - о расположении объекта, реализующего интерфейс CheckCallback и принадлежащего вызывающему сервису.

Примеры, использующие эти интерфейсы, расположены в инсталяции репозитория в поддиректории "demo, ознакомтесь с ними.

Хотя вызывать их и не обязательно, для полной поддержки репозитария необходимо после запуска сервиса вызвать сначала activated(myIOR)" а затем \verb"setCheck(callBack). Это гарантирует, что репозитарий будет знать о расположении объекта-сервиса и сможет проверить его доступность.

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

Взаимодействие репозитария и объекта-сервиса

Взаимодействие репозитария и объекта-сервиса возможно в нескольких вариантах:

Дополнительно в конфигурационном файле можно предоставить репозиторию информацию о перезапуске сервиса. Тогда этот сервис будет иметь установленным флаг restart_flag, называющийся ещё "всегда доступен" и репозиторий будет перезапускать его, если обнаружит что он недоступен.

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

Взаимодействие репозитария и объекта-клиента, использующего сервис

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

corbaloc::хост_репозитария:порт_репозитария/имя_необходимого_сервиса

Клиент направляет заявку используя этот корбалок. Орб клиента связывается с репозитарием и передаёт заявку. Орб клиента получает:

Если орб клиента плучает указание перенаправить заявку, то эта (и последующие) заявка отправляется скрыто для объекта-клиента по ссылке, предоставленной репозиторием.

Детали реализации: Орб клиента связывается с репозитарием и передаёт заявку. Репозитарий использует динамический сервант-приманку для ассоциирования с объектом, доступным по ссылкам указанного выше вида.

Поэтому заявка клиента направляется орбом репозитария серванту-приманке, но ее перехватывает интерцептор. Интерцептор извлекает имя_сервиса, содержащееся в заявке, затем обращается к внутреннему реестру для получения информации о сервисе. В зависимости от полученной информации интерцептор может произвести определенные операции над сервисом, согласно алгоритму работы репозитария, до источения таймаута redirecttimeout. Затем интерцептор возвращает результат клиенту.

Для лучшего понимания рассмотрите примеры в директории "demoдистрибутива репозитория.

Изменения

15.08.2002
Создана предварительная версия.

next_inactive up previous
GradSoft