Организация распределенных прикладных систем

Попытаемся ответить на вопросы Как устроены распределенные прикладные системы? Каковы наиболее важные их компоненты? Какую роль играет промежуточное программное обеспечение в разработке распределенных систем? Каковы типичные проблемы, которые могут возникнуть в процессе разработки и интеграции систем?

Как устроены распределенные прикладные системы Большинство прикладных программ можно разделить на три части: логику (алгоритмы) представления бизнес-логику (расчетные алгоритмы и правила) логику (алгоритмы) доступа к данным

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

Бизнес-логика определяет, для чего, собственно, предназначено приложение в зависимости от конкретных функциональных требований и сложности задач может быть полезным подразделить эту часть на несколько компонентов (набор процедур, класс или классы объектов, отдельные программы)

Алгоритмы доступа к данным исторически рассматривались как специфический для конкретного приложения интерфейс к механизму постоянного хранения данных (наподобие файловой системы или СУБД) при помощи этой части программы приложение управляет соединениями с базой данных и запросами к ней к этой части относят только специфический для приложения интерфейс к СУБД, но не ее саму

Распределенное приложение состоит из слоев «переднего слоя» (front-end, логика представления) «среднего слоя» (бизнес-логика) «заднего слоя» (back-end, логика доступа к данным)

Пример - приложение, которое производит поиск в базе данных 1.пользователь заполняет формы и нажимает кнопку «Поиск» 2.информация передается блоку бизнес-логики –формирует один или более запросов 3.запросы один за другим передаются блоку логики доступа к данным –преобразует данные и запросы в формат, совместимый с СУБД, выполняет каждый запрос, получает результат и преобразует его в формат приложения 4.результат возвращается блоку бизнес-логики –объединяет результаты нескольких запросов в порцию информации 5.результат передается блоку логики представления –помещает эти данные в удобочитаемую форму и показывает ее пользователю

Архитектуры прикладных систем

Виды архитектур прикладных систем Централизованная архитектура Разделение файлов Клиент-сервер

Централизованная архитектура

Разделение файлов dBASE, FoxPro и Clipper

Разделение файлов все приложения должны вписаться в единственный ПК совместное использование и конфликты обновления чрезвычайно снижают производительность пропускная способность сети - объем данных, которые могут передаваться, невелик

Клиент-сервер

вместо передачи файлов целиком он пересылает только ответы на запросы клиентов на уровне программного обеспечения разделение на клиента и сервер является логическим: процессы клиента и сервера могут физически размещаться как на одной, так и на разных машинах. под общим концептуальным названием скрываются три варианта архитектуры: –двухзвенная –трехзвенная –многозвенная Клиент-сервер

Двухзвенная архитектура

Недостатки: ограничение, вытекающее из вычислительной мощности отдельных машин клиентов ограничения на число одновременных соединений с сервером –сервер поддерживает открытое соединение со всеми активными клиентами, даже если никакой работы нет Двухзвенная архитектура

Технология хранимых процедур Идея - переместить алгоритмы бизнес- логики на серверную машину, ближе к данным, которые требуются им постоянно Ограничения число пользователей, которых может поддерживать такая система, ограничено максимумом возможных активных соединений с СУБД от СУБД к СУБД механизмы хранимых процедур разнятся Примеры: Delphi и PowerBuilder

Трехзвенная архитектура

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

Разновидности: с сервером приложений с монитором обработки транзакций с сервером передачи сообщений с брокером объектных запросов Трехзвенная архитектура

Сервер приложений

Преимущества: «утоньшение» клиента простота обновления прикладного ПО сервер приложений поддерживает пул открытых подключений к базам данных, подключения многократно используются для выполнения запросов различных клиентов

Сервер приложений аппаратная платформа, на которой выполняется сервер приложений, может быть достаточно мощной; это дает дополнительную степень масштабируемости всей прикладной системы централизованный доступ к данным в серверах приложений делает всю прикладную систему менее зависящей от конкретной СУБД другое «внешнее» приложение может легко взаимодействовать с «чужим» сервером приложений

Архитектура с пятью звеньями

Литература