Введение в Borland MIDAS
Multi-tier
Distributed Application Services Suite (MIDAS, набор сервисов для многозвенных
распределенных приложений) – технология компании Inprise Corporation (Borland
International), предназначенная для разработки многозвенных распределенных
приложений и их эксплуатации в корпоративных системах. Этот продукт позволяет
использовать при построении информационных систем трехзвенную архитектуру с
"тонким" клиентом, обеспечивая высокую производительность, надежность
и защиту от сбоев при эксплуатации подобных систем. Технология MIDAS позволяет
получать доступ к данным, физически расположенным на разных машинах,
распределять нагрузку ресурсов по сети, автоматически получать ограничения на
данные, что позволяет уменьшить сетевой трафик, а также разделить бизнес-логику
приложения на менее уязвимые части, распределив их по звеньям серверов. С
помощью MIDAS можно создавать системы для обработки запросов
Internet-приложений. MIDAS работает с технологиями CORBA, СОМ, MTS и
OLEnterprise (основанный на протоколе RPC продукт корпорации Open Environment, ставшей впоследствии подразделением Borland), а также упрощает
интеграцию существующих систем.
Основными инструментами разработки в технологии MIDAS являются интегрированные среды Delphi и C++Builder. Многозвенные приложения представляет собой распределенные системы удаленного доступа к данным, которые состоят как минимум из трех логических уровней. Эти логические уровни могут находиться как на одной, так и на нескольких машинах. Применение многозвенных приложений позволяет обеспечить несколько преимуществ.
· Формирование пакета бизнес-логики в общедоступном среднем уровне. Несколько клиентов имеют доступ на этот средний уровень. Это позволяет избежать дублирования бизнес-логики для каждого отдельного клиентского приложения.
· "Тонкий клиент" отличается высокой надежностью и простотой установки. Не надо заботиться о поддержании ПО для обеспечения связи с базой данных.
· Распределенная обработка информации. При распределении работы приложения на несколько машин можно улучшить эффективность благодаря балансировке нагрузки.
· Увеличение устойчивости. Можно изолировать чувствительные функциональные возможности в звенья, которые имеют различные ограничения доступа. Это обеспечивает гибкие, с перестраиваемой конфигурацией уровни защиты.
В самой простой форме, так называемой "three-tiered model", используются следующие уровни.
· Клиентское приложение обеспечивает интерфейс пользователя на пользовательской машине.
· Сервер приложений находится в доступном для всех клиентов месте и обеспечивает общую передачу данных. Управление передачей данных обеспечивает так называемый брокер данных.
· Удаленный сервер базы данных обеспечивает систему управления базой данных (СУБД).
Средствами
Delphi или C++Builder можно создать первый
и второй уровень, а для третьего воспользоваться уже существующими СУБД.
Схема распределенного приложения в терминах VCL
Информационные системы, созданные на основе классической архитектуры клиент-сервер, называются двухзвенными системами или системами с «толстым» клиентом. Они состоят из сервера баз данных, содержащего сгенерированные тем или иным способом таблицы, индексы, триггеры и другие объекты, реализующие бизнес-правила данной информационной системы, и одного или нескольких клиентских приложений, предоставляющих интерфейс пользователя и производящих проверку допустимости и обработку данных согласно содержащимся в них алгоритмам. Если говорить о клиентских приложениях, созданных с помощью Delphi или C++Builder, для доступа к источникам данных они применяют вызовы функций прикладных программных интерфейсов клиентских частей соответствующих серверных СУБД. Эти вызовы осуществляются обычно посредством использования библиотеки Borland Database Engine (BDE), хотя последнее не является обязательным. Схема такого классического клиентского приложения, по представлению Delphi–программиста, выглядит следующим образом.
Рис. 1. Классический «толстый» клиент
На форме помещаются требующиеся визуальные компоненты Data Controls, в то время как невизуальные компоненты доступа к данным (Data Access и другие), как правило, сохраняет специальный контейнер, называемый модулем данных (Data Module).
Схема трехзвенной системы, глазами того же программиста VCL, показана на следующем рисунке. Поскольку в данном случае речь идет о разработке лишь двух звеньев, «тонкого» клиента и сервера приложений, последний уровень серверов СУБД на схеме не показан. В известном смысле сервер приложений и «тонкий» клиент представляют собой разделенное на две части классическое клиентское приложение. Первая часть (сервер приложений) содержит компоненты доступа к данным и требует наличия BDE и клиента серверной СУБД, а вторая (клиент) должна содержать лишь пользовательский интерфейс и не требовать наличия BDE и какого-либо другого программного обеспечения доступа к данным.
Рис. 2. «Тонкий» клиент и сервер приложений
«Тонкий» клиент
Как видно, клиентское приложение по-прежнему содержит модуль данных (назовем его локальным), в котором помещаются невизуальные компоненты доступа к данным. Наиболее существенное отличие от классического клиента заключается в использовании вместо любого из компонентов, инкапсулирующих наборы данных (TDataSet), специальных компонентов клиентских наборов данных TClientDataSet, обеспечивающих кэшируемое соединение с удаленными наборами данных, расположенными на сервере приложений. Кроме этого является обязательным использование одного из так называемых компонентов связи: TDCOMConnection, TSocketConnection, TWebConnection, TOLEnterpriseConnection, TCorbaConnection. Задача компонентов связи – поиск и соединение с сервером приложений, а затем – управление этим соединением. Можно также использовать компоненты связи для вызова методов интерфейса сервера приложений. Каждый из компонентов связи использует определенный коммуникационный протокол: DCOM, Windows sockets (TCP/IP), HTTP, RPC и CORBA, соответсвенно.
Компонент TClientDataSet предназначен для хранения данных, полученных от сервера приложений, в кэше клиента, и, будучи потомком компонента TDataSet, обладает, подобно компонентам TTable и TQuery, как навигационными методами, так и методами, осуществляющими редактирование данных. Кроме того, этот компонент обладает методами SaveToFile и LoadFromFile, позволяющими сохранять данные из кэша в файле и восстанавливать их оттуда, реализуя так называемую «briefcase model». Такая модель обработки данных, основана на том, что «тонкий» клиент осуществляет редактирование данных по большей части при отсутствии соединения с сервером, используя лишь кэш или локальные внешние устройства, и лишь иногда соединяется с сервером приложений для передачи ему измененных данных с целью дальнейшей обработки.
Сервер приложений
Важнейшей частью серверного приложения является так называемый удаленный модуль данных (Remote Data Module). Существует три типа удаленных модулей данных.
· TRemoteDataModule. Этот тип используется в том случае, когда клиент имеет дело с компонентами сервера приложений, использующими протоколы DCOM, HTTP, Sockets, или OLEnterprise, за исключением случаев с использованием MTS.
· TMTSDataModule. Этот тип используется в том случае, если создается сервер приложений как библиотека, которая устанавливается в MTS. Можно также использовать этот тип с DCOM, HTTP, Sockets или OLEnterprise компонентами.
· TCorbaDataModule. Это сервер CORBA. Этот тип используется для обеспечения данными CORBA-клиентов.
Со всеми этими типами модулей данных можно использовать невизуальные компоненты, поскольку непосредственным предком удаленного модуля данных является обычный модуль данных, и унаследованные от него механизмы обеспечивают взаимодействие компонентов доступа к данным с сервером баз данных через BDE. Собственные механизмы удаленного модуля данных обеспечивают взаимодействие с клиентами.
Каждый удаленный модуль данных на сервере приложений содержит один или несколько провайдеров, инкапсулированных компонентами TDataSetProvider. Каждый набор данных клиента использует определенного провайдера, который действует как мост между набором данных клиента и данными, которые представляет удаленный модуль данных. Провайдер заботится об упаковке данных в пакеты, которые он посылает клиенту, и о приеме изменений, полученных от клиента. Удаленный модуль данных делает каждый такой провайдер доступным для клиента, поскольку позволяет предоставить DCOM-интерфейс для соответствующих объектов, делая их управляемыми извне и превращая, таким образом, сервер приложений в DCOM-сервер.
В свою очередь, провайдер данных:
· получает запрос на данные от клиента, получает запрошенные данные от базы данных, упаковывает данные для передачи, и посылает их клиенту;
· получает измененные данные от клиента, применяет изменения к базе данных, и записывает все изменения, которые не могут быть применены, возвращает не примененные изменения клиенту для дальнейшего согласования.
Относительно последнего пункта необходимо сделать следующее замечание. Инфраструктура разрабатываемого распределенного приложения предоставляет широкие возможности для решения характерных для многопользовательского доступа к данным проблем, связанных с попытками одновременного редактирования несколькими пользователями одних и тех же данных. Отметим, что в данном случае механизм блокировок, используемый в традиционной двухзвенной модели клиент-сервер, может оказаться неэффективным или даже неприемлемым, так как промежуток времени между редактированием записи и сохранением ее в базе данных может быть весьма длительным. Вместо этого используется следующий механизм. При попытке сохранения сервером приложений измененной записи в базе данных, прежде всего, производится ее поиск в соответствующем наборе данных на сервере приложений и сравнение всех ее полей с исходными значениями. В данном случае под исходными понимаются значения, которые были в кэше клиента на момент получения этой записи с сервера до того, как пользователь изменил в кэше эту запись. Таким путем автоматически выявляются потенциально опасные случаи параллельного изменения одной и той же записи несколькими пользователями. Если какие-либо поля за время между получением оригинала записи клиентом и попыткой сохранить изменения были модифицированы другим пользователем, запись может быть передана обратно в клиентское приложение для дальнейшей обработки пользователем.
В заключение обратим внимание на наличие в удаленном модуле еще двух компонентов, TВatabase и TSession (см. рисунок). Отметим, что для каждого «тонкого» клиента, подключенного к серверу приложений, создается свой экземпляр удаленного модуля данных, что собственно и обеспечивает одновременное обслуживание сервером сразу нескольких клиентов. Таким образом, для того, чтобы избежать конфликтов между соединениями с базой данных, устанавливаемых в разных экземплярах модуля данных, следует позаботиться о разных именах пользовательских сессий. Эту задачу выполняет компонент TSession, точнее, соответствующий его экземпляр в конкретном экземпляре модуля данных. «Размножение» же экземпляров TDatabase необходимо для того, чтобы иметь возможность индивидуальной регистрации на сервере СУБД каждого из подключаемых клиентов, поскольку имя пользователя СУБД и пароль являются свойствами именно этого компонента. Если соображения безопасности позволяют применить для всех подключений общее имя и пароль, можно упростить рассматриваемую схему, вынеся компонент TDatabase за пределы модуля данных, например, поместив его на главную форму. В этом случае нескольких его экземпляров создано не будет и необходимость в явном использовании компонента TSession отпадет.
Учебный пример трехзвенного приложения
Прежде всего, обратим внимание на важность порядка действий. Вы должны создать и запустить сервер приложений перед созданием клиента. Если вы следуете этому порядку, на этапе разработки вы можете подсоединиться к серверу и протестировать клиента. Вы можете, конечно, создавать клиента и без привязки к серверу во время разработки и использовать его только в готовом варианте. Однако в этом случае вы заранее не видите, работает ли клиент так, как вы того хотите, и не можете выбирать сервер и провайдер из списка в Инспекторе объектов.
После создания сервера приложений, его необходимо зарегистрировать. Если сервер приложений использует как коммуникационный протокол DCOM, HTTP, sockets или OLEnterprise, то он действует как сервер автоматизации и должен быть зарегистрирован подобно любому другому ActiveX- или СОМ-серверу. Если вы используете MTS, сервер приложений должен быть реализован в виде динамической библиотеки. Поскольку все вызовы СОМ должны проходить через MTS-прокси, нельзя просто зарегистрировать сервер приложений. Вместо этого следует инсталлировать библиотеку в среде MTS.
Когда сервер приложений использует CORBA, регистрация не всегда необходима. Если вы хотите позволить клиенту использовать динамическое связывание с вашим интерфейсом, вы должны инсталлировать интерфейс сервера в репозиторий интерфейсов. В дополнение к сказанному, если вы хотите позволить клиенту запускать сервер, если тот еще не запущен, он должен быть зарегистрирован с OAD (Object Activation Daemon).
Разработка учебного сервера приложений
Итак, разработка любой информационной системы на основе технологии MIDAS предполагает использование какой-либо серверной СУБД. Однако в целях упрощения рассматриваемой первоначальной иллюстрации процесса разработки наш сервер приложений будет использовать в качестве источника данных обыкновенные локальные таблицы dBase или Paradox. При этом мы воспользуемся демонстрационными таблицами из состава поставки BDE, например, из базы данных, названной поставщиком DBDEMOS. Таким образом, рассматриваемый пример на самом деле не содержит третьего звена, что впрочем, не снижает его иллюстративности: помещенные в удаленном модуле компоненты наборов данных (TDataSet) при желании можно перестроить на доступ к нужной серверной базе данных.
Разработку сервера приложений начнем с создания обычной формы небольшого размера, поскольку основное ее назначение – быть индикатором запущенного сервера приложений. Можно разместить ее где-нибудь в углу экрана и при желании установить значение свойства FormStyle равным fsStayOnTop (поверх всех остальных окон), чтобы не потерять это окно среди других открытых окон.
Помимо индикации запуска сервера, его форма будет отображать число подключенных к серверу клиентов. Для реализации данной функции используем компонент TLabel с установленным значением свойства Caption, равным ‘0’.
Далее из репозитария объектов добавим к проекту удаленный модуль данных. Для этого из основного меню File выберите команду New, затем страницу Multitier и на ней необходимый тип TRemoteDataModule. Создание удаленного модуля данных начинается с запуска мастера «Remote Data Module Wizard», где необходимо указать имя класса (CoClass Name), под которым данный сервер приложений будет зарегистрирован в реестре как OLE-сервер. Зададим, к примеру, имя DemoRDM. Согласно рассмотренной выше общей схеме трехзвенного приложения, помещаем в созданным модуль данных нужное количество компонентов наборов данных и для каждого из них – по собственному провайдеру (TDataSetProvider). В данном случае мы используем только один компонент TQuery для доступа к данным и соответственно один провайдер. Для того чтобы их связать между собой, как показано на схеме, необходимо установить значение свойства DataSet провайдера. Важно также обратить внимание на следующую особенность реализации провайдера: если требуется управлять присоединенным к нему компонентом набора данных из клиентского приложения, например путем передачи текста SQL‑запроса, необходимо в свойство Options провайдера включить значение poAllowCommandText. Для нашего примера установка этой опции является обязательной.
Сами компоненты наборов данных (TDataSet) необходимо настроить на доступ к соответствующей базе данных (в нашем случае – DBDEMOS). Поскольку требований к обеспечению безопасности доступа к данным в нашем иллюстративном примере не предъявляется, выберем наиболее простой способ настройки (см. предыдущий раздел): доступ к данным для всех «тонких» клиентов организуем через единственный компонент TDatabase, который мы с этой целью поместим на главной форме. Его свойство AliasName установим равным DBDEMOS, а свойству DatabaseName присвоим имя (например, demo), которое будет использоваться всеми компонентами TDataSet в качестве имени используемой базы данных. Так в нашем случае единственный компонент TQuery нужно соединить с TDatabase, установив значение его свойства DatabaseName соответственным образом.
Наконец, реализуем упомянутый счетчик подключенных клиентов. Его работа основана на описанном в предыдущем разделе механизме, при котором для каждого «тонкого» клиента, подключенного к серверу приложений, создается новый экземпляр удаленного модуля данных. Фактически, разрабатываемому серверу необходим счетчик создаваемых во время выполнения удаленных модулей данных. Реализуем обработчики событий, связанные с созданием и уничтожением удаленного модуля данных, которые будут отображать результат подсчета в метке формы:
procedure TDemoRDM.RemoteDataModuleCreate(Sender:
TObject);
begin
with
Form1.Label1 do
Caption :=
IntToStr(StrToInt(Caption)+1)
end;
procedure TDemoRDM.RemoteDataModuleDestroy(Sender:
TObject);
begin
with
Form1.Label1 do
Caption :=
IntToStr(StrToInt(Caption)-1)
end;
Программист, использующий среду C++Builder, напишет следующее:
void __fastcall
TDemoRDM::CRemoteDataModuleCreate(TObject *Sender)
{
Form1->Label1->Caption =
IntToStr(StrToInt(Form1->Label1->Caption)+1);
}
//-----------------------------------------------------------------
void __fastcall
TDemoRDM::CRemoteDataModuleDestroy(TObject *Sender)
{
Form1->Label1->Caption =
IntToStr(StrToInt(Form1->Label1->Caption)-1);
}
//-----------------------------------------------------------------
Перед тем как компилировать проект не забудьте в текст данного модуля (связанного с удаленным модулем данных) добавить ссылку на модуль формы:
uses Unit1;
На языке C++ это означает включение заголовочного файла главной формы:
#include "Unit1.h"
Полезно также изучить состав проекта разработанного сервера приложений. В частности, кроме использованных нами формы и модуля данных, в проекте можно обнаружить автоматически создаваемую библиотеку типов (Type library):
Рис. 3. Форма,
модуль данных и связанная с ним библиотека типов
Используя браузер библиотеки типов, можно убедиться, что COM-объект, который будет создаваться при подключении очередного клиента, обладает интерфейсом для доступа извне к удаленному модулю данных. Таким образом, разработанный нами сервер приложений является полноценным OLE-сервером, оформленным по всем правилам технологии COM.
После того как проект сохранен и откомпилирован, сервер приложений нужно запустить на выполнение, чтобы зарегистрировать его в реестре Windows. Рекомендуется убедиться, что регистрация прошла успешно при помощи утилиты Regedit (редактор реестра), после чего разработку сервера (а также – установку его на ваш компьютер) можно считать завершенной.
Разработка клиента с доступом по протоколу TCP/IP
Перед созданием клиентского приложения рекомендуется инсталлировать дополнительные средства для установления связи с разработанным ранее сервером приложений, обеспечивающие получение сообщений клиента, инициирование удаленного модуля данных и управление вызовами его интерфейса. Для выбранного нами протокола TCP/IP сокетов таким промежуточным программным обеспечением является специальная утилита Borland Socket Server (файл scktsrvr.ехе). В общем случае после запуска данной утилиты любой из установленных на компьютере серверов приложений, созданных по технологии MIDAS, может быть запущен с любого компьютера, доступного с помощью данного протокола. Поэтому при использовании подобных распределенных систем следует рассматривать различные вопросы, связанные с безопасностью их эксплуатации.
Итак, создадим новый проект будущего клиентского приложения. Удобно, хотя это и не обязательно, разработку вести на том же компьютере, на котором разрабатывался сервер. Или, по крайней мере, на компьютере, имеющем доступ по сети к установленному серверу. Согласно общей схеме трехзвенного приложения (рис.2), рассмотренной выше, клиент должен иметь локальный модуль данных с невизуальными компонентами. В простейшем случае без модуля данных можно обойтись, используя в качестве их контейнера главную форму. Таким образом, помимо визуальных компонентов (Data Controls), из которых мы воспользуемся двумя: TDBGrid и TDBNavigator, на форму следует поместить компонент связи TSocketConnection, рассмотренный выше компонент для доступа к удаленному набору данных TClientDataSet, а также компонент–источник данных, TDataSource, обеспечивающий взаимодействие визуальных компонентов с наборами данных, как показано на общей схеме (рис.2).
Попытаемся установить связь с сервером приложений (в этом и заключается упомянутое удобство: сервер может быть доступен еще на этапе разработки клиента). Для этого сначала заполним свойство Address компонента связи (IP адрес компьютера с установленным сервером), либо его свойство Host (имя компьютера в сети). Если теперь выбрать для установки свойство ServerName того же компонента связи, выпадет список всех MIDAS серверов, зарегистрированных на соответствующем компьютере, с которым компонент уже установил связь. Выберем разработанный нами сервер DemoSrv.DemoRDM. После заполнения свойства ServerName компонент связи автоматически установит свойство ServerGUID, записав в него значение глобального идентификатора COM-объекта DemoRDM из реестра. Если значение свойства ServerGUID осталось пустым, это значит, что сервер приложений не найден (т.е. он либо не зарегистрирован в реестре, либо к компьютеру нет доступа). Окончательно убедиться в доступности сервера клиенту можно, установив свойство Connected компонента связи: сервер приложений при этом должен запуститься и показать наличие у себя одного присоединенного клиента (в данном случае этим клиентом является среда разработки).
Далее согласно общей схеме, необходимо компоненту TClientDataSet указать компонент связи, который он будет использовать (свойство RemoteServer), после чего появиться возможность задать имя удаленного провайдера, экспортируемого запущенным сервером приложений (свойство ProviderName мы устанавливаем, выбирая из выпадающего списка значение DataSetProvider1). Связь между клиентским и удаленным наборами данных обеспечена. Теперь компонент TDataSource свяжем с набором данных (свойство DataSet), а все визуальные компоненты (в нашем приложении их два: TDBGrid и TDBNavigator), в свою очередь, с компонентом TDataSource (свойства DataSource визуальных компонентов).
Помимо средств отображения данных на форме разрабатываемый клиент будет генерировать SQL-запрос на выборку этих данных, и передавать этот запрос в виде команды на выполнение серверу приложений. В простейшем случае код, исполняющий эти действия, можно поместить в обработчик события нажатия кнопки на форме:
procedure
TForm1.Button1Click(Sender: TObject);
begin
with
ClientDataSet1 do begin
CommandText
:= 'SELECT * FROM COUNTRY';
Open
end
end;
Здесь COUNTRY – одна из таблиц демонстрационной базы данных DBDEMOS, на доступ к которой мы настроили наш сервер приложений. В среде C++Builder этот фрагмент выглядит следующим образом:
void __fastcall
TForm1::Button1Click(TObject *Sender)
{
ClientDataSet1->CommandText = "SELECT * FROM COUNTRY";
ClientDataSet1->Open();
}
//--------------------------------------------------------
Теперь можно запустить и протестировать клиентское приложение. Обратите внимание: показания счетчика соединений на форме сервера приложений должны измениться, так как теперь у сервера приложений два клиента – среда разработки и запущенное клиентское приложение (см. рисунок ниже).
Рис. 4.
«Тонкий» клиент, запущенный на компьютере с сервером приложений
Отметим, что разработанный клиент
позволяет не только просматривать, но и редактировать данные. Однако надо иметь
в виду, что изменения, вносимые пользователем, не переносятся на сервер базы
данных автоматически. Фактически разработанный нами клиент вообще не возвращает
серверу никаких данных. Вместо этого данные кэшируются на стороне клиента.
Механизм кэширования инкапсулируется использованным компонентом TClientDataSet, о чем рассказано ранее. Этот же
компонент осуществляет доступ к содержимому кэша, при необходимости инициируя
добавление в него новых записей или изменение существующих. Принцип работы
«тонких» клиентов – упомянутая ранее Briefcase Model (модель работы с данными без
постоянного соединения). Это означает, что клиенты лишь время от времени
соединяются с сервером приложений для синхронизации данных, а подавляющую часть
времени работают в автономном режиме с кэшем и локальными внешними
устройствами, периодически сохраняя и восстанавливая свои данные с помощью
методов SaveToFile
и LoadFromFile
компонента TClientDataSet.
Для инициации же процесса реального сохранения в базе данных используется метод
ApplyUpdates
того же компонента. Наш простейший «тонкий» клиент не предусматривает вызовов
этого метода, поэтому он никак не сможет изменить что-либо в базе данных.
Заключение: основные шаги при разработке многозвенных приложений
Для
создания сервера приложений начните новый проект, сохраните его и сделайте
следующее.
1. Добавьте новый удаленный модуль данных. Из основного меню File выберите команду New, затем страницу Multitier и на ней необходимый тип.
2. Поместите соответствующий компонент набора данных на модуль данных и установите его на доступ к базе данных сервера.
3. Поместите компонент TDataSetProvider на модуле данных для каждого набора данных.
4. Установите свойство DataSet для каждого провайдера.
5. Напишите код для обработки событий, бизнес-правил, проверки данных и обеспечения безопасности.
6. Сохраните, скомпилируйте, зарегистрируйте (или установите) сервер приложений.
7. Если сервер не использует DCOM, то вы должны инсталлировать дополнительные средства для получения сообщений клиента, инициирования удаленного модуля данных и управления вызовами интерфейса:
· для TCP/IP сокетов это утилита scktsrvr.ехе;
· для HTTP соединений это библиотеки httpsrvr.dll, ISAPI.DLL (NSAPI DLL), которые должны быть инсталлированы на вашем Web-сервере;
·
для
OLEnterprise это пакет OLEnterprise runtime;
· для CORBA это брокер запросов VisiBroker ORB.
Для создания клиентского приложения необходимо сделать
следующее.
1.
Добавить новый модуль данных в проект.
2. Поместить компонент связи на модуль данных.
3. Установить свойства компонента связи, определяющие сервер приложений, с которым будет установлено соединение.
4. Установить свойства других компонентов связи, если в этом есть необходимость. Например, вы можете установить свойство ObjectBroker, которое позволяет компоненту связи выбирать динамически один из нескольких доступных серверов.
5. Поместить столько компонентов TСlientDataSet на модуль данных, сколько потребуется и установить свойство RemoteServer для каждого компонента соответственно, чтобы указать один из используемых компонентов связи.
6. Установить свойство ProviderName для каждого компонента TClientDataSet. Если ваш компонент связи подсоединен к серверу приложений во время дизайна, то вы можете выбрать значение свойства из списка.