Взаимодействие программного агента на уровне сессии с интеллектуальными пространствами

На программной платформе Smart-M3 реализуются многоагентные распределенные системы, в которых агенты взаимодействуют в общем интеллектуальном пространстве (ИП, от англ. smart space) [7], [9]. Агент – программа, работающая на вычислительном устройстве. Семантический информационный брокер (SIB, от англ. semantic information broker) реализует интерфейс доступа агентов к ИП.

Информация в ИП представлена моделью RDF (от англ. resource description framework) в виде троек: субъект, предикат, объект. Это позволяет проводить машинную обработку и вывод новых понятий [5]. Таким образом, ИП рассматривается как база знаний [4], формируемая агентами и управляемая брокерами. Агент взаимодействует с брокером по протоколу SSAP (от англ. smart space access protocol) на основе сеансов клиент-сервер [8]. Для отслеживания изменений на стороне ИП в рамках сеанса организуются подписки [2].

В статье предлагается частный случай модели взаимодействия в распределенной системе [3] для поддержки параллельных сеансов агента с ИП. Модель определяет сессию, операции управления и хранилище данных. Используется онтолого-ориентированный подход к разработке агента [11] на основе языка веб-онтологий OWL. Подробнее о разработке агентов в [12], об использовании онтологий для разработки программного обеспечения и агентов в [10], [11].

Модель используется в авторском инструментарии для разработки Smart-M3 агентов SmartSlog [1] и позволяет уменьшить объем программного кода агента, использующего параллельные сеансы, и способствует разработке агента с более высоким уровнем переносимости.

УРОВЕНЬ СЕАНСОВ

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

Будем представлять сеанс p как ( Q_p , T_p ), где Q_p – это множество подписок агента в сеансе, T_p^p – набор всех троек, используемых (отправляе-м ^p ых и получаемых) в операциях сеанса. Множество всех сеансов и подписок заданного агента обозначим как P и Q .

Агент работает с локальными копиями данных, поэтому при использовании параллельных сеансов необходимо объединять данные, так как в распределенных системах связанные между собой данные могут получаться из различных источников. Пусть D = Y_{p ∈ P}T_p – локальное хранилище на стороне агента.

Рассмотрим пример использования параллельных сеансов на основе «умного дома», где ИП₁ работает внутри дома, а ИП₂ работает в доме и снаружи (рис. 1). В ИП₁ есть информация о звонках и электронных письмах, в ИП₂ – о звонках. В доме агент использует два параллельных сеанса, снаружи – один. При выходе из дома сеанс p ₁ с подписками завершается. При возвращении в дом сеанс p ₁ и подписки должны быть восстановлены. Нужно провести синхронизацию локального хранилища D с данными сеанса T_{p 1}, например, добавить данные о письмах и звонках в хранилище D , учитывая дублирование.

Рис. 1. Работа параллельных сеансов

Таким образом, для поддержки параллельных сеансов нужно: 1) реализовать работу сеансов и подписок, 2) организовать хранение данных с возможностью объединения и синхронизации. Для решения этих задач предлагается объединить сеансы в сессии и реализовать хранилище данных, разделенное между сеансами сессии, с возможностью синхронизации на основе подписок.

УРОВЕНЬ СЕССИЙ

Предлагаемой моделью параллельных сеансов описываются сессия, основанная на модели многоэлементной сессии [6], операции управления и хранилище данных. Данные представлены сущностями языка онтологий OWL: классами, свойствами и индивидами (экземплярами классов). Это позволяет работать с объектами (например, человек, машина) и скрыть низкоуровневые детали, упрощая разработку агента [11]. Данный подход позволяет использовать модель в инструментарии SmartSlog.

Сеансы объединяются в сессии s , реализуемой на прикладном уровне сетевой модели OSI [3] и определяемой как ( P_s , Q_s , D_s ), где P_s – сеансы, Q_s – подписки, D_s – хранилище данных. С точки зрения онтологического представления хранилище D_s определим как O_c ∪ O_v ∪ O_i , где O c , O v , O i - множества классов, свойств и индивидов. Все объекты онтологии O представим как O_c ∪ O_v ∪ O_i .

