Разработка web-приложений — это одно из популярнейших направлений программирования на сегодняшний день. Особенно это касается программистов, которые любят писать нативные приложения для Windows.
Как известно, Windows постепенно вытесняется Linux. Не знаю, будет из этого толк или нет, но я никогда не был фанатом Linux. Конечно, большинство специалистов считают, что Linux безопаснее Windows и реже взламывается. Но мое мнение на счет этого такое, что он редко взламывается, потому что он не так популярен. Посмотрим, что с ним будет через 10 лет, когда количество вирусов для него также вырастет, как и под Windows. Ну да ладно, тема не об этом.
Тема о том, что разработка web-приложений является отличным способом преодолеть психологический Linux-барьер тем программистам, которые любят Windows. В принципе, вы без труда и сейчас можете писать под Windows кроссплатформенные программы, которые будут либо использовать промежуточные виртуальные машины наподобие Java или Jit-компилятор для .Net, либо непосредственно из одного проекта компилировать приложение сразу для разные платформ, как это делает Delphi.
Но сейчас технологии шагнули еще больше. Теперь для создания web-приложений не нужно изучать классический стек вроде: html+css+JavaScript и для бекенда — PHP/Python. Теперь разрабатывать web-приложения можно точно также, как это делалось для Windows, то есть, перетаскивая объекты на форму, которая будет являться будущей страницей HTML и писать бекенд также в этой же среде программирования. Я говорю о современном Delphi. То есть, больше не нужно изучать JavaScript для того, чтобы писать фронтэнд и PHP/Python/Ruby/C#, чтобы писать бекенд. Сейчас все можно сделать на одном языке. И можно также подключать имеющиеся стили через файлы .CSS и работать совместно с дизайнером.
Более того, даже JavaScript развился на столько, что на нем можно писать замечательный код для бекенда.
Программировать становится все интересней. Конечно кому то нравятся классический подходы, потому что эти программисты сразу обучались именно им, кому то нравятся технологии от Microsoft по типу ASP.NET,третьим нравятся другие... Самое главное, чтобы конечное приложение было качественным и легко масштабировалось. А так, в принципе все языки программирования достаточно развиты и хороши. Ну чтобы вообще хоть как то начать создавать web-приложения, нужно ознакомиться хоть существующими технологиями, которые являются общими для всех подходов.
Чтобы изучать эту статью, желательно (для тех, кто плохо знаком с основами) изучить две предыдущие статьи, в которых я начал освящать вопросы создания web-приложений: «Удаленные базы данных» и «Базы данных и Интернет», поскольку современные web-приложения разрабатываются как многоуровневые (многозвенные) клиент-серверные приложения, которые хранят свои данные в базе данных.
Архитектура web-приложений
Web-приложения и Интранет
Интранет — это локальная корпоративная сеть. Но это не типичная локальная сесть в рамках здания или группы зданий. Интранет представляет собой локальную корпоративную сеть, которая использует интернет каналы. То есть, в рамках здания или группы зданий вполне может быть использована одна из сетевых топологий, например «Звезда», а вот с головным офисом дочерняя компания уже может взаимодействовать посредством Интернет-каналов связи. Такая сеть называется Интранет. Это можно еще описать как выделенная часть Интернета.
И вот в рамках этой выделенной части Интернета (в сети Интранет) и выполняются web-приложения. Собственно, появление Интранет и обусловлено тем, что работу web-приложеной в сети Интернет нужно как то защитить от злоумышленников.
Такие сети являются надежными и масштабируемыми. Они легко наращиваются и модернизируются. Главной особенностью Интранет является то, что она развертывается на уже существующей инфраструктуре Интернета.
При использовании web-приложений в Интранет-сети может быть использована архитектура, показанная на рисунке ниже:
Здесь в данной архитектуре браузеры выполняют роль недорогих клиентских приложений. Если по простому сказать, то браузер в такой схеме с помощью web-сервера обращается к серверу приложений или к SQL-серверу (СУБД), если отсутствует сервер приложений. Если используется сервер приложений, то web-сервер может быть расположен на том же компьютере, где и сервер приложений. Тогда такая архитектура будет выглядеть так:
Но у этой архитектуры может быть и разновидность, когда базу данных размещают отдельно от SQL-сервера (СУБД):
Если сервер приложений не используется в архитектуре, то web-сервер может быть расположен на компьютере, где расположен SQL-сервер:
Естественно, что база данных может быть расположена на отдельном компьютере, как и в случае архитектуры с сервером приложений.
Здесь стоит отметить, что при использовании сервера приложений, а также без него web-сервер может вообще быть расположен на отдельном компьютере.
Запросы от браузеров к web-серверу формируются по определенным правилам. Когда web-сервер получает такой запрос, то он должен преобразовать его в формат, понятный серверу приложений или SQL-серверу, например в команду языка SQL. Такое преобразование может выполнять даже не сам web-сервер, а его расширение.
Серверные модули расширения
На рисунке ниже изображена архитектура web-приложения с модулями расширения серверной части:
Сразу поясню, что на рисунке изображены все описанные технологии. Но при построении может быть использована только одна, например ASP или только ISAPI. Но может быть и комбинация технологий.
Разработка модулей расширения обеспечивается с помощью интерфейсов CGI, WinCGI и API.
CGI — стандартный протокол общения web-сервера и модуля его расширения. Модули расширения требуются для того, чтобы расширить функции web-сервера. Чтобы написать программу в соответствии с протоколом CGI потребуется любой язык программирования, дающим возможность работать с переменными среды и вводу-выводу через стандартные потоки STDIN и STDOUT. Delphi вполне подходит для такой задачи. CGI-программы — это консольные программы.
Запуск CGI-модуля сводится к тому, что браузер посылает в адресной строке запрос web-серверу на запуск модуля расширения. CGI-приложение (модуль расширения) подготавливает ответ для web-сервера и передает его ему. Web-сервер пересылает этот ответ с помощью HTML-протокола браузеру.
Когда несколько пользователей обращаются к web-серверу, то есть, множество браузеров посылают запрос на получение web-страницы, то web-сервер при использовании интерфейса CGI на каждое обращение браузера создает отдельный процесс и для каждого из этих процессов web-сервер создает копию CGI-модуля расширения. С одной стороны это нагружает компьютер, на котором находится web-сервер, с другой стороны — сбой в одном из процессов никак не повлияет на работу других процессов.
Если модуль расширения CGI представляет из себя большой файл то при создании отдельного процесса и загрузки этого модуля в оперативную память компьютера, на котором расположен web-сервер будет потрачено много времени. Это является причиной долгого отклика для браузера. Если же язык программирования, на котором написана CGI-программа не компилируемый, а интерпретируемый (например, PHP, Python, Perl), то тогда время отклика будет увеличено еще больше, так как для перевода CGI-программы в машинный язык потребуется загрузить интерпретатор. Соответственно, время отклика будет увеличиваться прямо пропорционально количеству обращений к web-серверу со стороны пользователей.
Операционная система UNIX может использовать единожды загруженные программные коды CGI-приложения для всех процессов. Единственное, что будет меняться для каждого процесса — это данные.
WinCGI — протокол (интерфейс), похожий на CGI, только в нем параметры передаются через файл .INI. Данный интерфейс работает под управлением ОС Windows.
Как уже было написано в предыдущей статье эти интерфейсы несколько устарели и на смену им пришли новые разработки, такие как ISAPI и NSAPI. При создании этих интерфейсов используются не интерпретируемые языки, а компилируемые. И результатом их работы являются созданные DLL-библиотеки, которые и представляют из себя модуль расширения web-сервера.
Как известно, DLL-библиотека загружается в память компьютера один раз, а затем используется для множества процессов.
ISAPI-модуль применяется также для создания ISAPI-фильтра, который на уровне HTTP-протокола контролирует все данные между браузером и web-севрером.
Клиентские модули расширения
Мы ознакомились с построением модуля расширения на стороне сервера. Теперь давайте ознакомимся с модулями расширения на стороне клиента.
Модули расширения на стороне клиента используются для создания динамического пользовательского интерфейса. Для этого могут быть использованы разные технологии: исполняемый файл, апплеты на языке Java, объекты ActiveX. В предыдущей статье эти технологии были рассмотрены.
Применение исполняемого файла для реализации модуля расширения на стороне клиента являлось первым решением в своей области. Для того, чтобы исполняемый файл функционировал, его необходимо установить на машине клиента и сконфигурировать браузер. Но из этого действия вытекает определенная сложность, связанная с тем, что у разных пользователей установлены разные обозреватели. Поэтому такой подход трудно унифицировать не только в части функционала, но в части пользовательского интерфейса.
Для создания динамического интерфейса также используются апплеты, написанные на языке Java. В браузере апплеты выполняются с помощью виртуальной машины Java, которая является для них интерпретатором. Java-машина является частью браузера.
Java-апплет может работать с базами данных. Для этого в Java имеются соответствующие классы. Для работы с базами данных применяется протокол JDBC, по аналогии с ODBC.
Преимущество Java-апплета по отношению к CGI-интерфейсу состоит в том, что Java-апплет находится на машине клиента, и по этой причине выполняется он быстрее. Также у него есть функции, которые отсутствую у интерфейса CGI.
Зато в плане безопасности CGI-интерфейс гораздо предпочтительнее, поскольку в следствии того, что CGI-программа выполняется на сервере у нее нет доступа к ресурсам клиентского компьютера.
Полная схема web-приложения с модулями расширения обозревателя может выглядеть следующим образом:
