Понятие формы

Понятие формы
Формы являются наиболее популярным способом интерактивного взаимодействия во
Всемирной паутине. С помощью HTML можно создавать простые формы,
предполагающие ответы типа “да” и “нет”, можно разрабатывать сложные формы для
заказов или для того, чтобы получить от читателей какие-либо комментарии и пожелания.
Форма представляет собой несколько полей, где пользователь может ввести некоторую
информацию, либо выбрать какую либо опцию. После того, как пользователь отправит
информацию, она обрабатывается программой (скриптом), размещенной на сервере.
Скрипт - это короткая программа, специально созданная для обработки каждой формы.
Существует также возможность создавать формы непосредственно в окне браузера
читателя.
Работа с тэгами форм



<TEXTAREA> - определяет поле, в которое пользователь вводит многострочную текстовую
информацию
<SELECT> - позволяет пользователю сделать выбор в окне с полосой прокрутки либо в
раскрывающемся меню
<INPUT> - обеспечивает некоторые другие виды ввода информации: ввод одной строки текста,
установку и сброс флажков (check boxes), выбор переключателя (radio buttons) и нажатие кнопки
для отправки данных или очистки формы.
Любое количество этих тэгов может быть размещено в контейнере FORM.
Тэг <FORM>
Этим тэгом начинается каждая форма. В нем нужно определить два атрибута, указывающих используемый
скрипт и метод посылки данных:


ACTION - определяет URL, который примет и обработает данные формы. Если
этот атрибут не определен, данные отправляются по адресу страницы, на которой
помещена форма.
METHOD - указывает форме, как послать информацию соответствующей
программе обработки (скрипту). Обычно он получает значение POST, тогда
информация посылается отдельно от URL. Если указано значение GET,
информация посылается вместе с URL.
Тэг <TEXTAREA>
Этот тэг предназначен для построения поля для ввода многострочной текстовой
информации. Тэг <TEXTAREA> имеет следующие атрибуты:



NAME - обязательный атрибут, определяющий название информации.
ROWS - устанавливает высоту поля, т.е. число строк в нем.
COLS - устанавливает ширину поля, т.е. число столбцов в нем.
Между тэгами <TEXTAREA> и </TEXTAREA> можно разместить любой текст,
выводящийся в поле по умолчанию.
Ниже приведен фрагмент HTML - кода и его интерпретация браузером
HTML - код
<FORM METHOD="POST">
<P>
<TEXTAREA NAME="S1"
ROWS="3" COLS="12">
DefaultText
</TEXTAREA>
</P>
</FORM>
Интерпретация
DefaultText
Тэг <SELECT>
Этот тэг используется для создания всплывающего меню или списка опций с полосой
прокрутки. Список опций и пункты меню располагаются внутри контейнера SELECT. Как
и тэг <TEXTAREA>, тэг <SELECT> требует обязательного определения имени в атрибуте
NAME. Ниже перечислены атрибуты тэга <SELECT>:



NAME - определяет название информации
SIZE - определяет вертикальный размер окна для опций выбора. Если атрибут
опущен или его значение равно 1, выводится всплывающий список опций. Если
указано значение больше 1, то опции выводятся в окне с полосой прокрутки. Если
значение атрибута больше, чем фактическое количество элементов списка,
добавляются пустые строки. При их выборе пользователем добавляются пустые
поля.
MULTIPLE - этот атрибут позволяет производить выбор сразу нескольких опций.
Список опций включается в контейнер <SELECT> при помощи тэгов <OPTION>. Этот тэг
имеет два атрибута:


VALUE - указывает значение, возвращаемое программе обработки в случае выбора
опции пользователем
SELECTED - указывает на опцию, выделенную по умолчанию.
Ниже приведен фрагмент HTML - кода и его интерпретация браузером
HTML - код
<FORM METHOD="POST">
<P>
<SELECT NAME="D1" SIZE="1">
<OPTION VALUE="1">Item1</OPTION>
<OPTION VALUE="2">Item2</OPTION>
<OPTION SELECTED VALUE="3">Item3</OPTION>
<OPTION VALUE="4">Item4</OPTION>
<OPTION VALUE="5">Item5</OPTION>
</SELECT>
</P>
</FORM>
Интерпретация
Item3
Тэг <INPUT>
Тэг <INPUT>, в отличие от <TEXTAREA> и <SELECT>, является одиночным тэгом. Он
предназначен для сбора информации различными способами, включая текстовые поля,
поля для ввода пароля, переключатели, флажки, кнопки для отправки данных (Submit) и
очистки формы (Reset, Clear).
Тэг <INPUT> располагает следующими атрибутами:






NAME - определяет имя данных. Является обязательным для всех видов данных,
кроме представляемых по нажатию кнопок Submit и Clear
SIZE - указывает размер поля в символах
MAXLENGTH - определяет максимально возможное число символов, вводимых в
поле
VALUE - для текстового поля определяет текст, выводимый по умолчанию. Для
флажков и переключателей указывает значение, возвращаемое программе
обработки. Для кнопок отправки и очистки формы определяет надпись на кнопке
CHECKED - устанавливает флажок или переключатель во включенное состояние
по умолчанию. С другими типами тэгов <INPUT> не употребляется
TYPE - устанавливает тип поля.
Атрибут TYPE тэга <INPUT> может принимать следующие значения:






TEXT - является значением по умолчанию и предполагает создание одной строки
для ввода данных. Для этого типа поля ввода употребляются атрибуты NAME
(обязательный), SIZE, MAXLENGTH и VALUE
PASSWORD - Позволяет заменять вводимые символы пароля звездочками. Для
этого типа поля ввода употребляются атрибуты NAME (обязательный), SIZE,
MAXLENGTH и VALUE
CHECKBOX - Позволяет вывести поле для установки флажка в виде маленького
квадратика, в котором может быть произведена отметка опции “галочкой”. Может
использоваться совместно с атрибутами NAME (обязательный), VALUE и
CHECKED (определяет установленный по умолчанию флажок). Флажки обычно
употребляются, когда можно выбрать сразу несколько опций из числа
предложенных
RADIO - позволяет выбрать только одну из представленного числа опций.
Переключатели можно группировать, задавая одно и то же значение атрибута
NAME (обязательный). Также используются атрибуты VALUE и CHECKED
RESET - позволяет создать кнопку для очистки формы. Атрибут VALUE может
быть использован здесь для наименования этой кнопки ( по умолчанию кнопка
имеет надпись RESET).
SUBMIT - Используется для создания кнопки, по нажатию которой введенные
данные отправляются на сервер для обработки программой - скриптом. В атрибуте
VALUE можно указать название для этой кнопки.
Ниже приведены фрагменты HTML - кода и их интерпретация браузером
TYPE (тип поля)
TEXT
HTML - код
<FORM METHOD="POST">
<P>
<INPUT TYPE="TEXT" NAME="T1"
SIZE="20"VALUE="InitialText">
</P>
</FORM>
Интерпретация
InitialText
PASSWORD
<FORM METHOD="POST">
<P>
<INPUT TYPE="PASSWORD"
NAME="T2" SIZE="20"
VALUE="InitialText">
</P>
</FORM>
CHECKBOX
<FORM METHOD="POST" >
<P>
<INPUT TYPE="CHECKBOX"
NAME="C1" VALUE="ON"
CHECKED>Check1<BR>
<INPUT TYPE="CHECKBOX"
NAME="C2" VALUE="ON1">
Check2<BR>
<INPUT TYPE="CHECKBOX"
NAME="C3" VALUE="ON">
Check3
</P>
</FORM>
RADIO
SUBMIT
<FORM METHOD="POST">
<P>
<INPUT TYPE="RADIO"
VALUE="V1"
CHECKED
NAME="R1">Radio1<BR>
<INPUT TYPE="RADIO"
NAME="R1"
VALUE="V2">Radio2<BR>
< INPUT TYPE="RADIO"
NAME="R1"
VALUE="V3">Radio3<BR>
</P>
</FORM>
<FORM METHOD="POST">
<P>
<INPUT TYPE="SUBMIT"
VALUE="Submit" NAME="B1">
</P>
</FORM>
***********
Check1
Check2
Check3
Radio1
Radio2
Radio3
Submit
HTML, SGML и CGI.
Стандартный язык, используемый в WWW для создания и публикации, называется HTML
(HyperText Markup Language - язык разметки гипертекста). До появления программы
Mosaic сеть Internet представляла собой конгломерат компьютеров, работающих в
различных ОС, что делало обмен документами весьма непростой задачей. Поиски
решения этой проблемы привели к созданию языка SGML (Standard Generalized Markup
Language - стандартный обобщённый язык разметки документов). SGML предназначен
для описания элементов документа, не навязывая получателю его оформление.
При чтении SGML - документов можно изменять размеры окна просмотра, чтобы
оптимально использовать рабочее пространство экрана, а при печати документ сохраняет
свою компоновку. Язык HTML был разработан на основе SGML как простой формат для
обмена гипертекстом, не ограниченный возможностями конкретных платформ. Подобно
SGML, он обеспечивает простоту создания документов и преобразования форматов.
Термин программирование на HTML используется везде и всюду, что не совсем
правильно. HTML - это не язык программирования.
HTML был создан сравнительно недавно и сам по себе лёгок для изучения. Web документы создаются на языке HTML и обычно сохраняются в файлах с расширениями
“.HTML” или “.HTM”. Они представляют собой обычные текстовые ASCII - файлы с
командами форматирования. Содержащие информацию о компоновке документа: стилях
текста, заголовках, абзацах, списках и гиперссылках.
Единый шлюзовой интерфейс CGI (Common Gateway Interface). Именно с его помощью
обрабатываются данные, введённые пользователем в интерактивные Web - формы. Он
также служит основой для создания “графических карт”, т.е. размеченных изображений с
“горячими точками”, которые выполняют ту же роль, что и гиперссылки в тексте.
Подробнее это будет рассмотрено далее.
позволяющий веб-серверу по запросу браузера пускать на себе какие-либо программы и
результат их работы отдавать браузеру. CGI программа (скрипт) - программа (скрипт),
работающая на сервере и обменивающаяся данными с браузером через вышеупомянутый
интерфейс. Поскольку не существует жесткой регламентации насчет определений и
терминов, то очень часто, говоря CGI, имеют ввиду именно программу (скрипт), а не сам
интерфейс.
Если это программа, то она должна иметь любой приемлемый для конкретной
операционной системы исполняемый формат. Программы можно писать на чем угодно:
C/C++, Pascal, Java, Visual и просто Basic, delphi и т.д.
Если это скрипт (сценарий), то на операционной системе, под которой крутиться вебсервер должен быть соответствующий интерпретатор сценариев: shell, perl, tcl/tk,
command.com и т.д.
Главное, чтобы средство разарботки CGI программы (скрипта) отвечало следующим
требованиям: - позволяют читать из стандартного потока ввода (stdin) - получать значения
переменных окружения (environment variables) - выводить в стандартный поток вывода
(stdout)
Для чего используется CGI:




Работа со справочными системами и базами данных.
Создание динамических HTML документов и ресурсов (в том числе счетчики, гостевые
книги и т.д.)
Удаленное администрирование различных систем.
Просто работа с различными программами, поскольку HTML интерфейс довольно удобен в
использовании, прост в изготовлении и приятно выглядит :)
Механизм работы CGI программ
Как уже было сказано, CGI получает входные данные со стандартного потока ввода stdin или из
переменных окружения, а выводит результаты своей работы в стандартный поток вывода stdout.
Для тех. кто не знает, что это такое: Стандартный поток ввода (stdin) - отсюда программа
(скрипт) по-умолчанию получает входную информацию. Обычно это клавиатура, но его можно
переназначить, и программа (скрипт) будет получать входные данные из файла, сокета,
выходного потока другой программы.
Переменные окружения (environment variables) - переменные, определенные для системы
и сервера, на которой будет выполняться CGI. .
Стандартный поток вывода (stdout) - сюда программа (скрипт) выводит результаты
своей работы. Обычно это экран, но его можно переназначит на файл, сокет, входной
поток другой программы, принтер и т.д.
Большинство примеров в этом руководстве написано на shell только для того, чтобы
упростить изложение материала.
Согласно последним веяниям по соблюдению безопасности не рекомендуется
использование shell для написания CGI скриптов.
1.1 Вызов CGI без параметров
Простейший скрипт, выводящий текущую дату:
#!/bin/sh
echo Content-type: text/html
echo
echo "<h2>Today is "
date
echo "</h2>"
В HTML документе ссылка на него описывется вот таким образом
<a href="/cgi-bin/examples/today.cgi">
ВАЖНОЕ ЗАМЕЧАНИЕ Основной ошибкой, которую совершают почти все, кто
начинает писать CGI программы или скрипты, заключается в том, что они забывают
вставить указатель на тип выводимого результата - заголовок выводимого документа. Это
вторая и третья строчки в примере.
echo Content-type: text/html
echo
где Content-type: - тип выводимого документа (text/html, image/gif, image/jpeg и т.д.).
Пустая строка в выводе говорит о том, что заголовок кончился и далее следует собственно сам
документ.
1.2 Передача параметров CGI скрипту или программе
Передача параметров осуществляется двумя основными методами: GET и POST. У
каждого из них свои достоинства и недостатки.
При использовании GET параметры добавляются к запрашиваемому URL и его можно
вызывать таким образом:
http://какой-то_хост/cgi-bin/какой-то_скрипт?параметры
что позволяет делать на такой скрипт ссылки в HTML документах. А на сервере переданные
параметры присваиваются переменной QUERY_STRING.
Текст самого скрипта:
#!/bin/sh
echo Content-type: text/html
echo
echo "<h2>Вы посылали вот это:</h2>"
echo "<b>"
set | grep QUERY_STRING
echo "</b><br><hr>"
echo "<b>Environment</b><br><xmp>"
set
echo ""
и как он вызывался из этого документа:
<a href="/cgi-bin/examples/link.cgi?some_parameters">
Пример работы (ткните тут)
</a>
Но применение метода GET для передачи параметров, содержащих конфиденциальную
информацию недопустимо, т.к. в данном случае вся эта информация передается открыто.
Метод POST позволяет обеспечить конфиденциальность при передаче параметров
скрипту. Но он передает параметры на стандартный поток ввода и для этого приходится
использовать формы. Сервер не посылает скрипту EOF в конце передачи. Вместо этого
вам придется использовать пременную окружения CONTENT_LENGTH, чтобы
определить какой объем данных вам надо считать из stdin.
Пишем счетчик
В последнее время, количество людей желающих прицепить на свою страницу счетчик
посещений растет бешеными темпами. В Интернете есть много мест, где желающие могут
взять какие угодно счетчики под любые операционные системы и прикрутить их на свои
страницы.
Эта глава руководства будет скорее полезна тем, кому интересен именно механизм работы
счетчиков, поскольку все прилагаемые примеры особыми "наворотами" по части
настроек, администрения, и т.п. не обладают. Более "навороченые", готовые к
эксплуатации счетчики ищите на Altavista, Yahoo и др. поисковых серверах. Или
спрашивайте в соответствующих конференциях новостей (relcom.www.users,
relcom.www.support; в фидошных эхах ru.internet.*).
2.1 Типы счетчиков
По механизму работы счетчики условно можно разделить на два типа:
1. CGI скрипты работающие как Server Side Include
2. CGI скрипты не использующие Server Side Include
Server Side Include (SSI) - тип HTML комментария , который указывает Web серверу, что в месте
вызова необходимо подставить динамически сгенерированные данные. Основной формат вызова
SSI в теле HTML документа выглядит следующим образом:
< !--#command tag="value"...-->
где #command - любая из многочисленных команд понимаемых Web сервером. В данном
случае наибольший интерес представляет команда #exec, которая позволяет выполнять
программы и подставлять результаты их работы. Анализируемые Web сервером HTML
документы называются server-parsed документами.
2.2 Cчетчик посещений работающий как SSI
Алгоритм работы:
1. Сервер получает от браузера запрос на HTML документ.
2. Сервер просматривает документ на наличие вызова SSI.
3. Если такие вызовы обнаружены, то на их место подставляется результат. В случае команды
#exec - результат работы программы, указанной в "value".
4. Сформированный HTML документ возвращается браузеру.
Необходимые настройки сервера (на примере сервера Apache):
1. В файле srm.conf прописать (если там еще не прописано):
2. AddType text/html .shtml
3. AddHandler server-parsed .shtml
Эти директивы говорят серверу, что файлы с раширением .shtml являются server-parsed
документами.
4. В файле access.conf на директорию, где будут лежать server-parsed документы, в Options
добавить опцию Includes.
5. Файлам, содержащим вызовы SSI присвоить расширение .shtml (см. п. 1)
Продемонстрируем работу счетчика на примере скрипта counter, найденного в Интернете на
http://www.webtools.org/. Он написан на столь популярном ныне Perl'е.
Вот тут будем считать : < !--#exec cgi="/cgi-bin/counter"-->
(нажимайте Reload пока не надоест)
Этот счетчик текстовый, т.е. скрипт возвращает просто текст, который и показывается.
Аналогичным образом можно выводить и картинки. Для этого нужно, чтоб вместо
текстовых цифр выводились тэги img src="картинка_с_соответсвующей_цифрой".
Пытливый читатель легко догадается, что количество тегов img src... равно количеству
цифр в значении возвращаемом счетчиком.
Вызов этого счетчика в теле документа осуществляется командой:
<
!--#exec cgi="/cgi-bin/counter"-->
2.3 Счетчик не использующий SSI
Более простым с точки зрения пользователя, но более сложным в программировании
является счетчик не использующий SSI. Механизм работы такого счетчика представляет
из себя следующее:


в теле HTML документа указывается:
<img src="/cgi-bin/examples/counter.cgi">
т.е. запрашиваемая картинка не является статической, а динамически генерируется CGI
скриптом.


