В первой части статьи «Разработка web-приложений» была рассмотрена архитектура web-приложений, а также схема взаимодействия модулей расширения клиентской и серверных частей.
Архитектура web-приложений, работающих с БД
Web-приложение, которое работает с базой данных ничем не отличается от обычного клиент-серверного десктопного приложения в отношении подключения к базе данных. Также, как и у десктопного приложения архитектура web-приложения, работающего с базой данных может быть выполнена как двухуровневая клиент-серверная архитектура, трехуровневая, многоуровневая. Здесь все также добавляется сервер приложений, сервер базы данных.
Если база данных находится вообще на другом компьютере, а СУБД на другом, то еще добавляется и тот компьютер, где находится база данных.
Web-севрер передает запрос от браузера программе расширению, которая используя шаблон для генерации внешнего вида страниц и используя информацию из базы данных, подставляет в этот шаблон полученные данные из базы. В итоге получается web-страница.
И как было сказано в предыдущей статье, такое формирование web-страницы выполняется с помощью одной из технологий: программ на основе протоколов CGI/WinCGI и ISAPI, которые являются расширением web-сервера или, например, используя технологию ASP/ASP.NET и IDC/HTX.
Чтобы сформировать динамическую web-страницу при использовании технологии ASP/ASP.NET и IDC/HTX, необходимо передать запрос специальной динамической библиотеки, которая входит в состав web-сервера. Эти библиотеки проводят анализ файлов ASP, IDC и HTX, являющихся шаблонами будущего web-документа.
Разработка web-приложений с двухуровневой архитектурой
В статье описаны архитектуры двух и трехуровневых приложений. Для читателей, не имеющих представления об этих технологиях, необходимо сначала ознакомиться с ними.
При двухуровневой клиент-серверной архитектуре база данных и сервер базы данных находятся на том же компьютере, на котором расположен web-сервер. При этом возможно два варианта исполнения такой схемы:
- первый вариант заключается в том, что сервер базы данных (SQL-сервер или по-простому СУБД) не используется а доступ к ней осуществляется средствами программы расширения web-сервера. Здесь стоит отметить, что, если при двухуровневой клиент-серверной архитектуре в десктопном приложении в схеме присутствовал сервер базы данных (СУБД), то в двухуровневой архитектуре его нет, а его функции выполняет расширение web-сервера;
- при втором варианте СУБД все-таки может присутствовать, но оно должно также находиться на том же компьютере, где расположен web-севрер.
Давайте посмотрим на обе схемы. Они очень похожи друг на друга.

Что здесь происходит? Браузер высылает запрос (URL-адрес) web-серверу, который web-сервер адресует своей программе-расширению. Дальнейшая работа отличается в зависимости от того, какой тип web-сервера используется.
Если в качестве web-сервера IIS (Microsoft Internet Information Server), то в программе-расширении используются такие протоколы как ISAPI, CGI/WinCGI, а также технология ASP/ASP.NET и IDC/HTX. Если же в качестве web-сервера используется сервер Apache (об этих серверах мы поговорим в одной из следующих статей), то тогда программа расширения использует протокол CGI.
Для извлечения данных из базы данных программа-расширения сервера формирует запрос к базе данных в формате языка SQL.
Сам же доступ к базе данных из программы-расширения также зависит от выбранного web-сервера. Например, если используется web-сервер IIS и технология ASP/ASP.NET, то применяется модель доступа к данным ADO/ADO.NET соответственно. Так же могут применяться интерфейс доступа к данным ODBC и модель OLE DB, которые были рассмотрены ранее в статье «Базы данных и Интернет».
Главный недостаток такой архитектуры заключается в том, что web-сервер и его расширение занимаются не только формированием web-страницы, но еще и получением выборок из базы данных, а также обработкой полученных выборок. Из-за этого нагрузку также испытывает не только программа-расширение, но и весь компьютер в целом, на котором расположены все эти программы.
Второй недостаток не менее важный и заключается он в том, что тяжело обезопасить базу данных в отношении конфиденциальности данных, а так же в отношении сбоев в работе базы дынных.
Теперь второй вариант схемы, но число недостатков от этого не уменьшается, поскольку физическое расположение всех узлов все также находится на одном компьютере. Единственное что, в отношении безопасности данных становится немного проще, поскольку СУБД (сервер БД) можно использовать для управления политикой безопасности при работы с базой данных.

Ну а решением перечисленных проблем является вынос СУБД (сервера базы данных) и самой базы данных на отдельную машину.
Трехуровневые web-приложения
При такой архитектуре на компьютере web-сервера находятся собственно web-сервер и его расширение: Схематично это выглядит следующим образом:

При такой архитектуре обработкой запросов к базе данных занимается не расширение web-сервера, а сервер БД, который к тому же находится на другом компьютере.
Такая архитектура имеет только один недостаток, связанный с тем, что за счет дополнительного звена (сервера БД) увеличивается время отклика для обозревателя.
Многоуровневые клиент-серверные web-приложения
Многоуровневая клиент-серверная архитектура является следствием дальнейшего развития данной технологии. Как ни трудно догадаться, в данной архитектуре дополнительно добавляется еще один уровень — сервер приложений.
Как и в десктопной клиент-серверной архитектуре, здесь на сервер приложений выносятся все объекты доступа к данным, превращая клиентские программы в тонких клиентов. Но в данной архитектуре тонким клиентом является программа-расширение web-сервера, ибо механизмы доступа и обработки данных переносятся на сервер приложений.
Получается, что сервер приложений забирает на себя часть функций от программы расширения web-сервера и часть функций от сервера базы данных, причем web-сервер со своим расширением и сервер базы данных могут работать на разных операционных системах.
Вкратце, такая архитектура выглядит следующим образом:

У такой архитектуры много преимуществ. Например, с помощью такого построения можно публиковать в Интернете данные из баз данных локальной сети. Взаимодействие между web-сервером и сервером базы данных становится более гибким, администрирование сервера базы данных становится проще.
Более того, используя такой подход, как конструктор можно добиться смешанного использования архитектуры, как показано на рисунке ниже:

Как вы можете видеть на этой схеме, при смешанном подходе используются клиенты, работающие в браузере (web-приложение), а также клиенты, работающие через сервер приложений (тонкие клиенты) и клиенты, работающие непосредственно с СУБД (толстые клиенты).
Архитектура web-приложений на основе технологии CORBA
Common Object Request Broker Architecture — общая архитектура с брокером при запросе объекта является еще одной архитектурой построения web-приложений.
Работает данная архитектура в тандеме с апплетами Java.
CORBA — это протокол распределенных объектов с открытыми стандартами. Аналогичной технологией является технология от компании Microsoft под названием Distributed Component Object Model (DCOM) — распределенная модель объектов.
CORBA является платформонезависимой технологией. Поскольку CORBA отлично работает с Java, то Java можно использовать совместно с Delphi в данной архитектуре.
Язык Java в полной мере не позволяет разработать клиент-серверное приложение, зато является довольно гибким при создании распределенных систем, обеспечивая связь между объектами CORBA и переносимыми приложениями Java.
Протокол CORBA применяется в построении web-приложений вместо протоколов CGI.
Благодаря объединения протокола CORBA и апплетов, написанных на языке Java появилась, так называемая, объектная модель Web. Ее применение подразумевает использование разных моделей в одном web-приложении (ADO, CORBA и другие модели)
В результате объединения Java-апплетов и CORBA-интерфейса появилось новое поня-
тие — объектная модель Web, означающее использование объектных моделей различ-ных интерфейсов (модели CORBA, ADO и др.) при построении Web-приложений.
Архитектура такого многоуровневого клиент-серверного Web-приложения, построен-
ного на основе технологии CORBA и Java, приведена на рис. 31.9.
На первом уровне находится клиентское приложение — обозреватель. В нем выполня-
ется клиентский апплет Java, из которого может осуществляться обращение к объектам
CORBA.
На втором уровне находится Web-сервер, обрабатывающий HTTP-запросы и CORBA-
вызовы клиентских приложений. Третий уровень соответствует серверу приложений, который реализуется с помощью посредника запросов ORB. Ну и четвертым уровнем является уровень сервера БД и самой БД. В общем все та же схема, только на уровне приложений выступает посредника запросов ORB. Схема такого подхода отображена ниже:
