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

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

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

Министерство общего и профессионального образования РФ

Дипломная работа

Исполнитель Апанасенко Е.В.

Челябинский государственный университет

Факультет математический

1. Введение

Базы данных настолько тесно вошли в нашу жизнь, что без их помощи не мыслится деятельность ни одной организации. С появлением локальных сетей, подключением таких сетей к Internet, созданием внутрикорпоративных сетей на базе intranet, появляется возможность с любого рабочего места организации получить доступ к информационному ресурсу сети, такому как база данных. Однако, при попытке использовать существующие базы данных возникают проблемы связанные с требованием однородности рабочих мест (для запуска "родных" интерфейсов), большим трафиком в сети (доступ идет напрямую к файлам базы данных), загрузкой файлового сервера и невозможностью удаленной работы (например, командированных сотрудников). Так, для каждой используемой базы данных необходим свой специфический клиент, такой как модуль времени исполнения или исполняемый файл, реализующий функциональность клиента. Клиентский компьютер должен быть достаточно мощным, для того чтобы справиться с обработкой функциональности клиента. Решением проблемы является использование унифицированного интерфейса WWW для доступа к информационным ресурсам организации [4].

Среди преимуществ такого подхода возможность доступа к базе данных посредством так называемого ⌠тонкого клиента■ - компьютера с установленной на нем стандартной программой-обозревателем Internet (Netscape Communicator, Microsoft Internet Explorer, и т.п.) вместо использования специфических программ-клиентов;

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

мобильность клиента: в качестве клиента может использоваться любой компьютер, под управлением любой ОС, имеющий обозреватель Internet;

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

В данной дипломной работе делается попытка проанализировать существующие технологии организации Web-ориентированных интерфейсов к базам данных и разработать такого рода систему, взяв в качестве прототипа реально существующую базу данных ⌠Библиографический каталог■, функционирующую в среде Microsoft Access [2].

Постановка задачи. Провести анализ имеющихся технологий разработки Web-ориентированных интерфейсов к базам данных и разработать справочно-библиографическую систему с WWW-интерфейсом, реализующую алфавитный и систематический каталоги публикаций на базе СУБД Oracle [7].

Для этой цели решались следующие задачи:

разработать структуру базы данных;

реализовать два варианта архитектуры WWW-интерфейса к базе данных и провести их сравнение;

разработать технологию импорта данных из формата СУБД MS Access в формат СУБД Oracle.

2. Две архитектуры систем доступа к базам данных через Web

В традиционной архитектуре клиент/сервер [1] действует принцип разделения задач, когда используется более чем один компьютер, и каждый из них выполняет строго определенные ему задачи. Такой подход уменьшает загрузку каждого узла системы, позволяя ему сконцентрироваться на выполнении ⌠своих■ задач и, следовательно, увеличивает производительность и возможности системы в целом.

В СУБД Oracle система баз данных разделена на две части: клиентскую часть и серверную часть [7] (Рис. 1).

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

Серверная часть, работающая на программном обеспечении Oracle, обслуживает задачи, необходимые для параллельного общего доступа к данным. Серверная часть принимает и обрабатывает SQL и PL/SQL запросы, посылаемые клиентскими приложениями [13]. Компьютер, обслуживающий серверную часть, должен быть оптимизирован для решения своих специфических задач √ он должен иметь большую дисковую память и быстрый процессор [8].

Связь между сервером и клиентом осуществляется посредством SQL*Net √ сетевого интерфейса Oracle [9]. SQL*Net позволяет программам Oracle, запущенным на сетевых клиентских рабочих станциях и серверах, организовать доступ, модификацию, разделение и хранение данных на других серверах.

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

2.1 Доступ к базе данных на стороне клиента

Доступ к базе данных на стороне клиента обеспечивает язык Java [10]. Java - это объектно-ориентированный язык программирования, являющийся, по сути дела, "безопасным" подмножеством языка Си++. В частности, Java не содержит средств адресной арифметики, не поддерживает механизм множественного наследования и т. д. Для языка Java существуют компиляторы в так называемый "мобильный код" (машинно-независимый код, который может интерпретироваться или из которого могут генерироваться машинные коды на разных платформах).

Технология разработки HTML-документа позволяет написать произвольное количество Java-программ, откомпилировать их в мобильные коды и поставить ссылки на соответствующие коды в теле HTML-документа. Такие дополнительные Java-программы называются апплетами (Java-applets). Получив доступ к документу, содержащему ссылки на апплеты, клиентская программа просмотра запрашивает у Web-сервера все мобильные коды. Коды могут начать выполняться сразу после размещения в компьютере клиента или быть активизированы с помощью специальных команд.

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

Для взаимодействия Java-апплета с внешним сервером баз данных разработан специализированный протокол JDBC, который, фактически, сочетает функции шлюзования между интерпретатором мобильных Java-кодов и ODBC, а также включает ODBC.

По сути дела, Web-интерфейс с доступом к базе данных на стороне клиента практически ничем не отличается от традиционной клиент/серверной архитектуры. Просто роль клиентского приложения здесь играет Java-апплет √ программа на псевдокоде, способная через Internet/intranet загрузиться и выполниться на вашем компьютере.

2.2 Доступ к базе данных на стороне сервера

Более интересной реализацией является механизм доступа к базе данных на стороне сервера. Существует два основных различия между работой приложения в клиент/серверной реализации Oracle и в Web реализации с доступом к базе данных на стороне сервера [6]:

Клиент/сервер (Рис. 1). Архитектура системы состоит из двух частей: Клиента и сервера баз данных. Модуль форм времени исполнения (и все прикладные функции) устанавливаются на настольные компьютеры пользователя. Хотя приложение теоретически может включать триггеры и прикладные функции на стороне сервера баз данных, на практике эта возможность используется редко, поэтому вся обработка интерфейса пользователя и триггеров, как правило, происходит на клиентских машинах [6].

Web (Рис. 2). Архитектура системы является трехзвенной и состоит из следующих частей: клиент(ы), сервер приложений, сервер баз данных. Все прикладные функции устанавливаются на сервере приложений, а не на клиентах. Вся обработка интерфейса пользователя выполняется клиентом, в то время как обработка триггеров происходит на сервере баз данных и сервере приложений.

2.2.1 Технология Oracle Web deployment

Модуль форм времени исполнения (Forms Runtime Engine) представляет собой программу, выполняющую формы приложения. В ее задачи входит запуск, отображение и обработка функциональности формы.

Сервер приложений (Application Server) представляет собой звено архитектуры, отвечающее за хранение и обработку прикладных функций приложения. Реализован в виде WWW-сервер. WWW сервер - это такая часть глобальной или внутрикорпоративной сети, которая дает возможность пользователям сети получать доступ к гипертекстовым документам, расположенным на данном сервере. Для взаимодействия с WWW сервером пользователь сети должен использовать специализированное программное обеспечение √ обозреватель Internet.

Клиент форм (Forms Client) реализован в виде Java-апплета, загружаемого в реальном времени в Web-обозреватель пользователя с сервера Приложений. Web-обозреватель, посредством экранных форм, отображает интерфейс пользователя и управляет взаимодействием конечного пользователя с сервером форм. Клиент форм принимает пакеты интерфейсных команд от сервера форм и транслирует их в интерфейсные объекты для конечного пользователя. Некоторые интерфейсные события (такие как ввод символов в текстовых полях или перемещение по элементам диалогового окна), которые в клиент/серверной реализации обрабатывались модулем времени исполнения сервера форм, в Web реализации обрабатываются клиентом форм без взаимодействия с сервером форм.

В числе достоинств клиента форм:

Общность. Нет необходимости каждый раз разрабатывать отдельный 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 файле для обеспечения доступа к нему пользователям. В случае если указано только имя файла (без специфицирования пути), то Модуль Времени Исполнения сервера форм ищет файл в двух местах (в порядке перечисления):

в каталоге ORACLE_HOMEBIN;

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

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

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

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

binf50srv32 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_HOMEforms50java (например, c:orantforms50java).

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

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

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

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

Назначение




2012 © Все права защищены
При использовании материалов активная ссылка на источник обязательна.