Имя материала: Базы знаний интеллектуальных систем

Мобильные агенты являются перспективными для 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. Технологическая схема процесса разработки

Страница: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 |