Технология DataSnap (статья)

== Технология DataSnap. Механизмы удаленного доступа ==
Как быть, если необходимо создать приложение, которое может с одинаковым успехом работать как в локальной сети, так и на удаленном компьютере.
Очевидно, что в этом случае модель доступа к данным должна быть расширена, т. к. наличие большого числа удаленных клиентов делает традиционные схемы создания приложений БД малоэффективными.
В этой главе мы рассмотрим модель распределенного приложения БД, которая называется многозвенной (multitiered), и, в частности, ее наиболее простой вариант - трехзвенное распределенное приложение. Тремя частями такого приложения являются:
* собственно сервер базы данных;
* сервер приложений (серверная часть приложения);
* клиентская часть приложения.
Все они объединены в единое целое единым механизмом взаимодействия (транспортный уровень) и обработки данных (уровень бизнес-логики).
Компоненты и объекты Delphi, обеспечивающие разработку многозвенных приложений, объединены общим названием DataSnap.
; Примечание: В предыдущих версиях Delphi (Delphi 4 и 5) эти компоненты объединялись под названием MIDAS (Multi-tier Distributed Applications Services - сервисы многозвенных распределенных приложений).
Палитра компонентов Delphi содержит специальную страницу DataSnap, на которой доступно большинство рассматриваемых в главах этой части компонентов. Однако при разработке многозвенных приложений нам понадобятся и многие другие компоненты, которым также уделено достаточное внимание.
== Структура многозвенного приложения в Delphi ==
Многозвенная архитектура приложений баз данных вызвана к жизни необходимостью обрабатывать на стороне сервера запросы от большого числа удаленных клиентов. Казалось бы, с этой задачей вполне могут справиться и приложения клиент/сервер, основные элементы которых представлены в части III.
Однако в этом случае при большом числе клиентов вся вычислительная нагрузка ложится на сервер БД, который обладает довольно скудным набором средств для реализации сложной бизнес-логики (хранимые процедуры, триггеры, просмотры и т. д.). И разработчики вынуждены существенно усложнять программный код клиентского ПО, а это крайне нежелательно при наличии большого Числа удаленных клиентских компьютеров. Ведь с усложнением клиентского ПО возрастает вероятность ошибок и усложняется его обслуживание.
Многозвенная архитектура приложений БД призвана исправить перечисленные недостатки.
Итак, в рамках этой архитектуры "тонкие" клиенты представляют собой простейшие приложения, обеспечивающие лишь передачу данных, их локальное кэширование, представление средствами пользовательского интерфейса, редактирование и простейшую обработку.
Клиентские приложения обращаются не к серверу БД напрямую, а к специализированному ПО промежуточного слоя. Это может быть и одно звено (простейшая трехзвенная модель) и более сложная структура.
ПО промежуточного слоя называется сервером приложений, принимает запросы клиентов, обрабатывает их в соответствии с запрограммированными правилами бизнес-логики, при необходимости преобразует в форму, удобную для сервера БД и отправляет серверу.
Сервер БД выполняет полученные запросы и отправляет результаты серверу приложений, который адресует данные клиентам.
Таким образом, многозвенное приложение БД состоит из
* "тонких" клиентских приложений, обеспечивающих лишь передачу, представление, редактирование и простейшую обработку данных;
* одного или нескольких звеньев ПО промежуточного слоя (сервер приложений), которые могут функционировать как на одном компьютере, так и распределенно - в локальной сети;
* сервера БД (Oralce, Sybase, MS SQL, InterBase и т. д.), поддерживающего функционирование базы данных и обрабатывающего запросы.
Более простая трехзвенная модель содержит следующие элементы:
* "тонкие" клиенты;
* сервер приложений;
* сервер БД.
Далее мы будем рассматривать именно трехзвенную модель. В среде разработки Delphi имеется набор инструментов и компонентов для создания клиентского ПО и ПО промежуточного слоя.
Сервер приложений взаимодействует с сервером БД, используя одну из технологий доступа к данным, реализованным в Delphi. Это технологии ADO, BDE, InterBase Express и dbExpress. Разработчик может выбрать наиболее подходящую, исходя из поставленной задачи и параметров сервера БД.
Удаленные клиентские приложения создаются с использованием специального набора компонентов, объединенных общим названием DataSnap. Эти компоненты инкапсулируют стандартные транспорты (DCOM, HTTP, сокеты) и обеспечивают соединение удаленного клиентского приложения с сервером приложения. Также компоненты DataSnap обеспечивают доступ клиента к функциям сервера приложений за счет использования интерфейса AppServer
Важную роль при разработке клиентских приложений играет компонент, инкапсулирующий клиентский набор данных. Его реализации также зависят от технологий доступа к данным.
Наряду с перечисленными выше преимуществами, наличие дополнительного звена - сервера приложений - дает некоторые дополнительные бонусы, которые могут быть весьма существенным подспорьем с точки зрения повышения надежности и эффективности системы.
Так как зачастую клиентские компьютеры - это достаточно слабые машины, реализация сложной бизнес-логики на сторону сервера позволяет существенно повысить быстродействие системы в целом. И не только за счет более мощной техники, но и за счет оптимизации выполнения однородных запросов пользователей.
Например, при чрезмерной загрузке сервера, сервер приложений может самостоятельно обрабатывать запросы пользователей (ставить их в очередь или отменять) без дополнительной загрузки сервера БД.
Наличие сервера приложений повышает безопасность системы, т. к. вы можете организовать здесь авторизацию пользователей, да и любые другие функции безопасности без прямого доступа к данным.
Кроме того, вы легко сможете использовать защищенные каналы передачи данных, например HTTPS.
== Трехзвенное приложение в Delphi ==
Теперь рассмотрим составные части трехзвенного распределенного приложения в Delphi. Как говорилось выше, в Delphi целесообразно разрабатывать клиентскую часть трехзвенного приложения и ПО промежуточного слоя - сервер приложений.
Части трехзвенных приложений разрабатываются с использованием компонентов DataSnap, а также некоторых других специализированных компонентов, в основном обеспечивающих функционирование клиента. Для доступа к данным применяется одна из четырех технологий, реализованных в Delphi.
; Примечание: Разработку трехзвенных приложений целесообразно вести, используя в среде разработки группу проектов вместо одиночных проектов. Для этого используется утилита Project Manager (меню View -> Project Manager).
Для передачи данных между сервером приложений и клиентами используется интерфейс AppServer, предоставляемый удаленным модулем данных сервера приложений. Этот интерфейс используют компоненты-провайдеры TDataSetProvider на стороне сервера и компоненты TClientDataSet на стороне клиента.
=== Сервер приложений ===
Сервер приложений инкапсулирует большую часть бизнес-логики распределенного приложения и обеспечивает доступ клиентов к базе данных.
Основной частью сервера приложений является удаленный модуль данных.
Во-первых, подобно обычному модулю данных он является платформой для размещения невизуальных компонентов доступа к данным и компонентов-провайдеров. Размещенные на нем компоненты соединений, транзакций и компоненты, инкапсулирующие наборы данных, обеспечивают трехзвенное приложение связью с сервером БД. Это могут быть наборы компонентов для технологий ADO, BDE, InterBase Express, dbExpress.
Во вторых, удаленный модуль данных реализует основные функции сервера приложений на основе предоставления клиентам интерфейса IAppServer или его потомка. Для этого удаленный модуль данных должен содержать необходимое число компонентов-провайдеров TDataSetProvider. Эти компоненты передают пакеты данных клиентскому приложению, а точнее компонентам TdientDataSet, а также обеспечивают доступ к методам интерфейса.
В состав Delphi входят удаленные модули данных. Для их создания используйте страницы Multitier, WebSnap и WebServices Репозитория Delphi.
* Remote Data Module - удаленный модуль данных, инкапсулирующий сервер Автоматизации. Используется для организации соединений через DCOM, HTTP, сокеты (см. гл. 21).
* Transactioiial Data Module - удаленный модуль данных, инкапсулирующий сервер MTS (Microsoft Transaction Server).
* SOAP Server Data Module - удаленный модуль данных, инкапсулирующий сервер SOAP (Simple Object Access Protocol).
* WebSnap Data Module - удаленный модуль данных, использующий Web-службы и Web-браузер в качестве сервера.
Помимо удаленного модуля данных неотъемлемой частью сервера приложений являются компоненты-провайдеры TDataSetProvider. С каждым компонентом, инкапсулирующим набор данных, предназначенным для передачи клиенту, в модуле данных должен быть связан компонент-провайдер.
=== Клиентское приложение ===
Клиентское приложение в трехзвенной модели должно обладать лишь минимально необходимым набором функций, делегируя большинство операций по обработке данных серверу приложений.
В первую очередь удаленное клиентское приложение должно обеспечить соединение с сервером приложений. Для этого используются компоненты соединений DataSnap:
* TDCOMConnection - использует DCOM;
* TSocketconnection - использует сокеты Windows;
* TWebConnection - использует HTTP.
Компоненты соединения DataSnap предоставляют интерфейс IAppServer, используемый компонентами-провайдерами на стороне сервера и компонентами TClientDataSet на стороне клиента для передачи пакетов данных.
Для работы с наборами данных используются компоненты TClientDataSet, работающие в режиме кэширования данных.
Для представления данных и создания пользовательского интерфейса в клиентском ПО применяются стандартные компоненты со страницы Data Controls Палитры компонентов.
== Механизм удаленного доступа к данным DataSnap ==
Для передачи пакетов данных между компонентом-провайдером и клиентским набором данных (между клиентом и сервером) должен существовать некий транспортный канал, обеспечивающий физическую передачу данных. Для этого могут использоваться разнообразные транспортные протоколы, поддерживаемые операционной системой.
Различные типы соединений, позволяющие настроить транспорт и начать передачу и прием данных, инкапсулированы в нескольких компонентах DataSnap. Для создания соединения с тем или иным транспортным протоколом разработчику достаточно перенести соответствующий компонент на форму и правильно настроить несколько свойств. Ниже рассматриваются варианты настройки транспортных протоколов для компонентов, использующих DCOM, сокеты TCP/IP, HTTP.
=== Компонент TDCOMConnection ===
Компонент TDCOMConnection предоставляет транспорт на основе технологии Distributed COM и применяется в основном для организации транспорта в рамках локальной сети.
Для настройки соединения DCOM в первую очередь необходимо задать имя компьютера, на котором функционирует сервер приложений. Для компонента TDCOMConnection это должен быть зарегистрированный сервер Автоматизации. Имя компьютера задается свойством ComputerName
Если оно задано правильно, в списке свойства ServerName в Инспекторе объектов можно выбрать один из доступных серверов. При выборе сервера также автоматически заполняется свойство ServerGUID
Причем для успешного соединения клиента с сервером приложений оба свойства должны быть заданы в обязательном порядке. Только имя сервера или только его GUID не обеспечат правильный доступ к удаленному объекту СОМ.
Открытие и закрытие соединения осуществляется свойством Connected или методами Open() / Close() соответственно.
Для организации передачи данных между клиентом и сервером компонент TDCOMConnection предоставляет интерфейс IAppServer. Доступ к интерфейсу IAppServer предоставляет свойство AppServer или метод GetServer()
Свойство ObjectBroker позволяет использовать экземпляр компонента TsimpleObjectBroker для получения списка доступных серверов по время выполнения (см. ниже).
Методы-обработчики компонента TDCOMConnection:
* AfterConnect - вызывается после установления соединения
* AfterDisconnect - вызывается после разрыва соединения
* BeforeConnect - вызывается перед установлением соединения
* BeforeDisconnect - вызывается перед разрывом соединения
* OnGetUsername - вызывается непосредственно перед появлением диалога удаленной авторизации пользователя. Для этого свойство LoginPrompt должно иметь значение True. Параметр Username может содержать имя пользователя по умолчанию, которое появится в диалоге
* OnLogin - вызывается после открытия соединения, если свойство LoginPrompt имеет значение True. Параметры Username и Password содержат имя пользователя и пароль, введенные при авторизации
=== Компонент TSocketConnection ===
Компонент TSocketConnection обеспечивает соединение клиента с сервером приложений за счет использования сокетов TCP/IP. Для успешного открытия соединения на стороне сервера должен работать сокет-сервер (приложение ScktSrvr.exe, рис. 20.4).
Для успешного соединения свойство Host должно содержать имя компьютера сервера. Дополнительно, свойство Address должно содержать IP-адрес сервера. Для открытия соединения должны быть заданы оба этих свойства.
Свойство Port устанавливает номер используемого порта. По умолчанию это порт 211, но разработчик волен изменить порт, например, для использования различными категориями пользователей или для создания защищенного канала.
После правильного выбора компьютера в списке свойства ServerName в Инспекторе объектов появляется перечень доступных серверов Автоматизации. И после выбора сервера свойство ServerGUID которое содержит имя компьютера GUID зарегистрированного сервера, задается автоматически, хотя его можно задать и вручную.
Метод GetServerList() возвращает список зарегистрированных серверов Автоматизации. Открытие и закрытие соединения осуществляется свойством Connected или методами Open() / Close() соответственно.
Канал сокета TCP/IP может быть зашифрован. Для этого используется свойство InterceptName содержащее программный идентификатор объекта СОМ, обеспечивающего шифрование/дешифрование данных в канале, и свойство InterceptGUID содержащее имя GUID компьютера этого объекта. Этот объект СОМ перехватывает данные в канале и осуществляет их обработку, предусмотренную собственным программным кодом. Это может быть шифрование, сжатие, обработка шумов и т. д.
; Примечание: Создание объекта СОМ, обеспечивающего дополнительную обработку данных в канале, ложится на плечи разработчика. Объект-перехватчик должен поддерживать стандартный интерфейс IDataintercept.
Естественно, на стороне сервера должен быть зарегистрирован объект СОМ, выполняющий обратную операцию. Для этого также используется сокет-сервер. Строка Interceptor на странице должна содержать имя компьютера GUID объекта-перехватчика СОМ.
GetlnterceptorList() возвращает список зарегистрированных на сервере объектов-перехватчиков.
Для организации передачи данных между клиентом и сервером компонент TSocketConnection предоставляет интерфейс IAppServer который также может быть получен методом GetServer() или свойством AppServer
Свойство ObjectBroker позволяет использовать экземпляр компонента TSimpieObjectBroker для получения списка доступных серверов во время выполнения (см. ниже).
Методы-обработчики событий компонента TSocketConnection полностью совпадают с методами-обработчиками компонента TDCOMConnection
=== Компонент TWebConnection ===
Компонент TWebConnection предоставляет клиенту соединение на основе транспорта HTTP. Для работы компонента на клиентском компьютере должна быть зарегистрирована библиотека wininet.dll. Обычно это не требует специальных усилий, т. к. этот файл уже имеется в системной папке Windows, если на компьютере установлен Internet Explorer.
На компьютере сервера должен быть инсталлирован Internet Information Server версии не ниже 4.0 или Netscape Enterprise версии не ниже 3.6. Перечисленное ПО обеспечивает доступ компонента TWebConnection к динамической библиотеке HTTPsrvr.dll, которая также должна находиться на сервере.
Например, если файл HTTPsrvr.dll расположен в папке Scripts US 4.0 на Web-сервере www.someserver.com, то свойство URL должно содержать следующее значение:
 http://someserver.com/scripts/httpsrvr.dll
Если URL задан верно и сервер настроен правильно, то в списке свойства ServerName в Инспекторе объектов появляется перечень зарегистрированных серверов Приложений. Имя одного из них должно содержаться в свойстве ServerName. После выбора имени сервера, в свойстве ServerGUID автоматически появляется GUID сервера. Свойства UserName и Password при необходимости могут содержать имя и пароль пользователя, которые будут использованы при авторизации.
Свойство Proxy содержит имя используемого прокси-сервера.
В заголовок сообщений HTTP можно поместить имя приложения. Для этого используется свойство Agent
Соединение открывается и закрывается при помощи свойства Connected Аналогичные операции выполняют методы Open() и Close()
Доступ к интерфейсу IAppServer предоставляет свойство AppServer или метод GetServer()
Список доступных соединению серверов приложений возвращает метод GetServerList()
Свойство ObjectBroker позволяет использовать экземпляр компонента TSimpieObjectBroker для получения списка доступных серверов во время выполнения (см. ниже).
Методы-обработчики событий компонента TWebConnection полностью совпадают с методами-обработчиками компонента TDCOMConnection.
=== Провайдеры данных ===
Компонент-провайдер TDataSetProvider представляет собой мост между набором данных сервера приложений и клиентским набором данных. Он обеспечивает формирование и передачу пакетов данных клиентскому приложению и прием от него сделанных изменений.
Все необходимые операции компонент выполняет автоматически. Разработчику необходимо лишь разместить компонент TDataSetProvider и связать его с набором данных сервера приложений. Для этого предназначено свойство DataSet
Если соединение в клиентском приложении настроено правильно (см. выше), то в списке выбора свойства ProviderName компонента TClientDataSet в Инспекторе объектов появляются имена всех компонентов-провайдеров сервера приложений. Если связать клиентский набор данных с компонентом-провайдером, а затем открыть его, в клиентский набор данных будут переданы записи из набора данных сервера приложений, указанного в свойстве DataSet компонента-провайдера TDataSetProvider.
Компонент также содержит свойства, помогающие настроить процесс обмена данными.
* ResolveToDataSet - управляет передачей данных от клиента серверу БД. Если оно имеет значение True, все изменения передаются в набор данных сервера приложений, заданный свойством DataSet. Иначе изменения направляются напрямую серверу БД. Если сервер приложений не должен отображать сделанные клиентом изменения, то свойству ResolveToDataSet можно присвоить значение False, что ускорит работу приложения.
* Constraints - управляет передачей ограничений серверного набора данных клиентскому. Если свойство имеет значение True, ограничения передаются.
* Exported - позволяет использовать в клиентском наборе данных интерфейс IAppServer. Для этого свойство должно иметь значение True.
Параметры компонента-провайдера задаются свойством Options Набор параметров свойства задается присвоением элементам значения True.
* poFetchBlobsOnDemand - включает передачу в клиентский набор данных значений полей типа BLOB. По умолчанию эта возможность, отключена для ускорения работы;
* poFetchDetailsOnDemand - включает передачу в клиентский набор данных подчиненных записей для отношения "один-ко-многим". По умолчанию эта возможность отключена для ускорения работы;
* poIncFieldProps - включает передачу в клиентский набор данных нескольких свойств для объектов полей: Alignment, DisplayLabel, DisplayWidth, Visible, DisplayFormat, EditFormat, MaxValue, MinValue, Currency, EditMask, DisplayValues;
* poCascadeDeletes - включает автоматическое удаление подчиненных записей в отношении "один-ко-многим" на стороне сервера, если главная запись была удалена в клиентском наборе данных;
* poCascadeUpdates - включает автоматическое обновление подчиненных записей в отношении "один-ко-многим" на стороне сервера, если главная запись была изменена в клиентском наборе данных;
* poReadOnly - включает режим "только для чтения" для набора данных сервера;
* poAllowMultiRecordUpdates - включает режим внесения изменений сразу в несколько записей одновременно. Иначе все записи изменяются последовательно, одна за одной;
* poDisablelnserts - запрещает клиенту вносить в набор данных сервера новые записи;
* poDisableEdits - запрещает клиенту вносить в набор данных сервера изменения;
* poDisableDeletes - запрещает клиенту удалять записи в наборе данных сервера;
* poNoReset - запрещает обновление набора данных сервера перед передачей записей клиенту (перед вызовом метода AS_GetReccrds интерфейса IAppServer);
* poAutoRefresh - включает автоматическое обновление записей клиентского набора данных. По умолчанию эта возможность отключена для ускорения работы;
* poPropogateChanges - если в методах-обработчиках BeforeUpdateRecord или AfterUpdateRecord клиентского набора данных были сделаны дополнительные изменения, то после их записи в наборе данных сервера, изменения снова направляются клиенту для обновления записи. Во включенном состоянии эта возможность позволяет полностью контролировать сохранение изменений на сервере;
* poAllowCommandText - позволяет изменять текст запроса SQL, имена хранимых процедур или таблиц в компоненте набора данных на сервере приложений;
* poRetainServerOrder - включает запрет на изменение порядка сортировки записей клиентом. Если этот параметр отключить, возможны ошибки отображения набора данных, проявляющиеся в появлении двойных записей.
Методы-обработчики компонента-провайдера данных TDataSetProvider:
* AfterApplyUpdates - вызывается после сохранения изменений, переданных от клиента, в наборе данных сервера
* AfterExecute - вызывается после выполнения запроса SQL или хранимой процедуры на сервере
* AfterGetParams - вызывается после того, как компонент-провайдер сформировал набор параметров набора данных сервера для их передачи клиенту
* AfterGetRecords - вызывается после того, как компонент-провайдер сформировал пакет данных для передачи набора данных сервера клиенту
* AfterRowRequest - вызывается после обновления текущей записи клиента компонентом-провайдером
* AfterUpdateRecord - вызывается сразу после обновления единичной записи на сервере
* BeforeApplyUpdates - вызывается перед сохранением изменений, переданных от клиента, в наборе данных сервера
* BeforeExecute - вызывается перед выполнением запроса SQL или хранимой процедуры на сервере
* BeforeGetParams - вызывается перед тем, как компонент-провайдер сформировал набор параметров набора данных сервера для их передачи клиенту
* BeforeGetRecords - вызывается перед тем, как компонент-провайдер сформировал пакет данных для передачи набора данных сервера клиенту
* BeforeRowRequest - вызывается перед обновлением текущей записи клиента компонентом-провайдером
* BeforeUpdateRecord - вызывается непосредственно перед обновлением единичной записи на сервере
* OnDataRequest - вызывается при обработке запроса на получение данных клиентом
* OnGetData - вызывается после получения данных от набора данных сервера, но перед их отправкой клиенту
* OnGetDataSetProperties - вызывается при создании структуры параметров набора данных сервера для их передачи клиенту
* OnGetTableName - вызывается при получении компонентом-провайдером имени таблицы, подлежащей обновлению
* OnUpdateData - вызывается при сохранении изменений в наборе данных сервера
* OnUpdateError - вызывается при возникновении ошибки сохранения изменений в наборе данных сервера
== Вспомогательные компоненты - брокеры соединений ==
В состав компонентов DataSnap входит ряд дополнительных компонентов, облегчающих работу с соединениями удаленных клиентов с сервером приложений. Рассмотрим их.
=== Компонент TSimpleObjectBroker ===
Компонент TSimpleObjectBroker инкапсулирует список серверов, доступных для клиентов данного многозвенного распределенного приложения. Список серверов создается на этапе разработки. При необходимости (отключение сервера, его перегрузка и т. д.) компонент соединения клиентского ПО может использовать один из запасных серверов из списка компонента TsimpleobjectBroker непосредственно во время выполнения.
Для этого необходимо заполнить список серверов компонента TSimpleObjectBroker и указать ссылку на него в свойстве ObjectBroker компонента соединения (см. выше). И тогда при "переоткрытии" соединения имя сервера будет запрашиваться из списка компонента TSimpleObjectBroker.
Список серверов задается свойством Servers
На этапе разработки список серверов заполняется специализированным редактором, который вызывается при щелчке на кнопке свойства в Инспекторе объектов. Свойство Servers представляет собой коллекцию объектов класса TServerItem. Этот класс имеет несколько свойств, позволяющих описать основные параметры сервера. При использовании в соединении значения этих свойств подставляются в соответствующие свойства компонента соединения.
Свойства класса TServerItem:
* ComputerName - имя компьютера, на котором функционирует сервер
* DisplayName - содержит имя сервера для представления в списке серверов
* Enabled - управляет доступностью записи о сервере для выбора при подключении. При значении True компоненты соединений могут использовать данную запись списка для подключения
* HasFailed - после неудачной попытки использовать данную запись списка при подключении свойству присваивается значение True и в дальнейшем эта запись не используется
* Port - содержит номер порта, используемого при подключении к серверу
Помимо списка серверов компонент имеет лишь несколько вспомогательных свойств и методов.
* GetComputerForGUID() - возвращает имя компьютера, на котором зарегистрирован сервер с GUID, заданным параметром.
* GetComputerForProgID() - возвращает имя компьютера, на котором зарегистрирован сервер с именем, заданным параметром ProgID.
* LoadBalanced - управляет выбором сервера из списка. При значении True запись о сервере выбирается случайным образом, иначе для соединения предлагается первая доступная запись о сервере.
=== Компонент TLocalConnection ===
Компонент TLocalConnection используется локально для получения доступа к существующим компонентам-провайдерам.
* Providers - содержит ссылки на все компоненты-провайдеры, размещенные с компонентом TLocalConnection на одной форме. Индексация в списке осуществляется по имени компонента-провайдера.
* ProviderCount - возвращает общее число компонентов-провайдеров в списке.
Кроме этого, при помощи компонента TLocalConnection можно получить доступ к интерфейсу IAppServer локально. Для этого используется свойство AppServer или метод GetServer()
=== Компонент TSharedConnection ===
Если интерфейс IAppServer удаленного модуля данных имеет метод, возвращающий ссылку на аналогичный интерфейс другого удаленного модуля данных, то первый модуль называется главным, а второй - дочерним. Компонент TSharedConnection используется для соединения клиентского приложения с дочерним удаленным модулем данных сервера приложений.
* ParentConnection - должно содержать ссылку на компонент соединения с главным удаленным модулем данных сервера приложений.
* ChildName - имя дочернего удаленного модуля данных 
Если интерфейс главного удаленного модуля данных настроен правильно, то в списке выбора свойства в Инспекторе объектов появляются имена всех дочерних удаленных модулей данных.
Интерфейс IAppServer дочернего удаленного модуля данных возвращает свойство AppServer или метод GetServer()
Методы-обработчики компонента TSharedConnection унаследованы от класса предка TCustomConnection
=== Компонент TConnectionBroker ===
Компонент TConnectionBroker обеспечивает централизованное управление соединением клиентских наборов данных с сервером приложений. Для этого свойство ConnectionBroker клиентских наборов данных должно ссылаться на экземпляр компонента TConnectionBroker. Тогда для изменения соединения (например, при переходе с транспорта HTTP на сокеты TCP/IP) нет необходимости изменять значение свойства RemoteServer всех компонентов TClientDataSet, а достаточно изменить свойство Connection компонента TConnectionBroker.
Доступ к интерфейсу IAppServer обеспечивает свойство AppServer или метод GetServer()
ID: 04362
Category:Базы данных
Category:Статьи
Category:Справочники