133. Технология Web Broker. Структура серверного Web-приложения

Структура серверного Web-приложения

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

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

Непосредственное взаимодействие с сервером осуществляет глобальный объект приложения. Его роль — создание и инициализация всех структур, необходимых для запуска кода, содержащегося в Web-модуле. В ряде случаев этот глобальный объект также управляет пулом потоков, обрабатывающих запросы, — это необходимо для приложений, работающих в режиме высокой нагрузки. Этот глобальный объект приложения нивелирует разницу между перечисленными ранее типами интерфейсов — ISAPI, CGI и Apache.

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

Диспетчер выполняет четыре основные операции:

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

2. формирует из поступившей от сервера информации и списка параметров объект TWebRequest;

3. вызывает так называемое действие — код, отвечающий за обработку данной команды;

4. получает объект ответа TWebResponse, при необходимости дополняет и модифицирует его и отдает вызвавшему приложению.

Сам по себе компонент TWebDispatcher применяется не очень часто, но он является составной частью Web-модуля — компонента TWebModule.

Web-модуль — объект, объединяющий в себе роли модуля данных и Web-диспетчера. Это следует понимать буквально: TWebModule = TDataModule + TWebDispatcher. Поэтому Web-модуль, с одной стороны, инкапсулирует действия, а с другой — справляется и с традиционной ролью модуля данных, а именно служит контейнером для хранения невизуальных компонентов и их программного кода.

В рамках технологии Web Broker в приложении может быть один и только один компонент-диспетчер, поэтому, в отличие от модулей данных TDataModule, вы не можете иметь более одного TWebModule или поместить на TWebModule компонент TWebDispatcher.

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

Для реализации бизнес-логики используются специальные объекты - действия (Actions). Действия имеют методы-обработчики события onAction, которые вызываются диспетчером при обработке запроса. Именно в них необходимо реализовывать операции приложения. Коллекция действий находится в каждом диспетчере.

Пользовательский интерфейс клиента — это браузер, поэтому серверное приложение возвращает Web-страницы - набор тегов HTML (или XML). Можно средствами Borland Builder C++ выбрать готовую — статическую — страницу и вернуть ее пользователю. Однако более предпочтителен динамический способ формирования страниц; для этого в Builder C++ используются компоненты-продюсеры, которые умеют формировать страницу на основе шаблонов НТМL или XML, а также таблиц баз данных и SQL-запросов; то есть они создают набор тегов HTML и код сценариев, обеспечивающих корректное представление и поведение страницы в браузере клиента. На странице «Internet» Палитры компонентов Borland Builder C++ доступны несколько компонентов-продюсеров для доступа к разным источникам данных.