Архитектура взаимодействия системы агентов

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

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

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

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

Иерархическая архитектура взаимодействия агентов. Рассмотрим простейший вариант иерархической организации взаимодействия агентов, который предполагает использование одного агента «метауровня», осуществляющего координацию распределенного решения задач (и) агентами.

Агент, осуществляющий координацию, может быть привязан к конкретному серверу, тогда он называется «местом встречи агентов». Место встречи агентов (Agent Meeting Place, AMP) — агент, играющий роль брокера между агентами, запрашивающими некоторые ресурсы, которыми обладают другие агенты, и теми агентами, которые эти ресурсы могут предоставить. Архитектура АМР — архитектура обычного агента, дополненная некоторыми вспомогательными компонентами, наличие которых обусловлено ролью этого агента как координатора взаимодействия других агентов. Эти вспомогательные компоненты должны, с одной стороны, содержать унифицированное описание множества доступных через АМР агентов и их возможностей (ресурсов, функций и нр.), а с другой — организовать к ним унифицированный доступ. Это обеспечивается следующими компонентами АМР.

• 1. Объекты базовых сервисов, в частности эго может быть удаленный вызов объектов, упорядочение объектов, дублирование объектов и другие базовые возможности, которые обычно поддерживаются той или иной платформой открытой распределенной обработки, например OMG/CORBA.
• 2. Связные порты, ответственные за прием и отправку агентов в АМР с помощью соответствующих протоколов.
• 3. Компонента установления подлинности агента, но имени (опознание агента, «авторизация»).
• 4. Консьерж, выполняющий функции контроля полномочий поступающего агента, наличия на АМР запрашиваемого сервиса, помощь агенту в выборе дальнейшего маршрута перемещения и др.
• 5. Поверхностный маршрутизатор, выполняющий функции интерфейса между агентами и компонентами АМР, которые сами, но себе регистрируются в этом маршрутизаторе; он поддерживает ограниченный словарь для удовлетворения агентских запросов.
• 6. Лингвистический журнал, который представляет собой БД, помогающую агентам и АМР понимать друг друга в процессе коммуникаций. В нем регистрируются словари и языки, но не описания языков или смысл терминов, а лишь ссылки на них, г. е. журнал предоставляет информацию о том, что может быть понято в АМР.
• 7. Глубинный маршрутизатор, который ассистирует поверхностному при более специальных и сложных запросах.
• 8. Менеджер ресурсов, который регистрирует агентов на АМР и ассоциированные с ними ресурсы, а также управляет ресурсами АМР.
• 9. Среда исполнения агента, которая регистрируется в АМР и управляет доступом к компонентам агента; она интерпретирует сценарии, обеспечивает доступ к базовым возможностям и др.
• 10. Система доставки событий; источниками событий могут быть локальные средства, резидентные агенты АМР и др. Система регистрирует события и выполняет поиск агентов для соответствующего типа событий и сообщений.

В остальном архитектура координирующего агента аналогична архитектуре обычного агента.