Содержание к диссертации
Введение
ГЛАВА 1. Задача предоставления данных пользователям отраслевой системы мониторинга рыболовства 9
1.1 Отраслевая система мониторинга 9
1.2 Основные типы информации осм и методов их сбора 12
1.3 Пользователи ОСМ 16
1.4 Возможные подходы к решению задач сбора, хранения и предоставления данных в ОСМ 21
1.5 Обзор технологий web-программирования 25
1.6 Выводы 32
ГЛАВА 2. Архитектура построения системы 33
2.1 Логическая схема работы системы распространения данных... 33
2.2 Архитектура реализации сбора и распространения данных 38
2.3 Основные информационные блоки системы и требования к ним 42
2.4 Протокол обмена данными 51
2.5 Выводы 54
ГЛАВА 3. Базовые программные элементы системы .. 56
3.1 Основные программные модули системы 56
3.2 Требования к системе взаимодействия модулей 58
3.3 Система передачи данных и контроль за работой системы 63
3.4 Модуль ввода информации в базу данных 64
3.5 Модуль фильтрации 72
3.6 Интерфейс пользователя 75
3.7 Выводы 87
ГЛАВА 4. Реализация системы распространения и предоставления даннъгх отраслевого мониторинга рыболовства 88
4.1 Организация сбора и рассылки данных в ОСМ 88
4.2 Информационные узелы 93
4.3 Картографический web-интерфейс к данным мониторинга флота и окружающей среды 100
4.4 Локальное рабочие место пользователя 112
4.5 Выводы 118
Заключение ...120
Литература 122
- Возможные подходы к решению задач сбора, хранения и предоставления данных в ОСМ
- Основные информационные блоки системы и требования к ним
- Требования к системе взаимодействия модулей
- Картографический web-интерфейс к данным мониторинга флота и окружающей среды
Введение к работе
Рыбный промысел традиционно имеет большое значение для стран, имеющих выход к морю. В некоторых регионах России сегодня рыболовной промысел является основной статьей дохода. Следовательно, оперативное получение информации о деятельности рыболовного флота и предоставление её заинтересованным государственным организациям является весьма актуальной задачей.
Такая информация необходима для работы различным отраслевым организациям, а так же организациям других ведомств, решающих задачи связанные с контролем экономической деятельности рыболовного флота или с мониторингом окружающей среды. С другой стороны развитее технических средств связи и спутникового позиционирования позволяют ставить качественно новые задачи по оперативности и точности получаемой информации.
Для более эффективного решения задач мониторинга рыболовного флота Российской Федерации была создана отраслевая система мониторинга (ОСМ). Основной целью ОСМ является обеспечение эффективного государственного управления водными биоресурсами в интересах экономической безопасности Российской Федерации, рационального использования, изучения и сохранения рыбных запасов. Первая очередь ОСМ была введена в эксплуатацию в 2000 году. Создание и развитие отраслевой системы мониторинга рыболовства является достаточно сложной задачей, требующей решения многих вопросов из разных областей знания. Среди этих вопросов заметное место занимаю проблемы связанные с созданием программных систем для решения задач информационного наполнения системы, распространения данных и решения прикладных задач конечных пользователей.
Данная работа посвящена созданию автоматизированной распределенной системы распространения и предоставления данных ОСМ.
Главная задача такой системы - организация оперативного обмена информацией между различными субъектами ОСМ.
В первой главе проведен анализ задачи организации автоматизированной системы распространения и предоставления данных отраслевого мониторинга рыболовства.
Приводится обзор основных характеристик и возможностей отраслевой системы рыболовства. Описывается основные типа её информационного наполнения и методов сбора данных. Для каждого типа информации описывается, каким образом данные попадают в системы и как часто они обновляются.
Описываются основные группы пользователей ОСМ, их
потребности в различного рода данных мониторинга рыболовного флота и
окружающей среды, оперативности доступа к данным, возможности
каналов связи. Суммируются основные особенности, важные для
S проектирования системы предоставления данных.
В главе дан анализ возможных подходов к решению задач сбора,
хранения и предоставления данных в ОСМ. Обсуждается возможные подходы к репликации данных, и формулируются требования к системе
репликации БД ОСМ. Дан обзор некоторых технологий программирования, которые могут быть использованы для разработок. Предложено использовать для решения поставленной задачи предоставления данных пользователям ОСМ механизм асинхронной репликации данных и пользовательский интерфейс на основе web-технологий.
Сформулированы требования к созданию автоматизированной
системы распространения и предоставления данных отраслевого
мониторинга рыболовства.
v Вторая глава посвящена описанию предлагаемой архитектуры
построения системы.
Приводится анализ логической схемы информационных потоков отраслевой системы мониторинга. Выделены следующие уровни: уровень «Источники», уровень «Сборка», уровень «Хранения и распространения
* данных», уровень «Получатели данных». Представлена схема
взаимодействия этих уровней. Описаны функциональные требования к
этим уровням.
Выделены следующие функциональные блоки. Для каждого из них переведен анализ технических требований, которым они должны удовлетворять. Предложена технологическая схема, реализующая обмен информацией в системе, в соответствии с описанной выше логикой информационных уровней.
Описывается протокол обмена данными в системе. Предлагаемый
формат представляет собой основанный на XML язык разметки текста.
Формат ориентирован на построчную интерпретацию, по сути, он
V представляет собой специальным образом записанную последовательность
SQL команд.
* В третьей главе описываются базовые элементы системы.
Определяются основные программные модули системы, которые
* необходимы для реализации описанных выше схем обмена данными.
Основные модули системы должны реализовывать следующие функции:
Передача данных между узлами системы.
Диспетчеризация информационных потоков.
Ввод полученных данных в БД ОСЫ в каждом из узлов системы.
Удаленный контроль работы модулей системы в разных узлах.
Интерфейс пользователя, обеспечивающий базовые возможности для просмотра и анализа данных в БД ОСМ.
Сформулированы требования к организации взаимодействия модулей в системе и описаны принципы, реализации такого взаимодействия в программном обеспечении, разработанным автором.
Определены выбранные для разработок операционная система и средства разработки. В главе также подробно описываются реализованные программные компоненты.
Четвертая глава посвящена описанию применений предложенной технологической схемы и разработанных программных модулей для сбора и распространения данных в отраслевой системе мониторинга.
Описана организация сбора и рассылки данных в ОСМ. Рассмотрен технологический процесс сбора данных о позиционировании и промысловой деятельности судов дальневосточного бассейна и информации о деятельности рыболовного флота в европейской части России. Эти данные собираются в объединенную базу данных ОСМ в головном узле системы в Национальном Центре Мониторинга и Связи Госкомрыболовства (НЦМС). НЦМС так же занимается поддержкой справочных таблиц базы данных. Приведена Схема информационных потоков ОСМ.
Дано описание предоставления данных организациям при помощи организации информационных узлов (ИУ). ИУ ОСМ создаются в регионах на государственных предприятиях, обеспечивающих реализацию управления водными биологическими ресурсами. Цель создания ИУ ОСМ - это обеспечение государственных предприятий отрасли необходимой программно-технической средой получения и доставки данных в единый информационный ресурс ОСМ и эффективное информационное обеспечение работы органов рыбоохраны, служб наблюдения за флотом, научных подразделений, занимающихся оценкой и состоянием рыбных запасов и др.
Далее дан анализ задачи обеспечения оперативной информацией, поступающей в ОСМ, и системой ее анализа отраслевых пользователей,
работающих удаленно от центральных и региональных информационных узлов ОСМ (например, инспекторов, находящиеся на судах). В рамках данной работы было разработано решение для этой задачи - локальное рабочее место пользователя (ЛРМП)
Предложенное программно-аппаратное решение работает под управлением ОС Windows. Что поваляет использовать в качестве арпаратной базы рабочую станцию, либо портативный компьютер, с сохранением всех базовых функций современного персонального компьютера (пакеты офисных программ, работа с Интернет и т.п.).
Описаны требования по системе поступления данных на ЛРМП и основные программные элементы необходимые для обеспечения работы ЛРМП. Рассказано о опыте практического использования ЛРМП при решении реальных задач отраслевой системы мониторинга.
В заключении приводятся основные результаты, выносимые на защиту.
Возможные подходы к решению задач сбора, хранения и предоставления данных в ОСМ
Итак, в отрасли имеются организации, занимающиеся сбором информации, имеющей общеотраслевую ценность. Возникает необходимость разработки системы, которая позволила бы использовать такие данные в работе всех заинтересованных пользователей. Такая система должна реализовывать интерфейс для предоставления данных организациями-источниками информации, обеспечить доставку информации в режиме близком к режиму реального времени в заинтересованные организации и предоставлять разработчикам и пользователям удобный интерфейс для работы с данными. При таком подходе создается некий единый информационный общеотраслевой ресурс, который постоянно поддерживается в актуальном состоянии [37].
Реализация системы хранения данных в виде реляционной базы данных [45-48] представляется весьма удачным решением. Такой подход предоставляет разработчику, или конечному пользователю стандартизированный, хорошо знакомый интерфейс для построения запросов в виде языка SQL ([49-54]), который обладает достаточным уровнем гибкости для решения прикладных задач.
Современные СУДБ позволяют так же решить проблему разграничения прав доступа, а так же эффективно решать вопросы ссылочной целостности и транзакций. Формат БД хранения данных разрабатывается в соответствии с потребностями отраслевых организаций и является фиксированным. В дальнейшем мы будем называть этот формат БД ОСМ (база данных отраслевой системы мониторинга).
Таким образом, задача сбора информации сводится к представлению данных в терминах БД ОСМ. После этого информация может быть собрана в некоем централизованном хранилище данных (центральной базе данных), и уже оттуда предоставляться конечными пользователям.
Учитывая сильно распределенный характер системы и современное состояние каланов связи, актуальным является вопрос об организации взаимодействия пользователей с центральной БД. С технической точки зрения не представляет сложности открыть доступ удаленным пользователям к этой базе данных напрямую, но на практике такой способ работы мало эффективен. Это связано с тем, что, при таком способе работы, происходит активный обмен информацией между сервером и клиентом, что в свою очередь порождает ряд вопросов связанных с безопасностью, оптимизацией трафика и т.д.
В некоторых прикладных задачах можно эту схему можно модернизировать, введя на стороне сервера модуль, осуществляющий реализующий представление данных в более подходящим для передачи по публичным каналам связи. В частности это можно реализовать как web-интерфейс к данным ОСМ.
Web технологии ([55-66]) в последнее время широко используются для организации работы удаленных пользователей и часто это именно интерфейс для работы с базой данных. Широкое распространение этого подхода связанно с рядом его технологических достоинств. В частности, один и тот же web интерфейс может использоваться для как для работы по сети Интернет, так и по локальной сети организации. Работа с таким интерфейсом не требует установки на рабочие место пользователя специального программного обеспечения и, как правило, не требовательна к ресурсам машины пользователя.
С другой стороны, web-технологии имеют так же и ряд недостатков. В первую очередь это время реакции при работе с таким интерфейсом. Это время на прямую зависит от качества связи с сервером. Но даже при работе по локальной сети web-технологии имеют ряд ограничений на скорость работы, так как специфика технологий не позволяет организовать эффективное кэширование данных на стороне клиента.
Принципиально другим подходом к предоставлению данных удаленным пользователям является организация в локальной копии БД ОСМ. Для пользователей-организаций такая БД может быть расположена на отдельном сервере баз данных в локальной сети, для пользователей не имеющих такой возможности, например мобильные пользователи системы, база данных может быть установлена непосредственно на рабочее место пользователя.
Таким образом, мы имеем задачу организации репликации данных ( см., например, [47] ). Надо сразу оговориться, что метод предоставления данных путем репликации БД ОСМ не рассматривается не как замена доступу через web, а как решение для другого класса задач. Эти два метода могут применяться одновременно. Так пользователи могут работать с данными локальной копии БД ОСМ через web-интерфейс общего назначения.
В задачах репликации данных возможны два различных сценария решения. Первый вариант, синхронная репликация, подразумевает, что обновление всех копий данных выполняются как часть самой транзакции обновления. Другими словами, все копии копируемых данных обновляются одновременно с изменением исходной копии. Для некоторого класса задач такое требование просто необходимо, например, в случаи финансовых операций, но ему свойственны определенные недостатки. В частности, транзакция не может быть завершена, если один из узлов с копией данных окажется недоступным. Кроме того, большое количество сообщений, необходимых для координации процесса синхронизации данных, создает значительную дополнительную нагрузку на сеть. В условиях, когда взаимодействие между узлами осуществляется по публичным каналам связи, а не в пределах корпоративной сети, такие ограничения оказываются неприемлемыми. Другой, асинхронный механизм, репликации предусматривает обновление целевых баз данных после обновления исходной БД. Задержка в восстановлении согласованности данных зависит от конкретных условий работы и реализации механизма. Однако в конечном итоге данные во всех копиях будут приведены в синхронное состояние. Хотя такой подход нарушает принцип независимости распределенных данных, он вполне может рассматриваться как приемлемый компромисс между требованиями обеспечения целостности и доступности данных. В случае ОСМ не требуется, что бы конечные пользователи работали с точно синхронизованной на текущей момент копией данных. Выше мы определили пределы допустимой задержки как несколько минут. С другой стороны надо понимать, что это время в расчете на приемлемое качество канала связи.
Основные информационные блоки системы и требования к ним
Следует обратить внимание на важность этапа верификации данных в АИУ, и как следствие необходимости наличия в активном информационном узле самосогласованной БД ОСМ, содержащую всю необходимую для этого информацию. Это может привести, например, к тому, что во входящий в АИУ поток будет включаться данные (справочники, отчетная информация и т.п.), не нужные непосредственно для работы АИУ. Может показаться, что хорошо реализованный ОСМ конвертор не нуждается в дополнительных проверках. Но процесс верификации данных является необходимой частью формирования потока пополнения, т.к. он происходит одновременно с вводом данных и только так можно гарантировать, что поток данных, формируемый АИУ, будет без ошибок усваиваться системой ввода как в ЦУ, так и в информационных узлах. В случаях же возникновения проблем только АИУ, производящий поток данных, может их решить. Возможно так же реализовать систему контроля на другом уровне, скажем ЦУ. Но в этом случае время реакции на ошибки сильно возрастает. Особенно если принять во внимание сильно распределенный характер ОСМ.
Отметим, что, так как АИУ является для системы в целом источником определенного рода информации, то его БД все время содержит актуальные данные, относящиеся к его компетенции. Следовательно, такого рода данные, приходящие к нему во входящем потоке данных из ЦУ или узла рассылки следует игнорировать. Имеет смысл реализовать этот контроль в таком виде, чтобы проверки на верификацию локально формируемых данных и фильтр входящего потока осуществлялся однотипно и конфигурировался одними и теме же настройками системы ввода данных. Наиболее сложным функциональным блоком системы является активный узел, с несколькими получателями, часть из которых так же является активными информационными узлами (рис. 2.6). Такой узел взаимодействует с другими блоками системе следующим образом: он получает информацию из ЦУ; отсылает необходимую информацию узлам, получающими данные ОСМ через него (такие ИУ мы дальше будем называть зависящими от рассматриваемого АИУ); принимает от некоторых из этих узлов формируемые ими данные; и отсылает в ЦУ данные, полученные им от зависящих от него узлов, а так же данные, формируемые им самим. Такой узел совмещает в себе функциональность АИУ и узла рассылки. При этом представляется целесообразным провести некоторую оптимизацию потоков данных.
Так же как и обычный АИУ, АИУ с рассылкой данных реализует некоторое количество ОСМ конверторов и валидацию получаемых от них данных одновременно с вводом в локальную БД. Полученный таким образом фильтрат попадает в исходящий из узла поток данных для ЦУ и в поток данных, предназначенный для зависящих ИУ. Этот поток проходит через систему фильтрации, и каждый ИУ получает необходимый ему объем данных.
Далее узел получает данные из зависящих узлов. Эти данные вводятся в локальную БД, попадают в поток данных для зависящих ИУ и передаются ЦУ. Таким образом, данные от одного из зависящих узлов, попадают в локальную БД узла и всем узлам-получателям без необходимости перекачки этих данных в ЦУ и обратно. При этом возможно при помощи системы фильтрации избежать перекачки данных, полученных из одного из зависящих узлов обратно ему же. Но такой оптимизации можно и не делать, если это упростит настройки системы и дополнительный входящий трафик в зависящий узел является приемлемым. Это не приведет ни к каким последствиям, т.к. АИУ, формирующий данные, не будет усваивать эти данные из входного потока. Данные, полученные рассматриваемым узлом от ЦУ, проходят через фильтр, удаляющий оттуда информацию, лежащую в компетенции узла и зависящих узлов. Это необходимо, т.к. ив локальной БД и в БД зависящих ИУ такие данные вследствие описанной выше оптимизации потоков поступают всегда раньше, чем они приходят из ЦУ и таким образом информация, уже находящаяся в указанных БД, всегда более актуальна. После этого данные усваиваются в локальную БД и попадают в поток данных для зависящих узлов, после чего они проходят через систему фильтрации и передаются в зависящие узлы.
Учитывая, что может потребоваться верификация любой БД системы с БД ЦУ, представляется необходимым, чтобы вся информация, проходящая через рассматриваемый узел к зависящим узлам, усваивалась в локальную БД. Даже если эти данные не нужны в рассматриваемом АИУ для работы, а требуются только для одного из зависящих узлов, их нужно ввести в локальную БД. В таком случае, как правило, пользователи рассматриваемого узла вообще не работают с таблицами БД, для которых предназначаются эти данные. Следовательно, дополнительные расходы такого подхода связанны только с дисковым пространством сервера БД и не повлияют на быстродействие при работе пользователей узла с БД. Взамен мы получаем существенное упрощение схемы в целом. Аналогично при пересылке данных от зависящих узлов в ЦУ эти данные необходимо ввести в локальную БД. Это не значит, однако, что эти данные обязательно нужно передать во все зависящие узлы.
Таким образом, мы видим, что взаимодействие функциональных блоков системы организуется в древовидную структуру. Подытожим основные принципы построения системы сбора и рассылки информации.
Требования к системе взаимодействия модулей
В данном разделе сформулированы требования к организации взаимодействия модулей в системе и описаны принципы, реализации такого взаимодействия в программном обеспечении, разработанным автором.
Так как система является распределенной и работает в автоматическом режиме, то очень важно обеспечить сохранность информации на протяжении всего цикла передач и обработок даже в случаи возникновения сбоев и нештатных ситуаций. Примером форс-мажорных обстоятельств может служить аварийное выключение питания. И хотя эта частная проблема имеет свое частное решение в виде, например использования систем бесперебойного электропитания ( UPS ), но мы никогда не можем гарантировать, что все подобные возможности исключены и для системы обеспеченны стопроцентно надежные условия работы. В идеале, в случаи возникновения какого-либо сбоя мы должны иметь возможность запустить работу системы с того места, где она была прервана сразу, как только причины аварии будут устранены.
Таким образом, мы не можем допускать того, чтобы в ходе обработки и передачи информации данные находились только в оперативной памяти программы. Мы должны обеспечить их хранение в энергонезависимой памяти компьютера. Самым очевидным решением является хранение данных в файловой системе в виде файлов.
Передача информации в системе происходит в виде документов обменного формата ОСМ. Как отмечалось раньше, этот формат ориентирован на построчную интерпретацию и по своей логике похож на последовательность SQL команд, и хотя формат позволяет группировать эти команды в транзакции, тем не менее, сам по себе он не обеспечивает правильной последовательности данных, необходимых для ввода информации в БД, с учетом поддержания логической целостности. За этим должен следить узел, поставляющий данные в отраслевую систему мониторинга. Таким образом, естественной единицей информации при передаче данных в рамках системы является документ обменного формата, сформированный в исходном центре сбора. В случаи представления информации в виде файлов проще говорить об обменных файлах.
Так как алгоритм работы системы состоит из различных задач, которые могут решать разные модули, то нам необходим универсальный подход к передаче информации между этими процессами. В разработанной системе выбран следующий подход: каждый модуль получает на вход набор файлов в определенном месте файловой системы, модуль уничтожает эти файлы после успешного завершения цикла своей работы, и результатом работы модуля являются файлы в другом месте файловой системы локального или удаленного компьютера, либо изменение информации в базе данных.
При запуске цикла обработки модуль ищет в определенном для него месте файловой системы файлы с именами, подпадающими под заданный шаблон. В ходе работы модуль либо передает эти файлы с одного компьютера на другой, либо обрабатывает информацию, содержащуюся в найденных файлах, и создает переработанные файлы и/или вводит данные в БД. В такой схеме файлы созданные одним модулем являются исходными для другого.
Ранее, при описании логики работы системы и схем отдельных узлов мы говорили об информационных потоках. Если мы говорим о файлах формата как об основной единице передача информации между модулями системы, то для реализации информационных потоков внутри системы необходимо гарантировать нужную последовательность обработки этих файлов. В разработанной системе это было сделано при помощи соглашения об именовании файлов. Было предложено, что имя файла имеет следующий формат: «YYYYMMDDhhmmss-prefix.ext». Где YYYYMMDDhhmmss это время формирования файла по Гринвичу с точностью до секунд, prefix и ext произвольные префикс и расширение файла.
Не трудно заметить, что процессы обработки происходят не мгновенно, а занимают конечное, иногда довольно большое время. В тоже время исходные файлы для работы модулей должны появляться «мгновенно», т.е. с точностью до элементарных файловых операций, таких как переименование файла. Это должно исключать ситуацию, когда модуль запустившийся, для очередного цикла работы обнаружил входной файл, не до конца сформированный предыдущей обработкой. В результате мы приходим к тому, что при необходимости создать файл, предназначающийся к последующей обработке модули должны работать с временным файлом. Временные файлы должны отличаться от окончательных результатов работы либо именем (они не должны подпадать под шаблон имен, для входных файлов следующего модуля), либо положением в файловой системе (использование временных директорий). В последнем случаи временная директория должны находиться на том же разделе диска, что и целевая директория, так что бы перемещение файлов происходило так же быстро, как и переименование файла внутри директории.
Важным моментом является также реакция модулей на возникающие ошибки. Необходимо иметь некие общие правила поведения модулей в случаи возникновения сбоев для упрощения процедуры отладки и технической поддержки системы. Для этого в предлагаемой реализации принято соглашение о кодах возврата при работе модулей и их компонент. Определены следующие значения: RET_OK запуск завершен успешно. RETERR цикл обработки не смог завершиться из-за ошибок, RETNODATA на входе утилиты нет данных. RETLOCK запуск утилиты блокирован другим процессом, запушенным ранее. RET_WARN в ходе обработки возникли некритические ошибки, часть операций пропущена.
Картографический web-интерфейс к данным мониторинга флота и окружающей среды
Как и любое приложение для Internet, web-интерфейс является клиент-серверным приложением. Взаимодействие серверной и клиентской части осуществляется по протоколу HTTP или HTTPS. Выше были рассмотрены возможные реализации клиентской части. Клиентская часть интерфейса работает под управлением программы web-браузера. Серверная часть работает под управлением http-сервера, в случае UNIX-подобной системы де-факто стандартом является сервер Apache [80]. Рассмотрим теперь взаимодействие клиентской и серверной частей. Главным вопросом здесь является проблема организации хранения и передачи параметров между запросами.
Проблема возникает из-за того, что протокол HTTP (RFC 2616) не поддерживает сессии, и каждый запрос от клиента к серверу приходит как бы «сам по себе», т.е. информация о предыдущих запросах клиента потеряна. В случае простого интерфейса в этом нет ничего страшного. Пользователь последовательно проходит через ряд страниц, заполняя поля форм или выбирая интересующую его ссылку. Самым простым решением в этом случае является подстановка, при генерации HTML-страницы, параметров запроса в ссылки или в скрытые поля формы. Очевидным недостатком такого подхода является ограничение на длину строки запроса (query string) при передаче информации через параметры ссылки. В лучшем случае это может привести к тому, что часть параметров до сервера просто не дойдет. В худшем случае броузер откажется обрабатывать такую ссылку, или сервер откажется обрабатывать запрос клиента.
Принципиальным ограничением такого подхода с точки зрения разработки и поддержки является то, что в случае разветвленной логики интерфейса параметры необходимо дублировать во многих местах, а в многофреймовом или многооконном интерфейсе — заботиться о передаче параметров в разные окна или фреймы интерфейса.
Представим себе сложный интерфейс, в котором необходимо задание пользователем многих параметров и при этом они могут меняться в процессе работы. Логика такого интерфейса напоминает уже не пошаговый переход от страницы к странице, а движение по дереву. С одной стороны, интерфейс должен предоставлять пользователю удобную навигацию по «дереву» и, с другой стороны запоминать значения всех параметров, измененяемых пользователем в процессе работы, учитывать их при генерации любой последующей страницы интерфейса. В рамках вышеописанной схемы это трудно реализуемо. Существует, однако, гораздо более простое и уже ставшее стандартным (для определенного класса задач) решение. Это эмуляция сессий при помощи cookies, которые представляют собой небольшой дополнительный блок данных, хранящихся на машине клиента и передающихся серверу при каждом запросе [55]. Сервер при отсылке клиенту ответа (HTML-страницы) может попросить установить или удалить cookies. Главная идея эмуляции сессий при помощи cookies является то j что «предыстория» общения клиента и сервера сохраняется сервером при помощи cookies и «неявно» передается серверу при каждом последующем запросе. При работе с сайтом или какой-то выделенной его частью серверу передаются одни и те же cookies для всех фреймов и окон броузера.
Возможны два подхода к сохранению параметров в cookies. Первый заключается в том, что в cookies сохраняются пары имени параметра и значения. Это подходит для случая, когда параметров немного. Другой метод состоит в том, чтобы сохранить в cookies только информацию, необходимую для идентификации «сессии», а параметры «сессии» хранить на сервере, например, в базе данных. Этот подход не имеет ограничения на количество параметров, но в этом случае возрастает нагрузка на сервер (это связано с требованиями к дисковому пространству), а также возникает необходимость следить за «устареванием» записей на сервере и удалять ненужную информацию.
В настоящие время существует много мощных средств разработки Internet-приложений, таких как mod_perl, php, mod_python, asp, и т.д. Большинство из них имеют возможность эмуляции сессий либо в виде стандартного средства, либо в виде дополнительного модуля. Причем в последнем случае возможно наличие выбора между библиотеками, реализующими разные алгоритмы. Конкретные технологии реализации следует выбирать исходя из условий конкретной задачи, имеющихся наработок и опыта. Распределение нагрузки между сервером и клиентом. Использование броузерозависимых технологий.
В настоящее время существует множество технологий, позволяющих реализовывать различные функциональные возможности в броузере клиента. Их краткий обзор был приведен выше. Теперь необходимо понять, какое место следует отвести этим технологиям при проектировании интерфейса.
При разработке интерфейса на JavaScript возникает соблазн использовать этот язык для дополнительной предобработки форм в броузере клиента, а также для хранения и передачи параметров и т.п. . При этом возникает достаточно много проблем с тем, что работающие в броузере скрипты становятся достаточно сложными, трудно отлаживаемыми и сложными для сопровождения. Поэтому в процессе создания и усовершенствования сайта необходимо все время четко представлять, какие функциональные возможности являются основными и должны быть доступны любому пользователю, а какие — дополнительными и могут исчезнуть в «неправильном» броузере.
Выше сказанное относится не только к технологии JavaScript, но к другим броузерозависимым технологиям. JavaScript — очень удачный пример, так как эта технология по самой своей идее является наиболее интегрированной в броузер. Это, с одной стороны, позволяет решать с её помощью задачи, которые нельзя решить, применяя другие технологий, с другой стороны, делает эту технологию очень броузерозависимой. Количество различных версий JavaScript, видимо, равно количеству броузеров, в которых эта технология в той или иной степени поддерживается.
