<< Предыдущая

стр. 21
(из 26 стр.)

ОГЛАВЛЕНИЕ

Следующая >>

+ + +
+
Слежение
за окружением
+ + +

+

Способность использования абстракций
+ + +
+
Способность использования предметных знаний
+ +

Возможность адаптивного поведения для достижения целей
+
+
Обучение из окружения
+
+
Толерантность к ошибкам и/или неверным входным сигналам Real-time исполнение
+

+

ЕЯ-взаимодействие
+


Как следует из приведенной таблицы, собственно целесообразное поведение появляется только на уровне интеллектуальных агентов [Пономарева и др., 1999; Хорошевский, 1999]. И это не случайно, так как для него необходимо не только наличие целей функционирования, но и возможность использования достаточно сложных знаний о среде, партнерах и о себе. С точки зрения целей настоящей книги, наибольший интерес представляют интеллектуальные и действительно интеллектуальные (см. табл. 9.1) агенты. Понятно, что все характеристики более «простых» .типов агентов при этом наследуются.
Иногда агентов определяют через свойства, которыми они должны обладать. Учитывая то, что нас в данной книге, в первую очередь, интересуют интеллектуальные агенты, приведем типовой список свойств, которыми такие агенты должны обладать [Wooldridge et al., 1995; FIPA, 1998]:
• автономность (autonomy, autonomious functioning) — способность функционировать без вмешательства со стороны своего владельца и осуществлять контроль внутреннего состояния и своих действий;
• социальное поведение (social ability, social behaviour) — возможность взаимодействия и коммуникации с другими агентами;
• реактивность (reactivity) — адекватное восприятие среды и соответствующие реакции на ее изменения;
• активность (pro-activity) — способность генерировать цели и действовать рациональным образом для их достижения;
• базовые знания (basic knowledge) — знания агента о себе, окружающей среде, включая других агентов, которые не меняются в рамках жизненного цикла агента;
• убеждения (beliefs) — переменная часть базовых знаний, которые могут меняться во времени, хотя агент может об этом не знать и продолжать их использовать для своих целей;
• цели (goals) — совокупность состояний, на достижение которых направлено текущее поведение агента;
• желания (desires) — состояния и/или ситуации, достижение которых для агента важно;
• обязательства (commitments) — задачи, которые берет на себя агент по просьбе. и/или поручению других агентов;
• намерения (intentions) — то, что агент должен делать в силу своих обязательств и/или желаний.
Иногда в этот же перечень добавляются и такие свойства, как рациональность (retionality), правдивость (veracity), благожелательность (benevolence), а также мобильность (mobility), хотя последнее характерно не только для интеллектуальных агентов.
В зависимости от концепции, выбранной для организации MAC, обычно выделяются три базовых класса архитектур [Wray et al., 1994; Wooldridge et. al., 1995; Nwana, 1996]:
• архитектуры, которые базируются на принципах и методах работы со знаниями (deliberative agent architectures);
• архитектуры, основанные на поведенческих моделях типа «стимул-реакция» (reactive agent architectures);
• гибридные архитектуры (hybrid architectures).
Наиболее «трудными» терминологически в этой триаде являются архитектуры первого типа. Прямая калька — делиберативные архитектуры — неудобна для русскоязычного произношения и не имеет нужной семантической окраски для русскоязычного читателя. Сам термин был введен в работе [Genesereth et al., 1987] при обсуждении архитектур агентов.

Таким образом, в данном случае мы имеем дело с «разумными» агентами и архитектурами, имеющими в качестве основы проектирования и реализации модели, методы и средства искусственного интеллекта. В работе [Тарасов, 1998] таких агентов предлагается называть когнитивными, что не вполне правильно, так как при этом неявно предполагается, что «рассуждающие» агенты познают мир, в котором они функционируют. Нам представляется, что для русского языка более удобным и адекватным были бы термины «агент, базирующийся на знаниях» или «интеллектуальный агент», а также «архитектура интеллектуальных агентов». Именно этих терминов мы и будем придерживаться в данном издании. Первоначально идея интеллектуальных агентов связывалась практически полностью с классической логической парадигмой ИИ. Однако по мере развития исследований в этой области стало ясно, что такие «ментальные» свойства агентов, как, например, убеждения, желания, намерения, обязательства по отношению к другим агентам и т. п., невыразимы в терминах исчисления предикатов первого порядка. Поэтому для представления знаний агентов в рамках данной архитектуры были использованы специальные расширения соответствующих логических исчислений [Поспелов, 1998], а также разработаны новые архитектуры, в частности архитектуры типа BDI (Belief-Desire-Intention). Один из конкретных примеров архитектуры этого класса обсуждается ниже. ,
Принципы реактивной архитектуры возникли как альтернативный подход к архитектуре интеллектуальных агентов. Идея реактивных агентов впервые возникла в работах Брукса, выдвинувшего тезис, что интеллектуальное поведение может быть реализовано без символьного представления знаний, принятого в классическом ИИ [Brooks, 1991]. Таким образом [Connah, 1994]:

