close

Вход

Забыли?

вход по аккаунту

?

8142.Разработка многоагентной платформы для распараллеливания ресурсоемких задач

код для вставкиСкачать
УДК 004.75
В.В. АНДРЕЕВ, Э.В. ШОГУЛИН
РАЗРАБОТКА МНОГОАГЕНТНОЙ ПЛАТФОРМЫ
ДЛЯ РАСПАРАЛЛЕЛИВАНИЯ РЕСУРСОЕМКИХ ЗАДАЧ
На сегодняшний день имеется огромное количество самых различных ЭВМ.
Если рассматривать суммарную вычислительную мощность всех ЭВМ, то получится единый огромный вычислительный ресурс, который можно было бы
использовать для решения задач. В связи с этим проводятся исследования, направленные на поиск решения, позволяющего в рамках существующих технологических решений объединить множество ЭВМ так, чтобы использовать их
как одну виртуальную ЭВМ. Тогда специализированные приложения, требующие значительных вычислительных ресурсов, работали бы на этой виртуальной ЭВМ гораздо быстрее, чем на отдельной ЭВМ, за счет параллельного
выполнения различных участков программного кода на различных физических ЭВМ. Исследования показали, что задача разбивается на две основные
подзадачи:
− приложение необходимо разделить на параллельно выполняющиеся части;
− обеспечить доставку и запуск каждой части приложения на выбранную
для неё ЭВМ из совокупности ЭВМ, образующих виртуальную, а также возврат результата её работы.
На данный момент нами реализована часть платформы, позволяющая
портировать агенты на удаленные ЭВМ и запускать их на выполнение. Задача
по доставке и запуску каждой части приложения усложняется тем, что единственной возможностью связи множества различных ЭВМ является глобальная
сеть Интернет. Необходимо преодолевать такие недостатки этой сети, как ненадежность передачи данных, медленная скорость доступа, дороговизна и
безопасность.
Под агентом понимается участок программного кода, реализующий некоторую законченную функциональность и оформленный в виде класса. Агенты
создаются специалистами (программистами), реализующими вычислительный
алгоритм по следующей технологии. Объявляется класс, который должен быть
пронаследован от имеющегося в платформе родительского. Для разделения выполнения различных частей кода по разным ЭВМ используется перегрузка в
разрабатываемом агенте виртуальных методов родительского класса. Части
платформы, расположенные на различных ЭВМ, получают агента и запускают
разные его методы. Таким образом, разные участки кода агента выполняются на
различных ЭВМ. Никакой дополнительной функциональности для реализации
портирования конечным программистом не требуется.
Решение рассматриваемой задачи нашло бы коммерческое применение, позволив компаниям сдавать свои вычислительные ресурсы в аренду. Кроме этого,
на базе виртуальной ЭВМ можно создать единое информационное пространство
между различными системами, разделенными между собой огромными расстояниями. Например, если ранее приложение могло работать только с локальными данными, находящимися на той же ЭВМ, на которой оно выполняется, то
при выполнении на виртуальной ЭВМ участки кода будут выполняться параллельно на различных ЭВМ. Это позволит приложению использовать данные,
находящиеся на удаленных ЭВМ, без изменения самого приложения. Это решение стирает физические границы между различными ЭВМ.
Многоагентная платформа построена на платформе .NET, в виде Win32
приложения и XML Web Service.
Используемые термины. Агент (agent). Под агентом понимается логическая сущность, которая обладает некоторой автономностью. В компьютерных
науках под агентом понимается сущность, которая объединяет данные, код, и
способна перемещаться между различными окружениями. Как правило, если
не оговорено иное, в окружении выполняется код агента.
Платформа (platform). Под платформой понимается программная платформа.
Хост (host). Под хостом понимается Web сервис, способный работать с
агентами.
Портирование. Под портированием понимается создание платформой копии агента и запуска этой копии. Сам по себе агент не в состоянии портироваться. То есть для портирования необходимо дополнительное окружение. Портирование состоит из нескольких частей: создание копии агента, возможное перемещение созданной копии на другой хост и запуск метода агента.
Создание копии агента. Созданная копия идентична оригиналу.
Перемещение агента. Портирование может осуществляться на тот же
хост. В этом случае перемещение может и не происходить.
Запуск метода агента. После перемещения запускается метод агента.
При портировании может запускаться тот же метод. Необходимо обратить
внимание на то, что метод запускается с самого начала, а не продолжает выполняться там, где он был прерван портированием.
Каким образом будет происходить портирование, задаётся типом агента.
Тип агента определяется при его запуске. Один и тот же агент может быть запущен под разными типами.
Управляющее приложение. Под управляющим приложением понимается
приложение (Web-приложение), взаимодействующее с конечным пользователем
и предназначенное для управления пользователем многоагентной платформой.
Дистрибьютер хостов (host distributor). Под дистрибьютером хостов понимается Web сервис, хранящий информацию обо всех доступных хостах.
Менеджер сборок. Под менеджером сборок понимается Web сервис,
предназначенный для управления сборками агентов.
Сборка агента. Под сборкой агента понимается сборка, содержащая агента.
Создание простейшего агента. Для создания простейшего агента достаточно создать в MS VisualStudio 2005 новый проект «Class Library», добавить в раздел «Reference» сборку “Map.Data.dll” и создать класс, пронаследованный от
«Map.Data.Agent». Ниже приведен исходный код простейшего агента.
using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using Map.Data.Agents;
namespace Map.Data.Agents.Calculation
{
/// <summary>
/// Summary description for CalculationAgent.
/// </summary>
[Serializable]
public class CalculationAgent: Agent
{
#region private
private Object Function1(Object param)
{
Thread.Sleep(60000);
return "Function1 result";
}
private Object Function2(Object param)
{
Thread.Sleep(40000);
return "Function2 result";
}
private Object Function3(Object param)
{
Thread.Sleep(20000);
return "Function3 result";
}
#endregion
public override Object Run(Object param)
{
FunctionEvent functionEvent1 = StartThread(
new RunFunctionHandler(Function1));
FunctionEvent functionEvent2 = StartThread(
new RunFunctionHandler(Function2));
Object functionEvent3Value = Function3(null);
Wait(functionEvent1, functionEvent2);
return Convert.ToString(functionEvent1.Value) +
Convert.ToString(functionEvent2.Value) +
Convert.ToString(functionEvent3Value);
}
public override void Stop()
{}
}
}
Здесь функциональную нагрузку несут методы «Function1», «Function2» и
«Function3». Все три метода выполняются параллельно и в зависимости от режима запуска – на различных хостах.
Требования к платформе. Для эксплуатации платформы необходимо
определиться с её функциональностью и оговорить предъявляемые к платформе требования:
− обеспечить распараллеливание на неограниченное количество частей;
− обеспечить доставку распараллеленных частей на различные компьютеры;
− доставка распараллеленных частей не должна зависеть от сетевых протоколов и реализаций;
− обеспечить выполнение распараллеленных частей после их доставки;
− обеспечить взаимодействие агентов.
Рассмотрим каждое из требований более подробно.
Основным требованием к распараллеливанию является прозрачность: разработчик не должен вникать в детали реализации и детали результата операции распараллеливания на потоки и знать, где эти потоки будут выполняться.
Распараллеливание происходит следующим образом:
FunctionEvent functionEvent = StartThread(new
RunFunctionHandler(Method1));
После выполнения строки «Method1» метод будет выполняться параллельно с основным потоком приложения. Таким образом, основной поток распараллелится на несколько потоков, которые могут выполняться на различных
машинах. Количество потоков зависит от типа запуска агента. Этим потоком
можно управлять. Для ожидания завершения потока необходимо использовать
следующий метод:
Wait(functionEvent);
В этом случае поток, вызвавший метод, приостановится и будет ожидать
завершения созданного потока.
Базовые подходы к реализации многоагентных решений. Основными
целями при разработке многоагентной платформы как таковой являются поддержка функционирования агентов и возможность управления агентами. То
есть платформа должна быть максимально понятна как разработчикам агентов, так и конечным пользователям. Под конечным пользователем понимается
пользователь, использующий платформу для работы с существующими агентами. В данном разделе рассмотрены подходы к реализации многоагентных
платформенных решений с точки зрения разработчиков агентов.
Любой разработчик агента, должен реализовать функциональность агента
в одном типе. Для того, чтобы разработчик мог воспользоваться преимуществами многоагентной платформы, он должен уметь с ней взаимодействовать.
Основная архитектурная проблема заключается в определении того, как разработчик агентов будет взаимодействовать с платформой.
Одно из напрашивающихся решений заключается в возможности использования некоторого специального типа, например «MultiAgentPlatform». Тогда
для того, чтобы выполнить некоторую функцию параллельно основному по-
току, необходимо будет вызвать метод этого типа. Например, это могло бы
быть реализовано следующим образом:
MulitAgentPlatform.StartThread(new RunFunctionHandler(Function));
Другое напрашивающееся решение будет заключаться в реализации всех
функций в базовом типе агента – «Map.Data.Agent».
Третьим, и наиболее логичным, на наш взгляд, является реализация
функциональности платформы в отдельном типе, но взаимодействие с этим
типом будет осуществляться через базовый тип агента.
Рассмотрим преимущества и недостатки реализации функциональности
платформы в базовом классе агента.
Преимущества: базовая сущность содержит весь необходимый функционал; разработчик агента должен пронаследовать базовый класс
«Map.Data.Agent»; таким образом, разработчик не должен обладать знаниями
о наличии дополнительных типов для взаимодействия с платформой.
Недостатки: 1) перегруженность функциональности базового класса; 2) базовый класс «Agent» предназначен для реализации агентов, но не части платформы, так как добавление лишней функциональности грозит чрезмерным запутыванием кода и роста его объема; 3) возрастание объема экземпляров агентов.
В последнем случае экземпляр агента содержит информацию, необходимую
не только для функционирования агента, но и для функционирования платформы. Это ведет к возрастанию сетевого трафика и уменьшению быстродействия
при передаче агента между различными процессами или компьютерами.
С учетом всех достоинств и недостатков был выбран третий вариант реализации многоагентной платформы. Таким образом, разработчик должен сосредоточить в разрабатываемом типе всю логику работы агента. Взаимодействие агента с платформой, например, с целью портирования агента на другие хосты,
должно осуществляться вызовом методом базового типа агента
«Map.Data.Agent».
Архитектура. При разработке многоагентной платформы нами поставлена задача сделать архитектуру платформы максимально гибкой и понятной.
Под словами «гибкий» и «понятный» подразумевается, что любые компоненты платформы могут быть замены пользователями и технология их замены
проста и одинакова. Это означает также, что при удалении или неактивности
какого-либо компонента многоагентная платформа сможет далее функционировать, за исключением функциональности удаленного или неактивного компонента. При этом гибкость и понятность архитектуры не должны быть реализованы за счет потери производительности.
Программная платформа .NET, на которой была построена рассматриваемая многоагентная платформа, является компонентно ориентированной. За
счет этого разработчикам удалось добиться преследуемых целей.
Разработанная многоагентная платформа состоит из следующих основных компонентов.
Контроллер менеджера сборок – это компонент, предназначенный для
взаимодействия с менеджером сборок. Любое взаимодействие любых компонентов платформы с менеджером сборок происходит только через него.
Хранилище сборок агентов – это компонент, предназначенный для хранения сборок, содержащих реализацию агентов.
Сборка агента – это компонент, предназначенный для управления сборками агентов на хосте.
Компоненты «Контроллер менеджера сборок», «Хранилище сборок» и
«Сборка агента» относятся к группе компонентов по управлению сборками,
содержащих реализацию агентов. Эти компоненты позволяют портировать
агентов на хосты, на которых отсутствуют сборки, содержащие их реализацию. То есть с помощью этой группы компонентов платформа сама развертывает агента на необходимом хосте при его портировании. Иначе говоря, если
разработчик создал нового агента (или новую версию существующего), то ему
нет необходимости копировать (или заменять в случае создание новой версии)
сборку этого агента на все хосты.
Контроллер агента – это вспомогательный компонент, предназначенный
для управления экземпляром агента. Он реализует функции сериализации и
десериализации копирования, извлечения стека.
Менеджер агентов – это компонент, предназначенный для управления
экземплярами агентов. Он позволяет запускать, останавливать и удалять экземпляры агентов на хосте.
Кэш агентов – это компонент, предназначенный для хранения экземпляров
агентов и созданных для их выполнения потоков. Также этот компонент предоставляет возможность быстрого поиска экземпляра агента и его потока.
Компоненты «Контроллер агента», «Менеджер агентов» и «Кэш агентов»
относятся к группе компонентов по управлению экземплярами агентов.
Контроллер дистрибьютера хостов – это компонент, предназначенный
для взаимодействия с компонентом дистрибьютера хостов.
Дистрибьютер хостов – это компонент, предназначенный для распределения доступных хостов для портирования агента.
Хранилище хостов – это компонент, предназначенный для хранения
имеющихся хостов.
Компоненты «Контроллер дистрибьютера хостов», «Дистрибьютер хостов» и «Хранилище хостов» относятся к группе компонентов, предназначенных для управлениями хостами.
Возможные применения многоагентной платформы. Рассмотрим возможные решения, построенные на базе реализованной многоагентной платформы. Все они основаны на главной особенности многоагентной платформы
– возможности выполнения различных частей программы параллельно на различных хостах.
Сдача вычислительных мощностей в аренду. В этом случае используется
возможность параллельного выполнения различных частей агента на различных хостах с целью использования максимально доступных вычислительных
мощностей и решения задачи с минимальными затратами времени.
Бизнес-приложения. В этом решении используется возможность портирования агента на различные хосты с целью выполнения различных частей агента на различных хостах.
Современные распределенные бизнес-решения являются многозвенными
приложениями с четкими разделениями на определенные звенья: клиент-сервер
приложения и база данных. В основе бизнес-логики таких решений лежат некоторые сущности, которые используются в реальной жизни конечными пользователями. Например, если бизнес-приложение является финансовой системой, то
оно наверняка оперирует такими понятиями, как заказ, счет, клиент. Эти понятия
также известны как бизнес-сущности. Приложение вынужденно работать с ними,
как правило, во всех своих звеньях. Как правило, звенья разделены: клиентская
часть использует сервер-приложения через Интернет, а сервер-приложения обращаются к базе данных через локальную сеть. Таким образом, разработчики вынуждены одни и те же бизнес-сущности реализовывать в различных звеньях. Так,
если в качестве клиента выступает обычное приложение, то это может быть некоторый тип, например Customer. На сервере приложений этот тип будет преобразован в промежуточный тип, например в типизированный DataSet, а на стороне
реляционной базы данных выражен в качестве таблицы.
Многоагентная платформа позволяет реализовать всю логику бизнессущности в одном типе – агенте. В этом случае этот агент будет для разработчика прозрачно портироваться с клиентской части на сервер приложений и
выполняться там. После работы на сервере приложений агент опять же прозрачно для разработчика вернётся на клиента.
АНДРЕЕВ ВСЕВОЛОД ВЛАДИМИРОВИЧ родился в 1964 г. Окончил Чувашский
государственный университет. Кандидат физико-математических наук, заведующий кафедрой телекоммуникационных систем и технологий. Область научных интересов – математическое моделирование и анализ сложных систем, информационные технологии.
Автор более 220 научных работ, в том числе 3 учебных пособий и монографии.
ШОГУЛИН ЭДУАРД ВЛАДИМИРОВИЧ родился в 1982 г. Окончил Чувашский государственный университет. Магистр техники и технологий. Аспирант кафедры телекоммуникационных систем и технологий. Область научных интересов – разработки многоагентных платформ. Автор 5 научных работ.
Документ
Категория
Без категории
Просмотров
4
Размер файла
189 Кб
Теги
платформы, ресурсоемких, разработка, распараллеливания, задачи, 8142, многоагентной
1/--страниц
Пожаловаться на содержимое документа