9. Физическая структура распределенных приложений
А сейчас обратимся к физическим уровням распределенных приложений.
Топология распределенной системы подразумевает разделение на:
несколько серверов баз данных,
несколько серверов обработки данных
совокупность локальных и удаленных клиентов.
Все они могут располагаться где угодно: в одном здании или на другом континенте.
В любом случае части распределенной системы должны быть соединены надежными и защищенными линиями связи.
Что касается скорости передачи данных, то она в значительной степени зависит от важности соединения между двумя частями системы с точки зрения обработки и передачи данных и в меньшей степени от их удаленности.
10. Распределение бизнес-логики по уровням распределенного приложения
Дадим подробное описание уровней распределенной системы.
Предварительно рассмотрим распределении функциональности приложения по уровням.
Бизнес-логика может быть реализована на любом из уровней трехуровневой архитектуры.
Серверы БД могут не только сохранять данные в базах данных, но и содержать часть бизнес-логики приложения в хранимых процедурах, триггерах и т. д.
Клиентские приложения также могут реализовывать правила обработки данных.
Если набор правил минимален и сводится в основном к процедурам проверки корректности ввода данных, мы имеем дело с "тонким" клиентом.
"Толстый" клиент, наоборот, содержит большую долю функциональности приложения.
Уровень обработки данных собственно и предназначен для реализации бизнес-логики приложения, и здесь сконцентрированы все основные правила обработки данных.
Таким образом, в общем случае функциональность приложения оказывается "размазанной" по всему приложению. Все разнообразие распределения бизнес-логики по уровням приложений можно представить в виде плавной кривой, показывающей долю правил обработки данных, сконцентрированной в конкретном месте. Кривые на рис. 3 носят качественный характер, но тем не менее позволяют увидеть, как изменения в структуре приложения могут повлиять на распределение правил.
Рис. 3. Распределение бизнес-логики по уровням распределенного приложения
И практика подтверждает это заключение. Ведь всегда найдется парочка правил, которые нужно реализовать именно в хранимых процедурах сервера БД, и очень часто бывает удобно перенести некоторые первоначальные операции с данными на сторону клиента - хотя бы для того, чтобы предотвратить обработку некорректных запросов.
11. Уровень представления данных
Уровень представления данных - единственный доступный конечному пользователю.
Этот уровень моделирует клиентские рабочие места распределенного приложения и соответствующее ПО.
Возможности клиентского рабочего места в первую очередь определяются возможностями операционной системы.
В зависимости от типа пользовательского интерфейса клиентское ПО делится на две группы:
клиенты, использующие возможности ГИП (например, Windows),
и Web-клиенты.
Но в любом случае клиентское приложение должно обеспечивать выполнение следующих функций:
получение данных;
представление данных для просмотра пользователем;
редактирование данных;
проверка корректности введенных данных;
сохранение сделанных изменений;
обработка исключительных ситуаций и отображение информации об ошибках для пользователя.
Все бизнес-правила желательно сконцентрировать на уровне обработки данных, но на практике это не всегда удается. Тогда говорят о двух типах клиентского ПО:
1. "Тонкий" клиент содержит минимальный набор бизнес-правил.
2. "Толстый" клиент реализует значительную долю логики приложения.
В случае тонкого " клиента распределенное приложение существенно легче отлаживать, модернизировать и расширять.
В случае толстого" клиента - можно минимизировать расходы на создание и поддержание уровня управления данными, так как часть операций может выполняться на стороне клиента, а на долю промежуточного ПО ложится только передача данных.