сервер, получив запрос на картинку, запускает скрипт, указанный в src тэга img.
скрипт, увеличивает значение счетчика на единицу, генерирует картинку со значением
счетчика и возвращает ее браузеру.
Поскольку данный тип счетчиков является самым популярным в Интернете, то алгоритм
его работы рассмотрим более подробно.
Скрипт (counter.cgi), который вызывается в теле HTML документа тэгом img
src="...counter.cgi" написан на shell и имеет следующий исходный текст (номера строк
добавлены только для упрощения объяснения):
1:
2:
3:
4:
5:
6:
#!/bin/sh
now=`date -u`
echo "Content-type: image/gif;"
echo "Expires: $now"
echo
counter|showdigits
Что делает этот скрипт (построковое описание):
1 - Заголовок самого скрипта. Он указывает на командный интерпретатор, который будет
его выполнять.
2 - Определяем переменную now, которая содержит время запуска скрипта (время
создания картинки). Ключик '-u' говорит, что, дата/время создания выводяться в GMT.
Зачем это надо будет описано ниже.
3 - Начинаем формировать заголовок ответа сервера. Указываем тип возвращаемых
данных: image/gif
4 - Поскольку это счетчик, то необходимо обеспечить, чтобы картика с его показаниями
не кэшировалась (а то какой он после этого счетчик:). Для этого указываем, что полученая
браузером картинка должна немедленно заэкспайриться. Вот тут то мы и используем
переменную now, определенную в строке номер 2. Употребление Expires в таком виде
соответствует стандарту на HTTP протокол версии 1.1. Но при использовании Expires
равным дате создания документа могут возникать забавные глюки, если часы на клиенте
отстают от часов сервера на несколько минут. Возникает дилемма - по стандарту
положено так, а получается не то что надо. Что делать? В предыдущей версии протокола
(HTTP 1.0) Expires можно было выставлять равным 0, а RFC2068 гласит, что клиенты и
кэши работающие по HTTP 1.1 должны поддерживать старый вариант использования
Expires (Expires: 0). Так шта, дорогие россияне, решайте сами.
5 - Конец заголовка ответа - возвращаем пустую строку.
6 - Используя две программы (counter и showdigits) генерим саму картинку.
Программы counter и showdigits написаны на Си с использованием библиотеки для работы
с GIF файлами - libgd. Без нее программы компилироваться не будут. Последнюю версию
библиотеки всегда можно получить на http://www.boutell.com/gd/.
Что делают эти программы:


counter - читает из файла counter.rc число, представляющее из себя предыдущее значение
счетчика, прибавляет к нему единичку и пишет обратно. Если не указан путь к файлам картинкам с цифрами и маска этих файлов,то береться дефолтовая, которая определна в
теле программы. После этого она вычисленное значение счетчика и пути к картинкам
выводяться на stdout, чем формируется коммандная строка для showdigits.
showdigits - эта программа, собственно, и формирует картинку с текущим показанием
счетчика. Для этого используется набор готовых картинок с цифрами (gif формат, все
картинки одинакового размера) и полученные на stdin от counter данные. По пути, маске и
числу беруться нужные картинки и из них собирается один гиф. После чего он
отправляется прямиком на ... stdout! А далее сервер перенапрявляет этот поток браузеру и
он (браузер) показывает его как картинку, поскольку в заголовке ответа указано, что это
гиф.
Вся суть здесь вот в чем: - Сервер передает браузеру поток данных. - Браузеру абсолютно все
равно, где и как сервер взял передаваемый ему поток данных (статический ли это, или
динамически сгенеренный; обычный файл или результат жизнедеятельности скрипта), главное,
чтоб браузер знал как его правильно интерпретировать. Для этого служит заголовок, который в
данном примере был сгенерирован скриптом counter.cgi, а именно в 3-5 строках (см. выше).
Причем, в случае статических файлов сервер сам генерирует этот заголовок, исходя из
собственных настроек, а в случае с cgi это должен делать сам скрипт.
Server side includes
Ежу понятно, что статические HTML документы - это хорошо, а динамически создаваемые - еще
лучше.:) Так вот, в этой главе мы поговорим о динамическом создании документов с
использованием Server Side Includes. Сразу отметим, что возможность использования SSI - это
возможность каждого конкретного сервера. Некоторые сервера не поддерживают SSI, а у тех,
которые имеют такую возможность, могут различаться форматы и наборы команд. Так что,
читайте инструкцию по эксплуатации вашего Web-сервера. Все примеры в этой главе приведены
для сервера Apache.
3.1 Что такое SSI
Как уже было сказано впредыдущей главе, Server Side Include (SSI) директива Web-сервера,
позволяющая серверу подставлять на место вызова какие-либо данные. В HTML документе вызов
SSI выглядит как комментарий формата:
< !--#command tag="value"...-->
где #command - любая из SSI директив понимаемых Web сервером, а "value" - ее
параметры.
Подставляемые данные могут быть статическими и динамически генерируемыми. Статические
данные уже готовые, записанные в виде файлов, фрагменты текста или HTML. Такие данные
удобно применять в случае, когда в различных HTML документах содержаться повторяющиеся
фрагменты. Динамически генерируемые данные результаты работы каких-либо CGI скриптов или
команд операционной системы, на которой работает конкретный Web-сервер. Использование
этого типа данных предоставляет Web-девелоперу огромные возможности. Но, как гласит
дебильная российско-буржуйская реклама, - "Не забывай про Орбит без сахара!". То бишь,
ПОМНИ О МЕРАХ ПО СОБЛЮДЕНИЮ БЕЗОПАСНОСТИ ДОСТУПА К ИНФОРМАЦИИ! Неправильное
использование SSI может привести к появлению возможности несанкционированного доступа к
информации и, соответственно, к различным тяжким последствиям. Чтобы уберечься от этого читайте необходимую литературу. Например, от W3C (master site:
http://www.w3.org/Security/Faq/) или одно из его многочисленных. В том числе и на русском:
http://private.peterlink.ru/www-security-faq/.
3.2 Основные SSI директивы
config управляет различными аспектами анализа (parsing) документа. Атрибуты: errmsg
сообщение об ошибке, возвращаемое клиенту, если при анализе документа произошел какойлибо сбой. sizefmt устанавливает формат вывода размера файла (байты, килобайты, мегабайты).
timefmt устанавливает формат вывода даты/времени. echo печатает значение одной из
нижеописаных переменных окружения. Атрибуты: var имя печатаемой переменной exec
выполняет указанную команду или CGI скрипт. Атрибуты: cgi указывается (%-кодированый) URLотносительный путь к CGI скрипту. Если путь не начинается с (/), считается, что путь указан
относительно текущего документа.
CGI скрипту передаются так же значения переменных PATH_INFO и QUERY_STRING
оригинального запроса клиента.
cmd сервер выполняет указанную строку, используя командный интерпретатор операционной
системы. fsize печатает размер указанного файла с учетом sizefmt. Атрибуты: file указывается путь
к файлу относительно текущей директории содержащей анализируемый файл. virtual указывается
(%-кодированый) URL-относительный путь к файлу. Если путь не начинается с (/), считается, что
путь указан относительно текущего документа. flastmod печатает дату/время последнего
изменения указанного файла с учетом timefmt. Атрибуты такие же как у команды fsize. include
вставляет текст другого документа или файла в анализируемый документ. Очень полезна при
повторяющихся фрагментах в разных документах. Атрибуты: file указывается путь к файлу только
относительно текущей директории содержащей анализируемый файл. virtual указывается (%кодированый) URL-относительный путь к файлу. Если путь не начинается с (/), считается, что путь
указан относительно текущего документа. В Apache включаемые таким образом файлы могут быть
вложенными. printenv печатает список всех существующих переменных и их значения. Атрибутов
нет. Пример:
< !--#printenv -->
set устанавливает значение переменной. Атрибуты: var указывается имя устанавливаемой
переменной. value указывается значение устанавливаемой переменной. Пример:
< !--#set var="variable_1" value="some_value_of_variable_1" -->
3.3 SSI переменные окружения
DOCUMENT_NAME - имя файла Описание в теле документа:
< !--#echo
var="DOCUMENT_NAME" -->
Результат использования:< !--#echo var="DOCUMENT_NAME" -->
DOCUMENT_URI - виртуальный путь к файлу Описание в теле документа:
< !--#echo
var="DOCUMENT_URI" -->
Результат использования:< !--#echo var="DOCUMENT_URI" -->
QUERY_STRING_UNESCAPED - раскодированя query string, причем все метасимволы shell
предваряются "\" Описание в теле документа:
< !--#echo var="QUERY_STRING_UNESCAPED" -->
Результат использования:
DATE_LOCAL - текущая дата и время (местное) Описание в теле документа:
< !--#echo
var="DATE_LOCAL" -->
Результат использования:< !--#echo var="DATE_LOCAL" -->
DATE_GMT - текущая дата и время (GMT) Описание в теле документа:
< !--#echo
var="DATE_GMT" -->
Результат использования:< !--#echo var="DATE_GMT" -->
LAST_MODIFIED - дата и время последнего изменения файла Описание в теле документа:
<
!--#echo
var="LAST_MODIFIED" -->
Результат использования:< !--#echo var="LAST_MODIFIED" -->
3.4 Настройка сервера
Для того, чтобы серевер знал, в каком месте в документе подставлять данные, он должен
этот документ проанализировать. Анализируемые сервером документы называются
server-parsed документами.
В первую очередь надо дать понять серверу, какие документы он должен анализировать.
Для этого в файл конигурации (для Apache старых версий и NCSA web-серверов это файл
srm.conf, а для новых версий Apache, например 1.3.4 - httpd.conf), нужно добавить
следующие параметры: Сервер Apache:
AddType text/html .shtml<BR>AddHandler
server-parsed .shtml
Сервер NCSA:
AddType text/x-server-parsed-html .shtml
Указанные параметры говорят о том, что все файлы с расширением
.shtml
являются server-parsed, и перед тем как "отдать" этот документ клиенту сервер должен их
проанализировать.
Зачем указывать отдельное расширение для server-parsed документов?,- спросит
пытливый читатель. Отвечаем. Конечно, никто не мешает добавить в файл конфигурации
строку
AddType text/x-server-parsed-html .html
Однако это приведет к тому, что сервер будет анализировать все документы с расширением
.html,
даже если в них нет вызова SSI, загрузка системы увеличиться, а производительность сервера
снизится.
Не следует забывать и о том, что бесполезно включать вызов SSI в CGI программы,
поскольку их вывод сервером не анализируется.
Для получения более детальной информации по конфигурированию вашего сервера на
предмет использования SSI читайте документайию на ваш сервер.
Приложения
Приложение 1. Переменные окружения сервера
Ниже приведен список основных переменных окружения сервера с краткими описанием
назначения.В данном случае сервер Apache 1.2.5 с модулем PHP/FI-2.0.1. Для других вебсерверов (MS IIS, Netscape, NCSA httpd, и т.д.) переменные могут отличаться.
REMOTE_HOST - имя хоста приконнектившегося к серверу. В случае работы через
прокси - имя прокси.
Пример: REMOTE_HOST=lom.pvrr.ru
REMOTE_ADDR - IP адрес хоста приконнектившегося к серверу. В случае работы через
прокси - IP адрес прокси.
Пример: REMOTE_ADDR=194.87.186.11
REMOTE_PORT - номер порта клиента.
Пример: REMOTE_PORT=3381
HTTP_USER_AGENT - имя/номер версии/и т.д. клиента (браузера). Использование этой
переменной иногда приводит в бешенство отдельных пользователей Интернет.:) Но на
самом деле очень полезная вещь. Например для автоопределения русских кодировок.
Пример:HTTP_USER_AGENT=Mozilla/4.07 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
HTTP_ACCEPT - типы данных, помимо text/html, воспринимаемые клиентом (браузером)
Пример: HTTP_ACCEPT=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png,
*/*
HTTP_ACCEPT_CHARSET - какие чарсеты понимает клиент (браузер).
Пример: HTTP_ACCEPT_CHARSET=iso-8859-1,*,utf-8
HTTP_ACCEPT_LANGUAGE - какие языки воспринимвает клиент (браузер).
Пример: HTTP_ACCEPT_LANGUAGE=nl,nl-BE,ru
SERVER_NAME - имя сервера соответствующее записи IN A в DNS, или значение
переменной ServerName (или похожей) в конфиге сервера.
Пример: SERVER_NAME=arche.pvrr.ru
HTTP_HOST - имя сервера или виртуального хоста, к которому обращается клиент.
Значение HTTP_HOST может быть равным значению SERVER_NAME.
Пример: HTTP_HOST=www.pvrr.ru
SERVER_SOFTWARE - какое ПО используется в качестве сервера.
Пример: SERVER_SOFTWARE=Apache/1.2.5 PHP/FI-2.0.1
DOCUMENT_ROOT - путь к "корню" веб-сервера от "корня" файловой системы
копьютера, на котором он работает.
Пример: DOCUMENT_ROOT=/usr/local/www/html
HTTP_CONNECTION - тип соединения.
Пример: HTTP_CONNECTION=keep-alive
SERVER_PROTOCOL - протокол, используемый для обмена данными с конкретным
клиентом.
Пример: SERVER_PROTOCOL=HTTP/1.0
REQUEST_URI - имя запрашиваемого ресурса/документа, включающее в себя путь от
корня веб-сервера. При обращении к корню сервера или каталогу этой переменной
присваивается имя каталога или "/" в случае корня сервера.
Пример: REQUEST_URI=/cgi-bin/tralala/script.cgi
DOCUMENT_URI - имя запрашиваемого ресурса/документа, включающее в себя путь от
корня веб-сервера. Обычно инициализируется при вызове SSI. В отличие от
REQUEST_URI эта переменная, в случае обращения к каталогу или корню сервера
получает значение содержащее и имя файла, являющегося Directory Index'ом этого
каталога.
Пример: DOCUMENT_URI=/tralala/index.shtml
HTTP_REFERER - полный URL документа, по ссылке с которого вы попали на этот
сервер. Эту переменную можно использовать при написании счетчиков.
Пример: HTTP_REFERER=http://lom.pvrr.ru/java/cgi/cgi_1.html
GATEWAY_INTERFACE - название/версия интерфейса, через который сервер работает
со скриптом.
Пример: GATEWAY_INTERFACE=CGI/1.1
SCRIPT_FILENAME - имя скрипта, содержащее полный путь от "корня" файловой
системы.
Пример:SCRIPT_FILENAME=/usr/local/www/cgi-bin/tralala/script.cgi
SCRIPT_NAME- имя скрипта, содержащее путь от "корня" веб-сервера.
Пример: SCRIPT_NAME=/cgi-bin/tralala/script.cgi
REQUEST_METHOD - метод используемый клиентом для передачи данных серверу.
Бывают GET, HEAD, POST, PUT.
Пример: REQUEST_METHOD=GET
QUERY_STRING - этой переменной значение присваивается при передаче данных
серверу методом GET
Пример: QUERY_STRING=button=on
CONTENT_LENGTH - этой переменной присваивается значение, равное количеству
байт, переданных браузером серверу при использовании метода POST.
Пример: CONTENT_LENGTH=9
REMOTE_USER - имя пользователя. Передается только если аутентифицируется доступ
к CGI скрипту.
PATH_INFO - дополнительная информация о пути, которую передал клиент. То есть
скрипт может получать некоторые параметры, содержащие информауцию о некотором
"пути" к некоторым данным (например к файлу конфигурации, необходимому для
обработки запроса отименно этого клиента). Этот путь "виртуальный" - т.е от "корня вебсервера". Остальные данные можно передавать как обычно - методом GET или POST.
Пример: PATH_INFO=/some/path
PATH_TRANSLATED - то же , что и PATH_INFO, только путь физический - "от корня
файловой системы"
REMOTE_IDENT - Если HTTP сервер поддерживает идентификацию согласно RFC 931,
то этой переменной присваивается имя пользователя получаемое от сервера.
SERVER_ADMIN - e-mail администратора веб-сервера.
Пример: SERVER_ADMIN=webmaster@www.pvrr.ru
SERVER_PORT - порт, который "слушает" веб-сервер.
Пример: SERVER_PORT=80
***
HTTP_X_FORWARDED_FOR - в случае работы через прокси - IP адрес клиента,
работаеющего через прокси.
Пример: HTTP_X_FORWARDED_FOR=194.87.186.11
HTTP_VIA - имя, номер порта, версия ПО прокси-сервера.
Пример: HTTP_VIA=1.0 proxy1.pvrr.ru:8080 (Squid/2.1.PATCH1)
HTTP_CACHE_CONTROL - что-то связанное с возрастом документа в кэше прокси
сервера:) Врать не буду - не знаю:)
Пример: HTTP_CACHE_CONTROL=max-age=259200
Виды клиентов
Под клиентской платформой целесообразно понимать не только системное окружение на
клиентской стороне, но и способ организации пользовательского интерфейса и его
взаимодействия с бизнес-логикой, разделенной в рамках приложения на клиентскую и
серверную часть. Графический интерфейс пользователя завязан на клиентскую логику,
исполняемую в некоторой среде (будь то браузер или приложение). И даже простенький
случай с Web-страницей, когда взаимодействие с пользователем осуществляется
посредством HTML-форм, как правило, предполагает ненулевую прослойку клиентской
— т.е. исполняемой на клиенте — логики, например, на Java-скрипте.
Клиентская часть приложения посредством некоторого протокола взаимодействует с
сервером, причем протокол по всем правилам OSI входит в слоеный пирог — от
прикладного до физического уровня. Далее — серверная логика, за ней — уровень
хранения данных. То, каким образом в приложении осуществляется взаимодействие
между клиентской и серверной частью, и является определяющим для клиентской
платформы. Учитывая набор доступных протоколов, архитектур и алгоритмов, нехитрая
на первый взгляд цепочка (рис. 1) дает большую степень свободы при построении этого
взаимодействия.
Рис. 1. Цепочка передачи данных в клиент-серверной архитектуре
Какими порциями и в каких случаях надо обновлять экран пользователя? Возможны
самые разные варианты — от полного обновления при использовании статического HTML
(страница с формой загружается в браузер, измененная форма отправляется на сервер) до
передачи событий отдельным измененным объектам от клиентской стороны к серверу и
обратно. Из-за того, что пользовательский интерфейс строится по несколько иным
законам, чем бизнес-логика приложения, практически всегда необходимо связывать
бизнес-объекты и элементы графического интерфейса пользователя. Это, как правило,
требует написания некоторого дополнительного программного кода. Такая «связующая»
логика может располагаться как на клиенте, так и на сервере, и тогда водораздел «клиент
— сервер» проходит либо через изменение визуальных элементов управления
(передаются события в GUI, как в терминальных клиентах), либо через изменение
клиентских представлений объектов.
Требования к клиентской платформе зависят от типа приложения. Есть приложения,
которые обновляют пользовательский интерфейс только по явным действиям
пользователей. Так работает большинство бизнес-приложений, где наиболее частыми
операциями являются операции редактирования, добавления и удаления записей или
документов и связей между ними. Тогда, скажем, после редактирования записи,
клиентское приложение отправляет соответствующие изменения на сервер, а пользователь
видит измененную запись. Есть приложения, в которых обязательна передача измененных
объектов с сервера на клиент с отображением этих изменений без явных действий
пользователя, как, например, в клиентах электронных торгов.
Рис. 2. Отображение объектной поверхности GUI в Baikonur/Taxxi
Данные, которые проходят через цепочку от СУБД к GUI и обратно, пребывают в
нескольких состояниях: в базе данных, в бизнес-логике и в пользовательском интерфейсе.
Приложение может требовать установки на клиенте, а может загружаться каждый раз
заново с сервера. Клиентское приложение может брать на себя выполнение всей бизнеслогики, а может состоять только из презентационного слоя, который отрабатывает
пользовательский интерфейс. Серверная логика может располагаться на уровне хранимых
процедур в СУБД, а может включать в себя полноценное объектно-ориентированное
многопоточное приложение. Словом, степеней свободы действительно много.
Двухзвенная клиент-серверная архитектура была настоящим бестселлером до WWWэпохи. Затем появился браузер как тонкий клиент, которому прочили судьбу «убийцы»
двухзвенного подхода, но пророчества эти оказались преждевременными. Данный подход
породил ряд иллюзий, вызванных концептуальной красотой решения, однако Internetприложения оказались более сложными в разработке, чем это казалось на первый взгляд,
причем пользователи, как правило, расплачиваются неудобством сильно урезанного Webинтерфейса по сравнению с «классическим» графическим пользовательским интерфейсом
настольных приложений. Для того чтобы построить равное по функциональным
возможностям и удобству использования Web-приложение, надо обладать большим
опытом, и требования к Web-программистам, как правило, значительно выше, чем
требования к «обычным» прикладным программистам.
Трехзвенная архитектура включает обязательное звено — сервер приложений, благодаря
которому на серверной стороне оказываются представлены сервисные функции:
пользовательские сеансы, транзакции, ведение учетных записей пользователей и прав
доступа, а также исполнение серверной логики на различных языках. Развитием
трехзвенного подхода являются технологии, позволяющие осуществлять гибкое и
продуманное разделение логики на клиентскую и серверную, и контролировать обмен
между клиентом и сервером более разумным способом, чем в двухзвенной архитектуре и
традиционных тонких Web-клиентах.
Taxxi: объектная поверхность
Сервер приложений Baikonur во многом предвосхищал ставшую популярной лишь годы
спустя трехзвенную архитектуру. Дополненный компонентами быстрой разработки,
интегрированными с очень распространенным и поныне инструментарием Delphi, сервер
приложений Baikonur привлек внимание разработчиков своей концептуальной
продуманностью и простотой создания полноценных приложений с Web-интерфейсом.
Пройдя стадии клиентов на базе HTML и Java, технология Baikonur пришла к концепции
«объектной поверхности» в сверхтонком Windows-клиенте Taxxi. Последний
представляет собой, по сути, легкий (около 400 Кбайт) XML-браузер, который
отрисовывает пользовательский интерфейс. На клиенте, помимо Taxxi, устанавливается
также Baikonur-сервер (еще около 1 Мбайт), и в этом смысле сам клиент приобретает
черты сервера, а само решение содержит все характерные черты распределенных
приложений.
Объектная поверхность — это набор объектов пользовательского интерфейса. Серверное
и клиентское приложения синхронизируют свои объектные поверхности: при действиях
пользователя на сервер передаются эти события, и после их обработки отрисовываются
элементы объектов пользовательского интерфейса.
Парадигма объектной поверхности, по-видимому, оптимальна для распределенных систем
со слабыми каналами: в ней минимизируется трафик взаимодействия клиента и сервера за
счет того, что передаются только содержательные данные по отрисовке пользовательского
интерфейса. Кроме того, проработанность решения с точки зрения сопряжения
пользовательского интерфейса (Taxxi — лишь GUI-клиент, взаимодействующий с
сервером) сокращает трудоемкость написания приложений в средах, подобных Delphi.
Чем этот подход отличается от терминальных решений? В терминальном сеансе
приложение работает только с данным пользователем, хотя и расположено на сервере. В
результате это совершенно не облегчает разработку распределенных бизнес-приложений,
которые в этом случае скорее следует отнести к двухзвенной архитектуре. Кроме того,
передача клиенту всех элементов пользовательского интерфейса, вместо передачи
измененных данных, подлежащих отрисовке, значительно нагружает канал связи,
особенно при отображении табличных данных, не поддающихся кэшированию.
VisualDoc: объектное пространство
Если в Taxxi клиент и сервер взаимодействуют на уровне объектной поверхности GUI, то
в технологии VisualDoc это взаимодействие происходит на уровне бизнес-объектов,
которые расположены на сервере, но имеют клиентские представления.
VisualDoc — это не только сервер приложений, но и объектная СУБД, построенная поверх
стандартной реляционной СУБД. Объекты принадлежат настраиваемой схеме данных:
путем задания структуры классов и связей между ними создается каркас будущего
приложения, который отражается в хранилище.
Чтобы понять суть подхода VisualDoc, рассмотрим простой пример — на клиенте имеется
приложение, которое отражает на форме или в табличном представлении значения полей
некоторых объектов из базы данных. Когда пользователь правит данные, изменяя через
элементы пользовательского интерфейса поля объектов, создавая и удаляя объекты, это
отражается на сервере приложений, а также в хранилище. Объекты на клиенте — это
всего лишь представления объектов на сервере. При изменении объектов на сервере,
помимо сохранения их в базе данных, происходит уведомление тех клиентов, которые
загрузили клиентские представления этих объектов, т.е. включили их в свое рабочее
объектное пространство. На события изменений клиентских объектов можно стандартным
образом подключать обработчики, например, на JavaScript, в результате чего мы имеем
распределенное приложение. На клиентской части идет связывание элементов
графического пользовательского интерфейса и полей объектов; при этом изменения
объектов передаются как от клиента к серверу, так и обратно.
Сервер VisualDoc предоставляет такие механизмы, как транзакции, кэширование,
разграничение прав доступа, версионность объектов, при этом данные хранятся в
нижележащей СУБД (Microsoft SQL Server или Oracle). Клиент и сервер общаются
посредством специального протокола (можно выбрать либо бинарный, либо основанный
на XML протокол), а клиентские объекты, в том числе и схема данных, доступны через
COM-интерфейс.
Рис. 3. Отображение объектного пространства в VisualDoc
VisualDoc, помимо сервера приложений и объектной СУБД (среди ее отличительных черт
— динамически определяемая объектная схема данных с наследуемыми, связанными друг
с другом классами, полями и методами, объектный язык запросов и т.д.), предоставляет
универсальный пользовательский интерфейс. Этот интерфейс строится динамически на
основе схемы данных и включает в себя интерфейсные паттерны, подобные древовидному
и табличному представлениям объектов, а также формы их редактирования. Это позволяет
создавать приложения без программирования, сразу готовые к работе после создания
объектной схемы данных и не теряющие работоспособности при ее изменении.
Бесспорно, универсальный пользовательский интерфейс имеет свои преимущества (его не
надо программировать), однако в большинстве систем требования на пользовательский
интерфейс все же специфичны и требуют написания кода. Для того чтобы сократить
трудоемкость этой работы, в VisualDoc включена библиотека визуальных элементов
управления, позволяющая разрабатывать клиентские приложения на платформе Microsoft
.NET, настраивая и связывая между собой визуальные компоненты на формах.
Avalon для Longhorn
В следующем поколении Windows, по-видимому, кардинальным образом изменится
парадигма построения пользовательского интерфейса. Презентационная подсистема
Longhorn с рабочим названием Avalon по своей архитектуре больше походит на
клиентские Web-приложения: средой для GUI выступает браузер, элементы
пользовательского интерфейса в рамках страниц разметки задаются на родственном XML
языке XAML, а связывание их с логикой осуществляется подобно тому, как это делается в
случае DHTML/JavaScript.
Программный код может быть размещен как в самих GUI-блоках, так и в отдельных .NETсборках. Такое разделение приложений на декларативный пользовательский интерфейс и
логику, событийно связанную с его элементами, уже давно произошло де-факто в
средствах разработки, хотя в механизме вызова графического пользовательского
интерфейса Windows был все тот же механизм оконных сообщений, а презентационная
подсистема не была отделена от ядра. Теперь сама операционная система предоставляет
высокоуровневые средства явного декларативного задания пользовательского интерфейса,
причем с четко выраженным объектно-ориентированным подходом (все элементы
пользовательского интерфейса — это экземпляры .NET-классов). Хотя здесь нет ничего
принципиально нового (примерно такой механизм работал в браузерах еще с момента
появления JavaScript), но интегрированный с .NET и встроенный в операционную
систему, этот подход даст разработчикам новые возможности более органичного
использования графического интерфейса Windows.
Какой вариант лучше?
Ответ на этот вопрос приходится давать в каждом конкретном случае заново. На выбор
влияют требования к ресурсам, которыми будет располагать будущая система, а также ее
разработчики и пользователи. Под ресурсами в данном случае могут понимать скорость
канала связи, вычислительную мощность и объем памяти клиентских машин и серверов,
возможность установки на клиентские рабочие места приложений без нарушения
требований безопасности, степень унификации системного окружения клиентских
рабочих мест, стоимость разработки на основе различных подходов, допустимое время
ожидания реакции и т.д. На выбор обычно влияют и другие факторы: степень владения
командой разработчиков той или иной технологией, традиционность либо «модность»
технологии, кажущаяся концептуальная красота и т.д.
О понятии «тонкий клиент»
В последнее время от пользователей систем электронного архива и документооборота
довольно часто приходится слышать требования, касающиеся обеспечения работы с
использованием «тонкого клиента». При этом далеко не все выдвигающие подобное
требование ясно представляют себе, что же такое «тонкий клиент» и чем работа с его
применением отличается от работы через web-интерфейс (для многих это одно и то же).
Мы постараемся расставить точки над «i» в вопросах терминологии и функциональных
возможностей «тонкого клиента» относительно его использования в упомянутых
системах.
Начнем с определения. Термин «тонкий клиент» возник сравнительно недавно и поначалу
относился, скорее, к области компьютерного жаргона. Искать его трактовку в толковых
словарях — дело заведомо безнадежное, хотя термин применяется все чаще и чаще. Не
претендуя даже на малую толику лексикографических заслуг Ожегова, попытаемся сами
объяснить понятие «тонкого клиента».
Надеемся, нашим читателям знакома следующая особенность построения баз данных
архитектуры «клиент-сервер» и трехзвенной архитектуры: в идеале все процессы
выполняются на сервере посредством отработки хранимых процедур сервера. Обращение
к серверу СУБД в архитектуре «клиент-сервер» реализуется через интерфейс клиентского
места, а в случае трехзвенной архитектуры осуществляется обращение с клиентского
места к серверу приложений, который, в свою очередь, обращается к СУБД. При этом
сервер СУБД и сервер приложений физически располагаются на мощных аппаратных
средствах, отличных от клиентских рабочих станций, что позволяет обрабатывать
большое число запросов и управлять большими объемами информации БД без нагрузки на
рабочие станции.
В различных источниках приводятся разные определения «тонкого клиента», причем
иногда они довольно противоречивы даже в рамках одного и того же источника:
1. В компьютерных технологиях «тонкий клиент» (thin client) — это «компьютер-клиент
сети с архитектурой “клиент-сервер”, который переносит большинство задач по обработке
информации на сервер» [1].
2. В том же источнике, только в его англоязычной версии приводится следующее
определение: «A thin client is a computer (client) in client-server architecture networks which
has little or no application logic, so it has to depend primarily on the central server for processing
activities. The word “thin” refers to the small boot image which such clients typically require —
perhaps no more than required to connect to a network and start up a dedicated web browser or
“Remote Desktop” connection such as X11, Citrix ICA or Microsoft RDP. In contrast, a thick or
fat client does as much processing as possible and passes only data required for communications
and archival storage to the server» [2]. Здесь уже указываются конкретные службы и
средства доступа: web-браузер и/или подключение к удаленному рабочему столу
посредством клиента терминальных сервисов.
3. «Тонкий клиент» — это «такая многопользовательская серверная модель, в которой
100% приложений выполняются на сервере» [3].
Можно привести и множество других определений, но все они либо дополняют, либо
взаимоисключают друг друга.
Давайте предпримем небольшой экскурс в историю. В старые добрые времена
мэйнфреймов доступ к многопользовательской среде осуществлялся через локальные и
удаленные терминалы. Именно этим устройствам суждено было стать прообразом
решений, объединенных сегодня термином «тонкий клиент». Итак, это решения,
имеющие в своем составе устройства ввода (клавиатура, мышь, считыватель смарт- и
флэш-карт и т.д.), устройства вывода (монитор, принтер, колонки и т.д.) и средства
подключения к серверу (адаптер сети Ethernet, адаптер последовательной линии связи или
модем). В качестве примера можно привести «тонкие клиенты» фирмы AK systems.
Именно поэтому третье из приведенных определений является абсолютно обоснованным.
Правда, сегодня понятие «тонкого клиента» этим определением не исчерпывается,
поэтому нам больше импонирует определение, данное в Free On-Line Dictionary of
Computing: «A simple client program or hardware device which relies on most of the function
of the system being in the server» [4]. То есть в качестве «тонкого клиента» может
выступать и полноценная рабочая станция, имеющая в своем составе ПО, имитирующее
режим «тонкого клиента». С развитием web-технологий стандартом де-факто для доступа
к web-узлам (серверам) стало использование web-браузера. Это и породило
отождествление понятий «web-браузер» и «тонкий клиент»…
Антиподом «тонкого» является «толстый» клиент, в определениях которого противоречия
встречаются реже. Приведем одно из них: «“Толстый клиент” производит обработку
информации независимо от сервера, используя последний в основном лишь для хранения
данных» [1].
Не станем дальше цитировать определения и заниматься поиском противоречий, а
поговорим лишь о «толщине» «тонкого клиента» — степени распределения нагрузки по
обработке информации между клиентским приложением и сервером СУБД (в двухзвенной
архитектуре) или между клиентским приложением, сервером приложений и сервером
СУБД (в трехзвенной архитектуре). Все изложение будет строиться на практике работы с
системами электронного архива и документооборота.
Большинство пользователей систем электронного архива и документооборота желают
получить возможность доступа к системе с любого компьютера и по любым каналам (при
этом не должна возникать необходимость в дополнительных клиентских приложениях
или каких-либо специфических настройках на удаленных рабочих станциях). Многие
пользователи хотели бы иметь доступ с удаленной рабочей станции к полному
функционалу системы электронного архива и документооборота. Иногда к этому
добавляется просьба обеспечить доступ к такой системе, не зависимый от операционных
систем удаленных рабочих станций. Причем, как правило, речь идет о доступе через
«тонкого клиента».
Обобщив все пожелания, можно сделать следующий вывод: в идеале для реализации
«тонкого клиента» должно существовать клиентское приложение, не требующее
дополнительных инсталляций в операционных системах рабочих станций и позволяющее
любому пользователю, имеющему необходимый сетевой доступ и параметры
идентификации, получить доступ к полному функционалу системы электронного архива и
документооборота независимо от операционной системы рабочей станции, сервера и
используемой СУБД.
Что касается практического воплощения этих пожеланий, то здесь многое зависит от
конкретики решаемых задач. Теоретически реализация такого суммарного функционала
сродни понятию математического предела: стремимся, но никогда не достигнем в идеале
(это касается и всех возможных задач при работе с БД, в частности — задач при работе с
БД систем электронного архива и документооборота).
Если система построена в архитектуре «клиент-сервер», то, на наш взгляд, нет
возможности четко разграничить системы, использующие «тонкого клиента», в которых
основная часть обработки информации возложена на сервер, и системы с «толстым
клиентом», где сервер применяется в основном для хранения данных. Прежде всего это
связано с тем, что сам принцип работы системы «клиент-сервер» как двухзвенной, так и
трехзвенной архитектуры подразумевает, что основная часть информации
обрабатывается на сервере. Кроме того, невозможность провести указанную грань
связана с отсутствием внятно сформулированных критериев. Например, вряд ли кемнибудь определено, в каких единицах измеряется и какой процент должна составлять
«основная часть обработки информации», возложенная на сервер. Численно не
определены и критерии эксплуатации сервера при его использовании «в основном для
хранения данных». Полагаем, что применительно к современным системам,
использующим архитектуру «клиент-сервер», следует говорить о «толщине» клиента, то
есть о степени участия клиентских рабочих мест в процессе обработки информации, о
нагрузке на них, о применении их ресурсов и доле сервера и сервера приложений в
процессах, происходящих во всей системе.
Позволим себе прокомментировать одно из устоявшихся мнений. Считая понятия webдоступа и «тонкого клиента» абсолютно идентичными, большинство нынешних да и
потенциальных пользователей систем электронного архива и документооборота уверено,
что «тонкий клиент» непременно должен реализовываться через web-браузер. Полагаем,
что в случае систем электронного архива и документооборота такое мнение не всегда
корректно.
Понятно, почему web-браузер является, на первый взгляд, оптимальным клиентским
приложением для реализации «тонкого клиента». Это неотъемлемая часть большинства
современных операционных систем, не требующая дополнительной инсталляции, HTMLстраницы одинаково отображаются в различных операционных системах и могут
передаваться по любым каналам связи. Работа через браузер удобна и привычна для
большинства пользователей. Общая схема работы системы электронного архива и
документооборота с использованием web-доступа показана на рис. 1. Подобная схема
применима и к трехзвенной архитектуре (в этом случае промежуточным звеном между
сервером СУБД и клиентскими рабочими станциями является сервер приложений). Схема
работает следующим образом:
• запрос с клиентской рабочей станции, формируемый через интерфейс клиентского
рабочего места (в случае web-доступа — через web-браузер), поступает на сервер
приложений (или, в случае web-доступа, — на web-сервер);
• сервер приложений (в случае web-доступа — web-сервер) производит обработку запроса,
при необходимости решает прикладные задачи и передает запрос серверу СУБД.
Примером прикладной задачи, решаемой сервером системы web-доступа к системе
электронного архива и документооборота TDMS (www.tdms.ru), является формирование и
передача СУБД запросов для маршрутизации документов между пользователями в
процессе разработки (обработки);
• СУБД отрабатывает запрос и возвращает результат серверу приложений, который
отправляет его клиенту в понятном тому виде. В случае же web-доступа web-сервер
должен дополнительно представить результаты в виде страниц, «понятных» webбраузеру, — например, используя технологию ASP или PHP.
При отработке запроса применяются специальные средства клиент-серверных СУБД
(Oracle, Microsoft SQL Server, Interbase и др.) — хранимые процедуры и триггеры,
реализованные на специализированных расширениях языка запросов (SQL) и являющиеся
неотъемлемой частью СУБД (для Oracle — PL/SQL, для Microsoft SQL Server — Transact
SQL). Как правило, хранимые процедуры представляют собой специальные блоки
программного кода, теоретически позволяющие производить на сервере любую обработку
данных. Команду на запуск той или иной хранимой процедуры СУБД получает от сервера
приложений.
Повторим, что в случае «ресурсоемких» систем с интенсивным доступом целесообразно
уменьшить нагрузку на сервер СУБД и выполнять с использованием хранимых процедур
далеко не весь объем обработки. В трехзвенной архитектуре часть обработки
производится сервером приложений.
Помимо команды на запуск той или иной хранимой процедуры, на сервер СУБД
передаются все необходимые параметры, вводимые через пользовательский интерфейс
клиентской рабочей станции или формируемые сервером приложений.
За целостность базы отвечает специальный вид хранимых процедур — триггеры. В
отличие от явно вызываемых хранимых процедур, они автоматически отрабатываются при
добавлении, удалении, обновлении информации в таблицах СУБД, реализуя необходимую
логику работы системы электронного архива и документооборота.
Приведем примеры задач, которые могут быть с успехом реализованы посредством
триггеров и хранимых процедур сервера СУБД. При изменении наименования заказчика-
потребителя проектной документации автоформируемые номера и наименования томов,
комплектов и документов в завершенных проектах, включающие код и название
заказчика, остаются прежними, а в некоторой части разрабатываемых проектов номера и
наименования автоматически изменяются, порой по достаточно непростой логике.
Другой пример: при попытке внести изменения в атрибутивную информацию документа,
принадлежащего завершенному проекту (тому, комплекту), автоматически проверяется,
соблюдена ли бизнес-логика (имеется ли разрешение на ревизию или извещение об
изменении).
Схема работы системы с использованием двухзвенной архитектуры «клиент-сервер»
отличается от приведенной на рис. 1 отсутствием сервера приложений. Считаем, что
иллюстрировать ее отдельно не стоит. В случае двухзвенной архитектуры «клиентсервер» запрос к серверу СУБД, формируемый через интерфейс клиентских мест,
поступает напрямую. При этом так же, как и в трехзвенной архитектуре, запускаются и
отрабатываются обработчики сервера СУБД — триггеры и хранимые процедуры.
Рис. 1. Общая схема работы системы электронного архива и документооборота
с использованием web-доступа
При интенсивном применении информационной системы использование сервера
приложений снимает нагрузку с сервера СУБД, что положительно влияет на
быстродействие и качество всей системы. В ряде случаев целесообразно применение
нескольких серверов приложений. Однако отсутствие элементарной информации о
назначении и принципе работы серверов приложений в совокупности с рекламными
акциями компаний-производителей ПО приводит к тому, что клиенты иногда
отказываются рассматривать любое решение, не поддерживающее трехзвенную
архитектуру, даже для одного-двух десятков рабочих станций с достаточно низкой
интенсивностью доступа к базе данных.
Несомненно, целесообразность применения трехзвенной архитектуры определяется
количеством одновременно работающих клиентов, интенсивностью их доступа,
«размером» базы данных, возможностями используемой СУБД и, конечно же, решаемыми
задачами, определяющими степень применения ресурсов сервера. Четких количественных
критериев здесь не существует. Например, при оптимальной конфигурации системы,
достаточных ресурсах сервера и использовании СУБД Oracle полнофункциональные
рабочие места системы электронного архива и документооборота устойчиво работают на
300-600 полнофункциональных рабочих станциях. При этом таблицы СУБД могут
содержать миллионы записей, а архитектура системы — быть двухзвенной без
использования серверов приложений.
Если появилась необходимость решить для большого количества пользователей
специфические и более узкие задачи (например, обеспечить доступ в систему
электронного архива только на просмотр), целесообразно для той же базы данных
применять сервер приложений или web-доступ, речь о котором пойдет ниже.
Надеемся, что все вышесказанное поможет сделать правильный выбор и сэкономить
средства.
Насколько «тонок» web-доступ
Из предыдущего раздела статьи вовсе не следует, что доступ к базе данных системы
электронного архива и документооборота, организованный через окно браузера, делает
ненужным рассмотрение любой системы электронного архива и документооборота,
предоставляющей информацию «не в окне браузера».
Отметим явные недостатки web-браузера при его использовании в качестве средства
доступа к полному функционалу системы электронного архива и документооборота.
Напоминаем: рассматриваются только системы электронного архива и
документооборота. В других приложениях, применяющих web-доступ, перечисленных
недостатков может и не оказаться, равно как могут проявиться и иные.
Производительность обработки данных на сервере при обращении к базе через браузер
такая же, как через «не web»-клиента, а вот возможности отображения информации
гораздо уже и определяются следующим:
• внешний вид HTML-страницы ограничен стандартным для браузера набором элементов.
Производительность работы при отображении ниже, чем в альтернативном клиенте,
поскольку применяемые в web-браузере HTML и JavaScript не позволяют быстро
«отрисовывать» динамически изменяющуюся информацию;
• как известно, web-браузер не отображает векторные форматы, не говоря уже о
сборках — многофайловых связанных структурах, получаемых в современных САПР.
При просмотре однофайловых документов и чертежей можно, конечно, воспользоваться
гиперссылкой и открыть файл в соответствующем приложении, проинсталлированном в
системе, но такой способ исключает возможность доступа с любого компьютера. Открыть
же трехмерную сборку невозможно еще и потому, что это требует инсталляции в
операционной системе не только САПР (или соответствующего средства просмотра), но и
специального интерфейса, позволяющего «собрать» все файлы вложенных сборок и
деталей с учетом имеющихся связей. Одно только создание такого интерфейса,
работающего через web-доступ, является весьма трудоемкой и дорогостоящей задачей.
Существуют технологии, позволяющие частично решить указанные проблемы. Все эти
технологии переносят часть процессов по обработке информации на клиентское место.
Они предоставляют возможность web-доступа, но превращают web-браузер в далеко не
идеального «тонкого клиента», «толщина» которого довольно велика. В некоторых
случаях, связанных с созданием большой нагрузки на клиентскую рабочую станцию при
обработке информации, сложно говорить о «тонком клиенте» вообще (несмотря на
web-доступ). Нередко случается, что желание «просто получить web-доступ» ведет к
необоснованным затратам: сказываются сложность реализации и потеря
производительности системы из-за громоздкости клиентского приложения.
Использование JAVA-приложений и объектов ActiveX
Для решения некоторых задач обработки документов с применением web-интерфейса в
системах электронного архива и документооборота можно использовать специальные
программы, загружаемые на рабочую станцию с сервера и выполняющиеся в окне webбраузера. Сегодня существуют две альтернативные технологии: JAVA-приложения
(апплеты) и ActiveX, различающиеся способом создания загружаемого приложения. Обе
они имеют следующий недостаток: программа выполняется на рабочей станции, занимая
немало ее ресурсов. В сравнении с доступом через «не web»-клиента применение
подобного web-доступа для решения задач электронного архива и документооборота
гораздо менее удобно и более ресурсоемко.
К минусам использования данной технологии следует отнести и то, что в настройках webбраузеров современных операционных систем по умолчанию запрещены загрузка и
выполнение JAVA-приложений и ActiveX-объектов. Связано это прежде всего с
политикой безопасности, блокирующей возможность загрузки из сети вирусов.
Необходимые настройки требуют соответствующей квалификации пользователей,
предоставления им соответствующих прав в операционной системе рабочей станции. А
кроме того, смягчение политики безопасности повышает риск загрузки и выполнения
действительно вредоносных программ.
При доступе через web-интерфейс в системах электронного архива и документооборота
технология ActiveX подходит больше, чем JAVA, поскольку с ее помощью можно внести
в окно браузера недостающий функционал. Таким функционалом являются, например,
средства работы с векторными изображениями и получаемыми при проектировании в
САПР трехмерными многофайловыми сборками. Кроме того, использование ActiveX
позволяет динамически отображать на экранах меняющуюся информацию БД, применять
в окне браузера привычные для пользователя элементы «не web»-интерфейса. Скорее
всего (конечно, все зависит от решаемых задач), практически 100% функционала
клиентского места системы электронного архива и документооборота можно реализовать
в окне браузера. Но, в отличие от JAVA-приложений, ActiveX-объекты могут выполняться
только в операционных системах Microsoft Windows.
Не вдаваясь в технические подробности, вкратце поясним суть работы ActiveX.
Технология использует специальные приложения, хранящиеся на сервере (например, в
виде OCX-файлов) и создаваемые практически в любых современных средах
программирования. При написании могут применяться API-библиотеки необходимых
САПР (тех, например, с файлами и сборками которых необходимо обеспечить работу в
окне web-браузера). В соответствующих тэгах HTML-кода страницы, хранящейся на
сервере, указывается команда на загрузку ActiveX-приложения в определенном месте
страницы. Такая загрузка осуществляется web-браузером с клиентского места
автоматически, причем, в отличие от JAVA-приложений, ActiveX-компоненты
загружаются при первом обращении к странице, а не каждый раз.
Описываемая технология имеет ряд особенностей, которые в случае систем электронного
архива и документооборота правильнее назвать недостатками:
• реализовать компонент ActiveX, позволяющий полноценно решать в окне web-браузера
все задачи систем электронного архива и документооборота, — дело довольно трудоемкое
и недешевое;
• размер файла-компонента ActiveX, решающего серьезные задачи, достаточно велик. Не
называя конкретного продукта, дабы не навлечь на себя подозрений в антирекламе,
приведем такой пример: в одной из систем размер ActiveX-приложения, работающего в
окне web-браузера, достигает 25 Mбайт. Напомним, что при первом обращении к
странице, работающей с ActiveX, этот файл должен быть загружен на клиентскую
рабочую станцию. Закачивать такой объем по низкоскоростным, в том числе и
коммутируемым каналам связи, мягко говоря, неудобно. Если же канал позволяет быстро
загружать такие файлы, следует вполне логичный вопрос: «А зачем в таком случае webдоступ и почему не использовать «не web»-клиентское приложение?»
Возможный ответ звучит так: «Но ведь все равно кроме браузера и единожды
загружаемого ActiveX ничего не требуется». Прокомментируем подобную точку зрения.
ActiveX-компонент, являясь отдельным приложением, автоматически инсталлируется в
операционной системе после первой загрузки. Кроме того:
• возникает ограничение по используемой операционной системе клиентского места: она
должна быть совместима с той, для которой создавался ActiveX;
• как уже сказано, для работы с файлами и сборками, получаемыми в двумерных и
трехмерных САПР, при написании ActiveX используются API-библиотеки этих САПР.
Таким образом, для работы ActiveX на клиентском месте недостаточно одной только
соответствующей операционной системы — необходимо еще и наличие API-библиотек.
Другими словами, должны быть проинсталлированы соответствующие САПР (а значит,
«толщина» клиента возрастает);
• еще раз напомним, что в настройках web-браузеров современных операционных систем
загрузка и инсталляция ActiveX по умолчанию запрещены. Конечно, при наличии
необходимых прав и должной квалификации пользователь может, понизив уровень
безопасности, обеспечить загрузку, инсталляцию и исполнение ActiveX-компонентов в
окне браузера, но тем самым он откроет доступ и вредоносным программам.
Принцип целесообразности
Таким образом, полноценная работа со всеми функциями системы электронного архива
и документооборота при попытках использовать web-браузер без увеличения нагрузки на
клиентские рабочие станции невозможна или крайне сложнодостижима. Следовательно,
реализация web-доступа к полному функционалу (при использовании web-браузера в
качестве полнофункционального «тонкого клиента») весьма нецелесообразна, громоздка,
ресурсоемка и затратна.
Теперь постараемся сформулировать наши подходы к применению web-доступа.
Несомненно, web-доступ удобен, полезен и порой необходим, но при его реализации и
использовании стоит руководствоваться принципом целесообразности. Так, web-доступ
можно применять, если действительно требуется доступ к системе электронного архива и
документооборота с любого компьютера с использованием web-интерфейса и без
инсталляции дополнительных программных средств. Правда, при этом, ввиду
вышеописанных причин, функционал рабочего места будет ограничен. Как правило, при
использовании любого web-браузера возможен поиск информации по атрибутам (и/или
полнотекстовый) и просмотр растровых изображений в форматах, поддерживаемых webбраузером. Кроме того, возможен просмотр документов других форматов, не
поддерживаемых браузером, — с использованием проинсталлированных в операционной
системе приложений для работы с этими документами. Через web-доступ возможна
маршрутизация документов в системе документооборота. Кроме того, зачастую
целесообразен web-доступ к функционалу системы электронного архива и
документооборота, связанному не только с просмотром, но и с редактированием
информации (например, к атрибутивной информации документов, а порой и их файлов).
Подчеркнем, что доступ к редактированию атрибутивной информации, как правило,
может осуществляться «стандартными» для web-интерфейса средствами.
Большинству пользователей системы электронного архива и документооборота,
выражающих обоснованное желание работать через web-доступ, как правило, не требуется
работа с файлами векторных форматов и 3D-моделями (чаще это не конструкторыпроектировщики, а руководители и административные работники). Web-доступ для
редактирования файлов документов, реализация которого требует дополнительных
средств, целесообразен лишь в крайних случаях — когда других вариантов нет, а создание
необходимых ActiveХ-приложений экономически оправдано, и эти приложения не
переносят большую часть процедур по обработке информации на клиентскую рабочую
станцию.
Реализация web-доступа для системы управления технической
информацией и документацией TDMS
Компания CSoft Санкт-Петербург (Бюро ESG) (www.csoft.spb.ru) активно продвигает и
внедряет системы электронного архива и документооборота в среде программного
комплекса TDMS — разработанной компанией Consistent Software Development
(www.consistent.ru) системы управления технической информацией и документацией.
Среди реализованных проектов — внедрение системы электронного архива ОАО
«Гипроспецгаз», системы электронного архива ОАО «Красный Октябрь», системы
электронного архива и документооборота ЗАО «ГТ-Инспект», системы электронного
архива и документооборота с элементами PDM ЗАО «ЦНИИ СМ» и многие другие.
Существенное место в проводимой работе занимает реализация технологий поддержки
жизненного цикла изделий и объектов. Мы неоднократно представляли наши подходы к
созданию подобных систем и рассказывали об их успешных реализациях в среде TDMS,
учитывающих различные задачи на разных этапах жизненного цикла (управление
проектированием, строительные модели, системы логистической поддержки с элементами
статистического анализа [5]).
Важной частью нашего подхода к внедрению ИПИ-технологий является электронный
документооборот [6].
В связи с вопросами реализации web-доступа и «тонкого клиента», часто возникающими
по ходу выполнения проектов внедрения систем электронного архива и
документооборота, и были сформулированы принципы, изложенные в данной статье.
Рис. 2. Доступ с ПК к базе данных системы электронного архива и документооборота
через web-интерфейс
Руководствуясь этими принципами, компания CSoft Санкт-Петербург (Бюро ESG)
разработала систему web-доступа к базе данных системы TDMS — программный
комплекс TDMS WEB Access. Продукт успешно внедрен и активно используется в
системе электронного архива и документооборота санкт-петербургского ОАО «Красный
Октябрь». При этом реализован следующий функционал:
• после соответствующей идентификации пользователя (рис. 2) доступ осуществляется
через web-интерфейс с любой машины сети;
• возможен поиск по атрибутивной информации документов;
• выполняется полнотекстовый поиск;
• осуществляется маршрутизация документа в процессе документооборота, рассылки
извещений и сообщений;
• возможно редактирование атрибутивной информации;
• допустимо редактирование части файлов документов (не требующее инсталляции
дополнительных программных средств, несущих большую нагрузку на клиентскую
рабочую станцию).
Использование TDMS WEB Access не исключает применения полнофункционального «не
web»-клиента. Для выполнения задач, требующих реализации функций, ресурсоемких как
для клиентского рабочего места, так и для бюджета, на предприятии используется «не
web»-доступ в двухзвенной архитектуре «клиент-сервер». Web-доступ к единому серверу
СУБД организован в трехзвенной архитектуре.
На рис. 3 показан процесс идентификации при доступе к БД TDMS с карманного
компьютера (Pocket PC). Отметим, что на карманном компьютере не потребовалось
дополнительной инсталляции каких бы то ни было программных средств.
Рис. 3. Доступ с карманного компьютера к базе данных TDMS (через web-интерфейс)
Использование терминального клиента
Постараемся ответить читателям, формулирующим следующую задачу: необходим
удаленный доступ с использованием «тонкого клиента» ко всему функционалу системы
электронного архива и документооборота, несмотря на то что web-браузер такого доступа
не обеспечивает. При этом условия не позволяют загружать JAVA- и ActiveX-приложения
и инсталлировать на клиентской рабочей станции дополнительные средства для работы с
векторной графикой и 3D-моделями.
Вернемся к одному из определений, приведенному в начале статьи: «“тонкий клиент”
представляет собой компьютер — клиент сети, который переносит большинство задач
по обработке информации на сервер», после чего внимательно изучим рис. 4,
иллюстрирующий удаленный доступ к рабочему столу компьютера, на котором
проинсталлирован стандартный клиент TDMS (не осуществляющий web-доступа и
выполняющий 100% функций работы в системе электронного архива и
документооборота). Доступ, показанный на этом рисунке, организован через Интернет с
использованием канала GPRS. Подобный доступ возможен с применением любого канала
(коммутируемого модемного соединения, выделенного Ethernet-канала, ADSL-канала
и т.д.). При этом может использоваться стандартное программное обеспечение КПК —
клиент терминальных сервисов. Из вышесказанного следует, что такое решение (см. рис.
4) является одним из вариантов обеспечения доступа к полному функционалу системы
электронного архива и документооборота без инсталляции дополнительного ПО на
клиентской рабочей станции.
Рис. 4. Доступ к рабочему столу компьютера через Интернет с использованием
терминального клиента КПК
Общая схема работы в системе электронного архива и документооборота с применением
терминального доступа показана на рис. 5 и поддерживает следующие принципы работы: