Технологии программирования Web

Программирование на стороне сервера в настоящее время является необходимым

условием для решения широкого спектра задач. Оно позволяет:

a) получать и обрабатывать на сервере данные, введенные пользователем при

помощи формы;

b) динамически создавать web-документы, не зависящие ни от платформы, ни

от браузера клиента;

c) обеспечивать динамический доступ к данным, находящимся на сервере, в

частности, к серверным базам данных (при таком способе доступа HTML-

документ автоматически изменится, как только изменятся хранящиеся на

сервере данные);

d) использовать серверные компоненты, предназначенные для решения типовых

задач (таких, например, как циклическая смена рекламных баннеров и

др.);

e) осуществлять аутентификацию пользователя;

f) получать информацию о браузере клиента;

g) создавать и читать ключики на стороне клиента;

CGI: Технология «клиент-сервер»

Большое количество World Wide Web приложений основано на использовании

внешних программ, управляемых Web сервером. Использование данных программ

позволяет строить Web приложения с динамически обновляемой информацией,

хранящейся в базах данных или генерирующейся в зависимости от бизнес-правил

решаемых задач. Для связи между Web сервером и вызываемыми программами

широко используется Common Gateway Interface (CGI), имеющий реализации как

для Windows-ориентированных программ, так и для приложений, функционирующих

в среде Unix.

CGI - Common Gateway Interface является стандартом интерфейса (связи)

внешней прикладной программы с информационным сервером типа HTTP, Web

сервер.

Обычно гипертекстовые документы, извлекаемые из WWW серверов, содержат

статические данные. С помощью CGI можно создавать CGI-программы, называемые

шлюзами, которые во взаимодействии с такими прикладными системами, как

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

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

Т.о., программа-шлюз запускается WWW сервером в реальном масштабе времени.

WWW сервер обеспечивает передачу запроса пользователя шлюзу, а она в свою

очередь, используя средства прикладной системы, возвращает результат

обработки запроса на экран пользователя. Программа-шлюз может быть

закодирована на языках C/C++, Fortran, Perl, TCL, Unix Schell, Visual

Basic, Apple Script. Как выполнимый модуль, она обычно записывается в

поддиректорий с именем cgi-bin WWW сервера.

Интернет вообще и WWW в частности работает по технологии «клиент-сервер»,

то есть все программное обеспечение разделяется на клиентскую и на

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

Важным для понимания моментом является то, что клиент не знает и не обязан

знать принципы работы и реализацию внутренних алгоритмов сервера, а сервер

не вмешивается в дела клиента. Для взаимодействия этих частей разработан

специальный протокол (в частном случае — протокол HTTP), и все

взаимодействие между клиентом и сервером осуществляется исключительно в

рамках данного протокола. Вашему броузеру все равно, какое программное

обеспечение стоит на сервере, какая там операционная система, где физически

лежат запрашиваемые документы на сервере (и лежат ли вообще, ведь они могут

и генерироваться на лету специальными программами). Сервер тоже не

вмешивается в дела вашего броузера, серверу абсолютно все равно, что

сделает клиент с переданной информацией, как он ее будет отображать,

сохранит на диске или проигнорирует — серверу до этого дела нет.

Взаимодействие клиента и сервера происходит по принципу «запрос-ответ».

Клиент посылает запрос, сервер обрабатывает его и посылает ответ (рис. 1.1-

1):

Рассмотрим более детально все этапы соединения по протоколу HTTP:

1. Формирование запроса клиентом. (Броузер формирует запрос из URL,

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

2. Установка соединения с сервером. (Если установить соединение не

удается, то на этом HTTP-транзакция закончится и клиент выдаст

пользователю сообщение об ошибке.)

3. Посылка запроса и ожидание ответа от сервера. (Все, что требуется

от клиента, это чтобы запрос был в корректном формате.)

4. Сервер принимает запрос. (Об этом и следующем этапе клиенту ничего

не известно.)

5. Сервер обрабатывает запрос.

6. Генерация ответа.

7. Прием ответа клиентом.

8. Разрыв соединения.

9. Обработка данных клиентом. (Вывод или сохранение данных.)

Обычно под запросом к серверу понимается URL (это унифицированная форма

«заказа» данных на сервере). К собственно URL могут еще «прилагаться»

некоторые данные, чаще всего это данные форм (вспомните, как вы вводите

ключевое слово в поисковике). Формирование HTTP-запроса будет детально

рассмотрено в одном из следующих уроков.

При установке соединения с сервером сначала происходит трансляция

символьного доменного имени, такого, как www.siemens.com, в IP-адрес, а

затем осуществляется непосредственно создание TCP/IP-соединения с данным

IP. Когда данные HTTP-запроса посланы серверу, клиент просто ожидает, пока

не придет ответ.

Пока нет обращений от клиентов, сам HTTP-сервер просто «спит» в ожидании

запросов. Когда клиент устанавливает соединение, сервер «просыпается» и,

приняв данные запроса, приступает к их обработке. Что именно сервер делает

с запросом — известно только самому серверу. Единственный результат всех

хитрых манипуляций — это выдача ответа, которого и ожидает клиент.

После того как сервер выдал ответ, он разрывает соединение и вновь

«погружается в сон». Естественно отметить, что в случае возникновения

ошибки HTTP-транзакция может закончиться на любом из этих этапов.

Все девять этапов HTTP-соединения показаны на рис. 1.2.

Если документ не найден или если для доступа к нему у вас нет прав (доступ

к ресурсу может быть ограничен), то выдается код ошибки. А если все

нормально, то информация, содержащаяся в документе, включая сопутствующие

данные о его типе, выдается в виде ответа.

Схема взаимодействия «клиент-сервер» для случая, когда URL указывает на CGI-

обработчик, показана на рис. 1.3.

Технология SSI

SSI (Server Side Includes, включения на стороне сервера) - это директивы,

вставляемые в HTML-код и служащие для передачи указаний серверу.

SSI позволяют "вставлять" фрагменты одних документов в другие. Конечно, это

можно сделать непосредственно в текстовом редакторе, но если, например, в

несколько документов вставляется один и тот же фрагмент, к тому же часто

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

Сервер интерпретирует SSI-директивы и выполняет соответствующие действия.

Использование SSI-вставок позволяет динамически формировать странички в

зависимости от различных параметров(например, типа браузера).

Преимущества SSI проявляются тем сильнее, чем больше по объему сайт,

имеющий повторяющиеся элементы кода на разных страничках.

Для того, чтобы сервер знал, что страничка не обычная, а содержит SSI-

директивы, используется специальное расширение: shtml или shtm. (Вообще-то,

конфигурация сервера может быть настроена и на другое расширение, но shtml

воспринимается всегда (если только на сервере не отключено применение SSI

вообще).

Для того, чтобы указать серверу, какой блок нужно вставить и в каком месте

странички, используется специальная форма записи в виде комментария:

|[an error occurred while processing this directive] |

При просмотре сформированного исходника HTML-файла пользователь не увидит

никаких признаков SSI, т.к. браузер получает уже готовый HTML-код.

Первое преимущество SSI с точки зрения дизайнера заключается в том, что при

таком подходе web-мастеру, занимающимуся поддержкой сайта, можно не бояться

случайно испортить дизайн. Элементы сложной верстки скрыты за счет

использования SSI, и поддержка содержимого страничек становится гораздо

более легким и приятным делом. Второе, не менее важное преимущество, - это

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

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

внешний вид сайта.

Не является ли SSI альтернативой CGI? Скорее, это дополнение (и очень

ценное) к CGI, предоставляющее web-программисту множество удобств.

ISAPI

Подобно CGI, спецификация ISAPI (Internet Server Application Programming

Interface) определяет правила взаимодействия между Web-сервером и

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

альтернативный подход к созданию программ, выполняющихся на сервере,

поговорим о преимуществах и недостатках стандарта CGI.

Несомненным преимуществом CGI является универсальность. CGI-сценарии могут

быть написаны на разных языках и выполняться на компьютерах с различной

архитектурой. Если при написании сценария вы учли все правила, то можете

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

взаимодействовать с любым Web-сервером. Простота CGI также способствует

широкому распространению этого стандарта.

Однако, наряду с преимуществами, CGI-сценарии обладают некоторыми

недостатками; главным из которых считается неэффективное использование

ресурсов. Каждый из запросов клиента, предполагающий вызов сценария,

порождает отдельный процесс на компьютере-сервере. Как известно, для

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

работы потока в составе процесса.

Стремление повысить производительность и снизить затраты ресурсов привело к

созданию корпоративных стандартов. Наиболее известными из них являются

NSAPI и ISAPI.

Основное отличие ISAPI-программы от CGI-сценария состоит в том, что ISAPI-

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

(DLL). Благодаря этому появилась возможность запускать программу не как

отдельный процесс, а как поток, принадлежащий Web-серверу. Для выполнения

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

процесса. Поток использует адресное пространство породившего его процесса и

работает намного быстрее, чем отдельный процесс.

По окончании выполнения процесс выгружается из памяти, а при поступлении

следующего запроса снова загружается с диска. Это также не способствует

эффективной работе CGI. При интенсивном поступлении запросов необходимость

постоянного обмена с диском создает дополнительную нагрузку на сервер. В

отличие от CGI-сценария, ISAPI-программа, окончив свою работу, как правило,

остается резидентной в памяти и используется для обработки последующих

запросов.

Однако иногда преимущества ISAPI-программ оборачиваются недостатками. (Это

не удивительно. Ведь если бы ISAPI-программы были свободны от недостатков,

они бы быстро вытеснили CGI-сценарии.)

Если за универсальность CGI-сценариев пришлось платить недостаточной

производительностью, то в качестве платы за высокую производительность

создатели ISAPI-программ жертвуют универсальностью. Арсенал языков,

имеющихся в распоряжении разработчиков ISAPI-программ, значительно беднее,

чем у их коллег, создающих CGI-сценарии. По сути, тому, кто хочет быстро

написать достаточно большую ISAPI-программу, не остается иного выбора,

кроме C++.

Второй недостаток ISAPI гораздо серьезнее первого. Поскольку программа

данного типа выполняется как поток, порожденный сервером, она использует

адресное пространство сервера. Следовательно, ошибка ISAPI-программы может

не только вызвать ее аварийное завершение, но и вывести из строя сервер.

Программы, использующие спецификацию ISAPI, делятся на две категории.

* Расширения. Функционально они мало чем отличаются от CGI-сценариев.

Подобно CGI-сценариям, расширения реализуют дополнительные возможности Web-

сервера, но строятся совершенно по-другому. Рассмотрению ISAPI-расширений

посвящена данная глава.

* Фильтры. Это особый класс программ. Если расширения дополняют

возможности Web-сервера, то фильтры изменяют его поведение. Принцип работы

и реализация ISAPI-фильтров будут рассмотрены в следующей главе.

ISAPI-расширение представляет собой динамическую библиотеку (DLL), которая

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

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

GetExtensionVersion() и HttpExtensionProcf).

Особенности выполнения ISAPI-расширений, а также основные отличия программ

данного типа от CGI-сценариев проще всего выяснить, рассматривая процедуру

вызова расширения, а также назначение указанных выше функций и параметров,

передаваемых при их вызове.

В отличие от расширения, которое вызывается лишь тогда, когда в запросе

клиента явно указан URL программы, ISAPI-фильтр получает управление при

каждом обращении клиента к серверу. Программа-фильтр загружается в память

при запуске Web-сервера и остается резидентной в течение всего времени

работы сервера.

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

Perl - интерпретируемый язык, приспособленный для обработки произвольных

текстовых файлов, извлечения из них необходимой информациии и выдачи

сообщений. Он также удобен для написания различных системных программ. Этот

язык прост в использовании, эффективен, но про него трудно сказать, что он

элегантен и компактен.

Perl был создан в 1986 году как инструмент для администрирования и

конфигурирования системных ресурсов сети, состоящей из Unix-компьютеров. Он

сочетает в себе лучшие черты C, shell, sed и awk, поэтому для тех, кто

знаком с ними, изучение Perl-а не представляет особого труда. Cинтаксис

выражений Perl-а близок к синтаксису C. В отличие от большинства утилит ОС

UNIX Perl не ставит ограничений на объем обрабатываемых данных и если

хватает ресурсов, то весь файл обрабатывается как одна строка. Рекурсия

может быть произвольной глубины. Хотя Perl приспособлен для сканирования

текстовых файлов, он может обрабатывать так же двоичные данные и создавать

.dbm файлы, подобные ассоциативным массивам. Perl позволяет использовать

регулярные выражения, создавать объекты, вставлять в программу на С или C++

куски кода на Perl-е, а также позволяет осуществлять доступ к базам данных.

Язык Perl был создан для повышения эффективности обработки текстовых

документов. Он ориентирован на обработку строк. В настоящее время язык

получил большое распространение как инструмент создания исполняемых модулей

WWW-сервера. Существующие пакеты расширения обеспечивают доступ к SQL-

серверам непосредственно из Perl-программы. Это позволяет использовать его

для решения всех задач, возникающих при обеспечении WWW-доступа к базам

данных. Perl эффективен также при обработке произвольных структур данных:

существующих отчетов, списков, карточек в электронном виде.

Хотя CGI-приложения можно писать практически на любом языке, Perl и CGI-

программирование стали синонимами для многих программистов. Как сказал

Хасан Шрейдер (Hassan Shroeder), первый вебмастер Sun, «Perl - это артерия

Интернета». Perl - самый широко используемый язык для CGI-программирования,

и для этого есть много веских причин:

• Perl легко выучить: его синтаксис напоминает другие языки (например

С), потому что он «многое прощает», - при ошибке выдается подробное

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

• Perl способствует быстрой разработке, так как это интерпретируемый

язык; исходный код не надо компилировать перед запуском.

• Perl доступен на многих платформах с минимальными изменениями.

• Perl содержит очень мощные функции для обработки строк со встроенной

в язык поддержкой поиска и замены по регулярным выражениям.

• Perl обрабатывает двоичные данные так же легко, как и текст.

• Perl не требует четкого разделения на типы: числа, строки и

логические выражения являются обычными скалярами.

• Perl взаимодействует с внешними приложениями очень просто и

обеспечивает собственные функции для работы с файловыми системами.

• Для Perl есть много свободно доступных модулей от CPAN, начиная с

модулей для создания динамической графики до интерфейсов с Интернет-

серверами и системами управления базами данных. За подробной

информацией по CPAN обратитесь к приложению В.

Perl действительно очень быстрый: считывая исходный файл, он тут же

компилирует его в низкоуровневый код, который потом исполняет. Обычно

компиляция и исполнение в Perl не воспринимаются как отдельные шаги,

поскольку выполняются вместе: Perl запускается, читает исходный файл,

компилирует его, запускает и затем завершает работу. Этот процесс

повторяется каждый раз, когда запускается сценарий Perl, в том числе CGI-

сценарии. Поскольку Perl так эффективен, этот процесс происходит достаточно

быстро, чтобы обрабатывать все запросы не на самых загруженных серверах.

Однако следует обратить внимание, что в системах Windows это гораздо менее

эффективно из-за необходимости создания новых процессов.

PHP

РНР изобретен Расмусом Лердорфом в конце 1994 года. Первая версия выпущена

в 1995 году под именем «Инструментарий Персональных Домашних Страниц»,

затем она была переработана и названа PHP/FI Version 2 (FI — модуль

обработки данных для форм). Также была добавлена поддержка баз данных mSQL.

С этого момента в разработке стали принимать участие добровольцы.

Статистика используемости РНР приблизительна, но, согласно исследованию,

проведенному Netcraft, в начале 2001 года РНР использовался на более чем 5

300 000 сайтах по всему миру. Для сравнения: в это время число IIS серверов

было примерно таким же (5 млн). Разработка интерпретатора РНР приняла форму

организованного командного процесса, ядро интерпретатора разрабатывает

компания Zend.com. При этом РНР распространяется свободно: его последнюю

версию можно загрузить с сайта PHP.net. Модули РНР поставляются в комплекте

с сервером Apache, в комплектах систем Linux.

Изначально аббревиатура РНР означала Preprocessor of Home Pages —

препроцессор домашних страниц. Это язык внедряемых в HTML-страницы

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

заимствован из таких языков, как С, Perl, Java, и при этом добавлена масса

возможностей, которых этим языкам недостает. Проще говоря, синтаксис РНР —

это разумная альтернатива и строгости С, и «беспредельности» Perl.

РНР наделен практически полным набором функциональности, о которой (до

появления РНР) мог только мечтать web-программист. Его цель — позволить

максимально быстро создавать динамически генерируемые web-страницы. С

полным основанием можно заявить, что изучение и использование РНР будет

выгодно как начинающим, так и профессиональным программистам.

Основными конкурентами РНР являются технологии JSP (Java Server Pages и

Java Scriptlets), ASP (Active Server Pages), Perl, SSI (Server Side

Includes), Cold Fusion Server Pages.

Рассмотрим те недостатки, которые присущи указанным технологиям. JSP —

достаточно сложный для изучения и использования язык. ASP, основанный на

синтаксисе VBScript (Visual Basic), имеет всего несколько десятков

собственных функций и поэтому вынужден использовать СОМ-объекты; кроме

того, он ориентирован исключительно на работу под Windows. Perl — язык

головоломный, и его вольности затрудняют его понимание. SSI позволяет всего

лишь компоновать HTML-страницу из нескольких файлов. CF — коммерческий

продукт, что является его основным недостатком.

Основные достоинства РНР:

. бесплатен; постоянно совершенствуется; работает на UNIX и Windows

платформах;

. допускает работу с большинством СУБД;

. имеет широкий набор функций (более 3 тыс.);

. допускает объектно-ориентированное программирование;

. способен использовать протоколы HTTP, FTP, ШАР, SNMP, NNTP, РОРЗ, net

sockets и другие;

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

и даже работать с файлами графики. Можно также запускать РНР-скрипты

как интерпретируемые файлы и компилировать исполняемые приложения (в

том числе с поддержкой графического интерфейса GTK).

Если вы обнаружите, что РНР не способен на что-то (или работает не так, как

вам хотелось бы), никто не будет препятствовать вам вносить в исходный код

РНР (написанный на С) желаемые изменения. РНР является программным

продуктом с открытым исходным кодом, и внесение в него улучшений и

дополнений путем создания собственных модулей расширения всегда

приветствуется.

ASP и ASP.NET в составе Microsoft.NET

В конце 1997 г. Microsoft реализовала относительно простую среду периода

выполнения пля Web — Active Server Pages (ASP) как часть сервера Internet

Information Server (IIS), включенного в Windows NT 4 Option Pack. IIS

обслуживает Web-страницы, запрашиваемые пользователем. ASP позволяет

программистам реализовывать алгоритмы динамического создания страниц на

IIS, состоящих из статического HTML и кода сценариев. Когда пользователь

запрашивает ASP-страницу, IIS должен ее найти и активизировать ASP-

процессор. ASP-процессор должен прочитать страницу и один к одному

скопировать содержащиеся на ней HTML-элементы в выходную страницу. В нашем

примере атрибут style устанавливает голубой цвет текста. При этом также

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

HTML-строки, которые ASP-процессор должен скопировать в выходную страницу в

те места, где были элементы сценария. Результирующая страница, собранная из

статических HTML-элементов и HTML, динамически сгенерированного сценарием,

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

легко, что является признаком качества этой технологии.

Страницы: 1, 2, 3, 4