страница 1
|
|||||||||||||||||||||||||||||||||||||||||||
Похожие работы
|
Кузнецов Кирилл Олегович Облачная мультиагентная платформа на основе jade и Google - страница №1/1
САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Математико-механический факультет Кафедра системного программирования Кузнецов Кирилл Олегович Облачная мультиагентная платформа на основе JADE и Google App Engine Магистерская диссертация Допущена к защите. Зав. кафедрой: д.ф.-м.н., проф. А.Н. Терехов Научный руководитель: к.ф.-м.н., Д.Ю. Бугайченко Рецензент: к.ф.-м.н., доц. И.П. Соловьев Санкт-Петербург 2013 SAINT-PETERSBURG STATE UNIVERSITY Mathematics & Mechanics Faculty Chair of Software Engineering Kirill Kuznetcov Cloud multi-agent framework based on JADE and Google App Engine Master’s Thesis Admitted for defence. Head of the chair: Professor A.N. Terekhov Scientific supervisor: PhD D.Y. Bugaychenko Reviewer: PhD I. P. Soloviev Saint-Petersburg 2013 Содержание1 Введение 4 2 Постановка задачи 8 3 Обзор предметной области 9 3.1 Мультиагентная система 9 3.2 Стандарты FIPA 12 3.3 JADE 15 3.4 Архитектура JADE 17 3.5 Облачные сервисы 20 3.6 Анализ поставщиков облачных услуг 24 4 Особенности реализации 28 4.1 Ограничения Google App Engine 28 4.2 Интеграция JADE 30 4.3 Проблемы 33 4.4 Демонстрационная система 34 5 Заключение 37 1ВведениеВ настоящее время существует множество мультиагентных систем, которые решают задачи в самых разных областях: поиск (как интеллектуальный так и обычная аггрегация), логистика, транспорт, моделирование, телекоммуникации[13,14]. Мультиагентные системы представляют собой парадигму распределенных вычислений, которая основана на взаимодействии множества интеллектуальных агентов[1]. Они часто применяются для решения проблем используя децентрализованный подход, когда несколько агентов вносят свой вклад в общее решение кооперируясь друг с другом. Одно из ключевых полезных свойств агентов — это интеллектуальное поведение, которое может быть заложено в каждого из них в соответствии с общим подходом к решению задачи, в рамках которого требуется взаимодействие многих агентов, работающих параллельно на одной или нескольких машинах одновременно. Многие мультиагентные системы должны динамически адаптироваться к изменяющейся (особенно часто — возрастающей) нагрузке и увеличивающимся объемам данных. С добавлением новых агентов, помимо затрат на их обслуживание, увеличивается также число возможных коммуникаций для уже существовавших ранее агентов. В качестве примера можно рассмотреть систему управления логистикой для перевозок грузов. Есть множество агентов соответствующих транспортным средствам — грузовикам самолетам, баржам - и грузам. В системе постоянно появляются новые грузы, которые нужно доставить оптимальным образом, изменяется состав активных участников логистической цепочки. В случае развития сети доставки или при появлении новых участников, не пользовавшихся системой ранее, необходимо адаптироваться к новым, возрастающим требованиям к ресурсам. Требуемые машинные мощности, а также хранилище достаточных объемов могут быть представлены вычислительным облаком[3,4]. Системы облачных вычислений предоставляют хорошо масштабируемые инфраструктуры для высокопроизводительных вычислений, которые динамически адаптируются к нуждам пользователя и приложения. На данный момент облака по большей части используются для обеспечения интенсивной вычислительной нагрузки и для предоставления больших объемов для хранения данных. И обе этих цели сочетаются с третьей: потенциально снизить издержки на администрирование и использование приложений, т. к. эти издержки берет на себя облако. Облачная модель вычислений естественным образом подходит для систем с нерегулярной нагрузкой, например:
Агентно-основанные приложения могут использовать облачную инфраструктуру, чтобы использовать огромное число процессоров и обрабатывать значительные объемы данных[4]. Такой подход позволит переложить серьёзные вычисления на плечи служебных процессов и элементов хранилища в облаке. Целая система или её наиболее загруженная часть может быть размещена в облаке, тогда как «легковесные» части системы могу выполняться на локальном сервере или на клиентской машине. Это позволит повысить эффективность агентов, а также может сделать их легче и умнее. Это достигается при помощи производительных мощностей облака, которые могут повысить «интеллект» агентов за счет использования более сложных алгоритмов или повышенной точности. При этом, агенты смогут адаптироваться к доступным виртуальным машинам, используют такие свои базовые свойства как автономность, проактивность, способности к переговорам и обучению. Таким образом, программные агенты могут быть размещены в облаке, чтобы улучшить их гибкость и адаптируемость, повысить автономность в использовании ресурсов, предоставлении услуг и выполнении крупномасштабных приложений. В этой работе представлена попытка реализовать платформу для выполнения мультиагентных систем на базе JADE – одной из самых известных и используемых в настоящее время мультиагентных платформ — в облаке. А также преимущества такого синтеза показаны на примере простейшей логистической системы, которая запущена в получившейся облачной платформе. 2Постановка задачиЗадача данной работы состоит в том, чтобы разработать платформу для выполнения агентов на базе JADE, работающую в облаке
3Обзор предметной области3.1Мультиагентная системаМультиагентая система представляет собой совокупность нескольких автономных сущностей, существующих и взаимодействующих в общей среде – программных интеллектуальных агентов[1, 20]. Агент автономно существует в рамках некой внешней среды, он может обмениваться с ней информацией, совершать определенные действия, но при это не может управлять состоянием среды. Для каждого агента определен некоторый круг целей, которые он старается рациональным образом достичь своими действиями. Также агент характеризуется несколькими ключевыми свойствами:
Несмотря на то, что агент сам по себе может существовать и действовать для выполнения поставленной задачи, большая эффективность достигается при работе в группе агентов, которые кооперируются друг с другом для получения информации, делегирования решения определенных задач – мультиагентной системе. Мультиагентным системам присущи следующие характеристики:
Мультиагентные системы используются в задачах, где методы централизованного решения менее эффективны. Это такие задачи, как например: логистика, моделирование, сбор и обработка информации, управление сложными автоматизированными системами и т.д. За последние годы появилось множество инструментариев, поддерживающих различные агентные архитектуры и предоставляющие библиотеки для протоколов взаимодействия: Jason [10], SPADE [17], JADE[9], Cougaar[12], Jadex[11] и т.д. Были приняты стандарты в области мультиагентных систем, такие как KQML (Knowledge Query and Manipulation Language)[21], который изначально создавался для экспертных систем, позже был принят и в области мультиагентных технологий, и FIPA[6]. Эти технологии создавались для использования в традиционных вычислительных системах и на текущий момент существует не так много исследований на тему интеграции мультиагентных систем и облачных вычислений. 3.2Стандарты FIPAВ 1996 году в Швейцарии была создана некоммерческая организация FIPA ( Foundation for Intelligent Physical Agents) . Целью создания этой организации была разработка стандартов для мультиагентных систем. Эти стандарты специфицируют то, как агенты должны существовать в системе, коммуницировать и взаимодействовать между собой[6]. А также, стандарты коснулись реализации систем, в которых агенты могли бы выполняться и действовать - агентных платформ(AP). Для таких платформ были специфицированы три выделенных служебных роли агентов:
Рис.1: Архитектура FIPA Также стандарты описывают язык общения между агентами - FIPA Agent Communication Language (ACL), однако только синтаксис и семантику, реализация этого языка не специфицирована. Помимо этого, спецификации FIPA описывают протоколы взаимодействия агентов. Наиболее известен FIPA Contract Net - он применяется для выбора агента-поставщика необходимого сервиса среди нескольких кандидатов. 3.3JADEJADE ( Java Agent Development framework) – это один из самых распространенных инструментов для создания мультиагентых систем, изначально созданный в Telecom Italia[5,9]. JADE написан на Java, поэтому является кроссплатформенным, может работать на беcпроводных мобильных устройствах, поддерживает стандарты FIPA и распространяется бесплатно по лицензии LGPL. Как платформа для выполнения интеллектуальных агентов JADE:
3.4Архитектура JADEВ платформе JADE агенты выполняются в контейнерах, которые могут быть распределены по сети. Эти контейнеры представляют собой отдельные Java-машины. Каждый агент – это поток в процессе, соответствующем его контейнеру. На Java-машине контейнера запущен экземпляр среды выполнения JADE и все сервисы, необходимые для хостинга и выполнения агентов. Существует специально выделенный, так называемый, главный контейнер, который представляет собой точку начальной загрузки в платформе. Это первый загружаемый контейнер и все остальные для присоединения к платформе должны регистрироваться с помощью главного контейнера. Будучи точкой начальной загрузки, главный контейнер отвечает за:
Как уже было сказано выше, в системе общение агентов друг с другом, и служебных и рядовых, а также с сервисами платформы осуществляется с помощью сообщений. Для передачи сообщений в JADE существует два протокола: Message Transport Protocol (MTP) и Internal Message transport Protocol (IMTP). MTP используется для коммуникации между агентами на разных платформах и реализован в соответствии со стандартом FIPA. Передача сообщений осуществляется по HTTP. IMTP – протокол для общения агентов внутри одной платформы JADE. IMTP допускает различные реализации, так изначально в JADE представлены две версии: первая использует Java Remote Method Calling (технологию взаимодействия с объектами, находящимся на другой Java-машине, по сети), вторая реализация создана для мобильных устройств и предназначена для работы с Java ME. Можно привести типичный пример развертывания определенной мультиагентой системы разработанной с использованием JADE: платформа включает в себя все агенты выполняющиеся на вычислительных мощностях какого-то дата-центра, а контейнеры в платформе соответствуют различным машинам, находящимся в этом дата-центре. Рис.2: Архитектура платформы JADE 3.5Облачные сервисыНациональный институт стандартов и технологии (National Institute of Standard and Technology - NIST) дает следующее полное определение: “Облачные вычисления это модель предоставления повсеместного и удобного сетевого доступа с оплатой за использование по мере необходимости к общему пулу конфигурируемых вычислительных ресурсов (например, сетей, серверов, систем хранения, приложений и сервисов), которые могут быть быстро предоставлены и освобождены с минимальными усилиями по управлению и необходимостью взаимодействия с провайдером услуг.” Облако состоит из группы соединенных между собой и виртуализированных компьютеров, которые выделяются динамически и предоставляются пользователю Ключевые свойства, которые выделяют облачные вычисления от традиционных подходов, были определены в [22] и обычно содержат следующие:
Более того, согласно NIST, существует три категории способов предоставления облачных сервисов, которые описывают различные степени доступности ресурсов облака:
Облачные вычисления являются результатом недавнего продвижения нескольких технологий[4] как со стороны аппаратного обеспечения (виртуализация и многоядерные архитектуры), так и со стороны программного обеспечения – это кластерные вычисления, грид-вычисления, веб-сервисы, сервисно-ориентированные архитектуры (Service Oriented Architectures - SOA), автономные вычисления и хранилища данных большого объема. В частности, для организации вычислительного облака виртуализация является ключевым элементом, который отделяет функциональность и реализацию системы от физических ресурсов. Инфраструктура облака может быть разбита на несколько виртуальных машин, которые динамически конфигурируются в соответствии с требованиями пользователя и должны выполнять независимые приложения одновременно. Виртуализация отделяет приложения от железа и пользователей друг от друга, давая им ощущение того, что вычислительная инфраструктура полностью соответствуют их приложениям за счет того, что поддерживает заданное качество услуг (QoS). Также, виртуализация используется для того чтобы изолировать приложения. Это позволяет избежать того, что отказ в работе одного приложения вызовет отказ в работе другого. Наконец, виртуализация – это способ повысить безопасность и конфиденциальность одновременно работающих в облаке приложений. 3.6Анализ поставщиков облачных услугВ настоящее время услуги облачных сервисов представлены многими компаниями, это и такие тяжеловесы индустрии программного обеспечения, как Microsoft с их Windows Azure[18], и интернет-гиганты, такие как Google, представившие в 2008 году Google App Engine, и Amazon. Amazon в 2005 году первыми начали предоставлять облачные сервисы с помощью Amazon Elastic Compute Cloud (Amazon EC2). Сейчас EC2 входит в платформу Amazon Web Services. Помимо крупных компаний на рынке также присутствуют поставщики облачных сервисов поменьше: Rackspace, GoGrid[8], платформа Force.com компании Salesforce[7] и другие. Облачные провайдеры в достаточной степени отличаются друг от друга - предоставляют различные сервисы в облаке, модели оплаты, уровни поддержки, надежности, гибкости использования, а также варьируются другие характеристики[3,15]. Поэтому при выборе потенциального поставщика облачных услуг для переноса мультиагентной платформы в облако необходимо четко представлять себе, какие требования должны быть предъявлены используемому сервису, какие он представляет какие возможности, какими свойствами обладает и как может быть сконфигурирован для нужд интеграции. Ниже будет представлен анализ наиболее популярных облачных сервисов – это уже упоминавшиеся выше: Windows Azure, Amazon Web Services, Google App Engine, Rackspace, GoGrid и Force.com. Для сравнения были выбраны следующие характеристики:
Windows Azure поддерживает только C#, PHP и VB.NET, поэтому для интеграции с JADE этот сервис не подходит. Все остальные провайдеры так или иначе поддерживают Java. Amazon Web Services, Rackspace и GoGrid – предоставляют доступ к своим ресурсам как IaaS. Что фактически означает, что разработчику предоставлена выделенная виртуальная машина, на которой клиент может делать практически все угодно, как и на локальной машине. При этом у сервисов PaaS – Google App Engine и Force.com - есть неоспоримое и очень важное преимущество – облако берет на себя организацию масштабирования. В частности, Google App Engine делает это автоматически, в зависимости от динамики обращений к серверу, наиболее безболезненно для пользователя облачного сервиса. Также PaaS-облака значительно упрощают обновление размещенного в облаке приложения, в то время как IaaS-облака никаким образом не заботиться об этом[3, 15, 19]. Если рассмотреть доступные ресурсы облака:
Говоря о доступности приложения GoGrid, Rackspace, и Google App Engine обеспечивает 100% бесперебойного времени работы, Force.com 99.9+ % и AWS - 99,9 – 99,95%, в зависимости от конкретного сервиса[16]. Если рассмотреть ценовую политику, то тут важно сказать, что Google App Engine единственный предоставляет бесплатный доступ к сервису, не ограниченный по времени, только по используемым ресурсам - это очень важно, так как разработчику необходим доступ к облаку, как минимум, для тестирования приложения. Force.com предоставляет бесплатный пробный доступ к ресурсам на 30 дней, однако такой вариант тоже мешает разработке. Остальные провайдеры предоставляют свои услуги исключительно за деньги. И, наконец, упоминая о поддержке системы Google App Engine имеет наиболее широкую информационную поддержку – сайт с полным описанием возможностей и документацией - https://developers.google.com/, официальное сообщество (http://appengine.community.com), где есть обучающие примеры и другая полезная информация, не представленная в документации, интернациональный блог разработчиков – http://googleappengine.blogspot.com. Остальные поставщики сервисов ограничиваются только официальными сайтами. Таким образом, подводя итог, можно сказать что Google App Engine является безусловным лидером по большинству выбранных критериев оценки. И его использование для интеграции с JADE обосновано. 4Особенности реализации4.1Ограничения Google App EngineGoogle App Engine предоставляет собой PaaS, т.е. фактически имеет свою среду выполнения Java. И, поскольку это не обычная Java-машина, на приложения размещаемые в облаке GAE накладываются определенные ограничения. Одно из ограничений - это отсутствие возможности использовать TCP-сокеты, все сообщение по сети в Google App Engine возможно только по HTTP. Как было сказано в обзоре JADE, для передачи сообщений внутри платформы используется одна из реализаций IMTP: Java RMI или, так называемая, LEAP для мобильных устройств. Технология RMI использует TCP-сокеты для осуществления коммуникации с Java-машиной на другом хосте. LEAP реализация выполняет транспорт сообщений при помощи проприетарного протокола, который в свою очередь работает поверх TCP. Таким образом, возник конфликт в интеграции JADE и Google App Engine. Другое важное ограничение – невозможность явно создавать потоки, есть возможности использовать их только для обработки входящих запросов или задач в так называемых очередях (task queues). Время жизни потока, созданного для обработки входящего запроса ограничено 30 секунд, а в случае задачи – это 10 минут. В обзоре JADE упоминалось, что каждый агент – это отдельный поток в процессе Java-машины, где выполняется контейнер платформы, который отвечает за этого агента. Поэтому возможность создавать и уничтожать потоки – критична для работы платформы. Помимо этих ограничений существует еще одно – доступ Java-приложений в среде Google App Engine разрешен на для всех классов стандартной библиотеки Java. Все поддерживаемые классы перечислены в особом списке, который доступен по адресу https://developers.google.com/appengine/docs/java/jrewhitelist?hl=ru. 4.2Интеграция JADEИсходя из описанных в предыдущем пункте проблем естественным образом очертился круг задач, которые необходимо было решить для переноса JADE в облако Google App Engine: необходимо было адаптировать работу RMI, отказавшись от использования TCP-сокетов, найти способ создавать потоки в системе и, наконец, убрать или заменить классы, не поддерживаемые Google App Engine. JADE – чрезвычайно сложная система, изменения отдельных частей могут повлечь ошибки в работе других. По этой причине при внесении изменений желательно максимально отделить части, которые должны быть переделаны, от остальной системы. Поэтому для всех классов, использование которых в облаке было невозможно, был проведен тщательный рефакторинг. По возможности, были выделены интерфейсы, а в некоторых случаях надклассы. В дальнейшем, другой частной реализацией стали классы, созданные для работы в облаке. Таким образом, была частично перепроектирована классовая иерархия JADE. Также, был добавлен менеджер, задачей которого стал выбор конкретной реализации интерфейса, в зависимости от того, где необходимо было запустить систему – в облаке или на локальной машине. Помимо стандартного варианта размещения приложения в Google App Engine так же возможно использование так называемых бэкэндов (backends). Использование бэкэндов позволяет получить доступ к большим объемам памяти, большей вычислительной мощности, и что самое главное, допускают использование потоков. Собственно, конфигурация бэкэнда определяет набор виртуальных машин, для размещения экземпляров клиентского приложения, описывая требуемый класс мощности и число экземпляров, которые нужно запустить. У такого способа есть свои недостатки – необходимо большее вмешательство разработчика для масштабирования приложения, сложности связанные с отладкой (это будет рассмотрено подробнее). Однако, Для устранения проблем с IMTP на первой стадии работы было принято решение для начала добиться запуска JADE в режиме “один контейнер на один экземпляр JADE”, а затем перейти к использованию HTTP для транспорта сообщений вместо RMI и TCP. Стоит отметить, что, как выяснилось в процессе работы над адаптированием протокола для работы в Google App Engine, в локальная передача сообщений в рамках одного контейнера тоже происходит с использованием текущей реализации IMTP – RMI, от которой было решено отказаться, в связи с чем пришлось осуществить переработку вертикальной (т.е. в рамках одного узла протокола) цепочки обработки сообщений и команд, отделив необходимую часть от Java RMI. Для совместимости с Google App Engine был осуществлен рефакторинг платформы. Из структуры были аккуратно удалены части, связанные с RMI и LEAP реализациями IMTP, поскольку по большей части их все равно не возможно было использовать. Так же была удалена поддержка инструментов отладки – поскольку на текущий момент их невозможно было бы использовать в облаке. Обратная интеграция этих инструментов может стать одной из возможных дальнейших задач развития платформы – например, можно настроить сообщение агентов отладчиков находящихся на локальном компьютере с платформой, работающей в GAE, или же реализовать специальные веб-интерфейсы для работы прямо в облаке. Поскольку JADE использует GUI, созданный с помощью Java Swing, который не поддерживается GAE, эта часть была полностью исключена из плафтормы, тем более что не было никакой необходимости её сохранять. Таким образом, в процессе осуществления описанных выше действий из JADE было удалено большинство классов, не входящих в “белый список” Google App Engine. Однако некоторые конфликты все же остались, в этих случаях классы получилось заменить на поддерживаемые аналоги, в некоторых случае это были классы из той же иерархии, но, например на ступень выше. Так, например, были сделано для классов логгирования в системе. 4.3ПроблемыВ процессе работы над интеграцией JADE и Google App Engine существовали две основные проблемы, замедлявшие процесс. Первая из них – отсутствие возможности полноценной отладки приложения в среде разработки. Набор инструментов разработки для GAE (Software Development Kit - SDK) включают в себя тестовый сервер приложений, однако он не поддерживает запуск backend-экземпляров. Таким образом вся отладка осуществлялась при помощи работы с логами в приложении. Каждая итерация отладки занимала длительное время, поскольку требовалось полностью разместить приложение в облаке, а результат такой итерации был гораздо менее информативным чем в обыкновенном отладчике, так как не было возможности в процессе работы проследить интересующие особенности поведения или состояние данных в программе. Другой проблемой была скудная документированность внутреннего устройства достаточно сложной платформы и IMTP. Платформа и протокол спроектированы и использованием нескольких уровней абстракции и единственным источником информации о внутренней структуре служил сам код. 4.4Демонстрационная системаОдна из наиболее типичных задач, которые решают мультиагентные системы – это задачи управления логистикой транспортных перевозок. Как было сказано в начале, перенос в облако наиболее актуален для систем с нерегулярной нагрузкой. Интенсивность перевозок зависит от числа заказов (может отличаться днем и ночью, в выходные и будние дни), нагруженности транспортных путей и других факторов. Помимо этого для логистических систем вполне возможно разрастание – если система работает хорошо, показывает свою эффективность в решении поставленной задачи, большее число клиентов захочет её использовать, что, в свою очередь, увеличит число агентов. Для проверки работоспособности получившейся в результате платформы необходимо было использовать тестовую мультиагентную систему. Все вышесказанное позволило в качестве тестовой предложить простейшую систему для управления логистикой. Так как система используется для тестовых целей, она достаточно простая. В системе существует три вида агентов:
Процесс происходит следующим образом: агент оператор создает случайно сгенерированную задачу. И затем начинаются переговоры по алгоритму Contract Net: агент оператор посылает запрос на предложение (call for proposal) с данными задачи, транспортные агенты, получившие запрос, предлагают свою “цену” перевозки – в данном случае “цена” отражает только время, за которое задача будет выполнена, и объем топлива, которое будет потрачено. Оператор выбирает того транспортного агента, чье предложение оказалось для него наиболее выгодным и посылает ему подтверждение, остальным агентам приходит ответ с отказом. Затем победитель принимает задачу, посылая соответствующее сообщение оператору и после того, как задача выполнена, сигнализирует об этом агенту, выдавшему задание. На рис. 2 представлена диаграмма взаимодействия. Рис. 3: Взаимодействие агентов в демонстрационной системе 5ЗаключениеВ рамках этой работы были достигнуты следующие результаты:
Список литературы
pp.79-92, 1998.
|
|