Сервисы

• Сервер БД
• secInfoService
• Сервис таймеров

Сервер БД

См. также:

(DBServer_MySQL) Реализация сервиса ведения БД на основе MySQL

Сервер БД

Общие сведения

Предназначен для работы с БД. Основная задача это - сохрание информации о датчиках, ведение журнала сообщений.

Сценарий работы

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

• через NameService
• при помощи UniversalInterface::send()

Сервис является системным, поэтому его идентификатор можно получить при помощи UniSetTypes::Configuration::getDBServer() объекта UniSetTypes::conf.

Реализацию см. (DBServer_MySQL) Реализация сервиса ведения БД на основе MySQL

Сервис сообщений

Общие сведения

В его задачи входит обработка всех сообщений для оператора. При приходе сообщения он производит следующие действия:

• переправляет сообщение в БД (Сервер БД)
• рассылает сообщение на все узлы, если оно помечено как broadcast.
• рассылает сообщение всем занесённым в RouteList(см. конф.файл).
• обрабатывает сообщение специфичным для каждого проекта образом (т.е. вызывает виртуальную функцию InfoServer::processing() )

Сценарий работы

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

• через NameService
• при помощи UniversalInterface::send()

Сервис является системным, поэтому его идентификатор можно получить при помощи UniSetTypes::Configuration::getInfoServer() объекта UniSetTypes::conf.

Интерфейс

InfoServer позволяет заказывать уведомелние о приходе тех или иных сообщений, а также подтверждения(квитирования). Можно производить заказ сообщения по коду

        InfoServer::ackMessage(UniSetTypes::MessageCode msgid, const UniSetTypes::ConsumerInfo& ci, 
                                    UniversalIO::UIOCommand cmd, CORBA::Boolean acknotify);

или сразу из диапазона кодов

        InfoServer::ackMessageRange(UniSetTypes::MessageCode from, UniSetTypes::MessageCode to,
                                    const UniSetTypes::ConsumerInfo& ci, 
                                    UniversalIO::UIOCommand cmd, CORBA::Boolean acknotify);

Реализацию см. InfoServer

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

Общие сведения

Данный сервис предоставляет возможность заказа переодических сообщений UniSetTypes::TimerMessage т.е. таймеров. Каждый заказчик может заказывать несколько таймеров, различающихся идентификаторами. При этом идентификаторы определяет сам заказчик. Они должны быть уникальны только для одного заказчика.

Заметки:

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

Сценарий работы

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

• через NameService
• при помощи UniversalInterface::askTimer()

Сервис является системным, поэтому его идентификатор можно получить при помощи UniSetTypes::Configuration::getTimerService() объекта UniSetTypes::conf.

Интерфейс

Сервис предоставляет одну функцию

        void TimerService::askTimer( CORBA::Short timerid, CORBA::Long timeMS, const UniSetTypes::ConsumerInfo& ci,
                                CORBA::Short ticks)

при помощи которой осуществялется заказ таймера.

Аргументы:

timerid

- уникальный идентификатор таймера

В случае попытки заказать таймер с уже существующим (для данного заказчика) идентификатором вырабатывается исключение TimerService_i::TimerAlreadyExist.

Аргументы:

	timeMS	- период между уведомлениями. Для отказа от таймера необходимо указать timeMS=0.
	ticks	позволяет ограничить количество уведомлений.

Если ticks<0 уведомления будут посылатся, пока заказчик сам не откажется от них. Общее количество таймеров (на всех заказчиков) ограничено ( TimerService::MaxCountTimers ). В случае превышения данного предела на все заказы будет вырабатываться исключение TimerService_i::LimitTimers. Для преодоления этого ограничения, а так же для обеспечения оптимальной работы сервиса, можно запускать на одном узле несколько TimerService-ов для распределения нагрузки(заказов) между ними. При этом за распределение заказов отвечает, разработчик.

Время жизни заказа

Для того, чтобы оптимизировать работу сервиса и уменьшить на него нагрузку вводится понятие "время жизни заказа". В случае, если в течение TimerService::AskLifeTimeSEC не удаётся послать заказчику уведомление, в следствие его недоступности - заказ анулируется.

Заметки:

Параметры можно задавать в конфигурационном файле Реализацию см. TimerService