Главная Коллекция "Otherreferats" Программирование, компьютеры и кибернетика Система сбора и мониторинга информации с удаленных информационных ресурсов

Система сбора и мониторинга информации с удаленных информационных ресурсов

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 07.06.2012
Размер файла 2,9 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Министерство образования РФ

Дальневосточный государственный университет

Институт математики и компьютерных наук

Факультет компьютерных наук

Кафедра информатики

Система сбора и мониторинга информации с удаленных информационных ресурсов

Дипломная работа

студента 259 группы

Павленко Виталия Сергеевича

научный руководитель:

ассистент кафедры информатики

Голик Андрей Владимирович

г. Владивосток, 2003г.

Введение

Основные исследования, проводимые специалистами Тихоокеанского океанологического института, связаны с изучением разнообразных параметров состояния водной среды, морского дна и атмосферы на акваториях дальневосточных морей и северо-западной части Тихого океана. Для повышения эффективности такого рода исследований, придания им комплексности, целесообразно использовать интегрированные геоинформационные системы (ГИС), предоставляющие специалистам учреждения доступ ко всей совокупности имеющихся данных по региону. Как правило, в таких ГИС представлены данные, полученные специалистами этого учреждения. Вместе с тем, очень часто в том же географическом регионе проводят исследования и другие научные учреждения, как отечественные, так и зарубежные. Данные этих исследований в режиме свободного, либо ограниченного доступа представляются в виде информационных хранилищ расположенных в сети Интернет. Использование таких дополнительных данных позволяет исследователям уточнять общую картину изучаемых ими явлений и процессов. [12]

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

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

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

1. Описание предметной области

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

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

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

1.1. Цели и задачи

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

· Предоставление сервиса, который хранит список центров удаленных данных;

· Получение этих данных по протоколам ftp и http;

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

· Формирование наиболее возможного метаописания этих ресурсов: дата создания, дата изменения, формат файла, авторские права, размер, дополнительное описание;

· Предоставление доступа пользователей к полученным данным, и их предобработка на сервере;

· Предоставление возможности поиска по базе локальных информационных ресурсов.

· Предоставление WEB интерфейса.

1.2. Аналитический обзор существующих систем

MapInfo Metadata Browser

MapInfo Metadata Browser (MMDB) - это интеллектуальный поисковый клиент, созданный для потребителей пространственных данных. MMDB позволяет пользователям собирать информацию о наличии пространственных данных, предоставляемую различными центрами обмена пространственной информацией, а также сравнивать и анализировать полученные метаданные. С помощью MMDB можно формулировать запросы, касающиеся пространственных данных, таких как: Существуют ли такие данные? Где имеются требуемые данные и как их можно приобрести? Отвечают ли эти данные моим требованиям? [16]

MMDB выполняет следующие функции:

· Построение запроса, основанного на списке атрибутов метаданных, соответствующих стандартам FGDC.

· "Сканирование" Интернета для нахождения метаданных, отвечающих запросу пользователя.

· Поддержку картографического интерфейса для выбора территории, на которую требуются пространственные данные.

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

· Работу на разных вычислительных платформах благодаря реализации на Java (Windows '95, '98, NT или UNIX).

· Возможность настройки под пользователя.

· Дружественный интерфейс и контекстно-чувствительная Справочная система.

· Позволяет обойти ограничения текущего стандарта FGDC по поиску метаданных.

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

· Позволяет параллельно обрабатывать до десяти запросов.

1.2.1.1 Недостатки

· Работает только как клиентское приложение, то есть если группе пользователей нужно получить какие-то данные, то каждый из них запускает на своем компьютере Metadata Browser, и получает данные, но при этом происходит дублирование работы, и загружается сетевой трафик.

· Осуществляет только поиск метаданных, функции редактирования метаданных отсутствуют.

· Список серверов данных не пополняем.

· Может работать только с теми серверами данных, на которых установлено специальное программное обеспечение.

ESRI ARCCatalog

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

Набор метаданных создается в программе ArcGIS ArcCatalog и публикуется на сервере. Опубликованные метаданные могут быть легко предоставлены другим пользователями системы. [16]

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

Можно самостоятельно формировать дерево Каталога. Такие функции, как Подключиться к папке и Отключиться от папки, позволяют добавить в Каталог только те папки, которые потребуются пользователю для работы. Помимо подключения к папкам, в ArcCatalog возможно подключаться к базам данных и Интернет-серверам.

Каталог - это своеобразное представление карт и географических данных, хранящихся на локальных и сетевых дисках.

