Под архитектурой системы понимается ее структура, то есть ее составляющие элементы, их внешние свойства и отношения-взаимосвязи между ними. Агент – это программа, обладающая независимым поведением и способная обмениваться сообщениями с другими агентами. Агент обладает набором поведений (функций, методов), для отработки заданной реакции на определенные события. Основной целью данной платформы является обеспечение существования и взаимодействия агентов.
Задачи агентной платформы заключаются в следующем:
• управление жизненными циклами агентов;
• эффективная передача сообщений между агентами.
Архитектура агентной платформы во многом определяется стандартом FIPA.
Выделяют следующие типы архитектурных структур:
• структуры компонент-соединитель – анализ работы JADE в период исполнения, оценка производительности и масштабируемости;
• модульные структуры – анализ конструкций в исходном коде, оценка расширяемости JADE;
• структуры распределения – анализ файловой организации JADE.
Remote management agent
Remote management agent (Рис.2.3) представляет собой графическую консоль для управления мультиагентным приложением. Позволяет создавать новые контейнеры, управлять агентами, создавать сообщения и запускать средства отладки.
Рис. 2.3 - Remote management agent
Dummy agent
Dummy agent (Рис. 2.4) является графической утилитой, которая позволяет посылать и получать сообщения от имени определенного агента, а также сохранять и загружать очередь его сообщений (отправленных и полученных).
Рис. 2.4 – Dummy agent
Sniffer agent
Sniffer agent (Рис. 2.5) – это графическая утилита для просмотра потока сообщений между избранными агентами. Представляет обмен сообщениями в виде диаграмм последовательностей. Позволяет сохранять/загружать поток сообщений между агентами, а также просматривать содержимое сообщений.
Рис.2.5 – Sniffer agent
Introspector agent
Introspector agent (Рис 2.6) – графическая утилита для просмотра внутреннего состояния агента. Позволяет контролировать жизненный цикл агента, просматривать очередь его сообщений, активные и выполненные поведения, а также запускать исполнение агента с задержками между операциями или по шагам. При этом «шагом» поведения агента считается исполнение метода action(), а не команда в коде языка Java.
Рис. 2.6 – Introspector agent
Log manager agent
Log Manager agent – графическая утилита для отображения лога сообщений в процессе работы агентного приложения (исследуйте самостоятельно)
DF GUI
DF GUI (Рисунок 2.7) – рафическая утилита для визуализации желтых страниц. Позволяет регистрировать и удалять сервисы агентов, а также осуществлять поиск сервисов.
Этот JADE-агент, предназначенный для установки коммуникаций с удаленными клиентами позволяет поддерживать 50 параллельных подключений. Каждое входящее сообщение парсится, проверяется его адресат по листингу агентных имен, и передается агенту в пункт назначения.
JADE предлагает графический интерфейс агента DF (Directory Facilitator). Он позволяет сотрудничать с другими DF-агентами и контролировать (регистрировать, модифицировать, искать агентов по их характеристикам) всю сеть объединения DF-агентов. Этот тип агентов предлагает сервис “yellow pаges” другим агентам. Они могут зарегистрировать свои услуги с помощью DF-агента или “попросить” его найти поддержку у других DF-агентов. Последние могут объединяться и создавать федерации агентов-фасилитаторов. Рис.2.7. показывает интерфейс таких агентов (добраться к немуможно через Tools агента AMSы).
Рис. 2.7 – DF GUI
Все JADE-инструменты, кроме Dummy-Агента, наследуют от jade.tools. Класс ToolAgent, который обеспечивает способность получить уведомления события по общепринятому пути. На Рис.2.8 – представлена UML диаграмма классов инструментов JADE.
Каждый инструмент является Агентом, который расширяет jade.core.Agent – основной Agent класс. Это дает некоторые важные особенности и упрощения:
1. Жизненный цикл инструмента JADE может управляться точно, как любой другой агент платформы.
2. Возможность запроса главного класса Агента может быть использована для взаимодействия между инструментом и AMS (Agent Message System), в частности для получения уведомлений событий платформы.
3. Несколько экземпляров одного и того же инструмента может сосуществовать на той же платформе и даже в том же контейнере.
Класс jade.tools.ToolNotifier, порождающий вспомогательных агентов, требуемых для продвижения событий отправки-принятия и внутренних для агента событий к заинтересованным агентам, - является сам ToolAgent. Таким образом можно обнаружить момент, когда целевой агент или агент наблюдателя уничтожается. Класс ToolNotifier жестко связан с ENS (EVENT NOTIFICATION SERVICE) и не рекомендован для прямого вызова программистами.
Рис. 2.8 – Диаграмма классов JADE-инструментов
Рис. 2.9 – Создание нового агента
ЗАДАНИЕ К ЛР№2
1. Создайте несколько агентов (Рис. 2.9), щелкнув правой кнопкой на MainContainer. (В пределах одной платформы требуются только имена агентов, например, MyAgentA)
2. Создайте также Dummy Agent. (при работе у него появляются два сообщения – синее и красное: синее –запрос, красное- ответ. И последнее сообщение находится сверху).
3. Отправьте несколько сообщений друг другу (с контентом ping и другим содержимым.)
4. Пронаблюдайте результат, в том числе в сниффере.
5. Сделайте выводы.
6. При защите ЛР предполагаются вопросы по теор. части из лекций и данной работы.
Лабораторная работа №3а. Типы поведения агентов JADE. Этапы разработки мультиагентной системы
Цель: изучить виды поведения агентов на примере мультиагентной системы, построенной по принципу pub/sub.
ПРИМЕР "Торговля книгами "
Для иллюстрации пошаговой разработки агентного приложения на JADE рассмотрим пример "Торговля книгами"[1]. Сценарий, рассматриваемый в этом примере, включает агентов с "поведением", продающих книги и других агентов, покупающих книги от имени своих пользователей.
Каждый агент покупателя получает название книги для покупки ("Какая-то книга") в качестве аргумента командной строки и периодически запрашивает всех известных агентов торговца о наличии предложения этой книги. Как только предложение получено, агент покупателя оповещается об этом и выпускает заявку на поставку. Если более одного агента-торговца готовы обеспечить предложение, агент покупателя принимает лучший (меньшая цена). Купив заказанную книгу, агент покупателя заканчивает свою работу.
Каждый агент торговца имеет минимальный GUI, с помощью которого пользователь может вставить новые заглавия (и желательную цену) в местный каталог книг для продажи. Агенты продавцы находятся в постоянном ожидании запросов от агентов покупателей. Когда появляется заявка обеспечить предложение для книги, "торговцы" проверяют, есть ли запрошенная книга в их каталоге, и если да, то выдают положительный ответ и цену. Иначе они отказывают. Когда "торговец" получает заявку на поставку, он обслуживают эту заявку и удаляет запрошенную книгу из своего каталога.
Все проблемы, связанные с электронной оплатой, не рассматриваются в этом примере и не принимаются во внимание.
|
bookTrading. Структура программы показана на рис.3.1.
