1. 2 Понятие систем мониторинга 3




Название1. 2 Понятие систем мониторинга 3
страница7/35
Дата конвертации11.12.2012
Размер3.08 Mb.
ТипРеферат
1   2   3   4   5   6   7   8   9   10   ...   35

3.1.2 Выбор средств реализации

3.1.2.1 Модель программирования


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

  • модель программирования на распределенной памяти или механизмы передачи сообщений (PVM [12], MPI [13]);

  • распределенные системы объектов (CORBA [14]);

  • нетрадиционные языки программирования для распределенных систем (Erlang [15]);

  • библиотеки промежуточного слоя (Ice ZeroC [16]).

В итоге, была выбрана объектно-ориентированная платформа среднего слоя Ice (The Internet Communication Engine) от компании ZeroC в силу доминирующего превосходства над аналогами. Платформа Ice снабжена инструментами, API и библиотеками для разработки объектно-ориентированных клиент–серверных приложений. Ice-приложения могут быть написаны на различных языках программирования (Java [17], C++, Python [18], C#, Ruby [19]), запущены под различными операционными системами (Windows NT, Linux, MacOS OS) и аппаратными платформами, а также могут взаимодействовать, используя разнообразные сетевые технологии. В общем случае Ice позиционируется как инструмент RPC (Remote Procedure Call) [20], который достаточно прозрачно применять на практике. Большое количество компаний по всему миру, таких как Skype, HP, Silicon Graphics используют технологию Ice в своих проектах.

Платформа Ice обладает следующими особенностями преимуществами:

  • объектно-ориентированная семантика;

  • поддержка синхронных и асинхронных вызовов;

  • аппаратная независимость;

  • языковая независимость;

  • операционная независимость;

  • безопасность;

  • доступность исходного кода;

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

3.1.2.2 Терминология модели программирования


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

Можно выделить два вида программных агентов в платформе Ice:

  1. клиент — активная сущность, запрашивающая некоторые ресурсы у сервера;

  2. сервер — пассивная сущность, предоставляющая некоторые ресурсы клиенту.

На практике редко встречаются «чистый» сервер или «чистый» клиент. Чаще всего это смешанный клиент-сервер, который одновременно и запрашивает и предоставляет ресурсы.

Любая сущность, запущенная в распределенной системе Ice, определяется так называемым Ice-объектом. Ice-объект – это абстракция, характеризующаяся следующим:

  • локальными или удаленным адресным пространством;

  • возможностью реакции на удаленный запрос;

  • поддержкой репликации;

  • несколькими интерфейсами;

  • публичными методами интерфейсов имеющих как входные, так и выходные параметры;

  • уникальным идентификатором, не совпадающим с любым другим идентификатором объекта в распределенной гетерогенной среде.

Для непосредственной распределенной коммуникации объектов платформа Ice реализует специальные механизмы транспортного уровня, инкапсулированные в объектах типа прокси. Практически, Ice-прокси соответствует одному Ice-объекту и предоставляет для него механизмы и примитивы для организации удаленных вызовов процедур. Прокси – это артефакт, который локален для клиентского адресного пространства. Ice-прокси инкапсулирует следующую информацию, о действиях, совершаемых платформой при вызове удаленной процедуры клиентом:

  1. определяет местоположение Ice-объекта;

  2. активирует сервер, если он не запущен;

  3. активирует Ice-объект на сервере;

  4. передает входные параметры Ice-объекту;

  5. ждет, когда операция закончится;

  6. передает возвращаемые значения или генерирует исключение.

Кроме того, Ice-прокси содержит:

  1. адресную информацию, которая позволяет клиентской стороне соединиться с нужным сервером;

  2. идентификатор объекта, который является целью запроса;

  3. дополнительный идентификатор, который определяет интерфейс объекта, к которому прокси обращается.

Стоит также рассмотреть виды запросов на диспетчеризацию и виды диспетчеризации вызовов.

Платформа среднего слоя Ice поддерживает следующие виды запросов на диспетчеризацию:

  • синхронный вызов, при котором клиент, совершивший вызов, повисает на время выполнения процедуры, пока она не закончится;

  • асинхронный вызов, сопровождаемый передачей объекта обратного вызова;

  • односторонний вызов метода с организацией одностороннего потока сетевого трафика;

Аналогично запросам на диспетчеризацию можно выделить следующие виды диспетчеризации методов:

  • синхронная диспетчеризация, при которой серверный поток повисает в ожидании завершения процедуры;

  • асинхронная диспетчеризация, эквивалентная асинхронному вызову методов;

Для описания удаленных интерфейсов объектов Ice использует специализированный язык описания спецификаций – Slice (Specification Language for Ice).

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

3.1.2.3 Язык программирования


Платформа среднего слоя Ice поддерживает почти все современные языки программирования, среди которых можно отметить наиболее популярные:

  • нативные (C++, Objective C [21]);

  • управляемые (Java, С#, VB.NET);

  • динамические/интерпретируемые (Python, PHP [22]).

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

  • достаточно высокая производительность языка или платформы;

  • кроссплатформенность;

  • поддержка ООП-семантики;

  • наличие современных и эффективных средств разработки;

  • доступность языка или платформы;

  • богатая библиотека стандартных модулей и классов.

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

Динамически интерпретируемые языки, такие как Python и PHP, не удовлетворяют требованиям к производительности. Безусловно, современные технологи построения интерпретаторов позволяют им добиваться сравнимой с нативным кодом производительности, однако ядро службы мониторинга является бутылочным горлышком системы и может существенно влиять на поведение и скорость работы всей системы в целом. Поэтому нами рассматривались два варианта – языки Java и С++. Языки на платформе .NET [23] не рассматривались из-за отсутствия кросс-платформенной реализации.

С одной стороны оба языка предоставляют программисту сравнительно одинаковый набор возможностей (ООП, стандартная библиотека классов и модулей). С другой – программы, написанные на Javaи на С++, показывают абсолютно разную, практически несравнимую производительность.

В конечном счете, нами была выбрана платформа Java. Решающим фактором, определившим наш выбор, стала скорость разработки, которая, как известно, на Java значительно выше, чем на C++. Более того, современные виртуальные машины платформы Java (Oracle Hotspot, OpenJDK) со встроенными компиляторами динамического кода (JIT) показывают отличную производительность, порой превосходящую нативное исполнение не в разы, а на порядки. Такой прирост производительности объясняется в первую очередь механизмами динамического профилирования и сборки мусора, которые идеологически недоступны в нативных компиляторах.

Помимо вышеперечисленного, для Java существует большое количество удобных и эффективных сред разработки (Eclipse [24], Netbeans [25], IntelliJIDEA [26]), отладки, тестирования, а также свободных переносимых библиотек для решения широкого круга прикладных задач.

Безусловно, нельзя отвергать тот факт, что участники проекта при выборе языковой платформы основывались на собственный опыт разработки программных систем, где чаще всего применялась платформа Java.
1   2   3   4   5   6   7   8   9   10   ...   35

Похожие:

1. 2 Понятие систем мониторинга 3 icon1. 2 Понятие систем мониторинга 3
Сравнительный анализ затрат в ходе эксплуатации программного продукта и аналога 85
1. 2 Понятие систем мониторинга 3 icon1. 2 Понятие систем мониторинга 2
Основная задача подобных решений систематический анализ и интерпретация протекающих в гетерогенной среде процессов. Полученные в...
1. 2 Понятие систем мониторинга 3 icon1. Цель мониторинга Мониторинг слово, вошедшее в педагогический лексикон относительно недавно. Современный словарь иностранных слов определяет это понятие как
Мониторинг процесса воспитания в школе Начнем, по­жалуй, с трех простых вопросов: нужно ли это, кому это нужно и зачем это нужно?...
1. 2 Понятие систем мониторинга 3 iconСистемы IP мониторинга ip pdu панели   ■ Контроль объектов   ■ ip мониторинг   ■ Управление электропитанием Системы Мониторинга / Распределитель Электропитания Системы мониторинга sc2100
Резервирование питания: 12В, встроенный датчик напряжения питания, можно подключить 
1. 2 Понятие систем мониторинга 3 iconОценочный доклад
Бляхарчук Т. А. д б н., с н с., лаб мониторинга лесных экосистем, Институт мониторинга 
1. 2 Понятие систем мониторинга 3 iconПрограмма fos (Fundamentals of Operating Systems) «Основы операционных систем»
Характеристики сетевой операционной системы. Многопользовательские, многозадачные и многопроцессорные системы. Структура операционной...
1. 2 Понятие систем мониторинга 3 iconПравовые основы  мониторинга и сохранения 
Брошюра-справочник участника Украинской сети мониторинга  и  сохранения  китообразных  может  быть  интересна  также 
1. 2 Понятие систем мониторинга 3 iconПлан отчета I. Методические рекомендации для администрации по проведению мониторинга и оценки индивидуального прогресса учащихся образовательного учреждения а) какие условия нужно учесть при организации регулярного тестирования (мониторинга) в школе?
А) какие условия нужно учесть при организации регулярного тестирования (мониторинга) в школе?
1. 2 Понятие систем мониторинга 3 iconКонспект урока 8 класс Тема: «Графический интерфейс операционных систем и приложений»
Цель: дать понятие графического интерфейса, основных элементов окон, научить детей пользоваться графическим интерфейсом, работать...
1. 2 Понятие систем мониторинга 3 iconСистема электронного мониторинга комплексного проекта модернизации образования
Работа на сайте электронного мониторинга и размещение данных на закрытой части сайта не вызывает трудностей у пользователей, т к...
Разместите кнопку на своём сайте:
kak.znate.ru


База данных защищена авторским правом ©kak.znate.ru 2012
обратиться к администрации
KakZnate
Главная страница