Вообще говоря, данный подход ведет свое начало с работ по планированию поведения роботов, которые активно велись в ИИ в 70-х годах. Простым примером реализации реактивных архитектур в этом контексте можно считать системы, где реакции агентов на внешние события генерируются соответствующими конечными автоматами. Широко известным примером системы с реактивной архитектурой является планирующая система STRIPS [Fikes et al, 1971], где использовался логический подход, расширенный за счет ассоциированных с действиями предусловий и пост-условий. Позже в рамках реактивных архитектур были разработаны и другие системы, но, как правило, они не могли справиться с задачами реального уровня сложности.
Учитывая вышесказанное, многие исследователи считают, что ни первый, ни второй подходы не дают оптимального результата при разработке агентов и MAC [Wray et al., 1994]. Поэтому попытки их объединения предпринимаются постоянно и уже привели к появлению разнообразных гибридных архитектур. По сути дела, именно гибридные архитектуры и используются в настоящее время во всех, сколько-нибудь значимых проектах и системах.
Мы рассмотрели основные подходы к разработке мультиагентных систем. Архитектуры MAC и их характеристики, широко используемые в настоящее время, представлены в табл. 9.2.
Таблица 9.2.
Архитектуры MAC и их характеристики

Архитектура
Представление знаний
Модель мира
Решатель
Интеллектуальная Реактивная
Гибридная
Символьное
Автоматное
Смешанное
Исчисление
Граф
Гибридная
Логический
Автомат
Машина вывода

Организация MAC на принципах ИИ имеет преимущества с точки зрения удобства использования методов и средств символьного представления знаний, разработанных в рамках искусственного интеллекта. Но в то же время создание точной и полной модели представления мира, процессов и механизмов рассуждения в нем представляют здесь существенные трудности, уже неоднократно обсуждавшиеся в данной книге в связи с рассмотрением вопросов приобретения знаний.
Реактивный подход позволяет наилучшим образом использовать множество достаточно простых образцов поведения для реакции агента на определенные стимулы для конкретной предметной области. Однако применение этого подхода ограничивается необходимостью полного ситуативного анализа всех возможных активностей агентов.
Недостатки гибридных архитектур связаны с «непринципиальным» проектированием MAC со всеми вытекающими отсюда последствиями. Так, например, многие гибридные архитектуры слишком специфичны для приложений, под которые они разрабатываются. Но несмотря на указанные недостатки, гибридные архитектуры позволяют гибко комбинировать возможности всех подходов. Вот почему в последнее время явно прослеживается тенденция разработки и использования именно гибридных МАС-архитектур и систем агентов [Sloman, 1996].

9.2. Проектирование и реализация агентов
и мультиагентных систем

9.2.1. Общие вопросы
проектирования агентов и MAC

