Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. - Базы данных. Учебник для высших учебных заведений (6-е изд.) - 2009

T C P / I P

Рис. 15.3. Архитектура Web-приложения с модулями расширения сервера

Различают пассивное и активное состояние Web-сервера. Так, Web-cepeep находится в пассивном состоянии, если формируемый им документ содержит

статическую информацию, то есть на Web-странице отсутствуют средства ввода и обработки запросов к серверу.

В активном состоянии Web-cepeep находится при динамическом создании

Web-документов в ответ на запрос пользователя (рис. 15.3) или в случае, когда в обозреватель загружены различные интерактивные элементы формы. Для публикации БД основной интерес представляет активный Wfeb-сервер, реализуемый с помощью модулей расширения Web-cepeepa.

Для организации связи программных расширений Web-сервера с БД используются также современные интерфейсы доступа к данным OLE DB, ADO и ODBC. Эти интерфейсы являются промежуточным уровнем между источником данных и приложением, в качестве которого выступают программные расширения Web-cepBepa.

Для создания модулей расширения Web-cepeepa могут использоваться интерфейсы CGI, WinCGI или интерфейсы программирования API.

Интерфейс CGI является стандартным протоколом взаимодействия меж-

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

Напомним, что интерфейсу CGI соответствуют обычные консольные приложения операционной системы DOS. Обмен информацией между сервером

574 Часть 4. Публикация баз данных в Интернете

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

WinCGI протокол отличается от протокола CGI только тем, что управляю-

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

Для написания CGI-программ подходит практически любой язык программирования, обеспечивающий доступ к переменным среды и ввод-вывод через стандартные потоки STDIN и STDOUT. Для написания CGI-программ подходят среды разработки C++Builder, Delphi, Visual С++ и Java. Кроме того, для этих целей можно использовать интерпретаторы языков Perl, РНР, предназначенные для различных интерфейсов Web-серверов.

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

Для запуска модуля расширения можно использовать следующие способы: •задание адреса URL модуля CGI в строке адреса обозревателя;

•посылка обозревателем серверу запроса на выполнение CGI-модуля при выборе пользователем ссылки, атрибут «href» которой содержит адрес этого модуля;

•нажатие кнопки типа «Submit», входящей в форму, у которой атрибут «Action» содержит адрес URL CGI-модуля.

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

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

576 Часть 4. Публикация баз данных в Интернете

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

Для уменьшения нагрузки на Web-cepeep часть функций, связанных с предварительной обработкой запросов и введенных данных, целесообразно выполнять на стороне клиента (в Web-обозревателе). Эту задачу решают модули расширения клиентской части. В следующем разделе рассмотрим основные особенности архитектуры Web-приложений, использующих модули расширения обозревателя.

Web-приложения с модулями расширения клиентской части

В случае модулей расширения клиентской части (активность на стороне клиента) используют апплеты, подключаемые программы, ActiveXобъекты и сценарии. Эти технологии могут использоваться для создания динамических эффектов при просмотре Web-страницы. Архитектура Webприложения с использованием модулей расширения клиентской части показана на рис. 15.4.

T C P / I P

Рис. 15.4. Схема Web-приложения с использованием модулей расширения обозревателя

Элементы управления ActiveX представляют собой вид модулей расши-

рения, которые могут использоваться на стороне клиента или на стороне сервера. Они реализуются с помощью динамических библиотек DLL и могут быть встроены в Web-документ как дополнительные интерфейсные элементы. Механизм работы элементов управления ActiveX позволяет из программного кода этих объектов получать неограниченный доступ к локальным ресурсам компьютера пользователя. Из элемента управления ActiveX имеется возможность предавать на сервер любую информацию с компьютера пользователя. С точки зрения обеспечения безопасности локальных данных пользователей использование элементов управления ActiveX не всегда оправдано.

Исполняемые программы являются первым поколением клиентских рас-

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

Апплеты Java применяются для создания динамически формируемого

интерфейса пользователя. Апплет представляет собой байтовый код, который интерпретируется виртуальной Java-машиной, входящей в состав обозревателя. У апплетов отсутствует возможность производить запись на диск пользователя. Поэтому использование механизма апплетов гарантирует целостность локальных данных пользователей.

Загрузка апплета производится при загрузке Web-документа. Принцип функционирования апплета включает возможность подключения Java-клас- сов, хранящихся на сервере. Таким образом, сам апплет содержит только необходимый код, а при последующем взаимодействии пользователя с интерфейсными элементами апплета могут дополнительно подгружаться требуемые Java-классы, реализующие дополнительные функции.

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

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

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

Апплет может быть специализирован для работы с внешними базами данных. С этой целью в Java включены наборы классов для поддержки графического пользовательского интерфейса и классы для доступа к БД. С помощью

19 Зак. 541

578 Часть 4. Публикация баз данных в Интернете

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

Для включения дополнительного действия в Web-приложение достаточно включить тег апплета в Web-документ и поместить апплет-класс в библиотеку апплетов на сервере. При этом изменения в конфигурацию Webсервера вносить не нужно.

Для взаимодействия Java-апплета с внешним сервером баз данных разработан специализированный протокол JDBC (Java DataBase Connectivity — совместимость Java с базами данных), который построен на принципах интерфейса ODBC и применяется для стандартизации кода Java-апплета при организации доступа к различным СУБД. Протокол JDBC является посредником между Java-кодом и драйвером ODBC.

Сравним достоинства и недостатки использования технологии Java и наиболее распространенного в настоящее время интерфейса CGI. Использование технологии Java-anrmeTOB реализует более гибкий механизм. Апплет выполняется локально на машине пользователя, поэтому он может обеспечивать динамическое взаимодействие с пользователем гораздо быстрее. Кроме того, апплет может использоваться для выполнения функций, не доступных CGIмодулю. Однако с точки зрения обеспечения безопасности данных компьютеров клиентов сети использование CGI-модуля более целесообразно, так как CGI-модуль выполняется на стороне сервера и получить доступ к ресурсам компьютера пользователя сети не может.

На этом мы закончим рассмотрение общих принципов построения Webприложений и перейдем к рассмотрению архитектуры Web-приложений, публикующих БД.

15.2. Архитектура Web-приложений, публикующих БД

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

При такой архитектуре Web-cepeep передает запрос на генерацию Webстраниц программе-расширению Web-сервера, которая формирует требуемый документ по информации из БД и затем Web-cepeep отсылает готовые Webстраницы обратно обозревателю. Для формирования динамических страниц используются различные средства и технологии: ASP и IDC/HTX-страни- цы, программы-расширения сервера на основе интерфейсов CGI и ISAPI.

При использовании ASP, РНР и IDC/HTX-страниц запрос на получение динамически формируемой Web-страницы передается специальным динамическим библиотекам, входящим в состав Web-сервера. Например, если в ка-

честве Web-сервера используется Personal Web Server и публикация осуществляется средствами IDC/HTX, то применяется динамическая библиотека «httpodbc.dll». Такие библиотеки анализируют файл ASP или IDC и НТХфайлы, которые используются в качестве шаблонов.

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

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

При динамической публикации Web-страницы создаются после поступле-

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

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

Двухуровневые Web-приложения

При двухуровневой архитектуре Web-приложений источник БД хранится на том же компьютере, где находится Web-cepBep. Для доступа к источнику БД используются модули расширения. В простейшем случае в архитектуру Web-приложений добавляется источник БД (рис. 15.5).

Схема функционирования Web-приложения при такой архитектуре заключается в следующем. Обозреватель для начала работы с Web-нриложени- ем отсылает URL-адрес главной страницы Web-приложения Wcb-еерверу. Последний, обработав URL запроса, высылает главную страницу Web-при- ложения обозревателю в формате HTML. Эта страница несет общую информацию о Web-приложении и позволяет выбрать требуемую для пользователя функцию из ряда других, предоставляемых этим Web-приложением. Далее

возможны несколько вариантов работы Web-приложения.

мированию HTML-страниц выполняется Web-сервером и модулями расширения Web-ccpeepa;

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

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

Трехуровневые Web-приложения

При внесении в Web-приложение промежуточного уровня, основанного на технологии клиент-сервер, его архитектура расширяется до трехуровневой. При такой архитектуре клиентский уровень занимает обозреватель, на уровне сервера находится сервер БД, на промежуточном уровне находятся Web-сервер и модули расширения сервера. Модуль расширения сервера выступает преобразователем протоколов между клиент-серверным приложением БД и Web-сервером (рис. 15.6).

Рис. 15.6. Архитектура трехуровневого Web-приложения, использующего БД

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

Для получения данных модуль расширения Web-cepeepa формирует и отсылает SQL-запрос удаленному серверу БД (SQL-серверу). На компьютере,

вер обеспечивает выполнение запроса и выдачу модулю расширения Webсервера результатов запроса.

Таким образом, в трехуровневой архитектуре вся обработка SQL-запроса выполняется на удаленном сервере. Достоинства такой архитектуры по сравнению с предыдущей состоят в следующем:

•уменьшение сетевого трафика — в сети циркулирует минимальный объем информации;

•увеличение уровня безопасности информации, поскольку обработка запросов к базе данных выполняется сервером БД, который управляет доступом к базе данных, запрещая одновременное изменение одной записи различными пользователями и реализуя механизм транзакций;

•повышение устойчивости Web-приложения к сбоям;

•взаимозаменяемость компонентов архитектуры трехуровневого Webприложения;

•снижение сложности модулей расширения Web-сервера, в которых отсутствует программный код, связанный с контролем БД и разграничением доступа к ней.

Недостатком рассмотренной архитектуры является увеличение времени обработки запросов, связанное с дополнительным обращением по сети к серверу БД. Для устранения этого недостатка между сервером БД и Web-сервером должны использоваться высокоскоростные надежные линии связи.

Многоуровневые Web-приложения

Дальнейшее развитие архитектуры Web-приложений и технологии «клиент-сервер» привело к появлению многоуровневой архитектуры, в которой между модулем расширения Web-сервера и базой данных, кроме сервера БД, дополнительно вводится сервер приложений. Сервер приложений является промежуточным уровнем, который обеспечивает орга-

низацию взаимодействия клиентов («тонких» клиентов) и сервера БД (рис. 15.7).

Напомним, что сервер приложений может использоваться для выполнения различных функций, которые в предыдущей архитектуре выполнялись сервером БД или модулем расширения Web-cepeepa.

В качестве «тонкого» клиента в этой архитектуре выступает программамодуль расширения Web-cepeepa. Сервер приложений может обеспечивать взаимодействие с Web-серверами и серверами БД, функционирующими на различных аппаратно-программных платформах (компьютерах различных типов и под управлением различных операционных систем). Такая архитектура является основой для интранет-сетей, создаваемых на основе существующих локальных сетей.