«Применение ит в системах Мобильных агетов»

Вид материала

Реферат

Содержание Глава 4.Разработка информационной системы Требования к системе Постановка задачи Классическое решение График 4.1 – Результаты Решение на основе мобильных агентов

Подобный материал:

• Market leadership in the 3 g market, 117.72kb.
• И. А. Терейковский Применение семантического анализа содержимого электронных писем, 279.31kb.
• Рабочая программа по дисциплине Моделирование и эксперимент (гпо 2 ) Для специальностей, 155.7kb.
• 4. Применение систем управления базами данных (субд) в современных системах обработки, 431.02kb.
• 2011 г. Вопросы, 73.31kb.
• Отзыв на автореферат диссертации Дудина А. А. «Применение языков декларативного программирования, 19.11kb.
• Ложения темпоральной (временной) логики для ветвящегося времени в плане ее использования, 138.35kb.
• Тематика рефератов по физике, 21.7kb.
• Обработка сигналов в радиотехнических системах, 166.53kb.
• Заявка участника Всероссийского молодежного конкурса наукоёмких инновационных идей, 244.53kb.

Глава 4.Разработка информационной системы

1. Мобильные агенты в Java

Платформа J2SE прекрасно подходит для организации систем мобильного кода, что подтверждается большим количеством платформ мобильных агентов на данном языке. В большая часть программного обеспечения ориентирована на платформу Java. Популярные системы мобильных агентов Tryllian ADK и DIET построены на основе J2SE.

Рассмотрим, средства Java обеспечивающие популярность данной платформы среди разработчиков систем мобильного кода.

Многопоточность и синхронизация. Платформа J2SE обладает средствами для создания многопоточных систем. Легко создать и запустить новый поток. Потоки могут использовать. Объекты могут иметь синхронизированные методы и атрибуты. Начиная с Java 5 Tiger многопоточные средства были расширены за счет пакетов java.util.concurrent, которые включили средства для атомарных операций, различные семафоры, классы для организации очередей, и создания задач, выполняемых по расписанию и т.п.;

Сериализация объектов. Платформа J2SE включает средства для сериализации объектов в поток байт. Естественно не все объекты могут быть сериализованы, например, сокет TCP или дескриптор файла. Сериализованный объект Java сохраняет все сериализуемые атрибуты, таким образом сериализуется так называемая «звезда» объектов;

Динамическая загрузка классов. При необходимости классы Java могут быть загружены в виртуальную машину из любого источника, путем расширения базовой функциональности системных загрузчиков классов;

Система безопасности. Как известно, Java код выполняется в среде виртуальной машины, что с одной стороны позволяет избавить программистов от рутинных и сложных моментов по выделению памяти и сборке мусора. С другой стороны выполнения кода позволяет ограничить выполняемый код в доступе к ресурсам операционной системы и другому выполняемому коду. Java 2 Security обеспечивает динамическое определение прав, а разграничение прав по источнику кода;

Кроссплатформенность. Платформа Java изначально разрабатывалась с учетом возможности выполнения в любой среде. Точнее J2SE есть набор стандартов, определяющих какие средства должны быть предоставлены выполняющейся программе. На сегодняшний день существуют реализации платформы J2SE (и как следствие J2EE) для операционных систем Windows, Linux, наиболее распространенных Unix систем (Solaris, AIX). Отметим, что кроссплатформенность обеспечивается не только на уровне классов, но и на уровне сериализованных объектов, что существенно для систем мобильного кода.

Перечисленные свойства наравне со свободных распространением платформы J2SE предопределили её популярность для систем мобильного кода.

Реализация узла платформы мобильных агентов на основе j2ee веб контейнера

Под платформой мобильных агентов понимают программное обеспечение, обеспечивающее выполнение и перемещение различных пользовательских агентов. Платформа состоит из узлов, между которыми агенты могут перемещаться. Узлы образуют каркас системы мобильных агентов. Естественно, что все существующие платформы программных агентов обладают собственной архитектурой агентов.

Большинство современных систем программных агентов подразумевает создание специфического программного обеспечения и размещение его в узлах информационных системы. Данное программное обеспечение обеспечивает выполнение агентов. При использовании платформы Java узлы каркаса системы реализуются на основе J2SE.

В данной работе предлагается реализация узла каркаса системы мобильных агентов в виде стандартного веб приложения J2EE. Что позволяет:

• Упростить конфигурацию и развертывание узла каркаса (узел каркаса поставляется в виде war файла);
  
• Стандартным образом конфигурировать предостваляемые агентам сервисы (JNDI контекст сервера J2EE);
  
• Сделать возможным выбор узла платформы (Tomcat, Weblogic, JBoss, OAS);
  
• Использовать стандартную и надежную реализацию транспортной системы для агентов. Использование протокола HTTP позволяет сделать транспортную систему более защищенной;
  
• Сохранить все преимущества платформы Java (систему безопасности, многопоточность и пр.).
  

Главный узел каркаса может быть размещен не только внутри J2EE веб контейнера, но также может быть развернут в среде J2SE, однако агент может быть в узел только путем расширения базовой функциональности. Именно таким образом, в систему мобильных агентов запускаются пользовательские агенты.

Как уже отмечалось, узел системы предоставляет сервисы агентам через стандартный механизм пространства имен веб приложения, которое может быть получено путем вызова new InitialContext().


Рисунок 4.1 – Принципиальное построение системы


Упаковщик агента является единственным объектом узла, с которому может обратиться объект агента, и отвечает за:

• перемещение и атомарность перемещения;
  
• события жизненного цикла агента (сердцебиение, прекращение жизни);
  
• передачу сообщений;
  
• связь агента с контекстом приложения.
  

Упаковщик агента получает от агента и каркаса узла сообщения, и помещает их в стек для обработки, туда же помещаются сообщения сердцебиения (события сердцебиения генерируются специальным потоком внутри упаковщика). Упаковщик агента по одному извлекает события из стека и передает их соответствующему методу агента. Таким образом, поток управления агента находится вне объекта агента, а принадлежит упаковщику агента, что позволяет обеспечивать атомарность перемещения агентов, т.к. когда из стека извлекается событие, требующее перемещения, известно что агент не выполняет никаких действий, поэтому он может быть безопасно сериализован и перемещен. При этом сохраняется парадигма того, что программный агент обладает фокусом управления.

В других системах мобильных агентов на основе Java атомарность передвижения и безопасная сериализация достигается следующими способами:

Tryllian ADK: активность агента разбита на отдельные из задачи, каждая из задач возвращает статус завершения. Перемещения представляется задачей. Таким образом для перемещения агента сериализуется граф задач, и текущее положение потока выполнения на этом графе. Так полностью сохраняется стек выполнения (естественно, уровня агента, а не объектов), а также обеспечивается безопасная сериализация и атомарность перемещения.

DIET: требование перемещения агент передает своему упаковщику, который чтобы прервать выполнение метода агента – вызывает исключительную ситуацию. Затем выполняет перемещения и заново запускает метод агента, реализующий основную логику. Однако такой механизм не полностью безопасен, так исключение может быть перехвачено кодом агента, или же вызвано самим кодом, а не упаковщиком агента, что в свою очередь влияет на атомарность перемещения.

Kaariboga: перемещения агентов отделены от логики выполняемой агентом. А имеено, все перемещения агента специфицированы заранее: агент перемещается, новая среда вызывает его специфический метод и по окончании его выполнения инициирует перемещения агента в соответствии с планом перемещения.

В разработанной системе реализуется механизм, похожий на DIET, только управление метода агента не прерывается исключительной ситуацией, а упаковщик агента помещает требование перемещение в стек событий данного агента и ждет окончания выполнения метода агента, чтобы продолжить обработку сообщений. Когда упаковщик агента получает из стека событие с требованием перемещения, он начинает сериализацию и перемещение. После перемещения обработка сообщения из стека продолжается: события сердце биения и управления жизнью агента опускаются, сообщения направляются на новое место жизни агента. После перемещения упаковщик продолжает свое функционирование в течение определенного периода времени для перенаправления сообщений.

В начальной реализации системы агент представляет собой один класс, во время перемещения сериализуемый вместе с классом в тело HTTP POST запроса. В заголовках запроса передаются размеры сериализованного объекта, класса и имя класса. Имя класса используется при построении загрузчика классов, который будет использован при десериализации агента. С помощью выделения загрузчика классов для каждого агента решается проблема нахождения двух агентов разных, но одноименных классов, а также проблема безопасности. Загруженному агенту разрешается только обращения через свой суперкласс к объекту своего упаковщика. Также лимитируется загрузка других классов

