Распределённые базы данных (стр. 6 из 7)

Любая информационная система, построенная на основе клиент-серверных Интернет технологий, должна содержать следующие серверные компоненты:

шлюз-сервер, управляющий правами доступа к информационной системе;

WWW-сервер;

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

сервер приложений и(или) сервер обработки транзакций.

Взаимодействие WWW сервера с базами данных может быть организовано двумя способами:

через сервер транзакций (см. рис.11);

через API интерфейс WWW сервера или сервера приложений (см. рис.12,13).

Использование коммерческих серверов транзакций, подразумевает организацию более менее стандартного интерфейса, а использование API приложений дает полную волю разработчикам

Рис 11. Взаимодействие с БД с использованием сервера транзакций

Организация взаимодействия с базами данных, использованием API, возможна по одной из приведенных на рис.12,13 схеме.

На рис.3 представлена стандартная схема формирования информационной системы, основанная как на использовании активных программ на сервере и стандартных средств доступа к БД как, например, Windows-NT ODBC интерфейс доступа к БД со стороны сервера и JDBC Java интерфейс доступа к БД со стороны клиента.

Рис 12. Использование API интерфейса WWW сервера

Схема, изображенная на рис.4, соответствует информационной системе использующей сервер приложений.

Рис 13. Использование сервера приложений и API интерфейса WWW сервера

В случае размещения базы данных на разных машинах, находящихся в различных локальных сетях, необходимо строить доверительные базы с обязательным применением шлюзов для обеспечения прав доступа (см. рис.14 ).

Рис 14. Организация доверительных БД -- работа через машину-посредник (шлюз)

Заключение

В основе любых технологических потрясений лежит простой экономический расчет: выгодно - невыгодно. В основе нынешней ситуации в развитии распределенных систем также лежит экономическое обоснование - стоимость передачи данных по сети становится меньше стоимости вычислений на клиентской машине и эта тенденция имеет устойчивый характер. Взрывной рост Internet, который многие связывают с "демократическими свободами" или развитием новой технологии имеет в своей основе все тоже простое экономическое обоснование - эта технология экономически выгодна. Отсюда проистекают и те изменения в мире технологий свидетелями которых мы являемся: стремительный рост пропускной способности каналов (Internet - 2, новые более быстрые модемы, спутниковые каналы для домашнего пользователя ), присутствие в сети большинства корпораций и масс медиа, электронная коммерция и банки … На основе этих технологий выросли новые направления бизнеса, а распространенность Internet растет темпами невиданными в отрасли (быстрее телефонии и телевидения).

Однако, если присмотреться поближе к этой технологии, то в ней нет ничего революционного, за исключением того, как уже известные решения применены в новой области. Давно известны языки разметки (TeX), протоколы передачи данных (TCP) и удаленных сервисов (NSF, POP), распределенные транзакции (мониторы транзакций), платформопереносимые языки (С, Perl) и т.д.

Весь секрет новых решений в заложенной изначально совместимости, опирающейся на открытые стандарты. Именно поэтому основная битва идет вокруг стандартов, чтобы не декларировали "участники забега". Решения, основанные на стандарте, являются экономически выгодными, т.к. гарантируют возврат инвестиций чтобы не происходило на рынке.

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

Создание реальных прикладных систем на основе Internet технологии, в свою очередь, катализировало изменения в самой технологии. Впервые ставится под вопрос необходимость священной коровы - Операционной Системы. Чрезвычайно фетишизированная усилиями Microsoft ОС, тем не менее, всего лишь служебная функция необходимая для выполнения реальных приложений (недаром Sun и Oracle заключили кросслицензионное соглашение, позволяющее встраивать функции ОС в СУБД и СУБД в ОС).

Значительно пересмотрены и другие концепции, казавшиеся незыблемыми. К примеру, технология клиент - сервер построена на обращении клиента к серверу по частному протоколу (SQL Net в случае). Находящийся на стороне сервера listener обеспечивает соединение и обработку запроса. Возникает вопрос - а почему к СУБД можно обращаться только по одному специальному протоколу? Ведь при построении приложения в Internet приходится несколько раз проводить преобразование протоколов http в SGI (Perl, сервлеты и т.п.) и затем в SQL. Когда можно просто поручить listener'у иметь возможность обрабатывать запросы по http, POP3, IMAP4, NFS и другим. Подобная концепция реализованная в Oracle8i позволяет реально превратить реляционную СУБД в хранилище информации в Internet. Подобные решения кардинальным образом переворачивают наши представления о правильно построенной информационной системе, но это неизбежная дань за участие в очередной технологической революции.

Подход корпорации Oracle основан на полном признании сложившихся стандартов и их интеграцию (тоже на основе стандартов). Для Oracle вопрос не ставится как "или" клиент-сервер "или" Web "или" распределенные объекты, решение Oracle являются объединением лучших черт технологий клиент-сервер (мощность, устойчивость, транзакции), Web (легкость распространения и управления, тонкий клиент) и распределенных объектов (компонентное программное обеспечение, интеграция решений от разных производителей и распределение задачи по всем компьютерам в сети). Такая интеграция возможна на основе стандартов CORBA 2.0 (Архитектура Диспетчера Объектных Запросов) , HTTP/HTML, IIOP (Internet Inter Object Protocol), COM/DCOM (стандарт Microsoft) и Java.

В основе подхода Oracle лежит WRB (Диспетчер Объектных Запросов Web), связанный с Web сервером и управляющий всеми объектами в сети. Такие объекты могут располагаться на сервере приложений (любом сервере в сети), в базе данных (используя все возможности Базы Данных Oracle 7 и особенно объектные расширения Oracle 8) или на клиентской части (браузере). При этом все объекты (картриджи) предоставляют Диспетчеру Объектных Запросов свой интерфейс и после этого могут вызывать друг друга, создавать новые экземпляры объектов и т.д. Управление объектами, их установка, секретность, регулировка загрузки серверов и др. возможности обеспечиваются WRB. Такая архитектура называется Архитектура Сетевых Вычислений.

Таким образом любое приложение используемое в Архитектуре Сетевых Вычислений становится независимым от языка программирования (Java, C/C++, SQL, Visual Basic и др.), независимым от типа архитектуры (клиент-сервер, web) и может быть легко интегрировано с любым другим приложением (картриджем), даже разработанным другим производителем.

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

Имея в своем арсенале Web сервер с функциональностью недостижимой при других подходах Oracle также предлагает средства разработки приложений уровня предприятия. Это Designer/2000 - лучшее на сегодня CASE решение, которое теперь имеет генератор не только для клиент-сервер, но и для Web, Developer/2000 - мощное средство разработки приложений, устанавливаемое как картридж на сервере приложений (под управлением WRB) и автоматически генерящее полный набор Java апплетов для работы на браузере, Sedona - мощное объектно-ориентированное средство для создания и управления распределенными объектами.

Система, построенная по технологии распределенных объектов, состоит из набора компонент (объектов), взаимодействующих друг с другом. При этом объекты, как правило, разбросаны по сети и выполняются отдельно друг от друга.

Рисунок 1: Модель распределенных объектов

DCOM и CORBA основываются на коммуникации типа клиент-сервер. Запрашивая сервис, клиент вызывает метод, реализуемый удаленным объектом, действующим в роли сервера. Сервис, предоставляемый объектом, инкапсулируется с помощью интерфейса, определенного на языке IDL. Именно собственный язык IDL является одной из изюминок CORBA. Вообще, существуют три различных языка описаний под одним и тем же названием: OMG IDL (очевидно, используется в CORBA), Microsoft IDL (разработан для технологии DCOM, но в силу двоичного представления объектов не играет в этой технологии ключевой роли) и OSF IDL. Однако, по сравнению с DCOM, CORBA имеет ряд существенных отличий.

Технология CORBA изначально проектировалась для создания распределенных систем. В силу этого сервер объектов и клиентские программы, в отличие от COM/DCOM, в технологии CORBA, как правило, располагаются на разных машинах. Взаимодействие между клиентом и сервером происходит следующим образом. В процессе клиента имеется объект-посредник, именуемый stub (или Client-Side Stab). Он является полномочным представителем сервера и исполняет функции, во многом сходные с функциями объекта Proxy в технологии DCOM. Именно к stub при помощи интерфейса объекта обращается программа-клиент так, как будто stub и являет собой объект. Далее stub перенаправляет запрос клиента к особому объекту, который действует также на машине клиента. Этот объект называется ORB (Object Required Broker, брокер объектных запросов). Получив запрос, ORB формирует широковещательное сообщение во внешнюю сеть. На это сообщение откликается один из объектов Smart Agent, который функционирует на одном из компьютеров сетевого окружения (локальная сеть или Интернет). Smart Agent знает, где расположены соответствующие серверы объектов (фактически это как бы виртуальный сетевой каталог, где зарегистрированы некоторые серверы), и перенаправляет запрос на нужный сервер. На сервере пакет запроса принимает еще один объект ORB, который дешифрует запрос и пересылает его следующему объекту — BOA (Basic Object Adapter, базовый адаптер объектов). Роль объекта BOA заключается в фильтрации, кэшировании запросов и, соответственно, разграничении доступа к объекту сервера. Если запрос пропущен BOA, то он попадает в объект сервера skeleton. При этом в адресном пространстве сервера создается требуемый объект, skeleton помещает аргументы вызова в стек объекта и реализует собственно вызов. Используя объект BOA, skeleton также регистрирует созданный серверный CORBA-объект с помощью Smart Agent, а также сообщает о доступности, факте создания и о готовности объекта принимать запросы клиента. Далее следует обратная связь по описанной цепочке объектов