Если сеанс p ∈ P_s , то в контексте сессии представим его как p = ( Q_p , O_p ), где Q_p ∈ Q_s , O_p ∈ D_s . Сеанс или подписка могут находиться в активном состоянии или в состоянии ожидания. Пусть множество сеансов P_s и подписок Q_s – это дизъюнкции P_a ∪ P_w и Q_a ∪ Q_w , где P_a , Q_a^s и P_w , Q_w – множества сеансов и подписок в активном состоянии и в состоянии ожидания. Для сеанса p ∈ P_a установлено сетевое соединение с брокером для операций по протоколу SSAP. Для подписки q ∈ Q_a ожидаются уведомления от брокера. Для сеанса p ∈ P_w и подписки q ∈ Q_w сетевое взаимодействие отсутствует.

В модели управление объектами выполняется на основе операций, каждое имеет вид (табл. 1):

U = { REG , DEL , ACTIVE , WAIT }, где REG – регистрация, DEL – удаление, ACTIVE – активация, WAIT – ожидание. Регистрация – это локальная операция, устанавливающая связь между объектами (сеансами, подписками, сущностями онтологий) и сессией. Операция DEL удаляет связь объекта с сессией. Операции ACTIVE и WAIT используются для управления состоянием всей сессии, отдельных сеансов и подписок.

УПРАВЛЕНИЕ ОБЪЕКТАМИ ДАННЫХ В РАМКАХ СЕССИИ

Все объекты сессии имеют уникальные идентификаторы, при помощи которых осуществляется регистрация. Для сессии и подписок идентификаторы генерируются при создании. Идентификаторы сеансов задаются разработчиком. Для классов и свойств используются URI (от англ. Uniform Resource Identifier, унифицированный идентификатор ресурса) [5] из онтологии. Для индивидов URI задается разработчиком либо создается на основе URI родительского класса.

На рис. 2 представлена диаграмма состояния объектов в сессии. Жизненный цикл объекта начинается при регистрации его в сессии и заканчивается при удалении. Объекты онтологий после регистрации помещаются в хранилище. Для управления состоянием сеансов и подписок применимы операции ACTIVE и WAIT . Использование нескольких сеансов с различными наборами подписок позволяет организовать группы подписок и активировать часть подписок при определенных условиях, останавливая другие, и наоборот.

Состояние сессии определяет состояние всех сеансов и подписок (см. таблицу). Выделим три способа использования нескольких сессий: 1) активация-ожидание, 2) активация-завершение, 3) смешанный. При способе 1 неиспользуемые сессии переводятся в состояние ожидания. При способе 2 сессия завершается после работы с ней. Способ 3 комбинирует два предыдущих. Например, агент использует часть сессий с постоянным набором сеансов и часть создает для разовых взаимодействий с ИП.

Рис. 2. Состояние объектов сессии

Операции управления объектами

Регистрация и удаление объекта из сессии; объекты онтологии помещаются или удаляются из хранилища

REG ( 5 , x ) =

( P5 и { x }, Qs, Ds ), если x e Pu x 4 P5 ( Ps , Qs и { x }, Ds), если x e Qu x 4 Qs ( P5 , Qs , Ds и { x }), если x e Ou x 4 Ds

DEL ( s , x ) = •

( Ps \ { x } , Qs , Ds ), если x e Ps ( Ps, Qs \{ x }, Ds), если x e Q 1 Ps , Qs , Ds \ { x }) , если x e Ds

Активация сессии, сеанса или подписки. Активация сессии приводит к активации всех сеансов в сессии. Активация сеанса приводит к активации подписок связанных с сеансом

ACTIVE ( 5 ) ^ ACTIVE ( 5 , p ), для V p е P5

ACTIVE{s,x) = -