Текстовое сообщение также передается в сериализованном специальном объекте, который также содержит идентификаторы отправителя и получателя, и TTL (time-to-life). Числовое поле TTL необходимо, так как в системе реализована передача сообщения вслед перемещенному агенту. Для этого объект упаковщика агента не уничтожается сразу после перемещения агента, а хранит адрес, куда переместился агент. При возвращении агента в тот же узел он помещается в тот же упаковщик агента.

2. Требования к системе

Основой архитектуры агента является контекст, или серверная среда, в котором он исполняется. Один и тот же сервер может поддерживать несколько контекстов, каждый из которых имеет собственный набор защитных ограничений. Каждый агент имеет постоянный идентификатор – имя. Агенты могут работать совместно или обмениваться информацией в агентных системах, местах и регионах, отправляя и получая сообщения.

Для передачи сообщений между агентами или между агентом и пользователем существуют посредники. Они скрывают местонахождение агента для упреждения доступа к его коду.

В серверной среде может исполняться не только исходный агент, но и его копия. Агенты способны самостоятельно создавать свои копии, рассылая их по разнообразным серверам для исполнения работы.

По прибытии агента на следующий сервер его код и данные переносятся в новый контекст и стираются на предыдущем местонахождении. В новом контексте агент может делать все, что там не запрещено.

По окончании работы в контексте агент может переслать себя в другой контекст или по исходящему адресу отправителя. Кроме того, агенту можно приказать оставаться в одном и том же контексте столько, сколько пожелает пользователь. Агенты способны также выключаться («умирать») сами или по команде сервера, который переносит их после этого из контекста в место, предназначенное для хранения. После включения агент автоматически переносится в контекст, где он работал в последний раз. Уничтожение агента прекращает его исполнение и исключает его из текущего контекста.

Стоит отметить, что сейчас не существует языка программирования или инструментальной системы разработки, которая бы полностью отвечала нуждам построения агентов. Такая система должна была бы отвечать таким требованиям: обеспечение перенесения кода на разнообразные платформы, доступность на многих платформах, поддержка сетевого взаимодействия, многопоточная обработка и другие [2].

Чаще всего в агентных технологиях используются: универсальные языки программирования. Для разработки в данной дипломной работе был использован язык Java.

3. Постановка задачи

Как уже было сказано, технология мобильных агентов достаточно новая, но несмотря на это существует целый ряд задач управления информацией, которые решаются с использованием этой технологии.

Рассмотрим следующую задачу обработки и информации. Клиент хочет стереть с удаленного сервера все файлы, которые были созданы более чем два месяца назад. Очевидно, что если решать эту задачу с помощью RPC, то клиенту придется выполнить (N + 1) вызовов. Один запрос для получения данных о файлах и еще N запросов для удаления N файлов. Таким образом, всего по сети будет передано 2 (N + 1) сообщений. То есть (N + 1) запросов и (N + 1) ответов. Что же качается агентного подхода, то для решения этой задачи необходимо передать только два сообщения.

Для анализа решения задачи на основе мобильного подхода и классического клиент-серверного, было предложено и реализовано две системы.

В качестве критериев оценки эффективности систем предложены следующие характеристики:

• время работы программы;
  
• сетевой трафик, затрачиваемый для решения задачи при использовании WiFi канала с пропускной способностью 54Кбит/с.
  

4. Классическое решение

При рассмотрении задачи с точки зрения классического клиент-серверного подхода была реализована система, листинг программы которой размещен в приложении А. Принцип работы программы заключается в следующем. Создаются N файлов фиксированного размера. Клиент запрашивает у сервера список файлов, которые следует удалить в силу их ненадобности. Критерием является дата, задаваемая пользователем ранее которой файл считается не пригодным. Сервер возвращает список файлов, удовлетворяющих запросу. После чего клиент удаляет файлы.

В
ходе эксперимента было показано, что размер файлов не влияет на получаемые результаты. График зависимости времени выполнения программы от количества файлов и их размера приведен на рисунке:

График 4.1 – Результаты


График был получен при помощи программного комплекса Mathematica 6 на основе данных полученных при работе реализованной программы.

Было принято решение в дальнейших экспериментах брать в расчет фиксированный размер файлов, а именно 1Кб.

При проведении экспериментов для получения качественной и количественной оценки предложенных критериев, были получена следующие графики:



График 4.2 – Зависимость количества файлов от времени работы программы для классического клиент-серверного подхода




График 4.3 – Зависимость сетевого трафика от количества файлов


Характерная линейная зависимость наблюдается и объясняется тем, что длина команд и путь к файлу удаления, передаваемые по сети, фиксированы и неизменны, что ведет к единому размеру пересылаемых пакетов для отработки программы на файл.

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

5. Решение на основе мобильных агентов

Прежде чем рассматривать реализацию системы следует отметить, что архитектура моей системы управления мобильными агентами не является стандартной, а представляет собой один вариант из многих. Работа включает в себя три проекта: приложение серверного процесса, приложение клиентского процесса и общую для этих двух проектов библиотеку классов, в которой содержится два класса: Agent и AgentHost.

Система на основе мобильных агентов была реализована для решения задачи, составленной в п. 3.1. Принцип работы предложенной реализации представлен на рисунке в виде диаграммы последовательности:



График 4.4 – Диаграмма последовательности работы системы

на основе мобильных агентов.


Итак, рассмотрим другой подход к решению поставленной задачи на базе метода RP. Клиент создает процедуру, которая анализирует файлы сервера и удаляет файлы, удовлетворяющие заданному в ней критерию. Затем клиент передает эту процедуру для выполнения на сервере. При таком подходе по сети передается два сообщения, передача процедуры и возврат результатов ее работы.

Перемещаемую процедуру и называют мобильным агентом. Удаленное взаимодействие заменяется локальным, и уменьшается зависимость от работы сети, уменьшается трафик. Второе преимущество этого метода - расширение функциональности сервера. Серверные компоненты приложения, работающего через RPC, должны быть статически инсталлированы, в то время как серверные компоненты приложения, использующего RP, динамически инсталлируются агентами.

Была реализована программа для расчета эффективности использования технологии МА для решения поставленной задачи. На следующих графиках представлены результаты работы программы, обработанные в программном комплексе Mathematica 6:



График 4.5 – Зависимость времени работы программы

от количества файлов


Для наглядности совместим полученные результаты от обоих подходов:



График 4.6 – Зависимости времени от количества

файлов двух подходов


Как видно из полученных результатов, классический подход в значительной мере проигрывает агентному и в контексте поставленной задачи составляет 20-25%.

Теперь проанализируем график зависимости сетевого трафика от количества файлов:



График 4.7 – Зависимость сетевого трафика от

количества файлов


Как видно из представленного графика сетевой трафик является величиной постоянной, что объясняется тем, что каждый раз для отработки задачи на сервер передавался МА удаления, который имеет неизменный размер.

Сравним полученную зависимость с классических подходом:



График 4.8 – Зависимость сетевого трафика от

количества информации двух подходов


Очевидно, что обильный подход дает неоспоримое преимущество в сравнение с классическим подходом.

Можно рассмотреть пример, в котором клиент хочет взаимодействовать с несколькими серверами. Пусть существует M таких серверов и к каждому из них клиент делает Ni обращений. Таким образом, при использовании первого подхода мы имеет 2((N1+1) + (N2+1)+...+ (NM + 1)) сообщений.

Второй подход в этом случае предполагает, что агент перемещается от сервера к серверу и затем возвращает результаты клиенту. При этом возможен случай, когда совокупность серверов, которые должен обойти агент, формируется динамически в процессе его работы. Так, возможно, в процессе работы на i-ом сервере агент определяет свои дальнейшие действия, например, он решает вернуть результаты клиенту и закончить работу. В случае использования RPC, анализ получаемых от серверов результатов ложится на клиента. Если агент последовательно "обходит" все сервера, по сети будет передано (M+1) сообщение. Однако тенденцию зависимостей по предложенным критерием это не меняет.

Вообще говоря, для оценки трафика нужно оценивать длину сообщений, передаваемых в случае обычного запроса и мобильного кода. Очевидно, что для выполнения запросов на одном удаленном сервере метод RP может не дать выигрыша в трафике, так как объем мобильного кода может превысить суммарный размер сообщений, содержащих запросы и ответы. Если же задействовано несколько удаленных серверов, каждому из которых к тому же нужно послать большое число запросов, то использование мобильного агента, содержащего в себе, инкапсулирующего, эти запросы, кроме отмеченных выше преимуществ, снижает трафик.

Можно утверждать следующее: чем больше вычислений нужно выполнить, тем больший выигрыш дает технология мобильных агентов.