АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
3.14. Облачные вычисления Идея облачных вычислений состоит в предоставлении пользователям удаленного доступа к услугам, вычислительным ресурсам и приложениям через Интернет. Появление современных облачных вычислений обычно относят к 2005 году и связывают выходом на рынок бизнес-решение под названием «Amazon Web Services» от компании Amazon. В 2009 году было запущено приложение Google Apps, что стало следующим важным шагом к популяризации и осмыслению облачных вычислений. Согласно документу IEEE, опубликованному в 2008 году: «Облачная обработка данных — это парадигма, в рамках которой информация постоянно хранится на серверах в Интернете и временно кэшируется на клиентской стороне, например, на персональных компьютерах, игровых приставках, ноутбуках, смартфонах и так дале.» Национальный институт стандартов и технологий CША (NIST) определяет облачные вычисления (Cloud Computing) как «модель обеспечения повсеместного сетевого доступа по требованию к совместно используемому пулу конфигурируемых вычислительных ресурсов, которые можно быстро предоставить и внедрить с минимумом административных усилий или взаимодействия с сервис-провайдером» [47]. Облачные вычисления по замыслу создателей должны: реализовывать самообслуживание по требованию, обеспечивать широкополосный сетевой доступ, поддерживать пул ресурсов, обеспечивать возможность быстрой перенастройки или расширения и иметь измеряемое обслуживание. Применительно к облачным вычислениям используются 3 сервисных модели: программа, платформа и инфраструктура в виде сервиса и 4 модели внедрения: публичная, общественная, частная и гибридная. Облаком обычно принято называть совокупность удаленных серверов, на которых разворачиваются виртуальные среды и программное обеспечение. Пользователь не имеет прямого доступа к аппаратному обеспечению, и обычно доступ к сервисам осуществляется через сеть. В облачных вычислениях различают несколько видов сервисов, для удобства в их обозначении используют аббревиатуру «as a service», то есть «как сервис», или «в виде услуги». Облачная обработка данных как концепция включает в себя понятия: «Все как услуга», «Инфраструктура как услуга», «Платформа как услуга», «Программное обеспечение как услуга»,«Рабочее место как услуга», «Данные как услуга» и т. п. Основными можно считать понятия Программное обеспечение как услуга, Инфраструктура как услуга и Платформа как услуга. SaaS (Software as a Service) - это модель использования бизнес-приложений в качестве Интернет-сервисов. SaaS приложения работают на сервере провайдера. Пользователь не покупает, а арендует приложение и работает с ним через браузер. В качестве преимуществ SaaS по сравнению с традиционным программным обеспечением обычно указывают следующие: низкая стоимость владения, более короткие сроки внедрения, возможность оперативно и часто бесплатно протестировать приложение, поддержка и обновление системы обеспечивается, возможность работать через Интернет, что очень удобно для географически распределенных компаний и удаленных сотрудников, минимальные требования к производительности компьютера пользователя, кросс-платформенность. Основные недостатки – это риски, связанные передачей коммерческих данных стороннему провайдеру, ограниченная скорость работы приложения и возможности сбоев в связи с необходимостью работать через Интернет. IaaS (Infrastructure as a Service) пользователю предоставляется возможность самостоятельно управлять ресурсами обработки, хранения, сетями, например, он (она) может устанавливать и запускать произвольное программное обеспечение, такое как ОС, платформенное и прикладное ПО, контролировать ОС, виртуальные системы хранения данных и установленные приложения. Управление и контроль основной физической и виртуальной инфраструктурой облака, в том числе сетями, серверами осуществляется провайдером. Основное достоинство такого подхода состоит в том, отпадает необходимость в приобретении физического оборудования, организации его обслуживания. Platform as a Service (PaaS, «платформа как услуга») — это модель предоставления облачных сервисов, при которой пользователь получает доступ к использованию информационно-технологических платформ, включая ОС, СУБД, промежуточному ПО, инструментальным средствам разработки и тестирования, размещённым у облачного провайдера. В этой модели вся информационно-технологическая инфраструктура полностью управляется провайдером, который также определяется состав доступных для потребителей видов платформ и состав управляемых параметров платформ, а пользователь может использовать платформы, создавать их виртуальные экземпляры, устанавливать, разрабатывать, тестировать, эксплуатировать на них прикладное программное обеспечение, при этом динамически изменяя количество потребляемых вычислительных ресурсов. Плата с пользователей облачных платформ может взиматься в зависимости от уровня потребления, тарификация возможна по времени работы приложений потребителя, по объёму обрабатываемых данных и количеству транзакций над ними, по сетевому трафику. Границы управляемости. Использование различных типов облачных сервисов в разной мере ограничивают свободу пользователя. Отличия в границах управляемости для различных типов облачных сервисов показаны в табл. 3.2. Из табл. 3.2 видно, что при развертывании собственной IT-инфраструктуры пользователь может управлять всеми ее компонентами – от сетевых ресурсов до выполняющихся приложений. При использовании модели IaaS пользователь может контролировать данные, приложения и промежуточное ПО, а при использовании модели PaaS, все компоненты платформы предоставляются пользователю как сервисы с ограниченными возможностями для управления ими. Таким образом, пользователь получает в свое распоряжение оптимально сконфигурированную платформу, не требующую дополнительных настроек. Таблица 3.2. Отличия в границах управляемости управляемости для различных типов облачных сервисов
Модели развертывания. Можно выделить 4 основные модели развертывания облачных сервисов. Публичное облако (public cloud) представляет собой инфраструктуру, предназначенную для свободного использования и может находиться в собственности, управлении и эксплуатации коммерческих, научных и правительственных организаций (или какой-либо их комбинации). Владельцем облака является поставщика сервисов. Общественное облако (community cloud) может находиться в совместной собственности, управлении и эксплуатации одной или более из организаций сообщества или третьей стороны. Физически оно может существовать как внутри, так и вне юрисдикции владельца. Частное облако (private cloud) ориентировано на использование в рамках одной организации, но может включать несколько групп пользователей, например, подразделений одной организации. Частное облако может находиться в собственности, управлении и эксплуатации как самой организации, так и третьей стороны (или какой-либо их комбинации). Физически оно может существовать как внутри, так и вне юрисдикции владельца. Гибридное облако (hybrid cloud) представляет собой комбинацию публичных, общественных или частных, облачных инфраструктур, остающихся уникальными объектами, но связанных между собой стандартизованными или частными технологиями передачи данных и приложений. Характеристики. К основным характеристикам облачных платформ обычно относят: масштабируемость, эластичность, многофункциональность, самообслуживание по требованию, билинг. Масштабируемость можно определить, как способность выдерживать растущие нагрузки и обрабатывать большие объемы данных, быстрая и надежная работа, исключающая отказы в обслуживании, задержки в ответах от системы и сбои, позволяющая повысить удовлетворенность и лояльность пользователей. Эластичность можно определить, как способность реагировать на изменяющиеся условия ведения бизнеса, например, сложившаяся рыночная конъюнктура и действия конкурентов могут потребовать быстро внедрить новый сервис, выполнив полный цикл планирования, проектирования и разработки ИС. Эластичность позволяет оперативно наращивать мощность облачной инфраструктуры, при минимальных инвестициях в оборудование и ПО. Эластичность тесно связана с масштабируемостью приложений, так как решает задачу моментального изменения количества выделяемых для работы вычислительных ресурсов. Многофункциональность можно рассматривать как один из способов снижения расходов за счет максимального использования общих ресурсов для обслуживания разных организаций и различных групп пользователей. Многофункциональность может быть особенно привлекательна для разработчиков приложений, так как позволяет снизить собственные расходы на оплату ресурсов облачной платформы и максимально использовать доступные вычислительные ресурсы. Самообслуживание по требованию можно определить, как наличие у пользователя возможности самостоятельно определять и изменять параметры сервисов, такие как скорости доступа, объём хранимых данных без взаимодействия с провайдером сервисов. Биллинг обычно определяют как комплекс процессов и решений, ответственных за сбор информации об использовании сервисов, их тарификацию, выставление счетов абонентам. Провайдер автоматически исчисляет потреблённые ресурсы на определённом уровне абстракции, например, объём хранимых данных, пропускная способность, количество пользователей, количество транзакций, и на основе этих данных оценивает объём предоставленных потребителям услуг. Существующие облачные платформы На рынке сегодня существует много как коммерческих, так открытых платформ, на основе которых организации создают свои инфраструктуры и предлагают средства для их управления, в частности, предоставляют комплексы для превращения имеющихся ресурсов в облака. Публичные облака. Из наиболее известных облачных решений можно отметить следующие платформы и компании: Amazon Web Services (AWS). Особенность является то, что AWS - это, инфраструктурный сервис (IaaS), который предоставляет максимум свободы разработчикам в выборе платформы и среды разработки. Однако проблема состоит в том, что многое приходится делать вручную. Лучше всего AWS подходит для построения SaaS сервисов. Windows Azure. ориентирована на разработчиков и компании, работающие с технологиями от Microsoft, хотя и поддерживает PHP, MySQL, Ruby on Rails, Python, Java, Основным преимуществом Azure перед Amazon Web Services является высокий уровень автоматизации, позволяющий разработчику думать только о своем приложении, а не об инфраструктуре. Следует отметить, что Windows Azure поддерживает стандарты SOAP, REST. Google App Engine (GAE). GAE, в основном, ориентирован на создание SaaS сервисов для малого бизнеса. Он, ориентирован, в первую очередь, на языки Python и Java. Платформа GAE предоставляет ограниченные бесплатные ресурсы (дисковое пространство и трафик), что удобно для образовательных учреждений и стартапов. VMWare vCloud. VMWare vCloud не является самодостаточной облачной платформой. Это промежуточное ПО, которое несколько партнеров VMWare предоставляют поверх своей серверной инфраструктуры. Поскольку VMWare является мировым лидером на рынке систем виртуализации, то главным преимуществом этой платформы является поддержка виртуальных образов приложений, что позволяет быстро и просто переносить локальные бизнес-приложения на облачную платформу без проблем, связанных с переносом сопутствующей ИТ-инфраструктуры. IBM Cloud. IBM Cloud ориентирована преимущественно на крупные компании и ресурсоемкие процессы: разработка и тестирование ПО, хранение и аналитическая обработка огромных массивов данных. Частные облака. Существует не только множество провайдеров предоставляющих ресурсы облачных систем, но также и различные приложения, для создания собственных облачных систем, такие как Eucalyptus, OpenNebula, OpenStack [48, 49, 50, 51]. Eucalyptus. (Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems). Eucalyptus позиционируется как открытое (open source) решение для организации доступа к вычислительным ресурсам. Также предоставляется возможность балансировки нагрузки и динамического масштабирования системы. Eucalyptus ориентирован на реализацию «облачных» технологий на кластерах. Интерфейс Eucalyptus совместим с интерфейсами облаков Amazon. Инфраструктура разработана для поддержки множественных клиентских интерфейсов. Eucalyptus реализуется на платформе Linux с использованием, как правило, доступных инструментариев и базовых веб-сервисных технологий. Eucalyptus реализует схему IAAS (Infrastructure-as-a-Service), а именно “нижний” уровень облака, позволяющий запускать виртуальные машины по запросу вышестоящих приложений. Возможности Eucalyptus во многом позаимствованы из Amazon, поэтому Eucalyptus с некими ограничениями и допущениями можно рассматривать как открытую альтернативу сервисам Amazon. Пример иерархической структуры Eucalyptus изображен на рис. 3.19.  Рис. 3.19. Eucalyptus. Пример иерархической структуры Node Controller (Контроллер узла, КУ) управляет запуском, работой и остановом виртуальных машин на подведомственном узле. Узел, это компьютер, на которой установлен гипервизор, который обеспечивает работу виртуальных машин (в терминологии Eucalyptus instances). Cluster Controller (Контроллер кластера, КК) управляет подведомственными контроллерами узлов (NC): собирает информацию о загруженности узлов и принимает решения, на каких узлах будет выполнен запуск виртуальных машин. Образы виртуальных машин хранятся в хранилище, в качестве которого хранилища используется Walrus (морж) – сервис, подобный сервису Amazon S3 (расшифровывается как Amazon Simple Storage Server — простое хранилище файлов от Amazon). Если говорить кратко, то это просто хранилище в Интернете.) Cloud Controller (Контроллер облака) представляет собой точку входа, на которую со стороны конечного пользователя или вышестоящего приложения поступают запросы на запуск виртуальных машин, а со стороны контроллеров кластеров поступают данные о загруженности отдельных узлов облака. Алгоритм работы. Владелец облака помещает в хранилище образы тех виртуальных машин, которые могут запускаться в облаке (например, Ubuntu, Debian или другой Linux). В запросе пользователя указывается сколько и какие машины требуется запустить. Пользователь может указать, в каком кластере, или зоне должны быть запущены машины. Соответствующий контроллер кластера получает запрос и принимает решение, на каких узлах будет выполнено задание. Запрос направляется либо первому из узлов, имеющему свободными ресурсы до его полного заполнения (режим Greedy) либо поочередно каждому из узлов (RoundRobin). Получив задание, контроллер узла загружает соответствующий образ из хранилища или своего локального кэша, если этот образ уже загружался, и запускает виртуальные машины средствами гипервизора. Eucalyptus поддерживает разные варианты организации сети, различающиеся механизмом выделения IP-адресов. В простейшем случае (используется по умолчанию) гостевые виртуальные машины в режиме System получают IP-адреса от DHCP-сервера, который должен быть во внешней сети. Кроме того, можно назначать каждому экземпляру ОС собственный IP-адрес с помощью внутреннего DHCP-сервера. Можно размещать ОС в отдельных сетях, работающих по правилам, определяемым самим. Eucalyptus может быть полезен во многих случаях, например, есть имеется сервис реализован в облачной среде, то по мере того, как количество запросов растет и сервис перестает справляться с нагрузкой, в систему можно добавить (динамически или по требованию) новые узлы и перераспределить нагрузку между ними. Eucalyptus может быть полезен разработчикам ИС, например, можно проверить работоспособность разработанного приложения на разных платформах. Следует отметить ограничения Eucalyptus. Eucalyptus – это, прежде всего, система выделения ресурсов, которая по имеющемуся образу может создавать произвольно число экземпляров гостевых машин. После выполнения задания машина уничтожается и нет возможности сохранить ее образ, что не всегда удобно для разработчиков. OpenNebula — это один из самых значимый проектов, относящихся к облачных технологиям. OpenNebula может быть использован для управления виртуальной инфраструктурой в информационном центре или кластере или для объединения локальной инфраструктуры с публичной облачно-ориентированной инфраструктурой. OpenNebula также поддерживает публичные облака. Это полностью открытая платформа для организации управления облачной инфраструктурой и виртуальными окружениями. Пакет позволяет организовать взаимодействие таких элементов, как хранилище, сеть, технологии виртуализации, средства мониторинга и управления безопасностью, Позволяет создавать динамически разворачиваемые многоуровневые сервисы, комбинировать ресурсы дата-центра и внешних облачных сервисов. Код системы полностью открыт и доступен всем желающим в полном объеме без ограничений, имеются готовые установочные пакеты для Linux (Ubuntu, Debian, Red Hat). OpenNebula позволяет создавать облака 3 типов: частные, доступные только внутри организации, полностью подконтрольные и выполненные на собственных мощностях, публичные, работающие в инфраструктуре внешних провайдеров, таких как Amazon, гибридные, сочетающие элементы публичных и частных облачных систем. Например, определенная критически важная часть инфраструктуры можно работать в частном облаке, а вторичные системы вынесены во внешние облака, или изначально вся система построена как частная, но при нехватке ресурсов в пиковые моменты к работе привлекаются мощности публичных сервисов. OpenStack — это ПО, которое может быть использован для создания инфраструктурных облачных сервисов и облачных хранилищ. OpenStack включает следующие основными компоненты: контроллер вычислительных ресурсов (Nova), облачное файловое хранилище, библиотека образов виртуальных машин, сервис идентификации, служба работы с блочными устройствами хранения данных, сервис «подключение к сети как услуга», графический интерфейс администрирования, средства сбора, нормализации и трансформации данных, предоставляемых сервисами, которые используются для реализации различных сценариев реагирования на события. Nova можно рассматривать как контроллер, управляющий работой виртуальных машин. Все действия, необходимые для поддержки жизненного цикла виртуальной машины в облаке OpenStack обрабатывает Nova. Она управляет всеми вычислительными ресурсами. Nova — это только средство управления платформой. Nova предоставляет свои возможности с помощью API веб-сервисов, совместимых с EC2 от Amazon Web Services. Amazon Elastic Compute Cloud (Amazon EC2) — это веб-сервис, который предоставляет вычислительные мощности в облаке. Этот сервис входит в инфраструктуру Amazon [52]. По состоянию на 2015 организация OpenStack Foundation, занимающаяся поддержкой проекта OpenStack насчитывает более чем 500 членов, включая AMD, Cisco, Citrix, Fujitsu, Hewlett-Packard, Huawei, IBM, Intel, NEC, Oracle, Red Hat, Solidfire, SUSE Linux, VMware, и Yahoo! [48]. Гибридное облако - это сочетание, по крайней мере, одного частного облака и одной облачной инфраструктуры общего пользования, создающее среду, которая обеспечивает прозрачный доступ к гибридному облаку и может динамически наращиваться для управления неравномерной нагрузкой. Гибридные облака становятся все более популярны, поскольку позволяет организации создать лучшие условия для реализации своей бизнес-модели. При этом усиливается внутренний контроль приложений, которые предприятие не хочет выводить за пределы межсетевого экрана, но в то же время остается возможность использовать облачные вычисления, когда они соответствуют потребностям организации. Схема гибридного облака показана на рис. 3.20. Работу приложений организации обеспечивают 2 публичных и частное облако с применением базовой модели SaaS.  Рис. 3.20. Гибридное облако Гибридные облака чаще всего используются в случаях, когда критически важные приложения необходимо оставить внутри организации, а остальные располагаются в облаке, когда облако используется в качестве временного рабочего пространства, когда облако используется в случае резервного ресурса при внезапных пиковых нагрузках. Другие типы облачных сервисов SaaS, IaaS и PaaS – это только основные модели облачных сервисов. В первую очередь в рамках гибридных облаков, предлагается большое число других моделей. Рассмотрим некоторые из них. При использовании модели компонент как сервис, облако превращается из среды, основанной на SaaS, в экосистему, в которой приложения сокращаются до своих основных функций и предоставляются как компоненты, при этом под компонентом понимается готовая, независимая часть бизнес-функциональности. Подход "каждый компонент как сервис" (XaaS), напоминающий многочисленные и разнообразные Web-сервисы, стал центральной концепцией вычислений на основе гибридного облака. Выбор компонентов "как сервис" быстро растет, что делает модель гибридного облака все более привлекательной. Например, в современном офисе часто используется компонент "связь как сервис", который включает такие сервисы, как голос поверх интернет-протокола (VoIP) и единая связь (Unified Communications), в которую входят обмен мгновенными сообщениями, видеоконференции и интерактивная доска. "Связь как сервис" позволяет сотрудникам предприятия быстрее и эффективнее взаимодействовать и общаться. Достаточно часто популярным является подход "рабочий стол как сервис". При использовании этой модели провайдер несет ответственность за хранение данных, резервное копирование, обеспечение безопасности и обновления. При использовании гибридных облаков, основные функции можно предоставлять как сервисы. "Сеть как сервис" ― это комбинация предложений "платформа как сервис" (PaaS) и "инфраструктура как сервис" (IaaS). Используя "сеть как сервис", сетевые ресурсы можно наращивать и сокращать в зависимости от их фактического использования. "Хранение как сервис" ― это способ арендовать дисковое пространство, обеспечивая экономию расходов на персонал, оборудование и физические запоминающие устройства. К этому можно добавить "базу данных как сервис", "мониторинг как сервис" позволяет дистанционно контролировать и управлять сетями, приложениями и службами; а "безопасность как сервис" обеспечивает управление учетными записями и доступом. В гибридном облаке легко управлять всеми этими новыми ИТ-сервисами. Разработку тоже можно вести в облаке, используя "проектирование как сервис". Это интегрированная среда, к которой локальные и удаленные группы разработчиков могут обращаться для целей создания, тестирования и передачи своего кода. Система планирования ресурсов предприятия также может быть развернута в облаке ― с использованием услуг "корпоративные приложения как сервисы". "Вычисления как сервис" можно использовать для доступа к виртуализированным серверам с целью быстрого наращивания вычислительной мощности в случае необходимости и ее сокращения при изменении требований. На самом деле в облаке можно разместить все бизнес-процессы предприятия, используя "бизнес-процессы как сервис". Даже такие процессы, как выставление счетов, могут предоставляться как сервис. Это приводит к созданию гибкой и динамичной архитектуры предприятия, оптимальной для реалий сегодняшней глобальной цивилизации и торговли. Преимущества облачных вычислений. 1. Пользователь оплачивает услугу только тогда, когда она ему необходима, а самое главное он платит только за то, что использует. 2. Облачные технологии позволяют экономить на приобретении, поддержке, модернизации ПО и оборудования. 3. Масштабируемость, отказоустойчивость и безопасность ― автоматическое выделение и освобождение необходимых ресурсов в зависимости от потребностей приложения. Техническое обслуживание, обновление ПО производит провайдер услуг. 4. Удаленный доступ к данным в облаке ― работать можно из любой точки на планете, где есть доступ в сеть Интернет. Недостатки облачных вычислений 1. Пользователь не является владельцем и не имеет доступа к внутренней облачной инфраструктуре. Сохранность пользовательских данных сильно зависит от компании провайдера. 2. Недостаток актуальный для российских пользователей: для получения качественных услуг пользователю необходимо иметь надежный и быстрый доступ в сеть Интернет. 3. Отсутствие общепринятых стандартов в направлении безопасности облачных технологий. 3.15. Мультиагентные системы Интеллектуальные агенты (ИА) и основанные на них мультиагентные системы (МАС). МАС являются одним из наиболее интересных классов интеллектуальных ИС, который на протяжении многих лет считался одним из перспективных, но, к сожалению, не получил широкого распространения. ИА обычно определяют как систему, обладающую следующими свойствами [54]: автономность – способность действовать (решать задачи) без прямого вмешательства человека или других агентов, самостоятельно управляя своими действиями и внутренним состоянием; реактивность – способность к восприятию внешней среды и своевременному отклику на происходящие в ней события (при этом внешней средой агента может быть физический мир, пользователь, совокупность других агентов или их комбинация); активность – способность осуществлять целенаправленное поведение и проявлять инициативу, а не просто откликаться на внешние события; социальность – способность взаимодействовать с другими агентами и/или людьми, общаясь с ними посредством языка межагентного общения. Данное определение характеризует лишь внешние свойства агента и ничего не говорит о его внутренней организации, поэтому его называют слабым, Известно и другое определение ИА, которое называют сильным, в соответствии с котором ИА рассматривается как система при описании внутреннего состояния и процессов переработки информации которой используются так называемые ментальные категории, такие как знания, убеждения, желания, цели, намерения, планы, обязательства и т. п. Наиболее существенной особенностью ИА является способность осуществлять целенаправленное поведение в открытых, динамических и неопределенных мирах. Открытые миры, в отличие от замкнутых, не позволяют на этапе проектирования агента исчерпывающе полно описать среду его функционирования. Динамичность мира означает постоянное изменение его состояния. Источниками изменений быть как нецеленаправленные динамические объекты, так и целенаправленные сущности (другие агенты). Неопределенность означает принципиальную невозможность для агента исчерпывающе полно и точно идентифицировать состояния мира. По типу среды функционирования выделяют программные и физические агенты. К программным агентам относятся агенты, функционирующие в информационном пространстве. Физические агенты действуют в физических средах (автономные роботы, беспилотные ЛА и т. п.) и в процессе функционирования непосредственно воздействуют на окружающую их физическую среду. Многоагентную систему определим как совокупность интеллектуальных агентов, взаимодействующих в процессе своей деятельности. С учетом специфики ИА, как целенаправленных систем, в качестве основы для классификации МАС целесообразно рассматривать типы отношений между агентами в МАС. Можно выделить следующие типы отношений: полная согласованность (когерентность) целей: сотрудничество на основе взаимной выгоды, нейтральность, конкуренция, антагонизм. Полная согласованность целей агентов имеет место, если МАС изначально создается для решения общей задачи. В этом случае агенты не имеют собственных целей и намерений, отличных от целей МАС в целом. Состав и организационная структура (распределение ролей между агентами) таких МАС, как правило, определяются на этапе их проектирования, однако, при необходимости могут меняться в процессе функционирования. Отношение кооперации (сотрудничества) имеет место, когда агенты изначально имеют собственные цели, однако в процессе функционирования приходят к заключению о целесообразности сотрудничества. При ведении переговоров используются различные протоколы. Нейтральными по отношению к некоторому агенту являются агенты, не оказывающие никакого влияния на реализацию его целенаправленного поведения и, как следствие, не представляющие для него интереса. Конкуренция между агентами в МАС возникает в ситуациях, когда нескольким агентам в процессе их функционирования требуется один и тот же ресурс. Под ресурсом понимается любая сущность (физическая или виртуальная), необходимая агенту для реализации его планов. Проблемные области, в которых между агентами имеет место отношение конкуренции можно разделить на два типа: области, конкурентные по своей сути, области, в которых отношение конкуренции возникает ситуативно в процессе функционирования. Для проблемных областей первого типа отношение конкуренции между агентами является неотъемлемой характеристикой. В качестве механизма разрешения конфликтных ситуаций, как правило, используются переговоры. Антагонистические отношения имеют место в системах, в которых агенты изначально создаются для противодействия другим агентам. К таким МАС относятся системы военного назначения: коллективы боевых роботов, беспилотные летательные аппараты и т. п. С точки зрения уровня интеллекта, выделяют следующие типы агентов: реактивные, обдумывающие решения и гибридные. Реактивные агенты реализуют рефлекторный тип поведения, т. е. функционируют по принципу «ситуация–действие». Агенты, обдумывающие решения, используют явные символьные модели окружающего мира и принимают решения, используя процедуры поиска в пространстве состояний, планирования действия и прогнозирования будущих состояний мира. Гибридные агенты представляют собой комбинацию двух указанных выше типов. В функциональном отношении ИА представляют собой многоуровневые системы, включающие уровни реактивного поведения, оценки ситуации, прогнозирования, планирования автономных и кооперативных действий. В ряде работ архитектуры агентов классифицируются на основе анализа связей функциональных уровней агента с подсистемой восприятия и исполнительными подсистемами. В соответствии с этим подходом выделяют горизонтально и вертикально организованные архитектуры. В горизонтально организованной архитектуре все уровни агента имеют непосредственный доступ к уровню восприятия и действий. В вертикально организованной архитектуре доступ к подсистеме восприятия и исполнительным подсистемам имеет только один уровень, а остальные могут взаимодействовать только со смежными уровнями. В [54] выделено пять типов архитектур ИА: простая реактивная архитектура, реактивная архитектура с моделями, управляемая целями архитектура; архитектура, основанная на полезности, и архитектура обучающегося агента. В простой реактивной архитектуре все знания агента представлены набором продукционных правил вида «Если <ситуация>, то <действие>», а все решения принимаются по схеме «стимул-реакция». При функционировании агента в сложных средах решение должно приниматься с учетом хранимой в его памяти предыстории. Кроме того, агент должен обладать знаниями (моделями), позволяющими ему прогнозировать развитие мира и возможные результаты собственных действий. Такие возможности реализованы в архитектуре с использованием моделей. Однако в данной архитектуре предыстория и ожидаемые результаты действий используются лишь на этапе идентификации ситуации. Выбор решений по-прежнему осуществляется с помощью продукционных правил по ситуационному принципу, поэтому данная архитектура по своей сути остается реактивной. В рассмотренных выше архитектурах цели функционирования агента не зафиксированы явно в его памяти, т. е. неизвестны ему. При функционировании в открытых средах цели могут динамически меняться, поэтому в архитектуре необходим механизм гибкого учета текущей цели. Архитектура, управляемая целями, использует явно представленные в памяти агента цели. Целенаправленные действия агента в сложных средах, как правило, требуют планирования – построения последовательностей шагов, направленных на достижение целевого состояния. При этом в общем случае в каждой ситуации существует не единственный возможный план действий. Поэтому агент должен оценивать и сравнивать эффективность различных вариантов действий с учетом их полезности. Архитектура обучающегося агента в дополнение к основному реализующему компоненту содержит обучающий компонент, компонент критики и генератор проблем. В качестве формальных моделей ИА, как правило, используются различные модальные логики. ИА, как интенсиональные системы, описываются в терминах ментальных состояний агента: убеждения, намерения и т. п. К знаниям относят постоянные знания агента о себе и внешнем мире (включая других агентов), которые остаются неизменными на протяжении всего жизненного цикла агента. Убеждения (мнения) – это знания агента, которые могут меняться в процессе его функционирования. Желания – состояния мира (включая самого агента), достижение которых агент считает для себя желательным. Цели – состояния мира (включая самого агента), к которым агент стремится в данный момент времени. Отличие целей от желаний состоит в том, что желания могут быть противоречивыми и агент, зная об этом, не ставит себе целью осуществить все желания. Намерения – действия, которые агент собирается выполнить для достижения своих целей или в силу взятых на себя обязательств. Планы являются, по существу, синонимом намерений и представляют собой последовательность действий, переводящих агента из текущего состояния в целевое. Обязательства – задачи, которые агент берет на себя в рамках кооперации с другими агентами по их просьбе, поручению или в результате реализации переговоров о координации совместных действий (сотрудничестве). Классическая логика предикатов первого порядка не позволяет адекватно работать с рассмотренными выше ментальными категориями. В конце 80‑х и в начале 90-х годов было разработано значительное число агентных систем и инструментальных средств для их разработки [55, 56]. Для стандартизации агентных технологий в 1996 г. была создана международная организация FIPA (Foundation for Intelligent Physical Agents), поставившая целью разработку открытых спецификаций, поддерживающих взаимодействия разнородных агентов и агентных сервисов [57], которая играет ключевую роль в разработке стандартов МАС. Эталонная модель управления агентами FIPA определена как множество логических компонентов, предоставляющих набор возможностей, которые могут комбинироваться в физических реализациях агентных платформ. Агентная платформа определяет инфраструктуру, в которую могут быть помещены программные агенты. Согласно спецификации FIPA агентная платформа включает три основных компонента: систему управления агентами (Agent Management System, AMS), службу каталогов (Directory Facilitator, DF)и службу транспортировки сообщений (MessageTransportService,MTS). Структура агентной платформы по FIPA представлена на рис. 3.21. Система управления агентами (AMS) представляет собой системного агента, управляющего доступом к агентной платформе и ее использованием. AMS является обязательным компонентом агентной платформы и обеспечивает два ее базовых сервиса: сервис жизненного цикла агентов и сервис «белых страниц» (поиск агентов по именам). На каждой платформе может существовать только один AMS. Для выполнения своих функций AMS поддерживает каталог идентификаторов агентов (AID) и базу данных состояний агентов. Каждый агент должен зарегистрироваться у AMS, чтобы получить свой уникальный AID. Рис. 3.21. Структура агентной платформы по FIPA Агенты Система управления агентами Служба транспортировки сообщений  Агентная платформа 1 Стороннее ПО Служба каталогов     Служба транспортировки сообщений Агентная платформа 2 Служба каталогов предоставляет агентам сервис «желтых страниц» и не является обязательным компонентом агентной платформы. Агенты могут регистрировать свои сервисы и выполнять поиск в службе каталога с целью найти агента, предоставляющего заданные сервисы. Службы каталогов могут объединяться в федерации, при этом на одной агентной платформе может существовать несколько таких служб. Служба транспортировки сообщений – программный компонент, управляющий всеми обменами сообщениями как внутри данной платформы, так и с удаленными платформами. Поддерживает заданный по умолчанию метод коммуникации между агентами на различных агентных платформах. Основным «действующим лицом» на агентной платформе является агент. Он реализует одну или более сервисных возможностей в унифицированной и интегрированной исполнительной модели, которая может включать доступ к внешнему программному обеспечению, людям-пользователям и коммуникационные возможности. Агент должен иметь, как минимум, одного владельца, т. е. обязательно должна быть определена его принадлежность к организации или человеку-владельцу. Агент может поддерживать несколько понятий идентичности. Идентификатор агента (Agent Identifier – AID) однозначно идентифицирует его в рамках универсума агентов. При этом каждый агент может регистрироваться с множеством транспортных адресов, по которым с ним можно контактировать. AID задается расширяемой совокупностью пар «параметр-значение», определяющих его имя, транспортные адреса и адреса сервиса разрешения имен. Обязательным параметром является только имя агента. Агент может выполнять роль брокера ресурсов и обеспечивать доступ к любому (неагентному) программному обеспечению. Особенности реализации агентной платформы определяются разработчиками конкретных агентных систем и не являются предметом стандартизации FIPA. Язык агентных коммуникаций FIPA – FIPA Agent Communication Language (FIPA ACL) – разработан на основе теории речевых актов и результатов, полученных в проекте KSE. JADE (Java Agent DEvelopment Framework) [55] – наиболее популярная и быстро развивающаяся агентная платформа, разработанная группой специалистов из научно-исследовательского института CSELT и университета г. Парма. Она распространяется в соответствии с лицензией на программное обеспечение с открытым исходным кодом для некоммерческого использования. JADE реализована на языке Java и предоставляет набор системных сервисов агентной платформы, соответствующих спецификациям FIPA: систему управления агентами, службу каталогов и систему транспортировки сообщений. Общение агентов осуществляется путем посылки сообщений на языке FIPA ACL. Агентная платформа может быть распределена между несколькими хостами, при этом на каждом хосте исполняется только одно Java-приложение (и, следовательно, только одна виртуальная Java-машина JVM). Каждая JVM обеспечивает среду параллельного исполнения нескольких агентов В базовом варианте каждый агент исполняется в собственном потоке вычислений (thread), однако агенту часто необходимо выполнять параллельные задачи. Поэтому помимо многопоточности, предоставляемой самим языком Java, JADE также поддерживает планирование поведения (задач) агента. Агентная платформа предоставляет пользователю графический интерфейс (GUI) для удаленного управления и мониторинга состояния агентов, позволяющий создавать, запускать на исполнение, останавливать и перезапускать агентов. Согласно подходу FIPA, стандартизации подлежит только внешнее поведение компонент системы. Детали реализации и внутренняя архитектура определяются самими разработчиками мультиагентных систем. Поэтому модель агента в JADE является достаточно общей и позволяет разработчикам реализовывать различные архитектуры агентов (реактивные, BDI-типа и др.). Следует заметить, что мультиагентные технологии хотя и медленно, но начинают внедряться в реальные системы. При этом они все чаще рассматриваются не только как системы искусственного интеллекта, но и как стиль программирования [56]. |