Подключение к папке указывает на корневую папку вашего локального диска или на выбранную папку диска, доступного в сети. В Каталоге отображаются все папки, находящиеся внутри подключенной папки. Если папка не содержит географических данных, она отображается обычным значком, как в проводнике Windows. Папки, содержащие географические данные, такие как базы геоданных, покрытия, шейп-файлы, файлы САПР и связанные с ними файлы, отображаются специальным значком. Причем, географические данные определенного формата отображаются собственными специальными значками. По умолчанию в ArcCatalog к географическим относятся данные следующих форматов: база геоданных и все ее содержимое (классы пространственных объектов, растровые наборы данных, классы отношений, геометрические сети и т.д.), шейп-файлы, покрытия, файлы САПР, документы и шаблоны карт, слои, растровые изображения нескольких форматов.

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

ArcCatalog позволяет быстро просматривать доступные данные. Есть несколько режимов отображения данных: крупные значки, список, детали (список с указанием типа данных) и образцы. Кроме этого, при помощи закладки Просмотр можно просматривать содержимое структурных единиц пространственных данных (шейп-файлов, покрытий, наборов классов и т.д.), не открывая их во вьюере (например, в ArcMap). На закладке Просмотр есть два режима просмотра: География и Таблица. Переключаясь между режимами, можно работать и с пространственными, и с атрибутивными данными.

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

В ArcCatalog есть набор важных инструментов, позволяющий повысить эффективность работы и отдачу от имеющихся данных, - инструменты для работы с метаданными. Метаданные - это «данные о данных». Они создаются в соответствии с существующими стандартами и содержат информацию, позволяющую четко идентифицировать данные, - начиная от названия организации, владеющей данными, и заканчивая географическими координатами участка покрытой данными территории. Метаданные облегчают управление данными, так как они помогают быстро ориентироваться в больших объемах информации. В частности, поиск, осуществляемый в ArcCatalog, работает и на основе метаданных: можно указать значения некоторых параметров метаданных, которые будут учитываться при поиске. ArcCatalog может создавать метаданные автоматически, внося в них информацию, получаемую из системы (название организации, дата создания, экстент данных и т.д.). В специальном редакторе метаданных можно изменить автоматически созданные метаданные, внеся дополнительную информацию, такую как назначение данных, комментарии и т.д.

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

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

1.2.1.2 Недостатки

· Работает только как клиентское приложение, то есть если группе пользователей нужно получить какие-то данные, то каждый из них запускает на своем компьютере Metadata Browser, и получает данные, но при этом происходит дублирование работы, и загружается сетевой трафик.

· Может работать только с теми серверами данных, на которых установлено специальное программное обеспечение.

· Работает только с определенным форматами данных.

1.3. Технологии описания данных

Метаданные

В Интернете содержится огромное количество документов, настолько огромное, что на первый план выходит не проблема собственно наличия документа в Интернете, а проблема поиска нужного документа. И здесь единственная возможность облегчения ситуации - научить компьютер понимать документы, т.е. существенная тенденция современного развития Интернет - это переход от документов, читаемых компьютером (machine readable) к документам, понимаемым компьютером (machine understandable).

Документ содержит дополнительную информацию, которая характеризует его. В простейшем случае - это информация о дизайне документа (шрифты и их размер, отступы и т.д.). [21]

Метаданные (metadata) - это информация о документе, понимаемая компьютером (machine understandable) иными словами данные о данных.

"Понимание компьютером" есть ключевой момент в определении метаданных. Человек смотрит на документ и видит его заголовок, в котором указано название документа. Подзаголовок может содержать тему документа, а также его краткую аннотацию. Обычно где-то в самом начале документа или в самом его конце указан автор (или авторы)... Таким образом, бегло взглянув на документ (и потратив обычно несколько секунд), человек получает дополнительную информацию о документе и после этого делает вывод: тот это документ, который ему нужен, или нет; читать ли сам текст, содержимое (content) документа или нет. Если бы машина могла также легко понять, какая тема документа, кто его автор и когда он создал этот документ и т.д., тогда реально можно охарактеризовать и автоматически искать документ по большому числу признаков. Если машина не понимает документ, то она принципиально может искать только по словам, содержащимся в документах. [1]

Язык XML

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

Самое важное состоит в том, что XML - это язык метаразметки. Это значит, что он не имеет фиксированного набора тегов и элементов для работы с любыми сферами интересов. Попытки создать конечный набор подобных тегов обречены на неудачу. XML позволяет разработчикам и создателям документов определять нужные им элементы по мере необходимости. Химики могут при помощи тегов описывать элементы, атомы, связи, реакции и другие понятия, принятые в химии. Агенты по недвижимости могут использовать элементы, описывающие квартиры, аренду, комиссионные сборы, местоположение и другие понятия, связанные с недвижимостью. Музыканты могут определить элементы для описания четвертных и половинных нот, тональностей, слов песен и других объектов, встречающихся в музыке. В аббревиатуре XML «X» обозначает extensible -расширяемый. Это значит, что язык может быть расширен и адаптирован в соответствии с различными потребностями. [23, 22]

