в каталоге 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 в