Серверные веб-приложения

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

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

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

Стандарт CGI

Круг задач, решаемых Web-сервером, ограничен. В основном он сводится к поддержке НТТР-взаимодействия и доставке клиенту Web-документов. Любые "нестандартные" действия реализуются с помощью специальной программы, которая взаимодействует с веб-сервером и клиентом. Это взаимодействие подчиняется определенным правилам.

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

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

Выполнение любой программы (в том числе CGI-сценария) можно условно разделить на пять этапов.

Различия между CGI-сценарием и консольным приложением касаются первого, второго и четвертого этапов выполнения.

Каждый раз, когда веб-сервер получает запрос от клиента, он анализирует содержимое запроса и возвращает соответствующий ответ:

CGI определяет:

В подавляющем большинстве случаев запуск CGI-сценария осуществляется щелчком на кнопке Submit, сформированной с помощью дескриптора <input tyре = "submit">, который находится на HTML-странице между <form> и </form>. Не зная назначения атрибутов action и method, невозможно понять, как происходит вызов программы и передача параметров.

Значением атрибута action дескриптора <form> является URL файла, содержащего код CGI-сценария. Так, приведенное ниже выражение означает, что файл с кодом CGI-сценария находится на сервере www.myhp.edu в каталоге cgi-bin в файле script.рl.

<form action="http://www.myhp.edu/cgi-bin/script.pl" method="post">

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

Идентификация по расширению используется относительно редко. Чаще всего все сценарии помещаются в cgi-bin, /Scripts или в другой каталог, специально выделенный для их хранения.

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

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

НТТР/1.0  200  OK

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

Самый естественный формат для браузера - формат HTML. Результаты работы сценария обычно оформляются в виде веб-страницы, т.е. возвращаемые данные следует дополнить дескрипторами HTML. Таким образом, ответ CGI-сценария клиенту обычно выглядит так:

Content-type: text/html

<html>
<hеаd>
<titlе>ответ сценария</titlе>
</hеаd>
<body>
……………………
</body>
</html>

Обратите внимание на пустую строку после выражения Content-type: text/html. Она обязательно должна присутствовать в ответе, в противном случае клиент воспримет все последующие данные как продолжение заголовка.

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

Для вызова данного сценария достаточно включить в веб-страницу следующий фрагмент HTML-кода:

<form method="post" action="/cgi-bin/hello.exe">
<input type="submit"> 
</form>

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

В большинстве случаев кроме кнопки Submit форма содержит другие интерактивные элементы, каждый из которых имеет имя (атрибут NAME ) и значение (атрибут VALUE, либо последовательность символов, введенная пользователем). Из имен элементов и их значений формируется строка параметров, которая имеет следующий формат.

имя=значениеимя=значение . . . имя=значение

Каждый параметр представляет собой имя управляющего элемента и его значение, разделенные знаком равенства, а несколько таких пар объединяют строку с помощью символа " !". Как правило, при передаче параметров трехсимвольными последовательностями заменяются все знаки, кроме латинских букв, цифр и символа пробела (последний заменяется знаком " + ").

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

Атрибут method дескриптора <form> имеет либо значение " GET ", либо значение " POST ". Значения " GET " и " POST " определяют два различных метода передачи параметров сценарию:

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

Если атрибут METHOD дескриптора <FORM> имел значение " GET ", строка параметр передается серверу в качестве значения переменной окружения QUERY_STRING.

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

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

Таким образом, в простейшем случае, чтобы выполнить обработку строки параметров, достаточно знать назначение трех переменных окружения: REQUEST_METHOD, QUERY_STRING и CONTENT_LENGTH.

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

$method = $ENV{'REQUEST_METHOD'};

if ($method eq "GET")
{ $pars = $ENV{'QUERY_STRING'};   }
else
{ $length =$ENV{'CONTENT_LENGTH'}; }

read (STDIN, $pars, $ length);

print "Content-type: text/html\n\n";
print "<HTML><BODY>\n";
print "<P>METHOD = ", $method;
print "<P>String of parameters: <P>\n";
print $pars;
print "</HTML></BODY>\n";

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

Сценарии

К основным достоинствам разработки приложений на стороне веб-сервера в форме сценариев можно отнести следующие:

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

В плане быстродействия сценарные языки можно разделить на:

В рассмотрим кратко наиболее известные языки разработки сценариев для веб- приложений.

Python

Python — высокоуровневый язык программирования общего назначения с акцентом на производительность и читаемость кода. Язык Python сочетает в себе минимализм синтаксиса ядра и большой объем полезных функций в стандартной библиотеке.

Python поддерживает структурную, объектно-ориентированную, функциональную, императивную и аспектно-ориентированную парадигмы.

Его основные архитектурные черты:

Код в Python организовывается в функции и классы, которые могут объединяться в модули (которые в свою очередь могут быть объединены в пакеты ).

Для всех основных платформ Python имеет поддержку характерных для данной платформы технологий (например, Microsoft COM/DCOM ). Cуществует даже специальная версия Python для виртуальной машины Java - Jython, что позволяет интерпретатору выполняться на любой системе, поддерживающей Java, при этом классы Java могут непосредственно использоваться из Питона и даже быть написанными на Python. Несколько проектов обеспечивают интеграцию с платформой Microsoft.NET, основные из которых - IronPython и Python.Net.

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

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

Ruby

Ruby — интерпретируемый язык высокого уровня для быстрого и удобного объектно-ориентированного программирования. Ruby обладает независимой от операционной системы реализацией многопоточности, строгой динамической типизацией, " сборщиком мусора " и многими другими возможностями. Многие особенности синтаксиса и семантики языка Perl заимствованы в Ruby.

Первая общедоступная версия Ruby появилась в 1995 г.

Ruby - полностью объектно-ориентированный язык:

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

Ruby поставляется с большой стандартной библиотекой. Это, прежде всего, библиотеки для работы с различными сетевыми протоколами на стороне сервера и клиента, средства для работы с различными форматами представления данных (XML, XSLT, YAML, PDF, RSS, CSV, WSDL). Также есть библиотеки для работы с архивами, датами, кодировками, матрицами, средства для системного администрирования, распределенных вычислений, поддержки многопоточности и т. д.

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

К недостаткам интерпретатора Ruby можно отнести следующие:

ASP

ASP (Active Server Pages) — технология, разработанная компанией Microsoft, позволяющая легко создавать приложения для Веб.

Программирование на ASP дает разработчикам доступ к интерфейсу программирования приложений Internet Information Server с помощью языка сценариев VBScript и JScript.

ASP работает на платформе операционных систем линии Windows NT и на веб-сервере Microsoft IIS.

Архитектура ASP представлена ниже.

Файлы ASP представляют собой сценарии, интерпретируемые по мере поступления запросов. ISAPI-расширение ASP.DLL связано в IIS с расширениями файлов .asp или .asa.

Порядок обработки таких файлов выглядит следующим образом:

Рассмотрим основы синтаксиса ASP.

IIS различает код, выполняющийся на сервере, и содержимое, отправляемое клиенту с помощью ASP.DLL, анализируя файл ASP на наличие начального " <% " и конечного " %> " тегов и выполняя код, расположенный между ними, с помощью WSH.

Рассмотрим пример:

<% Language=VBScript %>
<HTML>
<BODY>
<%
Response.Write("<p>Hello world!</p>")
%> 
</BODY>
</HTML>

В примере первая строка кода <% Language=VBScript %> сообщает о необходимости использовать интерпретатор языка VBScript. Для вставки строки в документ был использован метод Write стандартного объекта Response.

Событие веб-запроса в ASP обрабатывается с помощью следующих объектов:

ISAPI

Для веб-сервера IIS (Internet Information Server). был разработан специальный программный интерфейс для создания приложений расширяющих стандартные возможности веб-сервера.

ISAPI (Internet Server Application Programming Interface) – многозвенный API для IIS.

ISAPI также реализован в виде модуля mod_isapi для веб-сервера Apache. Таким образом, серверные приложения, разработанные для MS IIS могут также выполняться в Apache и других веб-серверах.

В противоположность CGI - ISAPI-приложение загружается в том же адресном пространстве, что и веб-сервер IIS. Это позволяет повысить производительность приложений благодаря сокращению издержек на запуск отдельных процессов. Однако сбой ISAPI-приложения может привести к неустойчивой работе самого веб-сервера. В 6-ой версии IIS имеется возможность запуска приложений в рамках отдельного процесса.

ISAPI включает в себя 2 компоненты: расширения и фильтры.

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

ISAPI приложения могут разрабатываться с помощью любых языков, поддерживающих экспорт стандартных С -функций, например С, С++, Delphi. Для разработки имеется ограниченное число библиотек для разработки ISAPI приложений, например Intraweb-компоненты Delphi Pascal, специальные MFC-классы, специальная С++ библиотека серверных технологий ATL.

К наиболее важным особенностям ISAPI-расширений можно отнести следующие:

ISAPI-фильтры необходимы для изменения или совершенствования функциональности IIS. Они обычно работают с IIS-сервером и фильтруют каждый запрос. Фильтры применяются для анализа и модификации входящих и исходящих потоков данных.

Фильтры также как и расширения реализуются в виде DLL файлов.

Обычно ISAPI-фильтры используются для решения следующих задач:

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