Введение

Для 4-го поколения SObjectizer была написана дополнительная библиотека для передачи сообщений, которая получила название MBAPI. Идея MBAPI заключалась в том, что сообщения пересылаются с одного mbox-а (почтового ящика) на другой. В процессе пересылки возможны и доставки сообщения до нескольких "слушателей" почтового ящика. Эта идея была взята за основу для организации локального обмена сообщениями между агентами в рамках одного SObjectizer Environment. Но MBAPI была создана в первую очередь для организации обмена сообщениями по сети, что в штатный механизм обмена сообщениями SObjectizer-5 не вошло. Но задачу организации обмена сообщениями между SObjectizer-приложениями призвано решить новое поколение библиотеки MBAPI, которое разработано с учетом опыта использования mbapi_3. В библиотеке mbapi_4 на смену mbox-ам и перехватчикам приходят понятия конечной точки и стадий. Кроме того внедрен механизм маршрутизации сообщений, который работает по принципам сетевого коммутатора, когда каждый mbapi_4 узел может выступать промежуточным звеном в передаче сообщения между двумя узлами, которые не имеют между собой mbapi_4-канала.

Основные понятия

Конечная точка и стадия конечной точки

Ключевым понятием mbapi_4 является конечная точка, информация о которой представляется классом endpoint_t. Все сообщения пересылаются от одной конечной точки к другой. Конечная точка может иметь цепочку стадий. Стадия представляет собой промежуточный этап, в которое попадает сообщение перед тем как прийти в конечную точку или к другой стадии. Причем при отправке сообщения от точки A к B сообщение сначала проходит через стадии конечной точки A, а затем через стадии – B. Для представления конечной точки и ее стадий служит класс endpoint_stage_chain_t, который позволяет создавать описание и текстового представления вида endpoint[stage1, stage2, ..., stageN] – endpoint_stage_chain_t::create_from_string().

Для представления промежуточной стадия конечной точки служит класс stagepoint_t. Стадия конечной точки идентифицируется именем стадии и именем конечной точки. Объекты stagepoint_t, можно создавть из текстового описания вида: stagename@endpointname при помощи stagepoint_t::create_from_string(). Надо заметить, что зачастую саму конечную точку удобно воспринимать, как особый вид стадии. Так, например, во внутренней реализации mbapi_4 при маршрутизации сообщений передача сообщения в конечную точку ничем не отличается от передачи сообщения следующей стадии.

Чтобы лучше понимать, какой путь проходит сообщение от одной конечной точки к другой, рассмотрим Следующий пример. Первая конечная точка: epA[sa1, sa2, sa3]; вторая: epB[sb1, sb2]. Тогда при отправке сообщения от epA в epB, оно должно пройти следующий путь: sa1@epA => sa2@epA => sa3@epA => sb2@epB => sb1@epB => epB

mbapi-сообщение

Mbapi-сообщение передаваемое в рамках mbapi_4 имеет асиметричное представление в зависимости от ситуации. Когда сообщение отправляется, пользователю достаточно передать объект, который является наследником от oess_2::stdsn::serializable_t, но для принятия сообщений конкретным агентом, пользователь должен создавать у агента обработчик, которому это сообщение будет передаваться в виде обертки message_t < SERIALIZABLE >, где SERIALIZABLE – это то самое пользовательское сообщение. Например, пусть ping_t – это пользовательский класс, тогда обработчик сообщения агента должен иметь следующую сигнатуру:

class a_sample_agent_t
    :
        public so_5::rt::agent_t
{
    // ...
    void
    evt_ping(
        const so_5::rt::event_data_t< mbapi_4::message_t< ping_t > > & msg );
    // ...
};

Кроме самого сообщения message_t содержит информацию об отправителе и получателе сообщения. Доступ к сообщению можно получить с помощью message_t::msg(). Кроме того через обертку message_t агент, выполняющий обработку на одной из стадий может передать сообщение слудующей стадии без изменений или заменив его – message_t::move_next().

Привязка к конечной точке и стадии

В то время, как классы endpoint_t и stagepoint_t предоставляют только информацию о конечной точке или стадии, то для реальной отправки и получения сообщений служат привязки. Это классы предоставляющие возможность отправки сообщений и подписки на них.

Для привязки к промежуточной стадии конечной точки служит stagepoint_bind_t. Он позволяет только подписываться на получения сообщений. Для подписки на сообщения служит метод stagepoint_bind_t::subscribe_event(), а для отписки – stagepoint_bind_t::unsubscribe_event().

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

Для привязки к конечной точке служит endpoint_bind_t. Он является наследником stagepoint_bind_t и добавляет к нему возможность отправки сообщений при помощи метода endpoint_bind_t::send(), который начинает движения сообщения через все стадии к указанной в параметрах конечной точке-получателю. Привязки создаются при помощи слоя mbapi_4.

Слой mbapi_4

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

Каждый SObjectizer Environment со слоем mbapi_4 представляет собой mbapi-узел с некоторым количеством конечных точек и промежуточных стадий. С помощью коммуникационных каналов (см. Коммуникационные каналы mbapi_4) mbapi-узлы могут связываться между собой в mbapi-сеть. Внутри которой, при необходимости, сообщение может прийти с любого узла на любой другой. При выдаче привязки в узле создается соответствующая конечная точка или стадия, информация о которой передается другим mbapi-узлам, чтобы те использовали ее для маршрутизации сообщений (см. Маршрутизация сообщений).

Привязки к конечным точкам и стадиям выдается с помощью методов mbapi_layer_t::create_endpoint_bind() и mbapi_layer_t::create_stagepoint_bind() соответственно. Слой контролирует уникальность выдаваемых привязок, поэтому в одном SObjectizer Environment не может быть более 2-ух привязок к одной конечной точке или стадии. Когда создается привязка к конечной точке, то в данном mbapi-узле появляется описание конечной точки: ее имя и последовательность имена всех ее промежуточных стадий. Эта информация используется для маршрутизации сообщений.

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

Информация о маршрутизации скрыта от пользователя, и доступна только коммуникационным каналам и самому слою, который выполняет маршрутизацию.

Маршрутизация сообщений

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

Таблица конечных точек – описания доступных конечных точек, в виде описания конечной точки и последовательности ее стадий. Служит для составления детального маршрута сообщения между двумя конечными точками. Имея детальный маршрут и текущую точку-стадию можно определить следующую, либо выяснить, что это была конечная точка.
Таблица точек-стадий обозримой mbapi-сети – содержит информацию о том на каких узлах созданы привязки к конечным точкам (рассматриваются, как частный случай стадии) и к промежуточным стадиям. Эта информация нужна, чтобы определять канал в который нужно отправлять сообщение, чтобы оно попало в обработчик заданной стадии.

Каждый mbapi-узел имеет уникальный идентификатор – node_uid, и этот идентификатор приписывается каждой записи маршрутной таблицы. Кроме того каждая запись в маршрутных таблицах сопровождается полем distance – расстояние до mbapi-узла на графе mbapi-сети, от которого исходит та или иная информация. Если, например, информация о конечной точке исходит от того, что на данном узле создана привязка к соответствующей конечной точке, то поле distance у этой записи будет равно 0. А если, например, информация о наличии стадии пришла с соседнего узла, в котором создана соответствующая привязка, то distance у этой записи будет равно 1, т.к. непосредственно до этой стадии надо сообщение должно преодолеть один канал. Причем при синхронизации маршрутных таблиц существующая запись заменяется на более свежую, если она исходит от того же mbapi-узла (определяется на основе node_uid) либо если она исходи от узла, который находится ближе (определятся на основе distance).

Каждый mbapi-узел отсылает соседним mbapi-узлам свои таблицы конечных точек и точек стадий с периодичностью в 1 секунду.

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

Если в момент маршрутизации оказалось, что информация о какой-либо конечной точке отсутствует или стадия получатель отсутствует в обозримом mbapi-окружении, то сообщение теряется.

Коммуникационные каналы mbapi_4

Соединение mbapi-узлов в сеть осуществляется по средством коммуникационных mbapi-каналов. Серверный и клиентский канал построены на библиотеке so_5_transport. Для создания серверного канала служит агент comm::a_mbapi_incoming_channel_t, а для клиентского – comm::a_mbapi_outgoing_channel_t. Эти агенты отвечают за поддержку транспортного протокола mbapi_4, с помощью которого два mbapi-узла общаются между собой с целью обмена маршрутными таблицами и передачи сообщений. Коммуникационные агенты с периодом в 1 секунду берут из слоя mbapi_4 копию маршрутных таблиц и пересылают их в свои каналы. Когда же они сами получают копии маршрутных таблиц соседнего mbapi-узла, то они выполняют синхронизацию маршрутных таблиц локального узла с пришедшими копиями.

Создание транспортных каналов с помощью so_5_transport разобрано в Кооперация агентов транспортного канала.

Оглавление