При своей гибкости в определении элементов XML строг в отношении многого другого. Он устанавливает для XML-документов грамматику, которая регулирует, где могут встречаться теги и как они располагаются, какие имена элементов являются допустимыми, как атрибуты присоединяются к элементам и т. д. Эта грамматика достаточно конкретна для разработки XML-анализаторов, которые могут читать и понимать любой XML-документ. Документы, удовлетворяющие этой грамматике, называются корректными (well-formed). Документ, не являющийся корректным, не допустим, подобно тому как не может быть допустимой программа на языке С, если она содержит синтаксическую ошибку. XML-процессоры отвергают документы с ошибками корректности. [19]

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

Разметка, разрешенная для конкретного XML-приложения, как правило, документирована в определении типа документа (DTD, Document Type Definition). В DTD перечислены допустимые теги разметки и указано, каким образом разметка включается в документ. Каждый конкретный случай сверяется с DTD. Документ, который соответствует DTD, называется действительным (valid). Если он не соответствует DTD, то является недействительным (invalid). Действительность зависит от DTD: документ будет действительным или недействительным в зависимости от того, с каким DTD выполняется сверка.

Не все документы должны быть действительными. Для многих целей достаточно корректности документа. DTD в XML необязательны. С другой стороны, иногда бывает недостаточно одного лишь DTD. Синтаксис DTD ограничен и не позволяет задать многих полезных утверждений, как, скажем «Элемент содержит число» или «Эта строка текста является датой между 1974 и 2032 годами».

XSLT и XSL-FO

Extensible Stylesheet Language (XSL, расширяемый язык таблиц стилей) делится на две части: XSL-трансформации (XSL Transformations, XSLT) и форматирующие объекты XSL (XSL Formatting Objects, XSL-FO).

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

XSL-FO - это полноценное XML-приложение, предназначенное для описания точного размещения текста на странице. В нем есть элементы для представления страниц, блоков тек ста на странице, графики и горизонтальных линеек. Однако в большинстве случаев вам не придется писать непосредственно текст XSL-FO. Вместо этого создается таблица стилей XSLT, преобразующая исходную разметку документа в XSL-FO. Приложение, отображающее документ, читает XSL-FO и показывает его пользователю. Так как ни один из основных браузеров пока непосредственно не поддерживает документы XSL-FO, обычно необходим третий этап, на котором еще один процессор преобразует XSL-FO в другой формат, такой как PDF или TEX. [17]

XSL трансформации для гео-метаданных

На данный момент времени для представления географических метаданных используются следующие XSL трансформации: [30, 31]

ESRI Web Style

FGDC FAQ Style

FGDC Report Style

XML Data Style

ISO Geography Network

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

Систему состоит из двух основных структурных частей: СЕРВЕР и КЛИЕНТ.

Рис 1. Диаграмма зависимости компонентов системы

2.1. Серверная часть

Серверная часть включает в себя: сервер СУБД, WEB-сервер, REFRESH-сервис, DATAConverter-сервис, которые можно размещать на различных компьютерах.

Сервер СУБД представляет собой сравнительно мощный компьютер на котором установлена СУБД Microsoft SQL Server 2000, он выполняет функции хранения данных системы.

WEB-сервер предназначен для предварительной обработки данных и создания пользовательского интерфейса к функциям системы. На него устанавливается Web-сервер Microsoft Internet Information Server 5 (MS IIS 5), включающий в себя интерпретатор ASP. На WEB-сервер может быть возложена функция обеспечения общей безопасности - пользовательские, запросы попадают именно сюда, здесь проверяются права пользователей.

Физически WEB-сервер и сервер СУБД можно объединить на одной машине, что рекомендуется, если СУБД используется только данной системой. В случае, когда WEB- и СУБД-сервер разделены, рекомендуется организовать высокопроизводительное сетевое соединение (например, можно использовать двухточечное соединение 100MBit Ethernet).

Клиент системы работает с пользовательским интерфейсом по протоколу HTTP. Приемлемая скорость работы может достигаться при скорости соединения в 33.6 KBit/s.

На WEB-сервере хранятся ASP-страницы (скрипты) для доступа к данным, и обеспечения менеджмента системы, а так же располагается XSLT модуль, обеспечивающий вывод информации о ресурсе, используя любую из XSL трансформаций:

· ESRI Web Style

· FGDC FAQ Style

· FGDC Report Style

· XML Data Style

· ISO Geography Network.

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

DATAConverter-сервис отвечает за предобработку данных.

2.2. Клиентская часть

Клиентская часть разделена на четыре модуля: UsersResourcesManager, ResourcesManager, ResourcesViewer, XMLMetaDataEditor.

Модуль UsersResourcesManager предназначен для управления пользователями и ресурсами системы, а так же сопоставления пользователей и ресурсов, используется пользователями типа Admin.

