|
Задача распределенного хранения заключается не только в
«распылении» данных по узлам компьютерной сети, но, прежде всего, в обеспечении их целостности и доступности. Не будет особой пользы от того, что «А» хранится здесь, а «Б» — на другом конце земного шара. А вот если требуемые нам данные извлекаются быстро из ближайшего к нам источника и при этом всегда поддерживаются в актуальном состоянии независимо от удаленности от первичного источника информации — это совсем другое дело.
База данных— это модель некоторой предметной области, включающая в себя факты и логические отношения между ними.С точки зрения формальной логики процесс работы с базой данных — это процесс доказательства или опровержения теорем, некоторой теории, аксиомами которой являются факты {записи) базы данных, а правила вывода соответствуют классической логике высказываний или логике предикатов первого порядка.
Рис. 1.1. Структура объектов сетевого приложения
Наибольшая концентрация объектов наблюдается в оперативной памяти сервера баз данных.
Давайте посмотрим на типовые архитектуры построения современных сетевых приложений, использующих в качестве основного источника информации сетевые базы данных
В схеме приложение выполняется на компьютере пользователя и взаимодействует посредством компьютерной сети с сервером баз данных. Это наиболее простая схема организации сетевого приложения, где на сеть ложится нагрузка по передаче информации между приложением и базой данных.
Рис. 1.2.Структура объектов реляционной базы данных
Рис. 1.3. Простая схема организации сетевого приложения
На схеме, показанной на рис. 1.4, мы наблюдаем декомпозицию задачи на три независимых процесса:
представление информации — реализуется программными средствами сетевого приложения, выполняемыми на компьютере клиента;
обработка информации— реализуется программным обеспечением сервера приложения;
хранение информации — реализуется сервером базы данных.
Рис. 1.4. Три независимых процесса в сетевом приложении
Главными преимуществами такой архитектуры приложения являются: независимая эволюция каждого компонента, которая может
происходить в разное время с различной скоростью;
повышение производительности за счет специализации и оптимизации каждого вычислительного устройства на решении узкой, относительно самостоятельной задачи;
неограниченное наращивание возможностей за счет использования типовых элементов и правил их взаимодействия.
Пример наращивания возможностей сетевого приложения, использующего сетевые базы данных, показан на рис. 1.5.
Отличие представленной на рис. 1.6 архитектуры от предыдущей заключается в разделении задачи представления информации между клиентом сетевого приложения иWeb-сервером. Это позволяет отказаться от необходимости устанавливать на клиенте компьютера дополнительное программное обеспечение, предназначенное для организации взаимодействия с сервером приложения.
Вместо этого используется унифицированный клиент на базе обозревателя 1пгете1 и стандартный протокол HTTP. Web-сервер переводит зависящие от приложения элементы представления информации на язык стандартных примитивов, описываемых языком HTML, на смену которому в последнее время приходит более современный и удобный стандарт XML. Web-сервер выполняет «отрисовку» электронного документа, который можно сохранить на носителе пользователя, вывести на печать или отправить
по электронной почте. В то же время Web-сервер унифицирует процедуру взаимодействия пользователя через интерфейс форм, позволяющих структурировать запрос пользователя к информационной системе.
Рис. 1.5. Наращивание возможностей сетевого приложения
Рис. 1.6. Разделение задачи представления информации между клиентом сетевого приложения и Web-сервером.
Задачу сопряжения интерфейса сетевого приложения и интерфейса унифицированного клиента выполняют Web-приложения. Это сценарии, оперирующие объектами и выполняющие отображение множества параметров сетевого приложения на множество элементов управления унифицированного клиента.
Но даже такой гибкой архитектуры оказалось недостаточно для удовлетворения потребности в удобной и эффективной разработке сетевых приложений любой сложности.
Поэтому в настоящий момент используется более сложная схема, показанная на рис. 1.7.
Рис. 1.7. Архитектура сетевого приложения с сервером-брокером.
В архитектуру добавлен сервер-брокер, задача которого — поиск необходимых для работы сетевого приложения объектов на одном или более серверах приложений. Введение этого компонента повышает эффективность работы сетевого приложения, упрощает «сборку» объектов приложения, поскольку теперь нет необходимости учитывать топологию серверов приложений, местонахождение отдельных объектов, требуемых для решения задачи. Мы просто сообщаем серверу-брокеру, что нам нужно, а он, в свою очередь, основываясь на оперативной информации о доступных ему ресурсах, выбирает оптимальный путь решения нашей проблемы. Теперь объекты сетевых приложений могут свободно мигрировать между серверами для достижения наибольшей производительности, и это никак не скажется на работе сетевых приложений, поскольку в функции сервера-брокера входит отслеживание всех изменений в размещении компонентов приложения.
Все рассмотренные схемы успешно сосуществуют в мире современных сетевых приложений.
Do'stlaringiz bilan baham: |