Идеи программных агентов вообще и интеллектуальных агентов, в частности, привлекательны, так как позволяют людям делегировать им свои полномочия по решению сложных задач. Однако разработка MAC и действительно интеллектуальных агентов требует специальных знаний и является сложной ресурсоемкой задачей. Ведь программные агенты — новый класс систем программного обеспечения (ПО), которое действует от лица пользователя. Они являются мощной абстракцией для «визуализации» и структурирования сложного. Но если процедуры, функции, методы и классы — известные абстракции, которые разработчики ПО используют ежедневно, то программные агенты — это принципиально новая парадигма, неизвестная большинству из них даже сегодня.
Вместе с тем развитие и внедрение программных агентов было бы, по-видимому, невозможно без предыдущего опыта разработки и практического освоения концепции открытых систем [Орлик, 1997], которые характеризуются свойствами:
• расширяемости/масштабируемости (возможность изменения набора составляющих системы);
• мобильности/переносимости (простота переноса программной системы на разные аппаратно-программные платформы);
• интероперабельности (способность к взаимодействию с другими системами);
• дружелюбности к пользователю/легкой управляемости.
Одним из результатов внедрения концепции открытых систем в практику стало распространение архитектуры «клиент—сервер» [Орлик, 1997]. В настоящее время выделяются следующие модели клиент-серверного взаимодействия:
• «Толстый клиент — тонкий сервер». Наиболее часто встречающийся вариант реализации архитектуры клиент—сервер. Серверная часть реализует только доступ к ресурсам, а основная часть приложения находится на клиенте.
• «Тонкий клиент — толстый сервер». Модель, активно используемая в связи с распространением Интернет-технологий и, в первую очередь, Web-броузеров. В этом случае клиентское приложение обеспечивает реализацию интерфейса, а сервер объединяет остальные части приложений.
При создании MAC могут с успехом использоваться обе модели, хотя в настоящее время чаще применяется вторая. Но независимо от используемой модели средства разработки и исполнения распределенных приложений, которыми, как правило, являются MAC, опираются на статический подход (позволяют передавать только данные приложений) или динамический подход (обеспечивают возможности передачи исполняемого кода).
При динамическом подходе МАС-приложения используют парадигму мобильных агентов.

Часть исследователей считают, что мобильные агенты обеспечивают более прогрессивный метод работы в сетевых приложениях. Другие авторы отмечают, что мобильные агенты привносят опасность с точки зрения обеспечения секретности информации и загруженности сети [Chess et. al. 1995].
Понятно, что одни и те же функциональные возможности в большинстве случаев могут быть реализованы как посредством мобильных, так и статических агентов. Использование мобильных агентов может быть целесообразным, если они:
• уменьшают время и стоимость передачи данных (например, при больших объемах данных вместо передачи всей необработанной информации по сети на хост-источник посылается агент, который выбирает только необходимую информацию и передает ее пользователю);
• позволяют преодолеть ограничение локальных ресурсов (например, если возможности процессора и объем памяти клиентского компьютера малы, то, может быть, целесообразнее использование мобильных агентов, выполняющих вычисления на сервере);
• облегчают координацию (например, запросы к удаленным серверам выполняются мобильными агентами как отдельные задачи, а потому не нуждаются в координации);
• позволяют выполнять асинхронные вычисления (например, запустив агента, можно переключиться на другое приложение и даже отсоединиться от сети, а результат будет доставлен агентом адресату после выполнения задания).
Мобильные агенты являются перспективными для MAC, но в настоящее время нет единых стандартов их разработки и все еще остается нерешенным ряд проблем, таких как легальные способы перемещения агентов по сети, верификация агентов (в частности, защита от передаваемых по сети вирусов), соблюдение агентами прав частной собственности и сохранение конфиденциальности информации, которой они обладают, перенаселение сети агентами, а также совместимость кода агента и программно-аппаратных средств сетевой машины, где он исполняется [Wayner, 1995].
В настоящее время наиболее известными технологиями реализации статических и динамических распределенных приложений являются программирование со-кетов, вызов удаленных процедур — RFC (Remote Procedure Call), DCOM (Microsoft Distributed Component Object Model), Java RMI (Java Remote Method Invocation) и CORBA (Common Object Request Broker Architecture) [Maurer et al., 1998]. Вместе с тем с точки зрения разработки и реализации MAC наиболее важными, по-видимому, являются последние три — DCOM, Java RMI и CORBA [Gopalan, 1999].
Модель Microsoft DCOM является объектной моделью, которая поддерживается Windows 95, Windows NT, Sun Solaris, Digital UNIX, IBM MVS и др. Основная ее ценность — в предоставлении возможностей интеграции приложений, реализованных в разных системах программирования.
Java RMI-приложения обычно состоят из клиента и сервера. При этом на сервере создаются некоторые объекты, которые можно передавать по сети, либо методы их определяются как доступные для вызова удаленными приложениями, а на клиенте реализуются приложения, пользующиеся удаленными объектами. Отличительной чертой RMI является возможность передачи в сети не только методов, но и самих объектов, что обеспечивает в конечном счете реализацию мобильных агентов.
CORBA является частью ОМА (Object Management Architecture), разработанной для стандартизации архитектуры и интерфейсов взаимодействия объектно-ориентированных приложений. Интерфейсы между CORBA-объектами определяются через специальный язык IDL (Interface Definition Language)^ который является языком описания интерфейсов. Сами интерфейсы могут при этом быть реализованы на любых других языках программирования и присоединены к
CORBA-приложениям. В рамках стандартов предполагается, что CORBA-объекты могут коммуницировать с DCOM-объектами через специальные CORBA-DCOM мосты (Bridges).
Технологии Java RMI и CORBA являются, по-видимому, на сегодняшний день самыми гибкими и эффективными средствами реализации распределенных приложений [Gopalan, 1999]. Эти технологии очень близки по своим характеристикам. Основным преимуществом CORBA является интерфейс IDL, унифицирующий средства коммуникации между приложениями и интероперабельность с другими приложениями. С другой стороны, Java RMI является более гибким и мощным средством создания распределенных приложений на платформе Java, включая возможность реализации мобильных приложений. В настоящее время еще не вполне ясно, какая из этих концепций «победит» в борьбе за мультиагентные системы. Вмешаться в этот процесс может и модель DCOM, активно «продвигаемая» компанией Microsoft. Но анализ существующих реализаций MAC показывает, что пока более распространенным здесь является подход Java RMI.
Выше кратко обсуждались вопросы стратегии программного обеспечения распределенных приложений. Если же вернуться к проблематике MAC, то все программные средства для их разработки и реализации на современном этапе можно разделить на два больших класса: МАС-библиотеки и МАС-среды. Впечатляющий список сайтов, где представлена информация о том и другом программном обеспечении, как из коммерческих, так и из исследовательских организаций, представлен в Интернет по адресу http://www.reticular.com/. Оставляя в стороне вопросы проектирования и реализации МАС-библиотек, которые, конечно, являются базисом для создания мультиагентных приложений, но выходят за рамки данного издания, в оставшейся части настоящего параграфа мы сосредоточимся на обсуждении инструментария для построения MAC. При этом нас будут интересовать, в первую очередь, модели, методы и средства поддержки процессов проектирования агентов и мультиагентных систем. Одним из удачных примеров систем данного класса является, на наш взгляд, инструментарий AgentBuilder компании Reticular Systems, Inc. [AgentBuilder, 1999] — одного из лидеров в этой области, к обсуждению которого мы и переходим.