Модуль ResourcesManager предназначен для редактирования параметров ресурсов системы, используется пользователями типа Manager и Admin.

Модуль ResourcesViewer предназначен для просмотра и поиска метаданных о ресурсах данных, используется пользователями типа User.

Модуль XMLMetaDataEditor представляет собой редактор файлов метаописания ресурсов, представленных в виде XML-файлов, используется пользователями типа Manager.

Метаданные могут быть представлены с помощью следующих стандартов: CSDGM, ЕСИМО, [Приложение 2].

3. Требования к окружению

3.1. Требования к аппаратному обеспечению

Требования к серверу

· Минимальная аппаратная платформа: PIIC-333 / 128MB / 2GB / Network.

· Рекомендуемая аппаратная платформа: 2PIII-800 / 512MB / 29GB 10K SCSI / Network.

Требования к клиенту

· Минимальная аппаратная платформа: P100 / 32MB / 500MB / Network.

· Рекомендуемая аппаратная платформа: PIIC-333 / 128MB / 1GB / Network.

3.2. Требования к программному обеспечению

Требования к серверной части

· Операционная система Windows 2000 Server, с установленной поддержкой протокола TCP/IP.

· СУБД Microsoft SQL Server 2000.

· HTTP-сервер Microsoft Internet Information Server 5, одновременно являющийся интерпретатором ASP страниц.

Требования к клиентской части

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

3.3. Требования к клиентам

В системе существует три категории пользователей: Пользователь (viewer), Менеджер ресурсов (manager), Администратор (admin).

Пользователь (viewer)

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

Менеджер ресурсов (manager)

Менеджер ресурсов должен обладать знаниями о работе протокола HTTP, иметь представление о ГИС технологиях, об используемых форматах данных, иметь представление о форматах представления метаданных.

Администратор (admin)

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

Администратор должен иметь глубокие познания в сфере установки, конфигурирования и работы с ОС и программным обеспечением, используемым системой. Также ему необходимо знать основы администрирования СУБД вообще и Microsoft SQL Server 2000 в частности. Желательно, чтобы системный администратор имел хотя бы общие познания в языках программирования и описаниях данных, используемых в системе (SQL, ASP, HTML и. др.). Администратор должен изучить техническую документацию к системе Remote Data Searcher (здесь и далее разрабатываемая система будет называться RDS) и руководство администратора системы RDS. Одной из задач администрирования является консультация пользователей системы RDS в случае возникновения у них каких-либо вопросов.

Рис 2. Диаграмма вариантов использования системы

3.4. Требования к интерфейсу

Для разгрузки сервера и канала связи система может поддерживать средства динамической генерации HTML-страниц на стороне клиента (JavaScript, DHTML и другие). Интерфейс должен быть спроектирован так, чтобы из любого графического браузера были доступны все функции системы. Дополнительные средства визуализации (перемещающиеся меню и др.), могут быть недоступны определенным браузерам - например, не поддерживающим расширения DHTML или JavaScript. При входе в систему возможности браузера должны определяться автоматически.

4. Спецификация данных

4.1. Схема данных

Рис 3. Структура базы данных

Сущность TResource - «Ресурс»

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

Таблица. 1 Сущность TResource

Имя поля

Тип поля

Размер

Описание

Resource_Id

int

4

Идентификатор «Ресурс», Ключ

Name_Res

varchar

250

Название

URL_Res

varchar

255

URL адрес

Login_Res

varchar

50

Логин для доступа к ресурсу

Password_Res

varchar

50

Пароль для доступа к ресурсу

Date_Last_Attemt_Refresh

datetime

8

Дата последней попытки обновления

Date_Last_Refresh_Site

datetime

8

Дата последнего обновления, если хоть один файл изменился, то это значение меняется, значение берется из http-заголовка получаемого от данного ресурса

Period_Refresh

int

4

Период обновления в секундах

Time_Refresh_Initial

datetime

8

Начальное время обновления

Number_Repeated_Attemts_File

int

4

Количество повторных попыток обновления, в случае неудачи

Server_TimeOut_Res

int

4

Время, в течение, которого ожидается ответ от сервера, после чего делается пауза (10 секунд)

Response_TimeOut_Res

int

4

Время получения ответа от сервера, если в течение этого промежутка времени не завершилась операция получения информации от сервера, то процесс обновления информации завершается (10 мин), и начинается все сначала

Notification_to_Admin

varchar

250

Уведомление администратору (mini log), при полной неудаче обновления

Total_Size_of_Files

int

4

Общий размер файлов на данном ресурсе

Total_Number_of_Files

int

4

Общее количество файлов на данном ресурсе

Rule_Id

int

4

Идентификатор «Правила обработки ресурса»

