1.4. Архитектура с использованием сервера приложений (трехзвенная архитектура)
Классическая архитектура клиент-сервер, как мы рассмотрели выше, подразумевает, что есть две программы. Первая, сервер баз данных, следит за сохранностью данных, размещает их на внешнем носителе и исполняет приходящие запросы на поиск и обновление данных. Вторая программа, программа-клиент, обеспечивает интерфейс с пользователем, формирует запросы к серверу базы данных, отсылает их и получает нужные данные, которые, скорее всего, показывает пользователю. Программа-клиент и программа-сервер могут физически находиться как на одном компьютере, так и на разных.
Использование архитектуры клиент-сервер позволило ускорить доступ к данным (сервер не занимается интерфейсом и логикой приложений), строить гетерогенные сети (клиент и сервер общаются по сетевому протоколу, и могут функционировать на совершенно различных платформах). Но у архитектуры клиент-сервер есть и отрицательные стороны (ничто не бывает задаром!).
В последнее время стал возникать синдром "толстого клиента". Это означает, что клиентское приложение имеет размер, сравнимый или даже превышающий размер программы-сервера базы данных. Такое приложение зачастую требует от компьютера-клиента очень больших ресурсов. А клиентских мест в реальной информационной системе, как правило, достаточно много. Поэтому общие затраты на оборудование (память, диски) для компьютеров-клиентов могут быть неоправданно большими.
С другой стороны, программы-клиенты в одной информационной системе с большой вероятностью содержат повторяющиеся куски кода. Например, если используемая Вами информационная система учитывает налоги, то она должна считать сумму налога на всех клиентах одинаково. Таким образом, получаем, что один и тот же код многократно продублирован и на каждом из компьютеров-клиентов занимает некоторые, весьма ощутимые ресурсы.
При некоторых видах обработки информации, хранящейся в базе данных, требуется передавать по сети большие объемы информации. Например, в базе данных хранится информация о миллионе платежных поручений. Правительством было принято постановление о изменении налогов. Вам надо пересчитать налог на каждый документ. Если это реализовать на клиенте, то тогда по сети потребуется передать практически все данные и выигрыша архитектура клиент-сервер не даст (передача данных по сети одно из самых узких мест в информационных системах).
Решением для данной проблемы могло быть проведение обработки непосредственно на том же компьютере, где хранятся данные. Серверы баз данных Informix поддерживают механизм хранимых процедур. Хранимые процедуры принадлежат, хранятся и исполняются на сервере. Для их программирования используется специальный язык - язык хранимых процедур SPL. Во многих случаях проще бы было разрабатывать алгоритм обработки на том же языке, в той же системе программирования, что и всю клиентскую часть, но исполнять этот алгоритм не на машине- клиенте, а на машине, где находится сервер баз данных.
В некоторых системе разработки приложений, например в Informix-NewEra, есть средства создания сервера приложений. С помощью этих библиотек можно разбивать свое клиентское приложение на две части. Одна часть будет традиционным клиентом и находится на компьютере-клиенте, а вторая часть, сервер-приложений, находится на другом компьютере, возможно как раз на том, где расположен сервер базы данных. Таким образом, используя сервер приложений можно смягчить или свести на нет недостатки традиционной архитектру “клиент‑сервер”.
Итак, идея сервера приложений заключается в разбиении приложения на две части - собственно клиента и сервера данного приложения. Причем сервер приложений может быть один на много приложений. Клиенты общаются с сервером приложений (или с серверами приложений, никто не запрещает иметь несколько серверов приложений). Клиенты посылают серверу приложений запросы, а получают ответы. Клиенты могут обратиться и непосредственно к серверу базы данных за теми или иными данными. Обращение за данными к серверу базы данных может производить и сервер приложений.
Таким образом, имеем три типа взаимодействующих компонент - сервер базы данных, приложение (клиент) и сервер приложения. Они могут взаимодействовать друг с другом по следующей схеме:
Рис. 1.5. Многопользовательская информационная система на основе архитектуры c “клиент‑сервер” с сервером приложений.
Именно по причине наличия трех компонент (приложение, сервер приложения, сервер баз данных), подобная архитектура называется трехсвязной (английский термин three-tier architecture).
- 4.5. Упражнения 67
- Глава 6. Устройство Informix Dynamic Server 165
- Глава 7. Эксплуатация информационных систем 177
- Глава 1 Обзор основных архитектур баз данных
- 1.1. Архитектура на основе разделяемых файлов
- 1.2. Архитектура “Хост-терминал”
- 1.3. Архитектура “Клиент-Сервер”
- 1.4. Архитектура с использованием сервера приложений (трехзвенная архитектура)
- 1.5. Упражнения
- Глава 2 Модели данных
- 2.1. Уровни восприятия данных
- 2.2. Иерархическая модель данных
- 2.3. Сетевая модель данных
- 2.4. Реляционная модель данных
- 2.5. Объектно-реляционная модель данных
- Глава 3 Реализация информационных систем на основе продуктов Informix Software
- 3.1. Обзор продуктов Informix
- 3.2. Варианты построения систем
- Internet/Intranet-конфигурация
- 3.3. Выбор оптимальной конфигурации
- Глава 4 Математические основы реляционных субд
- 4.1. Основные понятия
- 4.2. Ключи
- 4.3. Основные операции над таблицами и их интерпретация
- 4.4. Нормализация
- 4.5. Упражнения
- Глава 5 Язык sql
- 5.1. Типы данных, доступные в sql
- 5.3. Основные sql-операторы для доступа и модификации данных
- 5.4. Управление транзакциями
- 5.5. Продвинутые варианты оператора поиска
- 5.5.1. Поиск по нескольким таблицам
- 5.5.2. Устранение повторения данных в операторе select
- 5.5.3. Вычисления внутри оператора select
- 5.5.4. Логические выражения в условии sql-операторов
- 5.5.5. Слияние двух выборок
- 5.5.6. Сортировка выборки
- 5.5.7. Вставка в таблицу нескольких строк одновременно
- 5.6. Использование sql в языках программирования
- 5.7. Программирование сервера базы данных
- 5.7.1. Динамический sql
- 5.7.3. Хранимые процедуры
- 5.7.4. Триггеры
- 5.8. Ограничители (задание целостности на уровне схемы)
- 5.9. Разграничение в sql прав пользователей
- 5.9.1. Права доступа
- 5.9.2. Права на уровне базы данных
- 5.9.3. Права на таблицы
- 5.9.4. Права на хранимые процедуры
- 5.9.5. Кто и как следит за соблюдением прав
- 5.9.6. Механизм ролей
- 5.9.7. Псевдотаблицы (view)
- 5.9.7. Синонимы
- 5.10. Управление одновременным доступом к данным
- 5.10.1. Что бывает, когда несколько человек одновременно пытаются обновить одни и теже данные
- 5.10.2. Открытие базы данных только для себя
- 5.10.3. Блокирование таблицы
- 5.10.4. Механизм блокирования записей и уровни изоляции
- 5.10.5. Управление ожиданием снятия блокировок
- 5.10.6. Тупиковые ситуации
- 5.11. Повышение скорости обработки запросов.
- 5.11.1. Индексы
- 5.11.2. Буферизация журнала транзакций
- 5.11.3. Блокировка на уровне записей и страниц
- 5.11.4. Эффективное построение запросов
- 5.11.5. Сортировка и поиск по коротким полям. Классификаторы
- 5.12. Объектное расширение sql в Informix ds/Universal Data Option
- 5.12.1. Зачем нужна поддержка объектов в серверах бд?
- 5.12.3. Внедрение объектно-ориентированной технологии
- 5.12.4. Реализация объектного подхода в Informix
- Informix ds/Universal Data Option - объектно-реляционная субд
- 5.12.5. Итак…
- Глава 6. Устройство Informix Dynamic Server
- 6.1. Внутренняя архитектура dsa
- 6.2. Механизм хранения данных
- 6.3. Инсталляция продукта
- 6.4. Запуск и останов сервера
- 6.5. Работа с русским языком
- Глава 7. Эксплуатация информационных систем
- Администрирование серверов баз данных
- 7.2. Обеспечение сохранности данных.
- 7.2.1. Технологии постоянного дублирования
- 7.2.2. Архивация
- 7.2.3. Так как же обеспечить сохранность данных?
- 7.3. Архивирование и восстановление данных
- 7.3.1. Что нужно архивировать
- 7.3.2. Утилиты архивации и восстановления
- 7.3.3. Создание архивов утилитой ontape
- 7.3.4. Восстановление из архивов утилитой ontape
- 7.3.5. Как узнать “когда”?
- 7.3.6. Практические советы
- 7.4. Средства контроля за доступом
- 7.4.1 Как работает аудитинг?
- 7.4.2. Конфигурирование списков протоколируемых событий
- 7.4.3. Задание файлов, запуск и остановка механизма аудитинга
- Анализ протокола
- 7.4.5. Практические советы или Что делать, если вы хотите…
- 7.5. Реагирование на чрезвычайные ситуации
- 7.6. Мониторинг текущего состояния сервера базы данных
- 7.6.1. Кто работает с сервером базы данных
- 7.6.2. Сколько памяти использует сервер бд
- 7.6.3. Сколько свободного места имеется у сервера бд
- 7.7. Достижение требуемой производительности
- 7.7.1. Как узнать, что ждет некоторый запрос
- 7.7.2. Как выяснять причины падения производительности
- 2. Общие принципы предлагаемой технологии
- 3. Как портировать приложение