Архитектура и реализация JADE

Уровень публикуемого материала
	Уровень публикуемого материала
Рекомендуемый уровень знаний читателя в предметной области :	Средний
Обсуждение:	Обсудить

Публикация
	Публикация
Автор:	Гореликов М.В., Иванов А.М. МГТУ им. Н.Э. Баумана, каф. ИУ-3
Тип публикации:	Обзор
Оригинал:	AgentLab

Материал из Semantic Future

Перейти к: навигация, поиск

Содержание

1 Введение
2 Структуры компонент-соединитель
3 Модульные структуры
4 Структуры распределения
- 4.1 Размещение
- 4.2 Структура каталогов исходного кода
5 Источники информации

Введение

В данном документе проанализирована архитектура агентной платформы JADE (Java Development Environment) согласно методологии архитектурного анализа из [5].

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

Агент – это программа обладающая независимым поведением и способная обмениваться сообщениями с другими агентами. Агент обладает набором поведений (функций, методов), для отработки заданной реакции на определенные события.

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

Задачи агентной платформы заключаются в следующем:

управление жизненными циклами агентов. эффективная передача сообщений между агентами. Архитектура агентной платформы во многом определяется стандартом FIPA [1].

Далее мы рассмотрим архитектурные структуры трех типов согласно методологии из [5]:

Структуры компонент-соединитель – анализ работы JADE в период исполнения, оценка производительности и масштабируемости. Модульные структуры – анализ конструкций в исходном коде, оценка расширяемости JADE. Структуры распределения – анализ файловой организации JADE.

Структуры компонент-соединитель

В этом разделе рассмотрены структуры программы, возникающие в момент ее исполнения: процессы параллелизм, потоки данных и их хранилища. Анализ данных структур позволяет выявить и оценить характеристики поведения программы.

Агент

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

Такой подход позволяет гибко конфигурировать политики выделения потоков агентам:

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

Рис.1. Жизненный цикл агента в соответствии со спецификацией FIPA

На рис.1 представлен жизненный цикл агента согласно спецификации FIPA. Агент JADE может находиться в одном из состояний, согласно жизненному циклу агентной платформы:

AP_INITIATED – агент создан, но пока не зарегистрирован в AMS, поэтому он не имеет ни имени, ни адреса и не может обмениваться сообщениями с другими агентами.
AP_ACTIVE – агент зарегистрирован в AMS, имеет постоянное имя и адрес и может использовать все различные особенности JADE.
AP_SUSPENDED – агент в текущий момент времени остановлен. Его внутренний поток приостановлен и не выполняется никакого поведения агента. Все входящие сообщения буферизуются.
AP_WAITING – агент блокирован (в ожидании). Его внутренний поток бездействует, и он пробудится при выполнении некоторого условия (например, поступление сообщения).
AP_DELETED – агент явно мертв. Внутренний поток завершил его выполнение, и агент больше не зарегистрирован в AMS.
AP_TRANSIT – мобильный агент перемещается к новому местоположению. Система продолжает буферизовать сообщения, которые будут посланы ему, когда он прибудет в новое местоположение.
AP_COPY – создание копии агента.
AP_GONE – мобильный агент переместился к новому местоположению, и имеет устойчивое состояние.

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

Поведения

Для отработки реакции на события агент имеет поведения. Агент может отрабатывать несколько поведений одновременно. Обработка поведений происходит не по приоритетам (как java потоки), а совместно. Очередность исполнения отдельных простых поведений не гарантируется, для этого нужно использовать поведения специальных типов или синхронизацию.

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

Рис.2. Отработка поведений

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

AMS (Agent Management System) – данный агент управляет всей платформой. Этот агент необходим для взаимодействия агентов платформы, он обеспечивает доступ агентов к сервису белых страниц платформы и управляет их жизненным циклом. AMS обеспечивает различные операции платформы, такие как: создание и удаление агентов, удаление контейнеров, завершение работы платформы. Каждому агенту необходимо зарегистрироваться в AMS, для получения персонального идентификатора AID. Запуск агента AMS происходит внутри главного контейнера платформы, но может существовать в любом контейнере. Агент, совершающий действия связанные с функционированием платформы, должен вначале запросить подтверждение у агента AMS. DF (Directory Facilitator) – агент обеспечивает регистрацию сервисов и поиск агента по сервису в желтых страницах. Агенты платформы могут подписываться у DF-агента на получение информации о регистрации необходимого сервиса.

Рис. 3. Сервис желтых страниц

Рис.4. Отношения между основными архитектурными элементами

На рисунке выше показаны основные архитектурные элементы платформы JADE. Платформа JADE состоит из системы контейнеров, распределенных в сети.

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

Главный контейнер содержит таблицу контейнеров (CT-container table) – в данной таблице хранятся ссылки на объекты и транспортные адреса всех контейнеров, входящих в состав платформы.

Внутри каждого контейнера содержится:

GADT (global agent descriptor table) – это регистр агентов платформы, в котором хранятся их текущий статус и местоположение. LADT (local agent descriptor table) – тоже самое что и GADT, но для агентов контейнера.

Сервис обмена сообщениями

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

Рис.5. Диаграмма асинхронного обмена сообщениями

В связи с тем, что агенты, обменивающиеся сообщениями, могут находиться как в одном, так и в разных контейнерах JADE использует два типа протокола: MTP (message transport protocol) и IMTP (internal message transport protocol).

В том случае если агенты находятся в разных контейнерах, используется RMI(Java Remote Method Invocation).

В случае межплатформенного сценария взаимодействие осуществляется по ACC (Agent Communication Channel). Контейнеры могут быть запущены с различными типами MTP, при этом ACC должен обеспечивать взаимодействие между ними.

В JADE доступны различные типы протоколов MTP, такие как:

CORBA IIOP MTP, основанный на стандартном Sun ORB;
CORBA IIOP MTP, основанный на ORBACUS и HTTP.

Рис. 6. Компоненты сервиса обмены сообщениями

Анализ атрибутов качества

Производительность

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

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

Однако, сама по себе инфраструктура поведений вносит дополнительные вычислительные издержки. Особенно при однопоточном исполнении.

Также значительный издержки вносит система передачи сообщений (по-сравнению с простым обменом сообщениями в Actor-Model каркасах). Как будет показано ниже, она чрезвычайно гибкая и позволяет стандартными средствами передавать сложные типы данных вроде высказываний логики 1-го порядка. Но все это за счет производительности.

В общем, практика показывает, что на одном средней руки ПК одновременный запуск более 50-100 простых взаимодействующих агентов вызывает заметное падение производительности.

Масштабируемость

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

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

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

Готовность

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

Контролепригодность

Для обеспечения контроля могут быть использованы специальные системные агенты:

Sniffer Agent – отслеживание потока сообщений между агентами; Dummy Agent – отправка сообщения агенту; Introspector Agent – мониторинг жизненного цикла агента; Remote Monitoring Agent – мониторинг платформы.

Интеграция со сторонними системами

Платформа поддерживает интеграцию со сторонними системами:

внедрение агентов в апплет при разработке web-приложений;
интеграция с системами бизнес правил для создания интеллектуальных систем (Jess,Drools);
интеграция с машинами вывода BDI, AgentSpeak, Prolog и др.;
интеграция с другими агентными платформами, поддерживающими стандарт FIPA.