XML_Res_MetaData_Path

varchar

255

Путь к локальному файлу описания метаданных ресурса в формате XML

Path_to_LastCopy_of_ResPage

varchar

255

Путь к локальному файлу, содержащему HTML страницу ресурса со ссылками на файлы с данными.

Все поля обязательны

Поле Resource_Id - уникальное, остальные нет.

Сущность TResRule - «Правило обработки ресурса»

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

Таблица. 2 Сущность TResRule

Имя поля

Тип поля

Размер

Описание

Rule_Id

int

4

Ключ

Rule_Res

varchar

8000

Правило обработки ресурса

Rule_Descript

varchar

150

Описание правила обработки локального файла

Все поля обязательны

Поле Rule_Id - уникальное, остальные нет.

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

Таблица. 3 Правила обработки ресурса

Правило

Описание

<cut_before> <htmltags1> </cut_before>

Удалить все содержимое до <htmltags1>

<correct_links> <A HREF='%1'> %2 </correct_links>

1 - Извлечь ссылки на файлы

2 - Извлечь имена файлов

<cut_after> <htmltags2> </cut_after>

Удалить все содержимое после <htmltags2>

Сущность TFile - «Файл»

Данная сущность предназначена для хранения данных об используемых ресурс-файлах.

Таблица. 4 Сущность TFile

Имя поля

Тип поля

Размер

Описание

File_Id

int

4

Идентификатор «Файл», Ключ

Resource_Id

int

4

Идентификатор «Ресурс»

Name_File

varchar

255

Имя файла

URL_File

varchar

255

URL адрес

Date_File

datetime

8

Дата

Size_File

int

4

Размер

Server_TimeOut_File

int

4

Время, в течение, которого ожидается ответ от сервера, после чего делается пауза (10 секунд) (при первом обращении наследуется от сущности Resource)

Response_TimeOut_File

int

4

Время получения ответа от сервера, если в течение этого промежутка времени не завершилась операция получения информации от сервера, то процесс обновления информации завершается (10 мин), и начинается все сначала (при первом обращении наследуется от сущности Resource)

Number_Repeated_Attemts_File

int

4

Количество повторных попыток обновления, в случае неудачи

Format_Id

int

4

Идентификатор «Формат файла»

Flag_Local_File_Modify

int

4

Флаг на создание локальной обработанной копии файла

XML_File_MetaData_Path

varchar

255

Путь к локальному файлу описания метаданных файла в формате XML

Все поля обязательны

  • Поле File_Id - уникальные, остальные нет.

Сущность TFileFormat - «Формат файла»

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

Таблица. 5 Сущность TFileFormat

Имя поля

Тип поля

Размер

Описание

Format_Id

int

4

Ключ

Format

varchar

100

Формат файла

File_Descript

varchar

250

Описание формата файла

Все поля обязательны

  • Поле Format_Id - уникальное, остальные нет.

Сущность TLocalFileModify - «Обработанный локальный файл»

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

Таблица. 6 Сущность TLocalFileModify

Имя поля

Тип поля

Размер

Описание

File_Id

int

4

Ключ

Local_File_Id

int

4

Идентификатор «Локальный файл»

Size_LF

int

4

Размер файла в байтах

Date_LF

datetime

8

Дата локального файла

Path_to_File_on_Local_Disk

varchar

255

Локальный путь к файлу

Modif_Rules_Id

int

4

Идентификатор «Правила модификаций»

Initial_Down_Time

datetime

8

Начальное время скачивания

Time_to_Kill

datetime

8

Время удаления файла

Number_Repeated_Attemts_LF

int

4

Количество повторных попыток скачивания, в случае неудачи

Server_TimeOut__LF

int

4

Время, в течение, которого ожидается ответ от сервера, после чего делается пауза (10 секунд)

Response_TimeOut__LF

int

4

Время получения ответа от сервера, если в течение этого промежутка времени не завершилась операция получения информации от сервера, то процесс обновления информации завершается (10 мин), и начинается все сначала

Format_Id

int

4

Идентификатор «Формат файла»

Все поля обязательны

  • Поле File_Id - уникальные, остальные нет.

Сущность TFileRule - «Правило обработки локального файла»

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

Таблица. 7 Сущность TFileRule

Имя поля

Тип поля

Размер

Описание

Modif_Rules_Id

int

4

Ключ

Rule_File

varchar

8000

Правило обработки локального файла

Rule_Descript

varchar

250

Описание правила обработки локального файла

Все поля обязательны

Поле Modif_Rules_Id - уникальное, остальные нет.

  • Каждая запись поля Rulex представляет собой набор XML тегов, где каждый тег характеризует определенную макрокоманду. Используется для обработки файла. Теги могут быть следующих видов:

Таблица. 8 Правила обработки файлов

Правило

Описание

<cmd>gzip параметры

