Технология DataSnap. Механизмы удаленного доступа

• Структура многозвенного приложения в Delphi
• Трехзвенное приложение в Delphi
  • Сервер приложений
  • Клиентское приложение
• Механизм удаленного доступа к данным DataSnap
  • Компонент TDCOMConnection
  • Компонент TSocketConnection
  • Компонент TWebConnection
• Провайдеры данных
• Вспомогательные компоненты — брокеры соединений
  • Компонент TSimpleObjectBroker
  • Компонент TLocalConnection
  • Компонент TSharedConnection
  • Компонент TConnectionBroker
• Резюме

В главах части IV мы рассматривали вопросы создания обычных приложений БД, работающих с базами данных на локальных компьютерах или в пределах локальной сети. Однако, как быть, если необходимо создать приложение, которое может с одинаковым успехом работать как в локальной сети, так и на удаленном компьютере.

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 20.1. Многозвенная архитектура приложений БД

Таким образом, многозвенное приложение БД состоит из (рис. 20.1):

•  "тонких" клиентских приложений, обеспечивающих лишь передачу, представление, редактирование и простейшую обработку данных;
•  одного или нескольких звеньев ПО промежуточного слоя (сервер приложений), которые могут функционировать как на одном компьютере, так и распределенно — в локальной сети;
•  сервера БД (Oralce, Sybase, MS SQL, InterBase и т. д.), поддерживающего функционирование базы данных и обрабатывающего запросы.

Более простая трехзвенная модель содержит следующие элементы: 

•  "тонкие" клиенты; 
•  сервер приложений;
•  сервер БД.

Далее мы будем рассматривать именно трехзвенную модель. В среде разработки Delphi имеется набор инструментов и компонентов для создания клиентского ПО и ПО промежуточного слоя. Серверная часть — сервер приложений описывается в гл. 21, вопросы создания клиентского ПО — в гл. 22.

Сервер приложений взаимодействует с сервером БД, используя одну из технологий доступа к данным, реализованным в Delphi (см. часть IV). Это технологии ADO, BDE, InterBase Express и dbExpress. Разработчик может выбрать наиболее подходящую, исходя из поставленной задачи и параметров сервера БД.

Удаленные клиентские приложения создаются с использованием специального набора компонентов, объединенных общим названием DataSnap. Эти компоненты инкапсулируют стандартные транспорты (DCOM, HTTP, сокеты) и обеспечивают соединение удаленного клиентского приложения с сервером приложения. Также компоненты DataSnap обеспечивают доступ клиента к функциям сервера приложений за счет использования интерфейса AppServer (см. гл. 21).

Важную роль при разработке клиентских приложений играет компонент, инкапсулирующий клиентский набор данных. Его реализации также зависят от технологий доступа к данным и рассматриваются в гл. 22.

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

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

Например, при чрезмерной загрузке сервера, сервер приложений может самостоятельно обрабатывать запросы пользователей (ставить их в очередь или отменять) без дополнительной загрузки сервера БД.

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

Кроме того, вы легко сможете использовать защищенные каналы передачи данных, например HTTPS.

Трехзвенное приложение в Delphi

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

Рис. 20.2. Схема трехзвенного распределенного приложения

Части трехзвенных приложений разрабатываются с использованием компонентов DataSnap, а также некоторых других специализированных компонентов, в основном обеспечивающих функционирование клиента. Для доступа к данным применяется одна из четырех технологий, реализованных в Delphi (см. часть IV).

 Примечание 

Разработку трехзвенных приложений целесообразно вести, используя в среде разработки группу проектов вместо одиночных проектов. Для этого используется утилита Project Manager (меню View | Project Manager).

Для передачи данных между сервером приложений и клиентами используется интерфейс AppServer, предоставляемый удаленным модулем данных сервера приложений. Этот интерфейс используют компоненты-провайдеры TDataSetProvider на стороне сервера и компоненты TClientDataSet на стороне клиента.

Сервер приложений

Сервер приложений инкапсулирует большую часть бизнес-логики распределенного приложения и обеспечивает доступ клиентов к базе данных.

Основной частью сервера приложений является удаленный модуль данных.

Во-первых, подобно обычному модулю данных (см. гл. 11) он является платформой для размещения невизуальных компонентов доступа к данным и компонентов-провайдеров. Размещенные на нем компоненты соединений, транзакций и компоненты, инкапсулирующие наборы данных, обеспечивают трехзвенное приложение связью с сервером БД. Это могут быть наборы компонентов для технологий ADO, BDE, InterBase Express, dbExpress.

Во вторых, удаленный модуль данных реализует основные функции сервера приложений на основе предоставления клиентам интерфейса IAppServer или его потомка. Для этого удаленный модуль данных должен содержать необходимое число компонентов-провайдеров TDataSetProvider. Эти компоненты передают пакеты данных клиентскому приложению, а точнее компонентам TdientDataSet, а также обеспечивают доступ к методам интерфейса.

