8515-1 (Использование Internet/intranet технологий для организации доступа к базам данных), страница 2

Также как и в клиент/серверной реализации, Обработчик времени исполнения напрямую связывается с базой данных через SQL*Net (или другой драйвер для связи с источниками данных не Oracle).

Данные, проходящие между базой данных, сервером форм и клиентом форм автоматически шифруются перед посылкой и дешифруются после приема согласно протоколам RSA RC4 40-битное шифрование (для передачи между клиентом форм и сервером форм) и SQL*Net SNS/ANO (для передачи между сервером форм и сервером баз данных) [13].

2.2.2 Технология с использованием интерфейса CGI

В качестве более распространенного варианта разработки Web-ориентировных интерфейсов к базам данных выступает механизм CGI (Common Gateway Interface √ Общий Интерфейс Шлюзования). Система строится с использованием трехзвенной архитектуры, составляющими которой являются:

Web-сервер (сервер приложений) √ программно-аппаратный комплекс, который дает возможность пользователям сети получать доступ к гипертекстовым документам, расположенным на данном сервере;

Сервер баз данных;

Web-обозреватель клиента.

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

Если рассматривать технологию CGI применительно к организации интерфейса к базам данных, то CGI-скрипт должен, обработав запрос пользователя, передать его серверу баз данных и затем на основе результата сформировать HTML-документ, который и увидит пользователь (Рис. 4).

Таким образом, общая схема реализации доступа к базе данных выглядит следующим образом [4]:

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

клиент запрашивает эту страницу; помимо незаполненных форм страница содержит общую информацию о базе данных и о назначении предлагаемых форм;

клиент заполняет одну из форм и отправляет заполненную форму на сервер;

получив заполненную форму, сервер запускает соответствующую внешнюю программу, передавая ей параметры и получая результаты на основе протокола CGI;

внешняя программа преобразует запрос, выраженный с помощью заполненной формы, в запрос на языке, понятном серверу баз данных (в данном случае это язык SQL);

получив результат выполнения запроса к базе данных, CGI-скрипт формирует на его основе HTML-страницу и выводит ее на стандартный вывод;

Web-сервер передает HTML-страницу в клиентский обозреватель.

CGI-скрипт взаимодействует с базой данных Oracle по протоколу SQL* Net [7] √ сетевому протоколу Oracle. В задачи CGI-скрипта входит получение данных от пользователя, их обработка и формирование на их основе запроса к базе данных. После получения результата запроса CGI-скрипт создает HTML-страницу и передает ее Web-серверу. Web-сервер, в свою очередь, пересылает HTML-страницу клиенту, инициировавшему сеанс. Ввод данных клиентом осуществляется с помощью механизма HTML-форм.

3. Технология разработки Web-интерфейсов к базам данных

Как было описано в главе 2, архитектура приложений баз данных с WWW-интерфейсом базируется на трехзвенной архитектуре (Рис. 5), включающей:

Сервер баз данных;

Сервер приложений;

Клиентов.

Рассмотрим технологический цикл построения таких систем.

3.1 Технология Oracle Web-delpoyment доступа к базам данных на стороне сервера

Технологический цикл построения интерфейсов к базам данных сводится к формулировке задач, решаемых каждым звеном архитектуры и их настройке этих звеньев:

Сервер баз данных представляет самую массивную часть архитектуры. Находясь на этом уровне, необходимо создать собственно Базу Данных, то есть совокупность взаимосвязанных данных, хранимых в ЭВМ [1]. Проектирование базы данных включает инфологическое проектирование (определение предметной области системы и др.), логическое проектирование (создание схемы базы данных) и физическое проектирование (отображение ⌠логической■ структуры в структуру хранения и др.) [1].

Сервер приложений; Настройка сервера приложений включает следующие этапы:

создание и помещение FMX-файла на сервер приложений;

запуск Слушателя сервера форм;

обеспечение конечным пользователям доступа к приложению;

настройка клиента форм.

создание и помещение FMX-файла на сервер приложений

На этом этапе необходимо создать форму (формы) приложения в формате FMB-файла и сгенерировать исполняемый FMX-файл. Это связано с тем, что Oracle генерирует приложения в псевдокоде (файлы с расширением FMX), запуск которых возможен посредством Forms Runtime √ небольшого пакета, устанавливаемого на клиентскую машину. Генерация FMX-файлов должна производится на той же платформе, на которой установлен сервер приложений.

Сгенерированный FMX-файл можно поместить в любой каталог сервера приложений √ главное, чтобы на него была корректная ссылка в HTML файле для обеспечения доступа к нему пользователям. В случае если указано только имя файла (без специфицирования пути), то Модуль Времени Исполнения сервера форм ищет файл в двух местах (в порядке перечисления):

в каталоге ORACLE_HOME\BIN\;

в каталоге FORMS50_PATH (если переменная среды установлена),

где ORACLE_HOME и FORMS50_PATH √ переменные среды операционной системы.

