Очевидно, что в этом случае модель доступа к данным должна быть расширена, т. к. наличие большого числа удаленных клиентов делает традиционные схемы создания приложений БД малоэффективными.

В этой главе мы рассмотрим модель распределенного приложения БД, которая называется многозвенной (multitiered), и, в частности, ее наиболее простой вариант - трехзвенное распределенное приложение. Тремя частями такого приложения являются:

• собственно сервер базы данных;
□ сервер приложений (серверная часть приложения);

□ клиентская часть приложения.

Все они объединены в единое целое единым механизмом взаимодействия (транспортный уровень) и обработки данных (уровень бизнес-логики).

Компоненты и объекты Delphi, обеспечивающие разработку многозвенных приложений, объединены общим названием DataSnap.

(_Примечание_}

В предыдущих версиях Delphi (Delphi 4 и 5) эти компоненты объединялись под названием MIDAS (Multi-tier Distributed Applications Services - сервисы многозвенных распределенных приложений).

Палитра компонентов Delphi содержит специальную страницу DataSnap, на которой доступно большинство рассматриваемых в главах этой части компонентов. Однако при разработке многозвенных приложений нам понадобятся и многие другие компоненты, которым также уделено достаточное внимание.

В этой главе рассматриваются следующие вопросы:

□ структура многозвенных приложений;
□ механизм удаленного доступа к данным DataSnap;
□ удаленные модули удаленных данных;
□ компоненты-провайдеры;
□ транспортные компоненты удаленных соединений DataSnap;

□ вспомогательные компоненты - брокеры соединений.

Структура многозвенного приложения в Delphi

Многозвенная архитектура приложений баз данных вызвана к жизни необходимостью обрабатывать на стороне сервера запросы от большого числа удаленных клиентов. Казалось бы, с этой задачей вполне могут справиться и приложения клиент/сервер, основные элементы которых представлены в части Ш.

Однако в этом случае при большом числе клиентов вся вычислительная нагрузка ложится на сервер БД, который обладает довольно скудным набором средств для реализации сложной бизнес-логики (хранимые процедуры, триггеры, просмотры и т. д.). И разработчики вынуждены существенно усложнять программный код клиентского ПО, а это крайне нежелательно при наличии большого числа удаленных клиентских компьютеров. Ведь с усложнением клиентского ПО возрастает вероятность ошибок и усложняется его обслуживание.

Многозвенная архитектура приложений БД призвана исправить перечисленные недостатки.

Итак, в рамках этой архитектуры "тонкие" клиенты представляют собой простейшие приложения, обеспечивающие лишь передачу данных, их локальное кэширование, представление средствами пользовательского интерфейса, редактирование и простейшую обработку.

Клиентские приложения обращаются не к серверу БД напрямую, а к специализированному ПО промежуточного слоя. Это может быть и одно звено (простейшая трехзвенная модель) и более сложная структура.