Рис. 20.3. Выбор удаленных модулей данных в Репозитории Delphi

В состав Delphi входят удаленные модули данных. Для их создания используйте страницы Multitier, WebSnap и WebServices Репозитория Delphi (рис. 20.3).

•  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 Палитры компонентов.

Подробнее о разработке клиентского ПО для распределенных многозвенных приложений БД рассказывается в гл. 22.

Механизм удаленного доступа к данным DataSnap

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

Различные типы соединений, позволяющие настроить транспорт и начать передачу и прием данных, инкапсулированы в нескольких компонентах DataSnap. Для создания соединения с тем или иным транспортным протоколом разработчику достаточно перенести соответствующий компонент на форму и правильно настроить несколько свойств. Ниже рассматриваются варианты настройки транспортных протоколов для компонентов, использующих DCOM, сокеты TCP/IP, http.

Компонент TDCOMConnection

Компонент TDCOMConnection предоставляет транспорт на основе технологии Distributed COM и применяется в основном для организации транспорта в рамках локальной сети.

Для настройки соединения DCOM в первую очередь необходимо задать имя компьютера, на котором функционирует сервер приложений. Для компонента TDCOMConnection это должен быть зарегистрированный сервер Автоматизации. Имя компьютера задается свойством

property ComputerName: string;

Если оно задано правильно, в списке свойства

property ServerName: string;

в Инспекторе объектов можно выбрать один из доступных серверов. При выборе сервера также автоматически заполняется свойство

property ServerGUID: string;

Причем для успешного соединения клиента с сервером приложений оба свойства должны быть заданы в обязательном порядке. Только имя сервера или только его GUID не обеспечат правильный доступ к удаленному объекту СОМ.

Открытие и закрытие соединения осуществляется свойством

property Connected: Boolean;

или методами

procedure Open/procedure Close;

соответственно.

Для организации передачи данных между клиентом и сервером компонент TDCOMConnection предоставляет интерфейс IAppServer

property AppServer: Variant;

который также может быть получен методом

function GetServer: lAppServer; override;

Свойство

property ObjectBroker: TCustomObjectBroker;

позволяет использовать экземпляр компонента TsimpleObjectBroker для получения списка доступных серверов по время выполнения (см. ниже).

Методы-обработчики компонента TDCOMConnection представлены в табл. 20.1. 

Таблица 20.1. Методы-обработчики событий компонента TDCOMConnection

Компонент TSocketConnection

Компонент TSocketConnection обеспечивает соединение клиента с сервером приложений за счет использования сокетов TCP/IP. Для успешного открытия соединения на стороне сервера должен работать сокет-сервер (приложение ScktSrvr.exe, рис. 20.4).

Для успешного соединения свойство

property Host: String;

должно содержать имя компьютера сервера.

Рис. 20.4. Сокет-сервер ScktSrvr.exe 

Дополнительно, свойство

property Address: String;

должно содержать IP-адрес сервера.

Для открытия соединения должны быть заданы оба этих свойства.

Свойство

property Port: Integer;

устанавливает номер используемого порта. По умолчанию это порт 211, но разработчик волен изменить порт, например, для использования различными категориями пользователей или для создания защищенного канала.

После правильного выбора компьютера в списке свойства

property ServerName: string;

в Инспекторе объектов появляется перечень доступных серверов Автоматизации. И после выбора сервера свойство

property ServerGUID: string;

которое содержит имя компьютера GUID зарегистрированного сервера, задается автоматически, хотя его можно задать и вручную.

Метод

function GetServerList: OleVariant; virtual;

возвращает список зарегистрированных серверов Автоматизации. Открытие и закрытие соединения осуществляется свойством

property Connected: Boolean; 

или методами

procedure Open;

 procedure Close;

соответственно.

Канал сокета TCP/IP может быть зашифрован. Для этого используется свойство

property InterceptName: string;

содержащее программный идентификатор объекта СОМ, обеспечивающего шифрование/дешифрование данных в канале, и свойство

property InterceptGUID: string;

содержащее имя компьютера GUID этого объекта.

Этот объект СОМ перехватывает данные в канале и осуществляет их обработку, предусмотренную собственным программным кодом. Это может быть шифрование, сжатие, обработка шумов и т. д.

 Примечание

Создание объекта СОМ, обеспечивающего дополнительную обработку данных в канале, ложится на плечи разработчика. Объект-перехватчик должен поддерживать стандартный интерфейс IDataintercept.

Естественно, на стороне сервера должен быть зарегистрирован объект СОМ, выполняющий обратную операцию. Для этого также используется сокет-сервер (рис. 20.5). Строка Interceptor на странице должна содержать имя компьютера GUID объекта-перехватчика СОМ.

