Эта модель
является расширением двухуровневой модели и в ней вводится дополнительный промежуточный
уровень между клиентом и сервером. Архитектура трехуровневой модели приведена
на рис. 10.7. Этот промежуточный уровень содержит один или несколько серверов
приложений.
Рис.
10.7. Модель сервера приложений
В этой модели
компоненты приложения делятся между тремя исполнителями:
Клиент обеспечивает
логику представления, включая графический пользовательский интерфейс, локальные
редакторы; клиент может запускать ло-кальный код приложения клиента, который
может содержать обращения к локальной БД, расположенной на компьютере-клиенте.
Клиент исполняет коммуникационные функции front-end части приложения, которые
обеспечивают доступ клиенту в локальную или глобальную сеть. Дополнительно
реализация взаимодействия между клиентом и сервером может включать в себя
управление распределенными транзакциями, что соответствует тем случаям, когда
клиент также является клиентом менеджера распределенных транзакций.
Серверы приложений
составляют новый промежуточный уровень архитектуры. Они спроектированы
как исполнения общих незагружаемых функций для клиентов. Серверы приложений
поддерживают функции клиентов как частей взаимодействующих рабочих групп,
поддерживают сетевую доменную операционную среду, хранят и исполняют наиболее
общие правила бизнес-логики, поддерживают каталоги с данными, обеспечивают
обмен сообщениями и поддержку запросов, особенно в распределенных транзакциях.
Серверы баз данных
в этой модели занимаются исключительно функциями СУБД: обеспечивают функции
создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают
функции хранилищ данных (warehouse services). Кроме того, на них возлагаются
функции создания резервных копий БД и восстановления БД после сбоев, управления
выполнением транзакций
и поддержки устаревших (унаследованных) приложений (legacy application).
Отметим,
что эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее
заметны преимущества модели сервера приложений в тех случаях, когда клиенты
выполняют сложные аналитические расчеты над базой данных, которые относятся
к области OLAP-прнложений. (On-line analytical processing.) В этой модели большая
часть бизнес-логики клиента изолирована от возможностей встроенного SQL, реализованного
в конкретной СУБД, и может быть выполнена на стандартных языках программирования,
таких как С, C++, SmallTalk, Cobol. Это повышает переносимость системы, ее масштабируемость.
Функции промежуточных
серверов могут быть в этой модели распределены в рамках глобальных транзакций
путем поддержки ХА-протокола (X/Open transaction interface protocol), который
поддерживается большинством поставщиков СУБД.
Знаете ли Вы, что электромагнитное и другие поля есть различные типы колебаний, деформаций и вариаций давления в эфире.
Понятие же "физического вакуума" в релятивистской квантовой теории поля подразумевает, что во-первых, он не имеет физической природы, в нем лишь виртуальные частицы у которых нет физической системы отсчета, это "фантомы", во-вторых, "физический вакуум" - это наинизшее состояние поля, "нуль-точка", что противоречит реальным фактам, так как, на самом деле, вся энергия материи содержится в эфире и нет иной энергии и иного носителя полей и вещества кроме самого эфира.
В отличие от лукавого понятия "физический вакуум", как бы совместимого с релятивизмом, понятие "эфир" подразумевает наличие базового уровня всей физической материи, имеющего как собственную систему отсчета (обнаруживаемую экспериментально, например, через фоновое космичекое излучение, - тепловое излучение самого эфира), так и являющимся носителем 100% энергии вселенной, а не "нуль-точкой" или "остаточными", "нулевыми колебаниями пространства". Подробнее читайте в FAQ по эфирной физике.