Web-серверы в версии Oracle

Попробуем разобраться в отличиях Oracle WebServer 2.0 (OWS 2.0) от других Web-серверов. Как видно из рис. 1, основа OWS 2.0 - два автономных модуля: базовый HTTP-сервер и сервер приложений Web Request Broker (WRB). Стоит отметить, что Oracle WebServer тесно интегрирован с сервером СУБД Oracle7 и позволяет создавать динамические HTML-документы с использованием данных, хранимых в БД.

Что касается HTTP-сервера, то он представляет собой определяемое администратором множество слушающих процессов Oracle Web Listeners (у каждого свой порт, свое виртуальное файловое пространство и схемы защиты). Эти процессы выполняют обычные запросы к статическим HTML-документам и CGI-скриптам. Однако, в отличие от обычного HTTP-сервера, слушающий процесc сначала не анализирует URL, а передает его для обработки WRB. Если адрес ресурса не относится к компетенции WRB, то брокер сразу возвращает запрос слушающему процессу. Таким образом становится возможным подключение непосредственно к диспетчеру WRB HTTP-сервера другого производителя при наличии соответствующего адаптера WRB.

Намного интереснее устроен Web Request Broker - высокопроизводительный многопоточный сервер приложений. WRB API позволяет ему поддерживать динамическую связь с независимыми модулями расширения функциональности сервера (картриджами) различных типов. Открытость API позволяет разработать картриджи, совместимые с Web Request Broker, причем для этого можно использовать любой язык программирования, поддерживаемый узлом с OWS. Управляющий диспетчер WRB-запросов (WRBD, WRB Dispatcher) на основе зарегистрированных в механизме WRB картриджей, в зависимости от нагрузки, создает экземпляры сервисов WRB, которые состоят из общих "машин исполнения WRB" (WRBX, WRB eXecution engines) и динамически подгружаемых библиотек.

Здесь видно различие WRB API и API, разработанных для своих HTTP-серверов другими фирмами: NSAPI компании Netscape Communications, IS-API корпорации Microsoft и т. д. Прикладные интерфейсы HTTP нового поколения (NSAPI, IS-API) позволяют обрабатывать запросы быстрее и экономичнее, чем CGI, но все модули расширения (например, интерпретатор JavaScript, библиотеки C++ и т. д.) компонуются в единый исполняемый модуль и, следовательно, выполняются как единый процесс. Однако в этом случае велика вероятность конфликта модулей производства разных компаний. От этого недостатка избавляет модульная архитектура Web-сервера Oracle.

В состав OWS 2.0 входят следующие картриджи: интерпретатор Java (библиотека классов и утилиты для доступа к Oracle7), интерпретатор LiveHTML (расширение SSI - Server Side Includes) и PL/SQL Agent (оптимизированный многопользовательский доступ к Oracle7, библиотека PL/SQL для генерации динамического HTML), который можно считать самым полезным картриджем для разработки несложных интерфейсов к базе Oracle. На нем имеет смысл остановиться чуть подробнее.

Картридж PL/SQL Agent позволяет создавать Web-приложения, используя хранимые процедуры на языке PL/SQL. Если приложение основано только на данных, хранимых в Oracle7, то использование PL/SQL Agent дает неоспоримые преимущества: удобный и, как показывает практика, вообще самый быстрый доступ к данным Oracle. Кроме того, хорошо знакомый разработчикам язык и гарантированная переносимость на любую поддерживаемую Oracle операционную систему выгодно отличают PL/SQL Agent.

Oracle Web Applicaton Server 3.0

Пожалуй, мощь этого распределенного сервера (рис. 2) действительно пригодится "счастливым" обладателям перегруженных Web-систем. В новой версии не требуется запускать все компоненты (HTTP-сервер, WRB и картриджи) на одной машине. Все эти элементы уже представляют собой CORBA-совместимые распределенные объекты, что позволяет экономично решать проблемы с "узкими местами" для Web-систем. Теперь можно разместить несколько HTTP-серверов различных поставщиков на машинах с CPU средней производительности, и они смогут использовать совместно брокеры объектных заявок (ORB, Object Request Broker) и картриджи расширения функциональности. Для увеличения полосы пропускания можно наращивать число HTTP-серверов, а для обеспечения большего числа одновременно выполняемых запросов следует добавлять узлы для запуска картриджей. Можно выделять под картриджи с высокой нагрузкой отдельные узлы.

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

Любой зарегистрированный в WAS 3.0 картридж может воспользоваться многочисленными сервисами. Особое внимание следует обратить на следующие два сервиса, которые, несомненно, пригодятся при разработке Web-приложений.

Транзакции. До появления Oracle Web Application Server требовалось использовать TP-монитор для поддержки транзакционной модели в Web-приложениях. WAS 3.0 может выполнять транзакции в Internet без отдельного TP-монитора - он опирается на надежного транзакционного менеджера, входящего в состав СУБД Oracle уже в течение 15 лет. Oracle сделала ставку на стандарты открытых систем: API - X/Open Tx, интерфейс к базе данных - X/Open XA (eXtended Architecture). Таким образом, можно, например, выполнять SQL-запросы к другим СУБД, поддерживающим XA.

Для разработки приложений немалым преимуществом перед решениями на основе TP-мониторов будет способность WAS 3.0 поддерживать транзакции для клиентов с обычными браузерами (не требуются специальные расширения или интерпретатор Java для браузера), при этом используется стандартный HTTP. Такой подход ускоряет обработку транзакций - не приходится тратить время на загрузку транзакционного апплета клиентом. Кроме того, возможно очень эффективно распределять нагрузку на сервере, посылая запросы любому доступному экземпляру картриджа, - транзакции контролируются в СУБД, а не в картриджах.

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

Протокол взаимодействия картриджей (ICХ, Inter-Cartridge eXchange). ICX позволяет одному картриджу обратиться непосредственно к другому с пересылкой результатов клиенту или возвращением управления вызывающему картриджу для дальнейшей обработки. Что это дает разработчику? С учетом того, что механизм ICX предусматривает указание идентификатора транзакции при вызове, появляется возможность в рамках одной транзакции нескольким картриджам работать с базой данных. Картридж, принимающий ICX-запрос, не отличает его от HTTP-запроса и обрабатывает как обычно. Таким образом появляется возможность разрабатывать специализированные картриджи, которые не предназначены для вызова самим клиентом.

***

Основные характерные черты рассмотренных Web-серверов корпорации Oracle - изоляция процессов, объектная архитектура, возможность добавления своих модулей расширения функциональности. Эти серверы лучше всего подойдут для построения Web-узлов в организациях, уже использующих СУБД Oracle. Скорость генерации динамических HTML-документов при помощи хранимых в базе PL/SQL процедур действительно впечатляет. Третью версию Web-сервера можно назвать "лекарством от перегрузок" - за счет реализованной балансировки загрузки в распределенной среде. Кроме того, OWS 3.0 - это мощный инструмент для реализации Web-приложений с поддержкой транзакций.

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

Проблема обеспечения доступа к различным типам БД может быть решена для поддерживающих Open/XA баз данных путем установки WAS 3.0, но если, кроме этого, требуется написание достаточно сложной клиентской и серверной частей Web-приложения, то можно прибегнуть к технологии Java и задействовать доступ к БД из апплетов через "чистые" JDBC-драйверы, которые уже появились на рынке. Судя по темпам развития технологий доступа к базам данных из Web-приложений, в недалеком будущем в этой области появятся и другие интересные решения.

Сергей Шестаков  -- "Промышленно-строительный банк", (С.-Петербург).