Рис. 20.5. Регистрация объекта-перехватчика СОМ в сокет-сервере

Метод

function GetlnterceptorList: OleVariant; virtual;

возвращает список зарегистрированных на сервере объектов-перехватчиков.

Для организации передачи данных между клиентом и сервером компонент TSocketConnection предоставляет интерфейс IAppServer 

property AppServer: Variant;

который также может быть получен методом

function GetServer: lAppServer; override;

Свойство

property ObjectBroker: TCustomObjectBroker;

позволяет использовать экземпляр компонента TSimpieObjectBroker для получения списка доступных серверов во время выполнения (см. ниже).

Методы-обработчики событий компонента TSocketConnection полностью совпадают с методами-обработчиками компонента TDCOMConnection (см. табл. 20.1).

Компонент 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, то свойство

property URL: string;

должно содержать следующее значение:

  http://someserver.com/scripts/httpsrvr.dll

Если URL задан верно и сервер настроен правильно, то в списке свойства

property ServerName: string;

в Инспекторе объектов появляется перечень зарегистрированных серверов

Приложений. Имя одного из них должно содержаться в свойстве ServerName.

После выбора имени сервера в свойстве

property ServerGUID: string;

автоматически появляется GUID сервера. Свойства

property UserName: string;

И

property Password: string;

при необходимости могут содержать имя и пароль пользователя, которые будут использованы при авторизации.

Свойство

property Proxy: string;

содержит имя используемого прокси-сервера.

В заголовок сообщений HTTP можно поместить имя приложения. Для этого используется свойство

property Agent: string;

Соединение открывается и закрывается при помощи свойства

property Connected: Boolean;

Аналогичные операции выполняют методы

procedure Open;

 procedure Close;

Доступ к интерфейсу IAppServer предоставляет свойство

property AppServer: Variant;

или метод

function GetServer: IAppServer; override;

Список доступных соединению серверов приложений возвращает метод

function GetServerList: OleVariant; virtual; 

Свойство

property ObjectBroker: TCustomObjectBroker;

позволяет использовать экземпляр компонента TSimpieObjectBroker для получения списка доступных серверов во время выполнения (см. ниже).

Методы-обработчики событий компонента TWebConnection полностью совпадают с методами-обработчиками компонента TDCOMConnection (см. табл. 20.1).

Провайдеры данных

Компонент-провайдер TDataSetProvider представляет собой мост между набором данных сервера приложений и клиентским набором данных. Он обеспечивает формирование и передачу пакетов данных клиентскому приложению и прием от него сделанных изменений (см. рис. 20.2).

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

property DataSet: TDataSet;

Если соединение в клиентском приложении настроено правильно (см. выше), ТО В списке выбора свойства ProviderName компонента TClientDataSet в Инспекторе объектов появляются имена всех компонентов-провайдеров сервера приложений. Если связать клиентский набор данных с компонентом-провайдером, а затем открыть его, в клиентский набор данных будут переданы записи из набора данных сервера приложений, указанного в свойстве DataSet компонента-провайдера TDataSetProvider.

Компонент также содержит свойства, помогающие настроить процесс обмена данными.

Свойство

property ResolveToDataSet: Boolean;

управляет передачей данных от клиента серверу БД. Если оно имеет значение True, все изменения передаются в набор данных сервера приложений, заданный свойством DataSet. Иначе изменения направляются напрямую серверу БД. Если сервер приложений не должен отображать сделанные клиентом изменения, то свойству ResolveToDataSet можно присвоить значение False, что ускорит работу приложения.

Свойство

property Constraints: Boolean;

управляет передачей ограничений серверного набора данных клиентскому. Если свойство имеет значение True, ограничения передаются.

Свойство

property Exported: Boolean;

позволяет использовать в клиентском наборе данных интерфейс IAppServer. Для этого свойство должно иметь значение True.

Параметры компонента-провайдера задаются свойством

type

TProviderOption = (poFetchBlobsOnDemand, poFetchDetailsOnDemand,

poIncFieldProps, poCascadeDeletes, poCascadeUpdates, poReadOnly, poAllowMultiRecordUpdates, poDisablelnserts, poDisableEdits, poDisableDeletes, poNoReset, poAutoRefresh, poPropogateChanges, poAllowCoinmandText, poRetainServerOrder);

TProviderOptions = set of TProviderOption;

Набор параметров свойства задается присвоением элементам значения True.

property Options: TProviderOptions;

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 — включает запрет на изменение порядка сортировки записей клиентом. Если этот параметр отключить, возможны ошибки отображения набора данных, проявляющиеся в появлении двойных записей.

Методы-обработчики компонента-провайдера данных представлены в табл. 20.2.

Таблица 20.2. Методы-обработчики событий компонента TDataSetProvider

Вспомогательные компоненты — брокеры соединений

В состав компонентов DataSnap входит ряд дополнительных компонентов, облегчающих работу с соединениями удаленных клиентов с сервером приложений. Рассмотрим их.

Компонент TSimpleObjectBroker

Компонент TSimpleObjectBroker инкапсулирует список серверов, доступных для клиентов данного многозвенного распределенного приложения. Список серверов создается на этапе разработки. При необходимости (отключение

сервера, его перегрузка и т. д.) компонент соединения клиентского ПО может использовать один из запасных серверов из списка компонента TsimpleobjectBroker непосредственно во время выполнения.

Для этого необходимо заполнить список серверов компонента TSimpleobjectBroker и указать ссылку на него в свойстве objectBroker компонента соединения (см. выше). И тогда при "переоткрытии" соединения имя сервера будет запрашиваться из списка компонента TsimpleobjectBroker.

Список серверов задается свойством

property Servers: TServerCollection;

На этапе разработки список серверов заполняется специализированным редактором (рис. 20.6), который вызывается при щелчке на кнопке свойства в Инспекторе объектов.

Рис.20.6.Редактор списка серверов компонента TSimpleObjectBroker

Свойство servers представляет собой коллекцию (см. гл. 7) объектов класса TServeritem. Этот класс имеет несколько свойств, позволяющих описать основные параметры сервера (табл. 20.3). При использовании в соединении значения этих свойств подставляются в соответствующие свойства компонента соединения.

Таблица 20.3. Свойства класса TServeritem

Помимо списка серверов компонент имеет лишь несколько вспомогательных свойств и методов.

Метод

function GetComputerForGUID(GUID: TGUID): string; override;

возвращает имя компьютера, на котором зарегистрирован сервер с GUID, заданным параметром.

Метод

function GetComputerForProgID(const ProgID): string; override;

возвращает имя компьютера, на котором зарегистрирован сервер с именем, заданным параметром Progio.

Свойство

property LoadBalanced: Boolean;

управляет выбором сервера из списка. При значении True запись о сервере выбирается случайным образом, иначе для соединения предлагается первая доступная запись о сервере.

Компонент TLocalConnection

Компонент TLocalConnection используется локально для получения доступа к существующим компонентам-провайдерам.

Свойство

property Providers[const ProviderName: string]: TCustomProvider;

содержит ссылки на все компоненты-провайдеры, размещенные с компонентом TLocalConnection на одной форме. Индексация в списке осуществляется по имени компонента-провайдера.

Общее число компонентов-провайдеров в списке возвращает свойство

property ProviderCount: Integer;

Кроме этого, при помощи компонента TLocalConnection можно получить доступ к интерфейсу IAppServer локально. Для этого используется свойство

property AppServer: IAppServer;

или метод

function GetServer: IAppServer; override;

Компонент TSharedConnection

Если интерфейс IAppServer удаленного модуля данных имеет метод, возвращающий ссылку на аналогичный интерфейс другого удаленного модуля данных, то первый модуль называется главным, а второй — дочерним (см. гл. 21). Компонент TSharedConnection используется для соединения клиентского приложения с дочерним удаленным модулем данных сервера приложений.

Свойство

property ParentConnection: TDispatchConnection;

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

property ChildName: string;

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

Интерфейс IAppServer дочернего удаленного модуля данных возвращает свойство

property AppServer: Variant;

или метод

function GetServer: lAppServer; override;

Методы-обработчики компонента TSharedConnection унаследованы от класса предка TCustomConnection (см. табл. 20.1).

Компонент TConnectionBroker

Компонент TConnectionBroker обеспечивает централизованное управление соединением клиентских наборов данных с сервером приложений. Для этого свойство connectionBroker клиентских наборов данных должно ссылаться на экземпляр компонента TConnectionBroker. Тогда для изменения соединения (например, при переходе с транспорта HTTP на сокеты TCP/IP) нет необходимости изменять значение свойства RemoteServer всех компонентов TClientDataSet, а достаточно изменить свойство

property Connection: TCustomRemoteServer;

компонента TConnectionBroker.

Доступ к интерфейсу IAppServer обеспечивает свойство

property AppServer: Variant;

или метод

function GetServer: lAppServer; override;

Методы-обработчики компонента TConnectionBroker полностью соответствуют табл. 20.1.

Резюме

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

В Delphi для создания трехзвенных распределенных приложений используются компоненты DataSnap и удаленные модули данных. Все эти инструменты реализованы для различных типов транспортных протоколов.

Также в трехзвенных приложениях применяются компоненты-провайдеры TDataSetProvider и компоненты TClientDataSet, инкапсулирующие наборы данных на клиентской стороне.