Запустить внешний процесс gzip с параметрами

<cmd>mif_shape параметры

Конвертировать в файл в формате mif в файл в формате shape используя параметры

<cmd>h52gif параметры

Конвертировать в файл в формате hdf5 в файл в формате shape используя параметры
  • <cmd>shapetrans

>projection

>offset scale
  • Выполнение действий над shape файлом

изменение используемой проекции

выборка определенного региона

Сущность TUser - «Пользователь»

Данная сущность предназначена для хранения данных о пользователях.

Таблица. 9 Сущность TUser

Имя поля

Тип поля

Размер

Описание

User_Id

int

4

Ключ

FirstName

varchar

50

Имя

LastName

varchar

50

Фамилия

Positionx

varchar

250

Должность

Role_Id

int

4

Идентификатор «Роль пользователя»

Login_User

50

20

Логин пользователя

Password_User

varchar

50

Пароль пользователя

Email

varchar

250

Email

Все поля обязательны

  • Поля User_Id - уникальные, остальные нет.

Сущность TUserRole - «Роль»

Данная сущность предназначена для хранения данных о ролях пользователей.

Таблица. 10 Сущность TUserRole

Имя поля

Тип поля

Размер

Описание

Role_Id

int

4

Ключ

Roles

varchar

10

Роль (Admin, Manger, User)

Role_Descript

varchar

20

Описание роли

Все поля обязательны

Поле Role_Id - уникальное, остальные нет.

Сущность TResourceUser - «Ресурс - Пользователь»

Данная сущность предназначена для обеспечения связи «многие-ко-многим» для таблиц «Пользователь» и «Ресурс».

Таблица. 11 Сущность TUserRole

Имя поля

Тип поля

Размер

Описание

Resource_Id

int

4

Ключ

User_Id

int

4

Ключ
  • Все поля обязательны
  • Поля Resource_Id, User_Id - уникальные.

4.2. Формат метаданных описания ресурса

Формат метаданных описания ресурса представляет собой XML файл, основанный на стандарте Content Standard for Digital Geospatial Metadata (CSDGM), разработанный организацией FGDC (Federal Geographic Data Committee). [см. приложение 2]

<?xml version="1.0" ?>

- <metadata xml:lang="ru">

+ <Producer>

+ <idinfo>

+ <metainfo>

- <spdoinfo>

<direct Sync="TRUE" />

- <ptvctinf>

+ <esriterm Name="Areas">

+ <sdtsterm Name="Areas">

</ptvctinf>

</spdoinfo>

- <spref>

+ <horizsys>

</spref>

- <eainfo>

+ <detailed Name="Areas">

</eainfo>

- <distinfo>

- <stdorder>

+ <digform>

<transize Sync="TRUE" />

<dssize Sync="TRUE" />

</digtinfo>

</stdorder>

</distinfo>

</metadata>

5. Проект

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

5.1. Средства реализации

СУБД

Можно сказать, что общепринята практика использования «легких» СУБД типа MySQL или PostgreSQL в качестве back-end для систем с WEB-интерфейсом. Это объясняется рядом факторов, в основном ориентированностью этих СУБД на WEB-приложения. Так же надо отметить, что эти СУБД не надо лицензировать. [1, 29]

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

Проанализировав все выше перечисленное, было принято решение использовать для хранения данных какую-либо мощную промышленную СУБД, например, Microsoft SQL Server 2000 или Oracle 9. Выбор в пользу СУБД Microsoft SQL Server был обусловлен в основном двумя соображениями: во-первых, его легче конфигурировать, во-вторых, организация-заказчик имеет уже работающий сервер.

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

Существует два основных подхода к выбору языка программирования для реализации приложений, имеющих WEB-интерфейс. Один подход заключается в том, чтобы, используя какой-либо компилируемый язык высокого уровня типа C/C++, написать программу, работающую как CGI. Второй подход заключается в использовании скриптовых языков, ориентированных на WEB-приложения - PHP, Perl, ASP (Active Server Pages), и др. В их пользу говорит сравнительная легкость разработки приложений, специальные средства для WEB-программирования. Для работы программ на языках PHP и Perl нужны специальные интерпретаторы, а поддержка ASP встроена в операционную системы MS Windows Server 2000, под которой работает MS SQL Server 2000, а так же средства ASP позволяют объединить возможности HTML-страниц, команд сценариев и компонентов COM в интерактивных веб-страницах и мощных веб-приложениях, делают удобным и легким процесс их создания и изменения. Поэтому было принято решение производить разработку интерфейса с использованием ЯП ASP. [9, 10]

Сервис добавления и обновления информации о ресурсе и его файлах должен выполнятся на сервере 24 часа в сутки, и при этом не занимать много ресурсов оперативной памяти и процессорного времени, решить такую задачу может программа написанная на ЯП Visual С++. [10, 11]