9.2.2. Инструментарий AgentBuilder

Инструментарий для построения MAC компании Reticular Systems, Inc. состоит из двух компонентов: средств разработки (development tools) и окружения периода исполнения (run-time execution environment). Первый компонент ориентирован на поддержку процессов анализа предметной области создаваемой MAC и проектирование агентов с заданным поведением. Второй — обеспечивает эффективную среду для выполнения агентно-ориентированных программ. И тот и другой компоненты реализованы на языке Java, что позволяет им работать на всех платформах, где установлена Java-среда. Агентные программы, проектируемые в рамках AgentBuilder, тоже являются Java-программами и могут исполняться на любом компьютере, где установлена виртуальная Java-машина JVM (Java virtual machine).
Общая схема процесса проектирования и реализации агентно-ориентированных приложений на основе AgentBuilder ToolKit представлена на рис. 9.1. Этот инструментарий имеет средства для организации и предметной области создаваемой MAC, средства спецификации архитектуры агенства и поведения агентов, а также средства отладки агентных приложений и наблюдения за поведением созданных агентов.
Модель «жизненного цикла» агентов, разрабатываемых в рамках AgentBuilder, представлена на рис. 9.2. Как следует из данной схемы, стандартный «жизненный цикл» агента включает следующие основные шаги:
• обработка новых сообщений;
• определение, какие правила поведения применимы в текущей ситуации;
• выполнение действий, специфицированных этими правилами;
• обновление ментальной модели в соответствии с заданными правилами;
• планирование.
Собственно ментальные модели (начальная и текущая) включают описания исходных (текущих) намерений, полаганий, обязательств и возможностей, а также спецификации правил поведения.


Рис. 9.1. Технологическая схема процесса разработки
агентно-ориентированных приложений на базе AgentBuilder ToolKit

Данная модель получила название Reticular Agent Mental Model (RAMM) и является развитием модели Шохама (Shoham) [Shoham, 1993], где все действия выполняются только как результат определенных обязательств. В рамках RAMM эта идея расширена до уровня общих правил поведения, которые определяют причину действия агента в каждой точке его функционирования. При этом правила поведения фиксируют множество возможных «откликов» агента на текущее состояние среды так, как это предписывается полаганиями.
Для спецификации поведения агентов в системе AgentBuilder используется специальный объектно-ориентированный язык RADL (Reticular Agent Definition Language). Правила поведения в этом языке могут рассматриваться как конструкции вида WHEN-IF-THEN.





Рис. 9.2. Модель «жизненного цикла» агента в системе AgentBuilder

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

NAME имя правила
WHENMessage Condition(s)
IF Mental Condition(s)
THENPrivate Action(s); Mental Change(s); Message Action(s)

Для иллюстрации возможностей этого языка рассмотрим пример правила «Движение-Вперед-На-Зеленый-Свет» из предметной области «Управление автомобилем», взятый из руководства пользователя [AgentBuilder, 1999].

NAME "Greenlight Move Forward Rule"
WHEN
?KQMLMessage.Performative EQUALS TELL
?KQMLMessage.Sender EQUALS "stoplight-agent"
?KQMLMessage.Content EQUALS String
?KQMLMessage.Ontology EQUALS "Stoplight"
IF
?KQMLMessage.Content EQUALS "stoplight-green"
?KQMLMessage.Status EQUALS "stoppedAtRedLight"
currentMotion.Content EQUALS "stoplight-green"
currentLocation EQUALS nextlntersection
NOT(currentLocation EQUALS destination)
FOR_ALL (?BlockedIntersection,
NOT(?BlockedIntersection. Location EQUALS currentLocation))
THEN
DO (Go(trafficSpeed))
DO ($nextlntersection =
getNextIntersection (currentLocation,
currentMotion.Direction))
ASSERT (SET_VALUE_OF currentMotion.Status TO moving)
ASSERT (SET_VALUE_OF nextlntersection TO Snextlntersection)
SEND (performative = REPLY, receiver = "stoplight-agent",
content = "acknowledged",
in-reply-to = ?KQMLMessage.Reply-with)

Как следует из данного примера, в языке RADL активно используются образцы, имеются достаточно развитые средства работы с переменными и представительный набор действий, включающий формирование перформативов языка KQML [Labrou et al., 1997]. Структуры данных, на которых «работает» данный язык, являются, по существу, фреймами, а сами правила — суть продукции специального вида. Язык поддержан на инструментальном уровне системой специальных язы-ково-ориентированных редакторов.
Спецификация поведения агентов и их ментальных моделей составляет специальный файл (agent definition file), который используется совместно с классами и методами из библиотеки действий агентов и библиотеки интерфейсов. Этот файл интерпретируется в рамках компонента Reticular's Run-Time Agent Engine, являющегося частью окружения периода исполнения AgentBuilder.
Оценивая подход к спецификации моделей поведения агентов, используемый в AgentBuilder, можно констатировать, что в целом это серьезная система представления и манипулирования знаниями, ориентированная на описание моделей типа RAMM. Вместе с тем в данной модели отсутствуют средства эксплицитного управления выводом, которые могли бы существенно увеличить функциональную мощность языка. Нет в модели и средств явной фиксации состояния агента, отличных от флагов и/или значений переменных. Не вполне ясно и то, как в спецификации моделей поведения могут быть учтены разные, но одновременно сосуществующие «линии поведения», что характерно для действительно интеллектуальных агентов. Не вполне обоснованным представляется и использование режима интерпретации для реализации поведения агентов.
Но в целом можно еще раз отметить, что инструментарий AgentBuilder является современным и мощным средством проектирования и реализации MAC.

9.2.3. Система Bee-gent

Инструментарий AgentBuilder, обсуждавшийся выше, базируется на концепции среды разработки, принятой в технологии программирования. Отличный от этого подход применяется в системе Bee-gent [Bee-gent, 1999]. Здесь для проектирования и реализации MAC используется специальная МАС-библиотека, реализованная на языке Java, а собственно технология, на наш взгляд, представлена методологией спецификации поведения агентов распределенной системы. При этом в систтеме Bee-gent используется множество базовых агентов (generic agents), среди которых можно выделить упаковщики (agent wrappers) и медиаторы (mediation agents).
Поведение всей системы, направленное на достижение определенных целей, базируется на спецификации «бесед» (message exchanges) через протоколы взаимодействия (interaction protocols).
Такие протоколы представляются специальными графами (рис. 9.3), основными понятиями которых являются состояния (states) и переходы (transitions). При этом переходы, по сути дела, лишь специфицируют смещение «фокуса» в следующее состояние с помощью специальных правил перехода, а ядро формализма составляют состояния. Именно здесь проверяются предусловия перемещения в следующее состояние и в случае их удовлетворения выполняются действия, в основе которых обмен XML/ACL сообщениями. Возможны правила, результатом выполнения которых является выбор следующего состояния из множества подходящих.
Как и обычно в таких случаях, в качестве базиса сообщений декларируется использование теории речевых актов [Austin, 1965; Searle, 1985]. Однако в случае Bee-gent для этого используется специальный язык ACL, разработанный на основе KQML [Labrou et al, 1997]. Интересно здесь то, что логическая структура ACL-выражений представляется в формализме XML [XML, 1998]. Поэтому язык описания поведения агентов в Bee-gent называется XML/ACL. Основное отличие его от, например, языка RADL в том, что в XML/ACL введены перформативы представления намерений (intentions), а также средства спецификации потоков развертывания беседы (conversation flows). Вместе с тем в языке спецификации поведения агентов системы Bee-gent нет правил, определяющих, в каких случаях какие перформативы должны использоваться. И, следовательно, нет типовых сценариев диалогов. Пример перформатива в формализме XML/ACL приведен ниже:

<!DOCTYPE request SYSTEM "request.dtd">
<request>
<sender>Mediation Agent</sender>
<receiver>Agent Wrapper</receiver>
<content>
<action>actK/action>
<actor>Agent Wrapper</actor>
<args>null</args>
</content> ;
<protocol>Request-inform</protocol>
<reply-with>MSG-IO:K/reply-with>
<ontology>default</ontology>
</request>


Рис. 9.З. Общая структура протоколов взаимодействия
в системе Bee-gent

Как следует из данного примера, для спецификации перформативов используется система специальных тегов, что хорошо коррелирует с предложениями FIPA по созданию языка SKDL (Structured Knowledge Description Language) [SKDL, 1998]. Вместе с тем реализация поведения агентов лежит на специальной системе Java-классов и практически никак не связана с внешним представлением перформативов в языке XML/ACL.
Для иллюстрации подхода Bee-gent к описанию поведения агентов рассмотрим модельную задачу брокера [Bee-gent, 1999], обслуживающего потенциального покупателя, который находит продавца определенного товара, обсуждает с ним цены и информирует покупателя о возможных вариантах покупки.
Контрактная сеть верхнего уровня для данной задачи представлена на рис. 9.4.


Рис. 9.4. Контрактная сеть верхнего уровня для задачи брокера

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
















Рис. 9.5. Граф протокола взаимодействия для поведения продавца

Собственно инициация агента здесь осуществляется стандарным для Java-приложений образом:

import com.toshiba.beegent.*;
import com.toshiba.beegent. xml. *;
import com.toshiba.beegent.util. *;

public class AW2 extends AgentWrapper {
public static void main (StringC] argv) throws Exception {
AW2 aw = new AW2();
aw.setName ("bidder");
aw.printLog (true);
aw.setPassword ("kawamura");
aw.addPublicIPStates ,();
aw.startIP ();
}
}

Каждое состояние в протоколе взаимодействия является экземпляром класса AwrlPState, фрагмент описания которого приведен ниже.


class AwrlPStatel extends AwrlPState {
AwrlPStateSI () { super ("INIT"); }

public void action () {
XmlAcl xa = null;
…………………………………
while ( waitXML (0) ){
xa = getXML ();
perf = xa.getTag2Value ("performative");
sender = xa. getTag2Value ("sender")';
action = xa.getTag2Value ("action");
if (perf.equals ("cfp")) break;
}
// Send XML/ACL
int rand = new Random (System.currentTimeMillis()). nextlnt ();
int dice = Math.abs (rand) % 3;
switch (dice) {
case 0: // generate Refuse performative
setPostcond ("INIT");
break;

<< Предыдущая

стр. 21
(из 26 стр.)

ОГЛАВЛЕНИЕ

Следующая >>