Быстрый поиск

Дипломная работа: Использование Internet/intranet технологий для организации доступа к базам данных

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

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

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

получив заполненную форму, сервер запускает соответствующую внешнюю программу, передавая ей параметры и получая результаты на основе протокола 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). Далее необходимо набрать

<ORACLE_HOME>\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.

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

Назначение	Пример Физических Каталогов	Пример Виртуальных Каталогов
Applet codebase	c:\orant\forms50\java\	/web_code/
HTML файлы	c:\web_forms\html\	/web_html/
JAR-файлы	c:\orant\forms50\java\	/web_jars/

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 информационных потока:

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

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

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

Командная строка.

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

Ниже приводится значение некоторых переменных, объявленных в стандарте CGI:

CONTENT_LENGTH - значение этой переменной соответствует длине стандартного входного потока в символах;

QUERY_STRING - значение этой переменной соответствует строке символов следующей за знаком "?" в URL соответствующему данному запросу. Эта информация не декодируется сервером.

2. Стандартный вывод

CGI - модуль выводит информацию в стандартный выходной поток. Этот вывод может представлять собой или документ, сгенерированный cgi-модулем, или инструкцию серверу, где получить необходимый документ. Обычно cgi-модуль производит свой вывод. Преимущество такого подхода в том, что cgi-модуль не должен формировать полный HTTP заголовок на каждый запрос.

Вывод cgi-модуля должен начинаться с заголовка содержащего определенные строки и завершаться двумя символами CR (0x10). Любые строки не являющиеся директивами сервера, посылаются непосредственно клиенту. На данный момент, CGI спецификация определяет три директивы сервера:

Content-type

MIME или тип возвращаемого документа. Например:

Content-type: text/html <CR><CR>

сообщает серверу, что следующие за этим сообщением данные - есть документ в формате HTML;

Location

указывает серверу, что возвращается не сам документ, а ссылка на него. Если аргументом является URL, то сервер передаст указание клиенту на перенаправление запроса. Если аргумент представляет собой виртуальный путь, сервер вернет клиенту заданный этим путем документ, как если бы клиент запрашивал этот документ непосредственно.

Status

задает серверу HTTP/1.0 строку-статус, которая будет послана клиенту в формате: nnn xxxxx

где: nnn - 3-х цифровой код статуса

ххххх - строка причины

Например: HTTP/1.0 200 OK

Server: NCSA/1.0a6

Content-type: text/plain

<динамически генерируемый текст сообщения3. Стандартный входной поток

В случае метода запроса POST данные передаются как содержимое HTTP запроса и будут посланы в стандартный входной поток. Данные передаются cgi-модулю в следующей форме:

name=value&name1=value1&...&nameN=valueN

где name - имя переменной,

value - значение переменной,

N - количество переменных

На файловый дескриптор стандартного потока ввода посылается CONTENT_LENGTH байт. Так же сервер передает cgi-модулю CONTENT_TYPE (тип данных). Сервер не посылает символ конца файла после передачи CONTENT_LENGTH байт данных или после того, как cgi-модуль их прочитает. Переменные окружения CONTENT_LENGTH и CONTENT_TYPE устанавливаются в тот момент, когда сервер выполняет cgi-модуль. Таким образом, если в результате исполнения формы с аргументом тега FORM - METHOD="POST" сформирована строка данных firm=МММ&price=100023, то сервер установит значение CONTENT_LENGTH равным 21 и CONTENT_TYPE в

application/x-www-form-urlencoded, а в стандартный поток ввода посылается блок данных.

В случае метода GET, строка данных передается как часть URL.

Например

http://host/cgi-bin/script?name1=value1&name2=value2

В этом случае переменная окружения QUERY_STRING принимает значение

name1=value1&name2=value2

4. Аргументы командной строки

СGI-модуль в командной строке от сервера получает:

остаток URL после имени cgi-модуля в качестве первого параметра (первый параметр будет пуст, если присутствовало только имя cgi-модуля);

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

Ключевые слова, имена и значения полей формы передаются декодированными (из HTTP-URL формата кодирования) и перекодированными в соответствии с правилами кодирования Bourne shell [12] так, что cgi-модуль в командной строке получит информацию без необходимости осуществлять дополнительные преобразования (рассматривается реализация на Unix-платформе).

Исходя из разницы методов запросов GET и POST, можно определить последовательность действий для обработки входных данных cgi-модуля для разных типов запросов.

I. Для метода GET

Получить значение переменной QUERY_STRING;

Декодировать имена и их значения (учитывая, что все пробелы при декодировании сервером были заменены символом "+" и все символы с десятичным кодом больше 128 преобразованы в символ "%" и следующим за ним шестнадцатеричным кодом символа.);

Сформировать структуру соответствия "имя - значение" для дальнейшего использования в cgi-модуле.

II. Для метода POST

Получить из стандартного входного потока CONTENT_LENGTH символов;

Страницы: 1, 2, 3