Программные продукты и системы

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

Многоагентную платформу торговли в сети Интернет можно построить, интегрировав систему агентов в программную платформу электронного магазина, под которой будем понимать набор сервлетов (файлов, содержащих html-теги и java-код) и JSP-страниц (java server page), способных генерировать динамический контент сайта. Веб-сервер, на котором размещен интернет-магазин, способен стать местом дислокации базы платформы. База платформы – совокупность программного обеспечения, поддерживающего весь жизненный цикл агентов. На рисунке изображена архитектура многоагентной платформы торговой площадки.

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

После процедуры регистрации у посетителя появляется возможность делать заказы в интернет-магазине. Каждому зарегистрированному пользователю ресурса сопоставляется программный модуль агент-заказчик, представляющий его интересы. После авторизации клиента генерируется агент-заказчик клиента (имя агента соответствует полю login регистрационной формы). Роль агента-заказчика состоит в осуществлении проводок по реализации услуги, предлагаемой магазином. Агент принимает заказ и делает запись о нем в БД заказов, сообщает о сделке агенту-помощнику, который, в свою очередь, общаясь с агентом-хранителем БД, может информировать клиента о его предыдущих заказах. Агент-заказчик осуществляет информационный обмен с агентом-храни­телем БД заказов и без посредника. Если покупатель уверен в приобретении товара, агент-заказчик отсылает сообщение агенту-хранителю; из заголовка сообщения ясно, что необходимо сделать новую запись в БД. Содержимое новой записи соответствует телу сообщения агента-заказчика. Агент-заказчик создается всякий раз, когда авторизуется пользователь. По истечении сессии клиента он прекращает существование.

Для каждой платформы агент-хранитель БД создается лишь один раз. Только он имеет доступ к базе заказов через драйвер. Единичность агента на платформе объясняется тем, что в случае совместной работы нескольких подобных агентов с одной таблицей заказов (например, добавление новой записи) велика вероятность программного исключения. БД заказов географически может находиться где угодно. Контейнер же, в пределах которого действует агент-хранитель, необязательно должен располагаться на компьютере с установленным сервером БД, хотя исполнение функций агента-хранителя на компьютере посетителя интернет-магазина сокращает время транзакций и увеличивает скорость работы всего сервиса.

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

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

Агент-web-скребок (web-паук) – это агент, который собирает, фильтрует и агрегирует информацию определенного интернет-контента. В нашем случае подразумевается стоимость аналогов на товары и услуги, предлагаемые магазином. Конкурентное ценообразование, то есть выявление существующих на рынке цен на определенную категорию товара для установления соответствующих цен на собственную продукцию – не единственная функция агента. Web-скребок способен индексировать дружественные по тематике интернет-ресурсы и заносить их адреса в некоторую таблицу БД. Работоспособность уже имеющихся ссылок в таблице время от времени проверяется агентом. На основе информационного обмена с агентом-помощником пользователь интернет-магазина может воспользоваться услугами агента-web-скребка.

Агент-наблюдатель – это некоторого рода агент-осведомитель. Связь «агент–владелец платформы» у этого модуля прослеживается особенно четко. Все агенты платформы сообщают о своих действиях агенту-наблюдателю, который, в свою очередь, информирует владельца платформы обо всех переговорах, ведущихся агентами.

Жизненный цикл  любых агентов визуализируется с помощью специальной службы платформы – сервиса каталогов агентов. Сервис каталогов отображает не только тип агента, но и его контейнер в виде дерева. Контейнеры могут существовать на различных сетевых узлах. Главный контейнер должен располагаться на том же узле, где и база платформы. На главном контейнере постоянно создаются агенты-заказчики, агенты-помощни­ки покупателя и агент-наблюдатель. На второстепенных контейнерах могут существовать агент-хранитель БД заказов, агент-оценщик состояний заказов и агент-web-скребок.

Результаты изучения демонстрируют новый уровень возможности разработки многоагентной платформы для поддержки приложений электронной коммерции.

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

1. Безопасность проведения сделок в интернет-магазине, которая достигается за счет того, что любая информация о клиенте передается между агентами с помощью специального языка сообщений агентов Agent Communication Language (ACL). Язык ACL построен на основе технологии удаленного вызова методов Remote Method Invocation (RMI), при котором передача данных осуществляется не в текстовом виде, а посредством набора байтов. При этом исключается возможность использования перехваченных потоков информации.

2. Привлекательность интернет-ресурса, создаваемая благодаря использованию сервис-гида – агента-помощника покупателя.

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

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

Литература

1. Giovanni Caire. Programming Developing multi-agent applications with JADE. Tutorial for beginners / Caire Giovanni (TILAB, formerly CSELT). 2009. pp. 23.

2. Рассел С., Норвиг П. Искусственный интеллект: современный подход; пер. с англ. М.: Издат. дом «Вильямс», 2006. 2-е изд. 1408 с.