Е. В. Рогов
Архитектура системы анализа и обработки данных о поведении процессов

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

Актуальным является создание инструментальной системы, объединяющей в себе многие возможности разработанных ранее систем и расширяющей их за счет ориентации не на отдельную предметную область, а на широкий класс так называемых «плохо формализованных» процессов [1]. Важным свойством системы является использование в ней современных интернет-технологий, позволяющих, во-первых, обеспечить доступ для удаленных пользователей, а, во-вторых, организовать масштабируемую распределенную обработку и хранение данных [2,3].

Разрабатываемая система получила название «Система анализа и обработки данных о поведении процессов» (далее — просто Система).

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

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

Требования к Сиcтеме

Особенности хранимых в Системе данных. Основной тип данных, для работы с которым предназначена Система, это многопараметрический временной процесс.

Пусть задана временная сетка T: t₀, … ,t_N-1. Она может быть как равномерной, т. е. t_i = t₀ + iΔt, так и неравномерной, когда все узлы задаются индивидуально. Тогда многопараметрический временной процесс представляется вектором своих параметров P(t) = (p₀(t), … ,p_M-1(t)), каждый из которых есть функция, заданная на сетке T.

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

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

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

Структура Системы накладывает и еще одно требование — формат должен быть достаточно прост, чтобы на стороне клиента можно было бы работать с ним же. Если не будет существовать компактной библиотеки для работы с выбранным форматом, возникнет необходимость на стороне сервера осуществить перекодировку данных в какой-либо простой вид. Это потребует от ядра Системы понимания семантики хранимых данных, что не только существенно усложнит ядро, но и затруднит введение в Систему новых типов данных.

Желательно, чтобы формат данных был распространен в научном сообществе, что улучшит совместимость Системы с другими разработками, упростит импортирование в нее данных.

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

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

На основании анализа ряда распространенных универсальных форматов (CDF [4], netCDF [5], HDF [6] и XSIL [7]) для использования в качестве внутреннего формата данных Системы был выбран формат netCDF (network Common Data Form). Он разработан в рамках программы Unidata Университетской корпорации по атмосферным исследованиям (University Corporation for Atmospheric Research, UCAR).

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

Модель данных netCDF использует понятия размерность (dimension), переменная (variable) и атрибут (attribute). Размерность служит для представления какой-либо физической размерности, например, времени, широты, долготы и т. п. Переменные используются для хранения набора данных и в общем случае представляют собой многомерный массив с заданными размерностями. Атрибуты используются для представления метаинформации. Атрибуты могут относиться как ко всей совокупности данных, так и к конкретной переменной.

Главное достоинство netCDF по сравнению с остальными форматами — возможность использования одного формата как на стороне сервера, так и в апплете на стороне клиента. Причем на стороне сервера можно выбирать между эффективной, но зависимой от платформы программой (на C, Fortran), и менее эффективной, но переносимой программой на Java.

Особенности применяемых в Системе методов. Особый интерес в рамках Системы представляют так называемые «плохо формализованные» процессы — процессы, законы поведения которых неизвестны или недостаточно изучены. Основной метод их исследования сводится к анализу накопленной статистики поведения процессов той же природы.

Для изучения данных Системой предоставляется широкий спектр различных вычислительных методов. В них входят как алгоритмы _предварительной обработки данных_ (препроцессинга), так и _стандартные вычислительные алгоритмы_ (линейные преобразования, нормализация, интерполяция и экстраполяция, статистические функции, приближение методом наименьших квадратов, анализ данных с помощью преобразований Фурье и волновых преобразований (wavelet) и т. п.). Однако в качестве _основного инструмента анализа_ предполагается применять методы, использующие нейронные сети и генетические алгоритмы. Причина такого выбора в том, что аппарат нейронный сетей и генетических алгоритмов позволяет эффективно решать широкий круг задач в условиях, когда точные методы решения неизвестны или недоступны.

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

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

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

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

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

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

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

Архитектура Системы

Программная архитектура. Структурно Система состоит из четырех частей: рабочего стола, хранилища данных, набора вычислительных модулей и ядра, объединенных в трехзвенную архитектуру клиент-сервер (см. рис. 1).

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

Трехзвенная архитектура, по сравнению с более простой двухзвенной, позволяет минимизировать сетевой трафик между клиентом и сервером, поскольку запрос формулируется клиентом в высокоуровневых терминах и лишь на стороне сервера транслируется ядром в конкретные операции выборки и сохранения данных, выполнения над ними определенных вычислительных модулей. Наличие промежуточного звена позволяет существенно упростить логику клиента, исключая из нее управление распределенной структурой хранения данных и выполнения вычислений. Сокрытие от клиента внутреннего устройства серверной части позволяет изменять конфигурацию хранилища данных и вычислительных методов (добавлять или убирать вычислительные серверы, серверы данных, новые методы), не внося изменений в клиентскую часть. Наконец, трехзвенная архитектура с единственным выделенным компьютером для связи с внешней сетью позволяет эффективно организовать безопасность Системы [8].

Аппаратная архитектура. Система предназначается для работы в сетях TCP/IP. Это позволяет использовать ее и в интернете, и в локальных интранет-сетях.

Аппаратная конфигурация Системы может быть различной. В минимальном виде Система может выполняться целиком на одном компьютере. Другая крайность — компоненты, максимально распределенные по разным компьютерам в сети. Однако обычная конфигурация, на которую рассчитана Система, выглядит, как показано на рис. 2.

На одном, выделенном, компьютере работает ядро Системы и служебная СУБД. На ряде компьютеров, находящихся с выделенным в одной быстрой локальной сети, находится распределенное хранилище и вычислительные модули. Эта часть является масштабируемой за счет наращивания количества компьютеров. Пользовательский компьютер с рабочим столом может быть подключен к Системе через относительно медленный канал связи.

Схема взаимодействия. В общем случае взаимодействие происходит следующим образом.

Любое действие, которое должна совершить клиентская часть, оформляется в виде запроса ядру Системы. Запрос имеет определенный тип (соединение с сервером, получение данных, выполнение вычислений и т. п.), содержит имя пользователя и его пароль, идентификаторы данных и прочую необходимую информацию.

Ядро, получив запрос, разбирает его и выполняет. Для этого оно может обращаться к серверам распределенного хранилища и вычислительным серверам. Результат выполнения запроса возвращается клиенту.

Обмен данными происходит по протоколу HTTP [9,10]. Для получения, передачи и удаления данных с узлов сети применяются методы GET, PUT и DELETE. Программы на узлах выполняются, используя интерфейс CGI [11]. Для обращения к СУБД используется интерфейс JDBC [12].

Возможна ситуация, когда отдельные узлы не допускают произвольную конфигурацию со стороны администратора Системы, например, высокопроизводительный кластер, на котором для Системы предоставлен пользователь. В таком случае есть возможность в ущерб переносимости Системы использовать утилиты (ssh и scp) операционной системы Unix для обмена данными и вызова модулей.

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

Данные

Структура хранения данных в Системе. Для хранения служебной информации в Системе применяется реляционная база данных. Для соединения со служебной СУБД ядро Системы использует интерфейс JDBC (Java Database Connectivity). Это позволяет подключить к Системе любую СУБД, для которой существует JDBC-драйвер. На данный момент только на сайте фирмы Sun можно найти драйверы для более, чем 70 СУБД, а ведущие производители, такие, как Oracle, IBM, Informix, уже включили поддержку Java непосредственно в СУБД.

Для научных данных применяется распределенное хранение на узлах вычислительной сети. Необходимость распределять данные обусловлена, как отмечалось, их большим объемом.

Данные располагаются в файлах формата netCDF. Для организации распределенного хранения реализован следующий механизм.

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

Для повышения эффективности применяется кэширование данных как на сервере, так и на клиенте.

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

Кэширование данных. Чтобы повысить скорость работы и уменьшить сетевой трафик, в Системе применяется кэширование на стороне сервера и на стороне клиента (см. рис. 3).

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

Серверное кэширование состоит в том, что для каждого файла netCDF, хранящегося на одном из узлов сети, на сервере хранится его схема (под сервером здесь понимается тот узел, на котором работает ядро Системы). Размер схемы netCDF достаточно мал (в среднем меньше килобайта), так что для хранения схем всех данных не требуется много места.

На стороне клиента кэшируются и схемы, и сами данные. В случае, если дисковое пространство клиента ограничено, предусмотрен механизм принудительной очистки кэша данных или его полное отключение.

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

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

Принятая в Системе семантика неизменяемых файлов упрощает кэширование, так как не требуется проверки актуальности данных в кэше.

Вычислительные методы

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

• Методы предварительной обработки (препроцессинга) служат для приведения исходных экспериментальных данных в вид, удобный для дальнейшей обработки.
  Это — методы, исправляющие различные искажения, вносимые, например, измерительной аппаратурой (фильтрация шумов, восстановление пропущенных значений), а также методы, позволяющие согласовать несколько наборов данных друг с другом (приведение к общей временной шкале).
• К стандартным методам относятся методы, обычно присутствующие в различных системах и пакетах обработки данных.
  К ним относятся линейные преобразования, нормализация, интерполяция и экстраполяция, статистические функции (вычисление минимума, максимума, математического ожидания, среднего квадратичного отклонения, корреляции и т. п.), приближение методом наименьших квадратов, анализ данных с помощью преобразований Фурье и волновых преобразований (wavelet) и т. п.
• Специальные методы основаны на использовании нейронных сетей и генетических алгоритмов и являются основным инструментом изучения поведения процессов, предоставляемым Системой.
  С помощью нейросетей и генетических алгоритмов решаются такие задачи анализа процессов, как прогнозирование поведения, классификация, определения зависимых параметров процесса и др.

В настоящее время в Системе используется Штутгартский нейросетевой эмулятор SNNS [13]. Это свободно распространяемый продукт, имеющий открытую архитектуру и программный интерфейс.

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

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

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

Для решения этой проблемы вычислительный метод разделяется на две составляющие — серверную, которую мы будем называть модулем, и клиентскую, которую мы будем называть методом. Модуль, как правило, пишется на языках типа C или Fortran, для которых существуют эффективные компиляторы, и содержит только вычислительную часть. Метод представляет собой Java-класс, реализующий пользовательский диалог для модуля.

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

Во-первых, это дает возможность «модульной» организации задачи. Например, можно реализовать прямое и обратное преобразования Фурье в виде отдельных модулей и использовать их в ряде вычислительных методов. Впрочем, такой подход связан с накладными расходами и ему следует предпочесть обычное использование библиотеки.

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

Особая разновидность метода, выделяемая в Системе в отдельный тип, — визуализатор. Это программа, служащая для отображения данных. Как правило, визуализация происходит на стороне клиента, однако с помощью вызова соответствующего модуля можно реализовать и серверную визуализацию.

Типы модулей. В Системе предусмотрены модули трех типов в зависимости от времени работы порожденного ими процесса: непосредственные, фоновые и демоны.

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

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

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

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

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

Процессы-демоны (по аналогии с демонами системы Unix) предназначены для постоянной работы. Они запускаются пользователем и работают, пока не будет остановлены.

Демоны могут использоваться, например, для периодического сбора информации в сети интернет.

Ядро Системы

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

При работе над Системой для поддержки сервлетов использовался модуль jserv для веб-сервера Apache. И веб-сервер, и модуль являются свободно распространяемыми продуктами Apache Software Foundation.

Функции ядра. Ядро Системы является основным управляющим элементом и выполняет следующие функции.

• Принятие запросов от клиентов, их обработка и возвращение результатов.
  Это основная функция ядра. Для ее обеспечения могут также использоваться и другие функции, рассмотренные ниже.
• Поддержка распределенного хранения данных.
  Для поддержки распределенного хранения от ядра требуется, во-первых, по идентификатору получать данные с нужного узла сети, и, во-вторых, размещать в узлах сети новые данные, получаемые в результате работы или при импортировании. Для организации распределенного хранилища ядро использует служебную БД, в которой содержится информация о конфигурации узлов Системы и принадлежности пользователей узлам.
• Распределение вычислений по узлам сети и вызов вычислительных модулей.
  Вызов вычислительного модуля представляет собой довольно сложный процесс, в который входят поиск узла, на котором следует разместить задание, передача необходимых данных на выбранный узел, выполнение задания, прием и размещение результатов вычисления.
• Поддержка фоновых заданий и процессов-демонов.
  Специфика Системы предполагает, что часть вычислительных модулей может выполняться значительное время. К таким модулям относятся задания, связанные с нейросетями и генетическими алгоритмами. От ядра также требуется поддержка заданий, которые запускаются пользователем и далее работают автономно.

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

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

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

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

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

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

Клиент

Среда выполнения. Клиентская часть Системы написана на языке Java и допускает работу как в режиме апплета, так и в режиме приложения. И в том, и в другом случае пользователю необходимо установить Java 2 Runtime Environment фирмы Sun.

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

Апплет выкладывается на веб-сервере Системы и пользователи автоматически получают самую последнюю версию клиентской части при каждом обращении к веб-серверу. В этом случае пользователь должен иметь браузер с установленным Java Plug-in (версии 1.3 или выше); Java Plug-in позволяет выполнять апплет, используя Java-машину фирмы Sun вместо встроенной в браузер.

Встроенная Java-машина не годится по двум причинам. Во-первых, современные браузеры (Netscape Navigator 4 и Microsoft Internet Explorer 5) имеют Java-машину версии 1.1, что не позволяет использовать в апплете возможности, предоставляемые более новыми версиями. На сегодняшний день только Netscape Navigator 6 располагает Java-машиной версии 1.2. Во-вторых, практика показывает, что встроенные Java-машины работают крайне нестабильно и не вполне совместимы друг с другом.

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

Эта проблема решается с помощью подписанных апплетов (signed applets) [14]. Еще одно преимущество Java Plug-in состоит в том, что апплет подписывается одинаково для любого браузера, в то время, как встроенные Java-машины браузеров Netscape Navigator и Microsoft Internet Explorer требуют различных процедур.

От пользователя требуется импортировать сертификат Системы и прописать права, предоставляемые апплету, подписанному этим сертификатом. Все необходимые для этого инструменты (включая и сам Java Plug-in) входят в состав Java 2 Runtime Environment.

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

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

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

• Реализация клиент-серверного протокола.
  Любое взаимодействие с сервером осуществляется через данный сервис.
  Объект-запрос посылается серверу, от сервера принимается объект-ответ и возвращается в качестве результата. Поскольку запрос может передаваться и выполняться значительное время, выводится окно, показывающее состояние запроса.
• Авторизация пользователя.
  У пользователя запрашивается имя и пароль, после чего посылается запрос на авторизацию. Если авторизация на сервере проходит успешно, с сервера запрашивается список доступных пользователю данных, методов и визуализаторов. По списку данных с сервера запрашиваются их схемы. Визуализаторы регистрируются для поддерживаемых ими типов данных.
  Далее, загружается класс, реализующий рабочий стол группы, в которую входит пользователь. Классу передаются списки данных, методов и визуализаторов, которые он тем или иным образом использует в пользовательском интерфейсе.
• Вызов методов и модулей.
  При вызове метода с использованием Reflection API загружается класс, соответствующий данному методу. Этот класс организует диалог и формирование файла netCDF, содержащего параметры вызова вычислительного модуля. Далее класс инициирует вызов модуля и получает результаты. Метод может вызывать несколько модулей, получая их суперпозицию.
• Вызов визуализаторов.
  Вызов визуализатора похож на вызов обычного метода, однако при этом пользователь указывает только данные, но не имя визуализатора. Если для типа указанных данных зарегистрирован только один визуализатор, то он и вызывается. Если же визуализаторов несколько, пользователю дополнительно предлагается выбрать один из них.
• Поддержка кэша.
  Базовый класс осуществляет прозрачное для реализаций рабочего стола кэширование данных. При запросе на получение данных они берутся из кэша на локальном диске. Если в кэше данные отсутствуют, то они запрашиваются с сервера и размещаются в кэше.
• Отладочная журнализация.
  Программный интерфейс сервлетов предоставляет возможность ведения журнала (при этом, как правило, сообщения попадают в журнал веб-сервера). В случае клиентской части такая стандартная возможность отсутствует.
• Справочная система.
  Справочная система организована в виде html-страниц. Она хранится на сервере, и для ее просмотра используется веб-браузер. В случае, если клиент используется как апплет, для показа справки используется API апплета, позволяющий в новом окне направить браузер по нужному адресу. В случае приложения браузер запускается отдельно.

Список литературы

1. Ершов Н. М., Королев Л. Н., Малютина Э. Э. , Попов А. М., Попова Н. Н.
   Применение активных баз данных в прогнозировании. // Вестн. Моск. ун-та. Сер. 15. Вычисл. матем. и киберн. 1998. № 1. С. 32–43.
2. Королев Л. Н., Попов А. М., Попова Н. Н., Рогов Е. В.
   Реализация системы анализа динамических процессов в сети Интернет // Научный сервис в сети Интернет: Тезисы докладов Всероссийской научной конференции (20–25 сентября 1999 г., г. Новороссийск). М.: Изд-во МГУ, 1999. C. 162–167.
3. Рогов Е. В.
   Интернет-организация Системы Анализа Динамических Процессов // Программные системы и инструменты: Тематич. сб. ф-та ВМиК им. Ломоносова: № 1. М.: МАКС Пресс, 2000. С. 75–80.
4. CDF User’s Guide. National Space Science Data Center, 1999.
   NSSDC’s CDF
5. Rew R. K., Davis G. P., Emmerson S., Davies H.
   NetCDF User’s Guide for C. An Interface for Data Access, Version 3, 1997.
   Unidata NetCDF
6. HDF Specification and Developer’s Guide. NCSA, University of Illinois, 2001.
   NCSA HDF
7. Williams R.
   XSIL: Java/XML for Scientific Data. California Institute of Technology, 2000.
   XSIL
8. Яворски Д., Перроун П. Дж.
   Система безопасности Java. Руководство разработчика. Пер. с англ. М.: Издательский дом «Вильямс», 2001.
9. Berners-Lee T., Fielding R., Frystyk H.
   Hypertext Transfer Protocol — HTTP/1.0, RFC 1945, May 1996.
   RFC 1945
10. Fielding R., Gettys J., Mogul J. et al.
    Hypertext Transfer Protocol — HTTP/1.1, RFC 2616, June 1999.
    RFC 2616
11. Robinson D.
    The WWW Common Gateway Interface Version 1.1, Internet Draft, October 1995.
    CGI
12. Hamilton G., Cattell R., Fisher M.
    JDBC Database Access with Java: A Tutorial and Annotated Reference. Aliison-Wesley, 1997.
13. Zell A., Mamier G., Vogt M. et al.
    SNNS User Manual, Version 4.1, University of Stuttgart.
    SNNS
14. Srinivas R. N.
    Java Security Evolution and Concepts. Part 3: Applet Security. JavaWorld, 2000.
    Part 3: Applet Security