В числе достоинств клиента форм:
Общность. Нет необходимости каждый раз разрабатывать отдельный Java-апплет для каждого приложения, которое Вы хотите поместить в Web.
Динамичность. Клиент форм динамически реагирует на текущую форму, запрашивая и отображая только ту информацию и элементы пользовательского интерфейса, которые необходимы для передачи состояния приложения в конкретный момент времени.
Богатый набор интерфейсных элементов. Клиент форм поддерживает все элементы интерфейса пользователя, доступные в клиент/серверной реализации. Благодаря стандартизированным Java-объектам, вид и поведение интерфейсных элементов формы в Web практически не отличается от их в клиент/серверной реализации.
Динамическая загрузка. После запуска на клиентскую машину загружаются только те Java-классы, которые необходимы для отображения начального состояния приложения. Для поддержки дополнительной функциональности пользовательского интерфейса, необходимые классы могут подгружаться динамически, по мере надобности.
Сервер форм (Forms Server) состоит из двух компонент:
Слушатель (Listener). Слушатель сервера форм инициирует сессию сервера форм и обеспечивает связь между клиентом форм и обработчиком времени исполнения сервера форм.
Обработчик (Модуль) времени исполнения (Forms Runtime Engine). Обработчик времени исполнения форм представляет собой модифицированную версию обработчика времени исполнения для клиент/серверной реализации с функциональностью интерфейса пользователя, перенаправленной на клиента форм. Обработчик времени исполнения реализует всю функциональность формы, за исключением взаимодействия интерфейса пользователя; в его задачу входит обработка триггеров и транзакций, управление записями и общее взаимодействие с базой данных.
Как только устанавливается прямая связь по сети между клиентом форм и сервером форм, между ними начинается обмен сжатыми сообщениями в виде серий запросов и ответов.
Запросы клиента форм представляют собой события (такие как ⌠нажать кнопку■ или ⌠отобразить элемент■). Ответы сервера форм √ это инструкции по изменению пользовательского интерфейса (такие как изменение значения элемента или добавление/удаление объекта), которые клиент форм преобразует в изображение объектов. Например, если клиент форм получает ответ от сервера форм ⌠создать текстовый элемент зеленого цвета в канве Canva1■, то клиент форм транслирует ответ в изображение реальных интерфейсных объектов (в нашем случае цветной текстовый элемент).
Клиент форм запрашивает сервер форм, когда пользователь выполняет:
высокоуровневые операции (такие как подтверждение или отмена диалога);
операции (такие как отметка элементов типа checkbox или перемещение между полями), инициирующие проверку содержимого элементов, подстановку значений по умолчанию и обработку триггеров, определенных пользователем.
Для запуска приложения Oracle через Web, конечный пользователь должен, используя Java-совместимый Web-обозреватель, вызвать URL (Uniform Resource Locator) приложения. После этого порождается следующая цепочка:
URL соответствует HTML-странице (Hypertext Markup Language), содержащей ссылку на апплет клиента форм и параметры его запуска.
HTML страница, а затем и апплет клиента форм загружаются с сервера приложений в обозреватель клиента.
Клиент форм посылает запрос слушателю сервера форм (который запущен на определенном порту машины, с которой загрузился клиент форм).
Слушатель связывается с обработчиком времени исполнения сервера форм и подключается к процессу сервера форм (стартует новый процесс, либо подключается к уже существующему). Если в HTML странице указаны параметры командной строки запуска формы (такие как имя формы, идентификатор и пароль пользователя, SID базы данных, название меню и т.д.) и другие определенные пользователем параметры, то они передаются процессу через Слушатель.
Слушатель обеспечивает прямой канал с обработчиком времени исполнения и посылает информацию о канале клиенту форм. Клиент форм затем устанавливает прямое соединение с обработчиком времени исполнения. В дальнейшем клиент форм и обработчик времени исполнения ⌠общаются■ напрямую, разгружая тем самым Слушатель для принятия стартовых запросов других пользователей. Клиент форм отображает интерфейс пользователя приложения в окне апплета (не в основном окне Web-обозревателя пользователя).
Также как и в клиент/серверной реализации, Обработчик времени исполнения напрямую связывается с базой данных через 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 файле для обеспечения доступа к нему пользователям. В случае если указано только имя файла (без специфицирования пути), то Модуль Времени Исполнения сервера форм ищет файл в двух местах (в порядке перечисления):