Роль агентов в распределенном программировании

Возникновение распределенных программ было вызвано практической необходимостью. Нетрудно представить, что существует некоторый ресурс, который нужен программе, но этот ресурс размещен на другом компьютере или в сети. Под такими ресурсами часто понимают базы данных, Web-серверы, серверы электронной почты, серверы приложений, принтеры и крупные запоминающие устройства. Подобными ресурсами обычно управляет часть ПО, именуемал сервером. Другал часть ПО, которой необходимо получить доступ к ресурсам, называется клиентом. Тот факт, что ресурсы и клиент расположены на рааличных компьютерах, приводит к необходимости использования распределенных архитектур. В большинстве случаев не имеет смысла объединять эти программы в одну большую и выполнять ее на одном компьютере и в едином адресном пространстве. Более того, существует множество программ, разработанных в различное время, разными разработчиками и для разных целей, но которые могут успешно использовать преимущества друг друга. Приложение, которое использовало эти программы, эволюционировало определенным образом и в итоге «заслужило звание» распределенного приложения. Поскольку эти программы отделены друг от друга, каждая из них должна иметь собственное адресное пространство и «свои» ресурсы. Когда эти программы используются для совместного решения задачи, они образуют распределенное приложение. Оказывается, что архитектура распределенной программы обнаружила высокую степень гибкости, что позволило применить ее к крупномасштабным приложениям. Во многих приложениях необходимость в распределенной архитектуре обнаруживается довольно поздно, «когда поезд уже ушел». Но если заранее идентифицировать такую необходимость, можно с успехом использовать соответствующие методы проектирования программного обеспечения. Если вы уже точно знаете, что вам нужно разрабатывать распределенное приложение, то следующий вопрос должен прозвучать так: «как именно оно должно быть распределено?». От ответа на этот вопрос будет зависеть, какую модель следует использовать в этом случае. Несмотря на существование множества различных моделей (равноправных узлов и типа «клиент/сервер»), в этой книге мы остановимся только надвух: мультиагентной архитектуре и архитектуре «классной доски».

Оба эти вида архитектуры м огут использовать преи м у щ ества агентов, поскольку агенты представ л яют собой са м одостаточные, автоно м ные и рациональные программные структуры. Рациональность агентов зак л ючается в том, что им известно их назначение. И обычные объекты имеют це л ь, но агенты «знают», какова эта цель. Идентификация наз н аче н ия каждого аспекта ПО — вполне естественный процесс. На этане проектирования нетрудно продумать цель отдельной части ПО, и поэтому простейшая форма декомпозиции ПО состоит в том, чтобы назначить агенту его цель. Затем приходит черед понять, агентов какого класса лучше всего уполномочивать на выполнение той или иной работы. Поскольку агент— это единица модульности в агентно-ориентированной программе (agent-oriented program — АОР), то проблема распределения сводится к поиску средств взаимодействия множества агентов. Процесс проектирования исходного класса агента вбирает в себя все то, что необходимо для идентификации отдельных составных частей распределенной программы. Справившись с созданием агентов как действительно рациональных объектов, мы сможем воспользоваться преимуществами CORBA-спецификации для разработки действительно распределенных мультиагентных систем. CORBA скрадывает сложность распределенного программирования и взаимодействия посредством сетей (intranet Hlnternet). Обзор средств распределенного программирования с использованием CORBA-сиецификации приведен в главе 8. Поскольку агенты являются объектами, этот обзор CORBA-средств имеет силу и для агентов. В главе 6 рассмотрена система PVM (Parallel Virtual Machine — параллельнал виртуальная машина). Систему PVM также можно использовать для значительного упрощения взаимодействия между агентами, существующими в различных процессах или на разных компьютерах. Агенты можно реализовать как CORBA-объекты, либо их можно назначить отдельным PVM-процессам. В обоих случалх взаимодействие агентов упрощается в значительной степени. Если в одном приложении задействовано несколько агентов, то такое приложение представляет собой мультиагентную систему. Если агенты расположены на одном компьютере, то для взаимодействия между собой они могут использовать CORBA-, PVM- или MPI-средства (Message Passing Interface). Агенты в различных процессах также могут использовать такие традиционные методы межпроцессного взаимодействия (IPC), как FIFO-структуры, разделяемую память и каналы. В распределенном программировании есть три основные проблемы.

1. Идентификация декомпозиции ПО распределенного решения.

2. Реализация эффективного и рационального взаимодействия между распределенными компонентами.

3. Обработка исключительных ситуаций, ошибок и частичных отказов.

Несмотря на то что для реализации п. 2 в понятии класса агента нет ничего такого, что было бы свойственно только агентам, смысл п. 1 и 3 почти подразумевается в самой сути агента. Рациональность каждого агента определяет его назначение, а следовательно, и роль, которую он будет играть в решении ПО. Поскольку агенты самодостаточны и автономны, то хорошо продуманный класс агента должен включать необходимые меры по обеспечению их отказоустойчивости.