Источникs: http://www.madkit.org/


Аннотация.

В данной статье описывается многоагентная платформа MadKit (multi-agent development kit - средство разработки мультиагентов). MadKit основана на организационной модели, которая использует понятия групп и ролей для того, чтобы агенты могли управлять различными агентными моделями и многоагентными системами в то же время, имея глобальную структуру.
Архитектура MadKit основана на очень маленьком агенте ядра. Основные сервисы, такие как распределенная передача сообщений, миграция или мониторинг – обеспечены агентами платформы для максимальной гибкости. Компонентная интерфейсная модель позволяет использовать вариации внешнего вида платформы и агентов.
В статье объясняются некоторые последствия архитектуры и описывается мотивация для проектирования MadKit: интеграция разнородных приложений агента, многократное использование структурных шаблонов для социальных агентов и многосторонность прикладной платформы. На сегодняшний день, краткое изложение делается в некоторых MadKit-основанных приложениях.

1 Введение
1.1 Проблема разнородности

Главная особенность агентных исследований и приложений - высокая разнородность.
Под разнородностью подразумевается: разнородность модели агента, которая характерна для построения и описания агентов различными моделями и с различным уровнем формализма; языковая разнородность - агенты, использующие различные типы коммуникаций и схемы взаимодействия, и, наконец, разнородность в применении, поскольку мультиагентные системы используются с различными целями и применяются во многих областях.
Множество успешных теорий были предложены в различных областях исследования мультиагентных систем: интерфейсные агенты [8], мобильные агенты [7], агенты информационного поиска [11] и т.д.
Возможность использовать это разнообразие подходов одновременно является важной для проектирования сложных системы, сохраняя управляемую разнородность. Таким образом, актуальный вопрос состоит в том, как создать концептуальные модели и инструментальные средства программного обеспечения, чтобы облегчить интеграцию.
Взаимодействия в агентных системах должны быть предусмотрены на уровне агентов. Существующие способности механизмов к взаимодействию в программировании (CORBA, XML...) интересны для основ, которые они обеспечивают, но не являются универсальным ответом на наш вопрос. По крайней мере, отношения между основной платформой, лежащей в основе способности к взаимодействию, и агентным слоем являются ясно определенными и идентифицированными.

1.2 MadKit как мульти многоагентная система

Область платформы агента взята в качестве примера, но то же самое разнообразие подходов существует в пределах формализма агента, коммуникационных моделях и архитектуре.
Была спроектирована модель, названная AALAADIN, которая структурирует мультиагентные системы, и создана платформа, основанная на этой модели. Сама платформа была реализована, чтобы в полной мере воспользоваться моделью. В этой статье особенно сосредоточено внимание на платформе MADKIT. Структурная модель на уровне мультиагентных систем может ослабить интеграцию разнообразия агента в платформе, следовательно, его квалификация “много систем мультиагента”.
Средство разработки MADKIT был мотивирован потребностью обеспечить генетическую, настраиваемую и масштабируемую платформу агента. Цель создания основного слоя для различных моделей агента была важна, так же как создание основных услуг, которые являются полностью расширяемыми и заменимыми.
В разделе 3 кратко описывается концептуальная модель AALAADIN. Раздел 3 описывает архитектуру платформы: понятие “микроядра агента”, каким образом системные сервисы обеспечиваются агентами и краткий обзор модели интерфейса агента. Раздел 4 представляет некоторые эксперименты и системы, построенные с помощью MADKIT. Раздел 5 кратко описывает будущую работу и выводы.

2 Модель агент/группа/роль

Архитектура платформы MADKIT основана на AGR (agent/group/role - агент/группа/роль) модели, развитой в контексте проекта AALAADIN. И реализация, и использование MADKIT предназначены для управления этой моделью.
Рассмотрим организационные понятия, такие как группы, роли, структуры, зависимости, и т.д., поскольку граждане первого класса могли бы быть ключевым вопросом для строительства крупномасштабных, гетерогенных систем.
С этой точки зрения, организация рассматривается как структура для деятельности и взаимодействия через определение групп, ролей и их отношений. Организация расценена как структурные отношения между коллективами агентов. Таким образом, организация может быть описана исключительно на основе ее структуры (т.е. способом, которым группы и роли устроены для сформирования целого), не будучи обеспокоенным способом, которым фактически ведут себя агенты. Мультиагентные системы будут проанализированы с "внешней стороны", как ряд способов взаимодействия. Определенная архитектура агентов преднамеренно не проадресована.
Модель AALAADIN основана на трех основных понятиях: агент, группа и роль.
Рисунок 1 представляет диаграмму этой модели.


Рис. 1 – Модель ядра

2.1 Агент

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

2.2 Группа

Группы определены как атомарные наборы скопления агента. Каждый агент - часть одной или более групп. В ее наиболее канонической форме, группа - только способ пометить ряд агентов. В более развитой форме, в соединении с ролевым определением, группа может представить любую обычную мультиагентную систему. Агент может быть членом n групп в одно и то же время. Важный пункт групп AALAADIN - то, что они могут свободно пересекаться. Группа может быть основана любым агентом.

2.3 Роль

Роль - абстрактное представление функции агента, обслуживания или идентификации в пределах группы. Каждый агент может исполнять много ролей, и каждая роль, обработанная агентом, является локальной для группы. Управление ролью в группе должен требовать агент-кандидат, и он будет не обязательно награжден за её выполнение. Таким образом, абстрактные коммуникационные схемы определены от ролей.
Модель не статическое описание организации агента. Она также позволяет определять правила, установить часть динамики организации агента. Особый механизм для ролевого доступа в пределах группы не определен (систематическое принятие или отказ, входная плата, обусловленная навыками или диалогом входной платы, отношением к группе метрики...).

2.4 Обсуждение

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

3 Архитектура

Платформа MADKIT построена вокруг этой модели. В дополнение к трем основным понятиям платформа добавляет три принципа разработки:
– Микроядерная архитектура
– Агентификация услуг
– Графическая компонентная модель
MadKit является набором пакетов, классов Java, которые реализует ядро агента, различные библиотеки сообщений, маршрутов и агентов. Она также включает в себя графическую среду разработки и стандартные модели агента.


Рис.2 – Диаграмма архитектуры MadKit

Основная философия архитектуры MADKIT должна использоваться везде, где возможно использовать платформу для ее собственного управления: любая служба, которая гарантирует обработку микроядро агентами. Таким образом, платформа не является агентной платформой в классическом смысле. Уменьшенный размер микроядра, объединенного с принципом модульных служб, которыми управляют агенты, включает ряд разнообразных масштабируемых платформ и конструкции библиотек специализированных моделей агента.
Группы агента были предложены в другой архитектуре, такой как [1], хотя механизм является специально определенным для мобильных агентов и испытывает недостаток возможности обработать многократные группы и многократные роли в универсальной модели, как это реализовано в описанной ранее модели.

3.1 Микроядро агента

Микроядро MADKIT - маленькое (меньше чем 40 Кбайт) и оптимизированное ядро агента.
Термин "микроядро" является намеренно используемым в качестве ссылки на роль микроядра в домене разработки ОС [9]. Можно было непосредственно преобразовать их в девиз: «слияние многих ключевых средств позволяют эффективное развертывание инструментариев агента».
Ядро MADKIT только обрабатывает следующие задачи:
Контроль локальных групп и ролей (Менеджер групп/ролей). Большинство возможностей функциональной совместимости и расширяемости в MADKIT полагается на организационный уровень, т.к. необходимо, чтобы группа и роль были обработаны на самом низком уровне в платформе, чтобы обеспечить эту функциональность для любого агента, микроядро ответственно за поддержание корректной информации о членах группы и обработанных ролях. Оно также проверяет, корректны ли просьбы, обращенные к группам и ролевым структурам (то есть: оценка или делегирование оценки ролевых функций).
Управление жизненным циклом агента (Синхронизирующее устройство). Ядро также запускает (и, в конечном счете, уничтожает) агенты, и сохраняет таблицы и ссылки экземпляров агента, это - единственный модуль в MADKIT, которому принадлежат прямые ссылки на фактические агенты. Оно также обрабатывает персональные данные агента и присваивает ему глобальный уникальный идентификатор (адрес ядра плюс идентификатор агента на локальном ядре) и адрес агента после создания. Этот идентификатор может быть пересмотрен для принятия стандартизированной схемы именования агента.
Локальная передача сообщений (Обмен сообщениями). Ядро управляет маршрутизацией и распределением сообщений между локальными агентами. Основной механизм полагается на реализацию копии записи, чтобы избежать ненужных операций.
Само ядро «находится» в оболочке специального агента, KernelAgent (агент ядра), который создается при начальной загрузке. Он разрешает управление и контроль ядра в пределах модели агента.

Рычаги ядра

Само ядро полностью расширяемо через “рычаги ядра”. Любой названный агент (то есть агент, которому позволили быть элементом системной группы) может запросить у агента ядра подписку на рычаги ядра.
Рычаги - универсальная схема подписи-публикации, позволяющая расширение базового поведения платформы. Каждая базовая функция в ядре (добавление агента к группе, запуск агента, отправление сообщения) реализует эти механизмы.
Контролирующий рычаг. Никакое количество агентов не может подписаться на контролирующий рычаг. В этом типе рычага, вызов операции ядра заставляет KernelAgent отправить сообщение агентам, которые запрашивались контролирующим рычагом на этой операции с параметрами – содержимым сообщения. Например, это - то, как записаны агенты, которые контролируют совокупность или организацию в платформе.
Рычаги перехватчика. Эти рычаги подобны предыдущему типу, но только один агент может содержать рычаг перехватчик при передаче операций ядру. Кроме того, рычаг перехватчика предотвращает выполнение текущей операции ядра. Особенно полезно записывать распределенные обменивающиеся сообщениями агенты, групповые синхронизаторы, управление безопасностью в группах и т.д. изменяя поведение основных операций. Сокращенное количество вызовов ядра и простая базовая модель помогает модификации этих вызовов при сохранении их семантики.
Когда осуществлен вызов ядра, связанный с рычагом, информация передается KernelAgent, который осуществляет передачу сообщения.

Операции ядра

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

3.2 Агенты

Генетический агент – MADKIT – класс,  определяющий основной жизненный цикл (что делать после активации, выполнения и завершения).
- Контроль и жизненный цикл. Главный класс агента в MADKIT определяет примитивы, связанные с передачей сообщения, групповым и ролевым управлением, но не осуществляет определенную политику выполнения. Подкласс добавляет поддержку параллельного выполнения, которое является естественной моделью для крупнозернистого совместного или познавательного агента. Дополнительные подклассы осуществляют синхронное выполнение через внешнего планировщика, который фокусируется на реактивной или гибридной архитектуре: много мелкозернистых агентов.
- Коммуникация достигнута посредством асинхронной передачи сообщения. Для непосредственной посылки сообщения другому агенту, определенному его AgentAddress или высокоуровневой версией, когда выполняется посылка или вещание одному или всем агентам, которые выполняют данную роль в определенной группе.
- Группа, ролевые действия и запросы определены в предельно допустимой концентрации. Разработчик агента не ограничивается в определении поведения агента, но организационную модель должен соблюдать.

Посылка сообщений

Сообщения в платформе MADKIT наследуются от универсального класса сообщения. Таким образом, определенные сообщения могут быть определены для внутригрупповой передачи и позволяют группе иметь свои определенные коммуникационные атрибуты. Получатели и отправители сообщений идентифицированы их AgentAddress. MadKit не определяет механизм взаимодействия, который может быть определен на оперативной основе, или создан в определенной библиотеке модели агента.

Модели агента

Несколько особенных библиотек агента были созданы выше этой инфраструктуры, особенно:

3.3 Агентификация служб

В отличие от других архитектур, MADKIT использует агенты, чтобы достигнуть таких целей как распределенная передача сообщений, управление миграцией, динамическая безопасность и другие аспекты управления системой. Эти различные службы представлены в платформе как роли в некоторых определенных группах, определенных в абстрактной организационной структуре, что позволяет достигнуть очень высокого уровеня настройки, поскольку эти агенты-службы могут быть заменены без препятствий.
Например, внешние разработчики создали новый групповой агент синхронизатора, который использует совместно используемый каталог JNDI для поддержания информации о группе через распределенное ядро вместо того, чтобы использовать реализованную в MadKit систему. Их агент использует некоторые рычаги в ядре, чтобы достигнуть своих целей и заменить обеспеченного группового агента синхронизатора, запрашивая ту же самую роль в системной группе. Другие агенты не заметят изменения.
Ролевой принцип делегации имеет другой интересный эффект для обеспечения легкого масштабирования. Агент может выполнять несколько ролей в начале существования группы,  поскольку группа растет, запускает другие агенты, делегировать им некоторые из этих ролей.


Рис. 3 – Инструменты SEDIT, работающие как агенты в MADKIT

Передача и распределение

Поскольку обмен сообщениями, так же как группы и ролевое управление используют идентификатор AgentAddress (адрес агента), и поскольку этот идентификатор уникален и для удаленных ядер, агенты MADKIT могут быть прозрачно распределены, не изменяя ничего в коде агента. Группы могут размножаться через различные ядра, и агенты обычно не замечают этого.
Распределение в платформе агента полагается на две роли в системной группе:
– Агент коммуникатора используется микроядром, чтобы направить нелокальные сообщения к другим агентам коммуникатора на удаленных платформах, который вводит локальные сообщения в своем ядре (см. рисунок 4),
– Групповые агенты синхронизатора разрешают группам и ролям, которые будут распределены среди ядер, посылкой групп и ролей изменять другие синхронизаторы, которые поочередно вводят свою информацию в свое локальное ядро. Важно, что эти группы синхронизаторов сами пользуются своим собственным распределением на группы для облегчения управления распределенными группами.
Так как коммуникационные механизмы созданы как обычные агенты в платформе, передача и миграция могли быть адаптированы в соответствии с определенными требованиями платформы путем изменения коммуникационных агентов, например, в автономном режиме для переносных компьютаров.
Платформа MADKIT может работать в полном локальном режиме только без запуска коммуникационных агентов.
Эти службы не обязательно обрабатываются только одним агентом. Например, агент коммуникатора может быть представителем группы, объединяющей агенты, специализированные на сокетах или связи CORBA, и делегировать сообщение к соответствующему агенту.


Рис. 4 – Коммуникационные агенты

3.4 Компонентная графическая архитектура

Графическая модель MADKIT основана на независимых графических компонентах, использующих Бобовую спецификацию Java в стандартной версии.
Для каждого агента определяется свой собственный графический интерфейс в каждом аспекте (рендеринг, обработка событий, действия...). Интерфейс агента может быть простой меткой, сложной конструкцией, основанной на многократных виджетах или наследуемом бобовом программном модуле.
“Графическая оболочка” запускает ядро и установливает интерфейсы для различных агентов и управляет ими в глобальном GUI (например: каждый агент имеет свое собственное окно, или отображен в глобальном рабочем листе, или объединен с другим интерфейсом агента...).
Поскольку графическая оболочка - классический программный модуль, она может быть перенесена в агент для максимальной гибкости, позволяя управление другими интерфейсами агента регулярным агентом MADKIT, который может быть частью любого сценария взаимодействия.

3.5 Последствия и обсуждение

Соединение микроядра агента и разъединенного GUI агента, так же как модульного набора служб агента, позволяет добиться важных настроек платформы MADKIT (рисунок 5). Например, были разработаны следующие "варианты" платформы:
– Полная графическая среда для разработки и тестирования мультиагентных систем, названная "G-Box". Она делает возможным графическое управление жизненным циклом агента (запуск, завершение, пауза), динамической загрузкой агентов и использует самоанализ в коде агента для обнаружения времени выполнения ролей и групп, ссылок на другие агенты, и предлагает непосредственное управление этими структурами.
– Режим только для текста, запускает только микроядро без создания графических интерфейсов при запуске агентов. Эта платформа полезна для сохранения небольшого “agent daemon” на машине, предоставляющих услуги посредничества, именования или маршрутизации для других машин.
– Оболочка апплета, которая переносит микроядро агента с некоторыми агентами-приложениями, и выполняется в удаленном браузере.
- "Классическое" приложение, которое встраивает ядро MadKit и размещает агенты для обработки совместных / динамических аспектов. Например, так было реализовано приложение Wex, описанное ниже.
– Экспериментальная версия MADKIT 3.5, адаптированная для Palm Pilot. Ядро специальным образом настраивают, чтобы только использовать набор классов, содержащихся в Java Platform Micro Edition [6]. Специальный коммуникатор обрабатывает инфракрасный обмен сообщениями.


Рис. 5 – MADKIT, работающий в апплете, G-Box и консольных режимах.



Рис. 6 – Упрощенный пример ядра MadKit и двух агентов на устройстве Palm

4 Приложения

MadKit использовался в различных исследовательских группах для почти двухлетнего проекта, касающихся широкого диапазона приложений от моделирования гибридной архитектуры для управления подводных роботов до оценки социальных сетей или исследованию управления мультиагентами на производственной линии.
Например, Wex, разработанный Euriware S.A., является сложным приложением MADKIT для управления знаниями. Оно объединяет информацию от различных неоднородных источников данных (базы данных, инструментов поддержки, поисковых систем, текущей страницы, просмотренной пользователем и проанализированной...). Пользователи могут поддерживать совместное использованные онтологии на своем домене. Агенты были реализованы так, чтобы инкапсулировать различные механизмы для получения и преобразования информации.
Абстрактная организационная структура и различные агенты были определены так, что могут быть включены для адаптации платформы под определенные потребности клиента.

5 Заключение и планы на будущее

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

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

Литература

  1. Joachim Baumann and Nikolaos Radouniklis. Agent groups in mobile agent systems. In IFIP WG 6.1, International Conference on Distributed Applications and Interoperable Systems (DAIS 97), 1997.

  2. Per Bothner. Functional scripting languages for the jvm. In 3rd Annual European Conference on Java and Object Orientation, Arhus, Denmark, 1999.

  3. Jacques Ferber and Olivier Gutknecht. A meta-model for the analysis and design of organizations in multi-agent systems. In Third International Conference on Multi-Agent Systems (ICMAS ’98) Proceedings, pages 128–135. IEEE Computer Society, 1998.

  4. Jacques Ferber and Olivier Gutknecht. Operational semantics of a role-based agent architecture. In Proceedings of the 6th Int. Workshop on Agent Theories, Architectures and Languages. Springer-Verlag, 1999.

  5. Ernest J. Friedman-Hill. Jess, The Java Expert System Shell. Distributed Computing Systems, Sandia National Laboratories, Livermore, CA, 2000.

  6. Sun Microsystems Inc. The k virtual machine white paper. Technical report, 2550, Garcia Avenue, Mountain View CA 94043, 1997.

  7. Frederick C. Knabe. An overview of mobile agent programming. In Proceedings of the 5th LOMAPS Workshop on Analysis and Verification of Multiple-Agent Languages, Stockholm, Sweden, June 1996.

  8. Brenda Laurel. Interface agents : Metaphors with character. In Brenda Laurel, editor, The Art of Human Computer Interface Design, pages 355–365. Addison-Wesley, 1990.

  9. Richard Rashid, Robert Baron, Alessandro Forin, David Golub, Michael Jones, Daniel Julin, Douglas Orr, and Richard Sanzi. Mach : A foundation for Open Systems. In Proceedings of the 34th Computer Society Ithe Second Workshop on Workstation Operating Systems(WWOS2), September 1989.

  10. Mitchel Resnick. Turtles, Termites, and Traffic Jams : Explorations in Massively Parallel Microworlds. MIT Press, 1994.

  11. E. M. Voorhees. Software agents for information retrieval. In O. Etzioni, editor, Software Agents — Papers from the 1994 Spring Symposium (Technical Report SS–94–03), pages 126–129, March 1994.