Технология DataSnap. Сервер приложений.
Рассмотрим модель распределенного приложения БД,
которая называется многозвенной (multitiered), и, в частности, ее наиболее
простой вариант — трехзвенное распределенное приложение. Тремя частями такого
приложения являются:
·
собственно
сервер базы данных;
·
сервер
приложений (серверная часть приложения);
·
клиентская
часть приложения.
Все они объединены в единое целое единым
механизмом взаимодействия (транспортный уровень) и обработки данных (уровень
бизнес-логики).
Компоненты и объекты Delphi, обеспечивающие
разработку многозвенных приложений, объединены общим названием DataSnap.
Многозвенная архитектура приложений баз данных
вызвана к жизни необходимостью обрабатывать на стороне сервера запросы от
большого числа удаленных клиентов. Казалось бы, с этой задачей вполне могут
справиться и приложения клиент/сервер, однако в этом случае при большом числе
клиентов вся вычислительная нагрузка ложится на сервер БД, который обладает
довольно скудным набором средств для реализации сложной бизнес-логики (хранимые
процедуры, триггеры, просмотры и т. д.). И разработчики вынуждены существенно
усложнять программный код клиентского ПО, а это крайне нежелательно при наличии
большого Числа удаленных клиентских компьютеров
Многозвенная архитектура приложений БД призвана
исправить перечисленные недостатки.
Итак, в рамках этой архитектуры
"тонкие" клиенты представляют собой простейшие приложения,
обеспечивающие лишь передачу данных, их локальное кэширование, представление
средствами пользовательского интерфейса, редактирование и простейшую обработку.
Клиентские приложения обращаются не к серверу БД
напрямую, а к специализированному ПО промежуточного слоя. Это может быть и одно
звено (простейшая трехзвенная модель) и более сложная структура.
ПО промежуточного слоя называется сервером
приложений, принимает запросы клиентов, обрабатывает их в соответствии с
запрограммированными правилами бизнес-логики, при необходимости преобразует в
форму, удобную для сервера БД и отправляет серверу.
Сервер БД выполняет полученные запросы и
отправляет результаты серверу приложений, который адресует данные клиентам.
Таким образом, многозвенное приложение БД
состоит из (рис. 20.1):
·
"тонких"
клиентских приложений, обеспечивающих лишь передачу, представление, редактирование
и простейшую обработку данных;
·
одного
или нескольких звеньев ПО промежуточного слоя (сервер приложений), которые
могут функционировать как на одном компьютере, так и распределенно — в
локальной сети;
·
сервера
БД (Oralce, Sybase, MS SQL, InterBase и т. д.), поддерживающего
функционирование базы данных и обрабатывающего запросы.
Сервер приложений взаимодействует с сервером БД,
используя одну из технологий доступа к данным, реализованным в Delphi. Это
технологии ADO, BDE, InterBase Express и dbExpress. Разработчик может выбрать
наиболее подходящую, исходя из поставленной задачи и параметров сервера БД.
Удаленные клиентские приложения создаются с
использованием специального набора компонентов, объединенных общим названием
DataSnap. Эти компоненты инкапсулируют стандартные транспорты (DCOM, HTTP,
сокеты) и обеспечивают соединение удаленного клиентского приложения с сервером
приложения. Также компоненты DataSnap обеспечивают доступ клиента к функциям
сервера приложений за счет использования интерфейса AppServer.
Так как зачастую клиентские компьютеры — это
достаточно слабые машины, реализация сложной бизнес-логики на сторону сервера
позволяет существенно повысить быстродействие системы в целом. И не только за
счет более мощной техники, но и за счет оптимизации выполнения однородных
запросов пользователей.
Например, при чрезмерной загрузке сервера,
сервер приложений может самостоятельно обрабатывать запросы пользователей
(ставить их в очередь или отменять) без дополнительной загрузки сервера БД.
Наличие сервера приложений повышает безопасность
системы, т. к. вы можете организовать здесь авторизацию пользователей, да и
любые другие функции безопасности без прямого доступа к данным.
Кроме того, вы легко сможете использовать
защищенные каналы передачи данных, например HTTPS.
Трехзвенное приложение в Delphi
Теперь рассмотрим составные части трехзвенного
распределенного приложения в Delphi. Как говорилось выше, в Delphi
целесообразно разрабатывать клиентскую часть трехзвенного приложения и ПО
промежуточного слоя — сервер приложений.
Рис. 20.2. Схема трехзвенного
распределенного приложения
Для передачи данных между сервером приложений и
клиентами используется интерфейс AppServer, предоставляемый удаленным модулем
данных сервера приложений. Этот интерфейс используют компоненты-провайдеры
TDataSetProvider на стороне сервера и компоненты TClientDataSet на стороне
клиента.
Сервер
приложений
Сервер приложений инкапсулирует большую часть
бизнес-логики распределенного приложения и обеспечивает доступ клиентов к базе
данных.
Основной частью сервера приложений является
удаленный модуль данных.
Во-первых, подобно обычному модулю данных он
является платформой для размещения невизуальных компонентов доступа к данным и
компонентов-провайдеров. Размещенные на нем компоненты соединений, транзакций и
компоненты, инкапсулирующие наборы данных, обеспечивают трехзвенное приложение
связью с сервером БД. Это могут быть наборы компонентов для технологий ADO,
BDE, InterBase Express, dbExpress.
Во вторых, удаленный модуль данных реализует
основные функции сервера приложений на основе предоставления клиентам
интерфейса IAppServer или его потомка. Для этого удаленный модуль данных должен
содержать необходимое число компонентов-провайдеров TDataSetProvider. Эти
компоненты передают пакеты данных клиентскому приложению, а точнее компонентам
TdientDataSet, а также обеспечивают доступ к методам интерфейса.
В состав Delphi входят удаленные модули данных.
Для их создания используйте страницы Multitier, WebSnap и WebServices Репозитория
Delphi
·
Remote Data Module — удаленный модуль данных, инкапсулирующий
сервер Автоматизации. Используется для организации соединений через DCOM, HTTP,
сокеты
·
Transactioiial Data Module — удаленный модуль
данных, инкапсулирующий сервер MTS (Microsoft Transaction Server).
·
SOAP Server Data Module — удаленный модуль
данных, инкапсулирующий сервер SOAP (Simple Object Access Protocol).
·
WebSnap Data Module — удаленный модуль данных, использующий
Web-службы и Web-браузер в качестве сервера.
Помимо удаленного модуля данных неотъемлемой
частью сервера приложений являются компоненты-провайдеры TDataSetProvider. С
каждым компонентом, инкапсулирующим набор данных, предназначенным для передачи
клиенту, в модуле данных должен быть связан компонент-провайдер.
Интерфейс IAppServer
Интерфейс IAppServer является основной механизма
удаленного доступа клиентских приложений к серверу приложения. Набор данных
клиента использует его для общения с компонентом-провайдером на сервере
приложения. Наборы данных клиента получают экземпляр IAppServer от компонента
соединения в клиентском приложении.
При создании удаленных модулей данных каждому такому
модулю ставится в соответствие вновь создаваемый интерфейс, предком которого
является интерфейс IAppServer.
Разработчик может добавить к новому интерфейсу
собственные методы, которые, благодаря возможностям механизма удаленного
доступа многозвенных приложений, становятся доступны приложению-клиенту.
Свойство
property AppServer: Variant;
в клиентском приложении имеется как в компонентах
удаленного соединения, так и клиентском наборе данных.
По умолчанию интерфейс является несохраняющим
состояние (stateless). Это означает, что вызовы методов интерфейса независимы и
не привязаны к предыдущему вызову. Поэтому интерфейс IAppServer не имеет
свойств, которые бы хранили информацию о состоянии между вызовами.
Обычно разработчику ни к чему использовать методы
интерфейса напрямую, однако его значение для многозвенных приложений трудно
переоценить. И при детальной работе с механизмом удаленного доступа интерфейс
понадобится так или иначе.
Для создания нового сервера приложения достаточно
выполнить несколько простых операций.
1. Создать новый проект, выбрав в качестве типа
проекта обычное приложение (пункт меню File | New | Application) и
сохранить его.
2. В зависимости от используемой технологии, выбрать
из Репозитория Delphi необходимый тип удаленного модуля данных (см. рис. 20.3).
Удаленные модули данных располагаются на страницах Multitier, WebSnap и
WebServices.
3. Настроить параметры создаваемого удаленного модуля
данных
4. Разместить в удаленном модуле данных компоненты
доступа к данным и настроить их. Здесь разработчик может выбрать один из
имеющихся наборов компонентов ( в зависимости от используемого сервера БД и
требуемых характеристик создаваемого приложения.
5. Разместить в удаленном модуле данных необходимое
число компонентов TDataSetProvider и связать их с компонентами,
инкапсулирующими наборы данных.
6. При необходимости создать для потомка интерфейса
IAppServer, используемого в удаленном модуле данных, дополнительные методы. Для
этого создается новая библиотека типов
7. Скомпилировать проект и создать исполняемый файл
сервера приложения.
8. Зарегистрировать сервер приложения и при
необходимости настроить дополнительное ПО.
Весь механизм удаленного доступа, инкапсулированный в
удаленных модулях данных и компонентах-провайдерах, работает автоматически, без
создания разработчиком дополнительного программного кода.
Клиентское приложение
Клиентское приложение в трехзвенной модели
должно обладать лишь минимально необходимым набором функций, делегируя
большинство операций по обработке данных серверу приложений.
В первую очередь удаленное клиентское приложение
должно обеспечить соединение с сервером приложений. Для этого используются
компоненты соединений DataSnap:
·
TDCOMConnection
— использует DCOM;
·
TSocketconnection
— использует сокеты Windows;
·
TWebConnection
— использует HTTP.
Компоненты соединения DataSnap предоставляют
интерфейс IAppServer, используемый компонентами-провайдерами на стороне сервера
и компонентами TClientDataSet на стороне клиента для передачи пакетов данных.
Для работы с наборами данных используются
компоненты TClientDataSet, работающие в режиме кэширования данных.
Структура клиентского приложения
По своей структуре клиентское приложение подобно
обычному приложению баз данных.
Соединение клиента с сервером приложений
осуществляется специализированными компонентами DataSnap. Эти компоненты
взаимодействуют с удаленным модулем данных, входящим в состав сервера, при
помощи методов интерфейса IAppServer.
Также в клиентском приложении могут
использоваться дополнительные, определенные разработчиком, методы интерфейса
удаленного модуля данных, унаследованного от интерфейса IAppServer.
Соединение с сервером приложений обеспечивает
динамическая библиотека MIDAS.DLL, которая должна быть зарегистрирована на
компьютере клиента.
Как и обычное приложение БД, клиент
многозвенного распределенного приложения должен содержать компоненты,
инкапсулирующие набор данных, которые связаны с визуальными компонентами
отображения данных посредством компонентов TDataSource.
Очевидно, что набор данных сервера должен быть
скопирован клиентским приложением в некий локальный буфер. При этом должен
использоваться эффективный механизм загрузки данных сравнительно небольшими
порциями, что позволяет значительно разгрузить транспортный канал между
клиентом и сервером приложений.
Кэширование и редактирование данных в клиентском
приложении обеспечивает специализированный компонент TclientDataSet, отдаленным
предком которого является класс TDataSet. Помимо унаследованных от предков
методов, класс TclientDataSet инкапсулирует ряд дополнительных функций,
облегчающих управление данными.
Подобно обычному приложению БД, в
"тонком" клиенте для размещения невизуальных компонентов доступа к
данным необходимо использовать модули данных.
Для получения набора данных сервера компонент
TclientDataSet взаимодействует с компонентом TDataSetProvider, используя методы
интерфейса IProviderSupport
По существу все уникальные функции клиентского приложения
сосредоточены в компоненте. Клиентское приложение не отличается от обычного
приложения БД и при его разработке могут применяться стандартные методы.
Клиентские наборы данных
В Палитре компонентов Delphi представлено
несколько компонентов, инкапсулирующих клиентский набор данных. В то же время
при разработке настоящих удаленных клиентских приложений применяется компонент
TClientDataSet. Внесем ясность в этот вопрос. Итак, помимо компонента
TClientDataSet, расположенного на странице Data Access, существуют еще два
компонента:
·
TSimpleDataSet
— разработан для технологии доступа к данным dbExpress и, по существу, является
единственным полноценным средством для работы с набором данных в рамках этой
технологии;
·
TiBdientDataSet
— используется в технологии доступа к данным сервера InterBase — InterBase
Express.
Все перечисленные компоненты произошли от общего
предка — класса TCustomClientDataSet. Они обеспечивают
локальное кэширование данных и взаимодействие с серверным набором данных при
посредстве интерфейса IProviderSupport.
Основное различие между компонентом
TClientDataSet и другими клиентскими компонентами заключается в том, что первый
предназначен для использования с внешним компонентом-провайдером данных. А
значит, он может взаимодействовать с удаленным провайдером данных.
Остальные перечисленные компоненты инкапсулируют
внутренний провайдер данных, предоставляя тем самым для использования в рамках
соответствующих технологий доступа к данным эффективный механизм локального
кэширования данных. Использование внутреннего провайдера данных обеспечивает
общий класс- предок TCustomCachedDataSet.
Рис. 22.2. Иерархия
классов клиентских наборов данных
Для этого он имеет защищенное свойство
property Provider: TDataSetProvider;
Соединение с источником данных осуществляется не
свойством RemoteServer задающим удаленный сервер, а стандартными средствами
соответствующей технологии доступа к данным.
Таким образом, для работы с удаленными данными
(т. е. внешними по отношению к клиенту) пригоден только компонент
TclientDataSet, умеющий работать с внешним провайдером данных.
(продолжение вопроса)
Передача данных
Для передачи пакетов данных между
компонентом-провайдером и клиентским набором данных (между клиентом и сервером)
должен существовать некий транспортный канал, обеспечивающий физическую
передачу данных. Для этого могут использоваться разнообразные транспортные
протоколы, поддерживаемые операционной системой.
Различные типы соединений, позволяющие настроить
транспорт и начать передачу и прием данных, инкапсулированы в нескольких
компонентах DataSnap. Для создания соединения с тем или иным транспортным протоколом
разработчику достаточно перенести соответствующий компонент на форму и
правильно настроить несколько свойств. Ниже рассматриваются варианты настройки
транспортных протоколов для компонентов, использующих DCOM, сокеты TCP/IP,
http.
Компонент 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 для получения списка доступных серверов по время выполнения
Компонент
TSocketConnection
Компонент TSocketConnection обеспечивает
соединение клиента с сервером приложений за счет использования сокетов TCP/IP.
Для успешного открытия соединения на стороне сервера должен работать
сокет-сервер (приложение ScktSrvr.exe, рис. 20.4).
Для успешного соединения свойство
property Host: String;
должно содержать имя компьютера сервера.
Дополнительно, свойство
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 этого объекта.
Этот объект СОМ перехватывает данные в канале и
осуществляет их обработку, предусмотренную собственным программным кодом. Это
может быть шифрование, сжатие, обработка шумов и т. д.
Компонент 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 для получения списка доступных серверов во время выполнения
Провайдеры данных
Компонент-провайдер TDataSetProvider представляет
собой мост между набором данных сервера приложений и клиентским набором данных.
Он обеспечивает формирование и передачу пакетов данных клиентскому приложению и
прием от него сделанных изменений.
Все необходимые операции компонент выполняет
автоматически. Разработчику необходимо лишь разместить компонент
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 — включает запрет на изменение
порядка сортировки записей клиентом. Если этот параметр отключить, возможны
ошибки отображения набора данных, проявляющиеся в появлении двойных записей.