\Ps = {Pw\{x}c{Pac{x}},Qs,Ds)^ ACTIVE(s, q) для Vqe Qx, если xe Ps (Ps,Qs={QnA{x}c{Qac{x}},Ds), _ еслихе Q

Перевод в состояние ожидание сессии, сеанса или подписки. Переход сессии переводит в состояние ожидания все сеансы и подписки. Переход сеанса переводит все подписки в состояние ожидания

WAIT ( 5 ) ^ WAIT ( 5 , p ), для V p е Pa

WAIT(s,x) = -

' (Ps = {Pa\{x}c{P„c{x}},Qs,Ds^ WAIT(s,q) для ^q g Qx, если x g Ps (Ps, Qs = {6«\ M}u {S„ u to L ecnu XG Q,

РАЗРАБОТКА АГЕНТА НА УРОВНЕ СЕССИИ

На основе модели параллельных сеансов предложена следующая схема разработки агента (рис. 3).

Рис. 3. Схема разработки агента

Шаг 1. Создание сессии s , сеансов, классов и подготовка сессии к работе операцией REG ( s , x ). Если в сессии нет сеансов, то невозможно взаимодействовать с ИП. При отсутствии классов и свойств нельзя создавать индивидов и устанавливать связи.

Шаг 2. Использование а) операций для управления состоянием ( ACTIVE ( s , x ), WAIT ( s , x )), работы с локальными данными, б) операций для взаимодействия с ИП. Операции для работы с локальными данными и взаимодействия зависят от реализации в инструментарии.

Шаг 3. Завершение сессии: перевод сессии в состояние ожидания и удаление всех зарегистрированных объектов и сущностей онтологии (операции WAIT ( s ) и DEL ( s , x )).

На примере «умного дома» (см. рис. 1) рассмотрим использования сессии (см. пример ниже). В строках 1 и 2 создаются сессия, сеансы и классы. В строке 3 объекты регистрируются в сессии. В строках 4–6 создаются и регистриру- ются подписки. Строки 7–11 описывают логику управления состоянием сеансов в зависимости от местонахождения. Если территория «умного дома» покинута, то сессия останавливается, и из нее удаляются все объекты (строки 12–13).

Пример построения агента

• 1.    Создать сессию, сеансы: s , p ₁, p ₂

• 2.    Создать класс телефона и электронного письма: t , e

• 3.    Зарегистрировать объекты: REG ( s , p ), REG ( s , p ), REG ( 5 , t ), REG ( 5 , e )

• 4.    Создать подписки для звонков и писем сеанса p ₁: a_t , a_e

• 5.    Создать подписку для звонков сеанса p ₂: b_t

• 6.    Зарегистрировать подписки: REG ( s , a ); REG ( s , a );

• 7.    Пока В_Умном_Доме () = «Да»

• 8.    Если (В_Доме () = «Да» И p. е P ) { ACTIVE ( 5 , p ,); }

• 9.    Если (В_Доме () = «Да» И p 2 е P" ) { ACTIVE ( 5 , p 2 ); }

• 10.    Если (Снаружи () = «Да» И p 1 е P ) {WAIT ( 5 , p 1 ); }

• 11.    Конец

• 12.    Остановить сессию WAIT ( 5 )

• 13.    Завершить 5 // DEL ( 5 , x )

REG ( s , b_t )                                 ^{t            e}

ЗАКЛЮЧЕНИЕ

Предложенная модель позволяет агенту использовать несколько сеансов в одной сессии, управлять объектами в сессии и предоставляет локальное хранилище, разделенное между сеансами сессии. Хранилище синхронизируется при помощи подписок. Подписки можно разбивать на группы и управлять их состоянием. В результате агент имеет возможность: а) работать с параллельными сеансами, б) управлять состоянием сеансов и подписок, в) объединять данные различных ИП, г) синхронизировать локальное хранилище. Модель используется в инструментарии SmartSlog, что позволяет работать с объединенной и поддерживаемой в актуальном состоянии информацией об объектах предметной области разных ИП.

* Работа выполнена при поддержке Программы стратегического развития ПетрГУ в рамках реализации комплекса мероприятий по развитию научно-исследовательской деятельности на 2012–2016 гг.