2. запуск Слушателя сервера форм

Для запуска Слушателя сервера форм необходимо выбрать пункт Start->Run на панели задач Windows NT (описывается реализация для платформы Windows NT 4.0). Далее необходимо набрать

\bin\f50srv32 port=номер_порта и нажать Enter.

После этого будет запущен процесс слушателя на указанном порту. При опускании номера порта, процесс стартует, используя по умолчанию порт 9000. Этот номер должен совпадать с номером порта, который указывается в HTML файле (см. п.3 обеспечение конечным пользователям доступа к приложению).

Для проверки состояния запущенного сервера форм можно посмотреть вкладку Processes в окне Менеджера задач NT. Если прослушивающий процесс запущен, то будет присутствовать процесс с именем F50SRV32.EXE, а также несколько процессов F50WEB32.EXE (один для каждого активного соединения).

Для остановки Слушателя сервера форм необходимо выбрать пункт End Process в окне Менеджера задач NT.

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

3.1. создание виртуальных каталогов на Web-сервере

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

Ниже разъясняется семантика создаваемых виртуальных каталогов:

Applet codebase (является тэгом, т.е. ключевым словом HTML, в описании апплета). Указывает на основной URL апплета - задает каталог, содержащий код апплета (Java-классы).

ORACLE_HOME\forms50\java (например, c:\orant\forms50\java).

Нельзя устанавливать этот виртуальный каталог на /ORACLE/.

HTML файлы. Указывает на каталог, где Web-сервер будет искать HTML файлы приложения.

JAR-файлы. Указывает на физический каталог, где находятся JAR-файлы (Java Archives) Oracle.

Пример настройки виртуальных каталогов:

3.2. выбор метода создания HTML файла (динамический или статический)

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

Динамически. HTML файл динамически создается обработчиком картриджей форм. Этот метод требует установки Oracle Web Server в качестве сервера Приложений. В описываемой работе использовался и будет описываться другой метод √ статический.

Статически. Требует создания HTML файла, содержащего всю необходимую информацию для приложения. В качестве сервера приложений может использоваться любой Web-сервер. Дистрибутив Oracle Developer/2000 R2.0 содержит пример статического файла √ static.htm. При разработке приложения необходимо модифицировать этот файл, указав соответствующие значения тэгов апплета, такие как имя файла формы (.FMX) и др. После создания файла, необходимо поместить его в физический каталог, связанный с виртуальным каталогом, определенным для HTML файлов (см. п. 3.1).

3.3. обеспечение доступа к приложению Web через URL

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

http://gemini.math.cgu.chel.su/web_html/bibliogr.htm

Расшифровка URL: Протокол: http

Домен: gemini.csu.ac.ru

Виртуальный каталог

для HTML файлов: /web_html

Статический HTML файл: bibliogr.htm

4. настройка клиента форм

Когда конечный пользователь запускает Web приложение Oracle, с сервера приложений в его обозреватель загружается клиент форм (и файлы родственных Java-классов). В процессе работы пользователя с приложением, по мере необходимости могут подгружаться файлы дополнительные Java-классы. Существует возможность управления тем, как файлы классов будут загружаться в обозреватель пользователя. Есть два метода загрузки:

Инкрементная (Increment). Является настройкой по умолчанию и обеспечивает загрузку только тех файлов с Java-классами, которые необходимы для отображения начального состояния приложения.

Архивная (Bundled). В момент запуска приложения, на клиентскую машину загружаются один или несколько архивов с Java-классами. Преимущество архивов в том, что каждый архив загружается за одну сетевую транзакцию. Для использования этого варианта необходимо указать имена соответствующих JAR-файлов в HTML файле приложения.

Клиенты. Клиентская часть системы практически не требует настройки, так как базируется на ⌠тонком клиенте■ - Java-совместимом Web-обозревателе. Необходимо использовать обозреватель, имеющий поддержку JDK (Java Development Kit √ стандарт Java) версии 1.1.x или выше.

3.2 Технология доступа к базам данных на стороне сервера с использованием механизма CGI

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

Для реализации взаимодействия "клиент-сервер" важно, какой метод HTTP запроса использует клиентская часть при обращении к WWW серверу. В общем случае, запрос - это сообщение, посылаемое клиентом серверу. Первая строка HTTP запроса включает в себя метод, который должен быть применен к запрашиваемому ресурсу, идентификатор ресурса (URI - Uniform Resource Identifier), и используемую версию HTTP-протокола. Применительно к CGI, клиентская часть использует методы запроса POST и GET. Метод POST применяется для запроса серверу, чтобы тот принял информацию, включенную в запрос, как относящуюся к ресурсу, указанному идентификатором ресурса. Метод GET используется для получения любой информации, идентифицированной идентификатором ресурса в HTTP запросе.

Согласно спецификации, CGI определяет 4 информационных потока:

Переменные окружения;

Стандартный выходной поток;