
- •1. Модели взаимодействия компонентов рис
- •2. Обмен сообщениями
- •3. Удаленный вызов процедур
- •3.1. Вызов распределенных процедур.
- •4. Механизм работы rpc
- •5. Обращение к удаленным объектам (rmi)
- •6. Связь на основе потоков данных
- •7. Архитектура распределённых приложений
- •7.1. Принципы создания системы обработки информации в масштабе предприятия
- •7.2. Парадигма распределенных вычислений
- •8. Архитектура распределенных приложений
- •9. Физическая структура распределенных приложений
- •10. Распределение бизнес-логики по уровням распределенного приложения
- •11. Уровень представления данных
- •12. Уровень обработки данных
- •13. Уровень управления данными
- •14. Уровень хранения данных
- •15. Расширения базовых уровней
12. Уровень обработки данных
Уровень обработки данных:
1. Объединяет части, реализующие бизнес-логику приложения,
2. Является посредником между уровнем представления данных и уровнем их хранения. Через него проходят все данные и претерпевают в нем изменения, обусловленные решаемой задачей (см. рис. 2).
Рис. 2. Основные уровни архитектуры распределенного приложения
К функциям этого уровня относятся следующие:
обработка потоков данных в соответствии с бизнес-правилами;
взаимодействие с уровнем представления данных для получения запросов и возвращения ответов;
взаимодействие с уровнем хранения данных для передачи запросов и получения ответов.
Чаще всего уровень обработки данных отождествляют с промежуточным ПО распределенного приложения.
Такая ситуация в полной мере верна для "идеальной" системы и лишь отчасти - для реальных приложений (см. рис. 3).
Рис. 3. Распределение бизнес-логики по уровням распределенного приложения
Что касается реальных приложений, то промежуточное ПО для них содержит большую долю правил обработки данных, но часть из них реализована в серверах SQL в виде хранимых процедур или триггеров, а часть включена в состав клиентского ПО.
Примечание 1
SQL Serverпозиционируетя как реляционная СУБДс поддержкой языка SQLи возможностью работы по локальной сети.
Microsoft SQL Server— система управления реляционными базами данных (СУРБД), разработанная корпорациейMicrosoft.Основной используемый язык запросов—Transact-SQL,создан совместно MicrosoftиSybase.
SQL(англ.structured query language— «язык структурированных запросов»)—формальный непроцедурный язык программирования,применяемый для создания, модификации и управления данными в произвольнойреляционной базе данных, управляемой соответствующей системой управления базами данных(СУБД).
В Реляционных базах данныхданные собраны в таблицы, которые в свою очередь состоят из столбцов и строк, на пересечении которых расположены ячейки. Запросы к таким базам данных возвращает таблицу, которая повторно может участвовать в следующем запросе. Данные в одних таблицах, как правило, связаны с данными других таблиц, откуда и произошло название "реляционные".
Такое "размывание" бизнес-логики оправданно, так как позволяет упростить часть процедур обработки данных.
Возьмем классический пример выписки заказа. В него могут быть включены наименования только тех продуктов, которые имеются на складе. Следовательно, при добавлении в заказ некоторого наименования и определения его количества соответствующее число должно быть вычтено из остатка этого наименования на складе. Очевидно, что лучше всего реализовать эту логику средствами сервера БД - хранимой процедурой или триггером.
13. Уровень управления данными
Уровень управления данными нужен для того, чтобы приложение:
1. Оставалось единым целым,
2 Было устойчивым и надежным,
3. Имело возможности модернизации и масштабирования.
Уровень управления данными обеспечивает выполнение системных задач, без него части приложения (серверы БД, серверы приложения, промежуточное ПО, клиенты) не смогут взаимодействовать друг с другом, а связи, нарушенные при повышении нагрузки, нельзя будет восстановить.
Кроме того, на уровне управления данными могут быть реализованы различные системные службы приложения.
Ведь всегда существуют общие для всего приложения функции, которые необходимы для работы всех уровней приложения, следовательно, их невозможно расположить ни на одном из других уровней.
Например, служба единого времени обеспечивает все части приложения системными метками времени, синхронизирующими их работу.
Представьте, что распределенное приложение имеет некий сервер, рассылающий клиентам задания с указанием конкретного срока их выполнения. При срыве установленного срока задание должно регистрироваться с вычислением времени задержки. Если клиентские рабочие станции расположены в том же здании, что и сервер, или на соседней улице, - нет проблем, алгоритм учета прост. Но что делать, если клиенты расположены в других часовых поясах - в других странах или вообще за океаном? В этом случае сервер должен уметь вычислять разницу с учетом часовых поясов при отправке заданий и получении ответов, а клиенты будут обязаны добавлять к отчетам служебную информацию о местном времени и часовом поясе. Если же в состав распределенного приложения входит служба единого времени, то такой проблемы просто не существует.
Кроме службы единого времени уровень управления данными может содержать службы хранения общей информации (сведения о приложении в целом), формирования общих отчетов и т. д.
Итак, к функциям уровня управления данными относятся:
управление частями распределенного приложения;
управление соединениями и каналами связи между частями приложения;
управление потоками данных между клиентами и серверами и между серверами;
управление нагрузкой;
реализация системных служб приложения.
Необходимо отметить, что часто уровень управления данными создается на основе готовых решений, поставляемых на рынок программного обеспечения различными производителями.
Если разработчики выбрали для своего приложения архитектуру CORBA, то в ее составе имеется брокер объектных запросов (Object Request Broker, ORB), если платформу Windows, - к их услугам разнообразные инструменты:
технология COM+ (развитие технологии Microsoft Transaction Server, MTS),
технология обработки очередей сообщений MSMQ,
технология Microsoft BizTalk и др.