Операционная система и другие компоненты

В качестве операционной системы для сервера было решено использовать Microsoft Windows 2000 Server. Выбор конкретной версии ОС Microsoft Windows 2000 Server целиком и полностью продиктован системными требованиями версии СУБД Microsoft SQL Server 2000.

В качестве WEB-сервера система использует Microsoft Internet Information Server 5 (MS IIS 5) в основном из соображений его высокой надежности и интегрируемости, так же можно отметить то, что MS IIS 5 имеет самую высокую скорость работы с MS SQL Server 2000. MS IIS 5 распространяется вместе с сервером Microsoft Windows 2000 Server.

метаданные файл приложение информация

5.2. Подсистема «Сбор и мониторинг информации»

Рис 4. Диаграмма деятельности для модулей REFRESHER и DATA_CONVERTER

5.3. Подсистема получения файлов по протоколу FTP и HTTP

Hypertext Transfer Protocol

Hypertext Transfer Protocol (протокол передачи гипертекстов) начинался как один из простейших прикладных протоколов Internet. Когда Web только начинал приобретать популярность, протокол HTTP состоял из трех простых команд: GET, POST и HEAD. Эти три команды выполняли основные функции Web. Команда GET запрашивала у Web-сервера определенный объект, скажем, HTML-страницу или файл с рисунком, а Web-сервер отвечал, отправляя объект через то же гнездовое соединение. Команда HEAD запрашивала у сервера описание объекта, скажем, тип файла объекта (HTML, рисунок и т.д.), его размер и время последнего обновления. Команда POST применялась для отправки данных Web-серверу, который обычно передавал эту информацию отдельному приложению для обработки и генерирования некоторого динамического вывода, возвращаемого Web-браузером. [18]

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

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

В конечном итоге, в протокол HTTP уже было внесено множество изменений, и, вероятно, появится еще больше.

5.3.1.1 Содержание запроса и ответа HTTP протокола

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

Клиент инициирует транзакцию следующим образом:

1. Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию - 80). Затем посылается запрос документа с указанием HTTP команды (называемой методом), адреса документа и номера версии HTTP. Например:

GET /index.html HTTP/1.0

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

User-Agent: Mozilla/2.02Gold (WinNT; I)

Accept: image/gif, image/jpeg, */*

3. Послав запрос и заголовки, клиент может отправить дополнительные данные (тело запроса). Эти данные используются, например, CGI-программами, применяющими метод POST.

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

1. Первая часть ответа - строка состояния, содержащая версию протокола HTTP, код состояния и описание, которое представляет собой просто понятный для человека текст, поясняющий код состояния. Например:

HTTP/1.0 200 OK

2. После строки состояния сервер передает клиенту информацию заголовка ответа, содержащую данные о самом сервере и затребованном документе. Завершает заголовок пустая строка. Например:

Date: Fri, 20 Sep 1996 08:17:58 GMT

Server: NCSA/1.5.2

Last-modified: Mon, 17 Jun 1996 21:53:08 GMT

Content-type: text/html

Content-length: 2482

3. Если запрос клиента успешен, то сервер посылает затребованные данные. Это может быть копия файла или документ сформированный "на лету". Если запрос клиента удовлетворить нельзя, то сервер передает дополнительные данные в виде удобного для человека разъяснения причин, по которым сервер не смог выполнить запрос.

В HTTP 1.0 после передачи сервером затребованных данных следует разъединение с клиентом и транзакция завершается, если не был передан заголовок Connection: Keep Alive. В HTTP 1.1 сервер по умолчанию не разрывает соединение и клиент может посылать другие запросы. Это позволяет сэкономить время и затраты клиента, которому не приходится заново соединяться с тем же сервером. Таким образом, в HTTP 1.1 транзакция может циклически повторяться, пока клиент или сервер не закроет соединение явно.

5.3.1.2 Методы

Метод - это HTTP-комманда, с которой начинается первая строка запроса клиента. Метод сообщает серверу о цели запроса. Чаще всего используются методы GET, HEAD и POST (регистр имеет значение).

GET

Этим методом запрашивается информация, расположенная на сервере в указанном в запросе месте. Методом GET web браузеры обычно получают документы для визуализации. Результатом такого запроса может быть, например, файл, лежащий на сервере или же сформированный специально для этого запроса. Например:

GET / HTTP/1.0

User-Agent: Simple Web client

Accept: */*

HEAD

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

· время изменения документа;

· размер документа;

· тип документа;

· тип сервера.

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

HEAD / HTTP/1.0

User-Agent: Simple Web

Accept: */*

POST

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

· сетевых служб (например телеконференций)

· программ с интерфейсом типа "командная строка"

· выполнения операций в базах данных

Например:

POST / HTTP/1.0

User-Agent: Simple Web client by Eugen Kuleshov

Accept: */*

Content-type: application/x-www-form-urlencoded

Content-length: 16

test=20&test2=22

Рис 5. Содержание запроса и ответа HTTP протокола

Подробнее можно почитать в соответствующем RFC (HTTP 1.0 - rfc1945 или HTTP 1.1 - rfc2068).

File Transfer Protocol

File Transfer Protocol (Протокол передачи файлов) является несколько более сложным и находится в применении намного дольше HTTP. FTP используется для перемещения файлов между двумя или несколькими компьютерами, независимо от их типов. Он предоставляет клиентскому приложению возможность перемещаться в рамках файловой системы сервера, получать и размещать файлы на сервере, если клиент обладает на это соответствующим разрешением. Если пользователь имел соответствующие разрешения на работу с FTP-сервером, с помощью протокола FTP он мог даже удалять файлы с сервера.

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

Третий аспект протокола FTP заключается в том, для выполнения своих задач он использует несколько гнездовых соединений. Одно гнездовое соединение открывается клиентом и остается открытым вплоть до завершения сеанса. Это соединение называется командным соединением (command connection). Второе соединение открывается сервером или клиентом для передачи файлов между двумя компьютерами (рис.6). Соединение открывается при каждой команде клиента, требующей передачи данных между двумя компьютерами, и закрывается, когда передаются все затребованные командой данные. В протоколе FTP используются два гнездовых соединения

Рис 6. Передачи файлов между двумя компьютерами

5.3.1.3 Алгоритм работы протокола FTP

1. Сервер FTP использует в качестве управляющего соединение на TCP порт 21, который всегда находится в состоянии ожидания соединения со стороны пользователя FTP.

2. После того как устанавливается управляющее соединение модуля “Интерпретатор протокола пользователя” с модулем сервера -- “Интерпретатор протокола сервера”, пользователь (клиент) может отправлять на сервер команды. FTP-команды определяют параметры соединения передачи данных: роль участников соединения (активный или пассивный), порт соединения (как для модуля “Программа передачи данных пользователя”, так и для модуля “Программа передачи данных сервера”), тип передачи, тип передаваемых данных, структуру данных и управляющие директивы, обозначающие действия, которые пользователь хочет совершить (например, сохранить, считать, добавить или удалить данные или файл и другие).

3. После того как согласованы все параметры канала передачи данных, один из участников соединения, который является пассивным (например, “Программа передачи данных пользователя”), становится в режим ожидания открытия соединения на заданный для передачи данных порт. После этого активный модуль (например, “Программа передачи данных сервера”) открывает соединение и начинает передачу данных.

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

Класс CInternetSession

Класс CInternetSession открывает класс соединения. Этим классом соединения может быть обобщенный класс соединения CInternetConnection, однако, более вероятно, им будет класс, ориентированный на определенный тип соединения -- CHttpConnection, CFtpConnection или CGopherConnection. Открыв класс соединения, можно выполнять специфические команды протоколов для выполнения различных задач, которые может реализовать каждый из протоколов.

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

Для протоколов FTP существует группа классов, имеющих функциональные возможности для поиска и выявления файлов. Этими классами являются CFileFind, как базовый класс, а также CFtpFileFind как потомок. Последним классом Winlnet MFC является CInternetException, класс исключений, срабатывающий при возникновении любого исключения Winlnet. Класс CInternetException применяется для обработки любых исключений, порождаемых другими классами Winlnet MFC.

Основы сеанса internet

Отправной точкой каждого MFC-приложения Winlnet является базовые классы Internet -- CInternetSession, CInternetFile, CInternetException и CInternetConnection. CinternetSession - базовый класс.

5.3.1.4 Создание экземпляра CInternetSession

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

Если приложение должно работать в более сложной среде, скажем, через прокси-сервер, может потребоваться более жесткий контроль над созданием экземпляра CInternetSession.

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

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

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

Таблица 12. Значения параметра типа доступа

Значение

Описание

INTERNET_OPEN_TYPE_PRECONFIG

Значение по умолчанию; при этой установке используется конфигурация доступа из реестра.

INTERNET_OPEN_TYPE_DIRECT

Прямое соединение с Internet.

INTERNET_OPEN_TYPE_PROXY

Подключение к Internet через прокси-сервер.

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

Шестой и последний параметр, которые можно передать конструктору CInternetSession, является флагом, определяющим установки, перечисленные в табл. 13.

Таблица 13. Установки сеанса Winlnet

Значение

Описание

INTERNET FLAG OFFLINE

Указывает, что все затребованные данные не будут кэшироваться ни локально, ни в шлюзе, через который данные передаются.

INTERNET_FLAG_DONT_CACHE

Указывает, что все операции Winlnet будут выполняться асинхронно.

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены